The impact of inaccurate patient identification on a healthcare organization and its patients is wide-spread and significant. An inefficient master patient index results in duplicate and/or overlaid patient records. It can also result in inappropriate, delayed treatments, or other adverse events.
This, in turn, can create a life-threatening situation due to inaccurate medical records and clinical information at the point of care. An inefficient MPI also increases the workload for health information management and IT in terms of managing system integrity and creates a significant drain on financial resources.
Industry-wide estimates are that 5% to 20% of a hospital's records are duplicates. That rate increases to 40% or higher for organizations that have acquired and/or merged with other facilities or are part of an integrated delivery network. Each duplicate record carries direct costs ranging from $20 to identify and correct it to several hundred dollars in variable costs for repeated diagnostic tests when a patient's record cannot be located in a timely fashion.
Why an EMPI?
Multiple MPIs that are not linked across an enterprise can result in data being entered into multiple records for the same patient, with no ability to merge those records until post-discharge or sometimes not at all. This leads to inconsistencies and inaccuracies that impact care decisions. It can also affect the interoperability between and among a facility's information systems and those of its partners and affiliates.
These were the challenges Exempla Healthcare, which includes three hospitals and a network of clinics throughout the Denver metro area, was determined to overcome with the implementation of an enterprise master patient index.
In addition to the need to mitigate the risks created by an ineffective MPI, a primary driver of Exempla's push for EMPI was its migration to Epic. As part of that process, data would be aggregated from two MEDITECH systems and one Kaiser Permanente-hosted Epic system into a single Exempla-wide Epic system.
Exempla's objectives with its EMPI project were to:
A fourth goal was to reduce the cost Exempla was already incurring related to duplicate records. Estimates placed the duplicate volume for all three facilities at more than 17,000 records. Of those, an estimated 4.3% incurred additional clinical costs averaging $205.38 for repeated tests and treatment delays and incremental costs of $2.50 for additional registration times and $20.63 for correction. As a result, the total annual cost to the Exempla system for duplicate records was estimated at $554,000.
Industry reports have cited much higher clinical and treatment costs associated with unavailable historical medical information; in the neighborhood of 20% to 30%. This higher estimate would place Exempla's total annual cost in excess of $1.2 million.
Expectations were that the EMPI would reduce duplicate records by 70% after the first year. This would result in a return-on-investment within two years due to reduced costs in management of patient data, a reduction in the variable costs for duplicate tests, and elimination of on-going costs associated with resolving duplicate records.
Setting the Standards
Accomplishing these goals and objectives required Exempla to first determine whether an external EMPI was even necessary in light of the pending migration to Epic. They also needed to establish a clear understanding of key areas of weakness and set expectations for whatever EMPI solution was ultimately selected.
Recognizing that these critical tasks required a depth of experience and proven expertise that was not available in-house, Exempla engaged Just Associates, a consulting firm specializing in data integrity, to evaluate its strategic needs related to interoperability and an external EMPI. The firm was also charged with establishing a standard set of requirements to evaluate potential vendors.
This process started with a comprehensive data integration and patient identity data capture assessment to identify specific needs. Individuals involved in registration and scheduling were interviewed to gain a clear understanding of their work processes. Specifically, how pertinent information was collected from the patient, how that data was captured, how searches for existing patient records were conducted, and how that patient's identity was validated. Front-end search capability was evaluated in the registration and scheduling system with emphasis toward searching for records where multiple demographic data discrepancies might exist based on data being searched against what was stored in the database.
Next, back-end processes, namely the 200-plus system interfaces across which patient data was exchanged, were evaluated to ascertain how accurately the receiving system's record matching performed. Areas of potential risk were identified for each downstream system.