Short answer: an Encounter is one interaction between a patient and the health system: an outpatient visit, a hospital stay, an emergency attendance, a video consultation, a home visit. It records when (period), in what setting (class: ambulatory, inpatient, emergency, home health, virtual), its status (planned → in-progress → finished), who took part, why (reasonCode) and what was diagnosed (diagnosis, linking to Conditions). Observations, procedures, medication orders and documents point to the Encounter they belong to, which is how a record can be read visit by visit.
A valid FHIR R4 example
A valid FHIR R4 Encounter resource requires only status and class, but a useful one also carries subject, period, type, participants, a reason and the diagnoses it established. The example below is a finished ambulatory consultation for type 2 diabetes, with a primary performer, a chief-complaint diagnosis ranked first, a location and the responsible organisation.
{
"resourceType": "Encounter",
"id": "visit-2026-03-14",
"status": "finished",
"class": {"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "AMB", "display": "ambulatory"},
"type": [{"coding": [{"system": "http://snomed.info/sct", "code": "11429006", "display": "Consultation"}]}],
"serviceType": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/service-type", "code": "165", "display": "Diabetes Education"}]},
"subject": {"reference": "Patient/example"},
"participant": [{
"type": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "PPRF", "display": "primary performer"}]}],
"individual": {"reference": "Practitioner/gp-42"}
}],
"period": {"start": "2026-03-14T09:00:00+01:00", "end": "2026-03-14T09:25:00+01:00"},
"reasonCode": [{"coding": [{"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"}]}],
"diagnosis": [{
"condition": {"reference": "Condition/t2dm"},
"use": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/diagnosis-role", "code": "CC", "display": "Chief complaint"}]},
"rank": 1
}],
"location": [{"location": {"reference": "Location/clinic-3"}, "status": "completed"}],
"serviceProvider": {"reference": "Organization/hospital"}
}
Status: the lifecycle
A FHIR Encounter's status moves through planned, arrived, triaged, in-progress, onleave and finished, with cancelled, entered-in-error and unknown as the other exits. The statusHistory element keeps each earlier state with its period, so a hospital stay shows when the patient arrived, was admitted and left. An Encounter is the interaction itself, not the Appointment that booked it.
planned (booked, not yet started) → arrived → triaged (emergency departments) → in-progress → onleave (inpatient on temporary leave) → finished. cancelled and entered-in-error end it otherwise; unknown exists for imports. statusHistory keeps the earlier states with their periods, so a hospital stay shows when the patient arrived, when they were admitted and when they left. Note that an Encounter is not an Appointment: the Appointment is the booking; when the patient arrives, an Encounter is created that references it through appointment.
Class: the setting
The Encounter class comes from the HL7 v3 ActCode system: AMB ambulatory (outpatient), IMP inpatient, EMER emergency, HH home health, VR virtual (telehealth), ACUTE and NONAC for inpatient subtypes, OBSENC observation, PRENC pre-admission, SS short stay. classHistory records transfers, for example an emergency attendance that became an admission.
The other elements
Beyond status and class, a FHIR Encounter carries type and serviceType (what kind of visit and which service line), participant (clinicians with their roles and periods), reasonCode or reasonReference, diagnosis (linked Conditions with use and rank), hospitalization (admission and discharge details), location entries over time, length, serviceProvider and partOf for sub-encounters.
- type and serviceType say what kind of encounter and which service line (cardiology, diabetes education), with codes that vary by country.
- participant lists clinicians and others with a participation type (admitter, attender, primary performer, consultant, referrer) and the period each was involved.
- reasonCode / reasonReference give the reason for the visit; diagnosis links the Conditions established or addressed, with a
use(admission diagnosis AD, discharge diagnosis DD, chief complaint CC, comorbidity CM, billing) and arank. See FHIR Condition explained. - hospitalization carries admission details:
admitSource(GP referral, emergency, transfer),dischargeDisposition(home, another hospital, deceased),preAdmissionIdentifier, diet and special arrangements. - location lists the places with their status over time (planned, active, reserved, completed); a ward transfer adds a new entry.
- length is the duration; serviceProvider the organisation responsible; partOf links a sub-encounter (a ward stay) to the admission it belongs to.
What changed in R5
FHIR R5 renamed Encounter.hospitalization to admission, merged reasonCode and reasonReference into reason, made class a list of CodeableConcept (an encounter can carry several classifications), moved participant.individual to actor, and introduced EncounterHistory as a separate resource for status and class history. R4 remains the version in US Core and most national guides; see FHIR R4 vs R5.
Mapping from HL7 v2
HL7 v2 ADT messages map to FHIR Encounter by event type: A01 admit creates an inpatient Encounter in progress, A03 discharge finishes it with period.end and discharge disposition, A02 transfer adds a location entry, A04 registers an ambulatory Encounter and A08 updates it. Most of the data comes from the PV1 segment, whose visit number becomes Encounter.identifier.
An ADT^A01 (admit) creates an Encounter with class IMP and status in-progress; A03 (discharge) sets status finished and fills period.end and dischargeDisposition; A02 (transfer) adds a location entry; A04 (register outpatient) creates an AMB encounter; A08 updates it. PV1 carries most of the data (patient class in PV1-2, location in PV1-3, attending in PV1-7, visit number in PV1-19, which becomes Encounter.identifier). See HL7 v2 messages explained.
In Anpheros
Anpheros Platform creates FHIR Encounter resources in two ways: clinics write them through the API, and a person's own logged visit becomes a finished Encounter once the appointment has taken place. Results, documents and notes from that visit reference the Encounter, so the record can be read visit by visit by the person and by any clinic they share with.
Appointments booked in the app are Appointment resources until they happen.
Related pages
- FHIR Condition explained
- FHIR Patient resource explained
- HL7 v2 messages explained: ADT and ORU
- FHIR R4 vs R5
- FHIR DiagnosticReport explained
- Encounter example on the developer site
Sources
- HL7 FHIR R4: Encounter
- HL7 FHIR R5: Encounter
- HL7 Terminology: v3 ActCode (encounter class)
- HL7 Terminology: diagnosis-role code system
- HL7 US Core: Encounter profile
Frequently asked questions
What is the difference between Encounter and Appointment?
An Appointment is the booking of a future slot; an Encounter is the interaction that actually happened (or is happening). When the patient arrives, the Encounter is created and references the Appointment.
Is a hospital stay one Encounter or many?
Usually one Encounter for the admission, with location entries for each ward and classHistory for changes of setting. Some systems create sub-encounters per ward stay linked through partOf; national guides say which.
Where does the discharge summary go?
As a DocumentReference or a FHIR document whose Composition references the Encounter. The Encounter itself holds the discharge disposition and dates, not the narrative.
Does every Observation need an Encounter?
No. Observations the patient records at home, or that arrive from a wearable, have no Encounter. Those taken during a visit should reference it so the record can be read by visit.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
