Final draft of QDM version 5.6 currently under review and editing QDM v5.6-Draft_28Oct2020v7.zip 

Follow up - All proposed changes were approved by the eCQM Governance Group on November 24, 2020.  Publication will proceed after review by various contractors.

For final review by the eCQM Governance Group before final approval of QDM v5.6

The QDM User Group met on November 18, 2020 and approved the following changes for version 5.6:

Changes to QDM Entities (new items in bold):

• Patient
  • identifier
  • id (instance identifier)

• Care Partner
  • identifier
  • id (instance identifier)
  • relationship

• Practitioner
  • identifier
  • id (instance identifier)
  • role
  • specialty
  • qualification
  • organization
  • location

• Organization
  • identifier
  • id (instance identifier)
  • organizationType
  • location

New QDM Entity:

• Location
  • identifier
  • id (instance identifier)
  • locationType

Other additions

• Add relatedTo attribute to “Procedure, Performed”
• Create new interpretation attribute for “Laboratory Test, Performed”
• Update all definitions and guidance recommended in the QDM v5.5 Guidance Update published in May 2020
• Update Cumulative Medication Duration calculation section (5.7) and create a QDM Known Issue with this information for QDM 5.5.
• Retain and clarify relevantPeriod for “Medication, Order” and “Medication, Dispensed”
• Add relatedTo for:
  • “Medication, Order”
  • “Medication, Dispensed”
• Add relatedTo with strict guidance about need to address feasibility based on testing, indicating that the addition is to maintain consistency with FHIR capabilities.  - The QDM User Group did not believe feasibility was highly likely:
  • “Encounter, Performed”
  • “Intervention, Performed”
  • “Laboratory Test, Performed”
  • “Diagnostic Study, Performed”
  • “Physical Exam, Performed”
• Add interpretation to “Diagnostic Study, Performed” only with strict guidance about need to address feasibility based on testing, indicating that the addition is to maintain consistency with FHIR capabilities - The QDM User Group did not believe feasibility was highly likely.
• Do Not retire QDM datatype “Symptom” and encourage engagement in HL7 FHIR efforts addressing the Condition Resource (The Patient Care Workgroup), possibly for the upcoming Working Group Meeting.

New items for QDM User Group November 18, 2020:

American Academy of Neurology requested the addition of interpretation to additional QDM datatypes (I.e., not only "Laboratory Test, Performed"). Awaiting further input for the discussion next week.

For discussion on the QDM User Group November 18, 2020:

• Still open issues about adding more relatedTo attribute assignments as in the comment above.
• Still open issue about whether to remove relevantPeriod attribute from "Medication, Dispensed" and "Medication, Order"
• Still open issue about whether to retire the QDM datatype "Symptom"
• New - discussed as part of a Known Issue - need to add new QDM Entity attributes:
  • location as an attribute for the entities Practitioner and Organization so that a Practitioner or Organization can be connected to a specific location
  • organization as an attribute for the entity Practitioner to allow indication that a Practitioner is a member of an organization
  • Change the Organization type attribute name to organizationType consistent with the QI-Core element so it can reference example codes as in organization_type value set
  • Location as a new QDM Entity to allow the Practitioner or Organization that is connected to it to include specific information about the Location entity - thus the attributes of Location should include: id, identifier, and locationType (allowing specification of a "type" of location setting) - (analogous to the QI-Core profile Location built on the FHIR Location resource - to allow Location Role Types

I attached a QDM v5.6-Draft_28Oct2020v5.zipincluding the changes already approved by the QDM User Group plus the new Entity Location and the new Entity attributes noted above - but NOT including the other items still under consideration regarding relatedTo additions or relevantPeriod changes for "Medication, Dispensed" or "Medication, Order" or whether to keep "Symptom" as a datatype.

Continued QDM User Group 10-21-2020 - Item 4 (addition of relatedTo as an attribute for additional QDM datatypes)

4. Consider adding the attribute relatedTo for:

• "Medication, Order" and "Medication, Dispensed"
  • Opioid use measure uses both “Medication, Order” and “Medication, Dispensed” to assure capture of all opioids regardless of where they are ordered.
  • Need to avoid double counting the same prescription identified by both QDM datatypes.
  • QI-Core includes MedicationDispense.authorizingPrescription to indicate the dispensing event is related to the prescription
  • Similarly MedicationRequest.basedOn allows reference to a CarePlan, MedicationRequest, ServiceRequest, or ImmunizationRecommendation as the reason for the order
  • Adding relatedTo for these two datatypes will enable measure expressions to avoid the duplication data issue
• “Encounter, Performed”, “Laboratory Test, Performed”, “Physical Exam, Performed” based on justification provided above regarding (CMS 529) “Hybrid Hospital-Wide Readmission” attempts to tie “Laboratory Test, Performed” and “Physical Exam, Performed” to a specific encounter.

• • Discussion centered around whether a relatedTo attribute would be able to reference an existing linkage in clinical software. While a "Laboratory Test, Performed" may have a linkage to a "Laboratory Test, Order" requested in the same software system, that linkage may not be readily available. Any linkage to the "Encounter, Performed" would require a timing comparison rather than use of relatedTo. The same applies to the "Physical Exam, Performed". The challenge discussed is that a laboratory order generated based on what happened during an encounter may actually be ordered after the encounter ends. Also, the physical exam finding may be documented after the end of the encounter and it is not clear that the individual entering that observation will enter the exact time the observation occurred as distinct from the dateTime (timestamp) of the entry itself. Therefore, timing relationships may be the best way to consider connection between the encounter an a related activity.  Note - subsequent to the QDM UG call, an option might include indicating the performer of an order or observation is the same as the practitioner performing the encounter. However, many encounters include multiple individuals (physician, nurse, aide, student, etc) so seeking the same performer id may not be sufficient either.
  • The discussion did lead to a question about whether additional relatedTo attributes might benefit future testing, specifically looking at actions that might be tied to (relatedTo) and order for that activity (e.g., "Laboratory Test, Performed" relatedTo "Laboratory Test, Order" as noted above). The group considered such potential additions but had significant reservations that there is insufficient linkage in the real world and adding the attribute could lead to burden. The alternative opinion suggested that absence of the attribute would limit testing and evaluation.
• Action - The QDM User Group did not approve any additions of the relatedTo attribute other than those previously considered ("Procedure, Performed") or already present in QDM. The group will consider possibilities before the next meeting.

SUMMARY of QDM 5.6 changes to date (October 21, 2020):

1. Add relatedTo to "Procedure, Performed" – Consistent with QI-Core Procedure.basedOn
2. Create a new interpretation attribute for "Laboratory Test, Performed" to accommodate reference to critical values – Consistent with QI-Core/US Core Observation.interpretation
3. Update all definitions and guidance recommended in QDM v5.5 Guidance Update published in May 2020.
4. Add new class attribute to "Encounter, Performed" to allow reference to telehealth visits - Consistent with QI-Core/FHIR Encounter.class
5. Update Cumulative Medication Duration Section (5.7) to remove the relevantPeriod calculations and create a KNOWN ISSUE for QDM V5.5 Guidance Update.

For consideration by the next call (November 18, 2020):

1. retire relevantPeriod attribute from "Medication, Order" and "Medication, Dispense" (only retire from these two QDM datatypes)
2. Add relatedTo attribute to:
   • "Medication, Order" – Consistent with QI-Core MedicationRequest.basedOn
   • "Medication, Dispensed" – Consistent with QI-Core MedicationDispense.authorizingPrescription
   • "Encounter, Performed" – Consistent with QI-Core Encounter.basedOn
   • "Laboratory Test, Performed" – Consistent with QI-Core / US Core Observation.basedOn
   • "Physical Exam, Performed" – Consistent with QI-Core Observation.basedOn
   • "Diagnostic Study, Performed" – Consistent with QI-Core Observation.basedOn
3. Consider retiring the QDM datatype "Symptom" 

Continued QDM User Group 10-21-2020 (item 3 - Cumulative Medication Duration):

5.7.3.2 “Medication, Dispensed”

• attributes used:
  • daysSupplied
  • dosage
  • supply
  • frequency
  • refills
  • relevant dateTime [when dispensing occurred -_ _whenHandedOver_ _in FHIR]

• Option 1 - use daysSupplied:
  • CMD = daysSupplied beginning with relevant dateTime (whenHandedOver)
  • Since daysSupplied references a single dispensing event, the measure should identify all dispensing events over the time period desired by the measure (e.g., within 180 days after start of “Diagnosis” prevalencePeriod

• Option 2 - when daysSupplied is absent, derive it from other existing data:
  • CMD = [(supply / (dosage * frequency)] beginning with author dateTime
  • supply is quantity provided, i.e., number of doses; dosage is units per dose; frequency is # times per day. Thus, dividing supply by (dosage times number of times per day) = daysSupplied as a derived value. Then calculation is the same as when daysSupplied is available.
  • relevant dateTime should be used as the start date, with the assumption that medication administration is expected to begin upon receipt.

5.7.3.3 “Medication, Administered”

• attributes used:
  • daysSupplied
  • dosage
  • frequency
  • refills
  • relevant dateTime [single point in time of administration]
  • relevantPeriod [start and stop of individual administration, e.g., infusion]
  • author DateTime [for time recorded]

• relevant dateTime or relevantPeriod may be used as appropriate for a given scenario. However, the Measure Authoring Tool will be providing the ability to indicate "Normalized Interval" which allows a single expression to allow whichever timing is present in the system use to retrieve data. Different implementations may document administrations occurring over a period of time as a single point in time. Therefore, the Normalized Interval will allow retrieval regardless of the local method for recording the timing.
• “Medication, Administered” is useful for medications administered directly to the patient by a clinician (inpatient or directly observed therapy <DOT>).
• A CMD expression needs to identify ALL administration events over the period of time desired to use the first administration relevant dateTime or start of the first administration relevantPeriod through the last administration during the desired time period.

Action: QDM User Group will consider removal of relevantPeriod as an attribute for "Medication, Order" and "Medication, Dispense" to avoid confusion.

Continued QDM User Group 10-21-2020:

3. Cumulative Medication Duration (CMD): QDM currently suggests use of "Medication, Order" and "Medication, Dispensed" relevantPeriod for calculating CMD as "relevantPeriod addresses the time referenced in the dosage instruction indicating when the medication administration should start and end." Section 5.7 further provides examples of using relevantPeriod for CMD calculations with relevantPeriod for "Medication, Order" (section 5.7.3.1) and for "Medication, Dispensed" (section 5.7.3.2). Further feedback and analysis indicate that a medication prescription rarely, if ever, contains the expected start date and expected end date on which the patient receiving the prescription should take the medication. Rather, CMD can be directly calculated using the daysSupplied starting with the date of the order, or the date of the dispensing event. If the daysSupplied is not present, it can be derived by [(supply / (dosage * frequency)] where supply is # doses provided, dosage is number of units per dose and frequency is the number of times per time period (usually day) a unit dosage should be taken. 

Recommended: Change the following sections:

5.7.3.1 "Medication, Order"

• attributes used:
  • daysSupplied
  • dosage
  • supply
  • frequency
  • refills
  • author dateTime [__dateTime_ _prescription authored]

• Option 1 - use daysSupplied:
  • CMD = daysSupplied, beginning with author dateTime * (1+ #refills)
  • Since daysSupplied addresses a single dispensing event, so multiply by (1 + number of refills)

• Option 2 - when daysSupplied is absent, derive it from other existing data:
  • CMD = [(supply / (dosage * frequency)] beginning with author dateTime * (1+ #refills) 
  • supply is quantity provided, i.e., number of doses; dosage is units per dose; frequency is # times per day. Thus, dividing supply by (dosage times number of times per day) = daysSupplied as a derived value. Then calculation is the same as when daysSupplied is available.

Continued....

2. (primary diagnosis discussion continued from previous comment block for QDM User Group 10-21-2020):

• CDA® R2 IG: National Health Care Surveys (NHCS): "Primary diagnosis: Primary diagnosis is an important organizing or grouping variable for patient encounters across inpatient, outpatient, and emergency settings and is used to record the encounter diagnosis of central focus and/or most important diagnosis among a set of encounter related diagnoses." Source: HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3 - US Realm, Volume 2 - Templates and Supporting Material, February 2020.
• Note - the STU 3 of the NHCS Implementation Guide (IG) includes the language indicated and uses a LOINC code for Primary diagnosis (18630-4). However, the current version of the NHCS IG in use is STU 1.2 referencing primary diagnosis with the LOINC code 52534-5, principal diagnosis.
• The term primary does not seem to be a requirement for claim submission. The Medicare Claims Processing Manual (rev 10211_7-10-20) Chapter 23 describes a professional claim as the first diagnosis as a line item.  "Outpatient Claims Diagnosis Reporting: For outpatient claims, provider report the full diagnosis codes for up to 24 other diagnoses that coexisted in addition to the diagnosis reported as the principal diagnosis."  Thus, for professional (ambulatory) claims, the term principal diagnosis is still used.  A professional claim (CMS-1500) allows listing of up to 12 diagnosis codes on line 21, each represented by a letter. Each service listed in section 24 allows pointers in column E to up to 3 diagnosis pointers to the diagnoses listed in line 21  (I.e., entry of letters representing the diagnoses). The first letter listed in column E for each service is the principal, or primary diagnosis for that service/procedure. The remaining diagnosis pointers indicate declining level of importance to the service line. 
• Conclusion: The term primary diagnosis has different meanings to different people and organizations. Documentation for claim submission will follow rules for claims. Claim designation of diagnosis may not correlate with the patient's perception or primary reason for visit. 
• Action: Maintain current QDM determination for principal diagnosis using "Encounter, Performed" diagnosis code, rank =1 (with the diagnosis representing the billing diagnosis). The User Group did not see a need to add a consideration for primary diagnosis and considered that any active diagnosis associated with an encounter is sufficient to meet criteria for eCQM expressions used in the ambulatory setting.   Additional note of interest: The Patient Care Workgroup (HL7) requested that the Patient Administration Workgroup model Encounter.diagnosis separately from Encounter.procedure. Currently all encounter diagnoses and procedures are addressed with the Encounter resource element diagnosis. The change is under consideration for FHIR R5.