Earlier this week in Silver Spring, Maryland, a JDRF- and Helmsley Charitable Trust-sponsored meeting discussed interoperability in automated insulin delivery (AID) systems. The meeting was headlined by FDA’s Dr. Courtney Lias, who reviewed the vision behind the exciting new “integrated CGM” (iCGM) category with special controls (510(k)) that came with Dexcom’s G6 de novo clearance last month. The interoperability vision underlying the iCGM pathway was well received throughout the day. Notably, the possibility of subsequent “iPump” and “iAlgorithm” designations became a hot topic of conversation too – these could be clear next steps for the field, and one breakout even started to discuss what the special controls might look like for an “iPump.” iAlgorithm standards are harder to define at this stage.
The ultimate vision remains exciting: an ecosystem of components (pump/pen, CGM, algorithm), whereby individual devices are approved with interoperability in mind (assuming they meet pre-specified special controls, such as the performance standards that came with the G6 iCGM). Within this framework, a company would not need approval for every AID component combination – for instance, once a pump is approved to talk to one iCGM, additional iCGMs could be added without FDA submission (assuming the approved integration process is followed). End users could mix and match components together into a seamlessly-connecting AID system. This new paradigm could dramatically speed innovation, ensure systems are always up to date with newer components (e.g., better CGMs), allow companies to specialize and waste less time on contracts, and make the regulatory process far more efficient (including the submission and a company’s work to make modifications/upgrades).
Many challenges and questions came up, and we believe all are surmountable with clear planning and a constant reminder of how dangerous diabetes is right now. Should AID algorithms remain class III devices that talk to class II iCGMs and pumps? And if so, does that disincentivize smaller software companies (and the DIY community) from getting approval? How does the business model change in an interoperable AID ecosystem? (We imagine it could create new revenue streams, just like App Stores.) What about pump/CGM/algorithm human factors and user interface issues – can components be swapped in and out safely, and what testing is needed? What device modifications will manufacturers need to share with each other, and when? What product liability challenges come up with interoperable automated insulin delivery? Who is responsible if something goes wrong?
Greetings from Silver Spring, Maryland! We’re back with our full report on the one-day Helmsley Charitable Trust- and JDRF-sponsored meeting on establishing pathways toward interoperable automated insulin delivery (AID) systems. The small workshop was attended by ~100 influencers, including members of industry (four US CGM companies, at least five pump manufacturers), FDA’s CDRH division, the do-it-yourself (DIY) developer community, academia, and JDRF/Helmsley representatives.
This meeting comes at a critical juncture for the field following FDA’s new “integrated CGM” (iCGM) category with special controls (Dexcom G6 clearance) and JDRF’s Open Protocol initiative. The vision is paradigm shifting for the field: an interoperable ecosystem of component AID parts (pump/pen, CGM, algorithm), whereby devices are individually approved/cleared with interoperability in mind, and users can mix and match components together into a safe, effective, seamlessly-connecting AID system. FDA would not need to see every component combination as long as the proper integration process was followed – a major improvement in efficiency (for everyone) and for keeping devices updated. There are definitely still unanswered questions – e.g., pumps, algorithms, nitty gritty – but today’s meeting outlined some important next steps.
FDA’s visionary Dr. Courtney Lias was the headliner, discussing the rationale behind iCGM (received very well) and the drive to a “more vibrant device ecosystem” that could make the regulatory process easier for everyone. The first picture below shows how valuable the iCGM pathway could be for AID. She did not comment on a potential move to an “iPump” pathway, but she did use the term freely throughout the day. (It seems likely that things may go in this direction next. It certainly makes sense for pump companies to do this, as it could simplify the regulatory process for AID and enable pumps to have multi-CGM compatibility.)
We were especially moved by enthusiastic commentary from Dr. Aaron Kowalski, Mr. David Panzirer, Tidepool’s Howard Look, and others on their experiences with DIY hybrid closed loop and the interoperable vision. Said Dr. Kowalski: “It’s one of these discussions I find interesting because people say ‘oh, you’re a special case, since you’re in business, and you’re a scientist, so you can operate these systems.’ Right now, many people with type 1 diabetes are out there doing this without these systems – without any help at all. These systems are actually increasing safety. We’ve been doing this a long time. Now we need to find pathways to iterate and move faster.” And where do we hope to end up? Mr. Look described a vision of in-app purchases, where a pregnant woman can download a type 1 pregnancy algorithm for her AID system, or a triathlete can download an Ironman training module. Perhaps this level of customization and consumerization could be one of the big keys to dramatically increasing CGM and pump adoption?
Dr. Lias first shared this vision for interoperable AID two years ago at ADA 2016! At the time, it seemed like things were quite far from that – Bluetooth communication alone was still a scarcer commodity in diabetes devices. Two years later, some pieces are coming into place – the iCGM pathway, more use of Bluetooth, and active discussion of interoperability. We hope to see continued progress for pumps and algorithms and many more CGMs cleared through the new iCGM 510(k) pathway. This new paradigm seems like a home run for:
Users, who should see far more choice and less lag time when system components are improved (e.g., Dexcom G4/G5/G6);
Companies, who won’t have to make complicated contracts (e.g., pump/CGM/algorithm), submit an entire AID system as a PMA, and then undertake another huge submission when any piece is updated meaningfully;
FDA, who is over-burdened already and can now put standards in place with less need to review every combination of components.
That said, there are some challenges to work out, as we note in many of the highlights below. All seem surmountable, particularly if everyone remembers how dangerous diabetes is right now on open-loop therapy!
- Top Highlights
- 1. CDRH’s Dr. Courtney Lias Outlines Vision of iCGM and Interoperability – Step Toward Efficient Regulation, Faster Innovation, “More Vibrant” Ecosystem
- 2. Eventual “iPump” Designation Seems Likely, Though Field Needs to Agree on Special Controls & Address Issues of Controller Location, Underlying Pump Software, etc.
- 3. “iAlgorithm” Well-Received, but Seems Less Likely than iPump; Howard Look Foresees Class III Algorithms “for Some Time to Come”
- 4. Seven Concerns Voiced Throughout the Day by Industry Reps
- 5. Dr. Aaron Kowalski and Mr. David Panzirer Speak Frankly on the Competitive Advantage of Interoperable AID
- 6. Unique Product Liability Challenges Exist for Interoperable AID but Should Not Stifle Innovation
- 7. “Design for Failure” with Detailed Record; Maintaining Data Logs for Liability, Command Control, and Interface Monitoring
- 8. Post-Market Incident Handling Will Require Extensive Logging and Frequent Communication
- 9. Cybersecurity Concerns Are Valid but “Solvable Problems”
FDA’s visionary Dr. Courtney Lias delivered a comprehensive overview of iCGM, establishing it as step toward more efficient regulatory pathways, faster innovation, and a “more vibrant device ecosystem” – basically, a way to make CGMs work more broadly with other devices, while “drawing a bright line” between it and other components. View her slides here. She fleshed out exactly how the Agency envisions algorithm and pump manufacturers incorporating an iCGM into their systems: (i) Determine the specifications for CGM performance that will assure safe and effective use with the algorithm (e.g., accuracy standards); (ii) Evaluate whether those specifications are consistent with the iCGM standard, and whether the system requires additional CGM specifications (“an iCGM that also…”); (iii) Perform a clinical study with a representative or multiple iCGMs; (iv) Seek AID system approval for use with any iCGM device (labeling will include performance with a representative iCGM device, but the claim would be for “any iCGM”); (v) Once approved, additional iCGMs can be added without FDA submission if the approved integration process is followed. This was all received extremely well, and there were smatterings of commendation for the work of Dr. Lias and her team throughout the day. (As just one example, this could help avoid what happened with Tandem- and Animas-Dexcom G4 pumps, which took ~two years to be updated and approved to incorporate G5.) Other benefits that could stem from this paradigm shift include more efficient technology modifications (reducing the need for duplicative regulatory submissions), making the regulatory process faster and more predictable, functioning for both open and closed business models (even if a company didn’t want to play in a “plug-and-play ecosystem,” it would still benefit from the more efficient, faster, and predictable regulatory approach), and greater degrees of patient choice.
The above picture clearly delineates how much simpler the regulatory process would be, especially for updating components. In Dr. Lias’s words, the current situation (above, left panel) is “too complicated to succeed.” (In manufacturing lingo, the current process on the left is very much an inefficient “batch,” while the right process is leaner.) In the current scenario, she imagined a hypothetical pump company that relies on an externally-sourced CGM. Even if the CGM company makes a simple modification, the other companies need to conduct a quality assessment and come to FDA with a new PMA. A year, later, the CGM company could make another slight modification, which would again necessitate a completely new PMA. If the pump company doesn’t have the capital to pursue a whole new PMA, or if it takes a long time (i.e., Tandem and Animas updating from Dexcom G4->G5), then patients rightfully feel that their technology is outdated. Now, multiply that scenario by XX number of companies trying to play in automated insulin delivery – consider the multiple additional systems and components – things get complicated and very inefficient very quickly. So complicated, in fact, that some companies could drop out of the market (as Animas did and Roche has in the US for the time being). In case it wasn’t perfectly evident, Dr. Lias exclaimed, “Some companies would decide to drop out. Innovation would slow. That’s not our goal!”
In a breakout session, Dr. Lias suggested that with certain CGMs downgraded to class II with the iCGM path, “there’s an opportunity that if a device wanted to display real-time glucose data, it might not be class III.” The key word here is “device” – if she is referring to pumps, that would be a big deal, since it could mean sensor-augmented pumps go from the current class III down to class II. In other words, is a Tandem insulin pump integrated with Dexcom’s G6 (iCGM) a class II or a class III device? And what about when an automated insulin delivery algorithm is added – is that a class II or class III device? This seems to be an open question for now, though we hope all of those examples could move to class II with special controls over time – presumably iPump and iAlgorithm pathways will be needed to do so. Our interpretation of the G6 clearance was that display of real-time iCGM data on a phone or watch app would be down-classified– i.e., since the G6 system is now a class II device with special controls, primary display of that real-time data on a phone or watch app should theoretically also be class II. If that is the case, it would mean direct-to-smartwatch transmission (for instance) would be class II with special controls, a definite win for getting real-time data onto new primary display devices. This could also have decision support implications – would a CGM-based bolus calculator app move to class II, since bolus calculators are class II devices? We also assume the iCGM down-classification to class II will apply to third-party apps that use real-time iCGM data – presumably these would also fall under class II with special controls (or even class I), but we’re not positive.
Dr. Lias provided a number of example situations likely to come up in a regulatory landscape enabling AID compatibility and interoperability and how they might be handled. Some of these were quite confusing to understand, as there really aren’t commercial examples to attach to these cases yet. Still, the answer in all cases is that companies and FDA will just need to think ahead and plan – what’s the integration process for talking to a device? How will a company communicate when it makes updates to its device?
Case #1: An automated insulin delivery system is approved to work with all iCGMs. The AID system now wants to integrate a new iCGM with a proprietary (closed) communication protocol. FDA will take a flexible approach, allowing AID system integrators to work with both “open” and “closed” iCGM companies. AID system integrators will have autonomy to determine how they go about integrating an iCGM, so long as the process is understood and pre-approved by FDA. The Agency wants to see and pre-approve a plan of how the new iCGMs will be integrated into the system. In this example, Dr. Lias said the automated insulin delivery system would have first been approved using an iCGM with an “open published communication protocol.” We’re not sure what this means specifically, and it is still hypothetical for now – will Dexcom’s G6 eventually have an open protocol? Our interpretation of “open published communication protocol” is that anyone can look at the communication protocol and connect to the device without a partnership with the CGM company. Currently, CGMs are all “closed” to our knowledge, and DIY users have only been able to connect to them by reverse engineering the protocols. Will CGMs publish their communication protocols?
Case #2: An iCGM with a proprietary protocol modifies its communication protocol. Similar to Case #1, the iCGM manufacturer’s 510(k) submission will have included a clearly specified process for how it intends to communicate modifications to other component manufacturers. Dr. Lias clarified that details would be different depending on the model (open, proprietary, etc.).
Case #3: An automated insulin delivery system wants to connect to iCGMs with open published protocols. The AID system’s pre-approved communication process will specify how the sponsor will monitor for modifications to the iCGM communication protocol and make appropriate updates. Again, the details would vary depending on the approved process and available iCGMs.
Case #4: An iCGM manufacturer with open published protocols receives a complaint that its iCGM failed in an automated insulin delivery system (and complaints are being fielded). Even though the iCGM manufacturer has no official (partnership contract) relationship with the AID manufacturer, it is required to investigate the complaint. If the investigation reveals that the iCGM was not at fault (i.e., correctly sending glucose values), then, as specified by their FDA-cleared communication process, the iCGM manufacturer must notify the AID manufacturer of the complaint with adequate information to allow the AID developer to initiate their own investigation. According to Dr. Lias, this approach leverages existing FDA requirements for complaint-handling and CAPA (corrective and protective actions).
Case #4 seems to us to be the most ambiguous, as it raises a number of questions: When does FDA have to get involved, and who’s job is it to involve them? Is there precedent for this in other therapeutic areas? Will there be a need for a third-party “fault adjudicator”? Could there be an underlying surveillance system that automatically notifies each device manufacturer when one company receives a complaint? What degree of device/software/communication modification should warrant notification of FDA and/or other component manufacturers?
Dr. Lias noted that the iCGM special controls are an example of FDA trying not to be too restrictive when it doesn’t need to be. A big reason for this attitude is that they want to make the standards and policies applicable not only for the devices available today, but also looking ahead to future iterations. Thus, the iCGM designation was meant to be “as general and flexible as possible.” Dr. Lias – always open to feedback from the community – said that “we haven’t always succeeded on that; we can’t see the future. Give us feedback on whether we hit that bar.”
FDA has received a lot of questions on whether factory calibration is required to be an iCGM – the answer is no, in line with our interpretation of the special controls. If a BGM is necessary to calibrate, then it will be considered “inherently related to the CGM.” We assume what ultimately matters is if the system demonstrates accuracy to meet the special controls, as done in a typical YSI accuracy study where the CGM is calibrated with a BGM. To meet the stringent iCGM bar, we wonder if companies might need to specify that only certain accurate BGMs can be used for calibration. Though this would be a downside for patient choice, we do hear of many still calibrating their CGMs with inaccurate BGMs that are still very popular (e.g., OneTouch Ultra).
Dr. Lias sarcastically mused that the mandatory shutoff stipulation is “everyone’s favorite control we added.” While the decision may be unpopular among those that extend sensor wear to save money, we think it is important for safety – especially in factory calibrated systems where extending wear could alter the performance and there is no calibration “check” on the system. CGM devices are used in high-risk decisions (dosing insulins), and they have only been studied by the manufacturer for the described wear time. This does make us wonder if some manufacturers will opt to file two versions of their CGMs – a class II iCGM with a mandatory shutoff and a class III CGM without one – to provide more options for their customers. It will also be interesting to see if patients find workarounds to the mandatory shutoff.
As a side note, Dr. Lias suggested that there is still a little room for innovation in CGM, “but we’re getting close to the limits,” referring to the current level of CGM accuracy with factory calibration.
Selected Questions and Answers
Dr. Daniel Cherñavvsky (CMO, TypeZero): Is there a different path for regulatory if your system is bypassing the physician?
Dr. Lias: Whether or not you are going directly to the patient, that has less to do with classification and more to do with risk. We have BGM over the counter devices, and we have others. The question is whether risk has been mitigated or not. If someone wanted to put an iCGM over the counter, it doesn’t necessarily have to do with whether it’s class II or III, but more to do with whether the risks of that use can be adequately addressed within the class II classification so that the over the counter device could be found "substantially equivalent" to the prescription use device.
Dr. Barry Ginsberg (Diabetes Technology Consultants): One of things that DTS wrestles with is that every manufacturer changes to a new phone every year – nothing medical happens that fast.
Dr. Lias: We have to deal with the situation we’re in, figure out the gaps – if they’re there and mitigatable, that’s different from if they’re there and too big to solve. We need to understand the risk first.
Q (from Abbott employee): One question I have is on the accuracy. How did the iCGM special controls get developed for different bins in terms of relationships to the algorithm companies that’ll eventually use those?
Dr. Lias: The number of automated insulin delivery developers who have currently defined specifications for CGM accuracy is low, so we had to work from general knowledge. We do know how algorithms work, so we have a general sense about what kind of CGM information is important. We work with a number of AID developers through PMA and IDE submissions to see that. So we used that knowledge and information we have about the accuracy performance of CGMs to develop the accuracy standard. In an ideal world, we'd like to develop standards as a consensus within the clinical community. However, de Novo submissions are confidential, so we couldn’t reach out to the community in this case.
[Editor’s Note: This question has obvious implications for the Bigfoot/Abbott relationship, since FreeStyle Libre (in its current accuracy) does not appear to meet the hypoglycemia standard in the iCGM Special Controls. Abbott could presumably make FreeStyle Libre more accurate in hypoglycemia to achieve the iCGM standard, or it will need to convince the FDA that the special controls should be loosened. The question, therefore, is how set in stone those special controls are, since there is a degree of arbitrariness to them – read our table summarizing them here.]
Q: So the bins and percentages have to do with accuracy?
Dr. Lias: We tried to strike a balance – five glucose range bins for the transparency part – we did a lot to see what makes an impact when you split it out and what doesn’t. Also in CGM land, there’s not a lot of data below 54 mg/dl, so does it makes sense to have a requirement there?
[Editor’s note: The special controls currently set specific accuracy requirements in the bins of <70, 70-180, >180 mg/dl, and across the device’s full measuring range…manufacturers have to report <54 and >250 mg/dl in the labelling, but specific accuracy requirements in those bins are not mandated.]
Q: From your point of view, what will be the difference if someone is not using a proprietary communication protocol, but using a standard?
Dr. Lias: Well a standard doesn’t exist, but if one did, we think many would use a standard out of ease – that way they could automatically connect. Our goal wasn’t to pass judgment on which is better or not. We have some devices that use Bluetooth for medical applications, like CGM. There is a standard coming, but whether it’s adopted is not up to us. If regulation says you have to use a standard, then everyone has to do that – the goal wasn’t to dictate how it went, but to make sure however it went was allowable.
Dr. Steven Russell (MGH): On the process of getting approval for an AID system using iCGM: You said use a representative iCGM for the trial, then you can substitute others in with no more clinical data, assuming they meet the specifications. Could the CGMs have different user characteristics, but still use one representative iCGM?
[Editor’s note: Beta Bionics is considering using both Dexcom G6 and Senseonics Eversense CGMs in the Bionic Pancreas – hence the question.]
Dr. Lias: That’s potentially possible, but I haven’t thought through how that’d work.
Dr. Russell: For already PMA-approved devices, how would that look?
Lias: Send us a supplement with your plans and specifications, then you can upgrade intended use. The same thing is true for sensor-enabled pumps.
Dr. Peter Jacobs (OHSU): It’s very interesting that you’re taking CGM and reducing it from class III to class II. For requirements for special controls, do you think that adds substantial benefit that everyone will do it?
Dr. Lias: Well I think you have to ask the companies. Definitely the burden is less. With PMA, basically you can’t sneeze without coming back to FDA in the post-market setting. Not true for 510(k). 510(k)s are cheaper up front, but I think the maintenance of the PMA is the biggest cost. For 510(k), regulatory maintenance is less involved. Though both Class II and Class III devices have the same post-market requirements, they have very different post-market FDA submission requirements. We’re trying to separate responsibility – CGM is only responsible for measuring glucose, sending to the AID device, and alerting other component manufacturers to complaints – if that fails, they’re the fall guy. The whole goal to separate responsibilities and draw that line – it’ll never be perfect, but leveraging existing responsibilities for manufacturers will reduce the chasm.
Q: What about the issue of nonadjunctive CGM? How does that fall into iCGM?
Lias: We wouldn’t mandate that claim, but we’d allow it for iCGMs that meet the special controls.
Mr. Bryan Mazlish (CTO, Bigfoot Biomedical): How would a gap be managed, if it were identified?
Dr. Lias: We’re not all pump or algorithm experts at FDA. It’s really about the progress we’re making – it’s more about laying out the highest-risk processes, and asking what can be done to resolve them? We just want to understand the state of affairs.
Mr. Mazlish: I was thinking more along the iCGM line – one question, the special controls are pretty stringent. Those are determined under pretty controlled clinical trials, but these sensors have failing modes not observed in clinical trials. So how would a third party be able to mitigate and assess those risks?
Dr. Lias: If something happens, then you’re no longer meeting special controls, so you have to recall the device or we have to take action. So if you have violated special controls, then you’re no longer legally marketing your iCGM. As a manufacturer, you need to believe in FDA’s ability to oversee that you can be reasonably assured they worked that way while on the market. So if you’re worried that on-market performance is not as good, maybe take a different route (for example, include a CGM under your AID PMA instead of using iCGMs). Make a decision to tolerate some uncertainty with on-market performance. Some companies may choose to do their own testing. If your AID algorithm CGM accuracy specifications are very close to the iCGM specifications with little wiggle room, and you are concerned that an iCGM may fail in real-world settings, then you may not decide that use of any iCGM is the best choice for your AID system.
[Editor’s Note: This is a critical question for the field – do CGMs perform as well in the real-world as they do in the controlled trials for labeling? The answer, to us, is a clear NO. People calibrate with dirty hands, use inaccurate BGMs for calibration, exercise, and do all sorts of things that make real-world CGM performance worse than seen in labeled clinical trial performance. Drs. Steve Russell and Bruce Buckingham have both presented CGM accuracy (MARD) data from AID trials – accuracy in real-world use is not as good. Dr. Lias’ answer suggested that FDA expects real-world CGM performance to be similar (or perhaps somewhat reduced in certain cases) to what is shown in the clinical trial. That does seem reasonable, but how will companies monitor that once a device leaves the factory? What can be attributed to user error vs. device error? And if accuracy is worse in real-world use, what are the implications for recall, etc.?]
Mr. John Lum (Jaeb Center for Health Research): You mentioned limits like trends, data gaps, and alarms. It seems almost like that’s different from everything on the special controls. This has more to do with receipt of information, and less about the CGM performance (accuracy), for example. I’d like to hear just about alarms.
Dr. Lias: The reason we included that isn’t because the system needs to know that an alarm will go off. If they do have alarms, we think alarm performance is useful to have. An alarm tells you how many times someone went under, say, the 70 mg/dl threshold. This information can be useful in helping AID manufacturers understand threshold sensitivity (if that is helpful in their own specifications/assessments). It doesn’t give you amplitude, but it’s a little bit additive on top of other accuracy bins. For describing CGM performance, we are not sure those are the best to put in, but it can be helpful and it’s better to provide multiple types of information. Depending on the type of device, or another algorithm, it might be more meaningful. Someone might have an app that just provides alarms, maybe they just want to know how well it works.
Though Dr. Lias was clear that she couldn’t talk about whether FDA was moving toward an integrated pump (“iPump”) pathway, she and others used the term freely throughout the day. In response to Mr. Howard Look’s proposal that iPump is the direction the field is heading, she said “If the risks for a pump could be mitigated, we would like to understand them and what mitigations would be done.” Later in a breakout session, one group listed resolution (deliver insulin in small-enough increments), precision, accuracy (within 0.025 to 0.05 units, suggested Dr. Hovorka), and failure to deliver as parameters that should be considered for any potential special controls for an iPump. Other parameters such as bolus duration, max bolus, presence/absence of autonomously-initiated dual-wave boluses, square wave boluses, how the pump detects and reports occlusions, etc., and connectivity would have to be specified but not necessarily dictated by FDA. In other words, the iPump special controls could be similar to those for iCGM in that they would provide a minimum guarantee of basic performance, and then ensure the transparency of other pump performance parameters to allow AID developers to understand which pumps are adequate for their algorithms. An algorithm could then be indicated for use with all iPumps but only compatible with iPumps that have certain, more stringent, accuracy of insulin delivery. Dr. Lias wondered in her opening presentation if it makes sense to have iPumps. Per her logic, the set of information needed for pumps are fairly simple, as they only have to give drug (a specified quantity at a specified rate), reduce drug delivery (a specified quantity at a specified rate), and report back on pump status (what is going on?). We like the vision of an iPump that is indicated for interoperability (as we believe most in attendance did), and we wouldn’t be surprised to hear of such a designation in the near future – pumps are already regulated as 510(k) medical devices, so this would simply clear them for interoperable use cases and put some special controls around them. Perhaps Roche, the first company to openly support JDRF’s initiative to accelerate “Open Protocol” AID systems (announced at ATTD), will also beat the pack to filing a De Novo application with FDA?
A few attendees, including Dr. Lias, were fairly concerned about the possibility that underlying pump software (such as insulin infusion suspend) could complicate control by an external device. Questioned Dr. Lias, “How easy will it be for someone to work with that pump if it has its own control protocol, then you build one on top? I’m skeptical that there are big pitfalls associated with not doing that well, if you don’t understand software architecture, unless there are agreed-upon rules in place with software.” Some in the room were dismissive of the question at first (“well existing low-glucose suspend would just add another safety blanket”), but the point is a sound one – do we know enough about how these pieces of software would interact to deploy them now? Beta Bionics’ Dr. Ed Damiano suggested a brilliant workaround: Pumps could have different modes, such that they operate either (i) as fully-featured pumps or (ii) when communicating with an external controller, as simpler iPumps with more basic embedded functionality. Dr. Lias seemed to be on board with this idea: “The simpler the better. As soon as you have to tell how the algorithm will respond to embedded software, it’s much more difficult. But if there’s a way to give customers a pump that will do either thing – make one pump, and give it to people who don’t want automated insulin delivery (just a pump), and have it in "digital syringe" mode where people can operate automated insulin delivery software if they want. Have a control in place, where if something else is controlling the pump, it switches to a digital syringe.” A rep from Tandem nodded, exclaiming that it wouldn’t be burdensome from the manufacturer’s perspective to have this more basic mode that strips out features and puts the onus on the algorithm for control.
Attendees stressed the paramount importance of having a fallback safety setting (like “safe basal”) should the algorithm somehow fail. This was fairly easy to address – if connectivity to a remote algorithm is lost, a “safe” basal rate could be assumed (defined as the minimum basal needed to keep someone safe and out of DKA). Of course, this rate would have to be stored on the "digital syringe," so it would have to have some “brains.”
There was much debate surrounding the use of smartphones as controllers for iPumps. During the breakout sessions, some attendees strongly advocated for controlling pumps with smartphones, arguing that connected consumer electronics are the patient-preferred interface. Dr. Aaron Kowalski agreed, suggesting that patients will drive device form and functionality and that the ability to bolus from his phone is personally “very appealing.” Dr. Steven Russell, however, took a different tack, proposing that phones should be used as an additional (and optional) viewer, but that making the phone the interface is “a really big hill to climb when there are more important areas to invest in.” As he noted, patients can easily lose and damage phones, phones run out of battery, and patients will be charged with carrying an extra device. Yet, as Mr. Panzirer aptly reminded attendees, carrying a smartphone cannot entirely be characterized as an additional burden for many; he commented: “My daughter forgets her [RileyLink] controller all the time, she never forgets her phone.” Dr. Lias was further interested whether there were gaps (or not) in how to address questions like: in the ability of an algorithm to keep running during normal phone use, how much battery would the controller use, what would happen if there were apps running in the background, and what would happen to a bolus if a phone call came in. In our view, these issues have all largely been addressed by the G5 Mobile app (overriding iPhone mute) and the DIY community – when Loop isn’t working, the pump simply reverts to the pre-programmed basal rate once the current 30-minute temp basal expires. Ultimately, we agree with Dr. Kowalski, who maintained that JDRF wants to see multiple options. Some patients will prefer the security of restricting control to the pump, while others will choose the discretion of using their phone. Allowing for a variety of permutations can only benefit patients. Although challenges exist in either scenario, they should not impede development – industry members and regulators must work together to ensure the safety and reliability of every alternative.
Dr. Lias has “heard vaguely” that there are issues associated with phone use, but attendees with diabetes/caregivers, who focused on cybersecurity issues specifically, quickly countered that diabetes is riskier than exposing oneself to nefarious hackers. Read more on this topic below.
Selected Questions and Answers
Mr. Howard Look (CEO, Tidepool): I’d like to test an assumption of mine. I can imagine a world where now we have iCGM, Class II, special controls, and well-specified performance. And also, let’s call it “iPump,” a digital syringe, an infusion pump that does what it’s told based on secure communication protocols. If we can come up with iPump specifications, would it be possible for a De Novo application to be submitted by someone who’s not actually making a pump? So can we get out ahead of this.
Dr. Lias: It’s probably easy to discuss potential special controls separately from a device review, but that De Novo would have to show data from that pump to make that decision. So De Novo might not be the with process to get consensus.
Mr. Look: So if we can get one of the fine folks in this room to do that, then class II iCGM and class II iPump, then presumably controller will be a class III device for some time to come. Do you imagine that’s exactly how it will go – class II iCGM, class II iPump, and class III algorithm?
Dr. Lias: If the risks for a pump could be mitigated, we would like to understand them and what those mitigations could be.
The idea of an “iController” was fairly well-received, though there were plenty of questions about what the special controls would be and how they should be validated: Should algorithms be adjusted to fit pumps/sensors, or should they be indicated for use only with pumps and sensors with certain specifications? Could simulation play a role in their validation? (Dr. Lias seemed less comfortable on using modeling alone, given the July 2016 Advisory Committee’s lukewarm reception to simulation-only data for Dexcom’s G5 dosing claim. Of course, FDA recognizes the role and value of simulation, including modeling various scenarios under conditions that would be impossible in a clinical trial.) Would there have to be different specifications for algorithms on phones vs. embedded in pumps? – definitely a key question as closed loop algorithms move onto approved phone apps eventually. At the end of the day, most in attendance agreed that restrictive standards are definitively not the way forward, as that could have the unintended effect of stifling innovation. Based on the discussion, defining iAlgorithm standards seems a bit tougher than iPump standards, but both may be needed for the whole vision to become a reality.
From the standpoint of the algorithm, creating iCGM and iPump categories would be beneficial. As Dr. Lias presented: (i) Separating the controller from components allows more entities to realistically enter ecosystem; (ii) It may allow for fewer or smaller clinical trials (because algorithms could be indicated for use with CGMs/pumps that meet pre-specified parameters); (iii) Integration into smartphones could enable a more streamlined device experience for patients.
Dr. Kowalski proposed creating a list of critical algorithm characteristics to hone in on for faster pressure testing. As he put it, “we’ve been doing this for a long time… it seems like it’s got to be overkill by now.” There was much agreement in the room, with many noting that current requirements result in excessively lengthy and costly trials. One attendee recommended keeping such characteristics broad enough to allow for innovation; as an example, all algorithms should be robust against connectivity gaps, but how this is achieved can be left up to the individual developer. Some attendees also suggested allowing for a combination of simulation and clinical trials (e.g., Bigfoot’s vClinic is an example of how simulations might accelerate AID algorithm research). We love this idea of defining necessary safeguards. On the other hand, when Mr. Look asked Dr. Lias if we’re looking at class II iCGMs and class II iPumps working in tandem with class III algorithms “for some time to come,” she did not respond to the algorithm piece of the question. We are not software experts, but Mr. Look’s scenario seems to make sense to us for the near-term future – while pumps and CGMs can essentially be considered the effectors, the algorithm directs the whole operation and should therefore perhaps be evaluated with more scrutiny. Then again, keeping the controller a class III medical device leaves less room for innovation, likely keeps the DIY community from ever having an “FDA approved” algorithm, and keeps the bar high for the whole AID system as a PMA – thus limited to medical device companies. We see both sides…what do you think?
Selected Questions and Answers
Dr. Boris Kovatchev (UVA, Charlottesville): A special thanks for putting algorithm and developers in the middle of this – I’ve been dreaming of this moment for a very long time. I have a question about the testing of an algorithm: 10 years ago when we started, there was a landmark idea from FDA to allow algorithms to be tested in silico. Can we do it again? Would that be acceptable?
Dr. Lias: We see some modeling being useful in development activities. We didn’t get a lot of great feedback from the panel on modeling (alone) for Dexcom’s non-adjunctive claim. I’d never say never, but there’d have to be a lot of work done. But the more you understand about an algorithm, the more you can focus a study on what is meaningful.
Dr. Kovatchev: I’m not talking about replacing clinical trials, just using it for situations in which a trial would be unethical.
Dr. Lias: That’s what they weighed in on for Dexcom – different intended uses – but clinicians on the panel didn’t necessarily want that to be used still. You’re talking about cases where we can’t do clinical trials – so as part of risk analyses, there are certain things that can be done.
Dr. Kovatchev: When new systems come in, I’m suggesting this as a gatekeeper, at least in the beginning.
Dr. Lias: We always like to understand how companies make their decisions and we think in silico models can be great tools for that as well.
4. Seven Concerns Voiced Throughout the Day by Industry Reps
Throughout the day, we kept close tabs on the concerns that were voiced by people from industry, from the demand for interoperability to more granular questions. We believe most of them are either rooted in misunderstanding, are easily addressable, or have yet to be settled – but at the end of the day, we see all as surmountable.
At least one pump company executive wondered whether there would be demand for an ecosystem of interoperable AID components. How many people would actually want and take advantage of this “complexity?” Would it be limited to bleeding edge users? While it’s impossible to know for sure, Mr. Look, Dr. Kowalski, and Mr. Panzirer essentially pointed out that greater patient choice is in manufacturer’s interest.
What is the business model, and how is AID marketed? Does the ecosystem approach necessitate a stall out in fee-for-service? How would value-based contracts look when each company is essentially contracting not only with the payer, but also with the other manufacturers (if someone goes to the hospital due to an over-delivery of insulin caused by artificially high CGM readings, is the pump manufacturer held at all accountable from a payer’s point of view?). Logistically, it would be difficult for one company to own the delivery process and push for unique service models (like subscription deliveries of everything that is needed). Perhaps there is a role for a third-party company that could take care of deliveries of all systems, regardless of their components (or would that boost costs too much)? And finally, how would each company advertise? Would there be incentives for component manufacturers to partner up? For example, would it be in each of Dexcom’s, Tandem’s, and TypeZero’s interest to only advertise their composite system – this would broaden each’s exposure and could prevent other companies from entering the market. Would this be considered a form of collusion and outlawed?
One pump manufacturer rep wondered if his company would have to make both a “dumb pump” (for component-based AID) and “smart pump” (for non-AID purposes)? The answer seems to be “no,” especially if a pump could be programmed with both modes and toggle back and forth depending on the patient and application.
If algorithms remain class III devices, could there be disincentives for smaller software companies to enter the market? Large, mature companies generally manufacture CGM and pumps and are now looking at a much less burdensome 510(k) clearance, while small companies developing algorithms may be intimidated by the cost of entry with PMAs. In the worst case, hardware-focused companies would be forced to develop algorithms internally. In an intermediate case, large hardware companies would scoop up or partner with smaller companies, providing them financial stability. In the best case, the PMA process would become less burdensome for software companies, possibly via FDA’s digital health Precert program.
A number of industry reps voiced concern over the level of standardization they could face if iPump and iAlgorithm designations were also to be established. They were worried this would result in a stifling of innovation. Fortunately, their concerns were assuaged by Dr. Lias, who repeatedly underscored the Agency’s desire to “not be too high touch” and make guidance/regulation applicable both for devices today and in the future.
Both Bigfoot’s Mr. Bryan Mazlish and MGH’s Dr. Steven Russell wondered if and how various human factors issues and user interfaces would be taken into account in a system that considers all iCGMs/“iPumps” meeting certain accuracy and transparency parameters interchangeable. Dr. Russell seemed to be asking out of curiosity for the Beta Bionics system (which may use both Dexcom and Senseonics CGM) and the benefit of others in the room. Mr. Mazlish took on a more concerned tone: “One of the issues is there’s a tremendous amount of human factors work that goes in to these – the idea of taking a black box sensor and inserting, that’s easy. But if you’re talking about a pump with a user interface and you’re going to a different one, that’s a lot more challenging. At the end of the day, you have sensors, the actuator, and decision logic. There’s a reason sensor and decision logic are coupled, and it could be problematic to decouple them.”
Dr. Lias was also attentive to this issue, wondering aloud how easy such interface issues would be to evaluate and solve. “If these are prescription devices, it’d be good to have thoughts about who is appropriate for the device and who’s not. Or if the intended use population is less experienced – the device can be labeled to say indicated for X, Y, and Z. In the case where there is concerns about broad applicability for a specific device due to unique risks, it may be good to have a learned intermediary to determine who’s a good candidate.” Or, we’d propose, an algorithm that suggests the optimal device combination based on the individual’s background. Still, this is an issue we can definitely address.
It doesn’t seem clear at this point what device modifications FDA requires manufacturers to share with others and when.
Dr. Kowalski and Mr. Panzirer spoke with trademark passion and candor regarding the inevitability of and necessity for interoperable automated insulin delivery. In his opening remarks, Mr. Panzirer urged the audience: “I’d challenge anyone who thinks that having a closed system is a good idea to rethink that. Ask yourself, is it a competitive advantage or just something leftover? If you ask me, in the future that may come back to bite you.” Dr. Kowalski closed the day in a similar tone: “I can virtually guarantee someone will come along with a cheap pump, and they will plop algorithms in, and that’s what I’d be thinking about if I were in your shoes.” During breakout discussions, MGH’s Dr. Steven Russell questioned whether a pump company with its own algorithm would have an incentive to go through the extra trouble of developing an iPump. In response, Dr. Kowalski put forth a hypothetical scenario in which a manufacturer builds an iPump compatible with TypeZero, OpenAPS, Cambridge, Loop, and Dexcom – all of a sudden, Dr. Kowalski claimed, “the business model blows up.” As he put it: “If I were you, I’d be thinking, somebody will come along and do this, and I’d be ready for it.” We appreciate the enthusiasm with which Dr. Kowalski and Mr. Panzirer describe the future of interoperability, but also take Dr. Russell’s point. In order for companies to truly get on board, the regulatory pathways for iCGM (and possibly) iPumps and iAlgorithms cannot demand too much more of the industry. Companies also have to figure out a business model behind all of this, a challenge that other industries have gone through – software on PCs, apps on phones, etc. Dr. Kowalski, however, isn’t concerned, claiming he has “drunk the Courtney [Lias] Kool-Aid” and is convinced regulation will not be excessively burdensome. All of this of course remains to be seen, but we’re looking forward to what we’re sure will be a very exciting road ahead for diabetes.
6. Unique Product Liability Challenges Exist for Interoperable AID but Should Not Stifle Innovation
In response to industry concern, JDRF contracted the law firm Bowman & Brooke to better understand the unique product liability challenges associated with interoperable automated insulin delivery (get the slides here). Firm partners Ms. Mary Novacheck and Ms. Susan Burnett’s comprehensive overview of these issues gave industry players a number of strategies to mitigate risk but may have had the additional effect of instilling a sense of fear. Tidepool’s Howard Look grounded the conversation during Q&A by reminding the audience not to lose sight of the bigger picture, “which is that managing type 1 diabetes is really hard.” As he put it, “As an industry, if the message is ‘you better protect yourself,’ we’re missing the bigger picture that AID is way better at doing what we already ask people to do. Our responsibility is to get this out as fast as possible. Literally kids are dying in the middle of the night...” We wholeheartedly agree and sincerely hope that liability concerns do not impede these critical business decisions. Dr. Russell provided a possible workaround, wondering if AID systems might be afforded the same kind of “no-fault system” as the government compensation program for patients who experience adverse reactions to vaccines. This system for vaccines ensures consumers are protected (they can file a claim with the government), while still protecting companies. We like the potential here! Might JDRF/Helmsley Charitable Trust support such efforts?
Dr. Russell also commented on potential liability issues surrounding increasing the automation of devices (e.g., adding correction boluses on top of basal modulation). Although he personally believes increased automation to be a worthy goal, he acknowledged that many may shy away from such advances for fear of heightened liability. Ms. Burnett agreed that greater automation tips liability farther away from the user but urged concerned audience members to consider the “denominator” – how outcomes differ with automation vs. without automation. The likely decline in adverse events on a population level could provide evidence of solid design and improved efficacy, making a strong defense case. (This is something the FDA’s team, under Dr. Lias, has championed with CGM – adverse events reports are high, but that’s because diabetes is dangerous!) The overall sentiment was that the risk of a rare product liability case is inevitable, but this should not stifle innovation; as Ms. Novacheck put it, “this is why companies have product liability insurance.”
Ms. Burnett emphasized that the more FDA control on a device, the better the chance of securing a “preemption defense” – a huge win in liability cases, as it prevents having to stand trial before a jury. With the new iCGM pathway, Ms. Burnett explained, the possibility of a “preemption defense” is more tenuous, given that in 510(k) clearances, manufacturers have more leeway in the changes they can make without getting regulatory signoff. We take that to mean a jury trial is more likely in this world, but we could be misinterpreting.
Other issues common to AID systems that could impact product liability risk include: (i) Devices are used by laypersons outside the control of medical professionals, which must be considered in both user design and to whom warnings are communicated; (ii) Hacking into systems can not only threaten data privacy but also potentially cause personal injury; and (iii) the allocation of fault and responsibility can become murky when multiple manufacturers are involved. Throughout their presentation, both Ms. Burnett and Ms. Novacheck underscored the importance of fastidious documentation as a means to proactively manage product liability risk.
Everyone was in agreement that “data logs” should be maintained: when one medical device talks to another medical device(s), what time does that happen and what is the associated outcome? Dr. Kowalski described this traceability as “one of the most important things,” particularly when users are making their own modifications, such as when he uses his own temporary basal rates during exercises. To this end, most felt that patients should have access to these data, if desired, but questions remained surrounding data logging standards and whether users might amend data or provide context. A detailed “flight record” of each communication could be used for a variety of purposes including: (i) determining liability; (ii) providing command control (i.e., the pump must provide accurate dosing information to the algorithm, which must in turn instruct the pump when and how much insulin to deliver); and (iii) establishing interface monitoring (i.e., providing status information such as low reservoir, low battery, etc.). Much of the conversation focused on this last issue, with particular concern surrounding the return to manual mode in the event that the phone dies or software breaks. OpenAPS’s Ms. Dana Lewis was especially adamant on this front, urging industry members to “design for failure.” When such errors occur, Ms. Lewis explained, users have to fall back to their pump, making it critical that the data logged on the pump is accurate and comprehensive. Ideally, she claimed, the “flight record,” including factors like insulin on board, would exist on the pump. Abbott’s Mr. Joel Goldsmith took this idea a step further, suggesting that perhaps the command and control logic might be duplicated across the multiple devices so that even in an extreme disconnected state, each component operates as intended. It was heartening to hear the enthusiasm in the room – this will certainly be a critical topic for industry and regulatory leaders, as well as patient advocates, to continue to discuss.
What is the minimum set of data that should be logged by component AID systems? One breakout group agreed that only data that makes it to the controller and helps it make its decisions and device statuses need to be recorded. Fortunately, an engineer from a pump company chimed in to add that there is no cost in creating these logs. His company logs extensively, and the only “cost” comes in when users observe that it take forever to download their data log!
During a breakout session, Ms. Lewis made the excellent point that retrospective review of data by patients and healthcare providers must also be included in the initial design. Amidst a roomful of industry and regulatory personnel, Ms. Lewis brought a valuable patient perspective, encouraging attendees to use already available patient data and research to solve problems and remove barriers.
To a chorus of sighs, the Bowman & Brooke lawyers explained that patients will want to have access to their data logs until something goes wrong – as soon as they become plaintiffs and are suing a manufacturer(s), they want all potential evidence of their interference/fault to disappear. Mr. Look responded concisely: “I think that’s not ok, manufacturers – we have to log what we do. Dammit if we’re going to drive insulin into my daughter, I want to know who’s doing what.” Senseonics CEO Dr. Tim Goodnow voiced his dissent as well: “when we file an MDR (medical device report), which we will, we need to find out what went wrong. We can’t all run our businesses for the lawyer – we need to troubleshoot.”
8. Post-Market Incident Handling Will Require Extensive Logging and Frequent Communication
With respect to post-market surveillance, it was agreed that the company that fields a complaint should look into its logs and inform the other component manufacturers if it determines that its part didn’t malfunction. Exactly how and when FDA is brought into the conversation (how to minimize double-reporting?), how and when other players are notified, if there should be a third-party adjudicator of logs to determine fault, and other questions remain. Dr. Lias provided a real-life example (of a post-market scenario that is to be avoided) from a separate CDRH-regulated industry. A company that makes blood lead tests found out that its assays were delivering falsely low lead readings, and it concluded that the defect was likely related to a separate manufacturer’s blood tubes. The company contacted the manufacturer to let them know, but the manufacturer never followed through on an investigation, so now both companies are under an FDA warning letter. Translated to component automated insulin delivery, attendees fleshed out a hypothetical scenario: Someone calls a CGM complaining of insulin over-delivery, and it doesn’t seem to be the CGM’s fault. It is then incumbent on the CGM company to find out who the other component manufacturers are and notify them – they will then have to get their logs out and look. We are intrigued by the idea of a third-party, unbiased adjudicator who could determine which device was at fault, especially in the likely ambiguous case. Hogan Lovells’s Ms. Yarmela Pavlovic suggested that the issue is even bigger, in the case that someone reports an issue with an iCGM, and it turns out that the problem actually had to do with the algorithm and could be putting other people in danger. Right now, such incidences are handled under quality contractual agreements between companies, but what will happen if the companies aren’t in direct contact? How quickly can or does the iCGM company have to get in touch with the algorithm company/FDA so a recall can be initiated? We particularly like the idea of establishing a registry wherein a component manufacturer can automatically know what other components a caller is using, though we don’t know how possible this would be.
9. Cybersecurity Concerns Are Valid but “Solvable Problems”
Although concerns regarding the security of AID systems were raised during breakout sessions, the issue was put into context quickly and did not derail the conversation significantly. Dr. Russell pointed out that with greater connectivity “inevitably” comes more points of entry for “bad actors,” arguing that it is far safer to require bolus information to be inputted into the pump, rather than a smartphone. University of Toronto’s Dr. Joseph Cafazzo characterized the issue as “a very solvable problem” so long as measures are taken to ensure authentication and strict data logging. As one attendee argued, “we hear from users that because of security concerns we have to solve this problem, as opposed to simply not including smartphones.” Dr. Kowalski, while acknowledging the need for security, emphasized: “In the list of things I worry about in my diabetes life, somebody hacking my pump is probably one millionth.” A lively discussion between Dr. Lias, Mr. Panzirer, Mr. Look, and a rep from SOOIL (below) painted a similar picture –we give Dr. Lias the utmost credit for the way she handles difficult regulatory conversations with people from the DIY/#WeAreNotWaiting community – they also of course deserve the utmost credit). Although security should certainly be part of the discussion, we agree that it need not be a dominant issue. Indeed, Dr. Cafazzo pointed out that only two medical device hacks have been recorded in the last 10 years, one of which was demonstrated on Medtronic’s pumps. A Medtronic rep said that from a manufacturer’s perspective, “it’s not enough to never have had a cybersecurity issue. You have to be able to protect communication, access, and data on that phone. It needs to be engineered.”
Conversation about Cybersecurity
Dr. Lias: People have made it pretty clear they’re interested in phones – we hear vaguely there are cybersecurity issues, and I’m curious about them.
SOOIL rep: I’ve been using phones to control my pumps for nine years. Occasionally one fails, so I go back to open loop. The security issue I do have is if I leave my phone sitting there and someone picks up my phone, then they have access.
Mr. Panzirer: The DIY community uses fingerprints to confirm bolus.
Mr. Look: My daughter has been on DIY for two years. The risks I think about as a father are not OS security and cybersecurity –it’s occlusion failures, it’s she forgot to put her pump on after her shower, it’s because we were just in the desert and the insulin got too warm.
Dr. Lias: I’m just saying there are risks out there…
Mr. Look: There aren’t. Technically there are, but they’re so miniscule.
Dr. Lias: What are they, what can be done now? I’m not necessarily saying they aren’t mitigated or can’t be, I’m just saying what are they? I hear a lot of people talk generally about issues associated with phone use - not just cybersecurity issues - so I'm just hoping for further clarification.
-- Brian Levine, Maeve Serino, Adam Brown, and Kelly Close