June 27, 2014
Recently, a colleague and I were talking about how times have changed. My colleague is a physician, recently retired from private practice, though he continues to see patients part time in a teaching environment. He is a key individual who has been and continues to be instrumental in the development of several healthcare IT standards nationwide, and a number of key processes within DrFirst. As usual, our discussions provided me with a valuable insight. “I remember a time, not that long ago,” he told me, “when the only identity proof required by a provider could be found on a wall. My medical school diplomas and post graduate board certifications hung on my office wall for many years, and it was one of the first things patients noticed on their first visit. It was the only identity they cared about, or needed — for at least the average person.” Unfortunately, in today’s complex and interconnected healthcare environment, such a straightforward and seemingly pristine approach is obviously insufficient. Providers must prove their identity and supply credentials outside of their person to person interactions with patients and peers, and often to computer systems, large organizations and professional licensing bodies that require more rigorous and repeatable identity proofing and credentialing processes.
As I have discussed in prior blog posts, the establishment of identity is not a straightforward process. The strength of the assertion about who someone really is and how we connect that assertion to a mechanism or “credential” by which that person may access information, can be fraught with both complexity and mundane redundancy. The process used to establish the identity, irrefutably and irrevocably attach it to a trusted attribute or credential for proof, and then test that credential reliably and without disruption. Once completed, all combine to define the usefulness and “strength” of the identity. When, as an industry, we began to utilize electronic medical records systems, we also created a correspondingly electronic need to restrict and control the means of access to, and security, and distribution of, private medical information, a.k.a. “Protected Health Information” or PHI as defined in the Federal HIPAA Privacy rule over 10 years ago.
This might have been made easier if there was such a thing as a central system in use by all providers. However, such a daydream is long behind us. Despite congressional reluctance to authorize a national patient identifier, we have seen a bit of progress with the establishment of a “National Provider Identifier.” This at least offers a workable though not perfect substitute for the much misused and abused DEA number, originally and exclusively intended to manage the prescription of Controlled Substances. However as an industry, we have spent the better part of the past 30 years envisioning new, improved and ever expanding computer systems and software applications to digitize and manage patients’ medical records. The goal is to more efficiently deal with the explosion of healthcare specialties and services dealing with an increasingly mobile population. Nevertheless, in the current environment, a practicing hospitalist or a physician on multiple clinical staffs may be forced to utilize as many as five or six separate, individual, and mutually exclusive computer systems, each of which independently sets and maintains identity controls and processes for on boarding, including periodic re-assessment. This creates a very heavy burden on everyone involved: the IT department, organizational management, and of course the provider.
What is an identity exchange?
In order to remove the burdens caused by the level of redundancy in on boarding across health care IT systems, we need to separate and consider distinct the three basic components of access: identity, credential, authority. In previous blog posts, I have introduced this requirement as a central component to solving this vexing problem. This blog post will examine the first of those components necessary to establish a secure, reusable, inexpensive framework from which we can begin to repair the current situation.
An identity exchange is a service that creates reusable assertions that might be called upon to identify an individual reliably and inexpensively. Unlike other existing exchange models in practice today, an identity exchange is a set of services, offered under a Trust Mark, that only establishes an identity using one or more knowledge based authentication (KBA) methods or using other established forms of identity proofing. An identity exchange is not meant to provide system access or to evaluate credentials. Its use culminates in reusable assertions that are marked according to their method, level of assurance, origin, provenance, and date of establishment. Subsequently, the assertion itself is bound to some reusable attribute that may be either chosen by the individual or signed by a third party, but is nonetheless unique and durable. It is vital that the resulting identity is thoroughly defined and documented according to accepted guidelines and that it be re-testable, according to a predefined schedule, to assure that it hasn’t changed after it was created.
Most importantly, though, an identity exchange serves one major purpose: to prevent the need to reestablish identity each time a person establishes contact with a new application or system, often characterized as “the relying party.” Since the management of a person’s identity is kept separate from the management of the credentials and the use of those credentials to gain access to particular system assets, it can be considered durable. The identity is not subject to change as access rules or authority change over time. A person’s identity remains intact regardless of how that identity is treated or considered over time. For example, if you are the person known as “Dr. John Public,” and have proven this fact to some level of assurance — within some trust framework’s definition, this fact may be held within the repository of an identity exchange. Doing so will enable applications to leverage this fact repeatedly, rather than cause you to reproduce it on demand each time it is needed.
Now, if the “Exchange” allows you to associate this identity (and the fact it was rigorously proven) with an attribute of your choosing, we can establish a straightforward “index” or “seed” to your identity. The exchange must also protect this index against duplication or use by anyone else. Once claimed by a user, it is irrevocably theirs. For purposes of discussion, let’s call that index attribute “unique name” and for this example, let’s say you set your unique name to “Tiger1234January.” Effectively, that unique name value would be associated with your identity and called upon in order to recall the circumstances under which that identity was proven and the date that that identity might expire. Applications wishing to start a process with the identity exchange would pass the “Tiger1234January” value to the exchange as a means to identify who they were attempting to validate. This is not a proxy for username, as it is the credential, not the unique name that effectively completes this validation. Knowing the value would only start the process, not define a key. If it alone were shared or compromised, there would be no loss of system integrity.
The identity exchange does not grant you access to an application, nor does it validate a credential in order to prove that the entity requesting access is in fact the person who has been given authority to do so. This is where many people get confused. An identity exchange is meant to play a very singular role, and requires that the application performs access management, and that the credential is separately validated through a distinct and different function apart from the identity exchange or the application itself. All three functions must be working together to grant access.
So you may be wondering why I feel it is so important.
Consider that “Identity” gives meaning to access granted by an application. It would be little use to an application administrator if it were impossible for him to associate a human with the authority he is enabling. By giving Dr. John Public access to key information, the application administrator is cognitively associating the person he knows as Dr. John Public with whatever credential he thinks identifies John. However, he is not the only one doing so. The application administrator’s use of an identity exchange releases him and others like him from the responsibility to determine who John actually is, and to make certain that John is not impersonated. It’s also very important to remember that the application or relying party can require its own proprietary policy that must be satisfied by the Identity Exchange steps prior to granting access rights. Consequently, these assertions can be made more formally, rigorously, and with greater levels of assurance, since they will be done only once. This strengthens the security of all systems.
Furthermore, once the relying party’s policy requirements are satisfied, its applications no longer have the need to associate human beings with access controls; they no longer have to store information that can be co-opted in the process of compromising those controls. Remembering that identity, access, and credentials will now be three separately managed processes, there will no longer be a single target for any nefarious individual wishing to fraudulently gain access.
This sets the stage for the emerging standards related to a general need to strengthen identity and credential management in healthcare. Recently, discussions at the IDESG, NSTIC, ONC, and related subcommittees have considered the need to begin a mandate that all healthcare related systems adhere to NIST LOA 3 standards at a minimum. This would effectively mark the end of usernames and passwords for healthcare system access, and will rely instead on more sophisticated credentials and processes to establish identity and associate it with an appropriate credential for each user. While this might be some time coming, it is most certainly more imminent with each breach we hear in the news, and for every person’s privacy that gets compromised either through carelessness or some fraudulent act.
Regardless of this movement, it may be inevitable that providers and their staff be issued multiple credentials for the foreseeable future. However, if we are to establish the level of security necessary to safeguard our information assets in healthcare, and if we are called upon to raise the implementation to one with more rigorous identity controls, an identity exchange will be vital and indispensable to making the entire process tenable for IT, administrative organization, and the providers themselves. Reducing redundancy and identity definition is a crucial step to the acceptance of more rigorously defined identities for providers and their staff.
How would it work?
In short, the identity exchange would amalgamate multiple identity sources, some of which may be emergent at the moment. That is, the traditional identity proofing resources (credit bureaus, information databanks, government entities, etc.) will continue to play a role. However, new resources may also play a role, and include other technologies, possibly even low tech or no tech approaches. It is possible that a combination of social media, and referred identity (the fact that if a large number of already trusted people can agree collaboratively that “Dr. John Public” is who he purports to be) can also be used in the identity proofing process. Another possibility is emerging that a “low trust” identity that has been used hundreds of times over a very long period may build itself into a more reliable “self-asserted” identity.
It is almost certain that some common identifier such as the “unique name” discussed above will be necessary in order to interact with the identity exchange. An application would provide this attribute in order to check the status of an identity that had been previously asserted, or to ask that credentials associated with that identity be verified. Furthermore, this “unique name” would be used within each application in order for access controls to be set. Rather than associate those controls with username as they do now, applications would associate authority and roles with the “unique name” instead.
When asked to authenticate a user, the identity exchange will interact with a credential exchange whose sole responsibility is to validate one or more credentials, such as a two factor authentication device, biometric, or other multifactor mechanism. The credential exchange is signaled using an identifier unique to the identity exchange, such as an internally generated globally unique identifier (GUID), or some other unintelligible value generated by the identity exchange programming.
In this way, the identity exchange will be blinded to the actions of both the application and the credential exchanges to which it connects. In other words, the identity exchange has no way to associate a person with the authority that has been granted to that person by any of the applications that person is using. Similarly, the identity exchange has no way to connect a particular credential to one of those individuals whose identity it manages. Future blog posts will detail the actions of the credential exchange and the application.
What value would it provide?
As I mentioned at the outset, in order to assert more rigorous controls on application access and identity management, we need a mechanism to simplify the process of establishing and maintaining reusable identities. These reusable identities can then be described as “interoperable.” The fact that they will be reusable is a key function, because we wish to reduce the number of redundant identity sources, practices, and general inconvenience facing providers today. Reusable, interoperable identities are vital, and at the center of the principles established by IDESG. The promotion of reusable identities is the first step on the road to establishing more secure and reliable controls, and reducing the costs normally associated with strong credential processes. In the end, we will establish an increase in the de facto security and privacy controls that will likely be required in the coming years, while reducing the vulnerability of all applications universally.
I strongly believe that the time has come to create such an exchange. There is much more to be said about this, and many challenges to face. Healthcare application vendors tend to hold tightly to established means of credentialing, and the concept of the identity exchange will certainly threaten those models. However, just as providers have had to become accustomed to a plethora of new digital systems as well as challenges to their provenance by intervening payers, the systems that serve them must quickly catch up and look beyond the diploma that once was their only identification. If patients can learn to access 21st century information, looking past that sheepskin, so should all healthcare applications.