automated system validation 자동화자동화 시스템시스템시스템 … system...

Automated System Validation

1/23쪽

Automated System ValidationAutomated System ValidationAutomated System ValidationAutomated System Validation

자동화자동화자동화자동화 시스템시스템시스템시스템 검증검증검증검증

Version 1.0 Version 1.0 Version 1.0 Version 1.0 – 2002/12 2002/12 2002/12 2002/12

자동화 시스템 검증에 대한 내용을 다루고 있습니다.

국내에서 Computer Validation 이라 불리는 분야입니다.

Case Study 를 추가하여 실질적인 이해를 돕고 있습니다.

Case Study 에서 언급되는 문서의 Sample 은 다음주소에서 다운로드 받을 수 있습

니다.

http://www.validation.co.kr/references/gamp.htm

본 문서의 내용에 이의가 있거나 질문이 있으신 분은 연락해 주시기 바랍니다

IVSIVSIVSIVS

유재훈유재훈유재훈유재훈

[email protected]

www.validation.co.kr


2/23쪽

목목목목 차차차차

1. Automated System Validation (1. Automated System Validation (1. Automated System Validation (1. Automated System Validation (자동화자동화자동화자동화 시스템시스템시스템시스템 검증검증검증검증)))) …………………………………………………………………………………… 3 3 3 3

1.1 1.1 1.1 1.1 무엇인가무엇인가무엇인가무엇인가 ? ? ? ?

1.2 1.2 1.2 1.2 왜왜왜왜 해야해야해야해야 하는가하는가하는가하는가 ? ? ? ?

1.3 1.3 1.3 1.3 무엇을무엇을무엇을무엇을 해야해야해야해야 하는가하는가하는가하는가 ? ? ? ?

1.4 Validation 1.4 Validation 1.4 Validation 1.4 Validation 대상의대상의대상의대상의 평가방법평가방법평가방법평가방법

1.5 1.5 1.5 1.5 실제로실제로실제로실제로 가능한가능한가능한가능한 경우경우경우경우

2. 2. 2. 2. Automated System Validation Life CycleAutomated System Validation Life CycleAutomated System Validation Life CycleAutomated System Validation Life Cycle ……………………………………………………………………………………………………………………………… 9 9 9 9

2.1 Validation Life Cycle2.1 Validation Life Cycle2.1 Validation Life Cycle2.1 Validation Life Cycle

2.2 Automated System Validation Life Cycle2.2 Automated System Validation Life Cycle2.2 Automated System Validation Life Cycle2.2 Automated System Validation Life Cycle 의의의의 책임책임책임책임

2.3 2.3 2.3 2.3 대상시스템대상시스템대상시스템대상시스템 확인확인확인확인 - Identify System - Identify System - Identify System - Identify System

2.4 URS2.4 URS2.4 URS2.4 URS

2.5 2.5 2.5 2.5 검증전략검증전략검증전략검증전략 결정결정결정결정

2.6 2.6 2.6 2.6 계획계획계획계획

2.7 2.7 2.7 2.7 시스템시스템시스템시스템 규격규격규격규격

2.8 2.8 2.8 2.8 시스템시스템시스템시스템 설명설명설명설명

2.9 2.9 2.9 2.9 소프트웨어소프트웨어소프트웨어소프트웨어 개발과개발과개발과개발과 검토검토검토검토

2.10 2.10 2.10 2.10 검사검사검사검사

2.11 Validation 2.11 Validation 2.11 Validation 2.11 Validation 보고서보고서보고서보고서

2.12 2.12 2.12 2.12 검증상태검증상태검증상태검증상태 유지유지유지유지

3. 3. 3. 3. Automated System ValidationAutomated System ValidationAutomated System ValidationAutomated System Validation Case Study Case Study Case Study Case Study ……………………………………………………………………………………………………………………………… 16 16 16 16

3.1 Validation 3.1 Validation 3.1 Validation 3.1 Validation 대상대상대상대상

3.2 Validation3.2 Validation3.2 Validation3.2 Validation 대상의대상의대상의대상의 평가평가평가평가


3.4 3.4 3.4 3.4 Validation Master PlanValidation Master PlanValidation Master PlanValidation Master Plan

3.5 3.5 3.5 3.5 Validation Plan Validation Plan Validation Plan Validation Plan or or or or Validation ProtocolValidation ProtocolValidation ProtocolValidation Protocol

3.6 3.6 3.6 3.6 User Requirements Specification (URS)User Requirements Specification (URS)User Requirements Specification (URS)User Requirements Specification (URS)

3.7 3.7 3.7 3.7 Functional Specification (FS)Functional Specification (FS)Functional Specification (FS)Functional Specification (FS)

3.8 3.8 3.8 3.8 Software Design SpecificationSoftware Design SpecificationSoftware Design SpecificationSoftware Design Specification

3.9 3.9 3.9 3.9 Coding ConventionCoding ConventionCoding ConventionCoding Convention

3.10 3.10 3.10 3.10 Software Review PlanSoftware Review PlanSoftware Review PlanSoftware Review Plan

3.11 3.11 3.11 3.11 Software Review ReportSoftware Review ReportSoftware Review ReportSoftware Review Report

3.11 3.11 3.11 3.11 Acceptance Test PlanAcceptance Test PlanAcceptance Test PlanAcceptance Test Plan

3.12 3.12 3.12 3.12 Acceptance Test ReportAcceptance Test ReportAcceptance Test ReportAcceptance Test Report

3.13 3.13 3.13 3.13 설명서설명서설명서설명서


3/23쪽

1. Automated System Validation (1. Automated System Validation (1. Automated System Validation (1. Automated System Validation (자동화자동화자동화자동화 시스템시스템시스템시스템 검증검증검증검증))))

현재 의료보건 분야의 제조공정이나 실험실, 관리부서 등에서 수많은 Automated System

을 사용하고 있습니다. Automated System 이라고 하면 상당히 거창한 것을 생각하시 분

이 많으신데, 일반적인 PC 나 휴대용 측정장비, 온도조절기 등 거의 모든 장비를 포함합

니다. 그러나 이러한 장비에 대해서는 Validation 을 하지 않은 상태에서 사용하고 또한

필요성도 별로 느끼지 못했습니다. 그러나 최근의 추세는 Automated System 에 대한

Validation 을 강조하고 있으면 FDA 의 21 CFR Part 11 이라는 강력한 법령으로 제약업계

를 압박하고 있습니다.

본 강의는 일반적인 Validation 에 대한 전반적인 이해를 하고 있는 의료보건 분야의 실

무자를 대상으로 Automated System 에 대한 전반적인 이해를 돕기를 위하여 만들었습니

다.

1.1 1.1 1.1 1.1 무엇인가무엇인가무엇인가무엇인가 ? ? ? ?

Automated System Validation 은 제약, 생명공학, 의료장비를 포함하는 의료보건 제품의

품질, 안전, 식별 유효성에 관련된 Automated System 의 Validation 을 말합니다. 구체적

으로 자동화 생산설비, 자동화 실험설비, 자동화 의료장비, 자동화 측정장비, 공정제어

시스템, IT 시스템 등 모든 것을 포함합니다.

이쪽 분야에 관련된 단체로는 ISPE 산하 GAMP(Good Automated Manufacturing Practice)

Forum 이 있으며 GAMP Form 에서는 이 분야에 대한 지침서를 발간합니다. 2001 에 네번째

지침인 ‘GAMP 4 ‘를 일부 발표하였으면 추가 자료를 계속해서 발표할 것으로 보입니다.참고하시면 도움이 될 것입니다.

국내에서는 이쪽분야를 Computer Validation 이라는 관용어로 지칭하는 경우가 많이 있

습니다. 그런데 이 용어는 대상이 분명하지 않아 혼동의 소지가 있습니다. 미국이나, 유

럽 쪽에서도 Computer Validation 이라는 용어는 사용을 피하고 있으니 여러분도

Automated System Validation 이라는 용어를 사용하는 것이 좋겠습니다.

1.2 1.2 1.2 1.2 왜왜왜왜 해야해야해야해야 하는가하는가하는가하는가 ? ? ? ?

Automated System Validation 을 왜 해야 할까요. 우선 관련된 법령을 살펴봅시다.

21 CFR Part 211.68 Automatic, mechanical, and electronic equipment

21 CFR Part 11 Electronic Records; Electronic Signatures

21 CFR Part 820.30(a) Design controls

21 CFR Part 820.70(i) Production and process controls

Orange Guide1 Annex 11 Computerized Systems

Orange Guide Annex 18 5.4 Computerized Systems

미국과 유럽에는 위와 같은 법령이 있습니다. 하지만 다른 분야에 비하여 실재적인 법령

1 Orange Guide : Rules and Guidance for Pharmaceutical Manufacturers and Distributors 1997incorporation EC guide to good manufacturing practice(GMP) and good distribution practice, and EC

directives on good manufacturing practice and wholesale distribution


4/23쪽

은 매우 적은 것을 알 수 있습니다. 그럼 법령이 적으니 대충대충 적당히 해도 될까요?

전체적인 GMP 의 관점에서 생각해 봅시다.

위의 그림은 항생제 제조공정을 예로 들고 있습니다. 자동화 도입 이전에 모든 공정이

GMP 의 대상이며 Validation 을 실시해야 됩니다. 이와 마찬가지로 Automated System 을

도입한 이후 모든 공정에도 Validation 을 실시해야 됩니다. 초록색으로 표시된

Automated System 도 예외일수 없습니다.

즉, Automated System 을 직접적으로 규제하는 법령을 미비하지만 기존 Validation 대상

을 Automated System 으로 대치했을 경우 Validation 을 실시해야 합니다. 물론 기존의

Validation 되지 못한 Automated System 또한 Validation 대상입니다.

1.3 1.3 1.3 1.3 무엇을무엇을무엇을무엇을 해야해야해야해야 하는가하는가하는가하는가 ? ? ? ?

무엇을 해야 하는가는 명확합니다. 결론부터 이야기 하자면 Validation Life Cycle 에

따라 업무를 진행하고 차곡차곡 문서를 만드는 것 입니다. 그럼 Validation Life Cycle

은 무엇일까요? 말 그대로 이며, 또한 대부분 알고 계시는 내용입니다. Validation Life

Cycle 에 대한 세부항목에 대한 자세한 내용은 다음 강의에서 다루도록 하겠습니다. 여

기서는 전체적인 관점에서 생각해보도록 하겠습니다. 아래 그림은 Validation Life

Cycle 의 전형적인 모습입니다.


5/23쪽

그림에서 보면 크게 왼쪽은 계획, 오른쪽은 검사, 중간은 구현 부분입니다. 이 구조는

구현 부분을 중심으로 V 자로 되어 있습니다. 오른쪽은 평소에 자주 이야기 하는 IQ, OQ,

PQ 입니다. 이 그림을 잘 보면 왼쪽 부분을 오른쪽 부분에서 빠짐없이 검사하고 있습니

다.

이렇듯 하나의 제품(자동화 시스템뿐만 아니라, 모든 제품)을 생산하는데 있어서

Validation 이라는 것은 계획에 상응하는 검사를 실시하고 문서화하는 작업이며

Validation Life Cycle 이라 함은 이러한 일련의 과정입니다. Validation Life CycleValidation Life CycleValidation Life CycleValidation Life Cycle 을을을을

구성하는데구성하는데구성하는데구성하는데 중요한중요한중요한중요한 점은점은점은점은 계획과계획과계획과계획과 검사가검사가검사가검사가 빠짐없이빠짐없이빠짐없이빠짐없이 연결되어야연결되어야연결되어야연결되어야 한다는한다는한다는한다는 점입니다점입니다점입니다점입니다.... 만약 위

의 그림 중간의 설계와 검사를 연결하는 건을 없다면 그건 잘못된 Validation Life

Cycle 이라 할 수 있습니다.

현재 대부분의 시설(반응기, 공조기, 헤파필터 등)은 위의 그림과 같은 전형적인

Validation Life Cycle 로 Validation 되고 있으며, 거의 공식적이 Validation Life

Cycle 로 받아들이고 있습니다. 그런데 왜왜왜왜 Validation Life Cycle Validation Life Cycle Validation Life Cycle Validation Life Cycle 에에에에 대하여대하여대하여대하여 언급하고언급하고언급하고언급하고 있있있있

을까요을까요을까요을까요? ? ? ? 이유는이유는이유는이유는 Automated System Validation Automated System Validation Automated System Validation Automated System Validation 에서는에서는에서는에서는 위와위와위와위와 같은같은같은같은 전형적인전형적인전형적인전형적인 Validation Validation Validation Validation

Life CycleLife CycleLife CycleLife Cycle 을을을을 따르지따르지따르지따르지 않기않기않기않기 때문입니다때문입니다때문입니다때문입니다....

이러한 차이는 Validation 분야에서 사용하는 용어와 소프트웨어 공학에서 사용하는 용

어가 다르기 때문이며, 근본적으로 업무절차가 다르기 때문입니다.

간단한 예로 차이로 알아봅시다.

상황은 회사에 문서관리시스템을 도입하기 위하여, 문서관리시스템을 개발하고, 이제 사

용자용 프로그램을 각 사원들의 PC 에 설치할 단계라고 생각합시다. 프로그램을 PC 에 설

치하는 것을 ‘인스톨’이라고 하는데 MS-Word 나 아래한글처럼 프로그램을 인스톨한 후 해당 파일이 PC 에 복사되고 적절하게 설정된 것을 확인했습니다.

이 작업은 IQ 일까요? IQ 란 승인된 설계사양과 일치한다는 문서화된 Validation 입니다.

그럼 프로그램을 인스톨한 것을 어떤 과정일까? 위에서 제시된 전형적인 Validation

Life Cycle 에서 적당한 위치를 찾기란 어렵습니다. 이런 문제 때문에 Validation Life

Cycle 은 전형적인 모습에서 변형됩니다. 아래 두개의 그림은 Automated System 에서 전

형적인 IQ, OQ, PQ 에 대응하는 작업을 나타내고 있습니다.


6/23쪽

위 그림에서와 같이 기본적인 형태에서 대상에 따라 복잡하게 변하는 것을 알 수 있습니

다. 따라서 고민거리가 생깁니다. 그럼 어떤 Validation Life Cycle 을 적용해야 하는가

입니다. 그런데 이 문제에 대해서 FDA 나 GAMP 4 에서는 특정한 Validation Life Cycle

을 지정하지도 강요하지도 않고 자유로운 Validation Life Cycle 을 권장합니다. 즉즉즉즉, , , , 대대대대

상에상에상에상에 따라따라따라따라 Validation Life Cycle Validation Life Cycle Validation Life Cycle Validation Life Cycle 을을을을 만들어만들어만들어만들어 사용하라는사용하라는사용하라는사용하라는 이야기이야기이야기이야기 입니다입니다입니다입니다.... 이건 현실적으

로 상당한 어려운 작업으로 작업대상과 Validation 에 대한 양쪽의 지식을 요구합니다.

만약, Automated System Validation 에서는 Validation Life Cycle 을 만드셨다면 모든

작업의 1/3 을 했다고 할 수 있을 정도로 중요한 작업입니다. 신중하고 많은 노력을 들

여서 Validation Life Cycle 를 만들어야 합니다.

Validation Life Cycle 을 만드셨다면 그것에 따라 작업을 진행하면 됩니다.


7/23쪽

마지막으로 해야 할 일이 또 있습니다. Validation 상태의 유지입니다. 이것에 대한 내

용도 당연히 Validation Life Cycle 에 포함되어야 합니다. 다음 목록은 Validation 상

태 유지를 위하여 해야 할 작업입니다. 2-3 개를 제외하면 다른 장치와 동일한 내용입니

다.

Operational Plans and Procedures

Training

Problem Management and Resolution

Service Level Agreements

System Management

Backup and Recovery

Configuration Management

Operational Change Control

Security Management

Performance Monitoring

Record Retention, Archiving and Retrieval

Business Continuity Planning

Periodic Review and Evaluation

System Retirement

1.4 Validation 1.4 Validation 1.4 Validation 1.4 Validation 대상의대상의대상의대상의 평가방법평가방법평가방법평가방법

Automated System 을 Validation 하려면 해당 대상이 어느 정도 규모인가를 판단해야 하

는데 막상 접하게 되면 조금 막막합니다. 간단하게 다음 2 가지 질문으로 해당 작업의

규모를 어느 정도 예상할 수 있습니다.

하드웨어를 포함하는가?

Electronic Records / Electronic Signatures 를 포함하는가?

첫번째 고려사항으로 만약 하드웨어가 포함되어 있다면 소프트웨어와 별도로 하드웨어에

대한 Validation 이 필요하며 최종적으로 소프트웨어와 하드웨어의 통합 Validation 이

필요합니다. 따라서 작업의 양이 두배 이상 늘어나게 됩니다.

두번째 고려사항으로 Electronic Records(이하 ER) / Electronic Signatures(이하 ES)를

포함하게 되면 FDA 의 법령인 21 CFR Part 11 을 준수해야 합니다. 이 작업은 상당히 까

다로운 작업이며 다양한 추가 작업을 해야 합니다. 더욱이 ER 때문에 Backup 등

Validation 상태 유지에 더 많은 노력이 필요합니다.

1.5 1.5 1.5 1.5 실제로실제로실제로실제로 가능한가능한가능한가능한 경우경우경우경우

Automated System Validation 의 크게 다음과 같이 구분할 수 있습니다.

Case 1Case 1Case 1Case 1 : 오직 소프트웨어만

Case 2Case 2Case 2Case 2 : 소프트웨어와 주문제작 하드웨어

Case 3Case 3Case 3Case 3 : 소프트웨어, 범용 하드웨어, ER/ES

Case 4Case 4Case 4Case 4 : 소프트웨어, 주문제작 하드웨어, ER/ES

Case 1 은 가장 쉬운 경우로 VBA 로 프로그램된 엑셀시트 등이 있습니다.

Case 2 는 하드웨어가 포함된 경우로 제어기, 휴대용 측정장비, 의료장비 등이 이 경우


8/23쪽

에 포함됩니다.

Case 3 은 일반적인 IT System 이며 이 경우 범용으로 생산된 컴퓨터(Server, PC)가 사용

되므로 하드웨어 Validation 에 대한 작업을 줄일 수 있습니다.

Case 4 는 가장 어려운 대상으로 DCS, SCADA 등이 해당됩니다.


9/23쪽

2. 2. 2. 2. Automated System Validation Life CycleAutomated System Validation Life CycleAutomated System Validation Life CycleAutomated System Validation Life Cycle

본 강의에서는 일반적인 Life Cycle 에 대한 이야기는 너무 광범위 하므로 Automated

System Validation Life Cycle 에 대해서만 다루도록 하겠습니다. 앞 강의에서

Validation Life Cycle 의 특징에 대하여 이야기 했는데 이번 강의에서는 앞 강의에 관

련 내용을 다시 한번 이야기 한 후 세부적인 내용을 다루도록 하겠습니다.


그럼 Validation Life Cycle 은 무엇일까요? 말 그대로 Validation 할 대상의 계획에서부

터 폐기까지의 모든 과정을 말합니다. 아래 그림은 Validation Life Cycle 의 전형적인

모습입니다.

그림에서 보면 크게 왼쪽은 계획, 오른쪽은 검사, 중간은 구현 부분입니다. 이 구조는

구현 부분을 중심으로 V 자로 되어 있습니다. 오른쪽은 평소에 자주 이야기 하는 IQ, OQ,

PQ 입니다. 이 그림을 자세히 관찰하면 왼쪽 부분을 오른쪽 부분에서 검사하고 있습니다.

앞 강의에서 이야기 했듯이 Automated System 의 특성 때문에 위와 같은 전형적인

Validation Life Cycle 을 사용하는데 어려움이 있습니다. 따라서 대상에 따라

Validation Life Cycle 을 새로 만들어서 사용해야 합니다.

이 그림은 GAMP 4 에 나와있는 공정제어 시스템의 Validation Life Cycle 입니다. 참고하

세요


10/23쪽

실제 대상에 따라 만들어진 Validation Life Cycle 은 위의 그림과 같이 상당히 복잡합

니다. 어려운 작업입니다. 제 생각은, Validation Life Cycle 을 만드는데 크게 두가지

방법을 생각할 수 있습니다. 우선 첫번째 방법은 해야 할 작업에 따라 모든 단위 과정을

규정하고 순서에 따라 열거하는 방법이고, 두번째 방법은 위의 첫번째 그림과 같은 전형

적인 Validation Life Cycle 에 작업에 단위 작업을 적절히 분배하여 끼워 넣는 방법입

니다. 우선 첫번째 방법은 모든 단위 과정에 따라 작성되므로 명확하고 진행단계를 판단

할 때 유리하여 업무가 효율적입니다. 두번째 방법은 일반적으로 사용되는 IQ, OQ, PQ

에 소스코딩 검사, 모듈 검사, 적합성 검사 등을 적절하게 배분하여 구성하므로 정확한

작업이나 진행상태를 알기에 어려움이 있습니다. 그러나 이런 방법을 사용할 경우 사용

자(제약회사) 측 담당자에게 익숙한 용어를 사용하므로 혼란을 방지할 수 있습니다. 두

가지 방법 모두 장단점이 있으므로 적절히 선택하여 사용하면 됩니다.

어떤 방법으로 Validation Life Cycle 을 만들었더라도 다음 사항을 충족해야 합니다.

어떤어떤어떤어떤 상태의상태의상태의상태의 결과는결과는결과는결과는 다음다음다음다음 상태의상태의상태의상태의 입력자료로입력자료로입력자료로입력자료로 사용된다사용된다사용된다사용된다....

모든모든모든모든 계획은계획은계획은계획은 검사되어야검사되어야검사되어야검사되어야 한다한다한다한다....

어떤 상태의 결과는 다음 상태의 입력자료로 사용된다는 말은 Life Cycle 이라는 흐름에

만드는 논리적 방법입니다. 예를 들어, 사용자의 요구 조건인 URS 가 있어야 대응되는

기능사양(FS)가 존재할 수 있는 것 입니다. 모든 단위 작업은 업무의 진행에 따라 필연

적으로 발생하는 작업들로 구성되며 순서가 정해집니다. 또한 모든 계획은 반드시 검사

되어야 합니다. 만약 계획만 있고 검사가 없다면 잘못 만들어진 Life Cycle 입니다. 만

들어진 Life Cycle 를 평가하는 방법은 상식(Common Sense)입니다. 정해진 Life Cycle 은

없습니다. 여러 사람들과 논의를 통하여 논리적으로 타당한 Life Cycle 을 완성시켜야


11/23쪽

합니다.

Validation Life Cycle 을 구성하는 단위 작업은 아래에 기술되어 있습니다.

2.2 Automated System Validation Life Cycle2.2 Automated System Validation Life Cycle2.2 Automated System Validation Life Cycle2.2 Automated System Validation Life Cycle 의의의의 책임책임책임책임

대부분의 Validation 의 대상은 자체적인 제작보다 외부업체에서 구매를 통하여 이루어

집니다. (Validation 대상을 판매하는 쪽을 ‘공급자’ 구매하는 쪽은 ‘사용자’라고 지칭하겠습니다.) 이때 모든 Validation 의 책임은 사용자에게 있습니다. 즉, 하나의 제품을

구매할 때 ‘A 사는 Validation 을 해주고 B 사는 Validation 을 해주지 않는다’ 라는 말은잘못된 말이라는 것입니다. 어떤 제품을 구매하더라도 Validation 의 주체는 사용자에게

있으므로 Validation 에 관련된 모든 사항을 철저히 관리감독 해야 합니다. 그래서 위의

말은 ‘A 사의 제품은 Validation 에 필요한 자료를 제공해주므로 Validation 이 수월하고B사의 제품은 Validation 에 필요한 자료가 없으므로 사용자가 모든 것을 해야 한다’ 라고 바뀌어야 합니다. 이 말에 오해가 없기를 바랍니다.

그러므로 당연히 공급자는 다양한 방법을 통하여 직간접으로 검증에 관련되고 사용자는

공급자 감사를 통하여 공급자를 평가해야 합니다.

구체적으로 사용자가 책임지고 해야 할 작업 목록은 다음과 같습니다.

대상 시스템 확인

URS 작성

검증 전략 결정

검증계획 작성

사양 검토와 승인

시스템 개발 감시

Source code 검토

검사규격 검토와 승인

검사 수행

검사 보고서 검토와 승인

검증 보고서 작성

시스템 유지 보수

시스템 폐기

2.3 2.3 2.3 2.3 대상시스템대상시스템대상시스템대상시스템 확인확인확인확인 - Identify System - Identify System - Identify System - Identify System

대상시스템의 확인이란 어떤 것이 Validation 의 대상인가 입니다.(사무실에서 사용하는

연필이 Validation 대상일 수는 없으니까요) Validation 대상 시스템 목록을 작성해야

하며 더불어 목록의 기록, 변경, 승인 방법을 확립해야 합니다. 이 목록에는 최소한 GxP

에 규제되는 모든 시스템을 포함 해야 한다.

2.4 URS2.4 URS2.4 URS2.4 URS

URS 란 User Requirements Specification 의 약자로 해당 시스템이 해야 할 일과 갖추어

야 할 것을 규정한 기술한 문서입니다. URS 는 Validation Life Cycle 의 실질적인 시작

이며, 사용자의 의지의 표현입니다. 시작이 반이라는 말이 있듯이 사용자가 가장 공들여

서 해야 하는 일중에 하나입니다. URS 는 모든 Validation Life Cycle 에서 참조되는 문


12/23쪽

서입니다. 기능규격(FS)나 설계규격(DS)가 만들어진 상태에서 갑자기 사용자가 요구조건

을 변경하거나 추가한다면 모든것을 처음부터 다시 만들어합니다. 당연히 시간과 노력과

비용이 추가로 발생합니다. 성공적인 결과를 얻기 위해서는 좋은 URS 를 작성해야 합니

다. 작업이 어려울 경우는 외부인력을 이용하여 작성하는 경우도 있습니다. 외부로 제출

되는 문서이므로 승인된 문서여야 하며, 만약 계약이 성립된다면 계약에 필요한 문서로

사용됩니다.

2.5 2.5 2.5 2.5 검증전략검증전략검증전략검증전략 결정결정결정결정

사용자가 해야 할 작업으로 크게 위험 평가, 시스템 구성요소 평가, 공급자 평가와 교육

이 있습니다. 각 세부내용은 다음과 같습니다.

위험 평가

- 해당 자동화 시스템은 검증이 필요한가?]

- 해당 시스템은 얼마나 많은 검증이 필요한가?

- 제품과 잠재적인 안전요소를 위한 시스템의 주요 측면은 무엇인가?

- 사업위한 시스템의 주요 측면은 무엇인가?

시스템 구성요소 평가

- 소프트웨어

- 개발 & 진단 도구

- 하드웨어

공급자 평가와 교육

2.6 2.6 2.6 2.6 계획계획계획계획

계획이란 가장 중요한 작업입니다. 즉, Validation Life Cycle 를 만드는 작업입니다.

크게 ‘Validation 계획’, ‘품질과 프로젝트 계획’ 두가지로 구분됩니다. 반드시 두가지계획이 모두 필요한 것은 아닙니다. Validation 대상의 규모가 작다면 하나의 문서로 만

들어도 됩니다. 그러나 계획에 들어가야 할 내용은 반드시 숙지하고 있어야 합니다. 이

계획에 따라 Validation 을 포함한 모든 작업이 진행되고 보고됩니다.

Validation 계획

Validation 계획은 해당 프로젝트의 처리작업과 순서, 책임에 대한 내용을 담고 있어야

합니다. 사용자가 작성해야 하며, 경우에 따라 외부인력이 작성하는 경우도 있습니다.

가능하다면 URS 와 함께 공급자에게 제공하는 것이 공급자의 명확한 업무범위를 부여하

여 좋은 결과가 나타납니다. 이것은 프로젝트를 관리하는 도구로 사용되며, 계획에 따라

보고서를 작성해야 됩니다. 포함해야 할 내용은 다음과 같습니다.

범위 (작성자, 관련 정책과 문서와의 관계, 검증 범위, 검증 목적)

역할과 책임

조직도

GxP 주요 평가

검증 전략

검증 제공

적합성 기준

변경통제


13/23쪽

표준작업절차

교육

문서관리

검증상태 관리

품질과 프로젝트 계획 - Quality & Project Plan

품질과 프로젝트 계획은 Validation 계획보다 좀더 Validation 에 관련된 세부적인 사항

을 포함합니다. 실제 대상과 검사에 대한 내용을 명확하게 해야 합니다. 계약할 때 사용

자와 공급자가 동의해야 하는 계약문서 입니다. 이 계획에는 사용자의 품질 요구사항을

공급자가 만족시킬 방법이나 공급자 자체의 품질관리 시스템에서 만들어지는 문서의 적

용 방법이 나타나야 합니다. 포함내용은 다음과 같습니다.

일반 (작성자, 계상상태, 관련 정책과 절차 및 표준 지침과의 관계)

프로젝트 개요

사용자 품질 요구사항

공급자 품질 시스템

규격

설계 검토

검사

설치

자료 통합

정합성 검사

변경통제

설정 관리

위험 관리

교육

지원 조직 이관

조직도

공급대상 항목

활동 (프로젝트 주요시점, 프로젝트 활동, 개일 할당, 계획표)

품질과 프로젝트 계획은 계약에 중요한 요소로 작용합니다. 따라서 사용자는 다음과 같

은 책임이 있습니다.

품질과 프로젝트 계획의 검토와 승인

공급자 활동 감시

필요에 따라 개정하는 품질과 프로젝트 계획의 확인

적합성 활동을 위한 계획 확인

제공되는 항목과 활동계획 확인

규정준수에 필요한 계약 요구사항 검사

확인된 문제와 결함에 따른 활동계획 확인

유지보수, 오류처리와 관련된 동의

2.7 2.7 2.7 2.7 시스템시스템시스템시스템 규격규격규격규격

시스템 규격이란 공급자가 작성하여 사용자에게 주는 것으로 Validation 대상에 대한 설

명입니다. 잘 알고 계시는 기능규격(FS)이 여기에 포함됩니다. 크게 두가지로 나눌 수

있는데 우선 URS 에 대응되는 문서로 작성되는 기능규격과 계약성립 후 제출하는 세부적

이고 전문적인 설계사양이 있습니다.


14/23쪽

기능규격

공급자가 작성한다.

계약문서

제공되는 기능 및 장치

포함내용:

일반 (작성자, 계약상태, 관련 문서와의 관계)

핵심적인 시스템 기능과 인터페이스

제공되는 기능과 장치의 독립적인 설명

시스템에서 사용되는 자료

시스템의 모든 인터페이스

비 기능적 특징 ( 가용성, 유지보수)

설계사양

시스템의 구축과 유지보수가 가능한 정도의 자세한 설명

기능 사양에 포함되는 경우도 있다.

포함내용:

일반 (작성자, 관련 문서와의 관계)

하드웨어의 전반적인 설정

입/출력 장치

작동환경

필요 지원 사항

흐름도, 알고리즘, 화면설명

자료구조

각 모듈 설명

2.8 2.8 2.8 2.8 시스템시스템시스템시스템 설명설명설명설명

모든 시스템에 설명서를 작성해야 합니다. 단지 사용 설명서만이 아니라 원칙, 목적, 보

안수단, 시스템의 범위, 다른 시스템과의 상호절차, 설치, 관리에 관한 모든 설명서가

문서화 되야 합니다. 당연히 요구사항과 일치하도록 시스템이 설명되어야 합니다. 이미

만들어진 제품일 경우 기능사양에 포함될 수도 있습니다.

2.9 2.9 2.9 2.9 소프트웨어소프트웨어소프트웨어소프트웨어 개발과개발과개발과개발과 검토검토검토검토

실재로 소프트웨어를 구현하는 과정입니다. 만약 해당 프로젝트가 하드웨어를 포함하고

있다면 당연히 별도의 하드웨어의 개발과 검토가 이루어 져야 합니다. 이 과정에서도 여

러 가지 검사를 수반하는데 대부분 이 과정에서 행하는 검사는 공급자가 실시하는 검사

입니다. 특히 소스코드 검토는 사용자와 협의하에 진행해야 한다.

방법과 도구

정책과 절차

프로그램 규칙과 관습

검토와 방법

검사와 입증

보안과 기밀성

소스코드 검토


15/23쪽

2.10 2.10 2.10 2.10 검사검사검사검사

일반적으로 생각하는 IQ, OQ, PQ 에 해당하는 절차입니다. 앞 강의에서 논의 되었듯이

Validation 분야와 소프트웨어 공학분야의 용어와 절차에서 오는 차이 때문에 단순히 IQ,

OQ, PQ 라고 지칭하기 어려운 검사들이 있습니다. 경우에 따라 적당한 검사를 선택하여

실시해야 하며 다음사항을 포함해야 합니다.

소프트웨어 모듈 검사

소프트웨어 통합 검사

하드웨어 적합성 검사

시스템 적합성 검사

2.11 Validation 2.11 Validation 2.11 Validation 2.11 Validation 보고서보고서보고서보고서

이 문서는 사용자가 만드는 것으로 Validation 계획에 따라 제공된 모든 검토가 성공적

으로 수행되어 시스템이 Validation 되었다는 요약된 증거와 결론의 요약 문서입니다.

이것의 사용자의 내부절차나 규정에 따라 달라질 수 있습니다.

2.12 2.12 2.12 2.12 검증상태검증상태검증상태검증상태 유지유지유지유지

당연한 작업으로 사용자가 해당 시스템에 대하여 지속적으로 해야 할 작업입니다. 다음

과 같습니다.

작업 계획 & 절차 ( SOP 포함)

교육

문제 관리 & 해결

지원 수준 합의 (Service Level Agreement)

지원할 시스템

지원하는 방법

수행된 지원의 평가방법

시스템 관리

관리 / 유지 활동

소프트웨어 도구 사용

주기적인 검사와 교정

예비 / 소모성 부분 보관

백업 및 복원 (Backup & Recovery)

설정 관리

작업 변경 통제

보안 관리

성능 감시

자료 보유, 보관, 조회

업무 연속 계획 (Business Continuity Planning)

주기적인 검토 & 평가

시스템 폐기

하지만 검증상태를 유지하려는 것만으로 불가능한 경우도 있습니다. 시스템에 주요기능

이나 두드러진 변경이 이루어졌다면 검증 효력을 유지하는 것이 아니라 새롭게 검증을

실시해야 합니다.


16/23쪽

3. 3. 3. 3. Automated System ValidationAutomated System ValidationAutomated System ValidationAutomated System Validation Case StudyCase StudyCase StudyCase Study

이 강의는 지금까지 다루었던 Automated System Validation 에 대한 사례연구(Case

Study)로 MS-VBA 를 이용하여 프로그램된 엑셀시트를 대상으로 하였습니다. 이 강의를

통하여 지금까지 공부했던 Validation Life Cycle 이 어떻게 작성되고 구현되는지 확인

해 보도록 하겠습니다.

3.1 Validation 3.1 Validation 3.1 Validation 3.1 Validation 대상대상대상대상

실제적인 Validation 대상에 대하여 구체적으로 생각해봅시다.

위 그림은 제약 생산과정을 나타내고 있다. 제품생산 후 품질검사를 실시하는데 검사기

록은 MS 사의 엑셀을 이용하여 수식을 계산하고 지정된 기록서 양식으로 출력, 서명하여

보관됩니다. 품질 검사 기록 작업은 주기적으로 발생하는 작업이어서 회사에서는 수치계

산 및 출력양식 통일성을 위하여 작업자가 임의로 작성하는 것을 금지시키고 MS-VBA2를

이용하여 프로그램된 엑셀시트3를 개발하여 사용하도록 했습니다. 개발된 엑셀시트는 지

2 VBA : VBA(Visual Basic for Applications)는 Microsoft 사의 어플리케이션들을 자신에게 맞도록 고치기 위한 보편적 언어를 제공하는 Visual Basic 의 일부분이다. VBA 는 COM 을 지원함으로써, 엑셀, 워드, 그리고

기타 COM 기반의 프로그램들 내에서 내부 함수들을 호출하거나, 또는 독립형, 외부 COM 객체들을 사용하기

위한 VBA Script 를 허용한다. VBA 는 초기의 Macro 나 Script 언어를 통합하기 위한 공통 언어로 발전했다.

1996 년부터, VBA 는 Windows 환경의 비 Microsoft 어플리케이션에서 사용하기 위해, 제 3 의 회사들에게 라

이선스 되고 있다

3 개발엑셀시트 : 엑셀은 VBA 를 제공해서 사용자가 엑셀의 기능을 추가시킬 수 있다. VBA 로 추가되는 프로그램은 엑셀로 만들어지는 파일에(*.xls) 추가된다. 엑셀자체의 프로그램 기능이 변경되는 것이 아니라 VBA

가 추가된 엑셀파일을 열었을 때 파일의 일부로 작동된다. VBA 가 파일에 삽입되므로 단순한 문서파일로 생

각할 수도 있으나 VBA 는 간단하지만 엄연히 프로그램 언어이며 VBA 를 이용하여 논리적 판단과 수리적 연산

을 수행하는 프로그램이 가능하다. 따라서 형태는 파일이지만 독립적인 프로그램으로 인식해야 한다. 본 문

서에는 이러한 파일을 '개발된 엑셀시트', '개발엑셀시트'로 지칭한다.


17/23쪽

정된 항목에 시험 결과만 입력할 수 있으며 결과는 항상 종이로 출력됩니다. 또한 저장

이 불가능합니다. 이렇게 개발된 엑셀시트가 Validation 대상입니다. 개발된 엑셀시트의

기능은 시험자료 가공을 위한 계산기, 시험 기록서 작성을 위한 문서 편집기입니다. 해

당 Validation 대상을 평가해 봅시다.

3.2 Validation3.2 Validation3.2 Validation3.2 Validation 대상의대상의대상의대상의 평가평가평가평가

몇 가지 질문을 통하여 Validation 대상을 평가해 봅시다.

하드웨어를 포함하는가?

논란의 소지가 있지만 대답은 ‘아니오’입니다. 어떻게 보면 PC 를 사용하므로하드웨어가 포함됐다고 생각할 수 있지만 PC 는 범용 하드웨어다. 즉, 완제품으

로 구매되며, PC 의 규격은 주문제작 되거나 특수목적으로 제작된 것이 아닙니

다. 이와 같은 경우, PC 의 구매와 함께 제공되는 제품의 보증서, 설명서, 기타

기술 문서를 이용하여 Infrastructure Qualification 에서 작업해야 할 일입니

다. (하지만, 용산 등에서 조립한 PC 의 경우는 이러한 자료가 없으니 조금 힘

들 것 같습니다.)

Electronic Records / Electronic Signatures 를 포함하는가?

역시 대답은 ‘아니오’이다. 대상을 Electronic Records(이하 ER)로 착각 할 수있습니다. 문론 PC 에서 생성된 자료이긴 하지만 엑셀 파일로 저장되지 않고 종

이로 출력되므로 ER 로 평가되지 않습니다. 만약 회사 내부에 문서관리 시스템

이 있어 파일로 저장하여 보관한다면 문제는 달라질 수 있지만, 현재와 같은

경우는 ER 이 아니며, 서명 또한 출력된 종이에 하므로 Electronic Signatures

가 아닙니다. 결론적으로 개발된 엑셀 시트는 21 CFR Part 11 의 대상이 아닙니

다.

MS-엑셀은 Validation 대상인가?

대답은 ‘아니오’입니다. 일반적으로 문서 편집기나 수식계산을 위한 소프트웨어는 Validation 대상입니다. 하지만 전세계적으로 널리 사용되는 MS 사의 프로그

램은 암묵적으로 Validation 대상이 아니며 Validation 되었다고 생각합니다.

당연히 PC 에 설치된 윈도우 운영체제 또한 그냥 쓰면 됩니다. 너무 많은 분야

와 전세계적으로 사용되다 보니 그냥 넘어간다고 생각하면 됩니다.

결론적으로 Validation 대상은 굉장히 줄어들었습니다. MS-VBA 로 작성된 엑셀 시트만

Validation 하면 됩니다. Automated System Validation 중 가장 간단한 경우입니다.


앞 강의에서부터 강조해왔던 Validation Life Cycle 은 어떻게 구성될까요?. 기본 모습

과 본 예제에 맞게 만들어진 Validation Life Cycle 은 아래 그림과 같습니다.


18/23쪽

기본 Validation Life Cycle

개발된 엑셀 시트의 Validation Life Cycle

두개의 그림은 비교해 보면 기본적인 형태에서 대상에 어울리도록 많은 부분이 수정된

것을 알 수 있습니다. 본 강의에서 대상으로 하는 개발 엑셀 시트와 같은 간단한 경우도

위의 그림과 같이 상당히 복잡합니다. (위의 Validation Life Cycle 의 경우는 필자가

작성했습니다. 천천히 보시고 마음에 들이 않는 부분이 있다면 연락주세요. 같이 이야기

해 봅시다)

작성된 Validation Life Cycle 은 위에서 설명한 개발 엑셀 시트를 대상으로 작성된 것

입니다. 다른 곳에 적용하면 좋지 않는 결과를 초래할 수 있습니다.

Validation Life Cycle 을 구성하는 단위 작업은 아래에 기술되어 있습니다.


19/23쪽

3.4 3.4 3.4 3.4 Validation Master PlanValidation Master PlanValidation Master PlanValidation Master Plan

사용자가 작성해야 하는 문서이며, Automated System 에 관련된 최상위 문서로 모든

Automated System 은 이 문서에 영향을 받습니다. 특정 시스템을 대상으로 작성하지 않

습니다. 자동화 시스템이 있는 회사는 반드시 이 문서를 가지고 있어야 한다.

o 서론

o 적용범위

o 개요

-. 검증의 의미

-. 검증 방법

- 소프트웨어 카테고리

- 시스템 종류

- 시스템 라이프사이클

o 검증 계획

o 규격

- 이용자 요구사항(User Requirement Specification, URS)

- 기능 규격(Functional Specification, FS)

- 규격의 내용

o 중요성 분석

- 공통

- 특정 검증이 필요한 기능

o 납품업체 감사

o 설계 및 개발 문서

o 절차 및 교육

o 설치 적합성 검증

o 운전적합성검증

o 성능 적합성 시험

o 검증 보고

o 검증 상태의 유지

o 소급 검증

o 용어 정의

3.5 3.5 3.5 3.5 Validation Plan Validation Plan Validation Plan Validation Plan or or or or Validation ProtocolValidation ProtocolValidation ProtocolValidation Protocol

사용자가 작성하며, 일반적으로 Validation Protocol 이라고 불리는 문서입니다.

Validation 대상으로 하는 개발 엑셀 시트의 검증을 위한 총괄적인 계획이다. 위에 그림

으로 도식화된 Validation Life Cycle 를 설명합니다. 특정대상(여기서는 해당 개발엑셀

시트)에 적용되며 범용적으로 사용될 수 없습니다.

o 개요 및 범위

o 조직적 구조

o GxP 주요평가

o 검증 전략

- 해당 시스템의 종류

- Life Cycle

- 위험평가

- 검증 단계


20/23쪽

= 검증계획

= 사용자 요구사항

= 기능규격

= 소프트웨어 설계사양 (Software Design Specification)

= Coding Convention

= 사용자 설명서

= 소프트웨어 검토 계획서 (Software Review Plan)

= 소프트웨어 검토 보고서 (Software Review Report)

= 적합성 검사 계획 (Acceptance Test Plan)

= 적합성 검사 보고서 (Acceptance Test Report)

= 유지관리 방법서

o 검증 실행

o 적합성 기준

o 변경관리

o 표준작업절차

o 교육

o 문서관리

o 검증상태 유지

o 용어

3.6 3.6 3.6 3.6 User Requirements Specification (URS)User Requirements Specification (URS)User Requirements Specification (URS)User Requirements Specification (URS)

사용자 작성하며, 개발될 엑셀시트가 작동되기를 희망하는 기능, 제한사항을 나열합니다.

o 제목

o 목적

o 사용 범위

o 내용

o 제어해야 할 부분

3.7 3.7 3.7 3.7 Functional Specification (FS)Functional Specification (FS)Functional Specification (FS)Functional Specification (FS)

공급자가 작성합니다.

o 서론

o 개요

o 기능

- 구성요소

- 입력

- 출력

- 작성함수

- 수치계산

- 보호함수

- 기록함수

o 자료

o 인터페이스

o 기타

o 용어


21/23쪽

3.8 3.8 3.8 3.8 Software Design SpecificationSoftware Design SpecificationSoftware Design SpecificationSoftware Design Specification

공급자가 작성하며, 사용자에게 제공되는 문서이기는 하지만 개발자를 위하여 만든 문서

입니다. 개발자는 FS 보다 Software Design Specification 을 이용하여 프로그래밍 합니

다.

o 서론

o 개요

o 시스템 설명

- 시트구성

- VBA 모듈

o 시스템 자료

o 모듈 설명

o 첨부 : 순서도

3.9 3.9 3.9 3.9 Coding ConventionCoding ConventionCoding ConventionCoding Convention

공급자가 작성하며, 프로그래머를 위한 공급자의 내부 문서입니다. 사용자에게 제공할

수도 있고 제공하지 않을 수도 있습니다.

프로그램은 창작활동 이라서 동일한 내용을 프로그램해도 프로그래머에 따라 많이 다르

게 됩니다. 이러한 차이는 차후 유지보수를 어렵게 합니다. 따라서 프로그래머에 따른

차이를 최소화하는 기본적인 표준을 제시하는 문서이다.

o 프로그램 코딩 표준안 (특별한 양식은 없다.)

3.10 3.10 3.10 3.10 Software Review PlanSoftware Review PlanSoftware Review PlanSoftware Review Plan

공급자가 작성하며, 개발된 프로그램에 대한 코드 검사를 위한 문서입니다. 일반적인 IQ

Protocol 에 해당합니다.

o 서론

o 개요

o 책임/검토자

o 소프트웨어 구조검토

o 소프트웨어 코드검토

o 화면 검토

o 검토 요약

o 첨부 : 검사 보고서 양식

3.11 3.11 3.11 3.11 Software Review ReportSoftware Review ReportSoftware Review ReportSoftware Review Report

일반적으로 사용자가 작성하지만 전문적 지식이 필요해서 외부인력을 이용하기도 합니다.

Software Review Plan 을 바탕으로 프로그램의 코드를 검사한 보고서입니다. 일반적인

IQ 보고서에 해당한다.

o 목적


22/23쪽

o 범위

o 경과

o 결과

o 결론

o 첨부 : 검사보고서

3.11 3.11 3.11 3.11 Acceptance Test PlanAcceptance Test PlanAcceptance Test PlanAcceptance Test Plan

공급자가 작성하며, 개발된 프로그램의 기능 검사를 위한 문서입니다. 일반적인 OQ/PQ

Protocol 에 해당한다. 본 대상에는 FAT4, SAT5를 분리하여 실시하지 않고 한번만 실시하

고 있습니다. 이유는 엑셀 시트의 경우 버전만 일치한다면 어디에서도 동일한 결과를 나

타내기 때문입니다. 하지만 대부분의 경우 작업 및 검사 환경이 동일하지 않으므로 FAT,

SAT 를 전부 실시해야 합니다.

o 서론

o 범위

o 개요

o 검사를 위한 필요사항

o 검사

- 입력자료 검토 기능

- 출력 기능

- 계산 기능

- 보안 기능

o 용어

o 첨부 : 검사 보고서 양식

3.12 3.12 3.12 3.12 Acceptance Test ReportAcceptance Test ReportAcceptance Test ReportAcceptance Test Report

일반적으로 사용자가 작성하며, Acceptance Test Plan 을 바탕으로 프로그램의 기능을

검사한 보고서입니다. 일반적인 OQ/PQ 보고서에 해당합니다.

o 목적

o 범위

o 경과

o 결과

o 결론

o 첨부 : 검사보고서

4 FAT : Factory Acceptance TestAn Acceptance Test in the Supplier’s factory, usually involving the CustomerTesting conducted to determine whether or not a system satisfies its acceptance criteria and to

enable the customer to determine whether or not to accept the system.

5 SAT : Site Acceptance TestAn Acceptance Test at the Customer’s site, usually involving the CustomerTesting conducted to determine whether or not a system satisfies its acceptance criteria and to

enable the customer to determine whether or not to accept the system.


23/23쪽

3.13 3.13 3.13 3.13 설명서설명서설명서설명서

설명서는 사용자 설명서와 유지관리 방법서가 있으며 필요한 내용을 기술하면 됩니다.

automated system validation 자동화자동화 시스템시스템시스템 … system...

Documents