Encounter (QDM)

Back to Harmonization of Health Quality Information Models Page

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. 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. QDM defines three contexts for Encounter: Encounter, Order; Encounter, Performed; Encounter, Recommended.

Encounter, Order

QDM Attribute	QI Core Metadata Element	Comment
Encounter, Order	ReferralRequest.intent	Referral Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. For QDM datatypes with the context "order" the ReferralRequest.intent value shall be constrained to "order"
FacilityLocation	ReferralRequest.context	QDM matched to QI Core / FHIR
Negation Rationale	ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused)	Modeled as a procedure request - there is no Encounter request in QI Core
Reason	ReferralRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ReferralRequest.AuthoredOn	Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
Code	ReferralRequest.type	See also, Observation.category
id	ReferralRequest.id	QDM matched to QI Core / FHIR
Source	ReferralRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization on whose behalf the device or practitioner was acting

Encounter, Recommended

QDM Attribute	QI Core Metadata Element	Comment
Encounter, Recommended	ReferralRequest.intent	Referral Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. "Proposal" is most consistent with the ReferralRequest when applied to clinical decision support (CDS) in which the CDS proposes an action to a provider or to a patient. The QDM concept Recommended addresses expectations a provider gives to a patient. Such recommendations are most consistent with the ReferralRequest.intent value of "plan" (an intension to ensure something occurs without providing an authorization to act).
FacilityLocation	ReferralRequest.context	QDM matched to QI Core / FHIR
Negation Rationale	ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused)	Modeled as a procedure request - there is no Encounter request in QI Core
Reason	ReferralRequest.reasonCode	QDM matched to QI Core / FHIR
Author dateTime	ReferralRequest.AuthoredOn	QDM matched to QI Core/FHIR. Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
Code	ReferralRequest.type	See also, Observation.category
id	ReferralRequest.id	QDM matched to QI Core / FHIR
Source	ReferralRequest.requester	Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization on whose behalf the device or practitioner was acting

Encounter, Performed

QDM Attribute	QI Core Metadata Element	Comment
Encounter, Performed	Encounter (the .status metadata allows conformance to the specific QDM datatype context)	Constrained to status consistent with in-progress or finished.
Relevant Period	Encounter.period	QDM matched to QI Core / FHIR
Admission Source	Encounter.hospitalization.admitSource	QDM matched to QI Core / FHIR
Diagnosis	Encounter.diagnosis	QDM matched to QI Core / FHIR
Discharge Disposition	Encounter.hospitalization.dischargeDisposition	QDM matched to QI Core / FHIR
Length of Stay	Encounter.length	QDM matched to QI Core / FHIR
Negation Rationale	Encounter.extension (http://hl7.org/fhir/StructureDefinition/encounter-reasonCancelled)	Only applies to an encounter that was cancelled, not an encounter that was never planned for a specific reason.
Principal Diagnosis	Encounter.diagnosis.role Encounter.diagnosis.rank	Constrain Encounter.diagnosis.role to "Billing Diagnosis" and require Encounter.diagnosis.rank =1
Author dateTime	FHIR.provenance.recorded	FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
Code	Encounter.class	Encounter.class fits best with the type of encounter. Measure developers create their own values and might need to constrain the use to the suggested value set. The previous Encounter.class value set included OBS - observation defined as "Provision of care of women during pregnancy, childbirth and immediate postpartum period. Also known as Maternity." The updated value set includes OBSENC for "observation encounter" approved in the November 2017 Harmonization cycle.
FacilityLocations	Encounter.location	QDM matched to QI Core / FHIR
FacilityLocations code	Location.type	QDM matched to QI Core / FHIR
FacilityLocations location period	Location.period	QDM matched to QI Core / FHIR
id	Encounter.id	QDM matched to QI Core / FHIR