Fire Arrow vs custom backend
Fire Arrow vs writing your own healthcare backend
Writing a healthcare backend from scratch is a real choice and gives full control over every layer. It also means designing the clinical data model from first principles, building the authentication and authorisation layer, closing search side channels in every query path, building scheduling, notifications, audit, and an admin surface, and keeping the result aligned with the regulatory vocabulary the customer will be measured against. Fire Arrow Server starts from FHIR R4, a curated clinical data model with decades of field experience, and bundles the application backend layer that would otherwise be on the team's plate. The Postgres database and the Docker container shape are familiar; the difference is which part of the stack the team is paid to write.
What is on the team's plate when the backend is custom
- Designing the clinical data model
Patient, Practitioner, Encounter, Observation, MedicationRequest, CarePlan, Task, QuestionnaireResponse, Subscription, AuditEvent. FHIR has spent close to two decades shaping these. A custom schema starts that work over, in less time, with less domain feedback.
- Authentication and identity-to-data mapping
OAuth or OIDC with one or more identity providers, token validation, and a mapping from the authenticated subject to the data record they represent (the patient, the clinician, the organisation member). The mapping is the part that has to stay correct on every request.
- Fine-grained, relationship-aware authorisation
Patients see their own data. Clinicians see their organisation's data. Care teams cross organisational boundaries. Sponsors see redacted views. Rules combine role, resource type, operation, and the relationship between the caller and the record. Implementing this consistently across every endpoint is where most of the time goes.
- Closing search side channels
Hiding a field on a response is not enough if a client can probe the same field through search, sort orders, includes, or filter expressions. Every query path needs the same access narrowing, and every new search parameter is a potential leak that has to be reviewed.
- Scheduling, notifications, and audit
Recurring care plans need a scheduler that materialises tasks at their due time. Real-time integrations need a subscription or change-event pipeline. Compliance needs an audit log against the resolved user identity for every read and write. Each of these is a service of its own, with its own failure modes.
- Admin tooling and debug surfaces
Inspecting records, debugging why a request was denied, browsing relationships, replaying events. A custom backend either invests in this tooling or pays the cost in support tickets and incident response time.
- Keeping aligned with FHIR-shaped regulations
The US Cures Act, the EU European Health Data Space, ONC interoperability rules, HIPAA Right of Access, and the EU MDR for clinical software all reference or assume FHIR. A non-FHIR backend keeps a translation layer that has to be maintained as those frameworks evolve.
- Schema migrations as the product evolves
Every clinical feature added later (new resource type, new field, new relationship) becomes a database migration, an API change, an authorisation rule update, and an integration ripple. FHIR resources absorb most of this through Extensions and references that already exist in the standard.
Who this is for
Engineering leaders, CTOs, and architects considering whether to build a healthcare backend from scratch, fork an open-source FHIR server, or run Fire Arrow Server.
Clinical applicability
A remote-monitoring product whose primary data is QuestionnaireResponses, Observations, CarePlans, and Tasks fits the FHIR resource model directly. The same authorisation rules then cover patients, clinicians, organisations, and care teams. Building the equivalent in a custom backend means designing the schema, the access rules, and the integration surface for each of those audiences from scratch.
Capability comparison
What writing your own backend actually involves
A healthcare backend is more than a database and an API. It is a clinical data model, an authentication layer, an authorisation layer that respects clinical relationships, search narrowing applied at every query path, a scheduling engine for recurring care, a notification pipeline for downstream consumers, an audit log against resolved user identities, an admin surface, and a debug surface. Each of those is a service in its own right.
Writing all of them is possible. Teams have done it. The cost is real: most of the engineering budget for the first year goes to building infrastructure that does not directly differentiate the product, and the layers that do differentiate it (the workflows, the clinical insight, the user experience) wait their turn.
The data model is the hidden iceberg
The visible part of the data model is the small set of resources the first feature needs: Patient, Observation, maybe CarePlan. The hidden part is everything that connects to those: Encounter for visit context, Condition for clinical reasoning, MedicationRequest for prescribing, ServiceRequest for orders, Task for assigned work, QuestionnaireResponse for patient input, AuditEvent for compliance, AllergyIntolerance, Immunization, DocumentReference. Each one carries field-level shape, search parameters, and references to the others.
FHIR has spent close to two decades shaping this set. Every field carries the residue of feedback from clinics, EHR vendors, regulators, and standards bodies. A custom schema starts that work over with less time, less domain feedback, and a smaller cohort of users to surface edge cases. The schema that ships in the first release is rarely the schema that fits the third release; the gap shows up as migrations.
Authorisation is where most healthcare backend bugs live
Public security incidents in healthcare backends concentrate in a small band of failure modes. A search endpoint that returns more rows than it should because the row-level filter was missed for one role. A GraphQL resolver that bypasses the REST authorisation interceptor. A property hidden from the response but reachable through a sort order or an include. A role check coded into the application layer instead of the data layer, so a new endpoint forgets to call it.
These are not exotic bugs. They are the predictable result of expressing the same access rule in many places, in many languages, across many endpoints. The defensive pattern is to express the rule once at the data boundary and apply it at query time across every access path. Fire Arrow's authorisation rules live at the data boundary and apply to REST, GraphQL, and SQL-on-FHIR through the same evaluator. A custom backend has to implement the same pattern by hand and keep it consistent as the API surface grows.
Regulatory alignment is largely about being FHIR-shaped
The frameworks a healthcare product is measured against now reference FHIR explicitly. The US Cures Act and ONC interoperability rules require FHIR R4 APIs for patient access. The EU European Health Data Space (EHDS) is built around FHIR-shaped patient summaries and exchange formats. HIPAA Right of Access requests are typically served through FHIR APIs. EU MDR documentation for clinical software references interoperability standards that themselves reference FHIR.
A FHIR-shaped backend reaches these requirements as a property of its data model. A custom backend reaches them through a translation layer that has to be designed, built, validated, and maintained as the regulations evolve. Both paths are achievable; only one of them keeps the regulatory work largely incidental to product development.
The configure-not-code split
Fire Arrow Server is configuration-shaped. Authorisation rules, scheduling definitions, subscription channels, identity providers, and property filters are configuration files reviewed in pull requests rather than Java or Python code reviewed for correctness. The infrastructure layer is Fire Arrow's to maintain, regression-test, and document.
What the product team writes is the product: the clinical workflows, the patient experience, the analytics, the integrations that differentiate the offering. The backend layer that every healthcare product needs is shared with the rest of Fire Arrow's customer base, which is also where most of the field-tested fixes come from.
When writing your own still makes sense
There are real cases for a custom backend. The clearest is when the operational data model is intentionally not clinical: a payments-led product, an internal scheduling tool, a content platform that touches FHIR only at integration boundaries. Building those on FHIR resources is awkward and adds little.
The next case is when the team has the capacity, the time, and the appetite to own the infrastructure layer end-to-end as a deliberate engineering investment, with FHIR as a translation surface at the edge. This is a defensible position when infrastructure ownership is part of the product story (a research platform with bespoke storage requirements, a backend that has to interoperate with non-FHIR legacy systems at its core).
Most digital health products fall outside both of these. The data is clinical, the team has finite capacity, and the differentiators are in the workflow and the user experience. For that shape of product, configuring an existing backend is the lower-cost path.
FAQ
Is building it ourselves cheaper than running Fire Arrow?
Direct cash cost can look lower at the start because there is no licence line item. The full cost is the engineering capacity spent on schema design, authentication, authorisation, search narrowing, scheduling, subscriptions, audit, admin tooling, debug tooling, and regulatory alignment, plus the ongoing cost of maintaining all of it. For most digital health teams the comparison comes out the other way once a year of building has gone by, and the time-to-first-clinical-feature is markedly shorter on the configured path.
What if our product needs fields FHIR does not have?
FHIR is intentionally extensible. Use Extensions on standard resources for additional fields, define a custom resource through an implementation guide where a new type is genuinely needed, or carry product-specific data on Fire Arrow custom resource paths. The standard resource model is the starting point, not a ceiling.
Is FHIR overkill for an MVP?
Not in the cases where the data is clinical. The cost of learning the half-dozen FHIR resources an MVP touches is usually lower than the cost of designing the equivalent custom schema, and the schema cost grows over time while the FHIR-learning cost is paid once.
How long does a custom authorisation layer typically take to get right?
The first version usually ships in a few weeks. The version that consistently survives a security review, with search narrowing across every access path, identity-to-data mapping for every role, side-channel protection on every search parameter, and an audit trail that holds up under cross-examination, takes considerably longer. The last 20% of correctness is where the time concentrates, and where the bugs that show up in incidents tend to live.
Can we adopt Fire Arrow incrementally on top of a partial custom backend?
Yes. A common pattern is to move the FHIR-shaped data into Fire Arrow Server first (clinical resources, scheduling, subscriptions) while non-clinical data stays in the existing backend. Fire Arrow Core can also sit in front of an existing FHIR R4 service if one is already in place. The migration does not have to be all-or-nothing.
Our team has FHIR experience and prefers writing code. Why not build it?
The question is what the team's time is worth most on. Building the authorisation, search, scheduling, subscription, and admin layers is a known body of work that has been built many times before. A team with FHIR experience usually applies that experience to the product layer (clinical workflows, integrations, analytics) and lets the configured backend cover the parts that are the same across every healthcare product.
What is the cost of changing the data model later?
On a FHIR-shaped backend, most field-level changes are FHIR Extensions, which do not require schema migrations and do not break existing clients. New resource types are configuration changes. On a custom backend, the same changes are migrations, API revisions, and authorisation updates, and the cost compounds as the model grows.
What about teams that want to fork HAPI FHIR instead of building from scratch?
Forking HAPI is a smaller version of the same trade-off: the FHIR data layer comes for free, but the application backend layer (authentication, fine-grained authorisation, search narrowing across REST and GraphQL, scheduling, subscriptions, admin UI) is still on the team's plate. Fire Arrow Server uses upstream HAPI FHIR JPA as its data layer and adds those layers on top, which means a team can keep HAPI as the foundation and stop maintaining the application backend layer in-house.
