CPIA Module 21, Section 3: Rule Logic and Best Practice Advisory Configuration
MODULE 21: VENDOR-SPECIFIC LAB – EPIC WILLOW INPATIENT

Section 21.3: Rule Logic and Best Practice Advisory Configuration

A deep dive into Epic’s clinical decision support engine. Learn how to write criteria-based rules (LRC records) and configure Best Practice Advisories (BPAs) to guide prescribers and protect patients.

SECTION 21.3

Rule Logic and Best Practice Advisory Configuration

Translating Clinical Intuition into Digital Intelligence.

21.3.1 The “Why”: Digitizing the Pharmacist’s Sixth Sense

Every experienced pharmacist possesses a powerful, highly-trained clinical intuition—a “sixth sense” that activates when a prescription doesn’t feel right. It’s the internal alert that fires when you see an opioid order for a patient already receiving one from another provider, a metformin order for a patient with worsening renal function, or a potassium dose that just seems too high. This intuition is your most valuable safety tool. It is a complex algorithm running in your brain, constantly processing patient context, clinical guidelines, and pharmacological principles.

But this human algorithm has a fundamental limitation: it cannot scale. You cannot be at the elbow of every prescriber, for every order, for every patient, 24 hours a day. The central challenge of clinical informatics is to take this expert intuition and embed it into the electronic health record itself. How can we make the system as vigilant as an experienced pharmacist?

The answer lies in Epic’s Clinical Decision Support (CDS) engine. This engine is composed of two primary parts: Logic Records (`LRC` master file), which act as the digital “brain,” and Best Practice Advisories (`LGL` master file), which serve as the “voice.” A Logic Record, or “rule,” is the digital translation of your clinical knowledge—the “IF/THEN” statement that your brain processes instinctively. The Best Practice Advisory, or “BPA,” is the communication method—the tap on the shoulder, the cautionary note, or the hard stop that your intuition would compel you to deliver.

Mastering the art and science of building rules and BPAs is perhaps the most impactful skill a pharmacy informatics analyst can develop. You will move beyond simply managing the digital formulary to actively shaping clinical practice. You will build guardrails that prevent common errors, create workflows that promote best practices, and design alerts that provide crucial information at the precise moment of decision-making. However, this power comes with immense responsibility. A poorly designed alert can be worse than no alert at all, creating a cacophony of warnings that clinicians quickly learn to ignore—a phenomenon known as alert fatigue. Your challenge is to build a system that is not just intelligent, but wise; a system that speaks only when it has something truly important to say.

Retail Pharmacist Analogy: Writing the Instruction Manual for “Rex,” Your Hyper-Vigilant Technician

Imagine your pharmacy hires a new technician named Rex. Rex is incredibly fast, has access to every patient’s chart instantly, and never gets tired. However, he is also extremely literal and will only do exactly what you tell him to. Your job is to write his complete operational manual, turning him from a simple dispenser into a hyper-vigilant safety expert.

Part 1: The Instruction Manual (The `LRC` Rules)

You create a binder for Rex labeled “Safety Protocols.” This binder is your collection of Logic (`LRC`) Records. Each page contains a single, unambiguous “IF/THEN” instruction.

  • Page 1 – Renal Dosing: “IF a prescription is for ‘Gabapentin’ AND the patient’s most recent ‘eGFR’ lab value is less than 60, THEN you must flag this prescription for pharmacist review.”
  • Page 2 – Duplicate Therapy: “IF a prescription is for any drug on the ‘SSRI List’ AND the patient’s active medication profile already contains a different drug from the ‘SSRI List’, THEN you must flag this prescription.”
  • Page 3 – Therapeutic Monitoring: “IF a prescription is for ‘Amiodarone’ AND it is a ‘New Order’, THEN flag this as a reminder for the pharmacist to ensure baseline ‘LFT’ and ‘TSH’ labs have been ordered.”

This binder is the “brain” you are building for Rex. The more precise, evidence-based, and high-value your instructions are, the smarter he becomes.

Part 2: Rex’s Communication Style (The `BPA` Alerts)

Next, you have to tell Rex *how* to communicate his findings. He can’t just shout “Problem!” for everything. You create a “Communication Protocols” section in his manual. This is your Best Practice Advisory (`LGL`) Configuration.

  • For the Amiodarone Flag (Informational BPA): “Rex, when you flag an amiodarone order, just attach a small yellow sticky note to it that says, ‘Reminder: Check baseline LFTs/TSH.’ Don’t stop the workflow, just provide the information.”
  • For the Gabapentin Flag (Interruptive BPA): “Rex, when you flag a gabapentin order for renal dosing, I need you to place a large RED stop sign on the prescription. The pharmacist MUST stop, review the patient’s renal function, and sign off on an acknowledgment before they can proceed with verification.”
  • For the SSRI Flag (Actionable BPA): “Rex, when you flag a duplicate SSRI order, attach a note that says, ‘Duplicate Therapy Detected.’ Below that, give the pharmacist two buttons they can press: one button that says ‘Discontinue previous SSRI’ and another that says ‘Contact Provider.’ Make it easy for them to solve the problem.”

The combination of Rex’s instruction manual (`LRC` rules) and his communication style (`BPA` alerts) creates your automated safety net. If your rules are too broad (“flag all blood pressure meds”), Rex will overwhelm you with sticky notes, and you’ll start ignoring him. This is **alert fatigue**. Your job as an analyst is to be a master author of Rex’s manual, making him the most effective, intelligent, and respected member of the pharmacy team.

Part 1: Deconstructing the Rule Engine: Logic (`LRC`) Records

Logic records, stored in the `LRC` master file, are the foundational building blocks of Epic’s CDS. An `LRC` record is a set of criteria that the system evaluates against a patient’s chart at a specific moment in time (a “context”). If all the criteria in the rule are met, the rule “evaluates to true.” This “true” result is then used to trigger an action, most commonly the display of a Best Practice Advisory. Building an `LRC` record is like writing a logical statement or a hypothesis that the system will then test.

The Core Structure of a Rule

Every rule you build will have three main structural components that you must define with precision.

Component Description Analogy: Rex the Technician
Context WHEN should the rule be evaluated? This defines the trigger for the system to even look at the rule’s logic. This is telling Rex *when* to read a specific page in his instruction manual. “Only read the ‘Renal Dosing’ page when a new prescription arrives.”
Criteria WHAT should the rule check for? This is the logical statement, built from properties, operators, and Boolean logic (AND/OR). This is the actual “IF” statement on the page in Rex’s manual. “IF the drug is gabapentin AND the eGFR is less than 60…”
Evaluation Result The outcome of the check. The rule is either “True” or “False.” This is Rex’s conclusion after checking the prescription against his instructions. “Yes, the conditions are met” (True) or “No, they are not” (False).
Context: Defining the Trigger

Choosing the right context is the first and one of the most important steps in building a rule. An incorrect context means your rule will either never fire or will fire at the wrong time, annoying users and missing safety opportunities. Here are some of the most common contexts for pharmacy-related rules:

  • Order Signing (Provider Workflow): The rule is evaluated the instant a provider clicks “Sign” on one or more orders. This is the ideal context to catch errors before they even reach the pharmacy.
  • Order Verification (Pharmacist Workflow): The rule is evaluated when a pharmacist opens an order in their verification queue. This is a critical context for rules that provide pharmacists with information needed for their clinical review.
  • Medication Administration (Nursing Workflow): The rule is evaluated when a nurse scans a medication at the bedside. This is used for very specific warnings related to administration (e.g., “Administer over at least 60 minutes”).
  • Chart Open: The rule is evaluated whenever a user opens the patient’s chart. This is used for broad, persistent patient-level warnings (e.g., “Patient is on a high-risk medication protocol”).
Criteria: The Language of Logic

The criteria section is where you write the rule’s logic. This is done by combining three elements:

  1. Properties: Discrete pieces of data from the patient’s chart (e.g., Patient Age, an ordered medication’s GPI, the result of the latest Potassium lab).
  2. Operators: Logical operators that compare the property to a value you define (e.g., is, is not, is greater than, is less than, contains, is on list).
  3. Boolean Logic: The use of AND, OR, and parentheses to create complex logical statements.

Let’s visualize how these combine to form a complex rule:

Example Rule Logic: High-Risk Potassium Order
(
Property: Ordered Medication’s Therapeutic Class Operator: IS ON LIST Value: “Potassium Supplements”
AND
(
Property: Order Dose Operator: IS GREATER THAN Value: “40 mEq”
)
OR
(
Property: Patient’s Total Daily Potassium Dose Operator: IS GREATER THAN Value: “100 mEq”
)
)
Masterclass on Properties: Your Data Toolkit

The power of your rules is directly proportional to your knowledge of the available properties. There are thousands of properties you can use, but a core set will handle 95% of your pharmacy-related builds.

Property Category Commonly Used Properties Example Use Case in a Rule
Patient Data Age, Sex, Weight, Height, Allergies, Problem List, Diagnoses (Current and Historical) IF Patient Age is less than 18 AND Ordered Medication is "Aspirin" THEN... (Checks for Reye’s syndrome risk).
Medication Data Ordered Medication (by `MED` or `ERX` record), Therapeutic Class, GPI, Active Medications, Discontinued Medications, Medication History (from Surescripts) IF Ordered Medication GPI is in "Opioids" AND Patient Medication History contains an Opioid from a different prescriber in the last 30 days THEN... (Checks for potential doctor shopping).
Lab Data Latest result for a test, Highest/Lowest result in a timeframe, Presence of any result IF Ordered Medication is "Spironolactone" AND Latest "Potassium" result is greater than 5.2 THEN... (Checks for hyperkalemia risk).
Order Data Dose, Frequency, Route, Priority, Duration, Order Type (New, Modify) IF Ordered Medication is "Vancomycin" AND Order Dose is greater than 2000 mg THEN... (Checks for a potentially excessive single dose).
Flowsheet Data Vitals (BP, HR), Assessments (Pain Score), Intake/Output IF Ordered Medication is "Labetalol IV" AND latest "Heart Rate" is less than 60 THEN... (Checks for contraindication based on nursing documentation).

Part 2: Configuring the Alert: Best Practice Advisories (`LGL`)

If the `LRC` rule is the brain, the Best Practice Advisory (BPA) is the voice. A rule evaluating to “true” does nothing on its own. It must be linked to a BPA to have any visible effect on the end-user. BPAs are built as records in the Best Practice Advisory (`LGL`) master file. The art of a good analyst is not just writing an accurate rule, but pairing it with the right type of BPA to achieve the desired clinical outcome without causing undue frustration.

The BPA-LRC Linkage: The Critical Handshake

The very first and most important configuration step in a BPA record is linking it to the `LRC` record(s) that will trigger it. A single BPA can be triggered by multiple rules. For example, you could have one BPA that says “Renal Dosing Required” and link it to dozens of different `LRC` rules, one for each renally-cleared medication.

Efficiency Tip: Reusable Rules and Modular Design

Top-tier analysts do not build a new, monolithic `LRC` rule for every single BPA. They build smaller, reusable “component” rules and then combine them. For instance, instead of making a massive rule for “heparin-induced thrombocytopenia,” you would build smaller rules like:

  • `LRC 1`: Patient is on Heparin.
  • `LRC 2`: Platelet count has dropped by >50% in the last 72 hours.

You can then combine these two rules in your BPA logic. This modular approach means you can reuse `LRC 1` in other alerts related to heparin, saving you significant build time and making maintenance easier.

Masterclass on BPA Types: Choosing the Right Voice

The “Type” of BPA you choose is the single biggest factor in how it will be perceived by the end-user. Choosing the wrong type can turn a helpful suggestion into an infuriating roadblock.

Type 1: Informational (The Gentle Nudge)

These BPAs appear discreetly and do not interrupt the user’s workflow. They are the digital equivalent of a helpful sticky note.
Use Case: Providing context, reminders, or suggestions that are helpful but not critically urgent.
Example: When a provider orders IVIG, an informational BPA appears in a sidebar with a link to the hospital’s official IVIG dosing and administration protocol. The provider is not forced to look at it, but it’s easily accessible if they need it.

Type 2: Interruptive (The Cautionary Stop)

These BPAs pop up over the user’s screen, interrupting their workflow and forcing them to acknowledge the message before proceeding.
Use Case: Warning users about a clear and present potential for moderate to severe patient harm. These should be used judiciously to avoid alert fatigue.
Example: A provider orders tramadol for a patient actively taking fluoxetine. An interruptive BPA appears, warning of the significant risk of serotonin syndrome and requiring the provider to enter a reason for overriding the alert (e.g., “Benefit outweighs risk”).

Type 3: Actionable (The Smart Assistant)

These are the most advanced and helpful BPAs. They not only identify a problem but also offer one-click solutions.
Use Case: For common problems with standard, protocol-driven solutions. The goal is to make the right choice the easy choice.
Example: An `LRC` rule detects that a patient is being ordered sliding scale insulin but does not have an order for basal insulin. The BPA that appears says, “This patient does not have scheduled basal insulin. Use of sliding scale insulin alone is discouraged. Would you like to add a long-acting insulin order?” and includes an “Add Basal Insulin” button that automatically suggests a starting dose of Lantus.

The Hard Stop: The Nuclear Option

A special subtype of the Interruptive BPA is the “Hard Stop.” This is an alert that cannot be overridden by the end-user. It completely blocks the provider from proceeding. Hard Stops should be reserved for only the most catastrophic, life-threatening, “never-ever” events. An example would be attempting to order chemotherapy for a patient who is not in a location designated as a chemotherapy administration unit.

Implementing a Hard Stop is a major clinical and political decision that requires approval from the highest levels of clinical leadership. They are incredibly powerful but can also halt patient care if not designed with absolute perfection. Use with extreme caution.

Step-by-Step BPA Build: Renal Dosing for Gabapentin

Let’s walk through the configuration of an interruptive BPA linked to our previously discussed gabapentin renal dosing rule (`LRC` Rule: `IF Med is “Gabapentin” AND eGFR < 60`).

BPA Configuration Section Setting Value / Configuration Rationale
General Name PHARMACY - RENAL DOSING - GABAPENTIN Follow a standard naming convention so you can easily find and manage your alerts.
Triggering Logic Criteria Link to the `LRC` record for Gabapentin Renal Dosing. Connects the “brain” to the “voice.”
Display & Type Type Interruptive This is a significant safety risk that warrants stopping the user to ensure they have seen the patient’s renal function.
Title Text Renal Dosing Recommended A clear, concise title for the pop-up window.
Message Text Patient's eGFR is [Patient's Latest eGFR Value]. The ordered dose of gabapentin may be too high. Recommended max dose for this eGFR is [Calculation]. Please review and adjust the order. The body of the alert. Use “smart text” (the bracketed items) to pull in live patient data, making the alert more specific and useful.
User Interaction Acknowledgment Reasons Create a list of reasons: Will adjust dose, Benefit outweighs risk, Neurology consult approved dose. Forces the user to document *why* they are continuing, providing valuable data for later review and protecting them from a liability standpoint.
Security Override Security Allow users with the `PHYSICIAN` or `PHARMACIST` security class to override. Prevents a medical student or other user from overriding a critical safety alert.