projecttacoma / fqm-execution

fqm-execution is a library that allows users to calculate FHIR-based electronic Clinical Quality Measures (eCQMs) and retrieve the results in a variety of formats
https://projecttacoma.github.io/fqm-execution/
Apache License 2.0
18 stars 6 forks source link

UnexpectedProperty: Stratum strata-2 in group #311

Open JSRankins opened 2 months ago

JSRankins commented 2 months ago

Summary

In using the global CLI (v 1.5.0), ran into an issue with the associated measure and patient bundles for the reports method using something similar to following command:

fqm-execution reports -m "path\to\measures\EpisodeMeasure.json" -p "path\to\patients\Episode_Patient.json" -o "path\to\output\Individal_Report.json" --report-type individual --vs-api-key {apiKey}

The following error was received:

UnexpectedProperty: Stratum strata-2 in group 66dfc5b649447a49beca9124 not found in measure reports
    at C:\Users\user\AppData\Roaming\npm\node_modules\fqm-execution\build\calculation\MeasureReportBuilder.js:205:43
    at Array.forEach (<anonymous>)
    at C:\Users\user\AppData\Roaming\npm\node_modules\fqm-execution\build\calculation\MeasureReportBuilder.js:186:93
    at Array.forEach (<anonymous>)
    at C:\Users\user\AppData\Roaming\npm\node_modules\fqm-execution\build\calculation\MeasureReportBuilder.js:173:45
    at Array.forEach (<anonymous>)
    at MeasureReportBuilder.addPatientResults (C:\Users\user\AppData\Roaming\npm\node_modules\fqm-execution\build\calculation\MeasureReportBuilder.js:148:32)
    at C:\Users\user\AppData\Roaming\npm\node_modules\fqm-execution\build\calculation\MeasureReportBuilder.js:586:21
    at Array.forEach (<anonymous>)
    at MeasureReportBuilder.buildMeasureReports (C:\Users\user\AppData\Roaming\npm\node_modules\fqm-execution\build\calculation\MeasureReportBuilder.js:583:26) {
  debugOutput: undefined
}

The details method appears to work for the measure and patient bundles (response attached: Episode_Details.json): fqm-execution details -m "path\to\measures\EpisodeMeasure.json" -p "path\to\patients\Episode_Patient.json" -o "path\to\output\Episode_Details.json" --vs-api-key {apiKey}

Expected Behavior

Calculation and generation of individual report with the relevant results

Version or Commit

1.5.0

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

Measure Bundle: EpisodeMeasure.json

Patient Bundle: Episode_Patient.json

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

Used measurement period in Measure resource

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

3.3.2

hossenlopp commented 2 months ago

Hi @JSRankins,

Good catch! This does look like a small bug in our creation of MeasureReports when we made it able to handle stratifiers identified by code OR id. We will plan to resolve this soon.

Your example measure here does bring up another concern. We did not assume that there would be multiple cqfm-appliesTo extensions on a single stratification. We only handle the first one found right now. What should results look like when there are multiple cqfm-appliesTo entries on a single strata and what does it actually mean to do so?

JSRankins commented 2 months ago

Hi @hossenlopp. QM IG STU 4 CQFM Computable Measure Profile changed cardinality of appliesTo extension from 1..1 (which is what it was In STU 3) to 0..*. The description of the extension:

Indicates the population that this stratifier should apply to.

Based on CQI discussions, this extension is really just a way to say whether all populations or a subset of populations in the group should be stratified and provided back in a report or if all of the populations in the group should be stratified and reported back. Per the IG,

If none is specified, the stratification applies to all populations in the group.

Does that help?

hossenlopp commented 1 month ago

Hi @JSRankins,

That actually does not fit with what I remember from all of the discussions we had on various calls a few weeks ago. During those calls it was only noted that the appliesTo would be used once if used at all and it would define which population the stratification should be considered a subset of.

If appliesTo was not used at all, the stratification wouldn't be filtered on the result of any population in the group. This would give the same scoring for the stratifier as if it was "appliedTo" the Initial Population.

If appliesTo was used, it would be used with a single population given for appliesTo and that population would be used as a "prefilter" to the stratifier so the patient/episode would need to be in the appliesTo population to be counted scored in the stratification at all. For example a stratification with an "appliesTo" of Numerator would require a patient/episode to be in the Numerator to be counted in the startaification.

If multiple appliesTo are given, how should the results in the MeasureReport be structured? Should a separate stratifier object be returned for each appliesTo and how should these be identified?

JSRankins commented 1 month ago

Hi @hossenlopp. I understand the comment, but spec reads differently - constraint is 0..*. As far as how it would be reported - DEQM has a stratification individual report example that shows associated population counts under a stratifier: https://build.fhir.org/ig/HL7/davinci-deqm/MeasureReport-indv-measurreport-stratification-example.json.html. The example is a little weird because it is giving counts for SDEs, but that is how they are reported back in DEQM. Still, it will at least give you the structure. And I think the only difference is that the associated population would not be provided if it was not part of the associated appliesTo in the measure.