病院の看護師が入院時の情報と看護記録から、Azure OpenAI で看護計画（看護問題・目標・計画）の下書きを作り、評価の日を添えて看護師が確かめる

処理の起点を決める

毎日6時と14時に、入院時の情報の入力を終えた患者を取り出します。 6時の回は夜間と前日の夕方に入院した患者の分で、日勤の始まりに下書きがそろいます。 14時の回は午前中の予定入院の分で、日勤のうちに計画を立てられます。

Azure Functions のタイマー トリガーで、NCRONTAB 式は 0 0 6,14 * * * です。既定のタイム ゾーンは協定世界時（UTC）なので、日本の時刻で動かすには WEBSITE_TIME_ZONE のアプリ設定が要ります。Linux の従量課金プランと Flex 従量課金プランでは、この設定が現在サポートされていないとされているので、その場合は UTC に直した時刻（21時と5時）で書きます。

タイマー トリガーは、失敗した後に再試行しないとされています。6時の回が失敗すると、次は14時です。取り出し済みの患者を記録し、 前の回で処理できなかった患者は次の回で必ず拾います。下書きが届かないことは、病棟の一覧に「未作成」として出します。

入力データを集める

質を決めるのは、院内の看護問題の一覧の「立てる目安」の列です。 「転倒・転落のリスクの点数が院内の基準以上」「術後で疼痛の訴えがある」のように、どういう記載があればその問題を候補にするかを書いておきます。目安があると、AIは根拠の記載を探す先が決まります。

入院診療計画は、目標の期限の材料です。 通知では、入院の際に医師・看護師などが共同して総合的な診療計画を策定し、病名、症状、治療計画、検査内容及び日程、手術内容及び日程、推定される入院期間等を入院後7日以内に文書で説明することとされています。推定される入院期間より先に評価の日が来ないよう、 プログラムが評価の日を決めるときに使います。

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

電子カルテの書き出しは、提供元に確かめて決めます。 書き出しの仕組みや項目は製品によって違い、院内のデータの二次利用の基盤（データウェアハウス）から取る形のほうが組みやすい病院もあります。 どちらの場合も、氏名・住所・生年月日・患者番号を含めない書き出しにしてもらいます。 患者は書き出しの中だけで使う番号で扱い、病棟の一覧で看護師が見るときに電子カルテの患者と結び付けます。

「入力を終えた」の判断は、入院時の看護の情報の確定の印で行います。 入力の途中の情報で下書きを作ると、まだ聞いていない項目が「情報なし」として扱われ、 看護問題の候補が抜けます。

AIへ渡す前に整形する

1. 識別子を外す … 氏名・患者番号・住所・生年月日は書き出しの段階で含めません。書き出しの中だけの番号で扱います
2. 評価の未実施を拾う … 院内で入院時に必ず行うリスクの評価のうち、点数か評価日が無いものを一覧にします
3. 点数で必須の看護問題を決める … 評価の点数が院内の基準以上なら、その看護問題を「必須」として印を付けます。AIの判断を待ちません
4. 看護記録を絞る … 入院から下書きの作成までの記録だけにし、看護師の記録の中の氏名（家族の名前など）を続柄に置き換えます
5. 看護問題の一覧と標準看護計画を添える … AIに渡すのは、一覧の番号・名称・立てる目安と、標準看護計画のひな形だけです
6. 小児の病棟と産科の病棟は、別の一覧にする … 看護問題の一覧と標準看護計画が違うため、病棟の種類で渡す一覧を切り替えます

2番目と3番目が、この構成の安全装置です。 評価が済んでいなければ、AIが看護問題を推し量る前に、看護師に評価を求めます。 点数で必ず立てる問題は、AIが落としても規則の側で必ず残ります。

4番目で家族の名前を置き換えるのは、記録の中に家族の連絡先や名前が書かれていることが多いからです。 下書きに要るのは「長女が週に2回来院」までで、名前は要りません。

AIに処理させる

させるのは、院内の看護問題の一覧から候補を挙げて根拠を写し、標準看護計画のひな形をもとに、目標と計画の下書きを患者に合わせて作ることだけです。

目標は、評価の日に「達成したか」を判断できる形にさせます。 「転倒しない」だけでなく、「ナースコールを押してから移動できる」のように、評価の日に看護師が見て判断できる行動の形にします。 ただし、どの目標が患者に合うかは看護師が決めます。

2行目が、いちばん起きやすい失敗です。 80代の患者というだけで、AIは転倒・転落の看護問題を挙げがちです。根拠はリスクの評価の点数と記録の記載で、年齢だけではありません。 点数が基準より低ければ、必須ではなく、記録に根拠がある場合だけ候補にします。

4行目も同じくらい重要です。 転倒・転落のリスクの評価が未実施なのに、AIが「リスクが高いと考えられる」と書けば、評価をしたことになってしまいます。 未実施は未実施として返します。

指示内容を固定する

あなたは急性期病院の病棟で、受け持ちの看護師が看護計画を立てるのを
手伝う立場です。入力の【入院時の情報】【リスクの評価】【看護記録】
【入院診療計画】だけを根拠に、看護計画の下書きを作ってください。

【看護問題の選び方】
- 看護問題は【院内の看護問題の一覧】の番号から選んでください。
  一覧に無い看護問題を作らないでください。
- 【必須の看護問題】に挙がった番号は、必ず候補に含めてください。
- それ以外の候補は、【院内の看護問題の一覧】の「立てる目安」に当たる記載が
  入力にある場合だけ挙げてください。年齢や病名だけを根拠にしないでください。
- evidence には、根拠にした記載を入力からそのまま写してください。
  写せる記載が無い看護問題は挙げないでください。

【目標と計画の作り方】
- 【標準看護計画】の該当するひな形をもとに、目標と計画を患者に合わせて直してください。
- 目標は、看護師が患者を見て達成したかを判断できる行動の形にしてください。
- ケアと指導の計画は、入院時の ADL、入院前の生活、退院の見込みに合わせてください。
- ひな形を患者に合わせられない項目は、ひな形のまま残し、needs_adjustment を
  true にしてください。

【厳守事項】
- 入力に無いことを書かないでください。推測で補わないでください。
- リスクの評価が【評価の未実施】に挙がっているときは、その評価の結果を
  推し量らないでください。「リスクが高いと考えられる」と書かず、
  to_confirm に「評価が未実施」と挙げてください。
- 評価の日を書かないでください。
- 薬の量、安静度、食事の内容など、医師の指示に関わる変更を計画に書かないでください。
  入院診療計画にある指示は、そのまま参照するだけにしてください。
- 患者や家族の名前、病室の番号を書かないでください。

【入院時の情報】{admission}
【リスクの評価】{risk}
【評価の未実施】{missing_assessments}
【必須の看護問題】{required_problems}
【看護記録】{notes}
【入院診療計画】{care_plan}
【院内の看護問題の一覧】{problem_list}
【標準看護計画】{templates}

「年齢や病名だけを根拠にしない」を明記しないと、候補が増えすぎます。 候補が多い下書きは、看護師が外す手間を増やすだけで、一覧から選ぶ作業がかえって重くなります。 根拠の記載を写せるものだけに絞らせます。

「評価の日を書かない」も、名指しで禁じています。 何も言わなければ、AIは目標に「1週間後に」と期限を付けたがります。評価の日はプログラムが決まりで添えるので、 AIの書いた日付が二重に残ることを防ぎます。

出力形式を固定する

{
  "case_ref": "",
  "problems": [
    {
      "problem_no": "",
      "required": true,
      "evidence": [ "" ],
      "goal": "",
      "observation_plan": [ "" ],
      "care_plan": [ "" ],
      "education_plan": [ "" ],
      "needs_adjustment": false
    }
  ],
  "to_confirm": [ "" ]
}

構造化出力では、すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定するとされています。スキーマのプロパティは最大100個、入れ子は最大5段です。配列の要素の数の上限を指定するキーワードはサポートされていないため、候補の数が多すぎないかはプログラムの側で数えます。

JSON にする1つ目の理由は、problem_no を一覧と照合できることです。 AIが一覧に無い番号を返したら、プログラムがその候補を外し、外したことを to_confirm に足します。 必須の看護問題が返ってこなかったときも、プログラムが足します。

2つ目は、evidence を入力と照合できることです。 根拠として写した記載が、入力の中に本当にあるかを文字列で確かめます。入力に無い根拠が書かれていたら、その候補に「根拠の確認」の印を付けて看護師に見せます。

3つ目は、評価の日を後から足せることです。 プログラムが problem_no ごとに評価の日の決まりを引き、推定される入院期間の終わりより前になるように日付を決めて、 病棟の一覧に表示します。

表の日数は例で、看護記録委員会が決めます。 大事なのは、評価の日を看護問題の種類と入院期間から機械的に決めることです。

システムへ連携する

下書き一覧は、病棟ごと・受け持ちの看護師ごとに並べます。 看護師が開けるのは自分の病棟の患者の分だけにし、誰がいつ開いたかを残します。

電子カルテの看護計画には、看護師が自分で立てます。 下書きの problem_no は電子カルテの標準看護計画の番号と同じにしておき、看護師はその番号のひな形を呼び出して、下書きの直しを写します。 写す手間は残りますが、看護師が確かめていない計画が電子カルテに入る経路がありません。

人が確認する

下書きは全件、受け持ちの看護師が患者を見て確かめます。

1. to_confirm を最初に見る … 評価の未実施があれば、計画の前に評価を行います
2. 看護問題の候補を選ぶ … evidence を読み、患者の状態と合うかを確かめます。合わない候補は外し、足りない問題は足します
3. 目標を直す … 患者と話し、達成できる目標かを確かめます
4. 計画を直す … ケアと指導の計画を、患者と家族の生活に合わせます
5. 評価の日を確かめる … 決まりで付いた日が、患者の予定（手術、検査、退院）と合うかを見ます
6. 電子カルテで計画を立て、リーダーに確認してもらう

2番目で、候補を外すことをためらわないでください。 下書きに挙がった問題をそのまま全部立てると、計画が長くなり、通知が求める「簡潔明瞭」から離れます。 外した候補は、外した理由を一言残します。

看護記録委員会は、月に1回、各病棟の10件を抜き取り、 下書きと確定した計画を見比べます。外された候補が多い看護問題は、一覧の「立てる目安」を見直します。 足された問題が多いときは、目安が狭すぎます。

例外に対処する

上から2行目が、運用の初めに多く出ます。 入院時の評価の入力が漏れていたことが、下書きを作る段階で毎回見えるようになります。 未実施の件数を病棟ごとに数えると、入院時の手順の見直しの材料になります。

最後の行は、下書きの外に置いてください。 急変や手術の追加で状態が変わったときは、次の6時や14時の下書きを待つ理由はありません。 下書きは入院時の計画を立てる手間を減らすもので、計画の見直しの判断を遅らせるものではありません。

記録を残す

• 確定した計画 … いまと同じく電子カルテの看護計画に残ります
• 入力と下書き … 書き出しの内容、AIの下書き、プログラムが付けた印と評価の日を、確定から一定の期間（例：3か月）だけ残して消します
• 看護師の選択の記録 … どの候補を選び、どれを外し、何を足したか。外した理由の一言
• 操作の記録 … 誰が、いつ、どの患者の下書きを開いたか
• 決まりの版 … 看護問題の一覧、標準看護計画、評価の日の決まり、指示の文を、改訂のたびに日付付きで残します

看護師の選択の記録が、この構成を育てる材料です。 外された候補と足された問題を看護問題ごとに数えると、一覧の「立てる目安」と標準看護計画のどこを直すべきかが分かります。

下書きを長く残さないのは、正本と重ならないようにするためです。 正本は電子カルテの看護計画で、下書きは計画を立てるまでの材料です。