Editions
Fire Arrow exists in two editions: Fire Arrow Core and Fire Arrow Server. They both achieve the same goal with nearly the same API, but their target use cases are different.
-
Fire Arrow Core is a lightweight facade that attaches itself to an existing or managed FHIR infrastructure. It integrates easily into any FHIR-based architecture and is targeted primarily at startups. It is perfect while products undergo clinical studies, as it requires zero maintenance and minimal engineering headcount.
-
Fire Arrow Server is an opinionated implementation of an entire FHIR server, based on the open-source HAPI FHIR project. It allows more complex setups such as on-premise hosting and features powerful workflow and administration capabilities that otherwise are only available in separate client applications. It requires a higher level of infrastructure to host, and the deploying team needs to account for maintenance and security.
Architecture
Fire Arrow Core
Facade in front of a FHIR server. Designed for Azure Health Data Services, but compatible with any FHIR-compliant server. Use it together with a managed FHIR service for a low-ops, pre-certified setup.
- Data storage: Delegated to external FHIR server
- Deployment: Docker container
Fire Arrow Server
Fully integrated FHIR server. Designed for applications where a separately managed FHIR service is not available (due to hosting constraints), where faster response times matter, and the additional administration overhead is acceptable.
- Data storage: Integrated PostgreSQL database
- Deployment: Docker container
Which Edition Should I Choose?
| Fire Arrow Core | Fire Arrow Server | |
|---|---|---|
| Target use case | Optimised for low ops, low cost. Perfect for startups with few resources. Digital health apps, study companions, etc. | Applications with larger scale requirements, faster response times, or on-premise hosting needs (e.g. hosting outside of US-owned hyperscalers). |
| Infrastructure size | Works on a minimal Docker setup with 100MB-200MB per instance. | Needs PostgreSQL service and at least 2GB-4GB per instance. |
| Ops overhead | Minimal -- the managed FHIR service handles storage, scaling, and security patches | Higher -- team must account for PostgreSQL maintenance, backups, security updates, and infrastructure management |
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 |
| 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 |