JP6402342B1 - 投薬日数決定支援システム、投薬日数決定支援方法及び投薬日数決定支援プログラム - Google Patents

Abstract

【課題】残薬の増加を抑制しながら投薬日数の決定を簡素化できる投薬日数決定支援システムを提供する。
【解決手段】投薬日数決定支援システムは、患者に対して投薬を行う際に投薬日数の決定を支援する投薬日数決定支援システムであって、患者の前回の診療日に処方された薬剤の前回投薬日数と前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数とに基づいて、患者が今回の診療日又は薬剤受領予定日に有すると推定される推定残薬日数を算出する残薬日数推定部と、算出された推定残薬日数と今回の診療日又は薬剤受領予定日から次回診療予定日までの日数とに応じて今回の投薬日数を算出する投薬日数算出部を備える。
【選択図】図１

Description

本発明は、医師が治療上投薬の必要があるとして処方箋を交付する際に投薬日数の決定支援を行う投薬日数決定支援システム、投薬日数決定支援方法及び投薬日数決定支援プログラムに関する。

電子カルテに記載する内容を自動生成する情報処理装置が提案されている（例えば、特許文献１）。当該情報処理装置は、電子カルテを作成する際に前回処方した投薬量と次回の診察日までの期間とから処方量を調整する構成を有している。

特許文献１の技術では、例えば、前回の処方量が１週間分であり、今回の診察日から予約日時候補データの診察予約日まで２週間ある場合、入力候補作成部は、前回の処方量の２倍分を今回の処方量として、入力候補データを作成する。また、例えば、前回の処方量が１週間分であり、今回の診察日から予約日時候補データの診察予約日までの期間が５日間である場合、入力候補作成部は、前回の処方量の５／７倍分を今回の処方量として、入力候補データを作成する（特許文献１の段落［００８６］）。

特開２０１３−２２８９９４号公報

しかしながら、例えば、調剤薬局が遠方にある等何らかの事情で、患者が処方薬を入手するまでに日数がかったりすると、患者の服用期間が診察予約日までの期間とずれてしまい残薬が生じるおそれがある。また、治療に必要な薬剤を決定する医師が残薬を勘案して処方する際、投薬日数の決定が面倒となってしまう問題もある。

本発明は、以上の従来技術の問題点に鑑みなされたものであり、残薬の増加を抑制しながら投薬日数の決定を簡素化できる投薬日数決定支援システム、投薬日数決定支援方法及び投薬日数決定支援プログラムを提供することを目的とする。

本発明の投薬日数決定支援システムは、患者に対して投薬を行う際に投薬日数の決定を支援する投薬日数決定支援システムであって、
前記患者の前回の診察日を示す情報を記憶する記憶部と、
前記記憶部に記憶された前記患者の前回の診療日を加味して前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数を認識する投薬日数決定支援部と、
前記患者の前回の診療日に処方された薬剤の前回投薬日数と前記投薬日数決定支援部により認識された前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数とに基づいて、前記患者が今回の診療日又は薬剤受領予定日に有すると推定される推定残薬日数を算出する残薬日数推定部と、
算出された推定残薬日数と今回の診療日又は薬剤受領予定日から次回診療予定日までの日数とに応じて今回の投薬日数を算出する投薬日数算出部を備えることを特徴とする。

上記構成の投薬日数決定支援システムによれば、前記残薬日数推定部が推定残薬日数を算出し、投薬日数算出部が当該推定残薬日数と今回の診療日又は薬剤受領予定日から次回診療予定日までの日数とに応じて今回の投薬日数を算出するので、医師等による投薬日数決定及びその入力操作を簡素化できる。

本発明の投薬日数決定支援システムにおいて、
前記投薬日数算出部は、投薬日数と用量又は分量とに応じて投薬量を算出することが好ましい。

上記構成の投薬日数決定支援システムによれば、投薬日数と用量又は分量とに応じて投薬量を算出するので、投薬量を決定するための入力操作を簡素化することができることができる。

本発明の投薬日数決定支援システムにおいて、
前記投薬日数算出部は、
今回の診療の予約日が前倒しで変更されたか否かを判定し、
当該今回の診療の予約日が前倒しで変更されたと判定された場合、変更前の今回の診療の予約日又は薬剤受領予定日が、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日よりも後かどうかを判定し、
変更前の今回の診療の予約日又は薬剤受領予定日が、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日よりも後であると判定した場合には、その差分の日数に応じた日数だけ今回の投薬日数を減数して算出することが好ましい。

変更前の今回の診療の予約日又は薬剤受領予定日が、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日よりも後の場合、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日から変更前の今回の診療の予約日又は薬剤受領予定日までの日数分だけ、患者が薬剤を所有しているか、又は患者がその日数分だけ薬剤を服用しなくてよい状態であると推察される。上記構成の投薬日数決定支援システムによれば、今回の診療の予約日が前倒しで変更された場合、変更前の今回の診療の予約日又は薬剤受領予定日が、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日よりも後の場合には、その差分の日数に応じた日数だけ今回の投薬日数から減ずるので、投薬日数の残薬をさらに減らすことができる投薬日数が算出される。

本発明の投薬日数決定支援システムにおいて、
前記投薬日数算出部は、患者の受診履歴を参照することにより、次回診療予定日を推定し、かつ、前記推定残薬日数と前記今回の診療日又は薬剤受領予定日から前記推定された次回診療予定日までの日数とに応じて今回の投薬日数を算出することが好ましい。

当該構成の投薬日数決定支援システムによれば、投薬日数算出部により、患者の受診履歴が参照され、次回診療予定日が推定される。

そして、投薬日数算出部により、前記推定残薬日数と前記今回の診療日又は薬剤受領予定日から前記推定された次回診療予定日までの日数とに応じて今回の投薬日数が算出される。

これにより、患者が次回診療予約を行っていない段階でも、推定残薬数と次回診療予定日とを勘案した形で今回の投薬日数が算出できるので、患者または医師の手間を減らしながら、残薬の発生を抑制することが出来る。

本発明の投薬日数決定支援システムにおいて、
診療の予約を受け付ける診療予約受付部を備え、
前記投薬日数算出部は、今回の診療の終了後から所定時間以内に前記診療予約受付部により次回診療予定日の予約が受け付けられた場合には、当該予約された次回診療予定日を用い、今回の診療の終了後から所定時間以内に前記診療予約受付部により予約が受け付けられなかった場合には、患者の受診履歴を参照することにより、次回診療予定日を推定するように構成されていることが好ましい。

診療の終了後の所定時間後には処方を行うことが好ましい。換言すれば、診療終了後処方が行われるまでには期限がある。一方で、患者または医師の都合によっては、その期限までに予約ができることもあれば、予約ができないこともある。

この点に鑑みて構成された投薬日数決定支援システムによれば、今回の診療の終了後から所定時間以内に診療予約受付部により予約が受け付けられていればそれを反映し、診療予約が受け付けられていなければ受診履歴から次回診療予定日が推定される。これにより、残薬を抑制するような処方日数の算出にあたって、患者または医師が予約をした場合には予約された次回の診療予定日を用いることによりその患者または医師の意思を尊重し、患者または医師が予約をしていない場合には、次回の診療予定日を推定することにより患者または医師の手間を減らすことが出来る。

本発明の投薬日数決定支援システムにおいて、
投薬数の履歴及び薬代の履歴を、前記患者に閲覧可能に出力する出力部を備えることが好ましい。

上記構成の投薬日数決定支援システムによれば、患者自らが自分の治療情報を容易に知ることができ患者の利便性が向上する。

本発明の投薬日数決定支援システムにおいて、
前記処方される薬剤を配送する配送システムを備え、前記投薬日数算出部は、前記次回診療予定日から配送にかかる日数後の日を次回の薬剤受領予定日として認識し、前記今回の診療日又は薬剤受領予定日から前記次回の薬剤受領予定日までの日数から、当該推定残薬日数を減算した日数を前記今回の投薬日数として決定することが好ましい。

上記構成の投薬日数決定支援システムによれば、前記次回診療予定日から配送にかかる日数後の日までの日数が勘案されて今回の投薬日数が決定されるので、残薬の増加を抑制しつつ、次回の薬剤受領予定日まで薬剤が切れないような投薬日数とすることが出来る。

本発明の投薬日数決定支援システムにおいて、
前記患者の診療日にて処方される薬剤を配送する配送システムを備え、
前記投薬日数算出部は、一度次回の診療の予約がなされた後に次回の診療予定日が後ろ倒しに変更された場合、当初の次回の診療予定日と変更後の次回の診療予定日との差分の日数分の薬剤を患者宛てに発送するよう、前記配送システムに指示するように構成されていることが好ましい。

当該構成の投薬日数決定支援システムによれば、前記投薬日数算出部は、一度次回の診療の予約がなされた後に次回の診療予定日が後ろ倒しに変更された場合、当初の次回の診療予定日と変更後の次回の診療予定日との差分の日数分の薬剤を患者宛てに発送するよう、前記配送システムに指示する。これにより、当初に処方された薬剤及び残薬が当初の次回診療予定日周辺に尽きてしまうとしても、追加の薬剤が患者宛てに発送されるので、変更後の次回の診療予定日までの薬剤が確保される。これにより、予約変更を気にして薬剤の処方量に余裕を持たせる必要性が薄まるので、より残薬の発生を抑えることが可能となる。

遠隔診療支援システムの全体構成図。 患者リストを示す図。 医師リストを示す図。 保険組織リストを示す図。 診療支援情報リストを示す図。 診察情報リストを示す図。 予約リストを示す図。 診療可能時間帯情報リストを示す図。 基準保険組織負担額情報リストを示す図。 配達日数情報リストを示す図。 遠隔診療支援の一連の処理の全体フローチャート。 予約受付処理のフローチャート。 診療支援情報登録処理のフローチャート。 遠隔診療支援処理のフローチャート。 遠隔診療支援処理（投薬日数決定支援処理）のフローチャート。 遠隔診療支援処理（投薬日数決定支援処理）の後半のフローチャート。 前回の薬剤受領日から今回の薬剤受領予定日を経た患者が有する処方薬数の変化を示すグラフ。 前回の薬剤受領日から今回の薬剤受領予定日を経た患者が有する処方薬数の変化を示すグラフ。 医療費請求・報酬支払処理のフローチャート。 診察情報画面の構成図。 システム利用費決済処理のフローチャート。 薬剤履歴提供処理のフローチャート。 薬剤履歴画面の構成図。

以下、図面を参照しつつ本発明による実施例の投薬日数決定支援システムを包含する遠隔診療支援システムを一例として詳細に説明する。

（投薬日数決定支援システムを包含する遠隔診療支援システム）
遠隔診療支援システムは、医師と患者との間で行われる遠隔診療を支援するシステムである。

遠隔診療支援システムは、図１に示されるように、遠隔診療支援サーバ１と、一又は複数の医師端末２とを備える。遠隔診療支援サーバ１及び医師端末２のそれぞれは、一又は複数のユーザー端末３、一又は複数の保険組織端末４、及び一又は複数の自動薬剤配送センターＤＰ（配送システム）における薬剤配送端末５とのそれぞれとインターネット等の公共通信網（ネットワーク）を介して相互に通信可能に構成されている。なお、図１ではそれぞれ一つの医師端末２、ユーザー端末３、保険組織端末４及び自動薬剤配送センターＤＰの薬剤配送端末５を図示している。また、自動薬剤配送センターＤＰは当該遠隔診療支援システムを運用している医療機関（患者が遠隔診療を受ける医療機関）の一部である調剤薬局いわゆる院内処方を実施する事業所であり、遠隔診療支援サーバ１からの処方箋データにより個別に患者のもとへ薬剤を提供する機能を有している。自動薬剤配送センターＤＰは、患者者の診療日にて処方される薬剤を配送する配送システムとして遠隔診療支援システムに含まれる。

（遠隔診療支援サーバ）
遠隔診療支援サーバ１は、サーバ制御部１１と、サーバ記憶部１２と、サーバ通信部１５とを備えている。なお、遠隔診療支援サーバ１を構成するコンピュータの一部又は全部が、他の端末、例えば、医師端末２を構成するコンピュータにより構成されていてもよい。例えば、移動局としての一又は複数の医師端末２により、遠隔診療支援サーバ１の一部又は全部が構成されていてもよい。

サーバ制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の演算処理装置、メモリ、及びＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）デバイス等により構成されている。サーバ制御部１１は、一のプロセッサにより構成されてもよく、相互通信可能な複数のプロセッサにより構成されてもよい。

サーバ制御部１１は、所定のプログラムを読み込んで実行することにより、後述の演算処理を実行する診療予約受付部１１１、診療支援情報登録部１１２、診察情報登録部１１３、医療費決定部１１４、システム利用費決済部１１５、薬剤履歴提供部１１６、処方薬配送指示部１１７、及び投薬日数決定支援部１１８として機能する。投薬日数決定支援部１１８は投薬日数決定支援機能として残薬日数推定部１１８Ａ及び投薬日数算出部１１８Ｂを有している。

サーバ記憶部１２は、例えばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置により構成されている。サーバ記憶部１２は、サーバ制御部１１の演算結果、又はサーバ制御部１１がサーバ通信部１５を介して受信したデータを記憶するように構成されている。

サーバ記憶部１２は、患者リスト１２１、医師リスト１２２、保険組織リスト１２３、診療支援情報リスト１２４、診察情報リスト１２５、予約リスト１２６、診療可能時間帯情報リスト１２７、基準保険組織負担額情報リスト１２８、支払機関情報１２９及び配達日数情報リスト１３０を記憶するように構成されている。なお、患者リスト１２１、診療支援情報リスト１２４、及び診察情報リスト１２５のそれぞれに含まれる情報がカルテ情報に相当する。

患者リスト１２１は、図２Ａに示されるように、患者ＩＤカラム１２１１と、患者名カラム１２１２と、性別カラム１２１３と、年齢カラム１２１４と、病名カラム１２１５と、保険番号カラム１２１６と、連絡先カラム１２１７と、負担割合カラム１２１８と、決済情報カラム１２１９とを含んでいる。

患者ＩＤカラム１２１１は、患者それぞれを識別するためのＩＤ（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を格納している。患者名カラム１２１２は、患者それぞれの氏名及び名称を格納している。性別カラム１２１３は、患者それぞれの性別を格納している。年齢カラム１２１４は、患者それぞれの年齢を格納している。病名カラム１２１５は、患者それぞれの病名を格納している。保険番号カラム１２１６は、患者それぞれに割り振られた保険番号を格納している。この保険番号には、患者それぞれが加入している保険組織を識別するためのＩＤが含まれている。連絡先カラム１２１７は、患者それぞれの連絡先、例えば、薬剤の配送先（例えば住所）、電話番号、メールアドレスを格納している。薬剤の配送先は、例えば、郵便番号、地方若しくは州、都道府県、市町村、区、郡、丁目、番地、号、建物名及び部屋番号又は緯度及び経度等により表される。負担割合カラム１２１８は、医療費に対する患者それぞれの自己負担割合を格納している。決済情報カラム１２１９は、クレジットカード番号及び有効期限等の患者それぞれに対して請求及び決済を行うための情報を格納している。

患者リスト１２１に含まれる情報は、例えば、患者が遠隔診療支援システムに登録したときに入力され得る。

医師リスト１２２は、図２Ｂに示されるように、医師ＩＤカラム１２２１と、医師名カラム１２２２と、性別カラム１２２３と、専門カラム１２２４と、連絡先カラム１２２５と、報酬支払先情報カラム１２２６とを含む。

医師ＩＤカラム１２２１は、それぞれの医師を識別するための医師ＩＤを格納する。医師名カラム１２２２は、医師それぞれの氏名及び名称を格納する。性別カラム１２２３は、医師のそれぞれの性別を格納する。専門カラム１２２４は、医師のそれぞれの専門分野に含まれる病名を格納する。これに代えて、専門カラム１２２４には、医師のそれぞれの専門分野の名称（例えば「内科」）が格納されてもよい。連絡先カラム１２２５は、医師それぞれの連絡先、例えばメールアドレスを格納している。報酬支払先情報カラム１２２６は、医師それぞれの報酬の支払先の情報として、例えば口座情報を格納している。

医師リスト１２２に含まれる情報は、例えば医師が遠隔診療システムに登録したときに入力される。

保険組織リスト１２３は、図２Ｃに示されるように、保険組織ＩＤカラム１２３１と、保険組織名カラム１２３２と、決済情報カラム１２３３と、システム利用開始日カラム１２３４とを含む。

保険組織ＩＤカラム１２３１は、それぞれの保険組織を識別するためのＩＤを格納している。保険組織名カラム１２３２は、それぞれの保険組織名を格納している。決済情報カラム１２３３は、それぞれの保険組織の引落口座情報又はクレジットカード番号等の請求及び決済に必要な決済情報を格納している。システム利用開始日カラム１２３４は、それぞれの保険組織が遠隔診療支援システムを利用し始めた日（例えば、保険組織の加入者が最初に遠隔診療支援システムを介した遠隔診療を受診した日）を格納している。

診療支援情報リスト１２４は、患者が予め診療の前に登録する診療支援情報のリストであり、図２Ｄに示されるように、患者ＩＤカラム１２４１と、登録日時カラム１２４２と、血圧カラム１２４３と、体温カラム１２４４と、体重カラム１２４５と、最近かかった病気カラム１２４６と、最近飲んでいる薬剤カラム１２４７と、メッセージカラム１２４８と、を含む。診療支援情報リスト１２４は、このほかに診療に必要な情報を含むカラムを含んでいてもよい。

患者ＩＤカラム１２４１は、患者ＩＤを格納している。登録日時カラム１２４２は情報が登録された日時を格納している。血圧カラム１２４３は血圧値を格納している。体温カラム１２４４は体温を示す値を格納している。体重カラム１２４５は体重を示す値を格納している。最近かかった病気カラム１２４６は病名を示す文字列を格納している。最近飲んでいる薬剤カラム１２４７は薬剤を示す文字列を格納している。メッセージカラム１２４８は、患者により入力された文字列を格納している。

診察情報リスト１２５は、遠隔診療における診察結果に関する診察情報のリストが格納されており、図２Ｅに示されるように、患者ＩＤカラム１２５１と、受診日時カラム１２５２と、症状・診断結果カラム１２５３と、処方内容カラム１２５４と、医師ＩＤカラム１２５５と、医療点数（診療報酬点数）カラム１２５６と、医師コメントカラム１２５７とを含む。

患者ＩＤカラム１２５１は、診察対象の患者（対象患者）の患者ＩＤを格納している。受診日時カラム１２５２は、遠隔診療を受診した日時を格納している。症状・診断結果カラム１２５３は、遠隔診療における医師の見解情報を格納している。

処方内容カラム１２５４は、処方箋情報を格納している。処方箋情報は、薬名、分量、用法、用量、診療日、服用開始日、及び投薬日数を含む。薬名は薬剤を一意に特定可能な薬剤の名称である。分量は例えば内服薬で１日あたりの投与量（総服用量）である。用法は例えば朝食後、昼食後、夕食後、食間等の服用時点である。用量は１回あたりの服用量である。服用開始は服用を開始する時点であり、投薬日数は服用開始日から服用終了日するまでの期間である。

医師ＩＤカラム１２５５は、診察した医師（担当医師）の医師ＩＤを格納している。医療点数カラム１２５６は、遠隔診療における対象患者に対する診療報酬点数を格納している。医師コメントカラム１２５７は、担当医師から対象患者へのコメントを格納している。

予約リスト１２６は、図２Ｆに示されるように、患者ＩＤカラム１２６１と、医師ＩＤカラム１２６２と、予約時間帯カラム１２６３とを含む。

患者ＩＤカラム１２６１は、遠隔診療を予約した患者ＩＤを格納している。医師ＩＤカラム１２６２は、当該遠隔診療を担当する医師ＩＤを格納している。予約時間帯カラム１２６３は、当該遠隔診療の受診予約時間帯を格納している。

診療可能時間帯情報リスト１２７は、各医師が診療可能な時間帯に関する診療可能時間帯情報のリストであり、図２Ｇに示されるように、医師ＩＤカラム１２７１と、診療可能時間帯カラム１２７２とを含む。

医師ＩＤカラム１２７１は、医師それぞれの医師ＩＤを格納している。診療可能時間帯カラム１２７２は、医師それぞれの診療可能な時間帯を格納している。

基準保険組織負担額情報リスト１２８は、図２Ｈに示されるように、患者ＩＤカラム１２８１と、基準保険組織負担額カラム１２８２とを含む。

患者ＩＤカラム１２８１は、患者それぞれの患者ＩＤを格納している。基準保険組織負担額カラム１２８２は、患者それぞれの基準となる保険組織負担額を格納している。

患者ごとの基準となる保険組織負担額は、例えば患者それぞれの初回の受診日における当該患者の健康状態から算出される対面診療の医療費（薬代を含む。）のうちの保険組織負担額である。これに代えて、患者それぞれの初回から所定回までの各受診日における当該患者の健康状態から算出される対面診療１回あたりの医療費（例えば、平均医療費）の保険組織負担額が患者ごとの基準となる保険組織負担額として採用されてもよい。また、これに代えて、患者リスト１２１から患者の性別、年齢及び病名のうち少なくとも１つの情報を取得し、当該取得された情報に当てはまる患者の平均的な対面診療における医療費のうちの保険組織負担額が基準保険組織負担額として採用されてもよい。また、予め設定された医療費が基準保険組織負担額として設定されてもよい。

支払機関情報１２９は、保険診療費の請求先である保険診療費支払機関に関する情報である。補足すると、一般に、医療機関は、保険診療費と保険番号とを保険診療費支払機関に伝え、保険診療費の支払いを受ける。保険診療費支払機関は、保険番号から特定される保険組織に対し、保険診療費を請求する。

配達日数情報リスト１３０は、図２Ｉに示されるように、配達地域カラム１３０１と、配達必要日数カラム１３０２とを含む。

配達地域カラム１３０１は、処方薬を配達する地域を示す情報を格納している。処方薬を配達する地域を示す情報は、例えば、郵便番号、地方又は州、都道府県、市町村区郡、丁目、番地、号及び建物名の一部または全部又は緯度及び経度により指定される範囲等、薬剤の配送先よりも広範囲な地域を示す情報により表される。処方薬を配達する地域を示す情報は、薬剤の配送先を示す情報と同じ形式で表されることが好ましい。ここでは、処方薬を配達する地域を示す情報として、都道府県及び市町村区郡が格納されている。配達必要日数カラム１３０２は、各地域ごとの調剤後から患者に処方薬が届く配達日までに必要な日数（配達必要日数）を格納している。

かかる配達必要日数は、例えば、遠隔診療支援サーバ１の管理者等が予め設定した値であってもよいし、契約している配達業者から提供されたデータから認識された値であってもよいし、後日のアンケート等でこのシステムを利用した患者から取得したデータに基づいて地域ごとの配達にかかった配達日数の平均値を用いてもよい。

サーバ通信部１５は、ネットワークとしての公衆通信網（例えばインターネット）に接続され、医師端末２、ユーザー端末３、保険組織端末４、薬剤配送端末５等の外部の端末と通信する通信装置により構成されている。

（医師端末）
医師端末２は、医師端末制御部２１と、医師端末記憶部２２と、医師端末出力部２３と、医師端末入力部２４と、医師端末通信部２５とを備える。

医師端末２は、デスクトップコンピュータ等、特定箇所に設置されるように、サイズ、形状及び重量が設計されているコンピュータにより構成されている。医師端末２は、タブレット型端末又はスマートフォン等、医師端末２のユーザーである医師Ｄによる携帯が可能なようにサイズ、形状及び重量が設計されているコンピュータにより構成されていてもよい。

医師端末制御部２１は、ＣＰＵ等の演算処理装置、メモリ、及びＩ／Ｏデバイス等により構成されている。医師端末制御部２１には、遠隔診療支援サーバ１よりダウンロードした遠隔診療支援プログラムがインストールされている。遠隔診療支援プログラムが起動されることにより、医師端末制御部２１は、後述の演算処理を実行するように構成されている。

医師端末記憶部２２は、例えばＲＯＭ、ＲＡＭ、ＨＤＤ等の記憶装置により構成されている。医師端末記憶部２２は、あらかじめ登録された医師Ｄの医師ＩＤ２２１と、後述する予約受付処理で記憶される通信確立情報２２２とを記憶するように構成されている。

医師端末出力部２３は液晶パネルのような表示装置により構成され、医師端末入力部２４はタッチパッドのような位置入力装置により構成され、これらが組み合わせられてタッチパネルが構成されている。これに加えて又は代えて、医師端末入力部２４はキーボードを備えてもよい。医師端末出力部２３は、さらにスピーカーを備えている。また、医師端末入力部２４はさらにマイクを備えている。

医師端末通信部２５は、有線通信又はＷｉＦｉ（登録商標）等の通信規格にしたがった無線通信を介して、遠隔診療支援サーバ１等の外部端末と相互通信するよう構成されている。

（ユーザー端末）
ユーザー端末３は、ユーザー端末制御部３１と、ユーザー端末記憶部３２と、ユーザー端末出力部３３と、ユーザー端末入力部３４と、ユーザー端末通信部３５とを備える。

ユーザー端末制御部３１は、保険組織端末４（又は対象患者Ｐが加入する保険組織のサーバ若しくは遠隔診療支援サーバ１）からダウンロードした遠隔診療受診支援プログラムがインストールされている。遠隔診療受診支援プログラムが起動されることにより、ユーザー端末制御部３１は、後述する各処理を実行するように構成されている。

ユーザー端末記憶部３２は、医師ＩＤ２２１及び通信確立情報２２２に代え、ユーザー端末３のユーザーである対象患者Ｐの患者ＩＤ３２１及び通信確立情報３２２を記憶している。上記点を除き、ユーザー端末３は、医師端末２と同様の構成を有している。

（保険組織端末）
保険組織端末４は、遠隔診療支援プログラムがインストールされていない点、保険組織の保険組織ＩＤ４２１を記憶する点を除き、医師端末２と同様のデスクトップコンピュータ等により構成されている。

（薬剤配送端末）
薬剤配送端末５は、遠隔診療支援サーバ１からダウンロードした遠隔診療受診支援プログラムがインストールされている。

薬剤配送端末５は、医師ＩＤ２２１及び通信確立情報２２２に代え、遠隔診療支援サーバ１との通信のための薬剤配送ＩＤ及び通信確立情報を記憶している点を除き、医師端末２と同様のデスクトップコンピュータ等により構成されている。

（遠隔診療支援の一連の処理の全体概要）
図３を参照して、遠隔診療支援の一連の処理の全体概要を説明する。

遠隔診療支援サーバ１、医師端末２及びユーザー端末３は、後述する予約受付処理を実行する（図３／ＳＴＥＰ１００）。予約受付処理により、遠隔診療の受診日時の予約が行われ、医師端末２及びユーザー端末３に互いに通信を確立させるための通信確立情報が送信される。

遠隔診療支援サーバ１、医師端末２及びユーザー端末３は、後述する診療支援情報登録処理を実行する（図３／ＳＴＥＰ２００）。診療支援情報登録処理により、遠隔診療の受診前に対象患者Ｐの診療支援情報が診療支援情報リスト１２４に追加登録され、対象患者Ｐの遠隔診療を担当する担当医師Ｄにこの情報が共有される。

遠隔診療支援サーバ１、医師端末２及びユーザー端末３は、後述する遠隔診療支援処理を実行する（図３／ＳＴＥＰ３００）。医師端末２及びユーザー端末３は、通信確立情報を用いて通信を確立させ、担当医師Ｄ及び対象患者Ｐ間の遠隔診療支援を行う。遠隔診療の終了後、医師端末２は、対象患者Ｐに対する診察情報を遠隔診療支援サーバ１に送信し、診察情報リスト１２５に追加させる。

遠隔診療支援サーバ１、医師端末２及びユーザー端末３は、後述する医療費請求・報酬支払処理を実行する（図３／ＳＴＥＰ４００）。遠隔診療支援サーバ１は、図３／ＳＴＥＰ２００及びＳＴＥＰ３００で登録された診察情報に基づいて遠隔診療の医療費を決定し、保険支払機関に対する遠隔診療の保険診療費の課金、対象患者Ｐに対する遠隔診療の自己負担費の課金、及び担当医師Ｄに対する報酬支払の決済を行う。

遠隔診療支援サーバ１は、後述するシステム利用費決済処理を実行する（図３／ＳＴＥＰ５００）。遠隔診療支援サーバ１は、当該保険組織の決済情報を用いて、システム利用費の決済を行う。

（予約受付処理）
図４を参照して、予約受付処理を説明する。

まず、医師端末制御部２１は、担当医師Ｄから診療可能時間帯が医師端末入力部２４を介して入力されたか否かを判定する（図４／ＳＴＥＰ１２０）。

当該判定結果が否定的である場合（図４／ＳＴＥＰ１２０‥ＮＯ）、医師端末制御部２１は、再度図４／ＳＴＥＰ１２０の処理を実行する。

当該判定結果が肯定的である場合（図４／ＳＴＥＰ１２０‥ＹＥＳ）、医師端末制御部２１は、予め医師端末記憶部２２に登録された担当医師Ｄの医師ＩＤ、及び担当医師Ｄから入力された診療可能時間帯を含む診療可能時間帯情報を作成し、医師端末通信部２５を介して、遠隔診療支援サーバ１に送信する（図４／ＳＴＥＰ１２１）。

診療予約受付部１１１は、サーバ通信部１５を介して診療可能時間帯情報を受信したか否かを判定する（図４／ＳＴＥＰ１１０）。

当該判定結果が否定的である場合（図４／ＳＴＥＰ１１０‥ＮＯ）、診療予約受付部１１１は、再度図４／ＳＴＥＰ１１０の処理を実行する。

当該判定結果が肯定的である場合（図４／ＳＴＥＰ１１０‥ＹＥＳ）、診療予約受付部１１１は、受信した診療可能時間帯情報を図２Ｇに示される診療可能時間帯情報リスト１２７に追加する（図４／ＳＴＥＰ１１１）。

ユーザー端末制御部３１は、対象患者Ｐからの診療希望時間帯を指定する予約申し込み操作をユーザー端末入力部３４を介して検知したか否かを判定する（図４／ＳＴＥＰ１３０）。

なお、図４／ＳＴＥＰ１３０に先立って、ユーザー端末３からアクセスを受けた診療予約受付部１１１が、患者リスト１２１を参照することにより対象患者Ｐの病名を認識し、医師リスト１２２を参照することにより当該病名を専門とする医師を抽出し、診療可能時間帯情報リスト１２７を参照することにより当該抽出された医師の診療可能時間帯を抽出し、当該診療可能時間帯をユーザー端末３に送信し、ユーザー端末出力部３３に出力させてもよい。

当該判定結果が否定的である場合（図４／ＳＴＥＰ１３０‥ＮＯ）、ユーザー端末制御部３１は、再度図４／ＳＴＥＰ１３０の処理を実行する。

当該判定結果が肯定的である場合（図４／ＳＴＥＰ１３０‥ＹＥＳ）、ユーザー端末制御部３１は、ユーザー端末通信部３５を介して、予めユーザー端末記憶部３２に登録された対象患者Ｐの患者ＩＤ及び対象患者Ｐから入力された診療希望時間帯を含む予約申込み情報を作成し、遠隔診療支援サーバ１に送信する（図４／ＳＴＥＰ１３１）。

診療予約受付部１１１は、サーバ通信部１５を介して、予約申込み情報を受信したか否かを判定する（図４／ＳＴＥＰ１１２）。

当該判定結果が否定的である場合（図４／ＳＴＥＰ１１２‥ＮＯ）、診療予約受付部１１１は、再度図４／ＳＴＥＰ１１２の処理を実行する。

当該判定結果が肯定的である場合（図４／ＳＴＥＰ１１２‥ＹＥＳ）、診療予約受付部１１１は、予約申込み情報に基づいて、患者リスト１２１と医師リスト１２２と診療可能時間帯情報リスト１２７とを参照して、予約申込み情報に示される診療希望時間帯に対応可能な医師である担当医師を抽出する（図４／ＳＴＥＰ１１３）。

より具体的には、診療予約受付部１１１は、患者リスト１２１を参照して、予約申込み情報に含まれる対象患者Ｐの患者ＩＤを用いることにより対象患者Ｐの病名を認識する。そして、診療予約受付部１１１は、医師リスト１２２及び診療可能時間帯情報リスト１２７を参照することにより当該対象患者Ｐの病名に対応可能かつ予約申込み情報に含まれる診療希望時間帯に対応な医師である担当医師を認識する。

診療予約受付部１１１は、対象患者Ｐの患者ＩＤと、担当医師の医師ＩＤと、診療希望時間帯である予約時間帯とを予約リスト１２６に追加する（図４／ＳＴＥＰ１１４）。

診療予約受付部１１１は、患者リスト１２１を参照して対象患者Ｐの連絡先を認識し、対象患者Ｐの連絡先のメールアドレスに対し、サーバ通信部１５を介して、予約が受け付けられた旨と担当医師への通信確立情報と担当医師の医師情報を含む予約受付情報を送信する（図４／ＳＴＥＰ１１５）。

ここで、担当医師への通信確立情報は、例えば、担当医師による遠隔診療を受診するために必要な情報であり、例えば、対象患者Ｐの患者ＩＤに関連付けられた担当医師の医師ＩＤ及び遠隔診療支援サーバ１によるテレビ電話サービスを利用するための情報又は外部のテレビ電話サービスを利用するための情報としての担当医師の連絡先等の情報である。

ユーザー端末制御部３１は、ユーザー端末通信部３５を介して、予約受付情報を受信したか否かを判定する（図４／ＳＴＥＰ１３２）。

当該判定結果が否定的である場合（図４／ＳＴＥＰ１３２‥ＮＯ）、ユーザー端末制御部３１は、再度図４／ＳＴＥＰ１３２の処理を実行する。

当該判定結果が肯定的である場合（図４／ＳＴＥＰ１３２‥ＹＥＳ）、ユーザー端末制御部３１は、予約受付情報に含まれる予約が受け付けられた旨と担当医師の医師情報をユーザー端末出力部３３へ出力するとともに（図４／ＳＴＥＰ１３３）、予約受付情報に含まれる通信確立情報をユーザー端末記憶部３２に記憶する（図４／ＳＴＥＰ１３４）。

診療予約受付部１１１は、医師リスト１２２を参照して担当医師Ｄの連絡先を認識し、担当医師Ｄの連絡先に対し、サーバ通信部１５を介して、予約時間帯と対象患者Ｐへの通信確立情報と対象患者Ｐの患者情報を含む担当予約情報を送信する（図４／ＳＴＥＰ１１６）。

ここで、対象患者Ｐへの通信確立情報は、例えば、対象患者Ｐによる遠隔診療を受診するために必要な情報であり、担当医師への通信確立情報と同様の情報である。

医師端末制御部２１は、医師端末通信部２５を介して、担当予約情報を受信したか否かを判定する（図４／ＳＴＥＰ１２２）。

当該判定結果が否定的である場合（図４／ＳＴＥＰ１２２‥ＮＯ）、医師端末制御部２１は、再度図４／ＳＴＥＰ１２２の処理を実行する。

当該判定結果が肯定的である場合（図４／ＳＴＥＰ１２２‥ＹＥＳ）、医師端末制御部２１は、担当予約情報に含まれる予約時間帯と対象患者Ｐの患者情報を医師端末出力部２３へ出力するとともに（図４／ＳＴＥＰ１２３）、担当予約情報に含まれる通信確立情報を医師端末記憶部２２に記憶する（図４／ＳＴＥＰ１２４）。

以上の処理により、予約受付処理が終了する。なお、医師端末２又はユーザー端末３への通信確立情報の送信のうち、一方が省略されてもよい。

（診療支援情報登録処理）
図５を参照して、診療支援情報登録処理を説明する。

ユーザー端末制御部３１は、診療支援情報がユーザー端末入力部３４を介して入力されたか否かを判定する（図５／ＳＴＥＰ２３０）。診療支援情報は、図２Ｄに示されるように、患者ＩＤと対象患者Ｐにより入力された血圧、体温、体重、最近かかった病気、最近飲んでいる病気、及びメッセージ等の医師が診療に参考にできる情報とを含む情報である。

当該判定結果が否定的である場合（図５／ＳＴＥＰ２３０‥ＮＯ）、ユーザー端末制御部３１は、再度図５／ＳＴＥＰ２３０を実行する。患者ＩＤは、対象患者Ｐにより入力されてもよいし、ユーザー端末記憶部３２から読み込まれてもよい。

当該判定結果が肯定的である場合（図５／ＳＴＥＰ２３０‥ＹＥＳ）、ユーザー端末制御部３１は、ユーザー端末通信部３５を介して、診療支援情報を遠隔診療支援サーバ１に送信する（図５／ＳＴＥＰ２３１）。

診療支援情報のうち、血圧、体温及び体重のうち一部又は全部の値については、対象患者Ｐに身につけられたウェアラブルセンサ又は対象患者Ｐが使用した測定器により測定された値が、当該ウェアラブルセンサ又は当該測定器に登録された患者ＩＤとともに無線通信又は有線通信を介して遠隔診療支援サーバ１に送信されてもよい。

診療支援情報登録部１１２は、サーバ通信部１５を介して診療支援情報を受信したか否かを判定する（図５／ＳＴＥＰ２１０）。

当該判定結果が否定的である場合（図５／ＳＴＥＰ２１０‥ＮＯ）、診療支援情報登録部１１２は、再度図５／ＳＴＥＰ２１０を実行する。

当該判定結果が肯定的である場合（図５／ＳＴＥＰ２１０‥ＹＥＳ）、診療支援情報登録部１１２は、診療支援情報を診療支援情報リストに追加して登録する（図５／ＳＴＥＰ２１１）。

診療支援情報登録部１１２は、診療支援情報に含まれる患者ＩＤを基に、予約リスト１２６を参照して担当医師Ｄを認識し、医師リスト１２２を参照して担当医師Ｄの連絡先を認識し、当該担当医師Ｄの連絡先に対し、診療支援情報を送信する（図５／ＳＴＥＰ２１２）。

医師端末制御部２１は、診療支援情報を受信したか否かを判定する（図５／ＳＴＥＰ２２０）。

当該判定結果が否定的である場合（図５／ＳＴＥＰ２２０‥ＮＯ）、医師端末制御部２１は、再度図５／ＳＴＥＰ２２０を実行する。

当該判定結果が肯定的である場合（図５／ＳＴＥＰ２２０‥ＹＥＳ）、医師端末制御部２１は、診療支援情報を医師端末記憶部２２に記憶すると共に医師端末出力部２３に出力する（図５／ＳＴＥＰ２２１）。

以上の処理により、診療支援情報登録処理が終了する。

（遠隔診療支援処理）
図６Ａ及び図６Ｂのフロー図を参照して、遠隔診療支援処理を説明する。

医師端末制御部２１は、担当医師Ｄからの接続操作を医師端末入力部２４を介して検知したか否かを判定する（図６Ａ／ＳＴＥＰ３２０）。

当該判定結果が否定的である場合（図６Ａ／ＳＥＴＰ３２０‥ＮＯ）、医師端末制御部２１は、再度図６Ａ／ＳＥＴＰ３２０の処理を実行する。

当該判定結果が肯定的である場合（図６Ａ／ＳＥＴＰ３２０‥ＹＥＳ）、医師端末制御部２１は、医師端末記憶部２２に記憶された通信確立情報２２２から接続要求を作成し、当該接続要求を医師端末通信部２５を介してユーザー端末３に送信する（図６Ａ／ＳＴＥＰ３２１）。

ユーザー端末制御部３１は、ユーザー端末通信部３５を介して接続要求を受信したか否かを判定する（図６Ａ／ＳＴＥＰ３３０）。

当該判定結果が否定的である場合（図６Ａ／ＳＥＴＰ３３０‥ＮＯ）、ユーザー端末制御部３１は、再度図６Ａ／ＳＥＴＰ３３０の処理を実行する。

当該判定結果が肯定的である場合（図６Ａ／ＳＥＴＰ３３０‥ＹＥＳ）、ユーザー端末制御部３１は、接続要求をユーザー端末記憶部３２に記憶し、医師端末２に対し、接続を確立したことを知らせる接続確立通知を送信する（図６Ａ／ＳＴＥＰ３３１）。

医師端末制御部２１は、医師発言情報が医師端末入力部２４を介して入力されたか否かを判定する（図６Ａ／ＳＴＥＰ３２２）。医師端末制御部２１は、例えば、医師端末入力部２４としてのマイクを介して入力される担当医師Ｄの発言を医師発言情報として認識してもよい。また、医師端末制御部２１は、例えば、医師端末入力部２４としてのキーボード又はタッチパネルへの操作を介して入力される文字列等を医師発言情報として認識してもよい。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３２２‥ＹＥＳ）、医師端末制御部２１は、医師端末通信部２５を介して医師発言情報をユーザー端末３に送信する（図６Ａ／ＳＴＥＰ３２３）。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３２２‥ＮＯ）、医師端末制御部２１は、図６Ａ／ＳＴＥＰ３２４の処理を実行する。

また、図６Ａ／ＳＴＥＰ３３１のあと、ユーザー端末制御部３１は、患者発言情報がユーザー端末入力部３４を介して入力されたか否かを判定する（図６Ａ／ＳＴＥＰ３３２）。

ユーザー端末制御部３１は、例えば、ユーザー端末入力部３４としてのマイクを介して入力される対象患者Ｐの発言を患者発言情報として認識してもよい。また、ユーザー端末制御部３１は、例えば、ユーザー端末入力部３４としてのキーボード又はタッチパネルへの操作を介して入力される文字列等を患者発言情報として認識してもよい。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３３２‥ＹＥＳ）、ユーザー端末制御部３１は、ユーザー端末通信部３５を介して患者発言情報を医師端末２に送信する（図６Ａ／ＳＴＥＰ３３３）。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３３２‥ＮＯ）、ユーザー端末制御部３１は、図６Ａ／ＳＴＥＰ３３４の処理を実行する。

図６Ａ／ＳＴＥＰ３２４において、医師端末制御部２１は、医師端末通信部２５を介してユーザー端末３から患者発言情報を受信したか否かを判定する。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３２４‥ＹＥＳ）、医師端末制御部２１は、受信した患者発言情報を医師端末出力部２３に出力する（図６Ａ／ＳＴＥＰ３２５）。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３２４‥ＮＯ）、医師端末制御部２１は、図６Ａ／ＳＴＥＰ３２６の処理を実行する。

図６Ａ／ＳＴＥＰ３２６において、医師端末制御部２１は、医師端末入力部２４を介して終了操作を検知したか又はユーザー端末３との接続が切断されたか否かを判定する。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３２６‥ＹＥＳ）、医師端末制御部２１は、図６Ａ／ＳＴＥＰ３２７の処理を実行する。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３２６‥ＮＯ）、医師端末制御部２１は、図６Ａ／ＳＴＥＰ３２２の処理を実行する。

図６Ａ／ＳＴＥＰ３３４において、ユーザー端末制御部３１は、ユーザー端末通信部３５を介して医師端末２から医師発言情報を受信したか否かを判定する。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３３４‥ＹＥＳ）、ユーザー端末制御部３１は、受信した医師発言情報をユーザー端末出力部３３に出力する（図６Ａ／ＳＴＥＰ３３５）。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３３４‥ＮＯ）、ユーザー端末制御部３１は、図６Ａ／ＳＴＥＰ３３６の処理を実行する。

図６Ａ／ＳＴＥＰ３３６において、ユーザー端末制御部３１は、ユーザー端末入力部３４を介して終了操作を検知し又は医師端末２との接続が切断されたか否かを判定する。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３３６‥ＮＯ）、ユーザー端末制御部３１は、図６Ａ／ＳＴＥＰ３３２の処理を実行する。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３３６‥ＹＥＳ）、ユーザー端末制御部３１は、ユーザー端末通信部３５を介して切断通知を医師端末２に対して送信する（図６Ａ／ＳＴＥＰ３３７）。

図６Ａ／ＳＴＥＰ３２７において、医師端末制御部２１は、医師端末通信部２５を介して切断通知をユーザー端末３に対して送信する。

ユーザー端末制御部３１は、次回予約申し込み画面をユーザー端末出力部３３に出力する（図６Ａ／ＳＴＥＰ３３８）。

ユーザー端末制御部３１は、次回予約申し込み画面の確認ボタンが押下されたか否かを判定する（図６Ａ／ＳＴＥＰ３３９）。

当該判定結果が否定的である場合（図６Ａ／ＳＴＥＰ３３９‥ＮＯ）、ユーザー端末制御部３１は、その処理を終了する。

当該判定結果が肯定的である場合（図６Ａ／ＳＴＥＰ３３９‥ＹＥＳ）、ユーザー端末制御部３１は、次回診療の予約受付処理（図６Ａ／ＳＴＥＰ１００）を実行する。具体的には遠隔診療支援サーバ１の診療予約受付部１１１等による図４／ＳＴＥＰ１３０以下の予約受付処理を実行する。ここで、診療予約受付部１１１は、対象患者Ｐの患者ＩＤ「１」と、担当医師の医師ＩＤ「１１」と、診療希望時間帯（次回診療予約日）である予約時間帯「２０１６／５／２１ １５：００〜１５：１５」との情報を予約リスト１２６（図２Ｆ）に追加する。

予約受付処理（図６Ａ／ＳＴＥＰ１００）の後、医師端末２は、次回予約受付処理が完了したか否かを判定する（図６Ｂ／ＳＴＥＰ３２８）。

当該判定結果が否定的である場合（図６Ｂ／ＳＴＥＰ３２８‥ＮＯ）、医師端末２は、図６Ｂ／ＳＴＥＰ３２８の処理を再度実行する。

当該判定結果が肯定的である場合（図６Ｂ／ＳＴＥＰ３２８‥ＹＥＳ）、医師端末２は、医師端末記憶部２２に記憶された対象患者Ｐの患者ＩＤを含む今回−投薬日数決定データ要求を、医師端末通信部２５を介して遠隔診療支援サーバ１に送信する（図６Ｂ／ＳＴＥＰ３２９）。

（投薬日数決定支援処理）
図６Ｂのフロー図、図６Ｄ及び図６Ｅを参照して、投薬日数決定支援部１１８が実行する投薬日数決定支援処理を説明する。

ここで、図６Ｄは、前回の薬剤受領日（ｒ０）から次回の薬剤受領予定日（ｒ２）の処方薬数の変化を示すグラフであって、前回の薬剤受領日（ｒ０）、前回診療日の処方における薬剤の患者１日当たりの薬剤の服用量（ｄ０）、前回診療日の処方における薬剤の投薬日数（Ｔ０）、今回診療日（Ｐ１）、今回診療日の処方における患者１日当たりの薬剤の服用量（ｄ１）、今回の診療日の薬剤の今回の投薬日数（Ｔ１）、設定すべき今回の投薬日数（Ｔ１）、次回診療予約日（Ｐ２）、次回の薬剤受領予定日（ｒ２）、及び今回診療日に処方された薬剤を患者が受領する予定日である今回の薬剤受領予定日（ｒ１）を含むグラフである。図６Ｅは、図６Ｄに加えて、前回の薬剤受領日（ｒ０）から基準受領予定日（Ｐｒ）までの日数（Ｂ）が設定された場合の処方薬数の変化を示すグラフである。図６Ｄ及び図６Ｅの横軸は日数を、縦軸は患者の手元にある処方薬数の変化を示す。

図６Ｂのフロー図に戻って、遠隔診療支援サーバ１の投薬日数決定支援部１１８は、サーバ通信部１５を介して今回−投薬日数決定データの要求を受信したか否かを判定する（図６Ｂ／ＳＴＥＰ３１０）。

当該判定結果が否定的である場合（図６Ｂ／ＳＴＥＰ３１０‥ＮＯ）、投薬日数決定支援部１１８は、図６Ｂ／ＳＴＥＰ３１０の処理を再度実行する。

当該判定結果が肯定的である場合（図６Ｂ／ＳＴＥＰ３１０‥ＹＥＳ）、遠隔診療支援サーバ１の投薬日数決定支援部１１８は、今回−投薬日数決定データ要求に含まれる対象患者Ｐの患者ＩＤ「１」に基づいて、予約リスト１２６（図２Ｆ）を参照してその予約時間帯における次回診療予約日（Ｐ２：２０１６／５／２１）と、診察情報リスト１２５（図２Ｅ）を参照して当該患者ＩＤを含む診察情報を認識する（図６Ｂ／ＳＴＥＰ３１１）。例えば、投薬日数決定支援部１１８は、診察情報リスト１２５（図２Ｅ）から、対象患者Ｐの患者ＩＤ「１」に対応するフィールドの情報を抽出して、受診日時カラム１２５２と処方内容カラム１２５４を参照して、対象患者Ｐの患者ＩＤ「１」であるフィールドの情報のそれぞれの受診時点、すなわち、診察情報リスト１２５（図２Ｅ）の前回の診療日（２０１６／３／２２）における対象患者Ｐの薬剤１の投薬日数（３０日）を認識する。なお、薬剤の投薬日数のデータがない場合、診療予約受付部１１１は、各診療日における投薬量を、１日当たりの用量又は分量で割ることにより、薬剤の投薬日数を認識してもよい。

なお、投薬日数決定支援部１１８は、対象患者Ｐの患者ＩＤ「１」に対応するフィールドの情報に含まれる診察日のうち、最新の診察日（２０１６／３／２２）を前回の診療日として認識する。なお、図２Ｅに示される今回の診察日（２０１６／４／１５）における診察情報フィールド１２５８は、図６Ｂ／ＳＴＥＰ３１０より後のＳＴＥＰ３１９２で追加されるので、図６Ｂ／ＳＴＥＰ３１０を実行する時点では登録されていない。

また、投薬日数決定支援部１１８は、医師端末２から受信した今回−投薬日数決定データ要求から今回の診療日（Ｐ１）を認識する。

また、投薬日数決定支援部１１８は、患者リスト１２１を参照して、対象患者Ｐの患者ＩＤ「１」に対応する薬剤の配送先（北海道利尻郡・・・）を認識する。投薬日数決定支援部１１８は、配達日数情報リスト１３０を参照して、例えば部分一致等による検索により、当該薬剤の配送先（北海道利尻郡・・・）に対応する図２Ｉに示される地域（北海道利尻）を認識する。投薬日数決定支援部１１８は、配達日数情報リスト１３０を参照して、当該認識された地域における配達必要日数（１日）を認識する。投薬日数決定支援部１１８は、前回の診療日（２０１６／３／２２）から配達必要日数（１日）後の日（２０１６／３／２３）を前回の薬剤受領日（ｒ０）として認識する。これに代えて、投薬日数決定支援部１１８は、前回の診療日（２０１６／３／２２）を前回の薬剤受領日（ｒ０）として認識してもよい。

次に、残薬日数推定部１１８Ａは、図６Ｄに示す患者の前回診療日に処方された薬剤の前回投薬日数（Ｔ０）と前回の薬剤受領日（ｒ０）から今回の薬剤受領予定日（ｒ１）までの日数（ｒ１−ｒ０）とに基づいて、患者Ｐが今回の薬剤受領予定日（ｒ１）に有すると推定される推定残薬日数を算出する（図６Ｂ／ＳＴＥＰ３１２）。

具体的に、残薬日数推定部１１８Ａは、前回の薬剤受領日ｒ０の認識と同様にして、今回の診療日（Ｐ１）に基づいて今回の薬剤受領予定日（ｒ１）を認識する。ここでは、残薬日数推定部１１８Ａは、今回の診療日（Ｐ１、２０１６／４／１５）から必要配達日数（Ｌ１、１日）後の日（２０１６／４／１６）を今回の薬剤受領予定日（ｒ１）として認識する。そして、残薬日数推定部１１８Ａは、診察情報リスト１２５（図２Ｅ）に格納された患者の前回の診療日（Ｐ０，２０１６／３／２２）に処方された薬剤１の前回投薬日数（Ｔ０，３０日）と前回の薬剤受領日（ｒ０、２０１６／３／２３）から今回の薬剤受領予定日（ｒ１、２０１６／４／１６）までの日数（ｒ１−ｒ０、２４日）とに基づいて、患者が今回の薬剤受領予定日に有すると推定される推定残薬日数として６日を算出する。

ここで、推定残薬日数は、次の式で表される。

ここで、Ｔ０は前回の投薬日数、ｒ１は今回の薬剤受領予定日、ｒ０は前回の薬剤受領日である。

これに代えて又は加えて、配達の必要がない場合または配達必要日数が一定であると仮定できる場合には、残薬日数推定部１１８Ａは、前回の投薬日数Ｔ０と、前回の診療日Ｐ０から今回の診療日Ｐ１までの日数Ｐ１−Ｐ０からＴ０−Ｐ１−Ｐ０により推定残薬日数を認識してもよい。

推定残薬日数は、前回と今回の薬剤受領予定日の間に患者が処方薬を服用しきれなかった薬剤の残りを、患者が服用し消費する日数である。なお、推定残薬日数の算出は、これに限定されずに、例えば、診療日間の日数と予め設定された残薬日数を推定する係数との積を用いた数式により行ってもよい。

次に、投薬日数決定支援部１１８の投薬日数算出部１１８Ｂは、薬剤の配送にかかる日数を考慮して今回の投薬日数（Ｔ１）を以下のように算出する。

投薬日数算出部１１８Ｂは、図６Ｄに示す自動薬剤配送センターＤＰによる薬剤の配送にかかる日数分（配達必要日数：Ｌ２）を認識する（図６Ｂ／ＳＴＥＰ３１３）。例えば、投薬日数算出部１１８Ｂは、患者ＩＤ「１」より、患者リスト１２１の連絡先カラム１２１７から住所「北海道利尻郡…」を認識する。そして、投薬日数算出部１１８Ｂは、配達日数情報リスト１３０から、該住所が属する処方薬の配達地域を特定し、該配達地域にて処方薬が届くまでの配達必要日数（１日）を認識する。

次に、投薬日数算出部１１８Ｂは、図６Ｄに示す推定残薬日数と次回診療予約日（Ｐ２）からの配達必要日数分（Ｌ２）を考慮した演算を行い、今回の投薬日数（Ｔ１）を算出する（図６Ｂ／ＳＴＥＰ３１４）。

より具体的には、投薬日数算出部１１８Ｂは、診察情報リスト１２５（図２Ｅ）を参照して、今回の薬剤受領予定日（ｒ１、２０１７／４／１６）から次回診療予定日（Ｐ２，２０１７／５／２１）までの日数（Ｐ２−ｒ１、３５）に配達必要日数（Ｌ２、１）を加えた日数（３６）から推定残薬日数（Ｔ０−（ｒ１−ｒ０）、６）を減算して今回の投薬日数（Ｔ１、３０）を算出する。すなわち、今回の投薬日数（Ｔ１）は、次の式で表される。

ここで、Ｐ０は前回の診療日、Ｌ０は前回の配達必要日数である。

Ｔ１は次のように変形できる。

投薬日数算出部１１８Ｂは、今回の投薬日数（Ｔ１）と用量又は分量とに応じて投薬量を算出することができる。例えば、患者１日当たりの薬剤の服用量（ｄ１）と今回の投薬日数（Ｔ１）の積ｄ１＊Ｔ１により、今回の投薬量を算出できる。ここで、投薬日数算出部１１８Ｂは、診察情報リスト１２５に示される前回の１日当たりの薬剤の服用量（ｄ０）と同一の服用量を今回の患者１日当たりの薬剤の服用量（ｄ１）として認識してもよいし、医師端末２から受信したデータに基づいて患者１日当たりの薬剤の服用量（ｄ１）を認識してもよい。

次に、図６Ｅに示すように、投薬日数算出部１１８Ｂは、今回の基準受領予定日（Ｐｒ）が前回に投与された薬剤を消費する日（ｒ１＋Ｔ０）よりも後の場合（ｒ１＋Ｔ０＜Ｐｒ）には、その差分の日数（Ｂ＝Ｐｒ−ｒ１−Ｔ０）に応じて、上記決定された投薬日数を修正して、修正投薬日数を決定する。

今回の基準受領予定日（Ｐｒ）は、予約の変更があった場合の今回の最初に予約された診療予定日から認識される今回の当初の薬剤受領予定日である。

今回の基準受領予定日（Ｐｒ）が前回に投与された薬剤を消費する日（ｒ１＋Ｔ０）よりも後の場合（ｒ１＋Ｔ０＜Ｐｒ）とは、その差分の日数（Ｂ＝Ｐｒ−ｒ１−Ｔ０）分については、薬剤を投与しなくともよい日数であったり、前々回に投与された薬剤を消費するための日数であったりする。

このような日数を勘案することにより、今回の投薬日数をより適切に決定できる。

具体的には、投薬日数算出部１１８Ｂは、今回の診療日について予約の前倒しの変更がなされたか否かを判定する。そして、当該判定結果が肯定的である場合、図６Ｂ／ＳＴＥＰ３１５以下の処理を実行する。

投薬日数算出部１１８Ｂは、基準受領予定日（Ｐｒ）を認識する（図６Ｂ／ＳＴＥＰ３１５）。投薬日数算出部１１８Ｂは、例えば、不図示のログ等から、当初の予約日を認識する。そして、投薬日数算出部１１８Ｂは、今回の薬剤受領予定日と同様にして、当初の予約日から配送必要日数後の日を基準受領予定日（Ｐｒ）として認識する。

次に、投薬日数算出部１１８Ｂは、基準受領予定日（Ｐｒ）が前回に投与された薬剤を消費する日（ｒ１＋Ｔ０）より後か否かを判定する（図６Ｂ／ＳＴＥＰ３１６）。

当該判定結果が否定的である場合（図６Ｂ／ＳＴＥＰ３１６‥ＮＯ）、投薬日数算出部１１８Ｂは、算出された今回の投薬日数Ｔ１に基づいて、今回診療日における今回の投薬日数と今回の投薬量に基づいて投薬日数データを作成する（図６Ｃ／ＳＴＥＰ３１８）。

当該判定結果が肯定的である場合（図６Ｃ／ＳＴＥＰ３１６‥ＴＥＳ）、投薬日数算出部１１８Ｂは、差分の日数（Ｂ＝Ｐｒ−ｒ１−Ｔ０）を、今回の投薬日数Ｔ１から減算し、修正した今回の投薬日数（Ｐ２＋Ｌ２−ｒ１−（Ｔ０−（ｒ１−ｒ０）−Ｂ）を決定する（図６Ｃ／ＳＴＥＰ３１７）。投薬日数算出部１１８Ｂは、この修正した今回の投薬日数に基づいて投薬日数データを作成する（図６Ｃ／ＳＴＥＰ３１８）。

投薬日数決定支援部１１８は、作成した今回の投薬日数データをサーバ通信部１５を介して医師端末２に送信する（図６Ｃ／ＳＴＥＰ３１９）。

医師端末２において、医師端末制御部２１は、医師端末通信部２５を介して今回の投薬日数データを受信したか否かを判定する（図６Ｃ／ＳＴＥＰ３２９１）。

当該判定結果が否定的である場合（図６Ｃ／ＳＴＥＰ３２９１‥ＮＯ）、医師端末制御部２１は、図６Ｃ／ＳＴＥＰ３２９１の処理を再度実行する。

当該判定結果が肯定的である場合（図６Ｃ／ＳＴＥＰ３２９１‥ＹＥＳ）、医師端末制御部２１は、受信した今回の投薬日数データと医師端末入力部２４を介して入力された情報に基づいて、対象患者Ｐに対する診察情報を作成する（図６Ｃ／ＳＴＥＰ３２９２）。

医師端末入力部２４を介して入力された情報には、症状・診断結果、処方内容（医師端末通信部２５を介して受信した今回の投薬日数データの投薬日数と投薬量）、診療報酬点数及び医師コメントが含まれる。対象患者Ｐに対する診察情報には、通信確立情報に含まれる患者ＩＤと、接続確立通知を受信した時刻である受信日時と、症状・診断結果と、処方内容と、担当医師Ｄの医師ＩＤと、診療報酬点数と、医師コメントとが含まれる。

例えば、対象患者Ｐ「○田×男」に対する診察情報には、患者ＩＤ「１」と、受診日時「２０１６／４／１５ １２：００：００」と、症状・診断結果「高血圧 薬維持」と、処方内容「医薬１ ３カプセル／毎食 ３０日分」と、担当医師Ｄの医師ＩＤ「１１」と、診療報酬点数「１００」と、医師コメント「この調子でお酒と塩分を控えていきましょう。習慣的な運動も意識的に取り入れてください。」とが含まれる。

医師端末制御部２１は、作成した診察情報を医師端末通信部２５を介して遠隔診療支援サーバ１に送信する（図６Ｃ／ＳＴＥＰ３２９３）。

診察情報登録部１１３は、診察情報をサーバ通信部１５を介して受信したか否かを判定する（図６Ｃ／ＳＴＥＰ３１９１）。

当該判定結果が否定的である場合（図６Ｃ／ＳＴＥＰ３１９１‥ＮＯ）、診察情報登録部１１３は、図６Ｃ／ＳＴＥＰ３１９１の処理を再度実行する。

当該判定結果が肯定的である場合（図６Ｃ／ＳＴＥＰ３１９１‥ＹＥＳ）、診察情報登録部１１３は、受信した診察情報を診察情報リスト１２５に追加し登録する（図６Ｃ／ＳＴＥＰ３１９２）。例えば、図２Ｅに示されるように、患者ＩＤ「１」のフィールドとして、受診日時「２０１６／４／１５ １２：００：００」と、症状・診断結果「高血圧 薬維持」と、処方内容「医薬１ ３カプセル／毎食 ３０日分」と、担当医師Ｄの医師ＩＤ「１１」と、診療報酬点数「１００」と、医師コメント「この調子でお酒と塩分を控えていきましょう。習慣的な運動も意識的に取り入れてください。」とが、対象患者Ｐ「○田×男」に対する診察情報として診察情報リスト１２５に追加される。

遠隔診療支援サーバ１の処方薬配送指示部１１７は、追加された診察情報から処方内容を抽出するとともに、患者ＩＤ「１」より患者リスト１２１の連絡先カラム１２１７から住所と該住所が属する処方薬の配達地域（図１、図２Ｉ／配達日数情報リスト１３０）を特定する。処方薬配送指示部１１７は、特定された配達地域における自動薬剤配送センターＤＰの薬剤配送端末５に、当該処方内容を編集不可能なデータとしてこの処方箋情報を、サーバ通信部１５を介して送信する（図６Ｃ／ＳＴＥＰ３１９３）。例えば、遠隔診療支援サーバ１のから、当該患者の住所と図２Ｅに示される診察情報リスト１２５における患者ＩＤ「１」、医師ＩＤ「１１」、処方内容「医薬１ ３カプセル／毎食 ３０日分」等が処方箋情報として「北海道利尻」地域の自動薬剤配送センターＤＰの薬剤配送端末５に送信される。

自動薬剤配送センターＤＰの薬剤配送端末５は、処方箋情報をその端末通信部を介して受信したか否かを判定する（図６Ｃ／ＳＴＥＰ３５０）。

当該判定結果が否定的である場合（図６Ｃ／ＳＴＥＰ３５０‥ＮＯ）、薬剤配送端末５は、図６Ｃ／ＳＴＥＰ３５０の処理を再度実行する。

当該判定結果が肯定的である場合（図６Ｃ／ＳＴＥＰ３５０‥ＹＥＳ）、薬剤配送端末５は、受信した処方箋情報（患者住所、処方内容）をその端末記憶部に追加し登録して、処方箋情報に基づく調剤と配送を調剤薬局に実行させる（図６Ｃ／ＳＴＥＰ３５１）。

自動薬剤配送センターＤＰの調剤薬局において、登録された処方箋情報に基づいて調剤と配送が行われる。例えば、図１に示す薬剤師Ｐｈは、薬剤配送端末５によって制御されるプリンタＰＲＴ（図１）の印刷内容『患者ＩＤ「１」の対象患者の処方箋情報「医薬１ ３カプセル／毎食 ３０日分」』に基づいて、調剤を行う。

そして、調剤薬局での調剤された薬剤（処方薬）Ｐｄは、宅配便等の輸送便により該当住所の対象患者へ送られる。

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

（医療費請求・報酬支払処理）
図７を参照して、医療費請求・報酬支払処理を説明する。

医療費決定部１１４は、診察情報リスト１２５に含まれる対象患者Ｐの診療報酬点数に基づいて、所定の計算式を用いて、対象患者Ｐの自己負担額を決定する（図７／ＳＴＥＰ４１０）。ここで、対象患者Ｐの自己負担額は、遠隔診療支援処理（図３／ＳＴＥＰ３００）における担当医師Ｄによる遠隔診療における診療報酬点数に基づいて定められる額であり、処方された薬剤の薬剤費用は含まない。

医療費決定部１１４は、サーバ通信部１５を介して決定した対象患者Ｐの自己負担額及び対象患者Ｐの診察情報を含む請求データをユーザー端末３に送信する（図７／ＳＴＥＰ４１１）。

第１ユーザー端末制御部３１は、第１ユーザー端末通信部３５を介して請求データを受信したか否かを判定する（図７／ＳＴＥＰ４３０）。

当該判定結果が否定的である場合（図７／ＳＴＥＰ４３０‥ＮＯ）、第１ユーザー端末制御部３１は、図７／ＳＴＥＰ４３０の処理を再度実行する。

当該判定結果が肯定的である場合（図７／ＳＴＥＰ４３０‥ＹＥＳ）、第１ユーザー端末制御部３１は、図８に示されるように、受信した診察情報及び請求データを含む診察情報画面６を第１ユーザー端末出力部３３に出力する（図７／ＳＴＥＰ４３１）。

診察情報画面６は、例えば、Ｗｅｂ画面として構成され、受診者名表示６１１と、受診者ＩＤ表示６１２と、担当医師名表示６２１と、担当医師の医師ＩＤ表示６２２と、担当医師の医師ＩＤに関連付けられて記憶されている担当医師の写真を表示する写真表示６２３と、受信日時表示６３１と、症状・診断結果表示６３２と、処方内容表示６４１と、医師コメント６５１と、今回の自己負担額表示６６１とを含む。

図７／ＳＴＥＰ４１１の後、医療費決定部１１４は、患者リスト１２１に含まれる対象患者Ｐの決済情報を用いて、対象患者Ｐの自己負担額を決済する（図７／ＳＴＥＰ４１２）。例えば、医療費決定部１１４は、対象患者Ｐの決済情報に含まれるクレジット情報と自己負担額とを当該クレジット情報から特定される決済サーバに送信することにより、自己負担額の決済を行う。

また、医療費決定部１１４は、前記診療報酬点数と所定の式とを用いて担当医師Ｄの医療報酬を決定する（図７／ＳＴＥＰ４１３）。

医療費決定部１１４は、サーバ通信部１５を介して、医師報酬データを医師端末２に送信する（図７／ＳＴＥＰ４１４）。

医療費決定部１１４は、医師リスト１２２に含まれる担当医師Ｄの報酬支払先情報を用いて、担当医師Ｄに対する報酬の支払いの決済を行う（図７／ＳＴＥＰ４１５）。例えば、医療費決定部１１４は、担当医師Ｄの口座情報と医療報酬とを当該口座情報から特定される銀行サーバに送信することにより、担当医師Ｄに対する報酬の支払いの決済を行う。

また、医師端末制御部２１は、医師端末通信部２５を介して医療報酬データを受信したか否かを判定する（図７／ＳＴＥＰ４２０）。

当該判定結果が否定的である場合（図７／ＳＴＥＰ４２０‥ＮＯ）、医師端末制御部２１は、図７／ＳＴＥＰ４２０の処理を再度実行する。

当該判定結果が肯定的である場合（図７／ＳＴＥＰ４２０‥ＹＥＳ）、医師端末制御部２１は、受信した医療報酬データを含む医療報酬画面を医師端末出力部２３に出力する（図７／ＳＴＥＰ４２１）。

以上により、医療費請求・報酬支払処理が終了する。

（システム利用費決済処理）
図９を参照して、システム利用費決済処理を説明する。

システム利用費決済部１１５は、診察情報リスト１２５に含まれる対象患者Ｐの診察情報と、患者リスト１２１に含まれる対象患者Ｐの負担割合に基づいて、医療費のうち、対象患者Ｐが加入する保険組織の負担額である保険組織負担額を算出する（図９／ＳＴＥＰ５１０）。ここで、保険組織負担額は、保険診療費支払機関が一時的に負担した保険診療費と、診察情報に含まれる処方内容から特定される薬剤費用のうちの保険組織負担額とを合算した金額である。

例えば、対象患者Ｐの負担割合がＢＲであり、診察情報に含まれる診療報酬点数がＷ点であり、診療報酬点数１点当たりＸ円であり、薬剤１が合計Ｙカプセル処方され、外部の薬剤費用サーバから取得された薬剤１の単価が１カプセル当たりＺ円である場合、システム利用費決済部１１５は、以下の式（１）により、保険組織負担額ＩＢを算出する。

システム利用費決済部１１５は、基準保険組織負担額情報リスト１２８に示される対象患者Ｐの基準保険組織負担額と保険組織負担額との差額の一部をシステム利用費として決定する（図９／ＳＴＥＰ５１１）。例えば、システム利用費決済部１１５は、対象患者Ｐの基準保険組織負担額と保険組織負担額との差額の５割をシステム利用費として決定する。

システム利用費決済部１１５は、患者リスト１２１に含まれる対象患者Ｐの保険組織ＩＤを認識し、保険組織リスト１２３に含まれる当該保険組織ＩＤから特定される保険組織の決済情報を用いて、決定されたシステム利用費を決済する（図９／ＳＴＥＰ５１２）。

以上により、システム利用費決済処理が終了する。なお、システム利用費決済部１１５は、サーバ通信部１５と保険組織端末４を介して、保険組織の担当者Ｗに対し、保険組織の保険組織負担額のデータを提供する。

以上により、システム利用費決済処理が終了する。

（薬剤履歴提供処理）
図１０を参照して、対象患者Ｐのユーザー端末３に対し、対象患者Ｐの投薬数及び薬剤費用の履歴を示す薬剤履歴データを提供する薬剤履歴提供処理を説明する。

ユーザー端末制御部３１は、ユーザー端末入力部３４を介して薬剤履歴の表示要求操作が入力されたか否かを判定する（図１０／ＳＴＥＰ７３０）。

当該判定結果が否定的である場合（図１０／ＳＴＥＰ７３０‥ＮＯ）、ユーザー端末制御部３１は、図１０／ＳＴＥＰ７３０の処理を再度実行する。

当該判定結果が肯定的である場合（図１０／ＳＴＥＰ７３０‥ＹＥＳ）、ユーザー端末制御部３１は、ユーザー端末記憶部３２に記憶された対象患者Ｐの患者ＩＤを含む薬剤履歴データの要求を、ユーザー端末通信部３５を介して遠隔診療支援サーバ１に送信する（図１０／ＳＴＥＰ７３１）。

薬剤履歴提供部１１６は、サーバ通信部１５を介して薬剤履歴の表示の要求を受信したか否かを判定する（図１０／ＳＴＥＰ７１０）。

当該判定結果が否定的である場合（図１０／ＳＴＥＰ７１０‥ＮＯ）、薬剤履歴提供部１１６は、図１０／ＳＴＥＰ７１０の処理を再度実行する。

当該判定結果が肯定的である場合（図１０／ＳＴＥＰ７１０‥ＹＥＳ）、薬剤履歴提供部１１６は、薬剤履歴の表示の要求に含まれる対象患者Ｐの患者ＩＤに基づいて、診察情報リスト１２５を参照して、当該患者ＩＤを含む診察情報を認識する（図１０／ＳＴＥＰ７１１）。

例えば、薬剤履歴提供部１１６は、図２Ｅに示される診察情報リスト１２５の対象患者Ｐの患者ＩＤ「１」であるフィールドの情報から、各受診時点における患者の投薬数の履歴を認識する（図１０／ＳＴＥＰ７１２）。

例えば、薬剤履歴提供部１１６は、診察情報リスト１２５を参照して、各受診時点における対象患者Ｐの投薬数を認識する。ここで、薬剤履歴提供部１１６は、対象患者Ｐの薬剤費用を、保険自己負担割合と、調剤技術料、薬学管理料、薬剤料、特定保険医療材料料等の診療報酬点数に基づいて算出する。

薬剤履歴提供部１１６は、各受診時点における対象患者Ｐの投薬数及び薬剤費用に基づいて、投薬数及び薬剤費用の薬剤履歴データを作成する（図１０／ＳＴＥＰ７１３）。

薬剤履歴提供部１１６は、作成した投薬数及び薬剤費用の薬剤履歴データをサーバ通信部１５を介してユーザー端末３に送信する（図１０／ＳＴＥＰ７１４）。

ユーザー端末制御部３１は、ユーザー端末通信部３５を介して投薬数及び薬剤費用の薬剤履歴データを受信したか否かを判定する（図１０／ＳＴＥＰ７３２）。

当該判定結果が否定的である場合（図１０／ＳＴＥＰ７３２‥ＮＯ）、ユーザー端末制御部３１は、図１０／ＳＴＥＰ７３２の処理を再度実行する。

当該判定結果が肯定的である場合（図１０／ＳＴＥＰ７３２‥ＹＥＳ）、ユーザー端末制御部３１は、受信した投薬数及び薬剤費用の薬剤履歴データを例えば図１１に示される薬剤履歴画面７としてユーザー端末出力部３３に出力する（図１０／ＳＴＥＰ７３３）。

図１１は、薬剤履歴データに基づいて作成された表である。

薬剤履歴画面７は、例えば、Ｗｅｂ画面として構成され、患者ＩＤ表示６１２と、日時１２５２と、投薬数・薬剤費用１２５４１とを含む。

以上により、薬剤履歴提供処理が終了する。

なお、薬剤履歴提供部１１６が投薬数の履歴及び薬代の履歴を、患者に閲覧可能に出力する出力部に相当する。

上記構成の遠隔診療支援システムによれば、患者自分の薬剤履歴情報を容易に知ることができ患者の利便性が向上する。

（変形態様）
以上、本発明の一実施例について説明したが、かかる実施例に限定されるものではなく、特許請求の範囲に記載された本発明の範囲内において、種々の変形・変更が可能である。例えば、実施例においてはユーザー端末が遠隔診療支援サーバと通信をして実行しているが、ユーザー端末が必要な情報を遠隔診療支援サーバから取得し、すべての処理を行ってもよい。

また、上記実施形態では、診療予約受付部１１１により次回予約受付完了したことを要件として（図６Ｂ／ＳＴＥＰ３２８・・ＹＥＳ）、図６Ｂ／ＳＴＥＰ３２９以下の処理を実行したが、これに代えて、投薬日数決定支援部１１８は、例えば、診察情報リスト１２５から患者の平均の受診間隔を認識し、今回の診療日から当該間隔が経過した後の日を次回の診療予定日として推定して図６Ｂ／ＳＴＥＰ３１０〜図６Ｃ／ＳＴＥＰ３１９の処理を実行してもよい。この場合、診療予定日として、例えば、今回の診療日の１か月後の前後１週間等、複数の日が認識されることが好ましい。複数の日が認識された場合には、それぞれに応じた処方日数が提案されることが好ましい。例えば、２３日後、３０日後、３７日後が診療予定日として認識され、推定残薬日数が７日間である場合、処方日数として、１６日分、２３日分、３０日分が提案されることが好ましい。

また、投薬日数決定支援部１１８は、図６Ａ／ＳＴＥＰ３３７の切断後所定の時間（たとえば１時間）の間に診療予約受付部１１１による次回の予約受付が完了すれば、その日を次回の診療予定日として図６Ｂ／ＳＴＥＰ３２９以下の処理を実行し、図６Ａ／ＳＴＥＰ３３７の切断後所定の時間の間に診療予約受付部１１１による次回の予約受付が完了しなければ診察情報リスト１２５から次回の診療予定日を推定して図６Ｂ／ＳＴＥＰ３２９以下の処理を実行してもよい。

また、投薬日数決定支援部１１８は、一度次回の診療の予約がなされた後に次回の診療予定日が後ろ倒しに変更された場合、当初の次回の診療予定日と、変更後の次回の診療予定日との差分の日数分の薬剤について、ユーザー端末及び医師端末を介して患者及び医師に了承をとることを要件として、追加の薬剤を患者宛てに発送するよう、薬剤配送端末に指示してもよい。

また、次回の予約は、医師端末２から受信した情報に基づいてなされてもよい。

１‥遠隔診療支援サーバ、２‥医師端末、３‥ユーザー端末、４‥保険組織端末、５‥薬剤配送端末、１５‥サーバ通信部、１１１‥診療予約受付部、１１２‥診療支援情報登録部、１１３‥診察情報登録部、１１４‥医療費決定部、処方薬配送指示部１１７、１１８‥投薬日数決定支援部、１１８Ａ‥残薬日数推定部、１１８Ｂ‥投薬日数算出部、１１５‥システム利用費決済部、１１６‥薬剤履歴提供部、１１７‥処方薬配送指示部、１２‥サーバ記憶部、１２１‥患者リスト、１２２‥医師リスト、１２３‥保険組織リスト、１２４‥診療支援情報リスト、１２５‥診察情報リスト、１２６‥予約リスト、１２７‥診療可能時間帯情報リスト、１３０‥配達日数情報リスト、２１‥医師端末制御部、ＤＰ‥自動薬剤配送センター。

Claims (10)

1. 患者に対して投薬を行う際に投薬日数の決定を支援する投薬日数決定支援システムであって、
   前記患者の前回の診察日を示す情報を記憶する記憶部と、
   前記記憶部に記憶された前記患者の前回の診療日を加味して前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数を認識する投薬日数決定支援部と、
   前記患者の前回の診療日に処方された薬剤の前回投薬日数と前記投薬日数決定支援部により認識された前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数とに基づいて、前記患者が今回の診療日又は薬剤受領予定日に有すると推定される推定残薬日数を算出する残薬日数推定部と、
   算出された推定残薬日数と今回の診療日又は薬剤受領予定日から次回診療予定日までの日数とに応じて今回の投薬日数を算出する投薬日数算出部を備える
   ことを特徴とする投薬日数決定支援システム。
2. 前記投薬日数算出部は、投薬日数と用量又は分量とに応じて投薬量を算出する
   ことを特徴とする請求項１に記載の投薬日数決定支援システム。
3. 前記投薬日数算出部は、
   今回の診療の予約日が前倒しで変更されたか否かを判定し、
   当該今回の診療の予約日が前倒しで変更されたと判定された場合、変更前の今回の診療の予約日又は薬剤受領予定日が、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日よりも後かどうかを判定し、
   変更前の今回の診療の予約日又は薬剤受領予定日が、前回の診療日又は薬剤受領日から前回の投薬日数を経過した日よりも後であると判定した場合には、その差分の日数に応じた日数だけ今回の投薬日数を減数して算出する
   ことを特徴とする請求項１又は２に記載の投薬日数決定支援システム。
4. 前記投薬日数算出部は、患者の受診履歴を参照することにより、次回診療予定日を推定し、かつ、前記推定残薬日数と前記今回の診療日又は薬剤受領予定日から前記推定された次回診療予定日までの日数とに応じて今回の投薬日数を算出する
   ことを特徴とする請求項１〜３のいずれか１項に記載の投薬日数決定支援システム。
5. 診療の予約を受け付ける診療予約受付部を備え、
   前記投薬日数算出部は、今回の診療の終了後から所定時間以内に前記診療予約受付部により次回診療予定日の予約が受け付けられた場合には、当該予約された次回診療予定日を用い、今回の診療の終了後から所定時間以内に前記診療予約受付部により予約が受け付けられなかった場合には、患者の受診履歴を参照することにより、次回診療予定日を推定するように構成されている
   ことを特徴とする請求項４に記載の投薬日数決定支援システム。
6. 投薬数の履歴及び薬代の履歴を、前記患者に閲覧可能に出力する出力部を備える
   ことを特徴とする請求項１〜５のうちのいずれか一項に記載の投薬日数決定支援システム。
7. 前記患者の診療日にて処方される薬剤を配送する配送システムを備え、前記投薬日数算出部が配送による遅延を考慮して投薬日数を決定する
   ことを特徴とする請求項１〜６のうちのいずれか一項に記載の投薬日数決定支援システム。
8. 前記患者の診療日にて処方される薬剤を配送する配送システムを備え、
   前記投薬日数算出部は、一度次回の診療の予約がなされた後に次回の診療予定日が後ろ倒しに変更された場合、当初の次回の診療予定日と、変更後の次回の診療予定日との差分
   の日数分の薬剤を患者宛てに発送するよう、前記配送システムに指示するように構成されている
   ことを特徴とする請求項１〜７のうちのいずれか一項に記載の投薬日数決定支援システム。
9. 患者の前回の診察日を示す情報を記憶する記憶部を備えるシステムが実行する方法であって、
   前記記憶部に記憶された前記患者の前回の診療日を加味して前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数を認識するステップと、
   患者の前回の診療日に処方された薬剤の前回投薬日数と前記ステップにおいて認識された前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数とに基づいて、前記患者が今回の診療日又は薬剤受領予定日に有すると推定される推定残薬日数を算出するステップと、
   算出された推定残薬日数と今回の診療日又は薬剤受領予定日から次回診療予定日までの日数とに応じて今回の投薬日数を算出するステップとを含む
   ことを特徴とする投薬日数決定支援方法。
10. 患者の前回の診察日を示す情報を記憶する記憶部を備えるコンピュータに、
    前記記憶部に記憶された前記患者の前回の診療日を加味して前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数を認識するステップと、
    患者の前回の診療日に処方された薬剤の前回投薬日数と前記ステップにおいて認識された前回の診療日又は薬剤受領日から今回の診療日又は薬剤受領予定日までの日数とに基づいて、前記患者が今回の診療日又は薬剤受領予定日に有すると推定される推定残薬日数を算出するステップと、
    算出された推定残薬日数と今回の診療日又は薬剤受領予定日から次回診療予定日までの日数とに応じて今回の投薬日数を算出するステップとを
    実行させることを特徴とする投薬日数決定支援プログラム。