Content of Premarket Submissions for Device Software Functions
This guidance provides recommendations for documentation to include in premarket submissions for FDA's evaluation of device software functions. It applies to firmware and software-based control of medical devices, software accessories to medical devices, and software-only functions that meet the definition of a device. The guidance does not apply to automated manufacturing and Quality System software or software that is not a device.
What You Need to Know? 👇
What are the two Documentation Levels for device software functions in premarket submissions?
The FDA defines Basic and Enhanced Documentation Levels based on risk assessment. Enhanced Documentation is required when software failure could present probable risk of death or serious injury, while Basic Documentation applies to lower-risk scenarios.
Which consensus standards does FDA recommend for medical device software development?
FDA recommends ANSI/AAMI/ISO 14971 for risk management, ANSI/AAMI/IEC 62304 for software life cycle processes, and ANSI/AAMI SW91 for defect classification. These standards help ensure consistent software development and documentation quality.
What is the difference between software verification and software validation?
Software verification confirms that development outputs meet input requirements through testing and reviews. Software validation establishes that software specifications conform to user needs and intended uses in actual or simulated environments.
What key elements must be included in a Software Requirements Specification (SRS)?
The SRS must document software inputs/outputs, functions, hardware requirements, performance specifications, interfaces, user interactions, error handling, operating environment, safety requirements, and all acceptable ranges, limits, and default values.
How should sponsors determine if their device requires Enhanced Documentation Level?
Sponsors should assess whether failure of any device software function could present hazardous situations with probable risk of death or serious injury before implementing risk controls. This includes considering reasonably foreseeable misuse and cybersecurity vulnerabilities.
What information should be included in the System and Software Architecture Diagram?
The diagram must show modules and layers, their relationships, data inputs/outputs and flow, and how users or external products interact with the system. It should include descriptive text and maintain visual consistency throughout.
What You Need to Do 👇
Recommended Actions
- Determine appropriate Documentation Level (Basic or Enhanced) based on risk assessment
- Prepare required documentation package including:
- Documentation Level evaluation and rationale
- Software Description
- Risk Management File
- Software Requirements Specification
- System and Software Architecture Diagram
- Software Development and Configuration Management documentation
- Software Testing documentation
- Software Version History
- Unresolved Anomalies documentation
- For Enhanced Documentation Level, additionally prepare:
- Software Design Specification
- Detailed unit and integration test protocols/reports
- Ensure traceability between software requirements, design, and testing documentation
- Consider cybersecurity throughout software development lifecycle
- Maintain all documentation in Design History File per Quality System requirements
- For combination products or multiple function devices, address additional documentation needs
- Consider submitting Pre-Submission to obtain FDA feedback on Documentation Level determination
Key Considerations
Non-clinical testing
- Software testing documentation should be provided at unit, integration and system levels
- System level test protocol including expected results, actual results, pass/fail determination required
- For Enhanced Documentation Level, additional unit and integration level test protocols and reports required
Software
- Documentation Level (Basic or Enhanced) determined based on risk assessment
- Software Description required, including overview of features, functions, inputs/outputs
- Software Requirements Specification (SRS) required
- System and Software Architecture Diagram required
- Software Design Specification (SDS) required for Enhanced Documentation Level
- Software Development and Configuration Management practices documentation required
- Software Version History required
- Unresolved Software Anomalies documentation required
Cybersecurity
- Cybersecurity considerations should be included in risk assessment
- System architecture should document cybersecurity controls and interfaces
Safety
- Risk Management File required including:
- Risk Management Plan
- Risk Assessment
- Risk Management Report
- Risk assessment should consider hazards and hazardous situations before risk controls
Other considerations
- For combination products, additional documentation may be required
- For multiple function devices, documentation should address impact of “other functions”
- Quality System Regulation requirements must still be met
Relevant Guidances 🔗
- Off-The-Shelf Software in Medical Devices: Documentation Requirements for Premarket Submissions
- Software Validation for Medical Device Production, Quality Systems, and Device Components
- Cybersecurity in Medical Devices: Design, Implementation, and Premarket Submissions
- Multiple Function Device Products: Policy and Considerations for Functions Not Subject to FDA Review
- Clinical Evaluation of Software as a Medical Device (SaMD)
- Policy for Device Software Functions and Mobile Medical Applications
- Computer Software Assurance for Production and Quality System Software (Draft)
Related references and norms 📂
- ANSI/AAMI/ISO 14971: Medical devices - Applications of risk management to medical devices
- ANSI/AAMI/IEC 62304: Medical Device Software - Software Life Cycle Processes
- ANSI/AAMI SW91: Classification of defects in health software