製薬業界は、患者の安全を確保するために、さまざまな国際機関によって厳しく規制されています。 実装されたすべてのプロセスと製造された医薬品は、市場で使用または発売される前に徹底的に検証および検証されます。 これは、一貫した製品品質と患者の安全を確保するために特に行われます。 製薬プロセスを自動化する一方で、企業は購入を予定しているコンピューター システムを検証する必要もあります。 コンピュータ システムを検証する目的は、アプリケーション / システム / 機器 / マシンが指定された設計または要件どおりに動作するように、アプリケーション / システム / 機器 / マシンが適切に機能していることを確認することです。
コンピュータ システム検証の定義
コンピュータ システム検証は、コンピュータ システムが製薬などの規制部門で使用され、指定されたタスクを一貫した方法で達成できることを保証するための文書化されたプロセスです。 これらのシステムは、データの整合性、優れた製品品質、GxP 規制への準拠を保証する必要があります。 FDA は、21 CFR Part 11 に加えて 2003 年の CSV ガイドラインの発行以来、このアプローチを使用しています。
コンピュータ システム検証は、次のようなコンピュータ システムに適用されます。
プロセス制御ソフトウェア
コントローラ ベースのシステム (MP/MC)
管理された包装用の PLC 機器
監視制御およびデータ収集(SCADA)
分散制御システム(DCS)
商用オフザシェルフ (COTS) / Software as a Service (SaaS)
研究室情報管理 システム (LIMS)
臨床試験モニタリング システム
クロマトグラフィー データ システム (CDS)
エンタープライズ リソース プランニング (ERP) システム
製造実行 システム(MES)
バッチ レコード システム
ビル管理システム(BMS)
クラウド ベース ソフトウェア サービス
スプレッドシート
GAMP によるコンピュータ システムの分類 5
カテゴリ 1: インフラストラクチャ ソフトウェア、ツール、および IT サービス
カテゴリ 3: 標準システム コンポーネント / 未構成の機能
カテゴリ 4: 構成済みコンポーネント
カテゴリ 5: カスタム アプリケーションおよびコンポーネント
カテゴリ 2 存在
規制上の義務
各国には、コンピュータ システムを検証するために異なる一連の規制が設けられています。 これらには、米国 FDA、EU GMP、WHO、MHRA、MOW などが含まれます。米国 FDA は、検証が必要な 21 CFR 211.68 に従ってコンピュータ システムを機器として認識しています。 この規制は、21 CFR パート 11 で電子記録と電子署名の詳細な管理を規定しています。パート 11 では、電子記録と署名が正確で、信頼性があり、取得可能で安全であることを義務付けており、紙の記録と手書きの署名を法的に 100% 置き換えることができます。 FDA は、医療機器業界に対し、21 CFR 820 ガイドラインを使用してソフトウェアを検証することを義務付けています。 EU 附属書 11 には、コンピュータ化されたシステムの検証に関するガイダンスも記載されています。 ISO 13485 標準 16 は、医療機器業界に CSV を義務付けています。
適正自動製造基準 (GAMP) は、コンピューター システムが FDA 21 CFR 11 に準拠していることを検証するために製薬会社が使用する一連のガイドラインと手順です。GAMP は特に規制ではなく、一連の規制です。 これは、企業がガイドラインに準拠する法的義務がないことを意味します。 ただし、GAMP は企業が間接的に世界的な規制に準拠するのに役立ちます。
GxP とは何ですか?
G = Good | x = 変数| P = 実践
x は変数であるため、
GMP – 適正製造基準
GCP – 適正なクリニックの実践
GLP – 適正な検査室の実践
GDP – 適正な文書化の実践
GWP – 適正なストレージなど、製薬業界のさまざまな概念に対応できます。 実践
GEP – グッド エンジニアリング プラクティス
CSV の重要な手順
線形アプローチ (V モデル)
製薬業界のほとんどの組織は、GAMP 5 の V モデルに従って、ISPE の定義に従ってコンピューター システムを検証しています。 このモデルは、主要なユーザー要件とユーザー要件の間の関係を視覚化するために実装されています。 システムの仕様と、それに対して実行される検証またはテスト。 V字をイメージしてみましょう。 モデルの左側は要件または仕様 (URS、FS、DS) に対応していますが、 右側は、これらの要件を検証するための関連テストに対応します。
GxP 準拠: まず、コンピュータ システムが GxP 規制 (GMP、GCP、GLP、GDP、GWP) に準拠しているかどうかが検証されます。 これは、コンピュータ システム プロバイダーと将来のユーザーの両方によって保証されます。
必要な基準の定義: ユーザー要件仕様 (URS)、機能仕様 (FS)、設計仕様 (DS) などの必須基準を最初に定義する必要があります。 これらの基準を定義した後、コンピュータ システムはこれらの特定の基準に従ってテストされます。
ユーザー要件仕様 (URS): URS は、ユーザーのニーズを満たすためのシステム要件の概要を説明する正式な文書です。 URS は、ベンダーのソリューションの影響を受けないようソリューションを選択する前に定義されます。URS は、潜在的なベンダーとそのソリューションを評価し、ニーズに優先順位を付け、実装コストを削減するのに役立ちます。 URS は、法規制への準拠、安全要件、運用上の制約、その他の重要な要素も考慮します。
機能仕様 (FS): FS 文書は、ユーザーのニーズを満たすためにソフトウェアがどのように動作するかを指定します。 これは基本的に、ユーザー インターフェイス画面の説明、レポートの外観、およびキャプチャされるデータを文書化できます。 これには、ロジック、計算、規制要件も含まれる場合があります。
設計仕様 (DS): DS ドキュメントには、ソフトウェアのすべての技術要素が含まれており、システムがその機能仕様を満たす方法を指定します。 設計仕様の一部の要素は次のとおりです。
データベース設計
ロジック / プロセス設計
セキュリティ設計
インターフェイス設計
アーキテクチャ設計
ネットワーク要件
周辺機器 デバイス (スキャナ、プリンタなど)
構成/コーディング: ベンダーはソフトウェアを構築および開発し、ユーザーが設定した基準 (URS、FS、DS) を満たすように構成します。
CSV テストと検証: 受け入れ基準を設定した後、ユーザーは、GxP 準拠のシステムを提供し、必要な機能をすべて備えている一連のベンダーからソフトウェアを選択する必要があります。 製品を選択した後、URS、FS、DS 文書がベンダーに提示されます。 したがって、ベンダーはユーザーのニーズを満たすためにソフトウェアに必要な追加を加えます。 ソフトウェアがユーザーの要件に合わせてカスタマイズされた後、ユーザーによってテストされます。
このプロセスはユーザー受け入れテスト (UAT) として知られています。 テスト リンクを使用して製品を厳密にテストした後、検証リンクに渡されます。 ユーザーがシステムを完全にテストして検証した後、実際の運用リンクにさらに渡されます。つまり、ソフトウェアはユーザーの運用環境でテストされます。 この段階では、ソフトウェアが一貫した結果を提供できる場合、製品はクライアントに引き渡されます。
インストール適格性評価 (IQ): 「構成テストまたは統合テスト」とも呼ばれ、インストール適格性評価では、ソフトウェアが設計仕様に従ってインストールまたはセットアップされているかどうかを確認します。
動作適格性確認 (OQ): 動作テストまたは機能テストでは、仕様で定義されているすべての機能がコンピュータに存在し、正しく動作していることを確認します。
パフォーマンス適格性評価 (PQ): 「ユーザー要件テスト」とも呼ばれるパフォーマンス適格性評価は、ソフトウェアが意図された用途に適しており、すべてのユーザー要件仕様を満たしていることを確認します。
最終レポート: これは検証プロセスの最後のステップであり、システムがその意図された用途に適合しており、すべての成果物が計画どおりに提供されていることを宣言する概要レポートが作成されます。
反復的かつ段階的なアプローチ (アジャイル)
V モデルとは異なり、アジャイル アプローチでは、アジャイル開発実践と構造化された検証アクティビティを統合する柔軟な反復手法が採用されています。 反復的な製品開発、継続的なテスト、継続的な文書化に重点を置いています。 これには、ユーザーとベンダー間の継続的な交換が必要です。 プロセス全体には、要件の計画と指定、構成/コーディング、スプリント レビューによる検証とレビュー、振り返り、継続的なフィードバックと改善が含まれます。 段階的な製品構成により、開発者はより少ない負担でコンプライアンスとユーザーの要件を満たすことができます。
効果的なコンピュータ システム検証により、 さらに、製薬業界は、生産性、品質、コンプライアンスを確保できる優れたコンピュータ システムを評価し、投資することができます。 コンピュータ システムは、製造環境やリアルタイム環境で使用する前に適切な検証が必要です。 リニアかつアジャイルなアプローチを使用することで、ユーザーはソフトウェアを適切に選択でき、ベンダーはユーザーが指定した要件を満たす製品を効果的に提供できます。