| | 1 | [.. 소프트웨어 개발 지침서 (Software Development Guideline)] |
| | 2 | |
| | 3 | = 7. 소프트웨어 위험 관리 = |
| | 4 | 의료기기 소프트웨어 개발 플랫폼은 기본적으로 ISO 14971에 따라 위험관리를 수행해야 한다. |
| | 5 | |
| | 6 | Figure: 위험관리 프로세스 [[BR]] |
| | 7 | [[Image(risk_management_process.png)]] |
| | 8 | [[BR]] |
| | 9 | 출처: [ISO 14971] |
| | 10 | |
| | 11 | == 7.1. 위험분석 == |
| | 12 | 위에서, 소프트웨어는 위해 또는 위해상황을 식별해야 하며, 다음가 같은 상황을 고려해야 한다: |
| | 13 | 1. 소프트웨어 요구사항 사양의 불완전 또는 부정확 |
| | 14 | 1. 소프트웨어 아이템의 기능상 결함 |
| | 15 | 1. SOUP에 의한 의도되지 않은 결과 또는 실패 |
| | 16 | 1. 소프트웨어의 예상하지 못한 동작의 결과로 인해 발생하는 하드웨어의 고장 |
| | 17 | 1. 타당하게 예상할 수 있는 잘못된 사용 |
| | 18 | |
| | 19 | 예상하지 못한 SOUP의 오류에 의해 소프트웨어 아이템에 잠재적 위해가 발생할 수 있을 경우, 최소한 SOUP공급자가 배포한 이상상황목록에 대해서는 발생할 수 있는 위해상황을 평가해야 한다. |
| | 20 | |
| | 21 | 소프트웨어 아이템과 관련된 위해상황은 위험관리 파일에 문서화한다. 식별된 위해상황에 의해 발생할 수 있는 이벤트에 대해 위험관리 파일에 문서화한다. |
| | 22 | |
| | 23 | == 7.2. 위험평가 == |
| | 24 | 1. 소프트웨어의 경우 발생가능성은 100%로 추정한다. |
| | 25 | 1. 소프트웨어 제품의 심각성 기준은 다음과 같다: |
| | 26 | |
| | 27 | ||= Level =||= Severity =||= Description =|| |
| | 28 | || 5 || Catastrophic || 환자의 사망을 발생하는 수준 || |
| | 29 | || 4 || Critical || 영구적 손상 또는 치명적 상해를 발생하는 수준 || |
| | 30 | || 3 || Serious || 전문적 의료시술이 필요한 상해 또는 손상을 발생하는 수준 || |
| | 31 | || 2 || Minor || 전문적 의료시술이 필요 없는 일시적인 상해나 손상을 발생하는 수준 || |
| | 32 | || 1 || Negligible || 불편 또는 일시적 곤란을 발생하는 수준 || |
| | 33 | |
| | 34 | 1. 위험 계산 방법: [[BR]] |
| | 35 | 위험 수준 (Risk Level) = 발생가능성 정도(Probability rating) x 심각성 정도(Severity rating) |
| | 36 | 1. 위험 허용 기준 |
| | 37 | 1. 허용 가능한 위험 수준 (AR, Acceptable Risk) = 1, 2 |
| | 38 | 1. 허용할 수 없는 위험 수준 (UR, Unacceptable Risk) = 3, 4, 5 |
| | 39 | |
| | 40 | == 7.3. 위험통제 == |
| | 41 | 제조자는 위험통제수단을 정의하고 문서화해야 한다. 위험통제수단이 소프트웨어의 기능 일부로 구현된 경우 다음과 같이 수행해야 한다: |
| | 42 | 1. 소프트웨어 요구사항에 위험통제수단을 포함시킨다. |
| | 43 | 1. 위험통제수단으로 제어하고 있는 위험에 근거하여, 위험통제수단의 구현에 기여하는 각 소프트웨어 항목에 소프트웨어 안전등급을 배정한다. |
| | 44 | |
| | 45 | == 7.4. 위험통제수단의 검증 == |
| | 46 | 문서화된 각 위험통제수단의 구현은 검증되어야 하며, 검증 결과를 문서화한다. 제조자는 위험통제수단을 검토하고, 위험통제수단이 새로운 위험상황을 초래할 수 있는지 확인하여야 한다. |
| | 47 | |
| | 48 | 제조자는 또한 다음과 같은 추적성 명시해야 한다: |
| | 49 | 1. 위해상황에서 소프트웨어 항목까지 |
| | 50 | 1. 소프트웨어 항목에서 특정 소프트웨어 원인까지 |
| | 51 | 1. 소프트웨어 원인에서 위험통제수단까지 |
| | 52 | 1. 위험통제수단에서 위험통제수단 검증까지 |
| | 53 | |
| | 54 | == 7.5. 소프트웨어 변경의 위험 관리 == |
| | 55 | 제조자는 SOUP를 포함하여 의료기기 소프트웨어에 대한 변경을 분석해야 한다: |
| | 56 | 1. 추가적인 잠재적 원인이 위해상황에서 발생할 수 있는지 |
| | 57 | 1. 추가적인 위험통제수단이 필요한지 |
| | 58 | |
| | 59 | == == |
| | 60 | [.. 소프트웨어 개발 지침서 (Software Development Guideline)] |
| | 61 | |
| | 62 | |
