Patient matching is the part of healthcare data infrastructure that most teams assume is solved and most teams quietly struggle with in production. The algorithms behind real-world matching range from exact-identifier checks that anyone can implement in an afternoon to probabilistic models that need a data science team to tune. Knowing which algorithm fits which problem saves a lot of false starts.
This list covers the seven matching algorithms worth knowing if you are designing or evaluating a healthcare patient-matching layer. For related FHIR explainers, the broader catalog covers the surrounding ecosystem.
For the architectural framing first, the complete guide to FHIR master patient index in 2026 covers where these algorithms fit in an MPI.
The 7 Patient Matching Algorithms Worth Knowing
Order tracks how often each shows up in production matching pipelines.
- Exact identifier matching. The simplest approach: two records are the same if they share an identifier (MRN, national ID, FHIR resource ID). Necessary baseline, never sufficient on its own.
- Soundex and phonetic matching. Older string-matching approach that compares phonetic encodings of names. Useful as a fallback, brittle for non-English names.
- Jaro-Winkler string similarity. A character-level similarity score, widely used as a feature in modern matching pipelines for names and addresses.
- Levenshtein edit distance. Counts the character insertions, deletions, and substitutions between two strings. Useful for catching typos and transcription errors.
- Fellegi-Sunter probabilistic matching. The classical probabilistic record-linkage framework, still the foundation of most production MPI matching engines.
- Machine-learning ensemble matching. Combines multiple similarity features (name, address, birthdate, demographics) through a trained classifier. Modern MPI products lean on this for the highest accuracy.
- Privacy-preserving matching with Bloom filters. Specialized approach for cross-organization matching where the underlying data cannot be shared in plaintext.
What Separates a Production Matching Algorithm from a Demo
Three operational behaviors are the divider:
- Tunability. Production matching needs a threshold that can be adjusted as your demographic data evolves.
- Audit story. Every match decision should be reconstructable for clinical safety review.
- Performance at scale. A matching algorithm that takes 50ms per pair-check works for batch reconciliation; one that takes 5 seconds does not.
The algorithms above split into those that handle these natively (Fellegi-Sunter, ML ensembles) and those that need to be wrapped to handle them (Soundex, Levenshtein).
Which Algorithm for Which Matching Workflow
Tightly-controlled identifier ecosystems (one EHR, well-managed MRNs) run on exact identifier matching with minimal supplementation. Multi-system patient deduplication needs Fellegi-Sunter or ML ensembles for the demographic variation. Cross-organization matching where data cannot leave the institution lives on privacy-preserving Bloom filter approaches.
For the deterministic-vs-probabilistic side rather than the algorithm catalog, deterministic vs probabilistic patient matching: a practical comparison walks through the trade-offs.
For the product side rather than the algorithm side, Top 5 FHIR-native MPI products for 2026 covers what's available.
How to Evaluate a Matching Algorithm
Take a realistic dataset of patient records with known ground-truth matches, run the candidate algorithm against it, and measure both precision and recall at varying thresholds. The algorithm that gives the right precision-recall curve for your operational tolerance is the one to pick. Anything that performs only well on synthetic test data is the one to drop.
Sources
- Patient Matching IG (covers matching algorithm families) - HL7 build.fhir.org
- Scaling Patient Identity Solutions via FAST Identity IG (algorithm context) - HL7 Blog, 2024
- Patient $match operation specification (evergreen) - HL7 FHIR R5
