Healthcare Authorization with OpenFGA

Healthcare applications — EHR/EMR systems like Epic, Cerner, or Athenahealth, plus patient portals, telehealth, and clinical research tools — share a few hard authorization problems:

• A single patient is seen by many providers across many facilities, and the care team changes per encounter.
• Some fields on a patient record (allergies, blood type, date of birth) are more sensitive than others and need a separate permission.
• Records like diagnoses and treatments don't have their own ACL — they inherit visibility from the encounter and patient they belong to.
• Facility directors need to manage facility metadata without inheriting access to every patient seen there.

A relationship-based model handles all of this naturally. The full sample is in openfga/sample-stores/stores/healthcare.

Core resources and relations

The healthcare sample defines these object types:

• organization — the tenant (a hospital network, a clinic group). Roles: admin, provider, nurse, medical_records, member.
• facility — a physical site. Has a director and a parent organization.
• patient — belongs to an organization. The care team grants can_view_record to assigned providers and nurses, and a separate can_view_sensitive permission gates PHI fields.
• encounter — a visit. Belongs to a patient and a facility. Authorized providers can can_view, can_create, but typically not can_edit after the encounter closes.
• diagnosis and treatment — inherit visibility from encounter → patient, so the care team automatically sees them without separate tuples.
• medication (formulary) — admin-only writes, everyone-reads.

What the model gets right

Care-team scoping. Rather than granting a provider access to all patients in a facility, the model writes a tuple per (provider, patient) care-team relationship. Revocation is one tuple delete.

PHI as a distinct permission. can_view_record and can_view_sensitive are separate relations. A nurse on the care team can see the chart but not the sensitive fields without an explicit grant — useful when separating clinical-care views from billing or research access.

Record inheritance. Diagnoses and treatments use object-to-object relationships (parent-child) so the care team inherits access through the encounter and patient. No separate ACL maintenance on every clinical note.

Facility hierarchy. Facility directors are scoped to facility-level data (staff lists, equipment, schedules) — they do not inherit can_view_sensitive on patients seen at their facility. That separation is hard in role-only systems and easy in OpenFGA.

Where this maps to OpenFGA features

Healthcare requirement	OpenFGA feature
Care-team membership per patient	direct tuples on patient
PHI vs. non-PHI fields	two relations: can_view_record, can_view_sensitive
Diagnosis/treatment inheritance	parent-child relationships
Multi-tenant org isolation	tenant-scoped types, see multi-tenant SaaS
Time-bounded access (rotations, locums)	contextual tuples
Break-glass access logging	tuple writes flow through the Read Changes API

Compliance posture

OpenFGA itself isn't a HIPAA product — compliance is a property of how you run it. What OpenFGA does give you:

• A single, queryable source of truth for who can see which patient record at any moment, which audit programs typically require.
• Append-only tuple change history via the Read Changes API.
• Separation between checks (read-only) and writes (admin-only) at the API level.

For the operational side — encryption at rest, logging, deployment in a HIPAA boundary — see Running OpenFGA in Production.

Working sample

The full schema, sample tuples, and assertion tests for the model above live in openfga/sample-stores/stores/healthcare. You can load it with the FGA CLI and run the included assertions to see the model behave end-to-end.