PRE2016 3 Groep8
- 0957735 Ainse Kokkelmans
- 0895428 Joris Veens
- 0955135 Jolien van der Thiel
- 0957168 Joris Verhagen
- 0960769 Ineke Kil
- 0959019 Bjorn van Rixtel
More than 1.2 million people in the Netherlands have diabetes. That is about one out of every fourteen people and everyday about 169 people are newly diagnosed.  Although it is treatable with medicines or insulin, it is a chronically disease you are confronted with everyday. Depending on the type of diabetes, people have to insert insulin three times a day, around every meal. A diabetes patient always has to keep track of the number of grams of carbohydrates that have been consumed. On the basis of a formula, it can be calculated how much insulin is needed to keep ones blood sugar level on healthy terms. However, this is a standard formula for everyone and throughout your own life it also differs how much extra insulin is needed for every gram of carbohydrates. This formula should actually differ for every person and change from time to time. It is also quite some work to always keep track of the food or carbohydrates you have eaten, especially for a plate full of hot steaming food...
Our goal is to optimize the formula which calculates the amount of insulin a person with diabetes needs. The optimization will be tested by a diabetes application (web-app) which we will make ourselves. Our concept idea can be visualized in the figure below. We want to create an all-in-one user-friendly diabetes application which enables a patient to get a right personalized dose of insulin in an easy way. Instead of monitoring a patient all day long, we want to develop an algorithm that is based on and learns from the feedback it gets.
Because of most people have a kind of a fixed day rhythm, an algorithm could recognize this after some time and adapt to this. The adaption is based on the feedback that the software will get. This is the glucose level of the blood, after a period when insulin was injected. The glucose values always have to be in a certain range. And by coupling the data from the amount of insulin injected and the glucose level afterwards, the algorithm could learn to “know” somebody, because not everyone reacts the same on a certain amount of injected insulin. By receiving feedback over a longer period, the algorithm learns to recognize someone’s behavior too. Because of most people have a weekly fixed day schedule and for instance mostly sport on Monday, the algorithm could learn by making use of the feedback it will always need to give more insulin on Monday.
At the start of using the application you have to fill in what you have eaten on a day and your blood glucose level for a longer period. From this information the algorithm learns what your blood glucose level will be depending only on what you have eaten on a day. This information will be used to let the user know how much insulin must be inserted.
This piece of artificial intelligent learning software, has the possibility to be for instance implemented in an insulin pump, which is something a patient definitely has to wear all the time. Because of the fact that the algorithm learns to know it’s patient by receiving feedback in the form of training data it will calculate a personalized and therefore better and healthier dose of insulin that has to be given by the pump. The only thing the user has to do is measure it’s glucose level and eventually indicate a deviate day.
Additionally, the input of what you have eaten should be simple. This can be done with text. The program also remembers what you often eat at a certain time of the day, so if you want to fill in what you have eaten you receive suggestions of specific meals or snacks.
As extra help the application could be linked to a kitchen scale with Bluetooth. If you scoop up dinner on your plate while it is on the scale the application immediately knows how much grams of a certain kind of food you are going to eat. What the food that the user is weighing is, can be selected on the smartphone application. But since our main goal is the optimization of the formula, with the application only as a test tool, we will not look further into this.
To test the developed software we’ll make a web-app and “train” it with the year data of one of our group members. For us it is not possible to implement this for instance in a real insulin pump, but by making the app, we could have I look if it works or not. Furthermore we could investigate more in opportunities and possibility’s the implement our solution in real live existing and user friendly systems.
Most common current solutions
Most patients today use the manual calculation method for determining the necessary insulin dose. This is a time-consuming and, mainly in the beginning, a complex process, since 40-50% of the total daily insuline dose is to replace insulin overnight, when you are faston or between meals and the other 50-60% is for carbohydrate coverage and high blood sugar. 
Many of the diabetes patients find this process less than ideal. The weight and the amount of carbohydrates per certain amount of all the foods that the patient is going to eat needs to be known to calculate an insulin dose. There are, however, apps that take away some of the calculations from the patient. These apps will be explained in 'State of the art'.
Two existing technologies to ease the insulin dose calculations are apps and insulin pumps. These technologies will be explained in this chapter.
Current insulin calculating apps work on simple calculations. In general, the user enters their current blood sugar level and the amount of carbohydrates that the user is going to consume. The app will calculate the necessary dose of insulin for the user. Almost every application has the feature of saving the calculated insulin dose to a log. This log is able to provide insight over the user's glucose level throughout the day . The app which is regarded by its users as the most useful on AppCrawlr, is the $1.99 Glucose Companion app. Since this is regarded as most useful, it can also be regarded as state-of-the-art concerning diabetes applications. The special feature that this app offers is that it can keep a better track on the glucose levels and insulin doses and that it gives advice on certain diet options 
An insulin pump, which is shown on the image below, is connected to the patient by a cathether placed under the skin. When the pump is connected, the patient can receive short-acting insulin. The patient can increase the dose with buttons on the pump itself. This is to compensate the carbohydrates from a meal. The pump can also treat high blood glucose levels by taking a bolus. This is also determined by the patient him- or herself. It is important to note that the pump does not automatically correct the dose for everthing that the patient undergoes (such as meals and activities). The dose calculation is still done by the patient itself. The insulin pump has some advantages and disadvantages with respect to normally getting your insulin. These are stated below:
The website from the American Diabetus Society gives multiple advantages . The main one is that the patient does not have to bother with individual insulin injections which can really interfere with the patients life. Other advantages are:
- Insulin pumps deliver insulin more accurately than injections do.
- Insulin pumps result in fewer large swings in your blood glucose level since the doses are applied in a constant way.
- Insulin pumps allows the patient to be flexible about when and what he or she eats since the insulin pump directly corrects the insulin level in the body.
- Insulin pumps allows the patient to excercise without having to eat large amounts of carbohydrates.
The insulin pump does come with some disadvantages however. These are also given by the American Diabetus Society .
- Insulin pumps can cause weight gain to the patient.
- Insulin pumps can be expensive (and certainly are when they are not included in the patient's insurance).
- The insulin pump is connected to the patient most of the time. This can be bothersome.
In short, although the insulin pump solves some of the problems for the patient, it does not solve the biggest one which is manually increasing the insulin dose.
State of the Art
Artificial Intelligence Systems in Diabetes
Currently the most known AI approach in diabetes is the approach from PEPPER  (patient empowerment through predictive personalized decision support). PEPPER is a newly launched three-year research project, funded by the EU Horizon 2020 Framework. It’s goal is to create a portable personalized decision support system to empower individuals on insulin therapy to self-manage their condition. PEPPER employs CaseBased Reasoning to advise about insulin bolus doses, drawing on various sources of physiological, lifestyle, environmental and social data. It also uses a Model-Based Reasoning approach to maximise users’ safety.
Case-Based Reasoning (CBR) is a consolidated artificial intelligence technique, extensively applied in medicine, that tries to solve newly encountered problems by applying solutions learned from similar problems encountered in the past.
The system will be integrated with an unobtrusive insulin patch pump and has a patient-centric development approach in order to improve patient self-efficacy and adherence to treatment.
In the figure below, two architectures can be seen. These methods principally don’t differ quite much. In a nut shell, the PEPPER systems provide a portable personalised decision support system for insulin dosing that combines data from multiple sources such as body-worn sensors and manual inputs. These body-worn sensors for instance are the activity monitors that can be seen in the picture above. The manual inputs are given to the system by making use of a phone or handheld and consist of personal inputs like for instance the time someone sported, the amount and kind of food someone ate or the whether or not consumption of alcohol. The CaseBased Reasoning module is designed to provide a personalised insulin dose which adapts over time.
Another, similar apprach of AI in diabetes is the METABO  approach. The METABO approach is a diabetes monitoring and management system which aims at recording and interpreting patient's context, as well as, at providing decision support to both the patient and the doctor. The METABO system consists of (a) a Patient's Mobile Device (PMD), (b) different types of unobtrusive biosensors, (c) a Central Subsystem (CS) located remotely at the hospital and (d) the Control Panel (CP) from which physicians can follow-up their patients and gain also access to the CS. METABO provides a multi-parametric monitoring system which facilitates the efficient and systematic recording of dietary, physical activity, medication and medical information (continuous and discontinuous glucose measurements).
Based on all recorded contextual information, data mining schemes that run in the PMD are responsible to model patients' metabolism, predict hypo/hyper-glycaemic events, and provide the patient with short and long-term alerts. In addition, all past and recently-recorded data are analyzed to extract patterns of behavior, discover new knowledge and provide explanations to the physician through the CP. Advanced tools in the CP allow the physician to prescribe personalized treatment plans and frequently quantify patient's adherence to treatment.
Data Mining Techniques in Diabetes  
Data mining is the process of selecting, exploring, and modeling large amounts of data to discover unknown patterns or relationships useful to the data analyst. Medical data can be trained using data mining techniques to predict the diabetes. For this, dataset has to be preprocessed to remove noisy and fill the missing values. The management of diabetes is very well suited to a data mining approach, because of the availability of electronic health records and monitoring facilities a huge data sets are available for research. However, because diabetes is a lifelong disease, the available data for one individual may already be huge and very difficult to interpret.
Data mining are very useful techniques consists of a variety of methods like computer science approaches as multidimensional databases, machine learning, soft computing and data visualization and statistical-based methods, like hypothesis testing, clustering and regression. Data mining can be classified in two different “goal-tasks”. First of all this is description with the purpose to extract understandable patterns and associations from data. The second goal-task is prediction with the purpose to forecast one or more variables of interest, in the diabetes case this will be the blood glucose level.
The usual way to review the outcome of a certain therapy scheme starting from the analysis to the blood glucose is to check if someone shows a cyclostationary pattern. On other words, if someone shows a daily behavior that is almost the same over the monitoring time. The blood glucose pattern summarizes the patient’s own response to a certain amount of insulin. Mostly this is visualized by plotting the blood glucose data on a 24-hour scale or by computing the frequency histograms of the blood glucose measurements.
However, the problem is that a series of blood glucose data mostly isn’t cyclic or stationary. It’s has kind of a stochastic nature that leads to confusing data. Because of this a combination of signal processing and artificial intelligence is well suited. First of all a filtering approach, known as a structural analysis needs to be applied. Structural analysis decomposes a time series into a collection of signals with known “temporal structure”. This means that each blood glucose (BG) measurement can be expressed as a sum of separate components: a trend component (T), a cyclic component (C) and a stochastic component (E), for each measurement (i).
The problem of extracting Ti and Ci can be solved mathematically in different ways, including Kalman filtering, least-squares fitting, and Bayesian smoothing. By using the same technique it is possible to also separate daily cycles from weekly or monthly cycles, which may correspond to changes in the lifestyle during the weekend or through the year. Given the availability of trend and cyclic components, it is possible to pose some interesting clinical questions: (1) is there a trend in BG data, (2) Is there one or more cyclic behavior in BG data? Even more interestingly, it is possible to combine trend and cycle information with the absolute value of BG?
Following a data mining approach, a way to answer these questions is to apply an artificial intelligence technique known as temporal abstractions (TAs). The principle of TAs is to provide an interval-based representation of monitoring data: time-stamped data are processed into time intervals during which a certain event occurs. In the case of the blood glucose monitoring it’s a useful to apply three different kinds of TAs: state TAs (high / low value), trends TAs (increasing or decreasing) and complex TAs (daily patterns). The application of TA methods can therefore be seen as a way to search for patterns in continuous monitoring data.
Since the treatment of diabetus is going on for a long time, a lot of new technologies were created for measuring the current blood sugar level of the patient and determining the necessary dose of insulin for the patient. These old and new techniques are summarised below:
Meauring the blood sugar level
- Blood sampling:
The most popular and easiest way of measuring the current blood sugar level of a patient is using a lancet. With this device, which is shown below, the patient can prick the scin to draw a small sample of blood which will be analysed by a blood glucose monitor or blood glucose test strips. In many cases, the blood glucose monitor and the lancet is one device. The blood which is sampled from the patient is directly monitored to determine the blood sugar level.
- Artificial pancreas:
An artificial pancreas is supposed to automatically control the blood glucose level of the patient. It does this by replicating the endocrine functionality of a healthy pancreas since this system is generally not working properly for diabetes patients which is the reason why patients need the insulin doses. The artificial pancreas is implemented on the skin and, together with an insulin pump, gives an insulin dosage to the patient. There are different approaches to the "Artificial pancreas" such as the "medical equipment approach" (determining insulin dosage via closed loop control data from a continious blood glucose sensor), the "bioengineering approach" (creating a biological correct pancreas from real cells which is implemented under the skin of the patient), and the "gene therapy approach" (giving the patient a genetically changed virus which causes cells to become insulin-producing cells. In this project, the artificial pancreas is seen with the "medical equipment approach" in mind. This fits our approach to this project the best.
Determining the insulin dose
Once the glucose level is determined using one of the mentioned methods above, the patient needs to determine the insulin dose. This can be done in multiple ways as well. The most common ones are explained below:
- Manually calculating:
Manually calculating is perhaps the oldest and most common method of determining the correct insulin dose. To calculate the insulin dose, the patient needs several known variables. These are the 'blood glucose level' which can be measured and (often) displayed by the lancet, the 'target blood glucose level' which is below the measured blood glucose level, the 'carbohydrate intake' which is the amount of carbohydrates that the patient is going to eat in the upcoming meal (for which he is injecting insulin), the 'carb-to-insulin ratio' which is personalised and gives the amount of grams that are covered by one dose of insulin for the patient, and a 'correction factor' (also called the 'insulin sensitivity') which gives how much the patients blood sugar level lowers with one dose of insulin. This factor is not unique to the patient since it is an estimate, but it is different from patient to patient. With this information, the patient can calculate the number of insulin units he or she has to take for covering eaten carbohydrates using the following formula:
Insulin doses = (amount of carbs in the food)/(carb-to-insulin ratio)
To calculate the amount of insulin doses for lowering the patients blood sugar level, the following formula can be used:
Insulin doses = (current BG - target BG)/(insulin sensitivity)
If a patient has a high blood sugar level and he or she needs to eat, the patient can combine the two formulea into one which calculates the total amount of doses needed:
Insulin doses = (amount of carbs in the food)/(carb-to-insulin ratio) + (current BG-target BG)/(insulin sensitivity)
- Using an application:
Modern cellphones and computers can often calculate the insulin dose for the patient using an application. These applications require the exact same inputs as mentioned in the "manually calculating" part. The formula used is then also exactly the same. This means that even though cellphones and computers have a lot more calculating power than the patient has, it does not use this in calculating the correct dose of insulin. What the application does add, in some cases, are some diet recommendation and a better way to keep track of the patients blood sugar level with the use of generated graphs from the data etc.
Test App for the software and formula
Purpose of the app
We have given ourselves the taks to implement the improved formula into an web-application. This will not only be done because web-apps (and mainly on a mobile phone) are easily accesible for most patients and always at hand but also because it is easy to show the process of calculating a desired dose. The app is thus not meant to be a finished product in any sort of way. It is not meant for sale or medical use but will show the usefulness of the improved calculating method.
There generally has to be done a lot of work to make a web-app as userfriendly as possible. This would be even more important in this project since people are going to receive medical information so mistakes are not allowed to happen. This does not apply to our web-app though, since it will only be used to show the workings of the improved calculating method.
The development, success and consequences of a technology have always been shaped by the coherence between the User, Society, and Enterprise aspects in engineering. The key to developing a good technological solution is to find one that complies with the individual needs and desires of these three actors. Therefore, it is essential to create a clear image of each of them, before working towards a technological solution to our problem.
Different User groups (that consists of those who use the technology) formulate different desires and demands for the functioning of the technology around their needs as consumers.
- Primary users
In our case, the specific primary users that we will target, is the group of patients known to have diabetes type 1. The reason we chose this user group specifically is because they will profit the most of the solution we will develop. This is because those with this diabetes type are the most dependent on a proper estimate of their needed insulin intake, since they are incapable of producing any on their own. Furthermore, we do not intend to exclude those with diabetes type 2. Yet, since they are less dependent on such a technological solution (they do produce insulin to some extent), our primary focus will remain on type 1 diabetes patients. Our ambition is to reach and help as many diabetes patients as possible.
We expect the primary user’s needs, that shape the desires and demands of the technological solution, to be centered around three main requirements: its usefulness, accuracy and user-friendliness. Next to that, we will look into some less direct, but not unimportant requirements as well, such as: protection of user privacy and build-in safety features (for example not displaying an advice when the user input is too unrealistic).
- Secondary users
The secondary user to which this technology will apply, are the primary user’s doctors and other medical staff (such as pharmacy personnel). This User group will be in indirect contact with the technology, yet their desires and needs are of importance too.
We expect the secondary user’s needs to be centered around two main requirements: the ability to check and/or influence the direct output to the primary user (as a safety measure and for feedback on advice improvement) and the ability to look into the total collected primary user’s data (for the doctor, in order to give a more accurate medical advice for example).
- Tertiary users
The tertiary user consists of those who will be producing and maintaining the system. They are the ones that will benefit by the profits they make from investing in this technology.
Needs that we expect to apply to them are: its easy maintainability and cleaning and a high marketable value.
The Societal aspect is formed around all societal problems surrounding our problem. In our case, the most predominant one is the reduced risk of heart disease, high blood pressure, strokes and pancreas malfunctions.
The societal benefit will mostly consist of lower costs in the healthcare industry by lowering the health risks of a large group of diabetes patients.
There are multiple enterprises that could profit from a technological solution to this problem. Developers and investers in this technology could make profit from selling it to the primary user.
Furthermore, it could also be of interest too some semi-government institutions such as "Het Voedingscentrum", which strives for a healthier lifestyle for all. Institutions such as “Het Voedingscentrum” and others that try provoking a healthy living could benefit from the research that can be done on the primary user’s collective data.
Ethics - Liability
Medical applications in the Netherlands
Medical applications have a continue growing contribution in the healthcare market. Many consumers in the Netherlands use applications like ‘Moet ik naar de dokter?’, ‘Huidmonitor’ and the ‘iP plaslijst’. Even 60% of the doctors in our country says to make use of medical apps. Although the goal of those applications is to improve the quality and efficiency of patient care, certain risks of misdiagnosing are attached to them. 
To avert such risks there is the CE marking in the European Economic Area (EEA). This marking is mandatory for applications that make a medical claim. It ensures that medical devices suffice the European requirements for safety, health, environmental and consumer protection. Without this mark a medical device is not allowed to be commercialized. However, the CE-marking should not be confused with a quality mark. It does not guarantee the quality or clinical relevance of the product. 
The use of not CE-marked medical products can have consequences for many parties. Developers and doctors can receives fines. Institutions will be addressed upon the base of the law for quality of healthcare institutions. When a patient suffers damage because of the use of a not CE-marked medical product (so also applications), it is a professional misconduct of the doctor. In that case, the product developers will also be liable. 
An example for our situation can be that because of a programming mistake, the algorithm in the applications gives consistently too high values. If someone with diabetes suffers from this because he or she administers wrong doses insulin, this can lead to a claim. 
Is our app a medical device?
Whether our idea for applications should have a CE-marking can be checked with the flowchart in figure 1.
Figure 1,  This will lead to the conclusion that the application for our goal definitely will be seen as a medical device. It does (not???) contain a measuring function??
Liability of the producer
As a starter the producer of the application is primarily responsible for it legitimate bringing to the market of the application. This means, among other things, taking care of the CE-marking as mentioned in the paragraph above.
Besides, on the basis of article 6:185 BW, the producer of a product is responsible for the damage caused by a malfunctioning product. However, the question rises whether a medical application can be viewed as a product. A product is defined as a moveable property, but a medical application does not have this required materiality. Assuming that the rules for product liability are applicable on a medical application, man can think of mistakes in the production process, design mistakes or instruction mistakes. For the successfully addressing of the producer on article 6:185 BW, it is the patients task to prove that the producer marketed a malfunctioning application and that the application caused harm. Although the burden of proof is with the patient, it is wisely for the producer to be very careful by making and maintaining of the software to limit it’s liability. 
Liability of the care giver (hulpverlener)
In most cases it is the caregiver who chooses which kind of medical device will be used. This makes the care giver responsible for it legitimate using of a medical device during the treatment. This includes the use of a medical device with CE-marking and the correct use of the medical device. A care giver is also liable when, according to objective standards for a reasonable acting care giver, he or she could and should have acted differently. Like situations in which the care giver gives insufficient explanation about an application that is used on his or her initiative, causing the incorrect use of the application leading to shows of incorrect results in the application. Additionally, it is the care givers responsibility to not unthinkingly take over diagnoses that the application gives, even if it carries the CE-mark. 
In the Gant Chart different colors can be seen: Deadlines are marked red, wiki related tasks are marked black, milestones are marked green and all the remaining tasks are marked grey.
The deadlines are in week 2, 3 and 8, these are the presentations. Almost every week a black box can be seen, the findings done in that week will there be placed on the wiki to make sure the wiki-page stays up-to-date. Important milestones are finishing the literature study in week 5, finishing the code for the optimization of the formula in week 6, finishing the app in week 6 and finishing the wiki and testing the app in week 7. A clearer week distribution is shown below.
- First meeting
- Brainstorming ideas
- Choose idea
- Problem definition
- Describing findings week 1 in wiki
- Presentation 1 [deadline]
- Making structured layout in wiki
- Redefinition of the idea after feedback
- State of the Art
- Task division
- Presentation 2 [deadline]
- Research in software “learning” techniques / starting with optimization of formula
- Research already available methods of measuring blood values etc.
- Describing findings week 2+3 in wiki
Week 4: - Research user friendly making of the app
- Optimization of formula
- Research new/new developed methods of measuring values etc.
- Describing findings week 4 in wiki
- Research in ethical data aspects
- Finishing literature study [milestone]
- Describing findings week 5 in wiki
- Code for optimization of formula [milestone]
- Making the App [milestone]
- Describing findings week 6 in wiki
- Testing of the App [milestone]
- Finish wiki [milestone]
- Preparing presentation
- Describing findings week 7 in wiki
- Final presentation and demonstration [deadline]
 ‘Medische apps, is certificeren nodig?’, Nictiz, 7-06-2013, Anton Ekker and Barbara van Rest.https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/13005%20Whitepaper%20medische%20apps.pdf
‘Civiele aansprakelijkheid voor het gebruik van medische applicaties’, Tijdschrift voor Gezondheidsrecht, 27-10-2016, Mr. A.J. Zijlstra. http://www.sectionz.nl/cms/LAUXTERMANNADVOCATEN/media/pdf/TvGR_2016_40_07_schoon-zijlstra.pdf