病院に毎月出されるインシデント・ヒヤリハットの報告を、事例の概要・発生場面・影響の程度で分類し、医療安全管理委員会に出す月次の集計と要点の下書きを作る

処理の起点を決める

報告が確定したときに、1件ずつ動かします。 報告者が下書きのまま保存しているものは対象にしません。確定した報告だけを分類し、その日のうちに候補が付くようにします。月末にまとめて処理すると、第3章の（c）がそのまま残ります。

報告が修正されたときにも動かします。 報告者が後から経過を書き足すことはよくあります。書き足された本文で候補を付け直し、前の候補と違えば印を付けます。 確定済みの分類は自動では変えず、医療安全管理者に知らせます。

集計と要点の下書きは、月末の締めの翌日に動かします。 締めの日に確定していない報告は、「未確定」として件数だけを集計表の脚注に出します。 未確定を抜いて数えると、月ごとの比較で件数が動いて見えます。

入力データを集める

質を決めるのは、下の2つです。 生成AIは、語彙の定義と過去の確定例を見て候補を選びます。定義があいまいなら、候補もあいまいになります。 「輸液ポンプの設定の誤り」を「薬剤」にするか「医療機器等」にするかを院内で決めていなければ、生成AIも決められません。

語彙は、医療事故情報収集等事業のヒヤリ・ハットの報告項目にそろえます。 同事業の集計表では、事例の概要は薬剤／輸血／治療・処置／医療機器等／ドレーン・チューブ／検査／療養上の世話／その他、誤った医療行為または管理の実施の有無は「患者に実施された」と「誤りがあったが患者に実施されなかった」、仮に患者への影響が大きくなった場合の事例の程度は「死亡もしくは重篤な状況に至ったと考えられる」「濃厚な治療・処置が必要であったと考えられる」「軽微な治療・処置が必要であったと考えられる」「治療・処置は不要であったと考えられる」の4段階で示されています。同事業は2025年4月に報告項目を変えているので、院内の語彙は新しい項目に合わせます。

発生場面は、事例の概要ごとに語彙が違います。 同事業の集計表では、薬剤なら「処方・指示」「指示受け」「調剤」「準備」「投与」「薬剤管理」、検査なら「オーダ・指示」「検体採取」「検体提出・受け取り」「結果報告」「結果確認」のように分かれています。事例の概要を先に決め、その中の発生場面の語彙から選ぶ二段の形にします。

データの取得方法を決める

報告の仕組みから取り出す方法は、製品によって違います。 確定の通知を外へ送れる製品なら1件ずつ、送れなければ1日数回の出力のファイルを読む形にします。どちらが使えるかは導入している製品の機能によるため、この部分は個別の実装が必要です。

電子カルテからは取りません。 影響の程度の判断に経過の確認が要るときは、医療安全管理者が自分でカルテを見ます。生成AIに渡すのは報告の本文だけにして、扱う情報の範囲を報告の仕組みに閉じます。

AIへ渡す前に整形する

1. 符号化 … 報告の本文に書かれた患者の氏名・患者ID・職員の氏名を、符号に置き換えます。名簿と職員の一覧で照合し、照合できない固有名は伏せ字にします
2. 定型の除去 … 入力画面の見出しや「特になし」のような記入を除きます
3. 長さの確認 … 本文が極端に短い報告（「転倒あり」だけなど）は、候補を付けずに印を付けて医療安全管理者に回します。根拠の取れない報告に候補を付けると、それらしい分類が付いて確認から漏れます
4. 部署と職種の付与 … 部署と関わった職種は属性の欄から取り、本文から推し量らせません
5. 語彙の版の付与 … どの版の語彙で分類したかを記録に付けます

1番目は、外へ出す範囲を決める処理です。 報告の本文には、患者の氏名や病室番号がそのまま書かれていることがあります。分類に患者が誰かは要りません。 符号にしてから渡します。

AIに処理させる

させるのは、語彙の中から候補を選び、その根拠にした本文の箇所を写すことだけです。

右端の列の「迷ったら undetermined」が、この構成で最も大事な指示です。 影響の程度は、委員会での扱いと、原因の分析にどれだけ手をかけるかを決めます。生成AIが迷った末に軽いほうを選ぶと、深く見るべき事例が一覧に埋もれます。 重いほうを選ばせても、今度は印が多すぎて確認が回りません。迷ったものは迷ったまま人に渡します。

月末の要点の下書きでさせることは、別に決めます。 渡すのは、確定した分類から作った集計表（前月・前年同月との比較を含む）と、医療安全管理者が選んだ数件の事例の要旨だけです。

数字の増減は、集計表の値から機械で計算して渡します。 生成AIに引き算をさせず、「前月差：＋12」のように計算済みの値を渡して文にさせます。下書きに出てくる数字は、集計表と照合してから医療安全管理者に回します。

分類で「させないこと」の表の4行目と5行目（再発防止策の提案、報告者の評価）は、報告の文化を守るための線です。 報告を読んだ生成AIが「確認不足が原因」「ダブルチェックの徹底を」と書き添えると、それが委員会の資料に残り、報告した職員を責める材料に見えます。 報告がためらわれるようになれば、集計そのものが成り立ちません。

指示内容を固定する

あなたは病院の医療安全管理室で、インシデント・ヒヤリハットの報告を分類する補助をします。
報告の本文だけを読み、下の語彙から分類の候補を選んでください。

【分類する項目】
1. 事例の概要（主）：薬剤／輸血／治療・処置／医療機器等／ドレーン・チューブ／検査／療養上の世話／その他
2. 事例の概要（副）：関係する区分があれば1つ。なければ none
3. 発生場面：1で選んだ区分の発生場面の語彙から1つ
4. 実施の有無：implemented（患者に実施された）／not_implemented（誤りがあったが患者に実施されなかった）
5. 仮に患者への影響が大きくなった場合の程度：
   death_or_severe／intensive_treatment／minor_treatment／no_treatment

【厳守事項】
- 本文に書かれていることだけで選んでください。書かれていない経過を補わないでください。
- 決められない項目は undetermined にしてください。
  特に5は、迷ったときに重いほうも軽いほうも選ばず undetermined にしてください。
- 項目ごとに、根拠にした本文の箇所を evidence にそのまま写してください（60字以内）。
  根拠を写せない項目は undetermined にしてください。
- 原因、要因、再発防止策、誰の誤りかを書かないでください。
- 医療事故に当たるかどうかを書かないでください。
- 下の「定義と迷いやすい例」に当てはまる事例は、その例の分類に従ってください。
- 符号（P01、S01 など）は符号のまま扱ってください。

【語彙の定義と迷いやすい例】{definitions}
【発生場面の語彙】{scene_vocab}
【報告の本文】{report_text}
【報告の属性】部署：{dept}／発生場所：{place}／関わった職種：{role}

「根拠を写せない項目は undetermined」を入れないと、本文に無い経過から程度を推し量ります。 「点滴の速度を誤った」とだけ書かれた報告に、「濃厚な治療・処置が必要であったと考えられる」と付けるような場合です。写せる根拠があるかどうかで、選ぶか保留するかを分けます。

迷いやすい例を指示に入れるのは、院内の決め事を守らせるためです。 「輸液ポンプの流量の設定の誤りは医療機器等を主、薬剤を副」のような例を医療安全管理室で決め、確定した例を版ごとに増やしていきます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "report_id": "",
  "vocab_version": "",
  "summary_category": {
    "main": "drug | transfusion | treatment | device | drain_tube | exam | care | other | undetermined",
    "sub": "none | drug | transfusion | treatment | device | drain_tube | exam | care | other",
    "evidence": ""
  },
  "scene": { "value": "", "evidence": "" },
  "implemented": { "value": "implemented | not_implemented | undetermined", "evidence": "" },
  "impact_if_worse": {
    "value": "death_or_severe | intensive_treatment | minor_treatment | no_treatment | undetermined",
    "evidence": ""
  }
}

1つ目の理由は、語彙の外の値が返らないことです。 main や impact_if_worse.value を enum にしておけば、集計の表に「点滴関連」のような列が増えることがありません。 公式のページでは、スキーマのすべての項目を required にすること、オブジェクトに additionalProperties: false を付けることが求められています。

2つ目は、印を機械で付けられることです。 次の条件のどれかに当たる報告に印を付け、医療安全管理者が先に読みます。

3つ目は、evidence で確認が速くなることです。 医療安全管理者は、本文の全体を読む前に、どの一文を根拠に候補が付いたかを見て、合っていればそのまま確定できます。

月末の集計表は、確定した分類から次の形で作ります。

「保留のまま確定」の列を残すのは、人が程度を決めきれなかった報告の数を見えるようにするためです。 この数が多い分類は、定義を見直す候補になります。

発生場面は、事例の概要ごとに語彙が違うため、スキーマでは文字列にし、照合で語彙に入っているかを確かめます。 公式のページでは、スキーマ全体で項目は最大100、入れ子は5段までとされているので、事例の概要ごとに発生場面の enum を全部並べるより、照合で確かめるほうが扱いやすくなります。

システムへ連携する

報告の仕組みには書き込みません。 報告者の選んだ分類は、そのまま残します。報告者の分類と確定した分類の違いそのものが、どの部署にどの分類の説明が要るかを示す材料になるためです。

人が確認する

分類の確定は、すべて医療安全管理者が行います。 確かめ方を、印の有無で分けます。

1. 印の付いた報告を先に読む … 程度が高い・保留・報告者と違う・実施された、のどれかに当たるもの。本文を読み、evidence を確かめて確定します
2. 程度が高い報告は、経過を確かめる … 必要に応じて報告者・所属長に聞き、カルテを見ます。これは従来どおりの仕事で、この構成では減らしません
3. 印の無い報告は一覧で確かめる … 候補と evidence を一覧で流し見て、まとめて確定します
4. 候補を覆したら理由を書く … どの項目をどう変えたかと、その理由を残します。同じ理由が続けば、迷いやすい例に足します

3番目の一覧の確認を省かないでください。 印の無い報告は「生成AIと報告者が同じ分類を付けた」ものですが、両方が同じ誤りをしていることもあります。 一覧で根拠の一文を流し見るだけでも、明らかなずれは拾えます。

目標は、300件をならして1件5分です。 印の無いものは1件1分に満たず、印の付いたものは本文を読むので数分かかります。

例外に対処する

6行目は、この構成の外で扱う事態です。 死亡や重い障害に関わる事例は、医療法の医療事故の報告や院内の調査に関わり、月次の分類の流れに乗せて待つものではありません。 報告の仕組みの側で、従来どおりの緊急の連絡経路を残します。

記録を残す

• 報告の番号と、符号化した後の本文
• 語彙の版の番号と、そのときの定義・迷いやすい例
• 生成AIの候補と evidence、付いた印
• 確定した分類、確定者、確定日時、候補を覆した理由
• 月次の集計表と、要点の下書き、委員会に出した版

2つ目の語彙の版が大事です。 迷いやすい例を足すと、同じ事例でも候補が変わります。ある月から「医療機器等」が増えたときに、事例が増えたのか例を足したからなのかを、版の記録で見分けます。

4つ目の覆した理由は、語彙の定義を良くする材料です。 同じ理由で覆す報告が月に何件も出るなら、定義か迷いやすい例が足りていません。