• Why?

    My wife accuses me, rightly so, of asking this question too often. It is one thing, of many, that I do that annoys her. She asks me a question, for example, “can you please get me that bag of flour from the pantry?” My typical retort is “why?” And when I do, and her exasperation bubbles up into tangible, but transitory, angst between us, I silently blame my over twenty years of Product Management experience.

    A constant search for the “why” of everything.

    I have posed this question to myself that much more frequently lately. With my joining of WordPress platform leader, WP Engine, I have found myself in a vast world of ultimate creativity and daily reminders of the incredibly liberating power of an open-source software (OSS) project. Yes, WordPress started out as a blogging technology and yes, this site today, that you have stumbled upon, is a blog. But WordPress is much more than blogging and now living in its world, I have become inspired to perform some of the fundamental jobs-to-be-done of this world-changing software: sharing, building, communicating.

    My “why?” is quite simple. I write because I want to. Pushed further, by the persistence of a grizzled, elder Product Manager, I would expound with: I write because I want to record, for myself, the thoughts, ideas, feelings, questions, experiences of the present such that I may reflect upon them, far into the future. Beyond selfishness, I write also because this allows my wife and my children to know me in ways quite unexpected and potentially more deep. I write because I would have liked to have known my father likewise.

    Why? Why not, I say!

  • Using Realtime Capabilities To Manage Type 1 Diabetes (Part 2)

    Like any good parent of a child with Type 1 diabetes, I have no time. I know, I know. Every parent with young kids complains of a lack of free time. Of a lack of sleep. Of stress brought on by the craziness of life with young kids. Trust me. Type 1 diabetes parents are running on fumes, barely able to keep up with anything, given the incredible stress and demands that the disease puts on their lives and that of their family.

    All of this is my excuse for taking so long for my next post! But the above also is the rationale of why I started playing with various technical solutions in search of something that could make the management of Type 1 diabetes more manageable. Type 1 Diabetes really sucks (English degree for the win!?). Having a real personal reason to drive one to build solutions with technology? Pretty cool. Especially when a bunch of that tech is from the company at which you work and part of a product that you yourself manage.

    If you remember my previous post, it was not long after diagnosis that I started envisioning potential systems that could help with the day-to-day management of the disease. And it was at the same time that I discovered an incredibly rich, sophisticated and innovative DIY community that was building life-changing technology for the Type 1 diabetes world, outside the commercial space.

    We’re talking about organizations that have emerged over the last decade or so, where people who just wanted answers, who just wanted a better, improved way of managing Type 1 diabetes, dug into the depths of figuring out how things like the continuous glucose monitor (CGM) and insulin pumps were working — wanting to take advantage of data and capabilities and technology advancements in their own day-to-day lives to ease the burden of Type 1 diabetes.

    Without a doubt, the people and teams behind things like the Nightscout ProjectOpenAPS and Loop are tremendous examples of what can be done by a collaborative open source community.

    So as a technologist, a product manager and now a father of a daughter with Type 1 diabetes, I was energized about what I was seeing out there. I set forth, harnessing the power of the open source community, with one objective in mind: to have the fastest, most secure, scalable, resilient and flexible system for me to see my daughter’s ever-changing blood glucose levels.

    In this post, I’ll provide more detail on the hardware, network and communication software, and end-user applications for my DIY Type 1 diabetes management system.

    Solution Architecture

    I started by establishing what it was that I wanted to improve and outlining my challenges and requirements. My primary goal was to create a technology stack that could stream updates from my daughter’s CGM to an increasing amount of end-user applications, including SMS, push notifications, Slack, IoT lightbulbs (more on that one in a bit) — any interface I interact with throughout the day.

    Why so many apps? I have a life to live myself. I have to go to work. My wife and I both needed to be able to consume the data and updates, and it needs to be the exact same data. I can’t be looking at my phone all of the time, but I need to know the moment there’s a potential problem. Most important, I need to know that I have the most up-to-date data available.

    My solution architecture looks like this: Using PubNub, it’s 100% serverless, has reliable high-speed message delivery, it’s easy to integrate new clients and continues to prove extensible via PubNub Functions. More on those further down in this post.

    Hardware

    It all starts with the Dexcom continuous glucose monitor attached to my daughter’s belly. The CGM communicates with her phone that is always nearby, via Bluetooth. Every five minutes, the CGM sends her current blood glucose level to her phone.

    Software and network communication

    From that phone, using a slightly customized Loop application, the system sniffs out the Bluetooth traffic for new numbers and sends that data to PubNub through Wi-Fi or LTE. And from there, it’s off to the races.

    So, why PubNub?

    • I don’t have to stand up any servers. It’s entirely serverless.
    • I don’t have to build up any sophisticated application stacks.
    • It’s super-fast. Messages are sent from my daughter’s CGM to all end-user apps in under a quarter of a second.
    • Reliability. I’ve got great confidence that every message will be delivered in real time.

    The PubNub Data Stream Network is responsible for augmenting and distributing that data in sub-quarter-second speeds through any number of application channels. As you can see from the below picture, comparing the PubNub-powered application to the Dexcom cloud-based one, I receive the data almost instantaneously, and routinely many, many seconds before the Dexcom application, if not several minutes or longer. It’s so fast that I’ve made my non-techie wife a big fan of PubNub and a heavy user of our primary phone application, Slack.

    PubNub Functions, our serverless compute platform, also plays a big role in this and allows me to do a lot of things that I wouldn’t be able to do with the CGM system right out of the box. I have a number, the current blood glucose level, but now what can I do with it? A simple number might not be completely useful. What are the 10 numbers that came before it? What’s the trend? What other data can I add into that data packet that I’m going to distribute out?

    The platform brings business logic into my real-time environment. I can add in statistical analysis and make the data more readily understandable by humans. It’s all part of the data flow. It also expands what apps and devices integrate into the application, and we’ll cover those in our next part.

    End-user applications

    That data can be published to any number of application channels. Using core PubNub SDKs, I was able to quickly stream updates to my Mac menu bar, publish updates to a real-time chart or custom JavaScript webpage in the browser, and send a push notification with the newest reading.

    But not everything can be rapidly integrated into the app through the core PubNub SDKs, specifically the third-party services and devices. That needs a little bit of integration work. That’s where PubNub Functions comes into play, really opening up where I could stream the data to.

    This is how I’m able to trigger an SMS/text message through a third-party service. This is also how I’m able to send every new reading to Slack. And it’s how I’m able to change the color of an LIFX lightbulb depending on the number.

    Continuing to add new applications

    The LIFX lightbulb was particularly interesting to me and shows how flexible the system really is for adding new end-user applications. When my daughter’s asleep and I’m in my bedroom reading a book or watching TV, looking at my phone with each update takes me out of my concentration. Relaxation at the end of a long day is hard to achieve!

    So, I added the LIFX internet-connected lightbulb to the system, which changes color and brightness based on my daughter’s blood sugar levels. Red means high, green means in range, blue means trending low and incredibly bright blue means low and action required. It’s had a huge impact on my wife’s and my nightly routine. And it only took 15 minutes to implement, start to finish.

    Why all the fuss?

    Why am I so excited about what I’ve built and how I’ve used PubNub? The emotional benefit has been incredible for my wife and me. The whole notion of being able to see data the moment it comes off my daughter’s CGM — it’s huge as a parent.

    From there, I can easily distribute that number to an ever-growing number of applications I interact with, continuing to improve how I consume it in a more efficient, less disruptive way in my everyday life. That data is wherever I need it, whenever I need it.

    Lastly, resilience. This is what PubNub and other hosted-platforms like it do. Day in and day out, these vendors work to solve data distribution needs in the most reliable and secure way.

    I look forward to continuing adding new end-user applications, enhancing my system and improving how my wife and I manage my daughter’s Type 1 diabetes. And I’ll continue to share and watch with excitement as the DIY, open-source Type 1 diabetes community grows.

  • Using Realtime Capabilities To Manage Type 1 Diabetes (Part 1)

    In February 2018, my family of four — wife, 6-year-old boy and 3-year-old girl — were thrust quite suddenly into the world of Type 1 diabetes. We spent about five days in the hospital trying to stabilize my daughter and learning a whole lot about how to manage the life-threatening disease that would be with her forever.

    It is tough to articulate, without tearing up, the intense moments we lived through in those early days as we administered finger pricks and multiple daily insulin injections to a crying toddler. We still live with it; we’re in the early days of a long journey. It is a tough one at that, but we’re much appreciative of all of the wonderful advances that have been made, both medically and technologically.


    Diabetes Type 1 and managing the life-threatening disease

    Managing Type 1 diabetes lies in the real-time nature of the daily monitoring of my daughter’s disease — constantly keeping tabs on food intake and blood sugar levels so as to determine action or not. In fact, that’s what your normal pancreas — and the rest of your body — is doing right now: constantly tweaking its biochemistry in order to keep things, in this case blood sugars, in a normal, healthy range. Throw whatever you want at it, an In-N-Out Double-Double, a night out eating pizza and drinking beer, a big hangover brunch at the neighborhood diner, and your pancreas can handle it with aplomb, quickly determining exactly how much of its carb-processing power — insulin — it needs to dispense in order to convert this food into energy your body can use. Charting blood sugar over time, even for the craziest of meals, is like looking at a perfect bell curve, with a relatively small peak.

    Doing the same for a person with Type 1 diabetes would yield quite a different experience. Since their pancreas cannot produce insulin, the sugars from their meals would just continue to pile up in the bloodstream — this is what creates both short-term emergency risk as well as long-term health deterioration. A chart of their blood sugars gives just a glimpse of the chaos that they deal with on a daily basis, especially without proper, attentive management.

    What I set out to solve

    It is against this chaos that my wife and I fight each and every minute of the day. That said, life for diabetics has changed tremendously, for the positive, with the advent of technological advancements like the insulin pump and the continuous glucose monitor (CGM). The latter is life-altering for sure; the CGM is the thing that allows my wife and me to see our daughter’s blood sugar levels at any moment in time, even when we’re at work or otherwise far away. The device is firmly planted on my daughter’s belly and has a fine filament inserted into her tissue. Every five minutes, the CGM transmitter sends the current number to a phone nearby, which further sends the data to the cloud. That’s right — our family is a walking IoT use case!

    However, there’s a challenge.

    The data never gets to us as fast as we would like and, perhaps as importantly, never exactly where we need it to be. For the former, as a parent, I have unrealistic expectations. It can never be fast enough, although in reality, the downstream recipients of said data — me, my wife and other caregivers — can’t and shouldn’t act immediately. But still, I want it fast! On the delivery side, I can’t be picking up my phone constantly. Or staring at a webpage somewhere. Or casually glancing at my smartwatch. I need that singular value, my daughter’s most recent blood glucose level, accessible via many channels, from phone to smartwatch to iPad to computer to whatever other devices I want to connect.

    The maker of our CGM, Dexcom Inc., has done a great job with its product, and it has gotten better each release. The current version does not require a finger stick prick calibration, which means less poking of our three-year-old child. Despite the progress, and its basic tracking applications and historical reporting, Dexcom hasn’t invested heavily in the instantaneous delivery of blood glucose level readings to various types of apps and interfaces.

    To deal with this limitation, I set out to solve faster delivery to any number of devices and interfaces.

    DIY

    Luckily for me, I haven’t been alone in this — Type 1 diabetes has a robust, advanced do-it-yourself community. Makers and developers around the world have decoded Bluetooth transmissions to create completely new management applications. They have reverse-engineered communication protocols for insulin pumps and have created advanced algorithms, resulting in the first really usable artificial pancreas implementations. And they have created great mostly real-time visualization applications so parents and others can follow their patients and know what the blood glucose numbers are.

    That (poor) programmer inside cried a bit when I stumbled across the great efforts of several major players in the Type 1 diabetes DIY world — the Nightscout Foundation, OpenAPS and Loop. What could I tinker on, placating my technical curiosities, all the while making our day-to-day lives a bit easier when it came to disease management? The problem had been solved already!

    As I dug deeper, I saw opportunities though. And after I joined real-time API platform leader PubNub later in the year, things started to click. I needed to have everyone involved in my daughter’s care to have the same view of the data, at the same moment in time, as myself and each other. And I needed to recognize that not everyone was going to have the same application up and open at the same time. I needed to have, and others to have, the critical data as soon as it streamed off the CGM. And to have it visible to us all, whether in real-time charts, SMS, push notifications or Slack messages. There was this real-time aspect of the problem space that even some of the DIYers were missing or had codified in closed applications.

    Working with a real-time application platform allows you to think much differently about solution architectures. Integrated fast messaging, serverless extension and integration points, inline security and multiples of distribution models and user interfaces all allowed me to focus on the “business” problem that I was trying to solve:

    • Where was data being sent from?
    • To whom should it go and by which method?
    • Should I augment the data with, in this case, additional statistical aggregations?
    • Should I store it in a database, as well, for longer historical views?

    I spent way less time thinking about servers, API frameworks, logging, monitoring and so forth, and more time answering the questions that inevitably made the day-to-day management of my daughter’s Type 1 diabetes that much easier.

    Now that I’ve introduced you to my project and what I set out to solve, I’ll dive into the details of it all in subsequent parts. I’ll discuss the core components of the project — the hardware, the IoT network and communication — and the end-user applications. Keep an eye out for part two, coming soon!