Designing and maintaining roles

From jobs to roles

Dana Okafor's first shift needed entitlements in three applications: pediatric records in patient records, the unit's rota in scheduling, and the ward medication screens in the pharmacy system. In Access rules and birthright access, Harbor Clinic's pediatric nurse rule listed its entitlements one by one. That works for two or three. A real job touches dozens of entitlements across several systems, and every rule, exception, and request that deals with the job would need the same list, kept the same everywhere.

A role gives that bundle a name. Harbor distinguishes two kinds. A business role describes a job function in the organization's own words, such as "Pediatrics registered nurse". An application role is a bundle of permissions inside one system, defined in that system's terms. A business role is made of application roles, one or more in each system the job uses, and each application role is made of permissions.

When a nurse opens a record, patient records still has to check whether the nurse's role allows it. How that check works at request time is covered in Roles, assignments, and scope. The questions here are slower ones: what each role should contain, and how to keep that accurate for years while jobs and systems change.

In patient records, the pediatric nurse's application role is the one behind EHR_PED_RW, which lets a nurse read pediatric records and update notes and observations. In scheduling it is Unit staff, which lets a nurse view the unit's rota and request shift swaps. In pharmacy it is Ward nurse, which lets a nurse view the unit's medication orders and record doses given. Harbor's rule for pediatric nurses now assigns the business role, and the role carries the rest.

The two layers have different owners. The head of nursing owns the business role and answers for what the job needs. Morgan Hale, the records manager, owns the application roles in patient records and answers for what each one allows inside that system. The pharmacy manager does the same for pharmacy. A change to either layer needs the other layer's owners to know about it.

Two ways to find roles

Harbor can find its roles in two ways. The first starts from the jobs. Someone sits down with the pediatric nurse managers and asks what a pediatric nurse does on a shift, which systems that involves, and what each task needs. The result describes the job as the people who know it understand it. It is slow, it depends on who was in the room, and it misses things people do every day without thinking to mention them.

The second starts from the access people already have. Role mining analyzes existing entitlements to find the sets that people in the same job share. It is fast and grounded in what people actually hold. Here is a small slice of the data for six pediatric nurses at the main site:

All names, entitlements, and records in these examples are fictional.

The first six rows are the shared core. Every nurse holds them, and together they look like the contents of a pediatric nurse role. The two outliers need someone to explain them. Nurse C is a charge nurse who builds the rota each month, so Unit scheduler meets a real need, but it belongs to a smaller charge nurse role or to a request, not to every nurse. Nurse E transferred from oncology two years ago, and EHR_ONC_RW is a leftover that nobody removed. It should go.

The same reading applies at a larger scale. If 40 of 42 nurses share twelve entitlements and two nurses hold something extra, those two are more likely to be exceptions or leftovers than a new role waiting to be defined.

Mining has a weakness built in: it shows access as it is, not as it should be. In billing, it finds that every clerk can approve refunds. Years ago one clerk was given refund approval for a project, and since then each new clerk's account has been set up by copying an existing one. Mining sees a permission held by all of them and proposes refund approval as part of the billing clerk role. The pattern is real, but it describes a copying habit, not the job.

Mining proposes, and people decide. Priya Nair, the billing supervisor, owns the billing clerk role and confirms each entitlement in it. Refund approval is not part of a clerk's job, so it stays out of the role and is removed from the clerks who hold it. Most organizations combine the two approaches: mining produces a draft quickly, and the people who know the job confirm or reject each part of it.

When roles multiply

Harbor's first attempt at nurse roles went wrong in a different way. Each unit wanted its own role, then each site, then the night shift asked for a slightly different version. Within two years there were roles such as "Pediatrics nurse, Main site, Nights", about 90 of them, most differing from their neighbors by a single entitlement or only by name.

This is role explosion, the problem Designing a role model traced in a newsroom's photo library: so many roles that nobody can understand or maintain them. When pharmacy added a screen that every nurse needed, someone had to add it to 90 roles, and missed eleven. Nobody could review 90 nearly identical roles with any care, and several of them had a single member, created for a person rather than a job.

Most of those differences were about scope rather than content. Site and shift change where and when a nurse works, which site's rota they appear on and which wards they cover. They do not change what the job needs. Harbor now keeps one role for each job function, such as Pediatrics registered nurse, and keeps the unit in a role only where the work itself differs. Site and shift come from HR as attributes that scope what the role allows. Where an application can consider attributes when it makes a decision, the role grants access to the rota and the nurse's site decides which rota. Where an application only understands fixed groups, the identity system uses the attribute to pick the right group when it assigns the role.

A few warning signs are worth watching for: roles with only one or two members, roles that differ by a single entitlement, and role names that encode a place, a time of day, or a person.

Keeping roles honest

A role is a claim that its contents match a job. Keeping that claim true takes three things.

The first is an owner. Every business role has someone who answers for what it contains, such as the head of nursing for the nurse roles and Priya for the billing clerk role. Every application role has an owner in its own system. When an owner leaves, the role passes to a named successor rather than defaulting to IT.

The second is a review of what each role contains, separate from the review of who holds it. Once a year, the head of nursing goes through the pediatric nurse role entitlement by entitlement and asks whether each one is still needed and still described accurately. A role can be held by exactly the right people and still carry a permission that stopped being needed three system upgrades ago.

The third is change history. Every change to a role records who made it, who approved it, when, and why. That history lets Harbor answer how a permission got into a role, and undo a change that turns out to be wrong.

Changes to roles deserve more care than changes to one person's access, because changing a role changes everyone's access at once. Adding Order controlled medication to the pediatric nurse role would give it to every pediatric nurse in one step, without a single request. Harbor treats role changes as high-risk requests. The identity system shows how many people a change affects, the role owner and the owners of the affected entitlements approve it, and only then does it take effect. Removing a permission needs the same care in the other direction, since a mistake can stop forty nurses working on the same morning.

Roles also attract the same shortcut as rules. When one nurse needs something extra, adding it to the role is easier than a request, and a week later every pediatric nurse has it. One person's need belongs in a request or an exception with an end date, so the role stays a description of the job.

Some combinations of access are dangerous even when each part is justified on its own. Continue to Separation of duties to see how Harbor finds those combinations and keeps them apart.