EHR Conversions: Lessons Learned
Any time a project involves modifying a patient’s chart, inherent risk requires management. Electronic Health Record (EHR) conversions fall into that category and require experienced resources to manage and execute the plan in order to mitigate risks. As a project manager that has gone through several conversions, I have observed that there are commonalities across these projects. I would like to share some of my lessons learned in order to help you mitigate the risks to timeline, budget and resourcing for conversion projects. For this article I will refer to a conversion as migrating from a source EHR(currently using) to a target EHR (future system), which generally consist of converting allergies, medications, problems, immunizations, vitals, results and chart notes.
The first lesson learned is to set expectations with the providers after there is an analysis of the source EHR data. Add a feasibility phase to your plan and validate the data in the source EHR. Verify it contains all the data required by the target EHR . Analyze if the data in the current EHR is discrete or free text (free text generally requires additional resources to manually map data items), verify that the data contains a status (is it an active problem or is it past medical history), confirm that the data contains a clinically relevant date (when was the medication prescribed). This phase should answer three questions:
What clinical data items can be converted?
What will be the effort required to convert each data item?
What types of resources will this project require?
Another lesson learned is to define the implementation strategy from the source EHR to the target EHR upfront. This requires a detailed understanding of constraints, tolerance of staff and providers (are the providers/staff willing to navigate between two EHRs), other systems impacted by conversion (an EHR conversion requires a bulk load of patients into the new EHR). It is critical to determine if the clinical data elements will be split into a phased implementation or if all the clinical data items convert at once. For example, if there is a date constraint to meet a specific incentive program on the new EHR, a phased approach may be considered to first convert only the essential clinical data items required by the providers in the new EHR. Then move into a second phase to convert the remaining clinical data items. The goal is to determine the following:
Are there any time constraints?
Are the providers/staff willing to navigate between two EHRs?
Will there be a phased conversion plan or will all the data be converted at once?
Converting from one EHR to another requires resources that are subject matter experts (SME) on one or both systems. Once the project moves into the development phase SMEs are required to work with the conversion analyst to develop the logic used on each of the clinical data items. A
lessons learned from past projects on the importance of the SMEs comes from the level of expertise required for the project. Conversions require analysis of current and future EHR workflows and communicating them to conversion analyst to ensure the data is properly converted. For example, it is common for the two EHR systems to have different statuses for the same clinical data item and a map is required between the two. It is essential to make the determination on how to map these items and understand the impact to the workflow in the new EHR. You will need to ascertain the following:
Identify subject matter experts for both the source and target EHRs
Confirm subject matter experts are allocated to the project
Communicate the role of the subject matter experts
My last lesson learned is related to importance of creating a dedicated conversion environment. During the development phase, you will be required to validate the converted data. This will require a comparison of data between the source and target EHR’s. This can require hundreds, if not thousands of checks between the two systems. Each time there is a discrepancy an analysis must be performed to determine why the data was not converted as expected. If other systems or users (not assigned to the conversion project) are allowed to modify or update a patient’s chart, this will cause confusion and force hours to be spent on unnecessary analysis. Many hours will be saved by building a dedicated conversion environment. You will need to consider the following:
Hardware and software budget to build a dedicated development conversion environment
Allocate resources to build the dedicated environment
Allocate resources to maintain the dedicated environment
There are numerous lessons learned Project Navigation can share with your organization. We have many resources with experience managing and executing successful conversions. Please feel free to contact us to setup a free consultation to discuss your current or future conversion projects.