Stream: implementers
Topic: message events
Joanna Gaskill (May 18 2017 at 19:31):
Hi, I am looking into leveraging the message header and am confused by the message event codeset as it appears that it is meant to be a comprehensive list of values (https://www.hl7.org/fhir/valueset-message-events.html) but I thought any type of resource could be sent through the messaging interface and this list doesn't seem to have an appropriate option for the types of data messages we are exchanging (essentially ADT encounters). I'm also noticing a trend that often the codesets don't seem to have a comprehensive list of allowable values. Am I just misinterpreting this? Insight would be appreciated.
Grahame Grieve (May 18 2017 at 20:06):
have you read about the binding strength?
Grahame Grieve (May 18 2017 at 20:07):
with regard to messaging specifically, there has not been strong interest from the community in clarifying the use of messaging, so the message event list remains under investigated
René Spronk (May 19 2017 at 07:15):
there is some use of messaging, but typically not for ADT - most of that will continue to be v2 within the forseeable future. As Grahame points out the list was never intended to be exhaustive (you can easily define your own codes), it would however be good to add some of the more common ADT events. We do appreciate your suggestions.
Grahame Grieve (May 19 2017 at 09:46):
it's not clear whether the ADT events are relevant given that the resources are rich in status information. if they are useful - and why? - then what should the rules be between event and status?
René Spronk (May 19 2017 at 12:16):
status history does allow one to detect status changes.. state changes have traditionally been the trigger events, but not necessarily so if the state change is well identified as part of the payload (compare to ORC-1 in v2). Merge, Link etc. will be some of the exceptions.
Grahame Grieve (May 19 2017 at 17:28):
so you'll see that we have events for link etc.
René Spronk (May 20 2017 at 17:11):
In messaging we'll have a bit of an issues, systems are by definition 'loosely coupled' (one can't expect the receiver to be aware of the prior status of a focal resource) and 'status history' (which has cardinality 0..*, an element which only some of the administrative resources have).
Patient has no status history, so in order to be aware of the state change we'll need a full list of trigger events. For Enounter, it has 0..* statusHistory, so we can't always be sure that it'll be present. This'll need more analysis, but to me it seems we'll again end up with a fairly long list.
Grahame Grieve (May 20 2017 at 19:39):
why do you need to know what the status changed from?
René Spronk (May 21 2017 at 06:44):
Current trigger events in v2 and v3 always identify the state change, not just the resulting status. An encounter which transitions from planned-to-in_progress (v2: A01/A04) requires different processing than an encounter that transitions from finished-to-in_progress (v2: A11).
The situation is eased in FHIR in that we have a focal resource, as such "state change notification: from active to non-active" would apply to Patient and lots of other v3-role like resources, just as "state change notification: from planned to in-progess" would not just apply to Encounters but to other v3-act-like resources as well. So at least in FHIR we don't have to pre-coordinate the focal resource type into the trigger event code.
In my mind the trigger event is an identifier for a) the state change [in notifications], b) the receiver responsabilities (how to respond) [in orders] c) other behavioral expectations [the operation in FHIR speak] (e.g. process, store, do something, merge, link, ..)
Last updated: Apr 12 2022 at 19:14 UTC
