Epic Workflow Development in Three Simple Steps
A key part of any Epic project is developing specifications for what actually needs to get implemented. Your client's operational leadership should have a good idea of what workflows and processes need to be accounted for, but they don't generally know how to translate their needs into functional Epic design. Conversely, as a consultant, you come in knowing the Epic tools that are available, but you also face a learning curve regarding the client’s business requirements.
This post offers a three-step guide to navigating these knowledge gaps and eventually arriving at the best possible solution for the client with a minimum of re-work and decision swirl. With your training and knowledge—and an assist from easy-to-use diagramming tools like Microsoft Visio—the steps below should help you bring order and focus to an often chaotic, open-ended process.
Step 1: Define the Business Need
When presented with a request to accommodate a particular workflow or business need, resist the urge to immediately propose an Epic solution. Even if your first instinct for how to handle something in Epic is right, it’s easier to manage expectations with stakeholders if you don’t commit to certain functionality until you have fully assessed all the wrinkles of a workflow.
If you get ahead of yourself, you run the risk of creating opportunities for decision swirl. Operational leaders with limited knowledge of Epic may start second-guessing every decision—as well as each other—leading to long meetings where much is discussed but little is accomplished. This problem is particularly acute with remote meetings, which is why if you are limited to remote meetings it is especially helpful to have a focused review process and not an open-ended discussion.
Instead, in your initial requirements gathering, think like a journalist trying to get the “story” behind how a certain business need is addressed. For example, suppose your client wants to create a new denials management team for Hospital Billing, with process tracking in Epic. How would you write that story? Focus on getting the Who, What, When, Where, and Why of a workflow.
- Who: Which teams or groups of users are involved in the workflow? Who is responsible for decision making?
- In our denials management example, the 'Who' would be the billing office managers over the insurance follow up team.
- What: What is the end result of the workflow? A report? A regulatory filing? Payment? Are there multiple endpoints?
- In our example, the 'What' would be a reportable denials management workflow in Epic with dedicated users and workqueues.
- When: What is the turnaround time for this workflow? Is this something people or the system needs to do daily, weekly, or monthly?
- In our example, the 'When' is an ongoing process that is supposed to help reduce AR days.
- Where: Where are the decision points within a workflow? From a given starting point, what different paths are out there? Documentation of legacy processes is especially helpful here.
- In our example, the 'Where' would be different groups who would need to investigate a denial; in a legacy process, these groups would be contacted via email, but in Epic, they would be contacted using BDC records.
- Why: What is the underlying business or regulatory need being addressed here? While regulatory needs don’t change when you change IT systems, make sure the business need isn’t eliminated by the transition to Epic.
- In our example, the 'Why' is the need for improved efficiency in denial management and to report on the process using Epic reporting.
Step 2: Workflow Design and Validation
The next step to a fully validated workflow is to develop a flowchart that documents every action and decision point. Microsoft Visio is the preferred tool for this, but if you can’t get access to Visio you can still mock something up in Word or PowerPoint. The key is to get the first draft of the Epic workflow in a visual medium. This helps you document your thoughts, think through every possible variation of a process, and make sure the variants are accounted for.
Once your draft meets your own standards and addresses everything you learned in Step 1, it’s time to start reaching out to subject matter experts. This is not a formal validation step per se, but a chance to get feedback from the people who know and live with the details of the operational needs. Have the SMEs review your workflow, and incorporate changes based on their feedback. Don’t hesitate to pick up the phone and talk through any open questions. The more you and the SMEs communicate, the faster the process will go and the more comfortable everyone will be with the end result.
Continue this process of back-and-forth review until you get to a point where your SMEs are comfortable with the workflow; explain the underlying Epic functionality as necessary. Once you move to a broader group of stakeholders, you’ll want these SMEs to be able to explain and support your collective decisions to their peers. The SMEs are influential stakeholders and will play an important role selling the final workflow to hesitant internal team members.
As a final step before a formal validation/adoption session, socialize your workflow with the key decisions makers whose sign-off you need. By this point your workflow should be pretty close to final, but the senior managers will be sure to point out anything ambiguous or confusing. This will preempt a lot of potential questions with the broader group. It will also help help frame the final validation/adoption session as more of a check-off on the agreed upon workflow, rather than an open-ended working session.
Step 3: Formal Validation and Workflow Build
There are two different methodologies for successful validation/adoption sessions. The one to use depends a great deal on the audience and the underlying complexity of the workflow.
If your stakeholders are at a point where they are comfortable talking about Epic, it’s best to have the formal validation/adoption session prior to building anything out. This will avoid potential re-work. Present the Visio that you developed with SMEs and validated with senior management, walking everyone though the workflow. Ideally, you’ll obtain sign-off and additional feedback, then proceed to build out the workflow in Epic.
On the other hand, if the people in your validation session are still learning Epic, it may be best to do your validation/adoption session as a demo. This approach is best early in an install or when dealing with large, cross-functional teams. In this case, build out everything in Epic based on your Visio, and have a demo ready to go to show all the “branches” of the workflow. Then, as you go through the validation session, you can demonstrate each step of the workflow in Epic to help operational staff feel comfortable with what they are being asked to sign off on.
With either approach, the end result should be a completed workflow implemented in Epic with full operational buy-in and minimal time lost due to decision swirl and re-working the build.
Consultant David Ricci is an Epic Resolute HB Analyst with 5+ years Epic build experience who has participated in multiple, full life cycle Epic implementations.
