Compare

Fire Arrow vs other FHIR backends

Fire Arrow sits between bare FHIR storage and a fully custom backend: a FHIR-native data layer with the application backend (authentication, rule-based authorization, GraphQL, scheduling, subscriptions, admin UI) included. These pages place Fire Arrow next to the other options teams evaluate, with the architectural trade-offs spelled out.

Book a backend review Read the documentation

How Fire Arrow positions itself

  • FHIR-native data layer

    Standard FHIR R4 throughout, with profile validation. ISiK, KBV, US Core, and other regional profile families are configuration on the relevant resources, not a separate edition.

  • Application backend included

    OAuth/OIDC identity tied to a FHIR identity, deny-by-default authorization, GraphQL with consistent search narrowing, CarePlan-driven scheduling, FHIR Subscriptions, and an admin UI.

  • Two deployment shapes

    Fire Arrow Server is self-contained on PostgreSQL. Fire Arrow Core sits as a facade in front of an existing FHIR store (HAPI FHIR, Azure Health Data Services, others).

Who this is for

Architects, CTOs, and technical evaluators choosing a FHIR backend for a digital health product, a clinical platform, or a regulated medical device.

Open-source FHIR servers

These projects implement the FHIR REST surface and the storage underneath it. Fire Arrow Server uses HAPI FHIR JPA as its data layer, and Fire Arrow Core can sit in front of any FHIR-conformant server. The application backend layer (identity, authorization, GraphQL, scheduling) is what Fire Arrow contributes on top.

Commercial FHIR platforms

Aidbox, Smile CDR, Medplum, and Kodjin are self-contained FHIR backends with broader product surfaces. The comparison pages walk through where Fire Arrow Server overlaps, where it goes deeper (rule-based authorization tuned to clinical relationships, GraphQL with consistent search narrowing, CarePlan scheduling that schedules Questionnaires to patients), and where the other product has a wider feature set.

Cloud-managed FHIR APIs

Azure Health Data Services, Google Cloud Healthcare API, and AWS HealthLake are managed FHIR storage offerings from the major cloud providers. Fire Arrow Core can extend any of them with the application backend layer; Fire Arrow Server can replace them with a self-contained backend running on the same cloud.

Building it yourself

Some teams reach for a relational backend (Supabase, plain PostgreSQL with a custom API) or for in-house RBAC layered on a generic application framework. The build-vs-buy comparisons spell out what that path involves: the FHIR data model, the access-control surface area, and the regulatory artifacts that come with FHIR-shaped storage.

Related docs

Related pages

FAQ

Where do I start if I am not sure which comparison applies?

If you are already running a FHIR server, start with the comparison for that server (HAPI FHIR, Aidbox, Smile CDR, Azure Health Data Services). If you are weighing whether to build the backend in-house, the build-vs-buy comparison and the RBAC comparison cover the trade-offs end to end.

Are these comparisons fair?

Each page describes the other product on its own terms before drawing any contrast. Where the other product is the better fit for a use case, the page says so. Suggestions and corrections from the maintainers of those products are welcome.

Do you support migration from one of these to Fire Arrow?

For FHIR-native sources, migration is a FHIR Bulk Export from the source followed by a FHIR import into Fire Arrow. For non-FHIR sources, migration involves shaping the existing data into FHIR resources first; the comparison pages and the build-vs-buy whitepaper describe the typical patterns.