FDA의 의료기기 SRS

소프트웨어 인증쪽을 하다보면(특히, 의료기기에서)

기본적으로 SW 개발시 생각해야 할 기본을 빠뜨리지 않을 수 있다.

### Guidance for Industry and FDA Staff: Content of Premarket Submissions for Software in Medical Devices

#### 발표 시기:
- 2005년 5월 11일

#### 주요 요구 사항:

1. **Software Requirements Specification (SRS)**
   - **목적**: 소프트웨어의 요구사항 문서화
   - **내용**: 기능적, 성능, 인터페이스, 디자인, 개발 등의 요구사항 포함
   - **요구 사항 수준**:
     - **Minor Level of Concern**: SRS 요약본 제공
     - **Moderate/Major Level of Concern**: 전체 SRS 문서 제공

2. **Hardware Requirements**
   - 마이크로프로세서, 메모리 장치, 센서, 에너지원, 안전 기능, 통신 등 포함.

3. **Programming Language Requirements**
   - 프로그램 크기 제한, 메모리 관리 정보 포함.

4. **Interface Requirements**
   - 시스템 구성요소 간 및 사용자와의 통신 포함 (프린터, 모니터, 키보드, 마우스 등).

5. **Software Performance and Functional Requirements**
   - 치료, 진단, 모니터링, 알람, 분석을 위한 알고리즘 및 제어 특성 포함.

6. **Architecture Design Chart**
   - 소프트웨어의 주요 기능 단위와 하드웨어 및 데이터 흐름 간 관계 도표 포함.

7. **Software Design Specification (SDS)**
   - 소프트웨어 요구사항을 SRS에 어떻게 구현할지 설명.

8. **Traceability Analysis**
   - 제품 설계 요구사항, 설계 사양, 테스트 요구사항을 연결하는 분석 제공.

9. **Software Development Environment Description**
   - 소프트웨어 개발 생명 주기 계획 요약 및 구성/변경 관리 계획 포함.

10. **Verification and Validation Documentation**
    - 소프트웨어 기기의 테스트 문서:
      - **Minor Level of Concern**: 시스템 또는 기기 수준 테스트 문서.
      - **Moderate/Major Level of Concern**: 검증 및 검증 활동 목록 및 결과.

11. **Revision Level History**
    - 개발 과정에서의 소프트웨어 수정 이력 제공.

12. **Unresolved Anomalies (Bugs or Defects)**
    - 해결되지 않은 소프트웨어 이상 목록 제공:
      - 문제, 기기 성능에 미치는 영향, 문제 해결 계획.

13. **Special 510(k) Program**
    - 기존 510(k) 승인 기기의 수정 사항에 대한 특별 510(k) 프로그램 제출 가능.
    - 수정 사항에 대한 회귀 테스트 및 검증/검증 활동 결과 제출.

#### 추가 설명:

- **Minor, Moderate, Major Level of Concern**에 따라 요구되는 문서와 세부사항이 다릅니다.
- 규정 준수 및 제품의 안전성과 효과성을 보증하기 위한 다양한 문서와 계획이 필요합니다. 

이 가이드라인은 의료 기기의 사전 승인 제출 시 소프트웨어에 대한 필수적인 문서 제공 및 요구사항을 규정하고 있습니다.

 

 

오래된 문서긴 하다. 파일은 가장 아래 첨부하였음.

 

 

Guidance for Industry and FDA Staff

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

Document issued on: May 11, 2005

 

FDA 문서에서 SRS를 요구한다.

 

Software Requirements Specification (SRS)	Summary of functional requirements from SRS.	The complete SRS document.

 

 

 

그리고 다음 내용이 있어야 한다.

 

0. Software Requirements Specification
1. 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. Examples of some typical requirements that would be included in a SRS are

11

Contains Nonbinding Recommendations

described below. For Software Devices that are identified as Minor Level of Concern, we recommend that you provide only the summary functional requirements section from the SRS, includingidentificationofoff-the-shelfsoftware. ForSoftwareDevicesthatareidentifiedas Major or Moderate Level of Concern, we recommend that you provide the complete SRS document.

Hardware Requirements

Hardware requirements generally include:

• microprocessors
• memory devices
• sensors
• energy sources
• safety features
• communications. Programming language requirements include program size requirements or restrictions, and information on management of memory leaks. Interface requirements generally include both communication between system components and communication with the user such as: 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:
• • printers
  • monitors • keyboard • mouse.
• Interface Requirements
• Programming Language Requirements

• device limitations due to software
• internal software tests and checks
• error and interrupt handling
• fault detection, tolerance, and recovery characteristics

12

Contains Nonbinding Recommendations

• safety requirements
• timing and memory requirements
• identification of off-the-shelf software, if appropriate. 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 suchasnetworking. Itisusuallynotnecessarytoincludeeveryfunctioncallandmoduleinthis 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. For Moderate and Major Level of Concern devices, detailed information such as state diagrams may be useful to clearly depict the relationships among the software functional units. If the Architecture Design Chart is included in another document such as the SRS then you should include in your submission a statement to that effect and a reference to the location of the Architecture Design Chart in the submission. 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 you submit should, in and of itself, provide adequate information to allow for review of the implementation plan for the software requirements in terms of intended use, functionality, safety, and effectiveness. A Traceability Analysis links together your product design requirements, design specifications, andtestingrequirements. Italsoprovidesameansoftyingtogetheridentifiedhazardswiththe implementationandtestingofthemitigations. Werecommendthatyousubmitforreview explicit traceability among these activities and associated documentation because they are essential to effective product development and to our understanding of product design, development and testing, and hazard 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
• Traceability Analysis
• Software Design Specification
• Architecture Design Chart

13

Contains Nonbinding Recommendations

structure with a common numbering scheme; however, we recommend that you include some mechanism, such as a matrix for guiding the reviewer through the information you submit.

Software Development Environment Description

For Moderate and Major Level of Concern Software Devices, the submission should include a summary of the software development life cycle plan. This summary should describe the sponsor’s software development life cycle and the processes that are in place to manage the various life cycle activities. For Major Level of Concern Software Devices, 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.

As mentioned elsewhere, configuration or change management is a crucial aspect of software development. 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 of the development environment should provide information on your configuration management and maintenance plan that addresses these aspects of the software development life cycle. For a Major Level of Concern device, we recommend that you provide sufficient detail to allow for a thorough understanding of the configuration management and maintenance plan. For a Moderate Level of Concern device, we recommend that you provide only a summary of the configuration management and maintenance plans.

Verification and Validation Documentation

The terms “verification” and “validation” described earlier in this document refer to two phases of Software Device testing. This section recommends the type of testing documentation you should include in a premarket submission for a Software Device, based on the Level of Concern.

Minor Level of Concern Devices

For Minor Level of Concern devices, we recommend that you submit documentation of system or device level testing, and, where appropriate, integration testing. The documentation submitted should include system or device level test pass/fail criteria and a summary of the test results.

Moderate Level of Concern Devices

For Moderate Level of Concern devices, we recommend that you submit a summary list of validation and verification activities and the results of these activities. We also recommend that you submit your pass/fail criteria. You should ensure that the Traceability Analysis effectively links these activities and results to your design requirements and specifications.

14

Contains Nonbinding Recommendations

Major Level of Concern Devices

For Major Level of Concern devices, we recommend that you submit the information recommended above for Moderate Level of Concern devices and a description of any tests that were not passed. We also recommend that you include any modifications made in response to failed tests and documentation of results demonstrating that the modifications were effective. Documentation provided in your submission should include examples of unit integration testing and a summary of the results.

Revision Level History

Your submission should include the history of software revisions generated during the course of productdevelopment. Thistypicallytakestheformofaline-itemtabulationofthemajor 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)

For Moderate and Major Level of Concern Software Devices, the submission should include a list of all unresolved software anomalies. For each anomaly, we recommend that you indicate the:

• problem

• impact on device performance
• any plans or timeframes for correcting the problem (where appropriate). The Special 510(k) Program
• For a premarket submission to qualify for review under the Special 510(k) Program, the device should be a modification of your 510(k) cleared device that you own, where the modification does
• We recommend that you annotate each item with an explanation of the impact of the anomaly ondevicesafetyoreffectiveness,includingoperatorusageandhumanfactorsissues. Typically, this list can be generated as an output of a change control board or similar mechanism for evaluation and disposition of unresolved software anomalies. We recommend that you communicate this list to the end user as appropriate to assist in the proper operation of the device. Inallinstanceswhereitispracticaltodoso,youshouldincludeanymitigationsor possible work-arounds for unresolved anomalies; this recommendation applies to Blood Establishment Computer Software in particular.

15

 

Contains Nonbinding Recommendations

notaltertheintendeduseorthefundamentalscientifictechnologyofthedevicevii. InaSpecial 510(k), you should follow the recommendations in this guidance on the documentation to submit, but submit only the documentation related to the modification that prompted the submission. For example, when submitting the documentation of requirements and specifications in a Special 510(k), the documentation should focus on the modifications and may not necessarily include all of the requirements and specifications of the entire device.

We recommend that you submit the regression testing performed to verify and validate the modifications. Werecommendthatyousubmityourtestplans,pass/failcriteria,andsummary results rather than test data. In all cases, the type of software-related documentation and the level of detail you provide should be appropriate to the Level of Concern associated with your device in thecontextofthemodifications. SinceaSpecial510(k)submissionreliesonyourdeclarationof conformance to design controls, we believe you cannot properly submit a Special 510(k) until you have completed testing or other activities relied on by your declaration (see section 514(c)(1)(B) of the Federal Food, Drug, and Cosmetic Act (Act) (21 U.S.C. 360d(c)(1)(B)).

fda.pdf

다운로드