Patient Portals – Linking Providers and Patients using Two-Factor Authenticationby Applied Informatics
The critical function of a patient portal is to link a given patient to their provider in such a manner that a patient, say Bob, indeed gets linked to his doctor, say, Dr. Jane, so she can share his medical records or communicate with him and him alone.
And, the challenge is, how to accomplish this easily without undue back and forth between providers and patients and wrong Bobs getting linked to wrong Janes. Furthermore, such linking mechanisms need to be simple, easy-to-use and easy to implement, thus not relying on such devices that generate secure tokens or likewise.
In our patient portal, iHealthNY we have taken a four pronged approach to link patients and providers and in each we have utilized two factor authentication; which translates to two levels of assurance that the linking is indeed happening between the two intended parties.
Before we go on to describe our approach, a brief explanation on what is two-factor authentication and why it is important in this context.
What is two-factor authentication ?
As defined by the NIST in its e-authentication handbook,
Electronic authentication (e-authentication) is the process of establishing confidence in user identities electronically presented to an information system. E-authentication presents a technical challenge when this process involves the remote authentication of individual people over a network.
And the process involves several actors/stakeholders, as elucidated and explained in NIST’s well-grounded and comprehensive model (see image 1 below).
As the report further points out, “The classic paradigm for authentication systems identifies three factors as the cornerstone of authentication:
- Something you know (for example, a password)
- Something you have (for example, an ID badge or a cryptographic key)
- Something you are (for example, a fingerprint or other biometric data)
So what is Multi-factor authentication? It refers to the use of more than one of the factors listed above. The strength of an authentication system is largely determined by the number of factors incorporated by the system. Implementations that use two factors are considered to be stronger than those that use only one factor; systems that incorporate all three factors are stronger than systems that only incorporate two of the factors.
Note: in this regard use of two or multiple factors but of the same kind, doesn’t make the process multi-factor. The office of management and budget’s recommendation on e-authentication describes four levels of security with level 1 having the least security and level 4 the maximum. An example of a level 4 e-authentication token would be using say cryptographic device to generate a one-time token after the user inputs a memorized/secret password.
Given that this is a health portal we need to have adequate provisions that information shared by the provider (or patient) is indeed shared with the intended recipient only. For example, if one were to use the common method of sending an activation/signup link via email, and rely on one-factor authentication (the email recipient just needing to use their memorized token [password]) to access this activation link. One can observe that such a system would provide only limited security, for if the email was sent to the wrong person or the email was compromised, it would be trivial for the intruding third-party to sign up in lieu of the intended recipient and gain access to their confidential medical information!
Two factor authentication refers to utilizing two different kinds of factors to verify whether the person claiming to be who they are, are indeed them. The second factor, which would be ‘what they have’ utilizes one-type verification codes sent to a phone (that the person has to have) providing a simple, easy to achieve mechanism for us to attain two-factor authentication. This is guaranteed to be level 3 assurance with respect to security of the tokens used for authentication.
So now, lets get back to the patient portal and how we are linking patients to providers. The 4 ways we have programmed this in iHealthyNY are listed below along with descriptions of how they achieve two-factor authentication.
Linking Patients to Providers on iHealthNY
The four mechanisms are:
Provider sends an email activation link to the patient
Provider gives a printout with activation details to the patient
Provider enables patient for in-clinic sign up
- Patient initiates signup and sends request to be linked to provider
- Provider sends an email activation link to the patient.
- The activation link is sent to the patient’s email. To access this link the patient has to use his/her email password (this serves as the first factor: what they know).
- The activation link takes them to a sign-up page (if a new user) or a login page on the portal (which requires username/password. However, this is still one-factor).
- Once they signup/login, they are then asked to enter a code they receive on the phone number registered with the provider. The code is delivered to them via an automated phone call or an SMS (see image 2 below) and this is done using Twilio (we will be writing more on this shortly) . This serves as the second factor (what you have.). If the patient cannot complete this verification step, the linking stops and no sharing of medical information is effected between the provider and the patient.
- Provider gives a printout with activation details to the patient. More likely a scenario of patients who don’t want activation link in email
- The provider hands out a print-out to the patient in the clinic. This print-out contains a unique activation code just for this patient and serves as the ‘what you know’ factor.
- Next the patient uses this print out to visit the signup/login page (so another password challenge is presented).
- They are then asked to verify the phone number linked with their account in the providers EHR. This serves as two-factor authentication as above. So in both 1 and 2, if the email is compromised or the print out is passed on to someone else, the phone verification process ensures we have an additional safe guard before information is shared from the provider to the patient.
- Provider enables patient for in-clinic sign up. This covers the scenario when the provider is with the patient in the clinic and patient is willing/ready to sign up/link to provider in the clinic itself.
- Provider has the option to click “in-clinic signup” from the EHR itself which opens a window to let the patient sign-up or login, behind the scenes, to link the two. The two-factors in this case are what the person has and is. Who he/she is, is confirmed by being in physical presence of the provider. And what they have is the special unique link generated in real-time for them, which expires in 10 mins if not used.
- Patient initiates signup and sends request to be linked to the provider. This covers a scenario when a patient signs up on the portal on their own.
- Patient signs up or logs in.
- Patient then searches for providers in the eco-system and then sends linking request.
- They have to provide their basic demographic information (what they know factor).
- A request is sent to the provider who then verifies if the patient is indeed their patient and then sends a link confirmation request.
- The patient has to verify their phone once the provider accepts their request but before the link is established (this is the second factor).
So that explains our 4-pronged strategy and how each achieves two factor authentication. We believe that the above mechanisms capture most scenarios that may occur to link a provider to a patient and encompasses both provider and patient initiated approaches. These mechanisms are going to be used in a custom version of iHealthNY being rolled out for a large clearinghouse and EHR company.
We are excited about this as one of their biggest barriers to portal adoption has been patient registration and linking with providers. The new registration flows proposed and being put into place should hopefully eliminate this barrier.
Stay tuned! We will post more on this in days to come.