Stream: implementers
Topic: REST vs. FHIR Messaging
Kesara Liyanage (Oct 04 2018 at 02:25):
Does anyone understand differences between FHIR Messaging and REST? I'm a bit confused because, isn't REST just a method for delivering FHIR messages? Why do i keep hearing that REST is not ideal to a real world event? Such as a physical action? Couldn't a RESTful API service be built to deliver FHIR data structures triggered off a physical event?
Lloyd McKenzie (Oct 04 2018 at 02:41):
REST involves using HTTP to create, update, delete and query individual resource instances. So, for example, if you're admitting a brand new patient, you'r first POST a new Patient resource, then maybe a bunch of AllergyIntolerance resources, Coverage resources, a few Condition resources and other information as gleaned from the patient intake form. Then you'd POST a new Encounter resource corresponding to the admission. Over the course of the encounter you might POST and/or update a variety of other resources, including the Encounter. At no point is there ever an explicit event communicated of "patient admission". Instead, you just create (or update) the needed resources as needed by the event. The client decides what happens and when.
Messaging involves collecting a bunch of resources together into a single package (Bundle resource) with a special root resource called MessageHeader. The MessageHeader indicates who's sending the message and who's receiving (which allows indirect delivery). The MessageHeader also declares an event which indicates what sort of real-world activity is going on and cues the recipient as to what they should do with the data. Different recipients might behave differently in response to the same event. The MessageHeader also points to the 'focus' resource. The focus resource then points to and/or is pointed to by other resources which might in turn point to/be pointed to by still other resources. The whole package of inter-related resources deemed relevant to the event is packaged up inside the Bundle and transmitted to the receiver.
In the "patient admit" scenario, the event would be "Patient admission" or some similar code. The focus would be the (new) Encounter. The Coverage, Patient, AllergyIntolerance and other resources would be pointed to from or point to the Encounter or Patient. If the message were sent to a financial system, it would look at the message and grab the encounter information and coverage information and maybe some condition information, integrate that with whatever it had and throw away the rest. The Pharmacy system on the other hand would care about some of the AllergyIntolerances and the Patient demographics but throw away the Coverage. I.e. the server is in control of whether data is created or updated or ignored, not the client.
The main downside of the Messaging paradigm is that it requires consensus on what events can happen, what the focus of the event is, what elements need to be in the message "package", and when sort of response(s) if any are allowed. Also, if you need to set up a new behavior, you have to write a brand new set of code that knows how to process a distinct message. With REST, there's a limited set of operations (create/read/update/delete) that can be combined in various combinations to achieve many types of functionality. A data correction, bed transfer, leave of absense and discharge are all managed with a PUT to the Encounter resource and changing the appropriate data elements.
REST is web-like. You don't have to negotiate with Google, Microsoft, Apple or the Mozilla foundation when you want to set up a new website. You just write the appropriate HTML and make the page available and trust that compliant browsers will be able to find and display it. You can't get that same degree of interoperability with messaging without having some up-front negotiations or without designing your systems specifically to be able to talk over that interface to solve that specific business problem.
Lloyd McKenzie (Oct 04 2018 at 02:41):
Hope that helps...
Kesara Liyanage (Oct 04 2018 at 04:14):
Lloyd, this is tremendously helpful. I'm going to process this more and may have some follow ups. But thank you for taking the time. Much appreciated.
David Hay (Oct 04 2018 at 08:14):
Actually it would be great to have 'sticky' chat messages. This is a great explanation...
Kesara Liyanage (Oct 04 2018 at 13:53):
Lloyd, What i'm understanding is that FHIR messages are more constructive to real world situations and events. Where as sending a RESTful message is sending over set of resources without any real instruction. Also, are you saying that communication protocol is not defined? which means essentially that the client and the source have to negotiate a protocol? Couldn't FHIR messages be sent via REST [HTTP]? Therefore you still send the bundled resources but as a RESTful post or get?
Lloyd McKenzie (Oct 04 2018 at 14:22):
REST is extremely useful (and widely used) for real-world situations and events. It's a different design philosophy. REST is a client-driven architecture. Messaging is more of a server-driven architecture.
With REST, the communication protocol is fixed. You must use HTTP. With messaging, the protocol is wide open. There is an HTTP FHIR operation defined to support message transmission. However, you can also sent FHIR messages over HL7 v2's MLLP protocol, over SOAP, over SMTP, using something like MQSeries, etc.
Michael Donnelly (Oct 04 2018 at 14:25):
As an implementer, we've considered use cases that might require messaging, but REST has met the needs of all those cases thus far.
René Spronk (Oct 05 2018 at 06:40):
To me the paradigm is CRUD, not REST. CRUD over HTTP = REST, so to use the word REST for the paradigm is to tie it to a particular transport. Not that there's anything wrong with REST or HTTP. But if you wanted to, CRUD-webservices could achieve the same functionality, after all, transport is essentially irrelevant when choosing the most appropriate interoperability paradigm (CRUD, messaging, documents, services/operations).
FHIR is the first HL7 standard that embraces (at scale) the use of a CRUD paradigm. The other ones (on which the older HL7 standards are based) are supported as well.
Lloyd McKenzie (Oct 05 2018 at 11:34):
That's certainly the most important part, though the HTTP stack gives you standards for content and security negotiation and other services that you'd have to explicitly negotiate (or couldn't have at all) on other stacks.
Brian Postlethwaite (Oct 05 2018 at 14:58):
The spec does define the full http protocol for it, you could easily modify this for other protocols as you've noted, but as defined in the spec, it's REST.
Last updated: Apr 12 2022 at 19:14 UTC
