Stream: implementers
Topic: Binary reference in Composition resource
Florian Kelnerowski (Dec 11 2017 at 14:15):
Hello,
I would like to implement a BInary reference into a Composition resource but I don't know where is the better place.
I thought about the "subject" field, but I need it for "Patient".
The easiest option would be to put the Binary reference into an extension but I'm not sure that's quite right.
Thanks
John Moehrke (Dec 11 2017 at 14:19):
what is in your Binary? What purpose does it have? What do you think the recipient is going to do with it?
Florian Kelnerowski (Dec 11 2017 at 15:10):
My Binary will contain the PDF itself, in base-64, nothing more.
The goal of the Composition is to reference the Binary but also to contain some "metadata" of this Binary.
John Moehrke (Dec 11 2017 at 15:24):
Then seems your Binary would be in the Composition.section.entry... I might suggest that your Binary first be pointed to by a DocumentReference or Media; and that is what is pointed to by Composition.section.entry.
John Moehrke (Dec 11 2017 at 15:24):
Why not just use a DocumentReference? Why do you want to have a Composition?
Florian Kelnerowski (Dec 12 2017 at 10:21):
Thanks for your answers.
So, you think it should look like this : Binary into DocumentReference into Composition ?
Actually I found that Composition would be good to contains the metadatas, thats the only answer. But it seems like DocumentReference would do the work too.
The goal of the project is to get a list of the PDF documents of a patient.
My actual solution is to get a list of Composition (through an automatic Bundle) which will each contain the metadatas of the document (+ references to Encounter, Location,Period...) and the reference to the Binary.
If I use DocumentReference, the Binary reference would be in : content -> attachment -> url ?
John Moehrke (Dec 12 2017 at 13:56):
SO you clarified why just DocumentReferene->Binary is not sufficient. This would be sufficient if you were just looking for a way to discover the PDF files. This is common "Document Sharing" solution, originally based in IHE-XDS, now available in FHIR. Profiled in IHE using the MHD profile.
John Moehrke (Dec 12 2017 at 13:59):
There is an additional profile from IHE - mXDE, which shows interaction between a Document Sharing environment and an API that makes more fine-grain data (FHIR Resources) available http://wiki.ihe.net/index.php/Mobile_Cross-Enterprise_Document_Data_Element_Extraction; using the IHE QEDm profile (very similar to USA specific argonaut) http://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile. These are all international standards from IHE.
John Moehrke (Dec 12 2017 at 14:02):
You seem focused on using Composition, but it is not clear to me that you are actually creating a true Document http://build.fhir.org/documents.html It seems more that you are just needing a Operation that returns a Bundle. That bundle could contain the Encounter, Location, Patient, Provider, DocumentReference, and Binary) resources as necessary. The structure of Composition might not be adding value.
John Moehrke (Dec 12 2017 at 14:03):
That said, there is no problem with having a Composition carrying all of those resources including carrying the DocumetReference that points at (and describes) the Binary(PDF). Each of these resources would be different section elements.
John Moehrke (Dec 12 2017 at 14:05):
I am also hearing some are using DocumentReference to point at not just documents, but also other resources like Encounter, Location, etc.. That is that the DocumentReference is their primary API, and it can point at ANY FHIR resource in addition to content agnostic Documents.
Eric Haas (Dec 12 2017 at 16:56):
'I am also hearing some are using DocumentReference to point at not just documents, but also other resources like Encounter, Location, etc.. That is that the DocumentReference is their primary API, and it can point at ANY FHIR resource in addition to content agnostic Documents.' seems indirect way of doing this - but ok
Last updated: Apr 12 2022 at 19:14 UTC
