An array of annotations.
An array of associations for the resource.
Clock drift offset, expressed as milliseconds.
Conversion offset, expressed as milliseconds.
String representation of a Tidepool User ID. Old style IDs are 10-digit strings consisting of only hexadeximcal digits. New style IDs are 36-digit UUID v4
String representation of a Tidepool User ID. Old style IDs are 10-digit strings consisting of only hexadeximcal digits. New style IDs are 36-digit UUID v4
Globally unique to device and repeatable with each upload, e.g. device make and model with serial number
Revision history of the event
Location information associated with the resource. One or both of name
and gps
must be specified.
String representation of a Tidepool User ID. Old style IDs are 10-digit strings consisting of only hexadeximcal digits. New style IDs are 36-digit UUID v4
An array of 1 to 100 notes.
External origin information for the source of the resource.
Grab bag field for data that isn't yet part of the data model. The maximum size is 4K bytes.
An array of tags.
A string timezone name from the IANA timezone database
Time zone offset, expressed as positive or negative number of minutes from UTC.
Data type
An upload identifier; this field should be the uploadId of the corresponding upload record
String value encoding the type of alarm, with other
as the catch-all/default category.
The id
of the status event logically connected with this event.
A string ID. Added to each event during data processing in the Tidepool Uploader or upon ingestion by the platform data ingestion service.
The alarm sub-type describes alerts and alarms surfaced to the user by insulin pumps and continuous glucose monitors.
The alarm types built into the data model are common alarms to most insulin pumps or continuous glucose monitors. At present, Tidepool has only modeled the set of alarms for insulin pumps:
- Auto off : When an insulin pump stops all insulin delivery due to inactivity for a duration over the user's programmed threshold
- Low insulin : Low insulin reservoir alerts and alarms
- Low power : Low battery alerts and alarms
- No delivery : Alarms signaling any other stoppage of insulin delivery when a more precise cause (such as an occlusion or empty reservoir) is not indicated by the pump
- No insulin : Empty insulin reservoir alarms
- No power : Dead battery alarms
- Occlusion : Alarms regarding blockage of insulin infusion lines or sites
- Over limit : When insulin delivery has surpassed any of a user's programmed maximum bolus, basal, or hourly delivery thresholds
Most alarm events include a "payload" object with more device-specific information about the alarm. For example, a low insulin alarm may have a "units left" field in its payload to record the units of insulin remaining in the pump's reservoir at the time of the alarm.
A payload object is required when the alarm type is "other", which is the alarm type used for all device-specific alarms. For example, a pod expiration alarm is specific to the Insulet OmniPod insulin delivery system. The payload object should include all information that could be relevant to anyone wishing to audit the history and performance of the insulin pump in question.
Some pumps may use the no delivery alarm for all stoppages of delivery and may not distinguish between empty reservoirs and occlusions.
An alarm event may be the only indication of a suspension of insulin delivery in some devices. In such a case, a status event should also be uploaded to Platform and included (in its entirety) in the status field of the alarm event.
Some alarm types are correlated with a stoppage of insulin delivery. Tidepool assumes the following alarms correspond to a period of no insulin delivery on the insulin pump (i.e. the pump's delivery status is suspended):
- Auto off
- No delivery
- No insulin
- No power
- Occlusion
Some insulin pumps include indication of this stoppage both in the alarm event and elsewhere in their data protocols. Other insulin pumps, however, do not separately indicate the change in the pump's insulin delivery status. For such devices, a status event should be fabricated using the relevant information from the alarm event (timestamp, log index, etc.) and then embedded in the originating alarm to preserve the close connection between events. This also provides an audit trail of the user's processed and standardized data.
See linking events for additional details regarding inter-event linking in the Tidepool platform.
{
"type": "deviceEvent",
"subType": "alarm",
"alarmType": "occlusion",
"status": "4907943557f440dfbc12bdef4f85e01c",
"clockDriftOffset": 0,
"conversionOffset": 0,
"deviceId": "DevId0987654321",
"deviceTime": "2018-05-14T18:17:07",
"guid": "e3c82e3d-23ba-4048-9056-7b1b3c5aa4cc",
"id": "d5ed640dd8f74e6cb1a6bff796de3ba2",
"time": "2018-05-14T08:17:07.920Z",
"timezoneOffset": 600,
"uploadId": "SampleUploadId"
}
{
"type": "deviceEvent",
"subType": "alarm",
"alarmType": "low_insulin",
"clockDriftOffset": 0,
"conversionOffset": 0,
"deviceId": "DevId0987654321",
"deviceTime": "2018-05-14T18:17:07",
"time": "2018-05-14T08:17:07.920Z",
"timezoneOffset": 600,
"uploadId": "SampleUploadId"
}
{
"type": "deviceEvent",
"subType": "alarm",
"alarmType": "low_power",
"_active": true,
"_groupId": "abcdef",
"_schemaVersion": 0,
"_version": 0,
"clockDriftOffset": 0,
"conversionOffset": 0,
"createdTime": "2018-05-14T08:17:12.920Z",
"deviceId": "DevId0987654321",
"deviceTime": "2018-05-14T18:17:07",
"guid": "d19fe993-f26e-49d9-ac22-48be650a8e97",
"id": "a74b59b21581466b9d9f60811d327df2",
"time": "2018-05-14T08:17:07.920Z",
"timezoneOffset": 600,
"uploadId": "SampleUploadId"
}