v1.6.0

What's Changed

• Stratified report fix by @lmd59 in #315
• Coverage 3.14.0 by @lmd59 in #314
• ignore coverage regression files by @lmd59 in #316
• Relationship alias coverage fixes by @hossenlopp in #317
• update micromatch via npm audit fix by @hossenlopp in #319
• v1.6.0 by @hossenlopp in #320

Highlighting Changes

The annotation structure used for highlighting often includes localIds that are not in the ELM expression stack. These have always been ignored in coverage calculations except for cases we can map an annotation only localId to a relevant expression localId. This most commonly occurs with creation and usage of aliases. This helps to make sure they are accurately highlighted. With fqm-execution 1.6.0 we are switching the highlighting of the annotation only localIds for which we could not find a relevant expression to link them to simply inherit the highlighting of the parent node. This fixes various highlighting bugs that were showing a gap in coverage even though the coverage calculation was at 100%.

Coverage Changes

There are times where localIds are ONLY found in the expression stack and not in the annotation stack. In these cases a gap in coverage would not be able to be highlighted to show the gap in coverage. This commonly results from translator expanding out CQL with QICore profiled authoring or something simple as is not null as expressed in this issue cqframework/clinical_quality_language#1417. The approach we are taking to resolve this is that if the user cannot see the logic, it shouldn’t be counted in the coverage calculations. These 'hidden' clauses often do have results that bubble up to an expression that can be 'seen'. With fqm-execution 1.6.0 we are filtering out clauses that do not have corresponding localIds in the annotation structure. This will remove the chance that uncovered clauses that cannot be highlighted will affect the coverage calculation.

Full Changelog: v1.5.0...v1.6.0

v1.5.0

What's Changed

• Sort mustSupports, compare DRs with direct reference codes by @elsaperelli in #300
• Fix QueryFilter parsing on optional Query relationship field by @hossenlopp in #305
• Applies to stratifiers by @elsaperelli in #307
• appliesResult to StratifierResult in detailed results output by @elsaperelli in #308
• Update cql-execution to 3.1.0 by @hossenlopp in #309
• v1.5.0 by @hossenlopp in #310

New Feature - Stratification appliesResult

detailed calculation output now includes appliedResult in the stratifier results which gives the result with the cqfm-appliesTo population result 'applied' to it. This appliedResult makes it so the stratifier is a subset of the referenced population.

Implies Operator

This release upgrades cql-execution to 3.1.0 which brings support for the Implies operator.

Full Changelog: v1.4.1...v1.5.0

v1.4.1

What's Changed

• v1.4.1 by @hossenlopp in #303

This is simply a re-release that fixes an issue in our build that allowed a filename casing change to fail to propagate through the build process. This case change issue was hidden by the macOS APFS case insensitive file system. v1.4.1 will be required to run on case sensitive file systems.

Full Changelog: v1.4.0...v1.4.1

v1.4.0

What's Changed

• Refactor to separate gaps and data requirements by @lmd59 in #293
• Translator 3.6.0+ fixes by @elsaperelli in #296 #298
• Data requirements comparison script by @elsaperelli in #295
• Uncoverage by @hossenlopp in #299
• Highlighting compliance by @elsaperelli in #301
• v1.4.0 by @elsaperelli in #302

Notice of Clause Coverage Percentage Changes (cql-to-elm translator versions >= 3.6.0 ONLY)

For measures translated using newer versions of the cql-to-elm translator (version 3.6.0 and up), clause coverage highlighting and percentage increases compared to fqm-execution v1.3.3 due to handling of the additional localIds that were added in the ELM from the translator in version 3.6.0. Clause coverage percentage for measures using versions of the translator >= 3.6.0 is NOT going to be identical for measures that use older versions of the translator.

New Feature - Uncoverage

fqm-execution can now produce a new HTML output which highlights the measure logic which did NOT have a "truthy" value during calculation. This uses the same underlying calculation as clause coverage but inverts the highlighting. This output can be enabled by using the calculateClauseUncoverage calculation option flag. This is enabled by default when running in the CLI and will be output with debug data.

As as side effect of this work, we were able to optimize the underlying coverage calculation and HTML generation to be significantly faster. This may be noticeable when running larger measures with larger sets of patients (>30).

New Feature - Coverage Details

Details on the coverage can now be returned from fqm-execution. This information gives the counts of all clauses, covered clauses and uncovered clauses. Additionally, if there are uncovered clauses their locations are listed. This output can be enabled by using the calculateCoverageDetails calculation option flag. This is enabled by default when running in the CLI and will be output with debug data.

Example of coverage details output:

{
  "population-group-1": {
    "totalClauseCount": 333,
    "coveredClauseCount": 330,
    "uncoveredClauseCount": 3,
    "uncoveredClauses": [
      {
        "localId": "97",
        "libraryName": "MAT6725TestingMeasureCoverage",
        "statementName": "Has Medical or Patient Reason for Not Ordering ACEI or ARB or ARNI"
      },
      ...
    ]
  }
}

Full Changelog: v1.3.3...v1.4.0

v1.3.3

What's Changed

• Check if dataRequirement resourceType does not have patient search params by @elsaperelli in #289
• Not Equal and Not Equivalent clause coverage calculation handling by @elsaperelli in #291
• v1.3.3 by @hossenlopp in #292

Notice of Clause Coverage Percentage Changes

In this release, an issue with the coverage percentage calculation for Not Equivalent clauses was fixed. When a !~ (Not Equivalent) clause is translated from CQL to ELM, it results in separate Not and Equivalent clauses, each with their own localId. This caused coverage percentage calculation to only reach 100% if both of these pieces of logic evaluated to true. With this update, only the Not clause is factored into the coverage percentage calculation, allowing users to reach 100% without both equivalent and not-equivalent data in test cases.

With the current version of the cql-to-elm translator, this is not a problem for != Not Equal clauses. The Not and the Equal are still separated by the translator, but only the Not clause has a localId; therefore, the Equal clause is not factored into the coverage percentage calculation and users can reach 100%. The lack of a localId on the Equal clause will be fixed by the translator in a future update. We account for this upcoming fix by including handling for both of these cases.

This change only affects the coverage percentage calculation and does not change visual highlighting of coverage.

Reminder

Some aliases, unions and library references will show visually as uncovered. These are caused by quirks in the ELM annotation and do not affect the coverage percentage calculation.

Full Changelog: v1.3.2...v1.3.3

v1.3.2

What's Changed

• Allow for UNHIT clauses to be highlighted as specifically uncovered by @hossenlopp in #282
• Update source parsing for query filter parsing by @sarahmcdougall in #280
• Data requirement profiles by @elsaperelli in #284
• Fix ValueSet reference finder to use proper resource field in relatedArtifacts by @hossenlopp in #286
• v1.3.2 by @hossenlopp in #288

Notice of Clause Coverage Highlighting Changes

In this release, an issue with the visual coverage for clauses that are related to conditionally relevant populations (ex. "Denominator Exclusions") was fixed. This issue caused not-covered clauses to show as covered in statements related to these populations in some situations. This change only affects the visual highlighting of coverage and does not change coverage percentage calculation. Users should now be able to see the lack of coverage visually in these cases.

Reminder

Some aliases, unions and library references will show visually as uncovered. These are caused by quirks in the ELM annotation structure and do not affect the coverage percentage calculation.

Full Changelog: v1.3.1...v1.3.2

v1.3.1

What's Changed

• Require cql-execution 3.0.1 or newer and bump to v1.3.1 by @hossenlopp in #278

This release simply updates the version requirement of cql-execution to ^3.0.1 to ensure users are getting the latest bug fixes made in cql-execution without needing to explicitly update the dependency in their applications.

Full Changelog: v1.3.0...v1.3.1

v1.3.0

What's Changed

• dataRequirements/gaps-in-care catch un-calculable intervals before they error out by @hossenlopp in #274
• Null and case coverage fixes by @elsaperelli in #273
• Add statement-level HTML to statement results by @sarahmcdougall in #270
• Additional alias highlighting by @elsaperelli in #276
• v1.3.0 by @hossenlopp in #277

Notice of Clause Coverage Highlighting Changes

The additional support for Null and false Literals addressed in #273 impacts both visual highlighting and clause coverage percentage calculation. Users may likely see an increase in coverage if these clauses are included in the measure logic CQL and are processed during calculation. For example, users may see an increase in coverage for measures where the “SDE Sex” define statement is included in the measure logic.

The support for aliases nested within queries from QICore-authored CQL (addressed in #276) impacts visual highlighting (as these aliases now get highlighted) but does not impact the clause coverage percentage.

Two bug fixes in the cql-execution engine are reflected in this release:
(1) The lack of reasonCode highlighting (referenced in #275) has been fixed. This impacts both visual highlighting and clause coverage percentage calculation. The fix makes no changes to the calculation results.
(2) The execution results may be impacted in cases where a timezone offset is used when converting a birthDate from a Date to a DateTime in the underlying cql-execution engine. This may result in a difference in the logic highlighting that is returned from fqm-execution.

New Statement-level HTML support

See the documentation section on statement-level HTML for details. This new feature adds a string of HTML markup to each statement result. It does not have any impact on the logic highlighting or clause coverage highlighting output.

Updated Support for --patients-directory CLI Option

When running fqm-execution from the CLI, the user can supply the --patients-directory CLI option to specify a directory of test cases to use for measure calculation. This option now supports the new MADiE test case export format by scanning one level deep within the specified directory, filtering out non .json files.

Full Changelog: v1.2.2...v1.3.0

v1.2.2

What's Changed

• Human readable pretty statement results for FHIR by @lmd59 in #257
• Order population expressions for HTML output by @elsaperelli in #260
• ts-node upgrade by @elsaperelli in #264
• Update clause coverage percentage calculation to capture all relevant clauses by @elsaperelli in #266
• v1.2.2 by @hossenlopp in #267

Notice of Coverage Calculation Percentage Changes

The fix for clause coverage in #266 means that the coverage percentage calculation now correctly correlates with the coverage highlighting. Users may likely see either a drop in coverage or potentially an increase in coverage. Measures with test cases that gave a result of 100% coverage in v1.2.1 may not see the same 100% coverage after this update. This means there likely are clauses in the logic that were not actually covered by the test cases, please refer users to the highlighting to look for gaps in their testing. No change was made to the visual coverage highlighting.

Full Changelog: v1.2.1...v1.2.2

v1.2.1

What's Changed

• Update weighted composite measure calculation to divide by sum of all weights by @lmd59 in #253
• Add coverage workaround for nested scopes within Property and FunctionRef by @mgramigna in #255
  • Read more here
• Add disableHTMLOrdering Calculation Option by @sarahmcdougall in #256
  • Read more here

Full Changelog: v1.2.0...v1.2.1