FHIR backend
FHIR Backend for Digital Health Products
Fire Arrow turns FHIR into an application backend. Clinical data is stored as FHIR resources, exposed through GraphQL and FHIR REST, and protected by rules that map OAuth identities to Patient, Practitioner, RelatedPerson, and Device resources.
Who this is for
Digital health founders, CTOs, architects, and engineering teams choosing the application data layer for a regulated product.
Clinical applicability
A remote patient monitoring program can store Patients, Observations, QuestionnaireResponses, CarePlans, and Tasks as FHIR resources, and let patients see only their own data, clinicians see their organisation's panel, and a service account run anonymized analytics.
What ships in the box
Two editions cover the common deployment models. Fire Arrow Server is a self-contained backend built on HAPI FHIR JPA and PostgreSQL. Fire Arrow Core is a stateless facade that sits in front of an existing FHIR server such as Azure Health Data Services. Both editions use the same authentication and authorization model.
On the API side: FHIR REST, GraphQL, and HFQL (SQL-on-FHIR, beta) on Server; GraphQL plus delegated FHIR REST on Core. On the data side: HAPI FHIR JPA on Server, the upstream service on Core. On the workflow side: server-side CarePlan-to-Task materialization, FHIR Subscriptions over REST hook, email, WebSocket, and Azure Storage Queue, durable and one-time API tokens, and a web admin UI on Server.
How authorization works
Each request is authenticated against an OAuth 2.0 / OIDC provider, then mapped to a FHIR identity resource. A rule set is built from the client's role, target resource type, and operation (read, search, create, update, delete, graphql-read, graphql-search, subscribe, binary-upload, transaction, and others). The matched rule's validator decides whether the operation is allowed.
Searches are narrowed at the database level. A Patient role searching Observation under the PatientCompartment validator never sees other patients' rows because the server appends the compartment criterion to the underlying query. The same model applies to GraphQL through alternative search parameter maps. Identity filters add FHIRPath conditions to a rule, and property filters redact fields from authorized responses.
What you do not have to build
Authentication wiring, identity-to-FHIR mapping, role and rule evaluation, search narrowing, GraphQL schema generation over FHIR, CarePlan timeline materialization, subscription delivery channels, durable API tokens, audit-friendly identity protection, an admin UI, and the deployment artifacts for all of the above.
Related docs
Related pages
FAQ
Is FHIR a good fit for my application's primary data model?
If the application is about patients, observations, conditions, medications, care plans, or questionnaires, the FHIR resource model probably already covers most of the schema. If the data is not clinical or has no FHIR-equivalent shape, a general-purpose backend is a better fit.
Do GraphQL and FHIR REST share the same access rules?
Yes. The rule set is the same, but read and search must be configured per API surface. A rule for `read` does not grant `graphql-read`, and a rule for `search` does not grant `graphql-search`. This is intentional: it lets you expose a smaller GraphQL surface without rewriting REST authorization.
Which edition do I want?
Pick Fire Arrow Server if you need a single deployable backend with FHIR REST, GraphQL, server-side CarePlan scheduling, subscriptions, and an admin UI. Pick Fire Arrow Core if you already operate a managed FHIR service (such as Azure Health Data Services) and want to add authentication, authorization, and a GraphQL API in front of it.
Can it run in our own infrastructure?
Yes. Fire Arrow Server ships as a Docker container with PostgreSQL alongside it. Fire Arrow Core is a stateless container in front of your FHIR service. Both are deployable on Kubernetes, Docker Compose, or any container platform you control.
