openFDA Regulatory Metadata

openFDA MCP

openFDA API を通じて、FDA の規制メタデータ（医薬品、生物製剤、医療機器）を公開する MCP サーバーです。

Black Swan Causal Labs が、リアルワールドエビデンス（RWE）症例一覧の識別子解決レイヤーとして構築しました。FDA の申請番号または製品名から、信頼できる規制メタデータを特定します。

このツールの目的

openFDA MCP サーバーはほかにもあり、より幅広い機能を備えたものも複数あります。このサーバーは意図的に対象を絞っています。特定の公開済み RWE データセットに含まれる申請番号を解決したツールであり、そのデータセットが使用したツールを明示できるようにするために存在します。

これは、思われている以上に重要です。BLA 125123/2058 が特定の製品に解決されるか、あるいは DEN160026 が特定の医療機器クラスに解決されるかは、ソフトウェアによる判断です。別のラッパーを使えば、異なる症例一覧が得られる可能性があります。「openFDA を使用した」だけでは方法の記述として不十分ですが、**「openfda-mcp v0.1.0」**なら十分です。研究で使用する場合は、バージョンを固定してください。

一般的な openFDA クライアントに対する実用上の強みは、医療機器関連の機能です。CDRH の申請番号をリスククラスに解決するには、番号 → 製品コード → 分類という 3 段階の処理が必要で、見落としやすい落とし穴が 2 つあります。このサーバーはその両方に対応しています。

ツール

医薬品・生物製剤（/drug/* — CDER、CBER）

ツール	目的
search_drug_label	SPL ラベルのテキストを検索します。セクションを指定して絞り込むこともできます
lookup_drugsfda_application	NDA/BLA/ANDA 番号に対応する Drugs@FDA のレコードを検索します
resolve_drug_to_application	ブランド名または一般名 → 申請番号
screen_for_rwe_signals	試験的。 ラベルを一括検索して RWE のシグナルを探します

医療機器（/device/* — CDRH）

ツール	目的
lookup_device_submission	K / DEN / P / H 番号 → 医療機器レコード
classify_device_product_code	製品コード → 医療機器クラス + 専門分野
validate_device_application	完全な処理チェーン：番号 → クラス、専門分野、カテゴリー

インストール

pip install openfda-mcp

MCP クライアントの設定に追加します。

{
  "mcpServers": {
    "openfda": {
      "command": "openfda-mcp",
      "env": { "OPENFDA_API_KEY": "${OPENFDA_API_KEY:-}" }
    }
  }
}

API キーは任意です。 API キーがなくても、openFDA は 1 分あたり 40 件、1 日あたり 1,000 件のリクエストを許可しており、対話的な利用には十分です。無料の API キーを取得すると、上限が 1 分あたり 240 件、1 日あたり 120,000 件に引き上げられます。一括検索を行うなら取得する価値があります。

知っておくべき 2 つの知見

どちらも実証的に確認されたもので、FDA のドキュメントからはすぐに分かりません。

De Novo の認可情報は 510(k) エンドポイントに格納されています。 DEN###### 番号は /device/510k の k_number フィールドに格納されています。De Novo 専用のエンドポイントはありません。専用のものを探すと、De Novo 番号は解決できないという誤った結論に至ります。実際には解決できます。

HDE 番号は openFDA にまったく含まれていません。 510(k) エンドポイントにも PMA エンドポイントにも H###### は含まれていないため、製品コード、したがって分類も取得できません。それでも、このサーバーは規制上の推定に基づき、HDE の device_class として "III" を報告します。HDE は定義上、それ以外の場合には PMA が必要となる医療機器のための申請経路だからです。medical_specialty は実際に取得できないため null のままで、device_class_source にどちらのケースかが示されます。

一時的な障害は決して握りつぶされません

実際にデータが存在しない場合と、リクエストが失敗した場合は別のものであり、このパッケージでは明確に区別しています。

• 見つからない場合（HTTP 404、または結果なしの 200）→ None を返します。安全にキャッシュできます
• 一時的な障害（タイムアウト、接続エラー、429、5xx）→ バックオフを伴う再試行の後、OpenFDATransientError を送出します。決してキャッシュしないでください
• 拒否されたリクエスト（その他の 4xx）→ OpenFDARequestError を送出します

これは実際にあった不具合への直接的な対応です。以前のバージョンではあらゆる例外を握りつぶして None を返していたため、ある申請番号の読み取りタイムアウトが実際にデータが存在しないケースとしてキャッシュされ、そのレコードの 2 つのフィールドが何週間も気づかれないまま空欄になっていました。キャッシュされた障害は実際にデータが存在しない場合と区別できないため、気づかれないデータ損失の中でも最悪のものです。

screen_for_rwe_signals について

これは未検証です。探索的なスイープには正解を判定するオラクルがなく、有力な候補を除くと、結果の大半は無関係な意味で「registry」をラベルに含むアプリケーションが占めます。出力は人間がレビューする候補として扱ってください。調査結果や報告する件数として扱ってはいけません。既知の事例を含むホールドアウトセットに対する再現率の確立は、今後の課題です。

開発

pip install -e ".[dev]"
pytest              # unit tests, offline
pytest -m live      # live checks against api.fda.gov

ライブテストでは、既知の正常なフィクスチャ（K203571 → クラス II 眼科、DEN160026 → クラス II 免疫学、BLA761180 → LEO Pharma）に対してアサーションを行います。そのため、FDA 側の変更は、誤ったデータが気付かれないまま使われるのではなく、テストの失敗として表面化します。

ライセンス

MIT