JP6052875B2 - 救急医療管制支援システム及びサーバ並びに携帯端末 - Google Patents

Description

本発明は、救急医療管制支援システム及びサーバ並びに携帯端末に関する。

現在、救急医療の評価指標として総務省が発表する「救急車による搬送時間（通報から病院収容までの時間）」が使われる事が多い。しかしながら、この指標は救急医療の一側面をとらえているに過ぎない。救急医療はリレーに例えられるが、この指標は、救急リレーにおける第二走者のラップタイムを短くすることだけに注力しているようなもので、走者間のバトンパスワークなどを無視したものになりかねない。本来は、医学的にも「発症から治療開始までの時間」、即ちリレー走者の合計タイムが唯一の指標になるべきである。この指標を活用するためには、消防側の「発症〜病院到着まで」の時間と、医療機関が持っている「病院到着から治療開始まで」の時間を統合する必要があるが、現在、救急医療情報システム（病院前）と医療機関における診療記録（病院情報システム）とではデータの統合が全く行われていないのが実状である。

さらに、医療の高度化・専門化が進むにつれて、「当直医の専門性」によって治療できる疾患が異なってくる。例えば、同じ外科であっても、脳神経外科の専門医は腹部の手術はできないし、腹部外科の専門医は心臓の手術はできない。従って、救急医療のマッチングでは、「治療を必要とする患者」を「治療ができる病院」に搬送することは重要である。しかしながら、依然として、救急隊の中には「直近搬送（一番、最寄りの医療機関に搬送すること）」が根付いている。即ち、救急隊は直近搬送以外の尺度を持たない。同時に、救急隊は「直近搬送」をしない理由が分からない。「１０分離れているけど、Ａという疾患であれば、そちらの医療機関に搬送すべき」という明確なルールが存在しない。

一方、昨年改正された消防法では、各都道府県に重症度・緊急度に応じた搬送基準の策定と搬送先医療機関リストの作成を求めている。この搬送先医療機関リストは、各医療機関の「立候補」で決まるべきものではなく、本来は、各医療機関の「客観的な評価」に基づくべきものである。そのためには、各医療機関が、同じ基準で「医療の質指標」を算出し、客観的な評価をしていく必要がある。

さらに、現在、消防は市町村の事業であるため、各消防本部の情報システムが独立に運用されている。例えば、奈良県では１３の消防本部があるが、それらの間で搬送データの共有はされていない。つまり、隣の市であっても、奈良市消防の活動状況を生駒市の消防は全く分からないといった状況が生まれている。

また、救急隊と医療機関同士の確執も問題となっている。即ち、医療機関では「受けられない傷病」に関する問い合わせを何度も受けること、少し前に救急患者を受け入れて現在多忙にも関わらず別な救急隊からの問い合わせを受けること、更には、「軽傷だから」と言って重症患者を運んでこられる等、が起こっている。これらは、直近搬送文化、各消防本部におけるデータ共有がないこと、に起因しているが、医療機関では、これらが繰り返されることで「疑わしきは断る」という文化ができあがってくる。

さらに、医療機関同士も分断されている。即ち、医療機関も、自施設における状況は分かるが、隣の病院で今どのような患者が来院しているのか、どのような処置や手術が行われているのか、今晩入院するような重症患者がいるのか、などは分からない。従って、救急隊からの患者受け入れの依頼を断る場合にも「どこかが受けてくれるだろう」といった具合に考えてしまう医療機関が多い。

ところで、医療機関のベッドやリソースの空き状況を医療機関が各診療科毎、或いは専門性毎に「○」「×」などで表示し、救急隊はそのサインを元に搬送先を判断するシステムを一般に応需システムと呼んでいる。しかし、現在の応需システムは、「救急治療室と離れた場所にあり入力が面倒」、「実際にはそのときの状況や患者の状態などで総合的に受入を判断するために一概に○や×にできない」、「結局、直近搬送で×であっても電話がかかってくる」・・・という事からほとんど利用されていない。例えば、ある自治体の消化管出血搬送事例をみると、応需システム上、○をつけている医療機関と、×をつけている医療機関への照会回数がほぼ同数であった。また、1日に発生した患者数より、応需システム上○をつけている医療機関が多いにもかかわらず、問い合わせに対し半数以上で受入が断られていた。

地域に救急医療施設が少ない場合、その施設がほぼ１００％患者を受け入れることで、受入困難が発生していない施設においても、改正消防法に基づいて各都道府県が策定した「搬送実施基準」の医療機関分類（リスト）に掲載されている医療機関における医療の質指標（臨床指標）の評価や、観察基準や選定基準の精度の評価を行うためには、病院前の観察データと急性期医療機関における診療データを統合する必要がある。

さらに、現在、各消防局・本部・組合はそれぞれに別個にデータを管理しているが、地域における救急医療の状況を適切に把握するためには、これらのデータを統合する必要があり、消防の情報レベルでの広域化が必要となる。

このように現状で起こっているのは、救急医療全体を見通す視点の欠如に尽きると言っても過言ではない。

ここで、特許文献１では、救急医療サーバが、患者発生前に救急搬送先の病院の受入状況を常に把握しており、救急車から救急医療申請があった時点において最適な医療機関を検索することができる救急医療システムが開示されている。

特開２００９−１８７１６７号公報

しかしながら、以上の課題を整理すると、救急医療管制支援システムでは以下の事が実現される必要がある。
・ 質指標による医療機関ごとの診療機能、プロセス、アウトカムの見える化
・ 救急医療情報と医療機関情報の統合と診療連携状況の見える化
・ 各消防本部における救急医療情報の統合による地域全体の救急医療の見える化
・ 多忙な救急関係者の手間がかからない情報共有の仕組み
・ 重症度・救急度に基づいて適切な搬送先を決定するための意思決定支援
・ システムの評価とＰＤＳＡサイクルを回すための情報提供

そこで、本発明は上述の技術的な課題に鑑み、救急隊と医療機関が「同じ情報」を元に意志決定することで、納得のいく意志決定ができ、全県レベルの救急医療情報を全ての救急関係者が知ることで、状況に応じた最適の意志決定を可能とし、結果として、搬送時間や「発症から治療開始までの時間」を短縮させ、患者の予後が改善し、搬送基準や病院リストの妥当性と信頼性を定期的に評価し、改善できる救急医療管制支援システム及びサーバ並びに携帯端末を提供することを目的とする。

上述技術的な課題を解決するため、本発明の第１の態様では、ネットワークを介して携帯端末と所定の認証の後に通信自在なサーバであって、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備えたことを特徴とするサーバが提供される。

また、本発明の第２の態様では、携帯端末と、上記携帯端末とネットワークを介して通信自在な連携サーバと、統計サーバと、からなる救急医療管制支援システムであって、上記連携サーバは、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、上記登録された情報と各自治体で決められた所定の基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備え、上記統計サーバは、取得したタイムスタンプや登録された情報に基づいて所定の報告書を自動的且つ定期的に作成し、上記サーバの上記重症度判定部により、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御することを特徴とする救急医療管制支援システムが提供される。

また、本発明の第３の態様では、ネットワークを介してサーバと所定の認証の後に通信自在な携帯端末あって、全体の制御を司る主制御部と、上記通信を行う通信制御部と、画面データに基づく表示制御を行う表示制御部と、出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントの入力を受け付ける入力部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、表示を行う表示部と、を備え、上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして上記表示部に表示するよう制御することを特徴とする携帯端末が提供される。

このほか、救急隊における観察や処置の結果を搬送先候補となる医療機関と情報共有できる仕組みを提供できる。さらに、地域全体における患者の発生状況や、急性期医療機関の診療状況を関係者全員が共有できる仕組みを提供できる。そして、救急搬送された患者の診療記録を統合する仕組みを提供できる。

本発明に係る救急医療管制支援システム及びサーバ並びに携帯端末によれば、救急隊と医療機関が「同じ情報」を元に意志決定することで、納得のいく意志決定ができ、全県レベルの救急医療の状況を全ての救急関係者が知ることで、状況に応じた最適の意志決定を可能とし、結果として、搬送時間や「発症から治療開始までの時間」を短縮させ、患者の予後が改善し、搬送基準や病院リストの妥当性と信頼性を定期的に評価し、改善できる。

本発明の一実施形態に係る救急医療管制支援システムのネットワークのイメージ図である。 救急医療管制支援システムで利用する端末と、それぞれの端末からサーバへのアクセス形態を示す図である。 接続形式と端末の形態、インターネットへの接続、利用者が対比してまとめられている図である。 この発明の一実施形態に係る救急医療管制支援システムのシステム面におけるセキュリティ対策の概要を示す図である。 本発明の一実施形態に係る救急医療管制支援システムのサーバ構成を示す図である。 本発明の一実施形態に係る救急医療管制支援システムによる処理手順を詳細に示すフローチャートである。 データベースの構成を示す図である。 患者リスト４０１の構成を示す図である。 既往症リスト４０２の構成を示す図である。 搬送リスト４０３の構成を示す図である。 患者搬送指示リスト４０４の構成を示す図である。 患者状態詳細リスト４０５の構成を示す図である。 端末側病院状態リスト作成依頼リスト４０６の構成を示す図である。 搬送救急隊員リスト４０７の構成を示す図である。 救急隊処置記録リスト４０８の構成を示す図である。 受入要請リスト４０９の構成を示す図である。 転送受入要請リスト４１０の構成を示す図である。 端末側病院状況リスト４１１の構成を示す図である。 搬送先病院リスト４１２の構成を示す図である。 受入リスト４１３の構成を示す図である。 処置詳細リスト４１４の構成を示す図である。 病院状況リスト４１５、病院スケジュール管理情報リスト４１６、病院スケジュール詳細情報リスト４１７、輪番情報リスト４１８の構成を示す図である。 重症度、緊急度の判定アルゴリズムの一例を説明するフローチャートである。 出動〜現着画面５０１の表示例を示す図である。 初期分岐画面５０２の表示例を示す図である。 意識状態入力パネル５０３の表示例を示す図である。 血圧入力パネル５０４の表示例を示す図である。 脈拍入力パネル５０５の表示例を示す図である。 呼吸入力パネル５０６の表示例を示す図である。 体温入力パネル５０７の表示例を示す図である。 ＳｐＯ２入力パネル５０８の表示例を示す図である。 受入可否状況画面５０９の表示例を示す図である。 伝達項目パネル５１０の表示例を示す図である。 受入可否入力画面５１１の表示例を示す図である。 背景・搬送元入力パネル５１２の表示例を示す図である。 受入困難事由入力パネル５１３の表示例を示す図である。 病院側の入力画面６００の一例を示す図である。 救急患者発生マップの表示画面６０１を示す図である。 作成された各医療機関の日報の一例を示す図である。 携帯端末２００の詳細な構成を示す図である。

以下、本発明の救急医療管制支援システムに係る好適な実施形態について図面を参照しながら説明する。なお、本発明の救急医療管制支援システムは、以下の記述に限定されるものではなく、本発明の要旨を逸脱しない範囲において、適宜変更可能である。

図１には、本発明の一実施形態に係る救急医療管制支援システムのネットワークのイメージ図を示し説明する。

この図１に示されるように、指令本部にはノートブックやデスクトップ等の情報端末１０１ａやタッチパネル式端末１０１ｂが設置されており、光ファイバ、ケーブル、ＡＤＳＬ等或いは３Ｇ携帯網を介してインターネット網１０６に接続されている。住民は、ノートブック等の情報端末１０２を用い、光ファイバ、ケーブル、ＡＤＳＬを介してインターネット網１０６に接続する。また、医療機関（事務）は、ノートブック等の情報端末１０３ａやタッチパネル式端末１０３ｂを用いて、光ファイバ、ケーブル、ＡＤＳＬ等或いは３Ｇ携帯網を介してインターネット網１０６に接続する。医師・看護師は、タッチパネル式端末１０４を用いて、ワイヤレスＬＡＮ（院内）と、光ファイバ、ケーブル、ＡＤＳＬ等を介して、或いは３Ｇ携帯網を介して、インターネット網１０６に接続する。

実装するプログラムは、（１）主に携帯端末で利用するシンクライアント（純粋なＳａａＳ（Software As A Service）で、ブラウザ上で動かし、ほとんどのアルゴリズムはサーバ上で稼働する）、（２）リッチクライアント（フレームワークをインストールし、コンテンツを適宜、ダウンロードし、多くのアルゴリズムはクライアントで稼働する）の２種類である。双方とも特定ベンダーのネットワークの利用に拘ることなく、一般的な接続形態での接続を可能にする。但し、リッチクライアントの携帯端末は、救急隊による日常利用に耐え得る強固な構造の端末であることが望ましく、この端末で接続可能な３Ｇ携帯電話ネットワーク（例えばFOMA、WiMAX、イーモバイル等）であるＷＡＮ（Wide Area Network）を選ぶことになる。

シンクライアントは、通常のノートブック或いはデスクトップよりのアクセスを想定しており、各種固定回線（ISDN、ADSL、CATV、光ファイバ等）のいずれでも対応可能な設計とする。但し、医療機関の多くが院内端末からのインターネットへの接続を制限している現状を考えると、医療機関内からのアクセスには、上記のＷＡＮへの接続形式も選択肢とする必要があり、CATVが主なネットワークインフラである地域では、将来的な拡張にあたってはこれらも考慮する。

図２には、救急医療管制支援システムで利用する端末と、それぞれの端末から連携サーバへのアクセス形態を示し説明する。前述したように、救急隊・医療機関では３Ｇ携帯電話ネットワークに接続できる強固な構造の端末を利用し、その他ではノートブック・デスクトップなどのＰＣ端末の利用を想定している。将来的には、一部情報への一般住民からのアクセスを予定しており、その際には、携帯電話端末やＰＤＡ等からのアクセスも考慮する。

図３には、接続形式と端末の形態、インターネットへの接続、利用者が対比してまとめられている。即ち、シンクライアント（Thin-Client）は、端末の形態としてはノートブックやデスクトップが採用され、インターネットへは光ファイバ・ケーブル・ＡＤＳＬにより接続する。利用者としては、指令本部、住民に好適である。一方、リッチクライアント（Rich-Client）は、端末の形態としてはタッチパネル式端末が採用され、３Ｇ携帯ネットワークを介してインターネットに接続する。利用者としては、救急隊に特に好適であり、指令本部、医療機関でも利用されるが、住民には利用されにくい。

図４には、この発明の一実施形態に係る救急医療管制支援システムのシステム面におけるセキュリティ対策の概要を示している。同図に示されるように、この救急医療システムのセキュリティは、以下の５つのレベルで確保する。

・ 端末２００へのアクセス
端末２００には許可を得た個人のみアクセスを許可する。例えば、IDとパスワード、バーコード、ＩＣカード、指紋などの認証システムを活用する。

・ ＷＷＷサーバ２０１へのアクセス
原則、ＩＤとパスワードによるアクセス制限を行う。携帯端末２００とサーバはデジタルＩＤによる認証を行う。データの送受信は全てＳＳＬで暗号化する。

・ データベースサーバ２０２へのアクセス
データベースサーバ２０２は、医療機関の患者データが保管できるレベルの物理的、電子的セキュリティを確保する。データベースサーバ２０２には、上記のＷＷＷサーバ２０１のＩＰアドレスからのアクセスのみを許可する。

・ データ２０３の管理
全ての個人特定可能なデータ（例えば、米国HIPAAのProtected Health Informationに相当するもの）は暗号化して保管する。

・ 統計サーバ２０４におけるデータの管理
統計サーバ２０４では、全てのデータを匿名化する。元のデータと連結を可能にする連結テーブルは暗号化・アクセス制限機能を持ったＵＳＢに保管し、物理的にロックされた保管庫に保管する。

また、この救急医療システムは、以下の汎用性・モデル性を有する。

・ クラウドを利用することによるスケーラビリティ
この救急医療システムは、患者のデータを保管できるレベルのセキュリティをもったデータセンターにアクセスして利用するタイプのSaaSの形態をとる。携帯端末２００のメンテナンス、ソフトウェアやコンテンツのアップデートについても一元管理を行うことで各施設におけるメンテナンスのコストを削減できる。

・ 医学的なコンセンサスに基づく共有すべき情報の標準化
過去において様々な救急システムにおいて収集された情報は、論理ベースに基づかず、地域によってまちまちの運用であることが多かった。また、論理に基づかないため、集めたデータが活用されていない場面もあった。この救急医療システムでは、病院実績に基づいた搬送先のリストと、医学的なコンセンサスに基づいた搬送ルールを実装する。これらのリストとルールの作成は医療の質マネジメントに基く。

・ ベンダー、ＯＳ、ハードウェアに依存しないオープンな設計
データレベルではなく、情報レベルでの標準化を行うことで、各医療機関に導入されている医療情報システムがどのようなものであれ、「その情報を抽出するために必要なデータ」を得ることで医療情報システムのベンダーからフリーの設計が可能である。利用する携帯端末２００には、シンクライアントと、リッチクライアントを開発する。シンクライアントは一般的なブラウザで稼働する予定で、リッチクライアントも一般的なＯＳ（MacOS10.5以降、Windows(登録商標) XPあるいはWindows(登録商標)7など）で稼働するように設計する。

次に、図５には、本発明の一実施形態に係る救急医療システムの連携サーバの構成を示し説明する。尚、この連携サーバは、図４のｗｗｗサーバ２０１及びデータベースサーバ２０２を概念上含むものである。同図に示されるように、連携サーバ３００は、制御部３０１と通信制御部３０２、記憶部３０３を有した構成となっている。制御部３０１は、制御プログラムを実行することで、主制御部３０１ａ、表示制御部３０１ｂ、タイムスタンプ取得部３０１ｃ、情報登録部３０１ｄ、重症度判定部３０１ｅ、リスト作成部３０１ｆとして機能する。主制御部３０１ａは、全体の制御を司る。表示制御部３０１ｂは、端末における画面表示を制御するよう画面データを生成する。タイムスタンプ取得部３０１ｃは、端末からの出動、現場到着等といったイベントを検出しタイムスタンプを取得する。情報登録部３０１ｄは、救急隊や医療機関等からの情報登録を受け付ける。重症度判定部３０１ｅは、上記登録された情報や後述する指標に基づいて患者の重症度を算出する。リスト作成部３０１ｆは、上記登録された情報等に基づいて本日の病院の活動状況を示すリスト等を作成する。尚、先に図４に示した統計サーバ２０４は、全てのタイムスタンプやデータをレポジトリとして保管しており、取得したタイムスタンプや上記登録された情報等に基づいて所定の指標（特性、プロセス、連携）を算出し、消防機関、医療機関へのフィードバック、及び行政や住民への情報提供を可能にする。

以下、図６のフローチャートを参照して、本発明の一実施形態に係る救急医療管制支援システムによる処理手順を詳細に説明する。なお、救急隊の記録は、タッチパネルのボタンを押した時点でタイムスタンプとして記録される。すべての記録は「搬送先医療機関」の端末によりリアルタイムで閲覧可能である。

住民から通報がなされると（Ｓ１）、サーバは、患者の年齢、性別、状態などのデータを移行する（Ｓ２）。このデータの移行後に、救急隊は出動する。このとき、端末の出動ボタンが押下され（Ｓ３）、サーバは出動に関するタイムスタンプを記録する（Ｓ４）。

その後、救急隊は現場に到着すると、端末の現場到着ボタンが押下され（Ｓ５）、サーバは現場到着に関するタイムスタンプを記録する（Ｓ６）。救急隊は、現場において、患者の既往歴、現病歴、身体所見の中で「重症度・緊急度」の判定に必要なデータを記録する（Ｓ７）。この記録されたデータに基づいて、サーバにおいて、各自治体で決められている「傷病者の搬送及び受入れの実施基準等」に基づいて内部に組み込まれた重症度・緊急度判定アルゴリズムにより重症度の判定が行われる（Ｓ８）。

サーバは、重症度、緊急度の判断と、事前に登録されている医療機関の特性とリストに基づいて搬送対応医療機関一覧を、現場からの距離および各医療機関の繁忙度でソートした形で表示する（Ｓ９）。救急隊の端末では、搬送先候補一覧が表示される（Ｓ１０）。この一覧には、当日の各医療機関の状況がリアルタイムで反映されており、多忙な医療機関を避けた連絡を行うことを可能ならしめる。救急隊は、この搬送先候補一覧を見て、医療機関に連絡をする（Ｓ１１）。医療機関は患者の受け入れに関する意思決定を行い、その結果はサーバに通知される（Ｓ１２）。サーバでは、この通知に基づいて、リストを更新する（Ｓ１３）。このように、医療機関と緊急隊は同じ情報（県内における患者の発生状況、各医療機関の多忙さ、患者の状態など）を共有しながら、最適の決断をすることになる。なお、救急隊が問い合わせた時点で、医療機関の状況によって受入困難が生じている場合、救急隊がタッチすることで、その情報を共有できる。

こうして、救急隊は、現場を出発（現発）する。そのときに端末の現発ボタンが押下されると（Ｓ１４）、サーバは現場出発に関するタイムスタンプを記録する（Ｓ１５）。さらに、救急隊は、病院に到着する（病着）。そのときに端末の病着ボタンが押下されると（Ｓ１６）、サーバは病着に関するタイムスタンプを記録する（Ｓ１７）。

医療機関到着後、救急隊が入手している情報は自動的にサーバから医療機関の端末に転送される（Ｓ１８）。この情報は医療機関の端末において表示される（Ｓ１９）。医療機関において、外来診断が確定した時点で、診断ボタンが押下され（Ｓ２０）、サーバは診断内容と診断時間をタイムスタンプで記録する（Ｓ２１）。さらに、処置・手術が行われた場合、処置・手術ボタンが押下され（Ｓ２２）、サーバは処置・手術に関するタイムスタンプを記録する（Ｓ２３）。そして、最終的な転帰が決まった際には転帰ボタンが押下され（Ｓ２４）、サーバは転帰に関するタイムスタンプを記録する（Ｓ２５）。また、このとき、医療機関では、搬送された患者の「診断」、「処置・手術内容」、「転帰」の３項目を入力することでデータの統合と情報共有を実現できる。これら搬送された患者への医療機関の対応に基づいて、予め決められた一定時間の間（例：一般入院対応は1時間、腹部の手術は3時間・・・など）はその医療機関が繁忙であることをサーバに記録し、関係者の間でその情報を共有すると同時に、医療機関選定用リストにその旨を表示する。

こうして、蓄積された情報に基づいて各種の指標が作成され、その後、当該情報が共有されることになる（Ｓ２６）。こうして、一連の処理を終了する。なお、各種指標とは、搬送ルールの検証や、医療機関が適切に患者の受け入れを行っているかどうかに関するものであり、基本的なものは予めコンテンツとして実装するが、追加・更新は可能である。

ここで、図７乃至図２２には、データベースの構成を示し説明する。

これらの図に示されるように、データベースとしては、患者リスト４０１、既往症リスト４０２、搬送リスト４０３、患者搬送指示リスト４０４、患者状態詳細リスト４０５、端末側病院状況リスト作成依頼リスト４０６、搬送救急隊員リスト４０７、救急隊処置記録リスト４０８、受入要請リスト４０９、転送受入要請リスト４１０、端末側病院状況リスト４１１、搬送先病院リスト４１２、受入リスト４１３、処置詳細リスト４１４、病院状況リスト４１５、病院スケジュール管理情報リスト４１６、病院スケジュール詳細情報リスト４１７、輪番情報リスト４１８、がテーブル方式で蓄積されている。

尚、図７において"１"，"０"で示したのは、１は０に対して必須のリストであるが、０は１に対して必ずしも必須ではないとのエンティティの関係を示している。

より詳細には、患者リスト４０１（図８参照）では、患者No、患者状態区分、患者年齢、患者性別区分、患者氏名、患者生年月日、心肺停止有無区分、吐血有無区分、飲酒有無区分、搬送困難有無区分、腹痛有無区分、意識障害有無区分が対応付けられており、さらに既往症リスト４０２、搬送リスト４０３、患者搬送指示リスト４０４、患者状態詳細リスト４０５が紐付けられている。なお、患者リスト４０１の項目は、追加、削除、統合などが適宜可能である。これは、以下に述べる他のリストについても同様である。既往症リスト４０２（図９参照）では、既往症No、既往症状態区分、既往症、病院名、病院No、患者Noが対応付けられている。

そして、搬送リスト４０３（図１０参照）では、搬送No、搬送状態区分、発生場所、現場住所、現場緯度、現場経度、出動要請日時、搬送動態区分、救急車No、患者No、出動日時、端末側病院状況リスト作成依頼No、現着日時、搬送切分区分、病着日時、病発日時、帰署日時、発生日時が対応付けられており、更に、搬送救急隊員リスト４０７、救急隊処置記録リスト４０８、受入要請リスト４０９が紐付けられている。また、患者搬送指示リスト４０４（図１１参照）では、患者搬送指示No、患者搬送指示状態区分、出動指令No、通報者氏名、通報者性別区分、通報者関係区分、覚知方法区分、携帯転送受内容、覚知日時、通報内容詳細、搬送転送区分、消防本部No、患者No、依頼元病院No、端末側病院状況リスト作成依頼Noは対応付けられており、更に転送受入要請リスト４１０が紐付けられている。

さらに、患者状態詳細リスト４０５（図１２参照）では、患者状態詳細No、患者状態詳細状態区分、項目種別区分、ＪＣＳ、ＧＣＳ＿Ｅ、ＧＣＳ＿Ｖ、ＧＣＳ＿Ｍ、最高血圧、最低血圧、呼吸数、脈拍数、体温、ＳｐＯ２、心電図区分、左瞳孔、右瞳孔、左対光反射区分、右対光反射区分、患者Noが対応付けられている。端末側病院状況リスト作成依頼リスト４０６（図１３参照）では、端末側病院状況リスト作成依頼No、端末側病院状況リスト作成依頼状態区分、依頼元、搬送No、依頼元病院No、患者搬送指示Noが対応付けられている。搬送救急隊員リスト４０７（図１４参照）では、搬送救急隊員No、搬送救急隊員状態区分、UserNo、搬送Noが対応付けられている。救急隊処置記録リスト４０８（図１５参照）では、救急隊処置記録No、救急隊処理記録状態区分、処置日時、搬送処置区分、搬送Noが対応付けられている。

そして、受入要請リスト４０９（図１６参照）では、受入要請No、受入要請状態区分、受入要請方法区分、受入可否区分、病院No、搬送No、患者No、病院側受入可否区分、受入要請拒否理由区分、受入要請拒否理由、受入要請拒否日時、受入要請拒否理由解除予定日時、受入要請受諾日時、受入要請受諾取消理由区分、受入要請受諾取消理由、受入要請受諾取消日時、病院側受入可否回答日時、受入取消日時が対応付けられている。転送受入要請リスト４１０（図１７参照）では、転送受入要請No、病院No、患者No、受入可否区分、受入要請拒否日時、受入要請拒否理由解除予定日時、受入要請拒否理由区分、受入要請拒否理由、受入要請受諾取消理由区分、受入要請受諾取消理由、受入要請受諾取消日時、病院側受入可否区分、病院側受入可否回答日時、転送受入要請状態区分、受入取消日時、患者搬送指示No、依頼元病院Noが対応付けられている。

さらに、端末側病院状況リスト４１１（図１８参照）では、端末側病院状況リストNo、端末側病院状況リスト状態区分、病院No、心肺停止有無区分、吐血有無区分、下血有無区分、飲酒有無区分、搬送困難有無区分、腹痛有無区分、意識障害有無区分、病院名、病院住所、病院電話番号、診療休止中区分、次回診療開始時刻、端末側病院状況リスト作成依頼No、距離、症状徴候別医療機関選定区分が対応付けられている。搬送先病院リスト４１２（図１９参照）では、搬送先病院リストNo、搬送先病院リスト状態区分、病院No、病院名、病院住所、病院電話番号、端末側病院状況リストNo、搬送先選択区分が対応付けられている。

そして、受入リスト４１３（図２０参照）では、受入No、病院No、患者No、受入状態区分、患者ベッドＩＤ、患者受入詳細区分、医師No、受入要請No、受入日時、救急診断名、最終診断名、受入患者転帰区分、転帰日時、転送受入要請Noが対応付けられており、更に処理詳細リスト４１４が紐付けられている。そして、この処置詳細リスト４１４（図２１参照）では、処置詳細No、処置詳細状態区分、処理区分、処理開始日時、処理終了予定日時、処置終了日時、受入Noが対応付けられている。

さらに、病院状況リスト４１５（図２２参照）では、病院状況リストNo、病院状況リスト状態区分、待合室人数、内視鏡使用区分、手術室使用区分、カテ室使用区分、ＩＣＵ使用区分、入院満床区分、設備使用開始日時、設備使用終了予定日時、病院Noが対応付けられている。病院スケジュール管理情報リスト４１６（図２２参照）では、病院スケジュール管理情報No、病院スケジュール管理情報状態区分、診療年度、診療月、病院Noが対応付けられており、更に病院スケジュール詳細情報リスト４１７が紐付けられている。病院スケジュール詳細情報リスト４１７（図２２参照）では、病院スケジュール詳細情報No、病院スケジュール詳細情報状態区分、診療日、診療日種別区分、午前診療区分、午前診療開始時間、午前診療終了時間、午後診療区分、午後診療開始時間、午後診療終了時間、夜間診療区分、夜間診療開始時間、夜間診療終了時間、病院スケジュール管理情報Noが対応付けられている。そして、輪番情報リスト４１８（図２２参照）では、輪番情報No、輪番情報状態区分、開始日時、終了日時、対応診療科、地区、病院Noが対応付けられている。

以下、図２３のフローチャートを参照して、重症度、緊急度の判定アルゴリズムの一例について詳細に説明する。これらの重症度・緊急度の判定アルゴリズムは医療の進歩や各種の研究結果、あるいは地域性によって異なるため、判断基準は適宜、変更、追加、削除ができるようになっている。この重症度、緊急度の判定は、サーバの重症度判定部３０１ｅにより実施されることになる。００５４?００５８では、現時点でのアルゴリズムに基づいて、判断のプロセスを説明する。

処理を開始すると、致死性の病態（例：心肺停止状態や重症外傷）であるかどうかを尋ねる画面が現れる（Ｓ５０）、致死性の高い病態が選択されている場合には、各対応病院を搬送先とする（Ｓ５１Ａ〜Ｓ５１Ｅ）。即ち、端末での画面選択に応じて、外傷性ＣＰＡ対応（Ｓ５１Ａ）、小児ＣＰＡ対応（Ｓ５１Ｂ）、ＣＰＡ Ｃ（Ｓ５１Ｃ）、ＣＰＡ Ｂ（Ｓ５１Ｄ）、外傷Ｃ（５１Ｅ）が搬送先として決定される。ここで、"Ｃ"とは重症であることを意味しており、"Ｂ"は中程度、"Ａ"は軽症であることを意味している。尚、これらの分類は、医療の進歩や各種の研究結果、あるいは地域性によって異なる。

さらに、地域特性を考慮して、特定の疾患や病態における搬送先が決まっているような場合には、それぞれの対応病院が選択される。本例では、小児疾患である場合には（Ｓ５３Ａ）、小児対応病院を搬送先として決定し（Ｓ５４Ａ）、特殊疾患である場合には（Ｓ５３Ｂ）、特殊疾患対応病院を搬送先として決定し（Ｓ５４Ｂ）、母体搬送の場合には（Ｓ５３Ｃ）、母体搬送対応病院を搬送先として決定し（Ｓ５４Ｃ）、外傷の場合は（Ｓ５５）、その他の病院が搬送先として選定される。

バイタルサイン、意識レベル、疑い疾患名と患者状態などの入力がなされると（Ｓ５６）、それらの情報に基づいて搬送先を決定する。中でも緊急性が高い状態、即ち、１）意識障害（ＪＣＳ／ＧＣＳ）の有無（Ｓ５７Ａ）、２）ショック（ＳＩが１．５以上）の有無（Ｓ５７Ｂ）、３）バイタル２項目以上の異常（脈拍、呼吸、血圧、体温、ＳＩＲＳ３項目以上）の有無（Ｓ５７Ｃ）があった場合には、各自治体で決められた重症対応が可能な「搬送対応医療機関リスト」に基づいて搬送先候補が提示される

ここで、１）のみを満たす内因性である場合には（Ｓ５８）、その状態に基づいて、各自治体で決められた搬送対応医療機関リスト」に基づいて搬送先候補が提示される。例えば、現時点でのアルゴリズムでは、意識障害を伴う内因性疾患（Ｓ５９）、瞳孔異常がある場合には（Ｓ６０）、脳卒中Ｃが搬送先として決定され（Ｓ６２）、瞳孔異常がない場合には（Ｓ６１）、意識障害Ｂ対応医療機関が候補として表示される（Ｓ６３）。２）、３）のいずれかを満たす内因性である場合には（Ｓ６４）、バイタルの異常を伴う内因性疾患であるとし（Ｓ６５）、救命センター・Ｃ対応医療機関が候補として表示される（Ｓ６６）。１）〜３）のいずれかを満たす外傷の場合には（Ｓ６７）、重症外傷であるとし（Ｓ６８）、上記同様に救命センター・Ｃ対応医療機関が候補として表示される（Ｓ６６）。そして、１）〜３）のいずれかを満たさない外傷である場合には（Ｓ６９）、部位別の検討を行い（Ｓ７０）、外傷Ｂ（Ｂ１−Ｂ３）対応医療機関が候補として表示される（Ｓ７１）。

１）〜３）のいずれも満たさない内因性である場合には（Ｓ７２）、ある一定時間内（現在のガイドラインでは３時間以内だが、現在、適応が拡大中のため、変更される可能性もある）に生じた麻痺の場合には血栓溶解療法（tPA：tissue plasminogen activator）の対応となるため、脳卒中Ｃ２（ｔＰＡ）、くも膜下出血（SAH: subarachnoid hemorrhage）を疑う「過去に経験のないような強い頭痛」などの所見がある場合には脳卒中Ｃ１（脳外科緊急手術）に対応できる医療機関が候補として提示される。急性冠症候群（ACS: Acute Coronary Syndrome）疑い症状の場合にはＡＣＳネットワーク対応医療機関が、重症腹症症状の場合には腹痛Ｂ対応医療機関が、重症消化管出血の場合には消化管出血Ｂ対応医療機関が、搬送先候補として。上記のいずれにも該当しない場合、全身状態観察がなされ（Ｓ７４）、不良である場合にはＢ対応（Ｓ７５）、良好である場合にはＡ対応（Ｓ７６）の搬送先の候補が提示され、仮に搬送後に容体が急変して、重症になった場合には、速やかにＳ６２〜Ｓ６６の搬送先候補を提示するようになる。

以下、図２４乃至図３６を参照して、端末における画面遷移の一例を説明する。サーバの表示制御部３０１ｂの制御の下、端末における画面データが生成される。端末により入力された情報は、サーバの情報登録部３０１ｄに登録される。端末に表示されるリストはサーバのリスト作成部３０１ｆにより作成される。

図２４は出動〜現着画面５０１を示している。この画面５０１では、現場から病院までの経路（地図）表示領域と、患者の年齢や性別、出訴、入電、発見状況等の覚知情報の表示領域、症状に関する経過情報の表示領域が表示されており、現着ボタンも設けられている。現着ボタンが押下されると、図２５の初期分岐画面５０２に画面が遷移される。この画面５０２では、左上に緊急性の高い疾患の入力指定領域が、中央に特定疾患の入力指定領域が、右上に部位別症状入力領域が、そして下方にバイタルサイン入力領域が設けられている。バイタルサインとしては、意識状態、血圧、脈拍、呼吸、体温、ＳｐＯ２等が入力可能となっている。但し、これらに限定されないことは勿論である。

バイタルサイン入力領域の「意識状態」ボタンが押下されると、図２６に示されるような意識状態入力パネル５０３が表示される。このパネル５０３では、ＪＣＳに関する１０項目の中から１つを選択し、不穏、失禁、自発性喪失の中から該当するものを選択し（複数選択可能）、ＧＣＳに関する、Ｅ開眼、Ｖ言葉、Ｍ運動から１つの項目をそれぞれ選び、入力完了ボタンを押下すればよい。

バイタルサイン入力領域の「血圧」ボタンが押下されると、図２７に示されるような血圧入力パネル５０４が表示される。このパネル５０４では、測定部位を選択し、血圧の数値を入力すればよい。測定不能が押下されるまで、触知がグレー表示される。バイタルサイン入力領域の「脈拍」ボタンが押下されると、図２８に示されるような脈拍入力パネル５０５が表示される。このパネル５０５では、測定部位を選択し、脈拍の数値を入力すればよい。バイタルサイン入力領域の「呼吸数」ボタンが押下されると、図２９に示されるような呼吸入力パネル５０６が表示される。このパネル５０６では、レベル１〜３の中から患者の該当する症状を選び選択することになる。この例では、レベル１では「単語のみ会話」、「チアノーゼ」、レベル２では「文節会話」、「吸気性喘鳴」、レベル３では「文章単位会話」、「労作時息切れ」が選択できるようになっている。

バイタルサイン入力領域の「体温」ボタンが押下されると、図３０に示されるような体温入力パネル５０７が表示される。このパネル５０７では、体温の測定部位を選択し、数値を入力するようになっている。３つの数字を入力すると少数第１位まで表示されるようになっている。この他、測定環境について、低温環境下、高温環境下などの入力もできるようになっている。

バイタルサイン入力領域の「ＳｐＯ２」ボタンが押下されると、図３１に示されるようなＳｐＯ２入力パネル５０８が表示される。このパネル５０８では、患者のＳｐＯ２（動脈血酸素飽和度）の測定部位と数値（％）を入力するようになっている。

初期分岐画面５０２において、左上に表示された緊急性の高い疾患の入力指定領域において、内因性成人ＣＰＡ、内因性小児ＣＰＡ、外因性ＣＰＡ、ＤＮＲ対応ＣＰＡのうちの１つが指定されると、図３２に示されるような、ＣＰＡに関する受入可否状況画面５０９に画面が遷移する。この画面５０９では、発生状況（地図）、本日のリスト病院の活動状況、現在の患者の情報が表示されるようになっている。発生状況としては、現場と近隣の病院が地図上に表示される。本日のリスト病院の活動状況では、対応医療機関名と、当該医療機関までの距離、状況、診断名、重傷度、受入状況等が対応付けられて表示される。現在の患者としては、患者の年齢、性別、主訴、覚知、現着時刻等が表示される。このような画面５０９において、中央の「伝達画面」ボタンが押下されると、図３３に示されるような伝達項目パネル５１０が表示される。このパネル５１０では、基本項目として、推定心肺停止時刻、年齢、性別、ＤＮＲ対応の有無が入力され、ＣＰＡ特異的情報として、目撃者の有無、Bystanderの有無、初回心電図、ＡＥＤ、既往歴、かかりつけの医院、パスＩＤ、搬送歴、病名、搬送先、ＥＴＡ等が入力される。

受入可否状況画面５０９において、本日のリスト病院の活動状況のリストから病院が選択されると、図３４に示されるような受入可否入力画面５１１に画面が遷移する。この画面５１１では、上方に問合せ先の医療機関名、電話番号、当直医の名前が表示され、更に中ほどに電話、背景・搬送元、受入可能、受入困難のボタンが表示される。電話ボタンが押下されると、前述した伝達項目パネル５１０が表示される。背景・搬送元ボタンが押下されると、図３５に示されるような背景・搬送元入力パネル５１２が表示される。このパネル５１２では、背景因子と搬送依頼元が入力できるようになっている。背景因子は複数選択することができ、搬送依頼元はどれか１つを選択する。医療機関等で端末が操作されて、受入困難ボタンが押下されると、図３６に示されるような受入困難事由入力パネル５１３が表示される。このパネル５１３では、受入困難事由を選択することができるようになっている。

以上説明したように、本発明の実施の形態に係るサーバは、ネットワークを介して携帯端末２００と所定の認証の後に通信自在なサーバ２０１，２０２であって、全体の制御を司る主制御部３０１ａと、上記端末２００における画面表示を制御するよう画面データを生成する表示制御部３０１ｂと、上記端末２００からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部３０１ｃと、情報登録を受け付ける情報登録部３０１ｄと、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部３０１ｆと、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部３０１ｅとを備えたことを特徴とする。

ここで、重症度判定部３０１ｅは、アルゴリズムで特定された緊急性の高さに基づいて緊急性の高い病態に対応できる医療機関（主に救命救急センター）を搬送先候補とし、緊急性の高さに加え、疑い疾患やその重症度を加味して搬送先候補を選定する。

さらに、本発明の実施の形態に係る救急医療管制支援システムは、携帯端末２００と、上記携帯端末２００とネットワークを介して通信自在なサーバ２０１，２０２と、統計サーバ２０４と、からなる救急医療管制支援システムであって、上記サーバ２０１，２０２は、全体の制御を司る主制御部３０１ａと、上記端末２００における画面表示を制御するよう画面データを生成する表示制御部３０１ｂと、上記端末２００からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部３０１ｃと、情報登録を受け付ける情報登録部３０１ｄと、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部３０１ｆと、上記登録された情報と各自治体で決められた「傷病者の搬送及び受入れの実施基準等」に基づいて、病態の緊急度と重症度を判定する重症度判定部３０１ｅと、を備え、上記統計サーバ２０４は、取得したタイムスタンプや登録された情報に基づいて所定の医療の質指標（臨床指標）、日報、月報、地図上への表示報告書などを自動的に定期的に作成し、上記サーバ２０１，２０２の上記重症度判定部３０１ｅは、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、特定の病態の対応する搬送医療機関候補リストとして表示することを特徴とする。

なお、各種指標とは、傷病者の搬送基準の検証や、医療機関の受け入れ基準の評価に関するものであり、基本的なものは予めコンテンツとして実装するが、追加・更新は可能である。

ここで、上記携帯端末はタッチパネル式端末であってよい。なお、タッチパネル式端末には、タブレット型ＰＣやスマートフォンの如き端末が概念上、含まれることは勿論である。

携帯端末が病院側のものであれば、診断結果等の各種医療情報を入力画面より入力可能である。ここで、図３７には、病院側の入力画面６００の一例を示す。ここでは、「心・循環」の疾患の入力画面６００を示している。同図に示されるように、病院側では、患者のトリアージ（治療優先順位を決めること）を選択する。この例では「超緊急」、「緊急」、「準緊急」、「低緊急」、「軽症」の中から受入先病院の医師等が選択を行う。受入時に救急隊により緊急として搬送された患者であっても、この選択時に、そのトリアージが見直され、病院側で診察待ちをしている患者群は、この選択されたトリアージに従って診察順が更新される。続いて、検査内容（この例では、心電図等）、診断内容（この例では、ＳＴＥＭＩ（ＳＴ上昇型心筋梗塞）、心不全、不整脈等）、治療・処置内容（ＣＡＧ（選択的冠状動脈造影）、ＰＣＩ等）が入力される。例えば、ＰＣＩとはカテーテルによる冠動脈治療を意味するが、このＰＣＩが選択されると、当該医療機関は、所定時間の間は他の患者の治療には取りかかれないと認識が別の医療機関の関係者に生まれる。その後、転帰情報として例えば「入院」、「帰宅」、「上流転送」、「下流転送」、「死亡」が選択される。例えば、「入院」が選択されると、その手続に所定時間（例えば１時間）は処置などで多忙になるとの認識が外部端末により他の関係者によっても把握される。以上のような入力がなされると、入力情報は医療情報としてデータベースサーバ２０２のＤＢに記録されるだけでなく、複数の医療機関、救急隊、その他関係者によりリアルタイムで当該情報が共有可能となる。この病院側の入力画面としては、この「心・循環」に係る入力画面６００のほかに、「脳・意識」、「消化器」、「外傷」、「ＣＰＡ（心肺停止）」、「その他」に係る各種入力画面を選択することができ、各疾患別に所定の医療情報の選択入力が可能となっている。

ところで、前述したように、統計サーバ２０４は、取得したタイムスタンプや登録された情報に基づいて所定の医療の質指標（臨床指標）、日報、月報、地図上への表示報告書などを自動的に定期的に作成するが、以下、それらの一例を説明する。

図３８には、救急患者発生マップの表示画面６０１を示す。図３８では、図示を省略しているが、各市町村（この例では市単位）に区分された各領域は、管轄地域内の応需割合により色分けされている。各領域には、搬送患者の照会回数が星印で示されており、その色により照会回数を把握できるようになっている。さらに、星のプロットされている位置は、患者の発生場所を意味する。この位置は、救急隊の端末のＧＰＳ機能により自動的に特定される。さらに、この救急患者発生マップ上には、医療機関の応需割合が円グラフで示されている。グレースケールは受入可能の割合を、白色は受入不可の割合を示している。円グラフ自体の大きさは、応需、つまり受入に係る電話の多さを反映している。

図３９には、作成された各医療機関の日報の一例を示す。図３９では、消防本部向け日報としての搬送症例リストが示されている。この図３９に示されるように、搬送症例リストでは、搬送Ｎｏ．、疑い疾患分類、覚知時刻、救急隊名、年齢、性別、搬送時間、照会Ｎｏ．、照会開始時刻、通話時間、照会元、照会先医療機関、リスト内順位、照会順、応需状態、応需×への照会理由、受入可否、困難理由、搬送先医療機関、確定診断名、処置内容、外来転帰が示される。ここで、搬送時間とは、覚知から医師引渡しまでの所要時間（単位：分）を意味している。

この他、疑い疾患区分別の患者数について、自院に照会のあった患者全てのリストを作成することもできる。これは、昨日の照会件数、受入件数、応需割合、今週の累積（照会件数、受入件数、応需割合）、今月の累積（照会件数、受入件数、応需割合）、今年の累積（照会件数、受入件数、応需割合）を示すものである。

さらに、各医療機関の月報を作成することもできる。これは、各医療機関別の統計であり、月間統計として自院に照会のあった患者全てのリストを作成することもできる。これは、毎月の統計（先月までの照会件数と受入件数、応需割合）、今月の累積（照会件数と受入件数、応需割合）、今年の累積（照会件数と受入件数、応需割合）を示すものである。

また、県全体の統計として、全体統計を示すこともできる。報告内容としては、「照会と搬送」に関して、全照会数、全搬送数、応需割合、１回照会、１回照会割合、４回以上の数、４回以上照会割合、全搬送時間（中央値）、全搬送時間（平均値）、３０分以上数、３０分以上照会割合等を示すことができ、「医療機関」に関して、脳卒中治療数、緊急ＣＡＧ件数、緊急手術数、緊急入院数等を示すことができる。この他、疾患別統計として、搬送Ｎｏ．、疑い疾患区分、覚知時刻、救急隊名、年齢、性別、全搬送時間、照会回数、搬送先医療機関、確定診断名、処置内容、外来転帰等を示すことができる。疑い疾患区分としては、内因性ＣＰＡ、外因性ＣＰＡ、小児ＣＰＡ、ＣＰＡその他、重症脳卒中１、重症脳卒中２４、重症脳卒中５、脳卒中２３、脳卒中２３ｔＰＡ、脳卒中５、ＳＡＨ４、他重症意識障害、胸痛、ショック・意識障害を伴う腹痛、バイタル異常を伴う腹痛、重症腹痛、大量吐下血、小児重症（呼吸、痙攣、４０度以上など）、小児軽症、その他重症の内因性、その他軽症の内因性、重症外傷、軽度外傷、重度熱傷、軽度熱傷等がある。

ここで、本実施形態では、サーバ２０１，２０２が、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部３０１ｅを備えていたが、携帯端末に所定のアプリケーションを実装すれば、携帯端末２００側で重症度判定を行うこともできる。

即ち、図４０には、そのような携帯端末２００の詳細な構成を示す。同図に示されるように、携帯端末２００は、制御部２５１と通信制御部２５２、記憶部２５３、入力部２５４、表示部２５５を備えている。制御部２５１は、制御プログラムを実行することで、主制御部２５１ａ、表示制御部２５１ｂ、重症度判定部２５１ｃとして機能する。主制御部２５１ａは、全体の制御を司る。表示制御部２５１ｂは、表示を制御する。重症度判定部２５１ｃは、登録された情報や各種指標に基づいて患者の重症度を算出する。例えば、救急隊により、図２５に示したような画面５０２で、意識状態や血圧、脈拍、呼吸、体温、ＳｐＯ２等が入力されると、重症度判定部２０１ｅは、当該入力情報に基づいて、病態の緊急度等を判定し画面表示することができる。

以上、本発明の一実施形態について説明したが、本発明はこれに限定されることなく、その主旨を逸脱しない範囲で種々の改良・変更が可能であることは勿論である。例えば、現場や搬送中の観察所見に係る写真や動画を画面表示したり、音声を出力するようにしてもよいことは勿論である。

１０１ａ，１０２，１０３ａ 情報端末
１０１ｂ，１０３ｂ，１０４，１０５ａ〜１０５ｃ タッチパネル式端末
１０６ インターネット網
２００ 携帯端末
２０１ ｗｗｗサーバ
２０２ データベースサーバ
２０３ データ
２０４ 統計サーバ
３００ サーバ
３０１ 制御部
３０１ａ 主制御部
３０１ｂ 表示制御部
３０１ｃ タイムスタンプ取得部
３０１ｄ 情報登録部
３０１ｅ 重傷度判定部
３０１ｆ リスト作成部
３０１ｇ 指標作成部
３０２ 通信制御部
３０３ 記憶部

Claims (7)

1. ネットワークを介して携帯端末と所定の認証の後に通信自在なサーバであって、
   全体の制御を司る主制御部と、
   上記端末における画面表示を制御するよう画面データを生成する表示制御部と、
   傷病者の既往歴、現病歴、身体所見を含む情報の入力を受け付ける情報登録部と、
   前記情報登録部を介して受け付けた前記情報から、各自治体で決められた傷病者の搬送及び受入れの実施基準に基づく重症度・緊急度判定アルゴリズムに基づいて傷病者の重症度を判定する重症度判定部と、
   前記重症度判定部による判定結果と、事前に登録されている搬送対応医療機関リストとに基づき搬送先候補リストを作成するリスト作成部とを備え、
   前記主制御部は、前記表示制御部を介して前記搬送先候補リストを現場からの距離と搬送対応医療機関の繁忙度とでソートした結果を前記携帯端末における画面に表示させることを特徴とするサーバ。
2. 前記主制御部は、
   前記搬送先候補リストから選択された搬送対応医療機関における傷病者受け入れ応答に基づき、前記搬送先候補リストを更新すること
   を特徴とする請求項１に記載のサーバ。
3. 携帯端末と、
   上記携帯端末とネットワークを介して通信自在な連携サーバと、
   統計サーバと、
   からなる救急医療管制支援システムであって、
   上記連携サーバは、
   全体の制御を司る主制御部と、
   上記端末における画面表示を制御するよう画面データを生成する表示制御部と、
   上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、
   傷病者の既往歴、現病歴、身体所見を含む情報の入力を受け付ける情報登録部と、
   前記情報登録部を介して受け付けた前記情報から、各自治体で決められた傷病者の搬送及び受入れの実施基準に基づく重症度・緊急度判定アルゴリズムに基づいて傷病者の重症度を判定する重症度判定部と、
   前記重症度判定部による判定結果と、事前に登録されている搬送対応医療機関リストとに基づき搬送先候補リストを作成するリスト作成部とを備え、
   上記統計サーバは、取得したタイムスタンプ、登録された前記情報、又は前記搬送先候補リストから選択された搬送対応医療機関における傷病者受け入れ状況に基づいて所定の報告書を自動的且つ定期的に作成すること
   を特徴とする救急医療管制支援システム。
4. 上記携帯端末はタッチパネル式端末であること
   を特徴とする請求項３に記載の救急医療管制支援システム。
5. 上記所定の報告書とは、医療の質指標、日報、月報、地図上への表示の少なくともいずれかに係る報告書を含むこと
   を特徴とする請求項３に記載の救急医療管制支援システム。
6. ネットワークを介してサーバと所定の認証の後に通信自在な携帯端末あって、
   全体の制御を司る主制御部と、
   上記通信を行う通信制御部と、
   画面データに基づく表示制御を行う表示制御部と、
   出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断・処置・転帰に関する情報の入力を受け付ける入力部と、
   前記入力部を介して受け付けた前記情報から、各自治体で決められた傷病者の搬送及び受入れの実施基準に基づく重症度・緊急度判定アルゴリズムに基づいて傷病者の重症度を判定する重症度判定部と、
   前記重症度判定部による判定結果と、事前に登録されている搬送対応医療機関リストとに基づき搬送先候補リストを作成するリスト作成部と、
   表示を行う表示部と、を備え、
   前記主制御部は、前記表示制御部を介して前記搬送先候補リストを現場からの距離と搬送対応医療機関の繁忙度とでソートした結果を前記携帯端末における画面に表示させることを特徴とする携帯端末。
7. 前記タイムスタンプから得られる時刻情報には、少なくとも発症時刻、入電時刻、出動時刻、現場到着時刻、前記搬送対応医療機関に対する傷病者受け入れ照会開始時刻、傷病者受け入れ可否応答時刻、現場出発時刻、病院到着時刻、診断開始時刻、又は処置開始時刻が含まれ、
   前記医療の質指標には、前記搬送対応医療機関に対する傷病者受け入れ照合開始から傷病者受け入れ可否応答時間又は傷病名ごとの病院到着から処置開始時間の少なくとも一方
   が含まれることを特徴とする請求項３に記載の救急医療管制支援システム。

Images