Skip to content

CapabilityStatement — Deferred to IG-wide Effort

FHIR-26 scope decision (2026-05-26): Phase 1 does NOT bootstrap a CapabilityStatement covering only PolarisCoreSchedule + PolarisCoreSlot. This work is deferred until a broader IG-wide CapabilityStatement effort is scoped.

Why

The Polaris FHIR IG currently publishes 29 StructureDefinitions across 17+ resource types (Patient, Practitioner, Encounter, Observation, Condition, Appointment, etc.). There is no existing CapabilityStatement in the repo — none of the 29 profiles are 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 Polaris 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

When an IG-wide CapabilityStatement effort gets scoped (separate ticket), Schedule and Slot get added alongside the other 29 profiles. Until then, this doc + converter-contracts.md are the search-param contract.