What is the FDA Guidance about?
A draft version of the FDA guidance document “Content of Premarket Submissions for Device Software Functions” was published in November 2021. This version has now been official since 14 June 2023. This guidance replaces the “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” from May 2005.
The first change that immediately catches the eye is the adjustment from “software contained in the medical device” to “device software function”. This term broadenes the horizon and includes all software that contributes to the fulfilment of the intended purpose with its function – not just software as part of a medical device (embedded software), as it was previously the case.
The new guidance recommends the minimum amount of information that must be provided in a submission for a medical device that includes one or more software functions.
In the Guidance document, the term “pre-market application” includes, among other things
- a premarket notification 510(k) submission,
- an application for de novo classification,
- a Premarket Approval (PMA),
- an Investigational Device Exemption (IDE),
- a Humanitarian Device Exemption (HDE) or
- a Biologics Licence Application (BLA).
However, this guidance does not apply to software for automated manufacturing and quality systems or software that is not a medical device.
What is the biggest innovation in the FDA Guidance?
With its guidance, the FDA has come somewhat closer to IEC 62304 “Medical Device Software – Software Life Cycle Processes”. However, there is still the significant difference that the software safety classification of IEC 62304 (Class A, B, C) takes into account possible risk control measures, whereas the FDA guidance focuses with the determination of its “documentation level” – previously “level of concern” – on the pure application/purpose prior to the implementation of risk control measures.
The previous “level of concern” differentiated between the three levels “minor”, “moderate” and “major” – depending on the risk to patients or people in the vicinity of the medical device. The higher the classification, the greater the scope of documentation. With the new guidance, the classification has now been completely restructured : There is no longer a “Level of concern”, but a “Documentation level” with two classes:
- Basic Documentation should be submitted as a minimum approach with each submission prior to placing on the market.
- Enhanced Documentation should additionally be submitted with any premarket submission involving a device software function(s) whose failure or error could present a hazardous situation likely to result in death or serious injury to a patient, a user of the device or others in the use environment. This also includes the likelihood that product functionality may be intentionally or unintentionally compromised by inadequate cybersecurity of the product.
Regardless of the risk, “Enhanced Documentation” is recommended for a number of specified medical devices, particularly in connection with blood handling and for combination products containing drugs.
Examples for determining the documentation level
- A non-invasive blood pressure monitor with inflatable cuff
- Description: The device is a battery-powered, reusable device for use at home and in professional healthcare facilities and measures a person’s systolic and diastolic blood pressure by software-controlled inflation and deflation of the cuff.
- Justification: Failure or potential failure of the device software function will not result in death or serious injury to the patient, the user of the device or other persons in the application environment
- Result: Basic Documentation Level
- Electric exoskeleton for lower extremities.
- Description: A prescription powered exoskeleton for the lower extremities consisting of an external, motorised orthosis that is placed over a person’s paralysed or weakened limbs for medical purposes.
- Justification: Failure or potential failure of the device software function could result in death or serious injury to the patient
- Result: Enhanced Documentation Level
- Software device for retinal diagnosis
- Description: The prescription device contains an AI/ML-enabled algorithm designed to analyse images for diagnostic screening to detect retinal diseases or conditions.
- Justification: Failure or potential failure of the device software function could result in death or serious injury to the patient if conditions are not recognised (in time).
- Result: Enhanced Documentation Level
Recommended scope of documentation
The following table provides an overview of the recommended documentation for each software documentation element and the corresponding documentation level.
Software documentation | Basic Documentation Level | Enhanced Documentation Level |
Evaluation of the documentation level | The explanation and justification for the choice of documentation level should take into account the intended purpose of the product and, where appropriate, include references from the submission documentation to support the choice. | |
Software description | Software description, including an overview of the most important software features and functions, analyses, inputs, outputs and hardware platforms. Possible software changes since last FDA submission. Be sure to consider: Operation of the software (intended use, intended user, patient population, analysis methods, ML/KI methods), SW specifics (HW/SW platform, OTS-SW, SW version and possible differences between individual versions), SW inputs and outputs (input data and their format, who supplies the inputs, outputs and their format, who receives the outputs, influencing or replacing manual actions, design for interoperability) | |
Risk Management File | Risk management plan showing how the overall residual risk is to be weighed against the benefit of the intended use of the product. Risk assessment should be presented for the complete software/software system and include risk analysis, risk assessment, risk control and risk-benefit analysis. The risk management report should include a record of the implementation of the risk management plan, an assessment of the risk management activities and acceptance of the residual risk, and evidence of the suitability of the methods chosen for the collection and assessment of relevant information from production and post market surveillance. | |
Software Requirements Specification (SRS) | The software requirements specification describes the requirements for the software/software system and should be submitted: – in a format that is easy to read, organised and presented at the level of the software system or subsystems, – with sufficient information to understand the traceability of the information in relation to the other elements of the software documentation (e.g. system requirements, system and software architecture, software design specification, software testing), – in the case of changes to an already authorised or released product, with the identification of all relevant differences, – identifying all requirements that are most critical to the safety and effectiveness of the product, and – with reference to the necessary documents
| |
System and software architecture design | The system and software architecture provides detailed diagrams of the modules, layers and interfaces that make up the device, their relationships, the data inputs/outputs and data flow, and the way in which users or external products interact with the system and software (possibly described with text to facilitate testing). The relationships between the individual diagrams should also be clearly presented. Visual aspects (e.g. use of colour or other visual means), linguistic aspects (e.g. use of annotations, consistent terminology/terms), clear references are important. | |
Software Design Specification (SDS) | Not necessary. The FDA may request additional design information as needed to evaluate the safety and effectiveness of the device. | The Software Design Specification describes the technical design details of the software functions, the complete and correct implementation of all requirements of the SRS by the software design and the traceability of the software design to the SRS in terms of intended use, functionality, safety and effectiveness. It is expected that the SDS served as guidance for implementation and testing and was not created retrospectively. |
Software development, configuration management and maintenance practices | Summary of the life cycle development plan, configuration management and maintenance activities. OR Declaration of conformity to the FDA recognised version of IEC 62304, including subchapters 5.1.1-5.1.3, 5.1.6-5.1.9, Chapter 6 (Software Maintenance Process) and Chapter 8 (Software Configuration Management Process), and others as appropriate. | Basic Documentation Level, PLUS complete documentation of the implementation of the configuration management and maintenance plans; OR Declaration of conformity to the FDA recognised version of IEC 62304, including Subchapter 5.1 (Software Development Planning), Chapter 6 (Software Maintenance Process) and Chapter 8 (Software Configuration Management Process), and others as applicable. |
Software tests as part of verification and validation | A summary of testing activities at unit, integration and system level (including changes in response to failed tests and regression analysis and testing); AND Test protocol at system test level with the expected results, the actual results, the acceptance criteria and the test report at system level. The system level test report should show that all tests were performed, the test results were acceptable and all unresolved anomalies were accepted based on a risk assessment for the candidate release version. | Basic Documentation Level, PLUS test protocols at unit and integration level with the expected results, the actual results, the acceptance criteria and the test reports at unit and integration level. The test reports on the unit and integration tests should show that all tests were performed, the test results were acceptable and all unresolved anomalies were accepted based on a risk assessment for the candidate release version. |
Software version history | A history of the software versions that have been tested and documented as part of the verification and validation activities at unit, integration and system level, starting with the version that was subject to the regular design control process. This is usually in tabular form with the date and version number of the tested version (including bench, animal and clinical tests, if applicable) and a brief description of any changes to the version from the previously tested version. The final released version should be listed as the last entry, indicating the differences from the previously tested version together with an assessment of the potential impact of the changes on the safety and effectiveness of the product. | |
Unresolved Software Anomalies | List of remaining unresolved software anomalies usually as a table with the – description of the anomaly, – indication of how the anomaly was detected and, where possible, the root cause(s) of the anomaly; – assessment of the impact of the anomaly on the safety and effectiveness of the product and usability; – result of the assessment; and – risk-based justification based on the established risk policy as to why the anomaly was not corrected or rectified The application of a defect classification system or taxonomy to each anomaly is recommended. | |
What else needs to be considered
The guidance must be followed for all submissions since 14 August 2023.
All documents to be submitted should be legible and understandable, which means, for example
- no truncated diagrams,
- no insufficient font size,
- being not legible without high magnification
Failure to do so may result in the FDA requesting additional information and delaying approval.
Although the FDA’s new guidance document does not require a traceability matrix or similar as part of the premarket submission, the manufacturer is expected to document this analysis in its design documentation for the device. For example, based on the risk assessment submitted, the FDA will evaluate how identified risk control measures can be traced back to the product requirements, software testing and labelling. Special emphasis is placed on traceability between the requirements listed in the software requirements specification and the information on these requirements and other software documents, such as the software design specification, the system and software architecture design and the software test documentation.
When creating the software version history, it is not necessary to list all tested versions, but only those that were used in the most important development steps, which means, for instance, the software version used in the clinical study, usability tests, laboratory tests, standard in-house tests, etc. All information must be available for the versions listed so that the auditor can easily understand the software differences.
Please note: A declaration of conformity for full compliance with the ANSI/AAMI/IEC 62304 standard alone is not sufficient for approval, as there are differences in the categorisation of the device software function and recommended documentation between the FDA Guidance and IEC 62304.
Only the most important contents of the Guidance have been mentioned in this article. Further criteria and aspects of the individual documents to be submitted are explained in the Guidance itself.
Do you need support in creating your software documentation according to IEC 62034, the FDA Guidance or in compliance with both regulations? Contact us, we will be happy to create the necessary documentation with you and for you.
Please note that all details and listings do not claim to be complete, are without guarantee and are for information purposes only.
