Migration to a new EHR like Cerner, Epic, Allscripts, etc., is one of the largest and most complex projects the health IT team can take on. Typically, 100s of interfaces need to be converted or implemented, which requires the coordination of dozens of project managers, application analysts, interface analysts, and integration engineers to execute on schedule without negatively impacting day-to-day operations.
However, with the proper training and advice from experienced professionals, your IT team may be able to avoid some pitfalls. I surveyed our Professional Services team to compile a list of best practices to help customers migrate to Cerner’s EHR system. We hope the following suggestions will help you and your organization successfully join the growing Cerner user community.
Beginning at tip number eight, you’ll find some unique attributes about Cerner that will be particularly helpful as you begin migrating interfaces.
Tips for a successful Cerner migration
- IT leaders should immediately begin talking to colleagues from other departments to ensure there is “buy-in” at every level and to identify and address potential roadblocks early in the process.
- Project Managers should collaborate early and often with their interface teams, application teams, and integration engine vendor to determine the “best” migration strategy for their particular organization. This includes deciding whether or not to have rolling go-lives of interface groups in phases, or to have a “big-bang” type of go-live, in which all interfaces are brought into production over the course of a single event.
- Determine a clear delineation of responsibility. All stakeholders working on the migration should have clear knowledge of their expectations, including which aspects of the migration they will be responsible for, the process for communicating project status updates, etc.
- Assign an analyst to every application. You will need someone to thoroughly test and sign off on each new interface prior to production.
- Consider your old data: Will you leave it in the old EHR system or do you plan to backload it into Cerner? If so, which systems’ data do you want to include?
- Interface teams should take inventory of their current environment – make a list of existing applications and interfaces to identify those that are staying and those that need to be converted. Take the time to diagram the current interface environment and also create a diagram that dCernerts what it will look like after the Cerner migration.
- Does your current ADT feed send ROL and CON segments? How about A31s? Do your downstream applications need them? If not, you can filter these segments out using Corepoint Integration Engine. Do not send messages that are not needed or important.
- Cerner is leans toward being “encounter-centric” in its design. For example, some EHRs have one MRN per patient. If there happened to be multiple MRNs in the system for the same patient, they could be easily merged. In Cerner, a patient can exist with many MRNs and account numbers that use an end-effective date.
- Be on the lookout for phone number formatting in the modules. Occasionally, a patient’s phone number will be entered in one module, yet disappear by the time the patient record gets updated from a different module.
- Transacts in Cerner typically runs off of CCL scripts. CCL is Cerner’s SQL-based scripting language.
- And last, but not least, know that dates will change. Don’t freak out, and don’t stick to an unrealistic timeline.