Hacked Raspberry Pi turned into artificial pancreas(businessinsider.com)
businessinsider.com
Hacked Raspberry Pi turned into artificial pancreas
http://www.businessinsider.com/hacked-raspberry-pi-artificial-pancreas-2015-8
13 comments
The github repo https://github.com/openaps/openaps includes a description of some of the things the project can do. One of them is "predict - Can make predictions about what should happen next."
All diabetics ever have is a rear facing indicator, fortunately it's not really true that you can't predict the future when it comes to blood glucose. The simple equation is `exercise + carbs + current blood glucose level + insulin on board` along with all the attributes that make your body respond to artificial insulin the way it will. The system doesn't really need to predict the future to be a massive improvement on where diabetics already are thanks to slow moving organizations like the FDA. With appropriately cautious buffers around when to shut the insulin pump off a huge majority of diabetics will rarely see a low blood sugar. The technology is here, we just have to summon up the will to move medicine forward.
All diabetics ever have is a rear facing indicator, fortunately it's not really true that you can't predict the future when it comes to blood glucose. The simple equation is `exercise + carbs + current blood glucose level + insulin on board` along with all the attributes that make your body respond to artificial insulin the way it will. The system doesn't really need to predict the future to be a massive improvement on where diabetics already are thanks to slow moving organizations like the FDA. With appropriately cautious buffers around when to shut the insulin pump off a huge majority of diabetics will rarely see a low blood sugar. The technology is here, we just have to summon up the will to move medicine forward.
Are there systems feeding sugar in such an event? That would be the only thing really preventing a - possibly lethal - hypoglemic event, no?
Preventing these situations entirely by predicting these events and reducing the administered basal insulin would be ideal, but humans don't exist in a vacuum. I don't think a system autonomously feeding sugar would be the optimal solution however; patients who utilize CGM's today are still instructed to monitor blood glucose through traditional means for calibration and confidence in system accuracy, so I don't think it would be an additional burden for them to continue to carry a source of sugar for emergency hypoglycemic events. I think predicting and preventing lows through lowered basal rates, in combination with on hand sources of glucose for emergency situations, would be best.
Even a reduction in the amount of hypo- (and, hyper-) glycemic events would be a big win for patients and educators. I think the quality of care would vastly increase with such systems in place.
Additionally - the human body has systems in place to bring blood sugars back into a safe range when it feels it is in an emergency situation. I do not claim to be an expert on this matter, but it is my understanding that the liver is able to release glycogen into the system to spike blood glucose levels back up if they have fallen low [1]. This is why some diabetic patients may experience high blood sugars in the mornings if they have experienced a hypoglycemic event overnight and slept through it. I don't believe this would be a good solution to depend on, however.
[1]http://www.diabetes.co.uk/body/liver-and-blood-glucose-level...
Even a reduction in the amount of hypo- (and, hyper-) glycemic events would be a big win for patients and educators. I think the quality of care would vastly increase with such systems in place.
Additionally - the human body has systems in place to bring blood sugars back into a safe range when it feels it is in an emergency situation. I do not claim to be an expert on this matter, but it is my understanding that the liver is able to release glycogen into the system to spike blood glucose levels back up if they have fallen low [1]. This is why some diabetic patients may experience high blood sugars in the mornings if they have experienced a hypoglycemic event overnight and slept through it. I don't believe this would be a good solution to depend on, however.
[1]http://www.diabetes.co.uk/body/liver-and-blood-glucose-level...
I've had type 1 diabetes for 9 years. In the first 3-4 years my liver continued to produce glucagon. I experienced highs resulting from the down syndrome over night. But after that it just stopped.
Now I automatically wake up if my blood sugar is below a certain threshold. It's a survival instinct. Sometimes though it gets very scary. I can't scream, know that I need to get up and eat something, but I just can't.
The downside is that I am very paranoid. I wake up at least once a week at night (around 3 am) and check my blood sugar levels. Even though they are usually in the expected range, I still get that feeling of 'being low'. If I don't act on it, I might die.
While I am a big fan of DIY bio, my experience with Raspberry Pis is that they are highly prone to failure. Becoming dependent on a device- that is, expecting it to work with close to 100% reliability- and then using a device that is easy to disable and prone to failure (I run a fleet of Pis and they mangle their SD cards a lot)- seems like wishful thinking.
It may work 95% of the time, but that's not good enough. There's a reason really good medical devices are based on simpler platforms that are more robust.
It may work 95% of the time, but that's not good enough. There's a reason really good medical devices are based on simpler platforms that are more robust.
I'll just leave this here:
http://www.bunniestudios.com/blog/?tag=mediatek
I agree, this is a job more suited to a simple 8 or 16-bit micro without any OS.
These days you may as well use a 32bit micro, in terms of cost, toolchain and silicon ability.
The extra dollar you spend on those 16bits easily pays for itself in the extra features you often get with modern 32bit micros.
Especially something like this where you might want to do relatively complex maths / algorithms.
e.g. see the stm32 family
The extra dollar you spend on those 16bits easily pays for itself in the extra features you often get with modern 32bit micros.
Especially something like this where you might want to do relatively complex maths / algorithms.
e.g. see the stm32 family
At the same time, this is a really cool hobby project that someone interested in a future developing medical devices could try to replicate as they are learning.
I sure hope not.
This is an interesting personal project, but it is far from how medical devices should be (and are) developed. Where is the risk analysis, for example? Or the FMEA? Was the software developed under ISO 62304? Etc.
There's a lot of activity that happens in a regulated industry that is completely missing here, which is why I see this as a poor example.
This is an interesting personal project, but it is far from how medical devices should be (and are) developed. Where is the risk analysis, for example? Or the FMEA? Was the software developed under ISO 62304? Etc.
There's a lot of activity that happens in a regulated industry that is completely missing here, which is why I see this as a poor example.
Absolutely! The Pi is very valuable for exactly that. It's just that dosing yourself is a very serious matter, not a hobby.
I've had some mixed success with Raspberry Pi's spontaneously failing as well. This is perfect opportunity for a dual or triple redundancy lockstep MCU to take the place of the Raspberry Pi.
I had enough problems running one that was hooked up to the wall, running it on batteries just increases the chances of an SD card/file system failure.
They could make the thing a lot more fault tolerant if they set up its fstab to mount the file system read only, and run in memory.
They could make the thing a lot more fault tolerant if they set up its fstab to mount the file system read only, and run in memory.
Calling a glucose monitoring system with an insulin pump an artificial pancreas is a bit misleading, considering all the other functions the pancreas has.
This also isn't an artificial pancreas because you still have to wear an insulin pump and insulin pumps aren't artificial pancreases. To me, an artificial pancreas acts like the pancreas I already have - it monitors and excretes insulin so I never have to think about what my blood sugar is or think about it dropping low or spiking.
What are the other functions?
https://en.wikipedia.org/wiki/Pancreas#Function
"It is possible for one to live without a pancreas, provided that the person takes insulin for proper regulation of blood glucose concentration and pancreatic enzyme supplements to aid digestion."
"It is possible for one to live without a pancreas, provided that the person takes insulin for proper regulation of blood glucose concentration and pancreatic enzyme supplements to aid digestion."
Interesting. I've always wondered why we don't simply remove the entire pancreas for cases of pancreatic cancer?
Because there is no clinical evidence for the survival benefit of total pancreatectomy over a Whipple.
There's absolutely nothing simple about surgery when the pancreas is involved.
There's absolutely nothing simple about surgery when the pancreas is involved.
Do you have a citation for that? I'd be curious to read more.
Intiutively it sounds wrong since I'd image any cancer that comes back after the whipple is coming from left over cancer cells in the pancreas, no?
Intiutively it sounds wrong since I'd image any cancer that comes back after the whipple is coming from left over cancer cells in the pancreas, no?
It's saddening that a possibly avoidable organ leads to the most "lethal" cancer.
I got a glimpse into this when I talked to someone who was following the nightscout program for their child.
http://www.nightscout.info/
They were non-technical people. Yet they had an android phone connected to a medical device using a 3d printed bracket and short usb cable. The android phone was reporting to a windows azure instance. Pebble watch polling the azure instance for updated levels.
The sysadmin in me recoiled at the myriad operational deficiencies and potential failure modes. Yet they don't have a better option. I get that the FDA has standards it has to apply, but I imagine that many things they would reject would still be vastly better than this. Is there a term for 'the risks people will take anyway rather than wait for something perfectly safe'. Like if you make wait times at crosswalks too long will more people get killed crossing the street?
http://www.nightscout.info/
They were non-technical people. Yet they had an android phone connected to a medical device using a 3d printed bracket and short usb cable. The android phone was reporting to a windows azure instance. Pebble watch polling the azure instance for updated levels.
The sysadmin in me recoiled at the myriad operational deficiencies and potential failure modes. Yet they don't have a better option. I get that the FDA has standards it has to apply, but I imagine that many things they would reject would still be vastly better than this. Is there a term for 'the risks people will take anyway rather than wait for something perfectly safe'. Like if you make wait times at crosswalks too long will more people get killed crossing the street?
I've thought of this but am too worried a floating point number error or a problem with division could cause an automated fatal dose of insulin to actually do it.
Thus the comment in the article about a programmed maximum.
This is why I come here.
... all I have to say is... I LOVE SCIENCE!
I've had type 1 diabetes since I was 10. With even a semi-automated solution we would greatly prevent the short and long term complications. The biggest issue is that brain runs on glucose. When we can't manage our levels, the brain shuts down. In order to prevent this we grow up paranoid, watching for every sign. Stress, faulty needles etc. all effect us.
Knowing that we can theoretically prevent nerve damage (almost every person with 10+ years diabetes gets it) and other serious conditions (kidney failure, blindness) and practically not being able to do anything is very depressing.
It amazes me that technology to do this isn't already mainstream and ubiquitous.
It doesn't amaze me, the FDA and organisations like it are brilliant (without them the world would be a worse place) but they do put a retard on a lot of the cool stuff by demanding exhaustive testing (which in fairness I can't disagree with, medical stuff isn't a website where you can just patch it later - people will die).
It's not a perfect system though as substandard stuff does get through and the barriers to effective entry are so high that only the big well funded companies can afford access - not really sure what you can do about that.
It's not a perfect system though as substandard stuff does get through and the barriers to effective entry are so high that only the big well funded companies can afford access - not really sure what you can do about that.
I think you're supposed to call them mentally handicapped.
I must be unaware of the other meaning of the noun "retard".
As an alternative in this case, I might suggest, "brake".
As an alternative in this case, I might suggest, "brake".
Not really, it was the correct word appropriately used.
> Retard - delay or hold back in terms of progress or development.
> Retard - delay or hold back in terms of progress or development.
Yes, and that's "retard", the verb. A totally different word! (Maybe it depends on dialect, but as I've always heard it spoken, it doesn't even sound the same.)
"They do put a retard" - here, the word "retard" is used in a noun position. Therefore, it is a noun. Therefore, it must refer (and with an implication of cruel disaparagement) to somebody who is mentally handicapped.
I wonder if they use the same person each time?
"They do put a retard" - here, the word "retard" is used in a noun position. Therefore, it is a noun. Therefore, it must refer (and with an implication of cruel disaparagement) to somebody who is mentally handicapped.
I wonder if they use the same person each time?
What makes it a "hacked" Raspberry Pi? Or is everything with a few cables soldered to it "hacked"?
Hacking as a term doesn't mean much anymore beyond a weak social identifier. The startup scene calls marketing "growth hacking" these days ffs.
How much liability does a company open itself up to if they make their medical devices hackable? It's a travesty that these people had to rely on an unpatched vulnerability to make a device that would save people's lives.
I wonder why the medical industry doesn't do this, combining an insulin pump and a constant glucose monitor into a single system?
Liability. Clinical decisions are made by humans.
Sad thing is, although the software controlling this would undoubtedly have lots of flaws and cause suffering and death, not implementing something also allows people to suffer and die.
Sad thing is, although the software controlling this would undoubtedly have lots of flaws and cause suffering and death, not implementing something also allows people to suffer and die.
I'm sure this bias has a name? The idea that changing the outcomes for the better is actually worse because different people are affected. Or maybe because in one we are dying of a disease, and in the other one by software errors. Software errors should be avoidable, so they feel worse than disease somehow.
Think about it this way. Imagine there's a hypothetical medical device X. It has been calculated, that due to operator errors, this machine on average kills 1/1000 patients. Operators are given more training,but the average does not change.
Now. Another company makes an automated machine, which kills 1/10000 patients on average, because of software errors. Do you think anyone would ever allow the second machine to be sold, even though it would save 9 persons compared to the manually operated machine? Of course not. If it ever came to light that it killed anyone due to a software error, it would be gone faster from the market than you can spell "liability". Does not matter that in fact it's killing less people on average than any other type of machine - it's just that in our minds software bugs are avoidable so therefore they are not acceptable at all.
Now. Another company makes an automated machine, which kills 1/10000 patients on average, because of software errors. Do you think anyone would ever allow the second machine to be sold, even though it would save 9 persons compared to the manually operated machine? Of course not. If it ever came to light that it killed anyone due to a software error, it would be gone faster from the market than you can spell "liability". Does not matter that in fact it's killing less people on average than any other type of machine - it's just that in our minds software bugs are avoidable so therefore they are not acceptable at all.
> Liability. Clinical decisions are made by humans.
Pacemakers have a high risk, yet here we have an automated solution. I think liability alone cannot be the root cause.
Pacemakers have a high risk, yet here we have an automated solution. I think liability alone cannot be the root cause.
The regulatory approval pathway for a combination drug/device platform, with a automatic clinical decision component, is a nightmare.
Assume one did create the device, and got it to work across a wide patient population with varying diets, disease severity, treatment responsivity, etc., and then (somehow) got approval for it. Existing insulin pumps are already challenging to get reimbursed under insurance, and they have a more straightforward regulatory approval path with lower R&D costs. The super pump would need to be reimbursed for quite a bit more money to justify the increased R&D costs. That is going to be a very hard sell under quality of life improvement alone—clinical data showing an improved patient outcome or decreased long-term healthcare costs is what is needed. You're benchmarking against existing pumps with separate monitors, which sets a high bar.
Assume one did create the device, and got it to work across a wide patient population with varying diets, disease severity, treatment responsivity, etc., and then (somehow) got approval for it. Existing insulin pumps are already challenging to get reimbursed under insurance, and they have a more straightforward regulatory approval path with lower R&D costs. The super pump would need to be reimbursed for quite a bit more money to justify the increased R&D costs. That is going to be a very hard sell under quality of life improvement alone—clinical data showing an improved patient outcome or decreased long-term healthcare costs is what is needed. You're benchmarking against existing pumps with separate monitors, which sets a high bar.
[deleted]
New pumps by Medtronic are equipped with an auto-off feature that suspends insulin delivery if the user's blood sugar is below a certain threshold [1], however this is a rear-facing indicator and the patient will still experience a hypoglycemic event.
I assume the next logical steps towards making these systems fully autonomous is to remove the idealogical separation of basal and bolus insulin; instead, the system would register increases and decreases of blood sugar and take systematic steps towards bringing them back into a healthy range - much like a healthy pancreas does, either by increasing or decreasing the amount of insulin being delivered at a given time. That way a patient can eat, exercise, and live a "normal" lifestyle while the pump takes care of delivering the correct amount of insulin.
[1] http://www.medtronicdiabetes.com/products/minimed-530g-diabe...