By Bob Gronberg, Sr. Director, Meditech Professional Services, CereCore
Twitter: @CereCore
EHR implementations are a huge investment. And for many healthcare IT teams, this type of project may be a once in a career type of experience. I have spent more than 30 years of my career helping healthcare organizations through EHR implementations — converting from and to MEDITECH.
Over the years, I have accumulated scars, tattoos and wisdom from projects that have failed to achieve their original goals. So, let me pass on some of the most common “project killers” and the lessons learned that can help keep you on the right path.
Warning signs
One of the first things I do when working on a new project is do a quick scan for some early warning signs that a project killer might be lurking.
A project killer is any aspect of facet of the EHR implementation project that is likely to cause
- Timeline delays
- Added complexity
- Scope creep
- Increase in the project budget
Plan for the unknown and try to ask as many questions as possible, as early as possible in the planning process. Pay attention to subprojects. When they are undefined, the unknown can quickly add complexity, become more resource intensive than first thought, extend timelines and increases cost. Scope creep is a real threat and perhaps the number one warning sign that an implementation project is in jeopardy.
Recently, we worked with a site that originally had their lab inside the organization where they ran a lab department, just like most acute care facilities. Some staff changes occurred in that particular department during the EHR implementation so they decided to outsource the entire department. This decision had a huge ripple effect on workflow, resourcing, the project timeline and milestones. A project killer.
What can you do to guard against project killers?
Before you begin an EHR implementation project, make sure you have clear plans in place for these four areas:
- Project Governance
- Reporting
- Integration
- Data Conversion
Healthcare organizations that have taken the time to adequately plan for each of these areas have been more likely to rebound from the unexpected. Let’s dive into the details.
1. Project Governance
Project governance is the mechanism that will help stakeholders — from executive leadership to clinical department managers, revenue cycle experts, HR and others — understand what’s going on, have appropriate ownership for various parts of the project, facilitate decision making, and resolve conflicts.
Often governance meetings are held more frequently at the beginning of a project, taper off during the throes of the project and ramp up again before go-live. The more effective and relevant the governance meetings the more likely your project governance will be effective, too. When governance council meetings are canceled, executives or other decision makers don’t attend, then your governance framework will crumble, and the project will suffer.
Some of the common components of project governance include these types of groups:
Governance teams. Governance teams should help your organization navigate project planning decisions such as:
- What is my role on the project? What am I responsible for?
- What types of decisions can I make vs. the team?
- How will you handle conflicts? Who needs to be at the table to make decisions?
- How will decisions be documented and communicated?
- What decisions need to be made? For example, are we going to use similar data to what we had in the old system? Are we going to rewrite how this works or what it integrates with? How could this department benefit from workflow changes?
Executive sponsorship. An EHR implementation project is not an IT project but a clinical IT project. Having an executive sponsor who has a clinical background will help ensure clinicians have an advocate who keeps patient safety and clinician satisfaction top of mind.
Advisory groups. It’s important there is open dialogue and the executive sponsor is actively engaging with the physician, clinical and financial advisory groups so that the EHR can be designed and implemented in such a way that it supports their needs. Each specialty may have a slightly different approach to workflows and using the system. When you start to talking about how patients will flow in the system, you need to ensure the right people are at the table understanding what’s going on and hopefully the right people in power to drive decisions.
Steering committees. Typically, the steering committee focuses their attention on things like budget, project scope and overall timeline, appropriate evaluation criteria. They are also usually the team responsible for monitoring key performance indicators and metrics, and they need regular involvement in the EHR implementation project.
Core teams. Of course, the brunt of the work is done by core teams and they are focused on applications and workflows. As applications become more integrated, core teams have started organizing around work streams and workflow instead of a specific application.
The caveat: When project governance isn’t strong or healthy (lack of leadership, communication or staffing), then we often see projects begin to run into delays or they don’t achieve the original scope and goals.
2. Reporting
Reporting is an area often unnoticed until late in the project but needs early focus. It includes printed reports but also data automatically generated, files sent to a data warehouse or repository, dashboards and worklists.
- A key early step: Assess the current state. Understand which reports are used and how.
- Evaluate standard versus custom reports with a critical eye – use standard where ever possible.
- Analyze new system functionality and how it might change reporting needs or workflow. For example, MEDITECH Expanse has dashboards that can often replace printed reports in previous versions of MEDITECH.
- Determine priority for reports that will be needed at go-live. This will be critical in helping stratify the documented report writing needs.
To help get the conversation going, ask questions like these:
- How are you going to get data out of the system for daily operations?
- What near real time reporting do you need for patient safety?
- What reports do you use now? How do you use this information? What parts of the reports are of value to you?
- What reports must be available at go-live? Why? Engage the requestor in a justification exercise and remember that it costs time and money to write these reports.
- Does the report need to be printed? Could a dashboard help make the data more meaningful?
- An approach to consider: Put a moratorium of six months on developing custom reports until you have determined that the standard report won’t serve your needs?
I worked with one site who had thousands of custom reports that were mostly iterations of the same report. Instead of spending their time on rebuilding these custom reports, they defined report specifications and trimmed down the list of legacy custom items. Be aware that if you decide to recreate reports in the new system you might lack test data. Advanced functionality within MEDITECH Expanse relies on a certain amount of test data to create the dashboards, which may delay implementation of this feature. A better approach is to plan and budget for advanced reporting features in the phase two project that takes place after go-live. This will allow the reports to be tested against a robust LIVE data set.
3. Integration
There are many different layers to integration, ranging from point-to-point interfaces to bi-directional data connections with a third party. For integration, follow a similar thought process as you did with reporting. Analyze what you have, understand what’s important, what needs to be integrated and determine if there are areas of improvement or consolidation.
The number of interfaces you have can affect your project implementation budget. A good rule of thumb: if you have more than 20 active interfaces within your legacy environment, then you may need a specific project manager to help plan, test and coordinate all of the pieces.
I worked with a site in NY who created a map to understand their integrations and data flow, and the map spanned a 6×6 foot wall. Not understanding these complexities could interfere with your ability to have a comprehensive set of testing events.
Often the first level of integration testing is not complete and comprehensive, missing vendors who were unable to be ready in time. Questions to pose when it comes to integration testing milestones include:
- Who are the downstream vendors? Who will be required to participate in the integration testing events?
- What are the interface points for the workflows from patient scheduling through discharge?
- Have you accounted for the points within the workflow where data is sent out to other vendors?
4. Converted data
Assumptions are often made when it comes to getting data out of the old EHR and into the new EHR, and those assumptions can be problematic. Converted data is always a compromise, generally is far less clean than expected, and the perceived value of this data will rapidly diminish after go-live. Assess the data you really need and determine how legacy data will be used.
If you are transitioning from MEDITECH Magic to MEDITECH Expanse, data conversions are available but not all data conversions are accounted for or in the format you need, and you may be looking at additional cost and resources to convert data from certain applications. For example, archived data from Lab may not come over into the Lab application but needs to be reached via some archived report feature in the Scanning and Archive application.
We have worked with countless sites who have transitioned from Allscripts to MEDITECH, and while the process can bring over Master Patient Index (MPI) data, the process does not resolve duplicates. The integrity of the data is a common issue in this situation. Questions to ask when planning the conversion process: How clean will the data be when you bring it over? Will this data provide value and will it be trusted for patient care going forward?
Consult with your physician advisory committee (PAC) or ambulatory PAC to be sure the data will meet their needs for patient care and address any patient safety concerns. Often the project will discover end users would rather start fresh and not deal with the issues that converted data may present. For example, a site was looking at converting radiology data and the abstract would be available in the EHR but the type of test and physician information was only in the PACs system. While this data conversion is possible, does it provide value to providers? Or which data conversion might be a higher priority?
Be aware of the cost associated with formatting data from a legacy vendor to the MEDITECH specifications. Will the legacy vendor provide the data, but will it need to be massaged in order to determine how to move the data across? Analyzing legacy data is a time intensive exercise that adds additional cost to your budget quickly.
Finally, remember to discuss legal ramifications and regulatory requirements.
This article was originally published on CereCore and is republished here with permission.