---
type: "resource"
title: "Encounter"
resource: "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](#examples) 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](lifecycle#clinical) 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](https://build.fhir.org/ig/HL7/admin-incubator/StructureDefinition-EncounterHistory.html) 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](appointment#status-flow) 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
- The _class_ element describes the setting (in/outpatient etc.) in which the Encounter took place. Since this is important for interpreting the context of the encounter, choosing the appropriate business rules to enforce and for the management of the process, this element should be provided.
## Example usage
As stated, Encounter allows a flexible nesting of Encounters using the partOf element. For example:
- A patient is admitted for two weeks - This could be modeled using a single Encounter instance, in which the start and length are given for the duration of the whole stay. The admitting doctor and the responsible doctor during the stay are specified using the Participant component.
- During the encounter, the patient moves from the admitting department to the Intensive Care unit and back - Three more detailed additional Encounters can be created, one for each location in which the patient stayed. Each of these Encounters has a single location (twice the admitting department and once the Intensive Care unit) and one or more participants at that location. These Encounters may use the partOf relationship to indicate these movements occurred during the longer overarching Encounter.
- During the last part of the stay, the patient is visited by the members of the multi-disciplinary team that treated him for final evaluation - If relevant, for each of these short visits, an Encounter may be created with a single participant. Since these took place during the last part of the stay, the partOf element can be used to associate these short visits with either the third patient movement or the bigger overall encounter.
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)
- **[Encounter](/encounter-definitions#Encounter)** [0..*]: - An interaction during which services are provided to the patient
- **[Encounter.identifier](/encounter-definitions#Encounter.identifier)** [0..*]: [Identifier](/Identifier) Identifier(s) by which this encounter is known
- **[Encounter.status](/encounter-definitions#Encounter.status)** [1..1]: [code](/code) required:[encounter-status](/valueset-encounter-status) planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
- **[Encounter.businessStatus](/encounter-definitions#Encounter.businessStatus)** [0..*]: [BackboneElement](/BackboneElement) A granular, workflows specific set of statuses that apply to the encounter
- **[Encounter.businessStatus.code](/encounter-definitions#Encounter.businessStatus.code)** [1..1]: [CodeableConcept](/CodeableConcept) The current business status
- **[Encounter.businessStatus.type](/encounter-definitions#Encounter.businessStatus.type)** [0..1]: [Coding](/Coding) example:[encounter-businessstatus-type](/valueset-encounter-businessstatus-type) The kind of workflow the status is tracking
- **[Encounter.businessStatus.effectiveDate](/encounter-definitions#Encounter.businessStatus.effectiveDate)** [0..1]: [dateTime](/dateTime) When the encounter entered this business status
- **[Encounter.class](/encounter-definitions#Encounter.class)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[encounter-class](/valueset-encounter-class) Classification of patient encounter context - e.g. Inpatient, outpatient
- **[Encounter.priority](/encounter-definitions#Encounter.priority)** [0..1]: [CodeableConcept](/CodeableConcept) example:[v3-ActPriority](/valueset-v3-ActPriority) Indicates the urgency of the encounter
- **[Encounter.type](/encounter-definitions#Encounter.type)** [0..*]: [CodeableConcept](/CodeableConcept) example:[encounter-type](/valueset-encounter-type) Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
- **[Encounter.serviceType](/encounter-definitions#Encounter.serviceType)** [0..*]: [CodeableReference](/CodeableReference) example:[service-type](/valueset-service-type) Specific type of service
- **[Encounter.subject](/encounter-definitions#Encounter.subject)** [0..1]: [Reference(Patient](/Reference(Patient), [Group)](/Group)) The patient or group related to this encounter
- **[Encounter.subjectStatus](/encounter-definitions#Encounter.subjectStatus)** [0..1]: [CodeableConcept](/CodeableConcept) example:[encounter-subject-status](/valueset-encounter-subject-status) The current status of the subject in relation to the Encounter
- **[Encounter.episodeOfCare](/encounter-definitions#Encounter.episodeOfCare)** [0..*]: Reference([EpisodeOfCare](/EpisodeOfCare)) Episode(s) of care that this encounter should be recorded against
- **[Encounter.basedOn](/encounter-definitions#Encounter.basedOn)** [0..*]: [Reference(CarePlan](/Reference(CarePlan), [DeviceRequest](/DeviceRequest), [MedicationRequest](/MedicationRequest), [ServiceRequest](/ServiceRequest), [RequestOrchestration](/RequestOrchestration), [NutritionOrder](/NutritionOrder), [VisionPrescription)](/VisionPrescription)) The request that initiated this encounter
- **[Encounter.careTeam](/encounter-definitions#Encounter.careTeam)** [0..*]: Reference([CareTeam](/CareTeam)) The group(s) that are allocated to participate in this encounter
- **[Encounter.partOf](/encounter-definitions#Encounter.partOf)** [0..1]: Reference([Encounter](/Encounter)) Another Encounter this encounter is part of
- **[Encounter.serviceProvider](/encounter-definitions#Encounter.serviceProvider)** [0..1]: Reference([Organization](/Organization)) The organization (facility) responsible for this encounter
- **[Encounter.participant](/encounter-definitions#Encounter.participant)** [0..*]: [BackboneElement](/BackboneElement) List of participants involved in the encounter
- **[Encounter.participant.type](/encounter-definitions#Encounter.participant.type)** [0..*]: [CodeableConcept](/CodeableConcept) extensible:[encounter-participant-type](/valueset-encounter-participant-type) Role of participant in encounter
- **[Encounter.participant.period](/encounter-definitions#Encounter.participant.period)** [0..1]: [Period](/Period) Period of time during the encounter that the participant participated
- **[Encounter.participant.actor](/encounter-definitions#Encounter.participant.actor)** [0..1]: [Reference(Patient](/Reference(Patient), [Group](/Group), [RelatedPerson](/RelatedPerson), [Practitioner](/Practitioner), [PractitionerRole](/PractitionerRole), [Device](/Device), [HealthcareService)](/HealthcareService)) The individual, device, or service participating in the encounter
- **[Encounter.appointment](/encounter-definitions#Encounter.appointment)** [0..*]: Reference([Appointment](/Appointment)) The appointment that scheduled this encounter
- **[Encounter.virtualService](/encounter-definitions#Encounter.virtualService)** [0..*]: [VirtualServiceDetail](/VirtualServiceDetail) Connection details of a virtual service (e.g. conference call)
- **[Encounter.actualPeriod](/encounter-definitions#Encounter.actualPeriod)** [0..1]: [Period](/Period) The actual start and end time of the encounter
- **[Encounter.plannedStartDate](/encounter-definitions#Encounter.plannedStartDate)** [0..1]: [dateTime](/dateTime) The planned start date/time (or admission date) of the encounter
- **[Encounter.plannedEndDate](/encounter-definitions#Encounter.plannedEndDate)** [0..1]: [dateTime](/dateTime) The planned end date/time (or discharge date) of the encounter
- **[Encounter.length](/encounter-definitions#Encounter.length)** [0..1]: [Duration](/Duration) Actual quantity of time the encounter lasted (less time absent)
- **[Encounter.reason](/encounter-definitions#Encounter.reason)** [0..*]: [BackboneElement](/BackboneElement) The list of medical reasons that are expected to be addressed during the episode of care
- **[Encounter.reason.use](/encounter-definitions#Encounter.reason.use)** [0..*]: [CodeableConcept](/CodeableConcept) example:[encounter-reason-use](/valueset-encounter-reason-use) What the reason value should be used for/as
- **[Encounter.reason.value](/encounter-definitions#Encounter.reason.value)** [0..*]: [CodeableReference](/CodeableReference) preferred:[encounter-reason](/valueset-encounter-reason) Reason the encounter takes place (core or reference)
- **[Encounter.diagnosis](/encounter-definitions#Encounter.diagnosis)** [0..*]: [BackboneElement](/BackboneElement) The list of diagnosis relevant to this encounter
- **[Encounter.diagnosis.condition](/encounter-definitions#Encounter.diagnosis.condition)** [0..*]: [CodeableReference](/CodeableReference) example:[condition-code](/valueset-condition-code) The diagnosis relevant to the encounter
- **[Encounter.diagnosis.use](/encounter-definitions#Encounter.diagnosis.use)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[encounter-diagnosis-use](/valueset-encounter-diagnosis-use) Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
- **[Encounter.account](/encounter-definitions#Encounter.account)** [0..*]: Reference([Account](/Account)) The set of accounts that may be used for billing for this Encounter
- **[Encounter.dietPreference](/encounter-definitions#Encounter.dietPreference)** [0..*]: [CodeableConcept](/CodeableConcept) example:[encounter-diet](/valueset-encounter-diet) Diet preferences reported by the patient
- **[Encounter.specialArrangement](/encounter-definitions#Encounter.specialArrangement)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[encounter-special-arrangements](/valueset-encounter-special-arrangements) Wheelchair, translator, stretcher, etc
- **[Encounter.specialCourtesy](/encounter-definitions#Encounter.specialCourtesy)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[encounter-special-courtesy](/valueset-encounter-special-courtesy) Special courtesies (VIP, board member)
- **[Encounter.admission](/encounter-definitions#Encounter.admission)** [0..1]: [BackboneElement](/BackboneElement) Details about the admission to a healthcare service
- **[Encounter.admission.preAdmissionIdentifier](/encounter-definitions#Encounter.admission.preAdmissionIdentifier)** [0..1]: [Identifier](/Identifier) Pre-admission identifier
- **[Encounter.admission.origin](/encounter-definitions#Encounter.admission.origin)** [0..1]: [Reference(Location](/Reference(Location), [Organization)](/Organization)) The location/organization from which the patient came before admission
- **[Encounter.admission.admitSource](/encounter-definitions#Encounter.admission.admitSource)** [0..1]: [CodeableConcept](/CodeableConcept) preferred:[encounter-admit-source](/valueset-encounter-admit-source) From where patient was admitted (physician referral, transfer)
- **[Encounter.admission.reAdmission](/encounter-definitions#Encounter.admission.reAdmission)** [0..1]: [CodeableConcept](/CodeableConcept) example:[v2-0092](/valueset-v2-0092) Indicates that the patient is being re-admitted
- **[Encounter.admission.destination](/encounter-definitions#Encounter.admission.destination)** [0..1]: [Reference(Location](/Reference(Location), [Organization)](/Organization)) Location/organization to which the patient is discharged
- **[Encounter.admission.dischargeDisposition](/encounter-definitions#Encounter.admission.dischargeDisposition)** [0..1]: [CodeableConcept](/CodeableConcept) example:[encounter-discharge-disposition](/valueset-encounter-discharge-disposition) Category or kind of location after discharge
- **[Encounter.location](/encounter-definitions#Encounter.location)** [0..*]: [BackboneElement](/BackboneElement) List of locations where the patient has been
- **[Encounter.location.location](/encounter-definitions#Encounter.location.location)** [1..1]: Reference([Location](/Location)) Location the encounter takes place
- **[Encounter.location.status](/encounter-definitions#Encounter.location.status)** [0..1]: [code](/code) required:[encounter-location-status](/valueset-encounter-location-status) planned | active | reserved | completed
- **[Encounter.location.form](/encounter-definitions#Encounter.location.form)** [0..1]: [CodeableConcept](/CodeableConcept) example:[location-form](/valueset-location-form) The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
- **[Encounter.location.period](/encounter-definitions#Encounter.location.period)** [0..1]: [Period](/Period) Time period during which the patient was present at the location
## Mappings
- [Encounter Mappings](/encounter-mappings) — 101 mapping entries
## Implementation Guide
### implementationguide-Encounter-core.xml
```xml
```
## Resource Packs
### list-Encounter-packs.xml
```xml
-
```
## Search Parameters
- [account](/encounter-search#account) — **reference** — The set of accounts that may be used for billing for this Encounter — `Encounter.account`
- [appointment](/encounter-search#appointment) — **reference** — The appointment that scheduled this encounter — `Encounter.appointment`
- [based-on](/encounter-search#based-on) — **reference** — The ServiceRequest that initiated this encounter — `Encounter.basedOn`
- [class](/encounter-search#class) — **token** — Classification of patient encounter — `Encounter.class`
- [date](/encounter-search#date) — **date** — A date within the actualPeriod the Encounter lasted — `Encounter.actualPeriod`
- [date-start](/encounter-search#date-start) — **date** — The actual start date of the Encounter — `Encounter.actualPeriod.start`
- [end-date](/encounter-search#end-date) — **date** — The actual end date of the Encounter — `Encounter.actualPeriod.end`
- [diagnosis-code](/encounter-search#diagnosis-code) — **token** — The diagnosis or procedure relevant to the encounter (coded) — `Encounter.diagnosis.condition.concept`
- [diagnosis-reference](/encounter-search#diagnosis-reference) — **reference** — The diagnosis or procedure relevant to the encounter (resource reference) — `Encounter.diagnosis.condition.reference`
- [episode-of-care](/encounter-search#episode-of-care) — **reference** — Episode(s) of care that this encounter should be recorded against — `Encounter.episodeOfCare`
- [identifier](/encounter-search#identifier) — **token** — Identifier(s) by which this encounter is known — `Encounter.identifier`
- [length](/encounter-search#length) — **quantity** — Length of encounter in days — `Encounter.length`
- [location](/encounter-search#location) — **reference** — Location the encounter takes place — `Encounter.location.location`
- [location-period](/encounter-search#location-period) — **date** — Time period during which the patient was present at a location (generally used via composite location-period) — `Encounter.location.period`
- [location-value-period](/encounter-search#location-value-period) — **composite** — Time period during which the patient was present at the location — `Encounter.location`
- [part-of](/encounter-search#part-of) — **reference** — Another Encounter this encounter is part of — `Encounter.partOf`
- [participant](/encounter-search#participant) — **reference** — Persons involved in the encounter other than the patient — `Encounter.participant.actor`
- [participant-type](/encounter-search#participant-type) — **token** — Role of participant in encounter — `Encounter.participant.type`
- [patient](/encounter-search#patient) — **reference** — The patient present at the encounter — `Encounter.subject.where(resolve() is Patient)`
- [practitioner](/encounter-search#practitioner) — **reference** — Persons involved in the encounter other than the patient — `Encounter.participant.actor.where(resolve() is Practitioner)`
- [reason-code](/encounter-search#reason-code) — **token** — Reference to a concept (coded) — `Encounter.reason.value.concept`
- [reason-reference](/encounter-search#reason-reference) — **reference** — Reference to a resource (resource reference) — `Encounter.reason.value.reference`
- [service-provider](/encounter-search#service-provider) — **reference** — The organization (facility) responsible for this encounter — `Encounter.serviceProvider`
- [special-arrangement](/encounter-search#special-arrangement) — **token** — Wheelchair, translator, stretcher, etc. — `Encounter.specialArrangement`
- [status](/encounter-search#status) — **token** — planned | in-progress | on-hold | completed | cancelled | entered-in-error | unknown — `Encounter.status`
- [subject](/encounter-search#subject) — **reference** — The patient or group present at the encounter — `Encounter.subject`
- [subject-status](/encounter-search#subject-status) — **token** — The current status of the subject in relation to the Encounter — `Encounter.subjectStatus`
- [business-status](/encounter-search#business-status) — **token** — The current business status of the Encounter — `Encounter.businessStatus.code`
- [type](/encounter-search#type) — **token** — Specific type of encounter — `Encounter.type`
- [careteam](/encounter-search#careteam) — **reference** — Careteam allocated to participate in the encounter — `Encounter.careTeam`
[Full Search Parameters](/encounter-search)
## Examples
- [colonoscopy](/encounter-example-colonoscopy) — encounter-example-colonoscopy — Colonoscopy with an external service provider
- [emerg](/encounter-example-emerg) — encounter-example-emerg — Emergency transitioning into inpatient example
- [encounter-example](/encounter-example-encounter-example) — encounter-example
- [encounter-example-colonoscopy](/encounter-example-encounter-example-colonoscopy) — encounter-example-colonoscopy
- [encounter-example-emerg](/encounter-example-encounter-example-emerg) — encounter-example-emerg
- [encounter-example-f001-heart](/encounter-example-encounter-example-f001-heart) — encounter-example-f001-heart
- [encounter-example-f002-lung](/encounter-example-encounter-example-f002-lung) — encounter-example-f002-lung
- [encounter-example-f003-abscess](/encounter-example-encounter-example-f003-abscess) — encounter-example-f003-abscess
- [encounter-example-f201-20130404](/encounter-example-encounter-example-f201-20130404) — encounter-example-f201-20130404
- [encounter-example-f202-20130128](/encounter-example-encounter-example-f202-20130128) — encounter-example-f202-20130128
- [encounter-example-f203-20130311](/encounter-example-encounter-example-f203-20130311) — encounter-example-f203-20130311
- [encounter-example-home](/encounter-example-encounter-example-home) — encounter-example-home
- [encounter-example-xcda](/encounter-example-encounter-example-xcda) — encounter-example-xcda
- [encounter-examples-header](/encounter-example-encounter-examples-header) — encounter-examples-header
- [example](/encounter-example-example) — encounter-example — Encounter example
- [f001](/encounter-example-f001) — encounter-example-f001-heart — Real-world encounter example
- [f002](/encounter-example-f002) — encounter-example-f002-lung — Real-world encounter example
- [f003](/encounter-example-f003) — encounter-example-f003-abscess — Real-world encounter example
- [f201](/encounter-example-f201) — encounter-example-f201-20130404 — Real-world encounter example
- [f202](/encounter-example-f202) — encounter-example-f202-20130128 — Real-world encounter example (with primaryDiagnosis extension added)
- [f203](/encounter-example-f203) — encounter-example-f203-20130311 — Real-world encounter example
- [home](/encounter-example-home) — encounter-example-home — Encounter example - virtual encounter
- [xcda](/encounter-example-xcda) — encounter-example-xcda — for Clinical Document example patient
[Full Examples](/encounter-examples)
## Mapping Exceptions
### encounter-event-mapping-exceptions.xml
### Divergent Elements
- **Event.identifier** → **Encounter.identifier**
- shortUnmatched | reason=Unknown | pattern=Business identifier for encounter | resource=Identifier(s) by which this encounter is known
- definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this encounter by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=Identifier(s) by which this encounter is known.
- commentsUnmatched | reason=Unknown | pattern=Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
- requirementsUnmatched | reason=Unknown | pattern=Allows identification of the encounter as it is known by various participating systems and in a way that remains consistent across servers.
- **Event.basedOn** → **Encounter.basedOn**
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=The request that initiated this encounter
- definitionUnmatched | reason=Unknown | pattern=A plan, proposal or order that is fulfilled in whole or in part by this encounter. | resource=The request this encounter satisfies (e.g. incoming referral or procedure request).
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the encounter and tracking whether proposals/recommendations were acted upon.
- **Event.basedOn** → **Encounter.appointment**
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=The appointment that scheduled this encounter
- definitionUnmatched | reason=Unknown | pattern=A plan, proposal or order that is fulfilled in whole or in part by this encounter. | resource=The appointment that scheduled this encounter.
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the encounter and tracking whether proposals/recommendations were acted upon.
- **Event.partOf** → **Encounter.partOf**
- missingTypes | reason=Unknown | pattern=Reference(Event)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Part of referenced event | resource=Another Encounter this encounter is part of
- definitionUnmatched | reason=Unknown | pattern=A larger event of which this particular encounter is a component or step. | resource=Another Encounter of which this encounter is a part of (administratively or in time).
- commentsUnmatched | reason=Unknown | pattern=Not to be used to link an encounter to an Encounter - use 'context' for that. | resource=This is also used for associating a child's encounter back to the mother's encounter.
Refer to the Notes section in the Patient resource for further details.
- **Event.status** → **Encounter.status**
- shortUnmatched | reason=Unknown | pattern=preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown | resource=planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
- definitionUnmatched | reason=Unknown | pattern=The current state of the encounter. | resource=The current state of the encounter (not the state of the patient within the encounter - that is subjectState).
- commentsUnmatched | reason=Unknown | pattern=A nominal state-transition diagram can be found in the (Event pattern documentation
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).
- **Event.code** → **Encounter.type**
- shortUnmatched | reason=Unknown | pattern=What service was done | resource=Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
- definitionUnmatched | reason=Unknown | pattern=A code that identifies the specific service or action that was or is being performed. | resource=Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation).
- **Event.code** → **Encounter.serviceType**
- missingTypes | reason=Unknown | pattern=CodeableConcept
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=What service was done | resource=Specific type of service
- definitionUnmatched | reason=Unknown | pattern=A code that identifies the specific service or action that was or is being performed. | resource=Broad categorization of the service that is to be provided (e.g. cardiology).
- **Event.subject** → **Encounter.subject**
- shortUnmatched | reason=Unknown | pattern=Individual service was done for/to | resource=The patient or group related to this encounter
- definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is being or was performed on. | resource=The patient or group related to this encounter. In some use-cases the patient MAY not be present, such as a case meeting about a patient between several practitioners or a careteam.
- requirementsUnmatched | reason=Unknown | pattern=Links the encounter to the Patient context. May also affect access control.
- **Event.occurrence[x]** → **Encounter.actualPeriod**
- missingTypes | reason=Unknown | pattern=dateTime, Timing
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=When encounter occurred/is occurring | resource=The actual start and end time of the encounter
- definitionUnmatched | reason=Unknown | pattern=The date, period or timing when the encounter did occur or is occurring. | resource=The actual start and end time of the encounter.
- commentsUnmatched | reason=Unknown | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds.
. | resource=If not (yet) known, the end of the Period may be omitted.
- **Event.occurrence[x]** → **Encounter.length**
- missingTypes | reason=Unknown | pattern=dateTime, Period, Timing
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=When encounter occurred/is occurring | resource=Actual quantity of time the encounter lasted (less time absent)
- definitionUnmatched | reason=Unknown | pattern=The date, period or timing when the encounter did occur or is occurring. | resource=Actual quantity of time the encounter lasted. This excludes the time during leaves of absence.
When missing it is the time in between the start and end values.
- commentsUnmatched | reason=Unknown | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds.
. | resource=If the precision on these values is low (e.g. to the day only) then this may be considered was an all day (or multi-day) encounter, unless the duration is included, where that amount of time occurred sometime during the interval.
May differ from the time in `Encounter.period` due to leave of absence(s).
- **Event.performer** → **Encounter.participant**
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Who performed encounter and what they did | resource=List of participants involved in the encounter
- definitionUnmatched | reason=Unknown | pattern=Indicates who or what performed the encounter and how they were involved. | resource=The list of people responsible for providing the service.
- **Event.performer.function** → **Encounter.participant.type**
- bindingStrength | reason=Unknown | pattern=example
- shortUnmatched | reason=Unknown | pattern=Type of performance | resource=Role of participant in encounter
- definitionUnmatched | reason=Unknown | pattern=Distinguishes the type of involvement of the performer in the encounter.. | resource=Role of participant in encounter.
- requirementsUnmatched | reason=Unknown | pattern=Allows disambiguation of the types of involvement of different performers.
- **Event.performer.actor** → **Encounter.serviceProvider**
- missingTypes | reason=Unknown | pattern=Reference(Practitioner, PractitionerRole, CareTeam, Patient, Device, RelatedPerson)
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Who performed encounter | resource=The organization (facility) responsible for this encounter
- definitionUnmatched | reason=Unknown | pattern=Indicates who or what performed the encounter. | resource=The organization that is primarily responsible for this Encounter's services. This MAY be the same as the organization on the Patient record, however it could be different, such as if the actor performing the services was from an external organization (which may be billed seperately) for an external consultation. Refer to the colonoscopy example on the Encounter examples tab.
- **Event.performer.actor** → **Encounter.participant.actor**
- missingTypes | reason=Unknown | pattern=Reference(Organization, CareTeam)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Who performed encounter | resource=The individual, device, or service participating in the encounter
- definitionUnmatched | reason=Unknown | pattern=Indicates who or what performed the encounter. | resource=Person involved in the encounter, the patient/group is also included here to indicate that the patient was actually participating in the encounter. Not including the patient here covers use cases such as a case meeting between practitioners about a patient - non contact times.
- **Event.location** → **Encounter.location.location**
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Where encounter occurred | resource=Location the encounter takes place
- definitionUnmatched | reason=Unknown | pattern=The principal physical location where the encounter was performed. | resource=The location where the encounter takes place.
- requirementsUnmatched | reason=Unknown | pattern=Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).
- **Event.reason** → **Encounter.reason.value**
- shortUnmatched | reason=Unknown | pattern=Why was encounter performed? | resource=Reason the encounter takes place (core or reference)
- definitionUnmatched | reason=Unknown | pattern=Describes why the encounter occurred in coded or textual form or Indicates another resource whose existence justifies this encounter. | resource=Reason the encounter takes place, expressed as a code or a reference to another resource. For admissions, this can be used for a coded admission diagnosis.
- commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text.
- **Event.reason** → **Encounter.diagnosis.condition**
- shortUnmatched | reason=Unknown | pattern=Why was encounter performed? | resource=The diagnosis relevant to the encounter
- definitionUnmatched | reason=Unknown | pattern=Describes why the encounter occurred in coded or textual form or Indicates another resource whose existence justifies this encounter. | resource=The coded diagnosis or a reference to a Condition (with other resources referenced in the evidence.detail), the use property will indicate the purpose of this specific diagnosis.
- commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text.
### Unmapped Elements
- **Event.reported** — Unknown
- **Event.relevantHistory** — Unknown
- **Event.statusReason** — Unknown
- **Event.note** — Unknown
- **Event.category** — Unknown
- **Event.encounter** — Unknown
- **Event.recorded** — Unknown
- **Event.product** — Unknown
### encounter-fivews-mapping-exceptions.xml
### Divergent Elements
- **FiveWs.what[x]** → **Encounter.type**
- **FiveWs.context** → **Encounter.episodeOfCare**
### Unmapped Elements
- **FiveWs.recorded** — Unknown
- **FiveWs.author** — Unknown
- **FiveWs.actor** — Unknown
- **FiveWs.cause** — Unknown
- **FiveWs.version** — Unknown
- **FiveWs.witness** — Unknown
- **FiveWs.init** — Unknown
- **FiveWs.source** — Unknown
- **FiveWs.planned** — Unknown