Roadmap

Phases come from PRD v2.0. Nothing here is a delivery date; it is an ordering, and the order matters more than the dates.

The guiding rule is that correctness comes before breadth. A small number of interactions that behave exactly as FHIR specifies is worth more than a large number that mostly work.

v2.0 defines the whole platform rather than only the first server release. The capabilities below therefore belong to one product definition and must share a single security and Project model, even though they ship in phases.

Done — foundations

• Monorepo, build, and the pinned embedded-runtime fork
• Architecture boundaries expressed as interfaces
• Operational endpoints and an honest CapabilityStatement
• embedded-runtime's own API and admin console disabled by default (FR-029)
• OpenAPI description checked against the running server
• Open-source project setup and release pipeline

Phase 1 — FHIR core / v0.1

• Resource create, read, update, delete
• Immutable version history and versioned read
• Optimistic concurrency through ETag and If-Match
• Search parser and SearchParameter registry
• Paginated searchset and history Bundles
• OperationOutcome on every FHIR failure path
• Project isolation enforced in the query layer
• Authentication, authorization and an audit trail
• Typed search indexes — string, token, reference and date are in; number, quantity and URI are not
• Binary and DocumentReference payloads — Binary is in, over local disk, with the bytes made durable before the row that names them commits. DocumentReference refuses inlined bytes and sends a client to Binary. The S3-compatible store is not in
• Custom search parameters — a Project stores a SearchParameter and searches by it, with no restart and no operator step. Only what this build can actually apply: token, string, reference and date, over an expression naming one element. Anything else is refused rather than stored and silently unanswered
• Reindexing — a definition enqueues the types it names, and a claimed worker outside every request walks them, so a parameter is true of what was already stored. An operator-triggered reindex of a type nobody redefined is not in
• Backup and restore — ilavrita backup, verify-backup and restore, with the database snapshot and the payloads taken in an order that makes the archive consistent
• Upgrade and rollback procedures — the schema is prepared at startup, including rebuilding a table to adopt a constraint, and every migration, seed and backfill is idempotent and recorded in super_jobs against the table it acted on. Rolling an install back to an earlier release is not written down
• Bundle transaction — every entry happens or none does, entries decided and audited one at a time, and urn:uuid: references resolved across them before anything is written
• Bundle batch — every entry settles on its own inside a savepoint, and the response describes each one including the ones that failed
• Conditional create, update and delete, and conditional references inside a transaction — a search names the target, run under a grant for searching that type
• Conditional read — If-None-Match and If-Modified-Since answer 304
• Prefer: return=minimal|representation|OperationOutcome
• Type-level and system-level history — a version's sequence is per resource, so a type's feed needs last_updated ordering and a compound cursor rather than a wider query
• Patch — JSON Patch, FHIRPath Patch and XML Patch
• XML, and _format beyond JSON — R4 says a server SHOULD serve both wire formats and this one serves JSON
• Validation and $validate — every resource is checked against its own R4 base definition, on the operation and on every write alike, including all 203 of R4's required FHIRPath invariants
• Declared profiles — meta.profile is resolved and a held profile's resource-level rules applied; one this server does not hold is reported rather than passed. A profile's narrowed cardinality and slicing are not applied
• Reference integrity — $validate reports a relative reference that leads nowhere, under a read grant for the type it names. Writes do not refuse one, because R4 permits it and provisioning a compartment depends on it
• Terminology for required bindings — a code is checked against the value set its element is bound to, from the specification's own bundled sets
• Bringing an install into use — one claim token, handed over through the data directory and spent once, which is what an external tool needs before it can authenticate at all
• SMART App Launch and an OAuth2 authorization server, with .well-known/smart-configuration beside it. How a SMART scope becomes a storage.Scope is specified in docs/design/smart-scope-spec.md; the endpoints are ordinary once that is settled and unsafe before it is
• ABDM profiles (NRCeS) — 38 core profiles and 42 value sets, which needs profile application beyond the root invariants this build checks today, and the terminology directory back for SNOMED CT India and LOINC
• Single binary and container image

Conditional interactions are now the one that matters most. Several resources can be written as one act, and each is checked against its own definition and required bindings — so what this server keeps is a record a client can rely on. What it cannot yet do is let a client say write this only if it is not already here, which is how an ingestion pipeline stays idempotent and how a transaction entry names a resource by identifier rather than by id.

Phase 2 — control plane and developer platform

Projects as first-class isolation boundaries; ProjectMembership and profile-backed identity; Project Admin, Super Project and Super Admin controls; AccessPolicy and parameterized authorization; client applications and service accounts; project settings, secrets, quotas, feature flags and linked-project rules; OAuth and OIDC, SMART App Launch, MFA, external identity providers and token exchange; the TypeScript SDK, a CLI, GraphQL, subscriptions, terminology, implementation-guide packages, a stronger $validate, Bulk Data, async jobs, import and export, and expanded search behaviour.

Several of these arrived early because Phase 1 needed them: Projects and memberships, AccessPolicy with parameterized authorization, client applications and service accounts, a TOTP second factor, and rest-hook and websocket subscriptions. What remains in this phase is the rest of the control-plane surface, OAuth and OIDC, external identity providers, and the developer tooling.

Phase 3 — automation and application platform

Administrator and developer console, resource explorer, user and project administration, Bots and functions, cron and event automation, webhook, WebSocket, email and message subscriptions, Questionnaire and form tooling, reusable React clinical components, scheduling, intake, charting, diagnostic orders, medication workflows, care coordination, messaging, billing primitives, patient matching, and reference application shells.

Phase 4 — enterprise, interoperability and analytics

PostgreSQL and cluster storage, horizontal API scale, distributed workers and jobs, server-scoped subscriptions and system operations, enterprise operational controls, an on-premises Agent and gateway, HL7v2, DICOM and DICOMweb, FHIRcast, open-table warehouse synchronisation and analytics integrations, high-availability deployment patterns, and additional assurance packages.

Explicit non-goals for Phase 1

FHIR R5, a complete terminology server, production SMART or Bulk Data, FHIRcast, GraphQL, a workflow or serverless runtime, a no-code builder, multi-node high availability, PostgreSQL as the primary backend, HL7v2, DICOM, and any certification claim.

These are not rejected ideas. Most of them are Phase 2 to 4 above. They are deliberately after a correct core.