Family Health Guy

In which Sean talks about HealthVault and other cool ideas in Personal Health

A (much) better approach to patient identification

A (much) better approach to patient identification

  • Comments 2

Unlike some others, I’m optimistic about the creation of CommonWell and its potential for making more information available to caregivers where and when it’s needed. Not because it’s a new idea, but because I’m lucky enough to have worked with many of the specific individuals involved in the project, and they are simply great folks. If anybody in our community is going to make something real here, it’s these people. So … woo hoo!

That said … their focus on creating a national EMPI has spun up that tired old argument about national patient identifiers … and this one ticks me off because it’s just silly. We have absolutely no need to share a common patient identifier, whether created top-down or synthesized from demographics up. The solution is staring us in the face.

All we need is patients and their existing relationships with providers. This is one of the key transformations that HealthVault offers, but few recognize until they see it at work. When that light bulb does goes off, it’s pretty cool. To see what’s going on, let’s walk through the evolution of a HealthVault record.

When I create a HealthVault record, it isn’t connected to anything. It’s just this empty bucket up in the cloud that I control. I can put my own stuff into it, connect devices like a fitbit or glucose monitor, and so on. So it’s useful, but not particularly exciting. Looks kind of like this:

 

Now say I get some tests done at LabCorp, and I use their Beacon Portal to get a copy of my results in HealthVault. The Beacon site does some knowledge-based identity proofing to match me to my LabCorp information, and I (the patient) authorizes the link to HealthVault. A “link” is formed between HealthVault and LabCorp, and data can travel between the systems with high confidence:

 

Now here’s where things get interesting. Say I’m going to visit a new provider and want them to have access to my lab results. Either by giving me a PIN code or leveraging an existing patient portal, that provider can obtain my consent and link my HealthVault record to their internal chart. They can now peek into my HealthVault record and read out the results deposited there by LabCorp, as well as any other relevant information.

This process repeats at each provider and service I visit, creating a personal Health Information Exchange that provides all the capability we need to ensure that the right information is available when it’s needed and relevant, because every linked provider can see (subject to my OK) information from every other participant I’ve linked to my network.

 

 

They may look unassuming, but all the magic is in the “links” --- those grey arrows in the picture above. Because the properties of those links are what make this a seriously transformational idea:

  1. There is no “fuzzy” matching. Each link is created as a byproduct of a natural exchange that already occurs in the healthcare system: introducing yourself to a new provider, signing up for an online service, and so on. While no system can completely eliminate the risk of a mismatch, our real-life experience with HealthVault shows it to be dramatically more reliable than traditional EMPI techniques.
  2. Privacy, liability and HIPAA issues between providers COMPLETELY GO AWAY. Each link represents an independent agreement between the patient and a single provider. Information that goes from ProviderA to HealthVault and is then read by ProviderB requires no relationship between A and B whatsoever, because the information is brokered by the patient.
  3. This does not mean that the information can be faked. HealthVault contains extensive audit information, visible to all participants, so they can verify the “provenance” of data before accepting it. This is frankly WAY more reliable than getting a fax or a pile of paper.
  4. There is no common identifier shared between providers. The concern about a national identifier boils down to a fear that we’ll be easier for bad guys to track. In the HealthVault model, every “link” uses a different patient identifier … so the ID that ProviderA uses for me is completely different from the one used by ProviderB. Of course, buried within HealthVault there is a connection, but the system is built to never expose it to linked applications.
  5. And just for the conspiracy theorists out there … the HealthVault terms of use even restrict Microsoft from digging into this data without user consent. And those terms are enforced by the FTC and other agencies … it’s not something we take lightly or can just renege on.

So let’s recap. The HealthVault model is in production today, delivers better quality patient linking than other approaches, eliminates inter-provider privacy, liability and HIPAA concerns, doesn’t require a common patient identifier, puts citizens in greater control of their personal information, and enables more informed care TODAY.

Hmm.

Yeah, we’re making progress and connecting more folks to the network every day --- but I’m not sure how to end this post without screaming in frustration at how slow folks move in this industry. We NEED this NOW, people!

 

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • Fantastic explanation. This model can be implemented using the HIE standards available, and indeed is almost the model used in Europe (epSOS). I think you also know many of the people involved in NwHIN-Exchange (HealtheWay), CCC, and other networks. The problem tends to be very much politics, not actual technology. I too don't think we need a single identity. What we need is freedom to try. There is simply too much Fear, Uncertainty, and Doubt. This is keeping progress from happening. So the forbiddance for HHS to fund, is perceived as a forbiddance on the healthcare industry to try.

    I worry about a model such as you describe. I think it will work wonderfully when the patient is an actively involved and technically capable individual. I think this is a rather small population overall, and likely does not overlap well with those that need healthcare most.

    I thus think that there will continue to need to be multiple methods, not a single method. I don't think we need a SINGLE identity either, linkage is key for the foreseeable future. I do think that this linkage needs to be open and transparent to the patient themselves.

    Let us continue to work together in open and transparent ways.

  • John, thanks for the thoughtful comments --- and to your main point I do agree that a "ban" on the concept of a national patient identifier is sort of nutty ... there's no question that politics and little else are behind that one.

    But I think you're underestimating two things with the patient-controlled approach. The first is that we really can sidestep the politics by vectoring through the patient --- the law is already fully supportive of this kind of exchange and thanks to pretty consistent messaging from the Office of Civil Rights, that's finally getting through some very thick healthcare skulls. So it's not just the tech, it's the application of the tech through the patient that is "magic" in my mind.

    Second is your concern about activated patients being a subset of the folks we'd need to get engaged in this system. Zero argument from me that as positioned today patient control is reaching a smaller set of folks. But if you look at the way patients work with HIPAA consents today ... there's really no reason patient-controlled authorization has to be any harder than that. In other words, I don't think you really require "activated" patients the way we think about it today ... we just have to get folks used to giving a new kind of consent when they show up at the doc.

    Bottom line, I'm for all kinds of innovation, just as you are --- but I think the patient-controlled model has gotten a bad rap, often from folks who are just stuck in an old and paternalistic model (to be clear, not lumping you into that group) ... which is a shame.

Page 1 of 1 (2 items)