Patient matching continues to challenge healthcare organizations, though a glimmer of progress emerged in a report accompanying a fiscal 2017 funding bill, in which the House appropriations committee directed the Department of Health and Human Services to provide technical assistance to private-sector-led patient-matching initiatives.
The College of Healthcare Information Management Executives has also offered a $1 million challenge in an effort to find workable solutions to the problem.
For health information exchanges (HIEs), where patient records come in from many different providers, consolidating those records under a single patient’s identity becomes a greater headache.
FierceHealthIT spoke to Tom Check, president and CEO of Healthix, the largest Regional Health Information Organization (RHIO) in New York state, which works with about 300 healthcare organizations that range from the largest health systems to solo physician practices.
Though it has a staff of 50, it relies on two software solutions to resolve issues with patient matching in a fully automated system.
FierceHealthIT: Do HIEs have different patient-matching issues than large healthcare systems?
Check: Health information exchanges have a much higher volume of patient encounters coming into it from a lot of different sources. But more important, in a healthcare system the patient actually presents in person to the registration point.
They can resolve then and there if this is someone who’s already registered in the system. They can update addresses and other demographics.
The patient is right there and can confirm, “Yeah, that’s me.”
We get records from the provider organizations and don’t have contact with the patients to help us reconcile discrepancies. We have to use software and human judgment to determine whether different sets of demographics really identify the same person.
FHIT: How do you address this problem?
Check: We use software for patient identity reconciliation, and that gets us pretty far. That software allows us to set parameters in the matching algorithm to account for fuzzy matches in names and addresses, phone numbers, dates of birth. It allows us to set a threshold value: If these things match perfectly, then it’s clearly the same person. If they don’t match perfectly, how well do they match? We have a cutoff value.
The key elements for matching are first and last name, gender, date of birth, address, phone number, sometimes a health insurance policy number. And the software provides for equivalences: It knows that Margaret is the same name as Meg. It accommodates misspellings of street names. In New York City, we set it up so it knows that people sometimes use their neighborhood name as their city or they use the borough they live in. There are common transpositions in date of birth.
The software comes with a lot of that logic and we can add more.
It gives weights as to the certainty of matches in these different circumstances. Then every couple of years, we convene about a dozen medical records directors from participating hospitals and we go through examples with them of where we have the threshold set.
We ask: Statistically, how solid do we need to be to make the match automatic and at what threshold does a match need manual review? We sample records above and below our current thresholds. We try to reach consensus [on the records that can be matched automatically]. Then we look at samples below the threshold. Starting out, everyone’s agreeing, then as you get farther down, at some point people start saying, “Hey wait. We’d need to ask the patient about that.” When you reach that point, that’s where your threshold should be.
FHIT: Have you used this software from the inception of the organization?
Check: Yes, we’ve used it for eight years. The challenge is that it can't account for changes to patient demographics that legitimately occur between healthcare encounters. You have an individual who goes to the doctor in January and gives a name and address. Then in March that person gets married, changes their name, moves to a different address. Then in June, they go to a different provider and gives the new name and address.
The software we’ve been using has no way to know it’s the same person. We found we were having a good deal of success, but not nearly what we wanted.
At this point, we have more than 50 million medical record numbers at the provider level. We think there are about 16 million real people in that population in our database. Ideally, each of those 300 providers has one medical record number per person, but having gone to multiple providers, [patients will] have multiple medical record numbers. With our existing software, we’ve been able to reconcile that down to about 25 million actual identities, so about half of them.
We have an outside firm that can go through near-matches and manually review them, but again, they don’t have access to the patients in that process, it’s just the data from the EMRs that came to us.
So we looked into products and services that keep track of people’s identities on a continuous basis by using credit histories and other publicly available information. When the person who got married and had a change of name and address comes to a provider, that database would already know it’s the same person.
So these other databases and services are able to help us bridge these identities. We evaluated three services in the second quarter of this year and implemented one [cloud] offering. We found it’s making a 50% reduction in near-matches. So now, even though our total number of medical records keeps going up, we’re doing a good job of consolidating the identities of people appearing in different medical record numbers at different medical organizations. The throughput is really good: We’re able to give it more than 200,000 near-matches a day. When we get through all the near-matches we’ve identified, by the end of January, we think we’ll have reduced that 25 million to 17 million.
The other thing we appreciate about it is that we don’t have to send out huge files of personal health information. We’re able to send out one set of potentially matched identities at a time and get that back in real time, so the amount of PHI we have moving at any given time is less.
FHIT: How do you handle the ones you still can’t match?
Check: In reality, we’re not going to be able to match those. If the two sets of software don’t see these two sets of records being the same person, we probably would not spend the effort to research that case further because it’s too labor-intensive. But with the success we're having with these two systems, it’s hard to imagine doing much better in the absence of a national patient identifier.