DIY diabetes

Status
Not open for further replies.

Tdm

Well-Known Member
Relationship to Diabetes
Type 1
Pronouns
She/Her
Just a bit of a ponder really. It seems there is quite a bit of bodging and so forth in the world of diabetes. I use a modded version of dexcom app so it will run on a non approved phone (thank you random reddit dude), there are a range of 3rd part apps and people seemed to have been looping long before the news declared the 'invention' of the artificial pancreas. Is this common for medical conditions or unique to diabetes?
 
I’d say the #wearenotwaiting community was a pivotal force in propelling device manufacturers towards sensor augmented pumping, and remote realtime data sharing for family members at a speed they would never have managed if they hadn’t been chasing to keep up.

They just had the regulatory hoops to jump through, which must have been quite annoying!
 
They just had the regulatory hoops to jump through, which must have been quite annoying!
As somebody trying to do some relatively trivial stuff interconnecting tech stuff, I suggest you are grateful for the existence of the regulatory hoops which have to be navigated before anything can be approved for use. If I get it wrong then the worst I get is some smoke and a knackered circuit board. The consequences of not getting an insulin feed back loop working error free are a bit more serious.

Even with my curiosity level, I don't think I would be looking at it!
 
Even with my curiosity level, I don't think I would be looking at it!

True! But I am really grateful that there WERE people like Scott and Dana Lewis who had skills to link technologies together - and knew they could do it - who got so frustrated at the glacial progress of the device manufacturers that they found ways to make it worth, and then developed tools so that others could build on that early work.

 
Absolutely, but there is a big difference between those who know what they are doing and the curious and no doubt talented amateur!

Getting modern tech to work well together can be remarkably frustrating even when it is all supposed to be operating to the same standards as many members posting on the forum have found when trying to make Fred's fancy watch show what Joe's detector is reading. Not so much a problem when stuff either works or does not work. Big issue when something works but works badly. You can do without that when experimenting with insulin dosing.
 
Absolutely, but there is a big difference between those who know what they are doing and the curious and no doubt talented amateur!
Whenever I've read or watched people talk about this kind of thing, what's been obvious is that they understand the risks and are very, very, careful to try and reduce them as much as they possibly can. (On the other hand, it's not like humans are perfect either. It seems quite plausible that an automated system that has minor flaws might still be better at it than me.)
 
I must admit i'd be rather reluctant to let a pump make decisions on my behalf after seeing how badly the libre 2 did with just monitoring my bs. My dexco. g6 is another kettle of fish entirely
 
@Tdm it is usually to gradually turn things independently, to find out how each suits you.
For example, you may have a pump and CGM but they don't initially talk to each other. This gives you a chance to learn how to "manually" use the pump because CGMs do fail and you will need to revert to manual adjustments. And it gives you a chance to work out whether the CGM is accurate enough for you.
Once you have the confidence, the closed loop could be turned on. AND closely monitored.

My pump and CGM talk to each other but are not fully closed loop - my CGM will tell my pump when I am likely to go low and suspend my basal. It does nothing when my levels are high (this capability is not yet approved in the UK).
Now, I have enough confidence in my CGM (and it allows calibration) to use the Closed Loop capability once it becomes available. But it took me some months to get enough confidence to try out the auto-suspend feature.

I would not have done this with the Libre. Actually, I would not do it with any CGM that does not support calibration. I wonder what it is about implementing calibration that they remove it in cheaper CGMs. It does not feel as if it shoudl be difficult as the algorithm is done in the app so it is "only software" (so says a software engineer 😎 )
 
That sounds a sensible approach, biuldin up trust in the equipment and algorithm. Not thst i'm likely to be entitled to a pump anytime soon.
I'd just use it to snack anyway!
 
I would not have done this with the Libre. Actually, I would not do it with any CGM that does not support calibration. I wonder what it is about implementing calibration that they remove it in cheaper CGMs. It does not feel as if it shoudl be difficult as the algorithm is done in the app so it is "only software" (so says a software engineer 😎 )
You can always calibrate the Libre if you read the data outside of the official app, but I'm sure you know that. I assume you're talking about officially sanctioned/OEM produced hybrid systems rather than the #WeAreNotWaiting type of thing that was mention at the start of the thread.

I get the feeling that the "no calibration" thing is seen as a positive feature as there's then no need to prick your finger (until there is as the sensor has gone TU). I guess this is also cheaper as no need to prescribe test strips as well as the disposable interstitial sensors.

Needless to say I use libre (2 now) outside of the official app and make sure I calibrate it! 🙂
 
@SimonP when I used Libre on a daily basis (now use a different CGM that talks to my pump), I used xDrip.
With Libre 1, I used a Miaomiao to send the reading ls via Bluetooth. Before that arrived, I was using Glimp even with scanning so that I could calibrate.
Given Abbott makes finger pricks readers, I am surprised they would intentionally go down a root that does not need finger pricks to calibrate. But Dexcom do the same: the Dexcom One (their cheap offering made by removing features from their more expensive versions) cannot be calibrated.
Ho hum. It doesn't really matter. I am just curious.
Like you, I would use unofficial apps if calibration is not available.
 
Given Abbott makes finger pricks readers, I am surprised they would intentionally go down a root that does not need finger pricks to calibrate. But Dexcom do the same: the Dexcom One (their cheap offering made by removing features from their more expensive versions) cannot be calibrated.
Ho hum. It doesn't really matter. I am just curious.
One assumes there's some method to their madness, I'm not sure what it is mind you!

Can the cheaper (officially-)non-calibratable sensors be used with hybrid closed loop systems? I imagine they recommend at that point that people move to the more expensive calibratable sensors? If my completely unsupported supposition is correct, they use the cheaper no-finger-pricks needed version to get people in the door and using the sensors (cheaper as no sticks prescribed, end users happy as fingers don't hurt, etc. - I guess this is at least cost neutral as many people don't do very many blood tests) and then make a bit more money/cover their liability for sensor failures by moving people onto the more expensive calibratable type if they move onto a hybrid closed loop pump (which I assume is probably the most expensive type of pump cf a basic dial-it-up-yourself version).

I realise they are not just there to make money, and there's doubtless a desire to make life better for people, but they do have shareholders. Perhaps I'm too cynical 🙂

I must admit I know little about pumps (and certainly not much about specific versions, their costs, etc), though I have looked that the #WeAreNotWaiting software/algorithms to see what can be applied for MDI users. I'm happy to be told I'm wrong! 🙂
 
Its great we have all these non official aps, but it does rather worry me..
1/ I'm relying on a modded version of the offivial app downloaded from some reddit random for something that is safety critical (mind you, given the issues with libre link the non official apps seem as reliable..)
2/ not everybody is into tech stuff, and so there is something of a digital divide (mind you, so much about diabetes is taking responsibility forvyour treatment)

Is diabetes unique in the way the 'patients' take control and even come up with their own tech?
 
It is frustrating that one must jump through hoops to have real time access to the data. One assumes the NHS/NIH/other health legislators are happy that CGM data can be dumped for review by the medical profession, but I really don't see any downside in making real-time access to the data easier for the user. I can't even see that it will take any significant programming effort - local webserver/API call should be trivial to implement and would remove the need to hack the apps/comms protocols themselves.

It's a different matter with the pumps as there's bi-directional data transfer and also a significant danger to life with misuse, though these are also problems that could be overcome. I imagine the requirement for licencing (a specific combination of hardware and software) is the reason for this situation. I'm not sure what is a realistic path forward for pumps/pump control software, it's also not something I've spent any time thinking about.

I wonder if the CGM issue could be resolved by the medical authorities mandating that the apps provide a method of accessing the data (in a timely fashion i.e. as soon as it's available) so it can be analysed in real time outside of the OEM's apps. I've no idea how one would go about petitioning for this though.
 
Is diabetes unique in the way the 'patients' take control and even come up with their own tech?
Is it that there is data and something that can be controlled and a general lack of movement (closed off access to both data and control) from the equipment suppliers along with a strong motivation to do a better job? I think this combination may be the answer, for example I know the same approach of hacking protocols to have access to use data was performed in the early days of smart (electricity/gas) meters - the control aspect isn't there in quite the same way, though I suppose one could point at smart switches, etc., whose protocols were also reverse engineered to allow control outside of the OEM's often limited software.

I imagine there are other instances people know of. I can't think of anything off-hand in the medical world, though I imagine there's a healthy amount of reverse engineering of file formats that goes on to allow access to/processing of medical data files (e.g. imagery) outside of the apps that come with the kit.
 
I don't understand your question about real time access.
Do you mean using Bluetooth to send data?
Dexcom One does this out of the box.
As for NHS having access to data. So do we. For Libre this is Libre View

Maybe I misunderstood you.
 
What I meant was supplying the data in a format that can be processed in real time. Is there an openly available API provided by the Dexcom One device such that I could write myself an e.g. Android app to receive the data as it is generated and do something with it (present alongside IoB, CoB, and use to project future blood glucose).

LibreView displays the data, it also allows (iirc, I've not used it for a long time) a download in a CSV file, which is all fine for offline review (which is what our NHS consultants do) but isn't useful for real-time use to plan how much insulin to take for the meal you're about it eat right now.

I think the needs of those with pumps are perhaps different from those on MDI - I really value the ability to keep track of IoB/CoB (which I guess pumps do anyway) and to look at historic data to work out how things reacted the last time I was in a given situation (blood glucose level and trend, what I'm about to eat). I get the feeling, which may be completely wrong, that with a pump there's slightly less need to worry so much about the boundary conditions as you can tune in real-time, vs my taking relatively larger doses of insulin more infrequently, which means I'm very much more committed once I've made the decision.
 
Last edited:
@SimonP I have not looked for such an API but i assume it must exist because that is what the unofficial apps use. The data will not be in the form of BG. It will be some sort of ISR.
Have you looked at whether these apps have an API to extract the BG from in near real time?

As for pumps, the keep track of IOB but, if by cob you mean Carbs on Board, I think that is incredibly difficult to track because different carbs are digested at different rates. How are you going to tell an app that the 50g of carbs you just consumed were full fat coke or a large slice of meat feast pizza?
The advantage of a pump is that I can chose to have all the insulin now in terms of the coke or to eek it out slowly over the next 5 hours for the pizza. But that requires my brain to work it out.
I do not have a closed loop pump but my understanding is you still have to tell it how many carbs you are going to eat and chose how you want it dispensed.
No pump I know has a form of AI to work out if what you did last time you ate the same food was right or whether it needs tweaking.
The best it can do is work out how much basal you need. But because injected insulin is very slow (even the fast ones like Fiasp) compared with what a healthy pancreas produces, it cannot react to raises in BG.
 
@SimonP I have not looked for such an API but i assume it must exist because that is what the unofficial apps use. The data will not be in the form of BG. It will be some sort of ISR.
Have you looked at whether these apps have an API to extract the BG from in near real time?
I don't know about Dexcom (though I will have a look) but certainly the way the unofficial apps work with the Libre devices is to either talk to them directly over Bluetooth (with someone having reverse engineered the protocol and cracked the encryption), or (for libre3 afaiu) to decompile the official app and insert some code (a jump or a library shim, I've not looked at the specifics in this case) to send a broadcast message to let other apps know the value. My point was that it would be nice for the Libre app (and indeed all apps that talk to CGM devices and pumps for that matter) to do this by default - broadcast the new blood sugar (or e.g. insulin, carbs) value so any interested apps running on my phone could accept that data and use it for whatever they want to.

I hope we might eventually get to the point where the sensors themselves (the bit stuck in your arm) acts as a Bluetooth Low Energy CGM device (for which there is a standard open profile) - this would mean any app (which you authorise) could accept data from the device (including bike computers). I assume there may still need to be an app from the OEM to adjust the conversion parameters stored in the on-your-arm bit of the system. A pipedream perhaps 😉

As for pumps, the keep track of IOB but, if by cob you mean Carbs on Board, I think that is incredibly difficult to track because different carbs are digested at different rates. How are you going to tell an app that the 50g of carbs you just consumed were full fat coke or a large slice of meat feast pizza?
The advantage of a pump is that I can chose to have all the insulin now in terms of the coke or to eek it out slowly over the next 5 hours for the pizza. But that requires my brain to work it out.
I do not have a closed loop pump but my understanding is you still have to tell it how many carbs you are going to eat and chose how you want it dispensed.
No pump I know has a form of AI to work out if what you did last time you ate the same food was right or whether it needs tweaking.
The best it can do is work out how much basal you need. But because injected insulin is very slow (even the fast ones like Fiasp) compared with what a healthy pancreas produces, it cannot react to raises in BG.
I agree this is difficult, and perhaps it won't work, but it would be nice to have the data readily available to be able to experiment and see if it could be improved. I think outright predictions (like with the weather) will be hard to impossible for long durations (hours rather than days with the weather), but for an MDI being able to be more adaptive (moving toward the way a pump works) with pre-bolus and then perhaps a couple of injections across a large meal with some analysis built in (rather than guess work or gut feel) would be within the realms of possibility. There does of come a point where one asks whether a pump would be better, I suppose that could be analysed on a cost basis/determined by how much people dislike injections 🙂

It is possible to work on something along these lines now (I've started, it's a side project, motivation is proportional to periods of poor control, so hopefully motivation remains fairly low!) as I can get real-time data from my unofficial (XDrip+) app, but what happens when a new sensor type comes out and you're moved over by NICE edict? if you've developed something that works with the previous unofficial app, you're stuck until the new device can be reverse engineered. It would be better for the data to be available from the get-go and then it's simply a case of a minor mod to get it talking to the new API.

fwiw I believe some of the newer code in AndroidAPS will accept and deal with unannounced carbs and if they are announced but the quantity is wrong, will also try to deal with that.

Looking back at what I said I certainly didn't mean to imply that it's easy with a pump, it's not, it's just different. I guess what I didn't consider was that we all have different degrees of variation in what we do and how our bodies respond, so no matter whether you're using MDI or a pump, there is more that could potentially be done to predict and advise on dosing/correction decisions.

If it didn't actually directly affect me I'd simply see this as quite an exciting and interesting area of research (it won't be perfect, but how good could be be made to be for as little effort as possible for the end user).
 
Fundamentally this is not a software integration issue, in my view.

The real barrier to the type of predictive engine you seem to be hoping for is that the inputs are largely unknown.

For instance, I have collected a lot of data over the past years and can see multiple instances where I ate the same meal, ostensibly with the same starting conditions (e.g. blood sugar, exercise level) only for the after effects of the meal to be quite different. That leads me to conclude that there were other factors involved. Currently I know of no sensor technology that could make those factors available as inputs to a prediction algorithm.

That does not surprise me in the least. Our bodies are complex engines and with T1D a key feedback mechanism is broken. It’s almost like what would happen in a car engine if a key sensor lead was disconnected - the car might run but not without issues.
 
Status
Not open for further replies.
Back
Top