JP7245569B1 - プログラム、方法及び情報処理装置 - Google Patents

Abstract

【課題】薬剤師が、患者の薬剤の服薬状況をよりいっそう容易に把握できることを可能とする技術を提供する。【解決手段】プロセッサと、メモリとを備えるコンピュータに実行させるプログラムであって、プログラムは、プロセッサに、患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、処方箋が、予め規定された複数回数の処方が可能である処方箋であって、処方箋の処方回数が、規定された複数回数の上限に到達していない場合において、第１の情報に基づき、患者が処方箋に基づき薬剤を受け取る時期を算出する第２のステップと、第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、を実行させる。【選択図】図１

Description

本開示は、プログラム、方法及び情報処理装置に関する。

薬剤師は、薬局などの医療機関で患者に薬剤を提供するにあたり、薬を飲むうえでの留意点などを説明する。また、例えば、薬剤師は、慢性的な疾患を患っている患者に対して、提供した薬剤がなくなる前に再び病院を受診して、医師より薬剤を処方してもらい、薬局へ来局して薬剤の提供を受けることを説明する場合がある。次回の来院、来局時期を事前に患者へ通知するシステムとして、特許文献１がある。

特許文献１には、患者の処方箋情報と当該患者が所有する携帯端末の電子メールアドレスとを関連付けて記憶する患者情報記憶手段と、前記処方箋情報にもとづいて特定される薬剤の服用日時、及び／又は、次回の来院・来局時期を事前に通知するための通知メールを作成し、当該処方箋情報に関連付けられた電子メールアドレスに対して自動的に配信する通知メール自動配信手段と、を備える調剤薬局システムについて記載されている。

特開２０１３－１０５３０２号公報

患者より受け付けた処方箋が反復使用できる場合、薬剤の処方のための医師の診察が行われないことがある。そのため、薬剤師は、継続して薬剤の交付を受けることを患者へ促すなど、より一層患者に対して服薬を支援する必要が生じる場合がある。

そこで、本開示において、薬剤師が、患者に対する服薬支援をよりいっそう充実化させることを可能とする技術を提供する。

一実施形態によると、プロセッサと、メモリとを備えるコンピュータに実行させるプログラムが提供される。プログラムは、プロセッサに、患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、処方箋が、次の来局時に再度の使用が可能である場合において、第１の情報に基づき、次回患者が来局する時期を算出する第２のステップと、第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、を実行させる。

本開示によれば、薬剤師は、患者に対する服薬支援をよりいっそう充実化させることを可能とする。

システム１の全体の構成を示す図である。 第１の実施の形態のシステム１を構成する端末装置１０のブロック図である。 第１の実施の形態のシステム１を構成するサーバ２０の機能的な構成を示す図である。 サーバ２０が記憶する処方箋データベース２８１と、リマインドデータベース２８２と、連絡履歴データベース２８３と、患者情報データベース２８４のデータ構造を示す図である。 第１の実施の形態におけるシステム１により、患者へ薬剤の交付を可能とする時期を算出して、ユーザへ提示する流れの一例を示すフローチャートである。 第１の実施の形態におけるシステム１により、複数回数の薬剤の交付を可能とする処方箋において、薬剤を交付した回数が、予め規定された処方箋の使用可能な回数の上限に到達した場合における、システム１の処理の一例を示すフローチャートである。 第１の実施の形態における、ユーザである薬剤師の端末装置１０の画面例を示す図である。 第１の実施の形態における、ユーザである患者の端末装置３０の画面例を示す図である。 第２の実施の形態における、患者が直近に薬剤の交付を受けた薬局とは異なる薬局で薬剤の交付を受ける場合の流れの一例を示すフローチャートである。 第２の実施の形態における、患者の服薬状況に関する薬局間における情報共有について、患者の端末装置を利用する場合の流れの一例を示すフローチャートである。 第２の実施の形態における、薬剤師の端末装置１０又は患者の端末装置３０の画面例を示す図である。 第３の実施形態における、薬剤師によって患者への薬剤の交付の中止を判断した場合における処理を示すフローチャートである。 第４の実施の形態における、薬剤師のスケジュールを表示する流れの一例を示すフローチャートである。 第４の実施の形態における、薬剤師の端末装置１０の画面例を示す図である。

以下、図面を参照しつつ、本開示の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称及び機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

＜第１の実施の形態＞
＜１．システム１の全体構成＞
システム１は、医療機関において、薬剤師によって、患者に対して薬剤を提供しつつ、患者の薬剤の交付を受けることが可能な時期をユーザへ提示してリマインドすることを支援するためのシステムである。ここで、医療機関とは、医療を提供するための施設であり、例えば、病院、診療所、薬局、訪問看護ステーション、保健施設等である。以下、医療機関として薬局の例で説明する。また、ここでユーザとは、患者と、医療従事者である医師と薬剤師とのうち少なくともいずれかである。図１は、システム１の全体の構成を示す図である。

図１に示すように、システム１は、端末装置１０と、サーバ２０と、端末装置３０とを含む。端末装置１０は、医療機関に設置される端末、又は、医療機関の医療従事者が操作する端末である。端末装置１０は、医療機関として、薬局、病院などに設置される端末である。端末装置３０は、患者によって操作される端末である。端末装置１０、及び端末装置３０とサーバ２０とは、ネットワーク８０を介して通信接続する。

端末装置１０は、医療機関で各医療従事者によって操作される装置である。ここでいう医療従事者は、患者に対して薬剤を処方する者、又は、患者に薬剤を渡す者であり、例えば、医師、薬剤師が挙げられる。以下、医療従事者として薬剤師の例で説明する。端末装置１０は、例えば据え置き型のＰＣ（PersonalComputer）、ラップトップＰＣ、タブレットである。

端末装置３０は、患者によって所持される装置である。ここでいう患者は、医療機関で医師から薬剤を処方された者である。例えば端末装置３０は、タブレット、スマートフォンである。

図１に端末装置１０として示すように、端末装置１０は、通信ＩＦ（Interface）１２と、入力装置１３と、出力装置１４と、メモリ１５と、記憶部１６と、プロセッサ１９とを備える。

端末装置１０は、ネットワーク８０を介してサーバ２０と通信可能に接続される。ネットワーク８０の通信回線は、有線でもよいし無線でもよい。

通信ＩＦ１２は、端末装置１０が外部の装置と通信するため、信号を入出力するためのインタフェースである。入力装置１３は、薬剤師からの入力操作を受け付けるための入力装置（例えば、タッチパネル、タッチパッド、マウス等のポインティングデバイス、キーボード等）である。出力装置１４は、薬剤師に対し情報を提示するための出力装置（ディスプレイ、スピーカ等）である。メモリ１５は、プログラム、及び、プログラム等で処理されるデータ等を一時的に記憶するためのものであり、例えばＤＲＡ（DynamicRandomAccessMemory）等の揮発性のメモリである。記憶部１６は、データを保存するための記憶装置であり、例えばフラッシュメモリ、ＨＤＤ（HardDiscDrive）である。プロセッサ１９は、プログラムに記述された命令セットを実行するためのハードウェアであり、演算装置、レジスタ、周辺回路などにより構成される。

サーバ２０は、患者の情報及び薬剤師による患者への連絡履歴を管理する装置である。サーバ２０は、ネットワーク８０に接続されたコンピュータである。

図１に示すように、サーバ２０は、通信ＩＦ２２と、入出力ＩＦ２３と、メモリ２５と、ストレージ２６と、プロセッサ２９とを備える。

通信ＩＦ２２は、サーバ２０が外部の装置と通信するため、信号を入出力するためのインタフェースである。入出力ＩＦ２３は、薬剤師からの入力操作を受け付けるための入力装置、及び、薬剤師に対し情報を提示するための出力装置とのインタフェースとして機能する。メモリ２５は、プログラム、及び、プログラム等で処理されるデータ等を一時的に記憶するためのものであり、例えばＤＲＡＭ（DynamicRandomAccessMemory）等の揮発性のメモリである。ストレージ２６は、データを保存するための記憶装置であり、例えばフラッシュメモリ、ＨＤＤ（HardDiscDrive）である。プロセッサ２９は、プログラムに記述された命令セットを実行するためのハードウェアであり、演算装置、レジスタ、周辺回路などにより構成される。

＜１．１ 端末装置１０の構成＞
図２は、第１の実施の形態のシステム１を構成する端末装置１０のブロック図である。図２に示すように、端末装置１０は、通信部１２０と、操作受付部１３０と、表示部１６０と、記憶部１７０と、制御部１８０と、を含む。端末装置１０は、図２において特に図示していない機能及び構成（例えば、電力を保持するためのバッテリー、バッテリーから各回路への電力の供給を制御する電力供給回路など）も有している。図２に示すように、端末装置１０に含まれる各ブロックは、バス等により電気的に接続される。

通信部１２０は、端末装置１０が他の機器と通信するため、ネットワーク８０を介してサーバ２０と通信可能に接続される。

操作受付部１３０は、薬剤師の入力操作を受け付けるための機構を有する。例えば、操作受付部１３０は、マウス、キーボード又はタッチパネルなどを含む。

表示部１６０は、制御部１８０の制御に応じて、画像、動画、テキストなどのデータを表示する。表示部１６０は、例えば液晶ディスプレイによって実現される。

記憶部１７０は、例えばフラッシュメモリ等により構成され、端末装置１０が使用するデータ及びプログラムを記憶する。ある局面において、記憶部１７０は、処方箋情報１７１と、患者情報１７２とを記憶する。

処方箋情報１７１は、医師によって患者に対して薬剤を処方する処方箋の内容を示す情報である。端末装置１０は、ネットワーク８０を介して、薬剤師から、処方箋の内容を入力する操作を受け付ける。又は、端末装置１０は、医療機関の端末から、患者へ処方する処方箋の内容を示す情報を取得することとしてもよい。

患者情報１７２は、患者の氏名、連絡先、薬剤の服用状況など患者に関する情報である。端末装置１０は、ネットワーク８０を介して、薬剤師から、患者の情報を入力する操作を受け付ける。また、端末装置１０は、サーバ２０から、患者の情報を取得してもよい。

制御部１８０は、記憶部１７０に記憶されるプログラムを読み込んで、プログラムに含まれる命令を実行することにより、端末装置１０の動作を制御する。制御部１８０は、プログラムに従って動作することにより、入力操作受付部１８１と、送受信部１８２と、表示制御部１８３と、通知制御部１８４としての機能を発揮する。

入力操作受付部１８１は、マウス、キーボード等の入力装置に対する薬剤師の入力操作を受け付ける処理を行う。

送受信部１８２は、端末装置１０において、サーバ２０等の外部の装置と、通信プロトコルに従ってデータを送受信するための処理を行う。

表示制御部１８３は、表示部１６０の表示処理を制御する。例えば、表示制御部１８３は、表示部１６０の表示処理を制御する。例えば、表示制御部１８３は、ビデオメモリの内容を読み取ってディスプレイで表示させるための信号を生成してディスプレイに送出するように制御する。

通知制御部１８４は、薬剤師に対して通知される情報を提示する処理を行う。通知制御部１８４は、通知される情報を表示部１６０に表示させる処理等を行う。

＜１．２ サーバ２０の機能的な構成＞
図３は、第１の実施の形態のシステム１を構成するサーバ２０の機能的な構成を示す図である。図３に示すように、サーバ２０は、通信部２０１と、記憶部２０２と、制御部２０３としての機能を発揮する。

通信部２０１は、サーバ２０において外部の装置と通信するための処理を行う。

記憶部２０２は、サーバ２０において使用するデータ及びプログラムを記憶する。記憶部２０２は、処方箋データベース２８１と、リマインドデータベース２８２と、連絡履歴データベース２８３と、患者情報データベース２８４と、を記憶する。

処方箋データベース２８１は、薬局で受け付けた処方箋の情報を保持するためのデータベースである。詳細は後述する。

リマインドデータベース２８２は、薬剤の交付を可能とする期間を患者へ薬剤師により通知する内容を保持するためのデータベースである。詳細は後述する。

連絡履歴データベース２８３は、薬剤師が患者又は他の薬剤師のうち少なくともいずれかへ連絡した履歴を保持するためのデータベースである。詳細は後述する。

患者情報データベース２８４は、患者の情報を保持するためのデータベースである。具体的には、患者情報データベース２８４は、患者の情報として、患者の連絡先に関する情報、及び、薬剤の服用状況を示す情報を保持するためのデータベースである。詳細は後述する。

制御部２０３は、サーバ２０のプロセッサがプログラムに従って処理を行うことにより、各種モジュールとして示す機能を発揮する。

受信制御モジュール２０３１は、サーバ２０において外部の装置から通信プロトコルに従って信号を受信する処理を制御する。

送信制御モジュール２０３２は、サーバ２０において外部の装置に対し通信プロトコルに従って信号を送信する処理を制御する。

受付モジュール２０３３は、サーバ２０がネットワーク８０を介して、情報の入力及び登録を受け付ける処理を制御する。受付モジュール２０３３は、例えば、ユーザから情報の登録を受け付けることとして、以下を行う。
・薬剤師が入力した処方箋情報の登録を受け付けること。
・患者が入力した薬局への来局予定に関する情報の登録を受け付けること。

使用回数判定モジュール２０３４は、受付モジュール２０３３によって受け付けた処方箋の情報に基づいて、患者が当該処方箋を再度使用できる回数を判定する処理を制御する。使用回数判定モジュール２０３４は、サーバ２０がネットワーク８０を介して、薬剤師から入力を受け付けた処方箋の使用が可能である回数に基づいて、当該処方箋を再度利用できる回数を判定してもよい。

演算モジュール２０３５は、サーバ２０がネットワーク８０を介して、受付モジュール２０３３によって受け付けた情報に基づき、端末装置１０及び端末装置３０へ情報を出力するために演算する処理を制御する。演算モジュール２０３５は、例えば、受付モジュール２０３３によって受け付けた処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、処方箋情報に基づき、患者へ薬剤を交付する時期、及び、薬剤を交付する時期の到来を通知するためのリマインド時期を算出する。演算モジュール２０３５は、例えば、処方箋データベース２８１の処方箋の受付日及び服用期間に基づき、患者へ薬剤を交付する時期、及び、薬剤を交付する時期の到来を通知するためのリマインド時期を算出する。演算モジュール２０３５による患者へ薬剤を交付する時期、及び、リマインド時期の算出方法については、後述する。

提示モジュール２０３６は、サーバ２０がネットワーク８０を介して、ユーザへ情報を提示する処理を制御する。提示モジュール２０３６は、例えば、演算モジュール２０３５によって演算した患者の次回の来局時期、及び、薬剤師による患者に対するリマインド時期を端末装置１０の表示部１６０に画面として表示させるための信号をこの端末装置１０に送信する処理を制御する。
＜２．データ構造＞

図４は、サーバ２０の記憶する処方箋データベース２８１と、リマインドデータベース２８２と、連絡履歴データベース２８３と、患者情報データベース２８４のデータ構造を示す図である。

処方箋データベース２８１は、薬局において受け付けた処方箋の情報を保持するためのデータベースである。図４に示すように、処方箋データベース２８１のレコードのそれぞれは、項目「受付ID」と、項目「処方箋ＩＤ」と、項目「処方日」と、項目「受付日」と、項目「薬局ＩＤ」と、項目「患者ＩＤ」と、項目「発行元ＩＤ」と、項目「薬剤」と、項目「処方量」と、項目「服用期間」と、項目「使用可能回数」と、項目「残回数」と、項目「次回薬剤交付期間」と、項目「中止日時」と、項目「医師連絡日」を含む。サーバ２０は、例えば、医療機関で患者に対して発行される処方箋の情報を受付モジュール２０３３により受け付けることにより、処方箋データベース２８１にレコードを追加する。サーバ２０は、例えば、端末装置１０において薬剤師から処方箋情報を入力することを受付モジュール２０３３により受け付けることにより、処方箋データベース２８１にレコードを追加するとしてもよい。

項目「受付ＩＤ」は、患者から処方箋を受け付けた履歴それぞれを識別する情報である。例えば、サーバ２０は、端末装置１０において薬剤師から処方箋情報を入力することを受付モジュール２０３３により受け付けることに対応して、受付ＩＤを発行するとしてもよい。サーバ２０は、同一の処方箋を複数回数にわたって受け付ける場合に、処方箋を受け付けるごとにそれぞれ受付IDを発行することとしてもよい。

項目「処方箋ID」は、患者から受け付ける処方箋の情報を識別する情報である。サーバ２０は、同一の処方箋に対しては同一の処方箋IDを発行する。

項目「処方日」は、項目「処方箋ＩＤ」により識別される処方箋の発行年月日を示す情報である。

項目「受付日」は、薬局で処方箋情報を受け付けた年月日を示す情報である。

項目「薬局ＩＤ」は、薬局それぞれを識別する情報である。

項目「患者ＩＤ」は、患者それぞれを識別する情報である。

項目「発行元ＩＤ」は、項目「処方箋ＩＤ」により識別される処方箋を発行する医療機関それぞれを識別する情報である。

項目「薬剤」は、項目「処方箋ＩＤ」により識別される患者へ処方されるそれぞれの薬剤を示す情報である。

項目「処方量」は、項目「患者ＩＤ」により識別される患者へ処方される薬剤の量を示す情報である。具体的には、項目「処方量」は、処方箋に記載されている情報に基づき、薬剤師から入力を受け付けた情報である。項目「処方量」は、例えば、医療機関で患者に対して発行される処方箋のデータをサーバ２０によって取得した場合に、当該処方箋情報に示される情報である。

項目「服用期間」は、項目「患者ＩＤ」により識別される薬剤を服用する期間を示す情報である。具体的には、項目「服用期間」は、処方箋に記載されている情報に基づき、薬剤師から入力を受け付けた情報である。項目「服用期間」は、例えば、医療機関で患者に対して発行される処方箋のデータをサーバ２０によって取得した場合に、当該処方箋情報に示される情報である。

項目「使用可能回数」は、処方箋の使用が可能な回数を示す情報である。具体的には、項目「使用可能回数」は、医療機関で患者に対して処方箋が発行される際に、医師によって決定される情報であってもよい。

項目「残回数」は、サーバ２０が処方箋情報を取得した時点における、患者によって処方箋を再度使用できる残りの回数を示す情報である。具体的には、項目「残回数」は、医療機関で患者に対して発行される処方箋のデータに基づき算出された情報である。項目「残回数」は、例えば、薬局が患者から処方箋を受け付けることとしてサーバ２０が処方箋情報を取得した時点において、予め定められた処方箋を再度使用できる回数から、既に患者が薬剤師に対して処方箋の受け付けをした回数を減算した回数を示す情報である。また、具体的には、項目「残回数」は、処方箋を再度使用できる残りの回数を示す情報として、薬剤師から操作入力を受け付けた情報であってもよい。

項目「次回薬剤交付期間」は、患者によって処方箋を再度使用できる場合において、次に薬剤の交付を可能とする期間を示す情報である。具体的には、項目「次回薬剤交付期間」は、薬剤師から入力を受け付けた処方箋の情報に基づき算出するとしてもよい。薬剤の交付期間の詳細な算出方法については後述する。

項目「中止日時」は、医師と薬剤師とのうち少なくともいずれかが患者に対して処方箋の再度の使用を判断した日時を示す情報である。
具体的には、項目「中止日時」は、患者の来局時に観察した患者の体調又は患者による薬剤の服薬状況に基づき、患者に対して処方箋の再度の使用を中止すると薬剤師が判断した場合において、中止の入力を薬剤師から受け付けた日時を記憶してもよい。項目「中止日時」は、診察した患者の体調に基づき患者に対して処方箋の再度の使用を中止すると医師が判断した場合において、中止の入力を医師から受け付けた日時を記憶してもよい。具体的には、項目「中止日時」は、患者に対して処方箋の再度の使用を中止すると判断する通知を医師から薬剤師へ送信して、通知を受けた薬剤師から通知を確認した日時を記憶してもよい。

項目「医師連絡日」は、処方箋を発行した医師に対して、薬剤師から連絡した日を示す情報である。具体的には、項目「医師連絡日」は、薬剤師から患者に対して、処方箋の再度の使用を中止した場合において、医師へ連絡した日を示す情報である。項目「医師連絡日」は、処方箋を発行した医師が薬剤師に対して連絡した日を示す情報であってもよい。項目「医師連絡日」は、医師から患者に対して、処方箋の再度の使用を中止した場合において、医師が薬剤師へ連絡した日を示す情報であってもよい。

リマインドデータベース２８２は、薬剤師によって、薬剤の交付を可能とする期間を患者へ通知する内容を保持するためのデータベースである。図４に示すように、リマインドデータベース２８２のレコードのそれぞれは、項目「リマインドＩＤ」と、項目「受付ＩＤ」と、項目「残回数」と、項目「次回薬剤交付期間」と、項目「リマインド予定日」と、項目「再リマインド予定日」を含む。サーバ２０は、例えば、処方箋情報を受付モジュール２０３３により受け付けて、取得した処方箋情報に基づいて患者へリマインドを通知する時期を決定することにより、リマインドデータベース２８２にレコードを追加する。

項目「リマインドＩＤ」は、患者に対して行う、リマインド予定のそれぞれを識別する情報である。

項目「受付ＩＤ」は、患者から処方箋を受け付けた履歴それぞれを識別する情報である。例えば、薬剤師が患者から処方箋を受け付けることとして、サーバ２０は、端末装置１０を介して受信した処方箋情報を登録することに対応して、受付ＩＤを発行することとしてもよい。サーバ２０は、同一の処方箋を複数回数にわたって受け付ける場合に、処方箋を受け付けるごとにそれぞれIDを発行することとしてもよい。項目「受付ＩＤ」は、処方箋データベース２８１の項目「受付ＩＤ」と共通である。

項目「残回数」は、サーバ２０が処方箋情報を取得した時点における、患者によって処方箋を再度使用できる残りの回数を示す情報である。具体的には、項目「残回数」は、医療機関で患者に対して発行される処方箋のデータに基づき算出された情報である。項目「残回数」は、例えば、サーバ２０が処方箋情報を取得した時点において、予め定められた処方箋を再度使用できる回数から、既に患者が薬剤師に対して処方箋の受け付けをした回数を減算した回数を示す情報である。また、具体的には、項目「残回数」は、処方箋を再度使用できる残りの回数を示す情報として、薬剤師から入力操作を受け付けた情報であってもよい。

項目「次回薬剤交付期間」は、患者によって処方箋を再度使用できる場合において、次に薬剤の交付を可能とする期間を示す情報である。薬剤の交付期間の詳細な算出方法については後述する。

項目「リマインド予定日」は、次の薬剤の交付期間に基づいて、患者へリマインドする予定日を示す情報である。具体的には、項目「リマインド予定日」は、例えば、次の薬剤の交付期間の開始日から所定期間前のリマインド予定日を示す情報である。

項目「再リマインド予定日」は、リマインド予定日を複数設ける場合における、項目「リマインド予定日」と別の予定日を示す情報である。具体的には、項目「再リマインド予定日」は、次の薬剤の交付期間の終了日から所定期間前のリマインド予定日を示す情報である。項目「再リマインド予定日」は、例えば、当該再リマインド予定日の到来までに患者が来局しなかった場合において、患者に対して再度リマインドを通知する予定日、としてもよい。

連絡履歴データベース２８３は、薬剤師から患者又は他の薬剤師のうち少なくともいずれかへ連絡した履歴を保持するためのデータベースである。図４に示すように、連絡履歴データベース２８３のレコードのそれぞれは、項目「連絡ＩＤ」と、項目「担当ＩＤ」と、項目「受付ＩＤ」と、項目「リマインド日時」と、項目「リマインド内容」と、項目「回答日時」と、項目「回答内容」と、項目「情報送信日」を含む。サーバ２０は、提示モジュール２０３６が患者に対してリマインドを通知したことに応答して、リマインドIDを生成して、連絡履歴データベース２８３にレコードを追加する。サーバ２０は、例えば、演算モジュール２０３５によって患者へのリマインドのタイミングが到来したことを判定して、提示モジュール２０３６から患者へリマインド通知をしたことにより、データを連絡履歴データベース２８３に格納する。サーバ２０は、さらに、受付モジュール２０３３においてリマインド通知に対する回答を患者から受け付けたことにより、受け付けたデータを連絡履歴データベース２８３に格納する。

項目「連絡ＩＤ」は、薬剤師から患者に対して実際に連絡した履歴それぞれを識別する情報である。

項目「担当ＩＤ」は、項目「連絡ＩＤ」により識別される連絡において、患者への連絡を担当した薬剤師それぞれを識別する情報である。

項目「受付ＩＤ」は、患者から処方箋を受け付けた履歴それぞれを識別する情報である。例えば、薬剤師が患者から処方箋を受け付けることとして、サーバ２０は、端末装置１０を介して受信した処方箋情報を登録することに対応して、受付ＩＤを発行することとしてもよい。サーバ２０は、同一の処方箋を複数回数にわたって受け付ける場合に、処方箋を受け付けるごとにそれぞれIDを発行することとしてもよい。
項目「受付ＩＤ」は、処方箋データベース２８１、及び、リマインドデータベース２８２の項目「受付ＩＤ」と共通である。

項目「リマインド日時」は、薬剤師から患者へリマインドを通知した日時を示す情報である。

項目「リマインド内容」は、薬剤師から患者へリマインドを通知する内容を示す情報である。具体的には、項目「リマインド内容」は、患者の次の薬剤の交付期間、及び薬剤の交付期間の到来を知らせるための内容を示す情報である。項目「リマインド内容」は、例えば、薬剤の交付期間の到来を知らせるために薬剤師が患者にリマインドした内容を示す情報である。

項目「回答日時」は、患者の受け付けたリマインド通知に対する回答を患者から薬剤師へ通知した日時を示す情報である。

項目「回答内容」は、患者の受け付けたリマインド通知に対して患者から薬剤師へ回答した内容を示す情報である。

項目「情報送信日」は、薬剤師から他の薬局へ情報を送信した日を示す情報である。具体的には、項目「情報送信日」は、患者から別の薬局で薬剤の交付を受ける旨の通知のあった場合において、当該別の薬局へ患者の情報を送信した日を示す情報である。

患者情報データベース２８４は、患者の情報を保持するためのデータベースである。患者情報データベース２８４は、患者自身の情報と、患者の服薬情報とを保持するためのデータベースである。患者情報データベース２８４は、例えば、患者の氏名、連絡先、薬剤の服用状況などを示す情報を保持するためのデータベースである。図４に示すように、患者情報データベース２８４のレコードのそれぞれは、項目「患者ＩＤ」と、項目「患者氏名」と、項目「性別」と、項目「年齢」と、項目「連絡先」と、項目「ステータス」と、項目「特記事項」を含む。患者情報データべース２８４のレコードのそれぞれは、患者から薬剤の交付を受け付けた際に薬剤師が登録を行ってもよい。サーバ２０は、端末装置１０において薬剤師から患者の情報を入力することを受付モジュール２０３３により受け付けることにより、患者情報データベース２８４にレコードを追加するとしてもよい。

項目「患者ＩＤ」は、患者それぞれを識別する情報である。項目「患者ＩＤ」は、処方箋データベース２８１の項目「患者ＩＤ」と共通である。

項目「患者氏名」は、患者の氏名を示す情報である。

項目「性別」は、項目「患者ＩＤ」により識別される患者の性別を示す情報である。

項目「年齢」は、項目「患者ＩＤ」により識別される患者の年齢を示す情報である。

項目「連絡先」は、項目「患者ＩＤ」により識別される患者の連絡先を示す情報である。

項目「ステータス」は、薬剤師による患者への薬剤の交付状況を示す情報である。具体的には、項目「ステータス」は、患者に対して薬剤の交付期間が到来していることを示す情報と、患者の来局予定を示す情報とのうちの少なくともいずれかに関する情報である。

項目「特記事項」は、患者に関する特筆すべき事項を示す情報である。具体的には、項目「特記事項」は、患者による処方箋の再度の使用を中止して、医療機関を受診する判断をするための条件を示す情報であってもよい。項目「特記事項」は、患者へ処方箋を発行した医師から提示された情報であってもよい。項目「特記事項」は、薬剤師から端末装置１０を介して入力を受け付けた情報であってもよい。
＜３．動作＞

以下、図５から図８を参照しながら、システム１により、薬剤師による患者に対しての薬剤の説明を支援する処理について説明する。

図５は、第１の実施の形態におけるシステム１により、患者へ薬剤の交付を可能とする時期を算出して、ユーザへ提示する流れの一例を示すフローチャートである。ここでいうユーザは、薬剤師と患者とのうち少なくともいずれかである。以下、ユーザとして薬剤師の例で説明する。

ここで、本システム１は、１の処方箋において複数回数の薬剤の交付を可能とする処方箋を対象とするシステムである。一例として、複数回数の薬剤の交付を可能とする処方箋は、リフィル処方箋である。複数回数の薬剤の交付を可能とする処方箋とは、予め規定された回数の上限に到達するまで、患者が再度医療機関を受診することなく、複数回にわたり薬剤の交付を受けることができる処方箋のことをいう。１の処方箋で薬剤の交付を可能とする回数は、医療機関で処方箋が発行される際に医師によって決定されてもよい。以下、複数回数の薬剤の交付を可能とする処方箋を対象に説明する。

ステップS５１１において、端末装置１０は、薬剤師から処方箋の情報を入力する操作を受け付ける。端末装置１０は、処方箋の情報を入力することとして、例えば、患者から処方箋を受け付けた日、処方箋に記載されている薬剤の種類、処方日、処方日数、患者名、及び、当該処方箋において処方可能な回数に関する情報を入力する操作を薬剤師から受け付ける。端末装置１０は、Ｓ５１１で薬剤師による操作入力を介して受け入れた情報を通信部１２０などを介してサーバ２０に送信する

ステップS５２１において、サーバ２０は、ステップS５１１で受け付けた処方箋の情報に基づき、薬剤の交付を可能とする時期を算出する。ステップS５２１において、サーバ２０は、当該処方箋により患者へ再度の薬剤の交付を可能とするか判定する。判定方法は、例えば、以下であってもよい。
・処方箋の使用可能回数が、既に薬局が患者から処方箋を受け付けた回数より多い場合、患者へ再度の薬剤の交付を可能とすると判定する。
サーバ２０は、既に薬局が患者から処方箋を受け付けた回数を特定することとして、例えば、以下のいずれかのように特定してもよい。
・既に薬局が患者から処方箋を受け付けた回数について薬剤師から入力を受け付ける。
・処方箋データベース２８１を参照することにより、当該処方箋と同一の処方箋を受け付けた回数を特定する。例えば、サーバ２０は、処方箋データベース２８１に格納されている各レコードについて、項目「処方箋ID」が一致するレコードを抽出する。サーバ２０は、抽出したレコードを同一の処方箋を受け付けたレコードであると特定する。サーバ２０は、抽出したレコードの数を積算することにより、既に処方箋を受け付けた回数を特定する。
サーバ２０は、算出した処方箋の使用可能な残回数を、処方箋データベース２８１に登録する。

なお、ステップS５２１において、当該処方箋による再度の薬剤の交付を可能とするか否かについては、上記のようにサーバ２０によって判定する他に、入力する操作を薬剤師から受け付けてもよい。薬剤師は、患者から受け付けた処方箋の情報に基づき再度の薬剤の交付を可能とするか否かについて判断してもよい。端末装置１０は、薬剤師によって判断された結果を入力する操作を薬剤師から受け付けてもよい。

さらに、ステップ５２１において、再度の薬剤の交付を可能とすると判定した場合に、サーバ２０は、薬剤の交付を可能とする時期を算出する。ステップS５２１において、サーバ２０は、薬剤の交付を可能とする時期を算出する方法として、ステップS５１１で受け付けた情報である、患者から処方箋を受け付けた日、及び、処方日数に基づいて時期を算出する。サーバ２０は、例えば、薬剤の交付を受け付けた日を起算日として、起算日に処方日数を加算した日付を次回の薬剤の交付日として特定する。サーバ２０は、さらに、特定した次回の薬剤の交付日を基準日として、当該基準日を含み、基準日より一定期間前と、一定期間後とのうち少なくともいずれかの所定の期間を、薬剤の交付を可能とする時期として決定する。

ステップS５２２において、サーバ２０は、ステップS５２１で算出した薬剤の交付を可能とする時期に基づき、患者へのリマインド日を決定する。サーバ２０は、例えば、ステップS５２１において特定した薬剤を交付する時期の開始日を起算日として、起算日の一定期間前のタイミングをリマインド日として決定する。サーバ２０は、例えば、ステップS５２１において特定した次回の薬剤を交付する時期の開始日を起算日として、起算日の３日前のタイミングをリマインド日として決定する。さらに、ステップS５２２において、サーバ２０は、決定したリマインド日を薬剤師に提示する。サーバ２０は、例えば、決定したリマインド日を患者へ提示するとしてもよい。ステップS５２２において、サーバ２０は、リマインド日が決定したことに応答して、リマインドデータベース２８２にレコードを追加してもよい。

ステップS５２３において、サーバ２０は、ステップS５２１で算出した薬剤の交付を可能とする時期、及び、ステップS５２２において決定したリマインド日を薬剤師へ提示する。ここで、サーバ２０は、ステップS５２１で算出した薬剤の交付を可能とする時期、及び、ステップS５２２において決定したリマインド日を、患者へ提示してもよい。

ステップS５２４において、サーバ２０は、次回の薬剤を交付する時期の開始日より一定期間前のタイミングになったと判断して、一定期間後に到来する薬剤の交付を可能とする時期を患者が所有する端末装置３０に通知する。サーバ２０は、演算モジュール２０３５によって、現在の日付とリマインドデータベース２８２のリマインド予定日とを比較し、両者が致した場合に「リマインド日の到来」であると判定する。サーバ２０は、例えば、リマインドデータベース２８２に格納されているデータに基づき、リマインド日の到来を判定して、一定期間後に到来する薬剤の交付を可能とする時期を患者の端末装置３０に通知するとしてもよい。サーバ２０は、リマインド日の到来を判定して操作部材を端末装置１０の表示部１６０に表示させてもよい。サーバ２０は、操作部材を操作する入力を薬剤師から受け付けることに応答して、一定期間後に到来する薬剤の交付を可能とする時期を患者の端末装置３０に通知するとしてもよい。

ステップS５２４において、サーバ２０は、端末装置３０への通知方法として、たとえば、患者のメールアドレス、又は、ＳＭＳ（ShortMessageService）によってリマインドを通知してもよい。また、サーバ２０は、通知する手段として、患者が利用するＳＮＳ（SocialNetworkService）との連携により、リマインドを通知してもよい。ここで、患者が利用するＳＮＳのＩＤなどは、サーバ２０で管理してもよい。薬剤師は、リマインドを通知する患者を指定することはできるが、患者のＳＮＳのＩＤ等を閲覧することはできない構成にしてもよい。さらに、サーバ２０は、自動音声通話によって患者に連絡してもよい。

ステップS５３１において、端末装置３０は、ステップS５２４でサーバ２０から受け付けた通知を受信したら、薬剤の交付を受ける予定に関する情報の操作入力を患者から受け付ける。端末装置３０は、例えば、薬局へ来局する日時を示す情報の入力を患者から受け付けてもよい。端末装置３０は、例えば、患者の来局予定である薬局を示す情報の入力を患者から受け付けてもよい。端末装置３０はステップＳ５３１で患者から受け入れた情報をサーバ２０に送出する。サーバ２０は、ステップS５３１において端末装置３０が入力を受け付けた情報を、連絡履歴データベース２８３に登録する。

端末装置３０が、薬剤の交付を受ける予定の入力を患者から受け付けることは必須ではなく、この入力を受け入れない構成も可能である。この場合、患者は、例えば、来局予定を薬局に通知することなく、薬局へ直接来局するとしてもよい。

ステップS５１２において、端末装置１０は、処方箋情報の操作入力を薬剤師から受け付ける。端末装置１０は、例えば、患者へ薬剤を交付した実績を示す情報の操作入力についても薬剤師から受け付けてもよい。端末装置１０は、例えば、患者へ薬剤を交付した日時と、交付した薬剤の種類及び量とのうち少なくともいずれかを示す情報の入力を薬剤師から受け付ける。

また、ステップS５１２において、端末装置１０は、次の薬剤の交付を可能とする時期、及び、患者に対するリマインド日を決定して、薬剤師に提示してもよい。端末装置１０は、例えば、当該処方箋において薬剤の交付を可能とする回数と、これまでに薬局で当該処方箋による薬剤の交付を受け付けた回数の情報に基づき、当該処方箋による再度の薬剤の交付を可能とするか否かを判断する。サーバ２０は、再度の薬剤の交付を可能とすると判定した場合において、次の薬剤の交付を可能とする時期、及び、患者に対するリマインド日を決定して、薬剤師に提示してもよい。

上記一連の処理により、複数回数の薬剤の交付を可能とする処方箋において、薬剤の交付を可能とする時期を算出して薬剤師へ提示することにより、薬剤師は、患者に対する服薬支援をよりいっそう充実化させることを可能とする。また、薬剤師は、患者への説明負担を低減できる。さらに、患者へ薬剤の交付についてリマインドを通知することにより、患者の来局の可能性が高くなることを期待でき、薬剤師が個別にリマインドする必要性を低下させることができる。また、患者は、リマインド通知を受けることにより、薬剤の受け取りを忘れることを低減できるため、安定して服薬を継続できる。

図６は、第１の実施の形態におけるシステム１により、複数回数の薬剤の交付を可能とする処方箋において、薬剤を交付した回数が、予め規定された処方箋の使用可能な回数の上限に到達した場合における、システム１の処理の一例を示すフローチャートである。なお、ステップS５１１は、図５と同様の内容のため、説明を繰り返さない。

ステップS６２１において、サーバ２０は、ステップS５１１で受け付けた処方箋の情報に基づき、患者へ再度の薬剤の交付を可能とするか否かを判定する。ステップS６２１において、サーバ２０は、処方箋データベース２８１の項目「使用可能回数」と、項目「処方箋ID」を参照する。サーバ２０は、例えば、当該処方箋において薬剤の交付を可能とする回数と、当該処方箋による薬剤の交付を既に受け付けた回数に基づき、当該処方箋による再度の薬剤の交付を可能とするか判定する。例えば、処方箋の使用可能回数と、当該処方箋による薬剤の交付を既に受け付けた回数が一致する場合において、サーバ２０は、当該処方箋の使用可能である残回数が０であると判定する。サーバ２０は、例えば、当該処方箋において薬剤の交付を可能とする回数と、当該処方箋による薬剤の交付を既に受け付けた回数が同じである場合において、ステップS５１１において受け付けた薬剤の交付が当該処方箋における最終の薬剤の交付であると判定する。なお、当該処方箋による薬剤の交付を既に受け付けた回数の算出方法については、図５のステップS５２１で説明した方法と同じであってよい。

ステップS６２２において、サーバ２０は、ステップS６２１における判定に応答して、病院を受診する目安を患者へ示すための情報を生成する。サーバ２０は、例えば、病院を受診する目安を患者へ示すための情報を生成することとして、患者が服薬している薬剤の尽きるタイミングを示す情報を生成してもよい。また、サーバ２０は、例えば、体調の変化を示す情報を生成してもよい。サーバ２０は、例えば、処方箋データベース２８１と、患者情報データベース２８４とのうち少なくともいずれかを参照して、上記の病院を受診する目安を患者へ示すための情報を生成してもよい。サーバ２０は、例えば、薬剤の尽きるタイミングを以下のように算出して情報を生成してもよい。
・処方箋の受付日を起算日として、薬剤の服用期間を起算日に加算する。
サーバ２０は、例えば、体調の変化を示す情報を生成することとして、患者情報データベース２８４から患者に関する特記事項を示す情報を抽出するとしてもよい。

ステップS６２３において、サーバ２０は、ステップS６２１で判定した、処方箋の使用可能な残数の無い旨、及び、ステップS６２２において生成した情報を端末装置１０に送出し、この端末装置１０を介して薬剤師へ提示する。

上記一連の処理により、薬剤師は、患者の薬剤の服薬状況をよりいっそう容易に把握できることを可能とする。薬剤師は、患者から処方箋を受け付けるタイミングにおいて、薬局のディスプレイに表示された処方箋の使用可能である残回数を把握できるため、患者に対して服薬指導を適切に行うことができる。また、患者は、薬剤師から説明を受けることにより処方箋の使用可能である残回数を把握できるため、誤って再度薬局へ来局してしまう可能性を低減できる。
＜画面例＞

図７から図８は、第１の実施の形態における、ユーザの端末装置１０又は３０の画面例を示す図である。図７は、第１の実施の形態における、ユーザである薬剤師の端末装置１０の画面例を示す図である。図７は、図５のステップS５１１において、端末装置１０が薬剤師から情報の操作入力を受け付ける画面を示す図である。

図７に示すように、端末装置１０の表示部１６０に表示された表示画面１３１は、領域１３２と、領域１３３と、領域１３４と、領域１３５と、操作部材１３６とを含む。領域１３２は、患者の個人情報を表示するための領域である。領域１３３は、処方箋情報の入力を薬剤師から受け付けるための領域である。薬剤師は、表示画面１３１の領域１３３に該当する部分に、入力装置１３であるキーボードなどを介して処方箋情報を入力する操作を行う。端末装置１０は、領域１３３に該当する部分において操作入力があったことを検出して、薬剤師からの操作入力を受け付けてもよい。表示部１６０がタッチパネルである場合において、薬剤師は、表示画面１３１の領域１３３に該当する部分をタッチ又はクリックする操作を行う。端末装置１０は、領域１３３に該当する部分において操作入力があったことを検出して、薬剤師からの操作入力を受け付けてもよい。領域１３４は、再度の薬剤の交付を可能とする期間、及び患者へリマインドを通知する予定日を表示するための領域である。操作部材１３６は、患者の過去の来局履歴を閲覧するための操作入力を受け付ける操作部材である。

図７の画面例において、端末装置１０が領域１３３において薬剤師から操作入力を受け付けたことに応答して、サーバ２０は、薬剤の交付を可能とする時期、及び、患者へリマインドを通知する時期を端末装置１０のディスプレイに表示させる。端末装置１０が処方箋の情報として患者から処方箋の受付日、及び、処方日数を示す情報の操作入力を薬剤師から受け付けたことに応答して、サーバ２０は、図７の領域１３４を端末装置１０のディスプレイに表示させる。

さらに、端末装置１０は、患者の同じ薬局への来局可能性について領域１３５に表示する。サーバ２０は、患者の同じ薬局への来局可能性を、患者の過去の来局履歴に基づいて評価する。サーバ２０は、例えば、処方箋データベース２８１、及び、連絡履歴データベース２８３を参照することにより、患者の同じ薬局への来局可能性を複数段階で評価する。サーバ２０は、患者の同じ薬局への来局可能性を複数段階で評価することとして、患者が過去に薬局へ来局した回数に対して、同じ薬局へ来局した回数の割合が高いほど、同じ薬局へ来局する可能性が高いと評価する。サーバ２０は、特に、患者が同じ薬局へ来局した回数に対して、さらに同一の処方箋で薬剤の交付を受けた回数の割合が高いほど、来局可能性を高く評価してもよい。サーバ２０は、評価結果を領域１３５に表示する。

また、薬剤師は、操作部材１３６をタッチ又はクリックする操作を行う。端末装置１０は、操作部材１３６に対して操作入力があったことを検知することにより入力を受け付ける。端末装置１０は入力を受け付けたことに応答して、端末装置１０の表示部１６０に表示する表示内容を、図７に示す内容から患者の来局履歴を表示する内容に遷移させる。これにより、薬剤師は患者の過去の来局履歴を参照できるため、当該患者の同じ薬局への来局可能性を精度よく把握することができる。したがって、薬剤師は、よりいっそう当該患者の来局可能性を薬剤の在庫管理に役立てることができる。

図８は、第１の実施の形態における、ユーザである患者の端末装置３０の画面例を示す図である。図８は、図５のステップS５２４において、サーバ２０から薬剤の交付時期の到来についての通知を受けた端末装置３０の画面を示す図である。

図８に示すように、端末装置３０の表示部に表示された表示画面１３１は、領域１３７と、操作部材１３８と、操作部材１３９とを含む。領域１３７は、患者への薬剤の交付に関するスケジュール情報を示す領域である。操作部材１３８は、薬剤の交付を受ける予定の操作入力を患者から受け付けるための操作部材である。操作部材１３９は、直近に薬剤の交付を受けた薬局と異なる薬局へ来局する予定を入力する操作を患者から受け付けるための操作部材である。

操作部材１３８は、薬剤の交付を受ける予定の操作入力を患者から受け付ける。操作部材１３８は、例えば、図５のステップS５３１において、薬剤の交付を受ける予定を入力する操作を患者から受け付けてもよい。例えば、患者が直近に薬剤の交付を受けた薬局と同じ薬局で薬剤の交付を受ける予定である場合に、操作部材１３８は、当該薬局へ来局する予定の入力操作を患者から受け付けてもよい。端末装置３０は、例えば、ディスプレイに表示する表示内容を、図８に示す内容から、薬剤の交付を受ける予定を登録するための表示内容に遷移するための操作として、患者から操作部材１３８を押下する操作を受け付けてもよい。

操作部材１３９は、領域１３７に表示された薬局と異なる薬局へ来局する予定の操作入力を患者から受け付けてもよい。患者が異なる薬局へ来局するケースは、実施の形態２で説明する。

上記のように、サーバ２０が薬剤の交付を可能とする期間の到来を患者へ提示することにより、患者は、薬剤の受け取りを忘れることを低減できる。そのため、患者は安定して服薬を継続できる。また、薬剤師は、薬局へ来局する予定の通知を患者から受けるため、患者の来局予定の把握、及び薬剤の在庫管理が可能となる。

＜変形例＞
以上のように、サーバ２０が薬剤の交付を可能とする時期及び患者へのリマインド日を決定してユーザに提示する技術について説明した。この他に、以下のように構成してもよい。

処方箋情報を受け付ける方法：図５のステップS５１１について、サーバ２０は、処方箋情報を以下のように受け付けてもよい
・処方箋情報がQRコード（登録商標）等の二次元コードの状態で端末装置に表示されているか、又はQRコード（登録商標）等の二次元コードの状態で処方箋の書面に記載されているかの少なくともいずれかである場合、読み取り装置によって二次元コードを読み取る。二次元コードを介して読み取った情報をサーバ２０が取得する。
・スキャナ又はデジタルカメラの少なくともいずれかによって処方箋情報を読み取り、処方箋に記載された文字を文字コードに変換した情報をサーバ２０が取得する。
・処方箋を発行した医療機関の端末を介して受信した処方箋情報をサーバ２０が受け付ける。
・医療機関から発行された処方箋の情報がサーバに蓄積されており、端末装置１０が当該サーバへアクセスすることにより処方箋の情報を取得する。

リマインド日の複数設定：図５のステップS５２２において、サーバ２０は、患者へのリマインド日を複数設定してもよい。例えば、薬剤の交付を可能とする時期が複数日にわたって設定されている場合において、サーバ２０は、薬剤の交付を可能とする時期の一定期間前のタイミングを第１のリマインド日として設定してもよい。さらに、サーバ２０は、薬剤の交付を可能とする時期の開始後、終了前のタイミングを第２のリマインド日として設定してもよい。第１のリマインド日以降、第２のリマインド日より前のタイミングで薬剤師から患者へ薬剤の交付があった場合、サーバ２０は、第２のリマインド日に設定されたリマインドを患者へ通知しなくてもよい。第１のリマインド日以降、第２のリマインド日より前のタイミングで薬剤師から患者へ薬剤の交付があった場合、端末装置１０は、図５のステップS５１２において、第２のリマインド日に設定されたリマインドを解除する操作入力を薬剤師から受け付けてもよい。

リマインド日及びリマインド内容の決定方法：図５のステップS５２２における患者へのリマインド日の決定について、サーバ２０は、患者の行動履歴に基づいてリマインド日を決定してもよい。サーバ２０は、例えば、処方箋データベース２８１と、リマインドデータベース２８２と、連絡履歴データベース２８３とのうち少なくともいずれかに格納されている情報を参照して、患者それぞれの行動履歴を特定してもよい。サーバ２０は、例えば、患者の行動履歴として、所定の曜日又は日付において来局頻度が高いとみられる患者に対して、所定の曜日又は日付の一定期間前をリマインド日として決定してもよい。サーバ２０は、例えば、患者の行動履歴として、薬剤の交付を受けることを忘れる頻度が高いとみられる患者に対して、リマインド回数をさらに増やすことを決定してもよい。サーバ２０は、患者が薬剤の交付を受けることを忘れた回数を判定するための方法として、以下のようにしてもよい。まず、サーバ２０は、同一の処方箋IDを有しているレコードのうち、受付日が最新のレコードを判定対象とする。サーバ２０は、判定対象であるレコードのうち、「残回数」の値が１以上であるレコードを抽出する。サーバ２０は、抽出したレコードのうち「次回薬剤交付期間」が既に過ぎているレコードの数を積算する。サーバは、積算したレコードの数が、これまでに患者が薬剤の交付を受けることを忘れた回数を示すと判定してもよい。サーバ２０は、処方箋データベース２８１を参照して、患者が来局した回数に対して、患者が薬剤の交付を受けることを忘れたと判定した回数の割合が高い場合に、薬剤の交付を受けることを忘れる頻度が高いと判定してもよい。さらに、サーバ２０は、例えば、患者の行動履歴として、同じ薬局への来局可能性が低いとみられる患者に対して、リマインド通知の内容に当該患者の経過観察を示す情報を追加する決定をしてもよい。患者の同じ薬局への来局可能性の判定方法は、後述する。サーバ２０は、例えば、当該患者の経過観察を示す情報として、以下を追加する決定をしてもよい。
・過去の患者の来局時における、薬剤師によって患者へヒアリングした体調及び服薬状況。
・過去の患者の来局時における、薬剤師によって実施した患者の体調チェック結果。

サーバ２０は、リマインド日を次のように決定してもよい。サーバ２０は、患者から受けた通知の内容に基づいてリマインド日を決定してもよい。サーバ２０は、例えば、図５のステップS５３１において患者から入力を受け付けた内容である、患者が薬局へ来局する予定日に基づいてリマインド日を決定してもよい。サーバ２０は、患者が薬局へ来局する予定日の一定期間前をリマインド日として決定してもよい。

これにより、患者は、自身の行動履歴、及び、予定している来局日に応じたリマインド通知を薬剤師から受けることができるため、よりいっそう薬剤の受け取りを忘れることを低減できる。薬剤師は、患者の同じ薬局への来局可能性が高まることを期待できる。これにより、薬剤師は、継続して患者を経過観察できる可能性が高まる。

＜第２の実施の形態＞
以上の実施の形態の説明では、サーバ２０が、複数回数の薬剤の交付を可能とする処方箋において、薬剤の交付を可能とする時期、及び、患者へのリマインド時期を決定することについて説明した。以上の実施の形態の説明では、さらに、サーバ２０が、患者へ通知したリマインドに対する回答として、薬剤の交付を受ける予定についての通知を患者から受け付けることについて説明した。

以下の実施の形態では、患者へ通知したリマインドに対する患者の回答として、直近に薬剤の交付を受けた薬局と異なる薬局で患者が薬剤の交付を受ける旨の回答を患者から受け付けた場合におけるサーバ２０の処理について説明する。

図９は、第２の実施の形態における、直近に薬剤の交付を受けた薬局と異なる薬局で薬剤の交付を受ける旨の回答を患者から受け付けた場合の一例を示すフローチャートである。なお、ステップS５２４は、図５と同様の内容のため、説明を繰り返さない。また、図９の端末装置１０は、患者が来局する予定の薬局に設置された、あるいは薬局の薬剤師等により操作される端末装置であるとして、以下説明する。

ステップS９３１において、端末装置３０は、ステップS５２４でサーバ２０より受け付けた通知に対する回答として、直近に薬剤の交付を受けた薬局と別の薬局で薬剤の交付を受ける予定である回答の入力を患者から受け付ける。さらに、端末装置３０は、薬剤を受け取る予定の入力を患者から受け付けて通知する。ステップS９３１において、端末装置３０は、例えば、ディスプレイに表示する表示内容を、図８に示す内容から、薬剤の交付を受ける予定を登録するための表示内容に遷移するための操作として、患者から操作部材１３９を押下する操作を受け付けてもよい。端末装置３０は、例えば、来局予定の薬局を示す情報の入力を患者から受け付けてもよい。端末装置３０は、患者から入力を受け付けた情報をサーバ２０に送信する。

ステップS９２１において、サーバ２０は、ステップS９３１で端末装置３０が患者から受け付け、サーバ２０に送信した入力内容を登録する。サーバ２０は、端末装置３０から受信した入力内容を、リマインドデータベース２８２に登録してもよい。

ステップS９２２において、サーバ２０は、ステップＳ９３１で端末装置３０を介して指定された薬局に係る端末装置１０に対する、当該患者の服薬状況を表示するページのアクセス権を生成する。サーバ２０は、例えば、ステップＳ９３１で薬局を指定した当該患者について、図７の画面に表示されている、患者の服薬状況を表示するページへのアクセス権を生成する。サーバ２０は、例えば、ステップS９３１において患者から受け付けた情報から、患者が来局予定である薬局を特定する。サーバ２０は、特定した薬局の端末装置１０に対して、当該患者の服薬状況を表示するページが閲覧可能となる設定を行う。サーバ２０は、例えば、当該患者の服薬状況を表示するページの閲覧可能なIDが記憶されている記憶部のデータベースに、特定した薬局の端末装置１０のＩＤを追加する。サーバ２０は、アクセス権が付与された旨を、当該患者の来局予定である薬局の薬剤師に対して、端末装置１０を介して提示する。サーバ２０は、例えば、アクセス権が付与された旨を提示する他にも、以下のようにしてもよい。
・患者の服薬状況を表示するページにアクセスするためのパスワードを当該薬剤師に対して提示する。
・患者の服薬状況を表示するページのＵＲＬを当該薬剤師に対して提示する。

ステップS９１１において、端末装置１０は、患者の服薬状況を表示するページへアクセスする操作を当該薬剤師から受け付ける。

ステップS９２３において、サーバ２０は、ステップS９１１において当該薬剤師から操作を受け付けることに応答して、患者の情報を端末装置１０のディスプレイに表示させる。サーバ２０は、例えば、患者の服薬状況を表示するページを薬剤師へ提示する。

上記により、患者が同一の薬局で薬剤の交付を受けない場合であっても、当該患者へ薬剤を交付する予定の薬剤師は患者の薬剤の服用状況を示す情報を、他の薬剤師から共有してもらうことができる。したがって、薬剤師は、継続して患者を経過観察できる可能性が高まる。さらに、薬剤師は、各患者に対して患者の状況に合わせた服薬指導を行うことができる。

図１０は、第２の実施の形態における、患者の情報を他の薬剤師と共有するために、患者の端末装置３０を利用する場合の流れの一例を示すフローチャートである。なお、ステップS５２４、ステップS９３１、及び、ステップS９２１は、図９と同様の内容のため、説明を繰り返さない。また、図１０の端末装置１０は、当該患者が直近に薬剤の交付を受けた薬局の端末装置であるとして、以下説明する。

ステップS１０２１において、サーバ２０は、ステップS９２１で登録した情報に基づき、当該患者が別の薬局で薬剤の交付を受ける予定である旨の情報を端末装置１０へ通知する。サーバ２０は、例えば、患者が来局予定である別の薬局を示す情報を端末装置１０へ通知してもよい。サーバ２０は、例えば、患者が別の薬局へ来局する予定の日時を示す情報を端末装置１０へ通知してもよい。

ステップS１０１１において、端末装置１０は、当該患者について、別の薬局の薬剤師へ共有するための情報の入力を、直近に当該患者へ薬剤を交付した薬剤師から受け付ける。端末装置１０は、例えば、患者の服薬状況と、患者の体調を示す情報と、その他申し送り事項のうち少なくとも１以上の入力を薬剤師から受け付けてもよい。ステップS１０１１において、端末装置１０が別の薬局の薬剤師へ共有するための情報を薬剤師から受け付ける際に、端末装置１０は、ディスプレイに当該患者の服薬状況を示す情報を表示してもよい。そして、端末装置１０は、ステップＳ１０１１で受け付けた情報をサーバ２０に送信する。端末装置１０は、例えば、部材を押下する操作を薬剤師から受け付けることにより応答して、情報をサーバ２０へ送信する。

ステップS１０２２において、サーバ２０は、ステップS１０１１で端末装置１０によって薬剤師から入力を受け付けた情報を患者が所有する端末装置３０へ送信する。サーバ２０は、処方箋データベース２８１と、患者情報データベース２８４とのうちの少なくともいずれかから抽出した、当該患者の情報を端末装置３０へ送信してもよい。サーバ２０は、端末装置３０へ送信するための情報のうち、少なくとも一部の情報を二次元コードに記録して、この二次元コードを端末装置３０に表示させるためのデータを送信してもよい。

ステップS１０３１において、端末装置３０は、ステップS１０２２でサーバ２０から受信した情報を表示部に表示する。例えば、患者が薬剤の交付を受ける際に、端末装置３０は、情報を表示部に表示して、患者へ提示する。端末装置３０は、例えば、ステップS１０２２において生成した二次元コードを表示部に表示してもよい。

上記のように、薬剤師は、薬剤を交付する際に、患者の端末装置３０に表示される当該患者の服薬状況を示す情報を確認することができる。そのため、薬剤師は、患者のこれまでの服薬状況を把握することができ、患者それぞれに合わせた服薬指導が可能となる。また、薬剤師が患者の来局する薬局を把握できていない場合においても、薬剤師は、患者の来局の際に、患者の端末装置３０を介して患者の服薬状況を確認することができる。さらに、患者の端末装置３０に二次元コードが表示される場合に、薬剤師は、端末装置１０を介して患者の端末装置３０に表示されている二次元コードを読み取ることができる。そのため、薬剤師は、情報の取得を容易に行うことが可能となる。

図９において、患者の個人ページへのアクセス権を付与する以外にも、例えば、サーバ２０は、患者の薬剤の服薬状況を示す情報を、端末装置１０へ送信してもよい。

＜画面例＞
図１１は、第２の実施の形態における、薬剤師の端末装置１０の画面例を示す図である。図１１は、図９のステップS９２３において、薬剤師の端末装置１０の表示部１６０に表示される画面を示す図である。

図１１に示すように、端末装置１０の表示部１６０に表示された表示画面１３１は、領域１４０と、領域１４１と、領域１４２と、領域１４３と、操作部材１４４とを含む。領域１４０は、患者の情報を表示するための領域である。領域１４１は、患者の調剤情報を表示するための領域である。領域１４２は、当該処方箋による再度の薬剤の交付を可能とする期間を表示するための領域である。領域１４３は、薬局間又は薬剤師間で共有するための情報として、申し送り事項を表示するための領域である。操作部材１４４は、表示画面１３１に表示されている情報を他の端末装置１０に送るための操作入力をユーザから受け付けるための操作部材である。

図１１は、例えば、端末装置１０が患者の服薬状況を示す情報を提示するための操作を薬剤師から受け付けた場合に、図９のステップS９２３においてサーバ２０が端末装置１０に送信したデータに基づいて、端末装置１０の表示部１６０に表示される画面例である。あるいは、操作部材１４４は、薬剤師から操作入力を受け付けることによって、端末装置１０のディスプレイに表示されている情報を他の端末装置へ送信することができる。

また、図１１は、患者の端末装置３０の画面例を示す図であってもよい。図１１は、図１０のステップS１０２２において、サーバ２０が端末装置３０に送信したデータに基づいて、患者の端末装置３０の表示部に表示される画面を示す図であってもよい。図１１の患者の端末装置３０の表示部に表示される画面として、操作部材１４４の代わりに、図１０のステップS１０２２において生成された二次元コードを代わりに表示してもよい。端末装置３０の表示部に表示された二次元コードを他の端末装置が読み取ることにより、二次元コードを読み取った端末装置の表示部に当該情報を表示させることができる。

上記により、薬剤師は、患者の過去の薬剤の交付状況、及び、薬剤の服薬状況を容易に把握することができる。したがって、同じ薬剤師が継続して患者に対して薬剤を交付できない場合であったとしても、薬剤師は患者の状況に応じた服薬指導を可能とする。
＜変形例＞

図９のステップS９３１における、患者から情報の入力を受け付けるケースは、ステップS５２４の患者へのリマインド通知に対する回答として患者から入力を受け付けることに限られない。端末装置３０は、リマインド通知を受信する前に、患者が別の薬局へ来局する予定の入力を患者から受け付けてもよい。端末装置３０は、例えば、来局する予定である薬局を特定するための情報の入力を患者から受け付けてもよい。

図１０のステップS１０２２において、サーバ２０は、端末装置３０への通知方法として、患者のメールアドレス宛に電子メールで、又はＳＭＳ（ShortMessageService）によって情報を通知してもよい。また、サーバ２０は、患者に通知する手段として、患者が利用するＳＮＳ（SocialNetworkService）を用い、このＳＮＳとの連携により、情報を通知してもよい。ここで、患者が利用するＳＮＳのＩＤなどは、サーバ２０で管理してもよい。薬剤師は、リマインドを通知する患者を指定することはできるが、患者のＳＮＳのＩＤ等を閲覧できない設定にしてもよい。

＜第３の実施の形態＞
以上の実施の形態の説明では、複数回数の薬剤の交付を可能とする処方箋である場合において、サーバ２０が、薬剤の交付を可能とする時期、及び、患者へのリマインド時期を決定することについて説明した。また、以上の実施の形態の説明では、直近に薬剤の交付を受けた薬局と異なる薬局で薬剤の交付を受ける旨の回答を患者から受け付けた場合に、薬局間において当該患者の薬剤の服用に関する情報を共有することについて説明した。

以下の実施の形態では、複数回数の薬剤の交付を可能とする処方箋である場合において、処方箋の使用可能な回数が残っているにもかかわらず、薬剤師によって患者への薬剤の交付の中止を判断した場合における、サーバ２０の処理の例について説明する。

図１２は、第３の実施形態における、薬剤師によって患者への薬剤の交付の中止を判断した場合における処理を示すフローチャートである。

ステップS１２１１において、端末装置１０は、薬剤の交付を中止するための操作入力を薬剤師から受け付ける。ステップS１２１１において、端末装置１０は、例えば、患者の体調の変化が生じたことにより、患者へ薬剤の交付を中止すると判断した薬剤師から、薬剤の交付を中止するための操作入力を受け付ける。また、端末装置１０は、例えば、副作用の症状が現れた旨の申し出が患者からあったことにより、患者への薬剤の交付を中止すると判断した薬剤師から、薬剤の交付を中止するための操作入力を受け付けてもよい。さらに、端末装置１０は、例えば、患者の体調の変化が生じたことにより、患者に対して、服用する薬剤を変更すべきであると判断した薬剤師から、患者への薬剤の交付を中止するための操作入力を受け付けてもよい。そして、端末装置１０は、薬剤師から薬剤の交付を中止するための操作入力があったことをサーバ２０に通知する。サーバ２０は、薬剤師から操作入力のあった日時を処方箋データベース２８１に記憶してもよい。

ステップS１２２１において、サーバ２０は、ステップS１２１１において端末装置１０からの通知を受け付けたことに応答して、薬剤の交付を中止する旨の操作入力を受けた患者への薬剤の服用状況及び処方箋の情報を、処方箋データベース２８１及び患者情報データベース２８４から抽出する。サーバ２０は、例えば、患者の薬剤の服用期間及び処方日を示す情報と、患者の服用している薬剤の種類を示す情報とを、処方箋データベース２８１及び患者情報データベース２８４から抽出する。

ステップS１２２２において、サーバ２０は、医師へ連絡するための連絡フォームを生成する。サーバ２０は、例えば、ステップS１２２１において抽出した患者の情報を、医師へ連絡するための予め定められたフォームに入力する。さらに、サーバ２０は、患者の情報を入力した状態の連絡フォームを端末装置１０に表示させるためのデータを生成し、このデータを、端末装置１０を介して薬剤師に提示する。

ステップS１２１２において、端末装置１０は、ステップS１２２２で生成されて端末装置１０に送信された、医師への連絡フォームを端末装置１０の表示部１６０に表示させ、この状態において、医師への申し送り事項についての操作入力を薬剤師から受け付ける。端末装置１０は、例えば、医師への申し送り事項を受け付ける操作入力として、薬剤の交付を中止する判断をした理由を示す情報の操作入力を薬剤師から受け付けてもよい。そして、端末装置１０は、ステップＳ１２１２で受け付けた操作入力に係る情報をサーバ２０に送信する。

ステップS１２２３において、サーバ２０は、ステップS１２１２において薬剤師から入力を受け付けた医師への連絡フォームを、医師の端末装置１０Bに送信する。また、サーバ２０は、例えば、ステップS１２１２において薬剤師から受け付けた情報について、患者情報データベース２８４に登録する。

これにより、医師は、薬剤師による患者への薬剤の交付を中止した情報を把握できるため、患者が再度医療機関を受診する際、より患者の状況に応じた診察が可能となる。

ステップS１２１１における、薬剤師による患者へ薬剤の交付を中止する判断について、サーバ２０は、当該患者を診察した医師から、予め中止と判断する条件の入力を受け付けておいてもよい。例えば、図１２の端末装置１０Bは、患者へ薬剤の交付を中止する判断をするための条件を示す情報を入力する操作を予め医師から受け付ける。さらに、サーバ２０は、医師から受け付けた情報を、患者情報データベース２８４に登録しておく。サーバ２０は、図１２のステップS１２１１において、薬剤師が患者へ薬剤の交付を中止するか否かを判断する局面において、端末装置１０のディスプレイに、当該医師から受け付けた情報を表示させる。これにより、薬剤師は、予め医師から情報を提供されていることにより、患者へ薬剤の交付を中止することを容易に判断できる。

処方箋の使用可能な回数が残っているにもかかわらず以下のような場合に、医師が所有する端末装置１０Bは薬剤の交付を中止するための操作入力を医師から受け付けてもよい。
・病院を受診した患者に対する診察結果より、患者に対する当該処方箋による薬剤の交付の継続が適切でないと医師が判断した場合。
・病院を受診した患者に対する診察結果より、患者が服用する薬剤を変更するべきであると医師が判断した場合。
医師が所有する端末装置１０Bは、当該処方箋を識別する情報と、当該処方箋の使用中止を示す情報との入力を医師から受け付けてもよい。端末装置１０Bは、医師による操作入力を介して受け入れた情報を、通信部１２０を介してサーバ２０に送信する。サーバ２０は、端末装置１０Bから受信した情報を端末装置１０を介して薬剤師に対して提示する。サーバ２０は、端末装置１０Ｂから受信した情報を処方箋データベース２８１と患者情報データベース２８４とのうち少なくともいずれかに登録する。また、サーバ２０は、端末装置１０Ｂから情報を受信した日時を処方箋データベース２８１に登録してもよい。ここで、薬剤師が所有する端末装置１０は、当該患者に対するリマインド通知の設定を解除する入力を薬剤師から受け付けてもよい。端末装置１０は、例えば、薬剤師による入力を介して受け入れた情報を通信部１２０を介してサーバ２０に送信する。サーバ２０は、端末装置１０から受信した入力内容を、受付モジュール２０３３を介して受け付ける。サーバ２０は、受け付けた入力内容からリマインドデータベース２８２に格納される当該処方箋のレコードを抽出し、項目「リマインド予定日」に格納されているデータを削除してもよい。サーバ２０は、受け付けた入力内容からリマインドデータベース２８２に格納される当該処方箋のレコードを抽出し、項目「再リマインド予定日」に格納されているデータを削除してもよい。上記のように、薬剤師が処方箋による薬剤の交付を中止する情報を医師から取得することにより、薬剤師は患者の服薬状況を把握することができる。また、薬剤師は、誤って来局した患者に対して薬剤を交付することを回避できる。さらに、薬剤師が当該患者に対して設定されているリマインド通知を解除することにより、患者に対して不要なリマインド通知をすることを回避できる。

さらに、薬剤師は、処方箋による薬剤の交付を中止する情報を医師から取得することとして、電話とFAXとのうち少なくともいずれかの連絡手段によって医師から情報を取得してもよい。また、薬剤師は、医師が処方箋による薬剤の交付を中止した旨の情報を、患者から取得してもよい。薬剤師は、例えば、医師が処方箋による薬剤の交付を中止する情報を、電話とFAXのうち少なくともいずれかの連絡手段によって患者から取得してもよい。薬剤師は、図５のステップS５２４において患者へリマインドを通知した回答として、患者から処方箋による薬剤の交付を中止する情報を取得してもよい。これらの場合において、サーバ２０は、薬剤師が所有する端末装置１０を介して、当該処方箋を識別する情報を含む、処方箋による薬剤の交付を中止する旨の操作入力を薬剤師から受け付けてもよい。サーバ２０は、端末装置１０から受信した入力内容を、受付モジュール２０３３を介して受け付ける。サーバ２０は、受け付けた入力内容からリマインドデータベース２８２に格納される当該処方箋のレコードを抽出し、項目「リマインド予定日」に格納されているデータを削除してもよい。サーバ２０は、受け付けた入力内容からリマインドデータベース２８２に格納される当該処方箋のレコードを抽出し、項目「再リマインド予定日」に格納されているデータを削除してもよい。

また、図１２のステップS１２２２において、サーバ２０は連絡フォームを端末装置１０に提示する例を説明したが、この限りでない。サーバ２０は、例えば、医師へ連絡するための連絡フォームを用紙に出力してもよい。これにより、薬剤師は、FAXで医師へ連絡することが容易となる。さらに、図１２のステップS１２２２において、抽出した患者の情報を端末装置１０のディスプレイに表示すると同時に、サーバ２０は、当該患者を診察した医師の連絡先を合わせて表示してもよい。これにより、薬剤師は、電話によって医師へ患者の状況を説明する負担が低減される。

＜第４の実施の形態＞
以上の実施の形態の説明では、複数回数の薬剤の交付を可能とする処方箋である場合において、サーバ２０が、薬剤の交付を可能とする時期、及び、患者へのリマインド時期を決定することについて説明した。また、以上の実施の形態の説明では、患者へ通知したリマインドに対する患者の回答に応じた処理について説明した。さらに、薬剤師が薬剤の交付を中止する場合における処理についても説明した。

以下の実施の形態では、サーバ２０が、薬剤師に対して、患者の来局、患者へのリマインド、及び、薬剤の在庫管理に関するスケジュールを管理するためのページを表示する例について説明する。具体的には、サーバ２０は、薬剤師からの指定操作を受け付けることに対応して、薬剤師から指定された期間のスケジュールを表示する。

図１３は、第４の実施の形態における、薬剤師が管理するスケジュールを表示する流れの一例を示すフローチャートである。

ステップS１３１１において、端末装置１０は、薬局ID、及び、任意の期間を指定する操作入力を薬剤師から受け付ける。端末装置１０は、例えば、期間として特定の日付又は週を指定する操作を薬剤師から受け付けてもよい。端末装置１０は、ステップＳ１３１１で受け付けた薬局ＩＤ及び任意の期間を指定する情報をサーバ２０に送信する。

ステップS１３２１において、サーバ２０は、ステップS１３１１で薬剤師から指定を受け付けた薬局ID、及び、期間に基づき、これら薬局ＩＤ及び期間に対応付けられた患者への薬剤の交付の予定、及び、患者へのリマインド実施予定を示す情報を、リマインドデータベース２８２から抽出する。サーバ２０は、例えば、上記の情報に加え、当該患者に対応付けられた処方箋の情報についても、処方箋データベース２８１から抽出するようにしてもよい。

ステップS１３２２において、サーバ２０は、ステップS１３２１において抽出した患者への薬剤の交付の予定を示す情報を端末装置１０のディスプレイに表示させる。サーバ２０は、ステップS１３２１において抽出した患者へのリマインドの予定を示す情報を端末装置１０のディスプレイに表示させる。サーバ２０は、さらに、ステップS１３２１において抽出した処方箋の情報に基づき、当該指定を受け付けた期間に必要とされる、薬剤の種類及び薬剤の量についても端末装置１０に表示させてもよい。サーバ２０は、例えば、ステップS１３２１において抽出した処方箋の情報のうち、患者へ交付する薬剤の規格、量を示す情報を、薬剤の種類ごとに集計して、必要な薬剤の在庫量を示す情報として、端末装置１０のディスプレイに表示させてもよい。

＜画面例＞
図１４は、第４の実施の形態における、端末装置１０の表示部１６０に表示される画面例を示す図である。図１４は、例えば、図１３のステップS１３２２における、端末装置１０の表示部１６０に表示される画面例を示す図である。

図１４の画面例は、薬剤師が指定した任意の期間における、患者への薬剤の交付の予定、及び、患者へのリマインドの予定を把握するための表示を示す図である。図１４に示すように、端末装置１０の表示部１６０に表示される表示画面１３１は、領域１４５と、領域１４６と、領域１４７と、操作部材１４８と、領域１４９とを含む。領域１４５は、図１３のステップS1311で薬剤師から指定を受け付けた薬局及び期間を表示する領域である。領域１４６は、薬剤師から指定を受け付けた期間において、薬剤を交付する予定の対象である患者を表示する領域である。領域１４７は、薬剤師から指定を受け付けた期間において、リマインド通知予定の対象である患者を表示する領域である。操作部材１４８は、領域１４７に表示されている患者へ連絡をする処理を開始するための操作入力を薬剤師から受け付ける操作部材である。領域１４９は、薬剤師が指定した期間において、予測される必要な薬剤の種類と総量を表示する領域である。

これにより、薬剤師は指定した期間において、薬剤の交付を予定している患者、及び、リマインド通知を予定している患者の情報を把握することができる。さらに、患者ごとに設けられている操作部材１４８を薬剤師が押下することにより、薬剤師が患者へ連絡する処理を開始することができるため、患者へ容易に連絡することが可能である。また、指定された期間における、必要な薬剤の種類及び総量が把握できるため、薬剤師は、必要な薬剤の在庫を容易に管理することができる。薬剤師は、例えば、図７の領域１３５に表示されている患者の来局予測を参照することにより、必要な薬剤の種類及び量について、より正確に把握することができる。さらに、薬剤師は、図７の操作部材１３６を押下することにより表示される患者の来局履歴を参照することにより、必要な薬剤の種類及び量について、より正確に把握することができる。特に、患者へ特殊な薬剤の交付の予定のある場合において、薬剤師は、患者の来局にもかかわらず、薬剤の在庫切れにより薬剤を患者へ交付できない事態を回避することができる。

＜付記＞
以上の各実施の形態で説明した事項を以下に付記する。

（付記１）プロセッサと、メモリとを備えるコンピュータに実行させるプログラムであって、プログラムは、プロセッサに、患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップ（ステップS５１１）と、処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、第１の情報に基づき、患者が処方箋に基づき薬剤の交付を受ける時期を算出する第２のステップ（ステップS５２１）と、第２のステップにおいて算出した時期をユーザに提示する、第３のステップ（ステップS５２３）と、を実行させる、プログラム。

（付記２）プログラムは、プロセッサに、さらに、第２のステップにおいて算出された薬剤の交付を受ける時期を患者へ通知する第４のステップ（ステップS５２４）を実行させる、（付記１）に記載のプログラム。

（付記３）第４のステップにおいて、薬剤の交付を受ける時期よりも一定期間前に、薬剤の交付を受ける時期を患者へ通知する、（付記２）に記載のプログラム。

（付記４）プログラムは、プロセッサに、さらに、第４のステップにおいて患者への通知に対して、薬剤の交付を受けることに関する情報の入力を患者から受け付け、受け付けた情報を薬剤師へ通知する第５のステップ（ステップS５３１）を実行させる、（付記２）または（付記３）に記載のプログラム。

（付記５）第４のステップにおいて、患者へ通知するタイミングを、患者の行動履歴又は第５のステップで薬剤師へ通知する情報のうち少なくともいずれかに基づいて決定する、（付記４）に記載のプログラム。

（付記６）プログラムは、プロセッサに、さらに、薬剤師から所定の期間の指定を受け付けるステップと、薬剤師から所定の期間の指定を受け付けることに応答して、指定された期間に関連付けて登録された、患者への薬剤の交付に基づく薬剤師のスケジュールに関する情報を薬剤師へ提示させる第６のステップ（ステップS１３２２）を実行させる、（付記１）または（付記２）に記載のプログラム。

（付記７）第６のステップにおいて、薬剤師のスケジュールに関する情報を薬剤師へ提示することとして、薬局に来局した患者へ薬剤を交付すること、薬剤師が患者へ薬剤を受け取る時期を通知すること、又は、必要な薬剤の在庫管理をすることからなる群のうちの少なくともいずれかのスケジュールに関する情報を薬剤師に提示する、（付記６）に記載のプログラム。

（付記８）プログラムは、プロセッサに、さらに、患者が直近に処方箋による薬剤の交付を受けた情報を、患者へ薬剤を交付する予定の薬剤師が閲覧できない状態となる旨の通知を患者から受け付けた場合において、処方箋により薬剤の交付を受けた履歴に関する情報を、患者又は患者へ薬剤を交付する予定の薬剤師の少なくとも一方へ提示する第７のステップ（ステップS９２３、S１０３１）を実行させる、（付記１）に記載のプログラム。

（付記９）プログラムは、プロセッサに、さらに、患者が直近に処方箋による薬剤の交付を受けた情報を、患者へ薬剤を交付する予定の薬剤師が閲覧できない状態となる旨の通知を患者から受け付けることとして、患者が、直近に処方箋による薬剤の交付を受けた薬局とは別の薬局へ来局する予定の通知を患者から受け付けた場合において、処方箋により薬剤の交付を受けた履歴に関する情報を、患者又は患者へ薬剤を交付する予定の薬剤師の少なくとも一方へ提示する第７のステップを実行させる、（付記８）に記載のプログラム。

（付記１０）第７のステップにおいて、薬剤師が患者から通知を受けることとして、第４のステップにおいて、薬剤師が患者に対しての通知に応答する通知を受ける、（付記８）または（付記９）に記載のプログラム。

（付記１１）プログラムは、プロセッサに、さらに、処方箋による薬剤の交付回数が、規定された複数回数の上限に到達している場合において、第１のステップにおいて第１の情報を取得したことに応答して、処方箋による薬剤の交付が規定された複数回数の上限に到達している旨をユーザへ通知する、第８のステップ（S６２３）を実行する、（付記１）に記載のプログラム。

（付記１２）第８のステップにおいて、患者が医療機関を受診する目安を患者へ示すための情報をユーザに対して提示する（ステップS６２３）、（付記１１）に記載のプログラム。

（付記１３）プログラムは、プロセッサに、さらに、処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していないにもかかわらず、処方箋による患者への薬剤の交付を中止するための入力を薬剤師から受け付ける第９のステップ（ステップS１２１１）と、入力を受け付けることに応答して、医療機関へ連絡するための処理を開始する第１０のステップ（ステップS１２２２）を実行する、（付記１）に記載のプログラム。

（付記１４）第９のステップにおいて、処方箋による患者への薬剤の交付を中止する判断をするために必要な情報を薬剤師へ提示する、（付記１３）に記載のプログラム。

１：システム
１０：端末装置
１３：入力装置
１４：出力装置
１５：メモリ
１６：記憶部
１９：プロセッサ
２０：サーバ
２５：メモリ
２６：ストレージ
２９：プロセッサ
３０：端末装置
８０：ネットワーク
１２０：通信部
１３０：操作受付部
１３１：表示画面
１７１：処方箋情報
１７２：患者情報
１８０：制御部
１８１：入力操作受付部
１８２：送受信部
１８３：表示制御部
１８４：通知制御部
２０１：通信部
２０２：記憶部
２０３：制御部
２８１：処方箋データベース
２８２：リマインドデータベース
２８３：連絡履歴データベース
２８４：患者情報データベース
２０３１：受信制御モジュール
２０３２：送信制御モジュール
２０３３：受付モジュール
２０３４：使用回数判定モジュール
２０３５：演算モジュール
２０３６：提示モジュール

Claims (17)

1. プロセッサと、メモリとを備えるコンピュータに実行させるプログラムであって、
   前記プログラムは、前記プロセッサに、
   患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
   前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
   前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
   前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
   前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
   を実行させ、
   前記第４のステップにおいて、前記患者へ通知するタイミングを、前記患者の行動履歴に基づいて決定する、プログラム。
2. プロセッサと、メモリとを備えるコンピュータに実行させるプログラムであって、
   前記プログラムは、前記プロセッサに、
   患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
   前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
   前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
   前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
   前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
   前記第４のステップにおいて前記患者への前記通知に対して、前記薬剤の交付を受けることに関する情報の入力を前記患者から受け付け、受け付けた情報を薬剤師へ通知する第５のステップと、
   直近に前記薬剤の交付を受けた薬局と異なる薬局で前記薬剤の交付を受ける旨の前記情報を前記患者から受け付けた場合、前記患者が直近に前記処方箋による前記薬剤の交付を受けた情報を、前記患者へ前記薬剤を交付する予定の薬剤師が閲覧できない状態となる旨の通知を前記患者から受け付けた場合において、前記処方箋により前記薬剤の交付を受けた履歴に関する情報を、前記患者又は前記患者へ前記薬剤を交付する予定の薬剤師の少なくとも一方へ提示する第７のステップと、を実行させる、プログラム。
3. プロセッサと、メモリとを備えるコンピュータに実行させるプログラムであって、
   前記プログラムは、前記プロセッサに、
   患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
   前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
   前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
   前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
   前記処方箋による薬剤の交付回数が、前記規定された複数回数の上限に到達している場合において、前記第１のステップにおいて前記第１の情報を取得したことに応答して、前記処方箋による前記薬剤の交付が前記規定された複数回数の上限に到達している旨を前記ユーザへ通知する、第８のステップと、
   を実行させ、
   前記第８のステップにおいて、前記患者が医療機関を受診する目安を患者へ示すための情報として、前記患者が服薬している前記薬剤の尽きるタイミングを示す情報を前記ユーザに対して提示する、プログラム。
4. 前記プログラムは、前記プロセッサに、さらに、前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップを実行させ、
   前記第４のステップにおいて、前記薬剤の交付を受ける時期よりも一定期間前に、前記薬剤の交付を受ける時期を前記患者へ通知する、請求項１～３のいずれかに記載のプログラム。
5. 前記プログラムは、前記プロセッサに、さらに、
   前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
   前記第４のステップにおいて前記患者への前記通知に対して、前記薬剤の交付を受けることに関する情報の入力を前記患者から受け付け、受け付けた情報を薬剤師へ通知する第５のステップを実行させる、請求項１～３のいずれかに記載のプログラム。
6. 前記プログラムは、前記プロセッサに、さらに、
   前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
   薬剤師から所定の期間の指定を受け付けるステップと、
   前記薬剤師から前記所定の期間の指定を受け付けることに応答して、前記指定された期間に関連付けて登録された、前記患者への前記薬剤の交付に基づく前記薬剤師のスケジュールに関する情報を前記薬剤師へ提示させる第６のステップを実行させる、請求項１～３のいずれかに記載のプログラム。
7. 前記第６のステップにおいて、前記薬剤師のスケジュールに関する情報を薬剤師へ提示することとして、薬局に来局した患者へ薬剤を交付すること、薬剤師が患者へ薬剤を受け取る時期を通知すること、又は、必要な薬剤の在庫管理をすることからなる群のうちの少なくともいずれかのスケジュールに関する情報を前記薬剤師に提示する、請求項６に記載のプログラム。
8. 前記プログラムは、前記プロセッサに、さらに、
   前記患者が直近に前記処方箋による前記薬剤の交付を受けた情報を、前記患者へ前記薬剤を交付する予定の薬剤師が閲覧できない状態となる旨の通知を前記患者から受け付けることとして、前記患者が、直近に前記処方箋による前記薬剤の交付を受けた薬局と異なる薬局へ来局する予定の通知を前記患者から受け付けた場合において、前記処方箋により前記薬剤の交付を受けた履歴に関する情報を、前記患者又は前記患者へ前記薬剤を交付する予定の薬剤師の少なくとも一方へ提示する前記第７のステップを実行させる、請求項２に記載のプログラム。
9. 前記第７のステップにおいて、前記薬剤師が前記患者から通知を受けることとして、前記第４のステップにおいて、前記薬剤師が前記患者に対しての通知に応答する通知を受ける、請求項２に記載のプログラム。
10. 前記プログラムは、前記プロセッサに、さらに、
    前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していないにもかかわらず、
    前記処方箋による前記患者への前記薬剤の交付を中止するための入力を薬剤師から受け付ける第９のステップと、前記入力を受け付けることに応答して、医療機関へ連絡するための処理を開始する第１０のステップを実行する、請求項１～３のいずれかに記載のプログラム。
11. 前記第９のステップにおいて、
    前記処方箋による前記患者への前記薬剤の交付を中止する判断をするために必要な情報を 前記薬剤師へ提示する、請求項１０に記載のプログラム。
12. プロセッサと、メモリとを備えるコンピュータに実行させる方法であって、
    前記方法は、前記プロセッサが、
    患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
    前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
    前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
    前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
    前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
    を実行し、
    前記第４のステップにおいて、前記患者へ通知するタイミングを、前記患者の行動履歴に基づいて決定する、方法。
13. プロセッサと、メモリとを備えるコンピュータに実行させる方法であって、
    前記方法は、前記プロセッサが、
    患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
    前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
    前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
    前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
    前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
    前記第４のステップにおいて前記患者への前記通知に対して、前記薬剤の交付を受けることに関する情報の入力を前記患者から受け付け、受け付けた情報を薬剤師へ通知する第５のステップと、
    直近に前記薬剤の交付を受けた薬局と異なる薬局で前記薬剤の交付を受ける旨の前記情報を前記患者から受け付けた場合、前記患者が直近に前記処方箋による前記薬剤の交付を受けた情報を、前記患者へ前記薬剤を交付する予定の薬剤師が閲覧できない状態となる旨の通知を前記患者から受け付けた場合において、前記処方箋により前記薬剤の交付を受けた履歴に関する情報を、前記患者又は前記患者へ前記薬剤を交付する予定の薬剤師の少なくとも一方へ提示する第７のステップと、を実行する、方法。
14. プロセッサと、メモリとを備えるコンピュータに実行させる方法であって、
    前記方法は、前記プロセッサが、
    患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
    前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
    前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
    前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
    前記処方箋による薬剤の交付回数が、前記規定された複数回数の上限に到達している場合において、前記第１のステップにおいて前記第１の情報を取得したことに応答して、前記処方箋による前記薬剤の交付が前記規定された複数回数の上限に到達している旨を前記ユーザへ通知する、第８のステップと、
    を実行し、
    前記第８のステップにおいて、前記患者が医療機関を受診する目安を患者へ示すための情報として、前記患者が服薬している前記薬剤の尽きるタイミングを示す情報を前記ユーザに対して提示する、方法。
15. 制御部と、記憶部とを備える情報処理装置であり、
    前記制御部は、
    患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
    前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
    前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
    前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
    前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
    を実行し、
    前記第４のステップにおいて、前記患者へ通知するタイミングを、前記患者の行動履歴に基づいて決定する、情報処理装置。
16. 制御部と、記憶部とを備える情報処理装置であり、
    前記制御部は、
    患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
    前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
    前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
    前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
    前記第２のステップにおいて算出された前記薬剤の交付を受ける時期を前記患者へ通知する第４のステップと、
    前記第４のステップにおいて前記患者への前記通知に対して、前記薬剤の交付を受けることに関する情報の入力を前記患者から受け付け、受け付けた情報を薬剤師へ通知する第５のステップと、
    直近に前記薬剤の交付を受けた薬局と異なる薬局で前記薬剤の交付を受ける旨の前記情報を前記患者から受け付けた場合、前記患者が直近に前記処方箋による前記薬剤の交付を受けた情報を、前記患者へ前記薬剤を交付する予定の薬剤師が閲覧できない状態となる旨の通知を前記患者から受け付けた場合において、前記処方箋により前記薬剤の交付を受けた履歴に関する情報を、前記患者又は前記患者へ前記薬剤を交付する予定の薬剤師の少なくとも一方へ提示する第７のステップと、を実行する、情報処理装置。
17. 制御部と、記憶部とを備える情報処理装置であり、
    前記制御部は、
    患者に対して薬剤を処方する処方箋の内容を示す第１の情報を取得する、第１のステップと、
    前記処方箋が、予め規定された複数回数の薬剤の交付が可能である処方箋であって、前記処方箋による薬剤の交付回数が、規定された複数回数の上限に到達していない場合において、
    前記第１の情報に基づき、前記患者が前記処方箋に基づき前記薬剤の交付を受ける時期を算出する第２のステップと、
    前記第２のステップにおいて算出した時期をユーザに提示する、第３のステップと、
    前記処方箋による薬剤の交付回数が、前記規定された複数回数の上限に到達している場合において、前記第１のステップにおいて前記第１の情報を取得したことに応答して、前記処方箋による前記薬剤の交付が前記規定された複数回数の上限に到達している旨を前記ユーザへ通知する、第８のステップと、
    を実行し、
    前記第８のステップにおいて、前記患者が医療機関を受診する目安を患者へ示すための情報として、前記患者が服薬している前記薬剤の尽きるタイミングを示す情報を前記ユーザに対して提示する、情報処理装置。

Images