Dr. Tejasvi Kumar C

Artificial intelligence is becoming increasingly capable of analysing medical images, predicting clinical deterioration, identifying drug interactions and processing enormous quantities of patient data. Yet one of the biggest challenges facing clinical decision support systems (CDSS) is not necessarily the sophistication of their algorithms.

It is whether clinicians will actually use them.

A clinical decision support system can be technically impressive, evidence-based and statistically accurate and still fail in clinical practice if it interrupts workflow, generates irrelevant alerts, provides recommendations at the wrong moment or cannot explain why a recommendation matters.

This distinction is important.

Healthcare software is not simply software operating inside a hospital. It operates inside a complex clinical environment where decisions are made under uncertainty, time pressure and competing priorities. Designing effective clinical decision support therefore requires more than translating guidelines into algorithms.

It requires translating clinical reasoning into usable digital workflows.

That is why clinicians should not merely be consulted after a CDSS has been developed. They should participate in its design from the beginning.

What Clinical Decision Support Actually Means

Clinical decision support encompasses digital tools that provide clinicians, patients or other members of the healthcare team with knowledge or patient-specific information intended to improve healthcare decisions.

These systems may include:

• medication interaction warnings,
• diagnostic algorithms,
• risk prediction tools,
• investigation recommendations,
• preventive-care reminders,
• treatment pathways,
• antimicrobial stewardship systems,
• deterioration alerts,
• guideline-based recommendations, and
• increasingly, artificial intelligence-based predictive systems.

The Agency for Healthcare Research and Quality describes CDS as providing timely information—usually at the point of care—to help inform decisions about a patient’s care.

Importantly, CDS is intended to support rather than replace clinical judgment. The US Office of the National Coordinator for Health Information Technology similarly emphasises that decision support should deliver clear, well-organised information that fits into the clinician’s workflow.

This sounds straightforward.

In practice, achieving it is remarkably difficult.

A Technically Correct System Can Still Be Clinically Wrong

Consider a simple example.

A patient presents to an emergency department with abdominal pain.

A software system may correctly identify that a CT scan should be considered based on a predefined combination of symptoms, laboratory values and clinical rules.

But the treating clinician may simultaneously be considering pregnancy, renal impairment, haemodynamic instability, previous imaging, an alternative diagnosis or whether immediate surgical review is more appropriate.

The algorithm may therefore be technically correct according to its programmed rule while being inappropriate for the clinical context.

This illustrates one of the fundamental challenges in CDSS design:

Clinical decisions rarely occur in isolation.

They occur within sequences of decisions.

Experienced clinicians continuously integrate history, examination findings, investigations, disease probability, patient characteristics, previous interventions, available resources and the consequences of delaying treatment.

Software engineers can model these variables.

But identifying which variables actually change the decision requires clinical knowledge.

The distinction is critical.

The Real Unit of Design Is the Clinical Decision

Many healthcare technology projects begin with data.

What information is available in the electronic health record?

What variables can the algorithm analyse?

What can the machine-learning model predict?

A clinician may approach the problem differently:

What decision are we trying to improve?

That question changes the architecture of the system.

For example, predicting that a patient has a 17% probability of postoperative deterioration may be technically interesting.

But the clinician needs to know:

• Is 17% high enough to change management?
• What factors produced that risk?
• What should I do differently?
• Should the patient go to the ward, high-dependency unit or ICU?
• Should monitoring frequency change?
• Is there a reversible risk factor?
• How urgent is the intervention?

A prediction becomes clinically valuable only when it can inform an action.

This principle has been recognised for decades. Bates and colleagues’ influential work on effective clinical decision support emphasised that CDS should anticipate clinicians’ needs, deliver information in real time and fit into existing workflow [1].

More than twenty years later, the same problem remains central to CDSS design.

Workflow Is Not a Software Feature

Clinical workflow can appear deceptively simple when represented as a flowchart.

Patient arrives → clinician evaluates → investigation ordered → diagnosis made → treatment initiated.

Actual clinical practice is rarely that linear.

Information arrives asynchronously. Decisions are revised. Multiple clinicians participate. Investigations are delayed. Patients deteriorate. Resources vary between institutions. Senior and junior clinicians interpret the same information differently.

This is one reason workflow integration repeatedly emerges as a major determinant of successful CDS implementation.

Academic literature on effective CDS implementation highlights several characteristics associated with successful systems: decision support should be available as part of workflow, provide actionable recommendations, and appear when and where decisions are being made [1,4].

More recent evidence points in the same direction. A comprehensive review identified workflow integration, usability, transparency, trust and organisational factors as important influences on successful CDS implementation [4].

A system that requires clinicians to leave their electronic record, open another application, enter information already available elsewhere and then interpret a complex output has already created substantial friction.

The problem is not necessarily the algorithm.

The problem is the workflow.

The Five Rights of Clinical Decision Support

A useful framework for understanding this problem is the Five Rights of CDS.

Effective decision support attempts to deliver:

the right information

to the right person

in the right format

through the right channel

at the right time in the workflow.

Notice that only one component concerns the information itself.

The remaining components concern context and delivery.

This has an important implication for technology teams.

The question is not merely:

Is our recommendation medically correct?

The better question is:

Is this the correct information for this clinician, in this situation, presented in a form that helps them make the next decision?

Clinicians are essential to answering that question.

Alert Fatigue Shows What Happens When Context Is Ignored

Perhaps the clearest example of poorly integrated decision support is alert fatigue.

Electronic health systems can generate warnings for drug interactions, allergies, abnormal laboratory values, duplicate investigations and numerous other clinical situations.

Individually, many of these alerts are defensible.

Collectively, they can become overwhelming.

Research has demonstrated that repeated alerts and workload can contribute to alert fatigue and desensitisation [3]. Broader reviews similarly note that poorly contextualised alerts can disrupt clinical workflow and contribute to clinicians overriding or ignoring warnings [4].

This creates a paradox.

A system designed to improve safety can potentially create another safety problem: clinicians become accustomed to dismissing alerts.

The lesson is not that alerts are ineffective.

It is that clinical importance must determine interruption.

A life-threatening drug interaction and a minor theoretical interaction should not necessarily demand the same cognitive attention.

Clinicians understand these hierarchies because they make such prioritisation decisions continuously.

Clinical Guidelines Are Not Algorithms

Another common misconception in digital health is that converting a clinical guideline into software simply requires translating recommendations into “if-then” rules.

Guidelines are rarely that simple.

They contain:

• conditional recommendations,
• exclusions,
• contraindications,
• different levels of evidence,
• areas of uncertainty,
• patient preferences,
• resource considerations, and
• situations where clinician judgment remains necessary.

The World Health Organization’s SMART Guidelines initiative recognises precisely this translation challenge. Its approach aims to transform narrative health recommendations into structured, standards-based components that can be implemented consistently in digital systems.

But even a perfectly digitised guideline cannot anticipate every clinical scenario.

The purpose of CDS should therefore not be to eliminate clinical reasoning.

It should be to make evidence easier to apply during clinical reasoning.

That distinction should guide the design philosophy.

Human Factors Matter as Much as Algorithmic Performance

Clinical decision support is fundamentally a human-computer interaction problem.

Reviews of clinical decision support consistently emphasise that system design must account for clinical workflow, usability and human factors rather than focusing exclusively on the underlying decision rule [1,4].

A growing body of human-centred design research makes a similar argument.

The same literature identifies usability, workflow integration, iterative refinement and involvement of end users as important considerations in developing clinically usable systems [1,4].

This matters because clinicians do not interact with decision-support systems under laboratory conditions.

They interact with them while:

• answering telephone calls,
• speaking to patients,
• reviewing investigations,
• documenting notes,
• managing emergencies,
• coordinating teams, and
• simultaneously caring for several patients.

Every unnecessary click therefore has a cost.

Every irrelevant alert consumes attention.

Every ambiguous recommendation introduces cognitive work.

And every additional screen competes with patient care.

Artificial Intelligence Makes Clinician Involvement More Important, Not Less

AI adds another layer to this problem.

Traditional rule-based CDSS can often show clinicians the rule that produced a recommendation.

Machine-learning models may generate predictions from hundreds or thousands of variables.

This creates questions of explainability, trust and automation bias.

A comprehensive review of AI-driven CDSS has highlighted usability, workflow integration, trust, transparency and ethical considerations as important challenges for implementation [4].

Research also suggests that clinicians’ interaction with AI recommendations is complex.

For example, experimental work has demonstrated that both accurate and inaccurate AI advice can influence human diagnostic decisions [5]. This means that simply inserting an accurate model into clinical workflow does not guarantee better decisions.

The interaction between the clinician and the algorithm becomes part of the intervention.

The same experimental work showed that clinicians can be influenced by erroneous as well as accurate decision advice, reinforcing the importance of how trust in AI recommendations is calibrated [5].

The future of clinical AI therefore cannot be evaluated solely by asking:

How accurate is the model?

We must also ask:

How does the model change clinician behaviour?

That question requires clinical evaluation.

Clinicians Should Be Co-Designers, Not End-Stage Testers

Many healthcare technology projects involve clinicians relatively late.

A typical development pathway might look like:

problem identified → software designed → prototype built → clinician feedback obtained → product launched

A better model is:

clinical problem → workflow mapping → decision mapping → evidence mapping → clinician-engineer co-design → prototype → simulation → clinical testing → iteration → deployment → monitoring

Clinicians should help define at least five components.

1. The decision

What exact clinical decision is the system attempting to support?

2. The trigger

At what point should the system intervene?

3. The minimum information required

What variables genuinely change management?

4. The action

What should the clinician be able to do after receiving the recommendation?

5. The exceptions

Under what circumstances should the recommendation not apply?

Software teams can then translate this clinical architecture into reliable, scalable technology.

The relationship should therefore not be clinician versus engineer.

It should be clinician plus engineer.

Each possesses expertise the other does not.

Clinicians Alone Shouldn’t Build CDSS Either

The argument for clinician-led design should not be misunderstood as an argument that clinicians should independently build healthcare software.

That would simply reverse the same mistake.

Modern CDSS development requires expertise in:

• software engineering,
• interoperability,
• clinical informatics,
• cybersecurity,
• data engineering,
• human-computer interaction,
• artificial intelligence,
• quality assurance,
• regulatory compliance,
• clinical research, and
• implementation science.

Clinicians provide the clinical architecture.

Engineers provide the technical architecture.

Human-factors specialists help connect the two.

Researchers establish whether the resulting intervention actually improves care.

The strongest systems are therefore multidisciplinary by design.

Measure Clinical Utility, Not Just Model Accuracy

A CDSS should not be considered successful simply because its algorithm performs well.

A useful evaluation framework should examine several levels.

Technical performance: Does the algorithm work?

Clinical validity: Does it correctly identify the clinical state or risk?

Clinical utility: Does the information change appropriate management?

Usability: Can clinicians use it efficiently?

Workflow impact: Does it reduce or increase cognitive and administrative burden?

Safety: Can incorrect recommendations cause harm?

Patient outcomes: Does implementation ultimately improve care?

The distinction is important because systematic reviews have historically found that CDSS can improve healthcare process measures, while evidence regarding harder clinical, economic, workload and efficiency outcomes has been less consistent [2].

For AI systems specifically, emerging guidance emphasises early clinical evaluation within the technology lifecycle rather than treating model validation as the end of assessment [6].

The DECIDE-AI reporting guideline similarly emphasises early-stage clinical evaluation of AI-based decision support in real clinical settings [6].

Healthcare should therefore move beyond asking whether an algorithm works.

We need to know whether the clinical system built around the algorithm works.

The Future Is Clinician-Technology Collaboration

Clinical decision support is likely to become increasingly sophisticated.

Systems will combine electronic health records, imaging, pathology, genomics, wearable devices and real-time physiological monitoring. Large language models may eventually help synthesise this information and generate patient-specific recommendations.

But more computational power will not remove the fundamental challenge.

Healthcare decisions occur in context.

A clinically useful decision-support system must understand not merely the patient’s data but the decision being made, the clinician making it, and the workflow in which that decision occurs.

That is why the future of CDSS should not be framed as doctors versus algorithms.

Nor should it be framed as software replacing clinical reasoning.

The more productive model is augmented clinical intelligence: machines providing computational capability, evidence retrieval and pattern recognition while clinicians contribute context, judgment, prioritisation and accountability.

The best clinical decision support system is therefore not the one that makes the most decisions for clinicians.

It is the one that helps clinicians make better decisions themselves.

And designing such systems requires clinicians to be present not merely at deployment, but at the very beginning.

Academic References

1. Bates DW, Kuperman GJ, Wang S, Gandhi T, Kittler A, Volk L, et al. Ten commandments for effective clinical decision support: making the practice of evidence-based medicine a reality. J Am Med Inform Assoc. 2003;10(6):523-530. doi:10.1197/jamia.M1370.
2. Bright TJ, Wong A, Dhurjati R, et al. Effect of clinical decision-support systems: a systematic review. Ann Intern Med. 2012;157(1):29-43. doi:10.7326/0003-4819-157-1-201207030-00450.
3. Ancker JS, Edwards A, Nosal S, Hauser D, Mauer E, Kaushal R. Effects of workload, work complexity, and repeated alerts on alert fatigue in a clinical decision support system. BMC Med Inform Decis Mak. 2017;17:36. doi:10.1186/s12911-017-0430-8.
4. Sutton RT, Pincock D, Baumgart DC, Sadowski DC, Fedorak RN, Kroeker KI. An overview of clinical decision support systems: benefits, risks, and strategies for success. NPJ Digit Med. 2020;3:17. doi:10.1038/s41746-020-0221-y.
5. Gaube S, Suresh H, Raue M, et al. Do as AI say: susceptibility in deployment of clinical decision-aids. NPJ Digit Med. 2021;4:31. doi:10.1038/s41746-021-00385-9.
6. Vasey B, Nagendran M, Campbell B, et al. Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. Nat Med. 2022;28(5):924-933. doi:10.1038/s41591-022-01772-9.