Today, the U.S. Food and Drug Administration (FDA) issued the draft guidance: Content of Premarket Submissions for Device Software Functions. The draft guidance is intended to reflect FDA’s most current thinking on the recommended documentation sponsors should include in premarket submissions for FDA’s evaluation of the safety and effectiveness of device software functions, including both software in a medical device (SiMD) and software as a medical device (SaMD).
When final, it will replace the FDA’s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices issued on May 11, 2005.
Nice work Team FDA, evolution in thought and practice is a really good thing.
Quick observations from my first read through:
- The language “Software Contained in Medical Devices” moves to “Device Software Functions”
- The new guidance allows for declaration of conformance to IEC 62304 in some cases. IEC 62304 was not mentioned in the previous guidance
- The “level of concern” model has been replaced with Documentation Levels “Basic” and “Enhanced.”
It also updates the recommended documentation list as follows:
| 2005 Guidance | New DRAFT Guidance |
| Level of Concern | Documentation Level Evaluation |
| Software Description | Software Description |
| Device Hazard Analysis | Risk Management File |
| Software Requirements Specification | Software Requirements Specification |
| Architectural Design Chart | System and Software Architecture Design Chart |
| Software Design Specification | Software Design Specification |
| Traceability Analysis | (see below) |
| Software Development Environment | Software Development and Maintenance Practices |
| Verification and Validation Documentation | Software Testing as Part of Verification and Validation |
| Revision Level History | Revision Level History |
| Unresolved Anomalies (bugs or defects) | Unresolved Anomalies (Bugs, Defects or Errors) |
While there is no specific recommendation for a separate “Traceability Analysis”, the following language appears in the guidance
This recommended information should demonstrate that practices were employed resulting in traceability for device software functions and demonstrate planning, requirements, risk assessment, design reviews, change management, testing plans and results, and other aspects of good software engineering for device software functions, to help inform a regulatory decision on whether the software is appropriately designed, verified, and validated.
In addition, the need for traceability and trace needs is included in other parts of the guidance.
