Stream: implementers
Topic: MessageHeader.response.identifier
AbdulMalik Shakir (Mar 04 2019 at 21:02):
The definition of MessageHeader.response.identifier is "The MessageHeader.id of the message to which this message is a response. Note, this is a business identifier, not a resource identifier"
However, I do not see MessageHeader.id defined as an element of the MessageHeader. Am I missing something?
Grahame Grieve (Mar 04 2019 at 21:10):
yes it got moved to Bundle.identifier
AbdulMalik Shakir (Mar 04 2019 at 21:24):
"yes it got moved to Bundle.identifier
Thanks.
Lloyd McKenzie (Mar 04 2019 at 21:26):
AMS, can you submit a change request for us to correct the wording on MessageHeader.response.identifier?
AbdulMalik Shakir (Mar 04 2019 at 22:31):
AMS, can you submit a change request for us to correct the wording on MessageHeader.response.identifier?
Lloyd, I would be happy to submit a change request. Do you have a minute or two to show me how that is done?
Richard Townley-O'Neill (Mar 04 2019 at 22:51):
At the bottom of the resource definition page is a link to Propose a change. Follow the link to gforge, and use the New Tracker Item button.
Ken Sinn (Jun 11 2019 at 22:42):
For clarification, should MessageHeader.response.identifier be typed as identifier instead of id? The description of the field as a "business identifier" instead of a "resource identifier" makes me think it should be the identifier type.
Lloyd McKenzie (Jun 11 2019 at 22:45):
The 'system' for the MessageHeader identifier is known. It must have a value. There doesn't seem to be a good reason to move from 'id'.
Ken Sinn (Jun 12 2019 at 19:19):
Is the correct wording for "MessageHeader.response.identifier" supposed to be "The Bundle.identifier of the message to which this message is a response. Note, this is a business identifier, not a resource identifier"? Or is MessageHeader.response.identifier supposed to be some other value?
Lloyd McKenzie (Jun 12 2019 at 19:24):
It seems that it should be Bundle.id, though that makes the "this is a business identifier, not a resource identifier" assertion questionable. If we were to point to bundle.identifier, that would make the MessageHeader.response.identifier data type wrong. @Grahame Grieve ?
Ken Sinn (Jun 12 2019 at 19:36):
Is there a "business identifier" for the MessageHeader somewhere? Or is it considered redundant by the Bundle.identifier value?
Lloyd McKenzie (Jun 12 2019 at 21:13):
We dropped it (in STU3 I think) on the grounds that it was redundant with Bundle.identifier which got added in the same release.
Grahame Grieve (Jun 14 2019 at 02:07):
the definition and the type are consistent, and refer to the bundle id, not the Bundle.Identifier. This assumes that the bundle.id is unique in the context. If we were to change it to Bundle.identifier (which didn't exist earlier) then we'd have to change the type too
Lloyd McKenzie (Jun 14 2019 at 03:01):
The usage note on MessageHeader.response.identifier says This is a business identifier, not a resource identifier. That seems to be in conflict with it pointing to Bundle.id. (I'm totally fine with it pointing to Bundle.id, we should just be clear.)
Ken Sinn (Jun 28 2019 at 15:52):
We have a use case for having a MessageHeader.response.identifier be a business identifier, when you want to relate a series of Messages together using the same reference identifier (even if it's based on Bundle.identifier), rather than just the immediately previous MessageHeader.id. Based on Bundle.identifier definition, Bundle.identifier does not seem to be the right place to store a business identifier that would be the same across a series of Messages.
We're okay with creating an extension on MessageHeader if necessary, but seems like there was already some thought put into using MessgeHeader.response.identifier for this purpose, based on the definition (though not on the element type).
Grahame Grieve (Jul 03 2019 at 23:26):
we have not created an element on MessageHeader for an identifier that links a series of messages. If we did, I would ave called it "MessageHeader.conversationId". So that would be an extension (for now at least)
Ken Sinn (Jul 04 2019 at 16:41):
Thank you for the feedback, Grahame. We'll be implementing this as an extension, and look forward to supporting this as an element in the future, if others also find use for this element.
Geoff Ramsay (Jul 30 2019 at 18:13):
@Ken Sinn , We've found a few use cases in the Canadian eReferral space where we think a larger transaction identifier, or broker 'conversation identifier' would be helpful.
I've used an extension at this point.
I'd love to know/support if you push for inclusion.
Lloyd McKenzie (Jul 30 2019 at 18:30):
The "conversation" would presumably resolve around task. If the referral was part of a broader set of requests, then the requisition element would be appropriate.
Ken Sinn (Jul 30 2019 at 18:44):
Thanks @Geoff Ramsay , we will take a look at Lloyd's suggestion to use ServiceRequest.requisition, and see if the Message Bundles always include a ServiceRequest resource or not.
Ken Sinn (Nov 04 2020 at 14:26):
@Grahame Grieve @Lloyd McKenzie It looks like http://build.fhir.org/messaging.html#3.4.1.4 should also be changed, if messageheader.response.identifier is supposed to point to bundle.id?
"The response message also quotes the request MessageHeader.id in MessageHeader.response.identifier so that the source system can relate the response to its request."
Kevin Mayfield (Nov 04 2020 at 14:36):
See also https://chat.fhir.org/#narrow/stream/179166-implementers/topic/FHIR.20Message.20identifiers
Kevin Mayfield (Nov 04 2020 at 14:38):
@Ken Sinn did you implement a conversationID extension?
We (in the UK) have the same requirement
Ken Sinn (Nov 04 2020 at 14:45):
Thanks Kevin. The implementation stalled, so we did not have to implement the extension for now. Thanks for posting the other thread. I'll poke around in the fhir message stream, didn't know about that stream.
Lloyd McKenzie (Nov 04 2020 at 16:42):
MessageHeader.response.identifier should point to Bundle.identifier. Bundle.id could change in transit, Bundle.identifier won't.
Vassil Peytchev (Nov 04 2020 at 16:47):
MessageHeader.response.identifier should point to Bundle.identifier
That is a big change.
Lloyd McKenzie (Nov 04 2020 at 20:51):
I don't know there's a choice. The guidance is that if you touch the message in any way when routing, it's a new Bundle.id. And when the originator receives the response, it needs to be to an id they have, not that was created by routing jump #3.
Vassil Peytchev (Nov 05 2020 at 00:34):
But the current reference is to MessageHeader.id, not Bundle.id
Lloyd McKenzie (Nov 05 2020 at 02:52):
@Grahame Grieve Do you recall where we landed here? (In general, having identifier point to id is a bit odd)
Grahame Grieve (Nov 12 2020 at 10:28):
no I don't remember
Lloyd McKenzie (Nov 12 2020 at 14:11):
@Vassil Peytchev Can you raise a tracker item so we can get this landed?
Ken Sinn (Nov 12 2020 at 15:08):
How quickly do you think this will get sorted, @Lloyd McKenzie ? We're currently designing based on the as-written documentation of using ids and not identifiers for the response reference.
Lloyd McKenzie (Nov 12 2020 at 15:18):
Hopefully this year, but that's not a given.
Ken Sinn (Nov 12 2020 at 15:23):
Suggestions on best way to handle the design to be future-proof? Is pointing MessageHeader.response.identifier to Bundle.identifer pretty much the only solution? (which means Bundle.identifier becomes a required element for Message Bundles? Or something that's only required for implementations expecting a Message response?
Lloyd McKenzie (Nov 12 2020 at 15:37):
Pointing to Bundle.id is definitely not safe - the Bundle.id will change has the message propagates from server to server. Pointing to MessageHeader.id could be safe, but it's a bit messy because MessageHeader.id is only unique within the context of a particular originating server. While typically these would be UUIDs, I don't think that's a requirement. If the MessageHeader instances flowing through a given system originate from different places, duplicate ids are possible (though presumably the fullUrl for the MessageHeader entry would still be unique). MessageHeader.identifier got moved to Bundle.identifier, so it certainly seems logical that the acknowledgement would point to that element. However, the decision isn't mine and I can't guarantee that InM will land the same place I do.
René Spronk (Nov 12 2020 at 15:59):
IMHO It'd need to be an identifier, and not an id. Bundle.identifier seems appropriate.
Kevin Mayfield (Nov 12 2020 at 21:21):
Presume we'd need an identifier extension?
Lloyd McKenzie (Nov 12 2020 at 22:31):
Why an extension?
Vassil Peytchev (Nov 13 2020 at 14:35):
FHIR#29690 created
Kevin Mayfield (Nov 13 2020 at 15:37):
You are using identifiers to reference each other?
Ken Sinn (Nov 19 2020 at 18:24):
Unfortunately, since MessageHeader.response.identifier is typed as "id" at the moment, our implementation will be referencing the MessageHeader.id of the originating message bundle -- until the next release with the data type updated.
Last updated: Apr 12 2022 at 19:14 UTC
