Child pages
  • File Lists

The Kantara Trust Framework: Identity Assurance for US Healthcare

 

Introduction

 

This submission from the Kantara Health Identity Assurance Work Group on behalf of the Kantara Initiative community, is in response to an ONC call for   input and insight into existing challenges and promising innovations in patient identity.

 

The Kantara Initiative is the global ‘commons’ non-profit consortium unique in having both digital identity and privacy scoped to deliver   innovation, standardization and good practice. It attracts thought-leading organizations, governments and individuals to its open collaborative ethos,   Kantara operates Trust Frameworks to 3 rd party assess and assure digital identity solutions against standards such as NIST 800-63-3 and is home for two open specifications - UMA, the OAuth extension enabling respecting user-controlled delegation, and the Consent Receipt now part of an ISO privacy standard.  

 

Kantara appreciates the technical challenges involved in improving patient   identity matching - from   clean data and strong records management capability to agreed common taxonomies and standards for datasets and schemas to facilitate portability.   But even if this were all operating perfectly in a utopian world and false matching rates reduced as a result, it's hard to see how such a process can sustainably scale. At the other end of the architectural spectrum, the notion of a unique health identifier gives rise to security and privacy challenges while also adding to the patient's burden of managing their current suite of identifiers. Patients' rights, choices and experiences should be central to any discourse. Moreover, Kantara believes that the patient should be free to choose to leverage an existing identifier it holds, supported by processes that ensure its uniqueness. That is why Kantara's focus is on   identity assurance processes   in Healthcare - the existing identity and the binding of that identity to a credential identifier - which is the focus of this submission.

 

 

Patient Matching and Identity Assurance

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.

 

Smartphone 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 smartphone for identification will soon be able to include one’s mobile driver’s license and other digital credentials. One can already use the smartphone’s camera to capture formatted data like a QR code. The interworking of healthcare identifiers with other user credentials should be a high priority goal. It should be noted that there are technical solutions in use in banking today that utilize the individual’s own smartphone plus mobile app to perform all the steps necessary to comport with IAL2 and then to use that same smartphone 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 smartphone. In the future, the patient could link their mobile driver license when requested to complete this step.

5)     The patient is then 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 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 smartphone 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).  

 

Binding 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 their 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 smartphone.  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 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: Currently, 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 remote arrival 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 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

 

Mobile Apps 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 (TPO).  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.  Patients may also find it challenging to easily include or exclude family members or other caregivers from having permitted access to their medical records.  The following are examples of protocols and technologies available today promote a patient-centric design that can be promoted via mobile application.

Consent Receipt

The Kantara Notice of Consent and the use of a Consent Receipt may keep the patient informed about what information they have agreed to share and with whom they have agreed to share it with.  A Consent Receipt (CR), as the name implies, is a human-readable document that is provided to an individual when they agree to allow an organization to collect, use or disclose data about them according to a set of terms and conditions defined by the collecting organization.  The CR can enhance the ability to maintain and manage permission for personal data by both the patient and the healthcare organization.  Much like a retailer giving a customer a cash register receipt as a record of a purchase transaction, a healthcare organization could similarly create a record of consent interaction and provide it digitally to the patient.

 

UMA & HEART

Another Kantara promoted design is the User Managed Access (UMA) protocol. UMA is designed to give an individual a unified control point for authorizing who and what can get access to their digital data, content, and services, no matter where all those things live.  UMA’s architecture can service a variety of consumer-facing and enterprise-facing use cases, including healthcare.  A working group called Health Relationship Trust (HEART) is working to "harmonize and develop a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs", building upon, among other standards, UMA.  A mobile app that allows the patient to easily manage authorization access can provide record control in the palm on their hand.

 

A Mobile App Experience

With patients using a common mobile app experience it may be easier for healthcare organizations to immediately notify the patient when their PHI is being exchanged outside of the health system or practice.  This would help alert patients to suspicious exchanges and could make them a more conscientious manager of their clinical data. The mobile app is also the expected experience to allow the patient to receive their electronic consent receipt and to manage access to their health data.

 

A certified mobile app could provide assurance to the patient that their healthcare provider’s mobile app was properly protecting their information, enabling secure transmission and conforming to industry best practices for identity assurance and authentication.

 

Conclusion

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.  A mobile 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.

 

 

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

Mobile Authentication Assurance Statement (MAAS) 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

DirectTrust

Solutions Referenced in this Paper around Remote Identity Assurance and Mobile Authentication:

 

 

Healthcare Identity Assurance Principles

The Kantara Healthcare Identity Assurance Working Group (HIAWG) 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.