Stream: implementers
Topic: modeling specific details in FHIR Messaging
Josh Mandel (Feb 21 2020 at 17:08):
I'm still trying to grok messaging ;-)
As an example, say I want to send notifications like "Alice is retiring and transfering her practice to Bob on Jan 1, 2021."
To start, I'd define an event code (like maybe system: http://vocab.example.org/CodeSystem/lifecycle, code: practice-transfer). Then any time I wanted to send a message over the wire, I'd create a messaging Bundle and populate its MessageHeader.eventCoding with my new practice-transfer Coding.
But I'd still need a spot to indicate:
- That Alice is the one retiring
- That Bob is the one taking over her practice
- That Jan 1, 2021 is the date of the transfer
Here's where I'm struggling. In (1) and (2), Alice and Bob could be represented by FHIR Practitioner resources, and maybe could be listed in MessageHeader.focus, but how would I indicate which one is retiring, vs which one is taking over? And (3) isn't a resource, obviously. Would the transfer date be an extension on the MessageHeader?
Alternatively, I see an example involving Parameters in http://build.fhir.org/messaging, but this would appear only to apply to operations, and not for notification-type messages like the hypothetical practice-transferI describe here: the docs say that Parameters "has no other use" beyond "to pass information into and back from an operation."
I feel like I'm missing something. This seems like just about the simplest example of a "data model" for a message. @Lloyd McKenzie and @René Spronk or others, please let me know if there's a clear expected approach here.
Josh Mandel (Feb 21 2020 at 17:13):
(Incidentally, the example at http://build.fhir.org/messaging.html#search, like all inline examples in the FHIR spec, isn't auto-validate and therefore has fallen out of date. I've submitted J#26366 for this.)
Vassil Peytchev (Feb 21 2020 at 17:25):
How would you model this with REST and resources? I think you might be expecting too much from messaging. My first reaction would be making the "transfer" the focus of the message, maybe using Task.
Josh Mandel (Feb 21 2020 at 17:27):
Thanks for the quick response @Vassil Peytchev.
If this example is out of scope, what's the right way for me to think about what's in-scope?
Re: expecting "too much," this feels like about the simplest kind of notification we could consider, right? It uses one existing resource type (Practitioner) and one existing data type (date). In REST I'd use a Parameters resource or a set of extensions to capture these.
René Spronk (Feb 21 2020 at 17:29):
What really changes, and what resource would one use to express it? 'Transferring a practice' could either be as simple as setting active=false on Alice. And on PractionerRole for Bob you could set active=true for a role in the 'practice organization'. The focus could also be on a Contract between Alice and Bob, with Alice and Bob as supporting (non focal) resources.
Josh Mandel (Feb 21 2020 at 17:30):
I'm not asserting anything changes; this notification might be a broadcast that goes out via messaging to lots of endpoints in a region. Some might update their referral software, others might mail out notices to patients, others might just keep a log, others might throw it away. It's intended to be a classic "notification" here.
René Spronk (Feb 21 2020 at 17:33):
Bob taking over from Alice, that's a change. Which triggers the notification. Trigger = 'new practitioner takes over old practitioners practice/role'. Focus = 2 PractionerRoles, one which has status active, (and a date range, with the from date being the date of the switch), and the other one which wil have status active=false. Practice is referenced from PractitionerRole. That's simple enough, no need for any complexity.
Vassil Peytchev (Feb 21 2020 at 17:36):
Sounds like you are looking for a Notification resource, that can have a generic set of parameters? The way I understand it, sending notifications is enabled by messaging, but the semantics of the notification is expressed using the resources in the content.
René Spronk (Feb 21 2020 at 17:39):
Indeed. Notifications are based on state changes, and the focus of the message will be that resource/those resources that are subject to the state change. Any other supporting resources may be contained in the body. Some state changes (triggers) may not have a 1-1 relationship to state changes in a FHIR resource, and then the mapping gets a bit trickier.
Lloyd McKenzie (Feb 21 2020 at 17:51):
Messaging doesn't allow you to represent events that can't be expressed using resources normally. I agree that you'd probably be looking at Task to represent that transfer of practice. The MessageHeader would point to the Task.
Josh Mandel (Feb 21 2020 at 18:15):
I guess I'm trying to ask the more generic question, as Vassil suggests. Is messaging limited to conveying "state changes as represented in FHIR"? In other words, does every notification correspond to some set of operations I could invoke on a FHIR REST server to update the state of the world? I thought "event codes" were meant to define an event space outside of simple / explicit state changes.
Josh Mandel (Feb 21 2020 at 18:15):
If every message could be boiled down to a RESTful transaction bundle POST, the world gets a lot simpler.
Josh Mandel (Feb 21 2020 at 18:16):
Reading above, René says:
Some state changes (triggers) may not have a 1-1 relationship to state changes in a FHIR resource
... while Lloyd says:
Messaging doesn't allow you to represent events that can't be expressed using resources normally.
Is there disagreement or ambiguity on this point?
Jean Duteau (Feb 21 2020 at 18:26):
When I think of messaging, I tend to fall back on the HL7 v2 ADT messages as a comprehensive set of messages and their events. Some of those can be directly done via REST operations, but in many cases, there is some extra backend services that are being done which makes messaging a better fit than a REST operation.
As an example, sending the ADT_A01 Admit Patient message would have a Patient resource as its focus. This gets blasted out as a message from the ADT system to all of the other areas in the hospital and each of those areas does some area-specific thing. In all cases, I could reproduce this by simply creating a new Patient/Encounter resource in each of those area's systems. But then that system would have to have some notification that says "ah, new patient has been created, must create a ping so that someone can be alerted to do something". That something could be a "add the patient to the lunch and supper delivery service list" or "send a menu of food items to the patient's hospital location so they can choose their meals", etc.
Jean Duteau (Feb 21 2020 at 18:30):
I don't think that Lloyd and Rene are disagreeing.
I think that Rene is saying that there will be times you can't express what you want the receiving system to do completely with a FHIR resource. As an example, my ADT message to the Nutrition Services system is saying "here is this new patient, go do whatever it is that you do when a new patient is admitted". There isn't necessarily a FHIR resource that can be sent that represents that "go do" part unless you explicitly wanted to represent that as a Task. But I wouldn't use Task. I would just send the trigger event and the patient information (and maybe the Encounter information to indicate length of stay and location in hospital) and let the nutrition system do whatever it does.
Meanwhile, I think that Lloyd is saying that you can't use Parameters or some other means of expressing the stuff you are sending to the receiving system. Thus Rene's solution to your Practitioner transfer example. You don't use Parameters or anything to express the transfer date, you indicate that using the resources that Rene provided.
Lloyd McKenzie (Feb 21 2020 at 18:55):
I think of messages as intrinsically being operations. Typically the operations are super-simple ones where just specifying a focus or two is all that's needed. If the arguments are more complex, then the MessageHeader.focus might well be Parameters. What messaging typically adds is:
- supports routed delivery
- supports asynchronous responses (though we now have this covered at least in part in REST)
- supports operation where all contextual information must be delivered at once because the systems involved can't query to get context later
The most typical use-case that drives messaging is the last one.
Josh Mandel (Feb 21 2020 at 19:08):
I think that Lloyd is saying that you can't use Parameters or some other means of expressing the stuff you are sending
I think Lloyd just stated otherwise (... "the MessageHeader.focus might well be Parameters").
Jean Duteau (Feb 21 2020 at 19:08):
i know. i give up on trying to decipher lloyd's thoughts. :)
Josh Mandel (Feb 21 2020 at 19:09):
;-)
Josh Mandel (Feb 21 2020 at 19:09):
operation where all contextual information must be delivered at once
The regular old "Operations" framework supports this too -- you just supply the context as input parameters. So that's not in itself a driving use case. Ditto with asynchronous responses, given the async operations framework. Routed delivery seems like the key point of differentiation.
Lloyd McKenzie (Feb 21 2020 at 19:23):
Right. It should be able to be Parameters, but there's a prohibition. Also, Task can also behave in an operation-like manner, so there are multiple ways to skin the cat - and we don't have strong guidance, at least not yet.
Josh Mandel (Feb 21 2020 at 19:40):
OK, created FHIR#24848 the issue Vassil notes below for Parameters.
Vassil Peytchev (Feb 21 2020 at 20:52):
That doesn't seem to be the correct Jira issue - FHIR#26368
René Spronk (Feb 22 2020 at 09:35):
Jean is correct in that I don't believe a trigger event could only 'be about' something that can be expressed in FHIR. The whole point of a message is that a trigger event has 'business expectations' associated with it which need to be agreed upon by senders and receivers, these are not (don't have to be) expressed in a computable fashion anywhere.
Sending a 'discharge message' for inpatient Smith to the cleaning department will probably cause the bed to be exchanged and the room to be cleaned, but in and of itself there's no Task in the message that expresses that. If one were to translate such a message into a FHIR Transaction then one would have to explicitly express the business expectations, i.e. the 'trigger event' would be translated into a Task en a SeriviceRequest to clean a particular room/bed.
There's no need to be verbose when it comes to messaging. The trigger event identifies the business expectations. In that sense Lloyds comparison to a named operation holds - that operation will have to know what to do with the parameters it receives, it has knowledge of/implements business expectations that have not been explicitly expressed in its parameters.
Eric Haas (Feb 22 2020 at 18:44):
We have discussed at length Sub+Rest vs FHIR messaging. How would this scenario be answered with Sub + REST space, I would expect the Topic to correspond the event and focus? I have followed this thread and came away with use A,B, or C depending. That is not very satisfying answer for an interop standard is it?
Vassil Peytchev (Feb 23 2020 at 03:24):
I see these discussions as the first step towards a more cohesive guidance on the use of the different ways to exchange data using FHIR... I have linked several Zulip discussions in the Jira issue above, so hopefully that's a good starting point for Monday's meeting...
René Spronk (Feb 23 2020 at 09:26):
Indeed, a subscription could also be to something which need not be expressible in FHIR. However, a messaging trigger event has a pre-agreed upon business expectation, which isn't the case IMHO when it comes to subscriptions. (Maybe it is, messaging after all has an implicit subscription mechanism).
Given that FHIR subscriptions were initially modeled as queries (as they were in v3, and are in v2) - which means the subscriber is in full control as to what they subscribe to and also what they plan to do with the data if and when they receive it - I hesitate to assign a lot of 'business expectations on the part of the event publisher' to subscription events.
By moving to subscription topics (which need not be expressible in FHIR) we may have pushed the subscription mechanism much more into the messaging space.
Brendan Keeler (Feb 23 2020 at 17:21):
Much of the messaging we're doing at Redox is as Jean notes, translating HL7V2 events into FHIR bundles.
I agree with others that Josh's initial problem seemingly isn't necessarily a Messaging problem, but a "how do I express this in FHIR" problem
Josh Mandel (Feb 24 2020 at 14:47):
I was trying specifically to come up with an example that was just "here's my message" without a deep tie into FHIR modeling, so I'm glad to have stimulated the discussion!
Regarding v2 examples @Brendan Keeler maybe there's another angle that would help elucidate behaviors. Do your v2 notifications always come with details indicating what changed? For example if you are sending a message that is a notification of a change of patient address, do you have a way to supply just the address? Do you send along a full patient resource but only populate the address? How do you indicate which previous address is being replaced? All this kind of thing...
Vassil Peytchev (Feb 24 2020 at 15:07):
Well, that's one of the reasons why the discussion on what is messaging is taking place. I think what you are describing is a notification between/among tightly coupled systems. Just sending the change of address assumes that there is already established common patient object, and and established "source of truth" that will enable such a notification. That could be a particular flavor of messaging, or maybe a different "notification" (tied to/similar to subscription notification?).
In V2, there is no such thing - the full information is sent to indicate the change of address, and right now, as far as I can tell, FHIR messaging follows the same overall pattern - all resources relevant to the event in the message are contained in the message...
René Spronk (Feb 24 2020 at 15:11):
Indeed. Loosely coupled, server side orchestration. So you'd better send a snapshot of everything that could be relevant in the context of the trigger event. If, when and what a receiver processes is up to the receiver.
Josh Mandel (Feb 24 2020 at 15:17):
Explaining the event makes sense, and sending a snapshot makes sense. I'm wondering about cases where untangling exactly what happened might not be entirely evident from just the snapshot (especially for receivers without have recently joined a network and don't have history). I guess sending a complete previous state snapshot and a complete post-state snapshot of what's missing anything... Giving the receiver access back to a versioned store in the sender.
René Spronk (Feb 24 2020 at 15:19):
Messaging is about the here-and-now, who cares about a previous state? As a receiver one can't even assume one has access (via REST, messaging or otherwise) to a sender, let alone that such a sender would support versioning..
Josh Mandel (Feb 24 2020 at 15:20):
then I guess sending complete pre and post snapshots is the only way to communicate the full event under those circumstances.
Josh Mandel (Feb 24 2020 at 15:21):
Outside of a few data types where there are ways to flag inline the fact that something is no longer current (like Address.use)
René Spronk (Feb 24 2020 at 15:22):
Could you explain as to why you need the 'pre' ? If the trigger event says 'discharged' it's pretty clear (implicitly) what the previous state was, even if the receiver wasn't aware of that previous state.
René Spronk (Feb 24 2020 at 15:27):
And yes, there are interesting problems with snapshot behavior: trigger "modification of list of allergies" message1 contains all of the allergies I know (4 of them), and a later messag2 contains only 2 allergies. The receiver will have to somehow deduce that 2 allergies have been removed from the list. This requires the use of provenance and replacement of the 'snapshot as a whole' - delete all allergies that were send by application X, replace by a new list of allergies as send by X. But don't touch allergies as sent by Y, because message1 nor message2 will have included those in the snapshot they're sending. But in general the "here's what's happening now" approach of messaging works just fine.
Brendan Keeler (Feb 24 2020 at 15:38):
Just to confirm, we're sending the full snapshots. EVN segment in HL7v2 is and was never good enough to really tell you what things changed.
Josh Mandel (Feb 24 2020 at 18:51):
pretty clear (implicitly)
Yeah, pre/post snapshots would be used to make this explicit, for just the kinds of "interesting" cases you describe.
Vassil Peytchev (Feb 26 2020 at 22:26):
I am a bit confused with the resolution of FHIR#26368 - I was at 3/4 of the call, and I don't recall when it was discussed (it must have been after I dropped off).
But my confusion is about the resolution itself - the Parameters resource is Normative, yet the "relaxation" of the language drastically changes the use of Parameters. While the question prompting the raising of the specific Jira issue may be sufficient reason to relax the language, I am far from convinced that it actually is a sufficient reason, and even it it were, I would rather see the change in the description to be specifically for the use of Prameters with MessageHeader...
Can I request that the issue is re-opened until after we go through our further discussions regarding Messaging, Subscription, (Subscription)Notification, etc.?
Grahame Grieve (Feb 26 2020 at 23:49):
I'm not sure what changed that much
Vassil Peytchev (Feb 27 2020 at 01:27):
The original text clearly restricted the use of Parameters as the input to operations.
This resource is a non-persisted resource used to pass information into and back from an operation. It has no other use, and there is no RESTful endpoint associated with it.
Josh Mandel (Feb 27 2020 at 02:04):
We did talk through this issue in depth on the call and arrive at the resolution you cited. Is a specific concern you have about it? (to be clear, it is excellent having you on these calls and would love your feedback.)
Vassil Peytchev (Feb 27 2020 at 03:05):
I have multiple issues. On the general level, going from:
-
This is Item A and its only purpose is X (Normative)
to -
This is item A and it can be used anywhere (as an embedded resource, for example).
is a big substantive change, IMO.
On the specific level, referencing Parameters in MessageHeader, I don't believe there is agreement, or even sufficient discussion on whether that is a good idea. It is possible that the upcoming weeks can bring changes to the guidance on use for messaging and subscriptions, where the application of Parameters may be not necessary, or it may turn out Parameters needs to be referenced from a different resource. Once we have clarity, and there is a clear need to relax the constraints, then my preference would be to from
-
This is Item A and its only purpose is X
to -
This is Item A and its purposes are X and Y
Josh Mandel (Feb 27 2020 at 03:38):
Okay, this helps, thanks. The concern about "normative" content here seems less stark to me, given our versioning rules (http://build.fhir.org/versioning); generally allowing a resource to be used in additional contexts is acceptable.
If you want to open an issue to discuss further, that's okay. I don't think I share your concerns though.
Lloyd McKenzie (Feb 27 2020 at 03:58):
The expansion of use shouldn't break any existing system, I don't think?
Grahame Grieve (Feb 27 2020 at 06:16):
well, part of the problem is what's an operation? It's being used as input to operations, but that doesn't just mean RESTful operations. And if it appears in a message or subscription or something, it's till input/output for an 'operation'
Vassil Peytchev (Feb 27 2020 at 15:27):
Lloyd McKenzie said:
The expansion of use shouldn't break any existing system, I don't think?
Usually the expansions that won't break any systems are of the type
reference -> Practitioner changes to reference -> Practitioner | PractitionerRole
In this case it could be argued that the change actually modifies an implicit invariant in that wherever you had Reference(Any) , it was "any resource, except for Parameters". With the change, the invariant is no longer valid.
Grahame Grieve said:
well, part of the problem is what's an operation? It's being used as input to operations, but that doesn't just mean RESTful operations. And if it appears in a message or subscription or something, it's till input/output for an 'operation'
The original text explicitly linked to http://hl7.org/fhir/operations.html as the definition of operation. If messages and subscriptions need to be considered as special cases of operations, then updating that page to say so will satisfy the perceived need to expand the use of Parameters, without relaxing anything in the Parameters definition. This is in line with my view that expanding the use of Parameters needs to follow the specific use case(s) that we agree on, and not introduce general and vague language ("primarily used?") so as to not be helpful.
As per Josh's suggestion, issue FHIR#26390 created.
Lloyd McKenzie (Feb 27 2020 at 16:35):
Relaxing invariants is allowed. Our expectation is that old instances will still be valid, not that old systems will always be able to consume new instances
Vassil Peytchev (Feb 27 2020 at 16:52):
Invariants, regular expressions, fixed values and patterns will not be added, removed or changed.
Is this limited to only values, and not references?
Lloyd McKenzie (Feb 27 2020 at 17:10):
I would say that this line: "Additional data types may be added to elements which are already expressed as a choice of data types only if those elements are optional (minimum cardinality = 0)." applies to references, though some clarification would be in order. I'd certainly expect the list of choices allowed for a reference to be able to grow over time. (Particularly essential if a new resource is defined that is relevant for a Reference).
Vassil Peytchev (Feb 27 2020 at 17:28):
Yes, the list of references is allowed to grow over time, but in this case there was a blanket prohibition present. It is a very unusual situation, due to the "special" nature of the Parameters resource. In case I wasn't clear before, I am not opposed to allowing Parameters in other cases, as long as the cases have clear boundaries.
Last updated: Apr 12 2022 at 19:14 UTC
