Skip to Content
Testing規制された研究システムのための証拠指向のテスト

規制された研究システムのための証拠指向のテスト

OpenFactory は、委託研究組織の限定されたインフラストラクチャとアプリケーションのチェックを自動化できます。 25 コンプライアンスを決定したり、コンピュータ化されたシステム全体を自動的に検証したり、規制対象組織の品質システムや責任ある承認を置き換えたりするものではありません。

21 CFR Part 11  は、指定された電子記録と署名に適用され、オペレーティング システム イメージを超えた制御 (システムの検証、記録の保護と取得、アクセスと権限のチェック、タイムスタンプ付き監査証跡、トレーニング、ポリシー、文書管理、署名要件など) が含まれます。適用される述語ルールと使用目的は、資格のある法律、規制、および品質担当者によって確立される必要があります。

FDA の現在の Computer Software Assurance ガイダンス  では、生産および品質管理システム ソフトウェアに対するリスクベースのアプローチが説明されています。チームは、一般的なテスト数を検証として扱うのではなく、システムとコンテキストへの適用性を判断する必要があります。

OpenFactory の証拠が裏付けるもの

  • イメージ ビルドの正確なレシピとソースの出所。
  • ブートされたゲストのパッケージ、サービス、ファイル、ポート、およびコマンド アサーション。
  • サポートされているアサーションが実行される、限定された GUI とスクリーンショットの証拠。
  • 実行ごとのタイムスタンプ、出力、およびアーティファクト識別子。
  • 反復可能な陰性および回復テスト。そして
  • 新しい成果物と承認されたベースラインとの比較。

各項目は、記載された要件の証拠です。単独で規制上の受容性を確立できるものはありません。

使用目的とリスクから始める

テストを作成する前に、次のことを文書化します。

  1. コンピュータ化されたシステムの使用目的。
  2. 規制されている記録と署名 (存在する場合)。
  3. ユーザー、役割、インターフェース、データフロー。
  4. 患者、製品品質、データ完全性のリスク。
  5. それらのリスクに関連する要件と許容基準。
  6. サプライヤーおよびコンポーネントの責任。そして
  7. 変更、インシデント、バックアップ、リカバリ、保持、廃止の手順。

オペレーティング システム イメージは、そのシステム内の構成アイテムの 1 つにすぎません。

制限付きシナリオの例

この例では、合成統合サービスとローカル監査構成をチェックします。 EDC、LIMS、安全性データベース、または Part 11 ワークフローが検証されているとは主張しません。

{ "id": "synthetic-integration-smoke", "name": "Synthetic integration and audit smoke test", "enabled": true, "tests": ["boot", "login", "packages", "services"], "custom_tests": [ { "description": "Confirm the synthetic receiver and audit controls are present.", "assertions": [ { "type": "service_running", "description": "The synthetic receiver is running.", "params": {"service": "synthetic-receiver"} }, { "type": "port_listening", "description": "The synthetic receiver listens on its lab port.", "params": {"port": 2575} }, { "type": "service_running", "description": "The Linux audit daemon is running.", "params": {"service": "auditd"} }, { "type": "file_contains", "description": "The approved synthetic data path has an audit watch.", "params": { "path": "/etc/audit/rules.d/research-system.rules", "content": "-w /var/lib/synthetic-study" } } ] } ] }

共有ビルドおよびスクリーンショット システムでは、合成された非機密テスト データのみを使用してください。スクリーンショットにより、サブジェクト識別子、資格情報、通知、または無関係なデスクトップ コンテンツが公開される可能性があります。収集する前に、キャプチャ、編集、アクセス、保持、エクスポート、および削除の制御を定義します。

証拠パケット

承認されたテスト実行ごとに、以下を保存します。

  • 要件とリスクの識別子。
  • テストプロトコルと期待される結果;
  • レシピのリビジョン、ソースのコミット、依存関係のインベントリ、およびイメージのダイジェスト。
  • 環境とテストデータのアイデンティティ。
  • 生の出力、正当化されたスクリーンショット、タイムスタンプ、およびランナーのバージョン。
  • 逸脱、失敗したステップ、調査、および再テストのリンク。
  • 査読者の身元、決定、日付。そして
  • 要件から証拠およびリリース決定までのトレーサビリティ。

自動化されたイベント ログまたはスクリーンショット フォルダーのラベルを「12」監査証跡として再ラベル付けしないでください。 Part 11 監査証跡制御は、該当するシステム全体での規制された記録アクション、保持、可用性、および整合性に関係します。

変更と回帰のワークフロー

  1. 提案された変更の影響を評価します。
  2. リスクと影響を受ける要件に基づいてテストを選択します。
  3. 新しい不変アーティファクトを構築します。以前に承認された成果物を保持します。
  4. 制御された環境でプロトコルを実行します。
  5. 不利な証拠を削除せずに失敗と逸脱をレビューします。
  6. 必要な品質、セキュリティ、ビジネス、および規制上の承認を取得します。
  7. 変更管理を通じて展開し、実稼働構成を検証します。
  8. ドリフトを監視し、必要に応じてテストされた回復パスを実行します。

OpenFactory は、実際に自動化するステップの証拠収集を短縮できます。規制対象組織は、使用目的の検証、手順管理、データ ガバナンス、および最終的なリリースの決定に対して引き続き責任を負います。