Encounter Profile¶

Canonical	`https://fhir.apps.health/StructureDefinition/nexus-emr-core-encounter`
Status	draft · 1.25.1
Base	Encounter (constraint)
Source	FSH · JSON

Defines the Encounter resource constraints for the Nexus EMR project (CII), conforming to CA-Core+ requirements.

Overview

The Nexus EMR Core Encounter profile represents a synthesized view of patient interactions in primary care EMR systems. Unlike hospital settings where encounters have clear admission/discharge boundaries, primary care "encounters" are typically artificial constructs assembled from various clinical activities that occurred on the same day.

Primary Care Reality

What Primary Care EMRs Actually Have

Primary care EMRs don't model discrete encounters the way FHIR expects. Instead, they organize clinical data around:

SOAP notes: Multiple notes per day for different issues, loosely timestamped
Appointment slots: Which may not match when the patient was actually seen (or may not exist for walk-ins)
Daily activity sheets: Everything that happened on a given day
Billing codes: The only reliably structured element with accurate timestamps
Scattered documents: Prescriptions, referrals, forms, lab reviews - all loosely associated with "today"

The Synthetic Encounter

In Nexus EMR, Encounter resources are synthesized within the MedPlum repository by a specialized bot that heuristically groups all encounter-related records created on the same day. This allows Nexus EMR to send hospital-style "Encounter" records to secondary use systems that expect them, even though primary care EMRs don't naturally organize data this way.

Appointment ↔ Encounter (added 1.12.0)

Encounter.appointment carries the link, and Encounter is the association anchor for the visit: clinical resources arising from it reference .encounter, not the Appointment. An Appointment is a booking (it can be cancelled or no-showed and never become an Encounter); an Encounter is the visit that happened. They are distinct resources with distinct lifecycles — an Encounter is not "a container around an Appointment".

In primary care the relationship is 1:1, and consumers may assume one appointment per encounter for primary-care data. That is expressed as a #warning invariant plus this prose, deliberately not as cardinality, because R4 legitimately permits both of the shapes a tighter cardinality would foreclose:

many Encounters per Appointment — a booked visit that splits into several encounters, routine in specialist and hospital workflows;
many Appointments per Encounter — one visit fulfilling several bookings (a combined or double-booked visit), which is why appointment is 0..*.

Zero is also valid: a walk-in has no appointment.

One asymmetry to plan around: R4 has no reverse element on Appointment. Going from an Appointment to its Encounter(s) requires a search on this element, not a dereference — and search support for that direction is not yet declared in a CapabilityStatement (see the scheduling capabilitystatement-deferral note).

Key Differences from Hospital Care

Temporal Dynamics:

Primary care thinks in weeks to months ("see me in 3 months")
Patients are in the office for 15-30 minutes, not days
No bed management or real-time coordination needs
Activities span the entire day, not confined to visit times

Documentation Patterns:

Multiple unrelated issues in one visit
Phone calls and refills between patients
Forms completed after hours
Lab reviews during lunch

Economic Drivers:

Fee-for-service or capitation models
Billing drives the only reliable structure
Empty rooms are lost opportunity, not ongoing cost

Terminology bindings

Path	Strength	Value set
`Encounter.status`	required	encounter-status
`Encounter.class`	required	v3-ActEncounterCode