Implementing a new EHR system requires a great deal of collaboration between clinical and technical teams. Analyzing the legacy system and operational workflows, then successfully recreating—or better yet, improving—this experience in a new EHR takes finesse.
The foundation of every successful EHR and other large-scale implementation is a team of analysts who are knowledgeable, engaged and passionate about their work. From groundwork and discovery to build, acceptance testing and go-live support, analysts do it all. Here are four key considerations for analysts to keep in mind to help ensure their projects go well and they continue to thrive in their roles.
Start with the end goal in mind.
When gathering requirements, project teams will often start by walking through every workflow in the legacy system with end users. This can be a long process, and can lead to a lot of information gathering that is ultimately unnecessary. A better approach is to start at the end and work backwards. Ask users why they complete these workflows and what the expected outcome is. This will help get to the root of the requirements, and allow analysts to immediately begin thinking in terms of the new EHR.
Here are several questions analysts can ask when gathering requirements:
- What is the end goal or objective?
- Why have you traditionally done it this way?
- What would improve the process?
- What is the clinical rationale for this workflow?
By starting at the end and asking users why they do what they do and what outcome they are hoping to achieve, analysts can more effectively and efficiently build a system that meets the needs of users.
Be aware of the functional limitations of legacy systems.
A key point that is sometimes overlooked is that EHR workflows are often defined by—and limited by—the functionality of the EHR itself. Users will default to what they are familiar with, so if a certain workflow is used frequently in the legacy system, they will assume it is required in the new one. Some workflows may not be needed, however, because the new EHR is designed to achieve the objective in a different, more efficient way. If analysts do not understand this, they risk building in features that are counterproductive, or not needed at all in the new system.
For example, in her current workflow, a clinic manager needs to generate and print a report of all the assessments completed in the office each day. During requirements gathering, she may feel this is an important step to replicate in the new EHR. As it turns out, this workflow is a result of poor auditing functionality in the legacy system – to keep proper records, the clinic manager is required to generate and print these reports. Improved auditing functionality in the new EHR eliminates the need for the daily assessment report and makes this workflow unnecessary.
Communication is key.
One of the most important things an analyst can do is to effectively translate the clinical and business needs of end users into technical requirements for the new EHR system. They must also communicate future-state workflows in a way end users can understand and relate to. Communicating effectively is vital to project success.
EHR transitions are often intimidating and frightening for users who have established a comfort level with the legacy system, and likely had little input in the decision to change platforms. Analysts can begin to alleviate concerns and increase user adoption by putting together a few “quick wins.” A quick win is when an analyst identifies a piece of functionality that is very important to users, but is also easy to build and demonstrate in the new EHR. Quick wins communicate to users the team is not only listening to their needs, but can also deliver solutions quickly and effectively. This also increases confidence, workgroup participation, and communication response time with users and stakeholders, all of which contribute to project success.
Strike a balance between functionality and maintainability.
Enterprise EHR systems are complex and, depending on the size and diversity of the user base, may require a team of several hundred application analysts to maintain. In addition, it’s important to remember that every clinical user in a health system is depending on the EHR to complete their documentation and deliver the highest quality of care to patients. Because of this, it is important to strike a balance between functionality and maintainability.
The above graphic illustrates the relationship between functionality and maintainability – as one increases, the other decreases, and there are risks involved with moving to far in either direction.
If the project team attempts to build in every piece of functionality requested by end users, including things that are nice to have but not critical for the system to function, the EHR will become unwieldy and difficult to maintain. Future updates by the EHR vendor will likely break any customizations, cause unnecessary downtime, and push the volume of help desk requests beyond what the business can support.
In contrast, if the project team oversimplifies and standardizes too much, they risk building a system that does not meet the core requirements of end users. When users can’t leverage the system the way they need, they find “creative” approaches that don’t always work, or simply don’t document everything needed. This can lead to a host of problems such as violating operational policy, regulatory reporting issues, loss of revenue due to incorrect documentation, HIPAA violations and, ultimately, lower quality of care for patients. A well-balanced system will keep the support team busy but not overwhelmed, include all required functionality as well as some quality of life features and allow clinicians to be at their best with patients.
In summary, by keeping workflow objectives in mind, understanding legacy system limitations, communicating effectively and balancing functionality and maintainability, analysts demonstrate the value of their critical role in EHR implementation success.
