Overcoming Challenges of Merging Multiple Patient Identification and Matching Systems: A Case Study

[Editor’s Note: This paper was originally published in the Winter 2020 issue of Perspectives in Health Information Management. It is been reproduced in its entirety here, with the authors’ permission.]

Abstract

Northeast Alabama Regional Medical Center (RMC) in Anniston, Alabama purchased a smaller hospital in 2017. Staff at the two hospitals were tasked with merging the two Electronic Medical Record (EMR) systems into one unified system. From the outset, there were two systems with different medical record number specifications and patient identification systems as well as two different patient name parameters. The merging of these records and systems meant dealing with different vendor EMR systems and ancillary systems to produce a single unified record within RMC’s EMR and the document imaging system that housed the legal medical record for each patient.

This case study describes the process and procedures of merging the patient records from both hospitals to create one Enterprise Master Patient Index (EMPI); and the collaboration between the Health Information Management and Information Technology departments to accomplish this goal.  It also reviews the impact and challenges related to the system’s development, as well as lessons learned while completing the project.

Keywords: medical records systems, computerized/organization & administration, patient identification systems/standards, duplicated medical records

Introduction

Healthcare delivery has changed and increased in pace especially in the past three decades to include merging and acquisition of other healthcare organizations.¹ Mergers and acquisitions benefits integration of care, decreases duplication of clinical services, fosters clinical standardization to reduce cost for operating expenses and improves overall quality.^{2, 3} As more hospital systems purchase external clinics, physician practices and hospitals, the goal should be to have all operations using one medical record system to ensure quality of care is consistent among all providers and information is accessible by all entities within the system serving the patient. Patient identification and duplicated medical records are always challenges and are major issues to be resolved when merging medical record systems.

The challenges in hospital mergers and acquisitions involve multiple functions of the facilities, health information technology being one of the most challenging components.⁴ Other impacted areas, such as financial and accounting systems, purchasing and supply systems, pharmacy, radiology, laboratory and human resources systems require active reconciliation.^4,5 Healthcare informatics is the field of information science concerned with the management of all traits of health data and information through the application of computers and computer technologies.  Increased technology, such as advanced Enterprise Master Patient Index (EMPI), algorithms, radio frequency identification and smart cards, are major tools in solving duplicate medical records and patient identification matching issues.^{6, 7} Because of the current culture of mergers in the overall health care system, it is highly likely that a Health Information Management (HIM) Director or Manager, will be required to be responsible for making decisions on how to accomplish a unified medical record and an EMPI.⁶  A strong, collaborative and capable leadership team is the key for a project to be successful in merging and implementation of a new system within healthcare organizations.⁸

This case study describes the collaborative efforts between HIM and Information Technology (IT) as a very specialized team, their accomplishment of creating an Enterprise Medical Record System, the processes of the system’s development and steps involved in the merging process. It also reviews the impact and challenges related to the system’s development. Lastly, several lessons learned and recommendations for merging medical record systems and the alliance of HIM and IT collaboration works are discussed.

Methods

Project Scope

The purchasing hospital, Northeast Alabama Regional Medical Center (RMC)⁹ serves a five-county area as the region’s leading healthcare provider in northeast Alabama. The hospital that was purchased (Purchased Hospital) is in the same city as RMC. Statistically about 90% of the local physicians are on staff at both hospitals. The purchase was intended to align the delivery of healthcare in the region and reduce waste and duplication of limited healthcare resources.

As part of the acquisition, RMC was required to disconnect the Purchased Hospital from its legacy Electronic Medical Record (EMR) within 14 months of the purchase date. Dozens of systems had to be migrated in the 14-month timeframe, with the largest and most complex of these being the EMR and storage system for the legal medical record. RMC’s EMR is Allscripts Paragon, a single integrated system that allows both physicians and clinical staff to document, order and review patient information. The EMR transfers the data into OneContent, a Hyland Product, which is the document imaging storage system where the legal medical record is located. The Purchased Hospital’s EMR was a group of systems proprietary to the previous owner that provided the EMR functions for physicians and nurses. The Purchased Hospital used McKesson’s Horizon Patient Folder (HPF), an earlier software version of OneContent, for the document imaging storage system. RMC’s challenge was to convert and implement Paragon (and other key systems) at the Purchased Hospital for all EMR activities such as clinical functions, billing, General Ledger (GL)/Accounts Payable (AP), charge master and materials management.

RMC had decreased the clinical paper documentation to 30% since implementation in 2013 and only uses paper documentation in some outpatient areas. One goal would be to standardize the documents and continue decreasing paper at both hospitals. This was a large adjustment to the Purchased Hospital’s processes which would require RMC to educate and train all clinical disciplines how to document in Paragon. Since 90% of the physicians were using Paragon at RMC, the responsibility for physicians only included training 10% of the medical staff.

There was a total of 709,528 medical records in both systems with a potential 50% to 60% overlap which meant the patient had been at both facilities. This data was provided by an algorithm report that RMC contracted a vendor to provide RMC.  The first algorithm report showed that we would need to create an estimated 60,000 new medical record numbers for patients that were not in the RMC’s Master Patient Index (MPI). The goal was to decrease that by matching more of the patients by investigating each case to ensure the patient truly was not in RMC’s MPI. RMC’s Paragon had a total 482,528 medical records with a potential duplication rate of less than 2%. The medical record numbers were 6-digits (123456) and the account numbers were 10-digits (1234567890). The Purchased Hospital had 227,000 medical records with an 8% potential duplication rate. The medical record number was a 10-digits number which had 4 leading zeros (0000123456) and the account numbers had 7-digits (1234567). Table 1 illustrates the basic comparison of characteristics of medical record systems from RMC and the Purchased Hospital.

Project Goals

The primary goals of the project include:

1. Assess the feasibility, compatibility of the systems, and determine the scope of the project.
2. Design an electronic system that would merge and store all the medical records and administrative data from both hospitals.
3. Identify all potential duplicates in medical records, and upon verification, merge in the hospital information system.
4. Develop a team to ensure that any downstream systems that operate using a medical record as identification are updated or changed at the same time.
5. To create a new medical record number with all the patient’s visits from the Purchased Hospital’s system into RMC Paragon and OneContent. An example would include radiology films must match your EMPI.
6. Migrate all patient medical record documents stored in HPF into OneContent under the correct patient medical record number.

Definitions

• Person: Any individual contained within the Paragon database. A person can be a patient, physician, employee, guarantor, etc.
• Patient: A person within the Paragon database who has been registered for at least one visit. All patients are persons within Paragon, but not all persons are patients.
• Potential Duplicate: A patient identified as having two or more medical record numbers.

Project Phases and Timelines

This project consisted of three phases. It started from Phase I Analysis and Design in May 2017 and ended in Phase III Go Live in July 2018 (see Table 2).

Results

Project Procedures

In order to carry on the merging of duplicated records, a three-step process should be followed: identification, verification, and merging.

Step 1: Identification

1. Identification of potential duplicates is ascertained through daily monitoring of the Possible Duplicate Persons report housed in the Paragon Medical Records Reports Module and communication from hospital personnel who identify potential duplicates through the course of their job duties.
2. Printing the Possible Duplicate Persons report. Research the entries to confirm whether valid duplicate medical record numbers exist (see Figure 1).
3. Notifications regarding potential duplicates that are received via the Medical Record Number Correction form, e-mail, telephone call, etc. will be processed according to this policy and procedure.

Step 2: Verification

1. In order for the potential duplicates to be considered a 100% match all the following criteria MUST match:

a.) Date of Birth

b.) Social Security Number

c.) First Name

d.) Last Name

2. Access Abstract Maintenance in Paragon Medical Records to verify the information. Compare the print outs. If all items listed in #1 match for both persons, the merge process can begin. Otherwise, continue verification process.
3. Verify Social Security Number at OneSource. If social security verification determines person is not a duplicate, stop here and do not merge (see Figure 2).
4. Verify insurance using Paragon Patient Management and OneSource. Determine patient’s insurance type through Paragon Patient Management. Use OneContent to compare information such as insurance cards, signatures. Global documents will include information such as insurance cards, and driver’s license which can be used to verify patient’s identity (see Figure 3).

Step 3: Merging

Merging has two conditions:

a.) Merging when all medical record numbers are attached to a visit;

b.) Merging when one or more medical record numbers are not attached to a visit.

1. When determining which medical record number to retain, check to see if any of the medical record numbers have an active account. The merge cannot be completed until the account(s) have been discharged and are no longer active. Typically, the medical record number with the most visits will be retained. If the medical record numbers being merged have an equal number of visits, retain the medical record number with the most recent account.
2. After determining which medical number will be retained, review the demographic sheet print out and ensure the following data elements match the medical record number with the most current visit. The elements in bold must match for Paragon to allow the merge.

a.) Date of birth

b.) Sex

c.) Race

d.) Social Security number (enter 9 zeros for all medical records not being retained)

e.) Ethnicity

f.) Marital status

g.) Religion

h.) Preferred language

i.) Privacy note date

j.) Advance directive

The Key Tasks and Accomplishments in Each Phase

Phase I. Analysis and Design (May 2017-September 2017)

1. Assigned leadership responsibilities to the Director of Health Information Services (HIS) from RMC (with 33 years’ experience in HIM) to work with Chief Information Officer (CIO) (with 25 years hospital IT experience and system implementation) to have oversight for the project. Due to the nature of the project, it required both HIM and IT skill sets to accomplish this major project.
2. After assessing the systems at both hospitals, the team decided on the best approach to combine the disparate data sets. EMPI teams were formed to compare and review the data for accuracy for the overlay patients, duplicate patients and the patients that had not been to RMC. This team would determine which patients would need to be assigned a new medical record number. To correct each duplicate record, it was estimated that the length of time to take 38 minutes per record. Each person on the team could potentially fix 10 to 15 records per day.
3. Conducted an investigation to determine if new medical records would need to be created for all 60,000 patients. The investigation was needed due to discrepancies in the data fields such as different last names, dates of birth, unknown sex and social security numbers being off by one digit. It was estimated to take approximately 1 to 2 hours to complete the needed investigation work per patient record. This estimate included the time it took to switch and compare data between two systems. This goal was critical to patient safety to ensure a complete medical record was being implemented. Contracted with one HIM vendor to assist in doing the investigations for three months due to of the amount of time it would take to investigate each case.
4. Analyzed how the mapping would occur for the documents, bar codes and images from the Purchased Hospital’s HPF system into RMC’s OneContent system. The team made the decision to use RMC’s naming convention since RMC was the larger database and was built with more complicated workflows. An example of naming conventions would include a document name in the Legacy System such as Consent for Treatment and in OneContent that document name would be listed as Adm Consent Treatment. The team had to ensure that all documents would be stored properly for the legal medical record. Table 3 illustrates examples of documentation names.
5. Created an EMPI in Paragon and OneContent. Both hospitals would require training on how to locate the patient and medical record. Screen shots were developed for purpose of training the staff.
6. Set-up a messaging system to alert when there is a change in medical record numbers to downstream systems, such as laboratory radiology, cardiology, Tumor Registry and the patient portal, where the EMPI in the systems could be updated immediately.
7. Mapped financial data, such as patient types, payer codes, insurance, financial class and account types.
8. Developed training manuals and procedures by both HIM and IT teams. For protection of patient safety and data integrity, every staff member is responsible in following the procedures.

Phase Two: Action Steps (October 2017-July 2018)

1. Established a subset of EMPI data including medical record number, Social Security number, last name, first name, middle name, DOB, address, age and sometimes maiden name from both hospital systems. Determined which data subset contained the latest demographic data for each patient. These data subsets were used with a scripting tool to verify the data comparisons to the first algorithm report.
2. Merged all confirmed duplicate medical records in the live systems. The goal was to decrease the number of duplicate medical records before the systems Go Live.
3. Identified if a patient needed a new medical record number in RMC’s EMPI or if we needed to merge the patient’s medical records between the two hospitals. These reports were worked and saved weekly.
4. Weekly reports were run by Paragon and OneContent representatives to measure how many patients were left to match. The patients’ data were updated in the test system weekly and would be pulled from test into the live system on July 30, 2018.
5. Created a medical record process for new patients being registered in the hospital to allow automatically and systematically assigned medical record numbers.
6. Tested the amount of time it would take to move the medical records numbers, account numbers and documents with the images from the Purchased Hospital into Paragon and OneContent. These tests assisted with estimation of the required downtime during the Go Live conversion.
7. Determined how incorporating the Purchased Hospital into one system would affect the patient portals with an immediate HL7 feed at both facilities.
8. Consolidated statistical data or reports for financial, quality, state or federal reporting by multiple teams including Administration, IT and HIM. Formatted documentation forms with barcodes. Tested the amount of time that it took to move the actual document images. Mapped patient index files that required by Centers for Medicare and Medicaid Services (CMS) and The Joint Commission (TJC) to be permanent from both hospitals.
9. Provided screen shots to identify and teach all the staff on both campuses on the EMPI and how the new set-up will look.
10. Evaluated medical records from both hospitals for matching the Purchased Hospital’s 10-digit registration system. Many tests were required as this feature caused the hospital to have false data on the patient algorithm reports. Many of the 60,000 were actual one to one matches once the data was reviewed for 11-character names such as Christopher.
11. Matched EMPI number and medical record number in Paragon and OneContent. The team verified admission and discharge dates and times were correct for RMC and the Purchased Hospital.
12. Set-up Go Live date and time as July 30, 2018, at 7:00 am. All systems at Purchased Hospital were taken offline on July 27, 2018 at 5:00 a.m. and would begin manual downtime processes. Registration tracked all patients that were in-house at downtime and any other patients that were treated at the hospitals.
13. Uploaded verified data into the live system starting around 11:00 p.m. on July 29, 2018. During this time, IT pulled new reports and sent this to the team to analyze the data to ensure the data was uploaded correctly in the live system.

Phase III. Go Live (July 30, 2018)

1. Activated entire hospital system. All systems were brought on-line at 7:00 a.m. The EMPI team continued to verify the data and documents had uploaded correctly in the live systems. The Business office registered all the patients that had presented to the Purchased Hospital from July 27, 2018, 7:00 a.m. until Go Live on July 30, 2018 at 7:00 a.m.
2. A swat team of IT and clinical staff was maintained at the Purchased Hospital to support all hospital staff after Go Live. This team was stationed there for several weeks to ensure quick assistance and issue resolution.
3. Monitored all patient census coming into the system during the downtime.
4. Monitored and tested for any type of errors that may have been loaded in all systems for one month after Go Live. For example, patient portal reports were built to ensure that the correct patient’s information was automatically being sent to the portal.
5. Assigned one employee to report the census and another to work on any new duplicate medical records created after Go Live for both facilities from Paragon.

Discussion

When approaching a project such as this one it is essential to have an effective leadership team from both HIM and IT for a successful project.  The MPI is the foundation base for all EMRs and it is critical that the information is accurate.  Our key points on lessons learned and recommendations during the conversion include involve the right staff, clean up MPI, know the workflows, consolidate systems, interface to automate, and source of truth.

Involve the Right Staff

Involve all the key players from both facilities.  It is very important to ensure all key areas are represented while planning and working through the conversion process.  This should include not only HIM and IT but areas such as registration, scheduling and the business office.  These areas work with the patient accounts daily with very different functions that involve data being represented in the EMPI and patient accounts. Be prepared to commit to weekly or bi-weekly communication either by conference calls or video between all members. It is believed that this communication saved the hospital from many issues on the constant updating of data and meeting the goals.

Clean Up that EMPI

If your IT system has the ability to run an analytical report on both the current and the newly purchased systems this must be your first step. If not, we suggest purchasing an algorithm report. That will be your base to determine the amount of time needed and what type of work will need to be performed. Do as much cleanup work on the EMPI as possible before you begin to merge any data.  The more time spent identifying duplicate persons, missing data elements and cleansing data the better.  In our situation we had a large percentage of overlapping patients that had accounts at both hospitals.  This proved to be very challenging and required a lot of manual data verification to ensure the right accounts would be merged, and new accounts created when necessary.

Know the Workflows

It is critical to understand the workflows and the culture of the other organization.  This is a lesson we learned quickly.  While a workflow may work fine at one facility it may need to be tweaked to work just a little differently at the other facility.  Standardizing workflows and processes should be a goal but be flexible when needed.  Look at all options and possibilities.  Keeping in mind the way you are currently performing a process may not actually be the most efficient way to start with.  Just because it’s always been done that way does not mean it’s the right or best way.

Consolidate Systems

Consolidate systems when possible, as it is much easier to manage and support.  This holds true for not just clinical applications but any system being used at both facilities.  During our conversion the goal was to ensure both hospitals were using the same systems both clinical and non-clinical across the board.  This helps with staff orientation, training and when staff may float between hospitals. A good example of this is the policies and procedures that are attached to your workflows or documentation.

Interface to Automate

Interface to eliminate manual processes.  Interfaces are the backbone of healthcare applications allowing different systems to pass information back and forth.  Interfaces can save hundreds of man hours and ensure data is available in real-time.  Ensure you have a robust Interface Engine in place that can handle the multiple interface loads as well as being able to customize interfaces as needed.  And always remember a standard admission, discharge, transfer (ADT) interface is never “standard”.

Source of Truth

With so many different computer systems sharing data within a healthcare environment, it is critical that there be a single source of truth (SSOT) for EMPI data.  This SSOT is the master key to all EMPI related data.  All downstream systems will receive data from the SSOT provider, and that data should be considered golden.  Any and all changes to EMPI data should be made at the SSOT point.

Conclusion

Patient matching continues to be a challenge for hospitals and health information exchanges. This situation increases the hospital expenses and endangers the integrity of the patient medical records. A solution to ensure that patient data can be matched correctly is needed whether that is a national unique patient identification or allowing the private sector to help solve the problem. With increased technology and informatics, patient identification and matching issues can be resolved effectively and efficiently. This must be one of our nation’s priorities. A collaborative team between HIM and IT and a strong leadership are the key for a successful project in merging medical record systems.

Acknowledgment

The authors would like to thank everyone that worked with the team so closely in making this project such a success! Likewise, much appreciation also goes to the IT and HIM Departments along with the vendors, Allscripts and Hyland.

Donna Crew, RHIA (dcrew@rmccares.org) is Director of HIS/Privacy Officer, the Health Care Authority of the City of Anniston, Anniston, AL.

Pete Furlow (pfurlow@rmccares.org) is Chief Information Officer, the Health Care Authority of the City of Anniston, Anniston, AL.

Shannon H. Houser, PhD, MPH, RHIA, FAHIMA (shouser@uab.edu) is Professor, Department of Health Services Administration, the University of Alabama at Birmingham, Birmingham, AL.

References

1. Beaulieu ND, Dafny LS, Landon BE, Dalton JB, Kuye I, McWilliams JM. Changes in Quality of Care after Hospital Mergers and Acquisitions. The New England Journal of Medicine. 2020;382:51-9. DOI: 10.1056/NEJMsa1901383
2. Schmitt M. Do hospital mergers reduce costs?”Journal of Health Economics. 2017;52:74-94. https://doi.org/10.1016/j.jhealeco.2017.01.007
3. Noether MS. Hospital Merger Benefits: Views from Hospital Leaders and Econometric Analysis. Charles River Associates. 2017. Available at http://www.crai.com/sites/default/files/publications/Hospital-Merger-Full-Report-_FINAL-1.pdf
4. Lohrkea FT, Frownfelter-Lohrkea C, Ketchen DJ Jr. The role of information technology systems in the performance of mergers and acquisitions. Business Horizons. 2016;59(1):7-12. https://doi.org/10.1016/j.bushor.2015.09.006
5. Minich-Pourshadi K. Challenges in Hospital Mergers and Acquisitions. Health Leaders Intelligence. 2010. Available at http://content.hcpro.com/pdf/content/259008.pdf
6. Harris S, Houser SH. Double Trouble—Using Health Informatics to Tackle Duplicate Medical Record Issues. Journal of AHIMA. 2018;89(8): 20–23.
7. Steininger K, Kempinger B, Schiffer S, Pomberger G. A Process Model for IT Migrations in the Context of a Hospital Merger - Results From an Austrian Case Study. Studies of Health Technology Informatics. 2016;223:182-90.
8. Walker AR. “Case Study: Leading Change across Two Sites: Introduction of a New Documentation System.” Nursing Leadership. 2006;19(4): 34-40. doi:10.12927/cjnl.2006.18598
9. Reference: RMC Health System. “About Us.” Available at https://rmccares.org/about/

Table 1. Basic Comparisons of Medical Record Systems between RMC and the Purchased Hospital

Table 2. Phases and Timelines

Table 3. Examples of Document Names in Legacy System and OneContent

Figure 1. Screen Shot of Identification Procedure

Figure 2. Screen Shot of Verification Procedure

Figure 3. Screen Shot of Verification Procedure