Joiner, Mover, Leaver: Running the EHR Account Lifecycle Without Gaps

A nurse resigns on a Friday, works her last shift, and collects her final pay. Eight months later her EHR login still opens patient charts, because nobody told IT she had gone. This is not a rare horror story. It is the ordinary outcome when a hospital has no account lifecycle, only a pile of accounts that get created in a hurry and never cleaned up. The login outlives the job.

Most hospitals think about access on the day someone starts. Almost nobody thinks about the two harder days: when a staff member moves to a new role and quietly keeps the old permissions, and when they leave and nobody flips the switch. Get the full arc right, joiner to mover to leaver, and the security problem mostly takes care of itself. Get it wrong at any of the three points, and you are running an EHR full of accounts that no longer match the people behind them.

// 01 The joiner: who requests, who approves, who provisions

A clean joiner process answers three questions before a single account is created. Who requested this access? Who approved it? Who actually provisioned it? In most Nigerian hospitals the honest answer to all three is the same overworked person, usually a ward sister or a unit clerk who phones the IT desk and says "create one like the last doctor's". That copy-the-last-person habit is where over-privilege is born, because the last person's account had accumulations of its own.

Tie the request to the role the human resources record already names, not to a colleague's login. A new pharmacy technician gets the pharmacy-technician access set, nothing more. The line manager approves it because they own the consequence. IT provisions it against that approval and records the date. None of this needs new software. It needs a request that starts from a job title and an approval that is written down, so that six months later you can answer the question "why does this account have this access" without guessing.

Set a same-day target and mean it. When provisioning lags by a week, the ward improvises, and improvisation in a Nigerian hospital means the new house officer borrows a shared login to get through the night shift. The lifecycle has already failed on day one. Provisioning slowly is not the safe option; it is the option that breeds the shared accounts everyone later pretends do not exist.

// 02 The mover: the privilege that nobody takes away

The mover is the quietest failure in the whole lifecycle. A records officer is promoted to a supervisory role and gets new permissions. The old permissions stay. A doctor rotates from the antenatal clinic to the emergency unit and keeps access to both. A locum covers theatre for three weeks, gets theatre access, and that access is still live a year later. Nobody did anything wrong on the day. The access just never gets subtracted, only added, and the account slowly becomes a master key.

This matters because an attacker who phishes one set of credentials wants exactly this account: the one whose reach grew far past the job. The fix is recertification. Once or twice a year, the manager who owns each unit looks at the list of accounts that touch their data and confirms, name by name, that each person still needs what they hold. Attestation is the boring word for it. It is also the single control that catches the mover problem, because it forces a human to subtract.

For the design theory behind which access model makes recertification easier (where role explosion in a teaching hospital forces a rethink), our piece on choosing an access control model for patient records sits one layer up from this operational view.

// 03 The leaver: disable today, delete after retention

The leaver is where the opening story lives. Deprovisioning fails because it depends on a handover that nobody owns: HR knows the person resigned, IT controls the account, and the message between them gets lost in a WhatsApp group or a corridor conversation. Wire the trigger directly. When HR records a departure, that record is what disables the EHR account, on the last working day, not whenever IT next hears about it.

Disable first, do not delete straight away. A disabled account preserves the audit trail you may need if something surfaces later, and the National Health Act expects medical records and the accountability around them to survive for a defined period. Delete the account only after that retention window closes. Two dates, then: disable on the day they leave, delete on the calendar.

The leaver who keeps access is the start of an insider-risk story, and we follow that thread, including how to detect a returning ex-employee in the audit logs, in when a sacked employee still has access.

// 04 The accounts with no human at all

Three kinds of account never appear in the joiner-mover-leaver flow because no person owns them, and those are the ones that bite. Shared ward logins that a whole shift uses. Default vendor accounts shipped with the EHR, often still carrying the password from the install manual. Service and integration accounts that move data between the EHR and the laboratory or billing system, holding broad rights and never rotated. OWASP has flagged identification and authentication failures, including default and unmanaged credentials, as a standing class of web-application risk for years. The default vendor account is that risk wearing a hospital badge.

Pull all of them into one place: a plain account register. Every account, human or not, with an owner, a purpose, a date created, and a date last reviewed. It can live in a spreadsheet. The register is what turns "I think we cleaned that up" into a sentence you can actually check, and it is the artefact the NDPA accountability principle expects you to be able to produce when the NDPC asks how you control access to patient data.

When ClarenSec runs an access review, the orphaned service account and the live login of someone who left last year are usually the first two findings, and they are almost always already in nobody's register. The lifecycle is what stops that being true next time.