By David Harlow, JD MPH, Principal, The Harlow Group LLC
Twitter: @healthblawg
Host: Harlow on Healthcare
The FDA had a digital health banner day on December 7, announcing one final guidance and two draft guidance documents (with a 60-day comment period). Collectively, these guidances cover a range of digital health issues, and it is worth reading FDA Commissioner Scott Gottlieb’s statement about them as well as each individual document:
- Clinical and Patient Decision Support Software (CDS and PDS) (Draft)
- Changes to Existing Medical Software Policies Resulting From Section 3060 of the 21st Century Cures Act (Cures Act) (Draft)
- Software as a Medical Device: Clinical Evaluation (SaMD) (Final)
These publications come as part of the FDA’s effort to improve its approach to digital health, to continue to work on drawing the line between digital health tools that are properly regulated as “devices” by the FDA and those that are not. Since some digital health tools will inevitably be subject to regulation while many will not, the agency has previously issued a high-level plan for streamlining its processes. Issuing these guideline documents is a further step towards creating some predictability for folks in the industry who may shy away from including certain functionality in products for fear of being subject to unknown sorts of regulatory review by the FDA.
The agency has a history of articulating its position on where the line is to be drawn, on how it is to exercise its discretion in regulating devices. While many “consumer-grade” and “book-on-a-screen” sorts of tools will fall into the category of things the FDA doesn’t want to spend its time reviewing, it should come as no surprise that clinical decision support (CDS) software or software as a medical device (SaMD) will include digital tools including proprietary algorithms where the treating physician is unable to “look under the hood” and check the tool’s work, replicating the tool’s “thought process.” We also need to remember that these issuances come in the context of the broader agency approach to digital health, an ongoing struggle with how to regulate in this arena. How does an agency that can take months or years to review an application respond to an industry that iterates weekly or monthly with new versions of applications being released, or even more frequently, and more obscurely, as an artificial intelligence takes in new data and continually adjusts an algorithm that is an inscrutable “black box” as far as regulators and clinicians are concerned, yet is being put forward as a source of diagnostic or treatment recommendations?
FDA has done a very good job of moving the ball forward, though there is certainly room for improvement, and there is opportunity for comment on two of the three guidance documents announced. It is worth noting that the SaMD efforts are based on the principles articulated by a group of medical device regulators from around the world (IMDRF) which chartered a working group to look at SaMD; the IMDRF document was unanimously approved by its management committee and was adopted by the FDA.
The draft CDS and PDS Guidance is intended to clarify what sorts of digital health tools will not be considered devices and thus not regulated by the FDA. Examples of things that will still be considered medical devices include:
- software programs that are intended to process or analyze medical images
- signals from in vitro diagnostic devices
- patterns acquired from a processor like an electrocardiogram that use analytical functionalities to make treatment recommendations
The draft Cures Act Guidance follows the legislative language calling on the agency to clarify that its jurisdiction does not extend to so-called lifestyle apps, so long as they are not designed for use in the diagnosis, cure, mitigation, treatment or prevention of a disease or condition. These could include “general wellness” apps addressing things like:
- weight management
- physical fitness
- relaxation or stress management
- mental acuity
- self-esteem
- sleep management
- sexual function
Of course, one would hope that consumer protection regulators would step in to keep a lid on the quackery that is sometimes offered in those categories. While there are useful apps in each of those categories, there are plenty of “lifestyle” apps that are not particularly useful and could be harmful. A separate issue is the range of permissions granted to any of these apps by a user when accepting their terms of use and privacy policy. (Caveat emptor!)
The final SaMD Guidance builds upon three prior guidance documents, all of which are adopted by IMDRF. (If you’re being compliant or adherent you’ll read those three first: SaMD: Key Definitions (2013), SaMD: Possible Framework for Risk Categorization and Corresponding Considerations (2014), and SaMD: Application of Quality Management System (2015).) The IMDRF recognizes that the regulated community touched by this guidance is more software-focused than hardware-focused (and is not the traditional medical device regulated community), thus requiring some new approaches to data gathering and analysis. This guidance identifies the three-part analytical process that an SaMD producer must go through, with citations to other relevant IMDRF guidance documents: (i) valid clinical association, (ii)analytical validation and (iii) clinical validation. The guidance emphasizes the need to incorporate real world data into the evaluation process and and the need to use independent review — noting that the need for independent review increases as the risk categorization of the SaMD increases.
The issuance of these guidance documents is a positive step forward by the FDA, but the devil is in the details. Comments on the draft guidance documents and the process of finalizing them will create greater certainty for the regulated community. In parallel, FDA has rolled out a fast-track approach to regulating in the digital health. While some have questioned the pre-certification process as being beyond the legal scope of the FDA’s discretion, the agency has enrolled a handful of large companies in the FDA’s pre-certification program, and is focusing on developers and their processes, rather than on the digital health products themselves, in order to deal with some of the fundamental difficulties in regulating in this arena.
This article was originally published on HealthBlawg and is republished here with permission.