Keywords decision support systems, clinical - hematology - openEHR - organ failure - intensive care units, pediatric - diagnostic accuracy
Background and Significance
Background and Significance
Diagnosing organ dysfunction (OD) along the clinical pathway of critically ill children suffering from systemic inflammatory response syndrome (SIRS) or sepsis is a knowledge-intensive and fault-prone task that clinicians have to solve under profound urgency, due to its life-threatening character.[1 ] SIRS can progress to sepsis if there is an infection. As the name already suggests, SIRS represents a systemic response of the entire body often resulting in further suffering of affected organ systems. OD and failures occur, leading to a decreased chance of full recovery. By early initiation of antibiotic or symptomatic treatment continuously along this pathway, fatal outcomes might be preventable and mortality might be reduced. Thus, besides detecting SIRS as the starting point, also the early detection of associated OD along the path is important since it allows timely assessment of the progression state of infection in the patient.[2 ] Additionally, by this separate analysis for the presence of any OD, an early differentiation between SIRS and severe SIRS is possible. In 2005, field experts and researchers at the International Pediatric Sepsis Consensus Conference (IPSCC)[3 ] agreed on a set of diagnostic criteria for sepsis and associated ODs, including the multiple organ dysfunction syndrome (MODS). Concerning pediatric OD, the criteria comprise a list of laboratory parameters and thresholds for each organ system (respiratory, cardiovascular, renal, hepatic, hematologic, and neurological) potentially affected.[3 ] For the hematologic system of children, two physiological parameters are of great relevance: the platelet count and the international normalized ratio (INR).[3 ] According to Goldstein et al,[3 ] pediatric hematologic OD is defined as:
“Platelet count <80,000/mm3 or a decline of 50% in platelet count from the highest value recorded over the past 3 days (for chronic hematology/oncology patients).
Or, an international normalized ratio >2.
Delayed diagnosis can increase mortality, either by increasing the severity of OD or by increasing the number of failing organs.[4 ] Depending on the admission diagnosis, mortality rates range from approximately 14.3 to 24.7%.[5 ]
Concomitant with a fast-growing amount of complex and heterogeneous data, there is an increasing interest in clinical decision support (CDS).[6 ] However, for a CDSS to enhance its usefulness at the point of care, it must be well integrated into the clinical workflow. In related work, best practices and lessons learned describe key aspects of a successful implementation, focusing on user-friendly designs and evidence-based-driven algorithms.[7 ]
[8 ]
[9 ]
[10 ] To decide on the presence or absence of a physiological abnormality, physicians have to interpret different physiological parameters from various information sources, such as the laboratory information system, electronic health record (EHR), or a ward-specific patient data management system (PDMS). These data need to be analyzed for each patient individually as normal ranges vary between age groups.[11 ] Altogether, various aspects need to be considered in a short period, requiring substantial practical experience. Taking these unique conditions into account, clinical decision support systems (CDSS) could provide added value in reducing the workload of staff and enhancing a patient's condition by providing more accurate diagnoses.[12 ]
[13 ]
[14 ] To make sure that the decisions of the CDSS are reliable, a precise knowledge base is essential to cover all clinical and patient-related details that are crucial for making decisions fitting best to the patient's health and well-being.[15 ] Furthermore, to allow broad applicability and sharing of CDSS, semantic interoperability standards, interfaces, and FAIR principles[16 ] should be considered. This includes the reuse of existing data in a standardized and semantically enriched form rather than building yet another stand-alone system (specifically designed for an institution), implementing a new vendor locked-in PDMS, or relying on specific non-standardized data representations from a primary source system. To avoid this, various semantic interoperability or messaging standards are available, such as openEHR,[17 ] HL7 CDA/CCR,[18 ] or HL7 FHIR.[19 ]
In our previous work, we successfully presented and evaluated a holistic approach for designing an interoperable, knowledge-based CDSS for early detection of SIRS in pediatric intensive care units (PICU).[20 ] In this work, we aim at reproducing and enhancing this interoperable and rule-based CDSS approach for the detection of pediatric, SIRS/sepsis-associated, hematologic OD, thus also exploring the transferability of our design approach.
Objectives
Our long-term goal is the development of a CDSS able to assess patients with respect to sepsis. Therefore, we need to be able to identify pathological states that are clinically relevant for the clinical pathway of the patient along SIRS/sepsis progression, starting with initial SIRS detection[20 ]
[21 ] and going on with abnormal events related to SIRS/sepsis such as associated OD. In this paper, we follow our research path by focusing on the computerized detection of SIRS/sepsis-associated hematologic OD.
To enhance an existing, interoperable, and rule-based CDSS prototype for tracing the progression in critically ill children by augmenting it with the capability to detect SIRS/sepsis-associated hematologic dysfunction.
To determine diagnostic accuracy (i.e., sensitivity and specificity) of the CDSS for detecting pediatric hematologic dysfunction by analyzing real-world data as a proof-of-concept (PoC) study.
Methods
Interoperability in CDSS
We have reproduced an interoperable CDSS approach previously introduced by our working group for computerized detection of SIRS in PICU. A key characteristic of this concept is the use of openEHR as a clinical information standard.[20 ] OpenEHR specifies an open platform architecture for EHR systems and outmatches traditional approaches by ensuring semantic interoperability for collecting and exchanging clinical data.[22 ]
[23 ] This is assured as long as the exchanging institutions use the same standardized clinical information models, the so-called archetypes. Archetypes are used to define the clinical information to be represented (e.g., a laboratory test result) in a uniform, machine-readable as well as machine-actionable, and standardized form.[24 ] Thus, they are rich and computable metadata models of clinical information. Archetypes rely on the reuse of standardized and internationally agreed-upon data items but simultaneously encapsulate this technical content from the domain-specific aspects.[25 ] For example, for representing a laboratory test result, a standardized model, agreed upon internationally by various experts from different domains, can be used to capture and/or integrate routine laboratory test data.[26 ] Nesting and restricting different archetypes, the outcome is a template that usually refers to an entire document or form (e.g., laboratory report) that requires various archetypes to meet the local needs of an institution.[22 ] Terminology bindings (e.g., SNOMED-CT[27 ] or LOINC[28 ]) are possible on both archetype and template levels.[29 ] Throughout the modeling process and subsequently, archetypes and templates can be uploaded, managed, reviewed, and accessed via a web-based data repository, the Clinical Knowledge Manager (CKM).[30 ] Cross-institutional data transfer does not depend on local infrastructures, applications, and vendors, but rather on a common reference model (RM) which does not rely on elusive clinical knowledge.[22 ] Instead, the RM represents the basis upon which software applications can be built. Thus, decision logic in software applications is separated from clinical data, ensuring vendor independence and interoperability on the application level.[23 ] For the use case of hematologic OD, appropriate templates, consisting of international agreed-upon archetypes available in the CKM, need to be modeled to map the diagnostic criteria.
Step-wise Implementation Strategy
[Fig. 1 ] shows an overview of the existing CDSS architecture and the necessary modeling and implementation steps adapted for our new use case. For more information on the existing CDSS architecture, we refer to Wulff et al.[20 ]
Fig. 1 Bottom-up implementation plan to enrich the existing CDSS. CDSS, clinical decision support systems.
Step 1: Data Extraction and Integration
Data used in the CDSS is routinely captured by the PDMS m.life
[a ] by medisite (version 11.2.4) of the PICU at Hannover Medical School (HMH). After the extraction of routine data from primary source systems, data were transformed and loaded into an openEHR data repository by using standardized data models. Currently, our data extraction and integration processes are performed only on demand. However, it is possible to adjust those processes to be performed every time a new value comes in. The openEHR data repository used was based on the Better platform by Marand.[31 ]
Step 2: Data Querying
For retrieving data stored in archetypes, the model-based Archetype Query Language (AQL) was used.[32 ] AQL-constructed queries retrieve data from the openEHR data repository via a REST API and were – in contrast to SQL or similar query languages – independent of underlying primary source database structures and system vendors. This means that they work on any openEHR platform that implements the abovementioned, internationally agreed-upon archetypes.
Step 3: Knowledge Modeling
We adopted our previously designed approach for knowledge acquisition and representation that comprises the use of commonKADS as a well-documented and comprehensible methodology for acquiring, modeling, and processing knowledge.[33 ] In addition to literature research, we performed structured interviews to exchange information with two experienced intensive care pediatricians. The clinical question and methodology have been raised directly from the clinical context and worked out together with computer specialists. Knowledge transfer was the focus at the beginning. For this purpose, the pediatricians received a questionnaire tailored to the clinical picture of sepsis-associated hematological dysfunction. Based on these knowledge assets provided in the answers and additional expert discussions during rule development, the human-readable rules were jointly designed and translated into machine-readable rules by computer scientists (during step 4, see below). During the evaluation, pediatricians reviewed false positive and false negative alarms so that either the gold standard or the rule base could be optimized. We used commonKADS as a model-driven approach to conceptualize three knowledge models for each knowledge category including domain, inference, and task knowledge.[33 ] When knowledge was revealed at a later stage in the knowledge engineering process (e.g., during evaluation), the knowledge base was adapted iteratively.[15 ]
Step 4: Rule Development
For transferring expert knowledge into computable problem-solving steps, we implemented rules by using the Business Rules Management System Drools by JBoss (Red Hat),[34 ] which provides techniques to embed reasoning structures.
Step 5: Graphical User Interface Design
For the visualization of vital signs series, laboratory value courses, and warnings, a graphical user interface based on JavaFX – a framework for developing applications built on Java[35 ]– was designed. We concentrated on making decisions explainable and visually easy to catch. The graphical user interface visualizes also parameters that are not directly relevant to hematologic dysfunction but all together are required to provide information about the clinical progression of SIRS/sepsis.
Clinical Evaluation and Statistical Analysis
We used data from the prospective, monocentric, double-blinded, diagnostic CADDIE2 study to estimate diagnostic accuracy (sensitivity and specificity ) of the rule-based CDSS (index test ). Simultaneously, two experienced pediatricians defined the reference standard by blinded, retrospective digital chart review, and analysis based on the IPSCC criteria.
The CADDIE2 study included 168 consecutively sampled patients (0–18 years) from the interdisciplinary PICU of the MHH, who stayed for at least 12 hours with valid informed consent, between August 2018 to September 2019. These 168 patients reflected the intended sample size for the evaluation of the diagnostic accuracy of SIRS detection. For details on the study population and recruited patients, we refer to Wulff et al.[21 ]
We divided the PICU stay of a patient into blocks that were then labeled as “true positive,” “false negative,” “true negative,” or “false positive” (for details see [Supplementary Material S1 ], available in the online version). The blocks were generated dependent on a change in the diagnostic status (OD present vs. no OD) of either the CDSS, the reference standard, or both simultaneously. Missing values or indeterminate results were not possible. However, the labeling was slightly modified by using a ± 4-hour window around the onset and end of the reference standard episode (exact timestamps defined by clinicians) as well as merging diagnoses with less than 24 hours between episodes. The period from the onset to the end of an episode is referred to as the diagnostic episode, i.e., the patient is diseased (for details see [Supplementary Material S1 ], available in the online version). Based on the labels, sensitivity and specificity with their Wald 95% confidence intervals (CI) were estimated using the approach by Brunner and Zapf,[36 ] Lange,[37 ] and Rooney,[38 ] which accounts for the longitudinal data format (several blocks per patient). The analysis was performed in R version 4.1.2 (November 01, 2021). A subgroup or sensitivity analysis was not conducted.
Table 1
Cross-tabulation of time blocks among 168 patients
Clinician's diagnosis
CDSS
Hematologic dysfunction
Positive
Hematologic dysfunction
Negative
Total
Alarm
55
8
63
No alarm
12
262
274
Total
67
270
337
Abbreviation: CDSS, clinical decision support systems.
Results
Conceptualized Knowledge Model for Hematologic Organ Dysfunction
The preparation of a problem- and application-specific knowledge base is of great importance. Therefore, we conceptualized a knowledge model ([Fig. 2 ]) composed of a task, domain, and inference model. The inference model is required to perform problem-solving steps under the use of static expert knowledge (domain model) to complete the task of recognizing hematologic OD (task model). First, the normal range for each laboratory parameter must be specified (inference: specify). Depending on the underlying parameter, the correct normal range needs to be selected (inference: select), thereby in the next step, the respective laboratory result can be evaluated by comparing it to the normal range (inference: evaluate). Afterward, it can be inferred whether the value is within or outside the normal range, resulting in the actual decision if a hematologic OD episode is present or absent due to an off-limit condition.
Fig. 2 Simplified knowledge model and its dependencies of all three commonKADS knowledge categories.
Data Models and Querying
For this work, already existing archetypes could be reused to model three templates: (1) laboratory report, (2) diagnosis report, and (3) procedure report. The “laboratory report” ([Fig. 3 ]) contains data related to laboratory findings. The “diagnosis report” stores the diagnoses of a patient, and the “procedure report” holds data about the performed procedures.
Fig. 3 openEHR template for storing laboratory results (ID: ELISE Laboratory Report).
Since a “laboratory report” can store many test results, each instance of the cluster archetype “laboratory test result” stores, in addition to the laboratory value and its corresponding specimen collection timestamp, the terminology ID “LOINC” and its actual LOINC codes (platelets: “777–3,” INR: “6301–6”) in the corresponding data element of type DV_CODED_TEXT. The enrichment of LOINC terminology bindings ensures standardized data retrieval across different institutions, preconditioned that the AQL query is restricted to the same LOINC code (e.g., /name/defining_code/code_string = “777–3”).
Based on the template structure, we defined AQL queries to load data into the CDSS. In the first step, these queries were assigned to a variable in the CDSS, storing the query in a string format. Second, a REST API processed this string into a result set. Third, a loop iterated through each line of the result set and instantiates objects for each value of the patient (Patient State ). Further, these facts could be inserted into Drools streams where rules enriched the attributes of the objects before transferring the generated knowledge into a target database.
Implemented Knowledge Base, Reasoning Mechanisms, and User Interface
IPSCC diagnostic criteria serve as the foundation of the implemented rules (explicit knowledge).[3 ] However, some institution-specific adaptions to these internationally defined criteria were realized due to special characteristics of the patient collective of MHH. The first criterion was modified by using the first value after patient admission (here: baseline) as a comparator instead of the highest value recorded over the past 3 days to prevent adulterations associated with platelet transfusions or bleeding complications due to surgery. To decide whether a patient meets the baseline criterion, our domain experts identified diagnoses ([Supplementary Appendix B ], available in the online version) to recognize if a patient suffers from a chronic hematological/oncological illness associated with thrombocytopenia. If the patient was diagnosed with at least one of the diagnoses, hematologic OD would be present if either the platelet count would be below a threshold of 80,000/mm3 or if there would be a decline of 50% in platelet count compared with the first value recorded. Therefore, the latter criterion only applies to patients where at least one of these diagnoses was documented to catch the patients that might have platelet counts above 80,000/mm3 , however, their count in platelets significantly dropped due to a possible hematologic OD.
Primary diseases associated with an increase in INR ([Supplementary Appendix B ], available in the online version) have been identified, e.g., hereditary deficiencies. Analogous to the platelet count criterion, if the patient's diagnoses match with one of the ICD-10-GM codes (German Modification of the International Classification of Diseases)[39 ] listed in [Supplementary Appendix B ] (available in the online version), an increased INR will not be taken into account for the application of further rules.
Additionally, our domain experts decided to distinguish between patients who need extracorporeal membrane oxygenation (ECMO) and patients who do not need ECMO, since the CDSS and the physician in charge should incorporate that information when diagnosing thrombocytopenia. To circumvent false positives associated with ECMO (e.g., due to the administration of heparin or after pains of ECMO), a time span of 2 hours pre-ECMO and 12 hours post-ECMO has been added to the duration of ECMO.
[Fig. 4 ] shows the reasoning process for the hematologic OD including all adoptions. The left branch indicates under which circumstances an alarm is elicited, caused by a lack in platelet count. The right branch encompasses the conditions leading to an alarm caused by an offset limit violation of INR. If the alarms occur simultaneously, they are being concatenated to one hematologic OD caused by both abnormal platelets and INR values.
Fig. 4 Reasoning process based on explicit and tacit knowledge assets.
Drools decision tables are suitable for equally structured rules, in which each row represents a separate rule, whereas drools rule files encompass more specific rules. Each inference is associated with a set of rules which fire simultaneously. The rule engine ensures that another set of rules of the next inference can only fire until the previous inference step has been completed. First, a decision table makes sure that the incoming value is assigned to the corresponding normal range (parameter norm model). If every condition of a rule is met, the actions are being triggered. In this particular ruleset, the attributes maximum and minimum of the concept norm obtain a value, as shown in [Fig. 5 ]. Note that the diagnostic criteria only suggest a minimum value for platelet count and a maximum value for INR. The respective other boundary value is based on clinically reasonable values provided by domain experts.
Fig. 5 Extract of decision table for assigning the correct normal range to the patient's parameter value.
Subsequently, rules of three decision tables fire simultaneously using the knowledge generated by the specify -inference (alarm model). Depending on the parameter type and the presence of a limit value violation, at least one condition among all the rules of all three tables (distinguished by their alarm category) is met. In case the value exceeds the maximum (alarm category = “too high”) or falls below the minimum (alarm category = “too low”), this results in a so-called alarm event . Unlike these scenarios, the value can also be within the normal range (alarm category = “normal,” no alarm event is fired).
Based on the output of the decision tables, this newly generated knowledge can be used for further rules implemented via rule files. The ongoing inference mechanism is based on the step where alarm events of the same parameter type and alarm category merge if the events occur simultaneously. The resulting united alarm event has the starting point of the first alarm event and the ending point of the last overlapping alarm event .
[Fig. 6 ] gives an example of the Drools syntax of a rule in which an INR alarm (when-condition) results in an OD event being of the type “hematologic-inr” (then-condition).
Fig. 6 Example for eliciting an alarm due to increased INR implemented with Drools rule. INR, international normalized ratio.
To visualize the process of constantly changing the knowledge base throughout the reasoning process, [Fig. 7 ] demonstrates which attributes of the concepts within the knowledge base are being enriched (right hand side) and how the knowledge base alters during application runtime (left hand side).
Fig. 7 Iterative knowledge base alteration during reasoning.
The final decision of the CDSS is delineated in a clear and precise manner so that medical staff can retrace and comprehend the CDSS decision (explanation facility). Charts visualize alarms by illustrating the time course of the parameter values as well as emphasizing the presence of an OD episode in red color. Next to each chart, the normative values for the patient are visible to explain CDSS decisions. A table at the bottom summarizes relevant information of the alarm such as duration, parameter type, start and end time point. To align with the existing CDSS design, presented by Wulff et al,[20 ] the graphical user interface has the same appearance ([Fig. 8 ]).
Fig. 8 Graphical user interface for the recognition of hematologic dysfunction.
Estimation of Diagnostic Accuracy
The data for PoC included 168 patients (0–18 years) with 1.998 admission days and 337 blocks. Overall, 67 episodes of hematologic OD in 35 patients (10 patients with ≥two episodes) were recorded by the clinicians. The rule-based CDSS detected the onset of the hematologic dysfunction with a sensitivity of 0.821 (95% CI: 0.708–0.904) and a specificity of 0.970 (95% CI:0.942–0.987) ([Table 1 ]). The research did not cause any adverse events for patients, because the index test was applied retrospectively ([Fig. 9 ]).
Fig. 9 Flow diagram for recruited patients including their overall hematologic OD label (for details on the overall label see [Supplementary Material S1 ] (available in the online version).
Discussion
Strengths and Limitations
We have shown that our interoperable CDSS concept, first introduced for SIRS detection in children, is transferrable to other relevant clinical use cases. Addressing some false positives, one limitation of the CDSS is its inability to recognize pre-analytical errors, e.g., improper sample collection, or post-analytical errors such as mismatched laboratory specimens. However, this limitation could be addressed in a rule that compares each abnormal value with the previous and following value within a pre-defined timeframe. The timeframe should be selected in a way that would indicate that the clinician suspects an analytical error, hence ordering a new laboratory test immediately. Therefore, if the following value is not pathological and significantly differs from the current, pathological value, it is likely to be an erroneous value that does not fit the constitution of the patient. Other false positives are due to other procedures, especially if the patient has lost high volumes of blood during surgery, resulting in low platelet counts. The false negatives are related to the ECMO rules. In specific cases, for example, when the patient takes a relatively long time to achieve normal platelet levels after ECMO or achieves it only with repeated administration of platelets, clinicians suspect a hematologic dysfunction, deviating from the criteria. Another reason why sensitivity on the patient level was not as good as expected could be the quality of the primary source data. Overall, several strategies will be developed to optimize the CDSS before further steps are taken.
We are aware that our sample size of 168 patients is relatively small, which is related to the fact that, first, pediatric cohorts are generally smaller and, second, no reference standard with episodes of SIRS/sepsis and associated OD is available. The reason why we have not evaluated our approach on other wards is that a continuous, digitalized documentation of vital signs, laboratory values, and other values is a rarity in German wards. Without these data in other settings, it is simply not possible to use such a computerized clinical decision support approach for SIRS/sepsis and associated ODs. Consequently, we were not able to evaluate the transferability of our system to other wards. Nevertheless, we will integrate measured values from the intermediate care units shortly. This will be the first step to test our system also for other patient cohorts with other characteristics.
Rather than simply detecting abnormal laboratory values similar to what laboratory reporting systems are capable of, our goal was to detect SIRS/sepsis-associated hematologic dysfunction according to the IPSCC criteria, since such dependencies are not implemented in our laboratory information system. Additionally, some diagnostic criteria were modified due to specifics in MHH diagnostics and data capture. Consequently, these criteria differ from the consensus criteria defined by multiple experts from the IPSCC. To address this, the CDSS could be enhanced by user input fields to be able to choose from different available criteria to adapt to site-specific conditions. Further adaptions before the CDSS will be implemented in the PDMS, include, for example, integrating warnings when ECMO is present in the patient. In this case, the system should warn the pediatrician about abnormal values to prevent any fatal missing conditions of the patient on ECMO but will not label it as a dysfunction, unless the pediatrician determines otherwise. In general, the CDSS would have to be enriched with further knowledge to create alerts with clinical relevance as just described, but which do not lead to a diagnosis.
Relying on open standards (e.g., openEHR) is a clear advantage since it is vendor-neutral and openly specified. Another strength of the CDSS is its ability to produce high-quality labeled datasets useful to train machine-learning models. Once the CDSS can detect dysfunction of other organ systems, it provides data scientists with an efficient and fast-processing tool for data annotation concerning the multi-class problem of MODS. Since the prototypical approach had proven beneficial, it will serve as a role model for future implementations of dysfunction or failure of other organ systems along the pathway of SIRS/sepsis. These future implementations also include implementation into routine work, once our approach was proven beneficial in a multicenter study. For this, we are working closely together with a certified manufacturer to implement our results to comply with regulations of the European Medical Device Regulation (MDR). Thus, this work is intended to share early results with interested scientists. However, it is worthwhile to mention that our algorithm was applied to real clinical routine data.
As explained, our work is primarily about detecting SIRS/sepsis-associated hematologic dysfunctions. To differentiate between SIRS/sepsis-associated pathologic states and underlying diseases also resulting in abnormal IPSCC parameters, we implemented ICD-10-based measures. Indeed, since we decided to focus SIRS/sepsis progression, our approach is limited because detection of OD from other causes is not integrated.
Future Directions
We were able to present promising findings for data-driven hematologic OD detection by reusing an interoperable CDSS approach. In one of the next steps, we also aim at evaluating our approach in other, more general pediatric wards by making use of our labeling mechanism. In this context, we focus on labeling a large dataset of pediatric intensive care patients (approximately 5,000 encounters from 2015 to 2021) to use it as training and test data for data-driven approaches, which will also allow evaluating algorithms on a broader basis. For more information, we would like to refer to the publication server of our dataset.[40 ] We are currently in the process of further enriching the knowledge base with rules regarding more complex OD such as hepatic, renal, cardiovascular, and respiratory OD, dealing with more parameters and age-specific differences. In parallel, the PDMS manufacturer of MHH is implementing the rules that have already been evaluated in their certified medical device. Thereafter, we can make a definite statement on whether the diagnostic accuracy yields similar results to what we yielded with our CDSS in one of the first steps of CDSS implementation.
In addition, we aim at publishing a completely open accessible demonstrator, which will be published in a couple of weeks, so that the source code can be optimized by each interested researcher.[41 ] The next stage of our research will be the implementation of combination rules to detect MODS. Additional work on acquiring knowledge for organ failure would help us to implement rules for the detection of organ failure in critically ill children. Research into developing machine-learning algorithms using the labeled dataset by our CDSS is also underway, as questions about a potential refinement of the diagnostic criteria can be raised. Moreover, a usability study is planned and will be conducted in the upcoming months. We will assess the usability of our system by using quantitative and qualitative assessments, amongst others, resulting in a final SUS score.[42 ]
Conclusion
The authors have shown that our interoperable CDSS concept is transferrable to other clinical use cases. Using a stepwise approach, we augmented our CDSS with the capability for the detection of pediatric hematologic OD. The results of our evaluation show that the CDSS will correctly diagnose 82% of the patients who have a hematologic OD, but the CDSS will also issue a diagnosis for 3% of the patients who do not have a hematologic OD. The practicability concerning more complex OD will be addressed in future work.
Clinical Relevance Statement
Clinical Relevance Statement
Health care professionals will benefit from CDSS if these systems consolidate information from different source systems, analyze a large amount of heterogeneous data, present the most important pieces of information, and enable accurate, fast, and informed decision-making even in time-critical and high-risk situations. The ability of CDSS to detect OD can have a direct impact on the workload of pediatric intensive care physicians, including lower stress levels and error prevention, as well as it can support inexperienced physicians and close knowledge gaps. With CDSS for early detection of OD, the physician will be able to quickly assess the patient's condition and decide on further treatments that would better match the patient's risk status.
Multiple Choice Questions
Multiple Choice Questions
Which of the following is a well-known bottleneck of CDSS adoption?
The design of new CDSS as standalone systems.
The use of semantic and syntactic interoperability standards.
The design of new CDSS with interfaces to EHRs or further primary source systems in the information system landscape of the institution.
The reuse of existing routine data captured in primary source documentation or monitoring systems.
Correct Answer: The correct answer is option a. Stand-alone CDSS lacks interoperability and can disrupt the physician's workflow when not connected to the systems used in daily routine.
Which of the following aspects is decisive in the application of the openEHR approach for semantic modeling and structured representation of clinical concepts?
A deep technical understanding of the underlying database structure.
The reuse of existing archetypes that already have been published in freely accessible repositories.
Advanced knowledge of a programming language (e.g., Java, C + +).
The use of a specific vendor-dependent commercial archetype designer.
Correct Answer: The correct answer is option b. Many clinical concepts are already available in international archetype repositories (e.g., Clinical Knowledge Manager, CKM, www.openehr.org/ckm ). These archetypes are used in other openEHR-projects and have been developed in collaboration with various international experts. Reusing such archetypes not only preserves international interoperability but also saves resources. In addition, modeling is not limited to a specific commercial tool, as various products, including open source solutions, exist. Finally, openEHR realizes two-level modeling so that no deep understanding of technical problems such as the underlying database structure or advanced knowledge in a programming language is required.
