FDA's 21st Century Cures Act Guidance Documents Clarify the Landscape for Digital Health Innovation

On December 7, 2017, the US Food and Drug Administration (FDA) announced several digital health policy documents designed to "encourage innovation" and "bring efficiency and modernization" to the agency's regulation of digital health products. The three documents include two draft and one final guidance which address, in part, the important changes made by Section 3060 of the 21st Century Cures Act (Cures Act) to the medical device provisions of the Federal, Food, Drug, and Cosmetic Act (FDCA), which we previously summarized, that expressly excluded from the definition of medical device five distinct categories of software or digital health products. FDA Commissioner Dr. Scott Gottlieb emphasized that these documents collectively "offer additional clarity about where the FDA sees its role in digital health, and importantly, where we don't see a need for FDA involvement."

First, FDA released its long awaited draft guidance on "Clinical and Patient Decision Support Software" (Draft CDS Guidance), which outlines FDA's approach to clinical decision support software (CDS). The draft guidance is intended to "make clear what types of CDS would no longer be defined as a medical device, and thus would not be regulated by" FDA. The draft guidance further provides that FDA will "continue to enforce oversight of software programs that are intended to process or analyze medical images, signals from in vitro diagnostic devices or patterns acquired from a processor like an electrocardiogram that use analytical functionalities to make treatment recommendations, as these remain medical devices under the Cures Act."

Second, FDA issued draft guidance entitled, "Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act" (Section 3060 Guidance), which outlines FDA's interpretation of the types of software that are no longer considered medical devices (e.g., lifestyle or wellness apps). The draft guidance also proposes changes to FDA's previously published guidance documents on General Wellness products and Mobile Medical Applications (MMA), among others, to "be consistent with the Cures Act and reflective of the agency's new, more modern approach to digital health products." In particular, FDA proposed updating the categories of products for which FDA had already intended to exercise enforcement discretion due to their low risk and making "an even clearer distinction, consistent with the Cures Act," that "many of these products no longer qualify as medical devices that would be subject to" FDA oversight. Examples include software with healthy lifestyle claims, such as weight management, physical fitness, relaxation or stress management, mental acuity, self-esteem, sleep management, or sexual function, when not related to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.

Comments on the two draft guidance documents are due to FDA by February 6, 2018.¹

Lastly, FDA finalized its October 2016 draft guidance entitled, "Software as Medical Device: Clinical Evaluation," which establishes common principles for regulators to use in evaluating the safety, effectiveness, and performance of Software as a Medical Device (SaMD). Specifically, the guidance sets forth a three-step clinical evaluation process for ongoing activities conducted in the assessment and analysis of SaMD's clinical safety, effectiveness, and performance as intended by manufacturers in the SaMD's definition statement. The guidance emphasizes that the level of evaluation and independent review should be commensurate with the risk posed, and encourages manufacturers to use continuous monitoring to understand and modify software based on real-world performance.

These documents emerged shortly after FDA released its Digital Health Innovation Action Plan this past summer, which outlines the agency's efforts to "reimagine the FDA's approach to ensuring all Americans have timely access to high-quality, safe and effective digital health products." As part of this plan, FDA launched the digital health precertification pilot program (Pre-Cert), and selected nine companies to participate. FDA is hosting a Pre-Cert Pilot Program workshop on January 30-31, 2018 to discuss lessons learned from the pilot. FDA also has recently hired additional employees for its digital health team, and announced the Entrepreneurs in Residence Program.

Collectively, these policies and initiatives demonstrate a concerted effort by FDA to enhance and expand the agency's efforts to "encourage innovation in the ever-changing field of digital health" by providing "more clarity on and innovative changes to [FDA's] risk-based approach to digital health products." FDA maintained that its interpretation of the Cures Act creates "a bright line to define those areas where we do not require premarket review" and more detail on technologies and applications that are not medical devices. Taken together, FDA's draft guidance documents will help provide more certainty in integrating digital health solutions into manufacturers marketing strategies without necessarily triggering FDA regulation of the product as a medical device.

Part I of this advisory discusses FDA's guidance on clinical and patient decision support software; Part II discusses changes to the existing medical software policies resulting from Section 3060 of the Cures Act; and Part III discusses FDA's guidance regarding its regulation of clinical evaluation software as a medical device.

I. Clinical and Patient Decision Support Software

Industry has long waited for guidance from FDA on the agency's approach to the regulation of clinical decision support software. In recent years, FDA's has generally taken a risk-based approach to the regulation of CDS software whereby the agency would focus its oversight on a limited set of CDS functionalities that pose higher risk to patients. For years, the agency had indicated that specific guidance on the regulation of CDS software would be forthcoming. In December of 2016, Congress, through enactment of the Cures Act, added new section 520(o) to the FDCA amending the FDCA definition of "device" to expressly exclude certain software functions from the definition of device, including specifically certain CDS software functions (§520(o)(1)(E)). FDA's Draft CDS Guidance not only provides clarity on the types of CDS functions intended for use by healthcare professionals (HCPs) that the agency views as falling within the §520(o)(1)(E) exemptions, but also builds on those exemptions to describe CDS software functionalities intended for use by patients or their caregivers (PDS) that although not exempt from the definition of a device under §520(o)(1)(E), would be subject to FDA enforcement discretion.

With respect to the agency's interpretation of the §520(o)(1)(E) exemption for CDS software, FDA first clarifies that to be excluded from the definition of a device, the software function must meet all four of the following statutory criteria:

(1) Not 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;

(2) Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

(3) Intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and

(4) Intended for the purpose of 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.

The agency then provides clarifications on how it interprets each of the criterion. As relates to the independent review criteria, the agency states that it interprets the §520(o)(1)(E) exemption to describe software functions that clearly explain: (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. The agency further explains that in order for the software function to be excluded from the definition of device, the intended user should be able to reach the same recommendation on his or her own without relying primarily on the software function. The agency recommends that sources supporting the recommendation or underlying the rationale for the recommendation be identified and easily accessible to the intended user, understandable by the intended user, and publicly available.

FDA provides several examples of CDS functions that are not devices because they meet all four of the §520(o)(1)(E) criteria, including the following:

• Software that provides HCPs with recommendations on the use of a prescription drug that are consistent with the FDA-required labeling. FDA states that information relied upon by the software should be kept up-to-date and recommends that the source of the information (e.g., FDA approved labeling) be prominently displayed.
• Software that uses rule-based tools that compare patient-specific signs, symptoms, or results with available practice guidelines (institutions-based or academic/clinical society-based) to recommend condition specific diagnostic tests, investigations or therapy, and provide options to users to obtain up-to-date information.
• Software intended for use by HCPs to aid in diagnosing patients suspected to have diabetes mellitus. The HCP enters patient parameters and laboratory test results (i.e., fasting plasma glucose, oral glucose tolerance test results, and/or hemoglobin A1c test results), and the device suggests whether the patient's condition meets the definition of diabetes based on established guidelines.
• Software that makes chemotherapeutic suggestions to a HCP based on patient history, test results, and patient characteristics, including, for example, software suggesting a platinum-based chemotherapy for BRCA-positive individuals that is consistent with the drug labeling.

FDA also provides examples of CDS and other software functions that remain devices and for which the agency intends to focus its regulatory oversight, including the following:

• Software that manipulates or analyzes images and other data obtained from a radiological device (e.g., CT, bone density, and distance) to create 3D models of the region intended to be used in planning orthopedic/dental surgical treatments with a device.
• Software that analyzes multiple physiological signals (e.g., sweat, heart rate, eye movement, breathing–from FDA-regulated devices) to monitor whether a person is having a heart attack or narcolepsy episode.
• Software that analyzes breathing patterns from a sleep apnea monitor to diagnose sleep apnea or other conditions in patients.
• Software that analyzes CT images to compute and/or approximate fractional flow reserve. In this case the software performs and provides the user an image analysis that the user could not independently derive.
• Software that analyzes a patient's laboratory results using a proprietary algorithm to recommend a specific radiation treatment, for which the basis of the recommendation is unavailable for the HCP to review.
• Software intended for HCPs that uses an algorithm undisclosed to the user to analyze patient information (including noninvasive blood pressure (NIBP) monitoring systems) to determine which anti-hypertensive drug class is likely to be most effective in lowering the patient's blood pressure.

Several of the above and other examples described in the draft guidance highlight the agency's focus on the following two factors in determining whether to regulate a CDS software function as a device: (1) the transparency of the algorithm used by the software; and (2) whether the HCP would rely primarily on the output from the software in making a clinical decision. This focus is similar to the approach the agency has adopted for regulation of mobile medical applications that perform medical calculations, with the agency exercising enforcement discretion for mobile medical applications that perform simple medical calculations that are routinely used in clinical practice and found in medical sources. Relatedly, FDA in the Draft CDS Guidance notes that there are software products intended to support HCPs that are not affected by the Cures Act exemption, including software that performs calculations routinely used in clinical practice, for which FDA will maintain its existing policy of not intending to enforce compliance with applicable regulatory requirements.

The draft guidance also distinguishes clinical decision support software intended for HCPs (CDS) from clinical decision support software intended for patients or caregivers who are not HCPs (PDS). While noting that the §520(o)(1)(E) exemption does not apply to PDS, FDA states that it intends to adopt an enforcement discretion policy for PDS that generally parallels the CDS for HCPs excluded from the definition of a device under §520(o)(1)(E). FDA sets forth four factors that a PDS must meet to be subject to enforcement discretion. The factors largely parallel those for CDS described above, including that the PDS enable the patient to independently review the basis for the recommendation so that it is not the intent that the patient rely primarily on the software's recommendations to make a decision. The draft guidance highlights that the kinds of explanations for a HCP are different than the kinds of explanations that a patient may be able to understand and apply, given the differences in clinical education and experience, and provides as an example of a PDS that would be subject to regulatory oversight software that makes recommendations for warfarin dosing adjustments based on the outcome of a home blood test and published algorithms, without the patient seeking consultation with their HCP.

II. Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act

Section 3060(a) of the Cures Act, enacted by Congress in December 2016, amended the FDCA definition of "device" (Section 201(h)) to provide greater clarity and instruction to FDA about its regulatory approach and framework for digital health. Specifically, Congress excluded the following software functions from the definition of device:²

1. For administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow;
2. For maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;
3. To serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart, so long as: (i) such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals; (ii) such records are part of health information technology that is certified under section 3001(c)(5) of the PHSA; and (iii) such function is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition; and
4. For transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings

FDA stated that Section 3060 created a "function-specific definition," and as such, the functions excluded from the device definition are "independent of the platform on which they might run." As a result, FDA stated that it would update other relevant digital health guidance documents to clarify, where appropriate, that FDA's policies are "function-specific and apply across platforms." For example, FDA said it would change instances of "mobile application" in the MMA guidance to "software function."

FDA further explained that when the Section 3060 Guidance is final, the content of the guidance will be incorporated through Level 2 updates to the following guidance documents: (1) General Wellness: Policy for Low Risk Devices, (July 29, 2016); (2) Mobile Medical Applications (February 9, 2015); (3) Off-The-Shelf Software Use in Medical Devices (September 9, 1999); and (4) Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (February 9, 2015).

A. Software Functions Intended for Administrative Support of a Health Care Facility

FDA clarified that the agency "has not historically considered most" administrative support software used at a health care facility "to be devices." The agency clarified, however, that it was removing Section 3.2.2 of the Guidance for Off-the-Shelf Software Use in Medical Devices, titled "Exemption of Laboratory Information Management Systems" because Laboratory Information Management Systems (LIMS) are not within the definition of the term device as amended by the Cures Act.

B. Software Function Intended for Maintaining or Encouraging a Healthy Lifestyle

FDA explained that it considers a product with an intended use for maintaining or encouraging a "healthy lifestyle" to mean "a product with an intended use that encourages or maintains a 'general state of health or healthy activity,' as defined in the FDA guidance General Wellness: Policy for Low Risk Devices (General Wellness Guidance)," which we previously summarized here.

In that guidance CDRH defines a general wellness product as products that: (1) are intended for only general wellness use; and (2) present a low risk to the safety of users and other persons. That guidance defines two categories of general wellness intended uses: (1) an intended use that relates to maintaining or encouraging a general state of health or a healthy activity, or (2) an intended use that relates the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition.

FDA clarified in the Section 3060 Guidance that if the intended use of the software function is related to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition, then the product is not excluded from the definition of the term "device." Since the second category of permitted general wellness product intended uses "relates to the mitigation or prevention of a disease or condition," FDA clarified that such "products are not excluded from the definition of device as modified by" Section 3060, but FDA will continue "to not enforce the applicable requirements for this type of general wellness software function where it presents a low risk to the safety of users and other persons." This includes premarket review and post-market regulatory requirements, including but not limited to registration and listing and premarket notification requirements (21 CFR Part 807); labeling requirements (21 CFR Part 801 and 21 CFR 809.10); good manufacturing practice requirements as set forth in the Quality System regulation (21 CFR Part 820); and Medical Device Reporting (MDR) requirements (21 CFR Part 803).

Conversely, FDA explained that software functions with healthy lifestyle claims (first category in the General Wellness Guidance) are "not a device as long as its claims are unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition." For example, FDA said that software with healthy lifestyle claims, "such as weight management, physical fitness, relaxation or stress management, mental acuity, self-esteem, sleep management, or sexual function, are not devices when not related to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition." The Section 3060 Guidance further notes that examples 1-3 in Section V. of the General Wellness Guidance are not devices.³

Additionally, FDA will move a number of examples from Appendix B of the MMA Guidance (examples of mobile apps for which FDA intends to exercise enforcement discretion) to Appendix A (Examples of mobile apps that are NOT medical devices) because they no longer meet the definition of the term "device."⁴ These include mobile apps that are "intended for individuals to log, record, track, evaluate, or make decisions or behavioral suggestions related to developing or maintaining general fitness, health or wellness."

C. Software Function Intended to Serve as Electronic Patient Records

The Section 3060 Guidance reiterates that software functions intended to transfer, store, convert formats, or display electronic patient records that are the equivalent of paper medical charts are not devices if the three statutory requirements of Section 3060 are all met (e.g., created by HCPs, part of information technology certified by the Office of the National Coordinator for HIT (ONC), and not intended for interpretation or analysis of patient records for diagnosis, cure, mitigation, etc.). FDA clarified, however, that it does "not intended to enforce FDA requirements for software functions that are not certified by ONC, if they meet the other [two] criteria."

FDA explained that software functions that enable patients or non-HCPs to create, store, or transfer health records for their own record-keeping purposes that are not intended to be created, stored, transferred or reviewed by a HCP are considered personal health records (PHRs). The Section 3060 Guidance clarifies that the software functions in PHR systems that are not intended for use in the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition are not devices regulated by FDA.

The agency further explained that this category of excluded software functions may be contained in electronic health record (EHR) systems, PHR systems, and other health information technology. Such systems may also contain other software functions that could meet the definition of device. As a result, FDA noted that its approach to software functions that meet the definition of a device in a system "with software functions that do not meet the definition of device (products with multiple functions) will be addressed in a separate guidance document."

Similar to general wellness products, FDA clarified that it will move certain examples in Section V.B. and Appendix B of the MMA Guidance (Mobile Apps for which FDA intends to exercise enforcement discretion) to Appendix A (Examples of mobile apps that are NOT medical devices) because such examples are not devices. This includes mobile apps that: (1) enable individuals to interact with ONC-certified EHR systems, which are generally meant to facilitate general patient health information management and health record-keeping activities; and (2) during an encounter, an HCP to access their patient's PHR that is hosted on a web-based or other platform; and (3) help track or manage patient immunizations. FDA explained that the latter two examples must be products that are ONC-certified.

D. Software Function Intended for Transferring, Storing, Converting Formats, Displaying Data and Results

FDA clarified that under this exclusion, software functions that meet the definitions of Medical Device Data Systems (MDDS), medical image storage devices or medical image communications devices are no longer devices subject to FDA oversight. As such, products that are "solely intended to transfer, store, convert formats, and display medical device data and results, including medical images, waveforms, signals, or other clinical information are not devices and thus are not subject to FDA regulatory requirements." However, FDA reminded industry that "software functions that analyze or interpret medical device data in addition to transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results remain subject to FDA's regulatory oversight."

The Section 3060 Guidance provides, however, that this exclusion "does not capture software functions intended to generate alarms or alerts or prioritize multi-patient displays, because these functions involve analysis or interpretation of laboratory test or other device data and results." For example, FDA explained that if a "software function is intended to prioritize patients in an Intensive Care Unit based on their clinical status, then this function is intended to interpret or analyze device data, results, and findings and is, therefore, not excluded from the definition of device." FDA also stated that a software function that analyzes medical device data in order to "provide a notification or flag (e.g., that a parameter is out of range) are not excluded from the definition of device."

However, FDA said that it "does not intend to enforce" medical device requirements "for these low risk software functions" when "the analysis of data to provide a notification" does not require "immediate clinical action." Instead, FDA said that it would focus its regulatory oversight on software functions "intended to generate alarms or alerts or prioritize multi-patient displays if they are intended to alert a caregiver to take an immediate clinical action. Accordingly, FDA will revise the MDDS Guidance to clarify that such products are not devices and not subject to FDA regulatory requirements, "whether or not the use is for immediate clinical action." FDA will also revise the discussion and examples of devices in the MDDS Guidance to reflect this change.

Additionally, FDA will revise various examples from the MMA Guidance to correspond to this exclusion (e.g., clarifying that software that displays medical images directly from a Picture Archiving and Communication System (PACS) server and remote display of data from beside monitors is now subject to enforcement discretion, unless designed to generate alarms/alerts for immediate clinical action).⁵FDA will also move various examples from Appendix B in the MMA Guidance (enforcement discretion) to Appendix A (not medical devices).⁶ FDA will add the following example to Appendix B of the MMA Guidance (examples of mobile apps subject to enforcement discretion):

Software tools that analyze stored clinical information to flag patient results based on specific clinical parameters (e.g., out of range results, potential drug interactions, opportunities for complementary tests, create disease registries, summarize patient- specific information in an integrated report, and/or track a patient's treatment or disease outcome) provided that the analysis performed by these software is not intended for immediate clinical action and does not represent a unique interpretation function but rather summarizes standard interpretation of individual variables that healthcare practitioners could do themselves.

Lastly, FDA clarified that it is withdrawing the document entitled, "Guidance for the Submission of Premarket Notifications for Medical Image Management Devices" (July 27, 2000) because "some software functions described in that guidance no longer meet the definition of a device, as amended." FDA stated that for the "limited subset of Medical Image Management Devices that continue to meet the definition of a device and continue to require a 510(k) submission, the information provided in that document … is out of date," and encouraged manufacturers "to reference the most recent FDA-recognized versions of relevant voluntary consensus standards instead."

III. Software as a Medical Device: Clinical Evaluation

Software as a Medical Device (SaMD) is one of three types of software FDA recognizes as related to medical devices. FDA has adopted the International Medical Device Regulators Forum (IMDRF) definition of SaMD: "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." SaMD ranges from software that allows a smartphone to view images obtained from MRI medical device for diagnostic purposes to software that is intended for diagnosis of a condition using the tri-axial accelerometer that operates on the embedded processor on a consumer digital camera. However, software that merely relies on data from a medical device, but does not have a medical purpose, or software that monitors performance or proper functioning of a device for the purpose of servicing the device, for example, do not meet the definition of SaMD.

FDA has worked with IMDRF to harmonize global foundational principles that effectively evaluate the intended use and risks of SaMD. In 2013, IMDRF formed the SaMD Working Group, which is chaired by FDA. This working group has thus far agreed upon the key definitions for SaMD, framework for risk categorization for SaMD, the Quality Management System for SaMD, and most recently the clinical evaluation of SaMD. In FDA's October 2016 draft SaMD guidance, the agency adopted the IMDRF's initial recommendations on how developers should demonstrate safety, effectiveness, and performance of software that impacts the clinical management of patients.⁷

The final SaMD Guidance "provides harmonized principles for individual jurisdictions to adopt based on their own regulatory framework" and "does not exhaustively address all regulatory requirements relevant to SaMD, which may vary by jurisdiction." The final guidance also states that the document incorporates and builds on three conceptual documents published by IMDRF's SaMD Working Group: (1) SaMD N10 Software as a Medical Device (SaMD): Key Definitions to create a standard terminology for SaMD; (2) SaMD N12 Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations which proposes a method for categorizing SaMD based on the seriousness of the condition the SaMD is intended to address; and (3) SaMD N23 Software as a Medical Device (SaMD): Application of Quality Management System, outlining how manufacturers should follow Quality Management System (QMS) Principles for medical devices as well as good software engineering practices.

The primary focus of the final guidance is a three-part clinical evaluation process for SaMDs consisting valid clinical association, analytical validation, clinical validation. For each step, FDA cites to relevant IMDRF conceptual documents that address these the concept in more detail. FDA also diagrammatically depicts where the SaMD clinical evaluation process fits in relation to other SaMD lifecycle processes.

The final guidance goes on to explain how to generate appropriate evidence, provide links to techniques, definitions, and sources that may help a developer generate the evidence, and walk through examples for each step of the three-part clinical evaluation process. For valid clinical association, FDA/IMDRF recommends that developers first verify that the association between the SaMD output and the targeted clinical condition is supported by either generating new evidence, such as secondary data analysis, or using existing evidence, such as original clinical research. For analytical validation, FDA/IMDRF recommends that developers generate evidence that shows that the output of the SaMD is technically what the developer expected. This can be demonstrated through verification and validation activities as part of the developer's QMS, for example, or by generating new evidence through use of curated databases or use of previously collected patient data. For clinical validation, FDA/IMDRF recommends that developers generate evidence that shows the SaMD has been tested in the target population for the intended use and that users can achieve clinically meaningful outcomes through predictable and reliable use. Similar to the analytical validation step, evidence to validate clinical significance can occur during verification and validation activities as part of the developer's QMS, for example. Examples of measures of clinical validation include, but are not limited to sensitivity, specificity, odds ratio, and confidence interval.

FDA/IMDRF acknowledges that the degree of evidence generation needed for a given SaMD will depend on maturity of evidence underlying the clinical association and confidence in the evidence, among other parameters. However, as with all medical devices, the purpose of evidence assessment is to select information that demonstrates that the evidence is "high-quality, relevant, and supporting of the SaMD intended use." If the developer cannot generate the requisite quality of evidence, FDA/IMDRF suggests that the developer perform ongoing data analysis, modify the intended use to one that can be supported by available evidence, modify the target clinical association, and/or make changes to the software.

In addition, the final guidance reiterates two concepts that were presented in the draft guidance in the context of SaMD clinical evaluation: the importance of independent review and the value of collecting real world performance data. For independent review, FDA/IMDRF takes the same position as it did in the draft guidance when describing the risk-based approach and states that the higher the risk level and category of the SaMD, the higher the importance of independent review of the evidence. Moreover, real world performance data may be particularly useful in understanding user interactions with the SaMD, and conducting ongoing monitoring of analytical and technical performance to support future intended uses. FDA/IMDRF mentions that risk categorization and thereby the SamD definition statement could change based on real world data, but such data may not be sufficient to generate complete clinical evidence necessary for a change to the SaMD definition statement.

Conclusions

The FDA guidance documents described in this Advisory represent a remarkable evolution by FDA and Congress in the area of digital health. In the space of a few years, the policy framework for health-related software has gone from a period of uncertainty and potentially crippling regulation to a reasonable and risk-based approach that carves out significant areas for innovation. While some uncertainty remains with respect to certain technologies, Congress has rightly focused FDA on those areas of risk–such as devices that manipulate medical device data or utilize non-transparent algorithms or artificial intelligence–while allowing broad areas of digital health solutions to flourish. Hopefully FDA will be equally reasonable in the burdens it places on regulated categories of digital health solutions. Companies throughout the life sciences and healthcare industries should carefully consider the opportunities presented by these important policy shifts.

© 2017 Arnold & Porter Kaye Scholer LLP. This Advisory is intended to be a general summary of the law and does not constitute legal advice. You should consult with counsel to determine applicable legal requirements in a specific fact situation.