2010版GMP附錄：計算機化系統整體及條款解讀(完整精華版)

一、整體解讀

通讀全文，該附錄共有6章24個條款，筆者對其內容分佈整理如下：

章 節	條款數	主 要 內 容
第一章範圍	1條	講到什麼樣的計算機化系統才是需要被驗證的，以及計算機化系統的定義和構成
第二章原則	3條	講到計算機化系統驗證的目的、風險控制以及對供應商的管理要求
第三章人員	1條	講到驗證相關人員的職責、許可權和培訓要求
第四章驗證	4條	再次強調驗證範圍、程度，要建立計算機化系統清單，以及不同類別軟體的驗證策略和資料遷移要求
第五章系統	14條	從驗證系統的安裝、測試、使用、變更、資料列印、系統故障應急預案、系統的產品放行以及電子簽名作出了明確要求
第六章術語	1條	涉及電子資料、系統生命週期、資料審計跟蹤和資料完整性等名詞

從上述總結的內容分佈來看，筆者認為該附錄的核心思想體現為企業在採用計算機化系統來替代手工操作時，對藥品生產質量管理過程中的一種風險控制。本質上是藥企對自身生產經營風險的管控，從風險管理的角度來看，本附錄內容可進行重新編排為

1、風險識別（第一章 範圍&第四章 驗證 計算機化系統範圍的確定）：

2、風險評估（第二章 原則 需考慮患者安全、資料完整性和產品質量）

3、風險控制（第五章 系統 基於系統的複雜度、新穎性和類別確定驗證方案）

4、風險跟蹤（第三章 人員 明確人員職責和許可權，對風險控制措施效果跟蹤）

從流程管理的角度來看，該附錄可以從另外一個視角來進行重新解讀

1、目的：控制同GxP有關的計算機化系統的使用風險

2、範圍；藥企生產質量管理過程中涉及到的各類計算機化系統

3、原則：系統替代手工不增加總體風險，風險管理貫穿系統的全生命週期

4、方法：採用基於科學的風險評估，確定系統驗證方案、執行驗證活動

5、重點：不光是驗證的硬體、軟體本身，更是驗證系統所管控的流程；

不光確保某一個階段系統驗證合格，更要確保整個生命週期內系統處於驗證的受控狀態，例如在系統執行階段採用變更和配置管理，安全管理和再驗證等。

6、策略：根據軟體級別的不同其測試程度也不同，比如針對第5類軟體系統的原始碼稽核和功能測試；針對第4類軟體系統的配置測試，然後是基於黑盒的功能測試、需求測試以及結合實際工藝和流程的效能測試等。

二、條款解讀

原文內容：

第一條：本附錄適用於在藥品生產質量管理過程中應用的計算機化系統，計算機化系統由一系列硬體和軟體組成，以滿足特定的功能。

原文解讀：

第一條：此附錄描述了計算機化系統的適用範圍，是在藥品生產質量過程中，這是其一；其二，什麼是計算機化系統，由一系列硬體和軟體組成，從字面上來看，這個定義和“計算機系統”沒有本質區別，主要區別在於後面這幾個字“以滿足特定的功能”。按照PIC/SPI011-3指南的定義，計算機化系統（ComputerizedSystem）由計算機系統（ComputerSystem）和被其控制的功能和流程組成。

那麼，在製藥企業計算機化系統究竟包括哪些呢？下圖舉例來說明，大家就一目瞭然了，清楚多了。

原文內容：

第二條：計算機化系統代替人工操作時，應當確保不對產品的質量、過程控制和其質量保證水平造成負面影響，不增加總體風險。

原文解讀：

第二條：很顯然，這一條主旨是說計算機化系統可以代替人工操作，提高工作效率，但是需考慮這種替代或變革隨之帶來的風險，這種風險可能是來自產品質量的、過程控制的，也可能是整個質量保證體系的，需慎重、全面考慮這種變革帶來的諸多影響，原則上同過去手工操作相比，不增加總體風險即可。這一條其實給整個附錄定了一個基調，就是凡是大到變革、小到變更，只要有變化都要做好風險識別和風險評估工作，這是一切“變”的前提和剛性要求。

原文內容：

第三條：風險管理應當貫穿計算機化系統的生命週期全過程，應當考慮患者安全、資料完整性和產品質量。作為質量風險管理的一部分，應當根據書面的風險評估結果確定驗證和資料完整性控制的程度。

原文解讀：

第三條：這一條承接上一條，對風險管理從二個維度提出了具體要求。一個是時間維度，風險管理要求貫穿整個計算機化系統全生命週期，包括概念提出、專案實施、系統執行直到系統引退。這種風險意識其實也正好契合了企業家們的危機意識，當今以任正非為代表的中國企業家們，每天思考的其實不是如何成功，而是怎麼避免失敗，企業能活下去其實就是成功；另一個維度是潛在後果，即風險如果發生，可能會導致的後果會是什麼，人員傷亡、質量投訴、資料丟失等，正是基於對這些後果的考慮，才有了風險管理的現實出發點，即所有的系統設計、安裝、使用以及變更，都需要充分考慮患者安全、產品質量、資料完整性的影響。且根據風險評估做出的影響分析，用來作為確定系統驗證方案和系統資料完整性控制的依據。

原文內容：

第四條：企業應當針對計算機化系統供應商的管理制定操作規程，供應商提供產品或服務時（如安裝、配置、整合、驗證、維護、資料處理等），企業應當與供應商簽訂正式協議，明確雙方責任。企業應當基於風險評估的結果，提供與供應商質量體系和審計資訊相關的檔案。

原文解讀：

第四條：這一條其實是明確了對IT產品或服務供應商的具體管理要求，包括供應商管理SOP,正式的協議或合同。同時，企業應當基於對風險評估的結果，對供應商進行相應的調查、評估，並有實施審計形成檔案化的記錄，這一條其實還是在強調對供應商的風險管控，風險管理也從內部延伸到了外部。風險管理的影子無處不在，真的是深入到IT合規管理的骨髓了。

原文內容：

第五條：計算機化系統生命週期中所涉及的各種活動，如驗證、使用、維護、管理等，需要各相關的職能部門人員之間的緊密合作。應當明確所有使用和管理計算機化系統人員的職責和許可權，並接受相應的使用和培訓管理。

應當確保有適當的專業人員，對計算機化系統的設計、驗證、安裝和執行等方面進行培訓和指導。

原文解讀：

第五條：該條款特別強調在進行計算機化系統驗證整個生命週期當中，一定要事先明確所有使用和管理這些系統人員的職責和許可權，這一點很重要，如果事先不能很清晰地界定清楚大家的分工和職責，將會造成驗證工作的混亂，相互扯皮、甚至會造成某些環節在管理上的真空。關於這一點，通常要在驗證主計劃中寫明白、寫清楚。

大夥除了清楚各自幹什麼還不夠，你有沒有能力把很專業的工作幹好、做到位，這一點很關鍵，對於能力達不到的人員，培訓就顯得尤為重要。培訓涉及到接受培訓的人員和執行培訓的老師二個角色，條款中用了一個詞，叫“適當”，其實就是告訴我們對培訓人員和培訓老師要有適當的要求，包括課程設計、現場指導等。

說完對人員的要求，接下來再和大家說一說驗證的整體框架性要求。

原文內容：

第六條：計算機化系統驗證包括應用程式的驗證和基礎架構的確認，其範圍與程度應當基於科學的風險評估。風險評估應當充分考慮計算機化系統的使用範圍和用途。

應當在計算機化系統生命週期中保持其驗證狀態。

原文解讀：

第六條：這裡對計算機化系統的驗證範圍或物件再次進行了明確，同附錄第一條是相呼應的。驗證物件包括應用程式（就是軟體）和基礎架構（包括硬體和網路）。驗證的具體範圍和程度如何確定呢？答案是基於科學的風險評估，那麼風險評估又如何進行呢？答案是要充分考慮該系統的使用範圍和用途。這麼說有點抽象哈，舉例來說，某個系統的使用是否同GxP有關或對產品質量有影響，如果有，就需要進行風險評估，同時還要考慮該系統使用範圍大小，範圍越大，影響越大，風險越高。

此外，該條款特別強調了系統在整個生命週期中驗證狀態的保持，這一點告訴我們驗證工作其實是個常態的工作，而不是一項運動，更不是一項階段性的工作，需要我們終身堅持不懈地做下去，“不忘初心，方得始終”！

原文內容：

第七條：企業應當建立包含藥品生產質量管理過程中涉及的所有計算機化系統清單，標明與藥品生產質量管理相關的功能。清單應當及時更新。

原文解讀：

第七條：這裡提到了建立“計算機化系統清單”，這一點很重要，但往往容易被企業所忽視，這也是很多藥企在GMP現場稽核時，檢查官開得最常見的一項主要缺陷項。為什麼這一條在檢查官看來很重要呢？原因就在於，作為CIO或IT部門負責人，你對你所管理的整個IT各個系統要有很清晰的一張管理地圖，哪些系統需做驗證，哪些系統不需做驗證；需要做驗證的系統，他們的硬體、網路和軟體配置如何，能否滿足驗證和使用的要求，這些配置元件的更改有沒有及時更新到清單上來，如果連這一點都做不到，我是檢查官的話，我也會判缺陷項的，甚至是嚴重缺陷項！這一點，請CIO們務必重視起來。

原文內容：

第八條：企業應當指定專人對通用的商業化計算機軟體進行稽核，確認其滿足使用者需求。在對定製的計算機化系統進行驗證時，企業應當建立相應的操作規程，確保在生命週期內評估系統的質量和效能。

原文解讀：

第八條：這一條說的其實是對需要做驗證的系統或軟體進行一個分類，即商業化軟體（無需定製開發）和定製開發軟體這二大類。顯然，這二大類的軟體本身的技術複雜程度，我們無法評估，我們要考慮的其實是使用這些系統所帶來的風險，前者成熟穩定，經過了長時間市場和時間的檢驗；後者新穎獨創，很多潛在的Bug尚未被發現，需要經過實際的使用和時間的檢驗才能被證明是否穩定、可靠。所以，前者僅需做稽核、確認就夠了，而後者則需建立嚴格的操作規程，嚴格的測試，驗證其系統的穩定性和產品的健壯性，二者驗證的所要求的程度是不一樣。

原文內容：

第九條：資料轉換格式或遷移時，應當確認資料的數值及含義沒有改變。

原文解讀：

第九條：這一條很好理解，舉例來說在做系統升級時，升級後的系統遷移過來的資料的數值和含義必須是同升級前系統的資料保持一致。這是最基本的要求，否則系統升級就是不成功的。

原文內容：

第十條：系統應當安裝在適當的位置，以防止外來因素干擾。

原文解讀：

第十條：該條款首先從環境和安全的角度，提出了系統安裝的位置，以防止外來因素的干擾。這其實是說系統對機房或其他辦公環境的要求，包括室內的溫度、溼度、防塵、防潮、防盜等要求，所以，企業應首先建立《機房管理規程》，保障機房、機房內軟硬體及相關附屬裝置安全、穩定執行。

原文內容：

第十一條：關鍵系統應當有詳細闡述的檔案（必要時，要有圖紙），並需及時更新。此檔案應當詳細描述系統的工作原理、目的、安全措施和適用範圍、計算機執行方式的主要特徵，以及如何與其他系統和程式對接。

原文解讀：

第十一條：該條款對關鍵系統的技術資料提出了具體要求，比如功能說明書、硬體設計說明、系統概要設計和詳細設計，目的是要表述清楚整個系統的工作原理、安全措施、執行方式以及與外部系統的介面等，為後續系統的升級、維護提供技術交底材料。

原文內容：

第十二條：軟體是計算機化系統的重要組成部分。企業應當根據風險評估的結果，對所採用軟體進行分級管理（如針對軟體供應商的審計），評估供應商質量保證系統，保證軟體符合企業需求。

原文解讀：

第十二條：該條款是在強調對軟體的分級管理，為何要做分級管理呢？根本原因還是要做軟體的風險管控。如果軟體是向供應商購買的或委託供應商定製開發的，基於風險評估結果，必要時企業需對該軟體供應商進行審計，評估供應商的質量保證體系，確保軟體功能可靠、效能穩定、資料完整，滿足企業使用需求。

原文內容：

第十三條：在計算機化系統使用之前，應當對系統進行全面測試，並確認系統可以獲得預期的結果。當計算機化系統替代某一人工系統時，可採用兩個系統（人工和計算機化）平行執行的方式作為測試和驗證內容的一部分。

原文解讀：

第十三條：這裡強調了系統正式使用前，應該經過充分而全面的測試，並最終測試合格，通過驗收。至於需要做哪些型別的測試以及測試做到什麼程度，取決於上一條款提到的風險評估結果和軟體分級管理。最常見的測試型別，包括模組單元測試、系統整合測試以及使用者接受測試等。條款提到的人工和計算機化系統平行執行的方式，其實是系統切換上線後，有一個試執行階段，該階段結束後，將試執行期間人工記錄資料和系統執行資料進行比對，根據比對後的結果，做最終的驗證結論，本質上也是驗證系統是否可靠的一種手段。

原文內容：

第十四條：只有經許可的人員才能進入和使用系統。企業應當採取適當的方式杜絕未經許可的人員進入和使用系統。

應當就進入和使用系統制訂授權，取消以及授權變更的操作規程。必要時，應當考慮系統能記錄未經許可的人員試圖訪問系統的行為。對於系統自身缺陷，無法實現人員控制的，必須具有書面程式、相關記錄以及相關物理隔離手段，保證只有經許可的人員方能進行操作。

原文解讀：

第十四條：該條款對系統的許可權管理，提出了二個方面的管控：一個是進入系統，另一個是使用系統。前者只是瀏覽系統，獲取資訊，比如相關人員和領導；後者則要實實在在要在系統中進行業務操作。這是需要考慮的許可權控制範圍，具體該如何進行許可權控制的操作呢？

條款明確指出要制定系統許可權管理SOP,內容包括授權、取消授權以及許可權變更流程。同時，在系統設計時，需具備記錄未經許可的人員試圖訪問系統行為的功能。但如果系統之前的設計和功能存在缺陷，不能對人員的許可權進行控制的話，則必須制定書面程式，線下做好相關的記錄和手續，做到人員在物理上進入和使用系統的控制。

原文內容：

第十五條：當人工輸入關鍵資料時，應當複核輸入記錄以確保其準確性。這個複核可以由另外的操作人員完成，或採用經驗證的電子方式。必要時，系統應當設定複核功能，確保資料輸入的準確性和資料處理過程的正確性。

原文解讀：

第十五條：該條款強調關鍵資料的輸入，需要有人複核，本質上還是防止差錯。具體的做法有二種：一種方式是讓另外的操作的人員完成複核，這種方式絕大多數藥企都是這樣做的；另一種方式，就是採用經驗證的電子方式（即系統自帶的功能），比如經過驗證的稱重配料系統，通過系統報警提示“超重”或“欠重”，又比如SAP系統中錄入檢驗資料時，系統會自動校驗長度和小數位數，以保證資料輸入的準確性和處理的正確性。個人認為，保險的做法是將人工複核和系統校驗二者結合起來，寧可在資料入口多做檢查，也比後面發現錯誤去處理，無論從時間上還是成本上來說，都更為划算。

原文內容：

第十六條：計算機化系統應當記錄輸入或確認關鍵資料人員的身份。只有經授權人員，方可修改已輸入的資料。每次修改已輸入的關鍵資料均應當經過批准，並應當記錄更改資料的理由。應當根據風險評估的結果，考慮在計算機化系統中建立資料審計跟蹤系統，用於記錄資料的輸入和修改以及系統的使用和變更。一句話總結“系統許可權的合規管理需從使用者進入系統-》錄入資料-》更改資料-》審計追蹤進行完整管控才行，任何環節的管理缺失，都將帶來質量風險。

原文解讀：

第十六條：上一條說到資料的輸入，這裡提到了資料的更改，其實都是在強調對人員許可權的控制，而修改則更為嚴格，特別是關鍵資料的修改需經過批准，並記錄更改資料的理由（這一點，很多企業在操作過程中執行得不是很好，甚至無緣無故就把資料給改了，這樣做既不合規，又埋下了風險隱患）。此外，應當根據風險評估結果，建立系統資料審計跟蹤系統，對原始資料的輸入和修改能夠通過系統日誌進行查詢，這一點很重要，事實上很多的業務系統設計不是很完善，修改後的資料直接覆蓋了原始錄入的資料，這其實是違規的！

原文內容：

第十七條：計算機化系統的變更應當根據預定的操作規程進行，操作規程應當包括評估、驗證、稽核、批准和實施變更等規定。計算機化系統的變更，應經過該部分計算機化系統相關責任人員的同意，變更情況應有記錄。

原文解讀：

第十七條：該條款對系統變更作出了明確要求，需建立變更操作規程。並依據該操作規程進行變更評估、驗證、稽核、批准和實施，並最終形成變更記錄。

原文內容：

第十八條：對於電子資料和紙質列印文稿同時存在的情況，應當有檔案明確規定以電子資料為主資料還是以紙質列印文稿為主資料。

原文解讀：

第十八條：對於此條款，在我看來紙質記錄和電子資料其實沒有主次之分，只有先後之分。原因在於如果電子資料（比如圖譜）直接由系統生成，那麼可以在提供電子資料的同時，將該電子資料列印出來進行存檔、備查。而如果之前是現場的紙質記錄的話，那麼也可以將該紙質記錄資料掃描後，上傳到文件伺服器進行集中儲存。這裡需要強調的就一點，不管先有電子資料還是先有紙質記錄，二者的版本號和資料必須保持一致，這也是資料完整性的要求。

原文內容：

第十九條：以電子資料為主資料時，應當滿足以下要求：

（一）為滿足質量審計的目的，儲存的電子資料應當能夠列印成清晰易懂的檔案。（二）必須採用物理或電子方法保證資料的安全，以防止故意或意外的損害。日常執行維護和系統發生變更（如計算機裝置或其程式）時，應當檢查所儲存資料的可訪問性及資料完整性。（三）應當建立資料備份與恢復的操作規程，定期對資料備份，以儲存儲存的資料供將來呼叫。備份資料應當儲存在另一個單獨的、安全的地點，儲存時間應當至少滿足本規範中關於檔案、記錄儲存時限的要求。

原文解讀：

第十九條：這裡對電子資料提出三個方面的合規要求，一是能夠將電子資料列印出清晰易懂的紙質文件；二是需採取物理或者電子的方式，保證其資料的安全；同時，還應在日常運維和系統變更時，檢查儲存資料的可訪問性和資料完整性；三是需建立資料備份和恢復SOP，包括本地備份和遠端備份，以確保資料安全和呼叫。

原文內容：

第二十條：企業應當建立應急方案，以便系統出現損壞時啟用。應急方案啟用的及時性應當與需要使用該方案的緊急程度相關。例如，影響召回產品的相關資訊應當能夠及時獲得。

原文解讀：

第二十條：“凡事預則立，不預則廢”，該條款明確提出對系統可能出現各種的損壞提前考慮，包括當遇到自然災害、意外事故、作業系統崩潰、資料庫錯誤等原因造成SAP系統無法正常執行，導致公司業務無法正常運轉且用常規修復方法無法修復時，將啟用災難應急預案。應急方案啟用的及時性應當與需要使用該方案的緊急程度相關，包括立即啟用、24小時啟用等。

原文內容：

第二十一條：應當建立系統出現故障或損壞時進行處理的操作規程，必要時對該操作規程的相關內容進行驗證。

包括系統故障和資料錯誤在內的所有事故都應當被記錄和評估。重大的事故應當進行徹底調查，識別其根本原因，並採取相應的糾正措施和預防措施。

原文解讀：

第二十一條：企業除了需建立突發情況下的系統應急方案外，條款還提出要建立日常情況下的故障或損壞處理的操作規程，以保證業務的連續性。系統故障和資料錯誤應當作為事件被記錄和評估，根據需要完成相應的CAPA流程，直至問題處理閉環。

原文內容：

第二十二條：當採用計算機化系統放行產品時，計算機化系統應當能明示和記錄放行產品人員的身份。

原文解讀：

第二十二條：在系統中做放行產品時，系統應當能明示和記錄放行產品人員的身份，比如質量受權人，此過程可以通過電子簽名來實現。

原文內容：

第二十三條：電子資料可以採用電子簽名的方式，電子簽名應當遵循相應法律法規要求。

原文解讀：

第二十三條：電子資料即系統生成的所有電子文件，可以採用電子簽名的方式，包括使用者系統二次密碼驗證、第三方媒介如U盾簽名或確認等。不管哪種方式都必須遵循《中華人民共和國電子簽名法》的規定要求。

本文出處：暢享網
本文來自雲棲社群合作伙伴暢享網，瞭解相關資訊可以關注vsharing.com網站。