Release 4

This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU) in it's permanent home (it will always be available at this URL). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Patient Administration Work GroupMaturity Level: 2 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.

Cardinality0..*
TypeDomainResource
Alternate NamesVisit
Encounter.identifier
Element IdEncounter.identifier
Definition

Identifier(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

planned | arrived | triaged | in-progress | onleave | finished | cancelled +.

Cardinality1..1
Terminology BindingEncounterStatus (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.statusHistory
Element IdEncounter.statusHistory
Definition

The status history permits the encounter resource to contain the status history without needing to read through the historical versions of the resource, or even have the server store them.

Cardinality0..*
Comments

The current status is always found in the current version of the resource, not the status history.

Encounter.statusHistory.status
Element IdEncounter.statusHistory.status
Definition

planned | arrived | triaged | in-progress | onleave | finished | cancelled +.

Cardinality1..1
Terminology BindingEncounterStatus (Required)
Typecode
Encounter.statusHistory.period
Element IdEncounter.statusHistory.period
Definition

The time that the episode was in the specified status.

Cardinality1..1
TypePeriod
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.

Cardinality1..1
Terminology BindingV3 Value SetActEncounterCode (Extensible)
TypeCoding
Summarytrue
Encounter.classHistory
Element IdEncounter.classHistory
Definition

The class history permits the tracking of the encounters transitions without needing to go through the resource history. This would be used for a case where an admission starts of as an emergency encounter, then transitions into an inpatient scenario. Doing this and not restarting a new encounter ensures that any lab/diagnostic results can more easily follow the patient and not require re-processing and not get lost or cancelled during a kind of discharge from emergency to inpatient.

Cardinality0..*
Encounter.classHistory.class
Element IdEncounter.classHistory.class
Definition

inpatient | outpatient | ambulatory | emergency +.

Cardinality1..1
Terminology BindingV3 Value SetActEncounterCode (Extensible)
TypeCoding
Encounter.classHistory.period
Element IdEncounter.classHistory.period
Definition

The time that the episode was in the specified class.

Cardinality1..1
TypePeriod
Encounter.type
Element IdEncounter.type
Definition

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

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

Cardinality0..1
Terminology BindingService type (Example)
TypeCodeableConcept
Summarytrue
Encounter.priority
Element IdEncounter.priority
Definition

Indicates the urgency of the encounter.

Cardinality0..1
Terminology Bindingv3 Code System ActPriority (Example)
TypeCodeableConcept
Encounter.subject
Element IdEncounter.subject
Definition

The patient or group present at the 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.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).

Cardinality0..*
TypeReference(EpisodeOfCare)
Summarytrue
Encounter.basedOn
Element IdEncounter.basedOn
Definition

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

Cardinality0..*
TypeReference(ServiceRequest)
Alternate NamesincomingReferral
Encounter.participant
Element IdEncounter.participant
Definition

The list of people responsible for providing the service.

Cardinality0..*
Summarytrue
Encounter.participant.type
Element IdEncounter.participant.type
Definition

Role of participant in encounter.

Cardinality0..*
Terminology BindingParticipant type (Extensible)
TypeCodeableConcept
Summarytrue
Comments

The participant type indicates how an individual 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.

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.

Cardinality0..1
TypePeriod
Encounter.participant.individual
Element IdEncounter.participant.individual
Definition

Persons involved in the encounter other than the patient.

Cardinality0..1
TypeReference(Practitioner | PractitionerRole | RelatedPerson)
Summarytrue
Encounter.appointment
Element IdEncounter.appointment
Definition

The appointment that scheduled this encounter.

Cardinality0..*
TypeReference(Appointment)
Summarytrue
Encounter.period
Element IdEncounter.period
Definition

The start and end time of the encounter.

Cardinality0..1
TypePeriod
Comments

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

Encounter.length
Element IdEncounter.length
Definition

Quantity of time the encounter lasted. This excludes the time during leaves of absence.

Cardinality0..1
TypeDuration
Comments

May differ from the time the Encounter.period lasted because of leave of absence.

Encounter.reasonCode
Element IdEncounter.reasonCode
Definition

Reason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis.

Cardinality0..*
Terminology BindingEncounter Reason Codes (Preferred)
TypeCodeableConcept
Alternate NamesIndication; Admission diagnosis
Summarytrue
Comments

For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis).

Encounter.reasonReference
Element IdEncounter.reasonReference
Definition

Reason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis.

Cardinality0..*
TypeReference(Condition | Procedure | Observation | ImmunizationRecommendation)
Alternate NamesIndication; Admission diagnosis
Summarytrue
Comments

For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis).

Encounter.diagnosis
Element IdEncounter.diagnosis
Definition

The list of diagnosis relevant to this encounter.

Cardinality0..*
Summarytrue
Encounter.diagnosis.condition
Element IdEncounter.diagnosis.condition
Definition

Reason the encounter takes place, as specified using information from another resource. For admissions, this is the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure.

Cardinality1..1
TypeReference(Condition | Procedure)
Alternate NamesAdmission diagnosis; discharge diagnosis; indication
Summarytrue
Comments

For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis).

Encounter.diagnosis.use
Element IdEncounter.diagnosis.use
Definition

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

Cardinality0..1
Terminology BindingDiagnosisRole (Preferred)
TypeCodeableConcept
Encounter.diagnosis.rank
Element IdEncounter.diagnosis.rank
Definition

Ranking of the diagnosis (for each role type).

Cardinality0..1
TypepositiveInt
Encounter.account
Element IdEncounter.account
Definition

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

Cardinality0..*
TypeReference(Account)
Comments

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

Encounter.hospitalization
Element IdEncounter.hospitalization
Definition

Details about the admission to a healthcare service.

Cardinality0..1
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 hospitalization record.

Encounter.hospitalization.preAdmissionIdentifier
Element IdEncounter.hospitalization.preAdmissionIdentifier
Definition

Pre-admission identifier.

Cardinality0..1
TypeIdentifier
Encounter.hospitalization.origin
Element IdEncounter.hospitalization.origin
Definition

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

Cardinality0..1
TypeReference(Location | Organization)
Encounter.hospitalization.admitSource
Element IdEncounter.hospitalization.admitSource
Definition

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

Cardinality0..1
Terminology BindingAdmit source (Preferred)
TypeCodeableConcept
Encounter.hospitalization.reAdmission
Element IdEncounter.hospitalization.reAdmission
Definition

Whether this hospitalization is a readmission and why if known.

Cardinality0..1
Terminology Bindingv2 RE-ADMISSION INDICATOR (Example)
TypeCodeableConcept
Encounter.hospitalization.dietPreference
Element IdEncounter.hospitalization.dietPreference
Definition

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

Comments

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

Encounter.hospitalization.specialCourtesy
Element IdEncounter.hospitalization.specialCourtesy
Definition

Special courtesies (VIP, board member).

Cardinality0..*
Terminology BindingSpecial courtesy (Preferred)
TypeCodeableConcept
Encounter.hospitalization.specialArrangement
Element IdEncounter.hospitalization.specialArrangement
Definition

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

Cardinality0..*
Terminology BindingSpecial arrangements (Preferred)
TypeCodeableConcept
Encounter.hospitalization.destination
Element IdEncounter.hospitalization.destination
Definition

Location/organization to which the patient is discharged.

Cardinality0..1
TypeReference(Location | Organization)
Encounter.hospitalization.dischargeDisposition
Element IdEncounter.hospitalization.dischargeDisposition
Definition

Category or kind of location after discharge.

Cardinality0..1
Terminology BindingDischarge disposition (Example)
TypeCodeableConcept
Encounter.location
Element IdEncounter.location
Definition

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

Cardinality0..*
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.

Cardinality1..1
TypeReference(Location)
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.

Cardinality0..1
Terminology BindingEncounterLocationStatus (Required)
Typecode
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.physicalType
Element IdEncounter.location.physicalType
Definition

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

Cardinality0..1
Terminology BindingLocation type (Example)
TypeCodeableConcept
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.

Cardinality0..1
TypePeriod
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 example bundle showing an abbreviated set of Encounters for a colonoscopy.

Cardinality0..1
TypeReference(Organization)
Encounter.partOf
Element IdEncounter.partOf
Definition

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

Cardinality0..1
TypeReference(Encounter)
HierarchyThis reference is part of a strict Hierarchy
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.