The whole clinical backend, as a programming model.
Not another FHIR server — the app backend, the way Convex and Supabase did it for everyone else.
The shipped core and the contract we are building.
Today the core provides canonical FHIR R4, immutable history, SQL-on-FHIR projections, practice-scoped policy, cited search/context, and governed proposals. Typed app functions, universal fresh-on-commit reads, production semantic retrieval, patient/consent scope, and Bundle export are target work.
App-native primitives
Target API: notes, assessments, observations, and tasks become typed clinical functions over clean views instead of raw FHIR.
Explore primitives →Projected reads
Core: an atomic projected-write path and a framework-free LISTEN/NOTIFY query store. Governed-route coverage, browser/React adapters, polling fallback, and unified freshness receipts are target work.
See freshness →Cited clinical search
Core: Postgres full-text search over dedicated search_doc rows, with citations to canonical records and a development vector signal. Production embeddings and hybrid ranking are planned.
Agent context tools
Core: three scoped tools for search, cited context, and propose-only writes. Compiling one definition into SDK, full HTTP, and agent surfaces is the target.
Build context tools →Clinical authorization & audit
Core: practice/resource/purpose policy, Postgres RLS, governed proposals, citations, and hash-chained receipts. Patient/consent scope and complete read audit are next.
Lock it down →FHIR underneath
Core: FHIR R4 is the canonical record; typed reads are projections over it. Clean Bundle export is on the roadmap.
Explore FHIR → RoadmapOffline & local-first sync
Clinics have bad wifi. Optimistic local writes are designed to queue and sync on reconnect — the freshness lifecycle extends to sync state.
Go offline → RoadmapFile & attachment storage
Scanned forms, images, PDFs, scribe audio — designed to live in your S3, wired to FHIR, with the same ABAC and audit as your data.
Store files → TargetTerminology & validation
Validate codes on write and power code-pickers across LOINC, RxNorm & ICD-10 (SNOMED CT with your own UMLS license) — “store a diagnosis” stops being a project.
Validate codes →SQL-on-FHIR analytics
Core: SQL-on-FHIR v2 ViewDefinitions project flat tables under practice-scoped RLS. Patient and column ABAC plus automatic governed refresh are target work.
Query the chart → TargetClinically-dense seed data
One command seeds coherent, longitudinal, profile-valid patients into local Postgres — plus per-test snapshot & reset. A realistic patient in 5 minutes.
Seed a clinic →Security & HIPAA
Core: practice-scoped RLS/ABAC and hash-chained receipts. Patient/consent scope and automatic every-surface AuditEvent coverage are target work.
See the trust model →Write a function. Get a freshness receipt.
The clinical verb API below is a target contract. The current core already has an atomic projected-write primitive and a framework-free useClinicalQuery store over Postgres LISTEN/NOTIFY; universal governed-route coverage, browser bindings, downstream status, and Bundle export remain target work.
// Target API — not shipped // Create a note — returns a freshness lifecycle object const result = await clinical.notes.create({ patientId, encounterId, text }) // { // status: "committed", // views: { notesByPatient: "fresh", timeline: "fresh" }, // indexes: { semanticSearch: "pending", agentContext: "pending" } // } // Read reactively — commit-ordered updates push to the client const notes = useClinicalQuery(api.notes.listByPatient, { patientId }) // Record an assessment -> QuestionnaireResponse + Observation clinical.assessments.record("PHQ-9", { patientId, answers }) // Permission-aware, cited agent context const ctx = await clinical.agent.sessionPrep({ patientId, windowDays: 90, include: ["recentNotes", "assessments", "tasks"] }) // Planned clean FHIR R4 Bundle export await clinical.fhir.export(patientId)
The current framework-free store listens for projection changes and performs an RLS-scoped re-query; it exposes subscribe and getSnapshot but is not a React hook. One governed write path, browser/React adapters, polling fallback, async index status, and Bundle export are still target work. Add infrastructure only when a measured hot path requires it.
Not just a FHIR server.
A FHIR server stores and exchanges records. bonfireDB’s current core adds projections, policy, citations, and governed proposals above canonical FHIR R4; the complete app programming model is the target.
- App-native clinical verb API (target)
- Atomic projected-write primitive
- Framework-free LISTEN/NOTIFY query store
- End-to-end typed clinical verbs (target)
- Postgres full-text + development vector signal
- Citations + hash-chained audit receipts
- Practice-scoped clinical policy
- Agent context tools
- FHIR-compatible Bundle export (target)
- Runs in your AWS
- Apache-2.0 planned (pre-release)
You build the app. Bonfire is the clinical data layer underneath.
Join early access to run the core in your own AWS and help shape the typed programming model, patient-scoped authorization, and governed context compiler.
Frequently asked questions
What does a TypeScript FHIR backend like bonfireDB give you?
The current core gives you canonical FHIR R4, immutable history, conformance-tested projections, practice-scoped policy, cited search/context, and governed proposals. A complete typed TypeScript programming model with freshness receipts and Bundle export is the target.
Is bonfireDB just another FHIR server?
No. A FHIR server stores and exchanges records; bonfireDB is building the governed app-and-agent context layer above canonical FHIR R4. The current core implements projections, policy, citations, and proposals; the broader app programming model is still rolling out.
How does bonfireDB do realtime without Redis?
The current framework-free useClinicalQuery store listens for Postgres projection notifications and re-queries one whitelisted view through tenant-scoped RLS. It is not a React hook; browser/React adapters, a polling fallback, universal governed-write coverage, and unified freshness receipts are target work.
Does bonfireDB support hybrid search and vector embeddings?
The current core searches dedicated search_doc rows with Postgres full-text search, cites canonical records, and includes a development vector signal. Production semantic embeddings, hybrid ranking, and freshness status are planned.
Is bonfireDB available to use today?
bonfireDB is in early access and pre-launch. You can join the waitlist to run the open-source core in your own AWS or have us host it under a BAA. Features described here reflect the design and programming model, not a finished product.