本站小編為你精心準備了計算機化系統驗證的實際應用參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

摘要：2010版藥品生產質量管理規范(GMP)附錄《計算機化系統》的頒布，為我國制藥行業計算機化系統的管理提出了要求。而其中計算機化系統驗證的水平是國內藥品生產企業的短板。基于《良好自動化生產實踐指南(5版)》(GAMP5)這一國際通用的計算機化系統驗證指南，本文以4類軟件中最為復雜的SAP(即systemapplicationsandproducts)軟件驗證為例，具體說明如何實施計算機化系統驗證。

關鍵詞：良好自動化生產實踐指南(5版)(GAMP5)；計算機化系統；驗證

《良好自動化生產實踐指南(5版)》(GoodAutomatedManufacturingPractice-Rev5，GAMP5)是由國際制藥工程協會(ISPE)主編的計算機化系統驗證的指導方針。GAMP5使用廣泛，并得到了國際監管部門的公認，已有較多文獻對其進行了詳細描述。例如計算機化系統的定義、軟硬件的分類，以及基于不同類型軟件的可增減的驗證生命周期V模型等。因此本文不在概念及理論上給予太多篇幅的描述，而是直接以業內運用最為普遍的企業資源計劃(ERP)軟件SAP(systemapplicationsandproducts)驗證過程為例，講述如何以GAMP5為基礎開展符合中國、美國以及歐盟藥品生產質量管理規范(GMP)的計算機化系統驗證。

1供應商評估

對于供應商的評估是2010版GMP附錄《計算機化系統》第四條“……企業應對基于風險評估的結果提供與供應商質量體系和審計信息相關的文件”的要求[1]。基于風險的供應商評估方法重點關注于重要供應商，以下是供應商評估的3種主要類型：基于現有信息的基礎評估；使用調查問卷的郵件調查；由相關專家、審計員或審計小組進行的現場審計。需要注意的是SAP軟件分為軟件提供商和軟件實施商，經風險分析認為SAP軟件屬于全球同行業使用最廣泛的ERP軟件，因此對于軟件提供商的評估可以以調查問卷的郵件調查形式開展。而對于國內的軟件實施商，水平參差不齊，因此基于風險的考慮應該由相關專家、審計員或審計小組進行的現場審計[2]。

1.1郵件審計通常郵件審計的調查問卷包含以下內容：公司概述，包括所采購產品的生產地址；組織機構，角色和職責，員工培訓和經驗；關鍵產品和(或)服務的歷史與開發計劃；質量管理體系在公司層面和相關產品生產過程中的執行情況；產品/項目管理；軟件開發生命周期過程與交付物；軟件開發生命周期支持流程；安全性。

1.2現場審計現場審計人員中必須包括質量部門人員，還應指定審計組長，由其對審計的實施負全部責任。審計時可以邀請第三方審計人員共同參與，但應該事先通知供應商。審計主要通過質疑和檢查來確定供應商的運營是否充分，重點關注的應該是供應商的質量管理體系是否能確保交付符合要求的產品，并且在產品生命周期內始終給予技術和服務上的支持。現場審計由3個部分組成：開始審計會議、審查和檢查、結束審計會議。

2起草驗證主計劃驗證

主計劃(VMP)是整個SAP軟件驗證過程的頂層文件，所有接下來的驗證工作都以此文件為核心開展，驗證主計劃的內容通常包括以下內容。

2.1簡介簡介部分應該包括：驗證目標、驗證依據、驗證原因、驗證類型、系統使用描述、驗證計劃下發清單。

2.2驗證范圍通常ERP軟件的實施會涉及辦公用品采購、庫存管理、財務等非GMP模塊，所以應明確本次驗證的活動范圍。

2.3驗證策略驗證策略是驗證主計劃的核心內容，在驗證策略的綜述中應明確計算機化系統的編號、人員的培訓方式、第三方服務參與的分工、所有本次驗證文檔的管理要求。隨后根據系統生命周期(SDLC)原則將計算機化系統驗證分為5個階段實施。①項目啟動和計劃，包含項目計劃的建立、計算機化系統的GxP(制藥行業相關規范的統稱，如GMP、GLP等)相關性判定。②開發與獲得，包含定義需求、供應商評估報告、系統分類、定義系統說明、風險評估、設計確認。③實施、驗收與，包含安裝、測試、權限測試、單元測試、集成測試、用戶驗收測試(UAT)、追溯矩陣、操作規程和手冊、培訓、系統驗收和。④系統運行和維護，包含問題管理、配置管理及變更管理、業務持續性計劃、定期檢查、記錄保存及歸檔、偏差管理。⑤系統退役和停運。

2.4組織機構規定驗證實施包含的所有角色及其職責。

3計算機化系統的GxP相關性判定

根據表1中所示問題進行判斷，了解系統所能提供的功能。如果一個或多個問題的回答是“是”，則系統存在一個或多個功能要遵循GxP規范；如果所有問題的回答是“否”，則系統沒有任何功能需要遵循GxP規范[3]。

4用戶需求說明(URS)

URS旨在闡述用戶的需求，描述了用戶對質量管理的業務過程及功能的需求。這份文件是構建起項目和系統的文件體系的基礎，同時也是系統設計和驗證的可接受標準的依據。用戶需求應當基于對產品和流程的理解，包括對關鍵質量屬性(criticalqualityattribution，CQA)法規的理解，按自上而下的方式撰寫。URS不應該陷入技術細節，技術解決方案會在后續的功能說明(FS)中描述。當沒有選定商用現成軟件系統時，應避免需求陷入空想；當選定了商用現成軟件系統時，應避免陷入解決方案的陳述。

4.1流程圖SAP軟件是一個全球各行業均可以使用的ERP系統。藥品生產企業的部分業務流程要符合GMP規范，在此情況下SAP軟件的一些標準功能需要進行改變。實際上，SAP軟件也能根據企業的實際情況進行有限的配置和開發。所以，業務流程所有者應該和軟件實施顧問商討確定所有業務的流程，并以流程圖的形式進行描述。

4.2需求內容根據業務流程圖，將其中每一個流程節點所要達到的預期效果用文字描述清楚就得到了需求內容，同時對每一條需求的優先級和其是否與GMP相關進行評估。用戶需求GMP相關性判定是系統GMP相關性判定的延伸。這項評估有利于辨別更需要合規關注的活動和功能，可以用來在后續的生命周期中，特別是測試過程中提高測試的效率。GMP評估還需要考慮到健康因素，即對于系統使用者可能的潛在影響。GMP評估應該包含對于電子記錄和電子簽名的使用。只有在電子記錄和電子簽名信息充足的時候，GMP評估才有意義。然而，在書寫URS的時候，這些信息有可能是不足、不連貫、甚至是錯誤的。當發生這種情況時，可以把這次評估當成一次預評估，當信息充分之后，在后續的階段進行再評估。URS的優先級可以使軟件供應商、實施商更加有目的性，更加清晰地理解用戶的需求。評估原則為：強制的、必須的需求為高，例如業務強烈需求、直接影響到產品的質量或者法規的需求；與質量相關，但沒有直接影響到最終產品的質量，對于業務有重要提升作用的需求為中；僅對系統的功能有提升作用的需求為低。

5定義系統說明(SS)

系統說明包括功能說明(FS)和設計說明(DS)，以可驗證的方式精確描述了一個系統或組件的功能，以及提供判定這些功能是否能滿足需求的流程。系統說明和功能說明是系統對用戶需求說明的描述，是針對用戶需求說明制定的一個可行的解決方案。功能說明和設計說明在設計階段創建，在單元測試和集成測試中被驗證。URS、SS、FS和DS的關系見圖1[4]。系統說明舉例詳見表4。功能說明通過用例的形式詳細說明了每個用例的用戶操作、系統響應和細節需求。每個用例通過用例表(表5)表達了系統應該如何和最終用戶或其他系統進行交互，來達成一個指定的業務目標。

6風險評估

風險評估是基于對用戶需求的詳細評估，在適當的情況下設計確認(DQ)可能被包含在風險評估中。風險評估分為風險識別和風險控制兩部分。風險識別主要有：風險確認，識別可能出現的故障以及產生的影響和產生的原因；風險分析，判斷影響程度、發生概率、偵測概率；風險評估，對該故障進行風險分級，并確定風險優先級，通常采用“用例表”的形式，見表5。風險控制主要有：風險降低，針對可能出現的故障提出降低風險的措施；風險交流，確定可以驗證該措施的文檔；風險回顧，重新進行風險分析，確保降低風險優先級為高的問題。用于風險評估的工具有很多，且已有文獻對風險評估在驗證中的應用進行詳細描述，本文不再重復。

7數據遷移

數據可靠性是當下GMP熱議的話題之一，新系統的上線必定會涉及舊數據的保存與轉移。舊數據有紙質和電子兩種形式，為了保證數據遷移時的完整性和可追溯性，應該針對系統功能進行劃分，建立所有新系統所需數據的遷移方案。數據遷移方案應該遵循以下策略：數據源定義，在舊系統和文檔中定義數據源，確認數據源的特性并重點關注GxP相關的數據，見表7；數據映射，定義并文檔化每一個將在SAP系統中產生的字段與舊系統或者紙質文檔中字段的映射關系；數據收集，根據源數據的情況確定是否需要使用工具導入(大批量GxP相關數據的導入應使用工具)，確認收集模板；根據數據收集模板收集數據并與源數據比對確認；數據輸入，對手工輸入的數據進行復核，使用遷移工具則需提供遷移工具驗證文檔；數據確認，數據輸入后復核，并導出簽字確認。

8SAP軟件安裝確認

SAP系統的安裝確認主要分為安裝確認(IQ)、運行確認(OQ)和性能確認(PQ)。

8.1IQ確認硬件的安裝環境是否符合要求；確認硬件性能是否符合軟件運行要求；確認操作系統是否滿足軟件運行要求；檢查最新安裝相關的SAP日志；基礎安裝參數定義；創建必要的文件系統；檢查系統時區；安裝介質準備；安裝HANA(思愛普公司開發的一款數據庫軟件)數據庫實例后安裝日志檢查；安裝SAP應用實例后安裝日志檢查。

8.2OQSTMS(SAP軟件內部傳輸方式名稱)傳輸系統功能；SAP軟件授權；SAP系統一致性檢查；SAP生產HANA數據庫切換檢查；SAPGUI(用戶圖形操作界面)訪問。

8.3PQ操作系統資源檢查；HANA數據庫狀態檢查；STMS傳輸系統功能；SAP軟件授權；SAP系統一致性檢查；SAP生產系統HANA數據庫備份檢查；SAPGUI訪問。

9測試

測試是整個SAP系統驗證最關鍵的環節之一，通過測試來確認系統的所有功能都能符合URS的條款。通常來說，所有測試活動都要根據已文檔化的系統需求來執行并記錄。同時文檔化的風險分析結果也決定了測試范圍：任何使風險最小化的測試用例都應該包含于測試范圍中。在適當的時候，反向測試(禁止行為的測試，測試相應的活動或訪問以確保其沒有執行或訪問權限)也屬于測試范圍。模塊授權和系統授權是主要運用反向測試的場景。

9.1起草測試用例測試用例是測試的方案腳本，編寫測試用例時需要確保測試內容覆蓋所有用戶需求，必要時可以追溯到系統說明(SS)和功能說明(FS)。風險評估也是編寫測試內容時需要重點參考的文檔。測試用例要重點關注GMP相關功能的測試和權限控制的測試，這些GMP相關功能的測試和權限控制的測試是用戶驗收測試中需要強制完成的部分。軟件實施商要根據所需測試的系統功能，確保提供充足的測試數據供最終用戶來進行測試用例的執行。每一個測試用例要包含測試目的、測試前提、測試過程、測試驗收及關聯文檔。在測試過程中對步驟進行編號，同時記錄模塊、部門(或崗位)、步驟、操作說明、預期結果。

9.2測試用例執行測試用例執行是基于測試用例，并附加上運行號、測試結果、測試的總體狀況及驗收。測試過程要依照測試用例中對應區域給出的執行步驟按順序進行。每一步測試均需要生成一份《測試執行記錄》，記錄測試的實際結果以及必要的截圖。實際結果的記錄不接受如“OK”、“符合”、“成功”等簡單的文字判斷。需對實際出現的結果進行描述，如展示文檔的編號、重點期望的數據等。至少要填寫“符合預期結果”、“結果符合預期”、“系統運行符合預期”等內容。對于沒有重點內容的測試步驟(如“下一個畫面出現”)，簡單的描述證明即可。

9.3測試錯誤及問題處理在進行測試時，任何實際結果和用戶需求之間的差異都需要記錄在“實際結果”中，并判定為錯誤或問題。所有錯誤和問題都要填寫相應的記錄。錯誤或問題的影響等級由指定業務驗收人和質量部門協商判定。影響等級的分類定義和處理方法參考如下。

9.3.1微小，不需要變更錯誤或問題的影響較小，不會導致其他測試步驟失敗，只需要進行微小的調整即可使該步驟符合預期結果。若在測試時可以調整，僅需在實際結果中記錄調整前后的結果，并完成錯誤或問題記錄即可。

9.3.2中等，需變更錯誤或問題的影響較大，會導致其他的測試步驟失敗，需要對系統的配置及設計文檔進行變更。影響等級確認為中等后，需填寫錯誤或問題記錄，完成系統配置及相關文檔的變更，最后將該測試用例以新的運行號執行測試。

9.3.3嚴重，測試用例停止錯誤或問題已經違背了用戶的需求，需要重新溝通需求內容并變更系統。確認后，填寫錯誤或問題記錄，在更新需求內容、系統配置及相關文檔后，重新設置新的測試用例，并執行測試。在評估錯誤或問題的影響等級后，針對該錯誤或者問題分配解決人，由解決人提出解決方案并進行處理。解決方案的實施要經過用戶驗證，確認實施后的系統功能和相關文檔符合需求。這個過程可能會需要重新執行測試用例，修訂測試用例內容，甚至生成新的測試用例。

10追溯矩陣

追溯矩陣作為支持驗證的關鍵因素和證明材料，用來建立先期產生的各種用戶需求和相關文檔之間的可追溯性。其關注的主要部分是：用戶需求、系統說明、GMP相關分析、風險分析、系統配置以及各種測試內容。

11操作規程及手冊、培訓

系統上線前應確保運行所必須的操作規程、手冊已起草并被批準和用于培訓，所需的操作規程至少應包括以下類型：《問題管理標準操作程序》、《變更標準操作程序》、《系統操作手冊》、《數據備份標準操作程序》、《數據恢復標準操作程序》、《應急準備和響應標準操作程序》、《日常檢查、維護標準操作程序》、《權限管理及設置標準操作程序》。

12中期驗證

報告至此，SAP系統上線正式啟用前的驗證工作已完成，驗證小組起草中期驗證報告，涵蓋了SAP項目實施中所有在計劃階段、開發階段和實施階段完成的驗證內容。報告中應對每一驗證內容產生的文檔編號進行整理，再次確認每一驗證內容是否都已經完成并符合要求。最終，中期驗證報告應給出是否同意系統上線啟用的結論。

13最終驗證

報告最終驗證報告通常在系統上線的1～3個月后起草，此時系統已趨于穩定，變更及問題的數量也已經回落到正常水平。最終驗證報告對系統上線后的運行情況、變更情況以及問題進行統計和分析，得出系統是否驗證通過的最終結論。

14系統運行和維護

剛上線的系統必然還會遇到各種問題，此時就應該嚴格按相關流程記錄所有的問題以及由此導致的變更，并且通常在系統運行1個月以后，針對運行情況給出最終的驗證報告。在系統的運行和維護階段應做到定期對系統進行回顧，根據問題或變更的風險程度作出是否需要補充再驗證的決定。

15系統退役

計算機化系統的退役或停運是正式終止一個系統的活動，標志著系統生命周期的結束。對于現存系統、數據和流程的潛在影響需要在退役或停運前進行檢查。硬件和軟件的退役需要制定一份項目計劃，其中的活動可包括信息和文檔的遷移、歸檔或刪除。在停運計算機化系統之后，GMP相關文檔和計算機化系統中的數據將根據相關GMP條例來保存。

作者：沈忱，陸振宇，徐秀卉，徐蓉，來聰聰 單位：杭州康恩貝制藥有限公司