米国ペンシルベニア州スクラントンでは、公営と民間の救急搬送サービスを組み合わせたハイブリッド型の救急医療サービス（EMS）への移行が検討されています。2027年の資本予算案には、市が運営するEMS体制を構築し始めるため、中古救急車3台の購入が盛り込まれています。表面上は車両への投資に見えますが、より難しい問題は車両が運用に入った後に始まります。誰が出動指令を担当するのか。公営と民間の救急車を同じリソースプールで管理できるのか。どの隊が最も近く、その救急隊はどの程度の臨床対応能力を持つのか。受入病院は現在、その種類の患者に対応できるのか。さらに多数傷病者が発生した場合、消防、EMS、警察、指令センターはどれだけ迅速に一体の対応体制として動けるのか。救急車を増やすだけでは、これらの課題は自動的には解決しません。
規模を拡大したり運用モデルを変更したりするEMSにとって、車両台数は出発点にすぎません。重要なのは、それらのリソースを一つの運用状況の中で可視化し、指令し、連携できるかどうかです。そこで成熟した緊急指令・指揮システムが不可欠になります。
救急車を増やすと、まず指令が複雑になることが多い
一つの組織が車両、乗員、勤務表、指令権限を管理している場合、EMSの指令は比較的単純です。通信センターは自組織のリソースを直接把握でき、組織の境界を越えずに割り当てられます。
ハイブリッド型は異なります。市の救急車、民間EMS事業者、病院系の搬送チームが同時に利用可能でも、必ずしも同じ管理体制の下で動いているわけではありません。911通報が入ったとき、指令システムは「近くに救急車が5台ある」と表示するだけでは不十分です。どの隊が空いているか、すでに出動中か、各救急隊の臨床対応能力がその事案に適しているか、到着まで何分かかる見込みか、そして同じくらい重要な点として、指令員がそのリソースを実際に割り当てる権限を持っているかを示す必要があります。
こうした情報が別々のシステムに分断されていると、指令員は電話をかけ、複数のアプリを切り替え、あるいは無線で一隊ずつ呼び出さなければなりません。通報件数が少ないときは対応できても、大規模交通事故、悪天候、地域的な公衆衛生上の緊急事態では、手作業の調整が対応全体で最も遅い部分になりかねません。
したがって、ハイブリッド型EMSで最初に必要なのは大きなビデオウォールではなく、共有されたリソース状態モデルです。各事業者は自社の管理システムを継続利用できますが、待機可能、割当済み、現場へ移動中、現場到着、搬送中、病院到着、再び出動可能といった主要な運用状態は、共通の指揮画面で確認できなければなりません。
位置、隊の状態、事案への割当が継続的に更新されれば、指令センターは「無線に最初に応答した隊を出す」という単純な方法ではなく、距離、能力、管轄、事案の優先度に基づいて判断できます。
911通報から病院への引き継ぎまで、情報を途切れさせてはいけない
EMSは救急車が患者に到着した時点で終わるわけではありません。完全な対応には、通報受付、事案トリアージ、隊の割当、出動、現場処置、搬送、病院選定、到着前通知、最終引き継ぎまでが含まれます。各段階で新しい情報が生まれ、その更新によって次の行動が変わることがあります。
よくある状況を考えてみます。最初の通報では「患者が息苦しい」とだけ報告されるかもしれません。しかし現場に到着すると、救急隊が当初の報告よりはるかに重篤な状態だと判断することがあります。その場合、事案の優先度を上げ、追加リソースを要請し、当初予定していた搬送先病院を変更する必要が生じるかもしれません。
現場チームがこうした更新を無線で繰り返すしかなく、指令、病院、支援機関がそれぞれ別の情報系統を持っていると、同じ内容を何度も中継することになります。引き継ぎが増えるほど、遅延や文脈の欠落が起きる機会も増えます。
緊急指揮システムは、事案を継続的に更新される運用記録として扱うべきです。通信センターが通報を登録すると、隊の位置と状態を同じ事案に関連付けます。救急隊が現場に着けば、患者区分や支援要件を更新できます。搬送を開始したら、必要な到着前情報を搬送先の救急部門に送信できます。
病院にとっては、救急車が救急入口に着いてから準備を始めるよりも、どのような患者が来るのかを10分前に把握できる方がはるかに有用です。指令員にとっても、走行距離だけで搬送先を選ぶより、その病院が現在その種類の救急患者を受け入れられるかどうかを知る方が実務的です。
ここには重要な境界があります。緊急指揮システムが電子カルテ全体を複製する必要はありません。指令判断に必要なのは通常、事案の優先度、患者数、大まかな臨床区分、到着予定時刻、病院の受入状況といった運用情報です。詳細な診療記録は適切な医療システムに残し、対応するアクセス制御方針で管理すべきです。
つまり、EMSと緊急指揮を統合する目的は、すべての医療データを一つのプラットフォームに集めることではありません。対応に実際に参加している人が、自分の役割を果たすために必要な情報を、必要な時点で受け取れるようにすることです。
EMSは一つのネットワークではなく、複数の通信経路に依存する
EMSの現場通信は、もともと一つのネットワークだけに依存してきたわけではありません。救急隊員はミッションクリティカル無線で指令と連絡しながら、携帯データ通信で位置や任務状態を更新することがあります。病院は固定電話、IP音声、自院の臨床アプリを利用する場合があります。大規模事案では、消防、警察、緊急事態管理機関、追加の医療機関が、それぞれ異なる端末や通信システムで対応に参加することがあります。
そのため、緊急指揮のアーキテクチャを「全員に同じアプリを配る」ことに単純化してはいけません。異なる利用者が異なる端末やネットワークを使い続けても構いません。重要なのは、指揮層がそれらの通信関係を一つにまとめられるかどうかです。
通常の案件では、指令員がグループ音声、個別通話、メッセージを使って割当を調整できます。複数機関が対応する場合は、EMS、消防、現場指揮要員を同じ運用会話に参加させる一時的な通信グループを作成できることが望まれます。
重要な通信は、タイムスタンプ、指令員の操作、関連する通話記録を含めて事案と関連付けておき、必要に応じて後から事案全体を再構成できるようにするべきです。
医療緊急時には優先制御が特に重要です。通常通信が緊急事案を妨げてはいけません。重大事案が発生したとき、指揮センターは関連する通話グループやセッションを優先し、必要に応じて病院、監督者、地域緊急オペレーションセンターを参加させられる必要があります。
ネットワークの耐障害性も重要です。携帯データ通信は地図、映像、構造化された状態更新に便利ですが、混雑時や圏外では重要な音声通信が専用無線に依存することがあります。堅牢なEMS通信アーキテクチャは、一つのネットワークが常に利用できるとは想定しません。主系・予備系の通信経路を用意し、ネットワーク状態が悪化したときに段階的に縮退運転へ移行できるようにします。
医療分野は緊急指揮システムにより高い要件を求める
一般的な自治体向け緊急指令プラットフォームを調整なしで医療現場へそのまま導入しても、うまく機能する可能性は高くありません。医療対応には速度が必要ですが、情報アクセス、サービス継続性、説明責任についてもより厳しい要件があります。
第一の要件はロールベースのアクセス制御です。救急車運転者、救急隊員、指令員、救急部門スタッフ、指揮要員が同じ情報にアクセスする必要はありません。すべての端末からすべての事案と患者記録を見られるようにするのではなく、各役割に必要な機能とデータだけを表示すべきです。
第二の要件はデータ最小化です。GIS位置、隊の状態、事案優先度は運用上有用ですが、患者の身元や詳細な臨床情報は正当な必要性がある場合にのみ表示すべきです。システム設計は、技術的に収集・配布できるからという理由ではなく、「誰がこのデータを必要としているのか、なぜ必要なのか」という問いから始める必要があります。
追跡可能性も同様に重要です。出動指令、再割当、到着、病院選択、通信、大きな状態変更は、後の品質評価や説明責任に重要になる可能性があります。プラットフォームは事案の完全な時系列を再構成し、なぜその隊が選ばれたのか、いつ搬送先が変更されたのか、誰が重要な判断に参加したのかを示せるべきです。
最後の要件は運用継続性です。EMSはシステム保守中だからといってサービスを止められません。中核の指令、音声通信、隊状態機能は、サーバ障害、ネットワーク停止、停電、さらには主要指令センターの喪失まで想定する必要があります。重要業務には、文書化された代替手順や縮退運用手順が必要です。
将来的に病院救急システム、電子的な患者ケア記録、その他の医療アプリを統合する必要がある場合は、APIや標準化されたデータ交換インターフェースを利用できます。ただし、そのインターフェースは実際の緊急対応ワークフローに合わせて設計し、緊急指揮プラットフォームに病院情報システムのすべての機能を複製させるべきではありません。
結論：指揮システムとはビデオウォールではなく、都市から病院までの対応チェーンである
スクラントンが市営救急車を追加する計画は、単に3台の車両を増やす以上の意味を持ちます。多くの都市が最終的に直面する問いを示しています。公営と民間のEMSリソースが同じ地域で活動するとき、平時は車両、人員、通信システムを別々に維持し、事案発生後に手作業で調整するのではなく、実際の緊急時にどうすれば一体となって動けるのでしょうか。
答えは救急車の調達リストにはありません。緊急指令と指揮のアーキテクチャにあります。適切に設計された指揮システムは、複数組織の車両状態、位置、割当情報を共通の運用画面に集約し、指令員が近さと能力に基づいて隊を選べるようにします。また、通報受付、現場処置、搬送、病院への引き継ぎを一つの連続した情報チェーンとしてつなぎ、各参加者が適切な時点で適切な情報を受け取れるようにします。
さらに、無線、携帯通信網、IP音声、モバイル端末を統合し、さまざまなネットワーク条件でも重要通信を維持できます。同時に、医療分野が求めるより厳格なアクセス制御、データ最小化、追跡可能性、業務継続性にも対応しなければなりません。
導入順序も重要です。まず通報受付と指令の責任範囲を明確にします。次に公営・民間のEMSリソースを洗い出します。その後、重要な隊状態、GIS位置、事案IDを標準化します。さらに機関横断の音声、メッセージ、一時的な事案通信を統合します。大型ダッシュボード、分析、高度な可視化はその後に行うべきです。
基盤となるリソース間の関係が統合されていなければ、どれほど見栄えのする指揮センター表示でも、救急車が患者に到着するまでの時間は短くなりません。
公営EMS、民間救急事業者、病院、自治体の緊急対応機関が同じ事案を中心に連携できるようになれば、「統合指揮」は単なるソフトウェア機能ではなく、実際の救急医療対応能力になります。
Becke Telecomは、医療、公共安全、自治体の緊急対応向けに、緊急指揮、指令、ユニファイドコミュニケーションのソリューションを提供しています。公営・民間EMSリソースの統合アクセス、機関横断通信グループの迅速な作成、現場チームと病院の到着前連携、複数のネットワーク経路を使った耐障害性の高い通信を支援できます。
よくある質問
民間救急事業者は、市全体の指揮プラットフォームに参加するために既存の指令システムを置き換える必要がありますか？
必ずしも必要ではありません。多くの場合、より現実的なのは事業者の既存運用システムを残し、API、統合ミドルウェア、指令ゲートウェイを通じて必要な隊状態、位置、割当データだけを同期する方法です。完全に統一されたプラットフォームが必要かどうかは、組織規模、アクセス境界、既存システムによって異なります。
救急車のリアルタイム追跡は、誰でも車両の位置履歴を見られることを意味しますか？
そうあるべきではありません。リアルタイムの車両位置は主に指令と運用管理に使われます。アクセスは役割、機関、事案範囲ごとに制限できます。過去の位置情報の保存と利用も、運用要件、プライバシーポリシー、適用される地域ルールに従って管理すべきです。
緊急指揮プラットフォームは病院の空床状況をすべてリアルタイムで取得する必要がありますか？
通常は必要ありません。病院前救急（EMS）にとって重要なのは、病院が特定の種類の救急患者を受け入れられるか、救急部門に特別な制限があるか、現在のケースにどの搬送指針が適用されるかです。病院のベッド管理システム全体を指令プラットフォーム内に複製する必要は通常ありません。
携帯通信サービスが停止しても、EMS指揮システムは運用を続けられますか？
アーキテクチャによります。重要なEMSシステムでは通常、無線音声、予備ネットワーク、その他の代替通信手段を維持し、ネットワーク停止時の手動指令手順も定めます。データ機能は一時的に制限されることがありますが、重要な指令と音声通信は可能な限り継続できるよう設計すべきです。
