care-gap boolean-basis Measures only

[Capt-Mac]

Description

Currently care-gaps allows for any Measure resource of scoring type 'ratio' or 'proportion' to processed by the 'care-gap' population. The problem is that the basis of each Measure also needs to be restricted in order to have the 'CareGapStatusEvaluator' algorithm appropriately process the results of a Measure Report.

issue

When a Measure is a basis of 'boolean' it processes per subject whether or not they meet the criteria for care-gaps by looking at the improvementNotation, numerator, and denominator values. This means a subject is either "inDenominator" && "inNumerator" or not. This allows for a simple algorithm to say "open-gap" or "closed-gap".

The issue with 'resource' based Measures is that they can have criteria expressions for each population that produce multiple counts per population code for a specific subject/patient. This means that a patient could produce results that apply to all care-gap status critieria if interpreted per resource, or could gloss over the purpose of the Measure by just seeing if there is a positive value in the 'Numerator'.

Ideally a Care-gap useable Measure would be authored in a way that is Patient-care focused, where they either received recommended care, or did not.

Example Resource Measure

% of Encounters that received a specific test.

• initial-population: [Encounter-1][Encounter-2][Encounter-3][Encounter-4]
• denominator (opportunities for test Encounters): [Encounter-1][Encounter-2][Encounter-3]
• numerator (received test Encounters): [Encounter-1]

if evaluated on a Patient level per resource.

• [Encounter 4]- resource is 'not-applicable' to Measure
• [Encounter 3] & [Encounter 2] - resource is 'open-gap'
• [Encounter 1] - resource is 'closed-gap'

Therefore each resource would receive an applicable status, on a patient-level they would have 3 different care-gap status levels for the Measure, which is difficult to interpret.

current algorithm, if evaluated on Patient level and positive count per population

• inDenominator = true
• inNumerator = true

Therefore 'closed-gap' is the outcome, but that does not communicate the actual purpose of the measure, that care was met for 33% of Encounters. If a provider is meant to action this, then this interpretation fails to meaningfully derive a care-gap to resolve.

proposed solution

There is no one-size fits all interpretation of 'resource' based measures that allows for an algorithm to produce meaningful results in a standardized way, therefore we should not allow these types of Measures to be processed.

This request would restrict $care-gaps to only "boolean" basis Measures, to avoid a non-standardized solution.

Any existing Measures that look to leverage care-gaps, but are currently a 'resource' based Measure, will require a different implementation that is 'boolean' based in order to work.

This still allows for future implementations to solution 'resource' based measures, but until then will throw an error if requested.