A Governance and Evaluation Framework for Deterministic, Rule-Based Clinical Decision Support in Empiric Antibiotic Prescribing

This paper proposes a governance and evaluation framework for deterministic, rule-based clinical decision support systems in empiric antibiotic prescribing that prioritizes transparency, auditability, and conservative behavior by formally separating decision logic from scope constraints and utilizing synthetic case validation to ensure behavioral alignment with predefined rules.

The Gist

Imagine you are a chef in a very busy, high-stakes kitchen. You have to cook a meal for a patient who is very sick, but you don't have all the ingredients yet, and you don't know exactly what's wrong with them. You need to guess (make an "empiric" decision) which medicine to give them right away.

If you guess wrong, the patient could get worse, or you might use a "super-weapon" antibiotic that kills good bacteria and creates super-bugs. This is a scary situation.

This paper proposes a new way to build a digital kitchen assistant (a computer program) to help doctors make these guesses. But instead of making the assistant a "smart" AI that learns from experience like a human, the authors built a strict, rule-following robot with a very specific job description.

Here is the breakdown of their idea using simple analogies:

1. The "Traffic Light" System (Governance)

Most computer programs try to be helpful by giving an answer every time, even if they aren't sure. This paper says: "No. Sometimes the right answer is to say nothing."

They created a system where the computer has two layers:

• The Chef (Clinical Logic): This part knows the recipes. It looks at the symptoms and says, "Hey, this looks like a bacterial infection; maybe we need Penicillin."
• The Safety Inspector (Governance): This is the new, most important part. Before the Chef can speak, the Safety Inspector checks the rules.
  • Is the patient's file complete? (If no, Red Light).
  • Is the patient allergic to Penicillin? (If yes, Red Light).
  • Are we trying to use a "super-weapon" antibiotic when a weaker one would do? (If yes, Red Light).

If the Safety Inspector hits the Red Light, the system must stay silent. It doesn't guess. It says, "I cannot recommend anything right now." The authors call this "Abstention," and they treat it as a good thing, not a failure. It's like a pilot refusing to take off in a storm because the checklist isn't 100% green.

2. The "Robot vs. The Oracle" (Determinism)

Many modern AI systems are like Oracles: they look at millions of past cases and guess, "I'm 85% sure this is the right drug." But sometimes they get it wrong, and you can't always tell why.

This paper builds a Robot instead.

• The Rule: If Input A + Input B happens, Output C always happens.
• The Benefit: If you put the same patient data in twice, the robot gives the exact same answer twice. There is no "gut feeling" or "luck."
• The Trade-off: The robot is less "flexible." If a situation is weird and doesn't fit the rules perfectly, the robot won't guess. It will just stop and ask for more info. The authors prefer this "boring" safety over "exciting" but risky guessing.

3. The "Video Game Level" (Evaluation)

How do you test if this robot is working? Usually, you test a new drug on real patients to see if they get better. But you can't do that with a safety system yet; it's too risky.

So, the authors created a Video Game Level for testing.

• They invented 100 fake patients with specific, tricky scenarios.
  • Scenario A: "Patient has missing data." (Expected result: Robot says "I can't help.")
  • Scenario B: "Patient needs a narrow-spectrum drug, but the robot suggests a broad one." (Expected result: Robot says "No, that's against the rules.")
• They run the robot through these fake levels. If the robot follows the rules perfectly every time, it passes. They aren't testing if the robot saves lives yet; they are testing if the robot follows the rulebook without cheating.

4. Why Do This? (The Big Picture)

The authors argue that in high-risk medical situations (like giving antibiotics), safety and transparency are more important than being "smart."

• Old Way: "The AI thinks it's a 90% match, so let's give the drug." (What if the AI is wrong? We don't know why.)
• New Way: "The AI checked the rules. The rules said 'Stop' because we are missing a lab result. So, the AI stopped." (We know exactly why it stopped, and we know it's safe.)

Summary

Think of this framework as a strict bouncer at a very exclusive club.

• The bouncer (the Governance System) doesn't care if you are a famous doctor or a VIP.
• If you don't have your ID (missing data) or if you are trying to bring in a banned item (unsafe antibiotic), the bouncer says, "No entry."
• The bouncer never guesses, never changes their mind, and never lets anyone in unless the rules are 100% met.

The paper is essentially a blueprint for building these kinds of strict, unshakeable, rule-following assistants, ensuring that when they do speak, we can trust them completely because they never break their own rules.

Technical Summary

Based on the paper provided, here is a detailed technical summary of the proposed Governance and Evaluation Framework for Deterministic, Rule-Based Clinical Decision Support (CDSS) in empiric antibiotic prescribing.

1. Problem Statement

Empiric antibiotic prescribing in high-risk clinical contexts often occurs under conditions of incomplete information (before microbiological confirmation). This creates a critical tension between the need for timely treatment and the risks of inappropriate coverage or unjustified antibiotic escalation, which compromise patient safety and antimicrobial stewardship.

While Clinical Decision Support Systems (CDSS) have been proposed to assist clinicians, existing approaches often suffer from:

• Lack of Explicit Governance: They frequently fail to define the specific conditions under which recommendations are permissible or when the system must abstain.
• Opacity: Many systems rely on probabilistic inference or statistical learning, making decision pathways difficult to trace or audit.
• Uncontrolled Extrapolation: Systems may generate recommendations even when safety constraints or information completeness are not met, prioritizing coverage over safety.
• Evaluation Gaps: Current evaluation methods often focus on clinical outcomes or predictive accuracy rather than verifying that the system adheres to its defined governance rules and scope.

2. Methodology

The authors propose a Governance and Evaluation Framework designed specifically for deterministic, rule-based CDSS. The methodology is built on three core pillars:

A. Architectural Design: Separation of Concerns

The system architecture explicitly separates Clinical Decision Logic from Governance Mechanisms.

• Clinical Logic: Encodes conditions for appropriate antibiotic classes within a strictly defined scope.
• Governance Layer: Acts as a gatekeeping mechanism that determines if a recommendation is permissible based on input completeness, safety constraints, and stewardship rules.
• Determinism: The system is strictly deterministic; identical inputs always yield identical outputs. It avoids probabilistic inference, statistical learning, or adaptive mechanisms to ensure transparency and reproducibility.

B. Governance Constructs

The framework formalizes three core governance constructs as "first-class" design components:

1. Explicit Abstention Typology: Abstention (not making a recommendation) is treated as a correct, intended outcome rather than a failure. It is categorized into specific classes:
   • Missing inputs: Required data is absent.
   • Unknown risk: Contextual risks cannot be assessed within the scope.
   • Conflicting signals: Inputs activate mutually incompatible rules.
   • Explicit exclusions: The case falls under a predefined exclusion criterion.
   • Conservative ambiguity: Residual uncertainty persists, triggering a conservative non-recommendation.
2. Deterministic Stewardship Constraints: Hard rules that enforce antimicrobial stewardship (e.g., preference for narrow-spectrum antibiotics, prohibition of unjustified escalation). These act as veto mechanisms regardless of clinical logic.
3. Explicit Exclusion Rules: Formal definitions of contexts where the system is designed to abstain (e.g., outside the defined scope or unresolved complexity).

C. Evaluation Protocol

Instead of testing on real patient data or measuring clinical outcomes, the framework utilizes a mechanism-driven evaluation approach:

• Synthetic Cases: A fixed, versioned set of synthetic clinical cases is used. These are not representative of real-world epidemiology but are engineered to isolate specific decision pathways (e.g., triggering a specific exclusion rule or stewardship constraint).
• Expected Behavior: Each synthetic case has a predefined "expected behavior" (Recommendation vs. Abstention, and specific antibiotic class if applicable).
• Metric: The primary metric is Expected-Behavior Concordance (the proportion of cases where the system output matches the predefined expectation).
• No Statistical Inference: The evaluation does not use hypothesis testing or outcome-based validation; it strictly verifies behavioral alignment with specified rules.

3. Key Contributions

1. Formalized Governance Layer: The paper specifies a governance layer that separates "what to recommend" from "whether it is permissible to recommend," treating governance as a structural architectural component rather than a post-hoc filter.
2. Abstention as a Feature: It redefines abstention not as a system failure but as a correct, auditable, and intentional output when governance conditions are unmet.
3. Reproducible Evaluation Framework: It introduces a methodology for inspecting system behavior using fixed synthetic cases, enabling rigorous auditing of rule activation without reliance on clinical outcome data.
4. Deterministic Safety Model: It establishes a design philosophy where transparency, traceability, and conservative behavior (avoiding silent generalization) take precedence over predictive coverage.

4. Results

Note: As this is a methodological paper proposing a framework rather than a clinical trial, the "results" refer to the validation of the framework's logic and the demonstration of its operational capabilities.

• Behavioral Alignment: The framework successfully demonstrated that by separating governance from clinical logic, the system could consistently trigger abstention when inputs were incomplete or conflicting, preventing unsafe extrapolations.
• Traceability: Every system output (recommendation or abstention) could be directly traced to a specific rule activation, ensuring full auditability.
• Stewardship Enforcement: The deterministic constraints effectively vetoed broad-spectrum recommendations when narrow-spectrum options were permissible, enforcing stewardship rules structurally rather than heuristically.
• Reproducibility: Repeated execution of the evaluation script over the fixed synthetic case set yielded identical outputs, confirming the system's deterministic nature.

5. Significance and Implications

• Safety in High-Stakes Contexts: The framework addresses the critical need for CDSS in high-risk scenarios (like antibiotic prescribing) where "black box" AI or probabilistic models pose safety risks due to unpredictable extrapolation.
• Regulatory and Audit Readiness: By prioritizing explicit specification and traceability, the framework aligns with regulatory requirements for explainability and auditability in medical devices.
• Shift in Evaluation Paradigm: It challenges the standard reliance on outcome-based validation for rule-based systems, arguing that for deterministic systems, verifying behavioral alignment with rules is a necessary and distinct step before clinical deployment.
• Methodological Template: The paper provides a reproducible template for developing conservative, policy-aligned decision support systems. It acknowledges that while it sacrifices the coverage and adaptability of machine learning, it gains essential safety, transparency, and control, making it suitable for contexts where clinical guidelines are strict and justification is mandatory.

Limitations Acknowledged: The authors explicitly state that the framework does not provide clinical validation (no real patient data), is not adaptive (no learning), and is narrowly scoped to empiric antibiotic prescribing. It is a specification and evaluation construct, not a deployable clinical system in itself.