2022年9月13日付で、FDAがドラフトガイダンス「Computer Software Assurance for Production and Quality System Software」 (以下、CSAガイダンス) を公開しました。CSAガイダンスは医療機器の製造または品質システムの一部として使用される、コンピュータシステムおよび自動データ処理システムのためのコンピュータソフトウェア保証に係る推奨事項を提供するものです。現状では、医療機器企業における最終製品の品質保証においてCSV要求が最も高い障壁となっています。現在、規制要件で要求されているCSV (Computerized System Validation) は、文書化要求が多く、実施のためには時間、労力、コストがかかるという問題点がありました。しかも、CSVで作成される文書は、製品の品質保証や患者の安全性の担保のために使用されるものではなく、監査や当局査察に提示する目的で作成されてきました。つまり、無駄にコンプライアンスコストを消費してしまっているという問題がありました。企業が費やしたコンプライアンスコストは、治療費や薬価等に転嫁され、結果的には患者負担になっていました。
　こういった問題点を解決すべく、FDAの医療機器センターであるCDRHは、2011年からCase for Quality Programを推進し、業界やGAMPを巻き込んで、CSAガイダンスの作成を実施してきました。CSAガイダンスは、これまでのCSVにおける“煩雑さ”を取り除くものとなりました。CSAガイダンスは、医療機器の製造または品質システムに使用されるソフトウェアの信頼を確立し、追加的に厳密な保証を行うことが適切である場合を特定するためのリスクベースのアプローチによってコンピュータソフトウェアを評価するためのものです。さらに、CSAガイダンスは21 CFR Part 820 (QSR) で求められるコンピュータソフトウェアの検証に係る要求を満たすための、客観的な証拠を提供するために適用できるさまざまな方法とテスト活動についても説明しています。CSAガイダンスはCDRHが主管していますが、ヒト用医薬品のセンターであるCDER (Center for Drug Evaluation and Research) およびバイオ医薬品のセンターであるCBER (Center for Biologics Evaluation and Research) も協力して活動しています。さらにCSAガイダンスの策定には、ISPEのGAMPワーキングチームも加わっています。つまり医療機器のみならず、医薬品にも対応できるものです。また、CSAガイダンスは、1997年に施行された21 CFR Part 11 “Electronic Records; Electronic Signature”に代わる新しいコンピュータシステムにおけるFDA共通のガイダンスともなります。
　CSAガイダンスの適用範囲は、医薬品や医療機器の製造、測定・分析、品質システムの履行に使用するソフトウェアが対象となります。品質システムの履行に使用するソフトウェアとは、具体的にはERP、LIMS (ラボデータベース) 、LMS (教育管理システム) 、EDMS (ドキュメント管理システム) 、イベント管理システム (苦情・CAPA管理システム) などが相当します。コンピュータシステムで大事なことは、患者の安全性、データインテグリティ、製品の品質などを担保することです。そのため、直接的ではなく、間接的にそれらに影響するシステム (例:教育管理システム) などはいたずらに文書数や文書量を増やす必要はありません。例えば、必ずしもテストスクリプトを作成する必要はありません。大事なことはテスト結果を注視することです。ただし、文書や記録がないということは、実施していないとみなされることになるという原則は変わりません。また文書間におけるトレーサビリティマトリックスも依然として重要です。
　本セミナーでは、CSVとCSAの相違点を分かりやすく解説いたします。

1. はじめに
   • CSAガイダンスドラフトの公開
   • CSAガイダンスとは
   • 基準からリスクベースドアプローチへ
   • PIC/S GMP Annex 11の改定
   • GAMP 5 2nd Edition
2. なぜCSAが必要か
   • なぜFDAはコンピュータソフトウェアアシュアランスを導入するのか?
   • CSAが必要になった背景
   • Is the Potato Chip Industry More Hi – Tech than Pharmaceuticals?
3. 用語解説
   • 非製品ソフトウェア (Non – Product Software) とは
   • 直接的なシステムと間接的なシステム
4. Case for Qualityとは
   • Case for Qualityとは
   • Journey of FDA CSV Team
   • Case for Qualityの目的
   • 品質に重点を置いたアプローチを採ることの利点
5. クリティカルシンキングとは
   • 「スコッティ」のデザインはクリティカルシンキングにより決められた
   • クリティカルシンキング
   • CSVに対する思い込み
6. リスクベースドアプローチとは
   • リスクベースドアプローチとは
   • 製品とプロセスの理解
7. GPSVとは
   • ソフトウェアに起因した医療機器事故 (1985年〜1987年 Therac-25)
   • Therac – 25の事故調査を通じて分かったこと
   • 医療機器向けのソフトウェアバリデーションに関するFDAガイドラインFDA Guidance for industry and FDA staff / General Principles of Software Validation
8. 医療機器におけるCSV要求
   • 医療機器企業が実施しなければならないソフトウェアバリデーションについて
   • 医療機器におけるCSV要求
   • FDA21 CFR Part 11 electronic records;electronic signature§11.10 (a) バリデーション
   • FDA21 CFR Part 820 Quality System Regulation§820.70 製造および工程管理
   • ISO 13485:2016におけるソフトウェアバリデーション要求
   • 4 品質マネジメントシステム 4.1 一般要求事項
   • 7 製品実現 7.5 製造およびサービスの提供
   • 7 製品実現 7.6 監視機器および測定機器の管理
   • ISO/TR 80002-2:2017 Medical device software – - Part 2: Validation of software for medical device quality systems
9. CSAガイダンス概要
   • 非製品ソフトウェアのCSVの合理化
   • CSAガイダンスの概要
   • CSAはGPSVガイダンスを補足する
   • CSAガイダンスの適用範囲
   • CSAガイダンスとリスクベースドアプローチ
   • CSAガイダンスの5つの特長
   • CSVからCSAへ
   • CSAアプローチによるパラダイムの反転
   • CSAガイダンス (案) 目次
   • CSAガイダンスの問題点
10. CSAに関する質疑応答
    • CSAに関する質疑応答
    • コンピューターシステムバリデーション (CSV) とコンピューターソフトウェアアシュランス (CSA) の違い
    • FDAがこの変更を行うのはなぜか?
    • 「製品で使用されていないソフトウェア」 (または製品以外のソフトウェア) とはどういう意味か?
    • これは医療機器企業のみが対象か?
    • 間接システムと直接システムとは何か?
    • FDAは、CSVの取り組みが不十分である企業への言及をし始めている。査察官はCSAイニシアチブについてどのようにトレーニングされるのか?
    • CSAはGAMPにとって何を意味するか?GAMPは廃止されるか?
    • 21 CFR Part 11への影響は?
    • 監査証跡はどうか?
    • ISO 13485はどうか?
    • MDSAPはどうか?
    • IQ、OQ、PQにとってどのような意味があるか?
    • CSAはEU当局、MHRAなどに受け入れられるのか?
11. CSAのフレームワーク
    • CSA実施手順
    • 使用目的 (Intended Use) を特定する
    • リスクベースのアプローチを決定する
    • FDAは何を気にかけているか? リスクに関する考慮事項
    • ソフトウェア保証のための適切な方法と活動
    • 適切な記録
    • ソフトウェア保証のための適切な方法と活動
    • 適切な記録の確立 〜保証活動および記録の例〜
    • 業界チームの推奨事項
12. システムライフサイクル
    • ライフサイクル管理
    • 一般的な仕様と検証のアプローチ ー Specification & Verification Approach
    • ライフサイクル内開発フェーズと支援プロセス
    • システムライフサイクルフェーズと成果物 (例)
    • 開発:定義フェーズの成果物 (例)
    • 初期リスクアセスメント 〜製品とプロセスの理解〜
    • GxP評価
    • 開発:実装フェーズの成果物 (例)
    • 機能仕様書
    • 市販のパッケージソフトウェアとCSV成果物
    • 開発:テストフェーズの成果物 (例)
    • トレーサビリティマトリックスと機能リスク評価
    • Scriptedテスト (例)
    • ビジネステスト (UAT:User Acceptance Test) とは
    • 開発:デプロイフェーズの成果物 (例)
    • 保守フェーズ
    • 変更管理 (Change Control) の要点
    • サービスレベルアグリーメントと災害対策
13. ドラフトガイダンス逐条解説
    • I. 序文
    • II. 背景
    • III. 適用範囲
    • IV. コンピュータソフトウェア保証
    • V. コンピュータソフトウェア保証リスクフレームワーク
    • V. コンピュータソフトウェア保証リスクフレームワークA. 意図する使用の特定
    • V. コンピュータソフトウェア保証リスクフレームワークB. リスクベースのアプローチの決定
    • V. コンピュータソフトウェア保証リスクフレームワークC. 適切な保証活動の決定
    • V. コンピュータソフトウェア保証リスクフレームワークD. 適切な記録の確立
    • V. コンピュータソフトウェア保証リスクフレームワークD. 適切な記録の確立表 1 – 保証活動および記録の例
    • V. コンピュータソフトウェア保証リスクフレームワークD. 適切な記録の確立
    • 附表 A. 例
    • 附表 A. 例例 1: 不適合管理システム
    • 附表 A. 例例 1: 不適合管理システム表 2. 不適合管理システムにおけるコンピュータソフトウェア保証の例
    • 附表 A. 例例 2: 学習管理システム (LMS)
    • 附表 A. 例例 1: 不適合管理システム表 3. LMS のコンピュータソフトウェア保証の例
    • 附表 A. 例例 3: ビジネス・インテリジェンス・アプリケーション
    • 附表 A. 例例 1: 不適合管理システム表 4. ビジネスインテリジェンスアプリケーションのコンピュータソフトウェア保証の例
• 質疑応答