Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnexpectedProperty: Stratum strata-2 in group #311

Open
JSRankins opened this issue Sep 13, 2024 · 4 comments
Open

UnexpectedProperty: Stratum strata-2 in group #311

JSRankins opened this issue Sep 13, 2024 · 4 comments

Comments

@JSRankins
Copy link

JSRankins commented Sep 13, 2024

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
Copy link
Contributor

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
Copy link
Author

JSRankins commented Sep 20, 2024

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
Copy link
Contributor

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
Copy link
Author

JSRankins commented Oct 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants