Security & HIPAA
bonfire is a library, not a data processor. On the OSS tier it is designed to run in your AWS — we never touch your PHI, so you operate under your own AWS BAA. Need us to host it? The managed tier is designed around a BAA we sign, backed by our own AWS BAA. Either way, encryption, audit, ABAC, and consent are designed into the data layer — not bolted on.
The safest place for your PHI is the place we never see it
Most “HIPAA-compliant” backends ask you to ship your patients' data into their cloud and trust their controls. bonfire’s default is the opposite: the open-source tier runs entirely inside your AWS account. The data layer is yours, the encryption keys are yours, the audit trail is yours. We’re a dependency in your package.json — like Postgres or pgvector — not a third party holding your records.
Runs in your AWS
The OSS tier deploys into your own account. Postgres, pgvector, the read models, the canonical FHIR record — all inside your VPC, under your IAM, in your region.
Your keys, your audit
Encryption uses your KMS keys. The AuditEvent stream lands in your store. There’s no console of ours where your PHI can be browsed, because it isn’t there.
Compliance is designed in
Encryption at rest and in transit, automatic audit + provenance, ABAC with minimum-necessary, and a live consent engine are part of the data-layer design — you don’t assemble them.
Who is the Business Associate? It depends which tier you run.
This is the question every compliance buyer asks first, so here’s the honest, unambiguous answer — it turns on who holds the PHI, not on marketing.
- ✓ OSS tier (Apache-2.0): bonfire runs in your account. We never receive, store, or transmit your PHI, so we are not a Business Associate — there is nothing for us to sign, the same way Postgres or React isn’t your BA. You operate under your existing AWS BAA.
- ✓ Managed tier: we host it and handle PHI on your behalf, so we are your Business Associate — designed for a BAA with you, backed by our own AWS BAA. Planned for launch / early access.
- ✓ Same code path, same encryption, same audit and ABAC on both tiers. The only thing that changes is whose infrastructure runs it.
Choose the tier that matches who you want holding the PHI. If your security team would rather no vendor ever touch the data, run OSS in your own account and there is no BA relationship to negotiate.
// OSS tier — runs in YOUR AWS account const stack = await bonfire.deploy({ account: "your-aws-account", region: "us-east-1", kmsKey: "arn:aws:kms:…:key/your-cmk", }); // → we never see the PHI ⇒ not your BA // Managed tier — we host + sign a BAA // backed by our own AWS BAA // same SDK, same controls, you don't run infra
Encrypted at rest and in transit — with your KMS keys
Encryption isn’t a toggle you remember to flip. On the OSS tier, bonfire is designed to provision storage with KMS-backed encryption at rest and TLS everywhere on the wire — using keys that live in your account, so you control rotation, revocation, and who can decrypt.
clinical.encryption.config({ // at rest: your customer-managed KMS key (CMK) atRest: { kms: "arn:aws:kms:…:key/your-cmk", rotate: true }, // in transit: TLS to the DB and to every client inTransit: { tls: "required" }, // field-level envelope encryption for the most sensitive kinds fieldLevel: ["ssn", "psychotherapyNotes"], });
Honest framing: bonfireDB is pre-launch / early access. Encryption-at-rest, TLS in transit, and customer-managed KMS keys are part of the product design described here. Field-level envelope encryption for the most sensitive kinds is on the roadmap; the API shape above is how it’s intended to be configured.
Audit and provenance you don’t have to remember to write
The biggest gap in most clinical stacks is the AuditEvent nobody wired up. In bonfire the audit record is part of the operation — every read, write, export, and agent call emits a FHIR AuditEvent with actor, patient, purpose, and outcome, automatically.
- ✓ Auto-AuditEvent on every operation — designed so that no path touches a patient and forgets to log it.
- ✓ Writes carry Provenance back to their source, so “where did this value come from” is answerable.
- ✓ Agent reads are audited too — including which records the agent pulled to build its context.
- ✓ The audit stream lands in your store, in your account — yours to query, retain, and ship to a SIEM.
Because audit lives inside the access gate, the side doors that leak elsewhere — export, history, GraphQL — are logged here like any other read. See clinical authorization & audit for how the gate works.
{ resourceType: "AuditEvent", action: "R", // read outcome: "0", // success agent: { actor: "clinician:dr-okafor" }, entity: { patient: "pt-123", record: "Observation/o-9" }, purpose: "treatment", via: "agent:session-prep" // audited like any read }
ABAC, minimum-necessary, and consent — enforced on every path
HIPAA’s minimum-necessary rule isn’t a policy document in bonfire; it’s a function the data layer is designed to run on every request. Patient–clinician scoping, tenancy isolation, role-scoped kinds, and a live consent engine all gate reads and writes — there is no export door, history door, or agent door that skips them.
clinical.access.policy({ // tenancy: a request can only touch one tenant's data tenant: (ctx) => ctx.orgId, // patient scope: clinician must be assigned to the patient canReadPatient: (ctx, patientId) => clinical.assignments.exists({ clinician: ctx.userId, patientId }), // minimum necessary: scope which kinds a role may read minimumNecessary: { front_desk: ["appointments", "demographics"], clinician: ["notes", "assessments", "observations"], }, // consent as a live engine — withdrawn = closed on next request consent: (ctx, patientId) => clinical.consent.active({ patientId, purpose: "treatment" }), });
Every clause runs on both directions. A write that violates tenancy, minimum-necessary, or consent is refused the same way a read is — the policy doesn’t care which verb you used. Consent is evaluated per request: withdraw it and the next read fails closed, including $export and history.
No data egress. No lock-in. Export your Bundle anytime.
A clinical backend you can’t leave isn’t a backend — it’s a hostage situation. Because your record is canonical FHIR R4, leaving is a function call, not a migration project. Ask for the Bundle and you get a clean, standards-shaped copy of everything.
- ✓ Your PHI never leaves your account on the OSS tier — there’s no telemetry exfil of patient data, no phone-home.
- ✓ Export a complete FHIR R4 Bundle on demand — references resolved, ready to migrate or share.
- ✓ Apache-2.0 planned for the OSS core: when it opens you can read the code, fork it, and audit exactly what runs (pre-release today — early access).
- ✓ Data residency is yours to choose — pick the AWS region; the whole stack runs there.
The honest trade-off: running OSS in your own account means you own the operational burden — patching, backups, key rotation. The managed tier exists for teams who’d rather we carry that, under a signed BAA. More on FHIR underneath →
// leave anytime — no migration, no support ticket const bundle = await clinical.fhir.export(patientId); bundle.resourceType; // "Bundle" bundle.type; // "collection" // or the whole tenant, for migration or backup await clinical.fhir.exportTenant({ orgId, to: "s3://your-bucket" }); // flows through the same audited access gate
What the data layer is designed to enforce
Statuses live on the roadmap — “Building now” means in progress, not shipped; later stages haven’t started.
These are the controls a compliance buyer maps to the HIPAA Security Rule. In bonfire they’re designed as properties of the data layer, not a checklist you implement yourself.
- Encryption at rest (KMS, your keys)
- TLS in transit, end to end
- Auto AuditEvent on every op
- Provenance on every write
- ABAC: patient + tenant scoping
- Minimum-necessary, role-scoped
- Live consent engine, per request
- Time-bound break-glass, flagged
- Agent writes propose-only
- Choose your AWS region (residency)
- FHIR Bundle export anytime
- Apache-2.0 OSS core (planned) — auditable
The BA distinction in one line: on the OSS tier bonfire runs in your AWS and never handles your PHI, so it is not a Business Associate and there’s nothing for us to sign — you operate under your own AWS BAA, like any library. On the managed tier we host it and therefore are your Business Associate, so we sign a BAA with you, backed by our own AWS BAA. Pick the tier that matches who you want holding the PHI.
What we hold today — and what’s on the roadmap
bonfireDB is pre-launch / early access. We’d rather be precise than impressive: here’s what’s real, what’s planned, and where the line is. Certifications are earned, not claimed.
Launch / early access target
- OSS tier runs in your AWS — your keys, your audit, your region
- Encryption at rest (KMS) + TLS in transit
- Automatic AuditEvent + Provenance on every operation
- ABAC, minimum-necessary, and live consent on read + write
- FHIR R4 Bundle export — no egress, no lock-in
- Managed tier with a signed BAA, backed by our AWS BAA
On the roadmap — not yet claimed
- SOC 2 Type II — planned, not yet certified
- HITRUST CSF — planned, not yet certified
- Field-level envelope encryption for the most sensitive kinds
- Customer-facing audit + access-review reporting UI
- Managed-tier penetration test attestations
We will not put a certification badge on this page until we hold it. SOC 2 and HITRUST are on the roadmap; if you need a current attestation today, the OSS tier lets you inherit your own controls and your own AWS BAA in the meantime.
Security is the spine the rest of the backend runs through
Authorization & audit
The one gate every read, write, export, and agent call runs through.
Explore →FHIR underneath
Clean R4 Bundles power export, migration, and no-lock-in.
Explore →How it works
Canonical FHIR R4 in Postgres, fresh on commit, no Redis to put under a BAA.
Explore →All features
The full clinical data layer — primitives, hybrid search, MCP, and more.
Explore →You build the app. Bonfire is the clinical data layer underneath.
Run it in your own AWS under your own BAA, or let us host it and sign one with you. Either way, encryption, audit, ABAC, and consent are designed in, not bolted on.
Frequently asked questions
Is bonfireDB HIPAA compliant?
bonfireDB is designed so the compliance controls a buyer maps to the HIPAA Security Rule are built into the data layer: encryption at rest with KMS, TLS in transit, automatic AuditEvent and Provenance, ABAC with minimum-necessary, and a live consent engine. It is pre-launch / early access, and on the OSS tier you inherit your own AWS BAA and controls rather than relying on a vendor certification.
Do I need a BAA, and who is the Business Associate?
It depends on which tier you run. On the OSS (Apache-2.0) tier, bonfire runs in your AWS and never receives your PHI, so it is not a Business Associate and there is nothing for us to sign; you operate under your existing AWS BAA. On the managed tier we host it and handle PHI, so we are your Business Associate — designed for a BAA we sign with you, backed by our own AWS BAA (the managed tier is planned for launch / early access).
Can I self-host clinical data in my own AWS account?
Yes — that is the design: the OSS tier deploys entirely into your own AWS account, including Postgres, pgvector, the read models, and the FHIR projection, all inside your VPC, under your IAM, in the region you choose. Encryption uses your KMS keys and the audit stream lands in your store, so we never see your PHI.
How does bonfireDB enforce ABAC and minimum-necessary access?
HIPAA minimum-necessary is a function the data layer is designed to run on every request, not a policy doc. Patient-clinician scoping, tenant isolation, role-scoped kinds, and a live consent engine gate both reads and writes, and there is no export, history, or agent door that skips them. Withdraw consent and the next request fails closed.
Is bonfireDB SOC 2 certified?
No. SOC 2 Type II and HITRUST CSF are on the roadmap but not yet certified, and we will not put a badge on the page until we hold it. If you need a current attestation today, the OSS tier lets you inherit your own controls and your own AWS BAA in the meantime.