JP2017146914A - 情報処理装置 - Google Patents

Abstract

【課題】対面診療と同等の遠隔診療を実現する。
【解決手段】情報処理装置は、患者が使用する第１クライアント端末、及び、医師が使用する第２クライアント端末と接続可能である。情報処理装置は、患者を識別する患者識別情報と、医師を識別する医師識別情報と、ビデオ通話を用いた遠隔診療の予約に関する予約情報とを関連付けて記憶する手段と、予約情報に基づいて、第１クライアント端末と第２クライアント端末との間のビデオ通話シーケンスを開始する制御手段と、医師の指示に応じて、ビデオ通話シーケンスにおいて行った遠隔診療に関するカルテ情報を、患者識別情報と、医師識別情報とに関連付けて記憶する手段と、を備える。
【選択図】図２３

Description

本発明は、遠隔診療に用いられる情報処理装置に関する。

近年、インターネットを介して、医師から離れた場所にいる患者に対して行われる診療行為（以下「遠隔診療」という）が注目されている。遠隔診療は、医師及び患者の双方にとって、地理的制約、及び、時間的制約なしに、医師による診療を受けることができるという利点がある。

従来、医師と患者との間で、通信手段を用いた遠隔診療を支援する様々な仕組みが提案されている（特許文献１）。

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

従来の遠隔診療は、医師が患者と対面して行う対面診療を補完するものに過ぎない。例えば、従来の遠隔診療では、医師は、医療行為を行うのではなく、患者に対する助言を提供することにとどまっているものがある。この場合、医師は、患者に対して薬を処方することはなく、かつ、カルテを作成することもない。
そのため、患者は、薬を受け取るために、遠隔診療後に対面診療を受ける必要がある。

このように、従来の遠隔診療は、対面診療を代替することを想定していない。したがって、従来のシステムでは、対面診療と同等の遠隔診療を実現することはできない。

本発明の目的は、対面診療と同等の遠隔診療を実現することである。

本発明の一態様は、
患者が使用する第１クライアント端末、及び、医師が使用する第２クライアント端末と接続可能な情報処理装置であって、
前記患者を識別する患識別情報と、前記医師を識別する医師識別情報と、ビデオ通話を用いた遠隔診療の予約に関する予約情報とを関連付けて記憶する手段と、
前記予約情報に基づいて、前記第１クライアント端末と前記第２クライアント端末との間のビデオ通話シーケンスを開始する制御手段と、
前記医師の指示に応じて、前記ビデオ通話シーケンスにおいて行った遠隔診療に関するカルテ情報を、前記患者識別情報と、前記医師識別情報とに関連付けて記憶する手段と、
を備える、情報処理装置である。

本発明によれば、対面診療と同等の遠隔診療を実現することができる。

第１実施形態の情報処理システムのシステム構成図。 第１実施形態のクライアント端末の構成を示す図。 第１実施形態のサーバの構成を示す図。 第１実施形態の患者データベースのデータ構造を示す図。 第１実施形態の医師データベースのデータ構造を示す図。 第１実施形態のスケジュールデータベースのデータ構造を示す図。 第１実施形態の予約データベースのデータ構造を示す図。 第１実施形態の診療履歴データベースのデータ構造を示す図。 第１実施形態の問診票データベースのデータ構造を示す図。 第１実施形態のカルテデータベースのデータ構造を示す図。 第１実施形態の処方箋データベースのデータ構造を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の情報処理において表示される画面の例を示す図。 第１実施形態の予約の処理のシーケンス図。 第１実施形態の遠隔診療の処理のシーケンス図。 図２７のビデオ通話シーケンスの詳細なシーケンス図。

（１）第１実施形態
（１−１）情報処理システムの構成（図１）
第１実施形態の情報処理システムの構成について説明する。図１は、第１実施形態の情報処理システムのシステム構成図である。

図１に示すように、情報処理システム１は、クライアント端末１０（１０−１〜１０−ｎ）と、サーバ３０とを備える。
クライアント端末１０と、サーバ３０とは、通信網ＮＷ（例えば、インターネット）を介して、通信（例えば、ｈｔｔｐｓ通信）を行うことができる。

クライアント端末１０は、ユーザが使用する情報処理装置の一例である。クライアント端末１０は、例えば、スマートフォン、タブレット端末、パーソナルコンピュータ等である。
サーバ３０は、クライアント端末１０から送信されたリクエストに基づいて、所定の処理を実行する情報処理装置の一例である。サーバ３０は、例えば、ウェブサーバである。

（１−２）クライアント端末の構成（図２）
第１実施形態のクライアント端末の構成について説明する。図２は、第１実施形態のクライアント端末の構成を示す図である。

図２に示すように、クライアント端末１０は、ＣＰＵ（Central Processing Unit）１１と、記憶装置１１と、入力部１３と、表示部１４と、通信インタフェース１５と、カメラ１６と、サウンドモジュール１７とを備える。

記憶装置１１は、情報処理に必要なプログラム及びデータを記憶するように構成される。記憶装置１１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。
情報処理に必要なプログラムは、例えば、ＯＳ（Operating System）のプログラム、情報処理を実行するアプリケーション（例えば、ブラウザ、ビデオ通話用アプリケーション）のプログラム等である。
情報処理に必要なデータは、例えば、情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）である。

ＣＰＵ１２は、記憶装置１１に記憶されたプログラムを起動することによって、アプリケーションの機能を実現するように構成される。

入力部１３は、ユーザの指示を受け付けるように構成される。入力部１３は、例えば、キーボード、ポインティングデバイス、タッチパネル等である。

表示部１４は、ユーザに情報を提示するように構成される。表示部１４は、例えば、液晶ディスプレイである。

通信インタフェース１５は、クライアント端末１０と通信網ＮＷとの間の通信を制御するように構成される。

カメラ１６は、画像を撮像し、かつ、画像データを生成するように構成される。カメラ１６は、例えば、ＣＣＤ（Charge-Coupled Device）カメラである。

サウンドモジュール１７は、音声を入出力するモジュールである。サウンドモジュール１７は、例えば、マイク及びスピーカである。

（１−３）サーバの構成（図３）
第１実施形態のサーバの構成について説明する。図３は、第１実施形態のサーバの構成を示す図である。

図３に示すように、サーバ３０は、記憶装置３１と、ＣＰＵ３２と、入力部３３と、表示部３４と、通信インタフェース３５とを備える。

記憶装置３１は、情報処理に必要なプログラム、データ、及び、データベースを記憶する記憶装置である。記憶装置３１は、例えば、ＲＯＭ、ＲＡＭ、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。
情報処理に必要なプログラムは、例えば、ＯＳ（Operating System）のプログラム、サーバ３０の機能を実現するアプリケーションのプログラム等である。
情報処理に必要なデータは、例えば、要件情報（後述する）である。

ＣＰＵ３２は、記憶装置３１に記憶されたプログラムを起動することによって、サーバ３０の機能を実現するように構成される。

入力部３３及び表示部３４は、それぞれ、図２の入力部１３及び表示部１４と同様である。

通信インタフェース３５は、サーバ３０と通信網ＮＷとの間の通信を制御するように構成される。

（１−４）データベースのデータ構造（図４〜図８）
第１実施形態のデータベースのデータ構造について説明する。

（１−４−１）患者データベース（図４）
第１実施形態の患者データベースのデータ構造について説明する。図４は、第１実施形態の患者データベースのデータ構造を示す図である。

患者データベースのレコード（以下「患者レコード」という）には、患者に関する情報（以下「患者情報」という）が格納される。

図４に示すように、患者データベースは、「患者ＩＤ」フィールドと、「患者名」フィールドと、「生年月日」フィールドと、「性別」フィールドと、「住所」フィールドと、「支払情報」フィールドと、「保険証番号」フィールドと、「保険証画像」フィールドと、「メールアドレス」フィールドと、「パスワード」フィールドとを含む。

「患者ＩＤ」フィールドには、患者ＩＤが格納される。患者ＩＤは、患者として登録されたユーザ毎に固有の情報である。つまり、患者ＩＤは、患者を識別する情報である。患者ＩＤは、患者レコードの主キーである。患者ＩＤは、患者のログイン認証のために参照される。患者ＩＤは、サーバ３０が決定する情報である。

「患者名」フィールドには、患者の氏名を示すテキストデータが格納される。
「生年月日」フィールドには、患者の生年月日を示す値が格納される。
「性別」フィールドには、患者の性別を示すコード（以下「性別コード」という）が格納される。性別コード「Ｍ」は男性を示す。性別コード「Ｆ」は女性を示す。
「住所」フィールドには、患者の住所を示すテキストデータが格納される。
「支払情報」フィールドには、料金の支払に関する情報（例えば、クレジットカード番号、銀行口座番号等）を示す値が格納される。
「保険証番号」フィールドには、患者の保険証番号を示す値が格納される。
「保険証画像」フィールドには、患者の保険証の画像に対応する画像データが格納される。
「メールアドレス」フィールドには、患者のメールアドレスを示すテキストデータが格納される。
「患者名」フィールド、「生年月日」フィールド、「性別」フィールド、「住所」フィールド、「支払情報」フィールド、「保険証番号」フィールド、「保険証画像」フィールド、及び、「メールアドレス」フィールドの情報は、患者が任意に決定する情報である。

「パスワード」フィールドには、患者のパスワードを示すテキストデータが格納される。
「パスワード」フィールドの情報は、患者のログイン認証のために参照される。「パスワード」フィールドの情報は、患者が任意に決定する情報である。

（１−４−２）医師データベース（図５）
第１実施形態の医師データベースのデータ構造について説明する。図５は、第１実施形態の医師データベースのデータ構造を示す図である。

医師データベースのレコード（以下「医師レコード」という）には、医師に関する情報（以下「医師情報」という）が格納される。

図５に示すように、医師データベースは、「医師ＩＤ」フィールドと、「医師名」フィールドと、「性別」フィールドと、「画像」フィールドと、「所属病院」フィールドと、「診療科目」フィールドと、「疾患」フィールドと、「経歴」フィールドと、「署名画像」フィールドと、「メールアドレス」フィールドと、「パスワード」フィールドとを含む。

「医師ＩＤ」フィールドには、医師ＩＤが格納される。医師ＩＤは、医師として登録されたユーザ毎に固有の情報である。つまり、医師ＩＤは、医師を識別する情報である。医師ＩＤは、医師レコードの主キーである。医師ＩＤは、医師のログイン認証のために参照される。医師ＩＤは、サーバ３０が決定する情報である。

「医師名」フィールドには、医師の氏名を示すテキストデータが格納される。
「性別」フィールドには、医師の性別を示す性別コードが格納される。
「画像」フィールドには、医師の画像に対応する画像データが格納される。
「所属病院」フィールドには、医師が所属する病院の名称を示すテキストが格納される。
「診療科目」フィールドには、医師の診療科目を示すコードが格納される。
「メールアドレス」フィールドには、医師のメールアドレスを示すテキストデータが格納される。
「疾患」フィールドには、医師が担当可能な疾患を示すコード（以下「疾患コード」という）が格納される。
「経歴」フィールドには、医師の経歴を示すテキストデータが格納される。
「署名画像」フィールドには、医師の署名の画像に対応する画像データが格納される。
「医師名」フィールド、「性別」フィールド、「画像」フィールド、「診療科目」フィールド、「疾患」フィールドフィールド、「経歴」フィールド、「署名画像」フィールド、及び、「メールアドレス」フィールドの情報は、医師が任意に決定する情報である。

「パスワード」フィールドには、医師のパスワードを示すテキストデータが格納される。
「パスワード」フィールドの情報は、医師のログイン認証のために参照される。「パスワード」フィールドの情報は、医師が任意に決定する情報である。

（１−４−３）スケジュールデータベース（図６）
第１実施形態のスケジュールデータベースのデータ構造について説明する。図６は、第１実施形態のスケジュールデータベースのデータ構造を示す図である。

スケジュールデータベースのレコード（以下「スケジュールレコード」という）には、医師のスケジュールに関する情報（以下「スケジュール情報」という）が格納される。
１つの医師ＩＤには、複数のスケジュールレコードを関連付けることができる。

図５に示すように、スケジュールデータベースは、「スケジュールＩＤ」フィールドと、「日付」フィールドと、「開始時間」フィールドと、「終了時間」フィールドとを含む。

「スケジュールＩＤ」フィールドには、スケジュールＩＤが格納される。スケジュールＩＤは、医師のスケジュールを識別する情報である。スケジュールＩＤは、スケジュールレコードの主キーである。スケジュールＩＤは、サーバ３０が決定する情報である。

「日付」フィールドには、医師が診療可能な日付を示す値が格納される。
「開始時間」フィールド、及び、「終了時間」フィールドには、それぞれ、医師が診療可能な開始時間及び終了時間を示す値が格納される。
つまり、「日付」フィールド、「開始時間」フィールド、及び、「終了時間」フィールドの情報は、医師の診療可能枠を示している。「日付」フィールド、「開始時間」フィールド、及び、「終了時間」フィールドの情報は、医師が任意に決定する情報である。

（１−４−４）予約データベース（図７）
第１実施形態の予約データベースのデータ構造について説明する。図７は、第１実施形態の予約データベースのデータ構造を示す図である。

予約データベースのレコード（以下「予約レコード」という）には、遠隔診療の予約に関する情報（以下「予約情報」という）が格納される。
１つの患者ＩＤには、複数の予約レコードを関連付けることができる。

図７に示すように、予約データベースは、「予約ＩＤ」フィールドと、「スケジュールＩＤ」フィールドと、「疾患」フィールドと、「診療料」フィールドと、「予約ステータス」フィールドとを含む。

「予約ＩＤ」フィールドには、予約ＩＤが格納される。予約ＩＤは、予約を識別する情報である。予約ＩＤは、予約レコードの主キーである。予約ＩＤは、スケジュールＩＤに関連付けられる。予約ＩＤは、サーバ３０が決定する情報である。

「疾患」フィールドには、診療の対象となる疾患（以下「対象疾患」という）を示す疾患コードが格納される。
「疾患」フィールドの情報は、患者が任意に決定する情報である。

「診療料」フィールドには、診療料を示す値が格納される。
「予約ステータス」フィールドには、予約ステータスコードが格納される。予約ステータスコード「ＳＴＡ１」は予約が完了していないことを示す。予約ステータスコード「ＳＴＡ２」は予約が完了したことを示す。
「診療料」フィールド及び「予約ステータス」フィールドの情報は、サーバ３０が決定する情報である。

（１−４−５）診療履歴データベース（図８）
第１実施形態の診療履歴データベースのデータ構造について説明する。図８は、第１実施形態の診療履歴データベースのデータ構造を示す図である。

診療履歴データベースのレコード（以下「診療履歴レコード」という）には、遠隔診療の履歴に関する情報（以下「診療履歴情報」という）が格納される。
１つの患者ＩＤには、複数の診療履歴レコードを関連付けることができる。

図８に示すように、診療履歴データベースは、「診療履歴ＩＤ」フィールドと、「予約ＩＤ」フィールドと、「診療日時」フィールドと、「診療料」フィールドと、「薬料金」フィールドと、「決済ステータス」フィールドと、「要注意フラグ」フィールドと、「メモ」フィールドとを含む。

「診療履歴ＩＤ」フィールドには、診療履歴ＩＤが格納される。診療履歴ＩＤは、診療履歴を識別する情報である。診療履歴ＩＤは、診療履歴レコードの主キーである。診療履歴ＩＤは、サーバ３０が決定する情報である。

「予約ＩＤ」フィールドには、予約ＩＤが格納される。１つの予約ＩＤは、１つの診療履歴ＩＤに関連付けられる。

「診療日時」フィールドには、遠隔診療が行われた日時を示す値が格納される。
「診療料」フィールドには、診療料を示す値が格納される。
「薬料金」フィールドには、薬料金を示す値が格納される。
「決済ステータス」フィールドには、決済ステータスコードが格納される。決済ステータスコード「ＳＴＡ１」は、決済が完了していないことを示す。決済ステータスコード「ＳＴＡ２」は、決済が完了したことを示す。決済ステータスコード「ＳＴＡ３」は、予約日時を過ぎても遠隔診療が行われなかったことを示す。
「診療日時」フィールド、「診療料」フィールド、「薬料金」フィールド、及び、「決済ステータス」フィールドの情報は、サーバ３０が決定する情報である。

「要注意フラグ」フィールドには、患者が要注意患者であるか否かを示す値が格納される。値「０」は、患者が要注意患者ではないことを示す。値「１」は、患者が要注意患者であることを示す。要注意患者とは、医師が要注意であると判断した患者を意味する。
「メモ」フィールドには、医師のメモを示すテキストデータが格納される。
「要注意フラグ」フィールド、及び、「メモ」フィールドの情報は、医師が任意に決定する情報である。

（１−４−６）問診票データベース（図９）
第１実施形態の問診票データベースのデータ構造について説明する。図９は、第１実施形態の問診票データベースのデータ構造を示す図である。

問診票データベースのレコード（以下「問診票レコード」という）には、問診票に関する情報（以下「問診票情報」という）が格納される。
１つの患者ＩＤには、複数の問診票レコードを関連付けることができる。

図９に示すように、問診票データベースは、「問診票ＩＤ」フィールドと、「疾患」フィールドと、「質問」フィールドと、「回答」フィールドと、「既往歴」フィールドと、「アレルギー」フィールドと、「メモ」フィールドとを含む。

「問診票ＩＤ」フィールドには、問診票ＩＤが格納される。問診票ＩＤは、問指標を識別する情報である。問診票ＩＤは、問診票レコードの主キーである。問診票ＩＤは、サーバ３０が決定する情報である。

「疾患」フィールドには、問診票に対応する疾患を示す疾患コードが格納される。
「質問」フィールドには、質問を示すコード（以下「質問コード」という）が格納される。１つの疾患コードには、複数の質問コードが関連付けられる。
「疾患」フィールド、及び、「質問」フィールドの情報は、予め決められた情報である。

「回答」フィールドには、回答を示すコード（以下「回答コード」という）が格納される。１つの回答コードには、１つの質問コードが関連付けられる。
「既往歴」フィールドには、既往歴を示すコード（以下「既往歴コード」という）が格納される。１つの疾患コードには、複数の既往歴コードを関連付けることができる。
「アレルギー」フィールドには、アレルギーを示すコード（以下「アレルギーコード」という）が格納される。１つの疾患コードには、複数のアレルギーコードを関連付けることができる。
「メモ」フィールドには、患者のメモを示すテキストデータが格納される。
「回答」フィールド、「既往歴」フィールド、「アレルギー」フィールド、及び、「メモ」フィールドの情報は、患者が任意に決定する情報である。

（１−４−７）カルテデータベース（図１０）
第１実施形態のカルテデータベースのデータ構造について説明する。図１０は、第１実施形態のカルテデータベースのデータ構造を示す図である。

カルテデータベースのレコード（以下「カルテレコード」という）には、カルテに関する情報（以下「カルテ情報」という）が格納される。
１つの患者ＩＤには、複数のカルテレコードを関連付けることができる。

図１０に示すように、カルテデータベースは、「カルテＩＤ」フィールドと、「診療履歴ＩＤ」フィールドと、「診療録」フィールドと、「更新日時」フィールドとを含む。

「カルテＩＤ」フィールドには、カルテＩＤが格納される。カルテＩＤは、カルテを識別する情報である。カルテＩＤは、カルテレコードの主キーである。カルテＩＤは、サーバ３０が決定する情報である。

「診療履歴ＩＤ」フィールドには、診療履歴ＩＤが格納される。

「診療録」フィールドには、診療録を示すテキストデータが格納される。
「診療録」フィールドの情報は、医師が任意に決定する情報である。

「更新日時」フィールドには、カルテレコードが追加又は更新された日時を示す値が格納される。「更新日時」フィールドの情報は、サーバ３０が決定する情報である。

（１−４−８）処方箋データベース（図１１）
第１実施形態の処方箋データベースのデータ構造について説明する。図１１は、第１実施形態の処方箋データベースのデータ構造を示す図である。

処方箋データベースのレコード（以下「処方箋レコード」という）には、処方箋に関する情報（以下「処方箋情報」という）が格納される。
１つの患者ＩＤには、複数の処方箋レコードを関連付けることができる。

図１１に示すように、処方箋データベースは、「処方箋ＩＤ」フィールドと、「診療履歴ＩＤ」フィールドと、「処方薬」フィールドと、「種類」フィールドと、「用量」フィールドと、「用途」フィールドと、「用法」フィールドと、「数量」フィールドと、「発行フラグ」フィールドと、「処方箋ステータス」フィールドとを含む。

「処方箋ＩＤ」フィールドには、処方箋ＩＤが格納される。処方箋ＩＤは、処方箋を識別する情報である。処方箋ＩＤは、処方箋レコードの主キーである。処方箋ＩＤは、サーバ３０が決定する情報である。

「診療履歴ＩＤ」フィールドには、診療履歴ＩＤが格納される。

「処方薬」フィールドには、処方薬を示すコード（以下「処方薬コード」という）が格納される。１つの処方箋ＩＤには、複数の処方薬コードを関連付けることができる。
「種類」フィールドには、処方薬の種類を示すコード（以下「種類コード」という）が格納される。１つの種類コードは、１つの処方薬コードに関連付けられる。
「用量」フィールドには、１回当たりの服薬量を示す値が格納される。
「用途」フィールドには、処方薬の用途を示すコード（以下「用途コード」という）が格納される。１つの用途コードは、１つの処方薬コードに関連付けられる。
「用法」フィールドには、処方薬の用法を示すコード（以下「用法コード」という）が格納される。１つの用法コードは、１つの処方薬コードに関連付けられる。
「数量」フィールドには、処方薬の数量を示す値が格納される。１つの値は、１つの処方薬コードに関連付けられる。
「処方薬」フィールド、「用法」フィールド、及び、「数量」フィールドの情報は、医師が任意に決定する情報である。

「発行フラグ」フィールドには、処方箋を発行したか否かを示す値が格納される。フラグ「０」は、処方箋を発行していないことを示している。この場合、処方箋を発行することができる。フラグ「１」は、処方箋を発行したことを示している。この場合、処方箋を発行することはできない。

「処方箋ステータス」フィールドには、処方箋ステータスコードが格納される。例えば、処方箋ステータスコード「ＳＴＡ１」は、処方が完了していないことを示す。処方箋ステータスコード「ＳＴＡ２」は、処方は完了したが、発送が完了していないことを示す。処方箋ステータスコード「ＳＴＡ３」は、処方及び発送が完了したことを示す。
「処方箋ステータス」フィールドの情報は、サーバ３０が決定する情報である。

（１−５）情報処理において表示される画面（図１２〜図２５）
第１実施形態の情報処理において表示される画面について説明する。図１２〜図２５は、第１実施形態の情報処理において表示される画面の例を示す図である。
図１２〜図２５の画面は、クライアント端末１０の表示部１４に表示される。各画面では、ユーザは、入力部１３を用いて指示（入力フィールドへの入力、及び、ボタンの指定）を与えることができる。ユーザにより与えられた指示は、クライアント端末１０からサーバ３０に送信される。

図１２の画面Ｐ１００は、医師（医師ＩＤ「ＤＲ００１」）がログインした場合に最初に表示される医師用トップ画面である。
画面Ｐ１００は、ボタンＢ１００ａ〜Ｂ１００ｂを含む。

「診療可能枠」ボタンＢ１００ａは、診療可能枠画面Ｐ１１０を表示させるためのボタンである。
「予約状況」ボタンＢ１００ｂは、予約状況画面Ｐ１２０（図１３）を表示させるためのボタンである。

「診療可能枠」ボタンＢ１００ａが指定されると、画面Ｐ１１０が表示される。
画面Ｐ１１０は、表示領域Ａ１１０と、ボタンＢ１１０ａ〜Ｂ１１０ｃと、入力フィールドＦ１１０とを含む。

表示領域Ａ１１０には、診療可能枠の日付が表示される。

入力フィールドＦ１１０は、表示領域Ａ１１０に表示された日付において、診療可能な時間帯を入力するための入力フィールドである。入力フィールドＦ１１０は、時間帯毎のチェックボックスを含んでいる。

ボタンＢ１１０ａは、診療可能枠の日付を切り替えるためのボタンである。
ボタンＢ１１０ｂは、入力フィールドＦ１１０に表示される時間帯を切り替えるためのボタンである。

画面Ｐ１１０において入力フィールドＦ１１０に情報が入力され（例えば、チェックボックスが指定され）、かつ、「保存」ボタンＢ１１０ｃが指定されると、クライアント端末１０は、サーバ３０に、診療可能枠の登録を要求するためのリクエストを送信する。
サーバ３０は、クライアント端末１０からリクエストを受信すると、入力フィールドＦ１１０に入力された情報に基づいて、スケジュールデータベース（図６）を更新する。

図１２の「予約状況」ボタンＢ１００ｂが指定されると、図１３の画面Ｐ１２０が表示される。
画面Ｐ１２０は、表示領域Ａ１２０と、ボタンＢ１２０ａ〜Ｂ１２０ｂとを含む。

表示領域Ａ１２０には、医師（医師ＩＤ「ＤＲ００１」）が受けた遠隔診療の予約日時が表示される。

「参考情報」ボタンＢ１２０ａは、参考情報画面Ｐ１２１を表示させるためのボタンである。「参考情報」ボタンＢ１２０ａは、予約ＩＤに関連付けられている。
「診療室」ボタンＢ１２０ｂは、医師用診療画面Ｐ１３０（図２３）を表示させるためのボタンである。「診療室」ボタンＢ１２０ｂは、予約ＩＤに関連付けられている。「診療室」ボタンＢ１２０ｂは、予約日時になる前は表示されておらず、予約日時になったときに表示される。

「参考情報」ボタンＢ１２０ａが指定されると、画面Ｐ１２１が表示される。
画面Ｐ１２１は、ボタンＢ１２１ａ〜Ｂ１２１ｃを含む。

「患者情報」ボタンＢ１２１ａは、患者情報（例えば、患者データベース（図４）の情報）、及び、問診票情報（例えば、問診票データベース（図９）の情報）を表示させるためのボタンである。
「カルテ」ボタンＢ１２１ｂは、カルテ情報（例えば、カルテデータベース（図１０）の情報）を表示させるためのボタンである。
「処方箋」ボタンＢ１２１ｃは、処方箋情報（例えば、処方箋データベース（図１１）の情報）を表示させるためのボタンである。

図１４の画面Ｐ２００は、患者（患者ＩＤ「ＰＡ００１」）がログインした場合に最初に表示される患者用トップ画面である。
画面Ｐ２００は、ボタンＢ２００ａ〜Ｂ２００ｂを含む。

「診療予約」ボタンＢ２００ａは、診療予約画面Ｐ２１０を表示させるためのボタンである。
「マイページ」ボタンＢ２００ｂは、図１７のマイページ画面Ｐ２２０を表示させるためのボタンである。

「診療予約」ボタンＢ２００ａが指定されると、画面Ｐ２１０が表示される。
画面Ｐ２１０は、表示領域Ａ２１０ａ〜Ａ２１０ｃと、ボタンＢ２１０と、画像ＩＭＧ２１０ａ〜ＩＭＧ２１０ｄとを含む。

表示領域Ａ２１０ａには、画像ＩＭＧ２１０ａと、医師情報（例えば、医師名、診療科目、及び、担当可能疾患）が表示される。
画像ＩＭＧ２１０ａは、医師ＩＤに関連付けられている。画像ＩＭＧ２１０ａは、図１５の画面Ｐ２１１を表示させるためのボタンである。
表示領域Ａ２１０ａの情報は、医師データベース（図５）に格納された情報である。

表示領域Ａ２１０ｂには、診療予約の対象となる日付及び時間帯が表示される。
ボタンＢ２１０は、表示領域Ａ２１０ｂに表示された日付を切り替えるためのボタンである。

表示領域Ａ２１０ｃには、表示領域Ａ２１０ｂに表示された時間帯毎に、画像ＩＭＧ２１０ｂ〜ＩＭＧ２３１０ｄが表示される。
画像ＩＭＧ２１０ｂは、予約可能な診療可能枠（以下「予約枠」という）が所定数未満である（例えば、１である）ことを示している。
画像ＩＭＧ２１０ｃは、予約枠が所定数（例えば、２）以上であることを示している。
画像ＩＭＧ２１０ｄは、予約枠が０であることを示している。
画像ＩＭＧ２１０ｂ〜２１０ｃは、医師ＩＤに関連付けられている。画像ＩＭＧ２１０ｂ〜２１０ｃは、図１５の画面Ｐ２１１を表示させるためのボタンである。

画面Ｐ２１０において、画像ＩＭＧ２１０ａ〜ＩＭＧ２１０ｃの何れかが指定されると、図１５の画面Ｐ２１１が表示される。
画面Ｐ２１１は、表示領域Ａ２１１ａ〜Ａ２１１ｃと、ボタンＢ２１１ａ〜Ｂ２１１ｃと、画像ＩＭＧ２１１ａ〜ＩＭＧ２１１ｂとを含む。

表示領域Ａ２１１ａには、画像ＩＭＧ２１１ａと、医師（医師ＩＤ「ＤＲ００１」）の医師情報（例えば、医師名、診療科目、担当可能疾患、及び、経歴）が表示される。表示領域Ａ２１０ａの情報は、医師データベース（図５）に格納された情報である。

表示領域Ａ２１１ｂには、診療予約の対象となる日付が表示される。
ボタンＢ２１１ａは、表示領域Ａ２１１ｂに表示された日付を切り替えるためのボタンである。

表示領域Ａ２１１ｃには、診療予約の対象となる時間帯が表示される。
ボタンＢ２１１ｂは、表示領域Ａ２１１ｃに表示された時間帯を切り替えるためのボタンである。

画像ＩＭＧ２１１ｂは、予約枠が０であることを示している。
「予約」ボタンＢ２１１ｃは、予約枠が１以上であることを示している。「予約」ボタンＢ２１１ｃは、予約リクエスト（後述）を行うためのボタンである。「予約」ボタンＢ２１１ｃは、スケジュールＩＤに関連付けられている。

「予約」ボタンＢ２１１ｃが指定されると、図１６の画面Ｐ２１２が表示される。
画面Ｐ２１２は、ボタンＢ２１２ａ〜Ｂ２１２ｂを含む。

「花粉症」ボタンＢ２１２ａは、対象疾患として、花粉症を選択するためのボタンである。
「尿酸値」ボタンＢ２１２ｂは、対象疾患として、尿酸値を選択するためのボタンである。
ボタンＢ２１２ａ〜Ｂ２１２ｂは、疾患コードに関連付けられている。

「花粉症」ボタンＢ２１２ａが指定されると、画面Ｐ２１３が表示される。
画面Ｐ２１３は、表示領域Ａ２１３と、ボタンＢ２１３とを含む。

表示領域Ａ２１３には、予約情報（例えば、予約日時、医師名、対象疾患、患者名、請求金額、及び、支払方法）が表示される。
表示領域Ａ２１３の情報は、患者データベース（図４）及び医師データベース（図５）に格納された情報、並びに、サーバ３０によって生成された情報である。
「予約確定」ボタンＢ２１３は、予約確定リクエスト（後述）を行うためのボタンである。

「予約確定」ボタンＢ２１３が指定されると、クライアント端末１０は、サーバ３０に、予約確定リクエストを送信する。

画面Ｐ２００の「マイページ」ボタンＢ２００ｂが指定されると、図１７の画面Ｐ２２０が表示される。
画面Ｐ２２０は、ボタンＢ２２０ａ〜Ｂ２２０ｃを含む。

「登録情報」ボタンＢ２２０ａは、画面Ｐ２２１を表示させるためのボタンである。
「診療予約状況」ボタンＢ２２０ｂは、図１９の画面Ｐ２３０を表示させるためのボタンである。
「診療履歴」ボタンＢ２２０ｃは、図２０の画面Ｐ２４０を表示させるためのボタンである。

「登録情報」ボタンＢ２２０ａが指定されると、画面Ｐ２２１が表示される。
画面Ｐ２２１は、ボタンＢ２２１ａ〜Ｂ２２１ｂと、入力フィールドＦ２２１とを含む。

「編集」ボタンＢ２２１ａは、入力フィールドＦ２２１を編集するためのボタンである。
「問診票登録」ボタンＢ２２１ｂは、図１８の画面Ｐ２２２を表示させるためのボタンである。

入力フィールドＦ２２１には、患者（患者ＩＤ「ＰＡ００１」）の患者情報（例えば、メールアドレス、パスワード、患者名、生年月日、性別、住所、電話番号、保険証番号、保険証画像、及び、お知らせメールの受取の有無）が表示される。
「編集」ボタンＢ２２１ａが指定されると、入力フィールドＦ２２１が編集可能になる。

「問診票登録」ボタンＢ２２１ｂが指定されると、図１８の画面Ｐ２２２が表示される。
画面Ｐ２２２は、ボタンＢ２２２ａ〜Ｂ２２２ｂを含む。ボタンＢ２２２ａ〜Ｂ２２２ｂは、疾患コードに関連付けられている。

「花粉症」ボタンＢ２２２ａは、花粉症用の問診票登録画面Ｐ２２３を表示させるためのボタンである。
「尿酸値」ボタンＢ２２２ｂは、尿酸値用の問診票登録画面を表示させるためのボタンである。

「花粉症」ボタンＢ２２２ａが指定されると、画面Ｐ２２３が表示される。
画面Ｐ２２３は、ボタンＢ２２３と、入力フィールドＦ２２３ａ〜Ｆ２２３ｃとを含む。

入力フィールドＦ２２３ａ〜Ｆ２２３ｃは、疾患コード「Ｄ１」に関連付けられた質問に対する回答を入力するための入力フィールドである。入力フィールドＦ２２３ａ〜Ｆ２２３ｃは、チェックボックスを含んでいる。

入力フィールドＦ２２３ａ〜Ｆ２２３ｃに情報が入力され（例えば、チェックボックスが指定され）、かつ、「完了」ボタンＢ２２３が指定されると、クライアント端末１０は、サーバ３０に、問診票の登録を要求するためのリクエストを送信する。
サーバ３０は、このリクエストを受信すると、入力フィールドＦ２２３ａ〜Ｆ２２３ｃに入力された情報に基づいて、問診票データベース（図９）を更新する。

図１７の「診療予約状況」ボタンＢ２２０ｂが指定されると、図１９の画面Ｐ２３０が表示される。
画面Ｐ２３０は、表示領域Ａ２３０と、ボタンＢ２３０ａ〜Ｂ２３０ｂと、画像ＩＭＧ２３０とを含む。

表示領域Ａ２３０には、患者（患者ＩＤ「ＰＡ００１」）が予約した遠隔診療を担当する医師（以下「担当医師」という）の医師情報（例えば、医師名）と、予約情報（例えば、予約日時）と、当該医師の画像ＩＭＧ２３０とが表示される。
表示領域Ａ２３０の情報は、医師データベース（図５）及び予約データベース（図７）に格納された情報である。

「診療室」ボタンＢ２３０ａは、患者用診療画面Ｐ２５０（図２４）を表示させるためのボタンである。「診療室」ボタンＢ２３０ａは、予約ＩＤに関連付けられている。「診療室」ボタンＢ２３０ａは、予約日時になる前は表示されておらず、予約日時になったときに表示される。
「キャンセル」ボタンＢ２３０ｂは、予約をキャンセルするためのボタンである。「キャンセル」ボタンＢ２３０ｂは、予約ＩＤに関連付けられている。

「診療室」ボタンＢ２３０ａが指定されると、図２４の画面Ｐ２５０が表示される。

「キャンセル」ボタンＢ２３０ｂが指定されると、クライアント端末１０は、サーバ３０に、予約のキャンセルを要求するためのリクエストを送信する。
サーバ３０は、このリクエストを受信すると、予約データベース（図７）から、指定された「キャンセル」ボタンＢ２３０ｂに関連付けられた予約ＩＤを含む予約レコードを削除する。

図１７の「診療履歴」ボタンＢ２２０ｃが指定されると、図２０の画面Ｐ２４０が表示される。
画面Ｐ２４０は、表示領域２４０ａ〜Ａ２４０ｂと、ボタンＢ２４０ａ〜Ｂ２４０ｃと、画像ＩＭＧ２４０とを含む。

表示領域Ａ２４０ａには、担当医師の画像ＩＭＧ２４０と、担当医師の医師名と、対象疾患とが表示される。
表示領域Ａ２４０ｂには、過去の遠隔診療の診療日時が表示される。

「再診予約」ボタンＢ２４０ａは、再診予約を行うためのボタンである。「再診予約」ボタンＢ２４０ａは、表示領域Ａ２４０ａに表示された医師名に対応する医師ＩＤに関連付けられている。
「カルテ」ボタンＢ２４０ｂは、カルテ画面Ｐ２４１（図２１）を表示させるためのボタンである。「カルテ」ボタンＢ２４０ｂは、カルテＩＤに関連付けられている。
「処方箋」ボタンＢ２４０ｃは、処方箋画面Ｐ２４２（図２２）を表示させるためのボタンである。「処方箋」ボタンＢ２４０ｃは、処方箋ＩＤに関連付けられている。

「再診予約」ボタンＢ２４０ａが指定されると、図１５の画面Ｐ２１１が表示される。

「カルテ」ボタンＢ２４０ｂが指定されると、図２１の画面Ｐ２４１が表示される。
画面Ｐ２４１は、表示領域Ａ２４１と、ボタンＢ２４１とを含む。

表示領域Ａ２４１には、遠隔診療に関する情報（例えば、遠隔診療の診療日時、担当医師の医師名、及び、診療録）が表示される。
表示領域Ａ２４１の情報は、診療履歴データベース（図８）及びカルテデータベース（図１０）に格納された情報である。

「紹介状発行」ボタンＢ２４１は、紹介状を発行するためのボタンである。「紹介状発行」ボタンＢ２４１は、診療履歴ＩＤに関連付けられている。

「紹介状発行」ボタンＢ２４１が指定されると、クライアント端末１０は、サーバ３０に、紹介状の発行を要求するためのリクエストを送信する。
サーバ３０は、このリクエストを受信すると、医師のメールアドレス（例えば、図５の「メールアドレス」フィールドの情報）宛に、紹介状の発行が要求されたことを通知するメールを送信する。医師が承認（例えば、メールに埋め込まれた「承認」ボタンを指定）すると、サーバ３０は、紹介状のファイル（例えば、医師名と、所属病院名とが記載され、かつ、医師の署名の画像が埋め込まれたＰＤＦファイル）を作成する。次に、サーバ３０は、クライアント端末１０に、紹介状のファイルをダウンロードするためのＵＲＬ（Uniform Resource Locator）を送信する。
クライアント端末１０は、このＵＲＬにアクセスすると、紹介状のファイルをダウンロードする。
患者は、ダウンロードされたファイルを印刷することによって、通院することなく、紹介状を入手することができる。

図２０の「処方箋」ボタンＢ２４０ｃが指定されると、図２２の画面Ｐ２４２が表示される。
画面Ｐ２４２は、表示領域Ａ２４２と、ボタンＢ２４２とを含む。

表示領域Ａ２４２には、診療に関する情報（例えば、処方箋に対応する遠隔診療の診療日時、及び、担当医師の医師名）と、処方箋情報とが表示される。
表示領域Ａ２４２の情報は、医師データベース（図５）、診療履歴データベース（図８）、及び、処方箋データベース（図１１）に格納された情報である。

「処方箋発行」ボタンＢ２４２は、処方箋を発行するためのボタンである。「処方箋発行」ボタンＢ２４２は、処方箋ＩＤに関連付けられている。

「処方箋発行」ボタンＢ２４２が指定されると、クライアント端末１０は、サーバ３０に、処方箋の発行を要求するためのリクエストを送信する。
サーバ３０は、このリクエストを受信すると、医師のメールアドレス（例えば、図５の「メールアドレス」フィールドの情報）宛に、処方箋の発行が要求されたことを通知するメールを送信する。医師が承認（例えば、メールに埋め込まれた「承認」ボタンを指定）すると、サーバ３０は、処方箋のファイル（例えば、医師の署名画像が埋め込まれたＰＤＦファイル）を作成する。次に、サーバ３０は、クライアント端末１０に、処方箋のファイルをダウンロードするためのＵＲＬを送信する。
クライアント端末１０は、このＵＲＬにアクセスすると、処方箋のファイルをダウンロードする。
患者は、ダウンロードされたファイルを印刷することによって、通院することなく、処方箋を入手することができる。

図１３の「診療室」ボタンＢ１２０ｂが指定されると、図２３の画面Ｐ１３０が表示される。
画面Ｐ１３０は、動画ＭＯＶ１３０ａ〜ＭＯＶ１３０ｂと、表示領域Ａ１３０ａ〜Ａ１３０ｂと、ボタンＢ１３０ａ〜Ｂ１３０ｉと、入力フィールドＦ１３０ａ〜Ｆ１３０ｅとを含む。

動画ＭＯＶ１３０ａは、担当医師の動画（つまり、担当医師が使用するクライアント端末１０のカメラ１６によって撮像された画像）である。動画ＭＯＶ１３０ａは、画面Ｐ２５０（図２４）の動画ＭＯＶ２５０ａと同期している。
動画ＭＯＶ１３０ｂは、患者の動画（つまり、患者が使用するクライアント端末１０のカメラ１６によって撮像された画像）である。動画ＭＯＶ１３０ｂは、画面Ｐ２５０の動画ＭＯＶ２５０ｂと同期している。

表示領域Ａ１３０ａには、患者の基本情報（例えば、患者名、生年月日、及び、性別）が表示される。表示領域Ａ１３０ａの情報は、患者データベース（図４）に格納された情報である。
表示領域Ａ１３０ｂには、患者の薬歴（例えば、処方薬、数量、及び、処方された日付）が表示される。表示領域Ａ１３０ｂの情報は、処方箋データベース（図１１）に格納された情報である。

入力フィールドＦ１３０ａは、テキストチャットを入力するための入力フィールドである。入力フィールドＦ１３０ａは、画面Ｐ２５０（図２４）の入力フィールドＦ２５０と同期している。
「添付」ボタンＢ１３０ａは、画像ファイルを添付するためのボタンである。

入力フィールドＦ１３０ｂは、医師が任意にテキストを入力するための入力フィールドである。
「要注意」ボタンＢ１３０ｈは、患者を要注意患者として取り扱う（例えば、診療履歴データベース（図８）の「要注意フラグ」フィールドにフラグ「１」を格納する）ためのボタンである。

入力フィールドＦ１３０ｃは、患者の医療情報を編集するための入力フィールドである。入力フィールド１３０ｃには、問診票データベース（図９）に格納された問診票情報が予め表示される。
「編集」ボタンＢ１３０ｂは、入力フィールドＦ１３０ｃに表示された問診票情報を編集するためのボタンである。「編集」ボタンＢ１３０ｂが指定されると、入力フィールドＦ１３０ｃが編集可能になる。入力フィールドＦ１３０ｃが編集されると、サーバ３０は、編集後の入力フィールドＦ１３０ｃの情報に基づいて、問診票データベースを更新する。

入力フィールドＦ１３０ｄは、診療録を入力するための入力フィールドである。
「保存」ボタンＢ１３０ｃは、診療録を保存するためのボタンである。
「テンプレート」ボタンＢ１３０ｉは、診療録のテンプレートを選択するためのボタンである。
医師が「テンプレート」ボタンＢ１３０ｉを指定すると、予め用意されたテンプレート（例えば、疾患毎のテンプレート）のリストが表示される。医師がリストの中から所望のテンプレートを選択すると、当該テンプレートが入力フィールドＦ１３０ｄに表示される。
医師が、入力フィールドＦ１３０ｄに診療録を入力し、かつ、「保存」ボタンＢ１３０ｃを指定すると、サーバ３０は、入力フィールドＦ１３０ｄに入力された情報に基づいて、カルテデータベース（図１０）を更新する。

入力フィールドＦ１３０ｅは、処方箋情報（例えば、処方薬の名称、種類、用量、用途、用法、及び、処方の数量）を入力するための入力フィールドである。
「あり」ボタンＢ１３０ｄは、処方薬がある場合に指定するボタンである。「あり」ボタンＢ１３０ｄが指定された場合、入力フィールドＦ１３０ｅが編集可能になる。
「なし」ボタンＢ１３０ｅは、処方薬がない場合に指定するボタンである。「なし」ボタンＢ１３０ｅが指定された場合、入力フィールドＦ１３０ｅを入力せずに診療を終了させることができる。

「診療終了」ボタンＢ１３０ｆは、入力フィールドＦ１３０ｅに入力された処方箋情報を確定するためのボタンである。「診療終了」ボタンＢ１３０ｆが指定されると、図２５に示すように、患者用画面Ｐ２５１の表示領域Ａ２５１に、入力フィールドＦ１３０ｅに入力された処方箋情報が表示される。
「あり」ボタンＢ１３０ｄが指定され、かつ、入力フィールドＦ１３０ｅに少なくとも１つの処方薬に関する情報が入力された場合、又は、「なし」ボタンＢ１３０ｅが指定された場合に、「診療終了」ボタンＢ１３０ｆが指定可能になる。

「強制終了」ボタンＢ１３０ｇは、遠隔診療を強制的に終了させるためのボタンである。

図１９の「診療室」ボタンＢ２３０ａが指定されると、図２４の画面Ｐ２５０が表示される。
画面Ｐ２５０は、動画ＭＯＶ２５０ａ〜ＭＯＶ２５０ｂと、表示領域Ａ２５０と、入力フィールドＦ２５０とを含む。

動画ＭＯＶ２５０ａは、担当医師の動画（つまり、担当医師が使用するクライアント端末１０のカメラ１６によって撮像された画像）である。動画ＭＯＶ２５０ａは、図２３の動画ＭＯＶ１３０ａと同期している。
動画ＭＯＶ２５０ｂは、患者の動画（つまり、患者が使用するクライアント端末１０のカメラ１６によって撮像された画像）である。動画ＭＯＶ２５０ｂは、図２３の動画ＭＯＶ１３０ｂと同期している。

表示領域Ａ２５０には、担当医師の医師情報（例えば、医師名、診療科目、及び、性別）が表示される。表示領域Ａ２５０の情報は、医師データベース（図５）に格納された情報である。

入力フィールドＦ２５０は、テキストチャットを入力するための入力フィールドである。入力フィールドＦ２５０は、画面Ｐ１３０（図２３）の入力フィールドＦ１３０ａと同期している。
「添付」ボタンＢ２５０ａは、画像ファイルを添付するためのボタンである。

「強制終了」ボタンＢ２５０ｂは、遠隔診療を強制的に終了させるためのボタンである。

図２３の入力フィールドＦ１３０ｅに処方箋情報が入力され、かつ、「診療終了」ボタンＢ１３０ｆが指定されると、図２５の画面Ｐ２５１が表示される。
画面Ｐ２５１は、表示領域Ａ２５１と、ボタンＢ２５１ａ〜Ｂ２５１ｂとを含んでいる点において、画面Ｐ２５０（図２４）と相違する。

表示領域Ａ２５１には、図２３の入力フィールドＦ１３０ｅに入力された処方箋情報が表示される。

「ＹＥＳ」ボタンＢ２５１ａは、表示領域Ａ２５１に表示された処方箋情報に同意する（つまり、医師の処方薬を希望する意思を表明する）ためのボタンである。
「ＮＯ」ボタンＢ２５１ｂは、表示領域Ａ２５１に表示された処方箋情報に同意しない（つまり、医師の処方薬の変更を希望する意思を表明する）ためのボタンである。

「ＮＯ」ボタンＢ２５１ｂが指定されると、図２３の入力フィールドＦ１３０ｅの情報がクリアされる。この場合、医師が、改めて、入力フィールドＦ１３０ｅに処方箋情報を入力し、かつ、「診療終了」ボタンＢ１３０ｆを指定すると、表示領域Ａ２５１の処方箋情報が更新される。

「ＹＥＳ」ボタンＢ２５１ａが指定されると、画面Ｐ２５２が表示される。
画面Ｐ２５２は、表示領域Ａ２５２ａ〜Ａ２５２ｂと、ボタンＢ２５２ａ〜Ｂ２５２ｂとを含む。

表示領域Ａ２５２ａには、会計に関する情報（例えば、診療料、薬料金、処方薬の送料、及び、合計金額）が表示される。表示領域Ａ２５２ａの情報は、サーバ３０によって作成された情報である。
表示領域Ａ２５２ｂには、処方箋情報（例えば、処方薬、及び、数量）が表示される。表示領域Ａ２５２ｂの情報は、入力フィールドＦ１３０ｅに入力された処方箋情報である。

「ＯＫ」ボタンＢ２５２ａは、表示領域Ａ２５２ａ〜Ａ２５２ｂに表示された情報に同意するときに指定するボタンである。
「戻る」ボタンＢ２５２ｂは、表示領域Ａ２５２ａ〜Ａ２５２ｂに表示された情報に同意しないときに指定するボタンである。

「ＯＫ」ボタンＢ２５２ａが指定されると、クライアント端末１０は、サーバ３０に、診療終了リクエスト（後述）を送信する。
「戻る」ボタンＢ２５２ｂが指定されると、図２３の入力フィールドＦ１３０ｅの情報がクリアされる。この場合、医師が、改めて、入力フィールドＦ１３０ｅに処方箋情報を入力し、かつ、「診療終了」ボタンＢ１３０ｆを指定すると、表示領域Ａ２５１の処方箋情報が更新される。

（１−６）情報処理のフロー（図２６〜図２８）
第１実施形態の情報処理のフローについて説明する。以下の情報処理は、図２のＣＰＵ１２が記憶装置１１に記憶されたアプリケーションのプログラムを実行し、かつ、図３のＣＰＵ３２が記憶装置３１に記憶されたプログラムを実行することによって、実現される。
クライアント端末１０とサーバ３０とは、通信網ＮＷを介して、ｈｔｔｐｓ通信を行うことによって以下の情報処理を実現する。

（１−６−１）予約の処理のフロー（図２６）
本実施形態の予約の処理について説明する。図２６は、第１実施形態の予約の処理のシーケンス図である。

図２６のクライアント端末１０のユーザは、患者（患者ＩＤ「ＰＡ００１」）である。

クライアント端末１０は、患者用トップ画面の表示（Ｓ１００）を実行する。
具体的には、患者が、入力部１３を用いて、患者としてのログインに必要な情報（例えば、患者ＩＤ及びパスワード）を入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、患者ＩＤ「ＰＡ００１」及びパスワードを含む。
ＣＰＵ３２は、ログインリクエストに含まれる患者ＩＤ「ＰＡ００１」及びパスワードと、患者データベース（図４）の「患者ＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれる患者ＩＤ「ＰＡ００１」及びパスワードと、患者データベースの「患者ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれる患者ＩＤ「ＰＡ００１」及びパスワードと、患者データベースの「患者ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。
ログインが許可されると、ＣＰＵ３２は、ログインリクエストに含まれる患者ＩＤ「ＰＡ００１」に対応する患者用トップ画面を表示させるためのレスポンスをクライアント端末１０に送信する。
ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ２００（図１４）を表示部１４に表示する。

クライアント端末１０は、診療予約画面の表示（Ｓ１０１）を実行する。
具体的には、患者が、入力部１３を用いて、画面Ｐ２００（図１４）の「診療予約」ボタンＢ２００ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ２１０を表示部１４に表示する。

クライアント端末１０は、医師スケジュール画面の表示（Ｓ１０２）を実行する。
具体的には、患者が、入力部１３を用いて、画面Ｐ２１０（図１４）の画像ＩＭＧ２１０ａ〜ＩＭＧ２１０ｃの何れかを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、画像ＩＭＧ２１０ａ〜ＩＭＧ２１０ｃに関連付けられた医師ＩＤ「ＤＲ００１」を含む。
ＣＰＵ３２は、リクエストに含まれる医師ＩＤ「ＤＲ００１」に関連付けられたスケジュールデータベース（図６）を参照して、画面Ｐ２１１（図１５）を表示するためのレスポンスをクライアント端末１０に送信する。
ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ２１１を表示部１４に表示する。

クライアント端末１０は、疾患選択画面の表示（Ｓ１０３）を実行する。
具体的には、患者が、入力部１３を用いて、画面Ｐ２１１（図１５）の「予約」ボタンＢ２１１ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ２１２（図１６）を表示部１４に表示する。

クライアント端末１０は、予約リクエスト（Ｓ１０４）を実行する。
具体的には、患者が、入力部１３を用いて、画面Ｐ２１２（図１６）の「花粉症」ボタンＢ２１２ａを指定すると、ＣＰＵ１２は、予約リクエストをサーバ３０に送信する。予約リクエストは、ログインリクエストに含まれる患者ＩＤ「ＰＡ００１」と、「予約」ボタンＢ２１１ｃ（図１５）に関連付けられたスケジュールＩＤ「ＳＣ００１」と、「花粉症」ボタンＢ２１２ａに関連付けられた疾患コード「Ｄ１」とを含む。

サーバ３０は、診療料の計算（Ｓ３００）を実行する。
具体的には、ＣＰＵ３２は、予約された遠隔診療の所要時間（以下「予約時間」という）に基づいて、診療料を計算する。
ＣＰＵ３２は、計算結果をクライアント端末１０に送信する。

クライアント端末１０は、診療予約確認画面の表示（Ｓ１０５）を実行する。
具体的には、ＣＰＵ１２は、Ｓ３００においてサーバ３０から送信された計算結果に基づいて、画面Ｐ２１３（図１５）を表示部１４に表示する。

クライアント端末１０は、予約確定リクエスト（Ｓ１０６）を実行する。
具体的には、患者が、入力部１３を用いて、画面Ｐ２１３（図１６）の「予約確定」ボタンＢ２１３を指定すると、ＣＰＵ１２は、予約確定リクエストをサーバ３０に送信する。予約確定リクエストは、予約リクエストに含まれる患者ＩＤ「ＰＡ００１」、スケジュールＩＤ「ＳＣ００１」、及び、疾患コード「Ｄ１」を含む。

サーバ３０は、仮売上の処理（Ｓ３０１）を実行する。
具体的には、ＣＰＵ３２は、患者データベース（図４）において、予約確定リクエストに含まれる患者ＩＤ「ＰＡ００１」を含む患者レコードを特定する。
ＣＰＵ３２は、特定した患者レコードの支払情報に基づいて、仮売上リクエストの送信先となる金融機関又はクレジットカード会社のサーバ（以下「決済サーバ」という）を特定する。
ＣＰＵ３２は、決済サーバに、仮売上の与信枠の承認を要求するための仮売上リクエストを送信する。仮売上リクエストは、Ｓ３００の計算結果と、支払情報とを含む。

サーバ３０は、データベースの更新（Ｓ３０２）を実行する。
具体的には、ＣＰＵ３２は、予約データベース（図７）に新規の予約レコードを追加する。新規の予約レコードの「予約ＩＤ」フィールドには、新規の予約ＩＤ「ＢＯ００１」が格納される。新規の予約レコードの「スケジュールＩＤ」フィールドには、予約確定リクエストに含まれるスケジュールＩＤ「ＳＣ００１」が格納される。新規の予約レコードの「疾患」フィールドには、予約確定リクエストに含まれる疾患コード「Ｄ１」が格納される。新規の予約レコードの「診療料」フィールドには、Ｓ３００の計算結果を示す値が格納される。新規の予約レコードの「予約ステータス」フィールドには、予約ステータスコード「ＳＴＡ２」が格納される。

以上の処理により、予約の処理が終了する。

（１−６−２）遠隔診療の処理のフロー（図２７〜図２８）
本実施形態の遠隔診療の処理について説明する。図２７は、第１実施形態の遠隔診療の処理のシーケンス図である。図２８は、図２７のビデオ通話シーケンスの詳細なシーケンス図である。

図２７のクライアント端末１０−１のユーザは、患者（患者ＩＤ「ＰＡ００１」）である。クライアント端末１０−２のユーザは、医師（医師ＩＤ「ＤＲ００１」）である。

クライアント端末１０−１は、図２６と同様に、患者用トップ画面の表示（Ｓ１００）を実行する。

クライアント端末１０−１は、患者用診療画面の表示（Ｓ１１０）を実行する。
具体的には、患者が、入力部１３を用いて、画面Ｐ２００（図１４）の「マイページ」ボタンＢ２００ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ２２０（図１７）を表示部１４に表示する。
患者が、入力部１３を用いて、画面Ｐ２２０の「診療予約状況」ボタンＢ２２０ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ２３０（図１９）を表示部１４に表示する。
患者が、入力部１３を用いて、画面Ｐ２３０の「診療室」ボタンＢ２３０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ２５０（図２４）を表示部１４に表示する。

クライアント端末１０−２は、医師用トップ画面の表示（Ｓ２１０）を実行する。
具体的には、医師が、入力部１３を用いて、医師としてのログインに必要な情報（例えば、医師ＩＤ「ＤＲ００１」及びパスワード）を入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、医師ＩＤ「ＤＲ００１」及びパスワードを含む。
ＣＰＵ３２は、ログインリクエストに含まれる医師ＩＤ「ＤＲ００１」及びパスワードと、医師データベース（図５）の「医師ＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれる医師ＩＤ「ＤＲ００１」及びパスワードと、医師データベースの「医師ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれる医師ＩＤ「ＤＲ００１」及びパスワードと、医師データベースの「医師ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。
ログインが許可されると、ＣＰＵ３２は、ログインリクエストに含まれる医師ＩＤ「ＤＲ００１」に対応する医師用トップ画面を表示させるためのレスポンスをクライアント端末１０に送信する。
ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ１００（図１２）を表示部１４に表示する。

クライアント端末１０−２は、医師用診療画面の表示（Ｓ２１１）を実行する。
具体的には、医師が、入力部１３を用いて、画面Ｐ１００（図１２）の「予約状況」ボタンＢ１００ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ１２０（図１３）を表示部１４に表示する。
医師が、入力部１３を用いて、画面Ｐ１２０の「診療室」ボタンＢ１２０ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ１３０（図２３）を表示部１４に表示する。

サーバ３０は、Ｓ１１０及びＳ２１１が終了すると（つまり、患者及び医師の双方が診療室に入ると）、ビデオ通話シーケンス（ＳＱ１）を開始する。

サーバ３０は、遠隔診療データの同期（ＳＱ１０）を実行する。遠隔診療データとは、ビデオ通話シーケンスＳＱ１においてクライアント端末１０−１〜１０−２の間で送受信されるデータである。遠隔診療データは、テキストデータと、画像データと、ビデオデータ（動画データ、及び、音声データ）とを含む。
具体的には、クライアント端末１０−１及び１０−２は、サーバ３０を介して、テキストデータ（例えば、入力フィールドＦ１３０ａ（図１３）及びＦ２５０（図２４）に入力されたテキストに対応するテキストデータ）と、画像データ（例えば、「添付」ボタンＢ１３０ａ（図１３）又はＢ２５０ａが指定されたときに添付された画像データ）と、各クライアント端末１０のカメラ１６によって撮像された動画像に対応する動画データと、各クライアント端末１０のサウンドモジュール１７によって取得された音声に対応する音声データとを送受信する。
各クライアント端末１０の表示部１４には、送受信されたデータに応じた画面Ｐ１３０（図１３）及びＰ２５０（図２５）が表示される。
これにより、患者及び医師は、テキストチャット、画像ファイル、及び、ビデオ通話を通じて、遠隔診療を行うことができる。

クライアント端末１０−２は、カルテ情報の作成（ＳＱ１２０）を実行する。
具体的には、医師が、入力部１３を用いて、画面Ｐ１３０（図２３）の入力フィールドＦ１３０ｄに診療録を入力し、かつ、「保存」ボタンＢ１３０ｃを指定すると、ＣＰＵ１２は、カルテデータベース（図１０）の更新を要求するためのリクエストをサーバ３０に送信する。このリクエストは、入力フィールドＦ１３０ｄに入力された情報と、Ｓ１００のログインリクエストに含まれる患者ＩＤと、Ｓ２１０のログインリクエストに含まれる医師ＩＤとを含む。

サーバ３０は、データベースの更新（ＳＱ１３０）を実行する。
具体的には、ＣＰＵ３２は、カルテデータベース（図１０）に新規のカルテレコードを追加する。新規のカルテレコードの「カルテＩＤ」フィールドには、新規のカルテＩＤ「ＣＬ００１」が格納される。新規のカルテレコードの「診療履歴ＩＤ」フィールドには、新規の診療履歴ＩＤ「ＨＩ００１」が格納される。新規のカルテレコードの「診療録」フィールドには、ＳＱ１２０においてクライアント端末１０から送信されたリクエストに含まれる情報（つまり、入力フィールドＦ１３０ｄ（図２３）に入力された情報）が格納される。「更新日時」フィールドには、データベースの更新（ＳＱ１３０）の実行日時を示す値が格納される。

クライアント端末１０−２は、処方箋情報の作成（ＳＱ１２１）を実行する。
具体的には、医師が、入力部１３を用いて、画面Ｐ１３０（図２３）の入力フィールドＦ１３０ｅに処方箋情報（例えば、処方薬の名称、種類、用量、用途、用法、及び、処方の数量）を入力し、かつ、「診療終了」ボタンＢ１３０ｆを指定すると、クライアント端末１０−２のＣＰＵ１２は、サーバ３０を介して、入力フィールドＦ１３０ｅに入力された処方箋情報をクライアント端末１０−１に送信する。
なお、処方箋情報の作成（ＳＱ１２１）は必須ではない。例えば、「なし」ボタンＢ１３０ｅが指定された場合、処方箋情報の作成（ＳＱ１２１）は省略可能である。

クライアント端末１０−１は、処方箋情報の表示（ＳＱ１１０）を実行する。
具体的には、ＣＰＵ１２は、ＳＱ１２１においてクライアント端末１０−２から送信された処方箋情報に基づいて、画面Ｐ２５１（図２５）を表示部１４に表示する。表示領域Ａ２５１には、クライアント端末１０−２から送信された処方箋情報が表示される。
なお、処方箋情報の表示（ＳＱ１１０）は必須ではない。例えば、「なし」ボタンＢ１３０ｅが指定された場合、処方箋情報の表示（ＳＱ１１０）は省略可能である。

クライアント端末１０−１は、会計リクエスト（ＳＱ１１１）を実行する。
具体的には、患者が、入力部１３を用いて、「ＹＥＳ」ボタンＢ２５１ａを指定すると、ＣＰＵ１２は、会計リクエストをサーバ３０に送信する。

サーバ３０は、請求金額の計算（ＳＱ１３１）を実行する。
具体的には、ＣＰＵ３２は、所定のマッチングテーブルを参照して、ＳＱ１２１においてクライアント端末１０−２から送信された処方箋情報に基づく薬料金を計算する。このマッチングテーブルには、薬剤名毎の薬価を示す値が格納されている。
ＣＰＵ３２は、予約データベース（図７）において、Ｓ１１０において指定された「診療室」ボタンＢ２３０ａ、又は、Ｓ２１０において指定された「診療室」ボタンＢ１２０ｂに関連付けられた予約ＩＤ「ＢＯ００１」を含む予約レコードを特定する。
ＣＰＵ３２は、特定した予約レコードの「診療料」フィールドの値（つまり、診療料）を特定する。
ＣＰＵ３２は、計算した薬料金と、特定した診療料と、所定の送料との合計を計算する。この合計が、請求金額である。
ＣＰＵ３２は、計算結果（つまり、請求金額）をクライアント端末１０−１に送信する。

クライアント端末１０−１は、請求金額の表示（ＳＱ１１２）を実行する。
具体的には、ＣＰＵ１２は、ＳＱ１３１においてサーバ３０から送信された情報に基づいて、画面Ｐ２５２（図２５）を表示部１４に表示する。

クライアント端末１０−１は、診療終了リクエスト（ＳＱ１１３）を実行する。
具体的には、患者が、画面Ｐ２５２（図２５）の「ＯＫ」ボタンＢ２５２ａを指定すると、ＣＰＵ１２は、診療終了リクエストをサーバ３０に送信する。

サーバ３０は、データベースの更新（ＳＱ１３２）を実行する。
具体的には、ＣＰＵ３２は、予約データベース（図７）から、ＳＱ１３１において特定した予約レコード（予約ＩＤ「ＢＯ００１」）を削除する。
ＣＰＵ３２は、診療履歴データベース（図８）に新規の診療履歴レコードを追加する。新規の診療履歴レコードの「診療履歴ＩＤ」フィールドには、ＳＱ１３０において追加されたカルテレコード（カルテＩＤ「ＣＬ００１」）の「診療履歴ＩＤ」フィールドに格納された診療履歴ＩＤ「ＨＩ００１」が格納される。これにより、新規の診療履歴レコードと、新規のカルテレコードとが関連付けられる。新規の診療履歴レコードの「予約ＩＤ」フィールドには、ＳＱ１３１において特定された予約ＩＤ「ＢＯ００１」が格納される。新規の診療履歴レコードの「診療料」フィールド及び「薬料金」フィールドには、それぞれ、ＳＱ１３１の計算結果（診療料及び薬料金を示す値）が格納される。新規の診療履歴レコードの「決済ステータス」フィールドには、初期値として、決済ステータスコード「ＳＴＡ１」が格納される。新規の診療履歴レコードの「メモ」フィールドには、入力フィールドＦ１３０ｂ（図２３）に入力された情報が格納される。新規の診療履歴レコードの「要注意フラグ」フィールドには、「要注意」ボタンＢ１３０ｈ（図２３）が指定されたか否かに応じた値が格納される。
ＣＰＵ３２は、医師によって「編集」ボタンＢ１３０ｂ（図２３）が指定されていた場合、問診票データベース（図９）の「既往歴」フィールド、「アレルギー」フィールド、及び、「メモ」フィールドの情報を、入力フィールドＦ１３０ｃ（図２３）に入力された情報に基づいて更新する。
ＣＰＵ３２は、処方箋データベース（図１１）に新規の処方箋レコードを追加する。新規の処方箋レコードの「処方箋ＩＤ」フィールドには、新規の処方箋ＩＤ「ＰＲ００１」が格納される。新規の処方箋レコードの「診療履歴ＩＤ」フィールドには、ＳＱ１３０において追加されたカルテレコード（カルテＩＤ「ＣＬ００１」）の「診療履歴ＩＤ」フィールドに格納された診療履歴ＩＤ「ＨＩ００１」が格納される。これにより、新規の診療履歴レコードと、新規の処方箋レコードとが関連付けられる。新規の処方箋レコードの「処方薬」フィールド、「用法」フィールド、及び、「数量」フィールドには、入力フィールドＦ１３０ｅに入力された情報が格納される。「発行フラグ」フィールドには、初期値として、フラグ「０」が格納される。「処方箋ステータス」フィールドには、初期値として、処方箋ステータスコード「ＳＴＡ１」が格納される。

以上の処理により、ビデオ通話シーケンス（ＳＱ１）が終了する。

図２７に示すように、ビデオ通話シーケンス（ＳＱ１）が終了すると、サーバ３０は、決済の処理（Ｓ３１０）を実行する。
具体的には、ＣＰＵ３２は、患者データベース（図４）において、Ｓ１００のログインリクエストに含まれる患者ＩＤ「ＰＡ００１」に関連付けられた支払情報を特定する。
ＣＰＵ３２は、特定した支払情報に基づいて、決済リクエストの送信先となる決済サーバを特定する。
ＣＰＵ３２は、特定した決済サーバに、決済リクエストを送信する。

決済サーバによる決済が完了すると、サーバ３０は、処方箋情報の送信（Ｓ３１１）を実行する。
具体的には、ＣＰＵ３２は、決済サーバから決済が完了したことを示す通知を受信すると、患者データベース（図４）を参照して、Ｓ１００のログインリクエストに含まれる患者ＩＤ「ＰＡ００１」に関連付けられた患者名及び住所を特定する。
ＣＰＵ３２は、図２８のＳＱ１３２において、処方箋データベース（図１１）に追加した新規の処方箋レコードの処方箋情報と、特定した患者名及び住所とを、例えば、薬局に設けられた端末（例えば、コンピュータ、又は、プリンタ）に送信する。
薬局のオペレータ（例えば、薬剤師）は、サーバ３０から送信された処方箋情報に従って、処方薬を調剤する。次に、薬局のオペレータは、サーバ３０から送信された患者名及び住所宛に処方薬を発送する。これにより、患者は、薬局に行かずに処方薬を受け取ることができる。
薬局のオペレータが所定の指示（例えば、処方薬の発送が完了したことをサーバ３０に通知するためのボタンの指定）を行うと、薬局に設けられた端末は、サーバ３０に、データベースの更新を要求するためのリクエストを送信する。

サーバ３０は、データベースの更新（Ｓ３１２）を実行する。
具体的には、ＣＰＵ３２は、薬局に設けられた端末から送信されたリクエストを受信すると、診療履歴データベース（図８）において、ＳＱ１３２において追加した新規の診療履歴レコードの「決済ステータス」フィールドに決済ステータスコード「ＳＴＡ２」を格納する。
ＣＰＵ３２は、処方箋データベース（図１１）において、ＳＱ１３２において追加した新規の処方箋レコードの「処方箋ステータス」フィールドに処方箋ステータスコード「ＳＴＡ３」を格納し、かつ、「発行フラグ」フィールドにフラグ「１」を格納する。

以上の処理により、遠隔診療の処理が終了する。

（１−７）小括
本実施形態について小括する。

本実施形態のサーバ３０（情報処理装置の一例）は、患者が使用するクライアント端末１０−１（第１クライアント端末の一例）、及び、医師が使用するクライアント端末１０−２（第２クライアント端末の一例）と接続可能である。
サーバ３０は、患者を識別する患者ＩＤ（患者識別情報の一例）と、医師を識別する医師ＩＤ（医師識別情報の一例）と、ビデオ通話を用いた遠隔診療の予約に関する予約情報とを関連付けて記憶する手段（例えば、Ｓ３０２の処理）と、
予約情報に基づいて、クライアント端末１０−１とクライアント端末１０−２との間のビデオ通話シーケンスを開始する制御手段（例えば、ＳＱ１の処理）と、
医師の指示に応じて、ビデオ通話シーケンスにおいて行った遠隔診療の診療録を含むカルテ情報を、患者ＩＤと、医師ＩＤとに関連付けて記憶する手段（例えば、ＳＱ１３０の処理）と、
を備える。

これにより、対面診療と同等の遠隔診療を実現することができる。

サーバ３０は、ビデオ通話シーケンスにおいて、患者によって入力されたテキストデータ、及び、医師によって入力されたテキストデータを、クライアント端末１０−１〜１０−２に表示させる（例えば、ＳＱ１０の処理）。

これにより、遠隔診療における患者と医師のコミュニケーションを円滑化することができる。

サーバ３０は、患者の指示に応じて、患者の疾患に関する問診票情報を、患者ＩＤに関連付けて記憶する手段を備え（例えば、図９）、制御手段は、ビデオ通話シーケンスにおいて、問診票情報を、第２クライアント端末に表示させる（例えば、入力フィールド１３０ｃ）。

これにより、遠隔診療において、医師の診断を補助することができる。

サーバ３０は、ビデオ通話シーケンスにおいて、医師の指示に応じて、処方箋に関する処方箋情報をクライアント端末１０−１に表示させ（例えば、ＳＱ１１０の処理）、処方箋情報が表示された後の患者の指示に応じて、処方箋情報を、患者ＩＤと、医師ＩＤとに関連付けて記憶する手段（例えば、ＳＱ１３２の処理）をさらに備える。

これにより、患者は、医師が作成した処方箋の内容を確認した上で、遠隔診療を終了することができる。

サーバ３０は、処方箋情報を、薬局のオペレータが使用する端末（第３クライアント端末の一例）に送信する手段（例えば、Ｓ３１１の処理）をさらに備える。
また、サーバ３０は、患者の氏名及び住所を含む患者情報を患者ＩＤに関連付けて記憶する手段（例えば、図４）と、医師の氏名を含む医師情報を医師ＩＤに関連付けて記憶する手段（例えば、図５）と、をさらに備え、制御手段は、患者ＩＤに関連付けられた患者情報と、医師ＩＤに関連付けられた医師情報と、処方箋情報とを、薬局のオペレータが使用する端末に送信する。

これにより、医師が薬局に指示をすることなく、処方薬を患者に届けることができる。

サーバ３０は、ビデオ通話シーケンスにおいて、クライアント端末１０−１〜１０−２の間で送受信された遠隔診療データ（テキストデータ、画像データ、又は、ビデオデータの少なくとも１つの一例）を、患者ＩＤと、医師ＩＤとに関連付けて記憶する手段をさらに備えてもよい。

これにより、過去の遠隔診療の内容を、患者、及び、医師に提供することができる。

本実施形態において、「遠隔診療」とは、自由診療、及び、保険診療の何れも含む。「診療」とは、治療行為、診断行為、又は、それらの組合せである。
「処方薬」とは、一般用医薬品、及び、医療用医薬品の何れも含む。医療用医薬品は、新薬、ジェネリック医薬品、又は、それらの組合せである。

（１−８）第１実施形態の変形例
第１実施形態の変形例について説明する。

サーバ３０は、問診票情報に加えて、ビデオ通話シーケンスの前、又は、ビデオ通話シーケンス中に患者が使用するクライアント端末１０−１によって取得された身体情報を、医師が使用するクライアント端末１０−２に提供してもよい。
身体情報は、例えば、次の情報である。
・クライアント端末１０−１のカメラ１６によって撮像された身体の画像（一例としては、皮膚の画像、喉の画像、目の画像等）に対応する画像データ
・クライアント端末１０−１のセンサ（図示せず）によって取得されたバイタルデータ（一例としては、脈拍数、心拍数、体温、歩数、睡眠時間、摂取した食品等を示すデータ）
・クライアント端末１０−１に接続されたウェアラブルデバイスによって取得されたバイタルデータ
・サーバ３０とは異なるサーバによって管理された情報（例えば、カルテ情報、処方箋情報等）

サーバ３０は、医師ＩＤ毎に、カルテ情報へのアクセス可否を管理してもよい。
具体的には、サーバ３０は、患者（患者ＩＤ「ＰＡ００１」）と医師（医師ＩＤ「ＤＲ００１」）とが以下の条件を満たす場合に、当該患者のカルテ情報に対する当該医師のアクセスを許可する（一例として、当該医師が使用するクライアント端末１０−２の表示部１４に、図１３の画面Ｐ１２１の「カルテ」ボタン１２１ｂを表示する）。
・担当医師（医師ＩＤ「ＤＲ００１」）が患者（患者ＩＤ「ＰＡ００１」）の遠隔診療を行ったことがある（例えば、医師ＩＤ「ＤＲ００１」に関連付けられた診療履歴データベース（図８）の「予約ＩＤ」フィールドに、患者ＩＤ「ＰＡ００１」に関連付けられた予約ＩＤが含まれている）場合
・患者（患者ＩＤ「ＰＡ００１」）が、担当医師（医師ＩＤ「ＤＲ００１」）による遠隔診療を予約している（例えば、患者ＩＤ「ＰＡ００１」に関連付けられた予約データベース（図７）に、医師ＩＤ「ＤＲ００１」に関連付けられたスケジュールＩＤが含まれている）場合
・担当医師（医師ＩＤ「ＤＲ００１」）が、患者（患者ＩＤ「ＰＡ００１」）の遠隔診療を行ったことがある医師（つまり、過去の遠隔診療の担当医師）と同じ病院に所属している（例えば、過去の遠隔診療の担当医師が所属する病院の名称を示すテキストデータが、医師ＩＤ「ＤＲ００１」に関連付けられた医師データベース（図５）の「所属病院」フィールドに格納されている）場合

サーバ３０は、医師ＩＤ毎に、カルテ情報へのアクセス範囲を管理してもよい。
例えば、医師（医師ＩＤ「ＤＲ００１」）が患者（患者ＩＤ「ＰＡ００１」）の遠隔診療を行ったことがある場合、サーバ３０は、当該医師に対して、全てのカルテ情報へのアクセスを許可する。
例えば、患者（患者ＩＤ「ＰＡ００１」）が、医師（医師ＩＤ「ＤＲ００１」）による遠隔診療を予約している場合、サーバ３０は、当該医師に対して、所定期間内（例えば、過去半年）のカルテ情報へのアクセスを許可する。

上述の実施形態では、１名の患者と１名の医師とが遠隔診療に参加する例を示した。しかし、遠隔診療に参加する患者の数、及び、医師の数は、これに限られるものではない。

例えば、１名の患者に対して、複数の意思が遠隔診療に参加してもよい。この場合、以下の何れかが考えられる。
・予約の処理（図２６）において、複数の医師を指定する（具体的には、予約ＩＤを複数の医師ＩＤに関連付ける）。
・遠隔診療の処理（図２７）を開始する前に、予約を受けた医師（例えば、予約ＩＤに関連付けられた医師ＩＤによって識別される医師）が、他の医師に対して、遠隔診療に参加する権限を付与する（例えば、他の医師を識別する医師ＩＤに予約ＩＤを関連付ける）。
・ビデオ通話シーケンス（図２８）の実行中に、遠隔診療を行っている医師が、他の医師を、ビデオ通話に参加させる（具体的には、サーバ３０は、他の医師が使用するクライアント端末１０−３と、クライアント端末１０−１〜１０−２とを接続する）。この場合、各クライアント端末１０−１〜１０−３の表示部１４に表示される画面Ｐ１３０（図２３）及びＰ２５０（図２４）には、それぞれ、動画ＭＯＶ１３０ａ及びＭＯＶ２５０ａが複数個表示される。

上述の実施形態では、予約日時になると「診療室」ボタンＢ１２０ｂ（図１３）及びＢ２３０ａ（図１９）が表示される例について示した。しかし、本実施形態は、これに限られるものではない。
例えば、予約日時に所定時間前（例えば５分前）に「診療室」ボタンＢ１２０ｂ及びＢ２３０ａを表示してもよい。
また、予約日時前に患者が「診療室」ボタンＢ２３０ａを指定し、かつ、予約日時迄に医師が「診療室」ボタンＢ１２０ｂを指定しなかった場合、サーバ３０は、医師が使用するクライアント端末１０−２を呼び出してもよい。
また、予約日時前に医師が「診療室」ボタンＢ１２０ｂを指定し、かつ、予約日時迄に患者が「診療室」ボタンＢ２３０ａを指定しなかった場合、サーバ３０は、患者が使用するクライアント端末１０−１を呼び出してもよい。

上述の実施形態では、図２６の診療料の計算（Ｓ３００）において、予約時間に基づいて診療料を計算する例を示した。しかし、本実施形態の診療料の計算方法はこれに限られるものではない。例えば、サーバ３０は、次の方法で診療料を計算してもよい。
・医師毎に定められた金額を診療料とする。
・疾患毎に定められた金額を診療料とする。
・予約時間、医師、又は、疾患のうちの少なくとも２つの組合せに基づいて診療料を計算する。

上述の実施形態では、図２８の請求金額の計算（ＳＱ１３１）において、予約の処理（図２６）において計算された診療料を請求金額に含める例を示した。しかし、本実施形態の請求金額の計算方法はこれに限られるものではない。例えば、サーバ３０は、実際の遠隔診療の所要時間（例えば、ビデオ通話シーケンス（図２８）の処理の所要時間）に基づいて診療料を計算してもよい。

終了時間（例えば、予約ＩＤに関連付けられたスケジュールＩＤに関連する終了時間）を過ぎてもビデオ通話シーケンス（図２８）が終了しなかった場合、サーバ３０は、次の処理を実行してもよい。
・請求金額の計算（ＳＱ１３１）において、超過料金を請求金額に含める。
・ビデオ通話シーケンスにおいて、患者が使用するクライアント端末１０−１、又は、医師が使用するクライアント端末１０−２の少なくとも１つの表示部１４に警告画面（例えば、終了時間を経過していることを警告するメッセージを含む画面）を表示する。
・上記の組合せ。

サーバ３０は、患者データベース（図４）において、個人を特定する情報（例えば、マイナンバ）を格納してもよい。この場合、マイナンバは、患者ＩＤ、又は、保険証番号の少なくとも１つを代替することができる。

サーバ３０は、患者ＩＤ、又は、医師ＩＤの少なくとも一方を、他のサービスで使用されている情報と関連付けてもよい。他のサービスで使用されている情報とは、例えば、次のものが挙げられる。
・メールアドレス
・携帯電話番号
・ＳＮＳ（Social Networking Service）のユーザＩＤ
・ＳＮＳ以外のウェブサービス（例えば、学術論文を提供するウェブサイト、医療専門のポータルサイト、医療関係者用のプラットフォームサイト等）のユーザＩＤ
・マイナンバ

サーバ３０は、図２８のデータベースの更新（ＳＱ１３２）において、さらに、次の情報の少なくとも１つを、患者ＩＤ及び医師ＩＤに関連付けて記憶してもよい。
・入力フィールドＦ１３０ａ（図２３）及びＦ２５０（図２４）に入力された情報に対応するテキストデータ
・「添付」ボタンＢ１３０ａ（図２３）又はＦ２５０ａ（図２４）が指定されたときに添付された画像ファイル
・各クライアント端末１０−１〜１０−２の間で送受信されたビデオデータ（具体的には、カメラ１６によって撮像された画像に対応する画像データ、又は、サウンドモジュール１７によって取得された音声に対応する音声データの少なくとも１つ）

サーバ３０は、画面Ｐ１３０（図２３）に、診療の終了時間、又は、次の予約の開始時間の少なくとも１つを表示してもよい。

サーバ３０は、所定条件を満たす場合、医師の指示に応じて、図２８のデータベースの更新（ＳＱ１３０）において追加されたカルテレコードのカルテ情報を更新してもよい。
具体的には、ＣＰＵ３２は、データベースの更新（ＳＱ１３０）においてカルテレコード（医師ＩＤ「ＤＲ００１」と関連付けられたカルテレコード）の「更新日時」フィールドの値が示す時刻から所定時間（例えば、２４時間）以内に、医師（医師ＩＤ「ＤＲ０１」）が、入力部１３を用いて、所定の「更新」ボタン（不図示）を指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、入力フィールドＦ１３０ｃ（図２３）を表示部１４に表示する。この入力フィールドＦ１３０ｃには、カルテレコードの「診療録」フィールドの情報が表示されている。
医師（医師ＩＤ「ＤＲ０１」）が、入力部１３を用いて、入力フィールドＦ１３０ｃに新しい情報を入力し、かつ、「保存」ボタンＢ１３０ｃを指定すると、ＣＰＵ１２は、カルテ情報の更新のリクエストをサーバ３０に送信する。このリクエストは、入力フィールドＦ１３０ｃに入力された情報を含む。
ＣＰＵ３２は、クライアント端末１０−２から送信されたリクエストに含まれる情報を用いて、カルテレコードの「診療録」フィールドの情報を上書きする。ＣＰＵ３２は、クライアント端末１０−２から送信されたリクエストを受信した日時を示す値を用いて、カルテレコードの「更新日時」フィールドの値を上書きする。
これにより、所定条件を満たす場合に限り、医師の指示に基づいてカルテ情報が更新される。

上述の実施形態では、図２８に示すように、ビデオ通話シーケンス（ＳＱ１）においてカルテ情報の作成（ＳＱ１２０）を実行する例について説明した。しかし、カルテ情報の作成（ＳＱ１２０）は、ビデオ通話シーケンス（ＳＱ１）が終了した後に実行してもよい。

サーバ３０は、予約の開始時間（例えば、予約データベース（図７）の「スケジュールＩＤ」フィールドに関連付けられたスケジュールレコード（図６）の「開始時間」フィールドの値が示す時刻）の所定時間（例えば、５分）前になった場合、患者又は医師の少なくとも一方に、リマインダを通知してもよい。
具体的には、ＣＰＵ３２は、該当する予約レコードに関連付けられた患者ＩＤによって識別される患者、又は、該当する予約レコードに関連付けられた医師ＩＤによって識別される医師に対して、リマインダを通知する。通知の方法は、以下の少なくとも１つである。
・「メールアドレス」フィールド（図４又は図５）のメールアドレス宛にリマインダメッセージ（例えば、「５分後に診療開始です」というメッセージ）を送信する。
・患者が使用するクライアント端末１０−１又は医師が使用するクライアント端末１０−２に表示する画面（例えば、Ｐ２００（図１４）又はＰ１００（図１２））にリマインダメッセージ（例えば、「５分後に診療開始です」というメッセージ）を含める。
・患者が使用するクライアント端末１０−１の画面を、患者用診療画面Ｐ２５０（図２４）に遷移させる。
・医師が使用するクライアント端末１０−２に表示された医師用診療画面Ｐ１３０（図２３）（つまり、該当する予約の前の予約に対応する遠隔診療の実施中）にリマインダメッセージ（例えば、「次の診療開始まで残り５分です」というメッセージ）を含める。
・患者又は医師が使用する携帯電話をコールする。患者又は医師がコールに応答したら、リマインダメッセージ（例えば、「次の診療開始まで残り５分です」という自動音声）を再生する。
・患者が使用するクライアント端末１０−１又は医師が使用するクライアント端末１０−２のアプリケーションを起動させ、患者用診療画面Ｐ２５０又は医師用診療画面Ｐ１３０を表示させる。

（２）その他の変形例
上述の実施形態では、クライアント端末１０にインストールされたウェブブラウザと、サーバ３０とがｈｔｔｐｓ通信を行うことによって情報処理が実現される例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、クライアント端末１０にインストールされた専用アプリケーション（ブラウザ以外のアプリケーション）と、サーバ３０とがｈｔｔｐｓ通信を行うことによっても実現可能である。
また、本実施形態の情報処理は、専用アプリケーションのみによって実現されてもよい。この場合、クライアント端末１０とサーバ３０との間の通信は不要である。

上述の実施形態では、サーバ３０に設けられた記憶装置３１にデータベースを記憶する例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、サーバ３０の外部に設けられた記憶装置にデータベースを記憶する（つまり、ＣＰＵ３２は、通信インタフェース３５を介してデータベースにアクセスする）場合にも適用可能である。

以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態及び変形例は、組合せ可能である。

１ ：情報処理システム
１０ ：クライアント端末
１１ ：記憶装置
１２ ：ＣＰＵ
１３ ：入力部
１４ ：表示部
１５ ：通信インタフェース
１６ ：カメラ
１７ ：サウンドモジュール
３０ ：サーバ
３１ ：記憶装置
３２ ：ＣＰＵ
３３ ：入力部
３４ ：表示部
３５ ：通信インタフェース

Claims (7)

1. 患者が使用する第１クライアント端末、及び、医師が使用する第２クライアント端末と接続可能な情報処理装置であって、
   前記患者を識別する患者識別情報と、前記医師を識別する医師識別情報と、ビデオ通話を用いた遠隔診療の予約に関する予約情報とを関連付けて記憶する手段と、
   前記予約情報に基づいて、前記第１クライアント端末と前記第２クライアント端末との間のビデオ通話シーケンスを開始する制御手段と、
   前記医師の指示に応じて、前記ビデオ通話シーケンスにおいて行った遠隔診療の診療録を含むカルテ情報を、前記患者識別情報と、前記医師識別情報とに関連付けて記憶する手段と、
   を備える、情報処理装置。
2. 前記制御手段は、前記ビデオ通話シーケンスにおいて、前記患者によって入力されたテキストデータ、及び、前記医師によって入力されたテキストデータを、前記第１クライアント端末及び前記第２クライアント端末に表示させる、
   請求項１に記載の情報処理装置。
3. 前記患者の指示に応じて、前記患者の疾患に関する問診票情報を、前記患者識別情報に関連付けて記憶する手段を備え、
   前記制御手段は、前記ビデオ通話シーケンスにおいて、前記問診票情報を、前記第２クライアント端末に表示させる、
   請求項１又は２に記載の情報処理装置。
4. 前記制御手段は、前記ビデオ通話シーケンスにおいて、前記医師の指示に応じて、処方箋に関する処方箋情報を前記第１クライアント端末に表示させ、
   前記処方箋情報が表示された後の前記患者の指示に応じて、前記処方箋情報を、前記患者識別情報と、前記医師識別情報とに関連付けて記憶する手段をさらに備える、
   請求項１〜３の何れかに記載の情報処理装置。
5. 前記処方箋情報を、薬局のオペレータが使用する第３クライアント端末に送信する手段をさらに備える、
   請求項４に記載の情報処理装置。
6. 前記患者の氏名及び住所を含む患者情報を前記患者識別情報に関連付けて記憶する手段と、
   前記医師の氏名を含む医師情報を前記医師識別情報に関連付けて記憶する手段と、をさらに備え、
   前記制御手段は、前記患者識別情報に関連付けられた患者情報と、前記医師識別情報に関連付けられた医師情報と、前記処方箋情報とを、前記第３クライアント端末に送信する、
   請求項５に記載の情報処理装置。
7. 前記ビデオ通話シーケンスにおいて、前記第１クライアント端末と前記第２クライアント端末との間で送受信されたテキストデータ、画像データ、又は、ビデオデータの少なくとも１つを、前記患者識別情報と、前記医師識別情報とに関連付けて記憶する手段をさらに備える、
   請求項１〜６の何れかに記載の情報処理装置。

Images