医療機器としてのソフトウェアは、規制上通常とは異なる立場にあります。製品は、ハードウェア デバイス用に元々構築された文書化プロセスが処理できるように設計されていたよりも速く変化します。 SaMD 技術ファイルには、ソフトウェアが何を行うかだけでなく、リリース サイクル全体にわたってソフトウェアがどのように開発、検証、保守されたかについても記録する必要があります。リリース サイクルは数年ではなく数週間で測定される場合があります。 その違いは、多くのチームが実際に必要なものを過小評価している点にあります。
SaMD 技術ファイルで証明する必要があるもの
一般的なデバイスの説明と使用目的以外に、SaMD ファイルでは通常、以下を示す必要があります。
ソフトウェアによって提供される情報の重要性と、ソフトウェアが扱う医療状況や状態の状態に基づいて定義されたソフトウェア安全性分類
ソフトウェア要件の仕様、アーキテクチャ設計、 検証および検証活動を明確に追跡する詳細な設計文書
ソフトウェア機能の臨床リスクとソフトウェア自体のサイバーセキュリティ リスクの両方をカバーする、ソフトウェアに固有のリスク管理文書
SaMD は生きた製品として維持されることが期待されているため、最初の提出だけでなくすべてのリリースの検証および検証記録
各ソフトウェア アップデートがその製品に対してどのように評価されたかを示す変更管理記録 安全性と有効性への影響、および新たな規制当局への申請が必要かどうか
チームが問題に遭遇する場所
最も一般的なギャップは、文書の欠落ではありません。 これは文書として存在しますが、要件、その設計実装、検証テスト、およびそれに関連する欠陥や変更の間でトレーサビリティ規制当局が期待していることを実証するには十分に整理されていません。 おそらく数十のソフトウェア リリースにわたって、提出時にトレーサビリティを手動で再構築する必要がある場合、それが最大の遅延の原因となります。
2 番目によくあるギャップは、開発ドキュメントと技術ファイルで実際に参照されている内容の間のバージョン管理のずれです。特に、ソフトウェア チームが規制ドキュメントの更新よりも速く反復している場合に起こります。
検証済みのドキュメント管理システムがどのように役立つか
文書管理システムは、規制対象業界向けに構築されており、両方の問題に直接対処します。 バージョン管理と承認のワークフローにより、すべてのドキュメントが特定の追跡可能なリビジョンに関連付けられるため、技術ファイルには数か月前のスナップショットではなく、ソフトウェアの実際の現在の状態が反映されます。 関連ドキュメント間、設計要件から検証までの相互参照により、提出や監査のたびに手動で再構築する必要はなく、ソフトウェアの進化に合わせてトレーサビリティ チェーンが自動的に維持されます。
技術ファイルを 1 回限りの成果物ではなく、生きた文書として扱う
SaMD ドキュメントを最もスムーズに管理するチームは、ソフトウェア自体を扱うのと同じ方法で技術ファイルを扱う傾向があります。つまり、継続的に保守され、バージョン管理され、いつでも監査に対応できるようになります。 提出または検査の期限が来たときに遡って組み立てられるものではありません。 このアプローチの変化こそが、急速に進むソフトウェア開発と厳格な規制当局が要求するドキュメンテーションとの間のギャップを実際に埋めるものです。
リリース間でのドキュメントのトレーサビリティが SaMD ドキュメント プロセスで苦労している場合、ドキュメント管理システム ページでは、21 CFR Part 11 準拠の環境でバージョン管理と相互参照がどのように機能するかについて説明します。
