View raw Markdown
type: resourceresource: Encounter

Encounter

Introduction

Scope and Usage

A patient encounter is further characterized by the setting in which it takes place. Amongst them are ambulatory, emergency, home health, inpatient and virtual encounters. An Encounter encompasses the lifecycle from pre-admission, the actual encounter (for ambulatory encounters), and admission, stay and discharge (for inpatient encounters). During the encounter the patient may move from practitioner to practitioner and location to location.

Because of the broad scope of Encounter, not all elements will be relevant in all settings. For this reason, admission/discharge related information is kept in a separate admission component within Encounter. The class element is used to distinguish between these settings, which will guide further validation and application of business rules.

There is also substantial variance from organization to organization (and between jurisdictions and countries) on which business events translate to the start of a new Encounter, or what level of aggregation is used for Encounter. For example, each single visit of a practitioner during a hospitalization may lead to a new instance of Encounter, but depending on local practice and the systems involved, it may well be that this is aggregated to a single instance for a whole admission. Even more aggregation may occur where jurisdictions introduce groups of Encounters for financial or other reasons. Encounters can be aggregated or grouped under other Encounters using the partOf element. See below for examples.

Encounter instances may exist before the actual encounter takes place to convey pre-admission information, including using Encounters elements to reflect the planned start date or planned encounter locations. In this case the status element is set to 'planned'.

The admission component is intended to store the extended information relating to an admission event. It is always expected to be the same period as the encounter itself. Where the period is different, another encounter instance should be used to capture this information as a partOf this encounter instance.

The Procedure and encounter have references to each other, and these should be to different procedures; one for the procedure that was performed during the encounter (stored in Procedure.encounter), and another for cases where an encounter is a result of another procedure (stored in Encounter.reason) such as a follow-up encounter to resolve complications from an earlier procedure.

Status Management

During the life-cycle of an encounter it will pass through many statuses and subject statuses. Typically these are in order or the organization/department's workflow(s) e.g. planned, in-progress, completed/cancelled. In general terms the Encounter and Appointment both align with the Clinical Workflow Process Life Cycle pattern.
The status property tracks the (current) overall status of the encounter, whereas the subjectStatus property more closely tracks the patient explicitly. For example in a hospital emergency department the subjectStatus would reflect the patient's status e.g. arrived (when the patient first presents to the ED), triaged (when the patient is assessed by a triage nurse), etc.
This status information is often used for other things, and often an analysis of the status history is required for things like billing. This could be done by scanning through all the resource history versions of the encounter, checking the period of each, and then doing some form of post processing. However, this information is not always completed in real-time (or even in the same system) and needs to be updated over time - as a result the resource history is not adequate to satisfy these needs, and subsequently the new EncounterHistory resource provides this information
[%stu-note dstu%] In FHIR R4 and earlier this was done using the statusHistory and classHistory backbone elements, however with longer duration encounters (where a patient encounter might be considered active for years) this would become increasingly inefficient, and EncounterHistory remediates this issue. [%end-note%]

There is no direct indication purely by the status or subjectStatus field as to whether an encounter is considered "admitted".
The context of the encounter and business practices/policies/workflows/types can influence this definition. (e.g., acute care facility, aged care center, outpatient clinic, emergency department, community-based clinic).
Subject statuses of "arrived", "triaged" or "receiving-care" could be considered the start of the admission, and also have the presence of the admission sub-component entered.
The "discharged" status can be used when the patient care is complete but the encounter itself is not yet completed, such as while collating required information for billing or other purposes, or could be skipped and go direct to "completed". Refer to the appointment page for some sample possible workflows.
Also note that the binding for subjectStatus is "example" so that local use-cases could also include their own states to capture things like a "waiting" status if they decide to capture this in their specific workflow.

Subjects that have left without being seen would have a subjectStatus of departed, or possibly an implementer-specific code, while the Encounter.status could be completed or cancelled, depending on whether the patient had received some care before leaving, or other local business rules that could impact billing.

The "on-leave" subject status might or might not be a part of the admission, for example if the patient was permitted to go home for a weekend or some other form of external event.
During this time the encounter status itself might be marked as "on-hold". Local systems may have multiple different types of leave/hold and these can use appropriate combinations fo the status/subjectStatus fields to represent this.
The location is also likely to be filled in with a location status of "active".
For other examples such as an outpatient visit (day procedure - colonoscopy), the patient could also be considered to be admitted, hence the encounter doesn't have a fixed definition of admitted. At a minimum, we do believe that a patient IS admitted when the status is in-progress.

Boundaries and Relationships

The Encounter resource is not to be used to store appointment information, the Appointment resource is intended to be used for that. Note that in many systems outpatient encounters (which are in scope for Encounter) and Appointment are used concurrently. In FHIR, Appointment is used for establishing a date for the encounter, while Encounter is applicable to information about the actual Encounter, i.e., the patient showing up.
As such, an encounter in the "planned" status is not identical to the appointment that scheduled it, but it is the encounter prior to its actual occurrence, with the expectation that encounter will be updated as it progresses to completion. Patient arrival at a location does not necessarily mean the start of the encounter (e.g. a patient arrives an hour earlier than he is actually seen by a practitioner).

An appointment is normally used for the planning stage of an appointment, searching, locating an available time, then making the appointment. Once this process is completed and the appointment is about to start, then the appointment will be marked as fulfilled, and linked to the newly created encounter.
This new encounter may start in an "arrived" status when they are admitted at a location of the facility, and then will move to the ward where another part-of encounter may begin.

Communication resources are used for a simultaneous interaction between a practitioner and a patient where there is no direct contact. Examples include a phone message, or transmission of some correspondence documentation.
There is no duration recorded for a communication resource, but it could contain sent and received times.

Standard Extension: Associated Encounter
This extension should be used to reference an encounter where there is no property that already defines this association on the resource.

Notes

Notes

Example usage

As stated, Encounter allows a flexible nesting of Encounters using the partOf element. For example:

Exactly how the Encounter is used depends on information available in the source system, the relevance of exchange of each level of Encounter and demands specific to the communicating partners. The expectation is that for each domain of exchange, profiles are used to limit the flexibility of Encounter to meet the demands of the use case.

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-Encounter-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="Encounter-core"/>
  <version value="0.1"/>
  <name value="EncounterHL7Extensions"/>
  <title value="Encounter  H L7  Extensions"/>
  <status value="draft"/>
  <date value="2015-02-21T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - FHIR WG"/>
  <description value="Defines common extensions used with or related to the Encounter resource"/>
</ImplementationGuide>

Resource Packs

list-Encounter-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="Encounter-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/Encounter-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

encounter-event-mapping-exceptions.xml

Divergent Elements

Refer to the Notes section in the Patient resource for further details.

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=Note that internal business rules will determine the appropriate transitions that may occur between statuses (and also classes).

When missing it is the time in between the start and end values.

May differ from the time in Encounter.period due to leave of absence(s).

Unmapped Elements

encounter-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements