-
Type:
Other
-
Resolution: Answered
-
Priority:
Moderate
-
We will not move forward with the proposed change during this annual update.
Brief Description of Measure:
CMS529: Core Clinical Data Elements for the Hybrid Hospital-Wide Readmission (HWR) Measure with Claims and Electronic Health Record Data
This logic is intended to extract electronic clinical data. This is not an electronic clinical quality measure and this logic will not produce measure results. Instead, it will produce a file containing the data that CMS will link with administrative claims to risk adjust the Hybrid HWR outcome measure. It is designed to extract the first resulted set of vital signs and basic laboratory results obtained from encounters for adult Medicare Fee-For-Service patients admitted to acute care short stay hospitals.
CMS844: Core Clinical Data Elements for the Hybrid Hospital-Wide (All-Condition, All-Procedure) Risk-Standardized Mortality Measure (HWM):
This logic is intended to extract electronic clinical data. This is not an electronic clinical quality measure and this logic will not produce measure results. Instead, it will produce a file containing the data that CMS will link with administrative claims to risk adjust the Hybrid HWM outcome measure. It is designed to extract the first resulted set of vital signs and basic laboratory results obtained from encounters for adult Medicare Fee-For-Service patients admitted to acute care short stay hospitals.
Description of Issue:
The Hybrid HWR (CMS 529) and Hybrid HWM (CMS 844) measures aim to collect vital sign (physical exam) and laboratory result data for patients with encounters during the measurement period, when those results are within a specific time window of the encounter of interest. A new QDM 5.6 attribute 'relatedTo' provides opportunity to add more specificity to ensure laboratory and physical exam results are related to the appropriate encounter of interest.
We are interested in feedback on potential logic changes to incorporate the relatedTo attribute. We also request feedback on if the logic change adds value for implementers, and is easily understandable.
Three proposed options are captured in the Proposed Solution field.
Proposed Solution:
The following three options are being considered:
OPTION 1. No logic change; keep specification as is for both 'FirstLabTestWithEncounterId' and 'FirstPhysicalExamWithEncounterId' functions.
FirstLabTestWithEncounterId:
"Inpatient Encounters" Encounter
let FirstLab: First(LabList Lab
where Lab.resultDatetime during Interval[start of Encounter.relevantPeriod - 1440 minutes, start of Encounter.relevantPeriod + 1440 minutes]
sort by resultDatetime
)
return
OPTION 2. Update logic to include relatedTo attribute, for both 'FirstLabTestWithEncounterId' and 'FirstPhysicalExamWithEncounterId' functions (example of change provided):
FirstLabTestWithEncounterId:
"Inpatient Encounters" Encounter
let FirstLab: First(LabList Lab
where Lab.resultDatetime during Interval[start of Encounter.relevantPeriod - 1440 minutes, start of Encounter.relevantPeriod + 1440 minutes]
and(Encounter.id in Lab.relatedTo)
sort by resultDatetime
)
return
OPTION 3. Update logic to include relatedTo attribute and 'not exists' logic, for both 'FirstLabTestWithEncounterId' and 'FirstPhysicalExamWithEncounterId' functions (example of change provided):
FirstLabTestWithEncounterId:
"Inpatient Encounters" Encounter
let FirstLab: First(LabList Lab
where Lab.resultDatetime during Interval[start of Encounter.relevantPeriod - 1440 minutes, start of Encounter.relevantPeriod + 1440 minutes]
and(Encounter.id in Lab.relatedTo
or not exists Lab.relatedTo
)
sort by resultDatetime
)
return
Rationale for Change:
Aim to add more specificity to ensure laboratory and physical exam results are related to the appropriate encounter of interest.