How do we decide how much access to patient data each role should have?

Start

We need to set who may reach ePHI, and how much

Access to ePHI is decided role by role, not person by person. The limit comes from minimum necessary, the Privacy Rule idea that PHI used, disclosed or requested is limited to what the purpose needs. The Security Rule then asks you to authorise access and allow only those people in. Start from the role, because a person's job is what justifies the access.

• Then: Are we a covered entity?

Decision

Are we a covered entity?

The duty differs. A covered entity must identify the workforce roles that need ePHI and the categories each needs. A business associate applies minimum necessary to its own uses, disclosures and requests, and its agreement with the covered entity can shape the limit. If your role is not known, take the covered entity route, which asks more, and settle the question in “Is our organisation a HIPAA covered entity, a business associate, or neither?”. If you are neither, this flow does not apply to you.

• Yes, or not known: List the roles that need ePHI, with categories and conditions
• No, a business associate: Read the agreement, then apply the limit to our own uses

Step

Read the agreement, then apply the limit to our own uses

As a business associate, apply minimum necessary to what you use, disclose and request yourself, and read your agreement with each covered entity for limits it adds. Read both with counsel. Then carry on to the role list, which you still need to enforce the limit in your own systems.

• Then: List the roles that need ePHI, with categories and conditions

Step

List the roles that need ePHI, with categories and conditions

Name each person or class of people in the workforce who needs ePHI to do the job. For each, write the categories of ePHI needed and any conditions, such as only the patients on their own caseload, or only during a shift. Access is needed when the current job cannot be done without it, not because someone had it before or a colleague has it.

• Then: Is each role's need for ePHI clear?

Decision

Is each role's need for ePHI clear?

A need is clear when the role, the categories and the conditions are written and the system or data owner agrees. If one is unknown, do not grant on a guess. The cautious branch is the least access that lets the job start, with a date to settle the rest.

• Yes: Make a role profile for each role and grant only through it
• No, or not known: Give the least access, then ask the system or data owner

Step

Give the least access, then ask the system or data owner

Start the role on the narrowest access that allows the work. Ask the owner of the system or data which categories the role really needs, and widen only on a recorded answer. Least privilege applies to the permission as well as the system: a person entering records needs the entry role, not the supervisor role.

• Then: Make a role profile for each role and grant only through it

Step

Make a role profile for each role and grant only through it

A role profile is approved once and granted many times. The pack's rule: each profile has a named owner, is approved by the owner of every system in it, holds no segregation-of-duties conflict or privileged access, and is reviewed at the pack's default of every 12 months and after a reorganisation or a new core system. Access outside a profile needs a reason, two approvers and an expiry.

• Then: Is someone asking for more because a Privacy Rule exception applies?

Decision

Is someone asking for more because a Privacy Rule exception applies?

The Privacy Rule lists disclosures where minimum necessary does not apply, such as a disclosure to or request by a health care provider for treatment, a use or disclosure to the individual, one under an authorisation, one required by law, and a disclosure to the Secretary of HHS. The Rule's list has more. Each exception covers that disclosure. It does not widen what a role reaches inside your systems. Counsel confirms whether one applies.

• Yes: Handle that disclosure alone and keep the role limit
• No, or not known: Give every user a unique ID

Step

Handle that disclosure alone and keep the role limit

Treat the disclosure as its own decision with counsel's confirmation, and record the exception relied on. The role profiles stay as they are. If the work behind the request is permanent, change the profile through the normal approval, and do not quietly widen access.

• Then: Give every user a unique ID

Step

Give every user a unique ID

Unique user identification is a required specification of access control. Every user has a name or number of their own so that actions can be identified and tracked. No shared account reaches ePHI. Service accounts get a named owner, one job and the least rights they need.

• Then: Is there an emergency access procedure that has been tested?

Decision

Is there an emergency access procedure that has been tested?

An emergency access procedure is a required specification: a way to get at necessary ePHI in an emergency. It is a controlled exception, with no standing route around the profiles. The pack asks that it be defined and tested. Not known counts as No, because an untested procedure may fail when it is needed.

• Yes: Authorise, clear and end access through one process
• No, or not known: Write it and test it: who, how, review after use

Step

Write it and test it: who, how, review after use

Say who may use emergency access to reach necessary ePHI, how every use is noticed, and how often it is tested. After each use, review what was done against the stated reason and change the credential. The pack's break-glass standard for administrator accounts is a model for these controls: sealed credentials, an alert on every sign-in, regular tests, review after use. Its counts and intervals are for administrator lockout, so set your own.

• Then: Authorise, clear and end access through one process

Step

Authorise, clear and end access through one process

Have procedures to authorise or supervise workforce members before access starts, to decide that their access is appropriate, to grant, set up and change access, and to end it when employment or the arrangement ends. These are addressable specifications, assessed in the next question. Log every grant, change and removal, and count a removal done only when confirmed in the system. A monthly reconciliation with the HR record catches what the process missed.

• Then: Is a decision recorded for each addressable specification?

Decision

Is a decision recorded for each addressable specification?

Authorisation or supervision, clearance, termination, access authorization, access establishment and modification, automatic logoff, and encryption and decryption are addressable. Addressable is never optional, and a proposed change would make these required (check the current rule). Assess whether each is reasonable and appropriate, then record it as implemented, an equivalent alternative, or not implemented with the reasons. Not known counts as No. A clearinghouse inside a larger organisation also has a required isolation specification.

• Yes: Review access on every role change and at the set interval
• No, or not known: Assess each one and record the decision

Step

Assess each one and record the decision

For each addressable specification, record the risks it addresses, the four factors, whether it is reasonable and appropriate, the decision, any alternative, who decided and when it is reviewed. “Is an "addressable" HIPAA safeguard optional?” explains the method.

• Then: Review access on every role change and at the set interval

Step

Review access on every role change and at the set interval

A mover receives the new role profile, and the old role's access is checked and removed. Reviews run at least as often as the access scope requires. The pack's defaults are every 3 months for privileged access, every 6 months for systems supporting a critical service and every 12 months for others, and a review also runs after a restructure or an incident involving misuse of access.

• Then: Does anyone hold ePHI access beyond their profile?

Decision

Does anyone hold ePHI access beyond their profile?

Compare actual access with the role profiles and the approved non-standard access. Excess found is the control working, and nobody is blamed for finding it. If you cannot tell, treat it as Yes and check before the next cycle.

• Yes, or not known: Remove the excess, or approve it with an expiry
• No: Keep the role list, profiles and review record

Outcome

Remove the excess, or approve it with an expiry

Take the excess access away. If the need is real, approve it as non-standard access with a business reason, approval by the line manager and the system owner, and an expiry (the pack's default is no more than 6 months). Log the change, raise it as a finding with the access review coordinator, and send a pattern to the process owner.

Outcome

Keep the role list, profiles and review record

Keep the role list with its categories and conditions, the profiles, the account list, the emergency access test, the addressable decisions and the review results in your own register. They show the limit was set and still holds.