Understanding Best Practice Advisories in Epic
Epic's Best Practice Advisory system triggers alerts at the point of care when clinical workflows meet predefined rules. It's the mechanism that pops up when a physician orders a drug without checking a lab value, or when a medication conflicts with another active drug. The BPA framework sits inside the Cogito engine and can be configured through multiple entry points in the build manager. Most organizations run hundreds of them live, and a decent chunk of those generate daily alerts that clinicians acknowledge and dismiss. The core idea is simple: pair a trigger with a response. A BPA fires when a specific action occurs—like placing a medication order—and then presents either an alert, a documentation prompt, or an order set recommendation. You define the conditions using filters, select the message template, and decide whether it halts the workflow or runs silently in the background. Epic's standard distribution model means you're building on top of code that comes from the vendor, then layering your own custom conditions on top.
Best Practice Advisory Epic Examples
One of the most common BPA patterns I've seen is a renal dose adjustment alert. When a prescriber orders a medication that's renally cleared, the BPA checks the patient's latest creatinine clearance and fires if the dose exceeds what the protocol allows. The trigger pulls from the problem list for active renal conditions, references the result set for recent labs, and cross-references the medication's dosing guidelines. You'd think this would be straightforward. The edge case I ran into was with patients who had a creatinine clearance calculated by a formula that wasn't the default CKD-EPI method. The BPA was firing on normal doses because the lab system was sending CrCl values but the BPA filter wasn't matching against the correct result type identifier. I had to adjust the filter to also accept the alternate result set and add a secondary condition that checked the method code. That took about four hours of debugging across the build manager and the BPA trace tool. Another frequent example involves antibiotic stewardship. Hospitals use BPA to require a brief clinical justification before certain broad-spectrum antibiotics get ordered. The rule checks the drug, the indication on the problem list, and the allergy list. If the criteria don't align, the prescriber has to document why they're deviating from the standard. This reduces unnecessary fluoroquinolone and carbapenem use without completely blocking the order. The counter-intuitive part is that these BPA aren't actually the thing driving behavior change most of the time. The real lever is the reporting dashboard that feeds back to departments showing their compliance rates. The BPA itself often gets skimmed through because the message template is too long. Shorter messages with a single required checkbox have higher engagement.
Building and Configuring BPA
Access the build manager through the Epic tools and navigate to the BPA section. You'll create a new advisory, assign it a unique ID that follows your institution's naming convention, and then configure the trigger conditions. The trigger can be tied to medication orders, procedures, problem list changes, or even nursing assessments depending on the module. Each condition uses a filter builder where you select the data element, the operator, and the value. You can combine multiple conditions with AND or OR logic. After the trigger, you define the response. There are three main types: an informational alert that gives details without blocking, a hard stop that prevents the order from being placed until the clinician acknowledges, and a soft stop that allows override after a documented reason. Most organizations lean toward soft stops for common advisories because hard stops generate more override complaints and take longer to resolve. I've seen facilities cut their BPA override rate in half within a month just by converting twenty percent of their hard stops to soft stops with better message wording. The message template is where a lot of builds go wrong. The default templates are generic and fill the screen with policy language that nobody reads. I usually recommend stripping the message down to three lines maximum. One line stating the clinical issue, one line with the recommended action, and one line with the override path. The override field should require a reason code from a predefined list rather than free text. Free text reasons take longer to audit and rarely contain useful information. The reason code dropdown takes about ten minutes to set up and saves dozens of hours during annual review cycles.
Get the Full Details
Pitfalls and What Actually Breaks
The biggest mistake I see teams make is creating BPA without a deactivation plan. Every BPA needs an expiration date or a recurring review schedule. Alerts that sit live for years without review become noise. Clinicians learn to dismiss anything that appears more than twice a day regardless of severity. There's a threshold effect around seven alerts per provider per shift after which compliance drops off a cliff. I audited a system once that had over three hundred active BPA and the average clinician was seeing forty-two per day. The override rate was ninety-one percent. Essentially nothing was working. Another structural issue involves how BPA interact with order sets. If you push a BPA recommendation into an order set, the alert fires before the order set is even visible to the prescriber. That creates a confusing sequence where the user gets interrupted by something that the order set was supposed to prevent. The workaround is to either exclude that particular BPA from triggering within the order set context or restructure the order set to include the missing element as a required field. Epic lets you scope BPA to specific order set usage through the trigger conditions, but the interface for that isn't obvious. You have to know to look under the advanced options in the filter builder. Data quality is the silent killer of BPA reliability. A BPA that checks for a diagnosis on the problem list only works if that diagnosis actually exists on the problem list. If providers are documenting conditions in free-text notes instead of adding them as coded problems, the filter returns nothing and the alert never fires. I've spent entire weeks chasing BPA that appeared to be broken only to discover the underlying problem list was populated with non-coded entries. The fix was coordinating with the clinical documentation improvement team to shift certain diagnoses into structured problem list entries, which is a governance decision, not a technical one.
Testing Before You Go Live
Never deploy a BPA directly to production without validation. Use the test environment with real patient records that exercise every branch of your logic. Run the BPA trace tool to confirm it fires under the expected conditions and stays quiet under others. Check the overlap with existing BPA to make sure you're not creating duplicate alerts on the same clinical event. Duplicate BPA are a major source of alert fatigue and they compound because each one independently trains clinicians to hit dismiss. The validation phase should include a clinical subject matter expert reviewing the message wording and the override path. Engineers tend to write messages that are technically accurate but clinically useless. A nurse who will actually see the alert needs to confirm that the recommended action is something they can execute in their workflow. If the BPA tells a pharmacist to adjust a dose but appears on the nursing workstation, the chain of custody is broken and the alert will be ignored every time. I'd recommend starting with a small pilot group of ten to fifteen providers across different specialties. Monitor the alert volume and override patterns for two weeks before rolling out more broadly. The early data will tell you which advisories are worth keeping and which ones are just adding clutter. Most initial builds generate about thirty percent more alerts than the final optimized version. That reduction comes from refining the trigger conditions and removing duplicates during the pilot phase.
Epic provides documentation on BPA configuration through their support site and internal knowledge base. The current version-specific guidance covers the filter syntax, template variables, and deployment steps. There's also a community forum where health information managers share their configurations and sometimes post downloadable examples from their build environments. Those community examples are useful for understanding how other institutions structured their triggers, but you should never copy one directly. Your patient population, your local protocols, and your existing BPA landscape will be different.
The Hard Truth About BPA ROI
Best Practice Advisories are not a silver bullet for clinical quality improvement. They work best as part of a broader strategy that includes workflow redesign, provider education, and leadership accountability. A well-configured BPA can catch about sixty to seventy percent of the targeted adverse events in controlled studies. The remaining thirty to forty percent get through regardless of how many alerts you stack on top. That gap usually comes down to urgency. When a provider is in acute decision-making mode, even the most relevant alert gets overridden. The system design can't fix that. What it can do is make sure the alerts that do break through are the ones actually worth breaking through for. If your goal is pure compliance monitoring, BPA is the wrong tool. Use reporting queries and chart audits instead. BPA are designed for real-time intervention, and trying to repurpose them as after-the-fact tracking mechanisms creates confusing user experiences and unreliable data. Keep the tool honest by matching the alert type to the clinical intent. Actionable alerts for actionable moments. Documentation nudges for documentation gaps. And if an alert doesn't change behavior when it fires, it shouldn't be an alert. It should be a report.
