"ネットワークを介して携帯端末と所定の認証の後に通信自在なサーバであって、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備えたことを特徴とするサーバ。上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御することを特徴とする請求項1に記載のサーバ。携帯端末と、上記携帯端末とネットワークを介して通信自在な連携サーバと、統計サーバと、からなる救急医療管制支援システムであって、上記連携サーバは、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、上記登録された情報と各自治体で決められた所定の基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備え、上記統計サーバは、取得したタイムスタンプや登録された情報に基づいて所定の報告書を自動的且つ定期的に作成し、上記連携サーバの上記重症度判定部により、緊急性および重症度と各自治体で決められた搬送対応医療機関リストとに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御することを特徴とする救急医療管制支援システム。上記携帯端末はタッチパネル式端末であることを特徴とする請求項3に記載の救急医療管制支援システム。上記各自治体で決められた所定の基準には、傷病者の搬送及び受入れの実施基準を含むことを特徴とする請求項3に記載の救急医療管制支援システム。上記所定の報告書とは、医療の質指標、日報、月報、地図上への表示の少なくともいずれかに係る報告書を含むことを特徴とする請求項3に記載の救急医療管制支援システム。ネットワークを介してサーバと所定の認証の後に通信自在な携帯端末あって、全体の制御を司る主制御部と、上記通信を行う通信制御部と、画面データに基づく表示制御を行う表示制御部と、出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントの入力を受け付ける入力部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、表示を行う表示部と、を備え、上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして上記表示部に表示するよう制御することを特徴とする携帯端末。しかしながら、以上の課題を整理すると、救急医療管制支援システムでは以下の事が実現される必要がある。質指標による医療機関ごとの診療機能、プロセス、アウトカムの見える化救急医療情報と医療機関情報の統合と診療連携状況の見える化各消防本部における救急医療情報の統合による地域全体の救急医療の見える化多忙な救急関係者の手間がかからない情報共有の仕組み重症度救急度に基づいて適切な搬送先を決定するための意思決定支援システムの評価とPDSAサイクルを回すための情報提供そこで、本発明は上述の技術的な課題に鑑み、救急隊と医療機関が同じ情報を元に意志決定することで、納得のいく意志決定ができ、全県レベルの救急医療情報を全ての救急関係者が知ることで、状況に応じた最適の意志決定を可能とし、結果として、搬送時間や発症から治療開始までの時間を短縮させ、患者の予後が改善し、搬送基準や病院リストの妥当性と信頼性を定期的に評価し、改善できる救急医療管制支援システム及びサーバ並びに携帯端末を提供することを目的とする。上述技術的な課題を解決するため、本発明の第1の態様では、ネットワークを介して携帯端末と所定の認証の後に通信自在なサーバであって、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備えたことを特徴とするサーバが提供される。また、本発明の第2の態様では、携帯端末と、上記携帯端末とネットワークを介して通信自在な連携サーバと、統計サーバと、からなる救急医療管制支援システムであって、上記連携サーバは、全体の制御を司る主制御部と、上記端末における画面表示を制御するよう画面データを生成する表示制御部と、上記端末からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部と、情報登録を受け付ける情報登録部と、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部と、上記登録された情報と各自治体で決められた所定の基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、を備え、上記統計サーバは、取得したタイムスタンプや登録された情報に基づいて所定の報告書を自動的且つ定期的に作成し、上記サーバの上記重症度判定部により、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして表示するよう制御することを特徴とする救急医療管制支援システムが提供される。また、本発明の第3の態様では、ネットワークを介してサーバと所定の認証の後に通信自在な携帯端末あって、全体の制御を司る主制御部と、上記通信を行う通信制御部と、画面データに基づく表示制御を行う表示制御部と、出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントの入力を受け付ける入力部と、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部と、表示を行う表示部と、を備え、上記重症度判定部によって、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、上記表示制御部は、特定の病態の対応する搬送医療機関候補リストとして上記表示部に表示するよう制御することを特徴とする携帯端末が提供される。このほか、救急隊における観察や処置の結果を搬送先候補となる医療機関と情報共有できる仕組みを提供できる。さらに、地域全体における患者の発生状況や、急性期医療機関の診療状況を関係者全員が共有できる仕組みを提供できる。そして、救急搬送された患者の診療記録を統合する仕組みを提供できる。本発明に係る救急医療管制支援システム及びサーバ並びに携帯端末によれば、救急隊と医療機関が同じ情報を元に意志決定することで、納得のいく意志決定ができ、全県レベルの救急医療の状況を全ての救急関係者が知ることで、状況に応じた最適の意志決定を可能とし、結果として、搬送時間や発症から治療開始までの時間を短縮させ、患者の予後が改善し、搬送基準や病院リストの妥当性と信頼性を定期的に評価し、改善できる。以下、本発明の救急医療管制支援システムに係る好適な実施形態について図面を参照しながら説明する。なお、本発明の救急医療管制支援システムは、以下の記述に限定されるものではなく、本発明の要旨を逸脱しない範囲において、適宜変更可能である。図1には、本発明の一実施形態に係る救急医療管制支援システムのネットワークのイメージ図を示し説明する。この図1に示されるように、指令本部にはノートブックやデスクトップ等の情報端末101aやタッチパネル式端末101bが設置されており、光ファイバ、ケーブル、ADSL等或いは3G携帯網を介してインターネット網106に接続されている。住民は、ノートブック等の情報端末102を用い、光ファイバ、ケーブル、ADSLを介してインターネット網106に接続する。また、医療機関事務は、ノートブック等の情報端末103aやタッチパネル式端末103bを用いて、光ファイバ、ケーブル、ADSL等或いは3G携帯網を介してインターネット網106に接続する。医師看護師は、タッチパネル式端末104を用いて、ワイヤレスLAN院内と、光ファイバ、ケーブル、ADSL等を介して、或いは3G携帯網を介して、インターネット網106に接続する。実装するプログラムは、1主に携帯端末で利用するシンクライアント純粋なSaaSSoftwareAsAServiceで、ブラウザ上で動かし、ほとんどのアルゴリズムはサーバ上で稼働する、2リッチクライアントフレームワークをインストールし、コンテンツを適宜、ダウンロードし、多くのアルゴリズムはクライアントで稼働するの2種類である。双方とも特定ベンダーのネットワークの利用に拘ることなく、一般的な接続形態での接続を可能にする。但し、リッチクライアントの携帯端末は、救急隊による日常利用に耐え得る強固な構造の端末であることが望ましく、この端末で接続可能な3G携帯電話ネットワーク例えばFOMA、WiMAX、イーモバイル等であるWANWideAreaNetworkを選ぶことになる。シンクライアントは、通常のノートブック或いはデスクトップよりのアクセスを想定しており、各種固定回線ISDN、ADSL、CATV、光ファイバ等のいずれでも対応可能な設計とする。但し、医療機関の多くが院内端末からのインターネットへの接続を制限している現状を考えると、医療機関内からのアクセスには、上記のWANへの接続形式も選択肢とする必要があり、CATVが主なネットワークインフラである地域では、将来的な拡張にあたってはこれらも考慮する。図2には、救急医療管制支援システムで利用する端末と、それぞれの端末から連携サーバへのアクセス形態を示し説明する。前述したように、救急隊医療機関では3G携帯電話ネットワークに接続できる強固な構造の端末を利用し、その他ではノートブックデスクトップなどのPC端末の利用を想定している。将来的には、一部情報への一般住民からのアクセスを予定しており、その際には、携帯電話端末やPDA等からのアクセスも考慮する。図3には、接続形式と端末の形態、インターネットへの接続、利用者が対比してまとめられている。即ち、シンクライアントThinClientは、端末の形態としてはノートブックやデスクトップが採用され、インターネットへは光ファイバケーブルADSLにより接続する。利用者としては、指令本部、住民に好適である。一方、リッチクライアントRichClientは、端末の形態としてはタッチパネル式端末が採用され、3G携帯ネットワークを介してインターネットに接続する。利用者としては、救急隊に特に好適であり、指令本部、医療機関でも利用されるが、住民には利用されにくい。図4には、この発明の一実施形態に係る救急医療管制支援システムのシステム面におけるセキュリティ対策の概要を示している。同図に示されるように、この救急医療システムのセキュリティは、以下の5つのレベルで確保する。端末200へのアクセス端末200には許可を得た個人のみアクセスを許可する。例えば、IDとパスワード、バーコード、ICカード、指紋などの認証システムを活用する。WWWサーバ201へのアクセス原則、IDとパスワードによるアクセス制限を行う。携帯端末200とサーバはデジタルIDによる認証を行う。データの送受信は全てSSLで暗号化する。データベースサーバ202へのアクセスデータベースサーバ202は、医療機関の患者データが保管できるレベルの物理的、電子的セキュリティを確保する。データベースサーバ202には、上記のWWWサーバ201のIPアドレスからのアクセスのみを許可する。データ203の管理全ての個人特定可能なデータ例えば、米国HIPAAのProtectedHealthInformationに相当するものは暗号化して保管する。統計サーバ204におけるデータの管理統計サーバ204では、全てのデータを匿名化する。元のデータと連結を可能にする連結テーブルは暗号化アクセス制限機能を持ったUSBに保管し、物理的にロックされた保管庫に保管する。また、この救急医療システムは、以下の汎用性モデル性を有する。クラウドを利用することによるスケーラビリティこの救急医療システムは、患者のデータを保管できるレベルのセキュリティをもったデータセンターにアクセスして利用するタイプのSaaSの形態をとる。携帯端末200のメンテナンス、ソフトウェアやコンテンツのアップデートについても一元管理を行うことで各施設におけるメンテナンスのコストを削減できる。医学的なコンセンサスに基づく共有すべき情報の標準化過去において様々な救急システムにおいて収集された情報は、論理ベースに基づかず、地域によってまちまちの運用であることが多かった。また、論理に基づかないため、集めたデータが活用されていない場面もあった。この救急医療システムでは、病院実績に基づいた搬送先のリストと、医学的なコンセンサスに基づいた搬送ルールを実装する。これらのリストとルールの作成は医療の質マネジメントに基く。ベンダー、OS、ハードウェアに依存しないオープンな設計データレベルではなく、情報レベルでの標準化を行うことで、各医療機関に導入されている医療情報システムがどのようなものであれ、その情報を抽出するために必要なデータを得ることで医療情報システムのベンダーからフリーの設計が可能である。利用する携帯端末200には、シンクライアントと、リッチクライアントを開発する。シンクライアントは一般的なブラウザで稼働する予定で、リッチクライアントも一般的なOSMacOS105以降、WindowsXPあるいはWindows7などで稼働するように設計する。次に、図5には、本発明の一実施形態に係る救急医療システムの連携サーバの構成を示し説明する。尚、この連携サーバは、図4のwwwサーバ201及びデータベースサーバ202を概念上含むものである。同図に示されるように、連携サーバ300は、制御部301と通信制御部302、記憶部303を有した構成となっている。制御部301は、制御プログラムを実行することで、主制御部301a、表示制御部301b、タイムスタンプ取得部301c、情報登録部301d、重症度判定部301e、リスト作成部301fとして機能する。主制御部301aは、全体の制御を司る。表示制御部301bは、端末における画面表示を制御するよう画面データを生成する。タイムスタンプ取得部301cは、端末からの出動、現場到着等といったイベントを検出しタイムスタンプを取得する。情報登録部301dは、救急隊や医療機関等からの情報登録を受け付ける。重症度判定部301eは、上記登録された情報や後述する指標に基づいて患者の重症度を算出する。リスト作成部301fは、上記登録された情報等に基づいて本日の病院の活動状況を示すリスト等を作成する。尚、先に図4に示した統計サーバ204は、全てのタイムスタンプやデータをレポジトリとして保管しており、取得したタイムスタンプや上記登録された情報等に基づいて所定の指標特性、プロセス、連携を算出し、消防機関、医療機関へのフィードバック、及び行政や住民への情報提供を可能にする。以下、図6のフローチャートを参照して、本発明の一実施形態に係る救急医療管制支援システムによる処理手順を詳細に説明する。なお、救急隊の記録は、タッチパネルのボタンを押した時点でタイムスタンプとして記録される。すべての記録は搬送先医療機関の端末によりリアルタイムで閲覧可能である。住民から通報がなされるとS1、サーバは、患者の年齢、性別、状態などのデータを移行するS2。このデータの移行後に、救急隊は出動する。このとき、端末の出動ボタンが押下されS3、サーバは出動に関するタイムスタンプを記録するS4。その後、救急隊は現場に到着すると、端末の現場到着ボタンが押下されS5、サーバは現場到着に関するタイムスタンプを記録するS6。救急隊は、現場において、患者の既往歴、現病歴、身体所見の中で重症度緊急度の判定に必要なデータを記録するS7。この記録されたデータに基づいて、サーバにおいて、各自治体で決められている傷病者の搬送及び受入れの実施基準等に基づいて内部に組み込まれた重症度緊急度判定アルゴリズムにより重症度の判定が行われるS8。サーバは、重症度、緊急度の判断と、事前に登録されている医療機関の特性とリストに基づいて搬送対応医療機関一覧を、現場からの距離および各医療機関の繁忙度でソートした形で表示するS9。救急隊の端末では、搬送先候補一覧が表示されるS10。この一覧には、当日の各医療機関の状況がリアルタイムで反映されており、多忙な医療機関を避けた連絡を行うことを可能ならしめる。救急隊は、この搬送先候補一覧を見て、医療機関に連絡をするS11。医療機関は患者の受け入れに関する意思決定を行い、その結果はサーバに通知されるS12。サーバでは、この通知に基づいて、リストを更新するS13。このように、医療機関と緊急隊は同じ情報県内における患者の発生状況、各医療機関の多忙さ、患者の状態などを共有しながら、最適の決断をすることになる。なお、救急隊が問い合わせた時点で、医療機関の状況によって受入困難が生じている場合、救急隊がタッチすることで、その情報を共有できる。こうして、救急隊は、現場を出発現発する。そのときに端末の現発ボタンが押下されるとS14、サーバは現場出発に関するタイムスタンプを記録するS15。さらに、救急隊は、病院に到着する病着。そのときに端末の病着ボタンが押下されるとS16、サーバは病着に関するタイムスタンプを記録するS17。医療機関到着後、救急隊が入手している情報は自動的にサーバから医療機関の端末に転送されるS18。この情報は医療機関の端末において表示されるS19。医療機関において、外来診断が確定した時点で、診断ボタンが押下されS20、サーバは診断内容と診断時間をタイムスタンプで記録するS21。さらに、処置手術が行われた場合、処置手術ボタンが押下されS22、サーバは処置手術に関するタイムスタンプを記録するS23。そして、最終的な転帰が決まった際には転帰ボタンが押下されS24、サーバは転帰に関するタイムスタンプを記録するS25。また、このとき、医療機関では、搬送された患者の診断、処置手術内容、転帰の3項目を入力することでデータの統合と情報共有を実現できる。これら搬送された患者への医療機関の対応に基づいて、予め決められた一定時間の間例:一般入院対応は1時間、腹部の手術は3時間などはその医療機関が繁忙であることをサーバに記録し、関係者の間でその情報を共有すると同時に、医療機関選定用リストにその旨を表示する。こうして、蓄積された情報に基づいて各種の指標が作成され、その後、当該情報が共有されることになるS26。こうして、一連の処理を終了する。なお、各種指標とは、搬送ルールの検証や、医療機関が適切に患者の受け入れを行っているかどうかに関するものであり、基本的なものは予めコンテンツとして実装するが、追加更新は可能である。ここで、図7乃至図22には、データベースの構成を示し説明する。これらの図に示されるように、データベースとしては、患者リスト401、既往症リスト402、搬送リスト403、患者搬送指示リスト404、患者状態詳細リスト405、端末側病院状況リスト作成依頼リスト406、搬送救急隊員リスト407、救急隊処置記録リスト408、受入要請リスト409、転送受入要請リスト410、端末側病院状況リスト411、搬送先病院リスト412、受入リスト413、処置詳細リスト414、病院状況リスト415、病院スケジュール管理情報リスト416、病院スケジュール詳細情報リスト417、輪番情報リスト418、がテーブル方式で蓄積されている。尚、図7において1,0で示したのは、1は0に対して必須のリストであるが、0は1に対して必ずしも必須ではないとのエンティティの関係を示している。より詳細には、患者リスト401図8参照では、患者No、患者状態区分、患者年齢、患者性別区分、患者氏名、患者生年月日、心肺停止有無区分、吐血有無区分、飲酒有無区分、搬送困難有無区分、腹痛有無区分、意識障害有無区分が対応付けられており、さらに既往症リスト402、搬送リスト403、患者搬送指示リスト404、患者状態詳細リスト405が紐付けられている。なお、患者リスト401の項目は、追加、削除、統合などが適宜可能である。これは、以下に述べる他のリストについても同様である。既往症リスト402図9参照では、既往症No、既往症状態区分、既往症、病院名、病院No、患者Noが対応付けられている。そして、搬送リスト403図10参照では、搬送No、搬送状態区分、発生場所、現場住所、現場緯度、現場経度、出動要請日時、搬送動態区分、救急車No、患者No、出動日時、端末側病院状況リスト作成依頼No、現着日時、搬送切分区分、病着日時、病発日時、帰署日時、発生日時が対応付けられており、更に、搬送救急隊員リスト407、救急隊処置記録リスト408、受入要請リスト409が紐付けられている。また、患者搬送指示リスト404図11参照では、患者搬送指示No、患者搬送指示状態区分、出動指令No、通報者氏名、通報者性別区分、通報者関係区分、覚知方法区分、携帯転送受内容、覚知日時、通報内容詳細、搬送転送区分、消防本部No、患者No、依頼元病院No、端末側病院状況リスト作成依頼Noは対応付けられており、更に転送受入要請リスト410が紐付けられている。さらに、患者状態詳細リスト405図12参照では、患者状態詳細No、患者状態詳細状態区分、項目種別区分、JCS、GCS_E、GCS_V、GCS_M、最高血圧、最低血圧、呼吸数、脈拍数、体温、SpO2、心電図区分、左瞳孔、右瞳孔、左対光反射区分、右対光反射区分、患者Noが対応付けられている。端末側病院状況リスト作成依頼リスト406図13参照では、端末側病院状況リスト作成依頼No、端末側病院状況リスト作成依頼状態区分、依頼元、搬送No、依頼元病院No、患者搬送指示Noが対応付けられている。搬送救急隊員リスト407図14参照では、搬送救急隊員No、搬送救急隊員状態区分、UserNo、搬送Noが対応付けられている。救急隊処置記録リスト408図15参照では、救急隊処置記録No、救急隊処理記録状態区分、処置日時、搬送処置区分、搬送Noが対応付けられている。そして、受入要請リスト409図16参照では、受入要請No、受入要請状態区分、受入要請方法区分、受入可否区分、病院No、搬送No、患者No、病院側受入可否区分、受入要請拒否理由区分、受入要請拒否理由、受入要請拒否日時、受入要請拒否理由解除予定日時、受入要請受諾日時、受入要請受諾取消理由区分、受入要請受諾取消理由、受入要請受諾取消日時、病院側受入可否回答日時、受入取消日時が対応付けられている。転送受入要請リスト410図17参照では、転送受入要請No、病院No、患者No、受入可否区分、受入要請拒否日時、受入要請拒否理由解除予定日時、受入要請拒否理由区分、受入要請拒否理由、受入要請受諾取消理由区分、受入要請受諾取消理由、受入要請受諾取消日時、病院側受入可否区分、病院側受入可否回答日時、転送受入要請状態区分、受入取消日時、患者搬送指示No、依頼元病院Noが対応付けられている。さらに、端末側病院状況リスト411図18参照では、端末側病院状況リストNo、端末側病院状況リスト状態区分、病院No、心肺停止有無区分、吐血有無区分、下血有無区分、飲酒有無区分、搬送困難有無区分、腹痛有無区分、意識障害有無区分、病院名、病院住所、病院電話番号、診療休止中区分、次回診療開始時刻、端末側病院状況リスト作成依頼No、距離、症状徴候別医療機関選定区分が対応付けられている。搬送先病院リスト412図19参照では、搬送先病院リストNo、搬送先病院リスト状態区分、病院No、病院名、病院住所、病院電話番号、端末側病院状況リストNo、搬送先選択区分が対応付けられている。そして、受入リスト413図20参照では、受入No、病院No、患者No、受入状態区分、患者ベッドID、患者受入詳細区分、医師No、受入要請No、受入日時、救急診断名、最終診断名、受入患者転帰区分、転帰日時、転送受入要請Noが対応付けられており、更に処理詳細リスト414が紐付けられている。そして、この処置詳細リスト414図21参照では、処置詳細No、処置詳細状態区分、処理区分、処理開始日時、処理終了予定日時、処置終了日時、受入Noが対応付けられている。さらに、病院状況リスト415図22参照では、病院状況リストNo、病院状況リスト状態区分、待合室人数、内視鏡使用区分、手術室使用区分、カテ室使用区分、ICU使用区分、入院満床区分、設備使用開始日時、設備使用終了予定日時、病院Noが対応付けられている。病院スケジュール管理情報リスト416図22参照では、病院スケジュール管理情報No、病院スケジュール管理情報状態区分、診療年度、診療月、病院Noが対応付けられており、更に病院スケジュール詳細情報リスト417が紐付けられている。病院スケジュール詳細情報リスト417図22参照では、病院スケジュール詳細情報No、病院スケジュール詳細情報状態区分、診療日、診療日種別区分、午前診療区分、午前診療開始時間、午前診療終了時間、午後診療区分、午後診療開始時間、午後診療終了時間、夜間診療区分、夜間診療開始時間、夜間診療終了時間、病院スケジュール管理情報Noが対応付けられている。そして、輪番情報リスト418図22参照では、輪番情報No、輪番情報状態区分、開始日時、終了日時、対応診療科、地区、病院Noが対応付けられている。以下、図23のフローチャートを参照して、重症度、緊急度の判定アルゴリズムの一例について詳細に説明する。これらの重症度緊急度の判定アルゴリズムは医療の進歩や各種の研究結果、あるいは地域性によって異なるため、判断基準は適宜、変更、追加、削除ができるようになっている。この重症度、緊急度の判定は、サーバの重症度判定部301eにより実施されることになる。00540058では、現時点でのアルゴリズムに基づいて、判断のプロセスを説明する。処理を開始すると、致死性の病態例:心肺停止状態や重症外傷であるかどうかを尋ねる画面が現れるS50、致死性の高い病態が選択されている場合には、各対応病院を搬送先とするS51A~S51E。即ち、端末での画面選択に応じて、外傷性CPA対応S51A、小児CPA対応S51B、CPACS51C、CPABS51D、外傷C51Eが搬送先として決定される。ここで、Cとは重症であることを意味しており、Bは中程度、Aは軽症であることを意味している。尚、これらの分類は、医療の進歩や各種の研究結果、あるいは地域性によって異なる。さらに、地域特性を考慮して、特定の疾患や病態における搬送先が決まっているような場合には、それぞれの対応病院が選択される。本例では、小児疾患である場合にはS53A、小児対応病院を搬送先として決定しS54A、特殊疾患である場合にはS53B、特殊疾患対応病院を搬送先として決定しS54B、母体搬送の場合にはS53C、母体搬送対応病院を搬送先として決定しS54C、外傷の場合はS55、その他の病院が搬送先として選定される。バイタルサイン、意識レベル、疑い疾患名と患者状態などの入力がなされるとS56、それらの情報に基づいて搬送先を決定する。中でも緊急性が高い状態、即ち、1意識障害JCS/GCSの有無S57A、2ショックSIが1.5以上の有無S57B、3バイタル2項目以上の異常脈拍、呼吸、血圧、体温、SIRS3項目以上の有無S57Cがあった場合には、各自治体で決められた重症対応が可能な搬送対応医療機関リストに基づいて搬送先候補が提示されるここで、1のみを満たす内因性である場合にはS58、その状態に基づいて、各自治体で決められた搬送対応医療機関リストに基づいて搬送先候補が提示される。例えば、現時点でのアルゴリズムでは、意識障害を伴う内因性疾患S59、瞳孔異常がある場合にはS60、脳卒中Cが搬送先として決定されS62、瞳孔異常がない場合にはS61、意識障害B対応医療機関が候補として表示されるS63。2、3のいずれかを満たす内因性である場合にはS64、バイタルの異常を伴う内因性疾患であるとしS65、救命センターC対応医療機関が候補として表示されるS66。1~3のいずれかを満たす外傷の場合にはS67、重症外傷であるとしS68、上記同様に救命センターC対応医療機関が候補として表示されるS66。そして、1~3のいずれかを満たさない外傷である場合にはS69、部位別の検討を行いS70、外傷BB1-B3対応医療機関が候補として表示されるS71。1~3のいずれも満たさない内因性である場合にはS72、ある一定時間内現在のガイドラインでは3時間以内だが、現在、適応が拡大中のため、変更される可能性もあるに生じた麻痺の場合には血栓溶解療法tPA:tissueplasminogenactivatorの対応となるため、脳卒中C2tPA、くも膜下出血SAHsubarachnoidhemorrhageを疑う過去に経験のないような強い頭痛などの所見がある場合には脳卒中C1脳外科緊急手術に対応できる医療機関が候補として提示される。急性冠症候群ACSAcuteCoronarySyndrome疑い症状の場合にはACSネットワーク対応医療機関が、重症腹症症状の場合には腹痛B対応医療機関が、重症消化管出血の場合には消化管出血B対応医療機関が、搬送先候補として。上記のいずれにも該当しない場合、全身状態観察がなされS74、不良である場合にはB対応S75、良好である場合にはA対応S76の搬送先の候補が提示され、仮に搬送後に容体が急変して、重症になった場合には、速やかにS62~S66の搬送先候補を提示するようになる。以下、図24乃至図36を参照して、端末における画面遷移の一例を説明する。サーバの表示制御部301bの制御の下、端末における画面データが生成される。端末により入力された情報は、サーバの情報登録部301dに登録される。端末に表示されるリストはサーバのリスト作成部301fにより作成される。図24は出動~現着画面501を示している。この画面501では、現場から病院までの経路地図表示領域と、患者の年齢や性別、出訴、入電、発見状況等の覚知情報の表示領域、症状に関する経過情報の表示領域が表示されており、現着ボタンも設けられている。現着ボタンが押下されると、図25の初期分岐画面502に画面が遷移される。この画面502では、左上に緊急性の高い疾患の入力指定領域が、中央に特定疾患の入力指定領域が、右上に部位別症状入力領域が、そして下方にバイタルサイン入力領域が設けられている。バイタルサインとしては、意識状態、血圧、脈拍、呼吸、体温、SpO2等が入力可能となっている。但し、これらに限定されないことは勿論である。バイタルサイン入力領域の意識状態ボタンが押下されると、図26に示されるような意識状態入力パネル503が表示される。このパネル503では、JCSに関する10項目の中から1つを選択し、不穏、失禁、自発性喪失の中から該当するものを選択し複数選択可能、GCSに関する、E開眼、V言葉、M運動から1つの項目をそれぞれ選び、入力完了ボタンを押下すればよい。バイタルサイン入力領域の血圧ボタンが押下されると、図27に示されるような血圧入力パネル504が表示される。このパネル504では、測定部位を選択し、血圧の数値を入力すればよい。測定不能が押下されるまで、触知がグレー表示される。バイタルサイン入力領域の脈拍ボタンが押下されると、図28に示されるような脈拍入力パネル505が表示される。このパネル505では、測定部位を選択し、脈拍の数値を入力すればよい。バイタルサイン入力領域の呼吸数ボタンが押下されると、図29に示されるような呼吸入力パネル506が表示される。このパネル506では、レベル1~3の中から患者の該当する症状を選び選択することになる。この例では、レベル1では単語のみ会話、チアノーゼ、レベル2では文節会話、吸気性喘鳴、レベル3では文章単位会話、労作時息切れが選択できるようになっている。バイタルサイン入力領域の体温ボタンが押下されると、図30に示されるような体温入力パネル507が表示される。このパネル507では、体温の測定部位を選択し、数値を入力するようになっている。3つの数字を入力すると少数第1位まで表示されるようになっている。この他、測定環境について、低温環境下、高温環境下などの入力もできるようになっている。バイタルサイン入力領域のSpO2ボタンが押下されると、図31に示されるようなSpO2入力パネル508が表示される。このパネル508では、患者のSpO2動脈血酸素飽和度の測定部位と数値を入力するようになっている。初期分岐画面502において、左上に表示された緊急性の高い疾患の入力指定領域において、内因性成人CPA、内因性小児CPA、外因性CPA、DNR対応CPAのうちの1つが指定されると、図32に示されるような、CPAに関する受入可否状況画面509に画面が遷移する。この画面509では、発生状況地図、本日のリスト病院の活動状況、現在の患者の情報が表示されるようになっている。発生状況としては、現場と近隣の病院が地図上に表示される。本日のリスト病院の活動状況では、対応医療機関名と、当該医療機関までの距離、状況、診断名、重傷度、受入状況等が対応付けられて表示される。現在の患者としては、患者の年齢、性別、主訴、覚知、現着時刻等が表示される。このような画面509において、中央の伝達画面ボタンが押下されると、図33に示されるような伝達項目パネル510が表示される。このパネル510では、基本項目として、推定心肺停止時刻、年齢、性別、DNR対応の有無が入力され、CPA特異的情報として、目撃者の有無、Bystanderの有無、初回心電図、AED、既往歴、かかりつけの医院、パスID、搬送歴、病名、搬送先、ETA等が入力される。受入可否状況画面509において、本日のリスト病院の活動状況のリストから病院が選択されると、図34に示されるような受入可否入力画面511に画面が遷移する。この画面511では、上方に問合せ先の医療機関名、電話番号、当直医の名前が表示され、更に中ほどに電話、背景搬送元、受入可能、受入困難のボタンが表示される。電話ボタンが押下されると、前述した伝達項目パネル510が表示される。背景搬送元ボタンが押下されると、図35に示されるような背景搬送元入力パネル512が表示される。このパネル512では、背景因子と搬送依頼元が入力できるようになっている。背景因子は複数選択することができ、搬送依頼元はどれか1つを選択する。医療機関等で端末が操作されて、受入困難ボタンが押下されると、図36に示されるような受入困難事由入力パネル513が表示される。このパネル513では、受入困難事由を選択することができるようになっている。以上説明したように、本発明の実施の形態に係るサーバは、ネットワークを介して携帯端末200と所定の認証の後に通信自在なサーバ201,202であって、全体の制御を司る主制御部301aと、上記端末200における画面表示を制御するよう画面データを生成する表示制御部301bと、上記端末200からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部301cと、情報登録を受け付ける情報登録部301dと、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部301fと、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部301eとを備えたことを特徴とする。ここで、重症度判定部301eは、アルゴリズムで特定された緊急性の高さに基づいて緊急性の高い病態に対応できる医療機関主に救命救急センターを搬送先候補とし、緊急性の高さに加え、疑い疾患やその重症度を加味して搬送先候補を選定する。さらに、本発明の実施の形態に係る救急医療管制支援システムは、携帯端末200と、上記携帯端末200とネットワークを介して通信自在なサーバ201,202と、統計サーバ204と、からなる救急医療管制支援システムであって、上記サーバ201,202は、全体の制御を司る主制御部301aと、上記端末200における画面表示を制御するよう画面データを生成する表示制御部301bと、上記端末200からの出動、現場到着、現場出発、現場での観察所見、搬送中の観察所見、病院到着、病院における診断処置転帰を含むイベントを検出しタイムスタンプを取得するタイムスタンプ取得部301cと、情報登録を受け付ける情報登録部301dと、上記登録された情報に基づいて病院の活動状況を示すリストを作成するリスト作成部301fと、上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準等に基づいて、病態の緊急度と重症度を判定する重症度判定部301eと、を備え、上記統計サーバ204は、取得したタイムスタンプや登録された情報に基づいて所定の医療の質指標臨床指標、日報、月報、地図上への表示報告書などを自動的に定期的に作成し、上記サーバ201,202の上記重症度判定部301eは、緊急性および重症度と各自治体で決められた搬送対応医療機関リストに基づいて、各対応医療機関、特定病態が疑われた場合には、特定の病態の対応する搬送医療機関候補リストとして表示することを特徴とする。なお、各種指標とは、傷病者の搬送基準の検証や、医療機関の受け入れ基準の評価に関するものであり、基本的なものは予めコンテンツとして実装するが、追加更新は可能である。ここで、上記携帯端末はタッチパネル式端末であってよい。なお、タッチパネル式端末には、タブレット型PCやスマートフォンの如き端末が概念上、含まれることは勿論である。携帯端末が病院側のものであれば、診断結果等の各種医療情報を入力画面より入力可能である。ここで、図37には、病院側の入力画面600の一例を示す。ここでは、心循環の疾患の入力画面600を示している。同図に示されるように、病院側では、患者のトリアージ治療優先順位を決めることを選択する。この例では超緊急、緊急、準緊急、低緊急、軽症の中から受入先病院の医師等が選択を行う。受入時に救急隊により緊急として搬送された患者であっても、この選択時に、そのトリアージが見直され、病院側で診察待ちをしている患者群は、この選択されたトリアージに従って診察順が更新される。続いて、検査内容この例では、心電図等、診断内容この例では、STEMIST上昇型心筋梗塞、心不全、不整脈等、治療処置内容CAG選択的冠状動脈造影、PCI等が入力される。例えば、PCIとはカテーテルによる冠動脈治療を意味するが、このPCIが選択されると、当該医療機関は、所定時間の間は他の患者の治療には取りかかれないと認識が別の医療機関の関係者に生まれる。その後、転帰情報として例えば入院、帰宅、上流転送、下流転送、死亡が選択される。例えば、入院が選択されると、その手続に所定時間例えば1時間は処置などで多忙になるとの認識が外部端末により他の関係者によっても把握される。以上のような入力がなされると、入力情報は医療情報としてデータベースサーバ202のDBに記録されるだけでなく、複数の医療機関、救急隊、その他関係者によりリアルタイムで当該情報が共有可能となる。この病院側の入力画面としては、この心循環に係る入力画面600のほかに、脳意識、消化器、外傷、CPA心肺停止、その他に係る各種入力画面を選択することができ、各疾患別に所定の医療情報の選択入力が可能となっている。ところで、前述したように、統計サーバ204は、取得したタイムスタンプや登録された情報に基づいて所定の医療の質指標臨床指標、日報、月報、地図上への表示報告書などを自動的に定期的に作成するが、以下、それらの一例を説明する。図38には、救急患者発生マップの表示画面601を示す。図38では、図示を省略しているが、各市町村この例では市単位に区分された各領域は、管轄地域内の応需割合により色分けされている。各領域には、搬送患者の照会回数が星印で示されており、その色により照会回数を把握できるようになっている。さらに、星のプロットされている位置は、患者の発生場所を意味する。この位置は、救急隊の端末のGPS機能により自動的に特定される。さらに、この救急患者発生マップ上には、医療機関の応需割合が円グラフで示されている。グレースケールは受入可能の割合を、白色は受入不可の割合を示している。円グラフ自体の大きさは、応需、つまり受入に係る電話の多さを反映している。図39には、作成された各医療機関の日報の一例を示す。図39では、消防本部向け日報としての搬送症例リストが示されている。この図39に示されるように、搬送症例リストでは、搬送No.、疑い疾患分類、覚知時刻、救急隊名、年齢、性別、搬送時間、照会No.、照会開始時刻、通話時間、照会元、照会先医療機関、リスト内順位、照会順、応需状態、応需×への照会理由、受入可否、困難理由、搬送先医療機関、確定診断名、処置内容、外来転帰が示される。ここで、搬送時間とは、覚知から医師引渡しまでの所要時間単位:分を意味している。この他、疑い疾患区分別の患者数について、自院に照会のあった患者全てのリストを作成することもできる。これは、昨日の照会件数、受入件数、応需割合、今週の累積照会件数、受入件数、応需割合、今月の累積照会件数、受入件数、応需割合、今年の累積照会件数、受入件数、応需割合を示すものである。さらに、各医療機関の月報を作成することもできる。これは、各医療機関別の統計であり、月間統計として自院に照会のあった患者全てのリストを作成することもできる。これは、毎月の統計先月までの照会件数と受入件数、応需割合、今月の累積照会件数と受入件数、応需割合、今年の累積照会件数と受入件数、応需割合を示すものである。また、県全体の統計として、全体統計を示すこともできる。報告内容としては、照会と搬送に関して、全照会数、全搬送数、応需割合、1回照会、1回照会割合、4回以上の数、4回以上照会割合、全搬送時間中央値、全搬送時間平均値、30分以上数、30分以上照会割合等を示すことができ、医療機関に関して、脳卒中治療数、緊急CAG件数、緊急手術数、緊急入院数等を示すことができる。この他、疾患別統計として、搬送No.、疑い疾患区分、覚知時刻、救急隊名、年齢、性別、全搬送時間、照会回数、搬送先医療機関、確定診断名、処置内容、外来転帰等を示すことができる。疑い疾患区分としては、内因性CPA、外因性CPA、小児CPA、CPAその他、重症脳卒中1、重症脳卒中24、重症脳卒中5、脳卒中23、脳卒中23tPA、脳卒中5、SAH4、他重症意識障害、胸痛、ショック意識障害を伴う腹痛、バイタル異常を伴う腹痛、重症腹痛、大量吐下血、小児重症呼吸、痙攣、40度以上など、小児軽症、その他重症の内因性、その他軽症の内因性、重症外傷、軽度外傷、重度熱傷、軽度熱傷等がある。ここで、本実施形態では、サーバ201,202が、少なくとも上記登録された情報と各自治体で決められた傷病者の搬送及び受入れの実施基準に基づいて、病態の緊急度と重症度を判定する重症度判定部301eを備えていたが、携帯端末に所定のアプリケーションを実装すれば、携帯端末200側で重症度判定を行うこともできる。即ち、図40には、そのような携帯端末200の詳細な構成を示す。同図に示されるように、携帯端末200は、制御部251と通信制御部252、記憶部253、入力部254、表示部255を備えている。制御部251は、制御プログラムを実行することで、主制御部251a、表示制御部251b、重症度判定部251cとして機能する。主制御部251aは、全体の制御を司る。表示制御部251bは、表示を制御する。重症度判定部251cは、登録された情報や各種指標に基づいて患者の重症度を算出する。例えば、救急隊により、図25に示したような画面502で、意識状態や血圧、脈拍、呼吸、体温、SpO2等が入力されると、重症度判定部201eは、当該入力情報に基づいて、病態の緊急度等を判定し画面表示することができる。以上、本発明の一実施形態について説明したが、本発明はこれに限定されることなく、その主旨を逸脱しない範囲で種々の改良変更が可能であることは勿論である。例えば、現場や搬送中の観察所見に係る写真や動画を画面表示したり、音声を出力するようにしてもよいことは勿論である。"