SMART functional conformance passes. Inferno is green functionally; HTTPS/TLS closure is the remaining SMART gate. View the roadmap
Ilavrita
GitHubRun locally
ROADMAP · SOURCE-SYNCED

Make FHIR dependable.
Then make it scale.

The order is intentional. Ilavrita first has to behave predictably as a FHIR R4 server. Then it can add the identity, tooling, automation, storage, and interoperability layers that turn a correct core into a broader healthcare platform. This is sequencing, not a promise of dates.

Read the implementation roadmap
01
In development

Prove the FHIR R4 core

A large part of the core already works. External SMART App Launch STU2.2 testing now functionally passes; the immediate closure item is rerunning the controlled candidate behind HTTPS so the three TLS checks can be satisfied. The broader job remains to close remaining R4 and profile gaps and keep supported versus unsupported behavior explicit.

  • Close GAP-013 by running the controlled candidate behind proper HTTPS/TLS and recording a clean Inferno SMART App Launch STU2.2 run; the current functional suite passes and only three TLS checks remain
  • Build the profile and terminology depth needed for India-facing ABDM / NRCeS conformance instead of making US Core the product baseline
  • Finish remaining R4 gaps, including number/quantity/URI search, type/system history, Patch, XML/format handling, upgrade/rollback procedures, and release packaging
02
Partially implemented

Turn the core into a developer platform

Projects, memberships, policy-based authorization, service accounts, TOTP, subscriptions, OAuth/SMART flows, backend services authorization, and OpenID Connect now exist. This phase continues with broader identity-provider integration, administration, developer tooling, and operational surfaces around those primitives.

  • Extend the implemented OAuth 2.0, SMART App Launch STU2.2 and OpenID Connect foundation with external identity providers, token exchange, and stronger administrator controls
  • Project settings, secrets, quotas, feature flags, linked-project rules, and operational tooling
  • TypeScript SDK and CLI, richer terminology and validation, GraphQL, Bulk Data, async jobs, import/export, and broader search behavior
03
Planned

Give product teams more than an API

Once the server and control plane are dependable, Ilavrita can absorb more of the repeated work around healthcare applications, without forcing every product team to rebuild the same operational and clinical primitives.

  • Administrator and developer console, resource explorer, project administration, and user administration
  • Bots, functions, cron and event automation, webhooks, WebSocket, email, and messaging workflows
  • Questionnaires and forms, reusable clinical UI, scheduling, intake, charting, diagnostic and medication workflows, care coordination, billing primitives, and reference application shells
04
Planned

Scale the platform without changing the contract

Scale comes after correctness. The storage and execution boundaries are designed so larger deployments can change how work is stored and coordinated without changing what a FHIR client sees.

  • Pluggable database backends, PostgreSQL and cluster storage, project-aware partitioning, higher-throughput persistence, and migration paths
  • Redis-backed coordination where it earns its place, durable queues, distributed workers and jobs, horizontal API scale, high availability, and enterprise operations
  • HL7v2, DICOM/DICOMweb, FHIRcast, on-premises agent and gateway patterns, warehouse/analytics integrations, and additional assurance packages

Roadmap for direction. Docs for truth.

The repository owns implementation detail and the website syncs it automatically. Use this roadmap to understand where Ilavrita is going; use the source-synced docs and the running CapabilityStatement to understand exactly where it is today.

Open the live roadmap docs