Changes between Version 4 and Version 5 of SDG

Timestamp:

Sep 6, 2023 2:31:43 AM (20 months ago)

Author:

admin

Comment:

--

SDG

@@ -53 +53 @@
 제조자는 다음과 같은 절차에 따라 의료기기 안전 등급을 정해야 한다. 
 
-Figure 1: 소프트웨어 안전 등급 설정 프로세스
+Figure: 소프트웨어 안전 등급 설정 프로세스
 
 초기 소프트웨어 안전 등급이 B 또는 C로 분류된 경우, 제조자는 추가적인 위험 통제 조치를 소프트웨어 시스템 외부에 구현하고 (소프트웨어 시스템을 포함하는 소프트웨어 아키텍처 개정 포함) 추가적으로 새로운 소프트웨어 안전 등급을 설정한다. 
@@ -104 +104 @@
   1. 일반적인 소프트웨어 결함의 식별 및 회피 방법과 근거 
 
+== 7. 소프트웨어 위험 관리 ==
+의료기기 소프트웨어 개발 플랫폼은 기본적으로 ISO 14971에 따라 위험관리를 수행해야 한다.
+
+Figure: 위험관리 프로세스 
+
+=== 7.1. 위험분석 ===
+위에서, 소프트웨어는 위해 또는 위해상황을 식별해야 하며, 다음가 같은 상황을 고려해야 한다:
+ 1. 소프트웨어 요구사항 사양의 불완전 또는 부정확
+ 1. 소프트웨어 아이템의 기능상 결함
+ 1. SOUP에 의한 의도되지 않은 결과 또는 실패
+ 1. 소프트웨어의 예상하지 못한 동작의 결과로 인해 발생하는 하드웨어의 고장
+ 1. 타당하게 예상할 수 있는 잘못된 사용 
+
+예상하지 못한 SOUP의 오류에 의해 소프트웨어 아이템에 잠재적 위해가 발생할 수 있을 경우, 최소한 SOUP공급자가 배포한 이상상황목록에 대해서는 발생할 수 있는 위해상황을 평가해야 한다.
+
+소프트웨어 아이템과 관련된 위해상황은 위험관리 파일에 문서화한다. 식별된 위해상황에 의해 발생할 수 있는 이벤트에 대해 위험관리 파일에 문서화한다.
+
+=== 7.2. 위험평가 ===
+ 1. 소프트웨어의 경우 발생가능성은 100%로 추정한다. 
+ 1. 소프트웨어 제품의 심각성 기준은 다음과 같다:
+
+ ||= Level =||= Severity =||= Description =||
+ || 5 || Catastrophic || 환자의 사망을 발생하는 수준 ||
+ || 4 || Critical || 영구적 손상 또는 치명적 상해를 발생하는 수준 ||
+ || 3 || Serious || 전문적 의료시술이 필요한 상해 또는 손상을 발생하는 수준 ||
+ || 2 || Minor || 전문적 의료시술이 필요 없는 일시적인 상해나 손상을 발생하는 수준 ||
+ || 1 || Negligible || 불편 또는 일시적 곤란을 발생하는 수준 ||
+
+ 1. 위험 계산 방법: [[BR]]
+    위험 수준 (Risk Level) = 발생가능성 정도(Probability rating) x 심각성 정도(Severity rating)
+ 1. 위험 허용 기준
+  1. 허용 가능한 위험 수준 (AR, Acceptable Risk) = 1, 2
+  1. 허용할 수 없는 위험 수준 (UR, Unacceptable Risk) = 3, 4, 5
+
+=== 7.3. 위험통제 ===
+제조자는 위험통제수단을 정의하고 문서화해야 한다. 위험통제수단이 소프트웨어의 기능 일부로 구현된 경우 다음과 같이 수행해야 한다:
+ 1. 소프트웨어 요구사항에 위험통제수단을 포함시킨다.
+ 1. 위험통제수단으로 제어하고 있는 위험에 근거하여, 위험통제수단의 구현에 기여하는 각 소프트웨어 항목에 소프트웨어 안전등급을 배정한다. 
+
+=== 7.4. 위험통제수단의 검증 ===
+문서화된 각 위험통제수단의 구현은 검증되어야 하며, 검증 결과를 문서화한다. 제조자는 위험통제수단을 검토하고, 위험통제수단이 새로운 위험상황을 초래할 수 있는지 확인하여야 한다.
+
+제조자는 또한 다음과 같은 추적성 명시해야 한다:
+ 1. 위해상황에서 소프트웨어 항목까지
+ 1. 소프트웨어 항목에서 특정 소프트웨어 원인까지
+ 1. 소프트웨어 원인에서 위험통제수단까지
+ 1. 위험통제수단에서 위험통제수단 검증까지 
+
+=== 7.5. 소프트웨어 변경의 위험 관리 ===
+제조자는 SOUP를 포함하여 의료기기 소프트웨어에 대한 변경을 분석해야 한다:
+ 1. 추가적인 잠재적 원인이 위해상황에서 발생할 수 있는지
+ 1. 추가적인 위험통제수단이 필요한지
+
+== 8. 사이버보안 ==
+식품의약품안전평가원의 의료기기 사이버보안 허가심사 가이드라인 (민원인 안내서)를 따른다.
+
+== 9. 사용적합성 ==
+TBD
+
+== 10. 소프트웨어 개발 프로세스 ==
+소프트웨어 개발 프로세스는 Rational Unified Process를 기반으로 삼는다. 
+
+Figure: 소프트웨어 개발 프로세스
+
+The process can be described in two dimensions – the horizontal axis represents time expressed in phases, iterations, and milestones. The vertical axis represents workflows. A workflow is a sequence of activities that produces a result of observable value.
+
+프로세스는 두 개의 차원으로 설명할 수 있다. 수평 축은 단계, 반복, 마일스톤으로 표현되는 시간을 나타내며, 수평 축은 워크플로우를 나타낸다. 워크플로우는 관측 가능한 값으로 결과를 생성하는 일련의 활동이다.
+
+=== 10.1. PHASES ===
+
+==== 10.1.1. INCEPTION PHASES (도입 단계) ====
+During the inception phase, product concepts are defined. 
+
+도입 단계에서는 제품 컨셉을 정의한다.
+
+==== 10.1.2. ELABORATION PHASE (정교화 단계) ====
+The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the projects. 
+
+정교화 단계의 목적은 문제 영역을 분석하고 튼튼한 구조 기반을 구축하고, 프로젝트 계획을 개발하고, 프로젝트의 가장 큰 리스크 요소를 제거하는 것이다.
+
+==== 10.1.3. CONSTRUCTION PHASE (구축 단계) ====
+During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly verified. 
+
+구축 단계에서는 모든 구성요소와 어플리케이션 기능을 개발하고 제품에 통합하며, 모든 기능을 철저하게 검증한다.
+
+==== 10.1.3. TRANSITION PHASE (이관 단계) ====
+The purpose of the transition phase is to transition the software product to a user outside of project team. 
+
+이관 단계의 목적은 소프트웨어 제품을 프로젝트 팀 외부의 사용자에게 이관하는 것이다.