Abstract
Objective Clinical decision support systems (CDSS) have a critical role in improving the quality and safety of health care delivery. CDSS rules direct the behavior of CDSS. However, the CDSS rules have not been routinely shared and reused, and ontology can promote the reusing of CDSS rules. We systematically screened literature to elaborate on the current status of ontology applied in CDSS rule management.
Methods We searched PubMed, the Association for Computing Machinery (ACM) Digital Library, and the Nursing & Allied Health Database for publications focusing on ontology, clinical decision support, and rules. Grounded theory and PRISMA 2020 guidelines were followed. One author started the screening and literature analysis, and two authors validated the processes and results. Inclusion and exclusion criteria were developed and refined iteratively.
Results Among 81 included publications, the identified CDSS were mainly applied to managing chronic conditions, alerts for medication prescriptions, reminders for immunizations and preventive services, diagnoses, and treatment recommendations. The CDSS rules were presented in Semantic Web Rule Language, Jess, or Jena formats. Despite ontology was used to supply medical knowledge, CDSS rules, and terminologies to CDSS, ontology has not been used in CDSS rule management.
Conclusions Although ontology can facilitate the reuse, management, and maintenance of CDSS rules, CDSS ontology remains unavailable indicating that more efforts are needed to improve the reusability and interoperability of CDSS rules.
Introduction
Clinical Decision Support Systems (CDSS) have been studied and used in clinical care delivery for longer than half a century [1–5]. The effectiveness of CDSS in clinical care has been established [6–8]. We cite some prominent examples in CDSS. Middleton et al. reviewed the two decades of clinical decision support experiences as CDSS users and developers and discussed their vision of CDSS for the future [9]. Wright et al. recommended best practice guidelines in CDSS [10–14]. Meanwhile, Sittig and colleagues comprehensively documented the challenges of CDSS [15]. McDonald is one of the earliest pioneers who demonstrated the effectiveness of CDSS in clinical care [16]. Meeting clinicians’ information needs is one way to improve clinical care outcomes via CDSS. Many studies have shown the effectiveness of such CDSS, for example, Cimino’s Infobutton [6, 17]. Currently, CDSS is used routinely in clinical care in the USA. An analysis of a 2015 national survey showed CDSS usage rates reached 68.5% to 100% in primary care settings based in offices [18] in the USA. Therefore, CDSS is commonly used in clinical care delivery as part of electronic health record (EHR) systems. CDSS has a range of forms: such as reminders for preventive services (e.g., immunizations, screening tests) [19, 20], alerts for drug-drug interactions [14, 21, 22], diagnostic or treatment plan recommendations [23–25], content assistance for clinicians [26–30], or recommendations for adhering to current clinical practice guidelines [31–33]. CDSS has played a critical role and is used commonly in providing safer and better quality clinical care services.
CDSS rules, like central neural systems for humans, direct the behaviors of a CDSS during operations by incorporating a patient’s data, contextual information, and medical domain knowledge. CDSS rules have a central role and are a decisive factor in the relevance and usefulness of CDSS in the entire clinical workflow, including whether a CDSS will be adopted and used. CDSS rules can be written in different languages, such as Arden syntax [34], the Semantic Web Rule Language (SWRL), Jess, Jena, and other programming languages. Reusing and sharing CDSS rules is ideal since it is very costly to recreate these rules every time, but the process is not a routine operation across organizations. As a component of an EHR system, updating the CDSS rules regularly is needed to keep the CDSS relevant and useful in clinical care delivery. However, it is a very time-consuming and resource-demanding process to create, manage, maintain, reuse, and share CDSS rules—one type of CDSS artifact. This resource-demanding process has been recognized by larger institutes [4, 35], which usually are better resourced than small-scale practices. Therefore, creating and maintaining CDSS rules can be much more challenging in resource-limited office-based practices.
The ontology can facilitate the use, reuse, sharing, and interoperability of CDSS rules, solving the challenges of managing and maintaining CDSS rules across institutional borders. Ontology is the enabling technology of the Semantic Web [36] and is critical in information sharing and reusing [37, 38]. Although there are many definitions of ontology, we use the one by Gruber: “an ontology is a specification of conceptualization” [37]. Ontology has been used to generate and supply domain knowledge in many fields, including medicine [39] and CDSS [40], which is not an ontology that focuses on CDSS but includes relevant content of CDSS. Ontology can be used to shed light on achieving interoperable clinical information, such as CDSS rules, at a more granular level.
Although ontology can facilitate the reuse and sharing of CDSS rules, no CDSS ontology exists. Therefore, we are building a CDSS ontology [41]. Furthermore, to elaborate on the current status of using ontology in CDSS rules, to improve CDSS rules reuse and interoperability, we systematically reviewed existing English literature about the intersection of CDSS rules, Semantic Web technology (especially ontology), and the use of ontologies in CDSS. The primary rationale of this systematic literature review is that even though there is no existing CDSS ontology except for our effort, the systematic examination of the literature on the intersection of CDSS rules, ontology, and the use of ontology in CDSS can provide a clearer picture on how ontology is used in CDSS, especially regarding CDSS rules. The literature review can shed light on our effort to use the Semantic Web technology to enable the reuse and maintenance of CDSS rules.
Through this effort, we aimed to achieve three objectives. First, this systematic review will provide an initial structure and considerations for organizing our CDSS ontology. Second, the results can help us hone our focus area: ontology use in CDSS rule management. A clear scope and comprehensive picture can form a knowledge framework of the topic that may inspire and guide future efforts to advance this field more explicitly. Third, the manually annotated results of selected publications will be used as gold standards to automatically identify entities from the literature, which complements efforts to curate CDSS ontology manually.
Methods
General workflow
After the literature search, the first 100 of all the retrieved papers were initially screened by one author (XJ), and initial inclusion and exclusion criteria were drafted. This screening was replicated, and the results were discussed, validated, and the criteria were refined and adjusted by two other authors (HM and YG). Therefore, the first 100 papers were screened by all three authors independently. The inclusion and exclusion criteria were developed, revised, and refined during the iterative literature screening, review, analysis, and discussions. Then the rest of the papers were screened by at least two authors (XJ and MH, or XJ and YG) independently to determine if a paper should be included in the literature review. The discrepancies were discussed and resolved via iterative rounds of teleconferences.
When needed, the literature was first screened using publication titles, abstracts, and full-text publications. Then after determining which papers to include, included papers were manually coded to provide more content analysis and synthesized evidence. The final results were shared and agreed upon among all authors. Therefore, the screening of each paper and manual review of included papers were conducted by two authors independently and approved by at least two authors first and all authors later. All discrepancies and concerns were resolved via group email discussions and complementary teleconferences. Figure 1 illustrates the general workflow.
Databases and search strategies
On June 2, 2020, we did an initial set of literature searches. After initial review and discussions, we refined and agreed with the search strategies. On Sept 15, 2020, we searched PubMed, the Association for Computing Machinery (ACM) Digital Library, and the Nursing & Allied Health Database for literature with the following search strategies. On January 5, 2022, we conducted the exact search again in the three literature databases as an update.
PubMed
(clinical decision support systems[MeSH Terms]) AND (ontolog*[Title/abstract] OR rule*[Title/abstract])
ACM Digital Library
The following search was conducted within the scope of the ACM Guide to Computing Literature.
[[Publication Title: “clinical decision support*”] OR [Publication Title: cds*]] AND [[Publication Title: ontolog*] OR [Abstract: ontolog*] OR [Publication Title: rule*] OR [Abstract: rule*]]
Nursing & Allied Health Database (NAHD)
The following search was limited to peer-reviewed publications.
mesh(clinical decision support) AND (ti(ontology) OR ti(ontologies) OR ab(ontology) OR ab(ontologies) OR ti(rule) OR ti(rules) OR ab(rule) OR ab(rules))
Inclusion and exclusion criteria
The inclusion criteria were:
Literature is written in English;
Full-text publication available;
Ontology designed to implement or implemented in CDSS, especially related to CDSS rules;
Content includes granularity of CDSS rules;
Ontology designed to integrate or already integrated with health information systems (e.g., EHR), either in a production system or a prototype, with at least one architecture diagram;
Applied in clinical domains or designed for clinical domains to support health care providers;
Peer-reviewed publication; and
Contained details on integration between CDSS and EHR for evaluation studies.
The exclusion criteria were:
Only CDSS rules, regardless of any stage of the CDSS rules’ lifecycle (i.e., development, identification, refinement, validation, evaluation, or implementation), or no integration was mentioned, or no mention of ontology;
Only Ontology was developed, evaluated, and validated, or no integration was mentioned, or no CDSS was mentioned;
System was designed without mentioning the granularity of CDSS rules or ontology; and
The publication described nonclinical decisions, such as administrative or management decisions (e.g., supply chain management).
Reviewing, coding, analyzing, and synthesizing processes
During the reviewing and manual coding, we followed grounded theory. One author (XJ) randomly selected ten papers from the included 81 papers to start the coding based on the focus of this literature review: CDSS rules (including application and management), ontology, and roles of ontology. The coding results were discussed by three authors (XJ, HM, and YG). The discussion results formed the first draft of codes and code groups (Appendix 1), i.e., data items. Then the three coders (authors) reviewed and coded the first 40 of the included papers using the initial principles and code groups and adding new codes and code groups when needed. Midway through coding, consensus on updated principles and code groups was obtained at a second meeting and following iterative discussions. Then the refined codes and code groups were used to code the remaining papers. Every paper was coded by at least two coders independently. Then the coding results were compared, and any discrepancies were discussed to resolve. During each discussion, the code groups and codes were revised, consolidated, and updated. The refined code groups and examples are described in Appendix 2. Therefore, the data items were emerged during review and refined via discussions instead of pre-defined before reviewing.
A qualitative data analytic tool-ATLAS.ti 9 (desktop version and Web version), was used for coding by the three coders. To form the final codes and code groups, all projects (ATLAS.ti organizes the data as projects, i.e., each coder has a project to save all the papers and coding results) from all three coders were merged, and any duplicates were removed after a manual check. Then codes and code groups were later combined, and any duplicates were removed after a manual review.
After coding, the literature was analyzed and synthesized. For this process, we focused on several aspects, including the application domains of CDSS, the mechanism of CDSS used in clinical settings, CDSS rule format, authoring, management, and ontology roles. The process was iterated several times among the three coders first. Then after obtaining consensus among the three coders, the results were shared and discussed among all authors later. Through iterative discussions, any concerns, confusion, or disagreements among authors were resolved with group emails and complementary teleconferences.
We have followed the PRISMA 2020 checklist [42] in reporting the systematic review with all relevant items.
Results
Results related to CDSS characteristics
The literature searches generated 1,235 publications from three sources until Jan 5, 2022. After removing duplicates and examining according to inclusion and exclusion criteria, we included 81 publications (Appendix 3) in the final review and analysis [19-21, 23-25, 43-117]. Figure 2 illustrates each step of the literature search, screening, selection flow, and results. Figure 3 summarizes the main components covered by the literature review and the summary findings. Figure 3 also serves as an initial knowledge framework on CDSS, CDSS rules, and ontology applications in CDSS.
More than one-third (35.8%, 29/81) of CDSS was used for chronic condition management, prediction, or risk assessment. The chronic conditions included type 1 and 2 diabetes, hypertension, and asthma. Other significant domains included medication prescriptions (16%; 13/81), such as medication orders and detection of adverse drug events and drug-drug interactions, and cancer care (9.9%; 8/81). Most CDSS was designed and used by health care providers, and only 11.1% (9/81) were intended to be used by patients, some of which can be used by clinicians too. Most CDSS provide recommendations, suggestions, alerts, or reminders. Among all items we compared (Table 1), EHR evaluation had the least complete information. Some CDSS was implemented in production systems (38.3%; 31/81), excluding design, and some were implemented in prototypes (37%; 30/81), including experimental systems. Table 1 summarizes the essential characteristics of CDSS. We used the terms from the corresponding papers in all tables without changing them. For example, some papers used “physicians” as CDSS users, and others used “clinicians” as CDSS users. We used the authors’ terms in the tables.
Results related to CDSS rules
Most CDSS rules were written in the languages of SWRL (11.1%; 9/81), Web Ontology Language (OWL; 13.6%, 11/81), extensive markup language (XML; 12.3%; 10/81), Jena rules (6.2%; 5/81), and medical logic module (MLM; 3.7%; 3/81). Two publications [109, 111] used N3 language, and two [82, 109] used the natural rule language (NRL). Table 2 details the CDSS rules for publications that can fill out three (except for the authors and publication years) or more cells in table 2 (n = 54).
The most significant CDSS rule sources were from clinical practice guidelines (44.4%; 36/81). Other sources include domain expert input, publications (e.g., textbooks, papers), multimedia sources, and Internet resources. Two publications used data mining results as CDSS rule sources [59, 65]. CDSS rule authoring and editing tools were not routinely specified in the publications. Protégé [115] was the most popular tool to edit and author CDSS rules in publications with such detail. Several publications also describe developing such tools [49, 57, 83].
Rule engines are another technical detail that many publications did not specify. Among all publications with specified rule engines, Jena (7.4%; 6/81), inference engine (7.4%; 6/81), Jess (4.9%; 4/81), JBoss (3.7%; 3/81), guideline engine (3.7%; 3/81), Drools (2.5%; 2/81), and Bayes (2.5%; 2/81) were most often used. The column for CDSS rule operation in Table 2 summarizes how the CDSS rule works in a simplified manner. Many publications do not provide details on the working mechanism of CDSS rules within the system context.
Interoperability does not seem to be the focus of the publications. Only a few papers mentioned interoperability (Table 2). They all used HL7 CDA (Health Level 7, Clinical Document Architecture) or HL7 FHIR (Fast Healthcare Interoperability Resources) standards. However, we noticed that such measures are not specifically for CDSS rules but mainly for the input and output of CDSS.
Results related to ontology
In the included publications, ontology is mainly used as a knowledge source for CDSS (39.5%; 32/81) and to facilitate classification (8.6%; 7/81), reasoning, and inference (7.4%; 6/81; e.g., identification recommendations or relationships). Ontologies were also used to specify CDSS rules (15%; 12/80) or provide general knowledge for the electronic medical record (EMR) or electronic health record (EHR) systems. In some cases, these two uses also overlapped (23.5%; 19/81; i.e., the ontologies were used to provide specified CDSS rules and general knowledge).
Many authors use reasoner and rule engines interchangeably. In this manuscript, we distinguish the two concepts in a workable manner to use them. We do not intend to define them universally and comprehensively. In our description, we use the term reasoner to refer to the inference for a consistency check or classification for an ontology, which can be part of an ontology tool or external. In our description, we use the term rule engine to refer to generating or providing recommendations by incorporating a patient’s data, contextual information, and medical knowledge (usually from an ontology or knowledge base) for CDSS. However, we used the authors’ choice of terms in tables without modification. Among the publications, the most common reasoners were Pellet (13.6%; 11/81), Jena (4.9%; 4/81), the OWL reasoner (3.7%; 3/81), Jess (2.5%; 2/81), and the Euler/EYE inference engine (2.5%; 2/81).
Ontology sources should include the content and code systems used to represent the content. Content may come from a popular textbook or clinical practice guideline. The content can be coded in a specific code system, such as SNOMED CT. Because the CDSS rule source has been specified in Table 2, we only included code systems that served as a source of ontology in Table 3; We used this format to avoid redundancy in the presentation. The most often used coding systems were SNOMED CT (11.1%; 9/81), ICD10 (the International Statistical Classification of Diseases and Related Health Problems, Tenth Revision; 4.9%; 4/81), Unified Medical Language System (UMLS; 4.9%; 4/81), Logical Observation Identifiers Names and Codes (LOINC; 3.7%; 3/81), RxNorm (2.5%; 2/81).
Many included publications also did not include complete information for ontology validation. Approximately 20 publications mentioned some validation, including validation or evaluation by domain experts (24.7%; 20/81). Some ontologies were authored by domain experts [47, 55]. Table 3 shows additional details on the roles of ontology in the publications, although Table 3 includes only the publications that can fill out three (except for the authors and publication years) or more cells (n = 36).
Other results
After cleaning, discussion, and consolidation, we had 30 code groups and 221 final codes used in the ATLAS.ti (Appendix 2). These codes and code groups guided our results analysis and synthesis; these codes and code groups also helped us form the starting structure for the ontology we are building [41], i.e., the ontology for CDSS rule management and maintenance. Figure 4 illustrates the clinical domains of CDSS within included publications. Figure 5 shows a word cloud image generated from ATLAS.ti based on the codes used in all included publications. In the publications, we also found many large international collaborations [94, 101, 110] and solo author publications [57, 64, 105, 106]. We also noticed that some publications were missing necessary information for explaining the mechanisms of the systems that can be critical for reproducibility. Some examples include the architecture diagrams of CDSS, CDSS rule engine, CDSS rule language, how CDSS rules are managed at the backend, and integration mechanisms among CDSS rules, ontology, and EHR/EMR systems.
Based on our review, PubMed is still the clear dominant source to supply publications in this field. Approximately 90.1% (73/81) of publications were identified via PubMed. The ACM Library added only eight publications after removing duplicates.
We have followed the PRISMA 2020 checklist in writing this systematic review. However, we realize that PRISMA 2020 is intended to be used by outcome-oriented studies, which is not the focus of our systematic literature review. The publications included in our review are about design, development, and implementation. Therefore effect measures or certainty assessment were irrelevant items. We reported 18 items (out of 27 items, Appendix 4) in the full-text paper and ten in the abstract (out of 12 items, Appendix 5).
Discussion
Summary of results
Although CDSS has proved its effectiveness in clinical care for decades, the reusing and sharing of machine-processable CDSS rules has not been achieved. Ontology has the potential to facilitate interoperable CDSS rules. We conducted this systematic review on CDSS rules, ontology, and its applications in CDSS. Our systematic review shows the broad clinical application domains of CDSS in chronic condition management, medication order, and cancer care. Most CDSS is designed for health care providers, and most of the CDSS rules are based on clinical practice guidelines. Although we found details about CDSS rules, we noticed inconsistent presentations or unavailable information on CDSS rule language, CDSS rule engine, and evaluation details. We also observed inconsistent technical details related to ontology purposes, reasoners, mechanisms of connection, or communication with CDSS or EMR/EHR/HIS. Although some publications describe such a level of detail, not all publications include this information. It can be hard to perform reproducibility and further improvement without such information.
Although reusing and sharing CDSS artifacts is a challenge with very good recognition [1, 101], the reusability, customization, and shareability of CDSS rules are not yet a common focus, not even in publications that focus on CDSS rule editing [35, 118, 119]. We feel these topics are important, especially using ontology to achieve the goals. Therefore we conducted this literature review. Marco-Ruiz et al. [101] showed how to use CDSS artifacts in the Linked Data framework [120] by leveraging Semantic Web technologies, especially ontology. However, that work was at a higher level to describe the concepts without tangible tools implemented in clinical practices. Our motivation to build a CDSS ontology [41] aligns well with their vision. We are trying to shorten the gap between the high-level vision on these realistic issues (reusing and sharing CDSS artifacts) [1, 101] and CDSS operations in the clinical world by appraising existing efforts and using a more generic approach. The first step in filling this gap is constructing an upper-level CDSS ontology.
Significance of the work
We systematically reviewed literature about ontology applied in CDSS. Our approach illustrated the state-of-the-art applications of ontology in CDSS rule management. These applications present excellent potential in reusing and sharing CDSS artifacts, which are critical to clinical care quality and patient safety. Currently, it is very costly to create, maintain, and reuse these rules. Although some authors recognized this benefit [1, 35, 101], none have conducted a systematic review. Our literature review thoroughly analyzed the topic, established the knowledge framework, and created a comprehensive collection that can inform efforts to design or improve future CDSS, create a tutorial on the subject for newcomers in the field, and set the foundation for the CDSS ontology we are building.
We also recommend that authors include essential technical details in publications focusing on this topic. These details include CDSS application domain, CDSS users, CDSS notification types, CDSS evaluation (what, how, by whom), CDSS rule sources, CDSS rule language, CDSS rule engine, CDSS operation mechanism, ontology use purposes, ontology sources (both content and code systems), ontology validation, reasoner, connection/communication mechanism with CDSS, and EMR/EHR. We encourage authors to include such details to help readers reference, compare, and increase the reproducibility of the reported work.
Interpretation of the results
Rule engines are critical components of CDSS. The rule engine executes rules and patient data and context information to produce a result, e.g., an alert or a recommendation [1]. Jess is a rule engine and development environment in Java [121]. We noticed in our review that Jess is one of the famous rule engines used repeatedly. Jess can be used to develop rule-based expert systems or create Jess rules. In the popular tool Protégé, the plug-in API SWRLJessTab can convert SWRL rules to Jess rules. Jess rules can be used by Jess Rule Engine, which has many implementations in rule-based expert systems [121]. In addition to Jess, Jena and Drools were used repeatedly among the included publications. Jena is an API in Java designed to support rule-based inference and use RDF (Resource Description Framework) graphs [122]. Jena.java API can handle OWL models and is a popular framework for managing RDF/OWL descriptions [88]. Drools is a business rule management system, including a rule engine [123]. Drools also have SWRL API, which can support SWRL and SQWRL. SQWRL can query SWRL.
Reasoning via a reasoner is a critical characteristic for many ontologies, even though the current reasoning is still in the first-degree logic. Reasoning can be used for three main functions: consistency check, classification, and realization [124]. Several publications included in this systematic review specified the classification roles of the ontology and the reasoners (listed in Table 3). The OWL group has curated an updated list of OWL reasoners at the University of Manchester in the UK [124]. Parsia and colleagues compiled and compared the current OWL reasoners and their performances via the competition report [124]. Here, we only briefly discuss the reasoners used in the included publications.
Among the included publications, both Pellet and Jena are popular reasoners (Table 3), and other used reasoners include FaCT++ [90], Z3 Solver reasoner [97], Euler/EYE inference engine [109, 111], OWL Horst [101], and OWL Cerebra [55]. Among these reasoners, Pellet [125] is Java-based, and it can work on SWRL rules and ontologies written in OWL2. SWRL was initially designed as a rule language for Semantic Web technologies [126]. A user needs the rule language and an editor (e.g., Protégé SWRL tab) to write, revise, and query the rules. SWRL can be queried by SQWRL (a query language for OWL) or SPARQL (SPARQL Protocol and RDF query language). Then reasoners can be used to conduct reasoning based on the rules and facts defined in the ontology or knowledge base. Protégé-OWL [127] provides an editor for SWRL rules. Protégé SWRL editor is another example.
Not all ontologies or knowledge bases were formally evaluated, validated, or authored by domain experts. Only 25% of publications mentioned about evaluated or validated by domain experts. A formal assessment or validation is critical, regardless of a manually built ontology (or knowledge base). For some ontologies (or knowledge bases) derived from other automatic methods (e.g., machine learning algorithms), the validation is even more critical to ensure the validity of the results from automated processes. Testing has not been conducted consistently across the publications. Some have been formally tested with patient databases in the production systems, some were tested via prototypes, and some were tested conceptually. Technically, all such testing is valuable, to some extent. Without some types of testing, the validity of the work can be questionable. Some ontologies were authored by domain experts, which provides greater validity than those involving nondomain experts while constructing the ontology.
Also, not all publications clearly state whether the evaluation was conducted on the CDSS. For those publications with CDSS evaluation, not all provide adequate details on what was evaluated, how the evaluation was completed, and who the evaluators were.
We noticed that not all included publications provided the needed technical details during the literature review, such as the CDSS rule engine, rule language, and ontology reasoner. Some people may argue that such information can vary dramatically during implementation. However, we believe that including such details will present the work more robustly, help users better understand the system’s mechanism, provide possibilities for others to reproduce the work, and enable others to compare the technical solutions and design more optimal options in the future.
One systematic review by Dissanayake and colleagues [40] was similar to our review. However, our review has several distinct characteristics that complement the literature with unique insights about CDSS rules, ontology, and ontology applications, especially in rule management. For example, we focused on the mechanism of these characteristics in the HIS/EHR/EMR systems. In contrast, Dissanayake’s review focused on the reasoning processes during clinical decision-making, especially in forming the ontologies to support complex cognitive processes. Their study also compared evaluation metrics and evidence generated among the included publications, whereas we focused on the CDSS rule authoring, management, implementation, and ontology validation.
Our coding revealed factual evidence without any interpretations, which differs from qualitative data analysis and coding. Our discussions focused on the scope of coding, definitions of codes, the granularity of coding, dimensions, organization, categorization, and combinations of codes, articulating these points and obtaining consensus.
Knowledge gap and challenges moving forward
Although the importance and challenging nature of reusability and sharability of CDSS artifacts have been well recognized and documented, various efforts are focusing on this topic because of the potential of the Semantic Web technologies and ontology [1, 101]. However, the steps are mainly at the conceptual level without tangible tools to implement in the real world. No CDSS ontology bridges the high-level thinking, planning presented by different groups, and real-world implementations and operations of the process. This knowledge gap motivated our efforts to build a CDSS ontology that focuses on CDSS rule management and maintenance [41]. Moving forward, one challenge is more on the marketing side: let CDSS artifacts developers, vendors, and healthcare professionals, i.e., end-users, be aware of the CDSS ontology and adopt it in their work.
Strengths
This systematic review focuses on CDSS rules and ontology roles in CDSS and mechanisms of CDSS in clinical practices or prototypes. We established the initial knowledge framework on the intersections of CDSS, CDSS rules, and ontology. We summarized detailed information regarding the reasoner, rule engines, ontology, and CDSS rule formats used in each included publication. We also provided summaries (Tables 1–3) of valuable references for designing or improving systems. The side-by-side comparison also gives structured guidance for preparing future publications. We hope the knowledge framework, detailed summarizations, and comparisons can guide and enlighten future improvements and designs more explicitly in tangible ways.
Limitations
We recognize that our review has limitations. We were unable to include publications written in a language other than English. Also, we only included publications with full-text available. We had to exclude one thesis [128], which was a search result from the ACM Library, due to the unavailability of the full-text publication. Also, we excluded some publications that focused on the CDSS rule [35, 118, 119]. Although such publications had a similar focus to one aspect of our systematic review, none specified an ontology component in the publications. We also noticed that the publications on CDSS rule authoring and managing tools are from Partners HealthCare/Harvard Medical School.
We also exclude another category of papers that discussed best practices in CDSS rule management, such as Wright A et al. [10]. Although such publications can inform CDSS design, testing, and operation processes, they did not meet the focused criteria for this systematic review.
Interestingly, our two papers [129, 130] were not identified via our literature search strategies. The main reason such a search is missing is the keywords used in these papers. CDSS was not specified as a keyword in the two papers, although the content was undoubtedly within the scope of this review.
Unfortunately, these two publications may not be the only papers missed by this literature search. This challenge is common to how our current literature databases are organized and how we conduct a literature search. In the future, this challenge can be minimized by carefully choosing all keywords included in the publications to maximize the possibilities found during the literature search. This is also a lesson for all authors.
Conclusions
The reuse, management, and maintenance of CDSS rules are critical and challenging for clinical care. Ontology could facilitate the reusing and sharing of CDSS artifacts, e.g., CDSS rules. However, there is no CDSS ontology yet, and we are building one. We attempt to bridge the high-level visions and operational level efforts via the CDSS ontology to bring tangible applications to the field. Current publications present incomplete technical details on CDSS rules and ontology. We recommend future publications include more detailed information about the architecture diagrams, mechanism of connection among ontology, CDSS rules, EHR/EMR, CDSS rule language, reasoner, the rule engine, validation or authorization of ontology and CDSS rules, the purpose of the ontology, ontology source, and the management and maintenance of CDSS rules. Such details will increase the study’s reproducibility and help readers optimize their designs and development. In addition, we hope the established knowledge framework and summarizations of the included publications can guide future improvements and designs more explicitly.
Data Availability
All data produced in the present study are available upon reasonable request to the authors
Competing interests
None to disclose.
Appendices
Appendix 1: Initial draft of codes and code groups used in reviewing/coding
Appendix 2: Refined version of codes and code groups used in reviewing/coding
Appendix 3: All included paper lists (n = 81) in this systematic literature review
Appendix 4: PRISMA 2020 item checklist reported in our systematic literature review
Appendix 5: PRISMA 2020 for Abstracts checklist reported in our systematic literature review
Acknowledgment
This work is supported by the National Institute of General Medical Sciences of the National Institutes of Health under Award No. R01GM138589 and partially under P20 GM121342. We thank Professor James Cimino for his valuable feedback and suggestions on the manuscript.
Footnotes
↵* Xia Jing, Hua Min, and Yang Gong contribute equally to the manuscript. Therefore they share the first authorship.
References
- 1.↵
- 2.
- 3.
- 4.↵
- 5.↵
- 6.↵
- 7.
- 8.↵
- 9.↵
- 10.↵
- 11.
- 12.
- 13.
- 14.↵
- 15.↵
- 16.↵
- 17.↵
- 18.↵
- 19.↵
- 20.↵
- 21.↵
- 22.↵
- 23.↵
- 24.
- 25.↵
- 26.↵
- 27.
- 28.
- 29.
- 30.↵
- 31.↵
- 32.
- 33.↵
- 34.↵
- 35.↵
- 36.↵
- 37.↵
- 38.↵
- 39.↵
- 40.↵
- 41.↵
- 42.↵
- 43.↵
- 44.
- 45.
- 46.
- 47.↵
- 48.
- 49.↵
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.↵
- 56.
- 57.↵
- 58.
- 59.↵
- 60.
- 61.
- 62.
- 63.
- 64.↵
- 65.↵
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.↵
- 83.↵
- 84.
- 85.
- 86.
- 87.
- 88.↵
- 89.
- 90.↵
- 91.
- 92.
- 93.
- 94.↵
- 95.
- 96.
- 97.↵
- 98.
- 99.
- 100.
- 101.↵
- 102.
- 103.
- 104.
- 105.↵
- 106.↵
- 107.
- 108.
- 109.↵
- 110.↵
- 111.↵
- 112.
- 113.
- 114.
- 115.↵
- 116.
- 117.↵
- 118.↵
- 119.↵
- 120.↵
- 121.↵
- 122.↵
- 123.↵
- 124.↵
- 125.↵
- 126.↵
- 127.↵
- 128.↵
- 129.↵
- 130.↵