Your app code thinks in notes, sessions and assessments. FHIR R4 — core profiles — is generated beneath them, there when you need to export or integrate, invisible when you don't.
FHIR R4 was designed to move records between organizations that don't trust each other. That's the right tool for export and integration — and the wrong tool to reach for on every screen of one app you control. bonfire keeps both: app-native primitives on top, FHIR R4 (core profiles) generated underneath.
You write to clean primitives. bonfire keeps the corresponding FHIR R4 resource in sync underneath, so a clean Bundle is always one call away.
| App primitive | FHIR R4 resource (underneath) |
|---|---|
| Note | DocumentReference |
| Session / visit | Encounter |
| Assessment answers | QuestionnaireResponse |
| Assessment score | Observation |
| Symptom event | Observation |
| Follow-up | Task |
| Care plan | CarePlan |
| Patient | Patient |
| Clinician | Practitioner |
You never hand-build a resource graph or chase references to write a note. You call clinical.notes.create(...); the DocumentReference, its Encounter link, and the rest are generated and kept consistent for you — fresh on commit.
When interoperability actually matters — sharing a record, leaving the platform, integrating with an EHR — ask for the Bundle. Your app never had to speak FHIR to get here.
// Generate a FHIR R4 Bundle (core profiles) on demand const bundle = await clinical.fhir.export(patientId); // Patient, Encounters, DocumentReferences, Observations, // QuestionnaireResponses, Tasks, CarePlans — references resolved. bundle.resourceType; // "Bundle" bundle.type; // "collection"
Bundle export ships today. SMART-on-FHIR read — pulling standardized resources from a partner that exposes a SMART API — is planned, not yet shipped. The shape is the same on your side: app-native primitives, standard wire format at the edge.
// FHIR stays at the edges — export today, SMART read planned const bundle = await clinical.fhir.export(patientId); // Your app code keeps thinking in primitives const notes = useClinicalQuery(api.notes.listByPatient, { patientId });
bonfireDB is pre-launch / early access. The mapping covers the core resource types and common search paths that outpatient apps actually use first. It is deliberately not trying to be HAPI, HealthLake, or Medplum — those are mature, full FHIR servers, and if you need one as your interoperability hub, they earn that job. bonfire exports clean R4 to hand off to one.
If you need a full FHIR server as your interoperability hub, that's a different job — see the comparisons for where dedicated FHIR servers fit and where bonfire exports clean R4 to them.
New to the model? FHIR explained for app developers walks through the resource graph, and why build on FHIR (and when not to) covers when generating it underneath beats reaching for it on every screen.
Build on app-native primitives. Let FHIR R4 (core profiles) generate underneath, fresh on commit — there for export and interop, invisible the rest of the time.
Call clinical.fhir.export(patientId). bonfireDB keeps a FHIR R4 resource (core profiles) in sync underneath your app primitives, so it assembles a Bundle of type "collection" — Patient, Encounters, DocumentReferences, Observations, QuestionnaireResponses, Tasks, and CarePlans — with references resolved, in one call.
No. You write to clean app primitives like clinical.notes.create(...), and bonfireDB generates the corresponding FHIR R4 resource and its links underneath, kept fresh on commit. You never hand-build a resource graph or chase references.
Core resource types outpatient apps use first: Note maps to DocumentReference, Session to Encounter, assessment answers to QuestionnaireResponse, scores and symptom events to Observation, follow-ups to Task, care plans to CarePlan, plus Patient and Practitioner.
No. bonfireDB is pre-launch and offers scoped conformance — core resource types and common search paths — not a full enterprise FHIR server. It generates FHIR R4 underneath and exports clean Bundles to a full server when you need an interoperability hub — it doesn't run on top of one.
Bundle export ships today. SMART-on-FHIR read — pulling standardized resources from a partner that exposes a SMART API — is on the roadmap and not yet shipped. The design keeps interop at the edges while your app code stays on app-native primitives.