Microformats and blood glucose readings
I don't know how many of you have done anything with microformats. These turn out to be a very useful way to represent data such that it can moved around from one piece of software to another. Current there are micoformats for calendar events, people and their contact information, and other useful items.Over the years I've used about 4 different meters from various companies (OneTouch, FreeStyle, Ames, BD), and one thing I've noticed is that the data format that these meters use to return their data is not described so folks can take advantage of it. And where you can glean the format, it's not uniform across meters.
Now think about this. All readings have a Date/Time and a value (mmol/L or mg/dL). Then some meters also return additional information (before/after meal designations, health information, etc.).
So why not define a standard format for this data and then try to persuade the manufacturers to conform to this format? Once the format is agreed upon it will get much easier to develop standard charting and tracking software and transfer readings from package to package.
Now I've done some Google searches for things like microformat diabetes and so far I don't see anyone else working on this problem.
So gentle reader, your homework assignment is this. Please let me know if you're aware of anyone who is tackling this, or if you're interested in working on developing and publicizing such a standard.
posted by Bernard @ 2:01 PM
5 Comments:
I agree - very frustrating indeed!
Why do the companies all feel like they need to do it their own way!?
Especially when there are so many standards out there that could so easily be adapted - as you say, the information is not complicated!
Scott
I think it's never been done because no-one has asked for it.
Imagine the kind of software things that might happen if you could easily transfer readings between software regardless of the meter that it came from.
So now, I'm asking. Please feel free to spread the word.
Like back in the BBS days about various modem and file transfer protocols, we always said, "The nice thing about standards is that there are so many to choose from!" ;-)
The work I've done with HL7 versions 2 and 3 deals with sending lab results between computer systems in a flat-file and XML format, respectively. This is the "standard" that physical institutions use to exchange health data such as lab results (glucose values).
However, like Bernard said, it would be nice if meter manufacturers would agree on the same format, but they will never do that until the consumer drives that as a requirement. Right now, there are too many meters and too many companies doing it to agree on anything.
To start a standard, we would probably do something similar to an RFC document (in engineering terms), or if we're just talking about about creating a common data format (not mentioning how the format is transmitted electronically), perhaps some other working group committee. A few years ago, I saw a group of students attempt to create an XML standard, but my current Google search failed to recall who was trying to do it.
We'd need to leave it open enough to consider events such as medication/insulin doses, exercise, sickness notes, food consumption (with various attributes assigned to each), too. You know, things that log those sort of diabetes and life "events." Like the Onetouch Ultrasmart[2] meter, where those kind of events can be logged.
If anyone wants to work on it, I'll certainly sit at a desk to help, but I feel as though we need industry involvement to improve the chance that it would be adopted, rather than an exercise in creating yet another standard to choose from. ;-) I wish we had more industry involvement in the d-community.
It's never been done because that does not support the business model of the current manufacturers of blood glucose meters. It's also driven by fear of litigation in a highly regulated medical device industry that requires compliance with federal guidelines for software development including 510(k)'s, Investigational Device Exemption, CFR21 Part 11, etc...
There was an attempt a few years ago which ultimately did not deliver (CIC - connectivity industry consortium i think).
Diabetech has spent the past several years working across these non-standard interfaces to develop intensive management protocols incorporating real-time data collection, analysis and interventions.
The good news is that several of the meters do have published interfaces although not the newer ones. Even so, meters like the Ultra with a published API will likely remain in the market for several years to come.
I think Diabetech has helped pave the way toward industry supporting novel uses of the data. Unfortunately, that means public access will most likely be even further restricted now that it's been proven that monetizing use of the data beyond the meter is a reality.
In our case as a small company, we really don't have the resources to support a developer community and keep in mind those regulatory limitations. That said, the developer community is free to develop its own analytics based on devices with a published API.
In my opinion, the meter isn't the important part - that's a commodity. However, using technology to deliver outcomes is really the most important part and if you can deliver outcomes limited to a specific device then people will switch devices because of the outcomes now possible.
That's my story and I'm sticking to it...
Have you seen HL7 (Health Level 7)? HL7 is both an organization (a non-profit SDO, or "Standards Developing Organization") that has been accredited by the American National Standards Institute (ANSI) to develop standards for clinical and administrative healthcare data, and a standard--really a whole pile of standards that together comprise the HL7 standard. The website is hl7.org
The list of standards already approved by ANSI is already quite large. Talking about the latest version of the standard the site says here that "the initial release of Version 3 will use only XML encoding."
It's a big standard, and my uninformed first impression is that it provides the difficulties in human readability that XML is infamous for, but probably works great in software. ANSI claimed in 2002 (according to the book Patient Safety: Achieving a New Standard for Care,p 133, Aspden, Corrigan, Wolcott, Erickson, Eds., National Academies Press, 2004)that 90% of US hospitals had adopted the standard. I have no info on depth and breadth of adoption.
Post a Comment
Links to this post:
Create a Link
<< Home