How To Build A 510(k) Application For Your Mobile Medical App

By Keith Barritt, Fish & Richardson P.C.

Although the FDA has taken substantial steps to deregulate many mobile medical apps, there will always be some apps beyond that safe harbor — such as fetal heart rate monitors and acupuncture point locators — that are regulated as medical devices. These apps, unless they are Class I devices, will generally require FDA authorization under the 510(k) program before they can be legally marketed in the United States. 

This article discusses how software developers should build a 510(k) application once they’ve built their app. Better yet, developers should consider FDA requirements as they are writing the code and building their app. The FDA authorization process can seem a bit daunting, but careful planning will help to smooth out the rough edges.

Scope Of Applicable FDA Regulation

Not all medical devices are regulated the same way.  Under the agency’s three-tiered risk classification system, most Class I devices do not require prior FDA authorization to market, though they are still subject to Quality System Regulation (QSR), medical device establishment registration, device listing, labeling, and reporting requirements for adverse events.

Class II devices generally require prior FDA authorization via the 510(k) program, requiring the manufacturer to identify a lawfully marketed “predicate device” to which its device can be deemed “substantially equivalent.”  This is not always an easy task, and as technology develops, it can become a greater challenge to identify an appropriate predicate device. 

Class III devices (i.e., those that are truly novel or have already been placed in Class III) generally require FDA pre-market approval (PMA), a much higher regulatory burden than mere authorization under the 510(k) program.  Most manufacturers prefer to stay out of Class III if possible, though there are some advantages, such as avoiding being considered a potential predicate device for a competitor’s subsequent 510(k) application.

Beyond the basic elements of any 510(k) application, mobile medical app developers should consult several specific FDA guidance documents.  While guidance documents do not contain legal requirements, they do contain the FDA’s current thinking on certain topics, and following the advice in a guidance document can go a long way to convincing the FDA that your device is substantially equivalent to the predicate device (even if the FDA never considered the same issues for the predicate device).

Cybersecurity

Reflecting the rising concern over cybersecurity in general, the FDA released in October 2014 its guidance document Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.  As stated by the FDA, “failure to maintain cybersecurity can result in compromised device functionality, loss of data (medical or personal) availability or integrity, or exposure of other connected devices or networks to security threats.  This in turn may have the potential to result in patient illness, injury, or death.” Manufacturers are encouraged to address cybersecurity during design and development, including establishing a cybersecurity vulnerability and management approach as part of the software validation and risk analysis.

Based on the National Institute of Standards and Technology (NIST) Framework for Improving Critical Infrastructure Cybersecurity, the FDA recommends that manufacturers consider the following core functions to guide their cybersecurity activities: identify, protect, detect, respond, and recover.  Thus, manufacturers should consider the extent to which security controls are needed based on:

• The device’s intended use
• The presence and intent of the device’s electronic data interfaces,
• The device’s intended use environment
• The type of cybersecurity vulnerabilities present,
• The likelihood that the vulnerabilities will be exploited (either intentionally or unintentionally)
• The probable risk of patient harm due to a cybersecurity breach

Manufacturers should also provide justification in their 510(k) applications for the security features of devices. The FDA recommends that manufacturers include certain documentation related to cybersecurity in their 510(k) applications, including: 

• Hazard analysis, mitigations, and design considerations pertaining to intentional and unintentional cybersecurity risks associated with the device
• A traceability matrix that links the cybersecurity controls to the cybersecurity risks
• A summary describing the plan for providing validated software updates and patches as needed throughout the life cycle of the device to ensure its continued safety and effectiveness
• A summary describing the controls in place to ensure that the software will maintain its integrity (i.e., remain free of malware) from the point of origin to the point the device leaves the manufacturer’s control
• Instructions for use and product specifications related to recommended cybersecurity controls

Software Validation

In 2002, the FDA released “General Principles of Software Validation; Final Guidance for Industry and FDA Staff.”  Software validation is required under the FDA’s QSR, 21 C.F.R. Part 820.  Unless specifically exempted, software in medical devices is subject to design control provisions of the QSR, including specific requirements for software validation, planning, input, verification, and reviews.  Software developers should be familiar with the type of validation documentation the FDA expects manufacturers to maintain.

Some medical devices rely on off-the-shelf software.  The FDA’s 1999 guidance document Off-The-Shelf Software Use in Medical Devices details the documentation that should be maintained to demonstrate the software has been validated for its intended use.

Finally, in 2005, the FDA released its guidance document titled Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. This guidance discusses the documentation that should be included in a 510(k) application based on the device’s “level of concern,” (i.e., an estimate of the severity of injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or employing the device for its intended use).  The “level of concern” can be major, moderate, or minor, with different types of software validation documentation required for each.

Use Of Wireless Technology

Not all regulated mobile medical apps will rely on radiofrequency transmissions.  However, for those that do, manufacturers should be aware that having a product certified by the Federal Communications Commission (FCC) is not sufficient to guarantee it will be authorized by the FDA for marketing as a medical device.  Unlike the FCC, the FDA does not have specific technical requirements for regulated wireless medical devices, but rather the device must be found either substantially equivalent under the 510(k) program or safe and effective under the PMA program (assuming it is not a Class I device exempt from the FDA marketing authorization requirements).

In August 2013, the FDA released a detailed guidance on Radio-Frequency Wireless Technology in Medical Devices. This guidance discusses many aspects of the use of RF technology in medical devices, including:

• Selection and performance of wireless technology
• Wireless quality of service
• Coexistence with other wireless products
• Security of wireless signals and data
• Electromagnetic compatibility
• Information for proper setup and operation
• Maintenance considerations

Unique Device Identifier

The FDA is phasing in a requirement that all medical devices — including stand-alone software downloaded from a website — be labeled with a unique device identifier (UDI).  For life-supporting or life-sustaining Class II or Class I devices, the UDI requirements took effect on Sept. 24, 2015.  For other Class II devices, the requirements take effect on Sept. 24, 2016, and for other Class I devices the requirements take effect on Sept. 24, 2018.

The UDI is composed of both a device identifier, which identifies the labeler of the device and its specific version or model, and a production identifier, such as a lot or batch number, serial number, production date, etc.  The FDA’s rules on UDIs are rather complex, and manufacturers should begin now to plan how they will comply.

For downloadable software, the UDI must be provided through an easily readable plain-text statement displayed either when the software is started, or through a menu command (e.g., an “About...” menu command).  Stand-alone software that is not distributed in packaged form must include the version number in its production identifier.  Stand-alone software that is distributed in packaged form is subject to the same UDI labeling requirements as any other medical device; namely, the device label and device package must bear a UDI in a plain text and an automatic identification and data capture (AIDC) format (e.g., a bar code). 

Conclusion

Preparing a 510(k) application is almost never a simple cut-and-paste job, as each device has distinct characteristics and issues to be considered.  For mobile medical apps that are regulated by the FDA as medical devices, there are many considerations to be made, and new issues arise all the time as the FDA’s scrutiny is constantly evolving. 

Software developers should take care not to ignore the FDA’s important role in helping to ensure that regulated mobile medical apps are safe and effective for their intended uses — or, to be more precise, at least as safe and effective as the predicate device relied upon in a 510(k) application.

About The Author

Keith A. Barritt is a principal in the Washington, D.C., office of Fish & Richardson. His practice is primarily focused on all aspects of trademark law as well as all aspects of medical device regulation by the FDA, including obtaining marketing authorization for medical devices, use of new devices for investigational purposes, and import and export issues. Barritt has prepared and filed dozens of 510(k) pre-market notifications, ranging from innovative lasers to software-based surgical devices. He advises clients on issues involving quality system regulations, device labeling, medical device reporting obligations, recalls, device listing, establishment registration, and import/export regulations. To contact him, visit http://www.fr.com/keith-a-barritt/