(57)【要約】【課題】通信障害が生じた場合でも、ダブルブッキングを防止しつつ、受付けサービスを完全に停止させずに継続する。【解決手段】院外サーバ２５のＣＰＵ４２は、ＨＤＤ４４から予約受付プログラムをロードして、プログラムに記述された処理ステップを実行する。ＣＰＵ４２には、予約受付処理部２５ａ、ＤＢアクセス部２５ｂ、同期処理部２５ｃ、回線監視部２５ｄ、及び予約枠制限部２５ｅが構築される。回線監視部２５ｄは、予約枠の同期の状況を判断する。同期が取れていない場合には、予約枠制限部２５ｅは、受付け可能な予約枠を制限する。【選択図】図５
2010152593.tif 000002
【特許請求の範囲】
【請求項１】
医療施設内の端末から既定の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を院内データベースに記憶させる院内サーバと、
医療施設外の端末から、前記院内サーバが予約情報を受け付ける予約枠と同一の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を院外データベースに記憶させる院外サーバと、
各データベースの予約情報を同期させる同期手段と、
前記同期手段で各データベースの予約情報の同期が取れなくなった同期不能時に、各サーバの少なくとも一方の予約枠について、その一部を受付け不可とし、受付け可能な予約枠を制限する予約枠制限手段とを備えたことを特徴とする医療検査の予約受付システム。
【請求項２】
前記予約枠制限手段は、前記同期不能時から所定期間の予約枠を受付け不可とすることを特徴とする請求項１に記載の医療検査の予約受付システム。
【請求項３】
既定の予約枠は時間帯毎に複数あり、
前記予約枠制限手段は、各時間帯で少なくとも１つの予約枠を受付け不可とすることを特徴とする請求項１又は２に記載の医療検査の予約受付システム。
【請求項４】
前記予約枠制限手段は、過去の予約実績に基づいて、受付け不可とする予約枠を決定することを特徴とする請求項１〜３のいずれかに記載の医療検査の予約受付システム。
【請求項５】
前記予約枠制限手段は、前記同期不能となってから前記同期手段で各データベースの予約情報の同期が再度取れるようになった同期回復時に、受付け可能な予約枠の制限を解除することを特徴とする請求項１〜４のいずれかに記載の医療検査の予約受付システム。
【請求項６】
各サーバは、前記同期不能時に受け付けた予約情報を、仮の予約情報として対応するデータベースに記憶することを特徴とする請求項１〜５のいずれかに記載の医療検査の予約受付システム。
【請求項７】
各サーバは、前記同期不能時に予約情報を受け付けた際に、仮の受付けである旨を対応する端末に通知することを特徴とする請求項６に記載の医療検査の予約受付システム。
【請求項８】
前記同期不能時に各サーバが受け付けた予約情報が重複した場合、前記同期手段は、各サーバの予約情報の受付時刻、又は各サーバで受け付けた予約情報のいずれを優先的に受け付けるのかを指定した優先指定情報に基づいて、一方の予約情報を正式の予約情報として受け付け、他方の予約情報を無効にすることを特徴とする請求項１〜７のいずれかに記載の医療検査の予約受付システム。
【請求項９】
前記同期手段は、各サーバの予約情報の受付時刻が同一の場合、各受付時刻に乱数を加算した結果に基づいて、一方の予約情報を正式の予約情報として受け付け、他方の仮の予約情報を無効にすることを特徴とする請求項８に記載の医療検査の予約受付システム。
【請求項１０】
各サーバは、受け付けた予約情報が前記同期手段で無効にされた場合に、予約情報を送った端末に、予約情報が無効にされた旨を通知することを特徴とする請求項８又は９のいずれかに記載の医療検査の予約受付システム。
【請求項１１】
医療施設外の端末から受け付けた予約情報が前記同期手段で無効とされた場合、前記院外サーバは、予約情報を送った端末に、無効にされた予約情報で予約した医療施設とは別の医療施設の情報を通知することを特徴とする請求項８〜１０のいずれかに記載の医療検査の予約受付システム。
【請求項１２】
医療施設外の端末から受け付けて前記同期手段で無効にされた予約情報が、さらに前記別の医療施設の予約情報と重複した場合、前記同期手段は、前者の予約情報を受け付け、後者の予約情報を無効にすることを特徴とする請求項１１に記載の医療検査の予約受付システム。
【請求項１３】
医療施設内の端末から院内サーバに、既定の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院内サーバが院内データベースに記憶させる院内受付ステップと、
医療施設外の端末から院外サーバに、前記院内サーバが予約情報を受け付ける予約枠と同一の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院外サーバが院外データベースに記憶させる院外受付ステップと、
各データベースの予約情報を同期手段で同期させる同期ステップと、
前記同期ステップで各データベースの予約情報の同期が取れなくなった場合に、予約枠制限手段が、各サーバの少なくとも一方の予約枠について、その一部を受付け不可とし、受付け可能な予約枠を制限する予約枠制限ステップとを備えたことを特徴とする医療検査の予約受付方法。
【請求項１４】
医療施設内の端末から院内サーバに、既定の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院内サーバが院内データベースに記憶させる院内受付ステップと、
医療施設外の端末から院外サーバに、前記院内サーバが予約情報を受け付ける予約枠と同一の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院外サーバが院外データベースに記憶させる院外受付ステップと、
各データベースの予約情報を同期手段で同期させる同期ステップと、
前記同期ステップで各データベースの予約情報の同期が取れなくなった場合に、予約枠制限手段が、各サーバの少なくとも一方の予約枠について、その一部を受付け不可とし、受付け可能な予約枠を制限する予約枠制限ステップとをコンピュータに実行させることを特徴とする医療検査の予約受付プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを通じて医療検査の予約情報を受け付けてスケジュールを管理する医療検査の予約受付方法及びシステム、並びに医療検査の予約受付プログラムに関する。
【背景技術】
【０００２】
地域における医療施設間の医療連携の一環として、地域内の中核病院など、高度な医療検査設備を持つ比較的大規模な医療施設が、診療所などの比較的小規模な医療施設からの依頼に基づいて、医療検査を受託することが行われている。
【０００３】
特許文献１に記載の医用ネットワークシステムは、医療施設間の医療検査の予約をオンラインで行い、オンライン予約サービスを提供する。医用ネットワークシステムは、予約を申し込む予約元となる診療所の端末と、予約を受け付ける予約先となる中核病院の院内コンピュータシステムと、診療所の端末から中核病院の院内コンピュータシステムに送信される予約情報を中継するデータセンタのコンピュータシステムと備え、互いにネットワークを介して通信可能に接続されている。
【０００４】
院内コンピュータシステムは、不正アクセスなどによる患者の個人情報の漏洩を防止するために、診療所の端末など不特定の外部の端末からの直接的なオンラインアクセスが規制されている。そのため、データセンタのコンピュータシステムが診療所の端末からの直接的なオンラインアクセスを受け付けて、診療所の端末からの予約情報を院内コンピュータシステムへ中継している。
【０００５】
院内コンピュータシステムは、医療検査の予約枠の受付け状況を記録したスケジュールデータを含む院内データベース（ＤＢ）にアクセスが可能であり、院内ＤＢにアクセスしてスケジュールデータを更新することにより予約情報の受付け処理を行う院内サーバを備えている。院内サーバは、診療所などの院外予約ばかりでなく、中核病院の内部における院内予約（外科や内科といった診療科から放射線科といった検査科への医療検査の予約）も受け付ける。
【０００６】
一方、データセンタのコンピュータシステムは、院内ＤＢとは別の独立した院外ＤＢを持ち、院外ＤＢにアクセスして、診療所の端末からの予約を受け付ける院外サーバを備えている。院外ＤＢは、院内ＤＢから独立しているものの、中核病院の医療検査の予約を受け付けるためのものであるため、その内容は、院内ＤＢのスケジュールデータと同様であり、院内ＤＢと同一の予約枠を重複した形態で備えている。
【０００７】
このような形態で院内ＤＢと院外ＤＢが構成されていると、院内サーバと院外サーバが、それぞれ同じタイミングで同一の予約枠に対する受付け処理を行った場合、当然ながら、１つの予約枠に院外予約と院内予約が重複するというダブルブッキングが生じるおそれがある。
【０００８】
ダブルブッキングを防止するための解決策として、まず考えられるのが、コンサートチケットや切符などのオンライン予約システムのように、予約枠の受付け状況を記録するスケジュールデータを含むＤＢを１つにし、端末から予約の申込みがあった場合には、そのＤＢを参照するシステムを構築することである。ＤＢが１つであれば、ダブルブッキングを確実に防止することができる。
【０００９】
しかし、複数の医療施設の院内コンピュータシステムとデータセンタのコンピュータシステムからなる医用ネットワークシステムのように、ベンダー（製造供給元）や運営主体、構築する時期が異なる複数のコンピュータシステムを相互接続して構築する際には、既存のコンピュータシステムの改造を最小限に止めなければならないといった現実的な要請が強く、各コンピュータシステムが参照するＤＢを１つに統合したネットワークシステムを構成することは現実的には困難である。
【００１０】
そこで、医用ネットワークシステムにおいては、院内サーバと院外サーバが、予約の受付け処理の際に、ネットワークを介してリアルタイムで通信を行って、院内ＤＢと院外ＤＢの同期を取ることで、ダブルブッキングを防止することが検討されている。具体的には、例えば、一方のサーバの予約の受付け処理の際には、そのＤＢを更新するとともに、他方のサーバへその旨を通知して他方のＤＢも更新する。
【特許文献１】特開２００８−２３４３８１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、各サーバ間のリアルタイムの通信により各ＤＢの同期を取る方法は、ネットワークに通信障害が発生すると、不能になる。同期不能時にダブルブッキングを確実に防止するためには、通信障害が回復するまでの間、院内予約あるいは院外予約の少なくとも一方の予約の受付けサービスを完全に停止しなければならない。
【００１２】
受付けサービスを完全に停止すると、当然ながら、予約元が不便であるばかりでなく、予約枠の空き枠が増加することで、医療検査設備の稼働率が低下して、医療施設の損失も大きい。
【００１３】
受付けサービスの完全な停止を防止する方策として、通信回線を強化して通信障害の発生頻度を下げることが考えられる。具体的には、各サーバ間の通信回線として、速度保証型の専用線といった通信品質の高い回線に加えて、バックアップ回線を敷設して回線を二重化するといった方策がある。しかし、この方策は、各サーバ間の通信量に対する通信コストが嵩み過ぎるため採用できない。なぜならば、医用ネットワークシステムでは、データセンタが複数の医療施設と接続されるので、各医療施設との間の通信回線をすべて二重化する必要があり、大幅なコスト増が避けられず、現実的ではないからである。また、回線強化を行っても、通信障害が完全になくなるわけでもない。
【００１４】
そのため、通信障害が発生することを前提として、通信障害が発生した場合でも予約の受付けサービスの完全な停止を防止する方策が模索されていた。各サーバ間の通信回線としては、情報セキュリティの確保と通信コストの抑制を考慮した場合、ＶＰＮといったＩＰネットワークをバックボーンネットワークとしたベストエフォート型の通信回線を使用することが最良であるが、ベストエフォート型の通信回線は、速度保証型の専用線と比較して、通信障害の発生頻度が高いため、通信障害が発生した場合でも予約の受付けサービスの完全な停止を防止する方策の必要性が特に高い。
【００１５】
本発明は、上記背景を鑑みてなされたものであり、その目的は、院内ＤＢと院外ＤＢの複数のＤＢを持つ医用ネットワークシステムにおいて、通信障害が生じた場合でも、ダブルブッキングを防止しつつ、受付けサービスを完全に停止させずに継続することにある。
【課題を解決するための手段】
【００１６】
上記目的を達成するために、本発明の医療検査の予約受付システムは、医療施設内の端末から既定の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を院内データベースに記憶させる院内サーバと、医療施設外の端末から、前記院内サーバが予約情報を受け付ける予約枠と同一の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を院外データベースに記憶させる院外サーバと、各データベースの予約情報を同期させる同期手段と、前記同期手段で各データベースの予約情報の同期が取れなくなった同期不能時に、各サーバの少なくとも一方の予約枠について、その一部を受付け不可とし、受付け可能な予約枠を制限する予約枠制限手段とを備えたことを特徴とする。
【００１７】
請求項２に記載の発明では、前記予約枠制限手段は、前記同期不能時から所定期間の予約枠を受付け不可とする。
【００１８】
請求項３に記載の発明では、既定の予約枠は時間帯毎に複数あり、前記予約枠制限手段は、各時間帯で少なくとも１つの予約枠を受付け不可とする。
【００１９】
請求項４に記載の発明では、前記予約枠制限手段は、過去の予約実績に基づいて、受付け不可とする予約枠を決定する。
【００２０】
請求項５に記載の発明では、前記予約枠制限手段は、前記同期不能となってから前記同期手段で各データベースの予約情報の同期が再度取れるようになった同期回復時に、受付け可能な予約枠の制限を解除する。
【００２１】
請求項６に記載の発明では、各サーバは、前記同期不能時に受け付けた予約情報を、仮の予約情報として対応するデータベースに記憶する。
【００２２】
請求項７に記載の発明では、各サーバは、前記同期不能時に予約情報を受け付けた際に、仮の受付けである旨を対応する端末に通知する。
【００２３】
請求項８に記載の発明では、前記同期不能時に各サーバが受け付けた予約情報が重複した場合、前記同期手段は、各サーバの予約情報の受付時刻、又は各サーバで受け付けた予約情報のいずれを優先的に受け付けるのかを指定した優先指定情報に基づいて、一方の予約情報を正式の予約情報として受け付け、他方の予約情報を無効にすることを特徴とする請求項１〜７のいずれかに記載の医療検査の予約受付システム。
【００２４】
請求項９に記載の発明では、前記同期手段は、各サーバの予約情報の受付時刻が同一の場合、各受付時刻に乱数を加算した結果に基づいて、一方の予約情報を正式の予約情報として受け付け、他方の仮の予約情報を無効にする。
【００２５】
請求項１０に記載の発明では、各サーバは、受け付けた予約情報が前記同期手段で無効にされた場合に、予約情報を送った端末に、予約情報が無効にされた旨を通知する。
【００２６】
請求項１１に記載の発明では、医療施設外の端末から受け付けた予約情報が前記同期手段で無効とされた場合、前記院外サーバは、予約情報を送った端末に、無効にされた予約情報で予約した医療施設とは別の医療施設の情報を通知する。
【００２７】
請求項１２に記載の発明では、医療施設外の端末から受け付けて前記同期手段で無効にされた予約情報が、さらに前記別の医療施設の予約情報と重複した場合、前記同期手段は、前者の予約情報を受け付け、後者の予約情報を無効にする。
【００２８】
本発明の医療検査の予約受付方法は、医療施設内の端末から院内サーバに、既定の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院内サーバが院内データベースに記憶させる院内受付ステップと、医療施設外の端末から院外サーバに、前記院内サーバが予約情報を受け付ける予約枠と同一の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院外サーバが院外データベースに記憶させる院外受付ステップと、各データベースの予約情報を同期手段で同期させる同期ステップと、前記同期ステップで各データベースの予約情報の同期が取れなくなった場合に、予約枠制限手段が、各サーバの少なくとも一方の予約枠について、その一部を受付け不可とし、受付け可能な予約枠を制限する予約枠制限ステップとを備えたことを特徴とする。
【００２９】
本発明の医療検査の予約受付プログラムは、医療施設内の端末から院内サーバに、既定の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院内サーバが院内データベースに記憶させる院内受付ステップと、医療施設外の端末から院外サーバに、前記院内サーバが予約情報を受け付ける予約枠と同一の予約枠で医療検査の予約情報を受け付け、受け付けた予約情報を前記院外サーバが院外データベースに記憶させる院外受付ステップと、各データベースの予約情報を同期手段で同期させる同期ステップと、前記同期ステップで各データベースの予約情報の同期が取れなくなった場合に、予約枠制限手段が、各サーバの少なくとも一方の予約枠について、その一部を受付け不可とし、受付け可能な予約枠を制限する予約枠制限ステップとをコンピュータに実行させることを特徴とする。
【発明の効果】
【００３０】
本発明の医療検査の予約受付方法及びシステム、並びに医療検査の予約受付プログラムによれば、院内及び院外の各データベースの予約情報の同期が取れなくなったときに受付け可能な予約枠を制限するから、通信障害が生じた場合でも、ダブルブッキングを防止しつつ、受付けサービスを完全に停止させずに継続することができる。
【発明を実施するための最良の形態】
【００３１】
図１に示すように、予約受付システム１１は、データセンタ１２と複数の医療施設に設置されたコンピュータシステムとを通信ネットワークで接続し、オンラインで医療検査の予約受付を行うシステムである。データセンタ１２は、複数の医療施設に対して、医療検査の予約受付サービスを提供する。
【００３２】
複数の医療施設には、中核病院１３と診療所１４がある。中核病院１３は、ＣＴ（Computed Tomography）装置やＭＲＩ（Magnetic Resonance Imaging）装置など高度な医療検査装置を保有する。中核病院１３は、その地域内の医療施設の中で比較的大規模な医療施設であり、内部の診療科、及び外部の医療施設からの医療検査依頼を受ける。診療所１４は、高度な医療検査装置を持たず、中核病院１３へ医療検査を依頼する。
【００３３】
中核病院１３には、院内の各種のコンピュータをＬＡＮ（Local Area Network）１５で接続した院内情報システム１６が構築されている。院内情報システム１６は、医療検査の予約受付処理、診療受付処理、会計処理などの院内の情報処理を行う。ＬＡＮ１５は、院内に敷設された施設内ネットワークであり、院内情報システム１６は、インターネット１７など、不特定多数の利用者に開放された公衆系の外部ネットワークと遮断されている。これにより、外部からの不正なアクセスなどの情報セキュリティリスクを回避している。
【００３４】
院内情報システム１６では、院内の各診療科に設置された予約受付端末（以下、院内端末という。）１８からＬＡＮ１５を通じてオンラインで医療検査の予約ができる。院内サーバ１９は、こうした予約を受け付けて、医療検査のスケジュール管理を行う。
【００３５】
院内サーバ１９には院内データベース（以下、院内ＤＢと略す。）２２が接続されている。院内ＤＢ２２には、医療検査の予約状況などを表す院内スケジュールデータ（以下、院内データと略す。）２３が格納されている。
【００３６】
院内サーバ１９は、院内端末１８からのアクセスを受け付けて、院内データ２３に基づいて、院内端末１８へ予約状況を知らせる。そして、院内端末１８から予約情報を受信すると、その予約を受け付けて院内データ２３を更新する。院内端末１８からの予約情報には、検査の種類・日付と時間帯で指定される予約枠・患者名・疾患名、院内端末１８からの送信時に自動的に付される予約元（中核病院１３の診療科名）、予約受付時刻、院内データ２３及びこれと同じ予約枠を有する院外スケジュールデータ（以下、院外データと略す。）２７間の同期の成否などの情報が含まれる（図２参照）。予約受付時刻は、院内端末１８からの予約情報を院内サーバ１９で受け付けた時刻であり、院内サーバ１９によって付される。データ２３、２７間の同期の成否は、詳しくは後述する。院内サーバ１９は、院内端末１８から予約情報を受けると、受け付けた予約情報に予約ＩＤを付与する。
【００３７】
院内端末１８は、ブラウザソフトがインストールされたパーソナルコンピュータであり、院内サーバ１９と通信を行って、モニタへの予約状況の表示や、予約情報の送信を行う。
【００３８】
図には、施設ＩＤが「Ｘ」の中核病院１３についてのみ、その内部構成を示しているが、施設ＩＤが「Ｙ」の中核病院１３の内部構成も同様であり、便宜上図示を省略している。
【００３９】
各中核病院１３は、それぞれ各診療所１４からの医療検査の依頼を受けて、医療検査を実施する。データセンタ１２は、各中核病院１３の医療検査の受付窓口になっており、各診療所１４に設置された予約受付端末（以下、院外端末という。）２４からインターネット１７を通じてオンラインで医療検査の予約を受け付ける。このように、データセンタ１２にそれぞれの中核病院１３の受付窓口を一本化することで、各診療所１４は、中核病院１３毎に個別に医療検査の予約を行わなくて済む。
【００４０】
データセンタ１２は、院外サーバ２５、院外データベース（以下、院外ＤＢと略す。）２６を備えている。院外サーバ２５は、ＷＥＢサーバとして機能し、インターネット上で標準的に用いられるドキュメントシステム（ＷＷＷ：World Wide Web）に対応する。院外サーバ２５は、クライアント端末である院外端末２４からの要求に応答してデータを送受信する。院外端末２４は、ＷＥＢブラウザがインストールされたパーソナルコンピュータであり、院外サーバ２５へアクセスする。
【００４１】
院外サーバ２５には、院外ＤＢ２６が接続されている。院外ＤＢ２６には、中核病院１３毎の医療検査の予約状況などを表す複数の院外データ２７が格納されている。各院外データ２７は、中核病院１３毎の識別情報（施設ＩＤ）が付与されており、識別可能である。また、中核病院１３毎の院外データ２７は、各中核病院１３がそれぞれ実施する検査の種類別に分かれている。
【００４２】
院外サーバ２５は、院外端末２４からのアクセスを受け付けて、院外データ２７に基づいて、院外端末２４へ予約状況を知らせる。そして、院外端末２４から、予約情報を受信すると、その予約を受け付けて院外データ２７を更新する。院外端末２４からの予約情報には、診療科名の代わりに中核病院１３及び診療所１４の名称が予約先及び予約元の情報として付される他は、院内端末１８からの予約情報と同様の情報が含まれる（図３参照）。このように、院外サーバ２５は、院外端末２４からの予約を受け付け、その予約状況を管理する。
【００４３】
中継サーバ２８は、院内サーバ１９と院外サーバ２５との間で、それぞれが各端末１８、２４から受け付けた予約情報を中継する。中継サーバ２８は、外部から院内情報システム１６への不正アクセスを防止するファイヤーウォールとして機能する。
【００４４】
中継サーバ２８と院外サーバ２５は、ＶＰＮ（Virtual Private Network）２９を介して接続される。ＶＰＮ２９では、暗号化技術が使われており、複数の利用者によって共有される共有ネットワーク内に論理的な専用通信チャンネルが確立されている。これにより、通信拠点間の機密性が保持され、ネットワーク内の堅固な情報セキュリティが確保される。なお、ＶＰＮ２９には、Ｂフレッツ（登録商標）、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線といったベストエフォート回線を用いることが考えられる。
【００４５】
図２に示すように、院内ＤＢ２２には、院内データ２３の他に、登録テーブル３１、患者マスタ３２、診療所マスタ３３、及び診療科マスタ３４が格納されている。
【００４６】
登録テーブル３１には、予約受付時刻、予約ＩＤ、データ２３、２７間の同期の成否、患者名、疾患名、検査の種類、日付と時間帯で指定される予約枠、予約元などの情報が、受け付けた予約情報毎に記憶されている。登録テーブル３１は、院内端末１８から新たな予約情報が送信されることにより更新される。
【００４７】
患者マスタ３２には、患者ＩＤ、患者の個人情報（氏名、住所、連絡先）などの情報が、患者毎に記憶されている。患者マスタ３２は、院内端末１８を介して新規患者の患者データが入力されることにより更新される。
【００４８】
診療所マスタ３３には、診療所ＩＤ、診療所情報（名称、住所、連絡先）などの情報が、診療所１４毎に記憶されている。診療科マスタ３４には、診療科ＩＤ、診療科名などの情報が、診療科毎に記憶されている。診療所マスタ３３及び診療科マスタ３４は、院内サーバ１９のコンソール４７（図４参照）を操作することで更新可能である。
【００４９】
これらの各マスタ３２、３３は、院外ＤＢ２６の同一の各マスタ３２、３３（図３参照）と同期が取られることにより更新される。
【００５０】
院内データ２３は、予約枠マスタ３５、及び予約情報テーブル３６からなる。予約枠マスタ３５には、予約枠ＩＤ（予約枠毎に付されるＩＤであり、予約ＩＤとは異なる。）、予約枠の日付・時間帯などの情報が、ＣＴ、ＭＲＩといった検査種別毎に記憶されている。また、予約枠マスタ３５は、予約ＩＤを記憶する領域を予約枠毎に有している。予約枠は、例えば９：００〜、９：３０〜など、３０分間隔に区切られた時間帯毎に一つずつ設定されている。なお、図には、時間帯毎の予約枠の数が一つであることを意味する「１」をそれぞれ示している。本実施形態では、一つの時間帯に一つの予約枠を設定しているが、一つの時間帯に複数の予約枠を設定してもよい。院内端末１８から新たな予約情報が送信されることにより、その予約情報で指定された予約枠マスタ３５の時間帯に、その予約情報の予約ＩＤが記憶される。また、院外ＤＢ２６の登録テーブル３７（図３参照）の内容と同期が取られることにより、同期の取られた予約情報で指定された予約枠マスタ３５の時間帯に、同期の取られた予約情報の予約ＩＤが記憶される。
【００５１】
予約情報テーブル３６には、予約ＩＤ、患者ＩＤ、疾患名、検査の種類、予約枠ＩＤ、予約元ＩＤなどの情報が、受け付けた予約情報毎に記憶されている。詳しくは後述するように、予約情報テーブル３６は、データ２３、２７間の同期が取られ、データ２３の更新を確定（コミット）するように指示するコミット要求を受けることにより、登録テーブル３１の内容に基づいて更新される。予約情報は、予約情報テーブル３６に記憶されることで受付けが確定する。また、予約情報テーブル３６は、院外ＤＢ２６の登録テーブル３７（図３参照）の内容と同期が取られることにより更新される。
【００５２】
これら各マスタ３２〜３５、及び各テーブル３１、３６に記憶されている各情報は互いに紐付けされており、一方の情報から辿って他方の情報を知ることができる。例えば、予約枠マスタ３５と予約情報テーブル３６の予約情報とは、予約ＩＤで紐付けされている。
【００５３】
図３に示すように、院外ＤＢ２６には、中核病院１３毎の院外データ２７の他に、登録テーブル３７、患者マスタ３２、診療所マスタ３３、及び病院マスタ３８が格納されている。
【００５４】
登録テーブル３７には、院内ＤＢ２２の登録テーブル３１の内容に加え、予約先などの情報が、受け付けた予約情報毎に記憶されている。登録テーブル３７は、院外端末２４から新たな予約情報が送信されることにより更新される。
【００５５】
患者マスタ３２、診療所マスタ３３は、院内ＤＢ２２内の各マスタと同一の構成を有し、院外端末２４、院外サーバ２５のコンソール４７（図４参照）の操作に応じて各情報が更新される他は、院内ＤＢ２２内の各マスタと同一の作用であるため、説明を省略する。
【００５６】
病院マスタ３８には、病院ＩＤ、病院情報（名称、住所、連絡先）、営業時間、検査可能な疾患名などの情報が、中核病院１３毎に記憶されている。病院マスタ３８は、院外サーバ２６のコンソール４７（図４参照）を操作することで更新可能である。
【００５７】
院外データ２７は、予約枠マスタ３５、及び予約情報テーブル３９からなる。予約枠マスタ３５は、院内データ２３の予約枠マスタ３５と同一である。院外端末２４から新たな予約情報が送信されることにより、その予約情報で指定された予約枠マスタ３５の時間帯に、その予約情報の予約ＩＤが記憶される。また、院内ＤＢ２２の登録テーブル３１（図２参照）の内容と同期が取られることにより、同期の取られた予約情報で指定された予約枠３５の時間帯に、同期の取られた予約情報の予約ＩＤが記憶される。
【００５８】
予約情報テーブル３９には、院内ＤＢ２２の予約情報テーブル３６の内容に加え、予約先ＩＤなどの情報が、受け付けた予約情報毎に記憶されている。詳しくは後述するように、予約情報テーブル３９は、データ２３、２７間の同期が取られ、コミット要求を受けることにより、登録テーブル３７の内容に基づいて更新される。予約情報は、予約情報テーブル３９に記憶されることで受付けが確定する。
【００５９】
院内ＤＢ２２の場合と同様、これら各マスタ３２、３３、３５、３８、及び各テーブル３７、３９に記憶された各情報は互いに紐付けされている。
【００６０】
各端末１８、２４、及び各サーバ１９、２５、２８は、それぞれ、パーソナルコンピュータ、サーバ用コンピュータ、ワークステーションといったコンピュータをベースに構成されている。図４に示すように、各端末１８、２４、及び各サーバ１９、２５、２８には、オペレーティングシステムなどの制御プログラムや、アプリケーションプログラム（以下、ＡＰと略す。）４１がインストールされている。各サーバ１９、２５にインストールされているＡＰ４１には、予約受付サービスを提供する予約受付プログラムが含まれている。
【００６１】
各端末１８、２４、及び各サーバ１９、２５、２８は、ＣＰＵ４２、メモリ４３、ＨＤＤ（ハードディスクドライブ）４４、及び通信Ｉ／Ｆ（インターフェース）４５が設けられた本体４６と、コンソール４７とからなる。
【００６２】
ＨＤＤ４４には、制御プログラムや、ＡＰ４１が格納されている。メモリ４３は、ＣＰＵ４２が処理を実行するためのワークメモリである。ＣＰＵ４２は、ＨＤＤ４４に格納された制御プログラムをメモリ４３へロードして、プログラムに従った処理を実行することにより、コンピュータの各部を制御する。通信Ｉ／Ｆ４５は、ＬＡＮポート、ＷＡＮポート、ルータなどであり、ＬＡＮ１５、ＶＰＮ２９、あるいはインターネット１７に接続する通信ケーブルが接続される。通信Ｉ／Ｆ４５は、ＬＡＮ１５、ＶＰＮ２９、あるいはインターネット１７を経由したデータの遣り取りをする。
【００６３】
図５に示すように、各サーバ１９、２５のＣＰＵ４２は、それぞれ、ＨＤＤ４４から予約受付プログラムをロードして、プログラムに記述された処理ステップを実行する。これにより、院内サーバ１９のＣＰＵ４２には、予約受付処理部１９ａ、ＤＢアクセス部１９ｂ、同期処理部１９ｃ、及び回線監視部１９ｄが構築される。院外サーバ２５のＣＰＵ４２には、院内サーバ１９のＣＰＵ４２と同様の予約受付処理部２５ａ、ＤＢアクセス部２５ｂ、同期処理部２５ｃ、回線監視部２５ｄに加えて、予約枠制限部２５ｅが構築される。
【００６４】
各予約受付処理部１９ａ、２５ａは、予約受付端末１８又は２４とデータの遣り取りをする。具体的には、各予約受付処理部１９ａ、２５ａから予約受付端末１８、２４に送るデータは画面情報などであり、予約受付端末１８、２４から各予約受付処理部１９ａ、２５ａが受けるデータは予約情報などである。各予約受付処理部１９ａ、２５ａは、予約受付端末１８、２４から予約情報などを受け付けて、ＤＢアクセス部１９ｂ、２５ｂに引き渡す。各ＤＢアクセス部１９ｂ、２５ｂは、ＤＢ２２又は２６にアクセスして、予約受付処理部１９ａ、２５ａを介して取得した予約情報を元にデータ２３、２７を更新する。
【００６５】
各同期処理部１９ｃ、２５ｃは、ＬＡＮ１５やＶＰＮ２９を介して相互に通信して、各ＤＢ２２、２６内の各情報の同期を取る。以下、院内サーバ１９を主体として、予約枠の同期を取る場合について詳述する。
【００６６】
院内端末１８から予約情報を受け付けると、同期処理部１９ｃは、その予約情報で指定される予約枠及び予約ＩＤの情報を同期処理部２５ｃに送信する（以下、更新通知という。）。
【００６７】
同期処理部１９ｃからの更新通知が同期処理部２５ｃで受信されると、ＤＢアクセス部２５ｂは、院外ＤＢ２６の予約枠マスタ３５にアクセスして、更新通知で受けた予約枠が空いているか否かを調べる。予約枠が空いていた場合、ＤＢアクセス部２５ｂは、その予約枠に予約ＩＤを記憶させる。また、同期処理部２５ｃは、同期処理部１９ｃにコミット要求を送信する。
【００６８】
同期処理部２５ｃからのコミット要求が同期処理部１９ｃで受信されると、ＤＢアクセス部１９ｂは、院内端末１８から受け付けた予約情報を予約情報テーブル３６に記憶させ、受付けを確定させる。また、ＤＢアクセス部１９ｂは、院内ＤＢ２２の予約枠マスタ３５の、院内端末１８から受け付けた予約情報で指定された予約枠に、予約ＩＤを記憶させる。こうすることで、予約枠の同期が取られ、予約の重複（ダブルブッキング）が防止される。
【００６９】
一方、院外端末２４からも院内端末１８と略同時に同じ内容の予約情報が送信され、更新通知で受けた予約枠が埋まってしまった場合は、今度は逆に同期処理部２５ｃから同期処理部１９ｃに更新通知を送信する。この場合、ＤＢアクセス部１９ｂが予約枠に予約ＩＤを記憶させ、同期処理部１９ｃから同期処理部２５ｃにコミット要求を送信する。また、予約受付処理部１９ａは、予約枠が埋まって予約不可である旨を院内端末１８に送信する。その後の処理は、同期処理部２５ｃから同期処理部１９ｃにコミット要求を送信した場合と同様である。
【００７０】
なお、院外サーバ２５を主体とした場合は、各処理部の記載が逆になる他は同様の処理を実行するので、説明を省略する。また、予約情報は、予約枠の同期とは別のセッションで同期がとられるか、更新通知、コミット要求に予約情報を乗せて同じセッションで同期が取られる。但し、院外端末２４からされた予約情報を院内ＤＢ２２の予約情報テーブル３６に反映させることは必要であるが、院内端末１８からされた予約情報を院外ＤＢ２６の予約情報テーブル３９に反映させることは必要ではないため、院外端末２４からされた予約情報は院内ＤＢ２２の予約情報テーブル３６に反映されるが、院内端末１８からされた予約情報は院外ＤＢ２６の予約情報テーブル３９に反映されない。
【００７１】
各回線監視部１９ｄ、２５ｄは、それぞれ、中継サーバ２８を介して接続されたサーバ１９、２５の通信状況を監視し、その通信状況をＨＤＤ４４に格納されたログファイルにリアルタイムで記憶する。ログファイルには、接続時にはＯＫと記憶され、切断時にはＮＧと記憶される。ログファイルを参照することで、サーバ１９、２５間の通信状況、すなわち、データ２３、２７相互の予約枠の同期の状況を判断することができる。
【００７２】
予約枠制限部２５ｅは、ＨＤＤ４４に格納されたログファイルをリアルタイムで読み出して、予約枠の同期の状況を判断する。予約枠制限部２５ｅは、予約枠の同期が取れていない（各サーバ１９、２５の通信が途絶えた）と判断した場合、その時から所定期間、院外端末２４からの予約の受付けを不可とする。受付け不可とする予約の期間は、院内、院外ともに予約が集中し、院内、院外の予約情報のダブルブッキングが比較的高い確率で発生すると考えられる期間（例えば１週間）が予め定められる。予約枠制限部２５ｅは、予約枠の同期が取れるように各サーバ１９、２５の通信が回復するまで予約の制限を続け、通信が回復したら制限を解除する。なお、院内サーバ１９には予約枠制限部がないため、院内端末１８からの予約は制限されない。
【００７３】
予約枠の同期が取れていないときに受け付けた予約情報は、登録テーブル３１、３７に順次記憶される。予約枠の同期が取れるように各サーバ１９、２５の通信が回復すると、院内サーバ１９から院外サーバ２５に更新通知が送信される。院外端末２４からの予約が制限されている期間は、院内、院外の予約情報のダブルブッキングは発生しないため、各サーバ１９、２５は、コミット要求を送受信するまでもなく院内端末１８からの予約の受付けを確定する。
【００７４】
院外端末２４からの予約が制限されていない期間については、院内、院外の予約情報のダブルブッキングが発生する確率は比較的低いがゼロではない。予約が制限されていない期間で万が一ダブルブッキングが発生した場合は、データセンタ１２のオペレータが、確定する予約を院内、院外に適宜振り分け、予約が確定されなかった側の端末にその旨を通知するなどして対処する。
【００７５】
図６は、院内端末１８のモニタに表示される予約受付画面６１である。予約受付画面６１は、院内データ２３に基づいて作成される。院内データ２３は、ＨＴＭＬ形式やＸＭＬ形式などのマークアップ言語によって記述されたテキストファイルとして院内端末１８に配信される。院内端末１８にはブラウザがインストールされており、このブラウザが院内データ２３のテキストファイルの記述にしたがって、予約受付画面６１を構成してモニタに出力する。
【００７６】
予約受付画面６１には、予約枠とその予約状況をカレンダー形式で表示するとともに、申込みを受け付ける予約状況表示領域６２が設けられている。予約状況表示領域６２は、ＣＴ検査、ＭＲＩ検査、腹部エコー検査、アイソトープ検査、動脈硬化検査などの検査の種類毎に選択的に表示される。表示の切替えは、タブ６３によって行われる。図６では、ＣＴ検査が選択されている。
【００７７】
予約状況表示領域６２には、カレンダー形式で月単位の予約状況を一覧できる月別表示領域６４と、この月別表示領域６４で指定された１日分の予約状況を表示する日別表示領域６５とが設けられている。月別表示領域６４の予約枠に空きのある受付け可能な日は、無印で表示される。また、休日には「×」印が表示され、既に予約が埋まっている日にはハッチングが表示される。こうした表示により、予約ができる日とできない日が区別される。
【００７８】
月別表示領域６４内の所望の日をポインタ６６で指定してクリックすると、日別表示領域６５には、指定された日を含む数日間の予約枠６７が時間帯毎に表示される。受付け可能な予約枠６７には、予約ボタン６８が配されている。既に予約が埋まっている予約枠６７には、検査を受ける患者の氏名、及び予約元の名称（診療所１４の名称、診療科名）が表示されるとともに、申込みの詳細内容を表示するための詳細表示ボタン６９が配される。
【００７９】
予約ボタン６８をポインタ６６で指定してクリックすると、予約受付画面６１に切り替えて、図７に示すような、患者名などの申込みに必要な項目を入力する入力画面７１が表示される。入力画面７１には、予約受付画面６１で指定した検査の種類や予約枠の時間帯が表示されるとともに、患者名を入力するためのブランク７２、予め登録されたリストの中から疾患名を選択するためのポップアップメニュー７３、及び申込み内容を決定するための決定ボタン７４が配される。決定ボタン７４をポインタ６６で指定することで、入力画面７１に替えて、予約が受け付けられたか否かを表示する予約結果表示画面（図示省略）が表示される。
【００８０】
図８は、院外端末２４のモニタに表示される予約受付画面７８である。予約受付画面７８は、院外データ２７に基づいて作成され、予約受付画面６１と同様にしてモニタに出力される。予約受付画面７８は、中核病院１３を選択するポップアップメニュー７９が設けられ、患者の氏名や予約元の情報の代わりに、日別表示領域６５の予約枠に予約が埋まっているか否かを表示（予約が埋まっている場合は×、埋まっていない場合は予約ボタン６８を表示）する他は、予約受付画面６１と同様の構成である。
【００８１】
予約状況表示領域６２には、ポップアップメニュー７９で指定された中核病院１３の予約状況が表示される。ここでは、予約状況は図６と同一、現在の日付が１月１３日で、予約の申込み時に折悪しく各サーバ１９、２５の通信が途絶え、予約枠制限部２５ｅで予約枠を制限（例えば、１月１３日から１週間後の１月２０日まで予約枠の受付け不可）している状態を示す。
【００８２】
この場合、月別表示領域６４、日別表示領域６５の予約の受付けが制限されている日（１月１４日、１９日、２０日）に、休日と同じ「×」印が表示され、予約の受付けが不可である旨を通知する。例えば、日別表示領域６５の１月１９日の１０：３０〜、２０日の９：３０〜と１０：３０〜の予約枠は、図６ではいずれも予約ボタン６８が表示されて予約の受付けが可能となっているが、ここでは「×」印が表示される。予約を制限する期間以降（１月２１日以降）は、図６の表示と同じである。なお、予約ボタン６８を選択すると、図７の入力画面７１に表示される内容に加えて、ポップアップメニュー７９で選択された中核病院１３の名称が表示される。
【００８３】
［院内端末からの予約］
次に、中核病院１３に設置された院内端末１８から予約情報が入力された場合における予約受付システム１１の処理手順について、図９のフローチャートを参照しながら説明する。院内端末１８を操作してブラウザを起動すると、院内端末１８のモニタには、院内データ２３の内容を反映した予約受付画面６１（図６参照）が表示される。ユーザは、表示された予約受付画面６１に従ってポインタ６６を操作することで予約ボタン６８をクリックし、予約の申込みを開始する（ステップ（以下、Ｓと略す。）１１）。
【００８４】
予約ボタン６８がクリックされると、モニタには、予約受付画面６１に替えて入力画面７１（図７参照）が表示される。ユーザは、ポインタ６６などを操作することで予約に必要な項目を入力してから決定ボタン７４をクリックし、入力した内容で予約を申し込む。院内端末１８から申し込まれた予約情報は、ＬＡＮ１５を介して院内サーバ１９に送信される。
【００８５】
予約を申し込んでいる間に、他の院内端末１８から先行して予約が入り、予約枠が埋まってしまった場合（Ｓ１２でＮＯ）には、Ｓ１１でした予約は受け付けられない。モニタには、入力画面７１に替えて、予約が受け付けられなかった旨のメッセージなどが表示される（Ｓ１８）。
【００８６】
一方、予約を申し込んでいる間に、他の院内端末１８からの予約がなく、予約枠が埋まっていない場合（Ｓ１２でＹＥＳ）、院内サーバ１９のＤＢアクセス部１９ｂは、院内端末１８からの予約情報を登録テーブル３１に記憶させる（Ｓ１３）。
【００８７】
回線監視部１９ｄは、院内、院外の予約の同期の状況を監視している。予約の同期がとられている場合（Ｓ１４でＹＥＳ）、院内サーバ１９の同期処理部１９ｃは、院外サーバ２５の同期処理部２５ｃに更新通知を送信する（Ｓ１５）。
【００８８】
更新通知で送信した予約枠が空いていた場合、同期処理部１９ｃは、同期処理部２５ｃからコミット要求を受信する。一方、院外端末２４から先行して予約が入り、更新通知で送信した予約枠が埋まってしまった場合は、同期処理部１９ｃは、同期処理部２５ｃから予約情報付きの更新通知を受信する（Ｓ１６）。
【００８９】
次いで、ＤＢアクセス部１９ｂによって、前者の場合は院内端末１８から受け付けた予約情報が、後者の場合は院外端末２４から受け付けた予約情報が予約情報テーブル３６に記憶され、受付けが確定される（Ｓ１７）。
【００９０】
また、院内、院外それぞれの該当する予約枠に、予約ＩＤが記憶される。院内端末１８には、前者の場合は予約が受け付けられた旨、後者の場合は予約が受け付けられなかった旨のメッセージなどが表示される（Ｓ１８）。
【００９１】
予約の同期が取られている間は、次の予約を受け付けた時（Ｓ１９でＹＥＳ）に、以上の一連の処理を繰り返すことで、院内、院外で予約の受付け状況が共有される。
【００９２】
予約の同期が取れない場合（Ｓ１４でＮＯ）も同様に、予約情報の登録テーブル３１への記憶、及び院内端末１８への予約が受け付けられた旨のメッセージなどの表示（但し、予約が制限される期間のみ）はなされるが、更新通知やコミット要求の送受信は当然ながらできない。予約の同期が取れない間に受け付けた予約は、各サーバ１９、２５の通信が回復した時にまとめて更新通知がなされる。
【００９３】
［院外端末からの予約］
次に、診療所１４に設置された院外端末２４から予約情報が入力された場合における予約受付システム１１の処理手順について説明する。基本的な処理は、院内が院外に代わるだけで、院内端末１８からの予約時の処理と略同様である。但し、図１０のフローチャートに示すように、予約の同期が取れない場合（Ｓ２１）は、予約枠制限部２５ｅによって受付け可能な予約枠が制限される（Ｓ２２）。受付けが制限された予約枠は、予約受付画面７８上で「×」印が表示され、予約が不可となる。この予約枠制限部２５ｅによる予約の制限は、各サーバ１９、２５の通信が回復しない間（Ｓ２３でＮＯ）は続けられ、通信が回復したら（Ｓ２３でＹＥＳ）解除される（Ｓ２４）。
【００９４】
以上説明したように、予約枠の同期が取れなくなった場合に、院外で受付け可能な予約枠を制限することにより、受付けサービスを完全に停止することなくダブルブッキングを防止することができる。
【００９５】
より詳しくは、院外では所定期間の予約は制限されるものの、それ以降の予約については受付け可能であるため、受付けサービスを完全に停止させた場合よりも、ユーザにストレスを与えないで済む。院内では予約が制限されないので、同期が取れている通常の場合と同様の受付サービスを提供可能である。しかも、少なくとも予約を制限した期間は、ダブルブッキングは発生しない。
【００９６】
なお、上記実施形態では、予約枠の同期が取れなくなった場合に、院外からの予約を制限したが、これに代えて、あるいは加えて、院内からの予約を制限してもよい。この場合、院内サーバ１９のＣＰＵ４２にも予約枠制限部を構築させ、院外サーバ２６のＣＰＵ４２と同様の処理を実行させる。院内、院外両方で予約を制限する場合は、制限が解除されるまで、予約が制限される予約枠は空いてしまうが、同様の効果を得ることができる。
【００９７】
ダブルブッキングが発生する確率を減らすためには、予約を制限する期間を適当に定める必要がある。院内、院外からの予約は日々行われ、そのデータは院内ＤＢ、院外ＤＢに蓄積されている。この過去の予約実績を見れば、予約が集中する期間、すなわちダブルブッキングが発生する確率が高い期間を統計的に導き出すことができる。そこで、過去の予約実績に基づいて、予約枠を制限する期間を定めることが好ましい。
【００９８】
例えば、過去１週間、１箇月間、あるいは１年間の予約実績を各ＤＢから読み出して、予約が集中する期間とそうでない期間を解析する。そして、例えば、午前中は予約が集中するが、午後は予約がまばらな日は、午前中の予約を制限する。あるいは、週末は予約が集中するが、水曜日は集中しない週は、週末の予約枠を制限するなど、適宜予約枠を制限する期間を定める。こうすることで、上記実施形態のように一律に所定期間の予約を制限するよりも、予約を制限する期間の妥当性が増す。
【００９９】
また、上記実施形態では、一つの時間帯に一つの予約枠を設定した場合を説明したが、一つの時間帯に複数の予約枠が設定されている場合も適用可能である。この場合、予約を所定期間制限することに代えて、あるいは加えて、各時間帯の予約枠の個数を制限してもよい。例えば、一つの時間帯に五つの予約枠がある場合（図２の予約枠マスタ３５の予約枠の数が「５」の場合）、院内の受付け可能な予約枠を三つに、また、院外の受付け可能な予約枠を二つにそれぞれ制限する。
【０１００】
しかし、この場合は、制限された期間でダブルブッキングを完全に防止できるものの、制限が厳しく、医療検査装置の稼働率の低下を招くおそれがある。そこで、例えば、一つの時間帯に五つの予約枠がある場合、院内の受付け可能な予約枠を四つに、また、院外の受付け可能な予約枠を三つにそれぞれ制限する。このように、上記の場合と比較して制限を緩くすることで、制限された期間においてもダブルブッキングが発生するおそれはあるものの、医療検査装置の稼働率の低下を防止することができる。なお、制限する予約枠の数は、予め定めておいてもよいし、過去の予約実績に基づいて柔軟に定めるようにしてもよい。
【０１０１】
上記実施形態では、予約枠の同期が取れない間に受け付けた予約については、同期が取れるようになってからまとめて更新通知がなされるが、こうすると、同期が取れるようになるまで、予約が受け付けられたかどうかが分からない。そこで、予約枠の同期が取れないときに、予約が制限されていない期間に予約がされた場合、仮の予約受付けである旨のメッセージ画面を予約受付処理部から各端末に配信し、また、同期回復後に仮の予約が無効となった場合は、その旨のメッセージ画面を各端末に配信することが好ましい。予約が無効になる蓋然性を秘めていることを知らせることができ、予約が受け付けられたかどうかという不安を和らげることができる。なお、仮受付けとした場合、各サーバ１９、２５は、各端末１８、２４から受け付けた予約情報を、仮の予約情報として対応する登録テーブル３１、３７に記憶する。
【０１０２】
上記実施形態で述べた通り、予約が制限される期間は、ダブルブッキングは発生しないが、予約が制限されていない期間については、院内、院外の予約情報のダブルブッキングが発生するおそれがある。上記実施形態では、ダブルブッキングが発生した場合にはデータセンタ１２の運用でカバーする例を挙げたが、煩雑で面倒である。そこで、ダブルブッキングが発生した場合の対処として、以下の例を挙げる。
【０１０３】
ダブルブッキングが発生していた場合の対処の第一例は、予約情報の受付時刻に基づくものである。具体的には、院内、院外の予約情報のうち、各サーバ１９、２５への予約情報の受付時刻が早い方を正式の予約情報として受け付け、遅い方を無効にする。受付時刻が奇しくも同じ場合には、受付時刻に乱数を加算したもので同様に予約の有効、無効の判断をする。第二例は、院内、院外のうち、どちらを優先的に受け付けるかを予め指定しておき、この優先指定情報に基づいて行う。優先指定情報は、例えば院外サーバ２５のＨＤＤ４４に格納され、例えばデフォルトでは院内からの予約を優先する設定としておく。優先指定情報をコンソール４７からの入力によって変更可能としてもよい。
【０１０４】
いずれの例にしても、処理手順は図１１のフローチャートに示す通りである。すなわち、予約枠の同期が回復したとき（Ｓ３１）に、院内サーバ１９の同期処理部１９ｃから更新通知を受信した場合（Ｓ３２でＹＥＳ）、院外サーバ２５の同期処理部２５ｃは、予約が制限されていない期間について、更新通知と登録テーブル３７の予約情報とを照合し、ダブルブッキングが発生しているか否かを判定する。ダブルブッキングが発生していた場合（Ｓ３３でＹＥＳ）、同期処理部２５ｃは、予約情報の受付時刻、または優先指定情報に基づいて、院内、院外からの予約情報のうち、正式に受け付けるものと無効にするものを選別して、ダブルブッキングの解消処理を行う（Ｓ３４）。その後のＳ３５の同期処理は、上記実施形態と同様である。
【０１０５】
このように、予約を制限していない期間についても、手間を掛けずにダブルブッキングの発生を防止することができる。なお、ダブルブッキングが発生していた場合の対処としては、受付時刻や優先指定情報に関わらず、ランダムにいずれか一方を正式予約とし、他方を無効としてもよい。あるいは、例えば午前中は院内からの予約を優先し、午後は院外からの予約を優先するなど、ある期間毎に優先指定を変えてもよい。
【０１０６】
予約が無効とされた場合は再度予約を取り直さなければならないが、同期回復後に同期処理をした後は、当初予約をしようとしていた予約枠に加えて、他の予約枠も埋まっている公算が大きい。そこで、予約が無効とされた側に、これから予約を取るときに有用な情報を提供することが好ましい。
【０１０７】
具体的には、院外からの予約が無効となった場合、院外サーバ２５の予約受付処理部２５ａは、図１２に示す病院検索画面８１を院外端末２４に配信する。病院検索画面８１には、当初予定をしようとしていた予約枠の予約日時を検索キーとして、その予約日時で予約が可能な中核病院１３の名称がハイパーリンク８２で表示される。また、病院検索画面８１には、各中核病院１３の名称毎に表示されるチェックボックス８３と、選択された中核病院１３で予約を取るための決定ボタン８４とが配されている。いずれかのハイパーリンク８２をポインタ６６で指定することで、病院検索画面８１に替えて、指定された中核病院１３のホームページなどの詳細な情報が表示される。
【０１０８】
病院検索画面８１において、チェックボックス８３は択一的に選択可能であり、いずれかのチェックボックス８３をポインタ６６で指定することで、指定したチェックボックス８３に対応する中核病院１３が選択される。いずれかのチェックボックス８３が選択された後に決定ボタン８４をポインタ６６で指定することで、病院検索画面８１に替えて、予約が受け付けられたか否かを表示する予約結果表示画面（図示省略）が表示される。院外ＤＢ２６には、予約を無効とされた中核病院１３の他に、データセンタ１２に登録している他の複数の中核病院１３の予約状況が集約されているため、上記のような情報を提供することができる。
【０１０９】
なお、病院検索画面８１で別の中核病院１３で予約を取り直した際に、再びダブルブッキングが発生した場合は、これを無効にするとさらに検索の手間が掛かるため、無条件で取り直した方を正式予約とすることが好ましい。取り直しであることを示すフラグを予約情報に立てるなどして実現する。また、予約日時に代えて、あるいは加えて、診療所１４からの距離や患者の過去の通院履歴などで代替の中核病院１３を検索してもよい。
【０１１０】
上記実施形態では、予約を受け付けたときに予約枠の同期処理を行っているが、予約の受付け有無に関わらず、定期的に同期処理を行ってもよい。また、院内サーバと院外サーバに同期処理部などを設けているが、同期処理や回線監視、予約枠制限その他の役割を、中継サーバが担ってもよい。
【図面の簡単な説明】
【０１１１】
【図１】医療検査の予約受付システムの概略を示す構成図である。
【図２】院内ＤＢに格納されたデータの説明図である。
【図３】院外ＤＢに格納されたデータの説明図である。
【図４】各端末・各サーバの概略を示す構成図である。
【図５】各サーバに構築される機能の概略を示す構成図である。
【図６】院内端末のモニタに表示される予約受付画面を示す図である。
【図７】院内端末のモニタに表示される入力画面を示す図である。
【図８】院外端末のモニタに表示される予約受付画面を示す図である。
【図９】院内端末から予約を受け付けた場合における予約受付システムの処理手順を示すフローチャートである。
【図１０】同期が取れない時の処理手順を示すフローチャートである。
【図１１】同期が回復時の処理手順を示すフローチャートである。
【図１２】院外端末のモニタに表示される病院検索画面を示す図である。
【符号の説明】
【０１１２】
１１  予約受付システム
１３  中核病院（医療施設）
１９  院内サーバ
２２  院内データベース（院内ＤＢ）
２５  院外サーバ
２６  院外データベース（院外ＤＢ）
【図１】
2010152593.tif 000003
【図２】
2010152593.tif 000004
【図３】
2010152593.tif 000005
【図４】
2010152593.tif 000006
【図５】
2010152593.tif 000007
【図６】
2010152593.tif 000008
【図７】
2010152593.tif 000009
【図８】
2010152593.tif 000010
【図９】
2010152593.tif 000011
【図１０】
2010152593.tif 000012
【図１１】
2010152593.tif 000013
【図１２】
2010152593.tif 000014