Permission atoms

A capability is a named atom. Atoms attach to roles; roles attach to people. There is no path that grants a capability directly to a person, which is what keeps an access review finite and answerable.

#The shape of a name

text

prior_auth.submit.own-practice.phi-view
└────┬────┘ └─┬──┘ └────┬─────┘ └───┬───┘
  resource  action    scope      PHI marker

resource: What is being reached. prior_auth, ehr, eligibility, tenant, agent, audit, config.
action: What is being done. Read and write are always separate atoms - a role that can see a thing does not thereby change it.
scope: Load-bearing. own-practice is enforced by the gateway against the principal's practice, never against an argument. platform is the admin plane. full-spine is the whole audit record.
phi-view: Marks an atom that reaches patient data. Holding one is what makes a session require a second factor and what puts a purpose-of-use on every read.

#Three properties the catalog audit enforces

The admin plane never reaches a chart. A role holding a platform atom cannot hold a PHI atom. Provisioning a practice grants no access to its data.
Separation of duties. Declared pairs may never appear in one role - the author of a config change may not approve it, and so on. Each pair exists because the halves check each other, and one person holding both checks only themselves.
The catalog is closed. A capability that is not in the catalog does not exist. There is no ad-hoc grant and no wildcard.

The audit runs in the test suite and fails the build on a violation, so an unsafe role cannot be merged rather than being found later in a review.

#Just-in-time PHI access

Support roles hold zero standing PHI. Reaching patient data requires a time-boxed grant with a stated reason, which expires on its own. A support engineer who needed to see a record last Tuesday cannot see one today.

See the generated Atom catalog for every atom, which roles carry it, and which tools require it.