Syntax issue ( allowable, but causes error from fqm-execution )

[gregory-akins]

Summary

CQL contains a strange, but allowable syntax

or "Macular edema absent (situation)" in MacularEdemaAbsentNotCommunicated.reasonCode

When that clause is included in the CQL, fqm-execution returns an error ( e is undefined )

Expected Behavior

parsed & executed successfully

Stan Rankins reports

Greg Akins 1 day ago Do you think the syntax “should” work, or it should through an error from CQL-ELM-Translator (which it’s not)?

Stan Rankins 1 day ago That's what they are being told to do by Bryn - https://github.com/cqframework/CQL-Formatting-and-Usage-Wiki/wiki/Authoring-Patterns---QICore-v4.1.1#communication-not-done

Version or Commit

1.0.8

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

bundleAndTestcas.zip

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

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

CQFramework 2.7.0

Any Additional Info

[mgramigna]

Thanks for the issue. It looks like cql-execution is failing to even construct a valid expression based on the ELM provided, so the error is happening before it even tries any execution. Thanks for providing the detailed inputs, I think this will require digging into the ELM and the CQL to see what’s going on. We will look at this. Let me know if you come across anything interesting in the meantime.

The e is undefined message that happens from the minified JavaScript is not super helpful unfortunately. I linked it to my local TypeScript files and got the following:

It's failing on the constructor of the Expression, which tries to recursively build the internal cql-execution model based on the expression tree defined in the ELM. Specifically, it's trying to access operand on something that is undefined. That should be enough for us to start poking at at the very least. Will keep you updated with progress.

[birick1]

Related: https://github.com/cqframework/cql-execution/issues/296

[birick1]

There will be discussion around this item at the May 2023 HL7 Connectathon

[birick1]

Discussed with @brynrhodes at the May 2023 HL7 Connectathon.

Resolving this issue requires an update in both the translator and cql-execution.

For the translator, an update to the QICore modelinfo file is required and a ticket has been filed at https://github.com/cqframework/clinical_quality_language/issues/1168.

Once the translator is updated, a resolution for valueset expressions can be worked in cql-execution. Track https://github.com/cqframework/cql-execution/issues/296. fqm-execution will then incorporate the updated `cql-execution'.

[birick1]

@gregory-akins: Originated from MADiE Issue Tracker 1455

[mgramigna]

Just to follow up on this one, after a lot of discussion in the past couple weeks, it has been determined that the authoring pattern for CommunicationNotDone now explicitly discourages use of the "<direct reference code>" in <alias>.reasonCode syntax:

NOTE: The positive counterpart for this statement (Macular Edema Absence Communicated) uses a direct-reference code, and ideally the negative statement would as well. However, at this time, direct-reference codes cannot be used as the terminology target of a retrieve of a negation profile. The workaround for this issue is to create a value set with the single required code and use the value set negation pattern.

The updated syntax of that authoring pattern is supported as is in fqm-execution only if a reasonCode is directly present on the data. If the data is using the qicore-notDoneValueSet extension, this will not work in fqm-execution until https://github.com/cqframework/cql-execution/issues/296 is addressed. Our team will discuss priorities around that cql-execution issue and how best to move forward.

One key assumption that we've discussed as well is that any canonical to a ValueSet referenced using the notDoneValueSet extension must be resolved prior to doing execution. It should be a ValueSet that is already included in the CQL for the measure logic. So fqm-execution will expect any ValueSet referenced in the canonical of that extension to have already been provided to the engine.

I might suggest closing this issue, as the specific syntax that caused it is no longer of concern, but I will wait for input from others.

[mgramigna]

Follow https://github.com/cqframework/cql-execution/issues/296 for more progress on this