もう一度、火曜日の午後
第1章の火曜日の午後の回復室に戻りましょう。回復を終えた患者がベッドに残り、そのために次の手術が押し始めています。
私たちの画面の一つは、病院を生きた地図として見せます。紙に描かれた止まった見取り図ではありません。押す地図です。運営者が回復室のその場所を押すと、患者の回復状態が見え、帰宅案内が可能かどうかが見え、次の手術患者がどこまで準備できているかが見えます。そして一度の行動で帰宅手続きを実行します。
一度押せば、つながったすべての場所が動きます
その一度の行動に、病院のあちこちが同時に反応します。
帰宅案内と注意事項が患者と保護者に届き、次回来院の予約が入り、回復室の整理が担当者に割り当てられ、次の手術患者の入室案内が出て、その手術に使う消耗品が事前に点検されます。一箇所を押しただけで、つながったすべての場所が一緒に動きます。私たちが「Zero Data Silo」と呼ぶのは、まさにこれです。データが区切りに閉じ込められていないから、一度の行動が最後まで流れます。
第2部で私たちは病院を一つの網として描いてお見せしました。予約一つが手術室と人員と機器と在庫と精算につながっている関係の地図です。あのときの網は「見る」地図でした。第3部では、その地図は「押す」地図になります。つながりを知っているシステムの上でのみ、一度のクリックが十人の電話を代わることができます。
アラートではなく、次の行動が来ます
機器も同じ原理で動きます。
美容外科と皮膚科で機器は、その日の売上そのものです。主力レーザーが朝、言うことを聞かなければ、その日の予約された施術全体が揺らぎ、電話を回す一日が始まります。第1部でご紹介したシグナル(Signal)はその前に動きます。機器の異常兆候・消耗品不足・点検期限をリアルタイムで検知し、担当者に知らせます(機器会社との連携が必要)。しかし第3部の観点で重要なのはアラートそのものではありません。アラートに次の行動が一緒に載って来るということです。
普通の警告システムは「問題がある」で止まります。受け取った人はそこから調べなければなりません。どの機器か、どれほど急ぐか、誰に引き継ぐか。私たちのシステムのアラートは、機器がどこにあり、今どんな状態で、この状態でできる措置は何か — 点検予約、部品発注、担当割当 — を一緒に差し出します。受け取った人は調べる代わりに決めるだけでいいのです。その決定がアクションとなって実行され、記録されます。
「機器が止まる前にシステムが先に知らせる」という第1部の約束は、正確にはこう完成します。先に知らせ、次の行動まで揃えておくのです。
院長先生の判断が、そのまま実行になります
院長先生にとって最も意味のある部分はこれです。この構造の上では、院長先生の判断一つがそのまま病院全体の実行になります。
今、私たちが運営を支援している病院で実際に回っている流れです。患者が手術前の問診を入れると、担当チャネルに通知が自動で立ちます。院長が移動中でもそれを確認し判断を残せば、その判断がそのまま状態となり、患者に次の案内が自動で届き、関連部署の準備が始まります。院長がしたのは判断一つを残しただけです。その判断を伝え、追い、実行する仕事はシステムが代わります。
判断はまるまる院長先生のものとして残り、判断以降のすべての残務はシステムのものになります。院長先生が診療室の外の仕事に使う時間が減っていく仕組みが、まさにこれです。
今できることと、これからできること
一つはっきりさせておきます。私たちのシステムのすべての機能がまだこの水準で回っているわけではありません。ある領域は毎日現場で回り、ある領域は準備中です。だから私たちは「今できること」と「これからできること」を常に区別してお話しします。病院の運営を共に担うと言う会社であれば、当然守るべき態度だと信じているからです。
私たちの地図は「見る」ものではなく「押す」ものです。一度押せば、つながった病院全体が一緒に動きます。