医療データをAIにつなぐ「FHIR」　日本の共有基盤と実装の壁

FHIR（Fast Healthcare Interoperability Resources）は、電子カルテの情報をシステム間で交換するためにHL7が策定した規格だ。患者、検査結果、処方、アレルギーといった情報をリソース（Resource）という単位で表し、用途に応じて組み合わせる。AIにとっての意味は、病院ごとに異なる画面や文書をそのまま読むのではなく、項目とコードが明示されたデータを受け取る入り口が整うことにある。

FHIRの仕組み──病歴を共通の部品に分ける

HL7の仕様書は、交換する内容をリソースで定義し、個別の用途では複数のリソースを参照関係で組み合わせる設計を示している。患者の基本情報はPatient、検査値はObservation、処方はMedicationRequestというように役割を分ける。リソースには機械処理向けの構造化データと人が読める記述があり、XMLやJSONで表現される。RESTful APIを使えば、システムは患者単位や項目単位で検索、取得、更新を実行できる。

共通規格が必要なのは、同じ血液検査や薬剤でも、電子カルテの項目名、単位、コードが施設や製品によってそろわないためだ。FHIRは「検査結果」というリソースを用意するが、中身が正しいことまでは保証しない。元データの欠損、単位の誤り、ローカルコードから標準コードへの対応ミスは、変換工程で別に検証する必要がある。

自由記述を読むAIと、構造化データを扱うAI

大規模言語モデル（Large Language Model、LLM）は文章を処理できても、自由記述の診療録から正確な医療コードを取り出せるとは限らない。入院記録を使って六つのLLMを人間のコーダーと比較した研究では、ICD-10-CMコードの一致率はGPT-4が15.2％で最も高く、モデルが未確定の診断や過度に広いコードまで抽出する問題も確認された。研究対象や評価方法に依存する数字だが、読みやすい文章を返す能力と正確な符号化は別だと分かる。

構造化を組み込んだ試みもある。FHIRと腫瘍領域の共通データ要素mCODEを使い、自由記述から標準化プロファイルを生成したプレプリントは、SNOMED CTで87％、LOINCで90％、RxNormで84％の精度を報告した。ただし、この研究は腫瘍の臨床試験マッチングを想定した独自の枠組みを評価しており、前段のICDコード抽出研究とはデータ、モデル、正解条件が違う。数字を横に並べて「FHIRで精度が何ポイント上がる」と結論づける根拠にはならない。

FHIRがAIにもたらす利点は、精度を自動的に上げることではなく、入力の意味と形式を検査しやすくする点にある。どのResourceのどの項目を参照したかを追えれば、自由記述を丸ごと渡す場合よりも誤りの場所を切り分けやすい。モデルの性能、標準コードへの変換品質、データの欠損は、それぞれ別に測る必要がある。

日本では電子カルテ情報共有サービスに採用

日本でFHIRの実装を進める中心施策が、厚生労働省の電子カルテ情報共有サービスだ。厚生労働省はシステム事業者向けに技術解説書、FHIR記述データの手本、日本向け臨床情報プロファイルJP-CLINSへの導線を公開している。このサービスは全国医療情報プラットフォームの一部として整備されている。

同省の説明では、電子カルテ情報共有サービスは診療情報提供書、健診結果、傷病名、感染症、薬剤アレルギー、検査などを全国の医療機関や本人が共有・閲覧する仕組みである。医科診療所向けの標準型電子カルテも2026年度中の完成を目標に開発され、共有サービスから診療情報提供書や検査データを閲覧する機能が予定されている。

ここで整うのは診療情報を運ぶ基盤であり、AI向けの学習データベースそのものではない。医療機関をまたぐAI開発では、データを中央に集めずモデルの更新を共有する連合学習も選択肢になるが、FHIRと役割は異なる。FHIRはデータの意味と交換形式をそろえ、連合学習はデータを置いたまま共同学習する方法を扱う。

標準化しても残る権限と監査

医療データは、接続できれば自由に使える情報ではない。個人情報保護委員会と厚生労働省のガイダンスは、診療記録にある病歴、診療・調剤情報、健康診断の結果などを要配慮個人情報とし、取得や第三者提供には原則として本人の同意が必要だと示している。FHIRで形式をそろえても、利用目的や提供先をめぐる法的な判断は消えない。

技術仕様にも境界がある。HL7はFHIR自体が特定のセキュリティ実装を必須にするものではないと説明し、認証と認可にはOAuth、記録にはAuditEventリソースの利用を挙げている。SMART App LaunchはOAuth 2.0を基礎に、利用者向けアプリと無人のバックエンドサービスについて、リソースの種類や読み書きの範囲をスコープ（scope）で制御する方式を定める。実際に誰へどの範囲を与え、異常な連続照会をどう検知し、ログを誰が調べるかは運用側の責任になる。

AIエージェントをFHIRサーバーへ接続する場合、この設計はさらに重くなる。人が画面を操作する速度を前提にした権限でも、自動処理なら短時間に多数の患者情報へ到達しうる。読み取り専用のスコープ、患者や期間による絞り込み、操作回数の制限、監査ログの警告条件を先に決めなければ、標準APIはリスクを広げる経路にもなる。

日本ではFHIRを使う共有基盤の仕様と導入資料は公開されている。一方、その基盤につないだ医療AIの精度や業務効果を全国規模で検証した公的資料は、本稿の執筆時点で確認できていない。実装を評価するときは、FHIR対応の有無ではなく、標準コードへの変換精度、欠損率、権限の粒度、監査可能性を個別に見る必要がある。

よくある質問

FHIRを導入すれば、AIの医療コード判定は正確になるのか
導入だけでは決まらない。FHIRは入力項目の意味と形式をそろえるが、元データの誤りや欠損、ローカルコードの変換ミス、モデル自体の誤りは残る。構造化した入力と自由記述の差を測るには、同じデータと同じ評価条件で比較する必要がある。

FHIRは従来の電子カルテをすべて置き換えるのか
置き換えを必須とする規格ではない。既存の電子カルテが保持する情報をResourceへ変換し、別のシステムと交換する使い方が中心になる。日本の電子カルテ情報共有サービスも、事業者向けにFHIR記述と実装の手順を示している。

FHIRなら患者情報の安全も保証されるのか
保証されない。FHIRは認証、認可、監査に使う仕組みを用意しているが、誰にどのデータの読み書きを許すかは導入側が決める。OAuthのスコープ、AuditEventリソース、組織内の監査手順を組み合わせて初めてアクセス管理が成り立つ。