A clinical decision support system is defined by the decision it supports, not by whether it uses artificial intelligence. It combines medical knowledge with information about a particular patient and presents something useful while a clinician can still act on it.
The Office of the National Coordinator for Health IT describes clinical decision support in much the same way: timely, person-specific information, filtered or presented at an appropriate point in care. The output might be an alert, an order set, a patient summary, diagnostic support or a relevant guideline. The clinician remains responsible for the decision.
The useful boundary is the decision
Timing and context separate a CDSS from a medical reference. A guideline may contain the right recommendation, but the clinician still has to find the relevant section and decide whether it applies. A CDSS uses what is known about the patient to bring the relevant information into the clinical task.
That does not mean every output has to be a recommendation. A warning about a drug interaction supports a prescribing decision. A patient summary can support the next diagnostic or treatment decision. A reminder can support follow-up. These functions belong to the same category because they organize patient-specific information for a decision, not because their interfaces look alike.
Rules and models take different routes
A 2020 overview in npj Digital Medicine describes a common distinction between knowledge-based and non-knowledge-based systems.
In a knowledge-based CDSS, rules are written in advance. The system retrieves patient data, checks it against an IF-THEN rule and produces an action or output. A medication rule, for example, can compare a new prescription with the drugs already recorded for the patient. Because the logic is explicit, reviewers can inspect the rule that produced the alert.
A non-knowledge-based CDSS uses machine learning, statistical pattern recognition or another AI method instead of following only expert-written rules. A model might combine vital signs and laboratory values to estimate risk. This approach can detect patterns that are difficult to encode by hand, but its output still depends on the data, intended use and evaluation of the model. Calling it AI does not make the result clinically valid.
Both designs need a way to receive clinical data and present an output to a person. They fail differently, so they also need different checks. A rule can be outdated or applied to the wrong condition. A model's logic may be harder to inspect, and its result still depends on the available data and evaluation in the intended setting.
An electronic record is an input, not the system
Clinical decision support often runs inside an electronic health record, but it does not have to. ONC notes that CDS may be part of an EHR, a stand-alone system or a plug-in. Integration matters because a tool that cannot receive patient context may force the clinician to enter the same case twice.
Vietnam's Circular 13/2025/TT-BYT requires hospitals to implement electronic medical records by 30 September 2025. Other licensed facilities providing inpatient, day and outpatient treatment have until 31 December 2026. The Circular also requires IT infrastructure, clinical applications, backup storage, security and retrievable electronic records.
Those requirements create infrastructure that integrated decision support could use. They do not guarantee that data is complete, normalized across systems or ready for a particular CDSS. An electronic record stores clinical information. Decision support still has to interpret the available data, handle what is missing and fit the moment when a clinician needs help.
Where Meddies fits
For Meddies, this definition is a design boundary. The intended product brings prescription checks, chart summaries and evidence retrieval into the clinician's workflow instead of asking doctors to rebuild the case in a separate application. It is also intended to show the sources behind its clinical claims and leave the decision with the doctor.
These are product goals, not evidence of clinical benefit. They still have to be tested for accuracy, usability, ignored warnings and effects on clinical work. The test is concrete: does the output reach a real clinical decision in time, and can the clinician review and reject it?