特許 7335412 プログラム、システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2023-08-21

(45)【発行日】2023-08-29

(54)【発明の名称】プログラム、システム及び方法

(51)【国際特許分類】

   G16H 40/20 20180101AFI20230822BHJP

【ＦＩ】

G16H40/20

【請求項の数】 10

(21)【出願番号】P 2022151889

(22)【出願日】2022-09-22

【審査請求日】2022-09-30

【新規性喪失の例外の表示】特許法第３０条第２項適用 令和４年１月２０日に株式会社メドレーのニュースリリースｈｔｔｐｓ：／／ｗｗｗ．ｍｅｄｌｅｙ．ｊｐ／ｒｅｌｅａｓｅ／２０２２０１２０．ｈｔｍｌにて公開 〔刊行物等〕 令和４年１月２０日にクラウド歯科業務支援システム「Ｄｅｎｔｉｓ」のウェブサイトｈｔｔｐｓ：／／ｄｅｎｔｉｓ－ｃｌｏｕｄ．ｃｏｍ／にて公開

【早期審査対象出願】

【前置審査】

(73)【特許権者】

【識別番号】515345919

【氏名又は名称】株式会社メドレー

(74)【代理人】

【識別番号】110002789

【氏名又は名称】弁理士法人ＩＰＸ

(72)【発明者】

【氏名】前田 邦織

(72)【発明者】

【氏名】大岡 靖典

(72)【発明者】

【氏名】宮内 勇樹

【審査官】梅岡 信幸

(56)【参考文献】

【文献】特開２０１９－１１３８９８（ＪＰ，Ａ）

【文献】特開２０１６－２１８６４３（ＪＰ，Ａ）

【文献】特開２０２２－０８４９７８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００－８０／００

(57)【特許請求の範囲】

【請求項1】

医療機関における複数のユーザのステータス状態を示すデータベースを記憶し、前記ユーザのステータス状態を予定表に表示するシステムを制御するコンピュータに、
前記ユーザの第１端末から予約データを受け付けた場合に、前記ステータス状態を、受け付けた前記予約データに対応する第１状態として前記データベースに反映し、当該データベースに反映された前記第１状態を前記予定表の表示において前記ユーザのステータス状態として表示する処理と、
医療機関の第２端末から前記ユーザの来訪を示す来訪データを受け付けた場合に、前記ステータス状態を、受け付けた前記来訪データに対応する第２状態として前記データベースに反映し、前記予定表の表示における前記ユーザのステータス状態を、当該データベースに反映された前記第２状態に変更する処理と、
医療機関の第３端末から前記ユーザの症状または処置内容を示す診療結果データを受け付けた場合に、前記ステータス状態を、受け付けた前記診療結果データに対応する第３状態として前記データベースに反映し、前記予定表の表示における前記ユーザのステータス状態を、当該データベースに反映された前記第３状態に変更する処理と、
前記医療機関の第２端末から、前記ユーザの会計情報を示す会計情報データを受け付けた場合に、前記ステータス状態を、受け付けた前記会計情報データに対応する第４状態として前記データベースに反映し、前記予定表の表示における前記ユーザのステータス状態を、当該データベースに反映された前記第４状態に変更する処理と、
を実行させるプログラム。

【請求項2】

請求項１に記載のプログラムにおいて、
前記コンピュータに、
前記医療機関の第３端末から、次回診療の時間長さ又は次回診療までの間隔の少なくとも一方を受け付け、ユーザ情報と関連付けて保存する処理を実行させる、プログラム。

【請求項3】

請求項１に記載のプログラムにおいて、
前記コンピュータに、
前記ユーザの第１端末からの予約に加え、前記医療機関の第２端末からの予約を受け付け、前記第１端末からの予約は、医療スタッフの予定に基づく予約可能枠から受け付け、前記第２端末からの予約は、前記予約可能枠にかかわらず受け付ける処理を実行させる、
プログラム。

【請求項4】

請求項１に記載のプログラムにおいて、
前記予約データによる予約は、予約の日時が指定されることで行われ、
前記コンピュータに、
医療スタッフ及び設備のいずれか一方の予約の日時が指定された場合に、前記医療スタッフ及び前記設備の両方の予定を確保する処理を実行させる、プログラム。

【請求項5】

請求項１に記載のプログラムにおいて、
前記予約データによる予約は、対面診療の予約とオンライン診療の予約とを含み、
前記コンピュータに、
前記対面診療の予約が受け付けられた場合は、前記データベースが示す当該ユーザのステータス情報に基づき、当該予約を前記第１状態として表示する処理を実行させ、
前記オンライン診療の予約が受け付けられた場合は、前記データベースが示す当該ユーザのステータス情報に基づき、当該予約を第２状態として表示する処理を実行させる、プログラム。

【請求項6】

請求項１に記載のプログラムにおいて、
前記コンピュータに、
前記ユーザの第１端末からの対面予約を受け付け、前記データベースに、前記第１状態として登録する処理と、
前記医療機関の第２端末からの対面予約を受け付け、前記データベースに、前記第１状態又は第５状態として登録する処理と、
を実行させる、プログラム。

【請求項7】

請求項１に記載のプログラムにおいて、
前記コンピュータに、
前記ユーザの第１端末からの予約の場合、問診情報を当該第１端末から受け付ける処理と、
前記医療機関の第２端末からの予約の場合、問診情報を当該第２端末又は前記第１端末から受け付ける処理と、
を実行させる、プログラム。

【請求項8】

請求項１に記載のプログラムにおいて、
前記コンピュータに、
前記第１端末から診療メニューの選択を含む予約を受け付け、前記診療メニューは、予約対象の医療スタッフ又は設備の少なくとも一方と関連付けられており、選択された前記診療メニューに関連付けられた医療スタッフ又は設備の予約可能枠内から前記予約を受け付ける処理を実行させる、プログラム。

【請求項9】

請求項８に記載のプログラムにおいて、
前記コンピュータに、
前記診療メニューに医療スタッフが関連付けられていてもユーザ個人に関連付けられた医療スタッフがいる場合は、当該ユーザ個人に関連付けられた医療スタッフの予約可能枠内から前記予約を受け付ける処理を実行させる、プログラム。

【請求項10】

医療機関における複数のユーザのステータス状態を示すデータベースを記憶し、前記ユーザのステータス状態を予定表に表示するシステムを制御するコンピュータが、
前記ユーザの第１端末から予約データを受け付けた場合に、前記ステータス状態を、受け付けた前記予約データに対応する第１状態として前記データベースに反映し、当該データベースに反映された前記第１状態を前記予定表の表示において前記ユーザのステータス状態として表示する処理を実行し、
前記コンピュータが、医療機関の第２端末から前記ユーザの来訪を示す来訪データを受け付けた場合に、前記ステータス状態を、受け付けた前記来訪データに対応する第２状態として前記データベースに反映し、前記予定表の表示における前記ユーザのステータス状態を、当該データベースに反映された前記第２状態に変更する処理を実行し、
前記コンピュータが、医療機関の第３端末から前記ユーザの症状または処置内容を示す診療結果データを受け付けた場合に、前記ステータス状態を、受け付けた前記診療結果データに対応する第３状態として前記データベースに反映し、前記予定表の表示における前記ユーザのステータス状態を、当該データベースに反映された前記第３状態に変更する処理を実行し、
前記コンピュータが、前記医療機関の第２端末から、前記ユーザの会計情報を示す会計情報データを受け付けた場合に、前記ステータス状態を、受け付けた前記会計情報データに対応する第４状態として前記データベースに反映し、前記予定表の表示における前記ユーザのステータス状態を、当該データベースに反映された前記第４状態に変更する処理を実行する、
方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、プログラム、システム及び方法に関する。

【背景技術】

【0002】

特許文献１には、動物患者の状態を表す複数のラベルを動物患者に関連付け、動物患者に対応付けてラベルを記憶し、動物患者に付与されたラベルを表示する技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２２－１７５９０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

医療機関では、複数の医療スタッフおよび複数の設備（歯科のユニットや医療機器等）が存在していたり、患者が利用するアプリから予約されたりすることから、スケジュール管理が煩雑である。

【課題を解決するための手段】

【0005】

本発明の一態様によれば、プログラムが提供される。このプログラムは、医療機関における予定表を表示するシステムを制御するコンピュータに、ユーザの第１端末から予約を受け付け、第１状態として表示する処理と、医療機関の第２端末からユーザの来訪を受け付け、第２状態として表示する処理と、医療機関の第３端末からユーザの症状または処置内容を受け付け、第３状態として表示する処理と、医療機関の第２端末から、ユーザの会計情報を受け付け、第４状態として表示する処理とを実行させる。

【0006】

このような態様によれば、ユーザの状態を容易に把握することができる。

【図面の簡単な説明】

【0007】

【図1】医療用予定管理システム１の全体構成を示す図である。

【図2】サーバ装置１０のハードウェア構成を示す図である。

【図3】患者端末２０のハードウェア構成を示す図である。

【図4】各装置の制御部の機能構成を示す図である。

【図5】予定管理処理の一例を示すアクティビティ図である。

【図6】診療情報データベースの一例を示す図である。

【図7】患者向けの予約用の第１画面の一例を示す図である。

【図8】患者向けの予約用の第２画面の一例を示す図である。

【図9】患者情報データベースの一例を示す図である。

【図10】受付向けの予約用画面の一例を示す図である。

【図11】来訪の受付用の画面の一例を示す図である。

【図12】申し送りの入力用画面の一例を示す図である。

【図13】受付向けの予約用画面の一例を示す図である。

【図14】受付向けの予約用画面の一例を示す図である。

【図15】サーバ装置１０が実行する処理の一例を示すフロー図である。

【図16】患者情報データベースの別の一例を示す図である。

【図17】受付向けの予約用画面の一例を示す図である。

【発明を実施するための形態】

【0008】

以下、図面を用いて本発明の実施形態について説明する。以下に示す実施形態中で示した各種特徴事項は、互いに組み合わせ可能である。

【0009】

ところで、本実施形態に登場するソフトウェアを実現するためのプログラムは、コンピュータが読み取り可能な非一時的な記録媒体（Ｎｏｎ－Ｔｒａｎｓｉｔｏｒｙ Ｃｏｍｐｕｔｅｒ－Ｒｅａｄａｂｌｅ Ｍｅｄｉｕｍ）として提供されてもよいし、外部のサーバからダウンロード可能に提供されてもよいし、外部のコンピュータで当該プログラムを起動させてクライアント端末でその機能を実現（いわゆるクラウドコンピューティング）するように提供されてもよい。

【0010】

また、本実施形態において「部」とは、例えば、広義の回路によって実施されるハードウェア資源と、これらのハードウェア資源によって具体的に実現されうるソフトウェアの情報処理とを合わせたものも含みうる。また、本実施形態においては様々な情報を取り扱うが、これら情報は、例えば電圧・電流を表す信号値の物理的な値、０又は１で構成される２進数のビット集合体としての信号値の高低、又は量子的な重ね合わせ（いわゆる量子ビット）によって表され、広義の回路上で通信・演算が実行されうる。

【0011】

また、広義の回路とは、回路（Ｃｉｒｃｕｉｔ）、回路類（Ｃｉｒｃｕｉｔｒｙ）、プロセッサ（Ｐｒｏｃｅｓｓｏｒ）、及びメモリ（Ｍｅｍｏｒｙ）等を少なくとも適当に組み合わせることによって実現される回路である。すなわち、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）、プログラマブル論理デバイス（例えば、単純プログラマブル論理デバイス（Ｓｉｍｐｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ：ＳＰＬＤ）、複合プログラマブル論理デバイス（Ｃｏｍｐｌｅｘ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ：ＣＰＬＤ）、及びフィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ：ＦＰＧＡ））等を含むものである。

【0012】

１．ハードウェア構成
本節では、本実施形態に係る医療用予定管理システムのハードウェア構成について説明する。

【0013】

図１は、医療用予定管理システム１の全体構成を示す図である。図１においては、医療用予定管理システム１が備える各装置、各装置を利用するユーザ及び各装置において処理される情報等の概要が示されている。各概要については、他の図も参照しながら随時説明する。

【0014】

医療用予定管理システム１は、医療機関において診療等の予定を管理する情報処理システムである。診療とは、診察と治療の両方又は少なくとも一方を意味する。医療用予定管理システム１は、通信回線２と、サーバ装置１０と、患者端末２０と、受付端末３０と、医師端末４０とを備える。なお、医療用予定管理システム１は、患者端末２０、受付端末３０及び医師端末４０をそれぞれ２つ以上備えていてもよいが、図１では１つだけを示す。通信回線２は、インターネット等を含み、自回線に接続する装置同士のデータのやり取りを仲介する。通信回線２には、医療用予定管理システム１が備える各装置が有線又は無線で接続されている。

【0015】

患者端末２０は、患者（これから初診を受けようとしている者も含む）によって利用される端末である。受付端末３０は、例えば、医療機関の受付担当者（単に「受付」とも言う）によって利用される端末である。医師端末４０は、例えば、患者に対して診察や治療などを行う医師によって利用される端末である。各端末は、例えば、デスクトップパソコン、ノートパソコン、タブレット端末又はスマートフォン等の情報処理端末である。

【0016】

サーバ装置１０は、患者情報に関する処理を実行する情報処理装置である。患者情報とは、患者に関する情報であり、例えば、患者の氏名や住所等の基本情報、診察や治療の予約情報、問診情報及び診療結果情報等である。また、サーバ装置１０は、患者端末２０、受付端末３０及び医師端末４０による患者情報の表示を制御する。患者端末２０、受付端末３０及び医師端末４０がそれぞれのユーザからの操作を受け付け、サーバ装置１０がユーザ操作に応じて患者情報に関する処理を行うことで、

【0017】

図２は、サーバ装置１０のハードウェア構成を示す図である。サーバ装置１０は、制御部１１と、記憶部１２と、通信部１３と、バス１４とを備える。バス１４は、サーバ装置１０が備える各部を電気的に接続する。

【0018】

（制御部１１）
制御部１１は、例えば不図示の中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵ）である。制御部１１は、記憶部１２に記憶された所定のプログラムを読み出すことによって、医療用予定管理システム１に係る種々の機能を実現するコンピュータである。すなわち、記憶部１２に記憶されているソフトウェアによる情報処理が、ハードウェアの一例である制御部１１によって具体的に実現されることで、制御部１１に含まれる各機能部として実行されうる。これらについては、次節においてさらに詳述する。なお、制御部１１は単一であることに限定されず、機能ごとに複数の制御部１１を有するように実施してもよい。またそれらの組合せであってもよい。

【0019】

（記憶部１２）
記憶部１２は、前述の記載により定義される様々な情報を記憶する。これは、例えば、制御部１１によって実行される医療用予定管理システム１に係る種々のプログラム等を記憶するソリッドステートドライブ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ：ＳＳＤ）等のストレージデバイスとして、あるいは、プログラムの演算に係る一時的に必要な情報（引数、配列等）を記憶するランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ＲＡＭ）等のメモリとして実施されうる。記憶部１２は、制御部１１によって実行される医療用予定管理システム１に係る種々のプログラムや変数等を記憶している。

【0020】

（通信部１３）
通信部１３は、サーバ装置１０から種々の電気信号を外部の構成要素に送信可能に構成される。また、通信部１３は、外部の構成要素からサーバ装置１０への種々の電気信号を受信可能に構成される。さらに好ましくは、通信部１３がネットワーク通信機能を有し、これにより通信回線２を介して、サーバ装置１０と外部機器との間で種々の情報を通信可能に実施してもよい。

【0021】

図３は、患者端末２０のハードウェア構成を示す図である。患者端末２０は、制御部２１と、記憶部２２と、通信部２３と、入力部２４と、出力部２５と、バス２６とを備える。バス２６は、患者端末２０が備える各部を電気的に接続する。制御部２１、記憶部２２及び通信部２３は、図２に示す制御部１１、記憶部１２及び通信部１３と、スペック、モデル等は異なってもよいが、同様のハードウェアである。

【0022】

（入力部２４）
入力部２４は、キー、ボタン、タッチスクリーン及びマウス等のうちの１以上の入力インターフェースを有し、ユーザによる入力を受け付ける。
（出力部２５）
出力部２５は、ディスプレイ及びスピーカ等の出力デバイスを有し、表示面に画面、画像、アイコン、テキスト等といった、ユーザが視認可能な態様で生成された視覚情報を表示し、音声を含む音を出力する。

【0023】

２．機能構成
本節では、本実施形態の機能構成について説明する。前述の通り、各装置の記憶部に記憶されているソフトウェアによる情報処理がハードウェアの一例である制御部によって具体的に実現されることで、制御部に含まれる各機能部が実行されうる。

【0024】

図４は、各装置の制御部の機能構成を示す図である。サーバ装置１０の制御部１１は、サーバ表示部１１１と、ＤＢ制御部１１２（ＤＢ：Ｄａｔａｂａｓｅ）とを備える。患者端末２０の制御部２１は、第１ユーザ表示部２１１と、第１操作受付部２１２とを備える。受付端末３０の制御部３１は、第２ユーザ表示部３１１と、第２操作受付部３１２とを備える。医師端末４０の制御部４１は、第３ユーザ表示部４１１と、第３操作受付部４１２とを備える。

【0025】

サーバ表示部１１１は、医療用予定管理システム１に関するシステム画面を各端末に表示させるための処理を実行する。サーバ表示部１１１は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルの生成及び送信等の処理を行い、システム画面を示すウェブページを患者端末２０に表示させる。なお、サーバ表示部１１１は、医療用予定管理システム１を利用するためのアプリケーションの表示用データの生成及び送信等の処理を行ってもよい。

【0026】

ＤＢ制御部１１２は、各種のデータベースへの情報の出し入れを制御する。ＤＢ制御部１１２は、例えば、上述した基本情報、予約情報、問診情報及び診療結果情報等の患者情報を格納する患者情報ＤＢを制御する。

【0027】

患者端末２０の第１ユーザ表示部２１１は、患者端末２０が有する表示手段であるディスプレイへの表示を制御する。第１ユーザ表示部２１１は、例えば、サーバ表示部１１１から送信されてくるウェブページ又はアプリの画面を表示手段に表示させる。第１操作受付部２１２は、患者が行う操作を受け付ける。

【0028】

受付端末３０の第２ユーザ表示部３１１は、受付端末３０が有する表示手段であるディスプレイへの表示を制御する。第２ユーザ表示部３１１は、例えば、サーバ表示部１１１から送信されてくるウェブページ又はアプリの画面を表示手段に表示させる。第２操作受付部３１２は、医療機関の受付担当者が行う操作を受け付ける。

【0029】

医師端末４０の第３ユーザ表示部４１１は、医師端末４０が有する表示手段であるディスプレイへの表示を制御する。第３ユーザ表示部４１１は、例えば、サーバ表示部１１１から送信されてくるウェブページ又はアプリの画面を表示手段に表示させる。第３操作受付部４１２は、医師が行う操作を受け付ける。

【0030】

３．情報処理
本節では、本実施形態において、プログラムがコンピュータに実行させる情報処理について説明する。医療用予定管理システム１は、医療機関における予定表を管理する予定管理処理を実行する。

【0031】

図５は、予定管理処理の一例を示すアクティビティ図である。図５に示すアクティビティは、患者端末２０、受付端末３０及び医師端末４０がそれぞれ医療用予定管理システム１において提供されるシステム画面を表示することを契機に開始される。まず、サーバ装置１０は、各端末においてログインの操作が行われることで、Ａ１１において、サーバ表示部１１１により、システム画面を示す画面データを各端末に送信して、各端末にシステム画面を表示させる。

【0032】

各端末の利用者（患者、受付担当者、医師）には、予め認証情報が発行されているものとする。なお、患者が初めてログインする場合は、サーバ装置１０は、患者の基本情報の入力を受け付け、患者向けの認証情報を発行する。サーバ表示部１１１は、ログイン時に入力された認証情報が示す各端末の利用者（患者、受付担当者、医師）向けに設計された画面をシステム画面として表示させる。

【0033】

患者端末２０は、Ａ１２において、第１ユーザ表示部２１１により、送信されてきた画面データが示す患者向け画面を表示する。受付端末３０は、Ａ１３において、サーバ表示部１１１から送信されてきた画面データが示す受付向け画面を第２ユーザ表示部３１１に、表示する。医師端末４０は、Ａ１４において、サーバ表示部１１１から送信されてきた画面データが示す医師向け画面を第３ユーザ表示部４１１に、表示する。各端末のユーザ（患者、受付及び医師）は、それぞれ必要なタイミングでシステム画面を表示させて医療用予定管理システム１を利用する。

【0034】

サーバ装置１０は、診療情報を格納する診療情報データベースを記憶している。診療情報とは、患者への診療に関する情報を１回の診療単位でまとめて示す情報である。診療情報は、医療スタッフ及び設備毎に格納される。医療スタッフとは、患者に対して診療を行う人材のことであり、例えば、医師である。設備とは、診療に用いられる機器等のことであり、例えば、医療機関が歯医者であれば、患者が座る椅子と診療に必要な機器とがセットになったユニットと呼ばれる設備である。

【0035】

図６は、診療情報データベースの一例を示す図である。図６に示す診療情報データベースＤＢ１には、医療スタッフの各々について、患者ＩＤ、診療メニュー、診療形式、診療時刻、受付状況及び使用設備を示す診療情報、診療情報ＩＤ（「診療情報Ｓ１１」等）に対応付けて格納されている。また、診療情報データベースＤＢ１には、ユニットの各々について、患者ＩＤ、診療メニュー、診療形式、診療時刻、受付状況及び対応スタッフを示す診療情報が、診療情報ＩＤ（「診療情報Ｓ４１」等）に対応付けて格納されている。

【0036】

患者ＩＤは、診療を受ける患者に割り当てられた識別情報である。診療メニューは、診療の内容を示す情報である。診療時刻は、診療が行われる時刻を示す情報である。診療時刻は、医療機関での患者の受け付けが行われる前は予定された時刻であり、受け付けが行われた後は確定した時刻となる。受付状況は、医療機関の窓口における患者の受け付けの有無を示す。使用設備は、診療の際に使用される設備を示す。対応スタッフは、患者に対応する医療スタッフを示す。

【0037】

ＤＢ制御部１１２は、診療が予約される度に新たな診療情報を作成し、診療を行う医療スタッフ及び診療に用いられるユニットに対応付けて診療情報データベースＤＢ１に格納する。このように診療情報が格納されることで、診療情報データベースＤＢ１を参照すれば、各医療スタッフ及び各設備の予約の状況、予約されている診療の内容及び診療の実施状況等が把握できるようになっている。

【0038】

患者は、診療の予約をする際に、例えば、患者端末２０に表示された患者向け画面において診療の予約及び問診を行うための画面を表示させる操作を行う。サーバ表示部１１１は、患者端末２０に対してこの操作が行われると、患者向けの予約用画面を患者端末２０に表示させる。本実施形態では、患者向けの予約用画面は、予約用の第１画面及び第２画面を含んで構成されている。

【0039】

図７は、患者向けの予約用の第１画面の一例を示す図である。図７に示す患者向けの予約用の第１画面Ｃ１には、診療メニュー毎に用意された予約アイコンＥ１～Ｅ６が表示されている。例えば、予約アイコンＥ１は、「治療Ｆ１」という診療メニューと、診察等に要する時間が「３０分」であることと、診療形式が「対面」であることと、診療の概要を示す文章と、予約に進むボタンＢ１１とを含む画像である。

【0040】

また、予約アイコンＥ２～Ｅ６は、それぞれ「治療Ｆ２」、「治療Ｆ３」、「治療Ｆ４」、「相談Ｇ１」及び「相談Ｇ２」という各診療メニューについての同様の画像である。第１操作受付部２１２は、例えば、患者が診療を受けたい診療メニューの予約アイコンの予約に進むボタンＢ１１への操作を、診療の予約の操作として受け付ける。サーバ表示部１１１は、予約に進むボタンＢ１１への操作が受け付けられると、患者向けの予約用の第２画面を患者端末２０に表示させる。

【0041】

図８は、患者向けの予約用の第２画面の一例を示す図である。図８に示す患者向けの予約用の第２画面Ｃ２には、診療メニューの表示欄Ｅ２１と、予約日時の入力欄Ｅ２２と、診療形式の入力欄Ｅ２３と、問診情報の入力欄Ｅ２４と、患者向け予定表Ｅ２５と、予約確定ボタンＢ１２とが表示されている。表示欄Ｅ２１には、図７に示す第１画面Ｃ１で選択された診療メニューが表示されている。

【0042】

サーバ表示部１１１は、図６に示す診療情報データベースＤＢ１を参照し、医療スタッフの予約が可能な時間帯を示す患者向け予定表Ｅ２５を表示させる。サーバ表示部１１１は、本実施形態では、医療スタッフが一人でも予約可能であり且つ設備が１つでも予約可能な日時を、予約可能な時間帯として白い矩形の領域で示し、医療スタッフが一人も予約できず又は設備が１つも予約できない時間帯を、予約不可の時間帯として斜線パターンの領域で示す患者向け予定表Ｅ２５を表示させる。つまり、サーバ表示部１１１は、患者端末２０から予約される場合は、医療スタッフ及び設備の両方の予定に基づく予約可能枠から予約させる予定表Ｅ２５を表示させる。

【0043】

患者は、患者向け予定表Ｅ２５を見ながら自分が予約したい日時を入力欄Ｅ２２に入力する。なお、この入力は、患者向け予定表Ｅ２５において予約したい日時を指定する操作によって行われてもよい。また、患者は、診療形式として対面及びオンラインのいずれかを選択可能な場合は、選択した診療形式を入力欄Ｅ２３に入力する。診療形式が選択可能か否かは、「治療Ｆ１」等ではできないが、「相談Ｇ１」ではできるというように、診療メニューごとに決まっている。

【0044】

患者は、可能な場合は、入力欄Ｅ２４に診療メニューごとに設けられた問診情報を入力する。なお、問診情報の入力は必須ではなく、例えば、医療機関に訪問したときに行うこともできる。第１操作受付部２１２は、患者による上記の各操作を受け付けた後に予約確定ボタンＢ１２への操作を受け付けると、入力された予約のための各情報を示す予約データをサーバ装置１０に送信する。このように、患者端末２０は、Ａ２１において、第１ユーザ表示部２１１により、予約用の画面及び問診用の画面を表示して、第１操作受付部２１２により、患者による診療の予約及び（入力された場合は）問診の操作を受け付ける。

【0045】

サーバ装置１０は、Ａ２２において、ＤＢ制御部１１２により、患者端末２０において受け付けられた診療の予約及び問診の受付処理を行う。ＤＢ制御部１１２は、まず、図６に示す診療情報データベースＤＢ１に、新たな診療情報を格納する処理を受付処理として実行する。具体的には、ＤＢ制御部１１２は、予約を行った患者の患者ＩＤを含む診療情報を格納する診療領域を診療情報データベースＤＢ１に生成し、生成した領域に診療情報を格納する。

【0046】

ＤＢ制御部１１２は、例えば、生成した診療領域に、入力された診察メニュー及び診察形式を格納し、入力された予約日時を診療日時として格納する。また、ＤＢ制御部１１２は、生成した診療領域に、予約日時に予定が空いている診察スタッフ及び設備のうち任意の診察スタッフ及び設備を対応スタッフ及び使用設備として格納する。このように、本実施形態では、患者は特定の医療スタッフ及び特定の設備を指定して予約することはできないようになっている。

【0047】

ＤＢ制御部１１２は、予約日時を診療日時として格納する際に、予約日時に予定が空いている診察スタッフがいない場合、すなわち、患者が誤って予約不可の時間帯を予約日時として入力してきた場合は、予約日時を格納せず、予約の受付処理ができないことを通知する通知データを、サーバ表示部１１１を介して患者端末２０に送信する。患者端末２０は、第１ユーザ表示部２１１により、通知された内容を表示し、予約可能な日時の入力を促す。そうして、ＤＢ制御部１１２は、予約可能な日時が入力された場合に、予約の受付処理を実行する。

【0048】

診療情報データベースＤＢ１では、医療スタッフ毎及び設備毎に診療情報が格納されたが、サーバ装置１０は、患者毎に情報を格納する患者情報データベースも記憶している。
図９は、患者情報データベースの一例を示す図である。図９に示す患者情報データベースＤＢ２には、患者の基本情報、診療情報ＩＤ、問診情報、診療結果情報、次回診療情報及び会計情報が格納される。患者の基本情報は、患者が医療用予定管理システム１のユーザ登録を行ったときに入力されて格納されている。診療結果情報、次回診療情報及び会計情報については後ほど説明する。

【0049】

ＤＢ制御部１１２は、診療情報データベースＤＢ１に格納した診療情報の診療情報ＩＤを、その診療情報に含まれる患者ＩＤに対応付けて患者情報データベースＤＢ２に格納する。また、ＤＢ制御部１１２は、問診情報が入力された場合は、共に入力された診療情報に対応付けて患者情報データベースＤＢ２に格納する。ＤＢ制御部１１２は、このようにして、患者による予約が行われた場合の予約及び問診の受付処理を実行する。

【0050】

患者は、患者端末２０を操作して行う予約以外に、医療機関に電話して予約を行うことができる。その場合、医療機関の受付担当者は、例えば、受付端末３０に表示された受付向け画面において診療の予約を行うための画面を表示させる操作を行う。サーバ表示部１１１は、受付端末３０に対してこの操作が行われると、受付向けの予約用画面を受付端末３０に表示させる。

【0051】

図１０は、受付向けの予約用画面の一例を示す図である。図１０に示す受付向けの予約用画面Ｃ３には、患者名の入力欄Ｅ３１と、診療メニューの入力欄Ｅ３２と、予約日時の入力欄Ｅ３３と、診療形式の入力欄Ｅ３４と、対応スタッフの入力欄Ｅ３５と、使用設備の入力欄Ｅ３６と、予定表Ｌ１１と、予約確定ボタンＢ１３とが表示されている。

【0052】

予定表Ｌ１１は、各患者の診療の予定を示す表である。本実施形態では、診療情報が時系列に並べて予定表Ｌ１１に示されている。サーバ表示部１１１は、図６に示す診療情報データベースＤＢ１から診療情報を読み出し、各医療スタッフ及び各設備の予定欄に時系列に沿って並べて予定表Ｌ１１として表示させる。サーバ表示部１１１は、本実施形態では、予約可能な時間帯を白い矩形の領域で示し、既に予約が入っている時間帯を、診察情報を含む矩形の領域（以下「予約領域」と言う）で示す表を予定表Ｌ１１として表示させる。

【0053】

受付担当者は、予定表Ｌ１１を見ながら患者と話をして、患者名を入力欄Ｅ３１に、患者が予約したい日時を入力欄Ｅ３３に入力する。また、受付担当者は、患者から聞いた診療メニューを入力欄Ｅ３２に、診療形式を及び入力欄Ｅ３４に入力する。また、受付担当者は、予約日時に空いている医療スタッフ及び設備から、対応スタッフを入力欄Ｅ３５に、使用設備を入力欄Ｅ３６に入力する。サーバ表示部１１１は、入力された予約を示す情報を、予約された医療スタッフ及び設備の予定表における予約領域に表示させる。

【0054】

図１０の例では、サーバ表示部１１１は、「患者Ｋ６」の「治療Ｆ１」の「１２：３０－１３：００」における予約と、使用設備である「ユニットＵ２」とを示す予約領域Ｈ３１を、対応スタッフである「医師Ｄ２」に対応付けて表示させている。また、サーバ表示部１１１は、同じ予約と、対応スタッフである「医師Ｄ２」とを示す予約領域Ｈ３２を、使用設備である「ユニットＵ２」に対応付けて表示させている。また、サーバ表示部１１１は、予約が入力された段階では、医療機関における来訪の受け付けがまだ行われていないので、予約はされているが未受け付けであることを示す「未」という文字を表示させている。

【0055】

なお、患者が予約したい日時（時間帯）の入力は、予定表Ｌ１１において予約領域を直接指定する操作によって行われてもよい。例えば、受付担当者が医療スタッフの予定欄において予約したい日時を指定する操作を行う。すると、サーバ表示部１１１は、医療スタッフの予定欄の該当する日時にその医療スタッフの名前及び予約日時を含む予約領域を表示させる。その際、サーバ表示部１１１は、指定された予約日時を入力欄Ｅ３３に、その医療スタッフの名前を入力欄Ｅ３５に表示させる。これにより入力欄Ｅ３３及び入力欄Ｅ３５への入力が不要になる。

【0056】

また、サーバ表示部１１１は、指定された予約日時に予定が空いている設備がある場合、その設備（複数ある場合はそのうちのいずれか）の名前を入力欄Ｅ３６に表示させる。この状態で予約確定ボタンＢ１３を押す操作が行われると、サーバ表示部１１１は、入力欄Ｅ３６に表示された予約を示す情報を、予約された設備の予定表における予約領域に表示させる。サーバ表示部１１１は、設備の予定欄において予約したい日時を指定する操作が先に行われた場合も、同様に、予定が空いている医療スタッフの名前を入力欄Ｅ３５に表示させ、予約確定ボタンＢ１３を押す操作が行われた場合に、予約を示す情報を、予約された医療スタッフの予定表における予約領域に表示させる。

【0057】

このように、診療の予約は、予約の日時が指定されることで行われる。そして、サーバ装置１０は、医療スタッフ及び設備のいずれか一方の予約の日時が指定された場合に、前記医療スタッフ及び前記設備の両方の当該日時の予定を確保する処理を実行する。このような態様によれば、医療スタッフ及び設備のどちらからでも両方の予定を確保することができる。

【0058】

このように、受付端末３０は、Ａ２３において、第２ユーザ表示部３１１により、診療の予約用の画面を表示して、第２操作受付部３１２により、受付担当者による診療の予約操作を受け付ける。上述したように、患者が患者向けの予約用の第２画面Ｃ２を用いて予約する場合は特定の医療スタッフ及び設備を指定して予約することはできないが、受付担当者が受付向けの予約用画面Ｃ３を用いて予約する場合は、上記のとおり、特定の医療スタッフ及び設備を指定して予約することができるようになっている。

【0059】

また、第２操作受付部３１２は、予約情報Ｈ３３及びＨ３４が示すように、ユニットＵ１について２つの予約を重複して受け付けている。ＤＢ制御部１１２は、受付端末３０から入力された予約の場合は、このように１つの設備について重複して入力された２以上の予約の受付処理を実行する。なお、図１０の例では示されていないが、ＤＢ制御部１１２は、受付端末３０から入力された予約の場合は、１人の医療スタッフについて重複して入力された２以上の予約の受付処理も実行する。

【0060】

つまり、ＤＢ制御部１１２は、患者端末２０からの予約の場合は、上述したように医療スタッフの予約可能枠から予約を受け付けたが、受付端末３０からの予約の場合は、医療スタッフの予約可能枠に関わらずその予約を受け付ける。これにより、例えば、診療の緊急性が高い患者が予約するという状況が生じた場合に、医療スタッフや設備の予定が埋まっていても予約を入れられるようにして、ロバスト性を高めている。

【0061】

予約を入れた患者は、予約日時に診療を受けるために医療機関を訪問し、受付窓口に行って受け付けを行う。医療機関の受付担当者は、受付端末３０に対して患者の訪問を受け付ける操作を行う。受付端末３０は、Ａ３１において、第２ユーザ表示部３１１により、患者の来訪の受付用の画面を表示する。

【0062】

図１１は、来訪の受付用の画面の一例を示す図である。図１１に示す来訪の受付用の画面Ｃ４には、各患者の診療情報を時系列に並べて示す診療時間の予定表Ｌ１２が表示されている。予定表Ｌ１２では、各患者の診療情報が医療スタッフ毎及び設備毎に示されている。予定表Ｌ１２には、現在時刻線Ｊ１が示されている。現在時刻線Ｊ１より前は過去の時間帯を表し、現在時刻線Ｊ１より後は未来の時間帯を表している。

【0063】

サーバ表示部１１１は、受け付けがまだされていない診療情報には診療情報Ｍ３８のように「未」という文字を表示させる。診療情報Ｍ３５のように予約の時刻を過ぎても受け付けがされていない（キャンセルされた）診療情報は「未」という文字が表示されたままになる。また、サーバ表示部１１１は、受け付けがされて診療を待っている状態では診療情報Ｍ３７のように「診」という文字を表示させる。また、サーバ表示部１１１は、診療は始まっているが診療結果がまだ入力されていない状態でも、診療情報Ｍ３６のように「診」という文字を表示させる。

【0064】

サーバ表示部１１１は、診療結果が入力されて会計待ちの状態になると診療情報Ｍ３３のように「計」という文字を表示させる。また、サーバ表示部１１１は、会計処理が完了した状態になると診療情報Ｍ３４のように「完」という文字を表示させる。なお、各診療情報が示す診療は、予約された時刻のとおりに行われたとは限らないが、本実施形態では、サーバ表示部１１１は、診療済みの診療情報についても、予約された時刻のとおりの診療時刻を示すものとする。

【0065】

受付担当者は、来院した患者が窓口に来ると、その患者の来訪を受け付ける来訪操作を行う。来訪操作は、例えば、「未」という文字をクリックする操作等である。受付端末３０は、Ａ３１において、第２操作受付部３１２により、受付担当者による来訪操作を受け付け、患者ＩＤ及び来訪を示す来訪データをサーバ装置１０に送信する。サーバ装置１０は、来訪データを受信すると、Ａ３２において、ＤＢ制御部１１２により、来訪データが示す患者の来訪を受け付ける受付処理を実行する。

【0066】

ＤＢ制御部１１２は、図５に示す診療情報データベースＤＢ１の該当する診療情報の受付状況を受け付けが「無い」状態から「有る」状態に変更する処理を来訪の受付処理として実行する。サーバ表示部１１１は、ＤＢ制御部１１２が受付処理を実行すると、該当する診療情報の「未」という文字を「診」という文字に変更して受付端末３０に表示させる。

【0067】

ここで、予約時に患者が問診の入力を行っていない場合、問診の入力が行われる。来訪後の問診入力は、患者自身が患者端末２０を用いて行う第１の方法と、患者又は受付担当者が受付端末３０を用いて行う第２の方法とがある。第１の方法の場合、患者端末２０は、Ａ３３において、第１ユーザ表示部２１１により、図８と同様の問診情報の入力欄Ｅ２４を表示して、第１操作受付部２１２により、患者による問診の入力操作を受け付ける。問診情報の入力欄Ｅ２４の表示方法としては、患者が患者向け画面を表示させる方法の他にと、例えば、受付端末３０が問診情報の入力画面のリンクを示すコード画像（例えばＱＲコード（登録商標））を表示して、患者端末２０がそのコード画像を読み取ることで入力画面を表示させる方法を用いてもよい。

【0068】

第２の方法の場合、受付端末３０は、Ａ３４において、第２ユーザ表示部３１１により、図８と同様の問診情報の入力欄Ｅ２４を表示して、第２操作受付部３１２により、問診の入力操作を受け付ける。第２の方法では、受付端末３０がタブレット端末である場合に、そのタブレット端末を患者に渡して問診情報を入力させてもよいし、受付端末３０を患者に操作させることが難しければ、紙の問診票に患者が記載した内容を受付担当者が入力してもよい。

【0069】

第１の方法及び第２の方法のどちらで入力された場合も、すなわち、患者端末２０及び受付端末３０のどちらで入力された場合も、サーバ装置１０は、Ａ３５において、ＤＢ制御部１１２により、Ａ２２と同様に問診の受付処理を実行する。このような態様によれば、患者にとって都合が良い端末を用いて問診情報を入力することができる。一方で、Ａ２１において来訪前に予め問診情報を入力してもらう場合は、時間をかけて情報量の多い問診を行うことが可能であり、また、医療機関側も、予め問診情報が受け付けられるので、問診情報に基づいて診療の準備をしておくことができる。

【0070】

来訪の受け付けと場合によっては問診の受け付けとが終わった患者は、予約されていたユニットにおいて、予約されていた医師の診療を受ける。医師は、患者に対して診療を行うとともに、医師端末４０を用いて、患者の症状及び処置内容のうちの少なくとも一方を診療結果として入力する。医師端末４０は、Ａ４１において、第３ユーザ表示部４１１により、診療結果の入力用の画面を表示して、第３操作受付部４１２により、医師による診療結果の入力操作を受け付ける。第３操作受付部４１２は、入力された診療結果を示す結果データをサーバ装置１０に送信する。

【0071】

サーバ装置１０は、結果データを受信すると、Ａ４２において、ＤＢ制御部１１２により、結果データが示す診療結果を受け付ける受付処理を実行する。ＤＢ制御部１１２は、結果データが示す診療結果を対応する診療を受けた患者に対応付けて図９に示す患者情報データベースＤＢ２に格納する処理を診療結果の受付処理として実行する。

【0072】

また、医師は、診療の終わりに、次回の診療の予定について患者と話をする場合がある。その場合、医師は、次回の診療に必要な時間の長さと、次回の診療までの間隔とのうちの少なくともいずれか一方を次回診療情報として入力する。医師端末４０は、Ａ４３において、第３ユーザ表示部４１１により、医師による申し送りの入力用画面を表示する。

【0073】

図１２は、申し送りの入力用画面の一例を示す図である。図１２に示す申し送りの入力用画面Ｃ５には、患者名の入力欄Ｅ５１と、次回時間の入力欄Ｅ５２と、次回間隔の入力欄Ｅ５３と、申し送りの確定ボタンＢ１５とが表示されている。受付端末３０は、第３操作受付部４１２により、各入力欄への入力操作と、確定ボタンＢ１５への操作を、医師による次回診療情報の入力操作として受け付ける。第３操作受付部４１２は、入力された次回診療情報及び診療された患者を示す申し送りデータをサーバ装置１０に送信する。

【0074】

サーバ装置１０は、申し送りデータを受信すると、Ａ４４において、ＤＢ制御部１１２により、次回診療データが示す次回診療情報を保存する保存処理を実行する。ＤＢ制御部１１２は、申し送りデータが示す次回診療情報を、その次回診療データが示す患者に対応付けて図９に示す患者情報データベースＤＢ２に格納する処理を次回診療情報の保存処理として実行する。なお、医師による申し送り情報は上記に限らない。診療メニュー、診療形式、対応スタッフ及び使用設備等の情報が申し送りされてもよい。

【0075】

患者は、診療が終わると、会計のために受付窓口に行く。受付担当者は、診療済みの患者が来ると、会計を行うための会計画面を表示させる操作を行う。この操作が行われると、サーバ装置１０は、患者情報データベースＤＢ２を参照して患者への処置内容を読み出し、読み出した処置内容に応じた料金を算出する。サーバ装置１０は、サーバ表示部１１１により、算出した料金を示す画面データを受付端末３０に送信する。受付端末３０は、Ａ５１において、第２ユーザ表示部３１１により、送信されてきた画面データが示す会計用の画面を表示する。

【0076】

受付端末３０は、Ａ５１において、第２操作受付部３１２により、表示された料金の支払いを受け付けたことを示す操作を会計操作として受け付ける。第２操作受付部３１２は、診療を受けた患者、請求された料金及び支払いが完了したこと等を会計情報として示す通知データをサーバ装置１０に送信する。サーバ装置１０は、Ａ５２において、ＤＢ制御部１１２により、送信されてきた通知データが示す会計情報を受け付ける受付処理を実行する。ＤＢ制御部１１２は、通知データが示す会計情報を料金の請求先である患者に対応付けて図９に示す患者情報データベースＤＢ２に格納する処理を会計情報の受付処理として実行する。

【0077】

患者は、料金の支払いを完了させるとともに、次回の予約をしていく場合がある。その場合、受付担当者は、医師からの申し送り事項に基づいて患者の次回の予約を入力する。サーバ装置１０は、患者情報データベースＤＢ２を参照して患者の次回診療情報を読み出し、読み出した次回診療情報に基づいて次回の予約情報を生成する。サーバ装置１０は、サーバ表示部１１１により、生成した予約情報を示す予約データを受付端末３０に送信する。受付端末３０は、Ａ５３において、第２ユーザ表示部３１１により、送信されてきた予約データが示す予約情報を反映した受付向けの予約用画面を表示する。

【0078】

図１３は、受付向けの予約用画面の一例を示す図である。図１３に示す受付向けの予約用画面Ｃ６には、患者名の入力欄Ｅ６１と、診療メニューの入力欄Ｅ６２と、予約日時の入力欄Ｅ６３と、診療形式の入力欄Ｅ６４と、対応スタッフの入力欄Ｅ６５と、使用設備の入力欄Ｅ６６と、予定表Ｌ１６と、予約確定ボタンＢ１６とが表示されている。患者名、診療メニュー、診療形式及び対応スタッフは、今回の診療と同じ内容が予め入力されている。なお、これらの情報が申し送りされている場合は、その申し送りされた情報が予め入力されていればよい。

【0079】

予約日時には、対応スタッフの空き日程のうち、次回診療情報が示す次回時間及び次回間隔の条件を満たす日程から任意の時間帯が予約日時として示されている。使用設備には、その予約日時に空いている任意の設備が示されている。このように、サーバ表示部１１１は、患者を診療した医師からの申し送りがある場合は、申し送りされた情報に基づいて次回の予約内容を決定し、決定した内容の予約情報を受付端末３０に表示させる。

【0080】

受付担当者は、表示された予約日時を患者に伝え、問題なければ予約確定ボタンＢ１６を操作して予約を確定させる。また、受付担当者は、患者に予約内容の変更の希望があれば、その変更を反映する入力を行ってから予約確定ボタンＢ１６を操作して予約を確定させる。ＤＢ制御部１１２は、受付端末３０から入力された予約の受付処理を、Ａ２２と同様に実行する。

【0081】

以上のとおり、医療用予定管理システム１は、医療機関における予定表を表示するシステムである。医療用予定管理システム１は、ユーザの第１端末から予約を受け付け、第１状態として表示する第１表示処理を実行する。上述した患者は、ここでいうユーザの一例である。また、患者端末２０は、第１端末の一例である。また、例えば、図１０に示す予約情報Ｈ３３及びＨ３４のように、予約はされているが未受け付けであることを示す「未」という文字の表示が、第１状態としての表示の一例である。サーバ表示部１１１及びＤＢ制御部１１２は、第１表示処理を実行する第１表示処理部の一例として機能する。

【0082】

医療用予定管理システム１は、ユーザの第１端末からの予約に加え、医療機関の第２端末からの予約を受け付ける。受付端末３０は、第２端末の一例である。医療用予定管理システム１は、第１端末からの予約は、図８の説明で述べたように、医療スタッフの予定に基づく予約可能枠から受け付ける。一方、医療用予定管理システム１は、第２端末からの予約は、図１０の説明で述べたように、医療スタッフの予約可能枠にかかわらず受け付ける処理を第１表示処理として実行する。このような態様によれば、患者に対しては予約の重複を避けて確実な予約を可能とし、受付担当者に対しては急患等に対応可能なロバスト性の高い予約を可能とすることができ、利便性が高い予約システムを提供することができる。

【0083】

また、医療用予定管理システム１は、第２端末からの予約の場合、図１０の説明で述べたように、医療スタッフの予約及び設備の予約の両方を受け付ける処理を第１表示処理として実行する。図１０の例では、対応スタッフの入力欄Ｅ３５への入力で医療スタッフの予約が受け付けられ、使用設備の入力欄Ｅ３６への入力で設備の予約が受け付けられる。このような態様によれば、医療機関を通せば特定の医療スタッフ及び特定の設備を予約することができる。

【0084】

また、第２端末からの予約において、例えば、図１０で説明したように予定表Ｌ１１の予約領域を直接指定する操作によって予約が行われる場合でも、予約を確定すると、医療スタッフ及び設備の両方に予定が入る。その際、医療スタッフ及び設備のどちらから予約領域を指定しても、医療スタッフ及び設備の両方に予定を入れることが出来るため、例えば医療スタッフ及び設備で予約領域を指定する順番が決まっている場合に比べて、予約の操作が煩雑にならないようにすることができる。

【0085】

医療用予定管理システム１は、医療機関の第２端末からユーザの来訪を受け付け、第２状態として表示する第２表示処理を実行する。例えば、図１１に示す「診」という文字の表示が、第２状態としての表示の一例である。「診」という文字の表示は、診療情報Ｍ３７のように、患者の来訪が受け付けられて診療待ちの状態と、診療情報Ｍ３６のように、診療は始まっているが診療結果がまだ入力されていない状態とを示す。サーバ表示部１１１及びＤＢ制御部１１２は、第２表示処理を実行する第２表示処理部の一例として機能する。

【0086】

医療用予定管理システム１は、医療機関の第３端末からユーザの症状または処置内容を受け付け、第３状態として表示する第３表示処理を実行する。医師端末４０は、第３端末の一例である。例えば、図１１に示す診療情報Ｍ３３のように、医師によって診療結果が入力されて会計待ちの状態であることを示す「計」という文字の表示が、第３状態としての表示の一例である。サーバ表示部１１１及びＤＢ制御部１１２は、第３表示処理を実行する第３表示処理部の一例として機能する。

【0087】

医療用予定管理システム１は、医療機関の第２端末から、ユーザの会計情報を受け付け、第４状態として表示する第４表示処理とを実行させる。例えば、図１１に示す診療情報Ｍ３４のように、会計処理が完了した状態であることを示す「完」という文字の表示が、第４状態としての表示の一例である。以上のとおり、本実施形態によれば、第１端末、第２端末及び第３端末という３種類の端末から各種の情報が受け付けられる場合でも、ユーザが第１状態、第２状態、第３状態及び第４状態のいずれであるかが表示されるので、それらの表示が行われない場合に比べて、ユーザの状態を容易に把握することができる。サーバ表示部１１１及びＤＢ制御部１１２は、第４表示処理を実行する第４表示処理部の一例として機能する。

【0088】

本実施形態では、上記のとおり、図１１に示す予定表Ｌ１２のように１つの予定表の中で複数の患者のそれぞれのステータス情報が一気通貫で表示され、かつ、そのステータス情報が各医療スタッフ及び各設備に紐付けて表示される。この予定表は、医療機関によって管理されているが、患者の患者端末２０からの予約操作によっても更新される。また、この予定表には、医療スタッフと設備の予定が同時並列して表示される。

【0089】

これにより、医療スタッフと、医療設備の空き状況を連動して把握することができる。例えば、医療スタッフと医療設備の両方の空状況や、担当しているユーザ（患者）のステータス状態を容易に把握することができる。また、例えばステータス情報が患者別に表示される場合に比べて、予定表の視認性向上と操作性向上とが図られている。

【0090】

医療用予定管理システム１は、ユーザの第１端末からの予約の場合、図５に示すＡ２２で説明した処理のように、問診情報をその第１端末から受け付ける第１問診処理を実行する。また、医療用予定管理システム１は、医療機関の第２端末からの予約の場合、図５に示すＡ３５で説明した処理のように、問診情報をその第２端末又は第１端末から受け付ける第２問診処理を実行する。このような態様によれば、患者の都合に合わせて第１端末及び第２端末のいずれでも問診を入力可能なので、問診の入力を促進することができる。また、第１端末からの予約時に問診情報も受け付けた場合は、問診情報を事前に把握することができる。

【0091】

医療用予定管理システム１は、医療機関の第３端末から、次回診療の時間長さ又は次回診療までの間隔の少なくとも一方（本実施形態では両方を示す次回診療情報）を受け付け、図５に示すＡ４４で説明した処理のように、ユーザ情報と関連付けて保存する保存処理を実行する。ここでいうユーザ情報とは、ユーザに関する情報のことであり、本実施形態では、図９に示すような患者に関する基本情報である。医療用予定管理システム１は、例えば、次回診療情報を患者の基本情報に対応付けて患者情報データベースＤＢ２に格納する処理を保存処理として実行する。

【0092】

このような態様によれば、医師からの申し送りを不要にすることができる。また、図１３の説明で述べたように、受け付けた次回診療情報に基づいて次回診療の予約日時の候補を提示することができ、次回診療情報が保存されない場合に比べて、予約を入力する際の操作を簡略化することができる。

【0093】

<その他の実施形態>

【0094】

<オンライン診療の予約>
実施形態では、診療の予約に、対面診療の予約とオンライン診療の予約とが含まれていた。その場合に、医療用予定管理システム１は、対面診療の予約が受け付けられた場合は、その予約を第１状態として表示する処理を第１表示処理として実行し、オンライン診療の予約が受け付けられた場合は、その予約を第２状態として表示する処理を第２表示処理として実行してもよい。

【0095】

図１４は、受付向けの予約用画面の一例を示す図である。図１４に示す受付向けの予約用画面Ｃ７には、図１０に示すものと同じ患者名の入力欄Ｅ３１等の各入力欄と、予定表Ｌ１７と、予約確定ボタンＢ１３とが表示されている。図１５の例では、診療形式の入力欄Ｅ３４に「オンライン」が入力されている。この場合、設備は使用されないので、使用設備の入力欄Ｅ３６は「なし」となっている。サーバ表示部１１１は、予約用画面Ｃ７において、診療形式が対面の予約情報Ｈ３３等は「未」という文字を第１状態として表示している。

【0096】

一方、サーバ表示部１１１は、予約用画面Ｃ７において、診療形式がオンラインの予約情報Ｈ３５は「診」という文字を第２状態として表示している。オンライン診療の予約を行った患者は、医療機関を来訪することがない。オンライン診療でも対面診療と同じく第１状態で表示されていると、受付担当者は、予約時間が近づいているのにまだ来訪がないということで状況によっては患者に確認の連絡を行うことが起こりうる。上記のとおりオンライン診療は第２状態で表示することで、オンライン診療の患者の来訪を誤って待つことがないようにすることができる。また、オンライン診療の場合も来訪の受け付けをする場合に比べて、受付端末３０の操作を簡略化することができる。

【0097】

また、サーバ表示部１１１は、予約情報Ｈ３５に、オンライン診療であることを示すアイコンＰ３５を重ねて表示させている。このように、サーバ表示部１１１は、対面診療とオンライン診療とで表示態様を異ならせることで、表示態様が一律である場合に比べて、オンライン診療の予約の視認性を向上させることができる。

【0098】

図１５は、サーバ装置１０が実行する処理の一例を示すフロー図である。サーバ装置１０は、まず、Ｓ１１において、予約を受け付ける処理を実行する。サーバ装置１０は、Ｓ１２において、その予約がユーザの第１端末（実施形態では患者端末２０）から受け付けたのか、医療機関の第２端末（実施形態では受付端末３０）から受け付けたのかを判断する。

【0099】

サーバ装置１０は、Ｓ１２において第１端末から受け付けたと判断した場合（例えば患者が自分の患者端末２０から予約を行った場合）、Ｓ２１において、医療スタッフの予約可能枠からその予約を受け付ける。次に、サーバ装置１０は、Ｓ２２において、予約を受け付けた診療が対面診療かオンライン診療かを判断する。サーバ装置１０は、予約を受け付けた診療が対面診療であると判断した場合は、Ｓ２３において、サーバ表示部１１１により、例えば図８に示すように、医療スタッフの予約状態を第１状態として患者端末２０に表示させる。

【0100】

サーバ装置１０は、Ｓ１２において第２端末から受け付けたと判断した場合（例えば患者が受付担当者に電話して受付端末３０から予約をしてもらった場合）、Ｓ３１において、医療スタッフの予約可能枠にかかわらずその予約を受け付ける。次に、サーバ装置１０は、Ｓ３２において、設備の予約を受け付ける。続いて、サーバ装置１０は、Ｓ３３において、サーバ表示部１１１により、例えば図１１に示すように、医療スタッフ及び設備の予約状態を第１状態として受付端末３０に表示させる。なお、第２端末からの予約は、設備の予約から受け付けられてもよい。その場合、サーバ装置１０は、Ｓ３１において、設備の予約可能枠にかかわらずその予約を受け付け、Ｓ３２において、医療スタッフの予約を受け付ける。

【0101】

このように予約を行った患者が、医療機関を訪れて受付窓口で受け付けを行ったとする。その場合、サーバ装置１０は、Ｓ４１において、医療機関の第２端末（実施形態では受付端末３０）からユーザの来訪を受け付ける処理を実行する。次に、サーバ装置１０は、Ｓ４２において、サーバ表示部１１１により、受け付けた来訪の状態を第２状態として表示させる処理を実行する。第２状態の表示は、例えば、受付端末３０又は医師端末４０によって行われる。

【0102】

ここで、Ｓ２２において、予約を受け付けた診療がオンライン診療であると判断した場合、サーバ装置１０は、Ｓ４２において、サーバ表示部１１１により、受け付けたオンライン診療の予約の状態を第２状態として表示させる処理を実行する。Ｓ１１においてオンライン診療の予約が受け付けられた場合も、Ｓ４１において来訪が受け付けられた場合も、患者は、医師によって診療を受ける。

【0103】

その場合、サーバ装置１０は、Ｓ５１において、医療機関の第３端末（本実施形態では医師端末４０）からユーザの症状又は処置内容を受け付ける処理を実行する。次に、サーバ装置１０は、Ｓ５２において、サーバ表示部１１１により、受け付けた症状又は処置内容の状態を第３状態として表示させる処理を実行する。第３状態の表示は、例えば、受付端末３０又は医師端末４０によって行われる。

【0104】

ここで、医師は、患者と次回の診療の予定について確認をする場合がある。その場合、サーバ装置１０は、Ｓ５３において、医療機関の第３端末（医師端末４０）から次回の診療に関する次回診療情報を受け付ける処理を実行する。次に、サーバ装置１０は、Ｓ５４において、ＤＢ制御部１１２により、受け付けた次回診療情報を保存する処理を実行する。次回の確認が行われない場合はＳ５３及びＳ５４の処理は実行されない。

【0105】

診療が終わった患者は、会計窓口において支払いを行う。その場合、サーバ装置１０は、Ｓ６１において、医療機関の第２端末（受付端末３０）からユーザの会計情報を受け付ける処理を実行する。次に、サーバ装置１０は、Ｓ６２において、サーバ表示部１１１により、受け付けた会計情報の状態を第４状態として表示する処理を実行する。第４状態の表示は、例えば、受付端末３０によって行われる。

【0106】

窓口では、そのまま次回の予約が行われる場合がある。その際、医師からの次回診療情報の申し送りがある場合は、サーバ装置１０は、Ｓ７１において、サーバ表示部１１１により、図１３で説明したような次回診療情報を含む予約用画面を受付端末３０に表示させる。そして、サーバ装置１０は、Ｓ７２において、次回の予約の受け付け及び受け付けた予約の状態を第１状態として受付端末３０に表示させる。なお、申し送りがない場合でも、サーバ装置１０は、通常の予約用画面を受付端末３０に表示させて予約を受け付ける。

【0107】

医療用予定管理システム１は、上記のとおり、サーバ装置１０が異なる端末（患者端末２０、受付端末３０及び医師端末４０）と通信し、状態を一元管理するＳａａＳ型の医療管理システムである。ＳａａＳ型のシステムでは、インターネット経由で様々なユーザからアクセスされるが、医療用予定管理システム１は、アクセスしてくる端末ごとに異なる処理を実行する制御を行いつつ、患者の状態を一括で管理している。このような態様によれば、状態が個別に管理される場合に比べて、ユーザである患者の状態を容易に把握することができる。

【0108】

<ステータス状態の登録>
医療用予定管理システム１は、第１状態、第２状態、第３状態及び第４状態という患者のステータス状態を、患者端末２０、受付端末３０及び医師端末４０から所定の情報（予約、来訪、診療結果、会計情報）を受け付けることを契機に切り替えてきた。医療用予定管理システム１は、こうして切り替えたステータス情報を登録するようにしてもよい。

【0109】

図１６は、患者情報データベースの別の一例を示す図である。図１６に示す患者情報データベースＤＢ３には、図９に示す各情報に加えて、ステータス状態が格納されている。図１６の例では、第１状態の一例である「未受付」、第２状態の一例である「診療待ち」、第３状態の一例である「会計待ち」、第４状態の一例である「支払完了」が患者情報データベースＤＢ３に格納されている。

【0110】

ＤＢ制御部１１２は、患者の診療の予約を受け付けた場合にその患者に対応付けて「未受付」を格納することで、患者のステータス状態として第１状態を登録する第１登録処理を実行する。また、ＤＢ制御部１１２は、患者の医療機関への来訪を受け付けた場合にその患者に対応付けて「診療待ち」を格納することで、患者のステータス状態として第２状態を登録する第２登録処理を実行する。また、ＤＢ制御部１１２は、医師からの患者の診療結果を受け付けた場合にその患者に対応付けて「会計待ち」を格納することで、患者のステータス状態として第３状態を登録する第３登録処理を実行する。また、ＤＢ制御部１１２は、患者による支払いを受け付けた場合にその患者に対応付けて「支払完了」を格納することで、患者のステータス状態として第４状態を登録する第４登録処理を実行する。

【0111】

<第５状態>
上記の例では、医療用予定管理システム１が、ユーザの第１端末からの対面予約を受け付けた場合、ステータス情報を第１状態として登録する第１登録処理を実行した。ここで、医療用予定管理システム１は、医療機関の第２端末からの対面予約を受け付けた場合、ステータス情報を、第１状態又は第５状態として登録する第２登録処理を実行してもよい。

【0112】

図１７は、受付向けの予約用画面の一例を示す図である。図１７に示す受付向けの予約用画面Ｃ８には、受付端末３０から予約された患者Ｋ３の予約情報Ｈ３４及びＨ３５を含む予定表Ｌ１８が表示されている。これらの予約は、例えば、初診の患者の電話による緊急予約であるため、患者の基本情報が医療用予定管理システム１に登録されていないものとする。一方、患者端末２０からの予約の場合、患者を認証するために患者情報が登録されている必要があるので、初診であっても、患者情報が既に登録されている状態になっている。

【0113】

図１７の例では、サーバ表示部１１１は、患者端末２０から予約された患者の場合、患者情報が登録されている患者であるものとして、白抜き文字の「未」という表示を第１状態として表示する。また、サーバ表示部１１１は、患者端末２０から予約された患者の場合、患者Ｋ３のように患者情報が登録されていない患者であるものとして、黒文字の「未登録」という表示を第５状態として表示する。このような態様によれば、予約された患者の患者情報の有無を区別しやすくすることができる。

【0114】

サーバ表示部１１１は、例えば第５状態の表示を選択すると、図１７に示すように、患者名の入力欄Ｅ８１と、生年月日の入力欄Ｅ８２と、住所の入力欄Ｅ８３と、連絡先の入力欄Ｅ８４と、身長／体重の入力欄Ｅ８５と、血液型の入力欄Ｅ８６と、基本情報の入力ボタンＢ１８とを表示する。患者の基本情報を入力する操作が行われると、ＤＢ制御部１１２は、入力された基本情報を患者に対応付けて患者情報データベースＤＢ２に格納し、患者の基本情報を登録する。このように、第５状態を表示するとともに患者の基本情報の入力欄を表示することで、患者情報の入力をしやすくすることができる。

【0115】

<診療メニューの関連付け>
実施形態では、医療用予定管理システム１が、第１端末から診療メニューの選択を含む予約を受け付けている。診療メニューは、予約対象の医療スタッフ又は設備の少なくとも一方と関連付けられている場合がある。例えば、治療Ｆ１に必要な機器がユニットＵ１にしか備えられていない場合、治療Ｆ１はユニットＵ１に関連付けられる。また、相談Ｇ１に必要な資格を所有するのが医師Ｄ２だけである場合、相談Ｇ１は医師Ｄ２に関連付けられる。

【0116】

この場合に、医療用予定管理システム１は、選択された診療メニューに関連付けられた医療スタッフ又は設備の予約可能枠内から予約を受け付ける処理を第１表示処理として実行してもよい。サーバ装置１０は、診療メニューと医療スタッフ又は設備とを関連付けた関連付けテーブルを記憶しておく。サーバ装置１０は、患者端末２０又は受付端末３０からの予約の際に入力された診療メニューに関連付けられた医療スタッフ又は設備がある場合、その関連付けられた医療スタッフ又は設備しか選択できないようにして、予約を受け付ける。このような態様によれば、診療に適した医療スタッフ又は設備の予約を行うことができる。

【0117】

<かかりつけ医>
なお、医療用予定管理システム１は、上記のように診療メニューに医療スタッフが関連付けられていても、ユーザ個人に関連付けられた医療スタッフがいる場合は、そのユーザ個人に関連付けられた医療スタッフの予約可能枠内から予約を受け付ける処理を第１表示処理として実行してもよい。ユーザ個人に関連付けられた医療スタッフとは、例えば、患者を担当する、かかりつけ医である。

【0118】

サーバ装置１０は、患者とかかりつけ医とを関連付けた関連付けテーブルを記憶しておき、予約された患者に関連付けられた医療スタッフがいる場合、その関連付けられた医療スタッフしか選択できないようにして、予約を受け付ける。このような態様によれば、かかりつけ医のように他の医療スタッフに比べてユーザをよく知る医療スタッフを予約することができ、より的確な診療がされることを期待することができる。

【0119】

<予約可能枠>
サーバ表示部１１１は、実施形態では、医療スタッフ及び設備の両方の予定に基づく予約可能枠から予約させる予定表Ｅ２５を表示させたが、これに限らず、医療スタッフのみの予定に基づく予約可能枠から予約させる予定表を表示させてもよい。この場合、サーバ表示部１１１は、例えば、医療スタッフを一人でも予約可能な日時を、予約可能な時間帯として白い矩形の領域で示し、医療スタッフが一人も予約できない時間帯を、予約不可の時間帯として斜線パターンの領域で示す患者向け予定表を表示させる。

【0120】

設備の利用は調整されることがあったり、予約はされているが実際には稼働していない設備があったりするため、設備の予定に基づいて予約可能枠を表示すると、予約した設備で診療ができない場合がある。特に、医療用予定管理システム１のように患者と設備を関連付けて記憶する場合、患者の診療が予約された時刻どおりに行われなかった場合に、患者の待ち時間や診療後の会計終了後も設備の予約が入っているような状態になることが起こりうる。

【0121】

また、実施形態のように医療スタッフ及び設備の両方が空いていることを条件に予約可能とすると、医療スタッフの予定が空いているのに、設備が埋まっていて、予約ができない場合がある。そこで、上記のとおり医療スタッフの予定だけに基づいて予約可能枠を表示することで、予約が埋まっているように見えても実際には設備が空いているという場合に、予約を受け付けて、その設備が活用されるようにすることができる。

【0122】

図１に示す全体構成は一例であり、これに限られない。例えば、サーバ装置１０は、２台以上の装置に分散されてもよいし、クラウドコンピューティングシステムに代替されてもよい。また、図４に示す機能構成も一例であり、これに限られない。例えば、サーバ装置１０の機能が２台以上の装置に分散して実現されてもよい。また、１つの機能が行う動作を２以上の機能が分散して行ってもよいし、２以上の機能が１つの機能に統合されてもよい。要するに、医療用予定管理システム１の全体で図４に示す各機能が実現されていれば、それらの機能を実現する装置はどのような構成であってもよい。

【0123】

上述した実施形態の態様は、サーバ装置１０のような情報処理装置を備える医療用予定管理システム１のような情報処理システムであったが、情報処理方法であってもよい。その情報処理方法は、その情報処理システムが実行する各処理のステップを備える。また、上述した実施形態の態様は、プログラムであってもよい。そのプログラムは、コンピュータに、同様の情報処理システムが実行する各処理を実行させる。

【0124】

<付記>
さらに、次に記載の各態様で提供されてもよい。

【0125】

（１）医療機関における予定表を表示するシステムを制御するコンピュータに、ユーザの第１端末から予約を受け付け、第１状態として表示する処理と、医療機関の第２端末からユーザの来訪を受け付け、第２状態として表示する処理と、医療機関の第３端末から前記ユーザの症状または処置内容を受け付け、第３状態として表示する処理と、前記医療機関の第２端末から、前記ユーザの会計情報を受け付け、第４状態として表示する処理とを実行させるプログラム。

【0126】

このような態様によれば、ユーザの状態を容易に把握することができる。

【0127】

（２）上記（１）に記載のプログラムであって、前記コンピュータに、前記医療機関の第３端末から、次回診療の時間長さ又は次回診療までの間隔の少なくとも一方を受け付け、ユーザ情報と関連付けて保存する処理を実行させる、プログラム。

【0128】

このような態様によれば、予約を入力する際の操作を簡略化することができる。

【0129】

（３）上記（１）又は（２）に記載のプログラムであって、前記コンピュータに、前記ユーザの第１端末からの予約に加え、前記医療機関の第２端末からの予約を受け付け、前記第１端末からの予約は、医療スタッフの予定に基づく予約可能枠から受け付け、前記第２端末からの予約は、前記予約可能枠にかかわらず受け付ける処理を実行させる、プログラム。

【0130】

このような態様によれば、利便性が高い予約システムを提供することができる。

【0131】

（４）上記（１）～（３）のいずれか１つに記載のプログラムであって、前記予約は、予約の日時が指定されることで行われ、前記コンピュータに、医療スタッフ及び設備のいずれか一方の予約の日時が指定された場合に、前記医療スタッフ及び前記設備の両方の予定を確保する処理を実行させる、プログラム。

【0132】

このような態様によれば、医療スタッフ及び設備のどちらからでも両方の予定を確保することができる。

【0133】

（５）上記（１）～（４）のいずれか１つに記載のプログラムであって、前記予約は、対面診療の予約とオンライン診療の予約とを含み、前記コンピュータに、前記対面診療の予約が受け付けられた場合は、当該予約を前記第１状態として表示する処理を実行させ、前記オンライン診療の予約が受け付けられた場合は、当該予約を第２状態として表示する処理を実行させる、プログラム。

【0134】

このような態様によれば、第２端末の操作を簡略化することができる。

【0135】

（６）上記（１）～（５）のいずれか１つに記載のプログラムであって、前記コンピュータに、前記ユーザの第１端末からの対面予約を受け付け、前記第１状態として登録する処理と、前記医療機関の第２端末からの対面予約を受け付け、前記第１状態又は第５状態として登録する処理と、を実行させる、プログラム。

【0136】

このような態様によれば、患者情報の有無を区別しやすくすることができる。

【0137】

（７）上記（１）～（６）のいずれか１つに記載のプログラムであって、前記コンピュータに、前記ユーザの第１端末からの予約の場合、問診情報を当該第１端末から受け付ける処理と、前記医療機関の第２端末からの予約の場合、問診情報を当該第２端末又は前記第１端末から受け付ける処理と、を実行させる、プログラム。

【0138】

このような態様によれば、問診の入力を促進することができる。

【0139】

（８）上記（１）～（７）のいずれか１つに記載のプログラムであって、前記コンピュータに、前記第１端末から診療メニューの選択を含む予約を受け付け、前記診療メニューは、予約対象の医療スタッフ又は設備の少なくとも一方と関連付けられており、選択された前記診療メニューに関連付けられた医療スタッフ又は設備の予約可能枠内から前記予約を受け付ける処理を実行させる、プログラム。

【0140】

このような態様によれば、診療に適した予約を行うことができる。

【0141】

（９）上記（８）に記載のプログラムであって、前記コンピュータに、前記診療メニューに医療スタッフが関連付けられていてもユーザ個人に関連付けられた医療スタッフがいる場合は、当該ユーザ個人に関連付けられた医療スタッフの予約可能枠内から前記予約を受け付ける処理を実行させる、プログラム。

【0142】

このような態様によれば、ユーザをよく知る医療スタッフを予約することができる。

【0143】

（１０）医療機関における予定表を表示するシステムであって、ユーザの第１端末から予約を受け付け、第１状態として表示する処理と、医療機関の第２端末からユーザの来訪を受け付け、第２状態として表示する処理を実行する処理と、医療機関の第３端末からユーザの症状または処置内容を受け付け、第３状態として表示する処理と、医療機関の第２端末から、ユーザの会計情報を受け付け、第４状態として表示する処理とを実行するシステム。

【0144】

このような態様によれば、ユーザの状態を容易に把握することができる。

【0145】

（１１）医療機関における予定表を表示するシステムを制御するコンピュータが、ユーザの第１端末から予約を受け付け、第１状態として表示する処理を実行し、前記コンピュータが、医療機関の第２端末からユーザの来訪を受け付け、第２状態として表示する処理を実行し、前記コンピュータが、医療機関の第３端末からユーザの症状または処置内容を受け付け、第３状態として表示する処理を実行し、前記コンピュータが、医療機関の第２端末から、ユーザの会計情報を受け付け、第４状態として表示する処理を実行する方法。

【0146】

このような態様によれば、ユーザの状態を容易に把握することができる。
もちろん、この限りではない。
また、上述した実施形態及び変形例を任意に組み合わせて実施するようにしてもよい。

【0147】

最後に、本発明に係る種々の実施形態を説明したが、これらは、例として提示したものであり、発明の範囲を限定することは意図していない。新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

【符号の説明】

【0148】

１ ：医療用予定管理システム
１０ ：サーバ装置
１１ ：制御部
２０ ：患者端末
２１ ：制御部
３０ ：受付端末
３１ ：制御部
４０ ：医師端末
４１ ：制御部
１１１ ：サーバ表示部
１１２ ：ＤＢ制御部
２１１ ：第１ユーザ表示部
２１２ ：第１操作受付部
３１１ ：第２ユーザ表示部
３１２ ：第２操作受付部
４１１ ：第３ユーザ表示部
４１２ ：第３操作受付部

【要約】      （修正有）

【課題】ユーザの状態を容易に把握するプログラム、システム及び方法を提供する。
【解決手段】医療用予定管理システム１において、プログラムは、医療機関における予定表を表示するシステムを制御するコンピュータであるサーバ装置１０の制御部に、ユーザの第１端末から予約を受け付け、第１状態として表示する処理と、医療機関の第２端末からユーザの来訪を受け付け、第２状態として表示する処理と、医療機関の第３端末からユーザの症状または処置内容を受け付け、第３状態として表示する処理と、医療機関の第２端末から、ユーザの会計情報を受け付け、第４状態として表示する処理と、を実行させる。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】