Stream: implementers
Topic: Messaging, the unloved paradigm
René Spronk (Sep 05 2017 at 13:20):
During the upcoming DevDays in Amsterdam I'll be presenting a session (see https://www.fhirdevdays.com/schedule/#event-403 ) with the title "Messaging, the unloved paradigm".
Within the FHIR community messaging is usually seen as an old fashioned way of data interchange, yet at the same time: messaging is probably the most widely used paradigm for data exchange in healthcare, and a large number of FHIR projects are based on FHIR messaging.
My questions to you:
(1) I'd love to know about your messaging project, especially if the choice to use messaging was NOT based on the fact that you're converting from/to HL7 v2. The English NHS has embraced messaging, mainly for volumetric concerns they have with REST. - that's the kind of stuff I'd love to include in the presentation.
(2) As part of the presentation I'll debunk some of the bogus arguments against the messaging paradigm (like: "messaging is old fashioned"). [Note that there are valid arguments pro/con messaging, just as there are pro/con arguments related to REST or documents]. What bogus arguments have you heard yourself?
Lloyd McKenzie (Sep 05 2017 at 14:05):
Canada is using messaging with a "mailbox" approach on a central server for secure communication and e-prescribing. Rationale was that recipients wouldn't necessarily be up at time of delivery and a desire to send all relevant information as a single package. There was no desire to support information access beyond specificly targeted recipients, so hosting the information a FHIR server for query seemed inappropriate.
Richard Kavanagh (Sep 05 2017 at 14:30):
@René Spronk as you say in the NHS we are using the messaging paradigm quite extensively. There are a number of reasons for this not all attached to volumetrics. We use RESTful and Document paradigms as well. An appropriate solution to address the problem Across our very heterogeneous landscape we have to cater with a stack of legacy and a broad spectrum of "digital maturity". Happy to discuss more if you are in San Diego.
John Moehrke (Sep 05 2017 at 15:22):
Rene, I find that FHIR has added features that resolve much of the problems people point out as critical against messaging. First of all is the Subscription, to enable dynamic attachment/detachment to a messaging stream. Second of all the Conformance capabilities, to align expectations. Yes, messaging can be done without these, and you will end up with a very HL7 v2 like system... :-)
Grahame Grieve (Sep 05 2017 at 17:33):
I'm interested to know what the 'large number' is beside the NHS
René Spronk (Sep 06 2017 at 06:42):
@Grahame Grieve I'll add that to my list of issues to debunk -the "nobody is using it" comment. I'm aware you didn't intent to word it like that. I'm aware of 3 implementations that use it in production, and I recall some chats here with a fair number of participants (e.g. about 'trigger events'). I have yet to find out if/how they're using messaging.
As always it's difficult to be aware of projects that use one's specifications. How many projects do you know of that use FHIR Documents (i.e. those projects whose use-case is NOT based on CDA conversion) ? That's tough - it's early days yet.
René Spronk (Sep 06 2017 at 06:47):
@John Moehrke Note that my DevDays talk is aimed at those that know nothing about HL7v2, those that started working afresh with FHIR without any prior exposure to HL7. When en why should they use the messaging paradigm ? What is the messaging paradigm ? - That's the issue I'll be addressing, without mentioning HL7v2 ever (well, maybe just once, to illustrate the migration issues).
(As a side note: there'll be a similar talk at DevDays about the document paradigm for those new to FHIR, without any mention nor explanation of CDA R2)
Igor Sirkovich (Sep 06 2017 at 19:59):
In Ontario, Canada, we are using messaging for submission of immunization records by doctor's portal and EMR systems to the provincial immunization repository. The submission goes into a temporary repository first where public health nurses review them, might call a provider in case they need to clarify anything, might add a patient record if it's not in the system yet (e.g., newborn or newcomer) and then approve these immunization records to be added to the main repository.
Grahame Grieve (Sep 08 2017 at 03:03):
thx
Nick Hatt (Sep 08 2017 at 13:52):
@René Spronk me and my colleagues at Redox have built a cottage industry out of turning HL7v2 messages into JSON (not necessarily FHIR messages). The key concepts I would hammer home are state and events. Messages are powerful because they provide a framework to map real-world state changes. If I tried to map an ADT^A02 message to bundle, I would be relying on the receiver to detect a change in location for the patient. This seems risky, ands a lot of complexity to the receiver's logic. Best to explicitly say "A transfer happened" to remove ambiguity and allow the receiver of the message to focus on what to do after that event happens.
If you're looking for an example that can illustrate the concept - look at github webhooks: https://developer.github.com/webhooks/
People want to develop things that respond to events in Github in real-time. Same goes for healthcare, and real-time is much more important than github webhooks when it comes to ADT.
René Spronk (Sep 28 2017 at 12:17):
What's the intent of MesssageDefinition.event?
René Spronk (Sep 28 2017 at 12:23):
..and if trigger event, why not as a code as in CapabilityStatement.messaging.event.code ?
René Spronk (Sep 28 2017 at 12:28):
Side observation: CapabilityStatement.messaging.event.focus is 1..1, whereas a message can have multiple focal resources (this is supported by MessageDefinition..)
René Spronk (Sep 28 2017 at 13:28):
Side observation 2: CapabilityStatement.messaging.event.response is 1..1, thus indicating that each and every event shall have exactly 1 response message type. MessageDefinition has a 0..* list of AllowedResponse. message
Side observation 3: MessageDefinition has a strange lack of references to StructureDefinition - the only such link is for the "focal resource", not for the remainder / overall structure of the message.
Lloyd McKenzie (Sep 28 2017 at 14:47):
Cappability.messaging.event is going to go away, replaced by MessageDefinition. But I agree that the change away from code is concerning. MessageDefinition needs to be updated to use GraphDefinition to define the content. I'd forgotten to write the CR to do that. now done - GF#13970
Lloyd McKenzie (Sep 28 2017 at 14:47):
The intent with URI is to point to EventDefinition - but that seems like severe overkill given the historic use of messaging.
René Spronk (Sep 29 2017 at 09:14):
Ok, so something like [messaging_conformance.jpg] (shown below, showing highlights only for educational purposes)(https://chat.fhir.org/user_uploads/10155/8GcLAAlb_LrgDV_Y8VLnIBuy/messaging_conformance.jpg)
The NHS uses Composition as the focal resource in messages, which simplifies the graph.
Lloyd McKenzie (Sep 29 2017 at 15:09):
Yes
Last updated: Apr 12 2022 at 19:14 UTC
