The focus of the documentation levels is now centered around risk analysis. Improper and incomplete risk analysis may affect documentation levels. This is arguably the most important activity that is required per the guidance.
Moderate software could be considered either basic or enhanced depending on the results of the risk assessment. This could increase or decrease the amount of document submissions required to support your product.
Tabular description of identified hardware and software hazards including severity assessment and mitigations
Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report.
Previously software determined to be Minor will now require full SRS documentation under the basic category.
Full SRS documentation
SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other
Previously software determined to be minor will now require full SRS documentation under the basic category.
Summary SRS documentation
SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other
The new guidance provides clarification for meeting the system and software architecture design requirements.
Detailed depiction of functional units and software modules. May include state diagrams as well as flow charts.
Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products interact with the system and software.
Previously software determined to be minor will now require architecture design documentation under the basic category.
No documentation is necessary in the submission.
Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products interact with the system and software.
The FDA does not recommend that basic levels submit an SDS. However, this does not imply that creating an SDS is not necessary. The FDA may still request this information if needed.
Full software design specification documentation.
SDS Documentation, including sufficient information that would allow the FDA to understand technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended. Use, functionality, safety and effectiveness.
Although the SDS is not recommended for submission, it's still a good practice to have this information documented and ready for review should the FDA request additional information to evaluate the safety and effectiveness of the device.
No SDS documentation is necessary in the submission.
FDA is not recommending the SDS as part of the submission. However, the sponsor should document this information on the design via the DHF for the device. The FDA may request additional information if needed, to evaluate the safety and effectiveness of the device.
Good software development will still involve creating a traceability matrix and the expectation is that you still have one. Submission details provided in the SDS and SRS demonstrate traceability. However, you should still be able to trace the risks developed in the risk management plan to mitigations and additional user requirements presented in other documentation.
Traceability among requirements, specifications, identified hazards and mitigations, and V&V testing
No longer a stand-alone requirement for submission.
A declaration of conformity to the FDA version of IEC 62304 including specified subclauses is required. Additionally basic levels of documentation are required to include configuration management and maintenance plans.
Software Development Environment Description: Summary of the SDLC. Annotated list of control documents generated during the development process. Configuration management plan and maintenance documents.
Basic Documentation Level, PLUS complete configuration management and maintenance plan document(s);
OR
A Declaration of Conformity to the FDA-recognized version of IEC 62304, including subclause 5.1 (Software development planning), clause 6 (software maintenance process), and clause 8 (software configuration management process), among others as applicable.
A declaration of conformity to the FDA-recognized version of IEC 62304 including specified subclauses is sufficient. If you don't want to use IEC 62304, you can submit a summary of your life cycle development plan and a summary of configuration management and maintenance activities.
Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities.
A summary of the life cycle development plan and a summary of configuration management and maintenance activities;
OR
A Declaration of Conformity to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable.
A declaration of conformity to the FDA-recognized version of IEC 62304 including specified subclauses is sufficient. If you don't want to use IEC 62304, you can submit a summary of your life cycle development plan and a summary of configuration management and maintenance activities.
No documentation necessary
A summary of the life cycle development plan and a summary of configuration management and maintenance activities;
OR
A Declaration of Conformity to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable.
Core testing requirements remain essentially the same. The technical wording is a little differenct but expectations are the similar. However, additional testing requirements called out include intentional change testing and regression testing with associated analysis, test protocols, results, and reports. Anamolies are expected to be addressed here as well. Requirements for complete unit and integration testing are the delta between basic and enhanced levels of documentation.
Description of V&V activities at the unit, integration, and system level. Unit, integration and system level test protocols, including pass/fail criteria, test report, summary, and test results.
Basic level Documentation , PLUS unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports.
Core testing requirements remain essentially the same. The technical wording is a little differenct but expectations are the similar. However, additional testing requirements called out include intentional change testing and regression testing with associated analysis, test protocols, results, and reports. Anamolies are expected to be addressed here as well. Requirements for a summary of unit and integration testing are the delta between basic and enhanced levels of documentation.
Description of V&V activities at the unit, integration, and system level. System level test protocol, including pass/fail criteria, and tests results.
A summary description of the testing activities at the unit, integration and system levels;
AND
System level test protocol including expected results, observed results, pass/fail determination, and system level test report.
Provide a summary of the modifications compared to the previous cleared version with a summary of new tests.
Provide any intentional changes made in response to failed tests and documentation of test results demonstrating that the intentional changes were implemented correctly.
Regression analysis and testing (based on analysis) for unintended effects of a software change if needed.
System level test protocols including expected results are now required for software that would previously be considered minor and exempt from having to perform rigorous tests. Additionally, you must provide a summary description of testing activities at the unit, integration, and system levels. Additional testing requirements called out include intentional change testing and regression testing with associated analysis, test protocols, results, and reports. Anamolies are expected to be addressed here as well. Simple functional tests are no longer considered acceptable.
Software functional test plan, pass / fail criteria, and results.
A summary description of the testing activities at the unit, integration and system levels;
AND
System level test protocol including expected results, observed results, pass/fail determination, and system level test report.
Provide a summary of the modifications compared to the previous cleared version with a summary of new tests.
Provide any intentional changes made in response to failed tests and documentation of test results demonstrating that the intentional changes were implemented correctly.
Regression analysis and testing (based on analysis) for unintended effects of a software change if needed.
A list of software unresolved anomalies with an evaluation of safety and effctiveness is necessary now for all submissions. Description of software versions is new.
Revision history log, including release version number and date.
AND
List of remaining software anomalies
annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors.
A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version.
AND
List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness.
Description of software versions is new.
Revision history log, including release version number and date. No documentation was necessary in the submission
A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version.
List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness.