Stream: implementers
Topic: Documents
Jeremy Chapman (Sep 03 2019 at 16:32):
I want to send a message with DocumentReferences and then build services that the client can call to retrieve the actual documents. I would have services to retrieve CDA documents as well as other binary documents. I'm looking for the most efficient way to implement the services. The binary resource uses base64 in the resource which is not cool. Is it compliant to simply return the raw binary with the appropriate mime type or is there a better way? What if I want to return meta data about the document, but also return the raw binary content as well, how would one go about doing that?
Patrick Werner (Sep 03 2019 at 16:37):
this is described here: https://www.hl7.org/fhir/binary.html#rest
Patrick Werner (Sep 03 2019 at 16:38):
So if you have a GET request with a non-fhir mime type as accept, it is fine to directly return the binary
John Moehrke (Sep 03 2019 at 16:45):
You should also look to the IHE Implementation Guide on this topic -- MHD.
Note when you GET a binary the http negotiate is used to enable retrieval of formats other than FHIR wrapped (base64 encoded). Thus if you include in your GET on the binary that you prefer cda format, the server is free to provide it in that format (aka without the FHIR Binary wrapping and thus the base64 encoding).
BUT if you insist on using FHIR then it must be wrapped in a FHIR friendly Resource, ie the Binary Resource.
Jeremy Chapman (Sep 03 2019 at 16:46):
So in that approach would you have a separate service to get the raw contents, and one to return meta data about the document?
Patrick Werner (Sep 03 2019 at 16:52):
the meta about a CDA document would be a DocumentReference Resource pointing to the CDA doc
John Moehrke (Sep 03 2019 at 16:54):
Right the metadata is the DocumentReference resource.... It is possible that the Binary is held on a different server. This is why the DocumentReference.content.attachment.url is a "url"... thus allowing the Binary to be anywhere.
John Moehrke (Sep 03 2019 at 16:56):
now, in the case of publishing... often a publishing workflow (and true in MHD) the publishing is a Transaction that includes both the DocumentReference and the Binary such that the receiving service is expected to persist them. In this case it is common for the Binary and the DocumentReference to be maintained on the same server. This arrangement is not manditory, just a common setting for publication using a FHIR transaction.
John Moehrke (Sep 03 2019 at 16:58):
https://healthcaresecprivacy.blogspot.com/2015/03/what-is-mhd-beyond-xds-on-fhir.html
Ben Grey (Sep 03 2019 at 17:45):
@John Moehrke @Patrick Werner If I wanted to include say a pdf document within a FHIR Doc bundle, should I use DocumentReference.content.attachment.data to include the pdf or should we be storing the pdf within the binary resource and referencing it from DocumentReference? The pdf would be generated by us and would not need to be referenced to another server.
John Moehrke (Sep 03 2019 at 17:52):
There is no singular answer. The attachment.data is there for those that want to embed the data within the attachment. But the attachment.url is there for those that want to use the power of a URL... I prefer the URL method for the above stated reasons of being able to use the http negotiate methods to retrieve the PDF in native format, not forcing the recipient to un-base64.
Last updated: Apr 12 2022 at 19:14 UTC
