Skip to content

Schedule Profile

Canonical../StructureDefinition/nexus-emr-core-schedule
Statusdraft · 1.26.0
BaseSchedule (constraint)
CQL primary code pathserviceType — what this means
SourceFSH · JSON

Minimal Nexus EMR profile for Schedule resources, representing a clinic or provider's bookable calendar. Slots reference back to a Schedule via Slot.schedule. Phase 1 sources OscarPro provider templates (one Schedule per provider) but the profile supports room/equipment (Location) and service-line (HealthcareService) schedules as well.

Overview

Overview

The Nexus EMR Core Schedule profile represents a bookable calendar — typically a provider's recurring availability, but also rooms, equipment, or service lines. Schedules are the container that owns Slot resources; every NexusEmrCoreSlot must reference exactly one Schedule via Slot.schedule (FHIR R4 base requirement).

In Phase 1, schedules are sourced from OscarPro's scheduletemplate table (one row per provider-template combination) and materialised into FHIR by the Oscar-side converter. One Schedule resource is emitted per provider per planning horizon.

Key Features

  • Flexible actor model: One profile supports provider-owned (PractitionerRole), room/equipment (Location), and service-line (HealthcareService) schedules. At least one actor type must be present.
  • Nexus EMR ID + raw code identifiers: Same slicing pattern as every other Nexus EMR profile — one Nexus EMR-canonical ID plus optional source-system raw identifiers.
  • Planning horizon: Optional but RECOMMENDED — the rolling booking window the schedule supports (typically 90 days).
  • Coded services: serviceCategory and serviceType with both standard-terminology and raw-code coding slices.

Actor Cardinality

The actor element is sliced into three optional slices, with an invariant (schedule-actor-required) requiring at least one:

  • PractitionerRole 0..1 MS — provider whose calendar this is. Most common case.
  • Location 0..1 MS — for room or equipment schedules (e.g. exam room availability, MRI machine bookings).
  • HealthcareService 0..1 MS — for service-line schedules (e.g. walk-in clinic hours, telephone-triage availability) where no single provider owns the calendar.

Multiple slices may be present (e.g. provider + clinic Location), but at least one of the three must exist.

Relationship to Slot

A Schedule is the parent of one or more Slot resources. Booking workflows typically:

  1. GET Schedule?actor=PractitionerRole/<id>&active=true — discover available calendars
  2. GET Slot?schedule=Schedule/<id>&status=free&start=ge<date> — find free slots
  3. POST Appointment with .slot=[Slot/<id>] — book the slot

Slot.status transitions (free → busy-tentative → busy) are owned by the booking system, not the converter. See NexusEmrCoreSlot for details.

Alternatives Considered

FHIR R4 has multiple ways to model provider availability. Phase 1 chose Schedule + Slot for these reasons:

Model Why not chosen
PractitionerRole.availableTime / notAvailable Inline weekly-pattern strings; not queryable atomically. Useful for publishing hours, not for booking.
AppointmentResponse Not an alternative: it answers a different question. Schedule + Slot model availability; an appointment response records a participant's answer to a booking that already exists.
Bespoke extensions Reinvents FHIR-defined search semantics.

Schedule + Slot provides concrete, queryable, atomic-state windows — the natural match for a booking UI.

Correction: AppointmentResponse is not future scope

This page previously described AppointmentResponse as "tentative future scope if a formal confirmation step is needed". That was wrong. It is written into this estate today, and it is where a booking's confirmation state lives -- a consumer reading Appointment.status alone cannot tell a confirmed booking from an unanswered one. It is profiled as NexusAppointmentResponse, which describes the confirmation model in full.

Recurrence

FHIR R4 Schedule has no native recurrence element. OscarPro's recurring weekly templates are materialised into concrete daily Slot instances by the Oscar-side converter (one Slot per bookable time window per day). If a future booking UI needs to render "this slot repeats weekly," that requires an IG-level extension and is follow-up scope.

Phase 1 Source: OscarPro scheduletemplate

The Oscar-side converter (see migration spec in docs/guide/features/scheduling/converter-contracts.md) emits one Schedule per provider, deriving:

  • actor[PractitionerRole] from the template's provider_no
  • actor[Location] from the provider's primary clinic, if available
  • planningHorizon from the date range materialised at emission time
  • identifier as <provider_no> (or another deterministic per-provider value)

Schedules referencing rooms or service lines are not produced by the Oscar converter in Phase 1 but are supported by the profile for future converters and other source EMRs.