FHIR Chat · Reverse chaining with filtering on Task.Owner

Stream: implementers

Topic: Reverse chaining with filtering on Task.Owner

Jonas Toft (Nov 29 2021 at 20:21):

I would like to make a reverse chained query that fetches all Observations of all Encounters of all Tasks related to a specific Organization. I would also like to make a reverse chained query that fetches all Observations of all Encounters of all Tasks related to a specific PractitionerRole.

Given these queries I find that the "Task.owner.PractitionerRole=some_id" filter matches both Organizations with that id and PractitionerRoles with the id. Even though I have specified the reference type, I get results not matching that type. The same applies for the other query "Task.owner.Organization=some_id" which also does not honor the reference type and does return matching PractionerRole resources.

The model:

Encounter.reasonReference references Observation
Task.encounter references Encounter
Task.owner is either a reference to an Organization or a PractitionerRole

The queries:

Observation?_has:Encounter:reason-reference:_has:Task:encounter:owner.organization=some_id
Observation?_has:Encounter:reason-reference:_has:Task:encounter:owner.practitionerrole=some_id

Any ideas on this? Bug, feature, or am I missing something?

Thanks.

Paul Church (Nov 29 2021 at 22:00):

What server are you trying this on?

Jonas Toft (Nov 30 2021 at 08:30):

Paul Church said:

What server are you trying this on?

I am using HAPI FHIR 5.4.1

René Spronk (Nov 30 2021 at 08:36):

Does the 'self' link in the response bundle echo your entire search URL?

Jonas Toft (Nov 30 2021 at 09:26):

René Spronk said:

Does the 'self' link in the response bundle echo your entire search URL?

I believe so. When executing this query:
Observation?_has:Encounter:reason-reference:_has:Task:encounter:owner.practitionerrole=1952

The return self link is:
Observation?_has%3AEncounter%3Areason-reference%3A_has%3ATask%3Aencounter%3Aowner.practitionerrole=1952

René Spronk (Nov 30 2021 at 09:34):

If that's the case, and you're sure there is matching data on the server, I'd urge you to start looking for server-side issues. Perhaps using the #hapi stream on this forum.

Jonas Toft (Nov 30 2021 at 15:15):

Thanks for the help.

I did some more digging. As it turns out I can actually query what I want.

This query will give me Observations referenced by the PractitionerRole with id 1234:
Observation?_has:Encounter:reason-reference:_has:Task:encounter:owner=PractitionerRole/1234

This query will give me Observations referenced by the Organization with id 5678:
Observation?_has:Encounter:reason-reference:_has:Task:encounter:owner=Organization/5678

This query will give me Observations referenced by any Task.owner reference with id 1234 or 5678. Note the JIBBERISH at the end. This is the part that confused me. I would expect the server to return an error:
Observation?_has:Encounter:reason-reference:_has:Task:encounter:owner.JIBBERISH=1234,5678

René Spronk (Nov 30 2021 at 15:29):

I guess the self link doesn't contain the JIBBERISH part. If it does, talk to the authors of your server software. A server is supposed to largely ignore all parts of a search URL it doesn't understand, and to provide you with the best matching result set given what it does understand.

Josh Mandel (Nov 30 2021 at 15:29):

Re: jibberish, In general, servers are free to ignore search parameters they don't understand and are supposed to communicate to clients the list of search parameters they did understand by populating the Bundle.link[self] of the response. See http://build.fhir.org/search.html#errors

Jonas Toft (Dec 01 2021 at 07:35):

Josh Mandel said: