Stream: implementers
Topic: DocumentReference and FHIR Document
Raphael Scheible (Oct 20 2021 at 15:04):
Hi. We just thought about mapping several documents to FHIR resources. We found two possible ways: Document according to https://www.hl7.org/fhir/documents.html or to use a DocumentReference. We plan to do NLP with these
documents and hence, we will derive Observations from them. Unfortunately, derivedFrom in Oberservations can only be linked to DocumentReference which cannot contain a FHIR Document as reference. We wonder if there is a different way to model that?
Michele Mottini (Oct 20 2021 at 15:14):
DocumentReference contains (or reference - depending on the point of view) arbitrary binary data, so it can contain anything - including a FHIR Document
Raphael Scheible (Oct 20 2021 at 16:00):
Michele Mottini said:
DocumentReference contains (or reference - depending on the point of view) arbitrary binary data, so it can contain anything - including a FHIR Document
Do you mean to pack a FHIR Document JSON into a base64 and into the DocumentReference? If so, I think this would not really unleash the power and benefit of FHIR, as the Document endoints for the specific Document instance would not be existent.
Michele Mottini (Oct 20 2021 at 16:08):
Yes, that's what I mean. There is no Document end point (?)
Raphael Scheible (Oct 20 2021 at 16:11):
Oh yes, I meant these endpoints: https://www.hl7.org/fhir/documents.html#bundle
Yunwei Wang (Oct 20 2021 at 16:37):
You can use DocumentReference.content.attachment.url to point to your FHIR document Bundle.
But I don't quite understand your process.
mapping several documents to FHIR resources
Does that mean you already have the documents but just not in FHIR format? If so, you can attach the document to DocumentReference directly.
Raphael Scheible (Oct 20 2021 at 16:42):
The documents are text blobs. They can have headings and subheadings, which I did not see to model solely with a DocumentReference. Thus, I was looking for the FHIR Document, which as far as I understood, can model such a nested structure. I understood the DocumentReference in such a way, that the url is intended to point directly to the content rather than a content structure. To me such a method would feel a bit hacky. We miss the possibility to reference a FHIR Document within a DocumentReference as provided in other FHIR structures. Also, given the name DocumentReference, one could expect exactly that capability ;)
John Moehrke (Oct 20 2021 at 20:56):
as @Yunwei Wang mentioned
DocumentReference.content.attachment.url --> Composition
Corey Spears (Oct 21 2021 at 02:23):
You could have:
DocumentReference.content.attachment.url --> Composition (as mentioned above. If a server supports it, you could use $document operation to gather the document)
DocumentReference.content.attachment.url --> Bundle[type=document] (That contains all of the resource you want in it with the Composition resource first)
DocumentReference.content.attachment.url --> Binary (with encoded data being any number of formats including a Bundle[type=document]
DocumentReference.content.attachment.data (encoded with a Bundle[type=document] or anything else you would want to include
There are other potential options, but if you are talking about native FHIR documents, these are the ones that stick out to me.
Last updated: Apr 12 2022 at 19:14 UTC
