Data exchange between different applications is simplified with the format called xml. There is less room for interpretation because the data and its type can be described in a very exact form. This helps to analyse the data in the way it has been intended by the manufacturer.
However, today I have learned that this is just a theory if the basics of xml and its purpose are not well understood by the design team. Just look at the following two rows of G4 xml data:
The first is from a patient A measuring in mmol/l. The second is from patient B measuring in mg/dl. How on earth should any application processing that data decide which format to choose? In the current form this solution to take Value for both scales is prone to errors.
A professional design team would have added something like a Scale property. Why is it so hard to export it correctly like this?
Dexcom! This needs to be addressed ASAP! In the mean time we have to take the floating point as an indicator for mmol/l. We have the year 2013 and xml exists for a long time now. Still we are forced to make bold assumptions about the data because of poor design decisions or poorly skilled development teams. Aaaargh!!!!
That's all a bit "over my head," but still interesting and thank you for sharing. (Sorry, I am definately NOT a techi). Only been on my G4 about 4 weeks, but so far it is extreamly accurate. What I don't like about it is: it hurts to insert (can't they make it with a spring type devise so you don't have to manually "stab" yourself? - psychologically difficult for me) and also unhappy with fact that it DOES NOT STICK! Have to use medical tape and water-proof band-aids to keep it put. Also, the alarm is not loud enough, I have twice already slept through it alarming me to a low, thankfully it woke my husband.
In the Dexcom Studio you will find an option to export your data. This allows you to write all the data to an xml file. The nice thing about these files is that you can just open them with notepad or some other editor for text. Looking more closely you will see that your measurements are actually in there. They are just represented in a more formal way to make them accessible for other applications too.
Not sure if this helps, but I've used the tab delimited format (maybe it was comma delimited) from the G4 with success. It opens in Excel 2007 or newer perfectly.
Oh, yes, clearly this XML generated by the device is too simple.
The time units need to be clearly quantified, with an XML structure to explain to those unfamiliar with time, the hour, minutes, seconds, month, day, year.
And yes, of course, we must also specify that the time was measured on earth. So add XML to specify the local cluster of galaxies, our galaxy, Sol, Earth. And let's add some XML to give the details of earth's orbital path.
Don't forget XML for the molecular structure of glucose. Suggest "Chemical Markup Language".
At this point, an XML file with a day's worth of bg data will be approaching 500 Megabytes, and that's entirely more typical of stressful XML as used in the real world :-)
The time and date is not problematic at all because it follows ISO standards. Your statement is clearly indicating that you do not follow my argument. It takes so little efford to just put an indicator for the scale of the glucose and carbs into the header. Do you find it appropriate that one of the market leaders does not care about internationalization and correct data processing?
The first row in CSV files is very important. It explains what data can be found in every column. If the name for the glucose column is just named "value" you can not be sure what scale the data in this column has. Is it mg/dl or mmol/l? In addition manufacturers do change the number of columns in CSV files. Sometimes they do even change the naming of the column. Medtronic has done that for example. So in general CSV is the most unreliable format for data exchange.
Holger - I support your analysis and judgment here. It brings up an even larger issue that we need to be concerned about. That is the standardization of data and a reports for any person or medical professional to easily read.
It seems that each medical device company wants to design only with their needs in mind. They function in isolating silos and don't seem to consider that people like us may want to use the data so that we can make important treatment decisions.
I've read that many manufacturers build EKG machines but they all produce a standardized report that is familiar to any doctor. Why can't we require that insulin pumps, BG meters, CGM's, and even exercise monitors output data that can easily be integrated and result in a comprehensive report that actually helps us see what direction we need to take?
Perhaps the move to electronic records will force the various companies to agree on some simple standards so the data can be reliably read and aggregated.
Does the FDA have to OK any changes to the code of a medical device?
They will never get everyone on the same system it seems. Everyone is indignant about it.
However ther is no way I would ever think my glucose was 7,1 mg/ dl so it should be pretty easy to figure out which scale is used. I agree there there could be something written to make it clear. Usually these companies over do it not underdo it as they have done here. I need to get a new CGM I'm seriously thinking about switching back to dexcom. I had the Dex years ago, and I use MM sensors now, but I think the technology is superior with dex.
Applications processing that data have to assume that a decimal point is always an indicator for mmol/l. They also need to rely on the Dexcom Studio that "7" will always be exported as "7.0" - even for newer releases of the software coming in the future. It is just sad.
The application should choose if there is a decimal point in the value. It's not ideal but it would be a valid workaround. I haven't read the dexcom documentation but you will probably find that maximum mmol/l < minimum mg/dl so it would be an additional method of validation.
Folks, this is/was my business for the last 30 years or so. The simple truth is that Holger is absolutely correct - this is a basic code design blunder. XML is a standard. There are also standards like I18 which allow easy localization (proper date formats, sort ing order, number formating -for example a decimal point is not always a "decimal point." This is just shoddy work (in my humble opinion).
I'm just cautioning you not to go down the "Slippery slope" of XML markup to the extreme it is often done. A huge chunk of that slippery slope is internationalization but once you start sliding downhill, next thing you know what was a simple list of times and numbers becomes a 500 Mbyte file.
It's easy to go down that slippery slope but I advise you to not even take the first step. The data you need is already there in the file.
Thanks for supporting my view. Today I analyzed the G4 file further and discovered that they even changed the naming of XML objects. Although they still contain the same data:
This means all applications that have learned to import Dexcom data will have to be modified to process the old and the new format. They made this change but missed the chance to improve their format to clarify the scales. This clearly shows that Dexcom does not understand that the focus of the export is reliable data exchange. It is like a contract you should only break to make it better. After shoddy comes shoddier I suppose.
I know time flies but you haven't been doing XML for 30 years. 30 years ago it was that horrid thing called EDI. I still have nightmares about that and COBOL.
XML is a standard, poorly designed stuff is a standard too. I think the output probably complies with both standards.
It could be done better but it really isn't a critical thing that they must fix now or else. You can work with the data I even pointed out a very simple method above that works. Do whatever you want "properly". Even if you send off documentation it's highly unlikely it will go anywhere but into the first level tech support's trashcan.
But back then you and your colleagues put much thought into things before you implemented that stuff. Today the export to xml with tools like c#, java or go is just a no-brainer. The more I held them responsible for their careless design decisions and name changes. Of course we can compensate by taking the floating point and comma as an indicator that the value is intended to represent mmol/l. Of course we can now handle SensorReadings and GlucoseReadings. It is just a mess to work with. In comparison with the horrible CSV files from Medtronic they are gold I have to admit.
Should have been more precise - you're right we began playing with xml in 1997. But I have been writing & and (when I got older/dumber) managing teams and companies enterprise-level scientific software for that long :-).
I'll stop before we turn this into an "old software engineer's" thread.
Integrating the properties ScaleGlucose and ScaleCarbs into the header would be sufficient and space consuming. Devices must be fixed in their glucose scale. The fixing of the carb scale for all the coming data might be problematic because this scale might be adjustable for the user. Actually I was a bit surprised to see Carb data coming from the Dexcom G4. Obviously something you can enter manually.
