Stream: implementers
Topic: Bundles
Vadim Peretokin (Sep 26 2016 at 00:12):
Would I be correct in understanding that the only bundle types processed upon upload are transaction and batch - the rest are stored as-is just like any other resource?
Grahame Grieve (Sep 26 2016 at 00:27):
server's discretion how to handle them
Simone Heckmann (Sep 28 2016 at 13:22):
Interesting question. Makes me think:
If a server receives a document bundle, how does it know whether it is expected to store the document as-is or process the individual resources? There may be use cases for both "persist document" as well as "process document content". But since both go to the same endpoint, how does the server know what to do? Would the latter be an operation, as it potentially involves additional business logic such as mpi lookup?
John Moehrke (Sep 28 2016 at 14:00):
As Grahame has indicated... it is up to the server to decide. Some servers will be functioning as a simple storage system (aka IHE MHD base use-case), where it will just persist the binary as a binary (it will have the DocumentReference as the metadata about that document). Others (and this is fine with MHD too) will persist the binary as a binary, but will also bust it apart into parts. These are not requirements of the Interoperability specification, these would be requirements of the implementation specification. Both (and more) kinds of implementations will be needed in different cases.
Simone Heckmann (Sep 28 2016 at 16:34):
What if there's a server that needs to do both?
e.g an EHR server with
- one Client composes Documents from internal resources and the documents posted to the server simply need to be archived.
- another Client sends external Documents to the server that need to be both archived as well as processed into the Patient record
How will the server tell these two cases apart if both clients POST to the same endpoint...? Or is this unlikely to ever happen?
Simone Heckmann (Sep 28 2016 at 16:39):
It's probably possible to analyze the contend and figure out where stuff came from and whether it is already known to the server or needs to be added. But I guess that's pretty expensive escpecially if the internal documents outweigh the external ones by numbers.
I dunno.
Not a server implementer, just a girl with a vivid imagination.
Grahame Grieve (Sep 29 2016 at 02:52):
have you read this: http://hl7-fhir.github.io/documents.html#bundle
John Moehrke (Sep 29 2016 at 14:50):
I am not clear on why this duality would exist. If there was a real need for different behaviors, then there would likely be different endpoints. An endpoint has a defined behavior. Or we bring in Operations to identify different behavior.
Grahame Grieve (Sep 29 2016 at 15:58):
yes that's what the section describes - the different end points
Simone Heckmann (Sep 29 2016 at 23:56):
Oh! I wasn't aware that document bundles can also go to the basurl. Makes perfect sense to send them there in order to have them processed like transactions/batches. Cool. 
Vadim Peretokin (Sep 30 2016 at 03:03):
I also found additional guidance at http://hl7.org/fhir/2016Sep/http.html#other-bundles that expanded on GG's comment
Mat Coolidge (Nov 08 2016 at 17:36):
We are looking to do a query for all patients on a certain hospital list. In the query we want to also provide a list of observation values we want returned. My thought was using a bundle, but I wasnt sure how to structure the query. Any pointers or examples I could check out?
Mat Coolidge (Nov 08 2016 at 17:55):
Maybe a better question would be how to model a patient list with included resources (not refs)
Mat Coolidge (Nov 08 2016 at 17:56):
would it be a bundle that includes sub bundles?
Lloyd McKenzie (Nov 08 2016 at 20:07):
So your base query, you'd be querying against Observation, filtering on the observation values and also filtering on subject. Your subject would then need to do a "_has" to only include those patients present on the list. You'd then do an _include to bring back the Observation.subject (i.e. patients) too. Only downside is that you wouldn't see patients if they had no observations matching your list of codes.
Lloyd McKenzie (Nov 08 2016 at 20:09):
In general, we don't do "included lists". The search response can include references to or from the selected resources, but we wouldn't want to "store" a Bundle that contains a bunch of patients. You should use the List resource with references and use the query capabilities to include (or not) what you need in your response bundle.
Grahame Grieve (Nov 08 2016 at 21:17):
there's actually 3 options here:
- a single search with include (unlikely to be quite specific enough)
- a batch that has 2 searches, one with an include - that can be quite specific
- a profile on $everything (extending the ways $everything can be limited)
Brian Postlethwaite (Nov 09 2016 at 05:50):
+1 on the batch using searches to span all the resource types that you're looking for, or the $everything if that works for you
Last updated: Apr 12 2022 at 19:14 UTC
