Unburdening diabetes care: comparing and reducing manual interventions

[petervanrijt]

Hi all,

I am Peter, living in The Netherlands, and hope someone will find a cure for type 1 diabetes (T1D). Since my girlfriend (soon to be the mom of my son ^_^) was diagnosed with T1D only three years ago both of our lives rapidly have changed. We hope this is the right place for this improvement.

Love to hear feedback and hope to implement this together. This to provide insight on the number of manual interventions, and hopefully help each other to reduce them.

Best regards, Peter (and girlfriend)

A good quality of life

Our assumption for 'a good quality of life' is the combination of physical health (body) and mental health (little as possible manual interventions).

Closed loop systems really have improved my girlfriend's physical health and ensure less worrying (especially at night). We both are very grateful for this. At the same time, I see a physical burden arise. This because all (sensor) data, options, and alerts are always available. In one of our home discussions with my girlfriend, I asked what is most important to her. She mentioned:

1. a healthy HbA1c
2. a good TIR
3. fewer life interruptions because of diabetes

Her deepest desire is to live a normal - as possible - life without being bothered by diabetes. And stay healthy in the long run!

ADMI as new psychological metric

The above kept me thinking. The first two (HbA1c and TIR) are measurements already characterized as a number. You can view them in Nightscout on report tabs like 'Daily Stats'. Because of this, people are actively helping each other to adjust close loop systems to healthy levels.

Because of our closed loop system (AndroidAPS), my girlfriend has a very healthy HbA1C. But...nobody sees the effort it takes her to achieve it: the hidden costs. I daily see my girlfriend putting a tremendous effort in balancing between a hypo and a hyper. Often I wonder how to compare her efforts and results with others in the closed loop community.

Out of curiosity, I asked how many daily interventions she has (enter carbs, change cannula, start temp profile, snooze low alert(s), ...) compared to the best minimum amount. She could only guess because this currently is not (yet) characterized as a number.

This caused our idea to add a psychological metric: average daily manual interactions (ADMI). Because you enter all information in an app it should be possible to distinguish between manual and automatic actions. With this, our community gets a tool to inspire each other in unburdening daily diabetes care even more, whilst no forgetting a healthy HbA1c and TIR. Long story short: fewer life interruptions because of diabetes.

In natural language

Basically, this is an indicator of how much effort you have put into your diabetes care.

Suppose you bump into a T1D friend who uses the same equipment as you do and achieves similar physical results. For example, an HbA1C of 42 mmol/mol and TIR 85%. Both something to smile for.

Then you compare your 'average daily manual interactions' and see a difference of 20 manual interactions. Quickly you see an opportunity for more peace of mind and improved confidence in the closed loop system.

Example

To clarify the metric, I made a screen concept in which column 'Manual interactions' is added and filled with fictitious values:

Technical implementation

Educated as a programmer I tried to get an overview by analyzing MongoDB data collections. I saw our MongoDB (filled by AndroidAPS) does not seem to have a usable characteristic like inputType ('unknown', 'manual', 'loop' or 'automation'). The use of the metric (and) can only be added jointly by the #wearenotwaiting community:

1. Review this suggestion

2. Screen design We suggest to expand Nightscout reports below with 'manual interactions':

• Day to day
• Daily Stats
• Distribution
• Weekly Distribution
• Treatments

3. Screen design and reporting Report based on inputType ('unknown', 'manual', 'loop' or 'automation' where default should be set to 'unknown' to prevent interfering with current database values).

4. Storage in database Closed loop components like AndroidAPS, xDrip, Loop, OpenAPS, ... should enrich database information with inputType ('unknown', 'manual', 'loop' or 'automation' where default should be set to 'unknown' to prevent interfering with current database values).

Facebook

On Facebook, this idea has been shortly discussed with positive feedback (use this direct link). It took me some time to get it in writing.

[petervanrijt]

Added 'In natural language'

[TebbeUbben]

I'm really impressed by your idea. Many people seem to have forgotten that diabetes treatment shouldn't just be about BG values, but more importantly about improving people's quality of life.

As you already mentioned, your proposal requires differentiating between manual and automated treatments. You might be happy to hear that AndroidAPS is already able to provide most of these information:

Treatments (Bolus insulin and carbs)

Nearly all treatments are manual unless they are marked as SMB. The only culprit are eCarbs that produce many carb entries at once, even though it's just once "action". We could solve this by ignoring entries with less than 5g and instead looking at the Careportal note that the eCarb generator produces. In the future, we better store eCarbs as a single entry and create virtual carbs in memory when loading from the database to avoid this problem. I think it also makes sense to categorize many entries in a short time frame as one because some users tend to enter one entry after another for the things on their plate instead of summing them up.

Temporary Targets

Temporary Targets are manual unless their "reason" is "Automation".

Temporary Basals and Extended Boluses

I guess it's fair enough to assume that all TBRs and EBs are automated while the loop is active. We could use the "OpenAPS Offline" Careportal entry to determine when the loop wasn't active and then categorize all TBRs in that time range as manual.

Profile Switches

Unfortunately, there is currently no good way to distinguish between manual and automated Profile Switches other than looking at the log files.

[maryannep]

Excuse my big rave again, but I'm beyond excited to see what you've started up here, so here goes.

Great job getting this up & going. We've needed a way to bring 'time on task'/'time on life'/time not being 'pulled into screens' into the equation as a valid measure. As a psychosocial health researcher/usability consultant, I've also been thinking about this for a long time.

What you've created is a tool to change the conversation & validate that it's about so much more than the numbers. And that there's choice. One person's A1c of 5.8. might not be worth it for another if it involves a high number of manual tweaks. What's valuable for your partner right now during pregnancy & for women particularly in the first trimester, may well be worth more interventions, but once she has her bub she'll probably want to minimise d tasks.

And we all want best AID power/outcomes we can get with minimum manual tweaking.

This would be a wonderful thing to be able to use to compare DIY & commercial AID devices too. Thinking back awhile to a time when one company managed to create pumps that required more & more steps with each new iteration to get a simple thing done. Possibly due to approvals process, but gobsmacking.

I'm on a rave, but the first step is a simple measure like you've suggested as it's pretty concrete/indisputable. But each thing that might appear as a manual interaction is also experienced differently. Eg if I add some carbs on the fly via a click using Apple watch shortcuts & then use an Easy bolus button on my pump to give a portion of it, that feels good. But when I have to open my AndroidAPS app, go into a Bolus Wizard, am forced to think about what I'm going to eat & the timing, it's great to have this ability, but my heart is sinking. Esp if I can get the same outcomes from a quick watch click, a quick pump button click & leaving the rest to SMBs.

So yeah, will be challenging but worth it to think about capturing the nuances somehow too. And a useful tool for 'patients' to be able to bring into encounters with health care professionals too.

[kimberscott]

Just N'thing the enthusiasm here. We recently switched (back) from ControlIQ to OpenAPS for precisely this reason. "On paper," i.e. per standard metrics, our kid does about the same either way. But we were giving him sugar 2-3 times a day previously (I know!), even though he didn't spend much time low, and now he's doing just as well without manual intervention. I'd love to have an easy way to track this measure to see the effects of adjustments we make.

Will start tinkering around next week to learn more about what it'd entail! (We currently maintain a very-lightly-customized Nightscout fork but I haven't previously tried to add anything substantive.)

[maryannep]

The rescue sugar one is a good example. People often don't input this so it's not seen/taken into account (apart from as UAM but...) esp if it's done to prevent the low in the first place It means analysis tools may not work well including something I experienced recently... an endo eyeballing a Nightscout report. I knew something in. my settings was off, he thought it was fine. He didn't notice the hypos averted by pre-emptive glucose. Quick ways to add & incorporate this either with it affecting dosing or not affecting dosing seems like a good priority. (& of course, what we really want in the end is no bolus no carb counting at all)

[guydavies]

I love the general principles of this suggestion.

I'd like to see the possibility to differentiate between a "normal" manual action such as a set change, which happens periodically, and an "abnormal" interaction such as a correction bolus that doesn't have a matching carbs entry. This isn't quite as simple as it would seem because for some pumps the carbs and associated insulin dose are recorded as two separate records, so there would need to be some correlation. Even that might be tricky where the carbs are delayed relative to the insulin dose, but I'm just proposing what would be ideal rather than what is easily implemented or even possible. 😊

[sulkaharo]

Note the quality of this data is highly dependent on the technical setup of the user and this might in some cases increase the load of the user. For example, AFAIK most users are not using a Bluetooth paired glucometer and thus many measures are not stored, unless user started to mark down all the tests manually. This would also lead into the value not being comparable across users, thus possibly making the data look worse for users that have better data capture, which in turn can be counter-productive for the stress management once people start sharing the numbers. Also note most Nightscout users are not looping, so they also won't get data about insulin dosing and carbs unless the user manually enters the data. (FWIW we have a very low amount of manual interventions daily.)

I also wonder how people are expected to use this, where the underlying reasons for the number of actions / day is complicated and also involves things like nutrition, activity level, stress and other health conditions. So while people with great values could feel validated they're doing great, how will this lead to users with a larger amount of manual interventions being able to be less stressed?

[maryannep]

Great points. This is a really tricky thing to quantify. May not be possible at all. There may be better ways to get even the concept into discussion. And the very last thing I'd want to do is set up an awful added layer of some kind of competitiveness. This tech is meant to be freeing.

[inventor96]

I think there's a lot of potential with this idea. The biggest issue, as @sulkaharo pointed out, is getting reliable/consistent data. The more data the calculation has to work with, the more helpful it will be, but also the more work required by the end user, which is somewhat counter-intuitive consider what we're trying to measure with this.

I would suggest making this a non-default plugin to start with. This would allow people to use it and test it (hopefully being aware of the requirements and implications), but not show up for people who aren't aware of how to make it most useful to them.

@TebbeUbben

We could use the "OpenAPS Offline" Careportal entry to determine when the loop wasn't active and then categorize all TBRs in that time range as manual.

As a side note to this thought, this may not be a reliable method for the goal, because OpenAPS records everything that happens offline, and then uploads it to Nightscout when it gets the chance. The "OpenAPS Offline" careportal treatment is intended to silence unnecessary notifications about the T1D's OpenAPS rig seeming to not be working, when in reality it just doesn't have an internet connection to report its status.

[sulkaharo]

Related: I've historically done similar analyses based on data in our Nightscout instance. See for example https://twitter.com/sulka/status/1059103848906874882?s=20 The tool for pulling out the data for the graph is here: https://github.com/sulkaharo/oref0-tools