Fire Arrow on Azure
Fire Arrow and Azure Health Data Services
Fire Arrow is built with Azure as a primary target. Fire Arrow Core extends Azure Health Data Services by adding the application backend layer in front of it. Fire Arrow Server replaces Azure Health Data Services with a self-contained FHIR backend that runs on Azure, using Azure Database for PostgreSQL for storage, Azure Blob Storage for binary files, and Azure Storage Queue for change notifications.
Two ways Fire Arrow runs on Azure
- Fire Arrow Core in front of Azure Health Data Services
Core authenticates incoming requests against Microsoft Entra ID or any other OIDC provider, resolves the caller to a FHIR identity, applies the configured authorisation rules, and forwards permitted requests to Azure Health Data Services over standard FHIR REST. Microsoft keeps operating the FHIR store; Core adds the authorisation boundary and the GraphQL surface in front of it.
- Fire Arrow Server as a self-contained backend on Azure
Server runs as a Docker container on Azure (App Service, Container Apps, AKS) with Azure Database for PostgreSQL as its data layer. The FHIR REST API, GraphQL endpoint, authorisation layer, CarePlan scheduler, subscription channels, API token model, and web admin UI sit in the same deployment.
- Native Azure Identity authentication
Both editions integrate with Microsoft Entra ID out of the box. Tokens issued by Entra map to Patient, Practitioner, RelatedPerson, or Device identity resources, and the same authorisation rules apply regardless of how the user signed in.
- Azure Storage Queue for change notifications
Fire Arrow Server publishes FHIR Subscription events directly to Azure Storage Queue. Downstream Azure Functions, Logic Apps, or container workloads can consume them with the same patterns Azure-native teams already use.
- Azure Blob Storage for binary files
Both editions can store binary attachments in Azure Blob Storage. Fire Arrow Server returns time-limited pre-signed URLs so clients download directly from Blob Storage without proxying through the FHIR server, while the FHIR resource only carries an opaque reference.
- Microsoft FHIR server compatibility
Fire Arrow Core is built around Microsoft's open-source FHIR server, the same FHIR engine that powers Azure Health Data Services, so the same connector handles managed Azure Health Data Services and self-hosted Microsoft FHIR server deployments.
Who this is for
Azure-native healthcare teams that already use, or plan to use, Azure Health Data Services and need authentication, fine-grained authorisation, a GraphQL API, and operational tooling around their FHIR data.
Clinical applicability
An Azure-native team can keep PHI in Azure Health Data Services with Microsoft handling storage, scaling, and patching, and add Fire Arrow Core in front to enforce patient and clinician access rules and expose a GraphQL API to client apps. A team that wants the application backend (scheduling, subscriptions, admin UI, API tokens) inside its own deployment can run Fire Arrow Server on Azure with Azure Database for PostgreSQL and the same Azure Blob and Azure Storage Queue integrations.
Capability comparison
Two ways Fire Arrow runs on Azure
Fire Arrow has two editions, and both target Azure as a first-class environment. Fire Arrow Core extends Azure Health Data Services by adding authentication, FHIR-native authorisation, and a GraphQL API in front of it. Fire Arrow Server replaces Azure Health Data Services with a self-contained FHIR backend that runs on Azure infrastructure.
The choice between them is mostly a question of where the FHIR data lives and how much of the application backend should sit inside Microsoft's managed surface. Core keeps Azure Health Data Services as the system of record and adds the layer above it. Server bundles the FHIR data layer with the application backend and runs against Azure Database for PostgreSQL.
Fire Arrow Core in front of Azure Health Data Services
Fire Arrow Core is a stateless Docker container, around 100 to 200 MB resident memory per instance, with no database of its own. It authenticates requests against Microsoft Entra ID (or another configured OIDC provider), resolves the caller's identity to a FHIR resource (Patient, Practitioner, RelatedPerson, or Device), evaluates the configured authorisation rules, and forwards permitted requests to Azure Health Data Services over standard FHIR REST.
Microsoft remains responsible for storage, scaling, backups, and patching of the FHIR service. Core contributes the authorisation boundary and a GraphQL endpoint that supports both reads and writes. Pre-request, post-request, and pre-response hooks let you add custom validators or enrich responses without modifying the upstream service.
Core targets Microsoft's FHIR server, the open-source FHIR engine that also powers Azure Health Data Services. The same Core deployment works against the managed Azure Health Data Services workspace and against a self-hosted Microsoft FHIR server, so development, staging, and production can use whichever option fits the environment.
Fire Arrow Server as the FHIR backend on Azure
Fire Arrow Server is a self-contained backend. The natural Azure deployment runs Server as a Docker container (on Azure App Service, Azure Container Apps, or AKS) in front of Azure Database for PostgreSQL. The FHIR REST API, GraphQL endpoint, authorisation layer, scheduling engine, subscription channels, API token model, and web admin UI all run inside the same deployment, against the same database.
Server uses HAPI FHIR JPA as its data layer, so the FHIR semantics and the Postgres schema are HAPI's. Operationally, the database is a managed Azure Postgres instance: Microsoft handles host-level patching, backups, geo-redundancy, and read replicas; the customer keeps control of the FHIR application surface.
Server is the right edition when the team wants to consolidate the FHIR data layer and the application backend in one deployment, when scheduling, subscriptions, API tokens, or the admin UI are needed, or when the data residency and operational ownership profile of a managed FHIR service do not fit.
Azure-native integrations
Both editions support Microsoft Entra ID authentication out of the box. Tokens issued by Entra map to FHIR identity resources, and the authorisation rules treat Entra-authenticated users the same as users signed in through any other OIDC provider.
Fire Arrow Server publishes FHIR Subscription events directly to Azure Storage Queue. Azure Health Data Services publishes change events to Azure Event Grid, which can in turn route them to Azure Storage Queue or other destinations; on Fire Arrow Server the same Storage Queue destination is reachable as a built-in Subscription channel without an Event Grid hop. REST hook, email, and WebSocket channels are also available on Server.
Binary attachments live in Azure Blob Storage. The FHIR resource carries an opaque reference and Fire Arrow Server returns a time-limited pre-signed URL when the resource is read, so clients download directly from Azure Blob without proxying through the FHIR server. The blob lifecycle follows the FHIR resource: deleting the resource deletes the attachment.
Choosing between Core and Server on Azure
Fire Arrow Core fits when keeping Azure Health Data Services as the FHIR system of record is a deliberate choice (existing investment in Azure Health Data Services, regulatory or contractual reasons to keep PHI in a Microsoft-managed service, or a strong preference for managed FHIR). Core adds authentication, authorisation, and GraphQL on top with a small operational footprint and no separate database.
Fire Arrow Server fits when the team wants the FHIR data layer inside its own deployment, when the application backend features (CarePlan scheduling, FHIR Subscriptions, API tokens, admin UI) are required, or when the cost or operational profile of the managed service does not fit. Both editions speak FHIR R4, so a starting decision in one direction does not lock the architecture out of the other.
Related docs
FAQ
Is Fire Arrow an Azure Marketplace extension?
No. Fire Arrow Core and Fire Arrow Server are deployable Docker containers that run in your Azure subscription (or any other environment) and connect to Azure Health Data Services or Azure Database for PostgreSQL like any other workload.
Does Fire Arrow Core replace Azure Health Data Services?
No. Fire Arrow Core sits in front of Azure Health Data Services and adds the application backend layer (authentication, authorisation, GraphQL). Azure Health Data Services remains the FHIR system of record. Fire Arrow Server is the edition that replaces the managed FHIR service with a self-contained backend on Azure Database for PostgreSQL.
Can Fire Arrow use Microsoft Entra ID directly?
Yes. Both editions authenticate users via Microsoft Entra ID, and Azure Identity (managed identities, service principals) is supported for inter-service authentication and for connecting Server to its Azure dependencies.
How do change notifications compare?
Fire Arrow Server publishes Subscription events directly to Azure Storage Queue, alongside REST hook, email, and WebSocket channels. Azure Health Data Services publishes change events to Azure Event Grid, and Event Grid can route them to Azure Storage Queue or other destinations. The downstream consumer pattern is similar; the publication path is shorter on Fire Arrow Server.
How are binary files handled?
Both editions can store binary attachments in Azure Blob Storage. Fire Arrow Server returns time-limited pre-signed URLs so clients download directly from Blob Storage; the FHIR resource carries only an opaque reference, and the blob lifecycle follows the resource (deleting the resource deletes the attachment).
Can I move from Azure Health Data Services to Fire Arrow Server later?
Yes. Both speak FHIR R4. A FHIR Bulk Export from Azure Health Data Services followed by a FHIR import into Fire Arrow Server moves the data over losslessly. Starting with Fire Arrow Core in front of Azure Health Data Services and migrating to Fire Arrow Server later keeps the application code unchanged on the GraphQL side, since the GraphQL surface is provided by Fire Arrow in either case.
What does a typical Azure deployment look like?
Fire Arrow Core: Docker container on Azure App Service or Azure Container Apps, with Microsoft Entra ID for authentication and Azure Health Data Services as the upstream FHIR server. Fire Arrow Server: Docker container on Azure App Service, Azure Container Apps, or AKS, plus Azure Database for PostgreSQL for storage, Azure Blob Storage for binaries, Azure Storage Queue for Subscription events, and Microsoft Entra ID for authentication.
