FHIR underneath
The current core stores canonical FHIR R4 with immutable history and conformance-tested projections. App-native mappings and clean Bundle export describe the target early-access contract; Bundle export is not shipped in the canonical engine yet.
FHIR is for interoperability. It is not your app’s data model.
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, canonical FHIR R4 (core profiles) underneath.
The target mapping: every primitive maps to a FHIR resource
The core stores and versions canonical resources today. The early-access SDK is being built so clean primitives generate those resources consistently; clean Bundle export remains roadmap work.
| 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 |
Target contract: call clinical.notes.create(...) and have the DocumentReference, its Encounter link, and projections maintained through one governed write path. The current core has the canonical store and projected-write primitive; making every governed commit use that path is still in progress.
The planned API: a clean FHIR R4 Bundle in one call
The canonical resources needed for export live in the core today. Assembling a resolved patient Bundle through clinical.fhir.export is the next interoperability surface, not a shipped API.
// Target API — not shipped in the canonical engine yet const bundle = await clinical.fhir.export(patientId); // Patient, Encounters, DocumentReferences, Observations, // QuestionnaireResponses, Tasks, CarePlans — references resolved. bundle.resourceType; // "Bundle" bundle.type; // "collection"
Bundle export and SMART-on-FHIR read are on the roadmap
The current core stores canonical FHIR R4 and its history. Clean Bundle assembly and SMART-on-FHIR read are planned interoperability surfaces, not shipped APIs.
- Today: canonical, versioned FHIR R4 resources in Postgres
- Roadmap / planned: clean patient Bundle assembly for sharing or migration
- Roadmap / planned: SMART-on-FHIR read where the integration target supports it
- The intent — interop is a feature at the edges, not the substrate you code against
// Target interoperability APIs — both still planned const bundle = await clinical.fhir.export(patientId); // Your app code keeps thinking in primitives const notes = useClinicalQuery(api.notes.listByPatient, { patientId });
This is scoped conformance — not a full enterprise FHIR server
bonfireDB is pre-launch / early access. The core covers scoped resource storage, versioning, search paths, and conformance-tested projections. It is deliberately not trying to be HAPI, HealthLake, or Medplum. Clean Bundle handoff to an interoperability hub is planned, not implemented.
What bonfire is
- Canonical FHIR R4 underneath your app primitives
- Core resource types first (Patient, Encounter, DocumentReference, Observation, QuestionnaireResponse — plus Task, CarePlan, Practitioner)
- Common search paths before exhaustive search coverage
- Canonical FHIR R4 and immutable history today; Bundle export and SMART-on-FHIR read planned
What it is not (yet)
- A full enterprise FHIR server with every resource type and search parameter
- A drop-in replacement for HAPI / HealthLake / Medplum as the system of record for strangers
- A federation hub for cross-organization record exchange
If you need a full FHIR server as your interoperability hub today, that’s a different job — see the comparisons. Bonfire's clean Bundle handoff is still roadmap work.
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.
You build the app. Bonfire is the clinical data layer underneath.
Build toward app-native primitives over canonical FHIR R4. The canonical store and projections are in the core today; clean Bundle export and the complete SDK workflow are still rolling out.
Frequently asked questions
How do I generate a FHIR R4 Bundle from my app data?
Clean patient Bundle assembly is on the roadmap. The target API is clinical.fhir.export(patientId), backed by the canonical FHIR R4 resources and immutable history already implemented in the core.
Do I have to write FHIR resources to store clinical data in bonfireDB?
The current core accepts and stores canonical FHIR resources. The target SDK lets you write clean app primitives such as clinical.notes.create(…) and generates the corresponding canonical resource and links through one governed projected-write path.
Which FHIR resources does bonfireDB map to?
The target app primitives map to core outpatient resource types: Note 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.
Is bonfireDB a full FHIR server like HAPI, HealthLake, or Medplum?
No. bonfireDB is early access and offers scoped, conformance-tested resource storage and projections, not a full enterprise FHIR server. Clean Bundle export to an interoperability hub is planned, not shipped.
Does bonfireDB support SMART-on-FHIR?
Not yet. Both clean Bundle export and SMART-on-FHIR read are on the roadmap. The current core stores canonical FHIR R4 and immutable history so those interoperability surfaces have a lossless source.