Stream: implementers
Topic: search on resource by logical reference?
Robin Bosman (Oct 22 2020 at 17:00):
Let's say I have an Immunization that is on a FHIR server. That FHIR server does not have Patient resources.
Every Immunization would always refer to its patient via a logical reference (i.e. a Reference.identifier with system X and value Y)
Is it at all possible to construct a GET that would give me all the immunizations that have as their Patient a logical reference to system X and value Y or is this simply not possible?
(I have read that a logical reference prevents chaining - is the conclusion my above scenario is not possible?)
Paul Church (Oct 22 2020 at 17:03):
yes, Immunization?patient:identifier=X|Y - this is a modifier available in R4 reference search
Paul Church (Oct 22 2020 at 17:08):
(ironically :identifier is one of the things the Google implementation doesn't support yet :cant_talk: )
Lloyd McKenzie (Oct 22 2020 at 20:35):
You can search on .identifier, but you couldn't do an _include that matched on identifier, nor could you do chained searching based on identifier. I.e. you couldn't search Immunization?patient.name=foo if the Immunization.patient just had Reference.identifier and not Reference.reference
Robin Bosman (Oct 23 2020 at 07:24):
Thanks! So just to be sure, an Immunization resource that is uploaded like this:
<Immunization xmlns="http://hl7.org/fhir">
[...]
<patient>
<identifier>
<system value="X"/>
<value value="Y"/>
</identifier>
</patient>
[...]
</Immunization>
-> If now I would like to do a GET to give me all the Immunization that have their Patient only defined by their logical reference identifier X|Y -> this is not possible.
Vassil Peytchev (Oct 23 2020 at 13:34):
No, as Paul said, it is possible using GET [base]/Immunization?patient:identifier=X|Y
As long as the particular server implementation supports that type of search.
René Spronk (Oct 23 2020 at 13:53):
patient.identifier, not patient:identifier ..
Michele Mottini (Oct 23 2020 at 14:00):
patient.identifier, not patient:identifier ..
Oh no - can be either (and the client has to figure out which one is the right one)
Lloyd McKenzie (Oct 23 2020 at 14:30):
Right. Patient:identifier matches when Reference.identifier is present. Patient.identifier matches when Reference.reference is present and the resolved resource has an identifier
Michele Mottini (Oct 23 2020 at 14:33):
Patient:identifier matches when Reference.identifier is present. Patient.identifier matches when Reference.reference is present
Except that the client has to to do the search before seeing the resources, so it has to 'know' already (it would be so much better that patient.identifier always worked, but that ship has sailed I guess)
John Moehrke (Oct 23 2020 at 14:34):
surely we can move this complexity to the server... right?
Lloyd McKenzie (Oct 23 2020 at 14:38):
Someone could submit a change request that would propose that servers treat the chaining approach and the qualifier approach as covering both. Whether we can get away with that post-normative, I'm not sure
René Spronk (Oct 23 2020 at 14:44):
Ah, yes, reference.identifier again. I wonder how often that's actually used in production systems (usage seems to be very low (but I could be wrong), so we're skipping this in our FHIR training courses. Not part of the 80% of the 80% ;-) )
Jean Duteau (Oct 23 2020 at 14:50):
@René Spronk In Saskatchewan, where they are converting from a V3 pharmacy system to FHIR, they actually use reference.identifier quite a bit. In this architecture, the data comes into the V3 system and that kicks off a process to add the new data to FHIR. Since the V3 system doesn't know the FHIR ids of the data, we use reference.identifier to reference the various resources, eg. Patient, Practitioner, Dispense. But I do agree that this is not your normal case.
René Spronk (Oct 23 2020 at 14:57):
Hmm - so if you had a Bundle of these resources, how would one populate fullUrl ? some urn: that's totally useless because it'll never be used for inter-resource-referencing ?
Jean Duteau (Oct 23 2020 at 15:02):
they are batch Bundles, so no fullUrl is needed.
Michele Mottini (Oct 23 2020 at 15:15):
https://jira.hl7.org/browse/FHIR-29410
Paul Church (Oct 23 2020 at 15:33):
Also patient:identifier matches in situations where Reference.identifier is populated and the server has a resource with that identifier (so the server could, in theory, have translated that reference to a local reference when it was created) and also where Reference.identifier is populated with something that doesn't correspond to a resource on the server. There might be different solutions depending on which case we're in.
Lloyd McKenzie (Oct 23 2020 at 16:30):
Reference.identifier is pretty new, so most systems haven't had a chance to use it yet. It's relevant when you're trying to point at stuff that doesn't have a RESTful endpoint - which in legacy environments is somewhat common.
Jens Villadsen (Feb 03 2021 at 11:11):
@Lloyd McKenzie how 'new' are we talking here? Is it something that also applies to STU3? I would have imagined that eg. the following search: .../Communication?sender.identifier=1|2 should give me results that would contain the following eg.:
{
"resourceType": "Communication",
...
"sender": {
"identifier": {
"system": "1",
"value": "2"
}
}
}
Jens Villadsen (Feb 03 2021 at 11:34):
@James Agnew is that functionality intended to be supported by HAPI in the future?
Michele Mottini (Feb 03 2021 at 13:52):
No, to get that you have to use ../Communication?sender:identifier=1|2
Lloyd McKenzie (Feb 03 2021 at 17:11):
Reference.identifier was only introduced in R4. @Michele Mottini is right. sender.identifier=1|2 would only find a match if the Reference specified a Reference.reference that, when resolved, was to a resource with identifier system and value of 1,2. It totally ignores Reference.identifier.
Lloyd McKenzie (Feb 03 2021 at 17:12):
And FHIR-I just confirmed that it should ignore Reference.identifier. If you want to search by either, you need to do two searches, because otherwise the server has no way of communicating what searches it actually supports.
Jens Villadsen (Feb 03 2021 at 19:22):
@Michele Mottini / @Lloyd McKenzie point taken, with the ':'part. @Lloyd McKenzie regarding
Reference.identifier was only introduced in R4
-you mean as search parameter, right - because as a datatype, the reference datatype definitely contained the identifier-part in STU3.
Lloyd McKenzie (Feb 03 2021 at 20:30):
Actually, I meant being introduced at all, but looks like I was wrong. I guess it was introduced at the very tail end of STU3. The :identifier search qualifier was definitely R4.
Jens Villadsen (Feb 04 2021 at 11:09):
Just to be clear here, I'm not looking for an actual chained search. I don't expect the server holding the Communication instance, to also hold the actual Device instance. I'm only trying to identify the Communication instance which have a certain logical reference. But as you mention @Lloyd McKenzie , I can only see the :identifier as part of R4, not STU3. I guess I'll have to dig into the server implementation and either provide a custom search paramter or expand the allowed use of :identifier.
Last updated: Apr 12 2022 at 19:14 UTC
