Hacker News Reader

Comment by jimrandomh | Hacker News Reader

The article, strangely, leaves out the name of the project it's reporting on. It's OpenAPS, http://openaps.readthedocs.io/en/latest/ . I use it and have worked on the code. It's a massive health and quality of life improvement over anything that exists which is FDA approved. The core problem is that the FDA-approved devices are optimized not for getting the best result, but for ensuring the manufacturer can't be blamed if something goes wrong. But that in practice means kicking most of the important things to the end user and their physician, who can't do nearly as good a job as software can.

View on HN

Hi- I used to work in regulated pharma and I want to be clear: " The core problem is that the FDA-approved devices are optimized not for getting the best result, but for ensuring the manufacturer can't be blamed if something goes wrong" is a misleading statement. The reason everything is regulated is that sometimes things do go wrong, and it's necessary to have root cause attribution so the problem can be remedied and a fix deployed, and, if somebody did something illegal or dumb, they can be sanctioned.

I wish your project success, but I think (and I've got a bit of experience) if you can't accept that regulation of health products is almost certainly necessary, and that not producing the "best" results is a reasonable if conservative approach, I will never trust your product.

The problem is that although regulation may be necessary, the regulators incentives are different than the users. Regulators are rewarded for being overly conservative. If they are making an assessment best on the riskiness of a device versus the benefits to its users, they should say what their criteria are.

Different users are willing to accept different amounts of risk for a given quality of life improvement. Besides differing between users, the tradeoff is almost certainly in favor of accepting more risk than a regulator would approve.

I think it may help to have some specifics about what, exactly, the regulations are screwing up here.

Every type 1 diabetic has some parameters that they use to determine how much insulin they need: an insulin to carb ratio, an insulin sensitivity factor, and a basal rate (or several basal rates for different times of day). The way these parameters are traditionally managed is that your devices collect data about your carbohydrate intake and glucose at various times of day, and every 3 or 6 months you bring those devices to an endocrinologist's office where they print them out, a doctor looks at the printouts, and the doctor suggests tweaks to the parameters. This process works very poorly, first of all because 3-6 months is too infrequent, and second because calculating the correct parameter tweak requires a whole lot of math, not just looking at a printout.

The way it works in OpenAPS is that a program runs nightly, looks at historical data, figures out the correct parameter tweak, and applies it for the next day. This works much better. Much better long term health, much better quality of life, much lower short-term risk of death. But if someone dies, there's no doctor to pin it on. So device makers don't include that feature.

(This is the clearest example, but there are others as well. There are also things like where alert thresholds are set; too few alerts and you're at risk of failing to alert the user to something important, too many alerts and you cause alert fatigue and impact quality of life.)

When you say OpenAPS "works much better", while I believe that in general is probably true, how exactly do you know? Is somebody monitoring the OpenAPS fleet and its users? If something did go wrong, would you be able to recover the decision process that led to the incorrect dosing?

Deep understanding of the system, plus personal experience. There is a repository of OpenAPS users' logs, accessible to a small pool of researchers, but (for medical privacy reasons) there isn't any central fleet monitoring. Each user has detailed logs of what their own install saw and did and why, and is expected to monitor it closely. (And we do in fact monitor them--not just as a precaution, but as a necessary part of the remaining decision-making we still do ourselves. The monitoring requirement is much more manageable and less time-sensitive than it would be in the alternative, without a closed-loop system.)

I have, in fact, had incorrect dosing happen, including the worst-case scenario of an incorrect large bolus at night. (That happened because of a bug on the git head branch, not a release version, which is much riskier. As a developer of the system that's a risk I knowingly accept.)

And that's not actually that bad. The important thing to realize is that the point of comparison isn't a zero error rate, it's the error rate a human would make. The worst-case scenario is quite well understood: excess insulin, up to a configured dosage limit. And that's an error which humans definitely make--it's not even a rare mistake, it's a mistake that a human doing everything manually will make multiple times per year, every year.

When you say The worst-case scenario is quite well understood: excess insulin, up to a configured dosage limit.

Is the configuration software controlled? IE, if you had a bug in your configuration or in your microcontroller, could that bug lead to exceeding the configured dosage limit? Or is there a hard limiter (fixed amount of insulin, a physical limit switch, etc) that prevents that.

There's a software limit, selected by the user, in the microcontroller. There's a per-bolus limit, selected by the user, in the pump. There's a physical limit, in the amount of insulin that is loaded into the pump at a time (typically 2-5 days worth).

OK. Based on what you said, I see numerous situations in which a user could receive very large doses simply due to software errors. Have you had external auditors test your design from an adversarial point of view?

Well, the bloomberg article mentions that Medtronic has accepted this new uprising (which is great), but there's nothing mentioned about if the new relationship has meant the DIYers have a clear path to controlling pumps that doesn't rely on hacks.

The chances are this is unlikely, for legal reasons: Medtronic creates regulated medical devices. I wonder whether it would be possible to add something along the lines of "push this (software/hardware) button to allow non-regulated 3rd-party hardware and software to begin controlling your medical device, but doing so will bind you to <insert waiver here>" and get such functionality to pass FDA approval. I somehow suspect not, although I would be very happy to hear otherwise.

As things stand now, though, it sounds like (as the article suggests, with the picture of a "hacked pump") people are still relying on methods and techniques that it sounds like anyone can use. So yes, unfortunately everyone's in a situation where any adversary within Bluetooth range could probably take the device over, and (depending on the severity of the vulnerability being used) perhaps modify the pump itself to pump too much or too little regardless of inputs, or similar.

Quite an uncomfortable situation from a security perspective. :/

Chiming in to say that some data is available to the public as well, as these Open Humans users have shared their Nightscout data publicly: https://www.openhumans.org/api/public-data/?source=direct-sh...

These two explanations seem entirely compatible to me.

For better or for worse, in an environment where "root cause attribution" is such a preoccupation, it's not such a stretch to think that the agents acting in it would be strongly incentivized to minimize their opportunities to be the root cause - in other words, "be blamed if something goes wrong".

I don't think that needs to be interpreted as nefarious. It might just be that everyone looked at making them more automatic, and just decided that the costs to do all the research that would be necessary for CYA and regulatory purposes would be too great.

Yes. It is the "ensuring the manufacturer can't be blamed if something goes wrong" mindset that says, "it's necessary ... if somebody did something illegal or dumb, they can be sanctioned".

Another approach would be to focus on patients and ignore punishments. Which is what the hackers are doing: ignoring rewards and punishments that are driving professionals in the field.

Not necessarily even illegal or dumb.

One of the things about testing drugs and medical devices is, you really can't cover all your bases. It would be too expensive to construct a clinical trial with the statistical power necessary to reliably detect very rare side effects. I don't think anyone wants to delay releasing all new drugs to the market by 40 years so that we can be sure about what happens if you take it over a lifetime. Even post-release monitoring for these things is potentially tricky, due to the poor interoperability of EHR systems and also, in many jurisdictions, unintended consequences of health care privacy laws.

Meaning that there is no amount of due diligence that will guarantee you can't get sued. Which is fine, you can always go for proportionality instead. But then, the amount of due diligence that's necessary is driven by what costs the legal system is willing and able to impose, and, at least in the legal regime I live under (USA), they've got their own entirely other set of procedures and incentive structures that they're working with.

Insulin is incredibly expensive and is manufactured by some of the companies making these devices. I wonder how much less insulin people use with these devices?

There is no overlap between companies that manufacture insulin and companies that manufacture diabetes-related devices. (Not for any fundamental reason, it just happened to work out that way.)

Also, the amount of insulin used is not significantly different with a closed-loop system vs. not. Although closed-loop systems do increase the benefit of faster-acting insulin relative to slower insulin, and the fastest-acting insulins are more expensive (especially inside the US).

Somehow I can't help but read you've smuggled endorsement for: It's ok if the product is more dangerous when bundled with the benefit that we can blame it on some organization.

The more generous interpretation is: We value life and try to reduce the risk of severe damage when making drugs. And regulatory bodies exist to combat the incentive to just ship whatever works without adequate regard for what could go wrong

Yes, this is what I meant.

Thanks for being generous.

And what do you suggest we do when an open-source "biohack" results in something like this ?

https://en.wikipedia.org/wiki/Thalidomide

Note the mistake made, and just how subtle it was. During testing a somewhat more ad-hoc process was used to produce the drug that did not result in the bad isomere, and then it was sold with multiple isomeres in the actual drug. Regulators at the time thought that isomeres did not matter and it took years for the effects to become clear. Of course regulators did not test for things they didn't know about. Neither did the companies (not just one). Crucially the drug was NOT tested for the effect on pregnancies (and was therefore not to be taken by pregnant women, like many drugs and even some non-drug products like famously alcohol).

Furthermore: there is at least some amount of "guilt" on the part of some of the mothers: the medicine was NOT approved for use during pregnancy, and stated this.

Result: >10.000 crippled children.

Where is the guilt to be placed for this incident ? I would argue that the primary guilt is with the regulator (government) and a small amount with (most of) the mothers for taking unapproved medicine, with the rest of the mothers following doctors' prescriptions (which of course means those doctors prescribed unapproved medicine). Needless to say, the company was blamed, and forced to pay (essentially in trade for not going to prison). The German government denied any responsibility, and several other governments (famously Spain) went further: they denied anything had happened at all.

So let's say there is a timing bug in this "open source pancreas", and it starts pumping insulin into the patients bodies without cause, say at the unix epoch transition. I would guess that at least half of them won't survive.

What happens next ? Given the Thalomide incident we can make an educated guess: whatever the law says, and despite patients "accepting the risk", even when the patients explicitly make mistakes in the treatment, you can bet the government will go after whoever they can arrest, and force them to pay millions of euros, or throw them in jail for the rest of their life.

People cannot be trusted to accept responsibility for the result of picking their own treatments, even when fully informed about the risks.

I actually don't care about anyone else's opinion of what I may do to manage my chronic, lifelong, slog of a disease. This is merely my chosen alternative to doing math and jabbing myself with a needle manually, which any reasonable person can conclude is perfectly capable of killing me within minutes. This is already delegated to all T1Ds in the normal state.

Your scary hypothetical is not possible. As if to agree, my pump just beeped at 10PM, announcing that the temporary basal (which can't kill me at maximum setting) expired and a new one was chosen. It's best choice is actually to suspend basal entirely when it knows I've dosed too much, which makes it a very legit safety improvement.

Oh, and a company created the example, which waters down your point - what convinced you that the very capable hands of people affected by the disease directly with a strong desire for data to back every thing up is anything like an accident waiting to happen? There's no profit motive here! (PS: it runs a direct test suite on install, and has cloud CI)

I have to add: Thalidomide is still prescribed today as it is a very effective drug. Also, as a response, the US has a much stronger system for evaluating drug safety.

US regulators did not approve thalomide until after the risks were known. Their system for evaluating drug safety is the strongest in the world and that is why there were no thalomide induced birth defects in the US. Those problems, subtleties and failures of regulation were in European markets where thalomide was approved more quickly (and new manufacturing processes were less closely regulated than the drug itself). EU has stronger regulatory practices in place as a result.

The narrative is more complicated than that, see https://en.wikipedia.org/wiki/Frances_Oldham_Kelsey and https://blogs.fda.gov/fdavoice/index.php/2012/02/50-years-af.... In particular: athough Kelsey did correctly identify issues, there wasn't legal support for that kind of regulation until her work led to https://en.wikipedia.org/wiki/Kefauver_Harris_Amendment which was necessary legal support for the FDA regulation process.

True, but the point is more about that the government (and the people) went after the producer of the drug, despite that producer not really having screwed up, and left the ones that had screwed up (state, mothers and doctors) alone.

Furthermore, the law did not really support these cases. But when you cripple 10.000 babies, law does not matter. Plus we all know they went after the company, not because it was at fault, but because they could band together against it.

If that were to happen to an open source project (and that seems a reasonable guess for open source "biohacks"/medicine when they screw up) ... the authors will go to jail for life and die bankrupt. It doesn't matter what license, it doesn't matter what contracts say, it wouldn't even matter if you have personal videos of every user saying they will never hold you responsible with a paper around it signed in blood by both the user and a public notary.

THAT's why we have the pharmaceutical industry we have.

That's not the endorsement. The endorsement is that it's okay for a single product to be suboptimal as long as the system is optimal. It's more optimal to prevent or slow down a number of innovations in order to protect the vast majority of people from the sort of mistakes and scams that other industries accept as standard.

From the docs:

"One of the most frequently asked questions is “I have a 723 pump but it has version 2.5B software version. Has anyone figured out a way to make newer model Medronic pumps compatible? Like flash older version of software onto my 723 2.5B pump?” The answer is “No. The ability to downgrade software versions in the pumps does not exist. It has been investigated and nobody has made any successful progress to that end.”"

I'm curious as to what form the investigation took. Are you aware of an online record of this investigation?

Are compatible pumps rare enough that the need to preserve them is constraining reverse engineering efforts?

---

Edit: For those wondering what these things look like, here is the FCC submission including internal photos. FCC is involved because of the integrated wireless link.

https://fccid.io/OH21510

https://fccid.io/OH21510/Internal-Photos/Internal-Photos-239...

Looks like a System-on-a-Chip with separate memory chips? Can't make out the numbers. Opening in GIMP, it looks as if the photo has been doctored to remove chip numbers? That 12-pin unpopulated footprint on the processor board is for a test/JTAG header?

(I have 2 723 2.3A pumps, using OpenAPS)

A specific X-and-below is required because the RF protocol was reverse-engineered, presented at DEF CON 19 (2011), and the manufacturer locked it down immediately (PSK, gg). The new protocol has not been reverse engineered (this is for Medtronic Minimed)

A newer style of RF pump from a different manufacturer (Insulet OmniPod) has been de-capped and had its protected-mode firmware scanned, and has been disassembled and picked through - and re-flashed firmware has been sent to that pump and works fine, and we understand the cryptographic protection algorithm (we can talk to them) and a great deal of the protocol. That still leaves a massive "forward engineering" and integration efforts that must be non-commercial by nature (because laws)

edit: there are literally 7 of us that have access to the RE'ed firmware repo (it's a private github repo) - PM me if you're interested (there's a really irrelevant NDA that is involved, which I think is spooking wider sharing)

Pump manufacturers are not technology leaders and have no forcing function to create open systems. There is no reason they could not publish the protocol and also allow me to enroll a key (knowingly voiding affected aspects of the warranty) and interact with a device that is legally part of my person.

Of course, this is mostly a USA problem: for other jurisdictions there are open compatible pumps (http://www.sooil.com/eng/product/) that have this, but they are not available (including for insurance support of the consumables) in the USA

Someone should issue a challenge to hotz et al. My guess is that this the intersection between diabetics and reverse engineering hackers is only a very small number of people, so this kind of device or impact it could have on people might not even be generally known in the community

As a "reverse engineering hacker" who is a diabetic with one of these pumps (The 670G to be specific) I have black boxed the shit out of it, but because it is doing a good job of keeping me alive and the cost of a new one is high I have yet to disassemble it and do a thorough RE of it. In ~4 years when the warranty is up an insurance is willing to replace it then I will be disassembling it and hacking the shit out of it.

What happens to all the pumps that break? Chances are that the mechanics break before the electrics, so there will be a bunch of broken pumps with intact electronics somewhere in the wild. Can they be had as freebies for reverse engineering? Many would get returned to Medtronic under warranty, but there would be exceptions?

I had one mechanically fail this summer and my options were turn it in or pay $3,600 and as much as I want to RE it I don't want to spend $3,600 on it. So far medtronic is doing a very good job of limiting the secondhand market on these. I do make regular ebay crawls looking for them through. so far nothing has really turned up :(

Judging by the PCB photo's, that device is much more complitcated than I'd expected.

Anyway, I would love to help the community with some reverse engineering.

Compatible pumps ARE that rare these days... I've seen them being sold online for anywhere from $500 - $3,000 depending on their condition. I've purchased a few as backups because it's not a question of IF my current one will fail, it's WHEN.

Thank you for this work. Do you know why the applicability to type two diabetes is not as clear as for type one? I'd love to read more about that.

The core problem is that the FDA-approved devices are optimized not for getting the best result, but for ensuring the manufacturer can't be blamed if something goes wrong.

I live with someone who has a CGM (continuous glucose monitor) where the device came in a box with an insert saying "do not use this device to make medical treatment decisions." To see any of the readings you have to install an app whose start screen says it's experimental and, again, can't be used to make treatment decisions. But the user's manual has a chapter titled "Treatment Decisions" that tells you how to use it to decide when to take insulin and how much to take. It's frustrating that the messages have to be so contradictory.

A final question: how essential is it to be tech-savvy to use this technology? Is it sufficient to have somebody tech-savvy close to you who is available every day but not every hour of the day, or is it something that should only be in the hands of someone who understands how it works?

I'm not really an expert on T2DM (I'm T1), but I believe the main issue is going to be that insulin sensitivity is much more variable for T2s than T1s, and will change faster than autosens can keep up with.

The reason for the mixed messaging about treatment decisions is that the Dexcom G4/G5 (they're the same sensor with a different receiver) spent part of its product life not approved for use as a basis for treatment decisions, and was later approved for use as a basis for treatment decisions, but only under certain circumstances. There are some best-practices around CGM sensors that the manufacturers won't tell you about, like pre-soaking sensors, which greatly improve reliability. And, counter-intuitively, a closed-loop system is actually less demanding of sensor precision than a human giving correction boluses would be.

For OpenAPS, getting started involves installing Linux on an IoT board, setting up a server on Heroku, and monitoring log files. Tech savvy is definitely required, but mostly for setup, and occasional troubleshooting; if you have a tech-savvy person willing to put some time into it, the can set it up, show you how to monitor it, and then step away.

I can't answer your questions from a clinical perspective, however I'll have a stab at them. I'm a type 1 diabetic, diagnosed when I was 9.

> Do you know why the applicability to type two diabetes is not as clear as for type one?

I'm only stabbing at this, and it's anecdotal, but I believe it is likely due to the lack of consistency across type 2 diabetics. Whilst there is variation in Type 1 Diabetes, it is largely limited to lifestyle but the basic principle is the same - you don't produce insulin yourself. Type 2 diabetes is often caused by insulin resistance, and I guess varies wildly based on the individual, their lifestyle, and their genes.

> I live with someone who has a CGM (continuous glucose monitor) where the device came in a box with an insert saying "do not use this device to make medical treatment decisions." To see any of the readings you have to install an app whose start screen says it's experimental and, again, can't be used to make treatment decisions. But the user's manual has a chapter titled "Treatment Decisions" that tells you how to use it to decide when to take insulin and how much to take. It's frustrating that the messages have to be so contradictory.

I haven't been given a CGM for longer than a few weeks (NHS rules are a bit restrictive in my area if your control is good). However the rationale for not using the CGM to make decisions is based around how it gauges your blood sugar. Because it's relying on blood glucose levels in the skin tissue I have been told that there is a delay, and basically the CGM operates about 15 minutes behind your current glucose levels. This is ok when you're using it to track glucose levels over a day, but not particularly safe if you're relying on it to make a decision for obvious reasons.

> A final question: how essential is it to be tech-savvy to use this technology?

This is a question I have asked myself a few times. As mentioned above, it's pretty difficult to get a pump and CGM on the NHS in my area without proving that you can't treat yourself adequately with regular injections. I am unwilling to sacrifice my health to have a pop at getting a pump, so I had a look at private options. Whilst initially I think there's a fairly steep learning curve, there is quite a lot of documentation provided, and the community is pretty active and helpful. I suppose it's also helped by the fact that there is only a few pumps on the market (relatively speaking). The issue is that if something goes wrong in your config, which is not uncommon for a homebrew solution, then you have to go back to manually adjusting your insulin.

My SO has a continuous glucose monitoring, and as you say, the reading lags behind by 15-30 minutes compared to measurement from blood. But the blood measurement is a single, instantaneous value while the GCM meter shows the last 8 hour glucose levels plotted and the current upward/downward trend. While it takes a bit of cross-referencing between blood and tissue glucose levels to get used to the readings, it actually provides better information to base decisions on (fast acting) insulin dosage.

The GCM (Freestyle Libre) has been a life-changer and improved long-term management of diabetes. In particular, it has been helpful for maintaining a reasonably flat glucose level throughout the night (because of better information for evening insulin doses), where they previously had high and low peaks (down to dangerous levels a few times).

I suggest you do everything you can to get a continuous monitoring system. Because you can see your glucose level history, you can then make decisions on whether you need an insulin pump or not. If your night time glucose levels are fine, you might not need one. If there are high or low peaks you can't manage, a pump will improve your life.

> it actually provides better information to base decisions on (fast acting) insulin dosage

Would you say that's because you can get a better idea of trends once you have enough data? My understanding has always been that the true value in a CGM is revealing those trends and patterns that are really unique to the person and that are hard to spot with regular glucose testing.

EDIT: I realise that this is basically what you've said. Apologies, brainfart.

> I suggest you do everything you can to get a continuous monitoring system.

I'm currently jumping through the hoops to get myself one now. I can get my hands on one via the NHS fairly easily, it's just the pumps which are hard to get. I've done a lot of work over the past few years to get my control to a place I am happy with (finishing uni and that awful realisation that you are in fact mortal). I also wanna say that I recognise that as someone who is able to control my diabetes using injections it would be wrong for me to demand a pump when there are others who for various reasons can't control their condition. In a perfect world it would be great, but hey, we work with what we've got, right.

Yes, exactly. When you wake up in the morning, you can get a plot of the last night's glucose levels which you normally don't know about with discrete blood measurements. This allowed my SO to adjust evening eating and insulin dose and their timing so that the glucose levels stay within the "good zone" all night (the GCM reader unit has a helpful graph with the good levels highlighted).

If you can't get the NHS to give you one, it might be worth it to get it for at least some period (say 3-6 months) out of pocket. By that time it should have given you insights on your treatment and allow you to better assess if an insulin pump is the right thing for you.

It helps with figuring out long-term trends, but it's also an improvement even for a single snapshot-in-time decision. If your blood glucose is 150mg/dL and you're trying to get it to 100mg/dL, the difference between "150mg/dL and rising 3mg/dL/min" and "150mg/dL and falling 3mg/dL/min" is the difference between wanting insulin and wanting carbohydrates.

> better

What happens when the sensor is not reading correctly? Isn’t that the biggest possible danger? The human “knows” it’s wrong but software?

How do you tell that the glucose reading measured from blood (the old way) is correct? You can't. The new method is not worse than the old in this respect.

And again, you get at least 8 hours of history graphed on the display now. If it doesn't look sensible (w.r.t eating and insulin doses), you need a backup. If the old fashioned blood glucose meter gives a wrong reading, you are much worse off.

Note that the sensors are tested and approved, not the DIY hack the article talks about.

Old way: you repeat the measurement nothing is in your body. and you konw di you feel e.g. hypo. New way: the sensor needle is simply a little off (in stays sticked). You don’t know, the software doesn’t know. The sensor is not magic that works 100% of the time, it ends in a needle sticked in your body, many ways to go wrong, even if it worked a while.

And the danger of “fully automatic” is there.

Just to clarify, we were only discussing monitoring and sensors in this subthread. Not closed loop pump systems.

A sensor failure in closed loop is dangerous. I do not know how the control software detects and deals with this. I have no experience with them.

A closed loop uses the oref0 algorithm, which tweaks your basal levels and therefore cannot react to fast peaks or cause a hypo not easily fixed by having two candies (or giving an alarm if you're not awake). What it does is it detects an upward trend for the last X measurements, sets something such as 300% temporary basal rate, detects the trend reaching the peak, sets a 0% basal rate until you hit the predefined target (for me, 5.5 mmol/l during the day and 6.5 mmol/l at night). Here sudden wrong readings will not cause any harm or danger.

The new oref1 algorithm uses a method called super micro boluses, which can detect a sudden peak or unannounced meal, sees the first jump up, gives you a bolus so it borrows from the basals, setting the basals to 0%. The algorithm works really well for things such as eating a pizza, where you get about 50% of the carbs immediately and the rest + a bit more during the next five hours. So you take a bolus for the food, then when the fat hits in the oref1 will give you tiny boluses.

The latter is more sensitive to sensor failures, so it is on only when you told the system you have some carbs in your body, or if you happen to have a Dexcom G5 or G6 sensor with good noise readings, it will be on all the time and the system knows when the reading is faulty.

Which closed-loop system do you use which can provide both boluses and basals? Can you share? Also do you think Dexcom sensors can be always trusted? Searching, I find something like:

https://forum.fudiabetes.org/t/dexcom-out-of-range-calibrati...

The oref1 smb is in AndroidAPS release candidates and in OpenAPS. You can't trust anything 100% ever, but you start recognizing when they have problems and can cope with the errors.

Thanks. Readers should also note that the main topic is about the closed loop apparent "revolution." In reality it really can be dangerous, exactly because of the explained sensor problems which are real. To clarify to those that don't know:

The sensors are big things with the needle permanently in your body. You don't want three needles permanently to be sure that at least 2 from 3 work. If you have only one, you have a real problem if you trust it blindly.

Yes, it's good that some people try. But there are real risks, due to the current limitations as explained.

I'd say that I myself making all the judgements caused way more harm to my body than what the computer can do. It is that much better. Before I used to have nights when my sugar was in a dangerous hypo for hours during the night, luckily not causing too much brain damage. Now all of these problems are gone. Almost all of the scary hypos are gone. My A1c came down from 7.5% to 5.5%. I'm 88% of the time in range, 10% above the 8.5 mmol/l and 2% hypos (none of them at night) which I can correct fast due to alarms.

Thanks a lot. My question is: is the techology as reliable that somebody who is without any technical background (e.g a child on vacation without the parents) able to depend on it?

I know that most of the population is actually not technical, and that they can easily understand “correct when high, eat when low” but complex technical reasoning can’t be expected from them. In that context, sensors not functioning as in ideal lab conditions is a big issue.

Here in Germany we have a group of diabetics helping each other with the system. Most of us are not so technical, for everybody the system has been a massive improvement compared to their own judgement.

As a type1 you must have a lot of knowledge to be able to survive. The software is a tool you must learn how to use, but takes away lots of burden from the decision making.

> Here in Germany we have a group of diabetics helping each other with the system

Can you give some more details please? I ask for a friend of mine. Thanks.

It's just a loosely connected group of people in Berlin, going to the same doctor's office and being interested in tech.

For anyone interested, Scott Hanselman wrote about the open diabetes ecosystem (including OpenAPS) a few years ago:

https://www.hanselman.com/blog/ThePromisingStateOfDiabetesTe...

They actually aren't leaving out the name of the project, it's called Loop - the system that she's on is not actually OpenAPS. I've tried both systems, OpenAPS lacks a clean, user friendly UI. As a result, most people (according to a recent survey) are running Loop instead of OpenAPS.

And if you have different hardware (Combo, DanaR/RS), AndroidAPS gives a clean and nice UI and is based on the OpenAPS algorithms.

> optimized not for getting the best result, but for ensuring the manufacturer can't be blamed

read similar stories on r/medicine

advanced surgeons coming into the operating room with their lawyer in mind, entirely logical, totally sad

> The core problem is that the FDA-approved devices are optimized not for getting the best result, but for ensuring the manufacturer can't be blamed if something goes wrong

No, they're optimized for reducing risk as much as possible. The amount of scrutiny on a commercial product from a Fortune 200 company is about 2 orders of magnitude more than any DIY project would ever get.

You're both saying the same thing from different worldviews. Regulations work to minimize risk, but in the process they can and often do also reduce effectiveness and/or progress in a field.

To take a less sensitive example, NASA refused to allow SpaceX to do retropulsive soft landings for their Dragon crew/cargo capsules without a whole slew of regulatory work, which was just not a very effective allocation of resources for SpaceX. So instead of coming down retropulsively, similar to how they now regularly land their massive first stages with, the capsules come down using parachutes and a not-so-soft 'soft' landing as we've been doing since the 60s.

So you could argue this is safer. But that's not clear. What is entirely clear is that the cost and time effort that would be required to abide the regulatory requirements resulted in the entire idea being scrapped, derailing technological progress on that front. Perhaps with some irony, the capsules will still have the thrusters on the capsules to be used in case of an emergency abort - they just can't use them to enable genuinely soft landings.

It's the difference between risk of death, and risk of getting sued. The DIY project has a much lower risk of death, but (if a corporation were to do the same thing) a much higher risk of getting sued.

I disagree those two are decoupled. The DIY project has a much lower risk of getting sued, true. But lower of risk of death is highly dependent on edge cases and corner cases, and I'd challenge you to produce evidence that there is an overall lower risk of death.

None of this is to say I'm against any effort to develop an artificial pancreas. I used to work at Medtronic Diabetes. The slothful pace with which this endeavor is proceeding, despite the mountains of money behind it and the obvious and profound unmet clinical need, pains all of us. But "why was it taken so long?" is a question to which there is no simple answer. And though FDA is very much in the corner of "let's get it done" now, that was not always so.

For instance, the quote from the director at FDA re: "you can do everything but manage diabetes on your phone, you should be able to do that as well" masks the history of the med device industry for years trying to get applications on the iPhone approved by FDA and not being able to do so because you couldn't lock the iPhone down (i.e. prevent programmatically anyone from running any other program).

You're sort of skipping over the bit where a bug in the software (or a hardware issue) kills the user. That's the crux of "being blamed" and regulation.

You might say in response it will "almost never" happen, but when it happens to your loved one it most certainly matters a lot.

The risk-of-death is actually quite well understood. If a user gets too much insulin, and doesn't feel when their blood sugar is low and doesn't get a low-blood-sugar alarm or doesn't respond to the alarm, then they could die. So if the closed-loop system incorrectly commands too high a dose of insulin, that could be fatal.

But the alternative isn't that too-high doses of insulin never happen. The alternative is that all insulin doses are selected by a human, and subject to human error. And having a low blood sugar event due to too much insulin is not a rare occurrence for T1 diabetics at all.

Strikingly similar to a buddy of mine's story who was underground to the point he became known as "Bigfoot": https://www.bigfootbiomedical.com/the-legend/

Correction: It's Loop, which has some code overlap with OpenAPS but is a separate project. (Apologies to the Loop developers, your name was less Ctrl+F'able.)

This comment finally explains what article is about. Thank you.

Reply on news.ycombinator.com