Fire Arrow Server
FHIR Server for Digital Health Applications
Fire Arrow Server is the self-contained edition. One Docker container, one PostgreSQL database, FHIR REST and GraphQL behind the same authorization layer, and the workflow primitives a digital health product needs around them.
Who this is for
Teams that need to run their own FHIR backend instead of using a managed FHIR service.
Clinical applicability
A patient and clinician application can write FHIR resources through REST, read dashboard data through GraphQL, materialize PHQ-9 questionnaires from a CarePlan into Task resources, and notify the mobile client through a WebSocket subscription, all in one deployment.
What is in the deployment
A Java service built on HAPI FHIR JPA, packaged as a Docker container of around 2-4 GB resident memory per instance. PostgreSQL alongside. A web admin UI for inspecting resources, running ad-hoc GraphQL queries, browsing audit data, and managing tokens. Optional Azure Blob Storage integration for binary content. Configuration is a single `application.yaml` file.
FHIR REST, GraphQL (read-only), HFQL (SQL-on-FHIR, beta), and FHIR Subscriptions with REST hook, email, WebSocket, and Azure Storage Queue channels. Server-side CarePlan-to-Task materialization with a configurable scheduling horizon. Durable and one-time API tokens for service accounts.
Authorization at the server layer
Rules combine `client-role`, `resource`, and `operation` and delegate to a validator. The full set of validators on Server includes `Allowed`, `Forbidden`, `PatientCompartment`, `PractitionerCompartment`, `RelatedPersonCompartment`, `DeviceCompartment`, `LegitimateInterest` (covering Task), and `CareTeam`. Identity filters add FHIRPath conditions to scope a rule to a subset of users in a role. Property filters use `NullFilter` and `RandomFilter` to redact fields after a validator allows the request.
Search is narrowed at query time. For REST, additional parameters are appended to the underlying search. For GraphQL, alternative search parameter maps achieve the same narrowing without changes on the client. Rules can declare `blocked-search-params` to reject probes that would leak property-filtered values through chained or sorted searches.
Workflow primitives
Tag a CarePlan with the `https://firearrow.io/fhir/careplan-scheduling` `scheduled` meta tag and the server materializes its activities into Task resources up to a configurable horizon. Tasks transition to `ready` when due. Subscriptions on `Task?status=ready` deliver the events to your application over a REST hook, email address, WebSocket, or Azure Storage Queue, without an external scheduler.
Related docs
FAQ
Which FHIR version does it speak?
FHIR R4. The data layer is HAPI FHIR JPA, so storage, validation, and search semantics follow the upstream HAPI implementation.
Are there limits on which resources I can use?
No. The full FHIR R4 resource set is available. Authorization rules apply per resource type, so you grant access to only the types your product needs.
How does it handle binary content?
Through the `$binary-upload` operation, with Azure Blob Storage as the backing store. The `binary-upload` authorization operation gates who can upload and to which contexts.
Can I extend it with custom server logic?
Custom FHIR operations are supported on Server. For per-request transformation hooks (pre-request, post-request, pre-response), Fire Arrow Core is the right edition; Server keeps the server boundary closed and uses validators, identity filters, and property filters as the extension surface.
