Consolidations and Your Master Patient Index
Last time we took a look at how duplicates can occur at your site. This time lets take a look at the effect of a consolidation on your MPI. Remember from last time we said that there is a unique record number that exists in a MPI database, which no one sees. Always, there SHOULD only be one URN per patient. With each URN there can be multiple “Other Numbers”. That’s OK. These “other numbers” are usually unit numbers that the patient has at different facilities. If we have multiple URN’s per patient (not multiple “other numbers”) we have duplicates (and no matter how good you are you will have some duplicates).
Lets say that we register a patient as a duplicate. We realize our mistake and fix it by merging one patient into the other. Does the URN of the merged record go away? No, it does not. What happens is a special field, called the “merged.to” field, gets set to the URN of the record that it is should be. Whenever a user attempts to use the merged record, the “merged.to” field is checked to see if it has a value. If it does the MEDITECH system will jump automatically to the URN listed in the “merged.to” field. The duplicate URN is only used to point to the proper URN.
In a MEDITECH clinical consolidation we have separate MPI databases that must be merged together. A governing body will sanction that hospitals A, B, C and D are to become one. Each of these hospitals has its own MPI. The first step in consolidating or creating the MPI of the new entity is to clean up all of the duplicates in each of the separate distinct sites. A MPI clean up is done in hospital A, B, C and D. When each is clean of duplicates, the unique records are loaded into the new entity (This usually involves NPR Report data downloads and uploading automated by VB Scripting). This creates a multitude of duplicates in the new database. So a cleanup is then done on the MPI in the new entity, to merge the duplicates from each of the separate hospitals into the one entry in the new hospital or entity. In this way all of the information from the separate hospitals is moved to the new hospital and then matched with possible entries from the other hospitals. This lets us determine which hospital has the newer or more appropriate information for the person. The best information is identified and all separate records are merged into the newer/best record.
In identifying merges, different hospitals will use different criteria for selecting potential duplicate records. The following link has a NPR Report that you can run on your MEDITECH database to determine the number of potential duplicates at your site (www.meditrain.com/products/ams.html). This query finds duplicates based on “exact healthcare number” and “exact date of birth”. (If your healthcare number does not uniquely identify a person then this query will have to be modified. If you are unable to modify the report e-mail me your Health Care Number specification and I will modify it for you. Too, if you are Client Server let me know and I’ll modify it for C/S). Download the query and run it at your site to see how many duplicates you have. Your IT department may have to help you do this. You’ll be surprised with the results. Notice that it lists the detail for the first 25 duplicates.
This link also contains past articles written on this topic. Enjoy.
Next time I will discuss “How MEDITECH Presents Duplicate Records”.