Stream: implementers
Topic: REStful vs messaging for data contribution
frank cao (Apr 22 2021 at 17:48):
Hello. As a FHIR standard developer, what consideration should be given to choose between RESTful vs messaging when implementing data contribution? If we have an existing v2 implementation and we want to migrate to FHIR, should we consider messaging over RESTful?
Cooper Thompson (Apr 22 2021 at 18:49):
I think they key thing to consider here is what your trading partners support. If your trading partners support HL7v2, it might actually be a bad idea to move to FHIR. For a given domain, if there are two standards to do the same thing, you end up with reduced interoperability as there is now a chance that two parties don't implement the same standard and thus can't talk to each other.
Cooper Thompson (Apr 22 2021 at 18:52):
Two other considerations:
1) Is the exchange driven by system events, and if so, which system fires the event?
2) Which system knows the relevant data for the exchange. If the sender knows what data is relevant, than messaging is a good option, as the sender can pack up the relevant data into the message. If the recipient knows what data is relevant, then REST API (possibly with subscriptions) is a good option as the recipient can retrieve the data it needs.
Lloyd McKenzie (Apr 22 2021 at 20:12):
A lot of FHIR implementers choose REST over messaging because it requires much less negotiation - and thus there's a lower bar to getting interoperability across more systems. With messaging, you need to standardize the event codes, the message structures as well as the events and structures for allowed responses. With REST, the structures and events are all nailed down. As yet, there's been no appetite for standardizing messaging definitions at the international level, so when messaging is used with FHIR, it's typically based on IG-driven definitions.
A second consideration is that technologies such as SMART on FHIR, CDS Hooks an a lot of FHIR implementation guides (some of which need to be adhered to for regulatory compliance in various countries) typically depend on a REST interface.
On the other hand, if your back end is v2, you might not have the 'identity' and possibly version information needed to expose a useful FHIR interface.
Craig Newman (Apr 23 2021 at 13:55):
I've always wondered if the behavior of the receiving system impacts the choice. For example, an immunization registry accepts patient and immunization event data from a submitter (hospital, pharmacy, etc) but doesn't necessary store the data as it was sent. Because the registry accepts data from a large number of source who may all know about the patient and the event, the registry may end up ignoring the data (if it's out of date or less complete than from another source) or it may merge records from different submitters together. Does the use of RESTful obligate the receiving system to storing the data as it was sent (not necessarily as FHIR resources, but at least as a record of what was sent in whatever their internal format is)? And if the submitter sends a RESTful update, is the recipient obligated to accept the update?
Lloyd McKenzie (Apr 23 2021 at 14:01):
No obligation. If someone sends a POST and the system feels the data already exists, it can either reject (with an OperationOutcome indicating that the server believes the data already exists) or it can accept, but return a pointer to the existing resource rather than creating a new one. It's also free to drop (or add) to the data actually stored. Both create and update allow echoing back what was actually stored for precisely this reason. (The server SHOULD either echo back what was actually stored or pass back an OperationOutcome with a warning indicating that changes were made - the former being preferable as it provides a baseline for subsequent updates.)
Cooper Thompson (Apr 23 2021 at 14:11):
There are a lot of interesting details around what constitutes a successful "write". We're exploring this in the Argo Write project, but many servers may have different data stores for different types of data. In the registry example, the registry may want to accept and keep the data for reference, but not update their "source of truth" data store. So while the POST might be "successful" in that the registry now has the data. That might mean that a REST read API would not see it.
Cooper Thompson (Apr 23 2021 at 14:12):
The nice thing about messaging is that there isn't any obligation on the receiver to re-expose the data it gets in the message.
Lloyd McKenzie (Apr 23 2021 at 14:19):
Technically, you can have a server that supports POST but not GET - i.e. where the server acts like a black box
Lloyd McKenzie (Apr 23 2021 at 14:19):
You can also have operations that behave that same way
frank cao (Apr 23 2021 at 17:48):
Cooper Thompson said:
Two other considerations:
1) Is the exchange driven by system events, and if so, which system fires the event?
2) Which system knows the relevant data for the exchange. If the sender knows what data is relevant, than messaging is a good option, as the sender can pack up the relevant data into the message. If the recipient knows what data is relevant, then REST API (possibly with subscriptions) is a good option as the recipient can retrieve the data it needs.
In our case, the ADT based implementations are driven by events from hospitals. Does that mean messaging would be easier for them to implement? As the recipient, we would prefer to only supporting RESTful, but the caveat could be 1) what is easier for an HIS to implement without breaking the existing pattern, 2) We may need to support batch data contribution. If there is no best option, is there any downside to supporting both paradigms?
Lloyd McKenzie (Apr 23 2021 at 21:23):
If you're just consuming the data, take whatever they can give you. If you're planning to pass the message along, be sure you have systems that can consume the messages at all if you're planning to share FHIR messaging.
Vassil Peytchev (Apr 24 2021 at 02:21):
In our case, the ADT based implementations are driven by events from hospitals. Does that mean messaging would be easier for them to implement?
I don't think it will make it easier for them to implement messaging, if we are talking brand new capabilities.
As the recipient, we would prefer to only supporting RESTful, but the caveat could be 1) what is easier for an HIS to implement without breaking the existing pattern
It is more likely that it will be easier for them to implement HL7 v2 messages over HTTP. This will put the burden on you to parse and store the contents of HL7 V2 messages, but that would be easiest for the sender.
frank cao (Apr 25 2021 at 19:35):
So it sounds like that RESTful is preferred unless there is specific requirement for messaging. What would be an example when FHIR messaging is better than RESTful, as a recipient system which stores the data?
Lloyd McKenzie (Apr 25 2021 at 19:40):
When there's no possibility of the recipient querying for related data (because they can't reach the source, the source has no query capability, or there's no "identity" to allow reliable referencing across time). Messaging also allows 'routed' transmission via multiple intermediaries where the network address of the end recipient isn't known by the sender - though there's work on standardizing some headers that would allow that to be done in a pure REST environment.
Cooper Thompson (Apr 26 2021 at 14:22):
frank cao said:
So it sounds like that RESTful is preferred unless there is specific requirement for messaging. What would be an example when FHIR messaging is better than RESTful, as a recipient system which stores the data?
The key question is what your trading partners use. FHIR Messaging, FHIR REST API, HL7v2 messaging, or CSV flat files sent over SMTP could all make sense. The only "wrong" answer for exchanging data is faxing :joy:.
Also, consider the bias you might be getting by asking your question in a fhir chat platform.
Brendan Keeler (Apr 29 2021 at 03:22):
Strong and compelling reasons in this thread for us to deprecate HL7V2
Last updated: Apr 12 2022 at 19:14 UTC
