oliveregger
commented
2 years ago Thanks for the input, please find comments below.
Closed qligier closed 2 years ago
oliveregger
commented
2 years ago Thanks for the input, please find comments below.
oliveregger
commented
2 years ago Some elements are marked as "Must support", should we make sure these are mapped when implementing a converter? My plan was to firstly focus on required elements only, but some optional elements are marked as "Must support", so that would change my implementation scope.
The definition of must Support in IHE Implementation Guides is found in Appendix Z. This is equivalent to the IHE use of R2 as defined in Appendix Z.
we will add this to the implementation guide also.
oliveregger
commented
2 years ago DocumentReference-DocumentEntry mapping, comments to https://qligier.github.io/ch-epr/DocumentReference-DocumentEntry%20mapping.html
masterIdentifier
Mapped to DocumentEntry.uniqueId. In XDS, it’s an OID (1.3.6.1.4.1.21367.2005.3.7); in FHIR, it’s an URN-encoded OID (urn:oid:1.3.6.1.4.1.21367.2005.3.7) with the system urn:ietf:rfc:3986. ⚠️ value should be required and constrained to an UUID.
constrained to an OID (not UUID). IHE MHD did not constrain the identifier data type further, probably because XDS on FHIR is only an option. We will integrate into this IG and adjusted the examples the system urn:ietf:rfc:3986, thanks.
identifier
Mapped to DocumentEntry.entryUUID. How? The entryUUID is mapped to Identifier.value. Do we need a type/system to specify it’s the entryUUID (the identifier is 1..*? How to select the entryUUID in multiple identifiers? => If it’s implementation dependant, the MHD sender is unable to know what will be the mapped entryUUID, that’s bad. Restrict to 1..1 and UUID? ⚠️ value should be required and constrained to an UUID.
It is stated that 'When the DocumentReference.identifier carries the entryUUID then the DocumentReference.identifier use shall be ‘official’. And it needs to be an UUID. The entryUUID handling with MDS and XDS is however in discussion and will impact probably in future also this IG.
type
Mapped to DocumentEntry.typeCode. Value set on both sides. ⚠️ XDS requires the value, display name and coding scheme. Those are optional in MHD. ⚠️ MHD binding is only preferred, not required. ⚠️ No type-category mapping, as per DocumentEntry.classCode_DocumentEntry.typeCode_mapping.
category
Mapped to DocumentEntry.classCode. Value set on both sides. ⚠️ XDS requires the value, display name and coding scheme. Those are optional in MHD. ⚠️ MHD binding is only preferred, not required. ⚠️ No type-category mapping, as per DocumentEntry.classCode_DocumentEntry.typeCode_mapping.
same comments as to types above.
author
Complex mapping. Mapped to DocumentEntry.author. ⚠️ No MHD binding but XDS constrained by value set DocumentEntry.authorSpeciality. ⚠️ No MHD binding but XDS constrained by value set DocumentEntry.author.authorRole.
DocumentEntry.authorSpeciality -> ValueSet is http://fhir.ch/ig/ch-epr-term/ValueSet-DocumentEntry.authorSpeciality.html DocumentEntry.author.authorRole -> ValueSet is http://fhir.ch/ig/ch-epr-term/ValueSet-DocumentEntry.authorRole.html
XDS on FHIR does not give any detailed guidance on the author mapping. In the Swiss EPR spec we do not have any requirements for author mapping, so I think if further clarification is needed it would be best to add to IHE MHD.
ch-ext-author-authorrole
Mapped to DocumentEntry.author.authorRole. Value set on both sides. ⚠️ It’s 0..* in XDS and 1..1 in MHD.
Mapped to Document Entry.originalProviderRole and is in XDS according to the swiss spec a 1..1: 1.2.4.4 Document Entry.originalProviderRole An extra metadata attribute SHALL... Added the Name orginalProviderRole to the description.
securityLabel
Mapped to DocumentEntry.confidentialityCode. Value set on both sides. ⚠️ XDS requires the value, display name and coding scheme. Those are optional in MHD. ⚠️ MHD binding is only preferred, not required.
changed to required, thanks.
originalProviderRole
⚠️ Absent from the current MHD profiles.
see ch-ext-author-authorrole above which is the extension to hold the originalProviderRole
date
⚠️ Absent from XDS.
this is an open issue in MHD and will be clarified
content.attachment.contentType
Mapped to DocumentEntry.mimeType. ⚠️ No MHD binding but XDS constrained by value set DocumentEntry.mimeType.
added required binding to http://fhir.ch/ig/ch-epr-term/ValueSet-DocumentEntry.mimeType.html
content.attachment.language
Mapped to DocumentEntry.languageCode. Value set on both sides. ⚠️ MHD binding is only preferred, not required.
added required binding to https://fhir.ch/ig/ch-epr-term/ValueSet-DocumentEntry.languageCode.html, however needs a new release due to https://github.com/hl7ch/ch-epr-term/issues/6
content.attachment.creation
Mapped to DocumentEntry.creationTime. ⚠️ Absent for On-Demand document but always required in MHD. ⚠️ XDS and MHD allow for different date formats.
On-Demand document is not yet supported in MHD, could this be a work item proposal for IHE? see also objectType
content.format
Mapped to DocumentEntry.formatCode. Value set on both sides. ⚠️ XDS requires the value, display name and coding scheme. Those are optional in MHD. ⚠️ MHD binding is only preferred, not required.
set MHD binding to required
context.event
Mapped to DocumentEntry.eventCodeList. ⚠️ MHD binding HL7 v3 Value Set ActCode is incompatible with DocumentEntry.eventCodeList value set.
The MHD binding is an example binding, so this could be changed to any binding. for the swiss epr I don't see a necessity for any binding.
context.facilityType
Mapped to DocumentEntry.healthcareFacilityTypeCode.Value set on both sides. ⚠️ XDS requires the value, display name and coding scheme. Those are optional in MHD. ⚠️ MHD binding is only preferred, not required.
added required binding
context.practiceSetting
Mapped to DocumentEntry.practiceSettingCode.Value set on both sides. ⚠️ XDS requires the value, display name and coding scheme. Those are optional in MHD. ⚠️ MHD binding is only preferred, not required.
added required binding
objectType
⚠️ Absent from MHD but required in XDS. It should not be an issue for the PMP or the MobileAccessGateway, but others may encounter it.
this is also an On-Demand metadata topic for MHD future development.
oliveregger
commented
2 years ago Comments to DocumentReference-DocumentEntry mapping guide/review for the Resource Profile: CH MHD DocumentReference Comprehensive
ihe-designationType
Mapped to SubmissionSet.contentTypeCode? ⚠️ Not bound in MHD but restrained in XDS by SubmissionSet.contentTypeCode.
ihe-sourceId
Mapped to SubmissionSet.sourceId. ⚠️ value should be required.
raised an issue in MHD
ihe-intendedRecipient
Complex mapping. Optional, so not so important for a first mapping. ⚠️ Bad reference types (not the CH Core types).
intendedRecipient is optional and there is no requirement from the EPR specification so that's why it is not further constrained
identifier:uniqueId
Mapped to SubmissionSet.uniqueId. ⚠️ value should be required and constrained to an UUID.
it is currently not sliced into the different parts, this could be however done, but waiting outcome of discussion of https://github.com/IHE/ITI.MHD/issues/92 and https://github.com/IHE/ITI.MHD/issues/93
identifier:entryUUID
Mapped to SubmissionSet.entryUUID. How to select the entryUUID in multiple identifiers? => If it’s implementation dependant, the MHD sender is unable to know what will be the mapped entryUUID, that’s bad. Restrict to 1..1 and UUID? ⚠️ value should be required and constrained to an UUID. ⚠️ The cardinality could be adjusted to 1..1.
differentiation is with use, also waiting on outcome of discussion of https://github.com/IHE/ITI.MHD/issues/92 and https://github.com/IHE/ITI.MHD/issues/93
status
Mapped to SubmissionSet.availabilityStatus. In XDS, the status is always Approved. ⚠️ It should be fixed to current, as it is in the published version.
raised an issue for IHE MHD.
date
Mapped to SubmissionSet.submissionTime? XDS and MHD allow for different date formats. ⚠️ Technically not the same date (creation vs. submission).
Yes mapping from date is submissionTime, see map.
VOL3 says: Represents the point in time at the creating entity when the SubmissionSet was created. I think that matches to List.data, otherwise please raise an issue against IHE MHD for clarification: https://profiles.ihe.net/ITI/MHD/4.0.2/StructureDefinition-IHE.MHD.Minimal.SubmissionSet.html
source and ch-ext-author-authorrole
Complex mapping. Must support, so an important mapping?
The ch-epr requires SubmissionSet Author. The MHD or this ig has no explicit mapping yet defined.
Missing Assistant and Technical user.
Assistant and Technical User may be provided with SubmissionSet.Author.AuthorRole
⚠️ What to do if authorRole is e.g. HCP but source is Reference(CH Core Patient Profile)?
The SubmissionSet.Author element MAY be used to track the user who made the latest changes to the document metadata. If present, the value of the AuthorRole attribute SHALL be taken from the Submis- sionSet.Author.AuthorRole value .... This would mean that authRole e.g. HCP and author the patient would be not valid.
⚠️ Bad reference types (not the CH Core types). Also for ihe-authorOrg.
ihe-authorOrg: SubmissionSet.author when the author is an Organization: this is not applicable for th swiss epr will constrain it out, thanks!
text
Mapped to SubmissionSet.comments. Raw text in XDS, XHTML in FHIR. ⚠️ If XHTML text is given in MHD, it will be stripped in the mapping. ⚠️ Narrative.status is mandatory in FHIR, absent from XDS.
Submission.comments (and title) are optional and not specified in the ch epr.
oliveregger
commented
2 years ago @qligier thanks for the thorough feedback, such feedback helps to improve the specification!
A few comments are geared towards general IHE MHD XDS mapping, it would be very helpful if you can also provide your feedback also directly there in the future: https://profiles.ihe.net/ITI/MHD/index.html . There seems to be some uptake lately with comments coming in IHE MHD and we in the IHE ITI committee are trying to incorporate the feedback.
I will close the issue as ballot feedback is over, but if you think we need to rediscuss some of the issues just enter a new issue! Thanks again for your feedback.
qligier
commented
2 years ago Thank you Oliver! I'll check that again during 2022.
I've completed a review of the following profiles focused on the MHD-XDS conversion:
I've found multiple issues that prevent converting between MHD and XDS resources. Other conversion issues may or may not be in scope of the CH-EPR-mHealth IGs. Cardinalities are reviewed at the bottom of both guides and incompatibilities are highlighted.
Some elements are marked as "Must support", should we make sure these are mapped when implementing a converter? My plan was to firstly focus on required elements only, but some optional elements are marked as "Must support", so that would change my implementation scope.
Also, the new IHE mapping for DocumentManifest-SubmissionSet is an ugly mess that is not even consistent with DocumentReference-DocumentEntry 🙃