diabetes data standards

[Jana Beck]

I'd like to get in on the diabetes data standards conversation, the beginnings of which are here, right? I plan to fork and contribute my thoughts/additions if that is indeed the right place.

It is high time for me to refactor the code in which I've been bringing together all the data for my visualizations and have it output something cleaner and in a common format (JSON? I don't even know enough about D3 yet to know if that is the typical data source). I admit to having something of a soft spot for XML as a structured data format (and I can write DTDs/schemas if needed), but XML support in various programming languages (including Python) is so poor these days (Python doesn't support XPath 2, for example) that JSON is probably the way to go for an interchange format (setting aside the question of backend databases for now).

Thoughts?

Jana

[Damon Muma]

I'd love to have input on this! I started opendatabetes basically because I wanted to make a diabetes app, but got really stymied on the data modelling aspect of things and was really aware of not wanting to rope ppl into one standard or the other.

JSON seems like the 'way of the future' if there is such a thing as far as vaguely format agnostic formats.. although Benjamin mentioned some things I'm not familiar with.. "git/npm/egg style compilations of data" ?? I'd be curious if that might be something to look at. JSON is certainly lovely.. I was handcoding objects in arrays in objects in it for the first time today at work and that was a bit annoying :p

What I put up in Dataformats.md is a pretty quick and highly incomplete adaptation of what I had as a database structure for the prototype of Sanguine that I built.. the full one is here https://github.com/thedamon/opendatabetes/blob/master/Misc/Database_Map_V1_16.pdf

[Bernard Farrell]

I think one of the best first things we could do is agree on a set of data record types and then agree on the layout for each type.

Does anyone here have experience with database design? I've done this in the past but cannot claim to be any type of expert.

[Anthony Di Franco]

I've done it many times and I am doing it now at work.
Haven't been keeping up with this discussion though: what's desired here, in brief?
Anthony

On Feb 9, 2013 1:36 PM, "Bernard Farrell" <bernard...@gmail.com> wrote:

I think one of the best first things we could do is agree on a set of data record types and then agree on the layout for each type.

Does anyone here have experience with database design? I've done this in the past but cannot claim to be any type of expert.

--
You received this message because you are subscribed to the Google Groups "medevice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to medevice+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jana Beck]

Hi Anthony,

The beginnings of the discussion are in this document. If you're familiar with git, perhaps you could clone the repo, add your comments, and submit a pull request?

Or perhaps it would make sense to move this data standards document into the wiki?

Jana

[Damon Muma]

I also opened up an issue on that repo, with the intention of opening more.. I'm just extremely busy with other things right now so i haven't had the chance to do much.. I'm happy for other people to move the discussion forward.. One of the docs in the opendatabetes/misc folder is a pdf of the database design I used in the prototype version of Sanguine.. I had the help of a database professional, although my opinions of the absolute importance of normalizing absolutely everything to the point that it becomes convoluted and confusing is perhaps not necessary. At any rate that may be useful.

A 'database' is not exactly what we're after. We need a data format that can be represented conveniently in text I would think above all.. though obviously a lot of the same principles of database design would apply to that..

I think I'm going to open a couple more issues before bed in case other wish to weigh in... and Anthony by all means have a look and see what you think. Keep in mind the document Jana linked is not meant to be complete.. I just started putting stuff in there to have a start.. so add what you think needs adding and have a look at some of the notes.

[Benjamin West]

It's in both places.

I was thinking of periodically merging the most useful wiki content into the repo's markdown pages.

As for the format and interoperability, I'd like to see a set of rules for how to treat a git repo as a medical record.  Eg, maybe a package.json type of file to provide a standardized kind of manifest for what data is available. https://npmjs.org/doc/json.html

Other communities have done this to kind of standardize their process for "packaging" sets of source files, and I think it makes sense to "package" a set of well structured text files as a medical record, so long as there is a manifest.  This would lead us towards a kind of git-phr tool, which would 1.) make exchanging the data transport independent, 2.) future proof the data 3.) provide permanent audit trails on all the data available in my medical record.

FWIW, the industry has largely standardized how they will communicate medical records and lab results (using CCR/CCD codes, and a combination of OAUTH/atom/rdf.  See http://wiki.siframework.org/ABBI+PULL+Workgroup+Discussion, http://wiki.siframework.org/ABBI+PUSH+for+Developers+Strawman, http://docs.indivohealth.org/en/v2.0.0/schemas/index.html, http://docs.indivohealth.org/en/v2.0.0/sdm.html and friends )

I'd rather have a bunch of well organized text files, with a suite of tools that can reformat it accordingly.  That way, when I "check in" my latest labs, a suite of "build hooks" can process and re-transmit my data to all the correct places under my control.  For hacking purposes, the github API does a very nice job of this... and even supports private repos.

I've looked into privacy issues for "storage" of medical data, and the "bare" git repos are actually exactly what one wants.

As for data, I'm excited to hear what people  will come up with for dealing with pump histories, not just glucose values.  I am at the point where I want to "export" my dumps for decoding-carelink.  Until I can find some kind of pre-existing "virtual pump" software or a consumer to chart the data, there's not much of a requirement for any particular format: https://github.com/bewest/decoding-carelink

There are lots of projects using git repos as a kind of data-container for an application that knows how to work with many repos, eg gitolite, github, npm, bowers, python's egg/pip.  They all rely on a common way to store a manifest of the data available.  Otherwise, if the git-phr stuff is to crazy for people, we can try taking a stab at Indivo's docs; despite the presence of a "data-pipeline" their framework is more for institutions, than as a personal solution.  For a little more context, the workflow I'm looking to enable looks something like this: https://gist.github.com/bewest/4741016, where run_stick probably records the latest readings, then checks the data in to a [private] github repo.  At that point, any software with keys to my repo is updating my records.

-bewest

Here are a few reasons, I'm big on plain text formats:

* http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages

* http://microformats.org/2006/01/09/tim-bray-on-creating-xml-dialects

[Benjamin West]

I'm guessing the git-phr idea might not make sense to people; I tried advocating it with mPocketHealth(sp?) awhile ago, not sure what they found.

In terms of data modeling, the indivo/smartapp folks have already done quite a bit of work.  What I'm suggesting essentially is coming up with some examples of how to turn the CSV/text files we've been dealing with into our definitions of this type of thing:

http://dev.smartplatforms.org/reference/data_model/#BloodPressure.  So, basically we need BloodGlucose definitions to extend the existing Indivo Data Model.

So what would help immediately is to collect a list of the data and the fields we currently have.

For example, I noticed Jana's dexcom reports several differentiations in the types of time and the type of value displayed, and even though these are "glucose values" the thing measured is interstitial fluid.  So maybe a wiki page to start listing all of fields our software has observed, so we can line them up with new definitions in the Indivo data model.

http://dev.smartplatforms.org/reference/data_model/

There are a couple of advantages to this, since it would allow us to hook in to other existing implementations at clinics, and they also use django + python.

Specifically, we'll need to find CCR/CCD codes for our measurements, or define new codes of our own if none exist, but the lions share of effort here is creating a [wiki] page somewhere with a list of fields and mappings to the terms needed.

-bewest

[Jana Beck]

On Thu, Feb 14, 2013 at 1:32 PM, Benjamin West <bew...@gmail.com> wrote:

I'm guessing the git-phr idea might not make sense to people; I tried advocating it with mPocketHealth(sp?) awhile ago, not sure what they found.

Yeah, you lost me a bit with most of your last e-mail, although to the extent that it also sounds like an implementation discussion (correct me if I'm wrong), it also doesn't really fit into my interests or expertise.

In terms of data modeling, the indivo/smartapp folks have already done quite a bit of work.  What I'm suggesting essentially is coming up with some examples of how to turn the CSV/text files we've been dealing with into our definitions of this type of thing:

http://dev.smartplatforms.org/reference/data_model/#BloodPressure.  So, basically we need BloodGlucose definitions to extend the existing Indivo Data Model.

So what would help immediately is to collect a list of the data and the fields we currently have.

For example, I noticed Jana's dexcom reports several differentiations in the types of time and the type of value displayed, and even though these are "glucose values" the thing measured is interstitial fluid.  So maybe a wiki page to start listing all of fields our software has observed, so we can line them up with new definitions in the Indivo data model.

http://dev.smartplatforms.org/reference/data_model/

I agree, this seems like a good place to start. 

There are a couple of advantages to this, since it would allow us to hook in to other existing implementations at clinics, and they also use django + python.

Specifically, we'll need to find CCR/CCD codes for our measurements,

Does anyone have a good reference for these codes?

Jana

[Anthony Di Franco]

​Looks pretty straightforward.

A question for discussion: Does it mean anything interesting to say that certain kinds of bolus or ​basal rates were commanded, or is it sufficient to simply record dose per unit time?

Communicating intent, or something?

[Benjamin West]

FWIW, the medtronic pumps also encodes why it is undergoing an operation, ie, requested by remote control versus manually pressing pump buttons.

[Jana Beck]

On Monday, March 18, 2013 2:33:20 AM UTC-4, Anthony Di Franco wrote:

​Looks pretty straightforward.

A question for discussion: Does it mean anything interesting to say that certain kinds of bolus or ​basal rates were commanded, or is it sufficient to simply record dose per unit time?

Communicating intent, or something?

I think the "intent" behind the insulin dose is important to record. I was actually shocked (and dismayed) to find out that when I download my bolus logs from the Animas software, there is no record of the specific parameters of a "combo" (= dual or square wave in the MedT parlance) bolus. The fact that a bolus is a "combo" is recorded, and the total dose is there, but not what percentage was delivered up front and the duration of the "wave." So I record these things myself now, with the intent of one day going back and trying to assess whether my parameters for such boluses actually work or not.

And re:bewest's comment, Animas also records how the bolus was programmed (via pump buttons vs. meter remote and also, I believe, whether the "wizard" was used or whether the dose was manually dialed-in); I think this data is worth keeping too.

Jana

[Benjamin West]

Medtronic's binary pump logs do contain these hidden parameters ie unabsorbed components and dual wave... will double check on % up front..., but it's presentation in UI and CSV obscures some of the resolution available in the raw logs.  This is why I often refer to fidelity of care: the CSV conversion is a buggy/lossy process.

In addition, I'm not aware of any standard CCD code for some of these metrics, especially since they appear to be so vendor specific.

-bewest

[Damon Muma]

I have been told that the newer Medtronic pumps record every button press. I know my healthcare team likes to look at stuff like how often I override a bolus wizard recommendation etc.

I do not know very much about how other pumps handle things like that.

I'd be inclined to not worry about codifying that sort of stuff.. but recording it all in some way for posterity might be handy.

[Aleksander Rozman]

Sorry forgot to post this to the list...

Andy

---------- Forwarded message ----------
From: Aleksander Rozman <andy....@gmail.com>
Date: Wed, Mar 20, 2013 at 8:12 AM
Subject: Re: diabetes data standards
To: Damon Muma <dam...@gmail.com>

Actually as far I have seen Minimed pumps don't record every button press, just every succesfull button press (for example start of pump, stop of pump, setting TBR, etc), at least I think so, Benjamin decoded protocol (History data), so perhaps he can shed some light on this...

Andy

[Benjamin West]

That's true, the older models record less information.  I think Damon was referring to newer models.  The newer models I've worked with changed the way they log BG records with bolus wizard... it turns out using the bolus wizard is a good way to co-erce the pump to log other records as well, such as it's internal calculation of on board insulin.

I don't have the newest models, it wouldn't surprise me if they logged each button press.  This would a smaller change for them to make, given the way I believe the firmware works.  The remote control protocol makes no distinction between commands and data, all commands are evaluated using the same model, meaning there's no way to separate auditing and dosing commands.

-bewest