FDAの医療機器ソフトウェア機能の市販前申請ガイダンスが18年ぶりに改訂された

FDA 米食品医薬品局 が、医療機器を市販前申請する際の「デバイスソフトウェア機能の市販前申請の内容」（Content of Premarket Submissions for Device Software Functions）のガイダンスを 2023年6月14日に発行した。

このガイダンスは、米国で医療機器を販売する際に、ソフトウェアが含まれている場合は、このガイダンスに従って必要なドキュメントを FDA に提出しなさいという内容だ。

この文書は、2005年5月に発行された「医療機器に含まれるソフトウェアの市販前提出の内容に関するガイダンス」に代わるもので、内容はだいぶ変わっている。

とはいうものの 2021年11月にドラフトが公開されていたので、こんな感じで変わるということはアナウンスされていた。（FDAのガイダンスは ドラフト→ Final というプロセスを踏むが、ドラフト段階でもできているかどうか聞かれる）

一番の変更点は、2005年までのガイダンスでは、タイトルが「Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices」（医療機器に含まれるソフトウェアのための市販前ガイダンスの内容）だったのが、「Content of Premarket Submissions for Device Software Functions」（デバイスソフトウェア機能の市販前申請の内容）になった点だ。

これは何を意味しているかというと、2005年のガイダンスでは、「医療機器に含まれるソフトウェアに関するいろいろな説明をせよ」だったのが、2023年のガイダンスでは、医療機器に含まれるではなく、医療機器ソフトウェアの機能 がターゲットになったという点が異なる。

同じように見えるかもしれないが、2005年のガイダンスでは、医療機器に含まれるソフトウェアが審査の対象だった。2023年のガイダンスでは、医療機器に含まれるソフトウェアだけでなく、医療機器が提供する機能として、医療機器が連携するクラウド上のソフトウェアや、スマホやタブレットのブラウザやアプリケーションなども含めて「医療機器単体でできることだけでなく、ネットワークを含めたトータルのシステムでできること、しようとしていること」を説明することが求められるようになった。

以前は、ソフトウェアに障害が発生したときの患者への影響に応じて Level of Concern が Minor, Moderate, Major の3段階に設定され、それぞれのレベルに応じて提出するドキュメントが分かれていたが、今回は、基本ドキュメントと拡張ドキュメントの2段階になった。

拡張ドキュメントになる条件は以下になる。

医療機器のソフトウェア機能に関連する障害や欠陥が、患者、デバイスの使用者、または使用環境の他の人々に対して死亡または重大な負傷の恐れを伴う危険な状況を引き起こす可能性がある場合

下記に各ドキュメントレベルに応じて、求められる内容を示す。

Software Documentation Elements ソフトウェア ドキュメント 要素	Basic Documentation Level 基本ドキュメントレベル	Enhanced Documentation Level 拡張ドキュメントレベル
Documentation Level Evaluation ドキュメント レベル評価	A statement indicating the Documentation Level and a description of the rationale for that level. ドキュメンテーションレベルを示す声明と、そのレベルの根拠の説明。
Software Description ソフトウェア説明	Software description, including overview of significant software features, functions, analyses, inputs, outputs, and hardware platforms. ソフトウェアの説明、重要なソフトウェアの特徴、機能、分析、入力、出力、およびハードウェアプラットフォームの概要を含める。
Risk Management File リスクマネジメントファイル	Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report. リスクマネジメント計画、リスクが適切に軽減されていることを示すリスクアセスメント、およびリスクマネジメント報告書。
Software Requirements Specification(SRS) ソフトウェア要求仕様書(SRS)	SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other software documentation elements (e.g., risk management file, software design specification, system and software architecture design chart, software testing). SRS（Software Requirements Specification）文書は、システムまたはソフトウェアのニーズや期待事項を組織的な形式で記述し、ソフトウェアシステムレベルまたはサブシステムレベルに応じて、他のソフトウェア文書要素との情報のトレース性を理解するための十分な情報を提供する（例：リスクマネジメントファイル、ソフトウェア設計仕様、システムおよびソフトウェアアーキテクチャ設計図、ソフトウェアテスト結果など）。
System and Software Architecture Design システム及びソフトウェアアーキテクチャ設計	Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products (including information technology (IT) infrastructure and peripherals) interact with the system and software. デバイスを構成するモジュール、レイヤー、およびインターフェースの詳細な図解、それらの関係性、データの入力/出力とデータのフロー、およびユーザーや外部製品（情報技術（IT）インフラストラクチャや周辺機器を含む）がシステムとソフトウェアとのやり取りをする方法についての図解。
Software Design Specification (SDS) ソフトウェア設計仕様(SDS)	FDA is not recommending the SDS as part of the premarket submission. Sponsor should document this information on the design via the DHF for the device. During premarket review, FDA may request additional information, if needed, to evaluate the safety and effectiveness of the device. FDAは、市販前申請の一環としてSDS（Software Development Standards）の提出を基本ドキュメントレベルでは推奨していない。製造業者は、医療機器の設計に関するこの情報をデバイス履歴ファイル（DHF）に文書化する必要がある。市販前審査中、FDAは、必要に応じて、医療機器の安全性と有効性を評価するために追加の情報を要求することがある。	SDS documentation, including sufficient information that would allow FDA to understand the technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness. SDS（Software Development Standards）文書には、FDAがソフトウェアの機能の技術的な設計詳細、ソフトウェア設計がSRSのすべての要件を完全かつ正しく実装している方法、およびソフトウェア設計が意図された使用目的、機能、安全性、有効性に関してSRSとのトレース性を理解するために十分な情報が含まれる。
Software Development, Configuration Management, and Maintenance Practices ソフトウェア開発、構成管理(コンフィグレーションマネジメント)及び保守	A summary of the life cycle development plan and a summary of configuration management and maintenance activities; ライフサイクル開発計画の概要と、構成管理および保守活動の概要の要約。 OR 又は A Declaration of Conformity36to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable. FDAが認識しているIEC 62304のバージョンに対する適合性宣言（Declaration of Conformity）：該当する場合には5.1.1-5.1.3、5.1.6-5.1.9の細分箇条、箇条6（ソフトウェア保守プロセス）、および箇条8（ソフトウェア構成管理プロセス）などが含まれる。	A summary of the life cycle development plan and a summary of configuration management and maintenance activities; ライフサイクル開発計画の概要と、構成管理および保守活動の概要の要約。 OR 又は A Declaration of Conformity36to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable. FDAが認識しているIEC 62304のバージョンに対する適合性宣言（Declaration of Conformity）：該当する場合には5.1.1-5.1.3、5.1.6-5.1.9の細分箇条、箇条6（ソフトウェア保守プロセス）、および箇条8（ソフトウェア構成管理プロセス）などが含まれる。
Software Testing as Part of Verification and Validation 検証(ベリフィケーション)および妥当性確認(バリデーション)の一部としてのソフトウェアテスト	A summary description of the testing activities at the unit, integration and system levels; ユニット、統合、およびシステムレベルでのテスト活動の概要説明 AND 及び System level test protocol including expected results, observed results, pass/fail determination, and system level test report. システムレベルのテスト手順書（テストプロトコル）を含み、期待される結果、観測された結果、合格/不合格の判定、およびシステムレベルのテストレポートを含む。	Basic Documentation Level, PLUS 基本ドキュメントレベルに 加えて unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports. ユニットおよび統合レベルのテスト手順書（テストプロトコル）を含み、期待される結果、観測された結果、合格/不合格の判定、およびユニットおよび統合レベルのテストレポートを含む。
Software Version History ソフトウェアバージョン履歴	A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version. 以前にテストされたソフトウェアバージョンの履歴を含み、日付、バージョン番号、以前にテストされたソフトウェアバージョンとの関連でのすべての変更の簡単な説明が含まれる。
Unresolved Software Anomalies 未解決のソフトウェア異常	List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness. 未解決のソフトウェアの異常のリストと、各未解決のソフトウェアの異常がデバイスの安全性と有効性に与える影響の評価。

特に注目して欲しいのは、System and Software Architecture Design（システム及びソフトウェアアーキテクチャ設計）の部分で、「デバイスを構成するモジュール、レイヤー、およびインターフェースの詳細な図解、それらの関係性、データの入力/出力とデータのフロー、およびユーザーや外部製品（情報技術（IT）インフラストラクチャや周辺機器を含む）がシステムとソフトウェアとのやり取りをする方法についての図解。」の提出を求められることになった。

今回のガイダンスには Appendix B に このシステム及びソフトウェアアーキテクチャ設計図の例が3つ示されている。

1. ハンドヘルド診断デバイス

2. 患者と医療提供者向けのアプリケーションを備えた埋め込み式治療デバイス

3. 取得された医療画像を解析するためのクラウドベースのデバイスアルゴリズムのシステムおよびソフトウェアアーキテクチャ

これらのダイアグラムはハードウェア、ソフトウェアを含むシステム全体の静的なアーキテクチャ図で、この図は 一般的なURLの表記ではなく FDAの独自の表記法である。

凡例を付けていれば、この様式とまったく同じでなくてもよいようだが、このFDAが示す表記法で 医療機器申請をすれば審査が早く進むのだろう。

特徴的なのは、ハードウェアモジュール、ソフトウェアモジュール、OTS（市販されている既製のソフトウェア製品）を区別しており、それらの関係性をインタフェースの矢印線で示しているところだ。

2の 「患者と医療提供者向けのアプリケーションを備えた埋め込み式治療デバイス」のアーキテクチャ図を見ると分かるのは、埋め込み式の治療デバイスが物理的な医療機器なのだが、実際には、リーダー/プログラマと通信したり、リーダー/プログラムを通して、クラウドにデータを送ったり、モバイル端末でデータを見たりするような使い方をする（＝意図する使用としている）ことである。

ようするに、現代の医療機器は、医療機器単体で使用することは少なくなってきていて、ネットワークに接続して、クラウドで機械学習したり、モバイル端末で医療機器の情報を閲覧したりすることが当たり前になってきているということだ。そのため、患者リスクは医療機器の中だけに留まらず、医療機器から外に出た情報がどのように使われるのかも含めて、リスクマネジメントしないといけなくなってきている。

だからこそ、FDAのガイダンスのタイトルが「医療機器に含まれるソフトウェアのための市販前ガイダンスの内容」から「デバイスソフトウェア機能の市販前申請の内容」に変わったのだ。

規制当局としてチェックしなければいけないのは医療機器に含まれるソフトウェアだけではなくなったので、医療機器のソフトウェア機能として、ネットワークを含めた接続機器や機能全体を審査しないといけなくなったのである。

それにともない、医療機器が出力する情報は仕様を公開するので自由に使ってくださいという考え方はNGとなっている。相互運用性（Interoperability）を医療機器製造業者が定義した上で、その安全性や有効性の妥当性を確認する必要があるということになる。

そうなると、医療機器からどんな情報が出たり入ったりしていて、どんな機器やシステムと接続しているのか、それらの機器・システムには市販のソフトウェアが使われてるのかどうかを見る必要が出てくる。だからこそ、システム及びソフトウェアアーキテクチャ設計図が必要となった。

また、システム全体の機能として安全性や有効性を確認するためには、それぞれの機能モジュールの要求仕様を確認した上で、それらの要求仕様が検証され、バリデーションされているかのトレースを取る必要がある。

そのため、システム及びソフトウェアアーキテクチャ設計図の各モジュールには、要求仕様の番号が記載されている。（例 SWReq X.Y)  また、ところどころで機能モジュールの Intended Use（意図する使用）がノートで説明されている。例えば、1のハンドヘルド診断デバイスでは、解析エンジンのノートに下記のノートが付けられている。

Analysis engine consists of software algorithms for analyzing signals acquired from patient （解析エンジンは患者から取得した信号を解析するためのソフトウェアアルゴリズムで構成されています）

システム及びソフトウェアアーキテクチャ設計図が、SRS（ソフトウェア要求仕様）でも提示を求められているのは、各モジュールの要求仕様を確認したり、トレースを取ったりしたいからである。

医療機器ソフトウェアの安全性や有効性を確認するために、規制当局がシステムアーキテクチャまで踏み込んで審査する時代になった。

システムエンジニアやソフトウェアエンジニアは、ソフトウェアを作る以前に、さまざまなモデリングができなければいけなくなってきている。今回は、システム及びソフトウェアアーキテクチャ設計図だが、サイバーセキュリティでは脅威モデリングとしてデータフローダイアグラムを信頼境界も含めて描くことが求められてる。

現代のソフトウェアエンジニアは当たり前にモデリングができることが求められるようになった。

今回の FDA が要求する システム及びソフトウェアアーキテクチャ設計図 は、UML モデリングツール EnterpriseArchitect で描くことができる。

↓アドインの説明

System and Software Architecture Diagramの作成

EA 16.1 にこのアドインを取り込んで描いた図を示す。

すり合わせ的に作ってきたソフトウェアシステムは、こんなに綺麗に機能=モジュールになっていないかもしれないが、AIなど多様な機能を取り入れたシステムを実現するには、機能分割されたモジュールを組み合わせた設計にしていく必要がある。

すり合わせ一本でここまでソフトウェアを開発してきた技術者には、モデリングできるように今回のようなシステムアーキテクチャを描く練習するとともに、是非「リアルタイムOSから出発して 組込みソフトエンジニアを極める」を読んで、どうやって時間分割のハードルを越えて、さらに機能分割のハードルを越えるのかを学んで欲しい。