Hayes Review: December 2009

EHR Conversion Lessons

By Tom Maher and Laura Bloemer, RN, MSN

EHR conversions require a confirmation of clinical, technical and decision- making skills blended into a project management approach that constantly adjusts until the conversion design is built and validated through testing.

Conversions are different from system implementations due to the variety, complexity and the criticality of the data that needs to be moved from one structure (legacy system) to another structure (new system).

Data in an existing electronic medical record may not always translate ideally to the new EHR system. The most common reasons are the differences between data designs in the legacy and new system, and the variability in the collection of data due to user differences, etc.

Wherever possible, organizations want to take all of their data into the new EHR. However, there may be times when certain components of the clinical record will need to be populated in less than ideal manner or manually added to the record using abstraction.

Experience has taught us that certain elements of these conversions are predictable and repeatable while other elements are unique to the instance and will require a thorough testing process. There are many things to consider when performing a data conversion. Below are some tips we can share from our years of experience with healthcare data conversion projects. They are associated with a migration to EpicCare Ambulatory, but we have found them to be true for other systems as well.

Tips for data conversions:

Planning

• Getting started too late on planning and executing build is probably the single most frequent cause for conversion delays and resulting go-live delays.
• Major system build and data display decisions should be accomplished before conversion planning can occur. As a result, system build must start and finish months earlier than it would if no conversion were to take place.
• A thorough clinical and technical discovery analysis prior to finalizing conversion design is necessary to uncover systemic data content issues and possible limitations of conversion software tools.
• A data conversion rollout is less ominous than a big bang cut-over in terms of training and support. However, a rollout will require building in an additional phase – converting new clinical data in real time from the legacy EHR to the new system.
• Some legacy systems have allowed unrestricted free text overrides to an item designed as a pick list. In these cases, any mapping process between the two systems may be expanded exponentially. Free text is not a primary option in many EHR systems.  Spelling and minor grammatical differences and errors can account for a 90% increase in mapping work. It’s important to factor instances of free-text usage into your data mapping plan, because the impact can be significant.
• Sometimes a change can be minimal in actual build time, but the process time can be significant and add time that is not accommodated in the plan. Understand an organization’s process for making change in any “build” item.
• Precise volume estimates are very important for planning your testing and your live conversions. It’s also important to consider that some conversion loads are prerequisites to other loads – therefore, some instances require that the plan include calculating concurrent as well as prerequisite loads.
• The implementation of permanent interfaces needs to be planned in conjunction with the conversion, as conversions must send all transactions right up to the instant when the permanent interface takes over so that no transactions fall through the cracks.
• There are many application design decisions that need to be finalized in advance of the conversion design. Clinical content conversions cannot be designed until you have made decisions with physician input regarding the chart presentation. Answers to such questions as ‘What tabs will appear in your chart review section? Which documents file to which tabs? What is the design of the print groups that display the clinical documents?’ all need to be answered. Clinical content will typically be a large number of conversion feeds. The final design must demonstrate how the clinical content is extracted from the legacy system and depict the number of interfaces needed.

Mapping and matching

• Any legacy EHR that is not encounter-centric stores data related to a single patient visit as multiple separate clinical entries.  When the data is loaded to the new system that is encounter centered, it’s necessary to tie these fragmented pieces of documentation together using “encounter matching” logic. Typically, this matching is performed using either a visit ID or the Provider and Date.  The design also needs to accommodate the creation of new encounters when a match is not found.
• Targeted portions of the build must be complete in order for the mapping to proceed. Data mapping for things like Medications, Allergies, Procedures (especially labs) are always very complex.  Particularly when ambulatory and inpatient are combined in the same facility, other design aspects that affect both areas like encounter types and document types can get bogged down in broader design discussions.
• Decisions on the type of load to perform and the detailed specifications will need to be created as part of your technical conversion design.

Converting

• If your organization wants to convert patient data beyond basic demographics (Insurance, Guarantor, Employer, Family, Other), you will need to use a Bridges ADT interface configured to meet your needs.
• In Epic Systems software, for example, everything gets linked to an encounter. So, if documentation being loaded doesn’t get a hit during encounter matching, a new encounter is created.  During the clinical conversion, historical data from certain document types will be mapped to create specific encounters. For instance, a phone encounter will not attempt to perform encounter matching and will create a new phone encounter.
• Your organization could decide to convert all content from the legacy system, or you could be selective. For example, you may decide you only need to convert patients and documents covering encounters from the last three years. This decision will be influenced by whether the legacy system will remain available to query or if the new system must be the legal “medical record.”
• Your organization could decide that specific transactions will not convert effectively and choose to use manual abstraction to complete that portion of the chart.

Testing

• The testing process needs to be flexible enough to accommodate late design adjustments that are driven by random data usage patterns (discovered throughout testing).
• Disk space consumption can vary significantly depending on the system logging activities that are performed during your loads. Make sure you test with the same settings that will be turned on during your production loads or your load time estimates may be inaccurate or even worse, you may overrun available disk allotments in your production system. This could lead to a production service outage during your production conversion loads.
• Testing begins simply and with very low volumes and should continue until end to end tests are performed with full volume conversion loads. Since we like to include Quality Assurance (QA) as part of our testing, we also recommend some design walkthroughs with key user groups to make sure to decrease or eliminate any design flaws that could be related to misunderstood communications.

For more information about data conversions, sign up for our white paper, “What you need to know about your data conversion to EpicCare.” It is being written now and will be available in early January.

Tom Maher, Senior Healthcare Consultant at Hayes, has 35 years of healthcare experience and is an expert on data conversion for hospitals and physician practices. He recently managed the conversion of 38 million patient records for nearly a million patients from legacy EHR systems to the EpicCare Ambulatory EMR.

Laura Bloemer, RN, MSN is a Senior Healthcare Consultant at Hayes with more than 30 years of experience in healthcare information technology implementation and optimization. She is EpicCare Certified and assists clients with implementations and meaningful use reporting.