Allow DocumentReference.context.encounter

[simoneOnFhir]

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

[JohnMoehrke]

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.

[JohnMoehrke]

committee discussion:
likely good element for MHDS backends.
With XDS a conversion from MHD to XDS can put the id into referenceIdList;
Data coming from XDS referenceIdList would not be expected (but not forbidden) from being translated into .encounter.

[JohnMoehrke]

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]

@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

[JohnMoehrke]

http://build.fhir.org/ig/IHE/ITI.MHD/branches/allow-encounter/index.html

[JohnMoehrke]

pull request #135 closed