Sections

← Back to Patient Matching & Linking Toolkit

Patient matching can be implemented in different ways. Each project will have a set of requirements that make it unique. In this section, we will discuss some of the aspects to consider when capturing those requirements, what defines a patient matching project profile, and how to choose the best patient matching tool.

Disclaimer: The information presented here is to be used as a guideline, and each project will have very unique requirements that need to be taken into account and is not possible to capture all of them here. The tools and algorithms discussed were selected from our research but are not extensive.

Before embarking on the task of implementing patient matching, we should define what is the project profile. These are the aspects that need to be considered:

Production and Evaluation environments might use the same tool or different ones. As an example, Client Registries (CR) don’t normally include evaluation capabilities, so when CRs are used for production, another evaluation tool that processes records in batch can be used to calculate precision and recall and identify the optimal configuration for the linking.

Different projects might require one or more of the following requirements:

A Health Information Exchange (HIE) makes sharing health data across information systems possible. It enables data to be shared between databases, facilities, and across regions or countries.

The component in an HIE that executes patient matching is commonly called a Client Registry and these are the main workflows it must support:

The client registry implements a patient matching engine that operates in a transactional way. For the workflows above, every time a transaction is sent to the CR, the engine can search for patients that match and create links between them when required.

Existing data captured over a period of time from different source systems needs to be deduplicated. For this requirement, the existing records that belong to the same person need to be merged and a new database with unique records and merged data needs to be created.

This use case might also require the ongoing batch deduplication of smaller datasets later on.

Records in an existing database captured over a period of time from different source systems need to be linked and form a group or cluster when they belong to the same person. Records are not usually merged, as each source system can continue managing its data.

It is common for Client Registries to use linking in batch to load data for the first time into the system.

Scale options

Design recommendations

A blocking strategy needs to be implemented depending on the processing power available and the number of pairs to compare. Usually, medium and high scales require blocking.

A high-performance patient matching tool (multi-server architecture) is usually needed for high scales.

Low-quality data requires more complexity in the way patient matching is implemented for it to be successful. Probabilistic algorithms, especially when machine learning is applied, consistently outperform deterministic algorithms when the data quality is low.

This is a possible categorisation for existing patient matching approaches and algorithms, ordered in level of complexity:

These are two recent projects where Jembi is involved currently and patient matching was implemented.

The DISI MVP is an HIE implementation where a client registry is required. The data used for this project is synthetic, and it was generated to be of low quality. This project profile can be found below.

Based on this analysis, the tools selected are the following:

The Ethiopia example is an interim solution implemented to deduplicate existing data in a RedCap server. In future, a client registry is expected to be implemented.

The project diagram is as follows:

Based on this analysis, the tools selected are the following:

On This Page