One of PQE Group's unique features, is its global presence, with a dedicated local touch. We'll support you at 'home', providing your business with a rich experience from all over the world.
Learn more about our compliance support for Medical Device
What is a Device Software Function?
A Device Software Function is a software function that meets the device definition in Section 201(h) of the FD&C Act. The term “function” represents a distinct purpose of the product, which could be the intended use or a subset of its intended use.
Examples include, but are not limited to, firmware and other means for software-based control of medical devices, software accessories to medical devices, and software-only function(s) that meet the definition of a device.
Goodbye Level of Concern and Welcome Documentation Level
The first thing that catches your eye as you scroll through the new Guidance is that the terminology and the differentiation of the documentation to be provided according to the “Level of Concern" no longer appear.
This concept has been replaced by the “Documentation Level”.
The purpose of the Documentation Level is to help identify the minimum amount of information that would support a premarket submission that includes device software functions.
A risk-based approach has been introduced to determine the device’s Documentation Level that can be Basic or Enhanced.
When determining the Documentation Level, sponsors should consider all known or foreseeable software hazards and hazardous situations associated with the device, including those resulting from reasonably foreseeable misuse, whether intentional or unintentional, prior to the implementation of risk control measures. This also includes the likelihood that device functionality is intentionally or unintentionally compromised by inadequate device cybersecurity
FDA-required Documentation Levels
The documentation required are reported below:
|
Software Documentation Elements |
Basic Documentation Level |
Enhanced Documentation Level |
|
Documentation Level Evaluation |
A statement indicating the Documentation Level and a description of the rationale for that level. |
|
|
Software Description* |
Software description, including overview of significant software features, functions, analyses, inputs, outputs, and hardware platforms. |
|
|
Risk Management File |
Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report. |
|
|
Software Requirements Specification (SRS)* |
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 software documentation elements (e.g., risk management file, software design specification, system and software architecture design chart, software testing). |
|
|
System and Software Architecture Design |
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 (including information technology (IT) infrastructure and peripherals) interact with the system and software. |
|
|
Software Design Specification (SDS)* |
FDA is not recommending the SDS as part of the premarket submission. Sponsor should document this information on the design via the DHF for the device. During premarket review, FDA may request additional information, if needed, to evaluate the safety and effectiveness of the device. |
SDS documentation, including sufficient information that would allow FDA to understand the 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. |
|
Software Development, Configuration Management, and Maintenance Practices |
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 subclasses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 and clause 8 among others as applicable. |
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 subclasses 5.1, clause 6, and clause 8 among others as applicable. |
|
Software Testing as Part of Verification and Validation |
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. |
Basic Documentation Level, PLUS unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports. |
|
Software Version History* |
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. |
|
|
Unsolved Software Anomalies * |
List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness. |
|
*Already present in the previous guidance.
Conclusion
The content of this Guidance is planned to be put in force 60 days after its publication, sometime around August 14, 2023.
If you are thinking of entering the US market, it is best to begin developing documentation according to this updated Guidance.
PQE can support you with your submission to the FDA and in the issuing of all necessary documents.
