JP6401659B2 - 院外サーバ、診療案内サービスシステム及び診療案内方法 - Google Patents

Description

本発明は、院外サーバ、診療案内サービスシステム及び診療案内方法に関する。

インターネットの普及に伴い、自院の診療案内を載せたホームページを作成する病院が増えている。このため、診療を希望する患者は、各病院のホームページに掲載された情報や、各病院に対する他人の評判等を参考にして、診療を受ける病院を選定することが多くなっている。

特開２００２−０３２４７５号公報 特開２００７−１２２１１５号公報

ホームページに掲載された診療案内には、一般に、曜日毎の診療可能時間が含まれている。診療を希望する患者は、診療可能時間のうち、自分の都合が良い時間に直接来院するため、来院するまで、病院の混雑状況を把握することが難しい。このため、患者は、来院後、診療が開始されるまでに長時間待たされることがあるため、患者の利便性が低下することがある。

例えば院内システムの診療実績を集計することで、リアルタイムの混雑状況を取得することが考えられる。しかし、セキュリティの観点から診療実績を院外に持ち出すことは難しい。よって、院外の患者に対して混雑状況を伝えるために、院内ネットワークと切り離されたシステムやサーバ（つまり、院外のシステムや院外のサーバ）によって混雑状況を算出することが望まれている。

開示の技術は、上記に鑑みてなされたものであって、患者の利便性を向上することを目的とする。

開示の態様では、院外サーバは、通信部と、算出部と、生成部とを有する。前記通信部は、診療の予約に対する当該診療の開始実績を示す電文を受信する。前記算出部は、前記開始実績に基づいて、診療の開始の遅延の統計を算出する。前記生成部は、前記統計の表示データを生成する。

開示の態様によれば、患者の利便性を向上することができる。

図１は、実施例１の診療案内サービスシステムの構成例を示す図である。 図２は、実施例１の患者ＤＢの一例を示す図である。 図３は、実施例１の実績ＤＢの一例を示す図である。 図４は、実施例１の蓄積ＤＢの一例を示す図である。 図５は、実施例１のモバイルサーバの処理例の説明に供するフローチャートである。 図６は、実施例１の診療電文の一例を示す図である。 図７は、実施例１のメール依頼電文の一例を示す図である。 図８は、実施例１の配信サーバの処理例の説明に供するフローチャートである。 図９は、実施例１の外部サーバの構成例を示す機能ブロック図である。 図１０は、実施例１の外部サーバの処理例の説明に供するフローチャートである。 図１１は、実施例１の呼出メールの一例を示す図である。 図１２は、実施例１のモバイル端末における画面表示例を示す図である。 図１３は、実施例２の外部サーバのハードウェア構成例を示す図である。

以下に、本願の開示する院外サーバ、診療案内サービスシステム及び診療案内方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本願の開示する院外サーバ、診療案内サービスシステム及び診療案内方法が限定されるものではない。また、実施例において同一の機能を有する構成、及び、同一の処理を行うステップには同一の符号を付し、重複する説明を省略する。

［実施例１］
＜診療案内サービスシステムの構成＞
図１は、実施例１の診療案内サービスシステムの構成例を示す図である。図１において、診療案内サービスシステム１は、院内システム１０と、外部サーバ２５とを有する。院内システム１０は、Ａ病院、Ｂ病院、Ｃ病院、Ｄ病院等、病院毎に院内に設けられ、複数の病院において同一の構成を採る。外部サーバ２５は、Ａ病院、Ｂ病院、Ｃ病院、Ｄ病院等の複数の病院に対して１つ設けられ、院外に設置される。つまり、外部サーバ２５は、院外サーバの一例である。院内システム１０は、電子カルテシステム１１と、モバイルサーバ２３と、配信サーバ２４とを有する。電子カルテシステム１１は、電子カルテサーバ２１と、電子カルテクライアント２２とを有する。モバイルサーバ２３は、患者ＤＢ（DataBase）３１を有する。外部サーバ２５は、実績ＤＢ３２と、蓄積ＤＢ３３とを有する。院内システム１０の配信サーバ２４と、外部サーバ２５とは、インターネット３０を介して接続される。患者が所有するモバイル端末１５は、インターネット３０を介して、外部サーバ２５にアクセス可能である。モバイル端末１５として、例えば、携帯電話、スマートフォン、タブレット端末等が挙げられる。なお、外部サーバ２５にアクセス可能なユーザ端末は、モバイル端末に限定されず、例えば、パーソナルコンピュータ等であっても良い。

＜患者ＤＢの構成＞
図２は、実施例１の患者ＤＢの一例を示す図である。図２において、患者ＤＢ３１は、受付情報テーブルと、患者情報テーブルとを有する。受付情報テーブルに記憶される各レコードは、「患者ＩＤ（IDentifier）」と、「受付日」と、「診療科ＩＤ」と、「予約時間」との各フィールドを有する。患者情報テーブルに記憶される各レコードは、「患者ＩＤ」と、「メールアドレス」との各フィールドを有する。

「患者ＩＤ」は、患者を一意に特定可能な識別子を示す。「受付日」は、患者からの診療予約を受け付けた日付を示す。「診療科ＩＤ」は、診療予約が為された診療科を一意に特定可能な識別子を示す。「予約時間」は、患者から受け付けた診療予約の日時を示し、例えば、「ＹＹＹＹ年ＭＭ月ＤＤ日ＴＴ時」のフォーマットに従って記憶される。「予約時間」における「ＴＴ時」は、６０分毎に区切られた時間を示し、例えば、「９時」であれば９時００分から９時５９分までの時間帯を表し、「１３時」であれば１３時００分から１３時５９分までの時間帯を表す。「メールアドレス」は、電子メールの宛先アドレスを示す。

受付情報テーブルの各フィールドの値、及び、患者情報テーブルの各フィールドの値は、モバイルサーバ２３によって、電子カルテサーバ２１から取得されて、患者ＤＢ３１に記憶される。

＜実績ＤＢの構成＞
図３は、実施例１の実績ＤＢの一例を示す図である。図３において、実績ＤＢ３２は、診療実績テーブルを有する。診療実績テーブルに記憶される各レコードは、「病院ＩＤ」と、「診療科ＩＤ」と、「予約時間」と、「遅延フラグ」と、「遅延時間」との各フィールドを有する。「病院ＩＤ」は、病院を一意に特定可能な識別子を示す。「遅延フラグ」は、「予約時間」に対する「呼出時刻」の遅延時間が所定値以上であるか否かを示すフラグであり、遅延時間が所定値以上であるときに「オン（例えば、１）」に、遅延時間が所定値未満であるときに「オフ（例えば、０）」に設定される。「遅延時間」は、「予約時間」に対する「呼出時刻」の遅延時間を示す。「遅延時間」の算出方法の詳細は後述する。

＜蓄積ＤＢの構成＞
図４は、実施例１の蓄積ＤＢの一例を示す図である。図４において、蓄積ＤＢ３３は、病院実績テーブルと、病院情報テーブルと、診療科情報テーブルとを有する。病院実績テーブルに記憶される各レコードは、「病院ＩＤ」と、「診療科ＩＤ」と、「予約時間」と、「平均診療人数」と、「平均遅延人数」と、「平均遅延時間」との各フィールドを有する。平均診療人数、平均遅延人数及び平均遅延時間の算出方法の詳細は後述する。病院情報テーブルに記憶される各レコードは、「病院ＩＤ」と、「病院名」との各フィールドを有する。「病院名」は、「病院ＩＤ」に対応付けて予め登録されている。診療科情報テーブルに記憶される各レコードは、「診療科ＩＤ」と、「診療科名」との各フィールドを有する。「診療科名」は、「診療科ＩＤ」に対応付けて予め登録されている。

＜モバイルサーバの処理＞
図５は、実施例１のモバイルサーバの処理例の説明に供するフローチャートである。図１に示すモバイルサーバ２３は、例えば、図５に示すフローチャートに従った処理を行う。

図５において、モバイルサーバ２３は、ステップＳ２０１〜Ｓ２０３の処理を無限に繰り返す。また、モバイルサーバ２３は、ステップＳ２０１〜Ｓ２０３の処理と並行して、ステップＳ２１１〜Ｓ２１５の処理を無限に繰り返す。

ステップＳ２０１では、モバイルサーバ２３は、電子カルテサーバ２１を参照し、電子カルテサーバ２１に記憶されている情報のうち、互いに対応付けられている患者ＩＤと、受付日と、診療科ＩＤと、予約時間と、メールアドレスとの各情報を取得する。そして、モバイルサーバ２３は、取得した各情報に基づいて、患者ＤＢ３１の受付情報テーブル及び患者情報テーブルに対してレコードを追加またはレコードを更新して患者ＤＢ３１を更新する。電子カルテサーバ２１には、モバイルサーバ２３によって取得される情報以外にも、患者毎の診療結果、治療内容、投薬結果等の個人情報が記憶されているが、モバイルサーバ２３は、電子カルテサーバ２１に記憶されている情報のうち、患者ＩＤ、受付日、診療科ＩＤ、予約時間及びメールアドレスのみを電子カルテサーバ２１から取得する。また、モバイルサーバ２３は、受付情報テーブル及び患者情報テーブルのレコードの更新を、患者ＩＤをキーにして行う。

ステップＳ２０３では、モバイルサーバ２３は、一定時間ウェイトする。

一方で、ステップＳ２１１では、モバイルサーバ２３は、電子カルテクライアント２２から「診療電文」を受信するまで待機する（ステップＳ２１１：Ｎｏ）。モバイルサーバ２３が診療電文を受信すると（ステップＳ２１１：Ｙｅｓ）、処理はステップＳ２１３へ進む。

ここで、診療電文の構成を図６に示す。図６は、実施例１の診療電文の一例を示す図である。診療電文は、「患者ＩＤ」と、「呼出時刻」との各フィールドを有する。「呼出時刻」は、当該患者ＩＤの患者の診療開始に伴って当該患者が呼び出された時刻を示す。また、電子カルテクライアント２２に対する、例えば担当医師からの呼出入力あった時刻「ＴＴ時ＭＭ分」が、電子カルテクライアント２２によって「呼出時刻」として登録される。電子カルテクライアント２２は、呼出入力を為された時点で、診療電文を生成し、生成した診療電文をモバイルサーバ２３へ送信する。

図５に戻り、ステップＳ２１３では、診療電文を受信したモバイルサーバ２３は、診療電文に含まれる患者ＩＤをキーにして、患者ＤＢ３１の患者情報テーブルを検索し、当該患者ＩＤに対応するメールアドレスを患者情報テーブルから取得する。

次いで、ステップＳ２１５では、モバイルサーバ２３は、「メール依頼電文」を生成し、生成したメール依頼電文を配信サーバ２４へ送信する。

ここで、メール依頼電文の構成を図７に示す。図７は、実施例１のメール依頼電文の一例を示す図である。メール依頼電文は、「メールアドレス」と、「病院ＩＤ」と、「診療科ＩＤ」と、「予約時間」と、「呼出時刻」との各フィールドを有する。モバイルサーバ２３は、ステップＳ２１３で取得したメールアドレスを、メール依頼電文の「メールアドレス」フィールドに設定する。また、モバイルサーバ２３は、診療電文に含まれる呼出時刻を、メール依頼電文の「呼出時刻」フィールドに設定する。また、モバイルサーバ２３は、診療電文に含まれる患者ＩＤをキーにして、患者ＤＢ３１の受付情報テーブルを検索し、当該患者ＩＤに対応する診療科ＩＤ及び予約時間を受付情報テーブルから取得し、取得した診療科ＩＤ及び予約時間を、メール依頼電文の「診療科ＩＤ」及び「予約時間」の各フィールドに設定する。また、モバイルサーバ２３には、モバイルサーバ２３が設置された病院の病院ＩＤが予め登録されており、モバイルサーバ２３は、その登録されている病院ＩＤを、メール依頼電文の「病院ＩＤ」のフィールドに設定する。

このように、メール依頼電文は、「病院ＩＤ」と、「診療科ＩＤ」と、「予約時間」と、「呼出時刻」との各フィールドを有する。また、「呼出時刻」は、診療の開始時刻に相当する。よって、メール依頼電文は、診療の予約に対する当該診療の開始実績を示す電文の一例である。また、メール依頼電文は、患者毎の診療結果、治療内容、投薬結果等の個人情報を含まない。

＜配信サーバの処理＞
図８は、実施例１の配信サーバの処理例の説明に供するフローチャートである。図１に示す配信サーバ２４は、例えば、図８に示すフローチャートに従った処理を行う。

図８において、配信サーバ２４は、ステップＳ２２１〜Ｓ２２３の処理を無限に繰り返す。

ステップＳ２２１では、配信サーバ２４は、モバイルサーバ２３からメール依頼電文を受信するまで待機する（ステップＳ２２１：Ｎｏ）。配信サーバ２４がメール依頼電文を受信すると（ステップＳ２２１：Ｙｅｓ）、処理はステップＳ２２３へ進む。

ステップＳ２２３では、配信サーバ２４は、受信したメール依頼電文をインターネット３０を介して外部サーバ２５へ送信する。

＜外部サーバの構成＞
図９は、実施例１の外部サーバの構成例を示す機能ブロック図である。図９において、外部サーバ２５は、通信部１０１と、呼出メール生成部１０３と、実績更新部１０５と、統計算出部１０７と、表示データ生成部１０９と、実績ＤＢ３２と、蓄積ＤＢ３３とを有する。

通信部１０１は、インターネット３０を介して、配信サーバ２４及びモバイル端末１５と通信する。通信部１０１は、配信サーバ２４からメール依頼電文を受信し、受信したメール依頼電文を、呼出メール生成部１０３及び実績更新部１０５へ出力する。また、通信部１０１は、呼出メール生成部１０３によって生成された「呼出メール」を、呼出メールに含まれるメールアドレス宛に送信する。また、通信部１０１は、モバイル端末１５から受信した表示要求を表示データ生成部１０９へ出力する。また、通信部１０１は、表示データ生成部１０９によって生成された表示データを、表示要求元のモバイル端末１５へ送信する。

呼出メール生成部１０３は、通信部１０１から入力されたメール依頼電文に基づいて呼出メールを生成し、生成した呼出メールを通信部１０１へ出力する。呼出メール生成部１０３は、呼出メールを生成する際に、メール依頼電文に基づいて、蓄積ＤＢ３３の病院情報テーブル及び診療科情報テーブルを参照する。

実績更新部１０５は、通信部１０１から入力されたメール依頼電文に基づいて、実績ＤＢ３２の診療実績テーブルを更新する。

統計算出部１０７は、診療の開始の遅延の統計を算出し、算出結果を蓄積ＤＢ３３の病院実績テーブルに設定する。

表示データ生成部１０９は、通信部１０１から入力された表示要求（つまり、モバイル端末１５からの表示要求）に従って、蓄積ＤＢ３３の病院実績テーブルを参照し、診療の開始の遅延の統計の表示データを生成する。表示データ生成部１０９は、生成した表示データを通信部１０１へ出力する。

＜外部サーバの処理＞
図１０は、実施例１の外部サーバの処理例の説明に供するフローチャートである。図９に示す外部サーバ２５は、例えば、図１０に示すフローチャートに従った処理を行う。

図１０において、外部サーバ２５は、ステップＳ２３１〜Ｓ２３５の処理を無限に繰り返す。また、外部サーバ２５は、ステップＳ２３１〜Ｓ２３５の処理と並行して、ステップＳ２４１〜Ｓ２５１の処理を行う。なお、ステップＳ２４１〜Ｓ２５１の処理は、例えば、一定時間毎に行われても良く、また、処理要求に応じて行われても良い。

ステップＳ２３１では、呼出メール生成部１０３及び実績更新部１０５は、通信部１０１が配信サーバ２４からメール依頼電文を受信するまで待機する（ステップＳ２３１：Ｎｏ）。通信部１０１がメール依頼電文を受信すると（ステップＳ２３１：Ｙｅｓ）、処理はステップＳ２３３へ進む。

ステップＳ２３３では、呼出メール生成部１０３は、通信部１０１から入力されたメール依頼電文に基づいて呼出メールを生成し、生成した呼出メールを通信部１０１へ出力する。図１１は、実施例１の呼出メールの一例を示す図である。呼出メールは、「メールアドレス」と、「メール本文」との各フィールドを有する。呼出メール生成部１０３は、メール依頼電文に含まれるメールアドレスを、呼出メールの「メールアドレス」フィールドに設定する。また、呼出メール生成部１０３は、メール依頼電文に含まれる病院ＩＤ、診療科ＩＤ及び呼出時刻に基づいて、呼出メールの「メール本文」フィールドを設定する。すなわち、呼出メール生成部１０３は、メール依頼電文に含まれる病院ＩＤ及び診療科ＩＤに該当する病院名及び診療科名を蓄積ＤＢ３３の病院情報テーブル及び診療科情報テーブルより取得し、例えば、「Ａ病院の内科でＴＴ時ＭＭ分に診療の呼出がありました。」という文を呼出メールの「メール本文」フィールドに設定する。通信部１０１は、呼出メール生成部１０３によって生成された呼出メールを、呼出メールに含まれるメールアドレス宛に送信する。

次いで、ステップＳ２３５では、実績更新部１０５は、通信部１０１から入力されたメール依頼電文に基づいて、実績ＤＢ３２の診療実績テーブルを更新する。実績更新部１０５は、メール依頼電文に含まれる病院ＩＤ、診療科ＩＤ及び予約時間と、実績更新部１０５が算出する遅延フラグ及び遅延時間とを有するレコードを形成し、形成したレコードを診療実績テーブルに追加して更新する。

ここで、実績更新部１０５は、メール依頼電文に含まれる予約時間と呼出時刻とから遅延時間を算出する。例えば、実績更新部１０５は、「遅延時間＝呼出時刻ＴＴ時ＭＭ分−（予約時間におけるＴＴ時＋５９分）」という式に従って、遅延時間を算出する。よって例えば、予約時間におけるＴＴ時が「９時」であり、呼出時刻ＴＴ時ＭＭ分が「１０時４０分」であれば、遅延時間は「＋４１分」と算出される。また例えば、予約時間におけるＴＴ時が「１３時」であり、呼出時刻ＴＴ時ＭＭ分が「１３時３０分」であれば、遅延時間は「−２９分」と算出される。遅延時間が＋の値として算出されるときは、予約時間に対して実際に診療が開始された時刻が遅延していることを示し、遅延時間が−の値として算出されるときは、予約時間内に診療が開始されたことを示す。また、実績更新部１０５は、算出した遅延時間が所定値以上であるときに遅延フラグをオン（例えば、１）に設定し、算出した遅延時間が所定値未満であるときに遅延フラグをオフ（例えば、０）に設定する。例えば、遅延時間と比較される所定値は「３０分」であり、算出された遅延時間が３０分以上のときは遅延フラグがオンに設定され、算出された遅延時間が３０分未満のときは遅延フラグがオフに設定される。よって例えば、所定値が「３０分」であるのに対し、上記のように遅延時間が「＋４１分」と算出されたときは、遅延フラグがオンに設定される。また例えば、所定値が「３０分」であるのに対し、上記のように遅延時間が「−２９分」と算出されたときは、遅延フラグがオフに設定される。なお、実績更新部１０５は、遅延フラグがオンとなるときにだけ、実績ＤＢ３２の診療実績テーブルの遅延時間を設定しても良い。

一方で、統計算出部１０７は、実績ＤＢ３２の診療実績テーブルを参照し、ループ１〜４の条件下で、実績ＤＢ３２の診療実績テーブルにおいて、全レコード、全病院ＩＤ、全診療科ＩＤ及び全予約時間について、病院ＩＤ毎、診療科ＩＤ毎及び予約時間毎に、ステップＳ２４１〜Ｓ２５１の処理を繰り返す。ステップＳ２４１〜Ｓ２４９の処理が、実績ＤＢ３２の診療実績テーブルの全レコードを対象として、全病院ＩＤ、全診療科ＩＤ及び全予約時間について繰り返されることにより、病院ＩＤ毎、診療科ＩＤ毎及び予約時間毎に、平均診療人数、平均遅延人数及び平均遅延時間が算出される。

ここで、上記のように、「呼出時刻」は、診療の開始時刻に相当し、また、メール依頼電文は、診療の予約に対する当該診療の開始実績を示す電文の一例である。よって、病院ＩＤ毎、診療科ＩＤ毎及び予約時間毎の平均遅延人数及び平均遅延時間は、診療の開始実績に基づいて算出される、診療の開始の遅延の統計の一例である。統計算出部１０７は、診療の開始の遅延の統計の一例としての平均遅延人数及び平均遅延時間を以下のようにして求める。

すなわち、ステップＳ２４１では、統計算出部１０７は、「合計診療人数」、「合計遅延人数」及び「合計遅延時間」を０に設定して初期化する。

次いで、ステップＳ２４３では、統計算出部１０７は、合計診療人数をインクリメントして、対象とする病院ＩＤ、診療科ＩＤ及び予約時間の合計診療人数を１だけ増加させる。

次いで、ステップＳ２４５では、統計算出部１０７は、実績ＤＢ３２の診療実績テーブルにおける対象レコードの遅延フラグがオンか否かを判断する。対象レコードの遅延フラグがオンのときは（ステップＳ２４５：Ｙｅｓ）、処理はステップＳ２４７へ進み、対象レコードの遅延フラグがオフのときは（ステップＳ２４５：Ｎｏ）、ステップＳ２４７の処理が行われることなく、処理はステップＳ２４９へ進む。

ステップＳ２４７では、統計算出部１０７は、合計遅延人数をインクリメントする。つまり、統計算出部１０７は、対象レコードにおける遅延時間フィールドの値が所定値以上のときに、合計遅延人数を１だけ増加させる。また、ステップＳ２４７では、統計算出部１０７は、合計遅延時間に、対象レコードにおける遅延時間フィールドの値を加算する。つまり、統計算出部１０７は、対象レコードにおける遅延時間フィールドの値が所定値以上のときに、合計遅延時間に遅延時間を加算する。

ループ４の条件を満たして、処理がステップＳ２４９へ進むときには、対象とした病院ＩＤ、診療科ＩＤ及び予約時間について合計診療人数、合計遅延人数及び合計遅延時間が算出されている。

そこで、ステップＳ２４９では、統計算出部１０７は、対象とした病院ＩＤ、診療科ＩＤ及び予約時間について、平均診療人数、平均遅延人数及び平均遅延時間を算出する。統計算出部１０７は、蓄積ＤＢ３３の病院実績テーブルから、対象とした病院ＩＤ、診療科ＩＤ及び予約時間に対応する平均診療人数、平均遅延人数及び平均遅延時間を取得する。そして、統計算出部１０７は、取得した平均診療人数と、ステップＳ２４３で算出した合計診療人数とを合算し、合算結果を２で割った値を、対象とした病院ＩＤ、診療科ＩＤ及び予約時間に対応する新たな平均診療人数として算出する。また、統計算出部１０７は、取得した平均遅延人数と、ステップＳ２４７で算出した合計遅延人数とを合算し、合算結果を２で割った値を、対象とした病院ＩＤ、診療科ＩＤ及び予約時間に対応する新たな平均診療人数として算出する。また、統計算出部１０７は、取得した平均遅延時間と、ステップＳ２４７で算出した合計遅延時間をステップＳ２４７で算出した合計遅延人数で割った値とを合算し、合算結果を２で割った値を、対象とした病院ＩＤ、診療科ＩＤ及び予約時間に対応する新たな平均遅延時間として算出する。

次いで、ステップＳ２５１では、統計算出部１０７は、ステップＳ２４９で新たに算出した平均診療人数、平均遅延人数及び平均遅延時間によって、蓄積ＤＢ３３の病院実績テーブルにおいて、対象とした病院ＩＤ、診療科ＩＤ及び予約時間に対応するレコードの平均診療人数、平均遅延人数及び平均遅延時間の各フィールドを更新する。

ステップＳ２５１の処理後、処理はステップＳ２４１に戻り、次の予約時間を対象として、ステップＳ２４１〜Ｓ２５１の処理が行われる。

このように、ステップＳ２４１〜Ｓ２５１の処理が、実績ＤＢ３２の診療実績テーブルの全レコードを対象として、全病院ＩＤ、全診療科ＩＤ及び全予約時間について、病院ＩＤ毎、診療科ＩＤ毎及び予約時間毎に繰り返される。よって、ループ１〜４の条件を満たしたときには、蓄積ＤＢ３３の病院実績テーブルにおいて、全病院ＩＤ、全診療科ＩＤ及び全予約時間について、平均診療人数、平均遅延人数及び平均遅延時間が新たな値に更新されている。

＜画面表示例＞
表示データ生成部１０９は、蓄積ＤＢ３３を参照して、病院毎、診療科毎及び予約時間毎の平均診療人数、平均遅延人数及び平均遅延時間を画面表示するデータ（つまり、表示データ）を生成する。表示データの生成は、通信部１０１から入力される表示要求（つまり、モバイル端末１５からの表示要求）に従って行われる。この表示要求には、例えば、モバイル端末１５のユーザによって表示対象に指定された病院を特定する病院ＩＤが含まれる。また、表示要求には、病院ＩＤの他に、モバイル端末１５のユーザによって表示対象に指定された診療科を特定する診療科ＩＤが含まれても良い。

表示データ生成部１０９は、表示要求に含まれる病院ＩＤをキーにして蓄積ＤＢ３３の病院実績テーブルを検索し、当該病院ＩＤに対応する全診療科ＩＤを取得する。また、表示データ生成部１０９は、当該病院ＩＤに対応する全診療科ＩＤについて、予約時間毎の平均診療人数、平均遅延人数及び平均遅延時間を病院実績テーブルから取得する。また、表示データ生成部１０９は、表示要求に含まれる病院ＩＤをキーにして蓄積ＤＢ３３の病院情報テーブルを検索し、当該病院ＩＤに対応する病院名を病院情報テーブルから取得する。また、表示データ生成部１０９は、病院実績テーブルから取得した診療科ＩＤをキーにして蓄積ＤＢ３３の診療科情報テーブルを検索し、当該診療科ＩＤに対応する診療科名を診療科情報テーブルから取得する。そして、表示データ生成部１０９は、病院名、診療科名、及び、予約時間毎の平均診療人数、平均遅延人数及び平均遅延時間を画面表示するデータを生成し、生成した表示データを通信部１０１へ出力する。通信部１０１は、表示データを、表示要求の送信元のモバイル端末１５へ送信する。なお、表示要求に診療科ＩＤが含まれる場合には、表示データ生成部１０９は、当該診療科ＩＤだけを対象として表示データを生成する。

よって、モバイル端末１５の画面には、例えば、図１２に示すような画像が表示される。図１２は、実施例１のモバイル端末における画面表示例を示す図である。図１２では、一例として、Ａ病院を表示対象として指定したユーザのモバイル端末１５に表示される統計情報が示されている。例えば、Ａ病院の内科では、９：００〜９：５９の予約時間において、平均診療人数が２０人、平均遅延人数が５人、及び、平均遅延時間が３０分であることが示されている。また、平均遅延人数は、数字で表示されるとともに、＊を用いたグラフでも表示される。Ａ病院の外科についても、Ａ病院の内科と同様の形式で、統計情報が表示される。

以上のように、実施例１では、外部サーバ２５は、通信部１０１と、統計算出部１０７と、表示データ生成部１０９とを有する。通信部１０１は、診療の予約に対する当該診療の開始実績を示す電文としてメール依頼電文を受信する。統計算出部１０７は、メール依頼電文に示された開始実績に基づいて、診療の開始の遅延の統計を算出する。表示データ生成部１０９は、診療の開始の遅延の統計の表示データを生成する。

こうすることで、患者は来院予定の病院の診療の開始の遅延状況（つまり、混雑状況）を、モバイル端末等を用いて、来院前に事前に把握することができるため、患者の利便性を向上することができる。また、メール依頼電文には、患者毎の診療結果、治療内容、投薬結果等の個人情報が含まれないため、診療情報のセキュリティを確保したまま、来院予定の患者に対し、診療の開始の遅延状況を提示することができる。

また、実施例１では、統計算出部１０７は、メール依頼電文に含まれる、病院ＩＤと、診療の予約時間と、当該診療の開始時刻に相当する呼出時刻とに基づいて、病院毎に、診療の開始の遅延の統計を算出する。

こうすることで、患者は、複数の病院の混雑状況を比較した上で、来院する病院を選択することができる。

また、実施例１では、統計算出部１０７は、診療の開始の遅延の統計として、診療の予約時間と、当該診療の開始時刻とに基づいて、予約時間毎に、診療開始遅延時間を示す平均遅延時間を算出する。

こうすることで、患者は、来院前に事前に、診療開始までの待ち時間を時間帯毎に把握することができるため、例えば、病院が空いている時間に来院することが可能になる。

［実施例２］
＜外部サーバのハードウェア構成＞
外部サーバ２５は、例えば、次のようなハードウェア構成により実現することができる。図１３は、実施例２の外部サーバのハードウェア構成例を示す図である。図１３に示すように、外部サーバ２５は、ハードウェアの構成要素として、プロセッサ２５ａと、メモリ２５ｂと、ＨＤＤ（Hard Disk Drive）２５ｃと、ネットワークインタフェースモジュール２５ｄとを有する。プロセッサ２５ａの一例として、ＣＰＵ（Central Processing Unit），ＤＳＰ（Digital Signal Processor），ＦＰＧＡ（Field Programmable Gate Array）等が挙げられる。また、外部サーバ２５は、プロセッサ２５ａと周辺回路とを含むＬＳＩ（Large Scale Integrated circuit）を有しても良い。メモリ２５ｂの一例として、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory），ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。通信部１０１は、ネットワークインタフェースモジュール２５ｄによって実現される。呼出メール生成部１０３と、実績更新部１０５と、統計算出部１０７と、表示データ生成部１０９とは、プロセッサ２５ａによって実現される。実績ＤＢ３２と、蓄積ＤＢ３３とは、メモリ２５ｂまたはＨＤＤ２５ｃによって実現される。

また、外部サーバ２５での上記説明における各処理は、各処理に対応するプログラムを外部サーバ２５のプロセッサ２５ａに実行させることによって実現してもよい。例えば、上記説明における各処理に対応するプログラムがメモリ２５ｂまたはＨＤＤ２５ｃに記憶され、プログラムがプロセッサ２５ａによってメモリ２５ｂまたはＨＤＤ２５ｃから読み出されて実行されてもよい。

１ 診療案内サービスシステム
１０ 院内システム
１１ 電子カルテシステム
２１ 電子カルテサーバ
２２ 電子カルテクライアント
２３ モバイルサーバ
２４ 配信サーバ
２５ 外部サーバ
３１ 患者ＤＢ
３２ 実績ＤＢ
３３ 蓄積ＤＢ
１０１ 通信部
１０３ 呼出メール生成部
１０５ 実績更新部
１０７ 統計算出部
１０９ 表示データ生成部

Claims (5)

1. 院内サーバが、患者ＩＤと、当該患者ＩＤに対応する患者の診療の呼出時刻とを含む第一電文を電子カルテシステムから受信したときに生成する第二電文であって、前記患者ＩＤに対応するメールアドレスと、前記診療が行われる病院を示す病院ＩＤと、前記診療が行われる診療科を示す診療科ＩＤと、前記診療の予約時間と、前記呼出時刻とを含む前記第二電文を受信する通信部と、
   前記第二電文が受信されたときに、前記第二電文に基づいて、病院ＩＤと、診療科ＩＤと、診療の予約時間と、診療の予約時間に対する呼出時刻から算出される遅延時間とを含む診療開始実績を更新する更新部と、
   前記診療開始実績に基づいて、診療の開始の遅延の統計を算出する算出部と、
   前記統計の表示データを生成する第一生成部と、
   前記第二電文が受信されたときに、前記第二電文に含まれる前記メールアドレス宛に前記通信部によって送信される呼出メールを生成する第二生成部と、
   を具備する院外サーバ。
2. 前記算出部は、病院毎に、前記統計を算出する、
   請求項１に記載の院外サーバ。
3. 前記算出部は、前記統計として、前記予約時間毎に、診療開始遅延時間を算出する、
   請求項１に記載の院外サーバ。
4. 院内サーバと、院外サーバとを具備する診療案内サービスシステムであって、
   前記院内サーバは、患者ＩＤと、当該患者ＩＤに対応する患者の診療の呼出時刻とを含む第一電文を電子カルテシステムから受信したときに生成する第二電文であって、前記患者ＩＤに対応するメールアドレスと、前記診療が行われる病院を示す病院ＩＤと、前記診療が行われる診療科を示す診療科ＩＤと、前記診療の予約時間と、前記呼出時刻とを含む前記第二電文を送信し、
   前記院外サーバは、
   前記第二電文を受信したときに、前記第二電文に基づいて、病院ＩＤと、診療科ＩＤと、診療の予約時間と、診療の予約時間に対する呼出時刻から算出される遅延時間とを含む診療開始実績を更新し、
   前記診療開始実績に基づいて、診療の開始の遅延の統計を算出し、
   前記統計の表示データを生成し、
   前記第二電文を受信したときに、前記第二電文に含まれる前記メールアドレス宛に送信される呼出メールを生成する、
   診療案内サービスシステム。
5. 院内サーバが、患者ＩＤと、当該患者ＩＤに対応する患者の診療の呼出時刻とを含む第一電文を電子カルテシステムから受信したときに生成する第二電文であって、前記患者ＩＤに対応するメールアドレスと、前記診療が行われる病院を示す病院ＩＤと、前記診療が行われる診療科を示す診療科ＩＤと、前記診療の予約時間と、前記呼出時刻とを含む前記第二電文を受信し、
   前記第二電文を受信したときに、前記第二電文に基づいて、病院ＩＤと、診療科ＩＤと、診療の予約時間と、診療の予約時間に対する呼出時刻から算出される遅延時間とを含む診療開始実績を更新し、
   前記診療開始実績に基づいて、診療の開始の遅延の統計を算出し、
   前記統計の表示データを生成して前記表示データをユーザ端末へ送信し、
   前記第二電文を受信したときに、前記第二電文に含まれる前記メールアドレス宛に呼出メールを送信する、
   診療案内方法。

Images