Project Navigation Blog 10 key steps when converting Electronic Health Records (EHR)

Converting EHRs due to merger and acquisition or software vendor transitions are increasing in frequency and complexity. Hospitals and physician practices are expanding their market share to leverage buying power and increase revenue. In addition to the complexity of converting patient information are the risks and impacts to meaningful use incentive plans. Whether the healthcare organization is targeting federal fiscal year (FFY) 2014, 90 day attestation period or later; this list of top 10 is essential to be successful.Conversion scope and assumptions must be clearly documented and communicated to all stakeholders. Mistakes are made in EHR conversions because team members make assumptions that are either not true or unknown by all stakeholders. The most essential information in an EHR conversion is patient identification. An Admission, Demographic and Transfer system (ADT) will be directly impacted by converting from one EHR to another. In order for John Doe's record to remain accurate, the ADT and EHR systems, as well as ancillary systems, must have him identified correctly otherwise patient care will be at risk. We recommend having scenarios included in the scope document as a way to improve comprehension by a broader base of stakeholders. Medical Record Numbers (MRN) / Master Patient Identifiers (MPI) are key elements to identify patients. ADT systems utilize internal counters to sequentially allocate these data elements. Therefore the entire patient population (ADT and EHR) must be evaluated for existing overlap and future counter generator overlap. If there are multiple facilities / sites, the MPI may play a larger role if the MRNs are reused between facilities/ sites. Most systems will not allow duplicate MRN / MPI however converting data in a database is not always constrained to the same types of rules as an end user entering a registration. Once the MRN/MPI overlap plan is defined, a subset of the conversion data can be converted. Errors during these small subset conversions will require a conflict file resolution to be defined which should be documented in the scope document. Ideally, the conflict resolution occurs on the source system but if not, will need to be part of the conversion scripting typically referred to as a "Was / Is" file during the activation phase.Table definitions are integral for all systems to communicate. A cross matrix between source and target systems is a good way to get an "apples to apples" look at this information. The cross matrix is what will lead to building the import file parameters which typically include items such as physician, employer, county, country, discharge codes.. If multi-facility / sites are involved, evaluating whether or not these tables are shared may change how they are populated into the new system. Interfaces should be leveraged as much as possible to populate the new system including A01-A27 record types. Determining discrete versus non-discrete clinical information to be converted will define the mini-conversions required for testing phase.Test loads and mini-conversions are critical for validating assumptions of the conversion. Beginning with ADT, conversion subset and the associated conflict file need to be worked until the assumptions are proven true or false before proceeding to clinical data conversion subset. If the ADT data is not accurate, the clinical data conversion will fail to identify the correct patient to attach the clinical encounter. At this point, completing full system conversions and associated conflict file management as well as updating the scope documents are important for stakeholder assumptions. Discrete data conversion makes the system more valuable to the clinician for decision support however, it also adds conversion complexity. Interface testing and validation on new and existing interfaces are key. Once the ADT and EHR have a subset converted correctly, proceed with patient merge testing. Validating that MRN and MPI merges work is critical functionality to maintain synchronized systems and could be part of the conflict file resolution plan for the ADT and EHR system prior to going live. The new interfaces should undergo standard unit testing to ensure data is passing correctly and then a full integration testing cycle based on workflow scenarios similar to the testing that occurs during an ADT or EHR upgrade.Meaningful Use (MU) data must be available for 6 years after attestation. MU needs special consideration and planning and may impact what clinical information will be converted discreetly. Depending on the stage and year of MU, the timing must be evaluated for adoption impact to core and menu items as well as the clinical quality measures (CQM). We recommend at least 2 months adoption time post conversion to ensure end users are documenting necessary elements and monitoring MU dashboards in the EHR prior to attestation.Integration testing is key to ensure that the new system and converted data is working as expected. Several environments may be used during the conversion so labeling and communicating differences will reduce confusion and issue resolution. Test plans should be provided by the new vendor which can be customized to a healthcare organizations workflow and ancillary systems.A mock live event should occur 3-4 weeks in advance of go live. The extent of the mock live are related to the complexity and feasibility of the type of conversion and environment. The key to a mock live is having a fully defined activation plan. Whether a subset conversion is run amongst several systems and then registration begins with a few clinical analysts to enter orders and documentation or a meeting to review all conversion steps in preparation for activation, items will be identified that still need to be addressed and it is essential that all stakeholders are thinking through the process for go live.Training will vary depending on systems being converted. End user training plans need to begin when table build and the import files are defined. This will ensure that all end users impacted by the conversion and activation are identified and training needs and materials developed. Inevitably, in large system conversions some ancillary system will be overlooked. Have team leads / directors from every ancillary system involved in scope review.Activation steps and planning should begin as soon as the mini-conversions begin. Teams need to be asked the question, "will that need to be done at go live as well?" Starting 6 weeks prior to go, the activation plan should be reviewed at least weekly with task owners. System conversions into the production environments may start weeks in advance using "catchup files" which can be generated and loaded into the new system to minimize the amount of downtime associated with discontinuing use in the legacy system(s). These so called "catchup files" will reduce the amount of data and time needed to convert the last subset of information prior to end users on the system. Activation owners need to be defined for 24/7 during the conversion and subsequent go live.