Stream: implementers
Topic: Use of contained resources in mHD
Theo Stolker (Feb 07 2018 at 17:59):
Hi all,
I did implement an MHD client and found out that it promotes the use of contained resources, see https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf, section 4.5.1 Metadata Object Types mapped to FHIR
...
Some Document Sharing Metadata attributes must be treated as ‘contained’ FHIR Resources.
These are indicated using “Note 1”, and use of the word ‘contained’ in the Notes column of
Table 4.5.1.1-1. The details of the FHIR ‘contained’ mechanism is found at
http://hl7.org/fhir/STU3/references.html#contained.
Reading https://www.hl7.org/fhir/domainresource-definitions.html#DomainResource.contained I find the description above controversial at least.
Also, given that the FHIR specification provides clear alternatives through the search include mechanism in a reply Bundle, I am wondering if this was discussed before and couldnt be done in a more acceptable way.
Is there anyone involved in the creation or review of the MHD profile that can comment on this?
Thank you,
Theo.
Lloyd McKenzie (Feb 07 2018 at 18:04):
@John Moehrke ?
Elliot Silver (Feb 07 2018 at 18:05):
@Theo Stolker , most of us involved in MHD hang out on the #ihe stream.
However, the logic for use of contained resources is the need to provide a proxy for an XDS registry/repository. XDS metadata essentially has "contained" source patient, author, and institution content, and requiring creation of FHIR resources for this would complicate the proxy process. Further, the "contained" content is meant to be a snapshot in time (here's how we knew the patient when the document was published). Since FHIR doesn't have to support versioning, there is no other way to say here's the current patient info, and here's the old.
John Moehrke (Feb 07 2018 at 18:53):
Elliot already covered the ground... Any Implementation Guide (aka IHE Profile) examines a use-case and provides constraints to meet that profile, and through those constraints avoid problems with interoperability. In the case of MHD, which is an API to a Document Sharing system, there is a use-case need to capture the values of the Patient Identity (demographics), and authors in a way that preserves what they were know as at publication, and thus what the Document content would be using to express these. Where as the main patient ID does point at a managed Patient resource, so that patient identity and demographics would float to current knowledge at all time. Thus overtime the DocumentReference has linkages to current and past, and that past linkage explains the content of the document. This is expressly important when dealing with documents from history. It is not very helpful with non-historic documents. The MHD Document Sharing space is focused on Healthcare Information Exchange longitudinally, so history is important.
Grahame Grieve (Feb 07 2018 at 20:42):
so it makes sense why constrained resources are allowed, but I read that they are required?
Theo Stolker (Feb 08 2018 at 08:24):
Thanks, @Elliot Silver , @John Moehrke !
It might be useful to extend the documentation of https://www.hl7.org/fhir/domainresource-definitions.html#DomainResource.contained I to include the use cases intended to be covered here.
At the same time I do not see why historical patient information is needed, or why this couldn't have been solved by passing the Patient Resource with the DocumentReference in a Bundle.
Anyhow, I really do appreciate the hard work on the m-profiles.
Thanks
John Moehrke (Feb 08 2018 at 14:27):
Grahame, MHD use-case analysis comes to the conclusion that sourcePatientInfo needed to be contained to assure that it would NOT change over time. Using contained assured this. So I would agree that containment in general should not be manditory, but when a use-case requires it, then it should.
John Moehrke (Feb 08 2018 at 14:27):
There is a non contained Patient, it is the current Patient resource. One does NOT need to fill in the sourcePatientInfo... and it would seem really odd to have both sourcePatientInfo and Patient pointing at the same thing.
John Moehrke (Feb 08 2018 at 14:28):
so, ultimately there is a choice.. you can fill in sourcePatientInfo, or choose not to fill it out.... one always must point at an actively managed Patient
Elliot Silver (Feb 08 2018 at 17:48):
@Theo Stolker, there is no reason that the FHIR documentation provided by HL7 should reference the MHD use case defined by IHE. There are many other implementation guides out there that FHIR ignores documentation; bringing them into the FHIR spec would cause it to be unweildly, subject to continual revision, and force HL7 to choose which IGs it wants to bless, and which to ignore. If the FHIR documentation is generally insufficient though, feel free to submit a change request (bottom of every page of the spec); if the MHD documentation is insufficient, please let IHE know, and we can look at improving.
The historical patient information is needed because MHD is designed to be able to proxy between a FHIR server and an XDS environment. The XDS environment stores the historical patient data, so we need to be able to convey that in MHD. Whether XDS should convey that or not is a separate discussion, but MHD was written to meet that use case, and so the historical information is needed.
John Moehrke (Feb 08 2018 at 18:08):
The additional reason for the contained Patient for sourcePatientInfo is driven by the use-case for Cross-Enterprise and Cross-Community - Document Exchange. Where the contained Patient within the DocumentReference enables the thousands of document source systems to preserve their Patient description, independent of any centralized or federated Patient identity management system. Often there are thousands of organizations participating in a nationwide network, there is no way to create a unified Patient directory that maintains all versions of all Patients as known by those thousands of organizations. This contained mechanism overcomes this problem.
John Moehrke (Feb 08 2018 at 18:10):
I have a blog article from June 2016 that I think is still useful https://healthcaresecprivacy.blogspot.com/2016/06/mhd-why-use-of-fhir-contained.html
Last updated: Apr 12 2022 at 19:14 UTC
