Computer Software Assuranceセミナー

再開催を依頼する / 関連するセミナー・出版物を探す
オンライン 開催

日時

開催予定

プログラム

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

受講料

ライブ配信セミナーについて