Stream: implementers
Topic: Bundle.entry.fullUrl - no RESTful endpoint
Jonny Rylands (Mar 17 2020 at 13:39):
Is it legal to omit the Bundle.entry.fullUrl element where there is no RESTful read endpoint to independently retrieve the resource?
Kevin Mayfield (Mar 17 2020 at 13:42):
https://www.hl7.org/fhir/bundle.html#bundle-unique no it isn't
Jonny Rylands (Mar 17 2020 at 13:45):
That seems to contradict https://www.hl7.org/fhir/bundle-definitions.html#Bundle.entry.fullUrl "The fullUrl element SHALL have a value except that"
Jonny Rylands (Mar 17 2020 at 13:47):
If it is required, what can/do you populate when you don't have a RESTful read endpoint to retrieve the resource from?
Kevin Mayfield (Mar 17 2020 at 13:49):
I've never used it to read from a rest endpoint. I have used it a lot when creating or processing messages and responding to complex rest queries - it was invaluable.
Lloyd McKenzie (Mar 17 2020 at 13:56):
If the resource isn't available from a RESTful endpoint, you use urn:uuid:.....
Jonny Rylands (Mar 17 2020 at 14:02):
Thanks @Lloyd McKenzie . But you can continue to use your 'original' ids in Resource.id and references that point to it? e.g. Organization.id = 123 Patient.managingOrganization = Organization/123 Just wondering what the purpose of the fullUrl UUIDs are if nothing points to them, and the resources aren't retrievable by them?
Lloyd McKenzie (Mar 17 2020 at 14:13):
References resolve based on the fullURIs. The resource ids are ignored when resolving references, though I can't think of a reason why they should differ from the GUIDs in the fullURLs.
Jonny Rylands (Mar 17 2020 at 14:30):
OK thanks.
Vassil Peytchev (Mar 17 2020 at 16:38):
I think the description and definition is quite confusing. Is it implying that if the resource is not available through a restful endpoint, the fullUrl SHALL be an UUID in urn format? This says "should"...
Vassil Peytchev (Mar 17 2020 at 16:47):
Eric Haas (Mar 17 2020 at 21:35):
though I can't think of a reason why they should differ from the GUIDs in the fullURLs.
Why bother changing the ids to the uuid if they are transient anyway. For example, I assemble a message bundle and retain the existing ids, The references all resolve using the FullUri and UUIDs. If the recipient chooses to store the data as FHIR resources may use their own ids anyway.
Lloyd McKenzie (Mar 17 2020 at 21:41):
If the data is transient, then there isn't an I'd to change.
Eric Haas (Mar 17 2020 at 21:48):
I meant the ids are transient- in other words server dependent.
Lloyd McKenzie (Mar 17 2020 at 21:52):
Server ids that aren't tied to RESTful URLs aren't really relevant to expose. Having the id convey something other than the GUID of the fullURL isn't going to create any application awareness of what the server's internal id and result in recognition the instance is the same, for instance. If the fullURL is the same across messages, that indicates it's the same instance. The resource.id being the same would be ignored.
Eric Haas (Mar 17 2020 at 22:41):
After reading your response, I'm still confused... what is an example where the fullUrl and id need to match or things go awry?
Lloyd McKenzie (Mar 17 2020 at 23:05):
It's just confusing to people when they don't. In practice, the id is required, but also gets ignored. When you set it to something other than the GUID, it's just a recipe for making developers debugging instances bang their heads.
Jonny Rylands (Mar 20 2020 at 11:36):
@Lloyd McKenzie On this point "If the resource isn't available from a RESTful endpoint, you use urn:uuid:.....". Is that a MUST or a SHOULD in terms of FHIR spec compliance? Thanks.
Jonny Rylands (Mar 20 2020 at 12:41):
(Background: we have a FHIR operation returning a self contained Bundle (i.e. all references can be resolved within the Bundle) and so the fullUrls do not need to be resolved externally. We would rather not force the use of UUIDs as the systems the interface will sit in front on don't store UUIDs and would rather not use ephemeral UUIDs)
Lloyd McKenzie (Mar 20 2020 at 15:29):
It's not a question about "do not need to be". If they can be resolved externally, then use RESTful URLs. It's fine if everything resolves inside the Bundle - the receiving system might still want to query or update the source later. On the other hand, if there is no RESTful endpoint, then it's wrong to pretend there is one. If there's no RESTful endpoint, you should be using UUIDs.
Cooper Thompson (Mar 23 2020 at 13:59):
Do we have any guidance on how servers should handle fullUrl when it doesn't know if (or how) the client can access the RESTful endpoint? fullUrl is pretty annoying for us (Epic) since our FHIR server is often running behind an API manager, reverse proxy, load balanced VIP, WAF, and other network intermediaries. The main problem we face is that our FHIR server doesn't know the hostname that the client uses to reference our FHIR server (the hostname the client sees is the reverse proxy hostname, not the FHIR server host). We can generate a resolvable relative URL (which we do for references), but generating an absolute URL is a pain.
Paul Church (Mar 23 2020 at 14:07):
I ran into the same problem with a Google Cloud endpoint behind a proxy. We tried having the proxy do a regexp replace of the underlying endpoint's URL with the proxy's URL, on both incoming and outgoing payloads. Worked as a prototype solution but it tightly couples the outermost layer of proxy to the FHIR store and would have to think pretty carefully before deploying that in a production application.
Cooper Thompson (Mar 23 2020 at 14:41):
Yeah - one additional wrinkle is that often we have a single logical FHIR server that is accessible via multiple different DNS names depending on the client. E.g. public/internet clients vs. internal/LAN clients.
Paul Church (Mar 23 2020 at 17:45):
We have the additional issue that the actual fullUrl of a GCP FHIR store is an infrastructure backend that the application might not want to expose to clients - it contains a GCP project name, an API version, and other resource names. Developers might want to migrate some of those things without making the migration visible to the client.
I don't think we have a great solution yet but I'll keep an eye on how users deal with the issue.
Lloyd McKenzie (Mar 23 2020 at 19:15):
If the endpoint isn't intended to be visible, then just assign a GUID and use urn:uuid: - the same as you would for a system that didn't have a RESTful URL at all. What to do where the RESTful URL depends on who's looking is more challenging...
Vassil Peytchev (Mar 23 2020 at 19:34):
It is not that the endpoint isn't intended to be visible, it is that the endpoint is managed by a "presentation layer" that is removed from and independent from the FHIR sever itself.
Matt Stephens (Mar 24 2020 at 11:30):
"then just assign a GUID and use urn:uuid" - Why? This seems far from practical, not every supplier uses GUIDs as an identifier and they'll need to create another identifier just for this purpose, this will be even worse if the GUID is expected to be persistent as they would need to store it. I don't think fullUrl has been specified well from a practical point of view, this thread alone haas highlighted this.
Lloyd McKenzie (Mar 24 2020 at 13:23):
The GUID only needs to be valid for the Bundle - it doesn't need to be stored/retained by the sender. FullURL is very simple. It's the RESTful URL where the resource can be retrieved/manipulated. If there isn't one of those, then it needs to be urn:uuid:[some guid].
Jonny Rylands (Mar 24 2020 at 15:24):
If the server generates GUIDs on the fly for each Bundle response, the client isn't able to identify the same resource twice. Unless Resource.id uses a persistent identifier and not an on the fly GUID. But that would not be very pretty having fullUrl and references using GUIDs, and Resource.id using something else.
Lloyd McKenzie (Mar 24 2020 at 15:30):
Right. If there's no RESTful id, then resource.id is useless for identifying the resource across instances - you need to rely on the .identifier element
Vassil Peytchev (Mar 24 2020 at 15:37):
In such case, sounds like if there is no referencable fullUrl, identifier must be present. Is that currently the case?
René Spronk (Mar 24 2020 at 15:47):
That would be nice. But in real life, lots of things don't have solid identifiers.
Vassil Peytchev (Mar 24 2020 at 15:54):
René Spronk said:
That would be nice. But in real life, lots of things don't have solid identifiers.
Yet every FHIR resource that has a RESTful end point, must have a "solid" id. If the spec requires this part, why is it considered unreasonable to require "solid" identifiers for resources in a Bundle without a RESTful endpoint?
René Spronk (Mar 24 2020 at 15:59):
Do all 'socks' that you put in a gym locker have their own identifier? No. The locker does have a unique identifier. Socks may only be known as 'blue sock, size 42' - that's hardly unique.
René Spronk (Mar 24 2020 at 15:59):
Your IG could define identifier as a SHOULD. But SHALL is totally unrealistic in almost all contexts.
Lloyd McKenzie (Mar 24 2020 at 16:00):
identifier doesn't have to be present. If it's not, then you're either unable to match or have to match by other elements (demographics for patient, time and code for Observations, etc.)
Lloyd McKenzie (Mar 24 2020 at 16:01):
The base FHIR spec can't require what systems don't support. Profiles can certainly tighten expectations where they think that 'better' behavior is achievable.
Vassil Peytchev (Mar 24 2020 at 16:15):
René Spronk said:
Do all 'socks' that you put in a gym locker have their own identifier? No. The locker does have a unique identifier. Socks may only be known as 'blue sock, size 42' - that's hardly unique.
This is an excellent argument for using contained resources, not necessarily entries in a bundle :wink:
Vassil Peytchev (Mar 24 2020 at 16:17):
René Spronk said:
Your IG could define identifier as a SHOULD. But SHALL is totally unrealistic in almost all contexts.
SHALL in an IG is very realistic. What is not realistic is matching by other elements to determine equivalence - been there, done that, affects patient safety.
Vassil Peytchev (Mar 24 2020 at 16:18):
Lloyd McKenzie said:
The base FHIR spec can't require what systems don't support. Profiles can certainly tighten expectations where they think that 'better' behavior is achievable.
Agreed. Proper guidance, however, is essential.
Lloyd McKenzie (Mar 24 2020 at 16:34):
Resources without an identifier don't necessarily need to be 'contained'. The reality is that lots of the stuff passed around in messages and documents won't have identifiers - and won't be contained. It will also be painful to try to match to resources that are outside of the message/document. That's a world we've lived in in the CDA space and even v2 for a long time. FHIR doesn't magically make that issue go away
Cooper Thompson (Mar 25 2020 at 18:56):
It would be nice if you could just send a "fullUrl" that was a hash of (FHIR server logical identifier + resource type + resource ID), however that doesn't qualify as a UUID I believe. Is there a reason the only other option for fullUrl is a UUID, rather than some other sort of unique identifier?
Last updated: Apr 12 2022 at 19:14 UTC
