Stream: implementers
Topic: Composition vs Bundle Approach to Structured Documents
John Meredith (Jun 25 2018 at 08:07):
I am conducting an excercise trying to take a farily large blob of XML into a FHIR compliant format. The clinical context is of an outpatient appointment containing both history and new observations in support of a diabetes consultation. The source XML is presently aorund 3500 lines.
The first thing is that this document or consultation can happen over a short period of time and by mulitple authors. Depending on where you draw the line of the "composition" it could either be a bundle of documents, each of which has the context of the date, location, coded clinical context plus a series of observations, or alternativly one large all encompassing structure.
The important point is that the blob is designed to self contained with not external references. We do not have yet have a fully operation FHIR server (and are building to that), but in the short term can we develop standardised approach to our documents that paves the way for meaningful reuse in the future. And that's where the use of the com[position resource bothers me as it (as i understand it) is not supposed to be self contained snapshot. I think I am describing the output of a compostion resource operation.
Thoughts welcomed...
Stefan Lang (Jun 25 2018 at 08:32):
Composition and Bundle (of type "document") go hand in hand.
If you need that XML document represented in a similar (especially: explicitely self contained) way in FHIR, use a Bundle of type "document". The first resource within that Bundle has to be a Composition that lists all other resources contained in there. See https://www.hl7.org/fhir/documents.html .
Pro: you have "everything in one place"
Con: you don't have the separate resources available, so you can't easily search and (re-)use them as possibly required
If you don't really need that Bundle stored "as-is" (for legal reasons or such), you would store every resource seperately. You still can have a Composition resource that keeps them together. And you can even generate a Bundle on the fly from that Composition using the $document operation. See http://build.fhir.org/composition-operation-document.html
Pro: you have all the data of the original XML document ready for search and (re-)use. And you still can generate a Bundle of type document.
Con: that document Bundle is generated dynamically, so it does not exist on the server "as-is" (would you need that in your use case?)
I would go with the second variant whereever possible, but it of course depends on the use case.
Of course you can mix up both variants within the business logic of your server, so the two options are not necessarily mutual exclusive. But that would basically add complexity.
Grahame Grieve (Jun 25 2018 at 10:27):
it's perfectly valid and reasonable to use composition outside document
John Meredith (Jun 25 2018 at 12:07):
Excellent - thanks for the feedback @Stefan Lang . The first option seems like the right fit for us right now in order to future proof us. And hi @Grahame Grieve - I need to write to you regarding my research - I'm moving forward with it and your points on ontologies informed it a fair bit.
Last updated: Apr 12 2022 at 19:14 UTC
