Building on FHIR, explained.

Plain-English guides for developers and clinician-founders shipping outpatient healthcare apps.

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 →

Build an AI scribe in a weekend (without a HIPAA lawyer)

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 makes you agent-ready — and an honest look at when FHIR is the wrong call.

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 →
Coming soon

More in the series:

You build the app. Bonfire is the clinical data layer underneath.

bonfireDB is the open-source clinical backend for FHIR-safe outpatient apps. In early access.