Build AI health apps on a clinical context layer.
An open-source clinical backend with canonical FHIR R4, conformance-tested projections, cited search, and governed agent proposals in the core today. The broader contract — patient-scoped context compilation, consent, and bounded traversal — is being built and tested in the open.
One backend.
Two surfaces.
A patient app and a clinician portal on the same bonfireDB — always in sync, by default.
No indexing delay.
The patient logs a tic and it's in the clinician's timeline instantly. A typical FHIR backend is still waiting on its search index.
Realtime, both directions.
The clinician adds a check-in; the patient app updates live. A doctor writing to their own patient is clinical authorization, enforced — not a hand-rolled check.
Agents read cited evidence.
Build your own MCP: a query-aware, permission-scoped evidence packet — not a 3-million-token raw-FHIR dump.
And you built none of it.
FHIR R4 export, audit, provenance, and ABAC — automatic, underneath.
Become a design partner →From zero to a clinical backend.
One command scaffolds a FHIR-safe backend with a typed SDK; deploy it into your own AWS. Early access — join the waitlist for access.
# the intended workflow — CLI in early access # scaffold + deploy into your own AWS → Postgres + pgvector · FHIR R4 · auth · MCP
// target early-access workflow — surfaces still rolling out const note = await clinical.notes.create({ patientId, text }) const notes = useClinicalQuery(api.notes.listByPatient, { patientId }) await clinical.fhir.export(patientId) // Bundle export · roadmap
An app backend, not another FHIR server.
HAPI, HealthLake, and Medplum own the FHIR server. bonfireDB is building the layer your app and agents talk to. The cards below distinguish what the open-source core implements today from the target early-access contract.
Target app-native primitives
The target is clinical.notes.create() instead of raw FHIR REST, typed end to end.
Projected reads
Core: an atomic projected-write path. Unifying every governed write behind it is in progress.
Learn more →Cited hybrid search
Core: Postgres full-text + a development vector signal. Production semantic embeddings are planned.
Learn more →Agent context tools
Core: search, cited context, and propose-only writes. The query-aware compiler is the target contract.
Learn more →Clinical authz & audit
Core: practice, resource-type, purpose, RLS, and governed writes. Patient/consent scope is next.
Learn more →FHIR underneath
Core: canonical FHIR R4 with immutable history. Clean Bundle export is on the roadmap.
Learn more → RoadmapOffline & sync
Local-first writes that queue and sync on reconnect — designed for clinics with bad wifi.
Learn more → RoadmapFile & attachment storage
Designed to keep forms, images, PDFs and scribe audio in your S3 — wired to FHIR, same ABAC & audit.
Learn more →Terminology & validation
Validate codes on write + code pickers for LOINC, RxNorm & ICD-10 (SNOMED CT with your own UMLS license). No terminology server to run for everyday coded writes.
Learn more →SQL-on-FHIR analytics
Core: conformance-tested flat projections in Postgres. Patient and column ABAC remain target work.
Learn more →Clinically-dense seed data
One command seeds coherent, longitudinal, profile-valid patients into local Postgres. Plus snapshot & reset.
Learn more →Security & HIPAA
Core: practice-scoped RLS/ABAC and hash-chained receipts. Patient/consent scope and every-surface AuditEvent coverage are target work.
Learn more →The backend you build on — not the pipe that fetches records.
Health-data APIs (Metriport, Particle, Health Gorilla, Zus) pull a patient's outside records in from the networks. That's a different layer, and a complement. bonfireDB is where your app's data lives, where you build, and where your agents read it safely — the open alternative to closed, AI-bolted-on platforms.
The aggregation layer — complement
Metriport / Particle / Health Gorilla / Zus fetch and normalize the outside record from HIE networks. Point them at bonfireDB and keep building.
bonfireDB — the app backend
Canonical FHIR R4, projections, practice-scoped policy, cited context, and governed proposals in the core. The complete typed programming model and patient-scoped context compiler are being built in the open.
The useful layer sits between the chart and the model.
A separate MIMIC-IV-on-FHIR research program now supports three bounded mechanisms. Select records for the question: A6a beat frozen blunt projection twice. Translate the chart’s own vocabulary: QT-4 moved its registered microbiology stratum from 10/44 to 25/44. Traverse only when the task needs a path: A11 recovered terminal evidence on 96/96 answerable constructed cases.
The nulls are just as public. QT-4 did not promote traversal on its mostly star-shaped benchmark, three simpler packet additions changed nothing, the join tests remain exploratory, and A11b forced a redesign instead of a promotion. This points toward a selective context compiler. It does not validate Bonfire, graph storage, or generality across models and servers.
The full program: 15 experiments — 4 measured · 1 bounded · 3 exploratory · 2 null · 1 withdrawn · 4 open
Browse all 15 experiments → Watch the failure happen, node by node → Browse all the research →
EXPLORATORY FOLLOW-UP · THE 176 QUESTIONS THAT NAME A VISIT
Two exploratory join tests on the same charts. They show a promising subset signal and an unresolved driver comparison.
No difference was detected between the last two, but equivalence was not established (p=.41; 95% interval −8.7 to +17.6 points). The agent used 4.061× the cumulative input tokens. Historical grading sensitivity remains open.
What these results do—and do not—show
We are building a separate Bonfire product benchmark with synthetic Synthea data, deterministic state grading, and a zero-leak security gate. It has not produced a product result. The research below tests mechanisms on other benchmarks: selection, vocabulary, traversal, joins, grading, and failure handling. We publish the nulls and broken tests beside the wins.
// planned Bonfire product benchmark · not yet run synthetic Synthea → deterministic state grading cross-tenant leak rate → must be 0 // secondary · MIMIC-IV-on-FHIR · credentialed users raw FHIR dump → 25.4% pooled blunt projection → 39.4% measured code sandbox → 65.3% selection proxy initial A6a vs frozen A0′ → 54.3% vs 44.7% · +9.5pp repaired A6a replication → 54.5% vs 46.2% · +8.3pp accepted-attempt model tokens → 35.5% fewer QT-4 holdout vocabulary (micro n=44) → 56.8% vs 22.7% · +34.1pp · p=.000275 QT-4 holdout traversal vs vocabulary → 65.9% vs 56.8% · +9.1pp · p=.219 · not promoted QT-1 pinned references → +0.24pp · null · not promoted QT-2 aggregate summaries → −0.24pp · null · not promoted QT-3 endpoint reserve → 0.0pp · null · not promoted A11 path-required traversal (n=120) → 119/120 vs 24/120 · bounded support A11 event grouping beyond traversal → +0.83pp · not promoted A11b causal isolation → normalized tie · task flaw found · redesigning pre-join · visit questions (n=176) → exploratory +6.8pp · sensitivity pending pre-join · pooled (409) → +2.0pp · unresolved agent + join tools (n=176) → +4.0pp · unresolved · 4.061× cumulative input graph storage → not tested
The agents arrived before the data was ready for them.
Three things just became true at once — and together they're why a clinical backend has to be agent-native from the inside, not patched on later.
MCP went standard
Agent-to-data is a Linux Foundation standard as of Dec 2025. Every healthcare app is about to grow an agent — and point it at the chart.
Raw FHIR is a poor default agent interface
On one FHIR benchmark and context cap, question-aware selection beat a frozen blind projection twice, while several extra-structure variants were null. Models may improve; the evidence interface is the lever the application layer controls.
Anyone can build the UI
AI-assisted building made the front end trivial. The compliant clinical data layer is the one part that still stops people cold.
Where it fits — honestly.
We're not trying to be HAPI, HealthLake, or Medplum. We're the app backend above your canonical FHIR R4, not a FHIR server. See how the pieces line up, including where each competitor is stronger.
Compare vs HealthLake, Medplum & HAPI → Why building on FHIR is hard
Reimagining a DynamoDB app on a FHIR-safe backend.
TicVision — a Tourette's symptom-tracking app — reimagined on the target Bonfire contract. Four custom Dynamo tables and a hand-built HIPAA audit log become typed primitives with governed audit and Bundle export. This is an illustrative future rebuild, not a shipped migration.
Where we're going — and what's real today.
We build in the open and mark shipped vs planned honestly — a backend you trust starts with a roadmap you can trust. See the full roadmap →
The FHIR-safe backend
Built in the core (Apache-2.0 planned, pre-release): canonical FHIR R4 + immutable history, SQL-on-FHIR projections, practice-scoped RLS/ABAC, cited search and context packets, and propose → approve → commit governance. Patient/consent scope, unified write-path freshness, production semantic retrieval, Bundle export, and the complete HTTP/context-compiler surface are still building.
The agent-readability layer
Evidence packets + reference/code/temporal resolution that take an agent from raw FHIR to clean clinical context — plus an open, reproducible benchmark for it, and propose-not-commit agent writes (the agent drafts, the clinician commits).
Agents that aggregate, safely
Agent-readable cohort analytics with ABAC-enforced aggregates and small-cell suppression — answering "how many of my patients…" inside your boundary, without an ETL pipeline. App-scale, never cross-org.
The bet: become the agent-native clinical backend the next generation of AI-native health apps are built and run on. Read the vision →
Read before you build.
How to think about the clinical data layer under an AI-native health app — the scribe wedge, building on FHIR, and what FHIR actually is.
The backend for an AI medical scribe
Everyone builds the scribe. The context layer underneath — provenance, audit, freshness, and interoperable export — is the hard part Bonfire is working toward.
Read it →Why build on FHIR (and when not to)
When keeping FHIR canonical underneath beats reaching for it on every screen — and where a full FHIR server still earns its place.
Read it →FHIR explained for app developers
The resource graph, references, and codes — what FHIR is, in plain terms, before you decide how to build on it.
Read it →You build the app. Bonfire is the clinical data layer underneath.
bonfireDB is in early access. Join the waitlist and we'll get you in.
✓ You're on the list.
We'll email you the moment your early-access slot opens. While you wait: