Terminate EMR access the same day a workforce member leaves — before the exit interview, not after the final paycheck — and provision new users from a written role template rather than by cloning whoever sits nearest to them. Those two habits eliminate the majority of access problems a small or midsize practice will ever have. Everything else in this article is scaffolding to make those two things happen reliably when the person who normally does them is on vacation.
The short answer
User provisioning is not an IT chore; it is the mechanism by which your minimum-necessary policy either exists or does not. A practice can have an excellent written access policy and, in the EMR, a medical assistant who was cloned from a nurse practitioner three years ago and has been able to sign orders ever since. Nobody noticed, because nothing broke. Access problems are silent by nature — that is what makes them worth a routine.
Why offboarding fails in practices
It is rarely negligence. It is that the offboarding path has more owners than any single person can see:
- The EMR is not the only system. The e-prescribing module, the clearinghouse portal, the lab portal, the imaging portal, the patient-messaging tool, and the VPN may all have separate accounts. HR closes the payroll record and considers the person gone.
- Departures are not always clean. A per-diem nurse who has not worked a shift in four months is not "terminated," so nothing triggers.
- Locums and residents rotate. Short-term users are created quickly under pressure and almost never have an end date attached at creation.
- Nobody owns the list. If no single person can produce a current roster of active EMR users on demand, the roster is not being managed.
- Vendor support accounts persist. Implementation consultants, interface engineers, and vendor support staff often hold accounts that outlive the project.
What the Security Rule expects
The HIPAA Security Rule addresses this directly, and it is useful to know the exact hooks, because they map cleanly onto the checklist:
| Requirement | Citation | Status |
|---|---|---|
| Unique user identification | § 164.312(a)(2)(i) | Required |
| Authorization and/or supervision | § 164.308(a)(3)(ii)(A) | Addressable |
| Workforce clearance procedure | § 164.308(a)(3)(ii)(B) | Addressable |
| Termination procedures | § 164.308(a)(3)(ii)(C) | Addressable |
| Access authorization | § 164.308(a)(4)(ii)(B) | Addressable |
| Access establishment and modification | § 164.308(a)(4)(ii)(C) | Addressable |
| Automatic logoff | § 164.312(a)(2)(iii) | Addressable |
| Sanction policy | § 164.308(a)(1)(ii)(C) | Required |
Read "addressable" correctly. It does not mean optional. It means you must assess whether the safeguard is reasonable and appropriate for your environment and, if you conclude it is not, document that reasoning and implement an equivalent alternative measure where reasonable. A practice with no termination procedure and no documented rationale for not having one has not made a choice — it has an omission.
Note also that unique user identification is required, not addressable. Shared logins are not a gray area.
The provisioning checklist
- Start from a role template, never from a person. Maintain a written template per role — front desk, MA, RN, provider, biller, practice manager, IT. Cloning a user copies their accumulated exceptions along with their permissions, and those exceptions compound silently across years.
- Require a named approver. Access is granted on the request of a manager who owns that role, not on a hallway conversation.
- Assign a unique account. One human, one account. No shared front-desk logins, ever.
- Set an end date at creation for anyone temporary. Locums, residents, students, vendor staff, contractors. If the EMR supports account expiry, use it. If it does not, put the date in a calendar with an owner.
- Provision the adjacent systems in the same ticket. Clearinghouse, labs, imaging, e-prescribing, VPN, secure messaging. One ticket, one checklist, one closure.
- Record what was granted, and why. A one-line justification per non-standard permission. Future you will need it during the access review.
- Confirm training before enabling. Especially for anyone who will document or order.
The offboarding checklist
- Disable, do not delete. Deleting a user can orphan audit trails and unsigned documentation. Disable the account so history remains attributable.
- Do it on the last day, not after. Ideally within the hour the person leaves the building. Put a standing item in the HR termination workflow that notifies whoever administers the EMR.
- Sweep the adjacent systems. The same list you used to provision. This is why one ticket matters.
- Reassign the open work. Unsigned notes, open orders, pending results, inbox items, and any queues they owned. An account you disabled with forty unsigned notes behind it becomes a clinical problem, not just an access one.
- Revoke e-prescribing credentials — particularly anything tied to controlled substances — through the correct process, not just by disabling the EMR login.
- Collect the second factor. Tokens, keys, and any mobile device enrollment.
- Record the date and who did it. This is your evidence that the termination procedure exists in practice and not only on paper.
The quarterly access review
Provisioning and offboarding handle the edges. The middle — permission creep, role changes, the person who covered the billing desk for six weeks in 2024 and still has billing access — needs a periodic sweep. Quarterly is enough for most practices.
Pull a full list of active EMR users. For each one, confirm three things: this person still works here, this person still holds this role, and this account's permissions still match the role template. Anything that fails one of those tests gets fixed or gets a written justification. Have the manager who owns each role sign off on their own people rather than asking IT to guess.
The review takes an afternoon and will, the first time you do it, find something. It always does.
Shared accounts and service accounts
Two categories deserve their own handling. Shared human accounts — a generic front-desk or nurse-station login — must go. They defeat unique user identification, which is a required specification, and they make audit logs useless: if you cannot attribute an action to a person, you cannot investigate anything.
Service accounts — interface engine, backup agent, analytics connector, reporting job — are legitimate but need an owner, a documented purpose, a credential rotation schedule, and a permission set scoped to exactly what the integration requires. The failure pattern here is a service account provisioned with administrative rights during a rushed go-live because it was faster than working out the minimum, and then never revisited. Find those. Every practice has at least one.
What to automate, and what not to
Automate the trigger, not the judgment. An HR termination should automatically open a task with the full checklist attached. An account with an expiry date should automatically disable. A quarterly review should automatically land in someone's queue with the user list pre-attached.
What should stay human is the decision about what a person needs. Role templates are a starting point, not an oracle, and the moment they are treated as self-maintaining they start drifting from how the practice actually works. Review them once a year against what people really do.
The takeaway
Nothing in this article is difficult. It is a list, a ticket, and a calendar reminder. What makes access hygiene hard is that it is invisible when it works and invisible when it fails, so it competes for attention against problems that shout. Give it a fixed slot — same-day termination, quarterly review — and it stops being a project. Then go look at your service accounts, because that is where the surprise is.
Common questions
How fast should we disable an EMR account after someone leaves?
Same day. The HIPAA Security Rule requires termination procedures as an addressable specification at 45 CFR 164.308(a)(3)(ii)(C) but does not set a deadline, so you set it — and same-day is the only threshold that is easy to audit and hard to argue with.
Should we delete or disable a departed user's account?
Disable. Deleting can orphan audit history and unsigned documentation, and you need those records to remain attributable to the person who created them.
Are shared logins ever acceptable in an EMR?
No. Unique user identification is a required implementation specification at 45 CFR 164.312(a)(2)(i). Shared accounts also make audit logs unusable, since no action can be attributed to a person.
How often should we review EMR user access?
Quarterly works for most practices, with role owners signing off on their own staff. The Security Rule requires a periodic evaluation under 45 CFR 164.308(a)(8); a fixed cadence is how you make that real rather than theoretical.
Common questions
How fast should we disable an EMR account after someone leaves?
Same day. The HIPAA Security Rule requires termination procedures as an addressable specification at 45 CFR 164.308(a)(3)(ii)(C) but does not set a deadline, so you set it — and same-day is the only threshold that is easy to audit and hard to argue with.
Should we delete or disable a departed user's account?
Disable. Deleting can orphan audit history and unsigned documentation, and you need those records to remain attributable to the person who created them.
Are shared logins ever acceptable in an EMR?
No. Unique user identification is a required implementation specification at 45 CFR 164.312(a)(2)(i). Shared accounts also make audit logs unusable, since no action can be attributed to a person.
How often should we review EMR user access?
Quarterly works for most practices, with role owners signing off on their own staff. The Security Rule requires a periodic evaluation under 45 CFR 164.308(a)(8); a fixed cadence is how you make that real rather than theoretical.