Stream: implementers
Topic: search on type reference in STU3
Jens Villadsen (Dec 16 2020 at 12:40):
Is it possible to construct a query (in STU3) for eg. all Communications where the sender reference is of a/is not of a particular type?
René Spronk (Dec 16 2020 at 13:20):
/Communication?sender:Practitioner:missing=false (as an example for Practitioner senders). This is R4.
Jens Villadsen (Dec 16 2020 at 23:41):
@René Spronk that does not seem to do it even though the spec says that it seems doable. When doing http://hapi.fhir.org/baseDstu3/Communication?sender:Practitioner:missing=false I would have expected at least http://hapi.fhir.org/baseDstu3/Communication/2787907 among the results, but an empty resultset is returned.
Paul Church (Dec 16 2020 at 23:51):
:type:missing seems like a long shot, I doubt implementations are going to support that unless they thought of it specifically.
Maybe chain on ?sender:Practitioner with some trivial condition that will always be true? Or maybe ?sender._type=Practitioner
René Spronk (Dec 17 2020 at 07:58):
:missing is defined for all parameter types, so also for reference. If HAPI decides not to support it, then it should create an error. (non supported qualifiers and comparators should cause an error, they may not be ignored).
René Spronk (Dec 17 2020 at 07:59):
When GETting http://hapi.fhir.org/baseDstu3/Communication?sender:Practitioner:missing=false , the self link in the response is the same as the URL used, so the server supposedly processed all parts of the search URL. That's a HAPI bug.
René Spronk (Dec 17 2020 at 08:00):
However, Paul offers a nice alternative, which appears to work just fine.
Jens Villadsen (Dec 17 2020 at 09:47):
thx @Paul Church - http://hapi.fhir.org/baseDstu3/Communication?sender._type=Practitioner seems to fit the bill
René Spronk said:
:missing is defined for all parameter types, so also for reference. If HAPI decides not to support it, then it should create an error. (non supported qualifiers and comparators should cause an error, they may not be ignored).
@James Agnew it sounds like I'm gonna make a issue.
Jens Villadsen (Dec 17 2020 at 09:54):
Now, a clarifying question: should the following be possible http://hapi.fhir.org/baseDstu3/Communication?sender._type=Device,Practitioner - meaning that the types are OR'ed - meaning either Device or Practitioner?
@James Agnew the observed current behaviour seems to omit senders with type Device, so there is another bug in there somewhere.
Jens Villadsen (Dec 17 2020 at 09:58):
and a follow up question. Should sender._type work for contained resources?
Paul Church (Dec 17 2020 at 13:05):
I agree that it should be an error rather than ignored, but I'm not sure it's so clear-cut that the spec allows this combination. It certainly allows reference-field:missing, but there's not really any language about combinations of modifiers - many of which do not make sense, e.g. string-field:contains:missing.
René Spronk (Dec 17 2020 at 13:32):
Any combination of modifiers not supported by a server should result in an error. I agree that not all modifier combinations may make sense.
Jens Villadsen (Dec 17 2020 at 21:45):
@Paul Church does Google support ?sender._type=X,Z
Jens Villadsen (Dec 21 2020 at 13:18):
@Paul Church hmmm ... my 'empirical study' says Google doesn't support it
Paul Church (Dec 21 2020 at 16:11):
I'm off on holidays and haven't had a chance to look into it, but _type is a bit of a special case so it's possible we can't do that search.
Jens Villadsen (Dec 21 2020 at 19:40):
It would seem like a pretty useful feature, to be able to query for eg. messages (as in the case with Communication) that was sent from practitioners to you as a patient, at let the server do the filtering, instead of putting that load on the client
Jens Villadsen (Jan 07 2021 at 19:12):
@James Agnew is this something that is interesting to HAPI ?
Last updated: Apr 12 2022 at 19:14 UTC
