Virtual Dietitian: A Nutrition Knowledge-Based System Using Forward Chaining Algorithm

Introduction

The prevalence of a Knowledge-Based System (KBS) in these modern times still originates from the same mission of extracting human expertise to be then translated into binaryfriendly knowledge that a computer may use to solve similar problems. By virtue of a reasoning-like process of applying a set of rules, KBS utilizes similar rules-of-thumb that human experts use thus allowing computer programs to simulate the judgement and behavior of experts in a particular field [1]. In the nutrition science field, KBS and other techniques used in the branch of Artificial Intelligence (e.g., Artificial Neural Networks, Fuzzy Logic, Probabilistic Methods, Evolutionary Computing, and Learning Theory) are customarily applied in Precision Nutrition (PN) [2]. PN refers to the development of tailored nutrition guidelines at an individual level. With the union of computer science and nutrition science, a myriad of applications were proposed and implemented. Unfortunately, the inclusion of PN in these applications is still limited. This, as a result, yields a research gap in both fields. A systematic review of nutrition recommender systems (RS) demonstrated that PN integration to the reviewed software applications is still scarce [3]. The same paper also affirmed that a nutrition RS, if properly designed, could function as a practical tool to promote nutrition adequacy and a healthier lifestyle. This gap set forth the present study as an attempt to develop a nutrition KBS with consideration to PN concepts.

This paper reports the third part from the series of studies that has been covering the development of VD. The first part of the series focused on Plan-Cook-Eat (the original name of VD), which was designed to recommend healthy meal plans in accordance to total daily energy expenditure (TDEE) with proper consideration to an optimal macronutrient distribution [4]. Plan-Cook-Eat received positive quantitative ratings and useful feedback; however, participants also highlighted some shortcomings of the study. This includes adding more healthrelated system modules, integrating nutrition knowledge, and fostering a community within the application. The additional features that emerged in the first study renovated Plan-CookEat into VD – which is a larger and more intelligent nutrition system grounded on Nutrition Care Process (NCP). To assess whether VD is the right solution, the second study covered a mixed-methods needs-analysis [5]. In this preliminary study of VD, nutrition challenges of Filipino young adults as well as the applicability of a KBS as a nutrition intervention tool were determined. Results show that people do not track what they eat that leads to overeating or undereating. Fortunately, participants expressed their willingness in using a computerbased nutrition tool to improve their dietary behavior. With this confirmation, the present study was set forth as the third part from the series with the following research aims:

1. Extract domain knowledge from human experts on nutrition and dietetics as well as nutrition science research to build a knowledge base associated to the automated formulation of personalized meal plans;
2. Develop a nutrition KBS strictly anchored on NCP to emulate knowledge of dietetics professionals in meal selection and meal plan generation; and
3. Perform a beta evaluation through a mixed-methods research design using user study and SUS.

Background of the Study

Experts from decades ago classified KBS into five main types: (1) Expert Systems, (2) Intelligent Tutoring Systems, (3) Hypertext Manipulation Systems, (4) Database with an Intelligent User Interface, and (5) CASE Based Systems [6]. In a more recent survey of expert system applications [7], KBS was categorized according to its methodologies: rulebased systems, neural networks, fuzzy expert systems, and case-based reasoning systems. Notwithstanding, the standard components of a common KBS (inference engine, memory, user interface, knowledgebase) and its architecture design (as shown on Figure 1) remain the same. Additionally, there has been a proposed improvement in the knowledge-based expert system lifecycle [8] that includes a longer cycle and more processes compared to traditional expert systems architecture The core processes of these lifecycles, as also shown on Figure 2, are knowledge acquisition, knowledge verifications and validation, and knowledge representation. The first step, knowledge acquisition, is the most significant task in the KBS lifecycle, which is performed by a knowledge engineer. A knowledge engineer who is not familiar with the expertise of a domain expert must first acquire the background in that particular domain. Typically, this process incorporates factfinding methods such as interviews, questionnaires, record reviews, and observation. The acquired knowledge should be then validated against the body of knowledge (experiments, document guidelines, books, other experts), and immediately documented in a knowledge representation scheme.

If-then rules (rule-based) are one of the most usual forms of knowledge representation utilized in expert systems where the if part is the antecedent (premise or condition) and the then part is the consequent (conclusion or action). A typical rule-based system is composed of three components: the rule base, working memory, and inference engine. The rule base, also called as knowledge base, is the set of rules representing the knowledge about the domain, and is expressed using this production rule: "if condition then action" or "condition ⇒ action". Furthermore, the working memory represents the set of facts known about the domain, which reflects the current state of the world. On the other hand, the inference engine derives new information from a specific problem by utilizing rules in the rule base and knowledge in the working memory.

Rule 1:

IF diet_type(X, Y) AND food(Z, X)
THEN meal(Z, Y)

Rule 2:

IF allergy(A, B) AND !diet_type(C, A)
AND food(D, C) THEN meal(D, B)

Rule 3:

IF allergy(H, P) OR disease(D, P) AND food(F, H)
OR food(F, D) THEN restrict_meal(F, P)

Rule 1 represents the knowledge that if X is a diet type preferred by Y, and Z is an example of food for such diet X, then Z is the recommended meal for Y. In real life example, it means that if "Manuel"" prefers "Vegetarian Diet", and "Tofu scramble with beans and Chorizo" is a sample meal for such diet, then suggest that meal to "Manuel". On the other hand, Rule 2 represents the knowledge that if B has an allergy of A, and C is a diet type recommended for people with allergy A, and D is an example of food for such diet C, then D is the recommended meal for B. In other words, if "Manuel" has a "skin allergy" and "Complex Carbs Diet" is the suggested diet, which includes food like "Low Carb Beef & Zucchini Lasagna" then recommend such meal for "Manuel". Finally, Rule 3 represents the knowledge that if P has an allergy H, or disease D, and that food F is not good for P with allergy H or disease D, then all meals will be restricted, and food F will not be recommended. In other words, if "Manuel" is allergic to peanuts and with a diagnosis of hypertension then a meal like "Spicy Chicken Peanut with Pickles" is not included for recommendations since the meal contains peanut that is not good for allergy and pickles that are an ingredient to avoid when cooking food for people with hypertension.

Rule 4:

IF Body Image Goal == "Cutting"
THEN TDEE = TDEE - (TDEE * 0.20)
ELSE IF Body Image Goal == "Bulking"
THEN TDEE = TDEE + (TDEE * 0.20)
ELSE IF Body Image Goal == "Maintaining"
THEN TDEE = TDEE

Rule 5:

IF BMI < 18.5
THEN TDEE = TDEE + (TDEE * 0.20)
ELSE IF BMI >= 18.5 AND BMI <= 24.9
THEN TDEE = TDEE
ELSE IF BMI >= 25.0
THEN TDEE = TDEE - (TDEE * 0.20)

Under circumstances that there is a possibility of firing multiple rules, in which If parts are satisfied to be executed at the same time (the rules have the same condition, also known as conflict set), then a conflict resolution strategy is going to take effect. In VD, the main strategy to resolve such conflict is through variable labeling in terms of its risks and priorities (Figure 3). In the case of rule 4 and rule 5, it is possible that a person would prefer to gain weight even when diagnosed as obese, lose weight even when diagnosed as undernutrition, or maintain current weight even though a significant change in weight is necessary. In any of this scenario, VD observes the appropriate nutrition guidelines as well as the standard Body Mass Index (BMI) classification, which overrides the weight management goal set as the user preference. Together with a conflict set, these rules are stored in the knowledge base and used by an inference engine to compare it with facts stored in the working memory. These processes, until it derives a goal and result, are executed via a Forward Chaining Algorithm.

Forward chaining algorithm begins with initial facts and keep using the rules to draw new conclusions. For the sake of comparison, a backward chaining algorithm commences with a hypothesis to prove, and keeps looking for rules that would allow concluding that hypothesis [9]. VD utilizes forward chaining algorithm by starting with the initial set of elements (e.g., domain knowledge) in the working memory, and keeps on firing rules until there are no rules to be used, or the goal has been attained. Further, forward chaining is the suggested algorithm if a KBS needs the possible information (e.g., diet preferences and restrictions) prior to inferring personalized dietary plans. A basic instance of how the forward chaining algorithm was integrated with VD is illustrated below:

Rule 6:

IF Weight > Ideal Body Weight
THEN Weight Status = "Overnutrition"

Rule 7:

IF Weight Status == "Overnutrition"
THEN TDEE = "cutting"

Rule 8:

IF TDEE == "cutting"
THEN calories = TDEE - (TDEE * 0.20)

The initial fact of Weight > Ideal Body Weight helps infer the value of Weight Status from the rule 6, then rule 7 fires due to the inferred Weight Status (so TDEE is inferred), and then the rule 8 fires to infer calories. With forward chaining, the goal (calories) is achieved because of pattern matching.

Materials and Methods

A. Forward Chaining Algorithm

Prior to building the forward chaining algorithm, domain knowledge was extracted as part of knowledge acquisition. It includes doing informal interviews with registered dietitians and nutritionists, conducting a literature review on nutrition science research, and extracting relevant data from nutrition guidelines. Inferring meal plan recommendations to form an action of PN is then formulated by facts and rules of domain knowledge descent. Consequently, a match-fire procedure in the If-Then production rules is executed by using the forward chaining algorithm as the reasoning technique.

The meal recommender system of VD takes into account a myriad of factors from personal preferences to populationbased nutrition and health guidelines to determine the best nutrition recommendations. As vast as nutrition science, there are instances when dietary recommendations become challenging not only to encourage or support healthy eating behavior but also in predicting what people would like to eat. Moreover, their choices are often affected by several factors [10], not to mention it is multi-faceted, culturally determined, and context-dependent. In short, users may have a variety of preferences (e.g., the desire to eat protein-packed foods), and constrained needs (e.g., allergy or disease-related restriction). In order to generate personalized meal plans as part of the nutrition intervention, personal details are recommended to be encoded on the VD settings. This will help VD to filter the most appropriate meals up to its last ingredients. Then, the TDEE will be divided by the number of preferred meal spacing values – or the number of times a user wants to eat in a day. Each meal could be labeled as breakfast, snack, lunch, or dinner whereas only the meals under a specific food subgroup will be part of the recommended meals of the day.

Unless the ingredients are measured up to its last gram, it is important to note that the sum of the calories of the meals of the day could not be exactly the value of TDEE, rather, it will not be more than or less than its 5% (e.g., 2000 calories could have a range of 1900 to 2100 calories). Further, users can also control how much food to eat in one meal by adding a percentage distribution on the settings page. This is a very important feature of VD since the amount of food that an individual eats in a meal varies from person to person. That is, one person may prefer to eat less during breakfast while others do not. Let us suppose that an individual needs to consume at least 3000 calories to maintain the current body weight and a 30-40-30 meal distribution was instituted for breakfast, lunch, and dinner. For this particular scenario, VD will generate a meal plan of 900 calories for breakfast, 1200 calories for lunch, and 900 calories for dinner.

dist((x, y), (a, b)) = √ (x - a)² + (y - b)²

B. Nutrition Knowledge-Based System

Upon generating a daily meal plan, several processes are triggered by VD. To start with, forward chaining algorithm filter the meals according to user preferences and restrictions. Let us suppose that there are 1000 recipes in VD and a user only prefers to eat Filipino cuisine (20%, 200 recipes) using either by microwave (10%, 100 recipes), grilling (30%, 300 recipes), or stir-fry (30%, 300 recipes). The algorithm will start on the cuisine preference and will remove all other recipes that do not belong to Filipino cuisine. After the first condition, only 800 recipes will remain. Then, it will proceed to the next condition (technique preference) and will remove all other recipes that do not belong in microwave, grilling, or stir-fry. Depending on the composition of the remaining 800 recipes particularly on its technique categories, the remaining recipes will vary. If in some cases there are more preference or restriction data available, another set of condition will run to filter again the filtered list of meals. Assuming that there are 200 remaining meals as candidates for the meal plan after running the forward chaining algorithm, the meal list will be ranked by calculating Euclidean distance between similarly rated recipes among users. Euclidean distance (equation 1) is a distance-based similarity measure, which calculates, first, the distance between users and then similarity. Compared to other similarity measurements such as Log Likelyhood, City Block, Uncentered Cosine, Tanimoto Coefficient, Pearson Correlation, and Spearman Correlation, Euclidean Distance Measure has the highest performance quality [11]. In cases that a user cannot yield rankings due to lack of data, meals are selected randomly from the filtered meals.

C. Mixed-Methods Evaluation

With respect to a mixed-methods research approach, this study followed a convergent parallel design where both the quantitative and qualitative methodologies are concurrently achieved in the same phase of the research process. Further, it treats both methods equally, analyzes the two components independently, and interprets the findings together [12]. For this study, quantitative and qualitative results corroborated and supported one another as well as compare the outcomes to better understand how it achieved such results. Because the beta evaluation is dedicated on the initial prototype only, standardized tasks and SUS evaluation were utilized. First, the standardized tasks were carried out since RS rely on user interaction. In the RS handbook, this evaluation approach is commonly known as “user studies” where participants are recruited and asked to perform standardized tasks requiring an interaction with the RS [13]. Quantitative measurements such as task completion and the time taken to perform the tasks and qualitative feedback were collected. After the user study, the prototype was rated using SUS – a standardized questionnaire for assessing perceived usability. This 10-item questionnaire was developed by Brooke [14] in response to the insufficiency of objective usability (effectiveness and efficiency) as the primary metrics for the assessment of user satisfaction with systems [15]. In its original version, the structure of SUS was designed using alternating positive and negative statements to control acquiescence bias. This is also beneficial for researchers to easily identify respondents who were not attentive to their evaluations. However, there are evidences that this format can create more problems than it solves [16]. Following a retrospective survey [17], all negative statements were transformed into positive in order to prevent usual mistakes and misinterpretations in an alternating items. In that study, they found no evidence of acquiescence bias in the positive version of SUS and no statistically significant difference with the normal SUS (p > 0.39). The beta evaluation started on November 9 and ended on December 1, 2020. Finally, there were also open-ended questions included in the system evaluation to extract deeper explanations regarding the quantitative findings.

Results and Discussion

The beta version of VD was evaluated by six dietitians, which comprised of 67% clinical dietitians and 33% from the fitness sector. Four out of six (67%) dietitians work in the government sector while the remaining two dietitians (33%) work in the private sector. On the other hand, six information technology experts rated the beta version of Virtual Dietitian as well who all work in the private sector. Out of these six professionals, three (50%) of them work as web developer, one (16.67%) as a mobile app developer, one (16.67%) as networking specialists, and the remaining one (16.67%) as a computing professor. In summary, a total of 12 participants were recruited in the beta evaluation.

A. User Study

As part of the objective to test the usability of the system prior to its final release, a set of standardized tasks were performed by participants to determine whether they could perform the tasks or not, and the duration it takes to finish it. This is a vital part of the system development as it shows how potential users interact with the product and reduce the risks of developing the wrong one. Similar technique [18] was performed to evaluate the prototype of a web system for library usage where usability factors and the initial humansystem interaction are an essential part of assessment. Table 1 shows how participants performed in the beta test in terms of task and mean time completion. Among these tasks, those that requires interaction to users (e.g., asking for input data, changing user settings) received less than the perfect score. On the other hand, tasks 3 and 4 that asked users to navigate the system (e.g., looking at recipe pages and food nutrition facts) received perfect scores. Therefore, changes have to be made in terms of the infrastructure of the system. Aside from these task efficiency scores, the succeeding discussion explored the qualitative metrics per task to support this data.

Task 1: Visit Virtual Dietitian website and have a read through the “Getting Started” information in a form of onboarding. When you are ready, register an account.

The first task of beta testers was to read the introductory message in a form of onboarding, which aims to discuss the purpose of the application, and then register an account. As this is the main landing page to capture potential app users, the primary design goal is to make it as informative and as appealing as possible ([P3]: The introduction page with the carousel and illustrations look professional). Loading speed was also a concern, hence, the use of SVG images rather than traditional image files ([P7]: Onboarding is very nice. And the use of SVG illustrations is a good choice). Afterwards, testers moved on to the registration page where they have to fill up a multi-step form consisting of account information, personal information, and dietary preferences and restrictions ([P12]: Excellent for including gender, activity, etc. as these are needed for calculating the Total Energy Allowance or Energy Expenditure which dietitians used to determine the amount of food). Although the first task received numerous positive feedback, there were also negative responses:

• Consider adding information in the homepage similar to the onboarding so that users will get to know the website in the homepage right away. [P2]
• I am not sure if it is possible but I will like it even more if there is a tutorial on how to use the website app or a simple guide in the onboarding. [P4]
• There are too many items to fill up. Better if it is only username and password. [P5]
• Other buttons sometimes do not work. I have to refresh the page again to make it work. [P10]

Task 2: Go to the recipe database page and have a look at the meals under Cuisines, Techniques, Diets, and Courses. Visit at least one recipe page per each category.

Afterwards, beta testers proceeded to the recipe section to visit at least one recipe per each category. In total, there are 1,636 recipes with nutrition facts and 12 categories under cuisines, five categories under techniques, and six categories under courses ([P2]: The website has so many contents. It looks overwhelming at first but it is definitely helpful once you get to know the website). The main goal of a recipe page is to display recipe cards that look as inviting as possible to encourage clicks ([P7]: Recipe page looks professionally designed and that modern CSS codes are used). Even so, there are nutrition information when you hover your mouse on each recipe card to highlight the most important data without too much clicks ([P1]: I like the layout and the hover effect on each recipe card. Adds professionalism on the app). Each recipe is complete with instructions, ingredients, and nutrition facts ([P2]: I personally like the design and that every meal has nutrition information. Without this, it is difficult for dietitians to estimate the nutrition). Nevertheless, beta testers still found bugs and errors:

• The featured image with a back button positioned on the top left portion is confusing. [P4]
• Some unapproved recipes are visible for regular users This becomes problematic since their data is incomplete for example ingredients and steps. [P7]
• Favorite button is not working. [P10]
• Collection page gives me a 404 response and the collection box where you add recipes is not working especially on adding new collection name. [P11]
• The hover effect of recipe cards looks professional but I would like to see important information such as nutrients without going to actual page. [P12]

Task 3: Go to the food database page and have a look at the foods under Basic, Branded, and Restaurants. Visit at least three food pages to see the nutrition facts.

Then, beta testers proceeded to food database where they visited at least three food pages. In total, there are 12,897 foods complete with nutrition facts and 16 categories based from various databases ([P1]: Good job for using credible source such as the FNRI and USDA. This is what we also used in the hospital aside from the food exchange list from the book of FNRI, [P2]: I don't have to look at the Food Exchange List in a book which I used as a reference). With exact nutrition facts, total calories as well as macronutrients and micronutrients were accurately calculated as well. This also gives users the information they need to arm themselves on how to select their foods and meals ([P5]: I never thought that there are macronutrients that we should consider in a food aside from the vitamins and minerals). Nevertheless, beta testers still had their recommendations for improvement:

• I think you should add the source of nutrition data for each food for reference of users. [P4]
• Print button is not working. [P7]
• There are redundancies in the nutrients UI. [P8]

Task 4: Change your account settings and setup meal distribution (meal percentage and spacing). Afterwards, add your food preferences and restrictions.

The next task of beta testers is to navigate the settings page where they can setup their preferences, restrictions, and meal distribution (such as meal percentage and meal spacing) – all related to the meal generation process. This allows users to generate meal plan as flexible as possible, and in line with their real-life dietary activities. Although there are positive feedback on this task ([P7]: I like the fact that the navigation in the settings page is an ajax-based menu, [P10]: Looks very wellcoded and flexible), there are crucial findings that need to be fixed prior the live version:

• Please be careful on the use 'diet' in preferences. For dietitians, this may have a different meaning. This could also be confusing and should not be suggested for people with underlying conditions. FAD diets are very common nowadays. I suggest to remove the 'diet' preferences. [P1]
• I like to make a comment on the meal spacing. If you choose less value, for example 2, and you have to eat at least 3000 calories, then you will have a large amount of calorie in just one eating. This might not be recommended for some people. [P2]
• I like the settings page but submenus are visible without permission. As unauthorized user, I should not have a capability to edit or even see it. [P9]

Task 5: Go to Diary and generate a meal plan for three days. Tap all the checkbox beside each meal then Check the printable grocery list as well.

Lastly, beta testers generated a meal plan for three days ([P3]: As a dietitian, it usually take me a lot of time to plan for my patients' meal). The number of meals and the total calories are all based from user’s data, hence, the application of PN. There is also a generator for printable grocery list based on the ingredients of meals generated by VD ([P5]: Looks professional to me. Also the printable grocery list is a plus). Further, there are checkboxes allotted for each meal to record user meal intake. A button to change the meal is also available. When clicked, a certain meal is modified but the total calories is still in compliant with the user’s needs. In this final task, there were no recorded negative feedbacks nor suggestions to improve the meal generation.

B. System Usability Scale

To measure system usability of VD beta version, SUS was utilized. First, usability was measured as early as this stage of the project to determine the differences between the desired system functionalities and user behavior. In software development, these differences are better to be revealed as soon as possible as to ensure that the final version meets not only the objective of the project but also of the system. In short, early usability tests meant to find out the product’s future, which includes both potential success and problems, and give the developers an opportunity to polish the project at the earliest possible. Moreover, this early usability test aims to determine the missing features as well that might be more beneficial if included in the final version. Next, SUS was utilized as the instrument as this provides a quick and reliable way of systems testing that is cost-effective, valid, and accurate. Since Phase 1 deals with a beta version, SUS is the perfect instrument for measuring usability. The results show that VD acquired a mean score of 83.4, which could be interpreted as “excellent” according to the corresponding adjective rating scale for SUS Scores [19].

For the initial assessment of VD, participants expressed that they "like the idea of automating meal plan [P2]" and that the idea of this web app is "very promising especially for someone like me who didn't know that the calculation of calorie per person is important to determine the amount of food to eat [P10]". Although, some participants have some reservations especially for meals as "some foods might not be recommended for some people with underlying condition [P1]". Futher, there is also a suggestion to "consider budget constraints when generating meals [P3]". Nevertheless, both factors such as chronic diseases and budget were part of the study limitation. Nevertheless, user experience was praised by beta testers as it "loads fast probably because of the good coding practices applied and the use of modern languages such as CSS3 and HTML5" [P8]. The inclusion of large food database for nutrition facts was also noted since "without the database of food nutrition, you cannot determine what and how much food or meals to recommend [P6]".

Conclusion

This study focused on the development and beta testing of VD to provide a nutrition intervention tool in response to the inadequate nutrition problems of Filipino households. A prototype of VD was subjected to evaluation by information technology experts and registered dietitians to ensure system quality standards were followed as well as that the generated meal plans and other nutrition data were reliable and correct. Despite receiving 83.4 SUS score and 85% completion rate, feedback from experts provided changes for consideration prior to moving to the next and last phase of VD. Achieving a good nutritional status should be attainable to everyone. With VD, creating healthy meal plans according to personal preferences, restrictions, and energy expenditure aims to be a fundamental dietary approach that leads people to nutrition adequacy. Although there is still much to be improved in the project as nutrition and dietetics is truly a broad field, VD is already a fully functional nutrition KBS that could provide better patient care and improve public health.