Stream: fhir-messages
Topic: What goes in Subscription.focus
Eric Haas (Aug 14 2019 at 17:31):
The Da Vinci Alerts project is focused ( pun intended ) on Alert notifications using FHIR messaging, The definition of the element MessageHeader.focus allows for multiple interpretations...:
The actual data of the message - a reference to the root/focus class of the event
for the Requirements:
Every message event is about actual data, a single resource, that is identified in the definition of the event, and perhaps some or all linked resources.
The comments are not very helpful either since I don't know what "transaction type" means:
The data is defined where the transaction type is defined. The transaction data is always included in the bundle that is the full message. Only the root resource is specified. The resources it references should be contained in the bundle but are not also listed here. Multiple repetitions are allowed to cater for merges and other situations with multiple focal targets.
Resource are notes not much better and refer to list that does not exist.:
The actual content of the focus resource is specified for each message event (see the list on the messaging page). Any resources referenced in the focus element are always included in the bundle
So this leads to two way of implementing this:
- Defines all the required resources that need to be in the message and ignore MessageDefinition since this interpretation makes that totally redundant and it a lot simpler.
- Narrowly focused to a few key resources, for example, Encounter for admit notification and the use MessageDefintion to say what needs to go into the message Bundle.
There has been some discussion on this thread but is still not clear to us and I imagine to many others as well.
Eric Haas (Aug 17 2019 at 03:19):
@Brendan Keeler Redox seems to do it using option 1
note that this approach would imply that you would profile MessageHeader instead of using MessageDefinition
What are the advantages of MessageDefinition then:
- lighter weight assuming creating instances of MessageDefintion easier than creating instances of StructureDefinitions
Lloyd McKenzie (Aug 20 2019 at 03:10):
MessageHeader.focus must point only to the focus (or foci) of the specified event. Otherwise, the receiver doesn't know what the event is about. As an example, consider a message conveying a change (e.g. discharge) to an Encounter that, for one reason or another, also includes information about other encounters (sub-encounters, prior encounters, whatever). If the focus points to everything in the message, there'd be no clear way to figure out which of the encounters was the focus of the event.
There is no need for MessageHeader.focus to point to anything else other than the object of the event that triggered the message. Everything else in the message will be tied to the focus (foci) by relationship paths to and from the focal resource. There are only a few situations where you'd ever have more than one focus:
- if you were doing something like a merge - in which case each resource being merged would be one of the focuses
- if the message was reporting multiple events (e.g. here are all the reportable results for today), in which case each focus would be a distinct result
The boundary of what's included in the message vs. not is established by the MessageDefinition. Obviously the focus resources are included. Others are included as the graph in the MessageDefinition requires. The event code tells you what happened to the focus and the focus tells you what the event occurred to.
Eric Haas (Aug 20 2019 at 13:39):
Everything else in the message will be tied to the focus (foci) by relationship paths to and from the focal resource.
Is this strictly a requirement? what if I want to send some totally unrelated isolated resource ( say a binary of a picture of my cat ) as well in the message and I define in the Messagedefinition?
Lloyd McKenzie (Aug 20 2019 at 14:50):
It's a strict requirement - both for messages and documents. If you traverse all the relationships in all of the entries, the entire web must cling together. There can't be any non-connected nodes. If there are, it's an error. (And the validator currently checks this.)
Lloyd McKenzie (Aug 20 2019 at 14:58):
`The document bundle SHALL include only:
The Composition resource, and any resources directly or indirectly (e.g. recursively) referenced from it
A Binary resource containing a stylesheet (as described below)
Provenance Resources that have a target of Composition or another resource included in the document`
I can't see similarly clear wording for messages, but that's certainly the intent and is currently enforced. I've submitted GF#23722 to get clearer wording into the spec.
Last updated: Apr 12 2022 at 19:14 UTC
