What Clinicians Actually Need From Decision Support

What clinicians need from decision support is simple to state and hard to build: a suggestion that fits the patient in front of them, is safe to follow, explains itself in a sentence, arrives inside the visit they are already running, and carries evidence they can point to when someone asks why. Get those five right and a tool earns a place in the consultation. Miss any one and it becomes another window the clinician closes. The hard problem is not the model. It is the few minutes a clinician actually has.

A decision-support system is judged by whether a busy physician, mid-consultation, reaches for it instead of around it. Adoption is the real endpoint, and it is a design property, not a marketing one.

What does good clinical decision support need to do?

Here is a working definition. Clinical decision support is software that helps a clinician make a better choice at the moment a choice has to be made, by turning data already in the chart into a relevant, guideline-aligned next step. What separates the tools clinicians keep from the ones they mute comes down to five properties.

Individualized to this patient, not the average one

A recommendation built for the average patient is wrong for almost everyone. Real patients arrive with kidney function that rules out a first-line drug, a weight trajectory that should steer the choice, an intolerance buried in an old note, and other conditions pulling in different directions. Support that recites the top-line guideline reminds the clinician of something they already know while missing the reason this case is hard. The bar is whether it says something specific to the person in the room.

Safe to follow, and quiet when standard care is already right

Safety in decision support is mostly about restraint. A tool that fires on every patient trains people to click past it, and an alert everyone dismisses is worse than no alert, because it erodes the attention a genuinely important warning will later need. A common trap is measuring success by how often the tool speaks. The better measure is whether, on the rare occasion it speaks, it was right. Safe also means the system knows its own edges: when the data are too thin or the case sits outside what the tool was validated for, the honest behavior is to step back rather than produce a confident recommendation anyway.

Explainable in a sentence the clinician can repeat

A recommendation a clinician cannot explain is one they cannot defend, and they will not stake a patient's care on a black box. Explainability here does not mean a page of model internals. It means a short, legible reason: this suggestion, because of this value in this patient, aligned to this guideline. If the clinician can read that line and either nod or override it on the spot, the tool has done its part.

Inside the workflow, not beside it

The fastest way to kill a good recommendation is to make the clinician leave their workflow to get it. A second login, a separate tab, a copy-paste of the patient's numbers into another screen, and the tool has already lost to a short visit with a queue behind it. Support has to appear where the decision is being made, in a form the clinician can act on without breaking stride. This is the least glamorous requirement and the one that decides most deployments.

Backed by evidence the clinician can point to

Clinicians are trained to ask what the evidence is, and they are right to. A tool that improves care should be able to say it was tested against standard care in real clinics and the patients did better. A benchmark score on a held-out dataset only tells you the model pattern-matches on data resembling its training set. What counts is a result earned where the tool will live, the thing that lets a clinician adopt it without feeling they are gambling on a vendor's confidence.

How do you design decision support for the visit a clinician actually has?

You design backward from the consultation, not forward from the model. Building and evaluating EASY Diabetes taught me two things about doing that.

The first is that co-design is not a courtesy. As Head of Medical and Science I co-developed EASY Diabetes, an AI clinical decision-support system for type 2 diabetes, built together with patients, clinicians, and researchers rather than handed to them. When the people who use a tool every day shape it, the recommendations land in the language and at the moment decisions are actually made, and adoption follows. A tool that improves a decision while doubling the clinician's workload will not survive a real schedule, which is why we measured workflow effects alongside clinical outcomes.

The second is that evidence has to be earned in the field. The EASY-1 randomized controlled trial (NCT03258268) was a multi-clinic study comparing the system against standard of care. The multi-site design mattered as much as the result, because a tool that works in one motivated clinic may be quietly leaning on that clinic's habits. The variation across many clinics is the world you are claiming to improve. EASY Diabetes received the Medtech4Health Innovation Award.

Why do good tools still fail to get adopted?

Usually not because the model was wrong, but because the design failed one of those five tests. Each test is a decision that is fixable before launch if you treat the consultation as the specification.

There is also a quieter payoff when you get this right. Diabetes guidelines are detailed and they change, and a well-designed tool keeps a new resident and a seasoned physician anchored to the same current standard, reducing variation in care that patients feel in their outcomes.

This article is educational and is not medical advice. Decisions about diabetes treatment should be made with your own clinician, who can weigh your full history.

So build for the few minutes a clinician actually has, and prove the benefit where the tool will live. Then let the clinician override you whenever they know the patient better than the software does.