HIPAA
HIPAA-Compliant FHIR Backend
HIPAA does not certify software. It places obligations on the covered entity and its business associates that have to be demonstrable in the deployment. Fire Arrow gives those obligations a place to live in the architecture: every access tied to a real identity, every authorization decision recorded, every search narrowed at the database layer.
What you can build
- Security Rule safeguards mapped onto deployment artifacts
Access control, audit controls, integrity, person or entity authentication, and transmission security each have a concrete configuration the auditor can review.
- BAA scope defined by deployment shape
Evoleen-hosted Fire Arrow is a business associate and signs the BAA. Self-hosted Fire Arrow keeps PHI inside the customer environment and the BAA chain runs through the customer's own providers.
- Audit ready by default
Every authorized access logs the resolved FHIR identity, the operation, the resource, and the rule that matched. No additional instrumentation needed to satisfy access-log requests.
What you get out of the box
Who this is for
US digital health teams building covered or business-associate-facing products who need a FHIR backend that maps cleanly onto Security Rule safeguards and a BAA scope they can defend.
Clinical applicability
A telehealth platform stores PHI as FHIR resources. Patients see their own Encounters and Observations. Clinicians see only patients on their caseload. Billing services read claim-relevant resources only. Each request resolves to one identity, one rule, one audit row.
What HIPAA actually asks of a backend
The Security Rule does not certify products. It assigns safeguards to covered entities and business associates and requires those safeguards to be demonstrable. For a FHIR backend that means access control with a unique user identity for every read and write, an audit record that ties each access to that identity, integrity controls that prevent unauthorized modification, and transmission security for PHI in flight.
Software meets these requirements by making the right behavior the only available behavior. If a role can be configured to see only its own Patient compartment, and that configuration cannot be circumvented through a search parameter or a GraphQL traversal, the access-control safeguard is satisfied as a property of the system rather than a property of every endpoint review.
Fire Arrow controls in HIPAA terms
Authorization is rule-based and deny-by-default. A request resolves to an identity, the identity matches a role, the role matches one or more rules whose validators run against the request. If no rule matches, the request is denied. Search narrowing happens at the database layer, so unauthorized rows are never selected.
Audit covers REST, GraphQL, and bulk surfaces uniformly. Each authorized request logs the resolved FHIR identity, the operation, the resource type, the rule that matched, and the timestamp. Audit records are append-only and shipped to the operator's log infrastructure.
Authentication relies on OAuth/OIDC for human users and API tokens for service accounts. Identity mapping resolves the external subject to a FHIR resource that becomes the basis for compartment validators. There is no client-trusted user parameter to forge.
BAA scope and deployment topology
When Evoleen Technology hosts Fire Arrow for a US customer that handles PHI, Evoleen is a business associate. The BAA is signed as part of the engagement and the hosted environment runs under Evoleen's controls. Subcontractor flow-down agreements cover the underlying infrastructure provider.
Self-hosted Fire Arrow keeps PHI inside the customer's environment. Evoleen does not process PHI in this configuration, so a BAA with Evoleen is not in scope. The BAA chain runs from the covered entity through whichever providers operate the customer environment.
A common hybrid is Evoleen-hosted for non-production environments (where Evoleen handles synthetic data only and a BAA is not required) and customer-hosted for production. Either side can change without rewriting the deployment.
Related pages
FAQ
Does using Fire Arrow make my product HIPAA compliant?
Compliance applies to the covered entity, not to a single component. Fire Arrow contributes the architectural foundation for access control, audit, integrity, and authentication. The other safeguards (administrative, physical, organizational) sit at the deployment and operations layer. The combination is what an auditor reviews.
Will Evoleen sign a BAA?
Yes for Evoleen-hosted deployments where Evoleen Technology handles PHI as a business associate. For self-hosted deployments Evoleen does not process PHI, so a BAA with Evoleen is not in scope.
How are audit logs structured for HIPAA access reports?
Each authorized request emits an audit record containing the resolved FHIR identity (Patient, Practitioner, RelatedPerson, or Device), the resource type and id, the operation (read, search, write, graphql-read, etc.), the rule that matched, and the timestamp. Records are append-only and shipped to your log infrastructure for retention.
Can a clinician search across patients they are not assigned to?
Only if the rules allow it. A LegitimateInterest validator can scope clinician access to patients within their organization or care team. A Practitioner-only role can be locked down further with property filters and blocked search parameters.
What happens to PHI on a deletion request?
FHIR delete operations are supported on Server and on Core, scoped by rule. Hard delete vs soft delete is a deployment decision driven by the customer's retention policy. The request and its decision are recorded in the audit log.
