SDG: 5. 일반 요구사항 (General Requirements)

5.1. 품질관리시스템 (Quality Management System)

제조자는 다음 중 하나 이상의 품질관리시스템을 확보해야 한다:

1. ISO 13485
2. 국가 품질관리시스템 표준
3. 국가 품질관리시스템 인정서 (예, KGMP)

The manufacturer shall acquire one of the following quality management systems:

1. ISO 13485
2. A national quality management system standard
3. A quality management system required by national regulation (e.g., KGMP)

5.2. 위험관리 (Risk Management)

본 문서의 7. 소프트웨어 위험 관리를 따른다.

Refer to 7. Software Risk Management.

5.3. 소프트웨어 안전 등급 (Software Safety Classification)

제조자는 다음과 같은 절차에 따라 의료기기 안전 등급을 정해야 한다.

The manufacturer shall assign to each software system a software safety class.

Figure: Assigning software safety classification
출처: [IEC62304]

초기 소프트웨어 안전 등급이 B 또는 C로 분류된 경우, 제조자는 추가적인 위험 통제 조치를 소프트웨어 시스템 외부에 구현하고 (소프트웨어 시스템을 포함하는 소프트웨어 아키텍처 개정 포함) 추가적으로 새로운 소프트웨어 안전 등급을 설정한다.

For a software system initially classified as software safety class B or C, the manufacturer may implement additional risk control measures external to the software system (including revising the system architecture containing the software system) and subsequently assign a new software safety classification to the software system.

제조자는 각 소프트웨어 시스템에 대한 소프트웨어 안전 등급을 위험 관리 파일에 명시해야 한다.

The manufacturer shall document the software safety class assigned to each software system in the risk management file.

소프트웨어 시스템이 소프트웨어 항목으로 분해되고, 소프트웨어 항목이 추가 소프트웨어 항목으로 분해되는 경우, 해당 소프트웨어 항목은 제조자가 다른 소프트웨어 안전 등급으로 분류한 근거를 문서화하지 않는 한 원래 소프트웨어 항목(또는 소프트웨어 시스템)의 소프트웨어 안전 분류를 상속해야 한다. 그러한 근거는 새로운 소프트웨어 항목이 어떻게 분리되어 별도로 분류해도 되는지를 설명해야 한다.

When a software system is decomposed into software items, and when a software item is decomposed into further software items, such software items shall inherit the software safety classification of the original software item (or software system) unless the manufacturer documents a rationale for classification into a different software safety class. Such a rationale shall explain how the new software items are segregated so that they may be classified separately.

제조자는 소프트웨어 항목의 소프트웨어 안전 등급이 소프트웨어 항목 분해에 의해 생성된 소프트웨어 항목의 안전 등급과 다른 경우, 각 소프트웨어 항목의 안전 등급을 문서화해야 한다.

The manufacturer shall document the software safety class of each software item if that class is different from the class of the software item from which it was created by decomposition.

제조자는, 위험 관리 파일에 문서화하지 않는 한, 소프트웨어 항목 그룹에 가장 높은 안전 등급의 소프트웨어 항목을 분류하는데 필요한 프로세스와 타스크를 사용해야 한다.

The manufacturer shall use the processes and tasks which are required by the classification of the highest-classified software item in the group unless the manufacturer documents in the risk management file a rationale for using a lower classification.

5.4. 레거시 소프트웨어 (Legacy Software)

제조자는 레거시 소프트웨어를 사용하기 위해 다음과 같은 활동을 수행한다.

The manufacturer performs the following activities to use legacy software.

5.4.1. 위험 관리 활동 (Risk Management Activity)

1. 레거시 소프트웨어에 대한 피드백을 평가한다.
2. 다음과 같은 사항을 고려하여 레거시 소프트웨어를 계속 사용할 지 위험 관리 활동을 수행한다:
   1. 전반적인 의료기기 아키텍처에 레거시 소프트웨어의 통합
   2. 레거시 소프트웨어의 일부로 구현된 위험 통제 조치의 지속적인 유효성 검증
   3. 레거시 소프트웨어의 지속적인 사용과 관련된 위해상황 식별
   4. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인 식별
   5. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인에 대한 위험통제 조치 정의

1. Assess any feedback, including post-production information, on legacy software regarding incidents and / or near incidents, both from inside its own organization and / or from users.
2. Perform risk management activities associated with continued use of the legacy software, considering the following aspects:
   1. Integration of the legacy software in the overall medical device architecture.
   2. Continuing validity of RISK CONTROL measures, implemented as part of the legacy software.
   3. Identification of hazardous situations associated with the continued use of the legacy software.
   4. Identification of potential causes of the legacy software contributing to a hazardous situation.
   5. definition of risk control measures for each potential cause of the legacy software contributing to a hazardous situation.

5.4.2. 갭(격차) 분석 (Gap Analysis)

레거시 소프트웨어의 소프트웨어 안전 등급을 기반으로 제조자는 소프트웨어 요구사항, 소프트웨어 아키텍처, 소프트웨어 테스트, 리스크 관리에 대해 사용가능한 결과물에 대한 갭 분석을 수행해야 합니다.

1. 제조자는 활용가능한 산출물의 지속적인 유효성 검증을 평가해야 한다.
2. 갭이 식별되면, 제조자는 누락된 산출물과 관련 활동들을 생성한 결과 위험의 잠재적 감소를 평가해야 한다.
3. 이 평가에 따라, 제조자는 생성할 산출물과 관련된 활동들을 결정해야 한다. 최소한의 산출물은 소프트웨어 시스템 테스트 기록이어야 한다.

Based on the software safety class of the legacy software, the manufacturer shall perform a gap analysis of available deliverables against the software requirements, software architecture, software test and risk management.

1. The manufacturer shall assess the continuing validity of available deliverables.
2. Where gaps are identified, the manufacturer shall evaluate the potential reduction in risk resulting from the generation of the missing deliverables and associated activities.
3. Based on this evaluation, the manufacturer shall determine the deliverables to be created and associated activities to be performed. The minimum deliverables shall be software system test records

5.4.3. 갭 종료 활동 (Gap Closure Activities)

1. 제조자는 식별된 산출물을 생성하기 위한 계획을 수립하고 실행해야 한다.
2. 이 계획은 레거시 소프트웨어와 산출물에서 발견된 문제를 처리하기 위한 문제 해결 프로세스를 사용해야 한다.
3. 레거시 소프트웨어의 변경은 소프트웨어 유지보수 프로세스를 따라야 한다.

1. The manufacturer shall establish and execute a plan to generate the identified deliverables.
2. The plan shall address the use of the problem resolution process for handling problems detected in the legacy software and deliverables.
3. Changes to the legacy software shall be performed in accordance to the software maintenance process.

5.4.4. 레거시 소프트웨어 사용근거 (Rationale for Use of Legacy Software)

제조자는 레거시 소프트웨어의 지속적인 사용에 대한 근본적인 이유와 함께 레거시 소프트웨어 버전을 문서화해야 한다.

The manufacturer shall document the version of the legacy software together with a rationale for the continued use of the legacy software.