FHIR Chat · MHD DocumentReference.context.encounter forbidden · ihe

Stream: ihe

Topic: MHD DocumentReference.context.encounter forbidden


view this post on Zulip Simone Heckmann (Sep 14 2021 at 09:27):

Can anyone tell me more about the rationale of constraining DocumentReference.context.encounter in MHD to 0..0 ?
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 this restriction.

view this post on Zulip John Moehrke (Sep 14 2021 at 13:04):

it is defined this way because there is not place for that data in the Document Sharing metadata model. So although it would work in an MHDS environment, it would not work where XDS or XCA or XDR or XDM are used somewhere in the path.

view this post on Zulip John Moehrke (Sep 14 2021 at 13:07):

at one point we were thinking of using the Document Sharing metadata element ReferenceIdList, however current model just has .related mapped to this.

view this post on Zulip John Moehrke (Sep 14 2021 at 13:08):

I think it would be useful to have you explain the use-case in an issue that could drive change.

view this post on Zulip Simone Heckmann (Sep 14 2021 at 15:15):

I understand that it's 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.

view this post on Zulip John Moehrke (Sep 14 2021 at 15:18):

yes, that is exactly what I would like to see explained in a github issue on MHD. https://github.com/IHE/ITI.MHD/issues
Let me know what your github id is so that I can add you to the team.

view this post on Zulip John Moehrke (Sep 14 2021 at 15:21):

note that I do have many mentions in the specification that recipients should be robust to all elements. Thus recipients should not have a problem with an .encounter; they might not know what to do with it, but they should not be throwing an error.

view this post on Zulip John Moehrke (Sep 14 2021 at 15:21):

I do wish there was a "not recommended" equivalent negative flag to "must support". I did enter a FHIR CR asking for that. This would be a flag used to discourage without forbidding, like 0..0 does.

view this post on Zulip John Moehrke (Sep 14 2021 at 15:22):

that said.. I think a use-case could justify that both .encounter and .related could be mapped into DocumentEntry.referenceIdList... leaving XDS->FHIR mapping up to creative implementations to figure out which identifiers are which kind.

view this post on Zulip John Moehrke (Sep 14 2021 at 15:23):

hence, why I want an issue to drive IHE discussino.

view this post on Zulip Simone Heckmann (Sep 14 2021 at 15:30):

This is me on GitHub: https://github.com/simoneOnFhir

view this post on Zulip Simone Heckmann (Sep 14 2021 at 15:31):

I'll file the issue as soon as I have access

view this post on Zulip Vassil Peytchev (Sep 14 2021 at 17:02):

it is defined this way because there is not place for that data in the Document Sharing metadata model.

Doesn't ReferenceIdList provide this in the metadata?

view this post on Zulip John Moehrke (Sep 14 2021 at 17:16):

Vassil, yes it could be that way. it was mostly an oversite due to no one mentioning it.

view this post on Zulip Simone Heckmann (Sep 15 2021 at 12:40):

Issue added: https://github.com/IHE/ITI.MHD/issues/88

view this post on Zulip Simone Heckmann (Sep 15 2021 at 12:43):

tbh the way the IG publisher renders the profile, it's very hard to actually see the constraint, unless you're explicitly looking for the context.encounter element and wondering where it went.
Simplifier would render that as a striked (stoke? strikken?) out element, making this more obvious.
I only noticed it, when I looked at the FSH code :nerd:

view this post on Zulip John Moehrke (Sep 15 2021 at 17:02):

agreed. I am liking the FSH format for being blunt.

view this post on Zulip John Moehrke (Sep 15 2021 at 17:03):

thanks for creating these issues.

view this post on Zulip Grahame Grieve (Sep 17 2021 at 03:44):

what's hard to see?

view this post on Zulip Simone Heckmann (Sep 17 2021 at 07:10):

DocumentReference.context.encounter beeing set to 0..0
The element is simply missing from the differential, so you can't see the constraint.

view this post on Zulip Grahame Grieve (Sep 17 2021 at 07:12):

where is it missing from the differential? it certainly shouldn't be

view this post on Zulip Simone Heckmann (Sep 17 2021 at 07:12):

Ah sorry, it is struck out in the differential. It's the snapshot where you can't see it.

view this post on Zulip Grahame Grieve (Sep 17 2021 at 07:13):

ahh ok. well, you can take that up on #ig publishing requirements but that's been debated before


Last updated: Apr 12 2022 at 19:14 UTC