Child pages
  • File Lists

Patient Matching and Identity Assurance


This is a presentation from the Kantara Health Identity Assurance Work Group in response to a call from the ONC for input on patient matching by August 31.


NIST 800-63 has focused on the use of identity documents as a means to support identity assurance. We propose to focus on identity assurance that can be made available in digital format. And in particular we have adopted the recommendations of the RAND report to focus on the use of the smartphone as the tool that enables both identity assurance and authentication. We take a forward-looking approach here to include evolving as well as existing identification methods so that changes to self-issued identifiers or a national health care identifier can be easily accommodated.


Smart phone solutions will utilize the patient’s (or guardian’s) phone with a mobile app that can be downloaded from a source of the patient’s choosing, which will include their own health care providers in many cases. The mobile app directs the patient to complete a number of steps that confirm or “proof” the identity of the individual.  Once the patient is proofed, their smartphone can then be bound to their identity as known by the service provider. The phone can then be digitally presented in person, or online to authenticate the patient and assure that only the patient’s records are retrieved. Broad adoption of the technology will enable any enrolled health care provider or interchange system to immediately recognize the user for roaming or emergency care across the nation or around the world.


The use of the smart phone for identification will soon be able to include one’s mobile driver’s license and other digital credentials. It One can already use its the smart phone’s   camera to capture formatted data like a QR code. The interworking of healthcare identifiers with other user’s credentials should be a high priority goal. It should be recognized that T t here are technical solutions in use in banking today that utilize the individual’s own smart phone plus mobile app to perform all the steps necessary to comport with IAL2 and then to use that same smart phone as a mobile AuthN to comport with AAL2.


An Example of the Mobile Identity Assurance Process:

1)     The patient is directed by their healthcare provider or health plan to download a mobile app that will be used as their trustworthy “mobile digital identifier” when they need to identify themselves across the enterprise

2)     The patient downloads the app and is prompted to enter a few pieces of data. (The cell phone number is the one piece of data most often requested.

3)     In the background a query is done to the Mobile Network Operator (telco) to pull forward the PII associated with the person who is associated with that number and with this device.   Alternatively, the patient can manually enter a few pieces of PII such as their full name, email, cell phone number, DOB and address.

4)     The patient is next asked by the mobile app to take an image of the front and back of their DL or State-issued ID (a DL that meets Real-Id requirements is best) using their smart phone . . In the future, the patient could link their mobile driver license when requested to complete this step.

5)     The patient is then asked prompted by the app to take a selfie using their smartphone (the selfie is typically in the form of moving image that is captured in real-time)

6)     In the background the security features and the format of the DL is authenticated as being correct and the facial image of the patient on their DL is then compared to the dynamic image   captured from a the mobile device.

7)     Provided that all of this data lines up , the person’s identity is then deemed appropriate to meet IAL2.


Additional data validation may be performed such as confirming the patient’s PII with a 3 rd   party like a credit bureau or confirming their address with the USPS.


This identity assurance process typically takes less than 1 minute to complete and the PII captured is then used by the health system or payer to either establish a new record or is used to match to a possible existing record.


A Synopsis of the Mobile Identity Authentication Process:

Establishing the smartphone as the patient’s digital authenticator also takes a few steps and, depending on the technology vendor, is comprised of some different elements – but overall the primary objective is to bind the smartphone to the individual’s identity and to their record as maintained by the service provider. The ability of the smart phone to protect user authentication secrets is key to meeting high levels of authentication assurance.


The patient’s biometric (finger or face) will have already been captured and associated with their smartphone when they first began using their device.  This biometric becomes a 2 nd   factor in the MFA design.   Often a “spare” 2 nd   factor is required (like a PIN code) in case the biometric fails and the patient needs another way to accomplish the Auth transaction.   (A PIN code is also useful as a fallback 2 nd factor as many of us are now wearing face masks and can’t use our facial biometric image as our default 2 nd   factor).  


Bi n ding the device to the individual’s identity and to their record can be as simple as using the mobile app to read a one-time QR code created by the service provider for this purpose.


Once the patient’s mobile device is bound to the ir   patient’s identity that has just been proofed,   the individual has completed all necessary IAL2 and AAL2 steps and is now in a position where they can use their digital AuthN across any channels (in-person, online, mobile, tele, kiosk) that the service provider supports.


The Mobile Authenticator in Action – Use Cases:

Online:     As an alternative to the traditional username and password feature for online account access, the service provider can now offer a more secure process that allows the patient to login using their smart phone.  The patient enters their username or account number at the online website and a push notification is sent to the app on their smartphone.  The patient opens the notification and reads the query “ Would you like to login to XYZ the patient portal? or “ Would you like to request an appointment? The patient clicks YES or NO in the app and, if YES, is prompted by the mobile app to provide their biometric as their 2 nd factor.  Once this is read the Authentication process has been completed and the service provider can now provide access to the patient to their portal knowing with confidence that the individual requesting access is indeed the patient and is not a fraudster using a stolen username and password.


A screenshot of a cell phone

Description automatically generated

In-person: Instead of the patient writing their name on a clipboard and the registrar asking the patient to tell them their name and date of birth when they check-in for an appointment, the registrar instead asks the patient for their username.  This is the same username the patient uses for online access.


The register can type the patient’s username into a Check-In screen established for just this purpose. When near field technology is deployed to the provider, a simple tap of the phone and verification of the patient’s photo will simplify the process further.


A push notification will then be triggered and will be sent to the app on the patient’s smartphone.  The patient opens the notification and reads “ Are you checking in for an appointment at Clinic XYZ? ”  The patient clicks YES or NO in the app and, if YES, is prompted by the mobile app to provide their biometric as their 2 nd factor.  Once this is provided the Registrar now sees on her screen an identity synopsis of the patient who just checked-in including their name, address, DOB, facial image and any another other details that have been determined to be useful to facilitate the check-in process. 


A hand holding a cellphone

Description automatically generated


Most importantly this identity synopsis is linked to the patient’s Medical Record allowing the registrar to retrieve the one and only medical record associated to this patient at this facility.  There is no need to manually search for the record using name and DOB and select the record from a pick list that seems to best match the query.


  • This process is privacy preserving as the patient doesn’t need to write down their name on a clipboard nor tell the registrar any PII in a public waiting room.
  • This process is highly secure as only the actual patient can check-in using this service.  Even if the patient’s smartphone was stolen, only the true patient could correctly provide the biometric 2 nd factor needed to complete the transaction.
  • This process enforces a no-contact interaction between the patient and the registrar.  No paper or pen is used.  The only piece of data that is verbally conveyed between the two is the patient’s username which is not a data element in this design that exposes or subverts the security around the patient’s account.


Kiosk:  Instead of checking in with a registrar the patient may prefer to check-in at a kiosk.  This design allows the patient to enter their username on a freestanding kiosk or tablet available in the waiting room.  This triggers a notification to the patient’s app and following the same process for in-person check-in, the patient would Authenticate themselves from their smartphone. Near field identification would simplify this process as well.


The patient’s identity would then be added to a check-in queue that the registrar can refer to as they process patient arrivals.

  • This process allows a second path for patient check-in which may be especially useful for offices that are very busy or understaffed
  • This process is attractive for environments that don’t have a front-desk for patient check-in such as a retail clinic at a pharmacy


Mobile: Many healthcare providers are asking their patients to call or text them when they pull into the parking lot for their appointment.  The mobile authentication design can also work to facilitate this use case.


The patient is told to use their mobile app to “arrive” themselves when they pull into the parking lot.  The patient opens their mobile app and clicks on a button that says “ARRIVED”.  Because the the smartphone can detect its geolocation the app is aware of the patient’s proximity to the provider’s office and can deduce that the check-in is intended for that provider’s facility.  


The patient now receives a push notification asking: “ Are you checking in for an appointment with Dr. Z?”  The patient answers YES and provides their biometric as their 2 nd factor.  Once again, their identity is then added to a check-in queue that the registrar can refer to as they process patient arrivals.

  • This process is especially useful to maintain social distancing


Promotes a Patient-Centric Design

Most all healthcare organizations talk about putting the patient at the center of care; however, a true patient-centric design should also include the many exchanges of data that occur between providers that is often hidden from the patient.  Upon registration a patient is typically informed that under HIPAA their data may be exchanged with other parties for purposes of treatment, payment and healthcare operations.  The average patient probably doesn’t understand what this statement means and as a result is likely not aware that their clinical, financial and administrative data is being shared between parties involved in their episode of care.


With patients using a common mobile app experience it would be easier for healthcare organizations to inform notify the patient when a ny PHI exchange goes outside of the practice where the data was stored .  This would help alert patients to suspicious exchanges and could make them a more conscientious manager of their clinical data.    


A Foundation for a National Health Identifier

While many models for a national health identifier are being discussed, it is critical that regardless of the process that is used to establish a unique identifier that the enumerator ha s a way to bound to the mobile authenticator.  In this manner the patient could u se a digital “health wallet” on their mobile device to store and exchange their national health identifier(s) to whomever they wish.

As an example, Direct Trust has enabled a process by which a patient can receive their own unique Direct email address.  To accomplish this goal the patient must first be proofed to what was once known as LOA3 and is now known as IAL2 and AAL2.  A patient with a Direct email address is now able to securely exchange emails with their healthcare providers bypassing the use of the patient portal for this type of communication.  Another An added benefit of the Direct email address is that it is unique and assigned by an authoritative source.  As a result, even if the patient never uses the ir Direct email address to communicate with their health care provider, the Direct email address can serve as a unique health identifier that can be discovered and trusted by reliant parties.  In this manner the Direct email address can play the role of national health identifier – an objective that has seemed out of reach for many years.  



Mobile identity assurance and authentication is both quick and easy. It combines the ease of a mobile app experience while at the same time increasing privacy and security.  This design also allows the service provider to roll out this new process over time while still supporting their legacy online username/password processes and in-person check-in workflows.




Carmen Smiley Please send your comments and input to

Prepared for the Kantara Health Identity Assurance Work Group by:

Catherine Schulten, Tom Jones

Reference Material

Phone as Health Care Credential from Kantara work group

Patient Choice from Kantara work group (on the realities of empowering patients)

Defining and Evaluating Patient-Empowered Approaches to Improving Record Matching . RAND Corp., accessed Aug. 27, 2018,

ONC Patient Identity and Matching Working Session, 2020-06-01

Comparison NIST 800-63-3 SP & MITRE’s paper on Enrollment and Identity Proofing


Identity Assurance Principles

The working group has identified the following as requirements for a   healthcare identity ecosystem (shortened for clarity):

1.      The system shall support the goal of 100% accuracy in identity management and matching of patients to their health records

2.      The system shall include "Break the Glass" (BTG) capability for use in emergencies. A record of information accessed and actions taken using BTG capability must be included in audit logs and notices or receipts should be sent to patients or others affected to inform them of the emergency access.

3.      The system shall include features that preserve privacy of identity data, including support for pseudonymous access where risk factors allow.

4.      To enable compliance audits and forensics, the system shall create, protect and support analysis of comprehensive logs of access requests, modifications to identity and privileges records, and modifications to the configuration of identity ecosystem components.

5.      All features of the system shall be designed to maximize patient safety and to minimize healthcare providers’ liability arising from inaccurate, duplicate or conflicting identity information.

6.      The system shall support flexible, understandable and simple delegation of authority to a “proxy” to access healthcare information and functions.

7.      The system shall support authentication at NIST 800-63-3 AAL1 and AAL2, and federation of authenticators and attributes at FAL1 and FAL2 and its . successors.

8.      The system shall support identity proofing of subscribers at NIST 800-63-3 IAL1 and IAL2, and include a mechanism to convey the level of a   subscriber’s identity securely to Relying Parties.

9.      The system shall be resilient, with the ability to sustain critical healthcare operations and to recover quickly in the event of accidental damage, natural disaster or malicious attack

10. The system shall support effective redress via technological features, contractual agreements, and regulations to assign and enforce liability for intentional identity fraud, negligence, or failure to observe agreed obligations assumed as a participant in the healthcare identity ecosystem.