With a Hopeful Eye on Washington, Providers Continue Work on Patient-Matching Solutions

Eric Raffin recently became chief information officer for the San Francisco Department of Public Health after holding the same position for San Mateo County in California for several years. In San Mateo County, there are four different EHRs in use, and Raffin says the public health system needed to find a way to pull patient demographic data together. “We realized we really didn’t know at a level we could trust who is being served by which parts of our organization,” he explains. “We couldn’t necessarily see who were our most complex clients because they were seen in the behavioral health area or in a clinic, or maybe their child is enrolled in a family health services program. No one could see the big picture.”

To fill in the story, you need a table of contents and an index, Raffin adds. In order to present that patient story with relevant clinical and social services information, you have to unify the identity. San Mateo County deployed an enterprise master patient index solution from NextGate. Once the MPI was put in place, it enabled the creation of San Mateo County Connected Care, a health information organization which has exchange capabilities and is leading to the development of an enterprise data warehouse and analytics capabilities. “All those steps start with understanding who your clients are and where they are touching your organization,” Raffin says.

Raffin describes how it works: Using probabilistic matching, once the software gets a certain percentage confidence level your organization is comfortable with, it presumes there is a match and merges records so that instead of three versions of a person in an index, you have only one. It also highlights records it is not sure enough about to merge; those are passed along to health information management staff to analyze. “At the end of the day, there are duplicate records because the employees registering people at the point of care don’t have the information they need or the time to search when someone is standing right in front of them for an appointment,” he says. “If you don’t have a tool at your disposal, you are much more likely to create a duplicate record because you need to get that person seen,” he says.

Another nice component of these MPI solutions, Raffin says, is the ability to go into active mode, which means to decrease the likelihood of creating a duplicate record, you point the lookup feature in your EHR not just at one system out of your four, but at your enterprise MPI. If John Doe has been seen in behavioral health, then you can import the most current demographic into your system from within the MPI. “That is a game changer,” he adds. “The person at the front end who has a long line of people in front of them is able to see whether this person exists anywhere in the system and make a good choice. If they don’t show up in the MPI, it is much more likely that they are actually new to the system, and you should create a new registration.”

Raffin recently took the position of CIO at the San Francisco Department of Public Health, which is right at the beginning of a go-live on Epic’s EHR. Eventually getting all the clinics on the same system will resolve some of the risk in patient matching, he notes, but at least initially San Francisco will have some offices that are not on Epic. “For those, our goal is to ensure we can keep as many of the registration databases connected to the EMPI to make sure that matching is going on.”

Intermountain turns to referential matching

Shannon Hood, a solutions architect on the identity integrity team at Intermountain Healthcare in Utah, has been working for 25 years on the organization’s patient-matching efforts, and has experience with deterministic, probabilistic and referential matching. In 2014 Intermountain encountered a problem when it upgraded its master data management (MDM) solution, and more than 220,000 potential duplicates were generated that had to be investigated. “When we do have to merge or consolidate records, we have to ensure we have done it appropriately,” she explains. Working with a few contractors, the team set out to clean up the data, but Hood estimated that at the rate they were going it would take thousands of hours. “If each investigation took 10 minutes, it was going to take 916 weeks or 17.6 years,” she says. “That was untenable.”

Intermountain began working with a company called Verato, whose cloud-based Auto-Steward service automates some of this work by using what it calls referential matching technology. Verato describes it like this: “Rather than directly comparing the demographic data from two patient records to see if they match, Verato instead matches that demographic data to its comprehensive and continuously updated reference database of identities. This proprietary database contains over 300 million identities spanning the entire U.S. population, and each identity contains a complete profile of demographic data spanning a 30-year history. It is essentially a pre-built answer key for all patient demographic data.” Also, Verato’s database has lots of demographic attributes such as e-mail addresses and former residential addresses that the Intermountain database does not have access to.

After working with the solution for a while, Hood studied the impact of the deployment and found that it improved Intermountain’s data stewardship productivity by 174 percent, and the contractors were able to cut the backlog by two-thirds. She says Intermountain is interested in piloting a more real-time solution as well. “Instead of having to send them files, we would use a real-time API in our work flow to have Verato uncover duplicate records in real-time,” she says. “Then it would be used not just for our backlog, but also for routine duplicate investigations as well. We are very excited about that potential.”

A crowd-sourcing approach in Michigan

The Michigan Health Information Network Shared Services (MiHIN) is taking a crowd-sourcing approach to the issue. Tim Pletcher, executive director of the nonprofit organization, believes that “patient matching is not the problem, but everybody goes after it. The issue is linking. You don’t know who is connected to whom. If you solve for that problem, you actually can pick up a lot of the things around the matching process.”

MiHIN has created a “Common Key Service,” which assigns a unique attribute to every patient — one that cannot be read by humans. The service supports the goal of ensuring that information attributed to a patient is correct. So far, 9.5 million unique patients have been assigned common keys.

Pletcher described how it works: “We get everybody in the state to declare their linkages to a person. They all send us rosters. A health plan can send us its entire roster of patients; or it could be a whole population of an ACO, or just a doctor’s office,” he says. “All of that comes to us as part of our Active Care Relationship Service. Everybody is telling us who they are connected to. We feed that information into the Common Key Service, which uses one of the more advanced MPIs. We then assign a common key, which is meant for computers to read, not human beings. It is a big string of numbers meant to be an additional attribute on patient data, not the unique identifier. It is a giant crowd-sourced activity that is carried on statewide. The service also returns patient IDs it can’t match and tells health systems they need to clean those up.”

Some large healthcare organizations have lots of resources and dedicate teams of eight to 10 people to do that health information management work, Pletcher says. “But if you are a small organization, you don’t have that. Our Common Key Service is designed to allow the smaller practices and organizations to crowd-source to get the best data in the middle.”

He stresses that the provider organizations don’t need to go through a central translator every time they want to match patient identity data. Even when one Epic organization queries another Epic organization, there are matching problems, he says. “But when they add the common key, it actually improves the behind-the-scenes data exchange that we weren’t even a part of. The common key is an additional identifier that people can use in their own matching algorithm. We are not saying ‘thou shalt’ or we are the best. We tell them to trust this at the rate they want. We don’t have to harmonize everyone’s patient-matching policies across the state. We passively distribute this back to everyone and ask them to do their best to use it.”

James Noland, MiHIN senior product marketing manager, says that 45 organizations in Michigan are sending data with common keys, including two payers and all the major physician organizations. “We have gotten significant positive feedback,” he adds. “We know this shared process for patient identity resolution and data stewardship across organizations cleans up their data,” he stresses. “We push out notifications that an organization has recognized that these two patients we thought might be different are in fact the same person, so you can use that to help clean up your own data. In a couple major health systems participating, Henry Ford and Trinity Health, we have had good feedback that they have used it to clean up their internal duplicates.”

Other states have taken notice of the progress in Michigan. Common Key Service also is currently deployed in New Jersey with Oregon to complete deployment in 2020. Minnesota is considering it as well.

People have asked Pletcher what would happen to the Common Key Service if a national patient identifier were ever adopted. “I think it would be great,” he says. “I tell them we would be the fastest state in the union to onboard another identifier because we can actually match everybody. It would be a simple search and replace.”