eCQM Known Issues

FEisenberg edited this page Nov 8, 2018 · 16 revisions

eCQM Known Issues

This document provides a listing of known issues relative to CQL-Based eCQM support.

Measure Authoring Issues

Terminology Versioning

As part of the transition to support CQL, measures can now bind to terminology versions more flexibly than in the past. In particular, measures can specify the desired version of each code system to use in the expansion of a value set, or they can specify only a value set identifier, leaving version information to be determined in another way.

The ideal future state is to allow measures to be written without reference to a specific version of a value set, and allow the versioning information to be determined by program policy as a post-authoring step. However, there are more factors at play in enabling that functionality than just the specifications and authoring of the measures. As such, terminology version binding for measures authored in 2019 should be done using the same mechanisms used now for the QDM-Based measures.

Composite Measures

The STU3 release of the CQL-Based HQMF IG supports the definition of individual-based composite measures. These composite measures are supported by referencing the libraries of each component measure, and then provided population criteria that reference the component measures to create a combined population criteria. The implementation guide provides example formulas that illustrate how each of "All-or-nothing", "Opportunity", and "Patient-level Linear" scoring works. However, the formulas as published in STU3 do not account for denominator exception criteria of component measures correctly. These sections provide the corrected formulas.

All-or-nothing Scoring

The implementation guide describes All-or-nothing scoring as "includes an individual in the numerator of the composite measure if they are in the numerators of all of the component measures in which they are in the denominator." However, because the formulas provided are expressed only in terms of the individual population criteria for each component, they do not take into account the last part of that description (namely, in which they are in the denominator). To correct this, the formulas need to take denominator exclusions and denominator exceptions into account in the expression of the denominator. The following snippet provides an updated Numerator formula that addresses the issue:

define "ComponentMeasure1 Numerator Membership":
  ComponentMeasure1."Initial Population"
    and ComponentMeasure1."Denominator"
    and not ComponentMeasure1."Denominator Exclusion"
    and ComponentMeasure1."Numerator"

...

define "Numerator":
  "ComponentMeasure1 Numerator Membership"
    and "ComponentMeasure2 Numerator Membership"
    and "ComponentMeasure3 Numerator Membership"

Opportunity Scoring

For opportunity scoring, although the formulas are correct, they incorrectly use a reserved word in their description, case. To correct this issue, measure developers should choose an identifier that is not a reserved word, such as service. For example:

define "Initial Population":
("Patient Record" P
    where ComponentMeasure1."Initial Population"
        return { service: 'Service 1' }
)
    union ("Patient Record" P
        where ComponentMeasure2."Initial Population"
            return { service: 'Service 2' }
    )
    union ("Patient Record" P
        where ComponentMeasure3."Initial Population"
            return { service: 'Service 3' }

Patient-level Linear Combination Scoring

Patient-level Linear Combination Scoring is modeled as a continuous variable measure that gives numerator credit for the proportion of patients in the numerators of composite measures. The formulas given in the currently published implementation guide follow the established pattern for proportion measures, but do not correctly account for denominator exceptions. The corrected formula for component denominator and numerator membership is:

define "Is In Component 1 Denominator":
  ComponentMeasure1."Initial Population"
    and ComponentMeasure1."Denominator"
    and not ComponentMeasure1."Denominator Exclusion"
    and not (ComponentMeasure1."Denominator Exception" and not ComponentMeasure1."Numerator")

define "Is In Component 1 Numerator":
  ComponentMeasure1."Initial Population"
    and ComponentMeasure1."Denominator"
    and not ComponentMeasure1."Denominator Exclusion"
    and ComponentMeasure1."Numerator"
    and not ComponentMeasure1."Numerator Exclusion"

Additional Composite Measure Support

Additional composite measure features, such as support for tooling creation of the composite measure logic, and supporting component-level composite measures will be addressed in support of additional composite measures following the 2019 AU cycle.

Risk Adjustment Models

The base specifications provide support for identifying risk adjustment variables within measure specifications. However, no support is provided for communicating how those risk adjustment variables impact measure scoring (i.e. the risk adjustment model). More work is needed to identify requirements for risk adjustment models and to define a specification to support description and distribution of those models either as part of or in addition to measure definitions.

Tooling Issues

UCUM Validation

Measure authors expressed a need for validation of UCUM units used within measures. UCUM Validation has been incorporated into the CQL-to-ELM translator as of the CQL 1.3 release. However, the validation allows any unit that is a valid UCUM unit, which includes any annotations (such as {drinks}/day). The MAT environment supports configuring units that can be entered via selection, but users may still manually enter any valid UCUM unit and these annotated units are not allowed by the translator. Support for defining a list of allowed UCUM annotations is slated to be added to the CQL-to-ELM translator as part of a post-production release.

ConvertsTo() Operators

The 1.3.10 release of the CQL-to-ELM translator has an issue that results in incorrect translation errors when attempting to use any of the ConvertsTo() operators. Since the issue is minor, does not impact any of the annual update measures, and was identified late in the UAT cycle, there was not time to incorporate a release with this fix into the production tool chain. The issue will be addressed in a followup release of the CQL-to-ELM translator, but has not yet been scheduled for inclusion in the production tool chain.

Tooling Improvements and Optimizations

Many tooling issues identified during the 2018 AU cycle were addressed (including all critical issues), but there are still some non-critical issues outstanding. These items continue to be logged as issues in the CQL tooling repository and they are being addressed as part of the tooling maintenance process.

Standards Issues

CQL Clarifications and Enhancements

All critical items found during the 2018 AU cycle, as well as other comments that were submitted as part of the CQL STU were incorporated in an updated CQL specification that was balloted in May 2018. This ballot resulted in an updated CQL specification, version 1.3 (Release 1 STU 3) that is now published. Additional comments will be logged as STU comments during the STU period, which is currently through August 2019. These items will be discussed and resolved as part of the normal process of comment resolution for an HL7 standard within the stewarding work group (Clinical Decision Support). The current plan is to incorporate these changes into a Normative ballot of CQL in May of 2019. Should the need arise, an STU update process can be applied to address any critical items prior to that Normative ballot.

QDM Known Issues

QDM Immunization, Administered timing attribute advisory

Reference: QDM Issue Tracker QDM-211

eCQM implementers should interpret the author dateTime for Immunization, Administered as administered dateTime. The meaning of author dateTime for all other QDM datatypes remains unchanged. The next version of QDM will include this change (anticipated May or June 2019).

Description of the Issue: Quality measure developers use the Quality Data Model (QDM) Immunization, Administered datatype to request retrieval of a vaccine indicated by the corresponding value set or direct reference code was administered to the patient. As determined by the QDM User Group, the QDM datatype Immunization, Administered is supported by the following attributes. The general description of each is included below as defined in the QDM 5.4 document:

  • Dosage: Details of how medication is taken or is to be taken, i.e., the quantity (mg, cc, tablets) to be taken at a single administration.
  • Negation rationale: The reason that an action was not performed. Only QDM datatypes that represent actions (e.g., performed, recommended, communication, order, dispensed) allow the “negation rationale” attribute. The intent is to indicate a justification that such action did not happen as expected. This attribute specifically does not address the presence or absence of information in a clinical record (e.g., documented absence of allergies Vs lack of documentation about allergies). The syntax in the human readable HQMF is address in CQL examples and in the MAT User Guide. Prior versions of QDM used the syntax, “Procedure, Performed not done.” QDM 5.4 uses the syntax, “Procedure, not Performed.”
  • Reason: The thought process or justification for the datatype. In some measures, specific treatments are acceptable inclusion criteria only if a justified reason is present. Each of these measures uses a value set (often, but not exclusively, using SNOMED-CT®) to express acceptable justification reasons. Other measures specify reasons as justification for exclusions.
  • Route: The path by which the medication or substance should be taken into the body systems, such as intradermally, intrathecally, intramuscularly, intranasally, intravenously, orally, rectally, subcutaneously, sublingually, topically, or vaginally.
  • Author dateTime: The time the data element was entered into the clinical software.
  • Code: The single code or a member of the value set used to represent the quality data element. The code attribute explicitly specifies the value set (or direct reference code) filter such that the query will retrieve only values defined by the QDM data element value or value set.
  • Id: The identifier of a specific instance of any QDM data element. CQL logic uses the .id reference to specify that a query expects a specific instance of an element to be retrieved.

Specifically for Immunization, Administered, author dateTime is defined as “time of administration or time authored.” This ambiguity causes duplicate and confusing mapping for vendors implementing the related eCQMs. Vendors have to write special code to overwrite a true author dateTime with administered dateTime for one QDM datatype.

Considerations: Reviewing the options, the QDM User Group evaluated existing representations of time administered using the HL7 Fast Healthcare Interoperabilty Resources (FHIR) Standard for Trial Use (STU) 3.0:

  • The HL7 FHIR Immunization resource includes only one time element, date. http://hl7.org/fhir/stu3/immunization.html
  • The HL7 FHIR MedicationAdministration resource includes both an effectiveDateTime or an effectivePeriod, the former for use with administration at a single point in time, the latter for administration occurring over a period of time (e.g., an intravenous infusion). http://hl7.org/fhir/stu3/medicationadministration.html There is only one current immunization that might be administered over a period of time, the oral typhoid (Ty21a) vaccine, self-administered orally by patients as three capsules, each taken 48 hours apart. Review with the HL7 Public Health Workgroup in January 2018 indicates that this vaccine is documented once and no workflow exists for patients to document each dose as a separate administration.

There is no clear use case for an Immunization Administration effectivePeriod and the HL7 Immunization resource will not be updated to include an effectivePeriod. Therefore, the QDM User Group agreed to reference a single Immunization administered dateTime.

Summary: The next version of QDM is anticipated in Spring/Summer 2019 and will include the change from author dateTime to administered dateTime for Immunization, Administered. Until that new version of QDM is published, users should interpret the author dateTime for Immunization, Administered as administered dateTime. The meaning of author dateTime for all other QDM datatypes remains unchanged. This Known Issue is also addressed in the QDM Issues Tracker QDM-211.

QDM Procedure, Performed completion time

Reference: QDM Issue Tracker QDM-210

QDM does not provide a method to determine a procedure was adequately performed and not terminated without meeting its objective. Description of the Issue: Procedure, Performed template QRDA reporting template fixes the statusCode as “completed.” Thus all procedures are reported as completed with an end time (i.e., the end of the relevant period as defined in the Quality Data Model). However, although ended with a “completed” status, the procedure may not have been adequate to meet its objective. For example, a colonoscopy procedure may be terminated early due to patient, preparation or anesthetic factors but the procedure has an end time. A claim for such a procedure may include a CPT modifier to indicate the reason it was terminated, but the CPT modifiers are not included in the eCQM value sets. Using the current QDM 5.4, a measure developer can choose to specify that an incomplete procedure should be excluded. Using the existing QDM conceptual model, the eCQM expression would need to specifically exclude respective procedures with a QDM status attribute of “incomplete.” Without such exclusion, the measure report includes any procedure that is completed, whether successful or not. As such, completed but unsuccessful procedures include patients in numerators. Examples of existing CPT modifiers used to indicate terminated procedures in claims submitted https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/downloads/clm104c14.pdf, e.g.,:

  • Modifier 73: "surgical procedure is terminated due to the onset of medical complications after the patient has been prepared for surgery and taken to the operating room but before anesthesia has been induced or the procedure initiated"
  • Modifier 74: "a medical complication arises which causes the procedure to be terminated after anesthesia has been induced or the procedure initiated"
  • Modifier 52: "discontinued radiology procedures and other procedures that do not require anesthesia" By default, patients for whom claims include CPT modifiers are included as meeting numerator criteria in eCQM reports. Considerations: Feedback from vendors indicates that there is no clear, consistent manner in which EHRs or EHR implementers handle procedures that are inadequate to reach a conclusion regarding the reason for the procedure. Measure developers have not been able to find consistent ways to determine successful / adequate procedures. The HL7 Fast Healthcare Interoperability Resources (FHIR) Standard for Trial Use (STU) 3.0 Procedure resource includes two elements for consideration http://hl7.org/fhir/stu3/procedure.html:
  • Status - completed/not completed
  • Outcome - successful/unsuccessful/partially successful The status attribute is workflow related, i.e., the event has ended or it is still in progress. The outcome, however, is ambiguous; the definition of success depends on the instance of the procedure. The QDM User Group agreed that the issue significantly impacts routine clinical care and clinical decision support. Addressing procedure adequacy in an eCQM requires careful review of data capture feasibility, reliability and validity based on actual clinical documentation. Consideration regarding Procedure attributes is under review in the HL7 Patient Care Workgroup which manages the procedure resource. A new metadata element, “objective,” might more clearly allow the “outcome” to reference the objective to more explicitly determine if the outcome is successful, unsuccessful, or partially successful.
    This issue is also more pervasive than affecting procedures; it affects any activity including, but not limited to laboratory tests, diagnostic studies, physical exams, assessments. A corollary issue includes how to identify that an immunization administered from a manufacturer's lot that is subsequently recalled is identified so that the patient is recalled and receives a new dose of that vaccine. Please provide comments in the QDM Issue Tracker QDM-210 to help determine a potential resolution to this issue.

Differentiating Elective Vs Emergent or Urgent Encounters or Procedures

Reference: QDM Issue Tracker QDM-212 QDM datatypes Procedure, Performed and Encounter, Performed allow specification of a procedure or an encounter that has occurred, but neither allows differentiation of elective procedures or encounters from emergent or urgent ones As QDM is currently structured a measure developer must use a workaround by either excluding procedures with ICD-10 or CPT codes indicating emergent procedures or encounters, or by creating expressions to help define the intent. However, these workarounds are challenging with respect to capturing all the appropriate data. Current attributes for the Procedure, Performed and Encounter Performed QDM datatypes do not include any ability to reference urgency or priority. The Joint Commission (TJC) Technical Advisory Panel provided hospital feedback regarding availability of elective designation in existing systems. EHRs use “priority” to categorize surgeries or encounters. The challenge is that within the EHRs this concept is not a required element and it is rarely codified. The priority menu selection often includes elective, emergent, urgent, and emergent salvage. Some organizations are looking to code some of these concepts. SNOMED CT includes a qualifier concept for elective (SNOMED code: 103390000).
HL7 FHIR includes a resource for priority.

  • Resource: Encounter ** Encounter.priority *** Code system: ActPriority (16 concepts, including elective, emergency, pre-op)
  • Resource: Procedure ** ProcedureRequest *** Status of Procedure.Request.priority identities level of importance The QDM User Group met on October 17, 2018 and was generally supportive of adding the priority attribute to:
  • Encounter, Performed
  • Encounter, Order
  • Procedure, Performed
  • Procedure, Order The QDM User Group further suggested adding guidance language for measure developers:
  1. Caution should be used to constrain priority to surgical procedures or encounters (i.e., not to education or telephone calls), and
  2. Feasibility testing will be needed particularly when looking for documentation of a procedure or an encounter as elective versus non-elective. The issue requires further review before acceptance in the next version of QDM which is expected at the end of second quarter 2019. Please provide comments in the QDM Issue Tracker QDM-212 to help with QDM User Group discussions for this issue.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.