Skip to content

CapabilityStatement — the Schedule/Slot deferral, and how it resolved

RESOLVED. The IG-wide CapabilityStatement this page waited for now exists: nexus-emr-server declares every exposed resource type and its interactions, Schedule and Slot among them.

One condition of the original decision is not yet met: nexus-emr-server declares interactions but not general search parameters, because that surface varies by backing store and has not been measured against each one. So the Schedule and Slot search parameters listed below remain a narrative contract, not a declared one. What would settle it: a per-backend conformance run over these parameters, published into the searchParam block.

The rest of this page is kept as the record of the original decision and as the current search-parameter contract for the booking-UI and Oscar teams.

Scope decision: Phase 1 does NOT bootstrap a CapabilityStatement covering only NexusEmrCoreSchedule + NexusEmrCoreSlot. This work is deferred until a broader IG-wide CapabilityStatement effort is scoped.

Why

At the time, the Nexus EMR FHIR IG published 29 StructureDefinitions across 17+ resource types (Patient, Practitioner, Encounter, Observation, Condition, Appointment, etc.) with no CapabilityStatement at all — none of the 29 profiles were surfaced via a /metadata discovery contract.

Bootstrapping a CapabilityStatement that covers only the 2 new scheduling profiles would create three problems:

  1. Inconsistency — consumers calling /metadata would see Schedule + Slot listed but not the 29 other profiles they actually use. The CapabilityStatement implies completeness; a partial one misleads.
  2. Maintenance burden — every new profile or search-param addition would need to remember to update the partial CS, with no enforcement mechanism.
  3. Scope creep at the wrong time — the right scope is an IG-wide CapabilityStatement effort that covers all profiles + their conformance interactions, not a Schedule/Slot-shaped subset.

What this means in practice

  • Phase 1 ships without a CapabilityStatement. Schedule and Slot are discoverable via /StructureDefinition URLs and via the published IG site (artifacts.html), the same as every other Nexus EMR profile today.
  • The Oscar-side HAPI server registers Schedule and Slot ResourceProviders with base FHIR search parameter support — clients can perform Schedule?actor=... and Slot?schedule=...&status=...&start=... without an IG-level CS.
  • The converter migration spec in converter-contracts.md describes the search-param expectations narratively. That's the binding contract for the Oscar team until an IG-wide CapabilityStatement exists.

Search parameters Schedule + Slot rely on (all base FHIR R4)

Documented here for the booking-UI and Oscar teams; not yet enforced by a CS.

Schedule:

  • actor — Reference search (PractitionerRole, Location, HealthcareService)
  • active — token
  • date — date (planningHorizon overlap)
  • service-category — token
  • service-type — token
  • identifier — token

Slot:

  • schedule — Reference search
  • status — token
  • start — date (range search supported via geXXX / leXXX prefixes)
  • slot-type — token (corresponds to FHIR R4 Slot.appointmentType)
  • service-category — token
  • service-type — token
  • appointment-type — token
  • specialty — token
  • identifier — token

None of these are custom — all are base FHIR R4 SearchParameters. A booking client can use them today against any conformant HAPI server.

Custom SearchParameter — explicitly deferred

A composite slot-window SearchParameter (find all slots overlapping [start, end)) was considered. Deferred until a booking client confirms need. The above base params support a start=geXXX&start=leXXX workaround that returns slots starting in the range — close enough for the booking-UI MVP.

Follow-up

Schedule and Slot are now listed in nexus-emr-server alongside every other exposed profile, both read-only (the IG declares no create, update or delete on either). Their search parameters are still undeclared there, so this doc + converter-contracts.md remain the search-param contract until the per-backend conformance run lands.