DRY extraction of measure for calculation

[sarahmcdougall]

Summary

Code refactors related to measure extraction for the calculate function and its helpers.

New behavior

Main motivation: Future work related to composite measure calculation will require looping over component measures and calling various helpers on each component measure. Therefore, we want to limit the amount of code duplication related to measure extraction since we will want to specify the measure outside the helper functions when looping over the components rather than doing a .find() for the first measure in the given bundle every time.

No new behavior should be introduced.

Code changes

• Update extractMeasurementPeriod to take in a measure rather than a bundle
• Update execute to take in a measure in addition to a bundle
• Update extractLibrariesFromMeasureBundle to take in an optional measure in addition to a bundle
• Various unit test updates to reflect changes to function inputs

Some context behind these changes:

• The change to extractMeasurementPeriod is pretty self-explanatory - there's no reason to duplicate the measure extraction within calculate and within extractMeasurementPeriod
• The change to execute comes from the overarching motivation for composite measure calculation. We still need to pass in the entire measure bundle in order to resolve ValueSets. However, we want to specify the measure being passed in rather than extracting it from the bundle once we are in the execute function. This will allow us to call execute on each component (or on the single measure in the non-composite case).
• The change to extractLibrariesFromMeasureBundle is a little more nuanced. We call this function from retrieveELMInfo, which itself is called from execute. Therefore, when calculating detailed results, we will want to specify the measure that we are extracting the libraries from (following the same idea of looping over components), and this measure is already passed in to retrieveELMInfo. However, the extractLibrariesFromMeasureBundle function is also used for calculateDataRequirements and calculateQueryInfo, where we don't really need to specify the measure beforehand (at least not within the scope of this task since we are only focusing on composite measure calculation for detailed results). Therefore, measure is an optional input and will be extracted from the passed-in bundle if it is not supplied as a separate input (open to thoughts on this)
• While the extractMeasureFromBundle functionality is not necessarily what we will want to use with composite measures (since it does a .find() to get the first measure), I kept the existing functionality for now - figured it was out of scope to change this logic without adding full support for composite measures

Testing guidance

• Run unit tests and basic detailedResults CLI commands to check that calculation behavior has not changed
• Inspect calculate to see if there are any other useful refactors we can make now to allow for more flexibility with measure calculation

[github-actions[bot]]

Coverage report

St.:grey_question:	Category	Percentage	Covered / Total
🟢	Statements	85.26% (-0% 🔻)	1995/2340
🟡	Branches	73.9% (-0.01% 🔻)	1767/2391
🟢	Functions	87.34% (-0.03% 🔻)	352/403
🟢	Lines	85.56% (+0.01% 🔼)	1926/2251

Show files with reduced coverage 🔻

|

St.^{:grey_question:}

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

`...` / ELMInfoCache.ts

|

78.38% (-0.57% 🔻)

| 43.9% | 71.43% |

80.56% (-0.53% 🔻)

|

Test suite run success

371 tests passing in 28 suites.

Report generated by 🧪jest coverage report action from 32926542c469869596a534c482724e41ef8c026f

[sarahmcdougall]

1. I know you were more focused on detailedResults for this task, so it is okay if you don't want to add this but I think you can eliminate a call to extractMeasureFromBundle in calculateDataRequirements with the following:

Yeah I saw this too but figured it's out of scope. But it's an easy fix so I'll add it

2. Also potentially not in the scope of the task and I didn't look into it too much, but I think it may be possible to make the constructor in MeasureReportBuilder take measure rather than MeasureBundle. I think this would eliminate a call to extractMeasureFromBundle in calculateGapsInCare.

Also saw this and figured it's out of scope for now. I don't want to mess with anything related to measure reports until we get detailed results working for composite measures, and it will cause a good deal of unit test fixes.