Sage Journals: Discover world-class research

Abstract

Iron is a vital mineral for the proper function of hemoglobin which is also a protein needed to transport oxygen in the blood. The lack of iron in human blood causes a range of serious health problems including “anemia.” In this article, the COntAneRS (Clinical ONTology-based Iron Deficiency‐ANEmia‐ Recommendation System) is proposed as a clinical decision support system to diagnose iron deficiency and manage its treatment. The applied methodologies and main technical contributions of this study are discussed in four aspects: (1) Iron Deficiency Domain Ontology (IDDOnt), (2) Semantic Web Rule Knowledgebase (SWRL), (3) Inference Engine, and (4) Physician Portal of the system. Experimental studies of the proposed system have been applied on a population of 200 people, consisting of real anemia patients and healthy individuals. First, a decision tree classifier is used to diagnose iron deficiency condition based on the patients’ demographic information and certain medical data, as well as recently measured hemoglobin CBC levels of the patients. To check the effectiveness of the system, the data of 50 anonymous patients randomly selected from 200 patients are entered manually in the IDDOnt and the system is then verified according to the inferencing results. After inferencing step, the recommendations related to appropriate iron drugs, daily consumption dose, drug consumption periods, and additional medical suggestions about drug interactions are provided by the system to the responsible physician through system ontology, SWRL rules, and web services. As a result of experimental studies, our system has provided very good accuracy (99.5%) and robust results in producing patient-suitable suggestions. In addition, the applicability of the system on the cases is discussed as case studies in this paper. The results reported from the applied case studies are promising in demonstrating the applicability, effectiveness, and efficiency of the proposed approach.

Keywords

decision support systems anemia diagnosis iron deficiency Web ontology language semantic rules

Introduction

Around 10 million people in the United States have low levels of iron, and about five million of these have been diagnosed with iron deficiency according to the research studies performed.¹ Decision support systems (DSSs) and its sub-branch recommendation systems (RSs) are known as eye-catching technological developments and applied methods in healthcare systems.² In addition to that, the advent of many reporting technologies has shown that DSSs started to emerge as a critical component of health management design. DSSs support physicians and healthcare professionals for decision making during diagnosing, treatment, and supporting various medical procedures.^2,3 DSSs which perform selected cognitive decision-making functions are based on artificial intelligence in medicine. The systems use a domain knowledgebase in general and a set of predefined medical rules and then provide an analysis result on a patient’s information for the physicians.³ Semantic medical prescriptions in Khalili et al. study are one of the example research studies that has been done in this scope.⁴ In addition, DSSs are formed by using medical knowledge rules and detailed contextual taxonomy (e.g., ontologies) which are used during physician decision-making and constitute medical care workflows to improve patient care quality.^5‒8 As the name implies, iron deficiency anemia appears due to insufficient iron and it is the most common form of anemia in the world.⁹ Iron deficiency anemia may rarely cause death; however, the impact on human health is substantial. Anemia is simply diagnosed and treated but frequently unnoticed by physicians.¹⁰ Without enough iron, the human body cannot produce enough substance in red blood cells that enables them to carry oxygen (hemoglobin). Untreated iron deficiency anemia can make humans at more risk of illness and infection, and the lack of iron affects the immune system.¹⁰ Especially, untreated iron deficiency in pregnant females will be passed to the infant.¹¹ If a mother is iron deficient while she is pregnant, the child is born with poor iron reserves and is at great risk of morbidity, mortality, and learning disorders.¹¹ Shortly, in pregnancy, it can cause a great risk of complications before and after birth. Therefore, DSSs and RSs are significant technological contributions that help physicians to manage the treatment of anemia in children.¹¹

In this study, the COntAneRS (Clinical ONTology-based Iron Deficiency‐ANEmia‐ Recommendation System) is proposed as a clinical DSS to diagnose “anemia” disease and recommends proper treatment activities to physicians before decision-making. To diagnose anemia, a decision tree classifier is used in COntAneRS. In addition, Iron Deficiency Domain Ontology (IDDOnt) is constituted taking into account medical domain knowledge in the form of semantical medical rules and detailed contextual information of iron deficiency domain. IDDOnt has been developed by collaborating with domain-related physicians and using the anemia knowledge base available in WebMed.¹² Semantic Web Rule Language (SWRL)¹³ is used for creating semantical medical rules and is added to IDDOnt. Moreover, an Inference Engine (IE) is developed by using Java. IE aims to present various appropriate recommendations to physicians during the treatment and clinical consultation of their patients. COntAneRS executes its semantical medical rules on IDDOnt by taking into account the instant information about patients gathered. Thus, the system analyses the patient data to determine the direction of treatment plan. For a patient, appropriate recommendations deduced by IE after inferencing process appear on the physician portal of COntAneRS.

The rest of the paper is as follows. Section 2 includes background information. Section 3 discusses the survey results performed based on scientific research studies about anemia risk in the literature. Section 4 presents the system architecture of the proposed system and its working mechanism. Section 5 focuses on the decision tree classifier and the dataset used in experimental studies. Section 6 presents the development of the system ontology IDDOnt and the system semantical medical rules to deduce appropriate recommendations. Section 7 explores the semantic medical rule knowledge base of the system performance. In addition, it also presents a case study and user interfaces of the system. Section 8 discusses the methodologies, experimental studies performed and empirical findings. Finally, Section 9 includes conclusions and discussions.

Background

Rule-based systems (also known as production systems or expert systems) are one of the common application areas of artificial intelligence. It is a way of encoding a human expert’s knowledge into an automated system. Rules are expressed as a set of if-then statements.¹⁴ Rule-based expert systems have five major components: (1) knowledge base, (2) database, (3) inference engine, (4) explanation facilities, and (5) user interface.^14,15 The knowledge base contains the domain knowledge useful for problem solving and a set of rules. The rules which are executed in action part constitute the knowledge of human experts in general. The database represents a set of facts. The inference engine is the reasoning part and links the aforementioned two parts. The explanation facilities enable the user to know how a particular conclusion is reached and why a specific fact is needed. The user interface is the communication between a user and the system. The developer interface includes knowledge base editors, debugging and input/output facilities.

Semantic Web (SW) technology was proposed as an extension of the current Web and as a subset of artificial intelligence technology in which information has a well-defined meaning.¹⁶ SW enables better cooperation between computers and people that can allow users to find the answers to their queries more precisely via ontologies. Gruber¹⁷ described the ontology as a conceptual language of the SW that is a specification of a conceptualization of a knowledge domain. The “conceptualization” refers to an abstract model of phenomena in the world by having identified the relevant concepts. “Explicit” means the type of concepts used, and the constraints on their use are explicitly defined. “Formal” refers to the fact that the ontology should be machine readable. “Shared” reflects that ontology should capture consensual knowledge accepted by the communities.

An ontology is a formal description of knowledge as a set of concepts within a domain and the relationships that hold between them. To enable such a description, we need to formally specify components such as individuals (instances of objects), classes, attributes, and relations as well as restrictions, rules, and axioms. Precisely, ontology is a controlled vocabulary and formally describes concepts and their relationships. Recently, many ontological languages have been proposed and standardized such as Resource Description Framework Schema (RDFS)¹⁸ and Web Ontology Language (OWL).¹⁹ According to the World Wide Web Consortium (W3C), OWL is a family of knowledge representation languages for reasoning on ontologies.

DSSs are a very broad concept which involves all aspects of supporting individuals during decision-making and providing automated intelligent support where required and when available. In other words, DSSs are tools designed to facilitate a decision environment for a user. For instance, a DSS can help a physician to decide which drug to prescribe based on the patient’s medical history and a drug trial database, whereas a RS can suggest similar products by analyzing previous usage behavior, then making recommendations given a database of product data quickly.²⁰ DSSs use constructed ontology knowledge bases to make systems in the field of Health Recommender Systems, Information Retrieval, and Natural Language Processing.^20,21

Literature review

Automatic iron deficiency —anemia—detection would be helpful for supporting human immune system and a healthy life. Many techniques have been performed in the area of clinical DSSs.

Thangaraj and Gnanambal⁶ proposed a rule based DSS to diagnose Vitamin D deficiency. The researchers benefited the usage of neuro-fuzzy classifiers (NEFCLASS)-based decision-making environment, SWRL rule construction and execution environment, and ontology construction in their study. ²² Researchers first used NEFCLASS algorithms and Business Rule Management System (BRMS) to construct the rule repository and the rule engine for the diagnosis of Vitamin D deficiency.²³ NEFCLASS environment was used to generate classification rules using neuro-fuzzy classifiers from a dataset to achieve the diagnosis task.

On the other hand, based on the diagnosis, another system provided recommendations for dietary care through ontology using SWRL rules and JESS engine.²⁴ SWRL was used to create rules corresponding to Vitamin D deficiency management. The ontology was constructed from the knowledge of food supplements to manage Vitamin D deficiency. JESS inference engine was used to provide appropriate food items for Vitamin D deficiency management to patients.

Tejaswini et al.²⁵ proposes a nutrition deficiency decision support framework that models a biochemistry test report using an ontology and automatic nutrition deficiency classification. Their proposed system is planned to be used for automatic classification of nutritional deficiency in hospitals.

Chen et al. proposed a diabetes medication RS that uses an ontology knowledge base and the database of the American Association of Clinical Endocrinologists Medical Guidelines for Clinical Practice for the Management of Diabetes Mellitus (AACEMG).⁷ The purpose of the system is to analyze the symptoms of diabetes and can also choose the most appropriate drug(s) from the diabetes drugs for particular patient. The researchers used Protégé tool²⁶ to build the interrelated anti-diabetic drug knowledge and patient ontology knowledge. For building anti-diabetic drug association rules, the researchers preferred SWRL. In addition, XSLT was used to transform SWRL rules to a JESS acceptable format since SWRL cannot be used with JESS system. Finally, the researchers used JESS to develop an inference engine to generate potential prescriptions for patients through the instances of monitoring the disease, disease symptoms, and side effects.

A RS of anti-hypertensive drugs based on context-awareness and designed a context ontology was proposed by Chen et al.²⁷ Their system is capable of real-time sensing the users’ context with wearable and medical sensor devices and provides reliable anti-hypertensive drug recommendations that fulfill users’ need for drug information. They used SW and ontology engineering technologies to analyze user’s preferences. Researchers applied SWRL to create the rules of reasoning mechanism of their system to make the information recommendation of the drugs more personalized. The researchers also applied three categories of information recommendation rules that fit diverse priority levels and use a sorting algorithm to optimize the recommendations returned. To run the SWRL rules, the researchers used JESS engine to infer new knowledge. It is the fastest rule engine developed by Ernest Friedman. The engine uses the Rete algorithm to match patterns.²⁸ Jess provides two application extensions for Protégé editor which are Jess Tab and SWRL Jess Tab.

Quinn et al. proposed an information RS for diabetic and obese patients, especially for older adults which focus on personalized patient education.²⁹ In the system, information is captured related to four main entities: the patient, the medical conditions, physical activities, and the educational content. The researchers modeled these four main entities as ontology to define patients’ profile, their medical conditions, physical activities, and their educational attainments. Furthermore, the researchers applied SWRL rule-based reasoning to achieve this personalization. They used Protégé ontology editor to create their ontology knowledgebase. Furthermore, Pellet was used to reason with the SWRL rules and determined logical inferences about the data captured in their ontology.³⁰

Alharbi et al. proposed an ontology-based clinical DSS which is a diagnosis and treatment RS for diabetic patients.⁸ The researchers applied a Clinical Practice Guidelines (CPGs) for recommendations in their system which takes into account patient information, symptoms and signs, risk factors, lab tests, and then suggests a treatment plan according to the diabetes type of patient. The researchers designed ontology to model the key concepts and relationships in the clinical guidelines to allow clinical knowledge sharing, update, and reuse by using OWL-DL. In addition, the researchers used Pellet reasoner for verification of their ontology and selected the Jess’s SWRL rule-based reasoning engine to execute the SWRL rules of their system.

In this study, we proposed COntAneRS, a fully automated clinical DSS that can manage iron deficiency, which enables iron deficiency diagnosis and treatment flow for anemia patients. Technical contributions and main parts of the system (1) Iron Deficiency Domain Ontology (IDDOnt), (2) Semantic Web Rule Knowledgebase, (3) Inference Engine, and (4) Physician Portal are discussed in further sections.

System architecture and components

As aforementioned, COntAneRS is a clinical DSS to diagnose “anemia” disease and recommends proper treatment activities to physicians before decision-making. To do this, COntAneRS uses the following units and presents the recommendation results (such as proper prescription, treatment activities, and period of drugs) on the interface of COntAneRS to physicians before decision-making. The units of the proposed COntAneRS system involves (1) a fact base, (2) an ontology knowledge base, (3) a semantic medical rule base, (4) an inference engine, and (5) graphical user interfaces for physicians. Architecture of COntAneRS is demonstrated in Figure 1 and the functionality descriptions are given below. In addition, the characteristics of the proposed COntAneRS system are demonstrated in Table 1.

(a) The knowledge base of the proposed system is named as Iron Deficiency Domain Ontology (IDDOnt) which is constituted with the detailed contextual information of iron deficiency domain. IDDOnt has been developed by collaborating with domain-related physicians and using the anemia knowledge base available in WebMed.¹² IDDOnt is developed using OWL 2.0.¹⁹ The system knowledgebase consists of two essential parts: an ontology and SWRL rules. IDDOnt involves the concepts used in iron deficiency disease domain (e.g., available symptoms, vital signs, drugs, and genetic history of patients) and their relationships (e.g., drug_Prescribed → “is_a” → drug, BMI → “is_a” →Measure of Body Fat, Patient #1 → “has_Age” → 34, and Patient #1 → “has_Diagnosis” → Normal). Moreover, the medical rules of the IDDOnt are a group of If-Then-Else rules and are based on SWRL. The rules are a set of recommendations representing the procedure used by medical experts to diagnose anemia disease, treat their patients, and monitor them.

(b) Fact base consists of medical/profile data of patients retrieved from the system’s database in a given timeframe. The collection of medical facts can be the values (e.g., observed symptoms, instant vital signs, instant hemoglobin level, drug usage, and genetic history) of patients at a given time. These facts match the left sides of the If-Then-Else medical rules to determine appropriate rules to fire.

(c) Inference Engine (IE), also referred to as “reasoner,” is the essential part of the COntAneRS. IE is developed by using Java which associates suitable SWRL rules on the IDDOnt with the fact base (the medical data about patients gathered) and makes inferencing to recommend proper drugs and period of drug consumption for the patients to their physicians. In literature, many types of reasoners are available such as Pellet,³⁰ Hermit,³¹ FaCT++,³² and Drools^33–35. The reasoners are important tools to extract new medical data from the existing medical data during the inferencing process. IE uses Pellet reasoner which is developed based on forward-chaining mechanism.

(d) Graphical user interface allows the interaction between the physician and system. The interface presents inferred recommendations retrieved by the COntAneRS to the physician who will use the information to supervise and treat his/her patient for anemia disease.

Figure 1.

Architecture of the COntAneRS for iron deficiency.

Table 1.

Characteristics of the COntAneRS.

Item	Characteristic
Objective	Supporting physicians while diagnosing and monitoring their anemia patients and recommending proper drugs and treatment activities (e.g., the amount and period of consumption of the drugs) for the anemia disease
Domain	Iron deficiency -anemia- domain
Knowledge resource	Expertise, diagnosing factors, treatment rules, and supportive actions, and recommendations about the anemia disease
Knowledge acquisition technique used	Decision table and decision tree and requirements engineering
Knowledge representation technique used	OWL and SWRL languages are used to create IDDOnt and its rules, respectively
User interface	GUI by using Java
Inference engine	Pellet reasoner is preferred, and forward-chaining manner is used
Explanation facility	Recommendations by triggered rules and the relationships on IDDOnt
Development method	Prototype method
Development tools	Protégé editor, OWL API,³⁶ Pellet reasoner API,³⁷ and NetBeans Java platform
Development languages	OWL, SWRL, Semantic Query-Enhanced Web Rule Language (SQWRL),³⁸ and Java

In the development of COntAneRS, two physicians, who are specialized doctors at Afzalipour Hospital in Iran, guided the team of engineers during the development and validation of the IDDOnt and its final system. As seen in Table 1, the main functions of COntAneRS are divided into three steps as follows:

a) Decision Tree Classifier: It decides the iron condition through a patient’s blood test levels.

b) Inferring Suitable Recommendations via the SWRL Rules on the IDDOnt: Proper SWRL rules on IDDOnt are triggered by the IE of the COntAneRS, considering the demographic information, some medical data, and the classifier’s iron condition result of a patient, to produce appropriate recommendations for the patient.

c) Display Recommendations to the Physician: The recommendations deduced for the patient by the IE are shown to the user through the system’s user interfaces.

The decision tree classifier, development of the IDDOnt, and reasoning through SWRL rules are discussed with details in Sections 5, 6, and 7, respectively.

Decision tree classifier

Before diagnosis of anemia, the system firstly uses its fact base (e.g., patients’ demographic information and certain medical data) and decides then iron blood conditions by using a decision tree classifier. At the end of the classification, depending on the iron status in a patient’s blood, the diagnosis of anemia can be classified into the “Normal,” “Deficiency,” or “Hemochromatosis.” The anemia diagnostic classifier considers a patient’s profile and current medical data, as well as latest hemoglobin CBC test result. If a patient’s hemoglobin level is lower or higher than indicated in Table 2, the diagnosis would be “Deficiency” or “Hemochromatosis.” Otherwise, “Normal” is defined. Table 2 shows the normal ranges of Hemoglobin CBC level in blood according to age and gender.⁹

Table 2.

Hemoglobin CBC test.

Hemoglobin (g/DL)
Age	Male	Female
>65 years	12.6–17.4	11.7–16.1
4 5–64 years	13.1–17.2	11.7–16.0
18–44 years	13.2–17.3	11.7–15.5
12–17 years	11.7–16.6	11.5–15.3
9–11 years	12.0–15.0	12.0–15.0
6 months - 8 years	11.2–14.1	11.2–14.1
4–5 months	10.3–14.1	10.3–14.1
2–3 months	9.4–13.0	9.4–13.0
1 month	10.7–17.1	10.7–17.1
14–30 days	13.4–19.8	13.4–19.8
0–13 days	13.5–20.5	13.5–20.5

Decision tree classifier is one of the predictive modeling approaches used in statistics, data mining, and machine learning.³⁹ It is a maximum likelihood classifier that uses multi-stage decision logic. It is characterized by the fact that an unknown sample can be classified into a class using one or more successive decision functions. Table 3 presents the pseudocode of the decision tree classifier applied in the proposed system to define iron blood conditions.⁴⁰

Table 3.

Pseudocode for decision tree classifier.

Input: Patients' demographic information and certain medical data, as train data set.
Output: Patients' iron blood condition
The decision tree learning algorithm recursively learns the tree as follows:
1. Assign all training instances to the root of the tree
2. For each attribute:
a. Partition all data instances at the node by the value of the attribute
b. Compute the information gain ratio from the partitioning
3. Identify feature that results in the greatest information gain ratio. Set this feature to be the splitting criterion at the current node
a. If the best information gain ratio is 0, tag the current node as a leaf and return
4. Partition all instances according to attribute value of the best feature
5. Denote each partition as a child node of the current node
6. For each child node:
a. If the child node has instances from only one class tag it as a leaf and return
b. If not set the child node as the current node and recurs to step 2

To evaluate the system, medical data from 200 anonymous patients are collected retrospectively. The decision tree classifier applied to define iron blood conditions of patients has been modeled and evaluated using the 200 anonymous patient data (the train set contains 150 patient data, while the test set contains 50 patient data, and the sets are randomly selected). The manually entered data are mostly the patients’ basic information such as gender, age, nursing mother, pregnancy, inner bleeding patient, gastric ulcer patient, current antibiotic usage, dual capacity iron drug usage, weight, and so forth. The classifier is implemented in Java, and when the diagnose result is obtained, the diagnose result is saved into IDDOnt as to be used in SWRL rules.

Thereafter, based on the diagnose result, patient profile and other medical data, the recommendation about appropriate drugs, daily consumption doses, consumption periods of the drugs, and additional medical recommendations are to be provided through the IDDOnt, SWRL rules, and Web services to the responsible physician. Table 4 shows the details of the data set used by the system. The data given as input to the system are presented in the last column. Additionally, the output data returned after executing the SWRL rules by IE and system classifier are shown in the last column.

Table 4.

Overview of dataset used and returned results after the system classifier and IE.

No	Attribute name	Description	Input/output
1	Patient ID	Patient ID	Input
2	Age	Patient age	Input
3	Gender	Patient gender	Input
4	Nursing mother	Is breastfeeding mother?	Input
5	Pregnancy	Does the patient have a pregnancy?	Input
6	Inner bleeding patient	Does the patient have inner bleeding?	Input
7	Gastric ulcer patient	Does the patient have gastric ulcer?	Input
8	Antibiotic	Does the patient use any antibiotic currently?	Input
9	Dual capacity iron drug	Does the patient use any dual capacity iron drug now?	Input
10	Weight	Patient’s latest weight data	Input
11	Hemoglobin CBC level	Patient’s latest hemoglobin CBC level	Input
12	Diagnose result	Iron status in the patient’s blood or diagnose result for anemia	Output of the decision tree classifier. Input of the IE.
13	Drug type prescribed	Medication may require management in the form of tablets, capsules, injection, syrup, or hospital care	Output of IE (results of SWRL rules)
14	Dose	Various doses may be required on a mg basis	Output of IE (results of SWRL rules)
15	Period of the drug consumption	The drug may need to be used daily, weekly, and monthly with the required dosage	Output of IE (results of SWRL rules)
16	Other medical advices	Iron medication may interact with other medicines. The minimum time between the use of these drugs and the use of iron medicine is important. In addition, supplemental food or supplement vitamin tablets may be required with iron	Output of IE (results of SWRL rules)

Iron deficiency domain ontology

The characteristics and knowledge related to anemia patients (e.g., gender, age, iron diagnose condition based on hemoglobin CBC level, nursing mother, availability of pregnancy, inner bleeding patient, gastric ulcer patient, antibiotic usage, current other medical treatments, dual capacity iron drug usage, weight, symptoms of iron deficiency, drug prescribed for iron deficiency, its dose, period of the drug consumption, and so forth) are modeled as OWL-concepts, OWL-properties, and OWL-individuals on the IDDOnt. The important patient profile and medical information, which can interact with iron drugs, is kept on ontology, and the system aims to obtain accurate conclusions about the patient’ treatment. The ontology is established considering the medical knowledge in the form of rules and detailed conceptual information of diagnose and treatment of anemia. The ontology is coded in OWL and developed by using the Protégé ontology editor. Figure 2 depicts some portion of the IDDOnt on Protégé.

Figure 2.

Portion of the IDDOnt on Protégé editor.

IDDOnt starts with “Thing” class that is divided into various sub concepts such as “Drugs,” “Symptoms,” “Patient,” “Diagnostic Message,” and so forth. In addition, the concepts may also contain numerous sub concepts such as “DrugInteractions_Iron,” “Dual_Capacity_Iron_Drug,” “Dual_Capacity_Iron_Drug,” “Infection_Drug,” “Infection_Drug,” “Iron_Drug,” and so on. Based on those concepts, many OWL object type or OWL datatype properties are created such as “drug_Prescribed,” “hasDiagnosis,” “takeIteractionDrug,” “hasAge,” “hasGastricUlcers,” “hasGender,” “hasInfection,” “hasInnerBleeding,” “isConsuming_DualCapacityIron,” “hasWeight,” “isNursingMother,” “isPregnant,” “medicalAdvice,” “period_DrugConsumption,” and so forth. The properties are shaped to create interclass relations and to interpret OWL individuals.

Additional semantical relation that belongs to the classes is “owl:NamedIndividual.” For instance, the “Diagnostic Message” class involves three “owl:NamedIndividual” as “Normal,” “Deficiency,” and “Hemochromatosis.” The “Iron Drugs” class constitutes of “Injection,” “Iron-drop, Syrup,” and “Tablet-Capsul” instances. In addition, the “Drugs” class on the IDDOnt contains several type of drugs’ names as OWL individuals such as “azithromycin,” “calcium,” “ciprofloxacin,” “CU_copper,” “demeclocycline,” “doxycycline,” and so forth. Most of those drugs are widely used in the treatment of iron deficiency. Furthermore, IDDOnt is also developed based on the inspiration from anemia knowledge available in WebMd.¹² A summary sturucture of IDDOnt is given as a table in the Appendix 1.

Finally, the structure of the IDDOnt consists of 10 classes, 15 object-type and data type properties, 157 OWL individuals, 30 SWRL rules, and 50 real patients’ data. IDDOnt and semantic medical rules are tested by all research team members using 50 randomly selected patient data. The results returned from IDDOnt and semantic medical rules are evaluated with the collaborative physicians. It is then decided whether the rules would work correctly on IE for future patients’ evaluations. The evaluation results for a case study considered are given in the further sections. Although IDDOnt is currently limited compared with the conceptual knowledge of the iron deficiency risk domain, the IDDOnt can be enhanced accompanied by advances in drugs and treatments of anemia disease by ontology engineers over time. Technical merits about the SWRL rules in IE module of the system to generate recommendations for physicians are presented in the following subsection.

Reasoning of the recommendations by IE

The semantic medical rules of COntAneRS are generated by using SWRL.¹³ SWRL is a powerful and deductive rule description language and is standardized by W3C and based on OWL. SWRL rules are made of atoms and each atom may comprise OWL concepts, OWL object properties, OWL datatype properties, OWL annotation type properties, and OWL individuals. In addition, SQWRL is an expressive query language,³⁸ which is based on SWRL and used to query OWL ontologies. Main difference between SWRL and SQWRL is that the SWRL is an OWL rule language and SQWRL is an OWL query language. However, both of them have an antecedent part, which is known as the body, and a consequent part, which is known as the head. SWRL semantics is used for the left-hand side (inside the body) of SQWRL queries but running an SQWRL query does not alter the ontology in any way. Protégé editor, SWRL, and SQWRL are used to define and test semantic rules of the system, which provide user the combination of the problem definition facts and inference of the knowledge base.

Being supported by the Protégé ontology editor²⁶ as well as by popular rule engines and ontology reasoners, such as Jess,²⁵ Pellet,³⁰ Hermit,³¹ FaCT++,³² and Drools,^33–35 SWRL has become a very popular rule description language for emerging rule-based systems on top of ontologies.⁴¹ During the inferencing process via any reasoner, the inferencing process is executed only by running OWL individuals allocated to ontology on SWRL rules. For example, a SWRL rule is as follows: “hasParent (?x,?y), hasBrother (?y,?z) → hasUncle (?x,?z).” It means if x has parent y and y has brother z, then x has uncle z. This rule is processed on unknown individuals. Another example is “hasParent (Jessy and Tim) with the following rule as hasBrother (Tim and Jhon) → hasUncle (Jessy and Jhon). It means if “Jessy” has parent “Tim” and “Tim” has brother “Jhon,” then “Jessy” has uncle “Jhon.” Here, each parameter used in the parenthesis of the SWRL rule is an OWL individual (e.g., ?x, ?y, “Jhon,” and “Jessy”).

SWRL Tab in Protégé is used to create the SWRL rules and is located on IDDOnt. The intention of the SWRL rules is to infer suitable treatment recommendations to guide physicians according to the instant medical data gathered from their patients. IE of the system, which is software located in Web services of the system, is run by OWL individuals together with the SWRL rules to infer the suitable treatment recommendations via using Pellet reasoner. The inferred new information by the IE is stored to both IDDOnt and database of the system after reasoning process. COntAneRS aims to provide an application interface to guide physician users. A graphical interface makes the usage of COntAneRS much simpler. Pellet reasoner interprets the system SWRL rules using description logics (DL)-safe rule notion that means applying rules to only the OWL named individuals in the system ontology.

SWRL rule knowledgebase

SWRL rules associate the relations among diagnosis results, profile/genetic information of patients, and iron drugs that the patient should take. The rules are fired by considering the following medical data of patients:

— Patient profile information (e.g., age, gender, and weight)

— The availability of inner bleeding of a patient (“has inner bleeding” property),

— The gastric ulcer patient (“has gastric ulcer” property),

— The drugs used (e.g., “isConsuming_DualCapacityIron” true/false or “isConsuming_Antibiotic” true/false)

— Iron blood condition result (i.e., “has diagnosis” normal/deficiency/hemochromatosis),

— Drugs used recently, and period of usage (“has drug” and “period drug consumption” properties),

— A given medical treatment by a physician (i.e., “drug prescribed” tablets/capsules),

— Current possible conditions about cases (i.e., “is pregnant” true/false or “is nursing mother” true/false or), etc.

The data used in the system rules during inferencing process are detailed as input between the rows 1–12 of Table 4. Some examples of the system rules developed in COntAneRS are explained below. A portion of SWRL rules are shown in Figure 3.

Figure 3.

Portion of the SWRL rules created on Protégé editor.

Rule 1: If a patient’s diagnosis is deficiency, he does not have inner bleeding or gastric ulcers, and his age is greater than 20 years old, IE recommends that the patient may take 150 mg of tablets or capsules in two doses daily for four months after reasoning process.

Rule 1: The patient’s diagnosis is deficiency.

Patient (?p) ^ hasAge (?p, ?a) ^ swrlb:greaterThan (?a, 12) ^ hasDiagnosis (?p, Deficiency) ^ hasInnerBleeding (?p, false) ^ hasGastricUlcers (?p, false) → mg_DrugRecommended (?p, “150.0“) ^ period_DrugConsumption (?p, “four months, every day in two dose”) ^ drug_Prescribed (?p, Tablets_Capsuls).

Rule 2: If a patient’s diagnosis is normal, she is pregnant, and her age is greater than 20 years old, IE recommends that the patient may take 27 mg of tablets or capsules daily after the reasoning process.

Rule 2: The patient’s diagnosis is normal, but there is pregnancy.

Patient (?p) ^ hasAge (?p, ?a) ^ hasGender (?p, “female) ^ hasDiagnosis (?p, Normal) ^ swrlb:greaterThan (?a, 20) ^ isPregnant (?p, true) → drug_Prescribed (?p, Tablets_Capsuls) ^ mg_DrugRecommended (?p, “27.0“) ^ period_DrugConsumption (?p, “Everyday”)

Rule 3: If a patient’s diagnosis is deficiency, and his age is between 2 and 20 years old, IE recommends that the patient may have the injection by considering half of his weight as the amount of milligrams and use it once every 2 weeks for 12 weeks after reasoning process.

Rule 3: The patient’s diagnosis is deficiency, and age is between 2 and 20 years old.

Patient (?p) ^ hasAge (?p, ?a) ^ hasWeight (?p, ?w) ^ hasDiagnosis (?p, Deficiency) ^ swrlb:greaterThan (?a, 2) ^ swrlb:lessThanOrEqual (?a, 12) ^ swrlm:eval (?m, “0.5*w,” ?w) → drug_Prescribed (?p,Injection) ^ mg_DrugRecommended (?p, ?m) ^ period_DrugConsumption (?p, “Once every two weeks for 12 weeks“).

Rule 4: If a patient’s diagnosis is deficiency, he has inner bleeding, and his age is greater than 20 years old, IE recommends that the patient may take 200 mg by injection in five doses in 2 weeks.

Rule 4: The patient’s diagnosis is deficiency, age is greater than 20 years old, and has inner bleeding.

Patient (?p) ^ hasAge (?p, ?a) ^ hasDiagnosis (?p, Deficiency) ^ swrlb:greaterThan (?a, 12) ^ hasInnerBleeding (?p, true) → drug_Prescribed (?p, Injection) ^ mg_DrugRecommended (?p, “200.0“) ^ period_DrugConsumption (?p, “5 Dose in two weeks“).

After the inferencing process, the physician portal of COntAneRS presents certain medical recommendations to guide the user physician about the proper type of iron drug, the proper amount, and period of consumption. All SWRL rules created are validated through the capability of SQWRL querying on Protégé. By the use of this ability of Protégé, the list of patients, iron drugs, and dose of the drugs inferred are presented to our collaborated physicians, and thus the validation of the system’s rules is evaluated.

A case study

At the time of appointment in the health center, clinicians (nurse, receptionists, etc.) interview the patient and collect other relevant information. Figure 4 depicts a physician interface of the system which guides to the physician when analyzing a patient after gathering that patient’s information. The physician is able to see the system recommendations such as diagnose result, suitable drug for medication, suitable dose for consumption of the drug, and the drug consumption time for a selected patient. A physician is also able to search his patients on the panel and display all iron drugs prescribed and the dose information assigned. The patient names are anonymized for ethical reasons on the Figure 4.

Figure 4.

Interface of the iron deficiency management module.

The following case study, which discusses a patient who is pregnant, depicts the profile and medical data about the pregnant patient on the physician portal. The data asserted for the patient are her age, gender, weight, is she a nursing mother, availability of any infection issue, availability of gastric ulcers, is she pregnant, availability of any inner bleeding, iron blood condition, etc. Table 5 indicates this patient case analyzed by her physician.

Table 5.

Patient case analyzed by a physician interface.

Data asserted to the patient in the IDDOnt	Recommendations deduced by IE
“isNursingMother→false” “has Age→31” “hasInfection→false” “hasGastricUlcers→false” “isPregnant→true” “hasGender→female” “hasInnerBleeding→false” “hasDiagnosis→Normal” and so forth	“drug_Prescribed→Tablets_Capsuls" “mg_DrugRecommended→"27.0"^^xsd:double” “period_DrugConsumption→Everyday” “medicalAdvice→"It is better to take your iron tablets or capsuls with vitamin C."”

Figure 4 shows the system’s recommendation panel. In this panel, iron drugs, the dosage of the iron drug and duration of consumption, which are found suitable for this patient case, are deduced by IE and presented by the system to guide the physician with recommendations. IE module provides the physician with the necessary recommendations by running the rules that recommend appropriate treatment activities according to the risks and complications of this patient. In addition, the medical advice “It is better to take your Iron tablets or capsules with Vitamin C” is also recommended to the physician for the patient.

Experimental studies and empirical findings

The details related to the experimental studies including the methodology, verification, validation, and limitations are explained in this section. Moreover, comparison with the state-of-the-art is presented using the proposed COntAneRS system and Vitamin D deficiency management system (VitaminDDMS), Anti-Diabetic Drugs Recommend System (Anti-Diabetic Drugs RS), and Decision Support System for Diabetes Diagnostic (DSS Diabetes D).

Methodology applied

The engineering stage of COntAneRS is divided into three stages

(1) Modeling Stage: IDDOnt is designed as a domain ontology and its semantical medical rules which are cooperatively created by entire research team.

(2) Development Stage: one knowledge base and Java developer engineer developed the IDDOnt, its rules, and its system services by using the Protégé ontology editor and Java by collaborating with research leaders and the specialized internal medicine physicians.

(3) Verification and Validation Stage: COntAneRS has been evaluated by the collaborated two internal medicine physicians at Afzalipour Hospital in Iran. To evaluate the system, medical data from 200 anonymous patients are collected retrospectively, and then experimental studies of the system are conducted. Patient data collected includes demographic information and certain medical data of patients, such as gender, age, Hemoglobin CBC level, nursing mother, pregnant, inner bleeding patient, gastric ulcers patient, antibiotic usage, dual capacity iron drug usage, weight, drug prescribed before, its dose, and period of drug consumption. The fields of the data set used were detailed in Table 4. Next section discusses the verification and validation steps of the system proposed in more detail.

Verification and validation

The system is evaluated by the physicians and the research leaders on medical data from 200 anonymous patients. The experimental studies of the system are done using the system physician portal which is designed and built in Java. To check the effectiveness of the system, the data of randomly selected 50 anonymous patients are entered into the system manually and the system is verified according to the inference results. For the 50 cases, the recommendations of the system after the inferencing process are compared with the recommendations of the physicians after the manual evaluation. The aim is to check whether the recommendations provided by the system make sense, so that they are in line with the recommendations to be provided by physicians.

The system has nine different iron drug dose (mg) recommendations for the anemia patients prescribed. In addition, there are five different types of iron drug in the system (syrup, injection, tablet, capsule, and hospital care). In addition, five different time periods are recommended as the drug consumption period in the system. Four different recommendations are categorized in the system as additional medical recommendations or drug interaction warnings. Therefore, considering that, at least one or two of the additional medical recommendations are recommended by the system (other possibilities would be an improbable treatment according to our physicians), and the maximum number of recommendations of the system can arise in 1350 different combinations with the possibility of C (9,1) x C (5,1) x C (5,1) x C (4, 2).

The recommendations that are proposed by both the system and the physicians are defined as True Positive (TP). In addition to this, the recommendations proposed by the system but are not proposed by the physicians are defined as False Positive (FP). The recommendations that are not proposed by the system and are not actually suitable for the patient are True Negative (TN). Furthermore, the recommendations that are not proposed for the physicians but actually should have been proposed to the patient are defined as False Negative (FN).

Considering these metrics, the accuracy, precision and recall of the system are calculated based on the given formulas in equation (1), equation (2), and equation (3)

{acccuracy}_{suggestions} = \frac{TP + TN}{TP + TN + FP + FN} = \frac{202 + 1114}{202 + 1114 + 4 + 2} = 0.995

(1)

{precision}_{suggestions} = \frac{TP}{TP + FP} = \frac{202}{202 + 4} = 0.98

(2)

{recall}_{suggestions} = \frac{TP}{TP + FN} = \frac{202}{202 + 2} = 0.99

(3)

Accuracy determines how accurate the system is, and how accurate the recommendations are proposed by the system. Precision is related with to what extend the system defines correct recommendations for the patients. In addition to precision and accuracy, recall is defined as the specificity of the system. In other words, relevantly proposed recommendations affect the metric recall. It can be observed that for 50 patients, the system has made 206 recommendations. From these 206 suggestions, only four of them are classified as unnecessary by the physicians and are not suggested. FN defines the recommendations that should be but are not proposed by the system. In addition to the suggested recommendations, two suggestions are suggested additionally for the physicians. These additional recommendations are defined as FN for the system. TN is the recommendations that are not valid and are not proposed by the system. TN for the system is 1114 recommendations for 50 patients.

Considering the precision and recall of the proposed system, it can be said that 98% of the recommendations proposed are correct for the patients considered, and considering the recommendations that should have been proposed, 99% of them are assigned by the system.

During the verification phase with our collaborated HE, the missed suggestions in our rule set were observed in the first round of tests and the missing suggestions were integrated to the existing SWRL rules on the IDDOnt. Therefore, in case of similar cases, these missed suggestions will not be skipped anymore during further inferencing processes. Results in the second round showed that the system produced accurate and almost complete suggestions for all cases. In the second round of tests, the accuracy of the system performance increased to 0.99 after adding the missed suggestions to the rules.

Limitations

In knowledge-based rule-supported systems, as the number of rules in the system’s knowledge base increases and the features processed in the rules become more diverse, the complexity and contradictions in the rules increase which might have adverse effect for the accuracy of the system. Such rule-based systems require a validation process to add more rules to the system’s knowledge base over time and avoid conflicts with existing rules. This process, with the help of experts, enables to find and resolve conflicts between numerous rules in huge knowledge bases, and increase the accuracy of the system. The complexity of the problem domain focused can also affect rule conflicts and contradictions. In this study, we achieved a good result because the rule set was not overcrowded, and feature conflictions were not an issue. However, if more features, such as drug interactions, vital values, and other blood lab values, are included, this success will progress in the reverse direction and decrease. As the complexity and conflictions between rules decrease over time, accuracy will increase again.

Comparison

In the literature, a rule-based decision support system, called VitaminDDMS,⁶ was proposed to diagnose Vitamin D deficiency. The researchers used a neuro-fuzzy classifier in their system. They also developed an ontology about food supplements. The system deduces some supplementary recommendations to its users for the treatment of Vitamin D deficiency. VitaminDDMS⁶ system provides a guideline on the management of Vitamin D deficiency through its SWRL rules. The researchers also used Java Expert System Shell (JESS) in the reasoning stage to recommend suitable food supplements. They also measured the level of satisfaction on the diet plans offered to the system users.

In another study called Anti-Diabetic Drugs RS,⁷ an ontology and SWRL rule-based diabetes medication recommendation system was considered. Its ontology involves the knowledge of the diabetic drugs’ nature attributes, type of dispensing and side effects, and patients’ potential symptoms. It also uses SWRL for its rules and Java Expert System Shell (JESS) to induce possible prescriptions for patients. The aim of the system was to analyze the symptoms of diabetes as well as to select the most appropriate drug from related drugs. In the system evaluation, the researchers used drug recommendations. The drugs recommended by the system were compared with the drugs recommended by a doctor for each patient. The system is evaluated with 20 patient data. The researchers have also calculated the accuracy, precision and recall of their system. In that study, TP represents the doctor’s agreement on the recommended drugs and FN represents the doctor’s disagreement on the recommended drugs.

On the other hand, DSS Diabetes D⁸ was proposed as a diagnosis and treatment recommendation system for diabetic patients. The system considers patient information, symptoms and signs, risk factors, and laboratory tests and then recommends a treatment plan based on the type of diabetes recommended by the Clinical Practice Guidelines (CPGs). DSS Diabetes D system uses similar methodologies that are used in this study, namely, ontology development, SWRL rule base and inference with JESS inference engine.

Table 6 compares the proposed COntAneRS system with the aforementioned three similar studies which are semantic-based Vitamin D deficiency management system (VitaminDDMS),⁶ anti-diabetic drugs recommend system (Anti-Diabetic Drugs RS),⁷ and decision support system for diabetes diagnostic (DSS Diabetes D).⁸ As a result of the comparison analysis made on similar RSs, it is observed that the proposed system has functional advantages.

Table 6.

Comparison of the proposed COntAneRS with Vitamin D Deficiency Management System (VitaminDDMS), Anti-Diabetic Drugs Recommend System (Anti-Diabetic Drugs RS), and Decision Support System for Diabetes Diagnostic (DSS Diabetes D).

	Vitamin D DMS⁶	Anti-Diabetic Drugs RS⁷	DSS Diabetes D⁸	COntAneRS
Considering drug interactions	—	√	—	√
Presenting suitable medical recommendations to guide physicians	—	—	√	√
Availability of a user interface	—	√	—	√
Suggestion of proper drug prescription	√	√	√	√
Suggestion of proper period of drug consumption	√	—	—	√
Suggestion of proper drug dosages	√	√	—	√

Conclusion

There are many prescriptions for patients who have Iron deficiency problem. We propose COntAneRS system (Clinical ONTology-based Iron Deficiency ‐ ANEmia ‐ Recommendation System) as a clinical decision support system to diagnose iron deficiency anemia and manage its treatment. The applied methodologies and main technical contributions of this study are discussed in four aspects: (1) Iron Deficiency Domain Ontology (IDDOnt), (2) Semantic Web Rule Knowledgebase, (3) Inference Engine, and (4) Physician Portal of the system. The system has its own semantic rule knowledge base that provides appropriate medical recommendations on the treatment activities of iron deficiency risk such as proper drug types, doses, and periods of the drug consumption for anemia patients. The rules are based on the Semantic Web Rule Language (SWRL) to provide high-level context reasoning and information recommendation.

First, the decision tree classifier is used to diagnose iron deficiency condition based on a patient’s demographic information and certain medical data, as well as recently measured hemoglobin CBC level of the patient. Thereafter, based on the diagnosis, the recommendation about appropriate iron drugs, daily consumption dose, and consumption periods of the drug, and additional medical recommendations are to be provided through the system ontology, SWRL rules, and Web services to the responsible physician. This system not only simplifies the work of physicians but also provides a supportive interface for educating medical students.

An experimental study conducted with a group of anemia patients demonstrated that 98% of the recommendations proposed are correct for the patients considered, and considering the recommendations that should have been proposed, 99% of them are assigned by the system. The system is verified as capable of providing a recommendation service of high-quality medical information. The management of the iron deficiency problem in the blood is already a complex task in itself because it regularly requests a visit to physicians or dietitians. Instead, as a future study, we will study an automatic food recommendation system for iron management in blood acts as a helping hand for people by eliminating many medical formalities and reducing the time of domain experts.

In addition, the proposed system currently processes only one blood test measurement (HCT CBC level) as objective data in its SWRL rules. Other parameters of the SWRL rules are demographic data, recent drugs used, medical background, and so forth. However, there are many alternative methods that can precisely determine whether a patient really has iron deficiency. For example, in the diagnosis of iron deficiency, the blood substances’ tests such as serum iron in the blood, serum ferritin measurement, transferrin level capacity (TIBC), or total iron binding capacity (UIBC) may give more accurate results. In addition, hormone levels, especially thyroid hormone, are also one crucial sign of anemia. It is also possible to explore a blood substance called “erythrocyte protoporphyrin.” As it can be seen, many blood tests are an alternative screening method in diagnosing anemia. Therefore, as another future study, the existing SWRL rules of the system can be enhanced to process more detailed blood metrics.

Footnotes

Acknowledgments

No funds, grants, or other support were received.

Authors Contributions

Duygu Çelik Ertuğrul was born in Turkey. She is an associate professor in the computer engineering department at the Eastern Mediterranean University, Famagusta, North Cyprus via Mersin-10, Turkey. Her research topics are related to the Web and Semantics; Composition and Discovery of Semantic Web Services, Semantic Search Agents, Rule-Based Expert Systems, m-Health, and Healthcare Knowledgebase Expert Systems. She is one of the organizers of two international workshops and one international symposium: “IEEE International Workshop on ESAS: E-Health Systems and Semantic Web” since 2006, “Security of Information and Networks (SIN) between 2007 and 2011” and “IEEE COMPSAC Symposium on Web Technologies & Data Analytics (WEDA) in 2016.” She also supervises several research and development projects supported by the university, government, and industrial companies. She has organized a special issue for Expert Systems: The Journal of Knowledge Engineering and served as guest editor. She has published numerous articles/book chapters/book in several international/national journals and conferences on the topic of Web Semantics and Mobile Medical Healthcare Services and Systems. She is also the author of various books or book chapters about “Composition or Discovery of Semantic Web Services” and “Semantic Web based e-Health Services.”

Önsen Toygar was born North Cyprus. She received her B.S., M.S., and Ph.D. degrees in 1997, 1999, and 2004, respectively, from Computer Engineering Department of Eastern Mediterranean University, Northern Cyprus. Since September 2004, she worked in Computer Engineering Department of Eastern Mediterranean University. She is currently a Professor in the department and served as the Vice Chair of the department between September 2011 and January 2013. Her current research interests are in the area of biometrics, computer vision, image processing, and digital forensics.

Neda Foroutan was born in Iran. She is graduate student in the Computer science Department at the Saarland University, Saarbrücken, Germany. Her research topics are related to semantic Web, artificlal intelligence, Machine learning and fairness.

Conflicts of interest

The authors have no financial or proprietary interests in any material discussed in this article.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article.

Ethics approval statement

For this type of study formal consent is not required.

ORCID iD

Duygu Çelik Ertuğrul

Appendix

References

McLean

Cogswell

Egli

, et al. Worldwide prevalence of anaemia, WHO Vitamin and Mineral Nutrition Information System, 1993‒2005. Public Health Nutr 2009 Apr; 12(4): 444–54.

Abbasi

Kashiyarndi

. Clinical Decision Support Systems: A discussion on different methodologies used in Health Care. Marlaedalen University Sweden, 2006.

Chen

Hsu

, et al. Developing guideline-based decision support systems using protégé and jess. Comput Methods Programs Biomed 2011 Jun 1; 102(3): 288–294.

Khalili

Sedaghati

. Semantic medical prescriptions -- towards intelligent and interoperable medical prescriptions. In: IEEE Seventh International Conference on Semantic Computing. IEEE, 2013, pp. 347–354. DOI: 10.1109/ICSC.2013.66.

Yao

Kumar

. CONFlexFlow: integrating flexible clinical pathways into clinical decision support systems using context and rules. Decis Support Syst 2013 May 1; 55(2): 499–515.

Thangaraj

Gnanambal

. A rule based decision support system for aiding vitamin d deficiency management. Indian J Sci Technol 2014 Jan; 7(1): 48–52.

Chen

Huang

Bau

, et al. A recommendation system based on domain ontology and SWRL for anti-diabetic drugs selection. Expert Syst Appl 2012 Mar 1; 39(4): 3995–4006.

Alharbi

Berri

El-Masri

. Ontology based clinical decision support system for diabetes diagnostic. In: 2015 Science and Information Conference (SAI). IEEE; 2015 Jul 28, pp. 597–602.

Camaschella

. Iron-deficiency anemia. New Engl J Med 2015 May 7; 372(19): 1832–1843.

10.

Miller

. Iron deficiency anemia: a common and curable disease. Cold Spring Harb Perspect Med 2013 Jul 1; 3(7): a011866.

11.

Abebe Dename

Mengistu

. Ontology based decision support model to diagnoses anemia in children. Int J Adv Stud Comput Sci Eng 2017; 6(6): 22.

12.

WebMed . “Iron”, WebMed Medicine Journal [Online]. WebMed. Available: www.webmd.com/vitamins/ai/ingredientmono-912/iron (Accessed May 2020).

13.

Horrocks

Patel-Schneider

Boley

, et al. SWRL: a semantic web rule language combining OWL and RuleML. W3C Member Submission 2004 May 21; 21(79): 1–31.

14.

Grosan

Abraham

. Rule-based expert systems. In: Intelligent Systems. Berlin, Heidelberg: Springer; 2011, pp. 149–185.

15.

Lee

Wei

. KBSLUA: a knowledge-based system applied in river land use assessment. Expert Syst Appl 2008 Feb 1; 34(2): 889–899.

16.

Berners-Lee

Hendler

Lassila

. The semantic web. Scientific Am 2001 May 1; 284(5): 34–43.

17.

Gruber

. Ontology. Encyclopedia of database systems. Humanistic Al, 2008. Available: http://tomgruber.org/writing/ontology-definition-2007.htm (Accessed 13 Jan 2021).

18.

Lassila

. Resource description framework (RDF) model and syntax specification. W3C Recommend, 1999. http://www.w3.org/TR/PR-rdf-syntax.

19.

McGuinness

Van Harmelen

. OWL web ontology language overview. W3C Recommendation 2004 Feb 10; 10(10): 2004.

20.

Liang

. Recommendation systems for decision support: an editorial introduction. Decis Support Syst 2008; 45(3): 385–386.

21.

Woo

Yang

Lee

, et al. Healthcare decision support system for administration of chronic diseases. Healthcare Inform Res 2014 Jul 1; 20(3): 173–82.

22.

Nauck

. Fuzzy data analysis with NEFCLASS. Int J Approx Reason 2003 Feb 1; 32(2-3): 103–30.

23.

Swennen

. Open rules: An open source business decision management system linking business and technology. (Master's thesis, UHasselt Diepenbeek). UHasselt Diepenbeek, 2012.

24.

Friedman-Hill

. Jess, the rule engine for the java platform. . Manning Publications, 2008.

25.

Tejaswini

Manohara Pai

Pai

, et al. An ontology-based decision support system for nutrition deficiency. In: 2020 IEEE International Conference on Distributed Computing, VLSI, Electrical Circuits and Robotics (DISCOVER). IEEE, 2020, p. 267–274. DOI: 10.1109/DISCOVER50404.2020.9278069.

26.

Protégé . “Protégé OWL Ontology Editor”, Stanford University [Online]. Protégé. Available: http://protege.stanford.edu (Accessed 15 Feb 2021).

27.

Chen

Jin

Goh

, et al. Context-awareness based personalized recommendation of anti-hypertension drugs. J Med Sys 2016 Sep 1; 40(9): 202.

28.

Forgy

. Rete: a fast algorithm for the many pattern/many object pattern match problem. In: Readings in Artificial Intelligence and Databases. Morgan Kaufmann, 1989 Jan 1, pp. 547–559.

29.

Quinn

Bond

Nugent

. Ontological modelling and rule-based reasoning for the provision of personalized patient education. Expert Syst 2017 Apr; 34(2): e12134.

30.

Sirin

Parsia

Grau

, et al. Pellet: a practical owl-dl reasoner. J Web Seman 2007 Jun 1; 5(2): 51–53.

31.

Shearer

Motik

Horrocks

. HermiT: a highly efficient OWL reasoner. Owled 2008 Oct 26; 432: 91.

32.

Tsarkov

Horrocks

. FaCT++ description logic reasoner: system description. In: International joint conference on automated reasoning. Berlin, Heidelberg: Springer, 2006 Aug 17, pp. 292–297.

33.

Proctor

Neale

Lin

, et al. Drools documentation. JBoss 2008 Jan; 5(05): 2008.

34.

Drools engine, (n.d.). http://www.drools.org/ (Accessed June 25, 2019).

35.

SWRL Drools Tab. http://protege.cim3.net/cgi-bin/wiki.pl?SWRLDroolsTab (2012, Accessed 25 June 2019).

36.

Horridge

Bechhofer

. The OWL API: A Java API for working with OWL 2 ontologies. In: Proceedings of the 6th International Conference on OWL: Experiences and Directions. CEUR-WS. org, 2009 Oct 23, 529, pp. 49–58.

37.

Pellet API . OWL 2 Reasoner Java API. Stardog-Union. Available: https://github.com/stardog-union/pellet (Accessed 15 Feb 2021).

38.

O'Connor

Das

. SQWRL: a query language for OWL. OWLED 2009; 529: 2009.

39.

Swain

Hauska

. The decision tree classifier: Design and potential. IEEE Trans Geosci Electron 1977; 15(3): 142–147.

40.

Aruljothi

Eapen

. Booster in high dimensional data classification using Cnn and decision tree algorithm. Int J Recent Technol Eng July 2019; 8: S5.

41.

Bassiliades

. SWRL2SPIN: A tool for transforming SWRL rule bases in OWL ontologies to object-oriented SPIN rules. arXiv preprint, 2018 Jan 27.

A rule-based decision support system for aiding iron deficiency management

Abstract

Keywords

Introduction

Background

Literature review

System architecture and components

Decision tree classifier

Iron deficiency domain ontology

Reasoning of the recommendations by IE

SWRL rule knowledgebase

A case study

Experimental studies and empirical findings

Methodology applied

Verification and validation

Limitations

Comparison

Conclusion

Footnotes

Acknowledgments

Authors Contributions

Conflicts of interest

Funding

Ethics approval statement

ORCID iD

Appendix

References