Access controls for PHI decide who can open, change, export or delete a patient document, and HIPAA's Security Rule sets the floor: a unique ID for every user, an emergency access procedure, automatic logoff and encryption to consider. In a document workflow, that means roles matched to tasks, review queues limited by role, and prompt removal when people leave.
The access controls for PHI the Security Rule names
The HIPAA Security Rule's access control standard requires systems holding electronic PHI to let in only the people and programs granted access. It lists four implementation specifications: unique user identification and an emergency access procedure, both required, and automatic logoff and encryption, both addressable.
The standard itself, in 45 CFR 164.312 on eCFR, reads: "Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4)." The four specifications under it each do a different job.
Unique user identification (Required). The rule says to "Assign a unique name and/or number for identifying and tracking user identity." Every person who touches a scanned claim or intake form signs in as themselves. Without this, no log can say who did what.
Emergency access procedure (Required). The organization must establish procedures for getting at necessary electronic PHI during an emergency. For a billing office, that might be a sealed administrator account and a written process for an outage, with every use reviewed afterward.
Automatic logoff (Addressable). The rule describes electronic procedures that end a session after a set period of inactivity. A reviewer who walks away from a desk should not leave a queue of lab reports open to the next passer-by.
Encryption and decryption (Addressable). Systems should be able to encrypt and decrypt stored electronic PHI. The details of storage and network encryption are in the post on encryption at rest and in transit for PHI.
"Addressable" does not mean optional. 45 CFR 164.306 on eCFR requires an organization to assess each addressable item, implement it if reasonable and appropriate, and otherwise document why not and use an equivalent alternative if that is reasonable.
The access control standard points back to administrative rules. 45 CFR 164.308 on eCFR holds the information access management standard, which calls for policies "for authorizing access to electronic protected health information". Its addressable specifications cover access authorization and "Access establishment and modification", which means how a user's rights are set up, documented, reviewed and changed.
How should role-based access work for review queues?
Role-based access for review queues gives each person the documents and fields their job needs and nothing more. A review queue holds the fields extraction software was unsure of, shown against the original page, so it concentrates PHI from many patients in one screen. Limiting who sees which queue limits how much one account can expose.
A review queue is where a person confirms or fixes what software read from a document. On a fictional EOB, that might be an allowed amount of $160.00 that scored 82% confidence for member ID W123456789 (an example value). The reviewer needs to see the line, the amount and the page region it came from. They do not need every other patient in the batch.
Four design choices keep queues tight:
- Split queues by document type or client. An intake reviewer sees intake forms. A remittance reviewer sees EOBs. A billing service with several clinics gives each clinic's staff only that clinic's queue.
- Show the field in context, not the whole record. A reviewer approving a single field sees the page it came from, not the patient's full chart.
- Separate review from export. Approving a field and exporting a batch are different rights, held by different roles where staffing allows.
- Keep deletion rare. Few people need to delete a source document, and those who do should leave a log entry.
The HIPAA minimum necessary standard is the policy idea behind these limits. Applying it to extraction projects is covered in the minimum necessary standard for data extraction. Queue design and reviewer workflows in general are the subject of the human review category.
In Schema Care, a reviewer sees each uncertain field highlighted on the original page and approves or corrects it; you can see the steps in how the review queue works.
Which access roles does a PHI document team need?
A PHI document team usually needs five roles: someone who brings documents in, someone who reviews extracted fields, someone who owns billing output, an administrator who manages users, and limited support access for the vendor. Each role gets view, edit, export and delete rights matched to the job.
The matrix below is an example for a small billing office that processes EOBs, claims and intake forms. Names, rights and conditions are illustrative, not a standard.
| Role | View | Edit | Export | Delete |
|---|---|---|---|---|
| Intake clerk | Documents they uploaded, until filed | Document type and patient match only | No | No |
| Reviewer | Fields in assigned queues, with the source page | Approve or correct queued fields | No | No |
| Billing lead | All extracted fields for their clinic | Correct approved fields, with a reason | Yes, to the billing system | No |
| Administrator | User list, roles, settings and logs | Roles and thresholds | Audit log only | Source documents, per the retention policy |
| Vendor support | Nothing by default; time-limited access when the customer grants it | No | No | No |
Three notes make the matrix work in practice. First, a person can hold two roles, but each sign-in should still use their own unique ID. Second, the administrator's delete right should follow the retention schedule rather than personal judgment, which is the job of a data retention policy for medical documents. Third, vendor support access should be requested, granted for a fixed window and logged.
Smaller teams sometimes merge roles. A two-person office might have one person who reviews and one who exports. The point is not the number of roles but that each right is held on purpose.
Recording what each role actually does is the other half of access control. Which actions belong in the log is covered under which events belong in a PHI audit log.
Removing PHI access when staff leave or change roles
Removing PHI access when someone leaves or changes jobs is a named part of the Security Rule. Termination procedures, an addressable item in 45 CFR 164.308, call for ending access to electronic PHI when employment or another arrangement ends. A periodic access review catches what offboarding misses.
The workforce security standard in 164.308 asks for policies so that all workforce members have appropriate access and those without access cannot obtain it. Its specifications include authorization or supervision, a workforce clearance procedure, and termination procedures.
An offboarding checklist for a document team might include:
- Disable the person's account in every system that holds documents, not only the main one.
- Remove them from review queues and shared mailboxes, including any eFax inbox.
- Revoke API tokens, SFTP keys or saved credentials tied to their name.
- Collect devices and confirm any local copies of exports are deleted.
- Record the date and who did each step.
Example: one reviewer's last day
This scenario is fictional. Dana, a reviewer at a billing service, finishes on a Friday. Her manager files the offboarding ticket on Thursday. At 5 p.m. Friday an administrator disables Dana's single account in the extraction tool and the billing system, removes her from the EOB and intake queues, and deletes the SFTP key she used to upload batches from a scanner. The manager collects her laptop on the spot, and IT confirms on Monday that the downloads folder held no exports. The ticket records each step with a time and a name.
Two weeks later, the monthly log review shows no sign-ins on Dana's account after Friday. That line in the review record is the evidence that termination happened as written.
Role changes need the same care. A reviewer promoted to billing lead gains export rights and should lose queue rights they no longer use. Without a step for this, people collect permissions over the years.
A periodic access review asks each manager to confirm, user by user, that every account still needs its rights. The rule leaves the timing to the organization, so pick a cycle, write it in the policy and keep the signed results. Single sign-on, where staff use one company login across tools, makes offboarding faster because disabling one account closes many doors.
Shared logins and other access control failures with PHI
The most common access control failures with PHI are shortcuts: shared logins, generic front-desk accounts, administrators doing daily work, and vendor access that never expires. Each one breaks the link between an action and a person, which the unique user identification requirement exists to keep.
Shared logins. A team that shares one "billing" account cannot tell who corrected a payment or exported a batch. The fix is per-person accounts, even when it means paying for more seats.
Generic workstation accounts. A front-desk computer that stays signed in all day lets anyone at the counter open intake forms. Automatic logoff and quick re-entry, such as a badge or short PIN, balance speed and control.
Everyone is an administrator. Giving all staff admin rights avoids support tickets but means any account can change roles or delete documents. Keep the admin role to one or two people.
Standing vendor access. Support accounts that remain active after a fix give an outside party ongoing access. Grant access for a ticket and close it when the ticket closes.
Emergency accounts used for daily work. The emergency access procedure exists for outages and urgent cases. When staff start using the emergency login because it is faster, it becomes another shared account. Keep its credentials sealed, alert on every use, and review each use in writing.
Exports outside the system. A spreadsheet export saved to a personal drive escapes every control described here. Limit export rights, and treat export folders as PHI stores with their own access list.
Each failure has the same root: a right that no one decided to grant. Writing the role matrix down, and reviewing it, makes those rights visible.