Advisory System

From AardRock Wiki
Jump to: navigation, search

Cheetah advisory system


Cheetah will generate advice about insulin doses or food intake. Several software packages offer this kind of functionality, but none of them an advice as personal as Cheetah will. The system learns from the user and learns how its body reacts on events such as insulin usage, food comsumption and activities like sports. The generated knowledge base about the user is then shared (anonymously) with other users over the internet. Likewise, the user receives knowledge from other users. And this is exactly what makes Cheetah unique: it will be the first diabetes software that doesn't just learn from one isolated user, but learns from all. This combined with a smart knowledge inferencing system will add up to a complete diabetes health system.


Three types of advice can hypothetically be generated. The first one is short-term, and gives advice about today. The second one tackles long-term problems and generates modifications to the current food/insulin diet. The third kind of advice generates a complete diet for you. [Type A is a must for Cheetah, while types B and C are optional at the moment]

Type A Advice


  • Ann wants to eat grandma's pie. Given her current glucose level, she wants insulin advice to prevent a hyper.
  • Ann will exercise in 2 hours, and wants food advice to prevent a hypo.

Advice Features:

  • Advice is generated about insulin doses or food intake about today (max. 24h ahead).


  • The user asks for short-term advice
  • The system presents a scheme on which the user fills in today's future insulin or food intake. (Needs a intuitive and easy UI which allows the user to choose default values). The user can fill in "?" which are events to be advised.
  • Cheetah puts these things into his model and sees how to fill in the ?'s to make the glucose prediction as stable as possible.
  • Cheetah presents the advice.

Type B Advice


  • Ann always has a hypo at night. She wants advice to prevent this to happen again.
  • Ann always has a hyper in the evening. She wants advice to prevent his to happen again.

Advice Features:

  • Advice is generated not only for today, but is more general. Unlike type A, the (hypo/hyper) problem is recurrent.


  • The user (and Cheetah) spots a hypo/hyper problem and wants a solution.
  • Cheetah searches what causes the recurrent problem.
  • Cheetah presents the cause and gives advice how to solve this.

Type C Advice


  • Pete has very many hypo's and hypers and wants the system to make a complete food diet for him.
  • Pete goes on a food diet and asks the system to make a new insulin advise for him.

Advice Features:

  • Advice consists of a complete new personal diet, generated from scratch.


  • [This is a stub] System makes everything a variable and optimizes the curve.


System Overview

Lets begin with thinking about Type A Advice and forget type B and C advice. Regardless of the precise implementation, the system needs a way to (trustably) predict if the user will be o.k. given some conditions, and will not be o.k. given some other contitions. For now, lets forget on how this system can be build/learned, and just look at the properties of such system. In such system, the "o.k.-ness" is directly linked with the blood sugar level: these should between some variables, say 5 and 15. Also, the system should be able to say if a person will be o.k. in 1 hour, in 2 hours, in 3 hours etc. Variable activities like eating an apple, taking medicine or jogging have effect on the blood glucose level. After a blood glucose level measurement, the user (at will) receives advice.

The system needs some systems to achieve this:

  • A learning system that learns from each blood glucose measurement. By statistical inference it couples recent activities (conditions) to the change in blood glucose level.
  • A database storing all predicted effects of conditions
  • A prediction system using the database to make predictions about the following blood glucose measurement. [This could be reinforced by a glucose-insulin interaction model]
  • An advisory system using the prediction system advising the user how to optimize user health.

Read Condition Effect Learning to follow advancements on the learning system front.


Conditions are things like insulin or food intake, activities, current time, current glucose levels, health status etc. Conditions come in two kinds.

  1. Conditions, from which the effect is certain. Such conditions are current time and current glucose level (if measured). These could also be hard-coded events which effects are certain a priori.
  2. Conditions from which the effect is uncertain (system can give an estimation) or unknown (no estimation possible yet):
    • a) Predicted uncertain conditions. Such conditions have been seen before, and the effect has been estimated (with some certainty). Ann (or someone else in the network) has eaten grandma's applepie before, and the system has estimated the amount of effectivly absorbed carbs. Or: Ann has done a hockey training before, and the system has estimated (with some certainty) the amount of used glucose over the hours.
    • b) Conditions with unknown effect. These are new conditions. For example, you're eating something totally exotic and you nor the system cant give an estimation. The effects of such a condition are yet to be estimated.

Prediction system types

The prediction system currently is not planning to be uncomplicated, meaning that it will do a simple addition of individual effects.

Alternatives are:

  • A model with domain knowledge like the AIDA system. The system uses 12 mathematical functions to map input (taken carbs, insulin usage) to a glucose prediction. The system was tested clinically and generated a meaningfull prediction for 80% of the patients. As they say themselves, the system lacks some things like variable personal reaction to food and insulin types. Adding this would significantly improve the model. There exist other, better models than AIDA, which still have to be investiged.
  • An evolved neural network.
  • A different method like a kernel machine.

Model Performance

While trying out different models we should be able to evaluate their performance by some set of requirements.

  • Reliability of predictions at start (zero days of learning).
  • Reliability with training set of one week, month, quarterly and year.
  • Time needed to update model (happens daily, max some seconds, or else a background process).
  • Robustness (ability to ignore erroneous new input) and ability to cope with unknown conditions.
  • Feasibility (is it feasible to make within project time)

As defined in advice type A, a prediction will be maximally made of the next 24 hours. By limitations of temporal predictability of effects, the system can only learn about a condition effect by a certain inteval. For example: One eats an apple for breakfast, and the next glucose measurements are 2h and 4h later. Because the system can only learn the apple effect 2h and 4h after consumption, it is hard to make predictions about other 1h later. Since the glycemic response is non-lineair, inter- or extrapolating with just one or two measurents is nearly impossible.

Generation Of Advice

To make a prediction about a certain period, the conditions(food/medicine/activities) of this period have to be filled in. These could be default values, edited to match today. The user should be able to left some fields blank (or a questionmark) to indicate the to be advised values. The model then searches in the state space for the most optimal solution. This can be done with common algorithms like hill climbing. Then the most optimal optimal solution is presented.