Scott Hanselman

The Promising State of Diabetes Technology in 2016

June 16, '16 Comments [22] Posted in Diabetes | Open Source
Sponsored By

Glucopilot helped PalmPilots users in the 90sI've been a Type 1 Diabetic now for nearly 25 years. The first thing that every techie does once they've been diagnosed with Diabetes is they try to solve the problem with software or hardware. Whatever tool they have, they use that too to "solve their Diabetes." Sometimes it's Excel, sometimes it's writing a whole new system. We can't help ourselves. We see the charts and graphs, we start to understand that this is a solvable problem.

However, innovation in Diabetes technology has two sides. There's the "what can we do within the medical establishment" side, and there's the "what components do I, the actual diabetic, have to work with" side. We are given insulin pumps, glucose meters, and drugs but we aren't involved in the development, which makes sense to a point.

Fifteen years ago (yes, really, 15) I went on a trip with a PalmPilot, OmniSky wireless modem, Blood sugar meter, and insulin pump and quasi-continuously sent my blood glucose numbers back to a server and my doctor. Many many years later I demonstrated on stage at a Microsoft conference (video) how a remote management system like NightScout along with other innovations in IoT are taking these concepts so much further. It's through the work of hundreds of innovators and tinkerers that I think we're on the cusp.

Aside: If you are wholly unfamiliar with how Type 1 Diabetes works, please take a moment and read Diabetes Explanation: The Airplane Analogy. This post pretty clearly explains how blood sugar rises and falls and why fixing this isn't a simple problem.

Four years ago - four years ago this week in fact - I wrote a post called The Sad State of Diabetes Technology in 2012, largely in frustration. It became one of my most popular posts. For some it was a turning point and was called "seminal." For most Diabetics, though, the post said what everyone already thought and already knew. Diabetes sucks deeply, the technology we are given to manage it sucks deeply, and we are pretty much tired of waiting. We've been told a "cure" (or at least, a mostly fool-proof way to manage it) is just 5 years out. I've been told this, personally, every year for the last 25.

Here we are four years after I wrote my angry post and I'm actually feeling like we are on the edge of something big.

I believe that now we are inside a 5 year window of time where we WILL make Type 1 Diabetes MUCH MUCH easier to deal with.

Using this generation diagram from the JDRF, it's totally clear that the open source diabetes community is making Stage 4 happen today.

6 stages of "Artificial Pancreases"

Let's stop and level set for a moment. Here's a generalization of your day if you're not diabetic.

The "Normal Sugared" have it easy.

Here's what a Type 1 diabetic (like me) does:

Diabetics have to constantly manage their sugar, manually

What we need is for the "loop to be closed."

Is a Closed-Loop System for Diabetes Management like a Self-driving Car?

You know how the press just loves to call the Tesla a "Self-driving car?" It's not. I've driven one for over 15 thousand miles. It has two main features and they are both effectively cruise-control. There's the cruise control that slows down when there's a car in front of you, and then there's the "Tesla Auto-Pilot" feature. Amazing, sure, but realistically it's effectively "side to side cruise control." It will keep you in the lanes, usually, to a limit. You can't go to sleep, you shouldn't be texting. You are in charge. This isn't to minimize the amazing work that Tesla has done, but using a closed-loop insulin stages above as a parallel, a Tesla is barely stage 3 or 4.

However, this is still a fantastic innovation and for a diabetic like myself, I *would* like to take my hand off the diabetic wheel as it were, at least for the easy stuff like staying in the lanes on the freeway while going straight. Automatic basal insulin dosing (background insulin dosing) would free my mind up a LOT.

It's possible and it's happening.

What's required for a closed loop?

In order to close the loop, what are the components we need? For this simple exercise please assume that "safely and securely" applies to all of these statements.

  • The ability to tell an insulin pump to deliver insulin
  • The ability to read data from the insulin pump.
  • The ability to read current blood sugar from a continuous glucose meter
  • Some CPU or "brain" where an algorithm or controller lives to coordinate all this.
  • Storage, cloud or otherwise, to keep all this historical data

There are a number of issues to think about, though, if the open source community wants to solve this before the commercial companies do.

  • Most pump manufacturers don't like the idea of remotely controlling them after a series of insulin pump proof of concept "attacks."
    • This means that some systems require the use of an older pump to allow remote control. We, the community, need to encourage pump manufacturers to create pumps that allow secure remote control.
  • Most CGM manufacturers don't publish their specifications or like 3rd party apps or systems talking to their stuff.
    • We, the community, need to encourage manufacturers to create glucose meters that allow secure access to our sugar data. 'Cause it's our data.
  • Universal concern that someone will accidentally hurt or kill themselves or someone else.
  • Where should the "closed loop brain/algorithm" live? The cloud? Your phone? Another CPU in your pocket?

What happened in the Diabetes Technology Ecosystem in the last 4 years to make this possible?

The interesting part about this problem is that there are many ways to solve this. In fact, there are multiple closed loop OSS systems available now. Lots of things have made this possible.

Here's a rough timeline of the Open Diabetes Ecosystem.

  • Insulaudit -  Ben West starts an open source driver to audit medical devices
  • Decoding CareLink -  Driving an insulin pump with Python, Oct 2012
  • Decoding Dexcom - Pulling data off a Dexcom CGM 3 years ago!
  • CGM-Simple-Reader - Using Windows 8 DLLs from Dexcom Studio to get CGM data. Next step was uploading it somewhere!
  • Pebble - Being able to remotely view Nightscout Data on your wrist on a pebble.
  • Nightscout - Remote viewing of glucose data by pulling from a CGM and uploading to a web app. The addition of a REST API (Web API) was the killer that kick started other apps.
  • Parakeet Google App Engine - Gets data from The Parakeet Unit and talks to xDrip over the cell network. "OnStar for diabetes"
  • Nightscout Share Bridge - Takes Dexcom G5 data and copies it over to Nightscout.
  • xDrip - Talk to a CGM without a Receiver. Pulling the signal off the air itself. Can we improve their algorithm ourselves?
  • PingRF - Talking to the Animas Ping Pump via RF
  • OpenAPS - Open Artificial Pancreas System. A platform for building a closed-loop with open tools. There are almost 100 people running their own closed loops, today.
  • Watch Dana Lewis talk about OpenAPS at OSCON this year!
  • RileyLink - A bridge that can talk a Medtronic Pump. Make a the pump's RF programmatically available via Bluetooth
  • Loop - iPhone-based closed loop that uses RileyLink
  • xDripG5 - iOS Framework for talking to Dexcom CGMs over Bluetooth
  • OmniAPS - Talking to an OmniPod Pump

I realize this isn't comprehensive, but the point here is to understand there are dozens of ways to solve this problem. And there are dozens (hundreds?) of excited and capable people ready to make it happen.

Here's the systems that I have. This is my Dexcom G5 on my iPhone showing my blood sugar in near-realtime. Here I can see my sugar, but I have to make my own decisions about dosing.

Dexcom G5 on an iPhone

Here is a Raspberry Pi running OpenAPS. This is the brain. The algorithm runs here. It's talking to my Dexcom, to Nightscout in the cloud, and to my Medtronic Pump via RF via a USB device called a CareLink.

OpenAPS on a Raspberry Pi

Here is OpenAPS again, this time running on an Intel Edison sitting on a SparkFun Block with a battery and a TI C1111 RF transmitter. The Edison is the brain and has Bluetooth. The TI transmitter can replace the CareLink.

IMG_0058

As an alternative to OpenAPS, here is a RileyLink custom board that can also talk to the pump, but doesn't have a brain. There is no algorithm here. Instead, this is a bridge with RF in one hand and Bluetooth in the other. It makes a pump controllable and readable. The brain lives elsewhere.

RileyLink

Here's the RileyLink in a 3D printed case. I can keep it all in my pocket and it will run all day.

RileyLink in a 3D printed case

Here is a build of Loop from Nathan Racklyeft that uses Bluetooth to talk to both my CGM (Glucose Meter) and the Pump via the Riley Link. In this example, the phone is the brain. This is good and bad. You can't really trust your phone to keep stuff running if it also runs Candy Crush AND has a crappy battery. However, if both my Pump AND CGM spoke Bluetooth, we can imagine a world where the brain of my "artificial pancreas" is just an app on my phone. No additional hardware.

Loop puts the brain on your phone

The most important point here is that a LOT of stress could have been avoided if the manufacturers had just created open APIs in the first place.

There's also amazing work happening  in the non-profit space. Howard shared this common on my original "Sad State" Diabetes Post:

Great article, Scott. You've accurately captured the frustration I've felt since my 12 year old daughter was diagnosed with T1D nine months ago. She also wears a pump and CGM and bravely performs the ritual you demonstrate in your video every three days. The technology is so retro it's embarrassing.

Since then, Howard created Tidepool and recently spoke at the White House! On the commercial side, there are lots of players rushing to market. Medtronic may '>'>'>have a hybrid closed loop called the 670g by spring next year although trials move slowly so I'm thinking later or possibly 2018. Lane Desborough from Bigfoot Biomedical has also closed the loop and they are bringing it to market...soon we hope!

For more information, go watch Mark Wilson's talk at D-Data Exchange 2016. It is an excellent 30 minute overview of the ecosystem and a call to action to everyone involved.

Check out this visualization of 6 years of Hacking Diabetes. These are all the projects and commits as folks dump into Open Diabetes Hacking Community.

What's the take away? It's an exciting time. It's happening. It can't be stopped.

More Diabetes Reading


Sponsor: Big thanks to Redgate for sponsoring the feed this week. How do you find & fix your slowest .NET code? Boost the performance of your .NET application with ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Diabetes Technology: Dexcom G5 CGM Review - So much wasted potential

October 13, '15 Comments [56] Posted in Diabetes
Sponsored By

Dexcom G5 for iPhoneAs you may know, I'm a Type 1 Diabetic and have been for well over 20 years. I wear a Medtronic Insulin Pump 24 hours a day and use a Dexcom CGM (Continuous Glucose Meter) to monitor my blood sugar, also 24 hours a day.

This post won't explain how diabetes works to you, so check these posts out (or this video) first if you're not familiar.

Moving from a Dexcom G4 to a Dexcom G5

A CGM (Continuous Glucose Meter) doesn't keep you from pricking your fingers. You'll still do finger sticks in order to calibrate a CGM, at least twice a day.

The Dexcom G4 "with Share" worked like this. There was a small transmitter that is attached to me, and it talks a proprietary RF wireless format to a Receiver and then the Receiver talks Bluetooth LE to your iPhone, like this picture below.

Once the sugar number got to my iPhone it's then optionally uploaded to  the Dexcom Share Cloud. My wife can install the Dexcom Follow application on her iPhone and see my sugar on her phone. She also gets the same notifications and warnings I get.

How the Dexcom G4 system works

When you "upgrade" to the G5 from the G4, you'll likely do what I did. I called Dexcom support to see if I was eligible. They had a US$199 upgrade fee which I paid, and the G5 transmitter showed up a week later. I then called them back to get an "upgrade code" which was a 12 digit unique number (GUID) that I had to enter into their Dexcom Studio application on my Windows machine. I plugged in my Dexcom G4 with Share Receiver to my Windows machine using Microsoft USB and ran the upgrader. I needed that upgrade key. Then about 20 minutes later the G4 receiver (remember it talked RF to the G4 transmitter) is now a G5 and only speaks Bluetooth directly to the Bluetooth-enabled G5 transmitter. That means it works like this now:

How the Dexcom G5 system works

The G5 software that runs on the iPhone can also upload to the same Dexcom Cloud which means my wife's Dexcom Follow app *works unchanged*. This was a relief.

The Good

  • If I forget my Receiver device at home I can still see my sugars on my phone. This is huge if you're someone who didn't want to get a Dexcom CGM simply because you didn't want another device in your pocket. That is no longer a blocker.
    • You can carry and use either or both of them. However, if a family member is "Following" you and needs to see your numbers, only the phone is uploading them.
    • You can calibrate on either device and they'll both stay in sync. This was a nice touch as I was concerned I'd have to treat the iPhone as a "Virtual Receiver" and calibrate on both devices twice. Just calibrate on either device and the other sees it.

 

The Bad

First I want to say that I REALLY appreciate Dexcom, the company, the product, and the people, and I appreciate what you've done for myself and for Diabetics everywhere. The Dexcom sensor technology is unparalleled and a fundamental life changer. I can't imagine living without my CGM and I wholly and completely recommend a Dexcom CGM for ANY and ALL Type 1 Diabetics who want to get a real clear view of what's happening inside your body.

That said, I'm going to be very honest here, so if you work for Dexcom, please take my feedback as what it is. It's firm, crisp, actionable feedback. You should fix these things. They are bad and wrong.

There's no gap filling.

With the G4, if I had the receiver in my pocket but my phone was elsewhere, the phone would "fill the gaps" and load in missed readings that might have happened while the phone and receiver were apart. This doesn't happen anymore and it sucks. Sometimes the phone misses readings and sometimes the receiver misses them and I don't get a complete smooth curve even though the data seems to be available in the ether. As a techie, I'm assuming this means that the new Transmitter has no memory and just yells out the last reading over Bluetooth until a new reading shows up. IMHO it should remember maybe 5 to 10 and sync up gaps when possible. And if the receiver has records the phone doesn't or vice versus, for goodness sake, close the gaps.

IMG_1738

The phone just isn't a reliable receiver.

Remember when I said that having the G5 means you don't need the phone with you all the time? Well, kind of. I'm not sure that's 100% true. Here's 3+ hours of data that was completely missed this morning. The phone was 3 feet from my transmitter at all times, sitting on my night stand. My physical receiver was under my pillow and picked up the whole nights numbers, but the fact is, numbers were missed.

Yes, Bluetooth is a troublesome thing, but my Tile BT devices NEVER lose a connection. My Apple Watch never loses connection. My Microsoft Band doesn't lose connections. My car doesn't lose connections. You get the idea. I don't trust the Dexcom G5 software to use only my phone to view my data. I just can't avoid a lost hour.

Also, it's unclear to me how this data gets over the the iPhone from a software perspective. Is it a background task? Can the Dexcom software get ejected from memory when playing high memory pressure games? I need these answers.

I'd like to have a Dexcom engineer tell me/us that this is a transmitter/phone/software/hardware/radio/whatever problem, but who knows. They must know it's not as reliable as the physical device.

IMG_1735  

The Missed Opportunities

Please, Dexcom Engineer who must be reading this post, read these and explain.

  • There's no Watch app? The Dexcom G4 has an Apple Watch app, but this "upgrade" doesn't include one. Not cool. Don't remove functionality. I don't want to  pick up my iPhone and run an app every time I want to see my sugar. Glance-able data, people. 
    • complications_explained_2xWatch OS2 has the idea of "complications" which are AMAZING. Dexcom needs to let me put my sugar in an active area on my watch screen. To not to do this hurts. It hurts every day as I glance at my numbers hundreds of times a  day.
  • There's a HUGE amount of wasted whitespace in the chart. Huge. Notice that my goal area (the gray area) is less than 10% of my screen space. The area that I'm NOT supposed to be in (from 150 and up is huge). Please let us change the Y-Axis. Please. 300 to 400 mg/dl is far too much Y-axis for many folks. Give us a logarithmic scale. Let me change it to 200 or 250 until I get higher.
  • The app scales on iPhone 6+. If you want to play in the Apple App Store then play correctly. Make nice scalable graphics, and make it look pleasant everywhere.
  • No interactive graph until I landscape the device. The main screen is static. I can't change the axes (Y or X!) and I can't touch existing records. This is a dumb app on a pocket super-computer. Not being able to explore my data is unacceptable.
    • That said, I can flip the device into landscape and look at up to 24 hours in the past, and run my fingers over the results. Why not portrait?
  • No "iOS widgets." iOS has the notion of Widgets. Little active areas of contact for data like my calendar or the weather. I need to see my Glucose here. Again, this is a huge missed opportunity. Huge. Do it now.

Net net, was it a good upgrade? I'm not sure yet. The sensor tech is amazing. The accuracy remains amazing. I like having the option to not take my receiver with me, but the fact that I can't trust the phone not to disconnect when it's in my pocket on the same side the transmitter is remains a serious concern. Buy the G5 if you like Tech and new Stuff, but know that the G4 is still a great device, it's just one you have to carry with you no matter what.


Sponsor: Thanks to Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Bridging Dexcom Share CGM Receivers and Nightscout

March 14, '15 Comments [20] Posted in Diabetes | Hardware | Open Source
Sponsored By

Dexcom Share

I've long lamented the sad state of Diabetes technology. For the last 20 years I've been told that it'll be cured in the next few years. (Spoiler: That hasn't happened.)

Fortunately some technological breakthroughs have happened, like the CGM (Continuous Glucose Meter). This device has a transmitted embedded in my belly that transmits to a small receiver. However, my wife couldn't see my blood sugar remotely, so the Nightscout open source project pretends to be computer connected to the receiver, then uploads it to your own website. Then you can see your blood sugar on your watch, or family and friends can log in also. This project has been moving along nicely for a year or so now.

Just last month Dexcom, the CGM maker, released an update to their receiver that includes Bluetooth, called the Dexcom Share. Now my transmitter goes to my Dexcom device which then bounces via Bluetooth LE to my phone, which is then uploaded to the Dexcom site. The Dexcom iPhone app will support the Apple Watch in the future as well, they say.

However, I'd like more control over my data. Dexcom's solution (as of the time of this writing) is iPhone/iPad only. Not everyone can afford an iWatch and iDevices. I'd like to use my Pebble Watch, for example, which is supported in Nightscout today.

I got the Dexcom Share at 3:30pm today in the mail. By 4:40pm it was paired to my iPhone and working nicely. So what I really need is a simple bridge that takes my Dexcom Share data and copies it to Nightscout. From there I can analyze it, send it to my Pebble, or do whatever.

Watching iPhone Traffic from a Windows Machine

First, I need to understand the Dexcom Api. Let's watch the iPhone talk to Dexcom. I'll install Fiddler on my Windows machine and configure Fiddler as a proxy server. I'll need to trust the Fiddler SSL cert (only for dev purposes) on both the iPhone and the Windows machine. My machine is called Hexpower7 and the proxy is on port 8888. I'll visit http://hexpower7:8888 on my iPhone and install the cert there also, which will allow me to watch the traffic and learn about the API.

I learned a few things by watching the traffic.

Watching Traffic

Calling Dexcom with CURL

First, when you login to the Dexcom API you get a Session ID, which is common and to be expected. With that Session ID you can get your sugar values. After the login I retrieved my latest sugar number:

curl -k -X POST "https://share1.dexcom.com/ShareWebServices/Services/Publisher/ReadPublisherLatestGlucoseValues?sessionID=GUID&minutes=1440&maxCount=1" -H "Accept: application/json" -H "Content-Length: 0"

resulting in:

[{"DT":"\/Date(1426290216000-0700)\/","ST":"\/Date(1426293817000)\/","Trend":4,"Value":113,"WT":"\/Date(1426290240000)\/"}]

Here's a screenshot:

Talking to Dexcom Share from CURL

Cool. So I pair-programmed with Benjamin West from the Nightscout project and we spent an hour writing a script to get my Dexcom Share data and bridge/POST it to Nightscout.

I put the script in an Azure WebJob and it's pulling my Share data and putting it into Nightscout every few minutes. I won't post the code here, rather the Nightscout team will take our prototype from here, but the result is lovely.

I don't have to carry an extra Android device anymore, I just use my Dexcom Share and its supported iPhone uploader application. Very cool.

Now it's 7:30pm, just a few hours after I got my Dexcom Share and I've got the best of both worlds. The API was easy to use and we didn't spend more than two hours on it. Most of the time was waiting for the transmitter to complete its warmup cycle.

My Blood Sugar in the Cloud

I'll do a formal Dexcom review soon, but I can already tell you it's a winner. Everyone who can get a CGM should get a Dexcom Share. It's a thrilling device. I would like the iPhone app to support iPhone 6 and 6+ screen-sizes better, and a nicer UI, but all in all, it's a great device.

Don't forget, visit http://marchisformakers.com, tell your friends and tweet us at #MarchIsForMakers!


Sponsor: Big thanks to Aspose for sponsoring the blog feed this week! Are you working with Files?Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and many other formats in your applications. Start a free trial today.

RELATED READING

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Enabling Websockets for Socket.io Node apps on Microsoft Azure

November 3, '14 Comments [13] Posted in Azure | Diabetes | nodejs | Open Source
Sponsored By

Whoa my Blood Sugar is a CGM in the Cloud!NOTE: This is a technical post, I'll blog more about Nightscout later this week. Subscribe and watch for my take, or visit http://www.nightscout.info.

I'm running an application called Nightscout that is a node app with a MongoDB backend that presents a JSON endpoint for a diabetic's blood sugar data. I use my Dexcom G4 CGM (Continuous Glucose Meter) connected with a micro-USB OTG cable to an Android phone. An Android app bridges the device and POSTs up to the website.

Azure is well suited to run an app like this for a few reasons. Node works great on Azure, MongoLabs is setup in the Azure Store and has a free sandbox, Azure supports WebSockets, and *.azurewebsites.net has a wildcard SSL cert, so I could force SSL.

Enabling Websockets and Forcing SSL

So my goal here is to do two things, make sure Websockets/socket.io is enabled in my app because it's been using polling, and force my app to use SSL.

Setting up a node.js site on Azure is very easy. You can see a 3 minute video on how to do a Git Deploy of a node app here. Azure will see that there's a app.js or server.js and do the right thing.

However, because IIS and node are working together to host the site (IIS hands off to node using a thing called, wait for it, iisnode) you should be aware of the interactions.

There's a default web.config that will be created with any node app, but if you want to custom stuff like rewrites, or websockets, you should make a custom web.config. First, you'll need to start from the web.config that Azure creates.

Related Link:  Using a custom web.config for Node apps

Let's explore this web.config so we understand what's it's doing so we can enable Websockets in my app. Also, note that even though our project has this web.config in our source repository, the app still works on node locally or hosts like Heroku because it's ignored outside Azure/IIS.

  • Note that we say "webSocket enabled=false" in this web.config. This is confusing, but makes sense when you realize we're saying "disable Websockets in IIS and let node (or whomever) downstream handle it"
  • Note in the iisnode line you'll put path="server.js" or app.js or whatever. Server.js appears again under Dynamic Content to ensure node does the work.
  • I added NodeInspector so I can do live node.js debugging from Chrome to Azure.
  • Optionally (at the bottom) you can tell IIS/Azure to watch *.js files and restart the website if they change.
  • We also change the special handling of the bin folder. It's not special in the node world as it is in ASP.NET/IIS.
<?xml version="1.0" encoding="utf-8"?>
<!--
This configuration file is required if iisnode is used to run node processes behind
IIS or IIS Express. For more information, visit:

https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
-->

<configuration>
<system.webServer>
<!-- Visit http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx for more information on WebSocket support -->
<webSocket enabled="false" />
<handlers>
<!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<!-- Do not interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^server.js\/debug[\/]?" />
</rule>

<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>

<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="server.js"/>
</rule>
</rules>
</rewrite>

<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin"/>
</hiddenSegments>
</requestFiltering>
</security>

<!-- Make sure error responses are left untouched -->
<httpErrors existingResponse="PassThrough" />

<!--
You can control how Node is hosted within IIS using the following options:
* watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
* node_env: will be propagated to node as NODE_ENV environment variable
* debuggingEnabled - controls whether the built-in debugger is enabled

See https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config for a full list of options
-->
<!--<iisnode watchedFiles="web.config;*.js"/>-->
</system.webServer>
</configuration>

Next, turn on Websockets support for your Azure Website from the configure tab within the Azure Portal:

Turn on Websockets in the Azure Portal

Now I need to make sure the node app that is using socket.io is actually asking for Websockets. I did this work on my fork of the app.

io.configure(function () {
- io.set('transports', ['xhr-polling']);
+ io.set('transports', ['websocket','xhr-polling']);

It turns out the original author only put in one option for socket.io to try. I personally prefer to give it the whole list for maximum compatibility, but in this case, we clearly need Websockets first. When will Websockets fall back if it's unavailable? What Azure website pricing plans support WebSockets?

  • Free Azure Websites plans support just 5 concurrent websockets connections. They're free. The 6th connection will get a 503 and subsequent connections will fallback to long polling. If you're doing anything serious, do it in Shared or above, it's not expensive.
  • Shared Plans support 35 concurrent websockets connections, Basic is 350, and Standard is unlimited.

You'll usually want to use SSL when using Websockets if you can, especially if you are behind a proxy as some aggressive proxies will strip out headers they don't know, like the Upgrade header as you switch from HTTP to Websockets.

However, even free Azure websites support SSL under the *.azurewebsites.net domain, so doing development or running a small site like this one gets free SSL.

I can force it by adding this rule to my web.config, under <system.webServer>/<rewrite>/<rules/>:

<rule name="Force redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTP_HOST}" pattern=".+\.azurewebsites\.net$" />
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}"/>
</rule>

Note the pattern in this case is specific to azurewebsites.net, and will take any Azure website on the default domain and force SSL. You can change this for your domain if you ike, of course, assuming you have an SSL cert. It's a nice feature though, and a helpful improvement for our diabetes app.

I can confirm using F12 tools that we switched to WebSockets and SSL nicely.

image

The whole operation took about 15 minutes and was a nice compatible change. I hope this helps you out if you're putting node.js apps on Azure like I am!


Sponsor: Big thanks to Aspose for sponsoring the feed this week! Working with Files? Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and many other formats in your applications. Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Diabetics: It's fun to say Bionic Pancreas but how about a reality check

June 30, '14 Comments [23] Posted in Diabetes
Sponsored By

A diagram outlining the complete bionic pancreas systemThe state of healthcare reporting is just abysmal. It's all link-bait. It's fun to write things like "Random Joe invents cure for diabetes in his garage, saves dying 5 year old." It's surely less fun to read them with you're the one with the disease.

IMPORTANT UPDATE: Scott (me) has now interviewed Dr. Steven Jon Russell, MD, PhD, a member of the Bionic Pancreas Team! Check out their interview at http://hanselminutes.com/431.

It's time for medical journalists to try a little harder and pushback against editors that write headlines optimized for pageviews. The thing is, I've met a dozen General Practitioners who are themselves confused about how diabetes works, and link-bait journalism just ruins it for the public, too. I've received no fewer than 50 personal emails or FB posts from well-meaning friends this last week. "Have you heard? They've cured your diabetes with a bionic pancreas!"

I have been a Type 1 Diabetic for 20 years, I've worn an insulin pump 24 hours a day for the last 15 years (that's over 130,000 hours, in case you're counting), I'm a diabetes off-label body hacker with an A1C of 5.5%. What's that mean to you? I'm not a doctor, but I'm a hell of a good diabetic.

I know what I'm talking about because I'm living it, and living it well. A doctor may be able to tell me to adjust my insulin every 3 months when I see them, but they aren't up with me at 4 am in a hotel in Germany with jet-lag telling me what to do when I'm having a low. Forgive me this hubris, but it comes from 75,000 finger pricks and yes, it hurts every time, and no, my insulin pump doesn't automatically cure me.

Last year the FDA approved an Insulin Pump that shuts off automatically if it detects the wearer is having a low sugar. The press and the company itself called this new feature an "artificial pancreas." Nonsense. It's WAY too early to call this Insulin Pump an Artificial Pancreas.

Now we are seeing a new "bionic" pancreas for which that the press is writing headlines like "A Father Has Invented a Bionic Organ to Save His Son From Type 1 Diabetes" and "Bionic Pancreas" Astonishes Diabetes Researchers."

It's a great proof concept for a closed system based on dual insulin pumps (one with glucagon) and a high accuracy CGM managed by an iPhone. But that's a not a fun headline, is it?

"Boston University biomedical engineer Ed Damiano and a team of other researchers published a study earlier this month detailing a system that could prevent these dangerous situations."

Indeed, the study in the New England Journal of Medicine where Ed Damiano, Ph.D. is listed alongside Steven J. Russell, M.D., Ph.D., Firas H. El-Khatib, Ph.D., Manasi Sinha, M.D., M.P.H., Kendra L. Magyar, M.S.N., N.P., Katherine McKeon, M.Eng., Laura G. Goergen, B.S.N., R.N., Courtney Balliro, B.S.N, R.N., Mallory A. Hillard, B.S., David M. Nathan, M.D.

They are clearly all brilliant and of note. Let's break the study down.

"...we compared glycemic control with a wearable, bihormonal, automated, “bionic” pancreas (bionic-pancreas period) with glycemic control with an insulin pump (control period) for 5 days in 20 adults and 32 adolescents with type 1 diabetes mellitus."

They are trying to improve blood sugar control. That means keeping my numbers as "normal" as possible to avoid the nasty side-effects like blindness and amputation in the long-term with highs, and death and coma with lows. The general idea is that since my actual pancreas isn't operating, I'll need another way to get insulin into my system. "Bihormonal" means they are delivering not just insulin, which lowers blood sugar, but also glucagon, which effectively raises blood sugar. They tested this for 5 days on a bunch of people.

"The device consisted of an iPhone 4S (Apple), which ran the control algorithm, and a G4 Platinum continuous glucose monitor (DexCom) connected by a custom hardware interface."

I use a DexCom G4, by the way. It's a lovely device and it gives me an estimate of my blood sugar every 5 minutes by drawing a parallel between what it detects in the interstitial fluid of my own fat and tissues (not my whole blood) and then sends it wirelessly to a handset. I currently then make calculations in my head and decide (Note that keyword: decide) how much insulin to take. I then manually tell my Medtronic Insulin Pump how much insulin to take. The DexCom must be calibrated at least twice daily with a whole blood finger stick. Also, it's not too accurate on day 1, and can be wholly inaccurate after it's listed 7 day effectiveness range. But it's that keyword that this project is trying to help with. Decide. I have to decide, calculate, guess, determine. That's hard for me as an adult. It's near-impossible for an 8 year old. Or an 80-year old. Computers are good at calculating, maybe it can do this tedious work for us.

It's two pumps, one with insulin, one with glucagon, and an iPhone controlling them both

The thing is, with Type 1 Diabetes there's dozens of other factors to consider. How much did I eat? What did I eat? Am I sick? Does my stomach work? Do I digest slowly? Quickly? Do I have any acetaminophen in my system? Am I going jogging afterwards? Is this insulin going bad? Is the insulin pump's cannula bent, and dozens (I'm sure I could come up with a hundred) of other factors. Read Lane Desborough's paper (PPT as a PDF) on "Applying STPA (System Theoretic Process Analysis) to the Artificial Pancreas for People with Type 1 Diabetes" for a taste of what needs to be done.

image

The brilliance of this system - this "bionic" pancreas - is this...and these are MY words, no one else's:

The two pump bionic pancreas system gives you rather a LOT of insulin if needed (as if it's descending a plane quickly and dramatically) then it pulls you up nicely with a bit of glucagon (as if the pilot screamed pull up as he noticed the altitude change).

It's the addition of the glucagon to get you out of lows that is interesting. Typically Diabetics have a big syringe of glucagon in the fridge for emergencies. If you're super low - dangerously loopy - your partner can get you out of it with a big bolus of glucagon. But if you put glucagon in an insulin pump, you can deliver tiny amounts and now you are are moving the graph in two directions.

Think I'm kidding about the "pull up, pull up" analogy?

Here's a snippet of a graph from page 15 of one of the Appendices (PDF). Note around 19:00, the blue bar going down, that's a lot of insulin. Then the BG numbers come down, FAST. Note the black triangle at around 20:20. That's "pull up, pull up" and a bolus of glucagon in red. And more, and more, in fact, there are many glucagon boluses keeping the numbers up, presumably happening while the subject sleeps. Then around 07:00 the numbers rise, presumably from the Dawn Effect, and another automatic insulin bolus (an overcorrection) and then more glucagon. It's a wonderfully controlled roller-coaster. This isn't using the word roller-coaster as a pejorative - that is the life I lead as a diabetic.

Pull up, pull up!

It's also not mentioned in the press that this system uses lot more insulin than I do today. A lot more, due to it's "dose and correct" algorithm's design.

"Among the other 11 patients, the mean total daily dose of insulin was 50% higher during the bionic-pancreas period than during the control period (P=0.001);"

UPDATE: I spoke to Dr. Russell, and I'm not entirely correct that this system uses a lot more insulin. The system didn't use much more insulin in diabetic kids who have very controlled diets, and was 50% higher in only some of the adults, presumably because (anecdotally) many of them were eating a lot more and "testing" the extents of the system.

I use about 40U a day, total. So we're looking at me using perhaps 60U a day with this system. As with any drug, though, insulin use has its side effects. It can cause fat deposits, scarring at injection sites, and we can become resistant to it. It'd be interesting to think about a study where someone's on 50% more insulin for years. Would that cause increases in any of these side effects? I don't know, but it's an interesting question. Should a closed system also optimize for doing its job with the minimum possible insulin. I optimize for that today, on my own, hoping that it will make a difference in the long run.

But, glucagon isn't pump friendly as it is today. An unfortunate note that isn't covered in any of the press is that they are having to replace the glucagon every day. Juxtapose that with what I do currently with insulin. I keep my pump filled and swap out its contents and cannula (insertion site) every 4-7 days. Insulin itself can surface ~28 days at room temperature although it's most often refrigerated. Changing one of the pumps daily is a bummer, as they point out.

"...the poor stability of currently available glucagon formations necessitated daily replacement of the glucagon in the pump with freshly reconstituted material."

It's early, people. It's not integrated, it's a proof of concept. It's impressive, to be sure, but Rube-Goldbergian in its hardware implementation. Two pumps, a Dexcom G4 inside a docking station, receiving BG data over RF from the transmitter, then the Dexcom wirelessly talking to an iPhone within another docking station.

"Since a single device that integrates all the components of a bionic pancreas is not yet available, we had to rely on wireless connectivity to the insulin and glucagon pumps, which was not completely reliable."

I'm not trying undermine, undercut, or minimize the work, it's super promising, but medical journalists need to seriously understand what's really going on here.

Fast forward a few years, and there will very likely be an bi-hormonal "double" pump with both (more stable) glucagon and insulin that combines with a continuous glucose meter that provides the average Type 1 Diabetic with a reasonable solution to keep their numbers out of imminent danger. Great for kids, a relief for many.

But, just as pumps are today, it'll be USD$5000 to USD$10000. It will require insurance, and equipment, it'll require testing and software, it'll require training, and it won't be - it can't be - perfect. This is a move forward, but it's not a cure. Accept it for what it is, a step in the right direction.

Do I want it? Totally. But, journalists and families of diabetics, let's not overreact or get too ahead of ourselves. Does this mean I should eat crap and the machine will take care of it? No. I'm healthy today because I care to be. I work at it. Every day. As I'm typing now, I know my numbers, my trend-line, and my goal: stay alive another day.

Read my article from 2001 - yes, that's 13 years ago - called One Guy, an Insulin Pump, and 8 PDAs:

"I imagine a world of true digital convergence -- assuming that I won't be cured of diabetes by some biological means in my lifetime -- an implanted pump and glucose sensor, an advanced artificial pancreas. A closed system for diabetics that automatically senses sugar levels and delivers insulin has been the diabetics' holy grail for years. But with the advent of wireless technology and the Internet, my already optimistic vision has brightened. If I had an implanted device with wireless capabilities, it could be in constant contact with my doctor. If the pump failed, it could simultaneously alert me, my doctor, and the local emergency room, downloading my health history in preparation for my visit. If it was running low on insulin, the pump could report its status to my insurance company, and I'd have new insulin delivered to my doorstep the next day. But that's not enough. With Bluetooth coming, why couldn't my [PDA] monitor my newly implanted smart-pump?"

Go an educate yourselves about the "We Are Not Waiting" movement. Hear how Scott Leibrand has a "DIY Artificial Pancreas" that's lowered his girlfriends average blood sugar dramatically using only an DexCom G4 and smart algorithms. You can make a change today, at your own risk, of course.

Read about the The DiabetesMine D-Data ExChange and how non-profit Tidepool is creating open source software and systems to make innovation happen now, rather than waiting for it. Get the code, join the conversation. Exercise, eat better, read, work. You can hack your Diabetes today. #WeAreNotWaiting

Related Links and Writings


Sponsor: Thanks to friends at RayGun.io. I use their product and LOVE IT. Get notified of your software’s bugs as they happen! Raygun.io has error tracking solutions for every major programming language and platform - Start a free trial in under a minute!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Page 1 of 15 in the Diabetes category Next Page

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.