Medtech, innovation

Developing a Mobile Medical Device? FDA Is Watching

By Amy Scanlin
Medtech, innovation

Designers and manufacturers of both devices and software must conduct due diligence and ensure regulatory compliance in protecting user data.

As connected devices move further into mainstream, designers and manufacturers of both the devices themselves and the software that supports them must ensure due diligence, effectiveness, as well as regulatory compliance protecting the end user’s data. As countless examples of hackers obtaining data that was housed or transmitted without adequate security unfold, industry, FDA and customer confidence must be addressed early and often to create an on-going dialogue of how data is being protected.

According to the FDA, a 2017 survey estimated 325,000 healthcare applications were available on smartphones, which equated to an expected 3.7 billion mobile health application downloads by healthcare professionals, consumers and patients, that year alone, by smartphone users worldwide. The FDA encourages the development of mobile medical apps that improve healthcare and provide consumers and healthcare professionals with valuable health information. In 2019, FDA updated the definition of the term “device” to one that is function-specific in accordance with Section 3060 of the 21st Century Cures Act. Additionally, the agency updated the term “mobile application” to “software function” in its guidance document, Policy for Device Software Functions and Mobile Medical Applications.

Certainly, the wide array of connected devices and the data collected varies. Examples of this spread include trackers such as pedometers allowing the end user to ensure they are reaching their desired daily activity level to cardiac monitoring devices with software wirelessly reporting data directly back to the provider and electronic health record.

FDA has stated a risk-based approach to enforcement of software considered to be a device and will exercise discretion, including not requiring the submission of a premarket review application or registration and listing their software, provided the software functions are of minimal risk. Examples of minimal risk software functions include those that facilitate a user’s self-management of their disease or condition without providing specific treatment suggestions, and those that automate simple tasks for healthcare providers. FDA has provided a list of the types of devices for which it will exercise enforcement discretion.

FDA is, however, focusing on the subset of software functions that meet the regulatory definition of device that poses a risk to a patient’s safety if the software were to not function as intended. As such, FDA encourages software manufacturers to search the FDA’s public databases, such as the Product Classification database and the 510(k) Premarket Notification database, to determine the level of regulation for a given device and for the most up-to-date information about the relevant regulatory requirements. FDA provides examples of software functions on which it will focus enforcement efforts and they include, as expected, functions that gather cardiac data, oxygen saturation, blood glucose and the like. As software updates are required with great frequency, FDA does not require software developers to seek FDA re-evaluation for minor, iterative product changes.

What does this mean for manufacturers of software and the devices that run them? During the product development stage, it is important to determine if a similar product has already cleared FDA hurdles. If your product is similar to a predicate device, and you can demonstrate this through safety and performance data or other means, time and money can be saved in bringing your product to market. If your product innovation is so unique that no available predicate exists in the U.S. marketplace, it is important to understand the various risks during the product development stage through study design and assessment so that the appropriate protections are in place making the product suitable for an application filed with the FDA.

Your regulatory team should have knowledge of appropriate FDA databases from which to gather historical data as well as which submission pathway is most appropriate for the software device. If there is a question or uncertainty, enlisting an outside consulting service can fill gaps, or act as your regulatory representative in totality, offering a detailed study and application review as well as arrange for pre-meetings with FDA to discuss plans for the device in the earliest stages to ensure the agency’s questions and concerns are addressed up front.

The future opportunities of connective devices is immense as big data, artificial intelligence and our ability to harness these capabilities becomes more robust. Ensure that as innovators, you create products with a keen eye and utmost attention to regulatory compliance and security.

About The Author

MedTech Intelligence