QDM Known Issues

QDM Known Issues

• QDM Procedure, Performed completion time (All QDM versions)
• Differentiating Elective Vs Emergent or Urgent Procedures (QDM 5.6)
• QDM Negation Rationale Timing (QDM 5.6)
• QDM Encounter, Performed diagnosis attribute timing (QDM 5.6)
• QDM Medication Active Timing (QDM 5.6)
• QDM Medication Dispense Timing (QDM 5.6)
• QDM Laboratory Test Performed Timing (QDM 5.6)
• QDM 5..6 Entities (QDM 5.6)

QDM Procedure, Performed completion time (All QDM versions)

Posted 15 March 2019, Updated 17 June 2021, Reviewed 20 June 2022, Reviewed 12 July 2023, Reviewed 29 December 2023

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: QDM does not provide a method to determine a procedure was adequately performed and not terminated without meeting its objective. QDM Procedure, Performed relevant period addresses end time as completed. The related QRDA reporting template fixes the statusCode as “completed.” Thus all procedures are reported as completed with an end time. However, some completed procedures 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 still has an end time. Determining which procedures are potentially inadequate or incomplete is challenging. CPT modifiers used with claims help to indicate the reason a procedure is terminated, but CPT modifiers are not included in eCQM value sets. 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: Using the current QDM 5.6, a measure developer can choose to specify that an incomplete procedure should be excluded using a QDM status attribute constrained to incomplete. 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 FHIR Procedure resource includes two elements that may be helpful (STU 3.0 - http://hl7.org/fhir/stu3/procedure.html, R4 version: https://hl7.org/fhir/R4/procedure.html):

• Status - completed/not completed
• Outcome - successful/unsuccessful/partially successful

A QDM Procedure, Performed maps directly to a FHIR Procedure with .status = completed. However, there is no direct representation of outcome in QDM to align with the FHIR Procedure.outcome element. Moreover, there is no standard definition of what is meant by a successful outcome. The QDM User Group agreed that addressing procedure adequacy in an eCQM requires careful review of data feasibility, reliability and validity based on actual clinical documentation. Multiple discussions in HL7 Workgroups suggest that the most effective way to identify an effective procedure is to look for an observation that indicates a desired result. Using the colonoscopy example, a successful result can be expressed as (a) no cancer/suspicious lesions, (b) polyps/suspicious lesions identified, etc. To address procedure adequacy, measure developers should review what represents success with subject matter experts in the field addressed by the measure.

Differentiating Elective Vs Emergent or Urgent Procedures (QDM 5.6)

Posted 15 March 2019, Updated 17 June 2021, Reviewed 20 June 2022, Updated 07 July 2023, Reviewed 29 December 2023

QDM 5.6 retired the "Procedure, Performed" priority attributeReference: QDM Issue Tracker QDM-212 Previous version, QDM 5.5 included Procedure, Performed attribute, "priority". The QDM User Group reviewed workflow to determine the priority of a procedure (i.e., elective Vs. urgent) and determined that a consistent process to reference such information does not exist. A list of some of the factors considered:

• The QDM Procedure, Performed attribute priority does not map easily to structures in an implemented EHR.
• HL7’s QI-Core / FHIR addresses the priority of a procedure based on the priority of the encounter during which it occurs, and the ServiceRequest (order) on which it is based, in a scheduling system or in a appointment system.
• The QI-Core/FHIR Procedure resource includes an element, Procedure.basedOn, allowing direct reference to the order element (ServiceRequest.priority) to specify the elective or urgent nature of a procedure. However, there is no current profile in QI-Core for Appointment or for Schedule.
• Further, feedback from vendors and clinicians suggests: ** Procedures intended to occur during a hospital encounter but scheduled prior to the initiation of the encounter may be referenced in scheduling systems or as “orders” not accessible from the encounter record. ** Changes to an existing procedure order priority may occur via verbal communication, messaging, or possibly by a change to the original ServiceRequest.priority, an appointment or in a scheduling system but workflow is sufficiently variable that the information is inconsistently available.

Measure developers should carefully address clinical workflow and documentation practice to evaluate feasibility for data elements. To determine the priority of a principal procedure use the Encounter, Performed priority attribute for the encounter in which the procedure occurs.

Negation Rationale Timing (5.6)

Posted 15 March 2019, Updated 17 June 2021, Reviewed 20 June 2022, Reviewed 12 July 2023, Reviewed 29 December 2023

JIRA Ticket QDM-219 indicated confusion about the language regarding timing of Negation Rationale. To clarify, the negation rationale attribute references a one-time documentation of a reason an activity is not performed. Hence, only author dateTime applies to Negation Rationale. QDM (5.6) provides the following clarifying language regarding negation rationale:

• In some cases CQL supports identifying when something has not occurred. In this case the condition, order, situation of interest would not be found in the patient record, because it has not occurred.
• Measure developers should use the QDM attribute negation rationale to indicate an action intentionally not taken for an acceptable reason. 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 versus lack of documentation about allergies).

QDM assumes that any information expected will be in a clinical record. The situation is different when something that normally would be expected to be done is specifically not done because of a valid clinical reason (such as the patient is allergic, they are suffering from a complication, or some other rationale). To express lack of evidence, an eCQM author should use a CQL “not exists” expression noted in the examples, and they must also capture the Negation rationale to capture a reason for the absence, i.e., the reason must be included to qualify as a negation rationale type expression.

The syntax in the human readable HQMF is described in CQL examples and in the MAT User Guide. QDM 5.4 and earlier versions used the syntax, “Procedure, Performed not done.” QDM 5.6 uses the syntax, “Procedure, not Performed” associated with either a direct reference code (DRC) or a value set used to identify “the expected thing,” that was not done. The negation rationale attribute value indicates a one-time documentation of a reason an activity is not performed and must always use the author dateTime attribute to reference timing.

Note, that for converting QDM-based measures to FHIR measures, the QDM-to-QI-Core Mapping section of the QI-Core Implementation Guide includes specific guidance for modeling QDM's concept of negation rationale using FHIR.

QDM Encounter, performed "diagnosis" attribute timing (QDM 5.6)

Posted 15 March 2019, Reviewed 17 June 2021, 20 June 2022, Revised 12 July 2023, Reviewed 29 December 2023

The Encounter, Performed diagnosis attribute is intended to capture ALL diagnoses, including the principal diagnosis, i.e., all diagnoses addressed during the encounter regardless of onset time and represented by the diagnosis (code) used in the expression. There is no dependency on the timing of the diagnosis in relation to the encounter.

QDM 5.6 (intended for 2023 and 2024 eCQM reporting) defines the Encounter, Performed "diagnosis" attribute such that it includes three components:

• Diagnosis (code)
• PresentOnAdmissionIndicator (code)
• Rank (positive integer) [to indicate a principal diagnosis by a Rank = 1]

In QDM 5.6, to reference an encounter diagnosis, the expression must include the diagnosis code component. The PresentOnAdmissionIndicator and Rank are optional components. The other components are optional. The expression should only include the presentOnAdmissionIndicator code and, or the rank if it is necessary to reference present on admission or principal diagnosis.

QDM Medication Active Timing (QDM 5.6)

Posted 21 November 2019, Updated 20 June 2022, Updated 12 July 2023, Reviewed 29 December 2023

The QDM datatype Medication, Active includes several time-related attributes:

• Relevant dateTime – the time the medication is active on the medication record if it was given or taken at a single point in time.
• Relevant Period – the start and stop time for an active medication on the medication record that is given or taken over a time interval

• startTime – when the medication is first known to be used (generally the time of entry on the medication list)
• stopTime – when the medication is discontinued (generally, the time discontinuation is recorded on the medication list) QDM Jira Ticket QDM-242 noted that the Relevant Period definition seems to require that a provider specifically discontinue a medication from the medication list, or that the EHR might automatically discontinue a medication when the time or number of doses allowed by the prescription should be completed.

The QDM User Group discussed this concern on October 16, 2019 noting several scenarios that suggest modification of the current Relevant Period end time definition should be considered:

• The medication may have lapsed based on medication dispensing events but the patient may be taking it at a reduced frequency; thus, the patient remains on the medication even though it has lapsed.
• Some EHRs automatically remove medications from a medication list based on a locally determined time after it has lapsed.
• Without clearly matching orders from dispensing events, the actual number of remaining doses cannot be determined.
• Physicians do not necessarily discontinue medications; they remove them from the active medication list during medication reconciliation. Based on these considerations the User Group concluded that only way to address the end of the Medication, Active Relevant Period is to indicate “When the medication is no longer active.”

Resolution:

• QDM 5.6 updated the definition for Relevant Period stopTime to: “when the medication is no longer active.”

Note that the QDM to QI-Core Mapping Tables also references active medication consistent with the US Core definition. US Core (and, by reference QI-Core) identifies medications on the active medication list using the MedicationRequest resource with a status = active and an intent = order (for physician orders) or intent = plan (for patient-reported medications).

QDM Medication Dispense Timing (QDM 5.6)

Posted 20 June 2022, Updated 12 July 2023, Reviewed 29 December 2023

QDM v5.6 includes 3 timing attributes for “Medication, Dispense”. Since these attributes also apply to other QDM datatypes; the specific timings associated with relevantDatetime and relevantPeriod are defined in the description associated with each QDM datatype. The QDM datatype “Medication, Dispense”, details the timing attributes as follows:

• relevant dateTime references the dateTime the prescription dispensing event occurred, i.e., the time the prescription was handed to the patient or patient’s representative; similar to the QI-Core MedicationDispense.whenHandedOver element, or, if that time is not available, the MedicationDispense.whenPrepared element
• relevantPeriod addresses the time period for which the dispensed supply is to be administered/taken (i.e., not including refills; each dispensing event relevantPeriod is evaluated individually); similar to the QI-Core MedicationRequest.dosageInstruction.timing
• author dateTime the date and time the dispensing event is recorded (or the reason for not dispensing is recorded)

Other QDM datatypes use relevantPeriod to indicate the time a specific event starts until that event ends, e.g.,

• “Medication, Administration” uses relevantPeriod to reference the start and stop times of an intravenous infusion
• “Medication, Order” uses relevantPeriod to reference the time period the patient is expected to take the medication starting with the the initial prescription through the completion of all supply provided, including all available refills
• “Medication, Dispensed” relevantPeriod references the time period the patient is expected to take the medication starting with the the initial prescription through the completion of all supply provided, but NOT including refills as each refill represents a new dispensing event that has its own relevantPeriod Cumulative Medication Duration guidance generally recommends using daysSupplied (or calculating daysSupplied) rather than use of relevantPeriod to limit potential confusion.

Resolution:

• No further action required. The QDM 5.6 documentation provides this explanation. The addition to the QDM Known Issues provides additional visibility to the definitions as discussed in the QDM User Group on March 16, 2022.

QDM Laboratory Test Performed Timing (QDM 5.6)

Posted 21 November 2019, Updated 17 June 2021, Reviewed 20 June 2022, Reviewed 12 July 2023, Reviewed 29 December 2023

The QDM datatype Laboratory Test, Performed includes several time-related attributes:

• Relevant dateTime – the time the laboratory test is performed when the laboratory test occurs at a single point in time.

• Example – venipuncture to collect a blood specimen for fasting blood glucose.

• Relevant Period – the start and stop time for a laboratory test that occurs over a time interval

  • startTime – the time the laboratory test begins
  • stopTime – the time the laboratory test ends
  • Example – a 24-hour urine collection to measure creatinine clearance (initiation of collection until it is completed.
  • Relevant dateTime and Relevant Period represent the clinically relevant time or time period for the test, sometimes called the physiologically relevant time.

• Result dateTime – The time the result report is generated and saved in the database.

• Author dateTime – one-time documentation of a reason the laboratory test is not performed. QDM Jira ticket QDM-240 addresses the definition of the result dateTime attribute. Referencing HL7 FHIR R4 version, the concept most closely matches the Observation.issued, “the date and time this version of the observation was made available to providers, typically after the results have been reviewed and verified.”

• The QDM User Group reviewed the QDM 5.3, 5.4 and 5.5 definition and agreed to clarifying the definition for result dateTime. (Note this change also applies to QDM 5.6.) Rationale for this change:

• Feedback from an implementation site and three vendors indicates that most systems reference two times for a laboratory test: the collection time of the sample and the result time that most closely aligns with ‘issued’ or made available.

• There are cases where a health information exchange (HIE) receives the result before making it available to the clinical site, thus potentially delaying availability. However, such differences in availability result from local implementation issues.

Resolution:

• Update the definition for result dateTime consistent with FHIR R4 Observation.issued: The date and time this version of the observation was made available to providers, typically after the results have been reviewed and verified.
• QDM 5.6 includes this updated definition.
• Example scenario:
  • A laboratory technician obtains a blood specimen for a serum glucose test at 0600
  • The laboratory receives the specimen at 0700 and begins the testing
  • The laboratory finalizes the result at 0800 and issues that result
  • The result dateTime is 0800.
• Laboratory Test, Performed author dateTime should only be used to reference the time for negation rationale, i.e., the time a physician enters a reason acceptable to the eCQM logic for not performing the laboratory test.

QDM 5.6 Entities (QDM 5.6)

Posted 03 September 2020, Updated 17 June 2021, Updated 20 December 2021 to indicate updates in QDM 5.6 and remaining challenges, Reviewed 20 June 2022, Revised 12 July 2023, Reviewed 29 December 2023

QDM 5.6 defines four entities:

• Patient – information about an individual receiving healthcare services
• Care PPartner – a person that assists with a patient’s care (i.e., a family member and non-family, non-professional caregiver) but who is not the direct target of care
• Organization – a grouping of people or organizations with a common purpose
• Practitioner – a person with a formal responsibility in the provisioning of healthcare or related services
• Location – the physical place where services and resources are provided.

Purpose of entities: Allow expressions to reference the performer of an activity and to specify details about that performer, and to allow evaluation of eCQMs that address attribution.

Examples provided in QDM 5.6:

2.6.1 Specifying an organization as an encounter participant 2.6.2 Specifying a practitioner as an encounter participant 2.6.3 Specifying an encounter organization identifier 2.6.4 Specifying a physical examination performed by a care partner 2.6.5 Specifying an individual actor as a member of an organization The first 4 examples are correctly stated but the example in 2.6.5 is not feasible as the QDM 5.6 version of Practitioner entity is missing an attribute, organization.id. That additional attribute would allow a specification indicating that the practitioner is a member of the organization performing the action. Thus, an expression can specify a procedure or intervention performed by a specific practitioner and/or performed by a specific organization, but the expression currently cannot indicate that the practitioner is a member of that organization. The practitioner and organization are independent actors with the current QDM 5.6 model.

The QDM User Group determined that specification of such granularity is not in scope for measure development (i.e., indicating a practitioner performer is part of an organization performer). Therefore, a future QDM version might include a new QDM Practitioner attribute (organization.id) but there is no plan for such an update and EHR vendors and implementers indicate the feasibility of capturing such granular detail is very low. The capability may wait for a transition to FHIR for measurement and reporting if a clear use case can be presented.