Access controls determine who sees what — and whether you can prove it

The Security Rule access control standard at 45 CFR 164.312(a)(1) is unambiguous: implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights.

Translation: if someone can see patient data they do not need for their job, your access controls are broken.

This is Step 6 of our 17-step HIPAA compliance roadmap. We have established your entity status, mapped risks, built policies, secured the physical environment, and hardened endpoints. Now we control who gets through the door — digitally.

Unique user identification: no shared logins

The Security Rule requires that every person who accesses ePHI be assigned a unique identifier — 164.312(a)(2)(i). In practice, this means:

• No shared accounts. If two front desk staff use the same EHR login, you cannot determine who accessed which record. This is both a HIPAA violation and an audit nightmare.
• No generic accounts. "FrontDesk1" is not a unique user ID. Every person gets their own credentials.
• Service accounts must be documented. Automated processes that access ePHI (backup scripts, integration services) should use dedicated service accounts with documented purposes.

Shared credentials are one of the most common findings in OCR investigations of independent practices. They are also one of the easiest to fix. Your EHR supports individual accounts — use them.

Role-based access control (RBAC)

Not everyone needs access to everything. The front desk staff scheduling appointments does not need access to clinical notes. The billing specialist does not need access to psychotherapy notes. The IT consultant does not need access to patient records at all — they need access to the systems that store them.

RBAC means defining roles within your practice and assigning permissions based on those roles:

Common roles in an independent practice

• Provider — full access to clinical records for their own patients, limited access for coverage situations
• Clinical staff (hygienists, medical assistants, nurses) — access to clinical records relevant to their duties, no access to billing or financial data
• Front desk/scheduling — access to scheduling, demographics, and insurance information, no access to clinical notes
• Billing — access to billing records, procedure codes, and insurance information, limited or no access to full clinical records
• Office manager — broader access for operational oversight, with documented justification for the scope
• IT/technical — system-level access for maintenance, no routine access to patient records
• External BA (outsourced billing, clearinghouse) — access limited to the specific data required by the BAA

Patient Protect uses a 9-role access control system that maps to real practice structures, not theoretical models. The goal is the same regardless of platform: every person sees only the PHI they need to do their job.

The minimum necessary standard

The Privacy Rule's minimum necessary standard (45 CFR 164.502(b)) requires that when using, disclosing, or requesting PHI, you limit the information to the minimum amount necessary to accomplish the intended purpose.

This is not just a technical control — it is an operational principle:

• Internal use: When pulling patient data for billing, only the billing-relevant fields should be accessible. The full clinical record is not necessary and should not be exposed.
• Disclosures to other providers: When sending records for a referral, send only the relevant portion — not the entire chart.
• Vendor access: Business Associates should receive only the PHI they need to perform their contracted function.
• Reports and analytics: De-identify data wherever possible. If a staff meeting discusses patient volume trends, individual PHI is not required.

There is one exception: the minimum necessary standard does not apply to disclosures for treatment purposes. A provider treating a patient can access the full record. But even within treatment, role-based access ensures that non-clinical staff do not see treatment records simply because they work in the same practice.

Emergency access procedures

The Security Rule requires an emergency access procedure — 164.312(a)(2)(ii). This addresses how your practice accesses ePHI during a system outage, disaster, or other emergency.

Document the answers to these questions:

• Who has emergency access credentials, and how are they protected?
• Under what circumstances can emergency access be invoked?
• What is the process for granting temporary elevated access during an emergency?
• How are emergency access events logged and reviewed after the fact?

Emergency access is not a backdoor. It is a documented, controlled procedure that ensures patient care can continue when normal access mechanisms fail. Every use of emergency access should be logged and reviewed to ensure it was appropriate.

Audit controls and logging

The Security Rule audit control standard at 164.312(b) requires mechanisms to record and examine activity in systems that contain or use ePHI. You need to know:

• Who accessed what record
• When the access occurred
• What they did (viewed, modified, printed, exported, deleted)
• From where (which workstation, which IP address)

Most EHR systems include audit logging. The question is whether anyone is reviewing those logs.

Log review cadence

• Weekly: Review unusual access patterns — after-hours access, bulk record views, access by users who do not normally view that category of records
• Monthly: Review access to sensitive records (VIP patients, staff members' records, behavioral health notes)
• After incidents: Conduct targeted log review whenever a security concern arises
• Random audits: Periodically pull a random sample of access logs and verify that each access was appropriate for the user's role

Logging without review is meaningless. The log exists to detect inappropriate access — but only if someone looks at it.

What triggers investigation

• A staff member accessing their own record or a family member's record
• A staff member viewing records of patients they are not involved in treating
• Access spikes — a single user viewing an unusual volume of records
• After-hours access from unexpected locations
• Access immediately before or after a staff termination
• Any access that does not match the user's documented role

These patterns do not always indicate malicious intent. Sometimes a staff member is covering for a colleague. Sometimes a provider is reviewing a patient they treated last month. But every anomaly should be investigated and documented — because the alternative is discovering the breach months later through a patient complaint or OCR inquiry.

Vendor access management and BAAs

Every vendor that accesses ePHI needs two things: a signed Business Associate Agreement and appropriately scoped access controls. Vendor access should be:

• Limited to what the BAA authorizes — if the IT vendor is contracted for server maintenance, they should not have persistent access to the EHR's patient database
• Time-bound — access granted for the duration of the engagement, revoked upon termination
• Logged — vendor access should be logged the same way employee access is logged
• Reviewed — periodically verify that vendor access has not expanded beyond its intended scope

The Change Healthcare breach demonstrated what happens when vendor access controls fail at scale: more than 190 million patient records exposed. For independent practices, the risk is smaller in scale but identical in mechanism. If your IT provider's credentials are compromised and they have broad access to your systems, the attacker inherits that access.

Automatic logoff

The Security Rule at 164.312(a)(2)(iii) requires automatic logoff — terminating an electronic session after a predetermined time of inactivity. We covered the device-level implementation in Step 5. At the application level:

• EHR sessions should timeout after 5-10 minutes of inactivity
• Patient portal admin sessions should timeout after a similar interval
• Remote access sessions (VPN, remote desktop) should timeout after 15 minutes of inactivity

The key is layered enforcement: even if a user bypasses or extends one timeout, another layer catches the gap.

Putting it together

Access controls are not a single setting you configure and forget. They are a system:

1. Define roles based on your practice structure
2. Assign permissions based on minimum necessary
3. Issue unique credentials to every user
4. Log everything and review regularly
5. Manage vendor access under documented BAAs
6. Enforce automatic logoff at every layer
7. Document emergency access procedures
8. Audit and adjust as roles, staff, and systems change

When access controls work, they are invisible to compliant users and impenetrable to everyone else. When they fail, you find out through a breach notification — not through your audit logs.

---

This is Step 6 of our 17-step HIPAA compliance roadmap. Previous: Step 5 — Secure Devices and Endpoints. Next: Step 7 — Strengthen Patient Rights.