Build an AI medical scribe, fast.
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.
The scribe is the easy part. The data layer isn’t.
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 packages it as a starter app (early access).
Hand-rolling it
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.
With the Fire Starter
Target contract: typed scribe primitives, AI-versus-clinician provenance on every draft, complete read-and-write audit coverage, notesByPatient refreshed when a note is signed, and one-call DocumentReference export. The starter app is early access; implemented operations produce audit receipts, while complete every-read coverage remains target work.
The full transcript → signed-note lifecycle.
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.
Transcript → draft → signed
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 →AI-vs-clinician provenance
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.
Audited by default
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 →Notes-by-patient, fresh on commit
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.
One-call FHIR export
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 →Searchable transcript
The transcript is chunked and embedded asynchronously, so hybrid search (BM25 + vector) and agent context build in the background while the clinician keeps working.
Hybrid search →Five states, fully typed.
Each step is a typed call that returns a freshness lifecycle — committed reads stay current, heavy indexing runs async and reports its status.
Capture the transcript
Stream the visit transcript in. Chunking and embedding kick off asynchronously — the clinician never waits on the index.
Draft the note
Your model generates a draft. bonfire stamps it provenance:"ai" so the AI-authored origin is recorded, not inferred.
Clinician edits and signs
The clinician edits the draft and signs. The signed note locks, attributed to the clinician — provenance now shows AI draft, human review, human signature.
Reads go fresh on commit
On sign, notesByPatient and the patient timeline are fresh. Hybrid search and agent context finish indexing in the background.
Export to FHIR
Call export and get a clean FHIR R4 DocumentReference for the signed note — ready for downstream interop.
Transcript to DocumentReference, in one file.
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.
The scribe objects.
Everything the Fire Starter models out of the box — typed, scoped, audited, and FHIR-exportable.
- Transcript — raw visit text, chunked and embedded async for search + agent context.
- Draft note — AI-authored,
provenance:"ai", editable until signed. - Signed note — locked, clinician-attributed, immutable, exportable.
- Provenance trail — who wrote, who reviewed, who signed.
- notesByPatient — committed read model, fresh on sign.
- DocumentReference — clean FHIR R4 export, generated on demand.
// 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" } }
Starter apps that light the whole flow.
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 Health Level Seven International, and HL7® does not endorse bonfireDB.
You build the app. Bonfire is the clinical data layer underneath.
Clone the Scribe Fire Starter and ship the scribe — provenance, audit, fresh reads, and FHIR export already wired.
Frequently asked questions
What backend should I use for an AI medical scribe?
bonfireDB is designed as the app backend above your canonical FHIR R4 (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.
How do I model the transcript-to-signed-note flow?
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.
How does bonfireDB track who wrote an AI-generated note?
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.
Can I export a signed note to FHIR?
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.
Is an AI scribe built on bonfireDB HIPAA compliant?
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.