計算機化系統驗證的實施基礎

吳海華

（三生國健藥業（上海）股份有限公司，上海201203）

0 引言

2015年5月26日，國家食品藥品監督管理總局（CFDA）正式頒布了關于計算機化系統專項規范的附錄，該附錄要求自2015年12月1日起開始正式施行。《計算機化系統》附錄明確了計算機化系統的范圍、原則、人員、驗證、系統等方面的要求。

計算機化系統驗證是指持續地以文件形式來證明計算機化系統的開發符合預先設定的接受標準和質量屬性原則，能夠提供滿足用戶需求的功能并且能夠穩定長期工作的過程。

計算機化系統生命周期的驗證，始于最初的用戶需求，終于退出服務。其目的就是證明設備、系統、工藝過程是符合相關標準和法規指南的，根本目的是保證患者的用藥安全，保證產品質量和數據完整性。

隨著人們對GMP理解的不斷深入與提高，國內制藥行業與國際標準的逐漸接軌，計算機化系統驗證問題阻礙了我國制藥行業的自動化和信息化發展。鑒于此，本文將結合現有法規和實際工作經驗，探討如何真正深入理解第五版《良好自動化生產實踐指南》（簡稱GAMP5）的相關概念和理論，根據不同的計算機化系統特點和要求，對計算機化系統驗證工作的實施作一基礎闡述。

1 用戶需求說明

用戶需求說明（簡稱URS）是由系統用戶和項目專家制定的，用以詳細說明計算機系統的業務需求、期望和性能指標，其包括但不限于以下內容：

1.1 系統描述

系統描述主要是描述系統能做到什么程度，如何關聯不同模塊、控制方法（例如：邏輯控制、分離控制、連鎖控制、報警控制、位置控制、溫度控制、壓力控制、時間控制、計數和其他多級控制）、實施流程、操作員的端口和安全需求。

1.2 物理要求

物理要求包括有足夠的空間、位置、周邊環境等。

1.3 硬件文件標準

硬件文件標準包括圖紙、原理圖操作指南、備件清單等。

1.4 軟件文件標準

軟件文件標準包括程序編號和修改編號、輸出接口程序和詳細說明、軟件的追加和保留條件、系統分程序圖紙和配置清單等。

1.5 測試要求

測試要求測試項目和記錄必須在系統的發展進程中進行，包括模塊測試和集成分離測試。

1.6 對供應商的其他要求

對供應商的其他要求包括在發展進程中完成系統驗證、質量控制和變更控制等。

2 供應商審計與質量計劃的審核

2.1 供應商審計

對計算機化系統的潛在供應商的審計應盡早開始。供應商審計的目的是確認供應商有成熟的質量管理系統以及有能力交付按照預定規程開發和測試的系統，且符合所有預定要求。一般供應商優先采用GAMP5或類似的生命周期驗證模型，以滿足所有要求。

表1為供應商審計方式的建議，類別從1～5順序的評價費用會越來越高，最終選擇哪種評價方法應取決于風險評估結果。評價標準包括供應商風險與產品風險。

系統所有者應證明并記錄歸檔選擇的程序。系統所有者在QA人員和IT人員幫助下對供應商進行評估，并記錄歸檔評估結果。供應商如果已經在其他項目中進行過審計，該審計結果可以被直接采用。

2.2 質量計劃的審核

計算機化系統的每個供應商應提供項目質量計劃（PQP），其應說明如何滿足最終用戶的需求，這些需求描述體現在URS、規程、VMP（驗證總計劃）中。

項目質量計劃的重要作用是說明供應商如何滿足本文中的生命周期驗證模型，作為行動控制規程的參考文件。同時，PQP應按照建立的規程起草，并滿足GAMP5需求。最終用戶對PQP進行審核和批準。

3 計算機化系統的硬件和軟件分類

對藥品生產有直接影響的計算機化系統的軟件和硬件應進行分類，以制定適當的驗證策略和范圍。在設計階段，當供應商已經確定、設計文件可供使用時，應盡早進行計算機化系統軟件和硬件的分類。

最終用戶應按照硬件和軟件的GAMP5要求進行分類，其類別如表2、表3所示。在表格中記錄分類結果，同時定義生命周期驗證模型中需要哪些活動及其責任人（供應商/最終用戶）。

4 風險評估

風險評估應被應用到所有的計算機化系統驗證活動中。基于風險的驗證應得到管理機構的支持，可以幫助降低驗證費用。

風險評估的原則是風險能在發生前被識別并被緩解。系統的風險水平取決于系統生成和/或處理記錄的數量和危險程度。典型的風險水平一般分為高、中、低三個水平。系統所有者在各驗證步驟中都需要運用風險管理方法。

表1 供應商審計方式的建議

表2 G A M P5硬件類別

表3 G A M P5軟件類別

5 驗證計劃

為保證計算機化系統驗證的正確實施，需要制定一個驗證計劃（VP）。驗證計劃需要描述所有活動，例如：URS的審核、開發計劃的審核（設計）、測試策略、數據移植的確認、驗證文件的審核和整個系統的可接受標準。

驗證計劃包括日期、每個審核和測試的責任人可接受標準，至少在這些測試上有一個索引。

驗證計劃應在開始驗證前得到責任人的批準。

6 設計說明與設計確認

6.1 設計說明

供應商應提供功能和設計說明文件，清楚、完整地描述如何滿足URS要求，系統如何運作，如何設計硬件和軟件架構。

其中，文件命名、編號取決于供應商規程，但內容應符合GAMP5要求，以確認計算機化系統URS中的所有需求在設計中得到體現，供應商應使用最終用戶提供的RTM（需求追蹤矩陣）或同等內部格式的RTM。

6.1.1 功能說明

供應商應提供計算機化系統的功能說明（FS）。

FS應描述系統怎么工作，其詳細程度應滿足后續文件的設計和功能測試的要求。功能說明應詳述系統功能及界面、計算、安全和配置等。同時，能溯源到URS的具體要求。

6.1.2 硬件設計說明

供應商應提供計算機化系統的硬件設計說明（HDS）。

HDS定義了硬件的架構和配置，包括控制器、I/O卡、計算機和界面部件等。

對于相對簡單的系統，硬件設計說明可以整合到功能設計說明中。

6.1.3 軟件設計說明

供應商應提供計算機化系統的軟件設計說明（SDS）。

SDS基于功能設計說明，對內容進行拆解，對系統使用以及軟件架構的控制流程進行定義。例如，定義軟件是否基于模塊建立以及明確各模塊之間的界面。

對于相對簡單的系統，軟件設計說明可以整合到功能設計說明中。

6.1.4 軟件模塊設計說明

供應商應提供計算機化系統每個軟件模塊的設計說明（SMDS）。

SMDS基于軟件設計說明，對內容進行拆解，詳細介紹單獨軟件模塊的運行模式。

在軟件和硬件分類時，應明確供應商是否需要提供說明給最終用戶，取決于應用的軟件類型，包括標準模塊和客戶定制模塊。其中，客戶定制模塊一般需提供SMDS；PLC系統應用一般由標準模塊和客戶定制模塊組成。

供應商有每個標準模塊的SMDS，模塊在開發測試階段應按照說明進行測試（模塊驗證后，如項目未進行變更，無需再進行測試）。用戶定制的模塊都應編寫SMDS，作為開發測試階段的參考文件，通常需要提供給最終用戶。

系統相對簡單的軟件模塊設計說明可以整合到功能說明和/或軟件設計說明中。

6.2 設計確認

設計確認（DQ）應基于供應商的設計說明，確認所有系統設計符合URS中的所有要求。

DQ更多情況下是對URS的本地化響應，逐條確認計算機化系統的URS軟件以及硬件要求是不是在設計的時候得到了響應與滿足。

7 安裝、運行、性能確認

7.1 安裝確認（IQ）

IQ是文件化地確認系統已按照編寫的并預先批準的標準進行了安裝。

IQ執行應確保該系統安裝符合設計標準，需要提供所有的技術數據，確認內容應包括但不限于：

7.1.1 文件確認

文件確認應該包括對用戶技術指南、SOP、培訓計劃、售后服務協議、設備庫存、安全程序、硬件說明、軟件說明、源代碼、儀器清單、儀器校準程序、PID、控制回路圖、I/O設備清單和連接圖、備件清單和維護規程等文件的確認。

7.1.2 安裝過程確認

確認系統安裝符合PID和操作手冊的要求。

7.1.3 環境和公共設施確認

（1）系統安裝環境的檢驗和記錄，例如潔凈水平、射頻/電磁干擾、物理保護、溫度、濕度、聲音、照明等。

（2）記錄關鍵設施以及條件，確認公共設施應該跟說明一致，包括消防報警公告、預防系統、冷卻系統、持續供電、大面積網絡連接、本地區域網絡連接、災難恢復、模擬等。

7.1.4 系統測試確認

（1）報告項目FAT的驗收測試應該完全由供應商提供，且適用于設計標準。

（2）應該對系統運行情況開展必要的測試，基本內容包括：1）所有儀器儀表應該被校準和標注過期日，校準應該有明確的標準及應提供相應的檢查證件；2）I/O信號試驗應確保信號可以在控制系統設備間進行傳輸和反饋；3）數據采集、傳送和信號記憶測試。

7.1.5 軟件安裝確認與其他測試

最終用戶負責安裝確認。如供應商有支持IQ的確認執行方案和服務，最終用戶的IQ方案可以整合或引用那些測試。

7.2 運行確認（OQ）

OQ是文件化地確認系統能按照編寫的并預先批準的標準運行，包括所有特定的運行范圍。運行確認測試按照預先批準的方案實施。

7.2.1 測試系統安全

所有邏輯系統的“最壞情況”都應該進行測試，例如使用不同權限進行測試，以便確認未經授權操作是否能被禁止。

7.2.2 控制功能的測試

根據系統要求進行各種各樣的過程控制功能的測試。通過測試“最壞情況”（例如最大通信負荷、過程相當大的數據文件等），檢查系統和決策程序的功能，應根據系統URS的對應標準進行測試。

7.2.3 測試報警及連鎖功能

根據系統操作手冊，需要在系統報警和連鎖的條件下測試相應程序的功能。

7.2.4 測試定時器和定序器

根據系統操作手冊配置相關功能，測試系統定時、定序功能是否符合預定要求。

7.2.5 測試數據處理和存儲

（1）對正確的數據存儲、準確的數據采集和系統的自我搜索的確認；

（2）確認數據輸出長度、運載和空載的處理能力；

（3）數據保存到相應文件夾的功能確認。

7.2.6 關機/恢復測試

（1）在系統關閉之前和之后檢查數據采集的情況，確保數據沒有損壞或丟失；

（2）檢查備用電源的供應、不間斷電源的供應、電力調節器和電力發電機；

（3）系統故障或失敗時，能夠根據系統的操作手冊提供系統備份。

7.2.7 其他功能測試

最終用戶負責運行確認。如供應商有支持OQ的確認執行方案和服務，最終用戶的OQ方案可以整合或引用那些測試。

7.3 性能確認（PQ）

PQ是確認系統運行過程中的有效性和穩定性方面的情況。

當一個人工系統被計算機或PLC控制系統取代時，兩者需要平行運行。

計算機化系統如果是生產系統、實驗室或者公用設施的一部分時，計算機化系統可根據設施、設備的PQ進行性能確認。對于生產設備，要進行產品規格測試，如化驗、包裝規格測試等，確保所有的過程控制功能都是有效的，應當在相同的生產條件下進行至少3個連續批次的測試。

當系統或子系統任何性能隨時間的變化有惡化的跡象時，應進行額外測試。

8 結語

《計算機化系統》附錄從正式發布至今已經有三年時間，很多國內同行普遍認為在這方面的硬件、意識、培訓不足，存在較大的法規風險。同時，設備供應商在調試設備或者實施軟件系統時，由于對計算機化系統驗證的理解不夠，使得設備、軟件系統不能完全符合計算機化系統驗證的要求，特別是在面對FDA、EMEA、CFDA的現場檢查時，常常出現各種問題。因此，真正深入理解GAMP5的相關概念和理論，根據不同的計算機化系統特點和要求，建立起各類計算機化系統科學、合理的驗證模式或標準，將是未來一個關鍵性的課題。