(57)【要約】【課題】広域ネットワークからの医療情報のダウンロードにおける適時性及び安定性を向上させるための技術を提供する。【解決手段】個人医療情報を管理するデータベースを有するサーバから、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードする。個人医療情報は複数の分野の情報から構成されており、前記病院のコンピュータ又は前記サーバにおいて前記患者の診療に必要な個人医療情報の分野が特定される。これに基づいて、前記データベースに格納されている前記患者の個人医療情報のうち前記特定された分野に関わる一部の情報のみが前記病院のコンピュータへ送信される。【選択図】図１
2014134934.tif 000002
【特許請求の範囲】
【請求項１】
個人医療情報を管理するデータベースを有するサーバから、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードするための医療情報管理方法であって、
病院のコンピュータが、サーバに対して、診療する予定の患者の個人医療情報のダウンロード要求を送信するステップと、
前記サーバが、前記ダウンロード要求に応じて、前記患者の個人医療情報をデータベースから抽出し、前記病院のコンピュータに送信するステップと、
前記病院のコンピュータが、前記サーバから受信した前記患者の個人医療情報を記憶装置に記憶するステップと、を有し、
前記個人医療情報は複数の分野の情報から構成されており、
前記病院のコンピュータ又は前記サーバにおいて前記患者の診療に必要な個人医療情報の分野が特定されることにより、前記データベースに格納されている前記患者の個人医療情報のうち前記特定された分野に関わる一部の情報のみが前記病院のコンピュータへ送信される
ことを特徴とする医療情報管理方法。
【請求項２】
患者の診療に必要な個人医療情報の分野は、当該患者の対象部位又は症状に基づいて特定される
ことを特徴とする請求項１に記載の医療情報管理方法。
【請求項３】
前記患者の診療の結果、変更又は新たに得られた情報を、前記病院のコンピュータが前記サーバに対してアップロードし、前記サーバのデータベースに格納するステップをさらに有する
ことを特徴とする請求項１又は２に記載の医療情報管理方法。
【請求項４】
前記病院のコンピュータが患者から受診申し込みを受け付けるステップをさらに有し、
前記病院のコンピュータは、患者からの受診申し込みに応じて、当該患者の個人医療情報のダウンロード要求を前記サーバに対して送信する
ことを特徴とする請求項１〜３のうちいずれか１項に記載の医療情報管理方法。
【請求項５】
前記患者の個人医療情報の前記病院のコンピュータへのダウンロードが終了した場合、又は、前記患者の個人医療情報の前記病院のコンピュータへのダウンロードが診療日時よりも前に終了する見込みである場合に、前記病院のコンピュータが前記患者に対して受診の許諾を返信するステップをさらに有する
ことを特徴とする請求項４に記載の医療情報管理方法。
【請求項６】
前記サーバが患者から受診申し込みを受け付けるステップと、
前記サーバが当該患者の診療を行う病院を決定し、当該病院のコンピュータに対して受診申し込みを行うステップと、をさらに有する
ことを特徴とする請求項１〜３のうちいずれか１項に記載の医療情報管理方法。
【請求項７】
前記患者の個人医療情報の前記病院のコンピュータへのダウンロードが終了した場合、又は、前記患者の個人医療情報の前記病院のコンピュータへのダウンロードが診療日時よりも前に終了する見込みである場合に、前記サーバが前記患者に対して受診の許諾を返信するステップをさらに有する
ことを特徴とする請求項６に記載の医療情報管理方法。
【請求項８】
前記病院のコンピュータが、前記記憶装置に記憶された患者の個人医療情報を、当該患
者の診療が終了した後に、削除するステップをさらに有する
ことを特徴とする請求項１〜７のうちいずれか１項に記載の医療情報管理方法。
【請求項９】
前記個人医療情報のダウンロード要求に優先度を付加することが可能であり、
前記サーバは、優先度が付加されていないダウンロード要求よりも、優先度が付加されているダウンロード要求を優先的に処理する
ことを特徴とする請求項１〜８のうちいずれか１項に記載の医療情報管理方法。
【請求項１０】
前記ダウンロード要求に付加される優先度は、個人医療情報が必要とされる時刻を表す情報であり、
前記サーバは、優先度が付加されているダウンロード要求について、個人医療情報が必要とされる時刻が現在時刻に近いものほど優先的に処理する
ことを特徴とする請求項９に記載の医療情報管理方法。
【請求項１１】
前記サーバが、個人の端末から、直接に又は前記病院のコンピュータを介して、当該個人の個人医療情報のダウンロード要求を受信するステップと、
前記サーバが、前記個人の端末に対して、直接に又は前記病院のコンピュータを介して、ダウンロード要求された当該個人の個人医療情報を送信するステップと、
をさらに有することを特徴とする請求項１〜１０のうちいずれか１項に記載の医療情報管理方法。
【請求項１２】
前記サーバが、個人の端末から、直接に又は前記病院のコンピュータを介して、当該個人の個人医療情報を受信するステップと、
前記サーバが、前記個人の端末から受信した個人医療情報を前記データベースに格納するステップと、
をさらに有することを特徴とする請求項１〜１１のうちいずれか１項に記載の医療情報管理方法。
【請求項１３】
前記患者の診療が終了した後、前記サーバ又は前記病院のコンピュータが、診療の履歴を表す情報を前記患者に送信するステップをさらに有する
ことを特徴とする請求項１〜１２のうちいずれか１項に記載の医療情報管理方法。
【請求項１４】
前記診療の履歴には、少なくとも診療日と病院名が含まれており、
前記診療の履歴を表す情報は、前記サーバのデータベースに前記個人医療情報の一つとして記憶される
ことを特徴とする請求項１３に記載の医療情報管理方法。
【請求項１５】
個人医療情報を管理するデータベースを有するサーバから、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードするための医療情報管理方法であって、
病院のコンピュータが、サーバに対して、診療する予定の患者の個人医療情報のダウンロード要求を送信するステップと、
前記サーバが、前記ダウンロード要求に応じて、前記患者の個人医療情報をデータベースから抽出し、前記病院のコンピュータに送信するステップと、
前記病院のコンピュータが、前記サーバから受信した前記患者の個人医療情報を記憶装置に記憶するステップと、を有し、
前記個人医療情報のダウンロード要求に優先度を付加することが可能であり、
前記サーバは、優先度が付加されていないダウンロード要求よりも、優先度が付加されているダウンロード要求を優先的に処理する
ことを特徴とする医療情報管理方法。
【請求項１６】
個人医療情報を管理するデータベースを有しており、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードさせる、サーバであって、
病院のコンピュータから、診療する予定の患者の個人医療情報のダウンロード要求を受信する手段と、
前記ダウンロード要求に応じて、前記患者の個人医療情報をデータベースから抽出し、前記病院のコンピュータに送信する手段と、を有し、
前記個人医療情報は複数の分野の情報から構成されており、
前記病院のコンピュータ又は前記サーバにおいて前記患者の診療に必要な個人医療情報の分野が特定されることにより、前記データベースに格納されている前記患者の個人医療情報のうち前記特定された分野に関わる一部の情報のみが前記病院のコンピュータへ送信される
ことを特徴とするサーバ。
【請求項１７】
患者の診療に必要な個人医療情報の分野は、当該患者の対象部位又は症状に基づいて特定される
ことを特徴とする請求項１６に記載のサーバ。
【請求項１８】
前記個人医療情報のダウンロード要求に優先度を付加することが可能であり、
前記サーバは、優先度が付加されていないダウンロード要求よりも、優先度が付加されているダウンロード要求を優先的に処理する
ことを特徴とする請求項１６又は１７に記載のサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は医療情報管理方法に関し、特に病院外部のサーバから広域ネットワークを介して病院のコンピュータに患者の個人医療情報をダウンロードするための技術に関する。
【背景技術】
【０００２】
病院（受診）予約方法に関するシステムについては、特許文献１（特開平１０−３１７０８号公報）、特許文献２（特開平９−１６０９９４号公報）に開示されたものが知られている。特許文献１のシステムでは、病院情報システムが各受診予約日の当日又は前日以前に該当受診予約日の予約外来患者の診療履歴及び予約情報を検査画像管理システムへ送信し、検査に先立ち検査画像管理システムから表示端末へ検査画像を送る。その結果、病院内のネットワーク（ＬＡＮ）の処理負荷を軽くすることを可能としている。また、特許文献２には、コンピュータを用いて、病院内の情報特に患者の診断画像データなどの長大データを管理するような病院システムが開示されている。具体的には、特許文献２には、ＭＯチェンジャの様な低速記憶装置に記憶されている長大データを、予約情報に基づき、ＨＤＤの様な高速記憶装置に予めコピーしておくことによって、診療時に素早くデータを取り出すことを可能にすることが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０−３１７０８号公報
【特許文献２】特開平９−１６０９９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前述した従来システムは、患者の受診（検査）予約に対して、病院内のネットワーク（ＬＡＮ）のボトルネックや病院内の記憶装置のボトルネックを良好に解決することができる。しかしながら、従来システムの方法では、病院外部のネットワーク（ＷＡＮ）の速度低下によるボトルネックを解消することはできない。また、特許文献１、特許文献２のシステムでは救急患者の対応については考慮されていない。
【０００５】
ＩＴ技術の進歩やクラウドコンピューティングの登場により、最近では、医療情報を病院外部のサーバにて保管・管理し、異なる病院間で医療情報を共有するような仕組みが提案されはじめている。しかし、このような仕組みを実際に運用するにあたっては、従来システムとは異なる新たな課題が発生する。その一つが、病院外部のネットワーク（ＷＡＮ）上にあるサーバから、適時に且つ安定的に、個人医療情報のデータをダウンロードできるようにしなければならない点である。例えば、ネットワーク（ＷＡＮ）の混雑や不調により伝送速度が低下すると、データのダウンロードに予想以上の時間がかかる可能性がある。特に、診断画像などのデータが含まれていると、医療情報のデータサイズが非常に大きくなるため、ネットワーク（ＷＡＮ）の速度低下は深刻になる。もし個人医療情報のダウンロードが適時に行えないと、患者が病院に到着しているにもかかわらず、診断に必要な個人医療情報が手元に無いため、診断ができない、という問題が発生してしまう。また、救急患者のように、個人医療情報の入手（ダウンロード）に緊急性が要求される場合への対応も課題の一つである。
【０００６】
本発明は上記のような課題に鑑みたものであり、病院外部のネットワーク（ＷＡＮ：以降、広域ネットワークとも記す）からの医療情報のダウンロードにおける適時性及び安定性を向上させるための技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の第１態様は、個人医療情報を管理するデータベースを有するサーバから、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードするための医療情報管理方法であって、病院のコンピュータが、サーバに対して、診療する予定の患者の個人医療情報のダウンロード要求を送信するステップと、前記サーバが、前記ダウンロード要求に応じて、前記患者の個人医療情報をデータベースから抽出し、前記病院のコンピュータに送信するステップと、前記病院のコンピュータが、前記サーバから受信した前記患者の個人医療情報を記憶装置に記憶するステップと、を有し、前記個人医療情報は複数の分野の情報から構成されており、前記病院のコンピュータ又は前記サーバにおいて前記患者の診療に必要な個人医療情報の分野が特定されることにより、前記データベースに格納されている前記患者の個人医療情報のうち前記特定された分野に関わる一部の情報のみが前記病院のコンピュータへ送信されることを特徴とする医療情報管理方法である。
【０００８】
本発明の第２態様は、個人医療情報を管理するデータベースを有するサーバから、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードするための医療情報管理方法であって、病院のコンピュータが、サーバに対して、診療する予定の患者の個人医療情報のダウンロード要求を送信するステップと、前記サーバが、前記ダウンロード要求に応じて、前記患者の個人医療情報をデータベースから抽出し、前記病院のコンピュータに送信するステップと、前記病院のコンピュータが、前記サーバから受信した前記患者の個人医療情報を記憶装置に記憶するステップと、を有し、前記個人医療情報のダウンロード要求に優先度を付加することが可能であり、前記サーバは、優先度が付加されていないダウンロード要求よりも、優先度が付加されているダウンロード要求を優先的に処理することを特徴とする医療情報管理方法である。
【０００９】
本発明の第３態様は、個人医療情報を管理するデータベースを有しており、広域ネットワークを介して、患者の診療を行う病院のコンピュータへ当該患者の個人医療情報をダウンロードさせる、サーバであって、病院のコンピュータから、診療する予定の患者の個人医療情報のダウンロード要求を受信する手段と、前記ダウンロード要求に応じて、前記患者の個人医療情報をデータベースから抽出し、前記病院のコンピュータに送信する手段と、を有し、前記個人医療情報は複数の分野の情報から構成されており、前記病院のコンピュータ又は前記サーバにおいて前記患者の診療に必要な個人医療情報の分野が特定されることにより、前記データベースに格納されている前記患者の個人医療情報のうち前記特定された分野に関わる一部の情報のみが前記病院のコンピュータへ送信されることを特徴とするサーバである。
【発明の効果】
【００１０】
本発明によれば、広域ネットワークからの医療情報のダウンロードにおける適時性及び安定性を向上させることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施形態の処理フローを示す図
【図２】本発明の第２の実施形態の処理フローを示す図
【図３】本発明の第３の実施形態の処理フローを示す図
【図４】本発明の第４の実施形態の処理フローを示す図
【図５】本発明の第４の実施形態の他の処理フローを示す図
【図６】本発明の第５の実施形態の処理フローを示す図
【図７】個人医療情報の内容を示すファイル（情報タグファイル）の一例を示す表
【図８】診療履歴情報の情報タグファイルの一例を示す表
【図９】個人が個人医療情報を作成する場合の情報タグファイルの一例を示す表
【図１０】第１の実施形態の工程を模式的に示した図
【図１１】第２の実施形態の工程を模式的に示した図
【図１２】第３の実施形態の工程を模式的に示した図
【図１３】第４の実施形態の工程を模式的に示した図
【発明を実施するための形態】
【００１２】
本発明は、個人医療情報を管理するデータベースを有するサーバから、インターネット等の広域ネットワークを介して、患者の診療を行う病院（病院に類する施設を含む）のローカルコンピュータへ当該患者の個人医療情報をダウンロードするための技術に関する。特に本発明は、個人医療情報を入手できなければ医者が患者の診療を開始できないという個人医療情報の特殊性を考慮し、個人医療情報のダウンロードの適時性及び安全性を向上するための仕組みを提供することを特徴とする。特徴の一つは、すべての個人医療情報をダウンロードするのではなく、患者の診療に必要な情報（一部の情報）のみをダウンロードすることで、ダウンロード時間の短縮を図るという点である。また他の特徴は、すべてのダウンロード要求を画一的に処理するのではなく、優先度（緊急度）の高い要求を優先的に処理することで、例えば救急患者に対する即時性を高めることができるようにした点である。これらの特徴の具体的内容及び他の特徴については後述する。本発明は、個人医療情報を管理するサーバと病院のコンピュータとの協働で実現される、医療情報管理システムや医療情報管理方法として捉えることができ、病院の受診予約等に好ましく適用することができる。
【００１３】
個人医療情報は、広域ネットワークにあるサーバ（例えばクラウドサーバ）のデータベースに保管・管理される。個人医療情報には、例えば、病歴、診察や診断の結果、治療の内容や経過、身体的特徴、薬、アレルギなど、患者の診療に利用される情報であればいかなる種類の情報も含めることができる。また個人医療情報のデータ形式はどのようなものでもよい。例えば、医者の診断書やカルテの内容を記述したテキストデータでも良いし、診断書やカルテなどのＰＤＦデータや、レントゲン写真の様な画像データでも良い。もちろん、様々なデータ形式の複数のデータから個人医療情報が構成されていても良い。レントゲン写真の様に比較的データ量の小さい画像だけでなく、ＣＴやＭＲＩのような断層画像や、バーチャルスライドと呼ばれる高解像度の顕微鏡画像のように、データ量が大きい画像に本発明を適応するとより良好な効果を得ることができる。
【００１４】
以下では、初めに、本発明の効果がより顕著に表れるバーチャルスライドの画像データ、及び、バーチャルスライドの画像データのネットワーク（ＷＡＮ）を介した転送時間について説明する。その後、本発明の実施形態について詳細に説明する。
【００１５】
（バーチャルスライド）
近年、広範囲かつ高解像度の顕微鏡写真を画像データ化し、この画像データをビューアと言われるアプリケーションソフトウエアでパーソナルコンピュータのモニタ上に表示し診断することが行われている。観察者（医者）はビューアを用い、拡大、縮小、スクロール等の指示を行い、あたかも顕微鏡での観察をパーソナルコンピュータのモニタ上で再現することが行われている。そして、パーソナルコンピュータの画面を医者は観察し診断を行う。一般に、この画像をバーチャルスライドと呼んでいる。このバーチャルスライドのデータ量は、非常に大きい。
【００１６】
例えば、20mm×20mmの範囲を１画素0.25umの解像度で画像データ化すると、この場合の画素数は、
80k×80k＝6.4G                      ・・・式１）
となる。
画像データのデータ量は、例えば１画素がＲＧＢ各々８bitのデータとすれば、
6.4G×3×8bit＝153.6Gbit            ・・・式２）
となる。
【００１７】
バーチャルスライドシステムでは、例えば１つのスライド（被写体）を光軸方向（Ｚ方向）について焦点位置を変えながら複数回撮影することで、異なる深さの複数枚の画像データを取得することがある。各焦点位置の画像は「レイヤー画像」と呼ばれ、複数枚のレイヤー画像で構成される画像セットは「Ｚスタック画像」と呼ばれる。Ｚスタック画像を用いることで、ビューアにおいて、スライドのＸＹ面内だけでなく、深さ方向（Ｚ方向）の観察が可能となり、より詳細な診断ができる。
【００１８】
例えば１枚のスライドについて10層（10レイヤ）のレイヤー画像を持つ場合には、Ｚスタック画像のデータ量は、
153.6Gbit×10＝1536Gbit            ・・・式３）
となる。
一般に、このような大きなデータを持つことは記憶容量やデータの転送時間の問題から不都合であるので、公知のＪＰＥＧ等の技術を用いて圧縮を行い、1/5から1/10程度にデ
ータ量を削減する。例えば、ＪＰＥＧ圧縮により1/5にデータ量を削減すれば、Ｚスタッ
ク画像のデータ量は、
1536×0.2＝307.2Gbit              ・・・式４）
となる。
このように、バーチャルスライドの画像データのデータ量は非常に大きいことがわかる。
【００１９】
（バーチャルスライドの画像データの転送時間）
近年、ネットワークの通信速度は上昇している。例えば1Gbps程度の通信速度を有して
いるネットワークも実現している。
1Gbpsの通信速度を持つネットワークを用いて、式４）で示した量の画像データを転送
する場合を考える。例えば、ネットワークの伝送効率を25％とすれば、
307.2Gbit／(1Gbps×0.25)＝1228.8Sec    ・・・式５）
となり、約20分のデータ転送時間（ダウンロード時間）になる。
診療（診断）に必要なバーチャルスライドが複数の場合は、より多くの時間が必要となる。診療（診断）中にダウンロードを行う場合、医者と患者はダウンロードの完了を待たねばならず、問題となる。
【００２０】
＜第１の実施形態＞
本発明の第１の実施形態について説明する。第１の実施形態は、患者が病院に受診申し込みを行う形態を想定している。
第１の実施形態を実現する処理フローの詳細を記す前に、第１の実施形態のシステムの動作の理解のために、図１０（ａ）〜図１０（ｃ）を用いて第１の実施形態の概要を説明する。
【００２１】
図１０（ａ）〜図１０（ｃ）は本発明の第１の実施形態の工程を模式的に示した図である。患者が受診を申し込む場合、図１０（ａ）に示すように、初めに、患者１００は病院１０２に対して受診申し込み（Ｐ１）を行う。この受診申し込みは、例えば患者１００の個人端末１０１から病院１０２内のコンピュータ１０３に対して、不図示の広域ネットワーク（ＷＡＮ）を介して行うと好適である。受診申し込みの際、患者１００の識別を行う患者ＩＤ（例えば病院が発行する診療券の番号）や、対象部位や症状等を同時に病院１０２に対して申告する。対象部位とは、例えば、痛みや違和感のある部位、傷やケガを負った部位、病気の症状が出ている部位など、診療の対象となる部位のことである。病院１０
２内のコンピュータ１０３は患者ＩＤを基に患者１００の個人医療情報ＩＤを検索する。個人医療情報ＩＤは、個人医療情報を指定するための（個人を限定するための）ユニークな番号である。個人医療情報ＩＤについては、本システムが割り当てた番号でも良いが、国が国民に割り当てた国民識別番号（例えばアメリカ合衆国のＳＳＮ等）があればそれを利用しても良い。さらに、コンピュータ１０３は、患者１００から申告された対象部位や症状等から、診療に必要な個人医療情報の分野を特定する。この明細書では個人医療情報の絞り込みを行う条件を「分野」という言葉を用いて説明する。個人医療情報の分野の特定は必ずしも病院１０２内のコンピュータ１０３で行う必要はなく、例えば医者が直接指定しても良い。そして、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４に「個人医療情報ＩＤ」と特定した「個人医療情報の分野」を送り、患者１００の個人医療情報のダウンロードを要求する（Ｐ２）。サーバ１０４は、個人医療情報のダウンロード要求に応じて病院１０２内のコンピュータ１０３に個人医療情報を送信して良いかを患者１００に確認する。具体的には、サーバ１０４は個人医療情報ＩＤを基に患者１００の個人端末の電子メールアドレスを特定し、病院１０２内のコンピュータ１０３に個人医療情報を提供して良いかを確認する電子メールを送信する（Ｐ３）。患者１００が個人医療情報の提供を許可すると（Ｐ４）、サーバ１０４は、「個人医療情報ＩＤ」と「個人医療情報の分野」で特定される個人医療情報をコンピュータ１０３へ送信する（Ｐ５）。セキュリティーを高めるため、個人医療情報は暗号化されていると良い。個人医療情報を受信した病院１０２内のコンピュータ１０３は、患者１００の個人端末１０１に受診許諾を送信する（Ｐ６）。
【００２２】
次に図１０（ｂ）に示した様に、受診許諾を受けた患者１００は、病院１０２に行き、患者ＩＤと個人医療情報の暗号キーを病院１０２の受付に提示又は提出して診療の順番待ちをする（Ｐ７）。病院１０２内のコンピュータ１０３は暗号キーを用い個人医療情報を復号する（Ｐ８）。そして、医者は復号された個人医療情報を閲覧し患者１００を診療する（Ｐ９）。その後患者は帰宅する。
【００２３】
診療が終了すると、コンピュータ１０３は、変更または新たに得た個人医療情報を患者１００の暗号キーで暗号化し、図１０（ｃ）に示した様にサーバ１０４にアップロードする（Ｐ１０）。その結果、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４には暗号化された個人医療情報が蓄積される。さらに病院１０２内のコンピュータ１０３は、患者１００に今回の診療に関する診療履歴を電子メール等で送信する（Ｐ１１）。そして病院１０２内のコンピュータは、ダウンロードした個人医療情報を削除する。
【００２４】
（処理フロー）
次に、図１のフローチャートを用いて、本発明の第１の実施形態を実現するための処理フローを説明する。図１のフローを実行するためのハードウエアは、公知のネットワークやサーバやコンピュータや個人端末により構成することができる。以下に述べる本システムの機能は、これらの公知のハードウエア上で実行されるソフトウエアにより実現することができる。図１において、それぞれのフローチャートは左から、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４、病院１０２内部のコンピュータ１０３、患者１００の工程を示す。
【００２５】
初めに、患者１００は病院１０２内部のコンピュータ１０３に対して受診申し込みを行う（ステップＳＴ１００）。この受診申し込みは、前述した様に個人端末１０１すなわち個人で所有しているパーソナルコンピュータやスマートフォン等を用い不図示のネットワーク（ＷＡＮ）を経由して行う。個人端末１０１を使用できない患者は従来通り電話申し込みを行うか来院し直接申し込みを行う。この場合は、病院１０２のオペレータが代行して病院１０２内のコンピュータ１０３に受診申し込みを入力する。このとき、前述した様に患者１００を識別する患者ＩＤ（例えば病院が発行する診療券の番号）と、対象部位や
症状等を病院１０２内のコンピュータ１０３に対して入力する。患者が初診の場合は、患者ＩＤが無いので、個人医療情報ＩＤと、生年月日や氏名を代わりに送る。病院は患者ＩＤを作成し、患者ＩＤと個人医療情報ＩＤを関係づける。もちろん病院の患者ＩＤは個人医療情報ＩＤそのものを用いて管理しても良い。この場合、患者ＩＤと個人医療情報ＩＤの対応を病院１０２内のコンピュータ１０３は記憶する必要がない。
【００２６】
病院１０２内のコンピュータ１０３は患者１００の対象部位や症状から、診療に必要な患者１００の個人医療情報の分野を特定する。例えば患者１００が痛む部位を挙げた場合は、その部位を基に個人医療情報の分野を絞り込み特定する。また風邪の様な自覚症状の場合は、風邪と診断された症状を個人医療情報の分野として特定する。この個人医療情報の分野の特定は、患者１００の自己申告の場合は絞り込みを厳密に行わず関係する部位を広範囲に特定すると良い。例えば患者１００が「胃が痛い」という自覚症状を申告した場合は、特定する分野は胃以外に、食道、小腸、肝臓、腎臓、膵臓、脾臓等の部位とすると良い。これは患者１００の自己申告の場合、部位の特定が不正確であるためである。もちろん、医者が必要な個人医療情報の分野を直接指定しても良い。特に再診の場合は、病院１０２内のコンピュータ１０３が判断するのではなく医者が個人医療情報の分野の特定を行うと良い。
【００２７】
個人医療情報の分野の特定が終了すると、病院１０２内のコンピュータ１０３は、患者ＩＤを基に患者の個人医療情報ＩＤを検索する（ステップＳＴ２００）。そして、病院１０２内のコンピュータ１０３は、サーバ１０４に対して個人医療情報ＩＤと特定された分野の個人医療情報のダウンロード要求を行う（ステップＳＴ２０１）。個人医療情報のダウンロード要求を受けたサーバ１０４は、個人医療情報ＩＤから患者の電子メールアドレスを検索する。そして、サーバ１０４は、ダウンロード要求に応じて病院１０２内のコンピュータ１０３に個人医療情報を送信（提供）して良いかを確認する電子メールを患者１００へ送信する（ステップＳＴ３００）。個人医療情報ＩＤと患者の電子メールアドレス等の患者１００の個人情報はサーバ１０４のデータベースにあらかじめ登録されている。電子メールを受信した患者１００は個人端末１０１を用いて例えば電子メールで送信許可を返す（ステップＳＴ１０１）。このステップＳＴ３００、ＳＴ１０１の工程は、セキュリティーを高めるためには好適である。しかし、個人端末１０１を持たない患者１００に対して実現ができない点、患者１００操作が複雑になる点から、この工程を省略してもかまわない。後述する診断履歴により、セキュリティーを高めることは可能である。
【００２８】
個人医療情報の送信許可を受けたサーバ１０４は、ダウンロード要求に含まれる「個人医療情報ＩＤ」と「分野」に対応する個人医療情報をデータベースから取得し、病院１０２内のコンピュータ１０３に送信する（ステップＳＴ３０１）。特定された分野の個人医療情報のデータをサーバ１０４が容易に抽出できる様に、個人医療情報が例えば以下に示す様なファイル構造（データ構造）を持つと良い。すなわち、個人医療情報は情報毎にフォルダが分けられ、フォルダ内に個人医療情報のデータとその個人医療情報の内容を示すファイル（情報タグファイル）を記憶していると好適である。この個人医療情報の内容を示すファイル（情報タグファイル）は、特定された分野の情報を簡単に検索・抽出できるようにするためのインデックスということができる。
【００２９】
図７は、情報タグファイルの一例である。この例では、情報タグファイルの中に、個人医療情報に伴う情報が格納されている。このファイルをサーバ１０４は読み込み該当する症状、病名、部位等の内容から、特定された分野の個人医療情報かどうかを判断する。具体的な一例として、科名が「消化器内科」、かつ、病名が「胃がん」という分野であれば、情報タグファイル（図７）の医療情報項目毎に比較し、科名と病名が合致した場合に、該当する個人医療情報を選択する。このように医療情報項目毎に比較し個人医療情報を適宜選択する。症状、病名、部位による分野の特定ついて具体的に説明したが、例えば、「
『２０００年以降』ＡＮＤ『Ａ病院での検査』」と言う様な分野の特定も可能である。また、この例で示した様に、ＡＮＤやＯＲなどの論理演算子を使用して細かな条件も設定可能である。図７の表は一例であり、情報タグファイルが個人医療情報を特定するその他の情報を含んでいるとより好適である。
【００３０】
患者の個人医療情報を病院１０２内のコンピュータ１０３が受信（ダウンロード）終了すると（ステップＳＴＳ２０２）、病院１０２内のコンピュータ１０３は患者１００の個人端末１０１へネットワーク（ＷＡＮ）を介して、予約の許諾と診療日時を送信する。個人端末１０１を使用できない患者は従来通り病院１０２のオペレータが代行して予約の許諾と診療日時を患者１００に電話等で伝える（ステップＳＴ２０３）。前述したバーチャルスライドの画像データの様な大きなデータではダウンロード時間が非常に長くかかる可能性がある。このような場合は、コンピュータ１０３がダウンロードすべきデータ量に基づき個人医療情報のダウンロード終了予定日時を推定し、終了予定日時以降の診療であれば予約を許諾しても良い。つまり、診療日時より前にダウンロードが終了する見込みがついた場合であれば予約を許諾しても良い。ダウンロードすべきデータ量の計算や、ダウンロード時間の推定は、サーバ１０４が行っても良い。
【００３１】
予約日時に患者は来院し、患者ＩＤを病院１０２の受付に提出して診療順番待ちをする（ステップＳＴ１０２）。前述した様に、この時、患者１００は自分の個人医療情報の暗号キーも提示する。病院１０２内のコンピュータ１０３は暗号キーを用い個人医療情報を復号する（ステップＳＴ２０４）。復号が終わると、医者は個人医療情報を閲覧し患者１００を診療する（ステップＳＴ１０３、ステップＳＴ２０５）。診療時に取得あるいは変更した個人医療情報は、暗号キーにより暗号化される（ステップＳＴ２０６）。そして、コンピュータ１０３は、暗号化された新たな個人医療情報を、情報タグファイルを付加しサーバ１０４に送信（アップロード）する。この際、診療の情報（診療日、診療費、ダウンロードしたファイルのリスト等）も個人医療情報として同時に送信する（ステップＳＴ２０７）。この診療の情報については特に診療履歴情報と呼び、わかりやすいように区別して以降説明する。診療履歴情報も個人医療情報の一種であり、同じフォーマット、すなわち、情報タグファイルと関連のファイルで構成される。診療履歴情報の情報タグファイルの一例を示す表を図８に示す。
【００３２】
サーバ１０４は新たな個人医療情報と診療履歴情報を受信すると、それらを個人医療情報ＩＤに対応する情報としてデータベースに格納する（ステップＳＴ３０２）。データベースは、大容量のファイルサーバで構成されていると良い。一方、診療が終了した患者１００は帰宅する（ステップＳＴ１０４）。病院１０２内のコンピュータ１０３は患者１００に診療履歴を送信する（ステップＳＴ２０８）。患者１００に送る診療履歴は、診療履歴情報の一部あるいは全部、すなわち少なくとも、診療日、病院名を含み、さらに、医者氏名、診療内容、処方箋、ダウンロードデータ内容、診療費用を含むと好適である。
【００３３】
診療が終了した後、病院１０２内のコンピュータ１０３の記憶装置に記憶されている個人医療情報を速やかに消去し、病院１０２内のコンピュータ１０３の記憶装置の空き容量を確保すると良い。また別の方法としては、症状が不安定な患者については再診を予想して例えば医者が病院１０２内のコンピュータ１０３の記憶装置の保存期間を指定しその後に消去すると良い。さらに別な方法によれば、病院１０２内のコンピュータ１０３の記憶装置の容量をある一定値以上確保するように、古い個人医療情報から自動的に消去しても良い。以上説明した方法によって、病院１０２内のコンピュータ１０３の記憶装置の空き容量を確保することが可能となる。
【００３４】
（個人医療情報の暗号キー）
本発明の第１の実施形態の個人医療情報の暗号キーは、例えば個人が記憶しているパス
ワードや、暗号キー情報が磁気や光学パターンないしは半導体チップに記録されているＩＤカードであってもよい。後述するように、生体認証と言われている、指紋や網膜の血管パターンや虹彩パターンの濃淡値のヒストグラムを暗号キーとする方式などがより好ましい。
【００３５】
また、個人医療情報の暗号キーは、受診申し込み時（ステップＳＴ１００）に、個人医療情報ＩＤと共に、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４に送っても良い。さらに、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４や病院１０２内のコンピュータ１０３にあらかじめ暗号キーを預けて（登録して）おいても良い。このようにすることによって、患者１００が来院する以前に、患者１００の暗号化された個人医療情報を復号できる。すなわち患者１００が来院した際の待ち時間を少なくすることが可能となる。個人医療情報の暗号キーを病院１０２（のコンピュータ）や、病院１０２外部のサーバにに預けておくことにより患者が暗号キーを持たず（覚えておかずに）に暗号を復号できる。後述するように救急患者に対応して個人医療情報をダウンロードする際、有効である。この場合、特定された病院、サーバ以外に暗号キーを取り扱えない様にすることでセキュリティーの向上を実現すると良い。
【００３６】
以上説明してきたように、第１の実施形態では、患者１００の受診要求に応じて、病院１０２外部のサーバ１０４からネットワーク（ＷＡＮ）を介して患者１００の個人医療情報を病院１０２内部のコンピュータ１０３の記憶装置に取得（ダウンロード）する。このとき、診療に必要な個人医療情報の分野を特定してダウンロード要求を行い、患者の個人医療情報の中から必要な情報（一部の情報）のみをダウンロードできるので、ダウンロードするデータ量を削減できる。これにより、ネットワークのトラフィックを少なくし、ダウンロード時間を短縮する効果がある。そして、ダウンロードが終了した場合、あるいは診療日時より前にダウンロード終了見込みである場合に、受診予約を許諾するので、病院１０２外部のネットワーク（ＷＡＮ）の混み方によらず、診療開始時には個人医療情報が閲覧可能な状態にあることを保証できる。例えば、前述したようなバーチャルスライドの画像データでは、１枚のスライド当たり約２０分のダウンロード時間が必要である。本実施形態のシステムではこの時間は患者が来院する前に終了するので、医者及び患者１００にとって受診時の持ち時間を少なくするという効果を有する。さらに、医者が患者の個人情報を閲覧する時間及び診療する時間が増え、診療の精度が向上する間接的な効果も有する。
【００３７】
＜第２の実施形態＞
第１の実施形態では、患者が病院を決定して、決定した病院に対して直接受診を申し込む場合に有効な方法である。本発明の第２の実施形態は、患者が病院を決定せずに、病院外部のネットワーク（ＷＡＮ）上のサーバに対して受診申し込みを行い、サーバが患者の症状等から病院を決定し予約する方法である。
【００３８】
第２の実施形態を実現する処理フローの詳細を記す前に、第２の実施形態のシステムの動作の理解のために、図１１（ａ）〜図１１（ｃ）を用いて第２の実施形態の概要を説明する。
【００３９】
図１１（ａ）〜図１１（ｃ）は本発明の第２の実施形態の工程を模式的に示した図である。図１１（ａ）に示すように、患者１００は病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４に対して受診申し込みを行う（Ｐ１）。この受診申し込みは、例えば患者１００の個人端末１０１からサーバ１０４に対して、不図示の広域ネットワーク（ＷＡＮ）を介して行う。受診申し込みの際、希望する病院の地域と対象部位や症状等を患者１００の個人端末１０１からサーバ１０４に対して申告する。
【００４０】
次に、サーバ１０４は、患者１００の希望する病院の地域と、対象部位や症状等から、病院を決定する（Ｐ２）。病院の決定方法は後述する。サーバ１０４が病院１０２を決定すると、サーバ１０４は決定した病院１０２内のコンピュータ１０３に対して受診申し込みを行う（Ｐ３）。この際、症状・対象部位等の情報も送る。受診申し込みを受けた病院１０２内のコンピュータ１０３は受診可能かを判断する。受診可能であれば、コンピュータ１０３は症状や対象部位等の情報に基づき必要な個人医療情報の分野を特定し、サーバ１０４に特定した分野の個人医療情報のダウンロード要求を行う（Ｐ４）。次に、サーバ１０４は病院１０２内のコンピュータ１０３へ、個人医療情報ＩＤと特定された分野の個人医療情報を送信する（Ｐ５）。個人医療情報の受信（ダウンロード）が終了すると、コンピュータ１０３はサーバ１０４へ予約日時、診療科名を送信する（Ｐ６）。コンピュータ１０３から受信許諾を受けたサーバ１０４は患者１００の個人端末１０１に対して受診許諾の返事を返す（Ｐ７）。病院名、診療科名、診療日時を同時に送るとよい。
【００４１】
次に図１１（ｂ）に示した様に、受診許諾を受けた患者１００は、病院１０２に行き、患者ＩＤと個人医療情報の暗号キーを病院１０２の受付に提示又は提出する（Ｐ８）。暗号キーについては第１の実施形態で説明しているので詳細は省略する。初診であれば、病院は患者ＩＤを新規に作成する。一方、病院１０２内のコンピュータ１０３は暗号キーを用い個人医療情報を復号する（Ｐ９）。そして、医者は復号された個人医療情報を閲覧し患者１００を診療する（Ｐ１０）。その後患者は帰宅する。
【００４２】
診療が終了すると、コンピュータ１０３は、変更または新たに得た個人医療情報を患者１００の暗号キーで暗号化し、図１１（ｃ）に示した様にサーバ１０４にアップロードする（Ｐ１１）。その結果、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４には暗号化された個人医療情報が蓄積される。さらにサーバ１０４は、患者１００に今回の診療に関する診療履歴を電子メール等で送信する（Ｐ１２）。
【００４３】
（処理フロー）
次に、図２のフローチャートを用いて、本発明の第２の実施形態を実現するための処理フローを説明する。図２のフローを実行するためのハードウエアは、公知のネットワークやサーバやコンピュータや個人端末により構成することができる。以下に述べる本システムの機能は、これらの公知のハードウエア上で実行されるソフトウエアにより実現することができる。図２において、それぞれのフローチャートは図１と同様に、左から、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４、病院１０２内部のコンピュータ１０３、患者１００の工程を示す。
【００４４】
初めに、患者１００は個人端末１０１からサーバ１０４に受診申し込みを行う（ステップＳＴ１１０）。この際、患者１００は、予約に必要な情報も一緒にサーバ１０４に送る。予約に必要な情報の例として、患者の氏名、年齢、個人医療情報ＩＤ、希望する病院の地域、患者の症状・対象部位等である。サーバ１０４は、例えば受診の予約を受け付けるウェブサイトを提供しており、患者１００はこのウェブサイトに個人端末１０１を用いアクセスし、予約に必要な情報を書き込む。ウェブサイトの予約受付画面は、予約に必要な情報の入力が容易なユーザーインターフェイスを持つと好適である。このユーザーインターフェイスは第１の実施形態で示した病院１０２のコンピュータ１０３に受診申し込みを行う際のユーザーインターフェイスと共通であると、患者は受診申し込みの手順に迷うことが無いので好適である。
【００４５】
次に、サーバ１０４は、患者１０２の希望する病院の地域と症状・対象部位から、病院や診療する科を決定する。そして、決定された病院１０２内のコンピュータ１０３に対してサーバ１０４が受診申し込みを行う（ステップＳＴ３１０）。受診申し込みを行う際、サーバ１０４は、患者の氏名、年齢、個人医療情報ＩＤ、患者の症状・対象部位等を病院
１０２内のコンピュータ１０３に送信する。受診申し込みを受けた病院１０２内のコンピュータ１０３は受診可能かを判断する。受診可能であれば、コンピュータ１０３は、第１の実施形態で説明した様に、症状や部位等に基づき必要な個人医療情報の分野を特定し、患者が初診であれば患者ＩＤを発行する（ステップＳＴ２１０）。そして、コンピュータ１０３は、サーバ１０４に対し、特定した分野の個人医療情報のダウンロード要求を行う（ステップＳＴ２１１）。そして患者ＩＤと個人医療情報ＩＤとの関連が付けられる。以降の診療の際は、患者ＩＤから個人医療情報ＩＤを指定することが可能となる。診療に必要な分野を特定する方法は第１の実施形態で説明したので、説明は省略する。
【００４６】
サーバ１０４は特定された分野の個人医療情報を病院１０２内のコンピュータ１０３に送信する（ステップＳＴ３１１）。そして、病院１０２内のコンピュータ１０３は、特定された分野の個人医療情報を受信（ダウンロード）する（ステップＳＴ２１２）。病院１０２内のコンピュータ１０３は、個人医療情報のダウンロードを完了したら、サーバ１０４に予約許諾を送信する。バーチャルスライドの画像データの様な大きなデータではダウンロード時間が非常に長くかかる場合がある。このような場合は、コンピュータ１０３が、前述した様に個人医療情報のダウンロード終了予定日時を推定し、終了予定日時とともに予約許諾をサーバ１０４に送信しても良い。そして同時に、コンピュータ１０３はサーバ１０４に診療科名、診療日時も送る（ステップＳＴ２１３）。サーバ１０４は、患者１００の個人端末１０１へネットワーク（ＷＡＮ）を介して、予約の許諾と、病院名、診療科名、診療日時を送信する（ステップＳＴ３１２）。サーバ１０４がステップＳＴ２１３でダウンロード終了予定日時と予約許諾を受信した場合は、診療日時はダウンロード終了予定日時以降の日時に設定する。
【００４７】
予約日時に患者は来院し、診療順番待ちをする（ステップＳＴ１１１）。第１の実施形態同様に、来院時、患者１００は個人医療情報の暗号キーも提示する。病院１０２内のコンピュータ１０３は暗号キーを用い暗号化された個人医療情報を復号する（ステップＳＴ２１４）。暗号キーについては、第１の実施形態で説明した様に、生体認証と言われている暗号キーとしても良いし、サーバ１０４や病院１０２内のコンピュータ１０３にあらかじめ預けておいても良い。復号が終わると、医者は個人医療情報を閲覧し患者１００を診療する（ステップＳＴ１１２、ステップＳＴ２１５）。
【００４８】
診療時に取得あるいは変更した個人医療情報は、患者１００の暗号キーにより暗号化される（ステップＳＴ２１６）。そして、コンピュータ１０３は、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４に、暗号化された新たな個人医療情報を、情報タグファイルを付加して送信する。この際、診療の情報（診療日、診療費、ダウンロードしたファイルのリスト等）を診療履歴情報として同時に送信する（ステップＳＴ２１７）。前述した様に、診療履歴情報も個人医療情報と同じフォーマットから成り、情報タグファイルと関連のファイルで構成される。
【００４９】
サーバ１０４は新たな個人医療情報と診療履歴情報を受信すると、それらを個人医療情報ＩＤに対応する情報としてデータベースに格納する（ステップＳＴ３１３）。一方、診療が終了した患者１００は帰宅する（ステップＳＴ１１３）。サーバ１０４は患者１００に診療履歴を送信する（ステップＳＴ３１４）。患者１００に送る診療履歴は、診療履歴情報の一部あるいは全部、すなわち少なくとも、診療日、病院名を含み、さらに、医者氏名、診療内容、処方箋、ダウンロードデータ内容、診療費用を含むと好適である。
【００５０】
第１の実施形態同様に、診療が終了した病院１０２内のコンピュータ１０３の記憶装置に記憶されている個人医療情報は速やかに消去し、病院１０２内のコンピュータ１０３の記憶装置の空き容量を確保すると良い。また別の方法としては、症状が不安定な患者については再診を予想して例えば医者が病院１０２内のコンピュータ１０３の記憶装置の保存
期間を指定しその後に消去すると良い。さらに別な方法によれば、病院１０２内のコンピュータ１０３の記憶装置の容量をある一定値以上確保するように、古い個人医療情報から自動的に消去しても良い。以上説明した方法によって、病院１０２内のコンピュータ１０３の記憶装置の空き容量を確保することが可能となる。
【００５１】
（個人医療情報の分野の特定方法）
前述した様に、個人医療情報の分野の特定は病院１０２内のコンピュータ１０３が行う場合を一例として示した（ステップＳＴ２１０）。第２の実施形態の他の方法として、ステップＳＴ２１０において受診申し込みを受けた病院１０２内のコンピュータ１０３の表示画面に患者の症状、対象部位等を表示し、表示された情報を基に医者が判断し、個人医療情報の分野を特定しても良い。また別の方法としては、サーバ１０４がステップＳＴ３１０で、第１の実施形態で説明した病院１０２内のコンピュータ１０３で行ったアルゴリズムと同等のアルゴリズムを用い個人医療情報の分野の特定を行い、ステップＳＴ２１０で病院１０２のコンピュータ１０３は受診可能かの判断のみを行い受診の許諾を返す。そして、ステップＳＴ３１１においてステップＳＴ２１０で特定した分野の個人医療情報を送信するフローであっても良い。
すなわち、個人医療情報の特定は病院１０２内のコンピュータ１０３や医者や病院１０２外のネットワーク（ＷＡＮ）上のサーバ１０４いずれで行っても良い。
【００５２】
（病院の決定方法）
サーバ１０４は、患者１００の希望する病院の地域と症状・対象部位から、例えば以下の様に病院を決定する。
第一の方法として、症状が重いと患者が申告した場合は、自宅からの距離よりも病院の規模等を優先する。一方、症状が軽い時は病院の規模よりも患者の自宅からの距離を優先し、患者の自宅に近い病院を決定する。
第二の方法としては、サーバ１０４が、患者の希望する地域内に存在し、且つ、患者の症状や部位に対応する診療科のある病院を全てリストアップし、患者に対して病院のリストを提示する方法がある。この場合は、患者自身がリストの中から受診する病院を決定する。
第三の方法としては、第一の方法と第二の方法を組み合わせた方法がある。例えば、症状が重いと患者が申告した場合は、第二の方法と同様に全ての病院をリストアップし、患者に対して病院のリストを提示し、患者に病院を決定させる。一方、症状が軽い時は病院の規模より患者の自宅からの距離を優先し、患者の自宅に近い病院に決定する。
【００５３】
病院の決定方法は、上記の中から１つの方法を採用してサーバ１０４が実行しても良い。更に別の方法としては、上述した複数の病院の決定方法の中から患者に病院の決定方法を選択させても好適である。この場合、サーバ１０４は受診の予約を受け付けるウェブサイトの中で、受診予約画面で患者１００がメニュー形式で病院の決定方法の選択ができるようにすると好適である。もちろん、他の病院決定方法を用いても良い。
【００５４】
以上説明した第２の実施形態においても、第１の実施形態と同様の効果が得られる。すなわち、患者の個人医療情報の中から診療に必要な分野に関わる一部の情報のみをダウンロードできるので、ダウンロードするデータ量を削減でき、これにより、ネットワークのトラフィックを少なくし、ダウンロード時間を短縮する効果がある。また、病院１０２外部のネットワーク（ＷＡＮ）の混み方によらず、診療開始時には個人医療情報が閲覧可能な状態にあることを保証でき、医者や患者の待ち時間を少なくする効果がある。
【００５５】
更に、第２の実施形態は、第１の実施形態と異なり、患者１００の症状、対象部位、住所等に応じて適切に病院を決定する機能をサーバ１０４が持つ。その結果、患者１００は適切な病院で診療を受けることが可能となる。サーバ１０４によって選ばれた病院が患者
１００が診療を受けたことのない病院である、つまり初診となるケースが多くなる可能性があるが、本実施形態によれば、医者は診療に必要な個人医療情報を入手し閲覧できるので、正確な診療が可能となる。さらに医者は他の病院で作成された個人医療情報を閲覧できるので、不必要な検査を行う必要が無くなる。例えば、病院毎に同じ患部のＸ線撮影を行う等の無駄な被ばくを抑えることや、検査に伴う費用の削減が可能となる。したがって、患者１００は、サーバ１０４によって選ばれた初めての病院であっても、何らの不利益なく受診することが可能となる。結果として、病気の症状に対して複数の医者からの診断を受けることが可能になり（セカンドオピニオンとも言う）、患者にとって疾病の正確な把握が可能となる効果や、見落とされがちな疾病の発見等が可能となる間接的な効果も期待できる。
【００５６】
＜第３の実施形態＞
次に、本発明の第３の実施形態の説明をする。第３の実施形態は、第１の実施形態、第２の実施形態と異なり、患者が自分の意思で予約できない様な緊急時に有効な方法である。
第３の実施形態を実現する処理フローの詳細を記す前に、第３の実施形態のシステムの動作の理解のために、図１２（ａ）〜図１２（ｃ）を用いて第３の実施形態の概要を説明する。
【００５７】
図１２（ａ）〜図１２（ｃ）は本発明の第３の実施形態の工程を模式的に示した図である。第３の実施形態では、患者は救急車等で搬送されてきた救急患者である。図１２（ａ）に示すように、初めに、患者１００は病院１０２に救急車等で搬送される（Ｐ１）。この時多くの場合は、患者自身が第１の実施形態や第２の実施形態で説明した様な受診申し込みをすることはできない。場合によっては患者１００の意識がない場合もある。この場合、病院１０２の医者や看護師や救急車に同乗している救命士が、必要な患者の個人医療情報の分野を特定し、特定された分野の個人医療情報のダウンロード要求を行う（Ｐ２）。この時、患者１００の症状から、個人医療情報のダウンロード要求の優先度（緊急度）を医者や看護師あるいは救命士が決定し付加する。サーバ１０４は優先度に応じて個人医療情報を病院１０２内のコンピュータ１０３に送信（ダウンロード）する（Ｐ３）。優先度の具体的な方法については後述する。
【００５８】
患者１００が病院に到着する（図１２（ｂ））と、患者が初診となる病院であれば、患者ＩＤを新規に作成する。一方、病院１０２内のコンピュータ１０３は暗号キーを用い暗号化された個人医療情報を復号する（Ｐ４）。前述したように、このような場合、暗号キーが、個人が記憶しているパスワードや、磁気や光学パターンないしは半導体チップに記録されているＩＤカードである場合、役に立たないことが多くある。例えば、患者の意識がない場合は記憶しているパスワードは暗号キーとして役に立たない。ＩＤカードは緊急の場合、患者が持っていないこともあり、使用できない場合もある。一方、生体認証による暗号キーでは患者の意識がなくとも暗号キーとして機能する。そのため、生体認証による暗号キーが望ましい。また、前述した様に、個人医療情報の暗号キーを病院１０２（のコンピュータ）や、病院１０２外部のサーバに預けておくことにより患者の暗号キーを使用せず暗号を復号できるので、このような緊急時は、好適である。そして、復号された個人医療情報を閲覧し、医者は患者１００を診療する（Ｐ５）。その後患者は帰宅する。
【００５９】
診療が終了すると、コンピュータ１０３は、図１２（ｃ）に示した様に変更または新たに得た個人医療情報を患者の暗号キーで暗号化し、サーバ１０４にアップロードする（Ｐ６）。その結果、サーバ１０４には暗号化された個人医療情報が蓄積される。さらにサーバ１０４は、患者１００に今回の診療に関する診療履歴を電子メール等で送信する（Ｐ７）。
【００６０】
（処理フロー）
次に、図３のフローチャートを用いて、本発明の第３の実施形態を実現するための処理フローを説明する。図３のフローを実行するためのハードウエアは、公知のネットワークやサーバやコンピュータや個人端末により構成することができる。以下に述べる本システムの機能は、これらの公知のハードウエア上で実行されるソフトウエアにより実現することができる。図３において、それぞれのフローチャートは図１と同様に、左から、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４、病院１０２内部のコンピュータ１０３、患者１００の工程を示す。
【００６１】
初めに、患者１００が救急車等で病院１０２に搬送される（ステップＳＴ１２０）。医者（看護師や救命士でも良い）は患者１００の症状や傷病の部位から必要な個人医療情報の分野の特定を行い、優先度を決定する（ステップＳＴ２２０）。医者（看護師、救命士）は病院１０２内のコンピュータ１０３を用い、特定した分野の個人医療情報をサーバ１０４に対して要求する（ステップＳＴ２２１）。このとき、ダウンロード要求に優先度（緊急度）の情報が付加される。
【００６２】
この様な緊急時には、救急患者の個人医療情報ＩＤが解らない場合がある。したがって、例えば、患者の住所、名前、性別や運転免許証等の番号等の救急患者の何らかの個人情報から、該当する個人医療情報ＩＤを特定する方法がより好適である。この場合、救急患者の個人情報に、個人医療情報ＩＤの要求を行う医者や看護師や救命士のＩＤを添えて、サーバ１０４に照会要求をする。サーバ１０４は、あらかじめ登録されている医者や看護師や救命士のＩＤに対してパスワードを要求しパスワードが正しければ、患者の個人医療情報ＩＤを出力する様にすることによって、セキュリティーを高めることができる。また、サーバ１０４の送信先をあらかじめ登録してある病院のみに限定することによって、セキュリティーを向上させるとより好適である。
【００６３】
また、図３で示したフローと異なるが、より緊急の場合は救命士が救急車に車載されている端末や携帯型の端末によって、患者の個人医療情報のダウンロード要求をサーバ１０４に対して行うと更に好適である。医者が行う工程同様に、患者の症状から必要な個人医療情報の分野を特定し、優先度を付加したダウンロード要求を行う。もちろん、救命士は携帯電話等で医者の助言を受けながらこれらの工程を行うと好適である。
【００６４】
サーバ１０４は優先度に応じた処理速度（ダウンロード時間）で個人医療情報を病院に送信する（ステップＳＴ３２０）。そして、病院１０２内のコンピュータ１０３は特定した分野の個人医療情報を受信する（ステップＳＴ２２２）。サーバ１０４が特定された分野の個人医療情報を送る方法については第１の実施形態で説明したとおりであるので、説明は省略する。優先度についての具体的な説明は後述する。
【００６５】
患者の個人医療情報を受診した病院１０２内のコンピュータ１０３は、患者の暗号キーにより暗号を復号する（ステップＳＴ２２３）。これにより診療の準備が整う。これ以降の処理（ステップＳＴ２２４〜ＳＴ２２６、ＳＴ１２１、ＳＴ１２２、ＳＴ３２１、ＳＴ３２２）は第２の実施形態の処理（図２のステップＳＴ２１５〜ＳＴ２１７、ＳＴ１１２、ＳＴ１１３、ＳＴ３１３、ＳＴ３１４）と同様のため説明を省略する。
【００６６】
上述した実施形態では、医者（看護師）あるいは救命士が救急患者の個人医療情報の分野を特定し個人医療情報のダウンロードを要求した。他の好適な実施形態としては、患者の個人医療情報のリスト（情報タグファイル一覧）を表示し、その中から必要な情報を選択的にダウンロードできるようなユーザーインターフェイスをもつウェブサイトを、サーバ１０４が提供しても良い。医者や看護師や救命士がそのウェブサイトにアクセスし、診療に必要な個人医療情報を選択するとともに優先度を指定し、ダウンロードを行うことが
できれば、個人医療情報の分野の指定が容易となる。
【００６７】
（優先度付加時の動作）
次に、優先度と優先度付加時の処理フローについて詳細に説明する。前述したように、医者（あるいは看護師、救命士）は、患者の症状等に基づいて必要であると思われる個人医療情報の分野を特定する。同時に患者の症状等から、個人医療情報の取得の優先度（優先順位）を決定する。一例として、優先度を３〜１のランクで付加する。ランク３は例えば危篤等の非常に切迫した状態であり、他の個人医療情報の送信の処理（ダウンロード）に優先して実行する要求を示す。ランク２は重体等の切迫した状態であるので、ランク３以外の個人医療情報の送信の処理（ダウンロード）に優先して実行する要求を示す。ランク１は重症であり、優先度が付加されていない一般の個人医療情報の送信の処理（ダウンロード）に優先して実行する要求を示す。このように設定した優先度をダウンロード要求に付加してサーバ１０４に送信する。要求を受けたサーバ１０４は優先度のランクに応じて、例えば処理タスクの時間を多く割り振り、ランクの高い処理を優先して実行する。
【００６８】
具体例を説明する。一般の個人医療情報の送信のタスクに割り当てる時間をＴ０、ランク１の個人医療情報の送信のタスクに割り当てる時間をＴ１とする。同様に、ランク２のタスクに割り当てる時間をＴ２、ランク３のタスクに割り当てる時間をＴ３とする。この時、例えば、
Ｔ３＝４×Ｔ０
Ｔ２＝３×Ｔ０            ・・・式６）
Ｔ１＝２×Ｔ０
の関係になる様にタスクに割り当てる時間を決定すると良い。
【００６９】
また別の例として、
Ｔ３＝８×Ｔ０
Ｔ２＝４×Ｔ０            ・・・式７）
Ｔ１＝２×Ｔ０
の様に決定しても良い。
【００７０】
一般化すると、ｋ１、ｋ３、ｋ３を定数とすれば
Ｔ３＝ｋ３×Ｔ０
Ｔ２＝ｋ２×Ｔ０          ・・・式８）
Ｔ１＝ｋ１×Ｔ０
ここで、
ｋ３≧ｋ２≧ｋ１≧１      ・・・式９）
である。係数ｋ１、ｋ２、ｋ３を適宜設定し優先度のランク（つまり優先度の高さ）に応じてタスクへの割り当て時間を調整することにより、優先度の高い個人医療情報の送信に要する時間を少なくすることができる。このとき、係数ｋ１〜ｋ３を大きい値に設定するほど、優先度合いを高め、ダウンロード時間を短縮することができる。また、ｋ３＝ｋ２のように係数の値を同じにすれば、対応する２つのランク（この例ではランク３とランク２）の優先度合いを同じにすることができる。
【００７１】
このようにすることによって、優先度が設定されない一般の患者に比べて、優先度が設定された患者の個人医療情報を優先して取得できるので、救急患者に対して、より短時間に個人医療情報を取得することが可能となる。その結果、より迅速な診療を医者は行うことができる効果がある。もちろん、一般の病院予約する患者にはこの優先度は設定できないようにすると良い。
【００７２】
優先度の別の例として、医者（あるいは看護師、救命士）が患者の個人医療情報を必要
とする時刻そのものを優先度として設定する方法であっても良い。例えば重症の患者であっても、過去の個人医療情報が診療に有効で無い場合には、緊急に個人医療情報を得る必要はない。また、医者や設備の準備等の関係で実際に診療にとりかかるまで時間が空いてしまう場合、急いで個人医療情報を得る必要性は低い。個人医療情報が必要となる時刻そのものを優先度とし、これに基づいて処理の優先度を決定する方法は、このような場合に有効な方法である。
サーバ１０４は、必要となる時刻が現在の時刻に近いものを優先して処理を行う。前述したように、一般の受診予約する患者にはこの優先度は設定できないようにし、サーバ１０４は優先度の無い要求に対しては優先度を下げて処理する。
【００７３】
個人医療情報が必要となる時刻を優先度に利用する方法は非常に好適ではあるが、例えば医者が多忙の場合うっかり時刻を間違えて設定してしまう可能性がある。この対策として、個人医療情報が必要となる時刻のかわりに、個人医療情報のダウンロードに割り当てられる時間（つまり可能な待ち時間）を、医者に指定させる方法と採ると好適である。この場合、例えば病院１０２内のコンピュータ１０３は、現在の時刻に医者が要求するダウンロードに割り当てられる時間（可能な待ち時間）を加えた時刻を、個人医療情報が必要となる時刻とみなし、その時刻を優先度情報としてサーバ１０４に送信する。この場合も、サーバ１０４は個人医療情報が必要となる時刻が現在の時刻に近いものを優先して処理を行う。
【００７４】
より具体的には、患者の個人医療情報が必要となる時刻をｔｒ（優先度）、現在時刻をｔｎとし、一般の個人医療情報の送信のタスクに割り当てる時間をＴ０、優先度ｔｒの個人医療情報の送信のタスクに割り当てる時間をＴとすれば、
（ｔｒ−ｔｎ）≦ｔｍｉｎの場合：
Ｔ＝｛ｔｍａｘ／ｔｍｉｎ｝ｐ×Ｔ０
ｔｍｉｎ＜（ｔｒ−ｔｎ）≦ｔｍａｘの場合：
Ｔ＝｛ｔｍａｘ／（ｔｒ−ｔｎ）｝ｐ×Ｔ０
ｔｍａｘ＜（ｔｒ−ｔｎ）の場合：
Ｔ＝Ｔ０
と動的に決定する。ここで、ｔｍａｘ、ｔｍｉｎ（ｔｍｉｎ＜ｔｍａｘ）、ｐは設計者が決定する定数である。このような関係により、個人医療情報の送信のタスクに割り当てる時間Ｔを決定することによって、必要となる時刻が迫っている個人医療情報ほどダウンロード時間を短縮することができる。
【００７５】
上記の説明では、サーバ１０４がシングルプロセッサであるとし、タスクに割り当てる時間でタスクの処理速度を変える例を示した。サーバ１０４がマルチプロセッサや複数のコンピュータで構成されている場合は、前述したタスクの割り当て時間を、割り当てられるＣＰＵの数と時間等で決まる個人医療情報の送信のタスクに割り当てるリソースと考えればよい。
【００７６】
本実施形態によれば、救急患者を診療する医者は個人医療情報を閲覧して診療を行うことができるため、より正確な診療が可能となる。しかしながら、ダウンロード終了時刻が遅い場合は、救急患者に対して個人医療情報の閲覧することなく診療を進めなくてはならない。そのため、救急患者を診療する医者がダウンロード終了予定時刻を知ることができると望ましい。このような状況に対応するため、サーバ１０４あるいは病院１０２内のコンピュータ１０３は現在までのデータ転送速度から、ダウンロードが終了する時刻を推定し、推定時刻を表示する機能を有するとより良い。
【００７７】
このように、第３の実施形態は一般の患者の受診予約とは異なり緊急時に医者あるいは看護師、救命士が優先度を直接設定してサーバ１０４に個人医療情報のダウンロード要求
を行う。その結果、優先度が設定されていない一般の個人医療情報のダウンロード要求に対して、優先度が設定された緊急の個人医療情報のダウンロード要求が優先される。更に優先度が設定されたダウンロード要求に対して、サーバ１０４は優先度に応じて処理時間を割り振り、優先度の高い要求に対しては短時間にダウンロード処理を終了できるようにすることが可能となる。
【００７８】
第３の実施形態は、第１の実施形態や第２の実施形態の予約システムに機能を付加する形で実現できる。第１の実施形態や第２の実施形態の予約システムのユーザーインターフェイスに、個人医療情報のダウンロード要求時に優先度を指定する機能を追加すればよい。そして、サーバ１０４は優先度に従って個人医療情報のダウンロード要求に答えることによって、一般の患者の個人医療情報よりも、救急患者の個人医療情報を優先的にダウンロードできる仕組みが実現できる。
【００７９】
以上説明した第３の実施形態においても、第１の実施形態と同様の効果が得られる。すなわち、患者の個人医療情報の中から診療に必要な分野に関わる一部の情報のみをダウンロードできるので、ダウンロードするデータ量を削減でき、これにより、ネットワークのトラフィックを少なくし、ダウンロード時間を短縮する効果がある。また、少なくとも一般の受信予約患者に対しては、病院１０２外部のネットワーク（ＷＡＮ）の混み方によらず、診療開始時には個人医療情報が閲覧可能な状態にあることを保証でき、医者や患者の待ち時間を少なくする効果がある。
【００８０】
更に、第３の実施形態は、救急患者を受け入れた病院はその個人医療情報をサーバ１０４から優先的に入手でき、その結果、救急患者に対して迅速な診療が行える効果がある。これにより、緊急の場合は、データ量の大きい個人医療情報であっても可能な限りダウンロード時間の短縮が可能になる。その結果、救急患者であっても、優先度に従った少ない待ち時間で医者が患者の個人情報を閲覧することが可能となり、診療に時間をかけることが可能となり、救急患者に対する診療の精度が向上する間接的な効果がある。
【００８１】
＜第４の実施形態＞
次に、本発明の第４の実施形態の説明をする。第４の実施形態は、第１の実施形態、第２の実施形態と異なり、個人が自分の健康状態を確認するために、自分の個人医療情報をダウンロードする方法である。
第４の実施形態を実現する処理フローの詳細を記す前に、第４の実施形態のシステムの動作の理解のために、図１３（ａ）〜図１３（ｂ）を用いて第４の実施形態の概要を説明する。
【００８２】
図１３（ａ）〜図１３（ｂ）は本発明の第４の実施形態の工程を模式的に示した図である。第４の実施形態では、個人（傷病を負った患者では無い）が個人医療情報のダウンロード要求をする。図１３（ａ）において、１１０は傷病を負っていない個人を示す。初めに、個人１１０はネットワーク（ＷＡＮ）上のサーバ１０４に対して、自分の個人医療情報のダウンロード要求を行う。その際、個人医療情報ＩＤと個人医療情報を特定する分野を付加する（Ｐ１）。そして、サーバ１０４は対応する個人医療情報を個人１１０の個人端末１０１に送信する（Ｐ２）。そして、図１３（ｂ）に示した様に、個人端末１０１は個人医療情報の暗号キーを基に暗号化された個人医療情報を復号する（Ｐ３）。そして個人１１０は個人端末１０１上で個人医療情報を閲覧する。
【００８３】
（処理フロー）
次に、図４のフローチャートを用いて、本発明の第４の実施形態を実現するための処理フローを説明する。図４のフローを実行するためのハードウエアは、公知のネットワークやサーバやコンピュータや個人端末により構成することができる。以下に述べる本システ
ムの機能は、これらの公知のハードウエア上で実行されるソフトウエアにより実現することができる。図４において、それぞれのフローチャートは、左から、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４、病院１０２内部のコンピュータ１０３、個人端末１０１の工程を示す。
【００８４】
初めに、個人１１０が個人医療情報の分野を特定して、サーバ１０４に対して個人医療情報のダウンロード要求を行う（ステップＳＴ１３０）。ダウンロード要求を容易に行えるようにするため、サーバ１０４が個人医療情報のダウンロード要求を受け付けるウェブサイトを提供すると好適である。例えば、個人１１０が個人端末１０１からこのウェブサイトにアクセスし、所定の申込画面上で個人医療情報のダウンロード要求に必要な情報を入力できるようにすると良い。申込画面の形式はどのようなものでもよいが、最初に個人医療情報の分野の特定を行い、次にその特定した分野の中からダウンロードする情報の選択を行わせるようなユーザーインターフェイスが備わっているとよい。例えば、病名や、病院、受診日（年）等の分野を特定するためのリストを表示し、個人１１０に分野を指定させる。続いて、サーバ１０４は、指定された分野に対応する（例えば、病名や、病院、受診年毎の）個人医療情報のリスト表示を行い、リストにあるファイルを個人１１０が個人端末１０１で選択できる様にする（ステップＳＴ３３０、ステップＳＴ１３１）。なお、このようなウェブサイトでは、パスワード入力等により、正当な者からのダウンロード要求であることを確認することが好ましい。個人医療情報のダウンロード要求を受けたサーバ１０４は、指定された個人医療情報を送信する（ステップＳＴ３３１）。個人医療情報を受信した個人端末１０１は、そのデータを不図示の個人端末内部の、あるいは外部の記憶装置に記憶する。
【００８５】
そして、個人端末１０１は個人１１０の暗号キーを用いて個人医療情報を復号する（ステップＳＴ１３２）。そして個人１１０は個人医療情報を確認する。ここで、個人医療情報の暗号キーは前述しているように生体認証を用いても良いし、サーバ１０４にあらかじめ預けている暗号キーであっても良い。暗号キーをサーバ１０４にあらかじめ預けた場合は、サーバ１０４が暗号キーと個人医療情報を個人端末１０１に送信するようにしても良い。また、サーバ１０４が復号処理を行い、個人端末１０１に暗号化されていない個人医療情報を送信しても良い。
【００８６】
上記フローチャートでは、個人１１０が個人医療情報を指定して、個人医療情報のダウンロード要求を行ったが、個人１１０が個人医療情報の分野を選択しその分野に該当する個人医療情報をすべてダウンロードするフローであっても良い。もちろんどちらかを選択して両方の条件によって個人医療情報のダウンロードを可能にしても良い。
【００８７】
次に、本発明の第４の実施形態の別の例を説明する。図４に示した例では、個人１１０がサーバ１０４に対して個人医療情報のダウンロード要求を行ったが、以下に示す例では、個人１１０が病院１０２内のコンピュータ１０３に対して個人医療情報のダウンロード要求を行う。
【００８８】
図５のフローチャートを用いて、処理フローを説明する。図５のそれぞれのフローは、図４と同様、左から、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４、病院１０２内部のコンピュータ１０３、個人１１０の工程を示す。
【００８９】
初めに、個人１１０が個人医療情報の分野を特定して、病院１０２内のコンピュータ１０３に対して個人医療情報のダウンロード要求を行う（ＳＴ１４０）。この場合は、個人医療情報のダウンロード要求を受け付けるウェブサイトをコンピュータ１０３が提供することが好ましい。ただし、個人医療情報を管理しているのは病院１０２外部のネットワーク上にあるサーバ１０４であるため、コンピュータ１０３はサーバ１０４と連携して（サ
ーバ１０４に問合せを行うことで）、図４で説明したものと同様の入力機能を提供するとよい。具体的には、コンピュータ１０３が、サーバ１０４に対して個人医療情報ＩＤと個人医療情報の分野を送り、サーバ１０４から対応する分野の個人医療情報のリストを受け取る。そしてコンピュータ１０３が個人端末１０１に個人医療情報のリストを送る（ステップＳＴ２４０、ステップＳＴ３４０、ステップＳＴ２４１）。個人１１０は個人端末１０１に表示される個人医療情報のリストを基に必要な個人医療情報を指定する（ステップＳＴ１４１）。病院１０２内のコンピュータ１０３は、サーバ１０４に対して同じ内容（指定された個人医療情報）を要求する（ステップＳＴ２４２）。サーバ１０４は対応する個人医療情報をコンピュータ１０３に送り、コンピュータ１０３は個人端末１０１に対応する個人医療情報を転送する（ステップＳＴ３４１、ステップＳＴ２４３）。これ以降の処理は図４で説明したものと同様である。
【００９０】
このように病院１０２のコンピュータ１０３を経由してサーバ１０４にアクセスする構成には、次のような利点がある。すなわち、個人１１０は、自分自身のかかりつけの病院１０２に問い合わせる感覚で、個人医療情報のダウンロード要求をすることができるという安心感がある。また、個人１１０は、かかりつけの病院１０２以外のウェブサイトのアドレスを覚える必要がない。
【００９１】
以上述べた第４の実施形態によれば、個人１１０が必要と感じた時に自分の個人医療情報を取得できるので、自分の病気の症状の確認や、健康促進のために個人医療情報を利用できる効果がある。なお、第４の実施形態で述べた機能は、第１から第３の実施形態で述べたシステムの付加的な機能として提供すると良い。
【００９２】
＜第５の実施形態＞
次に、本発明の第５の実施形態の説明をする。第５の実施形態は、個人１１０が自分の健康状態を個人医療情報としてネットワーク（ＷＡＮ）上のサーバ１０４に出力（アップロード）する例である。
【００９３】
図６のフローチャートを用いて、本発明の第５の実施形態を実現するための処理フローを説明する。図６のフローを実行するためのハードウエアは、公知のネットワークやサーバやコンピュータや個人端末により構成することができる。以下に述べる本システムの機能は、これらの公知のハードウエア上で実行されるソフトウエアにより実現することができる。図６において、それぞれのフローチャートは、左から、病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４、病院１０２内部のコンピュータ１０３、個人端末１０１の工程を示す。
【００９４】
初めに、個人１１０が、個人端末１０１上で、個人医療情報と対応する情報タグファイルを作成する（ステップＳＴ１５０）。情報タグファイルの一例を図９に示す。図９の情報タグファイルは、個人医療情報「2011ABC.csv」がジョギングの時間と距離の月間デー
タに関するデータであることを示すものである。個人端末１０１は暗号キーを用いて個人医療情報を暗号化する（ステップＳＴ１５１）。次に個人端末１０１は、ネットワーク（ＷＡＮ）を介してサーバ１０４に対し個人医療情報のアップロード要求を行う（ステップＳＴ１５２）。個人医療情報のアップロード要求を受けたサーバ１０４は、アップロード要求の許可を返信する（ステップＳＴ３５０）。アップロード要求の許可を受けたら、個人端末１０１は、個人医療情報と情報タグファイルをサーバ１０４にアップロードする（ステップＳＴ１５３）。アップロードが完了するとサーバ１０４は完了信号を個人端末１０１へ送信する（ステップＳＴ３５１）。そして、個人端末１０１は例えばディスプレイにアップロード完了等のメッセージを表示する（ステップＳＴ１５４）。
【００９５】
この様に、日常の生活習慣の様な健康を維持するために有用な情報や、直接的な個人医
療情報ではないが、健康や医療にかかわる情報を個人医療情報としてサーバ１０４にアップロードしておくことにより、将来の疾病の予防の方針決定や、傷病時の診療に役立てることができる。もちろん、過去のカルテや定期健康診断の様な紙媒体の個人医療情報を電子化し情報タグファイルを付加してアップロードすることも有用である。
【００９６】
個人医療情報と情報タグファイルを作るために例えば、サーバ１０４が専用のウェブサイトを提供することも好ましい。そのウェブサイト上で、質問形式で各種の医療情報を入力できたり、情報タグファイルを作成できると良い。また暗号化などの処理も自動で行われると良い。また、ジョギング等のデータを取得し個人医療情報と情報タグファイルを作成し、サーバ１０４に自動的にアップロードする個人端末１０１上の専用アプリケーションソフトウエア等を開発すると好適である。このようなアプリケーションソフトウエアにより、個人１１０が健康や医療にかかわる情報を面倒な操作なしに継続したデータの取得とアップロードが可能となる利点がある。なお、このような個人情報のアップロードを行う際には、ウェブサイトがパスワード等による本人認証を行うことが好ましい。
【００９７】
第４の実施形態で例示したものと同じ様に、個人医療情報のアップロード要求を、サーバ１０４ではなく、病院１０２内のコンピュータ１０３に対して行う構成も好ましい。この場合、病院１０２内のコンピュータ１０３が個人医療情報のアップロード要求を受け付けるウェブサイトを提供し、個人１１０はこのウェブサイトに個人端末１０１を用いアクセスする。このウェブサイトは前述した診療予約や個人医療情報のダウンロード要求等を行うウェブサイトと同等のユーザーインターフェイスを持つと好適である。基本的な処理フローは図６のものと同じであるが、個人端末１０１とサーバ１０４の間のやり取りをコンピュータ１０３が仲介する点が異なる。
【００９８】
以上述べた第５の実施形態によれば、病院で作成した個人医療情報以外の情報を個人１１０が個人端末１０１でサーバ１０４にアップロードできる。すなわち、日常の生活習慣の様な健康を維持するために有用な情報や、直接的な個人医療情報ではないが、健康や医療にかかわる情報を個人医療情報としてサーバ１０４に個人１１０がアップロードすることが可能となる。このような情報は、将来の疾病の予防の方針決定や、傷病時の診療に役に立つと期待される。なお、第５の実施形態で述べた機能は、第１から第３の実施形態で述べたシステムの付加的な機能として提供すると良い。
【００９９】
＜その他の実施形態＞
本発明の第１から第５の実施形態で述べた方法では、病院１０２内のコンピュータ１０３、サーバ１０４、個人端末１０１等の間で、すなわち広域ネットワーク（ＷＡＮ）を通じて、患者ＩＤや個人医療情報や症状等の個人情報を転送する必要が生じる。したがって、これらの情報は暗号化して転送すると良い。具体的には、ＳＳＬ（Secure Socket Layer）プロトコル等を用いてセキュリティーを確保すると良い。ＳＳＬはNetscape Communications社が開発した、インターネット上で情報を暗号化して送受信するプロトコルであり、現在広く世界中で使用されているプロトコルである。広域ネットワーク（ＷＡＮ）のデータ転送のセキュリティーは本発明の必須要件ではないが、実際に発明を実施する上では重要な技術である。本発明では、広域ネットワーク（ＷＡＮ）のデータ転送のセキュリティーを確保する他の技術を用いてもかまわない。例えば、病院１０２内のコンピュータ１０３、サーバ１０４間では、ＶＰＮ（Virtual Private Network）と言われる仮想化した
専用回線サービスを用いてセキュリティーを確保し、個人端末との間は、ＳＳＬプロトコルを用いてセキュリティーを確保しても良い。このようなネットワーク（ＷＡＮ）のデータの転送のセキュリティーを確保するために、利用できる最良の方法を用いると良い。
【０１００】
本発明の第１から第５の実施形態では個人医療情報を患者の持つ暗号キーで暗号化している例を示した。本発明においては、データ量の大きい個人医療情報を高速に処理するこ
とが要求されるため、共通鍵暗号方式を採用することが好適である。なお、前述した様に、ＳＳＬやＶＰＮ等の技術を用いてネットワーク（ＷＡＮ）のセキュリティーを十分高くできれば、個人医療情報自体の暗号化は必ずしも必要なわけではない。
【０１０１】
本発明の第１から第５の実施形態において、病院１０２内コンピュータ１０３は、複数のコンピュータから構成されていてもかまわない。具体的には本発明で説明したコンピュータ１０３の機能が病院１０２内のネットワーク（ＬＡＮ）に接続された複数のコンピュータで実現されていれば、どのような形態で実現されていてもかまわない。例えば、コンピュータ１０３を、病院１０２内のネットワーク（ＬＡＮ）上のサーバと複数のクライアントから構成しても良い。病院１０２内のネットワーク（ＬＡＮ）上のサーバは、前述した様な、病院１０２外のネットワーク（ＷＡＮ）上のサーバ１０４や患者１００の個人端末との通信を受け持ち、予約の許諾や個人医療情報のダウンロードの対応を行う。医者は診療時に、病院１０２内のネットワーク（ＬＡＮ）を介し、病院１０２内のネットワーク（ＬＡＮ）上のサーバから医者が用いるコンピュータ（クライアント）に個人医療情報を移動し閲覧する。病院１０２内のネットワーク（ＬＡＮ）は病院１０２外部のネットワーク（ＷＡＮ）に比べ、通信量に合わせ最適に設計できるため安定な通信環境を構築できる。そのため、このように病院１０２内のネットワーク（ＬＡＮ）上のサーバに個人医療情報をダウンロード（格納）し、必要に応じてクライアントに病院１０２内のネットワーク（ＬＡＮ）を通じて個人医療情報を転送し、クライアントのディスプレイで閲覧することも可能になる。また、病院１０２内のネットワーク（ＬＡＮ）の伝送速度が遅い場合は、前述した実施形態のステップＳＴ２０２、ＳＴ２１２、ＳＴ２２２の個人医療情報の受信は、ネットワーク（ＷＡＮ）上のサーバ１０４から、病院内のネットワーク（ＬＡＮ）上のサーバを経由して医者が使用するコンピュータ（クライアント）に転送されるまでの工程とすればよい。
【０１０２】
また、バーチャルスライド等を使用した病理診断ができる病理医がいる病院が限られている場合がある。個人医療情報がバーチャルスライド等の場合、診療を行う病院と病理診断を行う病院が異なることもある。このような場合、診療を行う病院のコンピュータと病理診断を行う病院のコンピュータのそれぞれが、前述した病院１０２内のコンピュータ１０３に該当する。暗号キーを患者１００が持つ場合は、診療を行う病院と病理診断を行う病院の間で、広域ネットワーク（ＷＡＮ）を介して暗号キーを交換する必要がある。
また、病院１０２の予約管理等を病院１０２外部のサーバ（前述のサーバ１０４と同じであっても異なっていても良い）が代行しても良い。
以上説明したように、本発明における「病院のコンピュータ」は、１台のコンピュータで構成されても、複数のコンピュータから構成されていても良い。また、本発明における「病院のコンピュータ」には、診療を行う病院以外の病院（例えば病理診断を行う病院）のコンピュータが含まれていても良い。また、本発明における「病院のコンピュータ」は、病院の予約管理等を行うコンピュータや医者が診療時に個人医療情報を閲覧するコンピュータと、同じでも良いし、別のものでも良い。また、本発明における「病院のコンピュータ」は、必ずしも病院の内部に設置されている必要はない。すなわち、個人医療情報を管理する「サーバ」から「病院のコンピュータ」への個人医療情報のダウンロードが、広域ネットワーク（ＷＡＮ）を介して行われる構成であれば、本発明の効果を得ることができる。
【０１０３】
本発明の第１から第５の実施形態における広域ネットワーク（ＷＡＮ）上のサーバ１０４は、複数台のコンピュータからなる仮想マシンであっても良い。仮想マシンを用いたサーバにおいては、個人医療情報の容量や、ユーザ数、同時に可能なアクセス数等に応じて、簡単に仮想マシンの数を増減できる。すなわち、コストとスピードを最適に選ぶことが可能である。本明細書では病院１０２外部のネットワーク（ＷＡＮ）上のサーバ１０４と言う表記を行っているが、サーバ１０４は物理的に１つのコンピュータにより実現するも
のに限るものではない。最も好適な例としては、前述した様に仮想マシンによるサーバがコストとスピードの点で優れた実現方法である。
【産業上の利用可能性】
【０１０４】
本発明は、各医療機関の受診予約システムに好適に適用可能である。
【符号の説明】
【０１０５】
１００：患者、１０１：個人端末、１０２：病院、１０３：病院内のコンピュータ、１０４：病院外部のネットワーク上のサーバ、１１０：個人
【図１】
2014134934.tif 000003
【図２】
2014134934.tif 000004
【図３】
2014134934.tif 000005
【図４】
2014134934.tif 000006
【図５】
2014134934.tif 000007
【図６】
2014134934.tif 000008
【図７】
2014134934.tif 000009
【図８】
2014134934.tif 000010
【図９】
2014134934.tif 000011
【図１０】
2014134934.tif 000012
【図１１】
2014134934.tif 000013
【図１２】
2014134934.tif 000014
【図１３】
2014134934.tif 000015