Stream: implementers
Topic: Search on reference search parm using logical ID only
Mike Schroeder (Feb 08 2021 at 23:12):
Question on reference searches using only logical ID, relating to this passage in the spec at https://www.hl7.org/fhir/search.html#reference:
"Some references may point to more than one type of resource; e.g. subject: Reference(Patient|Group|Device|..). In these cases, multiple resources may have the same logical identifier. Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types. In order to allow the client to perform a search in these situations the type is specified explicitly..."
Given a search query of 'Observation?subject=123', should the request:
a) be rejected before even attempting the search, given that subject has multiple target types
b) be executed, and an error returned only if Observations are returned containing references to multiple resource types (i.e. 'Patient/123', 'Group/123', etc)
c) be executed and Observation results returned successfully regardless of resource type matched on
Michele Mottini (Feb 08 2021 at 23:15):
Our server does (a)
Lee Surprenant (Feb 09 2021 at 18:04):
@Mike Schroeder and I spent a long time yesterday trying to understand what that particular text was saying (and more importantly why). Any other thoughts/interpretations on this one?
Paul Church (Feb 09 2021 at 18:20):
My interpretation was b) but I didn't feel that it was clear. I think our implementation still does c) and we haven't fixed it yet.
As a meta point I don't see the value of allowing this search syntax (subject=123) at all. It implies that there are resources of different types with the same ID (probably not the best practice), the client somehow only knows the ID of what they're looking for, and the client can't be bothered to write subject=Patient/123,Group/123. This seems like it would be better served with an identifier reference and searching subject:identifier=123.
Lee Surprenant (Feb 09 2021 at 19:39):
thanks Paul, i think I share that sentiment. our implementation also does (c) currently and we were debating whether to make it do (a) or (b) instead. (a) seems the simplest for servers to implement, but to us the language used there seems to imply (b) was what the spec authors had in mind. but since those spec authors are on this channel, I suggested we ask here to find out...
Last updated: Apr 12 2022 at 19:14 UTC
