おがわの音♪　第1148版の配信★

 * 救急搬送支援アプリ

東京都で、自宅療養中の人が症状が悪化したので救急車を呼んだところ、受け入れ先が見つかるまで、救急隊員が100箇所以上に電話をしなければならず、結局入院先が見つかるまで8時間かかった、という記事を受けて、Twitterで次のようにつぶやいたところ、大きな反響がありました。

残念なことに、コメントの多くが「医療のことを理解していないエンジニアの独りよがり」というネガティブなもので、日本のインターネット特有の「嫌な部分」を象徴する典型的な「炎上」でした。

ブログを長年書いていて、「炎上」には慣れっこなので、精神的に傷つくことはありませんが、それだけ日本には他人を傷つけることでしか自分の存在意義を見つけられない不幸な人が多いのかと思うと、とても悲しくなります。

しかし、そんな中にも、「こんなアプリが既にある」「アプリはあるけど使われていない」などの建設的な情報も集まって来て、とても良い勉強になりました。

「統合救急搬送情報共有システム（fujitsu.com）」は富士通が開発したクラウドを利用したアプリです。ウェブサイトを見る限りは、一見しっかりと作られているようですが、実際にどのくらい利用されているのか、役に立っているのかは不明です。

「大阪府救急医療搬送支援・情報収集・収集分析システム（ORION）の開発と課題（mhlw.go.jp）」は、大阪市で2013年に導入されたORION（Osaka emergency information Research Intelligent Operation Network system）というシステムにより、搬送困難例（＝たらい回し）の回数を実際に減少させることが可能になったという、良い事例の紹介です。

「救急車の“たらい回し”を解消せよ！佐賀県のiPadを使った取り組み」は、佐賀県で救急車50台にiPadを配備し、ネット経由で病院の受け入れ状況を把握できるようにした仕組み（99さがネット）の紹介です。これが導入されるまでは、救急車は片っ端から病院に電話をかけて受け入れてもらえる病院を探すしかなかったのが、この仕組みの導入で、その手間が大幅に減ったそうです。

しかし、この手のシステムがありながらも、結局は救急隊員が電話を片っぱしからかけて受け入れ先を探さなければいけないのには、それなりの理由があるのだと思います。

せっかくシステム化しても、受け入れ先の病院が忙しい・人手が足りないなどの理由で、空きベッド情報を更新できていない、もしくは、意図的に常に受け入れ不可にして放置してある、などの状況であれば宝の持ち腐れです。

とは言え、実際に運用されているシステムには、現場の声も反映されているので、既存のものをベースに作るのであれば、私が調査した限りでは一番実用的に見える「99さがねっと」を（佐賀県もしくは開発した会社から買い取るなどして）オープンソース化して育てる、もしくは、このシステムと同等の機能を最新の技術（例えば、FirebaseとVue/Reactあたり）で作り直すところから始めるのが良いように思います（「99さがねっと」はフロントエンドは、JQueryで作られています）。

もし、ゼロベースで作るのであれば、なぜ「かたっぱしから電話」というアナログな方法がいまだに使われている理由をちゃんと解析した上で、「電話のように導入しやすく、かつ、電話より少し便利」なシステムを提供し、そこから徐々に改良していく、というのもあると思います。

この手のシステムは、そもそもシステムの導入に抵抗する人が必ずいるし、実際に導入しても期待した通りの使い方をしてくれない人が多いので、まずはシステムの導入の敷居を思いっきり下げ、実際に現場で使いながら少しづつ改良するのが良いと思います。

さまざまな「業務支援システム」が存在する中で、Slackというとてもシンプルなチャットツールが多くの会社で使われ、多くの業務がSlackだけで行われたり、Slackに少し機能を追加しただけで十分だったりする点は、とても参考になると思います。

誤解して欲しくないのですが、私は、Slackが救急医療に使えると主張しているわけではなく、Slackのもつ、使い安さと自由度の高さ（汎用性）が、この手のシステムの導入の敷居を下げるのに参考になると思うのです。

もっとも現実的なアプローチとしては、まずはWebRTCを使った音声チャットシステムを作る、というアプローチです。

アプリを開くと、近い順に救急医療病院が表示され、それをタップするだけで、電話とほぼ同じ感覚で、病院のオペレータと音声で会話することが出来るというシステムです。

これだけだと、電話をかけるのとほとんど変わりませんが、「まずはシステム導入の敷居を下げる」ことを優先するのであれば、最初は、これぐらいの機能で十分だと思えます。

救急隊員にとっては、近い順に病院が表示される、受け入れを拒否された病院に印が出来る、受け入れを受理してくれた病院への地図が表示される、ぐらいの「小さなメリット」を提供するだけで十分だと思います。そんなシステムであれば、電話とほとんど使い方は同じで、（少ないながらも）メリットだけしか見えないので、（救急隊員にとっての）導入コストが低く抑えられます。

このシステムがあるだけで、「どの病院がどのくらいの頻度で救急患者の受け入れを受理・拒否したのか」の履歴がデータベースに残るので、地方自治体から、その成績に従って報奨金などのインセンティブを与えるとか、成績の悪いところに業務改善命令を出す、などが可能になります。

病院側にも、救急医療の時間ごとのニーズが可視化されるので、ニーズに合わせた医療スタッフの配置などがやりやすくなります。

素晴らしいのは、病院側の手間を省略するため、過去24時間の搬送実績から、病院の受け入れ状況を予測する仕組みを導入している点で、これはとても参考になります。

このシステムの導入により、「搬送時間を平均で1分短縮した」「運営費を年4,000万円節約した」などの結果を出しており、他の自治体の人たちにとっても良い教材になると思います。

そして、こんなシステムが十分に現場で受け入れられてから、「ビデオ通話も出来るようにする」「電話の代わりにボタン一つで病院にリクエストを出す」「複数の病院に対して、同時にリクエストを出す」「患者のニーズに応じて病院のリストにフィルターをかける」「（佐賀県のシステムのように）過去の履歴から、受け入れ体制を予測して表示する」「病院側から能動的に受け入れの可否を指定できる」などの機能を追加して行けば良いのです。

こんなシステムを作って、実際に運用しデータを集めると現行の救急システムの問題点（「たらい回し」の頻度、救急医療施設として役に立っていない病院の存在など）が可視化され、最終的には現状を打破するためには救急病院のありかたそのものに踏み込んで、法改正や診療報酬から抜本的に見直す必要がある、という結論に至ると容易に想像出来ます。

せっかくシステム作りをするのであれば、最初からそこまで見据えた上で、取り掛かるべきだと思います。つまり、「IT化により、一気に問題を解決する」のではなく、「IT化により、少しづつ便利にしながら、現行の救急医療体制の問題点を可視化し、法改正を含めた抜本的な解決」を目指すべきなのです。

ちなみに、大切なことは、人月工数で稼いでいるITゼネコンにこの手のシステム開発の丸投げをしないことです。彼らに頼むと、どうしても何年に一回は大幅な作り直しが必要になり、そのたびに随意契約で法外なお金を取られることになります。

この手のシステムこそ、救急車一台・救急病院一つあたり、月額いくらのSaaS（Software as a Service）として開発・提供されるべきシステムであり、ベンダーロックインを避けるためにも、オープンソースの形で開発すべきものです。

そして、オープンソースで開発されたものを、各地方自治体の地元のソフトウェア・ベンダーがクラウドを使って運営し、それぞれの地方のニーズに合わせたカスタマイズ、既存のシステムとの繋ぎ込み、機能追加をしながら、協力してオープンソースを育てて行く、という形が理想的だと思います。

アプリの話が、救急医療体制そのものの話になってしまいましたが、本来、ソフトウェア設計とは、そうあるべきなのです。

普段から主張しているように、デジタル・トランフォーメーション（DX）は、既存の業務を自動化するだけでは全く不十分なのです。ソフトウェアは道具でしかなく、究極の目的は業務の抜本的な改善であり、ビジネスイノベーションなのです。

「患者のたらい回し」と「救急隊員による電話のかけまくり」は、単に「電話というアナログツールの効率の悪さ」から来ているものではないので、そこだけソフトウェアを導入しても、根本的な解決には至らないのです。

Amazonが小売業回を根本的に変えてしまったように、「救急医療体制の不備」「病院の経営悪化」「医師・看護師不足」「時代遅れな法律」「歪んだ診療報酬システム」などにまで踏み込んで改革してこそのデジタル・トランスフォーメーションなのです。

※ メール・BLOG の転送厳禁です!!  よろしくお願いします。