🔔 Clinical Decision Support Rule Engine Builder Simulator

Condition Modeling — Encoding Clinical Triggers and Binding to Terminology Standards

Every CDS rule begins as a set of atomic, machine-readable clinical facts: a lab value crossing a threshold, a medication actively on the patient's list, a diagnosis code on the problem list, a vital sign out of range, an order in flight. Before any logic can be composed, each of these facts must be bound to a standardized terminology so the rule fires consistently regardless of which lab analyzer, pharmacy system, or coding convention produced the underlying data.

• 100k+: LOINC codes in active use (laboratory & observation identifiers)
• ~275k: RxNorm normalized concepts (ingredient, brand, and clinical drug forms)
• 350k+: SNOMED CT concepts (US ed.) (diagnoses, findings, procedures)
• 2–5%: Local-to-standard mapping error (typical unmapped or misclassified codes)

Atomic condition types and their EHR data sources

A condition node in a CDS rule is a single testable predicate against the patient's current data state. In practice these fall into a small number of recurring categories:

• Laboratory results: numeric or coded observations (Creatinine, Potassium, INR, WBC) evaluated against a threshold, delta, or trend — sourced from FHIR Observation resources or HL7v2 OBX segments • Medication orders / active med list: presence, dose, or route of a drug — sourced from FHIR MedicationRequest / MedicationStatement resources, matched by RxNorm ingredient or class • Diagnoses / problem list: active or historical condition codes — sourced from FHIR Condition resources, matched by SNOMED CT or ICD-10-CM • Demographics and encounter context: age, sex, encounter type, care setting, allergy list • Orders in flight: what the clinician is about to sign — the trigger payload for order-time CDS Hooks such as order-select and order-sign

In the classic Arden Syntax formalism (HL7 standard since 1989), each of these sources is pulled into a Medical Logic Module's "data" slot using a curly-brace query against the institution's Arden Syntax Mapping (the local dictionary connecting {creatinine} to the actual lab interface code).

Terminology binding — why local codes fail at population scale

A rule authored against one hospital's internal lab code for serum creatinine will silently stop firing the moment a merger brings in a second lab vendor with different internal codes. Terminology binding solves this by mapping every local code to a canonical, vendor-neutral identifier before rule logic ever sees it:

• LOINC (Logical Observation Identifiers Names and Codes): the universal identifier for laboratory and clinical observations — a Creatinine result is always LOINC 2160-0 regardless of instrument or lab information system • RxNorm: normalizes the thousands of NDC package codes, brand names, and formulations for a given drug down to a small set of clinical drug concepts, so "on Warfarin" matches Coumadin, Jantoven, and generic warfarin sodium tablets alike • SNOMED CT: a polyhierarchical ontology where subsumption queries let a rule for "chronic kidney disease" automatically match any more specific descendant concept (CKD stage 3, stage 4, ESRD) without enumerating every code by hand

Mapping tables are curated by clinical informaticists and must be versioned and revalidated whenever a source system upgrades — an unnoticed mapping break is one of the most common silent-failure modes in production CDS, because the rule keeps running, it simply never matches anyone.

Threshold definition and clinical evidence sourcing

Numeric thresholds embedded in condition nodes are not arbitrary — each should trace back to a cited clinical guideline (KDIGO staging criteria for AKI, ACC/AHA thresholds for anticoagulation risk, institutional formulary policy) and be reviewed by a pharmacy and therapeutics or CDS governance committee before deployment.

Common pitfalls in threshold definition include unit mismatches (mg/dL vs. µmol/L for creatinine), reference range drift between lab instrument generations, and copy-pasted thresholds that were never validated against the local patient population's baseline distribution. Every threshold in this simulator's condition library — Creatinine > 2.0 mg/dL, eGFR < 30 mL/min, INR > 3.5 — mirrors published renal-dosing and anticoagulation-safety literature, the same standard a real rule-authoring workflow is expected to meet.

Logic Composition — Combining Conditions with AND / OR / NOT and Tuning Specificity

Once atomic conditions exist, they must be assembled into a boolean expression that captures the actual clinical scenario the rule is meant to catch. The shape of that expression tree — how many conditions are ANDed together, how permissive the OR branches are — is the single biggest determinant of whether a rule behaves usefully or becomes a source of alert fatigue.

• 2–4: Typical production rule depth (nested AND / OR levels)
• HL7, 1989: Arden Syntax MLM standard (data / logic / action knowledge slots)
• 9: CDS Hooks trigger types (patient-view, order-select, order-sign, …)
• tradeoff: Sensitivity vs. specificity (moving along the rule's ROC curve)

Boolean composition inside Arden Syntax Medical Logic Modules

An Arden Syntax MLM is organized into three knowledge slots that map directly onto the condition → logic → action pipeline this simulator visualizes:

• maintenance slot: authorship, version, institution — the provenance record required for governance audit • library slot: purpose, keywords, links to the supporting clinical citation • knowledge slot: data (condition bindings), logic (the boolean evaluation, e.g. "if creatinine_read is present and creatinine_read > 2.0 and egfr_read < 30 then conclude true"), and action (what fires when logic evaluates true)

The logic slot is where AND / OR / NOT composition happens explicitly. AND-ing two conditions narrows the trigger population — only patients matching every branch fire the rule. OR-ing conditions widens it — any single branch is sufficient. NOT is used to explicitly exclude a subgroup (e.g., "AND NOT already on renal dosing protocol") to prevent redundant re-alerting on a problem already being managed.

CDS Hooks and FHIR-based real-time triggers

Modern rule engines increasingly implement logic composition through the CDS Hooks specification rather than (or alongside) legacy Arden Syntax. CDS Hooks defines a small set of standardized trigger points in the clinical workflow — patient-view (chart opened), order-select (an order is being built), order-sign (about to be signed), medication-prescribe — at which the EHR calls out to an external or embedded CDS service.

Each hook call includes a "prefetch" template: a set of FHIR queries the EHR resolves before invoking the rule, bundling exactly the Observation, MedicationRequest, and Condition resources the rule's logic tree needs. This decouples rule authoring from any single EHR vendor's internal data model — the same rule logic, expressed against FHIR resources, can run inside Epic, Cerner/Oracle Health, or any CDS Hooks-compliant system, returning a standardized "card" containing the suggestion, its rationale, and (optionally) a pre-built order to accept.

Specificity tuning — moving along the false-positive / false-negative tradeoff

The rule specificity slider in this simulator models a real and unavoidable engineering tradeoff. A broad, loosely-ANDed rule (e.g., firing on eGFR < 60 alone) catches nearly every true case but also fires on a large population where the alert is not actually actionable — driving false-positive rate and override fatigue up. A narrow, tightly-ANDed rule (eGFR < 30 AND creatinine > 2.0 AND active nephrotoxic order) fires rarely, but every fire is far more likely to be clinically meaningful — at the cost of missing borderline true cases that don't satisfy every conjunct.

Governing this tradeoff quantitatively typically uses retrospective chart review: run the candidate rule logic against a historical cohort, have clinicians adjudicate each fire as a true or false positive, and plot positive predictive value against sensitivity across candidate threshold combinations before deploying the version that clears the institution's minimum PPV bar (commonly 30–50% for interruptive alerts).

Action Definition — From Passive Alerts to Order Suggestions and Auto-Documentation

A satisfied rule is inert until it is wired to a concrete action. The taxonomy of CDS actions ranges from a hard interruptive stop that blocks workflow, through gentler non-interruptive banners, to fully passive actions like pre-populating documentation — and the choice of action type has as much impact on clinician trust as the underlying logic's accuracy.

• 49–96%: Interruptive alert override rate (literature range for poorly tuned alerts)
• 2–3×: Non-interruptive engagement (higher acceptance vs. interruptive, when relevant)
• 20–40%: Order-suggestion acceptance (when contextually well-targeted)
• 6+: Distinct action types (typical EHR) (hard-stop, soft alert, order set, auto-doc, …)

Interruptive vs. non-interruptive alert design

Interruptive alerts (modal pop-ups that block the workflow until acknowledged) are reserved for the small subset of scenarios with high clinical stakes and high rule specificity — a hard drug allergy contraindication, a critical potassium value. Every interruptive alert imposes a real cognitive and time cost on the clinician, and institutions typically cap the number of hard-stop rules in production to a few dozen.

Non-interruptive alerts — a persistent banner, a sidebar flag, a colored icon on the patient list — carry the same underlying logic but without forcing an immediate decision. They are the default choice for lower-specificity or advisory-only rules, and empirically achieve higher engagement precisely because clinicians do not learn to reflexively dismiss them the way they do with over-fired interruptive alerts.

Order-set suggestions and default order pre-population

Rather than simply informing the clinician of a problem, an order-suggestion action offers a specific, one-click resolution: a "suggest dose adjustment" card that pre-fills the corrected renal dose and route, ready to accept into the order-sign workflow via a CDS Hooks order-sign response. This action type converts a diagnostic finding directly into a workflow-compatible fix, which is consistently associated with the highest acceptance rates of any CDS action category because it minimizes the clinician's marginal effort to comply.

Default order pre-selection goes one step further — rather than suggesting an alternative, the rule silently biases which option is pre-checked in an order set (e.g., defaulting to the renally-adjusted dose in a medication order panel) without an explicit interruption at all.

Auto-documentation and structured contraindication capture

Not every action needs to change clinician behavior — some exist purely to close a documentation gap. An auto-documentation action fires silently in the background, writing a structured note (e.g., "renal dose adjustment considered and declined — see order comment") into the chart whenever the underlying rule logic evaluates true, ensuring the clinical reasoning is captured for quality reporting and medico-legal completeness even when no interruptive action is warranted.

This action class is increasingly important for regulatory quality measures (e.g., CMS eCQMs) that require documented evidence a contraindication was actively considered, not merely that the patient's outcome happened to be acceptable.

Rule Execution — Streaming Patient Data Through Hundreds of Concurrently Active Rules

In production, a large health system runs hundreds to thousands of active CDS rules simultaneously against every patient encounter, every lab result, and every order. The engine must evaluate this entire rule set within a tight latency budget — and, critically, detect when two independently-authored rules fire actions that contradict each other for the same patient.

• 500–2,000+: Active rules, large health system (concurrently enabled)
• millions: Encounters evaluated per day (across all hook trigger types)
• <200 ms: Rule evaluation latency budget (per CDS Hooks service call)
• grows ~n²: Detected conflict pairs (with number of active rules)

Event-driven execution and the rule evaluation engine

Rather than continuously polling every rule against every patient, production CDS engines are event-driven: a new lab result posting, a medication being ordered, or a chart being opened each fire a discrete event that the engine matches against only the subset of rules subscribed to that event type and data domain. This indexing step — matching an incoming HL7 ORU or FHIR Observation-create event to the small set of rules that reference that LOINC code — is what keeps evaluation latency bounded even as the total rule count grows into the thousands.

Once the relevant rule subset is identified, each rule's logic tree is evaluated against the current patient snapshot (as visualized by the patient-data pulses traveling from condition nodes through gates to actions in this simulator), and any rule whose logic resolves true enqueues its associated action for delivery back to the clinician's workflow.

Detecting overlapping and contradictory rule actions

Conflict detection compares the action payloads of every rule that fired for the same patient within the same encounter window, looking for semantic contradiction rather than merely textual duplication. In the graph this simulator draws, "Fire Bleeding-Risk Alert" (triggered when a patient is on warfarin with an elevated INR) and "Suggest Warfarin Continue" (triggered by a separate high-risk-profile rule reasoning about stroke prevention) are a textbook conflict pair: both are individually well-reasoned, but their combined guidance for the same patient is contradictory.

At scale, conflict pairs grow roughly quadratically with the number of active rules, because every newly added rule must be checked against every existing rule's action space for medication-class overlap, opposing directionality (start vs. stop), or duplicate alerting on the same underlying problem. This combinatorial growth is precisely why unmanaged rule sets in large systems accumulate silent contradictions that no single rule author would ever notice in isolation.

CDS Hooks responses can carry a priority and an explicit override-hierarchy hint, but most legacy Arden Syntax and homegrown rule engines have no built-in conflict-resolution layer at all — contradictions are only caught if a governance review process actively looks for them.

Conflict resolution strategies: priority, suppression, consolidation

Once a conflict is detected, engines apply one of several resolution strategies:

• Priority ranking: each rule is assigned a clinical-severity tier; when two rules conflict, only the higher-tier action is surfaced, with the lower-tier action logged but suppressed • Suppression windows: if a semantically similar action already fired for this patient within a defined time window (e.g., 24 hours), a duplicate or contradictory low-priority rule is silently withheld • Consolidation: rather than suppressing one side, the engine merges the conflicting cards into a single composite alert that explicitly surfaces both considerations to the clinician, who is best positioned to weigh a genuine clinical tradeoff • Human-in-the-loop escalation: unresolvable or high-severity conflicts route to a pharmacist or clinical decision support analyst queue for manual adjudication before the rule set's next release

Governance & Optimization — Pruning the Rule Set to Reduce Alert Fatigue

A mature CDS program does not stop at deployment. A standing governance committee — typically informaticists, pharmacists, and frontline clinicians — reviews fire-rate, override-rate, and conflict metrics on a recurring cadence, retiring or retuning underperforming rules. The measurable outcome of this discipline is a rule set that fires less often but is right far more often when it does.

• quarterly: CDS committee review cadence (typical governance cycle, large systems)
• 10–30%: Rules retired per optimization pass (lowest-value or most conflict-prone)
• >90%: Override rate before tuning (documented for poorly-specified alert types)
• <40%: Override rate after tuning (achievable with active governance)

Fire-rate and override-rate review as the governance instrument panel

The core governance metric is the override rate: of every time a rule fired, what fraction did the clinician dismiss without acting on it? An override rate near 100% signals the rule is either miscalibrated (too broad, wrong threshold, stale terminology binding) or targeting a scenario clinicians do not consider actionable at all — both are governance findings, not just tuning parameters.

Dashboards typically stratify override rate by rule, by ordering service line, and by time of day, since alert fatigue compounds — a clinician who has dismissed the same low-value alert forty times in a shift will dismiss the forty-first even if it happens to be the one true positive. Tracking this trend over time is what turns a one-time rule launch into a continuously managed clinical asset.

Retiring, retuning, and consolidating low-value rules

When review identifies a rule with a persistently high override rate and low true-alert yield, governance has three levers: retire it outright, retune its logic (tightening AND conditions, adjusting a threshold, adding an exclusion clause), or consolidate it with an overlapping rule into a single better-specified alert. In this simulator, the "High-Risk Profile" OR-gate and its downstream "Suggest Warfarin Continue" action are the rule pair retired during governance — flagged for both a high conflict rate against the bleeding-risk rule and a low standalone specificity, exactly the profile committees prioritize for retirement.

Rule lifecycle management also requires versioning discipline: every retuned rule needs a change log, a re-validation pass against historical data, and a defined rollback path, since CDS logic errors can silently propagate incorrect guidance across an entire health system's patient population within hours of deployment.

The measured payoff of rigorous rule governance

Systems that implement active, recurring CDS governance consistently report the same pattern: total alert volume falls, true-alert yield holds steady or improves, and false-positive rate drops sharply — precisely the effect visualized by the FPR before/after comparison in this stage. This is not a cosmetic improvement; alert fatigue is a documented contributor to real missed diagnoses, because clinicians desensitized by a high-override-rate rule set are statistically more likely to dismiss the rare alert that actually mattered.

Published literature on drug-drug interaction and dosing alerts has repeatedly documented override rates exceeding 90% for poorly-tuned rule types (van der Sijs et al. and subsequent replications) — a large academic medical center running 500–2,000+ concurrently active CDS rules can generate hundreds of thousands of low-value alert firings per year without governance. Institutions that apply the specificity-tuning and rule-pruning discipline modeled in this simulator have documented override-rate reductions from the 90%+ range down below 40% while holding true-positive alert yield constant — the central return on investment of a CDS governance program.