Device event subType: alarm

Jump to...(notable fields on this type)

NB: All fields are required unless otherwise noted.

Jump to example JSON:

type

[ingestion, storage, client] The string deviceEvent.

QUICK SUMMARY
Required:
    jellyfish: yes
    platform: yes

subType

[ingestion, storage, client] The string alarm.

QUICK SUMMARY
Required:
    jellyfish: yes
    platform: yes

The alarm sub-type of deviceEvent describes alerts and alarms that are surfaced to the user by insulin pumps and continuous glucose monitors.

alarmType

[ingestion, storage, client] String value encoding the type of alarm, with other as the catch-all/default category.

QUICK SUMMARY
Required:
    jellyfish: yes
    platform: yes
Range: Must be one of:
    `low_insulin`
    `no_insulin`
    `low_power`
    `no_power`
    `occlusion`
    `no_delivery`
    `auto_off`
    `over_limit`
    `other`

The alarmTypes built into the data model are all and only those alarms that are common to most, perhaps all, insulin pumps or continuous glucose monitors. At present, we have only modeled the set of alarms for insulin pumps, and this list is:

  • low_insulin for low insulin reservoir alerts and alarms
  • no_insulin for empty insulin reservoir alarms
  • low_power for low battery or alerts and alarms
  • no_power for dead battery alarms
  • occlusion for alarms regarding the blockage of insulin infusion lines or sites
  • no_delivery for 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
  • auto_off for when an insulin pump stops all insulin delivery due to inactivity for a duration over the user's programmed threshold, if any
  • over_limit for when insulin delivery has surpassed any of a user's programmed maximum bolus, basal, or hourly delivery thresholds

Many if not all alarm events will include payload object with more information about the alarm that is device-specific. For example, a low_insulin alarm may have a units_left field in its payload to record the number of units of insulin that were remaining in the insulin pump's reservoir at the time of the alarm.

In addition, a payload object is required when alarmType is other, which is the alarmType value used to capture all alarms that are device-specific. 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.

On some pumps no_delivery may include all stoppages of delivery. That is, it may not always be possible to distinguish between empty reservoirs and occlusions.

For some devices, an alarm event (e.g., an occlusion alarm) is the only indication of a suspension of insulin delivery. In such a case, a status event should also be uploaded to the platform and should be included (in its entirety) in the status field of the alarm event.

status

This field is optional.

[ingestion] The status event logically connected with this event, or—for the legacy jellyfish data ingestion service only—optionally the id of the status event instead of the event itself.

[storage, client] The id of the status event logically connected with this event.

QUICK SUMMARY
Required:
    jellyfish: no (optional)
    platform: no (optional)

Some alarmTypes are correlated with a stoppage of insulin delivery. Specifically, we assume that all of the following alarms correspond to a period of no insulin delivery on the insulin pump—that is, a period of time when the pump's delivery status is "suspended":

  • no_insulin
  • no_power
  • occlusion
  • no_delivery
  • auto_off

Some insulin pumps do include in their data protocols a separate indication of this stoppage of insulin delivery elsewhere than just the alarm event. Some 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.). In order to provide an audit trail of the user's processed and standardized data, we then embed this status event in the originating alarm to preserve the close connection between the events.

See linking events for additional details regarding inter-event linking in the Tidepool platform.

clockDriftOffset

See common fields.

conversionOffset

See common fields.

deviceId

See common fields.

deviceTime

See common fields.

time

See common fields.

timezoneOffset

See common fields.

uploadId

See common fields.

_active

See common fields.

_groupId

See common fields.

_schemaVersion

See common fields.

_version

See common fields.

createdTime

See common fields.

guid

See common fields.

id

See common fields.

example (client)

{
    "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"
}

example (ingestion)

{
    "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"
}

example (storage)

{
    "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"
}

results matching ""

    No results matching ""