Overview of Mirth Match Matching Module facility
Mirth Match, developed by Mirth Corporation, is an implementation of the HSSP Entity Cross-reference Service (IXS) specification , which was submitted for ballot and approved in late 2009. IXS can be most easily thought of in the healthcare domain as an Enterprise Master Patient Index where it is given the responsibility for maintaining relationships (or linkages) between patients from multiple systems within a single enterprise as in an enterprise patient registry or across multiple communities in a Health Information Exchange (HIE) scenario.
Although typically used as the basis for building and maintaining an EMPI, an XIS service like Mirth Match can also serve to maintain other registries. Some other example use scenarios:
• Master provider index – tracking healthcare providers across an HIE community
• Master enterprise healthcare facility index – tracking source facilities across a regional group of health organization
• Master lab order code index – maintaining an index of lab order and test concepts allowing
Pluggable Matching Module Architecture
In Mirth Match all entity matching is completely factored out into matching modules. Users may write their own matching modules by following this guide. As of version 1.2, MirthMatch is bundled with a basic matching module inspired by the MHSip algorithm (see below).
Matching Phases
There are two main phases in the mirth match scoring process:
- The blocking phase reduces the overall search space before actual scoring takes place. This makes the scoring phase more efficient. More concretely, for a 1M entity population, when a new entity is registered and needs to be scored, it is far more efficient to compare this new entity with the 10 or 20 most similar entities rather than to exhaustively compare it with the entire 1M entity population. Matching modules may make use of special derived traits (traits derived from primary traits) for blocking. Only entities that first match based on these derived traits are actually compared. One example is last name metaphone plus birth date (derived from the primary traits last name and birth date).
- The scoring phase applies weights for various traits to come up with a confidence score for each entity pair. If the score is above a predetermined threshold, the score is considered a match, and a "link" between these two entities is stored in the database.
Scoring Thresholds and Relationship States
When a matching module computes a score for an entity pair, the score represents the degree of confidence that the two entity records actually refer to the same entity. The user, or matching module implementer, must determine what confidence score level is sufficient for a match to be created automatically by the matching module. There are two threshold levels:
- Automatic: Matches are automatically created (do not require human intervention) and are put into an actual state when scores are above this threshold.
- Manual Review: Matches are put into a potential state if the confidence score is between this threshold and the automatic threshold. They require manual approval in order to be put into an actual state.