FDAはCSVからコンピュータsoftware保証への移行を準備中
FDA、CDRHは、2020年後半に新しいguidance（draft）ガイダンスドキュメント「Computer Software Assurance for Manufacturing, Operations and Quality Systems Software；製造、運用、品質システムsoftwareのコンピュータsoftware保証」を発出する予定をしている。
| Computer Software Assurance for Manufacturing, Operations, and Quality System Software Risk Categorization for Software as a Medical Device: FDA Interpretation, Policy and Considerations |
この新しいガイダンスは、実際に一部のコンピュータsoftwareシステムの運用を合理化することを意図しているといわれている。のguideは、CDRHが主催して、CDER, CBERも共同作業を行っている。PRAT11に代わる、CDRHに限らずFDA内でのコンピュータに関連するguidelineになる予定である。
このGuide（draft）の策定作業は CDRHとISPE（GAMP working Team)の共同作業であること、長くFDAと医薬業界が、CSVの煩雑の緩和を協議した結果である。
目的は、soft wareを患者、医薬品尾品質に及ぼす影響に基づいて、従来とは異なりrisk評価して、影響のあるsoftwareに対してバリデーションを行う、更にCSVで増加した文書作成の仕組みを改めることである。
この内容は、ISPE India のweb セミナーを参照して頂きたい。
https://www.youtube.com/watch?v=LwVw9gJcARA
現在は、draftが発表前であるが、得られた情報で、CSV vs CSAの対比で、どの様に変わるかを示す。
| Title | CSV | CSA |
| Definition | 文書化された証拠を通じて、コンピュータ化されたシステムが、設計されたものを一貫して再現可能な方法で正確に動作するという保証を確立するプロセス。
|
クリティカルベースの考え方をリスクベースのアプローチと組み合わせて適用し、品質、患者の安全性、データの整合性を確保するための新しいフレームワークを開発するプロセス。 |
| Softwareの分類 | 一律 | 企業は、softwareの使用目的を特定し、リスクに基づく分類;低リスク機能は、アドホックテストで評価する。
高リスク機能を持つsoftwareには、手厚く管理・評価する。 |
| Approach | ウォーターフォール、アジャイル、スクラム、ハイブリッドなど、さまざまな検証方法を適用するリスクベースのアプローチ。 | クリティカルベースの考え方に重点を置いたリスクベースのアプローチ、自動化された/スクリプト化されていないテストおよびデジタル技術の適用。 |
| Benefit | システムが目的に適合していることを文書化した証拠。 | 品質保証、患者と製品の安全性、およびデータの整合性に重点を置いて、softwareの品質、新技術、文書の削減、自動化/スクリプト化されていない試験を強化する。時間の短縮 |
| Risk | 文書化された証拠と広範なシステムテストの欠如。 | 自動化された/スクリプト化されていないテストと実証されていない新技術の実施。 |
| Scope Validation | GAMP5にて定義された分類4,5に属するPC systemは、バリデーションが必須 | 製品の安全性や製品の品質に直接影響しないSoftwareを使用すれば、バリデーションは求められない
サポートツールのバリデーションは査察対象にならない |
| Softwareの評価の定義 | 定義されていない | 患者の安全に影響しますか？
•製品の品質に影響を与えますか？ •品質システムの整合性にどのように影響しますか？ |
| Softwareのsupplierの適格性 | 一様に、分類4,5（特注したコンピュータシステム等）は、soft wareの供給者評価が求められる | 品質等に直接影響がないsoft ware；文書管理、苦情処理システムなどの患者や製品に直接影響を与えない品質管理システムsoftwareは、特には求められない。<ただし、範囲外の使用では求められる＞
アドホックテストが必要になる場合がある程度 |
| Softwareの適格性確認 | IQ / OQ / PQは必要 | 頑健性が、重要項目、IQ / OQ / PQは不要になる予定。で |
| 頑健性 | 低リスク機能はアドホックテストで対応可能、高リスク機能は堅牢な試験・評価が求められる |
CSAでの手順 （CDRHがdraftを発出のため、CEDRは、deviceを医薬品に読み替えることになる）
- Softwareの使用目的を特定する
- どの特徴、操作、または機能が、デバイスの安全性、デバイスの品質、または品質システムの完全性に直接影響するかを特定する？
- リスクベースのアプローチで、softwareの分類の決定
- デバイスの安全性またはデバイスの品質に直接影響する自動化機能、操作、または機能を特定。
- これらの識別された自動化機能、操作、または機能が意図したとおりに確実に実行されないことが直接的な患者の安全リスクにつながる条項を特定。
- 特定された自動化のリスクの高い機能、操作、または機能が意図したとおりに確実に実行されるように設計された、適切なリスクベースで保証活動を確立。
- 方法と活動
- Vendor の適格性；既存の供給者（software）の活動とデータを活用
- リスクを軽減するためにプロセス制御の使用を活用する
- CSVのツールを用いて保証活動の自動化
- 必要に応じて、アジャイルテスト手法とスクリプト化されていないテストを使用する
- 電子データ収集と記録作成に使用する
- 監視と保証のために継続的なデータと情報を活用する
- 記録
意図された使用を考慮した保証活動に最も負担の少ない記録を作成する。
何を保証する必要があるか；機能、操作、または機能の影響とリスクレベルの決定。
特定された保証要求項;
結果が受け入れられたことを示すために収集された証拠。
この記録は、FDAの査察官ではなく企業にとって重要であること。
結論、纏め
CSAのguidelineが発効した後は、現在行われているCSVで対象になっているシステムのうち、品質、患者の安全性に係るシステムが、risk分析の結果選択され、選択されはシステム,Softwareがバリデーションの対象になる。（体的には、LIMS, MES,逸脱・CAPA、安全性情報通報システム等に、限定されることになる。
Draftが発出されたら、再度内容を解説する予定である。
