CPIA Module 5, Section 2: Design Principles and Rule Logic Frameworks
MODULE 5: CLINICAL DECISION SUPPORT (CDS) FUNDAMENTALS

Section 5.2: Design Principles and Rule Logic Frameworks

A Practical Guide to Translating Clinical Knowledge into Actionable Code.

SECTION 5.2

Design Principles and Rule Logic Frameworks

The Art and Science of Building Intelligent Clinical Guardrails.

5.2.1 The “Why”: From Clinical Expertise to System Engineering

In the previous section, we established the foundational philosophy of effective CDS through the Five Rights. We learned that to avoid creating noise and instead build meaningful interventions, we must deliver the right information to the right people, through the right channels, in the right format, at the right point in the workflow. This is the “what” and the “why” of our mission. Now, we pivot to the “how.” This section is designed to be your hands-on introduction to the engineering behind the philosophy. We will demystify the process of rule-building, transforming the abstract concepts of clinical safety into the concrete, logical structures that computers can execute.

As a pharmacist, you are a master of applied clinical logic. When you see a prescription for warfarin, your brain instinctively initiates a series of logical checks: “IF the patient is on an interacting antibiotic like trimethoprim/sulfamethoxazole, THEN I must warn the patient and prescriber about the increased bleeding risk. IF the patient’s latest INR is supratherapeutic, THEN I must recommend holding the dose.” You perform these complex logical operations dozens, if not hundreds, of times a day. Your clinical expertise is, in essence, a highly refined, human-powered rules engine.

The task of an informatics pharmacist is to serve as a translator—to take that sophisticated, nuanced clinical logic that lives in your brain and codify it into a formal, unambiguous language that the EHR can understand. This section will provide you with the grammatical rules of that language. We will deconstruct the fundamental “IF-THEN-ELSE” framework that forms the bedrock of nearly all CDS. You will learn how to identify the precise data elements needed to serve as triggers, how to combine them with logical operators to create specificity, and how to design the resulting actions to be maximally helpful and minimally disruptive. This is the point where your clinical judgment becomes the literal source code for system-wide patient safety.

Retail Pharmacist Analogy: From Master Chef to Recipe Author

Think of an experienced, world-class chef. They can walk into a kitchen, survey the available ingredients, and intuitively create a masterpiece. They don’t need a written recipe; the knowledge, the “rules” of flavor combinations, cooking times, and techniques, are all ingrained in their expertise. This is you, the experienced pharmacist, exercising your clinical judgment at the bedside or pharmacy counter.

Now, imagine that chef is tasked with creating a meal kit service, so that thousands of home cooks can replicate their famous dish perfectly every time. The chef’s intuition is no longer enough. They must now become a recipe author. They must deconstruct their intuitive process and translate it into a series of precise, explicit, and unambiguous instructions.

  • The “IF” Clause (The Prep Steps & Conditions): The recipe must be explicit. It can’t just say “cook until done.” It must say, “IF using a gas stove, THEN set the flame to medium-high. IF the chicken breast is thicker than 1 inch, THEN pound it to an even thickness.” These are the conditions and triggers.
  • The “THEN” Clause (The Action): This is the core instruction. “THEN sear the chicken for exactly 4 minutes per side.”
  • Specificity and Logic: The recipe must account for variables. “IF using unsalted butter, THEN add 1/2 teaspoon of salt. ELSE (if using salted butter), do not add extra salt.” This “IF-THEN-ELSE” logic prevents a disastrously salty or bland outcome.
  • The Goal: The goal is to write a recipe so clear and precise that even a novice cook can achieve a safe and delicious result.

As an informatics pharmacist building a CDS rule, you are the master chef acting as a recipe author. You are taking your deep clinical intuition and translating it into a flawless, step-by-step recipe that the EHR—the “home cook”—can execute reliably for thousands of patients, ensuring a safe and effective outcome every single time.

5.2.2 The Bedrock of CDS Logic: The “IF-THEN-ELSE” Framework

At its core, almost every piece of CDS, from the simplest alert to the most complex protocol, is built upon a simple, powerful logical construct: IF-THEN-ELSE. This structure is the fundamental syntax of clinical reasoning, both for humans and for computers. Understanding and mastering this framework is the absolute first step in learning how to build rules.

IF

The Condition (The Trigger)

This is the “question” the system asks. It is a set of criteria that is constantly evaluated against patient data. It is the “listener” that is waiting for a specific clinical scenario to occur.

THEN

The Action (The Intervention)

If the “IF” condition is met (evaluates to TRUE), this is what the system does. It is the “action” that delivers the CDS to the user, such as firing an alert, suggesting an order, or sending a task.

ELSE

The Alternative

This is what happens if the “IF” condition is NOT met (evaluates to FALSE). In 99% of CDS rules, this is simply “do nothing.” The system remains silent, avoiding unnecessary noise.

As an informatics pharmacist, your job is to define these three components with absolute precision. A vague or poorly constructed “IF” clause will cause the alert to fire too often (a high rate of false positives, leading to alert fatigue) or not often enough (a high rate of false negatives, leading to missed safety events). A poorly designed “THEN” clause will deliver a confusing or unactionable message, ensuring it gets overridden even when it’s correct. Mastering the art of writing clean, specific, and clinically relevant logic is the core technical skill of our profession.

5.2.3 Masterclass on Triggers: Deconstructing the “IF” Clause

The “IF” clause is where the magic happens. It is where you define, with surgical precision, the exact clinical scenario you want to target. Building a robust “IF” clause is an exercise in defensive design; your goal is not just to identify the problem, but to exclude all the scenarios where the problem doesn’t actually exist. This is the primary mechanism by which we combat alert fatigue. The trigger is built by combining fundamental building blocks: data elements, operators, and values, all tied together with logical connectors.

Masterclass Table: Building Blocks of a CDS Trigger
Building Block Description Simple Example Advanced Example (Combining Blocks)
Data Element A single piece of discrete, coded data from the EHR. This is the variable in your logical equation. `Patient Age`, `Ordered Medication`, `Latest Serum Potassium`, `Allergy List`, `Problem List` N/A
Operator A symbol or word that defines the relationship or comparison for a data element. `>`, `<`, `=`, `≠`, `contains`, `is a member of`, `starts with` `Patient Age` > `65`
`Latest Serum Potassium` ≥ `5.5`
Value The specific, constant value that the data element is being compared to. This can be a number, a string of text, or a concept from a standardized terminology. `65`, `”Lisinopril”`, `”Penicillins”` (a defined group), `SNOMED-CT: 38341003` (Hypertension) `Ordered Medication` = `”Lisinopril”` (where “Lisinopril” is an RxNorm concept)
Single Condition (Boolean Statement) A complete logical statement combining a data element, an operator, and a value. Every single condition must evaluate to either TRUE or FALSE. `Patient Age > 65` (This is either true for the patient, or it is false). N/A
Logical Connector (AND, OR, NOT) Used to combine multiple single conditions to create a more specific and nuanced trigger. This is how we build complex logic. AND: All connected conditions must be true.
OR: At least one of the connected conditions must be true.
NOT: The specified condition must be false.		 (`Ordered Medication` = “Spironolactone” AND `Latest Serum Potassium` > 5.0)
OR
(`Ordered Medication` = “Lisinopril” AND `Latest Serum Potassium` > 5.0)
AND NOT (`Patient is on Dialysis`)
The Cardinal Sin: Using Free Text in Logic

You cannot build reliable, scalable CDS on a foundation of free text. A computer cannot reliably interpret a physician’s typed note that says “patient’s kidney function is poor” or “Cr is high.” It needs discrete, coded data. The system must be able to look at a specific field in the EHR for the `Serum Creatinine` (identified by its LOINC code) and compare its numerical value to another number.

As an informatics pharmacist, you will be a relentless advocate for structured documentation. When you are asked to build a rule based on a concept that is only documented in free text, your first response should be, “We can’t build a reliable rule for that until we create a discrete field or flowsheet to capture that data.” This is a critical part of ensuring data quality and building a safe system.

Adding the Fourth Dimension: The Power of Temporal Logic

Clinical medicine is not static; it unfolds over time. An effective CDS must also understand the concept of time. It’s often not enough to know *if* a lab was high; you need to know *when* it was high. Was it high an hour ago, or a year ago? Temporal logic allows us to incorporate this crucial dimension into our “IF” clauses, making them infinitely more intelligent and clinically relevant.

Masterclass Table: Common Temporal Operators in CDS
Temporal Operator Logic Clinical Pharmacy Example
WITHIN LAST [timeframe] The condition must have been true at some point during the specified lookback period. `IF` the patient has an order for an aminoglycoside `AND` there is `NOT` a Serum Creatinine result `WITHIN THE LAST 48 HOURS`, `THEN` create a task for the pharmacist to recommend follow-up labs.
FIRST IN [timeframe] The condition is true only if this is the first time it has occurred within the specified lookback period. `IF` this is the `FIRST IN 90 DAYS` that the patient has received an opioid order, `THEN` display educational material about safe opioid use and risks. (This defines an “opioid-naive” patient).
[Event A] BEFORE [Event B] The rule only fires if Event A occurred chronologically before Event B. `IF` an order for broad-spectrum antibiotics is signed `AND` blood cultures were `NOT` drawn `BEFORE` the antibiotic order was signed, `THEN` display a reminder to the nurse to obtain cultures as soon as possible.
FOR AT LEAST [duration] The patient must have been in a certain state (e.g., on a medication) for a continuous period of time. `IF` a patient has been on an ACE inhibitor `FOR AT LEAST 6 WEEKS` `AND` does `NOT` have a documented potassium level since starting the medication, `THEN` recommend a follow-up BMP.
VALUE HAS CHANGED BY [amount/percent] The rule triggers based on the delta, or change, in a value over time, rather than a single absolute value. `IF` the patient’s Serum Creatinine `HAS INCREASED BY > 50%` from their baseline value `WITHIN THE LAST 72 HOURS`, `THEN` trigger an AKI (Acute Kidney Injury) alert and suggest a pharmacist review of their medication regimen.
From Clinical Thought to Advanced Pseudo-Code: A Practical Walkthrough

Let’s upgrade our previous colchicine example with more specificity and temporal logic to make it even smarter.

Upgraded Clinical Concern: “I want to prevent fatal colchicine toxicity. The rule should fire for patients with both a strong CYP3A4 inhibitor interaction AND renal dysfunction. However, I want to be even smarter. A stable patient with chronic kidney disease (CKD) is different from a patient with a new, acute kidney injury. Also, I don’t want the alert to fire if a pharmacist has already documented that they’ve addressed this issue.”

IF

(New Medication Order = “Colchicine”)

AND (Patient’s Active Medication List CONTAINS a member of Drug Group “Strong CYP3A4 Inhibitors”)

AND (

(Patient’s Latest eGFR WITHIN LAST 1 YEAR is < 30)

OR (Patient’s Latest eGFR has DECREASED BY > 25% from baseline WITHIN LAST 7 DAYS)

)

AND NOT

(There is a Pharmacist Intervention Note WITHIN LAST 24 HOURS that CONTAINS the text “colchicine DDI addressed”)

THEN

Display “Soft Stop” Alert to Prescriber with the following text:

“CRITICAL INTERACTION & RENAL RISK: Combining Colchicine with [Name of Interacting Drug] in patients with renal dysfunction may be fatal.
Patient has evidence of [Chronic Kidney Disease/Acute Kidney Injury].
Recommendation: AVOID COMBINATION. Consider alternative therapy.”

ELSE

Do nothing.

Notice the improvements: We are now checking for both chronic (low eGFR over the last year) and acute (a recent significant drop) kidney injury. Most importantly, we added a `NOT` condition that prevents the alert from firing if a pharmacist has already seen and handled the issue, respecting the workflow and preventing redundant interruptions. This is how we build intelligent, context-aware CDS.