Article

Patient Matching - Part 3: Digital Identifiers: Moving Beyond Repeated PII Exchange in Healthcare

In Part 1 and Part 2 of this series, we discussed approaches to identity resolution and matching patient identities between shared service identity providers and individual healthcare organizations. This Part 3 addresses what happens after a match is made between systems.

Repeated exchange of sensitive personal data creates unnecessary privacy risks and friction. Digital wallets and IAL2 Credential Service Providers offer a better path forward: match once deterministically, then use digital identifiers for all future interactions. 

This approach is similar to banking and debit cards. You provide your personal information to a bank to identify you. After identification, your bank issues you a debit card with a random account number on it. You then use that credential to identify yourself to organizations to pay.

From Deterministic Match to Digital Identifier

The pattern is straightforward but powerful. When a patient first connects their digital wallet to a healthcare organization, the system performs a deterministic match using one of our Tier 1 strategies—typically Name + DOB + SSN or Name + DOB + Address with longitudinal history. This initial match establishes with near-certainty that the digital credential belongs to the correct patient in the healthcare organization’s master patient index.

Once that match succeeds, the healthcare organization and the digital wallet CSP exchange a digital identifier—a unique token that represents this specific patient-credential pairing. From that point forward, the patient can authenticate using this digital identifier rather than repeatedly sharing their Social Security Number, address history, or other sensitive personal information.

As FTC Commissioner Mark Meador recently emphasized in remarks about age verification systems, modern identity technologies “rely on third-party providers who keep that data secure. Third parties who can contract with social media companies, or other online service providers, to simply verify whether a user is old enough to access a product, without turning over any raw personal data. This is elegant. It is efficient. It is secure.”

The same principle applies in healthcare. After the initial deterministic match, the healthcare organization doesn’t need to see your SSN again. They don’t need to verify your current address for the fifteenth time. They simply check: does this digital identifier correspond to patient record #847293 in our system? The answer comes back yes or no, without exposing underlying personal details.

This approach dramatically reduces the attack surface for identity theft. Instead of storing and repeatedly transmitting SSNs, addresses, and dates of birth across systems, healthcare organizations can work with pseudonymous identifiers that mean nothing to an attacker who intercepts them. The identifier only gains meaning through the secure relationship between the CSP and the healthcare organization’s identity resolution system.

Audit Trails as the Foundation of Trust

Digital identifiers aren’t magic tokens that automatically guarantee identity. Their trustworthiness depends entirely on the quality of evidence supporting them—specifically, the audit trail documenting how the identifier was created and linked to a real person.

Every digital identifier should be backed by an evidence chain answering three questions:

  1. How was identity established? The Credential Service Provider (CSP) should document the Identity Assurance Level (IAL) achieved during credential issuance. For healthcare contexts, this should be IAL2 minimum—meaning the CSP validated personal data in records, verified government-issued photo ID, performed liveness detection, and confirmed the person presenting credentials matched the identity documents. The audit trail should capture identity resolution, identity validation, identity verification and when those events occurred.
  2. How was the initial match performed? When the digital identifier was first linked to the patient’s healthcare record, which deterministic strategy succeeded? Did the system match on Name + DOB + SSN? On Name + DOB + Address with longitudinal history? Both? The healthcare organization should log which attributes matched, the confidence score of the match, and whether any manual review was required. This creates accountability: if a matching error occurs later, investigators can trace exactly how the linkage was established.
  3. What is the system’s accuracy rate? Feedback loops are critical for accountability and iterative improvements. No system is perfect, and identity theft and fraud are significant issues that plague all industries. When things go wrong, there must be a mechanism to trace why it went wrong and an action plan to correct it.

These audit trails serve multiple critical functions. They enable fraud detection—if someone attempts to use a stolen digital identifier, anomaly detection systems can compare current behavior against the verified identity’s historical patterns. They support compliance investigations—when regulators ask how a healthcare organization verified a patient’s identity, the audit trail provides definitive answers. And they facilitate error correction—if a patient reports they’re seeing someone else’s medical records, the audit trail shows exactly where the matching process went wrong.

The HL7 FAST Identity Implementation Guide emphasizes this documentation requirement, noting that identity assurance levels and verification evidence should be conveyed in match transactions so all parties understand the strength of identity claims. Without robust audit trails, digital identifiers become “trust me” tokens with no accountability.

Server-Side vs. Client-Side Architectures

Digital wallet architectures exist on a spectrum between two poles: server-side systems where the CSP maintains visibility into credential usage, and client-side systems where credentials live entirely on the user’s device with no intermediary observing transactions.

Server-side architectures route authentication requests through the CSP’s infrastructure. When a patient authenticates to a healthcare organization, the CSP sees the transaction, can apply fraud detection algorithms, and maintains audit logs. This visibility enables powerful protections. If someone steals a patient’s device and attempts to authenticate from an unusual location at an odd time, the CSP can flag or block the transaction. If a sophisticated phishing operation attempts to harvest credentials at scale, the CSP’s fraud detection systems spot the pattern and intervene.

Commissioner Meador’s remarks touch on this protective role: the market is developing systems that “meet the needs of the moment in efficient and sophisticated ways” while keeping data secure. Server-side architectures excel at this when identity theft and fraud risks are elevated—which they clearly are in healthcare, where medical identity theft can lead to incorrect treatment, financial fraud, and life-threatening errors in medical records.

Client-side architectures store credentials locally on the user’s device and conduct authentication without CSP involvement. The patient’s phone or hardware token communicates directly with the healthcare organization using cryptographic proofs that don’t require a third party to observe or validate. This maximizes privacy—the CSP never learns when or where the patient seeks healthcare, what providers they visit, or how frequently they authenticate.

Client-side approaches shine in contexts where identity theft risk is genuinely low and privacy concerns are paramount. Routine prescription refills at a known pharmacy. Scheduling an appointment with a longstanding primary care doctor. Accessing educational materials in a patient portal. These interactions rarely attract sophisticated attackers, and patients reasonably want their healthcare activities hidden from all external observers—including their CSP.

The best digital wallet systems offer both modes. They recognize that healthcare encompasses scenarios with radically different risk profiles. Authorizing a hospital to share your complete medical history with a new specialist you’ve never met carries high fraud risk and deserves server-side protections. Logging into a patient portal to download a copy of your vaccine records for your own files carries minimal risk and deserves maximum privacy.

A mature credential architecture might work like this: During initial enrollment and high-risk transactions (new provider relationships, controlled substance prescriptions, records release authorizations), default to server-side verification with full audit trails and fraud detection. For routine, low-risk interactions with established relationships, offer client-side authentication that leaves no trace with the CSP. Empower patients to choose their preferred mode based on their individual threat model and privacy preferences.

This flexibility aligns with Commissioner Meador’s vision of systems that “empower, rather than replace” people’s autonomy while still providing robust protections. The technology should serve the user’s needs, not force users into a one-size-fits-all model.

The Path Forward

Digital identifiers represent the maturation of healthcare identity management. Instead of treating every authentication as a fresh identity verification problem requiring sensitive PII exchange, we can establish trust once through deterministic matching, then maintain that trust through secure tokens backed by auditable evidence.

For healthcare organizations, this means implementing systems that can accept digital identifiers from IAL2+ CSPs, maintain mappings between identifiers and patient records, and log all matching decisions with sufficient detail for future audit. For CSPs, this means building identity verification processes that generate trustworthy audit trails and offering both server-side and client-side authentication modes to match diverse use cases.

The 42% of healthcare organizations currently collecting but not using SSNs for matching should prioritize getting their deterministic matching right first. Digital identifiers build on top of accurate matching—they don’t substitute for it. Once that foundation exists, digital identifiers eliminate the need to repeatedly exchange the very SSNs and addresses that make matching possible in the first place.

We can deliver a future where cancer patients don’t need to manually transport their records across different systems because patient matching has failed them. Healthcare identity management is ready for that future. The question is how quickly we’ll embrace it.