A Hybrid Approach to Developing Clinical Decision Support Systems for Treatment Planning and Monitoring

Abstract

The development of clinical decision support systems for treatment planning and monitoring faces significant challenges, such as high labor intensity, integration complexities, lack of universality, and insufficient consideration of individual patient characteristics. This paper presents an innovative approach to overcoming these limitations, based on the creation of a specialized software toolkit. The key feature of the proposed approach is the use of a hybrid decision-making mechanism that integrates knowledge-based reasoning and case-based reasoning. For knowledge representation, a universal generalized ontology was developed, capable of modeling information about different treatment modalities (pharmacological, rehabilitative, surgical) while remaining independent of any specific medical specialty. This enabled the creation of a unified decision-making algorithm. For case retrieval, a combined method was proposed. The toolkit is being actively used on the IACPaaS platform to develop treatment planning systems across various medical domains, demonstrating its practical applicability and effectiveness.

1. Introduction

Modern clinical practice requires physicians to analyze a substantial amount of information, including patients’ subjective complaints, results of objective, laboratory, and instrumental examinations, medical history of comorbid conditions, allergic status, pharmacological contraindications, and potential drug–drug interactions. Furthermore, Treatment is a multi-stage process that combines various methods, such as drugs, physical rehabilitation (including laser or ultrasound therapy), and surgery.

The extensive range of medications and rehabilitation techniques, along with the need to account for their possible synergies or antagonisms, significantly complicates the selection of an optimal treatment strategy for a specific patient. This process is characterized by a high degree of uncertainty and is associated with the risk of medical errors [1]. In this context, the use of clinical decision support systems (CDSS) appears to be a promising direction, providing intelligent assistance to physicians in selecting personalized treatment plans [2].

Despite the active integration of CDSS into medical practice, their functionality is often limited to administrative tasks, diagnosis (based on clinical data or medical imaging analysis), and prognosis [3,4]. The adoption of treatment planning and monitoring systems remains limited due to high costs, integration hurdles, and a lack of standardization. Development is expensive because systems must cover thousands of medical conditions, drugs, and therapies. They are difficult to integrate with heterogeneous hospital systems, and the absence of universal clinical protocols prevents scaling. Furthermore, decision-making is complicated by the need to account for patient-specific factors, such as the 5–10% of patients who exhibit atypical responses to therapy [5,6,7].

In this article, knowledge-based and case-based reasoning methods are integrated for developing CDSS. The rationale for this hybrid approach is twofold. First, medicine relies heavily on both codified knowledge (clinical guidelines, protocols) and experiential knowledge from past cases. Knowledge-based reasoning ensures that recommendations are grounded in established, evidence-based guidelines, providing safety, standardization, and regulatory compliance. However, clinical guidelines cannot account for all possible patient variations and rare, complex, or atypical presentations. This is where case-based reasoning becomes essential, as it leverages accumulated clinical experience by adapting solutions from similar past cases, thereby offering flexibility and supporting personalized decision-making in situations not fully covered by protocols. Integrating these two methods creates a synergistic effect: the knowledge-based component provides a robust, rule-driven foundation, while the case-based component enhances its ability to handle novelty and nuance, ultimately leading to more comprehensive and adaptable clinical decision support.

One of the most promising approaches in software engineering involves developing a toolkit specifically designed to address particular classes of problems [8]. This system uses reusable components and automated tools, giving three advantages: adaptability to different clinical situations, less development and maintenance work, and better software quality and reliability.

This article provides a comprehensive toolkit that includes models, methods, and software components designed to optimize the development and maintenance of intelligent treatment planning and monitoring systems. The proposed solution offers three distinctive features: disease and regulation-agnostic design (independent of specific medical conditions or institutional/regional guidelines), multimodal treatment support (incorporating pharmacotherapy, physical rehabilitation, and surgical interventions), and flexibility to adapt to various clinical guidelines. The approach addresses current limitations in the field and enhances the efficiency of clinical decision-making processes.

The paper is organized as follows. Section 2 provides a critical review of existing solutions, analyzing their advantages and limitations. Section 3 presents the fundamental design principles of the toolkit and their theoretical justification. Section 4 details the architectural components of the proposed toolkit. Section 5 demonstrates its implementation on the IACPaaS platform, including system architecture and practical applications for developing treatment planning systems across various disease domains. Finally, Section 6 discusses the implications of our findings and outlines directions for future research.

2. Literature Review

Systems that help physicians prescribe treatment can be divided into three main categories: knowledge-based systems, case-based systems, and machine learning-based systems.

2.1. Knowledge-Based Systems

Knowledge-based systems, or expert systems, utilize domain expertise from specialists to provide professional-level solutions within a specific narrow field. The key component of such systems is the knowledge base, which determines their capabilities. Numerous expert systems have been developed to support clinical decision-making, with diagnostic support systems being the most common, while treatment recommendation systems remain relatively scarce. These systems employ various knowledge representation models: formal-logical, production rules, semantic networks, and frame-based systems.

The MobiGuide system [9] exemplifies a formal-logical knowledge representation system. Designed to support diagnostic and treatment decisions, it has been clinically validated for conditions such as atrial fibrillation and gestational diabetes, utilizing computer-interpretable clinical guidelines in its knowledge base.

The primary limitation of formal-logical models and their implementations lies in the absence of clear principles for organizing facts within the knowledge base. Medical uncertainty complicates the incorporation of sufficient axioms for proper system operation, often resulting in insufficiently personalized treatment recommendations. Each axiom requires strict logical justification, typically reduced to binary “yes/no” decisions—a particular challenge in medical science that leads to exponential growth in system complexity. This demands substantial development efforts to ensure accuracy and clinical effectiveness, explaining why logical knowledge representation models have not gained widespread adoption in medical expert systems, particularly for treatment planning [10].

The production rule model enables knowledge representation through conditional statements of the form: “IF condition THEN action.”

The most prominent implementations using forward-chaining production rules are the MYCIN and ONCOCIN expert systems, which are considered prototypes for subsequent medical intelligent systems. The RTP-DSS system, a notable contemporary tool, compares multiple patient-specific treatment plans to recommend optimal radiation therapy regimens based on individual parameters. Another notable system, IndiGO, generates personalized diagnostic and treatment protocols for cardiology and endocrinology [11,12].

This type of knowledge representation is convenient in small systems, but it is of little use for the development of complex systems due to the multiply increasing complexity of the formation of knowledge base, as well as the subsequent low processing efficiency. Production rule systems suffer from two key drawbacks: the knowledge base becomes incomprehensible to domain experts and prohibitively difficult to maintain, a significant problem given the dynamic nature of treatment knowledge.

In semantic knowledge representation, the subject domain is modeled as a collection of objects and their interrelationships, where vertices represent objects (concepts, events, processes) and edges denote relations between objects. The frame-based approach builds upon semantic networks, where a frame constitutes a complete structure describing specific facts, events, phenomena, or processes through semantic dependencies.

Semantic knowledge representation is widely implemented in various formalisms for developing intelligent systems. Among the most prominent is Web Ontology Language (OWL) [13]. The SPELTA system [14] for treating speech and language disorders was developed using this formalism.

Another notable formalism is GLARE [15], which enables the creation, representation, and execution of computer-interpretable clinical guidelines. The PROforma [16] formalism, based on XML, has been used to develop numerous prototypes for managing HIV-positive patients and lung cancer cases.

Perhaps one of the largest and most widely used medical ontologies in the world is SNOMED CT [17,18]. It contains a comprehensive clinical terminology that standardizes the representation of medical information in Electronic Medical Records (EMRs). This transforms clinical data from plain text into structured, machine-readable information suitable for complex processing and analysis.

Another similar solution that has gained traction recently is the OMOP2OBO project [19]. It integrates a set of biomedical ontologies from the OBO standard into a unified data model for storing structured medical information from electronic medical records OMOP.

These ontologies are necessary primarily for the formalization of medical records and the exchange of clinical information. However, when using them as knowledge sources in CDSS, several limitations emerge. Many clinical concepts lack exact matches to concepts in the ontologies. Furthermore, detailed clinical terms are often mapped to overly general concepts in the ontology, leading to a loss of specificity.

The principal advantage of most semantic-based systems lies in their medical domain independence. However, the disadvantage is the relatively weak personalization of the recommendations provided due to the simplified presentation of clinical guidelines and their insufficient formalization.

2.2. Case-Based Reasoning Systems

Case-based reasoning (CBR) methods enable the solution of novel and unfamiliar problems by leveraging accumulated prior experience and adapting solutions from known cases. In clinical decision support systems, case retrieval techniques—such as the k-nearest neighbors (k-NN) algorithm and decision trees—are widely employed.

The k-NN method is one of the simplest and most versatile approaches. Its essence is as follows: to determine the degree of similarity in a variety of parameters, a certain metric is introduced. Then, based on this metric, the distance from the target point corresponding to the current problem situation to the points representing the case base is calculated. After that, the point closest to the target is selected.

This method has been implemented in CBR-DENT [20], a system for identifying analogous dental cases to support diagnosis and treatment planning. The modified method formed the foundation of another system, which was designed to optimize the dose plan for prostate cancer treatment [21]. The main advantages of this method are simplicity of implementation and versatility, allowing it to be applied in various problem areas. However, using this method requires choosing a single metric for calculations, which can be difficult for certain tasks.

The decision tree-based case retrieval method operates by matching clinical scenarios at each branching level of the tree structure, where nodes represent cases from the case base. Each tree node directs the subsequent search path for potential solutions. This approach demonstrates particularly high efficiency when working with large case bases, as most computational processing occurs during the initial tree construction phase, thereby significantly reducing solution retrieval time. The ReCall system [22] implements this methodology, utilizing an object-oriented graphical language to represent complex case structures.

A key disadvantage of case-based systems is that their recommendations are rarely truly personalized, as a perfect match between cases is extremely uncommon [23]. At the same time, most systems place great emphasis on the course of the disease itself when considering cases, although the individual characteristics of the patient also play an important role.

2.3. Machine Learning-Based Systems

One of the most famous representatives of this class of systems in medicine is IBM Watson [24]. Initially, the system was intended for the treatment of oncological diseases, and later it was used to treat other diseases. Another well-known machine learning system is Google’s DeepMindHealth [25]. According to the developers, the system is able to process hundreds of thousands of medical records in a few minutes and identify the necessary knowledge based on it.

Despite their prevalence in other fields, machine learning methods see limited adoption in treatment prescribing systems. A primary reason is the fundamental challenge of forming a suitable training dataset. For successful training of systems of this class, a large number of well-formalized EMR are necessary [26]. Knowledge about treatment is constantly changing, old methods are no longer used and new ones appear instead. In different regions, and even in different medical institutions, regulatory documents and approaches to prescribing treatment may differ significantly, which does not allow the use of historical data from different sources. Because of this, it is almost impossible to collect a representative sample for successful learning, which is confirmed by the experience of IBM Watson, which worked correctly only where it was taught.

Another serious problem is users’ distrust in the results of such systems due to the lack of transparency in their operation. This has led to the emergence of another research field—Explainable Artificial Intelligence (XAI). However, as demonstrated by the review [27,28], challenges persist in translating the proposed explanations into practical insights.

To summarize, we can say that currently existing computer decision support systems for prescribing treatment have a number of significant drawbacks that hinder their practical application. A comparative analysis of various approaches to development CDDS is shown in

Table 1. Comparison of different development approaches.

	Personalization of the Proposed Treatment	The Universality of the Approach (for Various Tasks and Fields of Medicine)	Difficulty of Development	Quality of the Explanations Provided	Complexity of the Support System
Knowledge-based system	++	++	++	+++	+++
Case-based system	+	+++	+	+	+
Machine learning-based systems	+++	+	+++	+	++

.

In a number of systems, it is not possible to prescribe treatment taking into account the personal characteristics of the patient; a significant part of them has a narrow specialization. They also lack an important function of monitoring the prescribed treatment and correcting it based on the prescribed treatment. Moreover, the treatment process for many diseases is multi-stage, including various types of treatment (sequentially or simultaneously): medical, restorative, and/or surgical treatment, which is also not provided by known systems. As a result, in real conditions it becomes necessary to use a variety of heterogeneous systems (for various nosologies, for various types of treatment), which, as a rule, are incompatible and not interrelated. Therefore, the problem of creating tools for creating systems to support the appointment of treatment, its monitoring and correction remains important and relevant.

3. Methodology

The development of the proposed toolkit was guided by the Design Science Research Process (DSRP). The DSRP cycle was applied throughout this work. This methodological framework provided a rigorous and structured approach to achieving the design objectives of our toolkit.

Considering the shortcomings of existing solutions for medical decision support systems regarding treatment, monitoring, and treatment adjustment, the following principles for creating the toolkit were formulated and justified:

1.

The developed toolkit should be based on a hybrid approach combining knowledge-based reasoning and case-based reasoning [29].

Justification: In medicine, treatment is prescribed strictly in accordance with the regulatory documents of the country (sometimes with the regulations of a particular medical institution). Regulations change frequently, on average every few months (as treatment methods improve and new medications and hardware techniques emerge). Therefore, knowledge-based reasoning, where knowledge reflects the content of regulatory documents, is paramount. At the same time, according to estimates [4,5,6], 5–10% of patients have atypical reactions to medical interventions (lack of treatment effect or insufficient effect, new unexpected side effects), which requires treatment adjustment. These unique cases are the most challenging for physicians, and despite treatment compliance with approved regulations, making decisions about its adjustment is quite difficult (it should also be noted that regulatory documents allow variability in medication choice, dosage, and duration of administration). Therefore, analyzing previous cases from practice can help physicians choose the optimal solution or adjust it. For analyzing such atypical, non-standard situations, analogy-based reasoning (case-based) appears to be the most appropriate.

Method of Achievement: This principle was realized through the architectural design of the toolkit, which integrates two complementary components: a knowledge-based inference algorithm (detailed in Section 4.3) operating on a specialized ontology, and a combined case-based reasoning method (detailed in Section 4.4). A decision logic was implemented to invoke the CBR component when the knowledge-based component encounters complex cases or when explicit search for analogous cases is requested by the physician.

2.

The toolkit should not depend on the medical specialty, specific disease (group of diseases), or type of treatment, which includes pharmacological, rehabilitative, and surgical interventions.

Justification: To ensure broad applicability and scalability across medical domains, a foundational, domain-agnostic core model was required.

Method of Achievement: This was achieved through the development of a universal generalized ontology for knowledge representation (Section 4.1). The ontology provides an abstract model of the treatment process. To adapt this generalized model to specific contexts, a mechanism of specialized ontologies linked via a correspondence table was implemented. This allows for the customization of terminology and structure for pharmacotherapy, rehabilitative therapy, or surgical interventions while maintaining a unified reasoning algorithm. The ontologies were implemented using the two-level ontological model and ontological knowledge graphs [30,31]. This model ensures a clear separation between the ontological structure and the substantive content of knowledge, allowing the development of a unified knowledge processing algorithm (solver) that operates under the control of ontology and is invariant to the specific content of the knowledge base.

3.

The toolkit should have the functional capability to generate personalized comprehensive treatment, conduct monitoring of treatment effectiveness, and adjust treatment according to changing patient parameters and considering previously prescribed treatment.

Justification: This principle addresses three key aspects of modern medicine: personalization, continuous monitoring, and adaptive therapy management.

Method of Achievement: Personalization is implemented within the Treatment Model of the ontology via Condition Blocks that incorporate patient-specific data from the EMR. Monitoring and adjustment capabilities are embedded directly into the knowledge structure through the Control points for evaluating the effectiveness of therapy section. The solver algorithm is designed to re-evaluate the patient’s state against these control points and the condition blocks during follow-up visits, enabling dynamic treatment adjustment.

4.

The toolkit should have an explanatory component.

Justification: This principle is driven by the critical need for trust, transparency, and clinical safety in medical AI. Explainability (XAI) is no longer optional but a fundamental requirement, as the “black box” approach is unacceptable in healthcare where decisions impact patient lives. Both clinicians and patients need to understand the rationale behind treatment recommendations. Furthermore, regulatory bodies like the FDA and EMA mandate algorithm interpretability as a prerequisite for the certification of medical AI solutions. Beyond compliance, explainability enables decision auditing, helps identify errors in knowledge or logic, and facilitates continuous improvement in the system based on feedback.

Method of Achievement: This was realized through the development of a dedicated Explanation Ontology (detailed in Section 4.2). This formal ontology structures the reasoning process and includes three core components: the knowledge sources used (e.g., clinical guidelines, patient data), the justification for selecting a specific therapy, and the alternative options considered with reasons for their rejection. This ontological approach ensures that explanations are standardized, built on a unified model rather than generated arbitrarily, and are machine-understandable. Each step of the treatment plan formation is documented in this structured manner, which is then used by the solver to generate comprehensive and auditable explanations for every recommendation.

5.

Case-based reasoning should enable the search for similar EMRs with user-configurable criteria.

Justification: This principle addresses the fundamental way physicians reason in clinical practice—by leveraging accumulated experience and drawing parallels to similar past cases. However, human memory and individual clinical experience are inherently limited. A system that can efficiently find and analyze analogous cases from a vast database thus becomes an indispensable tool for enhancing clinical decision-making. Furthermore, the clinical significance of different patient parameters varies dramatically depending on the context (e.g., family history for hereditary diseases vs. lab results for infections). Rigid, pre-defined search algorithms fail to capture this diversity, necessitating a flexible approach that allows the physician to guide the search based on their specific diagnostic hypotheses and the unique aspects of the case.

Method of Achievement: This capability was implemented through a combined case-based reasoning (CBR) method (detailed in Section 4.4). The method features a two-step process: an initial search using a universal similarity metric, followed by a user-configurable interface for refined search. This interface allows the physician to select, weight, and prioritize specific clinical criteria (observations) relevant to the task at hand. Additionally, the system is designed to present results in a physician-friendly format that goes beyond a simple list, visually highlighting key similarities and differences between the current case and retrieved precedents, enabling a rapid assessment of their relevance.

4. Result

Before detailing the ontologies, it is necessary to define the relationships between concepts in the target information (the knowledge graph formed based on the ontology) and concepts in ontologies. Restrictions are characterized by the following multiplicity specifiers:

• • copy (=)—copy;
  • one (!)—exactly one;
  • set (+)—non-empty set;
  • seq (Λ)—non-empty sequence;
  • copymm ([=])—possibly absent;
  • onemm ([!])—zero or one;
  • setmm ([+])—possibly empty set;
  • seqmm ([Λ])—possibly empty sequence;
  • proxy (~)—skip.

The specifiers “set (+)” and “setmm ([+])” impose a restriction on the name of the concept (vertex) in the target information: in the subset, all concept names must be unique. The specifiers “seq (Λ)” and “seqmm ([Λ])” impose another restriction: the name of the concept can only be a number in the order of vertex generation. “Copy (=)” and “copymm ([=])” mean that the concept from the ontology is fully transferred to the target information (knowledge base). The “proxy (~)” specifier restricts the use of the vertex in the target information; it is not available for generation and is not displayed in it.

4.1. Knowledge Representation Ontology

To ensure knowledge representation independent of medical field and treatment type, a model of the Generalized treatment knowledge representation ontology was developed [31]. It enables describing information while accounting for patients’ personal data, using standardized terminology applicable to all medical fields and treatment types. The ontology structure is shown in Figure 1.

For each Disease, its own Treatment model (or several models) is formed, which may include either rehabilitative, pharmacological, or surgical treatment. This vertex groups a set of medical interventions with proven clinical efficacy against a specific pathological process.

To address treatment personalization, each level of the Treatment model includes a set of conditions (Figure 2). This section allows building complex multi-level conditions that represent a set of criteria. A criterion can be understood as any element in an EMR. The section also allows imposing additional temporal and complex logical constraints.

In the ontology section Treatment scheme, medical care programs are grouped according to disease progression variants. Each Treatment goal includes a complex of clinical measures aimed at a specific aspect of the treatment being administered, for example: “Antitussive action”, “Expectorant effect”, etc. The treatment process can be multi-stage. A Treatment stage is organized either by time intervals or by achieving target indicators. Each stage corresponds to a set of clinical measures. For this purpose, it contains the sections: Complex of impacts and Duration of stage.

Complex of impacts allows describing information about any manipulations performed on the patient. An Impacts formalizes any action on the patient that has a proven therapeutic effect. These include administration of active substances, physiotherapy procedures, massage, and surgical manipulations (bandaging, suturing, wound treatment, etc.). Impacts can be grouped into two blocks: Block of alternative impacts and Block of combined impacts. These also contain sections that describe the parameters of the intervention itself: Characteristic (Figure 3) and Block characteristics. The sections include their own Condition block, necessary for selecting specific characteristics corresponding to the disease presentation.

To monitor and adjust treatment, there is a section in the ontology called Control points for evaluating the effectiveness of therapy. It allows you to set the control period, the goals to be achieved, and the necessary actions if they are not achieved. The description of the section is shown in Figure 4.

The proposed ontology model enables the formation of knowledge about various treatment methods, independent of the clinical presentation of the disease. This has allowed the integration of different therapy types into a unified system and the development of a standardized decision-making mechanism.

The authors of this article are the developers of this generalized ontology [32], and its model continues to be actively maintained and refined. This ongoing work ensures that the ontology adapts to new clinical requirements and remains a robust foundation for representing complex treatment knowledge across various medical domains. The use of a two-level ontological model and ontological knowledge graphs [30,31] provides a formal structure that clearly separates the ontological framework from the clinical content, facilitating both its evolution and the application of a unified reasoning algorithm.

To adapt the generalized ontology to specific treatment types or specialist requirements, a correspondence table is used. This table is designed to modify the structure and terminology of the generalized ontology according to the specific characteristics of the task at hand. The correspondence table maps abstract concepts from the generalized ontology to concrete concepts in the task-oriented ontology. It also allows for modifying the number of sections at any given structural level of the ontology.

Thus, specialized ontologies are created, adapted to specific treatment types and user requirements. Based on these ontologies, corresponding knowledge bases are formed for treating diseases across various medical domains. Since the structure and semantic content of sections in both the generalized and specialized ontologies are identical, a unified decision-making mechanism can operate with these knowledge bases through the correspondence table.

For example, adapting the generalized ontology for pharmacotherapy (Figure 5) begins at the Complex of impacts section, where the term Impacts is replaced with Active Substance, the term Block characteristics is replaced with Destination option, the term Characteristic is mapped to multiple specific concepts: Single dosage, Daily dosage, Administration method, Frequency of administration, Duration of admission.

For the adaptation of the generalized ontology to rehabilitation therapy (Figure 6), a different declarative correspondence model is used. The term Impact is replaced with Rehabilitation technique, the Block characteristics is mapped to the vertices: Treatment regimen, Description of expected response during the procedure. The term Characteristic is replaced with: Method characteristic, Application area, Number of procedures, Days of application.

4.2. Explanation Ontology

To ensure the generation of explanations for recommended treatment, a model of explanation ontology has been developed. The explanation ontology of the proposed treatment describes the structure for explaining the system’s output. The resource formed on its basis will explain which treatment was prescribed to the patient, which was not, and why. This resource will also be necessary for further monitoring and correction of the ongoing treatment.

The explanation ontology is divided into two main sections: Recommended treatment and Not recommended treatment (Figure 7). The first contains the structure for describing the proposed treatment plan for the patient, representing a set of treatment models, treatment schemes, and treatment goals, with corresponding intervention complexes that match the disease presentation.

The Not recommended treatment section represents treatments—including models, schemes, and treatment goals—that are unsuitable for the current clinical presentation for various reasons (Figure 8).

An important section of this ontology model is the explanation block. It is present at every structural level of the generalized ontology and explains the recommendations for inclusion or non-inclusion in the treatment of the section in question. It contains a set of criteria from the corresponding Condition block that were or were not fulfilled.

4.3. Knowledge-Based Inference Algorithm

The solver’s algorithm involves a step-by-step traversal of the ontological graph database for the treatment of a certain disease, as well as the patient’s EMR. By checking the necessary criteria, recommendations are made for personalized treatment, or monitoring and correcting existing treatment, with the generation of a detailed explanation. The solver algorithm is described below (Figure 9).

4.4. Case-Based Reasoning Method

The case-based reasoning (CBR) method acts as a complementary component, triggered specifically when knowledge-based reasoning demonstrates insufficient effectiveness for complex cases stemming from knowledge incompleteness.

A new combined case retrieval method is proposed [33]. The first step involves calculating a preliminary similarity based on standard medical observations (e.g., lab tests, objective exams, complaints). This calculation uses known reference intervals adjusted for the patient’s sex, age, and special conditions (e.g., pregnancy). Based on this knowledge, all values are converted to a unified metric and assigned numerical equivalents, after which aggregate similarity is calculated using the k-NN method.

The universal knowledge about medical observations is drawn from the Knowledge base of medical terms and symptoms [34]. It serves as an information source for populating both EMRs and the case base. It contains knowledge about all possible observations, enabling the definition of general principles for determining observation similarity applicable across all medical fields. This makes the component universal and suitable for working with any disease. The case base represents a collection of EMRs containing prescribed treatment regimens and corresponding treatment outcomes.

The method can be formally represented as follows:

$$\mathrm{I}\mathrm{s}{\displaystyle \left[\right]}={\sum }_0^{\mathrm{n}}{\mathrm{C}\mathrm{b}}_{\mathrm{i}}, \mathrm{i}\mathrm{f} {\displaystyle \frac{{\overline{\mathrm{d}}}_{\mathrm{X},{\mathrm{C}\mathrm{b}}_{\mathrm{i}}}}{\mathrm{n}·10}}>\mathrm{G\%},$$

(1)

where $\mathit{i}$—index of the corresponding case, $\mathit{n}$—number of observations in both the new case and the precedent case, $\mathit{G}$—required similarity percentage threshold, $\overline{\mathit{d}}$—distance metric between the new case and the precedent case.

For the correct calculation of similarity between heterogeneous observations, it is necessary to convert them into the EMR of the new case and the precedent case to a unified metric and ensure they have equal weights. For this purpose, all observation values are assigned a numerical equivalent ranging from “0” to “10”, based on the Knowledge base of medical terms and symptoms.

The calculation of equivalents for all values occurs pairwise for each observation, i.e., simultaneously for the new case and the precedent case. The assignment of equivalents for qualitative values is performed as follows. If the value of a qualitative feature or characteristic has an ordinal scale, then the set of its possible values from the knowledge base is projected onto the 0–10 range, where “0” corresponds to the minimum value and “10” corresponds to the maximum value. The equivalent of an intermediate value is calculated by the formula:

$$Э = {\displaystyle \frac{10(i-1)}{\mathrm{a}-1}},$$

(2)

where $\mathit{i}$—ordinal number of the value in the set, $\mathit{a}$—total number of possible values in the set.

When calculating the nominal scale, if the values match or correspond to one integrating value, the observation in the new case and the precedent is assigned “0”, i.e., a complete match. If the values of the signs are different, then one is assigned “0” and the other “10”, i.e., the maximum difference.

When calculating the convergence of numerical values, the equivalent is calculated as follows: “0” is compared to the range of the norm, and then, with a step of 0.6 of the range of this norm, we go to the desired segment. The values should then be shifted to the beginning of the range 0–10, keeping the distance between them. It should also be borne in mind that the maximum distance cannot be more than 10; it is assumed that any values for which the distance is more than 10 for us are equally as different as possible.

The proposed approach enables determining the convergence of feature values based on their generalized (rather than absolute) values, accounting for various factors (gender, age, patient condition, etc.).

The direct calculation of similarity between the new case and precedent cases is performed collectively for each feature using Manhattan distance, based on the obtained equivalents, and then converted to percentages using the following formula:

$${\%}_{\mathrm{п}}=(1-{\displaystyle \frac{{\sum }_{\mathrm{i}=1}^{\mathrm{n}}\left(\left|{\mathrm{a}}_{\mathrm{i}}-{\mathrm{b}}_{\mathrm{i}}\right|\right)}{\mathrm{n}\ast 10}})\ast 100,$$

(3)

where $\mathit{n}$—total number of different features in the new case and precedent case, $\mathit{i}$—index of the feature in the set, ${\mathit{a}}_{\mathit{i}}$—equivalent of the feature value from the new case, ${\mathit{b}}_{\mathit{i}}$—equivalent of the feature value from the precedent case.

The top five precedent cases that exceed the specified similarity threshold are presented to the user as results. The user can then conduct a refined precedent search by selecting the criteria (observations) of interest. The general algorithm for finding medical use cases is shown in Figure 10.

5. Implementation of the Toolkit

The toolkit was implemented on the cloud platform IACPaaS [35], a software and information system designed to support the development and use of applied and intelligent services.

During implementation, the following pre-existing resources hosted on the IACPaaS platform were utilized: The ontology and database of the pharmacological reference book; The ontology and knowledge base of medical terms and symptoms; The EMR ontology and the case base built upon it. This results in the following architecture of the toolkit (Figure 11). It consists of two components: knowledge-based reasoning and case-based reasoning. These components can operate either jointly within a single system or independently.

Using this toolkit, a number of applied systems for comprehensive treatment planning were created. One of them is an intelligent service for managing the treatment process of patients with pulmonary tuberculosis [36]. Its knowledge base was formed based on clinical recommendations from the Russian Ministry of Health. It was developed by scientists, educators, and practicing physicians with extensive practical experience. The system is based on up-to-date knowledge of pulmonary tuberculosis therapy (Figure 12). The left-hand side of the figure illustrates the overall structure of the treatment knowledge base. The right-hand side displays an example of a condition block description, in this instance, the cancelation of a previously selected treatment scheme. This system was tested at the Orenburg Regional Clinical Tuberculosis Dispensary.

The system’s output is a resource containing information that explains the selected regimen of anti-tuberculosis treatment tailored specifically for the individual patient (Figure 13).

It is composed of two sections: Recommended for treatment and Not recommended treatment. Each one provides a detailed rationale for the decision. The proposed treatment specifies a set of active substances and their dosage instructions. The system also explains the reasons for the absence of recommendations: most commonly, this occurs due to either undocumented clinical findings not entered in the medical record, incomplete/inadequate diagnostic workup, or lack of clinical indications for such treatment options.

Another system created using the software toolkit is a service for comprehensive rehabilitation in cases of dorsopathy. This knowledge base also included an additional course of therapy using sinusoidal modulated currents, general wraps with Rapan salt solution, and sedative inhalations to evaluate their effectiveness.

The use of this knowledge base significantly reduced the frequency of spinal and abdominal pain in patients. Quality of life indicators improved by 1.2 times [37].

Additionally, a series of systems were developed for managing treatment in cardiology and gastroenterology (Figure 14).

The result also includes an explanation. Observations in the EMRs from the case database are color-coded based on their similarity to the corresponding observations in the new case. The color scheme is as follows: green for a perfect match, yellow for 60–99% similarity, red for less than 60% similarity, and blue for missing elements.

6. Discussion

The developed software toolkit enables the creation of intelligent CDSS for comprehensive treatment planning, monitoring, and adjustment. The key features of this toolkit, which fundamentally distinguish it from other known solutions, include:

• Support for various treatment types (pharmacological, rehabilitative, surgical);
• Applicability to a wide range of diseases;
• Integration of knowledge-based reasoning with case-based reasoning;
• Generation of detailed explanations for proposed decisions;
• Functionality for monitoring prescribed treatments and adjusting them based on previous therapies;
• A customizable analogy search mechanism, which enhances the system’s diagnostic capabilities by allowing physicians to adapt case-matching criteria to specific clinical tasks.

The use of this software toolkit significantly reduces development costs for specific systems by reusing various information and software components. In traditional knowledge-based intelligent systems development technology, the following main stages can be distinguished:

• Development of the knowledge base;
• Development of the solver engine;
• Development of the user interface.

According to our long-term experience [38], developing a knowledge base on treatment for a single disease using the traditional approach requires an average of 12 man-months. Using the proposed software toolkit reduces knowledge base development time by more than half, to 5 man-months, through the application of an ontological approach.

Creating a single treatment solver (including treatment monitoring and correction systems, as well as analogical reasoning) requires 14 man-months. When using the toolkit, developing a solver is unnecessary since it is already included.

Developing a custom graphical user interface (including electronic medical record input systems and explanation generation) requires approximately 12 man-months. Within the proposed toolkit, developing a user interface is also not required. If integration with a Medical Information System (MIS) is necessary, there is no need to develop a data input user interface—only an MIS integration module is needed.

Thus, using the software toolkit reduces total labor costs when developing 10 different systems by an average of 6 times (Figure 15). Obviously, as the number of systems being developed increases, the effectiveness of using the toolkit will significantly grow.

To implement a specific application system, only the corresponding knowledge base needs to be created. The reasoning engine does not require modification for this purpose. Moreover, developing the knowledge base is significantly easier due to the use of an ontology, which defines its structure and constraints.

When evaluating the limitations and future development prospects of the proposed solution, a key focus is on automating the creation of the system’s knowledge base. Currently, this remains the primary challenge in developing specific applied systems. A promising solution lies in the automatic or semi-automatic generation of the knowledge graph (knowledge base) using large language models (LLMs). Preliminary results have already been achieved by the authors [39], and ongoing research aims to improve the quality of knowledge base formation.

When considering the relationship with emerging large language models (LLMs) in clinical decision support [40,41], our approach offers several distinct advantages crucial for real-world clinical implementation. Unlike LLMs that rely on general medical knowledge, our system strictly adheres to specific institutional and national treatment protocols, ensuring regulatory compliance. The explicit knowledge representation through ontologies provides complete transparency and detailed explanations for each recommendation, avoiding the “black box” limitations of LLMs. Furthermore, our integrated solver provides essential clinical functions including treatment monitoring, dynamic adjustment, and case-based reasoning—capabilities not inherently available in current LLMs implementations. While LLMs require substantial computational resources, our solution offers practical deployability even in resource-constrained settings. We envision future synergy through LLM-assisted knowledge base automation, while maintaining the critical safety and compliance features of our current architecture.

The developed toolkit can be integrated into the educational process. Two main directions of its application in education can be distinguished. The first direction focuses on developing treatment planning skills. In this case, both real clinical cases (medical records) and training cases aimed at improving specific treatment prescription skills can serve as assessment tasks for students. A key element of the educational process is comparing the treatment strategy proposed by the learner with the recommendations generated by the intelligent system.

The second direction is related to the formalization of medical knowledge based on an ontology. This skill is essential for the rapidly evolving field of “medical informatics” education. Testing the developed knowledge base on real clinical cases, along with explanation generation, will help assess the adequacy and correctness of the knowledge base. Formal completeness, syntactic correctness, and partial semantic validity are ensured by the IACPaaS platform’s knowledge editor, developed as part of the medical portal and governed by the ontology presented in this work.

The output of the case-based reasoning component also includes explanations. It visually demonstrates the degree of similarity between observations from different EMRs.

7. Conclusions

The developed software toolkit for treatment planning and monitoring, which integrates knowledge-based and case-based reasoning methods, represents a promising solution for clinical decision support in modern medicine. By combining these approaches, the system overcomes key limitations inherent in each method when used in isolation.

Implementing this toolkit in clinical practice can:

• Reduce medical errors through automated analysis of large volumes of clinical data;
• Optimize therapy selection by incorporating both formalized knowledge (clinical guidelines, protocols) and precedent-based experience;
• Enable dynamic monitoring and treatment adjustment via continuous analysis of evolving patient parameters;
• Decrease cognitive load on physicians through structured data representation and automated decision support.

Thus, the proposed system marks a significant step toward next-generation hybrid intelligent systems that combine the strengths of formal knowledge and case-based reasoning to deliver personalized and safer medical care. Its adoption will facilitate the digital transformation of healthcare while preserving a fundamental principle: patient needs-centered approach and the professional judgment of the physical.