Along with the massive influence of computing technologies in medical research and practice, the wide generation of patient, clinical and lab test data makes the assistance of intelligent information systems a very important factor for correct therapy, surveillance and advising of the patients. In this context decision support systems play an increasingly important role in medical practice. The implementation of a decision support system (DSS) in diabetes treatment and in particular in organizing an improved regime of food balance and patient diets is the target area of the presented study. Based on the recently created Diabetes Mellitus Treatment Ontology (DMTO), our DSS for dietary recommendations generates broader and more precise advices to patients with a known clinical history and lab test profiles. These recommendations are rule-based decisions derived using the DMTO subontologies for patient's lifestyle improvement and the data from the patient records.
Medical decision support and other intelligent applications in biomedical practice
and research depend on increasing amounts of data and digital information.
Intelligent data integration in the bio-medical domain is understood as a means
of combining data from different sources, creating a unified view and new
knowledge and improving their accessibility to a potential user [
Healthcare processes are getting more complex. The cognitive abilities of
individual caregivers and teams that manage acute and chronic disorders are
increasingly challenged. On a population scale, well-founded decisions need to be
made to warrant a maximum of healthcare at acceptable costs [
Ontologies are widely used in biological and biomedical research. Their
success lies in the combination of several important features presented in almost all
ontologies: provision of standard identifiers for classes and relations that
represent the phenomena within a domain; provision of a shared vocabulary for the
particular domain(s); provision of metadata that describes the intended meaning
of the classes and relations in ontologies; provision of machine-readable axioms
and definitions that enable computational access to some aspects of the meaning
of classes and relations [
The major aim of this study is to develop an ontology-based DSS for
dietary recommendations for diabetes mellitus. The principal tasks of the work are
related to the intelligent integration of patient lab test and clinical data and
developing suggestions of a medically well-defined diet plan based on these data.
The knowledge base of the system is implemented using DMTO and a set of
appropriate Semantic Web Rule Language (SWRL) rules [
In the recent decades ontologies are considered one of the richest semantic
structures to facilitate knowledge representation, integration, and reasoning [
All type 2 Diabetes Mellitus (T2DM) diagnoses, complications, lab tests,
physical examinations, and symptoms can be collected from the standard DDO
biomedical ontology [
The principal focus of our study is put on the reasoning capabilities based on DMTO in order to specify the formal needs and decisions in diet management and control of the T2DM patients. The creation of a DSS for diet recommendations is a promising step towards developing a sound approach for elaboration of an interactive software-based system intended to help endocrinologists and dietologists to develop and manage appropriate diet schemes for the treated patients. Such software solutions are intended to become part of the information systems of electronic medical health records being under development. 3
Our DSS for dietary recommendations is a typical knowledge-based system. It
consists of the following main components: an input part (containing patient data
as well as food data), a user integration point with RESTFul API service, a data
integrator, a knowledge base, an inference engine, and a storage part including:
diet recommendations cache, food data storage and patient instance base (Fig. 1).
Its functional architecture is analyzed in details in [
The knowledge base is implemented using DMTO and a set of newly defined production rules in SWRL format. These rules are designed to play the role of expert knowledge providing the creation of general and personalized treatment plans for T2DM patients.
A structured model for a patient’s blood data is defined in the anamnesa (disease history) part of the hospital record for the patient, holding information about the levels of his/her cholesterol, glucose and uric acid. The preparation of the patient data record consists of extending the Anamnesa element and providing a more fully defined structure.
The original Anamnesa (medical or disease history) XML tag has only text content and no child elements. The improved Anamnesa contains Blood elements which consist of child elements. Each child element represents a blood lab test and it is called by the name of the lab test – TotalCholesterol, Glucose or UricAcid. In addition to its value, the lab test element has also attributes min-threshold and max-threshold giving information about the range of the value.
Here is an example of this extension: <Anamnesa> <Blood> <TotalCholesterol units=”mmol/l” min-threshold=” 0” max-threshold=”5.2”>4.39</ TotalCholesterol> <Glucose units=”mmol/l” min-threshold=”3.3” max-threshold=”6.2”>10.13</Glucose> <UricAcid units=”umol/l” min-threshold=”208” max-threshold=”428”>379</UricAcid> </Blood> </Anamnesa>
Patient data is imported through the server endpoint. The server stores it in the patient instance base. Each import of patient data contains the patient’s profile and all lab tests related to it. In addition to this information, a treatment plan, a lifestyle subplan and a diet plan are created. After appropriate reasoning, the proportions and amounts for macronutrients for each meal are set for the particular patient.
Knowledge base – extension of DMTO and integration of heterogeneous knowledge sources
The DMTO ontology and the set of SWRL rules form the core of the knowledge base of our DSS for diet recommendations. When receives a query for diet suggestion, the server calls the selected reasoner (Pellet, a freely accessible OWL DL reasoner that can work with SWRL rules) which is doing the data analysis and solution generation. Then the server returns the result.
Each import contains a list of ambulatory records. An ambulatory record is related to a certain patient. For each ambulatory record a patient profile is created or updated. Lab tests are linked with the patient profile via the property has_lab_ test of the patient profile entity. When all ambulatory records are imported into the instance base, the changes are saved and the generated identifiers of all created patient profiles are returned.
The most important component of the knowledge base of our system is the
Diabetes Mellitus Treatment ontology DMTO, whose structure is enriched with a
number of object properties. DMTO is a comprehensive OWL ontology that
provides the highest coverage of formalized knowledge about T2DM patients’
current conditions, previous profiles, and T2DM-related aspects, including
complications, symptoms, lab tests, interactions, treatment plan (TP) frameworks, and
glucose-related diseases and medications. The current version of DMTO includes
more than 10,700 classes, 277 relations, 39,425 annotations, 214 semantic rules,
and 62,974 axioms. It provides proof of concept for an ontology-based approach
to modeling TPs [
Each patient has at least one profile. If a patient has a treatment plan, then he/she has at least one profile (the one used to tailor the plan), but not vice versa. A treatment plan is an action plan and has subplans that have some participants. Education and lifestyle subplans have many classes. Each plan has a date and a target that defines the plan’s target weight and glucose. The patient profile class could collect all of the patient’s electronic health record features. According to this profile, each patient is assigned a specific plan.
The first and most important modification of DMTO in our implementation is the change of the type from RDF/XML to OWL/XML, in order to be able to create the has_lifestyle_participant and has_breakfast_meal object properties.
RDF/XML is a serialization syntax for RDF graphs while OWL/XML is a serialization syntax for the OWL 2 Structural Specification. RDF/XML ontologies couldn’t be represented properly using standard XML tools. Moreover, there has been a desire for a more regular and simpler XML format. This is why OWL/ XML has been invented. It has been considered a concrete representation format for OWL ontologies.
The has_lifestyle_participant property is an object property of type diet. This property is owned by lifestyle subplan. Similarly, has_breakfast_meal is an object property of type meal. It is owned by the diet class. These properties are essential for building the chain treatment plan – lifestyle subplan – diet – meal. Our next modification is related to the extension of ’patient profile’ to have more than one lab test (Fig. 2).
Fig.2.ClassdiagramofthethreelevelsofDMTO’smaincore.
DMTO is built as a set of modules. These modules are implemented from scratch or imported from other well-known ontologies. For example, the temporal aspects are imported from the TIME ontology. Building DMTO in multilayer formsupportssubsequentmaintenanceandimprovement.Theboldlinesandelements on the class diagram indicate all the elements we have used in our DSS.
A number of production rules for setting diet meal parameters in order to achieve a personalized diet with different proportions between fat, carbohydrates andproteinsaredefinedforeachmeal(currentlyjustforbreakfast).Forahealthy person with values for “total cholesterol”, “plasma fasting glucose” (Glucose) and “urine blood” (Uric Acid) in normal intervals, the proportions are 30% fat, 50% carbohydrates and 20% proteins. For a person with values out of norm, the proportions are 20% fat, 40% carbohydrates and 40% proteins – raising protein amount and lowering carbs and fats.
These production rules are implemented in SWRL. Each rule contains three basic components:
• Used variables and fields, for example: meal(?bf), patient(?x), ‘treatment plan’(?tp), ‘patient profile’(?y), diet(?di), ‘lifestyle subplan’(?sub), has_patient_profile(?x,?y), has_treatment_plan(?y,?tp), has_part(?tp,?sub), has_lifestyle_participant(?sub,?di), has_breakfast_meal(?di,?bf) • Left-hand side – specification of custom values for the patient diet attributes, as for example: swrlb:divide(?fat_grams_bf,?amount_fat_bf,9), swrlb:divide(?prot_grams_bf,?amount_prot_bf,4), swrlb:multiply(?amount_bf,?ca,”0.25”^^xsd:double), swrlb:multiply(?amount_carbs_bf,?amount_ bf,”0.5”^^xsd:double), swrlb:multiply(?amount_fat_bf,?amount_ bf,”0.3”^^xsd:double), swrlb:multiply(?amount_prot_bf, ?amount_bf, “0.2”^^xsd:double) • Right-hand side – the suggested values of the diet attributes for the particular patient: has_carbohydrate_per_meal(?bf,?amount_carbs_bf), has_amount_of_calorie_for_meal(?bf,?amount_bf), has_fat_per_meal(?bf,?amount_fat_bf), has_protein_per_meal(?bf,?amount_prot_bf), has_carbohydrate_grams(?bf,?carbs_grams_bf), has_fat_grams(?bf,?fat_grams_bf), has_protein_grams(?bf,?prot_grams_bf)
To identify if a patient has lab test results within or out of the normal ranges, another set of rules are defined checking that and also setting the required ratio between fat, proteins and carbohydrates according to the lab tests results. The ratio of fats, carbohydrates and proteins is determined for each meal in the patient’s diet.
In the course of the experiments we initialize, integrate and give values to the particular patient profile elements: patient plans (treatment, lifestyle, diet), patient total calories, total cholesterol lab test, fasting plasma glucose (FPG) lab test, uric acid lab test and diet referred to breakfast meal.
We check if there are lab test values for total cholesterol, glucose and uric acid. Then we check whether any of the lab tests are in normal range or out of normal range. The normal proportions between carbohydrates, fats and proteins are correspondingly 50%, 30% and 20%, as mentioned in the previous section. If any lab test value is out of norm, the protein part is increased. Then the number of calories and the amount in grams for carbs, fats and proteins properties of the breakfast meal are calculated. The number of calories is calculated from the total calories for breakfast multiplied by the proportion of the macronutrient to the whole meal. The number of grams is calculated using the number of calories (Fig. 3).
Each patient profile includes a number of laboratory tests: FPG, Total Cholesterol and Uric Acid. The patient profile also includes a treatment plan. The treatment plan includes a lifestyle subplan. For the lifestyle subplan, a diet with breakfast meal is set as result of the experiment.
If all data for the patient mentioned above is available, then a reasoning procedure is applied. The reasoner executes the rules for the proportions of macronutrients. There is a rule for each lab test checking if its value is in or out of the normal range. For “Total Cholesterol” this range is 0 – 5.2, for “Glucose” it is 3.3 – 6.2 and for “Uric Acid” is 208 – 428.
The first experiment with our diet DSS was based on importing patient data with lab tests in norm. An amount of 1700 total calories was set as a referent patient profile. The patient profile included laboratory tests as: FPG – 4 mmol/l, Total Cholesterol – 5 mmol/l and Uric Acid – 379 umol/l. A treatment plan was created for the patient profile, including a lifestyle subplan where a set of diets for breakfast meal was suggested.
Other experimental tests with the implemented system were done in cases when there were patient data with lab tests out of norm. The total calories were again 1700. We imported data of a few patients with different lab tests exceeding the normal range. One patient had Total Cholesterol of 6 mmol/l, second patient had FPG of 10.13 mmol/l and the last patient had Uric Acid of 500 umol/l. For each of these patients the proportions between the macronutrients were set to 40% carbs, 20% fats, and 40% proteins.
Another series of experiments with our DSS were conducted to generate suggestions for particular food menu options based on the recommended number of calories and proportions of macronutrients (see Fig. 4). For this purpose, standard techniques for constraint satisfaction problem solving have been implemented.
The current version of the DSS provides only a command line user interface. The implementation of convenient GUI is one of the first tasks in our plan for future work on improving the usability of the system. 6
The presented approach for design and implementation of a decision support system for diet recommendations has many advantages and at the same time leaves some open problems to be overcome.
Advantages. The system works with common diabetes-related attributes like uric acid, FPG, cholesterol and their number can be easily extended and used in more complex systems. This provides both simplicity and extensibility of the designed DSS. The input of the system is provided by a user-friendly software module which can be linked directly to lab information systems and this gives a good level of convenience both for patients and doctors. A strong side of the system is related to two groups of patients. The first group consists of the patients using all necessary data about the calories of the food components and this is related mostly to the packaged foods where all values for carbs, fats and proteins are well described. The second group of patients are interested in weights in grams that are very useful when the food is cooked and each food composition can easily be calculated.
Open problems. Our current approach does not take into consideration the additional treatments and drugs which are applied for the other patient’s diseases. For some diseases, the patients should be very careful about possible dangerous interactions of foods and medicines. Some extension in this direction of the functionalities of our system is planned for the near future.
In conclusion, it should be noted that the work presented in this paper discusses some results of the development of an original ontology-based DSS for dietary recommendations for diabetes mellitus – a widespread socially significant disease caused mainly by the modern way of life in the developed countries. The workflow of our DSS is based on the successful integration of a number of modern semantic technologies. It provides reusability and a good level of interoperability with other healthcare information systems. 7
This research is supported by the National Scientific Program “eHealth” in Bulgaria. Methodological support was received from Project BG05M2P001-1.001-0004 “Universities for Science, Informatics and Technologies in the e-Society (UNITe)” funded by Operational Program “Science and Education for Smart Growth” cofunded by European Regional Development Fund.