Fire Arrow with HAPI FHIR

Fire Arrow and HAPI FHIR

HAPI FHIR is the open-source Java FHIR framework Fire Arrow is built on. Fire Arrow Server bundles HAPI FHIR JPA as its data layer; Fire Arrow Core can sit as a facade in front of an existing HAPI deployment. In both cases HAPI keeps doing what it does well, and Fire Arrow contributes the application backend layer on top.

Review Fire Arrow editions Talk through your HAPI setup

How Fire Arrow extends HAPI FHIR

Fire Arrow Core in front of HAPI
A stateless service that authenticates client requests, resolves the caller's identity to a Patient, Practitioner, RelatedPerson, or Device resource, applies the configured authorisation rules, and forwards permitted requests to the upstream HAPI server over standard FHIR REST.
Fire Arrow Server built on HAPI
A self-contained backend that bundles HAPI FHIR JPA, PostgreSQL, the authorisation layer, GraphQL, CarePlan scheduling, subscriptions, API tokens, and the web admin UI into one deployment. The data layer remains HAPI's.
Same FHIR semantics throughout
Both editions speak FHIR R4. Existing FHIR REST integrations against HAPI keep working. Client apps can move to GraphQL as a separate decision, on their own timeline.
GraphQL for client apps
Read-only GraphQL with reference traversal on Fire Arrow Server. Read and write GraphQL on Fire Arrow Core, since Core delegates persistence to the upstream FHIR server. The same authorisation rules apply to GraphQL and FHIR REST.
Authorisation that respects FHIR relationships
Rules combine role, resource type, and operation. Compartment-based, organisation-scoped, and care-team-scoped rules cover the common clinical patterns. Identity-conditional rules narrow access to a subset of users in a role.
Workflow primitives on Server
Server-side CarePlan-to-Task materialisation, FHIR Subscriptions over REST hook, email, WebSocket, and Azure Storage Queue, durable and one-time API tokens, and a rule debugger for diagnosing denied requests.

Who this is for

Teams already running HAPI FHIR (or planning to) who need authentication, authorisation, a frontend-friendly GraphQL API, and operational tooling around it.

Clinical applicability

A clinic network running HAPI FHIR can keep its existing data store and add Fire Arrow Core in front to enforce patient and clinician access rules and expose a GraphQL API to client apps. A team starting fresh, or one ready to consolidate, can run Fire Arrow Server, which bundles HAPI FHIR JPA with the same authorisation, GraphQL, scheduling, subscriptions, and admin UI in one deployment.

Capability comparison

Capability Fire Arrow HAPI FHIR on its own

FHIR R4 storage HAPI FHIR JPA + PostgreSQL on Server. Upstream HAPI deployment on Core. HAPI FHIR JPA + your database

OAuth / OIDC authentication Built-in. Tokens map to a Patient, Practitioner, RelatedPerson, or Device identity resource inside HAPI. HAPI authentication interceptors, written and maintained per project

Rule-based authorisation Rules combining role, resource type, operation, and a validator. Compartments, identity filters, property filters, and side-channel protection. HAPI authorisation interceptor framework, configured in Java

Search narrowing Applied at query time, consistent across REST and GraphQL Per-endpoint code in interceptors

GraphQL API Read-only on Server with separate authorisation operations. Read and write on Core, since Core delegates persistence to HAPI. HAPI GraphQL module, with authorisation to add

CarePlan-to-Task scheduling Server-side materialisation on Fire Arrow Server Build externally

Subscriptions REST hook, email, WebSocket, and Azure Storage Queue on Server REST hook on HAPI base

Admin UI Built-in resource browser, GraphQL explorer, and rule debugger on Server Build or use a third-party tool

Database schema HAPI FHIR JPA's schema in both editions. Fire Arrow does not introduce a separate database schema. HAPI FHIR JPA's schema

Two ways Fire Arrow extends HAPI FHIR

Fire Arrow does not replace HAPI FHIR. Fire Arrow Server bundles HAPI FHIR JPA as its data layer and adds the application backend layer on top. Fire Arrow Core runs as a stateless facade in front of an existing FHIR R4 deployment, including HAPI, and adds the same application backend layer at the network edge.

Either edition keeps HAPI as the FHIR system of record. The data, the FHIR REST surface, and the database schema stay HAPI's. What Fire Arrow contributes is the layer above: OAuth and OIDC authentication mapped to FHIR identity resources, rule-based authorisation that respects FHIR compartments and clinical relationships, a GraphQL API for client apps, and (on Server) scheduled care plans, subscriptions, API tokens, and a web admin UI.

Fire Arrow Core: a facade in front of HAPI

Fire Arrow Core is a stateless service. It authenticates client requests against a configured OIDC provider, resolves the caller's identity to a FHIR resource (Patient, Practitioner, RelatedPerson, or Device), evaluates the configured authorisation rules, and forwards permitted requests to the upstream FHIR server. Clients talk to Core over GraphQL; Core talks to HAPI over standard FHIR REST.

HAPI keeps storing the data and serving the FHIR REST API. Core adds the authorisation boundary and the GraphQL surface in front of it. There is no separate Fire Arrow database, no schema change to HAPI, and no Java code to write or compile against the HAPI server itself. The FHIR resources Core needs to read for identity resolution and rule evaluation are stored as ordinary FHIR resources inside HAPI.

Fire Arrow Server: built on HAPI

Fire Arrow Server bundles HAPI FHIR JPA, PostgreSQL, and the Fire Arrow application layer into a single deployment. The data layer is HAPI: the same JPA entities, the same Postgres schema, and the same FHIR REST semantics. The authorisation layer, GraphQL endpoint, CarePlan scheduler, subscription channels, API token model, and web admin UI run inside the same process.

Because the storage layout is HAPI's, the operational profile is familiar to any team that has run HAPI before. PostgreSQL for the database, Flyway for schema migrations, the standard HAPI tuning knobs for the JPA layer. The application backend features sit alongside it, configured rather than coded.

Migration paths from plain HAPI

Adopting Fire Arrow Core does not require a data migration. Core is added as a separate service in front of the existing HAPI deployment, and clients are routed through Core's GraphQL endpoint instead of (or alongside) HAPI's FHIR REST endpoint. HAPI remains the system of record. Existing FHIR REST integrations can keep talking to HAPI directly while client apps move to GraphQL on their own schedule.

Adopting Fire Arrow Server is also low-friction because Server uses the same database schema as HAPI. The straightforward path is to point Fire Arrow Server at the existing HAPI Postgres database and let it serve the same data through the FHIR REST and GraphQL surfaces. Where that level of binary swap is not appropriate, a FHIR Bulk Export from the existing HAPI server followed by a FHIR import into Fire Arrow Server moves the data over losslessly in one piece. Both editions speak FHIR R4 throughout, so the application surface for downstream FHIR consumers does not change.

Release alignment

Fire Arrow Server tracks upstream HAPI FHIR releases. The authorisation, GraphQL, scheduling, and subscription layers are tested against each tracked HAPI version, so HAPI upgrades do not require parallel reviews of the application layer and the data layer.

Fire Arrow Core is decoupled from HAPI's release cycle because it talks to HAPI over the FHIR REST API. A HAPI upgrade on the storage side does not require a Fire Arrow Core update unless a FHIR specification feature Core relies on changes.

Related docs

FAQ

Is Fire Arrow a HAPI FHIR fork?

No. Fire Arrow Server uses upstream HAPI FHIR JPA as its data layer; Fire Arrow Core sits in front of an existing FHIR R4 server (HAPI included) over standard FHIR REST. Neither edition forks the HAPI codebase.

Do I need to migrate data to use Fire Arrow Core?

No. Fire Arrow Core runs as a facade in front of the existing HAPI deployment. Client apps move to Core's GraphQL endpoint while HAPI stays as the system of record. Existing FHIR REST integrations can keep talking to HAPI directly.

How do I move from HAPI to Fire Arrow Server?

Two routes are available. Because Fire Arrow Server uses HAPI FHIR JPA's database schema, it can be pointed at the existing HAPI Postgres database and take over from the existing HAPI deployment. Where that is not appropriate, a FHIR Bulk Export from the source HAPI server followed by a FHIR import into Fire Arrow Server moves the data over losslessly in one piece.

Can I keep custom HAPI interceptors I have already built?

Most product-level concerns (authentication, authorisation, search narrowing, scheduling, audit) are expressed in Fire Arrow as configuration rather than as Java interceptors. For interceptors that handle truly server-internal concerns, contact us so we can talk through how they fit alongside Fire Arrow.

How do release cycles align with HAPI?

Fire Arrow Server tracks upstream HAPI versions, with regression coverage on the authorisation, GraphQL, scheduling, and subscription layers. Fire Arrow Core is decoupled from HAPI's release cadence because it communicates with HAPI over FHIR REST.

Which edition fits a team that already runs HAPI?

Fire Arrow Core is the lower-friction option: keep HAPI in place and add Core in front for authentication, authorisation, and GraphQL. Fire Arrow Server fits when the team is also looking to consolidate the application backend (scheduling, subscriptions, admin UI) into one deployment that uses HAPI's data layer underneath.