Stream: ihe
Topic: MHDS out for public comment
John Moehrke (Jan 22 2020 at 02:29):
Out for public comment is a Document Sharing implementation guide by IHE based around FHIR - https://healthcaresecprivacy.blogspot.com/2020/01/mobile-health-document-sharing-mhds.html
John Moehrke (Jan 23 2020 at 11:54):
I am interested in discussion of three potential changes to the FHIR model supporting MHD. These questions are being driven by two factors ( a ) the desire to move the MHD resources to Normative, and ( b ) the MHDS profile that is not backed by XDS and thus needs to be more friendly to a basic FHIR server.
1) Switch to List away from DocumentManifest. (Been some discussion here already see the DocumentManifest vs List stream)
2) Change in DocumentReference model from DocumentReference.masterIdentifier moving this function into DocumentReference.content.identifier (moving the element and renaming it)
3) No longer requiring the server to populate DocumentReference.identifier. Possibly recommending that where XDS metadata DocumentEntry.entryUUID is being mapped, that it be mapped into DocumentReference.id. We can stick with DocumentReference.identifier and just mention that entryUUID only gets added with XDS-on-FHIR?
Grahame Grieve (Jan 24 2020 at 06:26):
+1 to all 3, I think
John Moehrke (Jan 24 2020 at 13:39):
@Grahame Grieve including putting the xds entryUUID into the DocumentReference.id? It seems logical to me?
René Spronk (Jan 24 2020 at 15:28):
I don't see any other option, it's the functional equivalent of an id. Binary.id (if a /Binary is referenced from the attachment) would be the [document]uniqueId.
Keith Boone (Feb 01 2020 at 21:48):
I think I agree with all of this.
John Moehrke (Feb 03 2020 at 00:30):
I don't see any other option, it's the functional equivalent of an id. Binary.id (if a /Binary is referenced from the attachment) would be the [document]uniqueId.
not the same thing. entryUUID is the unique identifier of the DocumentEntry (DocumentReference). This is different from the document uniqueID, which is today saved in DocumentReference.masterIdentifier, which is somewhat related to Binary/id but does not need to be that.
I am proposing two very different things:
a ) DocumentReference.masterIdentifier be moved into DocumentReference.content.identifier -- holding the document unique identifier, that is XDS - DocumentEntry.uniqueId
b ) DocumentReference.identifier does NOT need to be XDS DocumentEntry.entryUUID -- That rather the entryUUID would be represented in DocumentReference.id when it is needing to be mapped... which it does not need to be mapped in a system that has a non XDS based persistance, and thus not needing to be mapped in MHDS where there is no XDS but rather just a FHIR Server.
René Spronk (Feb 03 2020 at 07:31):
My point is: if one uses XDS in FHIR, then the requirement should be that Binary.id SHALL be populated with documentUniqueId. In that context there is no alternative.
John Moehrke (Feb 03 2020 at 23:38):
I created #FHIR-25773 to move the masterIdentifier into .content.identifier
John Moehrke (Feb 03 2020 at 23:41):
My point is: if one uses XDS in FHIR, then the requirement should be that Binary.id SHALL be populated with documentUniqueId. In that context there is no alternative.
that is beyond the questions I currently am asking. I think your point is a useful 'best practice', but I don't know that it is something that should be mandated.
Grahame Grieve (Feb 04 2020 at 03:33):
so it turns out I was wrong at lunch time when I said that the IHE template would still work.
Grahame Grieve (Feb 04 2020 at 03:33):
am I ok to set up publishing the IHE template through fhir.org?
John Moehrke (Feb 04 2020 at 03:57):
Discussion at US-Realm that there is a desire for US-Core to not constrain DocumentReference.content to 1..1. This requirement in US-Core was added because it is a requirement in MHD, because it is a requirement in XDS... Multiple pages are expected to be multiple DocumentReference with a .relatesTo. However there is interest for multi-page-scanned paper to be represented as multiple .content elements...
MIGHT this be acceptable as a deviation in MHDS, while still being constrained in MHD? Is this a need to create a new type of DocumentReference??????
Grahame Grieve (Feb 04 2020 at 04:01):
I'd rather have a single DocumentReference for a multi-page scan, that's for sure
John Moehrke (Feb 04 2020 at 04:02):
understood, and that is why it rightly is so in FHIR core.
John Moehrke (Feb 04 2020 at 04:02):
the question is far more political.. how well can we all play nice without causing breaking changes or hard-to-implement bridging technology
Grahame Grieve (Feb 04 2020 at 04:04):
well, what does MHD say about multipage scans?
John Moehrke (Feb 04 2020 at 04:05):
MHDS is fully FHIR registry centered, so doesn't have an XDS problem... The XDS (XCA) problem comes when the multi-page DocumentReference is queried/retrieved by way of XDS/XCA
John Moehrke (Feb 04 2020 at 04:06):
MHD/XDS/XCA would have you create multiple DocumentReference with the multiples linked with relatesTo element
Grahame Grieve (Feb 04 2020 at 04:07):
pfft
John Moehrke (Feb 04 2020 at 04:07):
There are paper processing houses in XDS/XCA that do this (or append the pages into one PDF). -- Including those that have response-time in the many days timeframe
John Moehrke (Feb 04 2020 at 04:08):
These single page sources will work in FHIR DocumentReference... so the only breaking condition is where FHIR DocumentReference with multiple pages needs to be retrieved thru an XCA interface.. that solution could just use the multiple DocumentEntry approach. Ugly, but functional.
Last updated: Apr 12 2022 at 19:14 UTC
