FHIR infrastructureyou can actually own.
A self-hostable FHIR R4 foundation for teams building clinical products. Start with one node, keep the contract in your hands, and see exactly what the server supports before you depend on it.
Developer preview · Synthetic data only# Start with an observable foundation.
127.0.0.1:8090/healthz200 OK{
"status": "ok"
}Build the care product. Not the plumbing around it.
Healthcare teams keep rebuilding resource storage, search, version history, access control, audit, validation, files, and subscriptions. Ilavrita is putting those primitives behind one FHIR-native contract, in the open.
FHIR is the product contract.
Ilavrita owns the FHIR R4 surface: interactions, search semantics, validation behavior, versioning, authorization, and errors. The database does not define what your client sees.
Self-host without hiding the stack.
Run a compact Go server with SQLite today. Keep deployment simple while the architecture preserves a path to pluggable storage, distributed workers, and higher-throughput deployments.
Claims stop where the tests stop.
Capability discovery, known limitations, architecture decisions, and implementation docs are public. Ilavrita is designed to refuse unsupported behavior instead of quietly pretending it worked.
Clone it. Run it. Inspect the whole stack.
No hosted black box is required to get started. Run Ilavrita locally, inspect the API it actually serves, and use source-synced documentation to understand every implemented capability and known limit.
Read the quickstart# Get the source
git clone https://github.com/Ilavrita/Ilavrita.git
cd Ilavrita
# Fetch the pinned runtime and start
make bootstrap
make runInitial single-node architecture
One FHIR contract. Storage can change underneath.
FHIR behavior belongs to Ilavrita, not to its first database. Explicit storage boundaries keep the public API independent from the embedded runtime, so the platform can grow without asking clients to relearn it.
See the architecturePostgreSQL, project-aware partitioning, distributed queues and workers, horizontal scale, and broader interoperability sit later on the roadmap.
Useful already. Not finished. Clearly labeled.
Ilavrita already serves a substantial FHIR R4 surface and now has a tested SMART App Launch STU2.2 implementation covering authorization code, PKCE, refresh, backend services, browser FHIR CORS, OpenID Connect, and fhirUser behavior. The recorded Inferno run is a functional pass; three TLS checks remain because that run targeted a plaintext local HTTP server. Ilavrita remains a developer preview for synthetic data only.
126 declared R4 resource types, authenticated project-scoped access, search and version history, transaction and batch Bundles, conditional interactions, audit, validation, Binary handling, subscriptions, backup/restore, SMART authorization flows, backend services, and OpenID Connect.
Close GAP-013 by placing the controlled candidate behind proper HTTPS/TLS and rerunning Inferno so the remaining three TLS checks can be recorded cleanly. After that, the interoperability focus shifts toward ABDM / NRCeS profile conformance, broader terminology depth, and the remaining R4 protocol gaps.
Build on infrastructure you can read, run, and challenge.
Start with the source. Test the contract. Help turn a correct FHIR core into an open healthcare platform.