I started using the Minimed Revel a little over a year ago. Overall, I love it and I have really, really loved Carelink (I went from being world's worst logger to logger extraordinaire thanks to the ability to capture all my info via my pump and upload to Carelink).
But there's something that really bothers me - the lack of a dedicated Carelink iPhone app that would allow me to "log" other information, like kind and duration of exercise, schedule changes, and other things that I know potentially have an impact on my BG. While I can log into carelink via my computer and do this, I really want an iPhone app that allows me to do this "on the go."
Why hasn't Minimed developed this?? It would be so helpful. Do the data management systems for other pumps (Ping, Omnipod, t:slim) offer an iPhone app?
There are three devices I am always guaranteed to have on my person whenever I go - my pump, my BG meter, and my iPhone. I really wish my iPhone could do more with Carelink.
Making a sturdy, useable iPhone app can indeed take a long time. But there's no doubt Medtronic would have the resources to do this either way if they wanted to.
If you use the BolusExpert feature, you do at least get BE/Carbs data into the pump and thereby into Carelink. Apart from that, you can add event markers manually with the pump. There's no free text feature (e.g. Pizza), which perhaps reduces the ability to learn something from the data.
I guess the problem is that Medtronic deliberately do not provide a 3rd party interaction mechanism for Carelink. What would be cool is an opensource carelink. Then we could put whatever data we wanted in there. Bewest - your project on guthub looks absolutely fascinating. Have you heard of the GNU Gluco Control project (http://ggc.sourceforge.net/)? They seem to support some pumps but not Paradigm. If one could get the data in from the pump, move the desktop software into the 'cloud', we would just need a web service to output the charts and we'd be done. I wrote a simple PHP plotter for BG/Carbs/Insulin ages ago when I had to prove my "worthiness" for a pump. Once there was an open interface, anyone could write an iPhone app without restrictions.
Insulaudit is an opensource library to get data from carelink. Medtronic is completely uncooperative and I'm pursuing other options by engaging the FDA and preparing for courts.
https://github.com/bewest/insulaudit Data delayed is data denied. We currently have no ability to independently verify the analysis offered by Medtronic.
I'm working with Andy, the author of GGC to study the protocol in order to provide basic log auditing services, as well as offer create other points of interaction with the data.
Medtronic just called me yesterday to confirm that the only reason I can't have access to the protocol is because they consider it proprietary. Plain and simple.
Good for you. If there's any way I can help (I use a Paradigm Veo 554, with the USB stick and carelink), just let me know. I know some Python, C, but am much better in Java & PHP.
There always have been different solutions. For example the Accu-Check pumps have a long heritage of using an app for the Palm as the assistant for dosage, glucose, activity etc. The calculated dosage is just dialed into the old pumps.
Personally I would prefer to have a rather stupid pump. I would then use my Glucosurfer project to calculate the dosage and dial it in. This way I and my team could invent new ways to analyse data, to calculate the bolus or the IOB. Of course you could already use our Glucosurfer this way. All you need is Android, Windows Phone or pure web access. Sadly we have no expert for iPhone development right now. In its current state the system is not tailored to pumps. We had very little input from the pumping community so far. Maybe you would like to give us your feedback what type of input you are missing.
In general I think that the pumping community is focused on pumps with integrated remote controls like the OmniPod or the Accu-Check combo. The negative aspect is that you have to make compromises with these devices. One does feature the data input you like but the other has the IOB algorithm you would prefer. To get all that in one device is rather unlikely. The manufacturers are very conservative about options because medical devices are highly regulated and options can lead to great liability issues (misconfigurations etc). Thus they tend to offer one algorithm not a bunch of algorithms as would be appropriate for different user profiles. But to me that is the strength of software: being flexible and customizable to the people using it.
If the focus of your question is tight data integration between pumps and apps I have to disappoint you. I can not imagine any manufacturer to take this route. Even if they would like to: the legal issues will not allow it.
Please call/write Medtronic and demand access to the protocol so that you can independently audit your medical records.
How about Coffeescript/Javascript? I've been considering porting it to javascript or ruby. Insulaudit is currently in python, but lots of people seem to like java. I think it'd be nice to have a java version that can share test suites with my python version, and potentially even use try using jython to get bits to work together. Doing a java version would be a rather novel thing for me. For now, doing it in a completely different language helps stem claims against proprietary nonsense.
FWIW, we currently know how to download data from the pump, but do not know how to decode the historical data. I've tried to make this accessible as a puzzle using a toy python decoder: https://github.com/bewest/insulaudit/blob/master/pcap/andy/zero.py so any help at all is welcome there.
I often use your glucosurfer project as the kind of evidence I'm hoping to obtain from my pump's logs, Holger. Thank you for your excellent work.
The problem is not a technical one, but an epistemic one. If we can't independently reproduce the observations of business associates in our clinical loop then we lack the epistemic tools needed to safely engage therapy, and we've stopped using science as the basis for therapy.
What are the legal issues, exactly? In all my talks with the FDA and vendors no one has ever mentioned legal issues. The only discussion is on how much the vendor can claim is proprietary versus what belongs to me. I feel fairly confident that either side would have mentioned legal issues if it were in fact an issue.
The FDA posts guidelines that vendors "should" document communication methods used by the device to transmit data. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm206153.htm """Pump log
A communication interface, including network components and interfaces to other devices and systems
You should describe any communication between your device and a hospital information management system or another device.
You should describe the principle of operation of the infusion pump (i.e., the scientific principles behind how the device achieves its intended use).
You should describe the user interface components of the pump, including keypads, control menus, data entry screens, displays, indicator lights, alarms, auditory and tactile feedback, infusion sets, cassettes, free-flow prevention mechanisms, tubing, latches, doors or other components of the physical pump that may be manipulated.
You should identify and describe all patient interface accessories (e.g., infusion sets or cassettes, bolus buttons, wireless controllers)."""
They have failed to do this because "should" fails to compel them to make accessible anything they can keep proprietary. The WSJ article is really illuminating.
In Germany and the EU there are very explicit regulations for medical devices and I expect this is also true for the US. One example is the Medical Product Act. Look at ยง4 Prohibitions to ensure the protection of patients.
I have talked to Manufacturers at medical fairs about this issue and they agreed that they can not be as innovative as our Glucourfer project because of the legal restrictions. For example in our Glucosurfer we calculate the average glucose for every minute of the day. This is only possible by connecting the measurements and calculating the values along the line. The linearization is not the real glucose but by taking huge amounts of data it can still offer useful information. More useful than taking four measurements and calculating the average of these single events. This is because the length of influence plays a role in our model. The model assumes that a high number in the morning will lead to higher numbers at night (by linear connecting the last measurement with the morning measurement). Thus it has more impact than a shorter high after a meal. However this type of assumption driven data processing is already too far for a manufacturer of a medical device.
Another example are graphs that need more explanation to be understood by the audience. Our graph for the comparison of days has been criticised for this by the manufacturer audience. Here you can also see the tendency to keep things very simple to get around liability issues.
Actually I do not expect that this will change. However I do hope that pumps will get more modular. I would be great if the control module could be removed for example. This way the manufacturer could sell the pump under all the given restrictions. At our own risk we could then exchange the control module with our own module. For example a module that is controlled by an ordinary smartphone. With a standardized interface from the control module to the pump motors and sensors we could develop control modules for all pump models. Of course this will not happen but at least we could ask the industry to develop pumps for this purpose - to get the control back...
Turns out the FDA actually recommends they should make these details available in line with independently reporting observations. The vendors decline to comply with these guidelines by arguing that the analysis is not created or stored except on their off-site servers, out of FDA purview. See section 4. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm206153.htm
The control module on board is more or less irrelevant, I agree with you on that point, but there is no need for an either-or choice. They can use any control module as long as I retain the ability to independently reproduce their analysis and access the primitive pump with full control. This would restore the equivalent access we had using syringes.
