When any group or individual embarks on a new journey into the unfamiliar they often rely on those who have gone before them. Whether this is the result of consulting a map, reading a travel book or discussing with peers most don’t enter into a journey blindly. The growth of services like Google maps, Trip Advisor and Yelp all let people collectively share experiences to help those who come after make an informed decision. However, when planning a large complex technology initiative such as a Hospital Information System, or Electronic Medical Record, organizations can overlook this tried and tested approach. The challenge for many organizations undertaking a HIS/EMR replacement is that many of the hospital staff do not have experience leading or supporting such a significant change.
A typical approach for many hospitals is to hire project staff who have participated in such a change along with partnering aside vendors that promise success by following their special recipe. These mitigations aside there are still numerous stories of hospitals navigating pitfalls that are seen as novel. But the reality is that these pitfalls are often shared, much like the ratings found on Yelp or TripAdvisor. Failing to learn from other organizations is the equivalent of disregarding the various star ratings and maps of the aforementioned services: thinking that the food will somehow taste better, the rooms will definitely be cleaner, or someone must have put a road in by now to make your journey more efficient and timely. The point is, there is value in organizations completing lessons learned, like anyone planning a new journey, to avoid the challenges others have faced previously.
The challenge with making lessons learned successful is to ensure they are incorporated into an overall plan. If not, then the lessons just become a list of challenges an organization can expect to encounter. This isn’t an easy task. Early in many projects there is an optimism of what is ahead. This is natural for any project. Projects are selected based on the good they can accomplish, not the challenges they will pose. I’ve been in numerous lesson learned reviews where sponsors or leadership remarks that ‘those projects did a poor job’ or ‘that won’t happen to us’. The latter statement may be true, but not without effort and planning. Even then, it is likely that something will arise that challenges leadership and the organization. This isn’t a result of poor planning, or poor product selection. It also isn’t a product of poor leadership or staff. It is the natural effect of trying to plan for the future. Despite an organization’s best attempts at anticipating potential challenges, something unforeseen can still arise. Not all maps will tell you construction is on route, or an accident will occur affecting your drive. TripAdvisor and Yelp ratings, to return to an earlier example, are based on point-in-time experiences by people other than yourself. Menus, staff and quality can all change since the time of the review. It is also a personal experience and may not reflect the same tastes that one may have when judging the subjective. That said, it doesn’t mean we forego planning and doing due diligence. It just needs to be understood that there is only so much that can be controlled and understood early in any journey especially one as large and complex as an HIS/EMR replacement project.
That said, there are themes associated to the lessons many organizations learn when going through an HIS/EMR replacement. These include: support and go live, workflow planning and implementation approach, communication and executive support, project and resource management, testing and training, and finally data and integration. The following outlines some of the lessons learned hospitals have captured when implementing an HIS/EMR.
Best practices for deploying HIS/EMR
| Lessons Learned | ||
| Item/Risk | Issue(s) Realized | Mitigation recommendations |
| Support/Go-Live | Unclear downtime procedures.
Changes occurring post go-live generated confusion and rise in incident calls. Vendor was only onsite for a 1-2 weeks after Go-Live. Staff shifts not controlled during Go-Live; some staff members worked 36h straight |
Document downtime/change windows and downtime procedures.
Have downtime communication processes established prior to go-live. Keep support channels simple: one email, one phone number Start communication with enterprise early. Document change governance process. Ensure support knows how to triage calls post change. Have support staff wear identifiable clothing. Prepare schedule well in advance. Establish command centre. |
| Lessons Learned | ||
| Item/Risk | Issue(s) Realized | Mitigation recommendations |
| Workflow Planning
/Implementation Approach |
Unclear or poor communication on future state workflows.
Unclear expectations of HIS system. The higher speed of change overwhelm staff and increases risks of error created by many other system or process changes. Customization can increase build time and affect the implementation plan and budget. |
Allow time to establish future state workflows and communicate with staff .
Establish working groups & questionnaires to capture preferences. New processes need to be sustainably embedded into the work culture giving staff a chance to adjust to the changes. Hospitals can go with a staged approach by beginning to use different functions of the system at different times. Ensure all systems that need to interact with each other are interfaced correctly. Minimize the need for interfacing by choosing integrated software. Try to limit customization by highlighting the benefits of standardization. |
| Lessons Learned | ||
| Item/Risk | Issue(s) Realized | Mitigation recommendations |
| Communication/
Executive Support |
Not having enough senior team on the project resulted in less authority over
• Spending money • Hiring new staff • Changing policy • Redesigning workflows Competing priorities Lack of committed leadership support. Poor decision-making structure.
Lack of change management support and knowledge.
Workplace culture/politics preventing progress.
Not enough staff to backfill during training and other project activities. Emails were not the most effective way to communicate. Lack of communication that resulted in resistance to change.
Lack of good bi-directional communication between leadership and staff. |
Involve key decision makers in the team (as many as possible) as early as possible
Leadership “specific” for EMR. EMR rollout cannot be “one more thing” on their plate. Create scorecards for leadership to use where they could identify areas that are lagging compliance/buy-in
Assign champions who would encourage their peers to accept EMR showing the ease of use and workflow benefits
Highlight organizational priorities to show the importance of the work being conducted-
Ensure proper organizational change management strategies are in place Try to communicate mostly through in-person communication (face to face)
Leadership to help staff understand that they are embarking onto a transformation project that involves technology, not a technology project
Gather feedback and keep the communication channels open with the front line staff
Develop a framework for clear and rapid communications (e.g. weekly emails, all-staff meetings, bulletin board, etc.) about rapidly evolving situations |
| Lessons Learned | ||
| Item/Risk | Issue(s) Realized | Mitigation recommendations |
| Project Management/
Resources |
Vendor provides vendor specific timelines and tasks without consideration of site schedule.
Vendor does not leverage PMI standards (uses coordinator leveraging non-standard tools) Awareness not provided to project stakeholders until too late. Budget not revisited throughout project lifecycle. Resource(s) not dedicated or available when needed. Poor knowledge transfer during resource turnover resulting in lack of productivity. Additional resources required during different phases of project peak periods impacted budgets. Additional cost for trades for cabling, utilities and other physical modifications impacted budget. Under-scoping device config and costs (printing, bar-code scanners, etc.) impacted budgets. Reconfiguration due to infection control cost impacted budgets. Exchange rate impact to budget. Non-HIS customizations impacted budgets Additional interface work impacted budgets. Device expansion, impacted licensing for base software (i.e. windows OS, Office, etc.) |
Dedicate resources for project and fund backfill as appropriate.
Ensure standard documentation for project and ensure compliance to minimize loss of knowledge due to resource transfer or loss. Leverage in-house resources to retain knowledge. Ensure sufficient budget allocation for training and devices based on bench marking. Plan for a % of contingency regardless of dollar amount ie 10% contingency regardless of total budget. Ensure status reporting standards: format, audience and frequency are decided upon and adhered to throughout project lifecycle. Dedicate financial analyst to project to perform overall reporting. Ensure vendor provides standard suite of documentation. Build vendor of record relationship with resource suppliers. Plan budget spikes for resourcing during build, test and go-live phases. Involve staff in device selection and then freeze requirements. Involve infection control early in device evaluation process. Engage downstream (ie biomedical devices) vendors early to identify integration points and potential customizations. |
| Lessons Learned | ||
| Item/Risk | Issue(s) Realized | Mitigation recommendations |
| Testing/
Training |
Training without backfill of staff
Underestimation of amount of training required
Training too early required retraining, pushing timeline of go-live
Super users were not able to train their peers properly
Failure to ensure that staff actually complete training prior to using system.
Failure to have a full rehearsal before go-live.
End to end testing not performed until very late. This resulted in issues between modules that were built independently as well as interface issues. Test planning not formal, but vendor led via work sheets. True effort not scheduled. Not enough cycles planned for defect resolution. Gaps in usability found post go-live. What was communicated and functional were not consistent. Testing unable to be completed due to compressed timelines. Deficiencies that were accepted were not communicated. Test scripts vendor specific not organizational. Testing compressed and resource intensity increased resulting in resource burn out. |
Minimal training initially and detailed training right before go-live
Consider train-the-trainer approach to save costs Dedicate training hours for staff to avoid distraction Practice each major workflow repeatedly just before and during go-live.
Develop a strategy to use help files and train experienced users to be super users to help their colleagues. Train in groups with similar specialties (common goal and direction) Train Subject Matter Experts earlier in the process. This lead to increased adoption and engagement, better requirements and design options and reduces the need for education during meetings Develop a resource plan for testing. Ensure resources are fresh so issues can be discovered. Ensure function ownership and participation. Integrate end-users in test case creation. Communicate deficiencies and work arounds as part of go-live strategy. Determine entrance criteria for go-live. Don’t compromise. Develop organization specific test cases. Do not rely on vendor work sheets alone. Schedule numerous iterations of testing to ensure sufficient time to resolve issues. Ensure end to end testing is scheduled throughout the testing process. Formal test planning that informs project schedule. |
| Lessons Learned | ||
| Item/Risk | Issue(s) Realized | Mitigation recommendations |
| Data/Integration | Lack of design resulting in real time discovery impacting schedule.
Customizations required by non-HIS vendors not aligned with schedule. Additional resources required to assist with interface work to make up for schedule slippage. Resources working in isolation resulting in missing requirements. Lack of documentation, design and test cases making procured resources inefficient. Inability to plan for future state without familiarity of new system. Lack of clean up of dictionaries/data prior to migration negatively impacted schedule. Unclear impact to downstream systems as a result of dictionary changes resulted in delay to build and issues in test which impacted schedule. Dictionaries unavailable during testing created unforeseen issues when going live. |
Invest in current state integration map and data flow requirements.
Identify non-HIS system integration requirements early and engage vendors. Budget for software enhancements and resources to support spikes of work. Co-locate teams as much as possible. Determine documentation standards for design and test and ensure compliance. Bring in consultants with experience designing future state on selected platform. Plan for dictionary/data clean-up activities in schedule based on bench-marks. Bring consultants in early to identify potential lessons learned, pit falls and give enough time for consultant to understand current state needs. Make dictionaries a dependency for testing/training modalities where they are needed. |
Having just completed an HIS/EMR replacement project and doing the above work to help my organization complete this initiative I can say that we did not avoid all these issues. That said the project was considered a success by many involved and garnered external recognition as project implementation of the year by Canada Health Informatics Award. So it’s important to understand that a project can both be a success and have issues at the same time. Minimizing the issues as much as possible is the project goal, and how a project responds to issues that arise are often testaments to their skill, leadership and resiliency. However, expecting a project to be ‘issue free’ is unrealistic. After all, no one can predict the future.
Another important take away is that any lessons learned activity has a research component, which highlights what has happened to other organizations. This is one piece of the puzzle. It is also an opportunity to gain engagement from staff. Although they may have not completed an HIS/EMR replacement in the past, they have likely had first-hand experience delivering, participating or experiencing the outcomes of technology projects and as a result can provide insights that are specific to an organization. This information is just as valuable as it will help the project team proactively navigate organizationally specific cultural challenges.
Regardless of whether your organization is planning a HIS/EMR replacement or other technology implementation, the above lessons learned should serve as a Yelp or TripAdvisor comments section. It may or may not apply to you or your organization, but hopefully it is additional information that will help your organization plan for its future journey.
