cqframework / clinical_quality_language

Clinical Quality Language (CQL) is an HL7 specification for the expression of clinical knowledge that can be used within both the Clinical Decision Support (CDS) and Clinical Quality Measurement (CQM) domains. This repository contains complementary tooling in support of that specification.
https://confluence.hl7.org/display/CDS/Clinical+Quality+Language
Apache License 2.0
258 stars 120 forks source link

Question about differences between localIds in ELM and annotations #1417

Open nmorasb opened 5 days ago

nmorasb commented 5 days ago

Hi! We're hoping to get a little clarification on why not all localIds appear in the annotations. In MADiE, we rely on the annotations to re-construct CQL for our execution highlighting feature (for QDM). We finally got around to incorporating a newer version of cqframework and cql-to-elm, and noticed that there are now many more localIds in the ELM than previously. However, only a portion of those appear in the annotations.

For example, for this group:  

{
  "signature": [],
  "resultTypeName": "{urn:hl7-org:elm-types:r1}Boolean",
  "type": "Not",
  "localId": "398",
  "locator": "30:13-30:45",
  "operand": {
    "signature": [],
    "resultTypeName": "{urn:hl7-org:elm-types:r1}Boolean",
    "type": "IsNull",
    "localId": "397",
    "locator": "30:13-30:45",
    "operand": {
      "path": "result",
      "resultTypeSpecifier": {
        "type": "ChoiceTypeSpecifier",
        "choice": [...],
        "localId": "389"
      },
      "scope": "GestationalAge",
      "type": "Property",
      "localId": "380",
      "locator": "30:13-30:33"
    }
  }
}

MADiE looks at the associated annotations:

{
  "r": "398",
  "s": [
    {
      "r": "380",
      "s": [
        {
          "r": "379",
          "s": [
            {
              "value": [
                "GestationalAge"
              ]
            }
          ]
        },
        {
          "value": [
            "."
          ]
        },
        {
          "r": "380",
          "s": [
            {
              "value": [
                "result"
              ]
            }
          ]
        }
      ]
    },
    {
      "value": [
        " is not null"
      ]
    }
  ]
}

Because localId 397 does not appear in the annotations, the statement associated with it is identified by the parent localId. When generating our coverage highlighting and comparing against the covered/executed clauses (identified by localId) from the execution output, we're ending up with a handful of uncovered clauses that can't be identified within our highlighting.

So, we'd like to request an enhancement (if feasible) to have the annotations updated so clauses are broken down to the same granular level to include all localIds, or we'd appreciate some feedback on why that may not be possible. Thanks!

brynrhodes commented 3 hours ago

There isn't a 1:1 correspondence between ELM nodes and annotation nodes, the chunks are collapsed. So although not every ELM node will have an entry in the annotation, it should be the case that the annotation nodes cover all the ELM nodes in the chunks. The parent localId 398 in this case is the chunk, and so "includes" the operand localId 397. Does that work to indicate coverage?