When It Comes to Software As A Medical Device (SAMD), FDA Acknowledges that New Technology No Longer Fits The Old Regulatory Paradigm 

When you think about it, FDA’s general regulatory paradigm for regulating medical devices has enjoyed a tremendous run. The overarching statutory and regulatory foundation was started in 1976 and largely in place in its current form by 1997. (Think 510(k)/de novo/IDE/PMA requirements for the premarket phase and registration and listing/MDR/Part 806 and QSR procedures for the postmarket phase.) Yet, this structure has been sufficiently flexible to evolve administratively and to efficiently regulate a broad range of ever‑advancing device technology up through the present day. That is a run of more than 40 years, and counting – no small achievement.

The recent developments in digital health technologies has brought the first existential challenge to this regulatory paradigm. Of course, software has long been incorporated in medical devices and subject to traditional regulation (Software In A Medical Device, or SIMD). And early iterations of software as a medical device (SAMD) fared reasonably well under FDA’s 1989 draft policy for computer products and software. The 1989 draft policy was withdrawn in 2005. Nonetheless, for a period of years after that, FDA still managed to address SAMD reasonably well within existing regulatory structures.

There were stumbles. For instance, the Medical Device Data System (MDDS) regulation, issued in 2011, addressed software and hardware that transfers, stores, and displays medical device data. It was an example of fitting new software into the existing regulatory structure. It was supposed to be an innovative, “light touch” regulation, because it placed MDDS products in Class I, exempting them from all premarket review and subjecting them primarily to the QSR for quality control. By 2015, however, FDA had learned that QSR compliance was not particularly necessary for MDDS products; the agency therefore withdrew all active regulation as an exercise of enforcement discretion.

Still, the torrential development of digital health software has continued and indeed accelerated since 2011. We have seen the widespread advent of big data, machine learning, health care apps for both physicians and consumers/patients, health‑related wearables, and more. As a result, FDA has now publicly recognized that a new regulatory structure is needed. On July 27, 2017, FDA’s new Commissioner stated:

FDA’s traditional approach to medical devices is not well suited to these [digital health] products. We need to make sure our approach to innovative products with continual updates and upgrades is efficient and that it fosters, not impedes, innovation. Recognizing this, and understanding that the potential of digital health is nothing short of revolutionary, we must work toward establishing an appropriate approach that’s closely tailored to this new category of products. We need a regulatory framework that accommodates the distinctive nature of digital health technology, its clinical promise, the unique user interface, and industry’s compressed commercial cycle of new product introductions.

In line with this thinking, FDA has issued a “Digital Health Innovation Action Plan.” Many elements of this plan appear to be a round up of actions already taken. The interesting thing is that many FDA actions have involved getting out of the way, i.e., identifying categories of software that do not require regulatory oversight even though they could fit within the broad statutory definition of a medical device. For instance, the plan reminds everyone:

• We focused our oversight on mobile medical apps to only those that present higher risk to patients, while choosing not to enforce compliance for lower risk mobile apps;
• We confirmed our intention to not focus our oversight on technologies that receive, transmit, store or display data from medical devices;
• We chose not to focus our oversight on products that only promote general wellness. [Id. at 2.]

Notwithstanding FDA’s efforts, Congress has taken a step as well. The recent 21st Century Cures Act has a software provision (section 3060) that brought greater clarity by statutorily defining the categories of digital health software that FDA shall not regulate, including clinical decision support software (CDSS) for physicians. We summarized section 3060 here.

There remains the question about how to regulate SAMD that should be subject to FDA premarket oversight. A developer of SAMD needs to rapidly bring a product to market, obtain user/market feedback and iterate with modifications in order to discover functionality that truly adds value (and is worth paying for). As the Commissioner acknowledges, the traditional premarket review processes are too slow to support this process. At the same time, while it may be acceptable to rush slightly buggy but cool “beta” software to the consumer market, it is not acceptable in the medical arena if the beta software puts patients at risk.

FDA now proposes to balance the competing considerations with a Software Pre‑Cert pilot (a beta regulatory program, if you will). The pilot (including how to apply) is described in a Federal Register notice here. The crux is that the Software Pre‑Cert pilot will be used to develop “criteria [that] can be used to assess whether a company consistently and reliably engages in high-quality software design and testing (validation) and ongoing maintenance of its software product” (p. 5). Companies meeting these criteria could eventually “bring certain types of digital health products to market without FDA premarket review or after a streamlined, less-burdensome FDA premarket review.” A detailed FDA slide presentation is here.

This idea is interesting, because it will enable FDA to develop trust in the engineering robustness of the software up front, and perhaps focus more on clinical considerations in product review. That may be a viable way to shorten the review cycle, especially for software modifications.

Or it may not. In the world of digital health, it is difficult to predict what will and will not work. It is a time once again for “bold persistent experimentation.” So, while the remainder of the device industry is still evolving reasonably well within the old regulatory structure, FDA is developing a new regulatory paradigm for digital health. The Software Pre‑Cert pilot is a promising first step. It remains to be seen whether it succeeds well enough to move out of beta and into more general use.