JP6796898B1 - 遠隔診療予約システム - Google Patents

Abstract

【課題】キャンセルまたは診療時間の長時間化等による遠隔診療の診療スケジュールの乱れを防止して、患者及び医師に良好な遠隔診療の診療環境を提供することを目的とする。【解決手段】本発明の遠隔診療予約システムは、患者の以前の受診時における患者の受診履歴に基づいて決まる患者が診療を受ける可能性の高さを示す受診可能性指標、及び患者の以前の診療においてかかった時間と当該以前の診療の診療内容に基づいて決まる規定診療時間とによって決まる診療時間延長指標を含む患者情報を取得する患者情報取得部と、規定診療時間、受診可能性指標及び診療時間延長指標に基づいて仮想診療所要時間を取得する仮想診療所要時間取得部と、予約情報に含まれる希望時間枠及び前記仮想診療所要時間に基づいて、複数の予約時間枠の各々に前記患者の予約を登録する予約情報登録部と、を含むことを特徴とする。【選択図】図１

Description

本発明は、予約システムに関し、特に遠隔診療システムの予約システムである遠隔診療予約システムに関する。

従来、医師と患者とが互いに離れている状態で診療を行う遠隔診療が行われている。例えば、テレビ会議システムを用いて、医師が遠隔地にいる患者を診療することが行われている。特許文献１には、遠隔診療の予約システムが開示されている（特許文献１）。

特開2018-106402号公報

例えば、遠隔診療システムにおいては、患者が空いている予約時間枠に予約を入れて、当該予約された時間において遠隔診療が行われる。

しかし、例えば、診療予約をしたのにも関わらず診療予約を放置して診療を受けない、いわゆる無断キャンセルをする患者や、遠隔診療に用いる電話等の通信がなかなか確立できない患者、また診療が長引く患者等によって診療スケジュールが乱されてしまうということが問題の一例として挙げられる。

本発明は上記した点に鑑みてなされたものであり、例えば、キャンセルまたは診療時間の長時間化等による遠隔診療の診療スケジュールの乱れを防止して、患者及び医師に良好な遠隔診療の診療環境を提供することを目的とする。

本発明は、通信路を介した遠隔診療システムに用いられる遠隔診療予約システムであって、各々が延べ診療時間を有する複数の予約時間枠を含む予約スケジュール情報を取得するスケジュール情報取得部と、患者が受けることを希望する診療の内容及び前記診療の受診を希望する予約時間枠である希望時間枠を含む予約情報を取得する予約情報取得部と、前記患者の以前の受診時における前記患者の受診履歴に基づいて決まる前記患者が診療を受ける可能性の高さを示す受診可能性指標、及び前記患者の以前の診療においてかかった時間と、当該診療の診療内容に基づいて決まる規定診療時間とによって決まる診療時間延長指標を含む患者情報を取得する患者情報取得部と、前記予約情報に含まれる患者が受けることを希望する診療の内容、並びに前記規定診療時間、前記受診可能性指標及び前記診療時間延長指標に基づいて仮想診療所要時間を取得する仮想診療所要時間取得部と、
前記予約情報に含まれる希望時間枠及び前記仮想診療所要時間に基づいて、前記複数の時間枠の各々に登録された前記予約情報の前記仮想診療所要時間の合計が前記複数の時間枠の各々の前記延べ診療時間を超えないように、前記複数の予約時間枠の各々に前記患者の予約を登録する予約情報登録部と、を含むことを特徴とする遠隔診療予約システムである。

本発明によれば、患者から１の時間枠に対して診療の予約を受け付けた際に、当該患者が診療を受ける可能性の高さ及び予想される診療時間の延長可能性に鑑みた態様で診療の予約を当該予約時間枠に登録する。具体的には、患者から予約の希望を受け付けた際に、当該患者が受けたい診療の内容診療、診療時間の延長の可能性及び当該患者が診療を受ける可能性の高さに応じた長さの時間分の予約を予約時間枠に登録する。言い換えれば、本発明においては、患者が診療を受ける可能性の高さ及び診療時間の延長可能性に応じて当該患者の予約に割り当てる時間を変更する。このようにすることで、予約時間枠の各々における無断キャンセルによる診療スケジュールの乱れを抑制しつつ、無断キャンセルを想定した予約時間枠の利用効率の最大化が可能になる。

実施例１の予約システムを示す図である。 実施例１の予約システムを構成する端末の機能ブロック図である。 受付画面の一例を示す図である。 予約希望情報を示す図である。 実施例１の予約システムを構成する予約サーバの機能ブロック図である。 患者情報テーブルの一例を示す図である。 予約情報テーブルの一例を示す図である。 端末において実行される予約送信ルーチンを示すフロー図である。 予約サーバにおいて実行される予約登録ルーチンを示すフロー図である。 予約サーバにおいて実行される仮想診療所要時間算出サブルーチンを示すフロー図である。 医師情報テーブルの一例を示す図である。

以下に、本発明の実施例１である予約システム１００について添付図面を参照しつつ説明する。予約システム１００は、例えば、遠隔診療システムに用いられる予約システムである。以下の説明において、特に説明がない場合、診療とは遠隔診療、すなわち通信を介した音声通話またはビデオ通話による診療をいう。遠隔診療のための音声通話またはビデオ通話は、例えば、公衆電話網やインターネットを介した電話またはテレビ電話等で行われる。

図１は、本発明の実施例１である予約システム１００を示している。図１に示すように、予約システム１００は、端末１０及び予約サーバ２０を含んで構成されている。なお、図１においては、端末１０がタッチパネルディスプレイＴＰを有するタブレット端末である場合を例に説明する。

端末１０と予約サーバ２０とは、ネットワーク（通信路）ＮＷを介して、例えば、ＴＣＰ／ＩＰ等の通信プロトコルを用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、移動体通信網、ＷｉＦｉ（登録商標）等の無線通信及び有線通信を含むインターネット通信により構築され得る。

予約システム１００においては、予約サーバ２０が複数の医師についての複数の予約時間枠の空き状況すなわち予約状況を端末１０に送信する。また、予約システム１００においては、端末１０から予約サーバ２０に対して、当該予約時間枠に対する予約の希望を示す予約希望情報が送信される。予約サーバ２０は、当該予約情報に基づいて予約時間枠に予約を入れる。

図２は、端末１０の構成を示すブロック図である。例えば、端末１０は、システムバス１１を介して、大容量記憶装置１２と、制御部１３と、出力部１４と、入力部１５と、データ通信部１６と、が協働する装置である。

大容量記憶装置１２は、例えば、ハードディスク装置、ＳＳＤ（solid state drive）、フラッシュメモリ等により構成されており、オペレーティングシステムや、端末用のソフトウェア等の各種プログラムを記憶する。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、記録媒体に記録されて各種ドライブ装置を介して読み込まれるようにしてもよい。すなわち、大容量記憶装置２３に記憶される各種プログラム（後述する端末１０における処理を実行するためのプログラムを含む）は、ネットワークＮＷを介して伝送可能であるし、また、コンピュータ読み取り可能な記録媒体に記録して譲渡することが可能である。

制御部１３は、ＣＰＵ（Central Processing Unit）１３Ａ、ＲＯＭ（Read Only Memory）１３Ｂ、ＲＡＭ（Random Access Memory）１３Ｃ等により構成され、コンピュータとして機能する。そして、ＣＰＵ１３Ａが、ＲＯＭ１３Ｂや大容量記憶装置１２に記憶された各種プログラムを読み出し実行することにより各種機能を実現する。

出力部１４は、端末１０に備えられているタッチパネルディスプレイＴＰに表示画像を提供するインターフェースである。制御部１３は、タッチパネルディスプレイＴＰに表示すべき表示画像を出力部１４を介してタッチパネルディスプレイＴＰに出力することで、タッチパネルディスプレイＴＰに当該表示画像を表示させる。

入力部１５は、端末１０に備えられているタッチパネルディスプレイＴＰにおける操作入力を受け付けるインターフェースである。制御部１３は、入力部１５を介して取得される操作入力の情報に基づいて、種々の機能を実行し得る。例えば、制御部１３は、出力部１４を介してタッチパネルディスプレイＴＰに入力を受け付けるための画像を表示させ、当該画像に対するタッチパネルディスプレイＴＰへの入力が入力部１５を介して制御部１３に伝達される。

例えば、制御部１３は、タッチパネルディスプレイＴＰに、希望の診療内容や希望の診療時間等の診療予約に関する入力を受け付けるための予約受付画像を表示し、それに対するユーザからの入力を受け付けて診療予約に関するユーザの希望の情報を取得する。

データ通信部１６は、上記したネットワークＮＷに接続されており、種々のデータを予約サーバ２０等の他の機器との間で送受信する。例えば、制御部１３は、データ通信部１６を介して予約サーバ２０と通信して、上記入力された診療予約に関するユーザの希望の情報を送信可能である。また、制御部１３は、データ通信部１６を介して診療予約の空き状況の情報を取得可能である。

図３に、タッチパネルディスプレイＴＰに表示される予約受付画像の一例である受付画像ＩＭ１を示す。受付画像ＩＭ１において、左上に患者の登録ＩＤ及び患者名が表示されている。

受付画像ＩＭ１では、中央部の領域ＡＲ１が、どのような診療を受けたいのかの希望を受け付ける部分となっている。受付画像ＩＭ１では、領域ＡＲ１において、一例として、「いつもの薬が欲しい」、「いつもの処置をして欲しい」、「ちょっと気になるので診て欲しい」、「ちゃんと診て欲しい」という４つの選択肢が表示され、当該選択肢から患者の希望が選択可能になっている。

また、受付画像ＩＭ１では、領域ＡＲ１の下方の領域ＡＲ２が、希望の診療予約時間の選択を受け付ける部分となっている。受付画像ＩＭ１では、領域ＡＲ２において、例えば、医師名と医師毎かつ時間帯毎の予約枠が表されたスケジュール表が表示され、当該予約枠の中から希望の予約枠が選択可能になっている。図３の例では、患者が「いつもの薬が欲しい」という診療についての希望を選択し、明石医師の１１時から１２時の間の時間帯の予約枠を希望予約枠として選択している。

なお、領域ＡＲ２に表示されるスケジュール表は、予約サーバ２０からの情報に基づいて生成される。例えば、図３に示すように、予約サーバ２０からの情報に基づいて、予約可能性がある枠に「○」、予約が不可能な枠に「×」が示されてもよい。

受付画像ＩＭ１の右下部分には、送信ボタンＳＢが配されている。例えば、ユーザが、領域ＡＲ１及びＲ２において自らの診療に関する希望を選択する入力を行い、その後送信ボタンＳＢを押すことで、予約に関して選択された希望を示す予約希望情報、すなわち診療内容の希望と予約枠の希望を含む情報が予約サーバ２０に送信される。

図４に、端末１０から予約サーバ２０に送信される予約希望情報を含むデータである希望予約データＤ１の一例を示す。図４に示すように、予約希望情報には、予約を希望する患者の「患者ID」、「氏名」、「希望時間枠」、希望の「診療の内容」が含まれている。

図５は、予約サーバ２０の構成を示すブロック図である。例えば、予約サーバ２０はシステムバス２１を介して、大容量記憶装置２３と、制御部２５と、データ通信部２７とが協働している装置である。

大容量記憶装置２３は、例えば、ハードディスク装置、ＳＳＤ（solid state drive）、フラッシュメモリ等により構成されており、オペレーティングシステムや、端末用のソフトウェア等の各種プログラムを記憶する。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークを介して取得されるようにしてもよいし、記録媒体に記録されて各種ドライブ装置を介して読み込まれるようにしてもよい。すなわち、大容量記憶装置２３に記憶される各種プログラム（後述する予約サーバ２０における処理を実行するためのプログラムを含む）は、ネットワークを介して伝送可能であるし、また、コンピュータ読み取り可能な記録媒体に記録して譲渡することが可能である。

大容量記憶装置２３内には、患者に関する情報を含む患者情報データベース２３Ａが構築されている。また、大容量記憶装置２３内には、予約の状況を示す予約状況データベース２３Ｂが構築されている。各データベースの内容は、適宜更新され得る。

制御部２５は、ＣＰＵ（Central Processing Unit）２５Ａ、ＲＯＭ（Read Only Memory）２５Ｂ、ＲＡＭ（Random Access Memory）２５Ｃ等により構成され、コンピュータとして機能する。そして、ＣＰＵ２５Ａが、ＲＯＭ２５Ｂや大容量記憶装置２３に記憶された各種プログラムを読み出し実行することにより各種機能を実現する。

データ通信部２７は、上記したネットワークＮＷに接続されており、種々のデータを端末１０等の他の機器との間で送受信する。例えば、制御部２５は、データ通信部２７を介して端末１０と通信して、診療の予約枠及びその空き状況の情報を送信可能である。また、制御部２５は、上記端末１０から送信される予約希望情報を受信可能である。また、制御部２５は、受信した予約希望情報に示される希望通りの予約が取れるか否かの情報を端末１０に送信可能である。

図６は、患者情報データベース２３Ａに含まれる患者情報の一例である患者情報テーブルＴＢ１を示す図である。図６に示すように、患者情報テーブルＴＢ１には、患者のＩＤ、各患者の時間延長指標、受診可能性指標、性別及び年齢が含まれている。

診療時間延長指標としての「時間延長指標」とは、予約の際に各患者に割り当てる時間を多く見積もるための指標である。例えば、「時間延長指標」とは、各患者が当該所定の内容の診療を受けた際に予想される診療時間を示す指標である。例えば、「時間延長指標」は、所定の内容の診療の標準的な診療時間を１として決められる指標である。具体的には、予想される診療時間が標準的な診療時間より長い場合には「時間延長指標」が１よりも大きくなり、予想される診療時間が標準的な診療時間よりも短い場合には、「時間延長指標」が１よりも小さくなる。本実施例では、例えば、各指標値＝予想される診療時間／標準的な診療時間であるとして説明する。

「時間延長指標」は、例えば、過去の各診療において要した時間と標準的な診療時間とを比較することで算出されてもよい。具体的には、例えば、時間延長指標は、各患者の以前の診療においてかかった時間と、当該以前の診療の診療内容に基づいて決まる規定診療時間とを比較することで算出されてもよい。また、「時間延長指標」は、再診である場合よりも初診である場合の方が大きくなるようになされていてもよい。

「受診可能性指標」とは、予約の際に各患者に割り当てる時間を少なく見積もるための指標である。「受診可能性指標」は、患者が予約した診療を受ける可能性の高さ、すなわち受診確率を示す指標である。例えば、「受診可能性指標」は、予約した診療を患者が必ず受ける、すなわち患者が１００％診療を受けると予想される場合を１として定められる指標である。具体的には、予約した診療を患者が受ける可能性が低くなればなるほど、指標は０に近づいていく。

本実施例では、「受診可能性指標」は、患者が診療を受ける可能性がない、すなわち受診確率が０％である場合を０とし、受診確率に比例して増える指標であるとして説明する。「受診可能性指標」は、例えば、過去の遠隔診療の受診履歴を含む受診履歴情報に基づいて決められ得る。「受診可能性指標」は、例えば、「受診可能性指標」＝受診回数／予約回数で定義され得る。言い換えれば、「受診可能性指標」は患者の以前の予約の回数に対して患者が予約通りに診療を受けた回数の割合である。受診回数とは、例えば診療が電話またはテレビ電話で行われる場合、医師からの呼に所定時間内に応答して診療を受けた回数である。

なお、「受診可能性指標」は、遠隔診療特有の要素に基づいて補正されてもよい。例えば、呼の試行回数の多少、受診時の通信状況が良いかどうかまたは受診しているときの患者の周囲の環境が診療に適しているか否か等の要素に基づいて、「受診可能性指標」の補正がなされてもよい。言い換えれば、受診可能性指標は、遠隔診療特有の要素に基づいて決まり得る。

表１は、「受診可能性指標」に対する補正値の例を示すものである。表１に示すように、呼の試行回数の多少によって「受診可能性指標」を変化させるために、呼の試行回数が２回以上である割合に基づいた補正を行ってもよい。例えば、呼の試行回数が２回以上である割合が多い方が「受診可能性指標」が小さくなるように補正値が決められていてもよい。

また、受診時の通信状況が良いかどうかによって「受診可能性指標」を変化させるために、診療中の電話等の通信が途中で切れた割合に基づいた補正を行ってもよい。例えば、電話が途中で切れた割合が高ければ高いほど「受診可能性指標」が小さくなるように補正値が決められていてもよい。

また、受診環境が良いかどうかによって「受診可能性指標」を変化させるために、例えば、患者の電話口が騒がしい場合を受診環境が悪いとして、受診環境が悪い割合に基づいた補正を行ってもよい。例えば、受診環境が悪い割合が高ければ高いほど「受診可能性指標」が小さくなるように補正値が決められていてもよい。なお、「受診可能性指標」が受診回数／予約回数で決まらず、遠隔診療特有の要素のみに基づいて決まってもよい。例えば、呼の試行回数、通信状況及び周囲の環境のみに基づいて、「受診可能性指標」が決まってもよい。

図７は、予約状況データベース２３Ｂに含まれる予約スケジュール情報の一例である予約情報テーブルＴＢ２を示す図である。図７に示すように、予約情報テーブルＴＢ２には、医師毎の１時間毎の予約枠が示されている。予約情報テーブルＴＢ２においては、当該予約枠の各々の「氏名」の欄に当該予約枠に登録されている患者の氏名が示されている。

また、予約情報テーブルＴＢ２においては、「規定」の欄に当該患者が希望する診療の内容に基づいて決まる規定診療時間が示されている。この規定診療時間は、所定の診療内容の診療を行った際にかかる診療時間として予め規定されているものである。例えば、以下の表２に示す様な規定診療時間テーブルが予約サーバ２０に保存されており、この規定診療時間テーブルを参照して患者が希望する診療の内容に対する規定診療時間が決定されてもよい。

また、予約情報テーブルＴＢ２においては、「予定」の欄に当該患者に対する診療にかかる予定時間である予定診療時間が示されている。この予定診療時間は、患者が希望する診療の内容及び上記時間延長指標に基づいている。例えば、上記患者の診療に対する希望に基づいて決まる診療内容の診療にかかる標準的な時間に上記時間延長指標を乗じた時間が予定診療時間となり得る。

また、予約情報テーブルＴＢ２においては、「仮想」の欄に診療の内容、時間延長指標及び前記受診可能性指標に基づいて決まる仮想診療所要時間が示されている。具体的は、例えば、予定診療時間に受診可能性指標を乗じた時間が仮想診療所要時間となる。言い換えれば、仮想診療所要時間は、各患者の受診可能性指標によって変化し、受診可能性指標が低いほど、すなわち受診する可能性が低いと予想されるほどには時間が短くなる。予約サーバ２０において、診療の予約は、予約情報テーブルＴＢ２の各予約枠において、仮想診療所要時間が各予約枠の延時間、すなわち本実施例では６０分を超えないように登録される。

このように、予約サーバ２０においては、患者の過去の遠隔診療特有の履歴に応じて当該患者の予約に割り当てる時間を変更する。具体的には、例えば、遠隔診療特有の要因に基づいて決まる患者が診療を受ける可能性の高さに鑑みた態様で診療の予約を当該予約時間枠に登録する。具体的には、患者から予約の希望を受け付けた際に、当該患者が受けたい診療の内容及び当該患者が診療を受ける可能性の高さに応じた長さの時間分の予約を予約時間枠に登録する。言い換えれば、遠隔診療特有の要因に基づいて決まる患者が診療を受ける可能性の高さに応じて当該患者の予約に割り当てる時間を変更する。このようにすることで、予約時間枠の各々における遠隔診療特有の理由によるキャンセルによる診療スケジュールの乱れを抑制しつつ、キャンセルを想定した予約時間枠の利用効率の最大化が可能となる。

［処理ルーチン］
以下に、実施例１の予約システム１００の端末１０において、遠隔診療の予約を受け付ける際に実行される処理ルーチンについて説明する。

図８は、遠隔診療の予約を受け付ける際の処理ルーチンの一例である予約受付ルーチンＲ１を示す図である。予約受付ルーチンＲ１は、例えば、端末１０の電源がオンになると開始され、電源がオフになるまで繰り返し実行される。また、例えば、端末１０が汎用のスマートフォンやタブレットである場合には、予約システム１００のためのアプリが起動されたことをして、予約受付ルーチンＲ１が開始されてもよい。

まず、制御部１３は、予約サーバ２０に問い合わせを行い、予約状況を示す情報として、例えば、上述した予約情報テーブルＴＢ２を取得する（ステップＳ１１）。

ステップＳ１１において、予約情報テーブルＴＢ２が取得されると、制御部１３は、当該予約情報テーブルＴＢ２に基づいた予約状態を表示した受付画面をタッチパネルディスプレイＴＰに表示させ、当該受付画面に対する入力を待機する（ステップＳ１２）。この受付画面は、例えば図３に示したような受付画像ＩＭ１を表示した画面であってもよい。この場合、領域ＡＲ２に表示されるスケジュール表が、予約情報テーブルＴＢ２に基づいて予約状態を表示したものである。また、制御部１３が待機する入力は、例えば、領域ＡＲ１に対して患者が希望する診療内容を指定する入力及び領域ＡＲ２に対して患者が希望する予約時間帯を指定する入力である。

ステップＳ１２が行われて、受付画面が表示及び入力の待機が開始されると、制御部１３は、当該受付画面に対する入力が終了したか否かを判定する（ステップＳ１３）。この判定は、領域ＡＲ１において診療内容を指定する選択入力がなされ、領域ＡＲ２において時間帯を指定する選択入力がなされかつ受付画像ＩＭ１内の送信ボタンＳＢが押されたか否かでなされ得る。

ステップＳ１３において、入力が終了したと判定される（ステップＳ１３：ＹＥＳ）と、当該入力に基づいて患者が希望する診療内容及び予約時間帯を含む予約に関する患者の希望を示す希望予約情報が予約サーバ２０に送信される（ステップＳ１４）。ステップＳ１４においては、希望予約情報として、例えば、図４に示したような、予約を希望する患者の「患者ID」、「氏名」、「希望時間枠」、希望の「診療の内容」が含まれている希望予約データＤ１が送信され得る。ステップＳ１３において、入力が終了していないと判定されると（ステップＳ１３：ＮＯ）、制御部１３は、ステップＳ１２の処理を継続し、受付画面の表示及び入力の受付を継続する。

ステップＳ１４の処理によって希望予約情報が予約サーバ２０に送信された後、当該希望予約情報によって示される予約内容で予約が可能であるか否かが判定される（ステップＳ１５）。この判定は、例えば、希望予約情報に対する予約サーバからの予約可否の応答に基づいて行われ得る。

ステップＳ１５において、予約が可能であると判定される（ステップＳ１５：ＹＥＳ）と、制御部１３は、ステップＳ１４において送信された予約に関する希望に基づいた予約が確定したことを表す予約確定画面をタッチパネルディスプレイＴＰに表示する（ステップＳ１６）。この予約確定画面には、診療の内容及び診療の予約の時間帯が表示されていてもよい。ステップＳ１６の終了後、予約受付ルーチンＲ１は終了する。

ステップＳ１５において、予約が不可能であると判定される(ステップＳ１５：ＮＯ)と、制御部１３は、再度ステップＳ１１を実行して、現在の最新の予約状態の情報を取得すべく、予約サーバ２０から新たに予約情報テーブルＴＢ２を取得する（ステップＳ１１）。

以下に、実施例２の予約システム１００の予約サーバ２０において、遠隔診療の予約を登録する際に実行される処理ルーチンについて説明する。

図９は、サーバ２０が遠隔診療の予約を登録する際の処理ルーチンの一例である予約登録ルーチンＲ２を示す図である。予約登録ルーチンＲ２は、例えば、予約サーバ２０の電源がオンになると開始され、電源がオフになるまで繰り返し実行される。

まず、制御部２５は、端末１０から、予約情報として上述した希望予約情報の受信を待機し、当該希望予約情報を受信したか否かを判定する（ステップＳ２１）。ステップＳ２１においては、例えば、上述した希望予約データＤ１の受診が待機され、これを受診したか否かが判定される。ステップＳ２１において、希望予約データＤ１が受信されていないと判定される（ステップＳ２１：ＮＯ）と、その後ルーチンＲ２は終了する。ステップＳ２１において、制御部２５は、予約情報取得部として機能する。

ステップＳ２１において、希望予約データＤ１が受信されたと判定される（ステップＳ２１：ＹＥＳ）と、制御部２５は、上記した仮想診療所要時間を算出する仮想診療所要時間算出サブルーチンを実行する。

図１０に仮想診療所要時間算出サブルーチンＳＲを示す。仮想診療所要時間算出サブルーチンＳＲが開始されると、制御部２５は、希望予約情報に含まれる希望する診療の内容に基づいて規定診療時間を取得する（ステップＳ２２−１）。このステップＳ２２−１において、規定診療時間の取得は、例えば、上記表２の規定診療時間テーブルを参照して希望する診療の内容に対応した時間を取得することでなされてもよい。

ステップＳ２２−１で規定診療時間が取得されると、制御部２５は、予定診療時間を算出する（ステップＳ２２−２）。この予定診療時間の算出においては、例えば、患者情報データベース２３Ａ内の患者情報テーブルＴＢ１が参照される。例えば、予定診療時間は、患者情報テーブルＴＢ１から予約する患者の時間延長指標を取得し、ステップＳ２２−１において取得された規定診療時間に、当該取得した時間延長指標を乗じて算出され得る。

ステップＳ２２−２において、予定診療時間が算出されると、制御部２５は、仮想診療所要時間を算出する（ステップＳ２２−３）。この仮想診療所要時間の算出においても、例えば、ステップＳ２２と同様に、患者情報データベース２３Ａ内の患者情報テーブルＴＢ１が参照される。例えば、仮想診療所要時間は、上述のように、予定診療時間に受診可能性指標を乗じて算出される。ステップＳ２２において、制御部２５は、患者情報取得部及び仮想診療所要時間取得部として機能する。

ステップＳ２２が行われて、予定診療時間及び仮想診療所要時間が算出されると、制御部２５は、予約スケジュールを示す予約スケジュール情報としての予約情報テーブルＴＢ２を取得する（ステップＳ２３）。ステップＳ２３において、制御部２５は、スケジュール情報取得部として機能する。

ステップＳ２３で予約情報テーブルＴＢ２が取得された後、制御部２５は、上記希望予約データＤ１によって示された予約が入れられるか否かを判定する（ステップＳ２４）。この判定は、当該希望予約データＤ１によって示される予約を入れた際に、予約時間枠に入っている予約の仮想予定診療時間の合計が、当該時間枠の延べ時間を超えるか否かでなされてもよい。

ステップＳ２４において、予約が入れられない、例えば、予約を入れてしまうと仮想診療所要時間の合計が予約時間枠の延べ時間を超えてしまうと判定される（ステップＳ２４：ＮＯ）と、処理はステップＳ２５に進み、制御部２５が予約不可通知を端末１０に送信して予約登録ルーチンＲ２が終了する。

ステップＳ２４において、予約が入れられる、例えば、予約を入れても仮想診療所要時間が予約時間枠の延べ時間を超えないと判定される（ステップＳ２４：ＹＥＳ）と、処理はステップＳ２６に進み、制御部２５が予約を登録する、すなわち予約情報テーブルＴＢ２に希望予約データＤ１によって示される予約を登録する。

ステップＳ２６において、予約が登録されると、処理はステップＳ２７に進み、制御部２５が予約完了通知を端末１０に送信し、予約登録ルーチンＲ２が終了する。

すなわち、ステップＳ２４〜Ｓ２７においては、制御部２５は、予約情報テーブルＴＢ２及び仮想診療所要時間に基づいて、予約情報テーブルＴＢ２内の複数の時間枠の各々に登録された予約の仮想診療所要時間の合計が当該複数の時間枠の各々の延べ診療時間を超えないように、前記複数の予約時間枠の各々に前記患者の予約を登録する予約情報登録部として機能する。

［変形例］
以下に、本願実施例１の予約システム１００の変形例について添付図面を参照しつつ説明する。変形例の予約システムにおいては、予約サーバ２０に、さらに医師の信頼度を含む、医師に関する情報のデータベースである医師情報データベースが含まれている。変形例において、予約サーバ２０は、医師の信頼度に応じて、予約の登録の仕方を異ならしめる。例えば、この医師の信頼度は、診療を受けた患者からのアンケートによって定められてもよい。
図１１に、医師情報データベースに含まれるデータの一例である医師情報テーブルＴＢ３を示す。医師情報テーブルには、医師のＩＤ、医師の氏名、診療科、医師の信頼度等が含まれている。変形例の予約システムにおいては、例えば、予約サーバ２０は、信頼度の高い医師の予約時間枠に優先的に受診可能性指標が高い患者を割り当てる。図１１では、図７に出てくる医師のうち、明石医師の方が藤村医師よりも信頼度が高いことが示されている。

例えば、図７に示す予約情報テーブルＴＢ２を例に説明する。上述のように、明石医師が藤村医師よりも信頼度が高い場合、明石医師の予約枠には受診可能性指標が高い患者が優先的に登録され、藤村医師の予約枠には明石医師の予約枠に比べて比較的受診可能性指標が低い患者が登録されることになる。

その結果、図７に示すように、信頼度の高い明石医師の予約枠には仮想診療所要時間と予定診療時間との乖離が少ない、すなわち受診可能性指標が高くキャンセルの可能性が低い患者が登録され、明石医師はキャンセルをあまり気にすることなく診療を行うことができる。

それに対して、信頼度の低い藤村医師の予約枠には、想診療所要時間と予定診療時間との乖離が大きい、すなわちキャンセル可能性が高い患者が登録され、藤村医師は患者のキャンセルの様子を見ながら診療を行なわなければならない可能性が高くなっている。

このように、診療の予約の登録に医師の信頼度を加味することで、信頼度の高い医師が会的に診療を行う環境を提供することができる。これにより、ひいては、医師達に信頼度の高い医師になるべく努力するように仕向けることが可能となる。

上述した実施例における種々の構成等は、例示に過ぎず、用途等に応じて、適宜選択することができる。

１００ 予約システム
１０ 端末
２０ 予約サーバ

Claims (6)

1. 通信路を介した遠隔診療システムに用いられる遠隔診療予約システムであって、
   各々が延べ診療時間を有する複数の予約時間枠を含む予約スケジュール情報を取得するスケジュール情報取得部と、
   患者が受けることを希望する診療の内容及び前記診療の受診を希望する予約時間枠である希望時間枠を含む予約情報を取得する予約情報取得部と、
   前記患者の以前の受診時における前記患者の受診履歴に基づいて決まる前記患者が診療を受ける可能性の高さを示す受診可能性指標、及び前記患者の以前の診療においてかかった時間と、当該以前の診療の診療内容に基づいて決まる規定診療時間とによって決まる診療時間延長指標を含む患者情報を取得する患者情報取得部と、
   前記予約情報に含まれる患者が受けることを希望する診療の内容、並びに前記規定診療時間、前記受診可能性指標及び前記診療時間延長指標に基づいて仮想診療所要時間を取得する仮想診療所要時間取得部と、
   前記予約情報に含まれる希望時間枠及び前記仮想診療所要時間に基づいて、前記複数の予約時間枠の各々に登録された前記予約情報の前記仮想診療所要時間の合計が前記複数の予約時間枠の各々の前記延べ診療時間を超えないように、前記複数の予約時間枠の各々に前記患者の予約を登録する予約情報登録部と、
   を含むことを特徴とする遠隔診療予約システム。
2. 前記受診可能性指標は、前記患者の以前の予約の回数に対して前記患者が予約通りに診療を受けた回数の割合に基づいていることを特徴とする請求項１に記載の予約システム。
3. 前記予約時間枠は、複数の医師の各々に対して時間的に並列に割り当てられており、前記予約情報登録部は、前記複数の医師の対して付された信頼度を取得し、前記信頼度が高い医者に対して割り当てられている予約枠に前記受診可能性指標が高い患者の予約を優先的に登録することを特徴とする請求項１または２に記載の予約システム。
4. 前記受診可能性指標は、前記以前の受診時の呼（接続試行について柔らかい言い方で）の試行回数が多いほど低くなることを特徴とする請求項１乃至３のいずれか１つに記載の遠隔診療予約システム。
5. 前記受診可能性指標は、前記以前の受診時の通信状況が悪いほど低くなることを特徴とする請求項１乃至４のいずれか１つに記載の遠隔診療予約システム。
6. 前記受診可能性指標は、前記以前の受診時の患者の周囲の環境が悪いほど低くなることを特徴とする請求項１乃至５のいずれか１つに記載の遠隔診療予約システム。