The day someone leaves: a HIPAA termination checklist for ABA clinics

An RBT quits on a Tuesday. Not angrily, nothing dramatic, she took a job closer to home.

She still has the scheduling app on her personal phone. She still has a login to the EHR. Her clinic email still receives mail. She has a tablet in her car with session data on it, and she knows the wifi password, and she knows the door code.

None of that is a problem on Tuesday. It becomes a problem on some unremarkable Thursday six weeks later, when nobody remembers she still has any of it.

Most HIPAA obligations move slowly. Annual reviews, periodic training, a risk analysis you refresh once a year. This one moves in hours, and it is the only routine compliance task in a clinic that has a same-day clock on it.

What the rule says, and the trap in how it says it

Terminating access to ePHI when someone’s employment ends is an implementation specification under Workforce security (45 CFR 164.308(a)(3)(ii)(C)). And here is the part people get backwards: it is Addressable, not Required.

Addressable does not mean optional. It means you must assess whether the measure is reasonable and appropriate for your clinic, and then either implement it, or document why it is not and implement an equivalent alternative instead (45 CFR 164.306(d)(3)). Doing nothing and writing nothing is not one of the choices. The full explanation is here.

So try writing the alternative. “We assessed the procedure for revoking access when an employee leaves and determined it was not reasonable and appropriate for a clinic of our size.” Read that back. No owner would sign it, no lawyer would let them, and no investigator would accept it. Addressable does not mean optional, and there is no version of that sentence where declining to revoke a departed employee’s access is reasonable and appropriate.

Which makes this the clearest case in the whole Security Rule of a specification that is addressable in name and mandatory in practice. The flexibility is in how you do it, not whether.

“Addressable does not mean optional, and there is no version of that sentence where declining to revoke a departed employee's access is reasonable and appropriate”

Three lists, not one

The single most common failure here is not laziness. It is collapsing three different jobs into one line in a policy. They are three lists, they are executed differently, and finishing one tells you nothing about the others.

List one: accounts to revoke

Things you switch off. The test is simple: could this person log in from home tomorrow? If yes, it belongs on this list.

In a typical ABA clinic that means the practice management system or EHR, named specifically. The email suite. The billing clearinghouse or payer portals. The online fax service. Staff-side access to the parent portal. The telehealth platform. Payroll and HR self-service. Any data collection app. Any shared drive or cloud storage. The password manager, which people forget, and which is the key to everything else.

Two notes that matter more than they look. Disabling is not the same as deleting, and disabling is usually the right move first, because deleting an account can destroy the audit trail of what that person did. And unique logins are what make any of this possible: shared accounts cannot be revoked for one person, which is one reason unique user identification is Required rather than addressable (45 CFR 164.312(a)(2)(i)).

List two: property to collect

Things you take back. The test: is it physical?

The clinic laptop or tablet. The phone, if the clinic issued one. Badges and keys. And the one that is specific to this field: paper. Data sheets, printed schedules, session notes, the folder that lives in the back seat. Home-based and school-based work means paper travels, and it does not come back on its own.

Collecting the laptop does not revoke the accounts that laptop was logged into. And revoking the accounts does not retrieve the tablet. Those are two different motions, and a clinic that does one and feels finished is exactly where breaches come from.

There is a third case that belongs here and fits neither test cleanly: personal devices. If an RBT used her own phone for session data, the device is hers and the data is not. What you can actually do about that is decided long before someone quits, in whatever you set up when you allowed it, which is why BYOD is worth settling in advance.

List three: shared secrets to rotate

The forgotten one, and the reason a departure can leave a door open even after both other lists are complete.

The wifi password. The alarm or door code. Shared voicemail PINs. The front desk workstation password everyone knows. Any group login to a payer portal or a vendor account, which should not exist, and does.

Shared secrets are not revoked. They are changed, and everyone who still works there has to learn the new one, which is why clinics avoid doing it. But a secret shared with someone who left is a secret that person still has, indefinitely, and no access log will ever show you they used it.

Who does what, and by when

A procedure that does not name a role is not a procedure. Assign each list to a role rather than a person, because people leave (that is the entire subject here) and a policy naming Sarah becomes wrong the day Sarah moves on.

The rule sets no deadline. It says terminate access when employment ends, and stops. Which means you choose the standard, and then you are held to whatever you chose, so choose one you will actually keep.

The defensible pattern:

Accounts: same business day. This is the one with real urgency, because remote access does not require the person to be anywhere near your building.

Property: at separation, or on a dated schedule if that is not possible. People sometimes leave without a handoff. Write down what is outstanding and chase it.

Shared secrets: same day for anything that opens a door, within the week for the rest. If the departure was contentious, all of it is same-day.

Involuntary terminations run on a different clock. Access should be cut before or during the conversation, not after it. That is not paranoia; it is the same instinct that says you collect the keys before someone walks out, and it is the scenario where a delay is least defensible.

The record is the deliverable

Here is the part that decides how this goes in an audit, and it is not the work. It is the evidence the work happened.

A completed checklist, with the employee, the date of separation, each item, who did it, and when. Kept for six years like every other piece of required documentation (45 CFR 164.316(b)(2)(i)).

OCR settled with a five-facility behavioral health provider, Anchorage Community Mental Health Services, for one hundred fifty thousand dollars, after finding that the organization had adopted sample policies years earlier that were not being followed. The lesson is not that they lacked a policy. It is that the policy and the practice had drifted apart, and there was nothing to show otherwise.

“We definitely did it, we just did not write it down” is not an answer to an investigator. It is an admission that the program is running on memory.

What an auditor actually does with this

This is the easiest policy in your binder to test, which is why it gets tested.

They pick a former employee off your roster, someone who left eight months ago, and ask for that person’s termination checklist. Then they ask a second question, which is the one that decides it: can you show me that account is actually closed now?

If the checklist exists, is dated, names the systems, and the account really is closed, the conversation moves on. If the checklist does not exist, or it says “all systems” without naming any, they will keep pulling that thread, because a clinic that cannot show this simple thing is unlikely to be able to show the harder ones.

Which is the last point worth making. This is the most testable policy you have, and it is also the most concrete illustration of the standard the whole rule runs on: the document has to name your actual systems, or it cannot be executed by the person holding it on a Tuesday. What that looks like across every policy you own is the broader version of the same argument. The termination checklist is just where it becomes obvious fastest.