Identity credentials and unique identifiers are critical to enable data sharing and interoperability across healthcare and other industries. While both are important, each solves different problems, and it’s important to understand the purpose of each.
As a nonprofit Trust Framework supporting healthcare, DirectTrust™ is committed to “instilling trust in exchange.” We continually work with our community to develop standards and policies, including those to support patient identity (identity credential) and patient matching (unique identifier). One of our goals is to allow patients to gain access to their healthcare data when they want it.
This post is the first in a series about identity credentials and unique identifiers. Here, we will dive into some of the risks that identifiers help to mitigate. We’ll also tease apart the differences between these two cybersecurity assets. We’ll start our discussion with an analogy to help imagine digital concepts in real-life scenarios.
An Example of Identity in Action
Imagine attending a banquet with over 320 million Americans. You are working at the reception desk, handing out badges with the table assignment for each guest. If you give out the wrong badge, the person won’t be seated at the same table as the rest of their family. Your job is to give the right badge to the right person.
As someone responsible for distributing badges, you must consider at least three major risk categories. You need to keep these risks in mind to successfully carry out your duties.
Risk Category 1: Distinguishing Between Two People with the Same Demographics (Blog Post 1 – this post)
Risk Category 2: Someone Trying to Fool You Into Thinking They Are Someone Else
Blog Post 2: ID Proofing
Blog Post 3: Authentication
Blog Post 4: Operations and Cybersecurity of Identity Systems
Risk Category 3: Someone Gaining Access Who Isn’t Allowed (Blog Post 5)
FYI: For the identity experts reading this post, you’re right that there are many more risks than those outlined above. However, these risks should serve as a good starting point.
How Is a Unique Identifier Useful?
To illustrate the first risk category, imagine you’re checking someone in at the registration desk. They say their name is John Doe, born on July 1, 1985. Doe shows you his driver’s license to prove his identity. You look through the giant stack of badges and find more than one badge for a John Doe born on July 1, 1985. You know for certain you’re talking to John Doe because he’s proven his identity with what you assume is a legitimate license (more on that later in this series). Which badge do you give him?
The answer is, you don’t know for certain without asking John Doe for more identifying information. However, Doe declines to provide more information for privacy reasons. Now what do you do? This scenario occurs all the time in healthcare settings, and the typical response is to not release any data. That’s called a false negative, which means the data holder (health system, payer, provider, etc.) may have the information the patient is seeking but will not release it because the data holder cannot determine which health record to return to the patient. That’s the equivalent of telling John Doe that you can’t give him a badge, because you decide the risk is too great to give him someone else’s badge.
In the example, giving out the wrong badge might not be terrible. Unfortunately, we can’t say the same about health data. Giving out someone’s health data to the wrong individual is a serious error that could have real world impact for both the individual and the provider. Giving out someone else’s health data by accident is called a false positive. It’s generally accepted that a false positive is worse than a false negative (not giving out any data, even if the data holder has it).
What Can Data Holders Do to Solve This Problem?
A unique patient identifier is one way to solve this problem. You could assign each person a unique string of characters, for example, a driver’s license number. If John Doe’s badge had his driver’s license number printed on it, you could distinguish between multiple people with the same name. Those people could even have the same birthdate. Better yet is a well-designed unique identifier that is not personally identifiable by itself. In other words, if someone found John Doe’s driver’s license number written down somewhere, very little could be done with it because the number isn’t associated with someone’s demographics or physical characteristics.
The DirectTrust Privacy Enhancing Health Record Locator Service (PEHRLS) Consensus Body is a community initiative with participants from government and the private sector focused on developing an ANSI standard that defines a unique patient identifier. The goal is to develop a common standard in healthcare to ensure the correct medical record is associated with the right individual.
How is an Identity Credential Useful?
To demonstrate that a unique identifier by itself isn’t personally identifiable, let’s return to the nationwide banquet. What if someone approached you at the registration desk and gave you a driver’s license number but no name? They might be trying to fool you. Maybe they want to claim someone else’s seat at a table with celebrities, or they have a nefarious reason. How would you know they didn’t steal someone else’s driver’s license number? (Note: This question is addressed in much more detail in the three blog posts to follow.)
Knowing a unique identifier by itself is not a good way to prove someone’s identity. A strong identity credential, such as a driver’s license, can solve this problem. The driver’s license contains (or carries) the number that the person is presenting at the reception desk. Proving that a person owns a driver’s license number by verifying the number printed on their driver’s license card is an effective approach. That’s because the driver’s license has technology to help you detect fake licenses. State DMVs require extensive identity proofing before issuing a driver’s license. The license also contains a picture (biometric) of the individual, so you can compare the photo to the person standing in front of you.
Strong digital identity credentials must achieve the same aims as a physical driver’s license. This is true both in terms of trustworthiness and also in the ability to securely “carry” a unique identifier. The DirectTrust policies governing the DirectTrust Trust Framework subscribe to strenuous requirements. These requirements are defined in a special publication by the National Institute of Standards and Technology (NIST), which sets forth guidelines for strong digital identity credentials that are widely acknowledged by healthcare and other sectors.
How Do Identity Credentials and Unique Identifiers Differ?
Identity credentials and unique identifiers address two different problems. However, they are frequently confused because a unique identifier is often accompanied or “carried” by an identity credential. As a result, many think they are one and the same.
You’ll notice that your driver’s license does, in fact, have a unique number printed on it. The number by itself is rarely used without comparing the picture on the physical license to the bearer. Even if it didn’t contain a unique number, a driver’s license would still be a valid identity credential. However, resolving a person’s unique identity across a large pool of individuals without the unique driver’s license number (unique identifier) would be problematic.
For more than a decade, DirectTrust has been hard at work securing digital identity in healthcare. Although there are more than 280,000 healthcare endpoints on our network, we still have a lot more work to do. Check back in frequently for blog posts on other identity-related topics. If you’re passionate about patient identity and matching, see our website to get involved!
In this series, we will take a deeper dive into identity credentials. The posts to follow will focus on the risks that identity credentials help to mitigate when they are properly secured.
This post was contributed by Kyle Neuman, DirectTrust Director of Trust Framework Development.