Abstract
Diabetes Technology Society (DTS) convened a meeting about the US Food and Drug Administration (FDA) Digital Health Software Precertification Program on August 28, 2018. Forty-eight attendees participated from clinical and academic endocrinology (both adult and pediatric), nursing, behavioral health, engineering, and law, as well as representatives of FDA, National Institutes of Health (NIH), National Telecommunications and Information Administration (NTIA), and industry. The meeting was intended to provide ideas to FDA about their plan to launch a Digital Health Software Precertification Program. Attendees discussed the four components of the plan: (1) excellence appraisal and certification, (2) review pathway determination, (3) streamlined premarket review process, and (4) real-world performance. The format included (1) introductory remarks, (2) a program overview presentation from FDA, (3) roundtable working sessions focused on each of the Software Precertification Program’s four components, (4) presentations reflecting the discussions, (5) questions to and answers from FDA, and (6) concluding remarks. The meeting provided useful information to the diabetes technology community and thoughtful feedback to FDA.
Digital health is an emerging paradigm for medical devices to communicate. Digital health can include communication with other devices, with patients through software known mobile applications residing on smartphone, or with the Internet. FDA has announced efforts to develop new programs to ensure access to safe and effective digital health products. One of these programs will be the FDA Digital Health Software Precertification Program. FDA intends to focus on software as a medical device (SaMD), defined as software used for medical purposes without being part of a hardware medical device, for the initial phase of the Precertification Program. FDA is not defining software as being limited to SaMD. In the past few months, FDA has published multiple updates to a working model document, outlining the current thinking of the agency about this program.
A meeting was convened on August 28, 2018, in Herndon, Virginia, by DTS to foster two-way communication between the US Food and Drug Administration (FDA) and clinical, academic, and industry communities to provide input to the FDA Digital Health Software Precertification Program. DTS intended this meeting to be an opportunity to understand FDA’s needs and provide feedback as FDA continues planning for the next phase of the pilot effort.
Background of the FDA Digital Health Software Precertification Program
The FDA intends for a future regulatory model to provide more streamlined and efficient regulatory oversight of software-based medical devices. This program will be known as the FDA Digital Health Software Precertification Program and is intended to be a voluntary pathway with a regulatory model more tailored to the software development lifecycle than the current regulatory paradigm. The goals of the Precertification Program are ensuring the safety and effectiveness of software technologies while supporting patient access to these technologies. The program is further intended to provide more streamlined and efficient regulatory oversight of software-based medical devices from manufacturers who have (1) demonstrated a robust culture of quality and organizational excellence and (2) committed to monitoring real-world performance of their products after they are on the US market.1,2 This proposed approach will first focus on the software developer and/or digital health technology developer, rather than on the product, which is the FDA’s current approach to medical devices.
Software can be quickly adapted to respond to adverse events and other safety concerns. FDA intends to establish a new regulatory framework that is equally responsive if issues should arise. This is because the FDA’s current regulatory framework for devices can be slow in some cases when a more agile regulatory paradigm may be needed to accommodate rapid development and innovation in software-based products compared to what is needed for hardware-based products. The intent of the FDA Software Precertification Program is for software products from precertified companies to meet the same safety and effectiveness standard that the agency expects for products that have followed the traditional regulatory path to market, while improving timely access to innovative products. A pilot program focused on development of a precertification framework was announced by FDA in July 2017, and the FDA has worked with nine selected industry organizations over the past year to inform development of the Software Precertification Program. 3 The term “software as a medical device” (SaMD) is defined by the International Medical Device Regulator’s Forum (IMDRF) 4 as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. 1
FDA has indicated that the Digital Health Software Precertification Program will consist of four key components. FDA is currently deciding on specific policies for each component.
The first key component is developing policies for excellence appraisal and determination of the precertification level. This component will identify objective criteria and methods for precertifying a company and deciding whether a company can retain its precertification status. At this time, FDA is considering basing their determination of excellence on five culture of quality and organizational excellence (CQOE) principles. These include (1) patient safety, (2) product quality, (3) clinical responsibility, (4) cybersecurity responsibility, and (5) proactive culture. The current plan is for software developers to be assessed by FDA or an accredited third party for the quality of their software design, testing, clinical practices, and real-world performance monitoring and for other appropriate capabilities to qualify for a more streamlined premarket review. The FDA is also currently considering two levels of precertification based on (1) how a company meets the excellence principles and (2) whether the company has demonstrated a track record of delivering products. Based on whether a company does not have or does have such a track record, then the company will be classified and regulated in this program respectively as a Level 1 or Level 2 software developer.
The second key component is determining the review pathway by way of a risk-based framework. This approach will determine the premarket review pathway for a software product. With this regulatory program in place, a precertified company could market a lower-risk device either without FDA premarket review or with only a streamlined premarket review based on both the company’s precertification level and the level of risk. FDA intends to leverage the IMDRF risk categorization framework in determining the risk level of a product, focusing on the purpose of the software and the medical condition that it is intended to treat. 1
The third key component is developing a streamlined review process. This component of the Software Precertification Program will require identifying the necessary information that must be submitted for software to be reviewed for determining safety and effectiveness.
The fourth component is deciding how to monitor real-world performance in the postmarket setting. FDA wants to use some real-world information about SaMD to verify ongoing excellence of precertified companies as well as to identify emerging risks. Various objective and subjective types of data, including outcome results, could be selected for incorporation into this part of the program’s evaluation process.
FDA has stated that the fourfold goal of the Software Precertification Program is to deliver nonburdensome regulatory oversight that (1) identifies precertified developers of SaMD that can be trusted to develop high-quality SaMD products, (2) monitors product performance across the entire lifecycle of SaMD, (3) delivers a streamlined premarket review, and (4) verifies the continued safety, effectiveness, and performance of SaMD in real-world use with postmarket data.
FDA’s five aims for this program are to (1) benefit a participating precertified software-developing organization by offering streamlined premarket review as well as structured collection and review of real-world postmarket data, (2) create a streamlined review process for SaMD that is no less safe and effective as the current review process, (3) enable a regulatory framework that can accommodate software iterations, (4) ensure high-quality software products throughout the lifetime of the products, and (5) adapt itself according to its effectiveness.
The Software Precertification Program is intended to demonstrate that participating organizations have documented the ability to build, test, monitor, and proactively maintain and improve the safety, efficacy, performance, and security of their medical device software products, so that they will meet or exceed existing FDA standards of safety and effectiveness. Anticipated benefits for various stakeholders from the FDA Digital Health Software Precertification Program can be found in Table 1 (adapted from the FDA Working Model 2 ).
Anticipated Benefits for Various Stakeholders From the FDA Digital Health Software Precertification Program.
Source: Adapted from the FDA Working Model. 2
FDA has been seeking input from the public on the four components of the program, which they have also referred to as four streams. These include (1) excellence appraisal and determining precertification level, (2) review pathway determination, (3) the streamlined premarket review process, and (4) real-world performance.
Meeting Format
Prior to the FDA Digital Health Software Precertification Program Meeting, FDA and DTS together developed and distributed four sets of challenge questions for meeting attendees to address. These are contained in Appendix A.
At the meeting on August 28, 2018, the agenda included introductory remarks, a Software Precertification Program overview presentation from FDA, working breakout sessions that focused on each of the four components of the Software Precertification Program (excellence appraisal, review determination, streamlined review, and real-world performance), and then four presentations reflecting the discussions and conclusions of the working sessions. All of the 48 meeting participants (Figure 1) were given the opportunity to contribute to each of the presentations. Following all these presentations, FDA officials addressed topics that they selected from a set of questions and a set of recommendations developed by the participants during the working sessions. The full sets of questions and recommendations are set forth in Appendix B and Appendix C of this article.
Meeting participants at the FDA Digital Health Software Precertification Program Meeting.
Summaries of Presentations
Introductory remakes were provided by David Klonoff, Medical Director, Diabetes Research Institute at Mills-Peninsula Medical Center (Meeting Chair); Kong Chen, Acting Section Chief, Energy Metabolism Section, Diabetes, Endocrinology, and Obesity Branch of NIDDK (NIH); and Allan Friedman, Director of Cybersecurity Initiatives at the National Telecommunication and Information Administration (NTIA), US Department of Commerce. The keynote address was delivered by Bakul Patel, Associate Center Director for Digital Health at FDA, after which he answered questions from the audience. The participants’ comments in this report are all summarized from a meeting transcript.
Bakul Patel reviewed the current working model of the Precertification Program, many details of which are contained the background section of this report. He explained how the program was intended to create an ecosystem of trust, transparency, and verification. He described the four components of the program and the five excellence principles to qualify for precertification. Patel provided many details of the program according to FDA’s current thinking. He mentioned that the FDA Digital Health Software Precertification Program could be considered to be similar to the TSA Precheck program, where a participant shares information with TSA in exchange for a better airport experience.
Patel stated that most devices coming to FDA currently contain software that generates data. He also mentioned that approximately 1000 new health-related apps are introduced through the Apple Store monthly, and while many are general wellness products that do not meet the definition of a medical device, FDA expects increasing numbers of SaMD products in the near future.
Patel mentioned that there have been questions raised as to how this new process will differ from the 510(k), de novo, and Premarket Approval Application (PMA) pathways. Much of the content that the FDA will analyze is the same, but they will need to figure out how they can look at the content differently. The key factor may be reducing overlap. Something addressed in excellence appraisal may not need to be reviewed again in the review part of the process.
Finally, Patel stated that FDA is seeking input from industry about what would make the program valuable to them. For most software developers, the advantage will be streamlined review and the ability to make changes to a product once it is already on the market. The FDA wants to hear from clinicians as well. Precertification should be advantageous to them in that it may help clinicians recommend products to patients.
Allen Friedman commented on open source software. The US Department of Commerce feels very strongly that there should not be a separate solution for the energy sector, for the national security sector, and for the health care sector, and thinks that this is something that all sectors of the economy work on together. What we need to deal with is third party code that we do not know much about. Often we are not using the latest up to date products or else we are using an up to date product that does not use the latest components within it. Open code can help developers understand the risks of the software they are using and facilitate a secure development process.
Summaries of Conclusions About Four Streams From Breakout Groups
This section is a recap of the discussions in the breakout groups, rather than a review of the components of the program. Each of the 48 meeting attendees participated in a breakout group of six attendees for each of the four streams.
A pair of facilitators for each stream reviewed the conclusions of all the eight groups for that stream. These facilitators prepared a summary, which reflected all the groups’ ideas and then gave a presentation of the conclusions for all the attendees for that stream. Each of the four following sections is a summary of a presentation about one of the four streams delivered by the facilitators. The four summary statements reflect concerns and questions posed to FDA, but do not reflect FDA’s responses and clarifications.
Stream 1: Excellence Appraisal
The excellence appraisal portion of the program describes the criteria and standards that a company would be expected to demonstrate in order to obtain precertification.
During the meeting, when evaluating the excellence appraisal framework, many companies questioned how the FDA will give credit to existing recognized standards (eg, ISO 13485) in their review of company excellence. At this time, it is unclear which standards, if any, could serve as predictors of success in the program. Additionally, most standards address competence, or the minimum acceptable level of performance, whereas the FDA hopes that companies will use precertification as an opportunity to demonstrate excellence. The group noted that many standards do not relate to the specific intended uses of medical products and that this difference in intended use could lessen the relevance of meeting such standards. Participants also suggested that the FDA may want to consider using an advisory committee that reviews excellence appraisal applications. Alternatively, an advisory committee could advise on a one-time basis whether a standard was relevant and now it could be used.
Stakeholders also noted that given the public relations impact of FDA’s approval or clearance of SaMD under the existing regulatory framework, companies need to know how the FDA will similarly seek to instill, encourage, and inspire trust in the public about products that come to market through the Software Precertification Program. Trust must be earned over time. The public will need to hear that the program itself is promoting safety and effectiveness. FDA can consider two strategies. The first is to collect data on how products that have gone through precertification have performed against an objective measure of safety and effectiveness and then compare those products with other products that go either traditionally or concurrently through the 510(k) process. The expectation is that there would be either no difference or the precertified company’s products would turn out to be even safer or more effective than the ones that go through the 510(k) process. The second strategy is to collect data from multiple companies and synthesize/release that aggregated data with a similar comparison between outcomes of products as a group that went through different regulatory pathways. Many participants suggested that the FDA compile real-world data about the participants that are successful in the Software Precertification Program and identify factors that are correlated with success. This will help the FDA advise other companies that are seeking precertification.
Finally, participants asked if there are novel approaches to machine learning and artificial intelligence that, if incorporated into a product that is approved or cleared by the FDA, could become a precedent for other clearances or approvals. The consensus was that each algorithm is unique, making precedence unlikely, although most small groups did not express an opinion on that topic.
Stream 2: Review Pathway Determination
In this stream, stakeholder discussion focused on how FDA should distinguish between “major” and “minor” changes to software, how should “major” and “minor” be defined, and when and how manufacturers should provide the FDA with notice of such changes. With respect to the characterization of changes, stakeholders agreed that three types of “major” changes included (1) changes in intended use, (2) any change that is high risk (major impact on safety or effectiveness of the device), and (3) any change that the FDA and the manufacturer agree will be considered a “major” change during initial communications with the FDA. Any change that does not meet at least one of these three criteria for characterization as a “major” change should be classified as a “minor” change.
Consistent with the above, stakeholders recommended that FDA communicate with manufacturers during the precertification process to ensure agreement regarding what constitutes a “major” or “minor” change to the product. Predetermining the characterization of changes as major or minor will help both manufacturers and the FDA prepare for future regulatory submissions, where required. An emerging concept called semantic versioning might be used to distinguish major and minor changes.
Stakeholders also discussed the logistics of how companies will report changes to the FDA. Some stakeholders asked whether the FDA should be informed about new products and major changes to existing products from precertified companies if such products do not undergo premarket review. Moreover, when the FDA does need to be notified, how would manufacturers be expected to provide such notice? A framework that could be used by FDA is the Certified Health IT Product List, which lists software that is acceptable for Medicare claims. Another framework that FDA could use to determine whether a change is minor or major is OKR—objectives and key results—to assess whether the purpose of a software product is being accomplished.
Finally, some suggested that inclusion of universal device identifiers (UDIs) would be a useful addition to an updated registration and listing database for precertified software. Stakeholders noted that it can be difficult to locate product-specific information in FDA’s existing registration and listing database, and that inclusion of a product-specific identifier (such as the UDI) could help stakeholders more quickly identify the information applicable to a specific device.
Stream 3: Streamlined Review
To evaluate the benefits of participating in the Software Precertification Program, it is critical that industry understand how the normal review process compares to the elements that will be required in a “streamlined” review process. For example, while presubmission meetings can expedite the substantive review of a product application, it is unclear whether the number of presubmissions that would be required to support a streamlined review will make the process truly streamlined or more cumbersome, depending on what is required. Additionally, they would like to know the expected number of rounds of presubmission review for specific product types, and which products are unlikely to require any prior presubmission before entering the streamlined review. Companies need to be able to plan, and clarification of the specific timelines for the review pathway and the streamlined review pathway (through clearance of the product) will be helpful.
What elements should the FDA be considering during streamlined review to ensure safety and efficacy? Two themes emerged during discussion. The first approach was to look at what the FDA reviews as part of its “normal” review process and retain only those software elements that are highest risk per a hazard analysis. Then implement mitigations for those risks. The FDA would review only those high-risk elements of the software.
The second approach is that if FDA is satisfied with a company’s processes and approach to development and validation of products, then FDA’s focus during streamlined review should be exclusively on data used to support claims or usability of the product because the development of studies would have already been discussed with FDA in advance of the streamlined review. In that case, much of the information that FDA considered during the decision to precertify the company could be eliminated from the streamlined review process. The FDA should focus on the data that are needed to support claims and demonstrate the usability of the product. Human factors usability evaluation was a point of discussion on this theme. This is a product feature that is very relevant to the diabetes industry because many of the products are used by lay users. Current usability evaluations are subjective, but objective and systematic evaluations are needed.
Human factors evaluation is a point of tension for many companies because there is limited human factors staff at FDA, so that tends to be an area where reviews may slow down. It was suggested that FDA hire additional personnel familiar with human factors assessments to better enable streamlined review,
There was a request that there be efforts within FDA to align the streamlined review with expectations of post market compliance. This means good alignment between what is agreed to during the review determination and then the streamlined review and then how companies may be assessed during an inspection.
There was a specific proposal that came from one of the groups for developing decision trees for assessing whether, if a product happens to fall into a category, future streamlined review would be needed for modifications. Companies want greater certainty about when they might need to go back to the FDA and where they can work with the FDA to set the parameters around those changes.
Clinicians also mentioned that it would be helpful to know that the FDA had considered cybersecurity. Cyber vigilance is an element of the excellence appraisal, so there was not necessarily a consensus on what that would mean for streamlined review, but it is something that should be taken into account during the review. Finally, the streamlined review should be in line with the total product lifecycle approach.
Stream 4: Real-World Performance
Participants agreed that this area is much more concrete than the others. The key decisions that need to be made for the Software Precertification Program relate to the following two questions:
Which type of real-world performance data should be monitored by manufacturers and which should be monitored by the FDA?
Should a company that meets a higher level of certification have the same data requirements for real-world reporting and monitoring as a company that meets a lower level of precertification?
Real-world performance data that they know well and can explain should be easily collected so that they can be used to articulate how risk is managed in these products. Having access to adverse events data that are complete and accurate is a critical part of showing that devices are safe and effective. For review efforts to be most effective, the data should relay utilization and outcome detail of the product features. Therefore, it is essential to share this data with the FDA. Make sure it is complete and accurate and then have a great way of dealing with it.
For review efforts to be most effective, the data should relay utilization and outcome details of the product features. What is the software telling patients and providers and what is the impact of this software. How often are features being used, so regulators can know where to focus their review? This will determine the impact of a given feature or features and show which are used most often and which are most beneficial to the patient. Many lower-risk products will not be proactively assessing downstream clinical outcomes.
There is a cost to collecting real-world performance data. Companies will consider the cost when deciding whether to go through the precertification process or the 510(k) process. Real-world data collection should focus on quality, not quantity. We think companies should be rewarded for providing high-quality data. It will be easy for companies to provide a mountain of data, but it will help both the FDA and industry to focus less on volume and more on quality data. The data must be accurate and should relay utilization and outcome details of the product.
Participants agreed that real-world data requirements should depend on the risk level of the intended product claim. All companies, regardless of level of precertification, should expect the same rigor for postmarket review. The group also addressed the topic of whether organizations that meet a higher level of precertification should have the same requirements for real-world reporting as organizations with a lower level of precertification. The consensus was no they should not have the same requirements. Although Level 1 and Level 2 companies should expect the same rigor for real-world data reporting, these two types of companies might report different frameworks of results, or else results that best fit their identity and function as a software product or company. For precertification, Level 1 companies might tend to focus their real-world data on premarket related data because there they just don’t have the breadth of information in the marketplace yet, and Level 2 companies might tend to emphasize postmarket data because they will have a lot of history to report that demonstrates their qualities as a company and what type of data they can deliver.
While stakeholders acknowledged FDA’s desire to make real-world data readily accessible to the public, most participants agreed that performance data—particularly sensitive data—should be kept private (ie, confidential between the manufacturer and the FDA) until it is better understood how the public might interpret (or misinterpret) certain information collected by the FDA. In terms of the data to be collected, participants recommended that the FDA consider the intended use of the product, and based on such intended use, identify those results that best enable the agency to evaluate whether a product is performing as intended.
Industry expressed concern about whether certain types of data provided to FDA would become part of the public domain. Types of data that were concerning included raw data, information on a more extensive set of metrics than currently required, development processes long-term usage, complaints, the amount of technical support needed, and postmarket outcomes. Industry was not comfortable with these types of data (whether used to determine precertification or to verify ongoing excellence post-launch) possibly becoming public. Companies were concerned that consumers will not be able to understand the additional data that they will have access to for devices that are cleared through the Precertification Program compared to the lesser amount of information that will likely be available for devices cleared through other routes for device clearance.
Finally, participants were concerned about what should be an appropriate risk matrix for the FDA to use in determining which adverse outcomes should result in a loss of precertification status or other actions. Currently all of our history is about adverse events for products, but precertification is for a company. Reporting of adverse events for companies has to come with an appropriate context and review from the company when reporting to the FDA to explain the significance of the adverse event. (Participants recommended against structuring the program such that an adverse event in one product would trigger loss of precertification for all products. A precertified company with several products has to have a way of measuring the impact of an adverse event on all the company’s products and we do not want to penalize a beneficial product because of a product with a failure.
Questions for FDA About Precertification of Software as a Medical Device
At the conclusion of the meeting, FDA staff responded to several questions and comments posed by participants, including the following:
1. How will the four levels in the SaMD classification by IMDRF match up with the three FDA medical device classifications?
Response: In a future state the FDA will be thinking about international harmonization. The risk category framework proposed in the Software Precertification Program Working Model aligns with the framework described by the International Medical Device Regulators Forum. However, the FDA’s existing classifications remain relevant and somewhat controlling unless and until Congress changes the Food, Drug and Cosmetic Act. Higher risk categories could still require Premarket Approval (PMA) applications depending on the specific technology and intended use. Most SaMD are new innovative products that likely require De Novo reclassification requests.
2. How will review times be reduced?
Response: There are four ways that the FDA is considering reducing review times.
FDA is considering the list of items typically included in a premarket submission and will propose reducing to the most critical elements necessary for a streamlined review. Some items will be shifted into the excellence appraisal or used as real-world performance information.
FDA is also considering review processes that can be shifted earlier into the presubmission phase of review.
Reviews will be completed in a more interactive manner.
Some portions of review may be able to be automated.
Does precertification and the streamlined prereview process replace device classifications) and existing premarket review processes (eg, 510(k)s and PMAs)? Response: The Software Precertification Program does not replace device classification, as we know it today. It will be a voluntary program, and companies can still submit their products through the pathways that exist today.
3. With the design of the program, products made by precertification companies would have more postmarket requirements than devices that are not within the program. How will FDA work through this discrepancy?
Response: Precertified companies introducing SaMD products will have substantially reduced premarket requirements, and in exchange will be required to share postmarket performance metrics already collected by the organization.
4. Should software intended for a high-risk disease automatically be labeled as a high-risk product?
Response: It depends on the intended use and indications for use of the product. If the intended use is not high risk, then the product should not be considered high risk. The community should consider submitting comments to the docket about how risk should be considered.
5. How are recalls handled in the Software Precertification Program and can a modification of a software bug not lead to citation for a recall?
Response: The agency is aware that this needs to be addressed. Looking at the cybersecurity example, there are already similar concepts in place where the FDA provides criteria for determining when certain product modifications are not considered field corrections. The major issue is whether or not there are workflow changes and whether there are claims modifications. The broad-scale answer is that the current guidance already accounts for this. On a smaller scale, the answer may be more granular depending on what kind of software bug or software change is being considered. But there are existing mechanisms to be able to address this.
6. SaMD that is currently not regulated should remain unregulated.
Response: This program pertains to medical devices that are classified as medical devices currently and are not under enforcement discretion. The FDA is working on mapping the framework, not expanding the definition of a medical device for this program.
7. Can a company without a medical background be included in the program?
Response: Any company wishing to participate would need to demonstrate all five excellence principles. If a company meets all of the principles, including clinical responsibility, then the company could be placed into level 2 precertification.
8. Excellence means a high bar. Is FDA trying to get just the elite in this category? Or is better than average good enough? Or is it just for any company better than the bottom scum?
Response: Cisco Vicenty at FDA expressed the personal opinion that the current system works for companies to demonstrate that they are compliant, but this system does not allow them to bring the best value to the product. If we looked tomorrow, without a transition time for trust and mind-set shift, then it would be a very tough transition for the current device space. When companies gain perspective and get fear out of the equation in terms of how they will interact with the FDA, then most should be able to shift quickly into a much more value and quality driven, productive mind-set. This takes time to implement.
9. If only 5% of companies engage in the program, will that be enough?
Response: This would represent about 1200 companies that are currently in the medical device space. We just need to get the process going. Anything that relieves the burden on FDA is great. As a resource constrained organization, this would allow us to focus more on other things, especially if these are companies that are submitting a lot of 510(k)s and PMAs.
Conclusion
The FDA officials and the participants expressed concluding thoughts. The FDA noted that presubmissions and informational meetings are welcome. FDA asked participants to formally express their concerns during the upcoming public comment period for the program. FDA stated that while hearing about the issues raised at the meeting is helpful, there exists a formal process and public comment period for stakeholders to also submit written questions/comments via the official website to go on record at the FDA.
Finally, participants voiced a need to continue the conversation and continue to include diverse groups in the discussions of this program. The level of collaboration between industry and the FDA on this program was encouraging to all parties involved and it is clear that the Precertification Program has a bright future.
Most participants agreed that the Software Precertification Program will lead to better information for the users about the quality of products being cleared. Clinicians will likely gain a greater understanding of what to recommend for their patients to be better able to advocate for patient interests.
The FDA Digital Health Software Precertification Program shows foresight from FDA in three key areas. The FDA (1) recognizes that there is a need for streamlined processes, (2) will face a deluge of mobile apps and needs a way to process them, and (3) sees that clinicians need real-world performance data. The FDA is on the right track and we are excited to see how this program develops.
Footnotes
Appendix A
Appendix B
Appendix C
Acknowledgements
The authors thank the following meeting attendees for their contributions to the ideas and discussions summarized in this report: DTS would like to acknowledge the following attendees from the Food and Drug Administration: Marisa Cruz (CDRH), Kathryn Drzewiecki (CDRH), Martin Ho (CDRH), Diane Mitchell (CDRH), Bakul Patel (CDRH), Lauren Rodriguez (CDRH), Naomi Schwartz (CDRH), Cisco Vicenty (Case for Quality), and Beau Woods (CDRH). We would also like to acknowledge the following attendees from industry: Daniel Bernstein (Abbott Diabetes Care), Robby Booth (Glytec), Colleen Burdel (Ascensia Diabetes Care), Ginger Emrich (Roche Diabetes), Allan Friedman (National Telecommunications and Information Administration), Rune Frisvold (Lifecare), Matthew King (Insulet), Kate Lee (Bigfoot Biomedical), Mary Beth McDonald (Glooko), Devyani Nanduri (Abbott Diabetes Care), Chandra Osborn (One Drop), Stewart Polley (Novo Nordisk), Mihailo Rebec (Waveform Technologies), Pam Schaub (Ascensia Diabetes Care), Beth Stephen (Medtronic Diabetes), Peter Winarsky (Vida Health), Jonathan Woo (EOFlow), and Michael Zupon (MannKind Corporation). The authors thank Annamarie Sucher for her expert editorial assistance.
Abbreviations
CQOE, culture of quality and organizational excellence; DTS, Diabetes Technology Society; EAP, expedited access pathways; FDA, US Food and Drug Administration; IMDRF, International Medical Device Regulator’s Forum; KPI, key performance indicators; OKR, objectives and key results; PMA, Premarket Approval Application; RWPA, real-world performance analytics; RWPD, real-world performance data; SaMD, software as a medical device; UDI, universal device identifier; QMS, quality management systems; QSR, quality system regulation.
Declaration of Conflicting Interests
The author(s) declared the following potential conflicts of interest with respect to the research, authorship, and/or publication of this article: DCK is a consultant for Ascensia, AstraZeneca, EOFlow, Intarcia, Lifecare, Novo, Roche Diagnostics, and Voluntis. MH is a partner at Hogan Lovells and serves as a consultant to companies in the medical device and digital health industries. YP is a partner at Hogan Lovells and serves as a consultant to companies in the medical device and digital health industries. MR is a partner at McDermott Will & Emery. His thoughts are his own and should not be attributed to the firm or any firm client. AS is the cofounder of a medical device company, Cognita Labs. ES received research support from DEXCOM for the conduction of inpatient CGM studies. BMT is a partner in the law firm of Epstein Becker and Green, and his law firm represents a wide variety of organizations including many drug and medical device manufacturers as well as health care providers, payers, and investors. FK, DA, SA, EGB, JB, KC, AD, AF, MM, SM, PP, SS, MT, and JW have nothing to disclose.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article. Abbott Diabetes Care, Ascensia Diabetes Care, and Intel each provided a grant to the Diabetes Technology Society to support the meeting project.