JP6552903B2 - 診察案内サービス装置、システム及び方法 - Google Patents

Description

本発明は、診察順における予約を推進し、診察案内の精度を向上するための診察案内サービス装置、システム及び方法に関する。

病院の外来患者への診察案内において、診察順を適切に案内することについては、常に改善方法が求められている。病院の外来診療の患者の種類は大きく予約患者と予約外患者に二分される。予約外の患者とは、診察を受けたい当日に来院した患者であり、予約外の患者は当日予約といった形で予約患者と同様に診察を行っている。

近年、患者の予約率の向上に伴い診察案内の精度を向上させる外来診療が推進されている。しかし、現実の運営では、予約をしたのに来院しない患者、あるいは予約をしたが事情があって来院できない患者がでるため、予約情報によって、患者への正確な診察案内ができないという点が大きな課題となっている。

そこで、予約した患者を確実に来院させるために、患者だけでなく親族やホームヘルパーなどの患者の関係者へ患者の通院状況を通知して、患者が通院を忘れずに行えるようにする発明も提案されている（特許文献１）。

特開２０１４−１０６６４４号公報

来院の有無を確認するため、患者からの電話やメール返信を実現するといった方法が考えられるが、これらに対応するためには、予約コールセンタの設置や返信用アドレスを用意する必要がある。しかし、予約コールセンタの設置や返信用アドレスの用意は、病院側の負荷が高く実現できないというのが現状である。特に、患者の情報は秘匿性の高い情報であるので、病院と患者間での情報のやり取りには、細心の注意が要求されるからである。

本願発明は、上記課題に鑑み、簡単な端末操作で予約患者の通院意思を確実に把握して、診察案内の精度向上を実現する診察案内サービス装置を提供することを目的とする。

上記目的を達成するために、患者の端末に診察に関する案内メールを配信する診察案内サービス装置において、既に診察予約を済ませた患者である予約患者の端末に、少なくとも当該予約患者を特定する情報が組み込まれたＵＲＬを含む、当該予約患者の来院意思を確認するための予約確認案内メールを事前に配信し、前記予約確認案内メールが配信された端末における前記ＵＲＬへのアクセスを検知した場合に、当該ＵＲＬに組み込まれた患者を特定する情報に基づき、対応する予約患者の来院意思があるものとして当該予約患者の診察予約を確定させることを特徴とする。

本発明によれば、簡単な端末操作で予約患者の通院意思を確実に把握して、診察案内の精度向上を実現する診察案内サービス装置を提供することができる。

診察案内サービスシステムの全体構成を示す図である。 患者の最初のメールアドレス登録と登録後の携帯メール呼出を説明する図である。 予約確認案内メールによって予約が確定される様子を説明する図である。 モバイルサーバにより患者に適宜配信される当日案内メールの例を説明する図１である。 モバイルサーバにより患者に適宜配信される当日案内メールの例を説明する図２である。 モバイルサーバから端末に当日案内メールを通知する流れを示す図である。 モバイルサーバが、当日案内メールに対する端末での応答を検知して、予約受付情報に反映させる流れを示す図である。 患者ＤＢの内容を示す表である。 クラウドに設けられるデータベースの内容例を示す表である。 電文及びメールの構成例を示す表である。

以下、図面に従って本発明の実施形態を説明する。図１は、患者に診察情報を提供する診察案内サービスシステム１の全体構成を示す図である。本実施形態のシステム１は、病院内システム１００と、メール配信サービスやインターネットサービスを行うクラウド２００、患者の端末３００、及び病院内システム１００とクラウド２００と患者の端末３００を接続するネットワーク４００から構成される。

また、診察案内サービスシステム１に接続される病院は、単一の病院内システムだけではなく、複数の病院内システム１００（Ａ病院の病院内システム１００、Ｂ病院の病院内システム１００ｂ、Ｃ病院の病院内システム１００ｃ・・・）も可能である。Ｂ病院の病院内システム１００ｂ、Ｃ病院の病院内システム１００ｃは、Ａ病院の病院内システム１００と同等な内部システムを有し、Ａ病院と同等な診察案内サービス運営が可能である。以下では、Ａ病院の病院内システム１００を代表として、説明する。

病院内システム１００は、電子カルテシステム１２０、モバイルシステム１３０及び外部配信サーバ１４０を有し、これらは院内のネットワーク（ＷＬＡＮ等）で相互接続される。なお、モバイルシステム１３０と外部配信サーバ１４０は、院内情報のセキュリティを図るため専用プロトコル１５０で接続される。

電子カルテシステム１２０は、医師等が患者の診察記録（カルテ）を記入して管理するシステムである。電子カルテシステム１２０は、患者の診察が終わった際に、医師等が患者の呼出の順番を更新する機能も有している。電子カルテシステム１２０は、電子カルテサーバ１２２、電子カルテクライアント１２４を有する。

電子カルテサーバ１２２は、電子カルテシステム１２０を管理するサーバである。電子カルテクライアント１２４は、診察室に設置された医療従事者により操作されるクライアント端末である。電子カルテクライアント１２４は、医師等が患者の診察記録（カルテ）を記入すると共に、患者の診察が終わった際に、医師等が患者の呼出の順番を更新する端末である。

モバイルシステム１３０は、患者が所有する端末（携帯端末）３００に、メールで診察情報を提供して、診察案内サービスを行うものである。診察情報とは、患者の診療科名、医師名、予約時間、あるいは待ち人数等である。診察情報が提供されるメールを、以下で、「当日案内メール」と呼ぶ。

モバイルシステム１３０は、モバイルサーバ１３２と患者ＤＢ（データベース）１３４を有する。モバイルサーバ１３２は、モバイルシステム１３０を管理するサーバである。モバイルサーバ１３２は、診察案内サービス装置とも呼ばれる。

患者ＤＢ１３４は、診察案内サービスに必要な患者情報を記憶するデータベースである。患者ＤＢ１３４には、後述する受付情報ＴＢＬ（テーブル）１３４ａ、患者情報ＴＢＬ（テーブル）１３４ｂが記憶される。受付情報ＴＢＬ１３４ａは、患者毎の予約情報が記載されたテーブルである。患者情報ＴＢＬ１３４ｂは、各患者のメールアドレスが記載されたテーブルである。

モバイルシステム１３０では、患者の端末３００に、当日案内メールとして、受付開始前（例えば診察予約がある当日朝）に「予約確認用の当日案内メール（以下、予約確認案内メールと呼ぶ）」を配信させ、受付開始後には「受付開始後の当日案内メール」を配信させる。

予約確認案内メールは、患者の来院の意思を確認するためのメールである。受付開始後の当日案内メールは、主に受付後に、病院内で待機している患者に診察状況や待ち時間等の情報を提供するメールである。

モバイルサーバ１３２は、事前に診察を予約した予約患者に対して、例えば、診察当日の朝、患者ＤＢ１３４を参照して、予約確認案内メール用のメール依頼電文を作成する。なお、モバイルサーバ１３２は、診察当日の朝以外でも、診察時間の所定時間前に、予約確認案内メール用のメール依頼電文を作成してもよい。

診察開始後は、電子カルテサーバ１２２から、図９に示す診察電文Ｄ１がモバイルサーバ１３２に送信される。モバイルサーバ１３２は、診察電文Ｄ１を参照して、受付情報ＴＢＬ１３４ａを更新する。そして、モバイルサーバ１３２は、受付後の患者に対して、受付情報ＴＢＬ１３４ａを参照して、診察状況や待ち時間を案内する受付開始後の当日案内メール用のメール依頼電文を作成する。

モバイルサーバ１３２は、受付情報ＴＢＬ１３４ａ及び患者情報ＴＢＬ１３４ｂを参照して、メール依頼電文を作成する。

図７は、患者ＤＢ１３４の内容を示す表である。受付情報ＴＢＬ１３４ａは、予約患者の予約情報及び診察状況の情報等から構成される。受付情報ＴＢＬ１３４ａでは、患者ＩＤに対応付けて、受付日、診療科、予約時間帯、予約フラグ、遅延フラグの各項目が管理される。再来受付機（不図示）で患者が受付を完了すると、「受付日」に本日の日付が記載される。「診療科」には、患者が予約した診療科名が記載される。患者が事前に診察予約をした場合には、「予約時間帯」に、予約時間が記載される。「予約フラグ」は、詳細は後述するが、予約確認案内メールで、患者が端末３００で確定操作をした場合に、ＯＮになる。「遅延フラグ」は、患者の診察遅延状況を示すフラグで、例えば、患者の予約時間から３０分以上経過しても診察呼出がない場合に、ＯＮが入力される。患者情報ＴＢＬ１３４ｂでは、患者ＩＤに対応付けて、端末３００のメールアドレスが管理される。

外部配信サーバ１４０は、ネットワーク４００を介して、病院内システム１００と外部（本例では、クラウド２００）との情報通信を行うものである。また、クラウド２００は、ネットワーク４００を介してメール配信やＷｅｂサービスを行うよう、外部ネットワークに設置されるシステムである。

クラウド２００には、クラウドサーバ２０２ａ、Ｗｅｂサーバ２０２ｂ、メールサーバ２０２ｃ、実績ＤＢ２０４、蓄積ＤＢ２０６等が設けられる。クラウド２００により、モバイルサーバ１３２からのメール依頼が、端末３００へ当日案内メールとして配信される。

クラウドサーバ２０２ａは、外部配信サーバ１４０と、Ｗｅｂサーバ２０２ｂ及びメールサーバ２０２ｃを中継する。また、クラウドサーバ２０２ａは、モバイルサーバ１３２から送信されたメール依頼電文の内容（病院ＩＤ、診療科、診察室、メール配信時刻等）を、実績ＤＢ２０４や蓄積ＤＢ２０６に格納する。実績ＤＢ２０４及び蓄積ＤＢ２０６に保存される情報例を図8に示す。

Ｗｅｂサーバ２０２ｂは、端末３００からのＷｅｂサイトへのアクセスを検知し、端末３００に当日案内メールのＷｅｂ画面（図４Ａ、図４Ｂで後述）を提供する。Ｗｅｂサーバ２０２ｂは、実績ＤＢ２０４や蓄積ＤＢ２０６を参照して、端末３００に提供する当日案内メールのＷｅｂ画面を作成する。

メールサーバ２０２ｃは、モバイルサーバ１３２から送信されたメール依頼電文に基づき、当日案内メールを作成し患者の端末３００に配信する。図９のＤ３は、メールの構成例である。メールサーバ２０２ｃは、メール依頼電文に含まれる患者のメールアドレスや診察情報に基づき、当日案内メールを作成する。

また、メールサーバ２０２ｃは、当日案内メールの本文に応答用のＵＲＬ（Uniform Resource Locator）７００を含ませる。応答用のＵＲＬ７００（応答用ＵＲＬとも呼ぶ）には、診察案内Ｗｅｂに、患者ＩＤと病院ＩＤを暗号化した情報が加えられる。応答用ＵＲＬの具体例は、図３で説明する。

クラウドサーバ２０２ａは、端末３００からの応答用ＵＲＬによるＷｅｂサイトへのアクセスを、外部配信サーバ１４０を経由して、モバイルサーバ１３２に送信する。

患者の端末３００は、メール通信可能な装置であればよく、患者の所有する携帯電話あるいはタブレットでもよい。端末３００は、ネットワーク４００を介して、クラウド２００に接続され、更に外部配信サーバ１４０経由でモバイルサーバ１３２に接続される。

当日案内メールが配信される手順を簡単に説明する。診察予約日の朝あるいは診察予約時間の所定時間前、モバイルサーバ１３２から外部配信サーバ１４０経由で予約確認用のメール依頼電文がクラウド２００に送信され、メールサーバ２０２ｃが、予約確認案内メール５００ａを端末３００に配信する。端末３００で応答用ＵＲＬへのアクセス（応答）があると、Ｗｅｂサーバ２０２ｂが検出する。クラウドサーバ２０２ａが、端末３００からの応答用ＵＲＬへのアクセスを外部配信サーバ１４０経由でモバイルサーバ１３２に通知し、モバイルサーバ１３２は、受付情報ＴＢＬ１３４ａの予約フラグをＯＮにし、当該患者の診察予約を確定する。

また、モバイルサーバ１３２は、予約確認案内メール５００ａの配信後所定時間（例えば1時間）経過しても、端末３００から応答用のＵＲＬへのアクセスがない場合には、予約を取り消すようにしてもよい。また、モバイルサーバ１３２は、応答用のＵＲＬへのアクセスが所定時間以上ない場合には、メールサーバ２０２ｃに再度、予約確認案内メール５００ａの配信を指示してもよい。

診察受付後には、モバイルサーバ１３２から受付後のメール依頼電文がクラウド２００に送信され、メールサーバ２０２ｃが、受付後の当日案内メールとして端末３００に配信する。端末３００から、応答用ＵＲＬへのアクセスがあると、クラウド２００がモバイルサーバ１３２に通知する。モバイルサーバ１３２は、クラウド２００に診察状況の情報を通知する。Ｗｅｂサーバ２０２ｂは、Ｗｅｂ画面を作成して、端末３００に送信する。患者は、診察の進行状況や待ち時間等を知ることができる。

なお、電子カルテサーバ１２２、外部配信サーバ１４０、モバイルサーバ１３２、クラウドサーバ２０２ａ等の各サーバは、汎用のコンピュータ等により実現され、よってそのハードウェア構成は、特に図示しないが一般的なものである。すなわち、例えば、ＣＰＵ等の演算プロセッサ、ハードディスク、メモリ等の記憶装置、通信機能部等（何れも不図示）を有する。更に、ディスプレイ、キーボード／マウス等が備えられていても良い。

図２は、患者の最初のメールアドレス登録と登録後の携帯メール呼出を説明する図である。病院内システム１００には、患者の端末３００のメールアドレスを予め登録する登録端末１６０（不図示）が設けられ、モバイルシステム１３０や電子カルテシステム１２０と通信可能に接続される。

患者が、診察券（不図示）を登録端末１６０に挿入すると、登録端末１６０は、診察券の例えば、磁気ストライプに記憶されている患者ＩＤを磁気的に読み取る。登録端末１６０は、患者ＩＤに基づきＱＲコード（登録商標）を作成し、ＱＲコード６００を画面に表示する。ＱＲコード６００の内容は、送信先のメールアドレスと本文（患者ＩＤ）等である。送信先のメールアドレスは、例えば外部配信サーバ１４０のアドレスである。本文（患者ＩＤ）は、個人情報保護の観点から暗号化等のセキュリティ対策が施される。

患者は、端末３００に予め内蔵されたＱＲリーダアプリを起動し、端末３００のカメラを登録端末１６０の画面にかざす。端末３００は、自動的にＱＲコード６００を読み込み、読み込まれたＱＲコード６００から送信先メールアドレスを取得し、患者ＩＤをメール本文とする空メール５２０を送信する。外部配信サーバ１４０が送信先メールアドレスとなる。

外部配信サーバ１４０は、メールサーバ２０２ｃ経由で端末３００からの空メール５２０を受信する。モバイルサーバ１３２は、外部配信サーバ１４０から空メール５２０の受信通知を受ける。モバイルサーバ１３２は、空メール５２０の受信通知に対応して、空メール５２０を送信した患者のメールアドレスを、患者ＩＤに対応して患者ＤＢ１３４の患者情報ＴＢＬ１３４ｂに登録する。

モバイルサーバ１３２は、患者のメールアドレスを患者情報ＴＢＬ１３４ｂに登録し、登録完了メール５３０を患者の端末３００に送信するよう外部配信サーバ１４０経由でメールサーバ２０２ｃに指示する。そして、登録完了メール５３０がメールサーバ２０２ｃから端末３００に配信される。図２のメール画面Ｍ１は、端末３００に表示される登録完了メール５３０の例である。

登録完了後、モバイルサーバ１３２は、メールサーバ２０２ｃに適宜、当日案内メールの通知を指示し、メールサーバ２０２ｃから患者の端末３００に当日案内メールが配信される。メール画面Ｍ２は、端末３００に表示される当日案内メールの一例である。

次に、当日案内メールの内容を具体的に説明する。図３は、予約確認案内メールによって予約が確定される様子を説明する図である。患者は、事前に、電話あるいはＷｅｂ等で診察予約を行っていたとする。患者の端末３００には、予約日の朝あるいは予約時間の所定時間前に、予約確認案内メール５００ａが配信される。図３のメール画面Ｍ３は、予約確認案内メール５００ａの内容である。予約確認案内メール５００ａには、診療科や医師名等の予約内容が記載され、下段には、応答用のＵＲＬ７００が添付される。

端末３００で応答用のＵＲＬ７００がクリック（アクセス）されると、クラウド２００のＷｅｂサーバ２０２ｂはアクセスを検知する。Ｗｅｂサーバ２０２ｂが、外部配信サーバ１４０を経由して、応答用ＵＲＬ７００へのアクセスを、モバイルサーバ１３２に通知する。

モバイルサーバ１３２は、アクセスされた応答用のＵＲＬ７００の情報に基づき、アクセスした患者を特定し、受付情報ＴＢＬ１３４ａで対応する患者の予約フラグをＯＮに設定する。これで予約が確定される。そして、モバイルサーバ１３２は、受付情報ＴＢＬ１３４ａにおける患者の各予約情報を、外部配信サーバ１４０を経由して、Ｗｅｂサーバ２０２ｂに通知する。

一方、端末３００では、ＵＲＬ７００がクリックされた後、Ｗｅｂ画面Ｗ１に切り替わる。Ｗｅｂ画面Ｗ１で「診察待ち情報」がクリックされると、端末３００では、Ｗｅｂ画面Ｗ２が表示される。Ｗｅｂ画面Ｗ２は、モバイルサーバ１３２から通知された患者の予約内容に基づき、Ｗｅｂサーバ２０２ｂで作成された画面である。予約内容がＷｅｂ画面Ｗ２として表示されることで、患者は、予約内容の確認をすることもできる。

次に、図４Ａ、図４Ｂを用いて、モバイルサーバ１３２により患者に適宜配信される当日案内メール５００の例を説明する。図４Ａの左欄のＷｅｂ画面Ｗ２は、診察予約日の当日朝（例えば８：００）の予約確定後に配信される当日案内メールの内容である。Ｗｅｂ画面Ｗ２は、図３で説明したのと同じ画面で、受付はされていない状態での画面である。

Ｗｅｂ画面Ｗ３は、患者が病院での受付をしていない状況（例えば、９：３０）で、端末３００に配信される当日案内メールの画面である。患者は、Ｗｅｂ画面Ｗ３から、既に、診察状況が３０分遅れであることがわかる。

患者は、病院に到着後、病院内システム１００に接続された再来受付機（不図示）に自分の診察カードを入れて受付処理を行う。モバイルサーバ１３２は、患者が受付を済ませたことを再来受付機から通知され、患者ＤＢ１３４の受付情報ＴＢＬ１３４ａに記録する。

Ｗｅｂ画面Ｗ４は、病院での受付を済ませた後、例えば１０：３０に、端末３００に配信される当日案内メールの画面である。Ｗｅｂ画面Ｗ４では、あいかわらず、診察状況が３０分遅れであることが示される。

Ｗｅｂ画面Ｗ５（図４Ｂ）は、混雑しているために、予約時間（１１：００）を経過した後である１２：００に、端末３００に配信される当日案内メールの画面である。Ｗｅｂ画面Ｗ６（図４Ｂ）は、患者の診察が終了した後（１２：３０）に、端末３００に配信される診察が終了したことを知らせる当日案内メールの画面である。

次に、図５及び図６を用いて、診察案内サービスシステム１の各サーバ間における、当日案内メール配信の流れを説明する。図５は、モバイルサーバ１３２から、端末３００に当日案内メールを通知する流れを示す図である。図６は、モバイルサーバ１３２が、当日案内メールに対する端末３００での応答を検知して、予約受付情報に反映させる流れを示す図である。特に、端末３００でなされた予約確認案内メール５００ａに対するアクセスを、モバイルサーバ１３２で検知して、診察予約を確定させる流れを説明する。

図５から説明する。モバイルサーバ１３２は、受付情報取得プロセスと当日予約送信プロセスを並列的に実行する。受付情報取得プロセスとは、患者の受付情報を、患者ＤＢ１３４の受付情報ＴＢＬ１３４ａに、適宜登録する処理である。受付情報とは、患者の診察予約や患者の受付状態あるいは患者の診察状況等に関する情報である。

モバイルサーバ１３２は、起動後に、Ｐ１０からＰ３０の間を無限ループとして、患者の各種受付情報を取得して、取得した受付情報により患者ＤＢ１３４の受付情報ＴＢＬ１３４ａを更新する。例えば、モバイルサーバ１３２は、診察中であれば、電子カルテサーバ１２２を参照して、受付情報ＴＢＬ１３４ａを更新する（ステップＰ１２）。

また、モバイルサーバ１３２は、患者が再来受付機へ受付処理をした場合にも、受付情報ＴＢＬ１３４ａを更新する。また、モバイルサーバ１３２は、患者から電話や端末３００により診察予約があった場合には、受付情報ＴＢＬ１３４ａの診療科や予約時間帯等に予約内容を登録する。モバイルサーバ１３２は、一定時間待機後（ステップＰ１４）に、ステップＰ１０に戻る。

当日予約送信プロセスとは、モバイルサーバ１３２が、当日の来院意思を確認するために、診察予約をした患者に予約確認案内メール５００ａを送信する処理である。前述のように、モバイルサーバ１３２は、予約確認案内メール５００ａ以外の当日案内メール５００も端末３００に送信するので、当日予約送信プロセスは、当日案内メールの送信処理の一部である。

モバイルサーバ１３２は、起動後に、受信ポートをオープンにする（ステップＰ５０）。モバイルサーバ１３２は、Ｐ５２からＰ７０の間を無限ループとして、受付情報ＴＢＬ１３４ａを参照して、予約確認案内メール５００ａを送信すべき患者の有無を判断する。モバイルサーバ１３２は、患者ＩＤの受付情報で本日予約があるかを判断する（ステップＰ５４）。

前述したように、早朝の所定時に、モバイルサーバ１３２は、受付情報ＴＢＬ１３４ａの患者ＩＤの予約時間帯で、本日予約があるかを判断してもよい。また、モバイルサーバ１３２は、現時点から所定時間以内に予約があるかどうかで、予約確認案内メール５００ａの送信を判断してもよい。

モバイルサーバ１３２は、患者ＩＤの予約時間帯で本日予約があると判断すると（ステップＰ５４Ｙｅｓ）、外部配信サーバ１４０に所定のメール依頼電文を送信する（ステップＰ５６）。メール依頼電文の構成例を、図９の電文Ｄ２に示す。

モバイルサーバ１３２は、患者ＩＤの予約時間帯で本日予約がないと判断すると（ステップＰ５４Ｎｏ）、ステップＰ７０に進み、ステップＰ５２に戻る。なお、モバイルサーバ１３２は、予約確認案内メール５００ａ以外の当日案内メール５００（図４ＡのＷｅｂ画面Ｗ３、Ｗｅｂ画面Ｗ４、Ｗｅｂ画面Ｗ５等）の配信についても、外部配信サーバ１４０に所定のメール依頼電文を送信するが、詳細は省略する。

外部情報連携プロセスとは、外部配信サーバ１４０が、起動後に、Ｒ１０からＲ３０の間を無限ループとして、メール依頼電文を送信する処理である。外部配信サーバ１４０は、モバイルサーバ１３２からメール依頼電文を受信して（ステップＲ１２）、クラウドサーバ２０２ａへメール依頼電文を送信する（ステップＲ１４）。

クラウドサーバ２０２ａは、Ｓ１０からＳ３０の間を無限ループとして、外部配信連携プロセスを実行する。クラウドサーバ２０２ａは、起動後に、Ｓ１０からＳ３０の間を無限ループとして、メール配信を行う。

クラウドサーバ２０２ａは、外部配信サーバ１４０からメール依頼電文を受信して（ステップＳ１２）、メールサーバ２０２ｃにメールアドレスと本文を通信する（ステップＳ１４）。メールサーバ２０２ｃは、メール依頼電文に基づき、予約確認案内メール５００ａ（図３のＭ３参照）を作成し、メール依頼電文に記載されたメールアドレスに配信する。予約確認案内メール５００ａの構成は、図９のＤ３に示すようである。

また、クラウドサーバ２０２ａは、受信したメール依頼電文に基づき、実績ＤＢ２０４の病院毎診察実績ＴＢＬ２０４ｂに病院ＩＤ、診療科、診察室、メール配信時刻等を記載する（ステップＳ１６）。

端末３００は、起動後に、Ｔ１０からＴ３０の間を無限ループとして、メールを受信する（ステップＴ１２）。端末３００は、メールサーバ２０２ｃから配信される予約確認案内メール５００ａを受信する。

図６を用いて、配信された予約確認案内メール５００ａへのアクセスにより、モバイルサーバ１３２が予約を確定する処理を説明する。

端末３００は、Ｔ１０からＴ３０の間を無限ループとして以下処理を行う。端末３００は、予約確認案内メール５００ａの受信後に（ステップＴ１２）、当日案内メール５００の本文末尾の応答用ＵＲＬ７００が患者によりアクセス（クリック）されると、メールのリンクを確認して（ステップＴ２０）、リンク先に通知がされる。

クラウドサーバ２０２ａは、Ｓ１０からＳ３０の間を無限ループとして外部配信連携プロセスを実行する。クラウドサーバ２０２ａは、端末３００からのアクセス情報をＷｅｂサーバ２０２ｂから受信すると（ステップＳ２０）、クラウドサーバ２０２ａは、対応する応答用ＵＲＬ７００の内容から、病院と患者ＩＤを特定する。

クラウドサーバ２０２ａは、対応する病院の外部配信サーバ１４０に患者ＩＤにつき予約確認案内メール５００ａにアクセスのあったことを通知する。また、クラウドサーバ２０２ａは、実績ＤＢ２０４の病院毎診察実績ＴＢＬ２０４ｂへ病院ＩＤ、診療科、診察室、メール配信時刻等を記載する（ステップＳ２４）。

外部配信サーバ１４０は、Ｒ１０からＲ３０の間を無限ループとして外部情報連携プロセスを実行する。外部配信サーバ１４０は、クラウドサーバ２０２ａからのアクセス情報を受信すると（ステップＲ２０）、モバイルサーバ１３２へアクセスする（ステップＲ２２）。

モバイルサーバ１３２は、Ｐ１００からＰ１１０の間を無限ループとして、待ち人数更新プロセスを実行する。モバイルサーバ１３２は、外部配信サーバ１４０からアクセス情報を受信すると（ステップＰ１０２）、電子カルテサーバ１２２を参照して、患者ＤＢ１３４の受付情報ＴＢＬ１３４ａの来院予定を更新する（ステップＰ１０４）。モバイルサーバ１３２は、順番をカウントして待ち人数を返す（ステップＰ１０６）。

以上説明したように本実施形態によれば、メールに記載された応答用ＵＲＬをクリックするという簡単な操作で来院意思を確認し、従来のようなメール返信をするというような面倒な操作を不要にしたので、患者からの来院応答をより確実に期待できる。

また、応答用ＵＲＬを患者と病院を特定する情報のみで構成するので、患者の診察情報が外部に流出するおそれもない。

なお、本発明は上述した実施形態そのままに限定されるものではなく、実施段階でのその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素を適宜組み合わせても良い。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。このような、発明の趣旨を逸脱しない範囲内において種々の変形や応用が可能であることはもちろんである。

１ 診察案内サービスシステム
１００ 病院内システム
１２０ 電子カルテシステム
１２２ 電子カルテサーバ
１２４ 電子カルテクライアント
１３０ モバイルシステム
１３２ モバイルサーバ
１３４ 患者ＤＢ
１３４ａ 受付情報ＴＢＬ
１３４ｂ 患者情報ＴＢＬ
１４０ 外部配信サーバ
１５０ 専用プロトコル
１６０ 登録端末
２００ クラウド
２０２ａ クラウドサーバ
２０２ｂ Ｗｅｂサーバ
２０２ｃ メールサーバ
２０４ 実績ＤＢ
２０６ 蓄積ＤＢ
３００ 端末
４００ ネットワーク
５００ 当日案内メール
５００ａ 予約確認案内メール
５２０ 空メール
５３０ 登録完了メール
７００ ＵＲＬ７００

Claims (7)

1. 患者の端末に診察に関する案内メールを配信する診察案内サービス装置において、
   既に診察予約を済ませた患者である予約患者の端末に、少なくとも当該予約患者を特定する情報が組み込まれたＵＲＬを含む、当該予約患者の来院意思を確認するための予約確認案内メールを事前に配信し、
   前記予約確認案内メールが配信された端末における前記ＵＲＬへのアクセスを検知した場合に、当該ＵＲＬに組み込まれた患者を特定する情報に基づき、対応する予約患者の来院意思があるものとして当該予約患者の診察予約を確定させる
   ことを特徴とする診察案内サービス装置。
2. 前記診察案内サービス装置は、前記予約確認案内メールのＵＲＬへのアクセスを検知して予約患者の診察予約を確定させた後に、前記予約患者の端末に前記案内メールとして診察状況を通知する
   ことを特徴とする請求項１に記載の診察案内サービス装置。
3. 前記診察案内サービス装置は、前記予約患者の端末に、当日の診察開始後には、前記案内メールとして、少なくとも待ち人数を含む診察状況を通知する
   ことを特徴とする請求項１に記載の診察案内サービス装置。
4. 病院のネットワーク内に配置される前記診察案内サービス装置は、外部配信サーバを介して外部のネットワークに接続され、
   前記診察案内サービス装置は、外部のネットワークに設置されたメールサーバから前記予約患者の端末に前記案内メールが配信されるように、前記予約確認案内メールを作成するためのメール依頼電文を前記外部配信サーバ経由で前記メールサーバに送信し、
   前記診察案内サービス装置は、外部のネットワークに設置され前記予約患者の端末で行われる前記ＵＲＬへのアクセスを受信するＷｅｂサーバから、前記ＵＲＬへのアクセスを前記外部配信サーバ経由で受信する
   ことを特徴とする請求項１に記載の診察案内サービス装置。
5. 前記診察案内サービス装置は、前記予約確認案内メールのＵＲＬに、病院識別情報を含ませる
   ことを特徴とする請求項１に記載の診察案内サービス装置。
6. 患者の診察予約状況が患者の端末のメールアドレスに対応して記憶された患者データベースを参照して、既に診察予約を済ませた前記患者の来院意思を確認するための予約確認案内メールを前記患者の端末に送信する診察案内サービス装置と、
   病院のネットワークに接続された前記診察案内サービス装置を、病院外部のネットワークに接続する外部配信サーバと、
   前記病院外部のネットワークに接続され、前記外部配信サーバを経由して前記診察案内サービス装置から送信されるメール依頼電文に基づき、少なくとも前記患者を特定する情報が組み込まれたＵＲＬを含む前記予約確認案内メールを作成して前記患者の端末に送信するメールサーバと、
   前記病院外部のネットワークに接続され、前記患者の端末から前記予約確認案内メールのＵＲＬへのアクセスを検知するＷｅｂサーバと、を備え、
   前記診察案内サービス装置は、既に診察予約を済ませた患者である予約患者の端末に、当該予約患者の来院意思を確認するために前記予約確認案内メールを事前に配信し、前記ＷｅｂサーバでアクセスがあったＵＲＬに組み込まれた情報に基づき、対応する予約患者の来院意思があるものとして当該予約患者の診察予約を確定する
   ことを特徴とする診察案内サービスシステム。
7. 患者の端末に診察に関する案内メールを配信する診察案内サービス装置のコンピュータによる診察案内サービス方法において、前記コンピュータが、
   既に診察予約を済ませた患者である予約患者の端末に、少なくとも当該予約患者を特定する情報が組み込まれたＵＲＬを含む、当該予約患者の来院意思を確認するための予約確認案内メールを事前に配信し、
   前記予約確認案内メールが配信された端末における前記ＵＲＬへのアクセスを検知した場合に、当該ＵＲＬに組み込まれた患者を特定する情報に基づき、対応する予約患者の来院意思があるものとして当該予約患者の診察予約を確定させる
   ことを特徴とする診察案内サービス方法。