sarahmcdougall commented 1 year ago

Summary

For composite measure report building, filters the component results to those corresponding to groups defined by the CQFM Group Id extension (if applicable).

New behavior

Resources:

From the Multiple Populations section of the spec: "Component measures used in a composite SHOULD contain a single population group. For component measures that contain multiple population groups, the composite measure SHALL specify the specific group to be used in the composite using the cqfm-groupId extension."

Behavior does not change for calculating detailed results. Behavior does change for composite measure report building. When calculating the measure score, the component results will first be filtered so that the population results used for calculating the measure score are those that correspond to the specified groups. In other words, rather than considering all the component results across all the defined groups for measure score calculation, only one component result for a single group will be considered for measure score calculation. The logic can be broken down as follows:

If the component only contains one population group, that group is used to get the info necessary for measure report building
If the component contains multiple population groups and the CQFM Group Id extension is specified for the component, then the specified group will be used to get the info necessary for measure report building
If the component contains multiple populations groups and the CQFM Group Id extension is not defined for the component, an error is thrown

Code changes

MeasureBundleHelpers - helper functions that extract the group Id valueString from the defined CQFM Group Id extension and filter the component results according to the defined group Ids on the extension
CompositeReportBuilder - calls helper functions from MeasureBundleHelpers to extract the group Ids and filter the component results before looping through them for measure score calculation
New unit tests for extracting the group Id from the extension and for filtering the component results according to the defined groups on the extension

Testing guidance

Since no (known) composite measures exist in the wild, the best way to test functionality will be to run unit tests and integration tests. That being said, testing guidance is as follows:

Run unit tests —> tests that the Group Id extension can successfully be extracted and that the component results can be appropriately filtered
Run integration tests —> the integration tests do not test measure report building, but running them ensures that the detailed results are not filtered in any way (we only want to do filtering for report building)
To test via the CLI, refer to attached .zip. The .zip contains a directory of patients and two different measure bundles:
- composite-mb-no-extension.json - does not define the group Id extension. Component 1 has two defined groups. Should throw an error since a specific group is not specified with the extension.
- composite-mb-with-groupId.json - defines the group Id extension for Component 1. Component 1 has two defined groups. Should successfully build a composite measure report using the defined group.
- Test out edge cases by tweaking these measure bundles. For example, change the group Id extension in composite-mb-with-groupId.json to specify a non-existent group. This should throw an error.
- Test across the different composite scoring types. This can be done by changing the value of compositeScoring.coding.code on the composite measure in the measure bundle. At a minimum, test one of the scoring types that is checked in addPatientResults (all or nothing, opportunity, or linear) and test the weighted scoring type since that gets calculated in addWeightedResults.

composite.zip

github-actions[bot] commented 1 year ago

Coverage report

St.^{:grey_question:}	Category	Percentage	Covered / Total
🟢	Statements	86.25% (-0.19% 🔻)	2258/2618
🟡	Branches	75.4% (+0.15% 🔼)	2087/2768
🟢	Functions	89.41% (+0.08% 🔼)	422/472
🟢	Lines	86.57% (-0.21% 🔻)	2178/2516

Show files with reduced coverage 🔻

|

St.^{:grey_question:}

| File | Statements | Branches | Functions | Lines | | :----------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------- | :------------------------------------------------------------- | :---------------------------------------------------------- | :----------------------------------------------------------- | :------------------------------------------------------------- | | 🟢 |

`...` / CompositeReportBuilder.ts

|

88.62% (-9.42% 🔻)

|

75% (-5.86% 🔻)

|

96.43% (-3.57% 🔻)

|

88.62% (-9.42% 🔻)

|

Test suite run success

424 tests passing in 31 suites.

Report generated by 🧪jest coverage report action from 0245869c641f9710201f62a82d16a3b150ebb428

sarahmcdougall commented 1 year ago

I was trying some different test cases for this with @mgramigna and found an issue with the test case where there are two related artifacts of the same component (resource is the same) but the extensions of them are different groups. An example of this can be found at the bottom of the composite measures IG:

Ah, great catch. This example falls under part 2(c) here: "Multiple groups within the same measure may be referenced as different components of the same composite." I forgot this was possible because I keep thinking of measure and component as being synonymous, which isn't always the case since a measure can be referenced within multiple components. I'll update the storage method for mapping components to group Id

projecttacoma / fqm-execution

Add support for CQFM Group Id extension (composite measure report building) #243