FDA and IEC 62304 Software Deliverables

August 2, 2016
Need help on this topic?
Contact Us

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 3rd party software without documented controls as OTS (Off-the-shelf), and IEC 62304 considers as SOUP (Software of Unknown Provenance).  Both want the risks of device software addressed, but each require slightly different deliverables to be compliant.

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), the Documentation Plan,  and Configuration Management Plan
  2. Software V&V Plan -  Describe the plan to test the software.  I like to include the unit test and integration test plans in this document, as well as the final system software verification tests.
  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)
  4. Software Description - Describe what the software will do at a high level.  Include programming language, hardware platform, OS…
  5. Software Requirement Specification - Specify the functional requirements, performance requirements, interface requirements, safety requirements, hazard mitigations…
  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.
  8. Software Detailed Design Descriptions -  Provide the specification(s) detailing how software is implemented
  9. Off-the-shelf (OTS) Software List – List of OTS software used, including the source, version, license and function for the system
  10. Code Unit Verification -  Document the unit test and code review performed per the plan
  11. Integration Tests -  Document the integration, regression, and OTS software testing performed per the plan.
  12. 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.
  13. Summary Test Report - Create a summary of all software test per the V&V plan.
  14. 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)
  15. Revision Level History - Document major revisions and releases made in development with descriptions.
  16. Unresolved Anomalies - List the anomalies still present and associated risks, providing justification for release.
  17. Software Problem Resolution Process - Describe how reported problems are evaluated, investigated and how change requests will be handled. Once approved for change, Include how you will decide necessary regression testing.
Frances Cohen

Frances Cohen is President of Promenade Software Inc., a leading software services firm specializing in medical device and safety-critical system software. Frances has more than 20 years of experience leading software teams for medical device software. Starting with heart defibrillators for Cardiac Science  and following with  Source Scientific LLC and BIT Analytical Instruments Inc., Frances has overseen dozens of projects through development and the FDA, including IDEs, 510(k)s, and PMAs.   Frances has a B.S. in computer engineering from the Technion, Israel Institute of Technology.

About Promenade Software

Promenade Software, Inc. specializes in software development for Medical Devices and other safety-critical applications.

Contact

Promenade Software, Inc.
16 Technology Drive,  Suite 100
Irvine, CA 92618 
U.S.A.
info@promenadesoftware.com
(949) 329-8570
Go to Contact Form