SDG: 7. 소프트웨어 위험 관리 (Software Risk Management)

의료기기 소프트웨어 개발 플랫폼은 기본적으로 ISO 14971에 따라 위험관리를 수행해야 한다.

The manufacturer shall apply a risk management process complying with ISO 14971.

Figure: Risk management process

출처: [ISO 14971]

7.1. 위험분석 (Risk Analysis)

위에서, 소프트웨어는 위해 또는 위해상황을 식별해야 하며, 다음가 같은 상황을 고려해야 한다:

1. 소프트웨어 요구사항 사양의 불완전 또는 부정확
2. 소프트웨어 아이템의 기능상 결함
3. SOUP에 의한 의도되지 않은 결과 또는 실패
4. 소프트웨어의 예상하지 못한 동작의 결과로 인해 발생하는 하드웨어의 고장
5. 타당하게 예상할 수 있는 잘못된 사용

The manufacturer shall consider the following potential causes:

1. Incorrect or incomplete specification of functionality.
2. Software defects in the identified software item functionality.
3. Failure or unexpected results from SOUP.
4. Hardware failures or other software defects that could result in unpredictable software operation.
5. Reasonably foreseeable misuse.

SOUP의 실패 또는 예상치 못한 결과가 위험한 상황을 발생시키는 소프트웨어 항목의 잠재적 원인인 경우 제조자는 알려진 비정상 결과로 인해 위험한 상황을 초래할 수 있는 일련의 사건이 발생하는지 확인하기 위해 의료기기에 사용된 SOUP 항목의 버전과 관련된 SOUP 항목 공급자가 게시한 모든 비정상(anomaly) 목록을 평가해야 한다.

If failure or unexpected results from SOUP is a potential cause of the software item contributing to a hazardous situation, the manufacturer shall evaluate as a minimum any anomaly list published by the supplier of the SOUP item relevant to the version of the SOUP item used in the medical device to determine if any of the known anomalies result in a sequence of events that could result in a hazardous situation.

소프트웨어 아이템과 관련된 위해상황은 위험관리 파일에 문서화한다. 식별된 위해상황에 의해 발생할 수 있는 이벤트에 대해 위험관리 파일에 문서화한다.

The manufacturer shall document in the risk management file potential causes of the software item contributing to a hazardous situation.

7.2. 위험평가 (Risk Evaluation)

1. 소프트웨어의 경우 발생가능성은 다음과 같이 설정한다:
   • 위험 통제 이전에는 1.0(100%)로 설정한다.
   • 위험 통제 이후에는 0.5(50%)로 설정한다.
2. 소프트웨어 시스템의 심각성 기준에 따라 심각성 수준을 설정한다.
3. 위험 계산 방법:
   • 위험 수준 (Risk Level) = 발생가능성 정도(Probability) x 심각성 수준(Severity Level)
4. 위험 허용 기준
   • 허용 가능한 위험 수준 (AR, Acceptable Risk) = 2 이하
   • 허용할 수 없는 위험 수준 (UR, Unacceptable Risk) = 2 초과

1. Assign the probability of occurrence to
   • 1.0 (100%) before the risk control; and
   • 0.5 (50%) after the risk control.
2. Assign the severity level according to the severity criteria of the software system.
3. Calculate the risk level:
   • Risk Level = Probability * Severity Level
4. The criteria for risk acceptability
   • Acceptable Risk (AR) = 2 or less
   • Unacceptable Risk (UR) = more than 2

위에서, 소프트웨어 심각성 수준 기준은 다음과 같다:

In the above, the software severity level criteria are as follows:

Table: Software severity level criteria

Level	Severity	Description
5	Catastrophic	환자의 사망을 발생하는 수준 Results in Patient Death
4	Critical	영구적 손상 또는 치명적 상해를 발생하는 수준 Results in permanent impairment or life-threatening injury
3	Serious	전문적 의료시술이 필요한 상해 또는 손상을 발생하는 수준 Results in injury or impairment requiring professional medical intervention
2	Minor	전문적 의료시술이 필요 없는 일시적인 상해나 손상을 발생하는 수준 Results in temporary injury or impairment not requiring professional medical intervention
1	Negligible	불편 또는 일시적 곤란을 발생하는 수준 Inconvenience or temporary discomfort

7.3. 위험통제 (Risk Control)

제조자는 위험통제수단을 정의하고 문서화해야 한다. 위험통제수단이 소프트웨어의 기능 일부로 구현된 경우 다음과 같이 수행해야 한다:

1. 소프트웨어 요구사항에 위험통제수단을 포함시킨다.
2. 위험통제수단으로 제어하고 있는 위험에 근거하여, 위험통제수단의 구현에 기여하는 각 소프트웨어 항목에 소프트웨어 안전등급을 배정한다.

The manufacturer shall define and document risk control measures. If a risk control measure is implemented as part of the functions of a software item, the manufacturer shall:

1. include the risk control measure in the software requirements; and
2. assign to each software item that contributes to the implementation of a risk control measure a software safety class based on the risk that the risk control measure is controlling.

7.4. 위험통제수단의 검증 (Verification of Risk Control Measures)

문서화된 각 위험통제수단의 구현은 검증되어야 하며, 검증 결과를 문서화한다. 제조자는 위험통제수단을 검토하고, 위험통제수단이 새로운 위험상황을 초래할 수 있는지 확인하여야 한다.

제조자는 또한 다음과 같은 추적성 명시해야 한다:

1. 위해상황에서 소프트웨어 항목까지
2. 소프트웨어 항목에서 특정 소프트웨어 원인까지
3. 소프트웨어 원인에서 위험통제수단까지
4. 위험통제수단에서 위험통제수단 검증까지

The implementation of each risk control measure shall be verified, and this verification shall be documented. The manufacturer shall review the risk control measure and determine if it could result in a new hazardous situation.

The manufacturer shall document traceability of software hazards as appropriate:

1. from the hazardous situation to the software item;
2. from the software item to the specific software cause;
3. from the software cause to the risk control measure; and
4. from the risk control measure to the verification of the risk control measure.

7.5. 소프트웨어 변경의 위험 관리 (Risk Management of Software Changes)

제조자는 SOUP를 포함하여 의료기기 소프트웨어에 대한 변경을 분석해야 한다:

1. 추가적인 잠재적 원인이 위해상황에서 발생할 수 있는지
2. 추가적인 위험통제수단이 필요한지

The manufacturer shall analyze changes to the medical device software (including SOUP) to determine whether:

1. additional potential causes are introduced contributing to a hazardous situation; and
2. additional software risk control measures are required.