Skip to main content

About Fire Arrow

The problem​

A FHIR server gives you interoperable storage for health data. Building a digital health application on top of it requires significantly more: authentication, fine-grained access control, modern client APIs, workflow orchestration, and real-time notifications. FHIR servers leave all of this to application code.

Digital health developers typically face two options. They can start from a raw FHIR server and build every layer themselves — identity management, authorization logic, API gateways, scheduling infrastructure. Or they can adopt hospital-scale clinical systems that were designed for large institutions, not for focused digital health products.

Why FHIR​

Platforms like Firebase and Supabase are effective backends for general-purpose applications. Healthcare applications have different requirements, and FHIR addresses them at the data model and API level.

No data modeling required. FHIR defines a comprehensive set of resource types — Patient, Observation, Condition, MedicationRequest, CarePlan, and over a hundred others — each with a standardized structure. This eliminates the need to design a custom data model for health data. The model encodes decades of real-world clinical data management experience, which means edge cases and structural decisions that would otherwise surface months into development are already accounted for. It also removes one of the common reasons for database migrations: schema evolution driven by data modeling changes.

No API versioning. FHIR defines both the data model and the API. Read, search, create, update, and delete operations follow a single specification. There is no need to design, document, or maintain versioned API endpoints (v1, v2, v3). The API contract is the FHIR specification itself, and client libraries exist for most platforms.

Interoperability with the health ecosystem. EHRs (Epic, Oracle Health), national health exchanges, laboratory systems, and insurance platforms increasingly expose FHIR APIs. An application with a FHIR-native data model can consume and produce data in the format these systems already use. An application built on a custom schema requires a translation layer for every external integration — and those layers accumulate over the lifetime of the product.

Regulatory alignment. In the US, the 21st Century Cures Act and ONC certification rules require FHIR-based APIs for health data exchange. In the EU, the European Health Data Space regulation (EU 2025/327) mandates interoperable EHR systems, with HL7 FHIR as the technical foundation for the European Electronic Health Record Exchange Format. Building on FHIR means the application's data layer is already aligned with these requirements.

Patient data portability. Patients have legal rights to access and transfer their health data in both the US and the EU. FHIR data is portable by design — any compliant system can read it. Data stored in a custom schema requires extraction and format conversion to satisfy portability requests, with no guarantee that clinical semantics are preserved in the translation.

Domain-specific access control patterns. Healthcare access control follows patterns that are specific to the domain: a patient sees their own records, a practitioner sees records for patients at their organization, a caregiver sees a subset of a family member's data. These patterns map directly to FHIR's compartment model and resource relationships. General-purpose backends provide generic authorization mechanisms (document-level rules, row-level security) that can technically implement these patterns, but the developer must design the mapping between clinical relationships and database-level permissions without a standard to validate against. FHIR provides that standard.

What Fire Arrow does​

Fire Arrow is a FHIR backend and application platform for regulated digital health products. It includes a production-ready FHIR server, FHIR-native authorization, GraphQL, subscriptions, CarePlan automation, anonymization, and deployment support.

It occupies the same role in the healthcare domain that platforms like Firebase or Supabase occupy for general-purpose applications: it takes a standards-based data layer and adds the infrastructure that application developers actually need.

Concretely, Fire Arrow adds the following on top of a FHIR data store:

  • Vendor-neutral authentication. Any OAuth 2.0 / OpenID Connect provider works out of the box. Fire Arrow maps OAuth tokens to FHIR identity resources (Patient, Practitioner, RelatedPerson, Device), so your security model lives in FHIR — not in a proprietary user database. You can switch identity providers without changing your application or data model.

  • FHIR-native authorization. Access control rules are expressed in terms of FHIR compartments and resource relationships. A patient sees their own data. A practitioner sees data for patients in their organization. A study sponsor sees anonymized records. These rules are defined in a single configuration file and enforced consistently across all API surfaces — no separate ACL system, no per-endpoint authorization code.

  • Modern APIs. GraphQL and FHIR REST are available side by side, both subject to the same authorization rules. Mobile and web clients can use GraphQL for efficient data fetching; backend integrations can use FHIR REST for standards-based interoperability.

  • CarePlan orchestration (Fire Arrow Server). Care plans with recurring activities — daily medication reminders, weekly assessments, monthly check-ins — are automatically materialized into individual Task resources. The server manages the timeline, transitions tasks to "ready" when they become due, and notifies your application via subscriptions. No custom scheduling infrastructure required.

  • Real-time subscriptions (Fire Arrow Server). FHIR Subscriptions deliver change notifications over REST hooks, email, WebSocket, or message queues. Combined with CarePlan events, this provides a complete push notification pipeline without external job runners.

  • Extensibility. Webhooks, custom operations, and property filters allow you to add business logic, integrate external systems, or transform FHIR responses without modifying the core. Fire Arrow Core supports pre-request, post-request, and pre-response hooks. Fire Arrow Server supports identity filters, property filters for automatic data anonymization, and API tokens for programmatic access.

The result is a backend that handles authentication, authorization, data storage, workflow scheduling, and notifications — the same concerns that any digital health application needs — so that application developers can focus on the clinical workflows and user experience specific to their product.

Editions​

Fire Arrow is available in two editions.

Fire Arrow Core is a lightweight facade that sits in front of an existing FHIR server (such as Azure Health Data Services). It adds authentication, authorization, and a GraphQL API while delegating data storage to the upstream server. Core is designed for teams that want to use managed FHIR infrastructure and minimize operational overhead.

Learn more about Fire Arrow Core

Fire Arrow Server is a self-contained FHIR backend with an integrated data store (HAPI FHIR + PostgreSQL), FHIR REST API, server-side CarePlan scheduling, subscriptions, API tokens, binary storage, and a web administration UI. Server is designed for teams that need a complete backend in a single deployment.

Learn more about Fire Arrow Server

For a detailed comparison of features, see the Editions comparison.