FDA Software Documentation for Medical Devices

Freelance regulatory writer Shreya Chenni provides a guide to FDA software documentation for medical devices, including a breakdown of the requirements based on classification. 

The medical device industry is seeing rapid technological advancement and a high rate of innovation.  Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness. 

For any device that contains software going through the 510(k) route, specific software-related documents have to be submitted. In this article we discuss the documents required for 510(k) submissions and understand how to draft them based on your software classification.  

How to classify your medical device software? 

Identify the applicable Level of Concern (LoC). There are three levels: 

• Major: a failure or latent flaw could directly result in death or serious injury to the patient or operator 

OR 

 a failure or latent flaw could indirectly result in death or serious injury of the patient or operator through incorrect or delayed information or through the action of a care provider.

• Moderate: a failure or latent design flaw could directly result in minor injury to the patient or operator

 OR 

a failure or latent flaw could indirectly result in minor injury to the patient or operator through incorrect or delayed information or through the action of a care provider. 

• Minor:  if failures or latent design flaws are unlikely to cause any injury to the patient or operator. 

Use the Table 1 and Table 2 of the FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices to answer the questions and determine your Software Level of Concern. 

FDA software documents for medical devices

What are the documents to be submitted?

Softwares of moderate and major level of concern have 11 different documents to be submitted. Whereas, software under minor level of concern requires seven different documents. The scope and extent of detailing in these documents varies based on their LoC.

The following table identifies the documents required for each of the levels of concern: 

Minor	Moderate	Major
Level of Concern	Level of Concern	Level of Concern
Software Description	Software Description	Software Description
Device Hazard Analysis	Device Hazard Analysis	Device Hazard Analysis
Software Requirements Specification (SRS)	Software Requirements Specification (SRS)	Software Requirements Specification (SRS)
Traceability Analysis	Traceability Analysis	Traceability Analysis
Verification and Validation Documentation	Verification and Validation Documentation	Verification and Validation Documentation
Revision Level History	Revision Level History	Revision Level History
————	Architecture Design Chart	Architecture Design Chart
————	Software design specification document	Software design specification document
————	Software Development Environment Description	Software Development Environment Description
————	Unresolved Anomalies (Bugs or Defects)	Unresolved Anomalies (Bugs or Defects)

 

Description of the documents 

1. Level of Concern 

Record the answers to the questions in Table 1 and Table 2 of the FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices  in this document. Include a rationale for the determined level of concern. 

2. Software Description

This document introduces the device software and hence should provide a comprehensive overview of the features, functionalities, intended use. Include programming language, hardware platform, operating system and use of Off-the-Shelf software as applicable. Figures and diagrams should be included as appropriate. 

In case the device uses Off-the-Shelf software refer to the FDA guidance document “Guidance for Off-the-Shelf Software Use in Medical Devices.” 

3. Device Hazard Analysis 

 A device hazard analysis is a must. All the foreseeable hazards associated with the intended use of the device (software and hardware) should be captured. The risk analysis should be conducted in compliance with ISO 14971. The hazard analysis should identify the hazard, hazardous, severity of the hazard, cause of the hazard, risk control measure and verification of the control measure. 

4. Software Requirements Specification

The Software Requirements Specification (SRS) documents all the requirements for the software. Basically, the requirements describe what the software should do. Requirements can be put into different buckets such as functional, performance, user interface and regulatory. 

For minor LoC the SRS can be a summary of functional requirements, however for moderate and major the requirements have to be detailed and typically listed. Ensure that each requirement listed has a requirement ID assigned to it such as SRS-01, SRS-02 and so on. 

Here are few examples of the SRS: 

Hardware requirements: Include the requirements about –  

• microprocessors 
• memory devices
• sensors 
• energy sources 
• safety features
• communications

Programming requirements: Include the program size requirements, restrictions and so on 

Interface requirements: Include requirements that describe the communication between the software and hardware devices such as printers, monitors. Other requirements such as the operating system the software is compatible with and so on. 

Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. 

Software performance and functional requirements may also include:

• Device limitations due to software 
• Internal software tests and checks
• Error and interrupt handling 
• Fault detection, tolerance, and recovery characteristics 12 Contains Nonbinding Recommendations 
• Safety requirements
• Timing and memory requirements 
• Identification of off-the-shelf software, if appropriate. 

5. Architecture Design Chart

 This document clearly presents the relationship, flow of data and interaction between the major components or functional blocks of the software. This is usually depicted in the form of flowchart, block diagrams and other forms as appropriate. For moderate and major level of concern software, the design chart can include state diagrams. 

6. Software Design Specifications (SDS)

The implementation of the requirements is detailed in this document. Each SDS shall be numbered, such as SDS-01, similar to the SRS. Each requirement included in the SRS should have a corresponding design specification. However, it is also possible that a single design specification can correspond to a group of requirements. 

7. Traceability Analysis

This document links the requirements, design specification, hazards and V&V tests. The traceability matrix can be drafted as below, details can be added as appropriate: 

User need (optional)	SRS	SDS	Hazards	V&V test cases
UND-001	SRS-001 SRS-002	SDS-001	Haz-001	TC-001
UND-002	SRS-002	SDS-001 SDS-002	Haz-002	TC-002 TC-004

 

8. Software Development Environment Description (SDED)

Moderate and major level of concern software are required to submit a SDED which describes software development life cycle plan, maintenance and software activities. The level of detailing differs for Moderate and Major. Refer to EN 62304 Table 1: Table A.1 – Summary of requirements by software safety class. This can be used to identify the elements to be included and the activities that are to be documented per their class. The three classes A, B and C align with the FDA’s level of concern.  

9. Verification and Validation Documentation

Minor LoC: Document device level testing and integration testing (if applicable). Ensure the test cases have an acceptance criteria and summary of test results. 

Moderate LoC: Document summary list of validation and verification activities and their results. Include acceptance criteria. Ensure that Traceability Analysis references test case IDs. 

Major LoC: In addition to information above (Moderate LoC), description of any failed tests and changes made in response to these should be documented. 

10. Revision Level History

Document the major changes to the software ensuring that the last line time/entry is the latest version of the software. Identify the version number, date and describe the changes with respect to the prior version. 

11. Unresolved Anomalies 

Document the unsolved bugs existing in the software being released. Capture the following for each bug: 

• The problem
• Impact on device performance 
• Planned timelines to correct these bugs (if applicable) 

The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires Cybersecurity Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. 

References: 

• Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

Need help with FDA software documentation for medical devices? Get in touch with freelance regulatory writers and FDA submission experts on Kolabtree.