JP2015064832A - 情報処理装置、情報処理装置の制御方法及びプログラム - Google Patents

Abstract

【課題】予約を受け付けた順に利用者にサービスの提供を行うサービス提供者が利用者から予約のキャンセル要求を受けた場合に、他の利用者やサービス提供者の混乱を起こしにくいようにする。
【解決手段】予約を受け付けた順に付与した受付情報の順序で利用者にサービスの提供を行うサービス提供者により用いられる情報処理装置であって、サービスの提供を現在受けている利用者の受付情報と予約を既にキャンセルした利用者の受付情報とを含む、サービスの提供状況を示す情報を記憶するサービス管理テーブルと、通信可能に接続された端末から受付情報を指定した予約のキャンセル要求を受信するキャンセル要求受信部と、キャンセル要求により指定される受付情報とサービスの提供状況を示す情報とに基づいて予約のキャンセルの可否を判定する可否判定部と、キャンセルの可否の判定結果を端末に送信する判定結果送信部と、を備える。
【選択図】図１

Description

本発明は、情報処理装置、情報処理装置の制御方法及びプログラムに関する。

近年、病院等での待ち時間の短縮化を図るための技術が開発されている。
例えば、患者の携帯電話機やパーソナルコンピュータ等から、事前にインターネットを介して診察の予約やキャンセルを受け付け、患者の診察の順番が近付くとその患者の携帯電話機に電子メール等で通知を行うことが可能な予約システムが開発されている（例えば特許文献１参照）。

このような技術によれば、患者は自分の診察の順番が近付いてから病院に出向けば良いので、待ち時間を大幅に短縮できると共に、病院内が診察待ちの患者で溢れるという事態も改善することができる。

特開２００２−３２９００２号公報

しかしながら、患者が予約をキャンセルすると、その患者の後に予約した患者の順番が急に繰り上がるため、例えば短時間に多数のキャンセルが発生したような場合には、診察の順番が回ってくるまで時間的なゆとりがあると思っていた患者が不意に呼び出される、ということも起こりうる。

このようなことが起こると、予約システムを利用する患者も不便であるし、病院も混乱しかねない。

そのため、他の患者や病院に混乱を生じさせにくいように予約のキャンセルを行えるようにする技術が求められている。

本発明は上記課題を鑑みてなされたものであり、予約を受け付けた順に利用者にサービスの提供を行うサービス提供者が利用者から予約のキャンセル要求を受けた場合に、他の利用者やサービス提供者の混乱を起こしにくいようにすることを可能にすることを一つの目的とする。

前記課題を解決するための情報処理装置は、予約を受け付けた順に付与した受付情報の順序で利用者にサービスの提供を行うサービス提供者により用いられる情報処理装置であって、前記サービスの提供を現在受けている利用者の受付情報と、前記予約を既にキャンセルした利用者の受付情報と、を含む、前記サービスの提供状況を示す情報を記憶するサービス管理テーブルと、通信可能に接続された端末から、受付情報を指定した予約のキャンセル要求を受信するキャンセル要求受信部と、前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とに基づいて、前記予約のキャンセルの可否を判定する可否判定部と、前記キャンセルの可否の判定結果を前記端末に送信する判定結果送信部と、を備える。

本発明によれば、予約を受け付けた順に利用者にサービスの提供を行うサービス提供者が利用者から予約のキャンセル要求を受けた場合に、他の利用者やサービス提供者の混乱を起こしにくいようにすることができる。

本実施の形態の全体構成を示すブロック図である。 本実施の形態の患者端末、診療サーバ、院内端末、予約受付サーバ、院内予約サーバのハードウェア構成を示すブロック図である。 本実施の形態の予約受付サーバの記憶装置を示すブロック図である。 本実施の形態の院内予約サーバの記憶装置を示すブロック図である。 本実施の形態の患者データベースを示す図である。 本実施の形態の院内予約データベースを示す図である。 本実施の形態の順番予約データベースを示す図である。 本実施の形態の時間予約データベースを示す図である。 本実施の形態の予約キャンセルポリシーテーブルを示す図である。 本実施の形態の予約キャンセルポリシー設定画面を示す図である。 本実施の形態の待ちリストを示す図である。 本実施の形態の予約受付状況を示す画面を示す図である。 本実施の形態の処理の流れを示すフローチャートである。 本実施の形態の処理の流れを示すフローチャートである。 本実施の形態の患者端末に表示される画面を示す図である。 本実施の形態の患者端末に表示される画面を示す図である。 本実施の形態の患者端末に表示される画面を示す図である。 本実施の形態の患者端末に表示される画面を示す図である。 本実施の形態の患者端末に表示される画面を示す図である。

本明細書および添付図面の記載により、少なくとも以下の事項が明らかとなる。

本発明の実施形態に係る予約システム１０００の全体構成を図１に示す。

本実施形態に係る予約システム１０００は、予約受付サーバ２００と、院内予約サーバ１００と、患者データベース７００と、院内予約データベース７１０と、が通信可能に接続されて構成される。

診察の予約を行おうとする患者は、患者端末４００を用いて予約受付サーバ２００にアクセスして予約の申し込みを行うことで、診察の予約を行う。

予約受付サーバ２００は、患者端末４００から送信される予約のリクエストを受け付けて、院内予約サーバ１００に対して予約のリクエストを送信する。

院内予約サーバ１００は、予約受付サーバ２００から送信されてきた予約のリクエストに応じて、患者データベース７００や院内予約データベース７１０等を参照しながら、上記患者に対する診察の予約を行う。

なお詳細は後述するが、本実施形態において、患者は、予約の受け付け順に患者への診察が行われる「順番予約」により診察の予約を行うこともできるし、患者が指定した時間に患者への診察が行われる「時間予約」により診察の予約を行うこともできる。

院内予約サーバ１００と、患者データベース７００と、院内予約データベース７１０と、は、ＬＡＮ（Local Area Network）等により構築されている院内ネットワーク６１０を介して通信可能に接続されている。

また予約受付サーバ２００は、インターネット６００及び院内ネットワーク６１０を介して、院内予約サーバ１００に通信可能に接続されている。

また院内ネットワーク６１０には、院内予約サーバ１００、患者データベース７００、及び院内予約データベース７１０の他に、院内端末５００及び診療サーバ３００が接続されている。またインターネット６００には、患者端末４００が接続されている。

これらのうち、院内予約サーバ１００と、診療サーバ３００と、患者データベース７００と、院内予約データベース７１０と、院内端末５００とは、病院内に設置される携帯電話機やコンピュータ、データベース等の情報処理装置である。また患者端末４００は、患者が有する携帯電話機やコンピュータ等の情報処理装置である。また予約受付サーバ２００は、例えばデータセンタに設置されるコンピュータ等の情報処理装置である。なお予約受付サーバ２００が病院内に設置される形態でも良い。

院内端末５００は、例えば医師や看護師、医療技術者、あるいは病院の受付担当者等の病院内の職員により操作される様々な情報処理装置を総称したものである。診療サーバ３００は、例えば電子カルテ等の機能を医師や看護師等に提供する情報処理装置である。

例えば医師は、院内端末５００を用いて診療サーバ３００にアクセスし、この診療サーバ３００により提供される種々の機能を利用しながら、患者を診療した際に診立てた患者の傷病名や患者の主訴、医師の所見、経過、患者に実施した処置、処方、検査結果等の様々な診療データを診療サーバ３００に記録していく。

また医師が患者を診察した際に次回の診察の予約を行う場合には、医師は院内端末５００から予約受付サーバ２００にアクセスして、予約受付サーバ２００に予約のリクエストを送信するようにする。

なお本実施形態では、予約受付サーバ２００と院内予約サーバ１００とが別の情報処理装置により構成される場合について説明するが、予約受付サーバ２００が有する機能を院内予約サーバ１００が備えるようにし、患者端末４００から送信される予約のリクエストを院内予約サーバ１００が受信するようにすることも可能である。またこの場合、院内予約サーバ１００は、病院内に設置される形態であっても良いし、病院外のデータセンタ等に設置される形態であっても良い。

あるいは、院内予約サーバ１００が、患者データベース７００及び院内予約データベース７１０の少なくとも一方の機能を内蔵する形態も可能である。さらには予約受付サーバ２００が、患者データベース７００及び院内予約データベース７１０の少なくとも一方の機能を内蔵する形態も可能である。

次に、本実施形態に係る院内予約サーバ１００、予約受付サーバ２００、診療サーバ３００、患者端末４００、及び院内端末５００のハードウェア構成の一例をまとめて図２に示す。

院内予約サーバ１００は、ＣＰＵ（Central Processing Unit）１１０、メモリ１２０、通信装置１３０、記憶装置１４０、入力装置１５０、出力装置１６０及び記録媒体読取装置１７０を有して構成される情報処理装置である。

また予約受付サーバ２００は、ＣＰＵ２１０、メモリ２２０、通信装置２３０、記憶装置２４０、入力装置２５０、出力装置２６０及び記録媒体読取装置２７０を有して構成される情報処理装置である。

診療サーバ３００は、ＣＰＵ３１０、メモリ３２０、通信装置３３０、記憶装置３４０、入力装置３５０、出力装置３６０及び記録媒体読取装置３７０を有して構成される情報処理装置である。

患者端末４００は、ＣＰＵ４１０、メモリ４２０、通信装置４３０、記憶装置４４０、入力装置４５０、出力装置４６０及び記録媒体読取装置４７０を有して構成される情報処理装置である。

そして院内端末５００は、ＣＰＵ５１０、メモリ５２０、通信装置５３０、記憶装置５４０、入力装置５５０、出力装置５６０及び記録媒体読取装置５７０を有して構成される情報処理装置である。

なお、予約受付サーバ２００、診療サーバ３００、患者端末４００、及び院内端末５００の各ハードウェア構成要素は、院内予約サーバ１００の各ハードウェア構成要素と同様であるため、以下の説明では、院内予約サーバ１００のハードウェア構成要素について説明し、予約受付サーバ２００、診療サーバ３００、患者端末４００、及び院内端末５００のハードウェア構成要素についての重複する説明は適宜省略する。

ＣＰＵ１１０は院内予約サーバ１００の全体の制御を司るもので、記憶装置１４０に記憶される本実施形態に係る各種の動作を行うためのコードから構成される院内予約サーバ制御プログラム９１０、予約キャンセルポリシーテーブル７２０及び待ちリスト７３０をメモリ１２０に読み出して実行することにより、院内予約サーバ１００としての各種機能を実現する。

例えば、詳細は後述するが、ＣＰＵ１１０により院内予約サーバ制御プログラム９１０が実行され、メモリ１２０や通信装置１３０、記憶装置１４０等のハードウェア機器と協働することにより、サービス管理テーブル、キャンセル要求受信部、可否判定部、判定結果送信部が実現される。

メモリ１２０は例えば半導体記憶装置により構成することができる。

記憶装置１４０は、例えばハードディスク装置や半導体記憶装置等により構成することができる。記憶装置１４０は、各種プログラムやデータ、テーブル等を記憶するための物理的な記憶領域を提供する装置である。記憶装置１４０は、院内予約サーバ１００に内蔵されている形態とすることもできるし、外付されている形態とすることもできる。記憶装置１４０に、本実施形態に係る院内予約サーバ制御プログラム９１０や予約キャンセルポリシーテーブル７２０、待ちリスト７３０が記憶されている様子を図４に示す。

なお、院内予約サーバ制御プログラム９１０や予約キャンセルポリシーテーブル７２０は、記録媒体読取装置１７０を用いて、記録媒体（各種の光ディスクや磁気ディスク、半導体メモリ等）８００から記憶装置１４０に読み出すことで、院内予約サーバ１００に格納されるようにすることもできるし、通信装置１３０を介して通信可能に接続される他のコンピュータから取得することで、院内予約サーバ１００に格納されるようにすることもできる。なお後者の場合には、院内予約サーバ１００は記憶装置１４０を備えない構成とすることも可能である。

院内予約サーバ制御プログラム９１０、予約キャンセルポリシーテーブル７２０及び待ちリスト７３０は、本実施形態に示す院内予約サーバ１００の各種機能や方法を実現するためのプログラム及びテーブルである。詳細は後述する。

また、予約受付サーバ２００の記憶装置２４０には、本実施形態に係る各種の動作を行うためのコードから構成される予約受付サーバ制御プログラム９００が記憶されている。その様子を図３に示す。予約受付サーバ２００のＣＰＵ２１０が予約受付サーバ制御プログラム９００をメモリ２２０に読み出して実行することにより、予約受付サーバ２００としての各種機能が実現される。

次に、本実施形態に係る患者データベース７００について説明する。患者データベース７００の一例を図５に示す。患者データベース７００は、病院に登録されている患者に関する各種情報を記録したデータベースである。

本実施形態に係る患者データベース７００は、「患者ＩＤ」欄、「患者氏名」欄、「健康保険証番号」欄、「住所」欄、「メールアドレス」欄、「電話番号」欄、「パスワード」欄を有している。

「患者ＩＤ」欄には、それぞれの患者を一意に特定するための情報が記録されている。

「患者氏名」欄には、各患者の氏名が記載されている。

「健康保険証番号」欄には、各患者が加入している健康保険組合から発行されている健康保険証の番号が記載されている。

「住所」欄には、各患者の住所が記載されている。

「メールアドレス」欄には、各患者が有する患者端末４００の電子メールのアドレスが記録されている。院内予約サーバ１００が「メールアドレス」欄に登録されているメールアドレスに電子メールを送信することで、患者に電子メールを送信することができる。

「電話番号」欄には、各患者が有する電話機の電話番号が記録されている。患者端末４００が携帯電話機である場合には患者端末４００の電話番号であっても良い。院内予約サーバ１００が「電話番号」欄に登録されている電話番号に電話を掛けることで、病院の職員が患者と通話を行うことができる。あるいは院内予約サーバ１００が患者端末４００に自動音声メッセージを送ることができる。

「パスワード」欄には、患者が患者端末４００を用いて病院の診察の予約や予約のキャンセルを行なおうとする場合に、院内予約サーバ２００が患者端末４００に入力を求めるパスワードが記録されている。詳しくは後述する。

次に、本実施形態に係る院内予約データベース７１０について説明する。院内予約データベース７１０は、患者からの診察の予約受付状況を記録したデータベースである。院内予約データベース７１０の一例を図６に示す。

院内予約データベース７１０は、順番予約データベース７１１と、時間予約データベース７１２とを有している。

順番予約データベース７１１は、予約の受け付け順に患者への診察が行われる「順番予約」により予約を行った患者の患者ＩＤを、予約受付順序を示す受付番号（受付情報とも記す）と対応付けて記録したデータベースである。順番予約データベース７１１の一例を図７に示す。

本実施形態に係る順番予約データベース７１１には、各日付の午前（ＡＭ）と午後（ＰＭ）にそれぞれ予約受付順に患者ＩＤが記載されている。

例えば図７に示す例では、８月１日（８／１）の午前（ＡＭ）において、受付番号１番の患者は、患者ＩＤ「Ａ３１３３」の患者であり、受付番号２番の患者は患者ＩＤ「Ａ１０２０」の患者である。

また詳細は後述するが、受付番号３番は予約がキャンセルされたため欠番となっている。図７に示す例では受付番号３番の患者ＩＤ欄に「X」印が記入され欠番とされており、後から予約した他の患者に対して受付番号３番は付与されない。

また８月２日の午前は、受付番号３番までの予約が既になされており、受付番号４番の予約はまだなされていない状態である。

順番予約データベース７１１は、院内予約サーバ１００が予約受付サーバ２００を通じて患者端末４００や院内端末５００から送信された順番予約の要求、あるいは順番予約のキャンセル要求が許可された場合に、院内予約サーバ１００により更新される。

時間予約データベース７１２は、予約の際に患者が指定した時間に患者への診察が行われる「時間予約」により予約を行った患者の患者ＩＤを、予約時間と対応付けて記録したデータベースである。時間予約データベース７１２の一例を図８に示す。

本実施形態に係る時間予約データベース７１２には、各日付の所定の予約時間毎にそれぞれ患者ＩＤが記載されている。図８に示す例では、患者が指定可能な予約時間が１５分単位に定められている。そして８月１日の９時１５分には、患者ＩＤ「Ａ３２５４」で特定される患者が診察の予約を行っていることが示されている。

時間予約データベース７１２は、院内予約サーバ１００が予約受付サーバ２００を通じて患者端末４００や院内端末５００から送信された時間予約の要求、あるいは時間予約のキャンセル要求が許可された場合に、院内予約サーバ１００により更新される。

院内予約サーバ１００は、院内予約データベース７１０に記録されている上記の予約受付状況を示すデータを元に、待ちリスト７３０（サービス管理テーブルとも記す）を生成する。待ちリスト７３０は、現在診察を受けている患者の受付番号と、診察の予約を既にキャンセルした患者の受付番号と、を含む、診察の進行状況（サービスの提供状況）を示す情報を記憶するデータ構造である。

待ちリスト７３０の一例を図１１に示す。図１１に示す待ちリスト７３０は、８月１日の午前に予約を行った患者に対する診察の進行状況を示している。

具体的には、待ちリスト７３０は「受付番号」欄、「診察中」欄、「患者ＩＤ」欄、「キャンセル」欄を有する。

「受付番号」欄には、先頭の受付番号（本実施形態では１番）から予約が受け付けられた順に各患者に割り当てられる受付番号が記載される。

「診察中」欄には、現在診察を受けている患者の受付番号が記載される。本実施形態では右向き矢印で現在診察中の患者の受付番号が示されている。図１１に示す例では受付番号４番の患者が現在診察中であることが示されている。院内予約サーバ１００は、院内端末５００から、受付番号４番の患者に対する診察が終了したとの通知を取得すると、受付番号５番の患者に対応する行に右向き矢印を移動する。

「患者ＩＤ」欄には、各受付番号を有する患者の患者ＩＤが記載される。

「キャンセル」欄には、診察の予約を既にキャンセルした患者の受付番号が記載される。本実施形態では、”X”印により、予約をキャンセルした患者の受付番号が示されている。図１１に示す例では受付番号３番の患者が診察の予約をキャンセルしたことが示されている。院内予約サーバ１００は、予約がキャンセルされると、予約をキャンセルした患者の患者ＩＤに対応する行に”X”印を記載する。

なお、例えば受付番号２番の患者の診察が終了した時点で、既に受付番号３番の患者に対する診察の予約がキャンセルされている場合には、受付番号３番を飛ばして受付番号４番の患者に対する診察が開始される。

また院内予約サーバ１００は、診察の予約を行った各患者に対して、現在診察中の患者からの待ち人数を数える場合には、「キャンセル」欄を参照することで、予約を既にキャンセルし患者を除外して数えることができる。

院内予約サーバ１００は、待ちリスト７２０や患者データベース７００、院内予約データベース７１０を参照し、毎日の診察の予約状況及び診察の進行状況を、例えば図１２に示すように、院内端末５００の出力装置５６０であるであるモニタに表示する。図１２には、８月１日における診察の予約状況及び診察の進行状況が院内端末５００のモニタ５６０に表示されている様子が示されている。

図１２において、「状態」欄には、「順番予約」で診察の予約を行った受付番号１番及び２番の患者は既に診察を終了しており、受付番号３番の患者は予約をキャンセルしたことが示されている。そして受付番号４番の患者に対する診察が現在行われており、受付番号５番の患者は順番を待っている状態であることが示されている。

一方、「時間予約」で９時１５分に診察の予約を行った患者（患者ＩＤ「Ａ３２５４」）は、まだ病院の受付を行っていないことが示されている。

病院の受付担当者は、診察の予約を行っていた患者が来院すると、図１２に示すような院内端末５００のモニタ５６０に表示されている予約受付状況画面を見ながら、マウスやキーボード等の入力装置５５０を用いて、その患者の「状態」欄の内容を「未受付」から「待ち」に更新する。

また医師は、「待ち」状態の患者の診察を開始すると、図１２に示すような院内端末５００のモニタ５６０に表示されている予約受付状況画面を見ながら、マウスやキーボード等の入力装置５５０を用いて、その患者の「状態」欄の内容を「待ち」から「診察中」に更新する。この場合、院内予約サーバ２００は、診察が終了した患者の「状態」欄の内容を、「診察中」から「終了」に更新する。

なお医師は、次に診察する患者を選択する際に、時間予約で診察の予約を行っている患者が「待ち」の状態である場合には、現在時刻が予約時間に近い場合には、時間予約で予約した患者を選択するようにする。

また院内予約サーバ２００は、予約がキャンセルされた場合には、予約をキャンセルした患者の「状態」欄の内容を、「未受付」あるいは「待ち」から「キャンセル」に更新する。

そして院内予約サーバ２００は、上記のような各患者の予約状況や診察の進行状況が更新される都度、待ちリスト７３０や院内予約データベース７１０を更新する。

次に予約キャンセルポリシーテーブル７２０について説明する。予約キャンセルポリシーテーブル７２０は、院内予約サーバ１００が患者端末４００から予約のキャンセル要求を受信した場合に、その予約のキャンセルを認めるか認めないかを判定するための条件が記載されたテーブルである。予約キャンセルポリシーテーブル７２０の一例を図９に示す。

また、病院の職員等が予約キャンセルポリシーテーブル７２０の内容を設定する際に院内端末５００に表示される設定画面を図１０に示す。病院の職員は、図１０に示す画面を見ながら、予約キャンセルポリシーテーブル７２０の内容を設定することができる。

具体的には、本実施形態では、職員は、図１０に示す画面を見ながら、「１．常にキャンセルを禁止する」、「２．常にキャンセルを許可する」、「３．以下の場合に予約のキャンセルを禁止する」のうちのいずれかを選択することができる。また「３．以下の場合に予約のキャンセルを禁止する」を選択した場合には、さらに図１０の（１）（２）（３）の設定を行うことができる。

図１０の「１．常にキャンセルを禁止する」が選択された場合には、院内予約サーバ１００は、図９に示す予約キャンセルポリシーテーブル７２０のポリシーNO.１の「有効／無効」欄の内容を「有効」に設定する。そしてこの場合、院内予約サーバ１００は、患者端末４００から予約のキャンセル要求を受信した際には、予約キャンセルポリシーテーブル７２０を参照し、常に予約のキャンセルを不可と判定する。

また図１０の「２．常にキャンセルを許可する」が選択された場合には、院内予約サーバ１００は、図９に示す予約キャンセルポリシーテーブル７２０のポリシーNO.２の「有効／無効」欄の内容を「有効」に設定する。そしてこの場合、院内予約サーバ１００は、患者端末４００から予約のキャンセル要求を受信した際には、予約キャンセルポリシーテーブル７２０を参照し、常に予約のキャンセルを可と判定する。

また図１０の「３．以下の場合に予約のキャンセルを禁止する」が選択された場合には、さらに図１０の「（１）待ち人数がＮ人以下」、「（２）予想待ち時間がＭ分以下」、「（３）当日のキャンセル人数がＬ人以上」の設定が行われる。これら（１）（２）（３）の設定は、何れか一つを選択的に行っても良いし、複数を組み合わせて行っても良い。

図１０において、職員が「（１）待ち人数がＮ人以下」を有効にした場合には、院内予約サーバ１００は、図９に示す予約キャンセルポリシーテーブル７２０のポリシーNO.３の「有効／無効」欄の内容を「有効」に設定する。

そしてこの場合、院内予約サーバ１００は、待ちリスト７３０を参照することで、現在診察を受けている患者と、患者端末４００から予約のキャンセル要求を送信してきた患者との間で、診察の順番を待っている患者の数（待ち人数）を求め、待ち人数が所定値（Ｎ人）以下の場合は、予約のキャンセルを不可と判定する。なお、Ｎの値は、図１０に示す画面から入力することで適宜０人以上の値に設定することができる。

このような態様により、待ち人数が比較的少なく、診察開始までの待ち時間が比較的短いと想定される患者による予約キャンセルを防止することができるので、予約をキャンセルしようとしてきた患者の後で順番を待っている患者が急に診察で呼び出される、ということを回避することが可能になる。そしてこのため、他の患者や病院の混乱を防止することが可能になる。

また図１０において、職員が「（２）予想待ち時間がＭ分以下」を有効にした場合には、院内予約サーバ１００は、図９に示す予約キャンセルポリシーテーブル７２０のポリシーNO.４の「有効／無効」欄の内容を「有効」に設定する。

そしてこの場合、院内予約サーバ１００は、待ちリスト７３０を参照することで、現在診察を受けている患者と、患者端末４００から予約のキャンセル要求を送信してきた患者との間で、診察の順番を待っている患者の数（待ち人数）を求め、待ち人数に所定の係数を乗ずることにより、このキャンセル要求を送信してきた患者の待ち時間を求め、待ち時間が所定時間（Ｍ分）以下の場合は、予約のキャンセルを不可と判定する。なお、Ｍの値は、図１０に示す画面から入力することで適宜０分以上の値に設定することができる。

また上記の待ち時間を求めるための係数は、一人当たりの待ち時間、あるいは一人当たりの診察時間として職員の過去の経験などから事前に定めた固定値を、図１０に示す画面から入力することで設定することができる。例えば一人当たりの待ち時間を１５分として設定することができる。

このような態様により、待ち時間が比較的少ない患者による予約キャンセルを防止することができるので、予約をキャンセルしようとしてきた患者の後で順番を待っている患者が急に診察で呼び出される、というような事態を回避することが可能になる。そしてこのため、他の患者や病院の混乱を防止することが可能になる。また「一人当たりの待ち時間」として定めた固定値を「待ち人数」に掛けて「待ち時間」を算出するようにすることで、「待ち時間」の算出を簡単に行うことができる。

あるいは、上記の待ち時間を求めるための係数は、図１０に示すように、当日の一人当たりの平均診察時間とすることもできる。この場合、院内予約サーバ１００は、当日の診察開始時刻から現在の時刻までの時間を、当日既に診察を行った患者数で割ることで、当日の一人当たりの平均診察時間を算出することができる。

このような態様により、例えば一人当たりの診察時間は診察を担当する医師によって差があるが、日によって診察を担当する医師が変わる場合であっても、医師により異なる一人当たりの診察時間を反映でき、より正確に待ち時間を算出することが可能になる。

あるいは、院内予約サーバ１００は、現在診察を受けている患者と患者端末４００から予約のキャンセル要求を送信してきた患者との間で診察の順番を待っている患者の待ち人数を、所定の換算式に代入することによって、キャンセル要求を送信してきた患者の上記待ち時間を求めるようにしても良い。

この換算式としては、例えば下記の式（１）のように、現在時刻に応じて一人当たりの待ち時間が可変するような式（ｆは現在時刻の関数を表す）とすることができる。また関数ｆとしては、例えば、式（２）のように、現在が午前中である場合は係数Ａ、午後である場合は係数Ｂ、というように、午前と午後とで係数を変えるものを用いることができる。
待ち時間=ｆ(現在時刻)×待ち人数 …（１）
ｆ(現在時刻)＝A or B (午前であればA、午後であればB) …（２）

このような態様により、例えば病院内が混雑しやすい特定の時間帯には医師の判断により一人当たりの診察時間が短めになるような場合があるが、このような場合であっても、時間帯に応じて一人当たりの診察時間を正確に反映でき、待ち時間をより正確に算出することが可能になる。

あるいは、院内予約サーバ１００は、現在診察を受けている患者と患者端末４００から予約のキャンセル要求を送信してきた患者との間で診察の順番を待っている患者の待ち人数を、この待ち人数に応じて待ち時間を定めるための所定のテーブルを参照することにより、キャンセル要求を送信してきた患者の上記待ち時間を求めるようにしても良い。

例えば院内予約サーバ１００は、待ち人数が０人から９人の場合は１０分、待ち人数が１０人から１９人の場合は１１分、待ち人数が２０人以上の場合は１５分、というように、待ち人数と一人当たりの待ち時間とをテーブルに対応付けて記憶しておき、患者端末４００から予約のキャンセル要求を受信した際に、キャンセル要求を送信してきた患者の待ち時間を、上記テーブルを参照することにより求めるようにすることができる。

これにより、例えば待ち人数が多くなればなるほど病院内が混雑し、患者が一時的に所在不明になったり、呼び出しても患者が気づかなかったり、等によって診察の開始が遅れ、一人当たりの診察時間が長くなっていくような場合であっても、正確に待ち時間を算出することが可能になる。

また図１０において、職員が「（３）当日のキャンセル人数がＬ人以上」を有効にした場合には、院内予約サーバ１００は、図９に示す予約キャンセルポリシーテーブル７２０のポリシーNO.５の「有効／無効」欄の内容を「有効」に設定する。

そしてこの場合、院内予約サーバ１００は、当日の診察開始時刻等の所定のタイミング以降に予約を既にキャンセルした人数が所定値（Ｌ人）以上になった場合は、予約のキャンセルを不可と判定する。なお、Ｌの値は、図１０に示す画面から入力することで適宜０人以上の値に設定することができる。

このような態様により、既に所定数以上の患者が予約をキャンセルしている場合には、それ以上の予約キャンセルを防止することができるので、他の患者や病院の混乱を防止することが可能になる。

次に患者が診察の予約をキャンセルしようとする際に、本実施形態に係る患者端末４００、予約受付サーバ２００、院内予約サーバ１００が実行する処理の流れについて、図１３から図１９を参照しながら説明する。

まず、患者端末４００は、予約受付サーバ２００に対して、診察の予約に関する画面の送信要求を送信する（S1000）。

そうすると予約受付サーバ２００は、患者端末４００に対して、診察の予約に関する画面を送信する（S1010）。患者端末４００のモニタ４６０に、診察の予約に関する画面が表示されている様子を図１５に示す。

この図１５に示す画面において、患者は「予約キャンセル」を選択する（S1020）。

そうすると患者端末４００は、予約キャンセル画面の送信要求を予約受付サーバ２００に対して送信する（S1030）。そして予約受付サーバ２００は、予約キャンセル画面を患者端末４００に送信する（S1040）。患者端末４００のモニタ４６０に、予約キャンセル画面が表示されている様子を図１６に示す。

ここで患者は、患者ＩＤ（患者番号）とパスワードとを患者端末４００に入力して、「OK」を押す（S1050）。そうすると患者端末４００は、患者ＩＤとパスワードを予約受付サーバ２００に送信する（S1060）。そして予約受付サーバ２００は、この患者ＩＤとパスワードを、院内予約サーバ１００に送信する（S1070）。

院内予約サーバ１００は、患者データベース７００を参照し、上記患者ＩＤとパスワードに一致する患者ＩＤとパスワードが患者データベース７００に登録されているか否かを確認する（S1080）。

その結果、患者ＩＤとパスワードの少なくともいずれか一方が不一致である場合は、S1090を「NG」に分岐し、院内予約サーバ１００は、予約受付サーバ２００に対して照合失敗した旨を通知する（S1100）。そして予約受付サーバ２００は、S1110を「NG」に分岐し、患者端末４００に対して照合失敗した旨を通知する（S1120）。

この場合患者端末４００は、S1130を「NG」に分岐し、患者に対して再び、患者ＩＤとパスワードの入力を求める（S1050）。

一方、S1080において、患者端末４００から送信されてきた患者ＩＤ及びパスワードの両方がとも同じものが患者データベース７００に記録されていた場合は、S1090を「OK」に分岐し、院内予約サーバ１００は、その患者の予約情報を院内予約データベース７１０から抽出する（S1140）。予約情報には、順番予約の場合は予約日及び受付番号が含まれ、時間予約の場合は予約日と予約時間が含まれる。同一の患者が複数の予約を行っている場合には、これらの複数の予約情報が抽出される。

そして院内予約サーバ１００は、この予約情報を予約受付サーバ２００に送信する（S1150）。そして予約受付サーバ２００は、この予約情報を表示した予約情報表示画面を患者端末４００に送信する（S1160）。

この予約情報表示画面が患者端末４００のモニタ４６０に表示されている様子を図１７に示す。図１７に示す例では、この患者は12月17日の午後に、受付番号２番で診察の予約を行っていることが示されている。同一の患者が複数の予約を行っている場合には、これらの複数の予約情報がそれぞれ患者端末４００のモニタ４６０に表示される。

そして患者は、キャンセルしたい予約を選択して患者端末４００に入力する(S1170)。

そうすると患者端末４００は、選択された予約情報を含む予約キャンセル要求を予約受付サーバ２００に送信する（S1180）。そして予約受付サーバ２００は、この予約キャンセル要求を院内予約サーバ１００に送信する（S1190）。

そうすると院内予約サーバ１００は、予約キャンセルポリシーテーブル７２０及び待ちリスト７３０を参照し、患者がキャンセルしようとしている予約のキャンセルを行えるか否かの判定を行う(S1200)。この場合院内予約サーバ１００は、例えば上述したように、現在診察を受けている患者と、患者端末４００から予約のキャンセル要求を送信してきた患者との間で、診察の順番を待っている患者の数（待ち人数）を求め、待ち人数が所定人数以下の場合は、予約のキャンセルを不可と判定する。

院内予約サーバ１００は、予約のキャンセルを不可と判定した場合は、S1200を「NO」に進み、キャンセルができない旨を予約受付サーバ２００に送信する（S1210）。そして予約受付サーバ２００は、S1220を「NO」に進み、患者端末４００に対して、キャンセル不可の旨を送信する（S1230）。

そして患者端末４００は、S1240を「NO」に進み、予約のキャンセルができない旨の表示を行う（S1250）。

一方、予約のキャンセルを可と判定した場合は、院内予約サーバ１００は、S1200を「YES」に進み、キャンセル確認用のメッセージを予約受付サーバ２００に送信する（S1260）。そして予約受付サーバ２００は、S1220を「YES」に進み、患者端末４００に対してキャンセル確認メッセージを送信する（S1270）。

そして患者端末４００は、キャンセル確認のメッセージを、モニタ４６０に表示する。キャンセル確認のメッセージがモニタ４６０に表示されている様子を図１８に示す。

ここで患者は「はい」か「いいえ」を選択し、「いいえ」が選択された場合には患者端末４００はS1290を「しない」に進み、処理を終了する。

一方「はい」が選択された場合には、患者端末４００は、S1290を「する」に進み、予約受付サーバ２００に対してキャンセルの指示を送信する（S1300）。そして予約受付サーバ２００は、キャンセルの指示を院内予約サーバ１００に送信する（S1310）。

そして院内予約サーバ１００は、院内予約データベース７１０及び待ちリスト７３０を更新する（S1320、S1360）とともに、予約受付サーバ２００に対してキャンセルを完了した旨のメッセージを送信する（S1330）。そして予約受付サーバ２００は、キャンセルを完了した旨のメッセージを患者端末４００に送信する（S1340）。

そして患者端末４００は、キャンセルを完了した旨のメッセージをモニタ４６０に表示する（S1350）。キャンセルを完了した旨のメッセージがモニタ４６０に表示されている様子を図１９に示す。

一方で、院内予約サーバ１００は、S1320及びS1360により院内予約データベース７１０及び待ちリスト７３０を更新すると、待ちリスト７３０に掲載されている待機中の患者のうち、診察が近付いてきた所定の患者に対して、電子メールあるいは電話により、患者端末４００に診察が近いことを知らせるための通知を行う（S1370）。

この通知は、例えば受付番号順に、現在診察中の患者から、予約がキャンセルされた患者を除いて所定番目（例えば５番目）の患者に対して行われる。この通知を受けた患者は、自分の診察が近いことを知り、病院に出向くことになる。

またこの患者は、上記通知を受けた時点では診察の順番が到来するまでにはある程度の時間的な余裕があるので、あわてずに安心して病院に出向くことができる。

このように本実施形態によれば、院内予約サーバ１００が、患者端末４００から予約のキャンセル要求を受けた場合に、診察の進行状況に応じて予約のキャンセル可否を判定するようにしているので、他の患者や病院の混乱を起こしにくいようにすることができる。

また院内予約サーバ１００は、待ちリスト７３０を参照することで、現在診察を受けている患者と、患者端末４００から予約のキャンセル要求を送信してきた患者との間で、診察の順番を待っている患者の数（待ち人数）を求め、待ち人数が所定値（Ｎ人）以下の場合は、予約のキャンセルを不可と判定するようにもできる。

このような態様により、待ち人数が比較的少ない患者による突然の予約キャンセルを防止することができるので、予約をキャンセルしようとしてきた患者の後で順番を待っている患者が急に診察で呼び出される、ということを回避することが可能になる。そしてこのため、他の患者や病院の混乱を防止することが可能になる。

また院内予約サーバ１００は、待ちリスト７３０を参照することで、現在診察を受けている患者と、患者端末４００から予約のキャンセル要求を送信してきた患者との間で、診察の順番を待っている患者の数（待ち人数）を求め、待ち人数に所定の係数を乗ずることにより、このキャンセル要求を送信してきた患者の待ち時間を求め、待ち時間が所定時間（Ｍ分）以下の場合は、予約のキャンセルを不可と判定するようにもできる。

このような態様により、待ち時間が比較的少ない患者による突然の予約キャンセルを防止することができるので、予約をキャンセルしようとしてきた患者の後で順番を待っている患者が急に診察で呼び出される、というような事態を回避することが可能になる。そしてこのため、他の患者や病院の混乱を防止することが可能になる。

このとき上記所定の係数として、「一人当たりの待ち時間」として定めた固定値を用いるようにすることで「待ち時間」の算出を簡単に行うことが可能となる。

あるいは、上記所定の係数を当日の一人当たりの平均診察時間とすることもできる。この場合には、例えば診察を担当する医師が日によって異なる場合であっても、医師により異なる一人当たりの診察時間を反映でき、より正確に待ち時間を算出することが可能になる。

また院内予約サーバ１００は、現在診察を受けている患者と患者端末４００から予約のキャンセル要求を送信してきた患者との間で診察の順番を待っている患者の待ち人数を、所定の換算式に代入することによって、キャンセル要求を送信してきた患者の上記待ち時間を求めるようにしても良い。

このような態様により、例えば病院内が混雑しやすい特定の時間帯には医師の判断により一人当たりの診察時間が短めになるような場合であっても、時間帯に応じて一人当たりの診察時間を正確に反映でき、より柔軟に待ち時間を正確に算出することが可能になる。

また院内予約サーバ１００は、現在診察を受けている患者と患者端末４００から予約のキャンセル要求を送信してきた患者との間で診察の順番を待っている患者の待ち人数を、この待ち人数に応じて待ち時間を定めるための所定のテーブルを参照することにより、キャンセル要求を送信してきた患者の上記待ち時間を求めるようにしても良い。

このような態様により、例えば待ち人数が多くなればなるほど病院内が混雑し、患者が一時的に所在不明になったり、呼び出しても患者が気づかなかったり、等によって診察の開始が遅れ、一人当たりの診察時間が長くなっていくような場合であっても、正確に待ち時間を算出することが可能になる。

またさらに、院内予約サーバ１００は、当日の診察開始時刻等の所定のタイミング以降に予約を既にキャンセルした人数が所定値以上になった場合は、予約のキャンセルを不可と判定するようにしても良い。

このような態様により、既に所定数以上の患者が予約をキャンセルしている場合には、それ以上の予約キャンセルを防止することができるので、他の患者や病院の混乱を防止することが可能になる。

前述した実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明はその趣旨を逸脱することなく変更や改良等が可能であり、また本発明はその等価物も含むものである。

１００ 院内予約サーバ
１１０ ＣＰＵ
１２０ メモリ
１３０ 通信ＩＦ
１４０ 記憶装置
１５０ 入力装置
１６０ 出力装置
１７０ 記録媒体読取装置
２００ 予約受付サーバ
３００ 診療サーバ
４００ 患者端末
５００ 院内端末
６００ インターネット
６１０ 院内ネットワーク
７００ 患者データベース
７１０ 院内予約データベース
７１１ 順番予約データベース
７１２ 時間予約データベース
７２０ 予約キャンセルポリシーテーブル
７３０ 待ちリスト
８００ 記録媒体
９００ 予約受付サーバ制御プログラム
９１０ 院内予約サーバ制御プログラム
１０００ 予約システム

Claims (10)

1. 予約を受け付けた順に付与した受付情報の順序で利用者にサービスの提供を行うサービス提供者により用いられる情報処理装置であって、
   前記サービスの提供を現在受けている利用者の受付情報と、前記予約を既にキャンセルした利用者の受付情報と、を含む、前記サービスの提供状況を示す情報を記憶するサービス管理テーブルと、
   通信可能に接続された端末から、受付情報を指定した予約のキャンセル要求を受信するキャンセル要求受信部と、
   前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とに基づいて、前記予約のキャンセルの可否を判定する可否判定部と、
   前記キャンセルの可否の判定結果を前記端末に送信する判定結果送信部と、
   を備えることを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記可否判定部は、前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とを用いて、前記サービスの提供を現在受けている利用者と前記キャンセル要求を送信してきた利用者との間で前記サービスの提供を待機中の利用者の数を求め、前記待機中の利用者の数が所定値以下の場合は、前記予約のキャンセルを不可と判定する
   ことを特徴とする情報処理装置。
3. 請求項１に記載の情報処理装置であって、
   前記可否判定部は、前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とを用いて、前記サービスの提供を現在受けている利用者と前記キャンセル要求を送信してきた利用者との間で前記サービスの提供を待機中の利用者の数を求め、前記待機中の利用者の数に所定の係数を乗ずることにより、前記キャンセル要求を送信してきた利用者の待ち時間を求め、前記待ち時間が所定時間以下の場合は、前記予約のキャンセルを不可と判定する
   ことを特徴とする情報処理装置。
4. 請求項１に記載の情報処理装置であって、
   前記可否判定部は、前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とを用いて、前記サービスの提供を現在受けている利用者と前記キャンセル要求を送信してきた利用者との間で前記サービスの提供を待機中の利用者の数を求め、前記待機中の利用者の数を所定の換算式に代入することにより、前記キャンセル要求を送信してきた利用者の待ち時間を求め、前記待ち時間が所定時間以下の場合は、前記予約のキャンセルを不可と判定する
   ことを特徴とする情報処理装置。
5. 請求項１に記載の情報処理装置であって、
   前記可否判定部は、前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とを用いて、前記サービスの提供を現在受けている利用者と前記キャンセル要求を送信してきた利用者との間で前記サービスの提供を待機中の利用者の数を求め、前記待機中の利用者の数に応じて待ち時間を定めるための所定のテーブルを参照することにより、前記キャンセル要求を送信してきた利用者の待ち時間を求め、前記待ち時間が所定時間以下の場合は、前記予約のキャンセルを不可と判定する
   ことを特徴とする情報処理装置。
6. 請求項３に記載の情報処理装置であって、
   前記係数は、前記サービスの提供を既に受けた利用者が前記サービスの提供を受けた際にそれぞれ要した時間の平均値である
   ことを特徴とする情報処理装置。
7. 請求項３に記載の情報処理装置であって、
   前記係数は、事前に設定された固定値である
   ことを特徴とする情報処理装置。
8. 請求項１に記載の情報処理装置であって、
   前記可否判定部は、所定のタイミング以降に前記予約を既にキャンセルした人数が所定値以上の場合は、前記キャンセル要求により指定された前記予約のキャンセルを不可と判定する
   ことを特徴とする情報処理装置。
9. 予約を受け付けた順に付与した受付情報の順序で利用者にサービスの提供を行うサービス提供者により用いられ、前記サービスの提供を現在受けている利用者の受付情報と、前記予約を既にキャンセルした利用者の受付情報と、を含む、前記サービスの提供状況を示す情報を記憶する情報処理装置の制御方法であって、
   前記情報処理装置が、通信可能に接続された端末から、受付情報を指定した予約のキャンセル要求を受信し、
   前記情報処理装置が、前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とに基づいて、前記予約のキャンセルの可否を判定し、
   前記情報処理装置が、前記キャンセルの可否の判定結果を前記端末に送信する
   ことを特徴とする情報処理装置の制御方法。
10. 予約を受け付けた順に付与した受付情報の順序で利用者にサービスの提供を行うサービス提供者により用いられ、前記サービスの提供を現在受けている利用者の受付情報と、前記予約を既にキャンセルした利用者の受付情報と、を含む、前記サービスの提供状況を示す情報を記憶する情報処理装置に、
    通信可能に接続された端末から、受付情報を指定した予約のキャンセル要求を受信する手順と、
    前記キャンセル要求により指定される前記受付情報と前記サービスの提供状況を示す前記情報とに基づいて、前記予約のキャンセルの可否を判定する手順と、
    前記キャンセルの可否の判定結果を前記端末に送信する手順と、
    を実行させるためのプログラム。

Images