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