Why We Built Fire Arrow

The repeated pattern

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 from the first byte. The access boundary is a default-deny rule chain that evaluates at the data layer. The audit log records every authorised request with the resolved identity. The standard integrations ship with the product because every backend we built had to support them: the FHIR REST surface, 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. General-purpose backends give you tables, generic row-level security, and a job runner; the clinical model, the role-aware authorisation, the FHIR-shaped audit, and the regulatory artifacts are still on you to build. 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 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.

What we are not

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.

What we distilled into Fire Arrow is the part every one of those 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.

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.

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.

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.

The shape of the road ahead

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.

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 blog will publish release notes and our product change log as we continue to ship new versions.