QI-Core Implementation Guide: STU 4 (v4.0.0 for FHIR 4.0.0)

QI-Core Implementation Guide, Clinical Quality Improvement WG - CI build for vesion 4.0.0). This version is based on the current content of https://github.com/cqframework/qi-core/ and changes regularly. See the Directory of published versions

7.10.0 Encounter

QDM defines Encounter as 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.

7.10.1 Encounter Timing

Implementation considerations must be considered when referencing encounter periods (start to end time). Some clinical sites may leave Encounters "open" until all documentation has been completed which may take 72 hours or more. However, the actual encounter may have lasted for a much shorter time period (e.g., 15 minutes for an ambulatory encounter). This issue is addressed in The Office of the National Coordinator for Health IT (ONC) Issue Tracking System as item QDM-235. Two approaches clinical sites have used to manage this issue include:

  • Include a patient check-in and check-out time as part of the visit documentation. These times represent when the patient arrives and leaves, respectively, and these times are used for the Encounter relevant period. However, patient arrival at a location does not necessarily mean the start of the encounter (e.g. a patient arrives an hour earlier than he or she is actually seen by a practitioner).
  • Default an Encounter end as 23:59 on the date of the Encounter date if it is left open to allow completion of documentation and update the end time if the practitioner closing the chart enters a specific time that the encounter ended.

Undoubtedly, other clinical sites have implemented other solutions to documenting end times for ambulatory visits. Quality measure and clinical decision support (CDS) artifact authors should consider such issues when testing the validity and reliability of retrieved responses to data queries.

7.10.2 Encounter-Related Diagnoses and Procedures

Encounter.diagnosis refers to the list of diagnosis/diagnoses relevant to the encounter. The Encounter.diagnosis.use value differentiates if the diagnosis is the admission diagnosis (AD), the discharge diagnosis (DD), the chief complaint (CC), a comorbidity diagnosis (CM), a pre-op diagnosis (pre-op), a post-op diagnosis (post-op) or a billing diagnosis (billing).

Some quality measures used to evaluate care provided in hospital settings use concepts to define principal diagnosis and present on admission:

  • Principal diagnosis is defined as the condition that, after study, was determined to be the principal cause of the admission. QDM version 5.5 addresses that concept using the US-Core concepts Encounter.diagnosis.use value=billing with an diagnosis.rank=1.
  • Present on admission (POA) is an indicator assigned to Inpatient Encounter diagnoses and is used in quality and patient safety measures. QDM version 5.5 references this indicator as a component of each Encounter, Performed diagnosis The US-Core and FHIR Encounter resources do not address present on admission. However, the FHIR Claim resource includes a claim.diagnosis.onAdmission element referencing similar terms as the US UB-04 claim form to indicate present on admission – yes (y), no (n), unknown (u), and undetermined (w). QI-Core includes an extension on Encounter.diagnosis to reference the onAdmission element, thus enabling specification of an Encounter.diagnosis that is present on admission.
  • Principal procedure is the procedure performed for definitive treatment rather than diagnostic or exploratory purposes, or which is necessary to take care of a complication.


Principal procedure defines a procedures relationship to an encounter (most often an inpatient encounter). It has not relationship to the inherent nature of the procedure. Therefore, QI-Core includes an extension modeling Encounter.procedure in the same way as Encounter.diagnosis. The Encounter.procedure has a code to indicate the procedure code and a rank to indicate its ordinality such that rank=1 identifies the procedure as a principal procedure.

  • Elective procedure is another concept used in quality measurement, especially in hospital measures. A specific measure may have interest in evaluating care provided for elective procedures (e.g., hip surgery due to osteoarthritis) while excluding emergency, non-planned procedures (e.g., hip surgery due to acute fracture). The procedure code does not necessarily allow differentiation of the two concepts. A ServiceRequest.priority does have the ability to differentiate the urgency with which the request (or order) should be fulfilled. However, there is no element within the FHIR Procedure resource to address the issue. Encounter.priority allows specification of whether the encounter is elective. Since the Encounter.procedure can be linked to the ServiceRequest with its priority, there is no need to add a specific extension in QI-Core for Encounter.procedure.priority. Therefore, there is no direct mapping from the QDM Procedure priority attribute to QI-Core and measures considering the concept should reference QDM's Encounter, Order with its priority.

7.10.3 Encounter, Performed

QDM Context QI-Core R4 Comments
Encounter, Performed Encounter
Encounter.status consider constraint to - arrived, triaged, in-progress, on-leave, finished
Encounter.type type of service by CPT
QDM Attribute
Code Encounter.class ambulatory, ED, inpatient, etc.
id Encounter.id
Relevant Period Encounter.period start and end time of encounter
Diagnosis (code) Encounter.diagnosis.condition can be used for coded diagnoses
PresentOnAdmissionIndicator (code)
Rank (integer) Encounter.diagnosis.rank for each diagnosis role
Procedures Currently referenced as Procedure.priority in QDM 5.5. Principal procedures are more appropriately managed as Encounter.procedures; Elective procedures are more appropriately managed using Encounter.priority = elective with Encounter.procedure.rank =1.
Encounter.procedure.sequence Extension for Procedure.sequence to be consistent with the FHIR Claim resource includes a Claim.procedure.sequence used to uniquely identify procedure entries. Claim.procedure.type provides a relative ranking with two example concepts - primary (the first procedure in a series to produce an overall patient outcome) and secondary the second procedure in a series required to product an overally patient outcome). However, type refers to procedures within a serier for which one is first. Such a sequence does not assure that the first procedure is the principal procedure for an encounter.
Priority Encounter.priority
Length of Stay Encounter.length
Negation Rationale Not Addressed
Author dateTime Not Addressed
Admission Source Encounter.hospitalization.admitSource
Discharge Disposition Encounter.hospitalization.dischargeDisposition E.g., home, hospice, long-term care, etc.
Facility Locations
code Encounter.location.location
location period Encounter.location.period
Participant Encounter.participant.individual

7.10.4 Encounter, Order

To address the QDM attribute Encounter, Order see Service Request

7.10.5 Encounter, Recommended

To address the QDM attribute Encounter, Recommended see Service Request