Regulatory Focus™ > News Articles > 2021 > 11 > FDA issues draft guidance for device software in premarket submissions

FDA issues draft guidance for device software in premarket submissions

Posted 04 November 2021 | By Jeff Craven 

FDA issues draft guidance for device software in premarket submissions

The US Food and Drug Administration (FDA) has released draft guidance for sponsors outlining its thinking about the documentation needed to support the agency’s evaluation of device software functions for premarket submissions.
 
The agency said the guidance recognizes the “rapidly evolving nature of digital health and recent FDA recognized consensus standards related to software” and, when finalized, will serve as an update to the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices document released in May 2005.
 
Changes made to section 520 of the Federal Food, Drug, and Cosmetic Act (FD&C Act) under the 21st Century Cures Act in December 2016 exclude some types of software, such as lower-risk decision support software like certain mobile apps for consumers and software for administrative support of laboratories. (RELATED: FDA Explains What Mobile Apps Are No Longer Devices, Regulatory Focus 26 September 2019; FDA Backs Off From Regulating Certain Types of Health Software, Regulatory Focus 07 December 2017)
 
With these section 520 changes in mind, the draft guidance describes software in devices that falls under the purview of FDA when assessing safety and effectiveness of devices in premarket submission. “This draft guidance describes information that typically would be generated and documented during software development, verification, and design validation,” the agency wrote.
 
 
Software functions
 
FDA made a distinction between “Software in a Medical Device” (SiMD)—defined as software that is a part of a medical device or controls it—and “Software as a Medical Device” (SaMD), which is software that meets the definition of a device but is not part of the overall device’s hardware. Both SaMD and SiMD are “device software functions,” according to the agency.
 
“For any given product, the term ‘function’ is a distinct purpose of the product, which could be the intended use or a subset of the intended use of the product,” FDA wrote. “For example, a product with an intended use to analyze data has one function: analysis. A product with an intended use to store, transfer, and analyze data has three functions: (1) storage, (2) transfer, and (3) analysis.”
 
Overall, the guidance covers firmware and other software that controls medical devices, standalone software applications, software in general computing platforms, devices with dedicated hardware and software, and medical device accessories that include software. Excluded from the guidance was software for automated manufacturing and quality systems, and software that does not meet the device definition.
 
“Generally, the recommendations in this guidance apply to the device constituent part of a combination product (such as drug-device and biologic-device combination products) when the device constituent part includes a device software function,” FDA wrote.
 
 
Software device documentation
 
FDA has updated the documentation required for sponsors with devices that include software that meets the above specifications. The agency will now consider whether software needs a basic or enhanced level of documentation based on the software’s risk to the patient, device user, other individuals, and the environment in which a device is used. In general, enhanced documentation should be provided by a sponsor if the device is a class III device, presents a risk of serious injury or death for stakeholders, is “a constituent part of a combination product,” or “(a) is intended to test blood donations for transfusion-transmitted infections; or (b) is used to determine donor and recipient compatibility; or (c) is a Blood Establishment Computer Software.”
 
When describing software in a device, sponsors should include a summary of any significant software features and functionality with specifics such as the programming language and compiler versions used, hardware platforms, operating systems, whether the device uses off-the-shelf software, and the intended release version. In addition, sponsors should be prepared to document who will use the device software, the intended patient population, analysis methodology of any analyses performed by the software, whether the software assists or replaces clinician actions, and, if applicable, additional information about artificial intelligence and machine learning models.
 
Sponsors should also document the system and architecture diagram “to facilitate a clear understanding of 1) the modules and layers that make up the system and software, 2) the relationships among the modules and layers, 3) the data inputs/outputs and flow of data among the modules and layers, and 4) how users or external products, including IT infrastructure and peripherals (e.g., wirelessly connected medical devices) interact with the system and software,” FDA wrote.
 
In addition, the sponsor should provide a Software Requirement Specification (SRS)—"what the software function will do” and Software Design Specification (SDS)—" how the requirements in the SRS are implemented,” the agency noted.
 
 
Software risk management, maintenance, testing
 
A risk assessment that includes all “reasonably foreseeable software and hardware hazards associated with the device” and a risk management plan should be included in any premarket submissions of devices that have software meeting the criteria. “It should be clear in the risk management plan how the manufacturer’s plans to evaluate the overall residual risk against the benefits of the intended use of the device,” the agency wrote.
 
For software in devices that require either basic or enhanced documentation, sponsors can either submit a Declaration of Conformity to the currently FDA-recognized version of ANSI/AAMI IEC 62304 Medical Device Software - Software Life Cycle Processes or provide the agency with a complete list of processes and procedures they use to maintain software development and maintenance practices.
 
When testing software for verification or validation, FDA said the sponsor should document all testing activities, including the version of the software used, pass/fail test results, and changes made to the software in the event of failed test results. For software that requires enhanced documentation, “integration level test protocols and reports should be provided, including expected results derived from software requirements and design, actual results that are observed and recorded, objective pass/fail determination (i.e., actual results are acceptably equivalent to expected results) and unit and integration test reports,” according to the agency.
 
“The unit and integration level test reports should demonstrate that the protocols have been acceptably executed with passing testing results and any unresolved anomalies have been acceptably deferred based on a risk assessment for the candidate release version,” they said.
 
FDA noted it is aware that the information in the draft guidance may differ from the final guidance it released on off-the-shelf software in medical devices. The agency said it plans to update the OTS software guidance if final guidance for premarket submission device software is published to make both sets of guidances consistent.
 
 
Draft Guidance: Content of Premarket Submissions for Device Software Functions
 
Federal Register notice
 

 

© 2021 Regulatory Affairs Professionals Society.

Regulatory Focus newsletters

All the biggest regulatory news and happenings.

Subscribe