Nikki Batista, Director, Digital Health Regulatory Affairs, MCRA LLC05.17.21
Whether you’re a startup or a well-established manufacturer, it can be challenging to determine if the software you’re developing needs FDA oversight. Such a determination must be made correctly the first time. This column will address key questions to consider when defining the pathway to market for digital health technology.
To successfully navigate the U.S. digital health regulatory system, companies should understand the reasons for determining whether their technology is regulated. The main reason is risk mitigation for both customers and the business itself. Companies that develop and deploy products without first considering the regulatory framework risk violating federal law and repercussions from the FDA. Less serious, but suboptimal is determining a technology is subject to regulatory oversight during development and then scrambling to establish the proper processes and procedures in order to meet design control and quality system requirements. Reduce risk with proper diligence—identify the regulations with which you must comply. Institute the appropriate company policies. Know what the pathway to market will entail. This diligence will enable you to allocate the necessary time and resources to market a product faster and with fewer unexpected hurdles.
Key Question: Does the technology meet the statutory definition of a medical device?
Per 201(h) of the FD&C Act, a device is: “An instrument, apparatus, implement, machine, contrivance, implant, in-vitro reagent, or other similar or related article, including a component part, or accessory which is:
The driving force behind this regulatory spectrum is the 21st Century Cures Act, which amended a section of the FD&C Act and removed certain software functions from the definition of a medical device. These software functions include:
Key Question: What software function policies are potentially applicable to a technology that could down classify it?
Most FDA policies are fairly straightforward except for clinical decision support (CDS), which has important nuances that can tip the balance in either the regulated or non-regulated sides of the regulatory spectrum. This policy leverages the risk classification paradigm set forth by the International Medical Device Regulators Forum (IMDRF).6 The proposed classification paradigm uses two factors to determine the risk of a particular technology—the clinical utility and severity of the condition for which it is used. To further explain this, clinical utility is influenced by both the clinical care pathway impact and intended user. The impact to clinical care generally targets three areas: informing clinical management; driving clinical management; and treating or diagnosing the target condition. The intended users are either healthcare professionals (HCP) or patients.
The flexibility in the CDS policy is in the technology intended to inform clinical management, where FDA factors in the user’s ability to independently review the basis of the technology’s recommendation. Put simply, the user should not solely rely on the output of the technology to decide on the next step(s); rather, they should fully understand how the technology is being recommended so they can decide on the next step based partly on other patient information and data. If the intended user is an HCP, for example, FDA will not consider the technology a device and not subject it to agency oversight. If the intended user is a patient or caregiver, then enforcement discretion is applied only for technology that is intended for non-serious conditions. The FDA defines these conditions as those where timely and accurate diagnosis or treatment is important but not critical to mitigate long-term irreversible consequences to an individual’s health.6
There often is confusion in distinguishing between informing and driving clinical management. An inventor or manufacturer may say their technology gives users information they may not otherwise obtain about potential treatment options. Consequently, the product could be interpreted as either informing or aiding/helping the intended uses, which sounds the same but in this particular context, is actually different. A product that provides users with information meant to enhance the safe use of medicinal products or medical devices, helps predict a medical condition or makes a diagnosis, or identifies early signs of a condition meets the drive clinical management category. Mistaking these categories could lead a manufacturer down a development pathway that is very different from what they need to do—it is either overly burdensome or not sufficiently controlled.
Having explained the basics of the digital health regulatory framework, there are a few more key questions to consider that can help companies conceptualize their technology and determine the resources needed to market it.
Key Questions: What is the product intended to do? Who will be using the product? What marketing claims will be made about your product? How should the technology be positioned within the market?
The answer to these questions will be driven by the business. And these answers should be consciously made with the regulatory framework in mind.
I cannot conclude this examination of the U.S. digital health regulatory system without discussing the “It Has Come to Our Attention” letter from the FDA. Often, these letters arise because companies make claims on their website or marketing brochures about products that appear to meet the statutory definition of a medical device. If a product is determined to not be subject to regulatory oversight, companies must still be careful with the marketing language they choose. Medtech firms can avoid regulatory troubles by knowing the limitations in the claims they can legitimately make. Conducting the proper diligence to understand where on the regulatory spectrum the technology falls will better prepare organizations to answer any questions that may arise by customers, investors, or regulatory agencies. Knowing the regulatory framework the technology is within, sits just outside of, or is well outside of but may integrate with is diligence all companies should perform.
References
Nikki Batista is director of Digital Health Regulatory Affairs at MCRA. She possesses expertise in engineering research and regulatory affairs for digital health technologies and cardiology devices. Prior to joining MCRA, Batista worked for the FDA, where she was assistant director of the External Heart Rhythm and Rate Device Team. Batista provided oversight of a wide range of cardiac diagnostic devices and contributed to the development and implementation of several transformative policies at the FDA. Notably, she participated in the testing and development of the Digital Health Precertification Program, including the Streamlined Review Program and the Excellence Appraisal process, and the implementation of the Final Order to require PMAs for AED products. At MCRA, Batista supports companies of various sizes and stages of development in navigating the digital health regulatory framework, developing regulatory strategies, and supporting regulatory submissions.
To successfully navigate the U.S. digital health regulatory system, companies should understand the reasons for determining whether their technology is regulated. The main reason is risk mitigation for both customers and the business itself. Companies that develop and deploy products without first considering the regulatory framework risk violating federal law and repercussions from the FDA. Less serious, but suboptimal is determining a technology is subject to regulatory oversight during development and then scrambling to establish the proper processes and procedures in order to meet design control and quality system requirements. Reduce risk with proper diligence—identify the regulations with which you must comply. Institute the appropriate company policies. Know what the pathway to market will entail. This diligence will enable you to allocate the necessary time and resources to market a product faster and with fewer unexpected hurdles.
Key Question: Does the technology meet the statutory definition of a medical device?
Per 201(h) of the FD&C Act, a device is: “An instrument, apparatus, implement, machine, contrivance, implant, in-vitro reagent, or other similar or related article, including a component part, or accessory which is:
- recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,
- 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
- 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 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. The term ‘device’ does not include software functions excluded pursuant to section 520(o).”
The driving force behind this regulatory spectrum is the 21st Century Cures Act, which amended a section of the FD&C Act and removed certain software functions from the definition of a medical device. These software functions include:
- administrative support (e.g., claims or billing, appointment schedules, business analytics);
- maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;
- serving as an electronic patient record, such as those intended to store or transfer data under the supervision of a healthcare provider; those not intended to interpret or analyze patient data, or those that are part of health information technology certified under section 3001(c)(5) of the Public Health Service Act
Key Question: What software function policies are potentially applicable to a technology that could down classify it?
Most FDA policies are fairly straightforward except for clinical decision support (CDS), which has important nuances that can tip the balance in either the regulated or non-regulated sides of the regulatory spectrum. This policy leverages the risk classification paradigm set forth by the International Medical Device Regulators Forum (IMDRF).6 The proposed classification paradigm uses two factors to determine the risk of a particular technology—the clinical utility and severity of the condition for which it is used. To further explain this, clinical utility is influenced by both the clinical care pathway impact and intended user. The impact to clinical care generally targets three areas: informing clinical management; driving clinical management; and treating or diagnosing the target condition. The intended users are either healthcare professionals (HCP) or patients.
The flexibility in the CDS policy is in the technology intended to inform clinical management, where FDA factors in the user’s ability to independently review the basis of the technology’s recommendation. Put simply, the user should not solely rely on the output of the technology to decide on the next step(s); rather, they should fully understand how the technology is being recommended so they can decide on the next step based partly on other patient information and data. If the intended user is an HCP, for example, FDA will not consider the technology a device and not subject it to agency oversight. If the intended user is a patient or caregiver, then enforcement discretion is applied only for technology that is intended for non-serious conditions. The FDA defines these conditions as those where timely and accurate diagnosis or treatment is important but not critical to mitigate long-term irreversible consequences to an individual’s health.6
There often is confusion in distinguishing between informing and driving clinical management. An inventor or manufacturer may say their technology gives users information they may not otherwise obtain about potential treatment options. Consequently, the product could be interpreted as either informing or aiding/helping the intended uses, which sounds the same but in this particular context, is actually different. A product that provides users with information meant to enhance the safe use of medicinal products or medical devices, helps predict a medical condition or makes a diagnosis, or identifies early signs of a condition meets the drive clinical management category. Mistaking these categories could lead a manufacturer down a development pathway that is very different from what they need to do—it is either overly burdensome or not sufficiently controlled.
Having explained the basics of the digital health regulatory framework, there are a few more key questions to consider that can help companies conceptualize their technology and determine the resources needed to market it.
Key Questions: What is the product intended to do? Who will be using the product? What marketing claims will be made about your product? How should the technology be positioned within the market?
The answer to these questions will be driven by the business. And these answers should be consciously made with the regulatory framework in mind.
I cannot conclude this examination of the U.S. digital health regulatory system without discussing the “It Has Come to Our Attention” letter from the FDA. Often, these letters arise because companies make claims on their website or marketing brochures about products that appear to meet the statutory definition of a medical device. If a product is determined to not be subject to regulatory oversight, companies must still be careful with the marketing language they choose. Medtech firms can avoid regulatory troubles by knowing the limitations in the claims they can legitimately make. Conducting the proper diligence to understand where on the regulatory spectrum the technology falls will better prepare organizations to answer any questions that may arise by customers, investors, or regulatory agencies. Knowing the regulatory framework the technology is within, sits just outside of, or is well outside of but may integrate with is diligence all companies should perform.
References
- bit.ly/2R0x5QJ
- bit.ly/3dSaXB5
- bit.ly/3aGeuQO
- bit.ly/3u6aOiM
- bit.ly/3dQPmIV
- www.imdrf.org/workitems/wi-samd.asp
Nikki Batista is director of Digital Health Regulatory Affairs at MCRA. She possesses expertise in engineering research and regulatory affairs for digital health technologies and cardiology devices. Prior to joining MCRA, Batista worked for the FDA, where she was assistant director of the External Heart Rhythm and Rate Device Team. Batista provided oversight of a wide range of cardiac diagnostic devices and contributed to the development and implementation of several transformative policies at the FDA. Notably, she participated in the testing and development of the Digital Health Precertification Program, including the Streamlined Review Program and the Excellence Appraisal process, and the implementation of the Final Order to require PMAs for AED products. At MCRA, Batista supports companies of various sizes and stages of development in navigating the digital health regulatory framework, developing regulatory strategies, and supporting regulatory submissions.