It is pretty unusual to be reading Bloomberg Businessweek and see an article with the main picture featuring a purple PCB (the picture above, in fact). But that’s just what we saw this morning. The story is about an open source modification to an insulin pump known as the RileyLink. This takes advantage of older Medtronic brand insulin pumps and allows you to control the BLE device from a smartphone remotely and use more sophisticated software to control blood sugar levels.
Of course, the FDA isn’t involved. If they were, the electronics would cost $7,000 instead of $250 — although, in fairness, that $250 doesn’t cover the cost of the used pump. Why it has to be a used pump is a rather interesting story. The only reason the RileyLink is possible is due to a security flaw and an active hacker community.
Features Built on a Security Hole
In 2011 Medtronic, a major manufacturer of insulin pumps. was told by security researchers that their wireless link was insecure. Future devices closed that security hole, but the existing devices were never upgraded. This left thousands of pumps in circulation.
Although the researchers were worried about the malicious use of the security hole, [Ben West], a programmer with diabetes, started a five-year reverse engineering effort to understand the communication protocol. A group of hackers also figured out how to relay glucose monitoring data to remote smartphones. By 2014 [West] met a couple who had a workable insulin dosing algorithm and the automatic pancreas was born.
It is a great story and a great example of what hackers can do to change lives for the better when they work together. To their credit, though, Medtronic seems to be willing to work with the hackers and exchange ideas. You have to wonder, though.
How Can Open Source Medical Device Add-Ons Become Widespread?
It sounds like RileyLink has been a great success and we’re glad. It’s built on an a device which previously won FDA approval, but depends on what is essentially a design flaw. You can imagine the FDA would not be pleased (although not all of the users are in the US). If something did go wrong, what would happen then? If something bad happened on this or a similar project, there would be a feeding frenzy in the courtrooms as well as the court of public opinion. And how do you differentiate a sensible project like this from someone scamming people with a miracle cure add-on?
You can argue that the pump is an existing approved device. However, the FDA would — if this were a commercial product — regulate the software and data collection just as closely. In fact, there’s at least one start-up company aiming to put a lot of the software side of medical devices in the cloud to help cut the cost of FDA approval. Getting well-designed open source devices into the hands of those that need them (not just those who have the know-how to build and install them) is the next step and solving the regulation path and safety protocols are the biggest obstacles.
The need for insulin monitoring and dosing has attracted quite a bit of homebrew interest and we’ve seen artificial pancreas projects pop up before. OpenAPS, for example, uses approved medical devices just like RileyLink. If you want more details about life with an artificial pancreas, [Dan Maloney] has first-hand experience managing his daughter’s. Where there’s a need and interest from patients, parents, hardware engineers, and industry, there must be a way to bring everyone together to the benefit of all.
It’s all fine and dandy until someone with SDR decide to have fun with yours already non-functioning thyroid gland.
Um….the artificial PANCREAS should have been your first clue.
Thyroid? I thought it was about the pancreas?
there is correlation
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3139205/
mess someone body not instantly, to avoid immediate detection
Okay, I’ll buy that!
All that currently needs to be done to put a spanner in the works for most of the cheaper SDR hardware with TX capability is to make the timing on all handshakes take less time than the USB bus latency. e.g. USB 3.0 has an average latency of 30 μs (one way).
But non-SDR devices that do the handshake in hardware could still work e.g. Ubertooth one and YARD Stick One. But they would not function of you choose a frequency or protocols that they do not support in hardware.
It is one of the reasons that you do not see SDR WiFi NIC’s ( https://en.wikipedia.org/wiki/Short_Interframe_Space )
This is why we can’t have nice things.
Joking aside, if the companies that make the medical devices got together with the people working on open source extensions of those devices it should be possible to add an auth system that would validate the data.
While using the “security hole” does it also prevent others from exploiting the same?
The “security hole” requires knowledge of the pump’s serial number (which, IIRC, is not broadcast by the device, but I am a bit rusty as it has been a while) in order to pair a new control device.
I’m a bit rusty, but this particular security hole was overblown. Later devices have had remote bolus using stronger pairing mechanisms, but strangely not remote basal (which is far safer).
In short, it’s a “security hole” that can only be abused by someone who gains physical access to your pump in the first place.
Also, I’m annoyed at Medtronic – instead of a simple enhancement to the pairing system (require physical confirmation on the pump before allowing a remote device to pair), they just ripped out the feature. Can’t have people integrating a CGM superior to theirs (Dexcom) with their pump, can we?
INAL but it may be the case that removing the feature doesn’t require re-certification where as adding a feature may. FDA certification is not a trivial minefield to navigate.
Hey Al, thanks for noticing my tip and getting this article out to the community so quickly !! You rock!!
So, when this firmware hangs and injects an excessive dosage of insulin into someone killing him, who takes responsibility?
Well that was kind of my point. When someone has a problem from something like this everyone is going to want to sue someone. We were talking about that on the old radio tear down that had 600V on the back panel. In those days people thought “Well if you are dumb enough to touch the 600V, that’s what happens to you.” Now it is “Why didn’t someone stop you from touching the 600V?”
The open source controller software (Loop or OpenAPS) isn’t directly controlling the dosing: it’s just issuing instructions to the pump, which is well designed to fail safely. You can read more about the safety principles behind all of these DIY closed loop systems at OpenAPS.org, but the short version is: the pump can be and is configured to prevent the controller from doing anything acutely dangerous. And people with type 1 diabetes already have lots of redundant safety processes in place to deal with everyday bad blood sugars, so it’s easy to detect any less severe malfunctions before they require you to take more corrective action than “eat a cookie or drink some juice”.
Even if absolutely everything went wrong, the apps monitoring CGM readings would alert you to an impending low, and tell you how much iob you had, and a guess at the carbs needed to correct
“…However, the FDA would — if this were a commercial product — regulate the software and data collection just as closely.” Exactly. Even a minor code change can reqiure recertification that involves extensive (and expensive) testing. Anyone who’s been writing commercial (not life critical) software for any length of time has had the experience of spending hours or even days tracking down an obscure difficult-to-reproduce bug reported by a user. The amount of testing required to certify that a piece of software is virtually free of significant bugs is economically unfeasible in most industries. We’d still be running text-based applications on VT-100s if all software were held to that standard. But for life critical software, lives trump economics (at least to some extent). Yay open source and reduced costs as long as you also introduce a transparent, verifiable, open source certification process. The goal is to cut costs not lives.
I know a good thing that needs to be hacked BADLY. “Bone stimulators”. I broke my foot a few weeks back and before I actually got to see the orthopedist I was reading up and read that I might have to use a bone stimulator. Come to find out these things cost anywhere from $1500-$6000 and they only work a MAXIMUM of 270 days AND they can only be used once a day AND if the transducer comes loose from your skin, it’ll shut down that treatment for the day(and that apparently happens a lot). There’s not a whole lot keeping someone from hacking them as many apparently have a JTAG. Some people have managed to reset them a little bit by replacing the internal button cell battery but they still continue the 270 day countdown.
If anyone wants to get into this, I’d be down with it because I’d like to see them a lot easier and cheaper. I ended up not needing one but I recognize the need..
Interesting. I think TENS/EMS units used to be like this, but not quite as cumbersome or strict… But they’d lock themselves down and brick after X number of days. Now, they’re available OTC at Walgreens.
My dad had a TENS unit back in the mid/late 80s and the only limitation I remember it having was that you had to have a prescription to get one.
Had to actually look up “bone stimulators” as I’d never heard of them. After reading I’m still not convinced they’re actually all that effective. With pricing like that it certainly has a wiff of snake oil
I thought the same thing but apparently they’re legit.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2762251/
This sounds like a great way to wake up dead. There is a reason that the commercial products cost what they do. I am not questioning that profit is a piece of it, but also all of the devices are medical device rated and the designs are tested and reviewed much more rigorously than you could do at home. Open source is fine for things when they fail don’t turn your lights on or off, or you can’t tell how cold your fridge is from across the country. If there are a few speed bumps in getting a nice working project it is no big deal. I can see this leaving a string of dead bodies.
My son has used both Riley (Loop) and Open APS, and you are at far greater risk from a fat finger or middle of the night mistake on manual bolus entry, or Kids who sneak candy, or non-compliance with regimen. Both systems are pretty much incapable of doing anything unless the human in the loop makes the mistake. For the most part, they just modulate the basal rate, and are conservative in the extreme with regards to stacking insulin. They are making calculations based on the absorption curve, and are looking out 3-5 hours when making these calculations. And there is a max value hard coded into the software that mitigates most of the risk.
Also, you pretty much have to be a moderately competent software person to get either solution stood up. I now have an apple developer license that I’d never have touched with a 10 foot pole if it weren’t required to build the loop app.
These systems do give parents of pediatric T1D back some sanity, as they will suspend basal (continual non-carb based insulin requirement) in the case of a predicted low. This has almost certainly saved lives overnight. Only Loop allows bolusing for food from the app, and the human is the weak link in the system, again.
There is an upcoming code roll coming to Tslim pumps that will incorporate basal low suspend based on predicted low BG. Additionally, sometime in the next year, there will be full artificial pancreas in a commercial pump, including basal adjustments, so this is just a few years ahead of FDA approved solutions. Also, to be clear, a true artificial pancreas would incorporate insulin and glucagon. Only having the insulin knob to turn is so infuriating sometimes. room temperature stable liquid glucagon will be a watershed development.
All of the talk of SDR hacks are quaint. This is not that far outside the area of regard for my day job, and I’m unconcerned……
Yes, in all cases, a priori knowledge of the pump ESN is required to issue commands. And, again, if you try to get the pump to do something outside of some predefined safety limits, it just wont…..
The benefits to the patient and care giver far outstrip the perceived risks (better A1C, rest for parents, some autonomy for kids who would otherwise be kept closer to home to allow for parental monitoring and correction…). These systems are far from perfect, as they make some assumptions about the users lifestyle, and are not well tuned to adolescents. They help , but don’t fix everything. Hats off to Ben West for his work on the medtronic pump, and the omnipod reverse engineer is going to bear similar fruits.
Looking forward to the commercial solutions, because while I like being able to directly affect my sons quality of life with L33T Hax0rz skills, it’s a constant battle to keep hardware and software alive on a 10 year old. Kids are great for accelerated life cycle testing…..
BTW, Both systems depend exclusively on Dexcom CGM, which is the BEST THING IN THE WORLD for Diabetics!