Stream: fhir-messages
Topic: Multi-page messages
Benjamin Flessner (Jun 08 2018 at 13:46):
Has there been any thought to how FHIR might support paginated message bundles? I understand how pagination works with search results - the bundle contains links to pages of results that the client can retrieve - but this seems a bit clunky when a client is breaking up a bundle into multiple messages.
Sure, the server could know the first message of a collection of bundles has link/relation/self = link/relation/first and the last has link/relation/self = link/relation/last. But it would seem better to simply include this in the MessageHeader resource itself, something like { pagination: { currentPage: 1, totalPages: 26 } }.
Is there an alternative to / preference for these two options?
Lloyd McKenzie (Jun 08 2018 at 14:12):
There's been little to no work on message-based query responses. We haven't defined how to submit message-based queries, let alone continue them. Out of curiousity, what are your reasons for using message-based queries rather than simple REST?
René Spronk (Jun 08 2018 at 14:37):
A message based query is just a Message bundle with a Parameters resource as its focal resource.
René Spronk (Jun 08 2018 at 14:41):
Pagination: the current documentation is silent on this, there is currently no way to set the 'max number of requested responses' in a message based query. To answer a message based query synchronously with a bundle of response messages doesn't really help that much, because this would still be "all of the query results", whereas you only want a part of the result set. Both v2 as well as v3 support a continuation query, and as such you could create a change request to support the use case.
Benjamin Flessner (Jun 08 2018 at 14:53):
To clarify, I'm not talking about querying. I'm talking about using messaging to send a bundle of information to a FHIR server. The bundle needs to be handled as an entire group, but may need to be split into multiple messages.
Lloyd McKenzie (Jun 08 2018 at 15:15):
What's the event that drives passing the information? (And what's the usecase for using messaging rather than batch?)
Benjamin Flessner (Jun 08 2018 at 15:40):
The event is an export of data to be sent to a FHIR server. So you're right, it may make more sense as a batch or even a collection, though we're making use of information in MessageHeader.
In any case, the request is the same. This data dump may be too large to be contained in a single bundle, but still needs to be processed as a single group. So what would be the best way to communicate the relationships among multiple bundles? Stick to the link properties? Something in Bundle.meta? Extension somewhere in Bundle (but not Bundle itself)?
Lloyd McKenzie (Jun 08 2018 at 16:07):
Is it a batch or a transaction? If it's a batch, processing can proceed separately. (And if it's that huge, processing it as a transaction seems somewhat scary...)
Benjamin Flessner (Jun 08 2018 at 16:36):
Technically the whole set of bundles should be processed atomically, which I agree seems scary. Practically what is going on is (to use a term from René's messaging presentation) a "rip and replace" but instead of an allergy list, we're processing a facility's schedule which could be comprised of thousands of slots.
So while we don't need to actually process every bundle at the same time, we do need to know when the bundles start (i.e. when to "rip") and when the bundles are complete (at which point processing is complete or, if not all bundles have been received, we can rollback the data and/or return an error to the sender).
Lloyd McKenzie (Jun 08 2018 at 18:02):
Interesting use-case. I'm not even sure how we'd have solved that one in v2. You're sort of doing a pseudo-transaction split across multiple transmissions.
René Spronk (Jun 09 2018 at 08:04):
Looks more like a transaction-bundle question to me than messaging.
v2 does support the initial loading of a database via v2 messages, but that's not transactional (that is, each message is transactional, but not the overall sequence of messages).
Benjamin's use case doesn't fit within the 80%, so he'll have to use some creative workaround / extension to cover it.
Last updated: Apr 12 2022 at 19:14 UTC
