HAPI FHIR in production
HAPI FHIR Production Backend with Application Services
HAPI FHIR is a strong server foundation. Running it as a product backend means writing the authorization model, GraphQL layer, identity mapping, scheduling, subscriptions, admin tooling, and operational glue around it. Fire Arrow Server ships those pieces.
Who this is for
Engineering teams evaluating HAPI FHIR for a production product backend, or already operating one and looking at the build-vs-buy line.
Clinical applicability
A clinic network running a HAPI FHIR-based backend can enforce practitioner and organisation boundaries across REST search and GraphQL reads using the LegitimateInterest and PractitionerCompartment validators, instead of writing a custom interceptor for each access path.
What HAPI FHIR gives you
FHIR R4 storage, validation, search, history, transactions, and the standard operations. Excellent extensibility through Java interceptors. A mature codebase widely used in health interoperability stacks.
What Fire Arrow adds on top of HAPI
OAuth 2.0 / OIDC authentication that maps a token to a Patient, Practitioner, RelatedPerson, or Device resource. A rule-based authorization layer with `client-role`, `resource`, and `operation` matching. Validators (`Allowed`, `Forbidden`, `PatientCompartment`, `PractitionerCompartment`, `RelatedPersonCompartment`, `DeviceCompartment`, `LegitimateInterest`, `CareTeam`). Identity filters for FHIRPath-scoped rule subsets. Property filters with `NullFilter` and `RandomFilter` for in-place anonymization, plus `blocked-search-params` to close search side-channels.
Read-only GraphQL with the same authorization layer (separate `graphql-read` and `graphql-search` operations). HFQL (SQL-on-FHIR) with full authorization. CarePlan-to-Task materialization with a scheduling horizon. FHIR Subscriptions over REST hook, email, WebSocket, and Azure Storage Queue. Durable and one-time API tokens. Identity resource protection against impersonation and accidental duplication. A web admin UI with a GraphQL explorer and a rule debugger driven by the `X-Fire-Arrow-Debug` header.
When to stay on plain HAPI
If your team wants full Java-level control over server internals, custom interceptor pipelines, storage tuning, and FHIR infrastructure extension points, plain HAPI plus your own application layer is a reasonable choice. If the goal is to ship a digital health product without owning the application backend layer, Fire Arrow Server removes most of that work.
Related pages
FAQ
Does Fire Arrow modify HAPI FHIR internals?
Fire Arrow uses HAPI FHIR JPA as the data layer and stays close to upstream. The authorization, GraphQL, scheduling, and admin layers run as separate concerns around it.
Can I keep my existing HAPI interceptors?
Most product-level concerns (authn, authz, search narrowing, scheduling) are better expressed in Fire Arrow's configuration than as Java interceptors. If you have HAPI interceptors that are still useful, contact us about how they integrate with the Fire Arrow build.
Will Fire Arrow track HAPI FHIR upgrades?
Yes. Releases follow upstream HAPI versions, with regression coverage of the authorization, GraphQL, and scheduling layers.
