Risk Assessment for Validation

Risk Assessment for Validation 3/15 2.3 실시시기 RA 는 ‘실시시기’에 대하여 많이 생각해야 한다. 구분하기도 어렵도, 적용하기도 어렵다...

0 downloads 173 Views 86KB Size
Risk Assessment for Validation

Risk Assessment for Validation

1 서론 2 RA 란 ? 2.1 용어 2.2 대상 & 목적 2.3 실시시기 3 RA for Validation 3.1 원칙과 이점 3.2 역할과 책임 3.3 Validation 에 대해 3.4 RA 의 문서화 4 RA 방법 from GAMP4 4.1 공정 식별(Process Identification) 4.2 GxP 위험 식별(Identify GxP Risk) 4.3 영업위험 식별(Identify Business Risk) 4.4 위험발생상황 식별(Identify Risk Scenarios) 4.5 빈도 평가(Assess Likelihood) 4.6 악영향 평가(Assess the Severity of Impact) 4.7 위험등급 분류(Assign Risk Classification) 4.8 발견가능성 평가(Assess Probability of Detection) 4.9 위험순위 분류(Assign Risk Priority) 4.10 적절한 위험 경감 전략(Determine Appropriate Measures for Risk Mitigation) 첨부 : Risk Assessment Form

Version 1.0

Date 2004/1

Remark New

IVS 유재훈 [email protected] www.validation.co.kr 1/15

Risk Assessment for Validation

1 서론 최근 제약산업에서 Risk Assessment 또는 Risk Analysis, RA 라는 용어를 자주 접하게 된다. 여러 사람들이 실시하려고 하지만, 무엇을 해야 하고, 어떻게 해야 하며, 왜 해야 하는가 에 대한 논의가 부족하다고 생각된다. 이 글은 RA 에 대하여 이야기 한다. 하지만 RA 에 대하여 하나에서부터 열까지를 논하는 글이 아니라, 처음 RA 를 접하시는 분들이 기초적 인 내용을 이해하고, 좀더 올바른 RA 를 실시하기 위하여 고민해야 할 사항을 정리하려 한다. 특히 제약산업에서 관심 있는 GxP 와 Validation 을 위한 RA 에 중점을 두어 설명하기로 한다. 이 글은 다음 문서를 참고하였다. • ISPE GAMP Forum, GAMP4, The Good Automated Manufacturing Practice(GAMP) Guide for Validation of Automated System, ISPE, 2001.12 • ISPE GAMP Forum, ‘Risk Assessment for Use of Automated Systems Supporting Manufacturing Processes Part1 – Functional Risk’, Pharmaceutical Engineering, May/June 2003, Volume 23, Number 3 • 김경근, ‘Risk Analysis for Qualification & Validation’, surGMP, www.surgmp.com

2 RA 란 ? 2.1 용어 Risk Assessment 이거나 Risk Analysis 이거나 우리말로 하면 ‘위험평가’가 적당한 용어이다. ‘위험평가’란 용어는 의미가 명확하므로 오해의 소지가 없다고 판단된다. (그래도 ‘위험평 가’라는 용어가 익숙치 않으므로 본 문서에서는 RA 라고 사용한다.) RA 는 말 그대로 위험을 평가하는 작업이며, 결론적으로 평가된 위험을 피하기 위한 대 처방안을 만들거나, 위험을 줄일 수 있는 방법을 고민하는 작업이다.

2.2 대상 & 목적 RA 의 대상은 모든 것이 될 수 있다. 또한 RA 의 목적도 모든 것이 될 수 있다. 예를 들어, 제과점에서 판매하는 식빵에 대하여 RA 를 실시한다면 다음과 같은 것을 생 각해볼 수 있다. • 시장성을 위한 RA • 식빵위험성을 위한 RA • 식빵영향을 위한 RA 동일한 대상이라도 원하는 목적에 따라 다른 RA 를 실시해야 한다.

2/15

Risk Assessment for Validation

2.3 실시시기 RA 는 ‘실시시기’에 대하여 많이 생각해야 한다. 구분하기도 어렵도, 적용하기도 어렵다. RA 를 모호하고 이해하기 어렵게 만드는 요인이 시기에 따른 RA 이다. 최근에 RA 라는 용어가 난무하지만 RA 는 갑자기 나타난 신제품이 아니다. 우리가 지금 까지 계속적으로 했던 일을 조금 체계적으로 만든 것에 불과하다. 즉, ‘시장조사’, ‘신제품 조사’, ‘타당성검토’ 등은 모두 RA 로 생각할 수 있으며, 작게는 ‘적부판정’ 또는 ‘검토’도 RA 로 볼 수 있다. 그렇다면, 왜 RA 의 시기가 문제인가. 우리가 가지고 있는 보편적인 생각은 RA 는 무엇 을 수행하기 이전에 실시해야 한다고 생각한다. 실재로 대부분 이전에 실시한다. 하지만 이전에 실시하는 단계에도 여러 가지 경우를 생각해 볼 수 있다. 식빵의 경우를 생각하 면 • • • • • • • •

식빵을 만드는 제과점의 수익성 RA – 유동인규와 제과점 입지조건 고려 제빵기술자 인력수급 RA 식빵 제조공정 RA 식빵 종류와 크기 RA 식빵 제조위생 RA 불량식빵 처리 RA 식빵을 만들기 위한 제빵기기 RA 제빵기기 변경에 따른 RA

(쓰고 나니 복잡하군) 이렇게 많은 RA 중 어떤 RA 를 이야기 하는 것인지 분명하게 정해 야 한다. 만약, 누군가 ‘RA 를 실시 했습니까?’ 또는 ‘RA 가 필요한가요?’ 라고 질문을 한 다면 ‘언제, 무엇을 위하여 실시하는 RA 를 말하는 것인가요?’ 라고 다시 한번 질문을 해 야 한다. RA 란 매우 광범위하게 사용될 수 있는 수단이다. 사업초기에도 할 수 있고, 장치를 구 매할 때도 할 수 있고, 조직구조를 변경할 때도 사용할 수 있다. 그러므로 RA 는 단지 RA 를 수행여부만을 생각하지 말고 RA 의 실시시기와 목적을 같이 고민해야 한다.

3/15

Risk Assessment for Validation

3 RA for Validation RA 전체에 대하여 고려하면 너무 광범위하므로 제약산업에서 관심을 가지고 있는 Validation 에 초점을 맞춰 생각해 보기로 하자. 또한 특정 시스템을 구축하는 프로젝트를 진행중이라고 가정하자.

3.1 원칙과 이점 RA 를 실시하는 목적은 근본적으로 발생할 수 있는 위험을 피하여 손실을 최소화하고 이익을 최대화하는데 있다. 따라서 RA 는 다음의 원칙적인 질문에 따라 수행되어야 한다. • • • •

시스템이나 공정이 제품과 허용 안전에 중요한 영향을 주는 사항은 무엇인가? 시스템이나 공정이 영업활동에 중요한 영향을 주는 사항을 무엇인가? 시스템이 Validation 이 필요한가? 이 시스템을 위하여 어느 정도의 Validation 이 필요한가?

RA 의 이점은 당연히 손실의 최소화와 이익의 최대화이다. 특히 우리가 관심을 가지고 있는 Validation 에 경우, 시스템 하나부터 열까지, 빠뜨리지 않고 모두 검사한다는 것은 비현실적이다; 그러므로 중요한 영역에 노력을 집중해야 한다. 예를 들어, RA 는 특정 시 스템이나 공정에 대해 필요한 Validation 항목이 무엇인지를 결정하도록 도와준다. 또한 RA 를 상세하게 한다면 Validation 에 필요한 검사를 얼마나 엄격하게 적용해야 되는가를 결정할 수 있다. 그러나 Validation 수준을 결정하는 것은 자신의 판단, 경험, 규제기관의 요구사항에 따라 사용자가 결정해야 한다.

4/15

Risk Assessment for Validation

3.2 역할과 책임 역할과 책임을 구분하는데 있어 전체 RA 를 생각하면 너무 광범위하므로 특정 시스템을 구축하는 프로젝트를 진행중이라고 가정하자. RA 는 프로젝트 팀 전체 구성원의 책임의 일부다. 그러나 각 구성원은 평가 실시 과정에 서 서로 다른 역할을 담당한다. System Owner 시스템 소유자는 시스템 운전과 시스템 유지관리에 대한 궁극적인 책임이 있다. 시스템 소유자는 GxP 운영 절차의 일부로 식별된 위험에 대한 조사와 평가 책임이 있다. RA 문 서의 승인자이다. Business Owner 전체적인 영업 절차에 중요하게 식별된 위험에 대한 조사와 평가의 책임 있다. RA 문서 의 승인자이다. System Manufacture Personnel 시스템의 제작과 이행의 결과로 식별된 위험에 대한 조사와 평가 책임이 있다. Operations Personnel 기술적 이행의 결과로 식별된 위험에 대한 조사와 평가 책임이 있다. Quality Assurance 규제적 준수와 회사의 품질 표준과 정책의 관리에 관련된 위험에 대한 조사와 평가 책임 이 있다. RA 문서의 승인자이다.

3.3 Validation 에 대해 제약산업에서 Validation 이 필요한 단일 기기나 단일 시스템을 구축할 경우 RA 는 다음과 같은 단계에서 수행해야 한다. • • • • • • •

개념설계 타당성 검토 URS 를 작성할 때 공급자를 평가할 때 FS 를 검토할 때 설계검토를 할 때 시스템에 주요한 변경이 있을 때

또한 Validation 을 수행해야 한다면 Validation 과 RA 는 아래 그림과 같은 상관관계를 가 진다.

5/15

Risk Assessment for Validation [그림] Risk Assessment and the Validation Process Feasibility Stage

R

Is Validation Required

URS

No

End Process Decision documented

Yes Response to User Requirements Specification

Determine scope of Validation

R

Supplier Assessment & Purchase

Functional Spec & Design

Document Justification of Validation

R

Test System

Update Validation Plan

Develop Test plans

R Validated System

Change Control

R

Validation Activities

Project Implementation Activities R

= Risk Assessment (recommended)

R

= Risk Assessment (optional)

위에서 언급한 것과 같이 RA 는 여러 단계에서 실시해야 한다. 그러므로 RA 를 특정단계 에서만 실시해야 한다고 생각하는 것은 올바르지 않고, RA 를 지칭할 때도 어떤 단계의 RA 라고 이야기 해야 의미가 명확하게 전달된다. 하지만, 위와 같은 단계마다 RA 를 실 시하려면 엄청난 노력과 시간을 요구하게 된다. 각 경우에 따른 합리적인 선택이 요구된 다.

6/15

Risk Assessment for Validation

3.4 RA 의 문서화 RA 는 어떤 형태로 문서화해야 하는가? RA 의 문서화는 머리 아픈 문제이다. 일반적으로 문서화한다는 것은 행위에 대한 기록이므로 RA 의 실시시기와 관련 있다. 만약, URS 가 만들어지고 검토자가 서명전에 위험에 대한 자신의 의견을 서명 옆에 기술한다면 이것은 RA 라고 할 수 있을까? 아주 넓은 의미에서 본다면 RA 라고 판단할 수 있지만 일반적으 로 RA 라고 보기 어렵다. 즉, RA 는 공식적인 업무절차로 정해지고 수행되고 문서화되어 야 한다. VMP(Validation Master Plan), VP(Validation Plan), PP(Project Plan), SOP(Standard Operation Procedure) 등에서 공식적인 업무단계로 지정하고 인력과 자원을 할당해야 한다. 그러나 이렇게 업무절차를 정의하는 것은 대부분 형식적이고 제한적인 규제사항이 되고 만다. 필요한 단계에서 적절한 수준으로 이루어져야 하는 RA 를 특정단계에서만 실시해 야 하는 절차로 만들어 성공적인 업무수행을 방해할 수 있으므로 주의해야 한다.(때로는 번거러운 절차가 되기도 한다) RA 보고서는 다음 사항을 포함해야 한다. • • • • • •

공정 식별 위험 식별 위험이 없거나 허용 가능하다는 정당성 위험발생상황 위험경감 전략 만약, 위험을 피할 수 없을 경우 조치사항

RA 보고서는 두 가지 형태로 작성될 수 있다. 첫째는 ‘위험경감 전략’을 수립하고 보고서 로 작성하는 것이다. 이러한 RA 보고서를 일반적인 형태로 볼 수 있다. 두번째는 ‘위험경 감 전략’을 수립한 이후 조치사항을 관리하고 그 이후 위험도가 낮아진 결과까지 RA 보 고서에 기록하여 남기는 것이다. 이 방식은 이후 보완조치까지 관리하므로 공정 및 프로 젝트 관리 차원에서 매우 좋은 방법이지만 문서관리가 어렵고 진행과정이 너무 길어서 보고서로써 사용도가 떨어진다. 추천하는 방법은 첫번째 방법과 같이 RA 보고서를 작성 하고 이후 프로젝트 종료 시점이나 공정개선이후 “RA 조치사항’를 별도의 보고서로 만드 는 것이 좋다. 4 장에서 설명할 RA 실시 방법에 적용할 수 있는 ‘Risk Assessment Form’을 첨부하였다.

7/15

Risk Assessment for Validation

4 RA 방법 from GAMP4 RA 를 실시하는 방법은 여러 가지 있다. 어떤 것을 사용해도 무방하다. 본 글은 GAMP4 에서 소개된 방법을 소개한다. 이 방법은 시스템의 기능과 단위장치별로 구분하여 Risk Priority(위험우선순위)를 판단하는 방법이다. [그림] Overview of the Risk Assessment Process Process Identification

Business GxP Yes

No

Document in Assessment Form

Exclude from Validation

Justification for Non-GxP status

Identify Risk Scenarios

Assess Likelihood of Fault Condition

Assess Severity of Impact

Assign Risk Class

Assess Probability of Detecting Fault Condition

Document Risk in Assessment Form

Determine Mitigation Strategy

Document in Assessment Form

Risk Name GxP Relevance Risk Likelihood Probability of Detection Severity of Impact Risk Class

★ Response Summary

Initiate Risk Management Activities

8/15

Risk Assessment for Validation

4.1 공정 식별(Process Identification) 전체 시스템을 하나의 독립적인 단위로 볼 수 있는 기능과 단위장치로 분리하여 정리해 야 한다. 각 기능과 단위장치는 명확하고 의미 있게 식별해야 하며, 하나의 항목에 여러 개를 중복해서는 않된다.

4.2 GxP 위험 식별(Identify GxP Risk) 이 단계는 각 기능과 단위장치가 일련의 GxP 기준에 상반된다고 판단될 때 위험이 있는 지 여부를 판단한다. 식별되는 위험의 예는 아래와 같다. 하지만 아래 항목에만 국한되는 것은 아니다. • The pharmaceutical quality of the finished product (including clinical supplies): - Incorrect composition - Raw materials errors - Packaging materials errors - Integrity of QC laboratory results - Incorrect batch status - Failure of storage conditions - Batch recalls - Lot traceability - Labeling errors • The safety of patients and consumers: - Adverse reactions - Mix-up involving samples (finished product and clinical trials) - Inadequate complaints handling or monitoring • Incorrect data for the support of regulatory submissions: - Integrity of development laboratory results - Statistical evaluations - Calculation of results from test data - Composition of the dossier 프로젝트 팀은 각 기능과 단위장치 별로 GxP 영향을 평가해야 한다. 논의의 결과는 평가 형태로 문서화해야 한다. 만약 특정 기능과 단위장치가 GxP 위험이 없다고 판단된다면, 이런 의견의 정당성을 평 가 형태로 문서화해야 한다. 이것은 나중에 유용하게 사용될 수 있다. (만약 제 3 자에 의 한 특정 Validation 활동에 대한 설명이 필요할 때)

4.3 영업위험 식별(Identify Business Risk) RA 절차의 두번째 요소는 시스템 기능과 단위장치가 영업적인 관점에서 위험이 있는지 여부를 결정하는 것이다. 영업적인 위험은 이 문서를 보는 주된 독자인 QA 나 엔지니어 가 판단하기 어렵다. 때로는 이 항목을 무시하거나 가볍게 생각하는 경향이 있지만, 이 항목 역시 진지하게 판단해야 한다. 9/15

Risk Assessment for Validation

식별되는 위험의 예는 아래와 같다. 하지만 아래 항목에만 국한되는 것은 아니다. • Corporate reputation - Adverse publicity - Shareholder responsibilities - Earnings impact - Competitive advantage • Brand recognition - Customer loyalty - Supply chain loyalty • Risk to manufacturing(process) equipment - Equipment downtime - Equipment damage - Cost of replacement equipment parts - Potential for injury (Health and Safety) 만약 특정 기능과 단위장치가 영업 위험이 없다고 판단된다면, 이런 의견의 정당성을 평 가 형태로 문서화해야 한다.

4.4 위험발생상황 식별(Identify Risk Scenarios) 특정 기능과 단위장치가 GxP 위험이나 영업위험이 있다고 판단되면, 다양한 위험발생상 황(Risk Scenarios)를 만들어내야 한다. (위험발생상황에 따라 발생한 사건을 ‘이벤트’라고 지칭하자) 위험발생상황(Risk Scenarios)를 식별하기 위해서는 해당 분야에 경험과 지식이 풍부한 전 문가가 필요하다. 대부분의 위험은 복잡한 형태로 나타나다. 하나의 기능과 단위장치는 많은 종류의 위험에 영향을 미칠 수 있으며, 여러 가지의 사소한 문제가 중요한 위험으 로 나타날 수도 있다.

4.5 빈도 평가(Assess Likelihood) 다음 단계는 위에서 식별한 위험발생상황에 좋지않은 이벤트가 발생할 빈도(Likelihood)를 결정하는 것이다. 주어진 일정기간(일, 월, 연)동안이나 일정량의 업무동안 좋지않은 이벤 트가 발생할 빈도를 고려해야 한다. 발생할 빈도를 추정하는 방법으로 다음과 같은 기준 을 제시한다. • Low

: 10000 번의 작업동안 한번 발생하는 이벤트

• Medium

: 1000 번의 작업동안 한번 발생하는 이벤트

• High

: 100 번의 작업동안 한번 발생하는 이벤트

만약, 좋지않은 이벤트는 빈도를 추측할 수 없다면, 별도의 문서적인 증거가 없다면 가장 높은 ‘High’로 판단해야 한다. 프로젝트나 업무가 진행됨에 따라 더 많은 정보가 얻어진 다면, 이 값은 필요에 따라 재평가될 수 있다.

10/15

Risk Assessment for Validation

4.6 악영향 평가(Assess the Severity of Impact) 이 단계는 좋지않은 이벤트가 발생할 경우 미치는 영향(Impact)를 판단하는 작업이다. RA 는 즉각적인 영향을 식별하는 것 뿐만 아니라 오랜 기간과 넓은 영업 범위에 영향을 미 치는 것에도 판단해야 한다. 이러한 영향은 규제 준수 영향, 제정 영향, 고객과 공급자의 회사평판을 포함하여 다양한 문제에 고려해야 한다. 위험발생의 영향은 다음과 같이 평가한다. • Low

: 단기간 적은 부정적인 영향 예상.

• Medium

: 단기-중기간 중간정도 영향이 예상.

• High

: 매우 중요한 부정적인 영향이 예상, 영향은 중요하고 장기간의 부정적인 효과와 잠재적이고 파국적인 단기간의 효과가 예상

4.7 위험등급 분류(Assign Risk Classification) 위험발생 빈도(Likelihood)와 영향(Impact)을 이용하여 해당 위험의 등급(Class)을 분류할 수 있다. 위험등급(Class)은 임시적인 평가결과로 이후 우선순위(Priority)를 평가하는 자료 가 된다. 분류는 아래 그림과 같이 한다. [Level ONE]이 [Level THREE]보다 위험하다. [그림] Risk Classification

High

Medium

Low

Risk Likelihood

Business Impact

Level ONE High Level TWO Medium Level THREE Low

11/15

Risk Assessment for Validation

4.8 발견가능성 평가(Assess Probability of Detection) 평가 절차에서 이 단계는 위험 이벤트를 인식하거나 다른 수단을 통하여 찾아낼 수 있는 가를 평가하는 것이다. [Level ONE]의 위험일지라도 찾아낼 가능성이 높다면 심각한 위험 이 아니다. 왜냐하면 문제를 빨리 인식하고 적절한 보완조치로 문제의 영향을 완화 시키 기 때문이다. 반대로 오류를 찾아낼 가능성이 낮다면, 위험영향이 증가한다. 따라서 다른 절차, 설계, 구현을 검토해야 한다. 위험 발견의 가능성은 다음과 같이 추정할 수 있다: • Low

: 오류상태 발견을 거의 인지할 수 없다 (예를 들어, 3 번 작업이나 작동에 서 1 번보다 낮게 발견)

• Medium

: 오류상태를 어느 정도 인지할 수 있다. (예를 들어, 2 번 작업이나 작동에 서 1 번 발견)

• High

: 오류상태 발견을 즉각적으로 인지할 수 있다 (예를 들어 1 번 작업이나 작동에서 1 번 발견)

4.9 위험순위 분류(Assign Risk Priority) 위험분류(Class)와 발견가능성(Detection)의 조합을 이용하여, 매우 민감한 영역에 대하여 각 좋지않은 이벤트와 관련된 위험의 우선순위(Priority)를 매기는 것이 가능하다. 아래 그 림과 같이 분류할 수 있다. 위험순위가 높을수록 우선적으로 처리해야 하는 위험이다. [그림] Risk Priority

High

Medium

Low

Probability of Detection

Risk Classification

HIGH priority 1 MEDIUM priority 2 LOW priority 3

12/15

Risk Assessment for Validation

[표] 위험순위 요약표 Likelihood

Impact

Detection

Classification

Priority

Low Low Low Low Low Low Low Low Low Medium Medium Medium Medium Medium Medium Medium Medium Medium High High High High High High High High High

Low Low Low Medium Medium Medium High High High Low Low Low Medium Medium Medium High High High Low Low Low Medium Medium Medium High High High

Low Medium High Low Medium High Low Medium High Low Medium High Low Medium High Low Medium High Low Medium High Low Medium High Low Medium High

3 3 3 3 3 3 2 2 2 3 3 3 2 2 2 1 1 1 2 2 2 1 1 1 1 1 1

Medium Low Low Medium Low Low High Medium Low Medium Low Low High Medium Low High High Medium High Medium Low High High Medium High High Medium

13/15

Risk Assessment for Validation

4.10 적절한 위험 경감 전략(Determine Appropriate Measures for Risk Mitigation) 위험위선순위(Priority)가 결정되었다면, 해당 위험을 피하기 위한 대처방안을 만들거나, 위험을 줄이는 방법을 고민해야 한다. 오류상태의 위험 우선순위는 적절한 위험 완화방법을(Validation 노력에 초점을 맞추어) 선택하여 사용해야 한다. 예를 들어, 위험 분류가 Level 3 이라도, 발견수준이 낮다면 매우 취약한 영역이다.(HIGH priority) 이런 영역에 집중해서 전체 오류 가능성을 낮추어 시스 템의 품질을 구축해야 한다. 위험 수준을 변경하는 여러 가지 완화 전략이 있다. 이것은 주어진 시스템 적절하게 사용해야 한다. 이런 방법이 아래 표에 정리되어 있다. 하지만 아래 항목에만 국한되는 것은 아니다. [표] 위험 경감 전략 1 공정이나 시스템의 설계 변경 공정설계 변경 - 위험한 공정을 제거하거나 수정한다.(Likelihood ↓ , Impact ↓ ) - 시스템의 위험을 알 수 있는 독립적인 검사를 추가한다.(Detection ↑ ) - 추가적인 작업자 교육을 통하여 위험을 줄인다.(Likelihood ↓ ) - 해당 작업을 실시하기 전에 사전검사를 추가하도록 SOP 를 변경한 다.(Likelihood ↓ , Detection ↑ ) 외부(External) 방식 도입 - 오류나 위험을 알 수 있는 추가적인 외부의 장치나 방식을 도입한다. (이중 검 사 등).(Detection ↑ ) - 위험상태에서 지원할 수 있는 외부에 장치나 방식을 도입한다.(Impact ↓ ) 제품이나 시스템 설계 변경 - 오류나 위험에 대처할 수 있는 인정된 방법이나 도구를 사용한다. 2 프로젝트 전략 변경 프로젝트 구조의 재검토 - 프로젝트 구성원의 경험과 자질에 대한 재평가 이미 구축된 품질의 재평가 - 이미 승인되고 통제되는 문서를 식별된 위험을 반영하도록 새로 만들거나 제 거한다. 3 Validation 방법의 변경 검사 증가 - 다양한 Validation 단계에(개발기간의 특정 검사를 포함하여) 검사의 범위와 수 준을 증가시키다. 검사 감소 - 다양한 Validation 단계에서 검사의 범위와 수준을 감소시킨다.(매우 낮은 위험 일 때) 4 위험제거 회피 - 위험이 매우 높으므로 신규 방법을 적용하지 않는다. 문서화된 위험 경감 전략은 Validation 접근방법의 타당성으로 사용된다. 세부사항으로는 완화시키는 작업을 할 책임자를 포함해야 하고 프로젝트 팀의 구성원은 RA 문서를 승인 해야 한다.

14/15

Risk Assessment for Validation

첨부 : Risk Assessment Form Project Title / Risk Assessment Overview

Project Number

Assessment Scope / Assumptions Mode Function

Sub-Function

(Machine Component)

(Machine Component)

Measures

Assessment of Risk Relevance (GxP / Business)

Risk Scenarios

Likelihood Impact

Class

Detection

Risk Assessment Approved by:

15/15

Priority