Back to top

Encounter, Performed

Performance/Reporting Period
QDM Datatype (QDM Version 5.3):

Data elements that meet criteria using this datatype should document that the encounter indicated by the QDM category and its corresponding value set is in progress or has been completed.

Timing: The Relevant Period addresses:

  • startTime – the time the encounter began (admission time)
  • stopTime – the time the encounter ended (discharge time)

The Author dateTime addresses when an Encounter is documented. Documentation can occur at the beginning, during, at the end or subsequent to the end of an Encounter. The Author dateTime should be used only if the Relevant Period cannot be obtained.

The Location Period is an attribute of the attribute facility location addresses:

  • startTime - the time the patient arrived at the location;
  • stopTime - the time the patient departed from the location


QDM Category (QDM Version 5.3)


Encounter represents an identifiable grouping of healthcare-related activities characterized by the entity relationship between the subject of care and a healthcare provider; such a grouping is determined by the healthcare provider. A patient encounter represents interaction between a healthcare provider and a patient with a face-to-face patient visit to a clinician’s office, or any electronically remote interaction with a clinician for any form of diagnostic treatment or therapeutic event. Encounters can be billable events but are not limited to billable interactions. Each encounter has an associated location or modality within which it occurred (such as an office, home, electronic methods, phone encounter, or telemedicine methods). The encounter location is the patient’s location at the time of measurement. Different levels of interaction can be specified in the value associated with the element while modes of interaction (e.g., telephone) may be modeled using the data flow attribute.

Data Elements defined by this QDM Datatype:
QDM Attributes

Admission Source

The location from which the patient was admitted (e.g., physician referral, facility from which the patient was transferred).

Author dateTime

The time the data element was entered into the clinical software. Note, some datatypes include both Relevant Time and Author dateTime attributes. The purpose is to accommodate Author dateTime if the actual start and stop times are not available when evaluating for feasibility, and also to allow specification of a time for Negation Rationale.


Coded diagnoses/problems addressed during the encounter. The diagnoses attribute is intended to capture ALL diagnoses, including principal diagnosis. Use of the Encounter, Performed: diagnoses attribute and the Diagnosis datatype is redundant for relating the diagnosis to the Encounter, Performed. The Encounter, Performed: diagnoses syntax is preferred. Referencing the same diagnosis using Encounter, Performed (diagnoses attribute) and Diagnosis (datatype) should only occur if the measure must define a specified length of a prevalence period, e.g., the measure must assure that the diagnoses have been present for at least some defined time period before the encounter, and were addressed during the Encounter.

Discharge Disposition

The disposition or location to which the patient is transferred at the time of hospital discharge.

Facility Locations

The particular locations in a facility in which the diagnostic study or encounter occurs or occurred. Examples include, but are not limited to, intensive care units (ICUs), non- ICUs, burn critical-care unit, neonatal ICU, and respiratory-care unit. Each Encounter, Performed may have 1 or more locations. For example, a patient treated in multiple locations during an individual encounter might be expressed as: Encounter, Performed: Inpatient Admission, ICU (location period), Non-ICU Admission (location period), Rehab (location period). Facility Locations (plural) is used for Encounter, Performed since there may be more than one facility location used in any given encounter.

Length of Stay

The difference of the admission date/time and the discharge date/time for the encounter. This attribute should not be used for outpatient encounters.

Negation Rationale

The QDM attribute, negation rationale indicates 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 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. In this case, the 'thing not done' is rarely documented, especially as a code, in the patient record. To express such 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. Prior versions of QDM used the syntax, 'Procedure, Performed not done.' QDM 5.5 uses the syntax, 'Procedure, not Performed' and this is then associated with either a DRC or a value set used to identify 'the expected thing,' that in this case was not done. Negation Rationale attribute value indicates a one-time documentation of a reason an activity is not performed. Negation of QDM datatype-related actions for a reason always use the author dateTime attribute to reference timing.

Principal Diagnosis

The coded diagnosis/problem established after study to be chiefly responsible for occasioning the admission of the patient to the hospital for care.

Relevant Period

Relevant Period addresses the time between the start of an action to the end of an action. Each datatype using relevant period defines specific definitions for the start and stop time for the action listed.
Last Updated: Mar 31, 2020