検証とトレーサビリティの目的
検証の目的は、プロセスやシステムの一貫性を確保し、文書化することです。 システムの検証は規制機関の要件です。 たとえば、ライフ サイエンス組織の場合、規制機関に米国食品医薬品局 (FDA) が含まれます。
FDA は、検証を次のように定義しています。
特定の使用目的に対する特定の要求事項を一貫して満たすことを、審査および客観的証拠の提供によって確認する。
世界保健機関 (WHO) は、適正製造基準 (GMP) の要件に関するガイダンスにおいて検証を次のように定義しています。
計画されたプロセスが、期待される所定の結果に従って一様に行われることを高度に保証する文書での証拠を確立する。
これらの定義には、期待される結果に応じて、以下の要素が共通しています。
- 証拠の生成
- 規制へのコンプライアンス
- 要件の対応
コンピュータ化されたシステムの検証は、システムが一貫した再現性のある方法で設計通りに動作することを保証するための文書化されたプロセスです。 検証は、データ処理の完全性とセキュリティ、製品品質、および GxP（グッド {industry} プラクティス）に適用される規制への準拠を保証します。
コンピュータ化されたシステムを検証するプロセスは、ライフ サイエンス企業などの規制産業によって作成および定義された標準作業手順書 (SOP) やガイドラインに記載されています。 コンピュータ化されたシステムの検証については、国際製薬技術協会 (ISPE) の適正製造基準 (GAMP) 5: 準拠した GxP コンピューター システムへのリスクベースのアプローチに記載さるように、プロセスの実装をプロジェクトとして見ると便利です。
実装プロジェクトの開始前に、新しいソリューションの高度な計画を準備する必要があります。 次に、次の段階を経てプロジェクトを開始します。
- 計画: このフェーズでは、最初のリスク評価と、最終的には検証テスト (プロトコル) を正しく定義するために、要件と仕様が十分に明確な必要があります。 このフェーズでは、検証戦略全体とすべての成果物を定義した検証計画書を完成します。 戦略は、品質管理システム (QMS) およびポリシーと一致している必要があります。
- 仕様、構成、およびコーディング: このフェーズでは、システムの種類とその用途に必要な詳細レベルで、すべての設計仕様を作成します。 開発者は、承認された仕様に基づいて、コーディングや構成の要件に最も適した開発手法やオブジェクトを選択および使用します。 これらの活動はすべて開発環境で行われます。 このフェーズでは、開発者の視点から、ユニットや機能の検証を行うことに重点を置いてテストが行われます。 テスト活動の例には、ユニット テスト、コードの統計的テスト、統合テストがあります。 ツールによりこれらのテスト活動を自動化できます。
- テスト: このフェーズでは、システムの検査やテストを通じて、仕様が満たされていることを確認します。 テスト活動は、準備された適切なテスト環境の中で行われます。 テスト環境は、条件が同じで、運用環境でテストを繰り返す必要がないように、運用環境に似ている必要があります。 リスクは、テスト作業のスコープを決定する要因となるべきです。 リスク分析は、製品品質、患者さんの安全、またはデータの完全性に影響を与える可能性のある潜在的な危険を理解するのに役立ちます。 それらの潜在的な危険性は、コントロールの整備とテストによる証明によって緩和される必要があります。 どこかに高いリスクがある場合は、適切なテスト シナリオを用意し、ソリューションの設計に潜在的な不具合がないことを証明します。
- 報告とリリース: このフェーズでは、システムは、文書化および管理されたプロセスに従って、生産環境での使用が認められる必要があります。 プロジェクトの終了時には、実施した活動や検証計画からの逸脱を要約するために、システム検証完了書を準備する必要があります。 システムの使用を公開する前にシステムの検証を完了する必要があります。
次の図は、GAMP 5 第 2 版でサポートされる V モデルを示しています。 プロジェクト フェーズを全体的に見ることができます。
V モデルは、システムの開発活動やテストだけでなく、それらの順序や相互関係、検証されたコンピュータ化システムに適用される成果物の検証プロセスとして見ることができます。 要件、使用、およびテスト間の相互関係を保持および維持する必要があります。 この相互関係は、規制領域内のトレーサビリティ マトリックスに文書化されています。
トレーサビリティ マトリックスは以下を確保します。
- ソリューション設計で要件が満たされています。 つまり、各要求は関数、コントロール、構成、またはデザイン要素まで追跡されます。
- ソリューション設計が要件を満たしていること実証するために、必要に応じて要件はテストまたは検証されます。
トレーサビリティ マトリックスには次の利点があります。
- デザイン レビューをサポートします。
- 回帰テストのスコープの定義を支援します。
- 検査または監査活動中のサポートを提供します。
- 潜在的な変更に対するサポートを提供します。
プラットフォームの評価
規制産業では、Guides を実装する前にインフラストラクチャとしての Microsoft Power Platform を評価する必要があります。 プラットフォームの評価には、少なくとも以下のタスクが必要になります。
最初のリスク評価 (GxP の適用可能性の評価)
仕入先の評価 (仮想的、物理的、または郵便による仕入先の監査)
評価計画
プラットフォーム設計の技術仕様
リスク評価 (間違ったバージョンのガイドをオペレーターに使用可能にするリスクの評価など)
テスト:
- インストール テスト (環境が正しくインストールされているかのテストなど)
- 操作テスト (適切なユーザーが適切なアクセス権を持っているかのテストなど)
評価報告書の要約
プラットフォーム マニュアルまたは操作マニュアル、トレーニング資料
アプリケーションの検証
規制産業のビジネス プロセスをサポートするアプリケーション (Guides や Power Apps など) を検証する必要があります。 そのため、組織は次のタスクを行う必要があります。
最初のリスク評価
検証計画
ユーザーの要件
リスク評価
アプリケーション機能仕様または構成技術仕様
テスト (インストール評価 (IQ)、操作評価 (OQ)、およびユーザー受け入れテスト (UAT))。
- 操作テスト (機能の検証など)
- UAT
トレーサビリティ マトリックス
検証報告書の要約
アプリケーション マニュアルまたは操作マニュアル、トレーニング資料