FDA's Evolving Regulation of Software-Based Health Products

Background

The term software as medical device (SaMD) can be broadly defined as software that is intended to be used for one or more medical purposes without being part of a hardware medical device.  SaMD products vary greatly in terms of uses and complexity, and include everything from image-reading software that runs on a smartphone to advanced artificial intelligence (AI) such as machine learning algorithms. 

While software-based medical products hold tremendous potential, the question of their regulation has challenged FDA.  At issue are the medical device provisions of the Federal Food, Drug, and Cosmetic Act¹ (FDCA), which were initially crafted to address medical devices existing in the mid-1970s when the Medical Device Amendments² were enacted.  These types of products were mostly hardware based (e.g., a scalpel, wheelchair, or MRI equipment), and iterative technology design changes were relatively infrequent. 

While traditional device hardware still plays a prominent role in healthcare, advances in computational power and new digital platforms are redefining the way modern care is accessed and administered.  From mobile medical applications and wearable health technology to advanced analytics and AI, digital products are a growing portion of the device economy.  These products have brought new market participants, who have in turn brought innovation and unique manufacturing processes that don’t fit neatly into existing regulatory boxes.

21^st Century Cures and Excluded Medical Software

Recently, both FDA and Congress have taken steps to address industry concerns regarding how the digital sector is to be regulated.  FDA created a Digital Health Program tasked with developing and implementing a new regulatory model for digital health technology.  Over the last five years, the program has issued several enforcement discretion guidance documents (e.g., the Mobile Medical Applications Guidance)³ explaining FDA’s oversight approach.⁴

While these guidance documents are certainly helpful, FDA guidance is not law and the products addressed by these documents only scratch the surface of digital health.  Because of continuing regulatory uncertainty, the digital health industry has persistently asked for more precise, binding actions.  Stakeholders received a measure of satisfaction when Congress enacted the 21st Century Cures Act⁵ (Cures Act) in December 2016, which contains provisions clarifying FDA’s jurisdiction over digital health products.  Specifically, Section 3060 of the Cures Act excludes certain types of “medical software” from the FDCA definition of device.  While most excluded categories are relatively well understood and already within FDA’s established enforcement discretion policies (e.g., lifestyle applications and medical device data systems), one category of particular importance, requiring additional interpretive clarity, is software intended for:

(E)(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

(ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and

(iii) enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient

unless the function is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system.⁶   

This type of software is generally referred to as “clinical decision support” (CDS) software. CDS 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 CDS function must be intended to enable healthcare professionals to independently review the basis for the recommendations presented by the software.⁷   

To clarify its interpretation of this provision, FDA issued a draft guidance on December 8, 2017.⁸  The guidance discusses each prong of the exclusion and provides some interpretive clarity regarding how software might allow independent review by a healthcare professional.  FDA says this prong will be met if the software clearly explains:

1) The purpose or intended use of the software function;

2) The intended user (e.g., ultrasound technicians, vascular surgeons);

3) The inputs used to generate the recommendation (e.g., patient age and gender); and

4) The rationale or support for the recommendation.

Consistent with the statute, the guidance says that users should be able to reach the same recommendation without relying primarily on the software.  Further, the sources supporting the recommendation should be identified, easily accessible to and understandable by the intended user, and publicly available.  The guidance explains that a practitioner would be unable to independently evaluate the basis of a recommendation if it were based on non-public information or information whose meaning could not be expected to be independently understood by the user.⁹ As such, in the context of advanced analytics and AI-based software, it’s difficult to predict how FDA might interpret this requirement, especially if the recommendation is being produced by a proprietary machine-learning algorithm.  Considering the above, it’s a certainty that many types of medical software will remain under FDA’s purview, and the agency is actively evaluating what its regulatory approach should be with respect to these products.

A New Regulatory Approach to Software?

In FDA’s Digital Health Innovation Action Plan, issued in July 2017,¹⁰ FDA acknowledges that its traditional approach to hardware-based medical devices is not well suited for the faster iterative design, development, and validation used for software-based medical technologies. The Plan notes that traditional premarket requirements for devices may impede or delay patient access to critical health software, particularly those presenting a lower risk to patients.  Finally, it states that “an efficient, risk-based approach to regulating digital health technology 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, which is how FDA evaluates all other medical devices. Thus, if adopted in some form by the agency, this developer-targeted review would be a departure from FDA’s historic approach. The goals of the program are to:

• enable a modern and tailored approach that allows software iterations and changes to occur in a timely fashion;

• ensure high quality medical software throughout the product’s life by enabling companies to demonstrate their embedded culture of quality and organization excellence; and

• be a program that learns and adapts and can adjust key elements and measure based on the program’s effectiveness.¹³

The program has been underway for a few months, and FDA has been conducting on-site visits with pilot participants, including Apple, Fitbit and Verily.  The participants have provided FDA access to measures they use to develop, test and maintain software products, including ways post-market data are collected.  With this information, FDA hopes to determine the key metrics and performance indicators for precertification and identify ways that precertified companies could either submit less information or, potentially, not have to submit a low-risk product for premarket review at all.¹⁴  While forward thinking and certainly worth pursuing, as of today the legal construct of the program is conceptually amorphous and questions remain about whether a legislative fix may be needed.

On January 30-31, 2018, FDA held a public workshop to discuss how the program has progressed and to solicit public input about how the agency should proceed.¹⁵  During the event, the pilot participants were asked to give their impressions of the program and to describe their experience working with FDA.  The feedback was overwhelmingly positive, with consistent praise of FDA’s willingness to work collaboratively with participants in developing an oversight paradigm built from the ground up to address the unique challenges presented by regulated medical software. 

Along with the workshop, FDA issued a program update that describes what the agency has learned thus far.¹⁶ The document discusses “excellence principles” and common validation principles, which are supposed to provide the underpinnings for the precertification standard.¹⁷  The excellence principles include patient safety, clinical responsibility, product quality, cybersecurity responsibility, and proactive culture.¹⁸  The question FDA now must answer is how it intends to create objective, measurable standards based on these principles.  Regarding this point, the update states that “it was difficult for most of the pilot participants to identify activities related to the excellence principles through the four common validating principles, with many participants preferring to start with their internal organizational structures or major processes.”¹⁹  Due to this observation, FDA has concluded that it needs to modify its model to more closely align with the pilot participants’ orientations.

In terms of measurables, FDA says it intends to use some form of key performance indicators (KPIs) to precertify an organization and monitor precertification status.  However, permitting companies to maintain the approaches that are working for them will necessitate a “library of KPIs that could be used to measure and monitor the existence of a culture of quality and organizational excellence.”²⁰  Not only that, but “not all characteristics of excellent companies are directly and objectively observable.”²¹ In particular, internal KPIs, such as those related to culture and process validity, are difficult to define.  These observations reveal the inherent tension in a program intended to provide an objective, measurable standard for precertification while at the same time allowing each company to use its existing processes. 

One other important point discussed by FDA at the workshop is the need for the program to preserve the existing standards for safety and effectiveness.  Putting aside the fact that such standards are required to be met per the FDCA, the concept of precertification does raise questions about whether “reasonable assurance of safety and effectiveness,” as that phrase is defined and understood,²² can be applied to a medical device through the assessment of a company.  If it can, and the existing review standards can be met through precertification, what then are the implications for other regulated product types?  As of now, SaMD is regulated under the same statutory scheme as all other devices, and if precertification is implemented it is all but guaranteed that other industries will want equal treatment and access to the program. 

These are critical challenges that will have to be addressed by FDA before precertification is implemented.  At the public workshop, FDA acknowledged that there is still a long way to go in the development process and that it doesn’t yet have answers to all of these questions.  To that end, FDA has expressed a real desire to engage the public on these issues and a willingness to be open-minded and flexible. 

Conclusion

Although many aspects of the Pre-Cert Program have yet to be settled, it is remains clear that the regulation of digital health products will continue to evolve as medical technologies advance and as FDA continues to search for a balanced oversight approach. 

1.  21 U.S.C. § 301 et seq.
2.  Pub. L. No. 94-295, 90 Stat. 539 (1976). 
3.  https://www.fda.gov/downloads/MedicalDevices/.../UCM263366.pdf.
4.  The term “enforcement discretion” means that although FDA has jurisdiction over a product, it does not intend to enforce applicable regulatory requirements.  See Id. at 4.
5.  Pub. L. No: 114-255 (12/13/2016).
6.  Id. at Section 3060.
7.  Id.
8.  https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM587819.pdf.
9.  Id. at 7-8.
10.  https://www.fda.gov/downloads/MedicalDevices/DigitalHealth/UCM568735.pdf.
11.  Id. at 2.
12.  82 Fed. Reg. 35216-8 (July 28, 2017); see also Digital Health Software Precertification (Pre-Cert) Program, at https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm. 
13.  https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm.
14.  The FDA categorizes medical devices into one of three classes – Class I, II, or III – based on their risks and the regulatory controls necessary to provide a reasonable assurance of safety and effectiveness. Class I devices generally pose the lowest risk to the patient and/or user and Class III devices pose the highest risk.  The class to which a device is assigned determines, among other things, the type of premarketing submission/application required for FDA marketing authorization.  See 21 U.S.C. § 360c(a).
15.  https://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm587581.htm.
16.  https://www.fda.gov/downloads/MedicalDevices/NewsEvents/WorkshopsConferences/UCM593860.pdf.
17.  Id. at 2.  The common validation principles include: Organizational Resource Perspective; Customer Perspective; Learning and Growth Perspective; and Process Perspective.
18.  Id.
19.  Id. at 4.
20.  Id.
21.  Id.
22.  See 21 U.S.C. § 360c(a).
23. Ian Pearson is a senior associate at Jones Day.  His practice focuses on FDA regulatory matters, with an emphasis on medical devices, combination products, and the evolving digital health sector. Before joining Jones Day, Mr. Pearson served for more than seven years in FDA’s Office of Chief Counsel. At FDA, he worked across product areas and was a member of the device counseling, combination products, and information disclosure teams. He has significant first-hand experience navigating the Federal Food, Drug, and Cosmetic Act, as well as the Administrative Procedure Act, Freedom of Information Act, Privacy Act, and provisions of the Public Health Service Act applicable to FDA regulatory matters.  He may be reached at [email protected].