The Inference Gap: Red Door's Context-Aware Clinical Decision Support for Multi-Morbidity Patients

Multi-morbidity patients—those living with two or more chronic conditions—are the norm in internal medicine, yet most clinical decision support systems (CDSS) are built around single-disease guidelines. The result is an inference gap: alerts that contradict each other, drug-disease interactions that go unnoticed, and recommendations that would be appropriate for one condition but harmful for another. Red Door's context-aware CDSS framework aims to close that gap by reasoning over the patient's full clinical picture rather than firing isolated rules. This guide is for clinical informaticists, CDSS architects, and quality improvement leads who need a practical, workflow-oriented approach to building or retrofitting decision support for multi-morbidity populations.

We assume you already understand basic CDSS architecture (rules engines, trigger events, alert fatigue). What we cover here is how to move from single-condition logic to a context-aware inference layer that weighs competing guidelines, reconciles contradictory alerts, and presents a coherent recommendation set. The focus is on actionable steps, tooling trade-offs, and the failure modes that emerge when you try to scale context-aware logic across a real patient panel.

Why the Inference Gap Hurts Multi-Morbidity Care

A 70-year-old with type 2 diabetes, heart failure with reduced ejection fraction, and stage 3 chronic kidney disease walks into a clinic. A diabetes CDSS might flag metformin as first-line; a heart failure CDSS might recommend an SGLT2 inhibitor; a CKD CDSS might warn about contrast-induced nephropathy if imaging is ordered. Each alert is correct in isolation. Combined, the patient receives three conflicting or overlapping recommendations, and the clinician must manually reconcile them—often under time pressure. That manual reconciliation is the inference gap.

The harm is not just annoyance. Studies across health systems suggest that clinicians override 70–90% of CDSS alerts, and override rates are highest for patients with multiple conditions. When alerts contradict each other, trust erodes. The system becomes noise, and genuine safety signals get buried. For the multi-morbidity patient, the result is fragmented care: duplicated medications, missed drug-disease interactions, and guideline-concordant care for one condition at the expense of another.

Red Door's approach treats the patient as a single inference subject rather than a collection of disease-specific rule triggers. Instead of firing individual rules and letting the clinician sort out conflicts, the context-aware layer evaluates all active conditions, current medications, recent labs, and care goals together. It then produces a ranked set of recommendations with explicit trade-offs: 'Given the patient's CKD stage 3 and heart failure, consider an SGLT2 inhibitor over metformin, but monitor eGFR monthly.' The clinician still makes the final call, but the system surfaces the reasoning behind the ranking.

This shift—from rule-firing to inference—requires changes in data model, rule architecture, and user interface. The rest of this guide details how to implement that shift in practice.

Prerequisites: What You Need Before Building Context-Aware Logic

Before you write a single inference rule, you need a data foundation that can represent multi-morbidity patients accurately. Most CDSS deployments pull from an EHR via HL7 v2 messages or FHIR resources, but the way conditions, medications, and labs are structured matters enormously for context-aware reasoning.

Structured Problem List with Temporal Granularity

A free-text problem list is insufficient. You need coded diagnoses (ICD-10 or SNOMED) with onset dates, resolution dates, and an indication of whether the condition is active, resolved, or historical. For multi-morbidity patients, the interaction between conditions often depends on their time course: a patient with recent-onset heart failure and long-standing diabetes may need different medication adjustments than someone with stable heart failure for five years. Your data model must support temporal queries like 'conditions active in the last 90 days' or 'conditions with onset before the index date.'

Medication Reconciliation with Indications

Knowing what a patient is taking is not enough. You need to know why each medication was prescribed—which condition it targets, and whether it is being used off-label. This allows the inference engine to detect when a medication for one condition exacerbates another (e.g., NSAIDs for osteoarthritis worsening heart failure). If your EHR does not capture indication at the medication order level, you may need to infer it from the problem list and encounter diagnosis, which adds uncertainty. We recommend flagging inferred indications as such in the CDSS output.

Lab Trends, Not Just Last Value

Context-aware CDSS should evaluate lab trends, not just the most recent result. A creatinine that jumped from 0.9 to 1.4 over three months is more significant than a stable 1.4. Your data pipeline must store at least the last 12 months of lab results with timestamps, and your inference engine should compute slopes or moving averages. This is especially important for eGFR, HbA1c, potassium, and liver enzymes—common interaction points in multi-morbidity patients.

Care Goals and Patient Preferences

Guidelines assume aggressive targets, but many multi-morbidity patients have palliative or quality-of-life goals. Your CDSS needs a way to capture care goals—either through structured EHR fields (e.g., advance care planning documentation) or through a pre-visit questionnaire. Without this, the inference engine may recommend aggressive glycemic control that increases hypoglycemia risk in a frail elderly patient. Red Door's framework includes a 'goal alignment' score that adjusts recommendation strength based on documented patient preferences.

If your current data infrastructure lacks any of these elements, you have two options: enrich the data model before building inference logic, or build a lighter version that works with available data and clearly communicates its limitations. The latter is faster but risks perpetuating the inference gap. We generally recommend investing in data model improvements first, especially if you plan to scale context-aware CDSS across multiple clinics or patient populations.

Core Workflow: Building a Context-Aware Inference Layer

The inference layer sits between your rule base and the alert display. Its job is to take all triggered rules, evaluate them against the patient's full context, and produce a consolidated recommendation set. Here is a step-by-step workflow that Red Door teams use.

Step 1: Rule Triggering with Context Tags

Each rule in your CDSS should be tagged with metadata: the condition(s) it targets, the medications it involves, the lab thresholds it checks, and the strength of evidence (e.g., guideline-based, expert opinion, local protocol). When a patient encounters a trigger event (new lab, new medication order, new diagnosis), all relevant rules fire simultaneously. But instead of sending individual alerts to the UI, the system passes them to the inference engine as a batch.

Step 2: Conflict Detection and Prioritization

The inference engine scans the batch for conflicts: rules that recommend mutually exclusive actions (e.g., start beta-blocker vs. avoid beta-blocker due to asthma), rules that recommend the same action for different reasons (duplicate alerts), and rules that interact through a shared medication or lab. It then applies a prioritization matrix based on three factors: clinical urgency (immediate harm vs. long-term benefit), evidence strength, and goal alignment. Conflicts are not resolved automatically—they are surfaced with a priority score and a plain-language explanation of the trade-off.

Step 3: Composite Recommendation Generation

For each conflict group, the engine generates a composite recommendation. For example: 'Recommend starting an SGLT2 inhibitor for heart failure and diabetes management. Consider reducing the sulfonylurea dose to prevent hypoglycemia. Monitor potassium and eGFR in 2 weeks.' The composite recommendation includes a rationale that references the specific conditions, medications, and labs that drove the decision. This rationale is critical for clinician trust—without it, the composite alert feels like a black box.

Step 4: User Interface Presentation

The composite recommendations appear in a dedicated section of the CDSS interface, separate from single-rule alerts. Each recommendation shows its priority level (high, medium, low), the conditions it addresses, and a 'view rationale' link that expands the inference trace. Clinicians can accept, modify, or dismiss the recommendation, and their action is logged for future refinement. The goal is to reduce cognitive load: instead of sorting through five conflicting alerts, the clinician sees one prioritized recommendation with a clear justification.

Tools and Environment: What You Need to Run Context-Aware CDSS

Building a context-aware inference layer is not a purely software problem—it also depends on your clinical environment, integration architecture, and team skills. Here are the key considerations.

Rule Engine vs. Inference Engine

Traditional CDSS uses a rules engine (e.g., Drools, CQL engine) that evaluates conditions and fires actions. For context-aware CDSS, you need an inference engine that can reason over multiple rules simultaneously. Options include: (a) a Bayesian network that computes conditional probabilities for each recommendation given the patient's features; (b) a weighted scoring system that sums evidence for each possible action and ranks them; (c) a logic-based system using first-order logic or answer set programming. Most teams start with weighted scoring because it is simpler to explain to clinicians and easier to debug. Bayesian networks offer better handling of uncertainty but require more data to calibrate.

Integration with EHR and Clinical Workflow

Context-aware CDSS requires real-time or near-real-time access to patient data. A FHIR-based integration is ideal because it provides standardized access to conditions, medications, labs, and observations. If your EHR only supports HL7 v2, you will need a middleware layer that transforms messages into a unified patient state. Latency matters: if the inference engine takes more than a few seconds to compute, clinicians will not wait. Cache patient context when possible and update it incrementally as new data arrives.

Team Composition

You need at least three roles: a clinical informaticist who understands multi-morbidity care and can define conflict resolution rules; a data engineer who can build the patient context pipeline; and a software developer who can implement the inference engine and integrate it with the CDSS UI. If your organization has a clinical decision support committee, involve them early to validate the prioritization matrix—otherwise, clinicians may reject the composite recommendations as 'dumbing down' their decision-making.

Testing and Validation Environment

Before deploying to production, create a test set of 50–100 de-identified multi-morbidity patient records. Run your inference engine on each case and have a panel of clinicians review the composite recommendations for appropriateness, completeness, and safety. Expect to iterate: the first version will likely miss some interactions or over-prioritize certain conditions. Use the panel's feedback to adjust the prioritization weights and conflict detection rules.

Variations for Different Constraints

Not every organization can build a full inference engine from scratch. Here are three common constraint scenarios and how to adapt the approach.

Limited Data Quality: The Incremental Path

If your problem list is incomplete or medication indications are missing, do not attempt full context-aware inference. Instead, start with a simpler module that detects only the most common drug-disease interactions (e.g., NSAIDs in heart failure, metformin in advanced CKD). Use a lookup table rather than a full inference engine. Tag these alerts as 'limited context' so clinicians know the system is not considering the full picture. As you improve data quality, expand the module to cover more interactions.

Small Team: Leverage Open-Source Tools

Open-source CDSS platforms like OpenCDS or the CQL execution engine from the HL7 community can be extended with a simple scoring layer. Write a Python or Java service that receives triggered rules as JSON, evaluates them against a patient context object, and returns ranked recommendations. This is much faster than building a custom inference engine from scratch. The trade-off is that you have less control over performance and may need to optimize the patient context retrieval for speed.

High Alert Volume: Focus on High-Priority Conflicts

If your CDSS already generates hundreds of alerts per patient per visit, adding a context-aware layer could slow things down. In that case, limit inference to the top 5% of patients by complexity (e.g., those with 4+ chronic conditions and 10+ medications). For simpler patients, fall back to the traditional rule-based system. The inference engine can be triggered only when the patient's complexity score exceeds a threshold. This preserves performance while targeting the population that benefits most.

Pitfalls and Debugging: What to Check When It Fails

Context-aware CDSS is not a set-and-forget system. Here are the most common failure modes and how to diagnose them.

The Black Box Problem

Clinicians will distrust composite recommendations if they cannot see the reasoning. Always provide a trace: which rules fired, what conflicts were detected, and how the prioritization matrix resolved them. If clinicians override a recommendation, log their reason and use it to refine the inference logic. A high override rate for a specific conflict type indicates that your prioritization weights are misaligned with clinical practice.

Missing Context Due to Data Latency

If the inference engine uses stale lab results or outdated problem lists, it will produce incorrect recommendations. Monitor the age of the patient context at the time of inference. Set a threshold (e.g., context must be updated within the last 24 hours) and flag recommendations based on older data. This is especially important for lab trends: a 3-month-old creatinine is not useful for adjusting a medication dose.

Over-Prioritization of One Condition

In the early versions, the inference engine may consistently prioritize one condition (e.g., diabetes) over others (e.g., heart failure) because the evidence strength for diabetes guidelines is higher. This creates a new form of bias. Audit the recommendation distribution across conditions periodically. If one condition dominates, adjust the prioritization weights to give more weight to conditions with higher severity or patient-reported impact.

Alert Fatigue from Composite Alerts

If every patient generates a composite recommendation, clinicians may start ignoring them. Set a minimum priority threshold: only show composite recommendations that are medium or high priority. Low-priority recommendations can be logged for review during the next visit or summarized in a monthly report. Also, avoid showing composite recommendations for patients with only one active condition—the inference layer adds no value there.

Frequently Asked Questions and Common Mistakes

Q: Can we use machine learning instead of rule-based inference? A: Machine learning models can predict recommended actions, but they require large labeled datasets that are rare in multi-morbidity CDSS. They also lack explainability, which is critical for clinician trust. We recommend starting with a rule-based or scoring approach and adding ML only for specific sub-problems, such as predicting which patients are likely to experience a drug-drug interaction.

Q: How do we handle patient preferences that change over time? A: Store care goals with an effective date range. Re-evaluate the goal alignment score each time the inference engine runs. If a patient's goals change (e.g., from aggressive treatment to comfort care), the inference engine should automatically adjust recommendation priorities. This requires a workflow for updating goals in the EHR, which may involve nursing or care coordination.

Q: What if two guidelines directly contradict each other? A: This happens more often than you think. For example, some heart failure guidelines recommend beta-blockers, while COPD guidelines caution against them in severe cases. The inference engine should surface the contradiction explicitly and present both options with the evidence supporting each. Do not try to resolve the contradiction automatically—leave the decision to the clinician, but provide a summary of the trade-offs (e.g., 'Beta-blockers reduce heart failure mortality but may worsen COPD symptoms. Consider a cardioselective beta-blocker with close monitoring.').

Common mistake: building the inference engine in isolation from the clinical team. The prioritization matrix must reflect real clinical judgment, not just literature review. Involve a multi-specialty panel (primary care, cardiology, endocrinology, nephrology) to review and calibrate the weights. Another mistake: not testing with real patient data early. Synthetic data often misses the messy edge cases—like a patient with a condition that is documented in a note but not on the problem list. Run a pilot with live data in a test environment as soon as possible.

Finally, do not forget about performance. Context-aware inference adds computational overhead. Profile your inference engine under realistic load (e.g., 50 concurrent patient sessions). Optimize the patient context retrieval by caching frequently accessed data (e.g., problem lists, medication lists) and using incremental updates rather than full reloads for each inference call.

Next Steps: From Pilot to Production

If you are ready to move forward, here are five specific actions to take this quarter.

First, audit your current data model for the prerequisites we covered: structured problem lists, medication indications, lab trends, and care goals. Identify the gaps and create a data enrichment roadmap. Even if you cannot fix everything at once, prioritize the elements that affect the most common multi-morbidity interactions in your patient population.

Second, assemble a clinical advisory group of 3–5 physicians who regularly treat multi-morbidity patients. Schedule two 90-minute workshops: one to define the prioritization matrix (what conditions and interactions matter most) and one to review the first version of composite recommendations against real patient cases. Their feedback will save you months of rework.

Third, build a minimal viable inference engine using a weighted scoring approach. Integrate it with your existing CDSS in a test environment. Use 20–30 de-identified patient records to validate that the engine produces sensible recommendations and that the rationale traces are understandable. Do not aim for perfection—aim for 'better than the current single-rule alerts.'

Fourth, run a small pilot in one clinic or department. Monitor override rates, clinician satisfaction (via a brief survey after each visit), and the number of composite recommendations shown per patient. Set a target: for example, reduce the total number of alerts per multi-morbidity patient by 30% while increasing the acceptance rate of high-priority recommendations by 20%.

Fifth, plan for iterative refinement. After the pilot, review the logged override reasons and adjust the prioritization weights. Add new conflict detection rules for interactions that the pilot revealed. Expand the pilot to a second clinic with a different patient mix (e.g., a geriatrics clinic vs. a cardiology clinic) to test generalizability. Context-aware CDSS is not a one-time build—it is a continuous improvement cycle that evolves with your patient population and the evidence base.

Closing the inference gap for multi-morbidity patients is one of the highest-impact improvements you can make to your CDSS. The work is not trivial, but the payoff—better care decisions, reduced alert fatigue, and higher clinician trust—justifies the investment. Start small, involve clinicians early, and iterate based on real-world feedback.