QDM Known Issues

QDM Known Issues

• QDM Immunization, Administered timing attribute advisory (QDM 5.4)
• QDM Procedure, Performed completion time (All QDM versions)
• Differentiating Elective Vs Emergent or Urgent Procedures (QDM 5.5)
• QDM Negation Rationale Timing (QDM 5.4 and 5.5)
• QDM Encounter, Performed diagnosis attribute timing (QDM 5.4 and 5.5)
• QDM Assessment, Performed Timing (QDM 5.3 and 5.4)
• QDM QDM Medication Active Timing (QDM 5.4 and 5.5)
• QDM Laboratory Test Performed Timing (QDM 5.4 and 5.5)
• QDM 5.5 Section 2.6.5 Errata (QDM 5.5)

QDM Immunization, Administered timing attribute advisory (QDM 5.4)

Posted 30 October 2018, Reviewed 17 June 2021

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 and FHIR R4:

• The HL7 FHIR Immunization resource includes only one time element, date. http://hl7.org/fhir/stu3/immunization.html
• HL7 FHIR R4 allows Immunization.occurrence [https://hl7.org/fhir/R4/immunization-definitions.html#Immunization.occurrence_x_] and Immunization.recorded [https://hl7.org/fhir/R4/immunization-definitions.html#Immunization.recorded]
• 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.

Feedback regarding current documentation suggests that for Immunization Administration always references a single point in time. Therefore, the QDM User Group agreed to reference a single Immunization administered dateTime.

Summary: QDM 5.5 and 5.6 added Relevant dateTime to allow reference to the time the immunization was administered. For version 5.5, author dateTime should be used only to address negation rationale (i.e., immunizations intentionally not administered for a reason). In QDM version 5.4, author dateTime should address the actual dateTime the immunization was administered or the author time of the negation rationale. 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 (All QDM versions)

Posted 15 March 2019, Updated 17 June 2021

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.4 or QDM 5.5 and 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.5)

Posted 15 March 2019, Updated 17 June 2021

Reference: QDM Issue Tracker QDM-212 QDM 5.5 includes a new 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.
• 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, the QDM 5.5 datatype, Procedure, Performed, does not have a comparable attribute (relatedTo). 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, but workflow is sufficiently variable that the information is inconsistently available.

Updated guidance (for QDM 5.5):

• Avoid use of the priority attribute for the QDM datatype Procedure, Performed .
• 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.
• Note, QDM 5.6 retired the "Procedure, Performed" priority attribute

Negation Rationale Timing (QDM 5.4, 5.5, 5.6)

Posted 15 March 2019, Updated 17 June 2021

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.5 and 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.5 and 5.6 use 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| http://hl7.org/fhir/us/qicore/qdm-to-qicore.html] includes specific guidance for modeling QDM's concept of negation rationale using FHIR.

QDM Encounter, performed "diagnosis" attribute timing (QDM 5.4, 5.5, and 5.6)

Posted 15 March 2019, Reviewed 17 June 2021

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.

Note that QDM 5.5 (intended for 2021 and 2022 eCQM reporting) redefines the Encounter, Performed "diagnosis" attribute such that it now includes three components (with this same modeling in QDM 5.6 intended for 2023 eCQM reporting):

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

In QDM 5.5 or 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 Assessment, Performed Timing (QDM 5.3 and 5.4)

Posted 15 March 2019, Reviewed 17 June 2021

The QDM 5.5 version updates timing attribute options for Assessment, Performed to include Relevant dateTime, Relevant Period and author dateTime. The change allows eCQM expressions to reference the actual performance time (effective time) for an observation using the QDM Assessment, Performed datatype. QDM version 5.3 (used for eCQMs to be reported in calendar year 2019) and QDM version 5.4 (use for eCQMs to be reported in calendar year 2020) reference only author dateTime. The QDM User Group agreed in the April 2019 and May 2019 meetings that implementers can reference the actual performance time when retrieving data to meet measure expression criteria for Assessment, Performed. That capability may improve performance for eCQMs referencing observations (assessments) recorded after the end of an encounter but that actually occurred during the required time period. For those implementing measures using QDM 5.3 or 5.4 (2019 or 2020 reporting periods), the actual dateTime the assessment was performed may be substituted for the author dateTime.

QDM Medication Active Timing (QDM 5.4, 5.5, 5.6)

Posted 21 November 2019, Updated 17 June 2021

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:

• Update the definition for Relevant Period stopTime to: “when the medication is no longer active.”
• Implementers can use this updated definition for evaluating eCQMs using QDM 5.3 (2019 reporting), QDM 5.4 (2020 reporting) and QDM 5.5 (2021 reporting).
• Subsequent versions QDM will include this updated definition.

Note that the [QDM to QI-Core Mapping Tables|http://hl7.org/fhir/us/qicore/qdm-to-qicore.html] 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 Laboratory Test Performed Timing (QDM 5.4, 5.5, and 5.6)

Posted 21 November 2019, Updated 17 June 2021

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.
• Implementers can use this updated definition for evaluating eCQMs using QDM 5.3 (2019 reporting), QDM 5.4 (2020 reporting) and QDM 5.5 (2021 reporting).
• Subsequent versions QDM will include 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.5 Section 2.6.5 Errata (QDM 5.5)

Posted 03 September 2020, Updated 17 June 2021 to indicate updates in QDM 5.6 that correct this issue.

QDM 5.5 defines four entities:

• Patient
• Care Partner
• Organization
• Practitioner 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.5:

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 further evaluation determined that the fifth (2.6.5) example is not currently possible.

The example:

2.6.5 Specifying an individual actor is a member of an organization

Example provided in QDM 5.5:

define “Qualifying Encounters”

[“Encounter, Performed”: “Inpatient”] Encounter

where Encounter.participant is “Organization”

define “Eye Exam Order”

[Intervention, Order”: “Diabetic Eye Exam”] ExamOrder

where Exam.Order.requester is Practitioner

  and ExamOrder.requester.id in [Encounter.participant as Organization]

define “Eye Exam Complete”

[“Intervention, Performed”: “Diabetic Eye Exam”] EyeExam

where EyeExam.performer is Practitioner

  and Eye.Exam.performer.id in Encounter.participant.organization

I.e. The doctor ordering the diabetic eye exam and the doctor performing the exam are both members of the organization responsible for the initial encounter.

However, the entities are not fully specified to allow the "Encounter, Performed" participant to be an organization and the "Physical Exam, Performed" performer to be a practitioner who is a member of that referenced organization. It would require the ability to indicate:

ExamOrder.requester.organization is EyeExam.performer.organization is Encounter.participant in which both the ExamOrder.requester and the EyeExam.performed are both Practitioner members.

To so indicate requires a new attribute to the QDM Practitioner entity - I.e., organization.id and this new attribute requires a cardinality of 0..* since any given practitioner may be a member of more than one organization.

For now, the issue is being published as a QDM Known Issue (I.e., indicating the Section 2.6.5 in QDM 5.5 is incorrect).

The QDM User Group modified the entities in QDM 5.6 such that Practitioner now includes attributes of Organization and Location; Organization now includes attributes of organizationId and location, and a new Location entity includes an attribute of location.Id. This change allows more flexibility for defining relationships among the different entities. These changes are also consistent with modeling of the respective FHIR resources.