documents for FDA - Rev 2

Ok... Here is what that translates to.

I will need to have the following in my documents...

SOFTWARE DOCUMENTATION

Software Description

Overview of

· Software Features

· Device features controlled by software

· Intended operational environment

· Programming language

· Hardware platform

· Operating system (if applicable)

· Use of Off-the-Shelf software (if applicable)

Software Requirements Specification

· Describe what the Software Device is supposed to do

· Hardware requirements (Microprocessors, memory, devices, sensors, energy sources, safety features, communications)

· Programming Language Requirements (Development Tools, management of memory leaks etc)

· Interface Requirements (between system components, with the user, printers, monitors, keyboard, mouse)

· Software Performance and Functional Requirements

o algorithms

o control characteristics for therapy

o diagnosis

o monitoring

o alarms

o analysis and interpretation with full text references or supporting clinical data

o device limitations due to software

o internal software tests and checks

o error and interrupt handling

o fault detection, tolerance and recovery

o characteristics

o safety requirements

o timing

o memory requirements

o identification of off-the-shelf software

Architecture Design Chart

· Relationships among the major functional units in the Software Device

· Relationships to hardware

· Data flows (networking and others)

· State diagrams

· There should be sufficient information to allow for review of the organization of the software

o Relative to the functionality

o And to the intended use of the Software Device.

Software Design Specification

· A guideline on how to implement SRS (in terms of design / algo etc…) that is detailed enough so that:

o Developers know exactly how to implement support for SRS features.

o Reviewers can verify that SRS functionality, safety, effectiveness and intended use are implemented properly

Software Development Environment Description

Provide the following:

· Outline of Software development life cycle

· Outline of Processes for managing various life cycle activities.

· List of the control/baseline documents generated

· List or description of software coding standards.

· Change control process to software and device post FDA

· Configuration management plan

· Maintenance plan

Verification and Validation Documentation

· Documentation of system or device level testing

· Integration testing

· System or device level test pass/fail criteria

· Summary of the test results.

· Summary list of all V&V activities at module / unit level

· Description of tests that were not passed

o Resulting modifications

o Proof that modifications fixed the issue

· Ensure that the Traceability Analysis effectively links these activities and results to design requirements and specifications.

Revision Level History

· History of software revisions generated during development

· 1 row per release listing

o changes to the software relative to last

o date,

o version number,

· The last entry should also contain:

o differences between the tested version of software and the released version

o Assessment of the potential effect of the differences on the safety and effectiveness of the device.

Unresolved Anomalies (Bugs or Defects)

This is a list of all open bugs. For each entry provide:

· Impact on device performance

· Impact on device safety or effectiveness

· operator usage and human factors issues

· plans or timeframes for correcting the problem

· Any mitigation or possible work-around

This list should be communicated to the end user as appropriate to assist in the proper operation of the device.

Traceability Analysis

A Traceability Analysis is generally a matrix with line items linking the following together

· SRS

· SDS

· V & V

· Hazard Analysis

· The implementation and testing of the mitigations.

Device Hazard Analysis

This is a tabular description of identified hardware and software hazards associated with device’s intended use, including severity assessment and mitigations with one line item for each identified hazard. Each line item should include:

• Identification of the hazardous event
• Severity of the hazard
• Cause(s) of the hazard
• Method of control (e.g., alarm, hardware design)
• Corrective measures taken, including an explanation of the aspects of the device design/requirements, that eliminate, reduce, or warn of a hazardous event; and
• Verification that the method of control was implemented correctly.

When performing a hazard analysis address all foreseeable hazards including those resulting from intentional or inadvertent misuse of the device.

Level of Concern

This is a statement indicating the Level of Concern and a description of the rationale for that level. We recommend that you indicate the Level of Concern for your Software Device, determined before the effects of any mitigation. We recommend that you clearly state which one of the three levels of concern is appropriate for your device and include documentation of the rationale for your decision. We also recommend that your documentation make your decision-making process apparent to FDA.

Basic List of Documents Required

The first step was to figure out what is the basic stuff that they are going to be looking for. This blog lists all the documents that the guidance sheet says we need to submit. In some cases we need only a summary of the document but in some cases we need more. What I understood till now in a nutshell is:

• They want a window into your software development process.
• How “dangerous” is the product to someone determines the level of visibility they need into the complete software development process.
• Since the final destination of a medical device is manufacturing, ISO guidelines seem to have a strong influence on the guidelines

SOFTWARE DOCUMENTATION

Level of Concern
This is a statement indicating the Level of Concern and a description of the rationale for that level. We recommend that you indicate the Level of Concern for your Software Device, determined before the effects of any mitigation. We recommend that you clearly state which one of the three levels of concern is appropriate for your device and include documentation of the rationale for your decision. We also recommend that your documentation make your decision-making process apparent to FDA.

Software Description
This is a summary overview of the features and software operating environment. It provides a comprehensive overview of the device features that are controlled by software, and describe the intended operational environment. Generally it will have individual paragraphs highlighting major or operationally significant software features. It should include information on the following:

• Programming language
• Hardware platform
• Operating system (if applicable)
• Use of Off-the-Shelf software (if applicable)

Device Hazard Analysis
This is a tabular description of identified hardware and software hazards associated with device’s intended use, including severity assessment and mitigations with one line item for each identified hazard. Each line item should include:

• Identification of the hazardous event
• Severity of the hazard
• Cause(s) of the hazard
• Method of control (e.g., alarm, hardware design)
• Corrective measures taken, including an explanation of the aspects of the device design/requirements, that eliminate, reduce, or warn of a hazardous event; and
  Verification that the method of control was implemented correctly.

When performing a hazard analysis address all foreseeable hazards including those resulting from intentional or inadvertent misuse of the device.

Software Requirements Specification
The Software Requirements Specification (SRS) documents the requirements for the software. This typically includes functional, performance, interface, design, developmental and other requirements for the software. In effect, this document describes what the Software Device is supposed to do. Typically an SRS would have the following sections at least:

Hardware Requirements:
Microprocessors, memory devices, sensors, energy sources, safety features, communications.

Programming Language Requirements:
Programming language requirements include program size requirements or restrictions, and information on management of memory leaks.

Interface Requirements:
Interface requirements generally include both communication between system components and communication with the user such as printers, monitors, keyboard, mouse.

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, safety requirements, timing and memory requirements, identification of off-the-shelf software, if appropriate.

Architecture Design Chart
This document is typically a flowchart or similar depiction of the relationships among the major functional units in the Software Device, including relationships to hardware and to data flows such as networking. It is usually not necessary to include every function call and module in this document; however, there should be sufficient information to allow for review of the organization of the software relative to the functionality and to the intended use of the Software Device. Detailed information such as state diagrams may be useful to clearly depict the relationships among the software functional units.

Software Design Specification
The Software Design Specification (SDS) describes the implementation of the requirements for the Software Device. In terms of the relationship between the SRS and the SDS, the SRS describes what the Software Device will do and the SDS describes how the requirements in the SRS are implemented. The information presented in the SDS should be sufficient to ensure that the work performed by the software engineers who created the Software Device was clear and unambiguous, with minimal ad hoc design decisions. The SDS may contain references to other documents, such as detailed software specifications. However, the document should provide adequate information to allow for review of the implementation plan for the software requirements in terms of intended use, functionality, safety, and effectiveness.

Traceability Analysis
A Traceability Analysis links together your product design requirements, design specifications, and testing requirements. It also provides a means of tying together identified hazards with the implementation and testing of the mitigations. The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations. It is possible to document traceability simply through a shared organizational structure with a common numbering scheme supported by a matrix linking it all together.

Software Development Environment Description
This is a summary of the software development life cycle plan describing the software development life cycle and the processes that are in place to manage the various life cycle activities. This document should also include an annotated list of the control/baseline documents generated during the software development process and a list or description of software coding standards.

Changes to the Software Device after initial market release should be subject to positive control, with definitive specification and test plans including well-defined regression testing where appropriate.

The description should also include configuration management and maintenance plan that addresses these aspects of the software development life cycle.

Verification and Validation Documentation

Documentation of system or device level testing, and, where appropriate, integration testing, system or device level test pass/fail criteria and a summary of the test results. Ensure that the Traceability Analysis effectively links these activities and results to design requirements and specifications.

Moderate:
=======
All of above along with a summary list of all validation and verification activities (not just System level).

Major:
=====
This includes all of above, along with a description of tests that were not passed and any modifications made in response to failed tests along with documentation of results demonstrating that the modifications were effective. Also include examples of unit integration testing and summary of all unit testing activities.

Revision Level History
This document contains the history of software revisions generated during the course of product development. This is a line-item tabulation of the major changes to the software during the development cycle, including date, version number, and a brief description of the changes in the version relative to the previous version. The last entry in the list should be the final version to be incorporated in the released device. This entry should also include any differences between the tested version of software and the released version, along with an assessment of the potential effect of the differences on the safety and effectiveness of the device.

Unresolved Anomalies (Bugs or Defects)
This is a list of all unresolved software anomalies. For each anomaly, indicate the problem impact on device performance, an explanation of the impact of the anomaly on device safety or effectiveness, including operator usage and human factors issues, plans or timeframes for correcting the problem (where appropriate) and where practical, include any mitigations or possible work-around for unresolved anomalies.

This list should be communicated to the end user as appropriate to assist in the proper operation of the device.

Welcome to the Jungle

It all started when my boss came in and said "ok folks... we are about to go to FDA and ask them to approve the device we have been working on... so get all your ducks in a row... and prepare the set of documents for submitting to FDA"

We had consultants with experience in this kind of stuff guide us from early on, and with their help we prepared the first set documents that were submitted to the FDA... But they were not satisfied with that stuff and came back with a million questions...

So for round two, boss also decided to take in help I was asked to evaluate the CDRH guidelines for FDA for software containing medical devices and the questions of the FDA and prepare an appropriate set of documents.

This blog will list my exploits as I navigate the forest of FDA Guidelines trying to figure out what they really want and why and then how to put it in place with the minimal effort.