Execution returns wrong highlighting and no data for AgeInYearsAt function

[sb-cecilialiu]

Summary

Expected Behavior

AgeInYearsAt(date from start of "Measurement Period")>= 66 should be highlighted red, but it's green.

Version or Commit

Inputs (e.g. Measure Bundle, Patient Bundle, CQL Library)

{
   "resourceType":"Bundle",
   "id":"Patient-1-IPPass-66WithQualEnc",
   "type":"collection",
   "entry":[
      {
         "fullUrl":"633c9d020968f8012250fc60",
         "resource":{
            "resourceType":"Patient",
            "id":"Patient-1",
            "meta":{
               "profile":[
                  "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-patient"
               ]
            },
            "extension":[
               {
                  "url":"http://hl7.org/fhir/us/core/StructureDefinition/us-core-race",
                  "extension":[
                     {
                        "url":"ombCategory",
                        "valueCoding":{
                           "code":"2028-9",
                           "system":"urn:oid:2.16.840.1.113883.6.238",
                           "display":"Asian"
                        }
                     },
                     {
                        "url":"text",
                        "valueString":"Asian"
                     }
                  ]
               },
               {
                  "url":"http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity",
                  "extension":[
                     {
                        "url":"ombCategory",
                        "valueCoding":{
                           "code":"2135-2",
                           "system":"urn:oid:2.16.840.1.113883.6.238",
                           "display":"Hispanic or Latino"
                        }
                     },
                     {
                        "url":"text",
                        "valueString":"Hispanic or Latino"
                     }
                  ]
               }
            ],
            "identifier":[
               {
                  "system":"http://hospital.smarthealthit.org",
                  "value":"999999995"
               }
            ],
            "name":[
               {
                  "family":"Bertha",
                  "given":[
                     "Betty"
                  ]
               }
            ],
            "birthDate":"1957-01-02",
            "gender":"female"
         }
      },
      {
         "fullUrl":"633c9d020968f8012250fc61",
         "resource":{
            "resourceType":"Encounter",
            "id":"Encounter-1",
            "meta":{
               "profile":[
                  "http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-encounter"
               ]
            },
            "subject":{
               "reference":"Patient/Patient-1"
            },
            "status":"finished",
            "class":{
               "code":"AMB",
               "system":"http://terminology.hl7.org/CodeSystem/v3-ActCode",
               "display":"ambulatory"
            },
            "type":[
               {
                  "coding":[
                     {
                        "code":"185317003",
                        "system":"http://snomed.info/sct",
                        "display":"Telephone encounter (procedure)"
                     }
                  ]
               }
            ],
            "period":{
               "start":"2023-01-02T01:00:00.000Z",
               "end":"2023-01-02T01:15:00.000Z"
            }
         }
      }
   ]
}

Relevant Calculation Options (e.g. Measurement Period, meta.profile Validation):

measurement start: 01/01/2023, measurement end: 12/01/2023

cql-to-elm Version Used for Measure Logic Translation (if known)

Any Additional Info

[sb-cecilialiu]

[mgramigna]

Hi @sb-cecilialiu, are you able to provide the measure bundle being passed in to fqm-execution so we can replicate the issue and take a closer look at the logic?

[mgramigna]

But just from looking at the JSON posted with issue and the screenshot of the logic, your patient is exactly 66 years old on 2023-01-01. If the measurement period starts on 2023-01-01T00.00.00.000Z, isn't this expected to be truthy and therefore highlighted green?

I notice that the patient in the screenshot has a different birthDate than the one attached to this issue. Which one is the desired test case? I think I was able to replicate the issue when changing the patient's birthDate to Jan 2nd:

[jkotanchik-SB]

Yes, that's the noted issue with the DOB of 2023-01-02.

[sb-cecilialiu]

Thank you so much for replying! I'm sorry the patient bundle had the wrong data, dob should be 1957-01-02, one day less than 66 yrs old. The screenshot I sent had the right data. If dob is 1957-01-01, then the highlighting would be correct with green. I'll get the measure bundle as well for your reference, thanks again!

[sb-cecilialiu]

measure-bundle.txt

[sb-cecilialiu]

patient-bundle.txt

[sb-cecilialiu]

@mgramigna Just uploaded measure bundle and patient bundle. Thanks so much!!

[mgramigna]

Got it, thanks!

We'll take a look. Clause logic highlighting can be really finicky sometimes, but in an ideal world I think that the >= sign should probably be the part of the clause that is actually highlighted red.

We will look into this, just logged a ticket in our backlog. Thanks for the issue!

[sb-cecilialiu]

@mgramigna Awesome! Thank you so very much!!!

[sb-cecilialiu]

@mgramigna Good morning! Any update for the issuue?

[mgramigna]

Hi @sb-cecilialiu, this issue is currently in our backlog, meaning it will be prioritized when we plan a new sprint which will be next week. You can expect an update on the issue probably within the next two weeks or so

[sb-cecilialiu]

@mgramigna Thank you so very much for update! Sounds good!

[mgramigna]

@sb-cecilialiu @jkotanchik-SB We had a dev sync yesterday to talk about the plan for this issue in the next development sprint.

TL;DR: We think there might be an issue in the cql-to-elm translator that could help resolve this issue, but we think we can also code in a reasonable workaround in fqm-execution that will fix the highlighting for this case and similar cases. The plan is to still work on that workaround in the next sprint which starts a week from today.

---

Long answer:

See https://github.com/cqframework/clinical_quality_language/issues/1131 for a detailed description with ELM snippets for the potential translator issue identified.

For context, fqm-execution measure logic highlighting relies on the annotation list that exists on each ELM expression. It uses the "r" property on each annotation to do a lookup of "localId" in the ELM in order to determine which clause result from execution should be detected as truthy or falsy and therefore highlighted green or red. The way that annotations are generated for Comparison expressions where the RHS or LHS is an ELM Literal expression, the operator (in this case >=) is grouped in with the literal being compared to, which we believe is either A) a mistake or B) is fine, but has the wrong localId value associated with it.

{
  "r": "7",
  "s": [
    {
      "r": "5",
      "s": [
        {
          "value": ["\"Expression That Returns Number\""]
        }
      ]
    },
    {
      "r": "6",
      "value": [" ", ">=", " ", "66"]
    }
  ]
}

The localId "6" in this example is linking to the Literal 66 expression, not the GreaterOrEqual expression. If the localId instead linked to the GreaterOrEqual expression, then highlighting would work (a more verbose example is provided in the linked translator issue).

All this being said, there is precedent in fqm-execution for modifying the "actual" localIds that should be used when determining which clause result to look up for a given piece of ELM. I think we can code in a lookup for this case where the localId that should be used for comparisons to literals should link to the actual comparison expression itself. Doing so would generate the following highlighting for the above issue:

It's not 100% perfect, but we believe the above screenshot is a better representation of the logic highlighting for this case. Let me know your thoughts!

[sb-cecilialiu]

@mgramigna Thanks so much for taking the time analyzing it! The suggested change looks good to us. Would you please let us know when it's resolved? Thanks a lot!!

[mgramigna]

Fixed in v1.0.7, which is now released