Company Blog

Identity assurance for patients using Direct

Posted by Arien Malec - Vice President, Strategy and Product Marketing on August 20, 2012

Direct , patient identity , identity management HIE , health information exchange , meaningful use , identity proofing , patient privacy , data sharing

One of the great use cases for directed exchange is to push records to a patient's designated location, which could be the patient's PHR, their medical home or ACO-located data home, a care coordinator, a family member, or anyone else whom the patient designates to receive copies of the patient's health data. This case is featured quite prominently in the notice of proposed rulemaking (NPR) for Stage 2 of Meaningful Use in the "transmit" requirements and it is also one of the flows at the core of the new Automate BlueButton Initiative as part of the ONC-coordinated Standards & Interoperability (S&I) Framework.
 
Given that use case, there is often debate about what level of identity assurance is needed to enable the flow of data. With reference to the National Institute of Standards and Technology (NIST) Special Publication 800-63, the debate is over whether Level 1 or Level 2 identity assurance and authentication are necessary. I believe very strongly that Level 1 (with some additional authentication requirements) are sufficient and ideal, and that Level 2 requirements are both unnecessary and actually get in the way of basic real-world use cases.
 
Here's how a Level 1+ approach would work:

  • I get a Direct address that is specific to me from my Direct provider. I might get that address by registering myself with a PHR like HealthVault, my health system patient engagement provider, like RelayHealth,  or from my medical home, which could be given to me from my primary care provider's EHR, or from my HIE provider, like RelayHealth again. I could even have two or three: for example, I might want my data to be sent both to HealthVault and to my RelayHealth account, so that it can be used by my medical home or accountable care organization.
  • The organization that controls those addresses implements at least the equivalent of NIST Level 2 or higher authentication to make sure that address remains specific to me, and isn't accessible from someone who is not me or someone to whom I've delegated control. This is the "plus" in my "Level 1+" moniker.
    I give those addresses to the provider's office from whom I receive care. They know the addresses came from me because I gave it to them, in person. (In security-speak, this is called in-person identity proofing.)
  • The provider sends my data to the addresses on the close of encounter (e.g., office visit or acute care stay)

 
In Direct, the Direct address is paired with an X.509 certificate. For providers, we want to make sure there's a high degree of identity assurance to make sure the provider or provider organization really is the person or organization claimed. We want a trusted certification authority (CA) or registration authority (RA) to do the proofing and issue the certificates, and we want a certificate policy that provides the assurance we need. We do this because we want providers to send data to one another relying on their knowledge of the organizations or individuals as trusted organizations or providers without having to perform in-person identity proofing. It's a higher level, more secure version of the common method of information exchange today: the fax machine.
 
For patients, since we in-person identity proof to the level that we are prepared to provide care, we don't need special identity proofing associated with the address. Instead, we want something uniquely identified with the address that makes sure we can't send to the wrong address. For Direct, that might be a certificate associated with a self-signed root maintained by the PHR company or HIE company (HealthVault and RelayHealth in our examples), or it might be a lower assurance CA root maintained by a trusted CA. The issuing organizations need to keep the private keys secure and make sure they are uniquely associated with the addresses, but we don't need special methods of identity assurance.
 
This approach allows us to make sure our data aren't going to the wrong place, while giving us the flexibility to get started quickly and to send our data to multiple locations based on our needs.
 
What if we went with a Level 2 approach?
 
First, it would be much harder to get started: my PHR company, the EHR company that supports my medical home, and my accountable care organization would all have to do high-assurance identity proofing. That might mean asking me to go to a notary public to check my driver's license and my passport. I might have to do this multiple times…once for each of the places I send data. This would be a pain, and would raise the costs of participating in my healthcare.
 
At the end of all that, we would have a more flexible system, right? Probably not — I would likely still need to go in person to the provider's office to do identity proofing. Otherwise, how are they going to know I'm the same person to whom they are providing care? Just because I'm really John Smith doesn't mean I'm the same John Smith who's receiving care at Sunny Family Practice.
 
I'm not against Level 2 identity assurance: A system that performed a high level of assurance and allowed the lookup of identity attributes, like address, date of birth, gender, etc., might be able to get away from the need for in-person identity proofing and provide multiple additional benefits, but that's not the system you get with Level 2 identity proofing and certificates.
 
In this matter, as with many others, we should keep it as simple as we can, while still preserving high trust and security.

Contact the RelayHealth Speakers Bureau to schedule Arien Malec for speaking opportunities.

Follow Arien on Twitter. www.twitter.com/amalec


Was this helpful?


Post Your Own Comment:

Share This: