The crazy amount of activity going on in the Health IT world is a blessing and a curse. It’s more blessing of course --- Meaningful Use, Blue Button, Direct, Citizen Engagement --- these are all really great advances. But there is a downside, especially when laws, regulation and guidance are involved: it’s just hard to keep up and make sure the right discussions all happen at the right time between all the right people.
I’m worried that one of those discussions is happening right now, by a bunch of smart, well-meaning people, as part of the Direct Trust initiative. I really care about this one and have been trying to keep up, but my day job is making it hard. I joined the weekly call today after speaking with David Kibbe at the Redwood MedNet conference a couple of weeks ago, and it made me pretty nervous.
Because this is a complex topic, I wanted to write down my thoughts in some semi-logical way, thus this post. Buyer beware, but if you’re involved in the conversation I would really appreciate a careful read. ;)
1. The question and current debate
The question on the table is: how should patients participate in the Direct secure messaging ecosystem? Obviously if a provider is going to exchange health information with patients over Direct, they need to have an acceptable level of trust that the address they use belongs to the right individual.
This is the right question for sure. But the conversation today has morphed into something that seems to be a different and ultimately irrelevant question: what level of identity proofing should be required for patient Direct addresses?
In fact, the group is trending towards a recommendation that patient addresses be proofed to NIST Level 3 assurance, which is a pretty high bar --- walk your birth certificate over to a notary kind of stuff. If we’re going to go this route we’d better believe it adds a ton of value.
2. Why this is the wrong debate
On the surface, having “proofed” addresses seems like a good idea --- after all, there are other situations that seem analogous, such as presenting my state-issued driver’s license to prove I can order a drink at the Mariners game. But a closer look shows why it isn’t appropriate for patient data exchange.
Let’s get really concrete: what is the workflow of exchange going to look like? Just like other contact information, when I go to the doctor I’ll give the front desk my Direct address, along with a request to send my visit information there. Because I am the patient (or their guardian) as verified in real life, the provider is 100% sure that there is a connection between the address and my chart. They also can obtain the necessary patient consent to use the address as required under HIPAA. Done deal.
This model also allows the provider to use other means to tie the address to the chart if they are appropriate and available. For example, if the patient has already created a portal account and it’s tied to their chart, they can just add a Direct address online --- a great and appropriate reuse of hard work.
Now let’s look at what happens with an address that has been identity proofed. The provider still has to acquire the address somehow. If it’s given by the patient as per the above, then any additional “proof” is completely irrelevant. I already knew the address was coming from a trusted source, so what is this adding? Nothing at all.
Are there other models to get the address that make use of this identity proofing? Well, since we don’t have a national health identifier, we’d have to do a search using demographics (name, birthdate, gender, that kind of thing). That implies that there is a central database of demographics to search somewhere. Who pays for and runs this database? Are we OK having a huge semi-public directory of personal information for the whole country? And even if we get over those, the match from the address to the chart by demographics is going to be worse than an in-person exchange, because demographic matching is “fuzzy” and sometimes incorrect.
3. Doesn’t that mean patients have to re-proof at every provider?
Yes it does --- but that’s actually totally appropriate and works fine. In fact, this is the way the rest of our world actually works. I do business with Bank of America, Wells Fargo, Smith Barney, and a number of other financial institutions --- and for each one I had to proof my online account.
Similarly, before a provider can give me my health information, they need to collect consent. So we’re going to be in this situation no matter what; we might as well take advantage of it!
4. What about providers? Why are we identity-proofing them then?
Because the dynamic of messaging between providers is fundamentally different. When I am sharing health information between providers, very often it is without a pre-existing relationship. For example, a patient may move and ask their old PCP to send their records to a new one in another state.
In order for the provider to do this responsibly, it’s OK that they don’t know the other provider personally. They don’t even really have to know their name. They just have to have confidence that they’re sending to another provider, or in HIPAA-speak another covered entity. To make this decision, the provider needs to be able to say “give me their Direct address” and know that it belongs to another provider. If you look at proofing procedures like those used in Rhode Island, the key is “RIQI verifies Covered Entity status.”
This same dynamic does not apply to patients --- where the patient and provider always have a relationship if data is being exchanged. Just knowing that an address belongs to “a patient” isn’t useful.
5. Doesn’t that create different “classes” of Direct addresses?
Yes, and that’s ok too. We actually spoke about this in the earliest days of Direct, but decided we’d deal with it after we got our first uses cases in place. Over a year ago, I wrote a proposal for handling this on the original Direct Wiki, and I think it still applies today. There’s also a more tactical description of most of this on my blog. It lines up perfectly with the new work being considered for the new Automatic Blue Button project at ONC, so hopefully we’ll see some progress there.
6. Where does this leave us?
If you think I’m wrong on this, I’d love to hear why. Even better, I’d love to hear a really concrete, specific description of a workflow in which patient identity proofing will solve a problem for us in patient/provider communication. My belief is that this is a conversation that can only be meaningful when you move past the abstract into the real world.
And if I’m wrong, I’m wrong --- that’s cool. I’ve been living these workflows all day every day for six years now, though, so I’m pretty confident I’ve learned something about how to optimize them. Direct is a great opportunity to break down barriers to collaboration --- let’s not lose it!
Sean , thanks for the blog. On top of this we are expecting patients to setup a secure SNTP client. Users complained to me like crazy (as you know I complained to you) about having to setup a HealthVault account. Reminds me when I was working with IBM and Microsoft on SET (Secure Electronic Transaction) and SSL showed up, SET is out. We have to find an easier solution.
Arien has some great thoughts on this over at the Relay Health blog too: www.relayhealth.com/.../Identity-assurance-for-patients-using-Direct.html
I'm with Sean on this. If I tell my doctor this is my Direct address, that should be enough.