Introducing the Problem
I clearly state here that I am not a doctor or any kind of medical professional! I am writing these posts only to reflect my experience and share my story of how I used technology at a personal level to tackle one of the tedious and critical tasks we have in our daily life. So, this content does not constitute any professional medical advice, diagnosis, or treatment!
I split my write-up into 3 parts which I post successively. In this first post, I intend to describe the problem and provide essential domain knowledge to make it smoother to follow up the following posts.
The second post will describe the data, data extraction, preparation and transformation. The last (third) post will explain the modelling part and how I used AWS DeepAR algorithm to tackle the discussed problem.
At this moment, the other two post are not yet published, I will update those lines with the links when published.
Being a parent of a child with type 1 diabetes (T1D) is a kind of a hassle, even with being fortunate to acquire smart systems like continuous glucose monitoring system (CGM) and insulin pumps. Those are small computerized devices to mimic the way the human pancreas works by delivering small doses of short acting insulin continuously. However, these devices still need a lot of careful tuning and parameterization to deliver the correct amount of insulin at the right time. The parameters and factors' values are basically calculated and set by diabetes doctors along with the discussion with the patient (parent in our case).
Periodically (e.g., every 2 months), the diabetes doctor looks through the blood glucose levels registered by the CGM and the insulin amounts delivered by the insulin pump and tries to adjust particular factors, aiming to keep the blood glucose in range. Normally, the values are set following some rules and learning from experience, patterns and trends.
I believe we are so privileged to have a doctor who regards discussing the technical details. So every check-up appointment, we have a deep discussion akin to brain storming session to decide which parameter to keep and which to adjust.
Frankly to say, those discussions always tickle my sentiment regarding extracting knowledge and insights from data, as what we basically try to do is to find some patterns in the historical data and try to optimize the pump parameters in order to keep the blood glucose within range! It looks like a very legit machine learning problem! That stimulated my current passion regarding AWS and its machine learning algorithms, so I tried to experiment using AWS to enlighten our parameters-setting discussions! Yes, it might not yet be obvious how my problem is an awesome use case of AWS, so let me explain the details of the problem to be more acquainted with technical terms.
It is ironic that we can not actualize either the wise saying of the scientist and philosopher, Benjamin Franklin (1706-1790) "Eat to live, and not live to eat." or the sarcastic quote by anonymous "I don't eat to live, I live to eat"; without possessing a well-functioning pancreas!
The pancreas is an organ that plays a very essential role in converting the food we eat into fuel for the body's cells. A principal function of the pancreas is to regulate blood glucose. The pancreas secretes a hormone called insulin in response to elevated blood glucose levels. The insulin acts as a key 🗝️ to unlock the cell allowing the glucose to enter the cell and being used for energy. I tried to visually simplify the idea in the animation below.
So, without insulin, the glucose remains in the bloodstream, which can lead to dangerous complications like what is called hyperglycemia. If hyperglycemia is not treated, it may lead to even more serious problem, a condition called ketoacidosis (diabetic coma!). Without proper production of insulin, the body can't thrust glucose into cells and the body reacts by breaking down the body fat to use for energy!
A consequence of this temporary remedy of producing energy by breaking down fats is the production of waste products called ketones. It's a sad thing to know that our bodies cannot tolerate large amounts of ketones and tries to get rid of them through the urinary system. But it is even sadder to know that if the body cannot release all the ketones and they build up in the bloodstream, the ketoacidosis will be life-threatening and needs immediate treatment.
The plot below from  shows how the insulin production goes hand in hand with the glucose levels increase caused by the meals.
You might get many insights from the above plot, but two essential observations to understand for our machine learning problem which also map sharply to two insulin components used by the insulin pump to imitate the pancreas are:
- There are peaks (bursts) of insulin production by the pancreas every time the body consumes food. The insulin pump tries to imitate these peaks by injecting a quick-acting insulin before mealtimes and it is called Bolus.
- The plot above never crosses 0 of the Y-axis. In other words, the pancreas, continuously, produces some base amount of insulin around the clock. To mimic this, Basal insulin is continuously injected throughout the day as a longer-acting insulin that helps keep glucose levels steady day and night.
This plot from  shows the two insulin types Basal and Bolus working together to mimic the pancreas function.
Now we know that insulin pumps are smart devices that attached to the patient body and tries to mimic the function of the pancreas by delivering both types of insulin, the Basal and the Bolus.
We tried using different types of insulin pumps and each had its pros and cons for us. Lastly, we ended up using Omnipod system for a couple of years now. Even though Omnipod still lacks the closed-loop control system compared to Medtronic products, i.e., it does not allow the CGM (glucose sensor) to communicate directly to inject the insulin, we still see its tubeless system is a great advantage for our active kid.
The insulin pump PDM allows setting a basal program (i.e., schedule) to deliver a pre-set insulin amount for each pre-set time period. I thought at the beginning that the basal should have only a single value for the whole day/week, but it turned out the need for insulin changes during the day based on the person's activity level and other conditions. We can also have multiple basal programs to meet different activity levels and conditions such as weekends or gym-days. The image below shows how a basal program looks like as a graph and as a list that stored in the Omnipod PDM (personal diabetes manager).
When deciding to have a meal, we should also decide how much insulin we take for that a meal. A that moment, we should garb a pen and a piece of paper and calculate a bolus dose that consists of two components:
- A component that is proportional to the carbohydrate-content of the meal with a coefficient of proportionality that is called Insulin-to-Carbohydrate factor (ICF). This ICF defines how many carbohydrates can be handled by one unit of insulin.
- It is typical that the blood glucose be at an undesired level due to some error propagation. For instance if we incorrectly calculated the carbs for the breakfast, the blood glucose may stay high till the dinner time if we do not correct as rapidly as possible. Hence a second bolus component is calculated when having a meal or whenever required during the day. This correction component is controlled by a Correction Factor (CF) which defines how much one unit of insulin lowers the blood glucose level, and then we can calculate how much insulin we need to reach our an optimal (preferred) target blood glucose level, e.g. 5.0 mmol/L.
So, to calculate a bolus dose we use this simple equation:
As an example, suppose we pre-decided that these factor to be, ICF=20 and CF=10. And suppose the patient would like to drink a cup of milk which contains 10 gm of carbohydrates. At that moment, we measured the blood glucose and it was 7.0 mmol/L; however, we wish if we had it at 5.0 mmol/L. So to calculate the bolus, we plug those values into the above equation and that will lead to a bolus dose of 0.70 units as below:
Now you can imagine doing this calculation every time the patient needs to eat something! Things become more complicated when you know that those ICF and CF usually have different values for different times of the day, e.g. ICF might be 20.0 for the breakfast but 15.0 for the lunch! This why being equipped with an insulin pump that has a bolus calculator within it along with a CGM (continuous glucose monitoring) can save a lot of hassle.
We can compare the situation in which we do not have smart devices and the situation of having them. In the table below, I summarize the steps/activities that we must go through if we "decide" to have a meal. I describe how we perform each step in both situation.
Yes, so far that looks satisfactory and smart, and the table above gives a fairly positive picture of how the CGM and the insulin pump smartly lift a huge burden off our shoulders. However, to ensure an effective and tight control over blood sugar, we must optimally design the the basal program and the bolus factors. We have already mentioned that those factors can have a wide range of settings, not only at the factor value dimension but also the time and the activity dimensions. In other words, those factors have different optimal values during the day and based on the activity and many other conditions. I envision that to look like the plot below which this leads to unlimited number of values.
Normally, the optimal values of the factors are set following some rules and learning from experience. As still there is a substantial portion of the setting procedure done empirically, I take this as a strong motivation to leverage machine learning to at least give some insights. My motivation is also supported by the fact that those devices register considerable amount of data to learn from.
In the next post, I try to formulate the problem in the terminology of data science and machine learning context and discuss the data extraction and transformation.