Last week, I attended HIMSS 2025 in Las Vegas and came away with four big themes that stood out for me: (1) the industry’s growing focus on Identity & Access Services (IAS) and rock-solid identity verification, (2) the push to expand non-treatment use cases for interoperability (like payment and healthcare operations), (3) the urgent need for modernized consent management, and (4) the overarching importance of trust to tie it all together. Yet of all these, for me, IAS is the real showstopper: if we don’t get identity and access right, the rest of our digital transformations—from AI-driven insights to cross-network data sharing—could quickly unravel. In today’s post, I want to zero in on IAS—where it fits into HIPAA’s right of access, where personal representatives enter the picture, and why it risks becoming a Trojan Horse for unauthorized data if we don’t take the proper safeguards.
HIPAA Right of Access
Under 45 CFR § 164.524, patients have a right of access to their own medical records:
“Except as otherwise provided in § 164.524(a)(1) and (2), an individual has a right of access to inspect and obtain a copy of protected health information about the individual in a designated record set…”
This right is foundational to HIPAA, and covered entities (CEs) must comply unless a specific exception applies. OCR has recently ramped up enforcement here, issuing multiple financial penalties against providers who fail to give patients timely, complete access to their PHI. Moreover, refusing or unduly delaying access can also constitute information blocking under the 21st Century Cures Act (45 CFR Part 171).
IAS solutions essentially leverage this right of access to facilitate data exchange when patients request their records electronically. The concept is straightforward: if a patient says, “Send my records to me (or my designated app),” a covered entity is required to do so—no HIPAA authorization is needed.
Distinguishing the HIPAA Right of Access from HIPAA Authorization
Because HIPAA also allows an authorization pathway (45 CFR § 164.508) for releasing PHI to third parties, many people think a HIPAA Authorization and the right of access are interchangeable. They are not. Here’s are the key differences:
[Note: these conclusions are based on HIPAA only and do not include any impact of the Information Blocking Rule.]
| HIPAA Authorization | Right of Access |
| Permits, but does not require, a covered entity to disclose PHI to the requesting entity. | Requires a covered entity to disclose PHI, except where an exception applies |
| Requires a number of elements and statements, which include a description of who is authorized to make the disclosure and receive the PHI, a specific and meaningful description of the PHI, a description of the purpose of the disclosure, an expiration date or event, signature of the individual authorizing the use or disclosure of her own PHI and the date, information concerning the individual’s right to revoke the authorization, and information about the ability or inability to condition treatment, payment, enrollment | Must be “in writing,” signed by the individual, and clearly identify the designated person and where to the send the PHI. |
| No timeliness requirement for disclosing the PHI Reasonable safeguards apply (e.g., PHI must be sent securely) | Covered entity must act on request no later than 30 days after the request is received |
| Reasonable safeguards apply (e.g., PHI must be sent securely) | Reasonable safeguards apply, including a requirement to send securely; however, individual can request transmission by unsecure medium |
| No limitations on fees that may be charged to the person requesting the PHI; however, if the disclosure constitutes a sale of PHI, the authorization must disclose the fact of remuneration | Fees limited as provided in 45 CFR 164.524(c)(4) |
Because IAS typically relies on a patient’s right of access, covered entities must provide the requested PHI if the individual (or, as we’ll see, the individual’s authorized personal representative) asks for it—no “discretion” is allowed. That’s precisely what makes IAS so powerful, yet potentially risky if exploited by third parties.
IAS at HIMSS: Excitement, Security, and Identity Verification
At HIMSS 2025, IAS vendors and stakeholders underscored that identity proofing is the first line of defense: if an IAS platform can’t confirm someone’s identity to a high level of assurance, it risks inadvertently releasing PHI to impostors. This emphasis aligns with the TEFCA IAS Exchange Purpose Implementation SOP, updated in August 2024 and published by the Sequoia Project (see full SOP). Under the updated SOP, IAS Providers must contract with a credential service provider (CSP) that is vetted by an RCE-selected approval organization and verifies each user at NIST IAL2. While the SOP does not explicitly list organizations like the CARIN Alliance as approved CSPs, CARIN continues to lead initiatives around consumer-facing data standards—ensuring patients can prove their identities securely and consistently. Meanwhile, CLEAR is piloting biometric authentication in the SHIN-NY HIE to further advance IAS identity proofing.
Yet, while verifying someone’s identity is crucial, a bigger issue lurks in scenarios where an individual claims to be the patient’s personal representative (PR) and demands records under the right of access. For example, an “ambulance chaser” or another party could allege it has PR authority—but in reality, it might be using a blanket HIPAA authorization or partial legal authority that doesn’t truly “stand in the patient’s shoes.” That’s where the Trojan Horse problem truly begins.
Personal Representatives: The Real Deal or a Trojan Horse?
Under 45 CFR § 164.502(g), a “personal representative” is someone authorized under applicable law to act on behalf of the individual in making healthcare-related decisions. HIPAA requires covered entities to treat a valid personal representative as if they were the patient—allowing them the same rights of access and control over PHI (i.e., to “stand in the shoes” of the patient):
“A covered entity must treat a personal representative as the individual … with respect to protected health information relevant to such personal representation.” – (45 CFR § 164.502(g))
Depending on state law, PR status can be broad (e.g., a general healthcare power of attorney) or limited (e.g., only for a specific medical decision). The complexities multiply if you consider:
-
-
-
- Parents of minors (subject to various exceptions),
- Guardians for incompetent adults,
- Executors or administrators of an estate for deceased individuals,
- Others with narrow or special legal authority.
-
-
IAS magnifies PR concerns because it rests on the premise that if someone requests records under their HIPAA right of access, the covered entity must comply. If that “someone” is a proper personal representative, no problem—they’re legally standing in the patient’s shoes. But if they’re not truly the PR, or if the third party is incorrectly using a broad HIPAA authorization tp pose as though they are the patient, IAS systems might automatically release records with little chance to intervene.
Thus, risks with allowing PRs to access and use an IAS applications include:
🔹 Trojan Horse: A questionable third party could bypass the usual scrutiny around HIPAA authorizations by simply claiming to be the patient’s authorized personal representative.
🔹 State Law Gaps: PR definitions vary widely from state to state. So, an IAS vendor or a provider in one region might not realize the “authority” claimed in another region is invalid or incomplete.
🔹 Patient Not Really Involved: Sometimes a patient is only partially aware—or entirely unaware—that a third party is using their “right of access” to gather data for unrelated purposes (e.g., class-action suits, data brokering).
When a Patient vs. a Third-Party Initiates Access
Another challenge is determining whether it’s truly the patient wanting to access or direct their medical information, or a third party merely using the patient’s identity—like a predatory app that enrolls individuals and exploits that connection to the data source. Under HIPAA, this distinction matters greatly. If the patient personally says, “Send my PHI to me (or my app),” the covered entity is required to comply under 45 CFR § 164.524—unless a specific exception applies. If a third party uses a HIPAA authorization, the covered entity may (but need not) disclose, provided the authorization meets the strict requirements in 45 CFR § 164.508.
It gets even murkier when a third party claims to be a PR: the CE must confirm that the individual truly has legal authority under state law. If they genuinely stand in the patient’s shoes, the CE must treat them as the patient; if they don’t, releasing the records could be a major HIPAA violation. This scenario creates a loophole that third parties or data connectors and aggregators could exploit—posing as a personal representative to trigger the “must disclose” obligation intended only for the patient, thereby exposing PHI the individual never truly consented to share.
The IAS Trojan Horse in action might look like a data broker convincing hundreds of patients to sign confusing forms or enroll in applications—or even a mass tort attorney sitting in a back room, scribbling “HIPAA authorization” on behalf of clients they claim to “represent.” Armed with this presumed authority, they inundate IAS vendors with 164.524 Right of Access requests, each designed to appear as if the patient is initiating it directly. Because these requests seem legitimate under HIPAA, the covered entity or IAS vendor has little leeway to scrutinize the motives—potentially releasing massive amounts of PHI without the patient fully understanding what’s happening. And once that PHI is out the door, data aggregators can exploit it for anything from marketing or resale to large-scale litigation. It’s the perfect Trojan Horse scenario: cloaked under the guise of valid patient access, but ultimately undermining the very privacy protections HIPAA was designed to safeguard.
⚠️ NOTE: Anyone contemplating such an approach should be aware that under 42 U.S.C. § 1320d-6, HIPAA’s criminal provision imposes severe penalties—including fines and imprisonment—on those who knowingly obtain or disclose individually identifiable health information without proper authorization.
Avoiding IAS Pitfalls and Strengthening Protections
Avoiding IAS pitfalls is not just about checking boxes—it’s about constructing a fortress around patient data in an increasingly digital healthcare landscape. A misstep in verifying a personal representative’s authority or mishandling the nuances between a right of access and a HIPAA Authorization can have far-reaching consequences. The following measures are essential for IAS vendors and covered entities to maintain robust, HIPAA-compliant protections:
-
-
- Clarify Personal Representative Status: IAS vendors and covered entities need robust workflows to confirm that any claimed PR actually has legal authority. A mere HIPAA authorization does not automatically make someone a personal rep.
- Refine Policies for Authorization vs. Right of Access: Staff must know that right of access requests (164.524) are mandatory and subject to specific fees and deadlines, whereas an authorization is permissive and has no 30-day rule or fee cap.
- Identity Verification: Identity proofing solutions—like CLEAR’s biometrics or the CARIN Alliance frameworks—solve the “are you who you say you are?” question. But a second question is, “Do you truly stand in the patient’s shoes?” That requires a legal analysis of representative authority.
- Monitor for “Bulk” or Suspicious Requests: Even under the right of access, suspicious patterns—such as large-scale or automated requests—might merit a deeper review. Legitimate patients rarely request 1,000+ records at once.
- Stay Vigilant on State Law Nuances: Because “personal representative” definitions vary widely, multi-state covered entities (and IAS vendors) must coordinate with legal counsel in each jurisdiction.
-
An Ancillary Observation: The Irony of IAS’ Impact
One of the ironic outcomes of IAS is that it can empower patients to effortlessly transfer their entire medical record directly to their attorney—a capability that was once unthinkable at scale. Under HIPAA’s right of access (45 CFR § 164.524(c)(3)(ii)), a patient can instruct a covered entity to send their PHI to a designated recipient, whether that be their own personal health record or legal counsel (see HHS FAQ “Can an individual, through the HIPAA right of access, have his or her health care provider or health plan send the individual’s PHI to a third party?”).
In my previous post, Unmasking the Issues: The Final Resolution in the Epic v. Particle Health Dispute, I discussed a controversy that rocked the national network world when Epic suspended access to Particle Health, contending that it misapplied the “treatment” standard to justify its data access practices and effectively allowing third parties to exploit the system. It is important to note that when patients themselves control the request and transfer their records to their attorneys, that is entirely appropriate; however, this must be carefully distinguished from situations where third parties—such as ambulance-chasing law firms—mislead patients into using IAS to funnel records to them.
With IAS, the very mechanism mandated by HIPAA could be used legitimately by patients to transfer their records, even to law firms, creating an uncomfortable new reality for covered entities that have never had to process such mass, legally compliant transfers. Thus, as the industry moves toward this long-overdue patient-centric model, it must design and enforce robust safeguards to ensure that IAS reinforces trust and transparency rather than serving as a Trojan Horse that undermines patient privacy and enables exploitation.
Conclusion: Fortify the Gates Before It’s Too Late
IAS is long overdue—a critical evolution that empowers patients to control their own health records by harnessing HIPAA’s mandatory right of access. While this innovation is essential for modern healthcare, the industry must address its inherent risks now before they spiral out of control. The Epic v. Particle controversy, where “treatment” was stretched to permit third parties unauthorized access, serves as a stark warning. If left unchecked, IAS could become a Trojan Horse, enabling predatory actors to exploit the system under the guise of personal representation. The time to fortify IAS with robust identity verification, clear policies, and strict oversight is now, ensuring that this long-awaited advancement remains a tool for patient empowerment—not a backdoor to data abuse.
