Hi all, I know this has some overlap with other discussions on this group.
I’ve been trying for some time to get manufacturers to think about data standards for diabetes data. I wrote a paper (PDF) about this almost two years ago. Please read it because you’ll get some idea of how I’m thinking.
I also started a Diabetes Data wiki where I had hoped people might help with this work. Now I have a suggestion for how you can help in this work.
Last night I added a page about the Cozmo 1800 insulin pump. It gives instructions about how to export data from the Cozmo software and a little information about the data form. It also contains a pointer to an example XML file.
In the next few days I plan to add pages for OneTouch software, Wavesense software and Dexcom software. These are devices and software that I have access to.
Would anyone like to volunteer for other devices? Specifically Insulin Pumps (Animas and Minimed), CGMS (Minimed and Freestyle Navigator) and glucose meters (pick a brand).
For each device give the model number you’re using, the software and directions on how to either export the data, or where the data is stored and how to get to it, and an example of the data file. I will load this information on the Wiki and give full attribution to you. If you feel uncomfortable about putting your data online give it to me and I’ll tweak the values to make it less problematic.
My plan is to propose a data format standard for the following types of information.
Blood glucose measurement
Insulin doses (basal and bolus)
Ketone measurement
I’ll put this on the wiki and look for comments and feedback. If you can think of other things worth tracking let me know. I appreciate all feedback.
Hi Bernard, the free exchange of Diabetes information is very important. This way we can use the software that we like to use for our analysis needs.
I hope that many people will contribute to your project with example data. This way all developers of software will find real life examples in your database.
I will think about your idea to propose a general exchange format for diabetes data…
I will do the Medtronic pump, freestyle lite meter and the one touch meter that comes with medtronic for you. send me a private message and we can discuss the details.
I use the .csv export from Co-Pilot for the Freestyle meters, which are Abbott’s, and save in Excel format. I tried to open the Import/Export document to which you point in your blog, and I keep getting a “document is damaged/cannot open” error.
Fortunately, I was able to find it on Abbott’s site here. It’s listed as CoPilot System Import/Export Guide (English PDF 1.5MB/Spanish PDF 1.5MB) with live links for each language.
I can’t help much with other devices except for repeats (I have OneTouch meters – UltraMini, Ultra2, UltraSmart – and Wavesense meters – Keynote and Presto); the Advocate Duo has no meaningful way to export data (my user-oriented comments are posted here).
It can also be useful to sort data by time of day rather than date or time slot to consider 24-hour trends over a period of time. I found it very roundabout to try with Abbott’s export due to time and date being in the same field. Using Excel and a straight list of time versus glucose measurement, this can be accomplished provided one does not divide the time of day into more than 255 segments. I’ve somewhat simplified the process here.
Bernard, going to Password Sleuth for my Zero-Click backup, I got the exact password you did: nw6oUUWAKQ19B2rP. Looking at the .mdb file, I found over 17000 lines of “readings” from what appear to be test and demo profiles. I also found that the column labeled “Error code” was not populated for the factory readings, but had a default of “0” for most readings. The one test-high reading I ran (balsamic-vinegar contaminant test) showed an error code of “32”. Two other readings had an error code of “2”, but I can’t figure out from my various notes what those related back to.
I should also note the “e-mail reports” option provides a .csv file. The first 18 lines of this file provide the sending-user’s profile. Line 20 is a header line for the remainder of the file. Headings are “#”, “Date”, “Time”, “Value”, and “Comments”. The calibration code is not exported, nor are the Serial Number or any Error Codes. Error code 2 readings are not exported, so those MAY be control-solution readings or other marked readings. The Error Code 32 reading was exported, so I’m presume it’s one of those “hyperglycemic and out of range; check ketones” warnings.
Your idea of creation of standards is good, only thing wrong with it would be usage of such wastetful format, like Microformat. I am developer of one project, fighting with windmills (like meter/pump/cgms manufactures) and I have seen some of meter formats, and more simple they are better they are.
Using xml based format, that has too much data would be pretty hard to enforce especially on simpler devices, like meters, which don’t have any XML creating capabilty… in such cases it would be much simpler to use just simple export of data… For pumps and CGMS it would be nice to use XML, but not in Microformat of way.
So far I have seen two exports from pumps (csv from CareLink and data from SmartPix device for Roche pump), and while SmartPix format has some weird stuff in it, it’s by far much better than csv from carelink.
For simple devices (most of meters fall into this category), I would use simple format, while for Pump and CGMSes XML would be preffered, but not in the way of Microformat.
But since we are all dreaming of what WE would like (and what no diabetes manufacturer will ever do). I call all you “geeks” and geek-wannabes to help with development of my software… . We haven’t started so far with actual reading from pumps or CGMSes, because of all the secrecy, but we have data we can use from exports from either software (Carelink) or hardware (Smart Pix) which can be imported.
While SmartPix reading is a way to go (Since this is primary way the pump communicates with PC), using exports from different software is not intended way for GGC software *, but just temporary solution, until we can read data from pump directly…
Andy
GGC is short name for “my” software. It’s called GNU Gluco Control and is Open Source and written in Java, so it can run almost anywhere. Check it out here: http://ggc.sourceforge.net/
Lets say someone using Java built a cross platform program that went out found the USB cord found the meter accessed and downloaded the reading to excell allowed a previos AC1 result and showed based on (AC1 formula ) your current results show you sprinter towards the next higher number maybe a funny box that says you need to wallk more
To the data format maybe add blood pressure Triglycorides .
Rambling of a mad scientist
I think it is well past the time for the Tower of Babel to fall.
Diabetes is managed through the use of data. That data belongs to the user, the patient. It is theirs. Managing data should not a tool to strengthen a vendors proprietary grip on patients. Sadly patient data is almost universally maintained in proprietary formats guarded for the commercial advantage of durable device manufacturers market share.
I believe this is wrong. I believe it is a detriment to better health individually and for patients as a population. I believe that proprietary data puts a burden of maintaining data management on durable device manufacturers that increases the cost of devices. I believe when heath insurance mandates specific formulary brands and those brands do not share data well the insurance company is reducing the opportunity for better diabetes management to reduce cost.
I think it is time for patients to start asking their medical device manufacturers to open data standards and work towards a common language for diabetes devices. I think in the long run manufacturers’ costs for data management in the long run be reduced by benefiting from shared standards. I would like to see their energy spend on innovative devices not maintaining proprietary data standards. I would like to see patients and their advocate organizations have a voice in data standardization.
If you agree I would love to hear from you. I would love you to share your thoughts. Let start by seeing who all is interested. Bernard has an old thread on the topic at TuDiabetes. If you are interested in some grass roots advocacy on data standards please introduce your self here, like this:
I am Bennet and I am interested in promoting standards.
I really like to think of a diabetes data bus. If this is well-defined and a truly open standard, where anyone can use it, then it might be a basis for future device development.
I’m trying to connect with someone in JDRF to talk about what standard, if any, they’re developing for the Artificial Pancreas project. Because without this, it’s going to be harder to build APs out of different device combinations.
I’ve also tried talking with someone in the FDA about the lack of a standard as a safety issue – I know this is a stretch.
You may also be interested in an old paper(PDF) I published in the Journal of Diabetes Science and Technology. That was four years ago and nothing has really changed since then.
Anyhoo, I am Bernard (or Barnyard, Dranreb, or any other corruption of my name) and I want to help develop and promote these standards.
I’m Jim and I am interested in promoting standards. #databetics
I think this subject was what most disappointed me coming out of the MedtronicDAF this past weekend. While it was great hearing about being able to use CareLink on a MAC, the news about the Mobile App left me wanting more.
Maybe I don’t fully understand the legal issues. Why can’t a mobile app access the CareLink database to display reports / charts on a smartphone? And not just an iPhone. Sorry I’m a PC kind of guy and an Android user.
We are not talking about using the smart phone app to CONTROL the CGM or Pump in any fashion, just talking about getting to the data and viewing the reports already available to us.
I think your last point is important. I’m not sure the companies and the FDA understand the difference between a command that’s sent to a device to control it, and one that merely retrieves the current data. I think we need some sort of enlightenment campaign.
Jim what I understand is that he FDA considers each platform as an extension of the regulated device. Since dosing decisions are made on the information in the programs each has to go through F|DA approval.
It seem batty to me the logical extension is that the pen vs the pencil used to chart BG and dosing would have to be approve.
I think we need to try to find an ear in the FDA and start bending it. Diabetes is truly unique unfortunately the FDA is not motivated by better care they are motivated to avoid being blamed for bad outcomes. Taking no action and preventing action can be played off as being cautious and they cant be blamed form an abundance of caution.
Diabetes is very different from other diseases, since patients play as large of a role (if not much larger) in dosing decisions as our health care professionals do. In fact, we’re fairly unique this way.
At the very least, the FDA needs to define a class of devices and software that allows for the use of data for self management. It’s critical that the hardware and biological assay devices give the “correct” values, and it’s also important that software exports, loads and displays those values correctly. (So I can see the FDA’s oversight interest here.) The FDA should recognize that we already accept a lot of risk when it comes to managing diabetes; some of us are willing to accept a little more, by having complete access to a lot more data, so that we can treat our diseases effectively.
I’m Jeff, and I’m interested in promoting open, accessible data standards for diabetes data.
As far as data formats go, there’s already one huge precedent out there: DICOM, the standard format used in radiology (and ophthalmology and pathology and a growing number of other disciplines) to share data between devices. The standard is open, freely available, and well-maintained. The data is nonproprietary, even though device manufacturers can (and often do) embed some of their “private” data into the files. Any device can read and write DICOM data without approval from any regulatory body, such as the FDA. The usage of the data might be subject to FDA approval, but that’s on the end-user device/app to decide. (Does the device aid in medical decision making? Is it used in R&D or preclinical trials? Does it simply store data as an intermediary? Etc.)
There’s a role for conformance, where manufacturers say what part of the DICOM standard they implement and how they interact with other DICOM-compliant devices. There’s also a role for third-party conformance testing. These companies verify that a DICOM-enabled device actually does what it’s supposed to do. These companies are not the FDA, and I don’t think they have the ability to legally sanction people who incorrectly implement DICOM.
This is basically the model I think we could aim for. As third-party diabetes app developers we agree to read/write data correctly and voluntarily to submit to validation. (That could be as simple as reading a set of test data.) We could thereby provide apps that use the data that the FDA-approved devices produce without risk of corrupting the original data.
I’ve heard of the HL7 standard and Jeff just mentioned the DICOM standard. One problem with both of these standards is that you have to purchase a copy, which is fairly big $$ especially for a startup company. HL7 is definitely the accepted standard in many cases.
Ideally I’d like to define a simple, extensible, standard using an XML file format. I think there’s a small set of record types:
Blood Glucose measurement. Could be used for both meters and CGMs
Medication dosing. Need to cover injectables and tablets.
Health information. Am I sick, under stress, etc.
Exercise information. Type of exercise, duration, intensity,
Any other suggestions for data records that are specifically diabetes related? I’m assuming there are enclosing records for patient information.
Two things. DICOM is freely available. NEMA seems to have given up on the idea of getting people to buy five linear-feet of printed standard and now just provide the “blessed” standard as a PDF every year.
And the other is that we should allow as many of the pump events as possible. I don’t know what they all mean, but I wrote about the data my pump stores recently. I suspect there’s value in having all of that data accessible to app developers.
Oh, and I’m not advocating using DICOM or HL7. Just noting that DICOM provides a model for interoperability and industry-led self-regulation, which doesn’t require much FDA involvement.
I managed to get through. I consider it a challenge when a gate keeper doesn’t let me talk with someone. I a bit of a jerk like that.
Had a nice talk with the communications person who wrote the blog entry (that the operator said didn’t work for ADA. and said he was was a him when she is a her.) She is gonna introduce me to the person at ADA involved with the health vault thing.
Thanks guys for further explaining this stuff. It sometimes get very confusing.
Did the FDA just recently reduce the requirements for devices that “interface” with medical devices? Would this not help speed certain things up?
And its the pump that has the algorithm to adjust dosing, otherwise its us doing the pencil and paper tricks, okay a little help with a calculator. So why the FDA approval for getting to the data? Are you telling my my little USB dongle for CareLink has FDA approval?
