FHIR Chat · CQL <-> FHIR-REST-API-search · cql

Stream: cql

Topic: CQL <-> FHIR-REST-API-search

Georg Fette (Dec 19 2018 at 12:01):

Hello, as there are not yet many existing CQL-engines it would be an interesting (imho) approach to translate CQL to FHIR-REST-API-searches and vice versa. Although the FHIR-search is much less expressive, a subset of all possible queries would be translatable. Has this idea already been tried somewhere ? Or what would the experts in the field of CQL and FHIR-search think of that idea ?

Bryn Rhodes (Dec 20 2018 at 00:16):

Hi @Georg Fette , the java-based CQL engine translates retrieves to FHIR API calls, which is effectively conjunctive queries with sorting.

Bryn Rhodes (Dec 20 2018 at 00:17):

The translation is pretty rough right now, there are a lot of areas that should be more driven by the profiles (rather than the hard-coded translation that happens now), but the core is there.

Bryn Rhodes (Dec 20 2018 at 00:18):

And the CQL-to-ELM translator does some minimal optimization to push filters into retrieves. More could definitely be done in that area as well (like translating related retrieves into includes).

Georg Fette (Dec 20 2018 at 09:59):

Hi, @Bryn Rhodes, do you refer to the JavaScript- or the Java-engine ? In which of the code projects of the cqlframework repository is this translation located ? Or do you mean that the actual execution of CQL in the engine is performed by successive FHIR API calls, which can be seen as a translation to FHIR API calls ?

Bryn Rhodes (Dec 20 2018 at 15:46):

In the Java engine, FHIR provider, but yes, it is the latter, that the actual execution of CQL in the engine is performed by FHIR API calls. To do that, it needs to translate the retrieves to FHIR API calls. To use it as a translator independent of the engine would take some refactoring, but it's a place to start.

Chris Moesel (Dec 20 2018 at 18:20):

For the CQL Services prototype we built (which uses the coffeescript execution engine) we do a very simple analysis of the ELM to extract the retrieve statements and build FHIR DSTU2 queries for them (which we use to publish prefetch clauses for arbitrary CQL-backed CDS Hooks services).

The result is a set of very broad queries (e.g., Condition?patient={{context.patientId}}). We don't try to narrow based on value sets, time ranges, or other logic in the CQL query, although that would certainly be a nice capability to add.

See: https://github.com/AHRQ-CDS/AHRQ-CDS-Connect-CQL-SERVICES/blob/master/lib/local-hooks.js#L73-L180

Georg Fette (Dec 21 2018 at 08:57):

ah, interesting. Thank you.

Rich Boyce (Aug 26 2019 at 09:54):

@Bryn Rhodes and @Chris Moesel - I just read this thread from last year while trying to work develop knowledge artifacts for drug-drug interaction CDS using a CDS service, CQL, and CDS Hooks.

I was wondering the current status on the recommendations for specifying prefetch as written in http://hl7.org/fhir/2018May/clinicalreasoning-cds-on-fhir.html ?

I dug through the code of the most recent releases of cqf-ruler and played with adding lists of DataRequirement to both the PlanDefinition and Library for our CDS artifacts. In neither case does it affect the prefetch template of the service. Is this something that just wasn't implemented?

I did not try the AHRQ engine but from the thread, it looked like it would not do that either.

Chris Moesel (Aug 26 2019 at 13:13):

I can't speak for cqf-ruler, but regarding AHRQ CQL Services, we have not yet implemented any more sophisticated approaches to generating prefetch queries. I'm not sure if/when we will do that. It's not an immediate priority.

Bryn Rhodes (Aug 26 2019 at 22:51):

I'm surprised by the fact that data requirements aren't surfaced for you, that is something the CQF-Ruler is doing; I believe it takes it directly from the CQL though: http://cds-sandbox.alphora.com/cqf-ruler/cds-services

Bryn Rhodes (Aug 26 2019 at 22:51):

Not from the DataRequirements in the Library (though those should be consistent).

Rich Boyce (Aug 29 2019 at 21:43):

@Chris Moesel and @Bryn Rhodes Thanks for the replies. @Bryn Rhodes A bit of clarification - I do see data requirements surfacing from CQL but how that happen is not what I expected. In reading https://cql.hl7.org/05-languagesemantics.html it looks like a difficult problem was solved in determining data requirements from CQL. However, when I am writing a knowledge artifact that uses CQL + CDS Hooks, I am finding that the design might make it harder to be explicit about the prefetch templates I want the CDS client to receive when subscribing to a hook. What I end up with is a number of pre-fetch templates that look like a combination of all of the data queries present in CQL rather than the handfull of things that we want to suggest the CDS client send in the hook. That is why I wondered if I could explicitly specify the data requirement using the related Library or Plan Definition and maybe have that override the output of Request analysis when converted to prefetch? I am not very experienced so will be glad to be directed another direction if I am missing something. Please let me know your thoughts. Thanks!

Chris Moesel (Aug 29 2019 at 22:20):

Hi @Rich Boyce -- I'd love to solve this problem too and have thought along the same lines. Let me suggest an example to ensure we're on the same page. Let's say that you have CQL including something like this:

define RecentDrugTest: [Observation: "Urine Drug Test"] UDT
  where UDT.issued on or after (Today() - 1 year)

(Forgive any syntax errors; I did not try to compile it).

Ideally, the prefetch would be a FHIR query that filters on the code (to be a urine drug test) and the issued date (to be in the last year). Instead, the prefetch query gets generated as a wide-open query for all the patient's Observations (and the CQL engine does the filtering afterward). Is that about right? (That's how the AHRQ CQL Services works anyway).

Aside from the challenge of correctly translating arbitrary where clauses into a query, we also have the challenge that valueset-based queries on FHIR are unlikely to be supported. You could construct a query that enumerates all the codes in the value set, but for a large value set, this might also be problematic -- as you can end up with a looooong URL. So... the reason we haven't done it yet? It's hard.

I have also thought, however, that given this, perhaps the most feasible solution is to allow the calculated prefetch statements to be overridden via configuration. Although there is the danger that someone will write the queries wrong, there is some good upside if someone smart (like you) writes the queries right! In the AHRQ CQL Servics, we'd likely support this sort of thing through the CQL Hooks config file. In Bryn's Java based implementation, I'm not sure what the best approach would be.

Rich Boyce (Sep 04 2019 at 17:57):

@Chris Moesel - I apologize for the slow reply. I think your example is correct but I can show you a specific example that illustrates the issue. The CQL Library and PlanDefinition from here (https://git.rwth-aachen.de/binhphi109/pddi-cds/tree/connectathon-21-pddi/examples/pddi-cds/warfarin-nsaids-order-sign) are loaded into the v0.1.2-PDDI-CDS branch of cqf-ruler (https://github.com/DBCG/cqf-ruler.git). Also, the vocabulary bundle. I mention these so that you can see the resources specifically, especially the CQL (https://git.rwth-aachen.de/binhphi109/pddi-cds/blob/connectathon-21-pddi/examples/pddi-cds/warfarin-nsaids-order-sign/warfarin-nsaids-cds-sign-logic.cql). As a note, I removed all test resources provided by the cqf-ruler team so there should be no other terminology or CDS resources besides the ones for my PDDI use case. So, running a GET request for cds-services (http://localhost:2020/cds-services) returns the response in this attached JSON cqf-ruler-response.json which has a large number of non-relevant components in the prefetch template. The listing below shows what I would like and would be willing toto specify explicitly, perhaps using the PlanDefinition:

{
  "services": [
    {
      "hook": "order-sign",
      "name": "PlanDefinition - Warfarin NSAIDs Recommendation Workflow",
      "title": "Warfarin NSAIDs Recommendation",
      "id": "warfarin-nsaids-cds-sign",
      "prefetch": {
        "item1": "Patient?_id={{context.patientId}}",
        "item2": "MedicationRequest?patient={{context.patientId}}&authoredon=ge2019-05-27",
        "item3": "MedicationAdministration?patient={{context.patientId}}&effective-time=ge2019-05-27",
        "item4": "MedicationDispense?patient={{context.patientId}}&whenhandedover=ge2019-05-27",
        "item5": "MedicationStatement?patient={{context.patientId}}&effective=ge2019-05-27",
        "item6": "Condition?patient={{context.patientId}}"
      }
    },
    {
      "hook": "order-select",
      "name": "PlanDefinition - Warfarin NSAIDs Recommendation Workflow",
      "title": "Warfarin NSAIDs Recommendation",
      "id": "warfarin-nsaids-cds-select",
      "prefetch": {
        "item1": "Patient?_id={{context.patientId}}",
        "item2": "MedicationRequest?patient={{context.patientId}}&authoredon=ge2019-05-27",
        "item3": "MedicationAdministration?patient={{context.patientId}}&effective-time=ge2019-05-27",
        "item4": "MedicationDispense?patient={{context.patientId}}&whenhandedover=ge2019-05-27",
        "item5": "MedicationStatement?patient={{context.patientId}}&effective=ge2019-05-27",
        "item6": "Condition?patient={{context.patientId}}"
      }
    }
  ]
}

Bryn Rhodes (Sep 06 2019 at 03:37):

@Chris Moesel , the idea of specifying the prefetch explicitly as a configuration is definitely a possibility, and I do think it is a shortcoming of the current data requirements approach that there is no way to distinguish between something you want to fetch initially, versus something you're okay with retrieving after the fact. If we knew the initial query, we could limit the prefetch to only the data requirements involved in that. For example, the Inclusion Criteria.

Bryn Rhodes (Sep 06 2019 at 03:38):

@Rich Boyce , that looks like a bug in the requirements gathering code. We'll take a look and make sure that's functional on the latest branch in the ruler.

Last updated: Apr 12 2022 at 19:14 UTC