Stream: implementers
Topic: The order of resources in a bundle
Tim Berezny (Mar 09 2018 at 15:49):
I am wonder to what degree the order of resources in a bundle has impact or can have meaning. I have come across two scenarios where this question has come up. (For context, i am trying to POST a bundle with a /ServiceRequest as the primary resource in addition to all of the resources it references, such as /Patient, /Practitioner, etc.)
1) I was once told that the resource in the bundle should be included in such an order that references resources appear first, and parent resources appear last. For example, /Practitioner and /Patient are references from /ServiceRequest, so they would come in the bundle ABOVE /ServiceRequest
Is this necessary/helpful?
2) I have two basic flows in my eReferral architecture, a) sending ServicesRequests, b) sending Communications. We've discussed "how do we determine that the bundle is ABOUT a ServiceRequest, or ABOUT a Communication" (note that sometimes sending a ServiceRequest can include a Communication). We considered that whatever is the FIRST resource in the bundle will inform whether it is ServiceRequest-oriented or Communication-oriented transmission.
Is this a valid approach/idea?
Lloyd McKenzie (Mar 09 2018 at 15:59):
1. is definitely not true. It's possible some system might try to impose such a requirement, but it's not enforced by the spec and there will be situations where it's not possible
2. Documents or messages can be "about" something - and that's indicated by the MessageHeader.focus or the Document.section.entry resources. Query response, transaction and batch bundles aren't "about" anything. and arbitrary 'collection' bundles aren't defined as being about anything either
Tim Berezny (Mar 09 2018 at 21:11):
@Lloyd McKenzie do you think there's a strong case to be made that sending an eReferral (ServiceRequest) should be a message? i've been working with the batch or transaction approach up to this point, and have never been quite certain if that's the right approach.
Lloyd McKenzie (Mar 09 2018 at 21:21):
Well, a batch just says "create all of these records on the server". It doesn't say "do" anything and there isn't a response. However, if the Batch includes a Task that says "fulfill this" or one of the records has a "please fulfill" tag as discussed in Workflow, then it should result in action being taken. Going messaging means that there's more negotiation required between the systems interoperating. However, it does allow for the possibility of getting a Bundle back and eliminates the need for polling or subscriptions to keep track of how things are going. If you haven't read the workflow part of the spec, you might consider doing so - it talks alot about the different mechanisms FHIR has for managing workflow and what the tradeoffs are. (And feedback about how to make that content clearer/more useful is welcome too :))
John Silva (Mar 09 2018 at 22:57):
There are bundle processing rules that (I believe) address the way a FHIR server is supposed to handle resource dependencies within a bundle: https://www.hl7.org/fhir/http.html#2.21.0.17.1
Tim Berezny (Mar 10 2018 at 13:51):
Thanks, i've spent a fair bit of time looking into the task resource in particular, but am going to try and take a look at the wider workflow perspective.
Last updated: Apr 12 2022 at 19:14 UTC
