5 Minute Healthtech Jargon Buster: Clinical Decision Support Systems

CDSSs can include a wide variety of decision-making aids, such as computerized alerts and reminders to care providers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic support, and contextually relevant reference information, among other tools [3].

Clinical guidelines and diagnostic support frameworks do not have to be digital, but the modern definition of CDSS tends to focus on health IT applications, modules, or analytics that leverage an organization’s big data assets [4].

Traditional CDSSs are considered knowledge-based and consist of three parts [5]:

1. The knowledge base contains the rules and associations of compiled data which most often take the form of IF-THEN rules. If this was a system for determining drug interactions, then a rule might be that IF drug X is taken AND drug Y is taken THEN alert the user. Using another interface, an advanced user could edit the knowledge base to keep it up to date with new drugs.

2. The inference engine combines the rules from the knowledge base with the patient's data.

3. The communication mechanism allows the system to show the results to the user as well as have input into the system.

CDSSs which do not use a knowledge base use a form of artificial intelligence called machine learning, which allows computers to learn from past experiences and/or find patterns in clinical data. This eliminates the need for writing rules and expert input. However, this can make it harder for these systems to explain the reasons for their conclusions - needed for diagnoses, reliability, and accountability reasons - which motivates specific approaches to design and clinical evaluation which are described below.

Machine learning, which enables a range of different approaches, is well-suited to CDSS which seek to quickly and reliably identify patterns spread across multiple sources of clinical data while at the same time automating expert tasks such as patient examination and real-time monitoring.

A core requirement of any data-driven solution for healthcare is that it simplifies the already-complex tasks of patient care by providing reliable, easy to interpret insights and does not instead simply generate more complex data that risks confusing the healthcare professional, even to the point of ignoring the system entirely. This is particularly true of CDSS whose role is to alert or warn users working in busy environments such as hospitals [6].

CDSS alerts can save lives, but frequent insignificant ones might cause alert fatigue. Studies discuss that 33% to 96% of clinical alerts are ignored. A CDSS has the p[otential to generate a high number of inappropriate alerts that interrupt the clinical workflow. As a result, clinicians will silence, disable, or ignore alerts, thereby undermining patient safety. This behaviour is known as alert fatigue. Many CDSS alerts were not properly designed based on human factor methods and principles, explaining high alert overrides in clinical practices [7].

Fortunately, we can learn from other safety-critical applications, including aviation and surgery, where alert-fatigue is well understood and mitigating strategies can be studied and applied [8].

Evidence-based strategies to reduce alert fatigue and improve CDSS utilization can be categorised into five major areas:

1. Classify alerts in to three main levels; severe, moderate and minor then develop a core set of critical drug to drug interactions.

2. Classify alerts into active and passive groups, where only critical alerts should be interruptive actively while less critical alerts should be non-interruptive to the user.

3. Conduct regular user training on new improvements.

4. Keep monitoring alert response rates and keep ongoing research and improvement efforts.

5. Provide systems with automated feedback and learning mechanisms where frequently ignored and justified alerts could be moved automatically from the active interruptive to the passive non-interruptive model.

When developing CDSSs, manufacturers should ask users during development, testing and implementation: “At what point does the alert hurt you?”

As the line between CDSS and diagnostic can be subtle if not blurred, recent guidance from authorities such as the FDA has provided clarity on the mandatory regulations for these tools [9]. Unless the CDSS meets all four of the following criteria, it will need to be regulated as a medical device.

• Criterion 1: The software function is not intended to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system

• Criterion 2: The software function is intended for the purpose of displaying, analysing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines)

• Criterion 3: The software function is intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis or treatment of a disease or condition and

• Criterion 4: The software function is intended for the purpose of enabling such healthcare professional to independently review the basis for such recommendations that the software presents so that it is not the intent for such healthcare professional to rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

Many examples of CDSS seek to predict an event ahead of time, for example a patient needing to be admitted to intensive care, so that it can be preventatively managed or averted entirely and as a result the concept of a “silent trial” has gained some popularity. This is where a CDSS is operated alongside existing clinical practise and the predictions offered by the CDSS are compared to what transpires in practise, not yet allowing for intervention based on the prediction itself.

This early clinical evaluation provides a crucial scoping evaluation of clinical utility, safety and human factors challenges in live clinical settings. By investigating the potential obstacles to clinical evaluation at scale and informing protocol design, these studies are also important stepping stones toward definitive comparative trials.

However, the strongest evidence for these tools is when they can be shown to measurably improve patient outcomes, for which a full clinical study is required [10]. Here there is a substantial body of guidance on risk management [11], reporting clinical benefit in a replicable manner including human factors such as alert fatigue [12] as well as more generally across diagnostic and prediction technologies to guard against the risk of bias [13].