ChatGPT が Epic の電子カルテと公的医療データにつながった — 個人アカウントでは EHR 連携は使えない

要約

2026-09-01、OpenAI が ChatGPT for Healthcare 向けに2つの連携を発表しました。Epic の電子カルテ（EHR）連携と、Healthcare Public Data プラグインです。

1つ目、Epic 連携から説明します。

医療機関は Epic 環境を ChatGPT へ接続できるようになりました。 臨床医は、診察記録・検査結果・処方・専門医のドキュメントを1つずつ探し回るかわりに、ChatGPT 上で患者履歴の把握、変化の特定、診察準備を行えます。

さらに、対応するデプロイでは ChatGPT を EHR のレイアウト内へ直接組み込めます。 患者チャートを離れずに AI 支援のワークフローを回せる、という形です。公式は「既存の EHR ワークフローを補完する設計」と説明しています。

アクセスは read-only です。 ChatGPT がカルテへ書き戻すことはありません。

2つ目は、Healthcare Public Data プラグインです。

9つの公式な公開医療データソースへの構造化アクセスを、1つのプラグインにまとめたものです。ClinicalTrials.gov、CMS Coverage、RxNorm、DailyMed、PubMed などが含まれます。

ポイントは「構造化アクセス」という点です。 レコード・フィールド・識別子・バージョンの単位で扱えるため、治験の適格基準、医薬品の識別子、保険適用ポリシーのバージョン、医療提供者のレコードといった精密な情報を、ソースごとに検索し直さずに比較・検証できます。

同日の ChatGPT Release Notes（# September 1, 2026）にも掲載されました。 こちらは米国の対象 ChatGPT for Clinicians ユーザー向けの記述で、Plugin directory からインストールして使う手順が書かれています。

Release Notes には重要な注意が明記されています。 「これらのアプリは read-only で、患者チャートにはアクセスしません。公開ソースへ送る検索に、保護対象保健情報（PHI）を含めないでください。」

ChatGPT for Healthcare 自体は、ガバナンス付きのワークスペースとして提供されています。 ロールベースアクセス制御、SSO、監査ログを備え、BAA（Business Associate Agreement）を締結した顧客は、同一ワークスペース内で ChatGPT Work、Codex、アプリ、プラグインを HIPAA 準拠のワークフローに使えます。

何が変わったか

• Epic の電子カルテ連携: 権限のある患者情報を ChatGPT へ持ち込める。read-only（書き戻しなし）
• 対応デプロイでは EHR のレイアウト内に ChatGPT を直接組み込める
• Healthcare Public Data プラグイン: 9つの公式な公開医療データソースへの構造化アクセスを1プラグインで提供
• 含まれるソース: ClinicalTrials.gov、CMS Coverage、RxNorm、DailyMed、PubMed ほか
• レコード・フィールド・識別子・バージョンの単位で扱えるため、精密な比較・検証が可能
• 同日の ChatGPT Release Notes（# September 1, 2026）にも掲載。 米国の対象 ChatGPT for Clinicians ユーザーは Plugin directory から導入可能
• 公開ソースへの検索に PHI を含めないことが明記されている
• EHR 連携は個人アカウントでは利用不可
• ChatGPT for Healthcare はロールベースアクセス制御・SSO・監査ログを備え、BAA 締結で HIPAA 準拠ワークフローに使える

業務インパクト（一般企業向け）

まず、日本の医療機関にとっての位置づけを正確にしておきます。

この発表は米国の医療制度を前提としています。 Epic は米国で圧倒的なシェアを持つ EHR ベンダーで、CMS Coverage は米国の公的医療保険の適用ポリシーです。日本の医療機関がそのまま使える話ではありません。

しかし、この発表の構造は日本でも参照価値があります。 それは、「AI を業務システムへ組み込むときに、何が論点になるか」がここに全部出ているからです。

論点1: 有効化の主体が管理者であること。

EHR 連携は、ワークスペース管理者が有効にしなければ使えません。 個人アカウントでは利用できません。臨床医が個人の判断で導入できる範囲は、Healthcare Public Data プラグインだけです。

この線引きは、医療に限らず機微データを扱うあらゆる業務で同じ形になります。 「個人が試せる範囲」と「組織が有効化しなければ使えない範囲」を分ける——これが機微データを扱う AI 機能の標準的な設計です。

論点2: read-only という設計。

ChatGPT はカルテへ書き戻しません。 読むだけです。AI の出力に責任を持つのは人間であるという前提を、システムの制約として実装した形です。

この設計判断は、社内の AI 導入でも参照すべきです。 「AI に読ませる」と「AI に書かせる」の間には、責任の所在という深い断絶があります。まず read-only から始めるのは、多くの領域で妥当な進め方です。

論点3: PHI を公開ソースへ送るなという明示。

「これらのアプリは read-only で患者チャートにアクセスしない。公開ソースへ送る検索に PHI を含めないこと」——この注意書きは、同じワークスペース内に「機微データを扱ってよい経路」と「外部へ出る経路」が同居していることを示しています。

ここが実務でいちばん事故が起きるところです。 利用者から見ると、どちらも同じ ChatGPT の画面です。経路によってデータの扱いが違うことを、利用者が意識し続けられる設計にはなっていません。

したがって、組織側で「どの操作がどの経路を通るか」を教育する必要があります。 これは日本の組織で AI を導入するときにも、そのまま当てはまる論点です。「ChatGPT に入れていいデータ / いけないデータ」という粗い教育では足りず、「同じ ChatGPT でも、この機能を使うと外へ出る」という粒度が要ります。

論点4: BAA と監査ログ。

ロールベースアクセス制御、SSO、監査ログ、そして BAA。 規制産業で AI を使うために必要な要素が列挙されています。日本でも、医療・金融・法務で AI 導入を検討するときの要件チェックリストとして、この並びは参考になります。

特に監査ログは、後回しにされがちで、後から追加できない類の要件です。 「誰が、いつ、どの患者データを、どんな質問で参照したか」——これが残らない構成で運用を始めると、後で監査に答えられません。

副業・個人活用視点

医療系の案件に関わっている人以外には、直接の実利は薄い発表です。 それでも、押さえておく価値のある点が3つあります。

1つ目は、「構造化アクセス」と「検索」の違いです。

Healthcare Public Data プラグインの価値は、9つのソースをまとめたことよりも、レコード・フィールド・識別子・バージョンの単位で扱えることにあります。

単に「PubMed を検索できる」なら、以前からできました。 今回できるようになったのは、「この治験の適格基準の、このバージョンの、この項目」を特定して扱うことです。

この違いは、AI に外部データを扱わせる設計をするときに決定的です。 要約や検索で足りる用途と、識別子とバージョンを正確に扱わなければならない用途は別物であり、後者を前者の道具でやろうとすると、もっともらしいが微妙に間違った出力が出ます。

MCP やプラグインを自作する立場なら、ここは設計の分岐点です。 「検索結果をテキストで返す」のか、「構造を保ったまま返す」のか。後者の方が実装は面倒ですが、精度が必要な用途では前者では務まりません。

2つ目は、規制産業向けの提案の型です。

この発表が並べている要素——ロールベースアクセス制御、SSO、監査ログ、BAA、read-only、PHI の扱いの明示——は、規制産業へ AI を提案するときのチェックリストそのものです。

日本の医療機関や金融機関に提案するとき、この並びを自分の提案に持ち込めるかどうかで、話の通り方が変わります。 「便利です」から入る提案と、「アクセス制御と監査ログはこうなります」から入る提案では、相手の反応がまったく違う領域です。

3つ目は、個人でできることの範囲を正確に伝える姿勢です。

EHR 連携は個人アカウントでは使えません。 この種の制約を最初に伝えられるかどうかが、専門性の見え方を決めます。

「ChatGPT が電子カルテとつながった」という見出しだけを持って行くと、「うちでも使えますか」と聞かれて、「実は管理者の有効化と対象プランが必要で、個人では EHR 連携は使えません」と後から訂正することになります。

制約を先に言う。これは Astra の記事でも同じ結論になった原則です。 ニュースを扱う仕事をするなら、見出しではなく提供条件を読む習慣が、そのまま信頼の差になります。