CMS 996 STEMI: Coding of prior STEMI

XMLWordPrintable

    • Type: Hosp Outpt eCQMs - Hospital Outpatient eCQMs
    • Resolution: Answered
    • Priority: Moderate
    • Component/s: None
    • None
    • Sheila Danielson
    • Confluence Health
    • Hide
      Thank you for your inquiry regarding CMS996: Appropriate Treatment for ST-Segment Elevation.

      In understanding the logic in this measure, it is important to note that QDM does not prescribe the source of diagnosis data in an EHR. Diagnoses may originate from a patient’s problem list, encounter diagnosis list, claims data, or other sources within the EHR. As a result, CMS996 evaluates STEMI diagnoses based on how they are represented and timed within the QDM data model rather than their original clinical or billing context. The measure intends to capture STEMI during the ED encounter only.

      Within QDM, a diagnosis is represented with a prevalence period, where the onset dateTime corresponds to the start dateTime of the diagnosis and the abatement dateTime corresponds to the stop dateTime of the diagnosis. For CMS996, however, the measure logic does not evaluate diagnosis abatement, duration, or whether a diagnosis is ongoing. Instead, the logic evaluates whether a STEMI diagnosis is represented as beginning during the emergency department encounter or whether STEMI appears on the ED encounter diagnosis list.

      As a result, patients may be included in the CMS996 Initial Population when a STEMI diagnosis is represented in either of the following ways during a subsequent emergency department encounter:
      • the STEMI diagnosis onset dateTime (prevalencePeriod.start) is recorded as occurring during the ED encounter relevant period (the time from ED arrival or admission to ED discharge), or
      • the STEMI diagnosis is mapped to the ED encounter diagnosis list.

      In these scenarios, a prior STEMI diagnosis that remains reportable for coding or documentation purposes may be represented in a way that meets the CMS996 inclusion criteria, even when the ED visit is for an unrelated reason.

      To reduce the inclusion of historical STEMI diagnoses in CMS996, we recommend ensuring that STEMI is not documented as an ED encounter diagnosis unless it is actively being evaluated or treated during that encounter. Historical STEMI diagnoses should instead be documented in the patient’s problem list or another longitudinal diagnosis source that maps to the QDM “Diagnosis” datatype, with the onset dateTime accurately reflecting when the STEMI originally occurred. This ensures that the diagnosis does not appear to begin during an unrelated ED encounter and aligns the data representation with the intent of the measure logic.

      For reference, the CMS996 v6.3.000 measure logic defining an ED Encounter with STEMI Diagnosis is included below. This logic is also available on the eCQI Resource Center: [https://ecqi.healthit.gov/sites/default/files/ecqm/measures/CMS996-v6.3.000-QDM.html]:

      ED Encounter with STEMI Diagnosis
      "ED Encounter During MP" EDEncounterinMP
          where (exists (["Diagnosis": "STEMI"] DxSTEMI
            where DxSTEMI.prevalencePeriod starts during EDEncounterinMP.relevantPeriod))
          or (exists( EDEncounterinMP.diagnoses EncounterDiagnosis
            where EncounterDiagnosis.code in "STEMI" ))
      Show
      Thank you for your inquiry regarding CMS996: Appropriate Treatment for ST-Segment Elevation. In understanding the logic in this measure, it is important to note that QDM does not prescribe the source of diagnosis data in an EHR. Diagnoses may originate from a patient’s problem list, encounter diagnosis list, claims data, or other sources within the EHR. As a result, CMS996 evaluates STEMI diagnoses based on how they are represented and timed within the QDM data model rather than their original clinical or billing context. The measure intends to capture STEMI during the ED encounter only. Within QDM, a diagnosis is represented with a prevalence period, where the onset dateTime corresponds to the start dateTime of the diagnosis and the abatement dateTime corresponds to the stop dateTime of the diagnosis. For CMS996, however, the measure logic does not evaluate diagnosis abatement, duration, or whether a diagnosis is ongoing. Instead, the logic evaluates whether a STEMI diagnosis is represented as beginning during the emergency department encounter or whether STEMI appears on the ED encounter diagnosis list. As a result, patients may be included in the CMS996 Initial Population when a STEMI diagnosis is represented in either of the following ways during a subsequent emergency department encounter: • the STEMI diagnosis onset dateTime (prevalencePeriod.start) is recorded as occurring during the ED encounter relevant period (the time from ED arrival or admission to ED discharge), or • the STEMI diagnosis is mapped to the ED encounter diagnosis list. In these scenarios, a prior STEMI diagnosis that remains reportable for coding or documentation purposes may be represented in a way that meets the CMS996 inclusion criteria, even when the ED visit is for an unrelated reason. To reduce the inclusion of historical STEMI diagnoses in CMS996, we recommend ensuring that STEMI is not documented as an ED encounter diagnosis unless it is actively being evaluated or treated during that encounter. Historical STEMI diagnoses should instead be documented in the patient’s problem list or another longitudinal diagnosis source that maps to the QDM “Diagnosis” datatype, with the onset dateTime accurately reflecting when the STEMI originally occurred. This ensures that the diagnosis does not appear to begin during an unrelated ED encounter and aligns the data representation with the intent of the measure logic. For reference, the CMS996 v6.3.000 measure logic defining an ED Encounter with STEMI Diagnosis is included below. This logic is also available on the eCQI Resource Center: [ https://ecqi.healthit.gov/sites/default/files/ecqm/measures/CMS996-v6.3.000-QDM.html ]: ED Encounter with STEMI Diagnosis "ED Encounter During MP" EDEncounterinMP     where (exists (["Diagnosis": "STEMI"] DxSTEMI       where DxSTEMI.prevalencePeriod starts during EDEncounterinMP.relevantPeriod))     or (exists( EDEncounterinMP.diagnoses EncounterDiagnosis       where EncounterDiagnosis.code in "STEMI" ))
    • CMS0996v6
    • Patients in the denominator that do not belong for the given encounter.

      I have seen multiple other Jira tickets mentioning this issue, but it has not been directly addressed that I can locate.

      We have patients presenting to our EDs with a prior STEMI that has already been addressed. Per CMS billing guidelines (below), if it's within 28 days, the STEMI diagnosis is coded -

      Coding guidelines state:  
      ICD-10-CM Official Guidelines for Coding and Reporting FY 2026
      Section 1,Chapter 9.E.1

      “For encounters occurring while the myocardial infarction is equal to, or less than, four weeks old (28 days), including transfers to another acute setting or a post-acute setting, and the myocardial infarction meets the definition for “other diagnoses” (see Section III, Reporting Additional Diagnoses), codes from category I21 may continue to be reported.

      Section III. Reporting Additional Diagnoses

      • Section III. Reporting Additional Diagnoses GENERAL RULES FOR OTHER (ADDITIONAL) DIAGNOSES For reporting purposes, the definition for “other diagnoses” is interpreted as additional clinically significant conditions that affect patient care in terms of requiring: clinical evaluation; or therapeutic treatment; or diagnostic procedures; or extended length of hospital stay; or increased nursing care and/or monitoring.{}

      Patients who had a prior STEMI, presenting to our EDs with completely unrelated issues within the above timeframe are being included in our STEMI denominator as a result. 

            Assignee:
            Mathematica EH eCQM Team
            Reporter:
            Sheila Danielson
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved:
              Solution Posted On: