Across the Care Continuum, Improving Patient Matching Capabilities Has Become Paramount

Dec. 13, 2018
The Michigan Health Information Network—and other HIEs and HINs—have prioritized projects to standardize patient matching across different entities

Patient matching—the ability to accurately link all of a patient’s health data within and across health systems—has been a challenge for the healthcare industry for decades, and the lack of a nationwide patient matching strategy remains one of the largest unresolved issues in the safe and secure electronic exchange of medical data.

In a 2014 report about the issue, the Office of the National Coordinator for Health Information Technology (ONC) found the best error rate among healthcare providers is around 7 percent, though the error rate is typically closer to 10 to 20 percent within healthcare entities, and this rises to 50 to 60 percent when entities exchange information with each other.

And for health information exchanges (HIEs), the issue is often compounded as they specifically face a significant challenge with matching and linking patient identities because of the diversity and independence of the institutions they serve.

To this end, the Michigan Health Information Network (MiHIN)—a state-designated entity that facilitates information sharing among the state's numerous HIEs and hundreds of thousands of providers—has embarked on a major project: standardizing patient matching across all these different entities in the state.

Specifically, MiHIN officials said in an August announcement that the HIN uses the big data MPI (master patient index) from California-based clinical data exchange company 4medica, along with a private patient attribute or “common key” that links individuals and their health information across systems and organizations. The combined solution enables MiHIN to match patient identities in real time, officials noted.

Shelley Mannino-Marosi, MiHIN's senior director of state and national programs, says in a recent interview that in the early stages, MiHIN’s leaders were entirely determined to only aim for exact matching. “At MiHIN, and in Michigan, our goal is to get the right information about the right patient to the right care team member or provider at the point of care in near real time,” she says.

To help reach that goal, Mannino-Marosi points to one of MiHIN’s core services, its active care relationship service, or ACRS, which enables organizations to submit data files which record the care team relationships attributing a particular patient with health professionals at that organization. As Mannino-Marosi explains, this service enables a provider or payer to “declare” a patient, so that if something happens to him or her, such as a hospital admission, ACRS can be searched to see what providers or health plans have declared that relationship with the patient, leading to that stakeholder getting a notification.

Early on in the process, MiHIN’s staff would search the service and compare the demographics on an incoming ADT (admission, discharge, transfer) notification with the data that was stored in ACRS. “And we would look for an exact match only. We were very cautious in wanting to be extremely accurate and ensure we weren’t sending the incorrect information to the wrong place,” Mannino-Marosi says.

But over time, MiHIN’s leaders realized that there was a need to be more probabilistic. For example, Mannino-Marosi offers that if a patient’s first name is Bill and his doctor has already declared a relationship with this person as William, with the same date of birth, address and social security number, a computer can easily determine that Bill and William are in fact the same person. But with MiHIN’s early-stage patient matching system, the stakeholder who declared that patient would not receive this alert since the demographic information was not an exact match.

So what MiHIN did next was develop its in-house common key service that assigns a “key” or “ID” attribute to each patient. This information was funneled to the centralized MPI from 4medica, and then the common key, or attribute, is given back to the participating organization so that it could be stored in its system to add to any subsequent information, or to strengthen the matching that’s being done in ACRS. Essentially, explains Mannino-Marosi, “the common key becomes a shared attribute that MiHIN’s participating organizations could use to talk to the HIN or to one another.”

When used in action, 4medica’s big data MPI and the common key service can now determine with certainty that even if there’s just a bit of a difference in demographic information, the inbound ADT message is in fact talking about the same patient that the doctor cares about, Mannino-Marosi attests. Gregg Church, president of 4medica, adds, “It’s a guaranteed match even though the demographic change is in there, as we know it’s the same person based on everything that’s being looked at and scored against on the historical information.”

Notably, Mannino-Marosi contends that the common key service acts as a “gatekeeper” to the MPI and won’t automatically add information for patients when they don’t meet a certain threshold for the quality of the data. She explains that if the common key service queries the MPI and knows with certainty that a given patient is in the system, that unique attribute can be used. And at the same time, if the service knows that the person is brand new, he or she is assigned a new key and added to the MPI.

But where things can get tricky is the “middle zone” where it’s too close to call and the computer, as configured, isn’t 100 percent confident. “In that case, we will not assign a common key and will [instead] provide an error message back to the organization,” says Mannino-Marosi. That way, the cleanup of the data is also shared across the state, so the burden of data stewardship is spread out and everyone benefits from the data cleansing activities—as opposed to the person being added to the MPI and potentially pulling redundant information, she adds.

When it comes to evaluating the results of this system, Mannino-Marosi points out that some patient matching companies will boast about 100 percent or near 100 percent matching, but the criteria they are using to match is a grey area. For MiHIN, she notes, one key measure is how many unique identities they have been able to assess in Michigan. “Over a year-and-a-half, we have been able to uniquely identify nearly 8 million of the 9 million Michigan residents, and that number is of course growing,” she says.

Beyond that, another massively important metric to measure is if MiHIN can send more information to more care team members as a result of the service. “If I have three members of our care team but just one is notified, that doesn’t achieve our mission to ensure we’re getting the right information where it needs to go so that a singular patient’s care can be coordinated cost effectively and quickly,” Mannino-Marosi says. But by using the common key service with the 4Medica MPI, MiHIN has been able to send out well over a million more ADT notifications per week. “That’s very significant,” she asserts.

It’s important to note that the common key service from MiHIN is unique to Michigan, and other organizations that do not develop their own unique identifiers are using patient matching solutions—such as 4medica’s big data MPI—in a more conventional manner.

One such entity is the Nebraska Health Information Initiative (NeHII), a statewide HIE that is using the solution to assign unique patient identifiers to patient identities and to match incoming patient data to the right master patient record. According to Jamie Bland, NeHII’s CEO, because her HIE is a qualified clinical data registry for quality reporting purposes, it needed a robust solution that would be able to match patients across various complex data sets. The goal at NeHII, Bland says, “is to grow a true population health repository that matches patients. We can do better population health management and that starts with the identity matching aspect of data management.”

Currently, NeHII collects data from nearly 70 different hospital sources, and more than 200 sources in total across the state and region, says Bland. And because different hospital electronic health records (EHRs) have different matching algorithms for how they match patients, the level of complexity meant that the HIE needed to prioritize identity matching as it continued to grow in the diversity of data it was collecting.  

Bland says that the idea is to marry clinical data, along with claims data and PDMP (prescription drug monitoring program) data so that a population health utility is created. “That’s the last mile of interoperability,” she says. “We are here as a public service to assist in improving identity matching across the state so that we can build a population health infrastructure to make that a solid suite of applications that’s available through the HIE.”

Sponsored Recommendations

The Race to Replace POTS Lines: Keeping Your People and Facilities Safe

Don't wait until it's too late—join our webinar to learn how healthcare organizations are racing to replace obsolete POTS lines, ensuring compliance, reducing liability, and maintaining...

Transform Care Team Operations & Enhance Patient Care

Discover how to overcome key challenges and enhance patient care in our upcoming webinar on September 26. Learn how innovative technologies and strategies can transform care team...

Prior Authorization in Healthcare: Why Now?

Prepare your organization for the CMS 2027 mandate on prior authorization via API. Join our webinar to explore investment insights, real-time data exchange, and the benefits of...

Securing Remote Radiology with the Zero Trust Exchange

Discover how the Zero Trust Exchange is transforming remote radiology security. This video delves into innovative solutions that protect sensitive patient data, ensuring robust...