Stream: implementers
Topic: FHIR Message identifiers
Kevin Mayfield (Nov 02 2020 at 08:59):
I'm a bit confused around the use of identifiers.
Kevin Mayfield (Nov 02 2020 at 09:01):
Official guidance mentions the use of Bundle.id and MessageHeader.id https://www.hl7.org/fhir/messaging.html#3.4.1.4 I'm presuming this is meant to be identifiers not id.
This matches a page on simplifier Profiling Academy section 1.4 of https://simplifier.net/guide/ProfilingAcademy/FHIRmessaging
MessageHeader doesn't have identifier?
Kevin Mayfield (Nov 02 2020 at 09:02):
Both refer to id, is that correct? Should it not read identifier.
Kevin Mayfield (Nov 02 2020 at 11:27):
In addition.
MessageHeader.responese.identifier points to an id type. I'm presuming this is meant to refer to Bundle.identifier and should have the same data type, so an identifier.
This is a fault in the specification?
Lin Zhang (Nov 02 2020 at 13:57):
@Kevin Mayfield Possibly helpful discussion: http://build.fhir.org/resource.html#identification
Lloyd McKenzie (Nov 02 2020 at 14:06):
MessageHeader.response.identifier will refer to the Bundle.identifier of the original message. Agree that the wording is confusing - can you submit a change request to make it clearer we're talking about 'identifier'?
Kevin Mayfield (Nov 02 2020 at 14:15):
@Lloyd McKenzie Thanks will do.
Vassil Peytchev (Nov 02 2020 at 15:14):
Is this indeed the intent? The definition of MessageHeader.response.identifier states:
The MessageHeader.id of the message to which this message is a response.
All the discussion in 3.4.1.4 seems to be explicitly about .id, not .identifier.
Kevin Mayfield (Nov 02 2020 at 16:52):
I've taken it to mean identifier. To replace MessageHeader.id and I've created an identifier extension. Early draft profile
https://simplifier.net/guide/nhsdigitalspine/Spine-MessageHeader
Vassil Peytchev (Nov 02 2020 at 17:04):
I believe there was a deliberate decision NOT to have a MessageHeader.identifier. Adding an extension for that seems ill-advised. Changing the data type of MessageHeader.response.identifier on top of that, and now you have an incompatible IG that doesn't match any other implementation.
Lloyd McKenzie (Nov 02 2020 at 18:02):
Definitely you don't want an extension for identifier on MessageHeader. The identifier for a message is always Bundle.identifier.
Eric Haas (Nov 02 2020 at 19:07):
I read this as the id not identifier for both
Kevin Mayfield (Nov 03 2020 at 07:33):
resource.id seems ill suited as its transient and seems to go against rules for Bundles (plus it creates complications with libraries like HAPI).
I'm seeing the requirement for two types of message Identifiers:
- Correlation 'ID' - for use on multi hop/leg messages. i.e. A->B->C
- Request/Message 'ID' - for use on individual legs. These legs may use different transports (http and message queue) and payloads differ slightly. In the scenario I'm working on, some of the legs are HL7v3 and it is probable the first leg is HL7v2.
These message identifiers may be the same and some may not practical for some legs/hops.
I'm happy to stick with Bundle.identifier as the request/message ID but I don't have a place for the Correlation ID. Probably useful to include prior request/message ID's in the message somewhere.
Kevin Mayfield (Nov 03 2020 at 07:43):
Thanks @Eric Haas for the link. Are you working on the US Da Vinci alerts? If so have you created any documentation on messageHeader.
Lokesh G S (Nov 03 2020 at 08:30):
Hi team , i have doubt on fhir audit events, how to set up it ? does it capture automatically? or do we write when an event is done?
Mareike Przysucha (Nov 03 2020 at 08:37):
Hi @Lokesh G S. This seems to be the wrong stream for your question, as this is a stream about FHIR Message identifiers. Please re-ask your question in a more fitting stream or make a new stream. Thank you.
Lokesh G S (Nov 03 2020 at 08:38):
No one is helping me what to do @Mareike Przysucha . Can you please tell me any person who can help me on audit events
Mareike Przysucha (Nov 03 2020 at 08:39):
Sorry, I mixed stream and topic. There is a topic "AuditEvents in pure FHIR Servers" in the implementers stream. Probably that is a better place.
Lokesh G S (Nov 03 2020 at 08:42):
Yes i did in AuditEvents in pure FHIR Servers but no one is replying
Mareike Przysucha (Nov 03 2020 at 08:44):
First: I will answer in that topic, not here any more.
Mareike Przysucha (Nov 03 2020 at 08:48):
sorry, this sounded more strict than it was meant to.
Lokesh G S (Nov 03 2020 at 08:50):
I understand it @Mareike Przysucha sorry for it
Kevin Mayfield (Nov 03 2020 at 11:16):
Lloyd McKenzie said:
Definitely you don't want an extension for identifier on MessageHeader. The identifier for a message is always Bundle.identifier.
Not sure if I agree. This works for point to point messages but it's not so straight forward for those going through a series of message channels.
I would want to use an identifier with a wider scope than just 'point to point' Bundle.identifiers. Which is why I'm thinking of a 'end to end' Correlation ID.
Eric Haas (Nov 03 2020 at 16:36):
The Alerts guide is published. The Bundle and MessageHeader ids are both required they are transacted using the $process-message operation. We have guidance on how intermediaries need to update them here. Here is the simulation of it: http://ehaas.pythonanywhere.com/
Lloyd McKenzie (Nov 03 2020 at 19:44):
@Kevin Mayfield A message passing through multiple endpoints may change Bundle.id, but should never change Bundle.identifier.
Kevin Mayfield (Nov 04 2020 at 07:18):
Thanks @Eric Haas I'll create a thread on #fhir-messages to track differences between Da Vinci and UK Core (currently know as Spine). I want to lean towards Da Vinci if possible.
Main difference i'm seeing at the mo is UK trend is leaning towards HL7v2 and to a lesser extent HL7v3 (but it's limited feedback at present)
Last updated: Apr 12 2022 at 19:14 UTC
