FHIR backend explained

What is a FHIR backend? Architecture, capabilities, and how Fire Arrow implements one

A FHIR backend is the data layer of a digital health product. It stores clinical data as HL7 FHIR resources, serves it through FHIR REST and GraphQL, and enforces role-based access at the data layer. This page explains what that means, the capabilities a FHIR backend needs to be production-ready, and how Fire Arrow implements each one.

Read the architecture docs Book a free 30-min architecture review

What a FHIR backend gives you

  • A clinical data model that is already standard

    150+ HL7 FHIR R4 resource types cover patients, observations, conditions, medications, encounters, care plans, questionnaires, tasks, and the rest of the clinical surface. No custom schema, no migration when a partner system needs to read or write the data.

  • FHIR REST and GraphQL on the same data

    Standard FHIR REST for write paths and partner integrations. GraphQL for read-optimized queries from your own frontends. Both enforce the same authorization boundary.

  • Authorization that maps OAuth identities to FHIR resources

    OAuth/OIDC tokens resolve to Patient, Practitioner, RelatedPerson, or Device resources. Rules are evaluated at the data layer, so search results, includes, and bulk exports respect the same boundary as a single read.

  • Subscriptions and scheduled work as first-class concepts

    FHIR Subscriptions over REST hook, email, WebSocket, and message queue. CarePlan-to-Task materialization for recurring clinical activities like medication reminders or questionnaire schedules.

  • Audit and identity attribution by construction

    Every authorised request records the resolved identity and the rule that authorised it. The audit log is the input to HIPAA, GDPR, MDR, IEC 62304, ISO 27001, and DiGA dossiers without a parallel logging system.

  • Anonymization at query time

    Property filters redact fields from authorized responses. Identity filters narrow which resources a role can see using FHIRPath expressions. The same server can serve full PHI to one role and anonymized data to another with no export step.

What happens when a request hits a FHIR backend

  1. 1
    Authenticate the caller

    The OAuth 2.0 / OIDC provider issues a token for a user, a service account, or an AI agent. The backend verifies the token and resolves it to a FHIR identity resource (Patient, Practitioner, RelatedPerson, or Device).

  2. 2
    Build the rule set for the request

    The backend looks up the rules that match the caller's role, the target resource type, and the operation (read, search, create, update, delete, graphql-read, graphql-search, subscribe, transaction, bulk-export, and others).

  3. 3
    Evaluate the rules in order

    Default-deny. The first matching rule whose validator returns true authorises the request. The validator can be a compartment match, a care-relationship lookup, a FHIRPath expression, or a composition of any of those.

  4. 4
    Narrow the query at the data layer

    For searches, the backend appends the rule's criteria to the underlying query, so the database never returns rows the caller is not allowed to see. For GraphQL, the same model applies through the alternative search-parameter map.

  5. 5
    Apply field-level filters to the response

    Property filters strip fields the caller is not permitted to see. Identity filters can further narrow the result set. Side-channel controls (search-parameter blocklists, reference-traversal limits) close the inference paths a property filter alone does not close.

  6. 6
    Record the authorised request in the audit log

    The audit entry names the caller, the resource, the operation, and the rule that authorised it. The entry is identity-attributable by construction; no application code is required to log it.

Capabilities a production FHIR backend needs

Capability With Fire Arrow Building it yourself
FHIR data store HAPI FHIR JPA on PostgreSQL (Server) or any upstream FHIR service (Core). 150+ resource types, profile validation, history. Custom schema, custom indexing, custom history, custom profile validation. Months of work that ships nothing visible.
FHIR REST API Spec-conformant FHIR REST endpoints for every resource type. _search, _include, _revinclude, _summary, conditional updates. Implementing the FHIR REST surface, search-parameter parsing, and conformance statements per resource type.
GraphQL on FHIR GraphQL schema generated from the FHIR profile set, with the same authorization boundary as REST. Hand-rolled GraphQL schema, parallel resolver layer, parallel authorization checks per resolver.
OAuth/OIDC + identity mapping Vendor-neutral OAuth/OIDC, mapped to FHIR identity resources. Service-account and AI-agent tokens supported out of the box. Identity middleware, token-to-resource mapping, service-account model, on-behalf-of flow for agents.
Authorization (RBAC) at the data layer Default-deny rule chain. Compartments, care relationships, identity filters, property filters, search-parameter blocklists, reference-traversal limits. Per-controller checks that diverge over time. Search-result leaks. Side-channel inference through includes and search parameters.
CarePlan scheduling Server-side CarePlan-to-Task materialization. Tasks transition as they come due. Webhooks fire on state changes. Cron jobs, custom scheduler, custom webhook delivery, custom retry semantics.
FHIR Subscriptions REST hook, email, WebSocket, and message-queue channels. Topic-based subscriptions per FHIR R5. Change-data-capture pipeline, subscription store, delivery-channel implementations, retry and dead-letter handling.
Audit log Identity-attributable audit on every authorised request. Names the rule that authorised it. Application-level logging, parallel audit pipeline, after-the-fact reconciliation when the audit is incomplete.
Anonymization Property filters and identity filters at query time. Same server serves PHI and anonymized data to different roles. Separate anonymized export, parallel data store, ETL pipeline, drift between the two stores.
Compliance dossier inputs Architectural description, access-control documentation, change history, supplier-evaluation context for HIPAA, GDPR, MDR, IEC 62304, ISO 27001, DiGA. Developed under an ISO 27001-aligned QMS. Original work for each audit, recreated for each customer, recreated for each regulatory framework.

Who this is for

Digital health founders, CTOs, architects, and engineering teams evaluating whether a FHIR backend is the right data layer for their product, and what the implementation should look like.

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. The same backend handles a clinical trial, a digital therapeutic, or an EHR-connected workflow because the data model and access boundary do not change between products.

Capability comparison

Capability Fire Arrow General-purpose backend
Data model 150+ FHIR R4 resource types out of the box Empty schema. You design every table.
Interoperability Standard FHIR REST. Any FHIR-aware system can read/write. Custom REST/GraphQL. Each partner needs a translation layer.
Profile validation Validation against US Core, ISiK, KBV, IPS, EHDS profiles Custom validation rules per field, per profile
Authorization model FHIR-aware: compartments, care relationships, identity-to-resource mapping Generic row-level security. Clinical relationships are your code.
Audit Identity-attributable on every request, FHIR-shaped Application-level logging. Reconciliation is on you.
Workflow CarePlan-to-Task scheduling and Subscriptions ship with the product Cron jobs, queues, scheduler are your code
Regulatory dossier Backend-layer inputs for HIPAA/GDPR/MDR/IEC 62304/ISO 27001/DiGA Original work for each audit, each customer, each framework

What is a FHIR backend?

A FHIR backend is the data layer of a digital health product. It stores clinical data as HL7 FHIR resources rather than as application-specific tables, exposes that data through standard FHIR APIs (REST, and usually GraphQL on top), and enforces healthcare-specific access rules at the layer where the data lives.

The defining property is not just that the storage is FHIR. The defining property is that the entire interface to the data is FHIR-shaped: the resource types, the search parameters, the references between resources, the audit, and the access boundary all use FHIR concepts. A backend that stores FHIR JSON in a generic database but exposes it through a custom API is not a FHIR backend in the production sense; the layer above it has to re-invent the FHIR semantics that were thrown away at the storage boundary.

Why build on FHIR rather than a custom schema?

FHIR is the standard the industry has converged on for clinical data exchange. ISiK and KBV in Germany, US Core in the United States, IPS internationally, the EHDS across the EU. Each is a profile against the same FHIR R4 base. A backend that stores patients as a custom schema has to translate to FHIR for every partner system. A backend that stores patients as FHIR Patient resources just validates against the profile the partner expects.

FHIR also pre-decides a long list of design questions a custom schema team has to answer themselves: how to model an observation, how to link a medication to its administration, how to express a care relationship, how to version a resource, how to identify a patient across systems, how to represent consent. Each of those is a small project that a FHIR-shaped backend resolves by picking up the standard answer.

Where the architectural decisions live

The architecture of a FHIR backend lives in three places: the data store, the API surface, and the access boundary. The data store has to support the FHIR resource model, history, and search. The API surface has to support FHIR REST and, in practice, GraphQL for read-heavy frontends. The access boundary has to enforce healthcare-specific rules (patient compartments, care relationships, organisation membership, anonymized roles) at the layer where every read and every write flow through.

The hardest of the three is the access boundary. A FHIR backend that gets the data store and the API right but puts the access boundary in application code above the API leaks. The leak is predictable: a search returns rows a single-resource read would have refused; an _include reaches a resource the caller cannot read directly; a property filter strips a field but leaves the search parameter that infers it. The architectural decision that survives is putting the rule chain at the data layer, where the data store, the REST API, the GraphQL API, the subscription delivery, and the bulk export all flow through the same boundary.

We expanded on the access-boundary decision in [The FHIR Authorization Tax](/insights/the-fhir-authorization-tax/).

How Fire Arrow implements a FHIR backend

Fire Arrow ships in two editions that share the same authentication and authorization model. [Fire Arrow Server](/fhir-server/) is a self-contained backend built on HAPI FHIR JPA and PostgreSQL. [Fire Arrow Core](/azure-health-data-services-extension/) is a stateless facade that sits in front of an existing FHIR service (Azure Health Data Services, for example) and adds authorization, identity mapping, and a GraphQL API in front of it.

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.

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. The matched rule's validator decides whether the operation is allowed. Searches are narrowed at the database level, so a Patient role searching Observation under the PatientCompartment validator never sees other patients' rows. 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, an API-token model for anonymous and pseudonymous patterns, audit-friendly identity protection, an admin UI, and the deployment artifacts for all of the above. Each of these is the kind of work a team can do but rarely sets out to do. They are infrastructure for the application above them.

Related docs

Related pages

FAQ

What is a FHIR backend, in one sentence?

A FHIR backend is the data layer of a digital health product that stores clinical data as HL7 FHIR resources, exposes it through standard FHIR APIs, and enforces healthcare-specific access rules at the data layer.

How is a FHIR backend different from a generic application backend?

A generic backend gives you tables, generic row-level security, and a job runner. The clinical model, role-aware authorization, FHIR-shaped audit, partner integrations, and the regulatory dossier are still on you to build. A FHIR backend ships those as part of the product because they recur across every digital health application.

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.

Where should the access boundary live in a FHIR backend?

At the data layer. Boundaries enforced in API gateways or controller code fail in predictable ways: a search returns rows a read would have refused, an _include reaches a resource the caller cannot read directly. A boundary at the data layer is enforced uniformly across REST, GraphQL, subscriptions, and bulk export.

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 Fire Arrow 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 a FHIR backend 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.

How does a FHIR backend support multi-tenancy?

Tenant isolation lives in the FHIR data model, typically through Organization references and compartments. Composable validators let one server host many tenants without separate databases, and without the risk of a search query crossing the tenant boundary. See [multi-tenant FHIR](/use-cases/multi-tenant-fhir/) for the full pattern.

How does a FHIR backend handle anonymization?

Property filters redact fields from authorized responses; identity filters narrow which resources a role can see. The same server can serve full PHI to one role and anonymized data to another without an export step. See [FHIR anonymization](/features/fhir-anonymization/).

How does a FHIR backend handle AI agents?

AI agents are a new kind of caller, not a special case. They authenticate, take an on-behalf-of identity, and call the backend through tools. The data-layer access boundary applies to them the same way it applies to a clinician's session. See [AI agents on FHIR](/use-cases/ai-agents-fhir/) and [LLM access control for healthcare](/ai/llm-access-control-healthcare/).

Which compliance frameworks does a FHIR backend support?

A FHIR backend is the data layer; it produces the backend-layer inputs to a compliance dossier. Fire Arrow specifically supports HIPAA, GDPR, MDR, IEC 62304, ISO 27001, and the German DiGA framework. The customer's dossier is still the customer's submission; the backend supplies the architectural description, access-control documentation, change history, and supplier-evaluation context.

How does a FHIR backend compare to building on HAPI FHIR directly?

HAPI FHIR is the underlying FHIR server engine. A production FHIR backend needs the layers above HAPI: identity mapping, RBAC at the data layer, GraphQL, subscription delivery channels, CarePlan scheduling, an admin UI, and the deployment artifacts. See [Fire Arrow vs HAPI FHIR](/compare/hapi-fhir/) and [running HAPI FHIR in production](/hapi-fhir-production-backend/).