Stream: fhir-messages
Topic: Messaging as change-notification for IntegrationEngines
Simone Heckmann (Jul 29 2018 at 13:57):
Hi all messengers!
We have currently been discussing the following issue:
When we want to update a V2 System with anything that happened in the FHIR world, this gets quite difficult.
First of all, an integration engine would have to either poll the _history of the FHIR-Server or subscribe to all changes and then enrich the changed resources with context (Patient ID, Encounter ID etc) in order to create a valid V2 message.
So we have been thinking to create a message stream from a FHIR Server, that is triggered whenever a resource that lives in the Patient-Compartment
The resulting message SHALL contain
- an event-type that describes the kind of change (create/update/delete),
- the changed resource as focal resource
- both the Encounter(if the focal resource has a "context"-Element) and the Patient as additional resources
The purpose is that Integration Engines can have a realtime datastream from the FHIR Server, that can be processed into a V2 message without additional queries and routed to any V2 system, that needs the information.
Questions:
a) is that a good idea?
b) is anyone interested in developing such a solution or is already working on something similar?
René Spronk (Jul 30 2018 at 06:21):
Intersystems in the context of the English NHS are already doing this - "event detection" (not sure if this is purely FHIR based) followed by a FHIR bundle exchange (not a message I think). @jon payne ?
If one were to send FHIR messages it would help to create a trigger event table for inclusion in the FHIR spec.
jon payne (Jul 30 2018 at 06:59):
Hi Rene. Yes, it's based around receipt of a FHIR bundle, analysing the content against a set of subscriptions and then sending notifications to the interested end points so thy can retrieve the bundles as required. The FHIR bundles are persisted in a repository..
Nick Hatt (Jul 30 2018 at 12:17):
Messaging or at least a bundle sounds like a good approach. The biggest win I could see would be the limitations in the interface engines of the world. Having all the data in one payload would certainly make life easier for whoever is writing the translation, rather than trying to go grab 5 different resources and stitch them together. As event volume grows, the one request will scale better as well.
René Spronk (Jul 30 2018 at 14:03):
To me it's not necessary for the FHIR server to create a stream of messages. In general (and this applies to any standards conversion to a messaging paradigm) one has two problems: (1) detection of the trigger event when a message should be created, which could be based (in case of a FHIR server) on a subscription or some more complex logic, or on a event as triggered by a change to a (proprietary) database [e.g. an Epic persistence layer which exists next to its FHIR API], and (2) how to have sufficient data at hand to create a sufficiently good translation, which may require using cached data, the querying for additional data, or accessing (proprietary) databases to get hold of the information.
Configuring the FHIR server to export a FHIR-message if-and-when a v2-like trigger event happens may not be the easiest solution, for it requires the FHIR server to play along which such a transformation scenario.
Simone Heckmann (Jul 31 2018 at 04:30):
I was thinking, that we might be able to come up with a 80% solution that isn't too complex, but works for a majority of use cases, e,g,:
- Trigger: whenever something that lives in a Patient compartment changes
- Message content: the changed Resource
- the Patient if the Resource has an element "subject"
- the Encounter if the Resource has an element "context"
(or maybe we could (mis)-use the FiveWs model for a generic approach to defining the message content.
I don't think that the triggers need to be "V2-like". They could e far more generic with the Integration engine doing the work of mapping the eligible ones to V2 and discarding the rest. Besides, mapping to V2 probably isn't the only use case, just one of them.
Simone Heckmann (Sep 06 2018 at 07:31):
New idea:
What if we want to combine the routability, server-decides-what-to-do-with-it semantics of the message bundle with the "this-is-what-happened" verbosity of the transaction?
Is it legitimate to have a message type Bundle who's focal resource is a transaction type Bundle?
Like: System A sends out a trigger-based message with an event like "change-notification" and the transaction-Bundle inside the message-Bundle lists the changes that occured. So when System B receives the message, it can look at the changes and decide based on it's own business logic if and how to process the changes.
Along with the transaction that contains the actual change that occured, the message Bundle coult also contain the extra Resources that have just been added for context.
So, the Message could look something like this for an added Observation with Encounter and Patient as additional context (e.g. to populate a V2 ORU message):
Bundle (type="message")
entry(1): MessageHeader (event="observation-change", focus="entry(2)")
entry(2): Bundle (type="transaction")
entry(1) (resource="Observation", request.method="POST")
entry(3): Patient (for context)
entry(4): Encounter (for context)
or like this for an updated Patient:
Bundle (type="message")
entry(1): MessageHeader (event="patient-change", focus="entry(2)")
entry(2): Bundle (type="transaction")
entry(1) (resource="Patient", request.method="PUT")
Bonus: The transaction Bundle within the Message Bundle could also carry PATCH interactions, that could give a very precise Information about which data within a Resource has been added/deleted/updated
Josh Mandel (Sep 06 2018 at 17:31):
Interesting! How does this compare with flattening the internal bundle entries into the external bundle? In your examples there's not much importance to the grouping/nesting of the focus resources in their own bundle -- is the idea that this is directly reflecting a transaction that someone actually invoked, or is this inner transaction bundle more of a synthetic construct?
Simone Heckmann (Sep 06 2018 at 17:50):
it's basically a hack because you can't use the entry.request part in message type bundles, only in transaction or batch...
Simone Heckmann (Sep 06 2018 at 17:51):
invariant bdl-3
René Spronk (Sep 07 2018 at 06:58):
In order for the transaction to be of real value you'd have to assume senders and receivers are tightly coupled and in-sync. That's however one of the basic assumptions in messaging.
Should they not be a receiver could ignore the provided HTTP verbs and process the entire content of the message. The HTTP verbs also are all about client-orchestration, which again is not what I'd call messaging. As such this could still work (obviously), but it'd move us away from what we understand messaging to be. We already have the focal act to identify the things-that-changed, all non-focal acts just provide context. As such: what's the big benefit of the proposed approach?
Aditya Joshi (Sep 10 2018 at 13:24):
Hi @René Spronk does it mean that all the resources which contains some change should be referenced by MessageHeader.focus? Definition of focus states- "a reference to the root/focus class of the event". It sounds like it should be the main resource for which we are creating this message.
Taking an example- Sender sends Message with EligibilityRequest data. It needs EligibilityRequest resource, Patient resource, Encounter Resource, Coverage, Organization and Location. I thought that focus will refer to only EligibilityRequest resource which will internally call to rest of them (Patient, Coverage, Organization - Provider and payer etc.). Or we should have all the resource referenced through focus?
Same way, when Payer will send response message, that would have EligibilityResponse resource as the key resource but there would be certainly changes or updates in Coverage (more plan details), might have more data for Patient, reference to original EligibilityRequest resource etc. Here should we put EligibilityResponse resource n focus or all other resources wherever there are changes (Coverage, Patient)?
René Spronk (Sep 10 2018 at 14:36):
It depends on the trigger-event. If the trigger event is "new eligibility request" then it makes sense to only have that resource as the focus. That resource is the one undergoing a state change (it's being created). Messaging is based on server-side orchestration, having something as the focus assists the receiver in selecting the resources associated with the trigger event. If we assume such a message could contain earlier EligibilityRequests than the one that is the focus is the key one on this message, the others are just supporting information and not part of the focus.
I don't think that 'something changed in a resource, therefore it needs to be a focus resource' is true. A receiver may, if it elects to do so, process all resources (focus or not), or none, as it sees fit. There's no way a sender can influence the behaviour of a receiver, other than the expectation that a sender has that a reasonable (from a business process perspective) response message will be sent. In your case, that response message should at least include a EligibilityResponse resource (which is the focal resource of the response). Whether or not supportive information is present in the response message will be up for you or others to define in a profile.
It gets a bit more tricky when one has a trigger event that doesn't have a single resource as its focus: e.g. "admit newborn child" - a message which has an Encounter, and the Patient (baby) resource as the focus, and a Patient (mother) resource as supporting information. Trigger events are not predifined in FHIR, so they can be whatever you'd like them to be..
Aditya Joshi (Sep 10 2018 at 21:03):
Thanks for explanation. It helps.
Simone Heckmann (Sep 12 2018 at 12:34):
In order for the transaction to be of real value you'd have to assume senders and receivers are tightly coupled and in-sync. That's however one of the basic assumptions in messaging.
Should they not be a receiver could ignore the provided HTTP verbs and process the entire content of the message. The HTTP verbs also are all about client-orchestration, which again is not what I'd call messaging. As such this could still work (obviously), but it'd move us away from what we understand messaging to be. We already have the focal act to identify the things-that-changed, all non-focal acts just provide context. As such: what's the big benefit of the proposed approach?
@René Spronk
I think the benefit of the proposed approach is the following:
Let's assume, that the messages / change notifications are being broadcast from a central system to FHIR and non-FHIR-receivers alike. It'd be easy for an integration engine to process the messages into HL7 V2 messages for one receiver as well as posting them as a bare FHIR transaction to another in order to keep both FHIR and non-FHIR systems in sync with the sender.
René Spronk (Sep 12 2018 at 13:27):
That's true, however senders are rarely motivated by things like 'let's make things easy for an upstream messaging engine". The entire purpose of an engine is to do the conversion, in whatever way it sees fit.
A message-receiver determines what it'll do with the content of the message, as such you can't ever assume they'll be in-sync with a sender anyway.
Last updated: Apr 12 2022 at 19:14 UTC
