Restarting the Diabetes Data Standards Project

Replies to This Discussion

Permalink Reply by Holger Schmeken on March 9, 2009 at 1:03pm

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...

▶ Reply to This

Permalink Reply by Mommy and the monkeys on March 9, 2009 at 1:12pm

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.

▶ Reply to This

Permalink Reply by tmana on March 10, 2009 at 8:01am

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.

▶ Reply to This

Permalink Reply by tmana on March 10, 2009 at 2:27pm

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.

▶ Reply to This

Permalink Reply by tmana on March 10, 2009 at 3:04pm

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.

▶ Reply to This

Permalink Reply by AndyRozman on March 24, 2009 at 8:44am

Hi Bernard !

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/

▶ Reply to This

Permalink Reply by Joe on November 1, 2009 at 2:13pm

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

▶ Reply to This