【連載】FDAは何を見ているのか？ 「証拠の構造」を理解しなければ、審査は通らない（第3回）

FDAへの医療機器申請で最も件数が多い経路が510(k)（市販前届出、ファイブテンケイ）です。510(k)とは、新しく市場に出す医療機器が、すでに合法的に販売されている同種の医療機器（Predicate Device、既承認機器）と実質的に同等（Substantial Equivalence）であることを示す届出制度です。（図表1）

FDAはこの届出を受理する前に、書類が形式的に完備しているかを確認する「Refuse to Accept（RTA、受理拒否）」という事前審査を行います。2023年10月に電子提出テンプレート「eSTAR」が必須化されて以降、RTAで差し戻される割合は改善しましたが、ある分析によれば、それでも申請の約3割は少なくとも一度はRTAで差し戻されています。制度導入当初、その割合は6割に達していたと報告されています。

RTAを通過し、実質的な審査（Substantive Review）に入ってからも壁は続きます。審査官が技術文書の内容に疑問を持つと「Additional Information（AI、追加情報要求）」と呼ばれる照会状が発行され、企業は原則180日以内に回答しなければなりません。ある分析によれば、510(k)申請の約7割がこのAI照会を受けているとされます。

ここで重要なのは、RTAやAI照会の主な原因が「テストの失敗」ではないという点です。多くの場合、テスト自体は実施されており、結果も悪くありません。それでも審査が止まるのは、「なぜそのテスト結果によって安全性・有効性が証明されたと言えるのか」という説明が欠けているからです。

この問題に、FDAは2010年、興味深い形で正面から向き合いました。輸液ポンプ（インフュージョンポンプ）は、当時ソフトウェアの不具合による重大なリコールが相次いでいた製品分野です。FDAは「Infusion Pump Improvement Initiative（輸液ポンプ改善イニシアチブ）」を立ち上げ、その一環として「Safety Assurance Case（安全性保証ケース）」と呼ばれる文書の提出を試験的に求めるドラフトガイダンスを発行しました。

Safety Assurance Caseは、航空宇宙分野などセーフティクリティカルなソフトウェア工学の世界で発展してきた考え方です。構造はシンプルで、「主張（Claim）」「論拠（Argument）」「証拠（Evidence）」の三層からなります（図表2）。「この機器は意図通りに安全に動作する」という主張を頂点に置き、その主張がなぜ成り立つのかを論拠として示し、その論拠を裏付ける具体的な証拠――テスト結果、リスク分析、レビュー記録など――をひも付けます。テスト結果は、この構造の中の「証拠」のひとつに過ぎません。

FDAの試験運用の結果は示唆的でした。Safety Assurance Caseを提出した企業は、審査官とのやり取りに要する日数こそ増えましたが、承認に至った件数は増加し、申請の取り下げは減少しました。全体の審査期間に大きな変化はなかったものの、審査官が「何を確認すればよいか」を素早く把握できるようになったことが推察できます。

「テスト結果を提出する」ことと「安全性を証明する」ことの違いは、ここにあります。前者は証拠の断片を渡す行為です。後者は、その証拠がなぜ主張を裏付けるのかという論理の筋道を、審査官が追える形で示す行為です。

2023年6月、FDAは医療機器ソフトウェアの市販前申請に関する新しいガイダンス「Content of Premarket Submissions for Device Software Functions」を確定させました。2005年版ガイダンスを置き換えるこの文書は、IEC 62304（医療機器ソフトウェア―ソフトウェアライフサイクルプロセス、以下IEC 62304）の枠組みとの整合性を強め、ソフトウェア要求仕様（SRS）の記述方法や、要求事項の追跡可能性（トレーサビリティ）の説明を求めています。

FDAの品質システム規則（21 CFR Part 820）の中核にあるDesign Controls（設計管理、820.30条）も、この論理を支える仕組みです。設計インプット（要求事項）が設計アウトプットにどう反映され、検証・妥当性確認によってどう確認されたかを追跡することを求めています。

このガイダンスは、トレーサビリティマトリクス（図表3）そのものの提出までは求めていません。しかし、ソフトウェア要求がどのように識別・追跡されているかという「方法論」の説明を求め、審査官はリスクコントロール手段が製品要求・ソフトウェアテスト・添付文書までどう追跡されているかを評価します。IEC 62304が要求するハザード分析・リスクコントロール・検証記録の連鎖と、この考え方は同じ土台に立っています。

トレーサビリティとは「文書同士の対応表を作る事務作業」ではありません。「なぜこの設計が、その安全要求を満たすと言えるのか」「なぜこのテストが、そのリスクコントロールの妥当性を確認したと言えるのか」という論理の骨格そのものです。証拠の構造を審査官に示すための、いわば背骨です。

日本のPMDAの審査プロセスも、本質的には同じ構造を持っています。PMDAは承認審査において、提出資料の内容が科学的・倫理的に信頼できるかを確認する「信頼性調査」と、現在の科学技術水準に基づいて品質・有効性・安全性を評価する「承認審査」を行います。信頼性調査が確認しているのは、データそのものの真正性だけでなく、そのデータが結論を導く根拠として成立しているかという点です。

FDAとPMDAでは、審査の手続きや法的根拠が異なります。510(k)の実質的同等性という考え方はFDA特有のものですし、PMDAは薬機法に基づく承認・認証の枠組みで審査を行います。しかし「テストに合格した」という事実だけでは、どちらの審査当局も納得しません。両者が共通して確認しているのは、「その証拠が、安全性・有効性という主張をどう裏付けているのか」という論理です。規制当局ごとに手続きの形は違っても、見ている視点そのものは変わりません。

「テストは通っていた」という言葉は、この連載の第1回でTherac-25の事故を振り返ったときにも登場しました。テストの合格は、安全性の証拠の一つではあっても、証明そのものではありません。規制当局が審査で見ているのは、無数のテスト結果や文書の背後にある、一つの問い――「なぜ、この結果で安全と言えるのか」――への答えです。

審査資料を書くとき、規格が要求する項目を埋めるために書くのか、それとも「なぜこの設計・このテストが患者の安全を守ると言えるのか」という論拠を、審査官に伝えるために書くのか。この違いが、RTAやAI照会という形で、審査の行方を左右しています。

次回予告

第4回は「ドキュメントは敵か味方か？」をテーマに取り上げます。医療機器QAにおける文書主義の正体と、ドキュメントが本来果たすべき役割を掘り下げます。

参考文献・規格

21 CFR Part 820.30 Design Controls（設計管理）
FDA "Content of Premarket Submissions for Device Software Functions"（2023年6月）
FDA "General Principles of Software Validation"（2002年1月）
FDA "Infusion Pumps Total Product Life Cycle" Guidance（2014年12月）／Safety Assurance Case（安全性保証ケース）
IEC 62304:2006/AMD1:2015 「医療機器ソフトウェア―ソフトウェアライフサイクルプロセス」
医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律（薬機法）

参考サイト

ポータルサイト：https://www.medicalsoftwareconsulting.com/
規格解説動画：https://www.youtube.com/@MedicalSoftwareConsulting
医療機器ソフトウェア 規制・規格 知識データベース：https://watch.medicalsoftwareconsulting.com/