Proposed HIPAA Privacy Rule Update: What CHIME's Provider Concerns Mean for Your Compliance and Security Program

The College of Healthcare Information Management Executives (CHIME), joined by a coalition of 17 health systems, hospitals, and clinics, has formally raised concerns about proposed updates to the HIPAA Privacy Rule — specifically around new identity verification requirements tied to individuals exercising their right of access to their own protected health information (PHI). The coalition's letter, reported by The HIPAA Journal, argues that the proposed verification mandate as drafted could create significant operational burden, delay patient access, and introduce new administrative and technical complexity for covered entities already stretched thin by the HIPAA Security Rule modernization effort.

For security and compliance practitioners, this is not a story to file under "legal's problem." Verification-of-identity controls sit squarely at the intersection of privacy compliance and security engineering. Weak verification invites social engineering, pretexting, and unauthorized PHI disclosure. Overly rigid verification creates denial-of-access risk — which is itself an OCR enforcement target under the Information Blocking rules and the Right of Access initiative, an area where OCR has levied dozens of settlements since 2019. Defenders and privacy officers need to understand what is being proposed, why providers are alarmed, and how to build a verification program that satisfies both security and access obligations regardless of how the final rule lands.

What Is Being Proposed — and Why Providers Are Pushing Back

The proposed HIPAA Privacy Rule update introduces strengthened identity verification requirements that covered entities must apply before disclosing PHI in response to access requests. The intent is defensible: OCR has seen cases where PHI was released to imposters, and the threat landscape in 2025–2026 — with help-desk social engineering campaigns against healthcare organizations and rampant credential phishing — makes verification a genuine security control, not bureaucratic overhead.

The CHIME-led coalition's concerns, however, center on practical implementation:

Prescriptive verification rigidity. Providers argue the proposed language may mandate specific verification steps that don't account for the diversity of access channels — patient portals, in-person requests, third-party requests with valid HIPAA authorizations, and personal representative access. A one-size-fits-all verification bar could conflict with longstanding operational workflows.
Conflict with timely-access obligations. The Privacy Rule already requires access within 30 days (with one 30-day extension). Coalition members warn that layered verification requirements could push organizations past those deadlines, exposing them to Right of Access enforcement while attempting to comply with the new privacy controls.
Burden on smaller providers and clinics. Large IDNs can absorb new identity-proofing infrastructure. Rural hospitals and small clinics — many operating on thin margins and legacy EHR configurations — cannot easily stand up NIST 800-63-aligned identity proofing stacks.
Ambiguity in "reasonable verification." A recurring theme in provider feedback on HIPAA rulemaking is vague standards language that later gets interpreted aggressively in enforcement or post-breach investigations.

Why This Matters to Security Teams

From a defender's seat, identity verification for PHI access requests is an anti-social-engineering control. The same pretexting techniques used against IT help desks — impersonating a user, supplying plausible personal details, requesting a reset or a record release — are used against HIM (Health Information Management) departments and ROI (Release of Information) desks. If your verification process is weak, an attacker impersonating a patient, spouse, or attorney can extract records without touching your network perimeter. That is a reportable breach under HIPAA even though no system was "hacked."

Conversely, if your verification process is a poorly designed bolt-on, you create two failure modes: (1) staff under time pressure bypass it, and (2) legitimate requestors get stonewalled, generating complaints to OCR. The coalition's letter is essentially an early warning that the proposed rule, as written, risks codifying failure mode two.

Executive Takeaways

Regardless of whether the final rule adopts the exact verification language CHIME objects to, the trajectory is clear: regulators expect demonstrable, documented identity verification before PHI disclosure. Organizations that build this capability now — proportionate to risk, integrated with existing workflows — will be compliant under any final rule and better defended against pretexting attacks today.

Inventory every PHI disclosure channel and its current verification standard. Map portal requests, phone requests, mail/fax ROI workflows, in-person requests, third-party authorization-based requests, and personal representative access. Document exactly what identity proofing happens at each today. Most organizations discover significant variance — that variance is your risk surface.
Adopt a tiered verification framework aligned to NIST SP 800-63 identity assurance concepts. Low-risk requests (authenticated portal users releasing their own records to themselves) need lightweight verification. High-risk requests (third-party ROI, changes of address followed by record requests, requests to send PHI to new destinations) warrant stepped-up verification: knowledge-based checks are deprecated — use document verification, call-backs to numbers already on file, or in-person proofing for sensitive releases.
Instrument and audit the ROI/HIM workflow like a security control. Log who requested what, how identity was verified, who approved disclosure, and where the records went. Feed anomalies — bulk requests, requests from attorneys or "patients" with recently changed contact information, repeated failed verification attempts — into your SIEM or case management process. Failed verification attempts are an early indicator of pretexting campaigns.
Train HIM, ROI, and front-desk staff on social engineering with healthcare-specific lures. Generic phishing training does not cover pretexting against release-of-information workflows. Run tabletop exercises where a red-team scenario impersonates a patient, a personal representative, and a law firm. Measure verification bypass rates and close the gaps.
Engage in the rulemaking process and track the final rule closely. If your organization is a CHIME member or belongs to HIMSS, AHIMA, or a state hospital association, coordinate comments through those channels. Assign ownership internally — typically a joint privacy officer / CISO working group — to track the final rule's effective and compliance dates and produce a gap analysis within 90 days of publication.
Reconcile verification policy with the 30-day access clock now. Build verification steps that run in parallel with record retrieval, not serially. If identity cannot be verified, document the specific, reasonable grounds and communicate with the requestor — OCR's Right of Access enforcement history shows that silence and delay, not good-faith verification, draw penalties.

Bottom Line

CHIME and its coalition partners are right that badly drafted verification mandates create compliance collisions and operational burden — but the underlying regulatory direction is sound and inevitable. Attackers are already exploiting weak identity verification at disclosure desks, and OCR will not accept "the rule wasn't finalized" as a defense after an imposter walks away with a patient's records. Treat this proposed rule as the forcing function to professionalize PHI access verification: risk-tiered, documented, audited, and tested against real social engineering scenarios. Organizations that do this work now will be ready for whatever the final rule says — and materially harder to breach through the human channel.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub