今日のNHKでやってたけど、大金はたいて導入した救急医療情報システム（例）が全く活用されていないという問題。どこの腐れベンダーが作ったシステムか知らないけど、システム構築時に想定した運用は「ホゲホゲ内科 ○」みたいなのをマウスで延々入力して、時々刻々と変化する状況を常にアップデートするというもの。病院のナースステーション？らしきところの部屋の隅っこで、しょぼーいノートPCと、それにくくりつけられた専用端末らしき物体のくすみ具合が哀愁を誘います。二つしか救急受付病院がない小豆島にも導入されていたというのだから、もうどこかのITゼネコンが公共事業でやったとしか思えない気がしてきます。
いやしかし、1983年の時点では、少なくとも希望溢れるものであったらしい。論文読んだわけじゃないけど。
例えば松江圏域。救急車を受け入れる医療機関は３または４。その大半は日赤と市立でしょう。そんなシステムにつなぐより、電話した方が早いし、引き続き病院に情報が伝達できます。そんな情報システムに無駄なカネを使っていないという意味で島根県は「正しい」ということでしょう。山形、沖縄も地域性を考えれば同様でしょう。（その医療圏に救急車を受け入れ可能な医療機関はごく少数ということ）
さてさて、真面目にこの問題を考えるのであれば、地域の各地で不定期に発生する患者を、地域に点在する消防車を使って、地域の限られた病院へ効率的に輸送する問題です。そのときに、あちこちをたらいまわしにされて無駄なジプシー時間を過ごさないために、なるべくリアルタイムで病院の情報（救急車にとって、患者を運ぶゴール）を共有することが目的です。
病院の中の人は基本的に忙しいので、人手による情報の電子化はまず期待できないでしょう。その手段としては、設置カメラによる定点観測、センサーネットワークによる人間の動き、予めICタグを付与した患者や医師・看護師の位置の把握、予めICタグを付与した医療機器の動作状況、医療消耗品の消費速度*1、ICUの利用率とか、病床数等のキャパシティの事前把握など、とにかくいろいろな要素が考えられます。この要素の選定だけでも一朝一夕にはいかないでしょうが、最新の工学技術を使えば不可能ではないと思います。
次に、電子化された生のデータをリアルタイムで構造化し、「何人(0または1以上)の患者を受け入れ可能なのか」という情報をリアルタイムで救急車に配信することが考えられます。配信に関しては、自動車のネットワーク化（自動車に配信するデータ量自体はさほど多くはないので、携帯電話レベルの帯域でも十分かと）はすぐできそうですが、生データの構造化は難しそうです。つまり病院で観測された生データとは、動画情報や、ICタグなどセンサネットワークの解析などです。
救急車が各病院の状況をリアルタイムで瞬時に把握できるようになれば、次は計画を考えられるでしょう。つまり、各病院の状況と、現在の全救急車が担当している救急患者を照らし合わせれば、それぞれの救急車が向かうべき病院を計画（あるいは、救急車と病院が交渉）できるでしょう。さらに、この計画の過程で、現在の街の道路混雑の状態も考慮して、病院までの到着予想時刻も計算できればさらによいでしょう。
このとき、留意しなければならない点はいくつかあります。無停止のシステムであること、安定した通信を確保できること等は当然ですが、何よりも端末のユーザインタフェースの使いやすさが重視されるべきでしょう。換言すれば、ユーザインタフェースに対してもシビアな品質がここまで要求される分野というのも、他にはそうないのではないでしょうか。機器を利用するのは、一分一秒を争う救急救命士や救急車の運転手、あるいは病院の看護師などです。彼らは常にギリギリのタイミングで判断を要求されています。このような状態で、マウスやキーボードが使えるでしょうか？ タッチスクリーンにしたとして、必要な状況で必要なメニューだけが画面に表示されるでしょうか？ システムが、インターフェースが、彼らに迷いや困惑を与えてはなりません。理想的なのは映画「マトリックス」に登場したようなBMIですが…。
さすがにBMIはまだ非現実的ですが、ギリギリまで自動化できないと、救急医療のような即時性が要求される分野での電子システムは使い物にならないでしょう。これだけのSIができる会社が日本にいくつありますかね。
これだけ一生懸命考えましたが、救急車も病院もある程度数がある場所じゃないと、導入する意味はないです（当たり前）。
*1:ガーゼの消費速度とか、輸血の速度とか
