王健明

（上海信誼藥廠有限公司制藥二廠，上海201200）

0 引言

隨著GMP（2010修訂版）有關(guān)計(jì)算機(jī)化系統(tǒng)附錄的生效日期的臨近，計(jì)算機(jī)化系統(tǒng)驗(yàn)證的話題已經(jīng)被人們經(jīng)常提及，但大多對自己企業(yè)各類相關(guān)的計(jì)算機(jī)化系統(tǒng)應(yīng)該如何驗(yàn)證感到困惑，應(yīng)該遵從怎樣的規(guī)范來實(shí)施驗(yàn)證，本文希望就上述話題與同行一起學(xué)習(xí)和探討，分享我們多年來在工作實(shí)踐中的成果。

1 基本概念

GMP計(jì)算機(jī)化系統(tǒng)附錄第4章就驗(yàn)證做出如下闡述：應(yīng)使用科學(xué)的風(fēng)險評估方法來決定計(jì)算機(jī)化系統(tǒng)的驗(yàn)證范圍與程度，應(yīng)當(dāng)將驗(yàn)證看作計(jì)算機(jī)化系統(tǒng)生命周期的一個組成部分，這個生命周期包括計(jì)劃、設(shè)定標(biāo)準(zhǔn)、編程、測試、試運(yùn)行、文檔管理、運(yùn)行、監(jiān)控、修改更新等階段，要充分考慮計(jì)算機(jī)化系統(tǒng)的使用范圍，確定其屬于前驗(yàn)證還是回顧性驗(yàn)證，系統(tǒng)是否引入新的組件。

首先我們有必要將上述專業(yè)名詞用ISPEGAMP 5《良好自動化生產(chǎn)實(shí)踐指南》來做一下定義，以便明確其內(nèi)涵。

1.1 風(fēng)險評估方法

計(jì)算機(jī)化系統(tǒng)質(zhì)量風(fēng)險管理流程（圖1），采用了ICH Q9的一般原則來說明風(fēng)險管理的“5個步驟”，該流程是實(shí)現(xiàn)與維護(hù)系統(tǒng)不可或缺的部分，對于簡單的低風(fēng)險的系統(tǒng)可以進(jìn)行組合。

圖1 計(jì)算機(jī)化系統(tǒng)質(zhì)量風(fēng)險管理流程

1.2 計(jì)算機(jī)化系統(tǒng)

計(jì)算機(jī)化系統(tǒng)框圖如圖2所示，其是由硬件、軟件、網(wǎng)絡(luò)組件以及可控的功能和相關(guān)文件組成。它可以包括：生產(chǎn)資源計(jì)劃系統(tǒng)、實(shí)驗(yàn)室信息管理系統(tǒng)、自動化生產(chǎn)設(shè)備系統(tǒng)、生產(chǎn)執(zhí)行系統(tǒng)、倉儲與配送系統(tǒng)、文件管理系統(tǒng)。

圖2 計(jì)算機(jī)化系統(tǒng)框圖

1.3 計(jì)算機(jī)化系統(tǒng)的生命周期

計(jì)算機(jī)化系統(tǒng)的生命周期由以下4個主要階段組成：概念提出、項(xiàng)目實(shí)施、系統(tǒng)運(yùn)行、系統(tǒng)退役。

概念提出階段通常由監(jiān)管公司根據(jù)自己的業(yè)務(wù)需求和收益來考慮階段需要實(shí)現(xiàn)的業(yè)務(wù)流程，并考慮可能的解決方法。

項(xiàng)目實(shí)施是充分考慮了自己的業(yè)務(wù)需求和收益后，根據(jù)項(xiàng)目的活動中的計(jì)劃，評估和選擇供應(yīng)商，規(guī)范各層級的需求，并進(jìn)行配置、驗(yàn)證，直到項(xiàng)目的驗(yàn)收和系統(tǒng)投入使用。

系統(tǒng)運(yùn)行是4個階段中最長的階段，是由確定的及時更新的具有可操作性的規(guī)程來對其進(jìn)行管理，期望保持系統(tǒng)可控、符合預(yù)定用途及合規(guī)等都是非常關(guān)鍵的方面，重點(diǎn)是對系統(tǒng)的影響、范圍和復(fù)雜性的變更進(jìn)行管理。

當(dāng)系統(tǒng)即將退出公司的業(yè)務(wù)不再使用時，就自然進(jìn)入了退役階段，該階段決定對數(shù)據(jù)進(jìn)行保留、遷移還是銷毀。

2 驗(yàn)證實(shí)施

驗(yàn)證通常使用國際制藥工程協(xié)會（ISPE）的《良好自動化生產(chǎn)實(shí)踐指南》（GAMP5）的V字模型（圖3），該模型是使系統(tǒng)在整個生命周期實(shí)現(xiàn)合規(guī)與符合預(yù)定用途的通用方法。該模型的驗(yàn)證過程包括用戶需求規(guī)范、功能需求規(guī)范、設(shè)計(jì)規(guī)范、系統(tǒng)開發(fā)、安裝確認(rèn)、運(yùn)行確認(rèn)和性能確認(rèn)。測試階段的驗(yàn)證活動用來確認(rèn)規(guī)范階段的需求得到滿足。

2.1 驗(yàn)證主計(jì)劃（VMP）

在項(xiàng)目實(shí)施前首先需要定義驗(yàn)證計(jì)劃，它可以作為既定的時間段內(nèi)或工作流的總體計(jì)劃，它應(yīng)該是驗(yàn)證項(xiàng)目的概述文件，必須清晰精確地表述和涵蓋設(shè)施、系統(tǒng)、流程的概述。

驗(yàn)證過程是建立文件證據(jù)，為特定的計(jì)算機(jī)化流程可以持續(xù)地滿足預(yù)先定義的質(zhì)量要求規(guī)范提供高度保證。其主要目標(biāo)是通過文件、記錄系統(tǒng)可持續(xù)滿足需求。此驗(yàn)證主計(jì)劃的目的是定義該系統(tǒng)的驗(yàn)證活動，內(nèi)容包含定義、驗(yàn)證范圍、驗(yàn)證角色和職責(zé)以及主要驗(yàn)證產(chǎn)生文檔的描述。

圖3 GAMP5 V字模型

2.1.1 系統(tǒng)描述

系統(tǒng)是進(jìn)行藥品生產(chǎn)質(zhì)量控制的技術(shù)平臺，它是由多個子系統(tǒng)集成，主要涵蓋生產(chǎn)管理、質(zhì)量管理等模塊。

2.1.2 功能范圍

驗(yàn)證項(xiàng)目實(shí)施的范圍有生產(chǎn)流程、質(zhì)量管理流程，功能模塊有生產(chǎn)管理模塊、質(zhì)量管理模塊等。

2.1.3 系統(tǒng)的技術(shù)架構(gòu)

系統(tǒng)主要由生產(chǎn)管理模塊、質(zhì)量管理模塊以及其他業(yè)務(wù)模塊組成，涵蓋開發(fā)環(huán)境、驗(yàn)證環(huán)境、運(yùn)行環(huán)境以及備份服務(wù)器的架構(gòu)及配置文件的描述等。

2.1.4 驗(yàn)證方法

驗(yàn)證將使用國際制藥工程協(xié)會（ISPE）的《良好自動化生產(chǎn)實(shí)踐指南》（GAMP5）的V字模型，該模型是使系統(tǒng)在整個生命周期實(shí)現(xiàn)合規(guī)與符合預(yù)定用途的通用方法。該模型的驗(yàn)證過程包括用戶需求規(guī)范、功能需求規(guī)范、設(shè)計(jì)規(guī)范、系統(tǒng)開發(fā)、安裝確認(rèn)、運(yùn)行確認(rèn)和性能確認(rèn)等。

2.1.5 風(fēng)險評估

作為驗(yàn)證方法的組成部分，企業(yè)將采取基于風(fēng)險的方法，對系統(tǒng)功能的風(fēng)險水平進(jìn)行評估。風(fēng)險評估將對系統(tǒng)驗(yàn)證范圍內(nèi)的流程或功能相關(guān)的法規(guī)和業(yè)務(wù)風(fēng)險進(jìn)行合理地評估并進(jìn)行書面記錄。編制風(fēng)險評估報告遞交決策層審批。

2.1.6 驗(yàn)證交付

驗(yàn)證交付的內(nèi)容：驗(yàn)證主計(jì)劃、設(shè)計(jì)需求規(guī)范、功能需求規(guī)范、用戶需求規(guī)范、確認(rèn)階段（IQ、OQ、PQ）、標(biāo)準(zhǔn)操作程序、用戶培訓(xùn)、偏差管理、驗(yàn)證總結(jié)報告。

2.1.7 項(xiàng)目的角色與職責(zé)

驗(yàn)證主管和信息系統(tǒng)質(zhì)量保證主管需要對協(xié)議授權(quán)，對驗(yàn)證結(jié)果和驗(yàn)證總結(jié)報告進(jìn)行審批。項(xiàng)目中需要對團(tuán)隊(duì)的角色做出定義，如執(zhí)行決策者（ES）、項(xiàng)目經(jīng)理（PM）、開發(fā)團(tuán)隊(duì)主管（DTL）、開發(fā)團(tuán)隊(duì)成員（DTM）、業(yè)務(wù)部門主管/團(tuán)隊(duì)成員（BTL/BTM）、驗(yàn)證主管（VTL）、驗(yàn)證團(tuán)隊(duì)成員（VTM）、信息系統(tǒng)質(zhì)量保證主管（ISQA）等，并按照上述角色，確定審批矩陣。

2.2 風(fēng)險評估

該系統(tǒng)為企業(yè)的生產(chǎn)、質(zhì)量控制的業(yè)務(wù)流程提供有效的運(yùn)作支持，企業(yè)將采取基于風(fēng)險的方法，對業(yè)務(wù)環(huán)境面臨的風(fēng)險進(jìn)行整體的風(fēng)險評估。

2.2.1 目的

風(fēng)險評估的目的是對系統(tǒng)功能的重要性和復(fù)雜性進(jìn)行評價。風(fēng)險評估對企業(yè)系統(tǒng)的相關(guān)功能的業(yè)務(wù)、技術(shù)和法規(guī)風(fēng)險提供合理的評估結(jié)果，并進(jìn)行文件記錄。

對系統(tǒng)的功能性風(fēng)險評估將考慮系統(tǒng)對企業(yè)質(zhì)量管理體系、產(chǎn)品的質(zhì)量、安全和效用以及數(shù)據(jù)完整性方面的潛在影響。此外，系統(tǒng)功能所支持的業(yè)務(wù)的重要性以及系統(tǒng)解決方案的技術(shù)復(fù)雜程度也是風(fēng)險評估考慮的因素。

2.2.2 范圍

文檔的范圍限于驗(yàn)證主計(jì)劃中所列的業(yè)務(wù)流程涉及的各模塊。

2.2.3 角色與職責(zé)

定義驗(yàn)證團(tuán)隊(duì)業(yè)務(wù)部門主管、信息技術(shù)主管、項(xiàng)目經(jīng)理的職責(zé)。

2.2.4 風(fēng)險評估

2.2.4.1 系統(tǒng)風(fēng)險評估

（1）GMP評估：用來判斷該系統(tǒng)是否應(yīng)作為企業(yè)質(zhì)量體系的一部分而被定義為一個GMP相關(guān)的系統(tǒng)。被判定與GMP相關(guān)就要求通過驗(yàn)證以滿足GMP的要求。

（2）重要性評估：根據(jù)提出的問題所作的回答來判定其重要程度。

（3）復(fù)雜性評估：根據(jù)提出的問題所作的回答來判定其復(fù)雜程度。

（4）評估總結(jié)：對重要性和復(fù)雜性評估的結(jié)果作出判斷。

2.2.4.2 功能風(fēng)險評估

如果模塊是與GMP相關(guān)的，則需要對每個功能進(jìn)行進(jìn)一步的評估。表1為功能風(fēng)險評估表，功能風(fēng)險評估方法參照ISPEGAMP5中的方法，由業(yè)務(wù)風(fēng)險、技術(shù)風(fēng)險、GMP風(fēng)險3個維度組成。每個維度都有4個等級來表示風(fēng)險的等級：高（3）、中（2）、低（1）、無（0）。每個功能最終的風(fēng)險等級將由3個維度中風(fēng)險等級最高的維度的風(fēng)險等級決定。風(fēng)險評估的結(jié)果將被用來定義驗(yàn)證范圍和測試等級。驗(yàn)證范圍將包括所有與GMP相關(guān)的功能。

表1 功能風(fēng)險評估表

評估結(jié)果為高、中風(fēng)險，需要做正式歸檔測試，正式歸檔測試時，所有的測試實(shí)例會被預(yù)先審批，然后執(zhí)行、審核以及批準(zhǔn)。

評估結(jié)果為低、無風(fēng)險，需要做非正式歸檔測試，在非正式歸檔測試時，測試實(shí)例無需預(yù)先審批，只會在執(zhí)行后被審批，但是測試總結(jié)報告會被審核以及批復(fù)。

2.3 用戶需求規(guī)范

2.3.1 目的

文檔的目的是為了定義企業(yè)實(shí)施并使用系統(tǒng)的業(yè)務(wù)/用戶需求。

2.3.2 范圍

文檔的內(nèi)容包括生產(chǎn)管理、質(zhì)量管理業(yè)務(wù)流程的用戶需求。

2.3.3 用戶需求定義

表2 為用戶需求定義，其包括子流程編號、用戶需求編號以及用戶需求描述。

表2 用戶需求定義

2.4 功能需求規(guī)范

2.4.1 目的

文檔的目的是為了定義企業(yè)實(shí)施并使用系統(tǒng)的功能需求。

2.4.2 范圍

文檔的內(nèi)容包括企業(yè)生產(chǎn)、質(zhì)量管理業(yè)務(wù)流程的功能需求。

2.4.3 子流程功能需求定義

表3 為子流程功能需求定義，其文檔應(yīng)該具備功能需求編號及詳細(xì)描述。

2.5 設(shè)計(jì)需求規(guī)范

2.5.1 目的

文檔的目的是描述系統(tǒng)模塊的設(shè)計(jì)規(guī)范，簡述模塊中重要功能的輸入、輸出項(xiàng)及實(shí)現(xiàn)邏輯。

表3 子流程功能需求定義

2.5.2 范圍

文檔的內(nèi)容包括模塊業(yè)務(wù)流程中識別的被評估為高風(fēng)險的系統(tǒng)功能的設(shè)計(jì)需求。本文檔記錄的系統(tǒng)功能已對業(yè)務(wù)風(fēng)險、技術(shù)風(fēng)險、GMP風(fēng)險進(jìn)行了功能性風(fēng)險評估，3個維度均被評估為高風(fēng)險系統(tǒng)功能編寫設(shè)計(jì)需求。

2.5.3 功能描述

表4 為功能描述，其包括：（1）設(shè)計(jì)需求編號；（2）所實(shí)現(xiàn)的功能；（3）功能的輸入項(xiàng)目；（4）功能的輸出項(xiàng)目；（5）邏輯流程描述；（6）其他功能的接口和限制條件；（7）功能所需達(dá)到的性能要求；（8）測試要點(diǎn)。

表4 功能描述

2.6 安裝確認(rèn)

安裝確認(rèn)是指檢查、測試或其他核實(shí)，從而證明軟件和硬件的安裝、配置是正確的。

2.6.1 安裝確認(rèn)協(xié)議

2.6.1.1 目的

編寫本安裝確認(rèn)協(xié)議的目的是為了描述系統(tǒng)進(jìn)行安裝確認(rèn)將要執(zhí)行的各項(xiàng)任務(wù)。

2.6.1.2 方法

針對系統(tǒng)應(yīng)用的階段，可以將驗(yàn)證分為前驗(yàn)證或回顧性驗(yàn)證，驗(yàn)證系統(tǒng)生產(chǎn)運(yùn)行環(huán)境或驗(yàn)證環(huán)境范圍內(nèi)的硬件和軟件是否符合IT基礎(chǔ)設(shè)施和軟件規(guī)范定義的標(biāo)準(zhǔn)。

2.6.1.3 范圍

該安裝確認(rèn)協(xié)議適用范圍為系統(tǒng)的驗(yàn)證環(huán)境和生產(chǎn)環(huán)境的基礎(chǔ)設(shè)施和軟件。

該安裝確認(rèn)協(xié)議的測試實(shí)例，在被執(zhí)行之前，需要經(jīng)過審批，審批通過之后將被用來檢驗(yàn)驗(yàn)證。

該安裝確認(rèn)協(xié)議需要在進(jìn)行安裝確認(rèn)測試活動開始之前被審批。完成安裝確認(rèn)測試之后，安裝確認(rèn)報告將會被撰寫，其中將會包括安裝的滿意度和發(fā)現(xiàn)的問題。

2.6.1.4 風(fēng)險評估

本風(fēng)險估會在執(zhí)行此協(xié)議時被執(zhí)行。對于軟硬件的風(fēng)險評估，將基于該軟硬件是否對運(yùn)行確認(rèn)測試和性能確認(rèn)測試產(chǎn)生影響和該軟硬件是否將應(yīng)用于生產(chǎn)環(huán)境。如果符合以上2種情況中的任何一種，將判定該軟硬件的風(fēng)險等級為高。

2.6.1.5 角色與職責(zé)

定義項(xiàng)目參與人員及需要的角色，如質(zhì)量職責(zé)、信息系統(tǒng)職責(zé)、測試職責(zé)、驗(yàn)證團(tuán)隊(duì)等。

2.6.1.6 測試實(shí)例內(nèi)容

IT基礎(chǔ)設(shè)施驗(yàn)證包括：（1）物理環(huán)境；（2）系統(tǒng)崩潰；（3）訪問安全；（4）數(shù)據(jù)完整。

2.6.1.7 系統(tǒng)管理流程驗(yàn)證

系統(tǒng)管理流程驗(yàn)證包括：（1）服務(wù)器運(yùn)行（時鐘驗(yàn)證）；（2）系統(tǒng)狀態(tài)檢查；（3）定期維護(hù)；（4）系統(tǒng)清理；（5）系統(tǒng)診斷，性能評估；（6）系統(tǒng)電力供應(yīng)和后備電源。

2.6.1.8 物理安全流程驗(yàn)證

物理安全流程驗(yàn)證包括：（1）緊急情況條例；（2）訪問者/承包商條例；（3）機(jī)房訪問。

2.6.1.9 邏輯安全流程驗(yàn)證

邏輯安全流程驗(yàn)證包括：（1）系統(tǒng)訪問控制；（2）密碼變更方式和頻率；（3）病毒防護(hù)/探查方法和頻率；（4）自動注銷功能；（5）訪問復(fù)原要求流程。

2.6.1.10 培訓(xùn)

所有參加安裝確認(rèn)的人員，都應(yīng)該參加足夠的培訓(xùn)，以完成所分配的任務(wù)并明確培訓(xùn)的內(nèi)容。

2.6.1.11 流程

在執(zhí)行安裝確認(rèn)測試實(shí)例之前，以下工作必須完成：（1）安裝確認(rèn)協(xié)議需要被批準(zhǔn)；（2）軟硬件的風(fēng)險評估需被確認(rèn)；（3）每一個測試實(shí)例需要被批準(zhǔn)。

2.6.1.12 測試執(zhí)行

在正式測試前，需要對以下問題作出說明：系統(tǒng)訪問、閱讀測試實(shí)例、測試命令或數(shù)據(jù)輸入、系統(tǒng)截屏、測試結(jié)果、測試者姓名以及測試日期、測試員錯誤、非預(yù)期結(jié)果。

2.6.1.13 測試偏差

如果某種測試結(jié)果不能滿足之前提供的期望結(jié)果，測試員由于某種原因不能完成整個測試，或者驗(yàn)證團(tuán)隊(duì)主管決定某個測試結(jié)果不滿足預(yù)期結(jié)果則驗(yàn)證團(tuán)隊(duì)主管需要記錄該測試偏差，測試員需要填寫測試偏差記錄。內(nèi)容應(yīng)包括：測試偏差描述、偏差文檔、測試偏差分類、測試偏差調(diào)查、重新測試說明、重新測試、測試審核和結(jié)束、測試事件匯報和跟蹤。

2.6.1.14 測試結(jié)果審查

在每一個測試實(shí)例完成時，測試實(shí)例及其支持文檔應(yīng)被測試員和驗(yàn)證團(tuán)隊(duì)主管獨(dú)立審查，以確保測試結(jié)果的完成，包括對于測試偏差報告的審核、安裝確認(rèn)測試實(shí)例的審核等。

2.6.1.15 安裝確認(rèn)報告

安裝確認(rèn)報告將在測試完成后被編制和審批，該報告包含：（1）安裝確認(rèn)測試的概要；（2）各安裝確認(rèn)測試實(shí)例的結(jié)果；（3）產(chǎn)生的偏差事件以及結(jié)果；（4）與原測試計(jì)劃的偏離；（5）結(jié)果可接受性的結(jié)論。

2.6.2 安裝確認(rèn)測試腳本

安裝確認(rèn)測試腳本（表5）具體內(nèi)容如下：

（1）需要明確測試的環(huán)境及服務(wù)器名稱、環(huán)境名稱等詳細(xì)描述。

（2）測試記錄應(yīng)包括：規(guī)范描述、測試結(jié)果復(fù)核、步驟、操作/步驟描述、測試活動、預(yù)期結(jié)果、測試結(jié)果、測試結(jié)論、通過/不通過。

（3）總體測試結(jié)果：對測試結(jié)果作出判斷通過、不通過、在條件下通過的結(jié)論。

（4）審批矩陣。

（5）測試支持文檔：將測試過程中的主要結(jié)果以截圖方式提供。

表5 安裝確認(rèn)測試腳本

2.6.3 安裝確認(rèn)報告

文檔的目的是對安裝確認(rèn)測試活動以及結(jié)果作出綜合性的評價。安裝確認(rèn)測試已經(jīng)執(zhí)行，安裝確認(rèn)的目的是確認(rèn)系統(tǒng)的軟硬件已經(jīng)按照需求安裝，并能支撐系統(tǒng)的運(yùn)作。

2.6.3.1 詳細(xì)描述

記錄安裝測試腳本的實(shí)例匯總（表6），所有的測試腳本已經(jīng)完成，并對所列項(xiàng)目以表格形式匯總測試結(jié)果，應(yīng)包括：安裝確認(rèn)編號、測試實(shí)例名、生產(chǎn)環(huán)境（通過/不通過）、驗(yàn)證環(huán)境（通過/不通過）。

表6 安裝測試腳本的匯總

2.6.3.2 偏差記錄

測試員在IQ測試中發(fā)現(xiàn)的偏差已被記錄，驗(yàn)證團(tuán)隊(duì)已經(jīng)對偏差進(jìn)行了評估，并針對評估的結(jié)果制定了偏差處理的解決方案。根據(jù)解決方案，驗(yàn)證團(tuán)隊(duì)已經(jīng)對系統(tǒng)進(jìn)行了相應(yīng)的變更并進(jìn)行了重新測試。

2.6.3.3 偏差最終狀態(tài)

安裝協(xié)議中規(guī)定測試中出現(xiàn)的偏差需要重新測試，并在處理結(jié)果（表7）中顯示偏差描述、處理結(jié)果、偏差最終狀態(tài)，然后確認(rèn)是否同意關(guān)閉。

表7 偏差最終狀態(tài)處理結(jié)果

2.6.3.4 結(jié)論

安裝確認(rèn)已經(jīng)按照安裝確認(rèn)協(xié)議完整執(zhí)行。安裝確認(rèn)測試腳本已經(jīng)完成編制，并經(jīng)過審批和簽署。所有的偏差已經(jīng)被記錄、報告、分析和處理，所有的偏差都已被關(guān)閉，可以進(jìn)行運(yùn)行確認(rèn)測試。

2.7 運(yùn)行確認(rèn)

運(yùn)行確認(rèn)是指按照規(guī)范來進(jìn)行的系統(tǒng)測試或其他核實(shí)活動，用來證明功能的正確運(yùn)行能夠支持所有規(guī)定運(yùn)行范圍內(nèi)的具體業(yè)務(wù)流程。

2.7.1 運(yùn)行確認(rèn)協(xié)議

2.7.1.1 目的

運(yùn)行確認(rèn)協(xié)議的目的是記錄系統(tǒng)的運(yùn)行與用戶要求及功能描述相一致的驗(yàn)證過程。在批準(zhǔn)和執(zhí)行本運(yùn)行確認(rèn)協(xié)議并執(zhí)行相關(guān)測試后，編制運(yùn)行確認(rèn)報告，管理層對運(yùn)行確認(rèn)報告的審批表示系統(tǒng)的功能運(yùn)行已處于驗(yàn)證狀態(tài)，可以進(jìn)行下一步的性能確認(rèn)。

2.7.1.2 范圍

運(yùn)行確認(rèn)測試的功能范圍為規(guī)范階段定義的系統(tǒng)功能需求，包括生產(chǎn)管理模塊、質(zhì)量管理模塊等。

2.7.1.3 運(yùn)行確認(rèn)方法

文件定義了運(yùn)行確認(rèn)的目標(biāo)、范圍、職責(zé)、方法、執(zhí)行流程及驗(yàn)收標(biāo)準(zhǔn)。對于GMP風(fēng)險歸類被定義為“高”風(fēng)險的功能需求，在運(yùn)行確認(rèn)測試中將進(jìn)行重點(diǎn)測試。

（1）功能測試：運(yùn)行確認(rèn)單元功能測試是用來證明系統(tǒng)功能的運(yùn)作符合項(xiàng)目的設(shè)計(jì)的，單元功能測試可以確認(rèn)系統(tǒng)的運(yùn)作功能是否能滿足企業(yè)在功能需求文檔中的要求。

（2）測試環(huán)境：運(yùn)行確認(rèn)單元測試會在信息系統(tǒng)的驗(yàn)證環(huán)境中執(zhí)行，該環(huán)境需要包括所有系統(tǒng)功能以及運(yùn)行確認(rèn)范圍下定制的對象。任何與單元測試、偏差/錯誤修復(fù)不相關(guān)的系統(tǒng)配置更新會被歸檔，且按照項(xiàng)目變更控制流程來評估。

（3）運(yùn)行確認(rèn)測試的建立和審批：每個編制完成的測試腳本會在執(zhí)行之前被業(yè)務(wù)部門團(tuán)隊(duì)主管及驗(yàn)證團(tuán)隊(duì)主管審批。對于已經(jīng)審批的文檔如有任何更改，需要遵循文件控制流程。

（4）執(zhí)行運(yùn)行確認(rèn)測試：經(jīng)審批的運(yùn)行確認(rèn)測試腳本將被測試員執(zhí)行測試，將執(zhí)行運(yùn)行確認(rèn)單元測試腳本的結(jié)果以及相關(guān)的截屏打印出來，并在打印出的文件上簽署名字和日期。

（5）驗(yàn)證：驗(yàn)證主管需在執(zhí)行測試腳本前審查和批準(zhǔn)運(yùn)行確認(rèn)協(xié)議以及每個運(yùn)行確認(rèn)測試腳本，驗(yàn)證團(tuán)隊(duì)?wèi)?yīng)確保測試環(huán)境已被正確安全地建立，確保驗(yàn)證人員得到培訓(xùn)并熟悉協(xié)議中所確定的流程。驗(yàn)證主管需要評估運(yùn)行確認(rèn)的整體結(jié)果，來決定其是否滿足驗(yàn)收標(biāo)準(zhǔn)。

（6）測試腳本的執(zhí)行和審批：測試員需要遵循測試腳本中的測試步驟，記錄測試的實(shí)際結(jié)果，按需要提供系統(tǒng)截屏。測試員需要評估測試的實(shí)際結(jié)果，并確定它們是否滿足預(yù)期結(jié)果。如果滿足了預(yù)期結(jié)果，測試員需要標(biāo)注該步驟為“通過”，如果沒有滿足預(yù)期結(jié)果，測試員需要標(biāo)注該步驟為“未通過”，并且記錄為一個偏差。測試腳本應(yīng)當(dāng)在執(zhí)行前由驗(yàn)證主管審批。

（7）測試腳本執(zhí)行后的審查：職能團(tuán)隊(duì)主管需審查測試員的測試結(jié)果，也需要確認(rèn)提供的相關(guān)文檔與腳本執(zhí)行的結(jié)論（通過/未通過）相符，并提交驗(yàn)證主管審查批準(zhǔn)。

2.7.1.4 偏差管理

（1）偏差記錄。當(dāng)測試結(jié)果與預(yù)期結(jié)果或者功能規(guī)范不符時，測試員需要記錄為一個偏差，并記錄相關(guān)的測試步驟編號。

（2）偏差分類。偏差可以分為嚴(yán)重、高、中、低4類。

（3）測試偏差調(diào)查：系統(tǒng)管理員、測試員和驗(yàn)證團(tuán)隊(duì)主管會評估每一個測試事件及其成因。

（4）重新測試。如果測試事件報告的結(jié)論是需要重新測試，驗(yàn)證團(tuán)隊(duì)主管將發(fā)布運(yùn)行確認(rèn)重新測試副本，需包含相關(guān)的測試實(shí)例，標(biāo)記并簽名相關(guān)測試會被重新執(zhí)行。測試完成后，測試人員將所有的文檔遞交給驗(yàn)證團(tuán)隊(duì)主管。

（5）最終協(xié)議審批及驗(yàn)收標(biāo)準(zhǔn)。在測試執(zhí)行結(jié)束后且執(zhí)行性能確認(rèn)測試前，必須滿足下列驗(yàn)收標(biāo)準(zhǔn)：此協(xié)議下的所有測試腳本都被執(zhí)行，且相關(guān)的系統(tǒng)截屏或者其他支持文檔都已提交。所有測試步驟被標(biāo)注為“通過”，當(dāng)標(biāo)注為“未通過”時，相應(yīng)的偏差被修復(fù)或已擁有合適的替代方案。偏差只有不影響用戶使用系統(tǒng)時，在結(jié)束運(yùn)行確認(rèn)后，才可以允許維持“未關(guān)閉”狀態(tài)。嚴(yán)重偏差和高偏差必須修復(fù)，或者至少有過渡時期的解決方案。中低偏差需要先確認(rèn)分類是否準(zhǔn)確，并提出相應(yīng)的解決方案。

2.7.2 運(yùn)行確認(rèn)測試腳本

2.7.2.1 目的

文檔的目的在于確認(rèn)系統(tǒng)滿足了功能需求，并且系統(tǒng)能夠用來執(zhí)行性能確認(rèn)測試。

2.7.2.2 測試范圍

文檔包括生產(chǎn)管理、質(zhì)量管理流程的功能需求。

2.7.2.3 測試接受標(biāo)準(zhǔn)

測試結(jié)果與預(yù)期結(jié)果一致為通過，否則不通過。

2.7.2.4 測試環(huán)境描述

說明服務(wù)器名稱、測試環(huán)境、軟件版本等。

2.7.2.5 測試腳本

測試腳本中申明功能需求的編號、測試結(jié)果的復(fù)核，以及測試的步驟、操作描述、測試數(shù)據(jù)、預(yù)期結(jié)果、測試結(jié)果和測試結(jié)論。

2.7.2.6 偏差記錄

測試結(jié)果的審批。

2.7.3 運(yùn)行確認(rèn)報告

文檔目的是對運(yùn)行確認(rèn)測試活動以及結(jié)果給出綜合性的評價。運(yùn)行確認(rèn)測試已經(jīng)完成，運(yùn)行確認(rèn)的目的是確認(rèn)系統(tǒng)的功能需求已得到滿足，系統(tǒng)可以繼續(xù)執(zhí)行性能確認(rèn)的測試。

2.7.3.1 測試詳述

測試實(shí)例匯總，所有測試已經(jīng)執(zhí)行完畢。

2.7.3.2 偏差記錄（略）

2.7.3.3 結(jié)論

運(yùn)行確認(rèn)是已經(jīng)按照運(yùn)行確認(rèn)協(xié)議被完整地執(zhí)行。運(yùn)行確認(rèn)測試腳本已經(jīng)完成編制，經(jīng)過審批和簽署。所有的偏差已經(jīng)被記錄、報告、分析和處理，所有的偏差都已被關(guān)閉，可以進(jìn)行性能確認(rèn)測試。

2.8 性能確認(rèn)

通過測試和其他活動來證明系統(tǒng)符合預(yù)定用途，并允許按照所規(guī)定要求進(jìn)行系統(tǒng)驗(yàn)收。

2.8.1 性能確認(rèn)協(xié)議

2.8.1.1 目的

性能確認(rèn)是指通過文件記錄證明企業(yè)實(shí)施系統(tǒng)在業(yè)務(wù)流程和運(yùn)行環(huán)境范圍內(nèi)，能夠按照書面的預(yù)先已批準(zhǔn)的用戶需求規(guī)范正確運(yùn)行所要求的業(yè)務(wù)流程活動。性能確認(rèn)將使用集成的測試業(yè)務(wù)場景。性能確認(rèn)使用的是真實(shí)的業(yè)務(wù)數(shù)據(jù)，針對用戶角色安全功能的安全測試將被包含在性能確認(rèn)中。

2.8.1.2 系統(tǒng)描述

系統(tǒng)包含生產(chǎn)管理模塊和質(zhì)量管理模塊集成。

2.8.1.3 驗(yàn)證范圍

驗(yàn)證范圍僅限于在驗(yàn)證主計(jì)劃（VMP-CN）中確定的企業(yè)實(shí)施的系統(tǒng)。性能確認(rèn)測試的功能范圍為規(guī)范階段定義的用戶需求規(guī)范。在規(guī)范階段定義的用戶需求涉及生產(chǎn)業(yè)務(wù)流程、QA業(yè)務(wù)流程以及生產(chǎn)管理模塊、質(zhì)量管理模塊等系統(tǒng)模塊。

2.8.1.4 性能確認(rèn)方法（略）

2.8.1.5 測試數(shù)據(jù)需求

性能確認(rèn)使用的是真實(shí)的業(yè)務(wù)數(shù)據(jù)，來確保每個單元模塊聯(lián)合起來操作后也能正常穩(wěn)定地運(yùn)作。

2.8.1.6 職責(zé)

定義性能確認(rèn)的每個任務(wù)的執(zhí)行和審核職責(zé)。

2.8.1.7 驗(yàn)收標(biāo)準(zhǔn)

當(dāng)下列條件滿足時，性能確認(rèn)被認(rèn)為滿足驗(yàn)收標(biāo)準(zhǔn)：（1）用戶需求已得到滿足，系統(tǒng)能持續(xù)運(yùn)作；（2）每個測試腳本的驗(yàn)收標(biāo)準(zhǔn)已得到滿足；（3）所有性能確認(rèn)的測試已經(jīng)完成并圓滿通過；（4）異常情況被歸檔且解決；（5）性能確認(rèn)報告圓滿完成，通過審核并得到審批。

2.8.1.8 測試的執(zhí)行

（1）測試腳本審批：每個測試腳本在執(zhí)行前需要得到職能團(tuán)隊(duì)主管和驗(yàn)證主管的批準(zhǔn)。

（2）腳本執(zhí)行：測試員需要遵循測試腳本中的測試步驟，記錄測試的實(shí)際結(jié)果，按需要提供系統(tǒng)截屏。測試員需要評估測試的實(shí)際結(jié)果，并決定它們是否滿足預(yù)期結(jié)果。如果滿足了預(yù)期結(jié)果，測試員需要標(biāo)注該步驟為“通過”，如果沒有滿足預(yù)期結(jié)果，測試員需要標(biāo)注該步驟為“未通過”，并且記錄為一個偏差。

（3）執(zhí)行后審查：職能團(tuán)隊(duì)主管需要對測試員提供的文檔以及測試結(jié)果進(jìn)行審查。

2.8.1.9 偏差管理（略）

2.8.1.10 偏差記錄

當(dāng)測試結(jié)果與預(yù)期結(jié)果或者功能規(guī)范不符時，測試員需要記錄為一個偏差，并記錄相關(guān)的測試步驟編號。

2.8.1.11 偏差分類（同運(yùn)行確認(rèn)測試協(xié)議）

2.8.2 性能確認(rèn)測試腳本

2.8.2.1 目的

文檔的目的在于確認(rèn)系統(tǒng)的生產(chǎn)管理、質(zhì)量管理滿足了性能需求。

2.8.2.2 測試范圍

測試性能確認(rèn)包括生產(chǎn)流程、質(zhì)量管理流程系統(tǒng)性能需求。

2.8.2.3 測試條件的建立（略）

2.8.2.4 測試接受標(biāo)準(zhǔn)（略）

2.8.2.5 測試詳述

測試環(huán)境說明服務(wù)器名稱、測試環(huán)境、軟件版本等。

2.8.2.6 測試腳本

測試腳本中應(yīng)申明功能需求的編號、測試結(jié)果的復(fù)核以及測試的步驟、操作描述、測試數(shù)據(jù)、預(yù)期結(jié)果、測試結(jié)果和測試結(jié)論。

2.8.2.7 偏差記錄（略）

2.8.2.8 測試結(jié)果審批（略）

2.8.3 性能確認(rèn)報告

文檔的目的是對性能確認(rèn)測試活動以及結(jié)果作出綜合性的評價，性能確認(rèn)目的是確認(rèn)系統(tǒng)的用戶需求已經(jīng)得到滿足。

2.8.3.1 測試詳述

列出性能測試腳本的實(shí)例匯總，列出所有的測試腳本并已經(jīng)執(zhí)行完畢。

2.8.3.2 偏差記錄（略）

2.8.3.3 結(jié)論

性能確認(rèn)已經(jīng)按照性能確認(rèn)協(xié)議被完整地執(zhí)行。性能確認(rèn)測試腳本已經(jīng)完成編制，經(jīng)過審批和簽署。所有的偏差已經(jīng)被記錄、報告、分析和處理，所有的偏差都已被關(guān)閉。

2.9 驗(yàn)證總結(jié)報告

2.9.1 項(xiàng)目概述（略）

2.9.2 驗(yàn)證文件清單

驗(yàn)證主計(jì)劃（VMP）、安裝確認(rèn)協(xié)議（IQP）、安裝確認(rèn)報告（IQR）、運(yùn)行確認(rèn)協(xié)議（OQP）、運(yùn)行確認(rèn)報告（OQR）、性能確認(rèn)協(xié)議（PQP）、性能確認(rèn)報告（PQR）。2.9.3 人員與職責(zé)（略）

2.9.4 驗(yàn)證總結(jié)

驗(yàn)證方法依據(jù)國際制藥工程協(xié)會（ISPE）的《良好自動化生產(chǎn)實(shí)踐指南》（GAMP5）中類別軟件產(chǎn)品（可配置軟件產(chǎn)品）適用的V字模型。驗(yàn)證過程中編制的所有文檔均經(jīng)過審批。

2.9.5 驗(yàn)證主計(jì)劃描述

驗(yàn)證主計(jì)劃描述包括：（1）業(yè)務(wù)流程描述；（2）用戶需求規(guī)范描述；（3）功能需求規(guī)范描述；（4）設(shè)計(jì)需求規(guī)范描述；（5）安裝確認(rèn)；（6）運(yùn)行確認(rèn)；（7）性能確認(rèn)；（8）用戶培訓(xùn)驗(yàn)證結(jié)果判定和結(jié)論。

3 結(jié)語

GMP附錄就驗(yàn)證的定義可以看出，驗(yàn)證是計(jì)算機(jī)化系統(tǒng)生命周期的一個組成部分，是持續(xù)地貫穿于整個生命周期的活動，在每一階段都需要產(chǎn)生驗(yàn)證活動，尤其進(jìn)入運(yùn)行階段，從系統(tǒng)的變更管理活動而言，應(yīng)更加注重基于風(fēng)險評估的驗(yàn)證活動，只有如此，才能使系統(tǒng)永久處于可驗(yàn)證的良好運(yùn)行狀態(tài)。