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.
No comments:
Post a Comment