Stream: implementers
Topic: Subscription to Bundle
Martin Morrey (Oct 16 2019 at 13:22):
Hi,
Can anyone recommend how I should specify a subscription request for new Bundles, matching specific criteria?
For example, I would like to specify a subscription request for new Bundles which contain a Patient which has a managingOrganization reference to a specific Organisation resource
I have found an example of this kind of subscription request , https://developer.nhs.uk/apis/ems-beta/explore_create_subscription.html#criteria-examples
However, although it isn't totally clear, this appears to use a search parameter extension https://fhir.nhs.uk/STU3/SearchParameter/EMS-SubscriptionRuleType-1
Many thanks
Martin Morrey (Oct 16 2019 at 13:25):
My original instinct was to specify a subscription to new Patient resources which met my criteria, but I can't see an obvious way of then retrieving the original message Bundle which contains that Patient resource.
Lloyd McKenzie (Oct 16 2019 at 13:32):
Bundles can exist for a variety of reasons. They're generally only persisted if they're FHIR documents - is that your use-case?
Martin Morrey (Oct 16 2019 at 13:36):
I want to be able to access a message Bundle, as identified by search criteria which apply to one of the resources within it.
I MAY have answered my own question - the _containedType parameter appears to enable this https://www.hl7.org/fhir/search.html#containedType
However, if the message Bundle is not persisted, then I guess that would not work?
Lloyd McKenzie (Oct 16 2019 at 13:46):
Typically messages aren't stored if submitted for processing. Are you just storing undirected messages and then having systems query to retrieve them? The challenge if your Bundle is a message is that the Patient isn't at a pre-determined location. It depends on what the focus for the message is. That makes it hard to search on. Unfortunately the _contained and _containedType aren't going to do what you want. They work on 'contained' resources which is not the same as Bundle entries. You could define a new search parameter that would let you look at any entry in the Bundle (rather than just the root MessageHeader or Composition which is all that's supported by standard search parameters). However, you'd need to customize your server to support it.
Martin Morrey (Oct 16 2019 at 13:52):
Thanks. So, it sounds like I would need to use documents not messages. I am still not clear how I access the containing document Bundle though. Feels like I am missing something obvious here, I would assume this is a pretty normal thing to do....?
Basically the use-case is:
- FHIR server receiving Bundles of resources
- My system subscribes to receive notifications of new bundles/resources, and is then able to retrieve the whole bundle.
Lloyd McKenzie (Oct 16 2019 at 13:59):
Why is the data coming in as a Bundle at all?
Lloyd McKenzie (Oct 16 2019 at 14:00):
If you use Document, you can access the Patient filtering on Bundle?composition.subject
Martin Morrey (Oct 16 2019 at 14:01):
Sorry, my mistake, what I am dealing with would be a transaction Bundle, not a message or a document.
Martin Morrey (Oct 16 2019 at 15:01):
The reason the data is coming in as a Bundle, is that it is a package of data required to trigger an event, which includes mandatory elements over multiple resource-types. It's really a message at this stage in the workflow, which will be submitted as a Bundles of resources in a FHIR POST.
Depending on the outcome of the event, at a later stage of the workflow, the amount of information received on the patient would then be expanded, in one or more subsequent PUT/POST operations.
Martin Morrey (Oct 16 2019 at 15:03):
My understanding now is:
- In FHIR it is not possible to re-create or reference a non-document Bundle after it has been unpacked by the FHIR service.
- If a client solution wants to subscribe to notifications about a new multi-resource batch/transaction, it needs to subscribe to a specific resource-type within that, and then resolve the references between the previously-Bundled resources, to access them all.
Martin Morrey (Oct 16 2019 at 15:07):
I think I am reassured that I am not missing some important feature of post-request, intra-Bundle referencing!
I remain slightly mystified about how the NHS solution works though, https://developer.nhs.uk/apis/ems-beta/explore_create_subscription.html
Lloyd McKenzie (Oct 16 2019 at 15:17):
I wouldn't necessarily say "it's not possible", but it would certainly be a-typical for a system that had received a transaction Bundle and executed the transaction to subsequently make the Bundle available for retrieval via search.
Paul Church (Oct 16 2019 at 15:18):
Looks like the NHS solution is subscribing to Message bundles. Those could be either persisted on the server, or executed through $process-message. If they're just persisting bundles, then this is a normal subscription pattern.
There was some discussion in subscriptions of subscribing to operations, i.e. "notify when operation $foo is executed" that could in theory apply to executing a transaction bundle. I don't think that particular idea has come up though.
Lloyd McKenzie (Oct 16 2019 at 15:18):
For subscriptions, systems generally care about data that's been created or changed regardless of how the change was originated (transaction, batch or direct REST operation
Lloyd McKenzie (Oct 16 2019 at 15:19):
The revised subscription model will indeed support subscribing to particular types of events focused on a resource/class of resources rather than just subscribing to updates to a resource that matches a particular query
Lloyd McKenzie (Oct 16 2019 at 15:21):
Subscribing to transaction Bundles wouldn't be terribly efficient and could pose privacy/access control issues too. A given transaction could theoretically contain data relating to thousands of patients. If you had to query the whole Bundle to see data on a single patient of interest, that could be problematic
Martin Morrey (Oct 16 2019 at 15:27):
Yes, its only the use-case of a multi-resource transaction relating to a single patient that I am concerned with at the moment. If it were possible to define that as an event type, and subscribe to that, that would simplify what I am currently trying to specify.
Paul Church (Oct 16 2019 at 15:30):
Just to throw out an alternative idea, could you accomplish roughly the same thing by subscribing to patient changes and using "Patient/$everything?_since=[last event the client heard about]" to figure out the full set of resources that changed?
Martin Morrey (Oct 18 2019 at 12:18):
Thanks. Yes, I think this would be the pragmatic solution. Only slight concern would be theoretical possibility of getting two co-incident requests mixed/merged.
Martin Morrey (Oct 18 2019 at 12:22):
Also the added complexity of stored date-time of most-recent previous event on the client, although I guess there could be ways round this using _history
Last updated: Apr 12 2022 at 19:14 UTC
