A scoping review of rule-based clinical decision support malfunctions

Abstract

Objective

Conduct a scoping review of research studies that describe rule-based clinical decision support (CDS) malfunctions.

Materials and Methods

In April 2022, we searched three bibliographic databases (MEDLINE, CINAHL, and Embase) for literature referencing CDS malfunctions. We coded the identified malfunctions according to an existing CDS malfunction taxonomy and added new categories for factors not already captured. We also extracted and summarized information related to the CDS system, such as architecture, data source, and data format.

Results

Twenty-eight articles met inclusion criteria, capturing 130 malfunctions. Architectures used included stand-alone systems (eg, web-based calculator), integrated systems (eg, best practices alerts), and service-oriented architectures (eg, distributed systems like SMART or CDS Hooks). No standards-based CDS malfunctions were identified. The “Cause” category of the original taxonomy includes three new types (organizational policy, hardware error, and data source) and two existing causes were expanded to include additional layers. Only 29 malfunctions (22%) described the potential impact of the malfunction on patient care.

Discussion

While a substantial amount of research on CDS exists, our review indicates there is a limited focus on CDS malfunctions, with even less attention on malfunctions associated with modern delivery architectures such as SMART and CDS Hooks.

Conclusion

CDS malfunctions can and do occur across several different care delivery architectures. To account for advances in health information technology, existing taxonomies of CDS malfunctions must be continually updated. This will be especially important for service-oriented architectures, which connect several disparate systems, and are increasing in use.

Background and significance

The design and architecture of health information technology (HIT) are in the process of a transformative shift.¹ Software as service (SAAS) and cloud-based strategies are changing the way EHR systems and their ancillary components are implemented. Breakthroughs in health information exchange standards and application programming interfaces (API) that utilize modern internet protocols, such as Fast Healthcare Interoperability Resources (FHIR) and SMART, are supporting a shift to new distributed systems.^2–4 Several examples of this shift are present within the literature. One team created applications showcasing the potential of SMART and FHIR for both patient and provider-facing use cases.⁵ Other researchers demonstrated a prototype application that coordinated the use of several standards for drug-drug interaction.⁶ Even the content (eg, patient data) that feeds into these systems is becoming increasingly distributed.⁷ A major goal of the Trusted Exchange Framework Common Agreement (TEFCA) is to establish a baseline level of interoperability to allow for a nationwide system to safely and easily share patient health information.^8,9

However, these changes in design and architecture may impact the potential for patient risk. Duplicate or discordant data and system failures become increasingly likely as the variety and number of connections between systems increase.¹⁰ Clinical decision support (CDS) is a prime example of how this shift in architecture has created new modes of failure. CDS systems were introduced to improve patient safety and the quality of care provided. The ability of CDS to improve healthcare delivery has been so impactful that multiple stages of Meaningful Use require CDS.^11,12 Unfortunately, CDS has not been without risk, with several studies highlighting the ways in which these systems can malfunction.^13–16 Given the pressing need for a better understanding of the ways in which CDS malfunctions, researchers developed an empirical taxonomy categorizing malfunctions across several health systems.¹⁷ The taxonomy, however, was derived, in large part, from rule-based CDS (eg, derived from clinical algorithms instead of machine learning or other statistical techniques) developed using native EHR tools. As with all HIT, CDS architectures have evolved over the years from stand-alone systems to an increasing number of service-oriented systems. These models of CDS may have different failure mechanisms and impacts,¹⁸ but there has been little, if any, research that synthesizes this information. In this paper, we begin the process of understanding how system design can impact components such as CDS in addition to the function of the overall system.

Objective

The objective of this article was to conduct a scoping review of research studies that describe rule-based CDS malfunctions. We examine malfunction characteristics according to an existing taxonomy and provide additional attributes that have not yet been established.¹⁷ Particular attention is focused on the relationship between the type of CDS delivery architecture (eg, integrated or service-oriented), cause of the malfunction, and impact the malfunction has on the system (eg, CDS tool itself or the larger host system, such as an EHR).

Methods

This review was conducted in accordance with the five stages outlined in the methodological framework for scoping reviews from Arksey and O'Malley,¹⁹ which is based on the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA).²⁰ To be included in the review, papers needed to describe, in sufficient detail, a rule-based CDS system that was in production use by healthcare providers at the point of care. For the purposes of this review, we use the definition of CDS malfunction from Wright et al,¹³ which defines a malfunction as situations where “CDSS does not function as it was designed or expected to.” Further, we employ a sociotechnical model that highlights both technical and non-technical aspects of HIT in use, including internal policy, workflow, and communication.²¹ For inclusion in this review, the malfunction must be original to the paper. Given the anticipated paucity of information about CDS malfunctions, conference abstracts and proceedings were also included in the review. Papers were excluded if they were not written in English, the system did not meet the requirements of CDS, the CDS was intended for use by patients, not healthcare providers, or was non-electronic. For the purposes of this review, we used a narrow definition of CDS to include only event-based systems, such as CPOE with alerting functionality and point-of-care reminders. Examples of CDS that did not meet this criterion include CPOE without alerting and order sets.

To identify relevant documents, we searched the bibliographic databases MEDLINE (Ovid), CINAHL, and Embase in April 2022 for all literature referencing CDS malfunctions (see Supplementary Appendix A for the full query). A commercial systematic review tool (Covidence, Melbourne, Australia) was used for curation and reconciliation across reviewers as well as data charting.

After an initial abstract and title review (J.G.T.), two authors (J.G.T. and J.M.M.) performed a full-text review of 64 papers. Data extraction captured relevant descriptive characteristics (eg, study and clinical setting) and details about the malfunction, which were coded using the axes provided by the CDS malfunction taxonomy developed by Wright et al.¹⁷ These included: (1) cause; (2) how discovered; (3) when discovered; (4) effect on rule firing. Since this taxonomy was largely based on rule-based CDS developed using features native to the EHR, we added six categories (time to discovery, architecture, data source, data format, clinical impact, and scale of impact) to the extraction template. The additional categories are defined as follows:

1. Time to discovery—How long from implementation it took to identify the malfunction, coded as real-time (within minutes), near real-time (within hours), delayed (within days), retrospective (anything beyond days).

2. Architecture—Based on the categories defined by Wright and Sittig,²² which are:

   1. Stand-alone—Isolated systems, often requiring manual input (eg, web calculators and early expert systems).²³

   2. Integrated—Embedded within an existing clinical information system, such as the EHR.

   3. Standards-based—Specifications designed to standardize CDS content (eg, Arden Syntax and Guideline Interchange Format [GLIF]).^24,25

   4. Service-oriented—Distributed systems that decouple the CDS code from the clinical information system, but include a method to connect the two through application programming interfaces (eg, SMART and CDS Hooks).^3,26

3. Data source—Where the data for the CDS system was retrieved from. For systems using multiple sources, each source was listed individually.

4. Data format—The specification, if any, used to exchange information between the data source and the system. Examples include FHIR, HL7 V2, and continuity of care document.

5. Clinical impact—The clinical impact associated with the CDS malfunction. This could be based on individual patients (eg, readmitted) or population (eg, hospital-wide increase of venous thromboembolism rate).

6. Scale of Impact—How wide the malfunction was felt. This could be defined in terms of alerts (eg, missed or excess fires), patients, or time.

Two authors (J.G.T. and J.M.M.) independently charted data for 21% (n = 6) of the included papers, which follows the process outlined in prior reviews.²⁷ Discrepancies were resolved through discussion. Inter-rater reliability during charting was almost perfect (Cohen’s Kappa greater than or equal to 0.81), with disagreements occurring due to limited availability of context for the CDS system. In addition, during the independent charting process, both reviewers identified the need to expand the existing taxonomy. As a result, new codes were developed by two authors (J.G.T. and J.M.M.) and reviewed by all authors. Disagreements were resolved through discussion. After consensus was reached, one author (J.G.T.) charted the remaining 79% using the final template.

A comprehensive review of all identified malfunctions was completed after all data charting to ensure the malfunctions identified were not repeated across selected papers. This step was taken to avoid skewing our results based on malfunctions that were used across multiple projects. For instance, some malfunctions were used as examples in multiple papers to test different methods for identifying malfunctions through statistical methods. In situations where a duplicate was identified, the first reference to the malfunction was maintained for final review.

For all coded data, if the paper did not explicitly state the information sought for extraction, we attempted to infer details from context within the paper. Where this was not possible, “Not defined” was used. In addition, the level of specificity used to describe each malfunction varied widely across papers. Some malfunctions were described in detail, while collections of others were summarized together (eg, we made changes to alert text and updated errors in logic for 25 alerts). In these situations, because we were unable to correctly identify the number of actual malfunctions, we included the relevant malfunction only once. Further, since individual papers could describe several settings, systems, and malfunctions, in addition to characteristics of the paper, we split each malfunction into a separate entry and then grouped the extracted data across multiple axes (eg, architecture, cause, and impact). Descriptive summaries are provided for each axis.

Results

Our search identified 9145 potentially relevant articles. Of these, 4081 were retrieved from Embase, 3431 from Medline, and 1633 from CINAHL. After removing duplicates, the remaining 5868 articles were screened based on title and abstract, leaving 64 studies for full-text review. Of these, 36 were removed for the following reasons: 11 did not describe a malfunction, 8 did not include enough detail about the malfunction, 8 described a CDS not in production use at the time of the search (eg, research prototypes or non-production testing), 5 did not include an original malfunction, 2 described non-rule-based CDS, 1 did not describe a malfunction from a CDS system and 1 was a duplicate discovered through post data-charting analysis. Twenty-eight papers were included in the final review (Figure 1).

Figure 1.

Article review process.

Paper characteristics

The 28 papers described malfunctions from more than 31 different organizations (Table 1). There were 20 full papers, 3 case reports, 3 abstracts, and 2 conference papers. A majority of papers included an objective to identify malfunctions originating from a CDS system (n = 17, 61%) and were published after 2014 (n = 18, 64%). Most papers included academic medical centers (n = 20, 71%), were from the United States (n = 20, 71%), and described systems using the EHR or other similar health information system (HIS) as the primary data source (n = 24, 86%). Only 2 (7%) papers evaluated CDS malfunctions across all clinical settings, with a majority (n = 15, 54%) focused on a single setting (eg, emergency, inpatient, or primary care). Articles were not consistent in reporting clinical impact or scale of impact.

Table 1.

Paper and CDS system characteristics.

Paper				CDS system
Ref	Year	First author	Malfunction focused	Academic	Country	Clinical setting
13	2016	Wright A	X	X	United States	Not defined
14	2017	Kassakian SZ	X	X	United States	Inpatient
15	2019	Thayer JG	X	X	United States	Primary care
17	2018	Wright A	X	X	United States	Inpatient Outpatient
28	2008	Mille F		X	France	Inpatient
29	1993	Thomsen GE		X	United States	Inpatient
30	2008	Wadhwa R	X	X	United States	Inpatient
31	2010	Strom BL		X	United States	Inpatient
32	2011	Wetterneck TB	X	X	United States	Intensive care unit
33	2014	Lee J			South Korea	Inpatient
34	2017	Schreiber R	X		Not defined	Emergency department Inpatient
35	2018	Stone EG	X		Not defined	Inpatient Emergency department
36	2018	Yoshida E	X	X	United States	All
37	2019	Rubins D	X	X	United States	All
38	2020	Riley JD		X	United States	Not defined
39	2021	Wright A	X	X	United States	Not defined
40	2021	Feldman J	X	X	United States	Telemedicine
41	2022	Phadke NA	X	X	United States	Not defined
42	2021	Pannu SR		X	United States	Intensive care unit
43	2016	Mafi JN		X	United States	Not defined
44	2003	Rogers JE			UK	General practice
45	2005	Chan AS	X		United States	Primary care
46	2019	Rubins D	X	X	United States	Inpatient Outpatient
47	2017	Spat S		X	Austria	Inpatient
48	2019	Flint R			UK	Primary care Palliative care Oncology
49	2019	Patel R	X	X	United States	Urology
50	2009	Hanuscak TL	X		United States	Not defined
51	2013	Mohr NM			Not defined	Emergency department

Malfunction characteristics

Across all papers, 137 distinct malfunctions were identified. Post-data charting analysis of the malfunctions identified 7 duplicates, leaving 130 in the final review (see Table S1 for a full list). The malfunctions are further described across nine axes in the sections below.

Architecture

System architecture could be determined for 125 (96%) malfunctions: integrated (n = 93, 72%),^{13,14,17,28–41} service-oriented (n = 31, 24%),^{13,15,17,36,41–47} and stand-alone (n = 1, 1%).⁴⁸ No standards-based CDS malfunctions were identified. We believe this is likely due to the limited number of implementations of these systems, which were never widely accepted within the industry. The single stand-alone architecture was a web-based application. Design variation also existed within integrated and service-oriented architectures as well. For example, while several integrated systems relied on native EHR features (eg, rule builders) to develop the clinical logic associated with the CDS, others developed their own algorithms that were loaded into the EHR software. Service-oriented architectures also varied, with some systems connecting individual components (eg, rules engines or knowledge databases) to native alerts within the EHR (eg, native rule-based alerts), while others embedded full applications using integration frameworks similar to SMART.

Cause

This axis captures the underlying reason for why the CDS malfunction occurred. Within the original taxonomy, 10 causes were identified. Based on the expanded set of CDS architectures within our review, three new types of causes were identified (organizational policy [n = 3, 2%],^31,34,49 hardware error [n = 2, 2%],^29,50 and data source [n = 1, 1%]²⁹) and two existing causes were expanded (Table 2). First, due to the variation in detail provided about each malfunction, a new general software error category was created with “Defect in EHR software” added as a child. Second, “External Service Issue” was expanded to include three child categories: networking (n = 6, 5%),^17,42,47,50 component failure (n = 4, 3%),^13,17,36 and information exchange (n = 3, 2%).^41,46

Table 2.

Root cause of the malfunction.

Cause	Count
Software error	27
Defect in EHR software	10
Conceptualization	21
Build error	18
New code, concept or term introduced, but rule not updated	15
External Service Issue
Networking	6
Component failure	4
Information exchange	3
Environment migration	7
New value	6
Organizational policy	3
Inadvertent enabling/disabling	3
Alert text mismatch	3
Hardware error	2
Unaware of component reuse	1
Data source	1

How discovered

This axis identifies the mode of discovery for the CDS malfunction and was expanded to include five new categories (see Table 3). In addition to reported by an end user, which captures malfunctions recorded through incident management systems (eg, help desk), we added user feedback to identify situations where users were actively engaged by members of the CDS team and user survey for malfunctions identified through survey methods. Just over half of malfunctions were identified by an end user (n = 70, 54%) with the following breakdown: reported by end user (n = 48/70),^{13,15,17,35,36,46} user feedback (n = 16/70),^{30,34,37,45,47} review of override reasons (n = 3/70),¹⁷ and user survey (n = 3/70).⁵⁰ Only one malfunction was discovered using multiple methods (reported by end user and a review of firing data)³⁶ and only one method did not require human initiation (automated review of firing data).³⁶

Table 3.

How malfunctions were discovered.

How discovered	Count a
Reported by an end user	48
Study team analysis	24
Review of firing data	23
User feedback	16
Testing	5
Not defined	3
User survey	3
Review of override reasons	3
Review of input data element usage	2
IRB Committee	1
During investigation of other error	1
Safety database review	1
Demonstration of system	1

^aCount is higher than total number of malfunctions since one malfunction was identified using two methods.

When discovered

This axis identifies when the malfunction was introduced into the system, either occurring from its implementation in production or after deployment into production (Table 4). The percentage of malfunctions present upon implementation was higher for integrated architectures (58/93, 62%)^{17,28–39,41} compared to service-oriented architectures (15/31, 48%).^{15,17,41–45,47}

Table 4.

When the malfunction was discovered.

When discovered	Count
Integrated
After deployment into production	35
From its implementation in production	58
Service oriented
After deployment into production	16
From its implementation in production	15
Not defined
After deployment into production	1
From its implementation in production	4
Stand-alone
From its implementation in production	1

Impact on system

This category is a modified version of the original taxonomy's “Effect on Rule Firing” and includes additional categories. While the original taxonomy includes a category focused on the impact on the host system (“Rule fires in the correct situation, but causes the EHR to operate slowly”), we felt the name change was necessary to acknowledge the potential of CDS malfunctions to impact areas beyond the rule that triggers the CDS. Seven malfunctions (5%) impacted the EHR, with four causing slowness,^17,46 two creating partial failures of the EHR,¹⁵ and one causing a full crash of the EHR system.¹⁵ We also identified two (2%) malfunctions that generated partial CDS failures,⁴⁷ which is a particularly pernicious failure mode given the outcomes of these situations are often non-deterministic (eg, unpredictable). Due to varying degrees of detail, we also added a new category, “Incorrect CDS,” which accounted for 12 (9%) of all malfunctions.^{29,37,42,44,45,47} This category captures CDS that were classified as malfunctioning, but did not provide sufficient information about the impact the failure had on the system. For example, some authors only described alerts as inaccurate or having errors in their logic. While effort was made to classify these based on other contextual factors (eg, cause), it was not possible to confidently assign to specific categories due to high levels of uncertainty.

Time to discovery

Slightly less than half of studies (n = 61, 47%) provided enough detail to categorize how long it took to identify the malfunction.^{13–15,28–41,43–51} Only two malfunctions were identified in real-time. The first was located using automated reviews of firing data from a service-oriented CDS system.³⁶ The second originated from an integrated CDS system, which impacted several different alerts.¹³ Due to the scale of the failure, it was identified immediately by end users.

Data source and format

Almost all malfunctions identified used the EHR, or similar HIS, as the data source for the CDS system (n = 122, 94%).^{13–15,17,28–41,43–47,51} Data format was rarely described within the literature (n = 9, 7%) and only mentioned in malfunctions originating from service-oriented architectures.^17,46,47

Clinical impact

Twenty-nine malfunctions (22%) described the potential impact of the malfunction on patient care.^{31–35,40–42,47,49–51} Of these, only 11 (8%) reported a specific instance of an impact, occurring across integrated (n = 9) and service-oriented (n = 1) CDS architectures (one architecture could not be defined).^{31–35,41,49} Except for a patient being re-admitted,³⁵ allergy safety events for three patients,⁴¹ and a general increased rate of venous thromboembolism across the hospital,⁴⁹ the papers under review did not identify a specific harm to patients from the malfunctions.

Scale of impact

Thirty-nine (30%) of the malfunctions identified reported (or estimated) the scale of the impact.^{13–15,28–32,35,36,39–44,48,49} Only 1 malfunction (1%) measured the impact across multiple metrics (number of users and time duration).¹⁵ One paper provided a total count of the number of malfunctions (incorrect logic) identified as part of their project, which totaled 209 (only 2 of these malfunctions were included in this review due to lack of detail for the others).³⁹ Time-based metrics included “clinical seasons” (eg, flu season),¹⁴ hours,¹⁵ and days.^15,36 See Table S1 for a full list.

Discussion

This scoping review identified papers describing rule-based CDS malfunctions across different delivery architectures. We identified 28 papers, which included full studies as well as abstracts, and categorized 130 individual malfunctions across more than 31 organizations. Our review indicates there is a limited amount of research focused on CDS malfunctions, with even fewer focused on malfunctions associated with modern delivery architectures (eg, CDS Hooks or SMART). This is particularly concerning as healthcare is increasingly moving toward distributed systems that integrate into the EHR using standard interfaces.^26,52,53

Of the 130 malfunctions, most were from integrated systems and a handful of service-oriented architectures. Only 1 stand-alone malfunction was uncovered during this review and no standards-based errors were found. We believe this is due to the limited implementation of these systems across production systems due to limitations in their design. Stand-alone systems require users to enter information into the system, which may already exist in the EHR, leading to additional work and potential data entry errors. While standards-based systems provided a method for sharing CDS across EHR vendors, knowledge representation challenges limited their adoption.²² Just under half of the malfunctions identified came from a single review and over half were identified by a member of our team (A.W.). While CDS malfunctions are beginning to be recognized and described within the literature, additional research is required to expand our understanding of these failures across all delivery architectures.

Taxonomy expansion

During our review, we found the need to expand existing malfunction taxonomies across both depth and breadth. For example, due to the limited information provided within the paper, the “Impact on System” field for 12 malfunctions was classified using our expanded term “Incorrect CDS,” which is too general to fit within the existing labels. To encourage the reporting and cataloging of CDS malfunctions, an additional high-level field, such as “Incorrect CDS,” could be added to the taxonomy. Similar “upward” expansion could be added to the “Cause” axis, where “Software Error,” which was used to classify 27 malfunctions, could incorporate the existing label of “Defect in EHR Software” and leave room for further clarification from additional systems. New, or expansion within, fields is also required. For example, within the “Cause” axis, “Component failure,” “Information Exchange,” and “Networking” were included as children of the existing “External Service Issue” label. While these new fields accounted for only 10% of all malfunctions, they made up 39% of all service-oriented failures. Other labels could also benefit from additional detail, such as “Software Error,” which could fail due to incorrect handling of dates/times, managing resources (eg, memory), or orchestration (eg, frequency of data pull).

Definitions

One of the main challenges with categorizing CDS malfunctions relates to basic definitions of three key concepts. The first relates to improving our understanding of the boundaries of the CDS system. While tremendous gains have been made to describe the high-level factors within a health care environment through sociotechnical models like one from Sittig and Singh,²¹ we continue to think of CDS narrowly (eg, clinical logic or a single program). However, our review shows that CDS often acts as an integration engine across multiple components, such as external medication databases or lab equipment, which can fail or change. By limiting our view of the CDS system to only the components under direct management of the CDS team, we reduce our ability to be proactive about managing potential failures from external systems the CDS connects to. Further, beyond technical infrastructure, our review identified three CDS malfunctions that were caused by organizational policies. In addition to expanding the technical scope of the CDS system, it is imperative that we also incorporate all levels of the sociotechnical system.

Second, building on the boundary limits of a CDS system, as health information exchange and integration standards have continued to advance, the taxonomy from Wright and Sittig²² used to categorize architectures may require further updates to account for situations where a system incorporates multiple architectures into a single system. For example, based on the taxonomy, Clinical Quality Language would be categorized as a standards-based system, but it’s use could be embedded within a service-oriented system.^54,55 For the purposes of this review, we classified a system according to its most “advanced” architecture according to the taxonomy, but further specification, possibly by breaking a larger system into smaller components, may be necessary.

The third pertains to the definition of a malfunction itself. For our review, we used the definition from Wright et al,¹³ which defines a malfunction as a system that is not working as designed or expected. While this is a broad enough definition to capture a wide range of failures, we found the definition was often based on the perspective and experiences of the individual reviewer. For example, Schreiber et al³⁴ described a CDS malfunction caused by an organizational policy to ignore duplicate alerts within the EHR. From a technical perspective, the CDS system was functioning as intended, however, shifting the perspective from the technology to the full sociotechnical system, it is clear there was an organizational failure. Another challenge our team experienced was determining what constituted a system not functioning as expected. Several examples of CDS improvements were identified, such as methods to increase the specificity of the alerts, that were not ultimately included in the review. To differentiate improvements and malfunctions, our team added an additional quantifier related to the urgency of the fix.

Criticality

Following principles outlined in a failure mode and effects analysis, the criticality of a malfunction should be determined by combining multiple metrics such as frequency (scale of impact), severity (impact on system or patient), and ability to detect (cause).⁵⁶ While all malfunctions in our review reported on the impact to the system, only 39 (30%) described the scale of the impact. Within this axis, several metrics were used including number of alerts, number of logic statements (eg, if/else branches within clinical logic), number of patients, or time (eg, minutes, hours, or seasons). From a clinical perspective, 29 (22%) described the impact of the malfunction on potential outcomes to the patient. Only 14 (11%) reported on all three. Given both the varying measures used within an individual criterion (eg, scale) as well as the limited information provided across all malfunctions, we are not able to accurately compare the criticality between malfunctions. For example, one malfunction caused a complete failure of the EHR for all users (administrative and clinical) within an organization's primary care network while another contributed to the readmission of a single patient. Without a complete picture of the malfunction's frequency and severity, it is impossible to understand, which malfunction had a higher level of criticality.

Impact

Our review identified seven malfunctions where the impact spread to other areas of the larger HIT system. Four caused the EHR to perform slowly, two created a partial failure of the EHR system, and one fully crashed the EHR system for a subset of users within the organization. Most of these failures (n = 5/7) manifested from service-oriented architectures, which is a system design that continues to grow in popularity due to recent advances in HIT and information exchange standards. In addition, to reduce the potential impact of CDS failures on the host system, modern integration standards, such as SMART, specify applications must be launched either in a new browser (eg, a separate window) or an iframe, which essentially is a web page within a web page. Some vendors have taken additional steps to silence script errors (eg, pop-up alerts that may occur during the execution of a web application), however, this may hide the malfunctions from discovery. Silencing the errors may also increase the risk of partial CDS failures, which can lead to unpredictable system behavior and create the potential for patient harm.

CDS will continue to remain an integral aspect of the modern health care system. Further, advances in HIT data exchange and interoperability methods are creating new opportunities for delivering care. By identifying new CDS failure modes, our work takes the first step to ensure the continued safe and effective use of CDS across the development lifecycle (eg, design, development, implementation, and monitoring). However, more work is necessary. For example, current methods for automatically identifying CDS malfunctions often rely on alert-firing rates from the day before.⁵⁷ While helpful, this delay creates a potential gap in patient care if the service the CDS was intended to support is not provided. In addition, as we move toward more distributed architectures (eg, SMART and CDS Hooks), the failures themselves may not be as binary (eg, success or failure) and even seemingly functioning CDS, based on alert-firing rates, can be in a failed state (eg, providing incorrect information). We also hope our work encourages other organizations to use the taxonomy to code their own errors, which will help to increase our understanding of different failure mechanisms and create new models for fault-tolerant CDS systems.

Limitations

This review has several limitations. First, it does not include CDS systems developed using machine learning or other statistical methods. While this would have likely expanded our pool of malfunctions, non-rule-based systems contain distinct and potentially distracting failure modes (eg, incorrect recommendation based on black-box learning). Patient-centered CDS systems were also excluded. While many of the failure modes may have been similar, we scoped our review to CDS used by clinical providers during the point of care to provide insight on the predominant form of CDS used across healthcare. Second, we limited our review to papers identified using three large healthcare bibliographic databases. It is possible that CDS failures are reported in other mediums, such as more technically focused journals, white papers, or legal proceedings. Third, the initial abstract and title review and most of the charting was performed by a single reviewer. To mitigate this risk, two reviewers were used during full-text review, and data charting was validated by a second author with substantive expertise in CDS development (J.M.M.). The definition of a CDS malfunction and the boundary of a CDS system are not explicitly defined and thus, subject to interpretation. We attempted to apply a consistent definition across all papers, however, it is possible that all authors may not agree with our characterizations. Lastly, publication bias, in which some types of CDS research are more likely published than others, could have limited the number and types of malfunctions identified.

Conclusions

CDS malfunctions can occur and do so across several architectures. While research focused on the potential for CDS systems to fail began within the last 7 years, reports of malfunctions are present in the literature as far back as 30 years ago. However, compared with other work on CDS, such as alert design and outcomes, there is a relative lack of research on the ways in which CDS can fail. The 28 articles in this review highlight the variation in which malfunctions can occur and their impact on the larger system, which ranges from incorrect alert text to complete failure of the EHR. It also calls attention to the need to expand existing taxonomies of CDS malfunctions to incorporate a larger set of CDS architectures. This will be especially important for service-oriented architectures, which connect several disparate systems using recent advances in health information exchange standards. Lastly, health care is conducted within a complex adaptive environment and CDS often acts as the integration engine across otherwise disparate information. Given this, it is imperative that we continue to increase our understanding of the ways in which CDS can fail.

Author contributions

J.G.T. contributed to the research design, acquisition and analysis of data, and manuscript preparation. A.F., R.W.G., D.R., and A.W. contributed to the research design, data analysis, and manuscript preparation. J.M.M. contributed to the acquisition and analysis of data and manuscript preparation. All authors approved the final manuscript as submitted.

Supplementary data

Supplementary material is available at Journal of the American Medical Informatics Association online.

Funding

This research received no specific grant from any funding agency in the public, commercial or not-for-profit sectors.

Conflicts of interest

None declared.

Data availability

The data underlying this article are available in the article and in its online supplementary material.