Stream: implementers
Topic: Purpose of "MessageHeader.focus"
Tim Berezny (Mar 02 2019 at 14:53):
I'm trying to understand the specific intent behind MessageHeader.focus, to prevent myself from using it improperly.
I have a Messaging paradigm for submitting a ServiceRequest. In it, I send a ServiceRequest + a half dozen other related referenced resources like Patient, Practitioner, etc... (the event is called "add-service-request")
Now, it's clear from the event "add-service-request" that the message is primarily focused on the ServiceRequest. None the less, should I be using the MessageHeader.focus to reference the ServiceRequest bundle (and ONLY that resource)?
Tim Berezny (Mar 02 2019 at 14:57):
Also, in words that are different than what is published on build.fhir.org/messageHeader.html, what is the main purpose of messageHeader.focus (I'm having a hard time understanding exactly from the wording that is there)?
Lloyd McKenzie (Mar 02 2019 at 15:51):
Messaging is all about events. The MessageHeader.focus points to the focus of the event. Typically there will only be one focus. However, for some events (e.g. a merge) there can be more than one. Everything else in the message needs to connect to the focus resource(s) through some pathway of forward and/or backward links.
Tim Berezny (Mar 02 2019 at 16:03):
Great thanks, that's pretty clear and leads to my next question:
Let's say I make updates to my ServiceRequest and want to communicate that to others via messages. These updates might be to the ServiceRequest resource, or to an associated appointment, or to the Patient resource, or task etc...
TYPICALLY the workflow is that these resources are updated one at a time (i just added updated the ServiceRequest.status, or I just moved the appointment timeslot, etc...)
I have two architectures in mind for how to deal with sending these update messages out
ARCHITECTURE 1:
- Create a message event for each thing that can happen (e.g., add-appointment, update-appointment, update-service-request, update-status, add-document, etc...). Each of these events is essentially about a single resource in the ServiceRequest.
ARCHITECTURE 2:
- Create just one or two events (just update-service-request and possibly add-to-service-requeset ... or something along those lines) where the messageHeader.focus points to the resource of interest in that particular update. (this is kind of mimicking a more RESTful pub/sub architecture)
Is there a preferred/more common approach to this?
Lloyd McKenzie (Mar 02 2019 at 19:45):
The most common approach is not to use messaging at all and to use something similar to architecture 1 and just RESTfully create/update/delete resources as needed. Messaging is, by nature, a custom solution where all the participants need to customize their solutions to work with an agreed set of message events, agreed structures for payloads and agreed sets of responses to received messages. With REST on the other hand, the possible events (create/read/update/delete), payloads and responses are already pre-defined. That makes it a more open interface and more useable for alternate purposes. So if you don't need to use messaging, don't.
However, in some cases, REST won't meet requirements. REST doesn't provide context about what's happening or why. For example, a RESTful Encounter update could represent a bed transfer, a change to planned discharge date, an actual discharge, etc. It might be possible to infer what's going on by comparing previous data to new data, but it's not always obvious and sometimes multiple things will happen at once. If you have business rules that enforce different access privileges based on specific types of updates, you may need the "event code" that messaging provides. The other reason for messaging is if the systems involved don't support any query ability to retrieve contextual resources. For example, if you send a "create Encounter" REST call, the patient, admitting practitioner, reason for admission, etc. will all be references to other resources. If there's no ability for someone to retrieve those references, then you may need to pass everything together in one package.
In terms of the appropriate boundaries for events, there's no particular rules as it'll be driven by business requirements. If there are distinct rules, access privileges or responses for "add appointment, update appointment, update status, add document", then they may need to be distinct events. If you don't have a need to make them separate, then the only benefit would be slightly lighter-weight messages with a cost of considerably more development effort and testing.
Tim Berezny (Mar 02 2019 at 20:13):
Thanks, that's extremly helpful.
We initially went with messaging due to routing via HIAL needs, which is no longer a need so we are re-evaluating our approach.
1. Is it ok to have an implementation with mixed paradigms, where some business functions are solved with a restful paradigm and others with Messaging? or is it supposed to be an all or nothing thing into either camp?
2. When it comes to letting other systems know about changes to a resource in a restful paradigm, are subscriptions the way to go?
Lloyd McKenzie (Mar 02 2019 at 21:51):
1. FHIR was very much designed to support/enable mixed modes and to ease conversion between the different paradigms. Use REST where you can, but where the need dictates that a document approach or a messaging approach is going to better fit the use-case, then use those. The resource instances should end up looking the same regardless.
Lloyd McKenzie (Mar 02 2019 at 21:53):
2. Subscriptions and polling are the two primary mechanisms. Subscriptions means you'll get pushed a notification if something of interest has changed. With polling, you can do a query of records of interest, filtered by _lastupdated and see if there's anything new. Which approach makes sense depends on whether the system that needs to be notified is capable of receiving pushes.
Tim Berezny (Mar 02 2019 at 22:15):
Perfect, that's incredibly clear and helpful, thanks @Lloyd McKenzie !
AbdulMalik Shakir (Mar 04 2019 at 00:50):
For what its worth we struggled with the same issues with the "proper" use of message header for the Bidirectional Services electronic Referral project (BSeR). We considered the use of three elements in the message header: event, reason, and response. We use the MessageHeader.event to indicate the message type - referral request or referral request feedback. A referral request message is always sent by the referral initiator and a referral request feedback message is always sent by the referral recipient. We use the MessageHeader.reason to identify what triggered the sending of the request or feedback message. We developed a state machine for the referral (aka service request) and used the codes for each state as the value for MessageHeader.reason. We use the same message header structure for acknowledgment messages in which case we use the MessageHeader.response to indicate success, failure, or fatal failure of message receipt.
This approach is not novel, it mimics the message type/message trigger event model of HL7 v2. It works, we implemented for use in the HIMSS Interoperability Showcase along with Chicago Health System ACO, YMCA of America, and the Centers for Disease Control and Prevention. Whether or not this is an acceptable, flawed, or ideal approach is beyond my expertise. However, it is what we did and we describe our approach in our ballot. http://bit.ly/2tMX3s8 We will hear what the community thinks of our solution and react to ballot comments in May.
Grahame Grieve (Mar 04 2019 at 00:56):
I think that's pretty much the intent
Nick Hatt (Mar 06 2019 at 15:20):
Polling is an anti-pattern and I recommend RESTful PUT/POST, Messaging, or Subscriptions, especially if you're starting from scratch. In polling, the client is solely responsible for making sure they get all the updates. The other methods offer some form of acknowledgement so that the server knows the ServiceRequest made it downstream.
Nick Hatt (Mar 06 2019 at 15:26):
I think Zapier did some research on their own internal data and found that some crazy high > 95% of polling cycles were wasted. I can't find that blog but they have some notes on polling and deduplication here: https://zapier.com/developer/documentation/v2/polling/
Nick Hatt (Mar 06 2019 at 15:28):
We poll something like 10 different EHR vendors proprietary APIs so we can turn it into FHIR or whatnot and broadcast stuff out. As soon as the EHRs can support webhooks we convert things as soon as we can because of the consistency guarantees.
Lloyd McKenzie (Mar 06 2019 at 16:12):
Polling is an anti-pattern in some environments. Polling can be quite light-weight and can have variable frequency. The benefit is that it often doesn't require any customization of client or server. It works "out of the box". Messaging, on the other hand, generally only works in a closed community where the participants have all been adapted to support a specific message flow. Certainly if the systems involved can support subscriptions, it makes no sense to use polling.
Tim Berezny (Mar 17 2020 at 14:30):
@AbdulMalik Shakir I just clicked the link in your message to see your state pattern for eReferral (http://bit.ly/2tMX3s8 ) and it doesn't work anymore. Where might I be able to find it now?
Vassil Peytchev (Mar 17 2020 at 16:25):
Maybe it is in the BSeR IG?
Last updated: Apr 12 2022 at 19:14 UTC
