In mid-2017 the FDA announced its Digital Health Innovation Action Plan and began implementing this plan by hiring digital health specific staff, launching its digital health software Precertification Pilot Program (we will talk more about this later), released guidelines [evaluating SaMD (Software as a Medical Device) applications, clarification on the 21st Century Cures implementation, etc] and built bench strength and expertise in CDRH’s (Center for Devices and Radiological Health) digital health unit. The FDA must be on top of its game, right? Maybe not just yet.
Traditionally, the FDA has recognized moderate and higher risk hardware-based medical devices and therefore (and rightly so) made the process of regulatory approval stringent. The barriers to acceptance are high. However, how could this ‘build and freeze’ model be applicable to varying risk (very low to high), agile, iterative design and development solutions that we are seeing today? The FDA certainly needs to fulfil its mission - protecting the public health by ensuring the safety, efficacy, and security of human and veterinary drugs, biological products, and medical devices; and by ensuring the safety of the nation's food supply, cosmetics, and products that emit radiation - but not at the cost of hindering innovation.
Reduce ambiguity on the FDA’s approach to new technology
Whatever the policy federal bodies release, they need to be clear and easy to navigate for developers and entrepreneurs to apply them on their own. In our conversations with a number of digital health companies, they have had to seek out, on a case-by-case basis, the FDA’s position on their technological offering. That is not only cumbersome for the company, but hugely inconvenient for the FDA. How can one validate a machine learning algorithm without actually running the algorithm? What about all things in the Cloud - what rules apply? The point is, we need an agile framework to fit agile technologies into.
What the FDA has done so far
The 21st Century Cures Act, enacted in December 2016 and public guidance released for comment in Dec 2017, reflected, and, in some cases, expanded
policies the FDA had already begun to implement. Under the 21st Century Cures Act, certain medical software, including certain software that supports administrative functions, encourages a healthy lifestyle, serve as electronic patient records, assists in displaying or storing data, or provides limited clinical decision support, is no longer considered to be and regulated as a medical device. These are exempt from FDAs rigor that is applicable to med devices. While FDA had already taken a more hands off approach to low-risk digital health technology, it has left us with much to desire. ‘Limited’ clinical decision support - too vague for actionability. CDSS software is loosely defined as an application that analyzes data to help healthcare providers make clinical decisions. Many types of SaMD, including AI and advanced analytics, may fall into this category when used for a health purpose. Per the Cures Act, in order to be excluded from the definition of device, the CDSS function must be intended to enable healthcare professionals to independently review the basis for the recommendations presented by the software. What this means is that end users should be able to reach the same recommendation/ decision without relying primarily on the software. Sources supporting the recommendation (guidelines, or body of evidence) should be publicly available, identified, easily accessible to and understandable by the intended user. A lot is up in the air with such a definition and leaves a number of AI and machine learning enabled solutions at the mercy of the FDA.
This is essentially part of the of the 21st Century Cures Act. This program is intended to help patients have more timely access to devices and breakthrough technologies that provide for more effective treatment or diagnosis for life-threatening or irreversibly debilitating diseases, for which no approved or cleared treatment exists or that offer significant advantages over existing approved or cleared alternatives.
The Breakthrough Devices Program expands upon the Expedited Access Pathways (EAP) program by making future 510(k)s eligible as well as Premarket Approval applications (PMA) and De Novo device submissions. All participants previously granted EAP designation will have designation as Breakthrough Devices; no separate action is necessary. Historically, claiming something is “de novo” was a less common way of getting devices to market, but it is becoming more popular (think Apple watch series 4, Pear therapeutics, IDx’s AI software, DreaMed Diabetes, etc)
Came into existence because traditional premarket requirements for devices may impede or delay patient access to critical health software, particularly those presenting a lower risk to patients. According to the FDA, the pre-certification program is ‘an efficient, risk-based approach to regulating digital health technology that will foster innovation of digital health products.’ But what does that mean, and how flexible can FDA be within the existing statutory scheme?
FDA’s Digital Health Software Precertification (Pre-Cert) Pilot Program offers insight into a possible regulatory approach. According to FDA, this voluntary program, established in July 2017, is intended to help the Agency design a tailored approach to regulating software by looking at the developer of the product rather than primarily at the product. Thus, if adopted in some form by the agency, this developer-targeted review would be a departure from FDA’s historic approach.
There are nine pilot participants in the Pre-cert program. The FDA have started collecting data to evaluate organizational excellence key performance indicators and measures, conducted initial site visits with pilot participants. The end goal is to release guidance for other similar offerings to get regulatory approval more simply. Pre-certified companies would need to submit less information, or in some cases no premarket submission at all. In that case, they could launch a new product and begin post-market data collection. The FDA wants to focus on RWD to demonstrate that the underlying software and internal processes are sufficiently reliable. Post-market data could help FDA assure that the new product remains safe and effective as well as support new users.
Not all rainbows and butterflies
Three Senators, Elizabeth Warren (D-Mass.), Patty Murray (D-Wash.), and Tina Smith (D-Minn.), in their letter to the FDA have challenged the pre-cert program on multiple grounds:
- Criteria of selection of the nine conveniently popular pilot participants
- Renewal of the pre-certification. Software companies could be allowed to use an entirely self-policing review system in order to maintain a status that affords them valuable access to a streamlined review process, even for high-risk software and even if they have no prior experience marketing medical devices.
- Why need a third party (IMDRF, see below) to evaluate the companies
- No clarity on payments - how companies should pay to be pre-certified
FDA medical device categorization puts devices in three different classes based on the level of control necessary to assure the safety and effectiveness of the device (Class I, II, III). But SaMD is plain SaMD irrespective of whether it informs diagnosis, or treats. The International Medical Device Regulators Forum (IMDRF) is a voluntary group of medical device regulators from around the world who have come together to reach harmonization on medical device regulation. In 2013, IMDRF formed the SaMD Working Group (WG). Chaired by the FDA, the SaMD WG agreed upon the key definitions for SaMD, created a framework (see proposed below) for risk categorization for SaMD, and the clinical evaluation of SaMD. The final version decision is yet to be declared.
EU: Less noise?
The European Commission (EC) has published guidelines to help determine whether a product should be regulated as medical device/in vitro diagnostic medical device software. “Guidelines on the Qualification and Classification of Stand Alone Software Used in Health within the Regulatory Framework of Medical Devices” (MEDDEV) provide the criteria for classification of standalone medical software. This MEDDEV first release was revised in July 2016. The criteria to determine whether a digital health technology such as a software falls within the scope of the MEDDEV are the following:
- The product is a software
- The software is a standalone software
- The software performs an action on data which is different from storage, archival, communication, simple search of lossless compression
- The action of the software is for the benefit of individual patients
- The software is specifically intended by its manufacturer to be used for any purposes listed in the definition of medical device, i.e.:
diagnosis, prevention, monitoring, treatment or alleviation of disease
diagnosis, monitoring, treatment, alleviation, or compensation for an injury or handicap
investigation, replacement or modification of the anatomy or of a physiological process; control of conception.
No matter what the medical device, a CE mark is a must and has to be affixed to it in accordance with the provisions of the applicable EU legislation. The CE mark is affixed to the medical devices by its manufacturers following a conformity assessment procedure, unlike in the USA where it is conferred by a government body. For some medical devices, essentially those falling within Class I and those regulated as in vitro diagnostic medical devices, a self-assessment process and a related Declaration of Conformity by the manufacturer is sufficient to get the CE mark.
A new Medical Devices Regulation will come into effect in the EU in 2020 which is likely to change the risk classification of SaMD and increase post-marketing surveillance expectations from these manufacturers. The GDPR and data protection related regulation has been applicable to SaMDs since May 2018 and will continue to be the case.
To be (an SaMD) or not to be?
A number of companies steer clear of medical device or SaMD territory and hang in the wellness region so they can thrive and flourish. There’s a reason companies have avoided the FDA route (of clinical trials aimed at diagnostic certification). It can be a quite the process, and they aren’t accustomed to working at the FDA level of tardiness and scrutiny. A number of companies have come out to say that they have had to cough up major dollars to apply for and go through the steps of certification. How many investors are willing to give newbies that amount of money just so they can get to the starting line? Inability to afford the seven-figure investment required to file with the FDA has lead to several missed opportunities. Having said that, the FDA rapidly cleared the Apple Series 4 watch with ECG capabilities as a medical device in Sept 2018 that intended to convey a clear message: the FDA embraces digital health.
Have you passed these regulatory milestones or are in the process of doing so? Are there any hacks and tips you want to share on how to get your digital health solution approved by the hallowed orgs? Let us know.