JP2012027565A - 救急患者治療支援システム - Google Patents

Abstract

【課題】救急医療の現場において担当医が別の専門医に見解を求めることを容易にし、指導的専門医の見解を参照しつつ最適な治療を施す支援システムを提供する。
【解決手段】救急患者が搬送後、担当医は一次端末１を操作して指導的専門医の専門性レベルを指定し、見解情報の提供が可能かの問合せ情報をコミュニケーションサーバ３に送信する。コミュニケーションサーバ３は、指定されたレベルの指導的専門医が操作する二次端末２のアドレスをデータベースサーバ４を検索し、各二次端末２に問合せ情報を送信する。各指導的専門医は、可否情報を二次端末２からコミュニケーションサーバ３経由で一次端末１に送信する。担当医は、見解情報提供可能である旨の送信をした指導的専門医の二次端末２に、初期疾病情報を送信して見解情報を要請する。指導的専門医は、初期疾病情報を二次端末２で確認後、見解情報をコミュニケーションサーバ３経由で一次端末１に送信する。
【選択図】図１

Description

本願の発明は、救急患者の治療を支援する情報システムに関するものである。

医療の現場における技術革新には目覚ましいものがあり、ＣＴ装置やＭＲＩ装置等、多くの先端的医療機器が各種疾病の治療に利用されている。また、医療の現場におけるＩＴ（情報技術）の利用も進んできており、遠隔医療のために医療情報をネットワークを介して送ることや、コンピュータに対して症状等の情報を送ることでコンピュータが病名を推論するコンピュータ診断等の技術も提案されている。

特開２００４−２８０８０７号公報

しかしながら、上記医療現場におけるＩＴ利用に関する従来の提案は、救急医療、特に重篤の救急患者に対する治療の観点では甚だ不十分であった。救急医療の場合、患者が救急搬送された後、短時間のうちに診断を行い、どのような治療を行うか（治療方針）の決定を行わなければならない。診断の前には検査が必要な場合が多く、検査結果によっては再検査が必要な場合もある。

救急医療の現場で特に問題となるのは、どのような疾病であるか直ちには特定できない場合である。例えば、頭に強い痛みを訴えて救急搬送された患者については、通常は、頭部Ｘ線ＣＴや頭部ＭＲＩのような検査がまず行われる。この結果、ＣＴ画像やＭＲＩ画像といった検査画像が得られる訳であるが、画像だけでは、どのような疾病であるのか即断できないことが多々ある。例えば、脳血管障害で言えば、脳梗塞なのか脳出血なのか、画像からは即座に判断できない場合もある。また、疾病が特定できたとしても、どのような治療方法が最善であるか、即座には判断できない場合も多い。例えばくも膜下出血のような脳動脈瘤の治療の場合、こぶ（動脈瘤）の部分をクリップで塞いでしまうクリップ手術と、血管内にカテーテルを通してこぶの部分を内側からコイルで塞いでしまうコイル手術とがあるが、どちらが良いのか、画像からは即座に判断できない場合がある。

その一方、周知のように、このような脳血管障害の疾病は、発症から手術までの時間が長くなればなるほど生存率が低くなる疾病であり、極めて短時間に判断と処置を行うことが強く要請される疾病である。例えば脳梗塞の場合、発症から３時間以内にｔＰＡ（組織性プラスミノーゲン活性化因子，いわゆる血栓溶解剤）を投与できれば、社会復帰できる確率は３０〜４０％程度あるとされているが、３時間を超えた場合、社会復帰できる確率は激減するとされている。このような救急医療の現場では、担当となった医師は、時間との戦いの中で、自らの知識と経験を頼りに最善と思われる判断をし、処置をしている。

しかしながら、より良い結果を得るため、最善の結果を間違いなく得るためには、担当医だけの判断ではなく、別の専門医の見解を求めた方が良い場合もある。この場合、別の専門医が当直等で院内にいる場合には、画像を見てもらって判断を仰ぐこともできる。しかしながら、非番で院内にいない場合には不可能であるし、別の専門医が元々院内にいない（所属していない）場合もある。このような場合には、担当医のみの判断によるしかない。

また、上記の例は担当医が当該疾病の専門医であることを前提にしていたが、救急医療の現場では、専門医以外の医師が救急患者に対応しなければならないことも多々ある。例えば、上記のような循環器系の救急が救急搬送されたものの、当直の医師は消化器系の医師のみであったという場合もあり得る。さらに言えば、過疎地や僻地にある病院や診療所では、幅広い分野で診療を行っているものの特定の専門分野を持たない医師（いわゆる総合医）しか存在しない場合もある。この場合、上記のような高度な専門的判断が要求される診断や治療については、提供することができない。この場合は、その病院や診療所では対応できないので、別の医療施設に搬送するよう救急隊に連絡することになる。この場合には、いわゆるたらい回しのような問題も起こり得る。
さらに、ある程度の規模の病院であり、専門医が常駐している病院であっても、特殊な症例であって自己の専門的知識や経験では判断が難しい場合もあるし、自己の専門分野の疾病ではあっても、より良い結果を得るためには、より高い専門的知識を持った、その分野の指導的医師に見解を求めたい場合もある。このような場合でも、救急医療であるという時間的制約等から、限られた自己の専門的知識と経験で何とか対応しているというのが現状である。

ある疾病に対して別の医師の見解を求めること自体は、従来から行われている。自分が対応できない患者については、紹介状を書いて別の病院で看てもらうよう患者に伝えることは頻繁に行われているし、患者自身が別の専門医に見解を求めること（いわゆるセカンドオピニオン）も、しばしば行われている。しかしながら、これは、いわば、患者を介した別見解の求めであり、最初の担当医が直接的に別の専門医に見解を求めている訳ではない。その一方、救急医療の現場では、上述したように、時間的制約から、担当医が別の専門医に直接的に見解を求めることが望ましい場合が多々あるのが実情である。

本願の発明は、上記のような課題を解決するためになされたものであり、救急医療の現場において担当医が別の専門医、とりわけ指導的な専門医に見解を求めることを容易にし、指導的専門医の見解を参照しつつ最適な治療を施すのに役立つ支援システムを提供する意義を有するものである。

上記課題を解決するため、本願の請求項１記載の発明は、特定の疾病について特別の専門的知識と経験を有する者として認められる者である複数の指導的専門医の情報をデータベース化して記録した指導的専門医データベースファイルを含むデータベースサーバと、
指導的専門医データベースファイルに新たな指導的専門医の情報を記録して登録する登録手段と、
救急患者が治療を受ける病院の担当者が操作する一次端末と、
指導的専門医データベースファイルに情報が記録されている各指導的専門医によって操作される二次端末と、
コミュニケーションサーバと、
前記指導的専門医データベースファイルに記録された情報には、前記各二次端末のアドレス情報が含まれており、
さらに、
前記救急患者の患部を撮影した画像とその画像の撮影時刻との情報を含む情報である初期疾病情報を、前記一次端末から入力させ、前記指導的専門医データベースファイルに記録されたアドレス情報に従って前記コミュニケーションサーバを介して前記各二次端末に送信する一次送信手段と、
前記各二次端末に転送された前記初期疾病情報を前記各二次端末において受信して表示する受信表示手段と、
表示された前記初期疾病情報を確認した各指導的専門医に、当該救急患者についての追加検査の必要性の情報、どのような疾病であるかの情報又はどのように治療すべきかの情報である見解情報を各二次端末において各々入力させ、入力された見解情報を一次端末に送信する二次送信手段と、
各二次端末から送信された見解情報を一次端末に表示する見解情報表示手段とを備えており、
前記一次送信手段は、前記見解情報の送信期限とともに前記初期疾病情報を送信するものであり、
前記初期疾病情報が送信された際、各指導的専門医に対し、音、光、振動又はこれらの組み合わせから成るアラームを発するアラーム手段を備えているという構成を有する。
また、上記課題を解決するため、請求項２記載の発明は、前記請求項１の構成において、前記初期疾病情報を送信する前に、問い合わせ情報を前記一次端末から入力させて前記コミュニケーションサーバを介して前記各二次端末に送信する問い合わせ情報送信手段を備えており、
問い合わせ情報は、当該救急患者の疾病についての症状を記述したテキストと、前記初期疾病情報を送信した場合の前記見解情報の送信期限の情報とを含んでおり、送信期限内に前記見解情報を送信することができるかどうかを問い合わせる情報であり、
前記二次送信手段は、問い合わせ情報が転送された際、前記見解情報を送信することができるか否かの情報である可否情報を前記二次端末において入力させて前記一次端末に送信するものであり、
前記一次送信手段は、問い合わせ情報に対して、前記見解情報を送信することができる旨の可否情報が送信された前記二次端末に対してのみ前記初期疾病情報を転送するものであるという構成を有する。
また、上記課題を解決するため、請求項３記載の発明は、前記請求項１又は２の構成において、前記指導的専門医データベースファイルに登録された前記指導的専門医の情報には、各指導的専門医の専門性のレベルについての情報が含まれており、
前記一次送信手段は、前記指導的専門医データベースファイルに情報が登録された指導的専門医のうち、特定のレベルの指導的専門医のみを選び出してその指導的専門医が操作する前記各二次端末にのみ前記初期疾病情報を送信することができるものであるという構成を有する。
また、上記課題を解決するため、請求項４記載の発明は、前記請求項１、２又は３の構成において、前記二次送信手段は、前記コミュニケーションサーバを介して前記見解情報を前記一次端末に送信するものであり、前記コミュニケーションサーバは、前記見解情報が前記二次端末から送信された際に前記一次端末に転送するものであり、
前記初期疾病情報が送られた際、当該初期疾病情報を送った前記各二次端末と前記一次端末とをグループ化してリアルタイムコミュニケーションさせるリアルタイムコミュニケーション手段が設けられており、
リアルタイムコミュニケーション手段は、前記二次端末から前記見解情報が送られた際、当該見解情報を前記一次端末に送信するとともにグループの他の各二次端末にも送信するものであり、
前記一次端末及び前記各二次端末は、送信された前記見解情報に対する返信情報を入力させて前記コミュニケーションサーバに送信することが可能であり、
リアルタイムコミュニケーション手段は、返信情報が送信された際、送信元の一次端末又は二次端末以外のグループ内の各端末に返信情報を送信するものであり、
前記一次端末及び前記各二次端末は、送信された前記返信情報に対する再返信情報を入力させて前記コミュニケーションサーバに送信することが可能であり、
リアルタイムコミュニケーション手段は、再返信情報が送信された際、送信元の一次端末又は二次端末以外のグループ内の各端末に再返信情報を送信するものであるという構成を有する。
また、上記課題を解決するため、請求項５記載の発明は、前記請求項１乃至４いずれかの構成において、前記初期疾病情報を送信した後の救急患者の状態に関する情報又は追加検査、診断若しくは治療の情報である経過情報を前記一次端末において入力させて前記コミュニケーションサーバを介して前記各二次端末に送信する経過情報送信手段を備えており、
前記受信表示手段は、送信された経過情報を各二次端末で受信して表示する手段であるという構成を有する。
また、上記課題を解決するため、請求項６記載の発明は、前記請求項５の構成において、前記経過情報には、当該救急患者の状態に関する情報がいつの時点での情報であるか、又は当該追加検査、診断若しくは治療の情報がいつの時点での情報であるかを示す時間情報が含まれており、
前記経過情報送信手段は、前記各二次端末において、時間軸を示す直線であるタイムバー上に時系列的に前記経過情報が表示するよう前記経過情報を送信するものであるという構成を有する。
また、上記課題を解決するため、請求項７記載の発明は、前記請求項１乃至６いずれかの構成において、前記初期疾病情報に含まれる前記画像は動画であり、
前記一次送信手段は、前記画像を前記撮影機器が撮像している際、当該画像をリアルタイムで前記コミュニケーションサーバに送信するものであり、
前記コミュニケーションサーバは、送信された画像をリアルタイムで前記各二次端末に送信するものであるという構成を有する。
また、上記課題を解決するため、請求項８記載の発明は、前記請求項１乃至７いずれかの構成において、前記経過情報には動画が含まれており、前記経過情報送信手段は、当該画像を撮影機器が撮像している際、当該画像をリアルタイムで前記コミュニケーションサーバに送信するものであり、
前記コミュニケーションサーバは、送信された画像をリアルタイムで前記各二次端末に送信するものであるという構成を有する。
また、請求項９記載の発明は、前記請求項７又は８の構成において、前記画像は、前記救急患者の手術の際に撮影している患部の動画であるという構成を有する。
また、上記課題を解決するため、請求項１０記載の発明は、前記請求項１乃至７いずれかの構成において、前記画像は、撮影機器で取得されたデータを処理して得られた画像であり、
前記二次端末において表示される前記画像を再構築する画像再構築手段が設けられており、
画像再構築手段は、画像再構築プログラムが実装された画像再構築サーバを備えており、
前記受信表示手段は、前記画像を再構築する指令である画像再構築指令を前記二次端末において入力させて画像再構築サーバに送信することが可能となっており、
画像再構築プログラムは、画像再構築指令が送信された画像のデータを再処理して再構築した画像を生成して前記二次端末に送信し、前記受信表示手段により前記二次端末に表示するものであるという構成を有する。
また、上記課題を解決するため、請求項９記載の発明は、前記請求項１乃至９いずれかの構成において、記録手段及び記録サーバが設けられており、
記録サーバの記憶部には、各救急患者についての治療履歴情報をデータベース化して記録した履歴情報ファイルが設けられており、
記録手段は、各救急患者について、前記一次送信手段が前記各二次端末に初期疾病情報を送信した旨の情報を履歴情報ファイルに記録するとともに、前記各二次端末から前記見解情報が送信された旨と当該見解情報の内容とを履歴情報ファイルに記録するものであるという構成を有する。
また、上記課題を解決するため、請求項１０記載の発明は、前記請求項９の構成において、前記二次送信手段は、前記見解情報を入力する前記指導的専門医のデジタル署名を前記見解情報とともに前記一次端末に送信するものであり、
前記記録手段は、前記見解情報とともにその見解情報を入力した前記指導的専門医のデジタル署名を前記履歴情報ファイルに記録するものであるという構成を有する。

以下に説明する通り、本願の請求項１記載の発明によれば、複数の指導的専門医に対して画像を含む初期疾病情報が回答期限とともに送信され、各指導的専門医からは初期疾病情報を踏まえての見解情報が返信されるので、担当医は、各見解情報を参照して診断をしたり治療方針を決定したりすることができる。このため、担当医が単独で決定して治療を行う場合に比べてより適切な治療を行える場合が多くなる。
また、請求項２記載の発明によれば、上記効果に加え、初期疾病情報の送信の前に問い合わせ情報を送信し、対応可能と返信してきた指導的専門医にのみ初期疾病情報を送信して見解情報を求めるので、対応できない指導的専門医に対して無駄に初期疾病情報を送ることが無くなる。指導的専門医の側でも、対応できない案件についてむやみに初期疾病情報が送信されることがないので、煩雑さが生じない。また、初期疾病情報は患者の画像を含むので、対応可能と回答してきた指導的専門医に対してのみ送信することは、個人情報保護の観点からも望ましい。
また、請求項３記載の発明によれば、上記効果に加え、指導的専門医の専門性レベルについて特定のレベルの者のみを選び出して初期疾病情報を送ることができるので、疾病の特殊性、診断や治療の難易性等に応じて最適なレベルを設定して見解情報の提供を要請することができる。このため、より適切な見解情報を得ることにつながり、より適切な治療を行うことに貢献できる。
また、請求項４記載の発明によれば、上記効果に加え、リアルタイムコミュニケーション手段が設けられているので、一つの救急疾病や一つの見解情報に対して多くの指導的専門医が見解を述べて討議することが可能となる。このため、多くの見解を積み重ねることでより適切な結論に達することが可能となり、この点でさらに適切な治療を行えるようになる。
また、請求項５記載の発明によれば、上記効果に加え、経過情報送信手段を備えているので、初期疾病情報を送信した後の状況に応じてさらに見解情報を求めることも可能になり、この点で、さらに適切な治療が行えるようになる。
また、請求項６記載の発明によれば、上記効果に加え、経過情報は、時間軸を示す直線であるタイムバー上に時系列的に示されるので、時間経過の中でどのような状況であるかを指導的専門医が容易に把握することができる。
また、請求項７又は８記載の発明によれば、上記効果に加え、画像がリアルタイムで各二次端末に送信されるので、より短時間に見解情報を送信してもらうことが可能になる。このため、救急患者の治療を支援する上でより好適なものとなる。
また、請求項９記載の発明によれば、リアルタイム送信される動画が手術中の患部の映像なので、手術の進行状況等について即座に見解情報を送信してもらうことが可能になる。このため、救急患者の治療を支援する上でより好適なものとなる。
また、請求項１０記載の発明によれば、上記効果に加え、画像再構築手段が設けられており、指導的専門医の側で画像を自由に再構築して確認することができるので、より適切な見解情報を提供することができる。
また、請求項１１記載の発明によれば、上記効果に加え、記録サーバの履歴情報ファイルに、初期疾病情報を送信して見解情報を求めた旨と指導的専門医から寄せられた見解情報とが記録されて保存されるので、適切な取り扱いをした旨の証拠として後に利用することができる。
また、請求項１２記載の発明によれば、上記効果に加え、見解情報をデジタル署名付きで受信することができ、デジタル署名とともに見解情報を履歴情報ファイルに保存するので、見解情報の受信やその内容に対する信憑性（証拠価値）が高くでき、この点で好適なものとなる。

は、本願発明の実施形態に係る救急患者治療支援システムの概略図である。 は、本実施形態のシステムを利用した救急患者の治療について段階的且つ概略的に示した業務フロー図である。 は、指導的専門医データベースファイルの構造を示した概略図である。 は、テンプ案件ＤＢＦの構造の一例を示した概略図である。 は、テンプ送信先ＤＢＦの構造の一例を示した概略図である。 は、救急疾病支援プロジェクトのメニューフォームの一例の概略図である。 は、問い合わせ情報入力フォームの一例を示した概略図である。 は、問い合わせ情報送信フォームの一例を示した概略図である。 は、問い合わせ情報送信プログラムの概略を示したフローチャートである。 は、二次端末に表示された問い合わせメールの一例を示した概略図である。 は、可否情報送信プログラムによって一次端末に送信された対応可伝達メールの一例を示した概略図である。 は、初期疾病情報送信フォームの一例を示した概略図である。 は、二次端末において受信されて表示された初期疾病情報メールの一例を示した概略図である。 は、図１３において画像閲覧ボタンがクリックされた状態の一例を示した概略図である。 は、画像再構築ボタンがクリックされた際の二次端末の状態の一例を示した概略図である。 は、図１５において「回転」のコマンドボタンがクリックされた状態の一例を示した概略図である。 は、見解情報送信フォームの一例を示した概略図である。 は、二次送信プログラムの概略を示したフローチャートである。 は、一次端末に送信されて表示された見解情報表示メールの一例を示した概略図である。 は、回答有無表示フォームの一例を示した概略図である。 は、一次端末に表示された回答統合表示フォームの一例を示す概略図である。 は、画像取り込みフォームの一例を示した概略図である。 は、画像のファイル情報が取り込まれた後の初期疾病情報送信フォームの一例を示した概略図である。 は、一括型一次送信プログラムの概略を示したフローチャートである。 は、見解有無表示フォームの一例を示した概略図である。 は、見解情報統合表示フォームの一例を示した概略図である。 は、図２６において詳細ボタンがクリックされた状態の一例を示す概略図である。 は、リアルタイムコミュニケーション手段により自動転送された見解情報メールの一例を示す概略図である。 は、二次端末に送信された経過情報アラームメールの一例を示した概略図である。 は、二次端末に送信された経過情報の一例を示した概略図である。

次に、本願発明を実施するための形態（以下、実施形態）について説明する。
図１は、実施形態の救急患者治療支援システム（以下、単に支援システムという）の概略図である。図１に示す支援システムは、救急患者の治療を行う病院（以下、単に病院という）の担当者が操作する端末である一次端末１と、指導的専門医が操作する端末である二次端末２との間でインターネットのようなネットワークを介して情報のやり取りをすることで治療を支援するものである。

病院としては、救急指定を受けた病院である場合が多いが、必ずしも救急病院ではなくとも救急患者が運び込まれる場合があり、救急指定病院には限られない。
また、本実施形態の支援システムは、脳血管障害のような重篤な救急患者の治療に特に適したシステムであり、病院としては重篤な救急患者の受け入れ可能な病院であることが想定されているが、そのような場合に限られる訳ではない。
実施形態の説明において、端末とは、情報の入出力が行われるコンピュータのことであり、ネットワークを介して情報を送受信したり、受信した情報を画面に表示したりすることができるものであって、典型的にはパソコンや携帯電話、ＰＤＡ等である。携帯電話の場合、いわゆるスマートフォンが含まれるのは言うまでもない。
一次端末１を操作する「担当者」とは、典型的には、救急患者を治療する担当となった医者（以下、担当医という）であるが、担当医から指示を受けた担当者とは別の者（看護士や事務職の者）が操作する場合もあり、これらが「担当者」となる場合もある。

指導的専門医とは、特定の疾病の治療について特別の専門的知識と経験を有する者として認められる者である。「経験」とは、疾病についての診断、治療又はその両方の経験を指している。
現在、各科の学会等では、それぞれの分野において高度な専門的知識や技量、知識を持つ医師を専門医として認定している。専門医になるには、多くの場合、まず学会の認定医になった後、さらに研修や実習、試験等を経て専門医としての認定を受ける。
本実施形態における指導的専門医とは、このような専門医よりさらに高いレベルの専門性を持つ医師である。具体的には、いわゆる指導医やそれに類するレベルの医師が想定されている。指導医とは、専門医よりもさらに高度の知識や技量、経験を有し、認定医や専門医を指導する立場にある医師を一般的に指す。本実施形態の指導的専門医とは、このような指導医又は指導医と同等ないしそれ以上のレベルの者が想定されている。但し、後述するように、本実施形態においては、指導的専門医は、見解情報を提供してもらう相手側であり、どの程度の知識、技量、経験を有する者に見解情報を提供してもらうかは、状況により適宜決定すれば良い。したがって、専門医よりも高い知識等を有することは必要であるが、指導医よりも低いレベルの者であっても指導的専門医として見解情報を提供してもらうこともあり得る。

本実施形態の支援システムは、上記一次端末１及び二次端末２と、サーバ群等によって構成されている。各一次端末１とサーバ群は、病院内に設けられたイントラネット１０に接続されている。イントラネット１０は、不図示のファイアウォールを介してインターネットに接続されており、不正なアクセスが防止されている。
サーバ群のうちの一つは、一次端末１と二次端末２との間のコミュニケーションを仲介するコミュニケーションサーバ３である。サーバの別の一つは、上記指導的専門医の情報を記録した指導的専門医データーベースファイル等を管理するデーターベースサーバ４である。さらに別のサーバとして、記録サーバ５、ＰＡＣＳサーバ６及び電子カルテサーバ７がイントラネット１０上に設けられている。これらのサーバは、それぞれのサーバコンピュータとして設けられることもあるが、一つのサーバコンピュータが二つ以上の異なるサーバの役割を兼用するよう設けられる場合もある。後者の場合は、一つのサーバコンピュータが二以上の異なるサーバの役割を果たすようサーバプログラムが実装される。

病院内には多くの職員がいるから、一次端末１も多数存在する。一次端末１は、パソコン（デスクトップ又はノート）であったり、携帯電話やＰＤＡのような携帯端末であったりする。パソコンやワークステーションの場合、イントラネット１０上に有線ＬＡＮを介して設けられている。携帯端末の場合、インターネットのような公衆回線を介してイントラネット１０に接続されるのが一般的であるが、病院内に設けられた無線ＬＡＮを介してイントラネット１０と直接つながっている場合もある。

また、病院には、各種検査機器が接続されている。これら検査機器には、ＭＲＩやＸ線ＣＴといった検査結果を画像として得る機器（以下、撮影機器と呼ぶ）が含まれている。また、撮影機器が出力する画像をサーバで一括管理するＰＡＣＳ(Picture Archivingand Communication System)もイントラネット１０上に設けられている。ＰＡＣＳは、ＰＡＣＳサーバ６を含んでおり、ＰＡＣＳサーバ６内の画像データは、イントラネット１０を介して一次端末１等で取得できるようになっている。さらに、イントラネット１０上には、電子カルテシステムも設けられている。電子カルテシステムは、電子カルテサーバ７を含んでおり、電子カルテサーバ７内の電子カルテデータも、イントラネット１０を介して一次端末１等で取得できるようになっている。これらＰＡＣＳや電子カルテシステムは、各医療情報システムメーカーから販売されているので、適宜選択して用いれば良い。

本実施形態のシステムの各部の詳しい説明の前に、本実施形態のシステムを利用しつつ行われる救急患者の治療の業務フローについて概略的に説明する。
図２は、本実施形態のシステムを利用した救急患者の治療について段階的且つ概略的に示した業務フロー図である。
図２に示すように、業務は、救急患者が発生したことの連絡を受けることから始まる。この連絡は、受け入れが可能かを消防署や救急隊員が問い合わせてくることであるが、救急患者の家族等が直接問い合わせてくることもある。
問い合わせを受けた病院側は、対応できる医者がいるか、ＩＣＵのような治療施設に空きがあるか等を確認し、しかるべき者が受け入れを決定する。この際、対応できる医者が非番でいない場合、携帯電話等に連絡を入れ、救急車の到着に合わせて職務に就くことが可能かを聞き、可能であれば受け入れ可能の返事をする。

救急車が到着して患者が搬入されると、容態を確認し、必要な検査をすぐさま行う。この検査には、ＭＲＩやＣＴスキャンのような撮影機器を利用した検査が含まれる（以下、この検査で得られた画像を「初期疾病画像」と呼ぶ）。体温や血圧のような比較的簡単な検査は、搬送中に救急車内で行われることもある。
初期的な患者の検査の後、またはこれと並行して、電子カルテの作成が行われる。その病院で過去に治療したことのある患者の場合には、電子カルテの新規作成は行われず、診断や治療が一段落した際に電子カルテの更新が行われる。

次に、実施形態の支援システムを利用するかどうかの決定が行われる。利用するかどうかとは、他の病院ないし機関に所属する指導的専門医に見解を求めた上で診断や治療を行うかどうかの決定である。この決定は、当然のことながら、その救急患者の担当となった医者（担当医）において、どのような疾病であるか（診断）や、どのように治療すべきか（治療方針）や、追加検査が必要であるかどうか等について、自らの判断のみで決定できるかどうかの検討が含まれる。自らの判断では決定できないと思われる場合や、自らの判断では決定できるものの、指導的専門医の見解を求めるべきであると思われる場合には、この支援システムを利用することになる。

支援システムを利用しないとの決定の場合、自らの判断で診断を行い、必要と判断された追加検査等を行いながら、治療を実行する。一方、支援システムを利用すると決定した場合、どの程度高いレベルの指導的専門医に見解を求めるべきかを決定した後、各指導的専門医に、見解を提供することが可能かどうかを事前に問い合わせる問い合わせ情報を一次端末１から送信する。
見解の提供が可能であると返信してきた指導的専門医が全くいない場合、専門性のレベルを下げるかどうかを検討し、下げない場合には、支援システムの利用は諦め、独力での診断・治療とする。レベルを下げる場合には、低いレベルに設定し直して問い合わせ情報を一次端末１から改めて送信する。
見解の提供が可能であると返信してきた指導的専門医が一人以上いる場合には、その段階で得られている疾病の情報（初期疾病画像を含む。以下、初期疾病情報と呼ぶ。）を指導的専門医に送り、見解を求める。この見解は、どのような疾病であるかの情報（診断情報）、どのように治療すべきかの情報（治療方針情報）又は追加検査が必要かどうかの情報（追加検査要否情報）である。これらの情報が組み合わせられて寄せられる場合もある。以下、これらの情報をまとめて見解情報と呼ぶ。

初期疾病情報は二次端末２に送られ、各指導的専門医が二次端末２上で初期疾病情報を表示して内容を検討し、見解情報を二次端末２から返信する。担当医は、返信された見解情報を院内の一次端末１で確認する。また、状況に応じて、見解情報を寄せた各指導的専門医や担当医の間でチャット会議のようなリアルタイムコミュニケーションを行う。担当医は、これらを踏まえて、診断や必要な追加検査、治療方針決定等を行った後、治療を実行する。

以上の業務を行うのに利用される本実施形態の支援システムの各部の構成について、以下に詳しく説明する。
まず、データベースサーバ４について説明する。データベースサーバ４は、データベース管理プログラムを実装したサーバであり、サーバの記憶部（ハードディスクのような記憶装置）には、各種のデータベースファイルが記憶されている。
データベースファイルの一つは、指導的専門医の情報を記録した指導的専門医データベースファイル（以下、指導的専門医ＤＢＦ）である。この他、病院に勤務する医師（勤務医）の情報を記録した勤務医データベースファイル（以下、勤務医ＤＢＦ）や、本システムの利用の管理のために一時的に情報が記録されるテンプ案件ＤＰＦや、同様に管理のために案件毎に二次端末２の情報を一時的にデーターベース化するテンプ送信先ＤＢＦ等がデーターベースサーバの記憶部に記憶されている。

図３は、指導的専門医ＤＢＦの構造の一例を示した概略図である。図３に示すように、指導的専門医データーベースファイルは、指導的専門医を特定するコードである専門医ＩＤ、専門医氏名、端末アドレス等の指導的専門医についての各種情報をデータベース化したものである。
端末アドレスは、情報の送信先としての二次端末２を特定する情報である。本実施形態では、端末アドレスとして、「端末識別情報」と「メールアドレス」とが記録されるようになっている。このうち、「端末識別情報」は、その指導的専門医が操作する二次端末２を識別する情報であり、パソコン等の場合にはＩＰアドレス又はマックアドレスであり、携帯電話にはいわゆる個体識別番号である。情報の送受信にメールを使用する場合には端末アドレスとしてメールアドレスが使用されることになるが、ｆｔｐのようなサーバプログラムによる場合には、端末識別情報が使用されることもある。

また、「専門分野」は、その指導的専門医が指導的専門医であるとされる治療科目の分野の情報である。「専門分野コード」は、検索等のために各専門分野について付与されたコード情報である。
「専門性レベル」は、その指導的専門医が専門分野においてどの程度のレベルの専門性を有するかの情報である。本実施形態では、ＡＡ、Ａ、Ｂの三つのランクでレベル付与されるようになっており、ＡＡが最も高く、Ｂが最も低い。一例としては、Ｂのレベルが通常の指導医のレベルで、ＡＡがその分野でいわゆる権威として名の通った指導医のレベルとし、Ａをその中間程度のレベルとすることができる。この他、指導的専門医データーベースファイルには、その指導的専門医の所属機関等の情報が登録されるようになっている。また、図示はされていないが、指導的専門医ＤＢＦには、指導的専門医のレベルを推し量る参考情報として、「プロフィール」のフィールドと、「手術回数」のフィールドが設けられている。

また、同様に図示はされていないが、指導的専門医ＤＢＦには、「端末タイプ」の名前のフィールドが設けられている。「端末タイプ」は、二次端末の種類を登録したフィールドである。このフィールドには、「第３世代携帯電話」、「スマートフォン」、「パソコン」といった端末の種類の情報が記録される。この情報は、後述するように、画像を送信する際の圧縮レベルの選択等に利用される。

本実施形態の支援システムは、上記のような指導的専門医の情報を指導的専門医データベースファイルに登録する登録手段を備えている。イントラネット１０上には、病院の事務担当が操作する一次端末１である管理用端末が設けられており、上記のような指導的専門医に関する各情報は、後述するように管理用端末等において入力され、指導的専門医データーベースファイルに記録されて登録される。したがって、管理用端末やデータベースサーバ４等により登録手段が構成されている。
尚、本システムで情報がデータベース化される指導的専門医については、後述する問い合わせ情報の送付相手として予め了解を取っており、上記各情報が指導的専門医側から電子メール、ＦＡＸ又は郵便等で送られる。事務担当が管理用端末を操作し、指導的専門医データベースファイルにアクセスし、送られた情報を入力して指導的専門医ＤＢＦに記録しておく。

端末識別情報等は、インターネットを介して二次端末２にアクセスさせ、その際のセッション情報から取得するのが簡便であるので、そのような手法が取られる。例えば、コミュニケーションサーバ３へのアクセス情報（ＵＲＬ等）を記載した電子メールを二次端末２に送り、そこからコミュニケーションサーバ３にアクセスしてもらうようにする。コミュニケーションサーバ３では、セッション情報から端末識別情報や電子メールアドレスを読み取り、それをデーターベースサーバに送って記録するようにする。このようなシステム構成は、会員登録を行うサイトにおけるシステムと同様にできるので、詳細な説明は割愛する。

次に、勤務医ＤＢＦについて説明する。図示は省略するが、勤務医ＤＢＦは、各勤務医について付与されたＩＤである勤務医ＩＤ、勤務医氏名、治療科目等の情報をデータベース化したものである。また、各勤務医には、セキュリティのためのパスワードが与えられており、パスワードの情報も勤務医ＤＢＦの各レコードに記録されている。

次に、テンプ案件ＤＢＦ及びテンプ送信先ＤＢＦについて説明する。
図４は、テンプ案件ＤＢＦの構造の一例を示した概略図である。図４に示すように、テンプ案件ＤＢＦは、案件ＩＤ、勤務医ＩＤ、問い合わせ情報送信日時、対応可の有無等の情報がデータベース化されている。
図５は、テンプ送信先ＤＢＦの構造の一例を示した概略図である。テンプＤＢＦは、一人の救急患者の治療についての本システムの利用（案件）ごとに新しく作成されるデータベースファイルである。テンプ送信先ＤＢＦは、図４に示す案件ＩＤをファイル名にして作成される。図５に示すように、テンプＤＢＦには、問い合わせ情報を送信した相手先の指導的専門医の情報がデータベース化されている。各レコードには、問い合わせ情報の送信日時に加え、可否情報や初期疾病情報の送信日時等の情報も記録されるようになっている。

次に、コミュニケーションサーバ３について説明する。
コミュニケーションサーバ３は、各端末１，２との間でクライアント−サーバ環境を実現し、各種業務や情報を提供するものである。主要なサービスの一つは、各端末間での情報のやり取りの仲介である。情報のやり取りの多くは、電子メールの送受信で行われるので、コミュニケーションサーバ３は、メールを転送するサーバサイドプログラムであるＭＴＡ(Mail Transfer Agent)を実装している。例えば、sendmail、qmail等である。この他、通常のウェブサーバと同様に、ＨＴＭＬプロトコルでファイルを提供したり、ＦＴＰでファイルを転送したりすることもできるようになっている。これらの構成は、通常のウェブサーバと同様なので、説明は省略する。

また、実施形態の支援システムは、初期疾病情報を入力させて送信する一次送信手段を備えている。一次送信手段は、コミュニケーションサーバ３と、コミュニケーションサーバ３に実装された一次送信プログラムによって構成されている。
コミュニケーションサーバ３には、一次送信プログラムの他、本実施形態の支援システムを利用した業務のための特別のプログラムが実装されている。これらプログラムは、互いに関連づけられて統合されている。説明の便宜上、プログラムの上位概念としてプロジェクトという用語を用い、統合されたプログラム群からなるものを救急疾病支援プロジェクトと呼ぶ。

救急疾病支援プロジェクト内の各プログラムは、一例としてＪａｖａやＶＢ(Microsoft
Visual Basic)等といったオブジェクト指向プログラミング言語で記述されている。コミュニケーションサーバ３の記憶部には、情報の入力のための各種のフォームウインドウ（以下、単にフォーム）を端末に表示するファイル（以下、フォームファイル）が記憶されている。各フォームファイルには、プログラムを起動するためのボタン（コマンドボタン）が必要に応じて埋め込まれている。また、コミュニケーションサーバ３の記憶部には、問い合わせ情報や初期疾病情報等を入力して送信するためのフォームを提供する各種ファイルが記憶されており、端末から送信要求があった際にファイルを送信し、端末上にフォームを表示するようになっている。
また、救急支援プロジェクト内の各プログラムは、コミュニケーションサーバ３内の所定のＵＲＬ（例えば、http://www.99medical.gr.jp/project/）に記述されている。各端末間の情報の送受信はＵＲＬを通して行われる。各端末からこのＵＲＬにアクセスがされているとき、セッション変数には各種の情報が格納され、各端末１，２間や各フォーム間での情報の受け渡しが行われる。

救急支援プロジェクト内の各プログラムの多くは、病院内の各一次端末１に対して治療支援業務を行わせるプログラムとなっている。これらのプログラムを起動させるためのメニューフォームが用意されており、そのファイル（以下、メニューフォームファイル）が記憶部に記憶されている。
図６は、救急疾病支援プロジェクトのメニューフォームの一例の概略図である。メニューフォームファイルは、端末のＯＳに依存した通常動作画面（ウインドウズの場合にはいわゆるデスクトップ）に設けられたアイコンのクリックで記憶部から読み出され、ディスプレイに表示されるようになっている。図６に示す例は、表示する一次端末１がパソコンである例となっている。メニューフォームは一次端末１が携帯端末の場合でも表示可能であり、携帯端末用のメニューフォームのファイルが別途コミュニケーションサーバ３の記憶部に記憶されている。

図６に示すように、メニューフォームでは、「指導的専門医情報新規登録」と表記されたコマンドボタン（以下、専門医情報登録ボタン）３１が設けられている。専門医情報登録ボタン３１は、指導的専門医データーベースファイルに新しいレコードを追加して指導的専門医の情報を登録するためのコマンドボタンである。
コミュニケーションサーバ３の記憶部には、図４に示す指導的専門医データーベースファイルのレコードの各フィールドの情報を入力するためのフォーム（以下、専門医情報入力フォーム）用のファイルが記憶されている。専門医情報登録ボタン３１がクリックされると、このファイルが読み出されて専門医情報入力フォームが端末上に表示される。専門医情報入力フォームには登録用のコマンドボタン（登録ボタン）が設けられており、情報を入力した上で登録ボタンをクリックすると、データーベースサーバ上のデーターベースプログラムが起動し、レコードが追加されて入力情報がファイルに記録されるようプログラミングされている。

また、図６に示すように、メニューフォームには、「指導的専門医情報更新」と表記されたコマンドボタン（以下、専門医情報更新ボタン）３２が設けられている。コミュニケーションサーバ３の記憶部には、指導的専門医の登録情報を更新するためのフォーム（以下、専門医情報更新フォーム）用のファイルが記憶されている。専門医情報更新ボタン３２がクリックされると、指導的専門医の氏名又は専門医ＩＤ等を入力させるウインドウが表示され、入力された情報により指導的専門医データーベースファイルが検索されて該当するレコードの情報が専門医情報更新フォームに組み込まれて表示される。専門医情報更新フォームにも登録ボタンが設けられており、表示された各情報は端末上で変更可能となっている。任意の情報を変更して登録ボタンがクリックされると、変更後の情報がデーターベースサーバに送られ指導的専門医データーベースファイルの該当レコードに記録されてファイルが更新されるようプログラミングされている。

本実施形態では、初期疾病情報を送信する前に、問い合わせ情報を一次端末から入力させてコミュニケーションサーバに送信する問い合わせ情報送信手段が設けられている。問い合わせ情報送信手段は、コミュニケーションサーバ３と、コミュニケーションサーバ３に実装された問い合わせ情報送信プログラム等によって構成されている。
具体的に説明するお、図６に示すように、メニューフォームには、「問い合わせ情報送信」と表記されたコマンドボタン（以下、問い合わせ送信ボタン）３３が設けられている。一方、コミュニケーションサーバ３の記憶部には、問い合わせ情報入力フォームのファイル及び問い合わせ情報送信フォームのファイルが記憶されている。

図７は、問い合わせ情報入力フォームの一例を示した概略図である。
図７に示すように、問い合わせ情報入力フォームは、救急搬送日時入力欄、性別入力欄、年齢入力欄、患者ＩＤ入力欄、患者氏名入力欄、初期所見入力欄３４、治療科目入力欄、レベル入力欄、回答期限入力欄を有している。また、「確認画面」と表記されたコマンドボタン（以下、確認ボタン）３５が設けられている。
救急搬送日時入力欄は、救急患者が搬送された日時を入力する欄であり、「時刻・カレンダー」と表記されたコマンドボタンをクリックすることにより、プルダウンリストによる時刻表示やカレンダーが表示され、時刻や日時を容易に選択して入力できるようになっている。
性別入力欄は、いわゆるラジオボタンであり、いずれかを選択する。
年齢入力欄は、年齢の数字がプルダウンリストで表示され、いずれかを選択する欄である。

患者ＩＤの欄は、この段階で判っていれば入力される。救急搬送され、家族が同伴している等しており、保険証や診察券等を持参していれば、それに従って電子カルテサーバを検索し、患者ＩＤの情報を取得してこの欄に入力する。
初期所見入力欄３４は、テキストボックスである。初期所見入力欄３４は、各指導的専門医に対して見解情報を寄せることが可能かどうかを問い合わせるに際して、当該救急患者の容態について初期的な所見を文字情報で送信するものである。例えば、「激しい頭痛を訴えて救急搬送された」とか、「○○の疑いがある」とかの文字情報が入力される。また、脳神経系の疾病の場合、患者の意識レベルや神経症状といった神経学的所見が含まれることが多い。

診療科目入力欄は、プルダウンリストであり、見解情報を寄せて欲しい指導的専門医が属する診療科目を選んで入力する。当然のことながら、これは、初期所見の段階での患者の容態から判断ないし推測される診療科目ということになる。
レベル入力欄は、見解情報を寄せて欲しい指導的専門医のレベルを設定する欄である。本実施形態では、「ＡＡ」、「Ａ」、「Ｂ」というレベルから選んで設定するようになっているので、レベル入力欄もこれらが表示されるプルダウンリストになっている。尚、「ＡＡ」を選べばＡＡのレベルの指導的専門医を選んだことになり、「Ａ」を選べばＡのレベル以上だから、「ＡＡ」又は「Ａ」のレベルということになり、「Ｂ」を選べば「ＡＡ」、「Ａ」又は「Ｂ」のレベルということになる。
回答期限入力欄は、見解情報を寄せることができるかどうか回答の期限を入力する欄である。例えば、「１時間以内」、「３時間以内」、「５時間以内」、「７時間以内」・・・というように、問い合わせ情報の送信があってからの時間で回答期限を設定するようになっている。これ以外にも、「本日１９時まで」、「本日２１時まで」、「本日２３時まで」というように、日時を指定して回答期限としても良い。
「担当医」と表記された欄は、入力された勤務医ＩＤに従って自動的に表示される。即ち、メモリ変数から勤務医ＩＤが読み出され、勤務医ＤＢＦが検索されて勤務医の氏名の情報が取得され、この欄に嵌め込まれて表示されるようになっている。

図８は、問い合わせ情報送信フォームの一例を示した概略図である。図７において、各欄が正しく入力されて確認ボタン３５がクリックされると、図８に示す問い合わせ情報送信フォームが表示されるようになっている。但し、図８に示す情報のうち、患者ＩＤ及び患者氏名については、送信されない。このような患者を特定できる情報を院外の第三者に開示することはプライバシー保護の観点で好ましくないので、担当医において画面上確認できるだけにしてあり、二次端末には送信されないようになっている。
問い合わせ情報送信フォームでは、問い合わせ情報入力フォームで入力された各情報が確認のために表示される。そして、送信ボタン３６がクリックされると、入力された各情報がコミュニケーションサーバ３に送信されるようになっている。即ち、送信ボタン３６には、問い合わせ情報プログラムの起動コマンドが埋め込まれている。この起動コマンドは、問い合わせ情報入力フォームで入力された各情報を引数として渡して問い合わせ情報送信プログラムを起動する。

図９は、問い合わせ情報送信プログラムの概略を示したフローチャートである。図９に示すように、問い合わせ情報送信プログラムは、診療科目入力欄及びレベル入力欄の情報をデータベースサーバ４に送り、指導的専門医ＤＢＦを検索して該当するレコードがあるかどうか判断する。即ち、その診療科目にそのレベルの指導的専門医がいるかどうか判断する。レコードが全くない場合、「該当する指導的専門医は登録されていません。」というエラーメッセージが表示され、プログラムを終了させる。この場合、問い合わせ情報入力フォームが再び表示される。
該当するレコードがある場合、そのレコードの専門医ＩＤ、氏名、端末アドレスを読み出して各々メモリ変数に一時的に格納する。すべてのレコードの検索が終了したら、案件ＩＤを新たに生成し、テンプ案件ＤＢＦに新たなレコードを追加し、案件ＩＤ、勤務医ＩＤ、問い合わせ情報送信日時等の情報を記録する。次に、案件ＩＤをファイル名にしてテンプ送信先ＤＢＦを新たに作成し、ヒットした指導的専門医ＤＢＦの各レコードから読み出した専門医ＩＤ、氏名、端末アドレスの情報をそれぞれのレコードの情報として記録する。
その後、コミュニケーションサーバ３の記憶部に記憶されているメールフォームを読み出し、問い合わせ情報入力フォームで入力された情報を嵌め込む。そして、指導的専門医ＤＢＦから読み出した各端末アドレスに順次送信する。

本実施形態の支援システムは、送信された情報を各二次端末２において受信して表示する受信表示手段を備えている。受信表示手段は、各二次端末２と、各二次端末２にインストールされている受信表示プログラムによって構成されている。本実施形態では、各情報は電子メールの形で送信されるので、受信表示プログラムは、各二次端末２にインストールされたメーラ（電子メールプログラム）ということになる。
上記のように問い合わせ情報が嵌め込まれた電子メール（以下、問い合わせメール）は、インターネットを介して各二次端末２に送信される。問い合わせメールは、受信表示手段によって各二次端末２で受信されて表示される。図１０は、二次端末２に表示された問い合わせメールの一例を示した概略図である。図１０では、二次端末２がスマートフォンであり、問い合わせメールがスマートフォン上に表示された状態が描かれているが、他の種類の携帯電話の場合もあり、ノートパソコンやデスクトップパソコンの場合もある。

図１０に示すように、受信した問い合わせメールは、問い合わせ情報入力フォームで入力された各情報が表示されるようになっている。この例では、回答期限は、問い合わせ情報の送信から例えば１時間後が設定されており、問い合わせ情報送信プログラムが一時間後の時間を計算してメールに嵌め込んでいる。
尚、この例では、二次端末２のメーラ上では送信元の表示は、コミュニケーションサーバ３の登録名となってしまい（この例では「救急患者治療支援システム」）、送信元の医師が特定できなくなってしまうので、問い合わせ情報を入力した勤務医の氏名や所属が表示されるようにしている。

本実施形態の支援システムは、問い合わせ情報が送信された際、見解情報を送信することができるか否かの情報である可否情報を二次端末２において入力させて一次端末１に送信する可否情報送信手段を備えている。可否情報送信手段は、本実施形態では、問い合わせメールに嵌め込まれた可否情報送信ボタンと、コミュニケーションサーバ３と、可否情報送信プログラム等によって構成されている。
図１０に示すように、問い合わせメールには、「対応可能」との表記がされたコマンドボタン（以下、可能ボタン）２１と、「対応不可」と表記されたコマンドボタン（以下、不可ボタン）２２とが嵌め込まれている。これらのボタンが、可否情報送信ボタンである。

本実施形態では、可否情報送信プログラムは、サーバサイドのプログラムとなっている。即ち、可否情報送信プログラムは、コミュニケーションサーバ３に実装されており、可否情報送信ボタンによって起動するようになっている。
可否情報送信ボタンには、生成された案件ＩＤと可否情報を意味するコードとが埋め込まれている。即ち、可能ボタン２１には、案件ＩＤと、対応可能である旨を意味するコード（例えば、"Yes"）と、送信元アドレス（二次端末２のメールアドレス）とを引数にして可否情報送信プログラムを実行するコマンドが埋め込まれており、不可ボタン２２には、案件ＩＤと、対応不可である旨を意味するコード（例えば、"No"）と、送信元アドレスとを引数にして可否情報送信プログラムを実行するコマンドが埋め込まれている。

可否情報送信プログラムは、案件ＩＤがファイル名になっているテンプ送信先ＤＢＦを開き、送信元アドレス又はセッション情報から取得した端末識別情報に従って該当するレコードの「可否情報」の欄に値（上記の例では"Yes"又は"No"）を記録するようプログラミングされている。そして、テンプ案件ＤＢＦを開き、該当する案件ＩＤのレコードの「対応可の有無」のフィールドに値（例えば"Yes"）を記録するようプログラミングされている。
可否情報送信プログラムは、次に、一次端末１にメールの送信を行うようプログラミングされている。このメールの送信は、対応可との情報が送信された場合（可能ボタンがクリックされた場合）のみ行われるものであり、対応可との情報の送信があった旨を即座に担当医に知らせるためのものである（以下、このメールを対応可伝達メールという）。

図１１は、可否情報送信プログラムによって一次端末１に送信された対応可伝達メールの一例を示した概略図である。図１１に示すように、可否情報伝達メールでは、担当医が送信した問い合わせ情報を確認のために送るとともに、対応可能と回答してきた指導的専門医の氏名やプロフィール情報を送るようになっている。コミュニケーションサーバ３の記憶部には、このようなメールのテンプレートファイルが記憶されており、可否情報送信プログラムは、テンプレートファイルにこれら情報を組み込んで一次端末１に送信するようプログラミングされている。
本実施形態の支援システムは、対応可との回答があった指導的専門医が操作する二次端末２に対し、初期疾病情報を送信して正式に見解情報の提供を要請する一次送信手段を備えている。一次送信手段は、初期疾病情報を、一次端末１において入力させてコミュニケーションサーバ３に送信し、指導的専門医データベースファイルに記録されたアドレス情報に従ってコミュニケーションサーバ３から各二次端末２に到達するよう送信する手段である。初期疾病情報には、救急患者の画像と画像の撮影時刻との情報が含まれている。

具体的に説明すると、一次送信手段は、一次端末１と、コミュニケーションサーバ３と、コミュニケーションサーバ３に実装された一次送信プログラム等によって構成されている。コミュニケーションサーバ３の記憶部には、初期疾病情報を送信するためのフォーム（以下、初期疾病情報送信フォーム）用のファイルが記憶されている。図１１に示すように、可否情報伝達フォームには、「初期疾病情報送信」と表記されたコマンドボタン２３が設けられている。このボタンは、初期疾病情報送信フォームのファイルを読み出して一次端末１に初期疾病情報送信フォームを表示するコマンドボタン（以下、送信フォーム表示ボタン）となっている。送信フォーム表示ボタン２３には、初期疾病情報送信フォームを表示するとともに、可否情報伝達メールのセッション情報から送信元の端末アドレスを読み取り、メモリ変数に格納するプログラムが埋め込まれている。

図１２は、初期疾病情報送信フォームの一例を示した概略図である。図１２では、同様に一次端末１がスマートフォンのような携帯端末である場合の例が示されている。
初期疾病情報送信フォームは、送信した問い合わせ情報を確認のため表示するとともに、追加所見の入力欄（追加所見欄）２４と、画像確認用のコマンドボタン（画像確認ボタン）２５と、初期疾病情報送信ボタン２６等を有している。追加所見欄２４は、その後の救急患者の容態に関する情報等をテキストで入力する欄である。この欄は任意であり、省略して初期疾病情報を送信することができる。

初期疾病情報の主要なものは、画像である。図１２に示す例では、画像の情報は自動的に取り込まれて二次端末２に送信されるようになっている。即ち、可否情報送信プログラムは、対応可伝達メールを送信した際、初期情報送信ボタン２６に案件ＩＤを埋め込むようプログラミングされている。初期疾病情報送信ボタン２６は、案件ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、該当するレコードから「患者氏名」の情報と「患者ＩＤ」の情報を取得するとともに、ＰＡＣＳサーバ６にアクセスし、患者ＩＤを検索キーにして検索して該当する患者の画像のファイル情報を取得し、一次的にメモリ変数に格納するようプログラミングされている。

画像のファイル情報は、上記のように初期疾病情報送信フォームを表示した際に自動的に取り込まれるが、事前に確認できるようにもなっており、そのためのボタンが図１２に示す画像確認ボタン２５である。画像確認ボタン２５がクリックされると、フォームを新たにオープンし、取り込んだファイル情報に従ってＰＡＣＳサーバ６にアクセスしてフォーム内に画像が表示されるようになっている。尚、その患者について複数の画像がある場合、すべての画像のファイル情報がメモリ変数に格納されて送信されることになるが、画像を選択させて特定の画像のみを送るようにしても良い。
また、図１２に示すように、初期疾病情報送信フォームには、見解送信期限入力欄２７が設けられている。見解送信期限入力欄は、いつまでに見解情報を送信して欲しいかの期限を入力する欄である。この例では、「３０分以内」、「１時間以内」、「３時間以内」、「５時間以内」・・・というように、初期疾病情報を送信してからの時間を選ぶプルダウンリストとなっている。

図１２に示す初期疾病情報送信ボタン２６がクリックされてメールが送信されると、一次送信プログラムが起動するようになっている。また、コミュニケーションサーバ３の記憶部には、初期疾病情報を送信するメールフォーム（以下、初期疾病情報送信メールフォーム）が記憶されている。一次送信プログラムは、コミュニケーションサーバ３に実装されたプログラムであり、初期疾病情報送信メールフォームを読み出し、メモリ変数に格納しておいた画像のファイル情報を嵌め込み、同様にメモリ変数に格納しておいた端末アドレスに電子メールの形で初期疾病情報を送信するようプログラミングされている。以下、この電子メールを、「初期疾病情報メール」と呼ぶ。

図１３は、二次端末２において受信されて表示された初期疾病情報メールの一例を示した概略図である。図１３に示すように、初期情報送信メールには、問い合わせ情報の送信の際に送られた患者情報や追加所見、見解送信期限等が含まれている。一次送信プログラムは、案件ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、該当するレコードから各患者情報を取得して初期疾病情報送信メールフォームに嵌め込むようプログラミングされている。
また、図１３に示す例では、画像ファイルを初期疾病情報メールに添付したり嵌め込んだりするのではなく、別途アクセスさせて画像を閲覧させるようになっている。即ち、初期疾病情報メールには、画像を閲覧するためのコマンドボタン（以下、画像閲覧ボタン）４１が設けられている。
一方、コミュニケーションサーバ３の記憶部には、画像を表示するためのフォーム（以下、画像表示フォーム）のファイルが記憶されており、二次端末２に画像ファイルを送信して表示するプログラム（以下、画像表示プログラム）が実装されている。画像閲覧ボタン４１は、この画像表示プログラムの起動コマンドとなっている。

図１４は、図１３において画像閲覧ボタン４１がクリックされた状態の一例を示した概略図である。画像閲覧ボタン４１は、案件ＩＤと、画像のファイル情報と、その初期疾病情報メールを受信・表示している二次端末２の端末アドレス又は端末識別情報とを引数にして画像表示プログラムに渡すようになっている。画像表示プログラムは、案件ＩＤに従ってテンプ送信先ＤＢＦを開き、端末アドレス又は端末識別情報を検索キーにして検索して対応可情報を送った二次端末２であるかどうかを判断する。対応可情報を送った二次端末２であると判断されると、画像表示プログラムは、画像の閲覧を許可して良いと判断し、ファイル情報に従ってＰＡＣＳサーバ６にアクセスして画像を取得するようプログラミングされている。そして、画像表示フォームに画像ファイルを嵌め込み、二次端末２に送信して表示するようプログラミングされている。

この際、画像表示プログラムは、指導的専門医ＤＢＦにアクセスし、該当レコードの「端末タイプ」のフィールドの情報を取得する。そして、端末タイプに従って画像の圧縮レベルを決定し、そのレベルで圧縮をした後、二次端末２に送るようになっている。二次端末２がパソコンやワークステーションの場合、圧縮をせずにそのまま送信する場合も当然あり得る。このように二次端末２のタイプに応じて所定の圧縮レベルとするため、二次端末２の表示能力に応じて最適な状態で画像が表示されるようになっている。尚、図１４に示すように画像が二次端末２に表示された後は、サーバ側の制御はＰＡＣＳサーバ６に遷移されており、二次端末２はＰＡＣＳサーバ６にアクセスしてＰＡＣＳサーバ６上のプログラムを実行可能な状態となる。

図１４に示すように、画像表示フォームには、「画像再構築」と表記されたコマンドボタン（以下、画像再構築ボタン）４３が設けられている。一方、ＰＡＣＳサーバ６には、画像を再構築して二次端末２に送信して表示するプログラム（以下、画像再構築プログラム）が実装されている。
画像は、前述したように、ＭＲＩ等の撮影機器で撮像された画像である。周知のように、これらの撮影機器は多くがデジタル化されており、デジタルデータが出力される。そして、出力データの可視化には各種のデータ処理が行われる。本実施形態の画像再構築手段は、異なるデータ処理を行うことで異なる画像が二次端末２に表示されるようにする手段である。

図１５は、画像再構築ボタン４３がクリックされた際の二次端末２の状態の一例を示した概略図である。図１５では、まず画像再構築のメニュー一覧が表示されるようになっている。この例では、「回転」と「動画」という二種類の再構築が行えるようになっている。「回転」というのは、画像を回転させて患者の患部を異なる角度から撮像した画像のように変更するプログラムである。「動画」とは、画像データを動画として再構築し、動画が二次端末２上で表示されるようにするプログラムである。動画として再構築する例としては、画像のデータが元々動画の場合と、静止画のデータを処理して動画とする場合とがある。前者の場合、画像が動画データのうちの一つのフレームを取り出したものであるので、元データのうちのどこからどこまでを再生するか等を指定させて再構築することになる。後者の例としては、ＣＴ画像やＭＲＩ画像のように患者の体を所定の短い間隔で切り取って撮影した断層写真の場合に、それらを所定の時間間隔でつなげていくことであたかも動画であるように再構築する例が挙げられる。

本実施形態の支援システムの特徴点は、このような画像再構築プログラムが病院外の二次端末２から実行することができるようになっている点であり、見解情報を寄せることが可能であるとの回答をした指導的専門医にのみこのような操作を可能としている点である。
図１６は、一例として、図１５において「回転」のコマンドボタンがクリックされた状態の一例を示した概略図である。図１６に示すように、「回転」のコマンドボタンをクリックすると、画像内に矢印が表示されるようになっている。矢印は、画像の中心から放射状に八つほど表示されるようになっている。各矢印は、それが示す方向に画像の向きを変えるサブプログラムを実行するものである。
この他、図１６に示すように、この例の画像再構築プログラムを実行すると、画像表示フォームに「任意方向」と表記されたコマンドボタンが表示されるようになっている。このコマンドボタンは、画面にタッチしながらドラグした方向に画像の向きを変えるサブプログラムを実行するボタンである。画像再構築プログラムの他の構成としては、患者の患部の部位を選択的に表示するよう変更する構成がある。例えば、ＭＲＩ画像のうち、骨の部分だけを取り出し表示するようにしたり、血管の部分だけの取り出して表示したりする再構築である。こらら画像再構築プログラムは、ＰＡＣＳサーバ６に実装される周知のものと同様にできるので、詳細な説明は割愛する。

また、画像として当初から動画が送信される場合もある。即ち、画像閲覧ボタン４１がクリックされると二次端末２に動画が表示される場合もある。動画の場合、画像が過去のものではなく、リアルタイムの画像の場合もある。例えば、心電図のような患者に常時装着して検査を行うことができる検査機器の場合、その出力データをリアルタイムでストリーミング送信することも可能である。この構成を採用する場合、ストリーミング送信を行うプログラムをコミュニケーションサーバ３に実装しておき、図１３に示す画像閲覧ボタン４１がクリックされた際にこのプログラムが実行されるようにする。リアルタイムの画像の動画配信は、救急患者の治療であることを考えると、特に好ましいと言える。即ち、重篤な救急患者の場合、極めて短時間のうちに治療方針を決定しなければならないことが多い。この場合、画像をリアルタイムで指導的専門医に見てもらい、その場で見解情報を提供してもらうようにすれば、手遅れになることなく適切な治療を行うことができる確率が高くなる。
尚、画像の送信の仕方としては、初期疾病情報メールに直接嵌め込んで送信するようにしても良いことは勿論である。

次に、図１３に戻り、見解情報の送信について説明する。
本実施形態の支援システムは、見解情報を各二次端末２において各々入力させ、入力された見解情報を一次端末１に送信する二次送信手段を備えている。二次送信手段は、本実施形態では、二次端末２と、コミュニケーションサーバ３と、コミュニケーションサーバ３に実装された二次送信プログラム等から構成されている。
図１４〜図１６に示す画像表示フォームにおいて、「キャンセル」と表記されたボタンには、画像表示フォームを閉じ、図１６に示す初期疾病情報メールの画面に戻すとともに、サーバの制御をＰＡＣＳサーバ６からコミュニケーションサーバ３に戻すコマンドが埋め込まれている。

図１３に示すように、初期疾病情報メールには、「見解送信」と表記されたコマンドボタン（以下、見解送信ボタン）４２が設けられている。一方、コミュニケーションサーバ３の記憶部には、見解情報の入力と送信のためのフォーム（以下、見解情報送信フォーム）のファイルが記憶されている。
見解送信ボタン４２には見解送信フォームを表示するコマンドが埋め込まれており、見解送信ボタン４２をクリックすると、図１７に示すような見解情報送信フォームが二次端末２に表示されるようになっている。図１７は、見解情報送信フォームの一例を示した概略図である。
図１７に示すように、見解情報送信フォームでは、見解情報をテキストで入力する欄（以下、見解情報入力欄）４４が設けられている。また、見解情報送信フォームには、送信ボタン４５が設けられている。この送信ボタン４５には、二次送信プログラムの起動コマンドが埋め込まれている。送信ボタン４５は、セッション変数から案件ＩＤ、専門医ＩＤ等を読み出した後、入力された見解情報とともにそれらの情報をコミュニケーションサーバ３に送信するようプログラミングされている。

図１８は、二次送信プログラムの概略を示したフローチャートである。
二次送信プログラムは、テンプ案件ＤＢＦを開き、案件ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、該当するレコードの「見解情報の有無」のフィールドに真値を記録する。また、案件ＩＤに従ってそのファイル名のテンプ送信先ＤＢＦを開き、専門医ＩＤを検索キーにしてテンプ送信先ＤＢＦを検索し、該当するレコードの「見解情報送信日時」のフィールドに、環境変数から日時を取得して記録する。それとともに、そのレコードの「見解情報」のフィールドに、見解情報（テキスト）を記録する。
一方、コミュニケーションサーバ３の記憶部には、一次端末１上で見解情報を表示するためのメールフォーム（以下、見解情報表示フォーム）のファイルが記憶されている。二次送信プログラムは、上記各ＤＢＦへの記録の後、送られた見解情報を見解情報表示フォームに嵌め込み、テンプ案件ＤＢＦに記録されている勤務医ＩＤに従って、その勤務医の一次端末１に見解情報表示フォームをメール送信する。これで、二次送信プログラムは終了である。

図１９は、一次端末１に送信されて表示された見解情報表示メールの一例を示した概略図である。図１９に示すように、見解情報表示メールは、送信された見解情報とともに、その見解情報を送った指導的専門医の氏名、プロフィール等を含んでいる。二次送信プログラムは、見解情報を見解情報表示フォームに嵌め込む際、セッション変数から専門医ＩＤを読み出し、指導的専門医ＤＢＦを検索して専門医氏名やプロフィール等の情報を取得し、見解情報表示フォームに嵌め込むようプログラミングされている。
図１９に示す見解情報表示メールは、見解情報が送信された際に即座に個別に一次端末１上で内容を確認する手段であったが、本実施形態のシステムは、システムの一回の利用（一人の救急患者の治療支援，一案件）について情報を統合して一次端末１に表示する統合表示手段を備えている。「統合して」とは、各見解情報を比較して参照できるように同一の一次端末１上に表示するという程度の意味である。

より具体的に説明すると、図６に示すように、メニューフォームには、「問い合わせ回答確認」と表記されたコマンドボタン（以下、回答確認ボタン）３７が設けられている。一方、コミュニケーションサーバ３の記憶部には、問い合わせ情報に対する回答有無を表示する回答有無表示フォームが記憶されている。図２０は、回答有無表示フォームの一例を示した概略図である。
図６に示す回答確認ボタン３７には、一次端末１を操作する者の資格を確認した後に回答有無表示フォームを一次端末１に表示する回答確認プログラムの起動コマンドが埋め込まれている。本実施形態では、問い合わせ情報に対する回答や見解情報が院内の誰でも閲覧できるようにするのは妥当ではないとの考えから、限られた者にのみ情報の閲覧を許可している。回答確認ボタン３７がクリックされると、回答確認プログラムは、勤務医ＩＤ及びパスワードを入力させるフォームを表示し、勤務医ＩＤ及びパスワードが入力され、勤務医ＤＢＦ内の情報と照らし合わせて正しく入力されていると判断されたら、勤務医ＩＤをメモリ変数に格納した後、回答表示フォームを一次端末１に表示するようプログラミングされている。この際、勤務医ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、勤務医ＩＤが一致するレコードの各フィールドの情報を読み出し、回答有無表示フォームに表示するようになっている。

図２０に示す例では、担当となっている勤務医（担当医）の名称が「○田×夫」であり、この者が問い合わせ情報を送信したすべての案件についての回答有無が表示されている。この例では、この者が問い合わせ情報を送信した案件は、「特許太郎」という患者についての１件のみであり、これのみが表示されている。仮に、この「○田×夫」という勤務医が、同時に複数の救急患者の治療を抱えていて、それぞれについて問い合わせ情報を送信していると、回答有無表示フォームは、複数行のリスト表示となり、それぞれについて回答有無が表示される。
コミュニケーションサーバ３の記憶部には、問い合わせ情報に対する回答を統合して表示する回答統合表示フォームのファイルが設けられている。図２０には、「回答有無」と表記された列に「回答あり」と表記されたコマンドボタン３８が設けられている。このコマンドボタン３８は、回答確認プログラムが自動生成したコマンドボタンであり、テンプ案件ＤＢＦ内の該当レコードの回答有無のフィールドが真値であった場合に自動生成するコマンドボタンである。このコマンドボタン３８は、回答統合表示フォームを表示するコマンドボタンとなっている（以下、回答表示ボタン）。

図２１は、一次端末１に表示された回答統合表示フォームの一例を示す概略図である。図２１に示すように、回答統合表示フォームでは、その案件ＩＤについての患者情報や送信した初期所見等の情報が表示されるとともに、見解情報を寄せることができるとの回答があった指導的専門医の情報がリスト表示されるようになっている。回答表示ボタン３８は、案件ＩＤがファイル名となっているテンプ送信先ＤＢＦを開き、「対応可否」のフィールドが真値となっているレコードの専門医ＩＤの取得した後、その専門医ＩＤで指導的専門医ＤＢＦを検索して該当レコードの情報を取得してリスト表示するプログラムの起動コマンドが埋め込まれている。尚、「初期疾病情報送付有無」の列は、テンプ送信先ＤＢＦの「初期疾病情報送信日時」がＮｕｌｌ値かどうかの値が表示される。Ｎｕｌｌ値であれば偽値、Ｎｕｌｌ値でなければ真値が表示される。
図２１に示すように、回答統合表示フォームには、「初期疾病情報一括送信」と表記されたコマンドボタン（以下、一括送信ボタン）３９が設けられている。コミュニケーションサーバ３の記憶部には、画像取り込みフォームのファイルが設けられており、一括送信ボタン３９には画像取り込みフォームへのリンクが貼られている。

図２２は、画像取り込みフォームの一例を示した概略図である。この例では、回答統合表示フォームの上に重ねるようにして新たにフォームが表示されるようになっている。図２２に示すように、画像取り込みフォームは、「患者氏名」及び「患者ＩＤ」を表示するとともに、画像ファイルを選ぶウインドウを表示するものとなっている。「患者氏名」及び「患者ＩＤ」は、セッション変数から案件ＩＤを読み出し、テンプ案件ＤＢＦを検索することで取得される。また、一括送信ボタンには、ＰＡＣＳサーバ６にアクセスし、患者ＩＤを検索キーにして検索して該当する患者の画像フィアルをウインドウにリスト表示するプログラムが埋め込まれている。
図２２に示すように、画像取り込みフォームには、ＯＫボタン５１が設けられている。ＯＫボタン５１には、選択された画像ファイルのファイル情報（パス名及びファイル名）をメモリ変数に一時的に格納するとともに、ファイル名を初期情報送信フォームに嵌め込むプログラムが埋め込まれている。

図２３は、画像のファイル情報が取り込まれた後の初期疾病情報送信フォームの一例を示した概略図である。この例では、xxx-yyy-10007201840.dcmというファイル名の画像が取り込まれている。
また、図２３に示すように、初期疾病情報送信フォームには、同様に見解送信期限入力欄５２が設けられており、同様にプルダウンリストとなっている。
図２３に示す送信ボタン５３には、一括型一次送信プログラムの起動コマンドが埋め込まれている。図２４は、一括型一次送信プログラムの概略を示したフローチャートである。
一括型一次送信プログラムは、初期疾病情報送信フォームで入力された初期疾病情報を初期疾病情報メールフォームに嵌め込み、各端末アドレスに順次メール送信する。各端末アドレスとは、その案件ＩＤにおいて対応可と回答してきた二次端末２であって、まだ初期疾病情報が送信されていない二次端末２の端末アドレスである（図２１に示す回答統合表示フォームにおいて「初期疾病情報送付有無」が偽値の端末アドレス）。該当するすべての端末アドレスに初期疾病情報をメール送信すると、一括型一次送信プログラムは終了である。
上記の一括型の初期疾病情報の送信において、図１２にフォームを示す即時送信型の初期疾病情報の送信の場合と同様、画像のファイル情報の自動的に取り込むようにすることも可能である。逆に、図１２の即時型において画像をマニュアル操作で取り込む構成を採用しても良い。マニュアル操作の場合、画像が複数ある場合、選択して送信することができる。

次に、見解情報の統合表示について説明する。
図６に示すメニューフォームには、「見解情報閲覧」と表記されたコマンドボタン（以下、見解閲覧ボタン）５４が設けられている。一方、コミュニケーションサーバ３の記憶部には、見解有無表示フォームのファイルが記憶されており、見解閲覧ボタン５４には、見解有無表示フォームを一次端末１に表示する見解有無表示プログラムの起動コマンドが設けられている。見解有無表示プログラムは、回答有無表示プログラムと同様、勤務医ＩＤとパスワードを入力させ、アクセス権をチェックした後、勤務医ＩＤでテンプ案件ＤＢＦを検索し、該当するレコードの各フィールドの情報を読み出して見解有無表示フォームに嵌め込み、一次端末１に送信する。

図２５は、見解有無表示フォームの一例を示した概略図である。図２５に示すように、見解有無表示フォームでは、入力された勤務医ＩＤの勤務医が問い合わせ情報を送信した案件情報がリストで表示されるようになっている。この例では、抱えている案件は１つのみであるので、リストは一つである。リストの末尾の列には、「見解有無」と見出しに表記された列があり、この列に「見解有り」と表記されたコマンドボタン５５が設けられている。このコマンドボタン５５は、見解有無表示プログラムが自動作成したコマンドボタンであり、テンプ案件ＤＢＦの「見解有無」のフィールドが真値であった場合にのみ自動生成するコマンドボタンである（以下、見解内容閲覧ボタン）。
見解内容閲覧５５ボタンには、コミュニケーションサーバ３に実装された見解情報統合表示プログラムの起動コマンドが埋め込まれている。コミュニケーションサーバ３の記憶部には、見解情報統合表示フォームのファイルが記憶されている。

図２６は、見解情報統合表示フォームの一例を示した概略図である。図２５に示す見解内容閲覧ボタン５５には案件ＩＤが埋め込まれており、案件ＩＤを見解情報統合表示プログラムに引数として渡すようになっている。見解情報統合表示プログラムは、案件ＩＤに従ってテンプ送信先ＤＢＦを開き、各レコードの情報を読み出して見解情報統合表示フォームに嵌め込むようプログラミングされている。この際、「見解情報」のフィールドがＮｕｌｌ値ではないレコードについては、その「見解情報」のフィールドの値（テキスト情報）をメモリ変数にいったん格納し、見解情報統合表示フォームには、図２６に示すように「詳細」と表記されたコマンドボタン（以下、詳細ボタン）５６を自動生成する。

図２７は、図２６において詳細ボタン５６がクリックされた状態の一例を示す概略図である。詳細ボタン５６には、メモリ変数に格納しておいた見解情報を別フォームで表示するプログラムが埋め込まれており、詳細ボタン５６をクリックすることで、図２７に示すように見解情報の内容を閲覧することができる。
図２６及び図２７から解るように、本実施形態によれば、見解情報を寄せている指導的専門医の情報がリスト表示され、各リストの詳細ボタン５６をクリックすることでその指導的専門医が寄せた見解情報やプロフィール等を閲覧することができる。このため、どのような指導的専門医がどのような見解情報を寄せたかを比べながら閲覧することができる。

次に、リアルタイムコミュニケーション手段について説明する。本実施形態の支援システムは、初期疾病情報が送られた際、送り先の各二次端末２と送り元の一次端末１とをグループ化してリアルタイムコミュニケーション（以下、ＲＴＣ）させるリアルタイムコミュニケーション手段（以下、ＲＴＣ手段）が設けられている。
ＲＴＣ手段は、一つの案件について問い合わせ情報を送信した一次端末１と、対応可情報を送信してきたすべての二次端末２とをグループ化し、ＲＴＣを行わせる手段である。本実施形態では、ＲＴＣ手段は、初期疾病情報の送信後、いずれかの二次端末２から見解情報が送られた際にＲＴＣを行うことを選択できるようになっている。

図１９に示すように、見解情報メールには、「ＲＴＣを行う」と表記されたコマンドボタン（以下、ＲＴＣボタン）４６が含まれている。コミュニケーションサーバ３には、初期ＲＴＣプログラムが実装されており、ＲＴＣボタン４６は、初期ＲＴＣプログラムの起動コマンドが埋め込まれている。図２６に示す見解情報統合表示フォームにも同様のコマンドボタン５７が設けられている。
初期ＲＴＣプログラムは、まず、ＲＴＣの管理用の一時的なデータベースファイル（以下、テンプＲＴＣ−ＤＢＦ）を作成する。テンプＲＴＣ−ＤＢＦは、例えば10-a1111-rtc.dbfのように、案件ＩＤを使用して決められたやり方でファイル名を定める。次に、初期ＲＴＣプログラムは、セッション変数から案件ＩＤを読み出し、テンプ送信先ＤＢＦを開く。そして、テンプ送信先ＤＢＦで「可否情報」のフィールドが真値であるレコードの「専門医ＩＤ」、「専門医名称」、「端末アドレス」、「端末識別情報」等を読み出し、テンプＲＴＣ−ＤＢＦに記録していく（レコードをコピーしていく）。すべてのレコードをコピーした後、その案件ＩＤにおける一次端末１の情報（端末アドレス及び端末識別情報）を新たなレコードを追加して記録する。この結果、その案件について対応可の回答を寄せている各指導的専門医の二次端末２と、その案件の担当医の一次端末１とがグループ化された結果となる。

次に、初期ＲＴＣプログラムは、コミュニケーションサーバ３の記憶部に記憶されているＲＴＣ用メールフォームを読み出し、見解情報メール中の見解情報（テキスト）を貼り付けて自動転送メールを作成し、テンプＲＴＣ−ＤＢＦに従って、その見解情報メールの送信元の端末アドレス以外のグループ内のすべての端末にその見解情報メールを自動転送する。尚、図２６に示すＲＴＣボタン５７については、いずれかの見解情報を指定し（リストのいずれかの行を指定し）、その上でＲＴＣボタン５７がクリックされるようにし、指定された見解情報を他のすべての二次端末２に送信してＲＴＣを開始するようプログラミングされる。

図２８は、リアルタイムコミュニケーション手段により自動転送された見解情報メールの一例（以下、ＲＴＣ転送メール）を示す概略図である。図２８に示すように、ＲＴＣ転送メールでは、メールがシステムにより全メンバーに自動転送されたものであることや、見解等があれば入力して送って欲しい旨のメッセージが嵌め込まれている。本実施形態では、過去の発言に追記した形でメッセージを配信するようになっており、この例では、三つ目の発言があった状態である。
図２８に示すように、ＲＴＣ転送メールには、「発言する」と表記されたコマンドボタン（以下、発言ボタン）４７が設けられている。発言ボタン４７には、返信メッセージ入力欄と送信ボタンとを有する発言フォームのリンクが貼られており、そこでの送信ボタンには、コミュニケーションサーバ３に実装されているＲＴＣ自動転送プログラムの起動コマンドが埋め込まれている。ＲＴＣ自動転送プログラムは、それまでに送信されたメッセージに、入力された返信メッセージを追加してメール文を生成し、同様にＲＴＣ用メールフォームに貼り付けて自動転送メールを作成する。そして、同様に、送信元の二次端末２以外のグループ内の全端末１，２に自動転送メールを送信する。
尚、上記のような自動転送メールは担当医の端末（一次端末１）に送信される。したがって、担当医自身が返信をする場合がある。この場合は、グループ内のすべての二次端末２に自動転送メールが送られることになる。

次に、経過情報送信手段について説明する。
本実施形態の支援システムは、経過情報を各二次端末２に送信する経過情報送信手段を備えている。経過情報とは、初期疾病情報を送信した後の救急患者の状態に関する情報又は追加検査、診断若しくは治療の情報を意味している。
経過情報送信手段は、一次端末１と、コミュニケーションサーバ３と、コミュニケーションサーバ３に実装された幾つかのプログラムによって構成されている。経過情報送信用のコミュニケーションサーバ３上のプログラムとしては、経過情報の入力、経過情報表示フォームの加工及び各二次端末２へのアラームメールの配信までの行うプログラム（以下、経過情報送信用第一プログラム）と、各二次端末２からのアクセスに応じて経過情報表示フォームを送信するプログラム（以下、経過情報送信用第二プログラム）が実装されている。

上記のように問い合わせ情報を送信して見解情報を受信した後も、患者の容態は刻々と変化し得るし、その後に必要な検査や投薬等の処置が行われることも多い。したがって、このようなその後の経過情報を指導的専門医に送るべき場合がある。例えば、その後の状況によっては経過情報を送ってさらなる見解情報を求めた方が良い場合もある。経過情報送信手段は、このような点を考慮したものである。
経過情報送信については、初期疾病情報の送信の際の追加所見の送信のように、一次端末１においてテキスト情報を入力し、コミュニケーションサーバ３を経由して各二次端末２に送信するようにしても良いのであるが、本実施形態では、救急患者の治療支援であることを考慮し、特別の構成を採用している。即ち、経過情報に時間情報を含めるようにし、且つ時間軸を示す直線であるタイムバーとともに経過情報が表示されるよう送信する構成が採用されている。

図６に示すメニューフォームには、「経過情報送信」と表記されたコマンドボタン（以下、経過情報送信ボタン）５８が設けられている。コミュニケーションサーバ３の記憶部には、経過情報の種類を選ぶフォーム（情報ジャンル選択フォーム）のファイルが記憶されており、経過情報送信ボタン５８をクリックすると、このフォームが一次端末１に表示されるようになっている。
詳細な説明は省略するが、情報ジャンル選択フォームでは、画像データ（撮影機器の出力データ）を経過情報として選択するコマンドボタン（以下、画像選択ボタン）や、血圧や心拍数、体温などのような患者の容態に関する数値データを経過情報として選択するコマンドボタン（以下、数値選択ボタン）や、投薬情報を経過情報として選択するコマンドボタン（以下、投薬選択ボタン）が設けられている。

画像選択ボタンがクリックされると、前述したのと同様にＰＡＣＳサーバ６にアクセスがされ、その後の撮影された画像を取り込んで経過情報表示フォームの所定の位置に嵌め込むよう経過情報送信用第一プログラムがプログラミングされている。この際、その画像の撮像日時も併せてＰＡＣＳサーバ６から取得され、経過情報表示フォームに嵌め込まれる。
数値選択ボタンがクリックされると、イントラネット１０上に接続されている検査機器（血圧計等）からデータを直接取り込んだり、または一次端末１上で入力したりすることができるように経過情報送信用第一プログラムがプログラミングされ、且つ、それらを経過情報フォームの所定の位置に嵌め込むようプログラミングされる。この際、そのような数値検査データの採取日時も併せて取得され、経過情報フォームの所定の位置に嵌め込まれる。
また、投薬選択ボタンがクリックされると、投与した薬の名前、投薬量、投薬の日時が入力されるよう経過情報送信用第一プログラムがプログラミングされ、且つ、入力された情報が経過情報表示フォームの所定の位置に嵌め込まれるようプログラミングされる。

経過情報の各二次端末２への送信（配信）は、コミュニケーションサーバ３から各二次端末２にメールを送り、そのメール中にコミュニケーションサーバ３上の経過情報送信プログラムの起動コマンドを埋め込むことで行われる。このメールは、経過情報のコミュニケーションサーバ３へのアップロードが行われた旨を知らせてダウンロードを促すメールであり、以下、経過情報アラームメールと呼ぶ。
コミュニケーションサーバ３の記憶部には、経過情報を表示するフォーム（以下、経過情報表示フォーム）が記憶されている。経過情報送信用第一プログラムは、入力された経過情報を経過情報表示フォームに組み込み、コミュニケーションサーバ３の記憶部に記憶して保存する。そして、経過情報送信プログラムの実行のために経過情報アラームメールを送信すると、プログラムが終了である。

図２９は、二次端末２に送信された経過情報アラームメールの一例を示した概略図である。図２９に示すように、経過情報アラームメールは、支援システムから経過情報がアップロードされた旨を知らせるメールであり、「表示」と表記されたコマンドボタン（表示ボタン）４８が設けられている。表示ボタン４８には、コミュニケーションサーバ３上の経過情報送信用第二プログラムの起動コマンドが埋め込まれている。経過情報送信用第二プログラムは、コミュニケーションサーバ３の記憶部に記憶された加工後の経過情報表示フォームを読み出し、アクセスしてきた二次端末２に送信して表示するようプログラミングされている。

図３０は、二次端末２に送信された経過情報の一例を示した概略図である。図３０に示すように、経過情報表示フォームは、時間軸を示す直線であるタイムバー４９を含んでいる。この例では、タイムバー４９は横長のものとなっている。この例では、二次端末２はスマートフォンになっており、画面を横にして見ることが想定されている。
図３０に示すように、経過情報は、タイムバー４９に対して吹き出し形式で表示されるようになっている。即ち、経過情報を内側に表示した吹き出し枠５０が形成されるようになっている。吹き出し枠５０の位置は、タイムバー４９が示す時間経過において当該経過情報に含まれる時刻に対応したものとなっている。即ち、図３０に示すように、例えばタイムバー４９の開始時刻が2010/07/20 18:30（２０１０年７月２０日１８時３０分）とし、３０分毎に時間経過を表示する目盛りが表示されるものとする。この場合、経過情報が投薬情報であり、この投薬情報に含まれる時刻情報（投薬時刻）が同日の１９時３５分であるとすると、１９時３５分の位置からの吹き出し枠５０内に経過情報（投薬情報）が表示されるようになっている。

図３０に示す経過情報表示フォームにおいて、タイムバー４９の位置や長さは予め固定されており、フォーム内の一定の位置に表示されるようになっている。経過情報の入力の際には、タイムバー４９のスケール（何時間毎の目盛り表示か）を指定する入力欄が一次端末１に表示されるようようになっている。ここでスケールを指定すると、指定されたスケールで目盛り表示がされるよう経過情報送信用第一プログラムがプログラミングされている。そして、経過情報表示フォーム加工プログラムは、入力された経過情報からそこに含まれる時刻情報を取り出すステップと、指定されたスケールに応じてタイムバー４９上の吹き出し枠５０の位置を算出するステップと、経過情報を嵌め込んだ吹き出し枠５０を算出された位置に組み込むステップとを有している。
尚、一度加工した経過情報表示フォームは、案件ＩＤ等を利用したファイル名でコミュニケーションサーバ３の記憶部に保存されるようになっている。二回目以降に経過情報を送信する際には、保存された経過情報表示フォームを読み出し、経過情報を追記するように嵌め込んでファイルを更新する。そして、更新された経過情報表示フォームが二次端末２に送信されるようになっている。

次に、履歴情報の記録について説明する。
本実施形態の支援システムは、システムの利用履歴を記録するため、記録手段と記録サーバ５とを有している。記録手段は、記録サーバ５と、記録サーバ５の記憶部に記憶された履歴情報データベースファイル（以下、履歴情報ＤＢＦ）等から構成されている。
図６に示すように、メニューフォームには、「管理終了入力」と表記されたコマンドボタン（以下、管理終了ボタン）５９が設けられている。一方、コミュニケーションサーバ３には、コミュニケーションサーバ３上の管理を終了して履歴を記録サーバ５に残す管理終了プログラムが実装されている。管理終了ボタン５９をクリックすると、勤務医ＩＤとパスワードを入力するフォームが表示され、それらが正しく入力されると、管理終了のための確認フォーム（管理終了確認フォーム）が一次端末１に表示されるようになっている。

管理終了プログラムは、入力された勤務医ＩＤに従ってテンプ案件ＤＢＦを開き、勤務医ＩＤが一致するレコードをリスト表示するようになっている。この部分は、図２０等とほぼ同様である。リスト（通常はリストは一行であるが、複数の案件を抱えている場合は複数行になる）の末尾には、「終了」と表記されたコマンドボタンが自動生成されるようになっており、このコマンドボタンは、案件ＩＤを引数にして管理終了プログラムを起動するものとなっている。
管理終了プログラムは、案件ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、該当レコードの切り取りを行う。即ち、全フィールドの情報をそれぞれメモリ変数に格納した後、該当レコードを削除する。そして、履歴情報ＤＢＦに新たなレコードを追加し、格納した情報を記録する。履歴情報ＤＢＦのファイル構造は、テンプ案件ＤＢＦと全く同じものとされる。
次に、管理終了プログラムは、案件ＩＤに従ってその案件のテンプ送信先ＤＢＦの切り取りを行う。即ち、テンプ送信先ＤＢＦをメモリ変数に格納した後、コミュニケーションサーバ３の記憶部からそのテンプ送信先ＤＢＦを削除する。次に、格納したテンプ送信先ＤＢＦを記録サーバ５の記憶部に記憶して保存する。これで、管理終了プログラムは終了である。記録サーバ５の記録部のファイルは永久的に又は所定の長い期間保存されるものであり、システムの利用履歴情報の保存場所として意義を有する。

上記構成に係る本実施形態の支援システムにおいて、見解情報は、それを送信する指導的専門医のデジタル署名とともに送信されることが望ましい。デジタル署名付きのメール送信は、パソコンやノートパソコン用のメーラでは殆どの場合、標準の機能として有する。したがって、二次端末２がパソコンやノートパソコンである場合はそれを利用する。指導的専門医に対してはデジタル署名付きの送信で見解情報を送信してもらうよう要請しておく。
二次端末２が携帯電話等の携帯端末である場合、デジタル署名付きのメールが送れるものは現状では少ない。そこで、本実施形態のシステムは、指導的専門医に対して後からデジタル署名付きのメールを再送信してもらうよう要請する技術的工夫をしている。

具体的に説明すると、図２７に示すように、見解情報を表示するフォームには、「デジタル署名依頼」と表記されたコマンドボタン（以下、署名依頼ボタン）６１が設けられている。一方、コミュニケーションサーバ３の記憶部には、デジタル署名を依頼するメールフォーム（以下、署名依頼フォーム）のファイルが保存されており、署名依頼ボタン６１がクリックされると、署名依頼フォームが一次端末１上に表示されるようになっている。署名依頼ボタン６１には、専門医ＩＤを検索キーにしてテンプ送信先ＤＢＦを検索し、該当するレコードの「見解情報」のフィールドの値（テキスト）を取得した後、署名依頼フォームに嵌め込むプログラムが埋め込まれている。
一方、指導的専門医ＤＢＦには、デジタル署名を付してメール送信することが可能なメールアドレス（通常はパソコン又はノートパソコンにおけるメールアドレス）が登録されている。署名依頼ボタン６１に埋め込まれたプログラムは、専門医ＩＤを検索キーにして指導的専門医ＤＢＦを検索し、このメールアドレスの情報を取得する。

署名依頼フォームには、送信ボタンが設けられており、この送信ボタンには、取得したメールアドレスの情報が埋め込まれる。そして、署名依頼フォームには、確認のため表示した見解情報についてデジタル署名を付して再送信して欲しい旨のメッセージが表示されるようになっている。送信ボタンのクリックにより、署名依頼フォームは、署名可能な二次端末２のメールアドレスに送信され、指導的専門医は、デジタル署名を付して返信することになる。
尚、コミュニケーションサーバ３は、二次端末２からメール（見解情報のメールや上記返信メール）が送信された際、ヘッダ情報からデジタル署名が付されているかどうか判断し、デジタル署名が付されている場合、デジタル署名情報を取り出して保存するようプログラミングされている。デジタル署名情報の保存は、例えばテンプ送信先ＤＢＦに「デジタル署名情報」のフィールドを設けてそこに記録して保存したり、別途専用のデータベースファイルを設けて保存したりすることができる。そして、このように保存したデジタル署名情報は、見解情報と同様、記録サーバ５の履歴情報ファイルに記録されて保存される。

次に、アラーム手段について説明する。
本実施形態の支援システムおいて、各二次端末２は、コミュニケーションサーバ３から初期疾病情報が送信された際、アラームを発するアラーム手段を備えている。アラームは、初期疾病情報が送信された旨を指導的専門医に知らせ、見解情報を送信を促すためのものである。見解情報は、救急患者の治療のために送信してもらうものであり、緊急性を有する。初期疾病情報が届いていてもそれに気がつかないと、適切なタイミングで見解情報が届かず、治療方針等の決定の際に参考にできないことになり得る。このような点を考慮し、アラーム手段を設けている。本実施形態の支援システムでは、初期疾病情報の前段階の情報である問い合わせ情報についても、それが送信されたことを知らせるアラーム手段を設けている。具体的には、アラーム手段は、音、光、振動又はこれらの組み合わせから成るアラームを発する手段である。
本実施形態の支援システムは、問い合わせ情報や初期疾病情報を電子メールの形で送信するものとなっている。したがって、アラーム手段は、そのような電子メールが届いたことを知らせる手段である。現在使用されている殆どのメーラは、このようなアラーム手段を備えており、本実施形態ではメーラの機能がそのまま利用される。メーラのアラーム機能が動作するよう、各指導的専門医に対して二次端末２の設定を依頼することになる。

問い合わせ情報や初期疾病情報が電子メールの形で送信されない場合、アラーム手段も別のものに変更する必要がある。例えば、初期疾病情報が一次端末１からコミュニケーションサーバ３に送信された後、二次端末２からコミュニケーションサーバ３に能動的にアクセスさせて初期疾病情報を取得するような構成の場合、二次端末２に対してコミュニケーションサーバ３にアクセスするよう促すアラーム手段が必要であるが、この構成としては、各指導的専門医が保有する携帯電話に対していわゆるワン切り送信を行うことでアラームとすることができる。即ち、この支援システム固有の電話番号から各携帯電話に対して１回ないし数回の短い着信音の電話番号発信を行うことでアラームをするできる。この発信は、番号通知の設定としておき、各携帯電話において発信番号が本支援システムからのものであることが解るようにしておくことが望ましい。支援システム側では、各指導的専門医の携帯電話番号を指導的専門医ＤＢＦに登録しておき、コミュニケーションサーバ３から順次ワン切り発信をするプログラムが実装される。

また、問い合わせ情報や初期疾病情報は、コミュニケーションサーバ３からのダウンロードの形で送信される構成が採用されることもある。即ち、図２９に示すような簡単なテキストから成るメールをアラームの意味で送信しておき、そのメールにコミュニケーションサーバ３にアクセスするコマンドボタンを嵌め込んでおく。そのコマンドボタンをクリックすると、問い合わせ情報や（画像のみならずテキストも含む）初期疾病情報がコミュニケーションサーバ３からダウンロードされるよう構成しても良い。したがって、図２９に示すようなアラームメールを送信する手段を、アラーム手段として捉えることもできる。

上記構成に係る本実施形態の支援システムによれば、複数の指導的専門医に対して画像を含む初期疾病情報が回答期限とともに送信され、各指導的専門医からは初期疾病情報を踏まえての見解情報が返信されるので、担当医は、各見解情報を参照して診断をしたり治療方針を決定したりすることができる。このため、担当医が単独で決定して治療を行う場合に比べてより適切な治療を行える場合が多くなる。
また、本実施形態の支援システムでは、初期疾病情報の送信の前に問い合わせ情報を送信し、対応可能と返信してきた指導的専門医にのみ初期疾病情報を送信して見解情報を求めるので、対応できない指導的専門医に対して無駄に初期疾病情報を送ることが無くなる。指導的専門医の側でも、対応できない案件についてむやみに初期疾病情報が送信されることがないので、煩雑さが生じない。また、初期疾病情報は患者の画像を含むので、対応可能と回答してきた指導的専門医に対してのみ送信することは、個人情報保護の観点からも望ましい。

また、本実施形態の支援システムは、指導的専門医の専門性レベルについて特定のレベルの者のみを選び出して初期疾病情報を送ることができるので、疾病の特殊性、診断や治療の難易性等に応じて最適なレベルを設定して見解情報の提供を要請することができる。このため、より適切な見解情報を得ることにつながり、より適切な治療を行うことに貢献できる。
また、本実施形態の支援システムは、リアルタイムコミュニケーション手段が設けられているので、一つの救急疾病や一つの見解情報に対して多くの指導的専門医が見解を述べて討議することが可能となる。このため、多くの見解を積み重ねることでより適切な結論に達することが可能となり、この点でさらに適切な治療を行えるようになる。
また、本実施形態の支援システムは、経過情報送信手段を備えているので、初期疾病情報を送信した後の状況に応じてさらに見解情報を求めることも可能になり、この点で、さらに適切な治療が行えるようになる。この際、経過情報は、時間軸を示す直線であるタイムバー上に時系列的に示されるので、時間経過の中でどのような状況であるかを指導的専門医が容易に把握することができる。このため、「時間との戦い」である救急疾病の治療において、より適切なタイミングでより適切な治療が行えるよう見解情報を提供することができる。

また、本実施形態の支援システムは、画像再構築手段が設けられており、指導的専門医の側で画像を自由に再構築して確認することができるので、より適切な見解情報を提供することができる。
また、本実施形態の支援システムは、記録サーバ５の履歴情報ファイルに、初期疾病情報を送信して見解情報を求めた旨、及び指導的専門医から寄せられた見解情報が記録されて保存されるので、適切な取り扱いをした旨の証拠として後に利用することができる。即ち、診断や治療方針の決定が適切であったかどうか等が後に問題となった場合（例えば医療過誤を理由とする訴訟が提起された場合）、履歴情報ファイルの内容を根拠として適切に各指導的専門医に見解情報を求め、寄せられた見解情報をもとに治療を行った旨を釈明することができる。
このような釈明の際、本実施形態の支援システムでは、見解情報をデジタル署名付きで受信することができ、デジタル署名とともに見解情報を履歴情報ファイルに保存するので、見解情報の受信やその内容に対する信憑性（証拠価値）が高くでき、この点で好適なものとなっている。

上記実施形態の構成において、コミュニケーションサーバ３から送信される画像としては、手術中の患部を撮影した動画である場合がある。例えば、経過情報として手術中の患部を撮影した動画をリアルタイムで二次端末２に送信することもあり得る。この場合、動画のリアルタイム送信については、いわゆるストリーミング配信の技術を利用することができるし、ＩＰ電話によるテレビ電話を利用して行うこともできる。よって、詳細な説明は割愛する。尚、手術中の動画を配信しているフレームを嵌め込んだフォーム内に見解情報を送信するためのボタンを設け、指導的専門医が動画を見ている際に気がついた点を見解情報として送ってもらうようにすることも可能である。
尚、手術中の患部の動画は、初期疾病情報として送られる場合もある。即ち、問い合わせ情報として、これから手術に入るので手術中の画像を見た上で見解情報をもらえるかどうかを問い合わせておき、可能であると返信してきた二次端末に手術中の動画を送って見解情報を求めるような使い方も考えられる。

上述した本実施形態の構成において、経過情報の配信は、二次端末２だけではなく、院内の各一次端末１に対しても行うようにすると好適である。例えば、救急患者の治療について複数の医師や看護士がチームとして対応している状況において、チームの各員が携帯型の一次端末１を持ち歩くようにし、何らかの経過情報が発生したら、それを各員の一次端末１に即座に配信するようにする。これによりチーム全員が経過情報をリアルタイムで共有することができるようになり、より迅速により効果的に救急患者の診断や治療を進めることができるようになる。
上述した実施形態の説明では、脳梗塞やくも膜下出血のような脳血管系の救急患者を例にしたが、本願発明は、他科の救急患者の治療支援についても同様に利用することができる。例えば、心筋梗塞や大動脈瘤のような循環器系の救急患者や、交通事故等による外傷系の救急患者、さらには切迫早産や出産時の脳出血等の出産に関わる救急患者について、本願発明を利用することができる。

１ 一次端末
２ 二次端末
３ コミュニケーションサーバ
４ データベースサーバ
５ 記録サーバ
６ ＰＡＣＳサーバ
７ 電子カルテサーバ
１０ イントラネット

本願の発明は、救急患者の治療を支援する情報システムに関するものである。

医療の現場における技術革新には目覚ましいものがあり、ＣＴ装置やＭＲＩ装置等、多
くの先端的医療機器が各種疾病の治療に利用されている。また、医療の現場におけるＩＴ
（情報技術）の利用も進んできており、遠隔医療のために医療情報をネットワークを介し
て送ることや、コンピュータに対して症状等の情報を送ることでコンピュータが病名を推
論するコンピュータ診断等の技術も提案されている。

特開２００４−２８０８０７号公報

しかしながら、上記医療現場におけるＩＴ利用に関する従来の提案は、救急医療、特に
重篤の救急患者に対する治療の観点では甚だ不十分であった。救急医療の場合、患者が救
急搬送された後、短時間のうちに診断を行い、どのような治療を行うか（治療方針）の決
定を行わなければならない。診断の前には検査が必要な場合が多く、検査結果によっては
再検査が必要な場合もある。

救急医療の現場で特に問題となるのは、どのような疾病であるか直ちには特定できない
場合である。例えば、頭に強い痛みを訴えて救急搬送された患者については、通常は、頭
部Ｘ線ＣＴや頭部ＭＲＩのような検査がまず行われる。この結果、ＣＴ画像やＭＲＩ画像
といった検査画像が得られる訳であるが、画像だけでは、どのような疾病であるのか即断
できないことが多々ある。例えば、脳血管障害で言えば、脳梗塞なのか脳出血なのか、画
像からは即座に判断できない場合もある。また、疾病が特定できたとしても、どのような
治療方法が最善であるか、即座には判断できない場合も多い。例えばくも膜下出血のよう
な脳動脈瘤の治療の場合、こぶ（動脈瘤）の部分をクリップで塞いでしまうクリップ手術
と、血管内にカテーテルを通してこぶの部分を内側からコイルで塞いでしまうコイル手術
とがあるが、どちらが良いのか、画像からは即座に判断できない場合がある。

その一方、周知のように、このような脳血管障害の疾病は、発症から手術までの時間が
長くなればなるほど生存率が低くなる疾病であり、極めて短時間に判断と処置を行うこと
が強く要請される疾病である。例えば脳梗塞の場合、発症から３時間以内にｔＰＡ（組織
性プラスミノーゲン活性化因子，いわゆる血栓溶解剤）を投与できれば、社会復帰できる
確率は３０〜４０％程度あるとされているが、３時間を超えた場合、社会復帰できる確率
は激減するとされている。このような救急医療の現場では、担当となった医師は、時間と
の戦いの中で、自らの知識と経験を頼りに最善と思われる判断をし、処置をしている。

しかしながら、より良い結果を得るため、最善の結果を間違いなく得るためには、担当
医だけの判断ではなく、別の専門医の見解を求めた方が良い場合もある。この場合、別の
専門医が当直等で院内にいる場合には、画像を見てもらって判断を仰ぐこともできる。し
かしながら、非番で院内にいない場合には不可能であるし、別の専門医が元々院内にいな
い（所属していない）場合もある。このような場合には、担当医のみの判断によるしかな
い。

また、上記の例は担当医が当該疾病の専門医であることを前提にしていたが、救急医療
の現場では、専門医以外の医師が救急患者に対応しなければならないことも多々ある。例
えば、上記のような循環器系の救急が救急搬送されたものの、当直の医師は消化器系の医
師のみであったという場合もあり得る。さらに言えば、過疎地や僻地にある病院や診療所
では、幅広い分野で診療を行っているものの特定の専門分野を持たない医師（いわゆる総
合医）しか存在しない場合もある。この場合、上記のような高度な専門的判断が要求され
る診断や治療については、提供することができない。この場合は、その病院や診療所では
対応できないので、別の医療施設に搬送するよう救急隊に連絡することになる。この場合
には、いわゆるたらい回しのような問題も起こり得る。
さらに、ある程度の規模の病院であり、専門医が常駐している病院であっても、特殊な
症例であって自己の専門的知識や経験では判断が難しい場合もあるし、自己の専門分野の
疾病ではあっても、より良い結果を得るためには、より高い専門的知識を持った、その分
野の指導的医師に見解を求めたい場合もある。このような場合でも、救急医療であるとい
う時間的制約等から、限られた自己の専門的知識と経験で何とか対応しているというのが
現状である。

ある疾病に対して別の医師の見解を求めること自体は、従来から行われている。自分が
対応できない患者については、紹介状を書いて別の病院で看てもらうよう患者に伝えるこ
とは頻繁に行われているし、患者自身が別の専門医に見解を求めること（いわゆるセカン
ドオピニオン）も、しばしば行われている。しかしながら、これは、いわば、患者を介し
た別見解の求めであり、最初の担当医が直接的に別の専門医に見解を求めている訳ではな
い。その一方、救急医療の現場では、上述したように、時間的制約から、担当医が別の専
門医に直接的に見解を求めることが望ましい場合が多々あるのが実情である。

本願の発明は、上記のような課題を解決するためになされたものであり、救急医療の現
場において担当医が別の専門医、とりわけ指導的な専門医に見解を求めることを容易にし
、指導的専門医の見解を参照しつつ最適な治療を施すのに役立つ支援システムを提供する
意義を有するものである。

上記課題を解決するため、本願の請求項１記載の発明は、特定の疾病について特別の専
門的知識と経験を有する者として認められる者である複数の指導的専門医の情報をデータ
ベース化して記録した指導的専門医データベースファイルを含むデータベースサーバと、
指導的専門医データベースファイルに新たな指導的専門医の情報を記録して登録する登
録手段と、
救急患者が治療を受ける病院の担当者が操作する一次端末と、
指導的専門医データベースファイルに情報が記録されている各指導的専門医によって操
作される二次端末と、
コミュニケーションサーバと、
前記指導的専門医データベースファイルに記録された情報には、前記各二次端末のアド
レス情報が含まれており、
さらに、
前記救急患者の患部を撮影した画像とその画像の撮影時刻との情報を含む情報である初
期疾病情報を、前記一次端末から入力させ、前記指導的専門医データベースファイルに記
録されたアドレス情報に従って前記コミュニケーションサーバを介して前記各二次端末に
送信する一次送信手段と、
前記各二次端末に転送された前記初期疾病情報を前記各二次端末において受信して表示
する受信表示手段と、
表示された前記初期疾病情報を確認した各指導的専門医に、当該救急患者についての追
加検査の必要性の情報、どのような疾病であるかの情報又はどのように治療すべきかの情
報である見解情報を各二次端末において各々入力させ、入力された見解情報を一次端末に
送信する二次送信手段と、
各二次端末から送信された見解情報を一次端末に表示する見解情報表示手段とを備えて
おり、
前記一次送信手段は、前記見解情報の送信期限とともに前記初期疾病情報を送信するも
のであり、
前記初期疾病情報が送信された際、各指導的専門医に対し、音、光、振動又はこれらの
組み合わせから成るアラームを発するアラーム手段を備えているという構成を有する。
また、上記課題を解決するため、請求項２記載の発明は、前記請求項１の構成において
、前記初期疾病情報を送信する前に、問い合わせ情報を前記一次端末から入力させて前記
コミュニケーションサーバを介して前記各二次端末に送信する問い合わせ情報送信手段を
備えており、
問い合わせ情報は、当該救急患者の疾病についての症状を記述したテキストと、前記初
期疾病情報を送信した場合の前記見解情報の送信期限の情報とを含んでおり、送信期限内
に前記見解情報を送信することができるかどうかを問い合わせる情報であり、
前記二次送信手段は、問い合わせ情報が転送された際、前記見解情報を送信することが
できるか否かの情報である可否情報を前記二次端末において入力させて前記一次端末に送
信するものであり、
前記一次送信手段は、問い合わせ情報に対して、前記見解情報を送信することができる
旨の可否情報が送信された前記二次端末に対してのみ前記初期疾病情報を転送するもので
あるという構成を有する。
また、上記課題を解決するため、請求項３記載の発明は、前記請求項１又は２の構成に
おいて、前記指導的専門医データベースファイルに登録された前記指導的専門医の情報に
は、各指導的専門医の専門性のレベルについての情報が含まれており、
前記一次送信手段は、前記指導的専門医データベースファイルに情報が登録された指導
的専門医のうち、特定のレベルの指導的専門医のみを選び出してその指導的専門医が操作
する前記各二次端末にのみ前記初期疾病情報を送信することができるものであるという構
成を有する。
また、上記課題を解決するため、請求項４記載の発明は、前記請求項１、２又は３の構
成において、前記二次送信手段は、前記コミュニケーションサーバを介して前記見解情報
を前記一次端末に送信するものであり、前記コミュニケーションサーバは、前記見解情報
が前記二次端末から送信された際に前記一次端末に転送するものであり、
前記初期疾病情報が送られた際、当該初期疾病情報を送った前記各二次端末と前記一次
端末とをグループ化してリアルタイムコミュニケーションさせるリアルタイムコミュニケ
ーション手段が設けられており、
リアルタイムコミュニケーション手段は、前記二次端末から前記見解情報が送られた際
、当該見解情報を前記一次端末に送信するとともにグループの他の各二次端末にも送信す
るものであり、
前記一次端末及び前記各二次端末は、送信された前記見解情報に対する返信情報を入力
させて前記コミュニケーションサーバに送信することが可能であり、
リアルタイムコミュニケーション手段は、返信情報が送信された際、送信元の一次端末
又は二次端末以外のグループ内の各端末に返信情報を送信するものであり、
前記一次端末及び前記各二次端末は、送信された前記返信情報に対する再返信情報を入
力させて前記コミュニケーションサーバに送信することが可能であり、
リアルタイムコミュニケーション手段は、再返信情報が送信された際、送信元の一次端
末又は二次端末以外のグループ内の各端末に再返信情報を送信するものであるという構成
を有する。
また、上記課題を解決するため、請求項５記載の発明は、前記請求項１乃至４いずれか
の構成において、前記初期疾病情報を送信した後の救急患者の状態に関する情報又は追加
検査、診断若しくは治療の情報である経過情報を前記一次端末において入力させて前記コ
ミュニケーションサーバを介して前記各二次端末に送信する経過情報送信手段を備えてお
り、
前記受信表示手段は、送信された経過情報を各二次端末で受信して表示する手段である
という構成を有する。
また、上記課題を解決するため、請求項６記載の発明は、前記請求項５の構成において
、前記経過情報には、当該救急患者の状態に関する情報がいつの時点での情報であるか、
又は当該追加検査、診断若しくは治療の情報がいつの時点での情報であるかを示す時間情
報が含まれており、
前記経過情報送信手段は、前記各二次端末において、時間軸を示す直線であるタイムバ
ー上に時系列的に前記経過情報が表示するよう前記経過情報を送信するものであるという
構成を有する。
また、上記課題を解決するため、請求項７記載の発明は、前記請求項１乃至６いずれか
の構成において、前記初期疾病情報に含まれる前記画像は動画であり、
前記一次送信手段は、前記画像を前記撮影機器が撮像している際、当該画像をリアルタ
イムで前記コミュニケーションサーバに送信するものであり、
前記コミュニケーションサーバは、送信された画像をリアルタイムで前記各二次端末に
送信するものであるという構成を有する。
また、上記課題を解決するため、請求項８記載の発明は、前記請求項１乃至７いずれか
の構成において、前記経過情報には動画が含まれており、前記経過情報送信手段は、当該
画像を撮影機器が撮像している際、当該画像をリアルタイムで前記コミュニケーションサ
ーバに送信するものであり、
前記コミュニケーションサーバは、送信された画像をリアルタイムで前記各二次端末に
送信するものであるという構成を有する。
また、請求項９記載の発明は、前記請求項７又は８の構成において、前記画像は、前記
救急患者の手術の際に撮影している患部の動画であるという構成を有する。
また、上記課題を解決するため、請求項１０記載の発明は、前記請求項１乃至７いずれ
かの構成において、前記画像は、撮影機器で取得されたデータを処理して得られた画像で
あり、
前記二次端末において表示される前記画像を再構築する画像再構築手段が設けられてお
り、
画像再構築手段は、画像再構築プログラムが実装された画像再構築サーバを備えており
、
前記受信表示手段は、前記画像を再構築する指令である画像再構築指令を前記二次端末
において入力させて画像再構築サーバに送信することが可能となっており、
画像再構築プログラムは、画像再構築指令が送信された画像のデータを再処理して再構
築した画像を生成して前記二次端末に送信し、前記受信表示手段により前記二次端末に表
示するものであるという構成を有する。
また、上記課題を解決するため、請求項９記載の発明は、前記請求項１乃至９いずれか
の構成において、記録手段及び記録サーバが設けられており、
記録サーバの記憶部には、各救急患者についての治療履歴情報をデータベース化して記
録した履歴情報ファイルが設けられており、
記録手段は、各救急患者について、前記一次送信手段が前記各二次端末に初期疾病情報
を送信した旨の情報を履歴情報ファイルに記録するとともに、前記各二次端末から前記見
解情報が送信された旨と当該見解情報の内容とを履歴情報ファイルに記録するものである
という構成を有する。
また、上記課題を解決するため、請求項１０記載の発明は、前記請求項９の構成におい
て、前記二次送信手段は、前記見解情報を入力する前記指導的専門医のデジタル署名を前
記見解情報とともに前記一次端末に送信するものであり、
前記記録手段は、前記見解情報とともにその見解情報を入力した前記指導的専門医のデ
ジタル署名を前記履歴情報ファイルに記録するものであるという構成を有する。

以下に説明する通り、本願の請求項１記載の発明によれば、複数の指導的専門医に対し
て画像を含む初期疾病情報が回答期限とともに送信され、各指導的専門医からは初期疾病
情報を踏まえての見解情報が返信されるので、担当医は、各見解情報を参照して診断をし
たり治療方針を決定したりすることができる。このため、担当医が単独で決定して治療を
行う場合に比べてより適切な治療を行える場合が多くなる。
また、請求項２記載の発明によれば、上記効果に加え、初期疾病情報の送信の前に問い
合わせ情報を送信し、対応可能と返信してきた指導的専門医にのみ初期疾病情報を送信し
て見解情報を求めるので、対応できない指導的専門医に対して無駄に初期疾病情報を送る
ことが無くなる。指導的専門医の側でも、対応できない案件についてむやみに初期疾病情
報が送信されることがないので、煩雑さが生じない。また、初期疾病情報は患者の画像を
含むので、対応可能と回答してきた指導的専門医に対してのみ送信することは、個人情報
保護の観点からも望ましい。
また、請求項３記載の発明によれば、上記効果に加え、指導的専門医の専門性レベルに
ついて特定のレベルの者のみを選び出して初期疾病情報を送ることができるので、疾病の
特殊性、診断や治療の難易性等に応じて最適なレベルを設定して見解情報の提供を要請す
ることができる。このため、より適切な見解情報を得ることにつながり、より適切な治療
を行うことに貢献できる。
また、請求項４記載の発明によれば、上記効果に加え、リアルタイムコミュニケーショ
ン手段が設けられているので、一つの救急疾病や一つの見解情報に対して多くの指導的専
門医が見解を述べて討議することが可能となる。このため、多くの見解を積み重ねること
でより適切な結論に達することが可能となり、この点でさらに適切な治療を行えるように
なる。
また、請求項５記載の発明によれば、上記効果に加え、経過情報送信手段を備えている
ので、初期疾病情報を送信した後の状況に応じてさらに見解情報を求めることも可能にな
り、この点で、さらに適切な治療が行えるようになる。
また、請求項６記載の発明によれば、上記効果に加え、経過情報は、時間軸を示す直線
であるタイムバー上に時系列的に示されるので、時間経過の中でどのような状況であるか
を指導的専門医が容易に把握することができる。
また、請求項７又は８記載の発明によれば、上記効果に加え、画像がリアルタイムで各
二次端末に送信されるので、より短時間に見解情報を送信してもらうことが可能になる。
このため、救急患者の治療を支援する上でより好適なものとなる。
また、請求項９記載の発明によれば、リアルタイム送信される動画が手術中の患部の映
像なので、手術の進行状況等について即座に見解情報を送信してもらうことが可能になる
。このため、救急患者の治療を支援する上でより好適なものとなる。
また、請求項１０記載の発明によれば、上記効果に加え、画像再構築手段が設けられて
おり、指導的専門医の側で画像を自由に再構築して確認することができるので、より適切
な見解情報を提供することができる。
また、請求項１１記載の発明によれば、上記効果に加え、記録サーバの履歴情報ファイ
ルに、初期疾病情報を送信して見解情報を求めた旨と指導的専門医から寄せられた見解情
報とが記録されて保存されるので、適切な取り扱いをした旨の証拠として後に利用するこ
とができる。
また、請求項１２記載の発明によれば、上記効果に加え、見解情報をデジタル署名付き
で受信することができ、デジタル署名とともに見解情報を履歴情報ファイルに保存するの
で、見解情報の受信やその内容に対する信憑性（証拠価値）が高くでき、この点で好適な
ものとなる。

本願発明の実施形態に係る救急患者治療支援システムの概略図である。 本実施形態のシステムを利用した救急患者の治療について段階的且つ概略的に示した業務フロー図である。 指導的専門医データベースファイルの構造を示した概略図である。 テンプ案件ＤＢＦの構造の一例を示した概略図である。 テンプ送信先ＤＢＦの構造の一例を示した概略図である。 救急疾病治療支援プロジェクトのメニューフォームの一例の概略図である。 問い合わせ情報入力フォームの一例を示した概略図である。 問い合わせ情報送信フォームの一例を示した概略図である。 問い合わせ情報送信プログラムの概略を示したフローチャートである。 二次端末に表示された問い合わせメールの一例を示した概略図である。 可否情報送信プログラムによって一次端末に送信された対応可伝達メールの一例を示した概略図である。 初期疾病情報送信フォームの一例を示した概略図である。 二次端末において受信されて表示された初期疾病情報メールの一例を示した概略図である。 図１３において画像閲覧ボタンがクリックされた状態の一例を示した概略図である。 画像再構築ボタンがクリックされた際の二次端末の状態の一例を示した概略図である。 図１５において「回転」のコマンドボタンがクリックされた状態の一例を示した概略図である。 見解情報送信フォームの一例を示した概略図である。 二次送信プログラムの概略を示したフローチャートである。 一次端末に送信されて表示された見解情報表示メールの一例を示した概略図である。 回答有無表示フォームの一例を示した概略図である。 一次端末に表示された回答統合表示フォームの一例を示す概略図である。 画像取り込みフォームの一例を示した概略図である。 画像のファイル情報が取り込まれた後の初期疾病情報送信フォームの一例を示した概略図である。 一括型一次送信プログラムの概略を示したフローチャートである。 見解有無表示フォームの一例を示した概略図である。 見解情報統合表示フォームの一例を示した概略図である。 図２６において詳細ボタンがクリックされた状態の一例を示す概略図である。 リアルタイムコミュニケーション手段により自動転送された見解情報メールの一例を示す概略図である。 二次端末に送信された経過情報アラームメールの一例を示した概略図である。 二次端末に送信された経過情報表示フォームの一例を示した概略図である。

次に、本願発明を実施するための形態（以下、実施形態）について説明する。
図１は、実施形態の救急患者治療支援システム（以下、単に支援システムという）の概
略図である。図１に示す支援システムは、救急患者の治療を行う病院（以下、単に病院と
いう）の担当者が操作する端末である一次端末１と、指導的専門医が操作する端末である
二次端末２との間でインターネットのようなネットワークを介して情報のやり取りをする
ことで治療を支援するものである。

病院としては、救急指定を受けた病院である場合が多いが、必ずしも救急病院ではなく
とも救急患者が運び込まれる場合があり、救急指定病院には限られない。
また、本実施形態の支援システムは、脳血管障害のような重篤な救急患者の治療に特に
適したシステムであり、病院としては重篤な救急患者の受け入れ可能な病院であることが
想定されているが、そのような場合に限られる訳ではない。
実施形態の説明において、端末とは、情報の入出力が行われるコンピュータのことであ
り、ネットワークを介して情報を送受信したり、受信した情報を画面に表示したりするこ
とができるものであって、典型的にはパソコンや携帯電話、ＰＤＡ等である。携帯電話の
場合、いわゆるスマートフォンが含まれるのは言うまでもない。
一次端末１を操作する「担当者」とは、典型的には、救急患者を治療する担当となった
医者（以下、担当医という）であるが、担当医から指示を受けた担当者とは別の者（看護
士や事務職の者）が操作する場合もあり、これらが「担当者」となる場合もある。

指導的専門医とは、特定の疾病の治療について特別の専門的知識と経験を有する者とし
て認められる者である。「経験」とは、疾病についての診断、治療又はその両方の経験を
指している。
現在、各科の学会等では、それぞれの分野において高度な専門的知識や技量、経験を持
つ医師を専門医として認定している。専門医になるには、多くの場合、まず学会の認定医
になった後、さらに研修や実習、試験等を経て専門医としての認定を受ける。
本実施形態における指導的専門医とは、このような専門医よりさらに高いレベルの専門
性を持つ医師である。具体的には、いわゆる指導医やそれに類するレベルの医師が想定さ
れている。指導医とは、専門医よりもさらに高度の知識や技量、経験を有し、認定医や専
門医を指導する立場にある医師を一般的に指す。本実施形態の指導的専門医とは、このよ
うな指導医又は指導医と同等ないしそれ以上のレベルの者が想定されている。但し、後述
するように、本実施形態においては、指導的専門医は、見解情報を提供してもらう相手側
であり、どの程度の知識、技量、経験を有する者に見解情報を提供してもらうかは、状況
により適宜決定すれば良い。したがって、専門医よりも高い知識等を有することは必要で
あるが、指導医よりも低いレベルの者であっても指導的専門医として見解情報を提供して
もらうこともあり得る。

本実施形態の支援システムは、上記一次端末１及び二次端末２と、サーバ群等によって
構成されている。各一次端末１とサーバ群は、病院内に設けられたイントラネット１０に
接続されている。イントラネット１０は、不図示のファイアウォールを介してインターネ
ットに接続されており、不正なアクセスが防止されている。
サーバ群のうちの一つは、一次端末１と二次端末２との間のコミュニケーションを仲介
するコミュニケーションサーバ３である。サーバの別の一つは、上記指導的専門医の情報
を記録した指導的専門医データーベースファイル等を管理するデーターベースサーバ４で
ある。さらに別のサーバとして、記録サーバ５、ＰＡＣＳサーバ６及び電子カルテサーバ
７がイントラネット１０上に設けられている。これらのサーバは、それぞれのサーバコン
ピュータとして設けられることもあるが、一つのサーバコンピュータが二つ以上の異なる
サーバの役割を兼用するよう設けられる場合もある。後者の場合は、一つのサーバコンピ
ュータが二以上の異なるサーバの役割を果たすようサーバプログラムが実装される。

病院内には多くの職員がいるから、一次端末１も多数存在する。一次端末１は、パソコ
ン（デスクトップ又はノート）であったり、携帯電話やＰＤＡのような携帯端末であった
りする。パソコンやワークステーションの場合、イントラネット１０上に有線ＬＡＮを介
して設けられている。携帯端末の場合、インターネットのような公衆回線を介してイント
ラネット１０に接続されるのが一般的であるが、病院内に設けられた無線ＬＡＮを介して
イントラネット１０と直接つながっている場合もある。

また、病院には、各種検査機器が設けられている。これら検査機器には、ＭＲＩやＸ線
ＣＴといった検査結果を画像として得る機器（以下、撮影機器と呼ぶ）が含まれている。
また、撮影機器が出力する画像をサーバで一括管理するＰＡＣＳ(Picture Archivingand
Communication System)もイントラネット１０上に設けられている。ＰＡＣＳは、ＰＡＣ
Ｓサーバ６を含んでおり、ＰＡＣＳサーバ６内の画像データは、イントラネット１０を介
して一次端末１等で取得できるようになっている。さらに、イントラネット１０上には、
電子カルテシステムも設けられている。電子カルテシステムは、電子カルテサーバ７を含
んでおり、電子カルテサーバ７内の電子カルテデータも、イントラネット１０を介して一
次端末１等で取得できるようになっている。これらＰＡＣＳや電子カルテシステムは、各
医療情報システムメーカーから販売されているので、適宜選択して用いれば良い。

本実施形態のシステムの各部の詳しい説明の前に、本実施形態のシステムを利用しつつ
行われる救急患者の治療の業務フローについて概略的に説明する。
図２は、本実施形態のシステムを利用した救急患者の治療について段階的且つ概略的に
示した業務フロー図である。
図２に示すように、業務は、救急患者が発生したことの連絡を受けることから始まる。
この連絡は、受け入れが可能かを消防署や救急隊員が問い合わせてくることであるが、救
急患者の家族等が直接問い合わせてくることもある。
問い合わせを受けた病院側は、対応できる医者がいるか、ＩＣＵのような治療施設に空
きがあるか等を確認し、しかるべき者が受け入れを決定する。この際、対応できる医者が
非番でいない場合、携帯電話等に連絡を入れ、救急車の到着に合わせて職務に就くことが
可能かを聞き、可能であれば受け入れ可能の返事をする。

救急車が到着して患者が搬入されると、容態を確認し、必要な検査をすぐさま行う。こ
の検査には、ＭＲＩやＣＴスキャンのような撮影機器を利用した検査が含まれる（以下、
この検査で得られた画像を「初期疾病画像」と呼ぶ）。体温や血圧のような比較的簡単な
検査は、搬送中に救急車内で行われることもある。
初期的な患者の検査の後、またはこれと並行して、電子カルテの作成が行われる。その
病院で過去に治療したことのある患者の場合には、電子カルテの新規作成は行われず、診
断や治療が一段落した際に電子カルテの更新が行われる。

次に、実施形態の支援システムを利用するかどうかの決定が行われる。利用するかどう
かとは、他の病院ないし機関に所属する指導的専門医に見解を求めた上で診断や治療を行
うかどうかの決定である。この決定は、当然のことながら、その救急患者の担当となった
医者（担当医）において、どのような疾病であるか（診断）や、どのように治療すべきか
（治療方針）や、追加検査が必要であるかどうか等について、自らの判断のみで決定でき
るかどうかの検討が含まれる。自らの判断では決定できないと思われる場合や、自らの判
断では決定できるものの、指導的専門医の見解を求めるべきであると思われる場合には、
この支援システムを利用することになる。

支援システムを利用しないとの決定の場合、自らの判断で診断を行い、必要と判断され
た追加検査等を行いながら、治療を実行する。一方、支援システムを利用すると決定した
場合、どの程度高いレベルの指導的専門医に見解を求めるべきかを決定した後、各指導的
専門医に、見解を提供することが可能かどうかを事前に問い合わせる問い合わせ情報を一
次端末１から送信する。
見解の提供が可能であると返信してきた指導的専門医が全くいない場合、専門性のレベ
ルを下げるかどうかを検討し、下げない場合には、支援システムの利用は諦め、独力での
診断・治療とする。レベルを下げる場合には、低いレベルに設定し直して問い合わせ情報
を一次端末１から改めて送信する。
見解の提供が可能であると返信してきた指導的専門医が一人以上いる場合には、その段
階で得られている疾病の情報（初期疾病画像を含む。以下、初期疾病情報と呼ぶ。）を指
導的専門医に送り、見解を求める。この見解は、どのような疾病であるかの情報（診断情
報）、どのように治療すべきかの情報（治療方針情報）又は追加検査が必要かどうかの情
報（追加検査要否情報）である。これらの情報が組み合わせられて寄せられる場合もある
。以下、これらの情報をまとめて見解情報と呼ぶ。

初期疾病情報は二次端末２に送られ、各指導的専門医が二次端末２上で初期疾病情報を
表示して内容を検討し、見解情報を二次端末２から返信する。担当医は、返信された見解
情報を院内の一次端末１で確認する。また、状況に応じて、見解情報を寄せた各指導的専
門医や担当医の間でチャット会議のようなリアルタイムコミュニケーションを行う。担当
医は、これらを踏まえて、診断や必要な追加検査、治療方針決定等を行った後、治療を実
行する。

以上の業務を行うのに利用される本実施形態の支援システムの各部の構成について、以
下に詳しく説明する。
まず、データベースサーバ４について説明する。データベースサーバ４は、データベー
ス管理プログラムを実装したサーバであり、サーバの記憶部（ハードディスクのような記
憶装置）には、各種のデータベースファイルが記憶されている。
データベースファイルの一つは、指導的専門医の情報を記録した指導的専門医データベ
ースファイル（以下、指導的専門医ＤＢＦ）である。この他、病院に勤務する医師（勤務
医）の情報を記録した勤務医データベースファイル（以下、勤務医ＤＢＦ）や、本システ
ムの利用の管理のために一時的に情報が記録されるテンプ案件ＤＰＦや、同様に管理のた
めに案件毎に二次端末２の情報を一時的にデーターベース化するテンプ送信先ＤＢＦ等が
データーベースサーバの記憶部に記憶されている。

図３は、指導的専門医ＤＢＦの構造の一例を示した概略図である。図３に示すように、
指導的専門医データーベースファイルは、指導的専門医を特定するコードである専門医Ｉ
Ｄ、専門医氏名、端末アドレス等の指導的専門医についての各種情報をデータベース化し
たものである。
端末アドレスは、情報の送信先としての二次端末２を特定する情報である。本実施形態
では、端末アドレスとして、「端末識別情報」と「メールアドレス」とが記録されるよう
になっている。このうち、「端末識別情報」は、その指導的専門医が操作する二次端末２
を識別する情報であり、パソコン等の場合にはＩＰアドレス又はマックアドレスであり、
携帯電話にはいわゆる個体識別番号である。情報の送受信にメールを使用する場合には端
末アドレスとしてメールアドレスが使用されることになるが、ｆｔｐのようなサーバプロ
グラムによる場合には、端末識別情報が使用されることもある。

また、「専門分野」は、その指導的専門医が指導的専門医であるとされる治療科目の分
野の情報である。「専門分野コード」は、検索等のために各専門分野について付与された
コード情報である。
「専門性レベル」は、その指導的専門医が専門分野においてどの程度のレベルの専門性
を有するかの情報である。本実施形態では、ＡＡ、Ａ、Ｂの三つのランクでレベル付与さ
れるようになっており、ＡＡが最も高く、Ｂが最も低い。一例としては、Ｂのレベルが通
常の指導医のレベルで、ＡＡがその分野でいわゆる権威として名の通った指導医のレベル
とし、Ａをその中間程度のレベルとすることができる。この他、指導的専門医データーベ
ースファイルには、その指導的専門医の所属機関等の情報が登録されるようになっている
。また、図示はされていないが、指導的専門医ＤＢＦには、指導的専門医のレベルを推し
量る参考情報として、「プロフィール」のフィールドと、「手術回数」のフィールドが設
けられている。

また、同様に図示はされていないが、指導的専門医ＤＢＦには、「端末タイプ」の名前
のフィールドが設けられている。「端末タイプ」は、二次端末の種類を登録したフィール
ドである。このフィールドには、「第３世代携帯電話」、「スマートフォン」、「パソコ
ン」といった端末の種類の情報が記録される。この情報は、後述するように、画像を送信
する際の圧縮レベルの選択等に利用される。

本実施形態の支援システムは、上記のような指導的専門医の情報を指導的専門医データ
ベースファイルに登録する登録手段を備えている。イントラネット１０上には、病院の事
務担当が操作する一次端末１である管理用端末が設けられており、上記のような指導的専
門医に関する各情報は、後述するように管理用端末等において入力され、指導的専門医デ
ーターベースファイルに記録されて登録される。したがって、管理用端末やデータベース
サーバ４等により登録手段が構成されている。
尚、本システムで情報がデータベース化される指導的専門医については、後述する問い
合わせ情報の送付相手として予め了解を取っており、上記各情報が指導的専門医側から電
子メール、ＦＡＸ又は郵便等で送られる。事務担当が管理用端末を操作し、指導的専門医
データベースファイルにアクセスし、送られた情報を入力して指導的専門医ＤＢＦに記録
しておく。

端末識別情報等は、インターネットを介して二次端末２にアクセスさせ、その際のセッ
ション情報から取得するのが簡便であるので、そのような手法が取られる。例えば、コミ
ュニケーションサーバ３へのアクセス情報（ＵＲＬ等）を記載した電子メールを二次端末
２に送り、そこからコミュニケーションサーバ３にアクセスしてもらうようにする。コミ
ュニケーションサーバ３では、セッション情報から端末識別情報や電子メールアドレスを
読み取り、それをデーターベースサーバに送って記録するようにする。このようなシステ
ム構成は、会員登録を行うサイトにおけるシステムと同様にできるので、詳細な説明は割
愛する。

次に、勤務医ＤＢＦについて説明する。図示は省略するが、勤務医ＤＢＦは、各勤務医
について付与されたＩＤである勤務医ＩＤ、勤務医氏名、治療科目等の情報をデータベー
ス化したものである。また、各勤務医には、セキュリティのためのパスワードが与えられ
ており、パスワードの情報も勤務医ＤＢＦの各レコードに記録されている。

次に、テンプ案件ＤＢＦ及びテンプ送信先ＤＢＦについて説明する。
図４は、テンプ案件ＤＢＦの構造の一例を示した概略図である。図４に示すように、テ
ンプ案件ＤＢＦは、案件ＩＤ、勤務医ＩＤ、問い合わせ情報送信日時、対応可の有無等の
情報がデータベース化されている。
図５は、テンプ送信先ＤＢＦの構造の一例を示した概略図である。テンプＤＢＦは、一
人の救急患者の治療についての本システムの利用（案件）ごとに新しく作成されるデータ
ベースファイルである。テンプ送信先ＤＢＦは、図４に示す案件ＩＤをファイル名にして
作成される。図５に示すように、テンプＤＢＦには、問い合わせ情報を送信した相手先の
指導的専門医の情報がデータベース化されている。各レコードには、問い合わせ情報の送
信日時に加え、可否情報や初期疾病情報の送信日時等の情報も記録されるようになってい
る。

次に、コミュニケーションサーバ３について説明する。
コミュニケーションサーバ３は、各端末１，２との間でクライアント−サーバ環境を実
現し、各種業務や情報を提供するものである。主要なサービスの一つは、各端末間での情
報のやり取りの仲介である。情報のやり取りの多くは、電子メールの送受信で行われるの
で、コミュニケーションサーバ３は、メールを転送するサーバサイドプログラムであるＭ
ＴＡ(Mail Transfer Agent)を実装している。例えば、sendmail、qmail等である。この他
、通常のウェブサーバと同様に、ＨＴＭＬプロトコルでファイルを提供したり、ＦＴＰで
ファイルを転送したりすることもできるようになっている。これらの構成は、通常のウェ
ブサーバと同様なので、説明は省略する。

また、実施形態の支援システムは、初期疾病情報を入力させて送信する一次送信手段を
備えている。一次送信手段は、コミュニケーションサーバ３と、コミュニケーションサー
バ３に実装された一次送信プログラムによって構成されている。
コミュニケーションサーバ３には、一次送信プログラムの他、本実施形態の支援システ
ムを利用した業務のための特別のプログラムが実装されている。これらプログラムは、互
いに関連づけられて統合されている。説明の便宜上、プログラムの上位概念としてプロジ
ェクトという用語を用い、統合されたプログラム群からなるものを救急疾病治療支援プロ
ジェクトと呼ぶ。

救急疾病治療支援プロジェクト内の各プログラムは、一例としてＪａｖａやＶＢ(Micro
soft Visual Basic)等といったオブジェクト指向プログラミング言語で記述されている。
コミュニケーションサーバ３の記憶部には、情報の入力のための各種のフォームウインド
ウ（以下、単にフォーム）を端末に表示するファイル（以下、フォームファイル）が記憶
されている。各フォームファイルには、プログラムを起動するためのボタン（コマンドボ
タン）が必要に応じて埋め込まれている。また、コミュニケーションサーバ３の記憶部に
は、問い合わせ情報や初期疾病情報等を入力して送信するためのフォームを提供する各種
ファイルが記憶されており、端末から送信要求があった際にファイルを送信し、端末上に
フォームを表示するようになっている。
また、救急支援プロジェクト内の各プログラムは、コミュニケーションサーバ３内の所
定のＵＲＬ（例えば、http://www.99medical.gr.jp/project/）に記述されている。各端
末間の情報の送受信はＵＲＬを通して行われる。各端末からこのＵＲＬにアクセスがされ
ているとき、セッション変数には各種の情報が格納され、各端末１，２間や各フォーム間
での情報の受け渡しが行われる。

救急支援プロジェクト内の各プログラムの多くは、病院内の各一次端末１に対して治療
支援業務を行わせるプログラムとなっている。これらのプログラムを起動させるためのメ
ニューフォームが用意されており、そのファイル（以下、メニューフォームファイル）が
記憶部に記憶されている。
図６は、救急疾病治療支援プロジェクトのメニューフォームの一例の概略図である。メ
ニューフォームファイルは、端末のＯＳに依存した通常動作画面（ウインドウズの場合に
はいわゆるデスクトップ）に設けられたアイコンのクリックで記憶部から読み出され、デ
ィスプレイに表示されるようになっている。図６に示す例は、表示する一次端末１がパソ
コンである例となっている。メニューフォームは一次端末１が携帯端末の場合でも表示可
能であり、携帯端末用のメニューフォームのファイルが別途コミュニケーションサーバ３
の記憶部に記憶されている。

図６に示すように、メニューフォームでは、「指導的専門医情報新規登録」と表記され
たコマンドボタン（以下、専門医情報登録ボタン）３１が設けられている。専門医情報登
録ボタン３１は、指導的専門医データーベースファイルに新しいレコードを追加して指導
的専門医の情報を登録するためのコマンドボタンである。
コミュニケーションサーバ３の記憶部には、図４に示す指導的専門医データーベースフ
ァイルのレコードの各フィールドの情報を入力するためのフォーム（以下、専門医情報入
力フォーム）用のファイルが記憶されている。専門医情報登録ボタン３１がクリックされ
ると、このファイルが読み出されて専門医情報入力フォームが端末１上に表示される。専
門医情報入力フォームには登録用のコマンドボタン（登録ボタン）が設けられており、情
報を入力した上で登録ボタンをクリックすると、データーベースサーバ上のデーターベー
スプログラムが起動し、レコードが追加されて入力情報がファイルに記録されるようプロ
グラミングされている。

また、図６に示すように、メニューフォームには、「指導的専門医情報更新」と表記さ
れたコマンドボタン（以下、専門医情報更新ボタン）３２が設けられている。コミュニケ
ーションサーバ３の記憶部には、指導的専門医の登録情報を更新するためのフォーム（以
下、専門医情報更新フォーム）用のファイルが記憶されている。専門医情報更新ボタン３
２がクリックされると、指導的専門医の氏名又は専門医ＩＤ等を入力させるウインドウが
表示され、入力された情報により指導的専門医データーベースファイルが検索されて該当
するレコードの情報が専門医情報更新フォームに組み込まれて表示される。専門医情報更
新フォームにも登録ボタンが設けられており、表示された各情報は端末１上で変更可能と
なっている。任意の情報を変更して登録ボタンがクリックされると、変更後の情報がデー
ターベースサーバ４に送られ指導的専門医データーベースファイルの該当レコードに記録
されてファイルが更新されるようプログラミングされている。

本実施形態では、初期疾病情報を送信する前に、問い合わせ情報を一次端末１から入力
させてコミュニケーションサーバに送信する問い合わせ情報送信手段が設けられている。
問い合わせ情報送信手段は、コミュニケーションサーバ３と、コミュニケーションサーバ
３に実装された問い合わせ情報送信プログラム等によって構成されている。
具体的に説明すると、図６に示すように、メニューフォームには、「問い合わせ情報送
信」と表記されたコマンドボタン（以下、問い合わせ送信ボタン）３３が設けられている
。一方、コミュニケーションサーバ３の記憶部には、問い合わせ情報入力フォームのファ
イル及び問い合わせ情報送信フォームのファイルが記憶されている。

図７は、問い合わせ情報入力フォームの一例を示した概略図である。
図７に示すように、問い合わせ情報入力フォームは、救急搬送日時入力欄、性別入力欄
、年齢入力欄、患者ＩＤ入力欄、患者氏名入力欄、初期所見入力欄３４、治療科目入力欄
、レベル入力欄、回答期限入力欄を有している。また、「確認画面」と表記されたコマン
ドボタン（以下、確認ボタン）３５が設けられている。
救急搬送日時入力欄は、救急患者が搬送された日時を入力する欄であり、「時刻・カレ
ンダー」と表記されたコマンドボタンをクリックすることにより、プルダウンリストによ
る時刻表示やカレンダーが表示され、時刻や日時を容易に選択して入力できるようになっ
ている。
性別入力欄は、いわゆるラジオボタンであり、いずれかを選択する。
年齢入力欄は、年齢の数字がプルダウンリストで表示され、いずれかを選択する欄であ
る。

患者ＩＤの欄は、この段階で判っていれば入力される。救急搬送され、家族が同伴して
いる等しており、保険証や診察券等を持参していれば、それに従って電子カルテサーバ７
を検索し、患者ＩＤの情報を取得してこの欄に入力する。
初期所見入力欄３４は、テキストボックスである。初期所見入力欄３４は、各指導的専
門医に対して見解情報を寄せることが可能かどうかを問い合わせるに際して、当該救急患
者の容態について初期的な所見を文字情報で送信するものである。例えば、「激しい頭痛
を訴えて救急搬送された」とか、「○○の疑いがある」とかの文字情報が入力される。ま
た、脳神経系の疾病の場合、患者の意識レベルや神経症状といった神経学的所見が含まれ
ることが多い。

診療科目入力欄は、プルダウンリストであり、見解情報を寄せて欲しい指導的専門医が
属する診療科目を選んで入力する。当然のことながら、これは、初期所見の段階での患者
の容態から判断ないし推測される診療科目ということになる。
レベル入力欄は、見解情報を寄せて欲しい指導的専門医のレベルを設定する欄である。
本実施形態では、「ＡＡ」、「Ａ」、「Ｂ」というレベルから選んで設定するようになっ
ているので、レベル入力欄もこれらが表示されるプルダウンリストになっている。尚、「
ＡＡ」を選べばＡＡのレベルの指導的専門医を選んだことになり、「Ａ」を選べばＡのレ
ベル以上だから、「ＡＡ」又は「Ａ」のレベルということになり、「Ｂ」を選べば「ＡＡ
」、「Ａ」又は「Ｂ」のレベルということになる。
回答期限入力欄は、見解情報を寄せることができるかどうか回答の期限を入力する欄で
ある。例えば、「１時間以内」、「３時間以内」、「５時間以内」、「７時間以内」・・
・というように、問い合わせ情報の送信があってからの時間で回答期限を設定するように
なっている。これ以外にも、「本日１９時まで」、「本日２１時まで」、「本日２３時ま
で」というように、日時を指定して回答期限としても良い。
「担当医」と表記された欄は、入力された勤務医ＩＤに従って自動的に表示される。即
ち、メモリ変数から勤務医ＩＤが読み出され、勤務医ＤＢＦが検索されて勤務医の氏名の
情報が取得され、この欄に嵌め込まれて表示されるようになっている。

図８は、問い合わせ情報送信フォームの一例を示した概略図である。図７において、各
欄が正しく入力されて確認ボタン３５がクリックされると、図８に示す問い合わせ情報送
信フォームが表示されるようになっている。
問い合わせ情報送信フォームでは、問い合わせ情報入力フォームで入力された各情報が
確認のために表示される。そして、送信ボタン３６がクリックされると、入力された各情
報がコミュニケーションサーバ３に送信されるようになっている。即ち、送信ボタン３６
には、問い合わせ情報プログラムの起動コマンドが埋め込まれている。この起動コマンド
は、問い合わせ情報入力フォームで入力された各情報を引数として渡して問い合わせ情報
送信プログラムを起動する。但し、図８に示す情報のうち、患者ＩＤ及び患者氏名につい
ては、送信されない。このような患者を特定できる情報を院外の第三者に開示することは
プライバシー保護の観点で好ましくないので、担当医において画面上確認できるだけにし
てあり、二次端末には送信されないようになっている。

図９は、問い合わせ情報送信プログラムの概略を示したフローチャートである。図９に
示すように、問い合わせ情報送信プログラムは、診療科目入力欄及びレベル入力欄の情報
をデータベースサーバ４に送り、指導的専門医ＤＢＦを検索して該当するレコードがある
かどうか判断する。即ち、その診療科目にそのレベルの指導的専門医がいるかどうか判断
する。レコードが全くない場合、「該当する指導的専門医は登録されていません。」とい
うエラーメッセージが表示され、プログラムを終了させる。この場合、問い合わせ情報入
力フォームが再び表示される。
該当するレコードがある場合、そのレコードの専門医ＩＤ、氏名、端末アドレスを読み
出して各々メモリ変数に一時的に格納する。すべてのレコードの検索が終了したら、案件
ＩＤを新たに生成し、テンプ案件ＤＢＦに新たなレコードを追加し、案件ＩＤ、勤務医Ｉ
Ｄ、問い合わせ情報送信日時等の情報を記録する。次に、案件ＩＤをファイル名にしてテ
ンプ送信先ＤＢＦを新たに作成し、ヒットした指導的専門医ＤＢＦの各レコードから読み
出した専門医ＩＤ、氏名、端末アドレスの情報をそれぞれのレコードの情報として記録す
る。
その後、コミュニケーションサーバ３の記憶部に記憶されているメールフォームを読み
出し、問い合わせ情報入力フォームで入力された情報を嵌め込む。そして、指導的専門医
ＤＢＦから読み出した各端末アドレスに順次送信する。

本実施形態の支援システムは、送信された情報を各二次端末２において受信して表示す
る受信表示手段を備えている。受信表示手段は、各二次端末２と、各二次端末２にインス
トールされている受信表示プログラムによって構成されている。本実施形態では、各情報
は電子メールの形で送信されるので、受信表示プログラムは、各二次端末２にインストー
ルされたメーラ（電子メールプログラム）ということになる。
上記のように問い合わせ情報が嵌め込まれた電子メール（以下、問い合わせメール）は
、インターネットを介して各二次端末２に送信される。問い合わせメールは、受信表示プ
ログラムによって各二次端末２で受信されて表示される。図１０は、二次端末２に表示さ
れた問い合わせメールの一例を示した概略図である。図１０では、二次端末２がスマート
フォンであり、問い合わせメールがスマートフォン上に表示された状態が描かれているが
、他の種類の携帯電話の場合もあり、ノートパソコンやデスクトップパソコンの場合もあ
る。

図１０に示すように、受信した問い合わせメールは、問い合わせ情報入力フォームで入
力された各情報が表示されるようになっている。この例では、回答期限は、問い合わせ情
報の送信から例えば１時間後が設定されており、問い合わせ情報送信プログラムが一時間
後の時間を計算してメールに嵌め込んでいる。
尚、この例では、二次端末２のメーラ上では送信元の表示は、コミュニケーションサー
バ３の登録名となってしまい（この例では「救急患者治療支援システム」）、送信元の医
師が特定できなくなってしまうので、問い合わせ情報を入力した勤務医の氏名や所属が表
示されるようにしている。

本実施形態の支援システムは、問い合わせ情報が送信された際、見解情報を送信するこ
とができるか否かの情報である可否情報を二次端末２において入力させて一次端末１に送
信する可否情報送信手段を備えている。可否情報送信手段は、本実施形態では、問い合わ
せメールに嵌め込まれた可否情報送信ボタンと、コミュニケーションサーバ３と、可否情
報送信プログラム等によって構成されている。
図１０に示すように、問い合わせメールには、「対応可能」との表記がされたコマンド
ボタン（以下、可能ボタン）２１と、「対応不可」と表記されたコマンドボタン（以下、
不可ボタン）２２とが嵌め込まれている。これらのボタンが、可否情報送信ボタンである
。

本実施形態では、可否情報送信プログラムは、サーバサイドのプログラムとなっている
。即ち、可否情報送信プログラムは、コミュニケーションサーバ３に実装されており、可
否情報送信ボタンによって起動するようになっている。
可否情報送信ボタンには、生成された案件ＩＤと可否情報を意味するコードとが埋め込
まれている。即ち、可能ボタン２１には、案件ＩＤと、対応可能である旨を意味するコー
ド（例えば、"Yes"）と、送信元アドレス（二次端末２のメールアドレス）とを引数にし
て可否情報送信プログラムを実行するコマンドが埋め込まれており、不可ボタン２２には
、案件ＩＤと、対応不可である旨を意味するコード（例えば、"No"）と、送信元アドレス
とを引数にして可否情報送信プログラムを実行するコマンドが埋め込まれている。

可否情報送信プログラムは、案件ＩＤがファイル名になっているテンプ送信先ＤＢＦを
開き、送信元アドレス又はセッション情報から取得した端末識別情報に従って該当するレ
コードの「可否情報」の欄に値（上記の例では"Yes"又は"No"）を記録するようプログラ
ミングされている。そして、テンプ案件ＤＢＦを開き、該当する案件ＩＤのレコードの「
対応可の有無」のフィールドに値（例えば"Yes"）を記録するようプログラミングされて
いる。
可否情報送信プログラムは、次に、一次端末１にメールの送信を行うようプログラミン
グされている。このメールの送信は、対応可との情報が送信された場合（可能ボタンがク
リックされた場合）のみ行われるものであり、対応可との情報の送信があった旨を即座に
担当医に知らせるためのものである（以下、このメールを対応可伝達メールという）。

図１１は、可否情報送信プログラムによって一次端末１に送信された対応可伝達メール
の一例を示した概略図である。図１１に示すように、可否情報伝達メールでは、担当医が
送信した問い合わせ情報を確認のために送るとともに、対応可能と回答してきた指導的専
門医の氏名やプロフィール情報を送るようになっている。コミュニケーションサーバ３の
記憶部には、このようなメールのテンプレートファイルが記憶されており、可否情報送信
プログラムは、テンプレートファイルにこれら情報を組み込んで一次端末１に送信するよ
うプログラミングされている。
本実施形態の支援システムは、対応可との回答があった指導的専門医が操作する二次端
末２に対し、初期疾病情報を送信して正式に見解情報の提供を要請する一次送信手段を備
えている。一次送信手段は、初期疾病情報を、一次端末１において入力させてコミュニケ
ーションサーバ３に送信し、指導的専門医データベースファイルに記録されたアドレス情
報に従ってコミュニケーションサーバ３から各二次端末２に到達するよう送信する手段で
ある。初期疾病情報には、救急患者の画像と画像の撮影時刻との情報が含まれている。

具体的に説明すると、一次送信手段は、一次端末１と、コミュニケーションサーバ３と
、コミュニケーションサーバ３に実装された一次送信プログラム等によって構成されてい
る。コミュニケーションサーバ３の記憶部には、初期疾病情報を送信するためのフォーム
（以下、初期疾病情報送信フォーム）用のファイルが記憶されている。図１１に示すよう
に、可否情報伝達フォームには、「初期疾病情報送信」と表記されたコマンドボタン２３
が設けられている。このボタンは、初期疾病情報送信フォームのファイルを読み出して一
次端末１に初期疾病情報送信フォームを表示するコマンドボタン（以下、送信フォーム表
示ボタン）となっている。送信フォーム表示ボタン２３には、初期疾病情報送信フォーム
を表示するとともに、可否情報伝達メールのセッション情報から送信元の端末アドレスを
読み取り、メモリ変数に格納するプログラムが埋め込まれている。

図１２は、初期疾病情報送信フォームの一例を示した概略図である。図１２では、同様
に一次端末１がスマートフォンのような携帯端末である場合の例が示されている。
初期疾病情報送信フォームは、送信した問い合わせ情報を確認のため表示するとともに
、追加所見の入力欄（追加所見欄）２４と、画像確認用のコマンドボタン（画像確認ボタ
ン）２５と、初期疾病情報送信ボタン２６等を有している。追加所見欄２４は、その後の
救急患者の容態に関する情報等をテキストで入力する欄である。この欄は任意であり、省
略して初期疾病情報を送信することができる。

初期疾病情報の主要なものは、画像である。図１２に示す例では、画像の情報は自動的
に取り込まれて二次端末２に送信されるようになっている。即ち、可否情報送信プログラ
ムは、対応可伝達メールを送信した際、初期情報送信ボタン２６に案件ＩＤを埋め込むよ
うプログラミングされている。初期疾病情報送信ボタン２６は、案件ＩＤを検索キーにし
てテンプ案件ＤＢＦを検索し、該当するレコードから「患者氏名」の情報と「患者ＩＤ」
の情報を取得するとともに、ＰＡＣＳサーバ６にアクセスし、患者ＩＤを検索キーにして
検索して該当する患者の画像のファイル情報を取得し、一次的にメモリ変数に格納するよ
うプログラミングされている。

画像のファイル情報は、上記のように初期疾病情報送信フォームを表示した際に自動的
に取り込まれるが、事前に確認できるようにもなっており、そのためのボタンが図１２に
示す画像確認ボタン２５である。画像確認ボタン２５がクリックされると、フォームを新
たにオープンし、取り込んだファイル情報に従ってＰＡＣＳサーバ６にアクセスしてフォ
ーム内に画像が表示されるようになっている。尚、その患者について複数の画像がある場
合、すべての画像のファイル情報がメモリ変数に格納されて送信されることになるが、画
像を選択させて特定の画像のみを送るようにしても良い。
また、図１２に示すように、初期疾病情報送信フォームには、見解送信期限入力欄２７
が設けられている。見解送信期限入力欄は、いつまでに見解情報を送信して欲しいかの期
限を入力する欄である。この例では、「３０分以内」、「１時間以内」、「３時間以内」
、「５時間以内」・・・というように、初期疾病情報を送信してからの時間を選ぶプルダ
ウンリストとなっている。

図１２に示す初期疾病情報送信ボタン２６がクリックされると、一次送信プログラムが
起動するようになっている。また、コミュニケーションサーバ３の記憶部には、初期疾病
情報を送信するメールフォーム（以下、初期疾病情報送信メールフォーム）が記憶されて
いる。一次送信プログラムは、コミュニケーションサーバ３に実装されたプログラムであ
り、初期疾病情報送信メールフォームを読み出し、メモリ変数に格納しておいた画像のフ
ァイル情報を嵌め込み、同様にメモリ変数に格納しておいた端末アドレスに電子メールの
形で初期疾病情報を送信するようプログラミングされている。以下、この電子メールを、
「初期疾病情報メール」と呼ぶ。

図１３は、二次端末２において受信されて表示された初期疾病情報メールの一例を示し
た概略図である。図１３に示すように、初期情報送信メールには、問い合わせ情報の送信
の際に送られた患者情報や追加所見、見解送信期限等が含まれている。一次送信プログラ
ムは、案件ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、該当するレコードから各患
者情報を取得して初期疾病情報送信メールフォームに嵌め込むようプログラミングされて
いる。
また、図１３に示す例では、画像ファイルを初期疾病情報メールに添付したり嵌め込ん
だりするのではなく、別途アクセスさせて画像を閲覧させるようになっている。即ち、初
期疾病情報メールには、画像を閲覧するためのコマンドボタン（以下、画像閲覧ボタン）
４１が設けられている。
一方、コミュニケーションサーバ３の記憶部には、画像を表示するためのフォーム（以
下、画像表示フォーム）のファイルが記憶されており、二次端末２に画像ファイルを送信
して表示するプログラム（以下、画像表示プログラム）が実装されている。画像閲覧ボタ
ン４１は、この画像表示プログラムの起動コマンドとなっている。

図１４は、図１３において画像閲覧ボタン４１がクリックされた状態の一例を示した概
略図である。画像閲覧ボタン４１は、案件ＩＤと、画像のファイル情報と、その初期疾病
情報メールを受信・表示している二次端末２の端末アドレス又は端末識別情報とを引数に
して画像表示プログラムに渡すようになっている。画像表示プログラムは、案件ＩＤに従
ってテンプ送信先ＤＢＦを開き、端末アドレス又は端末識別情報を検索キーにして検索し
て対応可情報を送った二次端末２であるかどうかを判断する。対応可情報を送った二次端
末２であると判断されると、画像表示プログラムは、画像の閲覧を許可して良いと判断し
、ファイル情報に従ってＰＡＣＳサーバ６にアクセスして画像を取得するようプログラミ
ングされている。そして、画像表示フォームに画像ファイルを嵌め込み、二次端末２に送
信して表示するようプログラミングされている。

この際、画像表示プログラムは、指導的専門医ＤＢＦにアクセスし、該当レコードの「
端末タイプ」のフィールドの情報を取得する。そして、端末タイプに従って画像の圧縮レ
ベルを決定し、そのレベルで圧縮をした後、二次端末２に送るようになっている。二次端
末２がパソコンやワークステーションの場合、圧縮をせずにそのまま送信する場合も当然
あり得る。このように二次端末２のタイプに応じて所定の圧縮レベルとするため、二次端
末２の表示能力に応じて最適な状態で画像が表示されるようになっている。尚、図１４に
示すように画像が二次端末２に表示された後は、サーバ側の制御はＰＡＣＳサーバ６に遷
移されており、二次端末２はＰＡＣＳサーバ６にアクセスしてＰＡＣＳサーバ６上のプロ
グラムを実行可能な状態となる。

図１４に示すように、画像表示フォームには、「画像再構築」と表記されたコマンドボ
タン（以下、画像再構築ボタン）４３が設けられている。一方、ＰＡＣＳサーバ６には、
画像を再構築して二次端末２に送信して表示するプログラム（以下、画像再構築プログラ
ム）が実装されている。
画像は、前述したように、ＭＲＩ等の撮影機器で撮像された画像である。周知のように
、これらの撮影機器は多くがデジタル化されており、デジタルデータが出力される。そし
て、出力データの可視化には各種のデータ処理が行われる。本実施形態の画像再構築手段
は、異なるデータ処理を行うことで異なる画像が二次端末２に表示されるようにする手段
である。

図１５は、画像再構築ボタン４３がクリックされた際の二次端末２の状態の一例を示し
た概略図である。図１５では、まず画像再構築のメニュー一覧が表示されるようになって
いる。この例では、「回転」と「動画」という二種類の再構築が行えるようになっている
。「回転」というのは、画像を回転させて患者の患部を異なる角度から撮像した画像のよ
うに変更するプログラムである。「動画」とは、画像データを動画として再構築し、動画
が二次端末２上で表示されるようにするプログラムである。動画として再構築する例とし
ては、画像のデータが元々動画の場合と、静止画のデータを処理して動画とする場合とが
ある。前者の場合、画像が動画データのうちの一つのフレームを取り出したものであるの
で、元データのうちのどこからどこまでを再生するか等を指定させて再構築することにな
る。後者の例としては、ＣＴ画像やＭＲＩ画像のように患者の体を所定の短い間隔で切り
取って撮影した断層写真の場合に、それらを所定の時間間隔でつなげていくことであたか
も動画であるように再構築する例が挙げられる。

本実施形態の支援システムの特徴点は、このような画像再構築プログラムが病院外の二
次端末２から実行することができるようになっている点であり、見解情報を寄せることが
可能であるとの回答をした指導的専門医にのみこのような操作を可能としている点である
。
図１６は、一例として、図１５において「回転」のコマンドボタンがクリックされた状
態の一例を示した概略図である。図１６に示すように、「回転」のコマンドボタンをクリ
ックすると、画像内に矢印が表示されるようになっている。矢印は、画像の中心から放射
状に八つほど表示されるようになっている。各矢印は、それが示す方向に画像の向きを変
えるサブプログラムを実行するものである。
この他、図１６に示すように、この例の画像再構築プログラムを実行すると、画像表示
フォームに「任意方向」と表記されたコマンドボタンが表示されるようになっている。こ
のコマンドボタンは、画面にタッチしながらドラグした方向に画像の向きを変えるサブプ
ログラムを実行するボタンである。画像再構築プログラムの他の構成としては、患者の患
部の部位を選択的に表示するよう変更する構成がある。例えば、ＭＲＩ画像のうち、骨の
部分だけを取り出し表示するようにしたり、血管の部分だけの取り出して表示したりする
再構築である。こらら画像再構築プログラムは、ＰＡＣＳサーバ６に実装される周知のも
のと同様にできるので、詳細な説明は割愛する。

また、画像として当初から動画が送信される場合もある。即ち、画像閲覧ボタン４１が
クリックされると二次端末２に動画が表示される場合もある。動画の場合、画像が過去の
ものではなく、リアルタイムの画像の場合もある。例えば、心電図のような患者に常時装
着して検査を行うことができる検査機器の場合、その出力データをリアルタイムでストリ
ーミング送信することも可能である。この構成を採用する場合、ストリーミング送信を行
うプログラムをコミュニケーションサーバ３に実装しておき、図１３に示す画像閲覧ボタ
ン４１がクリックされた際にこのプログラムが実行されるようにする。リアルタイムの画
像の動画配信は、救急患者の治療であることを考えると、特に好ましいと言える。即ち、
重篤な救急患者の場合、極めて短時間のうちに治療方針を決定しなければならないことが
多い。この場合、画像をリアルタイムで指導的専門医に見てもらい、その場で見解情報を
提供してもらうようにすれば、手遅れになることなく適切な治療を行うことができる確率
が高くなる。
尚、画像の送信の仕方としては、初期疾病情報メールに直接嵌め込んで送信するように
しても良いことは勿論である。

次に、図１３に戻り、見解情報の送信について説明する。
本実施形態の支援システムは、見解情報を各二次端末２において各々入力させ、入力さ
れた見解情報を一次端末１に送信する二次送信手段を備えている。二次送信手段は、本実
施形態では、二次端末２と、コミュニケーションサーバ３と、コミュニケーションサーバ
３に実装された二次送信プログラム等から構成されている。
図１４〜図１６に示す画像表示フォームにおいて、「キャンセル」と表記されたボタン
には、画像表示フォームを閉じ、図１６に示す初期疾病情報メールの画面に戻すとともに
、サーバの制御をＰＡＣＳサーバ６からコミュニケーションサーバ３に戻すコマンドが埋
め込まれている。

図１３に示すように、初期疾病情報メールには、「見解送信」と表記されたコマンドボ
タン（以下、見解送信ボタン）４２が設けられている。一方、コミュニケーションサーバ
３の記憶部には、見解情報の入力と送信のためのフォーム（以下、見解情報送信フォーム
）のファイルが記憶されている。
見解送信ボタン４２には見解送信フォームを表示するコマンドが埋め込まれており、見
解送信ボタン４２をクリックすると、図１７に示すような見解情報送信フォームが二次端
末２に表示されるようになっている。図１７は、見解情報送信フォームの一例を示した概
略図である。
図１７に示すように、見解情報送信フォームでは、見解情報をテキストで入力する欄（
以下、見解情報入力欄）４４が設けられている。また、見解情報送信フォームには、送信
ボタン４５が設けられている。この送信ボタン４５には、二次送信プログラムの起動コマ
ンドが埋め込まれている。送信ボタン４５は、セッション変数から案件ＩＤ、専門医ＩＤ
等を読み出した後、入力された見解情報とともにそれらの情報をコミュニケーションサー
バ３に送信するようプログラミングされている。

図１８は、二次送信プログラムの概略を示したフローチャートである。
二次送信プログラムは、テンプ案件ＤＢＦを開き、案件ＩＤを検索キーにしてテンプ案
件ＤＢＦを検索し、該当するレコードの「見解情報の有無」のフィールドに真値を記録す
る。また、案件ＩＤに従ってそのファイル名のテンプ送信先ＤＢＦを開き、専門医ＩＤを
検索キーにしてテンプ送信先ＤＢＦを検索し、該当するレコードの「見解情報送信日時」
のフィールドに、環境変数から日時を取得して記録する。それとともに、そのレコードの
「見解情報」のフィールドに、見解情報（テキスト）を記録する。
一方、コミュニケーションサーバ３の記憶部には、一次端末１上で見解情報を表示する
ためのメールフォーム（以下、見解情報表示フォーム）のファイルが記憶されている。二
次送信プログラムは、上記各ＤＢＦへの記録の後、送られた見解情報を見解情報表示フォ
ームに嵌め込み、テンプ案件ＤＢＦに記録されている勤務医ＩＤに従って、その勤務医の
一次端末１に見解情報表示フォームをメール送信する。これで、二次送信プログラムは終
了である。

図１９は、一次端末１に送信されて表示された見解情報表示メールの一例を示した概略
図である。図１９に示すように、見解情報表示メールは、送信された見解情報とともに、
その見解情報を送った指導的専門医の氏名、プロフィール等を含んでいる。二次送信プロ
グラムは、見解情報を見解情報表示フォームに嵌め込む際、セッション変数から専門医Ｉ
Ｄを読み出し、指導的専門医ＤＢＦを検索して専門医氏名やプロフィール等の情報を取得
し、見解情報表示フォームに嵌め込むようプログラミングされている。
図１９に示す見解情報表示メールは、見解情報が送信された際に即座に個別に一次端末
１上で内容を確認する手段であったが、本実施形態のシステムは、システムの一回の利用
（一人の救急患者の治療支援，一案件）について情報を統合して一次端末１に表示する統
合表示手段を備えている。「統合して」とは、各見解情報を比較して参照できるように同
一の一次端末１上に表示するという程度の意味である。

より具体的に説明すると、図６に示すように、メニューフォームには、「問い合わせ回
答確認」と表記されたコマンドボタン（以下、回答確認ボタン）３７が設けられている。
一方、コミュニケーションサーバ３の記憶部には、問い合わせ情報に対する回答有無を表
示する回答有無表示フォームが記憶されている。図２０は、回答有無表示フォームの一例
を示した概略図である。
図６に示す回答確認ボタン３７には、一次端末１を操作する者の資格を確認した後に回
答有無表示フォームを一次端末１に表示する回答確認プログラムの起動コマンドが埋め込
まれている。本実施形態では、問い合わせ情報に対する回答や見解情報が院内の誰でも閲
覧できるようにするのは妥当ではないとの考えから、限られた者にのみ情報の閲覧を許可
している。回答確認ボタン３７がクリックされると、回答確認プログラムは、勤務医ＩＤ
及びパスワードを入力させるフォームを表示し、勤務医ＩＤ及びパスワードが入力され、
勤務医ＤＢＦ内の情報と照らし合わせて正しく入力されていると判断されたら、勤務医Ｉ
Ｄをメモリ変数に格納した後、回答表示フォームを一次端末１に表示するようプログラミ
ングされている。この際、勤務医ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、勤務
医ＩＤが一致するレコードの各フィールドの情報を読み出し、回答有無表示フォームに表
示するようになっている。

図２０に示す例では、担当となっている勤務医（担当医）の名称が「○田×夫」であり
、この者が問い合わせ情報を送信したすべての案件についての回答有無が表示されている
。この例では、この者が問い合わせ情報を送信した案件は、「特許太郎」という患者につ
いての１件のみであり、これのみが表示されている。仮に、この「○田×夫」という勤務
医が、同時に複数の救急患者の治療を抱えていて、それぞれについて問い合わせ情報を送
信していると、回答有無表示フォームは、複数行のリスト表示となり、それぞれについて
回答有無が表示される。
コミュニケーションサーバ３の記憶部には、問い合わせ情報に対する回答を統合して表
示する回答統合表示フォームのファイルが設けられている。図２０に示す回答有無表示フ
ォームには、「回答有無」と表記された列に「回答あり」と表記されたコマンドボタン３
８が設けられている。このコマンドボタン３８は、回答確認プログラムが自動生成したコ
マンドボタンであり、テンプ案件ＤＢＦ内の該当レコードの回答有無のフィールドが真値
であった場合に自動生成されるコマンドボタンである。このコマンドボタン３８は、回答
統合表示フォームを表示するコマンドボタンとなっている（以下、回答表示ボタン）。

図２１は、一次端末１に表示された回答統合表示フォームの一例を示す概略図である。
図２１に示すように、回答統合表示フォームでは、その案件ＩＤについての患者情報や送
信した初期所見等の情報が表示されるとともに、見解情報を寄せることができるとの回答
があった指導的専門医の情報がリスト表示されるようになっている。回答表示ボタン３８
は、案件ＩＤがファイル名となっているテンプ送信先ＤＢＦを開き、「対応可否」のフィ
ールドが真値となっているレコードの専門医ＩＤの取得した後、その専門医ＩＤで指導的
専門医ＤＢＦを検索して該当レコードの情報を取得してリスト表示するプログラムの起動
コマンドが埋め込まれている。尚、「初期疾病情報送付有無」の列は、テンプ送信先ＤＢ
Ｆの「初期疾病情報送信日時」がＮｕｌｌ値かどうかの値が表示される。Ｎｕｌｌ値であ
れば偽値、Ｎｕｌｌ値でなければ真値が表示される。
図２１に示すように、回答統合表示フォームには、「初期疾病情報一括送信」と表記さ
れたコマンドボタン（以下、一括送信ボタン）３９が設けられている。コミュニケーショ
ンサーバ３の記憶部には、画像取り込みフォームのファイルが設けられており、一括送信
ボタン３９には画像取り込みフォームへのリンクが貼られている。

図２２は、画像取り込みフォームの一例を示した概略図である。この例では、回答統合
表示フォームの上に重ねるようにして新たにフォームが表示されるようになっている。図
２２に示すように、画像取り込みフォームは、「患者氏名」及び「患者ＩＤ」を表示する
とともに、画像ファイルを選ぶウインドウを表示するものとなっている。「患者氏名」及
び「患者ＩＤ」は、セッション変数から案件ＩＤを読み出し、テンプ案件ＤＢＦを検索す
ることで取得される。また、一括送信ボタンには、ＰＡＣＳサーバ６にアクセスし、患者
ＩＤを検索キーにして検索して該当する患者の画像フィアルを画像取り込みフォームにリ
スト表示するプログラムが埋め込まれている。
図２２に示すように、画像取り込みフォームには、ＯＫボタン５１が設けられている。
ＯＫボタン５１には、選択された画像ファイルのファイル情報（パス名及びファイル名）
をメモリ変数に一時的に格納するとともに、ファイル名を初期情報送信フォームに嵌め込
むプログラムが埋め込まれている。

図２３は、画像のファイル情報が取り込まれた後の初期疾病情報送信フォームの一例を
示した概略図である。この例では、xxx-yyy-10007201840.dcmというファイル名の画像が
取り込まれている。
また、図２３に示すように、初期疾病情報送信フォームには、同様に見解送信期限入力
欄５２が設けられており、同様にプルダウンリストとなっている。
図２３に示す送信ボタン５３には、一括型一次送信プログラムの起動コマンドが埋め込
まれている。図２４は、一括型一次送信プログラムの概略を示したフローチャートである
。
一括型一次送信プログラムは、初期疾病情報送信フォームで入力された初期疾病情報を
初期疾病情報メールフォームに嵌め込み、各端末アドレスに順次メール送信する。各端末
アドレスとは、その案件ＩＤにおいて対応可と回答してきた二次端末２であって、まだ初
期疾病情報が送信されていない二次端末２の端末アドレスである（図２１に示す回答統合
表示フォームにおいて「初期疾病情報送付有無」が偽値の端末アドレス）。該当するすべ
ての端末アドレスに初期疾病情報をメール送信すると、一括型一次送信プログラムは終了
である。
上記の一括型の初期疾病情報の送信において、図１２にフォームを示す即時送信型の初
期疾病情報の送信の場合と同様、画像のファイル情報の自動的に取り込むようにすること
も可能である。逆に、図１２の即時型において画像をマニュアル操作で取り込む構成を採
用しても良い。マニュアル操作の場合、画像が複数ある場合、選択して送信することがで
きる。

次に、見解情報の統合表示について説明する。
図６に示すメニューフォームには、「見解情報閲覧」と表記されたコマンドボタン（以
下、見解閲覧ボタン）５４が設けられている。一方、コミュニケーションサーバ３の記憶
部には、見解有無表示フォームのファイルが記憶されており、見解閲覧ボタン５４には、
見解有無表示フォームを一次端末１に表示する見解有無表示プログラムの起動コマンドが
設けられている。見解有無表示プログラムは、回答有無表示プログラムと同様、勤務医Ｉ
Ｄとパスワードを入力させ、アクセス権をチェックした後、勤務医ＩＤでテンプ案件ＤＢ
Ｆを検索し、該当するレコードの各フィールドの情報を読み出して見解有無表示フォーム
に嵌め込み、一次端末１に送信する。

図２５は、見解有無表示フォームの一例を示した概略図である。図２５に示すように、
見解有無表示フォームでは、入力された勤務医ＩＤの勤務医が問い合わせ情報を送信した
案件情報がリストで表示されるようになっている。この例では、抱えている案件は１つの
みであるので、リストは一つである。リストの末尾の列には、「見解有無」と見出しに表
記された列があり、この列に「見解有り」と表記されたコマンドボタン５５が設けられて
いる。このコマンドボタン５５は、見解有無表示プログラムが自動作成したコマンドボタ
ンであり、テンプ案件ＤＢＦの「見解有無」のフィールドが真値であった場合にのみ自動
生成するコマンドボタンである（以下、見解内容閲覧ボタン）。
見解内容閲覧５５ボタンには、コミュニケーションサーバ３に実装された見解情報統合
表示プログラムの起動コマンドが埋め込まれている。コミュニケーションサーバ３の記憶
部には、見解情報統合表示フォームのファイルが記憶されている。

図２６は、見解情報統合表示フォームの一例を示した概略図である。図２５に示す見解
内容閲覧ボタン５５には案件ＩＤが埋め込まれており、案件ＩＤを見解情報統合表示プロ
グラムに引数として渡すようになっている。見解情報統合表示プログラムは、案件ＩＤに
従ってテンプ送信先ＤＢＦを開き、各レコードの情報を読み出して見解情報統合表示フォ
ームに嵌め込むようプログラミングされている。この際、「見解情報」のフィールドがＮ
ｕｌｌ値ではないレコードについては、その「見解情報」のフィールドの値（テキスト情
報）をメモリ変数にいったん格納し、見解情報統合表示フォームには、図２６に示すよう
に「詳細」と表記されたコマンドボタン（以下、詳細ボタン）５６を自動生成する。

図２７は、図２６において詳細ボタン５６がクリックされた状態の一例を示す概略図で
ある。詳細ボタン５６には、メモリ変数に格納しておいた見解情報を別フォームで表示す
るプログラムが埋め込まれており、詳細ボタン５６をクリックすることで、図２７に示す
ように見解情報の内容を閲覧することができる。
図２６及び図２７から解るように、本実施形態によれば、見解情報を寄せている指導的
専門医の情報がリスト表示され、リストの各行の詳細ボタン５６をクリックすることでそ
の指導的専門医が寄せた見解情報やプロフィール等を閲覧することができる。このため、
どのような指導的専門医がどのような見解情報を寄せたかを比べながら閲覧することがで
きる。

次に、リアルタイムコミュニケーション手段について説明する。本実施形態の支援シス
テムは、初期疾病情報が送られた際、送り先の各二次端末２と送り元の一次端末１とをグ
ループ化してリアルタイムコミュニケーション（以下、ＲＴＣ）させるリアルタイムコミ
ュニケーション手段（以下、ＲＴＣ手段）が設けられている。
ＲＴＣ手段は、一つの案件について問い合わせ情報を送信した一次端末１と、対応可情
報を送信してきたすべての二次端末２とをグループ化し、ＲＴＣを行わせる手段である。
本実施形態では、ＲＴＣ手段は、初期疾病情報の送信後、いずれかの二次端末２から見解
情報が送られた際にＲＴＣを行うことを選択できるようになっている。

図１９に示すように、見解情報メールには、「ＲＴＣを行う」と表記されたコマンドボ
タン（以下、ＲＴＣボタン）４６が含まれている。コミュニケーションサーバ３には、初
期ＲＴＣプログラムが実装されており、ＲＴＣボタン４６は、初期ＲＴＣプログラムの起
動コマンドが埋め込まれている。図２６に示す見解情報統合表示フォームにも同様のコマ
ンドボタン５７が設けられている。
初期ＲＴＣプログラムは、まず、ＲＴＣの管理用の一時的なデータベースファイル（以
下、テンプＲＴＣ−ＤＢＦ）を作成する。テンプＲＴＣ−ＤＢＦは、例えば10-a1111-rtc
.dbfのように、案件ＩＤを使用して決められたやり方でファイル名を定める。次に、初期
ＲＴＣプログラムは、セッション変数から案件ＩＤを読み出し、テンプ送信先ＤＢＦを開
く。そして、テンプ送信先ＤＢＦで「可否情報」のフィールドが真値であるレコードの「
専門医ＩＤ」、「専門医名称」、「端末アドレス」、「端末識別情報」等を読み出し、テ
ンプＲＴＣ−ＤＢＦに記録していく（レコードをコピーしていく）。すべてのレコードを
コピーした後、その案件ＩＤにおける一次端末１の情報（端末アドレス及び端末識別情報
）を新たなレコードを追加して記録する。この結果、その案件について対応可の回答を寄
せている各指導的専門医の二次端末２と、その案件の担当医の一次端末１とがグループ化
された結果となる。

次に、初期ＲＴＣプログラムは、コミュニケーションサーバ３の記憶部に記憶されてい
るＲＴＣ用メールフォームを読み出し、見解情報メール中の見解情報（テキスト）を貼り
付けて自動転送メールを作成し、テンプＲＴＣ−ＤＢＦに従って、その見解情報メールの
送信元の端末アドレス以外のグループ内のすべての端末にその見解情報メールを自動転送
する。尚、図２６に示すＲＴＣボタン５７については、いずれかの見解情報を指定し（リ
ストのいずれかの行を指定し）、その上でＲＴＣボタン５７がクリックされるようにし、
指定された見解情報を他のすべての二次端末２に送信してＲＴＣを開始するようプログラ
ミングされる。

図２８は、リアルタイムコミュニケーション手段により自動転送された見解情報メール
の一例（以下、ＲＴＣ転送メール）を示す概略図である。図２８に示すように、ＲＴＣ転
送メールでは、メールがシステムにより全メンバーに自動転送されたものであることや、
見解等があれば入力して送って欲しい旨のメッセージが嵌め込まれている。本実施形態で
は、過去の発言に追記した形でメッセージを配信するようになっており、この例では、三
つ目の発言があった状態である。
図２８に示すように、ＲＴＣ転送メールには、「発言する」と表記されたコマンドボタ
ン（以下、発言ボタン）４７が設けられている。発言ボタン４７には、返信メッセージ入
力欄と送信ボタンとを有する発言フォームのリンクが貼られており、そこでの送信ボタン
には、コミュニケーションサーバ３に実装されているＲＴＣ自動転送プログラムの起動コ
マンドが埋め込まれている。ＲＴＣ自動転送プログラムは、それまでに送信されたメッセ
ージに、入力された返信メッセージを追加してメール文を生成し、同様にＲＴＣ用メール
フォームに貼り付けて自動転送メールを作成する。そして、同様に、送信元の二次端末２
以外のグループ内の全端末１，２に自動転送メールを送信する。
尚、上記のような自動転送メールは担当医の端末（一次端末１）に送信される。したが
って、担当医自身が返信をする場合がある。この場合は、グループ内のすべての二次端末
２に自動転送メールが送られることになる。

次に、経過情報送信手段について説明する。
本実施形態の支援システムは、経過情報を各二次端末２に送信する経過情報送信手段を
備えている。経過情報とは、初期疾病情報を送信した後の救急患者の状態に関する情報又
は追加検査、診断若しくは治療の情報を意味している。
経過情報送信手段は、一次端末１と、コミュニケーションサーバ３と、コミュニケーシ
ョンサーバ３に実装された幾つかのプログラムによって構成されている。経過情報送信用
のコミュニケーションサーバ３上のプログラムとしては、経過情報の入力、経過情報表示
フォームの加工及び各二次端末２へのアラームメールの配信までの行うプログラム（以下
、経過情報送信用第一プログラム）と、各二次端末２からのアクセスに応じて経過情報表
示フォームを送信するプログラム（以下、経過情報送信用第二プログラム）が実装されて
いる。

上記のように問い合わせ情報を送信して見解情報を受信した後も、患者の容態は刻々と
変化し得るし、その後に必要な検査や投薬等の処置が行われることも多い。したがって、
このようなその後の経過情報を指導的専門医に送るべき場合がある。例えば、その後の状
況によっては経過情報を送ってさらなる見解情報を求めた方が良い場合もある。経過情報
送信手段は、このような点を考慮したものである。
経過情報送信については、初期疾病情報の送信の際の追加所見の送信のように、一次端
末１においてテキスト情報を入力し、コミュニケーションサーバ３を経由して各二次端末
２に送信するようにしても良いのであるが、本実施形態では、救急患者の治療支援である
ことを考慮し、特別の構成を採用している。即ち、経過情報に時間情報を含めるようにし
、且つ時間軸を示す直線であるタイムバーとともに経過情報が表示されるよう送信する構
成が採用されている。

図６に示すメニューフォームには、「経過情報送信」と表記されたコマンドボタン（以
下、経過情報送信ボタン）５８が設けられている。コミュニケーションサーバ３の記憶部
には、経過情報の種類を選ぶフォーム（情報ジャンル選択フォーム）のファイルが記憶さ
れており、経過情報送信ボタン５８をクリックすると、このフォームが一次端末１に表示
されるようになっている。
詳細な説明は省略するが、情報ジャンル選択フォームでは、画像データ（撮影機器の出
力データ）を経過情報として選択するコマンドボタン（以下、画像選択ボタン）や、血圧
や心拍数、体温などのような患者の容態に関する数値データを経過情報として選択するコ
マンドボタン（以下、数値選択ボタン）や、投薬情報を経過情報として選択するコマンド
ボタン（以下、投薬選択ボタン）が設けられている。

画像選択ボタンがクリックされると、前述したのと同様にＰＡＣＳサーバ６にアクセス
がされ、その後の撮影された画像を取り込んで経過情報表示フォームの所定の位置に嵌め
込むよう経過情報送信用第一プログラムがプログラミングされている。この際、その画像
の撮像日時も併せてＰＡＣＳサーバ６から取得され、経過情報表示フォームに嵌め込まれ
る。
数値選択ボタンがクリックされると、イントラネット１０上に接続されている検査機器
（血圧計等）からデータを直接取り込んだり、または一次端末１上で入力したりすること
ができるように経過情報送信用第一プログラムがプログラミングされ、且つ、それらを経
過情報フォームの所定の位置に嵌め込むようプログラミングされる。この際、そのような
数値検査データの採取日時も併せて取得され、経過情報表示フォームの所定の位置に嵌め
込まれる。
また、投薬選択ボタンがクリックされると、投与した薬の名前、投薬量、投薬の日時が
入力されるよう経過情報送信用第一プログラムがプログラミングされ、且つ、入力された
情報が経過情報表示フォームの所定の位置に嵌め込まれるようプログラミングされる。

経過情報の各二次端末２への送信（配信）は、コミュニケーションサーバ３から各二次
端末２にメールを送り、そのメール中にコミュニケーションサーバ３上の経過情報送信プ
ログラムの起動コマンドを埋め込むことで行われる。このメールは、経過情報のコミュニ
ケーションサーバ３へのアップロードが行われた旨を知らせてダウンロードを促すメール
であり、以下、経過情報アラームメールと呼ぶ。
コミュニケーションサーバ３の記憶部には、経過情報を表示するフォーム（以下、経過
情報表示フォーム）が記憶されている。経過情報送信用第一プログラムは、入力された経
過情報を経過情報表示フォームに組み込み、コミュニケーションサーバ３の記憶部に記憶
して保存する。そして、経過情報送信用第二プログラムの実行のために経過情報アラーム
メールを送信すると、経過情報送信用第一プログラムが終了である。

図２９は、二次端末２に送信された経過情報アラームメールの一例を示した概略図であ
る。図２９に示すように、経過情報アラームメールは、支援システムから経過情報がアッ
プロードされた旨を知らせるメールであり、「表示」と表記されたコマンドボタン（表示
ボタン）４８が設けられている。表示ボタン４８には、コミュニケーションサーバ３上の
経過情報送信用第二プログラムの起動コマンドが埋め込まれている。経過情報送信用第二
プログラムは、コミュニケーションサーバ３の記憶部に記憶された加工後の経過情報表示
フォームを読み出し、アクセスしてきた二次端末２に送信して表示するようプログラミン
グされている。

図３０は、二次端末２に送信された経過情報表示フォームの一例を示した概略図である
。図３０に示すように、経過情報表示フォームは、時間軸を示す直線であるタイムバー４
９を含んでいる。この例では、タイムバー４９は横長のものとなっている。この例では、
二次端末２はスマートフォンになっており、画面を横にして見ることが想定されている。
図３０に示すように、経過情報は、タイムバー４９に対して吹き出し形式で表示される
ようになっている。即ち、経過情報を内側に表示した吹き出し枠５０が形成されるように
なっている。吹き出し枠５０の位置は、タイムバー４９が示す時間経過において当該経過
情報に含まれる時刻に対応したものとなっている。即ち、図３０に示すように、例えばタ
イムバー４９の開始時刻が2010/07/20 18:30（２０１０年７月２０日１８時３０分）とし
、３０分毎に時間経過を表示する目盛りが表示されるものとする。この場合、経過情報が
投薬情報であり、この投薬情報に含まれる時刻情報（投薬時刻）が同日の１９時３５分で
あるとすると、１９時３５分の位置からの吹き出し枠５０内に経過情報（投薬情報）が表
示されるようになっている。

図３０に示す経過情報表示フォームにおいて、タイムバー４９の位置や長さは予め固定
されており、フォーム内の一定の位置に表示されるようになっている。経過情報の入力の
際には、タイムバー４９のスケール（何時間毎の目盛り表示か）を指定する入力欄が一次
端末１に表示されるようようになっている。ここでスケールを指定すると、指定されたス
ケールで目盛り表示がされるよう経過情報送信用第一プログラムがプログラミングされて
いる。そして、経過情報送信用第一プログラムは、入力された経過情報からそこに含まれ
る時刻情報を取り出すステップと、指定されたスケールに応じてタイムバー４９上の吹き
出し枠５０の位置を算出するステップと、経過情報を嵌め込んだ吹き出し枠５０を算出さ
れた位置に組み込むステップとを有している。
尚、一度加工した経過情報表示フォームは、案件ＩＤ等を利用したファイル名でコミュ
ニケーションサーバ３の記憶部に保存されるようになっている。二回目以降に経過情報を
送信する際には、保存された経過情報表示フォームを読み出し、経過情報を追記するよう
に嵌め込んでファイルを更新する。そして、更新された経過情報表示フォームが二次端末
２に送信されるようになっている。

次に、履歴情報の記録について説明する。
本実施形態の支援システムは、システムの利用履歴を記録するため、記録手段と記録サ
ーバ５とを有している。記録手段は、記録サーバ５と、記録サーバ５の記憶部に記憶され
た履歴情報データベースファイル（以下、履歴情報ＤＢＦ）等から構成されている。
図６に示すように、メニューフォームには、「管理終了入力」と表記されたコマンドボ
タン（以下、管理終了ボタン）５９が設けられている。一方、コミュニケーションサーバ
３には、コミュニケーションサーバ３上の管理を終了して履歴を記録サーバ５に残す管理
終了プログラムが実装されている。管理終了ボタン５９をクリックすると、勤務医ＩＤと
パスワードを入力するフォームが表示され、それらが正しく入力されると、管理終了のた
めの確認フォーム（管理終了確認フォーム）が一次端末１に表示されるようになっている
。

管理終了プログラムは、入力された勤務医ＩＤに従ってテンプ案件ＤＢＦを開き、勤務
医ＩＤが一致するレコードをリスト表示するようになっている。この部分は、図２０等と
ほぼ同様である。リスト（通常はリストは一行であるが、複数の案件を抱えている場合は
複数行になる）の末尾には、「終了」と表記されたコマンドボタンが自動生成されるよう
になっており、このコマンドボタンは、案件ＩＤを引数にして管理終了プログラムを起動
するものとなっている。
管理終了プログラムは、案件ＩＤを検索キーにしてテンプ案件ＤＢＦを検索し、該当レ
コードの切り取りを行う。即ち、全フィールドの情報をそれぞれメモリ変数に格納した後
、該当レコードを削除する。そして、履歴情報ＤＢＦに新たなレコードを追加し、格納し
た情報を記録する。履歴情報ＤＢＦのファイル構造は、テンプ案件ＤＢＦと全く同じもの
とされる。
次に、管理終了プログラムは、案件ＩＤに従ってその案件のテンプ送信先ＤＢＦの切り
取りを行う。即ち、テンプ送信先ＤＢＦをメモリ変数に格納した後、コミュニケーション
サーバ３の記憶部からそのテンプ送信先ＤＢＦを削除する。次に、格納したテンプ送信先
ＤＢＦを記録サーバ５の記憶部に記憶して保存する。これで、管理終了プログラムは終了
である。記録サーバ５の記録部のファイルは永久的に又は所定の長い期間保存されるもの
であり、システムの利用履歴情報の保存場所として意義を有する。

上記構成に係る本実施形態の支援システムにおいて、見解情報は、それを送信する指導
的専門医のデジタル署名とともに送信されることが望ましい。デジタル署名付きのメール
送信は、パソコンやノートパソコン用のメーラでは殆どの場合、標準の機能として有する
。したがって、二次端末２がパソコンやノートパソコンである場合はそれを利用する。指
導的専門医に対してはデジタル署名付きの送信で見解情報を送信してもらうよう要請して
おく。
二次端末２が携帯電話等の携帯端末である場合、デジタル署名付きのメールが送れるも
のは現状では少ない。そこで、本実施形態のシステムは、指導的専門医に対して後からデ
ジタル署名付きのメールを再送信してもらうよう要請する技術的工夫をしている。

具体的に説明すると、図２７に示すように、見解情報を表示するフォームには、「デジ
タル署名依頼」と表記されたコマンドボタン（以下、署名依頼ボタン）６１が設けられて
いる。一方、コミュニケーションサーバ３の記憶部には、デジタル署名を依頼するメール
フォーム（以下、署名依頼フォーム）のファイルが保存されており、署名依頼ボタン６１
がクリックされると、署名依頼フォームが一次端末１上に表示されるようになっている。
署名依頼ボタン６１には、専門医ＩＤを検索キーにしてテンプ送信先ＤＢＦを検索し、該
当するレコードの「見解情報」のフィールドの値（テキスト）を取得した後、署名依頼フ
ォームに嵌め込むプログラムが埋め込まれている。
一方、指導的専門医ＤＢＦには、デジタル署名を付してメール送信することが可能なメ
ールアドレス（通常はパソコン又はノートパソコンにおけるメールアドレス）が登録され
ている。署名依頼ボタン６１に埋め込まれたプログラムは、専門医ＩＤを検索キーにして
指導的専門医ＤＢＦを検索し、このメールアドレスの情報を取得する。

署名依頼フォームには、送信ボタンが設けられており、この送信ボタンには、取得した
メールアドレスの情報が埋め込まれる。そして、署名依頼フォームには、確認のため表示
した見解情報についてデジタル署名を付して再送信して欲しい旨のメッセージが表示され
るようになっている。送信ボタンのクリックにより、署名依頼フォームは、署名可能な二
次端末２のメールアドレスに送信され、指導的専門医は、デジタル署名を付して返信する
ことになる。
尚、コミュニケーションサーバ３には、二次端末２からメール（見解情報のメールや上
記返信メール）が送信された際、ヘッダ情報からデジタル署名が付されているかどうか判
断し、デジタル署名が付されている場合、デジタル署名情報を取り出して保存するプログ
ラムがインストールされている。デジタル署名情報の保存は、例えばテンプ送信先ＤＢＦ
に「デジタル署名情報」のフィールドを設けてそこに記録して保存したり、別途専用のデ
ータベースファイルを設けて保存したりすることができる。そして、このように保存した
デジタル署名情報は、見解情報と同様、記録サーバ５の履歴情報ファイルに記録されて保
存される。

次に、アラーム手段について説明する。
本実施形態の支援システムおいて、各二次端末２は、コミュニケーションサーバ３から
初期疾病情報が送信された際、アラームを発するアラーム手段を備えている。アラームは
、初期疾病情報が送信された旨を指導的専門医に知らせ、見解情報を送信を促すためのも
のである。見解情報は、救急患者の治療のために送信してもらうものであり、緊急性を有
する。初期疾病情報が届いていてもそれに気がつかないと、適切なタイミングで見解情報
が届かず、治療方針等の決定の際に参考にできないことになり得る。このような点を考慮
し、アラーム手段を設けている。本実施形態の支援システムでは、初期疾病情報の前段階
の情報である問い合わせ情報についても、それが送信されたことを知らせるアラーム手段
を設けている。具体的には、アラーム手段は、音、光、振動又はこれらの組み合わせから
成るアラームを発する手段である。
本実施形態の支援システムは、問い合わせ情報や初期疾病情報を電子メールの形で送信
するものとなっている。したがって、アラーム手段は、そのような電子メールが届いたこ
とを知らせる手段である。現在使用されている殆どのメーラは、このようなアラーム手段
を備えており、本実施形態ではメーラの機能がそのまま利用される。メーラのアラーム機
能が動作するよう、各指導的専門医に対して二次端末２の設定を依頼することになる。

問い合わせ情報や初期疾病情報が電子メールの形で送信されない場合、アラーム手段も
別のものに変更する必要がある。例えば、初期疾病情報が一次端末１からコミュニケーシ
ョンサーバ３に送信された後、二次端末２からコミュニケーションサーバ３に能動的にア
クセスさせて初期疾病情報を取得するような構成の場合、二次端末２に対してコミュニケ
ーションサーバ３にアクセスするよう促すアラーム手段が必要であるが、この構成として
は、各指導的専門医が保有する携帯電話に対していわゆるワン切り送信を行うことでアラ
ームとすることができる。即ち、この支援システム固有の電話番号から各携帯電話に対し
て１回ないし数回の短い着信音の電話番号発信を行うことでアラームをするできる。この
発信は、番号通知の設定としておき、各携帯電話において発信番号が本支援システムから
のものであることが解るようにしておくことが望ましい。支援システム側では、各指導的
専門医の携帯電話番号を指導的専門医ＤＢＦに登録しておき、コミュニケーションサーバ
３から順次ワン切り発信をするプログラムが実装される。

また、問い合わせ情報や初期疾病情報は、コミュニケーションサーバ３からのダウンロ
ードの形で送信される構成が採用されることもある。即ち、図２９に示すような簡単なテ
キストから成るメールをアラームの意味で送信しておき、そのメールにコミュニケーショ
ンサーバ３にアクセスするコマンドボタンを嵌め込んでおく。そのコマンドボタンをクリ
ックすると、問い合わせ情報や（画像のみならずテキストも含む）初期疾病情報がコミュ
ニケーションサーバ３からダウンロードされるよう構成しても良い。したがって、図２９
に示すようなアラームメールを送信する手段を、アラーム手段として捉えることもできる
。

上記構成に係る本実施形態の支援システムによれば、複数の指導的専門医に対して画像
を含む初期疾病情報が回答期限とともに送信され、各指導的専門医からは初期疾病情報を
踏まえての見解情報が返信されるので、担当医は、各見解情報を参照して診断をしたり治
療方針を決定したりすることができる。このため、担当医が単独で決定して治療を行う場
合に比べてより適切な治療を行える場合が多くなる。
また、本実施形態の支援システムでは、初期疾病情報の送信の前に問い合わせ情報を送
信し、対応可能と返信してきた指導的専門医にのみ初期疾病情報を送信して見解情報を求
めるので、対応できない指導的専門医に対して無駄に初期疾病情報を送ることが無くなる
。指導的専門医の側でも、対応できない案件についてむやみに初期疾病情報が送信される
ことがないので、煩雑さが生じない。また、初期疾病情報は患者の画像を含むので、対応
可能と回答してきた指導的専門医に対してのみ送信することは、個人情報保護の観点から
も望ましい。

また、本実施形態の支援システムは、指導的専門医の専門性レベルについて特定のレベ
ルの者のみを選び出して初期疾病情報を送ることができるので、疾病の特殊性、診断や治
療の難易性等に応じて最適なレベルを設定して見解情報の提供を要請することができる。
このため、より適切な見解情報を得ることにつながり、より適切な治療を行うことに貢献
できる。
また、本実施形態の支援システムは、リアルタイムコミュニケーション手段が設けられ
ているので、一つの救急疾病や一つの見解情報に対して多くの指導的専門医が見解を述べ
て討議することが可能となる。このため、多くの見解を積み重ねることでより適切な結論
に達することが可能となり、この点でさらに適切な治療を行えるようになる。
また、本実施形態の支援システムは、経過情報送信手段を備えているので、初期疾病情
報を送信した後の状況に応じてさらに見解情報を求めることも可能になり、この点で、さ
らに適切な治療が行えるようになる。この際、経過情報は、時間軸を示す直線であるタイ
ムバー上に時系列的に示されるので、時間経過の中でどのような状況であるかを指導的専
門医が容易に把握することができる。このため、「時間との戦い」である救急疾病の治療
において、より適切なタイミングでより適切な治療が行えるよう見解情報を提供すること
ができる。

また、本実施形態の支援システムは、画像再構築手段が設けられており、指導的専門医
の側で画像を自由に再構築して確認することができるので、より適切な見解情報を提供す
ることができる。
また、本実施形態の支援システムは、記録サーバ５の履歴情報ファイルに、初期疾病情
報を送信して見解情報を求めた旨、及び指導的専門医から寄せられた見解情報が記録され
て保存されるので、適切な取り扱いをした旨の証拠として後に利用することができる。即
ち、診断や治療方針の決定が適切であったかどうか等が後に問題となった場合（例えば医
療過誤を理由とする訴訟が提起された場合）、履歴情報ファイルの内容を根拠として適切
に各指導的専門医に見解情報を求め、寄せられた見解情報をもとに治療を行った旨を釈明
することができる。
このような釈明の際、本実施形態の支援システムでは、見解情報をデジタル署名付きで
受信することができ、デジタル署名とともに見解情報を履歴情報ファイルに保存するので
、見解情報の受信やその内容に対する信憑性（証拠価値）が高くでき、この点で好適なも
のとなっている。

上記実施形態の構成において、コミュニケーションサーバ３から送信される画像として
は、手術中の患部を撮影した動画である場合がある。例えば、経過情報として手術中の患
部を撮影した動画をリアルタイムで二次端末２に送信することもあり得る。この場合、動
画のリアルタイム送信については、いわゆるストリーミング配信の技術を利用することが
できるし、ＩＰ電話によるテレビ電話を利用して行うこともできる。よって、詳細な説明
は割愛する。尚、手術中の動画を配信しているフレームを嵌め込んだフォーム内に見解情
報を送信するためのボタンを設け、指導的専門医が動画を見ている際に気がついた点を見
解情報として送ってもらうようにすることも可能である。
尚、手術中の患部の動画は、初期疾病情報として送られる場合もある。即ち、問い合わ
せ情報として、これから手術に入るので手術中の画像を見た上で見解情報をもらえるかど
うかを問い合わせておき、可能であると返信してきた二次端末に手術中の動画を送って見
解情報を求めるような使い方も考えられる。

上述した本実施形態の構成において、経過情報の配信は、二次端末２だけではなく、院
内の各一次端末１に対しても行うようにすると好適である。例えば、救急患者の治療につ
いて複数の医師や看護士がチームとして対応している状況において、チームの各員が携帯
型の一次端末１を持ち歩くようにし、何らかの経過情報が発生したら、それを各員の一次
端末１に即座に配信するようにする。これによりチーム全員が経過情報をリアルタイムで
共有することができるようになり、より迅速により効果的に救急患者の診断や治療を進め
ることができるようになる。
上述した実施形態の説明では、脳梗塞やくも膜下出血のような脳血管系の救急患者を例
にしたが、本願発明は、他科の救急患者の治療支援についても同様に利用することができ
る。例えば、心筋梗塞や大動脈瘤のような循環器系の救急患者や、交通事故等による外傷
系の救急患者、さらには切迫早産や出産時の脳出血等の出産に関わる救急患者について、
本願発明を利用することができる。

１ 一次端末
２ 二次端末
３ コミュニケーションサーバ
４ データベースサーバ
５ 記録サーバ
６ ＰＡＣＳサーバ
７ 電子カルテサーバ
１０ イントラネット

Claims (12)

1. 特定の疾病について特別の専門的知識と経験を有する者として認められる者である複数の指導的専門医の情報をデータベース化して記録した指導的専門医データベースファイルを含むデータベースサーバと、
   指導的専門医データベースファイルに新たな指導的専門医の情報を記録して登録する登録手段と、
   救急患者が治療を受ける病院の担当者が操作する一次端末と、
   指導的専門医データベースファイルに情報が記録されている各指導的専門医によって操作される二次端末と、
   コミュニケーションサーバと、
   前記指導的専門医データベースファイルに記録された情報には、前記各二次端末のアドレス情報が含まれており、
   さらに、
   前記救急患者の患部を撮影した画像とその画像の撮影時刻との情報を含む情報である初期疾病情報を、前記一次端末から入力させ、前記指導的専門医データベースファイルに記録されたアドレス情報に従ってコミュニケーションサーバを介して前記各二次端末に送信する一次送信手段と、
   前記各二次端末に送信された前記初期疾病情報を前記各二次端末において受信して表示する受信表示手段と、
   表示された前記初期疾病情報を確認した各指導的専門医に、当該救急患者についての追加検査の必要性の情報、どのような疾病であるかの情報である診断情報又はどのように治療すべきかの情報である見解情報を各二次端末において各々入力させ、入力された見解情報を一次端末に送信する二次送信手段と、
   各二次端末から送信された見解情報を一次端末に表示する見解情報表示手段とを備えており、
   前記一次送信手段は、前記見解情報の送信期限とともに前記初期疾病情報を送信するものであり、
   前記初期疾病情報が送信された際、各指導的専門医に対し、音、光、振動又はこれらの組み合わせから成るアラームを発するアラーム手段が設けられていることを特徴とする救急患者治療支援システム。
2. 前記初期疾病情報を送信する前に、問い合わせ情報を前記一次端末から入力させてコミュニケーションサーバに送信する問い合わせ情報送信手段を備えており、
   問い合わせ情報は、当該救急患者の疾病についての症状を記述したテキストと、前記初期疾病情報を送信した場合の前記見解情報の送信期限の情報とを含んでおり、送信期限内に前記見解情報を送信することができるかどうかを問い合わせる情報であり、
   前記二次送信手段は、問い合わせ情報が送信された際、前記見解情報を送信することができるか否かの情報である可否情報を前記二次端末において入力させて前記一次端末に送信するものであり、
   前記一次送信手段は、問い合わせ情報に対して、前記見解情報を送信することができる旨の可否情報を送信した前記二次端末に対してのみ前記初期疾病情報を送信するものであることを特徴とする請求項１記載の救急患者治療支援システム。
3. 前記指導的専門医データベースファイルに登録された前記指導的専門医の情報には、各指導的専門医の専門性のレベルについての情報が含まれており、
   前記一次送信手段は、前記指導的専門医データベースファイルに情報が登録された指導的専門医のうち、特定のレベルの指導的専門医のみを選び出してその指導的専門医が操作する前記各二次端末にのみ前記初期疾病情報を送信することができるものであることを特徴とする請求項１又は２記載の救急患者治療支援システム。
4. 前記二次送信手段は、前記コミュニケーションサーバを介して前記見解情報を前記一次端末に送信するものであり、
   前記初期疾病情報が送られた際、当該初期疾病情報を送った前記各二次端末と前記一次端末とをグループ化してリアルタイムコミュニケーションさせるリアルタイムコミュニケーション手段が設けられており、
   リアルタイムコミュニケーション手段は、前記二次端末から前記見解情報が送られた際、当該見解情報を前記一次端末に送信するとともにグループの他の各二次端末にも送信するものであり、
   前記一次端末及び前記各二次端末は、送信された前記見解情報に対する返信情報を入力させて前記コミュニケーションサーバに送信することが可能であり、
   リアルタイムコミュニケーション手段は、返信情報が送信された際、送信元の一次端末又は二次端末以外のグループ内の各端末に返信情報を送信するものであり、
   前記一次端末及び前記各二次端末は、送信された前記返信情報に対する再返信情報を入力させて前記コミュニケーションサーバに送信することが可能であり、
   リアルタイムコミュニケーション手段は、再返信情報が送信された際、送信元の一次端末又は二次端末以外のグループ内の各端末に再返信情報を送信するものであることを特徴とする請求項１、２又は３記載の救急患者治療支援システム。
5. 前記初期疾病情報を送信した後の救急患者の状態に関する情報又は追加検査、診断若しくは治療の情報である経過情報を前記一次端末において入力させて前記コミュニケーションサーバを介して前記二次端末に送信する経過情報送信手段を備えており、
   前記受信表示手段は、送信された経過情報を各二次端末で受信して表示することが可能であることを特徴とする請求項１乃至４いずれかに記載の救急患者治療支援システム。
6. 前記経過情報には、当該救急患者の状態に関する情報がいつの時点での情報であるか、又は当該追加検査、診断若しくは治療の情報がいつの時点での情報であるかを示す時間情報が含まれており、
   前記経過情報送信手段は、前記二次端末において、時間軸を示す直線であるタイムバー上に時系列的に前記経過情報が表示されるよう前記経過情報を送信するものであることを特徴とする請求項５に記載の救急治療支援システム。
7. 前記初期疾病情報に含まれる前記画像は動画であり、
   前記一次送信手段は、前記画像を撮影機器が撮像している際、当該画像をリアルタイムで前記コミュニケーションサーバに送信するものであり、
   前記コミュニケーションサーバは、送信された画像をリアルタイムで前記各二次端末に送信するものであることを特徴とする請求項１乃至６いずれかに記載の救急患者治療支援システム。
8. 前記経過情報には動画が含まれており、前記経過情報送信手段は、当該画像を撮影機器が撮像している際、当該画像をリアルタイムで前記コミュニケーションサーバに送信するものであり、
   前記コミュニケーションサーバは、送信された画像をリアルタイムで前記各二次端末に送信するものであることを特徴とする請求項１乃至７いずれかに記載の救急患者治療支援システム。
9. 前記画像は、前記救急患者の手術の際に撮影している患部の動画であることを特徴とする請求項７又は８記載の救急患者治療支援システム。
10. 前記画像は、撮影機器で取得されたデータを処理して得られた画像であり、
    前記二次端末において表示される前記画像を再構築する画像再構築手段が設けられており、
    画像再構築手段は、画像再構築プログラムが実装された画像再構築サーバを備えており、
    前記受信表示手段は、前記画像を再構築する指令である画像再構築指令を前記二次端末において入力させて画像再構築サーバに送信することが可能となっており、
    画像再構築プログラムは、画像再構築指令が送信された画像のデータを再処理して再構築した画像を生成して前記二次端末に送信し、前記受信表示手段により前記二次端末に表示するものであることを特徴とする請求項１乃至９いずれかに記載の救急治療支援システム。
11. 記録手段及び記録サーバが設けられており、
    記録サーバの記憶部には、各救急患者についての治療履歴情報をデータベース化して記録した履歴情報ファイルが設けられており、
    記録手段は、各救急患者について、前記一次送信手段が前記各二次端末に初期疾病情報を送信した旨の情報を履歴情報ファイルに記録するとともに、前記各二次端末から前記見解情報が送信された旨と当該見解情報の内容とを履歴情報ファイルに記録するものであることを特徴とする請求項１乃至１０いずれかに記載の救急患者治療支援システム。
12. 前記二次送信手段は、前記見解情報を入力する前記指導的専門医のデジタル署名を前記見解情報とともに前記一次端末に送信するものであり、
    前記記録手段は、前記見解情報とともにその見解情報を入力した前記指導的専門医のデジタル署名を前記履歴情報ファイルに記録するものであることを特徴とする請求項１１記載の救急患者治療支援システム。

Images