Smile CDR Alternative for App Teams

TL;DR

Smile CDR is a mature, certified (ONC (g)(10), Drummond, HITRUST r2, SOC 2 Type II, ISO 27001) FHIR-native clinical data repository built on HAPI FHIR, proven at payer and government scale (100M+ lives) with a full enterprise terminology server, partition-based multi-tenancy, and a SMART/OAuth2 authorization server. It is engineered for interoperability programs — broad FHIR-version coverage, HL7v2/C-CDA ingestion, CMS suites — not for startup app velocity, and it carries an opaque enterprise license plus a heavy Java/JVM + Elasticsearch + Kafka operational footprint. bonfireDB is early-stage and largely vision: its bet is that founders building a single AI-native app want typed clinical primitives, a place for app/draft state, fresh-on-commit operational read models, a reactive client cache, and built-in ABAC-enforced semantic search, with FHIR R4 generated underneath rather than as the primary surface. If you run a multi-org interoperability program, Smile CDR is the safer, more complete choice today; if you are one team shipping an outpatient or agent-native product, bonfire's design targets the friction Smile CDR was never meant to solve.

At a glance

Smile CDR is the enterprise FHIR data fabric for payers, providers, and government interoperability programs; bonfireDB is an early-stage app-building backend for teams shipping outpatient and AI healthcare products fast.

	Smile CDR	bonfireDB
Type	Enterprise FHIR clinical data repository / health-data fabric	Clinical app backend (Convex-like), FHIR underneath
Language / stack	Java / JVM on HAPI FHIR; Linux-only; Postgres/Oracle/MSSQL + ES + Kafka	TypeScript + Postgres + pgvector
License / cost	Commercial, closed-source, contact-sales (see vendor pricing); per-module premium license keys	Planned Apache-2.0 core + managed tier
Hosting	Self-host (Docker/K8s, Linux) or managed; no free sandbox	Designed for your AWS or managed
App-native typed API	No — FHIR REST surface; custom logic via Java interceptors	Yes — typed clinical primitives
Fresh-on-commit app reads	Partial — parameter search is transactional; full-text (ES) is async by default	Yes — committed operational read models
Reactive realtime cache	No — server-side FHIR Subscriptions (Kafka/WebSocket); no client reactive cache	Yes — useClinicalQuery
Built-in semantic search	No — no native vector/semantic search; parameter + full-text only	Built in — pgvector, ABAC-enforced
Agent / MCP layer	No — no product MCP or agent layer; build over raw FHIR REST	Build-your-own-MCP over clean projections
Clinical authorization (write-enforced)	Yes — mature SMART/OAuth2 + compartment & partition permissions (write-enforced)	Yes — read + write enforced ABAC, auto-audit
Automatic audit / provenance	Automatic — all actions audited to admin-schema audit DB by default	Automatic
FHIR conformance / export	Full DSTU2-R5, ONC (g)(10) + Drummond certified, Bulk Data $export	FHIR R4 generated underneath; scoped conformance (honest: not a full enterprise FHIR server)
Best for	Payers, providers, government interoperability programs at scale	Builders of AI-native health apps (scribes, copilots, agents)

Where Smile CDR genuinely wins

Best-in-class conformance and certifications out of the box: ONC §170.315(g)(10) (Dec 2022, Inferno-tested), Drummond, HITRUST r2, SOC 2 Type II, and ISO 27001/27018/13485 — a compliance head start few competitors match.
Built on HAPI FHIR, the most widely deployed Java FHIR engine, with Smile as the upstream steward — deep spec expertise and fast tracking (R5 topic subscriptions, HAPI 8.x in 2026) plus complete DSTU2-through-R5 coverage with versioned-API auto-conversion.
A genuinely enterprise terminology server included, not bolted on: SNOMED CT, LOINC, ICD-10/11, RxNorm, CPT with $expand/$validate-code/$lookup/$translate, version-aware lookups, and CQL/quality measures.
Mature, FHIR-aware SMART-on-FHIR OAuth2 authorization server (App Launch + Backend Services, PKCE S256, consent screen) with compartment-level permission grants, partition permissions, and audit logging on by default.
Strong async backbone: classic and topic-based FHIR Subscriptions over Kafka/ActiveMQ with REST-hook/WebSocket/email/queue channels, reused for MDM — plus real partition-based multi-tenancy and MegaScale horizontal sharding.
Proven at payer/government scale (self-reported 190+ implementations, 100M+ US lives under CMS-9115-F, 255K+ tps) with broad HL7v2/C-CDA/CSV ingestion and managed Azure/AWS Marketplace options.

Where bonfireDB is built different

No native semantic/vector search, embeddings, RAG, or AI-agent layer in Smile CDR (confirmed absent from primary docs as of 2026.02.R01 / HAPI 8.x) — bonfire's design makes pgvector semantic search a built-in primitive, ABAC-enforced per hit, rather than something you export FHIR and build externally.
No product MCP server or build-your-own-tool layer in Smile CDR — agents must be bolted on over the raw FHIR REST API. bonfire's positioning is build-your-own-MCP over clean typed projections, so agents read curated read models instead of raw, sprawling FHIR resources.
Smile CDR's full-text search (_content / _text via Elasticsearch/OpenSearch) is asynchronous by default — verified: writes are 'not available to subsequent reads for a short period while the indexes synchronize,' and forcing refresh=wait_for is documented as a real performance hit. bonfire's design serves app reads from committed operational read models that are fresh on commit, so the UI never shows a stale full-text/derived view. (Honest scope: standard FHIR search parameters in HAPI/Smile ARE indexed in the relational DB within the write transaction, so parameter search is already consistent — the gap is the async full-text/derived-index path and the lack of typed app-facing projections, not all reads.)
Smile CDR provides server-side subscriptions but no client-side reactive query cache — you build a WebSocket/REST-hook consumer and wire your own UI invalidation. bonfire's design makes the reactive client primitive (useClinicalQuery) first-class, so the app cache updates live without hand-rolling a subscription pipeline.
FHIR has no first-class home for app/draft/UI state, and Smile CDR is a FHIR repository — non-clinical app state typically lands in a second database you operate. bonfire's design treats app state as a first-class typed primitive alongside clinical data in one TypeScript + Postgres stack, removing the second-DB tax.
TypeScript-first vs Java/JVM, Linux-only, multi-service ops (relational DB + Elasticsearch cluster for real search + Kafka/ActiveMQ for subscriptions): bonfire's Apache-2.0 core runs on TypeScript + Postgres + pgvector that a small team can self-host or take managed, versus Smile CDR's opaque enterprise license, per-module premium keys, and no free hosted sandbox.

Which should you choose?

Choose Smile CDR if…

Choose Smile CDR if you are running a multi-organization interoperability program — payer, provider network, government, or research — where certified conformance (ONC (g)(10), CMS suites), full FHIR-version breadth, enterprise terminology, MDM, and proven payer/government scale matter more than app iteration speed, and you have the team to operate a Java + Elasticsearch + Kafka stack or buy the managed tier.

Choose bonfireDB if…

Choose bonfire if you are one team shipping a focused outpatient or AI-native healthcare app and want typed clinical primitives, a home for app/draft state, fresh-on-commit reads, a reactive client cache, and ABAC-enforced semantic search out of the box — with FHIR generated underneath — accepting that bonfire is early-stage with scoped (not full enterprise) FHIR conformance.

bonfireDB is early-stage; this compares its design and positioning against Smile CDR as it ships today (2026). Verify current Smile CDR capabilities before deciding.

FAQ

Frequently asked questions

Is bonfireDB a Smile CDR alternative?

Only for one use case: a single team shipping an outpatient or AI-native app. bonfireDB is an app backend that generates FHIR underneath (not a FHIR server) (typed primitives, fresh-on-commit reads, ABAC semantic search) with FHIR R4 generated underneath. For a multi-org interoperability program, Smile CDR is the more complete, certified choice today.

What is the difference between Smile CDR and bonfireDB?

Smile CDR is an enterprise FHIR clinical data repository on HAPI FHIR (Java/JVM, plus Elasticsearch and Kafka), built for payer and government interoperability at scale. bonfireDB is an early-access TypeScript + Postgres + pgvector app backend optimized for one team's app velocity, not broad FHIR-version interoperability.

Does Smile CDR have built-in vector or semantic search for clinical notes?

As of 2026 (verify current), Smile CDR's primary docs show no native vector, semantic search, or RAG layer — it offers FHIR parameter search and Elasticsearch full-text only. bonfireDB is designed to make pgvector semantic search a built-in primitive, ABAC-enforced per hit, instead of exporting FHIR to build it externally.

Does Smile CDR have an MCP server or agent layer?

As of 2026 (verify current), no — agents are bolted on over Smile CDR's raw FHIR REST API. bonfireDB's design is build-your-own-MCP over clean typed projections, so agents read curated read models instead of sprawling raw FHIR resources.

Why choose a TypeScript FHIR backend over Smile CDR's Java stack?

Smile CDR runs Java/JVM on HAPI FHIR with Elasticsearch and Kafka, an opaque enterprise license, and no free sandbox. bonfireDB is designed as an Apache-2.0 TypeScript + Postgres + pgvector core a small team can self-host or take managed — trading enterprise FHIR breadth for app-building speed.

bonfireDB vs Smile CDR