Access, granted and revoked

An RBT resigned in March. In September, an OCR investigator asks one plain question: on the day of the incident, who could open this child’s record? Someone logs in to check, and there it is, the March RBT’s account, still active, still able to reach every client in the region, half a year after the last shift. Nobody had turned it off, because turning it off was nobody’s job.

That is the whole obligation in one scene. Access is not a state you set once and forget. It is a lifecycle: granted when someone arrives, shaped to what the role actually needs, and revoked the day the role ends. The login that outlives the job is the one an investigator finds.

What the rule requires

HIPAA splits access across two administrative standards and one technical one, and they only work together.

“The login that outlives the job is the one an investigator finds.”

On the administrative side, workforce security (45 CFR 164.308(a)(3)) requires policies and procedures ensuring every workforce member has the access they need and no more, and that anyone without a reason for access is kept out. Its three implementation specifications, authorization and supervision, workforce clearance, and termination procedures, are all Addressable. Information access management (45 CFR 164.308(a)(4)) requires policies for authorizing access in the first place, with access authorization and access establishment and modification also Addressable.

Addressable is the word that trips clinics, so be clear about it: Addressable does not mean optional (the distinction has its own page). It means you assess whether the measure is reasonable and appropriate for your clinic, and then either implement it, implement an equivalent, or document why it is not reasonable and what you do instead (45 CFR 164.306(d)). Skipping it silently is not one of the options.

On the technical side, access control (45 CFR 164.312(a)(1)) requires that your systems let only authorized people and programs reach ePHI, and it points straight back to the authorizations you set under 164.308(a)(4). Underneath it sits the requirement clinics violate most often, and this one is not Addressable, it is flatly Required: unique user identification (45 CFR 164.312(a)(2)(i)), a unique name or number for every person, so that identity can be tracked. Person or entity authentication (45 CFR 164.312(d)) is Required too: the system has to verify that whoever is asking for access is who they claim to be.

The grant half

Granting access is the easy half to get right and the easy half to overdo. The instinct in a small clinic is to give everyone everything, because it is faster and because trust is high. The rule points the other way: authorize the access the role needs, and establish it deliberately (164.308(a)(4)).

In an ABA clinic that means an RBT sees their own clients, a BCBA sees their caseload and their supervisees’ data, billing sees service codes and not clinical narrative, and the front desk sees scheduling and not session notes. None of that is exotic. It just has to be decided rather than defaulted, and it has to be written down, because “everyone can see everything” is not an access policy, it is the absence of one.

The revoke half, where clinics actually fail

The dangerous end of the lifecycle is revocation, and it fails for a structural reason: turnover runs faster than the access review. ABA clinics hire and lose RBTs at a pace no annual review can keep up with. If deprovisioning happens only when someone remembers, or only when the quarterly audit comes around, then every departure opens a window, and the window stays open until someone closes it.

Termination procedures (164.308(a)(3)(ii)(C)) are the Addressable spec that covers this, and the honest way to satisfy it is a process that runs the day employment ends, not a resolution to get to it eventually. The termination checklist is the operational version: the exact steps that have to fire on a last day. The point is that revocation cannot depend on memory, because memory is precisely what fails at RBT turnover speed.

Why shared logins are the cardinal sin

Unique user identification is Required for a reason that becomes obvious the first time something goes wrong. When four staff share one login, the audit log can tell you the account opened a chart, but it cannot tell you which of the four people did it. Every downstream control that depends on knowing who did what, your activity review, your breach investigation, your sanctions process, collapses to a shrug.

A shared account is not a convenience with a small compliance cost. It is the erasure of accountability at the exact moment you need it, the difference between “we can show you who reached this record” and “we have no idea.” Give every person their own identity (164.312(a)(2)(i)), and make the system prove they are who they say (164.312(d)).

The question you have to be able to answer

Here is the test the whole lifecycle is built to pass. On any given day, can you produce a current picture of who can see what, and can you show that the picture is true? Not reconstruct it painfully from HR records and email threads after an investigator asks. Produce it.

That current picture is also where leavers surface. A clinic that can answer “who has access right now” will notice the March RBT whose login is still live. A clinic that cannot answer it will find out in September, from someone whose job is to find exactly that.

The ABA-specific traps

A few that a generic access policy never anticipates:

• A supervising BCBA needs to see their supervisees’ session data, so access follows supervision relationships that themselves change monthly.
• The parent portal is one family, one login, and a family’s access has to end cleanly when a case closes or custody changes.
• An RBT carries client data on a personal phone, so access is not only a login in your system, it is data sitting on a device you do not control.
• The clinician granted broad access during a short-staffed month, whose access was never narrowed when staffing recovered.

How it dies

Quietly, at the revoke end. The grant half gets attention because it happens on someone’s first day, when everyone is watching. The revoke half happens on a last day, when the person is already gone and nobody owns the closeout. So access accretes: every hire adds a login, few departures remove one, and the list of who can reach ePHI drifts further from the list of who should, until an incident measures the gap for you.

The bottom line

Access is a loop, not a switch. Grant it to the right people, give each of them an identity you can trace, and revoke it the day the reason ends. The requirement with no flexibility in it at all is that every person be uniquely identified, because everything you will ever need to prove about access depends on knowing who, not just what. Get the revoke half running on the day someone leaves, and the login that outlives the job stops being the thing an investigator finds.