June 2015

Switching EHRs? Get the Data Conversion Correct
By Todd Frech, MLT
For The Record
Vol. 27 No. 6 P. 30

Dissatisfaction is rampant among EHR buyers. In fact, according to reports issued by IT research firms Software Advice and KLAS, 40% of physician offices and 50% of large hospitals have changed or are in the process of changing EHR vendors. With the selection of a new EHR comes the need for a systematically performed, rigorously tested data conversion. When done correctly, a data conversion preserves the structure of patient records, including all the information necessary to track drug interactions, perform allergy checks, and otherwise ensure the delivery of safe and efficient care. Data conversion, which requires a significant time allocation, should account for a substantial part of any EHR switch. Start the process early and make sure it's completed well before the go-live date.

There likely will be two different costs to convert data from one system to another. The current vendor will extract data and drop them into a format that works for the new vendor. Typically, this service is costly; it is, after all, the vendor's last opportunity to derive revenue from the client.

The process requires cooperation between vendors. Given the potential for revealing proprietary information, the new vendor will not want to access the previous system to extract the data. Conversely, the original vendor will not permit a competitor to access their inner workings. As a result, the new vendor will write programs to import the necessary data. This is where the organization will be charged a second time.

Data Conversion Types
Data element conversions take individual information items—first name, last name, address, known allergies, etc—and insert them into the appropriate fields in the new database. In cases where a full data element conversion is possible, the converted records appear as data collected by the native application. However, given that no two systems store data the same, full data element conversions rarely are possible without significant compromises. Typically, some or most data are converted, while other items are summarized.

In a record summary conversion, the history data contained in each record are synopsized and loaded into the new system as a static document. Because there aren't individual data elements that can be accessed and used for reports, alerts, or interactions with live data, this method isn't as useful as a data element conversion. Instead, there is a single long-form summary of the patient's history.

A conversion may combine the data element and summary approaches. This usually occurs with formatted documents such as physician and nursing notes or other narratives. The patient demographics may be converted data element by data element, with the notes summarized in a single database field. This also occurs when the receiving system does not have corresponding fields for all of the converted data. Since they are stored in one field and don't allow for the same flexibility and utility seen in a more granular data structure, the summarized data become less useful.

Paper conversions, in which paper medical records are manually transcribed to electronic records, are the most difficult. The information must be extracted by a health care professional, so that important data such as diagnosis codes, problem lists, medication lists, and allergies can be keyed into the receiving system. The conversion is likely to be limited to the most critical data elements required for good patient care; otherwise, the process takes far longer and costs much more than is practical. Occasionally, certain items in the paper record, such as physician notes, can be scanned and stored as static images, which can be read and reviewed but not modified.

Conversion Steps
In most cases, the conversion process begins when the new vendor supplies a data format specification, which defines the data to be converted, the conversion file's format, and the characteristics of the individual data elements. For example, a specification may state that the last name field must contain only alphanumeric characters, not exceed 50 characters in length, and be the first field of each record in the conversion file.

Since no two systems are alike, some fields may need to be mapped, altered, or augmented. For example, one system may have gender stored in the database as M, F, and O, while the other system defines it as Male, Female, and Unknown. Review the specification carefully to make sure all data elements are represented. This reconciliation step is important to ensure nothing is omitted.

The old vendor will extract a data sample from its system, format it according to specification, and provide it to the new vendor in a test file. Ideally, this test file will contain a variety of data from different years and in different formats, including all data types and examples of each patient type. If a system has been modified over the course of its life, knowing what changed and when ensures there are prime examples of these changes in the conversion test files. (If these changes have not been tracked, start doing so once the new system is installed and operational.) Once the test files are generated, they are passed on to the new vendor, which reviews for formatting consistency and either imports the data or, if corrections are needed, requests changes and another test file.

Once the format is accepted, the data are imported into a test system for review, an important step in that these converted data will be used to deliver patient care. In many cases, problems discovered after the final conversion are unable to be corrected.

Get Confirmation
Validating the test data is time-consuming and should be accounted for in a system implementation timeframe. Optimally, all data are reviewed for consistency and accuracy, but in reality there's not enough time and resources to validate tens of thousands of records. However, the following steps can help organizations make the most of the validation process without spending an inordinate amount of time on the process:

• Carefully review patient demographic data. To be able to match records in the system, this information must be correct.

• Validate that the sample data contain examples of all data types, including records from each year to be converted that represent all patient types.

• Don't stop if an error is detected. Instead, check the entire sample data set and report all problems. This limits the number of test files that must be generated and loaded. Most vendors will limit the number of test files they generate or load. Additional test files will likely incur additional charges.

Press Play
Once the test file is clean and correct, the data conversion can begin. Depending on the amount of data being converted, the process can take several weeks to complete. To ensure new errors don't crop up, continue to review the data. Various professional organizations may offer guidance on how many data should be reviewed and what records should be retained for reference during accreditation inspections. In general, plan to validate at least 15% of previously converted records and 10% of all other records. In the case of critical elements such as blood type, allergies, and medications, more data should be checked. When possible, data should be reviewed by the staff members who will be using them.

Sometimes it is necessary to convert files from multiple systems into one system. For example, an organization may be combining physician orders, transcribed reports, laboratory data, and pharmacy data into a new EHR system. It may elect to modify or delete data—Social Security numbers, for example—that are no longer being used. Such factors complicate the conversion.

Good technical management, which requires a detailed review of the converted data, is critical. Organizations that choose to change the data contained in the conversion must consider the legal ramifications. In these cases, it's best to consult with an experienced attorney before any modifications are made.

Match Points
Patient matching is the process of combining multiple records into one. Duplicate records can be created when there are poor procedures for creating new patient records or assigning medical record numbers. They also may occur during the merger of two or more databases, eg, when two facilities merge and combine separate systems or when multiple applications are directed into a new single application.

This can be the most technically demanding part of the data conversion process. Serious patient care errors can be made when a patient has multiple individual records, each containing only part of the medical record, or when information is merged incorrectly. When importing data into a database that already contains patient data, the matching algorithms must be even better. Many systems offer a utility that uses demographics such as first name, middle initial, surname, gender, and date of birth to identify patients with multiple records in the system. Other unique identifiers, such as medical record numbers, also may be used.

Depending on how controlled the process of creating a new patient record or medical record number has been, there may be multiple record numbers for a given patient. If that's the case, the medical record number is a poor choice for matching. Ideally, this clean-up will be done in the old system prior to any conversion, but it also can be performed as part of the conversion process.

Given the long history of some systems, data already may have been converted multiple times. This happens frequently in the laboratory information management market where systems have been changed or upgraded several times. Conversions that inherit the sins of the past are frequently more complex and riskier. In such cases, the data validation step must be more robust to ensure that the data are properly synced and errors in the historical data do not get converted into the new system.

Data conversion is not a task organizations should skip or leave to vendors. It's important to monitor the process to ensure it meets requirements and results in a fully functional system that doesn't pose a risk to patients on the go-live date. Careful planning, adequate quality assurance staff, and sound data conversion specification can make that a reality.

— Todd Frech, MLT, is a senior partner at Ocius Medical Informatics.