FDA and IEC 62304 Software Documentation

Compliance to the Regulations

If navigating between the FDA guidance documents and IEC 62304 is a difficult task, figuring out the differences is downright ominous. They have much in common, but they use different terms and definitions to get their point across. For example, the FDA refers to third-party software without documented controls as OTS (off-the-shelf), and IEC 62304 considers them as SOUP (Software of Unknown Provenance). Both want the risks of device software addressed, but each requires slightly different deliverables.

Ultimately, the goal of regulation is the same: to create a safe and effective system with software. You need to provide proof that software development was controlled, using good established development practices and showing that safety considerations have been addressed. I have seen a clear trend of auditors placing more and more scrutiny on software. Having a clean submission that clearly follows expectations helps your software sail through the process.  

Below, I have provided the list of deliverables needed to cover both the FDA and IEC 62304. This is the list that we use at Promenade. Note that each deliverable must be verified, and the plan should address how that is done (often review and sign-off).

1. Software Development Plan - Define processes, deliverables, and development activities. The plan should include the Life Cycle Activities, Risk Management Plan (don't forget to include OTS software and Cyber-security risks), Documentation Plan, Configuration Management Plan, Change Control process, and Problem Resolution Process.
   
2. Software V&V Plan - Describe the plan to test the software. Include all verification activities in this document, including code review, unit test and integration test plans, and the final system software verification test plan.
3. Software Level of Concern - Establish the risk level of the system software and the software class as I, II, or III (or associated A,B,C for IEC 62304).
   
4. Software Description - Describe what the software will do at a high level. Include programming language, hardware platform, OS, etc.
   
5. Software Requirement Specification - Specify the functional requirements, performance requirements, interface requirements, safety requirements, hazard mitigations, etc.
   
6. Software Architecture Chart - Include diagrams of subsystems and major components, and the interfaces between them. This can provide segregation of software entities for risk control.
   
7. Software Hazard Analysis - Create an IEC 62304 hazard analysis, identifying potential hazards and the software items that could cause them. Mitigations should feed back into the Requirements. Include OTS software hazard analysis and wireless QoS (if applicable).
8. Cybersecurity - Document Cybersecurity Controls and Features, Threat Model, Hazard Analysis, and Penetration Testing.
9. Software Detailed Design Descriptions -  Provide the specification(s) detailing how software is implemented.
10. Off-the-shelf (OTS) Software  – List the OTS software used, including the source, version, license, and function for the system. Outline the plan to control OTS software.
11. Wireless Technology Report - Describe the wireless technologies and functions used, if applicable.
12. Code Unit Verification -  Document the unit test and code review performed per the plan.
13. Integration Tests - Document the integration, regression, and OTS software testing performed per the plan.
14. System Software Verification Protocols - Detail test protocols for the final device software. These must trace to requirements and must provide coverage of the requirements. Each should have pass/fail criteria.
15. Summary Test Report - Create a summary of all software verification per the V&V plan.
16. Trace Matrix - Create a spreadsheet tracing system requirements to software requirements to associated design specifications and Test Protocols. Include software hazards (that have software mitigations).
17. Revision Level History - Document major revisions and releases made in development, with descriptions.
18. Unresolved Anomalies - List the anomalies still present and associated risks, providing justification for release.
19. Software Problem Resolution Process - Describe how reported problems are evaluated and investigated and how change requests will be handled. Once approved for change, include how you will decide necessary regression testing.

For more medical device industry insights, visit Promenade's blog.