A clinical decision support system (CDSS) is a type of health information technology that provides clinicians, staff, patients, and other individuals with knowledge and individual-specific information that is intelligently filtered or presented at the appropriate time to improve health and health care.

What is Clincical decision support system (CDSS)

Robert Hayward of the Centre for Health Evidence has proposed the following working definition: “Clinical decision support systems connect health observations and health information in order to influence clinicians’ health choices for enhanced health care.”

A clinical decision support system (CDSS) is a computer programme that analyses data in order to assist healthcare providers in making decisions and improving patient care. It is a subset of the decision support system (DSS) that is frequently used in corporate management. A CDSS focuses on the use of knowledge management to obtain clinical advice based on a variety of characteristics associated with patient data. Clinical decision support systems facilitate integrated processes, provide aid during care, and make suggestions about treatment plans.

When combined with appropriate clinical research, data mining can be used to investigate a patient’s medical history. Such analysis can therefore aid in the prediction of future occurrences, such as drug interactions or the identification of disease signs. Among these capabilities are automated alerts and reminders to caregivers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic help, and contextually appropriate reference information.

Purpose

Modern CDSS are primarily intended to aid doctors at the time of care.
This means that clinicians collaborate with a CDSS to analyse and diagnose patient data.

Initially, CDSSs were envisioned as being utilised to make clinical choices for the doctor. The physician would enter the data and then wait for the CDSS to generate the “correct” choice, which the doctor would then act on. However, the modern methodology of utilising CDSSs for assistance requires the clinician to interact with the CDSS, utilising both their own knowledge and that of the CDSS, in order to perform a more accurate analysis of the patient’s data than either the human or the CDSS could do on their own. Typically, a CDSS provides ideas for the clinician to consider, and the clinician is supposed to glean important information from the supplied data and disregard erroneous CDSS recommendations.

CDSS Classification

CDSS are classified into two broad categories: knowledge-based and non-knowledge-based.

A diagnosis decision support system is one example of how a clinician might use a clinical decision support system. A DDSS collects some of the patient’s data and responds with a list of possible diagnoses. The physician then uses the DDSS output to assess which diagnoses are potentially relevant and which are not, and, if necessary, performs more tests to narrow down the diagnosis.

A case-based reasoning (CBR) system is another type of CDSS. A CBR system may utilise prior case data to assist in determining the right number of beams and ideal beam angles for use in radiotherapy for patients with brain cancer; medical physicists and oncologists would then examine the recommended treatment plan for viability.

A CDSS can also be classified according to the time period in which it is used. Physicians employ these systems at the point of care to assist them in dealing with a patient, whether pre-, during, or post-diagnosis. Pre-diagnosis CDSS systems assist physicians in preparing diagnoses. CDSS are utilised during diagnosis to assist physicians in reviewing and filtering their preliminary diagnostic choices in order to improve their final outcomes. Post-diagnosis CDSS systems are used to mine data in order to establish linkages between patients and their prior medical history, as well as to conduct clinical research in order to forecast future events. As of 2012, it was suggested that decision support would eventually begin to take the position of clinicians in routine duties.

Another approach, used by the National Health Service in England, is to use a DDSS (either operated by the patient in the past or, more recently, by a non-medically trained phone operator) to triage medical emergencies outside of normal business hours by suggesting a suitable next step to the patient (e.g. call an ambulance, or see a general practitioner on the next working day). The suggestion, which may be disregarded by either the patient or the phone operator if common sense or caution dictate otherwise, is based on known information and an implicit conclusion about what the worst-case diagnosis is likely to be; it is not always disclosed to the patient, as it may be incorrect and is not based on the opinion of a medically trained person; it is only used f

Knowledge-based CDSS

The majority of CDSSs are composed of three components: a knowledge base, an inference engine, and a communication mechanism. The knowledge base stores the rules and associations associated with compiled data, which are frequently expressed as IF-THEN rules. If this were a system for assessing medication interactions, a rule may be: IF DRUGS X AND Y ARE TAKEN, THEN NOTIFY USER. A more sophisticated user might change the knowledge base using another interface to keep it current with new medications. The knowledge base’s rules are combined with the patient’s data by the inference engine. The communication mechanism enables the system to both display the results to the user and accept input from the user.

To express knowledge artefacts in a computable manner, an expression language such as GELLO or CQL (Clinical Quality Language) is required. For instance, if a patient has diabetes mellitus and their most recent haemoglobin A1c test result was less than 7%, they should be re-tested if it has been more than 6 months; however, if their most recent test result was greater than or equal to 7%, they should be re-tested if it has been more than 3 months.

The HL7 CDS Working Group’s current objective is to expand on the Clinical Quality Language (CQL). CMS recently stated its intention to use CQL to specify eCQMs (https://ecqi.healthit.gov/cql).

Non-knowledge-based CDSS

Without a knowledge basis, CDSSs rely on a type of artificial intelligence called machine learning, which enables computers to learn from previous experiences and/or identify patterns in clinical data. This obviates the requirement for rule writing and expert involvement. However, because machine learning-based algorithms are unable to explain their conclusions, most practitioners avoid using them directly for diagnosis for reliability and accountability reasons. Nonetheless, they can be beneficial as post-diagnostic systems, indicating patterns for physicians to investigate further.

Support-vector machines, artificial neural networks, and genetic algorithms are three forms of non-knowledge-based systems as of 2012.

Artificial neural networks analyse patterns observed in patient data in order to derive links between symptoms and a diagnosis.
Genetic algorithms are based on simplified evolutionary processes that employ directed selection to provide the best CDSS outcomes. Algorithms for selecting solutions to problems analyse components of random collections of solutions. The solutions that emerge as the winners are then recombined and modified and the process is repeated. This process is repeated until the correct solution is determined. They, like neural networks, are “black boxes” that attempt to generate information from patient data.
Non-knowledge-based networks frequently focus on a limited set of symptoms, such as those associated with a single disease, in contrast to knowledge-based networks, which encompass the diagnosis of a wide variety of disorders.

Challenges

Numerous medical institutions and software businesses have invested considerable effort in developing effective CDSSs that support all areas of clinical tasks. However, given the complexity of clinical workflows and the high demands on staff time, the institution implementing the support system must exercise caution to ensure that the system becomes an integrated and fluid component of the clinical workflow. Certain CDSSs have met with varied degrees of success, while others have seen widespread barriers to or reductions in successful adoption and acceptability.

The pharmaceutical and billing sectors of healthcare are two areas where CDSSs have had a significant impact. There are several widely used pharmacy and prescription ordering systems that currently do batch-based drug interaction checks on orders and alert the ordering professional. Another area where CDSS has had success is in billing and claim filing. Given that many hospitals rely on Medicare reimbursements to remain open, systems have been developed to assist in examining both a proposed treatment plan and the current Medicare rules in order to suggest a plan that attempts to address both the patient’s care and the institution’s financial needs.

Other CDSSs geared towards diagnostic tasks have been successful, but their implementation and scope are frequently somewhat limited. The Leeds Abdominal Pain System began operation in 1971 at the University of Leeds hospital and was claimed to have a success rate of 91.8 percent, compared to 79.6 percent for physicians.

Despite the numerous efforts made by institutions to develop and implement these systems, general adoption and acceptance of the majority of offers have not yet been accomplished. Historically, one significant impediment to adoption has been workflow integration. There was a tendency to focus exclusively on the CDSS’s functional decision-making core, resulting in a lack of planning for how the clinician will actually utilise the product in situ. Often, CDSSs were standalone apps that required clinicians to exit their present system, switch to the CDSS, input the relevant data (even if it had already been entered into another system), and analyse the results provided. Additional processes disrupt the clinician’s flow and consume valuable time.

Technical difficulties and implementation impediments

Clinical decision support systems encounter numerous technical obstacles. Biological systems are extremely complex, and a therapeutic choice may involve the consideration of a vast array of potentially relevant data. For example, when recommending a patient’s course of treatment, an electronic evidence-based medicine system may consider the patient’s symptoms, medical history, family history, and genetics, as well as historical and geographical trends in disease occurrence and published clinical data on medicinal effectiveness.

Clinically, a significant barrier to CDSS adoption is workflow integration.

Another point of criticism with many medical care systems is the enormous amount of notifications they generate. Apart from the irritation, when systems generate a high volume of warnings (especially those that do not require escalation), clinicians may pay less attention to warnings, resulting in the ignored of potentially vital signals.

The large number of EHR native rule engines, each with its own approach and workflow, creates a difficult environment in which to develop scalable CDS content. Mapping across these different systems is difficult and expensive, and making content changes to reflect new knowledge is perhaps no less difficult. Implementing CDS in a cloud-based environment offers the best opportunity to achieving the desired outcome of scale and spread. Toward that end, using a standards-based, Web API approach makes sense in that it will reduce EHR vendor work, CDS content vendor work, and implementation costs.

Maintenance

One of the primary issues confronting CDSS is the difficulty of combining the vast amount of clinical research released on a continuous basis. Tens of thousands of clinical trials are published each year. At the moment, each of these research must be personally read, appraised for scientific credibility, and accurately put into the CDSS. In 2004, it was said that the process of collecting clinical data and medical expertise and transforming them into a format that computers can modify to aid in clinical decision-making is “still in its infancy.”

Nonetheless, it is more practical for a corporation to handle this centrally, if inefficiently, than for each individual physician to keep up with all published studies.

Apart from being time consuming, integrating new data might also be difficult to quantify or include into the existing decision support schema, particularly in circumstances when clinical publications appear to contradict one another. Correctly resolving these types of inconsistencies frequently requires the writing of clinical papers (see meta-analysis), which might take months to complete.

How Can Clinical Decision Support Be Put Into Action?

CDS can be used on a variety of platforms (such as the Internet, personal computers, electronic medical record networks, handheld devices, or written materials). Planning for a new health information technology (IT) system to support electronically-based CDS includes a number of key steps, such as identifying the needs of users and what the system is expected to do, deciding whether to purchase a commercial system or build the system, designing the system for a clinic’s specific needs, planning the implementation process, and determining how to evaluate how well the system has addressed the identified needs. In the case of CDS, issues around design and implementation of the system are often interconnected.

AHRQ’s CDS Initiative includes a variety of research projects and outreach efforts to develop agreement in the health care field around the use of CDS to promote safe and effective health care. Each part of the initiative attempts to engage clinicians, provider organizations, guideline and quality measurement developers, and IT professionals in the ongoing work to improve making health care decisions using CDS systems.

Types of CDSS

There are different ways by which CDSS can be applied in an EPR application. CDSS can even be applied without an EPR application, to provide stand-alone decision support services. These are as below:

Evaluation

To be valuable, a CDSS must demonstrably improve clinical process or outcome. CDSS evaluation is the process of assessing the value of a system in order to enhance its quality and effectiveness. Because CDSSs serve distinct objectives, there is no universally applicable metric; however, characteristics such as consistency (with itself and with experts) frequently apply across a broad spectrum of systems.

The evaluation criterion for a CDSS is determined by the system’s objective: for instance, a diagnostic decision support system may be graded on the consistency and accuracy of its disease classification (as compared to physicians or other decision support systems). A system of evidence-based medicine may be graded on the basis of its high rate of patient improvement or higher financial compensation for care providers.

Benefits of Clinical Decision Support System

Organizations that use clinical decision support systems get more responses from the end-users. They are effective, provide the right treatment, and the best healthcare plan for the patients.

Here are a few benefits of CDSS and how it is helping healthcare professionals.

Reduce the Risk of Errors

Finding accurate information and doses given to any patient is challenging, especially when he/she is in critical condition. It is reported that over 35% of pediatric medication errors are caused by improper dosage.

Clinical Decision Support could give physicians the idea of dosage according to the patient’s weight, height, and disease. If accurate medication is given, there would be fewer errors.

Improves Efficiency

Deciding on a treatment plan and assessing a patient is a complex task. This requires experience and a lot of effort in collecting accurate information. It is reported that around 25 billion dollars are spent in correcting the mistakes as a result of misdiagnosis. This affects the patient’s health outcome.

With CDSS, physicians have greater chances of delivering accurate outcomes and also avoiding mistakes. This solves the problem before showing error.

Information at Fingertips

By using CDS, the organization is assured of getting reliable information about their specific patient. This information helps them to treat the patient accordingly without wasting time on the research. Also, the CDS system could easily be updated and validated.

The data here is stored in the central location, so there is no need for multiple logins. It also reduces care costs by avoiding unnecessary tests. It delivers the right information at the right time. For any organization, the system must provide meaningful support.

Examples of CDSS

Research into the use of artificial intelligence in medicine started in the early 1970’s and produced a number of experimental systems.

• AAPHelp: de Dombal’s system for acute abdominal pain (1972): An early attempt to implement automated reasoning under uncertainty. De Dombal’s system, developed at Leeds University, was designed to support the diagnosis of acute abdominal pain and, based on analysis, the need for surgery. The system’s decision making was based on the naive Bayesian approach.
• INTERNIST IN (1974): Pople and Myers begin work on INTERNIST, one of the first clinical decision support systems, designed to support diagnosis, in 1970.
  INTERNIST-I was a rule-based expert system designed at the University of Pittsburgh in 1974 for the diagnosis of complex diagnosis of complex problems in general internal medicine. It uses patient observations to deduce a list of compatible disease states (based on a tree-structured database that links diseases with symptoms). By the early 1980s, it was recognized that the most valuable product of the system was its medical knowledge base. This was used as a basis for successor systems including CADUCEUS and Quick Medical Reference (QMR), a commercialised diagnostic DSS for internists.
• MYCIN (1976): MYCIN was a rule-based expert system designed to diagnose and recommend treatment for certain blood infections (antimicrobial selection for patients with bacteremia or meningitis). It was later extended to handle other infectious diseases. Clinical knowledge in MYCIN is represented as a set of IF-THEN rules with certainty factors attached to diagnoses. It was a goal-directed system, using a basic backward chaining reasoning strategy (resulting in exhaustive depth-first search of the rules base for relevant rules though with additional heuristic support to control the search for a proposed solution). MYCIN was developed in the mid-1970s by Ted Shortliffe and colleagues at Stanford University. It is probably the most famous early expert system, described by Mark Musen as being “the first convincing demonstration of the power of the rule-based approach in the development of robust clinical decision-support systems”.
• The EMYCIN (Essential MYCIN) expert system shell, employing MYCIN’s control structures was developed at Stanford in 1980. This domain independent framework was used to build diagnostic rule-based expert systems such as PUFF, a system designed to interpret pulmonary function tests for patients with lung disease.
• CASNET/Glaucoma: CASNET (Causal ASsociational NETworks), developed in the 1960s, was a general tool for building expert system for the diagnosis and treatment of diseases. The most significant Expert System application based on CASNET was CASNET/Glaucoma for the diagnosis and treatment of glaucoma. Expert clinical knowledge was represented in a causal-associational network (CASNET) model for describing disease processes. CASNET/Glaucoma was developed at Rutgers University and implemented in FORTRAN.
• PIP: PIP, the Present Illness Program, was a system built by MIT and Tufts-New England Medical Center in the 1970s that gathered data and generated hypotheses about disease processes in patients with renal disease.
• ABEL Acid-Base and ELectrolyte program. An expert system, employing causal reasoning, for the management of electrolyte and acid base derangements. Developed at the Laboratory for Computer Science, MIT, in the early 1980s.
• ONCOCIN: A rule-based medical expert system for oncology protocol management developed at Stanford University. Oncocin was designed to assist physicians with the treatment of cancer patients receiving chemotherapy. ONCOCIN was one of the first DSS which attempted to model decisions and sequencing actions over time, using a customised flowchart language. It extended the skeletal-planning technique to an application area where the history of past events and the duration of actions are important.
• DiagnosisOne: DiagnosisOne is one of the best CDSS that helps in recording and analyzing health records. It uses SmartConsult CDS module scans and helps doctors in finding the best and effective treatment for their patients. It collects the data from different sources and delivers the information to the decision-makers. DiagnosisOne provides physician activity and health information exchange.
• Problem Knowledge Coupling: Developed by Dr. Lawrence Wee, the PKC could customize the information according to the patient’s condition. It gathers information and sorts them to get the best treatment possibilities for a patient’s condition. It offers tools like subjective, analytical, and objective planning.
• Elsevier Clinical Decision Support: This system is developed by Reed Elsevier Group. It contains a database of medical books, online reference tools, and offers drug reference, analytics, clinical content, and decision support. Check out other data analytics tools that should be used by healthcare professionals.
• Micromedex 2.0: It is one of the most popular CDSS today. Micromedex 2.0 allows physicians and healthcare professionals to get information on computers and smartphones as well. It is available on the app and offers toxicology, medication safety, and health and disease management. It is an easy-to-use tool and gets updated frequently. Micromedex reduces medication errors and improves outcomes. It facilitates decision making in the field of toxicology and alternative medicine and drug information. Micromedex 2.0 provides evidence ratings and supports clinical decision. What’s amazing is it could be accessed anytime and anywhere.
• DXplain: DXplain assists clinicians by generating a diagnosis based on user input. It was developed by Massachusetts General Hospital in 1986. It contains the largest database of information and includes data points and other essential data. It offers test results, diagnosis, and doctor observations. DXplain is used by thousands of healthcare professionals and is growing at a fast pace in the healthcare industry. It is generally used by medical schools and also for clinical consultation.

Characteristics of CDSS

A CDSS is a computerized system that uses case-based reasoning to assist clinicians in assessing disease status, in making a diagnosis, in selecting appropriate therapy or in making other clinical decisions. There are three key elements of a successful CDSS (Musen et al., 2001):

1. Access to accurate clinical data,
2. Access to pertinent medical knowledge
3. Ability to use appropriate problem solving skills.

An effective CDSS involves six levels of decision making: alerting, interpreting, critiquing, assisting, diagnosing and managing . Alerts are a vital component of a CDSS. Automated clinical alerts remain an important part of current error reduction strategies that seek to affect the cost, quality, and safety of health care delivery. The embedded knowledge component in a CDSS combines patient data and generates meaningful interpretations that aid clinical decision making . An effective CDSS also summarizes the outcomes, appraises and criticizes the caring plans, assists clinicians in ordering necessary medications or diagnostic tests, and initiates a disease management plan after a specific disease is identified.

Priorities for accelerating CDS Progress

• Development of CDS content that distills the wealth of information and clinical guidelines into a few action items that will have the biggest impact on patient-centered care.
• Learning from CDS implementing experience, including that related to incorporation into the EHR and delivery to the practitioner in a way that provides optimal support for the recommended clinical decisions.
• Practical strategies for embedding CDS in real-world environments that considers change management, people management, measurement of use, and usability considerations.
• Explication of the value proposition that fosters scale and spread of CDS through the development of clearinghouses and web-based repositories of CDS artifacts that can be shared, evaluated, and continuously improved through feedback from clinicians and patients.

Conclusion

Several tools for the healthcare industry are now accessible on the market. The CDSS helps to enhance the quality and safety of health care. The majority of CDS apps are compatible with EHRs. It may, however, be utilised on its own. It’s important to remember that the Clinical Decision Support System isn’t meant to take the place of a physician’s knowledge and expertise; rather, it’s meant to improve the hospital’s outcomes.