FHIR接続だけでは医療AIの安全性を証明できず　病院導入で確認する6項目

医療情報交換規格「FHIR」（Fast Healthcare Interoperability Resources）は、電子的な医療情報をリソース単位で表し、システム間で受け渡すための標準だ。患者、検査、薬剤などの情報構造と交換方法をそろえる役割を持つが、記録内容の正確さや医療AIの臨床性能を認定する規格ではない。

日本の電子カルテ情報共有サービスは、国内向けFHIR実装ガイド「JP-CLINS」（Clinical Information Sharing Implementation Guide）を採用する。厚生労働省の2026年6月版技術解説書は、JP-CLINSで定めたFHIRプロファイルの制約を調べるバリデータ、システムベンダ向け接続テスト、医療機関向け運用テストを別々の工程として示している。

接続確認の後に残るのが、データ品質、外部検証、個人情報保護、院内の使い方、情報開示、更新後監視である。本稿の調査では、FHIR接続、アプリ流通、医療AIの臨床評価を一括する日本国内の単一制度を示す公的資料は確認できていない。交換基盤と医療AIの評価を分け、病院側が導入条件を積み上げる必要がある。

FHIRが確認する範囲──データの形と交換

HL7 InternationalのFHIR R5仕様は、検証対象としてデータ構造、多重度、値の型、コード体系との結びつき、制約、プロファイルを挙げる一方、検証手段が扱えるのは機械判定可能な適合性に限られ、静的な検査だけでは仕様への完全な準拠を証明できないと明記する。必須欄に値が入っていても、採血条件、単位、時刻、診断ラベルが臨床上正しいかは別の問題だ。

層	主な確認対象	その層では証明しない事項
FHIR・JP-CLINS	構造、コード、プロファイル、交換手順	元記録の正確さ、AIの性能
SMART App Launch	アプリへの権限委譲、アクセス範囲	院内の権限方針、監査、事故対応
データ品質評価	欠損、単位、時系列、コード、偏り	導入先での患者転帰
臨床評価	対象患者、比較基準、性能、人との連携	更新後も同じ性能が続く保証
運用管理	権限、ログ、監視、停止、責任分担	未検証の用途への適用

第一項目──互換性は版と実データで確かめる

「FHIR対応」という表示だけでは実装条件が足りない。FHIRのリリース、採用する実装ガイドとプロファイル、その版、拡張項目、コード体系、必須項目を特定する。院内の電子カルテ、検査、画像、部門システムからFHIRリソースへ変換する対応表には、元項目、変換規則、単位、欠損時の処理、更新責任者を残す。

接続試験では送信成功の画面に加え、元記録と受信データの一致、患者と検査のひも付け、再送時の重複、時刻とタイムゾーン、エラー処理、AI出力を電子カルテへ書き戻す際のモデルの版と生成時刻を調べる。仕様書の適合試験と、病院の実データを使う受入試験は役割が異なる。

第三者アプリの接続にSMART App Launchを使う場合も、規格が担う範囲を切り分ける。HL7のSMART App Launch 2.2.0はOAuth 2.0によるFHIRリソースへの権限委譲を定めるが、組織が誰にどの権限を与えるかという方針、利用者本人の認証、セッション管理、監査を仕様の範囲外としている。アクセストークンの発行は、AI利用の妥当性や院内の安全管理を示さない。

第二項目──データ品質を施設ごとに測る

交換形式が同じでも、入力の意味はそろわない場合がある。検査値には単位や採取条件の差、診断名には確定と疑いの混在、時系列には入力日と実施日のずれが生じる。欠損率や外れ値だけを集計せず、AIの使用目的に必要な項目が正しい患者、正しい時点、正しい単位で届くかを調べる。

Lewisらが2023年に公表した系統的レビューは電子カルテのデータ品質を扱う103報を分析し、完全性、正確性、一致性、妥当性、最新性を主な評価軸として整理した。共通する型が繰り返し使われる一方、評価設計は主に研究ごとに組まれていた。FHIR適合を品質評価の代用にはできない。

病院側が求める資料には、項目別の欠損率、施設別の単位とコード、時間情報の定義、正解ラベルの作成方法、訂正履歴、対象患者の分布、変換前後の照合結果が入る。学習データと導入施設の違いが大きい項目は、使用制限か追加検証の対象になる。

第三項目──外部検証は患者、施設、取得経路を分ける

開発施設のデータを無作為に分けたテストだけでは、別の病院での性能を十分に示せない場合がある。患者の重複、施設固有の機器、検査手順、診療方針、ラベル作成者が訓練用と評価用のデータにまたがると、見かけの成績が高くなる。

厚生労働省・PMDAの2024年ガイダンスは、海外で検証したプログラム医療機器を日本へ導入する際、使用言語、医療環境、生活様式などの外的要因を検討し、入力情報や診断基準、学習データのアノテーションの差が出力へ及ぼす影響を評価する必要があるとする。本稿ではこの考え方を、装置や記録方法が異なる国内施設間の検証にも当てはめた。

国際医療機器規制当局フォーラム（IMDRF）が2025年に最終化した優良機械学習実務の10原則は、対象患者と使用環境を代表するデータを用い、患者、施設、取得経路に由来する訓練用とテスト用データの依存を避け、リスクに応じた外部検証を行うよう求める。導入候補の病院では全体指標に加え、年齢層、性別、疾患群、装置、診療科、施設ごとの成績と信頼区間を確認する。

第四項目──利用目的、権限、委託を先に決める

診療のために集めた情報が交換可能になっても、別目的のAI学習や製品改善へ無条件で回せるわけではない。誰のデータを、何の用途で、どの項目まで、誰が閲覧・取得し、どこへ保存し、いつ削除するかを用途ごとに分ける。

個人情報保護委員会と厚生労働省の2026年4月改正版ガイダンスは、医療・介護事業者に利用目的をできる限り特定するよう求め、個人データの漏えい、滅失、毀損を防ぐ安全管理措置と、従業者・委託先への必要かつ適切な監督を定めている。AI事業者が委託先か第三者か、再委託があるか、国外で取り扱うかによって確認事項は変わる。

厚生労働省は2026年6月に医療情報システムの安全管理ガイドラインを第7.0版へ改め、経営管理、企画管理、システム運用、保守委託の各編と、医療機関・薬局向けサイバーセキュリティ対策チェックリストを公表した。FHIRゲートウェイやAIサーバーを追加する場合も、アカウント、ログ、バックアップ、障害連絡、事業継続、契約終了時のデータ返却・消去を既存の安全管理へ組み込む。

第五項目──説明画面より臨床の透明性を見る

特徴量の順位やヒートマップを表示する機能だけで、医療者が安全に判断できるとは限らない。必要なのは、医療上の使用目的、対象患者、入力と出力、評価データ、性能、既知の失敗条件、人が確認する範囲、更新時の通知を一続きで追える情報である。

米食品医薬品局、Health Canada、英医薬品・医療製品規制庁が2024年に公表した共同原則は、説明可能性を透明性の一部と位置づけ、使用目的、対象集団、訓練・評価データ、臨床研究、性能、偏り、情報の空白、院内の使い方、更新後監視を利用者へ伝える項目として挙げる。説明の見栄えではなく、誰がどの時点で何を知り、AI出力をどう覆し、問題をどこへ報告するかが評価対象になる。

画面評価では、正常時の平均操作時間に加え、入力不足、信頼度の低い出力、通信断、対象外患者、誤警報が続く場面を試す。AIを使わない通常手順へ戻す条件と、医療者の判断を記録する方法も受入試験へ入れる。

第六項目──更新後の性能と停止条件を監視する

導入時のモデルが固定されるのか、事業者が再学習するのかで契約と監視は変わる。モデル、前処理、コード表、プロファイル、参照データの版を記録し、更新前後の比較、性能低下を判定する指標、警告と停止の基準、旧版へ戻す手順を決める。

IMDRFの10原則は、実運用中の性能を継続監視し、再学習に伴う過学習、意図しない偏り、データの変化による性能低下を管理するよう求める。施設別の入力分布、欠損、エラー、偽陽性・偽陰性、医療者による修正、処理遅延を時系列で追い、変化がデータ変換、診療手順、モデル更新のどこから生じたかを切り分ける。

厚生労働省・PMDAのガイダンスは、疾病の診断・治療・予防を目的とし、機能障害が生命・健康へ影響するおそれがほとんどないものを除くプログラムを「プログラム医療機器」と定義し、将来の改良計画を事前に確認する変更計画確認手続制度「IDATEN」も説明している。医療機器に該当する製品では、病院の更新手順と、承認・認証された使用目的や確認済みの変更計画との対応を製品ごとに調べる。

導入前に提出を求める6項目

1. 相互運用性：FHIRのリリース、実装ガイド、プロファイル、拡張、コード、対応表、バリデータと接続・運用テストの結果。
2. データ品質：施設別の欠損、単位、時刻、コード、正解ラベル、対象患者の分布、変換前後の照合結果。
3. 外部検証：訓練用と独立した患者・施設・取得経路、全体と集団別の性能、信頼区間、対象外条件。
4. 臨床ワークフロー：入力、出力、医療者の確認、上書き、警報、通信断、停止、通常手順への切り戻し。
5. 個人情報と安全管理：利用目的、権限、保存期間、ログ、委託・再委託、国外取扱い、事故連絡、データ返却・消去。
6. 監視と問責：モデルとデータ処理の版、更新通知、性能低下の指標、停止基準、規制上の変更手続き、病院と事業者の責任分担。

国内で公表を待つ情報

厚生労働省は2026年3月、中小病院と医科診療所向けの電子カルテ・レセプトコンピュータ標準仕様1.0版を公表したが、認証制度の詳細は今後掲載するとしている。電子カルテ情報共有サービス、電子カルテ標準、医療機器プログラムの薬事手続き、医療情報システムの安全管理は別の資料と制度で整備されている。FHIR接続、アプリ流通、医療AIの臨床評価を一括する単一制度を示す公的資料は、本稿の執筆時点で確認できていない。

確認できていないのは、制度や導入例が存在しないという意味ではない。公開情報からは、FHIRを介して複数施設へ展開した各医療AIについて、患者転帰、医療者の負担、費用、施設別性能、更新後の変化を同じ定義で横断比較できないという情報上の限界である。今後は、対象製品と版、認められた用途、施設別の外部検証、導入後監視、事故と停止の公表範囲が検証点になる。

よくある質問

FHIRに準拠すれば電子カルテをそのままAI学習へ使えるのか
そのままでは使えない。FHIRは情報の構造と交換方法を定める。利用目的と権限、記録の正確さ、欠損、単位、時系列、正解ラベル、患者集団の偏りを別に調べる。

SMART App Launchがあれば院内の権限管理は足りるのか
足りない。SMART App Launchは既存の権限を第三者アプリへ委譲する手順を定める。誰に元の権限を与えるか、利用者認証、監査、事故対応は病院側の管理に残る。

導入判断で最初に求める資料は何か
製品の使用目的と版、FHIRの実装条件と対応表、外部検証の対象施設・患者、利用目的と権限、院内の確認・停止手順、更新後監視を一組で求める。六つが同じ製品版と使用目的を指しているかを照合する。