Stream: implementers
Topic: UUIDs vs "fake" URLs in Bundle resources
Rick Geimer (May 17 2017 at 17:45):
Hi all. I'm generating FHIR Bundle resources, in particular documents converted from C-CDA, and would like to hear opinions on best practice for entry.fullUrl. Since there is no FHIR server involved in the conversion process, I am currently generating UUIDs to identify each resource, so entry.fullUrl looks like this:
<fullUrl value="urn:uuid:df2a676b-d2a6-4bbe-87e6-de61e14f4958"/>
However, I'm considering moving to something like this instead:
<fullUrl value="http://example.org/not-a-fhir-server/Patient/1"/>
My question is, does this add value by identifying the resource as a Patient and allowing for relative references from the FHIR base of http://example.org/not-a-fhir-server, or does it imply a false promise that the patient is actually accessible at that URL? Would like to hear others thoughts on this.
Lloyd McKenzie (May 17 2017 at 17:55):
If the reference is inside a Bundle, you already know it's a Patient because you can resolve the reference without doing a query. A fake URL is going to prompt systems to try to resolve it, at least in some cases, which means you'd be triggering a performance hit. The recommendation is to use a UUID and I don't see any reason to not do that.
Rick Geimer (May 17 2017 at 18:00):
Thanks Lloyd. One other reason I am considering this approach is that I am using XSLT, and am currently using a Java extension to generate the UUIDs, whereas with the URL-based approach I can simply use generate-id() to create resource ids that are unique within the Bundle.
Lloyd McKenzie (May 17 2017 at 18:22):
I'd stick with UUID. If it's a URL, the expectation is that it should be resolvable. Obviously servers go down, users don't have permissions, etc. But it's definitely supposed to be resolvable.
Ken Sinn (Oct 16 2017 at 17:37):
@Lloyd McKenzie Are UUIDs the preferred/only method to reference other resources within bundle? Are there any rules around the generation of a uuid for this purpose?
Ewout Kramer (Oct 16 2017 at 18:37):
No, you can use regular urls as well. Check the rules here: http://hl7.org/fhir/http.html#2.21.0.17.2
Lloyd McKenzie (Oct 17 2017 at 00:03):
If you're using a UUID, then normal UUID-generation rules apply - i.e. use an algorithm that should ensure global uniqueness. Good practice is for the same resource instance to have the same UUID if sent in multiple Bundles, but that's not a requirement.
Lloyd McKenzie (Oct 17 2017 at 00:03):
(But if the same UUID does appear in distinct Bundle instances, it should definitely be on the same resource instance :))
Ken Sinn (Oct 17 2017 at 15:27):
@Ewout Kramer Could you point me to an example of regular urls being used? Is this the "fake" URL as mentioned above? Again, this is in the case of a local resource within a bundle only.
Lloyd McKenzie (Oct 17 2017 at 16:57):
If the identifier is only valid within the scope of the bundle, then it needs to be a UUID. If you used URLs, the expectation is that they would resolve outside the Bundle to the resource.
Ken Sinn (Oct 17 2017 at 17:50):
Thank you @Lloyd McKenzie !
Ewout Kramer (Oct 18 2017 at 09:30):
Take a look at http://hl7.org/fhir/bundle-transaction.xml.html.
If a bundle would contain a fullUrl " <fullUrl value="http://example.org/fhir/Patient/123"/> " like it does here and other may reference it. However, if the entry.request.method would be a POST, it would get assigned a new id (you might not even be http://example.org) - and all references to this fullUrl in other parts of the bundle would get updated to this new id. It is not necessary for the fullUrl to be a UUID in this case - though it is user friendlier since it clearly indicates this is a "new" resource.
Brian Postlethwaite (Nov 10 2017 at 11:31):
Yes, if the resource is created by the bundle, then the refs in the bundle also need to be updated.
So this needs to be careful of the order of processing...
Last updated: Apr 12 2022 at 19:14 UTC
