Skip to main content

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​

TablePurpose
person_visibility_scopeWho/what may see a person.
consent_registryRecorded consent.
person_access_grantExplicit access grants to a person's data.
patient_facility_relationshipA patient's link to facilities.
health_cardHealth-card identity.

Key rules & invariants​

  • consent_registry.consent_type is the ConsentType enum (TERM-008M). Free text let a typo invent a consent that access decisions could never match. Jackson rejects unknown values (400); migration identityaccess/007 normalises then CHECK-constrains and HALTs on dirty data.
  • Reads of a person/patient are filtered by access scope server-side — visibility/consent/grants gate what a caller can retrieve.
  • health_card.card_type is HealthCardType (TERM-008L). It was free VARCHAR(40) with PHYSICAL as the only evidenced value. Jackson rejects an unrecognised value with 400; migration identityaccess/006 normalises non-null values, CHECK-constrains, and HALTs on dirty data. The column stays nullable — a card may omit its channel when only the number matters.
  • 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.