Snapshot 3: Connectathon 32 Base

This page is part of the FHIR Specification (v5.0.0-snapshot3: R5 Snapshot #3, to support Connectathon 32). 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

8.11 Resource Encounter - Content

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

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.

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

During the life-cycle of an encounter it will pass through many statuses. Typically these are in order or the organization's workflow: planned, in-progress, finished/cancelled.
This status information is often used for other things, and often an analysis of the status history is required. This could be done by scanning through all the versions of the encounter, checking the period of each, and then doing some form of post processing. To ease the burden of this (or where a system doesn't support resource histories) a status history component is included.

There is no direct indication purely by the status 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).
Statuses of "arrived", "triaged" or "in progress" 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".

The "on leave" 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.
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.

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.

Structure

Name iconFlags iconCard. iconType iconDescription & Constraints icondoco icon
.. Encounter TUDomainResourceAn interaction during which services are provided to the patient

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierIdentifier(s) by which this encounter is known

... status ?!Σ1..1codeplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
EncounterStatus (Required)
... statusHistory 0..*BackboneElementList of past encounter statuses

.... status 1..1codeplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
EncounterStatus (Required)
.... period 1..1PeriodThe time that the episode was in the specified status
... class Σ0..*CodeableConceptClassification of patient encounter context - e.g. Inpatient, outpatient
Encounter class icon (Preferred)

... classHistory 0..*BackboneElementList of past encounter classes

.... class 1..1Codinginpatient | outpatient | ambulatory | emergency +
Encounter class icon (Preferred)
.... period 1..1PeriodThe time that the episode was in the specified class
... priority 0..1CodeableConceptIndicates the urgency of the encounter
ActPriority icon (Example)
... type Σ0..*CodeableConceptSpecific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
EncounterType (Example)

... serviceType Σ0..*CodeableReference(HealthcareService)Specific type of service
ServiceType (Example)

... subject Σ0..1Reference(Patient | Group)The patient or group related to this encounter
... subjectStatus 0..1CodeableConceptThe current status of the subject in relation to the Encounter
EncounterSubjectStatus (Example)
... episodeOfCare Σ0..*Reference(EpisodeOfCare)Episode(s) of care that this encounter should be recorded against

... basedOn 0..*Reference(CarePlan | DeviceRequest | MedicationRequest | ServiceRequest)The request that initiated this encounter

... careTeam 0..*Reference(CareTeam)The group(s) that are allocated to participate in this encounter

... partOf 0..1Reference(Encounter)Another Encounter this encounter is part of
... serviceProvider 0..1Reference(Organization)The organization (facility) responsible for this encounter
... participant ΣC0..*BackboneElementList of participants involved in the encounter
+ Rule: A type must be provided when no explicit actor is specified
+ Rule: A type cannot be provided for a patient or group participant

.... type Σ0..*CodeableConceptRole of participant in encounter
ParticipantType (Extensible)

.... period 0..1PeriodPeriod of time during the encounter that the participant participated
.... actor Σ0..1Reference(Patient | Group | RelatedPerson | Practitioner | PractitionerRole | Device | HealthcareService)The individual, device, or service participating in the encounter
... appointment Σ0..*Reference(Appointment)The appointment that scheduled this encounter

... virtualService 0..*VirtualServiceDetailConnection details of a virtual service (e.g. conference call)

... actualPeriod 0..1PeriodThe actual start and end time of the encounter
... plannedStartDate 0..1dateTimeThe planned start date/time (or admission date) of the encounter
... plannedEndDate 0..1dateTimeThe planned end date/time (or discharge date) of the encounter
... length 0..1DurationActual quantity of time the encounter lasted (less time absent)
... reason Σ0..*CodeableReference(Condition | DiagnosticReport | ImmunizationRecommendation | Observation | Procedure)Reason the encounter takes place (core or reference)
Encounter Reason Codes (Preferred)

... diagnosis Σ0..*BackboneElementThe list of diagnosis relevant to this encounter

.... condition Σ1..1Reference(Condition | Procedure)The diagnosis or procedure relevant to the encounter
.... use 0..1CodeableConceptRole that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
DiagnosisRole (Preferred)
.... rank 0..1positiveIntRanking of the diagnosis (for each role type)
... account 0..*Reference(Account)The set of accounts that may be used for billing for this Encounter

... admission 0..1BackboneElementDetails about the admission to a healthcare service
.... preAdmissionIdentifier 0..1IdentifierPre-admission identifier
.... origin 0..1Reference(Location | Organization)The location/organization from which the patient came before admission
.... admitSource 0..1CodeableConceptFrom where patient was admitted (physician referral, transfer)
AdmitSource (Preferred)
.... reAdmission 0..1CodeableConceptThe type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission
hl7VS-re-admissionIndicator icon (Example)
.... dietPreference 0..*CodeableConceptDiet preferences reported by the patient
Diet (Example)

.... specialCourtesy 0..*CodeableConceptSpecial courtesies (VIP, board member)
SpecialCourtesy (Preferred)

.... specialArrangement 0..*CodeableConceptWheelchair, translator, stretcher, etc.
SpecialArrangements (Preferred)

.... destination 0..1Reference(Location | Organization)Location/organization to which the patient is discharged
.... dischargeDisposition 0..1CodeableConceptCategory or kind of location after discharge
DischargeDisposition (Example)
... location 0..*BackboneElementList of locations where the patient has been

.... location 1..1Reference(Location)Location the encounter takes place
.... status 0..1codeplanned | active | reserved | completed
EncounterLocationStatus (Required)
.... form 0..1CodeableConceptThe physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
Location Form (Example)
.... period 0..1PeriodTime period during which the patient was present at the location

doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

Encounter (DomainResource)Identifier(s) by which this encounter is knownidentifier : Identifier [0..*]planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)EncounterStatus! »Concepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variationsclass : CodeableConcept [0..*] « null (Strength=Preferred)EncounterClass? »Indicates the urgency of the encounterpriority : CodeableConcept [0..1] « null (Strength=Example)ActPriority?? »Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation)type : CodeableConcept [0..*] « null (Strength=Example)EncounterType?? »Broad categorization of the service that is to be provided (e.g. cardiology)serviceType : CodeableReference [0..*] « HealthcareService; null (Strength=Example) ServiceType?? »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 careteamsubject : Reference [0..1] « Patient|Group »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 statussubjectStatus : CodeableConcept [0..1] « null (Strength=Example)EncounterSubjectStatus?? »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)episodeOfCare : Reference [0..*] « EpisodeOfCare »The request this encounter satisfies (e.g. incoming referral or procedure request)basedOn : Reference [0..*] « CarePlan|DeviceRequest| MedicationRequest|ServiceRequest »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 encountercareTeam : Reference [0..*] « CareTeam »Another Encounter of which this encounter is a part of (administratively or in time)partOf : Reference [0..1] « Encounter »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 colonoscopyserviceProvider : Reference [0..1] « Organization »The appointment that scheduled this encounterappointment : Reference [0..*] « Appointment »Connection details of a virtual service (e.g. conference call)virtualService : VirtualServiceDetail [0..*]The actual start and end time of the encounteractualPeriod : Period [0..1]The planned start date/time (or admission date) of the encounterplannedStartDate : dateTime [0..1]The planned end date/time (or discharge date) of the encounterplannedEndDate : dateTime [0..1]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 valueslength : Duration [0..1]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 diagnosisreason : CodeableReference [0..*] « Condition|DiagnosticReport| ImmunizationRecommendation|Observation|Procedure; null (Strength=Preferred) EncounterReasonCodes? »The set of accounts that may be used for billing for this Encounteraccount : Reference [0..*] « Account »StatusHistoryplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknownstatus : code [1..1] « null (Strength=Required)EncounterStatus! »The time that the episode was in the specified statusperiod : Period [1..1]ClassHistoryinpatient | outpatient | ambulatory | emergency +class : Coding [1..1] « null (Strength=Preferred)EncounterClass? »The time that the episode was in the specified classperiod : Period [1..1]ParticipantRole of participant in encountertype : CodeableConcept [0..*] « null (Strength=Extensible)ParticipantType+ »The period of time that the specified participant participated in the encounter. These can overlap or be sub-sets of the overall encounter's periodperiod : Period [0..1]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 timesactor : Reference [0..1] « Patient|Group|RelatedPerson|Practitioner| PractitionerRole|Device|HealthcareService »DiagnosisReason 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 Procedurecondition : Reference [1..1] « Condition|Procedure »Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)use : CodeableConcept [0..1] « null (Strength=Preferred)DiagnosisRole? »Ranking of the diagnosis (for each role type)rank : positiveInt [0..1]AdmissionPre-admission identifierpreAdmissionIdentifier : Identifier [0..1]The location/organization from which the patient came before admissionorigin : Reference [0..1] « Location|Organization »From where patient was admitted (physician referral, transfer)admitSource : CodeableConcept [0..1] « null (Strength=Preferred)AdmitSource? »Whether this admission is a readmission and why if knownreAdmission : CodeableConcept [0..1] « null (Strength=Example)Hl7VSReAdmissionIndicator?? »Diet preferences reported by the patientdietPreference : CodeableConcept [0..*] « null (Strength=Example)Diet?? »Special courtesies (VIP, board member)specialCourtesy : CodeableConcept [0..*] « null (Strength=Preferred)SpecialCourtesy? »Any special requests that have been made for this admission encounter, such as the provision of specific equipment or other thingsspecialArrangement : CodeableConcept [0..*] « null (Strength=Preferred)SpecialArrangements? »Location/organization to which the patient is dischargeddestination : Reference [0..1] « Location|Organization »Category or kind of location after dischargedischargeDisposition : CodeableConcept [0..1] « null (Strength=Example)DischargeDisposition?? »LocationThe location where the encounter takes placelocation : Reference [1..1] « Location »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/timestatus : code [0..1] « null (Strength=Required)EncounterLocationStatus! »This will be used to specify the required levels (bed/ward/room/etc.) desired to be recorded to simplify either messaging or queryform : CodeableConcept [0..1] « null (Strength=Example)LocationForm?? »Time period during which the patient was present at the locationperiod : Period [0..1]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 inpatientclassHistory[0..*]The list of people responsible for providing the serviceparticipant[0..*]The list of diagnosis relevant to this encounterdiagnosis[0..*]Details about the admission to a healthcare serviceadmission[0..1]List of locations where the patient has been during this encounterlocation[0..*]

XML Template

<Encounter xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Identifier(s) by which this encounter is known --></identifier>
 <status value="[code]"/><!-- 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown -->
 <statusHistory>  <!-- 0..* List of past encounter statuses -->
  <status value="[code]"/><!-- 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown -->
  <period><!-- 1..1 Period The time that the episode was in the specified status --></period>
 </statusHistory>
 <class><!-- 0..* CodeableConcept Classification of patient encounter context - e.g. Inpatient, outpatient icon --></class>
 <classHistory>  <!-- 0..* List of past encounter classes -->
  <class><!-- 1..1 Coding inpatient | outpatient | ambulatory | emergency + icon --></class>
  <period><!-- 1..1 Period The time that the episode was in the specified class --></period>
 </classHistory>
 <priority><!-- 0..1 CodeableConcept Indicates the urgency of the encounter icon --></priority>
 <type><!-- 0..* CodeableConcept Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...) --></type>
 <serviceType><!-- 0..* CodeableReference(HealthcareService) Specific type of service --></serviceType>
 <subject><!-- 0..1 Reference(Group|Patient) The patient or group related to this encounter --></subject>
 <subjectStatus><!-- 0..1 CodeableConcept The current status of the subject in relation to the Encounter --></subjectStatus>
 <episodeOfCare><!-- 0..* Reference(EpisodeOfCare) Episode(s) of care that this encounter should be recorded against --></episodeOfCare>
 <basedOn><!-- 0..* Reference(CarePlan|DeviceRequest|MedicationRequest|
   ServiceRequest) The request that initiated this encounter --></basedOn>
 <careTeam><!-- 0..* Reference(CareTeam) The group(s) that are allocated to participate in this encounter --></careTeam>
 <partOf><!-- 0..1 Reference(Encounter) Another Encounter this encounter is part of --></partOf>
 <serviceProvider><!-- 0..1 Reference(Organization) The organization (facility) responsible for this encounter --></serviceProvider>
 <participant>  <!-- 0..* List of participants involved in the encounter -->
  <type><!-- 0..* CodeableConcept Role of participant in encounter --></type>
  <period><!-- 0..1 Period Period of time during the encounter that the participant participated --></period>
  <actor><!-- 0..1 Reference(Device|Group|HealthcareService|Patient|Practitioner|
    PractitionerRole|RelatedPerson) The individual, device, or service participating in the encounter --></actor>
 </participant>
 <appointment><!-- 0..* Reference(Appointment) The appointment that scheduled this encounter --></appointment>
 <virtualService><!-- 0..* VirtualServiceDetail Connection details of a virtual service (e.g. conference call) --></virtualService>
 <actualPeriod><!-- 0..1 Period The actual start and end time of the encounter --></actualPeriod>
 <plannedStartDate value="[dateTime]"/><!-- 0..1 The planned start date/time (or admission date) of the encounter -->
 <plannedEndDate value="[dateTime]"/><!-- 0..1 The planned end date/time (or discharge date) of the encounter -->
 <length><!-- 0..1 Duration Actual quantity of time the encounter lasted (less time absent) --></length>
 <reason><!-- 0..* CodeableReference(Condition|DiagnosticReport|
   ImmunizationRecommendation|Observation|Procedure) Reason the encounter takes place (core or reference) --></reason>
 <diagnosis>  <!-- 0..* The list of diagnosis relevant to this encounter -->
  <condition><!-- 1..1 Reference(Condition|Procedure) The diagnosis or procedure relevant to the encounter --></condition>
  <use><!-- 0..1 CodeableConcept Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …) --></use>
  <rank value="[positiveInt]"/><!-- 0..1 Ranking of the diagnosis (for each role type) -->
 </diagnosis>
 <account><!-- 0..* Reference(Account) The set of accounts that may be used for billing for this Encounter --></account>
 <admission>  <!-- 0..1 Details about the admission to a healthcare service -->
  <preAdmissionIdentifier><!-- 0..1 Identifier Pre-admission identifier --></preAdmissionIdentifier>
  <origin><!-- 0..1 Reference(Location|Organization) The location/organization from which the patient came before admission --></origin>
  <admitSource><!-- 0..1 CodeableConcept From where patient was admitted (physician referral, transfer) --></admitSource>
  <reAdmission><!-- 0..1 CodeableConcept The type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission icon --></reAdmission>
  <dietPreference><!-- 0..* CodeableConcept Diet preferences reported by the patient --></dietPreference>
  <specialCourtesy><!-- 0..* CodeableConcept Special courtesies (VIP, board member) --></specialCourtesy>
  <specialArrangement><!-- 0..* CodeableConcept Wheelchair, translator, stretcher, etc. --></specialArrangement>
  <destination><!-- 0..1 Reference(Location|Organization) Location/organization to which the patient is discharged --></destination>
  <dischargeDisposition><!-- 0..1 CodeableConcept Category or kind of location after discharge --></dischargeDisposition>
 </admission>
 <location>  <!-- 0..* List of locations where the patient has been -->
  <location><!-- 1..1 Reference(Location) Location the encounter takes place --></location>
  <status value="[code]"/><!-- 0..1 planned | active | reserved | completed -->
  <form><!-- 0..1 CodeableConcept The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.) --></form>
  <period><!-- 0..1 Period Time period during which the patient was present at the location --></period>
 </location>
</Encounter>

JSON Template

{doco
  "resourceType" : "Encounter",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifier(s) by which this encounter is known
  "status" : "<code>", // R!  planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
  "statusHistory" : [{ // List of past encounter statuses
    "status" : "<code>", // R!  planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
    "period" : { Period } // R!  The time that the episode was in the specified status
  }],
  "class" : [{ CodeableConcept }], // Classification of patient encounter context - e.g. Inpatient, outpatient icon
  "classHistory" : [{ // List of past encounter classes
    "class" : { Coding }, // R!  inpatient | outpatient | ambulatory | emergency + icon
    "period" : { Period } // R!  The time that the episode was in the specified class
  }],
  "priority" : { CodeableConcept }, // Indicates the urgency of the encounter icon
  "type" : [{ CodeableConcept }], // Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
  "serviceType" : [{ CodeableReference(HealthcareService) }], // Specific type of service
  "subject" : { Reference(Group|Patient) }, // The patient or group related to this encounter
  "subjectStatus" : { CodeableConcept }, // The current status of the subject in relation to the Encounter
  "episodeOfCare" : [{ Reference(EpisodeOfCare) }], // Episode(s) of care that this encounter should be recorded against
  "basedOn" : [{ Reference(CarePlan|DeviceRequest|MedicationRequest|
   ServiceRequest) }], // The request that initiated this encounter
  "careTeam" : [{ Reference(CareTeam) }], // The group(s) that are allocated to participate in this encounter
  "partOf" : { Reference(Encounter) }, // Another Encounter this encounter is part of
  "serviceProvider" : { Reference(Organization) }, // The organization (facility) responsible for this encounter
  "participant" : [{ // List of participants involved in the encounter
    "type" : [{ CodeableConcept }], // Role of participant in encounter
    "period" : { Period }, // Period of time during the encounter that the participant participated
    "actor" : { Reference(Device|Group|HealthcareService|Patient|Practitioner|
    PractitionerRole|RelatedPerson) } // The individual, device, or service participating in the encounter
  }],
  "appointment" : [{ Reference(Appointment) }], // The appointment that scheduled this encounter
  "virtualService" : [{ VirtualServiceDetail }], // Connection details of a virtual service (e.g. conference call)
  "actualPeriod" : { Period }, // The actual start and end time of the encounter
  "plannedStartDate" : "<dateTime>", // The planned start date/time (or admission date) of the encounter
  "plannedEndDate" : "<dateTime>", // The planned end date/time (or discharge date) of the encounter
  "length" : { Duration }, // Actual quantity of time the encounter lasted (less time absent)
  "reason" : [{ CodeableReference(Condition|DiagnosticReport|
   ImmunizationRecommendation|Observation|Procedure) }], // Reason the encounter takes place (core or reference)
  "diagnosis" : [{ // The list of diagnosis relevant to this encounter
    "condition" : { Reference(Condition|Procedure) }, // R!  The diagnosis or procedure relevant to the encounter
    "use" : { CodeableConcept }, // Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
    "rank" : "<positiveInt>" // Ranking of the diagnosis (for each role type)
  }],
  "account" : [{ Reference(Account) }], // The set of accounts that may be used for billing for this Encounter
  "admission" : { // Details about the admission to a healthcare service
    "preAdmissionIdentifier" : { Identifier }, // Pre-admission identifier
    "origin" : { Reference(Location|Organization) }, // The location/organization from which the patient came before admission
    "admitSource" : { CodeableConcept }, // From where patient was admitted (physician referral, transfer)
    "reAdmission" : { CodeableConcept }, // The type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission icon
    "dietPreference" : [{ CodeableConcept }], // Diet preferences reported by the patient
    "specialCourtesy" : [{ CodeableConcept }], // Special courtesies (VIP, board member)
    "specialArrangement" : [{ CodeableConcept }], // Wheelchair, translator, stretcher, etc.
    "destination" : { Reference(Location|Organization) }, // Location/organization to which the patient is discharged
    "dischargeDisposition" : { CodeableConcept } // Category or kind of location after discharge
  },
  "location" : [{ // List of locations where the patient has been
    "location" : { Reference(Location) }, // R!  Location the encounter takes place
    "status" : "<code>", // planned | active | reserved | completed
    "form" : { CodeableConcept }, // The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
    "period" : { Period } // Time period during which the patient was present at the location
  }]
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Encounter;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Encounter.identifier [ Identifier ], ... ; # 0..* Identifier(s) by which this encounter is known
  fhir:Encounter.status [ code ]; # 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
  fhir:Encounter.statusHistory [ # 0..* List of past encounter statuses
    fhir:Encounter.statusHistory.status [ code ]; # 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
    fhir:Encounter.statusHistory.period [ Period ]; # 1..1 The time that the episode was in the specified status
  ], ...;
  fhir:Encounter.class [ CodeableConcept ], ... ; # 0..* Classification of patient encounter context - e.g. Inpatient, outpatient
  fhir:Encounter.classHistory [ # 0..* List of past encounter classes
    fhir:Encounter.classHistory.class [ Coding ]; # 1..1 inpatient | outpatient | ambulatory | emergency +
    fhir:Encounter.classHistory.period [ Period ]; # 1..1 The time that the episode was in the specified class
  ], ...;
  fhir:Encounter.priority [ CodeableConcept ]; # 0..1 Indicates the urgency of the encounter
  fhir:Encounter.type [ CodeableConcept ], ... ; # 0..* Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
  fhir:Encounter.serviceType [ CodeableReference(HealthcareService) ], ... ; # 0..* Specific type of service
  fhir:Encounter.subject [ Reference(Group|Patient) ]; # 0..1 The patient or group related to this encounter
  fhir:Encounter.subjectStatus [ CodeableConcept ]; # 0..1 The current status of the subject in relation to the Encounter
  fhir:Encounter.episodeOfCare [ Reference(EpisodeOfCare) ], ... ; # 0..* Episode(s) of care that this encounter should be recorded against
  fhir:Encounter.basedOn [ Reference(CarePlan|DeviceRequest|MedicationRequest|ServiceRequest) ], ... ; # 0..* The request that initiated this encounter
  fhir:Encounter.careTeam [ Reference(CareTeam) ], ... ; # 0..* The group(s) that are allocated to participate in this encounter
  fhir:Encounter.partOf [ Reference(Encounter) ]; # 0..1 Another Encounter this encounter is part of
  fhir:Encounter.serviceProvider [ Reference(Organization) ]; # 0..1 The organization (facility) responsible for this encounter
  fhir:Encounter.participant [ # 0..* List of participants involved in the encounter
    fhir:Encounter.participant.type [ CodeableConcept ], ... ; # 0..* Role of participant in encounter
    fhir:Encounter.participant.period [ Period ]; # 0..1 Period of time during the encounter that the participant participated
    fhir:Encounter.participant.actor [ Reference(Device|Group|HealthcareService|Patient|Practitioner|PractitionerRole|
  RelatedPerson) ]; # 0..1 The individual, device, or service participating in the encounter
  ], ...;
  fhir:Encounter.appointment [ Reference(Appointment) ], ... ; # 0..* The appointment that scheduled this encounter
  fhir:Encounter.virtualService [ VirtualServiceDetail ], ... ; # 0..* Connection details of a virtual service (e.g. conference call)
  fhir:Encounter.actualPeriod [ Period ]; # 0..1 The actual start and end time of the encounter
  fhir:Encounter.plannedStartDate [ dateTime ]; # 0..1 The planned start date/time (or admission date) of the encounter
  fhir:Encounter.plannedEndDate [ dateTime ]; # 0..1 The planned end date/time (or discharge date) of the encounter
  fhir:Encounter.length [ Duration ]; # 0..1 Actual quantity of time the encounter lasted (less time absent)
  fhir:Encounter.reason [ CodeableReference(Condition|DiagnosticReport|ImmunizationRecommendation|Observation|Procedure) ], ... ; # 0..* Reason the encounter takes place (core or reference)
  fhir:Encounter.diagnosis [ # 0..* The list of diagnosis relevant to this encounter
    fhir:Encounter.diagnosis.condition [ Reference(Condition|Procedure) ]; # 1..1 The diagnosis or procedure relevant to the encounter
    fhir:Encounter.diagnosis.use [ CodeableConcept ]; # 0..1 Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
    fhir:Encounter.diagnosis.rank [ positiveInt ]; # 0..1 Ranking of the diagnosis (for each role type)
  ], ...;
  fhir:Encounter.account [ Reference(Account) ], ... ; # 0..* The set of accounts that may be used for billing for this Encounter
  fhir:Encounter.admission [ # 0..1 Details about the admission to a healthcare service
    fhir:Encounter.admission.preAdmissionIdentifier [ Identifier ]; # 0..1 Pre-admission identifier
    fhir:Encounter.admission.origin [ Reference(Location|Organization) ]; # 0..1 The location/organization from which the patient came before admission
    fhir:Encounter.admission.admitSource [ CodeableConcept ]; # 0..1 From where patient was admitted (physician referral, transfer)
    fhir:Encounter.admission.reAdmission [ CodeableConcept ]; # 0..1 The type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission
    fhir:Encounter.admission.dietPreference [ CodeableConcept ], ... ; # 0..* Diet preferences reported by the patient
    fhir:Encounter.admission.specialCourtesy [ CodeableConcept ], ... ; # 0..* Special courtesies (VIP, board member)
    fhir:Encounter.admission.specialArrangement [ CodeableConcept ], ... ; # 0..* Wheelchair, translator, stretcher, etc.
    fhir:Encounter.admission.destination [ Reference(Location|Organization) ]; # 0..1 Location/organization to which the patient is discharged
    fhir:Encounter.admission.dischargeDisposition [ CodeableConcept ]; # 0..1 Category or kind of location after discharge
  ];
  fhir:Encounter.location [ # 0..* List of locations where the patient has been
    fhir:Encounter.location.location [ Reference(Location) ]; # 1..1 Location the encounter takes place
    fhir:Encounter.location.status [ code ]; # 0..1 planned | active | reserved | completed
    fhir:Encounter.location.form [ CodeableConcept ]; # 0..1 The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
    fhir:Encounter.location.period [ Period ]; # 0..1 Time period during which the patient was present at the location
  ], ...;
]

Changes since R4

Encounter
Encounter.class
  • Min Cardinality changed from 1 to 0
  • Max Cardinality changed from 1 to *
  • Type changed from Coding to CodeableConcept
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
Encounter.classHistory.class
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
Encounter.serviceType
  • Max Cardinality changed from 1 to *
  • Type changed from CodeableConcept to CodeableReference
  • Type changed from CodeableConcept to CodeableReference
Encounter.subjectStatus
  • Added Element
Encounter.basedOn
  • Type Reference: Added Target Types CarePlan, DeviceRequest, MedicationRequest
  • Type Reference: Added Target Types CarePlan, DeviceRequest, MedicationRequest
Encounter.careTeam
  • Added Element
Encounter.participant.actor
  • Added Element
Encounter.virtualService
  • Added Element
Encounter.actualPeriod
  • Added Element
Encounter.plannedStartDate
  • Added Element
Encounter.plannedEndDate
  • Added Element
Encounter.reason
  • Added Element
Encounter.admission
  • Added Element
Encounter.admission.preAdmissionIdentifier
  • Added Element
Encounter.admission.origin
  • Added Element
Encounter.admission.admitSource
  • Added Element
Encounter.admission.reAdmission
  • Added Element
Encounter.admission.dietPreference
  • Added Element
Encounter.admission.specialCourtesy
  • Added Element
Encounter.admission.specialArrangement
  • Added Element
Encounter.admission.destination
  • Added Element
Encounter.admission.dischargeDisposition
  • Added Element
Encounter.location.form
  • Added Element
Encounter.participant.individual
  • deleted
Encounter.period
  • deleted
Encounter.reasonCode
  • deleted
Encounter.reasonReference
  • deleted
Encounter.hospitalization
  • deleted
Encounter.location.physicalType
  • deleted

See the Full Difference for further information

This analysis is available as XML or JSON.

See R3 <--> R4 Conversion Maps (status = 10 tests that all execute ok. All tests pass round-trip testing and 3 r3 resources are invalid (0 errors).)

Structure

Name iconFlags iconCard. iconType iconDescription & Constraints icondoco icon
.. Encounter TUDomainResourceAn interaction during which services are provided to the patient

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierIdentifier(s) by which this encounter is known

... status ?!Σ1..1codeplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
EncounterStatus (Required)
... statusHistory 0..*BackboneElementList of past encounter statuses

.... status 1..1codeplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
EncounterStatus (Required)
.... period 1..1PeriodThe time that the episode was in the specified status
... class Σ0..*CodeableConceptClassification of patient encounter context - e.g. Inpatient, outpatient
Encounter class icon (Preferred)

... classHistory 0..*BackboneElementList of past encounter classes

.... class 1..1Codinginpatient | outpatient | ambulatory | emergency +
Encounter class icon (Preferred)
.... period 1..1PeriodThe time that the episode was in the specified class
... priority 0..1CodeableConceptIndicates the urgency of the encounter
ActPriority icon (Example)
... type Σ0..*CodeableConceptSpecific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
EncounterType (Example)

... serviceType Σ0..*CodeableReference(HealthcareService)Specific type of service
ServiceType (Example)

... subject Σ0..1Reference(Patient | Group)The patient or group related to this encounter
... subjectStatus 0..1CodeableConceptThe current status of the subject in relation to the Encounter
EncounterSubjectStatus (Example)
... episodeOfCare Σ0..*Reference(EpisodeOfCare)Episode(s) of care that this encounter should be recorded against

... basedOn 0..*Reference(CarePlan | DeviceRequest | MedicationRequest | ServiceRequest)The request that initiated this encounter

... careTeam 0..*Reference(CareTeam)The group(s) that are allocated to participate in this encounter

... partOf 0..1Reference(Encounter)Another Encounter this encounter is part of
... serviceProvider 0..1Reference(Organization)The organization (facility) responsible for this encounter
... participant ΣC0..*BackboneElementList of participants involved in the encounter
+ Rule: A type must be provided when no explicit actor is specified
+ Rule: A type cannot be provided for a patient or group participant

.... type Σ0..*CodeableConceptRole of participant in encounter
ParticipantType (Extensible)

.... period 0..1PeriodPeriod of time during the encounter that the participant participated
.... actor Σ0..1Reference(Patient | Group | RelatedPerson | Practitioner | PractitionerRole | Device | HealthcareService)The individual, device, or service participating in the encounter
... appointment Σ0..*Reference(Appointment)The appointment that scheduled this encounter

... virtualService 0..*VirtualServiceDetailConnection details of a virtual service (e.g. conference call)

... actualPeriod 0..1PeriodThe actual start and end time of the encounter
... plannedStartDate 0..1dateTimeThe planned start date/time (or admission date) of the encounter
... plannedEndDate 0..1dateTimeThe planned end date/time (or discharge date) of the encounter
... length 0..1DurationActual quantity of time the encounter lasted (less time absent)
... reason Σ0..*CodeableReference(Condition | DiagnosticReport | ImmunizationRecommendation | Observation | Procedure)Reason the encounter takes place (core or reference)
Encounter Reason Codes (Preferred)

... diagnosis Σ0..*BackboneElementThe list of diagnosis relevant to this encounter

.... condition Σ1..1Reference(Condition | Procedure)The diagnosis or procedure relevant to the encounter
.... use 0..1CodeableConceptRole that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
DiagnosisRole (Preferred)
.... rank 0..1positiveIntRanking of the diagnosis (for each role type)
... account 0..*Reference(Account)The set of accounts that may be used for billing for this Encounter

... admission 0..1BackboneElementDetails about the admission to a healthcare service
.... preAdmissionIdentifier 0..1IdentifierPre-admission identifier
.... origin 0..1Reference(Location | Organization)The location/organization from which the patient came before admission
.... admitSource 0..1CodeableConceptFrom where patient was admitted (physician referral, transfer)
AdmitSource (Preferred)
.... reAdmission 0..1CodeableConceptThe type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission
hl7VS-re-admissionIndicator icon (Example)
.... dietPreference 0..*CodeableConceptDiet preferences reported by the patient
Diet (Example)

.... specialCourtesy 0..*CodeableConceptSpecial courtesies (VIP, board member)
SpecialCourtesy (Preferred)

.... specialArrangement 0..*CodeableConceptWheelchair, translator, stretcher, etc.
SpecialArrangements (Preferred)

.... destination 0..1Reference(Location | Organization)Location/organization to which the patient is discharged
.... dischargeDisposition 0..1CodeableConceptCategory or kind of location after discharge
DischargeDisposition (Example)
... location 0..*BackboneElementList of locations where the patient has been

.... location 1..1Reference(Location)Location the encounter takes place
.... status 0..1codeplanned | active | reserved | completed
EncounterLocationStatus (Required)
.... form 0..1CodeableConceptThe physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
Location Form (Example)
.... period 0..1PeriodTime period during which the patient was present at the location

doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

Encounter (DomainResource)Identifier(s) by which this encounter is knownidentifier : Identifier [0..*]planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)EncounterStatus! »Concepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variationsclass : CodeableConcept [0..*] « null (Strength=Preferred)EncounterClass? »Indicates the urgency of the encounterpriority : CodeableConcept [0..1] « null (Strength=Example)ActPriority?? »Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation)type : CodeableConcept [0..*] « null (Strength=Example)EncounterType?? »Broad categorization of the service that is to be provided (e.g. cardiology)serviceType : CodeableReference [0..*] « HealthcareService; null (Strength=Example) ServiceType?? »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 careteamsubject : Reference [0..1] « Patient|Group »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 statussubjectStatus : CodeableConcept [0..1] « null (Strength=Example)EncounterSubjectStatus?? »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)episodeOfCare : Reference [0..*] « EpisodeOfCare »The request this encounter satisfies (e.g. incoming referral or procedure request)basedOn : Reference [0..*] « CarePlan|DeviceRequest| MedicationRequest|ServiceRequest »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 encountercareTeam : Reference [0..*] « CareTeam »Another Encounter of which this encounter is a part of (administratively or in time)partOf : Reference [0..1] « Encounter »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 colonoscopyserviceProvider : Reference [0..1] « Organization »The appointment that scheduled this encounterappointment : Reference [0..*] « Appointment »Connection details of a virtual service (e.g. conference call)virtualService : VirtualServiceDetail [0..*]The actual start and end time of the encounteractualPeriod : Period [0..1]The planned start date/time (or admission date) of the encounterplannedStartDate : dateTime [0..1]The planned end date/time (or discharge date) of the encounterplannedEndDate : dateTime [0..1]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 valueslength : Duration [0..1]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 diagnosisreason : CodeableReference [0..*] « Condition|DiagnosticReport| ImmunizationRecommendation|Observation|Procedure; null (Strength=Preferred) EncounterReasonCodes? »The set of accounts that may be used for billing for this Encounteraccount : Reference [0..*] « Account »StatusHistoryplanned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknownstatus : code [1..1] « null (Strength=Required)EncounterStatus! »The time that the episode was in the specified statusperiod : Period [1..1]ClassHistoryinpatient | outpatient | ambulatory | emergency +class : Coding [1..1] « null (Strength=Preferred)EncounterClass? »The time that the episode was in the specified classperiod : Period [1..1]ParticipantRole of participant in encountertype : CodeableConcept [0..*] « null (Strength=Extensible)ParticipantType+ »The period of time that the specified participant participated in the encounter. These can overlap or be sub-sets of the overall encounter's periodperiod : Period [0..1]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 timesactor : Reference [0..1] « Patient|Group|RelatedPerson|Practitioner| PractitionerRole|Device|HealthcareService »DiagnosisReason 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 Procedurecondition : Reference [1..1] « Condition|Procedure »Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)use : CodeableConcept [0..1] « null (Strength=Preferred)DiagnosisRole? »Ranking of the diagnosis (for each role type)rank : positiveInt [0..1]AdmissionPre-admission identifierpreAdmissionIdentifier : Identifier [0..1]The location/organization from which the patient came before admissionorigin : Reference [0..1] « Location|Organization »From where patient was admitted (physician referral, transfer)admitSource : CodeableConcept [0..1] « null (Strength=Preferred)AdmitSource? »Whether this admission is a readmission and why if knownreAdmission : CodeableConcept [0..1] « null (Strength=Example)Hl7VSReAdmissionIndicator?? »Diet preferences reported by the patientdietPreference : CodeableConcept [0..*] « null (Strength=Example)Diet?? »Special courtesies (VIP, board member)specialCourtesy : CodeableConcept [0..*] « null (Strength=Preferred)SpecialCourtesy? »Any special requests that have been made for this admission encounter, such as the provision of specific equipment or other thingsspecialArrangement : CodeableConcept [0..*] « null (Strength=Preferred)SpecialArrangements? »Location/organization to which the patient is dischargeddestination : Reference [0..1] « Location|Organization »Category or kind of location after dischargedischargeDisposition : CodeableConcept [0..1] « null (Strength=Example)DischargeDisposition?? »LocationThe location where the encounter takes placelocation : Reference [1..1] « Location »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/timestatus : code [0..1] « null (Strength=Required)EncounterLocationStatus! »This will be used to specify the required levels (bed/ward/room/etc.) desired to be recorded to simplify either messaging or queryform : CodeableConcept [0..1] « null (Strength=Example)LocationForm?? »Time period during which the patient was present at the locationperiod : Period [0..1]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 inpatientclassHistory[0..*]The list of people responsible for providing the serviceparticipant[0..*]The list of diagnosis relevant to this encounterdiagnosis[0..*]Details about the admission to a healthcare serviceadmission[0..1]List of locations where the patient has been during this encounterlocation[0..*]

XML Template

<Encounter xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Identifier(s) by which this encounter is known --></identifier>
 <status value="[code]"/><!-- 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown -->
 <statusHistory>  <!-- 0..* List of past encounter statuses -->
  <status value="[code]"/><!-- 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown -->
  <period><!-- 1..1 Period The time that the episode was in the specified status --></period>
 </statusHistory>
 <class><!-- 0..* CodeableConcept Classification of patient encounter context - e.g. Inpatient, outpatient icon --></class>
 <classHistory>  <!-- 0..* List of past encounter classes -->
  <class><!-- 1..1 Coding inpatient | outpatient | ambulatory | emergency + icon --></class>
  <period><!-- 1..1 Period The time that the episode was in the specified class --></period>
 </classHistory>
 <priority><!-- 0..1 CodeableConcept Indicates the urgency of the encounter icon --></priority>
 <type><!-- 0..* CodeableConcept Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...) --></type>
 <serviceType><!-- 0..* CodeableReference(HealthcareService) Specific type of service --></serviceType>
 <subject><!-- 0..1 Reference(Group|Patient) The patient or group related to this encounter --></subject>
 <subjectStatus><!-- 0..1 CodeableConcept The current status of the subject in relation to the Encounter --></subjectStatus>
 <episodeOfCare><!-- 0..* Reference(EpisodeOfCare) Episode(s) of care that this encounter should be recorded against --></episodeOfCare>
 <basedOn><!-- 0..* Reference(CarePlan|DeviceRequest|MedicationRequest|
   ServiceRequest) The request that initiated this encounter --></basedOn>
 <careTeam><!-- 0..* Reference(CareTeam) The group(s) that are allocated to participate in this encounter --></careTeam>
 <partOf><!-- 0..1 Reference(Encounter) Another Encounter this encounter is part of --></partOf>
 <serviceProvider><!-- 0..1 Reference(Organization) The organization (facility) responsible for this encounter --></serviceProvider>
 <participant>  <!-- 0..* List of participants involved in the encounter -->
  <type><!-- 0..* CodeableConcept Role of participant in encounter --></type>
  <period><!-- 0..1 Period Period of time during the encounter that the participant participated --></period>
  <actor><!-- 0..1 Reference(Device|Group|HealthcareService|Patient|Practitioner|
    PractitionerRole|RelatedPerson) The individual, device, or service participating in the encounter --></actor>
 </participant>
 <appointment><!-- 0..* Reference(Appointment) The appointment that scheduled this encounter --></appointment>
 <virtualService><!-- 0..* VirtualServiceDetail Connection details of a virtual service (e.g. conference call) --></virtualService>
 <actualPeriod><!-- 0..1 Period The actual start and end time of the encounter --></actualPeriod>
 <plannedStartDate value="[dateTime]"/><!-- 0..1 The planned start date/time (or admission date) of the encounter -->
 <plannedEndDate value="[dateTime]"/><!-- 0..1 The planned end date/time (or discharge date) of the encounter -->
 <length><!-- 0..1 Duration Actual quantity of time the encounter lasted (less time absent) --></length>
 <reason><!-- 0..* CodeableReference(Condition|DiagnosticReport|
   ImmunizationRecommendation|Observation|Procedure) Reason the encounter takes place (core or reference) --></reason>
 <diagnosis>  <!-- 0..* The list of diagnosis relevant to this encounter -->
  <condition><!-- 1..1 Reference(Condition|Procedure) The diagnosis or procedure relevant to the encounter --></condition>
  <use><!-- 0..1 CodeableConcept Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …) --></use>
  <rank value="[positiveInt]"/><!-- 0..1 Ranking of the diagnosis (for each role type) -->
 </diagnosis>
 <account><!-- 0..* Reference(Account) The set of accounts that may be used for billing for this Encounter --></account>
 <admission>  <!-- 0..1 Details about the admission to a healthcare service -->
  <preAdmissionIdentifier><!-- 0..1 Identifier Pre-admission identifier --></preAdmissionIdentifier>
  <origin><!-- 0..1 Reference(Location|Organization) The location/organization from which the patient came before admission --></origin>
  <admitSource><!-- 0..1 CodeableConcept From where patient was admitted (physician referral, transfer) --></admitSource>
  <reAdmission><!-- 0..1 CodeableConcept The type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission icon --></reAdmission>
  <dietPreference><!-- 0..* CodeableConcept Diet preferences reported by the patient --></dietPreference>
  <specialCourtesy><!-- 0..* CodeableConcept Special courtesies (VIP, board member) --></specialCourtesy>
  <specialArrangement><!-- 0..* CodeableConcept Wheelchair, translator, stretcher, etc. --></specialArrangement>
  <destination><!-- 0..1 Reference(Location|Organization) Location/organization to which the patient is discharged --></destination>
  <dischargeDisposition><!-- 0..1 CodeableConcept Category or kind of location after discharge --></dischargeDisposition>
 </admission>
 <location>  <!-- 0..* List of locations where the patient has been -->
  <location><!-- 1..1 Reference(Location) Location the encounter takes place --></location>
  <status value="[code]"/><!-- 0..1 planned | active | reserved | completed -->
  <form><!-- 0..1 CodeableConcept The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.) --></form>
  <period><!-- 0..1 Period Time period during which the patient was present at the location --></period>
 </location>
</Encounter>

JSON Template

{doco
  "resourceType" : "Encounter",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Identifier(s) by which this encounter is known
  "status" : "<code>", // R!  planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
  "statusHistory" : [{ // List of past encounter statuses
    "status" : "<code>", // R!  planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
    "period" : { Period } // R!  The time that the episode was in the specified status
  }],
  "class" : [{ CodeableConcept }], // Classification of patient encounter context - e.g. Inpatient, outpatient icon
  "classHistory" : [{ // List of past encounter classes
    "class" : { Coding }, // R!  inpatient | outpatient | ambulatory | emergency + icon
    "period" : { Period } // R!  The time that the episode was in the specified class
  }],
  "priority" : { CodeableConcept }, // Indicates the urgency of the encounter icon
  "type" : [{ CodeableConcept }], // Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
  "serviceType" : [{ CodeableReference(HealthcareService) }], // Specific type of service
  "subject" : { Reference(Group|Patient) }, // The patient or group related to this encounter
  "subjectStatus" : { CodeableConcept }, // The current status of the subject in relation to the Encounter
  "episodeOfCare" : [{ Reference(EpisodeOfCare) }], // Episode(s) of care that this encounter should be recorded against
  "basedOn" : [{ Reference(CarePlan|DeviceRequest|MedicationRequest|
   ServiceRequest) }], // The request that initiated this encounter
  "careTeam" : [{ Reference(CareTeam) }], // The group(s) that are allocated to participate in this encounter
  "partOf" : { Reference(Encounter) }, // Another Encounter this encounter is part of
  "serviceProvider" : { Reference(Organization) }, // The organization (facility) responsible for this encounter
  "participant" : [{ // List of participants involved in the encounter
    "type" : [{ CodeableConcept }], // Role of participant in encounter
    "period" : { Period }, // Period of time during the encounter that the participant participated
    "actor" : { Reference(Device|Group|HealthcareService|Patient|Practitioner|
    PractitionerRole|RelatedPerson) } // The individual, device, or service participating in the encounter
  }],
  "appointment" : [{ Reference(Appointment) }], // The appointment that scheduled this encounter
  "virtualService" : [{ VirtualServiceDetail }], // Connection details of a virtual service (e.g. conference call)
  "actualPeriod" : { Period }, // The actual start and end time of the encounter
  "plannedStartDate" : "<dateTime>", // The planned start date/time (or admission date) of the encounter
  "plannedEndDate" : "<dateTime>", // The planned end date/time (or discharge date) of the encounter
  "length" : { Duration }, // Actual quantity of time the encounter lasted (less time absent)
  "reason" : [{ CodeableReference(Condition|DiagnosticReport|
   ImmunizationRecommendation|Observation|Procedure) }], // Reason the encounter takes place (core or reference)
  "diagnosis" : [{ // The list of diagnosis relevant to this encounter
    "condition" : { Reference(Condition|Procedure) }, // R!  The diagnosis or procedure relevant to the encounter
    "use" : { CodeableConcept }, // Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
    "rank" : "<positiveInt>" // Ranking of the diagnosis (for each role type)
  }],
  "account" : [{ Reference(Account) }], // The set of accounts that may be used for billing for this Encounter
  "admission" : { // Details about the admission to a healthcare service
    "preAdmissionIdentifier" : { Identifier }, // Pre-admission identifier
    "origin" : { Reference(Location|Organization) }, // The location/organization from which the patient came before admission
    "admitSource" : { CodeableConcept }, // From where patient was admitted (physician referral, transfer)
    "reAdmission" : { CodeableConcept }, // The type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission icon
    "dietPreference" : [{ CodeableConcept }], // Diet preferences reported by the patient
    "specialCourtesy" : [{ CodeableConcept }], // Special courtesies (VIP, board member)
    "specialArrangement" : [{ CodeableConcept }], // Wheelchair, translator, stretcher, etc.
    "destination" : { Reference(Location|Organization) }, // Location/organization to which the patient is discharged
    "dischargeDisposition" : { CodeableConcept } // Category or kind of location after discharge
  },
  "location" : [{ // List of locations where the patient has been
    "location" : { Reference(Location) }, // R!  Location the encounter takes place
    "status" : "<code>", // planned | active | reserved | completed
    "form" : { CodeableConcept }, // The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
    "period" : { Period } // Time period during which the patient was present at the location
  }]
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Encounter;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Encounter.identifier [ Identifier ], ... ; # 0..* Identifier(s) by which this encounter is known
  fhir:Encounter.status [ code ]; # 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
  fhir:Encounter.statusHistory [ # 0..* List of past encounter statuses
    fhir:Encounter.statusHistory.status [ code ]; # 1..1 planned | in-progress | on-hold | discharged | completed | cancelled | discontinued | entered-in-error | unknown
    fhir:Encounter.statusHistory.period [ Period ]; # 1..1 The time that the episode was in the specified status
  ], ...;
  fhir:Encounter.class [ CodeableConcept ], ... ; # 0..* Classification of patient encounter context - e.g. Inpatient, outpatient
  fhir:Encounter.classHistory [ # 0..* List of past encounter classes
    fhir:Encounter.classHistory.class [ Coding ]; # 1..1 inpatient | outpatient | ambulatory | emergency +
    fhir:Encounter.classHistory.period [ Period ]; # 1..1 The time that the episode was in the specified class
  ], ...;
  fhir:Encounter.priority [ CodeableConcept ]; # 0..1 Indicates the urgency of the encounter
  fhir:Encounter.type [ CodeableConcept ], ... ; # 0..* Specific type of encounter (e.g. e-mail consultation, surgical day-care, ...)
  fhir:Encounter.serviceType [ CodeableReference(HealthcareService) ], ... ; # 0..* Specific type of service
  fhir:Encounter.subject [ Reference(Group|Patient) ]; # 0..1 The patient or group related to this encounter
  fhir:Encounter.subjectStatus [ CodeableConcept ]; # 0..1 The current status of the subject in relation to the Encounter
  fhir:Encounter.episodeOfCare [ Reference(EpisodeOfCare) ], ... ; # 0..* Episode(s) of care that this encounter should be recorded against
  fhir:Encounter.basedOn [ Reference(CarePlan|DeviceRequest|MedicationRequest|ServiceRequest) ], ... ; # 0..* The request that initiated this encounter
  fhir:Encounter.careTeam [ Reference(CareTeam) ], ... ; # 0..* The group(s) that are allocated to participate in this encounter
  fhir:Encounter.partOf [ Reference(Encounter) ]; # 0..1 Another Encounter this encounter is part of
  fhir:Encounter.serviceProvider [ Reference(Organization) ]; # 0..1 The organization (facility) responsible for this encounter
  fhir:Encounter.participant [ # 0..* List of participants involved in the encounter
    fhir:Encounter.participant.type [ CodeableConcept ], ... ; # 0..* Role of participant in encounter
    fhir:Encounter.participant.period [ Period ]; # 0..1 Period of time during the encounter that the participant participated
    fhir:Encounter.participant.actor [ Reference(Device|Group|HealthcareService|Patient|Practitioner|PractitionerRole|
  RelatedPerson) ]; # 0..1 The individual, device, or service participating in the encounter
  ], ...;
  fhir:Encounter.appointment [ Reference(Appointment) ], ... ; # 0..* The appointment that scheduled this encounter
  fhir:Encounter.virtualService [ VirtualServiceDetail ], ... ; # 0..* Connection details of a virtual service (e.g. conference call)
  fhir:Encounter.actualPeriod [ Period ]; # 0..1 The actual start and end time of the encounter
  fhir:Encounter.plannedStartDate [ dateTime ]; # 0..1 The planned start date/time (or admission date) of the encounter
  fhir:Encounter.plannedEndDate [ dateTime ]; # 0..1 The planned end date/time (or discharge date) of the encounter
  fhir:Encounter.length [ Duration ]; # 0..1 Actual quantity of time the encounter lasted (less time absent)
  fhir:Encounter.reason [ CodeableReference(Condition|DiagnosticReport|ImmunizationRecommendation|Observation|Procedure) ], ... ; # 0..* Reason the encounter takes place (core or reference)
  fhir:Encounter.diagnosis [ # 0..* The list of diagnosis relevant to this encounter
    fhir:Encounter.diagnosis.condition [ Reference(Condition|Procedure) ]; # 1..1 The diagnosis or procedure relevant to the encounter
    fhir:Encounter.diagnosis.use [ CodeableConcept ]; # 0..1 Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …)
    fhir:Encounter.diagnosis.rank [ positiveInt ]; # 0..1 Ranking of the diagnosis (for each role type)
  ], ...;
  fhir:Encounter.account [ Reference(Account) ], ... ; # 0..* The set of accounts that may be used for billing for this Encounter
  fhir:Encounter.admission [ # 0..1 Details about the admission to a healthcare service
    fhir:Encounter.admission.preAdmissionIdentifier [ Identifier ]; # 0..1 Pre-admission identifier
    fhir:Encounter.admission.origin [ Reference(Location|Organization) ]; # 0..1 The location/organization from which the patient came before admission
    fhir:Encounter.admission.admitSource [ CodeableConcept ]; # 0..1 From where patient was admitted (physician referral, transfer)
    fhir:Encounter.admission.reAdmission [ CodeableConcept ]; # 0..1 The type of re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission
    fhir:Encounter.admission.dietPreference [ CodeableConcept ], ... ; # 0..* Diet preferences reported by the patient
    fhir:Encounter.admission.specialCourtesy [ CodeableConcept ], ... ; # 0..* Special courtesies (VIP, board member)
    fhir:Encounter.admission.specialArrangement [ CodeableConcept ], ... ; # 0..* Wheelchair, translator, stretcher, etc.
    fhir:Encounter.admission.destination [ Reference(Location|Organization) ]; # 0..1 Location/organization to which the patient is discharged
    fhir:Encounter.admission.dischargeDisposition [ CodeableConcept ]; # 0..1 Category or kind of location after discharge
  ];
  fhir:Encounter.location [ # 0..* List of locations where the patient has been
    fhir:Encounter.location.location [ Reference(Location) ]; # 1..1 Location the encounter takes place
    fhir:Encounter.location.status [ code ]; # 0..1 planned | active | reserved | completed
    fhir:Encounter.location.form [ CodeableConcept ]; # 0..1 The physical type of the location (usually the level in the location hierarchy - bed, room, ward, virtual etc.)
    fhir:Encounter.location.period [ Period ]; # 0..1 Time period during which the patient was present at the location
  ], ...;
]

Changes since Release 4

Encounter
Encounter.class
  • Min Cardinality changed from 1 to 0
  • Max Cardinality changed from 1 to *
  • Type changed from Coding to CodeableConcept
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
Encounter.classHistory.class
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
  • Remove Binding http://terminology.hl7.org/ValueSet/v3-ActEncounterCode (extensible)
Encounter.serviceType
  • Max Cardinality changed from 1 to *
  • Type changed from CodeableConcept to CodeableReference
  • Type changed from CodeableConcept to CodeableReference
Encounter.subjectStatus
  • Added Element
Encounter.basedOn
  • Type Reference: Added Target Types CarePlan, DeviceRequest, MedicationRequest
  • Type Reference: Added Target Types CarePlan, DeviceRequest, MedicationRequest
Encounter.careTeam
  • Added Element
Encounter.participant.actor
  • Added Element
Encounter.virtualService
  • Added Element
Encounter.actualPeriod
  • Added Element
Encounter.plannedStartDate
  • Added Element
Encounter.plannedEndDate
  • Added Element
Encounter.reason
  • Added Element
Encounter.admission
  • Added Element
Encounter.admission.preAdmissionIdentifier
  • Added Element
Encounter.admission.origin
  • Added Element
Encounter.admission.admitSource
  • Added Element
Encounter.admission.reAdmission
  • Added Element
Encounter.admission.dietPreference
  • Added Element
Encounter.admission.specialCourtesy
  • Added Element
Encounter.admission.specialArrangement
  • Added Element
Encounter.admission.destination
  • Added Element
Encounter.admission.dischargeDisposition
  • Added Element
Encounter.location.form
  • Added Element
Encounter.participant.individual
  • deleted
Encounter.period
  • deleted
Encounter.reasonCode
  • deleted
Encounter.reasonReference
  • deleted
Encounter.hospitalization
  • deleted
Encounter.location.physicalType
  • deleted

See the Full Difference for further information

This analysis is available as XML or JSON.

See R3 <--> R4 Conversion Maps (status = 10 tests that all execute ok. All tests pass round-trip testing and 3 r3 resources are invalid (0 errors).)

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

PathDefinitionTypeReference
Encounter.status

Current state of the encounter.

RequiredEncounterStatus
Encounter.statusHistory.status

Current state of the encounter.

RequiredEncounterStatus
Encounter.class

This value set defines a set of codes that can be used to indicate the class of encounter: a specific code indicating class of service provided.

PreferredEncounterClass icon
Encounter.classHistory.class

This value set defines a set of codes that can be used to indicate the class of encounter: a specific code indicating class of service provided.

PreferredEncounterClass icon
Encounter.priority

A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.

Discussion: This attribute is used in orders to indicate the ordered priority, and in event documentation it indicates the actual priority used to perform the act. In definition mood it indicates the available priorities.

ExampleActPriority icon
Encounter.type

This example value set defines a set of codes that can be used to indicate the type of encounter: a specific code indicating type of service provided.

ExampleEncounterType
Encounter.serviceType

This value set defines an example set of codes of service-types.

ExampleServiceType
Encounter.subjectStatus

This example value set defines a set of codes that can be used to indicate the status of the subject within the encounter

ExampleEncounterSubjectStatus
Encounter.participant.type

This value set defines a set of codes that can be used to indicate how an individual participates in an encounter.

ExtensibleParticipantType
Encounter.reason

This examples value set defines the set of codes that can be used to indicate reasons for an encounter.

PreferredEncounterReasonCodes
Encounter.diagnosis.use

This value set defines a set of codes that can be used to express the role of a diagnosis on the Encounter or EpisodeOfCare record.

PreferredDiagnosisRole
Encounter.admission.admitSource

This value set defines a set of codes that can be used to indicate from where the patient came in.

PreferredAdmitSource
Encounter.admission.reAdmission

Value Set of codes which are used to specify that a patient is being re-admitted to a healthcare facility from which they were discharged, and indicates the circumstances around such re-admission.

ExampleHl7VSReAdmissionIndicator icon (a valid code from re-admissionIndicator icon)
Encounter.admission.dietPreference

This value set defines a set of codes that can be used to indicate dietary preferences or restrictions a patient may have.

ExampleDiet
Encounter.admission.specialCourtesy

This value set defines a set of codes that can be used to indicate special courtesies provided to the patient.

PreferredSpecialCourtesy
Encounter.admission.specialArrangement

This value set defines a set of codes that can be used to indicate the kinds of special arrangements in place for a patients visit.

PreferredSpecialArrangements
Encounter.admission.dischargeDisposition

This value set defines a set of codes that can be used to where the patient left the hospital.

ExampleDischargeDisposition
Encounter.location.status

The status of the location.

RequiredEncounterLocationStatus
Encounter.location.form

This example value set defines a set of codes that can be used to indicate the physical form of the Location.

ExampleLocationForm (a valid code from Location type icon)

UniqueKeyLevelLocationDescriptionExpression
img enc-1Rule Encounter.participantA type must be provided when no explicit actor is specifiedactor.exists() or type.exists()
img enc-2Rule Encounter.participantA type cannot be provided for a patient or group participantactor.exists(resolve() is Patient or resolve() is Group) implies type.exists().not()

  • 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 is required.

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.

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionExpressionIn Common
accountreferenceThe set of accounts that may be used for billing for this EncounterEncounter.account
(Account)
appointmentreferenceThe appointment that scheduled this encounterEncounter.appointment
(Appointment)
based-onreferenceThe ServiceRequest that initiated this encounterEncounter.basedOn
(CarePlan, MedicationRequest, DeviceRequest, ServiceRequest)
careteamreferenceCareteam allocated to participate in the encounterEncounter.careTeam
(CareTeam)
classtokenClassification of patient encounterEncounter.class
datedateA date within the actualPeriod the Encounter lastedEncounter.actualPeriod17 Resources
date-startdateThe actual start date of the EncounterEncounter.actualPeriod.start
diagnosisreferenceThe diagnosis or procedure relevant to the encounterEncounter.diagnosis.condition
(Condition, Procedure)
end-datedateThe actual end date of the EncounterEncounter.actualPeriod.end
episode-of-carereferenceEpisode(s) of care that this encounter should be recorded againstEncounter.episodeOfCare
(EpisodeOfCare)
identifiertokenIdentifier(s) by which this encounter is knownEncounter.identifier30 Resources
lengthquantityLength of encounter in daysEncounter.length
locationreferenceLocation the encounter takes placeEncounter.location.location
(Location)
location-perioddateTime period during which the patient was present at the locationEncounter.location.period
part-ofreferenceAnother Encounter this encounter is part ofEncounter.partOf
(Encounter)
participantreferencePersons involved in the encounter other than the patientEncounter.participant.actor
(Practitioner, Group, Device, Patient, HealthcareService, PractitionerRole, RelatedPerson)
participant-typetokenRole of participant in encounterEncounter.participant.type
patientreferenceThe patient present at the encounterEncounter.subject.where(resolve() is Patient)
(Patient)
33 Resources
practitionerreferencePersons involved in the encounter other than the patientEncounter.participant.actor.where(resolve() is Practitioner)
(Practitioner)
reason-codetokenReference to a concept (by class)Encounter.reason.concept
reason-referencereferenceReference to a resource (by instance)Encounter.reason.reference
service-providerreferenceThe organization (facility) responsible for this encounterEncounter.serviceProvider
(Organization)
special-arrangementtokenWheelchair, translator, stretcher, etc.Encounter.admission.specialArrangement
statustokenplanned | in-progress | on-hold | completed | cancelled | entered-in-error | unknownEncounter.status
subjectreferenceThe patient or group present at the encounterEncounter.subject
(Group, Patient)
subject-statustokenThe current status of the subject in relation to the EncounterEncounter.subjectStatus
typetokenSpecific type of encounterEncounter.type6 Resources