ISBARは単なる申し送りフォーマットではない——口頭伝承が構造化データと出会うとき
Blog/

ISBARは単なる申し送りフォーマットではない——口頭伝承が構造化データと出会うとき

ISBARは世界共通の臨床申し送りフォーマットです。それを口頭伝承からデジタルシステムへと移行させる中で見えてきたのは、真の価値はフォーマットそのものではなく、その先にあるということでした——追跡可能、検証可能、再生可能という価値です。

3秒の申し送り

「30歳男性、自動車事故、左大腿骨開放骨折、血圧90/60、心拍数110、SpO2 94%、TXAを1回投与済み、手術室への直接搬送を推奨。」

経験豊富な救急隊員なら、これを3秒で言い切れます。受け入れる看護師はうなずき、すぐに準備に取りかかります。

これがISBARによる申し送りです。世界中で使われ、数えきれない命を救ってきました。

しかし、そこには3つの問題があります。

  1. 記録が残らない。3秒後、その言葉は空気の中に消えています。2日後に「あの患者の申し送りでは何が伝えられたのか」と聞かれても、答えは「たしか、こうだったと思う……」でしかありません。
  2. 検証できない。受け取った側が聞いた内容は、本当に伝えた側が言ったとおりなのか。誰にも分かりません。
  3. 再生できない。ある出来事の時系列を——誰が、いつ、誰に、何を伝えたのか——後から組み立て直したくても、口頭の申し送りではそれができません。

xGridは口頭での申し送りに取って代わろうとしているのではありません。口頭の申し送りが消えてしまわない構造化された記録として残るようにするものです。

ISBARの五つの項目

文字正式名称xGridが記録する内容
IIdentify(識別)患者氏名、年齢、性別、登録ID — システムが自動入力
SSituation(状況)主訴、搬送先、到着予定時刻
BBackground(背景)既往歴、アレルギー、現在の服薬、身長体重
AAssessment(評価)血圧、心拍数、呼吸数、SpO2、GCS、疼痛スコア
RRecommendation(推奨)推奨される処置、保留中の指示、搬送時の注意事項

「I」の項目は自動入力されます——申し送りを作成すると、システムが登録記録から患者情報を取り出します。プレッシャーのかかる状況で氏名や番号を手入力すれば、システムに自動入力させるよりもはるかにミスが起きやすくなります。

ISBARだけではない

xGridは4種類の申し送りフォーマットに対応しており、それぞれ異なる場面で使われます。

  • ISBAR — 院内標準の申し送り
  • MIST — 戦場外傷の申し送り(Mechanism:受傷機転、Injuries:損傷、Signs:徴候、Treatment:処置)
  • SOAP — 外来診療記録
  • ICU_SHIFT — 集中治療室の勤務交代時申し送り

フォーマットは異なっても、基盤となる追跡の仕組みは同じです。どの申し送りも、誰が渡し、誰が受け取り、いつ、そしてその状態はどうかを記録します。

スナップショット固定:申し送りの瞬間の真の状態

申し送りが作成されるたびに、システムは「スナップショット」を撮ります——その時点の患者データ、最新のバイタルサイン、トリアージ状態を、変更できない記録として凍結するのです。

なぜでしょうか。

患者のデータは変化し続けるからです。申し送りから1時間後には、トリアージがYELLOWからREDに上がっているかもしれませんし、血圧が下がり続けているかもしれません。もし申し送りの記録が「最新のデータ」を参照する仕組みだったら、「申し送りのその瞬間、患者の状態は実際どうだったのか」という問いに、あなたは永遠に答えられません。

スナップショット固定は、この問題を解決します。申し送りの記録に残るのは申し送りのその瞬間の真の状態であり、その後の更新によって上書きされることはありません。これは事後検証や法的手続きにおいて、決定的に重要な意味を持ちます。

二重受諾の防止

複数の看護師が同時に、受諾待ちの申し送りを目にすることがあります。2人が同時に「受諾」を押したら、どちらがその患者を担当するのでしょうか。

システムは原子操作によって、成功するのは1人だけであることを保証します。先に押した方が患者を受け持ち、後から押した方には「この申し送りはすでに受諾されています」と表示されます。

大量傷病者が発生する場面では、複数の看護師が同時に受諾待ちリストを確認するのはむしろ普通のことです。この保護がなければ、同じ患者を2つのチームが同時に引き受けてしまうことがあり——資源が無駄になり、責任の所在があいまいになります。

申し送りのその後

申し送りは一瞬の出来事ではなく、一つのプロセスです。救急隊員が申し送りを作成してから患者が目的地に到着するまでの間に、状況は変わり得ます。

xGridは付記システムで、申し送り後に起きたことを追跡します。

種類タイミング内容
到着時バイタルサイン救急隊員の到着時再測定したバイタルサイン
搬送中イベント搬送中酸素の調整、意識レベルの変化、経路変更
臨床メモいつでも救急隊員の臨床判断と観察事項

すべての付記にタイムスタンプが付き、申し送りから到着までの完全な時系列を構成します。

拒否も記録である

申し送りは拒否されることがあります。拒否は失敗ではありません——それ自体が意味のある臨床判断です。

  • 患者不安定 — 搬送に適さない状態
  • 受入先満床 — 空きがない
  • 搬送先閉鎖 — 当該施設はすでに撤収済み
  • その他 — 自由記述による説明

これらの記録も同じくらい重要です。「なぜこの患者は本来行くべき場所へ搬送されなかったのか」——災害後の検証で繰り返し問われるこの問いに、答えを与えてくれます。

自動的に組み立てられる時系列

すべての申し送り記録、付記、そして各システムのイベントをつなぎ合わせると、患者がたどった旅の全体像が見えてきます。

時刻イベント詳細
08:30現場受入患者到着、MIST申し送り、トリアージRED
08:31申し送り作成救急隊員がISBARを看護ステーション宛に作成
08:33申し送り受諾看護師Bが担当を受諾
08:35付記到着時バイタル:血圧85/55(申し送り時より低下)
08:37付記搬送中イベント:高流量酸素を追加投与
08:42申し送り完了患者が手術室に到着
08:43手術開始資源システムの記録
09:15血液製剤払出赤血球1単位を払出
10:30手術終了
10:35撤収パッケージ資源システムが臨床システムへ記録を返送

このタイムラインは自動的に組み立てられます。誰かが座って報告書を書く必要はありません。それぞれのシステムが自分の担当するイベントを記録し、事後にそれらを組み合わせると、完全な物語になります。

3秒から15秒へ

この記事の冒頭で紹介した、3秒の口頭申し送りに話を戻しましょう。

xGridでの申し送り操作は、およそ15秒かかります——口頭より12秒長いだけです。看護師はいくつかの項目(S、B、A、Rにそれぞれ一つずつ。Iは自動入力)をタップするだけで完了します。

しかし、その12秒と引き換えに得られるのは、次のようなものです。

  • 消えることのない記録
  • 検証可能なスナップショット
  • 再生可能な時系列
  • 分析可能なデータセット

100件分の申し送りの構造化データがあれば、こう問うことができます——どの搬送ルートが最も時間がかかっているか。どの時間帯に申し送りの拒否率が最も高いか。付記の詳細さは患者の転帰と関係があるのか。

口頭の伝統では、これらの問いに答えることはできません。構造化データなら、答えられます。


関連記事:壁が破られたとき — Safety-IIで医療システムを設計する