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.