ONC testimony on identity proofing; maybe another time!
Today the ONC Privacy and Security Tiger Team was supposed to be having a hearing on consumer identity proofing for health. Needless to say the weather put a crimp in that plan, even though it was by teleconference. Since I had my content actually prepared this time, I figured I'd post here for those that might find it useful or interesting. Bottom line is --- lots of complexity to connecting diverse players in the heatlhcare ecosystem, and while they all involve proving that people are who they say they are, trying to deal with that problem in isolation from other issues isn't super-productive. Kind of the same argument I made here, but hopefully a bit more concise and cogent.
Stay dry and safe, East Cost --- the gentle Pacific Northwest is rooting for you!
Consumer Identity Proofing in Microsoft HealthVault
Testimony for the Privacy & Security Tiger Team
Sean Nolan, Microsoft Distinguished Engineer
October 29, 2012 (postponed)
Introduction
Microsoft HealthVault is a global online service that enables individuals and families to collect, store, share and use important health information. In common terminology, it is an “untethered” personal record, meaning that it is not bound to any single care setting or provider system. Importantly, though, HealthVault is a connected personal record --- its purpose is to move information efficiently and when possible automatically between all relevant care settings and provider systems.
Creating these connections is difficult work --- just last Friday we celebrated HealthVault’s five-year birthday and clearly we’ve only begun to make traction against the challenge. But I am proud to say we’ve done a better job of it than anyone else. Today, HealthVault users can connect their records to hundreds of providers, national pharmacies, the two largest national laboratories, imaging centers, hundreds of home monitoring devices and applications --- there are even services to convert paper records into structured HealthVault information. And of course, our ongoing participation with the Direct Project and groups like ABBI are in support of this same long-term goal.
Hub and Spoke Connections
The best way to think about the HealthVault data ecosystem is as a hub and spoke configuration. The hub is an individual HealthVault record, and each spoke connects to a particular information source or target, for example a provider system or an HIE. Once established, information can move with relative ease along the spokes, but that establishment process requires a number of non-trivial things to all come together:
-
- HealthVault and the external system need to interoperate technically, using shared transport and content formats.
- The two systems must be able to link patient identities --- ensuring that the information exchanged applies only to the intended individual.
- The two systems must each obtain appropriate consent from their respective users to ensure that information only moves according to the wishes of the individual or their authorized representative.
It is tempting to imagine that we could solve each of these problems once and then have all of the “spokes” magically appear --- but unfortunately this is simply not realistic for many reasons --- technical, business, political and privacy-related.
Indeed, what we believe is transformative about HealthVault is our approach to scaling the creation of spokes with a flexible menu of approaches that make it ever-easier to connect systems in the real world.
“Identity Proofing” the Spokes
Identity proofing is a key part of establishing a spoke --- without some type of proofing solution we cannot address issue #3 above, obtaining appropriate consent. But because we do not use a common unique patient identifier in the United States, proofing is actually not particularly useful in step #2, linking patient identities ***. And both steps must be dealt with in order to establish a usable spoke.
Fortunately, it turns out that there are a number of approaches that can achieve both needs at the same time. The current HealthVault “menu” includes three approaches, each involving a different proofing mechanism.
Note in all of the cases below, while I describe processes being used by HealthVault in the real world today, each could be applied to the linking of a Direct Project address or other personal health account.
1. Leveraging an existing online portal
Many players in the healthcare ecosystem already deliver an online, patient-facing component. For example, virtually all pharmacies have systems where patients can refill prescriptions, and many clinical systems include tethered patient portals for scheduling, paying bills and other tasks. In order for these systems to operate, they have already had to solve the problem of establishing a set of credentials (username/password/etc.) that is linked to a particular patient/consumer record and controlled by the patient or their authorized representative.
When this is the case, no additional proofing need be done. The patient simply logs into their existing (proofed) portal account, and then from within that logged-in experience is directed to log into their HealthVault account. Upon successful login and authorization, HealthVault returns the appropriate identifier to the portal --- and a trusted link has been made.
Figure 1: The HealthVault link option is presented within the context of a pre-proofed portal experience; in this case an employee benefits site that uses a trusted enterprise login system.
2. In-person proofing
In other situations, wecan take advantage of the physical nature of healthcare delivery to establish a HealthVault link. In this approach, the patient presents in-person as part of receiving care and uses a commonly-accepted mechanism such as a government-issued ID card to assure their identity and relationship to their chart.
With this proof established, the provider can issue a secret passcode to the patient. Back at home, the patient or their representative logs into HealthVault and presents their passcode as well as the answer to a second factor knowledge check (e.g., the name of their first elementary school). Because the provider system knows that whoever possesses the passcode is linked to a specific chart in their system, they can now complete the spoke between HealthVault and their patient record.
Figure 2: At the in-person request of a patient, the clinical system allocates a secret passcode that can be used later to make a connection with HealthVault. This screenshot is from the Future Health eConnect EHR; a complete video showing the connection process may be viewed here.
3. Knowledge-based proofing
This is the most recent addition to the approaches for proofing and linking; it is typically used when neither of the first two mechanisms are available --- there is no existing proofed portal, and there is not necessarily an in-person exchange on which to piggyback.
In this approach, the user first logs into HealthVault and authorizes access to the provider system. With that in hand, the provider system initiates a series of knowledge-based questions such as “what model of car did you own in the 1990s”. A small number of vendors have aggregated a great deal of public and semi-public information to create these questionnaires; the end result of the process is a set of demographics and other identifying information that match the subject with “high confidence.”
This approach can be very useful, but it does incur a non-trivial financial cost. In addition, because it is not a “perfect” match and depends on demographics for matching, it can imply an error rate that not all data holders consider acceptable. Finally, it does not work for minors or other members of society where there is no information from which to create a knowledge-based assessment. For all of these reasons, we feel it should be up to individual providers to decide if this approach works for them.
Figure 3: After obtaining HealthVault authorization, LabCorp uses a knowledge based questionnaire to validate the identity of users before sharing lab results. You can try the LabCorp flow yourself here.
Flexibility is key
Efficiently creating trustable links between patients and their providers is the core function of HealthVault; we’ve been at it for some time and feel we understand the problem well. The three models I’ve described are deployed today and creating positive, trusted outcomes for real providers, individuals and their families.
While there are many ideas and options that will make the process simpler and easier over time, it is critical that we do not let those investigations (which I strongly support) delay our ability to make progress today --- flexibility and iterative improvements are critical to the success we’re all working towards.
Thank you for the opportunity to speak; I look forward to your questions.
*** Of course, provider-only systems commonly use demographic-matching algorithms to link patients from different systems into an EMPI. However, the non-zero error rates of these as well as the patient-vouched nature of demographics in a personal record make it not realistic in a patient environment.