Patient Linking with the Tigers

  • Article

Spent the day here in DC participating in the HITPC Privacy & Security "Tiger Team" (why is it that every time I try to write HITPC I write HITSP? Too many acronyms!) meeting on patient matching and linking. An interesting and useful conversation, by design primarily focused on demographic-based matching B2B challenges, but with some discussion of consumer-controlled links as well. I was particularly happy about the points that Wes Rishel drew out on that side of the issue.

I had to submit written testimony for this guy, so figured I might as well double-duty it here for those that might be interested. Fun problems, and great to visit with a collection of faces that are now familiar and valued colleagues. Boy has my life changed since 2005....

Introduction

Thank you for the opportunity to participate in this discussion, one that we agree is of significant importance for the nation. Microsoft Health Solutions delivers healthcare products across the care continuum, every one of which is dependent on patient linking at some level. For example:

  • Amalga , our real-time enterprise data insight system, aggregates patient information from dozens of systems within and between institutions.
  • Vergence , our enterprise context management system, exists entirely to support effective management of identities across workflows.
  • HealthVault , our consumer health platform, links consumer records across the incredibly fragmented data silos that together represent the totality of an individual's care.

While there is much to be discussed regarding advanced techniques for computational matching, it is crystal clear that there will never be a "perfect" solution to this problem. Even ignoring their political implications, unique identifiers do not provide a complete answer --- ID cards are lost, humans make mistakes and care must be delivered nonetheless.

We believe that what is most important to the national dialogue is to recognize that different use cases require different levels of confidence. It is important that we build this recognition into standards and regulatory requirements so that we do not inadvertently suppress innovation that could otherwise significantly advance the state of care.

In my testimony today, I will highlight two examples where different approaches to patient linking support real care scenarios, and look forward to the discussion and questions that they may elicit.

Differentiated Use Cases in the Enterprise

A key tenet of the Amalga system is to use the right information at the right time to answer questions. This demands that we retain a great deal of information about the information we manage - for example, the degree of confidence we have in any given patient match computation. With this metadata available, we can do the right thing in different situations. For example:

  • When matching biometric readings such as an EKG, an extremely high degree of confidence is required --- if unique identifiers do not produce a "perfect" match, human review is almost certainly required before clinical action can be taken, despite the labor costs involved.
  • When presenting a list of patient allergies, it may well be appropriate to accept a higher "false positive" rate in order to reduce the chances of "false negatives" --- because the ramifications of missing a potential allergy tend to be far more severe than those caused by "treating around" one that doesn't actually exist. In these cases, a system might show all matches with greater than 80% confidence, perhaps with an associated "confidence" user interface element that can alert the provider to look more closely if appropriate. This same approach may be taken in computation of drug interactions, or other similar safety-related use cases.
  • When reporting aggregated information or performing population analysis, even lower confidence rates, or those computed by more experimental methods may be acceptable. In these cases, the error rate may be determined to statistically "wash out," enabling useful and important population-level conclusions to be drawn.

In all of these cases, what is most important is not how matches are computed in the whole, but how match-related metadata is used to support a diverse set of use cases, each of which is requires a different idea of how "clean" a match must be.

This approach also enables improvement over time as technology advances, supports offline validation of success rates, and is effective in encouraging the "resiliency and recovery" that Rich described so eloquently in his testimony today.

Privacy-Preserving Links for Consumer Records

Consumer health platforms such as Microsoft HealthVault introduce another level of complexity into an already complex equation. HealthVault has created a sophisticated approach to matching that addresses and mitigates these challenges:

  • Demographics provided through the Internet are generally self-asserted and difficult to trust as input to matching algorithms.
  • Anything less than near-perfect match confidence is unacceptable because of the privacy and legal implications of releasing sensitive information inappropriately.
  • Sharing unique identifiers across "loosely-coupled" boundaries carries significant privacy risk due to potential "collusion" between third parties. For example, if one service knows that patient "X" has HIV and another service knows that patient "X" lives at a particular address, together significant invasions of privacy become trivial.

To address the first two issues above, HealthVault has rejected traditional patient matching methods altogether. Instead, the system relies on a technique called "dual-credential presentation." The idea is that, if an individual can prove that they own a particular HealthVault record and that they are a specific patient at an institution, a link between HealthVault and the institution can be inferred. Each connecting institution decides how best to identify its patients - from conservative in-person proofing to more online-friendly credit-report-style questionnaires - and combines that with a HealthVault login to complete a link that complies with their specific policies.

The privacy risk identified in the third bullet above is addressed by giving each external system its own, randomly-generated identifier for connected HealthVault records. In the figure below, you can see that although both hospitals have relationships with the individual "11111" in HealthVault, each "knows" that patient by a different "pseudo-identifier." In this way, HealthVault is able to act as a de-facto EMPI between loosely-coupled systems that have no knowledge of each other, encouraging reliable exchange without risk of collusion between them. 

 

Thank You

The work that has been done by the Tiger Team since its formation earlier this year has been instrumental in accelerating real-world techniques for healthcare information exchange. I and Microsoft appreciate the opportunity to contribute as we collectively learn how to best continue to make progress.