Advisory System

Cheetah advisory system

Prelude

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 KB 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 doesnt 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.

Advice

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

Examples:

• 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).

Steps:

• 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 advise.

Type B Advice

Examples:

• 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.

Steps:

• 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

Examples:

• 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.

Steps:

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

The Glucose Model

Model Properties

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. More concretely speaking, there should be a model mapping conditions to glucose levels over time. For each certain interval, say every hour, the model looks at the conditions and predicts blood sugar levels. If, given certain conditions, future glucose levels are optimal then the system knows the conditions are also optimal.

Conditions

Conditions are things like insulin or food intake, activities, current time, current glucose levels, health status etc. Conditions come in three kinds. 1. The first ones are certain 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. The second ones are 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. 3. The third ones are conditions which effect are yet unnknown. For example, you're eating something totally exotic and the system cant give an estimation. The effects of such a condition are yet to be estimated.

Model types

The type of model can be of several types.

• 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.
• A neural network. [This is a stub]
• A different method like a kernel machines.

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).
• Feasibility (is it feasible to make within project time)

Generation Of Advice

As defined in advice type A, a prediction will be maximally made of the next 24 hours. To make a prediction about a certain period, the conditions 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.