Fire Arrow and Aidbox

Two FHIR backends with different scopes

Aidbox and Fire Arrow Server occupy overlapping but distinct points in the FHIR backend space. Both run as self-contained services on PostgreSQL, both expose FHIR REST and additional read surfaces (GraphQL, SQL-on-FHIR), and both can be the system of record for a digital health product. The difference is scope.

Aidbox is a FHIR-first platform: terminology services, Implementation Guide management, multi-version FHIR, structured data capture forms, patient matching, and SDKs in three languages, all bundled in one product. The breadth makes it a strong fit for healthcare data platforms, clinical data repositories, and applications that need terminology, profiling, or analytics depth alongside the FHIR API.

Fire Arrow Server is narrower. It is a FHIR R4 backend focused on the application-facing layer: authorisation tuned to clinical relationships, GraphQL with the same access boundary as REST, server-side CarePlan-to-Task scheduling, FHIR Subscriptions, durable and one-time API tokens, and a rule debugger. Terminology workloads are handled by a service such as Snowstorm Lite or Snowstorm running alongside it. There is no IG management UI, no SDC form renderer, and no patient matching engine. For digital health products that primarily need a FHIR API with a strong authorisation and workflow layer, the smaller surface is the point.

Architecture and storage

Aidbox is built in Clojure on top of PostgreSQL. The storage layer is a custom JSONB layout with Health-Samurai-managed indexes and PostgreSQL extensions, tuned for FHIR query patterns. Aidbox publishes performance figures in the range of 20,000 resources per second on bulk import and several thousand requests per second on CRUD against multi-million-record datasets.

Fire Arrow Server is built in Java on Spring Boot, with HAPI FHIR JPA as its data layer and PostgreSQL underneath. The schema is HAPI's standard JPA schema. The trade-off is straightforward: Aidbox can tune its storage tier in ways HAPI cannot; Fire Arrow inherits HAPI's open-source data layer, which keeps the storage tier portable to any other HAPI-based deployment.

Authorisation models compared

Aidbox's AccessPolicy model is configurable through several evaluation engines. Matcho is a declarative pattern-matching syntax intended for the common cases. JSON Schema validates the request object. SQL embeds raw queries against the underlying database. Complex combines engines with AND and OR. Policies can link to User, Client, or Operation resources, and any number of policies can apply to a request: the request is authorised as soon as one of them passes. The flexibility is real, and so is the responsibility on the policy author to keep the rule set consistent across access paths.

Fire Arrow's authorisation is a constrained model. Each rule combines a role, a resource type, an operation, and a validator. Validators cover the standard FHIR compartments (Patient, Practitioner, RelatedPerson, Device), an organisation-scoped legitimate-interest rule, and a care-team membership rule. Identity-conditional rules narrow a rule to a subset of users in a role using FHIRPath expressions on the caller's identity resource. Property filters strip fields per role with explicit blocked-search-parameter lists to close the indirect-inference paths. The rule set is deny by default, and a debug header returns a structured trace of which rule matched and why a request was denied.

Both models can express the same access patterns at the bottom; they differ in shape. Aidbox's surface is power-first. Fire Arrow's surface is constraint-first, designed so the same configuration can be reviewed by a non-developer (an information security officer, a compliance reviewer) and traced top to bottom without reading SQL.

Where each goes deeper

Aidbox goes deeper on FHIR-data tooling: a built-in terminology server with ICD-10, SNOMED, and LOINC; an Artifact Registry that loads Implementation Guides at runtime; custom resource definitions through FHIR Schema or StructureDefinition; SQL-on-FHIR with materialised views; multi-FHIR-version support; multi-tenancy in two flavours (Organization-scoped or fully separate databases via Multibox); a Form Builder UI and SDC form renderer; SDKs in TypeScript, Python, and C#. The model is platform-shaped: customers extend Aidbox by writing code against it.

Fire Arrow Server goes deeper on the application backend layer: identity-aware authorisation rules tied to FHIR identity resources (Patient, Practitioner, RelatedPerson, Device); search narrowing applied at query time across REST, GraphQL, and SQL-on-FHIR; server-side CarePlan-to-Task materialisation that schedules Questionnaires to patients and stores their answers as standard QuestionnaireResponse resources; subscription channels including a direct Azure Storage Queue integration; durable and one-time API tokens tied to FHIR identities; a rule debugger that explains denied requests. Terminology workloads are delegated to a service such as Snowstorm Lite or Snowstorm running next to Fire Arrow Server. The model is product-shaped: customers configure Fire Arrow rather than writing SDK code against it.

Migration paths

Both servers implement the FHIR Bulk Data Access specification. The straightforward migration path between Aidbox and Fire Arrow Server, in either direction, is a FHIR Bulk Export from the source followed by a FHIR import into the target. The data moves over losslessly because both ends speak FHIR R4 with the same resource semantics. Implementation Guides, ValueSets, and CodeSystems used by the application are FHIR resources too and are exported alongside the rest.

Workflow primitives that are server-side on Fire Arrow (CarePlan-to-Task scheduling) but external on Aidbox (or vice versa) are configured rather than migrated: the underlying FHIR resources move with the rest of the data, and the scheduling or background-job configuration is reapplied on the destination side.

Fire Arrow Core does not target Aidbox. Core is built around Microsoft's open-source FHIR server, the same engine that powers Azure Health Data Services, and the connector model assumes that surface. Running Core in front of Aidbox is technically possible against the FHIR REST endpoint, but Aidbox already includes its own authentication, authorisation, and an admin UI, so the practical fit is limited.

When to choose which

Choose Aidbox when the platform is the product. A clinical data repository, a healthcare data platform serving multiple downstream applications, an interoperability hub, an EHR backend that needs runtime IG loading, terminology binding validation, multi-FHIR-version support, or a multi-tenant SaaS with strict per-tenant data isolation lives most comfortably on a broad FHIR platform. The breadth, the SDK story, and the managed cloud option are direct fits for that shape of work.

Choose Fire Arrow Server when the application is the product. A digital health product with patient, practitioner, and sponsor roles; a remote-monitoring or ePRO programme that needs scheduled patient questionnaires; an internal clinical workflow with CareTeams and organisation scoping; an AI-agent product that uses the FHIR backend as the authorisation boundary. The depth is in the application layer, the configuration is reviewable end to end, and HAPI underneath keeps the data layer portable.

Both servers can do most of what the other does. The choice is about which side of the stack should be the deepest part of the product.

FAQ