Identity & Access — How it works
Overview
The identity-access engine holds the cross-organization identity facts that feed access decisions: who is allowed to see a person, the consent on record, explicit access grants, a patient's relationship to facilities, and health-card identity. It supplies the visibility/consent/grant inputs that the access-control engine combines with local roles/scopes to decide object-level access.
Data model & ownership
| Table | Purpose |
|---|---|
person_visibility_scope | Who/what may see a person. |
consent_registry | Recorded consent. |
person_access_grant | Explicit access grants to a person's data. |
patient_facility_relationship | A patient's link to facilities. |
health_card | Health-card identity. |
Key rules & invariants
- Reads of a person/patient are filtered by access scope server-side — visibility/consent/grants gate what a caller can retrieve.
- These facts are inputs to the unified access decision; the access-control engine owns the decision itself.
API
See the API Reference. Endpoint groups under /api/v1/identity-access: visibility
scopes, consent, access grants, patient–facility relationships, health cards, and visibility
discovery.
Related features
- Access control (consumes these facts), Demographic (the persons being protected).