The following article is a module I wrote for the Faculty of Clinical Informatics (FCI). This will hopefully still be published as part of an education resource for early career-stage clinical informaticians. In the meantime I thought I would publish it here.
Learning Outcomes:
1. Define/ understand clinical decision support (CDS)
2. Overview of some common CDS tools
3. Basic understanding of programming considerations for CDS
4. Understand how CDS can support clinicians in delivering evidence-based care
5. Understand the limitations of CDS
6. Future developments in CDS
1. Introduction
Clinical decision support (CDS) systems are defined as tools that can support clinicians to deliver more equitable, evidence-based care[1]. They can be used across care settings, specialties and pathways to improve healthcare delivery and reduce errors. As clinical practice becomes increasingly complex and is being delivered by a wider range of professionals CDS can support clinicians to take standardised actions. They can promote best, or evidence-based, practice by supporting clinicians with the right information, for example targeted clinical knowledge, patient or other health information, at the time of decision-making[2]. They have been shown to enhance the quality of decision-making, reduce errors and unwarranted variation, as well as support shared decision-making2. Symptom checkers are sometimes classified alongside CDS. Symptom checkers are calculators that ask users to input details about their signs and symptoms of sickness, along with demographic information such as gender, age and location. Using computerised algorithms, the self-diagnosis tool will then give a range of conditions that might fit the problems a user is experiencing[3]. These calculators are designed to be used by patients and not usually by clinicians, consequently they have been considered as out of scope for this module.
Since their first use in the 1980s, CDS have seen a rapid evolution. They are now commonly provided via electronic patient records (EPR) or by other computerized clinical workflows. This move has been facilitated by increasing global adoption of EPRs with advanced capabilities3. The majority of CDS in current use are primarily used at the point-of-care, whereby the clinician combines their knowledge with information or suggestions provided by the CDS. Increasingly however, CDS systems are being developed with the capability to leverage data and observations otherwise unobtainable or uninterpretable by humans.
1.1 Types of CDS
We can think about CDS in two broad categories, knowledge based versus non-knowledge based (e.g. using artificial intelligence (AI)) systems3. Figure A. In knowledge-based systems, rules, for example IF-THEN statements are created, with the system retrieving data to evaluate the rule, and producing an action or output. An example of a knowledge-based CDS would be using Q-risk to calculate a person’s risk of developing a heart attack or stroke over the next 10 years[4]. This system uses a range of known factors, which may be entered manually or self-populated from information held in an EMR, to calculate the risk based on the rules held in the model.
CDS models are composed on (1) base: the rules that are programmed into the system (knowledge based), the algorithm used to model the decision (non-knowledge based), as well as the available data, (2) inference engine: Takes the programmed or AI-determined rules, and data structures, and applies them to the patient’s clinical data to generate an output or action, which is presented to the end-user through the (3) communication mechanism e.g. the website, application, or via the EMR frontend interface by which the user interacts with the system.
CDS that are non-knowledge based still require a data source, but the decision leverages AI, machine learning (ML), or statistical pattern recognition, rather than being programmed to follow expert medical knowledge3. In non-knowledge based systems the ‘training’ of the CDS is based on either real or synthetic data, which provides the basis from which outcome classification is based. An example of this type of non-knowledge based CDS would be one of the systems being developed using AI in imaging, for example mammography. The AI software detects and displays suspicious features in the image, and predicts the likelihood of malignancy, to help clinical diagnosis[5].
1.2 Examples of CDS
CDS can provide a range of support to the clinicians using them and fall into a range of broad categories. They include: clinical calculators, diagnostic support, prescription support, medication control, patient data reports, documentation templates, clinical workflow tools, alerts or alarm systems, automated order sets or links to reference guidelines or educational materials within an EMR or other system [2,3].
2. How they work?
From a computational perspective knowledge based CDS system decision rules are often represented in one of two formats: procedures and production rules. For use within clinical practice a number of issues arise with these formats. These issues include lack of specificity and lack of standardisation. In this context a lack of specificity means an inability to distinguish between inputs which may have similarities but should have different outputs, for example a CDS which was unable to distinguish between the likelihood of a viral and bacterial infection would not be able to pick which set of symptoms might require an antibiotic prescribing. A lack of standardisation means that the outcome may not be replicated for the same or similar input data. These deficits have led to the development of a further format, the Arden Syntax[6].
We will not cover further detail of the non-knowledge based CDS systems here as it is beyond the scope of the module, but it is discussed further in our Bitesize introduction to AI module.
2.1 Procedure
A procedure is typically a series of statements that are executed serially in the order that they appear in the unit of knowledge. This can be represented graphically as a decision tree. In the example, provided in Figure B, for a patient presenting with a sore throat the CDS takes the clinician through the questions in the order that they appear, producing an outcome at each level, either a suggested diagnosis, or a follow-up question [6].
The data elements describe common symptoms of throat infections, erythema means redness, and adenopathy is swollen glands.
2.2 Production rules
Production rules consist of repeated cycles of match, select and execute tasks, applying the knowledge base against the data available to the CDS in order to reach a desired conclusion, for example establishing a diagnosis or recommending a treatment. These programs consist of condition ⇒ action rules, known as productions. The programs are processed by an interpreter which repeats the following operations:
1. All rules whose conditions are satisfied are found (rule matching)
2. One of them is selected (conflict resolution)
3. The output is based on the action of the rule selected, called (rule firing).
The feature which distinguishes a production rule form one using procedural knowledge is that each IF-THEN rule is independent of every other one and can be executed without any regard to the execution state of any other rule. Consequently, the order of execution cannot be guaranteed [7].
Production rules can be represented graphically as a decision table with columns each headed by a data element deemed important in making decisions in a particular domain, along with a column for the action (output). Each sequence in the table is equivalent to a single IF-Then rule. The values on the left side, not all of which need to be present, are associated with an outcome on the right-hand side. In the example, in Figure C, the same sore throat example as shown in Figure B is used, but the questions don’t need to be asked in a specific order for an output to be reached. Again, the data elements which head each column describe common symptoms of throat infections.
In the first row none of the symptoms are present, so no conditions are satisfied, leading to the output of a non-infectious or viral cause of the presented symptoms. In the second and third rows the combination of rules matched and those not matched lead to an action or diagnosis of viral sore throat. In the final row the combination of rules matched leads to a diagnosis of bacterial sore throat.
Each piece of information in the table represents an association between specific values for clinically important variables (conditions) and the diagnosis (action) that can be inferred from those findings.
2.3 Hybrid decision rule
The Arden Syntax was developed as a hybrid of Procedures and Production rules. It is a widely recognised standard for representing clinical knowledge, it features a choice of data types tailored to the needs of clinical documentation, e.g. measures for time and duration, and is equipped with a set of features which suit its use in CDS7. The program code resembles natural language, making the code easier to understand by non-experts in computer science, and enabling decision support logic to be represented independently from the system programming language and consequently it can be used within different systems.
The code is organised in self-contained files called Medical Logic Modules (MLMs). The execution of an MLM can be triggered by specific data- or time-based events or by a direct call, and each MLM contains enough references and logic to make a single clinical decision. An example of a simple MLM is shown in Figure D.
Figure D – A CDS system using Arden Syntax to check the diastolic blood pressure of a patient[7]. [Unable to reproduce Figure D here – see https://en.wikipedia.org/wiki/Arden_syntax for details] We can see from this example that the programme runs through a series of steps to determine if the reading is within the normal range.
Each MLM is a procedure, in which the logical statements execute serially. However, each MLM also functions independently like a production rule, whereby a separate trigger that when satisfied by some specific data, for example time, causes the model to execute and produce some action. Consequently, this approach is considered a hybrid of the procedural and the production-rule forms of knowledge representation [7].
3. Advantages
The use of CDS aims to provide improvements in patient care, providing more standardised and / or evidence-based care practices, and improving patient safety. Areas in which CDS systems are cited as providing clinical advantage are:
· Reduction in medication errors
· Standardised/ protocol driven clinical management
· Cost containment e.g. reduction in duplications of care
· Administrative function automation e.g. clinical coding
· Diagnostic support
· Better documentation
· Workflow improvement [3]
As with many things, despite the logical basis, with improved care and patient safety as drivers for their implementation and use, the evidence is less definitive. A meta-analysis of CDS systems looking at 122 trials with data from more than 1 million patients showed that CDS systems produced an average absolute improvement of 5.8% (95% confidence interval 4.0% to 7.6%) in the percentage of patients receiving the desired process of care [9]. This may seem like a relatively small absolute improvement. However, for some processes of care, such as vaccinations and evidence-based cancer screening, even a small increase in the percentage of patients who receive this care will translate into worthwhile benefits at the population level. For many other processes of care, where the recommendation has a weaker connection with important outcomes, a small increase in adherence may not justify its implementation [9]. The following section outlines some of the considerations which are likely to influence the successful and consequently likely improved benefit for CDS implementation.
4. Requirements for a successful CDS
A variety of criteria have been identified which are associated with effectiveness in CDS. These internal qualities of a CDS system can be summarized as 5 Rights to support clinical decision making [2]. These Rights are:
· Right information: evidence or guideline based CDS that incorporates stakeholder inputs and aligns with current improvement initiatives.
· Right person: CDS must meet the specific needs of everyone in the multidisciplinary clinical team. Users should be aware of the purpose and limitations of the CDS, and how to report issues with its advice.
· Right format: CDS formats must present information to clinicians in a manner that complements workflows; for example, best practice alert, visual dashboard, smart order set, customised referral. Those writing CDS advice should be aware of good practice in risk communication (for example, use 1 in 100 rather than 1% risk) and avoid interrupting clinical tasks unless there is an immediate risk of serious error.
· Right channel: User experience needs to be considered. CDS should focus on the context of use, to ensure presented information does not disrupt workflows. Where possible and appropriate, it should be integrated within the primary EHR system.
· Right time: CDS must be integrated and seamless within the clinical workflow. CDS should operate across different care settings [2].
In addition to the inherent properties within a model, successful implementation and use also requires consideration of the system in which the CDS is to be deployed. The 6i model, shown in Figure E, has been developed to take into accounts those factors which might influence outcome [2]. The 6i’s are:
· Intelligent: CDS systems need to be evidence based and address real-world clinical decisions that would benefit from best practice support.
· Interpretable: CDS systems need to consider the healthcare professional’s knowledge of the topic, use clear and unambiguous content, and demonstrate validity and reliability of recommendations by linking to relevant explanations or evidence.
· Integrated: CDS systems need to be designed to complement workflows. Integration with clinical systems can increase impact by embedding decision support in clinical workflows.
· Impactful: CDS systems need to consider the experience of users, improve productivity and outcomes, and be clinically safe with mitigations made to reduce potential risks.
· Interoperable: CDS systems need to interpret clinical data from systems to minimise manual data entry and present result data within relevant clinical systems by using open application programming interfaces (API) whenever possible.
· Inclusive: CDS systems need to consider a broad range of end users, be based on trusted clinical data that is representative of the target population and help minimise health inequities by standardising care [2].
5. Limitations
Despite the research suggesting effectiveness, the models developed around implementation and use reflected above indicate that the uptake of CDS systems remains inconsistent. In addition, when CDS is used in the wrong way or implemented without full consideration of the context and/ or stakeholder needs there can be negative impacts which should not be underestimated.
The downsides of CDS systems include:
· Disruption to or fragmentation of clinical workflows
· Alert fatigue or inappropriate alerting
· Impact on user knowledge or skill, causing issues if the CDS becomes unavailable
· The impact of poor quality data or even incorrect content [2,3].
One of the key barriers to use is poor integration with existing IT systems or EPRs causing the need for users to log in or access the required CDS separately, this can cause significant barrier to workforce engagement [2,7]. In addition CDS cannot be seen as a static system, they need to be updated as new clinical knowledge and evidence emerges, or new guidelines are released and accepted [2,3]. As recognised in other common improvement interventions, such as bundles, checklists and financial incentives to promote good practices, CDS can become an ‘off the shelf’ intervention. In this way they may be implemented without much consideration of the way they work or the degree to which they would help with the identified problem. In these cases, the decision to use a CDS may reflect the ease of deployment rather than the likely outcomes of deployment9. Finally, there can also be financial challenges, CDS systems may be operated under licencing agreements and healthcare organisations may need to consider the cost of continued subscription [3].
5.1 Specific Negative features
Two specific features that can occur in CDS and can be very disruptive to clinical workflow are summarized here:
Ambush – A CDS that is likely to appear when not relevant to the immediate clinical task being performed by the user (e.g. a pop-up prompting the user to order vaccinations upon opening a patient’s record at all visits, not just screening visits).
Interruptive – A CDS that appears on screen and stops the user from performing any further tasks until it is either “acknowledged”, further information is added or a button is pressed to exit the loop, such as the Escape key [9].
5.2 Regulatory Considerations
Most CDS will have a clinical purpose as they are designed to support clinical processes and will need to be compliant with the NHS Clinical Risk Management standards[9]. Some may also be classed as software as a medical device, and will consequently require the development of a technical file to support this compliance[10].
Meeting the requirements for regulatory compliance may be particularly challenging for non-knowledge based CDS, this is due to challenges with understanding and trusting the logic that AI uses to produce recommendations (black boxes), issues in relation to the population used in training data, with the potential to cause bias, and problems with data availability and quality, for example [3, [11].
As referenced above CDS will need maintenance, and ongoing quality assurance to ensure that the guidance that they provide remains current and meets best practice.
The potential negative features of CDS captured here, particularly when it comes to deployment and use in real-world clinical settings, could explain the small size effects they typically achieve when it comes to measurable outcomes. The importance of informing the use of CDS with a rich sociotechnical model including the human-factors, hardware and software computing infrastructure, clinical content, user group, workflow, communication, organisational structure etc is understood, however these considerations, and the complex interplay between the factors, is often not fully considered when developing or implementing CDS systems [9].
6. Future developments
CDS continues to develop, and as we have indicated above one of the areas of ongoing development is the application of AI and ML in the non-knowledge based CDS systems. By leveraging ‘big data’ gathered from analysis of millions of health records it seems likely that the predictive ability of the models will continue to increase. There is already a move to provide prognostic risk prediction models, aiming to estimate the risk of a future outcome based on available data, and prompt proactive action to reduce this risk. These models which can provide individualised risk for patients are the foundation of precision medicine [3,[12].
As healthcare providers increasingly turn to unified EPRs, the success of risk prediction models will be dependent on the integration of tools within these systems. Usability barriers may be mitigated if clinicians can access risk prediction tools, with relevance to their practice, within their local EMR and have a risk score presented automatically as fields are populated with required data from within the system. This intuitively simple concept would create a paradigm shift for the practical daily use of such tools and translate to patient benefit [13].
When we look at the future development of the health technology sector in more general terms, we can also see areas of alignment and development which will impact or synergise with the development of CDS. The Topol Review summarized the top 10 digital healthcare technologies and their likely impact on healthcare in the short to medium term[13]. Figure F, taken from The Topol Review shows these ten technologies diagrammatically. The Topol Review was published in 2019 and it is already possible to see advances that have been made in the interim period.
Looking at some of the examples shown, we can see how they may impact the development of CDS.
Sensors and wearables, for diagnostics and remote monitoring. These bring diagnostics and monitoring ever closer to the patient and will be linked into CDS providing real, or close-to real time management of changing parameters. Closed-loop systems in which there is no need for a ‘clinical decision’ will become more prevalent.
Remote monitoring. The sharing of patient generated data with the healthcare workforce enables remote monitoring, but this needs to be integrated within clinical pathways. The application of AI to generate patient summaries, and the use of CDS as a mechanism to provide the next suggested action based on these summaries may provide a clinically useful solution.
Speech recognition technology could be built into smartphones, allowing recognition when a person’s speech pattern changes which could be an earlier indicator of a stroke for example, and could trigger a clinical review.
Further development of automated image interpretation will provide enhanced diagnostics in dermatology, radiology, ophthalmology and pathology. Digitised scans will increasingly be used to train deep learning systems and can then be used to reduce the time, cost and clinical resource required to analyse scans. By linking with CDS clinicians can be provided with bespoke analytic support at an individual patient level.
Predictive analytics at population level is already being used in several areas including frailty. The Electronic Frailty Index uses health data routinely collected in GP record systems and allows proactive local identification of older people at risk of adverse health outcomes and care home admission. Predictive modelling using machine learning applied to large, carefully annotated datasets is a more recent advance, for example, personalised treatment algorithms, patient triage algorithms and risk prediction. These methods are now being applied to EMR data which is largely unstructured, and not carefully annotated, and are being shown to be capable of accurately predicting multiple medical events from multiple centres. AI can also identify unexpected physiological deterioration and predict subsequent outcomes for in-hospital patients and help to predict individual response to treatment [14].
Predictive analytics and modelling are not new to healthcare. Clinical risk scores based on statistical regression models have been used for decades, but the ways in which they are being used, and the scale on which they can be implemented is really where these technologies are likely to have impact in terms of population level health outcomes.
The Topol Review also summarizes a Virtual Medical Coach Model, Figure G. In this model the convergence and complementarity of three major technologies – genomics, sensors and AI – enables patients to self-manage chronic conditions or achieve prevention for those at high-risk of developing a condition. Integration of these multi-modal data, from multiple sources, with associated analysis underpinned by individualised models, e.g. the impact to the individual based on analysis of both personal and population level data, will realise the full potential of true personalised medicine. Rather than relying on a concept of the normal derived from population studies, AI techniques such as deep learning will be used to define normality for an individual, and hence identify any deviation from it, using that individual’s genomic, anatomical, phenotypic and environmental data, and its variations over time [14]. There has been an increase in the development of such models since they may provide individualised risks for patients [2,13.]
In summary the future development of CDS seems to fit into two broad categories:
· The use of decision support combined with artificial intelligence (AI) to help clinicians, and the patients themselves, to apply best practice, to eliminate unwarranted variation across the whole pathway of care, and provide better overall management of health.
· The use of predictive techniques to support local health systems to plan and manage care at population level [15].
1. https://fci.org.uk/menu2/professional-competencies/core-competency-framework.html
3. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7005290/
4. https://patient.info/symptom-checker
6. https://www.nice.org.uk/advice/mib242/chapter/The-technologies
7. https://www.sciencedirect.com/science/article/pii/S1532046412000226
8. https://en.wikipedia.org/wiki/Arden_syntax
9. https://pubmed.ncbi.nlm.nih.gov/32943437/
10. https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
11. https://www.gov.uk/government/publications/medical-devices-software-applications-apps
12. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8521931/