Skip to content

Latest commit

 

History

History
74 lines (57 loc) · 3.84 KB

DataFormat.md

File metadata and controls

74 lines (57 loc) · 3.84 KB

Data Format

This is a preliminary summary of the data that needs to be tracked, for now with notes.

##Events

  • Blood Sugar
    • Reading - mmol/L, mg/DL1
    • Time2
    • Source - CGMS, which meter, etc.
    • (Status) - normal (default), flagged3
  • Bolus
    • Time
    • Amount
    • Insulin type
    • Type of bolus - dual wave, square wave, or normal with subfields/attributes for time of extended bolus in minutes and percentage of bolus delivered immediately if dual wave
    • Type of bolus - meal bolus or correction bolus4
  • Meal
    • Time
    • Total Carbs
    • (Components)
      • carbs
      • description
    • (IsEstimate)5
    • (Description)
    • IDREF to Bolus Event6
  • Basal
    • Time (start)
    • Rate
    • Insulin type
    • (Temporary) - boolean
    • (Pattern) - FK Settings ?7
  • HBA1C, Weight, BP, ?8
  • Exercise
    • Time (start) and Time (end)
    • (Activity) - running, cycling, walking, etc.
    • (Intensity) - Light, Moderate, Vigorous 9
    • (OtherStats) - heartrate, calories burned, miles run, etc.
    • (PumpDisconnected) - boolean10
  • Sleep11
    • Time (start) and Time (end)
    • (SleepQuality)

##Insulin Pump Settings

  • //Todo

##Patient Info

  • //Todo

I'm not sure if it is appropriate to have indexes in a microformat, but I think we want some way that comments can map to one or more events without being a property of the event.

Footnotes

  1. Units should be specified in the Patient Info or other metadata header perhaps? ↩

  2. I'd suggest ISO 8601 with offsets from UTC/Z(ulu): YYYY-MM-DDTHH:MM:SS+HH:MM (Python has good support for this. 'T' is the delimiter character between date and time, and timezone offsets are in the +HH:MM suffix, or Z for UTC/Z(ulu).) ↩

  3. The purpose of flagging is to indicate that a blood sugar reading is the result of extenuating circumstances and would not usefully count toward most trend analyses. Things like a high blood sugar because of a forgotten bolus, pump malfunction etc. A large number of these could indicate that specific steps should be taken to try and improve habits. ↩

  4. In my own self-tracking, I also tag correction boluses with either #my_bad or #WTF. I find it useful to keep track of my total #WTF boluses...when their number or percentage of my TDD starts to climb, I know something needs to be adjusted, whereas the #my_bad corrections aren't really relevant since they're usually connected to carb count mishaps. ↩

  5. In my own self-tracking, I tag carbs with three separate indicators of my confidence level in the carb count: #no_clue (usually when I'm eating out), #guesstimating, and #nutrition_facts for when I read it off the label. Overall, I'd argue for making this something more flexible, like an attribute or a tag field, rather than a boolean. I also have an #eating_out tag, for example. ↩

  6. This is in my Platonic ideal of diabetes data formats, to have meals connected by reference to their associated bolus events (and vice versa, meal boluses connected to meals and correction boluses to high BG readings), but current data exports from our pumps, meters, etc. don't provide an easy way to do this. ↩

  7. I don't know what FK settings is... - Foreign Keys. Tracking pump settings is where it gets tricky because they're all potentially different. ↩

  8. HbA1C should have a flag for whether it's one of those instant tests by meter, or a mail-away test, or an actual lab test. ↩

  9. This is a fairly standard measurement of exercise intensity, I think. http://www.mayoclinic.com/health/exercise-intensity/SM00113 ↩

  10. I often disconnect my pump for exercise, and that's probably a good thing to track. --I think in terms of data, this would be technically separate from Exercise. Maybe even just a basal of 0% ↩

  11. I think this could be useful for tracking noctural hypoglycemia. --Agreed! ↩