Everyone in healthcare-AI is building the scribe. Almost nobody wants to hand-roll the clinical database underneath it. The Scribe Fire Starter gives you the whole transcript-to-signed-note lifecycle — provenance, audit, fresh reads, and FHIR export — so you build the product instead.
A scribe is a thin product over a hard backend: you need to capture a transcript, draft a note an AI wrote, let a clinician edit and sign it, track who-wrote-what for the chart, keep the patient's note list current the instant it's signed, and hand back clean FHIR on demand. That last 80% is where teams disappear for months. bonfireDB ships it as a starter app.
You set out to ship a scribe and end up operating a FHIR server: conditional-create races spawning duplicate Patients, lost-update PUTs wiping concurrent edits, a search index that silently rots, a second DB for draft state, and no provenance trail when the auditor asks who wrote the note.
Typed primitives for the scribe objects, AI-vs-clinician provenance baked into every draft, audit on every read and write, notesByPatient fresh the moment a note is signed, and a one-call DocumentReference export. Clone it, point it at your transcription model, ship.
Not snippets. The actual flow a real scribe needs, modeled as committed operational read models plus async indexing — so reads are fresh on commit and the heavy work never blocks the clinician.
A real note lifecycle: capture the transcript, generate a draft, let the clinician edit, then lock it on sign. Drafts and signed notes are distinct states, not a mutable blob.
App-native primitives →Every draft is stamped provenance:"ai". Clinician edits and the signature are attributed to the clinician. When the chart is questioned, you know exactly who wrote what.
Every read and write is patient- and tenant-scoped and logged automatically. You don't bolt on AuditEvents later — they're a property of the backend.
Clinical audit →The notesByPatient read model is fresh on commit. The instant a note is signed, the patient's note list reflects it — no eventual-consistency lag, no manual cache busting.
A signed note exports to a clean FHIR R4 DocumentReference on demand. Interop and portability are a method call, not a migration project.
FHIR underneath →The transcript is chunked and embedded asynchronously, so semantic search and agent context build in the background while the clinician keeps working.
Semantic search →Each step is a typed call that returns a freshness lifecycle — committed reads stay current, heavy indexing runs async and reports its status.
Stream the visit transcript in. Chunking and embedding kick off asynchronously — the clinician never waits on the index.
Your model generates a draft. bonfire stamps it provenance:"ai" so the AI-authored origin is recorded, not inferred.
The clinician edits the draft and signs. The signed note locks, attributed to the clinician — provenance now shows AI draft, human review, human signature.
On sign, notesByPatient and the patient timeline are fresh. Semantic search and agent context finish indexing in the background.
Call export and get a clean FHIR R4 DocumentReference for the signed note — ready for downstream interop.
Typed methods, a reactive query for the note list, and every write returning the freshness object so you always know what's fresh and what's still indexing.
// 1. Capture the transcript — chunk + embed run async const t = await clinical.transcripts.capture({ patientId, encounterId, audioText }) // returns { status:"committed", indexes:{ semanticSearch:"pending" } } // 2. Draft the note — stamped as AI-authored const draft = await clinical.notes.create({ patientId, encounterId, text: model.draftFrom(t), provenance: "ai" }) // 3. Clinician edits, then signs — signed note locks, attributed to clinician await clinical.notes.update({ noteId: draft.id, text: edited }) const signed = await clinical.notes.sign({ noteId: draft.id }) // 4. The patient's note list is fresh on sign — reactive, no refetch const notes = useClinicalQuery(api.notes.listByPatient, { patientId }) // signed.views.notesByPatient === "fresh" // 5. Export the signed note as clean FHIR R4 const bundle = await clinical.fhir.export(patientId) // -> DocumentReference
Canonical SDK style. Every write returns a freshness lifecycle, e.g. { status:"committed", views:{ notesByPatient:"fresh", timeline:"fresh" }, indexes:{ semanticSearch:"pending", agentContext:"pending" } } — committed reads are fresh immediately; heavy indexing reports its own status.
Everything the Fire Starter models out of the box — typed, scoped, audited, and FHIR-exportable.
provenance:"ai", editable until signed.// the signed note's provenance, ready for the auditor { draft: { by: "ai", at: "2026-06-16T14:02Z" }, edits: { by: "clinician", at: "2026-06-16T14:09Z" }, signed: { by: "clinician", at: "2026-06-16T14:11Z" } }
Fire Starters are bonfireDB's starter apps — complete, opinionated working examples of a real outpatient workflow, built on the primitives. Clone one, point it at your model and your AWS, and you start from a working backend instead of a blank schema. The Scribe Fire Starter is the canonical one because everyone builds the scribe first.
Go deeper on the build: the backend for an AI medical scribe breaks down the data layer the scribe sits on, and build an AI scribe in a weekend walks the transcript-to-signed-note flow start to finish.
bonfireDB is early-stage. Pages reflect product design and positioning. FHIR-native/FHIR-compatible is used descriptively; "FHIR®" is a registered trademark of HL7.
Clone the Scribe Fire Starter and ship the scribe — provenance, audit, fresh reads, and FHIR export already wired.
bonfireDB is designed as the app backend that generates FHIR underneath (not a FHIR server), so you don't hand-roll the clinical database under your scribe. The Scribe Fire Starter ships the whole transcript-to-signed-note lifecycle — provenance, audit, fresh reads, and FHIR export — as a clonable starter app. It's early access; you point it at your transcription model and ship the product.
bonfireDB models it as five typed states: capture the transcript, draft the note, clinician edits and signs, reads go fresh on commit, then export to FHIR. Drafts and signed notes are distinct states, not a mutable blob — the signed note locks on sign and is attributed to the clinician.
Every draft is stamped provenance:"ai", while clinician edits and the signature are attributed to the clinician. The signed note carries a provenance trail showing AI draft, human review, and human signature with timestamps — so when the chart is questioned you know exactly who wrote what.
Yes. A signed note exports to a clean FHIR R4 DocumentReference on demand with a single call. Interop and portability are a method call rather than a migration project. "FHIR®" is a registered trademark of HL7, used descriptively.
bonfireDB is designed to give you the clinical-data primitives a HIPAA-sensitive scribe needs — patient- and tenant-scoped reads and writes, audit on every operation, and an explicit provenance trail. Compliance also depends on your own infrastructure, BAAs, and policies; bonfireDB is early access and provides the data layer, not a certification.