Hacker News Reader

> https://replica.health

Oh my gosh, this is the startup I considered starting last year when this issue became personal to me and I wrapped my brain around the complexity of insulin dosing.

There are a lot of challenges here but we absolutely need an external "brain" to correlate many data points, some trends, and reasonably estimate current insulin sensitivity.

I'd love to chat - send me an email at sam@replica.health . An accurate time-varying insulin sensitivity model is one of our big projects.

I formerly used to work in the diabetes management space, and I too would be interested in chatting seeing as I have acquired some modeling expertise in the meantime.

Good luck with Replica! I built something sort of similar for my family (my 8 yo has T1D and a lot of life-threatening food allergies): https://saltie.app. Happy to chat as well, I can create an account for anyone interested, and I can share what I’ve learned in making this.

So I do not have a medical background. I have however worked a number of Industrial Control Systems (ICS) projects, and what you describe kind of sounds like a PID control loop, which also is not a simple push up/down approach.

From Wikipedia:"A proportional–integral–derivative controller (PID controller or three-term controller) is a control loop mechanism employing feedback that is widely used in industrial control systems and a variety of other applications requiring continuously modulated control. A PID controller continuously calculates an error value e(t) as the difference between a desired setpoint (SP) and a measured process variable (PV) and applies a correction based on proportional, integral, and derivative terms (denoted P, I, and D respectively), hence the name."

Getting PID control loops to work has a lot of research behind it, but it's still hard to get right with new hardware. I would imagine a PID control loop involving organics (wetware) would be much order, and harder still a PID control loop in organics with life-threatening failures possible.

At this point all the major solutions are using an algorithm that would probably fall under the umbrella of "Model Predictive Control" rather than a vanilla PID controller. An absurd spate of patent trolling occurred back in the early 2000s related to Controller definitions like these though. Researchers patented the use of a "PID controller in artificial pancreas systems" [1][2] which slowed down the development of APSs by many years.

The way the Supreme Court recently changed patent law [3] for software has definitely had a positive effect for APS development. [1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2769814/ [2] https://patents.google.com/patent/US20150306314 [3] https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern...

An absurd spate of patent trolling occurred back in the early 2000s related to Controller definitions like these

That's good news, right? That means that everything that people now come up with has well-documented prior art?

PID works well for most industrial controls, but it's a blunt instrument. Its mainly valuable because it's simple and doesn't really require much knowledge of the plant to implement. No 'model' is really required, other than the vaguest knowledge of first order dynamics. Instead of model knowledge you just iteratively tune it until it works.

If you need a really optimal control trajectory minimizing or maximizing for some parameter, you are willing to do the system identification necessary for it to work, and you don't much care whether an electrician can understand how it works model-based controls are much better. as /u/Communitivity mentioned so called 'model based control' (which is an umbrella of techniques) is a much more powerful tool.

My father was an MD (psychiatrist) and had this saying:

    - 1 drug, it works ok, still very patient specific.
    - 2 drugs at the same time, only if you validated correctly at least one alone before.
    - 3 at the same time: clusterfuck/total mess.

Base rule: do everything possible to use only one active ingredient/drug at a time.

Yes, much easier to control a single variable.

I'm a type 1 diabetic on multiple daily injections -- a pump just introduces a lot of inconvenience for me, price aside. You have to track batteries and change tubing and make sure the tubing doesn't snag on things, and unplug the machine before taking a shower or bath, and ... blah blah blah...

All I need for MDI is to carry my syringes and vial around in a cold pack (I live in the tropics, lol) and I don't need to worry about hardware beyond that.

I'm in the same boat re. MDI over pumping. I can still keep very tight control without a bunch of cumbersome attachments (I do wear a flash sensor though). Why vials and syringe rather than a pen though? I usually just carry the pen in my pocket and phone for monitoring. Even in hot weather I've not had problems with insulin losing potency noticeably before finishing a cartridge.

> In any case you will still need some a-priori info about meals and planned activities

Not necessarily, at least not via patient input. In the albeit small Inreda studies manual announcement of exercise and meals wasn't required (or an option). Medtronic also has a meal prediction algorithm on their newest offering that's a step towards a fully automated process and currently more or less obviates carb counting but isn't at the point where you don't have to announce a meal (yet).

Rather than integrating external data sources the algorithms are predicting based on historical glucose levels and/or insulin administration and it seems to be working.

https://jamanetwork.com/journals/jamasurgery/article-abstrac...

Agree that patient input shouldn't be necessary, but to replace it we will need to include other inputs besides CGM in a systematic way to get the optimal results. My company is working on how to use contextual info automatically collected by your devices to help (detected activity, measured calorie burn, geofencing, data from meal-ordering apis, etc.). This is especially true given that the CGM data themselves are lagged due to averaging and/or kalman filtering going on under the hood. This is a fundamental problem; Inreda uses two identical CGMs for noise reduction purposes just so they can get clean data with less of a lag.

None of the systems claiming you don't have to do anything in terms of meal announcement are _working_ in the sense of achieving euglycemic parity, which should be the goal. I can say with certainty that the cgm logs from people who don't announce meals on the Inreda device do not look like they are from non-diabetics: there are still often large post-prandial spikes. Inreda likely does better than any single hormone system, but the problem is not solved in any sense.

> Agree that patient input shouldn't be necessary, but to replace it we will need to include other inputs besides CGM in a systematic way to get the optimal results.

I'm not going as far as to claim Medtronic's approach (I believe the only one commercially available with so-called meal prediction based on historical CGM and offers full correction boluses) is the optimal one, just that it is an approach that is at least very good (~80% time in target) and while it still requires meal announcements it's just the first step of what they're trying to do. Clearly we can expect further iterations of these algorithms as the technology matures.

> Inreda uses two identical CGMs for noise reduction purposes just so they can get clean data with less of a lag.

Just giving an example that this is possible without external input or data, your statement was that you will need a-priori information which is not necessarily the case. Whether such a system is optimal is a different question.

I haven't seen the raw data and highly doubt enough of it even exists for anyone to make a claim whether or not such a system can be optimized to the point necessary.

> None of the systems claiming you don't have to do anything in terms of meal announcement are _working_ in the sense of achieving euglycemic parity, which should be the goal.

For clarity to any less knowledgeable readers while time spent in euglycemia is a very important outcome measure it cannot come at the expense of severe hypoglycemia or severe hyperglycemia/diabetic ketoacidosis (i.e. an algorithm that improves euglycemia to 95% but has a 2% severe hypo time is less acceptable than 80% euglycemia and 0.5% severe hypo.)

To my knowledge no system on the market/generally available right now is claiming to be completely input free. The closest to my knowledge is again the MiniMed 780G discussed in my first point which will assuredly be iterated on.

Also to be clear I'm not being dismissive of what your company is working on, it's a very interesting and novel approach. It may even be necessary to achieve the optimal product. I look forward to reading about your results when you publish them. I'm just presenting alternatives and a brief overview of what other approaches are for HN readers who are likely unfamiliar with the topic being discussed.

Really appreciate the pointed commentary on this! Happy to make further prognostications about the success of CGM-input-only APSs via email.

For the record, when I say "Euglycemic Parity" what I really mean is a sort of Turing test (not time in range), where a data-driven Endocrinologist is asked to tell the difference between CGM records from a non-diabetic, and CGM records from a diabetic equipped with some control system. Passing this test should be our long term goal IMO and we will probably have to bring many techniques to bear to eventually achieve it.

I think the "no meal announcement" features are really valuable for traditionally underserved demographics who, for whatever reason, can't "get good" at managing their disease.

The difference between how quickly food and insulin hit your bloodstream make it seem like there is no way to "algorithm your way out of" meal announcements. Food hits almost immediately, and with variable strength depending on macronutrients in it, and insulin takes ~15 minutes to start working, and peaks at 1 hour, with no concern about BG levels. Can you square these 2 for me and make it make sense?

I think what you're missing for this to make sense is what is the desired outcome. For type 1 diabetics there are three important ones:

1. Time in severe hypoglycemia - ideally 0%

2. Time in severe hyperglycemia/diabetic ketoacidosis - ideally 0%

3. Time in euglycemia (also called time in target) - clinical target is >70% and for reference the median healthy non-diabetic is in target ~90-95% of the time.

Closed loop systems are very good at #1 and #2 as it takes a while for levels to get to the severe state and insulin can be administered (or withheld) based on CGM.

When we talk about algorithming out of meal announcements it's whether historical patient-specific blood glucose levels and insulin administrations (i.e. a prediction of what you eat and when) combined with CGM can keep #3 acceptable, not necessarily optimal. Medtronic is using this approach and their newest model more or less eliminates the need for accurate carb-counting but they still require meal announcements. The hope/idea is that this can potentially be eliminated in further iterations.

Another important thing to keep in mind which is sometimes lost in these discussions is that we don't treat numbers we treat patients (i.e. what are the clinical outcomes). Generally speaking, we assume the closer to normal the better but we don't have actual data about how much an extra X% outside of target ranges matters in terms of clinical outcomes and complication rates. We only really started getting this data with CGM and complications in these mild states would require very large cohorts and long (10-20 year) follow-ups to detect differences as they're likely to also be mild.

So while you're absolutely correct regarding the limitations and that an algorithm cannot outperform accurate carb-counting and meal announcements the missing piece is that it may be sufficient. Particularly if said algorithms result in improved time-in-target for patients who aren't good at managing their diabetes and find meal announcements cumbersome.

First of all, clearly you have a ton of knowledge in this space, and I'm feeling very lucky I get to learn from your experience here. I have one more last question/challenge:

I totally get that we "treat the patient" -- that's sort of what I'm hinting at with the demographics. But, in my opinion this thing you said:

> we don't have actual data about how much an extra X% outside of target ranges matters in terms of clinical outcomes and complication rates. We only really started getting this data with CGM and complications in these mild states would require very large cohorts and long (10-20 year) follow-ups to detect differences as they're likely to also be mild.

... is not the same as saying "we know that 70% TIR is safe to live with no complications". I don't think any of the guidelines are that confident, because there's not enough evidence yet. Consider this study (discussed at [1]):

> Overall, increasing time spent with glucose levels in the target range of 70–180 mg/dL (3.9–9.9 mmol/L) was associated with decreasing risk for microvascular complications. For instance, 50.0% of the 10 individuals in the lowest category for TIR (<40%) had at least one microvascular complication, compared with just 27.3% of the 99 people in the highest category for TIR (≥70%).

> Moreover, El Malahi said that the 180 people with microvascular complications had significantly lower average TIR than the 324 individuals without, at 60.4% versus 63.9%.

This suggests to me that a difference of 4% of TIR can seriously affect long-term outcomes. And, by the way, even those with the highest TIR still had microvascular complications higher than the normal population. On top of that, we know that genetic and environmental factors may be at play.

Therefore, my monkey math is that 75%+ as a TIR goal may mean that even if the patient is an order of magnitude more vulnerable to complications, microvascular or otherwise, they have a much better shot.

And, unfortunately, the typical western diet with 3 meals a day and snacks, you have to be "good at managing diabetes" to get to 75%+ TIR. Thanks for reading my ramble.

[1] https://diabetes.medicinematters.com/easd-2020/glycemic-cont...

Sorry I know this is off topic, but I'm a recently diagnosed T1D and I would like to get more information about Loop and other loop-like open-source systems.

My son is T1D since age 7. He is now on the OmniPod pump and the Dexcom G6 sensor. It’s been a very effective combination that’s covered by insurance. The challenge with the open source projects is limited equipment that can be hacked.

Most people on loop have omnipod and dexcom g6 also so I don’t think it’s that limited. It’s true that it takes a few months for new devices to get integrated but open source APS are the only systems lets you choose what devices you want to use with them.

One thing I wish I'd been told more about when first diagnosed was the possibility of prolonging the honeymoon period. It was decades ago, and back then the advice was to eat a fairly normal diet and just dose as much insulin as needed.

If I was back in that position I'd go low carb high exercise from the start, and do everything I could to reduce my insulin requirements as much as possible. There are cases of new T1s coming of insulin completely, or just a low basal dose for multiple years.

Bummer to hear about beta bionics! My understanding was that the hardware they are releasing does have a place for glucagon, just not the software and additional reservoir required. I'm considering a switch to their pump since it seems like they've made it as automated as possible with insulin-only.

Would love to see/hear more about what you're working on!

This is very interesting, and I (T1D) would like to learn more. However, the e-mail signup doesn't work for me. ("Oops! Something went wrong while submitting the form.")

This is awesome. The obvious next step here would be integration with the pump to send the correct dose after the user confirms the app is correct in the food they are eating