Is Digital Health Software Subject to FDA Regulation?
Friday, February 18th, 2022If you work in the software industry, you may be surprised to discover that digital health software products may be subject to regulation by the Food and Drug Administration (“FDA”). Some software is considered a software as a medical device (“SaMD”) product or software in a medical device (“SiMD”) product.
So, how do you know whether or not a digital health product you are building is going to be considered a SaMD or SiMD product?
The FDA issued a “Policy for Low Risk Devices” on September 27, 2019, which provides general nonbinding recommendations to clarify its policy on health software that has been deemed not to be a device under Section 201(h) of the FD&C Act. In this policy, the FDA specifically stated that software intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease of condition” does not constitute a “device” under section 201(h) of the FD & C Act. According to the FDA policy, general wellness products will not be examined to determine if they are devices and comply with the regulatory requirements for devices. The FDA further defines general wellness products to include products meeting the following requirements: (1) they are intended for only general wellness use as defined in the guidance and (2) they present a low risk to the safety of users and other persons.
In the Policy for Low Risk Devices, the FDA states that a “general wellness product” has the following:
(1) an intended use that relates to maintaining or encouraging a general state of health or healthy activity, or
(2) an intended use that related 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.
The FDA then provides examples of the specific types of uses that would fall under each category.
The FDA also states the test for assessing the degree of risk for general wellness products:
(1) Is the product invasive?
(2) Is the product implanted?
(3) Does the product involve an intervention or technology that may pose a risk to the safety of users and other persons if specific regulatory controls are not applied, such as risks from lasers or radiation exposure?
If all of the above answers are “no,” then the product is deemed to be low risk and not subject to FDA regulation.
The FDA also issued a “Policy for Device Software Functions and Mobile Medical Applications” on September 27, 2019, which provided nonbinding recommendations for regulation software applications intended for use on mobile platforms or on general purposes computing platforms.
In the “Policy for Device Software Functions and Mobile Medical Applications” the FDA clarified that it intended to focus its regulatory oversight to “only those software functions that are medical devices and whose functionality could pose a risk to a patient’s safety if the device were to not function as intended.” The FDA listed three categories of software functions that would be subject to this regulatory oversight focus:
(1) Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.
(2) Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors, or by including functionalities similar to those of currently regulated medical devices.
(3) Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations.
The FDA also clarified that it intended to exercise enforcement discretion for software functions that “help patients. . . . self-manage their disease or conditions without providing specific treatment or treatment suggestions” or “automate simple tasks for health care providers.” The FDA listed four categories of software functions that would be subject to this regulatory enforcement discretion:
(1) Software functions that provide or facilitate supplemental clinical care, by coaching or prompting, to help patients manage their health in their daily environment.
(2) Software functions that provide easy access to information related to patient’s health conditions or treatments.
(3) Software functions that are specifically marketed to help patients communicate with healthcare providers by supplementing or augmenting the data or information by capturing an image for patients to convey to their healthcare providers about potential medical conditions.
(4) Software functions that perform simple calculations routinely used in clinical practice.
The FDA also provided a list of categories of software functions that are not medical devices:
(1) Software functions that are intended to provide access to electronic “copies” of medical textbooks or other reference books with generic text search capabilities.
(2) Software functions that are intended for health care providers to use as educational tools for medical training or to reinforce training previously received.
(3) Software functions that are intended for general patient education and facilitate patient access to commonly used reference information.
(4) Software functions that automate general office operations in a health care setting and are not intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease.
(5) Software functions that are generic aids or general-purpose products.
(6) Software functions that are intended for individuals to log, record, track, evaluate, or make decisions or behaviorial suggestions related to developing or maintaining general fitness, health, or wellness.
(7) Software functions that enable individuals to interact with EHR software certified under the ONC Health IT Certification Program.
(8) Software functions that provide patients with simple tools to organize and track their health information.
(9) Software functions that provide easy access to information related to patients’ health conditions or treatments.
(10) Software functions that provide patients with simple tools to organize and record their health information.
(11) Software functions that are specifically marketed to help patients document, show, or communicate to providers regarding potential medical conditions.
(12) Software functions that enable, during an encounter, a health care provider to access their patient’s personal health record (health information) that is hosted on a web-based or other platform.
(13) Software functions for health care providers certified under the ONC Health IT Certification Program, such as those that help track or manage patient immunizations by documenting the need for immunization, consent form, and immunization lot number;
(14) Software functions that help asthmatics record (i.e. collect and log) inhaler usage, asthma episodes experienced, location of user at the time of an attack, or environmental triggers of asthma attacks;
(15) Software functions certified under the ONC Health IT Certification Program that prompt the health care provider to manually enter symptomatic, behavioral, or environmental information, the specifics of which are pre-defined by a health care provider, and store the information for later review;
(16) Software functions that record the clinical conversation a clinician has with a patient and sends it (or a link) to the patient to access after the visit;
(17) Software functions that allow a user to record (i.e. collect and log) data, such as blood glucose, blood pressure, heart rate, weight, or other data from a device to eventually share with a health care provider, or upload it into an online (cloud) database, or personal or electronic health record (PHR or EHR, respectively) that is certified under the ONC Health IT Certification Program;
(18) Software functions that enable patients or health care providers to interact with PHR systems or EHR systems that are certified under the ONC Health IT Certification Program;
(19) Software functions that meed the definition of Non-Device-MDDS, which are functions solely intended to transfer, store, convert formats, and display medical device data or results, without controlling or altering the functions or parameters of any connected medical device.
(20) Software functions that display patient-specific medical device data.
(21) Software functions that are intended 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 that data, results, and findings.
The policies provide much more detail about the scope of the regulatory authority to be exercised over software than what can be captured in a blogpost, but this overview at least summarizes the key points of the guidance.
If you are developing a digital health software product, you will want to carefully consider how the FDA will classify your product, and you will likely want to consult with an attorney who focuses in this niche. FDA legal practice is a narrow practice niche which includes a small circle of attorney practitioners, so it may be challenging to find a lawyer who practices in this specialty area outside of Washington, D.C. It is possible that a medical device patent attorney in your area may have this expertise or may be able to make a good referral for you, so that is a possibility you may want to explore.
