(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-08-29
(45)【発行日】2022-09-06
(54)【発明の名称】病院予約システム及びサーバ装置
(51)【国際特許分類】
G16H 40/20 20180101AFI20220830BHJP
【FI】
G16H40/20
(21)【出願番号】P 2018138465
(22)【出願日】2018-07-24
【審査請求日】2021-06-10
(73)【特許権者】
【識別番号】503246015
【氏名又は名称】オムロンヘルスケア株式会社
(74)【代理人】
【識別番号】100108855
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100103034
【氏名又は名称】野河 信久
(74)【代理人】
【識別番号】100153051
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100179062
【氏名又は名称】井上 正
(74)【代理人】
【識別番号】100189913
【氏名又は名称】鵜飼 健
(74)【代理人】
【識別番号】100199565
【氏名又は名称】飯野 茂
(72)【発明者】
【氏名】出野 徹
(72)【発明者】
【氏名】土屋 直樹
(72)【発明者】
【氏名】濱口 貴広
(72)【発明者】
【氏名】和田 洋貴
(72)【発明者】
【氏名】佐藤 博則
(72)【発明者】
【氏名】湯本 将彦
(72)【発明者】
【氏名】山内 隆伸
(72)【発明者】
【氏名】松岡 和
【審査官】山内 裕史
(56)【参考文献】
【文献】特開2005-196510(JP,A)
【文献】特開2004-355275(JP,A)
【文献】特開2018-112941(JP,A)
【文献】特開2003-303238(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
G16H 10/00 - 80/00
(57)【特許請求の範囲】
【請求項1】
複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークと、
前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部と、
通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、
前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、
前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、
前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、
前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、
前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部と、
前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、
を具備する、病院予約システム。
【請求項2】
前記評価部は、前記複数の病院又は医師の評価結果を表す評価値を算出し、
前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させる、請求項1に記載の病院予約システム。
【請求項3】
前記生体データ収集部によって収集した前記生体データの属性に応じて病院又は医師をデータベース化した対応関係データベースを更に具備し、
前記限定部は、前記要求元の前記ユーザ端末の前記ユーザの前記生体データの属性により、前記対応関係データベースを参照して、前記評価対象となる前記複数の病院又は医師を限定する、請求項1に記載の病院予約システム。
【請求項4】
前記生体データ収集部は、それぞれユーザの生体データを収集する複数のユーザ端末それぞれから送信されたユーザの生体データを、前記通信ネットワークを介して受信する、請求項1に記載の病院予約システム。
【請求項5】
前記生体データ収集部は、前記複数のユーザそれぞれの生体データの履歴を収集し、
前記評価部によって評価する評価項目は、更に、前記生体データ収集部によって収集した前記生体データの一定期間の履歴に基づく症状の改善度を含む、
請求項1に記載の病院予約システム。
【請求項6】
前記評価部は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とし、
前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させる、請求項1に記載の病院予約システム。
【請求項7】
前記各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得する医師属性取得部を更に具備し、
前記受付部は、更に、前記要求元の前記ユーザ端末の前記ユーザの属性情報を受け付け、
前記評価部によって評価する評価項目は、更に、前記医師属性取得部により取得される前記医師の属性情報と、前記受付部によって受け付けた前記要求元の前記ユーザ端末の前記ユーザの属性情報との関係を含む、請求項1に記載の病院予約システム。
【請求項8】
前記受付部は、更に、前記要求元の前記ユーザ端末から位置情報を受け付け、
前記限定部は、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報に基づいて、前記評価対象となる前記複数の病院又は医師を限定し、
前記評価部によって評価する評価項目は、更に、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報と、前記評価対象の前記病院の位置との関係を含む、請求項1に記載の病院予約システム。
【請求項9】
前記病院制御部は、更に、前記病院の時事の滞在中患者の時間管理を行い、
前記評価部は、前記病院制御部にアクセスして、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを取得し、
前記評価部によって評価する評価項目は、更に、前記取得した診療待ち患者人数及び予約患者数を含む、請求項1に記載の病院予約システム。
【請求項10】
複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集する電子カルテ収集部と、
通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、
前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、
前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、
前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、
前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、
前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部の内、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、
を具備する、サーバ装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、病院予約システム及びサーバ装置に関する。
【背景技術】
【0002】
例えば、特許文献1は、複数の医師それぞれに対する評価に基づいて、患者が自己の病気に関する治療を受ける上で適切な医師を選定できるようにした技術を提案している。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記特許文献1では、医師の評価は、その医師に関する情報を他の複数の医師に提示して、この情報に基づいて他の医師が評価するというものであり、主観的な評価になり易い。客観的な指標に基づいてユーザに適する医師又は医師が所属する病院の候補をユーザに提示し、その中からユーザが選定して予約することはできていない。
【0005】
本発明は、上記の事情に着目してなされたものであり、その目的は、客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる病院予約システム及びサーバ装置を提供することである。
【課題を解決するための手段】
【0006】
本発明は、上述した課題を解決するために、以下の構成を採用する。
【0007】
本開示の一態様では、病院予約システムは、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークと、前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部と、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部と、前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、を具備する。
なお、病院とは、ある建物の一室と言った小規模の病院から、一つの敷地内に複数の病棟が配置された大規模病院、更には、複数地域に分散した系列病院を含む病院グループであって良い。病院グループの場合、電子カルテは、グループ内の病院毎に分散配置される場合もある。また、電子カルテは、病院内ではなく、電子カルテネットワーク内に設けられたデータセンタに配置されても良い。ここで、配置とは、記憶媒体を備える記憶部に記憶されることを含む。電子カルテのデータフォーマットは、病院毎に異なっていても良く、各病院の電子カルテが電子カルテネットワーク内の統一フォーマットに変換されて、データセンタの記憶部に蓄積されることができる。各病院とデータセンタとの間の電子カルテの送受信においては、データ暗号化などにより、秘匿性が担保される。電子カルテネットワーク内では、医療従事者毎に制限されたアクセス権限が与えられて、各医療従事者が操作する医療端末から当該病院またはデータセンタに配置された電子カルテの情報の閲覧や更新が可能になっている。また、電子カルテネットワーク内では、患者であるユーザ毎に制限されたアクセス権限が与えられて、各ユーザが操作するユーザ端末からデータセンタに配置された自身の電子カルテの情報を閲覧できるようになっている場合もある。この場合も、ユーザ端末とデータセンタとの間のデータ送受信においては、データ暗号化などにより、秘匿性が担保されることが望ましい。
上記の構成の病院予約システムによれば、任意のユーザ端末からの評価要求に応じて、そのユーザ端末のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、その評価結果に基づいて予約候補をユーザに提示し、評価要求元のユーザ端末のユーザの選定に従って、病院の予約を行うので、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定でき、また、その選定に応じて病院を簡便に予約することができるようになる。
【0008】
なお、上記一態様において、前記評価部は、前記複数の病院又は医師の評価結果を表す評価値を算出し、前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させることができる。
当該構成によれば、評価値という数値を用いることで評価値の順番に並べ替えることができ、ユーザに適した予約候補を容易に提示することができる。
【0009】
また、上記一態様において、病院予約システムは、前記生体データ収集部によって収集した前記生体データの属性に応じて病院又は医師をデータベース化した対応関係データベースを更に具備し、前記限定部は、前記要求元の前記ユーザ端末の前記ユーザの前記生体データの属性により、前記対応関係データベースを参照して、前記評価対象となる前記複数の病院又は医師を限定するようにしても良い。
当該構成によれば、データベースを用いることで、容易且つ迅速に評価対象の病院又は医師を限定することができるようになる。
【0010】
また、上記一態様において、前記生体データ収集部は、それぞれユーザの生体データを収集する複数のユーザ端末それぞれから送信されたユーザの生体データを、前記通信ネットワークを介して受信することができる。
当該構成によれば、病院予約サービスに加入するユーザの各ユーザ端末から生体データを収集することで、生体データを容易に収集することができる。
【0011】
また、上記一態様において、前記生体データ収集部は、前記複数のユーザそれぞれの生体データの履歴を収集し、前記評価部によって評価する評価項目は、更に、前記生体データ収集部によって収集した前記生体データの一定期間の履歴に基づく症状の改善度を含むことができる。
当該構成によれば、症状の改善度という症状の改善状況に基づいた評価を加えることで、よりユーザに適した候補を提供することができるようになる。
【0012】
また、上記一態様において、前記評価部は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とし、前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させることができる。
当該構成によれば、点数化した評価値を用い、予約候補をその数値と共に提示することで、ユーザが予約する病院を選定する際の指標を提供することができ、ユーザの選定を容易にすることが可能となる。
【0013】
また、上記一態様において、病院予約システムは、前記各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得する医師属性取得部を更に具備し、前記受付部は、更に、前記要求元の前記ユーザ端末の前記ユーザの属性情報を受け付け、前記評価部によって評価する評価項目は、更に、前記医師属性取得部により取得される前記医師の属性情報と、前記受付部によって受け付けた前記要求元の前記ユーザ端末の前記ユーザの属性情報との関係を含むことができる。
当該構成によれば、評価値を提示するべきユーザの性別又は年齢と医師の性別又は年齢とにも基づいて評価するので、ユーザに適した医師を高く評価することができ、ユーザにより適した医師を候補とすることができるようになる。
【0014】
また、上記一態様において、前記受付部は、更に、前記要求元の前記ユーザ端末から位置情報を受け付け、前記限定部は、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報に基づいて、前記評価対象となる前記複数の病院又は医師を限定し、前記評価部によって評価する評価項目は、更に、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報と、前記評価対象の前記病院の位置との関係を含むことができる。
当該構成によれば、評価要求元のユーザの現在位置やユーザが指定した指定位置に応じて、ユーザが通い得る病院を限定することで、ユーザに不適切な病院を候補として提示する可能性を小さくすることができる。
【0015】
また、上記一態様において、前記病院制御部は、更に、前記病院の時事の滞在中患者の時間管理を行い、前記評価部は、前記病院制御部にアクセスして、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを取得し、前記評価部によって評価する評価項目は、更に、前記取得した診療待ち患者人数及び予約患者数を含むことができる。
当該構成によれば、各病院の現時点での待ち時間を考慮して病院または医師の候補を提示することが可能になる。
【0016】
本開示の別の態様では、サーバ装置は、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集する電子カルテ収集部と、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部の内、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、を具備する。
当該構成によれば、任意のユーザ端末からの評価要求に応じて、サーバ装置において、そのユーザ端末のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、その評価結果に基づいた予約候補を評価要求元のユーザ端末に送信してユーザに提示し、また、そのユーザ端末のユーザの選定に従って、病院の予約を行うので、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定できるようになり、また、その選定に応じて病院を簡便に予約することができるようになる。
【発明の効果】
【0017】
本発明によれば、客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる技術を提供することができる。
【図面の簡単な説明】
【0018】
【
図1】
図1は、実施形態に係る病院予約システムの構成の一例を模式的に例示するブロック図である。
【
図2】
図2は、第1実施形態に係る病院予約システムの全体構成の一例を示すブロック図である。
【
図3】
図3は、病院データベースの記憶内容の一例を示す図である。
【
図4】
図4は、ユーザデータベースの記憶内容の一例を示す図である。
【
図5】
図5は、対応関係データベースの記憶内容の一例を示す図である。
【
図6】
図6は、収集データベースの記憶内容の一例を示す図である。
【
図7】
図7は、評価データベースの記憶内容の一例を示す図である。
【
図8】
図8は、サービスサーバの処理手順の一例を例示するフローチャートである。
【
図9】
図9は、ユーザ端末の処理手順の一例を例示するフローチャートである。
【
図11】
図11は、
図8中の電子カルテ収集処理の一例を例示するフローチャートである。
【
図13】
図13は、生体データの履歴の一例を説明するための図である。
【
図14】
図14は、生体データの履歴の別の例を説明するための図である。
【
図15】
図15は、第2実施形態に係る病院予約システムにおけるサービスサーバの処理手順の一例を例示するフローチャートである。
【
図18】
図18は、第3実施形態に係る病院予約システムにおけるサービスサーバの処理手順の一例を例示するフローチャートである。
【発明を実施するための形態】
【0019】
以下、本発明の実施形態を、図面に基づいて説明する。
【0020】
[適用例]
まず、
図1を参照して、本発明が適用される場面の一例について説明する。
図1は、実施形態に係る病院予約システムの構成の一例を模式的に例示する。
【0021】
[適用例の構成]
図1の例では、病院予約システムは、インターネットなどの通信ネットワークNETにそれぞれ接続された、電子カルテネットワーク(EHR:Electronic Health Records)1とサービスサーバ10とを含む。サービスサーバ10は、通信ネットワークNETを介して、複数のユーザ端末20と接続され得る。
【0022】
電子カルテネットワーク1は、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテ(EMR:Electronic Medical Records)を、複数の病院の間で共有するためのネットワークである。電子カルテネットワーク1は、例えば、複数の病院それぞれに設けられた病院サーバ30と、データセンタに設けられたデータサーバ40とが、通信ネットワークNETを介して接続されて構成される。なお、電子カルテネットワーク1は、通信ネットワークNETとして、インターネットではなくて、専用の通信回線を使用するものであっても構わない。但し、データサーバ40は、サービスサーバ10が通信ネットワークNETを介して当該データサーバ40にアクセスできるようにする構成を持つ必要がある。
【0023】
各病院の病院サーバ30は、例えば、制御部31と、この制御部31に接続された記憶部32と、図示しない通信インタフェースを有することができる。また、病院サーバ30には、例えば、病院内の医師、看護師、検査技師、事務員などの医療従事者が操作するパーソナルコンピュータ(PC)、来院した患者が操作する自動受付機や自動会計機、などの各種の医療端末33が、病院内LAN(Local Area Network)などを介して接続されている。病院内LANは、有線LANであっても良いし、無線LANであっても良く、また、有線と無線とが混在したLANであっても良い。なお、特に図示はしていないが、病院サーバ30には、患者の血圧値などの生体データを計測する生体データ計測装置、患者の内部画像を撮影するCT(Computerized Tomography)装置などの内部画像撮影装置、などを含む各種の検査機器も病院内LANなどを介して接続可能となっている。
【0024】
病院は、ある建物の一室と言った小規模の病院から、一つの敷地内に複数の病棟が配置された大規模病院、更には、複数地域に分散した系列病院を含む病院グループであって良い。病院グループの場合、グループ内の病院毎に病院サーバ30が配されても良いし、一つの病院サーバ30が一つの主管病院に配置され、各系列病院の医療端末33が専用通信回線などを介して病院サーバ30に接続されていても良い。或いは、グループ内の病院毎に病院サーバ30の制御部31のみが設けられ、記憶部32は、一つの主管病院の病院サーバ30にのみ配置されても良い。
【0025】
病院サーバ30における制御部31は、図示はしないが、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)などのプロセッサと、RAM(Random Access Memory)やROM(Read Only Memory)などのメモリと、を含むことができる。ROMは、例えば、プロセッサが実行するプログラムを記憶する。RAMは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部31は、様々な動作を行うことができる。
【0026】
記憶部32は、例えば、制御部31のプロセッサにより実行されるプログラム、プログラムを実行するために必要な設定データ、及び各種データベースを記憶することができる。制御部31のプロセッサにより実行されるプログラムは、例えば、電子カルテの閲覧や更新を行う電子カルテ管理プログラム、患者の予約を管理する予約管理プログラム、病院に滞在中の各患者についての受付時間などを管理する時間管理プログラム、などを含むことができる。プログラムを実行するために必要な設定データは、例えば、データセンタのデータサーバ40のアクセスアドレス、などを含むことができる。データベースは、例えば、医療端末33を操作する医療従事者の権限やパスワードなどを含む各医療従事者情報を記憶する医療従事者データベース、各患者の電子カルテ(EMR)を記憶する電子カルテデータベース、予約状況を記憶する予約データベース、などを含むことができる。なお、各病院の記憶部32は、上記したようなプログラム、設定データ、及びデータベースの全てを記憶することは必須ではなく、また、上記した以外のプログラム、設定データ、及びデータベースを記憶していても良い。記憶部32が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部32が備える記憶媒体は、EEPROM(登録商標)(Electrically Erasable, Programmable Read-Only Memory)などを使用することができる。なお、この記憶部32についても、制御部31のプロセッサがワークメモリとして使用するようにしても良い。
【0027】
制御部31のプロセッサは、例えば、記憶部32に記憶された電子カルテ管理プログラムを実行することで、各医療端末33の操作に応じて、記憶部32に記憶している電子カルテの記載内容を医療端末33に表示させたり、電子カルテの記載内容を更新したりすることができる。また、制御部31のプロセッサは、例えば、図示しない検査機器からの検査データを、電子カルテに追記することも可能である。さらに、制御部31のプロセッサは、例えば、図示しない通信インタフェースにより、通信ネットワークNET又は専用の通信回線を介してデータサーバ40と通信することができる。通信インタフェースによる通信は、特定の通信方式に限定されるものではない。但し、データサーバ40との通信においては、データ暗号化などにより、秘匿性を担保することが必要である。制御部31のプロセッサは、例えば、記憶部32に記憶している電子カルテを、データセンタのデータサーバ40に送信することができる。この場合、制御部31のプロセッサは、電子カルテを、電子カルテネットワーク1の共通のデータフォーマットに変換し、例えば暗号化した上で、送信することができる。逆に、制御部31のプロセッサは、他の病院で作成されてデータサーバ40に共通フォーマットで蓄積されている電子カルテを、データサーバ40から受信して、それを例えば復号化し、当該病院の電子カルテのフォーマットに変化した上で、記憶部32の電子カルテデータベースに登録することができる。
【0028】
また、制御部31のプロセッサは、例えば、記憶部32に記憶された予約管理プログラムを実行することで、医療端末33からの予約、或いは通信ネットワークNETを介したサービスサーバ10又はユーザ端末20からの予約を受け付けて、予約データベースを時事更新することができる。
【0029】
更に、制御部31のプロセッサは、例えば、記憶部32に記憶された時間管理プログラムを実行することで、各患者の受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を取得して、その病院の時事の滞在中患者それぞれの時間管理を行うこともできる。なお、制御部31のプロセッサは、例えば、上記電子カルテ管理プログラムを実行することで、この取得した各患者の受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報を各患者の電子カルテに記載することができる。
【0030】
データセンタのデータサーバ40は、例えば、制御部41と、この制御部41に接続された記憶部42と、図示しない通信インタフェースを有することができる。制御部41は、図示はしないが、例えば、CPUやMPUなどのプロセッサと、RAMやROMなどのメモリと、を含むことができる。ROMは、例えば、プロセッサが実行するプログラムを記憶する。RAMは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部41は、様々な動作を行うことができる。
【0031】
記憶部42は、例えば、制御部41のプロセッサにより実行されるプログラム、プログラムを実行するために必要な設定データ、及び各種データベースを記憶することができる。制御部41のプロセッサにより実行されるプログラムは、例えば、各病院サーバ30から通信ネットワークNET又は専用の通信回線を介して送信されてきた電子カルテを処理する電子カルテ処理プログラム、サービスサーバ10やユーザ端末20と送信するための通信プログラム、などを含むことができる。データベースは、例えば、医療端末33を操作する医療従事者やユーザ端末20を操作するユーザの権限やパスワード、サービスサーバ10の権限などを記憶するアクセス権限データベース、病院サーバ30から受信した各患者の電子カルテ(EMR)を記憶する電子カルテデータベース、などを含むことができる。なお、記憶部42は、上記した以外のプログラムやデータベースを記憶していても良い。記憶部42が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部42が備える記憶媒体は、EEPROMなどを使用することができる。なお、この記憶部42についても、制御部41のプロセッサがワークメモリとして使用するようにしても良い。
【0032】
制御部41のプロセッサは、例えば、記憶部42に記憶された電子カルテ処理プログラムを実行することで、通信ネットワークNET又は専用の通信回線を介して、各病院サーバ30と通信し、それぞれの病院サーバ30から送信されてきた例えば暗号化された電子カルテを例えば復号化して、記憶部42の電子カルテデータベースに登録することができる。逆に、制御部41のプロセッサは、各病院の病院サーバ30からの要求に応じて、記憶部42の電子カルテデータベースに共通フォーマットで蓄積されている電子カルテを、例えば暗号化して、要求元の病院サーバ30に送信することができる。
【0033】
また、
図1の例では、病院Cは、病院サーバ30の記憶部32が電子カルテデータベースを備えていない。このような構成の病院サーバ30では、データサーバ40の記憶部42に記憶された電子カルテが、仮想的に、その病院Cの病院サーバ30が備える電子カルテとして使用されることができる。そのため、制御部41のプロセッサは、例えば、記憶部42に記憶された電子カルテ処理プログラムを実行することで、通信ネットワークNET又は専用の通信回線とその病院Cの病院サーバ30とを介して、医療端末33からの操作情報を取得して、電子カルテに対する処理が行えるようになっている。また、制御部41のプロセッサは、例えば、記憶部42に記憶された通信プログラムを実行することで、通信ネットワークNETを介して、サービスサーバ10或いはユーザ端末20と通信することができる。
【0034】
なお、上記のように、病院サーバ30の制御部31が電子カルテネットワーク1の共通のデータフォーマットに、記憶部32に記憶している独自のデータフォーマットの電子カルテを変換してから送信することは必須ではない。各病院の病院サーバ30からは独自のデータフォーマットの電子カルテを、例えば暗号化した上で、データセンタに送信しても良い。この場合には、それを受信したデータサーバ40の制御部41において、受信した電子カルテを例えば復号化し、データフォーマットを電子カルテネットワーク1の共通のデータフォーマットに変換して、記憶部42の電子カルテデータベースに記憶すれば良い。また、逆に、各病院の病院サーバ30へ電子カルテを送信する際には、データサーバ40の制御部41において、共通データフォーマットの電子カルテを各病院独自のデータフォーマットに変換してから、例えば暗号化して、送信するようにすれば良い。
【0035】
電子カルテネットワーク1内では、医療従事者毎に制限されたアクセス権限が与えられて、各医療従事者は、医療端末33から、アクセスが許可された自病院の病院サーバ30の記憶部32又はデータセンタのデータサーバ40の記憶部42に記憶された電子カルテの情報を閲覧できる。また、権限が与えられていれば、各医療従事者は、医療端末33から、電子カルテの更新も可能である。
【0036】
ユーザ端末20は、通信ネットワークNETへの接続機能を備えた一般的なスマートホン(スマホ)やタブレット型端末のようなスマートデバイスであって良い。ユーザ端末20は、例えば、制御部21と、この制御部21に接続された測定部22及び記憶部23と、図示しない通信ネットワークNETに接続するための通信インタフェースと、ユーザインタフェースと、を有することができる。また、ユーザ端末20は、生体データ計測装置24と接続されることができる。通信インタフェースは、例えば、Wi-Fi(登録商標)モジュールを含むことができる。通信インタフェースは、例えば、図示しないWi-Fi基地局を経由して、インターネットなどの通信ネットワークNETに接続され、通信ネットワークNETを介して、サービスサーバ10及び電子カルテネットワーク1のデータサーバ40と通信することができる。ユーザインタフェースは、液晶ディスプレイとその表示画面上に配置されたタッチパネル、及びスマートデバイスの筐体に設けられた操作ボタンを含む。
【0037】
ユーザ端末20における制御部21は、図示はしないが、例えば、CPUやMPUなどのプロセッサと、RAMやROMなどのメモリと、を含むことができる。ROMは、例えば、プロセッサが実行するプログラムを記憶する。RAMは、例えば、プロセッサがワークメモリとして使用するメモリである。
【0038】
測定部22は、ユーザの各種生体データを測定する。例えば、測定部22は、一般にスマートデバイスが備えるカメラとLEDフラッシュライトを光電脈波計(PPG(Photo Plethysmography)センサ)として利用して、脈拍数を測定することができる。また、圧力センサを加えることで、血圧測定を行い得るスマートデバイスも知られている。
【0039】
生体データ計測装置24は、心電や脈拍、血圧、体重、体脂肪率、など様々な生体データを、一つ又は複数計測可能な機器である。この生体データ計測装置24は、例えば、ユーザ端末20の制御部21との間で近距離無線通信する。例えば、ユーザ端末20及び生体データ計測装置24は、それぞれ、Bluetooth(登録商標)などの近距離無線データ通信規格を採用したBLE通信モジュールを有することができるが、これに限定されない。また、生体データ計測装置24とユーザ端末20の制御部21は、有線接続されても良い。
【0040】
記憶部23は、Webブラウザや各種のアプリケーションプログラム(スマホアプリ)を記憶する。プロセッサが、ROM又は記憶部23に記憶されたプログラムを実行することによって、制御部21は、様々な動作を行うことができる。例えば、制御部21は、スマホアプリやWebブラウザなどにより、サービスサーバ10にアクセスすることができる。また、電子カルテネットワーク1内では、患者であるユーザ毎に制限されたアクセス権限が与えられて、各ユーザは、ユーザ端末20からデータサーバ40にアクセスして、記憶部42に記憶されている自身の許可された電子カルテの情報を閲覧できるようになっている場合もある。ユーザ端末20は、GPS(Global Positioning System)受信機を有しても良い。ユーザ端末20は、GPS受信機またはWi-Fiモジュールによって取得した当該ユーザ端末の位置情報を、スマホアプリで利用することができ、必要に応じて通信ネットワークNETを介してサービスサーバ10などに送信可能となっている。
【0041】
また、記憶部23は、測定部22及び生体データ計測装置24によって取得したユーザの生体データを、PHR(Personal Health Records)として蓄積することができる。すなわち、当該ユーザ端末20のユーザは、記憶部23に、自身が自ら管理する医療・健康記録を一定期間以上に渉って保存しておくことができる。
【0042】
サーバ装置として動作するサービスサーバ10は、特に図示はしないが、例えば、制御部と、この制御部に接続された記憶部と、通信ネットワークNETに接続するための通信インタフェースと、を有することができる。通信インタフェースは、通信ネットワークNETを介して、ユーザ端末20及び電子カルテネットワーク1のデータサーバ40や病院サーバ30と通信することができる。通信インタフェースによる通信は、特定の通信方式に限定されるものではない。制御部は、例えば、CPUやMPUなどのプロセッサと、RAMやROMなどのメモリと、を含むことができる。ROMは、例えば、プロセッサが実行するプログラムを記憶する。RAMは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部は、電子カルテ収集部11、生体データ収集部12、受付部13、限定部14、評価部15、提示部16、予約部17、対応関係データベース18、及び医師属性取得部19の動作を行うことができる。
【0043】
電子カルテ収集部11は、例えば、通信ネットワークNETを介して電子カルテネットワーク1におけるデータセンタのデータサーバ40にアクセスして、記憶部42に記憶された各病院の電子カルテの記載内容を収集することができる。例えば、電子カルテ収集部11は、データサーバ40の制御部41に電子カルテの記載内容の送信を依頼し、データサーバ40から送信されてくる電子カルテを受信することで、電子カルテの記載内容を収集する。
【0044】
生体データ収集部12は、例えば、通信ネットワークNETを介して各ユーザ端末20の記憶部23に蓄積された生体データを収集することができる。例えば、ユーザ端末20において測定部22又は生体データ計測装置24によって生体データが取得される毎に、ユーザ端末20からその取得した生体データをサービスサーバ10に送信することで、生体データ収集部12は、各ユーザ端末20の記憶部23に記憶された生体データを収集することができる。あるいは、生体データ収集部12は、各ユーザ端末20の制御部21に記憶部23に記憶されている少なくとも一定期間の生体データの送信を依頼し、各ユーザ端末20から送信されてくる少なくとも一定期間の生体データを受信することで、生体データを収集することも可能である。
【0045】
受付部13は、例えば、通信ネットワークNETを介してユーザ端末20から要求を受け付ける。この受付部13が受け付ける要求は、病院候補の提示を要求する評価要求や病院への予約を要求する病院予約要求を含むことができる。なお、ユーザ端末20の制御部21は、評価要求をサービスサーバ10に送信する際、位置情報など、サービスサーバ10での評価動作に必要な情報を併せて送信することができる。このとき、記憶部23にPHRとして蓄積している生体データの内の最新のものも併せて送信するようにしても良い。ただし、これは、ユーザ端末20において生体データが取得される毎に、ユーザ端末20からサービスサーバ10に送信されているので、必ずしも必要というわけではない。また、病院予約要求には、予約を依頼する病院又は医師を示す情報が含まれる。
【0046】
限定部14は、例えば、受付部13によって通信ネットワークNETを介してユーザ端末20から評価要求とユーザ端末20のユーザの生体データとが受け付けられたとき、評価を行うべき評価対象を限定する。例えば、限定部14は、評価要求の要求元のユーザ端末20のユーザの生体データと、生体データ収集部12によって収集した複数のユーザから収集した生体データとに基づいて、複数の病院又は複数の病院に所属する複数の医師の中から、評価を行うべき評価対象を限定することができる。
【0047】
評価部15は、例えば、限定部14によって評価対象として限定された複数の病院又は医師を、電子カルテ収集部11によって収集した電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって評価する。例えば、診療時間は、患者の診療開始から診療終了までの時間であり、待ち時間は、患者の受付から診療開始までの時間と、診療終了から会計終了までの時間との合計である。
【0048】
提示部16は、例えば、評価部15による評価結果に基づいて、評価された複数の病院又は医師の中から少なくとも一つを予約候補として、通信ネットワークNETを介して評価要求元のユーザ端末20へ送信することで、当該ユーザ端末20に予約候補を提示させることができる。
【0049】
予約部17は、例えば、受付部13によって通信ネットワークNETを介して評価要求元のユーザ端末20から、提示された予約候補の中からユーザによって選択された病院又は医師に対する病院予約要求が受け付けられたとき、当該ユーザの予約を該当する病院へ依頼する。例えば、予約部17は、病院予約要求で示される病院又は医師に該当する病院の病院サーバ30の、患者の予約管理を行う病院制御部として動作する制御部31に、通信ネットワークNETを介して病院予約要求元の、すなわち評価要求元のユーザ端末20のユーザの予約を依頼することができる。
【0050】
対応関係データベース18は、例えば、生体データ収集部12によって収集した生体データの属性に応じて病院又は医師をデータベース化したものである。限定部14は、評価要求元のユーザ端末20のユーザの生体データの属性により、この対応関係データベース18を参照して、評価対象となる複数の病院又は医師を限定することができる。
【0051】
医師属性取得部19は、例えば、各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得することができる。データサーバ40は、特に図示はしていないが、各病院に所属する医師の医師属性情報を登録したデータベースを有しており、このデータベースが、例えば、各病院の病院サーバ30の制御部31により、所属する医師の変更がある度に更新されるようになっている。よって、医師属性取得部19は、例えば、通信ネットワークNETを介して、データサーバ40の制御部41から医師属性情報を取得することができる。また、多くの病院は、病院サーバ30によって或いは他のWebサーバによって、病院紹介のためのWebページなどを提供しており、そこに所属医師の公開可能な医師属性情報を公開している。よって、医師属性取得部19は、例えば、通信ネットワークNETを介してWebページより、医師属性情報を取得することもできる。
【0052】
なお、受付部13は、更に、通信ネットワークNETを介して評価要求元のユーザ端末20のユーザの属性情報を受け付けることができ、評価部15によって評価する評価項目は、更に、医師属性取得部19により取得される医師の属性情報と、この受付部13によって受け付けた評価要求元のユーザ端末20のユーザの属性情報との関係を含むことができる。ユーザの属性情報は、ユーザ端末20からの評価要求と共に送信されるようにしても良いし、サービスサーバ10が提供するサービスへのユーザ加入時に受付部13によって受け付けて、加入者であるユーザの情報を登録しておく図示しないユーザデータベースに登録しておくようにしても良い。
【0053】
[適用例の動作]
次に、病院予約システムの動作の一例について説明する。
【0054】
各病院においては、患者は、まず、自動受付機や受付カウンタで受け付けを行う。すると、例えば、自動受付機や医療従事者が操作するPCなどの医療端末33から、患者を特定するための患者IDなどを含む患者情報が制御部31に入力される。制御部31は、例えば、この患者情報に基づいて、記憶部32に記憶された電子カルテデータベースにおける該当患者の電子カルテに、受付日時を記載つまり記憶する。また、医師による患者の診療、診断、治療などの診療行為や、看護師や検査技師による患者の検査行為が行われると、例えば、医療従事者が操作する医療端末33から、診療開始日時、診療終了日時、診療医師、診療内容、処方、検査結果、などの情報が制御部31に入力される。制御部31は、例えば、その入力された情報を、記憶部32に記憶された電子カルテデータベースにおける該当患者の電子カルテに記載つまり記憶する。また、制御部31は、例えば、記憶部32に記憶した会計プログラムなどにより、記憶部32に記憶した電子カルテの記載内容に基づいて、各患者の支払額を算出する。患者が自動会計機や会計カウンタでその支払額を支払うと、例えば、自動会計機や医療従事者が操作するPCなどの医療端末33から、決済情報が制御部31に入力される。制御部31は、例えば、この決済情報を記憶部32に記憶すると共に、記憶部32に記憶された電子カルテデータベースにおける該当患者の電子カルテに、会計終了日時を記載つまり記憶する。なお、記憶部32に電子カルテデータベースを記憶せずに、データセンタのデータサーバ40に電子カルテを保存する形態を採る病院では、制御部31は、例えば、電子カルテに記載するべき情報を、通信ネットワークNET又は専用回線を介して、データサーバ40に送信する。データサーバ40の制御部41は、例えば、この受信した情報に基づいて、記憶部42に記憶している電子カルテデータベースの該当する患者の電子カルテの記載内容を更新する。
【0055】
また、制御部31は、例えば、各患者の電子カルテの記載内容が更新される度、あるいは一定時間おきに、更新が有った電子カルテについて、その電子カルテ全体又は更新内容を通信ネットワークNET又は専用回線を介して、データサーバ40に送信する。データサーバ40の制御部41は、例えば、この受信した情報に基づいて、記憶部42に記憶している電子カルテデータベースの該当する患者の電子カルテの記載内容を更新する。
【0056】
サービスサーバ10の電子カルテ収集部11は、例えば、一定時間おきに、図示しない通信インタフェースにより通信ネットワークNETを介して、電子カルテネットワーク1におけるデータセンタのデータサーバ40の制御部41に電子カルテ記載内容送信要求を送信することができる。そして、これに応じて、データサーバ40から送信されてくる電子カルテの記載内容を受信し、図示しない記憶部に記憶する。データサーバ40の記憶部42に設けられる電子カルテデータベースにおける各電子カルテには、氏名や住所などの患者個人を特定する個人情報と、その患者に関する検査情報と、を含む患者情報が記載されている。更に、各電子カルテには、その患者の各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時、などを含む診療情報が記載されている。データサーバ40に送信する電子カルテ記載内容送信要求は、収集するべき情報を特定する収集対象情報を含み、電子カルテ収集部11は、この収集対象情報に、少なくとも、診療情報を含める。また、既に収集済みの電子カルテの記載内容の送受信は、通信資源の浪費であるので、電子カルテ記載内容送信要求は、情報を収集するべき期間を示す収集期間情報を含むことができる。電子カルテ収集部11は、受信した電子カルテの記載内容により、図示しない記憶部の記憶内容を更新する。
【0057】
各ユーザ端末20において測定部22又は生体データ計測装置24によってユーザの生体データが取得されると、制御部21は、その取得した生体データを記憶部23にPHRとして記憶する。また、制御部21は、その取得した生体データを、図示しない通信インタフェースにより通信ネットワークNETを介してサービスサーバ10に送信することができる。
【0058】
サービスサーバ10の生体データ収集部12は、例えば、図示しない通信インタフェースにより、各ユーザ端末20から通信ネットワークNETを介して送信されてきた生体データを受信し、図示しない記憶部に記憶している各ユーザ端末20のユーザ毎の生体データの履歴に、その受信した生体データを追加記憶する。あるいは、生体データ収集部12は、各ユーザ端末20の制御部21に記憶部23に記憶されている少なくとも一定期間の生体データの送信を依頼し、各ユーザ端末20から送信されてくる少なくとも一定期間の生体データを受信することで、生体データを収集する。
【0059】
いずれかのユーザ端末20が、スマホアプリやWebブラウザなどにより、サービスサーバ10にアクセスして、評価要求を送信すると、受付部13は、図示しない通信インタフェースにより、この評価要求を受け付ける。受付部13がこの評価要求を受け付けたとき、それに応答して、限定部14は、評価要求と共に受け付けた評価要求元のユーザ端末20のユーザの生体データと、図示しない記憶部に記憶している複数のユーザから収集した生体データとに基づいて、複数の病院又は複数の病院に所属する複数の医師の中から、評価を行うべき評価対象を限定する。例えば、限定部14は、評価要求元のユーザ端末20のユーザの生体データの属性により対応関係データベース18を参照して、評価対象となる複数の病院又は医師を限定することができる。
【0060】
また、ユーザ端末20からの評価要求には、GPS受信機またはWi-Fiモジュールによって取得した当該ユーザ端末20の現在位置や、図示しないユーザインタフェースを介して入力されたユーザ指定の指定位置などの位置情報を含めることができる。指定位置は、例えばユーザの自宅や勤務地などの住所情報を含むことができる。また、指定位置は、予めユーザ毎に登録し、サービスサーバ10の図示しない記憶部に記憶しておくことも可能である。限定部14は、この位置情報に基づいて、評価対象となる複数の病院又は医師を限定することができる。
【0061】
評価部15は、電子カルテ収集部11によって収集して図示しない記憶部に記憶した電子カルテの記載内容の内、このように限定部14によって評価対象として限定された病院又は医師に対応する電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって評価することで、それら限定された複数の病院又は医師を評価し、その評価結果を図示しない記憶部に記憶する。なお、評価部15によって評価する評価項目は、生体データ収集部12によって収集して図示しない記憶部に記憶した生体データの一定期間の履歴に基づいた症状の改善度を含むことができる。更に、前記評価部15によって評価する評価項目は、評価要求元のユーザ端末20からの位置情報と評価対象として限定された病院の位置との関係を含んでも良い。
【0062】
なお、診療を行うために検査を実施した場合には、病院での滞在時間が長くなるため、病院又は医師の評価に際して、待ち時間をそのまま利用することは望ましくない。よって、電子カルテ収集部11によって収集して図示しない記憶部に記憶した電子カルテの記載内容に検査実施の記録が存在する場合には、その診療回の時間情報を病院又は医師の評価に利用しない、或いは、時間に何らかの係数を乗じて利用するものとする。また、電子カルテ収集部11での電子カルテの記載内容の収集の際に、検査実施の記録が存在する診療回の情報を収集しないようにしても良い。
【0063】
また、ユーザ端末20からの評価要求には、当該ユーザ端末20のユーザについての、少なくとも性別及び年齢を含むユーザ属性情報を含めることができる。或いは、ユーザ属性情報は、予めユーザ毎に登録し、サービスサーバ10の図示しない記憶部に記憶しておくことも可能である。また、医師属性取得部19は、各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得して、図示しない記憶部に記憶する。評価部15によって評価する評価項目は、これら図示しない記憶部に記憶したユーザ属性情報と医師属性情報との関係を含むことも可能である。
【0064】
また、病院サーバ30の制御部31は、当該病院の時事の滞在中患者の時間管理を行っている。評価部15は、図示しない通信インタフェースにより、通信ネットワークNETを介して限定された病院又は限定された医師が所属する病院の病院サーバ30の制御部31に、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを問い合わせて取得することができる。評価部15によって評価する評価項目は、この取得した診療待ち患者人数及び予約患者数を含むことができる。
【0065】
提示部16は、例えば、評価部15による評価結果に基づいて、評価された複数の病院又は医師の中から少なくとも一つを予約候補として、図示しない通信インタフェースにより、通信ネットワークNETを介して評価要求元のユーザ端末20へ送信する。この予約候補を受信したユーザ端末20のスマホアプリやWebブラウザなどでは、それをユーザに提示する。
【0066】
なお、評価部15は、評価対象として限定された複数の病院又は医師の評価結果を表す評価値を算出し、提示部16は、この評価値が高い方から複数の病院又は医師を予約候補として抽出して、抽出した予約候補をその評価値と共に評価要求元のユーザ端末20に送信するようにしても良い。
【0067】
また、評価部15は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とするようにしても良い。この場合、提示部16は、評価部15が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、抽出した予約候補をその評価値と共に評価要求元のユーザ端末20に送信することができる。
【0068】
ユーザ端末20に提示された予約候補を見た評価要求元のユーザ端末20のユーザである患者が、スマホアプリやWebブラウザなどにおいて図示しないユーザインタフェースにより、所望の病院の予約操作を行うと、ユーザ端末20の制御部21は、病院予約要求を、図示しない通信インタフェースにより通信ネットワークNETを介してサービスサーバ10に送信する。
【0069】
サービスサーバ10の受付部13が図示しない通信インタフェースによりこの病院予約要求を受け付けると、それに応答して、予約部17は、病院予約要求に含まれるユーザによって選択された病院又は医師が所属する病院を特定し、その病院へ当該ユーザの予約を依頼する。例えば、予約部17は、特定した病院の病院サーバ30の制御部31に、図示しない通信インタフェースにより通信ネットワークNETを介して、病院予約要求元の、すなわち評価要求元のユーザ端末20のユーザの予約を依頼する。患者の予約管理を行う病院制御部として動作する病院サーバ30の制御部31は、この予約の可否を判別し、予約可能であれば、その患者の予約を登録する。そして、予約結果を通信ネットワークNETを介してサービスサーバ10に返す。サービスサーバ10の予約部17は、図示しない通信インタフェースにより予約結果を受信して、予約要求元のユーザ端末20に結果を返す。なお、予約部17から病院サーバ30に送信する予約要求に、予約要求元ユーザ端末20のユーザの電子メールアドレスなどを含めることで、病院サーバ30からユーザへ直接、予約結果を報知できるようにしても良い。
【0070】
[適用例の効果]
以上のように、適用例に係る病院予約システムによれば、任意のユーザ端末20からの評価要求に応じて、サービスサーバ10の評価部15が、そのユーザ端末20のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、提示部16が、その評価結果に基づいて予約候補をユーザに提示する。そして、評価要求元のユーザ端末20のユーザの病院又は医師の選定に従って、予約部17が病院の予約を行う。よって、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定でき、また、その選定に応じて病院を簡便に予約することができるようになる。
【0071】
<1> 第1実施形態
以下に、第1実施形態について説明する。
【0072】
<1-1>構成
図2を用いて、第1実施形態に係る病院予約システムの構成例について説明する。第1実施形態に係る病院予約システムは、上記適用例で説明したように、インターネットなどの通信ネットワークNETにそれぞれ接続された、電子カルテネットワーク1と、複数のユーザ端末20と、サーバ装置として動作するサービスサーバ100と、を含む。
図2は、第1実施形態に係る病院予約システムの全体構成の一例を示すブロック図である。
【0073】
電子カルテネットワーク1は、上記適用例で説明したように、各病院の病院サーバ30と、データセンタのデータサーバ40とを含む。病院サーバ30は、上記適用例で説明したように、制御部31と、記憶部32と、図示しない通信インタフェースと、を備え、医療端末33と接続されている。データサーバ40は、上記適用例で説明したように、制御部41と、記憶部42と、図示しない通信インタフェースと、を含む。
【0074】
ユーザ端末20は、上記適用例で説明したように、制御部21と、測定部22と、記憶部23と、図示しない通信インタフェースと、図示しないユーザインタフェースと、を備え、生体データ計測装置24と接続可能である。
【0075】
サービスサーバ100は、
図2の例では、制御部110と、記憶部120と、通信インタフェース130と、を含む。なお、
図2では、通信インタフェースを「通信I/F」と記載している。
【0076】
制御部110は、例えば、CPU111、RAM112、ROM113などを含み、情報処理に応じてサービスサーバ100の各構成要素の制御を行う。CPU111の代わりに、MPUなどの他のプロセッサであっても良い。ROM113は、例えば、CPU111が実行するオペレーティングシステムや他のプログラム(例えば、病院予約プログラム)を記憶する。RAM112は、例えば、CPU111がワークメモリとして使用するメモリである。
【0077】
CPU111が必要なプログラムを実行することによって、上記適用例で説明したような電子カルテ収集部11、生体データ収集部12、受付部13、限定部14、評価部15、提示部16、予約部17、及び医師属性取得部19の処理を実行して良い。当該プログラムは、例えば、ROM113ではなく、記憶部120に記憶されていても良い。CPU111が必要なプログラムを実行する際は、例えば、ROM113及び/又は記憶部120に記憶された対象となるプログラムをRAM112に展開する。そして、CPU111は、例えば、RAM112に展開された当該プログラムを解釈及び実行して、各構成要素を制御する。
【0078】
記憶部120は、例えば、制御部110により実行されるプログラム(例えば、病院予約プログラム)、プログラムを実行するために必要な設定データ(例えば、データサーバ40のアドレス情報)、各種のデータベース、などを記憶することができる。記憶部120が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部120が備える記憶媒体は、例えば、EEPROMなどを使用することができる。なお、この記憶部120についても、CPU111がワークメモリとして使用するようにしても良い。記憶部120が記憶するデータベースは、病院データベース121、ユーザデータベース122、対応関係データベース123、収集データベース124、評価データベース125、などを含むことができる。なお、
図2では、病院データベース、ユーザデータベース、対応関係データベース、収集データベース及び評価データベースを「病院DB」、「ユーザDB」、「医療DB」、「収集DB」及び「評価DB」と記載している。
【0079】
通信インタフェース130は、制御部110の制御の下、通信ネットワークNETを介して、ユーザ端末20、病院サーバ30及びデータサーバ40との間でデータ通信を行う。通信プロトコルは、通信ネットワークNETで規定されたプロトコルを使用する。具体的にはTCP/IP(Transmission Control Protocol/Internet protocol)やUDP/IP(User Datagram Protocol/Internet protocol)等が使用され得る。
【0080】
図3は、病院データベース121の記憶内容の一例を示す図である。
図3に示す例では、病院データベース121は、病院ID、アクセス情報、病院情報、病院評判、診療科、医師ID、氏名、性別、年齢、滞在人数、予約状況、医師評判、などの項目名に対応する各病院の情報を記憶する。
図3では、医師評判を「評判」と記載し、滞在人数を「待ち」と記載している。
【0081】
「病院ID」は、サービスサーバ100が提供する病院予約サービスにおいて病院それぞれに一意に割り当てられる管理番号である。「アクセス情報」は、病院サーバ30や病院のWebページにアクセスするためのアドレス情報である。「病院情報」は、病院の名称、住所、電話番号、営業時間、休日(営業日)、駐車場情報、などの病院それぞれに関する一般的な情報である。「病院評判」は、各ユーザ端末20において任意に入力された、及び/または、インターネット上の各種の病院評価Webページなどから取得した、主観的な病院評価情報である。「診療科」は、内科や皮膚科といった、病院が有する診療科の情報である。
【0082】
「医師ID」は、病院に所属する各医師に一意に割り当てられる管理番号である。この医師IDは、病院IDと紐付くことで、各医師が区別可能であるが、医師が別の病院に移ることもあるので、サービスサーバ100が提供する病院予約サービスにおいて一意に設定される。各病院で独自の医師IDを使用している場合には、記憶部120に別途、医師データベースを用意し、病院独自の医師IDを本病院予約サービス用の医師IDに変換できるようにしておけば良い。「氏名」は、各医師の氏名である。「性別」は、各医師の性別である。「年齢」は、各医師の年齢である。「待ち」は、各医師についての現時点における診療待ち患者人数である。「予約状況」は、各医師についての今後の予約患者数である。この予約状況については、例えば、1日を午前と午後に分けるなど、任意の期間に分けて、それぞれの予約患者数が記憶される。「医師評判」は、各ユーザ端末20において任意に入力された、及び/または、インターネット上の各種の病院評価Webページなどから取得した、主観的な医師評価情報である。
【0083】
図4は、ユーザデータベース122の記憶内容の一例を示す図である。
図4に示す例では、ユーザデータベース122は、項目として、ユーザID、パスワード、氏名、ユーザ情報、病院毎ID、地点、優先条件、日付、通院フラグ、生体データ(例えば、血圧、脈拍、など)、症状パターンなどを有している。
図4では、パスワードを「PW」と、通院フラグを「通院F」と、症状パターンを「症状P」と、それぞれ記載している。
【0084】
「ユーザID」は、サービスサーバ100が提供する病院予約サービスへのユーザ加入時に一意に割り当てられるユーザの管理番号である。「パスワード」は、ユーザが認証のために任意に設定する値である。「氏名」は、ユーザの氏名である。「ユーザ情報」は、ユーザに関する情報であり、メールアドレス、電話番号、性別及び年齢を含む。「病院毎ID」は、当該ユーザの各病院での管理番号を示す情報であり、病院IDと当該病院でのユーザ管理番号とを組み合わせたものである。この病院毎IDにより、各ユーザと各病院の電子カルテとを紐付けることが可能となる。「地点」は、ユーザの位置情報であり、現在の位置、自宅住所、職場住所、登録位置を含むことができる。現在の位置は、例えばユーザ端末20から送信されてくる現在位置が必要に応じて登録される。自宅住所、職場住所、登録位置は、ユーザが任意に指定する指定位置である。「優先条件」は、ユーザが優先条件として、予め決められた選択肢から選択した或いは任意に指定した情報である。
【0085】
「日付」は、ユーザ端末20において生体データを取得した日付である。「通院フラグ」は、ユーザがいずれかの病院に通院したか否かを示すもので、通院した場合に「1」がセットされる。生体データ(「血圧」、「脈拍」、など)は、ユーザ端末20において取得された生体データである。「症状パターン」は、生体データに含まれる各種の測定値又は計測値の関係を含む生体データの属性、つまり生体データのパターンに基づいて設定される症状を示している。「日付」、「通院フラグ」、生体データ(「血圧」、「脈拍」、など)、「症状パターン」は、各ユーザに対して割り当て得るデータ容量が決まっているので、予め決められた期間分が記憶され、それ以上の情報を追加する際には、最も古い情報が削除される。期間ではなく、予め決められた数であっても良い。いずれにしても、この期間又は数は、少なくとも後述する一定期間以上の生体データが保存されるように決められていれば良い。ユーザデータベース122は、その他に、ユーザが過去に診療を受けた医師IDの記録などを記憶しても良い。
【0086】
図5は、対応関係データベース123の記憶内容の一例を示す図である。対応関係データベース123は、上記適用例で説明したような対応関係データベース18に対応するものである。
図5に示す例では、対応関係データベース123は、項目として、症状パターン、病院ID、及び医師IDを有している。
図5では、症状パターンを「症状P」と記載している。この対応関係データベース123は、症状パターンに対応する病院及び医師をデータベース化したものである。
【0087】
「症状パターン」は、ユーザデータベース122の症状パターンに対応している。「病院ID」は病院を特定するための管理番号である。「医師ID」は医師を特定するための管理番号である。これら病院ID及び医師IDは、病院データベース121のそれらと対応している。
【0088】
図6は、収集データベース124の記憶内容の一例を示す図である。
図6に示す例では、収集データベース124は、項目として、病院ID、患者ID、予約日時、受付、診療開始、医師ID、診療終了、会計終了、初診フラグ、症状、などを有している。
図6では、初診フラグを「初診F」と記載している。
【0089】
「病院ID」は、病院を特定するための管理番号であり、この病院IDにより、病院データベース121と収集データベース124の情報がリンク可能となる。「患者ID」は、各病院が独自に割り当てた患者の管理番号である。「予約日時」は、患者が予約した日時である。「受付」は、患者が来院して受付を行った時間である。例えば、各病院において、医療端末33、例えば、受付事務員が操作するPCや患者が操作する自動受付機によって受付を行うことで、受付時間が当該患者に対応する電子カルテに記載される。「診療開始」は、患者に対する医師の診療が開始された時間である。「医師ID」は、診療を行う医師を特定する情報である。この医師IDにより、病院データベース121と収集データベース124の情報がリンク可能となる。「診療終了」は、患者に対する医師の診療が終了した時間である。例えば、各病院において、医療端末33、例えば、医師又は看護師が操作するPCによって診療開始時間、医師ID、診療終了時間を入力することで、それらの情報が当該患者に対応する電子カルテに記載される。「会計終了」は、患者が会計を済ませた時間である。例えば、各病院において、医療端末33、例えば、会計事務員が操作するPCで支払い終了を入力することで、あるいは、患者が操作する自動会計機によって支払いを行うことで、会計終了時間が当該患者に対応する電子カルテに記載される。「初診フラグ」は、診療が初診であるか否かを示すもので、初診である場合に「1」がセットされる。「症状」は、患者の病名である。
【0090】
なお、この
図6の例は、電子カルテの記載内容の収集の際に、検査実施の記録が存在する診療回の情報を収集しないようにした場合を示している。検査を実施した診療回の情報も収集する場合には、収集データベース124は、例えば、項目として、更に検査実施の有無を示すフラグを設ける。多くの場合、初診の際に検査も実施されるので、この検査実施の有無を示すフラグとしては、「初診フラグ」が兼用されても良い。
【0091】
図7は、評価データベース125の記憶内容の一例を示す図である。
図7に示す例では、評価データベース125は、項目として、ユーザID、病院ID、病院スコア、診療科、診療科スコア、医師ID、総合スコア、時間スコア、症状別改善度スコア(例えば、高血圧改善度スコア、糖尿病改善度スコア、じんま疹改善度スコア、など)、などを有している。
図7では、症状別改善度スコアの内の高血圧改善度スコアのみを示し、「高血圧」と記載している。
【0092】
「ユーザID」は、ユーザを特定するための管理番号であり、このユーザIDにより、ユーザデータベース122と評価データベース125の情報がリンク可能となる。「病院ID」は、病院を特定するための管理番号であり、この病院IDにより、病院データベース121と収集データベース124と評価データベース125の情報がリンク可能となる。「病院スコア」は、病院の評価結果を数値化した評価値である。ここでは最高点を100点とした数値で示しているが、この数値表現は一例である。例えば、星5つを最高点として星の数で示したり、偏差値で表したりするなど、どのようなものであっても構わない。この「病院スコア」は、当該病院が有する全診療科の評価値の平均値とすることができる。「診療科」は、病院が有する診療科の情報であり、この診療科により、病院データベース121と評価データベース125の情報がリンク可能となる。「診療科スコア」は、診療科毎の評価値である。この「診療科スコア」は、当該診療科に属する全医師の評価値、例えば後述する総合スコア、の平均値とすることができる。
【0093】
「医師ID」は、診療を行う医師を特定する情報である。この医師IDにより、病院データベース121と収集データベース124と評価データベース125の情報がリンク可能となる。「総合スコア」は、医師毎の評価値である。この「総合スコア」は、当該医師についての時間評価値と、全改善度評価値の平均値や加重平均値との、加算値とすることができる。
【0094】
「時間スコア」は、医師毎の、一患者当たりの診療時間と待ち時間とから評価した時間評価値である。時間評価値は、例えば、一患者当たりの診療時間の平均値と一患者当たりの待ち時間との平均値とに基づいて評価する。例えば、一患者当たりの診療時間の平均値については、予め決めた時間範囲に応じて、その平均値が長い程高い評価値とする。例えば、一患者当たりの診療時間の平均値が10分以上であれば満点である10点とし、1分減る毎に1点減らす、などとすることができる。また、一患者当たりの待機時間の平均値については、例えば、予め決めた時間範囲に応じて、その平均値が短い程高い評価値とする。例えば、一患者当たりの待機時間の平均値が30分以内であれば満点の50点とし、時間が2分増える毎に1点減らす、などとすることができる。「時間スコア」は、こうして得られた一患者当たりの診療時間の平均値による点数と一患者当たりの待ち時間の平均値による点数との合計点数とすることができる。
【0095】
「症状別改善度スコア」は、各症状の改善度から評価した改善度評価値である。改善度評価値は、例えば、当該医師の診療を受けた患者の内、ユーザデータベース122に登録されていて生体データの一定期間の履歴を取得可能な患者について、その生体データの一定期間の履歴に基づいて症状がどれだけ改善したかにより、症状の改善度の評価値を求め、全ユーザの評価値の平均点とすることができる。例えば、症状が高血圧であれば、血圧値のデータから、一定期間、例えば一ヶ月間に、収縮期血圧が20mmHg下がっていれば満点である10点とし、低下量が1mmHg少なくなる毎に1点減らす、などとすることができる。
【0096】
なお、「総合スコア」は、「時間スコア」と全「症状別改善度スコア」から算出されることができるが、本実施形態では、後述するように、更に、病院予約を求めるユーザが指定する優先条件や、ユーザの属性情報などを評価項目に加えることで、算出した「時間スコア」を補正し得る。
【0097】
<1-2>動作
次に、
図8及び
図9を用いて、第1実施形態に係る病院予約システムの動作例について説明する。
【0098】
図8は、サービスサーバの処理手順の一例を例示するフローチャートであり、
図9は、ユーザ端末の処理手順の一例を例示するフローチャートである。
【0099】
<1-2-1>生体データ収集動作
[ステップS101]
サービスサーバ100のCPU111は、先ず、生体データを収集するべきタイミングになったか否かを判断する。本実施形態では、例えば、1日1回など、予め決めたタイミングで生体データを収集する。生体データを収集するべきタイミングであると判断した場合(ステップS101、YES)、CPU111は、処理をステップS102に進める。生体データを収集するべきタイミングではないと判断した場合(ステップS101、NO)、CPU111は、処理をステップS103に進める。
【0100】
[ステップS102]
上記ステップS101において生体データを収集するべきタイミングであると判断した場合(ステップS101、YES)、CPU111は、生体データ収集処理を実行する。この生体データ収集処理においては、CPU111は、通信インタフェース130により、ユーザデータベース122に登録されている各ユーザのユーザ端末20に、当該ユーザ端末20の記憶部23に記憶されているPHRの送信を依頼するPHR要求を送信し、これに応じて各ユーザ端末20から送信されてきたPHRを、ユーザデータベース122の対応するユーザの生体データ(「血圧」、「脈拍」、など)の項目に登録する。また、CPU111は、ユーザデータベース122に登録した生体データの各項目の測定値又は計測値の関係を含む生体データの属性、つまり生体データのパターンに対応する症状を決定し、それをユーザデータベース122の症状パターンの項目に登録する。なお、この症状の決定は、どのような手法を用いても良い。例えば、予め生体データの多数のパターンに対し症状を選定して、データベース化しておき、このデータベース化されたパターンとユーザデータベース122に登録した生体データのパターンとのパターンマッチングにより、最も近似するパターンの症状を採用することができる。或いは、生体データの大量のパターンを機械学習しておくことで、ユーザデータベース122に登録した生体データのパターンに対応する症状を判定するようにしても良い。この生体データ収集処理終了後、CPU111は、処理をステップS103に進める。
【0101】
[ステップS201]
すなわち、ユーザ端末20の制御部21の図示しないプロセッサは、電子メールプログラムなどと同様にバックグラウンドで実行するアプリケーションプログラムの一つとして病院予約プログラムを実行しており、図示しない通信インタフェースによりサービスサーバ100からPHR要求を受信したか否かを判断することができる。PHR要求を受信していないと判断した場合(ステップS201、NO)、プロセッサは、処理をステップS202に進める。また、PHR要求を受信したと判断した場合(ステップS201、YES)、プロセッサは、処理をステップS203に進める。
【0102】
[ステップS202]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS201において、サービスサーバ100からPHR要求を受信していないと判断した場合(ステップS201、NO)、図示しないユーザインタフェースを通じたユーザ操作が有ったか否かを判断する。何も操作が無いと判断した場合(ステップS202、NO)、プロセッサは、処理を上記ステップS201に戻す。また、何らかの操作が有ったと判断した場合(ステップS202、YES)、プロセッサは、処理をステップS204に進める。
【0103】
[ステップS203]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS201において、サービスサーバ100からPHR要求を受信したと判断した場合(ステップS201、YES)、PHR送信処理を実行する。このPHR送信処理においては、プロセッサは、PHR要求を受信したことをポップアップなどによりユーザ端末20のユーザに報知する。これを確認したユーザが、送信を許可する操作を行ったならば、プロセッサは、図示しない通信インタフェースにより、記憶部23に記憶しているPHRをサービスサーバ100に送信する。この場合、サービスサーバ100からの要求に応えるため、ユーザ認証処理は行わなくても良い。また、送信を許可する操作が行われなかった場合には、PHR要求を無視する、或いは、受信から所定時間待機後に拒否応答をサービスサーバ100に返す。したがって、サービスサーバ100の動作の上記ステップS102においては、生体データを収集できないユーザ端末が存在する。このPHR送信処理終了後、プロセッサは、処理を上記ステップS201に戻す。
【0104】
<1-2-2>登録情報更新動作
[ステップS103]
サービスサーバ100のCPU111は、上記ステップS101において生体データを収集するべきタイミングではないと判断した場合(ステップS101、NO)、或いは、上記ステップS102の生体データ収集処理の終了後、病院データベース121の更新処理を実行する。例えば、CPU111は、通信インタフェース130により、病院サーバ30又はデータサーバ40に更新の問合せを行って、或いは、病院サーバ30又はデータサーバ40から病院情報の更新要求を確認することで、更新が必要な病院について、病院データベース121を更新する。また、CPU111は、新たな病院について、病院データベース121に追加することができる。この新規登録については、例えば、サービスサーバ100の管理者が、サービスサーバ100に直接又は通信ネットワークNETを介して接続された図示しない管理者端末を操作して実施できるようになっている。なお、このステップS103の更新処理では、病院データベース121の項目の内、病院ID、アクセス情報、病院情報、診療科、医師ID、性別、年齢を更新或いは新規登録するものであり、滞在人数や予約状況については更新しない。また、CPU111は、任意のWebページなどから、主観的な病院評価情報や医師評価情報を検索し、その結果を、病院データベース121の病院評判及び医師評判の項目に登録することができる。なお、このステップS103の更新処理では、特に変更するべき情報が無く、病院データベース121の内容を何ら更新しない場合もあり得る。
【0105】
[ステップS104]
サービスサーバ100のCPU111は、ユーザデータベース122の更新処理を実行する。例えば、CPU111は、通信インタフェース130により、ユーザ端末20、或いは図示しない管理者端末からの操作により、更新が必要なユーザについて、ユーザデータベース122を更新する。ユーザ端末20からの操作に応じた更新を行うには、ユーザ認証が必要であり、このステップS104の更新処理は、ユーザ認証処理を含む。また、CPU111は、新たなユーザについて、ユーザデータベース122に追加することができる。なお、このステップS104の更新処理では、ユーザデータベース122の項目の内、ユーザID、パスワード、氏名、ユーザ情報、病院毎ID、地点、優先条件を更新或いは新規登録するものであり、生体データなど更新しない情報もあり得る。なお、病院毎IDについては、ユーザ端末20からの操作による入力を受け付けても良いし、ユーザ情報や地点(自宅住所)などをキーにして、当該ユーザの管理番号を各病院サーバ30に問い合わせることで収集しても良い。なお、このステップS104の更新処理では、特に変更するべき情報が無く、ユーザデータベース122の内容を何ら更新しない場合もあり得る。
【0106】
[ステップS105]
サービスサーバ100のCPU111は、通信インタフェース130により、通信ネットワークNETを介して何れかのユーザ端末20からPHRを受信したか否かを判断する。PHRを受信していないと判断した場合(ステップS105、NO)、CPU111は、処理をステップS106に進める。PHRを受信したと判断した場合(ステップS105、YES)、CPU111は、処理をステップS107に進める。
【0107】
[ステップS106]
サービスサーバ100のCPU111は、上記ステップS105において何れかのユーザ端末20からPHRを受信していないと判断した場合(ステップS105、NO)、通信インタフェース130により、通信ネットワークNETを介して何れかのユーザ端末20から評価要求を受信したか否かを判断する。なお、この判断は、ユーザ認証処理を含む。評価要求を受信していないと判断した場合(ステップS106、NO)、CPU111は、処理を上記ステップS101に戻す。ユーザ認証がなされて評価要求を受信したと判断した場合(ステップS106、YES)、CPU111は、処理をステップS108に進める。
【0108】
[ステップS204]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS202において何らかの操作が有ったと判断した場合(ステップS202、YES)、その操作は、測定部22による生体データの取得指示であるか否かを判断する。この生体データの取得指示は、ユーザ端末20が備える測定部22による生体データの測定の指示を含むことができる。また、生体データの取得指示は、ユーザ端末20と通信可能な生体データ計測装置24で計測された生体データの取得の指示であっても良い。生体データの取得指示が有ったと判断した場合(ステップS204、YES)、プロセッサは、処理をステップS205に進める。行われた操作は生体データの取得指示ではないと判断した場合(ステップS204、NO)、プロセッサは、処理をステップS208に進める。
【0109】
[ステップS205]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS204において生体データの取得指示が有ったと判断した場合(ステップS204、YES)、生体データ取得処理を実行する。この生体データ取得処理においては、ユーザ端末20が備える測定部22によって生体データを測定することで、生体データを取得する。或いは、ユーザ端末20と通信可能な生体データ計測装置24で生体データを計測し、その計測した生体データを通信により取得する。
【0110】
[ステップS206]
ユーザ端末20の制御部21の図示しないプロセッサは、記憶部23に蓄積しているPHRに、この取得した生体データを追加記録する。
【0111】
[ステップS207]
そして、ユーザ端末20の制御部21の図示しないプロセッサは、この記憶部23に蓄積したPHRを、図示しない通信インタフェースにより通信ネットワークNETを介してサービスサーバ100に送信する。この場合、そのPHRが誰の生体データであるのかを特定し得るように、ユーザIDを付して、PHRを送信する。また、必ずしも記憶部23に記憶しているPHRの全データを送信しなくても良い。例えば、最新の生体データのみを送信するようにしても良いし、最新から一定期間あるいは一定数の生体データを送信するのであっても良い。その後、プロセッサは、処理を上記ステップS201に戻す。
【0112】
[ステップS107]
サービスサーバ100のCPU111は、上記ステップS105において何れかのユーザ端末20からPHRを受信したと判断した場合(ステップS105、YES)、その受信したPHRに基づいて、ユーザデータベース122の、対応するユーザの日付や生体データ(「血圧」、「脈拍」、など)、症状パターンの項目を更新する。この場合、受信したPHRとユーザデータベース122に登録されている生体データとを比較して、差分のみを追加更新することができる。既に予め決められた期間分又は予め決められた数の生体データがユーザデータベース122の対応するユーザに対し記憶されている場合には、最も古い情報が削除されて追加される。また、受信したPHRが、1日に当たり何回分もの生体データを含む場合には、最初の1回分の生体データのみを追加するようにしても良いし、最後の1回分の生体データのみを追加するようにしても良い。例えば、血圧は、起床後の測定データが特に有効な情報であるため、最初の1回分の生体データを用いることが望ましい。よって、複数回分の何れを採用するかは、生体データの種類により決めても良い。このユーザデータベース122の更新が終了したならば、CPU111は、処理を上記ステップS106に進める。
【0113】
<1-2-3>電子カルテ収集及び評価動作
[ステップS208]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS204において行われた操作は生体データの取得指示ではないと判断した場合(ステップS204、NO)、行われた操作は医療評価の取得指示であるか否かを判断する。医療評価の取得指示が有ったと判断した場合(ステップS208、YES)、プロセッサは、処理をステップS209に進める。行われた操作は医療評価の取得指示ではないと判断した場合(ステップS208、NO)、プロセッサは、処理をステップS210に進める。
【0114】
[ステップS209]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS208において医療評価の取得指示が有ったと判断した場合(ステップS208、YES)、評価処理を実行する。
図10は、この評価処理の一例を例示するフローチャートである。
【0115】
[ステップS2091]
ユーザ端末20の図示しないプロセッサは、図示しないユーザインタフェースを通じたユーザ操作による、評価条件の入力を受け付ける。評価条件は、優先条件を含むことができる。また、評価条件は、評価結果を提示する対象が病院であるのか、医師であるのかを示す評価対象条件を含むことができる。なお、病院が複数の診療科を有する場合が有るので、評価対象条件は、病院の代わりに診療科であっても良い。
【0116】
[ステップS2092]
そして、ユーザ端末20のプロセッサは、その入力された評価条件を付けて、評価要求を、通信ネットワークNETを介してサービスサーバ100に送信する。この際、評価要求には、ユーザ認証のためのユーザID及びパスワードと、ユーザ端末20の現在位置を示す位置情報とが含まれることができる。また、記憶部23にPHRとして蓄積している生体データの内の最新のものも併せて送信するようにしても良い。
【0117】
[ステップS2093]
その後、ユーザ端末20のプロセッサは、通信ネットワークNETを介してサービスサーバ100からの予約候補を受信するのを待つ。すなわち、プロセッサは、予約候補を受信したか否かを判断し、受信していない場合(ステップS2093、NO)、このステップS2093の処理を繰り返す。
【0118】
[ステップS108]
サービスサーバ100のCPU111は、上記ステップS106において評価要求を受信したと判断した場合(ステップS106、YES)、受信した評価要求に含まれるユーザID及びパスワードによりユーザ認証を行った上で、同じく評価要求に含まれる位置情報と、評価要求と共に送られる評価条件に含まれる優先条件とにより、ユーザデータベース122を更新する。すなわち、CPU111は、ユーザデータベース122の、該当するユーザに関する地点における現在位置と優先条件とを、受信した情報に更新する。また、CPU111は、受信した評価条件に含まれる評価対象条件を、RAM112または記憶部120に記憶する。なお、最新の生体データも送信されてきた場合には、ユーザデータベース122に登録されている生体データと比較し、必要であれば追加登録する。
【0119】
[ステップS109]
ここで、CPU111は、評価対象とする病院又は医師を限定する。例えば、CPU111は、まず、ユーザデータベース122の該当するユーザの最新の生体データに対応する症状パターンの項目から症状を読み出し、読み出した症状を検索キーにして対応関係データベース123を検索し、病院又は医師を限定する。そして更に、CPU111は、この生体データの属性、つまり生体データのパターンによって限定した病院又は医師の中から評価対象とする病院又は医師を、ユーザデータベース122の該当するユーザの優先条件項目に記憶された情報の内、位置を規定する情報によって限定する。すなわち、CPU111は、例えば優先条件が「現在地」であれば、ユーザデータベース122の該当するユーザの地点項目に記憶されている現在位置により、病院データベース121の病院情報に記憶されている住所との距離が所定範囲内の病院又は医師を、評価対象として限定する。同様にして、優先条件が「自宅」であれば自宅の住所、「職場」であれば職場の住所、「登録位置」であれば登録位置により、評価対象の病院又は医師を限定することができる。
【0120】
なお、この評価対象の病院又は医師の絞り込みの手法に関しては、先に位置情報により限定し、その後に生体データのパターンによって限定するようにしても構わない。また、病院と医師の何れを評価対象とするかは、RAM112または記憶部120に記憶した評価要求元のユーザ端末20からの評価対象条件に従う。
【0121】
CPU111は、この限定した評価対象病院の病院IDのリスト又は評価対象医師の医師IDと該当医師が所属する病院の病院IDのリストを、RAM112または記憶部120に記憶する。評価対象が医師であっても、病院側が医師を指定した予約ができない場合が有り得るので、評価対象の医師が所属する病院も評価対象としている。
【0122】
[ステップS110]
CPU111は、限定した病院の電子カルテの内容を収集する電子カルテ収集処理を実行する。
図11は、この電子カルテ収集処理の一例を例示するフローチャートである。
【0123】
[ステップS1101]
電子カルテ収集処理においては、CPU111は、まず、RAM112または記憶部120に記憶した病院IDのリストの中から一つの病院IDを選択することで、取得先病院を決定する。
【0124】
[ステップS1102]
次に、CPU111は、通信インタフェース130により通信ネットワークNETを介して、データサーバ40からその取得先病院の電子カルテの内容を取得する。例えば、CPU111は、病院IDにより病院データベース121を参照して、当該病院を特定する特定情報、例えば病院ID、アクセス情報、病院名、住所または電話番号を読み出す。そして、CPU111は、通信インタフェース130により通信ネットワークNETを介してデータサーバ40の制御部41に、この特定情報と共に電子カルテの記載内容の送信を依頼する。CPU111は、これに応答してデータサーバ40から送信されてきた電子カルテの内容を通信インタフェース130により受信する。
【0125】
なお、取得先病院の電子カルテの数が多い場合には、処理時間が掛かることが想定されるため、電子カルテのタイムスタンプにより最新のものから、人数や期間を限定した送信を依頼するようにしても良い。
【0126】
[ステップS1103]
次に、CPU111は、受信した電子カルテの内容に基づいて、病院データベース121及び収集データベース124に情報を登録する。例えば、CPU111は、患者ID毎に、電子カルテに記載された、各回の診療に関する情報、つまり予約日時、受付、診療開始、医師ID、診療終了、会計終了、初診フラグ、症状を収集データベース124に記憶する。なお、本実施形態では、受信した電子カルテに検査実施が記録されている場合には、CPU111は、その診療回の診療に関する情報を収集データベース124に記憶しないようにしている。また、CPU111は、電子カルテの内容に基づいて、医師ID毎に、現時点の診療待ち患者人数を集計し、病院データベース121の各医師IDに対応させて集計した人数を「待ち」の項目に記憶する。
【0127】
[ステップS1104]
次に、CPU111は、通信インタフェース130により通信ネットワークNETを介して、その取得先病院から予約患者数を取得する。例えば、CPU111は、病院IDにより病院データベース121を参照して当該病院のアクセス情報を読み出し、通信インタフェース130により通信ネットワークNETを介して当該病院の病院サーバ30の制御部31に、各医師についての現在時点の予約患者数を問い合わせる。現在時点の診療待ち患者人数は電子カルテの内容を集計することで判るが、初診の予約を依頼した患者については未だ電子カルテが存在しないので、受信した電子カルテの内容からだけでは予約患者数を把握することができない。そのため、取得先病院へ予約患者数の問合せが必要となる。CPU111は、この問い合わせに応答して病院サーバ30から送信されてきた予約患者数の情報を通信インタフェース130により受信する。
【0128】
[ステップS1105]
次に、CPU111は、受信した各医師についての現在時点での予約患者数の情報に従って、病院データベース121の各医師IDに対応させて「予約状況」の項目に予約患者数を記憶する。
【0129】
[ステップS1106]
次に、CPU111は、RAM112または記憶部120に記憶した病院IDのリストで示される病院の全てについて電子カルテの内容の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合(ステップS1106、NO)、CPU111は、処理を上記ステップS1101に戻し、次の病院に対する処理を行う。リストアップした全ての病院から電子カルテの内容の収集が終了したと判断した場合(ステップS1106、YES)、CPU111は、処理をステップS111に進める。
【0130】
[ステップS111]
CPU111は、収集データベース124に記憶した限定した病院それぞれの電子カルテの内容に基づいて評価値を算出する評価算出処理を実行する。
図12は、この評価算出処理の一例を例示するフローチャートである。
【0131】
[ステップS1111]
評価算出処理においては、CPU111は、まず、RAM112または記憶部120に記憶した病院IDのリストの中から一つの病院IDを選択することで、処理対象病院を決定する。
【0132】
[ステップS1112]
次に、CPU111は、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって医師を評価する。例えば、CPU111は、病院IDにより収集データベース124を参照して、処理対象病院の医師毎の時間スコアを算出する。時間スコアは、例えば、一患者当たりの診療時間の平均値による点数と待ち時間の平均値による点数との合計に基づいて算出されることができる。診療時間は、収集データベース124に記憶された診療開始から診療終了までの時間であり、待ち時間は、収集データベース124に記憶された受付から診療開始までの時間と、診療終了から会計終了までの時間との合計である。CPU111は、算出した医師毎の時間スコアを、RAM112または記憶部120に記憶する。なお、多くの場合、初診の際には診療時間が長くなるので、収集データベース124の「初診フラグ」により初診か否かを判定し、時間スコアの算出に用いる時間は、初診であれば予め決められた係数を乗じた上で用いられるようにしても良い。
【0133】
[ステップS1113]
次に、CPU111は、医師の属性情報とユーザの属性情報との関係を含む評価項目によって医師を評価する。例えば、CPU111は、RAM112または記憶部120に記憶した医師毎の時間スコアを、属性情報に基づいて補正する。属性情報は、例えば、性別や年齢を含む。CPU111は、病院データベース121に記憶された各医師の属性情報と、ユーザデータベース122に記憶された、評価要求元のユーザのユーザIDに対応する属性情報とを比較する。そして、例えば同性であればスコアを高くしたり、年齢が近いほどスコアを高くしたりする等、予め決めた規則に則って、スコア値を補正する。CPU111は、補正した医師毎の時間スコアを、RAM112または記憶部120に記憶する。
【0134】
[ステップS1114]
次に、CPU111は、ユーザ端末20から優先条件として指定された位置情報と病院の位置との関係を含む評価項目によって医師を評価する。例えば、CPU111は、上記属性情報に基づいて補正してRAM112または記憶部120に記憶した医師毎の時間スコアを、優先条件に基づいて補正する。CPU111は、ユーザデータベース122に記憶された、評価要求元のユーザのユーザIDに対応する優先条件を参照し、優先条件として指定された位置情報が、病院データベース121に記憶された当該病院の住所に対して一定の距離以内である場合には、スコア値を高くする。CPU111は、補正した医師毎の時間スコアを、RAM112または記憶部120に記憶する。
【0135】
[ステップS1115]
その後、CPU111は、時事の診療待ち患者人数及び予約患者数を含む評価項目によって医師を評価する。例えば、CPU111は、上記優先条件に基づいて補正してRAM112または記憶部120に記憶した医師毎の時間スコアを、診療待ち患者人数及び予約患者数に基づいて補正する。CPU111は、病院データベース121に記憶された医師毎の診療待ち患者人数と予約患者数とを集計し、その集計した人数が少ないほど、スコア値を高くする。CPU111は、補正した医師毎の時間スコアを、RAM112または記憶部120に記憶する。
【0136】
[ステップS1116]
次に、CPU111は、ユーザデータベース122と収集データベース124とを参照して、医師毎の症状別改善度スコアを算出する。例えば、ユーザデータベース122の各ユーザの病院毎IDに基づいて、収集データベース124から当該ユーザの症状を取得し、その症状と同じ症状のユーザを特定する。また、その症状に応じて参照するべき生体データを決定する。そして、CPU111は、その特定されたユーザが、ユーザデータベース122に登録されていれば、そのユーザの症状により決定された生体データの一定期間の履歴をユーザデータベース122から読み出して評価する。例えば、症状が高血圧であれば、CPU111は、一定期間の血圧値を読み出して評価する。
【0137】
図13は、この読み出した生体データの履歴の一例を示す図である。この図の例では、一定期間Pの間に、収縮期血圧がDだけ下がっている。例えば、収縮期血圧の一定期間P、例えば一ヶ月間の低下量Dが20mmHg以上であれば満点である10点とし、低下量が1mmHg少なくなる毎に1点減らす、などとスコアを決定する。
【0138】
図14は、生体データの履歴の別の例を示す図である。この図の例も、一定期間Pの間の収縮期血圧の低下量Dが、
図13の例と同じスコアとなる範囲であったとする。しかしこの例では、一時的に悪化した履歴が含まれている。このような場合、そのまま
図13の例と同じスコアとしても良いが、
図13の例よりも低く算出しても良い。特に、一時的に悪化した状態から改善へ転じたタイミングが、別の病院や医師への切り替わりが有ったタイミングであった場合、一時的に悪化した状態が誤診によるものである可能性が高い。CPU111は、例えば、収集データベース124の予約日時項目に記録された日付と、ユーザデータベース122の日付項目に記録された日付及び通院フラグ項目に記録された通院の記録とに基づいて、この誤診の可能性を判断し、その結果に応じてスコアを修正することができる。
【0139】
CPU111は、こうして算出した医師毎の症状別改善度スコアをRAM112または記憶部120に記憶する。
【0140】
[ステップS1117]
次に、CPU111は、RAM112または記憶部120に記憶した医師毎の、症状別改善度スコアと補正後の時間スコアとから、総合スコアを算出する。更に、CPU111は、医師毎の総合スコアから、診療科スコア及び病院スコアを算出する。CPU111は、こうして算出した医師毎の総合スコア、診療科スコア及び病院スコアをRAM112または記憶部120に記憶する。
【0141】
[ステップS1118]
そして、CPU111は、こうして算出してRAM112または記憶部120に記憶した各スコアを、評価データベース125に、ユーザIDに対応させて登録する。このように、属性情報や優先条件などに基づいて時間スコアを補正することで、
図7に示すように、同じ医師、診療科、病院であっても、ユーザ毎に異なるスコア値が評価データベース125に登録されることになる。
【0142】
[ステップS1119]
次に、CPU111は、RAM112または記憶部120に記憶した病院IDのリストで示される病院の全てについて評価値の算出が終了したか否かを判断する。未だ評価値を算出していない病院があると判断した場合(ステップS1119、NO)、CPU111は、処理を上記ステップS1111に戻し、次の病院に対する処理を行う。リストアップした全ての病院について評価値の算出が終了したと判断した場合(ステップS1119、YES)、CPU111は、処理をステップS112に進める。
【0143】
[ステップS112]
CPU111は、RAM112または記憶部120に記憶した評価対象条件に従って、評価データベース125に記憶されている評価要求元のユーザのユーザIDに対応する評価結果を読み出してソートする。例えば、評価対象条件が病院であれば、病院IDと病院スコアの組を読み出して、病院スコアが高い順にソートする。また、例えば、評価対象条件が医師であれば、医師IDと総合スコアの組を読み出して、総合スコアが高い順にソートする。CPU111は、ソートした結果を、RAM112または記憶部120に記憶する。
【0144】
[ステップS113]
そして、CPU111は、RAM112または記憶部120に記憶しているソートした結果に基づいて予約候補を決定して、通信インタフェース130により通信ネットワークNETを介して、評価要求元のユーザ端末20に送信する。予約候補の数は、少なくとも一つ有れば良いが、ユーザに選択肢を与えるために複数決定して送信することが望ましい。勿論、ユーザ端末20からの折り返しの指示により、順次に次候補を決定して送信するようにしても構わない。予約候補は、RAM112または記憶部120に記憶した評価対象条件に従って決定される。例えば、評価対象条件が病院であれば、少なくとも病院の名称や住所を含む病院情報と、その病院のスコア値とを含むことができる。病院情報は、病院データベース121より取得することができる。また、例えば、評価対象条件が医師であれば、少なくとも医師の氏名、性別、年齢を含む医師情報及び当該医師のスコア値と、当該医師が所属する病院の病院情報及び当該病院のスコア値と、を含むことができる。医師情報及び病院情報は、病院データベース121より取得することができる。
【0145】
[ステップS2094]
上記ステップS2093において予約候補を受信したと判断した場合(ステップS2093、YES)、ユーザ端末20のプロセッサは、処理をステップS2094に進め、その受信した予約候補を図示しないユーザインタフェースによりユーザに提示する。
【0146】
<1-2-4>予約動作
[ステップS114]
上記ステップS113において予約候補を送信後、サービスサーバ100のCPU111は、通信インタフェース130により通信ネットワークNETを介して、当該ユーザ端末20からの予約要求を受信したか否かを判断する。予約要求を受信していないと判断した場合(ステップS114、NO)、CPU111は、処理をステップS115に進める。
【0147】
[ステップS2095]
また、ユーザ端末20の図示しないプロセッサは、上記ステップS2094において受信した予約候補をユーザに提示した後、図示しないユーザインタフェースを通じたユーザ操作による、終了又は予約の入力を受け付ける。予約の入力は、予約を望む病院または医師の選択と、希望日時の入力とを含む。
【0148】
[ステップS2096]
そして、ユーザ端末20のプロセッサは、受け付けた入力が終了の入力であるか否かを判断する。受け付けた入力が終了の入力ではない、つまり予約の入力であると判断した場合(ステップS2096、NO)、プロセッサは、処理をステップS2097に進める。
【0149】
[ステップS2097]
上記ステップS2096において予約の入力を受け付けたと判断した場合(ステップS2096、NO)、ユーザ端末20のプロセッサは、予約要求を、通信ネットワークNETを介してサービスサーバ100に送信する。
【0150】
[ステップS2098]
その後、ユーザ端末20のプロセッサは、通信ネットワークNETを介してサービスサーバ100からの予約結果を受信するのを待つ。すなわち、プロセッサは、予約結果を受信したか否かを判断し、受信していない場合(ステップS2098、NO)、このステップS2098の処理を繰り返す。
【0151】
[ステップS116]
サービスサーバ100のCPU111は、上記ステップS114において予約要求を受信したと判断した場合(ステップS114、YES)、処理をステップS116に進め、通信インタフェース130により通信ネットワークNETを介して、該当病院の病院サーバ30へ、予約要求を、ユーザデータベース122に記憶されている当該ユーザのPHRと共に送信する。全生体データを含むPHRではなく、最新の生体データのみで有っても良い。またこのとき、CPU111は、ユーザデータベース122の病院毎IDを参照して、もし当該ユーザが該当病院における管理番号を有するユーザであることが確認できた場合には、この予約要求にその管理番号を含めることができる。
【0152】
[ステップS117]
その後、CPU111は、通信インタフェース130により通信ネットワークNETを介して、該当病院の病院サーバ30からの予約結果を受信するのを待つ。すなわち、CPU111は、予約結果を受信したか否かを判断し、受信していないと判断した場合(ステップS117、NO)、このステップS117を繰り返す。
【0153】
患者の予約管理を行う病院サーバ30では、この予約要求に応じた予約処理を行う。そして、その結果を通信ネットワークNETを介してサービスサーバ100に返す。
【0154】
[ステップS118]
上記ステップS117において予約結果を受信したと判断した場合(ステップS117、YES)、CPU111は、通信インタフェース130により通信ネットワークNETを介して、予約要求元のユーザ端末20へ予約結果を送信する。その後、CPU111は、処理を上記ステップS114に戻す。
【0155】
[ステップS2099]
上記ステップS2098において予約結果を受信したと判断した場合(ステップS2098、YES)、ユーザ端末20のプロセッサは、処理をステップS2099に進め、その受信した予約結果を図示しないユーザインタフェースによりユーザに提示する。その後、プロセッサは、処理を上記ステップS2095に戻す。
【0156】
もし、所望の予約が取れないという予約結果であったならば、ステップS2095において、ユーザは別の予約希望日時を再設定したり、別の病院、別の医師などを選択したりすることが可能である。また、所望の予約が取れた場合には、ユーザは医療評価の処理を終了するために、終了の入力を行う。
【0157】
<1-2-5>終了動作
[ステップS20910]
ユーザ端末20の図示しないプロセッサは、上記ステップS2096において受け付けた入力が終了の入力であると判断した場合(ステップS2096、YES)、処理をステップS20910に進め、終了要求を、通信ネットワークNETを介してサービスサーバ100に送信する。そして、プロセッサは、処理を上記ステップS201に戻す。
【0158】
[ステップS115]
サービスサーバ100のCPU111は、上記ステップS114において予約要求を受信していないと判断した場合(ステップS114、NO)、更に、通信インタフェース130により通信ネットワークNETを介して、当該ユーザ端末20からの終了要求を受信したか否かを判断する。終了要求を受信していないと判断した場合(ステップS115、NO)、CPU111は、処理を上記ステップS114に戻す。終了要求を受信したと判断した場合(ステップS115、YES)、CPU111は、処理を上記ステップS101に戻す。
【0159】
<1-2-6>その他の処理
[ステップS210]
ユーザ端末20の制御部21の図示しないプロセッサは、上記ステップS208において行われた操作は医療評価の取得指示ではないと判断した場合(ステップS208、NO)その操作に応じた、その他の処理を実行する。このその他の処理は、例えば、サービスサーバ100の上記ステップS104でのユーザデータベース122の更新処理を行うための当該ユーザの新規登録操作や情報更新操作に応じた処理を含む。そして、処理実行後、プロセッサは、処理を上記ステップS201に戻す。
【0160】
<1-3>効果
上述した第1実施形態によれば、サービスサーバ100のCPU111が、複数の病院の間で電子カルテを共有するための電子カルテネットワーク1から各電子カルテの記載内容を収集すると共に、各ユーザのユーザ端末20から複数のユーザそれぞれの生体データの一定期間の履歴を収集し、これら収集した情報に基づいて、少なくとも病院毎、更には各病院の診療科毎または各病院の医師毎に、少なくとも一患者当たりの診療時間及び待ち時間に基づく時間スコアと、各ユーザの症状の改善度に基づく症状別改善度スコアとを算出して、評価データベース125に記憶する。よって、時間という客観的な指標と症状の改善度というユーザの症状の改善状況とに基づいて、少なくとも病院を、更には病院の診療科または医師を評価することができるようになる。そして、CPU111は、この評価スコアをユーザ端末20に送信してユーザに提示することで、ユーザは、自身が診療を受けようとする病院、診療科又は医師を、この提示されたスコアを参考にして、選定することが可能となる。
【0161】
また、第1実施形態によれば、評価結果を評価値つまりスコアという数値で求めていることで、その数値により評価結果を順番付けでき、その結果、ユーザに適した予約候補を容易に決定することができる。
【0162】
また、第1実施形態によれば、対応関係データベース123を用いることで、容易且つ迅速に評価対象の病院又は医師を限定することができる。
【0163】
また、第1実施形態によれば、病院予約サービスに加入するユーザの各ユーザ端末20からPHRを収集することで、ユーザの生体データを容易に収集することができる。
【0164】
また、第1実施形態によれば、時間的評価だけでなく、症状の改善度という症状の改善状況に基づいた評価を加えることで、よりユーザに適した候補を提供することができる。
【0165】
また、第1実施形態によれば、スコア値という点数化した評価値を用い、予約候補をその数値と共にユーザ端末20に送信して提示することで、ユーザが予約する病院を選定する際の指標を提供することができ、ユーザの選定を容易にすることが可能となる。
【0166】
また、第1実施形態によれば、評価要求元のユーザの性別又は年齢と医師の性別又は年齢とにも基づいて評価するので、ユーザに適した医師を高く評価することができ、ユーザにより適した医師を候補とすることができるようになる。
【0167】
また、第1実施形態によれば、評価要求元のユーザの現在位置やユーザが指定した指定位置に応じて、ユーザが通い得る病院を限定することで、ユーザに不適切な病院を候補として提示する可能性を小さくすることができる。
【0168】
また、第1実施形態によれば、病院又は医師の評価値を算出する際に、現時点における診療待ち患者人数と今後の予約状況とを参照し、待ち時間少なく直ぐに診療可能な病院や医師ほど高スコアとすることで、ユーザが予期せず空き時間が取れたときや、急に具合が悪くなったときなど、今すぐ診療可能な病院を探す場合に、有効な手段を提供することができる。
【0169】
なお、今すぐ診療可能な病院を探す場合には、ユーザ端末20における上記ステップS2091の条件入力の際に、その点を指定できるようにすることで、上記ステップS1115における診療待ち患者人数及び予約患者数に基づいた補正の重みを重くする、つまりスコア値を高くするようにしても良い。あるいは、上記ステップS1113の属性情報に基づく補正や上記ステップS1114における優先条件に基づく補正の重みを軽くしたり、それらの補正をスキップしたりできるようにしても良い。
【0170】
また、上述したような病院予約システムによってユーザが病院予約を行った場合、サービスサーバ100は、予約先の病院から紹介料金を徴収できる課金処理の手順を有しても良い。
【0171】
また、病院は、上述したようなサービスサーバ100の処理手順によって予約されたユーザに対しては、紹介状を不要又は減額とするようなサービスを提供するようにしても良い。
【0172】
<2>第2実施形態
次に、第2実施形態について説明する。
【0173】
<2-1>構成及び<2-2>動作
本第2実施形態に係る病院予約システムの基本的な構成及び基本的な動作は、上述した第1実施形態に係る病院予約システムと同様である。従って、上述した第1実施形態で説明した事項及び上述した第1実施形態から容易に類推可能な事項についての説明は省略する。
【0174】
図15は、第2実施形態におけるサービスサーバ100の処理手順の一例を例示するフローチャートである。
図8と同様の処理については同じ参照符号を付す。
【0175】
<2-2-1>収集動作
[ステップS119]
サービスサーバ100のCPU111は、先ず、生体データ及び電子カルテを収集するべきタイミングになったか否かを判断する。本実施形態では、例えば、1日1回など、予め決めたタイミングで生体データ及び電子カルテを収集する。生体データ及び電子カルテを収集するべきタイミングではないと判断した場合(ステップS119、NO)、CPU111は、処理をステップS103に進める。生体データ及び電子カルテを収集するべきタイミングであると判断した場合(ステップS119、YES)、CPU111は、処理をステップS102に進める。
【0176】
[ステップS102]
上記ステップS101において生体データ及び電子カルテを収集するべきタイミングであると判断した場合(ステップS101、YES)、CPU111は、先ず、上記第1実施形態と同様の生体データ収集処理を実行する。
【0177】
[ステップS120]
次に、CPU111は、電子カルテ収集処理を実行する。この場合、上記第1実施形態におけるステップS110の電子カルテ収集処理と異なり、対象病院の限定を行っていないので、CPU111は、限定されない、つまり全ての病院の電子カルテの内容を収集することとなる。
図16は、この電子カルテ収集処理の一例を例示するフローチャートである。
【0178】
[ステップS1201]
電子カルテ収集処理においては、CPU111は、まず、病院データベース121に登録されている病院IDの中から一つの病院IDを選択することで、取得先病院を決定する。
【0179】
[ステップS1202]
次に、CPU111は、通信インタフェース130により通信ネットワークNETを介して、データサーバ40からその取得先病院の電子カルテの内容を取得する。このステップS1202の処理は、上記第1実施形態におけるステップS1102の処理と同様である。すなわち、CPU111は、病院IDにより病院データベース121を参照して、当該病院を特定する特定情報、例えば病院ID、アクセス情報、病院名、住所または電話番号を読み出す。そして、CPU111は、通信インタフェース130により通信ネットワークNETを介してデータサーバ40の制御部41に、この特定情報と共に電子カルテの記載内容の送信を依頼する。CPU111は、これに応答してデータサーバ40から送信されてきた電子カルテの内容を通信インタフェース130により受信する。
【0180】
なお、取得先病院の電子カルテの数が多い場合には、処理時間が掛かることが想定されるため、電子カルテのタイムスタンプにより最新のものから、人数や期間を限定した送信を依頼するようにしても良い。
【0181】
[ステップS1203]
次に、CPU111は、受信した電子カルテの内容に基づいて、病院データベース121及び収集データベース124に情報を登録する。例えば、CPU111は、患者ID毎に、電子カルテに記載された、各回の診療に関する情報、つまり予約日時、受付、診療開始、医師ID、診療終了、会計終了、初診フラグ、症状を収集データベース124に記憶する。
【0182】
[ステップS1204]
次に、CPU111は、病院データベース121に登録されている病院IDで示される病院の全てについて電子カルテの内容の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合(ステップS1204、NO)、CPU111は、処理を上記ステップS1201に戻し、次の病院に対する処理を行う。登録されている全ての病院から電子カルテの内容の収集が終了したと判断した場合(ステップS1204、YES)、CPU111は、処理をステップS103に進める。
【0183】
<2-2-2>登録情報更新動作
[ステップS103]~[ステップS108]
CPU111は、上記ステップS119において生体データ及び電子カルテを収集するべきタイミングではないと判断した場合(ステップS119、NO)、或いは、上記ステップS110の電子カルテ収集処理の終了後、上記第1実施形態と同様の[ステップS101]乃至[ステップS106]の処理を行う。但し、上記ステップS106において評価要求を受信していないと判断した場合(ステップS106、NO)の処理の戻り先は、上記ステップS119である。すなわち、CPU111は、病院データベース121の更新処理とユーザデータベース122の更新処理とを行う。そして、CPU111は、何れかのユーザ端末20からPHR又は評価要求を受信したか否かを判断する。何れも受信していないと判断した場合、CPU111は、処理を上記ステップS119に戻す。PHRを受信したと判断した場合には、CPU111は、受信したPHRに基づいて、ユーザデータベース122の、対応するユーザの日付や生体データ(「血圧」、「脈拍」、など)の項目を更新する。また、評価要求を受信したと判断した場合には、CPU111は、受信した評価要求に含まれるユーザID及びパスワードによりユーザ認証を行った上で、同じく評価要求に含まれる位置情報及び評価要求に含まれる優先条件により、ユーザデータベース122を更新する。
【0184】
<2-2-3>評価動作
[ステップS109]
評価要求を受信してユーザデータベース122を更新した後、CPU111は、上記第1実施形態と同様に、評価対象の病院を限定する。
【0185】
[ステップS121]
その後、CPU111は、上記ステップS109で限定した病院それぞれにおける現在時点の診療待ち患者人数と予約患者数を集計する人数収集処理を行う。すなわち、上記ステップS120では、例えば、1日1回など、予め決めたタイミングで電子カルテの内容を収集するので、診療待ち患者人数と予約患者数の集計は行っていない。そこで、CPU111は、それら人数を収集する。
図17は、この人数収集処理の一例を例示するフローチャートである。
【0186】
[ステップS1211]
人数収集処理においては、CPU111は、まず、RAM112または記憶部120に記憶した限定した病院IDのリストの中から一つの病院IDを選択することで、取得先病院を決定する。
【0187】
[ステップS1212]
次に、CPU111は、通信インタフェース130により通信ネットワークNETを介して、その取得先病院から診療待ち患者人数及び予約患者数を取得する。例えば、CPU111は、病院IDにより病院データベース121を参照して当該病院のアクセス情報を読み出し、通信インタフェース130により通信ネットワークNETを介して当該病院の病院サーバ30の制御部31に、各医師についての現在時点の診療待ち患者人数と予約患者数とを問い合わせる。そして、CPU111は、この問い合わせに応答して病院サーバ30から送信されてきた診療待ち患者人数及び予約患者数の情報を通信インタフェース130により受信する。
【0188】
[ステップS1213]
次に、CPU111は、受信した各医師についての現在時点での診療待ち患者人数及び予約患者数の情報に従って、病院データベース121の各医師IDに対応させて「待ち」及び「予約状況」の項目にそれぞれの人数を記憶する。
【0189】
[ステップS1214]
次に、CPU111は、RAM112または記憶部120に記憶した病院IDのリストで示される病院の全てについて人数の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合(ステップS1214、NO)、CPU111は、処理を上記ステップS1211に戻し、次の病院に対する処理を行う。リストアップした全ての病院から人数の収集が終了したと判断した場合(ステップS1214、YES)、CPU111は、処理をステップS111に進める。
【0190】
[ステップS111]~[ステップS113]
その後、CPU111は、上記第1実施形態と同様の[ステップS111]乃至[ステップS113]の処理を行う。すなわち、CPU111は、収集データベース124に記憶した各病院の電子カルテの内容の内、この限定した病院の内容に基づいてのみ、評価値を算出する。その後、CPU111は、評価条件に含まれる評価対象条件に従って、評価データベース125に記憶されている評価要求元のユーザのユーザIDに対応する評価結果を読み出してソートし、そのソートした結果と評価対象条件に従って予約候補を決定する。そしてCPU111は、その決定した予約候補を、通信インタフェース130により通信ネットワークNETを介して、評価要求元のユーザ端末20に送信する。
【0191】
<2-2-4>予約動作、<2-2-5>終了動作
[ステップS114]~[ステップS118]
その後の[ステップS114]乃至[ステップS118]の処理は、上記第1実施形態と同様である。但し、上記ステップS115において終了要求を受信したと判断した場合(ステップS115、YES)の処理の戻り先は、上記ステップS119である。
【0192】
<2-3>効果
上述した第2実施形態によれば、上記第1実施形態と同様の効果を奏することができる。また、この第2実施形態では、電子カルテの記載内容を予め全ての病院について収集しておくので、ユーザからの評価要求に応じて直ちに評価値の算出処理を実行でき、レスポンス良くユーザに評価結果を提示することが可能になる。
【0193】
<3>第3実施形態
次に、第3実施形態について説明する。
【0194】
<3-1>構成及び<3-2>動作
本第3実施形態に係る病院予約システムの基本的な構成及び基本的な動作は、上述した第2実施形態に係る病院予約システムと同様である。従って、上述した第2実施形態で説明した事項及び上述した第2実施形態から容易に類推可能な事項についての説明は省略する。
【0195】
図18は、第3実施形態におけるサービスサーバ100の処理手順の一例を例示するフローチャートである。
図15と同様の処理については同じ参照符号を付す。
【0196】
<3-2-1>収集動作及び第1評価動作
[ステップS119]、[ステップS102]、[ステップS120]
サービスサーバ100のCPU111は、先ず、上記第2実施形態と同様に、生体データ及び電子カルテを収集するべきタイミングになったか否かを判断する。生体データ及び電子カルテを収集するべきタイミングであると判断した場合(ステップS119、YES)、CPU111は、上記第2実施形態と同様の[ステップS102]及び[ステップS120]の処理を行う。すなわち、CPU111は、上記第1実施形態と同様の生体データ収集処理と上記第2実施形態と同様の電子カルテ収集処理とを実行する。
【0197】
[ステップS122]
その後、CPU111は、収集データベース124に記憶した各病院の電子カルテの内容に基づいて評価値を算出する第1評価算出処理を実行する。この第1評価算出処理においては、評価値として、医師毎の時間スコアを算出する。
図19は、この第1評価算出処理の一例を例示するフローチャートである。
【0198】
[ステップS1221]
第1評価算出処理においては、CPU111は、まず、病院データベース121に登録されている病院IDの中から一つの病院IDを選択することで、処理対象病院を決定する。
【0199】
[ステップS1112]
次に、CPU111は、上記第1実施形態と同様に、病院IDにより収集データベース124を参照して、処理対象病院の医師毎の時間スコアを算出する。CPU111は、算出した医師毎の時間スコアを、RAM112または記憶部120に記憶する。
【0200】
[ステップS1222]
次に、CPU111は、算出してRAM112または記憶部120に記憶した当該病院に所属する各医師の時間スコアを、評価データベース125における該当する医師IDに対応する総合スコアの項目に登録する。
【0201】
[ステップS1223]
そして、CPU111は、病院データベース121に記憶されている病院IDで示される病院の全てについて評価値の算出が終了したか否かを判断する。未だ評価値を算出していない病院があると判断した場合(ステップS1223、NO)、CPU111は、処理を上記ステップS1211に戻し、次の病院に対する処理を行う。全ての病院について評価値の算出が終了したと判断した場合(ステップS1223、YES)、CPU111は、処理をステップS103に進める。
【0202】
<3-2-2>登録情報更新動作
[ステップS103]~[ステップS108]
[ステップS103]乃至[ステップS108]の処理は、上記第1実施形態と同様である。
【0203】
<3-2-3>第2評価動作
[ステップS109]
評価要求を受信してユーザデータベース122を更新した後、サービスサーバ100のCPU111は、上記第1実施形態と同様、ユーザデータベース122の該当するユーザの優先条件項目に記憶された情報の内、位置を規定する情報により、評価対象の病院を限定する。
【0204】
[ステップS121]
次に、CPU111は、上記第2実施形態と同様に、上記ステップS109で限定した病院それぞれにおける現在時点の診療待ち患者人数と予約患者数の問合せを行って、結果を病院データベース121に登録する人数収集処理を行う。
【0205】
[ステップS123]
その後、CPU111は、収集データベース124に記憶した各病院の電子カルテの内容に基づいて評価値を算出する第2評価算出処理を実行する。
図20は、この第2評価算出処理の一例を例示するフローチャートである。
【0206】
[ステップS1111]
第2評価算出処理においては、CPU111は、上記第1実施形態と同様に、まず、RAM112または記憶部120に記憶した病院IDのリストの中から一つの病院IDを選択することで、処理対象病院を決定する。
【0207】
[ステップS1231]
そして、その処理対象病院に所属する各医師の医師IDを病院データベース121により取得し、その医師IDに対応する時間スコアを、評価データベース125における該当医師IDに対応する総合スコアの項目から読み出し、RAM112または記憶部120に記憶する。
【0208】
[ステップS1113]~[ステップS1119]
その後の[ステップS1113]乃至[ステップS1119]の処理は、上記第1実施形態と同様である。すなわち、CPU111は、RAM112または記憶部120に記憶した医師毎の時間スコアを、属性情報及び優先条件に基づいて補正し、更に、診療待ち患者人数及び予約患者数に基づいて補正する。また、CPU111は、ユーザデータベース122と収集データベース124とを参照して、医師毎の症状別改善度スコアを算出する。そして、CPU111は、医師毎の、症状別改善度スコアと補正後の時間スコアとから、総合スコアを算出し、更に、この医師毎の総合スコアから、診療科スコア及び病院スコアを算出し、算出した各スコアを、評価データベース125に、ユーザIDに対応させて登録する。その後、CPU111は、RAM112または記憶部120に記憶した病院IDのリストで示される病院の全てについて評価値の算出が終了したか否かを判断し、未だ評価値を算出していない病院があれば、処理を上記ステップS1111に戻し、次の病院に対する処理を行う。そして、リストアップした全ての病院について評価値の算出が終了したと判断した場合、CPU111は、処理をステップS112に進める。
【0209】
[ステップS112]、[ステップS113]
その後の[ステップS112]及び[ステップS113]の処理は、上記第1実施形態と同様である。すなわち、CPU111は、評価条件に含まれる評価対象条件に従って、評価データベース125に記憶されている評価要求元のユーザのユーザIDに対応する評価結果を読み出してソートし、そのソートした結果と評価対象条件に従って予約候補を決定する。そしてCPU111は、その決定した予約候補を、通信インタフェース130により通信ネットワークNETを介して、評価要求元のユーザ端末20に送信する。
【0210】
<3-2-4>予約動作、<3-2-5>終了動作
[ステップS114]~[ステップS118]
その後の[ステップS114]乃至[ステップS118]の処理は、上記第1実施形態と同様である。但し、上記ステップS115において終了要求を受信したと判断した場合(ステップS115、YES)の処理の戻り先は、上記ステップS119である。
【0211】
<3-3>効果
上述した第3実施形態によれば、上記第2実施形態と同様の効果を奏することができる。また、この第3実施形態では、ユーザに依存しない評価値を予め算出しておくので、ユーザからの評価要求に応じて直ちにユーザに依存する評価値の算出処理を実行でき、レスポンス良くユーザに評価結果を提示することが可能になる。
【0212】
この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除しても良い。さらに、異なる実施形態に亘る構成要素を適宜組み合せても良い。
【0213】
例えば、フローチャートを参照して説明した処理手順は一例に過ぎず、各処理は可能な限り変更されて良い。また、説明した処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。
【0214】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られるものではない。
【0215】
(付記1)
複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワーク(1)と、
前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部(11)と、
通信ネットワーク(NET)を介して、複数のユーザそれぞれの生体データを収集する生体データ収集部(12)と、
前記通信ネットワークを介して、ユーザ端末(20)から要求を受け付ける受付部(13)と、
前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部(14)と、
前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部(15)と、
前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部(16)と、
前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部(31)と、
前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部(17)と、
を具備する、病院予約システム。
【0216】
(付記2)
プロセッサ(111)及びメモリ(112,120)を有するサーバ装置が実行する病院予約方法であって、
前記プロセッサにより、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集して前記メモリに記憶する過程(S110)と、
前記プロセッサにより、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集して前記メモリに記憶する過程(S102)と、
前記プロセッサにより、前記通信ネットワークを介して、ユーザ端末から評価要求を前記ユーザ端末のユーザの生体データと共に受け付ける過程(S106)と、
前記ユーザ端末からの前記評価要求に応じて、前記プロセッサにより、前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記メモリに記憶された前記複数のユーザそれぞれの前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する過程(S109)と、
前記プロセッサにより、前記メモリに記憶された前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記評価対象として限定された前記複数の病院又は医師を評価し、その評価結果を前記メモリに記憶する過程(S111)と、
前記プロセッサにより、前記メモリに記憶された前記複数の病院又は医師の評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる過程(S113)と、
前記プロセッサにより、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求を、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付ける過程(S114)と、
前記要求元の前記ユーザ端末からの前記病院又は医師に対する予約要求に応じて、前記プロセッサにより、前記通信ネットワークを介して、その依頼された前記病院又は医師に該当する病院が備える患者の予約管理を行う病院制御部に、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する過程(S116)と、
を備える病院予約方法。
【0217】
(付記3)
請求項10に記載のサーバ装置が具備する前記電子カルテ収集部(11)、前記生体データ収集部(12)、前記受付部(13)、前記限定部(14)、前記評価部(15)、前記提示部(16)、及び前記予約部(17)としてプロセッサを機能させる病院予約プログラム。
【符号の説明】
【0218】
1…電子カルテネットワーク
10…サービスサーバ
11…電子カルテ収集部
12…生体データ収集部
13…受付部
14…限定部
15…評価部
16…提示部
17…予約部
18…対応関係データベース
19…医師属性取得部
20…ユーザ端末
21,31,41,110…制御部
22…測定部
23,32,42,120…記憶部
24…生体データ計測装置
30…病院サーバ
33…医療端末
40…データサーバ
100…サービスサーバ
111…CPU
112…RAM
113…ROM
121…病院データベース
122…ユーザデータベース
123…対応関係データベース
124…収集データベース
125…評価データベース
130…通信インタフェース