FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

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 Id Encounter
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 Display An interaction during which services are provided to the patient
Cardinality 0..*
Type DomainResource
Alternate Names Visit
Summary false
Encounter.identifier
Element Id Encounter.identifier
Definition

Identifier(s) by which this encounter is known.

Short Display Identifier(s) by which this encounter is known
Note This is a business identifier, not a resource identifier (see discussion)
Cardinality 0..*
Type Identifier
Summary true
Encounter.status
Element Id Encounter.status
Definition

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

Short Display planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
Cardinality 1..1
Terminology Binding Encounter Status (Required)
Type code
Is Modifier true (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)
Summary true
Comments

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

Encounter.class
Element Id Encounter.class
Definition

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

Short Display Classification of patient encounter context - e.g. Inpatient, outpatient
Cardinality 0..*
Terminology Binding Encounter class icon (Preferred)
Type CodeableConcept
Summary true
Encounter.priority
Element Id Encounter.priority
Definition

Indicates the urgency of the encounter.

Short Display Indicates the urgency of the encounter
Cardinality 0..1
Terminology Binding ActPriority icon (Example)
Type CodeableConcept
Summary false
Encounter.type
Element Id Encounter.type
Definition

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

Short Display Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
Cardinality 0..*
Terminology Binding Encounter Type (Example)
Type CodeableConcept
Summary true
Comments

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

Encounter.serviceType
Element Id Encounter.serviceType
Definition

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

Short Display Specific type of service
Cardinality 0..*
Terminology Binding Service Type (Example)
Type CodeableReference(HealthcareService)
Summary true
Encounter.subject
Element Id Encounter.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 Display The patient or group related to this encounter
Cardinality 0..1
Type Reference(Patient | Group)
Alternate Names patient
Summary true
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 Id Encounter.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 Display The current status of the subject in relation to the Encounter
Cardinality 0..1
Terminology Binding Encounter Subject Status (Example)
Type CodeableConcept
Summary false
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 Id Encounter.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 Display Episode(s) of care that this encounter should be recorded against
Cardinality 0..*
Type Reference(EpisodeOfCare)
Summary true
Encounter.basedOn
Element Id Encounter.basedOn
Definition

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

Short Display The request that initiated this encounter
Cardinality 0..*
Type Reference(CarePlan | DeviceRequest | MedicationRequest | ServiceRequest | RequestOrchestration | NutritionOrder | VisionPrescription | ImmunizationRecommendation)
Alternate Names incomingReferral
Summary false
Encounter.careTeam
Element Id Encounter.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 Display The group(s) that are allocated to participate in this encounter
Cardinality 0..*
Type Reference(CareTeam)
Summary false
Encounter.partOf
Element Id Encounter.partOf
Definition

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

Short Display Another Encounter this encounter is part of
Cardinality 0..1
Type Reference(Encounter)
Hierarchy This reference is part of a strict Hierarchy
Summary false
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 Id Encounter.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 Display The organization (facility) responsible for this encounter
Cardinality 0..1
Type Reference(Organization)
Summary false
Encounter.participant
Element Id Encounter.participant
Definition

The list of people responsible for providing the service.

Short Display List of participants involved in the encounter
Cardinality 0..*
Summary true
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 Id Encounter.participant.type
Definition

Role of participant in encounter.

Short Display Role of participant in encounter
Cardinality 0..*
Terminology Binding Participant Type (Extensible)
Type CodeableConcept
Summary true
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 Id Encounter.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 Display Period of time during the encounter that the participant participated
Cardinality 0..1
Type Period
Summary false
Encounter.participant.actor
Element Id Encounter.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 Display The individual, device, or service participating in the encounter
Cardinality 0..1
Type Reference(Patient | Group | RelatedPerson | Practitioner | PractitionerRole | Device | HealthcareService)
Summary true
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 Id Encounter.appointment
Definition

The appointment that scheduled this encounter.

Short Display The appointment that scheduled this encounter
Cardinality 0..*
Type Reference(Appointment)
Summary true
Encounter.virtualService
Element Id Encounter.virtualService
Definition

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

Short Display Connection details of a virtual service (e.g. conference call)
Cardinality 0..*
Type VirtualServiceDetail
Summary false
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 Id Encounter.actualPeriod
Definition

The actual start and end time of the encounter.

Short Display The actual start and end time of the encounter
Cardinality 0..1
Type Period
Summary false
Comments

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

Encounter.plannedStartDate
Element Id Encounter.plannedStartDate
Definition

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

Short Display The planned start date/time (or admission date) of the encounter
Cardinality 0..1
Type dateTime
Summary false
Encounter.plannedEndDate
Element Id Encounter.plannedEndDate
Definition

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

Short Display The planned end date/time (or discharge date) of the encounter
Cardinality 0..1
Type dateTime
Summary false
Encounter.length
Element Id Encounter.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 Display Actual quantity of time the encounter lasted (less time absent)
Cardinality 0..1
Type Duration
Summary false
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 Id Encounter.reason
Definition

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

Short Display The list of medical reasons that are expected to be addressed during the episode of care
Cardinality 0..*
Summary true
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 Id Encounter.reason.use
Definition

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

Short Display What the reason value should be used for/as
Cardinality 0..*
Terminology Binding Encounter Reason Use (Example)
Type CodeableConcept
Summary true
Encounter.reason.value
Element Id Encounter.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 Display Reason the encounter takes place (core or reference)
Cardinality 0..*
Terminology Binding Encounter Reason Codes (Preferred)
Type CodeableReference(Condition | DiagnosticReport | Observation | ImmunizationRecommendation | Procedure)
Alternate Names Indication; Admission diagnosis
Summary true
Encounter.diagnosis
Element Id Encounter.diagnosis
Definition

The list of diagnosis relevant to this encounter.

Short Display The list of diagnosis relevant to this encounter
Cardinality 0..*
Summary true
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 Id Encounter.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 Display The diagnosis relevant to the encounter
Cardinality 0..*
Terminology Binding Condition/Problem/Diagnosis Codes (Example)
Type CodeableReference(Condition)
Alternate Names Admission diagnosis; discharge diagnosis; indication
Summary true
Encounter.diagnosis.use
Element Id Encounter.diagnosis.use
Definition

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

Short Display Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
Cardinality 0..*
Terminology Binding Encounter Diagnosis Use (Preferred)
Type CodeableConcept
Summary false
Encounter.account
Element Id Encounter.account
Definition

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

Short Display The set of accounts that may be used for billing for this Encounter
Cardinality 0..*
Type Reference(Account)
Summary false
Comments

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

Also note that the Encounter.account properties are meant to represent long-running or perpetual accounts. For short-lived, episodic accounts, see Account.covers.

Encounter.dietPreference
Element Id Encounter.dietPreference
Definition

Diet preferences reported by the patient.

Short Display Diet preferences reported by the patient
Cardinality 0..*
Terminology Binding Diet (Example)
Type CodeableConcept
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.

Summary false
Comments

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

Encounter.specialArrangement
Element Id Encounter.specialArrangement
Definition

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

Short Display Wheelchair, translator, stretcher, etc
Cardinality 0..*
Terminology Binding Special Arrangements (Preferred)
Type CodeableConcept
Summary false
Encounter.specialCourtesy
Element Id Encounter.specialCourtesy
Definition

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

Short Display Special courtesies (VIP, board member)
Cardinality 0..*
Terminology Binding Special Courtesy (Preferred)
Type CodeableConcept
Summary false
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 Id Encounter.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 Display Details about the admission to a healthcare service
Cardinality 0..1
Summary false
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 Id Encounter.admission.preAdmissionIdentifier
Definition

Pre-admission identifier.

Short Display Pre-admission identifier
Cardinality 0..1
Type Identifier
Summary false
Encounter.admission.origin
Element Id Encounter.admission.origin
Definition

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

Short Display The location/organization from which the patient came before admission
Cardinality 0..1
Type Reference(Location | Organization)
Summary false
Encounter.admission.admitSource
Element Id Encounter.admission.admitSource
Definition

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

Short Display From where patient was admitted (physician referral, transfer)
Cardinality 0..1
Terminology Binding Admit Source (Preferred)
Type CodeableConcept
Summary false
Encounter.admission.reAdmission
Element Id Encounter.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 Display Indicates that the patient is being re-admitted
Cardinality 0..1
Terminology Binding hl7VS-re-admissionIndicator icon (Example)
Type CodeableConcept
Summary false
Encounter.admission.destination
Element Id Encounter.admission.destination
Definition

Location/organization to which the patient is discharged.

Short Display Location/organization to which the patient is discharged
Cardinality 0..1
Type Reference(Location | Organization)
Summary false
Encounter.admission.dischargeDisposition
Element Id Encounter.admission.dischargeDisposition
Definition

Category or kind of location after discharge.

Short Display Category or kind of location after discharge
Cardinality 0..1
Terminology Binding Discharge Disposition (Example)
Type CodeableConcept
Summary false
Encounter.location
Element Id Encounter.location
Definition

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

Short Display List of locations where the patient has been
Cardinality 0..*
Summary false
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 Id Encounter.location.location
Definition

The location where the encounter takes place.

Short Display Location the encounter takes place
Cardinality 1..1
Type Reference(Location)
Summary false
Encounter.location.status
Element Id Encounter.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 Display planned | active | reserved | completed
Cardinality 0..1
Terminology Binding Encounter Location Status (Required)
Type code
Summary false
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 Id Encounter.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 Display The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
Cardinality 0..1
Terminology Binding Location Form (Example)
Type CodeableConcept
Summary false
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 Id Encounter.location.period
Definition

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

Short Display Time period during which the patient was present at the location
Cardinality 0..1
Type Period
Summary false