Patient Matching: Current State of Affairs Part 1 (of 2)

Lipsa Panda
Jul 25, 2021
8 min read

What is Patient Matching?

Sharing data is a pain in healthcare. Given all the data available to construct a data model around a patient’s health (labs, images, diagnoses, conversations, notes, dates, bills) and that data is collected in different doctor’s offices, hospitals or healthcare facilities in a variety of formats (electronic, paper etc.), it’s no wonder that healthcare "interoperability" is the buzzword of the last decade.

Even though medical records have been around since 1928, efforts to digitize them had not really been widely adopted until 2009 when President Barack Obama signed into law the Health Information Technology for Economic and Clinical Health (HITECH) Act. This set a goal such that 70% of medical providers would have to adopt some sort of electronic (as opposed to paper) health record by 2014. While this was easy enough for large profitable hospital systems to do -- this proved to be challenging for smaller practices.

In the 12 years since the bill became law in 2009, investment in digital health, electronic health data capture, and healthcare interoperability has skyrocketed. The key thing to take away here is that this field is still brand new. Healthcare monoliths have only recently adopted technology conventions that have been in place for many years in other industries (like APIs or transitioning from locally managed data centers to cloud computing). The bulk of investment now is in helping providers adopt new technologies faster, mine mountains of unstructured data, and use technology to drive innovation and automation of critical health services functions.

I’d like to focus on a very specific and pervasive problem in the brave new world of digital health: patient matching.

Patient matching is defined as the identification and linking of one patient's data within and across health systems in order to obtain a comprehensive view of that patient's health care record.

Patient matching is necessary because when one health system communicates with another re: a patient, they need to identify which patient the conversation is about. To make matters more complicated, health systems don’t often use the same data structures (read: "grammar/verbs/nouns") when talking about patients.

Different health systems and providers adopted different internal data schemas and models for health care data as they complied with HITECH (schema here refers to entity field names and data types while models refers to type of datastore: document model, relational model, graph model). While there are external data standards being designed for the industry and some that had even been in place (like FHIR, HL7, ADT), most systems maintained transitional layers that "normalized" data between external standards and internal schemas. Furthermore, other healthcare entities such as insurers, wearable device makers were not forced to comply with federal standards and started capturing novel types of data (heart rate and location over time for instance). As such, when data moved from place to place -- it became very hard to match incoming data to an existing patient record.

What does this look like in practice?

Let's start with an example:

Mr. Fred Jones lives right next door to Mr. Frederick Jones. In fact, they live in the same building. Actually Mr. Frederick Jones is Mr. Fred Jones’s father but Freddie (Jr) never refers to him that way. He has always been Mr. Jones or Sir (let's not unpack it). They both seek care with the same PCP, Dr. Wahlia. Dr. Wahlia used to use paper records for 20 years and now she has to switch to an EMR. She picks the cheapest one and hires an administrative assistant to digitize all new records/data entry. The assistant (poor soul) gets tired with all the typing he has to do and starts skipping suffixes. Coffee deprived, he accidentally transposes Apt 1 with Apt 2. Mr. Frederick Jones and Freddie Jr are now the one and the same Mr. Fred Jones who live right next to one another (but have switched apartments) with two seemingly duplicate records in a patient database.

Symptoms

The above example is rife with the symptoms of poor patient data capture. Pew Research has put together an infographic with the most important symptoms of patient matching problems. I say symptoms here because they indicate the issue of not being able to link a particular patient to another.

What's actually happening here?

A burgeoning industry means everyone is going to try to do things differently to experiment with innovative new practices. Another key distinguishing part of the above story is the experience of obtaining care is decentralized. As patients switch from job to job to no job to retirement or from provider to provider for second opinion to OneMedical back to provider, they accrue records of healthcare communication and decisions in hundreds of different places. For years the onus has been on the member to keep meticulous records or (during the era of paper) for providers to fax one another records. So two things characterize the health IT industry right now:

Decentralization
Experimenting with new strategies for data capture

Decentralization

Decentralization is at the heart of current interoperability issues. As stated earlier, throughout the course of a patient’s life - hundreds of providers/insurers and the like will accrue valuable information about patients and that means they will have to communicate and authenticate whether the information being shared is about the correct patient.

There are three main problems I see with decentralization:

There is no universal unique identifier for a given patient across healthcare organizations. Nothing like an SSN or a Passport Number or Driver's License that is maintained across health systems and organizations. This means data needs to be matched up on all the other information that could uniquely identify a patient. This includes, but is not limited to, your date of birth, full names, addresses, phone numbers, or gender. Why does this not include your actual SSN? Some systems capture that information, other systems don’t but most of the time it’s a really risky thing to give out anyway and it is surprising how commonly it is incorrectly written down. This is the root dilemma that seeds all the other problems listed below.
Data entry is prone to human and machine error; and since there is no single source of truth, it can go years uncorrected. No single system contains all the correct (or up-to-date for that matter) information so conflict resolution is difficult.
Data collection is neither a pull or a push system -- it happens randomly whenever a patient has an encounter. Healthcare providers cannot subscribe to patient information and patients cannot publish their information when it changes (like a marriage or job change).

Experimentation

Experimenting is really useful to drive innovation. OTOH it can causes problems without appropriate change management. Anyone who has tried to develop a publicly exposed API is aware that changes have to be tightly versioned over time and well communicated. Experimentation needs to be coupled with service level agreements so that when different healthcare actors communicate about patients, they are not changing the rules of the language as they speak.

While experimentation isn't inherently bad, risks arise from:

Patient records become really hard to match up if people are not using the same conventions and standards (but instead creating their own). Healthcare providers can enforce different rules for encoding things like addresses or names or make certain fields optional which means sparse data (much more missing information).
As we create new technologies and the world changes, we need to be able to flex to novel data concepts together (like managing non-binary gender in health data records or finding a way to incorporate data from wearable devices into a patient record or patients getting married and changing surnames and address). But if we experiment too fast, we may cause backward incompatibility [when new systems can’t ingest old data] or forward incompatibility [when old systems can’t ingest new data].

So we have established patient matching symptoms and the root causes of the patient matching problem. Now let's talk about

Consequences

Let’s go back to the Jones’s. Without warning, Senior goes into the hospital for an acute bacterial infection. He is unresponsive and cannot answer questions about his health. His son shares that they both go to the same PCP and Dr. Wahlia’s team is contacted for the medical records. In a rush, the office of Dr. Wahlia accidentally sends over Mr. Fred Jones’ medical information. Freddie authenticates the data based on the address. The hospitalist reviews the data and puts Senior on penicillin. Senior goes into shock. Unbeknownst to the internist, Mr. Frederick Jones Sr is allergic to penicillin but Freddie Jr is not.

This may seem inconceivable to you. The reality is: this happens all the time. One "study estimated that 195,000 deaths occur each year because of medical errors, with 10 of 17 being the result of identity errors or “wrong patient errors." Much of the time, this is due to duplica te patient records in the EMR. This, furthermore, can lead to duplicate billing issues. "A RAND Corporation report on duplicate records indicates that the average duplicate record rate for US healthcare organizations is 8 percent and is higher in large systems (15 to 16 percent)." Each duplicated patient is a source for errors as egregious as doctors operating on the wrong knee.

It also may be hard for you to envision what strategies healthcare providers use to deal with patient matching. A GAO report in 2019 describes the experience (because they have HAD this experience) of manually matching patient records.

All seven provider representatives we interviewed described manual matching as one of the ways that they match patient records when exchanging health information with other providers. With manual matching, an individual reviews a medical record in order to match it to the correct patient. For example, an outpatient practice representative said that to match records that the practice receives by fax, a staff member must manually review information such as name and DOB to identify the correct patient and add the new information to the correct patient’s electronic record. All of the provider representatives we interviewed told us that they receive health records from other providers by fax.

If that doesn’t offend you (assuming you are interested in tech), you’re not going to enjoy the rest of this article so carry on your merry way. And while there are automated approaches available, the UI/UX is not much better.

For example, representatives from four of the six providers told us they used a module offered by their EHR system vendor to match records and exchange information with other providers that use the same vendor’s EHR systems.20 The module includes an algorithm that compares patients’ demographic information and, if the information in two or more records is identical or very similar, can automatically link the records. Automated matching can also involve some degree of manual review, as algorithms can identify potential matches by providing information about the likelihood that two records with similar information refer to the same individual.

The EHealthInitiative (EHI) also did several surveys asking healthcare leaders what they believed were the impacts of not handling patient matching.

Until next time

Yikes, I think we've done our best to impress the consequences of not getting a solution for this ASAP. We've talked about classic symptoms of patient data problems - namely poor data management strategies, underlying causes of patient matching - decentralization of information and experimentation, and finally an example of the pain associated with this problem.

Good news though, the government (and non-government agencies) are on it. Next week, I'll cover some of the fundamentals around federal efforts to improve patient matching. We will talk about

How the government sees its role *this may change based on the administration
A short timeline of events since they started working on this problem
Where we are now

Thanks for reading! Please feel free to post in the comments if you have anything to add or suggest in terms of changes.