Release 5

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Patient Administration icon Work GroupMaturity Level: 4 Trial UseSecurity Category: Patient Compartments: Encounter, Patient, Practitioner, RelatedPerson

Detailed Descriptions for the elements in the Encounter resource.

Encounter
Element IdEncounter
Definition

An interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient. Encounter is primarily used to record information about the actual activities that occurred, where Appointment is used to record planned activities.

Short DisplayAn interaction during which services are provided to the patient
Cardinality0..*
TypeDomainResource
Alternate NamesVisit
Summaryfalse
Encounter.identifier
Element IdEncounter.identifier
Definition

Identifier(s) by which this encounter is known.

Short DisplayIdentifier(s) by which this encounter is known
NoteThis is a business identifier, not a resource identifier (see discussion)
Cardinality0..*
TypeIdentifier
Summarytrue
Encounter.status
Element IdEncounter.status
Definition

The current state of the encounter (not the state of the patient within the encounter - that is subjectState).

Short Displayplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
Cardinality1..1
Terminology BindingEncounter Status (Required)
Typecode
Is Modifiertrue (Reason: This element is labeled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid)
Summarytrue
Comments

Note that internal business rules will determine the appropriate transitions that may occur between statuses (and also classes).

Encounter.class
Element IdEncounter.class
Definition

Concepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variations.

Short DisplayClassification of patient encounter context - e.g. Inpatient, outpatient
Cardinality0..*
Terminology BindingEncounter class icon (Preferred)
TypeCodeableConcept
Summarytrue
Encounter.priority
Element IdEncounter.priority
Definition

Indicates the urgency of the encounter.

Short DisplayIndicates the urgency of the encounter
Cardinality0..1
Terminology BindingActPriority icon (Example)
TypeCodeableConcept
Summaryfalse
Encounter.type
Element IdEncounter.type
Definition

Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation).

Short DisplaySpecific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
Cardinality0..*
Terminology BindingEncounter Type (Example)
TypeCodeableConcept
Summarytrue
Comments

Since there are many ways to further classify encounters, this element is 0..*.

Encounter.serviceType
Element IdEncounter.serviceType
Definition

Broad categorization of the service that is to be provided (e.g. cardiology).

Short DisplaySpecific type of service
Cardinality0..*
Terminology BindingService Type (Example)
TypeCodeableReference(HealthcareService)
Summarytrue
Encounter.subject
Element IdEncounter.subject
Definition

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.

Short DisplayThe patient or group related to this encounter
Cardinality0..1
TypeReference(Patient | Group)
Alternate Namespatient
Summarytrue
Comments

While the encounter is always about the patient, the patient might not actually be known in all contexts of use, and there may be a group of patients that could be anonymous (such as in a group therapy for Alcoholics Anonymous - where the recording of the encounter could be used for billing on the number of people/staff and not important to the context of the specific patients) or alternately in veterinary care a herd of sheep receiving treatment (where the animals are not individually tracked).

Encounter.subjectStatus
Element IdEncounter.subjectStatus
Definition

The subjectStatus value can be used to track the patient's status within the encounter. It details whether the patient has arrived or departed, has been triaged or is currently in a waiting status.

Short DisplayThe current status of the subject in relation to the Encounter
Cardinality0..1
Terminology BindingEncounter Subject Status (Example)
TypeCodeableConcept
Summaryfalse
Comments

Different use-cases are likely to have different permitted transitions between states, such as an Emergency department could use arrived when the patient first presents, then triaged once has been assessed by a nurse, then receiving-care once treatment begins, however other sectors may use a different set of these values, or their own custom set in place of this example valueset provided.

Encounter.episodeOfCare
Element IdEncounter.episodeOfCare
Definition

Where a specific encounter should be classified as a part of a specific episode(s) of care this field should be used. This association can facilitate grouping of related encounters together for a specific purpose, such as government reporting, issue tracking, association via a common problem. The association is recorded on the encounter as these are typically created after the episode of care and grouped on entry rather than editing the episode of care to append another encounter to it (the episode of care could span years).

Short DisplayEpisode(s) of care that this encounter should be recorded against
Cardinality0..*
TypeReference(EpisodeOfCare)
Summarytrue
Encounter.basedOn
Element IdEncounter.basedOn
Definition

The request this encounter satisfies (e.g. incoming referral or procedure request).

Short DisplayThe request that initiated this encounter
Cardinality0..*
TypeReference(CarePlan | DeviceRequest | MedicationRequest | ServiceRequest)
Alternate NamesincomingReferral
Summaryfalse
Encounter.careTeam
Element IdEncounter.careTeam
Definition

The group(s) of individuals, organizations that are allocated to participate in this encounter. The participants backbone will record the actuals of when these individuals participated during the encounter.

Short DisplayThe group(s) that are allocated to participate in this encounter
Cardinality0..*
TypeReference(CareTeam)
Summaryfalse
Encounter.partOf
Element IdEncounter.partOf
Definition

Another Encounter of which this encounter is a part of (administratively or in time).

Short DisplayAnother Encounter this encounter is part of
Cardinality0..1
TypeReference(Encounter)
HierarchyThis reference is part of a strict Hierarchy
Summaryfalse
Comments

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.

Encounter.serviceProvider
Element IdEncounter.serviceProvider
Definition

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.

Short DisplayThe organization (facility) responsible for this encounter
Cardinality0..1
TypeReference(Organization)
Summaryfalse
Encounter.participant
Element IdEncounter.participant
Definition

The list of people responsible for providing the service.

Short DisplayList of participants involved in the encounter
Cardinality0..*
Summarytrue
Comments

Any Patient or Group present in the participation.actor must also be the subject, though the subject may be absent from the participation.actor for cases where the patient (or group) is not present, such as during a case review conference.

Invariants
Defined on this element
enc-1Rule A type must be provided when no explicit actor is specifiedactor.exists() or type.exists()
enc-2Rule A type cannot be provided for a patient or group participantactor.exists(resolve() is Patient or resolve() is Group) implies type.exists().not()
Encounter.participant.type
Element IdEncounter.participant.type
Definition

Role of participant in encounter.

Short DisplayRole of participant in encounter
Cardinality0..*
Terminology BindingParticipant Type (Extensible)
TypeCodeableConcept
Summarytrue
Comments

The participant type indicates how an individual actor participates in an encounter. It includes non-practitioner participants, and for practitioners this is to describe the action type in the context of this encounter (e.g. Admitting Dr, Attending Dr, Translator, Consulting Dr). This is different to the practitioner roles which are functional roles, derived from terms of employment, education, licensing, etc.

Invariants
Affect this element
enc-1Rule A type must be provided when no explicit actor is specifiedactor.exists() or type.exists()
enc-2Rule A type cannot be provided for a patient or group participantactor.exists(resolve() is Patient or resolve() is Group) implies type.exists().not()
Encounter.participant.period
Element IdEncounter.participant.period
Definition

The period of time that the specified participant participated in the encounter. These can overlap or be sub-sets of the overall encounter's period.

Short DisplayPeriod of time during the encounter that the participant participated
Cardinality0..1
TypePeriod
Summaryfalse
Encounter.participant.actor
Element IdEncounter.participant.actor
Definition

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.

Short DisplayThe individual, device, or service participating in the encounter
Cardinality0..1
TypeReference(Patient | Group | RelatedPerson | Practitioner | PractitionerRole | Device | HealthcareService)
Summarytrue
Comments

For planning purposes, Appointments may include a CareTeam participant to indicate that one specific person from the CareTeam will be assigned, but that assignment might not happen until the Encounter begins. Hence CareTeam is not included in Encounter.participant, as the specific individual should be assigned and represented as a Practitioner or other person resource.

Similarly, Location can be included in Appointment.participant to assist with planning. However, the patient location is tracked on the Encounter in the Encounter.location property to allow for additional metadata and history to be recorded.

The role of the participant can be used to declare what the actor will be doing in the scope of this encounter participation.

If the individual is not specified during planning, then it is expected that the individual will be filled in at a later stage prior to the encounter commencing.

Invariants
Affect this element
enc-1Rule A type must be provided when no explicit actor is specifiedactor.exists() or type.exists()
enc-2Rule A type cannot be provided for a patient or group participantactor.exists(resolve() is Patient or resolve() is Group) implies type.exists().not()
Encounter.appointment
Element IdEncounter.appointment
Definition

The appointment that scheduled this encounter.

Short DisplayThe appointment that scheduled this encounter
Cardinality0..*
TypeReference(Appointment)
Summarytrue
Encounter.virtualService
Element IdEncounter.virtualService
Definition

Connection details of a virtual service (e.g. conference call).

Short DisplayConnection details of a virtual service (e.g. conference call)
Cardinality0..*
TypeVirtualServiceDetail
Summaryfalse
Comments

There are two types of virtual meetings that often exist:

  • a persistent, virtual meeting room that can only be used for a single purpose at a time,
  • and a dynamic virtual meeting room that is generated on demand for a specific purpose.

Implementers may consider using Location.virtualService for persistent meeting rooms.

If each participant would have a different meeting link, an extension using the VirtualServiceContactDetail can be applied to the Encounter.participant BackboneElement.

Encounter.actualPeriod
Element IdEncounter.actualPeriod
Definition

The actual start and end time of the encounter.

Short DisplayThe actual start and end time of the encounter
Cardinality0..1
TypePeriod
Summaryfalse
Comments

If not (yet) known, the end of the Period may be omitted.

Encounter.plannedStartDate
Element IdEncounter.plannedStartDate
Definition

The planned start date/time (or admission date) of the encounter.

Short DisplayThe planned start date/time (or admission date) of the encounter
Cardinality0..1
TypedateTime
Summaryfalse
Encounter.plannedEndDate
Element IdEncounter.plannedEndDate
Definition

The planned end date/time (or discharge date) of the encounter.

Short DisplayThe planned end date/time (or discharge date) of the encounter
Cardinality0..1
TypedateTime
Summaryfalse
Encounter.length
Element IdEncounter.length
Definition

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.

Short DisplayActual quantity of time the encounter lasted (less time absent)
Cardinality0..1
TypeDuration
Summaryfalse
Comments

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).

Encounter.reason
Element IdEncounter.reason
Definition

The list of medical reasons that are expected to be addressed during the episode of care.

Short DisplayThe list of medical reasons that are expected to be addressed during the episode of care
Cardinality0..*
Summarytrue
Comments

The reason communicates what medical problem the patient has that should be addressed during the episode of care. This reason could be patient reported complaint, a clinical indication that was determined in a previous encounter or episode of care, or some planned care such as an immunization recommendation. In the case where you have a primary reason, but are expecting to also address other problems, you can list the primary reason with a use code of 'Chief Complaint', while the other problems being addressed would have a use code of 'Reason for Visit'.

Examples:

  • pregnancy would use HealthcareService or a coding as the reason
  • patient home monitoring could use Condition as the reason
Encounter.reason.use
Element IdEncounter.reason.use
Definition

What the reason value should be used as e.g. Chief Complaint, Health Concern, Health Maintenance (including screening).

Short DisplayWhat the reason value should be used for/as
Cardinality0..*
Terminology BindingEncounter Reason Use (Example)
TypeCodeableConcept
Summarytrue
Encounter.reason.value
Element IdEncounter.reason.value
Definition

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.

Short DisplayReason the encounter takes place (core or reference)
Cardinality0..*
Terminology BindingEncounter Reason Codes (Preferred)
TypeCodeableReference(Condition | DiagnosticReport | Observation | ImmunizationRecommendation | Procedure)
Alternate NamesIndication; Admission diagnosis
Summarytrue
Encounter.diagnosis
Element IdEncounter.diagnosis
Definition

The list of diagnosis relevant to this encounter.

Short DisplayThe list of diagnosis relevant to this encounter
Cardinality0..*
Summarytrue
Comments

Also note that for the purpose of billing, the diagnoses are recorded in the account where they can be ranked appropriately for how the invoicing/claiming documentation needs to be prepared.

Encounter.diagnosis.condition
Element IdEncounter.diagnosis.condition
Definition

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.

Short DisplayThe diagnosis relevant to the encounter
Cardinality0..*
Terminology BindingCondition/Problem/Diagnosis Codes (Example)
TypeCodeableReference(Condition)
Alternate NamesAdmission diagnosis; discharge diagnosis; indication
Summarytrue
Encounter.diagnosis.use
Element IdEncounter.diagnosis.use
Definition

Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …).

Short DisplayRole that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
Cardinality0..*
Terminology BindingEncounter Diagnosis Use (Preferred)
TypeCodeableConcept
Summaryfalse
Encounter.account
Element IdEncounter.account
Definition

The set of accounts that may be used for billing for this Encounter.

Short DisplayThe set of accounts that may be used for billing for this Encounter
Cardinality0..*
TypeReference(Account)
Summaryfalse
Comments

The billing system may choose to allocate billable items associated with the Encounter to different referenced Accounts based on internal business rules.

Encounter.dietPreference
Element IdEncounter.dietPreference
Definition

Diet preferences reported by the patient.

Short DisplayDiet preferences reported by the patient
Cardinality0..*
Terminology BindingDiet (Example)
TypeCodeableConcept
Requirements

Used to track patient's diet restrictions and/or preference. For a complete description of the nutrition needs of a patient during their stay, one should use the nutritionOrder resource which links to Encounter.

Summaryfalse
Comments

For example, a patient may request both a dairy-free and nut-free diet preference (not mutually exclusive).

Encounter.specialArrangement
Element IdEncounter.specialArrangement
Definition

Any special requests that have been made for this encounter, such as the provision of specific equipment or other things.

Short DisplayWheelchair, translator, stretcher, etc
Cardinality0..*
Terminology BindingSpecial Arrangements (Preferred)
TypeCodeableConcept
Summaryfalse
Encounter.specialCourtesy
Element IdEncounter.specialCourtesy
Definition

Special courtesies that may be provided to the patient during the encounter (VIP, board member, professional courtesy).

Short DisplaySpecial courtesies (VIP, board member)
Cardinality0..*
Terminology BindingSpecial Courtesy (Preferred)
TypeCodeableConcept
Summaryfalse
Comments

Although the specialCourtesy property can contain values like VIP, the purpose of this field is intended to be used for flagging additional benefits that might occur for the patient during the encounter.

It could include things like the patient is to have a private room, special room features, receive a friendly visit from hospital adminisitration, or should be briefed on treatment by senior staff during the stay.

It is not specifically intended to be used for securing the specific record - that is the purpose of the security meta tag, and where appropriate, both fields could be used.

Encounter.admission
Element IdEncounter.admission
Definition

Details about the stay during which a healthcare service is provided.

This does not describe the event of admitting the patient, but rather any information that is relevant from the time of admittance until the time of discharge.

Short DisplayDetails about the admission to a healthcare service
Cardinality0..1
Summaryfalse
Comments

An Encounter may cover more than just the inpatient stay. Contexts such as outpatients, community clinics, and aged care facilities are also included.

The duration recorded in the period of this encounter covers the entire scope of this admission record.

Encounter.admission.preAdmissionIdentifier
Element IdEncounter.admission.preAdmissionIdentifier
Definition

Pre-admission identifier.

Short DisplayPre-admission identifier
Cardinality0..1
TypeIdentifier
Summaryfalse
Encounter.admission.origin
Element IdEncounter.admission.origin
Definition

The location/organization from which the patient came before admission.

Short DisplayThe location/organization from which the patient came before admission
Cardinality0..1
TypeReference(Location | Organization)
Summaryfalse
Encounter.admission.admitSource
Element IdEncounter.admission.admitSource
Definition

From where patient was admitted (physician referral, transfer).

Short DisplayFrom where patient was admitted (physician referral, transfer)
Cardinality0..1
Terminology BindingAdmit Source (Preferred)
TypeCodeableConcept
Summaryfalse
Encounter.admission.reAdmission
Element IdEncounter.admission.reAdmission
Definition

Indicates that this encounter is directly related to a prior admission, often because the conditions addressed in the prior admission were not fully addressed.

Short DisplayIndicates that the patient is being re-admitted
Cardinality0..1
Terminology Bindinghl7VS-re-admissionIndicator icon (Example)
TypeCodeableConcept
Summaryfalse
Encounter.admission.destination
Element IdEncounter.admission.destination
Definition

Location/organization to which the patient is discharged.

Short DisplayLocation/organization to which the patient is discharged
Cardinality0..1
TypeReference(Location | Organization)
Summaryfalse
Encounter.admission.dischargeDisposition
Element IdEncounter.admission.dischargeDisposition
Definition

Category or kind of location after discharge.

Short DisplayCategory or kind of location after discharge
Cardinality0..1
Terminology BindingDischarge Disposition (Example)
TypeCodeableConcept
Summaryfalse
Encounter.location
Element IdEncounter.location
Definition

List of locations where the patient has been during this encounter.

Short DisplayList of locations where the patient has been
Cardinality0..*
Summaryfalse
Comments

Virtual encounters can be recorded in the Encounter by specifying a location reference to a location of type "kind" such as "client's home" and an encounter.class = "virtual".

Encounter.location.location
Element IdEncounter.location.location
Definition

The location where the encounter takes place.

Short DisplayLocation the encounter takes place
Cardinality1..1
TypeReference(Location)
Summaryfalse
Encounter.location.status
Element IdEncounter.location.status
Definition

The status of the participants' presence at the specified location during the period specified. If the participant is no longer at the location, then the period will have an end date/time.

Short Displayplanned | active | reserved | completed
Cardinality0..1
Terminology BindingEncounter Location Status (Required)
Typecode
Summaryfalse
Comments

When the patient is no longer active at a location, then the period end date is entered, and the status may be changed to completed.

Encounter.location.form
Element IdEncounter.location.form
Definition

This will be used to specify the required levels (bed/ward/room/etc.) desired to be recorded to simplify either messaging or query.

Short DisplayThe physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
Cardinality0..1
Terminology BindingLocation Form (Example)
TypeCodeableConcept
Summaryfalse
Comments

This information is de-normalized from the Location resource to support the easier understanding of the encounter resource and processing in messaging or query.

There may be many levels in the hierachy, and this may only pic specific levels that are required for a specific usage scenario.

Encounter.location.period
Element IdEncounter.location.period
Definition

Time period during which the patient was present at the location.

Short DisplayTime period during which the patient was present at the location
Cardinality0..1
TypePeriod
Summaryfalse