-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow DocumentReference.context.encounter #88
Comments
I think that the .encounter could easily map to DocumentEntry.referenceIdList. The complexity that there are two FHIR elements that map to the one XDS element can be overcome. The use of referenceIdList does include carrying identifiers like encounter. So this is well within the intended use of the element. MHD Document Consumer should always expect that any of the FHIR elements might be populated, so the current specification does not forbid returning it to a MHD Document Consumer. |
committee discussion: |
added a section to ITI-67 explaining populating Resource References -- 3.67.4.2.2.1.5 removed the 0..0 on encounter added a map for encounter to referenceIdList |
@JohnMoehrke with ReferenceIdList, use the CX type for encounter to enable putting ReferenceIdList that are encounter types into the DocumentReference.encounter.identifier. Table 4.2.3.1.7-2 - urn:ihe:iti:xds:2015:encounterId |
pull request #135 closed |
We have the situation that in an internal document exchange scenario between systems within a hospital (at least in Germany), the encounter context is pretty important both for querying as well as during the document provide interaction. So if we were do define profiles for this scenario we'd be incompatible with MHD due to the 0..0 restriction on DocumentReference.context.encounter.
I understand that encounter context is not relevant/needed in MHD/XDS context, but I would assume that in most internal scenarios, e.g. where FHIR replaces HL7 V2 MDM communication, the provision of encounter information will be mandatory.
The question this raises is: should these internally used DocumentReferences be reuseable - as is - for MHD or do vendors in fact need to actively remove the encounter reference?
Is the fact that the information would be dropped when mapping to XDS enough reason to completely rule out the element? In my interpretation of cardinalities, I would assume that the encounter reference should simply lack the mustSupport flag to indicate that it won't be processed within the MDH scope.
We are currently specifying such an internal document exchange and aim to harmonize with MHD as much as possible. However with the encounter reference we'd be forced to break compatibility.
see Zulip discussion here: https://chat.fhir.org/#narrow/stream/179223-ihe/topic/MHD.20DocumentReference.2Econtext.2Eencounter.20forbidden
The text was updated successfully, but these errors were encountered: