Identifying and Merging Duplicate Information Within Entities
HealthUnity MPI has the ability to indentify duplicate patient records coming from various patient record sources. However, in order for the MPI to be really effective, clean MPI identify feeds are important.
Once the data reaches the HIE MPI, the criteria used for duplicate identification is same as the criteria used for grouping patient records coming from different entities or patient sources. When the MPI system groups two patient records coming from a common patient source, they are marked as duplicates.
The HealthUnity MPI administration tool can be used to generate a report on duplicate records within an entity. We can export the report per source and send it over to the designated administrator of the source, who, in turn, must either merge the patients and send a merge message or call the merge API for merging the patient records in the MPI.
Merging Patient Records Across Entities
HealthUnity supports two distinct methods to merge patient records across entities. One of them is rule based auto grouping. Another is manual grouping using the MPI administration tool.
As noted above, through experience we have identified 11 rules that have proved to be effective in healthcare environment. These 11 rules come predefined with HealthUnity MPI. However, we can support practically unlimited number of additional rules to suite the requirement and the nature of data in hand. These rules can also be created later as the MPI gets loaded with more data and new matching patterns emerge. In such case, we have an option to re-do the grouping and indexing of MPI in offline mode without affecting the availability of the MPI.
MPI Rule Editor.
Following are some of the important fields available to the MPI administrator for creating rules:
|Name||Flipping of names words, common spelling mistakes, initials, diminutives, hyphenated names|
|Date of Birth||Proximity Search|
|SSN||By design – We limit to single transposition error|
|Driver's License||By design – We limit to single transposition error|
|Insurance Policy Number||By design – We limit to single transposition error|
|Phone Numbers||By design – We limit to single transposition error|
|Mother's Maiden Name||Flipping of names words common spelling mistakes, initials, diminutives, hyphenated names|
|Street Address||Flipping of words, common spelling mistakes, diminutives|
An MPI administrator can use the use the MPI administration tool to pull one or more patient records through one or more searches to the manual grouping worksheet and regroup patient records by simple dragging and dropping to different groups. Once the administrator is satisfied with the regrouping, she can confirm the regrouping. Patient records that are regrouped manually remained so till their grouping is changed manually. All the administrative activities are logged for audit purpose.
Manual Grouping worksheet. Names can be dragged from one group to manually regroup patient records.
Whenever there is any change in the patient grouping, whether within the entity or across the entity, the information is communicated using PIX notification messages to all the participating systems registered for listening to the PIX notification. This option is selectable by the customer.
Unmerge can be handled using automated mechanisms as well as manual (tool based) mechanisms.
Automated Unmerge: This is done by sending HL7 ADTA37 messages to the MPI system.
Manual Unmerge: HealthUnity MPI comes with an administrative tool which can be used to merge or unmerge identities manually. All the administrative activities are logged. Identities manually merged or unmerged can only be unmerged or merged respectively using manual methods, and they are otherwise unaffected by the grouping rules
Auto grouping is handled through a rules engine that executes multiple parallel matching rules which may be deterministic or probabilistic in its algorithmic behavior.
Architecture and process of bi-directional data-synchronization between registration systems and MPI
We support PIX notification as a configurable option that can be used for bi-directional data-synchronization between a participating entity and the HIE MPI.
To begin with, the participating entity sends an ADT feed to the HIE MPI.
The HIE MPI processes the patient record, forms patient record groups, and sends PIX notification to all the participating entities that are listening to PIX notification and where the patient exists. In order for the participating entities to perform two-way data synchronization, they should be able to successfully consume PIX notification messages.
The participating entities may cache the PIX notification message for future use.
A participating entity can periodically query the HIE MPI to fetch the latest ADT information from a given patient record source along with the timestamp of the message, compare the fetched patient record with their own copy and update their own record if they wish to. This way, we can perform two-way data synchronization between the HIE MPI and participating entities.
Our studies have shown that more than 20% of demographic data changes every year so that many back end systems are out of date. Those systems can subscribe to the latest demographic data subject to patient privacy and security constraints set by the HIE Operator.
Frequency-based indexing so that rare values receive different weights than common values
Our MPI solution has been fine tuned for healthcare domain using the entropy of common demographic fields. Fields with least entropy such as gender, race, religion, country etc. are least relevant in patient search as well as record linking. On the other hand, fields with high entropy such as SSN, DL, Insurance Policy Number etc. are highly relevant for above mentioned usage. The frequency analysis has been used intelligently in our MPI not only in designing the relevant rules but also for fine tuning the performance of MPI.
We believe that our MPI solution is the best tuned system for HIEs. MPI's deployed in HIE environments have to meet a much higher bar on grouping integrity as well as scalability. It is extremely important to maintain the integrity of the system by minimizing false positives. This is where the superior architecture and design of the HU MPI really makes a big difference for our HIE customers.
MPI leverage of probabilistic and deterministic scoring algorithm
We leverage probabilistic, deterministic as well as fuzzy logic scoring algorithms.
Our MPI utilizes multiple rules in parallel. Based on the customer's choice of specific configuration, we utilize deterministic or probabilistic and fuzzy logic matching algorithms. These algorithms are chosen automatically based on specific field types that are exactly fine tuned for healthcare and HIE settings within our product. For example, for text fields such as name, mother's maiden name, and street address we utilize fuzzy logic and probabilistic scoring algorithms. As described above we also provide tools to allow manual deterministic methods. The best way to describe our MPI is that it is fine tuned for healthcare environments, with a particular focus on HIE use cases.
Our MPI supports true probabilistic scoring for text fields where the importance of a matching word in text depends on the rareness of the word. For example, assuming that John is more common word in the MPI database than 'White'; the match score between 'John White' and 'John' would be lower than the match score between 'John White' and 'White'.
Support for equivalence strings (i.e. nicknames for with formal names)
The HealthUnity MPI algorithm supports equivalence strings. By way of example we have full support for abbreviations, nicknames, diminutives as well as synonyms. While these are configurable through the MPI administration console, our MPI product comes with a predefined set of abbreviations, diminutives, nicknames and synonyms for thousands of common American names, address lines (e.g. “St” for Street) and other text fields. They were designed specifically by studying scenarios that are commonly found in healthcare environments. Again, this illustrates the fact that we are finely tuned to work in the US healthcare environment.
Supported Versions of HL7
- Hl7 2.3.1 and 2.5 as required by IHE and CCHIT
- HL7 2.5.1 required for HIE certification
- HL7 v3 including CDA and CCD
In addition to above standards, we have the capability to quickly develop adapters to support other versions of HL7 using the Microsoft BizTalk Mapper tool and our own data cleansing and compliance tools.
Standards support in MPI solution
For an MPI solution to be useful in the US Healthcare environment, at the minimum it needs to be compliant to standards such as PIX, PDQ, ATNA, and CT. The MPI solution should also comply with the CCD, NHIN, and CCHIT certification requirements/standards.
Please note that CCHIT currently does not offer HIE certification. They offer EHR certification that includes HIE components. Hence, it is imperative that the MPI system also closely work with the EHRs in order to facilitate certification.
It is also important to note that while complying with the standards, the solution should also have the capability to adapt to implementation idiosyncrasies arising due to subjective interpretations of the standards. HealthUnity MPI comes with a powerful xml based pre and post substitution tool that enables us to adapt to such differences without the need for going back to the vendor who implemented the system in the first place. This approach has helped us implement MPI solutions more quickly than otherwise possible.
Apart from the industry standards, an effective MPI solution needs to work with popular EHR vendors to ensure that they are compliant in timely manner. We believe that only HU can build such an ecosystem. We have successfully done so several times while implementing HealthUnity gateway for HealthVault and Amalga.
Interfaces that are offered with our solution
HealthUnity MPI comes with three different programming interfaces and two different user interfaces:
- Programmable Interfaces
- Standards based IHE interfaces – PIX and PDQ
- Standards based .NET Interfaces
- Standards based Web services Interfaces
- User Interfaces
- Web based administration and clinical user tools
- .NET based administration and clinical user tools
MPI support for programmable APIs
We expose .NET and WebServices APIs in addition to standards based APIs, specifically the 2010 version (latest) of PIX and PDQ.