Security
Fire Arrow Security
Security in Fire Arrow rests on four properties. Every access decision is enforced by the server, never by the client. Every authorised request is attributed to a real FHIR identity, so audit logs reflect who actually did what. The system runs entirely in the customer's environment, so PHI never leaves it. And the architecture is a thin, auditable application layer on top of well-known building blocks (OAuth/OIDC, HAPI FHIR JPA, PostgreSQL) rather than a re-implementation of any of them.
Security posture at a glance
- Server-enforced access
Every read, search, write, and subscription is matched against an explicit rule before it reaches the data. Frontends and integrations cannot grant themselves access by sending a different parameter.
- Deny-by-default
Requests that do not match an explicit rule are rejected. Adding a new role, exposing a new resource type, or opening a new API surface requires a deliberate decision, not a config change that quietly grants access.
- Identity-faithful audit
Every authorised request is tied to a real FHIR identity (Patient, Practitioner, RelatedPerson, or Device). Audit logs attribute reads and writes to actual people and devices, not to a shared service account.
- Customer-controlled deployment
Both editions run in the customer's environment. PHI lives in the customer's database (Server) or upstream FHIR service (Core). There is no vendor-operated control plane that processes PHI and no outbound telemetry that exfiltrates it.
- Small, auditable application layer
Fire Arrow does not reinvent authentication, FHIR storage, or the database. It composes well-known building blocks (OAuth/OIDC providers, HAPI FHIR JPA, PostgreSQL) and concentrates on the application-level concerns those building blocks do not solve.
- Inspectable decisions
Authorisation outcomes are inspectable. A reviewer can replay a rule against a specific identity and operation and see exactly which rule matched, which strategy ran, and what the response would be, without enabling debug behaviour for live traffic.
Security review summary
Who this is for
Security reviewers, CISOs, CTOs, procurement engineers, and the implementation teams who answer their questions during diligence and integration.
Authentication and identity resolution
Fire Arrow does not run an identity provider. Authentication is delegated to OAuth 2.0 / OpenID Connect, with full support for any compliant provider on Server and dedicated support for Microsoft Entra ID on both editions. Scopes and roles are mapped per audience, so the same identity provider can serve patient apps, clinician portals, integration partners, and machine-to-machine traffic with different rule sets.
After authentication, every token is mapped to a FHIR identity resource: Patient, Practitioner, RelatedPerson, or Device. That mapping is the foundation of the rest of the security posture. Authorisation rules reason about a real clinical identity, audit logs attribute actions to that identity, and AI agents that act on a clinician's behalf can be configured to forward the original token rather than masquerading as a service account.
Authorisation as data, enforced server-side
Authorisation rules live in FHIR resources, not in code. Each rule pairs a role, a resource type, and an operation with an authorisation strategy. Strategies range from outright allow or deny, to compartment-based rules (a patient sees their own data; a practitioner sees their patients), to an organisation-scoped 'legitimate interest' rule, to a care-team membership rule (a specialist sees only the patients on the care teams they belong to). Identity-conditional rules layer FHIRPath conditions on the caller, so a rule applies only to a defined subset of users, for example, only practitioners marked as principal investigators on a specific study.
Search rules are applied at the database layer, not after the fact. A clinician searching for patients does not retrieve the full set and then have rows stripped out; the search itself is narrowed before the database returns results. The same rule shape covers REST, GraphQL, and SQL-on-FHIR, so the access boundary does not depend on which API surface a caller uses.
The default decision for an unmatched request is deny. Adding a new role, exposing a new resource type, or opening a new API surface requires a new rule. This deny-by-default posture is the foundation of the model: a misconfiguration fails closed.
Closing search-shaped side channels
Field-level redaction (clearing a name, replacing a contact point with a synthetic value) is necessary but not sufficient. Without further protection, a recipient with redacted access can probe redacted fields indirectly: searching for an exact name and observing whether a result comes back, sorting by a redacted field, or chaining a search through a reference into a record they should not be able to see.
Fire Arrow pairs redaction with explicit blocklists on the search parameters and reference traversals a role can use, applied uniformly across REST, GraphQL, and SQL-on-FHIR. Where the use case allows, the safer pattern is to grant 'read by ID' or GraphQL with inline reference expansion without granting search at all, which removes the side channel entirely. The pattern is documented; the choice between them is the customer's.
Identity integrity
Identity resources are themselves part of the data model. A Patient resource carries identifiers, demographics, and references that the rest of the system reads, which makes the identity resource itself a target. Server enforces two specific protections: a caller cannot modify the credentials or identifying fields of an identity resource that is not their own, and the system protects against accidental duplication of an identity resource that would otherwise lock the user out of their own data. Both protections are deny-by-default and audited.
Implementers can verify that the rule set behaves as intended by inspecting the authorisation decision for a specific identity and request, without enabling debug behaviour for live traffic. This makes rule changes reviewable in the same way code changes are: with a clear before-and-after for a concrete user.
Audit, faithful to who actually did what
Every authorised request is logged with the resolved FHIR identity, the rule that matched, the operation, and the resource. Where AI agents and integrations act on a clinician's behalf, token forwarding lets the agent's request be attributed to the clinician, preserving the chain of custody that auditors and regulators expect, instead of the 'integration user touched 14,000 records' pattern that obscures actual responsibility.
Audit records flow into the customer's logging stack via standard channels. There is no vendor-operated logging plane that receives PHI and no obligation to forward audit data to Fire Arrow.
Deployment, ownership, and disclosure
Both editions are container images that run in the customer's environment. Fire Arrow Server is a self-contained backend; the customer operates the PostgreSQL database it persists to. Fire Arrow Core is stateless and runs in front of an existing FHIR service the customer already operates. Either way, PHI never leaves the customer's environment, and there is no vendor-operated control plane that processes PHI.
Updates are explicit. Customers pull new container images on their own schedule. There is no automatic update channel and no outbound telemetry that exfiltrates patient data or operational logs.
Vulnerabilities can be reported through the responsible disclosure page. Reports are triaged on a defined timeline, fixes are released as updated container images, and disclosure is coordinated with affected customers.
FAQ
Where does PHI live?
On Fire Arrow Server, in the PostgreSQL database the customer operates. On Fire Arrow Core, in the upstream FHIR service the customer already runs (for example, Azure Health Data Services or a HAPI deployment). Fire Arrow does not transmit PHI to a vendor-operated control plane, and there is no telemetry channel that exfiltrates patient data.
How does Fire Arrow authenticate users?
Authentication is delegated to OAuth 2.0 / OpenID Connect. Server supports any compliant provider; both editions support Microsoft Entra ID directly. SMART on FHIR launch flows are supported. Service-to-service traffic uses durable or one-time API tokens issued and revoked through the admin surface; credentials are never shared between callers.
How are access rules expressed and reviewed?
Access rules are FHIR resources. Each rule pairs a role, a resource type, and an operation with an authorisation strategy (allow, deny, FHIR compartments, organisation-scoped, or care-team membership). Rule changes are diffable, reviewable, and auditable in the same way code changes are. Authorisation decisions for a specific identity and request can be inspected on demand without enabling debug behaviour for live traffic.
What about searches that could leak redacted fields?
Field-level redaction is paired with explicit blocklists on the search parameters and reference traversals a role can use, applied uniformly across REST, GraphQL, and SQL-on-FHIR. Where the use case allows, the safer pattern is to grant 'read by ID' without search at all, which removes the side channel entirely.
Are audit logs available, and what do they capture?
Yes. Every authorised request logs the resolved FHIR identity, the rule that matched, the operation, and the resource. With token forwarding for AI agents and integrations, reads performed on a clinician's behalf are attributed to that clinician rather than to a shared service account. Logs flow into the customer's logging stack through standard channels.
What is in Fire Arrow's trust boundary, and what is the customer's responsibility?
Fire Arrow's trust boundary covers the application backend layer: identity resolution, authorisation, audit, and the API surfaces. The customer operates the surrounding infrastructure: the OAuth/OIDC provider, the PostgreSQL database (Server) or upstream FHIR service (Core), the container runtime, ingress, secret management, and logging. The deployment model makes the boundary explicit so security review can ask the right questions about each side.
How are vulnerabilities reported and disclosed?
Through the responsible disclosure page. Reports are triaged on a defined timeline, fixes are released as updated container images, and disclosure is coordinated with affected customers.
