Vitamin D and insulin sensitivity

tl;dr – for me, Vitamin D hugely influences insulin sensitivity.

After the flu, I continued to be sick. We did the usual song and dance many people do around “hey, do you have pneumonia?”. Which, luckily, I didn’t, but I was still pretty sick and my after visit summary sheet said bronchitis. Also, my average BGs were going up, which was weird. After all, when I had the flu, I had spectacular BGs throughout. So I was pretty concerned when my time in range started dropping and my average BG started rising.

In diabetes, there are a lot of things that influence BGs. It can be a bad pump site; a bad bottle of insulin; stress; sickness; etc etc. that causes out of range BGs. Most of these are helped by having a DIY closed loop like OpenAPS. So, when your BGs start to rise above (your) normal and stay there, it’s indicative of something else going on. And because I was sick, that’s what I thought it was. But as I continued to gradually heal, I noticed something else: not only were my BG averages continuing to rise (not normal), but I also was needing a lot more insulin. Like, 20-30u more per day than usual. And that wasn’t just one day, it was 4 days of that much insulin being required. Yikes. That’s not normal, either.

So, I was thinking that I was hitting the Fiasp plateau, which made me really sad. I’ve been using Fiasp for many months now with good results. (For those of you who haven’t been tuned into the diabetes community online, while many people like Fiasp because it’s slightly faster, many people also have experienced issues with it, ranging from pump sites dying much faster than on other insulins; having issues with prolonged high BGs where “insulin acts like water”, etc.) But, I was prepared mentally to accept the plateau as the likely cause. I debated with Scott whether I should switch back to my other insulin for 2-3 sites and reservoirs to give my body a break, and try again. But I was still sick – so maybe I should wait until I was not clearing gunk out of my lungs. Or I was also pretty convinced that it was correlated with my absolute ZERO level of activity. (I had some rising BG averages briefly over Christmas where I was fearing the plateau, but turns out it was related to my inactivity, and getting more than zero steps a day resolved that.) I knew I would be moving around more the next week as I gradually felt better, so it should hopefully self-resolve. But making changes in diabetes sometimes feels like chicken and egg, with really complicated chickens and eggs – there’s a lot of variables and it’s hard to pin down a single variable that’s causing the root of the problem.

One other topic came up in our discussion – vitamin D. Scott asked me, “when was the last time you saw the sun?”. Which, because I’d been sick for weeks, and traveled for a week before that, AND because we live in Seattle and it’s winter, meant I couldn’t remember the last time I had seen the sun directly on my skin. (That sounds depressing, doesn’t it? Sheesh.)

So, I decided I would not switch back to the previous insulin I was using, and I would give it some time before I tried that, and I would focus on taking my vitamin D (because I hadn’t been taking it) and also trying to get at least SOME activity every day. I took vitamin D that night, went to bed, and….

…woke up with perfect BGs. But I didn’t hold my breath, because I was having ok nights but rough days that required the extra 30 units of insulin. But by the end of the day, I still had picture-perfect BGs (my “normal”), and I was back to using my typical average amount of insulin. PHEW. Day 2 also yielded great BG levels (for me, regardless of sickness) and around average level of insulin needed for the day time. Double phew. Day 3 is also going as expected BG and total insulin usage wise.

You might find yourself thinking, “how can it be as simple as Vitamin D? There’s probably something else going on.” I would think that – except for I have enough data to know that, when I’m vitamin D deficient, getting some vitamin D (either via pill or via natural form from sunlight) can pack a punch for insulin sensitivity. In 2014, Scott and I went out in February even when it was cold to sit in a park and get some sunshine. After about an hour of sitting and doing nothing, with no extra insulin on board, WHOOOSH. I went mega-low. I’ve had several other experiences where after being likely vitamin D deficient, and then spending an hour or so in sunlight, WHOOSH. And same for when there was no sunlight, but I took my vitamin D supplements after a while of not taking them. And no, they’re not mixed with cinnamon 😉 (That’s a diabetes joke, cinnamon does not cure diabetes. Nothing cures type 1 diabetes.)

So tl;dr – my insulin sensitivity is influenced by vitamin D, and I’ll be trying to do a better job to take my vitamin D regularly in the winters from now on!

Making changes in diabetes is hard by DanaMLewis

Women in open source make a difference

I was incredibly honored to find out that I had been nominated for the 2018 Women in Open Source award (and even more blown away to learn that I am one of the finalists). I wasn’t familiar with the award, and when I looked it up to learn more about it, the finalist list for the last few years gives me some serious imposter syndrome! Aside from that, there were a few things that caught my eye – and one of them was a citation from a study that found that only 11% of people contributing in open source are women.

To me, this number both makes sense, and doesn’t.

Why it makes sense (to me): open source can be hard on women.

I’ve been doing things in open source since 2014, falling into it because of DIYPS and because of getting to know people like Ben who are passionate open source advocates. Because I was helped by open source work, it was a key driver for my own passion behind making our work with OpenAPS open source, and is why I’m currently working on developing a series of open source tools to help researchers working with diabetes data. I don’t know that I would have done anything open source had I not found the perfect series of projects that led me there.

While there are many great people in the diabetes open source community, in the middle of 2014 I wrote this blog post about being female and being discounted. It was a hard post to write. But I felt it was important, because one of things both Scott and I noticed is a lot of the attitudes behind this seemed to be subconscious: directing technical questions about our project to Scott only; refusing to direct any substantial questions to me even after Scott specifically would redirect questions to me, etc. The only way I saw to (begin to) deal with the problem was to address it head on.

And, for me, things have improved with time. But it hasn’t gone away, and it still requires active addressing about once a month or so. And yes – these are (relatively) minor problems compared to what some women experience in open source, or in tech. But it’s some of the most common, frustrating friction that can easily drive women away when they get tired of experiencing stuff like that. And when they go away, it’s a loss for everyone.

Why this number doesn’t make sense (to me): women contribute incredible value to open source, and are high-volume contributors, especially if you look beyond the narrow definition applied to open source coding.

Every where I turn, I see women participating in open source. I see Kate Farnsworth and Christine Deltrap, two incredible individuals who have made watchfaces used by thousands of families to remote monitor their children’s blood sugars. I see Katie DiSimone, who has written hundreds of lines of documentation, and answers hundreds of technical troubleshooting questions across several channels. I see Mad Price Ball, who leads the Open Humans Foundation with open source work (*and* is an amazing mentor to women like me, who have non-traditional development backgrounds). I see Karen Sandler, a fierce advocate for making software open source, who herself is a finalist for the WOS award, too!

I also see a lot of my own contributions in open source, especially in the early days when Scott was the one doing most of the committing to Github for the tools we were building. Those were part of why I was told I was discounted in 2014, because my work didn’t “count”. Today when someone goes and looks at Github, if they look at the wrong toolkit (or just one, for example), it gets said that “Dana didn’t do anything on OpenAPS”. (Heh).

So I know there are also other women out there whose work is being overlooked when counting who’s doing open source. However, this type of work is absolutely crucial to open source projects, and these contributors drive an incredible amount of value. I’m glad the Red Hat Women in Open Source Awards site acknowledged this, and made this list:

  • Code and programming.
  • Quality assurance and bug triage.
  • Involvement in open hardware.
  • System administration and infrastructure.
  • Design, artwork, user experience, and marketing.
  • Documentation, tutorials, and other communications.
  • Translation and internationalization.
  • Open content.
  • Community advocacy and community management.
  • Intellectual property advocacy and legal reform.
  • Open source methodology.

The list was partially to help encourage people to nominate women; and also to help women to recognize all of the activities they do that’s open source. And it was helpful to me, too. Because of that list, instead of a handful of key examples of open source activity by women, I can instead name dozens of women. I bet you can, too. There’s so much incredible open source activity and value that happens in places outside of commit history, and if we want to recognize and acknowledge the work of everyone in open source communities, we should do a better job of acknowledging *all* of these types of activities and not just recognizing individuals (male or female) who have a traditional code-based commit history.

So if you’re reading this, it’s likely you’re a supporter of women in open source communities. Thank you for that! But I’d like to ask you to do two specific things.

1) Actively recognize the women working with you in open source. The internet can be a hard place to be, let alone work, when you are female. Help lift women up; recognize their work; and help them grow their skills.

2) Ok, this one is optional :) But if you’ve read all this way, you might consider clicking here and going to the Women in Open Source Awards site and voting for one the finalists in each category. It’s one vote per email address. Thanks!

Acknowledging all contributions in open source by DanaMLewis

Makers gonna make…a book about diabetes devices? Kids book written by @DanaMLewis

book inspirationLast year after Christmas, I was running around my parents’ backyard with my niece when she spotted my CGM sensor on my arm and asked what it was. I’m always struck when my niece and nephews have noticed my diabetes devices, and am interested to see what “new” humans think about and how they encounter things and what they mean. In this case, I explained the CGM and we went back to running around, but it stuck in my mind for a few days.

I also remember the excitement and attention any time a kids’ book has a character with diabetes in it, or a storyline of diabetes, because there’s just not much out there. I was diagnosed at 14, but I love seeing PWDs in the wild and like the idea of more diabetes inclusion in materials for all ages.

So, I wrote a kids book, with the goal of introducing the concept of diabetes devices and more broadly, how people are different in different ways. I talked my incredible artist aunt into illustrating this book. :)

This book is primarily for me and my niece and nephews, but I know there might be a few other people who like the idea, too (even as there may be a few people who sniff at the idea*). I investigated the publishing options and decided to go with self-publishing, which would allow for:

  • The cheapest copies for me as the author, to be able to give to my various family members who want them.
  • The ability to make it available to other people who want copies.
  • The ability to price said copies so it’s accessible and reasonable to order easily.
  • (It’s actually cheaper for you to order this on Amazon directly to your house, than it is for you to ask me for an author-priced copy and for me to go through the hoopla of getting it to ship.)
  • Every two copies purchased via Amazon yields an author-priced copy that I plan to donate to libraries, hospitals, etc. (If you’d like to sponsor 10+ books for a library system, feel free to ping me about the easiest way to do that.) I’m planning to use any “profits” from the book to pay for copies that I’m donating.

I’ve been working on it off and on for the past few months as my aunt illustrated it, and got to give a copy to my brother and niece as a total surprise to read when we were in Alabama this past weekend. So now that the cat is out of the bag, the book is available online! The book, “Carolyn’s Robot Relative” (that’s me!), is available on Amazon here (note that’s an Amazon affiliate link). (There’s also now a German-translated copy with the title, “Ist Carolyns Tante ein Roboter?” – see the German version on Amazon.de here!)

robot illustration @DanaMLewisI also *love* the robot illustration that my aunt made with the CGM as the main body of the robot.  I reached out to someone on Etsy who does custom “stuffies” – and it turns out, she has a diabetes connection, too! So, you can get a stuffed CGM robot if you or your kids like it, for $20. Here is the link to the listing on Etsy. (I don’t make any money from this; I paid $20 for my first one, but had worked with her on pricing so it would be reasonable for people to get if they liked it!)

CGM robot stuffy from Carolyn's Robot Relative by DanaMLewisCGM robot stuffy from Carolyn's Robot Relative by DanaMLewisThe stuffy with the book – it’s an awesome sized stuffy!

And because I have also been playing with code fabric on Spoonflower (see tweet thread here, or this blog post here) and know they do fabric as well as gift wrap…I uploaded the CGM robot there so I could turn it into wrapping paper, too. Here’s the link to see it on Spoonflower.

CGM robot giftwrap preview! available on Spoonflower as fabric, gift wrap/wrapping paper, or wallpaper

I learned a lot in the research process about self-publishing options and the route I took that I wanted to share here, especially for anyone who sniffs and goes troll on me about putting this out there.

*Tl;dr – self-publishing is easy, and if you don’t like my book, go make a better one yourself! :) The more books, the better!

Some background on the publishing process & how I made the book:

I chose self-publishing with CreateSpace on Amazon. They now have this new “Kindle Direct Publishing” (KDP) program that’s similar, but less tested than CreateSpace, and seems to be higher cost for author copies. I never figured out what the benefits are of that, and chose CS.

I generally Google’d a bunch of questions and ended up on the CS forums, too, and read up on different programs to use to create the book, etc.

My process:

  • I wrote the book test in Microsoft Word, then translated it into a Google spreadsheet so I could visualize the left/right layout of the flow of text, as well as start to identify where I had ideas about what images to use.
    Example_storyflow_spreadsheet_Dana_Lewis
  • My aunt began illustrating, and sending me pictures. Fun fact – all of the images in the book are put in via iPhone photos -> AirDrop -> my computer -> inserted! No fancy graphics. (Although I did open a few of the images in Preview and change the white balance, since each photo was taken in different lighting, in a weak attempt to balance the colors of the pictures side by side.)
  • I started dropping them into a Microsoft Word document. The one thing the CS forums warned about was making sure the images were high enough res. The images were…but later in the upload process, it complained about the DPI being low. I switched to Microsoft PowerPoint (doing the same thing I did in Word to create the custom page size to work with bleed, trim, etc.) and dropped the images in the same way, and PPT doesn’t compress the images and it was fine. Word was problematic. It didn’t take much time to switch back and forth, but if I did it again, I’d start with PPT because they generally seem to get that images need to be full sized.
  • (A workaround if you take screenshots and need to insert images – you can use Preview to go in and adjust the size and make it >300 DPI that CS prefers, before inserting the images into PPT).
  • I placed text boxes on top of the images.
  • Once done, I saved as a PDF, and then went to upload to CS. I uploaded and tweaked and viewed the Digital Proofreader tool about a dozen times the first day I did it, as I wanted to move text a tad up or down, and as I resolved the complaints about DPI not being great.
  • (You do the same process for the cover image, and CS is pretty good about telling you how to calculate your spine size for the number of pages in the book, and adding that in to the front/back cover size to calculate what you need. You can also get a sized template from them, and then use images and cover it up so it’s sized perfectly.)
  • Once you’re happy with what’s uploaded to the system, you submit to CS for review (takes 24 hours). You then get to review another digital proof, and a PDF version, and then get the chance to order a physical proof copy!

Tl;dr version 2 – it was actually super easy, even for someone who’s not a graphic designer, to do this. This was a great method to work with an illustrator with simple iPhone photos of awesome illustrations and turn them into a book. You could probably also scan and do all kinds of fancy stuff…but for a basic book, the basic process described above works great. It actually doesn’t take much time in terms of placing text or uploading and tweaking your file.

The hardest part was calculating the size of the pages and deciding on whether to do with bleed or without bleed.

The other hardest part was keeping the topic of the book a secret from my mom for 10 months, because I thought she’d get a bigger kick out of being surprised with the book’s topic and contents when she had a finished copy in her hands. Sorry, Mom! Hopefully you thought it’s worth it. :)

front and back of "Carolyn's Robot Relative" by @DanaMLewis

More open innovation coming soon?

This is a big deal: JDRF just announced funding for companies to open up their device protocols, with an explicit mention of projects including OpenAPS.

This is something we’ve been asking companies for over many years, but even the most forward-thinking diabetes device companies are still limiting patients to read-only retrospective access to the patient’s own data. That’s a start, but it isn’t enough.  We need all device makers to take the next step toward full and open interoperability: participating in open-protocol development of pumps and AP systems. If funding from a major organization like JDRF is what will be needed to prioritize this, great: we’re really excited to see them doing so.

Many of us in the diabetes community have chosen to accept the risk of a flawed device, because of the net risk reduction -and quality of life improvements – that come from being able to DIY closed loop. But that doesn’t mean we’re 100% happy with that.

  • We shouldn’t have to bandaid our pumps – literally – with tape.
  • We shouldn’t have to buy them second hand.
  • We should be able to use in-warranty devices that aren’t physically broken.

In order to use our medical devices in the safest and most effective way possible, we need the ability to remotely and safely control our devices – and understand them – as we see fit.  That means the makers of the medical devices we rely on need to openly document the communications protocols their devices use, so that any informed patient, or any company or organization operating on their behalf, can safely interact with the device.

It’s a big deal for JDRF to put resources into helping companies figure out how to do this, and ease liability and regulatory concerns. Thanks to everyone who’s been a vocal advocate in the DIY community; in organizations like JDRF; and individuals advocating at the medical device companies as well.  And props to the FDA, who last month released official guidance encouraging device makers to “design their devices with interoperability as an objective” and “clearly specify the relevant functional, performance, and interface characteristics to the user.”

We all have the same goals – to make life better, and safer, for those of us living with type 1 diabetes. I’m excited to see more efforts like this that further align all of our activities toward these goals.

To the diabetes device companies: we’ve long said we are happy to help if you want to figure out how to do this. Hopefully, you already have ideas about how to do this smartly and safely. But if you need help, let us know – we’re happy to help, because #WeAreNotWaiting and neither should you.

 

How I change pump sites

Last year, I wrote about how I “pre-soak” CGM sensors for better first-day BGs. That’s something I started doing years ago whenever possible.

Similarly, in the last few years, I’ve also changed how I change my pump sites with similar goals of improved outcomes, whenever possible.

What I used to do (i.e. for 12+ years):

  • Pull out pump site
  • Take shower
  • Put in new pump site
  • If the pump site didn’t work, spend all night high, or the next hours high while I debated whether it was just “slow” or if I needed a second new site. Ugh.

What I decided to start doing and have done ever since (unless a site gets pulled out by accident):

  • On day 3 when I decide to change my pump site, I do not take my “old” pump site out before my shower.
  • After my shower, I leave in the old pump site and put the new pump site on. Which means I am wearing TWO pump sites.
  • Put the tubing on the new site etc. as expected. But because I have the old site on, if I start to see BGs creep up, I can do one of two things:
    • 1) Swap tubing back to old site, give a bolus or a prime on the old site, then switch tubing back to new site. (I do this if I think the new site is working but “slow”)
    • 2) Swap tubing back to old site, ditch the new site, and then insert a second “new” site (or wait until the next morning to do so when I feel like it)
  •  Otherwise, if BGs are fine, I pull the “old” site out once I confirm the new site is good to go.

Is this method perfect? Nope. Does it usually help a lot when I have a new site that is kinked or otherwise a dud? Yup.

To me, it’s worth keeping the old site on for a few (or even ~12) hours. I know many people may not like the idea of “wearing two sites”. But it’s not wearing two sites for 3 days. And if you find yourself having a lot of kinked sites – that’s why and when I switched over to this approach.

YDMV, always. But hope this (post-soaking?) of pump sites, like the idea of pre-soaking CGM sensors, is helpful to someone else.

Why a non-academic (patient) publishes in academic journals

Today I was able to share that my Letter to the Editor was published in the Journal of Diabetes Science and Technology. It’s on why we need to set expectations to help patients successfully adopt hybrid closed loop/artificial pancreas/automated insulin delivery system technology. (You can read it via image copies in the first link.)

JDST_screenshot_LTE_expectationsI’ve published a few times in academic journals. Last year, Scott and I published another Letter to the Editor in JDST with the OpenAPS outcomes study we had presented at the 2016 ADA Scientific Sessions conference.

But, I’m sure people are wondering why I choose to do so – especially as I am 1) a patient and 2) a non-academic. (Although in case you missed it – I’m now the Principal Investigator on a grant-funded study!)

While there are many healthcare providers, researchers, industry employees, FDA staff, etc. who read blogs like this and are up to speed on the bleeding edge of diabetes technology… there are easily 10x the number that do not.

And if they don’t know about the existence of this world, they won’t know about the valuable lessons we’re learning and won’t be able to share those lessons and knowledge with other healthcare providers and the patients that they treat.

So, in my pursuit to find more ways to share knowledge from our community with the rest of the diabetes community, this is why we submit abstracts for posters and presentations to conferences like ADA’s Scientific Sessions. Our abstracts are evaluated just like the abstracts from traditional healthcare providers (as far as they can tell, I’m just another academic, albeit one with fewer credentials ;)), and I’m proud that they’re evaluated and deemed worthy of poster presentations alongside mainstream researchers. Ditto for our written publications, whether they be letters to the editor or other types of articles submitted to journals and publications.

We need to find more ways to share and distribute knowledge with the “traditional” medical and academic research world. And I’d love to do more – so please share ideas if you have them. And if you’re someone who bridges the gap to the traditional world, I appreciate your help sharing these types of articles and conversations with your colleagues.

What I wish CDEs (diabetes educators) and other HCPs knew about DIY and other diabetes tech (#OpenAPS or otherwise)

I had the awesome opportunity to present at #AADE17, the annual education meeting for the American Association of Diabetes Educators, this past weekend. My topic was about OpenAPS and DIY diabetes… which really translates to some broader things I want all educators and HCPs to know about patients and technology, whether it’s DIY or just unknown to them. Unfortunately AADE didn’t record or livestream my session, so I wanted to write up a summary of the content here.

(If you’re new to this blog/me/OpenAPS, you can also watch this June 2017 TEDX talk where I share some of the story of how I ended up with a DIY artificial pancreas and how the OpenAPS community came to be; or this older talk from OSCON 2016 as well. As always, if you’re curious to learn more about OpenAPS or wondering how to build your own DIY artificial pancreas, OpenAPS.org is the first place to learn more!)

Diabetes is hard. Even if you are privileged to have access to insulin, education, and technology – it can still be so incredibly hard to get it right. And even if you do everything “right”, the outcomes will still vary. And after all, the devices themselves are not perfect, and we still have diabetes.

The lack of varying alarms and the unchangeable volume is what led me to create DIYPS (my open loop and louder alarm system), and the same frustration with lack of data access and visualization led John Costik, Lane Desborough, Ben West, and so many others to explore creating other DIY tools, such as Nightscout. And thanks to social media, we all didn’t have to create in a vacuum: we can share code (this is what open source means) and insight through social media, and build upon each other’s work. As a result, these collaborations, sharing, and iterative development is how OpenAPS, the open source artificial pancreas system movement, was created.

I tweet and talk and share frequently about how great it is having #OpenAPS in my life. Norovirus? No problem. Changes in sensitivity due to exercise? Not the biggie it used to be.

However, this technology is by no means a cure. It still requires work on the part of the person with diabetes. We still have to:

  • Change pump sites
  • Change CGM sensors
  • Calibrate regularly
  • Deal with bonked pump sites and sensors that fall out

And also, given the speed of insulin, most people are still going to engage with the system for some kind of meal bolus or announcement. This is why it’s called “hybrid” closed loop technology. (However, depending on the sophistication of the technology, you start to get to be able to choose what you want to optimize for and the behaviors you want to choose to do less of, which is great.)

In some cases, we humans know more than the technology: such as when a meal is going to happen/is coming, and when exercise is going to happen. So it’s nice to be able to interoperate your devices and be able to use your phone, watch, computer, etc. to be able to tell the system what to do differently (i.e. set higher targets in the case of activity, or lower targets to achieve “eating soon” mode , or in the case of waking up).

But in a LOT of cases, it’s tiring for the human to have to think about all the things. Such as whether a pump site is slowly dying and causing apparent insulin resistant. Or such as when you’re more sensitive 12-24 hours after exercise. Or during menstrual cycles. Or when sick. Or during a growth spurt. Or during jet lag. Or during a trip where you can’t find anything to eat. Etc. It’s a lot for us PWD’s to track, and this is where computers come in handy. Things like autosensitivity in OpenAPS to automatically detect changes in sensitivity and adjust the variables for calculations automatically; and autotune, to track the data of what’s actually happening and make recommendations for changing your underlying pump settings (ISF, carb ratio, and basal rates).

And how has this technology been developed by patients? Iteratively, as we figure out what’s possible. It’s not about boiling the ocean; it’s about approaching problems bit by bit as we have new tools to solve them, or new people with energy to think about the problem in different ways. It’s like thinking about getting a car – you wouldn’t expect the manufacturer to sell bits and pieces of the car frame, and you don’t really expect medical device manufacturers to sell bits and pieces of a pump or other device. However, patients are closest to the REAL problems in living with diabetes. Instead of a “car”, they’re looking for solutions for getting from point A to point B. And so in the car analogy, that means starting with a skateboard, scooter, or bike – and ending up with a car is great, but the car is not the point.

So no, any piece of technology isn’t going to be a cure or solve all problems or work perfectly for everyone. But that is true whether it’s DIY or a commercial tool: one size certainly does not fit all. And patients are individuals with their own lives and their own challenges with diabetes, with different motivations around what aspects of life with diabetes feel like friction and what they feel equipped to tackle and solve.

So, here’s some of what’s on my list for what I’d like CDE’s and other HCP’s to know as a result of the proliferation of technology around diabetes:

  • Yes, DIY tech is often off label. But that’s ok – it just means it’s off label; it doesn’t prevent you from listening to why patients are using it, what we think it’s doing for us, and it doesn’t prevent you from asking questions, learning more, or still advising patients.
  • Don’t make us switch providers by refusing to discuss it or listen to it, just because it’s new/different/you don’t understand it. (By the way: we don’t expect you to understand all possible technology! You can’t be experts on everything, but that doesn’t mean shunning what you don’t know.)
  • You get to take advantage of the opportunity when someone brings something new into the office – it’s probably the first of many times you’ll see it, and the first patient is often on the bleeding edge and deeply engaged and understands what they’re using, and open to sharing what they’ve learned to help you, so you can also help other patients!
  • You also get to take advantage of the open source community. It’s open, not just for patients to use, but for companies, and for CDEs and other HCPs as well. There are dozens if not hundreds of active people on Twitter, Facebook, blogs, forums, and more who are happy to answer questions and help give perspective and insight into why/how/what things are.
  • Don’t forget – many of the DIY tools provide data and insight that currently don’t exist in any traditional and/or commercially and/or FDA-approved tool. Take autotune for example – there’s nothing else out there that we know of that will tune basal rates, ISF, and carb ratio for people with pumps. And the ability of tools like Nightscout reports to show data from a patient’s disparate devices is also incredibly helpful for healthcare providers and educators to use to help patients.

And one final point specific to hybrid closed loop technology: this technology is going to solve a lot of problems and frustrations. But, it may mean that patients will shift the prioritization of other quality of life factors like ease of use over older, traditionally learned diabetes behaviors. This means things like precise carb counting may go by the wayside for general meal size estimations, because the technology yields similar outcomes. Being aware of this will be important for when CDE’s are working with patients; knowing what the patterns of behaviors are and knowing where a patient has shifted their choices will be helpful for identifying what behaviors can be adapted to yield different outcomes.

I think the increase in technology (especially various types of closed loops, DIY and commercial) will yield MORE work for CDE’s and HCP’s, rather than less. This means it’s even more important for them to get up to speed on current and evolving technology – because it’s by no means going away. And the first wave of DIY’ers have a lot we can share and teach not just other patients, but also CDE’s. So again, many thanks to AADE for the opportunity to share some of this perspective at #AADE17, and thanks to everyone for the engagement during and after the session!

Different ways to make a difference

tl,dr: There are many ways to make a difference, ranging from donating time/energy/ideas to financially supporting organizations who are making a difference.

When I was first diagnosed with diabetes (at age 14, three months into high school – ugh), I was stunned. And I didn’t want anyone to know, because I didn’t want to be treated differently. So for the first few months, I learned how to take care of myself, and did that quietly and went about my life: school, color guard, etc. I was frustrated with the idea of having to do all this stuff for the rest of my life, and wanted as little as possible to have to talk/think about it beyond the bare minimum I had to do.

However, after I talked the Latin Club into making our fundraising dollars from the Rake-a-thon go toward the American Diabetes Association, and I saw the reaction of the local staff when I walked in and dropped a check on the desk and turned around and tried to walk out the door. (They didn’t let me just walk out!) I agreed to volunteer and do more, and it changed my life.

I don’t know what first thing I did, but I quickly came to realize that doing things for the broader population of people with diabetes – maybe they had type 2, maybe they lived somewhere else, didn’t matter – made me feel SO much better about my own life with type 1 diabetes. I wasn’t alone. And so my mantra became “Doing something for someone else is more important than anything you would do for yourself.” And it’s proved to be true for me for 14 years.

Since I grew up in Alabama, that’s where I started getting involved first. Inspired by my parents’ volunteer efforts that I saw growing up, I would volunteer my time and energy for a variety of things:

  • Fundraising for the local walk
  • Actually helping out the day of the walk
  • Joining the planning committee for the walk and spending months helping figure everything out and doing both actual and metaphorical heavy lifting to help make the event happen

Because of my volunteer efforts, I was asked to speak at a fundraising breakfast in Birmingham. It was my first time ever giving a public talk, let alone publicly talking about living with diabetes. And because of the people I met that day, I began doing more volunteer things around the state – and it led me to applying and being selected as the National Youth Advocate for the American Diabetes Association, and later serving on national committees like the National Youth Strategies committee (where we developed and improved the “Wisdom” kits for newly diagnosed kids with diabetes, created a kid-focused section of the ADA website, etc.). And my involvement continued as I graduated college and moved to Seattle, still serving on national committees but also joining the Western Washington Leadership Board and doing the same type of local event volunteering, but now in Seattle. I also have done more around advocacy over the years, beyond my time as NYA. While in college, I was asked to testify before the Senate HELP committee, talking about the need to increase funding for disease research. I’ve also participated regularly in ADA’s Call to Congress, including this year, where Scott and I paid to fly to DC and talk with our Washington state representatives and senators about the critical need for funding NIH & CDC; maintaining critical diabetes programs; and the issues around insulin affordability.

But it was when I was asked to represent the US and attend the World Diabetes Congress in 2006 when my eyes were opened to the issues around insulin access and affordability.

IDF first did a youth ambassador program in 2006, bringing around two dozen young adults with diabetes to the World Diabetes Congress to participate, train in advocacy activities, etc.

Having grown up in Alabama, where diabetes (particularly type 2) is highly prevalent, I knew that not everyone could afford pumps and CGMs (especially back then, when CGMs were brand new, way less accurate, and still super expensive, even with insurance coverage). I also knew that insulin & supplies were expensive, and some people struggled with gaining access to them. (And I always felt very fortunate that since diagnosis, my parents were able to afford my insulin & supplies.)

However, while in South Africa, I learned from my new friends from other parts of Africa and the rest of the world that this was the tippy top of the ice berg. I learned about:

  • Kids are walking alone on roads for miles and hours to get to a clinic to get a single, daily shot of insulin.
  • They may only test their BGs once a week, or month, or quarter.
  • It’s not just kids – adults would have to stop working and walk for hours, too, choosing to get insulin to stay alive to be able to work another few days to help their family survive.
  • Some people would only get insulin once a week, if that, or once a day – compared to me, where I might have several injections a day, as often as needed to keep my BGs in a safe range.

It was astonishing, saddening, maddening, and terrifying. And living so far away from this part of the world, I wasn’t sure how I could help, until I met Graham Ogle who created the “Life for a Child” program to help tackle the problem, with the vision that no child should die of diabetes. Life for a Child helps less resource-supported countries provide insulin, syringes, other supplies, and education (both for people living with diabetes and healthcare providers). And, they’re a very resource-efficient organization.

When Scott and I first met, he knew nothing about diabetes (and actually thought my insulin pump was a pager – hah!). And while I volunteered a lot of my time and energy to help organizations, he is also dedicated to finding effective ways to safe lives, and as a result, is a longtime donor to Givewell.org and some of their top charities, like Against Malaria Foundation. Givewell is a nonprofit dedicated to finding giving opportunities and publishing the full details of their analysis to help donors decide where to give. And unlike charity evaluators that focus solely on financials, assessing administrative or fundraising costs, they conduct in-depth research aiming to determine how much good a given program accomplishes (in terms of lives saved, lives improved, etc.) per dollar spent.

Therefore, when Scott and I got married, we decided that in lieu of wedding-related gifts, we would ask people to support our charities of choice, to further increase the impact we would be able to have in addition to our own financial and other resource donations.

However, Life for a Child was not evaluated by Givewell. So Scott and I got on a Skype call with Graham Ogle to crunch through the numbers and try to come up with an idea for how effective Life for a Child is, similar to what Givewell has already done for other organizations.

For example, the Against Malaria Foundation, the recommended charity with the most transparent and straightforward impact on people’s lives, can buy and distribute an insecticide-treated bed net for about $5.  Distributing about 600-1000 such nets results in one child living who otherwise would have died, and prevents dozens of cases of malaria.  As such, donating 10% of a typical American household’s income to AMF will save the lives of 1-2 African kids *every year*.

Life for a Child seems like a fairly effective charity, spending about $200-$300/yr for each person they serve (thanks in part to in-kind donations from pharmaceutical firms). If we assume that providing insulin and other diabetes supplies to one individual (and hopefully keeping them alive) for 40 years is approximately the equivalent of preventing a death from malaria, that would mean that Life for a Child might be about half as effective as AMF, which is quite good compared to the far lower effectiveness of most charities, especially those that work in first world countries.

(And some of the other charities and organizations don’t have clear numbers that can be this clearly tracked to lives saved. It’s not to say they’re not doing good work and improving lives – they absolutely are, and we support them, too – but this is one of the most clear and measurable ways to donate money and have a known life-saving impact related to diabetes.)

I am asked fairly frequently about what organization I would recommend donating to, in terms of diabetes research or furthering the type of work we’re doing with the OpenAPS community. It’s a bit of a complicated answer, because there is no organization around or backing the OpenAPS community’s work, and there are many ways to donate to diabetes research (i.e. through bigger organizations like ADA and JDRF or directly to research projects and labs if you know of a particular research effort you want to fund in particular).

And also, I think it comes down to seeing your donation make a difference. If you’d ask Scott, he would recommend AMF or other Givewell charities – but he’s seen enough people ask me about diabetes-related donation targets to know that people are often asking us because of wanting to make a difference in the lives of people with diabetes.

So, given all the ways I’ve talked about making a difference with different volunteer efforts (and the numerous organizations with which you could do so), and the options for making a financial donation: my recommendation for the biggest life-saving effort for your dollar will be to donate to Life for a Child, to help increase the number from the 18,000 children and 46 countries they’re currently helping in. (And, they now have a US arm, so if you are in the US your donation is tax-deductible).

You may have a different organization you decide to support – and that’s great. Thank you to everyone who donates money, time, and energy to organizations who are working to make our lives better, longer, and the world in general to be a better place for us all.

Write It Do It: Tips for Troubleshooting DIY Diabetes Devices (#OpenAPS or otherwise)

When I was in elementary school, I did Science Olympiad. (Are you surprised? Once a geek, always a geek…) One of my favorite “events” was “Write It Do It”, where one person would get a sculpture/something constructed (could be Legos, could be other stuff) and you had to write down instructions for telling someone else how to build it. Your partner got your list of instructions, the equipment, and was tasked with re-building the structure.

Building open source code and tools is very similar, now that I look back on the experiences of having built #DIYPS and then working on #OpenAPS. First step? Build the structure. Second step? Figure out how to tell someone ELSE how to do it. (That’s what the documentation is). But then when someone takes the list of parts and your instructions off elsewhere, depending on how they interpreted the instructions…it can end up looking a little bit different. Sometimes that’s ok, if it still works. But sometimes they skip a step, or you forget to write down something that looks obvious to you (but leaves them wondering how one part got left out) – and it doesn’t work.

Unlike in Science Olympiad, where you were “scored” on the creation and that was that, in DIY diabetes this is where you next turn to asking questions and troubleshooting about what to change/fix/do next.

But, sometimes it’s hard.

If you’re the person building a rig:

  • You know what you’re looking at, what equipment you used to get here, what step you’re on, what you’ve tried that works and what hasn’t worked.
  • You either know “it doesn’t work” or “I don’t know what to do next.”

If you’re the troubleshooter:

  • You only know generally how it can/should work and what the documentation says to do; but you only know as much about the specific problem is shared with you in context of a question.

As someone who spends a lot of time in the troubleshooter role these days, trying to answer questions or assist people in getting past where they’re stuck, here are my tips to help you if you’re building something DIY and are stuck.

Tips_online_troubleshooting_DIY_diabetes_DanaMLewis

DO:

  1. Start by explaining your setup. Example: “I’m building an Edison/Explorer Board rig, and am using a Mac computer to flash my Edison.”
  2. Explain the problem as specifically as you can. Example: “I am unable to get my Edison flashed with jubilinux.”
  3. Explain what step you’re stuck on, and in which page/version of the docs. Example: “I am following the Mac Edison flashing instructions, and I’m stuck on step 1-4.” Paste a URL to the exact page in the docs you’re looking at.  Clarify whether your problem is “it doesn’t work” or “I don’t know what to do next.”
  4. Explain what it’s telling you and what you see. Pro tip: Copy/paste the output that the computer is telling you rather than trying to summarize the error message. Example: “I can’t get the login prompt, it says “can’t find a PTY”.”
    (This is ESPECIALLY important for OpenAPS’ers who want help troubleshooting logs when they’ve finished the setup script – the status messages in there are very specific and helpful to other people who may be helping you troubleshoot.)
  5. Be patient! You may have tagged someone with an @mention; and they may be off doing something else. But don’t feel like you must tag someone with an @mention – if you’re posting in a specific troubleshooting channel, chances are there are numerous people who can (and will) help you when they are in channel and see your message.
  6. Be aware of what channel you’re in and pros/cons for what type of troubleshooting happens where.
    My suggestions:

    1. Facebook – best for questions that don’t need an immediate fix, or are more experience related questions. Remember you’re also at the mercy of Facebook’s algorithm for showing a post to a particular group of people, even if someone’s a member of the same group. And, it’s really hard to do back-and-forth troubleshooting because of the way Facebook threads posts. However, it IS a lot easier to post a picture in Facebook.
    2. Gitter – best for detailed, and hard, troubleshooting scenarios and live back-and-forth conversations. It’s hard to do photos on the go from your mobile device, but it’s usually better to paste logs and error output messages as text anyway (and there are some formatting tricks you can learn to help make your pasted text more readable, too). Those who are willing to help troubleshoot will generally skim and catch up on the channel when they get back, so you might have a few hours delay and get an answer later, if you still haven’t resolved or gotten an answer to your question from the people in channel when you first post.
    3. Email groups – best for if no one in the other channels knows the questions, or you have a general discussion starter that isn’t time-constrained
  7. Start with the basic setup, and come back and customize later. The documentation is usually written to support several kinds of configurations, but the general rule of thumb is get something basic working first, and then you can come back later and add features and tweaks. If you try to skip steps or customize too early, it makes it a lot harder to help troubleshoot what you’re doing if you’re not exactly following the documentation that’s worked for dozens of other people.
  8. Pay it forward. You may not have a certain skill, but you certainly have other skills that can likely help. Don’t be afraid to jump in and help answer questions of things you do know, or steps you successfully got through, even if you’re not “done” with your setup yet. Paying it forward as you go is an awesome strategy J and helps a lot!

SOME THINGS TO TRY TO AVOID:

  1. Avoid vague descriptions of what’s going on, and using the word “it”. Troubleshooter helpers have no idea which “it” or what “thing” you’re referring to, unless you tell them. Nouns are good :) . Saying “I am doing a thing, and it stopped working/doesn’t work” requires someone to play the game of 20 questions to draw out the above level of detail, before they can even start to answer your question of what to do next.
  2. Don’t get upset at people/blame people. Remember, most of the DIY diabetes projects are created by people who donated their work so others could use it, and many continue to donate their time to help other people. That’s time away from their families and lives. So even if you get frustrated, try to be polite. If you get upset, you’re likely to alienate potential helpers and revert into vagueness (“but it doesn’t work!”) which further hinders troubleshooting. And, remember, although these tools are awesome and make a big difference in your life – a few minutes, or a few hours, or a few days without them will be ok. We’d all prefer not to go without, which is why we try to help each other, but it’s ok if there’s a gap in use time. You have good baseline diabetes skills to fall back on during this time. If you’re feeling overwhelmed, turn off the DIY technology, go back to doing things the way you’re comfortable, and come back and troubleshoot further when you’re no longer feeling overwhelmed.
  3. Don’t go radio silent: report back what you tried and if it worked. One of the benefits of these channels is many people are watching and learning alongside you; and the troubleshooters are also learning, too. Everything from “describing the steps ABC way causes confusion, but saying XYZ seems to be more clear” and even “oh wow, we found a bug, 123 no longer is ideal and we should really do 456.” Reporting back what you tried and if it resolved your issue or not is a very simple way to pay it forward and keep the community’s knowledge base growing!
  4. Try not to get annoyed if someone helping out asks you to switch channels to continue troubleshooting. Per the above, sometimes one channel has benefits over the other. It may not be your favorite, but it shouldn’t hurt you to switch channels for a few minutes to resolve your issue.
  5. Don’t wait until you’re “done” to pay it forward. You definitely have things to contribute as you go, too! Don’t wait until you’re done to make edits (PRs) to the documentation. Make edits while they’re fresh in your mind (and it’s a good thing to do while you’re waiting for things to install/compile ;)).

These are the tips that come to mind as I think about how to help people seek help more successfully online in DIY diabetes projects. What tips would you add?

Making it possible for researchers to work with #OpenAPS or general Nightscout data – and creating a complex json to csv command line tool that works with unknown schema

This is less of an OpenAPS/DIYPS/diabetes-related post, although that is normally what I blog about. However, since we created the #OpenAPS Data Commons on Open Humans, to allow those of us who desire to donate our diabetes data to research, I have been spending a lot of time figuring out the process from uploading your data to how data is managed and shared securely with researchers. The hardest part is helping researchers figure out how to handle the data – because we PWDs produce a lot of data :) . So this post explains some of the challenges of the data management to get it to a researcher-friendly format. I have been greatly helped over the years by general purpose open-source work from other people, and one of the things that helps ME the most as a non-traditional programmer is plain language posts explaining the thought process by behind the tools and the attempted solution paths. Especially because sometimes the web pages and blog posts pop higher in search than nitty gritty tool documentation without context. (Plus, I’ve been taking my own advice about not letting myself hold me back from trying, even when I don’t know how to do things yet.) So that’s what this post is!

Background/inspiration for the project and the tools I had to build:

We’re using Nightscout, which is a remote data-viewing platform for diabetes data, made with love and open source and freely available for anyone with diabetes to use. It’s one of the best ways to display not only continuous glucose monitor (CGM) data, but also data from our DIY closed loop artificial pancreases (#OpenAPS). It can store data from a number of different kinds and brands of diabetes devices (pumps, CGMs, manual data entries, etc.), which means it’s a rich source of data. As the number of DIY OpenAPS users are growing, we estimate that our real-world use is overtaking the amount of total hours of data from clinical trials of closed loop artificial pancreas systems.  In the #WeAreNotWaiting spirit of moving quickly (rather than waiting years for research teams to collect and analyze their own data) we want to see what we can learn from OpenAPS usage, not only by donating data to help traditional researchers speed up their work, but also by co-designing research studies of the things of most value to the diabetes community.

Step 1: Data from users to Open Humans

I thought Step 1 would be the hardest. However, thanks to Madeleine Ball, John Costik, and others in the Nightscout community, a simple Nightscout Data Transfer App was created that enables people with Nightscout data to pop it into their Open Humans accounts. It’s then very easy to join different projects (like the OpenAPS Data Commons) and share your data with those projects. And as the volunteer administrator of the OpenAPS Data Commons, it’s also easy for me to provide data to researchers.

The biggest challenge at this stage was figuring out how much data to pull from the API. I have almost 3 years worth of DIY diabetes data, and I have numerous devices over time uploading all at once…which makes for large chunks of data. Not everyone has this much data (or 6-7 rigs uploading constantly ;)). Props to Madeleine for the patience in working with me to make sure the super users with large data sets will be able to use all of these tools!

Step 2: Sharing the data with researchers

This was easy. Yay for data-sharing tools like Dropbox.

Step 3: Researchers being able to use the data

Here’s where thing started to get interesting. We have large data files that come in json format from Nightscout. I know some researchers we will be working with are probably very comfortable working with tools that can take large, complex json files. However…not all will be, especially because we also want to encourage independent researchers to engage with the data for projects. So I had the belated realization that we need to do something other than hand over json files. We need to convert, at the least, to csv so it can be easily viewed in Excel.

Sounds easy, right?

According to basic searches, there’s roughly a gazillion ways to convert json to csv. There’s even websites that will do it for you, without making you run it on the command line. However, most of them require you to know the types of data and the number of types, in order to therefore construct headers in the csv file to make it readable and useful to a human.

This is where the DIY and infinite possibility nature of all the kinds of diabetes tools anyone could be using with Nightscout, plus the infinite ways they can self-describe profiles and alarms and methods of entering data, makes it tricky. Just based on an eyeball search between two individuals, I was unable to find and count the hundred+ types of data entry possibilities. This is definitely a job for the computer, but I had to figure out how to train the computer to deal with this.

Again, json to csv tools are so common I figured there HAD to be someone who had done this. Finally, after a dozen varying searches and trying a variety of command line tools, I finally found one web-based tool that would take json, create the schema without knowing the data types in advance, and convert it to csv. It was (is) super slick. I got very excited when I saw it linked to a Github repository, because that meant it was probably open source and I can use it. I didn’t see any instructions for how to use it on the command line, though, so I message the author on Twitter and found out that it didn’t yet exist and was a not-yet-done TODO for him.

Sigh. Given this whole #WeAreNotWaiting thing (and given I’ve promised to help some of the researchers in figuring this out so we can initiate some of the research projects), I needed to figure out how to convert this tool into a command line version.

So, I did.

  • I taught myself how to unzip json files (ended up picking `gzip -cd`, because it works on both Mac and Linux)
  • I planned to then convert the web tool to be able to work on the command line, and use it to translate the json files to csv.

But..remember the big file issue? It struck again. So I first had to figure out the best way to estimate the size and splice or split the json into a series of files, without splitting it in a weird place and messing up the data. That became jsonsplit.sh, a tool to split a json file based on the size you give it (and if you don’t specify, it defaults to something like 100000 records).

FWIW: 100,000 records was too much for the more complex schema of the data I was working with, so I often did it in smaller chunks, but you can set it to whatever size you prefer.

So now “all” I had to do was:

  • Unzip the json
  • Break it down if it was too large, using jsonsplit.sh
  • Convert each of these files from json to csv

Phew. Each of these looks really simple now, but took a good chunk of time to figure out. Luckily, the author of the web tool had done much of the hard json-to-csv work, and Scott helped me figure out how to take the html-based version of the conversion and make it useable in the command line using javascript. That became complex-json2csv.js.

Because I knew how hard this all was, and wanted other people to be able to easily use this tool if they had large, complex json with unknown schema to deal with, I created a package.json so I could publish it to npm so you can download and run it anywhere.

I also had to create a script that would pass it all of the Open Humans data; unzip the file; run jsonsplit.sh, run complex-json2csv.js, and organize the data in a useful way, given the existing file structure of the data. Therefore I also created an “OpenHumansDataTools” repository on Github, so that other researchers who will be using Nightscout-based Open Humans data can use this if they want to work with the data. (And, there may be something useful to others using Open Humans even if they’re not using Nightscout data as their data source – again, see “large, complex, challenging json since you don’t know the data type and count of data types” issue. So this repo can link them to complex-json2csv.js and jsonsplit.sh for discovery purposes, as they’re general purpose tools.) That script is here.

My next TODO will be to write a script to take only slices of data based on information shared as part of the surveys that go with the Nightscout data; i.e. if you started your DIY closed loop on X data, take data from 2 weeks prior and 6 weeks after, etc.

I also created a pull request (PR) back to the original tool that inspired my work, in case he wants to add it to his repository for others who also want to run his great stuff from the command line. I know my stuff isn’t perfect, but it works :) and I’m proud of being able to contribute to general-purpose open source in addition to diabetes-specific open source work. (Big thanks as always to everyone who devotes their work to open source for others to use!)

So now, I can pass researchers json or csv files for use in their research. We have a number of studies who are planning to request access to the OpenAPS Data Commons, and I’m excited about how work like this to make diabetes data more broadly available for research will help improve our lives in the short and long term!