電子カルテを医療AIにつなぐ四つの関門　FHIR対応後に残る検証

電子健康記録（Electronic Health Record、EHR）は、診断、検査結果、処方、医師の記録などを時間軸に沿って扱う患者中心の電子記録である。人工知能（Artificial Intelligence、AI）へ渡すデータは、そこから患者、時点、単位、出所を保ったまま切り出す必要がある。院内に電子カルテがあっても、そのままAIの入力が完成するわけではない。

米国医療IT調整室（Office of the National Coordinator for Health Information Technology、ONC）は、EHRを複数の医療機関や診療場面にまたがる長期記録とし、電子診療録（Electronic Medical Record、EMR）は主に単一の医療提供者や施設内で扱う記録と説明している。本稿ではこの区分を説明の枠組みに使う。日本の制度資料では「電子カルテ」という呼称が中心となるため、調達時は名称ではなく、院内に限るのか、他の医療機関の情報まで扱うのかを仕様で確かめる必要がある。

AIが読む対象は一枚の病歴ではない。患者基本情報、検体検査、処方、画像、自由記載、更新履歴は別のシステムや表に分かれ、同じ診断名でも問題リスト、受診時の診断、請求用コードでは意味が異なる。接続試験でデータが届いた事実と、その入力を臨床上の判断に使える事実は切り分けなければならない。

EHRと電子カルテ──日本では範囲を仕様で切る

厚生労働省は電子カルテ情報共有サービスを全国医療情報プラットフォームの一部とし、診療情報提供書の電子共有、健診結果と臨床情報の閲覧、本人向け患者サマリーの閲覧という四つのサービスを示している。単一施設の電子カルテを越えて情報を扱う点では、EHRが指す範囲に近い。

ただし、現行資料は全国で完成済みの仕組みを示していない。厚生労働省の2026年6月版技術解説書v2.1.0は、2文書・5情報と患者サマリーに日本向け臨床情報共有実装ガイドJP-CLINS（Clinical Information Sharing Implementation Guide）を使い、同年9月にプロファイル1.13.0をリリースする予定を示す一方、内容はモデル事業向けであり、次版が出るまでモデル事業外での実装・導入を控えるよう記している。公開資料が示すのは共有基盤の設計と検証中の仕様であり、FHIRに接続した医療AIの全国認証ではない。

FHIRがそろえるのは交換の形

医療情報交換規格FHIR（Fast Healthcare Interoperability Resources）は、患者、観察値、処方などをリソース（Resource）という単位で表し、参照によって関係を組み立てる。HL7のFHIR R4公式仕様は、リソースを交換可能な情報の基本単位とし、用途別のプロファイル（Profile）で項目の必須性、用語への結び付け、データ型、拡張を絞り込む構造を示している。FHIR対応という表示だけでは、どの版とプロファイルを使い、どのリソースと項目を実装したかまでは分からない。

日本の技術解説書が標準マスタ、未標準化コード、プロファイルの版、受信時のバリデーションを別々に定めているのも、この差があるためだ。同書は、指定単位へ変換しにくい検査試薬や機器があるとして、登録可能な検査単位を広げる方針へ改めた。形式が同じでも、検査項目、単位、測定法、基準範囲の意味が自動的に一致するわけではない。

権限管理もFHIRの外側に残る。FHIR R4のREST方式のAPI（Application Programming Interface）仕様は、API自体が認証、認可、監査情報の収集を直接扱わないと明記している。FHIRは交換形式と操作を共通化する規格であり、誰がどの患者の何を読めるか、操作をどの期間保存するかは導入側の設計になる。

四つの関門──接続試験と導入判断を分ける

第一関門：入力の出所と意味

最初に固定するのは、AIが使う項目と取得元である。患者識別子、観察時点、記録時点、単位、コード体系、検体、データ作成者、更新版、欠損時の扱いを項目ごとに対応表へ落とす。同じ血圧値でも測定日時や体位が欠ければ比較の意味が変わり、同じ診断コードでも登録目的が異なれば正解ラベルとしての扱いは変わる。

検収では、サンプルデータがプロファイルを通るかに加え、電子カルテ画面の元記録からAI入力、AI出力から表示画面までを双方向にたどる。変換前の値、変換規則、エラー、再送、版の履歴を残せなければ、誤りが元データ、変換、モデルのどこで生じたかを分離できない。

第二関門：利用目的、権限、監査

個人情報保護委員会の医療・介護ガイダンスは、診療録に記載された病歴、診療情報、調剤情報、健診結果などを要配慮個人情報に含め、取得と個人データの第三者提供には原則として本人同意が要ると説明している。法定の例外や委託に当たる取扱いもあるため、「医療目的」「院内AI」という名前だけで適法性を決められない。利用目的、取扱者、システム提供事業者が参照する範囲、保存、再利用、返却・消去をデータフローと契約の双方で確定する必要がある。

厚生労働省の医療情報システム安全管理ガイドライン第7.0版は、利用者の識別・認証、規程に基づくアクセス権限、ログの取得とレビューを求め、運用を委託する場合は医療機関と事業者の業務、役割、責任を事前に取り決める考え方を示している。APIが応答したという接続結果と、正当な利用者だけが必要な範囲へアクセスし、後から追跡できるという監査結果は別の記録になる。

第三関門：臨床画面と人の確認

AI出力をどの画面に置き、誰が確認し、採用、修正、見送りをどう記録するかは接続仕様の一部である。入力不足や処理失敗を通常の陰性結果と同じ表示にせず、元の記録、対象外の条件、不確実性、モデル版を確認できる画面が要る。AIが停止した場合に既存の手順へ戻る経路も、稼働前の試験対象になる。

医療機器に当たるAIでは、接続後の臨床評価も製品ライフサイクルの一部になる。国際医療機器規制当局フォーラム（International Medical Device Regulators Forum、IMDRF）が2025年に最終化した優良機械学習実務（Good Machine Learning Practice、GMLP）の10原則は、AI単体ではなく想定する臨床環境で人とAIを組み合わせた性能を評価し、訓練データから独立した条件で試験し、導入後も性能と再学習のリスクを監視するよう求めている。接続試験の成功は、この臨床評価を代替しない。

第四関門：製品用途と責任

EHRとつながるソフトが一律に医療機器になるわけではない。医薬品医療機器総合機構（Pharmaceuticals and Medical Devices Agency、PMDA）は、医療機器としての目的があり、意図どおりに動かない場合に患者や利用者の生命・健康へ影響するおそれがあるプログラムを、健康への影響がほとんどないものを除き、薬機法の規制対象となるプログラム医療機器（Software as a Medical Device、SaMD）と説明している。判断の入口はAIやFHIRという技術名ではなく、使用目的と不具合時の影響である。

病歴の検索、文書の下書き、事務上の通知と、診断候補、分流、治療方針の提示では、出力が診療へ及ぼす影響が異なる。導入文書には対象患者と利用者、入力、出力、対象外条件、人が確定する範囲、障害時の代替手順、更新と停止の権限を記録する。承認や認証が必要な製品では、その範囲と院内の使い方を一致させる必要がある。

日本で確認できること、まだ結べないこと

日本では、電子カルテ情報共有サービスの設計、医療情報システムの安全管理、プログラム医療機器の該当性について公的資料を確認できる。一方、共有サービスの2026年6月版技術解説書はモデル事業向けで、全国運用用の仕様確定前にある。共有基盤の整備予定を、医療AIの接続や臨床検証が全国で完了した証拠として扱えない。

電子カルテ連携AIについて、製品別の導入施設数、各施設の項目対応、院内検証結果、導入後の性能を全国横断で結び付けた公的資料は、本稿執筆時点で確認できていない。導入例や院内研究が存在しないという意味ではない。公開情報からは、どの製品がどの電子カルテ項目を使い、どの患者群で検証され、現場でどの性能を保っているかを一続きに比較できないという情報上の限界である。

よくある質問

EHRと電子カルテは同じ意味か
EHRは複数の医療機関や診療場面をまたぐ長期記録を指す説明が一般的で、EMRは主に単一施設内の記録を指す。日本では制度名や製品名に「電子カルテ」が広く使われるため、名称から範囲を決めず、共有先と収録項目を仕様で確認する。

FHIR対応なら医療AIは電子カルテを読めるのか
FHIR対応だけでは決まらない。使う版とプロファイル、実装するリソース、施設内コードとの対応、単位、時点、欠損、権限、監査を項目単位で検収する必要がある。FHIRは交換の枠組みであり、元データの正しさや臨床上の意味を保証しない。

EHRに接続するAIはすべてプログラム医療機器になるのか
一律ではない。医療機器としての目的と、不具合が生命・健康へ及ぼすおそれを基に該当性を判断する。検索や事務支援と、診断・治療に影響する出力では規制上の扱いが変わりうる。