The capabilities and sophistication of digital health technologies are constantly expanding, especially with the integration of artificial intelligence and machine learning. Many companies, both existing and start-up, are developing software aimed at health care systems, hospitals, physicians, and lay-users for various levels of use, from assisting diagnoses in a clinical environment to tracking exercise and general health indicators in the home. In particular, a growing number of companies are focusing on the development of digital therapeutics - a class of software devices that deliver and monitor medical interventions for the purpose of treating, managing, or preventing certain diseases or conditions - for use in a patient’s home.
With all of the new players jumping into the digital health technology game, we thought it might be useful to provide a brief primer on certain factors to consider when evaluating the potential regulatory requirements for such products. Of course, many companies in this space already realize that if the product is definitely a medical device, one must determine the device classification on the risk-based scale (class I, II, or III) administered by the Food and Drug Administration (FDA) and the type of pre-market submission pathway (510(k), De Novo, or Pre-Market Approval), if any, to pursue as a result. However, this blog post concerns other relevant considerations that affect the regulatory status of a digital health product and the type of information to include in a pre-market submission to FDA and accordingly, we won’t delve into medical device classifications further.
First: Is the Software a Device?
At the outset, we encounter the most critical question in developing a digital health product: “Is the product a medical device?” The answer to this question will determine whether the product is regulated under the Federal Food, Drug, and Cosmetic Act (the “FD&C Act”) and FDA’s device regulations. In particular, requirements relating to registration, listing, adverse event reporting, and quality systems apply to all devices regardless of their risk classification and can be burdensome for smaller companies to meet.
Under the FD&C Act, “device” means:
“an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is—
(A) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them,
(B) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
(C) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.”
(FD&C Act Section 201(h), 21 U.S.C. § 321(h))
The definition above would encompass each digital health product intended for a medical or clinical use, but critically the FD&C Act also excludes the following software types from the “device” definition:
- administrative support software for a health care facility;
- software for maintaining or encouraging a healthy lifestyle, unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;
- certain electronic patient records software;
- software for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, and related information, unless such function interprets or analyzes such data, results, or information;
- clinical decision support software intended to (i) display, analyze, or print medical information about a patient or other medical information, (ii) support or provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition, (iii) enable the health care professional to independently review the basis for the software’s recommendations; however, the software cannot itself acquire, process, or analyze a medical image, pattern, or signal from another medical device.
(See FD&C Act Section 520(o), 21 U.S.C. § 360j(o))
Based on these statutory excerpts alone, we see that a number of software functions are not considered medical devices, and in particular, Congress has excluded general health and wellness software from the device definition. If your software falls into any of the five categories above, it is not regulated by FDA as a medical device. One should always make sure to check the actual wording of the law, as well as the relevant guidance documents (e.g., General Wellness: Policy for Low Risk Devices and Clinical Decision Support Software), during a regulatory analysis of a new software product to confirm that conclusion.
Second: Is the Software Intended for General Wellness?
This question is technically a subset of the first question above, but considering the ubiquity of software functions intended for general wellness uses, it deserves specific attention. Digital health products that are only for general wellness uses and that present no or minimal safety risks are either not medical devices or, if they are, FDA does not intend to enforce compliance with applicable regulatory requirements (i.e., the agency will exercise what it calls “enforcement discretion”). The agency’s General Wellness: Policy for Low Risk Devices guidance describes two types of general wellness products: (i) those intended for use to maintain or encourage a general state of health or healthy activity unrelated to any specific disease or condition, and (ii) those intended for uses of promoting, tracking, or encouraging healthy choices to help reduce the risk of or living well with certain chronic diseases or conditions.
It is not always straightforward to tailor software functions and claims to align with the expectations outlined in FDA’s General Wellness guidance. Any determination that a digital health product is intended for general wellness uses only should be accompanied by a documented rationale based on the applicable laws, regulations, and guidance.
Keep in mind that a digital health product may have several different functions and each one must be separately evaluated. Although one function may meet the general wellness product requirements, others may be considered medical devices subject to pre-market clearance or approval requirements (see Policy for Device Software Functions and Mobile Medical Applications and Multiple Function Device Products: Policy and Considerations).
Third: Is the Software Function Under Enforcement Discretion?
As explained above, FDA has decided to exercise enforcement discretion for certain low-risk products. The agency applies this concept directly to digital health products in its Policy for Device Software Functions and Mobile Medical Applications (see Section V.B and Appendix B). In general, FDA’s policy of enforcement discretion applies to software intended to
- help patients self-manage diseases or conditions without delivering specific treatment or recommending possible treatments; or
- automate simple tasks for health care professionals.
The Device Software Functions guidance linked above provides many helpful examples of device software functions subject to enforcement discretion in Appendix B (see also Examples of Software Functions for Which the FDA Will Exercise Enforcement Discretion).
As recommended above with respect to general wellness products, a company developing software functions with the goal of being under enforcement discretion should document a well-reasoned rationale for why the software functions meet the relevant criteria in FDA’s Device Software Functions guidance. Any software function under enforcement discretion likely meets the “device” definition provided for in the FD&C Act, so the agency may decide at any time to reverse its enforcement discretion policy for any software function, or even for an individual company’s software product, especially if new safety concerns arise. Documenting relevant software function analyses in detail provides support for the company’s determination that the function is under enforcement discretion in case of FDA inquiry and makes it easier and more efficient for the company to respond and react to any future changes to the software function’s regulatory status.
Remember to evaluate each software function separately to determine whether enforcement discretion may apply. If any device software function in your digital health product is not eligible for enforcement discretion, it may be subject to pre-market clearance or approval requirements.
Fourth: Is the Software for Prescription or Over-the Counter (OTC) Use?
Once you have determined your digital health product is a device and decided that it is not subject to enforcement discretion and must be approved or cleared by FDA, the next biggest question is whether you want the software to be restricted to prescription by a licensed physician or directly available for consumer download and use. Whether a software device is prescription or OTC significantly affects the type and extent of information your company will submit in its eventual application for FDA clearance or approval, including performance testing and human studies.
When a device is restricted to prescription use, which includes devices that must be used by a licensed health care professional (e.g., surgical or radiographic imaging equipment), FDA relies in part on physicians’ professional judgment as a significant control factor for certain potential risks associated with the device. By contrast, an OTC device is distributed directly to consumers without physician involvement, and the consumer must be able to self-select and use the device based solely on the included instructions for use. Therefore, FDA expects an applicant to provide substantial evidence that an average, layperson consumer can reliably self-select and use the device safely based on the device’s design and labeling. In most cases, FDA requires applications for OTC devices to include data from a human factors study that tests label comprehension, self-selection performance, and whether the device design leads to consistent safe and effective use (see Applying Human Factors and Usability Engineering to Medical Devices and Content of Human Factors Information in Medical Device Marketing Submissions (draft guidance)).
The upshot is that obtaining FDA clearance or approval for an OTC device is often more difficult and takes more time and effort than for a prescription-use-only device.
Fifth: Is the Software for Use in a Clinical or Home Environment?
Another important factor to consider before progressing too far into the design and development phase is the use environment for the device, i.e., whether it is intended to be used in a medical institution/practice or in a user’s home. Any pre-market submission to FDA must specify the use environment for the device because it is closely tied to the device’s overall intended use. As with prescription-use-only devices described above, a clinical use environment provides some degree of assurance to FDA because the device is being used by or under the supervision of a health care professional so if any harm to the patient occurs, medical care is readily available. An application for a home-use device, on the other hand, requires substantial evidence, including human factors studies, demonstrating that the device design and labeling are sufficient to allow a consumer to use the device at home safely and effectively with minimal risk (see Design Considerations for Devices Intended for Home Use).
It is important to note that not all medical devices intended for home use are cleared or approved by the agency as “OTC.” Many home-use devices that provide essential treatment or diagnostic functions must be prescribed by a physician before patients may acquire and use them (e.g., many orthopedic devices, CPAP machines, or ambulatory infusion pumps).
As with OTC devices, obtaining clearance or approval for an at-home intended use for a digital health device is often more difficult and time-consuming than for a device intended for use in a clinical environment given the additional data that must be developed and submitted to support the device’s safety and effectiveness.
Conclusion
Bringing a digital health product to market is a complex process, and basic decisions about how the product will be used will have a substantial effect on whether the product is regulated by FDA and the level of information necessary to support an application for clearance or approval. This primer provides a brief introduction to some of the critical decision points that may ultimately impact the type and amount of testing data and other information a digital health product developer will have to gather and, if necessary, submit to the agency before commercialization.
[View source.]
