The Office of the National Coordinator for Health Information Technology (ONC) reports that in 2025, 65% of individuals accessed their health records online, 57% used app-based access, and 51% used proxy or caregiver access. Those numbers mean patient identity infrastructure now serves a population that varies widely in device security, technical literacy, network trust, and relationship complexity. A caregiver logging in from a shared tablet to check a parent’s lab results presents a different identity challenge than an employee accessing a records portal.

Patient identity is often treated as just a login problem. That framing collapses three distinct challenges into one: verifying that a person is who they claim to be, matching that person to the correct clinical or payer records across systems, and determining what that person or their delegate should be allowed to do. When those layers blur, security gaps and patient friction compound in ways that no single authentication upgrade can solve. The result is a false tradeoff. Teams believe they must choose between making access easier for patients and strengthening identity controls. A well-designed healthcare customer identity and access management (CIAM) strategy eliminates that tradeoff by applying the appropriate level of assurance to each interaction.

Current challenges in healthcare CIAM

Outside healthcare, CIAM platforms can typically assume that a user controls one account, authenticates on their own behalf, and interacts through a single channel. Healthcare use cases extend well beyond those assumptions.

A single patient may have portal accounts across multiple providers and payers, each with different demographic records and varying levels of matching confidence. Proxy access is no longer an edge case. It now represents roughly half the user population. ONC data show that caregiver and proxy access doubled from 24% in 2020 to 51% in 2025. As a result, healthcare CIAM systems must model explicit delegate relationships with their own identity verification requirements, authorization boundaries, and revocation paths. Platforms that support only a single authenticated principal are poorly aligned with real-world healthcare access patterns.

Channel diversity further complicates the challenge. Patients interact through Web portals, native applications, call centers, kiosks, and increasingly through Trusted Exchange Framework and Common Agreement (TEFCA)-connected third-party applications. Each channel carries different device trust signals, session risks, and regulatory expectations. A CIAM architecture that treats each channel as a separate identity silo creates duplicate accounts, weakens patient matching, and forces support teams to reconcile identities manually.

Three layers that define CIAM architecture in healthcare

The most consequential architectural decision in healthcare CIAM is whether to separate identity proofing, record matching, and access authorization into distinct layers or continue treating them as a single login flow.

Identity proofing establishes confidence that a person is who they claim to be. For sensitive first-time access, record release, or TEFCA individual access, that means identity assurance level 2 (IAL2) or an equivalent level of assurance: validating government-issued identity evidence, verifying that the applicant is the rightful owner of that evidence, and checking for identity fraud indicators. Proofing is not authentication. It occurs once or infrequently, and its output is a trust artifact that subsequent authentication events can rely on.

Record matching links a verified identity to the correct clinical or payer records. ONC defines patient matching as identifying and linking a patient’s data within and across health systems using demographic attributes such as name, date of birth, phone number, and address. Poor matching creates duplicate records and can result in misattributed information.

Access authorization determines what a verified and matched individual, or their delegate, is permitted to do. This includes read versus write permissions, record-level scoping, consent enforcement for caregiver access, and session-level risk evaluation.

Designing CIAM for both security and patient experience

A layered architecture matters only if it supports real patient workflows. Five questions can help organizations evaluate whether a CIAM architecture successfully balances access and security.

Does risk determine friction, or does every patient receive the same experience?

Checking an appointment time does not carry the same risk as releasing a complete medical record or changing an address on file. Applying uniform friction to both scenarios either slows routine access or under-protects sensitive actions. The ID Dataweb risk engine evaluates each session against behavioral baselines, device intelligence, and credential signals, then steps up verification when risk warrants it.

Can the solution deliver IAL2 proofing that patients will actually complete?

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63A-4 requires IAL2 processes to validate identity evidence, confirm the rightful owner, and screen for forged documents and injection attacks. TEFCA’s Individual Access Service (IAS) workflow establishes IAL2 as the minimum requirement for individual patient access. The ID Dataweb platform’s proofing workflows are IAL2 certified, enabling organizations to meet both NIST standards and TEFCA credential service provider requirements without building a separate proofing stack.

How does the solution handle caregivers and delegates?

When half of patients use proxy access, delegation is not an edge case. An identity threat detection and risk mitigation platform that treats delegation as a shared credential cannot model the relationships, permissions, and accountability that healthcare access requires.

Do identity signals persist across channels, or does each channel start from zero?

A patient who completes IAL2 proofing through a portal should not have to repeat the process when calling a support line or using a TEFCA-connected application. ID Dataweb works across Web, mobile, call center, and in-person channels through a single integration point using OpenID Connect or REST APIs. As a result, a proofing event in one channel produces a trust decision that other channels can consume.

Can fraud and IAM teams see the same telemetry?

Failed proofing attempts, impossible-travel signals, unusual device changes, risky recovery workflows, and indicators of delegate abuse matter to both teams. ID Dataweb surfaces these signals through a single decisioning layer rather than siloed dashboards, making it easier to detect attacks that move from identity fraud to access abuse.

Conclusion

Healthcare CIAM has evolved into a control layer where patient access, interoperability obligations, and identity security converge. Meeting those demands requires an architecture that keeps proofing, matching, and authorization distinct while raising or lowering assurance based on what a patient is trying to do. Rather than forcing every interaction through the same gate, organizations can apply the appropriate controls to the appropriate risk. When designed this way, patient access and identity security reinforce one another instead of competing.