Improving #OpenAPS connectivity with automatic Bluetooth tethering (and switching)

One of my favorite things about developing and designing new OpenAPS tools is that if it works for me, it probably will work for someone else, too, and is worth sharing. These little tweaks and hacks add up to improving the real-world lived experience (usability) of living with DIY devices quite a bit…and I’m hoping that continuing to remove that friction enables people with diabetes to live their lives & take action more easily elsewhere, less distracted by diabetes.

So this weekend, Saturday was about enabling easier re-running of the setup scripts to add advanced features more easily in the future.

But Sunday became all about Bluetooth.

Background

Recently, several people have made a concerted effort to create and improve the directions to enable people to connect their OpenAPS rigs to their phones, using Bluetooth.

Without Bluetooth capabilities, when someone left the house or a known wifi network, they would either have to plug in a CGM receiver to get BGs (or have xDrip); or “hotspot” their phone to connect the rig to the Internet. It wasn’t a big deal, but it was something else you had to get into the habit of doing every time you left.

With Bluetooth tethering, you can connect your rig to the phone. And we added the feature so that if you dropped off a wifi network (you left home; or your router at home went down), then your rig automatically established Bluetooth connection and your phone would provide Internet connectivity to your rig. Great!

Making it easier for PWDs with loved ones (spouses/partners/parents/etc.) supporting them

However, today I noticed that because I have both Scott and my phones enabled and configured, sometimes the rigs would grab my phone’s hotspot, and sometimes his (depending on the timing). As the PWD, I would prefer my phone to be the primary phone for Bluetooth, and to only grab Scott’s if mine is out of range/unavailable. And I realized that this will probably be true for most people: kids may sometimes carry a phone, but not always, so it’ll make sense to check for a PWD’s phone first before cycling to try their support network’s phones next.

..so off we went to build that in. Scott also added code that makes it so that if your rig spots an open wifi, but it has a captive portal (meaning it requires passwords or accepting T&C, which the computer can’t automatically do, so it really doesn’t enable Internet access) and wifi ultimately doesn’t work, it will turn off wifi so the Bluetooth can provide connectivity..until the Bluetooth goes away. So it makes it easier for the rig to automatically stay online while you’re going to and from various places that do and don’t have open wifi networks for connectivity.

More connectivity is awesome

I was telling someone the other day why having easier connectivity and remote troubleshooting options is awesome – even as an adult. When a PWD is busy (at school, or on a stage presenting, or at a meeting, or whatever), a loved one can remote in and see what’s going on in the rig and resolve any issues, allowing the PWD to live their life.

That’s something to ask the commercial manufacturers of AP systems as they are in the pipeline to roll out to the broader community of people living with diabetes. For any commercial system you’re considering, ask the manufacturer:

  • How will your system enable me to live my life successfully?
  • How can see I easily see my data in the ways that I want to see it, on the devices that I want to see it on?
  • How will my loved ones be able to see my data?
  • How will my loved ones in a different location be able to help troubleshoot when things are going on?

These are the details that make the difference. This is why #WeAreNotWaiting.

Feedback on proposed FDA guidance on interoperable medical devices

Our friend Anna McCollister-Slipp first alerted us to the proposed draft guidance recently released from the FDA, covering medical device interoperability. (You can read the draft guidance linked here.) We were subsequently among those asked by Amy Tenderich, and others, to share our initial thoughts and comments in response to the draft guidance. We wanted to publicly share our initial thoughts as a draft comment in response to the proposed guidelines (which we plan to officially submit as well), in hopes of encouraging subsequent discussion and additional commentary submitted in response to the draft guidance. We’d love to hear your thoughts after you read the linked guidance, as well as our comment below, and also encourage you to consider submitting a comment to the FDA regarding the guidance.

Draft comment response by Scott Leibrand & Dana Lewis:

The proposed FDA guidance on medical device interoperability is a gesture in the right direction, and is clearly intended to encourage medical devices to be designed with interoperability in mind. However, in the current draft form, the proposed guidance focuses too much on *discouraging* manufacturers from including the kinds of capabilities necessary to allow for continued innovation (particularly patient-led innovation as seen from the patient-driven #WeAreNotWaiting community).  Instead, much of the guidance assumes that manufacturers should only provide the bare minimum level of interoperability required for the intended use, and even goes so far as to suggest they “prevent access by other users” to any “interface only meant to be used by the manufacturer’s technicians for software updates or diagnostics”.  There is also much note of “authorized users”, which is language that is often currently leaned upon in the real world to exclude patients from accessing data on their own medical devices – so it would be worthwhile to further augment the guidance and/or more specifically review the implications of the guidance with an eye toward patients/users of medical devices.  The focus on including information on electronic data interfaces in product labeling is a good inclusion in the guidance, but it would be far more powerful (and less likely to be interpreted as a suggestion to cripple future products’ interoperability capabilities) if manufacturers were encouraged to properly include interface details for *all* their interfaces, not just those for which the manufacturer has already identified an intended use case.

Specific suggestions for improving the proposed guidance on medical device interoperability:
  • The guidance needs to more explicitly encourage manufacturers to design their products for *maximum* interoperability, including the ability for the device to safely interoperate with devices and for use cases that are not covered by the manufacturer’s intended uses.
  • Rather than designing device interoperability characteristics solely for intended uses, and withholding information related to non-intended uses, manufacturers should detail in product labeling the boundaries of the intended and tested use cases, and also provide information on all electronic data interfaces, even those with no manufacturer-intended use.  Labeling should be very clear on the interfaces’ design specifications, and should detail the boundaries of the uses the manufacturer intended, designed for, and tested.
  • The guidance should explicitly state that the FDA supports allowing third parties to access medical devices’ electronic data interfaces, according to the specifications published by the manufacturers, for uses other than those originally intended by the manufacturer.  They should make it clear that any off-label use by patients and health care professionals must be performed in a way that interoperates safely with the medical device per the manufacturer’s specifications, and it is the responsibility of the third party performing the off-label use, not the manufacturer, to ensure that they are making safe use of the medical device and its electronic data interface.  The guidance should make clear that the manufacturer is only responsible for ensuring that the medical device performs as specified, and that those specifications are complete and accurate.
With these kinds of changes, this guidance could be a powerful force for improving the pace of innovation in medical devices, allowing us to move beyond “proprietary” and “partnership” based solutions to solutions that harness the full power of third-party innovation by patients, health care professionals, clinical researchers and other investigators, and startup technology companies.  The FDA needs to set both clear rules that require manufacturers to document their devices capabilities as well as guidance that encourages manufacturers to provide electronic data interfaces that third parties can use to create new and innovative solutions (without introducing any new liability to the original manufacturer for having done so).  If the FDA does so, this will set the stage to allow innovation in medical devices to parallel the ever-increasing pace of technological innovation, while preserving and expanding patients rights to access their own data and control their own treatment.