©2019 by Abido Network. 

Beyond the Basics with Epic Beacon

January 4, 2019

Beacon is a unique application in the Epic universe. Beacon lives somewhere between Ambulatory, Willow, and Inpatient, drawing functionality from each application. While Beacon itself is a fairly straightforward app to learn and build, a deep knowledge of at least one of the other apps is necessary to take full advantage of Beacon, with Willow being the most influential secondary application. 

 

Chemotherapy roadmaps were inherently more complex than the standard admission order set in the paper world, and the roadmap transition to Epic is no different. This complexity combined with tight project timelines and under-experienced builders often times leads to organizations simply copying the paper roadmap directly into a treatment plan. While this provides the bare minimum value of moving to an electronic record, it completely misses all of the opportunities for increased safety, efficiency, and automation that Beacon can provide. 

 

Eventually, machine learning will take over as the gold standard for real-time decision support, but that does not mean that you cannot build some automation into Beacon as it exists today.

 

Let’s take a look at the top four missed opportunities when building Beacon protocols:

 

 

1. Not using ERX orderables for all mixture medications

 

This is a huge problem for most organizations that rushed through Beacon implementation. Best practice is to have an orderable for every mixture medication that appears in a protocol. Yes, every single one. If that seems impossible, an orderable for every chemotherapy agent is the bare minimum. Even if there is only one ERX for a medication, it is still best practice to make an orderable with one medication. Seems like a huge build effort right? Not really, and the initial workload will pay dividends down the road. Let’s see how:

 

Maintenance. More ERXs means more maintenance, right? Not when it comes to Beacon. Let’s say for medication X you have an ERX for a 50 mL mixture and an ERX for a 100 mL mixture. At the time of the treatment protocol build, the roadmap called for the 50 mL mixture. However, as the roadmap is revised, the prefered mixture changes to the 100 mL. 

 

If your treatment protocol was built with the dispensable 50 mL ERX, then you have a big problem. Not only do you have to replace it with the 100 mL ERX in each treatment protocol, you also have to manually go into each active patient on that treatment plan and change it one by one. Every. Single. One. For a large oncology organization, that could be hundreds of patients if not thousands. This would take hours for the build team, who would most likely turf this task to the clinical end users. Any time there is a manual process, it introduces an unnecessary patient safety risk.

 

On the other hand, if this medication was inserted into the treatment protocol as an orderable, the process is much easier. The orderable ERX needs to be adjusted to point to the 100 mL ERX instead of the 50 mL ERX. That’s it. All of the treatment protocols will automatically update as well as all of the active patient treatment plans. By using an orderable ERX, a change that would normally take days only takes a few minutes.

 

Flexibility.  Using an orderable ERX introduces another level of automation. In versions Epic 2015 and earlier, this means that patient age and weight parameters can be utilized for dose automation. Epic 2017 introduced rule based context and mapping that exponentially expands the options for dose automation.

 

2. Ignoring dosing rules

 

Dosing rules provide the type of automation that everyone hoped to gain from the adoption of electronic health records. The problem with dosing rules is that it generally requires a more sophisticated level of build and extensive collaboration from clinical staff. The benefits in efficiency and in patient safety are well worth the effort.

A properly built treatment protocol has two levels of dosing rules: ERX orderable and treatment modification rules. Both take advantage of CER rules that can be built on a large variety of properties. These rules can vary in complexity from simply age to almost any discretely captured variable available in the patient’s chart. Let’s take a quick look at how they differ:

  1. ERX orderable rules can be used for dosing with context rules or in product selection with mapping rules. When would you want to use these rules in a treatment protocol?

    1. The medication is always going to be dosed in this way regardless of the treatment protocol or even outside of Beacon.

    2. This orderable is only going to be used for this protocol.

    3. If there is more than one drug, or another creative build solution in combination with treatment modification rules.

  2. Treatment modification rules are defined directly in the Beacon order group. Treatment modification rules also take advantage of CER rules to make specific modifications. Here is when you would want to use treatment modification rules:

    1. If orderable ERXs are shared among several treatment protocols or are even used outside of Beacon.

    2. In combination with ERX orderable rules for creative build solutions.

 

3. Refusing to build protocol specific ERXs

 

Many build teams I have worked with have a general aversion to building custom ERX records. It is absolutely necessary to build custom ERXs for your version of Epic. The Foundation System provided by Epic is a very basic shell that is really only intended to provide example ERXs for your reference. This version of Foundation System is provided to all new customers, from rural one hospital systems to multinational organizations like Mayo Clinic and Johns Hopkins, from pediatric hospitals to oncology hospitals. There is absolutely no way that the Foundation System can come even close to providing everything you need as an organization.

 

In addition to that, keep in mind that end user functionality and patient safety are the most important factors when it comes to EHR build, not build effort. In order to optimize either of those two factors, it might be necessary to build duplicative ERXs for specific protocols or even particular order sets. The maintenance aspect to ERX build is largely overblown, especially when utilizing orderables in protocols and provider facing med lists. The functionality within medication lists provides a large amount of flexibility with regards to which ERXs are available for providers. At the end of the day, if your Beacon build can be solved by creating a new ERX record, then that is exactly what you should do.

 

4. Only using basic mode order groups

 

Sure, basic mode order groups are the easiest to build and implement but they do not offer the end user the type of flexibility that they may want. Additionally, only building basic order groups often leads to including way too many supportive medications for every patient. For example, if only using basic order groups, it might be tempting to default orders for zofran tablets, ODT tabs, liquid, and injection just in case the patient has a preference for one of those. What results is four orders for essentially the same medication for every patient on that particular treatment protocol, even if they only want to take the ODT tablets on every visit.

Instead, take advantage of the different order modes to allow providers to select the supportive therapy that is the best fit for the patient. In addition to basic, there is single-select, multi-select, and select-all. For medications, multi-select gives the provider the greatest amount of flexibility while keeping the treatment plan from becoming cluttered with unnecessary medication orders.

 

Oncology is a complex and challenging discipline in medicine, and sophisticated Beacon build can simplify many of the routine aspects of chemotherapy treatment, producing more time for providers to spend focusing on their patients, research, or any other activity in pursuit of advancing the field. Beacon optimization for automation represents a tremendous opportunity to improve the end user experience while increasing patient safety.

 

Case study

 

Below is an actual scenario that presented at a hospital live on Beacon:

The treatment protocol called for corticosteroid therapy based on the patient’s age:

  • Decadron (patients <10 yo): dose: 5 mg/m2/dose BID x14 days (28 doses)

  • Prednisone (patients >/=10 yo): dose: 30 mg/m2/dose BID x28 days (56 doses)

The treatment protocol was built with both options presented to the provider. It is up to the provider to select the correct therapy. There were cases of patients receiving inappropriate therapy for extended periods of time due to incorrect selections at the time of treatment plan entry.

 

Using what you have learned in this post, how would you automate this therapy using the least amount of rules and custom ERX records? 

 

For more information on managing your Epic system, be sure to check out our services page.

Share on Facebook
Share on Twitter
Please reload

Featured Posts

Beyond the Basics with Epic Beacon

January 4, 2019

1/4
Please reload

Recent Posts
Please reload

Archive