Comparison

Fire Arrow vs building RBAC in your own API

Authorization in healthcare quickly outgrows simple role checks. Patients, clinicians, organisations, care teams, and service accounts each need different rules, and those rules must apply consistently across every path that reads or writes the data. Fire Arrow expresses this as a composable validator chain on top of FHIR resources; building it yourself on a generic backend (Postgres, Hasura, Firebase, or a custom service) is mostly an exercise in keeping the rules consistent across query paths.

Review Fire Arrow editions Book an architecture comparison

Who this is for

Architects, CTOs, staff engineers, and product leaders evaluating FHIR infrastructure options.

Clinical applicability

A multi-clinic product cannot rely on client-side organisation filters: the backend must narrow every read, search, write, and bulk operation to what the caller is allowed to see, with patient-scoped exceptions for cross-clinic specialists. Whether the storage layer is Postgres, Hasura, Firebase, or a FHIR server, the access logic still has to be written, kept consistent, and audited.

Capability comparison

Capability Fire Arrow building RBAC in your own API

Role + resource + operation matching Built-in Build per route or per resolver

Patient, practitioner, related-person, and device compartments Built-in compartment validators Build the relationship resolution and the filter logic

Organisation-scoped access with role differentiation Built-in legitimate-interest validator with PractitionerRole filtering Build the org-membership join and role-aware checks

Per-patient cross-organisation exceptions Built-in care-coordination, related-person, and identity-filtered validators, additive with the tenant rules Build a sharing model that does not over-grant

Field-level redaction with side-channel protection Built-in property filters with search-parameter blocklists Build per response and per search; remember the side channels

Search narrowing across all access paths Applied at query time, consistent across REST, GraphQL, and SQL-on-FHIR Implement per query path; keep them in sync as the API surface grows

Composable validators on the same role/resource pair Multiple validators apply additively in one default-deny chain Build the chain semantics and the deny-by-default behaviour

Rule debugger for denied requests X-Fire-Arrow-Debug header returns the rule trace and near-miss hints Add tracing into every authorisation decision

When to choose building RBAC in your own API

Your access model is small and stable, the data is not strongly clinical, and you have no plan to add patient self-service, multi-organisation, or service-account access patterns later.

When to choose Fire Arrow

Your product needs a composable access model that spans patient self-service, clinician access, service accounts, AI agents, and multi-tenant SaaS, with consistent enforcement across every read and write path.

Related docs

FAQ

What is the worst-case failure of building it ourselves?

Inconsistency across access paths. A rule enforced on the REST search endpoint but missed on the GraphQL resolver, the bulk export, or the analytics view is the canonical bug, and it tends to surface in production. The risk is independent of the storage choice; it grows with the number of access paths and the number of roles. Fire Arrow evaluates rules in a single layer that every access path flows through.

We are not using FHIR. Does any of this apply?

The composable validator pattern applies to any healthcare backend: organisation-scoped access, patient compartments, per-patient exceptions, role differentiation, and field-level redaction are the same problems whether the storage is Postgres, Firebase, Hasura, or a FHIR server. Fire Arrow Server adds the FHIR resource model on top, which is the part that lets the rules express clinical relationships directly. If you are committed to a non-FHIR backend, the categories above are still the work; the lift comes from building each one.

Can we adopt Fire Arrow's rules incrementally?

Yes. You can start by granting `Allowed` for roles you have not yet modelled and tighten rules as you add validators and identity filters. The deny-by-default mode is a switch that you flip when the rule set is complete.