医療機器のためのFDAソフトウェア・ドキュメンテーション

フリーランス レギュラトリーライター Shreya Chenniは、医療機器のためのFDAソフトウェア・ドキュメンテーションのガイドを提供しており、分類に基づく要件の内訳も含まれています。 

のです。 医療機器 industry is seeing rapid technological advancement and a high rate of innovation.  Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness. 

ソフトウェアを含むすべてのデバイスで 510(k)ルートそのためには、特定のソフトウェア関連の書類を提出する必要があります。この記事では、以下の場合に必要な書類について説明します。 510(k)の提出物 また、ソフトウェアの分類に基づいて、どのように起草するかを理解する必要があります。  

医療機器のソフトウェアをどのように分類するか？ 

該当する懸念レベル（LoC）を特定する。3つのレベルがあります。 

• 重大：故障や潜在的な欠陥が、患者や操作者の死亡や重傷に直結する可能性があるもの 

OR 

 故障や潜在的な欠陥は、誤った情報や遅れた情報、あるいは医療従事者の行動によって、間接的に患者や操作者の死亡や重傷につながる可能性があります。

• 中程度：故障や潜在的な設計上の欠陥により、患者や操作者が直接軽傷を負う可能性があるもの。

 OR 

誤った情報や遅れた情報、あるいは医療従事者の行動によって、故障や潜在的な欠陥が間接的に患者や操作者に軽傷を与える可能性があります。 

• 軽度：故障や潜在的な設計上の欠陥があっても、患者や操作者に傷害を与える可能性が低い場合。 

の表1と表2を使用します。 医療機器に搭載されるソフトウェアの市販前提出書類の内容に関するFDAガイダンス をクリックして質問に答え、あなたの「ソフトウェアの懸念レベル」を決定してください。 

医療機器のFDAソフトウェア文書

提出すべき書類は何ですか？

中程度の懸念レベルのソフトウェアと大規模な懸念レベルのソフトウェアでは、11種類の文書を提出する必要があります。一方、軽微な懸念レベルのソフトウェアでは、7種類の文書が必要です。これらの文書に記載されている内容の範囲と程度は、そのLoCに応じて異なります。

次の表は、懸念されるレベルごとに必要な書類を示しています。 

マイナー	モデレート	メジャー
悩みのレベル	悩みのレベル	悩みのレベル
ソフトウェアの説明	ソフトウェアの説明	ソフトウェアの説明
デバイスのハザード分析	デバイスのハザード分析	デバイスのハザード分析
ソフトウェア要求仕様書（SRS	ソフトウェア要求仕様書（SRS	ソフトウェア要求仕様書（SRS
トレーサビリティー分析	トレーサビリティー分析	トレーサビリティー分析
検証とバリデーションのドキュメント	検証とバリデーションのドキュメント	検証とバリデーションのドキュメント
リビジョンレベル履歴	リビジョンレベル履歴	リビジョンレベル履歴
————	建築設計図	建築設計図
————	ソフトウェア設計仕様書	ソフトウェア設計仕様書
————	Software Development Environment Description	ソフトウェア開発環境の説明
————	未解決の異常（バグやディフェクト）について	未解決の異常（バグやディフェクト）について

 

ドキュメントの説明 

1.気になるレベル 

の表1と表2の質問に対する答えを記録する。 医療機器に搭載されるソフトウェアの市販前提出書類の内容に関するFDAガイダンス  この文書では決定された懸念のレベルの根拠を含む。 

2.ソフトウェアの説明

このドキュメントは、デバイスのソフトウェアを紹介するものであり、その特徴、機能性、使用目的についての包括的な概要を示す必要があります。必要に応じて、プログラミング言語、ハードウェア・プラットフォーム、オペレーティング・システム、既製ソフトウェアの使用についても記載してください。また、必要に応じて図や表を掲載してください。 

既製品のソフトウェアを使用する場合は、FDAのガイダンス文書を参照してください。医療機器における既製ソフトウェアの使用に関するガイダンス." 

3.デバイスのハザード分析 

 A device hazard analysis is a must. All the foreseeable hazards associated with the intended use of the device (software and hardware) should be captured. The risk analysis should be conducted in compliance with ISO 14971. The hazard analysis should identify the hazard, hazardous, severity of the hazard, cause of the hazard, risk control measure and verification of the control measure. 

4.ソフトウェア要求仕様

ソフトウェア要求仕様書（SRS）は、ソフトウェアに対するすべての要求事項を文書化したものです。基本的に、要件はソフトウェアが何をすべきかを記述する。要件は、機能、性能、ユーザーインターフェース、規制など、さまざまなバケツに入れることができる。 

マイナーなLoCの場合、SRSは機能的な要求の要約でよいが、中程度やメジャーの場合、要求は詳細であり、典型的なリストでなければならない。リストアップされた各要件には、SRS-01、SRS-02などの要件IDが割り当てられていることを確認する。 

ここでは、SRSの例をいくつかご紹介します。 

ハードウェア要件。についての要件を含める。  

• マイクロプロセッサー 
• メモリーデバイス
• センサー 
• エネルギー源 
• 安全機能
• コミュニケーション

プログラミング要件。プログラムサイズの要件、制限事項などを含む 

インターフェース要件。ソフトウェアとプリンターやモニターなどのハードウェア機器との間の通信についての要件を含む。その他、ソフトウェアが対応しているOSなどの要件も含まれています。 

Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. 

また、ソフトウェアの性能や機能に関する要求事項も含まれることがあります。

• ソフトウェアによるデバイスの制限 
• 内部のソフトウェアテストとチェック
• エラー・割込み処理 
• フォールト検出、耐性、回復特性 12 非拘束の推奨事項を含む 
• 安全性について
• タイミングとメモリの要求 
• 適切であれば、既製のソフトウェアの識別。 

5.アーキテクチャ設計図

 このドキュメントは、ソフトウェアの主要なコンポーネントまたは機能ブロック間の関係、データの流れ、および相互作用を明確に示しています。これは通常、フローチャートやブロックダイアグラムなど、必要に応じた形式で描かれる。中程度の懸念レベルのソフトウェアおよび主要な懸念レベルのソフトウェアについては、デザインチャートに状態図を含めることができる。 

6.ソフトウェア設計仕様書（SDS

要件の実施については、本文書で詳述する。各 SDS には、SRS と同様に SDS-01 のような番号を付ける。SRSに含まれる各要件には、対応する設計仕様が必要である。ただし、1つの設計仕様が一群の要件に対応することも可能である。 

7.トレーサビリティー分析

このドキュメントは、要求事項、設計仕様、ハザード、V&Vテストをリンクしています。トレーサビリティマトリクスは以下のように作成され、必要に応じて詳細を追加することができます。 

ユーザーニーズ（オプション	SRS	SDS	危険性	V&Vテストケース
UND-001	SRS-001 SRS-002	SDS-001	HAZ-001	TC-001
UND-002	SRS-002	SDS-001 SDS-002	HAZ-002	TC-002 TC-004

 

8.ソフトウェア開発環境記述（SDED

中程度の懸念レベルのソフトウェアは、ソフトウェア開発ライフサイクル計画、メンテナンス、ソフトウェア活動を記載したSDEDの提出が必要です。中程度とメジャーでは詳細のレベルが異なる。EN 62304 Table 1: Table A.1 - Summary of requirements by software safety classを参照のこと。これは、クラスごとに含まれるべき要素と文書化されるべき活動を特定するために使用できる。A、B、Cの3つのクラスは、FDAの懸念レベルと一致しています。  

9.検証および妥当性確認のための文書

マイナーなLoC。デバイスレベルのテストと統合テスト（該当する場合）を文書化する。テストケースには、受け入れ基準とテスト結果の概要があることを確認する。 

中程度のLoC。妥当性確認と検証の活動とその結果をまとめた文書。受け入れ基準を含める。トレーサビリティー分析がテストケースIDを参照していることを確認する。 

メジャーなLoC。上記（Moderate LoC）の情報に加えて、失敗したテストとそれに対する変更の記述を文書化する必要がある。 

10.リビジョンレベル履歴

ソフトウェアへの主な変更点を文書化し、最終ラインの時間/エントリがソフトウェアの最新バージョンであることを確認する。バージョン番号、日付を特定し、旧バージョンに対する変更点を説明する。 

11.未解決のアノマリー 

リリースされるソフトウェアに存在する未解決のバグを文書化する。それぞれのバグについて以下のことを把握する。 

• 問題点
• デバイスのパフォーマンスへの影響 
• これらのバグを修正するための計画的なスケジュール（該当する場合 

The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires サイバーセキュリティ Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: 医療機器におけるサイバーセキュリティ管理のための市販申請書の内容について. 

リファレンス 

• 医療機器に搭載されるソフトウェアの市販後申請書の内容に関するガイダンス

医療機器のFDAソフトウェア・ドキュメンテーションでお困りですか？フリーランスのレギュラトリー・ライターと連絡を取ってください。 FDA申請エキスパート をKolabtreeに掲載しました。