Tips on How to Successfully Select and Implement an Electronic Health Record

Pat Stricker, RN, MEd
Senior Vice President
TCS Healthcare Technologies

Selecting and implementing a new electronic medical record (EMR) or electronic health record (EHR) is a huge project for any organization. These are large systems used throughout the organization with detailed information about the patient and their treatment. They are integral to the daily operations of the organization, so organizations must think carefully about exactly what they need and be sure the system will help them achieve their organizational mission and goals. They also need to choose the right vendor – one that aligns with their organizational goals and strategies, is willing to be a “partner” with the client, and has a good reputation for successfully completing implementations and launching the system as promised and on-time. 

While the terms EMR and EHR are often used interchangeably, there are differences according to the Office of the National Coordinator for Health Information Technology (ONC).

• EMRs were developed in the 1960s and were primarily digital medical (clinical) records used by physicians to diagnosis and treat their patients. They took the place of paper records and, in addition, provided the ability to monitor and track patient data and improve the quality of patient care. However, the information did not travel outside the practice group. The patient record still needed to be printed and mailed to specialists and other members of the care team. 
  
  
• Over time the EMRs evolved into EHRs as the healthcare industry started to develop standards to allow other healthcare data to be collected and shared with all care team members. EHRs provided a broader view of the patient record that could be shared outside the practice group with specialists, hospitals, therapists, outpatient care, post-acute care facilities, home care agencies, laboratories, etc. EHRs also began to define and drive workflow processes, as well as provide evidence-based decision-making tools, order entry, plans of care, documentation templates and detailed monitoring and analytical capabilities. EHRs became total patient health records that can be accessed by the patient or any healthcare provider caring for them to assure the most up-to-date, coordinated, patient-centered care.
  
  An electronic health record is defined by the Healthcare Information and Management Systems Society (HIMSS) as: “a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR automates and streamlines the clinician’s workflow. The EHR has the ability to generate a complete record of a clinical patient encounter – as well as supporting other care-related activities directly or indirectly via interface – including evidence-based decision support, quality management, and outcomes reporting.”

So even though the terms EMR and EHR are used interchangeably, they are very different. We will be using the term EHR.

Last month’s article, Physician and Nurse Involvement Is Critical in EHR Selection and Implementation, focused on why EHRs are important and why physicians and nurses need to be part of the selection and implementation process. This article will focus on how to select the right EHR and vendor and how to make sure the system is implemented in a way that meets your needs and those of your patients.

Selecting an EHR

Selecting the “right” software for any project is not an easy task. There are numerous EHRs available, each with its own capabilities and processes. On average it takes 6 months to over 2 years for organizations to select an enterprise software. So you must make sure you take the time to find the one that fits your unique goals and needs (requirements). The following are some key steps that you should consider when selecting an EHR or other software for your business needs. 

Planning

• Create a selection committee comprised of representatives from management and line positions from all functional areas that will be using the system or interacting with it. This is critical so ideas, input and feedback are obtained from all interested parties.
  - Assign an executive champion to provide guidance and clear roadblocks
  - Assign a full-time project manager with experience implementing large software projects
  
  
• Define your organization’s business, operational, and expected outcome goals and how you envision the system can help achieve them.
  
  
• Define “ideal” processes and workflows
  - Review all current and planned workflows carefully. Identify what works/is needed and what doesn’t work/isn’t needed. Eliminate all unneeded steps and those that are not being tracked or reported on.
  - Spend time re-designing workflows so you have streamlined, automated workflows that you can use to define your workflow requirements. Include steps you think may not be possible (it never hurts to ask!).
  
  
• Define requirements that are critical to your processes (efficiency measures, documentation standards, performance consistency and standardization, etc.).
  NOTE: On average a requirements document such as this will consist of over 275 requirements. Sites like SelectHub provide templates to help you develop the requirements.
  - “Must Have” – mandated requirements that are essential
  - “Needed” – requirements that are necessary. They are needed to make workflows and processes easier or improve efficiency and performance, but not mandated. 
  - “Like-to Have ”– ideas that seem improbable or impossible, but would be great if they were available, such as auto-documentation, automated integration with other applications, etc. (They may not be available but it never hurts to ask!)
  - Analytic – Quality, analytic, and quantitative tracking, monitoring, and reporting
  
  
• Research software products that meet the needs identified above.
  - Conduct an internet search for a product that meets all your identified requirements.
  NOTE: An average of about 10 software products are typically researched, but that number should be reduced before scheduling demonstrations.
  - Using a site like SelectHub may help reduce your time and effort. It provides a software selection platform that lets you identify the type of product needed, determine the requirements you are looking for, set priorities and compare products that meet your needs. It also provides templates to help you develop the requirements.
  - Seek input from surveys, client recommendations, or other rating services.
  - Make sure the product is flexible enough to fit your defined needs. You should not have to change your workflows to fit the software.
  - All data in the system should be reportable, measureable, and able to be analyzed to show how workflow benefits the patients, providers, organization, and entire healthcare system.
  - Consider the user experience and ability of the patient to access their record.
  - Consider the way the system is deployed and what IT resources are needed to maintain it.
  
  
• Research software vendors to find a “partner”, not merely a service provider or vendor. Selecting the “right” vendor is just as important as selecting the “right” software. The vendor needs to be aligned with and able to support your strategic goals and expected outcomes. And the two organizations need to have similar company cultures so they can develop a true collaborative partnership in which each is willing to help the other. Conducting a detailed vendor assessment is key! It is just as important as assessing the product.
  - Conduct an internet search for a vendor that has a proven track record in the industry.
  - Seek input from surveys, client recommendations or other rating services.
  - Consider whether the vendor aligns with your clinical, administrative, revenue, population health and analytic goals.
  - Ask for statistics on their success rates for implementation and launching on-time. Ask if they have ever failed an implementation. They should have these statistics available.
  NOTE: Under-performance and project failures can be an issue. Statistic show that for all IT projects more than ½ fail and 83.3% under-perform.
  - Make sure they have a defined implementation process (with timelines) to share with you and that they have a dedicated implementation team to work with your team.
  - Ask for references and speak to or visit them to see how the system works for them. Also ask what the system is not able to accomplish for them.
  - Develop a list of vendor requirements based on the above.
  - Schedule an on-line overview demo to see if the product is what you are looking for. It does not need to be detailed at this point in the process.
  
  
• Develop a Request for Information (RFI) and/or Request for Proposal (RFP) Document based on the product and vendor requirements that you have already defined.
  - An RFI is an initial communication document sent to numerous vendors that describes your organization; the need, scope, and purpose of the proposed project; and higher level requirements. It may also include expected pricing, delivery methods, and other business information. An RFI provides the organization with summarized information from each vendor in order to determine which vendors should be reviewed in more detail.  
  - An RFP is a formal, comprehensive request that is sent after an RFI or in place of an RFI to elicit detailed information from vendors an organization is interested in. It includes detailed information about the project, its timeline and budget and detailed requirements that a vendor must meet. It allows the organization a chance to compare all vendors using the same criteria.
  - A list of detailed “Must Have,” “Needed,” and “Like-to-Have” requirements should be listed giving the vendor as much information about what you are looking for and what the system needs to be able to do.
  NOTE:  The Smartsheet website provides free business templates designed to assist organizations in building RFI, RFP, and requirements documents for projects.
  
  
• Evaluate RFIs/RFPs to Determine Vendors for Demonstrations
  - Develop a Demonstration Checklist based on the product and vendor requirements.
  - Each type of requirement in the RFI/RFP should be listed with a scored ranking. Quality, analytic, and quantitative tracking, monitoring, and reporting requirements would be listed under one of these categories and scored accordingly. Using a point system for scoring will make it easier to objectively compare all products and vendors. The scoring system could be similar to this for the system requirements:
  - “Must Have” - mandated requirements, so no points awarded                       0
  - “Needed” - necessary, but not mandated. They make workflows and
  processes easier or improve efficiency and performance.                            + 1
  - “Like-to Have” - ideas that seem improbable or impossible, but would be
  GREAT to have                                                                                             + 2
  - “Available” with Customization (extra cost)                                                 -  1       
  - “Not available” – requirements are not available                                         -  2
  
  
• Add a vendor requirements section to the checklist.
  - Score their requirements in a similar fashion
  - Also consider adding or subtracting points based on your interactions with the representatives from each vendor. Were they responsive, friendly, and helpful? Did they anticipate your needs? Did they understand your business needs and goals? Do they have a dedicated team to work with your team? Does their culture seem to fit in with your organizations culture? How do they handle issues and delays? Do they have good implementation and launch statistics? Have they ever had a failed implementation? Also add other things that are important to your organization.
  - Tabulate the scores for each vendor and choose the top 3-6 for further evaluation.
  
  
• Manage the Demonstration Process
  - Select no more than the top 3-6 vendors for a demonstration based on the product and vendor scores.
  - Schedule a demo – It can be an initial online demo, if that has not been done, or a full product demo at your site.
  - Schedule a defined timeline for the demo – Schedule the same amount of time for each vendor (e.g. 2-4 hours) and stick to the timeline. Do not allow vendors to go over the time allotted, as it is not fair to other vendors. It also shows that the vendor may not be organized enough to conduct the demo within the specified timeline.   
  - Schedule all demos within a short timeframe (e.g. 2-3 days or up to 1 week). This makes it a little difficult time-intensive for the Selection Committee during that time period, but it reduces the confusion of trying to remember vendors and products that were presented over a long time period. 
  - Ask for customized case scenarios to be presented - Send the vendor case scenarios for key processes or functions you want them to demonstrate. Vendors should be asked to develop these scenarios in their system and show them during the demo. Those that do not take the time to develop these scenarios should have points deducted from their score. 
  - Ask vendors to show other “Must Have” and “Like-to-Have” requirements – Ask them to show as many as possible in their demo. They should not be allowed to just tell you that they can do something. Insist that they show you how it is done.
  - Develop a Demonstration Checklist that includes all product and vendor requirements. Also include Comment Sections so the committee can provide non-solicited feedback.
   - Provide each committee member with a checklist at the beginning of each demo and ask them to rate each requirement as it is demonstrated.
  - Require committee members to complete the checklist at the end of each demo to assure their observations are fresh. Allowing them to wait until the end of the entire demo process to fill out the checklists leads to confusion about what each product/vendor demonstrated. It is best to collect feedback immediately.
  - Tabulate the results of the Demonstration Checklists after all demos have been completed.
  - Hold a committee meeting to discuss the demo results. Gather input from all areas and try to reach a consensus on a chosen product/vendor.
  -Select a “Partner” and product.
  
  
• Contracting would be the last step in selecting a software.   

Implementing an EHR

The next step is to implement the chosen software. This task will now be taken over by the implementation team. Some of these team members may have been on the selection committee, but many others were not, so all team members need to be brought up to speed on the product and its goals for the organization. The goals and strategies for the project need to be reviewed, as well as the requirements, and expected outcomes. A demo of the system is also needed, so everyone is familiar with its capabilities.

The vendor’s project manager oversees the implementation project, working in conjunction with the client’s project manager. Weekly status meetings should be scheduled for the implementation team, as well as monthly or bi-monthly governance meetings with senior leadership to discuss the project’s progress and outstanding issues.    

While each product will have its own steps in the implementation process depending on the nature of its processes, they usually include steps similar to these:

• Initial Implementation Team Meeting – this can be done by conference call, on-line or in-person at the client site to introduce the client and vendor management and implementation teams.
  - The client should present an overview of the goals and strategies for the project, as well as the requirements, and the expected outcomes.
  - The vendor should present an overview demonstration of product, the implementation process, and review a draft implementation plan explaining: all key steps, expected timeframes, training schedules, and expected responsibilities and time commitments for implementation team members.
  
  
• Installation of the System – The two technical teams should begin to install the system.
  
  
• Initial On-site Meeting – should include:
  - An initial overview training for the implementation team focusing on the features of the system and “hands-on” practice in navigating it.
  - An in-depth assessment and discussion of current and expected workflow processes for all functional areas should be conducted, if this has not already been done. The goal should be to revise and optimize the workflows and processes, not use the current ones. This is an essential step that drives how the system will be configured to meet the client’s unique needs and helps the vendor finalize the implementation project plan with realistic tasks and timeframes. 
  
  
• In-depth training for the client’s implementation groups:  technical, clinical, reporting, etc. These sessions focus on specifics related to their key responsibilities.
  - The technical team will install the system, set-up network connections, create processes for data loads and exports, build interfaces, etc.
  - The analytics group will work on developing reports, audits, and data analytic needs.
  - The clinical team will set up workflow processes and configure the system.
  
  These trainings can be done on-site or in on-line sessions. Due to the cost of on-site visits, more implementation steps are being done using on-line conference sessions. These sessions, which continue throughout the implementation, are part training and part “hands-on” work, with tasks assigned between meetings. Intermittent on-site work sessions are also scheduled.  
  
  
• Re-designing Processes  – Old, convoluted processes and work-arounds should not be brought over to the new system. Workflow processes need to be simplified, optimized, and automated as much as possible. Automated workflows based on business rules and evidence-based data should be added whenever possible. All stakeholders should have input into the re-design of the workflows that affect them. Third-party applications should also be reviewed to see if they are still needed or if the processes can be done in the new system, thereby eliminating extra work.
  
  Health care leaders agree that streamlining, automating, and optimizing processes is a critical step that allows the system to provide value and efficiencies. One even joked that “if you don’t (redesign workflows first), you’re just moving garbage at the speed of light and magnifying inefficiency.”  Another said, “When we redesigned the system around (a workflow process)…it streamlined so much, and from a quality point of view it also took out a huge number of errors and potential errors.”  Clearly, process redesign is a critical step that requires time and attention!
  
  
• Development of a Practice System – Each team needs to have access to a practice system where the implementation staff can test data loads, configuration, reports, etc. The vendor should offer a process that allows each team their own system that can be used by them and not interfere with other groups. For example a vendor may offer to set up three databases: one for technical group to use for data loads, interfaces, etc.; one for configuring the workflows and processes; and one for training and practice used by all groups.
  
  
• User Acceptance Training – Prior to the final training, the data load and configuration databases that contain all the new processes and integrations can be combined to produce a database for User Acceptance Testing. Realistic case scenarios should be developed for all workflows and processes. Team members should enter these into the system to assure they are accurate. If not, they should make needed changes and test again. Once the team is convinced the workflows and processes are accurate, the database can become the End-User Training database.     
  
  
• End-User Training  – This is usually conducted within one to two weeks before Go-Live. The timing will be determined based on the number of staff to be trained and the availability of training facilities. The goals should be to train for comprehension and retention of basic skills and to observe the students and offer suggestions. Ideally, each trainee should have their own computer, not a shared computer, so they can get as much “hands on” practice as possible. The class should be taught by the vendor and the client, with the vendor providing basic features and navigation and the client teaching client-specific workflows and processes.
  
  After the training a training room should be available for the staff to continue to do more individual practice or have 1:1 training with an instructor or mentor before Go-Live. They should be encouraged to enter real-life, case scenarios that test the various workflow processes that are included in a normal workday or to replicate actual cases they performed the previous day. This has been identified as a key need, as studies have shown that in problem implementations about 85% of the staff members were missing basic skills at Go-Live. Extra practice time also provides further User Testing of the newly designed workflows and system changes.  
  
  
• Go-Live! - The implementation team and vendor should be available for the staff at Go-Live and during the first week to offer assistance and keep logs depicting all issues, suggestions and requests for changes. At the end of each day, the implementation team should review what went well and things that need revision. This continuous improvement quality process is critical, so that issues are identified and addressed on a timely basis. 
  
  
• Post-Implementation Support – Weekly team status meetings should continue for the next three to four weeks or until all issues and revisions are resolved. An ongoing Change Management Process should be put in place to identify and resolve all quality issues that continue to arise. The client should be reviewing the system, utilization, performance, and workflow issues and results.
  
  About four to six weeks after Go-Live, the vendor should schedule a meeting with the client’s leadership and implementation teams to get input on the overall implementation project: what worked, what could have gone better, etc. This information should be used by the vendor to improve their implementation processes.
  
  Lastly, about six to nine months after Go-Live, the vendor should conduct another on-site visit to determine how the system is working, reassess the client’s needs, review ongoing configuration needs, provide suggestions for improvements, provide additional tips and hints for better use of the systems and assist the client in determining how to add additional programs or processes, if needed.  

It’s hard to know if a software system will work the way you initially envision, until you actually work with it for a while. Defining exact requirements at the beginning of the project is a crucial step, but it still needs to be followed by a continued process to monitor and revise issues and problems as they arise. You can’t just implement a system and then forget it and move on to the next project.   

I hope this article has provided some insight into the most important factors to consider, if you are looking for a new system. Knowing how to choose the “right system and vendor” is extremely important, which then makes the actual implementation much easier. Any implementation takes a great deal of time and resources, but it is definitely worth it, because of the improved effectiveness, efficiency, productivity and clinical outcomes that it can provide. Taking the time to choose the “right system and vendor,” re-design and optimize workflow processes, and train the staff on basic skills are critical keys to achieving a successful implementation.          

But the most important thing is to “get a seat at the table” – to become part of the selection and implementation process. If you know this type of project is being planned, volunteer to be on a committee; don’t wait to be asked. Your input is invaluable. You work in these systems every day. You know what is needed. You know what works and what doesn’t. You know what new processes are needed and what could be eliminated. If you are not chosen for a committee, document your ideas and suggestions in a professional, positive, succinct format and submit them to the selection committee. That way, even if you don’t have a seat at the table, you will be at the table and you’ll have a chance to offer input. 

Pat Stricker, RN, MEd, is senior vice president of Clinical Services at TCS Healthcare Technologies. She can be reached at pstricker@tcshealthcare.com.