The clinical data layer is the part that stops everyone.

Doing it right means FHIR correctness, ABAC, consent, audit, and a BAA. So that layer gets hand-rolled — a second database for app state, a cron to rebuild projections, a homegrown audit log, a compliance surface nobody on the team wanted to own. We take that weight off you.

Build a product on it and you inherit a federation protocol: referential integrity you enforce by hand, write semantics that assume strangers, search that’s a portability contract instead of a query language. You set out to ship a feature and end up operating a FHIR server. bonfireDB flips it — the record stays canonical FHIR R4 (stored lossless as JSONB), and you write typed clinical functions over the fast read models generated on top, like any backend.

On our benchmark, agents over raw FHIR failed for architectural reasons: they overflow on large charts, skip references, filter on display text instead of codes, and lose the temporal evidence the question asked for. In that test the prompt-side levers were null — the lever that moved accuracy lives in the data layer. We make the record legible: query-aware evidence packets, resolved references and codes, deterministic reducers, citations, and the part we’re building that no FHIR server or SQL-on-FHIR engine we reviewed ships — letting an agent read and aggregate the record while still respecting every patient’s compartment and consent, inside your boundary.

We don’t claim a moat we haven’t built — at this stage, our honesty is the product. We earn the trust one app, one agent, one audited read at a time, and we publish the benchmark so you never have to take our word for it.

See the roadmap →  ·  See the open benchmark →