The Epic Charge Router is one of the most robust pieces of charging functionality within the Epic EMR platform. It can create new charges, delete unnecessary charges, and update any item of the charge it pleases. On the surface the charge router seems like a tool to solve all complex issues derived from your integrated revenue integrity team.
Despite being an incredible tool that can perform wonders for your clinicians, coders, and billers alike, it can also be misused. Changes made in the Epic charge router are permanent, meaning they don’t respect downstream build for the updated items. For example, if you update the cost center in the charge router, it is not going to evaluate through the cost center assignment table. This, in turn, means any future changes to that charge do not result in evaluation against the cost center assignment table. The cost center that was set in the router will stay on the charge unless manually updated.
Investigating issues in the router can also be a headache. In the example above, if the charge router incorrectly set the cost center due to inaccurate rule build, your IT team would then need to investigate the root cause. One of the first places your team will likely review is the charge router. Unfortunately, the charge router isn’t the easiest tool to dig through.
There is functionality available to “trace” the charges as they go through the router, but this function is resource intensive. Because of this, it is recommended to leave tracing off in your Epic Production environment. This means if there is an issue needing investigation, your team will need to spend time stepping through each piece of the charge router build or recreate the issue in a test environment where tracing is on. It becomes a cumbersome process to review these issues.
Adding to the misery of reviewing these issues is the amount of hands that help build the router. It’s not uncommon for multiple people to have built portions of the router. This lack of continuity leads to build that overlaps, cancels out, or even changes the way other portions of the router were intended to work. You may know your build, but when troubleshooting an issue, you need to know everyone else’s build as well.
As you can see, without the proper guidelines and management, the charge router can get out of control. If this is happening at your site, don’t worry, you are not alone. Our consultants at The Wilshire Group have seen this happen countless times, which is why we will be posting guidelines for maintaining an efficient charge router in this summer’s revenue integrity blog series. For today, we want to focus on how to proactively monitor your charge router’s efficiency; knowing how and when to automate the router so you can avoid this common pitfall.
Identify the Need
The Wilshire Group’s number one guiding principle is to identify if it truly is a need. It’s important to ask these questions:
How was this done historically (note: historical may not apply to since you went live on Epic!)? What is the need for this to be done automatically? What is the impact/volume?
What is the need for this to be done automatically?
What is the impact/volume?
What are other available tools?
This should truly be done for all IT requests, but it is especially important to follow this first guideline with charge router build requests or build evaluations.
Assess the Impact/Volume
As with any build decision or new workflow build in Epic, it’s important to understand the volume/impact. How often is this situation going to occur? Is the total volume or revenue impact worth the build effort needed to automate it?
At The Wilshire Group, we use the general rule of thumb that if it isn’t happening every week, then it may be best to look at other options, including manual entry. There is no sense in spending hours building, testing, and completing the final validation of new charge router build for a charge code that will be triggered 2-3 times a month and bring in $50 of net revenue to the organization.
For example, one of our customers wanted to assign the cost center within the router for a shared emergency room/urgent care space based on patient class. Patient class was the only identifier that defined where the patient was as there was only one department built out. In theory this sounded like the best idea, but we quickly realized that setting the cost center through the router could negatively impact revenue routing. The people setting the patient class were not necessarily the ones that knew whether the patient was in the urgent care or emergency room. We determined the best route was to assign a modifier from the ED Navigator and place this logic in the cost center assignment table.
While the volume in this case was high, there was a greater chance of a negative impact by building this out through the router. We weighed this against the potential manual workflow and decided the risk for incorrect revenue routing was too high to justify the automation.
As with any rule of thumb, there are exceptions (e.g. compliance), but this gives you a pretty good starting point.
Evaluate Other Available Tools
This might seem obvious, but it is often a forgotten step in evaluating whether to use the charge router. It isn’t necessarily because people don’t want to use other tools, it’s because people don’t understand all the tools available to them. The charge router becomes a catch-all solution people latch on to because it’s the closest tool that touches their workflows. The charger router signals the transition from clinical workflows to revenue cycle workflows in the charging process.
Although there are many other instances where this happens, we see it commonly with revenue routing. A supply or procedure isn’t routing to the correct cost center, and it needs to be resolved. This is absolutely something the charge router could fix, but it is usually not the best way to resolve the issue. The first step should be to see if the issue should be fixed where 95% of revenue routing occurs: the cost center assignment table.
The situation above provides insight into what the thought process should be when evaluating which tool to use. If you need to fix a pricing issue, the first step should be to review the fee schedules and fee schedule groups. Likewise, if you need to determine a method for adding a charge, the clinical charge trigger method should be the first stop, not the charge router. If those areas do not work, then review the possibility of utilizing the charge router as the last option, not the first option.
Putting these three things together to formulate a strategy of building out the router can be difficult. When and how should you automate within the router based on these guardrails?
Automate if there are not other methods available. If the charge can be triggered through an upstream charge capture method, start there.
Automate if it is high volume. Adding resource intensive build to the router for 1 or 2 cases a month isn’t worth the headache.
Automate if there is a high need. Make sure to evaluate what the need is and if it truly should even be considered for the router.
Do you feel like your revenue integrity team is bogged down by a complex or overgrown charge router? Do you find your revenue integrity team spending hours attempting to evaluate why an issue occurred only to find that there was errant build in the router or within components of the HB build? Are you struggling to understand how to implement an efficient charge router during your Epic implementation?
If your team is struggling to maintain the router post-implementation or struggling to build it our during your implementation, The Wilshire Group has the resources to provide you guidance and assistance. Our team knows how to set you and your revenue integrity team up for success. The Wilshire Group’s team of revenue integrity experts combine years of experience and industry knowledge to ensure your organization comes out ahead.
As mentioned above, these guiding principles are just the first step in creating an efficient charge router. How to automate within the Epic charge router and maintaining the charge router has its’ own set of guiding principles which we will be covering in the next few blog posts.