3秒の申し送り
「30歳男性、バイク事故、左大腿骨開放骨折、血圧90/60、心拍数110、SpO2 94%、TXA 1回投与済み、手術室への直接搬送を推奨」
経験豊富な救急隊員がこの情報を3秒で伝達します。受け入れ側の看護師がうなずき、準備を開始します。患者が搬送されます。命が救われます。
これがISBARの最も優れた姿です。迅速で、標準化されており、臨床現場で普遍的に理解されています。
しかし、根本的な問題があります。3秒後、その情報は人間の記憶の中にしか存在しません。
2日後にその申し送りで何が伝えられたかを尋ねると、「確か...だったと思います」という回答が返ってきます。どの生体情報が具体的に伝達されたかを尋ねると、概算値が返ってきます。受け入れ側の看護師が救急隊員の発言と同じ内容を聞き取ったかを尋ねると、沈黙が返ってきます。
xGridは3秒の申し送りを置き換えるものではありません。それに影を与えるのです。構造化され、タイムスタンプが付与され、検証可能な記録が、発せられた言葉が消えた後も残り続けます。
5つの項目、1つのロックされたスナップショット
ISBARは臨床の申し送りを5つのカテゴリーに構造化します。
I — Identify（識別）：患者氏名、年齢、性別、登録ID。xGridでは患者記録から自動入力されます。手動での転記は不要であり、写し間違いもありません。
S — Situation（状況）：主訴、搬送先、到着予定時刻。申し送りの「理由」にあたる部分です。
B — Background（背景）：既往歴（高血圧、糖尿病など）、アレルギー、現在の服薬、身体計測データ。
A — Assessment（評価）：現在のバイタルサイン — 血圧、心拍数、呼吸数、SpO2、GCS（開眼/言語/運動）、疼痛スコア。
R — Recommendation（推奨）：推奨される処置、保留中の指示、搬送時の注意事項。
申し送りが作成されると、xGridはスナップショットを取得します。これは患者の現在の状態を凍結したコピーであり、デジタル指紋で保護されています。このスナップショットは変更不可能です。2時間後には患者の状態が大きく変化している場合があります。しかし、申し送りの記録は申し送り時点で把握されていた情報を保存しており、その後判明した事実ではありません。
この区別は、インシデント後のレビューや法的手続きにおいて極めて重要です。「救急隊員は何を伝達したか？」と「患者の実際の状態はどうだったか？」は異なる問いです。スナップショットは前者に回答し、変化し続ける医療記録は後者に回答します。
1人の患者、1人の受け入れ看護師
申し送りはPENDINGステータスで作成されます。1人以上の看護師がキューで確認します。2人が同時に「受諾」を押した場合、誰が患者を担当するのでしょうか。
システムが自動的に解決します。受諾チェックにより、最初の看護師のみが受諾に成功します。2人目の看護師は即座に「この申し送りは既に受諾されています」と表示されます。
大量傷病者対応の場面では、複数の看護師が同じ待機キューを確認するのは例外ではなく常態です。この保護機能がなければ、同一患者を2つのチームが引き受ける可能性があり、希少な資源の浪費と危険な責任の空白を生み出します。
申し送り後の過程
申し送りは一瞬ではありません。それはプロセスです。「救急隊員が申し送りを作成」してから「患者が目的地に到着」するまでの間に、さまざまな事象が発生します。xGridはそれらを付記システムで追跡します。
到着時バイタルサイン：救急隊員が患者の所在地に到着した際、バイタルサインを再測定します。これらは申し送りに紐づけられた新しい測定値として記録され、初期評価からの変化を把握します。
搬送中イベント：搬送中に状況が変化します。酸素流量の調整、患者の意識レベルの低下、道路損傷による経路変更。各イベントにタイムスタンプが付与され、追記されます。
臨床メモ：構造化されたカテゴリーに該当しない自由記述の観察事項。
付記は申し送りが受諾された後にのみ追加できます。保留中の申し送りにはまだ責任者がいないため、メモを追加する権限を持つ者がいません。
拒否も情報である
申し送りは拒否される場合があります。これは失敗ではありません。それは構造化された理由コードで記録される、意味のある臨床判断です。
- 患者不安定：患者の状態が変化し、搬送は安全ではない
- 受入能力なし：受入先の施設が満床
- 搬送先利用不可：対象施設が避難済みまたは閉鎖
- その他：自由記述による説明
これらの拒否記録は、災害後レビューで必ず浮上する問いに回答します。「なぜこの患者は行くべき場所に搬送されなかったのか？」
構造化された拒否追跡がなければ、回答は通常「誰かが搬送しないと決めたが、理由は分からない」となります。追跡があれば、すべての判断が文書化されます。
タイムラインの再構築
申し送り記録、付記、監査ログ、リソース管理イベントストリームを組み合わせると、各患者の旅路の完全なタイムラインが得られます。
| 時刻 | イベント | 詳細 |
|---|---|---|
| 08:30 | 現場受入 | 患者到着、MIST申し送り、トリアージRED |
| 08:31 | 申し送り作成 | 救急隊員がISBARを看護ステーション宛に作成 |
| 08:33 | 申し送り受諾 | 看護師Bが担当を受諾 |
| 08:35 | 到着時バイタル | 血圧85/55（初期評価から低下） |
| 08:37 | 搬送中イベント | 酸素を15 L/分に増量 |
| 08:42 | 申し送り完了 | 患者が手術室に到着 |
| 08:43 | 手術開始 | 術式開始の記録 |
| 09:15 | 血液製剤払出 | 血液銀行から1単位払出 |
| 10:30 | 手術終了 | 術式完了 |
| 10:35 | 術後パッケージ | リソースデータが臨床システムに返送 |
このタイムラインは自動的に組み立てられます。誰かが座って報告書を書く必要はありません。各システムがそれぞれの領域のイベントを記録し、事後にそれらが完全な物語へと統合されます。
価値は時間とともに増大します。1つのタイムラインはケースレビューです。100のタイムラインはデータセットになります。どの搬送ルートが最も時間がかかるのか。どの時間帯に申し送りの拒否率が最も高いのか。詳細な付記はより良い患者転帰と相関するのか。
4つのフォーマット、1つの基盤
xGridは4つの申し送りフォーマットに対応しています。
- ISBAR — 院内標準の申し送り
- MIST — 戦場外傷（受傷機転、損傷、徴候/症状、処置）
- SOAP — 外来臨床記録
- ICU Shift — 集中治療室の勤務交代時申し送り
フォーマットは異なりますが、基盤となる記録管理は同じです。構造化された項目の集合が、同一のメタデータ（誰が、いつ、ステータス、検証用フィンガープリント）で包まれています。システムはどのフォーマットを使用するかを問いません。すべての申し送りに完全な監査証跡があることを重視します。
即興から根拠へ
Safety-IIの記事で、ある看護師が避難命令が発令される前に血液製剤データを自発的に携帯電話にスキャンした事例を紹介しました。その即興的な対応はイベントログに記録され、最終的に推奨ワークフローの一部となりました。
同じ原則が申し送りにも当てはまります。すべての申し送りが構造化データであるとき、即興的な対応が可視化されます。どの臨床スタッフが最も詳細なBackground項目を追記しているかが分かります。どのRecommendationが実際に実行されているかを特定できます。さまざまな状況における申し送り作成から受諾までの時間を測定できます。
口頭での申し送りでは、これらは一切不可能です。口頭の情報が価値に劣るからではなく、蒸発してしまうからです。構造が永続性を与えます。永続性が学習を可能にします。
関連記事：すべての血液バッグの旅 — 血液製剤管理チェーンのデジタル化 · 壁が破られたとき — Safety-IIで医療システムを設計する