Access rules and birthright access
The same start for everyone in a job
Dana Okafor starts as a registered nurse in Harbor Clinic's pediatrics unit on Monday 2 November 2026. Someone has to decide what Dana's accounts can do on that first shift. For years, Harbor answered with an email from the unit's nurse manager to IT: "Please set Dana up the same as Kim." IT copied Kim's access, and the new nurse inherited six years of Kim's history, including a pharmacy permission from a project that ended long ago.
Copying a colleague is quick, but it treats one person's history as the definition of a job. Nothing in that email separates what every pediatric nurse needs from what Kim once needed, for a reason nobody wrote down.
Most of what a new nurse needs is not personal at all. Every registered nurse in pediatrics reads and updates pediatric patient records, sees the unit's rota in scheduling, and needs email and somewhere to keep files. Those needs follow from the job and the unit, and the HR system already records both. Birthright access is this baseline: the access a person receives because of their place in the organization, such as their department, job, and site, without anyone having to ask for it.
In Deciding what someone can do, attributes such as a department helped an application decide whether to allow a single request. Birthright access uses attributes earlier and for a different purpose. The identity system reads them from the authoritative source and decides which entitlements each person should hold in the first place.
Writing an access rule
An access rule connects a condition on identity attributes to a set of entitlements. While a person's attributes satisfy the condition, the identity system makes sure they hold those entitlements, sending any changes to each application through its provisioning service. Harbor starts with three rules:
| Rule | Condition | Grants | Agreed by |
|---|---|---|---|
| R1 All staff | Status is active or pending start | Email and files, and an entry in the staff directory | IT service owner |
| R2 Pediatric nurses | Department code PED and job code RN | EHR_PED_RW, Unit staff for Pediatrics in scheduling, and Ward nurse for Pediatrics in pharmacy | Morgan Hale and the head of nursing |
| R3 Oncology nurses | Department code ONC and job code RN | EHR_ONC_RW, Unit staff for Oncology in scheduling, and Ward nurse for Oncology in pharmacy | Morgan Hale and the head of nursing |
All names, codes, and identifiers in these examples are fictional.
Each rule records who agreed to it. Morgan Hale, the records manager, owns access to the patient records system and agreed that every registered nurse in pediatrics needs EHR_PED_RW, which lets them read and update pediatric patient records. When an auditor later asks why Dana can open a pediatric record, the answer is a rule, the people who agreed to it, and the HR attributes that matched. Nobody has to reconstruct who emailed whom.
The conditions use codes rather than the words people see on screen. HR keeps PED and RN stable because other systems depend on them. Job titles such as "Registered Nurse" are written for people to read, and people edit them. R1 also counts people whose start is still pending, so that their accounts can be created a week ahead and kept disabled until the first day, as Joining an organization described.
A rule speaks for a whole group, so it should grant only what nearly everyone in that group needs. Unit staff, the scheduling entitlement that lets a nurse see a unit's rota and request shift swaps, belongs in R2 because every pediatric nurse works from the rota. Unit scheduler, which lets someone edit the rota, does not. Only the nurses who build each month's rota need it.
When attributes change
Sam Reyes has been a pediatric nurse for four years and transfers to oncology on Monday 9 November 2026. HR records the move on 26 October, effective that Monday. The identity system recalculates each person's access by evaluating the rules again whenever an attribute they depend on changes, and on a regular schedule in case a change slipped through. Here are the same three rules evaluated for Dana and for Sam:
| Person | Status, department, job | Rules matched | Entitlements |
|---|---|---|---|
| Dana, from 2 November | Active, PED, RN | R1, R2 | Email and files, directory entry, EHR_PED_RW, Unit staff and Ward nurse for Pediatrics |
| Sam, until 8 November | Active, PED, RN | R1, R2 | Email and files, directory entry, EHR_PED_RW, Unit staff and Ward nurse for Pediatrics |
| Sam, from 9 November | Active, ONC, RN | R1, R3 | Email and files, directory entry, EHR_ONC_RW, Unit staff and Ward nurse for Oncology |
Before the move, Dana and Sam get identical results, because they have identical attributes. A new nurse and a nurse with four years in the unit start from the same place, whatever happened to either of them before.
On 9 November nobody files a ticket. R2 stops matching Sam, so the identity system removes EHR_PED_RW and the pediatric Unit staff and Ward nurse entitlements. R3 starts matching, so it grants the oncology equivalents. R1 is unaffected, and Sam's email and files carry on as before. The same evaluation that adds access also removes it.
Compare that with access granted by hand. If someone had added Sam to pediatric records through a help desk ticket, nothing about the transfer would touch it, and Sam could still open pediatric records a year later. Changing jobs followed how movers collect access that way. Rules cannot clean up access they never granted, but everything they did grant follows the person's current job.
Recalculation does exactly what the rules say, and that cuts both ways. An earlier version of R2 and R3 matched the job title text "Registered Nurse" instead of the job code. One evening HR tidied its titles, and "Registered Nurse" became "Registered nurse (RN)". At the next evaluation, nobody matched either rule. The identity system removed pediatric and oncology record access from every nurse in both units, and the morning shift arrived to find they could not open a chart.
Nothing in the identity system had failed. The rules depended on a value that was never meant to be stable. Harbor now writes conditions against codes HR maintains for other systems, and HR tells rule owners before those codes change. The identity system also holds any evaluation that would remove access from an unusually large number of people until someone confirms it. A rule is only as good as the attributes it reads, and Sources of truth looked at who keeps those attributes correct.
What a rule should not grant
A rule grants access without anyone looking at the individual. That is its strength for the baseline, and the reason some access should never come from one. A useful test is to ask whether Harbor would be comfortable if a change to HR data, with no person reviewing it, gave someone this access.
For pediatric records and the unit's rota, the answer is yes. A pediatric nurse who could not open pediatric records could not do the job, and an error in HR data would be noticed quickly. For other access, the answer is no:
- Ordering controlled medication in the pharmacy system. Harbor wants a named person to approve each holder, a record of that decision, and a check that the same person cannot also receive the medication they ordered.
- Administering a system, such as
EHR_ADMINin patient records. Even the IT staff who need it should hold it only while they are using it. - Access that only some people in a group need, such as
ONC_RESEARCH_R, which lets a few oncology nurses read the research database for a study. HR does not record who works on which study.
Access like this is requested, approved by people who can judge it, and often given an end date.
One kind of access never comes from a rule: management authority. That means the ability to approve access requests, assign roles, change other people's access, or edit the rules themselves. If a rule granted it from attributes, the people who maintain HR data would be choosing who controls access at Harbor, without anyone approving that choice. A clerk correcting a job code could create an administrator by mistake, and anyone able to change a department field could do it on purpose. Management authority is given to named people through a request, approved, recorded, and reviewed.
Exceptions
When HR records the transfer on 26 October, the pediatrics nurse manager asks IT to keep Sam's pediatric record access for a two-week handover. The quickest-looking fix is to edit R2 so that it reads "department code PED and job code RN, or employee number E07731". Another is to copy R2 into a new rule that matches only Sam. Either one works on Monday.
Both cause trouble later. R2 no longer describes pediatric nurses. It describes pediatric nurses and Sam, with no end date, so Sam keeps pediatric access long after the handover. Someone reviewing R2 sees a rule for pediatric nurses and approves it without noticing the name inside. The next request is handled the same way, and after a few years the rule is a list of names whose reasons nobody remembers.
An exception is a grant to one named person that sits outside the rules, with a reason, an owner, and an end date. It is recorded separately, so reviews see it for what it is. Sam's looks like this:
Exception EXC-26-0193
Person Sam Reyes (E07731)
Grants EHR_PED_RW
Reason Handover of pediatric patients after the transfer
to oncology on 2026-11-09
Owner Pediatrics nurse manager
Approved by Morgan Hale, records manager
Starts 2026-11-09
Ends 2026-11-23On 23 November the identity system removes EHR_PED_RW from Sam's account, and nobody has to remember to ask. R2 still describes pediatric nurses and nothing else. The nurse manager answers for the exception if anyone asks why it existed, and extending it means making that decision again with a new end date.
Exceptions should stay rare. If several nurses each need the same exception, the rule is probably wrong. The fix is to change the rule openly with its owners, so the change applies to everyone it should and the record shows why.
Sam's next piece of access is neither birthright nor an exception to a rule. Sam asks for it, gives a reason, and other people decide. Continue to Requesting and approving access to follow that request from the catalog to confirmed access.