What's the fundamental difference between Encounter and Appointment?

Appointment represents a scheduled interaction, whether future or past, while Encounter represents the actual clinical interaction itself, meaning a single Appointment might result in one Encounter, no Encounter, or in rare cases multiple related Encounters.

Does every completed Appointment need a corresponding Encounter resource?

Not automatically — the relationship between the two often needs to be explicitly implemented, since an Appointment reaching fulfilled status doesn't inherently trigger Encounter creation without specific integration logic built for that purpose.

How should no-show appointments be handled in FHIR?

Mark the Appointment status as noshow, and typically no corresponding Encounter resource should be created, since no actual clinical interaction took place that would warrant representing it as a completed encounter.

Can an Encounter exist without a prior Appointment resource?

Yes, particularly for unscheduled visits like emergency department encounters, where a patient arrives without a prior scheduled appointment, meaning Encounter can exist independently without always being preceded by an Appointment resource.

How do hospitalization details differ from general Encounter fields?

The hospitalization element captures inpatient-specific details like admission source and discharge disposition, which only apply meaningfully to inpatient encounters and wouldn't be populated for a routine outpatient visit encounter.

FHIR Encounter and Appointment Resources Explained

Q: What does the class field on Encounter actually indicate?

Class indicates the general category of encounter, such as inpatient, outpatient, or emergency, giving downstream systems immediate context about the setting and nature of that particular patient interaction with the healthcare system.

TL;DR

Appointment represents a scheduled interaction (status: booked, arrived, fulfilled, cancelled, noshow), while Encounter represents the actual clinical interaction itself once underway (status: planned, arrived, in-progress, finished). Encounter's class field distinguishes inpatient/outpatient/emergency, participant lists who was involved, and hospitalization captures admission/discharge details for inpatient stays. An Appointment reaching fulfilled doesn't automatically create an Encounter — that relationship usually needs to be explicitly built — and no-shows or cancellations typically shouldn't produce an Encounter at all. An Encounter can also exist with no prior Appointment, as with unscheduled ED visits.

Quick answer

FHIR's Encounter and Appointment resources cover related but distinct concepts that integrators frequently conflate: Appointment represents a scheduled future or past interaction, while Encounter represents the actual interaction itself once it's genuinely underway or completed, and understanding that distinction matters for building correct workflow logic. Encounter provides essential context for other resources like Observation and Condition, tying them to a specific visit, while Appointment drives scheduling workflows before that visit ever actually begins.

Below is what each resource actually contains, how their statuses and lifecycles differ, and how the two resources relate to each other in a complete workflow. If you're building scheduling or encounter-based logic, our free Mirth Health Check can review your specific implementation directly — part of the Mirth Connect support work we do for US healthcare teams.

What the Encounter Resource Actually Contains

Encounter captures the details of an actual patient interaction with the healthcare system, providing the contextual anchor that many other clinical resources reference directly.

Class Distinguishes Inpatient, Outpatient, and Emergency Visits

The class element indicates the general category of encounter, such as inpatient, outpatient, ambulatory, or emergency, giving downstream systems immediate context about the nature and setting of that specific patient interaction.

Participant Captures Who Was Involved

The participant element lists the practitioners and other individuals involved in the encounter, each with a role indicating their specific function, such as the attending physician or a consulting specialist.

Period Defines the Actual Encounter Timeframe

The period element captures the actual start and end time of the encounter, distinct from any originally scheduled appointment time, reflecting what genuinely happened rather than what was originally planned.

Hospitalization Details for Inpatient Encounters

For inpatient encounters specifically, the hospitalization element captures details like admission source, discharge disposition, and other information relevant specifically to an inpatient stay rather than an outpatient visit.

How Encounter and Appointment Statuses Differ

Both resources use a status field to track their lifecycle, but the specific status values and what they represent differ meaningfully between the two resource types given their different purposes.

Appointment Status Tracks the Scheduling Lifecycle

Appointment status values include booked, arrived, fulfilled, cancelled, and noshow, tracking the scheduling process from initial booking through to whether the patient actually attended the scheduled visit.

Encounter Status Tracks the Actual Visit Lifecycle

Encounter status values include planned, arrived, in-progress, and finished, tracking the actual clinical encounter itself once it has genuinely begun, distinct from the scheduling status tracked separately in Appointment.

An Appointment Doesn't Automatically Become an Encounter

A scheduled Appointment reaching its fulfilled status doesn't automatically generate a corresponding Encounter resource in every implementation, so integration logic often needs to explicitly create that Encounter once the visit genuinely begins.

Handling No-Shows and Cancellations Correctly

Appointment's noshow and cancelled statuses represent outcomes where no actual Encounter should exist, so integration logic needs clear rules distinguishing which Appointment statuses should and shouldn't trigger Encounter creation.

How Appointment Drives Scheduling Workflows

Appointment resources support the practical scheduling workflows that happen before, and sometimes independently of, whether an actual clinical encounter ever takes place.

ServiceType and AppointmentType Categorize the Visit

ServiceType and appointmentType elements categorize what kind of appointment is being scheduled, such as a routine checkup versus a follow-up visit, supporting scheduling logic that needs to differentiate between visit categories.

Start and End Define the Scheduled Window

The start and end elements define the scheduled time window for the appointment, which may differ from the actual encounter period if the visit runs longer or shorter than originally scheduled.

Participant Required Status Indicates Necessity

Each participant in an Appointment can be marked as required or optional, letting scheduling systems distinguish between a mandatory attendee, like the patient, and an optional one, like a translator who may or may not be needed.

Appointment Supports Both Patient and Provider-Initiated Scheduling

Appointment resources support scheduling workflows initiated either by patients through self-scheduling portals or by staff through internal scheduling systems, with the resource structure remaining consistent regardless of who initiated the booking.

When to call for help

If Appointment-to-Encounter transitions are producing gaps or duplicates, the cause is usually a missing or overly broad rule for which statuses should trigger creation. Our free Mirth Connect health check reviews your implementation as part of the standard diagnostic.

Book a Free Health Check →

Troubleshooting something specific? Send us the log, or check pricing for our support plans.

FHIR Encounter and Appointment Resources: Visits and Scheduling Explained