Typed clinical primitives on Postgres, FHIR R4 generated underneath, and an agent layer that reads — and safely aggregates — the record. You build the app; ship a SMART-on-FHIR app, not a FHIR server.
Built for agents, not just dashboards.
A patient app and a clinician portal on the same bonfireDB — always in sync, by default.
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.
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.
Build your own MCP: a cited, permission-scoped projection — not a 3-million-token raw-FHIR dump.
FHIR R4 export, audit, provenance, and ABAC — automatic, underneath.
Become a design partner →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
// typed clinical primitives, fresh on commit const note = await clinical.notes.create({ patientId, text }) const notes = useClinicalQuery(api.notes.listByPatient, { patientId }) await clinical.fhir.export(patientId) // clean FHIR R4 Bundle
HAPI, HealthLake, and Medplum own the FHIR server. bonfireDB is the layer your app actually talks to — typed, fresh, and agent-ready.
Write clinical.notes.create(), not raw FHIR REST. Typed end to end.
Common reads update on commit. No eventual-consistency lag for your screens.
Learn more →pgvector over clinical text — ABAC-scoped and cited to the source record.
Learn more →Don't ship one canned MCP — ship the MCP compiler. Every function becomes a scoped tool.
Learn more →Patient/tenant-scoped by default. Every read audited, every write governed.
Learn more →FHIR R4 generated under your primitives. Export a clean Bundle on demand.
Learn more →Local-first writes that queue and sync on reconnect. Built for clinics with bad wifi.
Learn more →Forms, images, PDFs, scribe audio in your S3 — wired to FHIR, same ABAC & audit.
Learn more →Validate codes on write + code pickers for LOINC/SNOMED/RxNorm. No terminology server to run for everyday coded writes.
Learn more →Flat, fresh-on-commit views with row + column ABAC. Reports, BI, and ML in plain SQL — no Spark, no ETL.
Learn more →One command seeds coherent, longitudinal, profile-valid patients into local Postgres. Plus snapshot & reset.
Learn more →Runs in your AWS under your own BAA. Encryption, automatic audit, ABAC, no lock-in.
Learn more →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.
Metriport / Particle / Health Gorilla / Zus fetch and normalize the outside record from HIE networks. Point them at bonfireDB and keep building.
Typed primitives, fresh-on-commit reads, FHIR generated underneath, and the agent layer. Runs in your AWS, you own the data — the open alternative to AI-bolted-on EHR platforms.
The leading peer-reviewed benchmark (FHIR-AgentBench) found LLM agents over raw FHIR cap near 50% answer-correctness — an architecture ceiling, not a model one. bonfireDB's projection layer is built to break it, and we publish the eval, the method, and the harness so you can re-run it. Until it's measured, this is the ceiling we're attacking — not a number we claim.
We benchmark against the strongest baseline a competent team ships today — Medplum's MCP as shipped, same model, same token budget — and report the per-task breakdown, not a single vanity number.
// same model · same tasks · same real data raw FHIR alone (FHIR-AgentBench) → ~50% (published floor) bonfireDB agent layer → target, measured in the open // held-out · multi-model · reproducible
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.
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.
A peer-reviewed, unsolved ceiling. The fix is the data interface, not a bigger model — which is exactly the layer we build.
The vibe-coding wave made the front end trivial. The compliant clinical data layer is the one part that still stops people cold.
We're not trying to be HAPI, HealthLake, or Medplum. We're the app backend that generates FHIR underneath (not a FHIR server). See exactly how the pieces line up — including where each competitor genuinely wins.
Compare vs HealthLake, Medplum & HAPI → Why building on FHIR is hard
TicVision — a Tourette's symptom-tracking app — reimagined on bonfireDB. Four bespoke Dynamo tables and a hand-rolled HIPAA audit log become typed primitives with audit and FHIR export for free. (Our own illustrative rebuild.)
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 →
Scaffold into your own AWS · typed clinical primitives with FHIR R4 generated underneath · fresh-on-commit reads · clinical ABAC + automatic audit · semantic search · custom MCP builder · terminology validation · seed data · clean FHIR export, no lock-in. Designed in; rolling out through early access — see the roadmap for what is live vs building.
Projections + 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).
Agent-readable cohort analytics with ABAC-enforced aggregates and small-cell suppression — answering "how many of my patients…" under your BAA, 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 →
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.
Everyone builds the scribe. The data layer underneath — provenance, audit, fresh reads, FHIR export — is the hard 80%.
Read it →When generating FHIR underneath beats reaching for it on every screen — and where a full FHIR server still earns its place.
Read it →The resource graph, references, and codes — what FHIR is, in plain terms, before you decide how to build on it.
Read it →bonfireDB is in early access. Join the waitlist and we'll get you in.