紹介元の医療機関へ送る返書の下書きを、紹介状の依頼内容と外来の診察記録・検査結果・今後の方針から作り、担当医の確認に回す
紹介を受けた患者の外来の診察が終わったあと、紹介状の依頼内容と診察記録・検査結果・今後の方針から、紹介元へ送る返書の下書きを作ります。担当医は下書きを読み、直して署名します。
- 生成AI
- Azure OpenAI Service/Claude/Gemini
- 連携・自動化
- Power Automate
- 対象業界
- 医療
- 対象部門
- 総務
- 対象業務
- 書類作成/要約
- 主な課題
- 人手が足りない/書類作成に時間がかかる/期限・対応漏れが起きる
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/対応スピード向上/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 医療連携室が紹介状を受け付け、スキャンして電子カルテに取り込む。紹介患者の台帳に登録する
- 担当医が外来で診察し、診察記録に所見・評価・方針を書く。検査を出す
- 医師事務作業補助者が返書の様式を準備し、宛先と紹介日を入れる
- 担当医が診療の合間か診療後に、紹介状と診察記録と検査結果を開き直す
- 返書の本文(受診の報告、所見、診断、方針、紹介元へのお願い)を書く
- 署名し、医療連携室が郵送か地域の医療連携の仕組みで送る
- 医療連携室が台帳に送付日を入れる。未作成のものを担当医に催促する
- 人医療連携室が紹介状を受け付け、台帳に紹介の依頼内容を写す(これまでの受付に1項目足す)
- 人担当医が外来で診察し、診察記録を書く(これまでどおり)
- 自動診察記録が確定したことをきっかけに、連携の処理が紹介患者かどうかを台帳で確かめる
- 自動紹介状の依頼内容、診察記録、検査結果、処方、方針を集め、患者を特定する情報を仮の番号に置き換える
- 自動生成AIが返書の下書きを作り、依頼への答え、結果待ちの項目、記録に無かった項目を分けて返す
- 自動連携の処理が、下書きの中の値(検査の値、薬の名前と量、日付)を元の記録と照らす
- 人医師事務作業補助者が宛先と添付を整え、担当医の確認待ちの一覧に載せる
- 人担当医が下書きを読み、直して署名する
- 人医療連携室が送り、台帳に送付日を入れる
各工程の詳しい説明を読む
- 医療連携室が紹介状を受け付け、スキャンして電子カルテに取り込む。紹介患者の台帳に登録する
- 担当医が外来で診察し、診察記録に所見・評価・方針を書く。検査を出す
- 医師事務作業補助者が返書の様式を準備し、宛先と紹介日を入れる
- 担当医が診療の合間か診療後に、紹介状と診察記録と検査結果を開き直す
- 返書の本文(受診の報告、所見、診断、方針、紹介元へのお願い)を書く
- 署名し、医療連携室が郵送か地域の医療連携の仕組みで送る
- 医療連携室が台帳に送付日を入れる。未作成のものを担当医に催促する
(a)返書は診療の後に回る。 外来の診療中に返書を書く時間はなく、診療が終わった夕方以降か、翌日以降にまとめて書きます。 その時点で紹介状と診察記録を開き直し、何を診てどう考えたかを思い出すところから始まります。
(b)依頼に答えていない返書がある。 紹介状を読み返さずに書くと、診察の所見と検査の値は並んでいても、「手術の適応はあるか」という依頼への答えが書かれていない返書になります。紹介元の医師は、その答えを患者に説明するために紹介しています。
(c)途中の状態を言い切ってしまう。 外来の初診では、検査の結果が出ていないことも、診断が「疑い」のままのことも多くあります。急いで書くと「〜と診断しました」と書いてしまい、 後の結果で診断が変わったとき、紹介元が患者に説明し直すことになります。
(d)未作成の返書がたまる。 1件の返書に8分かかると、月に15件の紹介を受ける医師で2時間です。外来の多い医師ほど返書が遅れ、 紹介元から「その後どうなりましたか」と問い合わせが入ります。
- 【人】 医療連携室が紹介状を受け付け、台帳に紹介の依頼内容を写す(これまでの受付に1項目足す)
- 【人】 担当医が外来で診察し、診察記録を書く(これまでどおり)
- 【自動】 診察記録が確定したことをきっかけに、連携の処理が紹介患者かどうかを台帳で確かめる
- 【自動】 紹介状の依頼内容、診察記録、検査結果、処方、方針を集め、患者を特定する情報を仮の番号に置き換える
- 【自動】 生成AIが返書の下書きを作り、依頼への答え、結果待ちの項目、記録に無かった項目を分けて返す
- 【自動】 連携の処理が、下書きの中の値(検査の値、薬の名前と量、日付)を元の記録と照らす
- 【人】 医師事務作業補助者が宛先と添付を整え、担当医の確認待ちの一覧に載せる
- 【人】 担当医が下書きを読み、直して署名する
- 【人】 医療連携室が送り、台帳に送付日を入れる
8番目が、この設計の分かれ目です。担当医は署名の前に必ず本文を読みます。 下書きは記録を並べ直したもので、医師がその言葉で紹介元に伝えてよいかを決めるのは医師だけです。 読んで直す時間を含めて1件3分です。
6番目を機械の照合にしているのも、意図してのことです。 検査の値や薬の量を文章にするとき、生成AIは桁や単位を写し間違えることがあります。値が元の記録と一致しているかは、文章を書いたAIではなく、記録を持っている側で確かめます。
02今回想定するシステム構成
紹介状(スキャン)+ 紹介患者の台帳(依頼内容) ▼【トリガー】外来の診察記録の確定 Azure Functions(連携の処理) ├──▶ 台帳で紹介患者かを確認、報告の種類(受診報告/結果報告)を決める ├──▶ 電子カルテ:診察記録、検査結果、処方、方針 ├──▶ 患者を特定する情報を仮の番号に置き換え ▼ Azure OpenAI(Microsoft Foundry)── 構造化出力で返書の下書き │ ① 依頼への答え ② 所見と検査 ③ 診断(確定/疑い) │ ④ 今後の方針と紹介元へのお願い ⑤ 結果待ちの項目 ▼ Azure Functions ── 値の照合、仮の番号を戻す ▼ 【医師事務作業補助者が宛先・添付を整える】→【担当医が確認・修正・署名】
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Azure OpenAI(Microsoft Foundry) | Claude API、Gemini API |
| 連携 | Azure Functions(記録の集約、置き換え、値の照合、受け渡し) | Power Automate |
| 診療記録 | 既存の電子カルテ(診察記録、検査結果、処方、文書作成の機能) | ― |
| 台帳 | 医療連携室の紹介患者の台帳 | ― |
電子カルテと台帳は、新しく足すものではありません。 返書の確定と保存はこれまでどおり電子カルテの文書作成の機能で行い、この構成は下書きを作って確認待ちの一覧に置くところまでを受け持ちます。電子カルテに直接書き込むことはしません。
生成AIは、Azure OpenAI の構造化出力で呼びます。 Microsoft Learn では、構造化出力を使うとモデルは推論 API 呼び出しの一部として指定した JSON スキーマの定義に従うとされ、有効な JSON は保証するがスキーマへの厳密な準拠はできなかった以前の JSON モードとは違うと説明されています。Chat Completions API では response_format に、Responses API では text.format にスキーマを書きます。すべてのフィールドを必須にし、省略できる項目は null との共用体型で表し、オブジェクトには additionalProperties: false を付けます。
院内からの接続は、閉じた経路にします。 「Foundry Tools の仮想ネットワークを構成する」では、既定では任意のネットワーク上のクライアントからの接続を受け入れるとされ、ネットワーク ルールで特定のサブネットや IP アドレスからの要求に限れます。プライベート エンドポイントを使うと、仮想ネットワーク上のクライアントとリソースの間の通信は Private Link を経由し、パブリック インターネットにさらされないと説明されており、Azure OpenAI はこの対象に含まれています。
データの扱いは、「データ、プライバシー、セキュリティ」のページで確かめます。 プロンプトと出力は他のお客様には利用できず、OpenAI には提供されず、お客様の許可または指示なしに生成 AI 基盤モデルのトレーニングに使われないとされ、モデルはステートレスとされています。一方、Responses API や保存済みの補完などの機能を使うと、メッセージ履歴などがリソースに保存されます。 本記事は、保存の機能を使わない呼び方を想定します。
03どうやって実装するのか
処理の起点を決める
起点は、紹介患者の外来の診察記録が確定したことです。 電子カルテから記録の確定を知らせる仕組みが無い場合は、1日に2回(昼と診療終了後)、その日に確定した記録の一覧を出力して連携の処理に渡します。 返書は当日中に送るものではないので、この間隔で足ります。
報告の種類は、台帳と検査の状態で決めます。 初診の日で、出した検査の結果がまだ返っていなければ受診報告、結果がそろっていれば結果報告です。受診報告を送った患者は、検査の結果がそろった日にもう一度、結果報告として下書きを作ります。同じ患者に2通目を作るときは、1通目の内容を入力に入れ、重ねて書かないようにします。
紹介患者でない患者の記録は、連携の処理に入れません。 台帳に載っていない患者は、その時点で処理を止めます。生成AIに渡す記録を、返書が要る患者に限るためです。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 紹介の情報 | 紹介元の医療機関と医師、紹介日、依頼内容、紹介状に書かれた既往と処方 | 紹介患者の台帳、紹介状 |
| 診察記録 | 主訴、所見、評価、方針(初診と、その後の外来) | 電子カルテ |
| 検査結果 | 検体検査の値と基準値、画像検査の報告書、結果の状態(確定/未着) | 電子カルテ |
| 処方 | 当院で出した薬の名前・量・日数、中止した薬 | 電子カルテ |
| 前回の返書 | 同じ紹介で先に送った受診報告の本文 | 電子カルテの文書 |
| 書き方の決まり | 返書の構成、敬語の型、紹介元への定型のお礼の文 | 医療連携室が作る文書 |
質を決めるのは、いちばん上の依頼内容です。 紹介状のスキャンから依頼を毎回読ませると、手書きの紹介状では読み違えが出ます。医療連携室が受付のときに、依頼内容を台帳の1項目として写します。 「精査依頼」「治療依頼」「手術適応の判断」「当院での継続可否」「その他(原文)」の区分と、紹介状の該当の一文です。
検査結果の「状態」を必ず持たせます。 値の無い検査を「未着」として渡さないと、生成AIは結果が無いことに気づかず、所見だけで書き上げてしまいます。
データの取得方法を決める
診察記録と検査結果は、電子カルテのデータ出力の機能で取ります。 出力の方式(ファイルの出力、連携用のインターフェース、データウェアハウス)は電子カルテのベンダーによって違うため、利用している電子カルテのベンダーに確かめる必要があります。 この構成で要るのは、患者と日付を指定して次の4つが取れることです。
| 取るもの | 範囲 | 使い方 |
|---|---|---|
| 診察記録 | 紹介日以降の、その診療科の外来の記録 | 所見、評価、方針 |
| 検査結果 | 紹介日以降に出した検査 | 値と状態。未着は未着として渡す |
| 処方 | 紹介日以降の処方と中止 | 紹介元が続ける薬の確認 |
| 文書 | 同じ紹介で送った返書 | 2通目で重ねて書かないため |
範囲は、紹介日以降のその診療科に限ります。 他の診療科の記録や、紹介より前の入院の記録まで入れると、紹介元が聞いていないことまで返書に書かれます。 紹介元に伝える範囲を、入力の時点で絞ります。
紹介状の既往と処方も、依頼内容と同じく台帳の項目として渡します。 紹介状には、紹介元がこれまでに出した薬が書かれています。「貴院で処方されている薬を続けてほしい」と書くには、紹介元が何を出しているかが要るからです。 スキャンした紹介状の全文を生成AIに読ませることはせず、医療連携室が受付のときに既往と処方の欄を台帳に写します。
患者を特定する情報は、生成AIに渡す前に置き換えます。 氏名、患者番号、生年月日、住所を仮の番号にし、年齢と性別だけを残します。返書の宛名と患者名は、確認の段で連携の処理が元に戻します。
AIへ渡す前に整形する
- 紹介患者かを確かめる … 台帳に載っていて、返書が未送付の紹介に当たるかを見ます
- 報告の種類を決める … 検査の状態から、受診報告か結果報告かを決めます
- 記録の範囲を絞る … 紹介日以降、その診療科の外来に限ります
- 置き換える … 氏名、患者番号、生年月日、住所を仮の番号にします。記録の本文中の氏名も置き換えます
- 検査結果を表にする … 項目、値、単位、基準値、状態の列にそろえます
- 薬を表にする … 名前、量、日数、開始・中止の列にそろえます
- 前回の返書を付ける … 結果報告のときは、受診報告の本文を入れます
4番目の記録の本文中の氏名を見落とさないでください。 診察記録には「娘さん(○○様)同席」「前医○○先生より」といった名前が本文に入ります。決まった欄の置き換えだけでは、本文の名前がそのまま出ます。 台帳の患者・家族・紹介元の名前を辞書にして、本文も置き換えます。
5番目と6番目を表にするのは、第5章の6番目の値の照合のためです。 文章のまま渡すと、下書きの中の値がどの記録から来たのかを機械で追えません。
AIに処理させる
させるのは、記録に書かれた内容を、紹介元の医師が読む順番で返書の文に並べ直すことです。 項目は次の5つです。
| 書く項目 | 書き方 | 記録に無いときの扱い |
|---|---|---|
| 依頼への答え | 依頼内容の区分に対応する方針の記載を、最初の段落に置く | 「記録に答えの記載なし」として担当医に返す |
| 所見と検査 | 主な所見と、異常のあった検査の値 | 未着の検査は「結果待ち」と書く |
| 診断 | 記録の評価の欄の診断名。「疑い」は疑いのまま | 記録に無ければ書かない |
| 方針とお願い | 当院での治療か、紹介元での継続か。紹介元に続けてほしい薬・注意 | 記録に無ければ「記録に記載なし」 |
| 結果待ちの項目 | 未着の検査と、次の受診日 | ― |
いちばん左の「依頼への答え」が、この構成の中心です。 紹介元が手術の適応を聞いているなら、記録の方針の欄に「手術適応あり、○月に手術予定」とあればそれを最初に書き、記録に答えが無ければ、作文せずに担当医に返します。 依頼への答えは、診察した医師の判断そのものだからです。
| させないこと | 理由 |
|---|---|
| 記録に無い診断や方針を書くこと | 医学的な判断は担当医が行う |
| 「疑い」を確定に書き換えること | 紹介元がそのまま患者に説明する |
| 未着の検査の結果を見込みで書くこと | 結果が出てから結果報告で書く |
| 検査の値・薬の量を丸める・換算すること | 値は記録のとおりに写す |
| 紹介元の診療への評価を書くこと | 返書は紹介元への報告で、評価の場ではない |
2行目がいちばん起きやすい失敗です。 評価の欄に「○○疑い、精査中」と書かれていても、文章を整えるうちに「○○と考えられます」「○○の診断で」と言い切りに寄ります。指示で禁じたうえで、出力の項目に診断の確度を別に持たせます。
指示内容を固定する
あなたは病院の外来で、紹介元の医療機関の医師へ送る返書の下書きを作る担当です。
読むのは、患者を紹介してくれた診療所・病院の医師です。
渡された記録に書かれていることだけを使ってください。
【書く順番】
1. 紹介へのお礼を1文
2. 依頼への答え(依頼内容の区分に対応する方針の記載)
3. 主な所見と、異常のあった検査の値
4. 診断(記録の評価の欄のとおり)
5. 今後の方針と、紹介元へのお願い
6. 結果待ちの項目と、次の受診日
【厳守事項】
- 記録に書かれていない診断、治療、方針を書かないでください。
- 記録に依頼への答えが見つからないときは、2. を書かず、
answer_to_request を null にしてください。作文しないでください。
- 「疑い」「精査中」「否定できない」と書かれた診断は、そのまま書いてください。
「〜と考えられます」「〜の診断で」に言い換えないでください。
- 状態が「未着」の検査は、結果を書かず「結果待ち」と書いてください。
- 検査の値、単位、薬の名前と量は、記録のとおりに写してください。
丸めたり、単位を換算したりしないでください。
- 紹介元の診療についての評価や意見を書かないでください。
- 患者は仮の番号で書かれています。名前を作らないでください。
- 前回の返書があるときは、すでに伝えた内容を繰り返さず、
前回からの変化と、結果の出た検査を中心に書いてください。
- 敬語は「書き方の決まり」の型に合わせてください。
【報告の種類】{report_type}
【紹介の情報】{referral}
【診察記録】{notes}
【検査結果の表】{labs}
【処方の表】{meds}
【前回の返書】{previous_letter}
【書き方の決まり】{style_guide}
「答えが見つからないときは作文しない」を明記しないと、所見から答えを組み立てます。 「手術の適応について」と聞かれ、記録の方針が空欄だと、モデルは所見と検査の値から「手術適応はあると考えます」と書きます。それは医師の判断を、記録の外で作ったことになります。 null にして担当医に返します。
「疑い」を言い換えない、を具体的な言い回しで書いているのは、 「確定と書かない」だけでは「〜と考えられます」のような柔らかい言い切りに逃げるからです。
出力形式を固定する
次の形のJSONで受け取ります。
{
"report_type": "visit_report | result_report",
"answer_to_request": "string | null",
"findings": "",
"lab_mentions": [
{ "item": "", "value": "", "unit": "", "status": "final | pending" }
],
"diagnoses": [
{ "name": "", "certainty": "confirmed | suspected", "source_line": "" }
],
"plan_and_requests": "",
"med_mentions": [
{ "name": "", "dose": "", "action": "start | continue | stop" }
],
"pending_items": [""],
"missing_in_record": [""],
"letter_body": ""
}
1つ目の理由は、answer_to_request が null になれることです。 null のものは確認待ちの一覧で印を付け、担当医が最初に依頼への答えを書き足すところから始められます。 返書の中で最も大事な段落が空いていることが、一目で分かります。
2つ目は、diagnoses に確度と根拠の行を持たせることです。 certainty が suspected なのに、letter_body の中で言い切っていないかを、連携の処理が文の終わり方で見ます。根拠の行 source_line があれば、担当医は記録のどこから取ったかをすぐに確かめられます。
3つ目は、lab_mentions と med_mentions を元の表と照らせることです。 連携の処理が、値・単位・量を検査結果の表と処方の表に一つずつ当て、一致しないものを赤で示します。 文章の正しさではなく、値の一致を機械で確かめます。
letter_body は、たとえば次のような下書きになります(受診報告で、依頼が「精査依頼」の例)。
【ご紹介へのお礼】
このたびは患者さん(仮番号 P-0412、70歳代男性)をご紹介いただき、ありがとうございました。
【ご依頼への答え】
ご依頼の貧血の精査につきまして、上部・下部の内視鏡検査を予定しております。
【所見と検査】
初診時の血液検査で Hb 8.9 g/dL と低下を認めました。便潜血は結果待ちです。
【診断】
鉄欠乏性貧血の疑い(消化管からの出血の有無を精査中)。
【今後の方針とお願い】
検査の結果がそろいましたら、改めてご報告いたします。
貴院で処方されている鉄剤は、当面そのまま継続をお願いいたします。
【結果待ちの項目】
便潜血、上部・下部内視鏡(次回受診 ○月○日)
見てほしいのは「疑い」と「結果待ち」が残っていることです。 この下書きで担当医がすることは、言い回しの確認と、鉄剤の継続のお願いが自分の考えどおりかの確認だけです。検査の値 8.9 g/dL は、連携の処理が検査結果の表と一致していることを確かめた上で表示されます。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 電子カルテ | データ出力(方式はベンダーに確認) | 診察記録、検査結果、処方、文書を取る |
| 紹介患者の台帳 | 読み取り | 紹介患者か、依頼内容、送付の状態 |
| Azure OpenAI | プライベート エンドポイント経由の API 呼び出し | 構造化出力で下書きを返す |
| 確認待ちの一覧 | 院内の画面(Azure Functions が作る) | 下書き、照合の結果、依頼への答えの有無 |
| 電子カルテの文書作成 | 人が貼り付けて確定 | 署名と保存はこれまでどおり |
電子カルテへは書き込みません。 担当医が確認待ちの一覧で下書きを直し、電子カルテの文書作成の画面に貼って署名します。返書を確定させる操作を、人の手に残すためです。
台帳の送付日も、送ったときに医療連携室が入れます。 下書きができた時点で「作成済み」にすると、署名されていない返書が送付済みに見えます。
人が確認する
担当医は、署名の前に必ず本文を読みます。 確認の順は次のとおりです。
- 依頼への答えを見る …
answer_to_requestが null なら、ここを書き足します - 赤の値を見る … 値の照合で一致しなかった検査・薬を、記録で確かめて直します
- 診断の言い方を見る … 「疑い」のものが言い切られていないかを読みます
- 方針とお願いを読む … 紹介元に続けてほしいこと、注意してほしいことが、自分の考えどおりかを確かめます
- 署名する … 電子カルテの文書作成の画面に貼り、署名します
医師事務作業補助者は、担当医の前に宛先と添付を整えます。 紹介元の医療機関と医師の名前、添付する検査結果と画像の報告書をそろえ、担当医が本文だけを読めばよい状態にして一覧に載せます。
目標は、900件をならして1件3分です。 依頼への答えが記録に書かれていて値の照合がすべて合う返書は1分ほどで済み、答えを書き足すものは5分以上かかります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 依頼内容が台帳に写されていない | 下書きを作らず、医療連携室に依頼内容の入力を求める |
| 記録に依頼への答えが無い | answer_to_request を null にし、担当医が書き足す |
| 検査の結果が未着 | 受診報告として作り、結果がそろった日に結果報告を作る |
| 値の照合が合わない | 赤で示し、担当医が記録で確かめて直す |
| 紹介状が手書きで読めない | 医療連携室が紹介元に問い合わせて依頼内容を確かめる |
| 紹介元が複数(主治医と専門医) | 台帳で宛先を確かめ、宛先ごとに下書きを作る |
| 患者が受診しなかった | 下書きを作らない。医療連携室が紹介元に連絡する |
| 結果報告なのに前回の返書が見つからない | 受診報告が紙で送られた可能性がある。医療連携室が控えを探し、見つからなければ受診報告として作り直す |
| 診察の途中で別の診療科へ回した | 回した先の診療科の担当医に下書きの担当を移し、台帳の担当医を書き換える |
| 生成AIの呼び出しが失敗する | 確認待ちの一覧に「下書きなし」と出し、担当医がこれまでどおり書く |
上から2行目は、失敗ではありません。 記録に依頼への答えが書かれていないのは、診察の時点でまだ決めていないか、記録に書き漏らしているかのどちらかです。 どちらにしても、返書を書く前に担当医が決めることです。
記録を残す
- 下書きを作った日時、患者の仮の番号、報告の種類、担当医
- 生成AIに渡した入力(置き換え後のもの)と、返ってきたJSONの全文
- 値の照合の結果(一致しなかった項目)
- 担当医が直した後の本文と、下書きとの差分
- 依頼への答えが null だった件数(担当医ごと・診療科ごと)
- 送付日と、紹介を受けてから送付までの日数
4つ目の差分は、書き方の決まりを直す材料になります。 担当医が毎回同じ言い回しを直しているなら、指示か書き方の決まりのほうを直します。
最後の行は、医療連携室が返書の遅れを見るための数字です。 構成を入れる前と後で、紹介から送付までの日数がどう変わったかを見ます。
04実装レベルの3段階
最小構成では、記録を書き出して伏せる作業が重く、900件には使えません。 確かめるための段階です。 半自動化で、1件8分が5分程度になります。 下書きは出ますが、値が記録と合っているかを担当医が一つずつ確かめ、受診報告か結果報告かも人が決めます。本格構成で3分になり、この段階が本記事の想定です。 差が出るのは、値の照合と報告の種類の判定が、半自動化ではまだ担当医の手元に残るからです。 段階を飛ばさないでください。 半自動化で1か月使うと、依頼内容が台帳に無い紹介と、答えが記録に無い返書の割合が分かります。そこを直してから自動で動かすほうが、担当医の手直しが減ります。
05工数削減シミュレーション
導入後 900件 × 3分 ÷ 60 = 45 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 地域の診療所から紹介を多く受ける急性期病院・地域医療支援病院。返書を外来の担当医が診療の合間や診療後に書いていて、未作成の返書が数日から数週間たまる場合。医師事務作業補助者が返書の様式の準備や宛先の確認をしているが、本文は医師が一から書いている場合。電子カルテから診察記録と検査結果を出力する手段がある場合。
- 紹介患者が月に数十件で、返書が滞っていない場合。電子カルテの記録を院外のクラウドに出す運用が、院内の規程で認められていない場合(閉じたネットワーク構成を組めない場合を含みます)。診断や今後の方針の判断そのものをAIに任せたい場合(この構成は記録に書かれた内容を返書の形に整えるだけで、医学的な判断は担当医が行います)。
07最小構成で試す方法
- 協力してくれる診療科を1つ決め、先月の紹介患者から20名を選ぶ
- その20名の紹介状の依頼内容、初診の診察記録、検査結果を、氏名などを伏せて書き出す
- 院内で利用が認められている生成AIの環境で、1名ずつ「この記録だけを使って、紹介元への返書の下書きを書いてください。依頼への答えを最初に書き、記録に無ければ書かないでください。疑いの診断は疑いのまま書いてください」と指示する
- 出てきた下書きを、実際に送った返書と並べて、担当医に読んでもらう
記録は必ず伏せてから使ってください。 院内で利用が認められていない生成AIのサービスに、診療記録を貼り付けてはいけません。試す段階から、置き換えの手順を作ることになります。
| 出てきた内容 | 判断 |
|---|---|
| 実際の返書と同じ内容が、依頼への答えから並んだ | 電子カルテの出力と連携に進む |
| 疑いの診断を言い切った | 指示の書き方で直る。構成は有効 |
| 記録に無い方針を書いた | 指示の見直しと、answer_to_request の null の扱いが要る |
| 依頼内容が分からず、答えが書けない | 台帳に依頼内容を写す運用が先 |
4行目が出ることは珍しくありません。 紹介状の依頼は、紹介状の本文のどこかに書かれているだけのことが多く、受付で1項目として写しておかないと、返書を書く人も毎回探すことになります。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 依頼への答えが無い返書になる | 依頼内容を台帳に写し、答えの段落を最初に置かせる |
| 記録に答えが無いと作文する | null にして担当医に返す。 指示に明記する |
| 「疑い」を言い切る | 言い換えを具体的に禁じ、確度を別の項目に持たせる |
| 検査の値・薬の量を写し間違える | 表にして渡し、値の照合を連携の処理で行う |
| 未着の検査を見込みで書く | 検査に状態を持たせ、未着は「結果待ち」とする |
| 本文中の氏名がそのまま出る | 台帳の名前を辞書にして、本文も置き換える |
| 紹介元が聞いていない記録まで書く | 記録の範囲を紹介日以降・その診療科に絞る |
| 2通目に1通目の内容を繰り返す | 前回の返書を入力に入れ、変化を中心に書かせる |
| 下書きができた時点で送付済みにする | 送付日は医療連携室が送ったときに入れる |
| 担当医が読まずに署名する | 依頼への答えと赤の値を先に見る画面にする |
上の2行が、この構成の失敗のほとんどです。 どちらも、返書でいちばん大事な段落が「紹介元の依頼に答えているか」に関わります。依頼内容が入力に入っているかと、答えが無いときに作文させないかで、運用に乗るかが決まります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 患者の診察記録、検査結果、処方、診断、紹介元の医療機関と医師の名前です。診療に関する情報で、要配慮個人情報に当たります。
- 医療情報の安全管理のガイドラインに沿って設計する … 厚生労働省の「医療情報システムの安全管理に関するガイドライン」は令和8年6月に第7.0版へ見直され、医療機関等に遵守をお願いするとされています。外部のクラウドに記録を渡す構成は、院内の情報システムの担当と、このガイドラインに照らして設計します
- 閉じた経路で呼ぶ … プライベート エンドポイントとネットワーク ルールで、院内のネットワークからの要求だけを受け付けるようにします
- 患者を特定する情報を渡さない … 氏名、患者番号、生年月日、住所を置き換え、本文中の名前も置き換えます
- 保存の機能を使わない … Responses API の会話の保存や保存済みの補完を使わない呼び方にします。不正使用の監視でのデータの保存と人のレビューについては、変更された不正使用の監視の承認を受けているかを確かめ、 承認されているときは
ContentLoggingがfalseと表示されることで確かめられるとされています - 医学的な判断を下書きに委ねない … 依頼への答え、診断、方針は、記録に担当医が書いたものだけを使い、記録に無ければ空欄で返します
- 将来の電子的な共有を見込んでおく … 厚生労働省の電子カルテ情報共有サービスは、診療情報提供書を電子で共有できるサービスを含む仕組みとされています。返書の送り方が変わっても、下書きの作り方は変わりません。送る経路と下書きを作る経路を分けておきます
誤りが起きた場合のリスクは、記録に無い判断が返書に入ることと、値が写し間違えられることの2つです。 前者は作文させない指示と null の扱いで、後者は値の照合で防ぎます。どちらも、最後は担当医が読んで署名するという手順の上に置きます。
10まず何から始めるか
1週目:台帳に依頼内容の項目を足す
医療連携室の紹介患者の台帳に、依頼内容の区分と紹介状の該当の一文を写す項目を足します。新しく受け付ける紹介から写し始めます。ここが返書の最初の段落の入力になります。
2週目:伏せた記録で20名を試す
協力してくれる診療科で、先月の紹介患者20名の記録を伏せ、院内で認められた環境で下書きを作ります。実際に送った返書と並べ、疑いの言い切りと、記録に無い方針の作文がないかを最優先で見ます。
3週目:電子カルテの出力の方式を決める
情報システムの担当とベンダーと、診察記録・検査結果・処方・文書を、患者と日付を指定して出力する方式を決めます。あわせて、置き換えの辞書(患者・家族・紹介元の名前)の作り方を決めます。
4週目:1診療科で半自動化を始める
1つの診療科で、出力した記録から下書きを作り、確認待ちの一覧に並べます。この時点では値の照合は担当医が目で行い、照合で拾うべき項目を書き出します。
2か月目: 値の照合と報告の種類の判定を足し、プライベート エンドポイントの経路に切り替えます。3か月目以降: 診療科を広げ、紹介から送付までの日数と1件8分が何分になったかを実測します。担当医の直しの差分を見て書き方の決まりを直し、依頼への答えが null になる割合が下がった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
構造化出力で、モデルが指定した JSON スキーマの定義に従うこと。以前の JSON モードとの違い。Chat Completions API では response_format、Responses API では text.format にスキーマを書くこと。すべてのフィールドを必須にし、省略可能な項目は null との共用体型で表すこと。additionalProperties: false が必要なこと | Microsoft Learn: Azure OpenAI で構造化出力を使用する方法 | 2026-10-07 |
プロンプトと出力が他のお客様に利用できず、OpenAI に提供されず、許可または指示なしに基盤モデルのトレーニングに使われないこと。モデルがステートレスであること。Responses API や保存済みの補完などでメッセージ履歴が保存されること。変更された不正使用の監視の承認で保存と人のレビューが行われないこと。ContentLogging が false で確かめられること | Microsoft Learn: Azure が販売する Foundry モデルのデータ、プライバシー、セキュリティ | 2026-10-07 |
| 既定では任意のネットワーク上のクライアントからの接続を受け入れること。ネットワーク ルールで特定のサブネットや IP アドレスからの要求に限れること。プライベート エンドポイントでは通信が Private Link を経由し、パブリック インターネットにさらされないこと。Azure OpenAI が対象のサービスに含まれること | Microsoft Learn: Foundry Tools の仮想ネットワークを構成する | 2026-10-07 |
| 医療情報システムの安全管理に関するガイドラインが令和8年6月に第7.0版へ見直されたこと。医療機関等に本ガイドラインの遵守をお願いしていること | 厚生労働省: 医療情報システムの安全管理に関するガイドライン 第7.0版 | 2026-10-07 |
| 電子カルテ情報共有サービスが全国の医療機関や薬局などで患者の電子カルテ情報を共有する仕組みであること。診療情報提供書を電子で共有できるサービスを含むこと | 厚生労働省: 電子カルテ情報共有サービス | 2026-10-07 |
診断、依頼への答え、今後の方針は、担当医が判断してください。 本記事は公開仕様で確認できた範囲だけを扱っています。電子カルテからの記録の出力の方法は、利用している電子カルテのベンダーに確認してください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0691)についてのご相談はこちらから。
