Why We Built Fire Arrow

Rebuilding the same backend

For most of the last decade we have built backends for digital health products. The product on top changed each time. The backend underneath was the same shape with a different schema. Each one stored patients, observations, conditions, medications, encounters. Each one had to authenticate users, authorise per-role access, audit every read and write, and survive a regulator’s review. Each one took most of a year to get right and the rest of the year to keep working as the product grew.

The pattern was not that the backend was hard in a new way each time. The pattern was that the same hard parts recurred across products and across customers: the access boundary, the audit, the integration shape, the regulatory dossier. The unique parts (the workflow, the UX, the clinical model) were what teams were paid to build, and what they spent the least time on because the backend ate the year.

We built Fire Arrow because we got tired of building it again.

What the product is

Fire Arrow is a FHIR backend. The data model is HL7 FHIR R4, the global standard to exchange healthcare data. Access control, authentication, identity resolution and audit capabilities are built right into the foundation and ship with every deployment, because every backend we built in the past had to support them. This includes the FHIR REST API, GraphQL, FHIR Bulk Data, and OAuth 2.0 / OpenID Connect for authentication.

The backend-layer compliance work we used to redo on every project is now written once, against a single Fire Arrow architecture. That work covers the architectural description, the access-control documentation, the change history, and the supplier-evaluation context required for HIPAA, GDPR, MDR, IEC 62304, ISO 27001, and DiGA. It feeds into whatever dossier each customer project requires.

A team uses Fire Arrow the way they would use a ready-made application backend, except that the data model, the access boundary, the audit log, and the regulatory shape are healthcare-specific from the start. We found that general-purpose backends give us tables, generic row-level security, and a job runner; the clinical model, the role-aware authorisation, the FHIR-shaped audit, and the regulatory artifacts were still on us to build. We wrote up that comparison in Fire Arrow vs building a custom healthcare backend and vs Supabase for healthcare. Fire Arrow takes the part that is the same across digital health products and ships it. The team’s work is the application above it.

Fire Arrow also ships the slice of clinical workflow that kept ending up in the backend on every project: CarePlan activities materialise into Task resources on a recurring schedule, transition as their due time arrives, and emit notifications for clients to act on. Clients fulfil the work or record fulfilment, decisions, and patient data through the FHIR API. This is not a general workflow engine; it is the workflow primitive any clinical product needs. The same primitive shows up in patient questionnaires, chronic disease management, and remote patient monitoring.

The same reasoning applies to AI. The model and the agent logic live above the backend. The groundwork required to deploy an agent safely on clinical data lives inside it: an access boundary at the data layer that an agent cannot bypass, industry-standard FHIR APIs the agent can be pointed at, and a data plane shaped for agentic access. That data plane includes durable and one-time API tokens scoped to FHIR identities, identity-attributable audit, and the retrieval surfaces the agent reads through: REST, GraphQL, FHIR Bulk Data, and SQL on FHIR. See AI agents on FHIR, healthcare RAG over FHIR, and MCP server for FHIR for the patterns we have built around this.

What Fire Arrow is not

Fire Arrow is not a clinical decision support system. Not a hospital information system. Not a radiology workstation. Not a practice management system. Not an EHR. Each of those is a product category in its own right, and each carries deep, category-specific code that does not transfer to the next one: image and diagnostic workflows for radiology, billing and coding and patient reminders for a practice system, guideline engines for decision support, longitudinal record management for an EHR. None of that complexity belongs in a backend that is meant to ship across all of them.

But: Fire Arrow makes it incredibly easy to build each of these products.

We distilled into Fire Arrow the part every one of these products had in common across every project we built: the FHIR data model, the access boundary, the audit, the integration shape, the workflow primitive, the regulatory dossier. A team building a radiology workstation, a practice system, or a decision support tool on Fire Arrow can move faster on the category-specific work because the foundation underneath is already built. The foundation ships with the product; the complexity that is unique to each category stays with the team that knows the category.

The boundary is intentional. A backend that tries to be the application as well is a backend that constrains the application’s shape. A backend that ships the data layer, with the workflow and AI primitives any clinical product needs, leaves the application free to be whatever the team needs.

What we believe about access boundaries

The most important architectural decision a healthcare backend makes is where the access boundary lives. We believe the boundary lives at the data layer. Not at the API gateway. Not at the application code. Not at the prompt of an AI agent. At the data layer, where every read and every write flow through, where the rules can be expressed once and enforced everywhere. We argued the case at length in The FHIR Authorization Tax and shipped it as the FHIR authorization and RBAC feature.

Fire Arrow’s own FHIR database expresses who can access which data under which circumstances. We decided not to model this with proprietary data structures that are opaque to other clients. This means that the relationships created in the FHIR data model itself now automatically also model the authorization relationships.

Boundaries that live elsewhere fail in predictable ways. Gateway boundaries fail when the gateway is bypassed by an internal service. Application-code boundaries fail when one of the dozen places that should check the rule forgets. Prompt boundaries fail when the agent’s input contains text that overrides the prompt. Data-layer boundaries fail only when the data layer itself fails: the failure mode every other layer also inherits.

The boundary at the data layer is the boundary that survives.

What we believe about FHIR

FHIR is the standard the industry has converged on for clinical data exchange. The convergence is not perfect (multiple versions, multiple profile families, multiple regional flavours) but it is closer to a single standard than any prior attempt. Building a backend around FHIR R4 from the start is a bet that the convergence continues, that the partners we will need to integrate with will be FHIR-shaped, and that the regulators we will need to satisfy will lean on FHIR for interoperability.

The bet has paid back faster than we expected. ISiK and KBV profiles in Germany, US Core in the United States, IPS internationally, the EHDS across the EU. Each of these is a profile against the same FHIR R4 base. A backend that stored patients as a custom schema would have to translate. A backend that stored patients as FHIR Patient resources just validates against the relevant profile. For the integration side of that bet, see Cerner / Oracle Health FHIR, Epic FHIR backend, and SMART on FHIR app launch.

Also our own work has benefitted a lot. Besides the technical headstart we have on every project, FHIR has unified our language around application-specific concepts. Whenever we discuss workflows and business concepts, we immediately know how to express it in FHIR and thus also immediately know how certain things will work under the hood and how they can be implemented, including all the boundary cases. We immediately know how to address common issues such as user management, role management, admin tasks, data storage, etc. because everything is now a series of battle-tested and proven designs based on common approaches with common data modeling. The grey area or window of uncertainty that exists in every development project now narrows down to a small fraction of the project and not its entirety as every developer needs to stay up-to-date with everybody else’s progress.

What we believe about compliance

Compliance is best treated as a property of the system rather than a project. A system produces most of a compliance package as a matter of course when its access boundary is enforceable, its audit log is identity-attributable, its configuration is in source control, its deployment is reproducible, and its backend supplier publishes versioned releases with change history and security advisories. A system that is none of these produces a compliance project the team has to mount before each audit. The Build vs Buy whitepaper has the cost model behind that point. The DiGA Technical Requirements Checklist and IEC 62304 and the Backend Layer whitepapers cover the artifacts that two of the most common framework dossiers actually want.

We built that discipline into the product because it is the same discipline every customer needs, and the same one every backend we wrote needed before this one. The dossier itself is still the customer’s submission; what we provide are the backend-layer inputs that feed it.

What we believe about AI

AI agents are a new kind of caller. They are not a special case in how the boundary treats them. They authenticate, they take an on-behalf-of identity, they call the backend through tools, and they produce audit records. The boundary at the data layer is the boundary that survives prompt injection because the prompt cannot override what the rule chain refuses to permit. We believe the AI access pattern fits the existing access boundary when that boundary lives at the data layer.

We have written more on this in the Agentic LLM Access and MCP for FHIR whitepapers.

Where the product goes next

Fire Arrow is a product, but it is also a working hypothesis: that the FHIR backend layer can be a commodity for digital health teams the way the database is a commodity for everything else. The teams we serve are not in the business of building FHIR backends. They are in the business of building digital health products. The backend is a means; the product is the end. If you want to read where the product fits in the wider landscape, our Compare hub puts Fire Arrow next to HAPI FHIR, Aidbox, Medplum, Azure Health Data Services, and the rest. The Glossary is the entry point if you are still mapping the FHIR vocabulary, starting with what is a FHIR backend and what is a FHIR server.

We will keep writing about the architectural decisions that go into the backend, the patterns that survive production loads, and the failure modes that show up when they do not. The Insights feed carries updates on our stance on FHIR and the digital health ecosystem. The docs changelog will publish release notes and our product change log as we continue to ship new versions.