Premarket Submissions of Device Software Functions
TL;DR
The FDA’s 2021 draft guidance on software documentation meaningfully updates a 16-year-old framework that industry had grown accustomed to:
- The previous three-tier risk classification (Minor, Moderate, Major) has been consolidated into two documentation levels — Basic and Enhanced — with the Enhanced threshold now triggered by four explicit risk factors rather than a detailed question-based assessment.
- Former Moderate-level submissions face the most significant documentation burden under the new guidance, now required to meet Enhanced-level standards that include full unit and integration test protocols and reports.
- A notable tension exists between the guidance and IEC 62304: the guidance requires risk assessment before risk controls are applied, while IEC 62304 assesses classification after, a discrepancy that could result in different documentation expectations for the same software.
How the FDA’s new guidance on software documentation changes current requirements
On November 4th, 2021, the FDA issued a new draft guidance: Content of Premarket Submissions for Device Software Functions. This draft guidance was issued for commenting and is intended to replace their previous guidance on the subject, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices from May 2005.
Background
Over 15 years old, the original guidance is well used and understood by industry. So the changes in this new version will require significant changes in mindset about how to carry out and document software development. Whilst draft guidances are intended to be drafts for comment, there is an understanding that they are the latest thinking from the FDA and should be considered when developing medical devices. In a recent Q&A session, the FDA were keen to emphasize that the draft guidance is not in affect yet. They did not elaborate on when it might be finalised, however, they did say that the commenting period is open until February and they expected it to be “some time” before the draft would be final.
This draft guidance document is intended to provide information regarding recommended documentation that should be included in premarket submissions for FDA’s evaluation of the safety and effectiveness of device software functions. It applies to the following types of submissions:
- Premarket Notification (510(k))
- De Novo Classification Request
- Premarket Approval Application (PMA)
- Investigational Device Exemption (IDE)
- Humanitarian Device Exemption (HDE)
- Biologics License Application (BLA)
This list has been expanded to reflect the submission types that are now available compared to those in 2005.
Additional documentation may also be required for post-market activities relating to software. This guidance specifically looks at documentation needed for submission.
The guidance also clarifies that it applies to both Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD), but it does not apply to automated manufacturing and Quality System software or software that is not a device. This is a helpful delineation of scope.
Changes from Previous Version of this Guidance
The previous guidance categorized software into 3 risk classifications or levels of concern: Minor, Moderate, Major. These levels were somewhat aligned with the relevant process standard IEC 62304:2015 Medical Device Software – Software life cycle processes, which had classes A, B, C. At very least they had the same number of levels.
The new guidance now defines the following:
Documentation Level
The recommended documentation for a premarket submission depends on the device’s risk to a patient, a user of a device, or others in the environment of use.
- Basic Documentation should be provided for any premarket submission that includes device software functions where Enhanced Documentation does not apply.
- Enhanced Documentation should be provided for any premarket submission that includes device software functions, which include any of the 4 subsequently stated risk factors in the next section.
This reduces the categories that software fall in from three to two, which provokes the questions of how do the previous classifications relate to the new classifications?
Determination of Risk compared to Previous Guidance
First let’s look at what triggers the higher level, enhanced documentation. If the software exhibits any of the following Risk Factors, then it requires the enhanced documentation:
- The device is a constituent part of a combination product.
- The device (a) is intended to test blood donations for transfusion-transmitted infections; or (b) is used to determine donor and recipient compatibility; or (c) is a Blood Establishment Computer Software.
- The device is classified as class III.
- A failure or latent flaw of the device software function(s) could present a probable* risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. These risk(s) should be assessed prior to implementation of risk control measures. You should consider the risk(s) in the context of the device’s intended use; the direct and indirect impacts to safety, treatment, and/or diagnosis; and other relevant considerations.
* ‘probable’ is intended to capture reasonably foreseeable software and hardware risks associated with the device
In comparison, the previous guidance required a determination of Level of Concern through answering the following questions:
- If the answer to any one question below is Yes, the Level of Concern for the Software Device is likely to be Major.
- Does the Software Device qualify as Blood Establishment Computer Software?
- Is the Software Device intended to be used in combination with a drug or biologic?
- Is the Software Device an accessory to a medical device that has a Major Level of Concern?
- Prior to mitigation of hazards, could a failure of the Software Device result in death or serious injury, either to a patient or to a user of the device? Examples of this include the following:
- a) Does the Software Device control a life supporting or life sustaining function?
- b) Does the Software Device control the delivery of potentially harmful energy that could result in death or serious injury, such as radiation treatment systems, defibrillators, and ablation generators?
- c) Does the Software Device control the delivery of treatment or therapy such that an error or malfunction could result in death or serious injury?
- d) Does the Software Device provide diagnostic information that directly drives a decision regarding treatment or therapy, such that if misapplied it could result in serious injury or death?
- e) Does the Software Device provide vital signs monitoring and alarms for potentially life-threatening situations in which medical intervention is necessary?
- If the Software Device is not Major Level of Concern and the answer to any one question below is Yes, the Level of Concern is likely to be Moderate.
- Is the Software Device an accessory to a medical device that has a Moderate Level of Concern?
- Prior to mitigation of hazards, could a failure of the Software Device result in Minor Injury, either to a patient or to a user of the device?
- Could a malfunction of, or a latent design flaw in, the Software Device lead to an erroneous diagnosis or a delay in delivery of appropriate medical care that would likely lead to Minor Injury?
- If the answers to all of the questions above are No, the Level of Concern is Minor.
Immediately one can see the correlation between Risk Factors 1 and 2 from the new guidance, with questions 1 and 2 under Major Level of Concern in the old guidance. Risk Factor 3 in the new guidance, has some alignment with the sub-questions under question 4 of Major Level of Concern in the old guidance. The generalisation that all class III devices including software will require enhanced documentation is understandable as these high risk devices will be expected to provide more detailed and extensive documentation throughout the submission and not just for software.
It is interesting that the questions about accessories to a medical device are no longer explicitly stated, but it is inferred that this is being covered by the risk assessment.
Finally, Risk Factor 4 in the new guidance has been worded more generically to cover all the remaining considerations from Major and Moderate questions in the old guidance.
Assessment of Risk compared to IEC 62304
Risk Factor 4 is the first conflict with IEC 62304, as in the guidance it specifically states “these risk(s) should be assessed prior to implementation of risk control measures” whereas the assessment flow chart from IEC 62304 (Figure 1) shows an expectation that the classification is determined after risk controls are applied. This could lead to different risk profiles being defined for the same software, leading to different documentation expectations. This is in addition to the difference between the two levels in the guidance and the 3 levels in IEC 62304.
Figure 1 – IEC 62304: 2015 Figure 3 – Assigning software safety classification.
(International Organization for Standardization)
This discrepancy is concerning because in this new guidance it sets an expectation that software will be developed in accordance with IEC 62304 and even states under the category of “Software Development and Maintenance Practices” that a Declaration of Conformity to IEC 62304 can be provided.
Documentation required by the Guidance
When looking at what documentation is required, both the previous and new version of the guidance provide a helpful table of what is expected for classification of software and provide further details on the content of those documents. The Documentation Requirements comparison below is only a summary and does not contain full details. Please see the guidance for more information.
Table 1 – Documentation Requirements comparison between 2005 and 2021 Guidances
Document Type
Previous (2005) Guidance
Minor Concern
Moderate Concern
Major Concern
New (2021) Guidance
Basic Level
Enhanced Level
Level of Concern / Documentation Level Evaluation
A statement indicating the Level of Concern and a description of the rationale for that level.
A statement indicating the appropriate Documentation Level and a description of the rationale for that level.
Software Description
A summary overview of the features and software operating environment.
Software description, including overview of operationally significant software features, analyses, inputs, and outputs.
Device Hazard Analysis / Risk Management File
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.
Software Requirements Specification (SRS)
Summary of functional requirements from SRS.
The complete SRS document.
The complete documentation, describing the needs or expectations for a system or software, presented in an organized format 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 as part of verification and validation).
Architecture Design Chart / System and Software Architecture Design Chart
No documentation is necessary in the submission.
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 (including IT infrastructure and peripherals) interact with the system and software.
Software Design Specification (SDS)
No documentation is necessary in the submission.
Software design specification document.
None.
The complete 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.
Traceability Analysis
Traceability among requirements, specifications, identified hazards and mitigations, and Verification and Validation testing.
See SRS.
Software Development Environment Description / Software Development and Maintenance Practices
No documentation is necessary in the submission.
Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities.
Summary of software life cycle development plan. Annotated list of control documents generated during development process. Include the configuration management and maintenance plan documents.
A Declaration of Conformity to IEC 62304
OR
a summary of the life cycle development plan and a summary of configuration management and maintenance activities.
A Declaration of Conformity to IEC 62304
OR
Basic Documentation Level PLUS complete configuration management and maintenance plan document(s).
Verification and Validation
Documentation / Software Testing as Part of Verification and Validation
Software functional test plan, pass/fail criteria, and results.
Description of V&V activities at the unit, integration, and system level. System level test protocol, including pass/fail criteria, and tests results.
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 tests results.
A summary description of the testing activities at the unit, integration, and system levels.
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.
Revision Level History
Revision history log, including release version number and date.
Revision history tabulating the major changes to the software during the development cycle, including date, version number, a brief description of the changes relative to the previous version, and indication of the version on which testing was performed.
Unresolved Anomalies (Bugs or Defects)
No documentation is necessary in the submission.
List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors.
List of remaining software anomalies (e.g., bugs, defects) annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors, work-arounds, and timeframe for correction.
Highlights from the above table:
- The elements of the submission between the guidances remains similar, with the exception of traceability analysis which was previously called out as its own item, but now is integrated into the Software Requirements Specification (SRS).
- The “Device Hazard Analysis” element is now indicated as the “Risk Management File” and describes a set of documents rather than the individual document. However, these documents would normally be included in a submission and are not an additional burden.
- The major/moderate expectations have been combined into the enhanced level of documentation, and the basic level has added in some of the moderate level descriptive aspects to the previous minor level requirements.
- Additional detail is being provided about the content of each element.
In summary, the impact of the changes between the two versions of the guidance could be considered to be as follows:
Table 2 – Summary of Changes in Guidance Requirements
| Categories | Change |
|---|---|
| Was minor, now basic | Additional descriptive documents required |
| Was moderate, now enhanced | Additional descriptive documents required Additional V&V detailed protocols and reports |
| Was major, now enhanced | No significant change |
Alignment with IEC 62304
But how does the draft guidance compare with the expectations of documentation and development activities from IEC 62304?
Enhanced level documentation approximately aligns with Class B/C. Basic would be equivalent to class A. However, due to the differences in assessing the risks associated with the software, a class B from IEC 62304 which has a non-serious harm (prior and post risk controls) could exist, which would then only need the basic level documentation for submission.
The Comparison between Guidance and IEC 62304 table below shows the documentation required from IEC 62304:
Table 3 – Comparison between Guidance and IEC 62304
| Document Type | Basic | Class A | Enhanced | Class B/C |
|---|---|---|---|---|
| Software Development Plan1 | X | X | ||
| Documentation Level Evaluation (formerly Risk Classification) | X | X | X | X |
| Software Description2 | X | X | ||
| Software Architecture | X | X | X | |
| Risk Management File | X | X | X | Specific Software Risk |
| Software Requirements | X | X | X | X |
| Software Design Specification | X | X | X | |
| Software Development and Maintenance Practices | X | X | X | X |
| Software testing as Part of Verification and Validation | System | System | System, Unit, Integration | System, Unit, Integration |
| Revision Level History | X | X | X | X |
| Unresolved Anomalies | X | X | X | X |
1 Specific to IEC 62304
2 Specific to software submissions in accordance with FDA guidance
For most items, the draft guidance and IEC 62304 are reasonably aligned but discrepancies exist in the expectations for:
- Software architecture – basic/class A
- Software design specification – basic/class A
FDA and IEC 62304 Alignment Remains an Open Question
Care is needed when planning medical device development with software likely to be submitted to the FDA for authorization, to ensure all required activities and documentation are covered.
The expectations between the FDA guidance and IEC 62304 need to be resolved if industry is expected to comply with both.
Save Time and Money with our Regulatory Checklist
What Manufacturers Need to Know About the New FDA Software Documentation Guidance
Does the 2021 FDA draft guidance replace the 2005 guidance on software documentation?
The 2021 document is a draft guidance issued for comment and is intended to replace the 2005 guidance. While it is not yet finalized, the FDA considers it a reflection of current thinking, and manufacturers developing software-containing devices should account for it in their planning.
What triggers Enhanced Documentation under the new guidance?
Enhanced Documentation is required if any one of four risk factors applies: the device is part of a combination product; it involves blood donation testing, donor/recipient compatibility, or Blood Establishment Computer Software; it is classified as Class III; or a software failure could present a probable risk of death or serious injury prior to risk controls being applied.
How does the new guidance affect devices previously classified as Moderate concern?
Devices that previously fell under the Moderate level now require Enhanced Documentation, which adds complete unit and integration test protocols and reports — a meaningful increase in documentation burden compared to the old Moderate requirements.
Is IEC 62304 compliance still expected under the new guidance?
Yes. The guidance continues to expect software development to align with IEC 62304, and accepts a Declaration of Conformity to IEC 62304 as part of the submission. However, a conflict exists in how risk is assessed: the guidance and IEC 62304 differ in whether risk classification is determined before or after risk controls are applied.
Does this guidance apply to Software as a Medical Device (SaMD)?
Yes. The guidance explicitly applies to both Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD), while excluding automated manufacturing software and Quality System software that is not itself a device.
Helen Simons is a former Senior Director of QA/RA at StarFish Medical. Helen has over 15 years experience in product development. She has worked on a wide range of Medical Device and IVD products, from inhalers and injection devices to phototherapy devices and ventilators. Her experience includes project managing product developments and providing quality and regulatory guidance to both internal teams and clients for the US, EU and Canadian markets. Providing detailed insight into the regulatory requirements for those markets, Helen’s expertise includes business improvements and building effective and efficient quality systems. Prior to joining StarFish Medical, Helen worked at companies including Sagentia, Cambridge Design Partnership, and GHD. She holds a Master’s Degree in Engineering from Durham University, Durham, England.