Stream: implementers
Topic: MessageHeader.eventCoding: Missing Codes / Code System Typo?
Igor Sirkovich (Mar 04 2019 at 04:56):
MessageHeader.eventCoding is bound to http://hl7.org/fhir/ValueSet/message-events (Example binding), but its expansion has 0 concepts and its Code System http://hl7.org/fhir/message-events doesn't show any codes either. Both Value Set and Code System show maturity level "N". I'm wondering whether the codes are missing due to a generation error and also whether the Code System should be changed to http://terminology.hl7.org/CodeSystem/message-events
Lloyd McKenzie (Mar 04 2019 at 05:40):
We could change the code system, but given that it's empty, there's no real reason. It's empty on purpose. Technically, we should probably just remove the binding. The codes that we did have were a mess and few implementers actually used them - so we yanked them all and leave it up to implementation guides to define the appropriate events.
Igor Sirkovich (Mar 04 2019 at 06:01):
Thank you Lloyd!
René Spronk (Mar 04 2019 at 08:35):
This may change given that CMS (in their letter to HL7) expressed a 'wish' to use FHIR messaging for ADT. This may be the motivation to come up with some example values (probably similar ones to the popular trigger events in v2 ADT). Some US implementation guide could then also publish the GraphDefinitions for the message structures associated with these FHIR messaging trigger events. The current validators don't support GraphDefinition as of yet, although it's on Grahame's to-do list (like a ton of other stuff).
The example triggers which we had in the publication (as Lloyd points out) were in too much of a mess to be really useful.
Grahame Grieve (Mar 04 2019 at 08:58):
it's not clear to me that this is what CMS actually asked for
René Spronk (Mar 04 2019 at 12:18):
I know, but that's my positive message-based interpretation. Which it could well be, replace v2 messaging with FHIR stuff, in which case FHIR messaging would be a good candidate.
Craig Newman (Mar 04 2019 at 13:04):
Is there a mechanism to easily find codes that existing IGs have created for eventCoding? The v2-to-FHIR project may be creating a set of event codes as part of mapping messages to FHIR elements and it would be nice to see which ones integrations are already using and harmonizing if we can.
Benjamin Flessner (Mar 04 2019 at 15:21):
FWIW, Redox does use patient-link(from the STU3 version of the system) for merge scenarios. For other v2 messages we generate eventCodes based on our datamodels (which are, in turn, based on v2 events). For example, https://developer.redoxengine.com/data-models/PatientAdmin.html messages can create PatientAdmin-Arrival, PatientAdmin-Cancel, PatientAdmin-Discharge, etc.
Lloyd McKenzie (Mar 04 2019 at 15:51):
It would be unfortunate to move some v2 messages to FHIR messages when REST could accomplish the same ends better. If we're going to perform as major a disruption as replacing v2 within institutions, we should look at replacing the messaging architecture as well - at least where appropriate.
John Silva (Mar 04 2019 at 16:18):
@Lloyd McKenzie - I went back and looked at your PPT from Sep 2016 "FHIR For Architects" where you describe when to use the Messaging vs RESTful paradygm. It seems like one of the key ones you point out (quoting from your PPT) is:
"Need to drive behaviors more complex than CRUD on a single resource"
"No “identity” for many resources" (this is sometimes one of the problems going from V2 to FHIR -- how to come up with a unique 'business identity' for each resource)
So I guess the question becomes, are there still some V2 workflows where the RESTful model isn't sufficient?
Lloyd McKenzie (Mar 04 2019 at 16:44):
There absolutely can be. My point wasn't that we wouldn't have any messaging. It was more that "just because it was solved using messaging in v2, that doesn't mean we should automatically solve it with messaging in FHIR".
Lloyd McKenzie (Mar 04 2019 at 16:45):
In some cases we might want to support more than one approach - encouragement towards a RESTful solution for those who can manage it with a fallback to messaging for those that can't.
Craig Newman (Mar 04 2019 at 16:46):
It feels like this is a big topic that we should be discussing as part of the v2-to-FHIR project. If we are going to "officially" publish mappings and presumably best practices (or at least advice), we should all be on the same page as to what sort of considerations play into the messaging versus REST decision for a given implementation.
Brendan Keeler (Mar 04 2019 at 16:52):
Pretending that a RESTful solution works for many (most) implementations and trying to funnel them into that paradigm isn't a solution. Messaging (pushing based on event triggers) is a necessary step, especially when considering initial enrollment of patients into third party systems isn't always best served by a query.
John Silva (Mar 04 2019 at 17:35):
@Lloyd McKenzie - as an example (luckily the IHE folks are looking at this) --- how does one represent the "ADT workflow" in the RESTful paradygm? There are obvious event-driven state transitions that don't necessarily fit into the RESTful model . These are the concerns of folks in the V2 world trying to figure out how to embrace FHIR; we are not working with a 'green field' environment so guidance on how to deal with these V2 workflows is very important. (as @Craig Newman says -- this seems to be a bigger discussion than one-by-one mapping of V2 messages to FHIR.)
Lloyd McKenzie (Mar 04 2019 at 17:47):
ADT is actually a whole bunch of different workflows. However, creating encounters, updating encounters, creating accounts, creating and updating patients, etc. can all be done RESTfully - and systems can receive notifications of the same through subscriptions and/or polling. For something like merges, you have a choice of using 'transaction' or an operation.
Grahame Grieve (Mar 04 2019 at 19:22):
I think the picture is very mixed. While it's true that you can achieve many of those things using a RESTful paradigm, it's also true that it's not possible to do that when you are bolting on top of an information architecture based on messaging, where business rules are based on an event model
Lloyd McKenzie (Mar 04 2019 at 20:37):
Right. So one of the questions about a FHIR replacement for v3 would have consider is whether we want to provide a FHIR interface to "sit on top" of a v2 interface, something that would truly replace the v2 interface (no v2 underneath) or perhaps both.
Last updated: Apr 12 2022 at 19:14 UTC
