Why AI CDSS Does Not Reach Production Operation
An AI CDSS prototype almost always looks convincing: on historical datasets, the recommendation matches the physician's decision in most cases, and the metrics on the test set look stable.
The problem begins at the stage of implementing AI CDSS in a live clinic — there the system works not with a clean dataset but with what is actually recorded in the charts, and clinical decision support turns into a set of contradictory signals. We analyze why this happens and how it is addressed.
The first bottleneck in implementation is medical data quality.
Drug dictionaries, laboratory results, orders, and examination text reside in different systems: codes diverge, dosages and units of measurement are written in free text, and some significant signs do not make it into structured fields at all.
Until data is brought to a unified form and checked for completeness, any clinical decision support relies on noise — and issues confident recommendations where there is no input data for them.
Second — response time at the moment of the appointment. A recommendation makes sense only before a decision is made: while the physician is with the patient and formulating a hypothesis.
If the answer comes with a delay, the physician either does not wait and acts according to protocol, or closes the interface and never returns to it.
Hence the rule: heavy checks are computed in advance; at the moment of the appointment, only what fits within the waiting budget is executed.
Third — blurred responsibility for the recommendation. Boundaries must be fixed in advance: the system suggests, the physician makes the decision, but the verifiable trigger rules for the recommendation, the dictionary version, and the input data must be logged.
Then case review is reproducible rather than reduced to an argument about "why the system stayed silent."
Fourth — the absence of these rules as a formalized artifact. If trigger conditions are described only in the model code, they can neither be agreed upon with physicians nor updated for a changed clinical protocol. It is precisely at this junction that AI CDSS implementation most often stops at the pilot.
What Changes After Implementation: Effects the Clinic Measures
Time to a Ready Decision
The key metric that shows the effect of implementation is the time from the appearance of primary data to a ready decision: a recommendation with rationale, ranked hypotheses, and clearly marked data gaps.
Before the system, this time consists of manual searching through protocols, cross-checking with the history of appointments and consultations — on a duty shift it is measured in tens of minutes and grows with each new patient in the queue.
The system pulls data from the clinic's existing environment — laboratory, orders, indicator dynamics — and brings it to a unified structure on HL7 FHIR, and returns the answer to the physician's working interface rather than in a separate window.
The duty shift receives the recommendation at a moment when the decision can still be changed: before the order, not after. The burden on the physician decreases not through auto-populating decisions but through removing routine search — the final decision remains with the human.
What Changes in the Structure of Errors and Failures
We measure the reduction in the error rate not as a single number but by class: a missed contraindication in a drug interaction, an overdue action on an order, incorrect interpretation of a result outside the reference interval.
For each class, we record whether the rule triggered, whether the physician confirmed it, and how the case ended — these three marks provide manageable statistics instead of the wording "there are fewer errors."
Separately, we count a class of failures that is usually overlooked: false triggers. When there are too many recommendations or their rationale is unconvincing, the physician begins to skip them — and the share of overdue actions returns to the baseline.
Therefore, rules are configured by sensitivity thresholds and versioned: a specific rule can be rolled back without rebuilding the system, and the metrics immediately show what changed on the shift.
AI CDSS Operating Modes: Recommendation, Verification, Routing
The modes differ by the point of embedding in the clinical pathway and by who makes the final decision. A recommendation at the input changes data collection, order verification — an already made decision, routing — the patient flow. They should be enabled one at a time; otherwise it is unclear what exactly influenced the result.
Input Recommendation Mode
The system sees primary data and returns a list of hypotheses, relevant studies, and warning signs. The physician remains the author of the decision, and the system's role is to prevent missing something significant.
Limitation: the recommendation relies only on what is entered into the fields, so with an incomplete history it stays silent where it should warn.
Verification and Routing Mode
Order verification checks the dose, frequency, contraindications, and interactions with already prescribed treatment; routing distributes the patient by profile and urgency.
Here the system works at the output of the decision, so the cost of an error is higher: a false trigger slows down the appointment, while a miss goes into the chart unnoticed.
| Option | When It Fits | Mode Limitations |
|---|---|---|
| Input recommendation | Initial appointment, broad profile, shortage of narrow specialists | Depends on completeness of input; does not replace examination; a simple way to reject the recommendation is needed |
| Order verification | Inpatient care, high risk of interactions, age-related and pediatric doses | False triggers with weak dictionaries; thresholds are configured for the department |
| Patient routing | Admission department, flow of requests, remote consultations | An error changes the patient's path entirely; disputed cases require manual review |
The modes are compatible with each other and are deployed in stages: first one, with measurement of the share of accepted recommendations and rejected triggers, then the next. This way, the limitations of each mode are visible before it begins to affect the clinical pathway.
Implementation Stages: From Data Audit to Handover to Operation
Implementing a clinical decision support system is not a product installation but a sequence of engineering steps, each relying on the result of the previous one.
We do not configure rules until it is clear where the data comes from and at what moment the recommendation reaches the physician.
Data and Clinical Process Audit
We inventory the sources: laboratory results, orders, medical histories, drug dictionaries and their interactions. We check completeness, duplicates, coding discrepancies, and arrival delays — most often this is exactly what breaks the rules.
- Data and process audit: source map, field quality, bottlenecks in the current patient pathway.
- Decision-making scheme: at which step of the physician's work the recommendation appears, what the physician sees, and what goes into the log.
- Rule configuration: thresholds, priorities, exceptions — so that the shift receives meaningful notifications rather than an avalanche.
- Rule verification: a run on a dataset of closed cases, the share of triggers and false signals, threshold calibration.
Pilot in One Department
- Pilot in one department: a limited environment, the recommendation does not block the physician's decision, we record agreement with the recommendation and reaction time.
- Review of discrepancies with the shift, refinement of rules, and re-verification on history — the edit must not break previously agreed cases.
- Handover to operation: regulation for updating rules, access control, logging, instructions, and shift training.
After handover, we support the system: every new rule undergoes the same verification on history, and changes are rolled back without stopping the department's work.
Implementation Artifacts: Rules, Schemes, Regulations, Training
Implementation ends not with the system launch but at the moment when the clinic works with it without us. Therefore, the project closes with a package of documents that remains with the customer's team — not a presentation but working materials.
- Trigger rules — conditions, thresholds, and combinations of signs under which the system issues a recommendation, with the source of each threshold.
- Data flow map — where data comes from, in what form, where it is stored, and at which step it is de-identified.
- Access rights — a "role × action" matrix: who sees the recommendation, who confirms it, who exports data.
- Regulation for reviewing disputed cases — what to do when the physician and the system diverge, timeframes, responsible parties.
- Instructions — step-by-step scenarios for the physician and administrator, including non-standard situations.
- Staff training program — roles, scope, format, and criteria for permission to work independently.
Trigger Rules and Thresholds
Rules are described in a table: condition, threshold, priority, source. The physician sees why the system triggered and disputes a specific rule rather than the entire model. A threshold change is approved by the clinical lead, and the change is recorded in the version log.
Regulation for Reviewing Disputed Cases
Every discrepancy goes through one scheme: case recording, review with a clinical expert, decision — correct the rule, add data, or recognize the discrepancy as acceptable. Accumulated cases become material for updating instructions and retraining.
Case Study: How Recommendation Accuracy and Decision Speed Increased
AI CDSS development was carried out at Multidisciplinary Medical Center: inpatient care and a flow of initial appointments, where the prescribing decision is made in the first minutes of conversation with the patient.
The recommendation must appear in the chart, over the orders, with rationale and a source reference — not in a separate window that still needs to be opened.
Metrics were taken on the same cross-section of physicians before the pilot and after three months of operation, so that the comparison would be fair.
How It Was Before Implementation
Trigger usefulness — the share of recommendations that the physician recognized as justified and took into account — remained around one third.
The rest had to be filtered manually: the system reacted to any intersection of the drug list, without considering dose, duration of therapy, or how recent the tests were.
Because of the noise, pop-up windows stopped being read, and the usual workaround kicked in. Time to a ready decision for a complex patient took more than ten minutes: checking interactions against the dictionary, clarifying contraindications, calling the laboratory.
Every fifth visit for the same reason returned within a month — the order was adjusted only after deterioration occurred.
What Changed After the Pilot
The trigger filter was rewritten for the patient context: dose, duration of therapy, concomitant diagnoses, and freshness of laboratory data are taken into account.
Each recommendation comes with a brief explanation — what raised concern and on which norm the conclusion is based; this removed distrust of the system as a "black box."
Trigger usefulness increased to two thirds, and the share of cases where the recommendation was accepted without edits is more than half.
Time to a ready decision decreased by approximately half: the physician receives a justified option directly in the chart and spends time on the patient rather than on searching.
Repeat visits for the same reason fell from every fifth to one in twelve — orders hold the first time.
How Does an AI CDSS Add-On to a MIS Differ from a Standalone Service?
The key difference is not in the model but in where the patient data lives and who owns the clinical context.
An add-on to a MIS reads the history of appointments, orders, and laboratory results through an integration layer and returns the recommendation directly into the appointment card.
A standalone service maintains its own database and receives data through manual entry or periodic export.
From this, the limitations of the options also diverge.
Integration with a MIS is limited by its capabilities: if there is no event interface, the exchange is built through an intermediate layer and a message queue, and some fields are mapped manually — but the recommendation relies on the full appointment history.
A standalone workstation is freer in development and does not depend on the MIS vendor, but dual entry appears and there is a risk of database divergence.
| Option | When It Fits | Limitations |
|---|---|---|
| Add-on to MIS | There is a software exchange interface, the physician works in a single card | Vendor dependency, exchange delay, a decision log is needed |
| Standalone service | Several different MISs at the site, quick validation of the approach is needed | Manual entry, incomplete context, data divergence |
| Hybrid through an exchange layer | A unified dictionary for several MISs, a long horizon | More complex support and access control |
The choice of architecture is set not by model quality but by the source of truth for the patient and the owner of the recommendation log during incident review.
In industry practice, exchange is built on HL7 FHIR profiles — then the add-on remains replaceable and does not tie the clinic to a single MIS vendor.
Technical Doubts: Addressing Objections Before Start
AI CDSS development almost always begins with the same doubts: who is responsible for the recommendation, what to do with heterogeneous sources, and how to verify model quality. Below are brief answers to each.
Who Is Responsible for the Recommendation?
The physician makes the decision: the system shows options with rationale — which signs influenced the result, how complete the data is, and what alternatives exist. The interface does not make a diagnosis; it logs whether the recommendation was accepted or rejected.
What to Do with Disparate Data?
We place a normalization layer between sources: laboratory, chart, and conclusions are brought to a unified model, and duplicates and contradictions are marked. If indicators are insufficient, the system shows the gap rather than filling in data.
How Is Recommendation Quality Verified?
On retrospective datasets, we calculate sensitivity, specificity, and the share of discrepancies with experts. Before launch, the model operates in shadow mode: its conclusions are compared with physicians' decisions but are not shown to them.
How Does It Scale?
We proceed in stages: department, clinic, network. Access rights are configured at the profile level, so a new unit is connected without rewriting the core.
How Well Is Patient Data Protected?
Access is role-based, accesses to the patient record are logged, and de-identified datasets for development are separated from the working environment. Rolling back to a previous model version is a standard operation.
Let's Discuss the Task: How Collaboration Begins
The conversation begins not with model selection but with the clinical pathway.
To discuss the task concretely, at the first review we go through it step by step and record at which point the system recommends and where the decision remains with the physician — everything else depends on this: data sources, rules, and the look of the interface.
What is worth bringing to the first meeting:
- Clinical pathway description: the specific step where support is needed, and the specialist's role in decision-making.
- Data sources: electronic medical record, laboratory system, drug and diagnosis dictionaries — what already exists and in what form it provides data.
- Volume of historical cases with confirmed outcomes: we use them to check how AI CDSS reproduces the decision logic.
- Limitations: what the system must not do — make a diagnosis, change orders, work without human confirmation.
- Explainability requirements: whether a reference to the rule or data fragment from which the recommendation was derived is needed.
- Timelines and form of result handover: pilot environment, documentation package, staff training.
- Responsible persons on your side: who confirms clinical rules and accepts the result of each stage.
After the review, we will return with an estimate and work plan: the sequence of stages, what will be required from your side, and on which data we verify correctness before introduction into clinical practice. Describe the task — and we will start with this list.
