FHIR Chat · Chaining · implementers

Stream: implementers

Topic: Chaining

Amy Abraham (Feb 08 2022 at 15:41):

Re: http://www.hl7.org/fhir/search.html#chaining

In this example GET Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN ; where an '&' is used, the description states 'may return Patients cared for by Joe from CA and Jane from MN: no one practitioner need satisfy both conditions. E.g. the chains are evaluated separately.' ;

Is this a mistake, shouldnt '&' mean all the criteria's should be met ?

René Spronk (Feb 08 2022 at 15:59):

It's not a mistake, the wording is correct.

René Spronk (Feb 08 2022 at 16:00):

All criteria are indeed met - (Patients that have PCP Joe) and (Patients that have a PCP in MN).

Craig McClendon (Feb 08 2022 at 16:22):

That would be OR-logic, not AND-logic. I guess you need to think of the '&' here as not an AND, rather just a HTTP parameter separator character. I'm not sure though why chains are evaluated with OR-logic. Perhaps to simplify implementations?

Paul Church (Feb 08 2022 at 16:22):

It is an AND. Chains are not evaluated with OR logic.

Craig McClendon (Feb 08 2022 at 16:29):

GET Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN

In SQL if I have a 'general-practitioner' table with 'name' and 'address-state' columns.

*SELECT * FROM general-practitioner WHERE name = 'Joe' AND address-state = 'MN'*
would not return Jane from MN.

What am I missing?

Paul Church (Feb 08 2022 at 16:33):

We're not selecting from general-practitioner. We're selecting from patient, and each patient might have multiple general-practitioner references. The chain clauses can match different references on the same patient, which satisfies the AND despite not having any single general-practitioner that satisfies both.

Paul Church (Feb 08 2022 at 16:34):

For outgoing references with max cardinality 1 this problem doesn't exist.

Gino Canessa (Feb 08 2022 at 16:41):

I think this is a language parsing challenge. The sentence "may return Patients cared for by Joe from CA and Jane from MN" is indicating that a single patient that has a practitioner 'Joe' in CA and a practitioner 'Jane' from MN would still meet the requirements.

E.g., the 'and' is applied to the set the root level instead of inside the chain.

(edit: see: 'garden path sentence' =)

Amy Abraham (Feb 08 2022 at 16:44):

Thanks all

Craig McClendon (Feb 08 2022 at 16:56):

Just to complete the SQL analogy, it works out logically to something similar to this and Paul and Gino are correct.

*SELECT * FROM Patient pat
WHERE EXISTS (select * from general_practitioner gp where gp.name = 'Joe' and gp.patient_id = pat.id)
AND EXISTS (select * from general_practitioner gp where gp.state = 'MN' and gp.patient_id = pat.id)*

Paul Church (Feb 08 2022 at 17:06):

@Gino Canessa maybe if you're doing any rewriting in this area we could make it clearer that this caveat applies to repeated outgoing references? This question seems to come up a lot.

Gino Canessa (Feb 08 2022 at 17:21):

Yep, I added a note. Hopefully have a completed pass to start reviewing soon, but I discovered the search 'page' is more like the search 'short book' =)

Michele Mottini (Feb 08 2022 at 17:27):

The reference goes from patient to practitioner, so more like:

SELECT * FROM Patient pat
WHERE EXISTS (select * from practitioner gp where gp.name = 'Joe' and gp.id = pat.generalpractitioner_id)
AND EXISTS (select * from practitioner gp where gp.state = 'MN' and gp.id = pat.generalpractitioner_id)

(but same idea)

René Spronk (Feb 09 2022 at 07:08):

.. so by changing the focus of the search, Practitioner?name=Joe&state=MN&_revinclude=Patient:practitioner (not the correct parameter names, but you get the gist) it'd be a true AND on the Practitioner resource, and it would return the Patients that have Joe-in-MN as their PCP/GP.

Krishna Kumar (Feb 09 2022 at 07:55):

I am getting oauth2 error on epic it was working before but now not working

Krishna Kumar (Feb 09 2022 at 07:56):

I am sending the payload below:

FHIR.oauth2.authorize({
      'client_id': 'f3174bc9-02d2-4637-a612-9166b3b3aa93',
      'scope':  'patient.read, patient.search, observation.read, observation.search',
      'redirect_uri': 'http://localhost:3000',
    'iss': 'https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/'
    })

Lloyd McKenzie (Feb 09 2022 at 14:54):

Epic issues are best resolved by reaching out to open@epic.com

Last updated: Apr 12 2022 at 19:14 UTC

Main menu