Access reviews

Looking again

Every quarter, Morgan Hale, Harbor Clinic's records manager, receives a list of everyone who can update oncology patient records. In the patient records system, that ability is the entitlement EHR_ONC_RW. Each person on the list got it for a reason at some point. A rule matched their department, a manager approved a request, or someone at the help desk added it while sorting out a problem. Morgan's task is to say whether each of those reasons still holds.

Rules and approvals deal with the moment access is granted. They answer the question "should this person get this access now?" Months later, the same access needs a different question: "should this person still have it?" The project behind a request has finished. A cover arrangement has ended. Someone has moved to another unit and kept the old access because nothing removed it. None of these changes reaches the access by itself.

An access review is a scheduled or triggered check in which a responsible person looks at access that already exists and decides whether it should stay. It is also widely called certification, because the reviewer certifies that the access is still appropriate. A review produces a record as well as decisions. Months later, that record can show who looked at the oncology list, what they saw, and what they decided.

Who reviews what

The same access can be reviewed from three directions, and each suits a different reviewer.

A review by manager lists everything one person holds, across every system, and sends it to that person's manager. Sam Reyes's manager knows what Sam's job involves and can say whether Sam still needs to edit the unit rota or read the research database. The same manager may have no idea what EHR_ADMIN allows, or why it matters.

A review by entitlement lists everyone who holds one entitlement and sends it to the entitlement's owner. Morgan's oncology list is this kind. Morgan knows exactly what EHR_ONC_RW allows and who would normally need it, but cannot know all forty people on the list personally.

A review by application lists every account in one system, with what each account holds, and sends it to the application's owner. The pharmacy manager, reviewing every pharmacy account, is the person most likely to spot an account that belongs to nobody, a problem the next lesson takes up.

Harbor combines them. Sensitive entitlements go to their owners, who understand the risk. Everything else goes to managers, who understand the job. Nobody reviews their own access: Morgan's own entitlements in patient records go to a different reviewer, for the same reason nobody approves their own request.

How often each review runs follows risk. Updating oncology records, administering the patient records system, and approving supplier payments are reviewed every quarter. Editing a unit's rota or using shared files might be reviewed once a year. Reviewing everything quarterly would bury reviewers in low-risk rows, and reviewing everything yearly would leave the riskiest access unexamined for too long.

Some reviews should not wait for the calendar. When Sam moved from pediatrics to oncology, rules recalculated Sam's baseline access, but anything Sam had requested or been given by hand stayed behind, as Changing jobs described. A transfer can trigger a small review of its own: Sam's new manager receives only the access the move did not recalculate and decides what stays. Other events can do the same, such as a change of manager, a contractor whose sponsor has left, or an entitlement newly marked as sensitive.

Making a decision

For each item, the reviewer has three choices: keep the access, remove it, or change it, for example by adding an end date or replacing it with something narrower. A row that says only "Elena Brandt, EHR_ONC_RW" gives the reviewer nothing to decide with, and the easiest answer is to keep it because nothing looks wrong.

Three pieces of context make the decision real. Last use shows whether the access is still part of someone's work. A comparison with peers shows whether others in the same department and job hold the same access, so anything unusual stands out. How the access was granted shows where it came from: a rule, a request with an approver and a reason, or a manual grant that may have no recorded reason at all. Here is part of Morgan's worksheet for the December review.

The first two rows are not decided person by person. Sam and Ines Fischer hold EHR_ONC_RW because rule R3 grants it to every registered nurse in oncology, as described in Access rules and birthright access. If the rule is right and the HR data it reads is right, everyone it matches should have the access, and removing it from one person would last only until the rule ran again. So access granted by a rule is reviewed through the rule and its inputs. Morgan confirms once that registered nurses in oncology should be able to update oncology records, and the people are checked by checking that their department is correct. On the full list, the 24 nurses become one decision, and the oncology physicians and pharmacists, who hold the entitlement through rules of their own, are reviewed the same way.

The remaining rows are where Morgan's attention belongs. Noor Haddad's trial has closed, months before the request's end date, and Dr. Ravi Chandran's grant has no recorded reason, no peers, and no use in fourteen months, so both go. Elena Brandt's cover arrangement is real and the access is in weekly use, but the request was given the catalog's longest duration and would outlast the cover by more than two months, so Morgan keeps it and brings the end date forward.

Dr. Hana Sato's row looks just as odd as Dr. Chandran's: a manual grant, no reason recorded, and no peers with the same access. But Dr. Sato is the clinic's palliative care physician, sees oncology patients every week, and used the access two days ago. Morgan keeps it and records the reason, so the next review does not have to rediscover it. Unusual access is a reason to look, not a reason to remove.

Rubber-stamping

Morgan's review was not always this manageable. A year earlier, Harbor sent Morgan one list with every entitlement in the patient records system: 412 rows, most of them nurses holding exactly what their rules gave them. The review system recorded all 412 decisions as "keep", made in under six minutes.

That is rubber-stamping: approving items without examining them. It is rarely laziness. Morgan had no context for most rows, a deadline, and a reasonable worry that removing the wrong access would stop a nurse from treating patients. When every row looks the same and keeping is the safe-looking choice, approving the whole list is the predictable result. The review was complete and changed nothing.

Harbor changed the design of the review rather than asking Morgan to try harder.

• The review got smaller. Access granted by rules is decided once, through the rule, instead of row by row. Low-risk entitlements moved to a yearly manager review. Morgan's quarterly list now concentrates on sensitive access that came from requests and manual grants.
• Unusual items stand out. Rows with no use in 90 days, access that no peer holds, manual grants with no reason, and toxic combinations found by the separation of duties checks are listed first and marked.
• Keeping a marked item needs a reason, and there is no button that keeps every marked row at once.
• Silence is not approval. An item nobody decides by the deadline goes to the reviewer's manager instead of quietly counting as "keep".

The worksheet above is the result. Morgan now sees a few rows that need real decisions, each with enough context to make one, and several of those decisions are removals.

Closing the loop

Morgan's decision to remove Dr. Chandran's access does not remove anything. It creates work. For the patient records system, the identity system sends the change through its provisioning service. For a system that is changed by hand, it opens a ticket for Jordan Ellis. Either way, the review item is not finished until three things have happened: the access is removed, the removal is confirmed in the target system, and the result is recorded alongside the decision that caused it.

Confirmation matters because a request to remove access is not the same as access being gone. A provisioning call can fail without anyone noticing, and a ticket can be closed by mistake. The identity system checks by reading the account back from the patient records system, or by seeing the change in its next reconciliation, and only then marks the item complete. The record keeps the reviewer, the decision, the reason, the time, and the confirmation together, so a question about Dr. Chandran's access next year can be answered from it.

Here is how it can still go wrong. Suppose Sam's transfer had never reached the HR system, which still listed Sam in pediatrics. The oncology nurse manager would have requested EHR_ONC_RW so Sam could work, and Morgan's worksheet would have shown Sam's row as granted by request when every other oncology nurse has it by rule. Looking closer, Morgan finds Sam still holding EHR_PED_RW, unused since the move, and removes it. Jordan confirms the removal in the patient records system that afternoon. The next morning, the access is back.

Nothing malfunctioned. The pediatric rule still matched Sam, because the HR system said Sam worked in pediatrics, and the overnight sync did what it is meant to do: it restored access that the rule says Sam should have. Removing it again would only repeat the cycle. When removed access comes back after the next sync, a rule or a source still grants it, and the fix belongs there. Once HR corrects Sam's department, the pediatric rule stops matching and removes EHR_PED_RW by itself, the oncology rule grants EHR_ONC_RW, and the requested grant can end because the rule now covers it. If the rule itself had been wrong, for example granting pediatric access to everyone at the main site, the review item would become a change to the rule, decided by its owner.

Reviews start from access Harbor knows about, held by people it knows. Some accounts have no person behind them at all. Continue to Orphaned, dormant, and shared accounts to find them and decide what to do with them.