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.

Identifier(s) by which this encounter is known.

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

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.

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

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

The time that the episode was in the specified status.

inpatient | outpatient | ambulatory | emergency +.

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

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

Indicates the urgency of the encounter.

The patient present at the encounter.

While the encounter is always about the patient, the patient may not actually be known in all contexts of use.

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

The referral request this encounter satisfies (incoming referral).

The list of people responsible for providing the service.

Role of participant in encounter.

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

The period of time that the specified participant was present during the encounter. These can overlap or be sub-sets of the overall encounters period.

Persons involved in the encounter other than the patient.

The appointment that scheduled this encounter.

The start and end time of the encounter.

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

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

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

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

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

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.

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

Details about the admission to a healthcare service.

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

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

Pre-admission identifier.

The location from which the patient came before admission.

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

The admitting diagnosis field is used to record the diagnosis codes as reported by admitting practitioner. This could be different or in addition to the conditions reported as reason-condition(s) for the encounter.

Whether this hospitalization is a readmission and why if known.

Diet preferences reported by the patient.

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.

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

Special courtesies (VIP, board member).

Wheelchair, translator, stretcher, etc.

Location to which the patient is discharged.

Category or kind of location after discharge.

The final diagnosis given a patient before release from the hospital after all testing, surgery, and workup are complete.

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

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

The location where the encounter takes place.

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

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.

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

An organization that is in charge of maintaining the information of this Encounter (e.g. who maintains the report or the master service catalog item, etc.). This MAY be the same as the organization on the Patient record, however it could be different. This MAY not be not the Service Delivery Location's Organization.

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