驗證與可追溯性的目的
驗證的目的是確保流程或系統的一致性和記錄性。 系統驗證是規範機構的要求。 例如，對於生命科學組織，規範機構包括美國食品藥品監督管理局 (FDA)。
FDA 對驗證的定義如下：
通過檢查並提供客觀證據，確認特定預期用途的特定要求可以持續得到滿足。
世界衛生組織 (WHO) defines validation在其有關良好製造規範 (GMP) 要求的指南中對驗證的定義如下：
建立文件證據，以提供高度保證，確保計畫中的程序將一致地符合預期的指定結果。
這些定義共有以下相同元素，符合預期結果：
- 證據世代
- 法規合規性
- 需求履行
電腦化系統的驗證是一個文件化的程序，確保系統按照一致可重複的方式確切執行其設計目的。 驗證確保資料處理的完整性和安全性、產品品質以及適用於良好的{industry}做法 (GxP) 的法規遵從性。
驗證電腦化系統的程序在標準作業程序 (SOP) 和指南中有所描述，這些文件由受規範的產業 (如生命科學組織) 制定和定義。 對於電腦化系統的驗證，將實施程序視為一個專案，這是根據國際藥品工程學會 (ISPE) 的良好自動化製造做法 (GAMP) 5：符合 GxP 電腦化系統的風險型方法所描述的。
在開始實施專案之前，應該制定新解決方案的高層計畫。 然後透過完成以下階段來啟動專案：
- 規劃：在此階段，需求和規範應該足夠清晰，以進行初始風險評估，最終為驗證測試 (協議) 的正確定義做好準備。 在此階段，您提供了定義整個驗證策略和所有交貨成果的驗證計畫文件。 該策略應與品質管理系統 (QMS) 和政策一致。
- 規格、配置和編碼：在此階段，根據系統的類型和用途，制定所有詳細設計規範。 開發人員選擇並使用最適合編碼和設定要求的開發方法和物件，並基於已核准的規範。 所有這些活動都在開發環境中進行。 在此階段，測試更加聚焦於開發人員角度的單元或功能驗證。 測試活動的例子包括單元測試、代碼的統計測試和整合測試。 工具可以使這些測試活動自動化。
- 測試：此階段通過檢查和系統測試確認規範的滿足程度。 測試活動在預備且適當的測試環境中進行。 測試環境必須與生產環境相似，以確保條件相同，並避免在生產環境中重複測試。 該風險應該推動測試工作的範圍。 風險分析可以幫助您了解可能對產品品質、病患安全或數據完整性產生影響的潛在危害。 這些潛在危害必須透過已有控制措施和測試證明來緩解。 如果某個地方存在高風險，應該有適當的測試方案來證明解決方案設計不存在潛在故障。
- 報告和發布：在此階段，系統必須按照一個文件化和受控的流程，符合在生產環境中使用的條件。 在專案結束時，必須準備系統驗證完成報告，總結所進行的活動以及與驗證計畫的任何偏差。 系統的驗證應該在釋放供使用之前完成。
以下插圖展示了由 GAMP 5 (第二版) 支援的 V 模型。 該插圖提供了一種良好的整體專案階段檢視表。
V 模型不僅可以看作系統的開發活動和測試，還可以看作它們的順序、相互關係以及適用於驗證電腦化系統的交貨成果的驗證程序。 您必須保持並維護需求、規範和測試之間的相互關係。 這種相互關係在受規範的領域中以可追溯性矩陣的形式記錄。
可追溯性矩陣可確保：
- 需求由解決方案設計滿足。 換句話說，每個需求都與功能、控制、設定或設計元素相關。
- 必要時，需求經過測試或驗證以證明解決方案設計是否符合需求。
可追溯性矩陣有下列好處：
- 可支援設計回顧。
- 有助於定義回歸測試的範圍。
- 可在檢測或稽核活動期間提供支援。
- 可對潛在變更提供支援。
平台授與資格
在實施 Guides 之前，受規範的產業必須對 Microsoft Power Platform 進行基礎結構資格審查。 平台資格審查至少需要完成以下任務：
初始風險評估 (評估 GxP 適用性)
廠商評估 (稽核廠商，無論是虛擬的、實體的還是郵寄的方式)
授與資格方案
平台設計技術規格
風險評估 (例如，評估將錯誤版本的指南提供給操作員的風險)
正在測試：
- 安裝測試 (例如，測試環境是否正確安裝)
- 操作測試 (例如，測試正確的使用者是否具有正確的存取權限)
摘要資格報表
平台或操作手冊，以及訓練素材
應用程式驗證
在受規範產業中支援商務程序的應用程式 (如 Guides 和 Power Apps) 必須進行驗證。 因此，您的組織必須完成以下任務：
初始風險評估
驗證方案
使用者需求
風險評估
應用程式功能規格或設定技術規格
測試 (安裝資格驗證 [IQ]、操作資格 [OQ] 和使用者接受度測試 [UAT])：
- 操作測試 (例如驗證功能)
- UAT
可追溯性矩陣
摘要驗證報表
應用程式或操作手冊，以及訓練素材