Yesterday, June 1, 2020 the ONC held a working session on patient identity and patient matching. I was able to attend along with some other Project Unify group members and here are my takeaways along with some takeaways/thoughts/comments from other members:

While I missed some presentations due to other work, many of the ONC Patient Identification and Matching workshop presentations seemed to be either (mostly) “Yay!” Universal Patient Identifier (UPI) cheerleaders (and specific proposals for UPIs) or “Warning!” NPI/UPI naysayers. Amongst the pro-UPI presentations there was also a nice introduction, by Jim St Clair, to the Trust over IP Foundation – How Blockchains Can Anchor Trust on the Internet via Self-Sovereign Identity credentials – an interesting approach to a UPI in control of the end individual.

Given the history of misuse of SSN by identity thieves and poor governance processes that undermine SSN uniqueness over time, I personally have my doubts about how long UPI will remain unique. Although I am usually an ardent champion of using technology to solve problems, even with the best technology we haven’t manage to keep, for example, such financially valuable/sensitive ids such as credit card numbers from being misused by the bad guys. I personally suspect that, short of using blockchain, UPI will become yet another vector for identify theft or health care services theft.

And, UPI will not address matching requirements for:

1. Historical information (data pre-dating UPI assignment)
2. Research information (anonymized data, yet still needing unique identification)
3. New borns (UPI not yet assigned)
4. Impoverished but outside the social safety net system (patients not yet “case managed”)
5. “Known to the Practice” patients (HIPAA-supported anonymous medical consultation)
6. Illegal Immigrants, Criminals, Celebrity/VIPs (patients actively avoiding accurate identification)
7. Human Services, Education, Courts, etc. Matching (UPI not likely to be sharable across domains)

That said, while UPI is not a panacea, UPI will help address patient identification and matching requirements for those patients with public or private health insurance (payers) and/or who are otherwise well-known to the health care system. And there is significant health care and payer industry enthusiasm for a UPI since it could dramatically reduce health IT costs and reduce health care mistakes for (my guess) about 80%-90% of patient encounters. (There was an interesting NHS slide towards the end of the afternoon which listed % missing UPIs for various types of encounters. I didn’t think to correlate their numbers with my intuition. It would be worth digging that slide out once we are granted access to the entire deck.)

So, accepting the concept of a UPI, how does that affect what we need to do for effective cross-domain patient/client identification and matching within Project Unify? Well, while UPI reduces costs and increases information sharing across health care systems and payers, it does not completely eliminate need for effective patient identification and matching within the health domain, and doesn't address client identification and matching across non-health domains. This is especially disconcerting when attempting to integrate health-related information across health care systems and educational systems, human services systems, and/or courts systems.

Project Unify needs to stay focused on putting in place technology, processes, policy and governance for cross-domain patient/client identification and matching. This is particularly important for Project Unify since a higher percentage of the human services clients being served by an integrated social services/health care system are likely to lack a UPI, at least during initial encounters.

Finally, I thought the presentation on NYS SHIN-NY patient matching was one of the few that discussed the full range of multi-factor matching issues and I recommend we embrace some of their thinking independent of whether there is a NPI/UPI in our mix of multi-domain multi-factor (and possibly referential) matching. And Mark LaRow of Verato, Howard Sragow of AllScripts, and David Speights of Appriss each had nicely balanced presentations on referential matching approaches.

TL/DR: We can cheer on UPI/NPI for healthcare, but we will also still need to do the hard work of multi-factor matching between non-health domains and health care.

Brian Book

I’ve talked about the same topics many times in the community and think there is a simple solution to this problem.  You can see my thoughts here if you are interested:  https://blog.bookzurman.com/blog/brianbookshiftspatientmatchingprotocol

I’ve lamented many times that the healthcare community, somehow, believes that its problems are so unique that they can’t look outside healthcare for solutions to their problems.  Many have been solved over and over again with fabulous success outside healthcare, but we continue to try to reinvent the wheel (or setup a new workgroup or create something new that will take a decade to implement).

Feedback from Noam Arzt

Watched your video, Brian. Interesting. Of course, I do a lot of work with children - they have no credit cards and credit card companies are not that great dealing with proxies And how do you respond to the comment by one of the speakers that it is important to keep financial and healthcare domains (for instance) separate so there is no security exposure between them. And given the debacles that have happened with security of financial service information (e.g., the Experian breach), is that industry really the right steward for this?

As for your post office analogy, millions and millions of letters don't go to the right place, in some locations more than others. That's why I have Informed Delivery and I things do get missed.

Generally, I found the entire day useless. Sounded like the same people saying the same things they usually do. I know from back channel e-mail with ONC that this is all about deciding whether to recommend that Congress approve a UPI or not.

Response from Brian to Noam

I’m proposing that healthcare leverage the credit card companies ability to issue and manage unique numbers, not extend credit to everyone. This would keep the finance and healthcare domains separate. I’m not proposing that the industries merge, but rather issue anyone who asks a unique number. As a standards proponent, I originally thought that healthcare should just use the standards that the credit card companies use to create their own unique numbers, but I think this would lead to endless workgroups that would want to reinvent those standards and again push us a decade away from a solution. As for the Experian breach, this was a “Credit Reporting” breach, not a “Credit Card” breach. They are two completely separate industries, but even they are orders of magnitude more capable of matching people and transactions than the most successful patient matching system.

I am a Six Sigma Blackbelt and managed hundreds of product and process improvement projects in my past.  A process that is operating at a Six Sigma level produces 3.4 defects per million opportunities. So in my mail analogy, for every million letters sent, only 3.4 would not make it to their destination.  Believe it or not (I had a really hard time believing it) the US Postal System is close to Six Sigma in their ability to deliver that mail.  They deliver 472.1M mail pieces per day, even if patient matching was 99% effective at matching patient records at the post office that would be 4.7M pieces of mail undelivered per day.  I assure you, patient matching will never get to 99% accuracy, ever.

So, I have made the same challenge to everyone that doesn’t like my approach.  How would you solve the problem?

Response from Noam to Brian

Thanks for your explanations, Brian. I appreciate it.

Still getting my thoughts together on alternative solutions, though I have written about this a lot. Remember, not all problems have solutions...

Andrew Laing

 I appreciate this discussion and listened in as much as I could yesterday.

Yet I am frustrated at the nature of the discussion. Why isn’t our industry better at articulating:

1. At its root, entity match is about trust... trust that the match is correct. Trust falls on a continuum and is not a binary. Does “pretty sure” suffice? Maybe.
2. Context matters. Data are sensed. Data are attempts at measuring the real world. Understanding the context of their origination (provenance) and handling along the way gives intelligence to qualify match.
3. And along those lines, clean (enough) data is fundamental to usability, including match.
4. Traditional thinking will not solve match-at-scale. This is a non-linear problem (exponential) that prevents using traditional ETL or MDM approach. (see Blunder #4 from data luminary Mike Stonebraker: https://youtu.be/4SK8jdBhGNI?t=698)
5. What are my data rights? Data sovereignty? We need better mechanisms to enforce data governance. If my data are mine, whether for pie-in-the-sky monetization opportunities or for real-world accuracy challenges in a service-delivery model, how do I exercise my rights post-match?

 For me, the UPI conversation doesn’t seem to solve (or even pretend to understand) these issues. SSN has been around for a long time, for instance.

 I don’t know the answers but am reluctant to just stand around with my hands in my pocket, admiring the problem. Ideas that resonate for me include better chain-of-custody/metadata-management (blockchain-model, Apache Kafka event-model), match-at-time-of-use through adaptive (ML) algorithms, and systems-of-governance built around challenges of semantics and efficacy.

Unify seems well positioned to provide a functional model that includes hooks for match (as well as cleaning/wrangling/munging) and governance. It doesn’t have to solve everything. Naming the problem and building coalition to address may well be enough.

Eric Jahn

Speaking of provenance, here is a vocabulary that could be used for describing the provenance of identifiers: http://trdf.sourceforge.net/provenance/ns.html .