Blogs Home
Wednesday, August 21, 2013 10:41 AM

Read this latest blog post to learn about Finding Duplicate Medical Records (Client/Server, MAGIC or 6.0).

Written by Joe Cocuzzo, Senior VP of Report Writing Services - iatricSystems

Recently, a user posting to Meditech-L was looking for a report that could compare patient records in MRI and find all cases where "different" patients have the same name, birth date, and social security number. This means that they have different unit numbers at the same facility, so MEDITECH would treat them as different patients even though they are very likely to be missed merges, and actually the same person.

This makes a good "NPR tip," showing how to use a macro as a program for selection, and the code is the same for the MAGIC, C/S or 6.x platform.

First, we build a simple MRI.PAT report with no index.

We sort by xx.name with a header and trailer. If we used a sort of @name, a middle initial or difference in case would separate our matches. Instead, we build a computed field that will keep our name matches in groups. The Z.convert.name program is used by MEDITECH in the MRI.PAT filer program to build the subscripts of the @actual.name.index.

To select our records, we use a computed select field "xx.ck" that calls a program:

In the program, we are going to loop on the "actual.name.index" to take the @name from the record we are checking and loop through all the name matches to see if the patient also matches on DOB and SSN, has not already been merged, and has a unit number.

We could have also used the social security index to find all patients with the same SSN, name, and DOB, but I thought that some sites might want to remove the SSN match criteria, and that makes the name index approach more flexible.

In MAGIC, the actual.name.index looks like this:

In Client/Server, it has some additional subscripts after urn, but our looping code can ignore this, as we only need to loop to the urn level. Therefore, the same macro code works in both C/S and MAGIC.

While we might have been able to squeeze our looping/matching into a computed field, using a program instead allows us unlimited "elbow room," and we can be sure we will not "step on" subscript values that the report is using. In a computed field, nilling or changing the value of a subscript that your report is looping on can cause your report to either end early or loop forever. In a macro written and called as a program, you have a separate set of local variables so this cannot happen.

Our macro looks like this:

For extra credit, we create a computed total field to count the number of matches like this:

Here is some test system output from a MAGIC site:

Here is some test system output from a 6.0 site:

Sample reports: MRI.PAT.zcus.is.find.dup.pts2 have been created for both MAGIC and C/S (or 6.x) systems and uploaded to the report library on our website.