Comparison
Fire Arrow vs building RBAC in your own API
Authorization in healthcare quickly outgrows simple role checks. Patients, clinicians, organisations, CareTeams, and service accounts each need different rules, and those rules must apply consistently across REST, GraphQL, and search. Fire Arrow expresses this as configuration; building it yourself is mostly an exercise in keeping the rules consistent.
Who this is for
Architects, CTOs, staff engineers, and product leaders evaluating FHIR infrastructure options.
Clinical applicability
A multi-clinic SaaS cannot rely on client-side organisation filters when FHIR search remains global. The backend must narrow searches to the caller's clinic and respect cross-clinic CareTeam relationships, and it must do so consistently for REST, GraphQL, and bulk operations.
Capability comparison
When to choose building RBAC in your own API
Your access model is small, stable, not strongly tied to FHIR relationships, and unlikely to grow new roles or cross-organisation patterns.
When to choose Fire Arrow
Your access model depends on patient compartments, practitioner roles, organisations, CareTeams, identity-conditional rules, property filters, and consistent search narrowing across REST and GraphQL.
Related pages
FAQ
What is the worst-case failure of building it ourselves?
Inconsistency across access paths. A rule enforced on REST search but missed on GraphQL search is the canonical bug, and it tends to surface in production. Fire Arrow's model evaluates rules in a single layer that all access paths flow through.
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.
