FHIR Chat · search: mixing _has with chaining · implementers

Stream: implementers

Topic: search: mixing _has with chaining

Severin Skillman (Oct 10 2019 at 20:13):

I want to write a query that will return all Observations that are created based on CarePlans who's subjects are Patients that are members of a Group with the id of "cohort1".

Would the below query be valid?

GET [base]/Observation?_has:Group:based-on.patient:_id=cohort1

where based-on is the search param for Observation.basedOn(CarePlan)
and patient is the search param for CarePlan.subject (Patient)

Severin Skillman (Oct 10 2019 at 20:42):

perhaps an operation would be more appropriate?

Lloyd McKenzie (Oct 10 2019 at 20:55):

Even if you express the search parameters correctly, you may hard-pressed to find a server who'll support it. You might be better doing something like that with GraphQL

Lloyd McKenzie (Oct 10 2019 at 20:55):

@Grahame Grieve ?

Alexander Zautke (Oct 10 2019 at 21:18):

Yes, in theory combining Chaining and Reverse Chaining is allowed using the syntax that you described. However there are two issues with that specific one. First you need to specify the resource linking to Observation as the first element after _has. So, Observation?_has:CarePlan:based-on, otherwise you would look for all Groups referencing Observations directly through the based-on attribute, which would not be valid. Than we chain from CarePlan to Group through the patient search parameter. However that one is defined for either a Patient or a Group resource, so we need to pass a :type modifier ...based-on.patient:Group.... And instead of a “:” you need to chain _id using a “.”.

So GET [base]/Observation?_has:CarePlan:based-on.patient:Group._id=<id> should work.

Severin Skillman (Oct 10 2019 at 22:04):

A bit late here to get my head around that one, but thank you. I think I'll opt for defining a SearchParameter instead.

natus (Oct 16 2019 at 21:02):

hi @Severin Skillman are you like me in the process to implement a cohort tool on top of fhir ? glad to share experience and thought on this

natus (Oct 16 2019 at 23:22):

what about using _list parameter as a proxy for group ? The _list would contain the patient within the group. This avoid defining your own SearchParameter

Hue Nguyen (Jul 11 2020 at 08:20):

I want write query to return all Practitioner have name like Mr and base on PractitionerRole who's practitioner is Practitioner that have Organization name is something
Query like bellow

GET [base]/Practitioner?name=Mr&_has:PractitionerRole:practitioner:organization.name=something

I got 2 trouble in here.

1. Practitioner name seem like wont work with Mr except i include :exact into it. I was try with another string like Happy and it work without :exact
2. _has not work with field name. I try to change to _has:PractitionerRole:practitioner:organization={ID} and it work
   cc: @Alexander Zautke

Josh Mandel (Jul 11 2020 at 13:13):

Which server are you testing these queries with?

Hue Nguyen (Jul 11 2020 at 14:52):

@Josh Mandel this is GCP FHIR

Josh Mandel (Jul 11 2020 at 14:54):

Okay. @Paul Church should be able to provide some advice. (I'm guessing these features may not be supported or may be incompletely supported.)

Hue Nguyen (Jul 11 2020 at 14:58):

@Josh Mandel thanks.
I have one more question about :iterate with GCP FHIR

GET [base] /PractitionerRole?_include=PractitionerRole:practitioner&_revinclude:iterate=Encounter:practitioner

I try to get all Encounter which relate to Practitioner
But seem like :iterate didn't work. Maybe i got some mistake on this query. Can you give me some advice ?

Lloyd McKenzie (Jul 11 2020 at 15:02):

Your _revinclude is going to include Encounters that have those practitioners. What are you expecting to iterate?

Hue Nguyen (Jul 11 2020 at 15:07):

@Lloyd McKenzie i don't think so.
If only use _revinclude, that mean we're trying to get Encounters from PractitionerRole. That impossible, right ?
What i try to do is get Encounter base on practitioner, not practitionerRole.
That why i add iterate to get all Encounter from included practitioner
Do i understand correct about how this work ?

Josh Mandel (Jul 11 2020 at 15:10):

My understanding is that iterate was used to request inclusions for results that are themselves inclusions. So the query actually looks good to me.

Josh Mandel (Jul 11 2020 at 15:11):

I think the meta advice is that most servers do not support this behavior or perhaps do not support it very consistently. Spec says:

It is at the server's discretion how deep to iteratively evaluate the inclusions. 

and more broadly, support for these include of parameters at all is pretty variable today.

Josh Mandel (Jul 11 2020 at 15:13):

I tried to get hapi to return me data using the same pattern of include underverse include you listed above: http://hapi.fhir.org/baseR4/Observation?_id=7195dad9-25aa-449b-8a4d-969333592d17&_include=Observation:patient&_revinclude:iterate=Encounter:subject&_count=1 . (Note that I supplied and ID specifically to make sure I was pointing at an Observation resource that actually has all the relevant links in and out.) I tried with and without iterate but could not get the encounter to be return to using reverse include.

Josh Mandel (Jul 11 2020 at 15:14):

(for this particular query there is a simpler way to get the encounter, which is from a direct include on the observation itself, rather than a reverse include on the patient. But I am trying to test server functionality here rather than write efficient queries. :-))

Hue Nguyen (Jul 11 2020 at 15:28):

@Josh Mandel i got your point.
I was check on GCP document. Spec says:

The modifier :iterate causes an _include or _revinclude to be evaluated iteratively

But they only have example for _include:iterate. That weird...
@Paul Church can you give me some advice about this situation?

Paul Church (Jul 13 2020 at 17:14):

There are a few different bits of functionality here. GCP FHIR does not support mixing _has with chaining, and does not support _revinclude:iterate.

The documentation is slightly misleading, sorry about that. I wrote it with one eye on the spec and the other on our implementation, and in the case of _revinclude it incorrectly implies that we support :iterate. I'll get that wording fixed.

Paul Church (Jul 13 2020 at 17:24):

In one of your examples there is also a known limitation/bug - very short tokens (1 or 2 characters) are not indexed for non-exact match. This is why name=Mr does not find Mr but it will find Mrrrr. Any exact match like name:exact=Mr works correctly. We were already looking into this, hopefully we can change it so short tokens will work for prefix match (the default) but not for substring (:contains) to keep the index size under control.

Hue Nguyen (Jul 13 2020 at 23:51):

@Paul Church thanks, i have one more question.
Yesterday, i try to search HumanName with Japanese character(with and without encode UTF-8, with and without :exact) and alot of word doesn’t return the correct result. Do i need add some header into the request ?

Paul Church (Jul 14 2020 at 01:02):

I expected that would work by default, but you can try the header "Content-Type: application/fhir+json;charset=utf-8" to explicitly set UTF-8. If not, send an example of a string that doesn't match and I will investigate.

Hue Nguyen (Jul 14 2020 at 01:06):

@Paul Church here is some word
木村通男
会田

Hue Nguyen (Jul 14 2020 at 01:07):

I already put this content type, but it’s not work

Hue Nguyen (Jul 14 2020 at 01:08):

And this is word that work well

张无忌

Hue Nguyen (Jul 14 2020 at 13:04):

@Paul Church hello, Seem like GCP doesn't support, is this right ?
I got trouble while trying get Encounter base on Practitioner name
Relationship like this:
Encounter -------> PractitionerRole ----------> Practitioner
Query will be like
`<Base>Encounter?participant:PractitionerRole.practitioner.name=Morning

I was check on docs [1] and gcp support for it
But i can not get correct data.

[1] https://cloud.google.com/healthcare/docs/how-tos/fhir-advanced-search

Paul Church (Jul 14 2020 at 16:22):

I can reproduce this problem with Japanese characters and I'll have my team look into it. I see that all of them match when using :exact so this seems specific to substring matching.

Paul Church (Jul 14 2020 at 16:51):

For the 2 level chain example, we only support one level of chaining. Try this query with the header "Prefer: handling=strict" (or set the defaultSearchHandlingStrict option on the fhir store config) and you'll see the error "only single level chaining is supported". This option is useful for any kind of development work when testing search queries.

Hue Nguyen (Jul 14 2020 at 17:04):

@Paul Church i got the point.

For the 2 level chain example, we only support one level of chaining

I don't want make a lot of request into healthcare. That'll scale up when data is bigger everyday.
Do you have any idea for it ?

Paul Church (Jul 14 2020 at 18:24):

Depending on the use case you might cache the result of the chain, for example if practitioners do not change often. For non-real-time queries you can export data to BigQuery and do arbitrary levels of joining. Or you can do multiple queries, the API supports a lot of traffic.

Hue Nguyen (Jul 14 2020 at 23:47):

I see, thank you :+1::+1:

Last updated: Apr 12 2022 at 19:14 UTC