Stream: implementers
Topic: Bundle inside Bundle vs DocumentReference
Maria Hu (Jun 18 2021 at 21:31):
When doing a POST of a document to Azure Cosmos db, I can either Bundle a 'sub-Bundle with resources' or I can embed a 'Bundle with multiple resources' inside DocumentReference.content.attachment.data . Wondering if one way more proper than the other from FHIR standard perspective? Please advise, thanks.
Lloyd McKenzie (Jun 27 2021 at 01:52):
Can you explain more about what you're doing? Why would posting a document have sub-Bundles at all?
Kevin Mayfield (Jun 27 2021 at 05:34):
Are you using FHIR Documents (a Bundle of type = document) or a normal document?
and in either case you will have a DocumentReference for the document metadata.
John Moehrke (Jun 27 2021 at 16:03):
There has been some discussion about this in the IHE space around the MHD and MHDS implementation guides. The attachment.data (or in the case of MHD the attachment.url points at) an object that is described with the mime-type in attachment.contentType. If that contentType is a FHIR type, then the contents pointed to can be seen as a FHIR Resource type. For attachment.url situations this is often a Binary that holds the content. Either way the concept that the attachment has a mime-type and a content enables the source to use a FHIR Document Bundle, or a FHIR Binary with anything.
So far, MHD/MHDS has been silent on this FHIR Document Bundle use, because it is unclear how that affects persistence as bits (which is important to MHD/MHDS)
A Binary will have a deterministic hash and size... a FHIR Document Bundle might start out with the one and morph as translations and re-encodings happen.
So, needing Trial Implementation experience to uncover the concerns and advantages.... they are not all clear right now.
Kevin Mayfield (Jun 28 2021 at 05:07):
I've been looking at how to merge a variety of document exchanges and I'm leaning towards IHE MHD and the use of FHIR Document as an alternative to a FHIR Binary.
https://simplifier.net/guide/NHSDigital/document
John Moehrke (Jun 28 2021 at 12:04):
I think that should work... and I would like to hear how well it does. I have an open issue in MHD looking for experience on this. Please keep me informed on how well it goes.
Maria Hu (Jun 29 2021 at 00:13):
John Moehrke said:
I think that should work... and I would like to hear how well it does. I have an open issue in MHD looking for experience on this. Please keep me informed on how well it goes.
Thanks John.
I tried two different options as follow, wondering which option is best practice:
Option 1:
Bundle (Master)
Entry
Bundle (Sub)
Entry
MessageHeader
Patient
Practitioner
Organization
ServiceRequest1
Servicerequest2
Option 2:
Bundle
Entry
MessageHeader
DocumentReference
Content.attachment.data (encode Patient/Practitioner/Organization/ServiceRequest1/ServiceRequest2)
Brendan Keeler (Jul 01 2021 at 01:55):
Vassil Peytchev (Jul 01 2021 at 14:29):
Option one doesn't make sense... Are you looking for a FHIR message containing a document?
David Pyke (Jul 01 2021 at 14:32):
I think we better need to understand your use case and workflow so that the options have more context
Simone Heckmann (Sep 23 2021 at 17:15):
I'm currently working on an document exchange specification that aims to align with MHD. But more often than not, the content will be a FHIR document bundle.
I was thinking thet the "provide document" transaction could be a transaction bundle where the DocumentReference.content.attachement.url resolves within the Bundle to another entry containing the document Bundle. So you get another Bundle instead of a Binary (currently not allowed in MHD).
However, this seems to be quite a redundant approach, because Patient, Practitioner(Author), Organization (Custodian) etc. would be both in the outer and in the inner bundle. I suppose this is by design in order to keep metadata separate from content, but it still feels a bit weird.
Any thoughts on this?
John Moehrke (Sep 23 2021 at 17:33):
Your point about redundancy due to the nested nature.. YES. But the Bundle of type Document requires they be in there. And the FHIR-Document rules are good and appropriate. I am not clear on why this replication is all that troubling. it is just bits
Simone Heckmann (Sep 23 2021 at 17:45):
true :big_smile:
Simone Heckmann (Sep 23 2021 at 17:57):
But it is correct that MHD doesn't allow this currently. The only compliant way would be to Base64 encode the document Bundle an put it in a Binary, right?
John Moehrke (Sep 23 2021 at 18:09):
correct... until we work together to improve the spec...
Simone Heckmann (Sep 23 2021 at 18:35):
@John Moehrke you mentioned earlier that you had an open issue for this? Could you share a link, I'd be happy to update it in case we go along with the above mentioned pattern and have collected some experience.
John Moehrke (Sep 23 2021 at 18:40):
https://github.com/IHE/ITI.MHD/issues/91
John Moehrke (Sep 23 2021 at 18:59):
Note that there is a set of open issues asserted in the specification.
https://profiles.ihe.net/ITI/MHD/a_issues.html
Simone Heckmann (Sep 23 2021 at 21:22):
I added a comment to the issue. We're only at the beginning of defining our use cases, so I might add more in the future...
John Moehrke (Sep 24 2021 at 12:40):
thanks. Note that the consumer side is not burdened by the Binary constraint. A server is free to follow the http negotiate to determine that the consumer would prefer FHIR mime-type, and thus return the Document Bundle. Not clear how many servers will do this, but it is mentioned in MHD and does leverage the explanation in Binary resource. Im not saying it is obvious or clear, but possible.
Michele Mottini (Sep 24 2021 at 12:53):
A server is free to follow the http negotiate to determine that the consumer would prefer FHIR mime-type, and thus return the Document Bundle
Mhh, no: 'When a read request is made with a FHIR type in the Accept header (e.g. "application/fhir+xml" or "application/fhir+json") the Binary resource is returned in the requested FHIR format. This applies even when the binary data itself has a FHIR mime type' (from http://hl7.org/fhir/binary.html#rest)
John Moehrke (Sep 24 2021 at 13:22):
odd that FHIR explicitly enables easier Binary for all other mime types, and makes fhir mime type harder...
John Moehrke (Sep 24 2021 at 13:23):
well, more reason to get MHD (and thus the attachment datatype, url element) to better handle FHIR Documents.
Simone Heckmann (Sep 30 2021 at 16:36):
I don't understand why a FHIR server would persist FHIR data as Binary...? I mean, even if it's necessary to Base64 encode the document Bundle for the transaction, I would expect the server to decode it when processing hte transaction and simply store the Bundle. Why would it want to maintain the encoding...?
Lloyd McKenzie (Sep 30 2021 at 17:12):
The issue is that if the instance contains elements (e.g. extensions) the system doesn't know how to persist and would normally throw away, then you'd break the signature. Also, some systems may introduce elements (e.g. code translations, alternate display values, etc.) when re-serializing. By storing a binary copy, you hold onto everything and maintain signature validity even if you then also store the resource normally in a way that modifies the content.
John Moehrke (Sep 30 2021 at 19:30):
I am expecting that a server would store the Binary as a binary, but I am not presuming that the server would be forbidden from returning the result to a client that asks for a specific mime-type encoding that the server can fulfill.
Last updated: Apr 12 2022 at 19:14 UTC
