FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

Sample Pages

BACK
to
Product Page
more information

Evidence Product Checklist

for the

FDA Document

FDA Guidance for the Content of

Premarket Submissions for Software Contained in Medical Devices

May 11, 2005

Introduction

The process of defining what is necessary for compliance with a guideline such as “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” is often confusing and laborious because the directions contained in the guidelines are unclear or ambiguous. To aid in determining what is actually “recommended” by the guideline in the way of physical evidence of compliance, the experts at SEPT have produced this checklist. This checklist is constructed around a classification scheme of physical evidence comprised of procedures, plans, records, documents, audits, and reviews. There must be an accompanying record of some type when an audit or review has been accomplished. This record would define the findings of the review or audit and any corrective action to be taken. For the sake of brevity this checklist does not call out a separate record for each review or audit. All procedures should be reviewed but the checklist does not call out a review for each procedure, unless the guideline calls out the procedure review. In this checklist “manuals, reports, scripts and specifications” are included in the document category.

The author has carefully reviewed the guideline “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” and defined the physical evidence recommended based upon this classification scheme. SEPT has conducted a second review of the complete list to ensure that the guideline s’ producers did not leave out a physical piece of evidence that a “reasonable person” would expect to find. It could certainly be argued that if the guideline did not call it out then it is not recommended; however, if the document was used by an organization to improve its process, then it would make sense to recognize missing documents. Therefore, there are documents specified in this checklist that are implied by the guideline, though not specifically called out in the guideline, and they are designated by an asterisk (*) throughout this checklist. These items are classified as suggested. If a document is called out more than one time, only the first reference is stipulated. If there are no new requirements or suggestions in a particular clause or sub-clause then the clause or sub-clause is omitted throughout sections 2-7.

There are occasional situations in which a procedure or document is not necessarily separate and could be contained within another document. For example, the “Data Base Requirements Document" could be a part of the Software Requirements Document". The author has called out these individual items separately to ensure that the organization does not overlook any facet of physical evidence. If the organization does not require a separate document, and an item can be a subset of another document or record, then this fact should be denoted in the detail section of the checklist for that item. This should be done in the form of a statement reflecting that the information for this document may be found in section XX of Document XYZ. If the organizational requirements do not call for this physical evidence for a particular project, this should also be denoted with a statement reflecting that this physical evidence is not recommended and why. The reasons for the evidence not being recommended should be clearly presented in this statement. Further details on this step are provided in the Detail Steps section of the introduction. The size of these documents could vary from paragraphs to volumes depending upon the size and complexity of the project or business requirements.

General Principles

General Principles of the checklist for “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices”

This checklist was prepared by analyzing each clause of this guideline for the key words that signify a:

· Procedure

· Plan

· Records

· Document ( Including Lists, Manuals, Reports, Scripts and Specifications)

· Audit

· Review

This checklist specifies evidence that is unique. After reviewing the completed guideline, the second review was conducted from a common sense “reasonable man” approach. If a document or other piece of evidence appeared to be recommended, but was not called out in the guideline, then it is added with an asterisk (*) after its notation in the checklist. The information was transferred into checklist tables, based on the type of product or evidence.

Using the Checklist

When a company is planning to use “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices”, the company should review the evidence checklist. If the company’s present process does not address an “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” product, then this question should be asked: Is the evidence product recommended for the type of business of the company? If in the view of the company the evidence is not recommended, the rationale should be documented and inserted in the checklist and quality manual. This rationale should pass “the reasonable person rule.” If the evidence is recommended, plans should be prepared to address the missing item(s).

Detail Steps

An enterprise should compare the proposed output of their software project or organization against the checklist. In doing this, they will find one of five conditions that exist for each item listed in the checklist. The following five conditions and the actions required by these conditions are listed in the table below.

Condition	Action Required
1. The title of the documented evidence specified by the checklist (document, plan, etc) agrees with the title of the evidence being planned by the organization.	Record in checklist that the organization is compliant.
2. The title of the documented evidence specified by the checklist (document, etc) disagrees with the title of the evidence planned by the organization but the content is the same.	Record in the checklist the evidence title the organization uses and record that the organization is compliant, and the evidence is the same although the title is different.
3. The title of the documented evidence specified by the checklist (document, etc) is combined with another piece of evidence.	Record in the checklist the title of the evidence (document, etc) in which this information is contained.
4. The title of the documented evidence specified by the checklist (document, etc) is not planned by the organization because it is not required.	Record in the checklist that the evidence is not required and the rationale for this decision.
5. The title of the documented evidence called out by the checklist (document, etc) is not planned by the organization and should be planned by it.	Record in the checklist when this evidence will be planned and reference a plan for accomplishing the task.

Components of the Checklist

This checklist is composed of 7 sections:

· Section 1. Introduction

· Section 2. Composites of all recommended and suggested “FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices”.

· Sections 3-7. Individual checklists for each evidence type.

Product Support

All reasonable questions concerning this checklist or its use will be addressed free of charge for 60 days from time of purchase, up to a maximum of 4 hours consultation time.

FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, Checklist by Page and Paragraph	Procedures	Plans	Records	Documents	Audits & Reviews
Page 9 Table 3
Page 9 Table 3 Row 1-Level of Concern Level of concern A, B, and C	· Level of Concern Document Procedure*			· Level of Concern Document	· Level of Concern Document Review*
Page 9 Table 3 Row 2-Software Description Level of concern A, B, and C	· Software Description Document Procedure*			· Software Description Document	· Software Description Document Review*
Page 9 Table 3 Row 3-Device Hazard Analysis Level of concern A, B, and C	· Device Hazard Analysis Document Procedure*			· Device Hazard Analysis Document	· Device Hazard Analysis Document Review*
Page 9 Table 3 Row 4-1-Software Requirements Specification (SRS) Level of concern A	· Summary of Functional Requirements Specification (SRS) Document Procedure* (Summary of functional requirements only)			· Summary of Functional Requirements Specification (SRS) Document (Summary of functional requirements only)	· Summary of Functional Requirements Specification (SRS) Document Review * (Summary of functional requirements only)
Page 9 Table 3 Row 4-2-Software Requirements Specification (SRS) Level of concern B and C	· Software Requirements Specification (SRS) Document Procedure* · (Complete document)			· Software Requirements Specification (SRS) Document (Complete document)	· Software Requirements Specification (SRS) Document Review* (Complete document)
Page 9 Table 3 Row 5- Architecture Design Chart Level of concern B, and C	· Architecture Design Chart Document Procedure*			· Architecture Design Chart Document	· Architecture Design Chart Document Review*
Page 9 Table 3 Row 6- Software Design Specification (SDS) Level of concern B, and C	· Software Design Specification (SDS) Document Procedure*			· Software Design Specification (SDS) Document	· Software Design Specification (SDS) Document Review*
Page 9 Table 3 Row 7- Traceability Analysis Level of concern A, B, and C	· Traceability Analysis Document Procedure*			· Traceability Analysis Document	· Traceability Analysis Document Review*
Page 9 Table 3 Row 8-2- Software Development Environment Description Level of concern B	· Software Development Environment Description Document Procedure* (Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities)			· Software Development Environment Description Document (Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities)	· Software Development Environment Description Document Review * (Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities)
Page 9 Table 3 Row 8-3- Software Development Environment Description Level of concern C	· Software Development Environment Description Document Procedure* (Summary of software life cycle development plan, Annotated list of control documents generated during development process. Include the configuration management and maintenance plan.)			· Software Development Environment Description Document (Summary of software life cycle development plan, Annotated list of control documents generated during development process. Include the configuration management and maintenance plan.)	· Software Development Environment Description Document Review* (Summary of software life cycle development plan, Annotated list of control documents generated during development process. Include the configuration management and maintenance plan.)
Page 10 Table 3 Row 9-1- Verification and Validation Documentation Level of concern A	· Verification and Validation Document Procedure * (Software functional test plan, pass/fail criteria, and results.)			· Verification and Validation Documentation (Software functional test plan, pass/fail criteria, and results.)	· Verification and Validation Document Review* (Software functional test plan, pass/fail criteria, and results.)
Page 10 Table 3 Row 9-2- Verification and Validation Documentation Level of concern B	· Verification and Validation Document Procedure * (Description of V&V activities at the unit, integration and system level. System level test protocol including pass/fail criteria and test results.)			· Verification and Validation Document (Description of V&V activities at the unit, integration and system level. System level test protocol including pass/fail criteria and test results.)	· Verification and Validation Document Review* (Description of V&V activities at the unit, integration and system level. System level test protocol including pass/fail criteria and test results.)

Home / Contact us: r cgroup@rcglobal.com