JP2020016994A - 病院予約システム及びサーバ装置 - Google Patents

Abstract

【課題】客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる技術を提供すること。【解決手段】病院予約システムは、評価要求元のユーザの生体データと予め収集した複数ユーザの生体データとに基づいて限定した上で、電子カルテネットワークから収集した電子カルテの記載内容に基づく、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって病院又は医師を評価して決定した予約候補を、要求元のユーザ端末に提示させる提示部と、当該ユーザ端末からの予約要求に応じて、該当する病院に設けられた、患者の予約管理を行う病院制御部へ予約を依頼する予約部と、を具備する。【選択図】図１

Description

本発明は、病院予約システム及びサーバ装置に関する。

例えば、特許文献１は、複数の医師それぞれに対する評価に基づいて、患者が自己の病気に関する治療を受ける上で適切な医師を選定できるようにした技術を提案している。

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

上記特許文献１では、医師の評価は、その医師に関する情報を他の複数の医師に提示して、この情報に基づいて他の医師が評価するというものであり、主観的な評価になり易い。客観的な指標に基づいてユーザに適する医師又は医師が所属する病院の候補をユーザに提示し、その中からユーザが選定して予約することはできていない。

本発明は、上記の事情に着目してなされたものであり、その目的は、客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる病院予約システム及びサーバ装置を提供することである。

本発明は、上述した課題を解決するために、以下の構成を採用する。

本開示の一態様では、病院予約システムは、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークと、前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部と、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部と、前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、を具備する。
なお、病院とは、ある建物の一室と言った小規模の病院から、一つの敷地内に複数の病棟が配置された大規模病院、更には、複数地域に分散した系列病院を含む病院グループであって良い。病院グループの場合、電子カルテは、グループ内の病院毎に分散配置される場合もある。また、電子カルテは、病院内ではなく、電子カルテネットワーク内に設けられたデータセンタに配置されても良い。ここで、配置とは、記憶媒体を備える記憶部に記憶されることを含む。電子カルテのデータフォーマットは、病院毎に異なっていても良く、各病院の電子カルテが電子カルテネットワーク内の統一フォーマットに変換されて、データセンタの記憶部に蓄積されることができる。各病院とデータセンタとの間の電子カルテの送受信においては、データ暗号化などにより、秘匿性が担保される。電子カルテネットワーク内では、医療従事者毎に制限されたアクセス権限が与えられて、各医療従事者が操作する医療端末から当該病院またはデータセンタに配置された電子カルテの情報の閲覧や更新が可能になっている。また、電子カルテネットワーク内では、患者であるユーザ毎に制限されたアクセス権限が与えられて、各ユーザが操作するユーザ端末からデータセンタに配置された自身の電子カルテの情報を閲覧できるようになっている場合もある。この場合も、ユーザ端末とデータセンタとの間のデータ送受信においては、データ暗号化などにより、秘匿性が担保されることが望ましい。
上記の構成の病院予約システムによれば、任意のユーザ端末からの評価要求に応じて、そのユーザ端末のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、その評価結果に基づいて予約候補をユーザに提示し、評価要求元のユーザ端末のユーザの選定に従って、病院の予約を行うので、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定でき、また、その選定に応じて病院を簡便に予約することができるようになる。

なお、上記一態様において、前記評価部は、前記複数の病院又は医師の評価結果を表す評価値を算出し、前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させることができる。
当該構成によれば、評価値という数値を用いることで評価値の順番に並べ替えることができ、ユーザに適した予約候補を容易に提示することができる。

また、上記一態様において、病院予約システムは、前記生体データ収集部によって収集した前記生体データの属性に応じて病院又は医師をデータベース化した対応関係データベースを更に具備し、前記限定部は、前記要求元の前記ユーザ端末の前記ユーザの前記生体データの属性により、前記対応関係データベースを参照して、前記評価対象となる前記複数の病院又は医師を限定するようにしても良い。
当該構成によれば、データベースを用いることで、容易且つ迅速に評価対象の病院又は医師を限定することができるようになる。

また、上記一態様において、前記生体データ収集部は、それぞれユーザの生体データを収集する複数のユーザ端末それぞれから送信されたユーザの生体データを、前記通信ネットワークを介して受信することができる。
当該構成によれば、病院予約サービスに加入するユーザの各ユーザ端末から生体データを収集することで、生体データを容易に収集することができる。

また、上記一態様において、前記生体データ収集部は、前記複数のユーザそれぞれの生体データの履歴を収集し、前記評価部によって評価する評価項目は、更に、前記生体データ収集部によって収集した前記生体データの一定期間の履歴に基づく症状の改善度を含むことができる。
当該構成によれば、症状の改善度という症状の改善状況に基づいた評価を加えることで、よりユーザに適した候補を提供することができるようになる。

また、上記一態様において、前記評価部は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とし、前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させることができる。
当該構成によれば、点数化した評価値を用い、予約候補をその数値と共に提示することで、ユーザが予約する病院を選定する際の指標を提供することができ、ユーザの選定を容易にすることが可能となる。

また、上記一態様において、病院予約システムは、前記各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得する医師属性取得部を更に具備し、前記受付部は、更に、前記要求元の前記ユーザ端末の前記ユーザの属性情報を受け付け、前記評価部によって評価する評価項目は、更に、前記医師属性取得部により取得される前記医師の属性情報と、前記受付部によって受け付けた前記要求元の前記ユーザ端末の前記ユーザの属性情報との関係を含むことができる。
当該構成によれば、評価値を提示するべきユーザの性別又は年齢と医師の性別又は年齢とにも基づいて評価するので、ユーザに適した医師を高く評価することができ、ユーザにより適した医師を候補とすることができるようになる。

また、上記一態様において、前記受付部は、更に、前記要求元の前記ユーザ端末から位置情報を受け付け、前記限定部は、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報に基づいて、前記評価対象となる前記複数の病院又は医師を限定し、前記評価部によって評価する評価項目は、更に、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報と、前記評価対象の前記病院の位置との関係を含むことができる。
当該構成によれば、評価要求元のユーザの現在位置やユーザが指定した指定位置に応じて、ユーザが通い得る病院を限定することで、ユーザに不適切な病院を候補として提示する可能性を小さくすることができる。

また、上記一態様において、前記病院制御部は、更に、前記病院の時事の滞在中患者の時間管理を行い、前記評価部は、前記病院制御部にアクセスして、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを取得し、前記評価部によって評価する評価項目は、更に、前記取得した診療待ち患者人数及び予約患者数を含むことができる。
当該構成によれば、各病院の現時点での待ち時間を考慮して病院または医師の候補を提示することが可能になる。

本開示の別の態様では、サーバ装置は、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集する電子カルテ収集部と、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部の内、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、を具備する。
当該構成によれば、任意のユーザ端末からの評価要求に応じて、サーバ装置において、そのユーザ端末のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、その評価結果に基づいた予約候補を評価要求元のユーザ端末に送信してユーザに提示し、また、そのユーザ端末のユーザの選定に従って、病院の予約を行うので、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定できるようになり、また、その選定に応じて病院を簡便に予約することができるようになる。

本発明によれば、客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる技術を提供することができる。

図１は、実施形態に係る病院予約システムの構成の一例を模式的に例示するブロック図である。 図２は、第１実施形態に係る病院予約システムの全体構成の一例を示すブロック図である。 図３は、病院データベースの記憶内容の一例を示す図である。 図４は、ユーザデータベースの記憶内容の一例を示す図である。 図５は、対応関係データベースの記憶内容の一例を示す図である。 図６は、収集データベースの記憶内容の一例を示す図である。 図７は、評価データベースの記憶内容の一例を示す図である。 図８は、サービスサーバの処理手順の一例を例示するフローチャートである。 図９は、ユーザ端末の処理手順の一例を例示するフローチャートである。 図１０は、図９中の評価処理の一例を例示するフローチャートである。 図１１は、図８中の電子カルテ収集処理の一例を例示するフローチャートである。 図１２は、図８中の評価算出処理の一例を例示するフローチャートである。 図１３は、生体データの履歴の一例を説明するための図である。 図１４は、生体データの履歴の別の例を説明するための図である。 図１５は、第２実施形態に係る病院予約システムにおけるサービスサーバの処理手順の一例を例示するフローチャートである。 図１６は、図１５中の電子カルテ収集処理の一例を例示するフローチャートである。 図１７は、図１５中の人数収集処理の一例を例示するフローチャートである。 図１８は、第３実施形態に係る病院予約システムにおけるサービスサーバの処理手順の一例を例示するフローチャートである。 図１９は、図１８中の第１評価算出処理の一例を例示するフローチャートである。 図２０は、図１８中の第２評価算出処理の一例を例示するフローチャートである。

以下、本発明の実施形態を、図面に基づいて説明する。

［適用例］
まず、図１を参照して、本発明が適用される場面の一例について説明する。図１は、実施形態に係る病院予約システムの構成の一例を模式的に例示する。

［適用例の構成］
図１の例では、病院予約システムは、インターネットなどの通信ネットワークＮＥＴにそれぞれ接続された、電子カルテネットワーク（ＥＨＲ：Electronic Health Records）１とサービスサーバ１０とを含む。サービスサーバ１０は、通信ネットワークＮＥＴを介して、複数のユーザ端末２０と接続され得る。

電子カルテネットワーク１は、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテ（ＥＭＲ：Electronic Medical Records）を、複数の病院の間で共有するためのネットワークである。電子カルテネットワーク１は、例えば、複数の病院それぞれに設けられた病院サーバ３０と、データセンタに設けられたデータサーバ４０とが、通信ネットワークＮＥＴを介して接続されて構成される。なお、電子カルテネットワーク１は、通信ネットワークＮＥＴとして、インターネットではなくて、専用の通信回線を使用するものであっても構わない。但し、データサーバ４０は、サービスサーバ１０が通信ネットワークＮＥＴを介して当該データサーバ４０にアクセスできるようにする構成を持つ必要がある。

各病院の病院サーバ３０は、例えば、制御部３１と、この制御部３１に接続された記憶部３２と、図示しない通信インタフェースを有することができる。また、病院サーバ３０には、例えば、病院内の医師、看護師、検査技師、事務員などの医療従事者が操作するパーソナルコンピュータ（ＰＣ）、来院した患者が操作する自動受付機や自動会計機、などの各種の医療端末３３が、病院内ＬＡＮ（Local Area Network）などを介して接続されている。病院内ＬＡＮは、有線ＬＡＮであっても良いし、無線ＬＡＮであっても良く、また、有線と無線とが混在したＬＡＮであっても良い。なお、特に図示はしていないが、病院サーバ３０には、患者の血圧値などの生体データを計測する生体データ計測装置、患者の内部画像を撮影するＣＴ（Computerized Tomography）装置などの内部画像撮影装置、などを含む各種の検査機器も病院内ＬＡＮなどを介して接続可能となっている。

病院は、ある建物の一室と言った小規模の病院から、一つの敷地内に複数の病棟が配置された大規模病院、更には、複数地域に分散した系列病院を含む病院グループであって良い。病院グループの場合、グループ内の病院毎に病院サーバ３０が配されても良いし、一つの病院サーバ３０が一つの主管病院に配置され、各系列病院の医療端末３３が専用通信回線などを介して病院サーバ３０に接続されていても良い。或いは、グループ内の病院毎に病院サーバ３０の制御部３１のみが設けられ、記憶部３２は、一つの主管病院の病院サーバ３０にのみ配置されても良い。

病院サーバ３０における制御部３１は、図示はしないが、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などのプロセッサと、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部３１は、様々な動作を行うことができる。

記憶部３２は、例えば、制御部３１のプロセッサにより実行されるプログラム、プログラムを実行するために必要な設定データ、及び各種データベースを記憶することができる。制御部３１のプロセッサにより実行されるプログラムは、例えば、電子カルテの閲覧や更新を行う電子カルテ管理プログラム、患者の予約を管理する予約管理プログラム、病院に滞在中の各患者についての受付時間などを管理する時間管理プログラム、などを含むことができる。プログラムを実行するために必要な設定データは、例えば、データセンタのデータサーバ４０のアクセスアドレス、などを含むことができる。データベースは、例えば、医療端末３３を操作する医療従事者の権限やパスワードなどを含む各医療従事者情報を記憶する医療従事者データベース、各患者の電子カルテ（ＥＭＲ）を記憶する電子カルテデータベース、予約状況を記憶する予約データベース、などを含むことができる。なお、各病院の記憶部３２は、上記したようなプログラム、設定データ、及びデータベースの全てを記憶することは必須ではなく、また、上記した以外のプログラム、設定データ、及びデータベースを記憶していても良い。記憶部３２が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部３２が備える記憶媒体は、ＥＥＰＲＯＭ（登録商標）（Electrically Erasable, Programmable Read-Only Memory）などを使用することができる。なお、この記憶部３２についても、制御部３１のプロセッサがワークメモリとして使用するようにしても良い。

制御部３１のプロセッサは、例えば、記憶部３２に記憶された電子カルテ管理プログラムを実行することで、各医療端末３３の操作に応じて、記憶部３２に記憶している電子カルテの記載内容を医療端末３３に表示させたり、電子カルテの記載内容を更新したりすることができる。また、制御部３１のプロセッサは、例えば、図示しない検査機器からの検査データを、電子カルテに追記することも可能である。さらに、制御部３１のプロセッサは、例えば、図示しない通信インタフェースにより、通信ネットワークＮＥＴ又は専用の通信回線を介してデータサーバ４０と通信することができる。通信インタフェースによる通信は、特定の通信方式に限定されるものではない。但し、データサーバ４０との通信においては、データ暗号化などにより、秘匿性を担保することが必要である。制御部３１のプロセッサは、例えば、記憶部３２に記憶している電子カルテを、データセンタのデータサーバ４０に送信することができる。この場合、制御部３１のプロセッサは、電子カルテを、電子カルテネットワーク１の共通のデータフォーマットに変換し、例えば暗号化した上で、送信することができる。逆に、制御部３１のプロセッサは、他の病院で作成されてデータサーバ４０に共通フォーマットで蓄積されている電子カルテを、データサーバ４０から受信して、それを例えば復号化し、当該病院の電子カルテのフォーマットに変化した上で、記憶部３２の電子カルテデータベースに登録することができる。

また、制御部３１のプロセッサは、例えば、記憶部３２に記憶された予約管理プログラムを実行することで、医療端末３３からの予約、或いは通信ネットワークＮＥＴを介したサービスサーバ１０又はユーザ端末２０からの予約を受け付けて、予約データベースを時事更新することができる。

更に、制御部３１のプロセッサは、例えば、記憶部３２に記憶された時間管理プログラムを実行することで、各患者の受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を取得して、その病院の時事の滞在中患者それぞれの時間管理を行うこともできる。なお、制御部３１のプロセッサは、例えば、上記電子カルテ管理プログラムを実行することで、この取得した各患者の受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報を各患者の電子カルテに記載することができる。

データセンタのデータサーバ４０は、例えば、制御部４１と、この制御部４１に接続された記憶部４２と、図示しない通信インタフェースを有することができる。制御部４１は、図示はしないが、例えば、ＣＰＵやＭＰＵなどのプロセッサと、ＲＡＭやＲＯＭなどのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部４１は、様々な動作を行うことができる。

記憶部４２は、例えば、制御部４１のプロセッサにより実行されるプログラム、プログラムを実行するために必要な設定データ、及び各種データベースを記憶することができる。制御部４１のプロセッサにより実行されるプログラムは、例えば、各病院サーバ３０から通信ネットワークＮＥＴ又は専用の通信回線を介して送信されてきた電子カルテを処理する電子カルテ処理プログラム、サービスサーバ１０やユーザ端末２０と送信するための通信プログラム、などを含むことができる。データベースは、例えば、医療端末３３を操作する医療従事者やユーザ端末２０を操作するユーザの権限やパスワード、サービスサーバ１０の権限などを記憶するアクセス権限データベース、病院サーバ３０から受信した各患者の電子カルテ（ＥＭＲ）を記憶する電子カルテデータベース、などを含むことができる。なお、記憶部４２は、上記した以外のプログラムやデータベースを記憶していても良い。記憶部４２が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部４２が備える記憶媒体は、ＥＥＰＲＯＭなどを使用することができる。なお、この記憶部４２についても、制御部４１のプロセッサがワークメモリとして使用するようにしても良い。

制御部４１のプロセッサは、例えば、記憶部４２に記憶された電子カルテ処理プログラムを実行することで、通信ネットワークＮＥＴ又は専用の通信回線を介して、各病院サーバ３０と通信し、それぞれの病院サーバ３０から送信されてきた例えば暗号化された電子カルテを例えば復号化して、記憶部４２の電子カルテデータベースに登録することができる。逆に、制御部４１のプロセッサは、各病院の病院サーバ３０からの要求に応じて、記憶部４２の電子カルテデータベースに共通フォーマットで蓄積されている電子カルテを、例えば暗号化して、要求元の病院サーバ３０に送信することができる。

また、図１の例では、病院Ｃは、病院サーバ３０の記憶部３２が電子カルテデータベースを備えていない。このような構成の病院サーバ３０では、データサーバ４０の記憶部４２に記憶された電子カルテが、仮想的に、その病院Ｃの病院サーバ３０が備える電子カルテとして使用されることができる。そのため、制御部４１のプロセッサは、例えば、記憶部４２に記憶された電子カルテ処理プログラムを実行することで、通信ネットワークＮＥＴ又は専用の通信回線とその病院Ｃの病院サーバ３０とを介して、医療端末３３からの操作情報を取得して、電子カルテに対する処理が行えるようになっている。また、制御部４１のプロセッサは、例えば、記憶部４２に記憶された通信プログラムを実行することで、通信ネットワークＮＥＴを介して、サービスサーバ１０或いはユーザ端末２０と通信することができる。

なお、上記のように、病院サーバ３０の制御部３１が電子カルテネットワーク１の共通のデータフォーマットに、記憶部３２に記憶している独自のデータフォーマットの電子カルテを変換してから送信することは必須ではない。各病院の病院サーバ３０からは独自のデータフォーマットの電子カルテを、例えば暗号化した上で、データセンタに送信しても良い。この場合には、それを受信したデータサーバ４０の制御部４１において、受信した電子カルテを例えば復号化し、データフォーマットを電子カルテネットワーク１の共通のデータフォーマットに変換して、記憶部４２の電子カルテデータベースに記憶すれば良い。また、逆に、各病院の病院サーバ３０へ電子カルテを送信する際には、データサーバ４０の制御部４１において、共通データフォーマットの電子カルテを各病院独自のデータフォーマットに変換してから、例えば暗号化して、送信するようにすれば良い。

電子カルテネットワーク１内では、医療従事者毎に制限されたアクセス権限が与えられて、各医療従事者は、医療端末３３から、アクセスが許可された自病院の病院サーバ３０の記憶部３２又はデータセンタのデータサーバ４０の記憶部４２に記憶された電子カルテの情報を閲覧できる。また、権限が与えられていれば、各医療従事者は、医療端末３３から、電子カルテの更新も可能である。

ユーザ端末２０は、通信ネットワークＮＥＴへの接続機能を備えた一般的なスマートホン（スマホ）やタブレット型端末のようなスマートデバイスであって良い。ユーザ端末２０は、例えば、制御部２１と、この制御部２１に接続された測定部２２及び記憶部２３と、図示しない通信ネットワークＮＥＴに接続するための通信インタフェースと、ユーザインタフェースと、を有することができる。また、ユーザ端末２０は、生体データ計測装置２４と接続されることができる。通信インタフェースは、例えば、Ｗｉ−Ｆｉ（登録商標）モジュールを含むことができる。通信インタフェースは、例えば、図示しないＷｉ−Ｆｉ基地局を経由して、インターネットなどの通信ネットワークＮＥＴに接続され、通信ネットワークＮＥＴを介して、サービスサーバ１０及び電子カルテネットワーク１のデータサーバ４０と通信することができる。ユーザインタフェースは、液晶ディスプレイとその表示画面上に配置されたタッチパネル、及びスマートデバイスの筐体に設けられた操作ボタンを含む。

ユーザ端末２０における制御部２１は、図示はしないが、例えば、ＣＰＵやＭＰＵなどのプロセッサと、ＲＡＭやＲＯＭなどのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。

測定部２２は、ユーザの各種生体データを測定する。例えば、測定部２２は、一般にスマートデバイスが備えるカメラとＬＥＤフラッシュライトを光電脈波計（ＰＰＧ（Photo Plethysmography）センサ）として利用して、脈拍数を測定することができる。また、圧力センサを加えることで、血圧測定を行い得るスマートデバイスも知られている。

生体データ計測装置２４は、心電や脈拍、血圧、体重、体脂肪率、など様々な生体データを、一つ又は複数計測可能な機器である。この生体データ計測装置２４は、例えば、ユーザ端末２０の制御部２１との間で近距離無線通信する。例えば、ユーザ端末２０及び生体データ計測装置２４は、それぞれ、Bluetooth（登録商標）などの近距離無線データ通信規格を採用したＢＬＥ通信モジュールを有することができるが、これに限定されない。また、生体データ計測装置２４とユーザ端末２０の制御部２１は、有線接続されても良い。

記憶部２３は、Ｗｅｂブラウザや各種のアプリケーションプログラム（スマホアプリ）を記憶する。プロセッサが、ＲＯＭ又は記憶部２３に記憶されたプログラムを実行することによって、制御部２１は、様々な動作を行うことができる。例えば、制御部２１は、スマホアプリやＷｅｂブラウザなどにより、サービスサーバ１０にアクセスすることができる。また、電子カルテネットワーク１内では、患者であるユーザ毎に制限されたアクセス権限が与えられて、各ユーザは、ユーザ端末２０からデータサーバ４０にアクセスして、記憶部４２に記憶されている自身の許可された電子カルテの情報を閲覧できるようになっている場合もある。ユーザ端末２０は、ＧＰＳ（Global Positioning System）受信機を有しても良い。ユーザ端末２０は、ＧＰＳ受信機またはＷｉ−Ｆｉモジュールによって取得した当該ユーザ端末の位置情報を、スマホアプリで利用することができ、必要に応じて通信ネットワークＮＥＴを介してサービスサーバ１０などに送信可能となっている。

また、記憶部２３は、測定部２２及び生体データ計測装置２４によって取得したユーザの生体データを、ＰＨＲ（Personal Health Records）として蓄積することができる。すなわち、当該ユーザ端末２０のユーザは、記憶部２３に、自身が自ら管理する医療・健康記録を一定期間以上に渉って保存しておくことができる。

サーバ装置として動作するサービスサーバ１０は、特に図示はしないが、例えば、制御部と、この制御部に接続された記憶部と、通信ネットワークＮＥＴに接続するための通信インタフェースと、を有することができる。通信インタフェースは、通信ネットワークＮＥＴを介して、ユーザ端末２０及び電子カルテネットワーク１のデータサーバ４０や病院サーバ３０と通信することができる。通信インタフェースによる通信は、特定の通信方式に限定されるものではない。制御部は、例えば、ＣＰＵやＭＰＵなどのプロセッサと、ＲＡＭやＲＯＭなどのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部は、電子カルテ収集部１１、生体データ収集部１２、受付部１３、限定部１４、評価部１５、提示部１６、予約部１７、対応関係データベース１８、及び医師属性取得部１９の動作を行うことができる。

電子カルテ収集部１１は、例えば、通信ネットワークＮＥＴを介して電子カルテネットワーク１におけるデータセンタのデータサーバ４０にアクセスして、記憶部４２に記憶された各病院の電子カルテの記載内容を収集することができる。例えば、電子カルテ収集部１１は、データサーバ４０の制御部４１に電子カルテの記載内容の送信を依頼し、データサーバ４０から送信されてくる電子カルテを受信することで、電子カルテの記載内容を収集する。

生体データ収集部１２は、例えば、通信ネットワークＮＥＴを介して各ユーザ端末２０の記憶部２３に蓄積された生体データを収集することができる。例えば、ユーザ端末２０において測定部２２又は生体データ計測装置２４によって生体データが取得される毎に、ユーザ端末２０からその取得した生体データをサービスサーバ１０に送信することで、生体データ収集部１２は、各ユーザ端末２０の記憶部２３に記憶された生体データを収集することができる。あるいは、生体データ収集部１２は、各ユーザ端末２０の制御部２１に記憶部２３に記憶されている少なくとも一定期間の生体データの送信を依頼し、各ユーザ端末２０から送信されてくる少なくとも一定期間の生体データを受信することで、生体データを収集することも可能である。

受付部１３は、例えば、通信ネットワークＮＥＴを介してユーザ端末２０から要求を受け付ける。この受付部１３が受け付ける要求は、病院候補の提示を要求する評価要求や病院への予約を要求する病院予約要求を含むことができる。なお、ユーザ端末２０の制御部２１は、評価要求をサービスサーバ１０に送信する際、位置情報など、サービスサーバ１０での評価動作に必要な情報を併せて送信することができる。このとき、記憶部２３にＰＨＲとして蓄積している生体データの内の最新のものも併せて送信するようにしても良い。ただし、これは、ユーザ端末２０において生体データが取得される毎に、ユーザ端末２０からサービスサーバ１０に送信されているので、必ずしも必要というわけではない。また、病院予約要求には、予約を依頼する病院又は医師を示す情報が含まれる。

限定部１４は、例えば、受付部１３によって通信ネットワークＮＥＴを介してユーザ端末２０から評価要求とユーザ端末２０のユーザの生体データとが受け付けられたとき、評価を行うべき評価対象を限定する。例えば、限定部１４は、評価要求の要求元のユーザ端末２０のユーザの生体データと、生体データ収集部１２によって収集した複数のユーザから収集した生体データとに基づいて、複数の病院又は複数の病院に所属する複数の医師の中から、評価を行うべき評価対象を限定することができる。

評価部１５は、例えば、限定部１４によって評価対象として限定された複数の病院又は医師を、電子カルテ収集部１１によって収集した電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって評価する。例えば、診療時間は、患者の診療開始から診療終了までの時間であり、待ち時間は、患者の受付から診療開始までの時間と、診療終了から会計終了までの時間との合計である。

提示部１６は、例えば、評価部１５による評価結果に基づいて、評価された複数の病院又は医師の中から少なくとも一つを予約候補として、通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０へ送信することで、当該ユーザ端末２０に予約候補を提示させることができる。

予約部１７は、例えば、受付部１３によって通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０から、提示された予約候補の中からユーザによって選択された病院又は医師に対する病院予約要求が受け付けられたとき、当該ユーザの予約を該当する病院へ依頼する。例えば、予約部１７は、病院予約要求で示される病院又は医師に該当する病院の病院サーバ３０の、患者の予約管理を行う病院制御部として動作する制御部３１に、通信ネットワークＮＥＴを介して病院予約要求元の、すなわち評価要求元のユーザ端末２０のユーザの予約を依頼することができる。

対応関係データベース１８は、例えば、生体データ収集部１２によって収集した生体データの属性に応じて病院又は医師をデータベース化したものである。限定部１４は、評価要求元のユーザ端末２０のユーザの生体データの属性により、この対応関係データベース１８を参照して、評価対象となる複数の病院又は医師を限定することができる。

医師属性取得部１９は、例えば、各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得することができる。データサーバ４０は、特に図示はしていないが、各病院に所属する医師の医師属性情報を登録したデータベースを有しており、このデータベースが、例えば、各病院の病院サーバ３０の制御部３１により、所属する医師の変更がある度に更新されるようになっている。よって、医師属性取得部１９は、例えば、通信ネットワークＮＥＴを介して、データサーバ４０の制御部４１から医師属性情報を取得することができる。また、多くの病院は、病院サーバ３０によって或いは他のＷｅｂサーバによって、病院紹介のためのＷｅｂページなどを提供しており、そこに所属医師の公開可能な医師属性情報を公開している。よって、医師属性取得部１９は、例えば、通信ネットワークＮＥＴを介してＷｅｂページより、医師属性情報を取得することもできる。

なお、受付部１３は、更に、通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０のユーザの属性情報を受け付けることができ、評価部１５によって評価する評価項目は、更に、医師属性取得部１９により取得される医師の属性情報と、この受付部１３によって受け付けた評価要求元のユーザ端末２０のユーザの属性情報との関係を含むことができる。ユーザの属性情報は、ユーザ端末２０からの評価要求と共に送信されるようにしても良いし、サービスサーバ１０が提供するサービスへのユーザ加入時に受付部１３によって受け付けて、加入者であるユーザの情報を登録しておく図示しないユーザデータベースに登録しておくようにしても良い。

［適用例の動作］
次に、病院予約システムの動作の一例について説明する。

各病院においては、患者は、まず、自動受付機や受付カウンタで受け付けを行う。すると、例えば、自動受付機や医療従事者が操作するＰＣなどの医療端末３３から、患者を特定するための患者ＩＤなどを含む患者情報が制御部３１に入力される。制御部３１は、例えば、この患者情報に基づいて、記憶部３２に記憶された電子カルテデータベースにおける該当患者の電子カルテに、受付日時を記載つまり記憶する。また、医師による患者の診療、診断、治療などの診療行為や、看護師や検査技師による患者の検査行為が行われると、例えば、医療従事者が操作する医療端末３３から、診療開始日時、診療終了日時、診療医師、診療内容、処方、検査結果、などの情報が制御部３１に入力される。制御部３１は、例えば、その入力された情報を、記憶部３２に記憶された電子カルテデータベースにおける該当患者の電子カルテに記載つまり記憶する。また、制御部３１は、例えば、記憶部３２に記憶した会計プログラムなどにより、記憶部３２に記憶した電子カルテの記載内容に基づいて、各患者の支払額を算出する。患者が自動会計機や会計カウンタでその支払額を支払うと、例えば、自動会計機や医療従事者が操作するＰＣなどの医療端末３３から、決済情報が制御部３１に入力される。制御部３１は、例えば、この決済情報を記憶部３２に記憶すると共に、記憶部３２に記憶された電子カルテデータベースにおける該当患者の電子カルテに、会計終了日時を記載つまり記憶する。なお、記憶部３２に電子カルテデータベースを記憶せずに、データセンタのデータサーバ４０に電子カルテを保存する形態を採る病院では、制御部３１は、例えば、電子カルテに記載するべき情報を、通信ネットワークＮＥＴ又は専用回線を介して、データサーバ４０に送信する。データサーバ４０の制御部４１は、例えば、この受信した情報に基づいて、記憶部４２に記憶している電子カルテデータベースの該当する患者の電子カルテの記載内容を更新する。

また、制御部３１は、例えば、各患者の電子カルテの記載内容が更新される度、あるいは一定時間おきに、更新が有った電子カルテについて、その電子カルテ全体又は更新内容を通信ネットワークＮＥＴ又は専用回線を介して、データサーバ４０に送信する。データサーバ４０の制御部４１は、例えば、この受信した情報に基づいて、記憶部４２に記憶している電子カルテデータベースの該当する患者の電子カルテの記載内容を更新する。

サービスサーバ１０の電子カルテ収集部１１は、例えば、一定時間おきに、図示しない通信インタフェースにより通信ネットワークＮＥＴを介して、電子カルテネットワーク１におけるデータセンタのデータサーバ４０の制御部４１に電子カルテ記載内容送信要求を送信することができる。そして、これに応じて、データサーバ４０から送信されてくる電子カルテの記載内容を受信し、図示しない記憶部に記憶する。データサーバ４０の記憶部４２に設けられる電子カルテデータベースにおける各電子カルテには、氏名や住所などの患者個人を特定する個人情報と、その患者に関する検査情報と、を含む患者情報が記載されている。更に、各電子カルテには、その患者の各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時、などを含む診療情報が記載されている。データサーバ４０に送信する電子カルテ記載内容送信要求は、収集するべき情報を特定する収集対象情報を含み、電子カルテ収集部１１は、この収集対象情報に、少なくとも、診療情報を含める。また、既に収集済みの電子カルテの記載内容の送受信は、通信資源の浪費であるので、電子カルテ記載内容送信要求は、情報を収集するべき期間を示す収集期間情報を含むことができる。電子カルテ収集部１１は、受信した電子カルテの記載内容により、図示しない記憶部の記憶内容を更新する。

各ユーザ端末２０において測定部２２又は生体データ計測装置２４によってユーザの生体データが取得されると、制御部２１は、その取得した生体データを記憶部２３にＰＨＲとして記憶する。また、制御部２１は、その取得した生体データを、図示しない通信インタフェースにより通信ネットワークＮＥＴを介してサービスサーバ１０に送信することができる。

サービスサーバ１０の生体データ収集部１２は、例えば、図示しない通信インタフェースにより、各ユーザ端末２０から通信ネットワークＮＥＴを介して送信されてきた生体データを受信し、図示しない記憶部に記憶している各ユーザ端末２０のユーザ毎の生体データの履歴に、その受信した生体データを追加記憶する。あるいは、生体データ収集部１２は、各ユーザ端末２０の制御部２１に記憶部２３に記憶されている少なくとも一定期間の生体データの送信を依頼し、各ユーザ端末２０から送信されてくる少なくとも一定期間の生体データを受信することで、生体データを収集する。

いずれかのユーザ端末２０が、スマホアプリやＷｅｂブラウザなどにより、サービスサーバ１０にアクセスして、評価要求を送信すると、受付部１３は、図示しない通信インタフェースにより、この評価要求を受け付ける。受付部１３がこの評価要求を受け付けたとき、それに応答して、限定部１４は、評価要求と共に受け付けた評価要求元のユーザ端末２０のユーザの生体データと、図示しない記憶部に記憶している複数のユーザから収集した生体データとに基づいて、複数の病院又は複数の病院に所属する複数の医師の中から、評価を行うべき評価対象を限定する。例えば、限定部１４は、評価要求元のユーザ端末２０のユーザの生体データの属性により対応関係データベース１８を参照して、評価対象となる複数の病院又は医師を限定することができる。

また、ユーザ端末２０からの評価要求には、ＧＰＳ受信機またはＷｉ−Ｆｉモジュールによって取得した当該ユーザ端末２０の現在位置や、図示しないユーザインタフェースを介して入力されたユーザ指定の指定位置などの位置情報を含めることができる。指定位置は、例えばユーザの自宅や勤務地などの住所情報を含むことができる。また、指定位置は、予めユーザ毎に登録し、サービスサーバ１０の図示しない記憶部に記憶しておくことも可能である。限定部１４は、この位置情報に基づいて、評価対象となる複数の病院又は医師を限定することができる。

評価部１５は、電子カルテ収集部１１によって収集して図示しない記憶部に記憶した電子カルテの記載内容の内、このように限定部１４によって評価対象として限定された病院又は医師に対応する電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって評価することで、それら限定された複数の病院又は医師を評価し、その評価結果を図示しない記憶部に記憶する。なお、評価部１５によって評価する評価項目は、生体データ収集部１２によって収集して図示しない記憶部に記憶した生体データの一定期間の履歴に基づいた症状の改善度を含むことができる。更に、前記評価部１５によって評価する評価項目は、評価要求元のユーザ端末２０からの位置情報と評価対象として限定された病院の位置との関係を含んでも良い。

なお、診療を行うために検査を実施した場合には、病院での滞在時間が長くなるため、病院又は医師の評価に際して、待ち時間をそのまま利用することは望ましくない。よって、電子カルテ収集部１１によって収集して図示しない記憶部に記憶した電子カルテの記載内容に検査実施の記録が存在する場合には、その診療回の時間情報を病院又は医師の評価に利用しない、或いは、時間に何らかの係数を乗じて利用するものとする。また、電子カルテ収集部１１での電子カルテの記載内容の収集の際に、検査実施の記録が存在する診療回の情報を収集しないようにしても良い。

また、ユーザ端末２０からの評価要求には、当該ユーザ端末２０のユーザについての、少なくとも性別及び年齢を含むユーザ属性情報を含めることができる。或いは、ユーザ属性情報は、予めユーザ毎に登録し、サービスサーバ１０の図示しない記憶部に記憶しておくことも可能である。また、医師属性取得部１９は、各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得して、図示しない記憶部に記憶する。評価部１５によって評価する評価項目は、これら図示しない記憶部に記憶したユーザ属性情報と医師属性情報との関係を含むことも可能である。

また、病院サーバ３０の制御部３１は、当該病院の時事の滞在中患者の時間管理を行っている。評価部１５は、図示しない通信インタフェースにより、通信ネットワークＮＥＴを介して限定された病院又は限定された医師が所属する病院の病院サーバ３０の制御部３１に、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを問い合わせて取得することができる。評価部１５によって評価する評価項目は、この取得した診療待ち患者人数及び予約患者数を含むことができる。

提示部１６は、例えば、評価部１５による評価結果に基づいて、評価された複数の病院又は医師の中から少なくとも一つを予約候補として、図示しない通信インタフェースにより、通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０へ送信する。この予約候補を受信したユーザ端末２０のスマホアプリやＷｅｂブラウザなどでは、それをユーザに提示する。

なお、評価部１５は、評価対象として限定された複数の病院又は医師の評価結果を表す評価値を算出し、提示部１６は、この評価値が高い方から複数の病院又は医師を予約候補として抽出して、抽出した予約候補をその評価値と共に評価要求元のユーザ端末２０に送信するようにしても良い。

また、評価部１５は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とするようにしても良い。この場合、提示部１６は、評価部１５が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、抽出した予約候補をその評価値と共に評価要求元のユーザ端末２０に送信することができる。

ユーザ端末２０に提示された予約候補を見た評価要求元のユーザ端末２０のユーザである患者が、スマホアプリやＷｅｂブラウザなどにおいて図示しないユーザインタフェースにより、所望の病院の予約操作を行うと、ユーザ端末２０の制御部２１は、病院予約要求を、図示しない通信インタフェースにより通信ネットワークＮＥＴを介してサービスサーバ１０に送信する。

サービスサーバ１０の受付部１３が図示しない通信インタフェースによりこの病院予約要求を受け付けると、それに応答して、予約部１７は、病院予約要求に含まれるユーザによって選択された病院又は医師が所属する病院を特定し、その病院へ当該ユーザの予約を依頼する。例えば、予約部１７は、特定した病院の病院サーバ３０の制御部３１に、図示しない通信インタフェースにより通信ネットワークＮＥＴを介して、病院予約要求元の、すなわち評価要求元のユーザ端末２０のユーザの予約を依頼する。患者の予約管理を行う病院制御部として動作する病院サーバ３０の制御部３１は、この予約の可否を判別し、予約可能であれば、その患者の予約を登録する。そして、予約結果を通信ネットワークＮＥＴを介してサービスサーバ１０に返す。サービスサーバ１０の予約部１７は、図示しない通信インタフェースにより予約結果を受信して、予約要求元のユーザ端末２０に結果を返す。なお、予約部１７から病院サーバ３０に送信する予約要求に、予約要求元ユーザ端末２０のユーザの電子メールアドレスなどを含めることで、病院サーバ３０からユーザへ直接、予約結果を報知できるようにしても良い。

［適用例の効果］
以上のように、適用例に係る病院予約システムによれば、任意のユーザ端末２０からの評価要求に応じて、サービスサーバ１０の評価部１５が、そのユーザ端末２０のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、提示部１６が、その評価結果に基づいて予約候補をユーザに提示する。そして、評価要求元のユーザ端末２０のユーザの病院又は医師の選定に従って、予約部１７が病院の予約を行う。よって、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定でき、また、その選定に応じて病院を簡便に予約することができるようになる。

＜１＞ 第１実施形態
以下に、第１実施形態について説明する。

＜１−１＞構成
図２を用いて、第１実施形態に係る病院予約システムの構成例について説明する。第１実施形態に係る病院予約システムは、上記適用例で説明したように、インターネットなどの通信ネットワークＮＥＴにそれぞれ接続された、電子カルテネットワーク１と、複数のユーザ端末２０と、サーバ装置として動作するサービスサーバ１００と、を含む。図２は、第１実施形態に係る病院予約システムの全体構成の一例を示すブロック図である。

電子カルテネットワーク１は、上記適用例で説明したように、各病院の病院サーバ３０と、データセンタのデータサーバ４０とを含む。病院サーバ３０は、上記適用例で説明したように、制御部３１と、記憶部３２と、図示しない通信インタフェースと、を備え、医療端末３３と接続されている。データサーバ４０は、上記適用例で説明したように、制御部４１と、記憶部４２と、図示しない通信インタフェースと、を含む。

ユーザ端末２０は、上記適用例で説明したように、制御部２１と、測定部２２と、記憶部２３と、図示しない通信インタフェースと、図示しないユーザインタフェースと、を備え、生体データ計測装置２４と接続可能である。

サービスサーバ１００は、図２の例では、制御部１１０と、記憶部１２０と、通信インタフェース１３０と、を含む。なお、図２では、通信インタフェースを「通信Ｉ／Ｆ」と記載している。

制御部１１０は、例えば、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３などを含み、情報処理に応じてサービスサーバ１００の各構成要素の制御を行う。ＣＰＵ１１１の代わりに、ＭＰＵなどの他のプロセッサであっても良い。ＲＯＭ１１３は、例えば、ＣＰＵ１１１が実行するオペレーティングシステムや他のプログラム（例えば、病院予約プログラム）を記憶する。ＲＡＭ１１２は、例えば、ＣＰＵ１１１がワークメモリとして使用するメモリである。

ＣＰＵ１１１が必要なプログラムを実行することによって、上記適用例で説明したような電子カルテ収集部１１、生体データ収集部１２、受付部１３、限定部１４、評価部１５、提示部１６、予約部１７、及び医師属性取得部１９の処理を実行して良い。当該プログラムは、例えば、ＲＯＭ１１３ではなく、記憶部１２０に記憶されていても良い。ＣＰＵ１１１が必要なプログラムを実行する際は、例えば、ＲＯＭ１１３及び／又は記憶部１２０に記憶された対象となるプログラムをＲＡＭ１１２に展開する。そして、ＣＰＵ１１１は、例えば、ＲＡＭ１１２に展開された当該プログラムを解釈及び実行して、各構成要素を制御する。

記憶部１２０は、例えば、制御部１１０により実行されるプログラム（例えば、病院予約プログラム）、プログラムを実行するために必要な設定データ（例えば、データサーバ４０のアドレス情報）、各種のデータベース、などを記憶することができる。記憶部１２０が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部１２０が備える記憶媒体は、例えば、ＥＥＰＲＯＭなどを使用することができる。なお、この記憶部１２０についても、ＣＰＵ１１１がワークメモリとして使用するようにしても良い。記憶部１２０が記憶するデータベースは、病院データベース１２１、ユーザデータベース１２２、対応関係データベース１２３、収集データベース１２４、評価データベース１２５、などを含むことができる。なお、図２では、病院データベース、ユーザデータベース、対応関係データベース、収集データベース及び評価データベースを「病院ＤＢ」、「ユーザＤＢ」、「医療ＤＢ」、「収集ＤＢ」及び「評価ＤＢ」と記載している。

通信インタフェース１３０は、制御部１１０の制御の下、通信ネットワークＮＥＴを介して、ユーザ端末２０、病院サーバ３０及びデータサーバ４０との間でデータ通信を行う。通信プロトコルは、通信ネットワークＮＥＴで規定されたプロトコルを使用する。具体的にはＴＣＰ／ＩＰ（Transmission Control Protocol／Internet protocol）やＵＤＰ／ＩＰ（User Datagram Protocol／Internet protocol）等が使用され得る。

図３は、病院データベース１２１の記憶内容の一例を示す図である。図３に示す例では、病院データベース１２１は、病院ＩＤ、アクセス情報、病院情報、病院評判、診療科、医師ＩＤ、氏名、性別、年齢、滞在人数、予約状況、医師評判、などの項目名に対応する各病院の情報を記憶する。図３では、医師評判を「評判」と記載し、滞在人数を「待ち」と記載している。

「病院ＩＤ」は、サービスサーバ１００が提供する病院予約サービスにおいて病院それぞれに一意に割り当てられる管理番号である。「アクセス情報」は、病院サーバ３０や病院のＷｅｂページにアクセスするためのアドレス情報である。「病院情報」は、病院の名称、住所、電話番号、営業時間、休日（営業日）、駐車場情報、などの病院それぞれに関する一般的な情報である。「病院評判」は、各ユーザ端末２０において任意に入力された、及び／または、インターネット上の各種の病院評価Ｗｅｂページなどから取得した、主観的な病院評価情報である。「診療科」は、内科や皮膚科といった、病院が有する診療科の情報である。

「医師ＩＤ」は、病院に所属する各医師に一意に割り当てられる管理番号である。この医師ＩＤは、病院ＩＤと紐付くことで、各医師が区別可能であるが、医師が別の病院に移ることもあるので、サービスサーバ１００が提供する病院予約サービスにおいて一意に設定される。各病院で独自の医師ＩＤを使用している場合には、記憶部１２０に別途、医師データベースを用意し、病院独自の医師ＩＤを本病院予約サービス用の医師ＩＤに変換できるようにしておけば良い。「氏名」は、各医師の氏名である。「性別」は、各医師の性別である。「年齢」は、各医師の年齢である。「待ち」は、各医師についての現時点における診療待ち患者人数である。「予約状況」は、各医師についての今後の予約患者数である。この予約状況については、例えば、１日を午前と午後に分けるなど、任意の期間に分けて、それぞれの予約患者数が記憶される。「医師評判」は、各ユーザ端末２０において任意に入力された、及び／または、インターネット上の各種の病院評価Ｗｅｂページなどから取得した、主観的な医師評価情報である。

図４は、ユーザデータベース１２２の記憶内容の一例を示す図である。図４に示す例では、ユーザデータベース１２２は、項目として、ユーザＩＤ、パスワード、氏名、ユーザ情報、病院毎ＩＤ、地点、優先条件、日付、通院フラグ、生体データ（例えば、血圧、脈拍、など）、症状パターンなどを有している。図４では、パスワードを「ＰＷ」と、通院フラグを「通院Ｆ」と、症状パターンを「症状Ｐ」と、それぞれ記載している。

「ユーザＩＤ」は、サービスサーバ１００が提供する病院予約サービスへのユーザ加入時に一意に割り当てられるユーザの管理番号である。「パスワード」は、ユーザが認証のために任意に設定する値である。「氏名」は、ユーザの氏名である。「ユーザ情報」は、ユーザに関する情報であり、メールアドレス、電話番号、性別及び年齢を含む。「病院毎ＩＤ」は、当該ユーザの各病院での管理番号を示す情報であり、病院ＩＤと当該病院でのユーザ管理番号とを組み合わせたものである。この病院毎ＩＤにより、各ユーザと各病院の電子カルテとを紐付けることが可能となる。「地点」は、ユーザの位置情報であり、現在の位置、自宅住所、職場住所、登録位置を含むことができる。現在の位置は、例えばユーザ端末２０から送信されてくる現在位置が必要に応じて登録される。自宅住所、職場住所、登録位置は、ユーザが任意に指定する指定位置である。「優先条件」は、ユーザが優先条件として、予め決められた選択肢から選択した或いは任意に指定した情報である。

「日付」は、ユーザ端末２０において生体データを取得した日付である。「通院フラグ」は、ユーザがいずれかの病院に通院したか否かを示すもので、通院した場合に「１」がセットされる。生体データ（「血圧」、「脈拍」、など）は、ユーザ端末２０において取得された生体データである。「症状パターン」は、生体データに含まれる各種の測定値又は計測値の関係を含む生体データの属性、つまり生体データのパターンに基づいて設定される症状を示している。「日付」、「通院フラグ」、生体データ（「血圧」、「脈拍」、など）、「症状パターン」は、各ユーザに対して割り当て得るデータ容量が決まっているので、予め決められた期間分が記憶され、それ以上の情報を追加する際には、最も古い情報が削除される。期間ではなく、予め決められた数であっても良い。いずれにしても、この期間又は数は、少なくとも後述する一定期間以上の生体データが保存されるように決められていれば良い。ユーザデータベース１２２は、その他に、ユーザが過去に診療を受けた医師ＩＤの記録などを記憶しても良い。

図５は、対応関係データベース１２３の記憶内容の一例を示す図である。対応関係データベース１２３は、上記適用例で説明したような対応関係データベース１８に対応するものである。図５に示す例では、対応関係データベース１２３は、項目として、症状パターン、病院ＩＤ、及び医師ＩＤを有している。図５では、症状パターンを「症状Ｐ」と記載している。この対応関係データベース１２３は、症状パターンに対応する病院及び医師をデータベース化したものである。

「症状パターン」は、ユーザデータベース１２２の症状パターンに対応している。「病院ＩＤ」は病院を特定するための管理番号である。「医師ＩＤ」は医師を特定するための管理番号である。これら病院ＩＤ及び医師ＩＤは、病院データベース１２１のそれらと対応している。

図６は、収集データベース１２４の記憶内容の一例を示す図である。図６に示す例では、収集データベース１２４は、項目として、病院ＩＤ、患者ＩＤ、予約日時、受付、診療開始、医師ＩＤ、診療終了、会計終了、初診フラグ、症状、などを有している。図６では、初診フラグを「初診Ｆ」と記載している。

「病院ＩＤ」は、病院を特定するための管理番号であり、この病院ＩＤにより、病院データベース１２１と収集データベース１２４の情報がリンク可能となる。「患者ＩＤ」は、各病院が独自に割り当てた患者の管理番号である。「予約日時」は、患者が予約した日時である。「受付」は、患者が来院して受付を行った時間である。例えば、各病院において、医療端末３３、例えば、受付事務員が操作するＰＣや患者が操作する自動受付機によって受付を行うことで、受付時間が当該患者に対応する電子カルテに記載される。「診療開始」は、患者に対する医師の診療が開始された時間である。「医師ＩＤ」は、診療を行う医師を特定する情報である。この医師ＩＤにより、病院データベース１２１と収集データベース１２４の情報がリンク可能となる。「診療終了」は、患者に対する医師の診療が終了した時間である。例えば、各病院において、医療端末３３、例えば、医師又は看護師が操作するＰＣによって診療開始時間、医師ＩＤ、診療終了時間を入力することで、それらの情報が当該患者に対応する電子カルテに記載される。「会計終了」は、患者が会計を済ませた時間である。例えば、各病院において、医療端末３３、例えば、会計事務員が操作するＰＣで支払い終了を入力することで、あるいは、患者が操作する自動会計機によって支払いを行うことで、会計終了時間が当該患者に対応する電子カルテに記載される。「初診フラグ」は、診療が初診であるか否かを示すもので、初診である場合に「１」がセットされる。「症状」は、患者の病名である。

なお、この図６の例は、電子カルテの記載内容の収集の際に、検査実施の記録が存在する診療回の情報を収集しないようにした場合を示している。検査を実施した診療回の情報も収集する場合には、収集データベース１２４は、例えば、項目として、更に検査実施の有無を示すフラグを設ける。多くの場合、初診の際に検査も実施されるので、この検査実施の有無を示すフラグとしては、「初診フラグ」が兼用されても良い。

図７は、評価データベース１２５の記憶内容の一例を示す図である。図７に示す例では、評価データベース１２５は、項目として、ユーザＩＤ、病院ＩＤ、病院スコア、診療科、診療科スコア、医師ＩＤ、総合スコア、時間スコア、症状別改善度スコア（例えば、高血圧改善度スコア、糖尿病改善度スコア、じんま疹改善度スコア、など）、などを有している。図７では、症状別改善度スコアの内の高血圧改善度スコアのみを示し、「高血圧」と記載している。

「ユーザＩＤ」は、ユーザを特定するための管理番号であり、このユーザＩＤにより、ユーザデータベース１２２と評価データベース１２５の情報がリンク可能となる。「病院ＩＤ」は、病院を特定するための管理番号であり、この病院ＩＤにより、病院データベース１２１と収集データベース１２４と評価データベース１２５の情報がリンク可能となる。「病院スコア」は、病院の評価結果を数値化した評価値である。ここでは最高点を１００点とした数値で示しているが、この数値表現は一例である。例えば、星５つを最高点として星の数で示したり、偏差値で表したりするなど、どのようなものであっても構わない。この「病院スコア」は、当該病院が有する全診療科の評価値の平均値とすることができる。「診療科」は、病院が有する診療科の情報であり、この診療科により、病院データベース１２１と評価データベース１２５の情報がリンク可能となる。「診療科スコア」は、診療科毎の評価値である。この「診療科スコア」は、当該診療科に属する全医師の評価値、例えば後述する総合スコア、の平均値とすることができる。

「医師ＩＤ」は、診療を行う医師を特定する情報である。この医師ＩＤにより、病院データベース１２１と収集データベース１２４と評価データベース１２５の情報がリンク可能となる。「総合スコア」は、医師毎の評価値である。この「総合スコア」は、当該医師についての時間評価値と、全改善度評価値の平均値や加重平均値との、加算値とすることができる。

「時間スコア」は、医師毎の、一患者当たりの診療時間と待ち時間とから評価した時間評価値である。時間評価値は、例えば、一患者当たりの診療時間の平均値と一患者当たりの待ち時間との平均値とに基づいて評価する。例えば、一患者当たりの診療時間の平均値については、予め決めた時間範囲に応じて、その平均値が長い程高い評価値とする。例えば、一患者当たりの診療時間の平均値が１０分以上であれば満点である１０点とし、１分減る毎に１点減らす、などとすることができる。また、一患者当たりの待機時間の平均値については、例えば、予め決めた時間範囲に応じて、その平均値が短い程高い評価値とする。例えば、一患者当たりの待機時間の平均値が３０分以内であれば満点の５０点とし、時間が２分増える毎に１点減らす、などとすることができる。「時間スコア」は、こうして得られた一患者当たりの診療時間の平均値による点数と一患者当たりの待ち時間の平均値による点数との合計点数とすることができる。

「症状別改善度スコア」は、各症状の改善度から評価した改善度評価値である。改善度評価値は、例えば、当該医師の診療を受けた患者の内、ユーザデータベース１２２に登録されていて生体データの一定期間の履歴を取得可能な患者について、その生体データの一定期間の履歴に基づいて症状がどれだけ改善したかにより、症状の改善度の評価値を求め、全ユーザの評価値の平均点とすることができる。例えば、症状が高血圧であれば、血圧値のデータから、一定期間、例えば一ヶ月間に、収縮期血圧が２０ｍｍＨｇ下がっていれば満点である１０点とし、低下量が１ｍｍＨｇ少なくなる毎に１点減らす、などとすることができる。

なお、「総合スコア」は、「時間スコア」と全「症状別改善度スコア」から算出されることができるが、本実施形態では、後述するように、更に、病院予約を求めるユーザが指定する優先条件や、ユーザの属性情報などを評価項目に加えることで、算出した「時間スコア」を補正し得る。

＜１−２＞動作
次に、図８及び図９を用いて、第１実施形態に係る病院予約システムの動作例について説明する。

図８は、サービスサーバの処理手順の一例を例示するフローチャートであり、図９は、ユーザ端末の処理手順の一例を例示するフローチャートである。

＜１−２−１＞生体データ収集動作
［ステップＳ１０１］
サービスサーバ１００のＣＰＵ１１１は、先ず、生体データを収集するべきタイミングになったか否かを判断する。本実施形態では、例えば、１日１回など、予め決めたタイミングで生体データを収集する。生体データを収集するべきタイミングであると判断した場合（ステップＳ１０１、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０２に進める。生体データを収集するべきタイミングではないと判断した場合（ステップＳ１０１、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。

［ステップＳ１０２］
上記ステップＳ１０１において生体データを収集するべきタイミングであると判断した場合（ステップＳ１０１、ＹＥＳ）、ＣＰＵ１１１は、生体データ収集処理を実行する。この生体データ収集処理においては、ＣＰＵ１１１は、通信インタフェース１３０により、ユーザデータベース１２２に登録されている各ユーザのユーザ端末２０に、当該ユーザ端末２０の記憶部２３に記憶されているＰＨＲの送信を依頼するＰＨＲ要求を送信し、これに応じて各ユーザ端末２０から送信されてきたＰＨＲを、ユーザデータベース１２２の対応するユーザの生体データ（「血圧」、「脈拍」、など）の項目に登録する。また、ＣＰＵ１１１は、ユーザデータベース１２２に登録した生体データの各項目の測定値又は計測値の関係を含む生体データの属性、つまり生体データのパターンに対応する症状を決定し、それをユーザデータベース１２２の症状パターンの項目に登録する。なお、この症状の決定は、どのような手法を用いても良い。例えば、予め生体データの多数のパターンに対し症状を選定して、データベース化しておき、このデータベース化されたパターンとユーザデータベース１２２に登録した生体データのパターンとのパターンマッチングにより、最も近似するパターンの症状を採用することができる。或いは、生体データの大量のパターンを機械学習しておくことで、ユーザデータベース１２２に登録した生体データのパターンに対応する症状を判定するようにしても良い。この生体データ収集処理終了後、ＣＰＵ１１１は、処理をステップＳ１０３に進める。

［ステップＳ２０１］
すなわち、ユーザ端末２０の制御部２１の図示しないプロセッサは、電子メールプログラムなどと同様にバックグラウンドで実行するアプリケーションプログラムの一つとして病院予約プログラムを実行しており、図示しない通信インタフェースによりサービスサーバ１００からＰＨＲ要求を受信したか否かを判断することができる。ＰＨＲ要求を受信していないと判断した場合（ステップＳ２０１、ＮＯ）、プロセッサは、処理をステップＳ２０２に進める。また、ＰＨＲ要求を受信したと判断した場合（ステップＳ２０１、ＹＥＳ）、プロセッサは、処理をステップＳ２０３に進める。

［ステップＳ２０２］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０１において、サービスサーバ１００からＰＨＲ要求を受信していないと判断した場合（ステップＳ２０１、ＮＯ）、図示しないユーザインタフェースを通じたユーザ操作が有ったか否かを判断する。何も操作が無いと判断した場合（ステップＳ２０２、ＮＯ）、プロセッサは、処理を上記ステップＳ２０１に戻す。また、何らかの操作が有ったと判断した場合（ステップＳ２０２、ＹＥＳ）、プロセッサは、処理をステップＳ２０４に進める。

［ステップＳ２０３］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０１において、サービスサーバ１００からＰＨＲ要求を受信したと判断した場合（ステップＳ２０１、ＹＥＳ）、ＰＨＲ送信処理を実行する。このＰＨＲ送信処理においては、プロセッサは、ＰＨＲ要求を受信したことをポップアップなどによりユーザ端末２０のユーザに報知する。これを確認したユーザが、送信を許可する操作を行ったならば、プロセッサは、図示しない通信インタフェースにより、記憶部２３に記憶しているＰＨＲをサービスサーバ１００に送信する。この場合、サービスサーバ１００からの要求に応えるため、ユーザ認証処理は行わなくても良い。また、送信を許可する操作が行われなかった場合には、ＰＨＲ要求を無視する、或いは、受信から所定時間待機後に拒否応答をサービスサーバ１００に返す。したがって、サービスサーバ１００の動作の上記ステップＳ１０２においては、生体データを収集できないユーザ端末が存在する。このＰＨＲ送信処理終了後、プロセッサは、処理を上記ステップＳ２０１に戻す。

＜１−２−２＞登録情報更新動作
［ステップＳ１０３］
サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０１において生体データを収集するべきタイミングではないと判断した場合（ステップＳ１０１、ＮＯ）、或いは、上記ステップＳ１０２の生体データ収集処理の終了後、病院データベース１２１の更新処理を実行する。例えば、ＣＰＵ１１１は、通信インタフェース１３０により、病院サーバ３０又はデータサーバ４０に更新の問合せを行って、或いは、病院サーバ３０又はデータサーバ４０から病院情報の更新要求を確認することで、更新が必要な病院について、病院データベース１２１を更新する。また、ＣＰＵ１１１は、新たな病院について、病院データベース１２１に追加することができる。この新規登録については、例えば、サービスサーバ１００の管理者が、サービスサーバ１００に直接又は通信ネットワークＮＥＴを介して接続された図示しない管理者端末を操作して実施できるようになっている。なお、このステップＳ１０３の更新処理では、病院データベース１２１の項目の内、病院ＩＤ、アクセス情報、病院情報、診療科、医師ＩＤ、性別、年齢を更新或いは新規登録するものであり、滞在人数や予約状況については更新しない。また、ＣＰＵ１１１は、任意のＷｅｂページなどから、主観的な病院評価情報や医師評価情報を検索し、その結果を、病院データベース１２１の病院評判及び医師評判の項目に登録することができる。なお、このステップＳ１０３の更新処理では、特に変更するべき情報が無く、病院データベース１２１の内容を何ら更新しない場合もあり得る。

［ステップＳ１０４］
サービスサーバ１００のＣＰＵ１１１は、ユーザデータベース１２２の更新処理を実行する。例えば、ＣＰＵ１１１は、通信インタフェース１３０により、ユーザ端末２０、或いは図示しない管理者端末からの操作により、更新が必要なユーザについて、ユーザデータベース１２２を更新する。ユーザ端末２０からの操作に応じた更新を行うには、ユーザ認証が必要であり、このステップＳ１０４の更新処理は、ユーザ認証処理を含む。また、ＣＰＵ１１１は、新たなユーザについて、ユーザデータベース１２２に追加することができる。なお、このステップＳ１０４の更新処理では、ユーザデータベース１２２の項目の内、ユーザＩＤ、パスワード、氏名、ユーザ情報、病院毎ＩＤ、地点、優先条件を更新或いは新規登録するものであり、生体データなど更新しない情報もあり得る。なお、病院毎ＩＤについては、ユーザ端末２０からの操作による入力を受け付けても良いし、ユーザ情報や地点（自宅住所）などをキーにして、当該ユーザの管理番号を各病院サーバ３０に問い合わせることで収集しても良い。なお、このステップＳ１０４の更新処理では、特に変更するべき情報が無く、ユーザデータベース１２２の内容を何ら更新しない場合もあり得る。

［ステップＳ１０５］
サービスサーバ１００のＣＰＵ１１１は、通信インタフェース１３０により、通信ネットワークＮＥＴを介して何れかのユーザ端末２０からＰＨＲを受信したか否かを判断する。ＰＨＲを受信していないと判断した場合（ステップＳ１０５、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１０６に進める。ＰＨＲを受信したと判断した場合（ステップＳ１０５、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０７に進める。

［ステップＳ１０６］
サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０５において何れかのユーザ端末２０からＰＨＲを受信していないと判断した場合（ステップＳ１０５、ＮＯ）、通信インタフェース１３０により、通信ネットワークＮＥＴを介して何れかのユーザ端末２０から評価要求を受信したか否かを判断する。なお、この判断は、ユーザ認証処理を含む。評価要求を受信していないと判断した場合（ステップＳ１０６、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１０１に戻す。ユーザ認証がなされて評価要求を受信したと判断した場合（ステップＳ１０６、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０８に進める。

［ステップＳ２０４］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０２において何らかの操作が有ったと判断した場合（ステップＳ２０２、ＹＥＳ）、その操作は、測定部２２による生体データの取得指示であるか否かを判断する。この生体データの取得指示は、ユーザ端末２０が備える測定部２２による生体データの測定の指示を含むことができる。また、生体データの取得指示は、ユーザ端末２０と通信可能な生体データ計測装置２４で計測された生体データの取得の指示であっても良い。生体データの取得指示が有ったと判断した場合（ステップＳ２０４、ＹＥＳ）、プロセッサは、処理をステップＳ２０５に進める。行われた操作は生体データの取得指示ではないと判断した場合（ステップＳ２０４、ＮＯ）、プロセッサは、処理をステップＳ２０８に進める。

［ステップＳ２０５］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０４において生体データの取得指示が有ったと判断した場合（ステップＳ２０４、ＹＥＳ）、生体データ取得処理を実行する。この生体データ取得処理においては、ユーザ端末２０が備える測定部２２によって生体データを測定することで、生体データを取得する。或いは、ユーザ端末２０と通信可能な生体データ計測装置２４で生体データを計測し、その計測した生体データを通信により取得する。

［ステップＳ２０６］
ユーザ端末２０の制御部２１の図示しないプロセッサは、記憶部２３に蓄積しているＰＨＲに、この取得した生体データを追加記録する。

［ステップＳ２０７］
そして、ユーザ端末２０の制御部２１の図示しないプロセッサは、この記憶部２３に蓄積したＰＨＲを、図示しない通信インタフェースにより通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。この場合、そのＰＨＲが誰の生体データであるのかを特定し得るように、ユーザＩＤを付して、ＰＨＲを送信する。また、必ずしも記憶部２３に記憶しているＰＨＲの全データを送信しなくても良い。例えば、最新の生体データのみを送信するようにしても良いし、最新から一定期間あるいは一定数の生体データを送信するのであっても良い。その後、プロセッサは、処理を上記ステップＳ２０１に戻す。

［ステップＳ１０７］
サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０５において何れかのユーザ端末２０からＰＨＲを受信したと判断した場合（ステップＳ１０５、ＹＥＳ）、その受信したＰＨＲに基づいて、ユーザデータベース１２２の、対応するユーザの日付や生体データ（「血圧」、「脈拍」、など）、症状パターンの項目を更新する。この場合、受信したＰＨＲとユーザデータベース１２２に登録されている生体データとを比較して、差分のみを追加更新することができる。既に予め決められた期間分又は予め決められた数の生体データがユーザデータベース１２２の対応するユーザに対し記憶されている場合には、最も古い情報が削除されて追加される。また、受信したＰＨＲが、１日に当たり何回分もの生体データを含む場合には、最初の１回分の生体データのみを追加するようにしても良いし、最後の１回分の生体データのみを追加するようにしても良い。例えば、血圧は、起床後の測定データが特に有効な情報であるため、最初の１回分の生体データを用いることが望ましい。よって、複数回分の何れを採用するかは、生体データの種類により決めても良い。このユーザデータベース１２２の更新が終了したならば、ＣＰＵ１１１は、処理を上記ステップＳ１０６に進める。

＜１−２−３＞電子カルテ収集及び評価動作
［ステップＳ２０８］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０４において行われた操作は生体データの取得指示ではないと判断した場合（ステップＳ２０４、ＮＯ）、行われた操作は医療評価の取得指示であるか否かを判断する。医療評価の取得指示が有ったと判断した場合（ステップＳ２０８、ＹＥＳ）、プロセッサは、処理をステップＳ２０９に進める。行われた操作は医療評価の取得指示ではないと判断した場合（ステップＳ２０８、ＮＯ）、プロセッサは、処理をステップＳ２１０に進める。

［ステップＳ２０９］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０８において医療評価の取得指示が有ったと判断した場合（ステップＳ２０８、ＹＥＳ）、評価処理を実行する。図１０は、この評価処理の一例を例示するフローチャートである。

［ステップＳ２０９１］
ユーザ端末２０の図示しないプロセッサは、図示しないユーザインタフェースを通じたユーザ操作による、評価条件の入力を受け付ける。評価条件は、優先条件を含むことができる。また、評価条件は、評価結果を提示する対象が病院であるのか、医師であるのかを示す評価対象条件を含むことができる。なお、病院が複数の診療科を有する場合が有るので、評価対象条件は、病院の代わりに診療科であっても良い。

［ステップＳ２０９２］
そして、ユーザ端末２０のプロセッサは、その入力された評価条件を付けて、評価要求を、通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。この際、評価要求には、ユーザ認証のためのユーザＩＤ及びパスワードと、ユーザ端末２０の現在位置を示す位置情報とが含まれることができる。また、記憶部２３にＰＨＲとして蓄積している生体データの内の最新のものも併せて送信するようにしても良い。

［ステップＳ２０９３］
その後、ユーザ端末２０のプロセッサは、通信ネットワークＮＥＴを介してサービスサーバ１００からの予約候補を受信するのを待つ。すなわち、プロセッサは、予約候補を受信したか否かを判断し、受信していない場合（ステップＳ２０９３、ＮＯ）、このステップＳ２０９３の処理を繰り返す。

［ステップＳ１０８］
サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０６において評価要求を受信したと判断した場合（ステップＳ１０６、ＹＥＳ）、受信した評価要求に含まれるユーザＩＤ及びパスワードによりユーザ認証を行った上で、同じく評価要求に含まれる位置情報と、評価要求と共に送られる評価条件に含まれる優先条件とにより、ユーザデータベース１２２を更新する。すなわち、ＣＰＵ１１１は、ユーザデータベース１２２の、該当するユーザに関する地点における現在位置と優先条件とを、受信した情報に更新する。また、ＣＰＵ１１１は、受信した評価条件に含まれる評価対象条件を、ＲＡＭ１１２または記憶部１２０に記憶する。なお、最新の生体データも送信されてきた場合には、ユーザデータベース１２２に登録されている生体データと比較し、必要であれば追加登録する。

［ステップＳ１０９］
ここで、ＣＰＵ１１１は、評価対象とする病院又は医師を限定する。例えば、ＣＰＵ１１１は、まず、ユーザデータベース１２２の該当するユーザの最新の生体データに対応する症状パターンの項目から症状を読み出し、読み出した症状を検索キーにして対応関係データベース１２３を検索し、病院又は医師を限定する。そして更に、ＣＰＵ１１１は、この生体データの属性、つまり生体データのパターンによって限定した病院又は医師の中から評価対象とする病院又は医師を、ユーザデータベース１２２の該当するユーザの優先条件項目に記憶された情報の内、位置を規定する情報によって限定する。すなわち、ＣＰＵ１１１は、例えば優先条件が「現在地」であれば、ユーザデータベース１２２の該当するユーザの地点項目に記憶されている現在位置により、病院データベース１２１の病院情報に記憶されている住所との距離が所定範囲内の病院又は医師を、評価対象として限定する。同様にして、優先条件が「自宅」であれば自宅の住所、「職場」であれば職場の住所、「登録位置」であれば登録位置により、評価対象の病院又は医師を限定することができる。

なお、この評価対象の病院又は医師の絞り込みの手法に関しては、先に位置情報により限定し、その後に生体データのパターンによって限定するようにしても構わない。また、病院と医師の何れを評価対象とするかは、ＲＡＭ１１２または記憶部１２０に記憶した評価要求元のユーザ端末２０からの評価対象条件に従う。

ＣＰＵ１１１は、この限定した評価対象病院の病院ＩＤのリスト又は評価対象医師の医師ＩＤと該当医師が所属する病院の病院ＩＤのリストを、ＲＡＭ１１２または記憶部１２０に記憶する。評価対象が医師であっても、病院側が医師を指定した予約ができない場合が有り得るので、評価対象の医師が所属する病院も評価対象としている。

［ステップＳ１１０］
ＣＰＵ１１１は、限定した病院の電子カルテの内容を収集する電子カルテ収集処理を実行する。図１１は、この電子カルテ収集処理の一例を例示するフローチャートである。

［ステップＳ１１０１］
電子カルテ収集処理においては、ＣＰＵ１１１は、まず、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、取得先病院を決定する。

［ステップＳ１１０２］
次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、データサーバ４０からその取得先病院の電子カルテの内容を取得する。例えば、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して、当該病院を特定する特定情報、例えば病院ＩＤ、アクセス情報、病院名、住所または電話番号を読み出す。そして、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介してデータサーバ４０の制御部４１に、この特定情報と共に電子カルテの記載内容の送信を依頼する。ＣＰＵ１１１は、これに応答してデータサーバ４０から送信されてきた電子カルテの内容を通信インタフェース１３０により受信する。

なお、取得先病院の電子カルテの数が多い場合には、処理時間が掛かることが想定されるため、電子カルテのタイムスタンプにより最新のものから、人数や期間を限定した送信を依頼するようにしても良い。

［ステップＳ１１０３］
次に、ＣＰＵ１１１は、受信した電子カルテの内容に基づいて、病院データベース１２１及び収集データベース１２４に情報を登録する。例えば、ＣＰＵ１１１は、患者ＩＤ毎に、電子カルテに記載された、各回の診療に関する情報、つまり予約日時、受付、診療開始、医師ＩＤ、診療終了、会計終了、初診フラグ、症状を収集データベース１２４に記憶する。なお、本実施形態では、受信した電子カルテに検査実施が記録されている場合には、ＣＰＵ１１１は、その診療回の診療に関する情報を収集データベース１２４に記憶しないようにしている。また、ＣＰＵ１１１は、電子カルテの内容に基づいて、医師ＩＤ毎に、現時点の診療待ち患者人数を集計し、病院データベース１２１の各医師ＩＤに対応させて集計した人数を「待ち」の項目に記憶する。

［ステップＳ１１０４］
次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、その取得先病院から予約患者数を取得する。例えば、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して当該病院のアクセス情報を読み出し、通信インタフェース１３０により通信ネットワークＮＥＴを介して当該病院の病院サーバ３０の制御部３１に、各医師についての現在時点の予約患者数を問い合わせる。現在時点の診療待ち患者人数は電子カルテの内容を集計することで判るが、初診の予約を依頼した患者については未だ電子カルテが存在しないので、受信した電子カルテの内容からだけでは予約患者数を把握することができない。そのため、取得先病院へ予約患者数の問合せが必要となる。ＣＰＵ１１１は、この問い合わせに応答して病院サーバ３０から送信されてきた予約患者数の情報を通信インタフェース１３０により受信する。

［ステップＳ１１０５］
次に、ＣＰＵ１１１は、受信した各医師についての現在時点での予約患者数の情報に従って、病院データベース１２１の各医師ＩＤに対応させて「予約状況」の項目に予約患者数を記憶する。

［ステップＳ１１０６］
次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて電子カルテの内容の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合（ステップＳ１１０６、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１１０１に戻し、次の病院に対する処理を行う。リストアップした全ての病院から電子カルテの内容の収集が終了したと判断した場合（ステップＳ１１０６、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１１１に進める。

［ステップＳ１１１］
ＣＰＵ１１１は、収集データベース１２４に記憶した限定した病院それぞれの電子カルテの内容に基づいて評価値を算出する評価算出処理を実行する。図１２は、この評価算出処理の一例を例示するフローチャートである。

［ステップＳ１１１１］
評価算出処理においては、ＣＰＵ１１１は、まず、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、処理対象病院を決定する。

［ステップＳ１１１２］
次に、ＣＰＵ１１１は、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、病院ＩＤにより収集データベース１２４を参照して、処理対象病院の医師毎の時間スコアを算出する。時間スコアは、例えば、一患者当たりの診療時間の平均値による点数と待ち時間の平均値による点数との合計に基づいて算出されることができる。診療時間は、収集データベース１２４に記憶された診療開始から診療終了までの時間であり、待ち時間は、収集データベース１２４に記憶された受付から診療開始までの時間と、診療終了から会計終了までの時間との合計である。ＣＰＵ１１１は、算出した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。なお、多くの場合、初診の際には診療時間が長くなるので、収集データベース１２４の「初診フラグ」により初診か否かを判定し、時間スコアの算出に用いる時間は、初診であれば予め決められた係数を乗じた上で用いられるようにしても良い。

［ステップＳ１１１３］
次に、ＣＰＵ１１１は、医師の属性情報とユーザの属性情報との関係を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、属性情報に基づいて補正する。属性情報は、例えば、性別や年齢を含む。ＣＰＵ１１１は、病院データベース１２１に記憶された各医師の属性情報と、ユーザデータベース１２２に記憶された、評価要求元のユーザのユーザＩＤに対応する属性情報とを比較する。そして、例えば同性であればスコアを高くしたり、年齢が近いほどスコアを高くしたりする等、予め決めた規則に則って、スコア値を補正する。ＣＰＵ１１１は、補正した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１１４］
次に、ＣＰＵ１１１は、ユーザ端末２０から優先条件として指定された位置情報と病院の位置との関係を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、上記属性情報に基づいて補正してＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、優先条件に基づいて補正する。ＣＰＵ１１１は、ユーザデータベース１２２に記憶された、評価要求元のユーザのユーザＩＤに対応する優先条件を参照し、優先条件として指定された位置情報が、病院データベース１２１に記憶された当該病院の住所に対して一定の距離以内である場合には、スコア値を高くする。ＣＰＵ１１１は、補正した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１１５］
その後、ＣＰＵ１１１は、時事の診療待ち患者人数及び予約患者数を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、上記優先条件に基づいて補正してＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、診療待ち患者人数及び予約患者数に基づいて補正する。ＣＰＵ１１１は、病院データベース１２１に記憶された医師毎の診療待ち患者人数と予約患者数とを集計し、その集計した人数が少ないほど、スコア値を高くする。ＣＰＵ１１１は、補正した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１１６］
次に、ＣＰＵ１１１は、ユーザデータベース１２２と収集データベース１２４とを参照して、医師毎の症状別改善度スコアを算出する。例えば、ユーザデータベース１２２の各ユーザの病院毎ＩＤに基づいて、収集データベース１２４から当該ユーザの症状を取得し、その症状と同じ症状のユーザを特定する。また、その症状に応じて参照するべき生体データを決定する。そして、ＣＰＵ１１１は、その特定されたユーザが、ユーザデータベース１２２に登録されていれば、そのユーザの症状により決定された生体データの一定期間の履歴をユーザデータベース１２２から読み出して評価する。例えば、症状が高血圧であれば、ＣＰＵ１１１は、一定期間の血圧値を読み出して評価する。

図１３は、この読み出した生体データの履歴の一例を示す図である。この図の例では、一定期間Ｐの間に、収縮期血圧がＤだけ下がっている。例えば、収縮期血圧の一定期間Ｐ、例えば一ヶ月間の低下量Ｄが２０ｍｍＨｇ以上であれば満点である１０点とし、低下量が１ｍｍＨｇ少なくなる毎に１点減らす、などとスコアを決定する。

図１４は、生体データの履歴の別の例を示す図である。この図の例も、一定期間Ｐの間の収縮期血圧の低下量Ｄが、図１３の例と同じスコアとなる範囲であったとする。しかしこの例では、一時的に悪化した履歴が含まれている。このような場合、そのまま図１３の例と同じスコアとしても良いが、図１３の例よりも低く算出しても良い。特に、一時的に悪化した状態から改善へ転じたタイミングが、別の病院や医師への切り替わりが有ったタイミングであった場合、一時的に悪化した状態が誤診によるものである可能性が高い。ＣＰＵ１１１は、例えば、収集データベース１２４の予約日時項目に記録された日付と、ユーザデータベース１２２の日付項目に記録された日付及び通院フラグ項目に記録された通院の記録とに基づいて、この誤診の可能性を判断し、その結果に応じてスコアを修正することができる。

ＣＰＵ１１１は、こうして算出した医師毎の症状別改善度スコアをＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１１７］
次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した医師毎の、症状別改善度スコアと補正後の時間スコアとから、総合スコアを算出する。更に、ＣＰＵ１１１は、医師毎の総合スコアから、診療科スコア及び病院スコアを算出する。ＣＰＵ１１１は、こうして算出した医師毎の総合スコア、診療科スコア及び病院スコアをＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１１８］
そして、ＣＰＵ１１１は、こうして算出してＲＡＭ１１２または記憶部１２０に記憶した各スコアを、評価データベース１２５に、ユーザＩＤに対応させて登録する。このように、属性情報や優先条件などに基づいて時間スコアを補正することで、図７に示すように、同じ医師、診療科、病院であっても、ユーザ毎に異なるスコア値が評価データベース１２５に登録されることになる。

［ステップＳ１１１９］
次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて評価値の算出が終了したか否かを判断する。未だ評価値を算出していない病院があると判断した場合（ステップＳ１１１９、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１１１１に戻し、次の病院に対する処理を行う。リストアップした全ての病院について評価値の算出が終了したと判断した場合（ステップＳ１１１９、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１１２に進める。

［ステップＳ１１２］
ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した評価対象条件に従って、評価データベース１２５に記憶されている評価要求元のユーザのユーザＩＤに対応する評価結果を読み出してソートする。例えば、評価対象条件が病院であれば、病院ＩＤと病院スコアの組を読み出して、病院スコアが高い順にソートする。また、例えば、評価対象条件が医師であれば、医師ＩＤと総合スコアの組を読み出して、総合スコアが高い順にソートする。ＣＰＵ１１１は、ソートした結果を、ＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１３］
そして、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶しているソートした結果に基づいて予約候補を決定して、通信インタフェース１３０により通信ネットワークＮＥＴを介して、評価要求元のユーザ端末２０に送信する。予約候補の数は、少なくとも一つ有れば良いが、ユーザに選択肢を与えるために複数決定して送信することが望ましい。勿論、ユーザ端末２０からの折り返しの指示により、順次に次候補を決定して送信するようにしても構わない。予約候補は、ＲＡＭ１１２または記憶部１２０に記憶した評価対象条件に従って決定される。例えば、評価対象条件が病院であれば、少なくとも病院の名称や住所を含む病院情報と、その病院のスコア値とを含むことができる。病院情報は、病院データベース１２１より取得することができる。また、例えば、評価対象条件が医師であれば、少なくとも医師の氏名、性別、年齢を含む医師情報及び当該医師のスコア値と、当該医師が所属する病院の病院情報及び当該病院のスコア値と、を含むことができる。医師情報及び病院情報は、病院データベース１２１より取得することができる。

［ステップＳ２０９４］
上記ステップＳ２０９３において予約候補を受信したと判断した場合（ステップＳ２０９３、ＹＥＳ）、ユーザ端末２０のプロセッサは、処理をステップＳ２０９４に進め、その受信した予約候補を図示しないユーザインタフェースによりユーザに提示する。

＜１−２−４＞予約動作
［ステップＳ１１４］
上記ステップＳ１１３において予約候補を送信後、サービスサーバ１００のＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、当該ユーザ端末２０からの予約要求を受信したか否かを判断する。予約要求を受信していないと判断した場合（ステップＳ１１４、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１１５に進める。

［ステップＳ２０９５］
また、ユーザ端末２０の図示しないプロセッサは、上記ステップＳ２０９４において受信した予約候補をユーザに提示した後、図示しないユーザインタフェースを通じたユーザ操作による、終了又は予約の入力を受け付ける。予約の入力は、予約を望む病院または医師の選択と、希望日時の入力とを含む。

［ステップＳ２０９６］
そして、ユーザ端末２０のプロセッサは、受け付けた入力が終了の入力であるか否かを判断する。受け付けた入力が終了の入力ではない、つまり予約の入力であると判断した場合（ステップＳ２０９６、ＮＯ）、プロセッサは、処理をステップＳ２０９７に進める。

［ステップＳ２０９７］
上記ステップＳ２０９６において予約の入力を受け付けたと判断した場合（ステップＳ２０９６、ＮＯ）、ユーザ端末２０のプロセッサは、予約要求を、通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。

［ステップＳ２０９８］
その後、ユーザ端末２０のプロセッサは、通信ネットワークＮＥＴを介してサービスサーバ１００からの予約結果を受信するのを待つ。すなわち、プロセッサは、予約結果を受信したか否かを判断し、受信していない場合（ステップＳ２０９８、ＮＯ）、このステップＳ２０９８の処理を繰り返す。

［ステップＳ１１６］
サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１１４において予約要求を受信したと判断した場合（ステップＳ１１４、ＹＥＳ）、処理をステップＳ１１６に進め、通信インタフェース１３０により通信ネットワークＮＥＴを介して、該当病院の病院サーバ３０へ、予約要求を、ユーザデータベース１２２に記憶されている当該ユーザのＰＨＲと共に送信する。全生体データを含むＰＨＲではなく、最新の生体データのみで有っても良い。またこのとき、ＣＰＵ１１１は、ユーザデータベース１２２の病院毎ＩＤを参照して、もし当該ユーザが該当病院における管理番号を有するユーザであることが確認できた場合には、この予約要求にその管理番号を含めることができる。

［ステップＳ１１７］
その後、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、該当病院の病院サーバ３０からの予約結果を受信するのを待つ。すなわち、ＣＰＵ１１１は、予約結果を受信したか否かを判断し、受信していないと判断した場合（ステップＳ１１７、ＮＯ）、このステップＳ１１７を繰り返す。

患者の予約管理を行う病院サーバ３０では、この予約要求に応じた予約処理を行う。そして、その結果を通信ネットワークＮＥＴを介してサービスサーバ１００に返す。

［ステップＳ１１８］
上記ステップＳ１１７において予約結果を受信したと判断した場合（ステップＳ１１７、ＹＥＳ）、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、予約要求元のユーザ端末２０へ予約結果を送信する。その後、ＣＰＵ１１１は、処理を上記ステップＳ１１４に戻す。

［ステップＳ２０９９］
上記ステップＳ２０９８において予約結果を受信したと判断した場合（ステップＳ２０９８、ＹＥＳ）、ユーザ端末２０のプロセッサは、処理をステップＳ２０９９に進め、その受信した予約結果を図示しないユーザインタフェースによりユーザに提示する。その後、プロセッサは、処理を上記ステップＳ２０９５に戻す。

もし、所望の予約が取れないという予約結果であったならば、ステップＳ２０９５において、ユーザは別の予約希望日時を再設定したり、別の病院、別の医師などを選択したりすることが可能である。また、所望の予約が取れた場合には、ユーザは医療評価の処理を終了するために、終了の入力を行う。

＜１−２−５＞終了動作
［ステップＳ２０９１０］
ユーザ端末２０の図示しないプロセッサは、上記ステップＳ２０９６において受け付けた入力が終了の入力であると判断した場合（ステップＳ２０９６、ＹＥＳ）、処理をステップＳ２０９１０に進め、終了要求を、通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。そして、プロセッサは、処理を上記ステップＳ２０１に戻す。

［ステップＳ１１５］
サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１１４において予約要求を受信していないと判断した場合（ステップＳ１１４、ＮＯ）、更に、通信インタフェース１３０により通信ネットワークＮＥＴを介して、当該ユーザ端末２０からの終了要求を受信したか否かを判断する。終了要求を受信していないと判断した場合（ステップＳ１１５、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１１４に戻す。終了要求を受信したと判断した場合（ステップＳ１１５、ＹＥＳ）、ＣＰＵ１１１は、処理を上記ステップＳ１０１に戻す。

＜１−２−６＞その他の処理
［ステップＳ２１０］
ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０８において行われた操作は医療評価の取得指示ではないと判断した場合（ステップＳ２０８、ＮＯ）その操作に応じた、その他の処理を実行する。このその他の処理は、例えば、サービスサーバ１００の上記ステップＳ１０４でのユーザデータベース１２２の更新処理を行うための当該ユーザの新規登録操作や情報更新操作に応じた処理を含む。そして、処理実行後、プロセッサは、処理を上記ステップＳ２０１に戻す。

＜１−３＞効果
上述した第１実施形態によれば、サービスサーバ１００のＣＰＵ１１１が、複数の病院の間で電子カルテを共有するための電子カルテネットワーク１から各電子カルテの記載内容を収集すると共に、各ユーザのユーザ端末２０から複数のユーザそれぞれの生体データの一定期間の履歴を収集し、これら収集した情報に基づいて、少なくとも病院毎、更には各病院の診療科毎または各病院の医師毎に、少なくとも一患者当たりの診療時間及び待ち時間に基づく時間スコアと、各ユーザの症状の改善度に基づく症状別改善度スコアとを算出して、評価データベース１２５に記憶する。よって、時間という客観的な指標と症状の改善度というユーザの症状の改善状況とに基づいて、少なくとも病院を、更には病院の診療科または医師を評価することができるようになる。そして、ＣＰＵ１１１は、この評価スコアをユーザ端末２０に送信してユーザに提示することで、ユーザは、自身が診療を受けようとする病院、診療科又は医師を、この提示されたスコアを参考にして、選定することが可能となる。

また、第１実施形態によれば、評価結果を評価値つまりスコアという数値で求めていることで、その数値により評価結果を順番付けでき、その結果、ユーザに適した予約候補を容易に決定することができる。

また、第１実施形態によれば、対応関係データベース１２３を用いることで、容易且つ迅速に評価対象の病院又は医師を限定することができる。

また、第１実施形態によれば、病院予約サービスに加入するユーザの各ユーザ端末２０からＰＨＲを収集することで、ユーザの生体データを容易に収集することができる。

また、第１実施形態によれば、時間的評価だけでなく、症状の改善度という症状の改善状況に基づいた評価を加えることで、よりユーザに適した候補を提供することができる。

また、第１実施形態によれば、スコア値という点数化した評価値を用い、予約候補をその数値と共にユーザ端末２０に送信して提示することで、ユーザが予約する病院を選定する際の指標を提供することができ、ユーザの選定を容易にすることが可能となる。

また、第１実施形態によれば、評価要求元のユーザの性別又は年齢と医師の性別又は年齢とにも基づいて評価するので、ユーザに適した医師を高く評価することができ、ユーザにより適した医師を候補とすることができるようになる。

また、第１実施形態によれば、評価要求元のユーザの現在位置やユーザが指定した指定位置に応じて、ユーザが通い得る病院を限定することで、ユーザに不適切な病院を候補として提示する可能性を小さくすることができる。

また、第１実施形態によれば、病院又は医師の評価値を算出する際に、現時点における診療待ち患者人数と今後の予約状況とを参照し、待ち時間少なく直ぐに診療可能な病院や医師ほど高スコアとすることで、ユーザが予期せず空き時間が取れたときや、急に具合が悪くなったときなど、今すぐ診療可能な病院を探す場合に、有効な手段を提供することができる。

なお、今すぐ診療可能な病院を探す場合には、ユーザ端末２０における上記ステップＳ２０９１の条件入力の際に、その点を指定できるようにすることで、上記ステップＳ１１１５における診療待ち患者人数及び予約患者数に基づいた補正の重みを重くする、つまりスコア値を高くするようにしても良い。あるいは、上記ステップＳ１１１３の属性情報に基づく補正や上記ステップＳ１１１４における優先条件に基づく補正の重みを軽くしたり、それらの補正をスキップしたりできるようにしても良い。

また、上述したような病院予約システムによってユーザが病院予約を行った場合、サービスサーバ１００は、予約先の病院から紹介料金を徴収できる課金処理の手順を有しても良い。

また、病院は、上述したようなサービスサーバ１００の処理手順によって予約されたユーザに対しては、紹介状を不要又は減額とするようなサービスを提供するようにしても良い。

＜２＞第２実施形態
次に、第２実施形態について説明する。

＜２−１＞構成及び＜２−２＞動作
本第２実施形態に係る病院予約システムの基本的な構成及び基本的な動作は、上述した第１実施形態に係る病院予約システムと同様である。従って、上述した第１実施形態で説明した事項及び上述した第１実施形態から容易に類推可能な事項についての説明は省略する。

図１５は、第２実施形態におけるサービスサーバ１００の処理手順の一例を例示するフローチャートである。図８と同様の処理については同じ参照符号を付す。

＜２−２−１＞収集動作
［ステップＳ１１９］
サービスサーバ１００のＣＰＵ１１１は、先ず、生体データ及び電子カルテを収集するべきタイミングになったか否かを判断する。本実施形態では、例えば、１日１回など、予め決めたタイミングで生体データ及び電子カルテを収集する。生体データ及び電子カルテを収集するべきタイミングではないと判断した場合（ステップＳ１１９、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。生体データ及び電子カルテを収集するべきタイミングであると判断した場合（ステップＳ１１９、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０２に進める。

［ステップＳ１０２］
上記ステップＳ１０１において生体データ及び電子カルテを収集するべきタイミングであると判断した場合（ステップＳ１０１、ＹＥＳ）、ＣＰＵ１１１は、先ず、上記第１実施形態と同様の生体データ収集処理を実行する。

［ステップＳ１２０］
次に、ＣＰＵ１１１は、電子カルテ収集処理を実行する。この場合、上記第１実施形態におけるステップＳ１１０の電子カルテ収集処理と異なり、対象病院の限定を行っていないので、ＣＰＵ１１１は、限定されない、つまり全ての病院の電子カルテの内容を収集することとなる。図１６は、この電子カルテ収集処理の一例を例示するフローチャートである。

［ステップＳ１２０１］
電子カルテ収集処理においては、ＣＰＵ１１１は、まず、病院データベース１２１に登録されている病院ＩＤの中から一つの病院ＩＤを選択することで、取得先病院を決定する。

［ステップＳ１２０２］
次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、データサーバ４０からその取得先病院の電子カルテの内容を取得する。このステップＳ１２０２の処理は、上記第１実施形態におけるステップＳ１１０２の処理と同様である。すなわち、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して、当該病院を特定する特定情報、例えば病院ＩＤ、アクセス情報、病院名、住所または電話番号を読み出す。そして、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介してデータサーバ４０の制御部４１に、この特定情報と共に電子カルテの記載内容の送信を依頼する。ＣＰＵ１１１は、これに応答してデータサーバ４０から送信されてきた電子カルテの内容を通信インタフェース１３０により受信する。

なお、取得先病院の電子カルテの数が多い場合には、処理時間が掛かることが想定されるため、電子カルテのタイムスタンプにより最新のものから、人数や期間を限定した送信を依頼するようにしても良い。

［ステップＳ１２０３］
次に、ＣＰＵ１１１は、受信した電子カルテの内容に基づいて、病院データベース１２１及び収集データベース１２４に情報を登録する。例えば、ＣＰＵ１１１は、患者ＩＤ毎に、電子カルテに記載された、各回の診療に関する情報、つまり予約日時、受付、診療開始、医師ＩＤ、診療終了、会計終了、初診フラグ、症状を収集データベース１２４に記憶する。

［ステップＳ１２０４］
次に、ＣＰＵ１１１は、病院データベース１２１に登録されている病院ＩＤで示される病院の全てについて電子カルテの内容の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合（ステップＳ１２０４、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１２０１に戻し、次の病院に対する処理を行う。登録されている全ての病院から電子カルテの内容の収集が終了したと判断した場合（ステップＳ１２０４、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。

＜２−２−２＞登録情報更新動作
［ステップＳ１０３］〜［ステップＳ１０８］
ＣＰＵ１１１は、上記ステップＳ１１９において生体データ及び電子カルテを収集するべきタイミングではないと判断した場合（ステップＳ１１９、ＮＯ）、或いは、上記ステップＳ１１０の電子カルテ収集処理の終了後、上記第１実施形態と同様の［ステップＳ１０１］乃至［ステップＳ１０６］の処理を行う。但し、上記ステップＳ１０６において評価要求を受信していないと判断した場合（ステップＳ１０６、ＮＯ）の処理の戻り先は、上記ステップＳ１１９である。すなわち、ＣＰＵ１１１は、病院データベース１２１の更新処理とユーザデータベース１２２の更新処理とを行う。そして、ＣＰＵ１１１は、何れかのユーザ端末２０からＰＨＲ又は評価要求を受信したか否かを判断する。何れも受信していないと判断した場合、ＣＰＵ１１１は、処理を上記ステップＳ１１９に戻す。ＰＨＲを受信したと判断した場合には、ＣＰＵ１１１は、受信したＰＨＲに基づいて、ユーザデータベース１２２の、対応するユーザの日付や生体データ（「血圧」、「脈拍」、など）の項目を更新する。また、評価要求を受信したと判断した場合には、ＣＰＵ１１１は、受信した評価要求に含まれるユーザＩＤ及びパスワードによりユーザ認証を行った上で、同じく評価要求に含まれる位置情報及び評価要求に含まれる優先条件により、ユーザデータベース１２２を更新する。

＜２−２−３＞評価動作
［ステップＳ１０９］
評価要求を受信してユーザデータベース１２２を更新した後、ＣＰＵ１１１は、上記第１実施形態と同様に、評価対象の病院を限定する。

［ステップＳ１２１］
その後、ＣＰＵ１１１は、上記ステップＳ１０９で限定した病院それぞれにおける現在時点の診療待ち患者人数と予約患者数を集計する人数収集処理を行う。すなわち、上記ステップＳ１２０では、例えば、１日１回など、予め決めたタイミングで電子カルテの内容を収集するので、診療待ち患者人数と予約患者数の集計は行っていない。そこで、ＣＰＵ１１１は、それら人数を収集する。図１７は、この人数収集処理の一例を例示するフローチャートである。

［ステップＳ１２１１］
人数収集処理においては、ＣＰＵ１１１は、まず、ＲＡＭ１１２または記憶部１２０に記憶した限定した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、取得先病院を決定する。

［ステップＳ１２１２］
次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、その取得先病院から診療待ち患者人数及び予約患者数を取得する。例えば、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して当該病院のアクセス情報を読み出し、通信インタフェース１３０により通信ネットワークＮＥＴを介して当該病院の病院サーバ３０の制御部３１に、各医師についての現在時点の診療待ち患者人数と予約患者数とを問い合わせる。そして、ＣＰＵ１１１は、この問い合わせに応答して病院サーバ３０から送信されてきた診療待ち患者人数及び予約患者数の情報を通信インタフェース１３０により受信する。

［ステップＳ１２１３］
次に、ＣＰＵ１１１は、受信した各医師についての現在時点での診療待ち患者人数及び予約患者数の情報に従って、病院データベース１２１の各医師ＩＤに対応させて「待ち」及び「予約状況」の項目にそれぞれの人数を記憶する。

［ステップＳ１２１４］
次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて人数の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合（ステップＳ１２１４、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１２１１に戻し、次の病院に対する処理を行う。リストアップした全ての病院から人数の収集が終了したと判断した場合（ステップＳ１２１４、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１１１に進める。

［ステップＳ１１１］〜［ステップＳ１１３］
その後、ＣＰＵ１１１は、上記第１実施形態と同様の［ステップＳ１１１］乃至［ステップＳ１１３］の処理を行う。すなわち、ＣＰＵ１１１は、収集データベース１２４に記憶した各病院の電子カルテの内容の内、この限定した病院の内容に基づいてのみ、評価値を算出する。その後、ＣＰＵ１１１は、評価条件に含まれる評価対象条件に従って、評価データベース１２５に記憶されている評価要求元のユーザのユーザＩＤに対応する評価結果を読み出してソートし、そのソートした結果と評価対象条件に従って予約候補を決定する。そしてＣＰＵ１１１は、その決定した予約候補を、通信インタフェース１３０により通信ネットワークＮＥＴを介して、評価要求元のユーザ端末２０に送信する。

＜２−２−４＞予約動作、＜２−２−５＞終了動作
［ステップＳ１１４］〜［ステップＳ１１８］
その後の［ステップＳ１１４］乃至［ステップＳ１１８］の処理は、上記第１実施形態と同様である。但し、上記ステップＳ１１５において終了要求を受信したと判断した場合（ステップＳ１１５、ＹＥＳ）の処理の戻り先は、上記ステップＳ１１９である。

＜２−３＞効果
上述した第２実施形態によれば、上記第１実施形態と同様の効果を奏することができる。また、この第２実施形態では、電子カルテの記載内容を予め全ての病院について収集しておくので、ユーザからの評価要求に応じて直ちに評価値の算出処理を実行でき、レスポンス良くユーザに評価結果を提示することが可能になる。

＜３＞第３実施形態
次に、第３実施形態について説明する。

＜３−１＞構成及び＜３−２＞動作
本第３実施形態に係る病院予約システムの基本的な構成及び基本的な動作は、上述した第２実施形態に係る病院予約システムと同様である。従って、上述した第２実施形態で説明した事項及び上述した第２実施形態から容易に類推可能な事項についての説明は省略する。

図１８は、第３実施形態におけるサービスサーバ１００の処理手順の一例を例示するフローチャートである。図１５と同様の処理については同じ参照符号を付す。

＜３−２−１＞収集動作及び第１評価動作
［ステップＳ１１９］、［ステップＳ１０２］、［ステップＳ１２０］
サービスサーバ１００のＣＰＵ１１１は、先ず、上記第２実施形態と同様に、生体データ及び電子カルテを収集するべきタイミングになったか否かを判断する。生体データ及び電子カルテを収集するべきタイミングであると判断した場合（ステップＳ１１９、ＹＥＳ）、ＣＰＵ１１１は、上記第２実施形態と同様の［ステップＳ１０２］及び［ステップＳ１２０］の処理を行う。すなわち、ＣＰＵ１１１は、上記第１実施形態と同様の生体データ収集処理と上記第２実施形態と同様の電子カルテ収集処理とを実行する。

［ステップＳ１２２］
その後、ＣＰＵ１１１は、収集データベース１２４に記憶した各病院の電子カルテの内容に基づいて評価値を算出する第１評価算出処理を実行する。この第１評価算出処理においては、評価値として、医師毎の時間スコアを算出する。図１９は、この第１評価算出処理の一例を例示するフローチャートである。

［ステップＳ１２２１］
第１評価算出処理においては、ＣＰＵ１１１は、まず、病院データベース１２１に登録されている病院ＩＤの中から一つの病院ＩＤを選択することで、処理対象病院を決定する。

［ステップＳ１１１２］
次に、ＣＰＵ１１１は、上記第１実施形態と同様に、病院ＩＤにより収集データベース１２４を参照して、処理対象病院の医師毎の時間スコアを算出する。ＣＰＵ１１１は、算出した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１２２２］
次に、ＣＰＵ１１１は、算出してＲＡＭ１１２または記憶部１２０に記憶した当該病院に所属する各医師の時間スコアを、評価データベース１２５における該当する医師ＩＤに対応する総合スコアの項目に登録する。

［ステップＳ１２２３］
そして、ＣＰＵ１１１は、病院データベース１２１に記憶されている病院ＩＤで示される病院の全てについて評価値の算出が終了したか否かを判断する。未だ評価値を算出していない病院があると判断した場合（ステップＳ１２２３、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１２１１に戻し、次の病院に対する処理を行う。全ての病院について評価値の算出が終了したと判断した場合（ステップＳ１２２３、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。

＜３−２−２＞登録情報更新動作
［ステップＳ１０３］〜［ステップＳ１０８］
［ステップＳ１０３］乃至［ステップＳ１０８］の処理は、上記第１実施形態と同様である。

＜３−２−３＞第２評価動作
［ステップＳ１０９］
評価要求を受信してユーザデータベース１２２を更新した後、サービスサーバ１００のＣＰＵ１１１は、上記第１実施形態と同様、ユーザデータベース１２２の該当するユーザの優先条件項目に記憶された情報の内、位置を規定する情報により、評価対象の病院を限定する。

［ステップＳ１２１］
次に、ＣＰＵ１１１は、上記第２実施形態と同様に、上記ステップＳ１０９で限定した病院それぞれにおける現在時点の診療待ち患者人数と予約患者数の問合せを行って、結果を病院データベース１２１に登録する人数収集処理を行う。

［ステップＳ１２３］
その後、ＣＰＵ１１１は、収集データベース１２４に記憶した各病院の電子カルテの内容に基づいて評価値を算出する第２評価算出処理を実行する。図２０は、この第２評価算出処理の一例を例示するフローチャートである。

［ステップＳ１１１１］
第２評価算出処理においては、ＣＰＵ１１１は、上記第１実施形態と同様に、まず、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、処理対象病院を決定する。

［ステップＳ１２３１］
そして、その処理対象病院に所属する各医師の医師ＩＤを病院データベース１２１により取得し、その医師ＩＤに対応する時間スコアを、評価データベース１２５における該当医師ＩＤに対応する総合スコアの項目から読み出し、ＲＡＭ１１２または記憶部１２０に記憶する。

［ステップＳ１１１３］〜［ステップＳ１１１９］
その後の［ステップＳ１１１３］乃至［ステップＳ１１１９］の処理は、上記第１実施形態と同様である。すなわち、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、属性情報及び優先条件に基づいて補正し、更に、診療待ち患者人数及び予約患者数に基づいて補正する。また、ＣＰＵ１１１は、ユーザデータベース１２２と収集データベース１２４とを参照して、医師毎の症状別改善度スコアを算出する。そして、ＣＰＵ１１１は、医師毎の、症状別改善度スコアと補正後の時間スコアとから、総合スコアを算出し、更に、この医師毎の総合スコアから、診療科スコア及び病院スコアを算出し、算出した各スコアを、評価データベース１２５に、ユーザＩＤに対応させて登録する。その後、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて評価値の算出が終了したか否かを判断し、未だ評価値を算出していない病院があれば、処理を上記ステップＳ１１１１に戻し、次の病院に対する処理を行う。そして、リストアップした全ての病院について評価値の算出が終了したと判断した場合、ＣＰＵ１１１は、処理をステップＳ１１２に進める。

［ステップＳ１１２］、［ステップＳ１１３］
その後の［ステップＳ１１２］及び［ステップＳ１１３］の処理は、上記第１実施形態と同様である。すなわち、ＣＰＵ１１１は、評価条件に含まれる評価対象条件に従って、評価データベース１２５に記憶されている評価要求元のユーザのユーザＩＤに対応する評価結果を読み出してソートし、そのソートした結果と評価対象条件に従って予約候補を決定する。そしてＣＰＵ１１１は、その決定した予約候補を、通信インタフェース１３０により通信ネットワークＮＥＴを介して、評価要求元のユーザ端末２０に送信する。

＜３−２−４＞予約動作、＜３−２−５＞終了動作
［ステップＳ１１４］〜［ステップＳ１１８］
その後の［ステップＳ１１４］乃至［ステップＳ１１８］の処理は、上記第１実施形態と同様である。但し、上記ステップＳ１１５において終了要求を受信したと判断した場合（ステップＳ１１５、ＹＥＳ）の処理の戻り先は、上記ステップＳ１１９である。

＜３−３＞効果
上述した第３実施形態によれば、上記第２実施形態と同様の効果を奏することができる。また、この第３実施形態では、ユーザに依存しない評価値を予め算出しておくので、ユーザからの評価要求に応じて直ちにユーザに依存する評価値の算出処理を実行でき、レスポンス良くユーザに評価結果を提示することが可能になる。

この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除しても良い。さらに、異なる実施形態に亘る構成要素を適宜組み合せても良い。

例えば、フローチャートを参照して説明した処理手順は一例に過ぎず、各処理は可能な限り変更されて良い。また、説明した処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られるものではない。

（付記１）
複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワーク（１）と、
前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部（１１）と、
通信ネットワーク（ＮＥＴ）を介して、複数のユーザそれぞれの生体データを収集する生体データ収集部（１２）と、
前記通信ネットワークを介して、ユーザ端末（２０）から要求を受け付ける受付部（１３）と、
前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部（１４）と、
前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部（１５）と、
前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部（１６）と、
前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部（３１）と、
前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部（１７）と、
を具備する、病院予約システム。

（付記２）
プロセッサ（１１１）及びメモリ（１１２，１２０）を有するサーバ装置が実行する病院予約方法であって、
前記プロセッサにより、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集して前記メモリに記憶する過程（Ｓ１１０）と、
前記プロセッサにより、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集して前記メモリに記憶する過程（Ｓ１０２）と、
前記プロセッサにより、前記通信ネットワークを介して、ユーザ端末から評価要求を前記ユーザ端末のユーザの生体データと共に受け付ける過程（Ｓ１０６）と、
前記ユーザ端末からの前記評価要求に応じて、前記プロセッサにより、前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記メモリに記憶された前記複数のユーザそれぞれの前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する過程（Ｓ１０９）と、
前記プロセッサにより、前記メモリに記憶された前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記評価対象として限定された前記複数の病院又は医師を評価し、その評価結果を前記メモリに記憶する過程（Ｓ１１１）と、
前記プロセッサにより、前記メモリに記憶された前記複数の病院又は医師の評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる過程（Ｓ１１３）と、
前記プロセッサにより、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求を、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付ける過程（Ｓ１１４）と、
前記要求元の前記ユーザ端末からの前記病院又は医師に対する予約要求に応じて、前記プロセッサにより、前記通信ネットワークを介して、その依頼された前記病院又は医師に該当する病院が備える患者の予約管理を行う病院制御部に、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する過程（Ｓ１１６）と、
を備える病院予約方法。

（付記３）
請求項１０に記載のサーバ装置が具備する前記電子カルテ収集部（１１）、前記生体データ収集部（１２）、前記受付部（１３）、前記限定部（１４）、前記評価部（１５）、前記提示部（１６）、及び前記予約部（１７）としてプロセッサを機能させる病院予約プログラム。

１…電子カルテネットワーク
１０…サービスサーバ
１１…電子カルテ収集部
１２…生体データ収集部
１３…受付部
１４…限定部
１５…評価部
１６…提示部
１７…予約部
１８…対応関係データベース
１９…医師属性取得部
２０…ユーザ端末
２１，３１，４１，１１０…制御部
２２…測定部
２３，３２，４２，１２０…記憶部
２４…生体データ計測装置
３０…病院サーバ
３３…医療端末
４０…データサーバ
１００…サービスサーバ
１１１…ＣＰＵ
１１２…ＲＡＭ
１１３…ＲＯＭ
１２１…病院データベース
１２２…ユーザデータベース
１２３…対応関係データベース
１２４…収集データベース
１２５…評価データベース
１３０…通信インタフェース

Claims (10)

1. 複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークと、
   前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部と、
   通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、
   前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、
   前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、
   前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、
   前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、
   前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部と、
   前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、
   を具備する、病院予約システム。
2. 前記評価部は、前記複数の病院又は医師の評価結果を表す評価値を算出し、
   前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させる、請求項１に記載の病院予約システム。
3. 前記生体データ収集部によって収集した前記生体データの属性に応じて病院又は医師をデータベース化した対応関係データベースを更に具備し、
   前記限定部は、前記要求元の前記ユーザ端末の前記ユーザの前記生体データの属性により、前記対応関係データベースを参照して、前記評価対象となる前記複数の病院又は医師を限定する、請求項１に記載の病院予約システム。
4. 前記生体データ収集部は、それぞれユーザの生体データを収集する複数のユーザ端末それぞれから送信されたユーザの生体データを、前記通信ネットワークを介して受信する、請求項１に記載の病院予約システム。
5. 前記生体データ収集部は、前記複数のユーザそれぞれの生体データの履歴を収集し、
   前記評価部によって評価する評価項目は、更に、前記生体データ収集部によって収集した前記生体データの一定期間の履歴に基づく症状の改善度を含む、
   請求項１に記載の病院予約システム。
6. 前記評価部は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とし、
   前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させる、請求項１に記載の病院予約システム。
7. 前記各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得する医師属性取得部を更に具備し、
   前記受付部は、更に、前記要求元の前記ユーザ端末の前記ユーザの属性情報を受け付け、
   前記評価部によって評価する評価項目は、更に、前記医師属性取得部により取得される前記医師の属性情報と、前記受付部によって受け付けた前記要求元の前記ユーザ端末の前記ユーザの属性情報との関係を含む、請求項１に記載の病院予約システム。
8. 前記受付部は、更に、前記要求元の前記ユーザ端末から位置情報を受け付け、
   前記限定部は、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報に基づいて、前記評価対象となる前記複数の病院又は医師を限定し、
   前記評価部によって評価する評価項目は、更に、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報と、前記評価対象の前記病院の位置との関係を含む、請求項１に記載の病院予約システム。
9. 前記病院制御部は、更に、前記病院の時事の滞在中患者の時間管理を行い、
   前記評価部は、前記病院制御部にアクセスして、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを取得し、
   前記評価部によって評価する評価項目は、更に、前記取得した診療待ち患者人数及び予約患者数を含む、請求項１に記載の病院予約システム。
10. 複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集する電子カルテ収集部と、
    通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、
    前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、
    前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、
    前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、
    前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、
    前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部の内、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、
    を具備する、サーバ装置。