The US Food and Drug Administration (FDA) is considering changes to the regulatory pathways for software used as a medical device (SaMD). Members of Dentons' Life Sciences team attended FDA's public meeting, "Fostering Digital Health Innovation: Developing the Software Precertification Program," held January 30 and 31 on the campus of the National Institutes of Health (NIH) in Bethesda, Maryland. Here are our key takeaways from that meeting.
Software as a medical device is defined by the International Medical Device Regulators Forum (IMDRF) as "software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device." FDA has also provided definitions and examples of software that it intends to regulate as a medical device (such as treatment-planning software that supplies information used in a linear accelerator) and contrasts that with other software products that will not be regulated as a medical device (such as encryption software that relies on data from a medical device, but does not have a medical purpose). A comprehensive list of definitions and examples can be found on the FDA's website.
Hardware vs. software: Does it call for a different regulatory approach?
Recognizing that the traditional process of reviewing medical devices no longer fits, FDA has worked to develop a more streamlined process for premarket review and clearance of software products regulated as medical devices. The new process is intended to be better calibrated to the development, maintenance and lifespan of software products and services.
For example, consider the role and function of the design history file (DHF) in the traditional medical device development process. The DHF should contain (among the other requirements of 21 CFR Part 820.30), records related to development activity, design outputs required to build the device, design verification and validation protocols, and everything required to transfer the device to manufacturing (whether internal or a contract manufacturer). Although those requirements reflect the more traditional notion of a medical device, they no longer match up to the typical software development and verification process. In addition, compared to hardware, which may be designed to continue to be used without modification for extended periods (especially in the case of implantable medical devices), software is regularly patched, updated and even replaced, often several times a year.
When FDA launched a new Precertification Pilot Program for companies developing SaMD in August 2017, the agency acknowledged the situation and noted that its
traditional approach to moderate and higher risk hardware-based medical devices is not well suited for the faster iterative design, development and type of validation used for software products. An agile paradigm is necessary to accommodate the faster rate of development and innovation of software devices as compared to other types of devices. Traditional implementation of the premarket requirements may impede or delay patient access to critical evolutions of software technology, particularly those presenting a lower risk to patients.
FDA's Software Precertification Program
When FDA announced the Software Precertification Pilot Program last summer, it indicated that a new regulatory review process for SaMD may include (a) precertification of digital health developers, for those developers that reliably manufacture high-quality, safe and effective digital health devices while providing appropriate patient safeguards, (b) an avenue by which pre-certified developers may market their lower-risk devices without additional FDA review or with a more streamlined premarket review and (c) collection by those developers of real-world postmarket data, to affirm the regulatory status of the product, as well as to support new and evolving product functions. The first component, precertification, has been the agency's focus for the past several months.
As the first step in the Precertification Pilot Program, FDA worked with nine pilots partners—Apple, Fitbit, Johnson & Johnson, Pear Therapeutics, Phosphorous, Roche, Samsung, Tidepool and Verily—to solicit their perspectives on what makes their companies' operations excellent, what practices and processes they put in place to create and maintain excellence, and how they know that those practices and processes are working. The pilot participants and FDA also considered how their approaches to operational excellence align with the excellence principles and common validating processes proposed by FDA. The agency then published a report on its visits to the nine pilot participants.
With regard to precertification, FDA appears ready to establish standards for "organizational excellence," under which an organization (rather than a particular device) might be pre-certified. The initial approach focuses on patient safety, product quality, clinical responsibility, cybersecurity responsibility and proactive culture. If an organization is pre-certified under these excellence standards, the organization may be entitled to launch new SaMDs with reduced premarket review requirements. Those organizations may also have lower reporting and qualification requirements before, for example, rolling out update and new versions. Eventually, FDA may authorize other competent authorities to precertify software designs and manufacturers, similar to the way the European Union relies on notified bodies to help manufacturers qualify medical devices for a European Conformity (CE) mark.
As part of the public meeting, FDA invited stakeholders to attend as the "tenth pilot partner." The agency convened workshops at which pre-certification pilot companies endorsed its step toward "right-sizing" the regulation of digital health. One participant from FDA noted that, although the agency will always maintain rigorous oversight of device safety and effectiveness, "nothing is sacred"—suggesting a willingness to reconsider and reconceive how those ends are accomplished.
Next steps in developing a software pre-cert program
The workshops not only provided an update from FDA, they also invited stakeholder input. Some of the open issues identified during the workshops included:
- Whether the pre-cert program would take the place of a traditional 510(k) or pre-market approval (PMA) review process for software products intended for use as medical devices
- Whether the pre-cert program would change the standards or length of premarket review (presumably the focus of the next phase of updating the regulation of SaMD)
- Discussion of the standards that would be used to measure organizational excellence, such as international standards or an FDA-developed model
- How payers might evaluate SaMD products for coverage and reimbursement, if SaMD products were cleared for market without clinical and other data that would currently be required for premarket review
- How the pre-cert program might change the current approach to premarket review for software products and related services (for example, the DHF)
- How FDA will likely manage the process of certifying organizational excellence, including whether it may establish standards for outsourcing precertification
- How the emerging new regulatory pathway might apply to "software in a medical device" (SiMD)
To help build this pathway, and to answer these and many other open questions, the FDA has issued a call to stakeholders: "We cannot build this program to create the right incentives, solve the right problems, and produce the right outcomes for public health without input and collaboration from all stakeholders."
To that end, and until March 1, 2018, stakeholders are invited to offer comment and recommendations at FDA's website. Although the process of updating the regulation of software products and services will take the next few years, this is the beginning of a process that is poised to radically change the clearance process for software as a medical device and digital health. Any businesses interested in the future of digital health should consider stepping forward and participating in the creation of this regulatory pathway.