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

planned | in-progress | onhold | discharged | completed | cancelled | discontinued | entered-in-error | unknown.

Short Displayplanned | in-progress | onhold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
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.

Short DisplayList of past encounter statuses
Cardinality0..*
Summaryfalse
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 | in-progress | onhold | discharged | completed | cancelled | discontinued | entered-in-error | unknown.

Short Displayplanned | in-progress | onhold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
Cardinality1..1
Terminology BindingEncounterStatus (Required)
Typecode
Summaryfalse
Encounter.statusHistory.period
Element IdEncounter.statusHistory.period
Definition

The time that the episode was in the specified status.

Short DisplayThe time that the episode was in the specified status
Cardinality1..1
TypePeriod
Summaryfalse
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 BindingEncounterClass icon:
TypeCodeableConcept
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.

Short DisplayList of past encounter classes
Cardinality0..*
Summaryfalse
Encounter.classHistory.class
Element IdEncounter.classHistory.class
Definition

inpatient | outpatient | ambulatory | emergency +.

Short Displayinpatient | outpatient | ambulatory | emergency +
Cardinality1..1
Terminology BindingEncounterClass icon:
TypeCoding
Summaryfalse
Encounter.classHistory.period
Element IdEncounter.classHistory.period
Definition

The time that the episode was in the specified class.

Short DisplayThe time that the episode was in the specified class
Cardinality1..1
TypePeriod
Summaryfalse
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 BindingEncounterType (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 BindingServiceType (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 BindingEncounterSubjectStatus (Example)
TypeCodeableConcept
Summaryfalse
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 example bundle showing an abbreviated set of Encounters for a colonoscopy.

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 BindingParticipantType (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.

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.

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

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 | ImmunizationRecommendation | Observation | 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
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.

Short DisplayThe diagnosis or procedure relevant to the encounter
Cardinality1..1
TypeReference(Condition | Procedure)
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..1
Terminology BindingDiagnosisRole (Preferred)
TypeCodeableConcept
Summaryfalse
Encounter.diagnosis.rank
Element IdEncounter.diagnosis.rank
Definition

Ranking of the diagnosis (for each role type).

Short DisplayRanking of the diagnosis (for each role type)
Cardinality0..1
TypepositiveInt
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.admission
Element IdEncounter.admission
Definition

Details about the admission to a healthcare service.

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 BindingAdmitSource (Preferred)
TypeCodeableConcept
Summaryfalse
Encounter.admission.reAdmission
Element IdEncounter.admission.reAdmission
Definition

Whether this admission is a readmission and why if known.

Short DisplayThe type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission
Cardinality0..1
Terminology Bindinghl7VS-re-admissionIndicator icon (Example)
TypeCodeableConcept
Summaryfalse
Encounter.admission.dietPreference
Element IdEncounter.admission.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.admission.specialCourtesy
Element IdEncounter.admission.specialCourtesy
Definition

Special courtesies (VIP, board member).

Short DisplaySpecial courtesies (VIP, board member)
Cardinality0..*
Terminology BindingSpecialCourtesy (Preferred)
TypeCodeableConcept
Summaryfalse
Encounter.admission.specialArrangement
Element IdEncounter.admission.specialArrangement
Definition

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

Short DisplayWheelchair, translator, stretcher, etc.
Cardinality0..*
Terminology BindingSpecialArrangements (Preferred)
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 BindingDischargeDisposition (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 BindingEncounterLocationStatus (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