D190 Task 3 Database Quality Review Example

Three Duplicates, One Pair of Twins and Five Bad Fields: A Data Quality Review of a Composite Family Medicine Clinic's Patient Database Extract

Student Name

Leavitt School of Health, Western Governors University

D190: Introduction to Healthcare IT Systems, Task 3

Course Instructor

Month Day, Year

Three Duplicates, One Pair of Twins and Five Bad Fields: A Data Quality Review of a Composite Family Medicine Clinic's Patient Database Extract

The Extract Reviewed

Birchwood Family Medicine is a composite four-provider clinic that registers patients in its practice management system, which feeds the electronic health record. After a patient's allergy list was found split across two charts, the practice manager asked the health information management (HIM) department to review a sample extract of 14 patient records flagged by the system's weekly possible-duplicate report. Every name and number below is invented for this sample; only the last four digits of Social Security numbers (SSN) are shown.

Duplicate Records Identified

A duplicate record exists when one person has more than one medical record number (MRN). The review found three duplicate pairs. In each case the evidence rests on several independent identifiers matching, with the differences explained as entry errors.

Rows 1 and 2 (MRN 100231 and 104877). Date of birth, sex, SSN, address and phone all match. The last names differ by one letter, Hernandez and Hernandes, and one record carries a middle initial while the other spells out the middle name. The street is written Elm St in one and Elm Street in the other. These are spelling and formatting differences, not a different person. Misspellings were the leading cause of name mismatches in a multisite study of confirmed duplicates, which also found the middle name to be the field most often mismatched (Just et al., 2016).

Rows 3 and 4 (MRN 101560 and 105012). Date of birth, sex, SSN, address and phone match. The first and middle names are swapped: James Robert in one and Robert J in the other. The most likely explanation is that the patient goes by his middle name, and a registration clerk entered the name he gave rather than his legal first name. Swapped name fields are a recognized source of duplicates (Just et al., 2016).

Rows 5 and 6 (MRN 102788 and 106134). Name, sex, address and phone match. The dates of birth, 07/09/1990 and 09/07/1990, contain the same day and month in reverse order, which is typical of a date entered in day-month format by mistake. One record has a blank SSN, so the system could not use that field to connect them. Because every other identifier matches and the transposition explains the only conflict, these records almost certainly belong to one patient; the clinic should confirm the correct date of birth with the patient and her identification before merging.

A Pair That Must Not Be Merged

Rows 7 and 8 (MRN 103004 and 103005) share a last name, date of birth, sex, address and phone, and the possible-duplicate report flagged them with a high score. They are not duplicates. The first names, Emily and Emma, and the middle names are different, and the SSNs are different. These are twin sisters. Merging them would create an overlay, in which two people's information is combined in one record, which is more dangerous than a duplicate because one child's allergies, immunizations or results could be applied to the other. The records should be marked as not duplicates in the matching system, and a twin alert should be added to both charts so that staff check two identifiers at every encounter.

Other Data Errors

Five records contain errors that do not create duplicates but reduce the quality of the database and make future matching harder.

Row 9 has an impossible date of birth, February 30. Row 10 lists a Carver address with ZIP code 56999, while every other Carver record uses 56331, so the ZIP code or the city is wrong. Row 11 uses placeholder values, 0000 for the SSN and 000-000-0000 for the phone, which look like data but carry none and may cause the system to match unrelated patients who share the same placeholder. Row 12 gives a birth year of 1908, which would make the patient 118 years old; given his recent visits, 2008 or another year is more likely, and the error could affect age-based dosing and screening reminders. Row 13 has a blank sex field and a four-digit ZIP code, both of which the system should not have accepted.

Risks to the Clinic and Its Patients

Duplicate records split a patient's history. The allergy list that prompted this review is the clearest risk: a clinician who opens the incomplete chart may prescribe a drug the patient is allergic to. Duplicates also lead to repeated tests, missed results filed to the other chart, claim denials when insurance information differs between records, and privacy problems when records are released. Data errors weaken the matching tools that are meant to catch duplicates, so each bad field makes the next duplicate more likely.

Recommendations

Because every problem found in this review began at registration, prevention should start there. The clinic should require registration staff to search for an existing record using at least three identifiers, including partial and sound-alike name searches, before creating a new MRN. A standard naming policy should record the legal name from an identification document in the name fields and the name the patient uses in a separate preferred-name field, which would have prevented the Olson duplicate. Photo identification and insurance cards should be scanned at every new registration. An environmental scan of patient matching practices prepared for ONC, the federal office that coordinates health IT policy, pointed to the standardization of specific demographic fields, together with shared best practices for data quality, as ways to improve matching (Morris et al., 2014).

The system should validate fields as they are entered: reject impossible dates, check ZIP codes against city names, require the sex field and block placeholder values in SSN and phone fields, leaving them blank with a reason instead. Standardizing these attributes matters because matching algorithms depend on them; a study of 38 health care provider organizations found wide variation in how patient attributes are collected and formatted, and concluded that standardization can improve patient matching (Deng et al., 2023).

Finally, HIM should own an ongoing process. A data integrity specialist should work the possible-duplicate report weekly, merge confirmed duplicates only after two identifiers are verified with the patient or source documents, document decisions not to merge, and report the clinic's duplicate rate and the number of records corrected each month.

Conclusion

The 14-record extract contained three true duplicate pairs, one pair of twins wrongly flagged as a duplicate and five records with other data errors. Each problem can be traced to how information was entered, and each can be reduced through better registration practice, system validation and a steady HIM review process.

References

Deng, Y., Gleason, L. P., Culbertson, A., Chen, X., Bernstam, E. V., Cullen, T., Gouripeddi, R., Harle, C., Hesse, D. F., Kean, J., Lee, J., Magoc, T., Meeker, D., Ong, T., Pathak, J., Rosenman, M., Rusie, L. K., Shah, A. J., Shi, L., . . . Kho, A. (2023). Evolving availability and standardization of patient attributes for matching. Health Affairs Scholar, 1(4), qxad047. https://doi.org/10.1093/haschl/qxad047

Just, B. H., Marc, D., Munns, M., & Sandefer, R. (2016). Why patient matching is a challenge: Research on master patient index (MPI) data discrepancies in key identifying fields. Perspectives in Health Information Management, 13(Spring), 1e.

Morris, G., Farnum, G., Afzal, S., Robinson, C., Greene, J., & Coughlin, C. (2014). Patient identification and matching final report. Office of the National Coordinator for Health Information Technology. https://www.healthit.gov/sites/default/files/patient_identification_matching_final_report.pdf