Stream: implementers
Topic: GCP Chain search
Hue Nguyen (Jul 30 2020 at 12:44):
Hello,
I wanna search Encounter base on Patient Birthdate with GCP healthcare api.
Query be like: <Base Path>Encounter?patient.active=false&patient.birthdate=2020-01-01
Expect: 6 data in response
Actual:
{
"issue": [
{
"code": "no-store",
"details": {
"text": "storage_error"
},
"severity": "error"
}
],
"resourceType": "OperationOutcome"
}
After that, i try to remove param patient.active=false on search
Query be like: <Base Path>Encounter?patient.birthdate=2020-01-01
Expect: 6 data
Actual: 6 data
Lloyd McKenzie (Jul 30 2020 at 14:59):
With what server? The OperationOutcome is certainly a little light on detail...
Paul Church (Jul 30 2020 at 17:16):
(GCP = Google Cloud Platform)
I'm unable to reproduce this error, the same chained query works for me. The generic storage_error usually indicates an internal error in the storage layer so there are a variety of possible causes. I'll have to investigate further - I would expect this query to succeed.
Hue Nguyen (Jul 30 2020 at 23:45):
Seem like the error relate to relationship.
I try with another birthdate which return only 1, 2 result and the query work like a charm.
Hue Nguyen (Jul 30 2020 at 23:49):
For example:
Query be like: <Base Path>Encounter?patient.active=false&patient.birthdate=2020-02-01
Expect: 2 data as response
Actual: 2 data
I was try search PractitionerRole base on Practitioner.name and Organization.name. If response result is bigger than 7. Same error will return
Paul Church (Jul 31 2020 at 17:55):
Thanks for the detailed report. I have identified a bug triggered by having two chained search clauses in a query, where both clauses are chaining on the same search parameter (patient, in this case). I'm working on a fix.
Hue Nguyen (Aug 01 2020 at 07:56):
@Paul Church
Thank you so much,
I have one more problem with chain search in here
I try to write a query to get all Encounter where have participant:PractitionerRole._id= {Id1}
Query will like:
Encounter?participant:PractitionerRole._id=001
Data base will like:
Encounter 1: include PractitionerRole id = 001
Encounter 2: include PractitionerId = 001
Expect: GCP return Encounter 1
Actual: GCP return both Encounter 1 & 2
I was try to add header "Prefer: handling=strict " and no error with query above.
Seem like server ignore ResourceType in participant:PractitionerRole._id and only care about participant._id. So, result is incorrect
Paul Church (Aug 04 2020 at 15:42):
I'll take a look at that as well. There is a known issue where a resource with references to A/001 and B/002 will incorrectly match searches for A/002 or B/001 but your example might not be the same case. We do check the type on a typed chain query so if the IDs are unique I expect it to work.
Paul Church (Aug 14 2020 at 20:18):
@Hue Nguyen I tested this out and confirmed that it is the known issue that I thought it was.
You will only encounter this issue in the case where the Encounter contains multiple participant references, one of which is Practitioner/001 and another is PractitionerRole/<any ID>. This resource will incorrectly match PractitionerRole/001. In general, typed chained search is filtered by resource type. The issue is specific to references that have multiple values of different resource types.
We recommend keeping resource IDs unique where possible as the easiest workaround.
Hue Nguyen (Aug 17 2020 at 14:30):
@Paul Church Sorry for late response.
Thank you for your supporting
Hue Nguyen (Aug 31 2020 at 02:57):
Paul Church said:
Thanks for the detailed report. I have identified a bug triggered by having two chained search clauses in a query, where both clauses are chaining on the same search parameter (patient, in this case). I'm working on a fix.
@Paul Church How's this going?
Do you know when will it done :pray:
Paul Church (Aug 31 2020 at 20:17):
@Hue Nguyen The fix is rolled out to some regions already, it should be live in all regions in about 2 more days.
Hue Nguyen (Aug 31 2020 at 23:07):
@Paul Church I see, thank you so much
Last updated: Apr 12 2022 at 19:14 UTC
