Stream: implementers
Topic: Reference to a "Search" result
Josh Mandel (Jan 03 2018 at 15:51):
I recently came across a FHIR server where the Reference.reference values were populated with search strings like Patient?identifier=123. I'm pretty sure this isn't allowed, but there was some confusion. The developer also pointed out the following note from http.html:
in a transaction (and only in a transaction), references to resources may be replaced by a search URI that describes how to find the correct reference:
... <reference value="Patient?identifier=12345"/>
Now that we have Reference.identifier, couldn't this special-case rule go away?
Lloyd McKenzie (Jan 03 2018 at 16:21):
Reference.identifier doesn't support the same capabilities for auto-resolution.
John Moehrke (Jan 03 2018 at 17:01):
why would we forbid search in a Reference.reference? It would be unsual, but I could see how i might be useful when the target is on another system.
Josh Mandel (Jan 03 2018 at 18:46):
We say that a reference "resolves," which I took to mean "Resolves to a resource" -- which is different from "Resolves to a Bundle that may contains resources."
Josh Mandel (Jan 03 2018 at 18:46):
Can you say more about the capabilities that Reference.identifier is missing for the use case above?
Lloyd McKenzie (Jan 03 2018 at 19:01):
If it resolves to a bundle of more than one, that would be an error. If it resolves to 0, not sure if that's an error or not.
John Moehrke (Jan 03 2018 at 19:01):
Ah, good point. I kind of thought of that after I hit enter.
John Moehrke (Jan 03 2018 at 19:02):
Reference.identifier works to hold the identifier, but not the location
John Moehrke (Jan 03 2018 at 19:02):
in your example, they should just do it right... Is there a good reason for us to accept that example?
Lloyd McKenzie (Jan 03 2018 at 19:21):
"Do it right"? If they don't know what the resource id is going to be, but the expect the query to resolve, what other mechanism can they use?
John Moehrke (Jan 03 2018 at 19:56):
so Lloyd, you are okay with the example Josh found? It seems it is not proper... right? You have indicated yourself that it is an error
John Moehrke (Jan 03 2018 at 19:57):
seems to me if they don't yet know the URL, then they should use Reference.Identifier...right?
Lloyd McKenzie (Jan 03 2018 at 20:37):
I didn't indicate it was an error. I indicated that it could be an error depending on how it resolves. It's a feature we've defined in the spec and I don't see a good way to make it go away. Using Reference.identifier wouldn't accomplish the same thing.
Lloyd McKenzie (Jan 03 2018 at 20:38):
(because there's no expectation on servers to resolve Reference.identifier)
Karl M. Davis (Jan 03 2018 at 20:40):
I'll chime in here as the owner of the server that Josh "recently came across" that was doing this.
Background:
- This was a holdover from back when we were using HAPI's JPA storage layer, and HAD to submit our bundles to it that way -- we didn't know the logical IDs yet, so we couldn't reference them.
- When we switched to our own storage layer, our mapping code didn't get changed to account for the fact that our mapping now happens at query time, when we DO know the logical IDs.
My thoughts:
- I don't think that the spec (https://www.hl7.org/fhir/references.html) is super clear about what relative URL Reference.reference values SHOULD be. All it (sort of) states is that those relative references should be resolvable.
- I can't think of any scenarios where a relative reference returned by a server _couldn't_ be a logical ID. Can anyone else?
- If not, I'd suggest that the spec be modified to include something like, "Relative Reference.reference values SHOULD be the logical ID, e.g.
Patient/abc123, of a resource on the same server, which SHOULD be resolvable (barring authorization issues)." Sound reasonable?
Grahame Grieve (Jan 04 2018 at 09:47):
you are allowed to include anything in the reference that resolves to a single resource. It's not really expected to be a general query - we only specifically document the query use for transactional behaviour, and in those cases, a server is required to resolve them or blow up. I suppose there's some ambiguity then, if you mean for them to be a query and not to be resolved in the transaction.
but out general guidance is simply: it must resolve to a single resource. It may be specified on a FHIR RESTful interface (and veyr often is) but this is not required
Josh Mandel (Jan 04 2018 at 18:17):
And when you say "Resolves to a single resource," @Grahame Grieve do you mean that GET $url returns a resource? How about a Bundle containing a resource? How about a PDF file containing a text box containing a serialized resource? (The latter, I would expect, is _not_ what you mean, but I'd like to be explicit about what "resolve" means, because finding a Bundle when I expect a Patient would be pretty surprising.)
Josh Mandel (Jan 04 2018 at 18:18):
Also @Lloyd McKenzie I still don't get what this special case for transactions is all about. If there's a _special case_, why couldn't we use Reference.identifier to address the special case? Why overload Reference.value?
Lloyd McKenzie (Jan 04 2018 at 18:46):
Because you're not always going to search by identifier. You're going to search by some set of criteria that you expect will resolve to a single resource.
Lloyd McKenzie (Jan 04 2018 at 19:40):
@Simone Heckmann can explain more about the use-cases
Grahame Grieve (Jan 04 2018 at 20:52):
identifier doesn't have the obligation to resolve.
Grahame Grieve (Jan 04 2018 at 20:53):
a bundle containing a resource is a reference to a bundle, not a reference to the resource in the bundle. So that might be legal if you meant to refer to the bundle. but not if you meant to refer to the resource inside the bundle
Josh Mandel (Jan 04 2018 at 21:57):
Thanks @Grahame Grieve -- and you're saying that populating (say) Observation.subject.reference with Patient?identifier=123 (which returns a bundle) is not okay in a "normal" Patient resource, but is okay in a Patient resource that appears in a transaction bundle?
Grahame Grieve (Jan 04 2018 at 22:03):
yes
Simone Heckmann (Jan 05 2018 at 07:42):
Conditional reference is the Client saying to the server "please resolve this for me". With logicel reference it's up to the server to decide whether to resolve or not.
It is also important to note that an unresolvable conditional reference will cause the transaction to fail, whereas an unresolvable logical reference would probably just reamin untouched. A typical use case for conditional references is pretty much every HL7 V2 message that reports something about a Patient. When you map this to FHIR you will have Observations, ChargeItems, Procedures etc. that need to be linked with a Patient of which you only know the logical Identifier.
Josh Mandel (Jan 05 2018 at 13:53):
Thanks @Simone Heckmann!
John Moehrke (Jan 05 2018 at 14:47):
That sounds like a fantastic capability. Is it required of all servers? Or do we need to identify a way a server declares support for this? I can see this being very helpful in PUSH style communication, and MHD specifically. Would really save a roundtrip at times.
Ben Spencer (Jan 05 2018 at 17:31):
I believe it's required if transactions are supported (personally I think the transaction functionality is a bit monolithic and it'd be easier for implementers if they could specify which parts are supported)
Grahame Grieve (Jan 06 2018 at 01:18):
we always only introduce complexity like this if people ask. you're the first
Last updated: Apr 12 2022 at 19:14 UTC
