FHIR Chat · fullUrl and MessageHeader.id · implementers

Stream: implementers

Topic: fullUrl and MessageHeader.id

Patricia Alves (Mar 29 2016 at 09:12):

Hi, can u please help me on this question? When I send a json message with a bundle where the first entry is a MessageHeader, I set the entry.fullUrl to "urn:uuid:49c843ba-5686-4549-93c8-afb8c8d2c1ea" and the entry.resource.MessageHeader.id to "49c843ba-5686-4549-93c8-afb8c8d2c1ea", but then the HAPI validator deletes the entry.resource.MessageHeader.id, is this normal?

James Agnew (Mar 29 2016 at 13:44):

Hi Patricia, do you mean like you're sending it to a HAPI server and the server is deleting the ID? Or something else?

Lloyd McKenzie (Mar 29 2016 at 13:56):

Deleted

Patricia Alves (Mar 29 2016 at 14:03):

Yes, i'm sending to a HAPI server

Patricia Alves (Mar 29 2016 at 14:03):

and it deletes the iD

James Agnew (Mar 29 2016 at 14:42):

HAPI treats UUID IDs on resources it receives as being placeholders, and replaces them with the appropriate permanent ID. The idea is that if you want to send in a bunch of resources with links to each other but you don't yet know what the IDs for those resources will be, you can use placeholder UUIDs as a substitute. There's an example of this here: http://jamesagnew.github.io/hapi-fhir/doc_rest_client_examples.html#Transaction_With_Placeholder_IDs

What are you trying to achieve? Do you want the resource to actually be stored with that UUID?

Richard Ettema (Mar 29 2016 at 14:54):

@James, I believe Patricia is implementing a fhir messaging paradigm, not transaction. In the fhir messaging definition on MessageHeader Identifiers - http://hl7-fhir.github.io/messaging.html#2.4.1.3 - the purpose of the MessageHeader.id is "Each time a new message is created, it SHALL be assigned an identifier (MessageHeader.id) that is unique within that message stream. ... This can be achieved by using a UUID or an OID." Also, "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."

Richard Ettema (Mar 29 2016 at 14:54):

So, from my understanding within the context of fhir messaging, the MessageHeader.id value should not be considered a "placeholder" value.

Patricia Alves (Mar 29 2016 at 14:57):

That's correct @Richard, I just want to give an ID to the resource like you describe. And since I saw the use of "urn:uuid" in this example (http://hl7-fhir.github.io/message-request-link.json.html) I also used it in my message. I don't want it to be a placeholder.

Patricia Alves (Mar 29 2016 at 16:04):

So, is it normal in the messaging context that the MessageHeader.id is removed?

James Agnew (Mar 29 2016 at 16:41):

Can you describe exactly what you're doing? HAPI's server doesn't do any messaging out of the box so I'm having a bit of trouble picturing what this issue is..

If you're just creating a resource and using the parser to serialize it, the ID shouldn't be removed. If you're posting it to fhirtest.uhn.ca though it is probably being treated as a transaction and not a message though, so placeholder ID rules would be applied. I may not be understanding what you're up to though.

Richard Ettema (Mar 29 2016 at 16:42):

@Patricia, no, it is not normal. The fhir messaging context is designed to utilize the MessageHeader.id in both the request and response as described in MessageHeader Identifiers section of the specification. In addition, the very next section after that, Absence of Reliable Messaging - http://hl7-fhir.github.io/messaging.html#reliable, goes into further details and consequences regarding the use of both the Bundle.id and MessageHeader.id.

Richard Ettema (Mar 29 2016 at 16:48):

@Patricia, are you posting your message to the $process-message operation? The FHIR DSTU2 specification re-defined the messaging interface to now use the $process-message operation. The FHIR DSTU1 and earlier used 'mailbox'.

Richard Ettema (Mar 29 2016 at 17:03):

James' question is very appropriate. It would help to understand what issue/problem you are attempting to solve/implement via the fhir messaging paradigm. To make matters even more interesting, FHIR now has an Extended Operations framework or architecture - http://hl7-fhir.github.io/operations.html - that may be potential fit for what you wish to implement.

Patricia Alves (Mar 30 2016 at 11:08):

I'm using FHIR DSTU2 and the message is being posted to the $process-message operation. What I'm doing is to send the json message to a fhir server, which serializes the message to xml. That's when the ID is removed, since I did not replace the placeholder by anything. I can post the code if you need.

James Agnew (Mar 30 2016 at 14:15):

Can you describe this server more? Like, is this a server you wrote, or one of the public test servers? If it's a HAPI server of your own creation, it might be worth adding logging to see if the ID makes it in but is lost on the way out, or if it doesn't even make it in...

Patricia Alves (Mar 31 2016 at 08:08):

Sure and thank you very much for your time. It is a server written by us and we already had logging, and what happens is what you described: "the ID makes it in but is lost on the way out..."

James Agnew (Mar 31 2016 at 12:25):

Is the handler method in your server short enough you could paste it in? I'd love to see if I can reproduce this in a unit test...

Patricia Alves (Apr 01 2016 at 13:27):

It's not very short, but I can try to resume. I'll post in a moment.

Patricia Alves (Apr 05 2016 at 09:43):

Hi @James, sorry for the late answer, but I had some mandatory issues to solve. The ID is lost after parsing the resource (in the serialization-deserialization process):

var parser = inboundFormat.toUpperCase() == "XML" ? ctx.newXmlParser(): ctx.newJsonParser();
var hapiResource = parser.parseResource(Packages.ca.uhn.fhir.model.dstu2.resource.Bundle, msgString);
var x = parser.setPrettyPrint(true).encodeResourceToString(hapiResource);
logger.debug("x-> " + x);

James Agnew (Apr 05 2016 at 10:57):

Does the ID remain in the Bundle.entry.fullUrl field? I just had a go at this with a unit test:

        Patient p = new Patient();
        p.addName().addFamily("FAMILY");
        p.setId("urn:uuid:4f08cf3d-9f41-41bb-9e10-6e34c5b8f602");

        ca.uhn.fhir.model.dstu2.resource.Bundle b = new ca.uhn.fhir.model.dstu2.resource.Bundle();
        Entry be = b.addEntry();
        be.setResource(p);
        be.getRequest().setUrl(p.getId().getValue());

        String output = ourCtx.newXmlParser().setPrettyPrint(true).encodeResourceToString(b);
        ourLog.info(output);

        ca.uhn.fhir.model.dstu2.resource.Bundle parsedBundle = ourCtx.newXmlParser().parseResource(ca.uhn.fhir.model.dstu2.resource.Bundle.class, output);
        Entry parsedEntry = parsedBundle.getEntry().get(0);

        assertEquals("urn:uuid:4f08cf3d-9f41-41bb-9e10-6e34c5b8f602", parsedEntry.getRequest().getUrl());

and this passes. The parsed patient.getId().getValue() does not contain the UUIID though, which I think is confusing. The parser should be taking care of that, and possibly this is what's causing your issue. As a workaround until we get that fixed, can you grab the ID from Bundle.entry.request.url?

Patricia Alves (Apr 05 2016 at 15:15):

Yes, the Bundle.entry.fullUrl ID is maintained . The test you made was for the URL, can you please test for the resource.id? parsedEntry.getResource().getId().getValue(). It should be equal to 4f08cf3d-9f41-41bb-9e10-6e34c5b8f602. But if you check the prettyPrint for the parsedEntry it does not have that element (Patient.id).

James Agnew (Apr 05 2016 at 19:00):

Yeah, I added that test and it did indeed not pass. That is a bug in HAPI, or at least something that I would agree doesn't work the way it should.

It is fixed in the latest trunk HAPI, so this will work the way you want in HAPI 1.5 which will be released with a week or so.

Patricia Alves (Apr 06 2016 at 11:02):

That's great! Thank you very much! =)

Last updated: Apr 12 2022 at 19:14 UTC