この記事は3回シリーズの第2回で、FDAの「生産および品質システムソフトウェアのコンピュータソフトウェア保証ガイダンス（CSA）」の草案を使用した2つのバリデーションプロジェクトを完了した際に、我々のバリデーションチームが学んだ教訓を紹介するものである。リソースの数、実行される作業の量、および完成した成果物の数は、実行フェーズにおいて常に最高レベルである。このため、実行フェーズは、検証作業中に最も多くの問題が発生し、プロジェクトのコストとスケジュールに大きな影響を与える場所である。この記事では、プロジェクトの実行段階におけるCSA手法の実施中に発生する問題を防止するか、少なくともその影響を低減するために実施できるアクションを紹介する。
レッスン1：すべての検証テストについて、包括的なテスト計画とプロトコルを作成する
バリデーション計画は、システムのバリデーションを完了するために必要な成果物を特定する。それでもなお、テスト計画とプロトコルの内容には、計画で定義された検証要件を満たす情報とテストが含まれていなければならない。CSAガイダンスを使用する際に問題となるのは、低リスクの要件を検証するためにベンダーが作成した文書を使用することである。ベンダーのテスト文書は、通常、検証作業の範囲外で作成され、多くの場合、テストの期待値と結果、問題の特定と解決、テスト実行者の特定とテスト実行日が文書化されていない。CSA ガイダンスでは、システムの動作を検証するためにテスト結果を使用する場合、テスト文書にこれらの情報を含めることを求めています。テスト中にこれらの項目を記録しないと、不十分な文書化されたテストの再テストにより、プロジェクトの完了が遅れる可能性があります。ベンダーの品質プログラムと手順を評価し、その成果物がガイダンスの適切な記録に関する要求事項を満たしていることを確認する。ベンダーのテストをレビューし、これらの要求事項を満たさない場合、ガイダンスに適合するようにテストを実行前に修正することが可能かもしれない。それは、イニシャル／日付のための余分なスペースを追加したり、発見された問題の解決策を参照したり、テストの目的をより明確に説明したりすることである。ベンダーのテスト文書をアップグレードする積極的なアプローチにより、GxP 記録を検証するための CSA 文書要件を元々満たしていないベンダー・テストの再実行をなくすことができます。
中リスクまたは高リスクの要件は、通常、GxPに準拠したプロセスと手順を用いて作成され、ベンダーの代わりに医薬品製造業者によってレビューされ承認される、より堅牢なプロトコルを用いて検証される。これらの試験結果には、通常、CSAに記載されている許容される試験記録のすべての要素が含まれている。これらの文書を作成する際には、既に完了し、更なる検証を必要としない試験で検証された要求事項を特定するセクションをプロトコルに含めることが良い方法である。例えば、サイト受入試験（SAT）は、工場受入試験（FAT）または低リスク要件を検証する開発試験を参照することができる。据付および運用に関する適格性確認（Installation and Operational Qualification）についても、同様にSATまたはFATを参照することができる。これらのセクションを含むプロトコルの承認は、次の試験段階に移行する前に、バリデーションおよび品質保証グループがこれらの結果を受け入れたことを示す証拠となる。このような慣行に従うことで、過剰で不要なテストが実施されることを防止し、プロジェクトの後半で要求事項やテスト結果をレビューする際に、プロジェクトの利害関係者が驚くことを防ぐことができる。
レッスン2：すべてのテストを綿密に監視する
多くのベンダーは、ほとんど監視されることなく、非公式にテスト結果を記録し、問題点とその解決策をわずかな文書化するだけで、開発テストや工場テストを実施することに慣れていることを忘れないでください。テスト結果を正式に文書化し、発生した問題（およびその解決策）を記録し、すべてのデータエントリに署名して日付を記入することは、多くの場合、新しい慣行です。新しいテスト／文書化プロセスを説明するトレーニングセッションに参加した後でも、特に問題や逸脱に対処する際に、古い習慣に戻ってしまう可能性があります。その結果、納品されたテスト結果や文書が、検証作業で使用するための優れた文書化要件（GDP）（Good Documentation Requirements）を満たさない可能性がある。継続的なモニタリングの仕組みを導入し、実施中に問題を迅速に検知して対処することで、ベンダーが実施するテストによってもたらされる許容できないテスト結果の数を最小限に抑えることができる。特に、最終開発テストと FAT の間にベンダーの成果物を監視することが重要である。ベンダ ーは、システムの出荷承認を得ることに集中し、受け入れ可能なバリデーション文書を作成 することに集中しない。
このような追加的な監視を行うための一つの方法として、ベンダーの試験中に短時間のステータスミーティングを開催し、質問に答えたり、試験要件を強化したりする方法がある。このようなミーティングでテスト結果のサンプルをレビューし、特にテストの初期段階で、適切に文書化されたテスト結果の例を提示することで、プロトコルへの準拠を確認し、適切に記録されたテスト結果の視覚的な例を提供し、プロジェクトの後半で多くの文書化されたテスト結果を変更しなければならないことを防ぐことができます。このような変更は、プロジェクトの後期に驚くほど多くのリソースと時間を追加することになる。この種の監視はまた、開発テストやFATで検出された多くの問題を指摘しながらも、SATや認定テストまで修復を完了させないという過去のベンダーの慣習を抑制するため、プロジェクトの初期段階での問題解決を迅速化する。CSA以前は、ほとんどの企業が妥当性確認試験中のみ適格性確認試験結果を受け入れていたため、このようなやり方は容認されていた。しかし、開発試験やFATの結果をシステムバリデーションの適切な記録として使用することは問題である。
レッスン3：コミュニケーション／コラボレーション
既存のバリデーション手法に従ったバリデーション計画では、効果的なコミュニケーションと、実行中の多くの柔軟性が求められる。CSAガイダンスを使用した新しい手法を採用することで、プロジェクトの全期間にわたってこれら2つのツールを使用することの重要性が高まる。問題点、特にCSAガイダンスの遵守に起因する問題点に焦点を当てたミーティングを開催すべきである。メンバーの中には、変更に違和感を感じたり、希望通りに実施するための補強が必要な場合もあるため、チーム内の風通しをよくする。これらのミーティングにおいても、逸脱や問題解決への協力的なアプローチを促進する。問題の報告や対処、プロジェクトへの最新情報の提供、タスクを完了するための適切なリソースの特定など、明確なコミュニケーションチャネルを確立する。このような行動をとることで、問題解決を迅速化し、チームメンバーに情報を提供し、実行効率を高めることで、プロジェクトのタイムラインを維持することができる。プロジェクトの初期段階で要件トレーサビリティマトリクスを作成し、各検証ステップでそれを更新するのがよい方法です。これにより、各要件のリスク、関連するテストの厳密性、および要件のテスト結果を検証するドキュメントが特定されるだけでなく、プロジェクトの進捗が視覚的に文書化され、成果物の変更が特定され、プロジェクトが完了に近づいたときに特定されるギャップを最小限に抑えることができます。このように検証を迅速に変更できることで、テスト計画やスケジュールへの影響を最小限に抑えることができる。
CSA ガイダンスを実施することは、多くのリソースを、これまで慣れ親しんできたソフトウェア検証とは異なる考え方にさらすことになる。この記事で提案する対策を実施することで、プロジェクトの早い段階で問題を修正し、後の手戻りを減らすことで、実行フェーズからこの予測不可能性を取り除くことができる。実行フェーズの成果物は、規制当局や将来のレビューに対して、システムがどのようにバリデーションされたかを文書化した証拠を提供するため、非常に重要である。バリデーションの結果は、明確、簡潔、完全でなければならず、どれだけテストや再テストが行われたとしても、システム要件が満たされていることを検証しなければならない。