The minimum identity checks for health records are documented procedures that verify workforce members, contractors, and other entities are who they claim to be before receiving electronic protected health information (ePHI) access; assign each person a unique account; prohibit shared interactive credentials; remove access when identity or employment status changes; and retain evidence that these steps occurred. For HIPAA Security Rule §164.312(d), Person or Entity Authentication, a two-hour baseline is not a complete identity program, but it can produce a defensible control foundation and an auditor-ready evidence trail. The priority is to prove that the organization has a repeatable verification process operating now, not merely a policy that promises one later.
What is the minimum-viable definition of compliant for minimum identity checks for health records?
HIPAA §164.312(d) requires covered entities and business associates to implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. The regulation does not prescribe a single technology such as biometrics, smart cards, or multifactor authentication. For an external assessment, the minimum viable position is that the organization can show a reasonable, documented method for verifying identity at account creation, authenticating the person or entity during use, and removing access when the identity should no longer have it.
As an internal auditor, avoid labeling a control “compliant” solely because users have passwords. A password may be part of an authentication method, but the assessment will also examine how the account was tied to a verified individual, whether accounts are unique, whether shared credentials exist, and whether the organization can produce evidence of account lifecycle decisions.
| Control objective | Minimum operating condition | Evidence an assessor can test |
|---|---|---|
| Verify claimed identity | An authorized manager, HR process, credentialing process, or vendor sponsor confirms identity before an account is created. | Approved access request, HR roster match, contractor sponsorship record, or credentialing record. |
| Authenticate each user or entity | Each workforce user has a unique username and authentication method; system-to-system accounts are uniquely named and owned. | EHR user list, identity-provider export, service-account inventory, and account naming standard. |
| Prevent untraceable access | Shared interactive accounts are disabled, converted, or formally treated as exceptions with compensating safeguards. | Account review results, exception register, and login audit records. |
| Remove invalid access | A defined process disables accounts for termination, transfer, expired contracts, and compromised credentials. | Termination tickets, deprovisioning logs, and a sample comparison of HR status to active accounts. |
| Demonstrate operation | The organization retains enough records to show the procedure was followed. | Completed sampling worksheet, access tickets, audit logs, and control-owner attestation. |
This baseline applies to more than the primary EHR. Include systems that create, receive, maintain, or transmit ePHI, such as Epic or Oracle Health EHR environments, imaging systems, patient portals, secure messaging platforms, billing applications, virtual desktop environments, and cloud administration consoles that can reach ePHI systems.
What should happen during Hour 0–4?
The first two hours establish the baseline. Hours two through four stabilize obvious weaknesses and assemble the evidence package an external assessor is most likely to request. Do not attempt a broad identity-platform migration during this window.
Hour 0–1: define scope and name an accountable owner
- Identify the systems that hold or provide administrative access to ePHI. Start with the EHR, identity provider, remote access platform, and any clinical-system administrator accounts.
- Name one control owner, usually the IAM lead, security officer, or IT operations manager, and one evidence custodian for the assessment file.
- Obtain the current active-user export from the EHR and identity provider. If Microsoft Entra ID is used, export active users, privileged roles, sign-in logs, and conditional access policy assignments.
- Obtain a current HR or contractor roster containing active, terminated, and transferred personnel status.
- Write a one-page procedure that describes how identity is verified before access is granted and how access is revoked.
Person or Entity Authentication Procedure 1. Manager or authorized sponsor submits an access request. 2. HR, credentialing, or the sponsoring department confirms the requestor's identity and work relationship. 3. IT creates a unique account; shared interactive accounts are not permitted. 4. The system authenticates the user with an assigned credential before ePHI access. 5. HR or the sponsor notifies IT of termination, transfer, contract expiration, or suspected compromise. 6. IT disables or adjusts access and retains the request, approval, and completion evidence. Control owner: Security Officer Evidence retention location: GRC repository / HIPAA / 164.312(d)
Keep the procedure truthful. If contractors are currently verified through procurement sponsorship rather than HR, state that. An accurate, limited procedure is stronger than a mature-looking document that staff do not follow.
Hour 1–2: test whether the current state supports the procedure
Select a small but purposeful sample: five active clinical or billing users, two privileged users, two contractors if applicable, and two recently terminated or transferred workers. For every sampled identity, confirm that the account is uniquely assigned, has a manager or sponsor, and corresponds to an active authorized relationship. For terminated identities, verify that the account was disabled or that there is a documented reason it remains active.
Also identify all accounts with generic names such as nurse1, frontdesk, clinicadmin, or sharedscanner. A shared account may have been created for workflow convenience, but it prevents reliable attribution and weakens the organization’s ability to demonstrate person-or-entity authentication.
Hour 2–4: remediate the clearest gaps and preserve proof
- Disable confirmed orphaned accounts and accounts belonging to terminated personnel, following the organization’s approved change process.
- Disable shared interactive accounts where operationally safe, or document a time-bound exception with an accountable owner and a conversion date.
- Confirm that administrator accounts are separate from daily-use accounts. If a single account is unavoidable temporarily, record it as a risk item rather than ignoring it.
- Save dated exports, sample results, tickets, approvals, and screenshots in a restricted evidence location.
- Create a short exception register that identifies the system, account, risk, compensating safeguard, owner, and target date.
For example, a Microsoft Entra ID environment should show that privileged users are identifiable, sign-in logs are available, and conditional access policies are assigned as intended. If the organization has a policy requiring multifactor authentication for remote or administrative access, verify that the policy is enabled and not merely configured in report-only mode.
What should be completed during Day 1–7?
The first week turns the initial evidence snapshot into a repeatable control. The auditor’s focus should shift from “we checked these accounts once” to “we can show how this will continue to operate.”
| Day 1–7 task | Practical output | Assessment value |
|---|---|---|
| Reconcile identities | Compare HR, contractor, credentialing, EHR, VPN, and privileged-account lists. | Shows that identity verification covers the relevant population. |
| Document account types | Inventory workforce, contractor, vendor, service, emergency-access, and privileged accounts. | Prevents entity accounts from disappearing outside the normal joiner-mover-leaver process. |
| Set review cadence | Monthly privileged-account review and quarterly broader access/identity review, based on risk. | Establishes ongoing monitoring rather than a one-time cleanup. |
| Test deprovisioning | Select recent separations and measure whether accounts were disabled according to policy. | Creates direct operating-effectiveness evidence. |
| Align risk documentation | Add identity-related findings, such as shared accounts or weak remote authentication, to the HIPAA risk analysis and remediation plan. | Demonstrates risk-based decision-making when gaps remain. |
During this week, ensure the written procedure identifies the actual approval sources: HR for employees, credentialing for clinicians, procurement or a business owner for vendors, and a sponsoring manager for contractors. The most common audit weakness is not the lack of a password rule; it is the inability to demonstrate who authorized an account and why that person or entity remained active.
What have you intentionally deferred, and why is that acceptable?
A two-hour baseline should deliberately defer work that requires architecture, clinical workflow validation, procurement, or formal risk decisions. Deferral is acceptable only when it is documented, owned, and protected by interim safeguards.
- Enterprise-wide multifactor authentication: MFA is often the right risk-based upgrade, especially for remote, privileged, and cloud access, but rolling it out to every clinical workflow may require device testing and downtime planning. Do not defer MFA for high-risk access if the risk analysis, contracts, or internal policy already require it.
- Single sign-on and federation redesign: SSO can improve account lifecycle management, but hurried integration can create access outages or unintended privilege mappings.
- Privileged access management: Tools such as CyberArk or BeyondTrust can strengthen administrator authentication and session accountability, but implementation requires account discovery and operational ownership.
- Biometric, badge-tap, or workstation proximity controls: These may improve clinical usability, but they are not the minimum evidence needed to demonstrate §164.312(d).
- Full service-account modernization: Rotating secrets, eliminating embedded credentials, and migrating applications to managed identities should be planned separately, with application-owner testing.
The acceptable interim position is unique accounts, verified sponsorship, meaningful logging, prompt response to account changes, and a documented remediation plan. The unacceptable position is treating known shared access or orphaned accounts as normal because a future identity project exists.
When should the quick-start baseline become a mature identity program?
Upgrade immediately when the organization supports remote clinical access, relies on cloud administration, experiences phishing or credential incidents, uses many contractors, has recurring shared-account exceptions, or cannot reconcile active identities to authoritative sources. An upcoming external assessment is also a trigger: assessors will expect the organization to explain how its initial procedures mature in response to risk analysis findings.
A mature program typically adds phishing-resistant or app-based MFA for privileged and remote access, automated HR-to-IAM provisioning and deprovisioning, periodic recertification by managers, centralized authentication logging, formal service-account governance, conditional access controls, and measured metrics such as orphaned-account rate, termination disablement timeliness, and percentage of privileged accounts protected by MFA.
Next step: Assemble the two-hour evidence package, sample it against the procedure, and present the resulting exceptions and seven-day remediation plan to the HIPAA Security Officer before the external assessor requests it.
