コンピュータ・システム・バリデーションのあり方について、製薬メーカーやコンサルタントと数年間話し合った後、FDAは2022年9月にコンピュータ・ソフトウェア保証ガイダンスの草案を発表した。それ以来、私はこのガイダンスを利用して、2つの大規模なコンピュータシステムバリデーションプロジェクトを完了するのに必要な労力とコストを削減した。このブログでは、これらのバリデーション作業から得られた知見を紹介し、GMP機能の実行に使用されるコンピュータ化されたシステムを検証するこの「新しい方法」を実施する際に遭遇した問題のいくつかを回避するのに役立つであろう。プロジェクト実行中に学んだ教訓を列挙した後、それを3つの分野、すなわち計画、実行、要約に分けるのが論理的であると思われた。その結果、3つの記事が生まれ、最初の記事は計画に焦点を当てたものである。この記事では、ほとんどの企業が慣れ親しんでいる、試行錯誤のバリデーション・プロセスへの変更に伴う成長痛を軽減するのに役立つ、プロジェクトの計画段階で学んだ教訓について述べている。
レッスン1：FDAガイダンスを十分に理解する。
- 私たちの検証作業を複雑にした問題の一つは、ベンダー、開発者、プロトコル作成者の何人かが、FDAのCSAガイダンスと、それがソフトウェア検証にどのように適用されるかについて、異なる理解を持っていたことです。このガイダンスは、規制の状況を、すべてのテストが正式な検証バリデーションプロセスで使用できるような「荒野の西側」に変えるものではありませんでした。ガイダンスでは、ソフトウェアのインストールと動作を検証するために、ベンダーテスト、その他のアドホックテスト、電子データ収集などをメーカーが使用することについてのFDAの考えについて、具体的な情報を提供している。プロジェクトをCSAの道に進める前に、チームの全員が、異なる要求事項のカテゴリーと、FDAがソフトウェア検証のために推進しているテストのタイプを理解していることを確認してください。新しいアプローチとガイダンスの検証成果物に対する要求事項に対するチームの理解を深めるために時間を費やすことは、許容できない文書化された成果物の大幅な手戻りをなくし、CSAに基づくソフトウェア検証作業の効率化を実現するために不可欠である。
教訓2：強固なリスク評価と軽減プロセスを構築する。
- 様々な要件を検証するために必要な厳密さを、プロジェクトの極めて早い段階で特定することが不可欠である。詳細なリスクアセスメントを実施して、ソフトウェアの検証に関連する潜在的なリスクを特定し、その結果に基づいて緩和戦略を策定して、特定されたすべてのリスクに可能な限り効率的な方法で対処する。これにより、CSA ベースの検証戦略でどのような要件やシステムをより効率的に検証できるか、また、どのようなリスクの高い要件を検証ライフサイクル成果物一式で検証しなければならないかについてのロードマップが得られる。QA とバリデーションをこのプロセスに参加させ、検証の決定について彼らの意見を得ることで、プロ ジェクトの後半におけるこれらのグループとの問題を防止する。プロジェクトの初期段階でのコミュニケーションは、問題を未然に防ぎ、時間を節約するために極めて重要である。このアプローチにより、チームメンバー間の調整と理解が深まり、後で問題を修正するのではなく、より成功したプロジェクト成果につながる。バリデーション計画は、リスクアセスメントと緩和プロセスを定義するものでなければならないし、SOPや会社の方針を参照することもできる。しかし、早期に設置し、すべてのソフトウェアと要件を検証するための道筋を作るための生きた文書およびツールとして使用しなければならない。この作業を遅らせたり、最小限に抑えたりすると、プロジェクトの実行フェーズで誤解や対立を生むことになる！
レッスン3：プロジェクトの文書化戦略を明確にする。
- 標準的なバリデーション作業における正式なバリデーションファイルだけでなく、複数の形式で提供される可能性のあるベンダーからの記録、多数のソースから生成された電子記録、メーカーの情報、およびバリデーションを完了するために必要となる可能性のあるその他のデータを取り扱うことができる強固な文書化戦略を確立する。そのプロセスには、様々な文書をレビューし、承認し、保管し、検索し、修正する方法が含まれていなければならない。これは、GMPシステムのバリデーションに不可欠な部分であるため、会社の通常のデータ管理システムや手順とはかなり異なる場合がある。
レッスン4：包括的なバリデーションシステムプロジェクトプランの作成
- バリデーション計画は、前述のリスクベースアプローチや文書管理プロセスなど、バリデ ーションで使用する手順を記載する。バリデーション計画は、バリデーションプロジェクトの範囲と成果物を定義し、成果物の責任と成果物のレビュー／承認プロセスを特定し、必要に応じてプロジェクトを変更することを規定する。バリデーション計画は、この種の検証作業において非常に重要であり、CSA ベースのプロセスを明確に定義し、この種の検証プロセスを使用する際に必要とされる成果物に精通していないチームメンバーを指導するのに役立つものでなければならない。承認された計画は、運用、IT、エンジニアリング、品質、バリデーション、およびその他の関連する利害関係者が、計画にマッピングされた CSA に基づく検証プロセスを理解し、使用することに同意することを保証する。CSA に基づくバリデーション作業では、文書主導のバリデーションに精通した利害関係者が理解し、サポートできるロードマップが必要であるため、これは特に重要である。CSA に基づくプロジェクトの検証作業を定義する優れた検証プロジェクト計画は、プロジェクト期間中、多くの会議や対立をなくすことができ、またなくすことができる。
バリデーションプロジェクトにおいて、計画策定は常に重要であり、見落とされがちなフェーズである。バリデーション作業において CSA ガイダンスを導入すると、プロジェクトに参加する多くのリソースが、これまで使い慣れたソフトウエアのバリデーションとは異なる考え方に触れることになるため、このフェーズの重要性はさらに高まります。計画段階の成果物は、CSA に基づくバリデーション作業を成功させるための礎石であり、プロジェクト実行の各段階において、リソースと成果物を正しい軌道に維持する。