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