Thursday, September 15, 2016

Diabetes data platforms need competition

I received the recent news of Diasend and Glooko merger with mixed feelings. My main concern is the openness of the joint platform. Will it be possible for other apps to use the data? Ultimately, will it be possible for people with diabetes to upload their data once to a safe location, and then use the apps and gadgets they choose to make sense of that data in a way that best supports their individual goals?


Diasend have discussed opening an API for third party applications and developers for some time now. I have assumed they just lacked resources to make it available (although they never explicitly stated they would make that API open for anyone). Glooko, on the other hand, have never made any promises regarding an API. They do refer to a platform, but that's a much more vague term.

In their take on the news, Tidepool state that they don't consider themselves competitors to Diasend and Glooko. In a way, I'm disappointed. Competition is one of the key driving forces of innovation. We definitely do need that in the diabetes data management market. We need companies, nonprofits, and independent developers competing, for instance with the following:

  • Who will be the first to build an open platform for all the data people with diabetes need to see together?
  • Who will be the first to release a truly universal uploader, supporting all the different hardware we use?
  • Who will create the best developer experience, attracting all the best apps to be connected with the platform?
  • Who will build the best architecture, combining security and privacy features while enabling easy sharing of data between stakeholders.
  • Who will build the best user experience, making it easy to use the above mentioned tools?

We've seen how Nightscout, the open source project lead by independent developers on their free time, has helped commercial vendors bring their products to the market faster. Having the technology out there both validates the need for it and puts pressure on the companies to introduce their own solutions in order to not miss the train. In the case of Nightscout, it also put pressure on the regulator to approve the new commercially available technology in an accelerated procedure.

We do need the same with the diabetes apps ecosystem, with the data management platforms. I do believe that once we see the first platform that really enables upload from the most used glucometers and insulin pumps, and makes that data available for all third party applications, we see a quantum leap of innovation. We see that data actually being used. Used in many ways we currently dream of, and also in ways we cannot yet even imagine. I see the lack of such a platform as the biggest bottleneck of innovation currently.

At Sensotrend, we've from the beginning seen our own offering as a service that runs on Personal Health Record (PHR) platforms. On generic PHRs like Apple's Health and Microsoft's HealthVault, but also on PHRs focused on diabetes. We would really like to see Glooko, Nightscout, and Tidepool becoming such platforms. And we'd like to see them competing on who's the first one!





Friday, September 2, 2016

So long, Sports Tracker

Last week, I had the privilege to attend to the Sports Tracker Innovation Night. The event was targeted to people like me, with a CTO role in startup companies, or something close to that. I went there with great expectations. Is this the moment they finally open their API?

The first time I asked Sports Tracker for an API to access some of the exercise data was at Slush 2013, almost three years ago. I could hear from the answer that many other people and companies had asked for that too, and plans are currently being made for making an API available. I’ve repeated the question occasionally since then, and the answer has always been that the API is being planned, designed, or even built.

During the event, it became somewhat evident that an API is not being built. The presentation I saw (there were several presentations running in parallel) was about digital transformation, but mainly presented ideas on how to market and sell more goods to consumers through digital sales channels. The current owner of the Sports Tracker app is Amer group, the owner of many great brands like Atomic, Patagonia, Salomon, Suunto, Wilson, etc. It’s understood that within the group there’s a lot of know-how on how to market and sell goods.

I’m writing this on my way home from the MyData2016 conference. In the conference, there were numerous presentations on how the society is changing, and many on how consumerism is changing, too. People of today don’t want to be sold to. They want to get personalised experiences matching their values, and they want to be involved in creating value on initiatives and activities that matter to them. I see this as a really welcome development, and really want to believe in it.

Almost all other sports and wellness apps have already understood and are embracing the API ecosystems. When you expose access to data through publicly available interfaces, you no longer need to worry about offering that personalized experience to each and every different user or user group. The data produced by a sports app may be a key ingredient in something more meaningful, like in an athlete learning to train better or a person with chronic illness being able to manage his condition better. But the sports app cannot produce all the value alone. Especially not to both the athlete, and the chronically ill, and the myriads of other people with different needs, life styles and preferences. On the other hand, the value of the data from that app increases exponentially, when combined with data from a nutrition diary, smart scale, and perhaps medical devices.

Today, building an API should not be a big task. The first step for a wellness app would be to integrate with HealthKIT and Google FIT. In case that’s inconvenient for some reason, the app most likely uses and API already, to communicate with a cloud server. Opening that API for third parties requires little more than an OAuth2 implementation, for which there are plenty of implementations available. Of course, there’s the added cost of documentation and support. To get around that, an alternative is to open the API to aggregators, such as Human API, Validic, W2E, or Wellmo. You can even get the aggregator really interested by making an exclusive offer. It would be more limiting to developers wanting to use the data, but at least there would be a way.

Among Sensotrend’s current users, and among the potential users we have interviewed, Sports Tracker seems to be a really popular application. This may be due to it’s long history, and due to Nokia being so dominant in the Finnish handset market at one point in time, and Sports Tracker being the most highly acclaimed sports app at that time, on that platform. We’ve gotten many requests to support Sports Tracker in our app. This far, we have asked those users to be patient, and wait until the API gets released or the app gets integrated to HealthKit and Google FIT.

From today on, we’re changing that message. It’s evident that an API is not coming in any foreseeable future. People who are interested in seeing their data in our service, or in any other service for that matter, should instead select Endomondo, Strava, Runkeeper, Moves, or almost any other app that gets the value of open APIs.

I’m a long time user of Sports Tracker myself, and changing to another app requires some effort. Just selecting the right one from the ones listed above needs some research. However, the longer I keep using Sports Tracker, the more I feel I’m being left out of opportunities to learn, and to use the data in meaningful ways. And the bigger the effort to transfer the data manually to another platform, if I ever choose to.

It’s supposed to be my data. I should be able to use it in the ways I want to.


Wednesday, January 6, 2016

Frustration with Enlite

I just disabled all alarms and the SmartGuard feature of the pump.

I have great trouble getting the Enlite sensor to be accurate. Maybe it's just me, maybe the sensor finds my tissue hard to read, maybe I'm not calibrating it right, maybe there was something off in the manufacturing or transportation of the particular batch of sensors. The sensors just keep giving me numbers that are way off from what my glucose meter says.

At 10 am, when I woke up, the pump told me the sensor reads my glucoses at stable 3.8 mmol/l and the SmartGuard feature has been activated to save me from going too low. I did not feel low at all, so checked with the meter. It said 9.9 mmol/l. And 10.4 mmol/l when I measured again. And after washing my hands carefully, still 10.2 mmol/l. The real glucose level was clearly around 10 mmol/l. I dismissed the SmartGuard to resume the insulin flow, and injected some insulin to bring my glucoses down. I did not calibrate at this point, as I was sure the calibration that far from the sensor reading would be rejected by the transmitter. I felt a bit frustrated, as I thought the SmartGuard action of the night was likely the reason for the high level. It may also be that my glucose levels had really been low and then bounced back up due to my liver releasing some glucose into my bloodstream just before I woke up, so the sensor just did not have time to catch the change.

An hour later (at 11:12), just before breakfast, my meter told me I was at 6.9 mmol/l, so I bolused accordingly. Again I did not calibrate, as although the meter reading was now much closer to that of the sensor's (5.2 mmol/l), there was an downward arrow in display, so I knew my glucoses were still dropping, a bad time to calibrate. Shortly after, the pump buzzed and told me that insulin delivery had been stopped again, to save me from going too low. I needed to dismiss the SmartGuard again, as I knew I wasn't that low, and was currently eating, which would rather bring my glucoses up soon. In addition to that, it took me a while to find the amount of bolus insulin that had been injected (only 0.15 units -- the bolus delivery rate of the 640G is really, really slow!), and even longer to find the real amount that should have been injected.

While I can understand the logic the sensor and the pump used, and acknowledge I'm not yet familiar with the menu system and that's why it takes me time to get around and perform some actions, I became frustrated. It felt I was just fighting an enemy, rather than working together to treat me in the best possible way.

I have used the Dexcom G4 CGM for more than a year, on and off. Before that I occasionally got a CGM (either Dexcom or Medtronic one) from my clinic for a week. Throughout this time, I've gotten better results from the Dexcom. 90% of the time, it shows what I expect when calibrating it (that is, within 15% of the reading of my glucose meter). And 90% of the time it's off, it's easy for me to see, in retrospect, the point when it got off the track and also back on track. Either I calibrated when my glucose levels were changing rapidly, or I probably slept on it, causing the so called 'pressure low'.

With the Enlite, I have never gotten the same feeling. I have no idea why it behaves the way it does.

When searching the internet, I find I'm not the only one with these issues. See for instance the end part of this review: http://www.healthline.com/diabetesmine/medtronic-minimed-connect-review.

I also had a short discussion about the issues in Twitter.

Anyway, for a couple of days, at least, I don't let the Enlite sensor interfere with my treatment. I keep wearing the sensor, and keep watching its readings. I hope I can better learn the ways it works, so we can work better together. I already got some advice from both a local representative and a peer support group:
  • Calibrate at least 3 times within first 5 hours after inserting the sensor.
  • Only calibrate, if bg/ISIG is above 0.14 and below 0.44, applies when bg is in mmol/l).
  • Pay attention to the insertion site.
  • Try inserting the sensor first, connecting the transmitter hours later.
I really want to learn to trust the sensor and the system. For me, the SmartGuard feature of the Medtronic Minimed 640G is a really promising step towards an artificial pancreas. A system that would eventually do all the micro management required to control my glucose levels for me. But there's no way I'm giving that responsibility to a system I don't fully trust and understand.


Finally, I ask you to remember that in this blog I share my experiences when and as I face them. I may be totally in love with the system next week.

Monday, January 4, 2016

Will I use the bolus calculator of the Medtronic Minimed 640G?

I have been using the Accu-Chek Spirit Combo pump system for five and a half years. I have been really happy with its bolus calculator feature.

When I first started pumping, I was offered a choice between Accu-Chek, Animas, and Medtronic pumps. I chose the Spirit Combo as it's meter could be used as a remote controller for the pump. This means whenever I measure my blood glucose, I can immediately also dose the right amount of insulin, without having to reach for another device. I still think this is a winning feature.

After having used the system for some time I came to appreciate the embedded bolus calculator too. Without the bolus calculator, I would often get too much insulin when correcting a high blood glucose. For instance, if in the morning my sugars would be high, I'd take some additional insulin for my breakfast bolus, to bring them down. Then I'd measure my blood glucose again in one and a half hours, and see that it's even higher. So I'd inject some more insulin. One and a half hours from that I'd measure again, and find that my sugars are still high, so I'd start to wonder whether there's something wrong with either the insulin or the cannula, but inject some more insulin to make sure. Less than an hour from that, my sugars would come crashing down, and I'd be trembling in an episode of hypoglycemia.

I did not really notice that pattern back then. But the bolus calculator taught me patience. When I'd check my glucose one and a half hours from breakfast, it would tell me "OK, your sugars are still high, but that's to be expected after the breakfast, remember? There are still many units of insulin in effect in your body, the situation is being taken care of." And an hour and a half from that, when I'd be frustrated again, it would remind me that yes, the insulin I have taken to lower the high reading is still working and already bringing the glucoses down, I don't need any extra insulin.

Here the bolus calculator reminds me that I still have 1.2 units of insulin on board to bring that 8.9 mmol/l down to target level, I only need 0.2 units more (added to the 6.9 units I need to cover the 55g of carbs in my meal) to make it perfect. Without that reminder I would most likely be frustrated that the reading is still high and dose some more correcting insulin that would then cause a hypo later on.

The bolus calculator has really helped me to avoid many lows, and to be less frustrated when waiting for the insulin to take effect. I would really like to continue using it.

In the Medtronic 640G, the pump system I'm currently trying out, there is no bolus calculator in the meter. The glucose meter does work as a remote controller, meaning you can set a bolus with it, but when you do that, neither the pump or the meter know how much insulin you took for the meal you were about to eat, and how many units of the total were dosed to correct a high. So after one and a half hours, there's no tool showing you that everything is going on just as planned, no need to panic and adding more insulin to the system does not benefit at all.

This is one of the things I'll be paying attention to when considering the switch. Will I get used to handling two devices (both the meter and the pump)? Or is it just too convenient to set the bolus with the meter? Do I really need the help of the bolus calculator anymore, or have I learned my lesson already and can think things through before stacking a dose after dose of insulin?