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.

The QDM User Group met on October 21, 2020 and concluded the following with respect to additions to QDM version 5.6 draft:

1. Add "Encounter, Performed" class attribute. This attribute parallels the QI-Core Encounter.class element which uses the ActEncounterCode value set; that value set includes the concept VR - "A patient encounter where the patient and the practitioner(s) are not in the same physical location. Examples include telephone conference, email exchange, robotic surgery, and televideo conference." The QDM class attribute will not be constrained to the VR code which is present in the VSAC HL7 V3 ActCode value set (as are other ActCodes). This new QDM attribute will also map directly to QI-Core Encounter.class in the next version or update of QI-Core. 
   • An additional question arose about how to use a CPT modifier code that indicates an encounter is virtual. There is currently no reference to CPT modifiers in the CMS Measures Blueprint and the modifiers are not present in VSAC. Presumably, use of "Encounter, Performed" class = VR would allow mapping of existing encounters with modifier codes to the class = VR to retrieve appropriate data.  However, for the 2021 AU cycle, the class attribute does not exist (QDM version 5.5). Will request input from Rob McClure and others about whether the reference should be included only in guidance or if there is a mechanism to address modifier codes.  Another question arose about other CPT modifier codes (I.e., not telemedicine-specific). The only known modifier codes discussed include the codes that indicate presence of a patient, medical or system reason for negationRationale. These concerns have been evaluated in the eCQM Governance Group previously, determining that negationRationale should be obtained from clinical and not claims data. Any further options regarding modifier codes will require specific use cases for evaluation.
2. The HL7 Plenary and Working Group meeting addressed an issue about defining a primary diagnosis which is distinct from principal diagnosis. The use case considered is that a patient should see the same diagnosis on the clinical visit summary as the Explanation of Benefits (EOB – claim) to avoid confusion or potential concerns about fraudulent claims. The concept addresses “What the clinician thinks is the most important diagnosis out of a set of encounter diagnoses.”
   • ++Currently, the CARIN Alliance defines principal diagnosis "The circumstances of inpatient admission always govern the selection of principal diagnosis. The principal diagnosis is defined in the Uniform Hospital Discharge Set (UHDDS) as 'that condition established after study to be chiefly responsible for occasioning the admission to the hospital for care.' The UHDDS definitions are used by hospitals to report inpatient data elements in a standardized manner. These data elements and their definitions can be found in the July 31, 1985 Federal Register (Vol. 50, No. 147), pp 31038-40. Since that time the application of the UHDDS definitions has been expanded to include all non-outpatient settings (acute care, short term, long term care and psychiatric hospitals; home health agencies; rehab facilities; nursing homes, etc). The UHDDS definitions also apply to hospice services (all levels of care)." ICD-10 diagnosis code are maintained by the National Centers for Health Statistics out of CDC. The guidelines are at: https://www.cdc.gov/nchs/data/icd/10cmguidelines-FY2020_final.pdf. 

Continued...

To Grace Glennon - I added your request for relatedTo additions for the QDM User Group next Wednesday, October 21. I have a question though. A completed Laboratory Test ("Laboratory Test, Performed") might be based on a "Laboratory Test, Order" that happens within the time bounds of the "Encounter, Performed". So should the "Laboratory Test, Performed" be relatedTo the "Laboratory Test, Order" that is tied to the "Encounter, Performed" using CQL expressions (rather than relatedTo the encounter directly)? The "Physical Exam, Performed" might also happen within the time bounds of the encounter (relative dateTime) rather than relatedTo the encounter. I think it will help to have this discussion next week.

Thanks

Floyd

All of the above items have been added to the October 21, 2020 QDM User Group Call.  If you entered a comment, please consider joining that call 2:30 - 4:30 PM October 21, 2020.  Thank you.

We are requesting consideration for also adding relatedTo as an attribute to Encounter, Performed, Laboratory Test, performed and Physical Exam, performed as well. Currently, the Hybrid HWR measure (CMS 529) attempts to tie laboratory and physical exam results to a specific encounter. A change to QDM 5.6 would allow for this to be more transparent to implementers.

currently the QRDA User Guide provides the following guidance for this measure:

This section provides guidance on how to submit the encounter id associated with a core clinical data element for hybrid measure voluntary submission. Association of the data element to the encounter id uses the Related To (2.16.840.1.113883.10.20.24.3.150:2017-08-01) template in conjunction with the Laboraty Test, Performed (V5) (2.16.840.1.113883.10.20.24.3.38:2019-12-01) and the Physical Exam, Performed (V5) (2.16.840.1.113883.10.20.24.3.59:2019-12-01) templates respectively.

to allow for submission of data for this portion of logic:

return

return

Review options for QDM 5.6

4. Consider errata for QDM 5.5 and update for QDM 5.6: Description for Cumulative Medication Duration and how to use relevantPeriod for "Medication, Order"; "Medication, Dispensed"; and "Medication, Administered".

QDM 5.5 section 5.7.3 provides guidance for calculating cumulative medication duration (CMD) for "Medication, Order" (section 5.7.3.1), "Medication, Dispensed" (section 5.7.3.2); and "Medication, Administered" (section 5.7.3.3) using relevantPeriod for each of these examples. Technically, that would work if prescriptions, and dispensed information had evidence of detailed dosage instruction indicating the date the medication should start and the date the medication should stop for the initial requested or actual dispensing event and for each refill.  Such information can be mapped to FHIR [MedicationRequest.dosageInstruction.timing for which timing is a period, or http://hl7.org/fhir/us/qicore/StructureDefinition-qicore-medicationdispense-definitions.html#MedicationDispense.dosageInstruction.timing for which timing is a period.  The challenge is that such detailed structured information is often lacking. More likely, there will be information about the QDM attribute daysSupplied which is comparable to http://hl7.org/fhir/us/qicore/StructureDefinition-qicore-medicationrequest- definitions.html#MedicationRequest.dispenseRequest.expectedSupplyDuration. 

The QDM User Group meeting on October 21, 2020 will discuss this issue to consider a possible Known Issue and suggestions for updating guidance in QDM 5.6.

3. Consider adding relatedTo as an attribute of "Medication, Order" and "Medication, Dispensed" in QDM 5.6, for discussion in the QDM User Group on October 21, 2020: A new issue presented in reviewing an opioid use measure trying to avoid double counting medications if the "Medication, Order" and "Medication, Dispensed" are both available for the same prescription. There is currently no method using existing QDM attributes to indicate that a dispensed medication is derived from / authorized by a specific medication order. FHIR does have such ability by the MedicationDispense.authorizedBy element which can reference the respective MedicationRequest. However, QDM does not include the relatedTo attribute in the “Medication, Order” or “Medication, Dispense” QDM datatypes.  That change will allow opioid measures to avoid double counting opioid prescriptions and dispensing since they cannot specify they are related events.

2. On August 19, 2020, the QDM User group also discussed a QDM 5.5 Known Issue and potential additional attribute organization.id to the QDM entity Practitioner:  

QDM 5.5 defines four entities:

• Patient
• Care Partner
• Organization
• Practitioner

Purpose: Allow expressions to reference the performer of an activity and to specify details about that performer.

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.

Moving forward, the QDM User Group will decide if QDM 5.6 should add the organization.id attribute to the Practitioner entity.  Note that FHIR allows the reference desired since PractitionerRole includes an organization element so such a change would be consistent with a future FHIR transition. The eCQM Governance Group also reviewed the QDM Known Issue on September 1, 2020.

1. Potential addition of class attribute to "Encounter, Performed" in QDM 5.6:  The QDM User Group met on August 19, 2020 and discussed the issue of how to use the FHIR concept Encounter.class in QDM. Encounter.class has a binding to a value set with a code VR for virtual visits; that value set also addresses other visit classes such as inpatient. ambulatory, emergency, field, etc.  In reviewing how current eCQMs address QDM's "Encounter, Performed" code attribute, most use terminologies recommended by the CMS Blueprint for all "Encounter, Performed"; "Encounter, Order" and "Encounter, Recommended" - SNOMED CT procedure (transition - CPT, HCPCS, ICD-9 procedure, ICD-10 PCS, ICD-10 CM).  Thus, the code attribute is the same for encounters performed, ordered or recommended.  Thus, the current QDM to FHIR mapping is incorrect (maps "Encounter, Performed" code to Encounter.class) and should change to map to Encounter.type for which the value set binding is consistent with current practice in eCQMs (ValueSet -us-core-encounter-type). That raises the question about whether QDM 5.6 should add an attribute, class, to "Encounter, Performed" to allow specific reference to the class as defined in FHIR and to include ability to use a VR (virtual) code, or, perhaps modifier codes to address telehealth visits.  More feedback from implementers will help determine if this approach is feasible and reasonable. The QDM User Group will consider such an additional attribute (I.e., class) for "Encounter, Performed" in QDM 5.6.  The next meeting of the QDM User Group is scheduled for October 21, 2020.

QDM "Encounter, Performed" includes a code attribute which has been used to indicate both the specific encounter and the class of the encounter. The QI-Core to QDM mapping in QI-Core STU 4.0.1 maps the QDM code attribute to Encounter.class (http://hl7.org/fhir/us/qicore/qdm-to-qicore.html#811-encounter).  Thus, adding a class attribute to QDM "Encounter, Performed" is redundant. However, there is no good way to indicate an "Encounter, Performed" code that might be used for multiple classes of visit (e.g., in-person and telehealth/virtual). The QDM User Group should discuss how to approach this issue going forward as it came up during the 2020 reporting/performance period when CMS allowed some ambulatory visit codes to be used for telehealth. One option is to use the facilityLocation attribute even though telehealth is a class and not a location.  Note that the value set used for Encounter.class is V3-ActEncounter (http://hl7.org/fhir/R4/v3/ActEncounterCode/vs.html); it includes a code for virtual (VR) visits.  The QI-Core Encounter.location.physicalType uses an example value set location-physical-type which indicates physical locations. SNOMED environments also indicate physical locations rather than class of visit.  Defer to discussion in the QDM User Group August 19, 2020.