50 | | == [wiki:general_requirements 5. 일반 요구사항 (General Requirements)] == |
51 | | |
52 | | === 5.1. 품질관리시스템 === |
53 | | 제조자는 다음 중 하나 이상의 품질관리시스템을 확보해야 한다: |
54 | | 1. ISO 13485 |
55 | | 1. 국가 품질관리시스템 표준 |
56 | | 1. 국가 품질관리시스템 인정서 (예, KGMP) |
57 | | |
58 | | === 5.2. 위험관리 === |
59 | | 본 문서의 7. 소프트웨어 위험 관리를 따른다. |
60 | | |
61 | | === 5.3. 소프트웨어 안전 등급 === |
62 | | 제조자는 다음과 같은 절차에 따라 의료기기 안전 등급을 정해야 한다. |
63 | | |
64 | | Figure: 소프트웨어 안전 등급 설정 프로세스[[BR]] |
65 | | [[Image(software_safety_class_process.png)]] |
66 | | [[BR]] |
67 | | 출처: [IEC62304] |
68 | | |
69 | | 초기 소프트웨어 안전 등급이 B 또는 C로 분류된 경우, 제조자는 추가적인 위험 통제 조치를 소프트웨어 시스템 외부에 구현하고 (소프트웨어 시스템을 포함하는 소프트웨어 아키텍처 개정 포함) 추가적으로 새로운 소프트웨어 안전 등급을 설정한다. |
70 | | |
71 | | 제조자는 각 소프트웨어 시스템에 대한 소프트웨어 안전 등급을 위험 관리 파일에 명시해야 한다. |
72 | | |
73 | | === 5.4. 레거시 소프트웨어 === |
74 | | 제조자는 레거시 소프트웨어를 사용하기 위해 다음과 같은 활동을 수행한다. |
75 | | |
76 | | ==== 5.4.1. 위험 관리 활동 ==== |
77 | | 1. 레거시 소프트웨어에 대한 피드백을 평가한다. |
78 | | 1. 다음과 같은 사항을 고려하여 레거시 소프트웨어를 계속 사용할 지 위험 관리 활동을 수행한다: |
79 | | 1. 전반적인 의료기기 아키텍처에 레거시 소프트웨어의 통합 |
80 | | 1. 레거시 소프트웨어의 일부로 구현된 위험 통제 조치의 지속적인 유효성 검증 |
81 | | 1. 레거시 소프트웨어의 지속적인 사용과 관련된 위해상황 식별 |
82 | | 1. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인 식별 |
83 | | 1. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인에 대한 위험통제 조치 정의 |
84 | | |
85 | | ==== 5.4.2. 갭(격차) 분석 ==== |
86 | | 1. 제조자는 활용가능한 산출물의 지속적인 유효성 검증을 평가해야 한다. |
87 | | 1. 갭이 식별되면, 제조자는 누락된 산출물과 관련 활동들을 생성한 결과 위험의 잠재적 감소를 평가해야 한다. |
88 | | 1. 이 평가에 따라, 제조자는 생성할 산출물과 관련된 활동들을 결정해야 한다. 최소한의 산출물은 소프트웨어 시스템 테스트 기록이어야 한다. |
89 | | |
90 | | ==== 5.4.3. 갭 종료 활동 ==== |
91 | | 1. 제조자는 식별된 산출물을 생성하기 위한 계획을 수립하고 실행해야 한다. |
92 | | 1. 이 계획은 레거시 소프트웨어와 산출물에서 발견된 문제를 처리하기 위한 문제 해결 프로세스를 사용해야 한다. |
93 | | 1. 레거시 소프트웨어의 변경은 소프트웨어 유지보수 프로세스를 따라야 한다. |
94 | | |
95 | | ==== 5.4.4. 레거시 소프트웨어 사용근거 ==== |
96 | | 제조자는 레거시 소프트웨어의 지속적인 사용에 대한 근본적인 이유와 함께 레거시 소프트웨어 버전을 문서화해야 한다. |
97 | | |
| 50 | == 5. 일반 요구사항 (General Requirements) == |
| 51 | |
| 52 | [wiki:general_requirements 5. 일반 요구사항 (General Requirements)] |