厚生労働省は2026年6月26日、医科診療所と中小病院向けクラウド電子カルテの認証制度案を示し、要綱を同年9月ごろに公表する計画を明らかにした。認証は製品ごとに行い、標準仕様への準拠、医療DXサービスとの接続、稼働実績、バックアップ、セキュリティなどを審査する。初回認証は2026年度内、認証製品の提供環境は2027年度から整える方針だ。

この案が測るのは、電子カルテ製品の接続性と運用基盤の品質である。診断支援AIの臨床性能、患者集団ごとの偏り、薬機法上の承認・認証は、公開された評価項目に含まれていない。医療機関が医療AIを組み込む際は、電子カルテ認証を入口としつつ、別の審査と院内検証を重ねる必要がある。

認証制度案──稼働率99.9％と年1回の検査

認証の申請者は、医科診療所または中小病院向け電子カルテの提供事業者を想定する。機能面では、オンライン資格確認、電子処方箋、電子カルテ情報共有サービス、クラウド型レセプトコンピュータとの接続可否を調べる。非機能面では、直近1年間の稼働率99.9％以上を原則とし、届かない場合は障害分析の提出を求める案だ。

セキュリティではペネトレーションテストと脆弱性診断を原則年1回以上とし、実施を見送る場合はリスク評価にもとづく理由の提示を求める。データ保管、バックアップ、単一コードベースによる提供、価格の公開も評価案に入った。ただし、99.9％は認証申請前の稼働実績に関する要件案であり、将来の無停止を保証するサービス水準ではない。算定から除く停止時間や事業者との責任分界は、最終要綱と契約で確かめる項目になる。

制度はまだ始まっていない。厚生労働省は要綱公表後に申請を受け付け、審査を経て2026年度内の認証を目指すとしている。申請時に必要な稼働医療機関数、技術審査の方法、製品更新後の扱いは検討が残る。

FHIRはデータ交換の規格、AIの性能証明ではない

医療情報交換規格「FHIR」（Fast Healthcare Interoperability Resources）は、電子的な医療情報をリソース単位で表し、システム間で交換するための規格だ。HL7 InternationalのFHIR R4仕様は、機械処理に使う医療データには構造化と標準化が要り、リソースを用途に応じたプロファイルで制約すると説明している。

日本の電子カルテ情報共有サービスは、FHIR実装ガイド「JP-CLINS」で文書や臨床情報の記述条件を定める。厚生労働省の2026年6月版技術解説書は、JP-CLINSに沿うFHIRデータを開発環境で検査するバリデータと、本サービスへの接続テストを関連資料に挙げている。一方、記載内容は最終確定前で、冬ごろの次版が出るまではモデル事業以外で実装・導入を控えるよう求めている。FHIRの国内運用自体が、検証を経て仕様を固めている段階にある。

FHIRの公式仕様で検証対象となるのは、データ構造、多重度、値の型、コード体系との結びつき、制約、プロファイルなどである。HL7は、こうした方法で確認できるのは機械判定可能な適合性に限られ、静的な検査だけで仕様への完全な適合を証明するには足りないとしている。必須欄に値が入っていても、その値が臨床上正しいか、学習対象の患者集団を十分に表すかまでは判定しない。FHIR適合とAIの精度は別の評価である。

SMART App Launchはアプリの認可を扱う

FHIRアプリ起動・認可仕様（SMART App Launch）は、第三者アプリが電子カルテのFHIRリソースへ接続する手順を定める。HL7の2.2.0版はOAuth 2.0にもとづき、アプリが認可コードとアクセストークンを取得し、許可された範囲のFHIRリソースへアクセスする流れを規定する。ただし、組織が誰にどの権限を与えるかという方針、利用者本人の認証、セッション管理、監査は仕様の範囲外である。

FHIRがデータの形をそろえ、SMART App Launchがアプリへの権限委譲をそろえても、病院側にはアカウント管理、ログ監視、インシデント対応、委託先管理が残る。認可トークンの取得に成功した事実は、AIの出力が正しいことも、製品が薬機法上の手続きを終えたことも示さない。

層 主に確認するもの 別途確認が要るもの
FHIR データ構造、コード、プロファイル 記録内容の正確さ、AIの臨床性能
SMART App Launch アプリの認可委譲、トークン、アクセス範囲 院内の権限方針、監査、事故対応
クラウド電子カルテ認証 標準仕様、接続、稼働実績、セキュリティ 医療AI単体の有効性、安全性、公平性
薬機法上の承認・認証 製品の使用目的、性能、有効性、安全性 導入施設のデータ品質、院内運用、退場手順

電子カルテ認証と薬機法上の承認・認証は別

「認証」という同じ語でも、制度の根拠と対象は異なる。厚生労働省は、疾病の診断・治療など医療機器としての目的があり、意図どおりに動かない場合に患者の生命・健康へ影響するおそれがある単体プログラムを、薬機法上の医療機器プログラムとして規制する。AIという技術名だけで該当性は決まらず、表示された使用目的とリスクで判断される。

薬機法上の第三者認証は、厚生労働大臣が基準を定めて指定した医療機器を、登録認証機関が品目ごとに審査する制度である。基準の対象外となる医療機器は、リスク分類や品目に応じて大臣承認など別の手続きをたどる。今回検討されているクラウド電子カルテ認証は、標準仕様に合う電子カルテ製品の普及を目的とした仕組みであり、この薬事手続きを置き換えない。

更新を前提とする医療AIでは、初回の手続き後も変更範囲の管理が要る。厚生労働省とPMDAのプログラム医療機器ガイダンス第二版は、将来の改良が見込まれる承認済み医療機器について、変更計画をあらかじめ確認するIDATENを説明し、申請前にPMDAの相談を受ける手順を示している。モデル更新が承認・認証された範囲に収まるかは、製品側が適用される変更手続きに照らして確認する事項だ。

導入前に確かめる5関門

  1. データ標準：FHIRのリリース、JP-CLINSの版、コード体系、必須項目を確認する。バリデータの通過後も、欠損、単位、コード変換、元記録との一致を標本で調べる。
  2. 臨床評価：AIの使用目的、評価施設、患者集団、使用機器、比較基準、主要指標、患者集団別の成績を読む。自院の患者構成や業務フローと異なる条件は、そのまま当てはめない。
  3. 制度上の位置づけ：電子カルテ認証の対象製品と版を確かめ、AIについては医療機器該当性、承認・認証の有無、認められた使用目的を分けて記録する。
  4. 導入後の監視：モデルとデータ処理の版、更新通知、性能指標、偽陽性・偽陰性、利用停止の基準、医療者による確認、切り戻し手順を決める。更新前後の比較結果を保存する。
  5. 責任と退場：セキュリティ更新、事故連絡、ログ保全、バックアップ、再委託、データ出力、契約終了時の消去と移行を契約に置く。病院と事業者の担当範囲を障害の種類ごとに分ける。

厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン」を第7.0版へ改め、経営管理、企画管理、システム運用、保守委託を分冊化し、医療機関・薬局向けのサイバーセキュリティ確認表も公表した。電子カルテ認証案も同ガイドラインへの準拠を求める。FHIRやSMART App Launchを採用しても、この運用管理は省けない。

制度開始後に検証すべき効果

認証制度の要綱が公表された後は、対象製品、適用する標準仕様の版、審査結果の公開範囲、更新時の再審査、認証の有効期間を確認する必要がある。現段階の説明では、稼働実績に必要な医療機関数や技術審査の具体的な手順が決まっていない。

電子カルテ情報共有サービスの技術仕様も、モデル事業の結果を反映して改訂される。認証製品が増えた後に見るべき指標は、医療機関の接続工数、障害件数、復旧時間、セキュリティ更新、データ変換エラー、契約終了時の移行実績だ。医療AIを載せる場合は、これらに臨床性能の変化、医療者による確認の発生率、モデル更新後の再検証を加える。

電子カルテの標準仕様準拠と、医療AIの臨床性能、公平性、モデル更新を一括して判定する日本の公的認証制度は、本稿の執筆時点で確認できていない。新しいクラウド電子カルテ認証は共通の技術基盤を選ぶ助けにはなるが、医療AIの導入判断を一度の認証で終わらせる制度ではない。

よくある質問

FHIRに準拠すれば、医療AIの精度まで保証されるのか
保証されない。FHIRはデータの構造や交換方法を定める。元データの正確さ、患者集団の代表性、AIの臨床性能は別の検証対象だ。

クラウド電子カルテ認証は、薬機法上の認証と同じか
異なる。前者は厚生労働省が検討中の電子カルテ標準仕様への適合制度で、後者は指定された医療機器を登録認証機関が品目ごとに審査する薬事制度だ。

認証製品なら病院側の検証は不要か
不要にはならない。最終要綱で認証範囲を確認した上で、院内のデータ品質、アクセス権、臨床運用、障害対応、契約終了時の移行を検証する作業が残る。