(57)【特許請求の範囲】
【請求項１】
所定のネットワークとインターネットとを接続する外部情報受配信装置であって、
前記インターネットに接続可能な端末への所定サービスの提供に関する処理を行うモバイル部と、
あらかじめ割り当てられたグローバルＩＰアドレスを保持するとともに、前記モバイル部の前記処理に基づいて行われる、前記モバイル部と前記所定サービスの提供を前記端末へ行う外部との間の通信を前記グローバルＩＰアドレスを用いて中継する外部配信部とを、
備え、
前記グローバルＩＰアドレスは、前記外部情報受配信装置を前記所定のネットワークへ接続する際に前記外部情報受配信装置に設定されるグローバルＩＰアドレスであって、前記端末によって共有されるグローバルＩＰアドレスであり、
前記モバイル部と前記外部配信部との間の通信は、専用プロトコルによるシリアル通信であり、前記外部配信部と前記外部との間の通信は、前記グローバルＩＰアドレスを用いて前記インターネットを介して行われる、
ことを特徴とする外部情報受配信装置。
【請求項２】
前記所定のネットワークは病院内に設置されたネットワークであり、前記端末は患者が携帯するモバイル端末であり、前記所定サービスは前記モバイル端末へのメール配信サービスであり、前記外部は前記病院の外部に設置されたクラウドであることを特徴とする請求項１に記載の外部情報受配信装置。
【請求項３】
前記端末が複数の場合、前記グローバルＩＰアドレスは前記複数の端末で共有されることを特徴とする請求項１又は２に記載の外部情報受配信装置。
【請求項４】
所定のネットワークとインターネットとを接続する外部情報受配信装置による外部情報受配信方法であって、
前記外部情報受配信装置のモバイル部が、前記インターネットに接続可能な端末への所定サービスの提供に関する処理を行い、
前記外部情報受配信装置の外部配信部が、前記モバイル部の前記処理に基づいて行われる、前記モバイル部と前記所定サービスの提供を前記端末へ行う外部との間の通信を、あらかじめ割り当てられたグローバルＩＰアドレスを用いて中継し、
前記グローバルＩＰアドレスは、前記外部情報受配信装置を前記所定のネットワークへ接続する際に前記外部情報受配信装置に設定されるグローバルＩＰアドレスであって、前記端末によって共有されるグローバルＩＰアドレスであり、
前記モバイル部と前記外部配信部との間の通信は、専用プロトコルによるシリアル通信であり、前記外部配信部と前記外部との間の通信は、前記グローバルＩＰアドレスを用いて前記インターネットを介して行われる、
ことを特徴とする外部情報受配信方法。
【請求項５】
前記所定のネットワークは病院内に設置されたネットワークであり、前記端末は患者が携帯するモバイル端末であり、前記所定サービスは前記モバイル端末へのメール配信サービスであり、前記外部は前記病院の外部に設置されたクラウドであることを特徴とする請求項４に記載の外部情報受配信方法。
【請求項６】
前記端末が複数の場合、前記グローバルＩＰアドレスは前記複数の端末で共有されることを特徴とする請求項４又は５に記載の外部情報受配信方法。
【請求項７】
所定のネットワークとインターネットとを接続する外部情報受配信装置に実行させる外部情報受配信プログラムであって、
前記外部情報受配信装置のモバイル部に、前記インターネットに接続可能な端末への所定サービスの提供に関する処理を行わせ、
前記外部情報受配信装置の外部配信部に、前記モバイル部の前記処理に基づいて行われる、前記モバイル部と前記所定サービスの提供を前記端末へ行う外部との間の通信を、あらかじめ割り当てられたグローバルＩＰアドレスを用いて中継させ、
前記グローバルＩＰアドレスは、前記外部情報受配信装置を前記所定のネットワークへ接続する際に前記外部情報受配信装置に設定されるグローバルＩＰアドレスであって、前記端末によって共有されるグローバルＩＰアドレスであり、
前記モバイル部と前記外部配信部との間の通信は、専用プロトコルによるシリアル通信であり、前記外部配信部と前記外部との間の通信は、前記グローバルＩＰアドレスを用いて前記インターネットを介して行われる、
ことを特徴とする外部情報受配信プログラム。
【請求項８】
前記所定のネットワークは病院内に設置されたネットワークであり、前記端末は患者が携帯するモバイル端末であり、前記所定サービスは前記モバイル端末へのメール配信サービスであり、前記外部は前記病院の外部に設置されたクラウドであることを特徴とする請求項７に記載の外部情報受配信プログラム。
【請求項９】
前記端末が複数の場合、前記グローバルＩＰアドレスは前記複数の端末で共有されることを特徴とする請求項７又は８に記載の外部情報受配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定のネットワークとインターネットを接続した際のセキュリティを担保する技術に関する。
【背景技術】
【０００２】
病院の外来診療を受ける患者にとって、診察待ちに要する時間は大きな負担となっている。患者数を削減することができれば、この負担は減るが現実的には困難な為、近年、待ち時間の見える化と患者への診療待ち情報を通知することにより、患者の診療待ち時間の有効活用と、待ち時間に関するストレス緩和を目的として、院内に設置された表示装置や患者が所有するモバイル端末へ診療待ち情報を通知する案内表示システムが導入されている。なお、前記システムの導入が進む中、案内表示の精度を更に向上させる為、病院の外来患者への診察案内について、診察順を適切に案内することは、常に改善方法が求められている。
【０００３】
病院の外来診療において、患者の種類は大きく予約患者と予約外患者に二分される。予約外の患者とは、診察したい当日に来院した患者であり、予約外の患者は当日予約といった形で予約患者と同様に診察を行っている。
【０００４】
近年、患者の予約率を向上することによって診察順の精度を向上させる外来診療が推進されている。しかし、現実の運営では、予約をしたのに来院しない患者、あるいは予約をしたが事情があって来院が遅れる患者がでるため、予約情報によって、正確な診察順番管理ができないという点が大きな課題となっている。
【０００５】
このような課題を改善するために、病院内に設置されたネットワークとインターネットを接続して構築したシステムを用いることが考えられる。しかし、従来は、下記の特許文献１の図１に示されているように、論理的に隔離されたシステムを構築することでセキュリティを担保することが多い。そのため、専用のサーバ機をそれぞれ用意し、通信のためにＯＳや専用プログラムをインストールし、インターネット回線と通信端末を用意してサーバ機へ接続・設定し、病院内に設置されたネットワークとインターネットを接続するシステムを構築する必要があった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１５−６０５６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、セキュリティを担保しつつも通信のためだけにシステムを構築することは、ハードウェアの調達やインストールに手間が掛かり、また別途グローバルＩＰアドレスの設定が生じ、システム構築に大きなコストが必要になるという問題があった。
【０００８】
本願発明は、上記課題に鑑み、セキュリティを保ちつつ、ハードウェアの調達などの手間を省き、グローバルＩＰアドレスの取得・設定を容易にし、システム構築のコストを低減させることができる外部情報受配信装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、所定のネットワークとインターネットとを接続する外部情報受配信装置であって、前記インターネットに接続可能な端末への所定サービスの提供に関する処理を行うモバイル部と、あらかじめ割り当てられたグローバルＩＰアドレスを保持するとともに、前記モバイル部の前記処理に基づいて行われる、前記モバイル部と前記所定サービスの提供を前記端末へ行う外部との間の通信を前記グローバルＩＰアドレスを用いて中継する外部配信部とを備え、前記グローバルＩＰアドレスは、前記外部情報受配信装置を前記所定のネットワークへ接続する際に前記外部情報受配信装置に設定されるグローバルＩＰアドレスであって、前記端末によって共有されるグローバルＩＰアドレスであり、前記モバイル部と前記外部配信部との間の通信は、専用プロトコルによるシリアル通信であり、前記外部配信部と前記外部との間の通信は、前記グローバルＩＰアドレスを用いて前記インターネットを介して行われることを特徴とする。ここで、所定のネットワークは、後述する院内のネットワークに相当し、所定サービスの提供に関する処理は、例えば、後述する予約確認案内メール用のメール依頼電文の作成や送信処理に相当する。
【００１０】
また、本発明の外部情報受配信装置において、前記所定のネットワークは病院内に設置されたネットワークであり、前記端末は患者が携帯するモバイル端末であり、前記所定サービスは前記モバイル端末へのメール配信サービスであり、前記外部は前記病院の外部に設置されたクラウドであることは、好ましい態様である。
【００１１】
また、本発明の外部情報受配信装置において、前記端末が複数の場合、前記グローバルＩＰアドレスが前記複数の端末で共有されることは、好ましい態様である。
【００１２】
また、本発明の外部情報受配信方法は、所定のネットワークとインターネットとを接続する外部情報受配信装置による外部情報受配信方法であって、前記外部情報受配信装置のモバイル部が、前記インターネットに接続可能な端末への所定サービスの提供に関する処理を行い、前記外部情報受配信装置の外部配信部が、前記モバイル部の前記処理に基づいて行われる、前記モバイル部と前記所定サービスの提供を前記端末へ行う外部との間の通信を、あらかじめ割り当てられたグローバルＩＰアドレスを用いて中継し、前記グローバルＩＰアドレスは、前記外部情報受配信装置を前記所定のネットワークへ接続する際に前記外部情報受配信装置に設定されるグローバルＩＰアドレスであって、前記端末によって共有されるグローバルＩＰアドレスであり、前記モバイル部と前記外部配信部との間の通信は、専用プロトコルによるシリアル通信であり、前記外部配信部と前記外部との間の通信は、前記グローバルＩＰアドレスを用いて前記インターネットを介して行われることを特徴とする。
【００１３】
また、本発明の外部情報受配信方法において、前記所定のネットワークは病院内に設置されたネットワークであり、前記端末は患者が携帯するモバイル端末であり、前記所定サービスは前記モバイル端末へのメール配信サービスであり、前記外部は前記病院の外部に設置されたクラウドであることは、本発明の好ましい態様である。
【００１４】
また、本発明の外部情報受配信方法において、前記端末が複数の場合、前記グローバルＩＰアドレスが前記複数の端末で共有されることは、好ましい態様である。
【００１５】
また、本発明の外部情報受配信プログラムは、所定のネットワークとインターネットとを接続する外部情報受配信装置に実行させる外部情報受配信プログラムであって、
前記外部情報受配信装置のモバイル部に、前記インターネットに接続可能な端末への所定サービスの提供に関する処理を行わせ、前記外部情報受配信装置の外部配信部に、前記モバイル部の前記処理に基づいて行われる、前記モバイル部と前記所定サービスの提供を前記端末へ行う外部との間の通信を、あらかじめ割り当てられたグローバルＩＰアドレスを用いて中継させ、前記グローバルＩＰアドレスは、前記外部情報受配信装置を前記所定のネットワークへ接続する際に前記外部情報受配信装置に設定されるグローバルＩＰアドレスであって、前記端末によって共有されるグローバルＩＰアドレスであり、前記モバイル部と前記外部配信部との間の通信は、専用プロトコルによるシリアル通信であり、前記外部配信部と前記外部との間の通信は、前記グローバルＩＰアドレスを用いて前記インターネットを介して行われることを特徴とする。
【００１６】
また、本発明の外部情報受配信プログラムにおいて、前記所定のネットワークは病院内に設置されたネットワークであり、前記端末は患者が携帯するモバイル端末であり、前記所定サービスは前記モバイル端末へのメール配信サービスであり、前記外部は前記病院の外部に設置されたクラウドであることは、好ましい態様である。
【００１７】
また、本発明の外部情報受配信プログラムにおいて、前記端末が複数の場合、前記グローバルＩＰアドレスが前記複数の端末で共有されることは、好ましい態様である。
【発明の効果】
【００１８】
本発明によれば、セキュリティを保ちつつ、ハードウェアの調達などの手間を省き、グローバルＩＰアドレスの取得・設定を容易にし、システム構築のコストを低減させることができる。
【図面の簡単な説明】
【００１９】
【図１】診察案内サービスシステムの全体構成を示す図である。
【図２】外部情報受配信装置のソフトウェア構成の例を示すソフトウェア構成図である。
【図３】患者の最初のメールアドレス登録と登録後の携帯メール呼出を説明する図である。
【図４】予約確認案内メールによって予約が確定される様子を説明する図である。
【図５Ａ】モバイルサーバにより患者に適宜配信される当日案内メールの例を説明する図である。
【図５Ｂ】モバイルサーバにより患者に適宜配信される当日案内メールの例を説明する図である。
【図６】モバイルサーバから端末に当日案内メールを通知する流れを示す図である。
【図７】モバイルサーバが、当日案内メールに対する端末での応答を検知して、予約受付情報に反映させる流れを示す図である。
【図８】患者ＤＢの内容を示す表である。
【図９】クラウドに設けられるデータベースの内容例を示す表である。
【図１０】電文及びメールの構成例を示す表である。
【発明を実施するための形態】
【００２０】
以下、図面に従って本発明の実施形態を説明する。図１は、患者に診察情報を提供する診察案内サービスシステム１の全体構成を示す図である。本実施形態のシステム１は、病院内システム１００、メール配信サービスやインターネットサービス（所定サービスとも言う）を行うクラウド２００、患者の端末（以下、モバイル端末とも言う）３００、及び病院内システム１００とクラウド２００と患者の端末３００を接続するネットワーク４００から構成される。なお、端末３００は、１台に限られるものではなく、複数台存在することが一般的である。
【００２１】
また、診察案内サービスシステム１に接続される病院は、単一の病院内システムだけではなく、複数の病院内システム１００（Ａ病院の病院内システム１００、Ｂ病院の病院内システム１００ｂ、Ｃ病院の病院内システム１００ｃ・・・）も可能である。Ｂ病院の病院内システム１００ｂ、Ｃ病院の病院内システム１００ｃは、Ａ病院の病院内システム１００と同等なシステムを有し、Ａ病院と同等な診察案内サービス運営が可能である。以下では、Ａ病院の病院内システム１００を代表として、説明する。
【００２２】
病院内システム１００は、電子カルテシステム１２０、外部情報受配信装置１３０を有し、これらは院内のネットワーク（ＷＬＡＮ等）で相互接続される。なお、ここでは図示されていないが、病院内システム１００が、病院内に設置された表示盤に患者の受付番号を表示して患者を誘導する患者案内表示システムを有していてもよい。
【００２３】
電子カルテシステム１２０は、医師等が患者の診察記録（カルテ）を記入して管理するシステムである。電子カルテシステム１２０は、患者の診察が終わった際に、医師等が患者の呼出の順番を更新する機能も有している。電子カルテシステム１２０は、電子カルテサーバ１２２、電子カルテクライアント１２４を有する。
【００２４】
電子カルテサーバ１２２は、電子カルテシステム１２０を管理するサーバである。電子カルテクライアント１２４は、診察室に設置された医療従事者により操作されるクライアント端末である。電子カルテクライアント１２４は、医師等が患者の診察記録（カルテ）を記入すると共に、患者の診察が終わった際に、医師等が患者の呼出の順番を更新する端末である。
【００２５】
外部情報受配信装置１３０は、院内のネットワーク（所定のネットワーク）とネットワーク４００（インターネット）を接続する装置で、従来の表示サーバ（モバイルサーバ）と外部配信サーバの機能を有し、更にＷｉ−Ｆｉ（登録商標）機能を有し、インターネットへの接続を可能にしている。
【００２６】
ここで、外部情報受配信装置１３０のソフトウェア構成について図２を用いて説明する。図２に示すように、外部情報受配信装置１３０は、モバイル部２０と外部配信部２１から構成され、モバイル部２０と外部配信部２１は互いに連携して所定の処理（例えば、後述する予約確認案内メールの配信など）を実現する。モバイル部２０と外部配信部２１との間の通信は、院内情報のセキュリティを図るため、専用プロトコルによるシリアル通信である。なお、院内情報のセキュリティを図ることができれば、上記通信方法に限られるものではない。
【００２７】
モバイル部２０は、ビジネスロジック（モバイルサーバプログラム）２２、デバイス制御２３、通信管理２４、ＯＳ（operating system）２５の機能を備えているが、これらの機能に限定されるものではなく、他の機能を有していてもよい。なお、後述する外部配信部２１についても同様に、図２に記載された機能に限定されるものではない。
【００２８】
ビジネスロジック（モバイルサーバプログラム）２２は、ＯＳ２５のもとで動作するものであり、患者に関するデータを管理する患者データ管理２２ａ、病院内の不図示の患者案内表示盤などへ表示するデータを管理する表示データ管理２２ｂ、後述するデバイス制御２３による制御の管理を行うデバイス制御管理２２ｃ、電文の送受信の管理などを行う通信管理２２ｄ、患者に関するデータを格納する患者データ２２ｅ、電文受信や電文生成、データ管理等を行う共通２２ｆ、さらに電子カルテサーバ１２２を参照して、患者データ２２ｅの受付情報ＴＢＬ（テーブル）１３４ａを更新する受付情報取得プロセス２２ｇ、受付情報ＴＢＬ１３４ａを参照して本日の予約がある場合、外部配信部２１へメール送信依頼を行う当日予約送信プロセス２２ｈ、外部配信部２１からアクセス情報を受信し、患者データ２２ｅの受付情報ＴＢＬ１３４ａの来院予定を更新する待ち人数更新プロセス２２ｉから構成されている。
【００２９】
デバイス制御２３は、制御モジュール２３ａを備え、モバイル部２０の動作を制御するものである。また、デバイス制御２３は、専用プロトコルを用いて外部配信部２１側のデバイス２１aとシリアル通信を行うデバイス２０ａを制御するものであり、後述する予約確認案内メール用のメール依頼電文を外部配信部２１側のデバイス２１ａへシリアル通信で送信するようデバイス２０ａを制御する。
【００３０】
通信管理２４は、送受信管理２４ａ、ＬＡＮ（Local Area Network)２４ｂの一般的な機能を制御し、病院内システム１００や外部配信部２１との通信を管理するものである。
【００３１】
外部配信部２１は、ビジネスロジック（外部配信サーバプログラム）２６、デバイス制御２７、通信管理２８、ＯＳ２９の機能を備えている。ビジネスロジック（外部配信サーバプログラム）２６は、ＯＳ２９のもとで動作するものであり、後述するデバイス制御２７による制御の管理を行うデバイス制御管理２６ａ、電文の送受信の管理などを行う通信管理２６ｂ、後述するクラウドサーバ２０２ａへ送信するメールの定形文を管理するメール定形文２６ｃ、電文受信や電文生成、データ管理等を行う共通２６ｄ、さらにモバイル部２０からメール依頼電文を受信し、クラウドサーバ２０２ａへメール依頼電文を送信したり、クラウドサーバ２０２ａからアクセス情報を受信し、モバイル部２０へアクセス情報を通知する外部情報連携プロセス２６ｇから構成されている。
【００３２】
デバイス制御２７は、制御モジュール２７ａを備え、外部配信部２１の動作を制御するものである。また、デバイス制御２７は、専用プロトコルを用いてモバイル部２０側のデバイス２０ａとシリアル通信を行うデバイス２１ａを制御するものであり、例えば、クラウドサーバ２０２ａから受信する後述のアクセス情報をモバイル部２０側のデバイス２０ａへシリアル通信で送信するようデバイス２１ａを制御する。
【００３３】
通信管理２８は、送受信管理２８ａ、ＷＡＮ（Wide Area Network)２８ｂ、グローバルＩＰ２８ｃの機能を制御し、外部（クラウド２００）やモバイル部２０との通信を管理するものである。
【００３４】
グローバルＩＰ２８ｃは、例えば、外部情報受配信装置１３０を院内ネットワークへ接続する際に外部情報受配信装置１３０に設定されるグローバルＩＰアドレスであって、患者が有する端末３００によって共有されるグローバルＩＰアドレスを保持するものである。上記保持されたグローバルＩＰアドレスと同じグローバルＩＰアドレスが、例えば病院を識別する病院コードなどと関連付けられてクラウド２００（クラウドサーバ２０２ａ）に記録されている。
【００３５】
クラウド２００への上記記録は、例えば、外部情報受配信装置１３０が院内ネットワークに接続された旨の連絡を受けたクラウド２００を管理する管理者などによって行われる。なお、クラウドサーバ２０２ａには、固有のグローバルＩＰアドレスが割り当てられており、それを用いて、外部情報受配信装置１３０や端末３００と後述する通信が行われる。モバイル端末３００は、後述するように、ＵＲＬ越しにＷｅｂサーバ２０２ｂやメールサーバ２０２ｃにアクセスしてサービスの提供を受ける。以下では特に述べないが、インターネットを介した通信が行われる際には、上述したグローバルＩＰアドレスが用いられる。
【００３６】
外部情報受配信装置１３０が、上記構成のため、セキュリティを保ちつつ、ハードウェアの調達などの手間を省き、グローバルＩＰアドレスの取得・設定を容易にすることができる。
【００３７】
外部情報受配信装置１３０（モバイル部２０）は、患者が所有する端末（携帯端末）３００に、メールで診察情報を提供して、診察案内サービスを行うものである。診察情報とは、患者の診療科名、医師名、予約時間、あるいは待ち人数等である。診察情報が提供されるメールを、以下で、「当日案内メール」と呼ぶ。また、以下では、外部情報受配信装置１３０（モバイル部２０）を単にモバイル部２０と呼ぶ。
【００３８】
患者データ２２ｅは、診察案内サービスに必要な患者情報を記憶するデータベースである。患者データ２２ｅには、後述する受付情報ＴＢＬ（テーブル）１３４ａ、患者情報ＴＢＬ（テーブル）１３４ｂが記憶される。受付情報ＴＢＬ１３４ａは、患者毎の予約情報が記載されたテーブルである。患者情報ＴＢＬ１３４ｂは、各患者のメールアドレスが記載されたテーブルである。
【００３９】
モバイル部２０では、患者の端末３００に、当日案内メールとして、受付開始前（例えば当日朝）に「予約確認用の当日案内メール（以下、予約確認案内メールと呼ぶ）」を配信させ、受付開始後には「受付開始後の当日案内メール」を配信させる。
【００４０】
予約確認案内メールは、患者の来院の意思を確認するためのメールである。受付開始後の当日案内メールは、主に受付後に、病院内で待機している患者に診察状況や待ち時間等の情報を提供するメールである。
【００４１】
モバイル部２０は、事前に診察を予約した予約患者に対して、例えば、診察当日の朝、患者データ２２ｅを参照して、予約確認案内メール用のメール依頼電文を作成する。このメール依頼電文の作成や送信は、メール配信サービスの提供に関する処理に相当する。なお、モバイル部２０は、診察当日の朝以外でも、診察時間の所定時間前に、予約確認案内メール用のメール依頼電文を作成してもよい。
【００４２】
診察開始後は、電子カルテサーバ１２２から、図１０に示す診察電文Ｄ１がモバイル部２０に送信される。モバイル部２０は、診察電文Ｄ１を参照して、受付情報ＴＢＬ１３４ａを更新する。そして、モバイル部２０は、受付後の患者に対して、受付情報ＴＢＬ１３４ａを参照して、診察状況や待ち時間を案内する受付開始後の当日案内メール用のメール依頼電文を作成する。
【００４３】
モバイル部２０は、受付情報ＴＢＬ１３４ａ及び患者情報ＴＢＬ１３４ｂを参照して、メール依頼電文を作成する。
【００４４】
図８は、患者データ２２ｅの内容を示す表である。受付情報ＴＢＬ１３４ａは、予約患者の予約情報及び診察状況の情報等から構成される。受付情報ＴＢＬ１３４ａでは、患者ＩＤに対応付けて、受付日、診療科、予約時間帯、予約フラグ、遅延フラグの各項目が管理される。再来機（不図示）で患者が受付を完了すると、「受付日」に受付を完了した日の日付が記載される。「診療科」には、患者が予約した診療科名が記載される。患者が事前に診察予約をした場合には、「予約時間帯」に、予約時間が記載される。「予約フラグ」は、詳細は後述するが、予約確認案内メールで、患者が端末３００で確定操作をした場合に、ＯＮになる。「遅延フラグ」は、患者の診察遅延状況を示すフラグで、例えば、患者の予約時間から３０分以上経過しても診察呼出がない場合に、ＯＮになる。患者情報ＴＢＬ１３４ｂでは、患者ＩＤに対応付けて、端末３００のメールアドレスが管理される。
【００４５】
外部情報受配信装置１３０（外部配信部２１）は、ネットワーク４００を介して、病院内システム１００と外部（本例では、クラウド２００）との情報通信を行うものである。以下では、外部情報受配信装置１３０（外部配信部２１）を単に外部配信部２１と呼ぶ。
【００４６】
クラウド２００は、ネットワーク４００を介してメール配信やＷｅｂサービスを行うよう、外部ネットワークに設置されるシステムである。
【００４７】
クラウド２００には、クラウドサーバ２０２ａ、Ｗｅｂサーバ２０２ｂ、メールサーバ２０２ｃ、実績ＤＢ２０４、蓄積ＤＢ２０６等が設けられる。クラウド２００により、モバイル部２０からのメール依頼が、端末３００へ当日案内メールとして配信される。
【００４８】
クラウドサーバ２０２ａは、外部配信部２１と、Ｗｅｂサーバ２０２ｂ及びメールサーバ２０２ｃを中継する。また、クラウドサーバ２０２ａは、モバイル部２０から送信されたメール依頼電文の内容（病院ＩＤ、診療科、診察室、メール配信時刻等）を、実績ＤＢ２０４や蓄積ＤＢ２０６に格納する。実績ＤＢ２０４及び蓄積ＤＢ２０６に保存される情報例を図９に示す。
【００４９】
Ｗｅｂサーバ２０２ｂは、端末３００からのＷｅｂサイトへのアクセスを検知し、端末３００に当日案内メールのＷｅｂ画面（図５Ａ、図５Ｂで後述）を提供する。Ｗｅｂサーバ２０２ｂは、実績ＤＢ２０４や蓄積ＤＢ２０６を参照して、端末３００に提供する当日案内メールのＷｅｂ画面を作成する。
【００５０】
メールサーバ２０２ｃは、モバイル部２０から送信されたメール依頼電文に基づき、当日案内メールを作成し患者の端末３００に配信する。図１０のＤ３は、メールの構成例である。メールサーバ２０２ｃは、メール依頼電文に含まれる患者のメールアドレスや診察情報に基づき、当日案内メールを作成する。
【００５１】
また、メールサーバ２０２ｃは、当日案内メールの本文に応答用のＵＲＬ（Uniform Resource Locator）７００を含ませる。応答用のＵＲＬ７００（応答用ＵＲＬとも呼ぶ）には、診察案内Ｗｅｂに、患者ＩＤと病院ＩＤを暗号化した情報が加えられる。応答用ＵＲＬの具体例は、図４で説明する。
【００５２】
クラウドサーバ２０２ａは、端末３００からの応答用ＵＲＬによるＷｅｂサイトへのアクセスを、外部配信部２１を経由してモバイル部２０に送信する。
【００５３】
患者の端末３００は、メール通信可能な端末であればよく、患者の所有する携帯電話あるいはタブレットでもよい。端末３００は、ネットワーク４００を介して、クラウド２００に接続され、更に外部配信部２１経由でモバイル部２０に接続される。
【００５４】
当日案内メールが配信される手順を簡単に説明する。診察予約日の朝あるいは診察予約時間の所定時間前、モバイル部２０から予約確認用のメール依頼電文がクラウド２００に送信され、メールサーバ２０２ｃが、予約確認案内メール５００ａを端末３００に配信する。端末３００で応答用ＵＲＬへのアクセス（応答）があると、Ｗｅｂサーバ２０２ｂが検出する。クラウドサーバ２０２ａが、端末３００からの応答用ＵＲＬへのアクセスを外部配信部２１を経由してモバイル部２０に通知し、モバイル部２０は、受付情報ＴＢＬ１３４ａの予約フラグをＯＮにし、当該患者の診察予約を確定する。
【００５５】
また、モバイル部２０は、予約確認案内メール５００ａの配信後所定時間（例えば1時間）経過しても、端末３００から応答用のＵＲＬへのアクセスがない場合には、予約を取り消すようにしてもよい。また、モバイル部２０は、応答用のＵＲＬへのアクセスが所定時間以上ない場合には、メールサーバ２０２ｃに再度、予約確認案内メール５００ａの配信を指示してもよい。
【００５６】
診察受付後には、モバイル部２０から受付後のメール依頼電文がクラウド２００に送信され、メールサーバ２０２ｃが、受付後の当日案内メールとして端末３００に配信する。端末３００から、応答用ＵＲＬへのアクセスがあると、クラウド２００がモバイル部２０を経由してモバイル部２０に通知する。モバイル部２０は、クラウド２００に診察状況の情報を通知する。Ｗｅｂサーバ２０２ｂは、Ｗｅｂ画面を作成して、端末３００に送信する。これにより、患者は、診察の進行状況や待ち時間等を知ることができる。
【００５７】
なお、電子カルテサーバ１２２、外部配信部２１、モバイル部２０、クラウドサーバ２０２ａ等のサーバや装置は、汎用のコンピュータ等により実現され、よってそのハードウェア構成は、特に図示しないが一般的なものである。すなわち、例えば、ＣＰＵ等の演算プロセッサ、ハードディスク、メモリ等の記憶装置、通信機能部等（何れも不図示）を有する。更に、ディスプレイ、キーボード／マウス等が備えられていても良い。
【００５８】
図３は、患者の最初のメールアドレス登録と登録後の携帯メール呼出を説明する図である。病院内システム１００には、患者の端末３００のメールアドレスを予め登録する登録端末１６０（不図示）が設けられ、モバイル部２０や電子カルテシステム１２０と通信可能に接続される。
【００５９】
患者が、診察券（不図示）を登録端末１６０に挿入すると、登録端末１６０は、診察券の例えば、磁気ストライプに記憶されている患者ＩＤを磁気的に読み取る。登録端末１６０は、患者ＩＤに基づきＱＲコード（登録商標）を作成し、ＱＲコード６００を画面に表示する。ＱＲコードの内容は、送信先のメールアドレスと本文（患者ＩＤ）等である。送信先のメールアドレスは、例えば外部配信部２１のアドレスである。本文（患者ＩＤ）は、個人情報保護の観点から暗号化等のセキュリティ対策が施される。
【００６０】
患者は、端末３００に予め内蔵されたＱＲリーダアプリを起動し、端末３００のカメラを登録端末１６０の画面にかざす。端末３００は、自動的にＱＲコード６００を読み込み、読み込まれたＱＲコード６００から送信先メールアドレスを取得し、患者ＩＤをメール本文とする空メール５２０を送信する。外部配信部２１が送信先メールアドレスとなる。
【００６１】
外部配信部２１は、メールサーバ２０２ｃ経由で端末３００からの空メール５２０を受信する。モバイル部２０は、外部配信部２１から空メール５２０の受信通知を受ける。モバイル部２０は、空メール５２０の受信通知に対応して、空メール５２０を送信した患者のメールアドレスを、患者ＩＤに対応して患者ＤＢ１３４の患者情報ＴＢＬ１３４ｂに登録する。
【００６２】
モバイル部２０は、患者のメールアドレスを患者情報ＴＢＬ１３４ｂに登録し、登録完了メール５３０を患者の端末３００に送信するようメールサーバ２０２ｃに指示する。そして、登録完了メール５３０がメールサーバ２０２ｃから端末３００に配信される。図３のメール画面Ｍ１は、端末３００に表示される登録完了メール５３０の例である。
【００６３】
登録完了後、モバイル部２０は、メールサーバ２０２ｃに適宜、当日案内メールの通知を指示し、メールサーバ２０２ｃから患者の端末３００に当日案内メールが配信される。メール画面Ｍ２は、端末３００に表示される当日案内メールの一例である。
【００６４】
次に、当日案内メールの内容を具体的に説明する。図４は、予約確認案内メールによって予約が確定される様子を説明する図である。患者は、事前に、電話あるいはＷｅｂ等で診察予約を行っていたとする。患者の端末３００には、予約日の朝あるいは予約時間の所定時間前に、予約確認案内メール５００ａが配信される。図４のメール画面Ｍ３は、予約確認案内メール５００ａの内容である。予約確認案内メール５００ａには、診療科や医師名等の予約内容が記載され、下段には、応答用のＵＲＬ７００が添付される。
【００６５】
端末３００で応答用のＵＲＬ７００がクリック（アクセス）されると、クラウド２００のＷｅｂサーバ２０２ｂはアクセスを検知する。Ｗｅｂサーバ２０２ｂが、外部配信部２１を経由して、応答用ＵＲＬ７００へのアクセスを、モバイル部２０に通知する。
【００６６】
モバイル部２０は、アクセスされた応答用のＵＲＬ７００の情報に基づき、アクセスした患者を特定し、受付情報ＴＢＬ１３４ａで対応する患者の予約フラグをＯＮに設定する。これで予約が確定される。そして、モバイル部２０は、受付情報ＴＢＬ１３４ａにおける患者の各予約情報を、外部配信部２１を経由して、Ｗｅｂサーバ２０２ｂに通知する。
【００６７】
一方、端末３００では、ＵＲＬ７００がクリックされた後、Ｗｅｂ画面Ｗ１に切り替わる。Ｗｅｂ画面Ｗ１で「診察待ち情報」がクリックされると、端末３００では、Ｗｅｂ画面Ｗ２が表示される。Ｗｅｂ画面Ｗ２は、モバイル部２０から通知された患者の予約内容に基づき、Ｗｅｂサーバ２０２ｂで作成された画面である。予約内容がＷｅｂ画面Ｗ２として表示されることで、患者は、予約内容の確認をすることもできる。
【００６８】
次に、図５Ａ、図５Ｂを用いて、モバイル部２０により患者に適宜配信される当日案内メール５００の例を説明する。図５Ａの左欄のＷｅｂ画面Ｗ２は、診察予約日の当日朝（例えば８：００）の予約確定後に配信される当日案内メールの内容である。Ｗｅｂ画面Ｗ２は、図４で説明したのと同じ画面で、受付はされていない状態での画面である。
【００６９】
Ｗｅｂ画面Ｗ３は、患者が病院での受付をしていない状況（例えば、９：３０）で、端末３００に配信される当日案内メールの画面である。患者は、Ｗｅｂ画面Ｗ３から、既に、診察状況が３０分遅れであることがわかる。
【００７０】
患者は、病院に到着後、病院内システム１００に接続された再来機（不図示）に自分の診察カードを入れて受付処理を行う。モバイル部２０は、患者が受付を済ませたことを再来機から通知され、患者データ２２ｅの受付情報ＴＢＬ１３４ａに記録する。
【００７１】
Ｗｅｂ画面Ｗ４は、病院での受付を済ませた後、例えば１０：３０に、端末３００に配信される当日案内メールの画面である。Ｗｅｂ画面Ｗ４では、あいかわらず、診察状況が３０分遅れであることが示されている。
【００７２】
Ｗｅｂ画面Ｗ５（図５Ｂ）は、混雑しているために、予約時間（１１：００）を経過した後である１２：００に、端末３００に配信される当日案内メールの画面である。Ｗｅｂ画面Ｗ６（図５Ｂ）は、患者の診察が終了した後（１２：３０）に、端末３００に配信される診察が終了したことを知らせる当日案内メールの画面である。
【００７３】
次に、図６及び図７を用いて、診察案内サービスシステム１のサーバと装置（端末３００を含む）間における、当日案内メール配信の流れを説明する。図６は、モバイル部２０から、端末３００に当日案内メールを通知する流れを示す図である。図７は、モバイル部２０が、当日案内メールに対する端末３００での応答を検知して、予約受付情報に反映させる流れを示す図である。特に、端末３００でなされた予約確認案内メール５００ａに対するアクセスを、モバイル部２０で検知して、診察予約を確定させる流れを示す。
【００７４】
図６から説明する。モバイル部２０は、受付情報取得プロセスと当日予約送信プロセスを並列的に実行する。受付情報取得プロセスとは、患者の受付情報を、患者データ２２ｅの受付情報ＴＢＬ１３４ａに、適宜登録する処理である。受付情報とは、患者の診察予約や患者の受付状態あるいは患者の診察状況等に関する情報である。
【００７５】
モバイル部２０は、起動後に、Ｐ１０からＰ３０の間を無限ループとして、患者の各種受付情報を取得して、取得した受付情報により患者データ２２ｅの受付情報ＴＢＬ１３４ａを更新する。例えば、モバイル部２０は、診察中であれば、電子カルテサーバ１２２を参照して、受付情報ＴＢＬ１３４ａを更新する（ステップＰ１２）。
【００７６】
また、モバイル部２０は、患者が再来機へ受付処理をした場合にも、受付情報ＴＢＬ１３４ａを更新する。また、モバイル部２０は、患者から電話や端末３００により診察予約があった場合には、受付情報ＴＢＬ１３４ａの診療科や予約時間帯等に予約内容を登録する。モバイル部２０は、一定時間待機後（ステップＰ１４）に、ステップＰ１０に戻る。
【００７７】
当日予約送信プロセスとは、モバイル部２０が、当日の来院意思を確認するために、診察予約をした患者に予約確認案内メール５００ａを送信する処理である。前述のように、モバイル部２０は、予約確認案内メール５００ａ以外の当日案内メール５００も端末３００に送信する。
【００７８】
モバイル部２０は、起動後に、受信ポートをオープンにする（ステップＰ５０）。モバイル部２０は、Ｐ５２からＰ７０の間を無限ループとして、受付情報ＴＢＬ１３４ａで本日予約があるかを判断する（ステップＰ５４）。
【００７９】
前述したように、早朝の所定時に、モバイル部２０は、受付情報ＴＢＬ１３４ａの患者ＩＤの予約時間帯で、本日予約があるかを判断してもよい。また、モバイル部２０は、現時点から所定時間以内に予約があるかどうかで、予約確認案内メール５００ａの送信を判断してもよい。
【００８０】
モバイル部２０は、受付情報ＴＢＬ１３４ａで本日予約があると判断すると（ステップＰ５４Ｙｅｓ）、外部配信部２１に所定のメール依頼電文を送信する（ステップＰ５６）。メール依頼電文の構成例を、図１０の電文Ｄ２に示す。
【００８１】
モバイル部２０は、受付情報ＴＢＬ１３４ａで本日予約がないと判断すると（ステップＰ５４Ｎｏ）、ステップＰ７０に進み、ステップＰ５２に戻る。なお、モバイル部２０は、予約確認案内メール５００ａ以外の当日案内メール５００（図５ＡのＷｅｂ画面Ｗ３、Ｗｅｂ画面Ｗ４、Ｗｅｂ画面Ｗ５等）の配信についても、外部配信部２１に所定のメール依頼電文を送信するが、詳細は省略する。
【００８２】
外部配信部２１は、起動後に、Ｒ１０からＲ３０の間を無限ループとして、メール依頼電文を送信する。外部配信部２１は、モバイル部２０からメール依頼電文を受信して（ステップＲ１２）、クラウドサーバ２０２ａへメール依頼電文を送信する（ステップＲ１４）。
【００８３】
クラウドサーバ２０２ａは、Ｓ１０からＳ３０の間を無限ループとして、外部配信連携プロセスを実行する。クラウドサーバ２０２ａは、起動後に、Ｓ１０からＳ３０の間を無限ループとして、メール配信を行う。
【００８４】
クラウドサーバ２０２ａは、外部配信部２１からメール依頼電文を受信して（ステップＳ１２）、メールサーバ２０２ｃにメールアドレスと本文を通信する（ステップＳ１４）。メールサーバ２０２ｃは、メール依頼電文に基づき、予約確認案内メール５００ａ（図４のＭ３参照）を作成し、メール依頼電文に記載されたメールアドレスに配信する。予約確認案内メール５００ａの構成は、図１０のＤ３に示すようである。
【００８５】
また、クラウドサーバ２０２ａは、受信したメール依頼電文に基づき、実績ＤＢ２０４の病院毎診察実績ＴＢＬ２０４ｂに病院ＩＤ、診療科、診察室、メール配信時刻等を記載する（ステップＳ１６）。
【００８６】
端末３００は、起動後に、Ｔ１０からＴ３０の間を無限ループとして、メールを受信する（ステップＴ１２）。端末３００は、メールサーバ２０２ｃから配信される予約確認案内メール５００ａを受信する。
【００８７】
図７を用いて、配信された予約確認案内メール５００ａへのアクセスにより、モバイル部２０が予約を確定する処理を説明する。
【００８８】
端末３００は、Ｔ１０からＴ３０の間を無限ループとして以下処理を行う。端末３００は、予約確認案内メール５００ａの受信後に（ステップＴ１２）、予約確認案内メール５００ａの本文末尾の応答用ＵＲＬ７００が患者によりアクセス（クリック）されると、メールのリンクを確認して（ステップＴ２０）、リンク先に通知がされる。
【００８９】
クラウドサーバ２０２ａは、Ｓ１０からＳ３０の間を無限ループとして以下処理を行う。クラウドサーバ２０２ａは、端末３００からのアクセス情報をＷｅｂサーバ２０２ｂから受信すると（ステップＳ２０）、クラウドサーバ２０２ａは、対応する応答用ＵＲＬ７００の内容から、病院と患者ＩＤを特定する。
【００９０】
クラウドサーバ２０２ａは、対応する病院の外部配信部２１に患者ＩＤにつき予約確認案内メール５００ａにアクセスのあったことを通知する。また、クラウドサーバ２０２ａは、実績ＤＢ２０４の病院毎診察実績ＴＢＬ２０４ｂへ病院ＩＤ、診療科、診察室、メール配信時刻等を記載する（ステップＳ２４）。
【００９１】
外部配信部２１は、Ｒ１０からＲ３０の間を無限ループとして以下処理を行う。外部配信部２１は、クラウドサーバ２０２ａからのアクセス情報を受信すると（ステップＲ２０）、モバイル部２０へアクセスする（ステップＲ２２）。
【００９２】
モバイル部２０は、Ｐ１００からＰ１１０の間を無限ループとして、待ち人数更新プロセスを実行する。モバイル部２０は、外部配信部２１からアクセス情報を受信すると（ステップＰ１０２）、電子カルテサーバ１２２を参照して、患者データ２２ｅの受付情報ＴＢＬ１３４ａの来院予定を更新する（ステップＰ１０４）。モバイル部２０は、順番をカウントして待ち人数を返す（ステップＰ１０６）。
【００９３】
以上説明したように本実施形態によれば、従来の表示サーバ（モバイルサーバ）と外部配信サーバの機能を備え、あらかじめ割り当てられたグローバルＩＰアドレスを保持するようにしたので、セキュリティを保ちつつ、ハードウェアの調達などの手間を省き、グローバルＩＰアドレスの取得・設定を容易にし、システム構築のコストを低減させることができる。
【００９４】
なお、本発明は上述した実施形態そのままに限定されるものではなく、秘匿性が必要とされるシステムを有する分野におけるサービスにも適用可能であり、実施段階でのその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素を適宜組み合わせても良い。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。このような、発明の趣旨を逸脱しない範囲内において種々の変形や応用が可能であることはもちろんである。
【符号の説明】
【００９５】
１      診察案内サービスシステム
１００  病院内システム
１２０  電子カルテシステム
１２２  電子カルテサーバ
１２４  電子カルテクライアント
１３０  外部情報受配信装置
１３４ａ  受付情報ＴＢＬ
１３４ｂ  患者情報ＴＢＬ
１６０  登録端末
２００  クラウド
２０２ａ  クラウドサーバ
２０２ｂ  Ｗｅｂサーバ
２０２ｃ  メールサーバ
２０４  実績ＤＢ
２０６  蓄積ＤＢ
３００  端末
４００  ネットワーク
５００  当日案内メール
５００ａ  予約確認案内メール
５２０  空メール
５３０  登録完了メール
７００  ＵＲＬ
２０  モバイル部
２０ａ  デバイス
２１  外部配信部
２１ａ  デバイス
２２  ビジネスロジック（モバイルサーバプログラム）
２２ａ  患者データ管理
２２ｂ  表示データ管理
２２ｃ  デバイス制御管理
２２ｄ  通信管理
２２ｅ  患者データ
２２ｆ  共通
２２ｇ  受付情報取得プロセス
２２ｈ  当日予約送信プロセス
２２ｉ  待ち人数更新プロセス
２３  デバイス制御
２３ａ  制御モジュール
２４  通信管理
２４ａ  送受信管理
２４ｂ  ＬＡＮ
２５  ＯＳ
２６  ビジネスロジック（外部配信サーバプログラム）
２６ａ  デバイス制御管理
２６ｂ  通信管理
２６ｃ  メール定形文
２６ｄ  共通
２６ｇ  外部情報連携プロセス
２７  デバイス制御
２７ａ  制御モジュール
２８  通信管理
２８ａ  送受信管理
２８ｂ  ＷＡＮ
２８ｃ  グローバルＩＰ
２９  ＯＳ
【図１】
0006496202.tif 000002
【図２】
0006496202.tif 000003
【図３】
0006496202.tif 000004
【図４】
0006496202.tif 000005
【図５Ａ】
0006496202.tif 000006
【図５Ｂ】
0006496202.tif 000007
【図６】
0006496202.tif 000008
【図７】
0006496202.tif 000009
【図８】
0006496202.tif 000010
【図９】
0006496202.tif 000011
【図１０】
0006496202.tif 000012