(57)【特許請求の範囲】
【請求項１】
院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、医療検査の予約情報を蓄積する外部サーバに広域ネットワークで接続され、予約情報に基づいた予約状況を表すスケジュールデータの配信を外部サーバに対して要求し、配信要求に応じて外部サーバから配信されたスケジュールデータを受信するクライアント端末において、
自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行するサーバアクセス部と、
第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納するストレージ制御部と、
外部サーバとの通信障害の有無を監視する回線接続監視部と、
スケジュールデータに基づいた予約状況確認画面をディスプレイに表示させる表示制御部とを備え、
前記表示制御部は、前記回線接続監視部で通信障害が発見されない場合、第一スケジュールデータに基づいた第一予約状況確認画面を表示させ、通信障害が発見された場合、第二スケジュールデータに基づいた第二予約状況確認画面を、第一予約状況確認画面と区別可能に表示させることを特徴とする医療施設のクライアント端末。
【請求項２】
前記表示制御部は、第二スケジュールデータに基づくものであることを示すマークを第二予約状況確認画面に表示させることを特徴とする請求項１に記載の医療施設のクライアント端末。
【請求項３】
前記表示制御部は、第二予約状況確認画面を表示する際に、第二スケジュールデータに基づくものであることを示すメッセージを表示させることを特徴とする請求項１または２に記載の医療施設のクライアント端末。
【請求項４】
前記表示制御部は、第二スケジュールデータの取得日時を第二予約状況確認画面に表示させることを特徴とする請求項１ないし３のいずれかに記載の医療施設のクライアント端末。
【請求項５】
前記表示制御部は、第二配信要求の発行を開始する時刻を設定するためのウィンドウを表示させることを特徴とする請求項１ないし４のいずれかに記載の医療施設のクライアント端末。
【請求項６】
前記表示制御部は、前記サーバアクセス部に第二配信要求を発行させるか否かを設定するためのウィンドウを表示させることを特徴とする請求項１ないし５のいずれかに記載の医療施設のクライアント端末。
【請求項７】
前記表示制御部は、第一予約状況確認画面で操作入力を受付可能な領域を、第二予約状況確認画面では非アクティブ状態にして表示させることを特徴とする請求項１ないし６のいずれかに記載の医療施設のクライアント端末。
【請求項８】
院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、医療検査の予約情報を蓄積する外部サーバに広域ネットワークで接続され、予約情報に基づいた予約状況を表すスケジュールデータの配信を外部サーバに対して要求し、配信要求に応じて外部サーバから配信されたスケジュールデータを受信するクライアント端末において、
自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行するサーバアクセス部と、
第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納するストレージ制御部とを備え、
前記ストレージ制御部は、今回の第二配信要求から次回の第二配信要求の間に受信した第一スケジュールデータのうちの第二スケジュールデータに該当する部分を、今回の第二配信要求で得られた第二スケジュールデータと置き換えてストレージデバイスに格納することを特徴とする医療施設のクライアント端末。
【請求項９】
前記サーバアクセス部は、第二配信要求として、第二スケジュールデータそのものの配信を要求することを特徴とする請求項１ないし８のいずれかに記載の医療施設のクライアント端末。
【請求項１０】
前記サーバアクセス部は、第二配信要求として、第一配信要求と同じく第一スケジュールデータの配信を要求し、
前記ストレージ制御部は、第一スケジュールデータから第二スケジュールデータを生成し、これをストレージデバイスに格納することを特徴とする請求項１ないし８のいずれかに記載の医療施設のクライアント端末。
【請求項１１】
院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、医療検査の予約情報を蓄積する外部サーバに広域ネットワークで接続され、予約情報に基づいた予約状況を表すスケジュールデータの配信を外部サーバに対して要求し、配信要求に応じて外部サーバから配信されたスケジュールデータを受信するクライアント端末でスケジュールデータをバックアップする方法であって、
自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行するステップと、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納するステップと、
外部サーバとの通信障害の有無を監視する回線接続監視ステップと、
スケジュールデータに基づいた予約状況確認画面をディスプレイに表示する表示ステップとを備え、
前記表示ステップでは、前記回線接続監視ステップで通信障害が発見されない場合、第一スケジュールデータに基づいた第一予約状況確認画面を表示し、通信障害が発見された場合、第二スケジュールデータに基づいた第二予約状況確認画面を、第一予約状況確認画面と区別可能に表示することを特徴とする医療検査の予約のスケジュールデータバックアップ方法。
【請求項１２】
院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、医療検査の予約情報を蓄積する外部サーバに広域ネットワークで接続され、予約情報に基づいた予約状況を表すスケジュールデータの配信を外部サーバに対して要求し、配信要求に応じて外部サーバから配信されたスケジュールデータを受信するクライアント端末でスケジュールデータをバックアップする方法であって、
自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行するステップと、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納するステップであり、
今回の第二配信要求から次回の第二配信要求の間に受信した第一スケジュールデータのうちの第二スケジュールデータに該当する部分を、今回の第二配信要求で得られた第二スケジュールデータと置き換えてストレージデバイスに格納するステップとを備えることを特徴とする医療検査の予約のスケジュールデータバックアップ方法。
【請求項１３】
医療検査の予約情報を蓄積する外部サーバと、
前記外部サーバと広域ネットワークで接続され、院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、予約情報に基づいた予約状況を表すスケジュールデータの配信を前記外部サーバに対して要求する医療施設のクライアント端末とからなり、
前記外部サーバは、配信要求に応じて検索した予約情報を元にスケジュールデータを生成してこれを前記クライアント端末に配信し、
前記クライアント端末は、自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行し、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納し、外部サーバとの通信障害の有無を監視して、外部サーバとの通信障害が発見されない場合、第一スケジュールデータに基づいた第一予約状況確認画面をディスプレイに表示させ、通信障害が発見された場合、第二スケジュールデータに基づいた第二予約状況確認画面を、第一予約状況確認画面と区別可能にディスプレイに表示させることを特徴とする医療検査の予約受付システム。
【請求項１４】
医療検査の予約情報を蓄積する外部サーバと、
前記外部サーバと広域ネットワークで接続され、院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、予約情報に基づいた予約状況を表すスケジュールデータの配信を前記外部サーバに対して要求する医療施設のクライアント端末とからなり、
前記外部サーバは、配信要求に応じて検索した予約情報を元にスケジュールデータを生成してこれを前記クライアント端末に配信し、
前記クライアント端末は、自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行し、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納し、この際、今回の第二配信要求から次回の第二配信要求の間に受信した第一スケジュールデータのうちの第二スケジュールデータに該当する部分を、今回の第二配信要求で得られた第二スケジュールデータと置き換えてストレージデバイスに格納することを特徴とする医療検査の予約受付システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広域ネットワークを通じて外部サーバから医療検査の予約状況を表すスケジュールデータを受信する医療施設のクライアント端末、医療検査の予約のスケジュールデータバックアップ方法、並びに医療検査の予約受付システムに関する。
【背景技術】
【０００２】
最近、地域における医療施設間の医療連携を強化する必要性が高まっている。その一環として、診療所等の比較的小規模な医療施設からの医療検査の依頼を受け、地域内の中核病院等、高度な医療検査設備を持つ比較的大規模な医療施設が医療検査を実施することが行われている。特許文献１には、こうした医療連携サービスを提供するデータセンタを仲介として、医療施設間における医療検査の予約をオンラインで行うことができる医療検査の予約受付システムが開示されている。予約受付システムは、データセンタと、医療検査の依頼元、引受先の複数の医療施設とを、広域ネットワーク（ＷＡＮ）で相互に接続してなる。
【０００３】
特許文献２には、中核病院等の院内医療システムにおいて、医療検査の準備を滞りなく遂行するため、医療検査の予約情報を蓄積するＨＩＳサーバからＣＴ、ＭＲＩ等の医用検査装置に送る予約情報（医用検査装置でその日に実施する予定の予約情報）を、決められた時間に予め読み込んでおき、医用検査装置が予約情報を使用する際に予約情報を即座に提供することが記載されている。
【０００４】
特許文献３には、計算機のストレージに格納されているデータを保護するために、該データをバックアップするバックアップ機が開示されている。バックアップ機は、予め設定されたバックアップ条件に適合するデータのみをバックアップする。バックアップ機のバックアップストレージの容量を計算機のストレージの容量よりも小さくすることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３０１４３４号公報
【特許文献２】特開２００２−１５９４４９号公報
【特許文献３】特開２００６−１６３５６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１のような予約受付システムは、データセンタのサーバに複数の医療施設のクライアント端末がネットワーク接続された形態であり、サーバからのアプリケーションサービスの提供をクライアント端末で受けるＡＳＰ（アプリケーションサービスプロバイダ）型のネットワークシステムを構築している。こうした予約受付システムでは、医療検査の引受先である中核病院等の比較的大規模な医療施設は、院内のクライアント端末からネットワークを通じてデータセンタのサーバにアクセスして、自施設宛の医療検査の予約状況を表すスケジュールデータをデータセンタのサーバからダウンロードしている。そして、ダウンロードしたスケジュールデータを例えばカレンダー形式の画面でクライアント端末に出力させ、該画面を通して自施設宛の医療検査の予約状況を確認している。
【０００７】
この際、中核病院のクライアント端末とデータセンタのサーバを繋ぐネットワーク回線に通信障害が生じると、クライアント端末にスケジュールデータをダウンロードすることができず、従って予約状況を確認することもできなくなる。通信障害が復旧する時間は、一般的にはせいぜい１日以内で長期にわたることはないが、その間にも予約状況が確認できないと、予約済みの医療検査に関して患者や依頼元の診療所から予約日時の問い合わせがあったときや、院内の科、あるいはネットワーク経由以外（例えば電話）で診療所から新規の予約を申し込まれたときに即答ができない。また、医療検査に従事するスタッフが予約状況に応じて医療検査の準備をすることもできなくなり、患者、中核病院の双方が不利益を蒙る。
【０００８】
医療検査の予約情報には個人情報が含まれるので、情報セキュリティを確保するために、通信の有無に関わらず回線を占有する速度保証型の専用回線を使用することが好ましいが、専用回線は通信コストが高いため、現在の予約受付システムでは、情報セキュリティの確保と通信コストの抑制を考慮して、ＶＰＮといった回線共用型のＩＰネットワークをバックボーンネットワークとしたベストエフォート型の通信回線が使用されている。ベストエフォート型の通信回線は、速度保証型の専用線と比較して、通信障害の発生頻度が高い。このため、通信障害が発生した場合でも予約状況を確認することが可能な方策が熱望されている。
【０００９】
特許文献２に記載の発明は、院内ＬＡＮ等の比較的通信障害が発生しにくい通信回線を用いた院内医療システムを対象としており、システムの形態が異なるうえ、そもそもネットワーク回線の通信障害による上記の問題を想定していない。また、予約受付システムでは、予約状況が時々刻々と変わり、その都度予約状況を確認する必要があるが、特許文献２では決められた時間に予約情報を読み込んでいるだけで、その対策も講じていない。
【００１０】
通信障害が発生した場合でも予約状況の確認を可能とする方策としては、予約状況を確認した際にダウンロードしたスケジュールデータを、クライアント端末のストレージデバイスに手動でバックアップすることが考えられるが、手動バックアップは煩雑であり、バックアップのし忘れも起こり兼ねない。また、予約状況の確認は不定期に行われるため、前回から次回の確認の間が空いてバックアップしたスケジュールデータと実際の予約状況とに大きな乖離が生じることがあり、この場合はバックアップの意味がない。
【００１１】
もう一つの方策としては、特許文献３に記載の発明の如く、一般的なコンピュータシステムのサーバで行われているバックアップ技術を適用し、データセンタのサーバから中核病院のクライアント端末に自施設宛の医療検査のスケジュールデータを定期的にバックアップすることが考えられる。しかしながら、特許文献３のバックアップ装置は、バックアップ条件に合ったデータを全てバックアップするので、バックアップストレージの容量をそれなりに確保しなければならない。また、バックアップするデータの容量そのものが大きい場合の対処については何ら考慮されていない。
【００１２】
クライアント端末は汎用のパーソナルコンピュータをベースにしているため、大容量のストレージデバイスや専用のバックアップストレージをスケジュールデータのバックアップのためだけに設けることは現実的ではなく、もし実現したとしても設備費用の大幅な増大に繋がる。
【００１３】
以上述べた通り、特許文献２、３に記載の発明は、いずれもＡＳＰ型のネットワークシステムである予約受付システムとは明らかに形態が異なる。また、特許文献３は、一般的なコンピュータシステムのサーバで行われているバックアップ技術であり、サーバのデータをクライアント端末にバックアップするという発想は皆無である。しかも、いずれの文献もバックアップ用のストレージデバイスのデータ容量が圧迫されることを回避する有効な方策はない。
【００１４】
本発明は、上記背景を鑑みてなされたものであり、その目的は、設備費用の増大を抑えつつ、ネットワーク回線の通信状態に左右されずに最低限必要な予約状況を確認可能とすることにある。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明の医療施設のクライアント端末は、院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、医療検査の予約情報を蓄積する外部サーバに広域ネットワークで接続され、予約情報に基づいた予約状況を表すスケジュールデータの配信を外部サーバに対して要求し、配信要求に応じて外部サーバから配信されたスケジュールデータを受信するクライアント端末において、自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行するサーバアクセス部と、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納するストレージ制御部とを備えることを特徴とする。
【００１６】
前記サーバアクセス部は、第二配信要求として、第二スケジュールデータそのものの配信を要求する。あるいは、第一配信要求と同じく第一スケジュールデータの配信を要求してもよい。後者の場合、前記ストレージ制御部は、第一スケジュールデータから第二スケジュールデータを生成し、これをストレージデバイスに格納する。
【００１７】
外部サーバとの通信障害の有無を監視する回線接続監視部と、スケジュールデータに基づいた予約状況確認画面をディスプレイに表示させる表示制御部とを備えることが好ましい。前記表示制御部は、前記回線接続監視部で通信障害が発見されない場合、第一スケジュールデータに基づいた第一予約状況確認画面を表示させ、通信障害が発見された場合、第二スケジュールデータに基づいた第二予約状況確認画面を表示させる。
【００１８】
前記表示制御部は、第一、第二予約状況確認画面をそれぞれ区別可能に表示させる。例えば、画面の表題やレイアウトを変更したり、マークを表示したり、第二予約状況確認画面を表示する際にポップアップウィンドウ等で警告表示したりする。第二スケジュールデータの取得日時を第二予約状況確認画面に表示させてもよい。
【００１９】
前記表示制御部は、第二配信要求の発行を開始する時刻を設定するためのウィンドウや、前記サーバアクセス部に第二配信要求を発行させるか否かを設定するためのウィンドウを表示させる。
【００２０】
また、前記表示制御部は、第一予約状況確認画面で操作入力を受付可能な領域を、第二予約状況確認画面では非アクティブ状態にして表示させる。
【００２１】
前記ストレージ制御部は、今回の第二配信要求から次回の第二配信要求の間に受信した第一スケジュールデータのうちの第二スケジュールデータに該当する部分を、今回の第二配信要求で得られた第二スケジュールデータと置き換えてストレージデバイスに格納する。
【００２２】
本発明の医療検査の予約のスケジュールデータバックアップ方法は、院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、医療検査の予約情報を蓄積する外部サーバに広域ネットワークで接続され、予約情報に基づいた予約状況を表すスケジュールデータの配信を外部サーバに対して要求し、配信要求に応じて外部サーバから配信されたスケジュールデータを受信するクライアント端末でスケジュールデータをバックアップする方法であって、自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行するステップと、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納するステップとを備えることを特徴とする。
【００２３】
本発明の医療検査の予約受付システムは、医療検査の予約情報を蓄積する外部サーバと、前記外部サーバと広域ネットワークで接続され、院外からの医療検査の予約を受託する医療施設に設置されるクライアント端末であり、予約情報に基づいた予約状況を表すスケジュールデータの配信を前記外部サーバに対して要求する医療施設のクライアント端末とからなり、前記外部サーバは、配信要求に応じて検索した予約情報を元にスケジュールデータを生成してこれを前記クライアント端末に配信し、前記クライアント端末は、自施設宛の全予約情報を対象とした第一スケジュールデータの配信を操作指示に応じて要求する第一配信要求に加えて、第二配信要求を操作指示に関わらず定期的に発行し、第二配信要求によって得られ、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを順次更新しつつストレージデバイスに格納することを特徴とする。
【発明の効果】
【００２４】
本発明によれば、操作指示に関わらず第二配信要求を外部サーバに定期的に発行して、配信要求時を基点とする将来の一定期間の予約情報に基づいた第二スケジュールデータを得て、これを順次更新しつつストレージデバイスに格納するので、設備費用の増大を抑えつつ、ネットワーク回線の通信状態に左右されずに最低限必要な予約状況を確認することができる。
【図面の簡単な説明】
【００２５】
【図１】医療検査の予約受付システムの概略を示す構成図である。
【図２】診療所からの予約情報の内容を示す説明図である。
【図３】院内、診療所の端末と院内、センタ、中継サーバの基本構成を示す図である。
【図４】院内端末、センタサーバのＣＰＵに構築される機能部を示す図である。
【図５】第一予約状況確認画面の例を示す図である。
【図６】第一配信要求を配信したときの各機能部の処理を示す図である。
【図７】第二配信要求を配信したときの各機能部の処理を示す図である。
【図８】第二予約状況確認画面の例を示す図である。
【図９】院内端末の処理手順を示すフローチャートである。
【図１０】第二予約状況確認画面を表示する際にポップアップウィンドウを表示する例を示す図である。
【図１１】第一予約状況確認画面から第二予約状況確認画面にワンクリックで表示遷移するためのボタンを配した例を示す図である。
【図１２】バックアップ条件設定ウィンドウを示す図である。
【発明を実施するための形態】
【００２６】
図１において、予約受付システム２は、データセンタ１０と、複数の医療施設に設置されたコンピュータシステムとを通信ネットワークで接続し、オンラインで医療検査の予約受付を行うものである。データセンタ１０は、複数の医療施設のコンピュータ同士をネットワークで結び、オンライン予約サービスを提供するＡＳＰ（アプリケーションサービスプロバイダ）型のネットワークシステムを構築する。
【００２７】
複数の医療施設には、中核病院１１と診療所１２がある。中核病院１１は、その地域内で比較的大規模な医療施設である。中核病院１１は、ＣＴ（Computed Tomography）装置やＭＲＩ（Magnetic Resonance Imaging）装置等の高度な医療検査装置を保有し、院内の診療科だけでなく、診療所１２等の外部の医療施設から医療検査依頼を受ける。診療所１２は、高度な医療検査装置を持たず、中核病院１１へ医療検査を依頼する。
【００２８】
中核病院１１には、院内の各種のコンピュータをＬＡＮ（Local Area Network）１３で接続した院内情報システム（ＨＩＳ；Hospital Information System）１４が構築されている。院内情報システム１４は、医療検査の予約受付処理、診療受付処理、会計処理等の院内の情報処理を行う。ＬＡＮ１３は、院内に敷設されたネットワークであり、院内情報システム１４は、インターネット１５等、不特定多数の利用者に開放された公衆系の外部ネットワークと遮断されている。これにより、外部からの不正なアクセス等の情報セキュリティリスクを回避している。
【００２９】
院内情報システム１４では、院内の各診療科に設置された端末（以下、院内端末という）１６からＬＡＮ１３を通じてオンラインで医療検査の予約ができる。院内情報システム１４の院内サーバ１７は、こうした予約を受け付けて、医療検査のスケジュール管理を行う。
【００３０】
院内端末１６は、院内サーバ１７と通信するためのブラウザソフトがインストールされたパーソナルコンピュータであり、院内サーバ１７と通信を行って、受信した予約状況をディスプレイに表示したり、予約情報の送信を行う。
【００３１】
中核病院１１は、各診療所１２からの医療検査の依頼を受けて、医療検査を実施する。データセンタ１０は、中核病院１１の医療検査の受付窓口になっており、各診療所１２に設置された端末（以下、診療所端末という）１８から、インターネット１５を通じてオンラインで医療検査の予約を受け付ける。以下、院内情報システム１４で行われる医療検査の予約（院内予約）と区別するため、診療所端末１８からの医療検査の予約を院外予約と表記する。
【００３２】
データセンタ１０は、センタサーバ１９、および予約情報データベース（以下、予約情報ＤＢと略す）２０を備えている。センタサーバ１９は、ＷＥＢサーバとして機能し、インターネット上で標準的に用いられるドキュメントシステム（ＷＷＷ：World Wide Web）に対応する。センタサーバ１９は、クライアント端末である診療所端末１８からの要求に応答してデータを送信する。診療所端末１８は、ブラウザソフトがインストールされたパーソナルコンピュータであり、センタサーバ１９へのアクセスが可能である。
【００３３】
予約情報ＤＢ２０には、院外予約の予約情報２１が格納されている。センタサーバ１９は、診療所端末１８からのアクセスを受け付けて、予約情報２１に基づいて、診療所端末１８へ予約状況を報せる。そして、診療所端末１８からの予約を受け付けて予約情報２１を更新する。また、センタサーバ１９は、院内端末１６からの要求に応じて、院内端末１６にも同様にして院外予約の状況を報せる（ともに図２参照）。
【００３４】
図２に示すように、診療所端末１８からの一件の予約情報２１には、検査の種類・目的、日付と時間帯で指定される受診日時（予約枠）、患者名、性別、年齢・生年月日、傷病名、予約受付日時等の情報が含まれる。また、検査の依頼先として指定された中核病院１１のＩＤ、および予約元の情報として診療所１２のＩＤが付される。予約枠は、例えば９：００〜、９：３０〜等、３０分間隔で区切られた時間帯毎に一つずつ設定されている（図５も参照）。予約受付日時は、診療所端末１８からの予約情報をセンタサーバ１９で受け付けた時刻であり、センタサーバ１９によって付される。
【００３５】
なお、図示は省略したが、院内サーバ１７にもセンタサーバ１９と同様に予約情報ＤＢが接続されている。但し、この予約情報ＤＢには、院外予約の予約情報２１が格納される予約情報ＤＢ２０とは違い、院内端末１６から受け付けた院内予約の予約情報が格納される。中核病院１１のスタッフは、院内、院外の各予約情報に基づいた予約状況を院内端末１６で確認・照合し、ダブルブッキングがないよう医療検査のスケジュールを調整して、院外予約を院内サーバ１７の予約情報ＤＢに反映させる。
【００３６】
図１に戻って、中継サーバ（ゲートウェイ）２２は、ＬＡＮ１３、ＶＰＮ（Virtual Private Network）２３といった異なるネットワークを介して接続される院内サーバ１７とセンタサーバ１９との間で各種情報を中継する。中継サーバ２２は、各サーバ１７、１９間の通信におけるデータフォーマット変換、プロトコル変換を行うとともに、外部から院内情報システム１４への不正アクセスを防止するファイヤーウォールとして機能する。
【００３７】
中継サーバ２２とセンタサーバ１９は、回線共用型のＩＰネットワークをバックボーンネットワークとしたベストエフォート型の通信回線であるＶＰＮ２３を介して接続される。ＶＰＮ２３では暗号化技術が使われており、複数の利用者によって共有される共有ネットワーク内に論理的な専用通信チャンネルが確立される。これにより、通信拠点間の機密性が保持され、ネットワーク内の堅固な情報セキュリティが確保される。
【００３８】
各端末１６、１８、および各サーバ１７、１９、２２は、それぞれ、パーソナルコンピュータ、サーバ用コンピュータ、ワークステーションといったコンピュータをベースに構成されている。図３に示すように、各端末１６、１８、および各サーバ１７、１９、２２には、オペレーティングシステム等の制御プログラムや、アプリケーションプログラム（以下、ＡＰと略す）３５がインストールされている。各サーバ１７、１９にインストールされているＡＰ３５には、予約受付サービスを提供する予約受付プログラムが含まれている。
【００３９】
各端末１６、１８、および各サーバ１７、１９、２２は、ＣＰＵ３６、メモリ３７、ストレージデバイス３８、および通信Ｉ／Ｆ（インターフェース）３９、およびコンソール４０を備えている。これらはデータバス４１を介して相互接続されている。
【００４０】
ストレージデバイス３８は、例えば、ＨＤＤ（Hard Disk Drive）である。ストレージデバイス３８には、制御プログラムやＡＰ３５が格納される。
【００４１】
メモリ３７は、ＣＰＵ３６が処理を実行するためのワークメモリである。ＣＰＵ３６は、ストレージデバイス３８に格納された制御プログラムをメモリ３７へロードして、プログラムに従った処理を実行することにより、コンピュータの各部を制御する。
【００４２】
通信Ｉ／Ｆ３９は、ＬＡＮポート、ＷＡＮポート、ルータ等であり、ＬＡＮ１３、ＶＰＮ２３、あるいはインターネット１５といったネットワークに接続する通信ケーブルが接続される。通信Ｉ／Ｆ３９は、ＬＡＮ１３、ＶＰＮ２３、あるいはインターネット１５を経由したデータの遣り取りをする。コンソール４０は、ディスプレイ４２と、キーボードやマウス、マイクロホン等の入力デバイス４３とからなる。
【００４３】
院内端末１６およびセンタサーバ１９のＣＰＵ３６は、それぞれ、ストレージデバイス３８から予約受付プログラムをロードして、プログラムに記述された処理ステップを実行する。これにより、院内端末１６およびセンタサーバ１９のＣＰＵ３６には、図４に示す各部がそれぞれ構築される。
【００４４】
図４において、院内端末１６のＣＰＵ３６は、サーバアクセス部１６ａ、コンソール制御部１６ｂ、ストレージ制御部１６ｃ、および回線接続監視部１６ｄとして機能する。サーバアクセス部１６ａは、センタサーバ１９に院外予約の状況を確認するための予約状況配信要求等を送信するとともに、センタサーバ１９から予約状況を表すスケジュールデータ等を受信する。なお、院内端末１６とセンタサーバ１９との通信は、実際には中継サーバ２２を介して行われるが、説明を簡単化するため省略している。
【００４５】
コンソール制御部１６ｂは、第一予約状況確認画面（図５参照）５０等の各種操作画面をディスプレイ４２に出力し、操作画面を通じて入力デバイス４３からの操作指示の入力を受け付ける。ストレージ制御部１６ｃは、ストレージデバイス３８へのデータの格納、およびストレージデバイス３８からのデータの読出し制御を行う。サーバアクセス部１６ａで受信した各種データは、このストレージ制御部１６ｃを介してストレージデバイス３８に格納される。
【００４６】
回線接続監視部１６ｄは、サーバアクセス部１６ａの送受信状況に基づき、院内端末１６とセンタサーバ１９との通信障害の有無を監視する。具体的には、サーバアクセス部１６ａからセンタサーバ１９に向けて何らかの配信要求を送ったときに、その応答が返ってきたか否かによって通信障害の有無を判断する。回線接続監視部１６ｄは、何らかの不具合で院内端末１６とセンタサーバ１９間の回線に通信障害が発生したときに、その旨を示す信号をコンソール制御部１６ｂ、およびストレージ制御部１６ｃに送信する。
【００４７】
センタサーバ１９のＣＰＵ３６は、要求受付／配信部１９ａ、および要求処理部１９ｂとして機能する。要求受付／配信部１９ａは、院内端末１６からの予約状況の配信要求等を受信する。要求処理部１９ｂは、要求受付／配信部１９ａが受け付けた配信要求に応じた処理を実行する。具体的には、要求元の院内端末１６がある中核病院１１向けの予約情報２１を、中核病院１１のＩＤをキーとして予約情報ＤＢ２０から検索する。そして、検索した予約情報２１に基づいて、ＨＴＭＬ形式やＸＭＬ形式などのマークアップ言語によって記述された、予約状況を表すスケジュールデータを生成する。要求受付／配信部１９ａは、要求処理部１９ｂで生成したスケジュールデータ等を要求元の院内端末１６に配信する。
【００４８】
院内端末１６のサーバアクセス部１６ａは、予約状況配信要求の応答としてセンタサーバ１９の要求受付／配信部１９ａからスケジュールデータを受信する。コンソール制御部１６ｂは、サーバアクセス部１６ａで受信したスケジュールデータの記述に従って、例えば図５に示すカレンダー形式の第一予約状況確認画面５０を構成してディスプレイ４２に出力する。
【００４９】
図５において、第一予約状況確認画面５０は、ＣＴ検査、ＭＲＩ検査等の検査の種類毎に予約状況を選択的に表示する。種類毎の予約状況の表示は、タブ５１をポインタ５２で選択することで切り替わる。
【００５０】
第一予約状況確認画面５０には、カレンダー形式で月単位の予約状況を一覧できる月別表示領域５３と、この月別表示領域５３で指定された１日分の予約状況を表示する日別表示領域５４とが設けられている。月別表示領域５３の無印の日は、予約枠に空きのある日を表す。また、「×」印の日は過日および中核病院１１の休診日を表し、ハッチングされている日は既に予約が埋まっている日を表す。
【００５１】
月別表示領域５３内の所望の日をポインタ５２で選択すると、指定された日を含む数日間の予約枠５５が時間帯毎に日別表示領域５４に表示される。受付け可能な予約枠５５には、「空き」の文字が表示される。既に予約が埋まっている予約枠５５には、検査を受ける患者の氏名、および予約元の診療所１２の名称が表示されるとともに、予約の詳細な内容を表示するための詳細表示ボタン５６が配される。
【００５２】
院内端末１６からセンタサーバ１９に送信する予約状況配信要求には、入力デバイス４３の操作指示に応じた不定期なもの（以下、第一配信要求という）と、操作指示に関わらず定期的に送信するもの（以下、第二配信要求という）とがある。第二配信要求は、例えば予約枠の区切りの時間毎（本例では３０分毎）に送信される。
【００５３】
図６に示すように、第一配信要求を要求受付／配信部１９ａで受信した場合、要求処理部１９ｂは、要求元の院内端末１６がある中核病院１１向けの全ての予約情報２１を予約情報ＤＢ２０から検索し、検索した予約情報２１を元に前述のスケジュールデータ（以下、第一スケジュールデータという）を生成する。院内端末１６のサーバアクセス部１６ａは、この第一スケジュールデータを受信してストレージ制御部１６ｃに受け渡す。ストレージ制御部１６ｃは、第一スケジュールデータをストレージデバイス３８に格納する。
【００５４】
ストレージ制御部１６ｃは、入力デバイス４３を介した第一予約状況確認画面５０の起動指示に応じて第一スケジュールデータをストレージデバイス３８から読み出し、コンソール制御部１６ｂに受け渡す。コンソール制御部１６ｂは、第一スケジュールデータに従って図５の第一予約状況確認画面５０をディスプレイ４２に表示させる。第一スケジュールデータは、第一予約状況確認画面５０が閉じられたときにストレージデバイス３８から自動的に削除される。
【００５５】
一方、予約状況配信要求のうち、定期的に送信される第二配信要求を要求受付／配信部１９ａで受信した場合、図７に示すように、要求処理部１９ｂは、要求元の院内端末１６がある中核病院１１向けの予約情報２１のうち、配信要求を受信した時刻を基点とする将来の一定期間の予約情報２１、例えばその当日の配信要求を受信した時刻以降と翌日の全ての予約情報２１を元にスケジュールデータ（以下、第二スケジュールデータという）を生成する。
【００５６】
第二スケジュールデータは、生成元の予約情報２１の期間が制限されているため、全予約情報２１を生成元とする第一スケジュールデータよりも当然ながらデータ容量が小さい。第二スケジュールデータは、定期的に送信される第二配信要求に応じて生成されるので、院内端末１６とセンタサーバ１９間の回線接続に支障がない限り、要求受付／配信部１９ａからサーバアクセス部１６ａに定期的に送られてくる。また、第二スケジュールデータは、第一スケジュールデータの場合と異なり、第二予約状況確認画面６０（図８参照）が閉じられたときに削除はされない。
【００５７】
ストレージ制御部１６ｃは、古い第二スケジュールデータを削除して新しい第二スケジュールデータに順次更新しつつ第二スケジュールデータをストレージデバイス３８に格納する。ストレージ制御部１６ｃは、院内端末１６とセンタサーバ１９間の回線に通信障害が発生した旨の信号を回線接続監視部１６ｄから受信し、且つ予約状況確認画面の起動指示があった場合、第二スケジュールデータをストレージデバイス３８から読み出し、コンソール制御部１６ｂに受け渡す。
【００５８】
コンソール制御部１６ｂは、図８に示す第二予約状況確認画面６０をディスプレイ４２に表示させる。第二予約状況確認画面６０は、図５の第一予約状況確認画面５０と異なり、表題が「予約スケジュール（臨時）」となっており、また、「バックアップデータ参照中」（バックアップデータは第二スケジュールデータと同意）なるメッセージ６１が表示され、この第二予約状況確認画面６０が第二スケジュールデータに従って作成されたものであることを明示している。さらには、月別表示領域５３の下方に第二スケジュールデータの取得日時を示すメッセージ６２が表示される。
【００５９】
月別表示領域５３は、表示はされているが選択不可の非アクティブ状態であり、日別表示領域５４は、第二スケジュールデータで包含されている予約枠（本例では２０１０年１月１９日の１０：００以降の予約枠と１月２０日の全予約枠）以外はハッチングで示すように非表示となる。
【００６０】
以下、図９のフローチャートを参照して、院内端末１６で院外予約の状況を確認する際の処理を説明する。Ｓ（ステップ）１０において、中核病院１１のスタッフにより入力デバイス４３を介して予約状況確認画面の起動指示がされたとき、院内端末１６とセンタサーバ１９間の回線に通信障害が発生した旨の信号が回線接続監視部１６ｄから出力されていない場合、すなわち院内端末１６とセンタサーバ１９間の回線が支障なく接続されている場合（Ｓ１１でＮＯ）、サーバアクセス部１６ａからセンタサーバ１９の要求受付／配信部１９ａに予約状況配信要求（第一配信要求）がなされる。
【００６１】
センタサーバ１９では、要求処理部１９ｂにて第一スケジュールデータが生成され、要求受付／配信部１９ａからサーバアクセス部１６ａに第一スケジュールデータが配信される。
【００６２】
サーバアクセス部１６ａで受信された第一スケジュールデータは、ストレージ制御部１６ｃによってストレージデバイス３８に格納される（Ｓ１２、ＤＬはダウンロードの意）。そして、コンソール制御部１６ｂにより第一スケジュールデータに基づいた第一予約状況確認画面５０がディスプレイ４２に表示される（Ｓ１３）。予約状況の確認後、第一予約状況確認画面５０が閉じられると、第一スケジュールデータがストレージデバイス３８から自動的に削除される。
【００６３】
一方、予約状況確認画面の起動指示がされたときに院内端末１６とセンタサーバ１９間の回線に通信障害が発生した旨の信号が回線接続監視部１６ｄから出力された場合（Ｓ１１でＹＥＳ）、ストレージ制御部１６ｃによってストレージデバイス３８から第二スケジュールデータが読み出され（Ｓ１４）、コンソール制御部１６ｂに第二スケジュールデータが受け渡される。そして、コンソール制御部１６ｂにより第二スケジュールデータに基づいた第二予約状況確認画面６０がディスプレイ４２に表示される（Ｓ１５）。
【００６４】
以上説明したように、直近の院外予約の状況を表す第二スケジュールデータを定期的に配信要求してこれを順次更新しつつ格納し、院内端末１６とセンタサーバ１９間の通信障害が発生したときに、第二スケジュールデータを元に第二予約状況確認画面６０を表示するので、通信障害によって中核病院１１の業務に支障が出ることを防ぐことができる。
【００６５】
院内端末１６とセンタサーバ１９間に通信障害が発生し、これにより予約状況が確認できないと、予約済みの医療検査に関して患者や依頼元の診療所１２から予約日時の問い合わせがあったときや、院内の科、あるいはネットワーク経由以外で診療所１２から新規の予約を申し込まれたときに対応することができない。また、医療検査に従事するスタッフが予約状況に応じて医療検査の準備をすることもできなくなる。本発明によれば、こうした懸念を払拭することができ、患者、ひいては中核病院１１に利益をもたらす。
【００６６】
第二スケジュールデータは、要求元の院内端末１６がある中核病院１１向けの予約情報２１の一部を元に生成されるため、第一スケジュールデータよりもデータ容量が小さい。また、第二スケジュールデータは、常に新しい第二スケジュールデータに更新されて古い第二スケジュールデータが残ることはない。従って、第二スケジュールデータの記憶容量でストレージデバイス３８の容量を圧迫するおそれがない。裏返せば、専用のバックアップストレージや大容量のストレージデバイス３８を必要としない。設備費用の増大を抑えることができる。
【００６７】
センタサーバ１９等のサーバのデータを専用のバックアップストレージを有する別のサーバにバックアップすることは一般的に行われているが、本発明のように、ＡＳＰ型のネットワークシステムである予約受付システムにおいて、サーバのデータをクライアント端末にバックアップするという概念は非常に稀であり独創的である。
【００６８】
上記実施形態では、センタサーバ１９の要求処理部１９ｂで第二スケジュールデータの元となる予約情報２１を検索し、センタサーバ１９側で第二スケジュールデータを生成しているが、第二配信要求を第一配信要求と同じ内容とし、第二配信要求で第一スケジュールデータを受信して、ストレージ制御部１６ｃにより、受信した第一スケジュールデータから第二スケジュールデータに該当する予約情報２１を抜き出して第二スケジュールデータを生成してもよい。こうすれば、各配信要求は、不定期と定期的の配信タイミングが異なるだけで同じ内容とすることができる。但し、上記のように院内端末１６側で第二スケジュールデータを生成するよりは、センタサーバ１９側で第二スケジュールデータを生成して配信するほうが、ネットワーク負荷が少ないためより好ましい。なお、院内端末１６側で第二スケジュールデータを生成する場合は、センタサーバ１９から配信するデータは第一スケジュールデータに限らず、第二スケジュールデータの元となる予約情報２１を含んでいればよい。
【００６９】
上記実施形態では、院内予約と院外予約のスケジュール調整を中核病院１１のスタッフが手動で行っているが、これをセンタサーバ１９あるいは院内サーバ１７に担わせて自動化してもよい。
【００７０】
院内端末１６に予約情報の編集機能をもたせてもよい。このような構成とした場合、院内端末１６とセンタサーバ１９間で通信障害が発生したときには、当然ながら院内端末１６で予約情報を編集することは不可能になるので、例えば第二予約状況確認画面６０の「空き」の予約枠５５を、月別表示領域５３と同様に選択不可の非アクティブ状態とするか、選択はできても院内予約の受付はできなくする等、院内端末１６で編集可能な領域の操作入力を無効にすることが好ましい。
【００７１】
第一スケジュールデータと第二スケジュールデータを元にした予約状況確認画面をそれぞれ区別するため、上記実施形態では予約状況確認画面の表題を変えたり、メッセージを表示したり、月別表示領域、日別表示領域の表示の仕方を変えているが、本発明はこれに限定されない。図１０に示すように、第二スケジュールデータを元に第二予約状況確認画面６０を表示する際に、ポップアップウィンドウ７０で第二予約状況確認画面６０が第二スケジュールデータを元にしたものであるというメッセージを報せてもよい。
【００７２】
第一予約状況確認画面５０を表示中に院内端末１６とセンタサーバ１９間で通信障害が発生した場合は、第一予約状況確認画面５０を閉じた後、再び予約状況確認画面の起動指示をすれば第二予約状況確認画面６０を表示させることができる。あるいは、図１１に示すように、第二予約状況確認画面６０にワンクリックで表示遷移させるための専用ボタン７５を、第一予約状況確認画面５０に設けてもよい。操作の手間を省くことができる。
【００７３】
さらには、第一予約状況確認画面５０を表示中に通信障害が発生したときに、自動的に第二予約状況確認画面６０に表示を切り替えてもよい。この場合は第二予約状況確認画面６０に切り替える際に図１０の如くポップアップウィンドウ７０を表示して報せればよい。但し、通信可能な状態と不可の状態が断続的に繰り返されるようなネットワーク接続が不安定な場合には、その都度ポップアップウィンドウ７０が表示されると煩わしいので、図１１の専用ボタン７５を設けて強制的に第二予約状況確認画面６０に表示を切り替えることが好ましい。
【００７４】
また、例えば院内端末１６の起動時や予約受付プログラムの起動時、あるいは専用のボタンをクリックしたときに、図１２に示すバックアップ条件設定ウィンドウ８０をディスプレイ４２に表示させてもよい。バックアップ条件設定ウィンドウ８０は、第二スケジュールデータのバックアップを開始する時刻を入力するための入力ボックス８１と、設定、無効ボタン８２、８３とを有する。入力ボックス８１に時刻を入力し、設定ボタン８２をクリックすると、第二スケジュールデータのバックアップを開始する時刻が設定される。無効ボタン８２をクリックすると、第二スケジュールデータのバックアップは行われない。
【００７５】
中核病院によっては、院外予約の受付をある期間に制限（例えば週末の午後のみ）している等、必ずしも第二スケジュールデータのバックアップがいらないところもある。バックアップ条件設定ウィンドウ８０により、このような多様性に応えることができる。また、第二スケジュールデータの容量が小さいとはいえ、バックアップには相応の負荷が掛かるため、ニーズに合った設定をバックアップ条件設定ウィンドウ８０で設定することで、バックアップ負荷の軽減を図ることもできる。
【００７６】
なお、第二スケジュールデータのバックアップの間に院外予約等があって予約情報ＤＢ２０の予約情報２１が書き換えられると、この変更は次回のバックアップまで反映されない。このため、第二スケジュールデータのバックアップ後に予約情報ＤＢ２０の予約情報２１が変更され、これに基づいた第一予約状況確認画面５０で予約状況を確認後、次回のバックアップに至る前に通信障害が発生した場合、予約情報２１の変更が反映されていない第二スケジュールデータに基づく第二予約状況確認画面６０が表示されてしまう。つまり、第一、第二予約状況確認画面５０、６０のそれぞれで確認した内容が違ってしまう。
【００７７】
具体例として、１：００と１：３０に第二スケジュールデータをバックアップする設定であった場合を考える。１：０５に予約情報ＤＢ２０の予約情報２１が書き換えられ、１：１０に第一予約状況確認画面５０で予約状況を確認した場合、この第一予約状況確認画面５０は１：０５の予約情報２１の書き換えが反映されたものである。ここで、１：２８に再度予約状況確認画面の起動指示をしたときに通信障害が発生した場合は、１：００にバックアップした第二スケジュールデータ（１：０５の予約情報２１の書き換えは反映されていない）に基づいた第二予約状況確認画面６０が表示されてしまう。
【００７８】
この不具合を防止するため、第二スケジュールデータの今回の配信要求から次回の配信要求の間に受信した第一スケジュールデータのうちの第二スケジュールデータに該当する部分を、今回の配信要求で得られた第二スケジュールデータと置き換えて記憶させてもよい。こうすれば、第一、第二予約状況確認画面５０、６０で表示させる内容が同じになり、混乱が起こらない。
【符号の説明】
【００７９】
２  予約受付システム
１０  データセンタ
１１  中核病院
１２  診療所
１６  端末（院内端末）
１６ａ  サーバアクセス部
１６ｂ  コンソール制御部
１６ｃ  ストレージ制御部
１６ｄ  回線接続監視部
１９  センタサーバ
１９ａ  要求受付／配信部
１９ｂ  要求処理部
２０  予約情報データベース（予約情報ＤＢ）
２１  予約情報
３５  アプリケーションプログラム（ＡＰ）
３６  ＣＰＵ
５０、６０  第一、第二予約状況確認画面
７０  ポップアップウィンドウ
８０  バックアップ条件設定ウィンドウ
【図１】
0005404436.tif 000002
【図２】
0005404436.tif 000003
【図３】
0005404436.tif 000004
【図４】
0005404436.tif 000005
【図５】
0005404436.tif 000006
【図６】
0005404436.tif 000007
【図７】
0005404436.tif 000008
【図８】
0005404436.tif 000009
【図９】
0005404436.tif 000010
【図１０】
0005404436.tif 000011
【図１１】
0005404436.tif 000012
【図１２】
0005404436.tif 000013