1 Introduction
The origins of
Clinical Practice Guidelines (CPGs) are to be found in the French
«Médicine d’observation» movement [
108] in the mid-nineteenth century. Proponents of that movement like Pierre C. Alexander Louis, Xavier Bichat, and François Magendie considered that healthcare professionals should not apply clinical methods based solely on their own personal experience and appreciation of their patients’ behavior, but that clinical practice should be based on research results with quantifiable conclusions [
50]. Since the nineteenth century, this approach has evolved, improving clinical practice with techniques like randomized clinical trials (1948) [
23] to perform scientific analyses based on statistical methods and clinical epidemiology. The new technique was accepted and improved in clinical practice after the publication in 1992 of a study by the Evidence-Based Medicine Working Group (Canada) [
46] which demonstrated the effectiveness of evidence-based methods in improving the treatment of clinical pathologies. In this regard, it can be concluded that good clinical practice and healthcare depend on the translation of empirical evidence into CPGs [
89]. At present, the concept of CPGs can be defined as
«statements that include healthcare processes, clinical rules and recommendations intended to optimize patient care that are informed by a systematic review of evidence and an assessment of the benefits and harms of alternative care options» [
58].
A well-defined CPG is beneficial to both healthcare professionals and patients [
59,
62,
92]. For example: it makes it possible to reduce variability during clinical practice and improve the quality of clinical professionals’ performance and decision-making, it pools clinical knowledge obtained applying formal techniques that guarantee clinical and systematic validations of different clinical scenarios, and it facilitates effective, reliable interventions based on empirical evidence.
There now exist a number of different public repositories (US National Guideline Clearinghouse,
1 Scottish Intercollegiate Guidelines Network
2 and Wiley Cochrane Library,
3 etc.) containing CPGs published by international organizations for numerous clinical domains (e.g., oncology, nutrition, cardiology, etc.), but these CPGs are not widely used in day-to-day clinical practice.
Although clinical guidelines can be considered as mechanisms for improving patient treatment, improving the performance of health professionals, and reducing variability in clinical practice [
59], some researchers have identified factors which hinder their adoption by health professionals. For example, Lugtenberg et al. [
63] conducted a qualitative study involving more than 30 professionals from different clinical organizations and identified limitations commonly experienced by the participants: lack of applicability, lack of evidence, lack of flexibility due to organizational restrictions, lack of clinical knowledge about the recommendations offered by each CPG and ambiguity in how those recommendations are described. Cabana et al. [
17] also identified similar barriers associated with lack of awareness about the existence of guidelines, lack of consensus among health professionals and their institutions, perceived interference with the criteria of the healthcare professional, lack of understanding of clinical rules and recommendations, and the inherent difficulty of getting health professionals to change their habits.
Most of the above-mentioned factors restricting the adoption of clinical guidelines could be mitigated using software systems which allow CPG management to be fully digitized [
7,
76] (from design or definition through to execution, evolution, and maintenance). However, one of the most recurrent barriers to the more widespread adoption of guidelines is the ambiguity inherent in their statements due to the fact that they are usually expressed in text format [
17,
63].
This ambiguity affects both health professionals, who must daily apply and consider clinical recommendations, and software engineers, who digitize CPG and develop expert systems and Clinical Decision Support Systems (CDSSs) for CPG management. The software engineers also face an additional challenge in that they have to ensure the automatic maintainability of CPGs. This kind of system is usually developed ad hoc for clinical institutions because each institution has its own medical committees that decide how clinical guidelines should be used by their health professionals. And when public agencies publish new versions of CPGs, these must also be updated in each CDSS. In this regard, the development and maintenance of CDSSs are hard, complex, and expensive tasks. Other CPG-related challenges include the possible hindering of interoperability between different organizations, lack of standardization (since each hospital may decide to evolve or not to evolve the guidelines under execution in its systems), and the growing variability of clinical practice among professionals and even between hospitals.
Moreover, mechanisms must be researched, proposed, and defined to ensure the correct and successful execution and management of CPGs in order to reduce the development costs of CDSSs and reduce the degree of variability with which CPGs are applied for different patients in similar medical situations. It is important to mention that, although these systems may be correctly defined, the frequency of CPG evolution means that solutions must be provided regarding other essential aspects related to CPG maintenance and traceability. Managing change in an appropriate manner, maintaining traceability between the definition and implementation of CPGs, and achieving effective continuous improvement therefore become key tasks within health organizations.
The Contribution of the Paper. The final purpose of our work is to propose a model-driven and tool-supported framework to cover a set of clinical challenge of dealing with CPGs and a set of challenges and motivation for software engineers. From the clinical perspective, our proposal helps to: (i) facilitate the human-centered digitisation of CPGs within a continuous improvement lifecycle (from their definition to their execution, monitoring and maintenance); and (ii) reduce the variability of clinical practice when health professional carries out the follow-up of the pathology of their patients. From the software engineer perspective, our proposal looks for: (i) offering tools for automatically improving the definition and development of CDSS; and (ii) using the power of user-centered principles to offer a very power tools for automation but also very friendly to be used for non-technician people. In this sense, an interdisciplinary team of engineers and healthcare professionals were involved in our proposal to address these challenges from both perspectives, including a human-centric approach to consider the interaction between people and
information technology (IT) tools [
47] based on scientific evidence from CPGs. Specifically, it has been essential to take into account during the design and development of the software a human-centric approach to ensure the adoption of the developed tools in clinical practice.
For this purpose, this paper follows the
Design Science Research Methodology (DSRM), formulating the following hypotheses: (i)
«It is possible to successfully improve the design and development of CDSS with support for the digitisation of CPG through user-friendly, human-centric and model-based solutions»; and (ii)
«It is possible to define a model-based language that contains concepts related to the definition, execution, orchestration,4 and monitoring of CPGs».
In this context, our proposal (called IDE
4ICDS;
Integrated Development Environment (IDE) for
Improving Clinical Decision Support based on Clinical Guidelines (ICDS)) integrates our own CDSS and
Model-Driven Engineering (MDE) [
96] mechanisms, aiming to ensure the systematization, version compatibility, adaptability and interoperability needed to solve the above problems. Besides, our model-driven proposal seeks to simplify the understanding of a new system through abstract and graphical modelling [
48], addressing technological heterogeneity and fostering productivity and rapid prototyping from a human-centered perspective. The main features of the IDE
4ICDS platform are: (i) centralization, i.e., a single nucleus of information is stored and traceability is maintained between all the components of a CPG; (ii) integration, i.e., a single platform (IDE
4ICDS) provides modules for defining, executing, and monitoring CPGs; and (iii) collaboration, i.e., if a health committee wishes to improve or evolve a CPG, they can do it intuitively and in a user-friendly fashion, and the resulting modification can subsequently be used by another health organization. These requirements have been included by incorporation of human centric-issues throughout the MDE process lifecycle, whose design and development were carried out considering the technical and functional needs of the healthcare professionals thanks to the coordination between engineers and clinicians. In addition, comparing existing solutions [
24,
99], IDE
4ICDS has been developed with the ability of tolerating, controlling, and supporting deviations and inconsistencies of the real-world behaviors with respect proposal seeks to provide consistent and effective support to the human-centered system, still maintaining a high degree of flexibility and adaptability to the evolving needs, preferences, an expertise of the human agents in the health field.
Moreover, it is relevant to mention that our proposal has been validated from a clinical and software engineering perspective. On the one hand, IDE4ICDS was validated by implementing the CPGs for Type 2 Diabetes Mellitus (T2DM) in a real clinical environment at two health clinics in the Andalusian Public Health System in the southern Spanish region of Andalusia, involving 89 patients and obtaining a concordance analysis based on the kappa value. On the other hand, IDE4ICDS also showed good results and benefits from a software engineering perspective after comparing the software design and development process of the CPG for T2DM with a previous scenario, where a similar CPG was designed and developed without using the IDE4ICDS framework.
Finally, following this introduction, this paper is organized as follows.
Section 2 presents some related works and computer-based execution CPG tools have been published in the scientific literature to know strengths and weaknesses.
Section 3 describes the methodology used to design our proposal. Later,
Section 4 and
Section 5 details the theoretical results obtained and the supporting tool, respectively.
Section 6 describes the validation case from a clinical and software engineering perspective. Finally,
Section 7 presents the main conclusions drawn from this study and sets out some strategic considerations regarding future lines of research.
5 IDE4ICDS Tool Support
Throughout of
Section 4, theoretical aspects of IDE
4ICDS have been presented. Its lifecycle has been introduced, and how the choice of it can be made more flexible thanks to bidirectional transformations and traceability management has been discussed. Moreover, it has been described how the model-driven paradigm is instantiated within the methodology, showing in detail some of its metamodels and transformations. However, IDE
4ICDS could not be considered a suitable solution if we do not instantiate all these ideas in a practical context, supported by tools that allow mixed teams of clinicians and software engineers to work effectively. Therefore in the following sections we present the architecture of the IDE
4ICDS tool and how it is used in a real project.
5.1 Technological Architecture
In order to support the use of IDE4ICDS through a tool, the first step is to consider our requirements. The first is that the tools needed to incorporate all aspects related to MDE. In other words, we had to be able to include metamodels, transformations and profiles in a simple and suitable way that would guarantee us the ability to easily evolve IDE4ICDS MDE foundation. However, if IDE4ICDS wants to be an usable tool for industry, complex and abstract concepts like metamodels, transformations, and profiles have to be easy enough to be rightly dealt for the development teams. Therefore, we had to look for a simple environment with a reduced learning curve for mixed teams of clinicians and software engineers, but powerful enough to support our MDE environment.
The choice of the way in which we should approach the development of a tool that would support IDE4ICDS was not trivial, since a range of possibilities opened up before us to support IDE4ICDS’ MDE fundamentals and its CDSS, ranging from generating a new tool from scratch to the use and extension of existing tools, either open-source or commercial tools. It was discarded the option of developing a completely new tool, so we carried out a comparative review of between possible base MDE-supported tools and process execution engines with rule engine.
On the one hand, with regard to MDE-supported tools, tools such as Modelio, MagicDraw, WebGME, or the Eclipse ecosystem (Eclipse Modeling Framework - Graphical Modeling Framework, Sirius, Epsilon, and Theia-Graphical Language Server Platform Server) were evaluated, and finally
Enterprise Architect (EA) [
100] was the base solution selected
6 because it provides the ability to model with UML and other modeling languages, it offers the possibility to develop new UML-profiles (meaning to extend the default version of UML), it allows to develop custom and user-friendly integrable GUIs inside itself, and it provides views such as the traceability matrix as long as certain properties are included in the modeling elements.
On the other hand, with regard to rule-driven process execution engines, after considering the requirements of IDE
4ICDS and the findings of some surveys such as [
70], we decided to use the well-known technologies BonitaOS [
8] and Drools [
9], which are an open-source process execution engine and a forward and backward chaining inference based rule engine, respectively.
In this context,
Figure 8 shows the technological architecture of the IDE
4ICDS platform. This architecture was designed using well-known software engineering patterns for designing computer systems [
82] (such as, separation of concerns [
14] and component-based software engineering [
52] patterns) with encapsulated functionalities independent of each other, and divided by functional modules (both at front-end and back-end layer).
On the one hand,
Definition Module is part of the front-end layer and its purpose is to be used by health professionals mainly to model CPG. It has been developed as a plugin within EA, offering wizards and user-friendly GUIs (which were developed using C# and other.NET Microsoft technologies). We also integrate UML-profiles into this IDE
4ICDS plugin to instantiate each metamodel (c.f.
Section 5.2). Specifically, three UML-profiles was implemented with their associated graphic editors: (i)
«Clinical Guideline Modeling Tool»; (ii)
«Clinical Rule Modeling Tool»; and (iii)
«Healthcare Process Modeling Tool».
Section 5.3 describes in detail how these editors are used in practice.
On the other hand, Transformation Rule Module is also part of the front-end layer (specifically, within the aforementioned IDE4ICDS plugin for EA) and its purpose is to be used by software engineers to obtain the executable version of the CPG definition models. It has been developed as a C#-encoded library to automatically execute both M2M and M2T transformation rules between models defined in the previous module. The systematic application of these transformation rules guarantees traceability between models when any change is made by users. The traceability of models is intrinsically supported by EA, improving the consistency of the relationships between different model versions of the same CPG.
Once the executable version of the CPG has been generated, the software engineers must deploy it in the Execution and Orchestration Modules. First, software engineers have to integrate the data entry forms within the execution module, which is related to the IDE4ICDS platform’s web portal; this web portal is part of the front-end layer of the platform. These forms are coded in C# and have been automatically generated from the CPG definition models. Later, software engineers have to connect these forms with the back-end orchestration module with the process engine and rules engine (which are included). In terms of software architecture, this module comprises a process execution engine (supported by BonitaOS) and a clinical rule decision engine (supported by Drools) Both engines manage flow control data, clinical data, and decision data on a clinical knowledge database, which are stored in two databases (knowledge database and clinical data database). These databases are directly managed by features included in the Data Persistence Module.
Finally, we also support the definition of KPIs when the CPG is modelled in the definition module to subsequently generate executable code using the transformation rules module. This executable code is structured as a library of methods (coded in C#) that perform the calculations associated with each KPI. After generating this code, the software engineer has to integrate this code within the Monitoring Module to measure and obtain indicators of the status of the CPG model execution.
5.2 UML-Profiles to Support the IDE4ICDS Metamodels
Following the recommendations of OMG, we have decided to design and develop UML-profiles to facilitate the instantiation of the IDE
4ICDS metamodels because the UML extension provides a flexible and usable solution considering it is a well-known standard with many successful cases [
29] and is supported by many modelling tools [
93]. In short, UML provides three extension mechanisms: (i) «stereotype», defining the elements of a specific domain from which UML metaclasses would be extended; (ii) «tagged value», adding extra meta-attributes to any stereotyped element defined in the profile; and (iii) «constraint», identifying the conditions of the stereotyped elements to create well-defined models and extrapolate constraints (defined in the metamodel) to the profile.
The full description of our UML-Profile would be too long for this paper, so only a fragment of it is shown. In this sense,
Table 1 shows the correlation between some IDE
4ICDS stereotype and its related UML metaclass, as well as the justification of this relationship.
Figure 9 also shows a fragment of the UML-Profile associated with the IDE
4ICDS process modeling metamodel. It is important to note that two types of triangles are used in
Figure 9: the dark triangle denotes the UML extension mechanism and the clear triangle represents the UML inheritance mechanism.
5.3 Applying the Tool
This section describes how the IDE
4ICDS platform is used in practical environments to support each phase of the lifecycle (c.f.,
Figure 1) considering the IDE
4ICDS technology architecture (c.f.,
Figure 8).
On the one hand, during the modelling phase, healthcare professionals model and define the structure of the CPG using three graphical editors integrated in EA (
«Clinical Guideline Modeling Tool»,
«Clinical Rule Modeling Tool»,
«Healthcare Process Modeling Tool»), which are related to our CPG definition metamodel. Space restrictions make it impossible to show many images of this module in this article, but it is briefly illustrated in
Figure 10. To facilitate its explanation, the figure has three labelled areas:
—
Zone A. This shows the structure and organization of models from EA’s project browser. As can be seen in
Figure 10, several packages are created automatically when the user creates a new project (i.e., a new CPG) in IDE
4ICDS:
«Repository of Indicators» stores metrics and indicators that have been defined to measure the execution and performance of the clinical guideline;
«Repository of Rules» stores clinical rules;
«Repository of Variables» stores clinical data used in the clinical guideline; and
«Clinical Process» represents the healthcare workflow associated with the clinical guideline.
—
Area B. This shows the working space for users. As can be seen in
Figure 10, models are built visually and graphically by dragging and dropping elements from the toolbox. The toolbox was obtained after implementing our UML-Profiles with EA.
Figure 10 shows part of the workflow associated with a CPG.
Regarding our toolbox, readers may have doubts about the very small set of elements contained in the toolbox. This fact is justified and is related to Area C of
Figure 10. Right from the beginning, the IDE
4ICDS platform was designed to be user-centered and to reduce cognitive loads when in use. These decisions (especially, the reduction of the cognitive load) were taken to improve the acceptance and usability of IDE
4ICDS in practical environments, as has been corroborated in some studies such as [
45], which analyzed the cognitive overload of several languages (e.g., i* [
74], BPMN [
43], and UML [
73]). These works have confirmed that complex modeling languages increase users’ cognitive overload and make the defined model more difficult to understand. This usability aspect has a major influence on users’ efficiency when using a language.
In this context, our toolbox therefore contains the minimum set of elements necessary to build the basic structure of the CPG, whereas the rest of the information is defined with user-friendly wizards and user-oriented GUIs.
—
Area C. This area displays one of the GUIs of the IDE
4ICDS platform. Specifically, this GUI makes it possible to associate and link clinical rules to output links of a conditional element of the CPG process. When its condition is satisfied, this link allows clinical rules and recommendations to be executed. It is also possible to create new rules from this GUI (
Figure 11) using the
«Nueva Regla» (
«New Rule» in English) button. This button opens the wizard for defining new clinical rules. These forms also implement automatic semantic validations to ensure the building of well-formed models.
On the other hand, after defining the CPG definition model, the software engineer obtains its executable version (both for process engine, rule engine and indicator calculation) using the transformation rules module. This module is part of the IDE
4ICDS plugin and its only user interface is within the menu EA (see top center area of
Figure 10), which allows access to each transformation rule.
Once the executable version has been automatically obtained, it is deployed and configured in the execution and orchestration modules by the software engineer.
Figure 12 briefly illustrates this module from the user’s perspective once the executable version of the clinical guideline is up and running. The screenshot at the back of this figure shows a form associated with one of the activities defined in the diabetes mellitus CPG. This form is executed in BonitaOS to collect clinical data from patients and send this information to the next activity when the healthcare professional finishes the current activity. This action launches the verification of some clinical rules with associated clinical recommendations for the healthcare professional.
7 The action is captured by BonitaOS, which sends the clinical and context data to Drools to verify the rules associated with the current transition between activities. If the rule is verified, clinical recommendations are shown to the healthcare professional in the next activity (the blue text from the screenshot at the front of
Figure 12).
Finally, regarding the monitoring and continuous improvement phase, the IDE
4ICDS platform web portal provides different views to track the indicators that were defined during the modelling phase. In this sense, scorecards, timelines with the evolution of each indicator, and other features, are provided as shown in the
Figure 13.
7 Conclusions, Lessons Learned, and Future Works
CPGs formalize existing clinical knowledge in a specific context, but their representation is usually textual which causes ambiguity and variability when applying any CPG in clinical practice by healthcare professionals. In this article, we propose a model-driven and human-centered framework (IDE4ICDS) to mitigate this clinical situation and improve the software design and development of CDSS. In this respect, we propose the digitization of CPGs within a software lifecycle of continuous improvement (from their definition to their execution and monitoring) for reducing the variability of clinical practice when healthcare professionals monitor their patients’ pathology.
Furthermore, IDE4ICDS has been applied to validate the digitisation of the CPG for T2DM in two clinics of the Andalusian Public Health System in the southern region of Spain, involving 89 patients and obtaining a concordance analysis based on the kappa value. We have also analyzed the benefits of our model-driven approach from a software engineer’s perspective by comparing the results of the diabetes guide with a similar software project (without IDE4ICDS support). Both validations have returned valuable the following lessons learned.
On the one hand, the lessons learned by the clinicians were as follows: (i) reduction of the variability in the healthcare practice as the workflow is guided and suggests by the clinical recommendations of IDE4ICDS; (ii) possibility of providing feedback to improve the platform by recording the reasons why a recommendation is not followed in order to propose changes in the new versions of the clinical guideline; (iii) reduction of the patient follow-up time due to the automated support of the proposal; (iv) personalized attention to the different needs of each patient; (v) improvement of patient care; and (vi) reduction of iatrogenesis; and, as a consequence of all previous benefits, (vii) reducing healthcare costs; and (viii) increasing patient safety.
On the other hand, although we have also verified the use of model-driven paradigm facilitates the daily work of analysts and software experts (from a software engineering perspective in efficiency and effectiveness terms), concepts such as metamodels, UML profiles and transformations are very abstract and complex for them and non-technical users. However, this effect was mitigated with our proposal. Firstly, the collaboration between clinicians and software engineers was very fruitful to define the technical and functional requirements of the CPG for T2DM, thanks to the use of the domain-specific languages integrated in IDE4ICDS and the user-friendly and human-centered design of its user interfaces. These tools enabled a better understanding by healthcare professionals of the software design process for T2DM CPG, resulting in a more accurate and refined requirement model. As a consequence, it was possible to reduce the time spent during the software development stage thanks to the model-driven mechanisms incorporated in our proposal, which allowed to automate the generation of source-code (improving the quality of the software and requiring less time in testing and bug fixing stages).
Moreover, some future works will be discussed after presenting our proposal.
On the one hand, we plan to continue the validation and evaluation of our proposal on CPG for: (i) other pathologies (such as cardiac pathologies, oncological, autoimmune disease such as lupus, or even pluripathological patients, among others); and (ii) other important healthcare fields such as the nursing services to improve the preventive follow-up of patients with pathologies such as diabetic foot or patients with preeclampsia/eclampsia, among others. In this sense, our purpose is to ensure the generality and applicability of IDE4ICDS to different conditions and medical environments.
On the one hand, we plan to improve the functional and technical capabilities of IDE
4ICDS by focusing on two technical aspects that have been highly requested by the healthcare professionals who validated our proposal. First, we will integrate our proposal with the healthcare IT ecosystems used in the Andalusian Health Service, developing and integrating an API based on the
Fast Healthcare Interoperability Resources (FHIR)10 [
109] (Fast Health Interoperability Resources) interoperability standard in IDE
4ICDS. Later, once this FHIR-based API has been developed, we plan to extend our monitoring module to include early warnings on key clinical variables in the patient follow-up when the CPG is being executed into our proposal. We plan to disseminate these early warnings generated by IDE
4ICDS to the rest of the healthcare IT system. Both improvements will represent an important technical advance because all healthcare professionals (of any medical specialty) will be able to know any clinical alteration of their patient in real time, which is especially relevant for multi-pathological patients who are treated by several healthcare professionals from different medical specialties.
Finally, the iterative nature of human-centered software design and development can often present a challenge [
55] when software teams are faced with the necessary, rapid, product development lifecycles associated with healthcare IT software ecosystem. In fact, it has been observed that many otherwise excellent software products have failed in the marketplace due to poor design, while mediocre products have thrived due to attractive and user-friendly human-centered design [
34]. Therefore, an important consideration in healthcare software design is the usability and human factors characteristics of the user interfaces and, hence, the experience they provide to the user. In this context, we plan to evaluate and validate the IDE
4ICDS framework to ascertain the degree of acceptance, usability, ease of use, the training required to effectively utilize the platform, and its impact on clinical workflow efficiency when healthcare professionals use our proposal.