JP2013190875A - 発熱患者の分布計測システム、並びにサーバ装置及びその制御方法 - Google Patents

Abstract

【課題】 発熱症状を有する患者の分布を地図上に視覚的に示すことで、今後の流行の地理的な方向についても推察可能な情報を提供し得る技術を提供する。
【解決手段】 サーバ装置は、前記各端末の地理的位置を記憶している。そして、サーバ装置は、各端末から、診察した患者の体温データと発熱患者数を表わす情報を含む電子メールを受信する。それらを受信した電子メールの発信元から、地理的位置に応じた発熱患者分布を求め、地図画像に合成してＷｅｂページとして配信する。
【選択図】 図５

Description

本発明は発熱者の体温に基づく発熱患者の分布計測システムに関するものである。

本願出願人は、既に気象の影響による循環器疾患発症の予報する技術を提案した（特許文献１）。脳卒中、心筋梗塞等の循環器疾患の発症と、気温、湿度、気圧との間には或る程度の因果関係があるためである。

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

しかし、上記特許文献１に係る技術では、風邪、インフルエンザ等の発熱を症状の１つとする感染症の地理的分布や今後の流行について情報を得るものではない。

本発明は発熱症状を有する患者の分布を地図上に視覚的に示すことで、今後の流行の地理的な方向についても推察可能な情報を提供し得る技術を提供しようとするものである。

かかる課題を解決するため例えば本発明の発熱患者の分布計測システムは以下の構成を有する。すなわち、
端末と、当該端末とネットワークを介して接続され、少なくともＷｅｂサーバとして機能するサーバ装置とで構成される発熱患者の分布計測システムであって、
前記端末は、
前記ネットワークを介して、発信元を特定する情報と、体温と測定した発熱患者数を示す情報を含む体温測定情報を前記サーバに送信する送信手段を有し、
前記サーバ装置は、
前記地理的位置に対応する複数の記憶領域を有する第１の記憶手段と、
端末を特定する情報と当該端末の前記地理的位置とを対応付けて記憶する第２の記憶手段と、
前記ネットワークインタフェースを介して、前記端末から送信されてきた前記体温測定情報を受信する受信手段と、
該受信手段で受信した前記体温測定情報に含まれる前記端末を特定する情報をキーにして、前記第２の記憶手段を検索することで、前記体温測定情報の送信元の前記端末の前記地理的位置を判定する判定手段と、
該判定手段で判定した前記地理的位置に対応する１つの記憶領域を、前記第１の記憶手段における前記複数の記憶領域の中から特定する特定手段と、
該特定手段で特定された記憶領域に、前記体温測定情報に含まれる体温と測定した発熱患者数を示す情報を格納する格納手段と、
前記第１の記憶手段の各記憶領域に格納された体温と患者数を表わすグラフィカルシンボルを、予め用意された地図画像上の該当する前記地理的位置に配置した画像を含む、Ｗｅｂブラウザで閲覧可能なページを生成する生成手段と、を有する。

本発明によれば、発熱症状を有する患者の分布を地図上に視覚的に示すことで、今後の流行の地理的な方向についても推察可能な情報を提供し得ることが可能になる。

実施形態における発熱患者の分布計測システムの構成概念図である。 実施形態におけるサーバの構成図である。 実施形態における医療機関ＤＢのデータ構造を示す図である。 実施形態における体温ＤＢのデータ構造を示す図である。 実施形態におけるサーバにアクセスした端末の表示画面の例を示す図である。 実施形態におけるサーバにアクセスした端末の表示画面の他の例を示す図である。 実施形態におけるサーバのメール受信時の処理内容を示すフローチャートである。 実施形態におけるサーバのＷｅｂサーバとして機能する場合の処理手順を示すフローチャートである。

以下、添付図面に従って本発明に係る実施形態を詳細に説明する。尚、以下に述べる実施の形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。

図１は実施形態における体温分布計測システムの概念図である。本システムは、サーバ１００、各医療機関２００、２１０に設置された端末２０１、２１１、並びに、一般ユーザである一般家庭２５０に設置された端末２５１（携帯端末でも構わない）、更には、これらを接続するネットワーク（実施形態インターネットとする）３００で構成される。なお、図示では、２つの医療機関の端末、１つの一般家庭を示しているが、勿論、これら多数存在するものである。図示はあくまで便宜的なものである点に注意されたい。

＜システム概要の説明＞
本実施形態におけるシステムでは、各医療機関及び／またはユーザの端末から、その日一日に診察した外来患者の診察の際に測定した体温データや一般家庭で測定した体温データを、例えば所定時刻（例えば１７：００）になった時にネットワーク３００を通じてサーバ１００に送信（通知）する。送信する手段としては、如何なるものでも構わない。ここで、医療機関とは、病院，診療所，開業医等である。

一例としては、サーバ１００にデータエントリーのホームページを用意し、各医療機関の端末２０１、２１１はそのホームページ上で体温データを入力することでサーバに通知することが考えられる。この場合、データエントリーのためのホームページにアクセスする以前に認証処理を行うことが望ましい。サーバ１００は、認証に成功したとき、その際の認証手続で、どの医療機関からのアクセスであるかを判定でき、受信した体温データと医療機関とを関連づけが行えるからである。また、一般ユーザである一般家庭２５０に設置された端末２５１でもそのホームページ上で体温データを入力することでサーバに通知することが考えられる。この場合、データエントリーのためのホームページにアクセスする以前に認証処理を行うことが望ましい。

通信を行なうための所定のプロトコルの例としては、電子メール（ＳＭＴＰプロトコル：以下、単にメールという），ＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル），ＦＴＰ（ファイル・トランスファー・プロトコル）等にて体温データをサーバ１００に送信することである。電子メールの場合、メールの記述であるが、単純に、その日に診察した各患者の体温値を、カンマ区切りにしてサーバ１００に送信するものとする。サーバは、受信したメールの発信元アドレスから、発信元の医療機関を特定できる。また、受信したメール本文から、体温データが幾つ有るかを計数することで、発熱患者数を判定することもできる。メールによる送信の場合、医療機関の操作者の操作は更に簡便なものとすることができる。

以下の実施形態では、医療機関の端末２０１、２１１からサーバ１００への患者数を含む体温データ（発熱患者数を含む）の通知はメールにて行うものとして説明する。

サーバ１００は多数の医療機関から、上記のようにして、診察した発熱患者の体温データを受信すると、各医療機関の位置毎に体温データを集計し、不特定多数のユーザに、医療機関の位置の近隣に、該当する発熱患者が居住しているものと見なし、その体温の分布を表わす地図をホームページ上に公開する。

図５は一般ユーザ（図１の端末２５１のユーザ）に対して公開するホームページの一部を示している。図示の５００が端末２５１が起動したブラウザ内に表示される体温分布ウインドウを示している。この体温分布ウインドウ５００は、地図表示領域５０１、この地図表示領域５０１内に表示される地域の位置を変更するためのスクロールバー５０２、５０３、並びに、地図の縮尺を変更するためのツマミ（以下、縮尺変更ツマミ）５１０、表示する体温の閾値を変更するためのツマミ（体温閾値変更ツマミ）５１１、表示する日付を変更する日付変更ツマミ５１２で構成される。地図表示領域５０１を除く、スクロールバー５０２、５０３、縮尺変更ツマミ５１０、体温閾値変更ツマミ５１１、日付変更ツマミ５１２は、いずれも端末２５１が有するマウスやタッチパネル等のポインティングデバイスで操作するためのものである。

上記において、体温閾値変更ツマミ５１１は表示すべき体温値の下限を指定するものであり、デフォルトでは３７．０°である。すなわち、デフォルトでの表示すべき体温分布は３７．０℃以上の患者の分布となる。ユーザが、体温閾値変更ツマミ５１１を操作して、仮に、３８．０℃に設定した場合、３８．０以上の体温の発熱患者の分布を表示することになる。また、日付変更ツマミ５１２は、デフォルトでは昨日（図示では２月１６日）を表わしており、日付変更ツマミ５１２を変更することで、過去の希望とする日付の体温閾値以上の患者の分布を表示することが可能になる。なお、実施形態では、最大で１週間前の日付まで遡れる例を示しているが、記憶容量が許すかぎり遡れる期間を更に大きくしても構わない。

さて、スクロールバー５０２、５０３、並びに、縮尺変更ツマミ５１０のそれぞれの位置から、地図表示領域５０１に表示する地位域範囲が決定できる。そして、体温閾値変更ツマミ５１１、日付変更ツマミ５１２の位置により、表示すべき体温分布の日付と、体温の下限が決定できることは理解できよう。

本実施形態におけるサーバ１００は、これらの表に係るパラメータに従い、表示する地図上の各地域毎に、体温閾値以上の体温値の発熱患者数を集計し、各地域を中心とし、集計した数に応じた大きさの円を地図上に合成して表示する。図示の符号５５０がその集計結果を示す円である。

地図の縮尺が小さい（縮尺変更ツマミ５１０を図示の下方向に近づける＝縮尺の分母が大きい）ほど、地図表示領域５０１には、より広範囲の地域が表示される。つまり、１つの円が表わす現実の地域のサイズは、より広範囲の発熱患者数を表わすようにしなければならない。従って、地図の縮尺を小さくするのは、おおざっぱな体温の分布を把握するのに適した操作と言うことができる。

一方、地図の縮尺が大きい（縮尺変更ツマミ５１０を図示の上方向に近づける）ほど、１つの円が表わす実際の地域は狭くなる。つまり、地図の縮尺が大きくするのは、更に細かい地域単位での発熱患者数の分布を把握するのに適した操作と言うことができる。図６は、図５の状態で、縮尺変更ツマミ５１０を上方向に移動させ、地図の縮尺が大きくした例を示している。図５と比べると、１つの円が示す地域の範囲が、狭くなり、より細かい地域毎の患者分布を知ることができる。

また、図５、図６からもわかるように、日付変更ツマミ５１２を過去から現在に向かう順に、順位に移動させると、閾値以上の体温の発熱患者数の変化から、その流行の方向がある程度は把握できる。特に、学校関係者にとっては事前に予防措置を取ることに役立てることもできよう。また、医療関係者にとっては、来院する発熱患者数が増えるのかどうかの予測にも利用でき、薬の仕入れや勤務シフトをも考慮に入れ得た計画に役立てることもできる。

以上、実施形態における体温分布計測システムにおける概要を説明した。次に、上記を実現するための、実施形態におけるサーバ１００の具体的な構成と処理内容を説明する。

実施形態におけるサーバ１００のブロック構成図を図２に示す。同図に示すように、サーバ１００は、装置全体の判断・制御を司るＣＰＵ１０１、ＢＩＯＳ及びブートプログラムを格納しているＲＯＭ１０２、ＣＰＵ１０１のワークエリアとして使用したり、ＯＳ（オペレーティングシステム）並びに後述するサーバアプリケーションをロードするためのＲＡＭ１０３を有する。また、ネットワーク３００に接続するためのネットワークＩ／Ｆ１０４、ＯＳや各種データやアプリケーションを記憶する外部記憶装置としてのハードディスク装置（ＨＤＤ）１０５を有する。このＨＤＤ１０５には、メールの発信元の医療機関を識別するため、並びに、その医療機関の地理的位置の情報として、座標位置（経度、緯度）を記憶する医療機関データベース（以降、医療機関ＤＢ）１０６ａ、地図表示領域５０１に表示すべき地図を、縮尺に応じて切り出し可能な地図ＤＢ１０６ｂ、体温ＤＢ１０６ｃが予め確保されている。また、ＨＤＤ１０５には、ユーザ端末にて、先に示した図５、図６の表示を実現するためのＨＴＭＬ文書を作成するためのサーバプログラム１０７が格納されている。なお、サーバ１００の機能は、それ上で動作するＯＳやサーバプログラムに依存するものであって、ハードウェア構成は一般的なパーソナルコンピュータでも構わない。一般のユーザの端末２５１についてのデータベースも、上述のデータベースと同様の構造、即ち、座標位置（経度、緯度）を記憶する端末ＤＢ（データベース），地図表示領域５０１に表示すべき地図を、縮尺に応じて切り出し可能な地図データベース（ＤＢ）、体温データベース（ＤＢ）としている。

さて、本装置に電源が投入されると、ＣＰＵ１０１はＲＯＭ１０２に格納されたブートプログラムに従って、ＨＤＤ１０５をアクセスし、ＯＳをＲＡＭ１０３上にロードする。そして、サーバプログラム１０７を同様にＲＡＭにロードし、実行することで、本装置が体温分布計測システムのサーバ１００として機能することになる。

地図ＤＢ１０６ｂは、中心位置の緯度、経度と、縮尺値、並びに、表示するウインドウのサイズを指定することで、表示される領域の地図の画像が得られれば良く、カーナビゲーションに利用されている技術でもあるので、ここでの説明は省略する。従って、以下では先ず医療機関ＤＢ１０６ａを説明し、その後で体温ＤＢ１０６ｃについて説明する。

図３は、医療機関ＤＢ１０６ａの具体的な構造を示している。一般家庭２５０のユーザの端末２５１についてのデータベースも、医療機関ＤＢ１０６ａと同様の構造としている。ＤＢの図示の通り、医療機関ＤＢ１０６は、第１フィールドには医療機関のメールアドレス、第２フィールドにはその医療機関の経度、緯度（実施形態では、日本をターゲットにしているので、東経（Ｅ）、北緯（Ｎ）となる）。先に説明したように、実施形態における発熱患者の居住場所は、メール送信元の医療機関の近隣としている。勿論、遠くまで自動車で診察に向かう等もあり得るが、本発明は地域別の大まかな患者分布を計測することを目的としているので、そこまでの精度はもともと要求もしていない。従って、本発明者は、診察を受けた患者は概ねその医療機関から半径で数ｋｍの範囲内に居住していると見なして構わないと判断した。実施形態では、この距離を約２ｋｍとした例を説明する。緯度１秒が約３０ｍ弱であるから、医療機関の緯度、経度の精度は「分」単位の精度で良いことになる（１分≒６０×３０≒１８００ｍ＝約２ｋｍ）。

サーバ１００は、ネットワークＩ／Ｆ１０４を介して、各医療機関から体温データを受信すると、その発信元のメールアドレスと一致するメールアドレスを、医療機関ＤＢ１０６ａの第１フィールドから検索し、該当する医療機関の地理的位置の座標(緯度、経度)を得ることができる。

次に、実施形態における、体温ＤＢ１０６ｃについて説明する。先に説明したように、発熱患者の居住位置は正確に知る必要はないし、実施形態では医療機関の近隣（半径２ｋｍ）に居住していると見なして発熱患者分布を計測している。従って、図５の地図表示領域に表示する地図の精度も、最大縮尺（図５の縮尺変更ツマミ５１０をもっとも上）にした場合の、患者分布の分解能が２ｋｍより小さくなっても意味はない。また、居住区域の円で管理すると演算が面倒でもあるので、本実施形態では、東西４ｋｍ、南北４ｋｍの矩形範囲を体温分布の最少単位とした。

当然のことながら、この「東西４ｋｍ、南北４ｋｍ」の矩形範囲内には、地域によっては複数の医療機関が存在することもあり得るし、１つも存在しない場合も有り得る。本実施形態では、この「東西４ｋｍ、南北４ｋｍ」内に現実に医療機関が幾つ存在していたとしても、その「東西４ｋｍ、南北４ｋｍ」の区域には、あたかも仮想的な医療機関が１つだけ存在するものと見なし、体温データを記憶管理するものとした。以下に本実施形態における体温ＤＢ１０６ｃの構造とその原理を説明する。

図４は実施形態における体温ＤＢ１０６ｃの概念図である。体温ＤＢ１０６は、３次元データベースであって、その１つの次元が時間（日付）である。そして、残りの２次元で地理の２次元座標を表わす。図示の１つのマス目が、「東西４ｋｍ、南北４ｋｍ」の矩形範囲に相当する体温データを格納する領域である。以降、このマス目のことを「体温データ格納セル」もしくは単に「セル」と呼ぶ。

１つの体温データ格納セルに格納するデータは、体温を適当な精度で分類した場合の、各分類毎の発熱患者数である。実施形態では、体温の分類は、所定の体温、例えば３７．０以上を基準とし、０．５℃を単位に分類した。
３７．０℃以上３７．５℃未満
３７．５℃以上３８．０℃未満
３８．０℃以上３８．５℃未満
３８．５℃以上３９．０℃未満
３９．０℃以上３９．５℃未満
３９．５℃以上３９．５℃未満
４０．０℃以上４０．５℃未満
４０．５℃以上

サーバ１００のＣＰＵ１０１は、通常のメールクライアントアプリケーションと同様に、適当な時間間隔でメールサーバにアクセスし、自身宛のメールの受信処理を行う。いずれかの医療機関から体温データを記述したメールを受信すると、ＣＰＵ１０１は、先ず、３７℃以上の体温を上記分類別に集計する。つまり、各体温の範囲毎の発熱患者数をカウントする。そして、ＣＰＵ１０１は、受信したメールの発信元メールアドレスをキーにして医療機関ＤＢ１０６ａを検索することで、その医療機関の地理的位置の情報である座標(緯度、経度)を得る。この後、ＣＰＵ１０１は、この地理的位置の情報である座標(緯度、経度)から、図４のいずれの体温データ格納セルが該当するかを判定し、その体温データ格納セル内に既に格納されているデータ（もしあれば）を更新する。この結果、１つの体温データ格納セルに相当する地域に複数の医療機関が存在したとしても、それらの集計結果が、あたかも１つの仮想医療機関の体温データとして記憶管理することができる。

なお、図４に示す体温データ格納セルは、図５のＧＵＩにおける最大縮尺（図５の縮尺変更ツマミ５１０を最上の位置に移動したとき）の体温分布の最少単位に対応するものである。縮尺を下げたとき、つまり、より広い範囲の地図を地図表示領域５０１に表示させる指示があったとき、その際に表示する体温分布の最少単位は、上記の１つの体温データ格納セルがカバーする地域サイズよりも大きくしなければならない。そのためには、図４に示す水平方向連続するｍ個、垂直方向に連続するｍ個の計ｍ×ｍ個の体温データ格納セル内の各温度毎の発熱患者数を合算し、１つの「仮想」体温データ格納セルを構築すればよい。ここで、「ｍ」は縮尺の度合で決まる値であって、縮尺が小さいほど、大きな値を持つようにすればよい。単純には、最大縮尺をＲmaxとし、変更後の縮尺をＲとしたとき、ｍ＝Ｒmax／Ｒとすればよい（ただし、ｍは整数）。また、適当な係数ｋを採用し、ｍ＝ｋ・Ｒｍａｘ／Ｒとしても構わない。

以上、実施形態におけるサーバの構成と、医療機関ＤＢ１０６ａ、体温ＤＢ１０６ｃの構造並びにその原理について説明した。

次に、実施形態におけるサーバ１００におけるＣＰＵ１００が実行するサーバプログラム１０７の処理手順を図７、図８のフローチャートに従って説明する。なお、サーバ１００には、Ｗｅｂサーバとしての周知のプログラムが既に実行されているものとして説明する。なお、日付が代ったとき、全セルにおける全体温分類の発熱患者数が０とする、新たな日付の体温データを格納する領域をＨＤＤ１０５に確保するものとする。

以下、図７のフローチャートに従って説明するが、一般家庭２５０のユーザの端末２５１に対するフローも同様である。

ＣＰＵ１０１はステップＳ７０１にて、体温データを記述したメールを受信するのを待つ。体温データを記述しているメールを受信すると、ステップＳ７０２に進み、ＣＰＵ１０１は、受信した体温データを解析し、０．５℃の範囲毎に温度データの個数、すなわち、発熱患者数を集計する。そして、ステップＳ７０３に進んで、医療機関ＤＢ１０６ａを参照して、メールの発信元の地理的位置の情報である座標(緯度、経度)から地理的位置（経度、緯度）を判定する。次で、ステップＳ７０４に進んで、判定した地理的位置から、「今日」が示す体温データＤＢ内の該当する体温データ格納セルを決定する。そして、ステップＳ７０５にて、該当する体温データ格納セル内に格納された各体温範囲の患者数に、今回のメールで示された各体温範囲の発熱患者数を加算することで、その体温データ格納セルを更新する。

次に、実施形態におけるサーバ１００はＷｅｂサーバとして機能している場合のサーバプログラム１０７の処理を図８のフローチャートに従って説明する。これは、一般家庭２５０の端末２５１や医療期間の端末からのアクセスに応じた処理でもある。

ユーザが持つ端末（例えば図１の端末２５１等）から、アクセスがあると、先ず、ＣＰＵ１０１は、昨日までに集計された体温ＤＢ１０６ｃに基づく表示のためのＨＴＭＬドキュメントを作成する。具体的には、先ず、ステップＳ８０１にて、縮尺Ｒをデフォルト値に初期化し、ステップＳ８０２にて初期の体温閾値を３７．０℃に設定する。そして、ステップＳ８０３にて、初期の表示対象の体温分布を昨日の体温データから作成するように設定する。この後、ステップＳ８０４に進んで、初期の縮尺に応じて、体温分布データを再構築する。すなわち、先に説明したように、初期に縮尺に応じて、図４から「仮想」体温データ格納セルのサイズ（先に説明したｍ）を決定し、仮想体温データ格納セル毎の各温度毎の発熱患者数を集計する。このとき、初期の体温閾値ツマミ５１１の位置（すなわち、３７．０°Ｃ）以上の発熱患者数も集計しておく。

次で、ＣＰＵ１０１は、初期のスクロールバー５０２、５０３の位置、初期の縮尺（初期の縮尺ツマミ５１０の位置でもある）から、地図ＤＢから地図表示領域５０１に表示する地図イメージを切り出す。そして、その切り出した地図イメージ上の、各仮想体温格納セルの該当する位置に、初期の体温閾値“３７．０℃”以上の発熱患者数に見合った半径の円を合成する。そして、合成後の地図画像を含む図５に示す初期画面を表示するためのＨＴＭＬ（もしくはＸＭＬ）ドキュメントを生成し、要求元の端末に向けて送信する（ステップＳ８０５）。

上記の結果、本サーバにアクセスしてきたユーザの端末（例えば図１の端末２５１）のブラウザ画面には図５に示す初期のウインドウ５００が表示されることになる。この後、ユーザは、スクロールバー５０２、５０３、縮尺ツマミ５１０、体温閾値ツマミ５１１、日付変更ツマミ５１２のいずれかをポインティングデバイスで操作することになる。これが操作されると、端末２５１からサーバ１００にはその操作に係る要求が送信される。サーバ１００のＣＰＵ１０１は、この要求をステップＳ８０６にて待つことになる。

要求を受信すると、その要求が何であるのかをステップＳ８０７乃至Ｓ８１０にて判定することになる。

先ず、スクロール要求であると判定した場合、処理はステップＳ８１１に進め、ＣＰＵ１０１は地図ＤＢからの部分地図を切り出し位置を変更する。そして、ステップＳ８１５にて、変更後の切り出し位置に応じた、体温データに基づく円を合成し、送信する。このステップＳ８１５の処理は、実質的にＳ８０４、Ｓ８０５の処理と同じである。ただし、スクロール要求の場合には、縮尺が変更されたわけではないので、従前に生成した体温分布データを活用できる。

また要求が縮尺変更であると判定した場合、ＣＰＵ１０１は処理をステップＳ８１２に進め、新たな縮尺に応じた仮想体温格納セルのサイズｍを決定し、集計する。因に、縮尺が最大の場合には、仮想体温格納セルのサイズは、図４に示す１つの体温格納セルのサイズと等しい。この後、ステップＳ８１５に進み、地図データと体温データに基づく円との合成画像を生成し、要求元に送信する。

また体温閾値の変更要求であると判断した場合には、処理をステップＳ８１３に進め、体温閾値を変更し、現在の仮想体温格納セルに基づく、変更後の体温以上の発熱患者数を集計を行う。また、日付変更が要求された場合には、ステップＳ８１４に進み、処理対象の体温データを変更後の日付の体温データに設定する。いずれの場合でも、ステップＳ８１５に進み、地図データと円とを合成した画像を生成し、要求元に送信する。

以上実施形態に係る体温分布計測システムを説明した。上記からもわかるように、本システムを利用すると、医療機関にとってみれば自身が位置する地域で、発熱を伴う感染症の近い将来で流行するかどうかを判断することはでき、しかも、その流行がると判断できる場合には、事前に薬の手配や人員の勤務形態を変更する等の事前準備が可能になる。

また、サーバが医療機関から受けとる情報は、体温データ及び患者数で十分であるので、個人情報の漏洩と言った問題は発生しない。

また、実施形態では、各医療機関からメールにて、体温データを、カンマで区切ってサーバに送信し、サーバは、各体温データを０．５℃範囲毎に体温データの個数（発熱患者数）を集計するものとした。この処理は、各医療機関側で行っても構わない。すなわち、「３７．０℃以上３７．５℃未満はｘｘ人」、「３７．５℃以上３８．０℃未満はｙｙ人」…という形式でサーバに送信するようにしても構わない。

また、先に説明したように、サーバのホームページに、各温度範囲に対する発熱患者数を入力する画面を用意し、各医療機関の端末でサーバのそのホームページを閲覧してデータをエントリーしても構わない。この場合、医療機関を特定するために、ログイン時にＩＤやメールアドレスを入力させることが必要になる。

また、実施形態では、日本全土における体温分布図をサーバ１００が作成するものとして説明したが、地方別（北海道、東北、関東等）にサーバを設置して、個々のサーバの負担を軽減させるようにしても構わない。ただし、精度上、最少範囲は都道府県までとすることが望ましい。

さらにまた、一般人にとっては、例えば観光先に行く際にマスク等の下準備が必要かどうかも指針を得ることも出来よう。

なお、上記実施形態では、地図に合成する発熱患者数の度合を、サイズの異なる円で表わしたが、発熱患者数の多少をグラフィカルシンボルで示せば良いので、形状は円に限らず如何なる形状でも良い。例えば、棒グラフの形式でも構わない（この場合、棒グラフの高さが発熱患者数になる）。

また、上記実施形態に加えて、個人がＧＰＳ機能を内蔵した携帯端末（携帯電話等）から、自身が測定した体温データをＧＰＳで測定した位置情報と共にサーバにメールとして送信しても構わない。サーバは、このメールを受けとったとき、ＧＰＳの位置情報から体温データ格納セルを決定し、該当する体温データの「患者数」を＋１だけ更新する処理を行えば良い。

また、上記実施形態ではとくに説明しなかったが、サーバ１００が記憶管理する医療機関ＤＢ１０６ａは、医療機関からの登録要求に応じて登録可能にすることが望ましい。その際の登録メールの記述サンプルは、サーバ１００が有するホームページで示せば良いであろう。

また、上記実施形態の記載からも明らかなように、実施形態におけるサーバ１００は、図７、図８に示すプログラムを実行できればその機能を実現でき、通常のパーソナルコンピュータ等の汎用情報処理装置のハードウェアがあれば十分である。従って、本発明はコンピュータプログラム、並びに、それを格納したＣＤＲＯＭ等のコンピュータ可読記憶媒体をもその範疇とすることは明らかである。

１００：サーバ、２００、２０１：医療機関、２０１、２１１、２５１：端末、２５０：一般家庭、３００：ネットワーク、１０１：ＣＰＵ、１０２：ＲＯＭ、１０３：ＲＡＭ、１０４：ネットワークＩ／Ｆ、１０５：ＨＤＤ、１０６ａ：医療機関ＤＢ、１０６ｂ：地図ＤＢ、１０６ｃ：体温ＤＢ、１０７：サーバプログラム

Claims (12)

1. 端末と、当該端末とネットワークを介して接続され、少なくともＷｅｂサーバとして機能するサーバ装置とで構成される発熱患者の分布計測システムであって、
   前記端末は、
   前記ネットワークを介して、発信元を特定する情報と、体温と測定した発熱患者数を示す情報を含む体温測定情報を前記サーバに送信する送信手段を有し、
   前記サーバ装置は、
   前記地理的位置に対応する複数の記憶領域を有する第１の記憶手段と、
   端末を特定する情報と当該端末の前記地理的位置とを対応付けて記憶する第２の記憶手段と、
   前記ネットワークインタフェースを介して、前記端末から送信されてきた前記体温測定情報を受信する受信手段と、
   該受信手段で受信した前記体温測定情報に含まれる前記端末を特定する情報をキーにして、前記第２の記憶手段を検索することで、前記体温測定情報の送信元の前記端末の前記地理的位置を判定する判定手段と、
   該判定手段で判定した前記地理的位置に対応する１つの記憶領域を、前記第１の記憶手段における前記複数の記憶領域の中から特定する特定手段と、
   該特定手段で特定された記憶領域に、前記体温測定情報に含まれる体温と測定した発熱患者数を示す情報を格納する格納手段と、
   前記第１の記憶手段の各記憶領域に格納された体温と患者数を表わすグラフィカルシンボルを、予め用意された地図画像上の該当する前記地理的位置に配置した画像を含む、Ｗｅｂブラウザで閲覧可能なページを生成する生成手段と、
   を有することを特徴とする発熱患者の分布計測システム。
2. 前記第１の記憶手段に確保された記憶領域は、予め設定された前記地理的位置を内包する所定の距離範囲に対応し、
   前記格納手段は、前記距離範囲に属する異なる医療機関に設置された前記端末から受信した前記体温測定情報については、仮想的な１つの医療機関から情報として、前記患者の前記体温と測定した前記発熱患者数を示す情報を１つの前記記憶領域に格納する
   ことを特徴とする請求項１に記載の発熱患者の分布計測システム。
3. 前記サーバ装置は、前記ネットワーク上の端末から体温の前記地図画像のスクロール要求を受信する第１の要求受信手段を更に有し、
   前記生成手段は、前記要求に応じたスクロール後の地図画像と、当該スクロール後の地図画像に内包される地理的位置に対応する前記記憶領域に格納された前記体温と前記患者数を表わすグラフィカルシンボルを配置した地図画像を再構成することを特徴とする請求項１又は２に記載の発熱患者の分布計測システム。
4. 前記サーバ装置は、前記ネットワーク上の端末から前記地図画像の縮尺を変更する要求を受信する第２の要求受信手段を更に有し、
   前記生成手段は、
   前記第２の要求受信手段で受信した要求に応じた変更後の縮尺に応じて、患者数を表わす前記グラフィカルシンボルの１つが表わす地理的範囲を決定し、
   当該地理的範囲の１つに属する前記第１の記憶手段の記憶領域のデータを合算して、対応するグラフィカルシンボルを配置した地図画像を再構成する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の発熱患者の分布計測システム。
5. 前記サーバ装置は、前記ネットワーク上の端末から体温の下限閾値を変更する要求を受信する第３の要求受信手段を更に有し、
   前記生成手段は、前記第３の要求手段が受信した要求に応じた変更後の下限体温閾値以上の体温を持つ発熱患者数を前記第１の記憶手段を参照して集計し、対応するグラフィカルシンボルを配置した地図画像を再構成することを特徴とする請求項１乃至４のいずれか１項に記載の発熱患者の分布計測システム。
6. 前記第１の記憶手段は、日付毎に、前記地理的位置に対応する複数の記憶領域を有し、
   前記サーバ装置は、前記ネットワーク上の端末から日付変更の要求を受信する第４の要求受信手段を更に有し、
   前記生成手段は、前記第４の要求手段に応じて変更した日付の、前記第１の記憶手段の各記憶領域に格納された体温と前記患者数を表わすグラフィカルシンボルを含む地図画像を再構築する
   ことを特徴とする請求項１乃至５のいずれか１項に記載の発熱患者の分布計測システム。
7. 前記端末が有する送信手段は所定の通信プロトコルで送信し、
   前記サーバ装置が有する受信手段は、前記通信プロトコルを受信し、
   前記判定手段は、各医療機関のアドレスと、各前記端末の経度、緯度で表わされる地理的位置の情報で構成されるデータベースを参照することで、前記受信手段で受信した前記体温測定情報に含まれる前記発信元を特定する情報から、発信元の前記地理的位置を判定することを特徴とする請求項１乃至６のいずれか１項に記載の発熱患者の分布計測システム。
8. 送信手段は、自身の地理的位置情報を含む前記体温測定情報を送信し、
   前記受信手段で受信した前記体温測定情報に前記地理的位置情報が含まれる場合には、前記特定手段は、当該体温測定情報に含まれる地理的位置情報に従って、前記第１の記憶手段における前記複数の記憶領域の中の１つを特定する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の発熱患者の分布計測システム。
9. ネットワークインタフェースを有すると共に、当該ネットワークインタフェースを用いたＷｅｂサーバ機能を有し、発熱患者の分布を表わす地図を前記Ｗｅｂサーバ機能を利用して配信するサーバ装置であって、
   地理的位置に対応する複数の記憶領域を有する第１の記憶手段と、
   各端末を特定する情報と各端末の地理的位置とを対応付けて記憶する第２の記憶手段と、
   前記ネットワークインタフェースを介して、各端末から、測定された患者の体温と測定された患者数を示す情報、並びに、前記端末を特定する情報とを含む体温測定情報を受信する受信手段と、
   該受信手段で受信した前記体温測定情報に含まれる前記端末を特定する情報をキーにして、前記第２の記憶手段を検索することで、前記体温測定情報の送信元の前記端末の地理的位置を判定する判定手段と、
   該判定手段で判定した前記地理的位置に対応する記憶領域を、前記第１の記憶手段における前記複数の記憶領域の中から特定する特定手段と、
   該特定手段で特定された記憶領域に、前記体温測定情報に含まれる患者の前記体温と測定した前記患者数を示す情報を格納する格納手段と、
   前記第１の記憶手段の各記憶領域に格納された前記体温と前記患者数を表わすグラフィカルシンボルを、予め容易された地図画像上の該当する前記地理的位置に配置した画像を含む、Ｗｅｂブラウザで閲覧可能なページを生成する生成手段と、
   を有することを特徴とするサーバ装置。
10. ネットワークインタフェースと、地理的位置に対応する複数の記憶領域を有する第１の記憶手段と、各端末を特定する情報と各端末の地理的位置とを対応付けて記憶する第２の記憶手段とを有し、前記ネットワークインタフェースを用いたＷｅｂサーバ機能を有し、発熱患者の分布を表わす地図を前記Ｗｅｂサーバ機能を利用して配信するサーバ装置の制御方法であって、
    前記ネットワークインタフェースを介して、各端末から、測定された患者の体温と測定された患者数を示す情報、並びに、前記端末を特定する情報とを含む体温測定情報を受信する受信工程と、
    該受信工程で受信した前記体温測定情報に含まれる前記端末を特定する情報をキーにして、前記第２の記憶手段を検索することで、前記体温測定情報の送信元の前記端末の地理的位置を判定する判定工程と、
    該判定工程で判定した前記地理的位置に対応する記憶領域を、前記第１の記憶手段における前記複数の記憶領域の中から特定する特定工程と、
    該特定工程で特定された記憶領域に、前記体温測定情報に含まれる患者の前記体温と測定した前記患者数を示す情報を格納する格納工程と、
    前記第１の記憶手段の各記憶領域に格納された前記体温と前記患者数を表わすグラフィカルシンボルを、予め容易された地図画像上の該当する前記地理的位置に配置した画像を含む、Ｗｅｂブラウザで閲覧可能なページを生成する生成工程と、
    有することを特徴とするサーバ装置の制御方法。
11. コンピュータに読み込ませ実行させることで、前記コンピュータに、請求項１０に記載の各工程を実行させるためのプログラム。
12. 請求項１１に記載のプログラムを格納したコンピュータ可読記憶媒体。

Images