Building on FHIR, explained.
Plain-English guides and research notes for developers and clinician-founders shipping outpatient healthcare apps and clinical agents.
The backend for an AI medical scribe
Where transcripts and SOAP notes actually go, the data model a scribe needs, and the regulated parts (BAA, audit, signed-note provenance, FHIR export) you cannot fake.
Read the guide →What actually moves FHIR agents
The visual summary of our benchmark: raw FHIR, blunt projection, sandbox proxy, cost ledger, and the pre-registered A6a query-aware selection result.
Read the research →Clinical context engineering for FHIR agents
The full red-teamed report: context fit, judge failure, query-aware selection, and why Bonfire is a clinical context layer, not a prompt trick.
Read the research →The evidence packet is the product
Why the durable object for clinical agents is a bounded, cited, query-aware read packet - not a raw FHIR dump, a prompt trick, or a sandbox by default.
Read the research →MCP benchmarks are easy to lie with
MCP is an interface, not the treatment. Freeze the tool schema, returned evidence, prompt, model, judge, context budget, and cost before making claims.
Read the research →Build an AI scribe in a weekend without hand-rolling the data layer
Step by step: capture audio → transcribe → AI draft → clinician signs with provenance → store as a FHIR DocumentReference → export → audit.
Read the guide →How to build an outpatient app in an afternoon
Behavioral-health, end to end: a patient, a PHQ-9 intake as a QuestionnaireResponse, notes, and a fresh timeline — on typed clinical primitives.
Read the guide →What is a SMART-on-FHIR app — and how to make your app interoperable
Plain English: FHIR is the data layer, SMART is the auth layer. EHR launch vs standalone, scopes and PKCE, and the playbook for interoperability — without hand-rolling a FHIR server.
Read the guide →Why build on FHIR (and when you shouldn't)
The custom-schema trap, the interoperability expectation, why FHIR is the substrate — and why agents still need query-aware context above it.
Read the guide →Can you vibe-code a HIPAA-compliant app?
AI tools can build the app — but a BAA on your coding tool doesn't make it compliant, and they emit compliant-looking code that isn't. Where the line really is.
Read the guide →FHIR, explained for app developers
The no-jargon guide: what FHIR actually is, why it exists, and why building your app directly on it hurts — and what to do instead.
Read the guide →More in the series:
- Skills are not a product: how to test FHIR playbooks without fooling yourself
- Your LLM judge is part of the system under test: how a weak grader can invert a benchmark
- The token ledger is a product requirement: cost, calls, and context waste beside accuracy
- Hybrid clinical memory without generic RAG: vectors after patient, date, code, and permission filters
You build the app. Bonfire is the clinical data layer underneath.
bonfireDB is the open-source clinical backend that handles healthcare's data standards for you. In early access.