Model FHIR in typed Rust — five releases, R2 through R6 — and store it in a SQL database as real relational tables — typed columns, child tables, foreign keys, check constraints — not JSON blobs. Get it back losslessly.
Start the tutorial Run the examples
Pre-release. Each database port is described at its own conformance level. The conformance matrix is the status document to trust, and the audit findings list every known divergence, with evidence.
What is here
A data model, six storage libraries, a shared persistence core, and an HTTP surface — deliberately separate, composing in one direction.
The complete HL7 FHIR data model as Rust types — five releases (R2–R6) as separate crates, generated from the official specification, with validation, builders, choice enums, an XML bridge, a REST client, and cross-release conversion with a loss report.
Six FHIR-to-relational libraries — PostgreSQL, SQLite, MySQL, MariaDB, SQL Server, Oracle — one specification, one shared pure-Rust core, identical across all six and gated in CI. Schemas are generated from the FHIR specification packages.
The engine-agnostic half of persistence, shared by every port: the tamper-evident audit chain (SHA-256 + SHA3-256, optional HMAC), attribution, and the result types. No driver, no socket, no HTTP.
A FHIR RESTful API — Rust, Loco, Axum — mounted over a store. CRUD, vread, history, search, CapabilityStatement, PASETO authentication. The split is the point: storage guarantees live in the libraries, HTTP lives here.
The databases
Conformance levels, not feature lists: what has been verified for that port.
| Port | Database | Status |
|---|---|---|
fhir-postgresql | PostgreSQL 18 | Reference full store, full test suite |
fhir-sqlite | SQLite 3 | Store native, embeddable, no server |
fhir-mysql | MySQL 8.4 | Store |
fhir-mariadb | MariaDB 11.4 | Store |
fhir-mssql | SQL Server | Store live-verified; a standing TLS advisory risk (F-67) |
fhir-oracle | Oracle Database | Store live-verified; no upgrade path yet, snapshot reads open |
The levels are defined in Conformance, and broken down requirement by requirement in the conformance matrix — read that before choosing one.
Learn it
The specification decides what must be true; these explain how it works.
Run it
Complete programs from the model crate — each one a tutorial in its header comment.
Run one from a checkout with cargo run --example <name> — see the examples index.
Implement or audit it
Four families, four bodies of requirements. Requirement ids are permanent.
The specification root says which spec governs which code and how the requirement-id namespaces relate. Non-normative companions: conformance matrix · audit findings · locale and accent folding · publishing readiness. The server specification covers the HTTP surface.
Use it
The model family is published; the database ports are pre-release.
The model is fhir = "3" — five releases behind cargo features, r5 on
by default. The database ports and the server are pre-release in the fhir-rust repository, each at the conformance level the matrix
states.
