suspends in carelink do not show up in blip

[cmakler]

William suspended his pump twice last night, first from around 6:30-7:00pm and then from around 7:45-8:00pm. Neither shows up in Blip, but both show up in CareLink.

[cheddar]

What should happen on suspend?

[cheddar]

@HowardLook @skrugman @brandonarbiter Just pinging you guys. I need to know what should happen when a suspend occurs in order to know how to handle this.

[cmakler]

I believe that showing it as the equivalent of a 0% temp basal would be an acceptable short-term solution, but that’s my opinion.

On Apr 28, 2014, at 12:48 PM, cheddar notifications@github.com wrote:

@HowardLook @skrugman @brandonarbiter Just pinging you guys. I need to know what should happen when a suspend occurs in order to know how to handle this.

— Reply to this email directly or view it on GitHub.

[cmakler]

This is what it looks like in Carelink:

Sent from my iPhone

On Apr 28, 2014, at 12:48 PM, cheddar notifications@github.com wrote:

@HowardLook @skrugman @brandonarbiter Just pinging you guys. I need to know what should happen when a suspend occurs in order to know how to handle this.

— Reply to this email directly or view it on GitHub.

[cheddar]

@cmakler Whatever you did from your phone, it didn't work...

[jebeck]

What would the long-term be? The value of a suspend is 0.0 U/hr, that seems perfectly accurate to me. Were you envisioning an additional annotation of a suspend event, @cmakler?

[cmakler]

@jebeck my hypothesis is that it's fine in the long term as well, since a suspend is functionally equivalent to a 0% temp basal. However, the reasons for a suspend and a temp basal may be different, so I'd want to understand all potential use cases before jumping to a long-term solution. (for example, consider a suspend initiated by the Enlite CGM...We might want to annotate that differently from a 0% temp basal, and a manual suspend)

[cheddar]

Are there any other functionalities of the pump that are also affected by a suspend?

[jebeck]

Yes, @cheddar although these will have to be verified by an actualfax MedT user, since I am not one. For Animas pumps, extended boluses are terminated (and not resumed) during a suspend; same for temp basals. MedT users weigh in? @HowardLook @brandonarbiter?

[cheddar]

Ok, I was trying to figure out if I should convert the suspend into a "temp" basal type thing or if the viz should handle this and I'm now thinking that it probably makes the most sense to expose the suspend as another event stream type and let the visualization decide what to do with it.

@jebeck do you agree with that? If so, this is largely gonna become your problem...

[jebeck]

Hmm, I don't know. I was definitely imagining "deliveryType": "temp" and just maybe a separate "subType": "suspend" analogous to the subType field we have for boluses.

The advantage of treating it as a temp of 0.0 is that segmentutil won't need to be modified. On the other hand, giving it a new deliveryType requires changes to segmentutil, no?

[cheddar]

Yeah, I was imagining the former as well. But, if it potentially needs to terminate extended boluses, then it seems like the effects of it are much more global. I'm thinking of something like

{ type: 'deviceMeta',
  subType: 'status',
  value: 'suspend' }

{ type: 'deviceMeta',
  subType: 'status',
  value: 'resume' }

or something similar...

[jebeck]

Ah, yes, that makes sense. As long as it is easy to generate a segment/duration from the deviceMeta events, then tideline's preprocess plugin should be able to generate a temp basal event to play nicely with segmentutil, and we can have our cake and eat it too ;)

FYI, there are implications for stats widget here too in favor of treating them as temps at some stage. The requirement is that the suspend end up as part of the actuals stream after going through segmentutil, because the actuals stream is what basalutil uses to calculate basal stats for the widget.

[kentquirk]

I'm putting in my vote for having separate events; if we can know something specific is happening, we should record it. If the visualization treats it the same as a temp basal, that's one thing -- but the data stream should have it as an identifiable separate event.

On Mon, Apr 28, 2014 at 4:09 PM, Jana Beck notifications@github.com wrote:

Ah, yes, that makes sense. As long as it is easy to generate a segment/duration from the deviceMeta events, then tideline's preprocess plugin should be able to generate a temp basal event to play nicely with segmentutil, and we can have our cake and eat it too ;)

FYI, there are implications for stats widget here too in favor of treating them as temps at some stage. The requirement is that the suspend end up as part of the actuals stream after going through segmentutil, because the actuals stream is what basalutil uses to calculate basal stats for the widget.

— Reply to this email directly or view it on GitHubhttps://github.com/tidepool-org/hub/issues/34#issuecomment-41625483 .

Kent Quirk VP of Engineering, Tidepool

Tidepool is an open source, not-for-profit effort to build an open data platform and better applications to reduce the burden of Type 1 Diabetes.

[cheddar]

Ok, the format I'm taking for handling this is

{
  type: "deviceMeta",
  subType: "status",
  status: "suspended"/"resume",
  deviceTime: TS,
  deviceId: "deviceId",
  joinKey: "id_of_suspended_event" // exists on events that refer back to another status event (i.e. resume)
}

Note, there will be an edge case with this. I'm am going to write it up in the notes about Carelink data now.

[cheddar]

Comments added at

https://github.com/tidepool-org/hub/blob/master/medtronic/carelinkIssues.md#resume-events-do-not-reference-their-corresponding-suspend

@HowardLook @jebeck @kentquirk @cmakler Please verify that the explanation of the corner case makes sense and that you agree with the method of processing. If you want to see an example of what Carelink is doing, check out Howard's data on 04/06 and 12/19 (look at the Daily Summary as well as a data table)

[cheddar]

I had the wrong link, so I just edited the comment. If you follow the link from email, scroll up.

[jebeck]

LGTM, @cheddar. Are you also working on the implications for e.g., extended boluses and temp basals (if those have been confirmed by actual MedT users)? Or do we need to add a separate ticket for those and release note the fact that we're not including those implications yet?

FWIW, I'm not sure how we should visualize the former.

[kentquirk]

Dang, I love that document. Thanks.

[cmakler]

LGTM too.

[cheddar]

@jebeck, I am not working on those implications. My intent was simply to do the parsing side of it for now (or, actually, probably tomorrow, I'm not sure how long I'll be around today and there are a few more things to do on the gatekeeper stuff which I want to get done lest it go stale)

[jebeck]

OK, sounds like a separate issue should be opened for investigation and potential implementation of implications then.

[cmakler]

https://trello.com/c/3NsIIGOp

[cheddar]

@cmakler Given that this is in the Completed column on trello, should this be closed? Or is there some other criteria for closing these?

[cmakler]

All I’m doing right now is linking up the Trello cards and the Github issues in both directions, so we link back and forth.

When Github issues are completed I would definitely recommend closing them :) But I would say that’s a decision you or @kentquirk should make.

On May 6, 2014, at 10:58 AM, cheddar notifications@github.com wrote:

@cmakler Given that this is in the Completed column on trello, should this be closed? Or is there some other criteria for closing these?

— Reply to this email directly or view it on GitHub.