safety

#OpenAPS rigs are shrinking in size

by Dana Lewis

My newest #OpenAPS rig is roughly the size of two sticks of Chapstick.

Small "explorer board" OpenAPS rig next to a stick of chapstick for size comparison

Think about that, especially in context of my earliest rig of a Raspberry Pi, Carelink stick, battery with enough power to last a full 12 hour day (or more), and the bulk that it added to my bag. I was happy to carry it, but once Oskar started working on a smaller rig with better range, for many people it was a game changer!

Components of an #OpenAPS implementation: pump; CGM; Raspberry Pi with battery and a radio communication device

And now we have another option with a new open source hardware board called the “915MHz Edison Explorer Board“. It’s a board designed to hold an Intel Edison (the ‘mini computer’), and it also has a 900MHz antenna on it – which means we can use it to talk to the insulin pump. This eliminates the need for a separate ‘radio stick’ – like the Carelink or a TI or similar. This is a huge improvement!

What carrying the new rig looks like:

This is what a full rig setup looks like:

  1. Insulin pump
  2. CGM
  3. Explorer Board rig
Showing the rig in size comparison with the pump

…and that’s all that’s strictly required. You can use openxshareble to read BG data from the receiver directly, but that’s currently the flakiest part of my setup, so I still recommending hotspotting your phone to pull BG data down from the cloud – and more importantly, so you can use Nightscout or similar to visualize what the loop is doing.

So, today’s post is about the new, shiny, smaller rig, and I know everyone wants to know how to get the parts to build their own!

**Update** – You can order an Explorer Board here. . Keep in mind Edison and battery are not included, so if you don’t already have an Edison, you’ll want to order one of those, too.

Improved #OpenAPS docs in the works, too!

Also, stay tuned – we have a new setup script and guide being developed and tested to streamline the setup of an OpenAPS implementation using this board or any of the previous hardware. These new docs will streamline the installation and configuration of the components required for anyone to build a new OpenAPS implementation for themselves, so they can more easily focus on testing the algorithm and decision making process that’s a critical part of DIY looping.

 

Old news alert: FDA is monitoring the DIY community

by Dana Lewis
There was a news article today that got a lot of people to react strongly. In that sense, the article did it’s job, to get people talking. But that doesn’t mean it got all the details right, as an insider to the DIY community would know.

What am I talking about?

There was an article posted today in “Clinical Endocrinology News” with the titillating headline of “FDA Official: We’re monitoring DIY artificial pancreas boom”.

Guess what, though? This is NOT news. We’ve been talking to the FDA, and they’ve in fact been “monitoring” us (especially if monitoring includes reading this blog, DIYPS.org ;)) since the summer of 2014, before we even turned our eyes toward closing the loop. Definitely since we, while they were in the room at a D-Data in 2015, announced we would close the loop. And even more so after we closed the loop and then decided to go the #OpenAPS route and find a way to make closed loop technology open source. And others from the community, like Ben West, have been talking with the FDA for even longer than we have.

What the article got right:

Recently at AADE, Courtney Lias from FDA (who gave a similar presentation at D-Data a month ago) gave a presentation talking about AP technology. She addressed both how the FDA is looking at the DIY community (they believe that they have enforcement discretion, even though no one in the DIY community is distributing a medical device, which is legally where FDA has it’s jurisdiction) and how it’s looking at the commercial vendors with products in the pipeline.

Courtney highlighted questions for CDE’s to ask patients of theirs who may be bringing up (or bringing in) DIY closed loops. They are good questions – they’re questions we also recommend people ask themselves and are a critical part of the safety-first approach the DIY community advocates every day.

(It was not mentioned in this article, but Aaron Kowalski’s presentation at AADE also highlighted some critical truths that I think are key about setting and managing expectations regarding closed looping. I often talk about these in addition to pointing out that it should be a personal, informed choice in choosing to closed loop. I hope these points about setting expectations and our points about the stages of switching from standard diabetes tool to closed looping becomes a bigger part of the conversation about closed loop safety and usability in the future.)

Where the article linked together some sentences that caused friction today:

The end of the article had a statement along the lines of an FDA concern about what happens if an AP breaks and you have a newly diagnosed person who doesn’t have old school, manual diabetes methods to fall back on. The implication appeared to be that these concerns were solely about the DIY looping “boom”. However, we know from previous presentations that Courtney/FDA usually brings this up as a concern for commercial/all AP technology – this isn’t a “concern” unique to DIY loops.

And that’s the catch – all of the concerns and questions FDA has, the DIY community has, too!

In fact, we want FDA to ask the same questions of commercial vendors, and we are going to be reaching out to the FDA to ask how they will ensure that we, as patients, can ask and get answers to these questions as end users when the FDA is approving this technology.

Because that’s the missing piece.
Right now, with the current technology on the market, we don’t get answers or insight into how these systems and devices work. This is even MORE critical when we’re talking about devices that automate insulin delivery, as the #OpenAPS community has learned from our experiences with looping. Getting the right level of data access and visibility is key to successful looping, and we expect the same from the commercial products that will be coming to market – so the FDA has a role to play here.

What we can do as a result
And we have a role, too. We’ll play our part by communicating our concerns and questions directly to the FDA, which is the only way they can officially respond or react or adjust what they’re doing. They unfortunately can’t respond to tweets. So I’m drafting an email to send to FDA, which will include a compilation of many of the questions and concerns the community has voiced today (and previously) on this topic.

Moving forward, I hope to see others do the same when concerns and questions come up. You don’t need to work for a commercial manufacturer, or be a part of a formal initiative, in order to talk to the FDA. Anyone can communicate with them! You can do that by sending an email, submitting a pre-submission, responding to draft guidances, and more. And we can all, in our informal or formal interactions, ask for clarity and push for transparency and set expectations about the features and products we want to see coming from commercial manufacturers.

OpenAPS poster cited in Nature!

by Dana Lewis

I was thrilled to read a commentary by John Wilbanks and Eric Topol, out in Nature today, titled “Stop the privatization of health data“. (Click here to read a PDF version of the article.)

Tucked on the bottom of the second page of the (PDF version of the) article:

“For instance, in 2014, a woman with type 1 diabetes wired together a tiny processor, an insulin pump and a continuous glucose monitor to automate the regulation of her blood sugar levels. For a small community of patients, the collective use of such ‘home-made’ systems has resulted in improvements that are well ahead of those provided by devices and interventions emerging from conventional markets.1”

(The citation is to the poster that we presented on behalf of the #OpenAPS community at the American Diabetes Association Scientific Sessions meeting last month, with self-reported outcomes from 18 of the first 40 users and builders of DIY artificial pancreas systems)

OpenAPS (n=1)*98 as of July 19, 2016It’s worth noting that there are now (n=1)*98 users of #OpenAPS, so this “small community” is growing fast: doubling approximately every three months.

Wilbanks and Topol highlight some critical truths in their commentary, and call out another (frustrating) diabetes example to illustrate:

“Although patients can monitor their glucose levels at any instant, their aggregate records are not made accessible to them. And there is no mechanism by which patients or researchers outside the company can gain access to Medtronic’s tens of thousands of measurements.”

I’ve written about this specific example before, in fact: new ‘partnerships’ mean my personal health data is likely shared with IBM for Watson’s usage…but I don’t have access to this data or insights, and am in fact missing critical information and data visualization on my FDA-approved medical device that’s been on the market for years.

The call to action for device manufacturers, regulators, and the medical industry is simple: Give me, the patient, my data that I need so I can safely take care of myself and better manage my diabetes.

Wilbanks and Topol emphasize that this won’t happen “…unless each of us takes responsibility for our own health and disease, and for the information that we can generate about ourselves. When it comes to control over our own data, health data must be where we draw the line.”

This needs to happen everywhere, not just in diabetes. Will you join us in drawing the line?

Feedback on proposed FDA guidance on interoperable medical devices

by Dana Lewis

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.

The second year of #DIYPS (and my first full year with a closed loop)

by Dana Lewis

As we developed #DIYPS from a louder alarm system to a proactive alert system (details here about the original #DIYPS system before we closed the loop) to a closed loop that would auto-adjust my insulin pump basal rates as-needed overnight, I have been tracking the outcomes.

There were the first few nights of “wow! this works! I wake up at night when I’m high/low”. Then there were the first 100 nights that involved more iteration, testing, and improvements as we built it out more. And then suddenly it had been a year of using #DIYPS, and it was awesome to see how my average BG and a1c were down – and stayed down – while equally as important, my % time in range was up and stayed up. Not to mention, the quality of life improvements of having better nights of sleep were significant.

Year two has been along the same lines – more improvements on A1c/average BGs, time in range, and sleep – but heavily augmented by the fact that I now have a closed loop. If you follow me on Twitter or have checked out the hashtag, you might be tired of seeing me post CGM graphs. At this point, they all look very similar:

Looping for over a year and OpenAPS still successfully preventing overnight hypoglycemia Overnight safely looping with OpenAPS

(It’s worth noting that I still use #DIYPS, especially during the day to trigger “eating-soon” mode or basically get a snapshot glance at what my BGs are predicted to be, especially if I plan to go out without my loop in tow.)

In this past year, we also went from closing the loop with the #DIYPS algorithms (which required internet connectivity so I could tell the system when I was having carbs), to deciding we wanted to find a way to make it possible for more people to safely DIY a closed loop. (And, we feel very strongly that the DIY part of closing the loop is very important and deciding to do so is a very personal question.)

Thus, #OpenAPS was born in February 2015. Ben West spent a lot of time in 2015 building out the openaps toolkit to enable communication with diabetes devices to make things like closed loops possible. And so the first few months of #OpenAPS seemed slow, while we were busy working on the toolkit and finding ways to take what we learned with the #DIYPS closed loop and model a closed loop that didn’t require knowledge of carbs and could work without internet connectivity (see more about the #OpenAPS reference design here).

In July, we saw a tipping point – multiple other people began to close the loop, despite the fact that we didn’t have very much documented or available to guide them beyond the reference design. (These first couple of folks are incredible! Watch the #OpenAPS hashtag on Twitter to see them share some of their experiences.) With their help, the documentation has grown by leaps and bounds, as has the number of people who were subsequently able to close the loop.

As of 12/31/15 as I write this post, there are 22 people who have told me that they have a closed loop running that’s based on the OpenAPS reference design. I make a big deal about marking the date when I make a statement about the number of people running #OpenAPS (i.e. (n=1)*22), because every time I turn around, someone else seems to have done it!

It’s so exciting to see what’s happened in 2015, and what this type of #WeAreNotWaiting spirit has enabled. For Scott & me this year: we’ve climbed mountains around the world (from Machu Picchu to Switzerland), gotten married, changed jobs, and explored Europe together. Diabetes was there, but it wasn’t the focus.

There are dozens of other amazing stories like this in the #WeAreNotWaiting community. As we look to the new year, and I start to wonder about what might be next, I realize the speed of technology and the spirit of ingenuity in this community makes it impossible to predict exactly what we’ll see in 2016.

What I do know is this: we’ll see more people closing the loop, and we’ll see more ways to close the loop, using devices other than the Raspberry Pi, Carelink stick and Medtronic pump.  We’ll see more new ways to communicate with old & new diabetes devices and more ways to make the diabetes parts of our lives easier – all because #WeAreNotWaiting.

Building diabetes technology is like building a mountain bike

by Dana Lewis

I’ve had the opportunity to meet some fantastic people through our work with #DIYPS and #OpenAPS, one of whom is Eric Von Hippel, an MIT professor and researcher who work on user innovation. He shared a great example of user innovation that I was previously unfamiliar with, but is an awesome parallel for what we in the diabetes community are doing.

History: bike manufacturers used to make bikes for riding on flat surfaces. Some people wanted to ride their bikes down mountains, but existing bikes weren’t too comfortable (they didn’t have spring-based seats – ouch!). So, bikers started customizing and modifying the bikes they had. Eventually, bike manufacturers saw the demand and started building mountain bikes with the same features that the original mountain bikers had used. (And if you don’t like my paraphrased version of this story, Wikipedia is always your friend!)

The parallels:

We in the diabetes community have seen a series of needs that are not being met with our existing, FDA approved medical devices that are out on the market. From not-loud-enough alarms to not enabling us to track critical information like temporary basal rate history on the pump itself, these are the needs that drove me (and Scott) to first build #DIYPS and then to close the loop. At the same time, the need for remote data access is what drove John Costik and then the other Nightscout founders and developers to build an amazing, community-based open source tool to enable real-time remote data sharing.

Are there commercial products coming to market or are in the market that meet some of these needs now? Sure. But remember, I’ve had diabetes since 2002. In 2013, when Scott and I first started working to solve my need for louder alarms, there was NO commercial solution available for either remote data access or alarm customization. Thus the need for #DIYPS, which we built in 2013, and Nightscout, which blossomed in early 2014. And even though tools like Dexcom SHARE and MiniMed Connect have come to market (and in some cases, more quickly with help from the community communicating to the FDA about the critical importance of these tools), they came in 2015, which is a long time to wait for new tools when you’re dealing with diabetes 24/7/365. And when we managed to close the loop, again with help from the amazing #wearenotwaiting community, in December of 2014? Well, it’s now nearing the end of a year (and with amazing continued results from #OpenAPS not just for me, but for 13 additional people and potentially more to come soon), and we are AT LEAST a year and a half, if not more, away from any commercial device to reach the market. Not to mention: I’m not sure that the first generation of closed loops commercially available will be good enough for me.

The commercial entities are getting there. And, I always want to give them credit – I have a closed loop, but I can’t have one without a solidly working insulin pump and an excellent CGM system. They are, for the most part (with the exception of some missing features), making good, solid safe products for me to use.

The manufacturers are also starting to be open to more conversations. Not just “listening”, which they’ve sort-of/maybe done in drips over the past, but actual two-way conversations where we can share the needs that we know of in the community, and discuss what can be incorporated into their commercial product pipeline more quickly. This is progress starting to be made, and I’m excited to see more of it. It seems like there is a refreshed mindset and energy in the industry, as well as an understanding that we all care deeply about safety and that we’re all in this together to make life with diabetes less of a burden – like riding downhill on a mountain bike rather than a road bike.

“Should I build an artificial pancreas?” (It’s a personal question)

by Dana Lewis

Given that many (7 almost 8!) of us have closed the loop with OpenAPS, and sometimes show pictures of great overnights like the below, and given the fact that diabetes is a complicated, annoying, unfair disease, there is a lot of interest in closing the loop. Scott and I definitely get that, which is why we started the #OpenAPS movement.

I have been asked more and more lately, “Are you going to make this available to less tech-savvy people?” and “Should I build one?”.

Less insulin needed and OpenAPS reduced accordingly

The answer to the first question is emotionally hard, because a DIY build of a medical device that auto-adjusts insulin will always involve some technical knowledge – or at the very least, a growth mindset and willing to learn many new things to build a technical knowledge in order to proceed through the murky process of building a not-100%-documented artificial pancreas. You don’t have to be a programmer or an engineer; but you do have to have time and energy to spend learning as well as doing. I say this every day: the DIY part is important.

(And, I know people always want to hear “yes! It’ll be out on X date, and just as easy as installing Nightscout.” But it’s not as easy as installing something like Nightscout and never will be.)

That leads into the second question as an explanation of why it’s not as easy as we would wish:

Even if you have a very technical background, you’ll still spend time learning new languages, new pieces of software, and building pieces of your own. Things will break, things will need to be improved, and you need to have the knowledge of what’s going on and understand the logic of what you’re trying to achieve at each stage in order to be able to troubleshoot both the code part of things and the diabetes part of things.

It is hard. And it is a lot of work.

What you don’t see when someone says they’ve (DIY) closed the loop:

For every “I had such a great night” picture someone posts, that probably represents at least (10?+) hours of working on building or troubleshooting their system. Scott and I have each spent hundreds of hours working with my system, from trouble shooting, to building in new features, to reaffirming that things are all working as planned, etc. That figure should be a bit lower for new people as a result of our efforts, but it will never be as easy as just plugging something in, giving it your weight, and letting it take over. The system only does what you program it to do.

I often say this is “not a set-and-forget” system. And this is also true in the wearability of it. Right now, I use a Raspberry Pi and Carelink USB stick to communicate with my pump. They’re great, but the separate power source I also have to keep charged, plus keeping the USB in range of my pump, plus making sure it’s all working, can be a headache sometimes. (Which is why I’m so glad we made an offline mode, to reduce one of the biggest headaches of using the system.) When I’m on the go during the day, sometimes I don’t take it with me, or I choose to stop and un-power it and resume it when I get home. At this point, I wouldn’t be surprised if most people use it for nighttime use only (at least for the most part). But even with nighttime use only, there’s still constant changing of the code (in some cases daily), tweaking, altering, fixing, breaking, and un-breaking various parts.

Did I mention it was a lot of work?

And does a closed loop prevent all lows and highs? No.

It’s important to realize this is not a cure. I work really hard to do eating soon mode before meals to prevent spikes from the amount of carbs I choose to eat. I still have to test my blood sugar and calibrate my CGMs multiple times a day. I still have to change out my pump site every 2-3 days, and deal with the normal hassles of wonky pump sites, etc. I still have some highs – although the loop helps me handle them and I spend less time above range. And I still have some lows – although usually they’re from human error related to bolusing, the loop helps prevent them from always being a true low and/or blunting the drop so I don’t require as much correction. But diabetes is still a good amount of work, even with a closed loop.

Is it worth it to self-build an artificial pancreas?

This is a personal question. It’s a lot of work, with risk involved.

For me, I have decided and continue to decide that it’s worth it.

But only you can decide if the work and the risk are worth the potential rewards for you.

Does the FDA care more about safety than people with diabetes do?

by Dana Lewis

Today my inbox was suddenly flooded with links to a video with some commentary about artificial pancreas technology at a conference by a representative of the U.S. FDA. The implication many people are getting after watching the video clip is that this FDA representative is implying that people are being unsafe by building their own artificial pancreas. He mentions it is consumer prerogative to build an artificial pancreas – which is correct. The implication of his analogy is that changing your car and killing yourself is similar to a DIY artificial pancreas effort.

The scary takeaway from the video, in my opinion, as well as other public comments in the past, is the implication that the FDA cares more about the potential harms of taking action than the almost certain harms of inaction. And it’s increasingly frustrating that the FDA appears to imply publicly that those of us in the #wearenotwaiting community are doing things unsafely as a result of taking action.

Safety is what drives the #wearenotwaiting movement. In my case, I refuse to sleep another night with the fear that I won’t wake up in the morning because there’s not an FDA-approved system on the market that will wake me up if my life is in danger, let alone a system that can take action and change the situation to be more safe. So I built my own (#DIYPS), because the current FDA-approved CGM devices were not (and still are not) loud enough to wake me up at night, putting me at risk of dying in my sleep. And yes, it ultimately turned into an artificial pancreas – with the same goal of ensuring I wake up every morning, safely (alive). That is my prerogative for sure.

But I fail to see why the FDA, which collectively has no particular knowledge of these systems (especially as they have no jurisdiction, acknowledged on all fronts, over what I do myself – it’s my prerogative), is making public statements implying that these types of systems are categorically unsafe.

As a matter of fact, every DIY system I’ve seen is safer than the FDA-approved standard of care available for people with diabetes. The thousands of people using Nightscout, which is currently a DIY remote view-only monitoring system? Provides more safety and security for people with diabetes, not to mention it is helping achieve better outcomes for people with diabetes than they were able to achieve before with the standard of diabetes care as it exists today. (This was originally for the most part because of restricted access to data, although while that has improved there’s still interoperability issues getting access to real-time data in the same place from the 3+ average devices a person with diabetes uses…unless they have Nightscout or another DIY tool running.) The dozens of people working on their DIY version of an artificial pancreas system (many of whom are collaborating and sharing data in the #OpenAPS community)? These systems are safer than the standard of care, which is to let an insulin pump continue to overdose you if you are dangerously low while you sleep.

(You can see some of my personal data from #DIYPS, before we closed the loop, here and more about outcomes after we closed the loop and had #OpenAPS here. My closed loop artificial pancreas system continues to work excellently nine plus months in, and you can continue to watch my outcomes as I post them to Twitter regularly using the #DIYPS and #OpenAPS hashtags. I’ve also shared the other powerful lessons that DIY tech has helped me learn about diabetes care that helps all people with diabetes, regardless of technology.)

Are there risks to DIY efforts? Yes. But there’s risks to living with diabetes regardless. And as a person with diabetes, I am well aware of the risks that I choose to take. Diabetes is a disease in which you carry around large amounts of a lethal drug in your pocket that you are supposed to inject daily in order to save your life. As a person with diabetes, we are nothing but aware of the multitude of risks of living with this chronic disease 24/7/365.

In fact, even without a DIY artificial pancreas system, I am at risk every day simply from using my FDA-approved insulin pump that does not accurately track how much insulin I am given. (Read more here about how most insulin pumps on the market calculate IOB only from boluses, and often do not provide a record let alone incorporate any temporary adjustments to your basal rates and do not in any case track the impact of suspending your pump completely.)

And as someone who has founded the #OpenAPS movement, with the goal of an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available to more quickly improve and save as many lives as possible and reduce the burden of type 1 diabetes…..we approach it with safety first in mind, and is a big part of why the DIY part is critical and is a part of our number one priority of safety.

Not everyone will choose to go the DIY route. In fact, most people do not and I am told all the time “Oh, I would never do that.” And that’s fine! Everyone can choose what they want for themselves.

But technology has made it increasingly feasible for those of us who want to improve our own safety to do so, because the industry and the FDA are not moving quickly enough to meet our needs.

That, indeed, is our prerogative – to increase our own safety.