(第一の実施形態)
以下に、図面を参照して第一の実施形態について説明する。図1は、第一の実施形態の予約システムを説明する図である。
予約システム100において、予約サーバ200は、バイタルサインを測定する測定装置400からの測定値を受信する(ステップS1)。そして予約サーバ200、この測定値が正常範囲内にない場合に、本システムの利用者と対応付けられた携帯端末300に対し、医療機関での診察の予約を促すメッセージを表示させる(ステップS2)。本システムの利用者とは、例えば実際に測定装置400でバイタルサインを測定した人であっても良いし、バイタルサインを測定した人が未成年や要介護者等であった場合には、利用者はその保護者や介護者等であっても良い。
予約サーバ200は、携帯端末300において予約依頼がなされると(ステップS3)、指定された医療機関に対して診察の予約申請を行う。
また、予約サーバ200は、例えば医療機関に対する予約を行った後に再度測定装置400から測定値を受信した際に(ステップS4)、測定値が正常範囲となっていた場合、携帯端末300に対して予約のキャンセルを促すメッセージを表示させる(ステップS5)。予約サーバ200は、携帯端末300から予約のキャンセル要求を受けると(ステップS6)、予約のキャンセル申請を行う。
以下に、本実施形態の予約システム100の利用例を説明する。例えば、携帯端末300は、乳児の保護者の端末であるものとし、バイタルサインを体温として説明する。
乳児が発熱した場合、保護者は測定装置400で乳児の体温を測定する。測定装置400は、測定値を予約サーバ200へ送信する。この測定値が、例えば予め設定された平熱の範囲内にない場合、予約サーバ200は、保護者の端末である携帯端末300に、診察の予約を行うか否かを問う画面を表示させる。ここで、携帯端末300において予約の依頼がなされると、予約サーバ200は、後述する医療機関の予約端末へ予約申請を行う。
したがって、本実施形態によれば、保護者は、乳児の体温を測定し、携帯端末300に表示された問いに回答するだけで予約を行うことができ、コンピュータを立ち上げたり、病院に電話を掛けたりする手間をなくすことができる。
保護者は、例えば予約後に、医療機関に向かう前に、再度乳児の体温を測定装置400により測定することが考えられる。測定された体温は、予約サーバ200へ送信される。このとき、測定値(体温)が平熱の範囲内まで下がっていた場合、予約サーバ200は、予約をキャンセルするか否かを問う画面を携帯端末300に表示させる。予約サーバ200は、携帯端末300からキャンセル要求を受けると、医療機関の予約端末へ予約のキャンセル申請を行う。
したがって、本実施形態によれば、保護者は、乳児の体温を測定するだけで、自身の携帯端末300に予約をキャンセルするか否かを問う画面が表示されるため、予約のキャンセルを忘れることが少なくなる。よって、本実施形態によれば、キャンセルされるべき予約により、他の人の予約を妨害することを抑制できる。また、本実施形態によれば、保護者は自身の携帯端末300に表示された問いに回答するだけで予約や予約のキャンセルを行うことができ、コンピュータを立ち上げたり、病院に電話を掛けたりする手間をなくすことができる。
以上のことから、本実施形態によれば、予約に係る手間を軽減させることができる。
図2は、第一の実施形態の予約システムのシステム構成を説明する図である。本実施形態の予約システム100は、予約サーバ200と、携帯端末300とを有する。予約サーバ200と携帯端末300とは、ネットワークを介して接続されている。予約サーバ200は、測定装置400とネットワークを介して接続されている。さらに、予約サーバ200には、病院等の医療機関に設置された予約端末500−1、500−2、・・・、500−Nがネットワークを介して接続されている。すなわち本実施形態の携帯端末300は、予約サーバ200や予約端末500と通信を行う通信端末である。
本実施形態の予約サーバ200は、予約プログラム210がインストールされており、測定値データベース220、設定データベース230、病院データベース240、かかりつけ病院管理データベース250、診察データベース260を有する。
本実施形態の携帯端末300は、予約依頼プログラム310がインストールされている。
本実施形態の予約端末500−1、500−2、・・・、500−Nは、それぞれが予約データベース510−1、510−2、・・・、510−Nを有する。以下の説明では、予約端末500−1、500−2、・・・、500−Nのそれぞれを区別しない場合には、単に予約端末500と呼ぶ。また、以下の説明では、予約データベース510−1、510−2、・・・、510−Nのそれぞれを区別しない場合には、単に予約データベース510と呼ぶ。
本実施形態の予約システム100の測定装置400は、人のバイタルサインを測定する装置である。バイタルサインとは、生命兆候を示す値であり、少なくとも血圧、脈拍数・呼吸速度、体温の何れかを含む。以下の実施形態では、測定装置400を体温計として説明するが、測定装置400は、バイタルサインを測定する装置であれば良く、例えば血圧計等であっても良い。また、本実施形態では、バイタルサインに血糖値等が含まれても良い。
本実施形態の予約端末500は、例えば予約端末500が設置された医療機関における予約管理を行う予約端末である。
図3は、第一の実施形態の予約サーバのハードウェア構成の一例を示す図である。
本実施形態の予約サーバ200は、それぞれバスBで相互に接続されている入力装置21、出力装置22、ドライブ装置23、補助記憶装置24、メモリ装置25、演算処理装置26及びインターフェース装置27を有する。
入力装置21は、例えばマウスやキーボード等であり、各種信号の入力に用いられる。出力装置22は、例えばディスプレイ等であり、情報の出力に用いられる。インターフェース装置27は、モデム,LANカード等を含み、ネットワークに接続する為に用いられる。
予約プログラム210は、予約サーバ200を制御する各種プログラムの少なくとも一部である。予約プログラム210は例えば記録媒体28の配布やネットワークからのダウンロードなどによって提供される。予約プログラム210を記録した記録媒体28は、CD−ROM、フレキシブルディスク、光磁気ディスク等の様に情報を光学的,電気的或いは磁気的に記録する記録媒体、ROM、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。
また、予約プログラム210を記録した記録媒体28がドライブ装置23にセットされると、予約プログラム210は記録媒体28からドライブ装置23を介して補助記憶装置24にインストールされる。ネットワークからダウンロードされた予約プログラム210は、インターフェース装置27を介して補助記憶装置24にインストールされる。
補助記憶装置24は、インストールされた予約プログラム210を格納すると共に、必要なファイル、データ等を格納する。メモリ装置25は、コンピュータの起動時に補助記憶装置24から予約プログラム210を読み出して格納する。そして、演算処理装置26はメモリ装置25に格納された予約プログラム210に従って、後述するような各種処理を実現している。
尚、本実施形態の予約サーバ200は、例えばタブレット型のコンピュータであっても良い。その場合、予約サーバ200は、入力装置21と出力装置22のかわりに、タッチパネル等により実現される表示操作装置を有する。
本実施形態の携帯端末300のハードウェア構成は、予約サーバ200がタブレット型のコンピュータであった場合と同様であるから、説明を省略する。
以下に、図4乃至図8を参照し、予約サーバ200の有する各データベースについて説明する。
図4は、測定値データベースの一例を示す図である。本実施形態の測定値データベース220は、情報の項目として、利用者ID、測定日時、測定値を有し、項目「利用者ID」の値と、他の項目の値とが対応付けられている。以下の説明では、項目「利用者ID」の値と、項目「利用者ID」の値と対応付けられた他の項目の値とを、測定情報と呼ぶ。
項目「利用者ID」の値は、例えば本実施形態の予約システム100を利用する利用者に与えられる利用者識別情報を示す。
項目「測定日時」の値は、測定装置400による測定が行われた日時を示す。項目「測定値」の値は、測定結果の値を示す。図4の例では、測定値は体温の値である。
本実施形態では、測定装置400に、利用者IDが予め設定されており、測定装置400が予約サーバ200へ測定値を送信する際に、測定装置400に設定された利用者IDと、測定日時とを合わせて送信するものとした。
図5は、設定データベースの一例を示す図である。本実施形態の設定データベース230は、情報の項目として、利用者ID、設定項目、設定値を有し、項目「利用者ID」の値と、他の項目の値とが対応付けられている。以下の説明では、項目「利用者ID」の値と、項目「利用者ID」の値と対応付けられた他の項目の値とを、設定情報と呼ぶ。
本実施形態の項目「設定項目」の値は、設定が行われる項目を示す、項目「設定値」の値は、設定項目に対して設定された値を示す。
図5の例では、例えば利用者ID「76387」に対して、設定される項目として、予約条件、キャンセル条件、診察後設定時間の3つがある。予約条件の設定値は、未予約の状態で体温38.5度以上であり、キャンセル条件の設定値は、予約済みの状態で体温36度以下であり、診察後設定時間の設定値は12時間である。尚、診察後設定時間を具体的に説明すると、診察済で、かつ、予約条件を満たしている場合に、この診察後設定時間内であれば、予約処理をしないための時間である。例えば、処方した薬品の効果がまだ出ていない期間となる。
すなわち、図5では、利用者ID「76387」の測定値が未予約の状態で38.5度以上であった場合、予約条件を満たすことになる。同様に、利用者ID「76387」の測定値が予約済みの状態で36度以下であった場合、キャンセル条件を満たすことになる。
尚、本実施形態では、予約条件とキャンセル条件とのそれぞれについて設定値(閾値)を設けたが、設定値の設け方はこれに限定されない。
例えば、予約条件は38度以上とし、キャンセル条件を38度未満というように、予約を行うかキャンセルを行うか否かを判定する閾値を同一の値としても良い。
図6は、病院データベースの一例を示す図である。本実施形態の病院データベース240は、情報の項目として、病院名と、予約端末アドレスを有し、両者は対応付けられている。
項目「病院名」の値は、病院名を示す。項目「予約端末アドレス」の値は、病院内で予約の管理を行う予約端末500のアドレスを示す。
図7は、かかりつけ病院管理データベースの一例を示す図である。本実施形態のかかりつけ病院管理データベース250は、情報の項目として、利用者ID、利用者端末アドレス、かかりつけ病院名、かかりつけ病院診察ID、予約フラグ、診察フラグを有する。
かかりつけ病院管理データベース250では、項目「利用者ID」の値と、他の項目の値とが対応付けられている。以下の説明では、項目「利用者ID」の値と、項目「利用者ID」の値と対応付けられた他の項目の値とを、かかりつけ病院情報と呼ぶ。
項目「利用者端末アドレス」の値は、予約システム100の利用者が使用する携帯端末300のアドレスを示す。予約システム100の利用者は、例えば患者が未成年等である場合には、患者の保護者が利用者となっても良い。また、予約システム100の利用者と患者とが同一人物であっても良い。
項目「かかりつけ病院名」は、利用者のかかりつけの病院の名前を示す。かかりつけ病院とは、日頃から患者の体質や病歴、健康状態を把握し、診療行為のほか健康管理上のアドバイス等を行う病院のことである。かかりつけの病院は、単純に過去の何度か受信した病院であってもよく、利用者があらかじめ設定した病院であっても良い。
項目「予約フラグ」の値は、かかりつけ病院に対して予約が行われたか否かを示す。本実施形態では、項目「予約フラグ」の値が1である場合、かかりつけ病院に対して予約が行われたことを示す。項目「予約フラグ」の値が0である場合、かかりつけ病院に対して予約が行われていないことを示す。以下の説明では、項目「予約フラグ」の値が1の状態を予約済み状態と呼び、項目「予約フラグ」の値が0の状態を未予約状態と呼ぶ。
項目「診察フラグ」の値は、予約した病院で診察を受けたか否かを示す。本実施形態では、項目「診察フラグ」の値が1である場合、予約した病院で診察を受けたことを示す。項目「診察フラグ」の値が0である場合、予約した病院で診察を受けていないことを示す。
尚、「診察フラグ」は、例えば「1」に設定されてから24時間経過で「0」に変更されても良いし、あるいは、日が変わった段階で「0」に変更されてもよい。このように、所定期間の経過にて「0」に戻る。以下の説明では、項目「診察フラグ」の値が1の状態を診察済み状態と呼び、項目「診察フラグ」の値が0の状態を未診察状態と呼ぶ。
図8は、診察データベースの一例を示す図である。本実施形態の診察データベース260は、情報の項目として、利用者ID、予約先かかりつけ病院名、予約申請日時、診察予約日時、診察日時を有し、項目「利用者ID」の値と、他の項目の値とが対応付けられている。以下の説明では、項目「利用者ID」の値と、項目「利用者ID」の値と対応付けられた他の項目の値とを、診察予定情報と呼ぶ。
項目「予約先かかりつけ病院名」は、予約を行ったかかりつけ病院の名前を示す。項目「予約申請日時」の値は、予約の申請を行った日時を示す。項目「診察予約日時」の値は、診察の予約が確保できた日時を示す。項目「診察日時」の値は、診察を受けた日時を示す。
次に、図9を参照して、予約端末500の有する予約データベース510について説明する。図9は、予約データベースの一例を示す図である。
本実施形態の予約データベース510は、情報の項目として、予約ID、予約日時、患者ID、状態を有し、項目「予約ID」の値と、その他の項目の値とが対応付けられている。以下の説明では、項目「予約ID」の値と、項目「予約ID」の値と対応付けられた他の項目の値とを、予約情報と呼ぶ。
項目「予約ID」の値は、予約が行われた病院が、予約を受け付けた際に発行するものであり、予約を識別するための情報を示す。項目「患者ID」は、診察を受ける予定の患者を特定するための情報を示す。項目「状態」は、予約した患者が診察を受けたか否か、又はキャンセルを行ったか等の情報を示す。項目「状態」の値は、例えば診察中、診察済み、順番待ち、キャンセルのうちの何れかとなる。
次に、図10を参照し、本実施形態の予約システム100の有する各装置の機能構成について説明する。図10は、第一の実施形態の予約システムの有する各装置の機能構成を説明する図である。
初めに、本実施形態の予約サーバ200の機能構成について説明する。本実施形態の予約サーバ200は、予約処理部210Aを有する。本実施形態の予約処理部210Aは、予約サーバ200が演算処理装置26により予約プログラム210を実行することで実現される。
本実施形態の予約処理部210Aは、入力受付部271、測定値取得部272、条件判定部273、フラグ判定部274、情報取得部275、予約申請部276、キャンセル申請部277、フラグ制御部278、データベース更新部279、画面データ生成部280、出力部281を有する。
入力受付部271は、予約サーバ200に対する各種の情報の入力を受け付ける。測定値取得部272は、測定装置400から送信される測定情報を取得する。
条件判定部273は、測定情報に含まれる測定値が、予約の申請を行うと判定するための予約条件を満たすか否かを判定する。また、条件判定部273は、測定値が、キャンセルの申請を行うと判定するためのキャンセル条件を満たすか否かを判定する。
フラグ判定部274は、かかりつけ病院管理データベース250の項目「予約フラグ」の値や項目「診察フラグ」の値を参照し、各フラグの値に基づき、予約や診察の状態を判定する。
情報取得部275は、予約処理部210Aの処理に必要な情報を取得する。予約申請部276は、携帯端末300において予約依頼が行われた病院に対して予約申請の処理を行う。具体的には予約申請部276は、予約端末500に対し、少なくとも病院を受診する患者を特定する情報を含む予約依頼情報を送信する。
キャンセル申請部277は、携帯端末300においてキャンセル依頼が行われた病院に対してキャンセル申請の処理を行う。具体的にはキャンセル申請部277は、予約端末500に対し、少なくとも診察の予約をした患者を特定する情報を含むキャンセル依頼情報を送信する。
フラグ制御部278は、予約申請やキャンセル申請等に応じて予約フラグの値を制御する。また、フラグ制御部278は、診察データベース260を参照した結果に応じて、診察フラグの値を制御する。
データベース更新部279は、予約サーバ200の有する各データベースの更新を行う。また、本実施形態のデータベース更新部279は、予約を行った病院の予約端末500に対し、予約データベース510の更新要求を行う。
画面データ生成部280は、携帯端末300に表示させる画面の画面データを生成する。出力部281は、生成した画面データを携帯端末300へ送信(出力)する。
次に、本実施形態の携帯端末300の機能について説明する。本実施形態の携帯端末300は、予約依頼処理部310Aを有する。予約依頼処理部310Aは、演算処理装置により予約依頼プログラム310を実行することにより実現される。
本実施形態の予約依頼処理部310Aは、入力受付部311、要求送信部312、画面データ受信部313、表示制御部314を有する。
入力受付部311は、携帯端末300の表示操作装置等からの入力を受け付ける。また、入力受付部311は、携帯端末300が受信した情報の入力を受け付ける。要求送信部312は、携帯端末300において指示された各種の要求を予約サーバ200へ送信する。
画面データ受信部313は、予約サーバ200から送信される画面データを受信する。表示制御部314は、受信した画面データに基づく画面を携帯端末300の表示操作装置に表示させる。
尚、本実施形態の測定装置400は、例えば通信機能を有する体温計等である。本実施形態の測定装置400は、測定値取得部410と、測定値送信部420とを有する。測定値取得部410は、体温を測定する。測定値送信部420は、測定値取得部410による測定結果の測定値と、測定装置400に設定された利用者IDと測定日時とを、予約サーバ200に送信する。
次に、図11乃至図14を参照し、本実施形態の予約サーバ200の動作を説明する。図11は、第一の実施形態の予約サーバの動作を説明する第一の図である。図11では、予約サーバ200のメインの処理を説明する。
本実施形態の予約サーバ200は、入力受付部271により、測定装置400から測定情報を受信したか否かを判定する(ステップS1101)。ステップS1101において、受信していない場合、予約サーバ200は、後述するステップS1111へ進む。
ステップS1101において受信した場合、予約サーバ200は、データベース更新部279により、受信した測定情報を測定値データベース220へ格納する(ステップS1102)。
続いて予約サーバ200は、条件判定部273により、受信した測定情報に含まれる測定値が予約条件を満たすか否かを判定する(ステップS1103)。より具体的には、条件判定部273は、設定データベース230において、測定情報に含まれる利用者IDと対応する設定項目の予約条件の設定値を参照する。そして、条件判定部273は、測定値が予約条件として設定された範囲に含まれるか否かを判定する。
ステップS1103において予約条件を満たさない場合、予約サーバ200は後述するステップS1108へ進む。
ステップS1103において予約条件を満たす場合、予約サーバ200は、フラグ判定部274により、かかりつけ病院管理データベース250を参照し、受信した利用者IDと対応する予約フラグの値と診察フラグの値とがともに0か否かを判定する(ステップS1104)。
ステップS1104において、予約フラグの値が0の場合とは、かかりつけ病院での診察の予約がなされていないことを示す。また、診察フラグの値が0の場合とは、所定期間において診察されていないことを示す。予約フラグと診察フラグの値が0場合、予約サーバ200は、診察の予約を行い(ステップS1105)、ステップS1111の処理を行う。ステップS1105の処理の詳細は後述する。
ステップS1104において、予約フラグの値が0でない場合、予約サーバ200は、フラグ判定部274により、受信した利用者IDと対応する診察フラグの値が1で、且つ前回の診察から診察後設定時間が経過したか否かを判定する(ステップS1106)。
予約フラグの値が0でない場合とは、予約フラグの値が1であり、かかりつけ病院の診察の予約が行われた予約済みの状態であることを示す。診察フラグの値が1である場合とは、対応するかかりつけ病院で診察を受けた診察済みの状態であることを示す。また、本実施形態の診察後設定時間は、設定データベース230において、受信した利用者IDと対応する設定項目の診察後設定時間の設定値である。また、前回の診察の日時は、診察データベース260を参照して得ることができる。
すなわち、ステップS1106では、予約したかかりつけ病院を受診した後に診察後設定時間が経過したか否かを判定している。
ステップS1106において、診察フラグが1でない場合、又は所定時間が経過していない場合、又は診察フラグが1でなく且つ診察後設定時間が経過していない場合、予約サーバ200は、ステップS1111の処理をおこなう。診察フラグが1でない場合とは、予約したかかりつけ病院をまだ受診しておらず、これから診察を受ける状態である。診察後設定時間が経過していない場合とは、予約したかかりつけ病院を受診し、診察済みの状態となってから間もないことを示す。
ステップS1106において、診察フラグの値が1で、且つ診察後設定時間が経過した場合、予約サーバ200は、再診の予約を行い(ステップS1107)、ステップS1111の処理をおこなう。ステップS1107の処理の詳細は後述する。
続いて、予約サーバ200は、条件判定部273により、受信した測定値がキャンセル条件を満たしているか否かを判定する(ステップS1108)。より具体的には、条件判定部273は、設定データベース230において、測定情報に含まれる利用者IDと対応する設定項目のキャンセル条件の設定値を参照する。そして、条件判定部273は、測定値がキャンセル条件として設定された範囲に含まれるか否かを判定する。
ステップS1108において、キャンセル条件を満たさない場合、予約サーバ200はステップS1111の処理をおこなう。
ステップS1108において、キャンセル条件を満たす場合、予約サーバ200は、フラグ判定部274により、かかりつけ病院管理データベース250において、受信した利用者IDと対応する予約フラグの値が1か否かを判定する(ステップS1109)。測定値がキャンセル条件を満たす場合とは、測定値が正常値の範囲となったときである。具体的には、測定値が体温である場合、体温が平熱の範囲となったときである。
ステップS1109において、予約フラグの値が1でない場合、すなわち予約フラグの値が0の場合、ステップS1111の処理をおこなう。
ステップS1109において、予約フラグの値が1である場合、予約サーバ200は、予約のキャンセルを行う(ステップS1110)。すなわちステップS1110では、例えば体温が平熱であるにも関わらず、診察の予約が行われているか否かを判定している。ステップS1110の処理の詳細は後述する。
続いて予約サーバ200は、入力受付部271により、病院の予約端末500から、診察完了通知を受信したか否かを判定する(ステップS1111)。ステップS1111において、診察完了通知を受信しない場合、予約サーバ200は、ステップ1101の処理に戻る。
ステップS1111において、診察完了通知を受信した場合、予約サーバ200は、データベース更新部279により、診察データベース260に、ステップS1101で受信した測定情報に含まれる利用者IDと、診察日時と、受診した病院の病院名とを格納する(ステップS1112)。続いて予約サーバ200は、フラグ制御部278により、かかりつけ病院管理データベース250において利用者IDと対応する予約フラグの値を1から0とし、診察フラグの値を0から1とし(ステップS1113)、処理を終了する。
図12は、第一の実施形態の予約サーバの動作を説明する第二の図である。図12は、図11のステップS1105の予約サブルーチンの処理を説明するフローチャートである。
本実施形態の予約サーバ200は、ステップS1104において予約フラグの値が0の場合、情報取得部275により、かかりつけ病院管理データベース250を参照し、利用者IDと対応するかかりつけ病院の病院名を取得する(ステップS1201)。
続いて予約サーバ200は、画面データ生成部280により、かかりつけ病院名を含む予約画面の画面データを生成する。そして、予約サーバ200は、出力部281により、かかりつけ病院管理データベース250において利用者IDと対応付けられた携帯端末300のアドレスへ、生成した画面データを送信する(ステップS1202)。
続いて予約サーバ200は、入力受付部271により、携帯端末300から病院名とその病院に対する予約要求を受信したか否かを判定する(ステップS1203)。ステップS1203において予約要求を受信しない場合、予約サーバ200は、入力受付部271により、予約をしない旨の通知を受信したか否かを判定する(ステップS1204)。
ステップS1204において、通知を受信した場合、予約サーバ200は処理を終了する。ステップS1204において、通知を受信しなかった場合、予約サーバ200はステップS1203へ戻る。
ステップS1203において予約要求を受信した場合、予約サーバ200は、情報取得部275により、病院データベース240を参照し、予約要求と共に受信した病院名と対応する予約端末アドレスを取得する(ステップS1205)。
続いて予約サーバ200は、予約申請部276により、取得した予約端末500のアドレスに予約申請を行う(ステップS1206)。尚、予約申請部276は、予約要求と共に、携帯端末300の利用者により入力された患者IDと、希望時間帯とを予約端末500へ送信しても良い。患者IDとは、例えば予約を行う病院の診察券番号であっても良い。また。また、予約申請部276は、患者IDのかわりに、患者氏名等を予約端末500に送信しても良い。
続いて予約サーバ200は、入力受付部271により、予約端末500から予約完了通知を受信したか否かを判定する(ステップS1207)。ステップS1207において、予約完了通知を受信していない場合、予約サーバ200は、受信するまで待機する。ステップS1207において予約完了通知を受信した場合、予約サーバ200は、フラグ制御部278により、かかりつけ病院管理データベース250において、利用者IDとかかりつけ病院名とに対応する予約フラグの値を0から1とする(ステップS1208)。
続いて予約サーバ200は、データベース更新部279により、診察データベース260に、利用者IDと、現在日時を予約申請日時とし、診察予約が確保された日時を診察予約日時とし、予約先かかりつけ病院名と対応づけて格納し(ステップS1209)、処理を終了する。
図13は、第一の実施形態の予約サーバの動作を説明する第三の図である。図13は、図11のステップS1107の再予約サブルーチンの処理を説明するフローチャートである。
本実施形態の予約サーバ200の情報取得部275は、診察データベース260を参照し、図11のステップS1101で受信した測定情報に含まれる利用者IDと対応し、且つ診察日時が格納されている予約先かかりつけ病院名を抽出する。そして、情報取得部275は、抽出した予約先かかりつけ病院名の中から、所定日数以内に診察を受けた病院名を取得する(ステップS1301)。本実施形態では、所定日数を例えば30日(1ヶ月)とした。すなわち、ステップS1301で取得される病院名は、30日以内に受診したことがあるかかりつけ病院の病院名である。
続いて予約サーバ200は、画面データ生成部280により、ステップS1301で取得した病院名を含む再予約画面の画面データを生成する。そして予約サーバ200は、出力部281により、かかりつけ病院管理データベース250において利用者IDと対応する携帯端末300のアドレスへ画面データを送信する(ステップS1302)。
すなわち、ステップS1302では、30日以内に受診したかかりつけ病院名を含む再予約画面の画面データを携帯端末300へ送信する。
続いて予約サーバ200は、入力受付部271により、携帯端末300から再予約要求を受信したか否かを判定する(ステップS1303)。ステップS1303において、再予約要求を受信しない場合、予約サーバ200は、後述するステップS1309へ進む。
ステップS1303において、再予約要求を受け付けた場合、予約サーバ200は、情報取得部275により、病院データベース240を参照し、再予約がなされた病院と対応する予約端末アドレスを取得する(ステップS1304)。
ステップS1304からステップS1308の処理は、図12のステップS1205からステップS1209までの処理と同様であるから、説明を省略する。
ステップS1303において再予約要求を受信しない場合、予約サーバ200は、入力受付部271により、他のかかりつけ病院の予約要求を受信したか否かを判定する(ステップS1309)。他のかかりつけ病院とは、所定日数以内に受診していないかかりつけ病院である。
ステップS1309において予約要求を受け付けない場合、予約サーバ200は、後述するステップS1313へ進む。
ステップS1309において予約要求を受け付けた場合、予約サーバ200は、情報取得部275により、かかりつけ病院管理データベース250を参照し、予約要求を受けたかかりつけ病院名を取得する(ステップS1310)。続いて予約サーバ200は、画面データ生成部280は、予約要求を受けたかかりつけ病院名を含む予約画面の画面データを生成する。そして、予約サーバ200は、出力部281により、利用者IDと対応する携帯端末300のアドレスへ生成した画面データを送信する(ステップS1311)。
続いて予約サーバ200は、入力受付部271により、病院名と、予約要求とを受信したか否かを判定する(ステップS1312)。
ステップS1312において予約要求を受信しない場合、予約サーバ200は、予約要求を受信するまで待機する。ステップS1312において予約要求を受信した場合、予約サーバ200は、ステップS1304へ進む。
ステップS1309において、他のかかりつけ病院の予約要求を受信しない場合、予約サーバ200は、入力受付部271により、予約をしない旨の通知を受信したか否かを判定する(ステップS1313)。
ステップS1313において通知を受信しない場合、予約サーバ200は、ステップS1303へ戻る。ステップS1313において通知を受信した場合、予約サーバ200は処理を終了する。
図14は、第一の実施形態の予約サーバの動作を説明する第四の図である。図14は、図11のステップS1110のキャンセルサブルーチンの処理を説明するフローチャートである。
本実施形態の予約サーバ200は、情報取得部275により、診察データベース260から、かかりつけ病院管理データベース250で予約フラグの値が1となっているかかりつけ病院の病院名と、予約日時を取得する(ステップS1401)。
続いて予約サーバ200は、画面データ生成部280により、ステップS1401で取得した病院名と、予約のキャンセルを推奨するメッセージとを含むキャンセル画面の画面データを生成する。そして、予約サーバ200は、出力部281により、利用者IDと対応する携帯端末300のアドレスへ、生成した画面データを送信する(ステップS1402)。
続いて予約サーバ200は、入力受付部271により、携帯端末300からキャンセル要求を受信したか否かを判定する(ステップS1403)。ステップS1403においてキャンセル要求を受信しない場合、予約サーバ200は、後述するステップS1409へ進む。
ステップS1403においてキャンセル要求を受信すると、予約サーバ200は、情報取得部275により、病院データベース240を参照し、キャンセル対象の病院の予約端末アドレスを取得する(ステップS1404)。続いて予約サーバ200は、キャンセル申請部277により、取得した予約端末500のアドレスに、キャンセル申請を送信する(ステップS1405)。
続いて予約サーバ200は、入力受付部271により、予約端末500からキャンセル完了通知を受信したか否かを判定する(ステップS1406)。ステップS1406においてキャンセル完了通知を受信しない場合、予約サーバ200は、キャンセル完了通知を受信するまで待機する。
ステップS1406においてキャンセル完了通知を受信した場合、予約サーバ200は、フラグ制御部278により、かかりつけ病院管理データベース250の利用者IDとかかりつけ病院名とが対応する予約フラグの値を1から0にする(ステップS1407)。
続いて予約サーバ200は、データベース更新部279により、診察データベース260から対応する診察予定情報を削除し(ステップS1408)、処理を終了する。
ステップS1403においてキャンセル要求を受信しない場合、予約サーバ200は、入力受付部271により、キャンセルをしない旨の通知を受信したか否かを判定する(ステップS1409)。
ステップS1409において通知を受信しない場合、予約サーバ200は、ステップS1403へ戻る。ステップS1409において通知を受信した場合、処理を終了する。
以下に、図15乃至18を参照し、本実施形態の予約システム100の動作を具体的に説明する。
以下の説明では、例えば利用者ID「76387」である利用者が発熱し、測定装置400で体温を計測したものとする。
測定装置400は、体温の測定が終了すると、測定日時と、利用者ID「76387」と、測定値とを予約サーバ200へ送信する。このとき、測定値は40.1度である(図4参照)。
予約サーバ200は、この測定値が予約条件である38度以上を満たすと判定し(図5参照)、携帯端末300に表示させる予約画面の画面データを生成し、携帯端末300へ送信する。以下に、図15を参照して予約画面について説明する。
図15は、第一の実施形態の携帯端末に表示される画面の例を示す第一の図である。
図15に示す予約画面151は、図12のステップS1202において予約サーバ200から送信される画面データを携帯端末300に表示させた画面である。
本実施形態の携帯端末300は、画面データ受信部313により、予約サーバ200から予約画面151の画面データを受信し、表示制御部314により予約画面151を表示させる。
予約画面151には、携帯端末300の利用者に対して診察の予約を促すメッセージ152と、利用者のかかりつけ病院の一覧及び選択欄153と、予約を行うか否かを利用者に選択させるボタン154、155と、が表示される。
図15の予約画面151は、利用者ID「76387」の利用者の携帯端末300に表示された画面を示している。利用者ID「76387」と対応するかかりつけ病院名は、「AA病院」と「BBクリニック」である(図7参照)。したがって、予約画面151には、利用者が登録したかかりつけ病院の一覧として、この2つの病院名が表示される。さらに、予約画面151では、2の病院名のそれぞれに対応した選択欄が設けられている。
本実施形態の携帯端末300では、予約画面151において、かかりつけ病院の一覧及び選択欄153において、かかりつけ病院が選択され、ボタン154(押下)が操作されると、入力受付部311が選択を受け付ける。そして、携帯端末300は、要求送信部312により、選択されたかかりつけ病院の予約要求を予約サーバ200へ送信する。
予約サーバ200は、この予約要求を受け付けると、AA病院の予約端末500のアドレスへ、利用者ID「76387」の利用者の診察の予約申請を行う。そして予約サーバ200は、AA病院の予約端末500に対し、予約データベース510の更新を要求する。
また、予約画面151においてボタン155が操作されると、携帯端末300は、要求送信部312により予約を行わない旨の通知を予約サーバ200へ送信する。
次に、利用者ID「76387」の利用者が、AA病院で再度診察を受ける場合の再予約について説明する。再予約は、例えば過去30日以内に受診した病院を再度受診する際に行われる。
図16は、第一の実施形態の携帯端末に表示される画面の例を示す第二の図である。
図16に示す再予約画面161は、図13のステップS1302において予約サーバ200から送信される画面データを携帯端末300に表示させた画面である。
本実施形態の携帯端末300は、画面データ受信部313により、予約サーバ200から再予約画面161の画面データを受信し、表示制御部314により再予約画面161を表示させる。
再予約画面161には、携帯端末300の利用者に対して診察の再予約を促すメッセージ162と、過去30日以内に受診したかかりつけ病院に対する再予約依頼を行うボタン163と、前回の診察日164と、が表示される。また、再予約画面161には、他のかかりつけ病院に対しての予約依頼を行うか否かを選択するためのボタン165、166が表示される。
利用者ID「76387」の利用者は、2014/7/1にかかりつけ病院である「AA病院」を受診している(図8参照)。したがって、予約サーバ200は、上述の情報を含むAA病院の再予約画面161の画面データを生成し、携帯端末300へ送信する。
携帯端末300は、再予約画面161において、ボタン163が操作されると、要求送信部312により、AA病院の予約依頼を予約サーバ200へ送信する。
また、携帯端末300は、再予約画面161においてボタン165が操作されると、要求送信部312により、他のかかりつけ病院の予約要求を予約サーバ200へ送信する。
予約サーバ200は、この要求を受けて、かかりつけ病院管理データベース250において利用者ID「76387」と対応するかかりつけ病院のうち、「AA病院」以外のかかりつけ病院の名前を含む予約画面の画面データを生成し、携帯端末300へ送信する。
携帯端末300は、画面データ受信部313により画面データを受信し、表示制御部314により画面データに応じた予約画面を表示させる。
図17は、第一の実施形態の携帯端末に表示される画面の例を示す第三の図である。
図17に示す予約画面171は、再予約画面161においてボタン165が操作された際に携帯端末300に表示される画面であり、図13のステップS1311において表示される画面である。
図17に示す予約画面171のメッセージ152、ボタン154、155は、図15に示す予約画面151が含むものと同様であるから説明を省略する。
予約画面171では、かかりつけ病院の一覧及び選択欄172において、受診済みのAA病院以外のかかりつけ病院の一覧として、BBクリニックが表示される。
次に、利用者ID「76387」の利用者が、予約画面151において予約を行った後に、再度測定装置400で体温を検出した際に、利用者の体温が平熱の36度まで下がっていた場合を説明する。
測定装置400は、AA病院の予約を行った後に測定された、測定値は、予約条件を満たさず、且つキャンセル条件を満たしている。したがって、予約サーバ200は、利用者に予約のキャンセルを促すキャンセル画面の画面データを生成して携帯端末300へ送信する。
携帯端末300は、画面データ受信部313により画面データを受信し、表示制御部314によりキャンセル画面を表示させる。
図18は、第一の実施形態の携帯端末に表示される画面の例を示す第四の図である。
図18に示すキャンセル画面181は、図14のステップS1402において予約サーバ200から送信される画面データを携帯端末300に表示させた画面である。
キャンセル画面181には、携帯端末300の利用者に対して診察の予約のキャンセルを促すメッセージ182と、予約済みの病院に対するキャンセル依頼を行うボタン183と、キャンセルをしない旨を通知するボタン184と、が表示される。
キャンセル画面181において、ボタン183が操作されると、携帯端末300は、要求送信部312により予約サーバ200へAA病院の予約のキャンセル要求を送信する。予約サーバ200は、キャンセル要求を受けて、AA病院の予約端末500の予約データベース510から、利用者ID「76387」と対応する予約情報を削除する。
また、キャンセル画面181において、ボタン184が操作されると、携帯端末300は、要求送信部312により、キャンセルを行わない旨の通知を予約サーバ200へ送信する。
以上のように、本実施形態によれば、測定装置400で体温を測定するだけで診察の予約や予約のキャンセルに関する問い合わせの画面が携帯端末300に表示されるため、予約に係る手間を軽減させることができる。
尚、本実施形態の予約画面151、161、171では、かかりつけ病院名とその選択欄が表示されるものとしたが、これに限定されない。例えば予約画面には、利用者が受診したい時間帯を選択させる一覧が表示されても良い。
また、本実施形態の予約サーバ200では、設定データベース230の設定項目と設定値が予め設定されているものとしたが、これに限定されない。本実施形態では、例えば測定装置400に、測定対象となる利用者の利用者ID毎に、設定項目と対応する設定値が変更されても良い。具体的には、例えば利用者ID「1111」の利用者が測定対象であった場合には、予約条件の体温の範囲を37.5度以上等としても良い。
(第二の実施形態)
以下に図面を参照して第二の実施形態について説明する。第二の実施形態は、携帯端末が測定装置を有する点のみ、第一の実施形態と相違する。よって、以下の第二の実施形態の説明では、第一の実施形態との相違点についてのみ説明し、第一の実施形態と同様の機能構成を有するものには第一の実施形態の説明で用いた符号を付与し、その説明を省略する。
図19は、第二の実施形態の予約システムの有する各装置の機能構成を説明する図である。
本実施形態の予約システム100Aは、携帯端末300Aと、予約サーバ200とを有する。
本実施形態の携帯端末300Aは、予約依頼処理部310Aと、測定処理部400Aとを有する。本実施形態の携帯端末300Aは、例えば体温や血圧等を測定するためのセンサ等の測定装置400を有しており、測定処理部400Aは、測定装置400を制御する。
測定処理部400Aは、測定値取得部410Aと、測定値送信部420とを有する。測定値取得部410Aは、測定装置400による測定値を取得する。
以上のように、本実施形態では、携帯端末300Aがバイタルサインを測定する測定装置400を有するため、携帯端末300Aと別に測定装置400を有していなくても、第一の実施形態と同様の効果を得ることができる。さらに、本実施形態では、携帯端末300Aが測定装置400を備えているため、測定装置400を有していなくても、バイタルサインの測定が可能となる。
(第三の実施形態)
以下に図面を参照して第三の実施形態について説明する。第三の実施形態は、携帯端末が測定装置と予約サーバの機能とを有する点が、第一の実施形態と相違する。よって、以下の第三の実施形態の説明では、第一の実施形態との相違点についてのみ説明し、第一の実施形態と同様の機能構成を有するものには第一の実施形態の説明で用いた符号を付与し、その説明を省略する。
図20は、第三の実施形態の携帯端末の機能構成を説明する図である。
本実施形態の携帯端末300Bは、予約依頼プログラム310と、予約プログラム210の両方がインストールされている。したがって、本実施形態の携帯端末300Bは、予約依頼処理部310Aと、測定処理部400Aと、予約処理部210Aとを有する。
本実施形態の携帯端末300Bは、予約処理部210Aを有することで、第一の実施形態の予約サーバ200の役割も果たす。したがって、本実施形態では、携帯端末300Bが予約端末500に対して予約申請やキャンセル申請を行う。
尚、本実施形態の携帯端末300Bは、第一の実施形態の予約サーバ200の有する各データベースも有するものとした。
以上のように、本実施形態では、予約サーバ200を設けずに、携帯端末300Bのみで病院の予約端末500に対して予約申請やキャンセル申請を行うことができ、予約に係る手間を軽減できる。
尚、本実施形態の携帯端末300Bは、例えば予約サーバ200との通信により、予約プログラム210と、予約サーバ200の有する各データベースとを取得しても良い。
(第四の実施形態)
以下に図面を参照して第四の実施形態について説明する。第四の実施形態は、携帯端末が予約サーバの機能を有する点が第一の実施形態と相違する。よって、以下の第四の実施形態の説明では、第一の実施形態との相違点についてのみ説明し、第一の実施形態と同様の機能構成を有するものには第一の実施形態の説明で用いた符号を付与し、その説明を省略する。
図21は、第四の実施形態の携帯端末の機能構成を説明する図である。本実施形態の予約システム100Bは、測定装置400と、携帯端末300Cとを有する。
本実施形態の携帯端末300Cは、測定装置400から受信した測定情報に応じて、予約依頼処理部310Aと予約処理部210Aが各処理を実行する。
したがって、本実施形態も、第三の実施形態と同様に、予約サーバ200を設けずに、携帯端末300Bのみで病院の予約端末500に対して予約申請やキャンセル申請を行うことができ、予約に係る手間を軽減できる。
開示の技術では、以下に記載する付記のような形態が考えられる。
(付記1)
所定のバイタルサインを測定する測定部と、
前記所定のバイタルサインの測定結果が第一の所定の範囲外を示す場合に病院の診察予約画面を表示部に表示させ、病院の診察予約画面を表示した後に受信した前記所定のバイタルサインの測定結果が第二の所定の範囲内を示す測定結果を取得した場合に、前記病院の診察予約のキャンセル画面を前記表示部に表示させる制御を行う制御部と、
前記所定のバイタルサインの測定結果と、前記診察予約画面に応じた診察予約情報又は前記病院の診察予約のキャンセル画面に応じた診察キャンセル情報とを送信する送信部と、を有する通信端末。
(付記2)
前記測定部は、体温を測定する体温計である付記1記載の通信端末。
(付記3)
前記所定のバイタルサインの測定結果が所定の閾値以上である場合を前記第一の所定の範囲とし、前記所定の閾値未満である場合を前記第二の所定の範囲とすることを特徴とする付記1又は2記載の通信端末。
(付記4)
前記制御部は、
前記病院の診察予約画面を前記表示部に表示させた後に、前記病院の診察予約時間を取得して記憶しておき、
前記病院の診察予約画面を前記表示部に表示させた後であり且つ前記病院の診察予約時間前に取得した前記所定のバイタルサインの測定結果が前記第二の所定の範囲内を示す場合に、前記病院の診察予約のキャンセル画面を前記表示部に表示させることを特徴とする付記1乃至3の何れか一項に記載の通信端末。
(付記5)
コンピュータによる予約支援方法であって、該コンピュータが、
所定のバイタルサインを測定する測定部から前記所定のバイタルサインを取得し、
前記所定のバイタルサインの測定結果が第一の所定の範囲外を示す場合に病院の診察予約画面を表示部に表示させ、病院の診察予約画面を表示した後に受信した前記所定のバイタルサインの測定結果が第二の所定の範囲内を示す測定結果を取得した場合に、前記病院の診察予約のキャンセル画面を前記表示部に表示させ、
前記所定のバイタルサインの測定結果と、前記診察予約画面に応じた診察予約情報又は前記病院の診察予約のキャンセル画面に応じた診察キャンセル情報とを送信する、
予約支援方法。
(付記6)
所定のバイタルサインを測定する測定部から前記所定のバイタルサインを取得し、
前記所定のバイタルサインの測定結果が第一の所定の範囲外を示す場合に病院の診察予約画面を表示部に表示させ、病院の診察予約画面を表示した後に受信した前記所定のバイタルサインの測定結果が第二の所定の範囲内を示す測定結果を取得した場合に、前記病院の診察予約のキャンセル画面を前記表示部に表示させ、
前記所定のバイタルサインの測定結果と、前記診察予約画面に応じた診察予約情報又は前記病院の診察予約のキャンセル画面に応じた診察キャンセル情報とを送信する、
処理をコンピュータに実行させる予約支援プログラム。
(付記7)
所定のバイタルサインを測定する測定部と、
前記所定のバイタルサインの測定結果を送信する送信部と、
を有する測定装置と、
前記測定装置から送信された前記所定のバイタルサインの測定結果を受信する受信部と、
受信した前記所定のバイタルサインの測定結果が第一の所定の範囲外を示す場合に病院の診察予約画面を表示部に表示させ、病院の診察予約画面を表示した後に受信した前記所定のバイタルサインの測定結果が第二の所定の範囲内を示す測定結果を取得した場合に、前記病院の診察予約のキャンセル画面を前記表示部に表示させる制御を行う制御部と、
前記所定のバイタルサインの測定結果と、前記診察予約画面に応じた診察予約情報又は前記病院の診察予約のキャンセル画面に応じた診察キャンセル情報とを送信する送信部と、
を有する通信端末と、
を備えたバイタル測定システム。
(付記8)
所定のバイタルサインの測定結果を受信する受信部と、
前記所定のバイタルサインの測定結果が第一の所定の範囲外である場合に病院の診察予約画面の画面データを生成して出力し、前記診察予約画面の画面データを出力した後に受信した前記所定のバイタルサインの測定結果が、第二の所定の範囲内である場合に、前記病院の診察予約のキャンセル画面の画面データを生成して出力する画面データ生成部と、
前記所定のバイタルサインの測定結果と、前記診察予約画面において入力された診察予約情報又は前記キャンセル画面において入力されたキャンセル依頼情報を出力する出力部と、を有する予約サーバ。
本発明は、具体的に開示された実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。