Stream: fhir-messages
Topic: Absence of Reliable Messaging Documentation
Eric Haas (Jan 13 2020 at 00:26):
This section's doco is confusing ( suspect a typo ):
http://hl7.org/fhir/messaging.html#reliable
“Some of the message delivery mechanisms mentioned above are reliable delivery systems - the message is always delivered, or an appropriate error is returned to the source. However most implementations use methods which do not provide reliable messaging, and either the request or the response can get lost in transit. FHIR messaging describes a simple approach that receivers SHOULD conform to in order to handle the absence of reliable messaging that maintains predictable functionality.”
Where is this described??? ( I think is a type and should say…)
“... The following simple approach that receivers SHOULD conform to in order to handle the absence of reliable messaging that maintains predictable functionality.”
Also...
If there is a Bundle.identifier and, if added in the future as discussed here MH.identifier, do they change in a similar fashion and which one trumps the other if they do not?
how
Eric Haas (Jan 13 2020 at 00:28):
@Lloyd McKenzie ?
Lloyd McKenzie (Jan 13 2020 at 02:05):
Agree with the change to "following simple". Change request?
As for the second, ugh. This is why I think it's a bad idea to add stuff for modeling purity when from a requirements perspective, we've decided that something isn't desirable. We specifically yanked MessageHeader.identifier because it caused problems once Bundle.identifier got added.
@Grahame Grieve thoughts?
Grahame Grieve (Jan 13 2020 at 02:35):
I don't know. Purity is in the eye of the beholder
Lloyd McKenzie (Jan 13 2020 at 03:17):
Right - but you'd proposed adding identifier everywhere. This would be one of the places where doing that would have an unpleasant cost.
Eric Haas (Jan 13 2020 at 03:27):
Well right now there is Bundle.identifier and the spec gos on to say....
If the sender of the message implements reliable messaging, it SHALL do the following when it receives no response to a message within a configured timeout period based on the value specified in the CapabilityStatement messaging.event.category for the event associated with the message: Consequence Resend the same message (with the same MessageHeader.id) with the same Bundle.id Currency Resend the same message (with the same MessageHeader.id) with a different Bundle.id Notification Resend the same message (with the same MessageHeader.id) with a different Bundle.id
Grahame Grieve (Jan 13 2020 at 03:27):
it raises a question about whether the message header exists independently of the message
Eric Haas (Jan 13 2020 at 03:30):
so what about Bundle.identifier if present. I assume that should be the same and then what if Bundle.id is different?
Re
it raises a question about whether the message header exists independently of the message
in the MH scope section:
The principal usage of the MessageHeader resource is when messages are exchanged. However, as a resource that can be used with the RESTful framework, the MessageHeader resource has the normal resource end-point ([base-url]/MessageHeader), which is used to manage a set of static messages resources. This could be used to make an archive of past messages available.
Eric Haas (Jan 13 2020 at 03:31):
which suggests it can be....
Eric Haas (Jan 13 2020 at 03:37):
FYI I'm spit-balling overloading MH for subscriptions as a straw man as we try to tease out using Messaging for unsolicited notifications and Subscription Notifications proposal for a bundle type with some header like resource and Subscription messaging channel....
Eric Haas (Jan 13 2020 at 03:39):
but for the present the above guidance certainly suggests that the id should be profiled as min =1 for Bundles and MH for messaging use cases
Eric Haas (Jan 13 2020 at 03:41):
I will submit the tracker for the agreed on change above.
Last updated: Apr 12 2022 at 19:14 UTC
