Glucometers (which measure glucose levels in blood) are medical devices familiar to diabetics, and notorious for being proprietary. Gentoo Linux developer [Flameeyes] has some good news about his open source tool to read and export data from a growing variety of glucometers. For [Flameeyes], the process started four years ago when he needed to send his glucometer readings to his doctor and ended up writing his own tool. Previously it was for Linux only, but now has Windows support.
Glucometers use a variety of different data interfaces, and even similar glucometers from the same manufacturer can use different protocols. Getting the data is one thing, but more is needed. [Flameeyes] admits that the tool is still crude in many ways, lacking useful features such as HTML output. Visualization and analysis are missing as well. If you’re interested in seeing if you can help, head over to the GitHub repository for glucomerutils. Also needed are details on protocols used by different devices; [Flameeyes] has only been able to reverse-engineer the protocols of meters he owns.
Speaking of glucometers, there is a project for a Universal Glucometer which aims to be able to use test strips from any manufacturer without needing to purchase a different meter.
Thanks for the tip, [Stuart]!
“Speaking of glucometers, there is a project for a Universal Glucometer which aims to be able to use test strips from any manufacturer without needing to purchase a different meter.”
Think we know what happens when one tries to break someone’s razor and razor blades business model.
Yeah except here, it’s “uses anyone’s blades”.
Although if it provides more capabilities than the ReliON Prime but uses Prime strips, that would be awesome.
Higher-end ReliON meters use different strips – I’m 99% certain their capabilities are identical, but you pay more for the strips just to use the nicer meter.
Grumble, can’t edit my post, but “without having to buy a new meter” isn’t really of much benefit. New meters are given away practically for free, with costs less than a single package of strips in most cases. The ReliON Prime I mentioned is $9, and strips for it are $9 per 50
But in this case you end up buying the Razors which is what the manufacturer wanted to happen anyways. I don’t think they give a hoot if you make your own handle.
Razor Blades (not Razors)…. I meant to say Razor blades. It should be Handles and Razor model. Need an edit button.
Dollarglucoseclub.com ;)
Aside from the fact they all seem to have different pin outs. I’m curious as to why reading the it’s not just a calibration issue with these strips. The strips themselves are fairly sinple devices, it equates to measuring their resistance and scaling it appropriately. I’m also curious to look up how easy it is to make the glucose oxidase required in accurate enough concentrations to be viable.
How easy or not it is to make is nearly irrelevant. One lawsuit – real or complete BS, it doesn’t matter – and the legal fees will far exceed the hard costs of production.
This x1000. It’s good and all that people are learning to design and build medical devices themselves but when used as an actual medical device then that makes it iffy. Who should shoulder the burden of making sure it not only works correctly but also starting/working with a respectable governing body to ensure safety and compliance?
Even using it as a warning device is a bit of an iffy situation because that implies that the device will not reasonably cause unnecessary burden on the healthcare system by giving false positive/negatives. Who ends up paying for those errors in time and money? Sure the individual that made it may be okay with paying for these errors if they were to ever occur but these errors also propagate to other individuals (healthcare workers) in terms of attention and time which could have been used on other patients.
It’s just a slippery slope to assume homemade is better because it is cheaper without also considering everything else in the mix. Compare apples to apples and not apples to oranges.
I have an interest in this project as I was diagnosed with Type 2 diabetes 3 years ago. Until 6 months ago I had things mostly under control with careful diet management. However I am now taking medication. My dad had the same progression and ended up needing insulin injections. Since I am in the UK and we have proper health care, and I am retired with only my state pension, I get free prescriptions. If I have to start using insulin, which judging by my dad’s experience could happen within the next 5 years, the testing machine, strips and insulin will all be free. However, I would be interested in kit which gave me access to the data in a more usable form.
So 2 questions, is the problem of certification a particularly US issue? We have national standards, and over the last 20 years most of the national standards in Europe have converged, So I believe that certification in one country, pretty much guarantees certification in the EU.
Secondly if such a machine is being designed by an actual user, then the incentive to get it right is a great deal stronger than for a commercial manufacturer. I would be more inclined to trust this open source kit because of that alone.
And just as an aside, there is precedent, at least here in Europe, for devices which use the same consumables. I have an older Phillips electric toothbrush. It uses the same fitting as a Bosch of the same vintage, so I can buy either manufacturers brush heads.
And then there are staples! Because there are standards for the staples, I can buy any manufacturers staples for my Stanley staple gun.
First of all, my condolences for you being diagnosed with Type 2 DM and worsening disease course.
In regards to certification, the company that I have worked for closely follows the IEC60601 standards with additional parallel certifications when required. Since IEC is more of a global thing then what we get certified should theoretically translate to other countries without any modification however that is not always the case depending on what kind of medical device as well as where it is going to be used (hospital/long term acute care, skilled nursing facility, nursing home, home, commercial, etc). There are certain things emphasized in the IEC that are more stringent and much government red tape and lag time that it is a headache to navigate through which is indeed a US issue though other countries may have similar things. Additionally, there are a couple of other standards that must be met in addition to the IEC again depending on type and usage of the device. Most places have any entire department dedicated to just making sure compliance standards are fulfilled correctly and to make sure the right testing/certification is carried out. It’s a headache and I wish there was a way to make it much more streamlined as well as easier to access (have to pay to even get the standards).
In regards to trust. I wholeheartedly agree with you that if you were the one designing it then you would likely make it better than the commercial offerings – at the very least non-inferior when compared. Open-source would be an advantage as well as others can see what it is doing exactly and improve upon it. What makes it complicated is that where would the fault lie in the case of if something went wrong (nothing is foolproof only lower risk)*. Does it go to the person making it, the seller, the user? Who ensures that all copies made from a design gets updated in the case something is found to be wrong? It’s easy enough to appoint blame if someone gets hurt by their own design but it gets a bit hard when it’s not their own design and they get hurt.
As far as compatibility goes. Part of that is due to greed and another due to the laziness/insular design process. Unless a governing body with enforcement power demands that things be compatible (such as the USB port for charging phones via common external power supply by the European Commission initiative), device manufacturers will continue to create their own proprietary things. Not having standards to adhere to opens the window to customer lock-in and lightens the design process by doing whatever is convenient. In addition, there is no significant incentive to make it easy for the customer to retrieve information from their medical device as the majority of the target customer base either (1) does not care or (2) does not know enough/has interest in retrieving it and actually doing something with it. That being said, yes there are medical devices which do offer the capability to download data but it’s kind of niche. For patient use that would be the OneTouch glucometer and for physician use that would be all insulin pumps as well as (my favorite area) implantable pacemakers, loop recorders, and defibrillators.
* By wrong/hurt it includes not only the instance of say device failure but includes things like false results which in turn leads to consequences resulting in either bodily harm or cost of time/money.
I would like to echo the comments that Toby has left. I actually work in exactly the role that Toby has described, ensuring that all FDA and ISO compliance standards are met in order for my employer’s glucose monitoring systems
to be legally marketed in the US. And, the biggest hurdle to any startup that would want to make a glucose monitor that works with another manufacturer’s test strips is precisely what Toby mentioned — who is responsible. The OEM of the test strips would surely state that they cannot be held accountable for any negative effects when using a meter that was not part of their (the strip manufacturer’s) design process. Each meter is designed very specifically to work with a particular type of strip and the error trapping mechanisms are all part of the system design which must be documented in the device master record and design history file. Now, if the meter manufacturer were to work with the strip manufacturer and develop a co-marketing agreement, then both companies would ultimately be certifying the performance of their combined system and would both be responsible for the reliability and quality of the system. FDA put out a specific guidance document on 11Dec2016 outlining the requirements for OTC glucose monitoring systems. (https://www.fda.gov/downloads/ucm380327.pdf)
Specific to this exact issue, FDA states:
VIII. Third Party Test Strips
Third party test strips refer to test strips manufactured and distributed by a company other
than the company that manufactures and distributes the glucose meter. Third party test strip
manufacturers should ensure that they are aware of any design changes to the meter because
such changes could affect compatibility of the test strip with the meter. Because test strips
and meters work as integral systems, third party test strip manufacturers should sufficiently
address in their 510(k) submissions how they will mitigate the risk of incorrect results due to
meter design changes. One way to effectively ensure that the third party test strip
manufacturer is made aware of any design changes to the meter is by having in place an
agreement between the third party test strip manufacturer and the meter manufacturer.
While I think this idea has a lot of promise, the regulatory hurdles are substantial.
sadly the big expense isn’t the meters. Ive got two now that work. when one broke I was given another free.
Exactly. What is needed is a hacked strip. Something cheap to make that will give the same results as the “razor blade model” commercial ones.
I don’t want any one to access my glucometer readouts. That is personal.
That is exactly why I have been writing this tool! Even some of the open-core or open-source projects related to glucose readings out there will rely on remote web apps that are insecure by nature, particularly when ran by inexperience users that only want to see their own data. The closed-source apps are trying harder and harder to have access to your readings, so that they can share them for research purposes, and not everybody is (or even should be) okay with that.
My approach is to write a totally local script for downloading and processing that data so that nobody but you and who you share the data with would have access :)
I use a tablet and the maufacturer does not provide an appfor my model
I’m afraid I don’t have an answer for that need yet :( But part of the work I’m doing with documenting the protocols (https://github.com/Flameeyes/glucometer-protocols) should allow others to build generic apps. I know of at least one iOS (proprietary, closed-source) app that uses the protocol definition I reversed, and provided corrections and improvements on them.
Tidepool is a non profit that has done some excellent work getting data out of glucose monitors and into their open soure platform. They’ve even worked directly with several manufacturers.
http://tidepool.org/
Author of the software linked earlier here.
Tidepool, and another half-dozen projects that I have been pointed at in the past year and a half, is only open source where they care about it. In particular, almost all the projects I’ve been pointed at, with a few exceptions, have an open source web app to upload data to and analyze it, which does not really make much sense if all you want is generate a report to share with your doctor (my doctor here is very happy to receive the exported PDF from Abbott’s app, but he wouldn’t care to sign up for an account on either a centralised or one-per-patient app).
Also, while Tidepool (and others) have software to upload data to meters, their software is not open source at all. The keyword there usually is “directly with manufacturers”. I had already a not-really-positive encounter with another similar project that decided to work with manufacturers to come to define an exchange format – Tidepool has a data model that may actually be more suitable, and actually open sourced, so that may be useful – but as usual once you decide to work with manufacturers, the last thing they want you to do is collaborate in the open (or they would be publishing their protocols themselves).
The Python tool started mostly as a personal need and proof of concept. I know at least one iOS (closed-source, proprietary and paid-for) app used the protocol documentation I produced (at https://github.com/Flameeyes/glucometer-protocols) to support more devices, and they even contributed corrections and further details.
I know of at least three other protocols that have been reversed and documented, partially or fully. I have asked at least one of them if they had interest in adding the documentation to that repository but I have been told by the author they didn’t have time/interest. Another one didn’t reply, and the last one I have not contacted yet.
I really want to separate the idea of being able to access the data from the having the data itself available, first of all. But I also don’t have particular care to have a web app to store that data. Unless my doctor was to run his own instance of whichever open-source app, that’s not really useful to me, I’d say.
(Also as a note, I don’t have Type 1, so Tidepool itself declares me as not their target user.)
I was contacted by members of Tidepool that pointed out I was incorrect in the openness of the source code from Tidepool, they have indeed released their uploader tool and the meters’ access code.
Unfortunately it appears I was right at least regarding the fact that working with manufacturers mean you don’t get to publish clear protocol documentation the way I have been doing. I’ll spend some time trying to reverse engineer the drivers code (in JavaScript) into a description of the protocol, so I can implement it on my own tool and keep it document for posterity.
All in all, i’ll have to look deeper in Tidepool, so thank you Anders for pointing me at them!
Optical Based Noninvasive Glucose Monitoring Sensor Prototype
http://ieeexplore.ieee.org/document/7782291/