Editions
Fire Arrow is available as Fire Arrow Core and Fire Arrow Server. Both provide the same authentication and authorization model. They differ in where data lives and how much infrastructure Fire Arrow manages for you.
Fire Arrow Core
Fire Arrow Core is a stateless facade that sits in front of an existing FHIR server. It intercepts client requests, authenticates them against any configured OIDC provider, resolves the caller's identity to a FHIR resource, enforces authorization rules, and forwards permitted requests to the upstream server.
Core does not store data. The FHIR server behind it — Azure Health Data Services, HAPI FHIR, or any FHIR R4-compliant server — remains the system of record. This makes Core a good fit for teams that already operate managed FHIR infrastructure and want to add authentication, authorization, and a GraphQL API with minimal additional hosting.
Operational profile: Docker container, 100–200 MB per instance, no database of its own. The managed FHIR service handles storage, scaling, backups, and security patches.
Fire Arrow Server
Fire Arrow Server is a self-contained FHIR backend. It includes its own FHIR data store (HAPI FHIR JPA + PostgreSQL), exposes both GraphQL and FHIR REST APIs under the same authorization layer, and adds server-side features that require control over the data layer: CarePlan scheduling, FHIR Subscriptions, API tokens, and a web administration UI.
Server is designed for teams that do not have — or do not want — a separately managed FHIR service. It handles data storage, authentication, authorization, workflow orchestration, and notifications in a single deployment.
Operational profile: Docker container + PostgreSQL, 2–4 GB per instance. The team is responsible for database maintenance, backups, and infrastructure management.
When to choose which
| Consideration | Fire Arrow Core | Fire Arrow Server |
|---|---|---|
| You already have a FHIR server | Adds auth + authz + GraphQL on top of existing infrastructure | Replaces the external FHIR server entirely |
| Ops capacity | Minimal — managed FHIR service handles storage and scaling | Higher — team manages PostgreSQL, backups, and upgrades |
| API access | GraphQL (read and write) | GraphQL (read) and FHIR REST (read and write), HFQL (SQL-like read), all under the same authorization rules |
| Server-side workflows | CarePlan scheduling, subscriptions, and API tokens must be handled by the client or external systems | Built-in CarePlan materialization, FHIR Subscriptions (REST hook, email, WebSocket, message queue), durable and one-time API tokens |
| Hosting constraints | Works with any FHIR R4 server, including cloud-managed services | Self-hosted; suitable when a managed FHIR service is not available or when data must stay on-premise |
Detailed Feature Comparison
API
| Feature | Fire Arrow Core | Fire Arrow Server |
|---|---|---|
| GraphQL | Yes (read and write). Forward references supported. No nested queries. Includes search modifiers in field values. | Yes (read only). Forward references supported. Nested queries supported. Uses _filter for search modifiers. |
| REST | Via direct server access, bypassing the authorisation layer | Yes, with full authorisation layer |
| Bundle processing | Via direct server access, bypassing the authorisation layer | Yes, with full authorisation processing for each individual resource inside the transaction |
| SQL on FHIR | Via direct server access, bypassing the authorisation layer (must be supported by the underlying FHIR server) | HFQL supported with full authorisation layer (beta) |
Authentication
| Feature | Fire Arrow Core | Fire Arrow Server |
|---|---|---|
| OAuth 2.0 / OIDC | Yes. OAuth flows against single audience. Pre-filtering against authentication-supplied scope / role not supported. | Yes. Full implementation that considers both scopes and roles in tokens, allowing per-auth-system control of interactive and automated clients. |
| Azure Identity | Yes | Yes |
| API tokens | No | Yes (durable and one-time tokens) |
Authorization
| Feature | Fire Arrow Core | Fire Arrow Server |
|---|---|---|
| Validators | Allowed, Forbidden, DeviceCompartment, PatientCompartment, PractitionerCompartment, RelatedPersonCompartment, GeneralPractitioner, OrganizationCompartment, LegitimateInterest. Compartment validators support one inclusion parameter per resource. | Allowed, Forbidden, DeviceCompartment, PatientCompartment, PractitionerCompartment, RelatedPersonCompartment, LegitimateInterest (includes Task), CareTeam. Compartment validators support the full FHIR R4 compartment inclusion criteria. OrganizationCompartment and GeneralPractitioner to be added later. |
| Multiple rules per role / resource pair | Only one validator may exist per client role / target resource pair. Multiple roles are supported for Practitioner clients via LegitimateInterest only. Rules are exclusive. | Multiple validators may exist for the same client role / target resource pair. Rules are additive. For example, a practitioner can be either a general practitioner or an HCP in the patient's managing organisation, and resource access will be validated via both routes simultaneously. |
| Identity filters (restricting rules to a specific client identity) | No | Yes. Conditional application of rules within a client role using FHIRPath expressions on the identity resource. |
| Property filters (automatic anonymization / restriction of resource values on property level) | Through webhook filter chains | Yes, directly supported via validation rules. Includes search parameter blocking to prevent data leakage through search probing. |
| Custom webhooks (for custom validation rules or additional filtering) | Yes. Supports post-validation, pre-request, post-request, and pre-response hooks to add custom business logic (custom validators or custom response scraping / enhancements). | Not supported |
| Identity resource protection | Validators prevent impersonation attempts (changing identity credentials) | Validators prevent impersonation attempts. Optionally protects against identity resource duplication (prevents client lock-out). |
| Rule debugger | No | Yes. Detailed diagnostics on denied requests via X-Fire-Arrow-Debug header. |
Features
| Feature | Fire Arrow Core | Fire Arrow Server |
|---|---|---|
| Web UI | No | Yes |
| Subscriptions | As provided by the underlying FHIR service (e.g. Azure Health Data Services sends change events to Event Grid) | Yes (REST hook, email, websocket, Azure Storage Queue) |
| CarePlan expansion into Tasks | Must be performed by client | Fully supported server-side |
| Dynamic CarePlan schedule updates based on Task completion | Must be performed by client | Fully supported server-side |
| PlanDefinition $apply | Yes (limited, opinionated implementation) | Yes (enhanced, with timezone support and extension propagation) |
| Binary file storage | Azure Blob, S3 | Azure Blob |