JP5801015B1 - 処方薬販売システム、処方薬販売方法、プログラムおよび情報記憶媒体 - Google Patents

Abstract

電子的な処方箋と電子商取引とを用いて薬を購入する場合に、その処方箋が対象とする患者と関係のない購入者に薬が販売されることを防ぐ。処方薬販売システムは、ユーザを認証する認証情報と紐付けられかつ電子処方箋を示す情報を前記ユーザから受信し、前記紐付けられた認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行し、前前記確認のための処理の結果に従って、前記電子処方箋に応じた薬の販売処理の実行を制御する。

Description

本発明は処方薬販売システム、処方薬販売方法、プログラムおよび情報記憶媒体に関する。

患者が医師にかかった後に薬を購入する場合、医師が患者に紙の処方箋を発行している。患者は発行された処方箋を薬局に提出することで処方箋に記載された薬を購入している。

特許文献１には、診療が終わる都度、処方箋を医師端末より受信し、処方箋に薬支給があれば処方箋と、患者氏名と、宅配指定の有無と、薬の受取り場所とを薬局端末に指示することが開示されている。

特許文献２には、遠隔利用システムにより診察が行われた後、調剤、配送センターが薬の調剤を行い、その薬を患者へ宅配するシステムが開示されている。そのシステムは処方箋集配信サーバと調剤、配送センターとを含み、処方箋集配信サーバは、病院内の医師により作成された処方箋情報を病院から受信すると、患者管理ＤＢから患者氏名や患者の最寄の調剤、配送センターの番号を取得し、その調剤、配送センターへ処方箋情報や患者情報の一部または全部を送信する。

特開２００３−１０８６７５号公報 特開２００２−２７９０６９号公報

近年、処方箋を電子化することが検討されている。さらに、処方箋が電子化された際には、ユーザがインターネットを介した電子商取引によりその処方箋に記入された薬を購入することが考えられる。ユーザが電子商取引により薬を購入する場合、その利点の一つとして購入手続きや薬の授受のタイミング等に融通がきくことが挙げられる。

しかしながら、一方で電子的な処方箋が対象とする患者と関係のない者に薬を販売することは好ましくないことから、電子的な処方箋に記載された患者とその処方箋を提出した者との照合や電子的な処方箋に記載された患者と薬の購入者との照合を各々行わなければならない。その照合の処理は煩雑になることが懸念される。また、薬の受け渡し時に薬剤師によるそのユーザの個人情報、病状、他の薬の併用の有無や使用履歴等からその薬の内容・用法の説明をする必要があることから、従来考えられていたシステムでは、実際には購入手続きのタイミングはユーザが薬剤師と話のできるタイミングに拘束され、電子商取引による上記利点を必ずしも得ることができない場合がある。

本発明は上記課題を鑑みてなされたものであって、その目的は、電子的な処方箋と電子商取引とを用いて薬を購入する場合に、電子商取引による利点を損なうことなく、その処方箋が対象とする購入以外の不正な薬の販売を防ぐ技術を提供することにある。

上記課題を解決するために、本発明にかかる処方薬販売システムは、ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信する処方箋受信手段と、前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行する処方箋確認手段と、前記処方箋確認手段による確認のための処理の結果に従って、前記セッション中に前記電子処方箋に応じた薬の販売処理の実行を制御する制御手段と、前記電子処方箋に基づく薬の売買に関する情報を前記電子処方箋に紐づけて記憶する手段と、を含む。

また、本発明にかかる処方薬販売方法は、ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信するステップと、前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行するステップと、前記ユーザの情報と前記患者の情報とが対応するか否か確認するための処理の結果に従って、前記電子処方箋に応じた薬の販売処理の実行を制御するステップと、前記電子処方箋に基づく薬の売買に関する情報を前記電子処方箋に紐づけて記憶するステップと、を含む。

また、本発明にかかるプログラムは、ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信する処方箋受信手段、前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行する処方箋確認手段、および、前記処方箋確認手段による確認のための処理の結果に従って、前記電子処方箋に応じた薬の販売処理の実行を制御する制御手段、前記電子処方箋に基づく薬の売買に関する情報を前記電子処方箋に紐づけて記憶する手段、としてコンピュータを機能させる。

また、本発明にかかるコンピュータ読取り可能な記憶媒体は、上記プログラムを格納する。

本発明によれば、電子的な処方箋を用いて電子商取引により薬を購入する場合に、その処理が煩雑になることなく処方箋が対象としていない販売を防ぐことができる。

本発明の一態様では、処方薬販売システムは、前記電子処方箋に基づく薬が既に販売されているか否かを前記売買に関する情報に基づいて確認するための処理を実行する販売確認手段をさらに含み、前記制御手段は、まだ前記薬が販売されていないと確認された場合に前記電子処方箋に応じた薬の販売処理が実行されるよう制御してもよい。

本発明の一態様では、処方薬販売システムは前記電子処方箋がいずれかの薬局により使用されたか否かを示す使用情報を受信する手段をさらに含み、前記制御手段は、前記使用情報がまだ前記電子処方箋が使用されていないことを示す場合に前記電子処方箋に応じた薬の販売処理が実行されるよう制御してもよい。

この態様によれば、患者が薬局から電子処方箋に記載される薬を複数回購入したり、患者になりすます者が薬を購入することを防ぐことができる。

本発明の一態様では、処方薬販売システムは、前記電子処方箋にかかる患者の属性情報を、ユーザの属性情報を格納する記憶手段から取得する属性取得手段と、前記電子処方箋と前記読み出されたユーザの属性情報とを薬剤師に提示し、その提示に基づいて薬剤師から入力された説明文を受け付け、当該説明文を記憶手段に記憶させる説明文受付手段と、前記処方箋受信手段が前記電子処方箋を示す前記情報を受信した場合に前記説明文を前記ユーザに向けて出力する説明文出力手段と、をさらに含んでもよい。

また、処方薬販売システムは、前記処方箋受信手段により前記電子処方箋を示す前記情報を前記ユーザから取得する前に別途前記ユーザと異なる送信元から前記電子処方箋に含まれる薬および患者に関する情報を受信する事前受信手段を有し、前記属性取得手段は、ユーザと異なる送信元から受信された前記患者に関する情報に基づき前記電子処方箋にかかる患者の属性情報を、ユーザの属性情報を格納する記憶手段から取得し、前記説明文受付手段は、前記ユーザと異なる送信元から受信された前記薬に関する情報と前記読み出されたユーザの属性情報とを薬剤師に提示し、その提示に基づいて薬剤師から入力された説明文を受け付け、当該説明文を記憶手段に記憶させてもよい。

また、処方薬販売システムは、ユーザが前記説明文を確認したことを示す確認データを受信する確認データ受信手段をさらに含み、前記確認データが受信された場合に前記制御手段による前記電子処方箋に応じた薬の販売処理が実行されてもよい。

これらの態様によれば、実際の薬局と同様にユーザが薬剤師の説明を確認することができる。また、予めユーザに対する薬の説明文を準備して表示できるようにしておくことで、ユーザが電子処方箋を示す情報を送信してから薬剤師の説明を確認するまでの時間を短縮することができるばかりでなく、購入手続きのタイミングをユーザが自由に選択することができる。

本発明の一態様では、処方薬販売システムは、前記電子処方箋により指定される薬を複数の選択肢からユーザに選択させるための情報を生成する生成手段をさらに含み、前記制御手段は、前記販売処理を実行する際に前記ユーザに選択された選択肢に基づいて前記電子処方箋に応じた薬の販売処理の実行を制御してもよい。

この態様によれば、電子処方箋に対応する薬として、例えば先発薬とその先発薬と同じ成分のジェネリック薬とがある場合等にユーザの希望に応じてその選択をさせることができ、より実際の薬局に近い対応が可能となる。

本発明の一態様では、前記電子処方箋に含まれる薬の情報と薬局の在庫情報とに基づいて、当該電子処方箋に指定される薬を販売する薬局のうちいずれかをユーザに選択させるための情報を生成する生成手段をさらに含み、前記制御手段は、ユーザに選択された前記薬を販売する薬局に基づいて前記電子処方箋に応じた薬の販売処理の実行を制御してもよい。

この態様によれば、電子処方箋に対応する薬である先発薬やジェネリック薬の在庫の有無が複数の薬局で異なる場合や、その他の販売条件が異なる場合等に、それらを比較してユーザの希望に応じて購入する薬局を選択することができるという、オンラインでの販売特有の効果を得ることができる。

本発明の一態様では、処方薬販売システムは、前記電子処方箋に応じた薬の情報及びユーザの希望の少なくともいずれか一方に基づいて、前記薬を一回で、または複数回に分けて発送するスケジュールを生成する発送スケジュール生成手段をさらに含んでもよい。

更に、本発明の一態様では、処方薬販売システムは、前記生成された発送スケジュールに基づいて、前記薬の発送を管理する発送管理手段をさらに含んでもよい。

更に、本発明の一態様では、処方薬販売システムは、前記発送管理手段が、前記薬の発送スケジュールとユーザの希望とに基づいて、未発送の前記薬の発送を停止可能となっており、前記発送管理手段により前記薬の発送が停止された場合に、その発送状況に基づき、薬の売買が一部または全部キャンセルされたことを前記電子処方箋に基づく薬の売買に関する情報の更新内容として前記薬の売買に関する情報の記憶する手段に記憶する、ようにしてもよい。

これらの態様によれば、保存の難しい薬や飲み過ぎによる事故の発生が懸念される薬について、患者が何度も受診する手間を減らしつつ、薬の服用に伴う事故のリスクを減らすことができる。また、余剰薬が発生した場合に未発送の薬を薬局が買い戻す等、有効利用することができる。

本発明の実施形態にかかる処方薬販売システムの構成を示す図である。 薬局システムに含まれるコンピュータ、電子商店街サーバ、ユーザ端末、病院サーバのハードウェア構成の一例を示す図である。 処方薬販売システムが実現する機能を示すブロック図である。 処方薬の販売過程の一例を概略的に示す図である。 図４の例におけるユーザ端末、電子商店街サーバ、薬局システム、病院サーバの間での通信を示すシーケンス図である。 電子商店街サーバの処理の概要を示すフロー図である。 ログイン画面の一例を示す図である。 ユーザ情報の一例を示す図である。 処方箋送信画面の一例を示す図である。 電子処方箋に含まれる情報の一例を示す図である。 電子処方箋に含まれる情報の一例を示す図である。 ユーザに薬を選択させる際の処理の一例を示すフロー図である。 薬種類情報の一例を示す図である。 薬局選択画面の一例を示す図である。 注文一覧画面の一例を示す図である。 注文詳細画面の一例を示す図である。 販売状況を確認する際の処理の一例を示すフロー図である。 説明文入力画面の一例を示す図である。 説明文出力画面の一例を示す図である。 メッセージ確認画面の一例を示す図である。 発送スケジュールを生成する処理の概要を示すフロー図である。 発送スケジュールの案を作成する処理の一例を示すフロー図である。 発送スケジュール確認画面の一例を示す図である。 処方薬の販売過程の他の一例を概略的に示す図である。 図２４の例における、ユーザ端末、電子商店街サーバ、薬局システム、病院サーバの間での通信を示すシーケンス図である。 薬詳細画面の一例を示す図である。 説明文出力画面の他の一例を示す図である。

以下では、本発明の実施形態を図面に基づいて説明する。同じ符号を付された構成については、重複する説明を省略する。

図１は、本発明の実施形態にかかる処方薬販売システムの構成の一例を示す図である。この処方薬販売システムは、薬局システム１と、電子商店街サーバ２と、ユーザ端末３と病院サーバ４とを含む。これらは、ネットワーク５を介して接続されている。ネットワーク５は、例えばローカルエリアネットワークやインターネットである。

薬局システム１は、サーバコンピュータとクライアントコンピュータとにより構成されるシステムである。薬局システム１は、サーバコンピュータであってもよいし、パーソナルコンピュータであってもよい。薬局システム１は薬局ごとに存在する。図１では薬局システム１は１つしか記載されていないが、実際には複数の薬局システム１が存在してよい。薬局システム１は、薬局の薬の在庫を管理し、また薬剤師と電子商店街サーバ２とのやりとりを仲介する。

電子商店街サーバ２は、サーバコンピュータである。電子商店街サーバ２は、ウェブサーバプログラム（ｈｔｔｐｄなど）を実行し、ブラウザプログラムを実行するユーザ端末３からインターネットを介して情報を受信し、ユーザ端末３にボタンや文字列を含む画像（画面）を表示させる情報等を出力する。また電子商店街サーバ２は、ユーザ端末３に、処方薬を販売する薬局を選択させるための情報を出力し、ユーザ端末３が選択した薬局の薬局システム１に処方薬を販売するための情報を送信する。

ユーザ端末３は、例えばパーソナルコンピュータやスマートフォンであり、ユーザが入力した情報を電子商店街サーバ２等に送信し、電子商店街サーバ２等から情報を受信し、その情報に応じた画像を表示出力デバイスが表示するよう制御する。病院サーバ４はサーバコンピュータである。病院サーバ４は電子的な処方箋（以下では電子処方箋と記載する）を管理する。病院サーバ４は病院ごとに存在するが、１つの病院サーバ４が複数の病院についての電子処方箋を管理してもよい。

図２は、薬局システム１に含まれるコンピュータ、電子商店街サーバ２、ユーザ端末３、病院サーバ４のハードウェア構成の一例を示す図である。薬局システム１に含まれるコンピュータ、電子商店街サーバ２、ユーザ端末３、病院サーバ４のそれぞれは、プロセッサ１１、記憶部１２、通信部１３、入出力部１４を含む。

プロセッサ１１は、記憶部１２に格納されているプログラムに従って動作する。またプロセッサ１１は通信部１３、入出力部１４を制御する。なお、上記プログラムは、インターネット等を介して提供されるものであってもよいし、フラッシュメモリやＤＶＤ−ＲＯＭ等のコンピュータで読み取り可能な記憶媒体に格納されて提供されるものであってもよい。

記憶部１２は、ＲＡＭやフラッシュメモリ等のメモリ素子やハードディスクドライブによって構成されている。記憶部１２は、上記プログラムを格納する。また、記憶部１２は、各部から入力される情報や演算結果を格納する。

通信部１３は、他の装置と通信する機能を実現するものであり、例えば有線ＬＡＮの集積回路などにより構成されている。通信部１３は、プロセッサ１１の制御に基づいて、他の装置から受信した情報をプロセッサ１１や記憶部１２に入力し、他の装置に情報を送信する。

入出力部１４は、表示出力デバイスをコントロールするビデオコントローラや、入力デバイスからのデータを取得するコントローラなどにより構成される。入力デバイスとしては、キーボード、マウス、タッチパネルなどがある。入出力部１４は、プロセッサ１１の制御に基づいて、表示出力デバイスに表示データを出力し、入力デバイスをユーザが操作することにより入力されるデータを取得する。表示出力デバイスは例えば外部に接続されるディスプレイ装置である。

次に、本発明の実施形態にかかる処方薬販売システムが実現する機能や処理について説明する。図３は、処方薬販売システムが実現する機能を示す機能ブロック図である。処方薬販売システムは機能的に、受信部５０、処方箋確認部５３、販売制御部５４、販売状況確認部５５、選択情報生成部５６、選択部５７、決済処理部５８、説明文入力部５９、説明文出力部６０、確認結果取得部６１、発送スケジュール生成部６２、発送管理部６３、処方箋事前受信部６４、属性取得部６５、ユーザ情報格納部７１、説明文格納部７２、注文情報格納部７３を含む。また受信部５０はユーザ認証部５１、処方箋受信部５２を含む。

これらの機能のうち受信部５０、ユーザ認証部５１、処方箋受信部５２、処方箋確認部５３、販売制御部５４、販売状況確認部５５、選択情報生成部５６、選択部５７、決済処理部５８、説明文入力部５９、説明文出力部６０、確認結果取得部６１、発送スケジュール生成部６２、発送管理部６３、処方箋事前受信部６４、属性取得部６５、ユーザ情報格納部７１、説明文格納部７２、注文情報格納部７３は、電子商店街サーバ２に含まれるプロセッサ１１が、記憶部１２に格納されたプログラムを実行し通信部１３等を制御することにより実現される。ここで、受信部５０、処方箋確認部５３、販売制御部５４、選択情報生成部５６、説明文入力部５９、説明文出力部６０、確認結果取得部６１、注文情報格納部７３、処方箋事前受信部６４、属性取得部６５、発送スケジュール生成部６２、発送管理部６３は、それぞれ、本願請求項における、処方箋受信手段、処方箋確認手段、生成手段、制御手段、説明文受付手段、説明文出力手段、確認データ受信手段、格納手段、事前受信手段、属性取得手段、発送スケジュール生成手段、発送管理手段、に対応する。また販売状況確認部５５は、本願請求項における販売確認手段および使用情報を受信する手段に対応する。

なお処方箋事前受信部６４や属性取得部６５は、薬局システム１に含まれるコンピュータに含まれるプロセッサ１１が、記憶部１２に格納されたプログラムを実行し通信部１３等を制御することにより実現されてもよいし、他の電子商店街サーバ２にかかる機能が同様に薬局システム１により実現されてもよい。

受信部５０は、ユーザ認証部５１と処方箋受信部５２とを含み、ユーザからひとつのセッション中にユーザ認証情報と電子処方箋を示す情報とを受信する。ユーザ認証部５１と処方箋受信部５２との処理については後述する。

ユーザ情報格納部７１は、ユーザを認証するための情報およびユーザの年齢、性別その他の属性の情報を格納し、説明文格納部７２は薬剤師から受け付けた説明文の情報を格納する。注文情報格納部７３は、ユーザから受け付けた処方薬の注文についての注文情報を格納する。注文情報は、電子処方箋に基づく薬の注文の情報であり、電子処方箋に紐付けられて注文情報格納部７３に格納される。また注文情報は、注文の処理の進行状況を示すステータス情報を含む。ステータス情報には電子処方箋に基づく薬が売買されたか否かを示す情報（薬の売買に関する情報）が含まれる。ユーザ情報格納部７１、説明文格納部７２、注文情報格納部７３は例えば電子商店街サーバ２の記憶部１２を中心として実現されるが、電子商店街サーバ２と異なりかつデータベース管理プログラムが実行される他のサーバコンピュータにより実現されてもよい。

また、発送管理部６３は、薬局システム１に含まれるコンピュータなどの電子商店街サーバ２と異なるコンピュータに含まれるプロセッサ１１等により実現されてもよい。また、電子商店街サーバ２をなくし、電子商店街サーバ２が実現するすべての機能の処理を薬局システム１が代わりに実行してもよい。

薬局システム１は、図示しない、薬局にある薬の種類毎の在庫を管理する機能と、薬をユーザに渡す際に必要な情報を出力する機能とをさらに含む。これらの機能は、薬局システム１に含まれるプロセッサ１１等がプログラムを実行することにより実現される。

ユーザ端末３は、電子商店街サーバ２等から受信したデータに基づいて画面を提示する機能や、その画面についてユーザが入力した情報を電子商店街サーバ２等に送信する機能を実現する。これらの機能は、例えばユーザ端末３に含まれるプロセッサ１１等がブラウザなどのプログラムを実行し、電子商店街サーバ２等から受信したデータに応じた処理をすることで実現される。またブラウザではなく、専用のアプリケーションプログラムによりこれらの機能が実現されてもよい。

病院サーバ４は、図示しない、医師が入力した電子処方箋の情報をユーザ端末３または薬局システム１に送信する機能と、薬局システム１等から電子処方箋にかかる処方薬が販売されているかの問合せを受け付ける機能と、記憶部１２に記憶された情報に基づいてその処方薬が販売されているか否かを薬局システム１等に返信するとともに、その処方薬が販売されていない場合にその電子処方箋にかかる処方薬が販売されたことを示す情報を記憶部１２に記憶する機能とを実現する。これらの機能は、病院サーバ４に含まれるプロセッサ１１がプログラムを実行することにより実現される。

次に、本実施形態の一例における処方薬の販売過程の概要について説明する。図４は、処方薬の販売過程の一例を概略的に示す図である。この例では、はじめに、病院にて医師が電子処方箋を発行し（１．処方箋発行）、病院サーバ４は発行された電子処方箋をユーザ端末３へ送信する（２．処方箋送信）。そして、ユーザはユーザ端末３を用いて電子商店街サーバ２が提供する処方薬販売サービスにログインし（３．ログイン）、ユーザは電子商店街サーバ２へユーザを認証する認証情報に紐付けられた電子処方箋を送信する（４．処方箋送信）。そして、電子商店街サーバ２は受信した電子処方箋に含まれる薬を販売できる薬局のリストの情報をユーザ端末３に送信する（５．薬局リスト提示）。ユーザはそのリストに含まれる薬局を選択し、ユーザ端末３は選択された薬局の情報を電子商店街サーバ２に送信する（６．薬局選択）。すると、電子商店街サーバ２は選択された薬局に対応する薬局システム１に電子処方箋を送信し（７．処方箋送信）、決済処理が実行される。そして、薬局システム１は、処方箋を管理する病院サーバ４にこの電子処方箋が他の薬局等により利用されているか問い合せる（８．処方箋利用状況確認）。ここで、電子処方箋が利用されていることは、この電子処方箋に基づく薬が既に販売されている状態か、あるいはその薬の販売が進行している状態を示す。この電子処方箋による処方薬が他の薬局により利用されていない場合には、薬剤師が入力した説明文がユーザに向けて送信される（９．説明文送付）。ユーザがその説明文を確認したことを薬剤師が確認すると（１０．確認）、薬局は処方薬をユーザに向けて発送する（１１．発送）。

図５は、図４の例における病院サーバ４、ユーザ端末３、電子商店街サーバ２、薬局システム１の間での通信を示すシーケンス図である。図５は、病院サーバ４、ユーザ端末３、電子商店街サーバ２、薬局システム１の間でやりとりされる情報の時系列を示している。図６は、電子商店街サーバ２の処理の概要を示すフロー図である。以下では、図５に示すシーケンス図と、図６や他の図に示されるフローチャートとを用いて電子商店街サーバ２が実現する機能を説明する。

はじめに、病院サーバ４は、医師が入力した電子処方箋を記憶部１２に格納し、その電子処方箋を通信部１３を用いて送信し、ユーザ端末３は電子処方箋を受信する。

ユーザ認証部５１は、主に電子商店街サーバ２に含まれるプロセッサ１１、記憶部１２および通信部１３により実現される。ユーザ認証部５１は、ユーザ端末３からユーザ認証情報を受信することによりそのユーザ認証情報を取得し、ユーザ端末３を用いてアクセスするユーザを認証する（ステップＳ１０１）。図５の例では、以下のような処理を実行する。ユーザ認証部５１は、電子商店街サーバ２にアクセスするユーザが操作するユーザ端末３に、認証に必要な情報を入力させるログイン画面を表示させる情報を送信する。そして、その送信された情報に基づいてユーザ端末３がログイン画面を出力し、そのログイン画面に対してユーザが認証のための情報を入力すると、ユーザ認証部５１はユーザ端末３からその入力された情報を含むユーザ認証情報を受信する。ユーザ認証情報は、電子商店街サーバ２にアクセスするユーザであって、後に電子処方箋を示す情報を送信するユーザを特定する情報である。

図７は、ログイン画面の一例を示す図である。図７の例では、ユーザはユーザＩＤおよびパスワードを入力し、ユーザ認証部５１はユーザＩＤおよびパスワードを示す情報を含むユーザ認証情報を受信する。ここで、ユーザ認証情報は必ずしもユーザＩＤとパスワードでなくてもよく、ユーザを認証する手法に応じた他の情報であってもよい。例えばユーザ認証情報にクライアント証明書を含んでもよいし、指紋などのユーザの生体情報を含んでもよい。また、ユーザ端末３が実行するブラウザのクッキーにユーザ認証情報としてハッシュ値が格納されてもよい。ユーザ端末３が処方薬販売サービスにアクセスすると、ブラウザは自動的にそのユーザ認証情報を送信してもよい。この場合、ユーザ認証部５１がそのハッシュ値に基づいて、ユーザＩＤやパスワードの入力なしにユーザを認証してもよい。

そして、ユーザ認証部５１はユーザ情報格納部７１に格納されたパスワードを示す情報とユーザを特定する情報とに基づいて、そのユーザ認証情報が示すユーザが正規のユーザであるか否かを判定する。そのユーザが正規のユーザである場合には、ユーザ認証部５１はその認証情報を送信したセッションに対してセッションＩＤを割り当て、セッションＩＤをユーザ端末３に返信する。ユーザ端末３は、これ以降、電子商店街サーバ２に情報を送信する際にはその情報とともにこのセッションＩＤを送信する。なお、ユーザ認証部５１はこのセッションＩＤをユーザＩＤに紐付けて記憶部１２に格納する。なお、セッションＩＤは電子商店街サーバ２と異なるサーバに格納されてもよい。また、ユーザ端末３が電子処方箋を受信する前に、ユーザが認証されセッションＩＤとユーザＩＤとが紐付けられていてもよい。

ここで、セッションＩＤはユーザと電子商店街サーバ２との通信のセッションを規定する情報であり、例えば同じセッションＩＤを有する一連のｈｔｔｐ通信は同一のセッションとして扱われる。例えば、セッションは、ここに示すセッションＩＤによりアプリケーションプログラムが実現されてもよいし、ＴＣＰのセッションのように、通信プロトコルにより実現されてもよい。

図８は、ユーザ情報の一例を示す図である。各ユーザについてのユーザ情報は、ユーザＩＤと、図７でユーザが入力するユーザＩＤに相当するメールアドレスと、パスワードとを含む。またユーザ情報は、ユーザの属性である氏名、生年月日、性別、保険者番号、区分、アレルギー、病歴、副作用履歴等の情報も含む。なお、パスワードの項目には、パスワードが暗号化されたデータまたはハッシュ関数によるパスワードのハッシュ値が格納されている。ユーザ情報は、ユーザが電子処方箋を示す情報を送信する前に入力されている情報であるが、ユーザ情報はユーザの状況の変化に応じて適宜メンテナンスされ、原則としてユーザが電子処方箋を示す情報を送信する時点のユーザの状態を示すが、ユーザの状況の変化がユーザ情報に反映されていないこともありうる。この属性情報は、後述する購入申込時に入力された質問への回答を補完する情報として用いられる。

処方箋受信部５２は、主にプロセッサ１１、記憶部１２および通信部１３により実現される。処方箋受信部５２は、ユーザが認証された後に、ユーザからユーザ認証情報に紐付けられた電子処方箋を取得する（ステップＳ１０２）。図５の例では、処方箋受信部５２はユーザ端末３に電子処方箋を送信させるための処方箋送信画面の情報を送信し、処方箋送信画面に対するユーザの操作によりユーザ端末３から送信された電子処方箋を受信する。ここで、ユーザ認証情報と電子処方箋とは、同じセッション中に受信されることにより紐付けられている。

図９は、処方箋送信画面の一例を示す図である。ユーザ端末３は処方箋受信部５２が送信した処方箋送信画面の情報に基づいて図９に示す画像を表示出力デバイスに表示させる。そして、ユーザが電子処方箋のファイルを選択し処方箋送信ボタンを押下すると、ユーザ端末３は電子処方箋を処方箋受信部５２に向けて送信し、処方箋受信部５２はセッションＩＤなどの情報とともに電子処方箋を受信する。ここで、セッションＩＤはユーザに紐付けられており、セッションＩＤとともに電子処方箋が送信されることでユーザと電子処方箋とが紐付けられる。

なお、処方箋受信部５２がユーザ端末３から受信する電子処方箋を示す情報は、電子処方箋そのものでなくてもよい。例えば、電子処方箋を示す情報は電子処方箋を特定する処方箋ＩＤであってもよい。この場合、ユーザ認証情報に紐付けられた処方箋ＩＤは電子処方箋に紐付けられ、処方箋受信部５２はその処方箋ＩＤに基づいて病院サーバ４から電子処方箋をダウンロードする。また、ユーザ認証部５１および処方箋受信部５２は、ユーザ認証情報と電子処方箋とをほぼ同じタイミングで受信してもよい。例えば処方箋送信画面の情報に、ユーザＩＤやパスワードを入力させるための情報を含ませておき、ユーザ認証情報と電子処方箋を示す情報とがその画面への入力に応じて受信されても、ユーザ認証情報と電子処方箋を示す情報とがおなじセッションに受信される。

図１０および図１１は、電子処方箋に含まれる情報の一例を示す図である。電子処方箋は、電子処方箋を特定する処方箋ＩＤと、患者の属性に関する情報と、処方箋を作成した医師および病院に関する情報と、処方される薬に関する情報と、処方箋の発行日および有効期限とを含む。図１０からわかるように、電子処方箋は患者の属性についての情報として、氏名、生年月日、性別、保険者番号、保険者か非扶養者かの区分、患者コードを含み、医師および病院に関する情報として、病院コード、病院名、医師名、医師連絡先を含む。また、図１１からわかるように、処方される薬に関する情報として、薬の項目ごとに、処方薬、用法、一回あたりの量、処方日数、その薬の総量、後発薬への変更を禁止するか否かの変更不可フラグ、分割発送許可フラグ、分割投薬制限といった情報の欄を含む。処方薬の欄は薬を特定する情報であり、その情報は薬の成分および剤形であってもよいし、薬の商品名であってもよい。分割投薬制限は、分割発送する場合に１回に投薬できる薬の最大量を日数で示す項目であり、例えば保存が難しい薬の場合にはその日数は使用期限に相当する日数である。

処方箋確認部５３は、主にプロセッサ１１および記憶部１２により実現される。処方箋確認部５３は、電子処方箋に紐付けられたユーザ認証情報とユーザ情報格納部７１に格納されるユーザ情報と電子処方箋とに基づいて、ユーザ認証情報に対応するユーザの情報と、電子処方箋に含まれる患者の情報とが対応するか否か確認するための処理を実行する（ステップＳ１０３）。より具体的には、はじめに、処方箋確認部５３は電子処方箋とともに送信され、ユーザ認証情報と電子処方箋とを紐付けるセッションＩＤから、そのセッションＩＤに紐付けて記憶部１２に格納されたユーザＩＤを取得することでユーザを特定する。そして、処方箋確認部５３はそのユーザＩＤを有するユーザ情報から氏名、生年月日、性別、保険者番号、区分の情報を取得し、それぞれ電子処方箋に含まれる患者の氏名、生年月日、性別、保険者番号、区分と照合する。そして、照合された情報が予め定められた程度より類似であるまたは一致する場合は、ユーザ認証情報に対応するユーザ（電子処方箋を送信したユーザ）の情報と電子処方箋に含まれる患者の情報とが対応すると判定する。なお、ユーザ情報に病院コードと患者コードとを記録し、処方箋確認部５３が電子処方箋に含まれる病院コードと患者コードと照合することにより電子処方箋を送信したユーザの情報と電子処方箋に記載された患者の情報とが対応するか判定してもよい。

また、処方箋確認部５３におけるユーザ認証情報に対応するユーザの情報と、電子処方箋に含まれる患者の情報とが対応するか否か確認するための処理は、電子商店街サーバ２を操作する操作者が確認した結果を取得する処理であってもよい。例えば、処方箋確認部５３がセッションＩＤから特定されたユーザＩＤを有するユーザ情報と、電子処方箋に含まれる患者の情報とを並べて表示させる画面の情報を生成し、その画面に基づいて操作者がユーザの情報と患者の情報とが対応するか否か確認した結果を処方箋確認部５３が取得してもよい。

販売制御部５４は、主にプロセッサ１１および記憶部１２により実現される。販売制御部５４は、処方箋確認部５３による確認の処理の結果に基づいて、電子処方箋に応じた薬の販売処理が実行されるよう制御する。より具体的には、販売制御部５４は、電子処方箋を送信したユーザの情報と患者の情報とが対応すると判定された場合に（ステップＳ１０４のＹ）、以降の処理である、選択情報生成部５６、選択部５７、決済処理部５８、説明文入力部５９、説明文出力部６０、確認結果取得部６１、発送スケジュール生成部６２、発送管理部６３等が行う処理を開始させる（ステップＳ１０５）。また、販売制御部５４は、販売状況確認部５５による確認の結果にさらに基づいて電子処方箋に応じた薬の販売処理を進めるよう制御するが、これについては後述する。

選択情報生成部５６は、主にプロセッサ１１、記憶部１２および通信部１３により実現される。選択情報生成部５６は、電子処方箋に指定された薬を複数の選択肢からユーザに選択させるための情報を生成する。複数の選択肢のそれぞれは、１または複数の薬の組合せを含んでいる。

ここで、電子処方箋に含まれる薬の項目において一般名で薬を特定する場合には、その一般名により特定され互いに異なる複数の薬の商品（薬の種類）が存在することが多い。その一般名で特定され互いに異なる複数の薬の商品の中には、一般的には先発薬と後発薬とが含まれる。先発薬は薬の商品のうち、特許権を有する企業がはじめに発売するものであり、後発薬は特許権の存続期間が満了した後に他の企業が販売するものである。先発薬、後発薬（ジェネリック医薬品とも呼ばれる）はそれぞれ薬の種類の１つであり、先発薬と後発薬とは互いに商品名や販売企業が異なりかつ薬効について互換性を有する。ある一般名の薬について先発薬の商品と１または複数の後発薬の商品との両方が存在する場合もあるし、後発薬の商品が存在しない場合もあるし、後発薬の商品しかない場合もある。また、電子処方箋において薬の商品名（例えば先発薬）によって薬を特定する場合も、もちろんその薬を代替することのできる１または複数の薬の商品（例えば後発薬）が存在しうる。

選択情報生成部５６は、例えば電子処方箋において一般名で指定されたある薬の項目について、上述の選択肢のうち１つがその一般名で指定されるある薬の商品を含み、選択肢のもう１つがその一般名で指定される他の薬の商品を含むように情報を生成する。さらに、選択情報生成部５６は、上述の選択肢のうち１つの選択肢は先発薬を含み、他の選択肢はこの先発薬の代替薬である後発薬を含むように情報を生成してよい。後者の場合、選択情報生成部５６が生成する情報は、電子処方箋により指定される薬として、先発薬とその代替薬である後発薬とのうちいずれかを選択させる情報である。また、選択情報生成部５６はその情報をユーザが操作するユーザ端末３に向けて送信する。図５の例では、前述の選択肢のうち１つの選択肢はある薬局が販売する薬を含み、他の選択肢は他の薬局が販売する薬を含む。そのため、その情報は、電子処方箋に指定された薬を販売する薬局のうちいずれかをユーザに選択させるための情報（図５の薬局選択画面に相当する）でもある。

選択部５７は、主にプロセッサ１１、記憶部１２および通信部１３により実現される。選択部５７は、先発薬と後発薬のいずれかをユーザに選択させるための情報に対して、ユーザが先発薬と後発薬のいずれかを選択したかを示す情報とユーザが選択した薬局を示す情報を通信部１３を介して取得する。

図１２はユーザに薬を選択させる際の処理の一例を示すフロー図である。はじめに選択情報生成部５６は、複数の薬局に対応する複数の薬局システム１のそれぞれに薬のリストを要求する情報を送信し、選択情報生成部５６はその薬局システム１のそれぞれから主に先発薬からなる薬のリストおよび主に後発薬からなる薬のリストを取得する（ステップＳ２０１）。この処理は図５の「薬リスト問合せ」に相当する。

薬局システム１は選択情報生成部５６から薬のリストを要求する情報を受信すると、薬種類情報に含まれる薬の在庫情報を確認し、在庫のある先発薬を中心とする薬の組合せを示すリストと、在庫のある後発薬を中心とする薬の組合せを示すリストとを生成する。また薬局システム１は生成されたリストを選択情報生成部５６に送信する。ここで、薬局システム１がリストを生成する処理を、電子商店街サーバ２に含まれる選択情報生成部５６が代わりに行ってもよい。

図１３は、薬種類情報の一例を示す図である。薬種類情報は、薬ごとに、薬ＩＤ、薬名称、一般名、後発区分、投薬制限最小、投薬制限最大、在庫情報としての在庫量、薬の説明を含む。商品名は製薬企業が名づけた薬の名前であり、一般名は薬の成分や剤形などに対応し、同じ成分や剤形の薬の一般名は、製薬企業にかかわらず同じとなる。後発区分は、この薬が先発薬と後発薬かとのうちどちらであるかを示す。説明は、薬の服用時の注意事項を示す文章を含む。投薬制限最小は、分割発送をする場合などに一度に送ることのできる薬の最小量を日数で示し、投薬制限最大は、一度に送ることのできる薬の最大量を日数で示す。

そして、選択情報生成部５６は主に先発薬からなる薬のリストを含む選択肢と主に後発薬からなる薬のリストを含む選択肢とを含む薬局選択画面のデータを生成し（ステップＳ２０２）、薬局選択画面のデータをユーザ端末３に送信する（ステップＳ２０３）。ここで、複数の選択肢には必ずしも先発薬からなる薬のリストと後発薬からなる薬のリストの両方を必ずしも含まなくてよい。また、選択情報生成部５６は、ユーザにより詳細を表示させることを指示された選択肢（薬のリストに対応）についての詳細を示す薬詳細画面のデータを生成し送信する（ステップＳ２０４）。

図１４は、薬局選択画面の一例を示す図である。選択情報生成部５６は、薬局と先発薬／後発薬との組合せ（選択肢に対応）ごとに、薬のリストと、支払額と、この組合せについて詳細を表示させる指示のための「詳細」ボタンとを含む薬局選択画面を表示させるデータを生成する。薬のリストは複数の薬のそれぞれについて、薬の商品名と総量の情報を含む。選択情報生成部５６は、複数の薬局のうち、ユーザが予めかかりつけ薬局として指定した薬局と、当該薬局より支払い総額が安くなる薬のリストを生成した薬局と、これらの薬局と配送に関するサービスが異なる薬局とを選択し、その選択された薬局について薬局選択画面を生成してよい。また、選択情報生成部５６が生成する画面の情報は、薬局選択画面と異なってもよい。例えば、選択情報生成部５６はかかりつけ薬局など１つの薬局についての複数のリストのみを含む画面の情報を生成してもよい。

送信された薬局選択画面のデータに基づいてユーザ端末３が薬局選択画面を表示出力デバイスに表示させ、ユーザが「詳細」ボタンを押下することによりいずれかの薬局についての薬のリストについての詳細の表示を指示すると、ユーザ端末３はその選択肢の詳細の表示が指示されたことを示すデータを送信する。そして、選択情報生成部５６は、その表示の指示についてのデータが受信されると、その指示された選択肢について、薬詳細画面を表示させるデータを生成する。

図２６は、薬詳細画面の一例を示す図である。選択情報生成部５６は、この選択肢についてリストに含まれる薬のそれぞれの詳細と、１または複数の質問と、ユーザがこの選択肢を選択したことを示す情報をユーザ端末３に送信させる「購入申込」ボタンとを含む薬詳細画面を表示させるデータを生成し、このデータをユーザ端末３に向けて送信する。選択情報生成部５６は、電子処方箋に含まれる複数の薬の一般名のそれぞれ、または選択肢に含まれる複数の薬の商品（種類）のそれぞれに関連づけられた質問を取得する。選択情報生成部５６はその質問の重複を削除した上で、ユーザに対する質問の情報を生成する。この質問は、ユーザの属性に関するものである。選択情報生成部５６はユーザ情報に含まれるユーザの属性の情報から質問の回答を取得できる場合（例えば年齢や性別、アレルギー歴）にはその属性に関する質問を削除してもよいし、またユーザ情報に含まれる属性（例えば性別）に当てはまらない質問（例えば男性に対する妊娠に関する質問）を削除してもよい。また、薬詳細画面のデータは、「購入申込」ボタンが押下された際に、ユーザ端末３がそれぞれの質問についての回答の情報を送信させるデータを含む。

送信された薬詳細画面のデータに基づいてユーザ端末３が薬詳細画面を表示出力デバイスに表示させ、ユーザが「購入申込」ボタンを押下することにより、複数の選択肢のうち詳細が表示されたこの選択肢（いずれかの薬局についての薬のリスト）について薬を購入することを選択すると、ユーザ端末３は選択された薬局や選択された薬のリストを示すデータを送信する。選択部５７は選択された薬局や選択された薬のリストを示すそのデータを受信する（ステップＳ２０５）。すると、処方薬の注文が受け付けられ、販売制御部５４は注文情報格納部７３に該当する薬のリストについての注文情報および質問に対する回答の情報を格納する。ここで、注文情報を格納する前に、さらにユーザ端末３から送付先や決済方法のデータを受信し、それらを注文情報に格納してもよい。また販売制御部５４は、ユーザに向けて注文を受け付けたことを示す受付メッセージを送信する。選択された薬局に電子処方箋を送信する（ステップＳ２０６）。受付メッセージはユーザ端末３に向けて送信される画面の情報であってもよいし、ユーザ宛の電子メールであってもよい。

電子処方箋の送信については、薬局システム１に直接的に電子処方箋を送信してもよいし、薬局の担当者に向けてその薬局への注文が受け付けられた旨のメッセージを送信し、その担当者が操作する薬局システム１が電子商店街サーバ２へアクセスし電子処方箋を取得してもよい。

図１５は、注文一覧画面の一例を示す図である。注文一覧画面は、薬局の担当者が電子商店街サーバ２にアクセスした際に表示される画面であり、この画面の情報は、販売制御部５４により生成される。販売制御部５４は、注文一覧画面としてその薬局に対する注文の一覧を表示出力デバイスに出力させる情報を生成する。図１５の例では、その情報は、注文ごとに、注文を受け付けた日時、注文を特定する注文番号、決済方法、決済ステータス、発送ステータス、処方薬の販売状況を示す処方箋利用状況の情報を含む注文一覧画面の情報を含む。

薬局の担当者が注文番号を選択すると、販売制御部５４はその注文の詳細を示す注文詳細画面の情報を担当者が操作するコンピュータ（主に薬局システム１）に向けて送信する。図１６は、注文詳細画面の一例を示す図である。注文詳細画面により出力される情報は、電子処方箋、ユーザの質問に対する回答、ユーザのアレルギー歴や副作用履歴、決済方法、薬の送付先、決済ステータス、発送ステータス、処方箋利用状況を含む。この注文詳細画面の情報は、図５の電子商店街サーバ２から薬局システム１に送信される電子処方箋に相当する。

決済処理部５８は、プロセッサ１１、記憶部１２および通信部１３により実現される。決済処理部５８は、薬局の担当者が注文詳細画面で決済依頼ボタンを押下したことを示す情報（決済依頼）を受信する。決済処理部５８は、決済依頼を受信すると、ユーザにより指定された決済方法（例えばクレジットカード）による決済処理を通信部１３を用いて実行し、決済処理の結果を注文情報に格納する。薬局の担当者は、決済処理の結果は、注文一覧画面や注文詳細画面により確認する。なお、決済処理を行うタイミングは、後述する販売状況を確認した後、薬局が発送を行うまでの間のいずれかのタイミングであってよい。

販売状況確認部５５は、主にプロセッサ１１、記憶部１２および通信部１３により実現される。販売状況確認部５５は、注文にかかる電子処方箋に基づく薬が既に販売されているか否かを確認するための処理を実行する。この処理は、この処方薬販売システムで既にその電子処方箋に基づく薬が販売されたか否かを確認する処理と、他の薬局がこの電子処方箋にかかる薬を販売したか確認する処理と、を含む。販売状況確認部５５の２種類の処理のうち後者の処理は、図５の処方箋利用状況確認に相当する。

まず、販売状況確認部５５が行う２種類の処理のうち前者の処理について説明する。この処理では、販売状況確認部５５は注文情報格納部７３に、今回の電子処方箋に紐付けられた注文があるか否かを確認する。より具体的には、これまでに処方箋確認部５３の処理が行われたあとに販売制御部５４などが注文情報として、注文と電子処方箋の処方箋ＩＤとを注文情報格納部７３に格納しておき、販売状況確認部５５は今回の電子処方箋の受信に対応する注文と異なりかつ同じ処方箋ＩＤを含む注文の注文情報が存在するか否かを確認する。また販売状況確認部５５はその注文情報が存在する場合に、その注文情報に含まれるステータス（売買に関する情報）が、販売処理が進んでいることを示すか否かを確認する。このステータスが販売処理が進んでいることを示す場合、販売状況確認部５５はこの電子処方箋に基づく薬が販売されている、もしくはその薬の他の販売処理が進行していると判定し、処方箋利用状況のステータスを「確認済ＮＧ」に更新する。なお、この処理は、電子商店街サーバ２が電子処方箋を受信してから実際に発送する前であれば、いつ実行されてもよい。

次に販売状況確認部５５が行う２種類の処理のうち後者の処理について説明する。この後者の処理は、病院サーバ４への問合せに基づいて電子処方箋に基づく販売がされたか否かを示す情報を取得する処理である。図１７は、販売状況を確認する際の処理の一例を示すフロー図である。販売状況を確認する際には、はじめに、販売状況確認部５５は、通信部１３を用いて処方箋を管理する病院サーバ４に処方箋ＩＤを含む問合せ要求を送信し、病院サーバ４から、注文にかかる電子処方箋について販売状況を取得する（ステップＳ３０１）。販売状況は、複数の薬局のうちいずれかの薬局により薬が販売されるか否か、言い換えれば、いずれかの薬局により電子処方箋が利用されたか否かを示す情報である。そして、その販売状況が、いずれの薬局も薬を販売していないことを示す場合には（ステップＳ３０２のＹ）、販売状況確認部５５は、病院サーバ４に処方箋ＩＤを含む更新要求を送信し（ステップＳ３０３）、病院サーバ４に含まれる記憶部１２に、注文にかかる電子処方箋の販売状況を、販売状況がこの注文を受け付けた薬局が薬を販売することを示すように更新させる。また販売状況確認部５５は、注文情報に含まれる処方箋利用状況のステータスを、販売状況を確認し販売処理を進めることができることを示す「確認済ＯＫ」のステータスに更新する（ステップＳ３０４）。一方、その販売状況が、いずれかの薬局が薬を販売したことを示す場合には（ステップＳ３０２のＮ）、販売制御部５４は、この電子処方箋にかかる薬の販売処理ができないことを示すように注文情報に含まれる処方箋利用状況のステータスを「確認済ＮＧ」に更新する（ステップＳ３０５）。「確認済ＮＧ」のステータスは、電子処方箋が他の薬局について利用されかつ、本システム（本薬局）では、後続の販売処理を進められないことを示す。このステータスでは、電子処方箋に基づく薬は他の薬局により既に販売されたか販売処理が進行中であり、仮に薬を販売するとユーザに二重に薬を販売することを示している。

この病院サーバ４に電子処方箋に基づく薬の販売が既にされたか否かを問い合せる処理は、図４や図５では説明文の確認などの前になっているが、この処理のタイミングは前後してもよい。例えば、説明確認データの送受信後であってもよいし、発送指示情報の送信直前であってもよい。これらの例では、同じ電子処方箋について複数の注文が並行して処理される恐れがより大きいが、その複数の注文について２以上の発送がされることを防ぐことができる。また、ユーザ端末３側のプログラムが電子処方箋が利用されたか否かを示す情報を保持し、販売状況確認部５５が病院サーバ４の代わりにユーザ端末３からその情報を受信することで処方箋利用状況のステータスを更新してもよい。この場合、ユーザ端末３から電子処方箋を電子商店街サーバに送る際に（図４の４．処方箋送信）、利用されたか否かを示す付加情報を付加して送ってよい。この場合、電子商店街サーバの販売状況確認部５５は、上記の付加情報を確認することにより既に電子処方箋にかかる薬の注文がなされているかを示す販売ステイタスを確認できる。

処方箋利用状況のステータスが「確認済ＯＫ」に更新されると、販売制御部５４は電子処方箋に応じた販売処理（発送スケジュールの決定以降の処理）の実行がされるよう制御する。薬局の担当者は、処方箋利用状況のステータスを、注文一覧画面や注文詳細画面により確認し、販売に関する操作を続けてよい。一方、処方箋利用状況のステータスがこの電子処方箋にかかる薬の販売処理ができないことを示す場合には、販売制御部５４はこれ以降は販売に向けた処理を進められないよう制御し、薬局の担当者は、このステータスの更新をうけて必要に応じて返金などを行う。

説明文入力部５９は、プロセッサ１１、記憶部１２および通信部１３を中心として実現される。説明文入力部５９は、注文申込をしたユーザに関する情報を薬剤師に提示し、注文にかかる薬局の薬剤師から入力された注文にかかる説明文（図５の説明文入力データに相当）を受け付ける。ユーザに関する情報はユーザ情報に含まれる属性の情報とユーザの質問の回答に含まれるユーザの属性の情報とを含み、ユーザに関する情報は、薬剤師が説明文を作成したり処方が正しいかを判断する際に利用される。説明文入力部５９は、受付けられた当該説明文を記憶部１２を含む説明文格納部７２に格納する。なお、図１５の例では、説明文入力部５９の処理は、注文にかかる薬局の薬剤師が注文詳細画面で説明ボタンを押下し、薬剤師が操作するコンピュータが説明文の入力を開始する要求を説明文入力部５９へ送信すると開始される。

また、属性取得部６５は、電子商店街サーバ２に含まれるプロセッサ１１、記憶部１２および通信部１３を中心として実現される。属性取得部６５は、受信された電子処方箋にかかる患者の属性情報を、ユーザの属性情報を格納するユーザ情報格納部７１から取得する。説明文入力部５９は、この患者の属性情報に基づいて注文申込をしたユーザに関する情報を薬剤師に提示する。

図１８は、説明文入力画面の一例を示す図である。説明文入力画面の情報は、注文にかかる電子処方箋の情報と、ユーザ情報に含まれる注文を申込したユーザの属性の情報と、薬剤師がユーザに説明する説明文のメッセージの件名および本文を入力させる欄の情報と、入力されたメッセージを説明文入力部５９に向けて送信させるボタンの情報とを含む。説明文入力部５９は、これらの情報を含む説明文入力画面の情報を生成し、薬局システム１に向けて送信する。薬剤師は受信した情報に応じた説明文入力画面に表示される電子処方箋およびユーザのアレルギー歴や病歴、副作用履歴を参照し、説明文のメッセージの件名や本文を薬局システム１に入力する。そして、薬剤師が送信ボタンを押下すると、薬局システム１は説明文のメッセージを説明文入力部５９に向けて送信する。また説明文入力部５９はそのメッセージを受付け、説明文格納部７２に格納する。

なお、説明文入力部５９は、電子処方箋に含まれる薬に応じて薬種類情報から説明文に記載する事項を取得し、その事項を含む説明文の案を生成し、その説明文の情報を含む説明文入力画面の情報を送信してもよい。例えば、説明文入力画面の本文の欄に表示される説明文の案を薬剤師が修正することで、ユーザへの説明文が入力されてもよい。

説明文出力部６０は、主にプロセッサ１１、記憶部１２および通信部１３により実現される。説明文入力部５９は説明文のメッセージを受信すると、説明文出力部６０は注文にかかるユーザに向けて説明文（図５の説明文データに相当）を出力する。

図１９は、説明文出力画面の一例を示す図である。説明文出力画面の情報は図５の説明文データに相当し、説明文出力部６０が生成し送信する説明文出力画面の情報は、説明文入力部５９が受付けた説明文の件名および本文の情報と、説明文に含まれる確認項目に応じて配置されるチェックボックス３１の情報と、ユーザが説明文を確認したことを示す説明確認データをユーザ端末３に送信させる送信ボタンの情報とを含む。なお、説明文出力部６０は、説明文入力画面で入力された四角の記号がチェックボックス３１に変換されるように説明文出力画面の情報を生成する。ユーザが説明文出力画面を確認し、チェックボックス３１をチェックしてＯＫボタンを押下すると、ユーザ端末３は説明文が確認されたことを示す説明確認データを送信する。なお、ユーザがチェックボックス３１をチェックしない場合や、説明文に文字列を追記した場合には、その追記された説明文のメッセージを確認結果取得部６１に向けて送信する。

確認結果取得部６１は、プロセッサ１１、記憶部１２および通信部１３を中心として実現される。確認結果取得部６１は、ユーザ端末３から送信される説明確認データを受信し、注文にかかる注文情報に含まれる説明ステータスを、説明確認データが受信されたことを示すステータスに更新する。これにより、注文情報格納部７３に説明確認データが受信されたことを示す情報が格納される。薬局の担当者は、更新された説明ステータスを、メッセージ確認画面、注文一覧画面や注文詳細画面により確認し（図５の説明ステータス確認に相当）、販売に関する操作を続ける。

図２０は、メッセージ確認画面の一例を示す図である。メッセージ確認画面のうちメッセージ一覧の欄には、注文にかかるすべてのメッセージの件名が配置される。説明確認データを受信した場合にはメッセージ一覧の欄に説明文がユーザにより確認されたことを示す文字列（「ユーザ確認済」）が配置される。またメッセージ欄には、一覧のメッセージのうち選択されたメッセージの本文が配置され、その欄の下には、そのメッセージを薬剤師が確認した際に押下する「薬剤師確認」ボタンが配置される。なお、メッセージ確認画面で新規メッセージのボタンが押下されると、説明文入力部５９はさらに説明文入力画面を表示してもよい。

薬剤師が「薬剤師確認」ボタンを押下すると、販売制御部５４は注文情報の説明ステータスを「確認済」に更新する。また、これにより、販売制御部５４は発送スケジュールを決定する処理を進める。

発送スケジュール生成部６２および発送管理部６３のそれぞれは、主にプロセッサ１１、記憶部１２および通信部１３により実現される。発送スケジュール生成部６２は、電子処方箋に含まれる薬の情報およびユーザの希望のうち少なくとも一方に基づいて、薬を１回で、または複数回に分けて発送するスケジュールを生成する。例えば、発送スケジュール生成部６２は電子処方箋に含まれる薬の情報に基づいて発送スケジュールの案を生成し、生成されたスケジュールの案を示すデータを薬局の担当者に向けて出力し（図５の発送スケジュール確認画面に相当）、担当者がスケジュールを承認したことを示す情報を受信すると、発送スケジュール生成部６２は承認されたスケジュールを電子処方箋にかかる薬を発送する正式な発送スケジュールとして生成する。

以下では発送スケジュールを生成する処理についてさらに説明する。図２１は、発送スケジュールを生成する処理の概要を説明する図である。はじめに、発送スケジュール生成部６２は、電子処方箋に含まれる１または複数の薬のうち、分割発送の欄が許可となっており、分割発送が許可されている薬について、薬種類情報から投薬制限最大に格納されている日数と、電子処方箋の分割投薬制限の日数とを取得し、取得された日数の最小値（以下では最大分割間隔と記載する）が電子処方箋の薬の処方日数より大きい薬を分割対象リストに追加する（ステップＳ４０１）。そして、分割対象リストに属する薬がある場合には（ステップＳ４０２のＹ）、薬を分割して発送する発送スケジュールの案を生成する（ステップＳ４０３）。ここで、以下では薬種類情報の投薬制限最小に格納されている日数を最小分割間隔と記載する。

図２２は、発送スケジュールの案を作成する処理の一例を示すフロー図である。発送スケジュール生成部６２は、電子処方箋に存在し、かつ分割対象リストに属さない薬について、その薬の発送日に最短で発送可能となる日（最短発送日）を設定する（ステップＳ５０１）。つぎに、発送スケジュール生成部６２は、分割対象リストに属する１または複数の薬について最大分割間隔の最小値を求める（ステップＳ５０２）。この最小値は、分割発送をする際に隣り合う発送日の間の間隔になる可能性が高いので、基本間隔と記載する。次に発送スケジュール生成部６２は、分割対象リストに属する薬のうち、基本間隔の値が最小分割間隔以上かつ最大分割間隔以下となる条件を満たす薬を選択し、その選択された薬について、初回の発送日に最短発送日を設定し、以降の発送日には、最短発送日から処方日数経過するまでの日付のうち、前の発送日との間隔が基本間隔となる日付を設定する（ステップＳ５０３）。また発送スケジュール生成部６２は発送日が設定された薬を分割対象リストから削除する（ステップＳ５０４）。

そして、発送スケジュール生成部６２は、分割対象リストに属する残りの薬のうち、（ｎ×基本間隔）の値（ｎは２以上の整数）が最小分割間隔以上かつ最大分割間隔以下となる条件を満たす薬を選択し、その選択された薬について、初回の発送日に最短発送日を設定し、以降の発送日には、最短発送日から処方日数経過するまでの日付のうち、前の発送日との間隔が（ｎ×基本間隔）となる日付を設定する（ステップＳ５０５）。また発送スケジュール生成部６２は発送日が設定された薬を分割対象リストから削除する（ステップＳ５０６）。そして、発送スケジュール生成部６２は分割対象リストに薬が残っている場合には、その薬について初回の発送日を最短発送日とし、以降の発送日には、最短発送日から処方日数経過するまでの日付のうち、前の発送日との間隔が最大分割間隔となる日付を設定する（ステップＳ５０７）。これにより薬ごとの発送スケジュールの案が生成される。

発送スケジュールの案が生成されると、発送スケジュール生成部６２は薬ごとに、その案に含まれる発送日と、電子処方箋から取得される１日の用量に応じて、各発送日に送る量を算出する（ステップＳ４０４）。図１１に示す電子処方箋の例では、１日の用量は各日の用法から求められる回数に１回辺りの量を掛けた値となる。発送スケジュール生成部６２は、各発送日に送る量として、次の発送日がある場合には１日の用量に、今回の発送日と次の発送日との間隔をかけた値を、次の発送日がない場合には、処方日数から初回発送日と今回の発送日との間隔の日数を引いた値を、１日の用量にかけた値を求める。

そして、発送スケジュール生成部６２は、求められた薬ごとの発送日と発送日に送る薬の量とに基づいて、発送スケジュール確認画面のデータを生成して出力し、薬剤師の承認を得る（ステップＳ４０５）。

図２３は、発送スケジュール確認画面の一例を示す図である。図２３は、電子処方箋に図１１に示す薬の情報が含まれかつその電子処方箋に対して図１６に示される薬が販売される場合に対応する発送スケジュールである。処方日数が１０日である一方、「咳止シロップＡ」の薬について、薬種類情報および医師に指定される分割投薬制限が７日であり、「胃腸薬Ｂ」の薬について薬種類情報に指定される投薬制限最大の日数が９日であるので、ステップＳ４０１において、分割発送の対象となる薬は「咳止めシロップＡ」および「胃腸薬Ｂ」となる。またステップＳ５０２において基本間隔として７日が求められ、これらの薬はその基本間隔で発送しても投薬制限についての条件を満たすので、発送スケジュールではこれらの薬はステップＳ５０３により初回発送日と、その７日後に発送される。また分割発送の対象となっていない塗り薬Ｃは初回発送日のみに発送される。発送スケジュール確認画面の情報には、このように決定された発送スケジュールの情報が含まれる。

なお、咳止めシロップＡの最大分割間隔が４日間、胃腸薬Ｂの最小分割間隔が５日間の場合、基本間隔が４日となる。発送スケジュールでは、初回発送日の４日後に咳止シロップＡが発送され、さらに４日後に咳止シロップＡと胃腸薬Ｂ（ステップＳ５０４参照）が発送される。

薬剤師は、発送スケジュール確認画面に表示されうる発送スケジュールを確認し、問題がなければ確認ボタンを押下することで、この発送スケジュールを承認する。確認ボタンが押下されると、薬局システム１は、薬剤師が発送スケジュールを確認したことを示すスケジュール確認結果（図５参照）を発送スケジュール生成部６２に送信する。また、発送スケジュール生成部６２は、スケジュール確認結果を受信する。そして、発送スケジュール生成部６２は、受信されたスケジュール確認結果により承認されたスケジュールを記憶部に保存する（ステップＳ４０６）。

発送管理部６３は、主にプロセッサ１１、記憶部１２および通信部１３により実現される。発送管理部６３は、ユーザに向けて薬を複数回に分けて発送するための発送スケジュールまたは一括で配送するための発送スケジュールに基づいて、薬の発送を管理する。図２１の例では、発送スケジュールが承認された後に、注文情報に含まれる発送ステータスを「発送待ち」に変更する（ステップＳ４０８）。また、発送管理部６３は発送スケジュールと現在日付に応じて、薬局に発送指示情報を送信する（ステップＳ４０９）。

発送指示情報は、例えば各発送日の当日または前日に薬局システム１に向けて送信され、発送日に発送する薬の情報を含むメールであってもよい。薬局の薬剤師は、このメールに基づいて薬を発送する。このメールにより、発送管理部６３は薬の発送を管理する。また、発送指示情報は薬局システム１に含まれる配送システムに入力される発送スケジュールの情報であってもよい。なお、本発明の実施形態にかかる処方薬販売システムでは、処方薬の初回発送をもって処方薬についての売買契約が成立する。

なお、発送スケジュール確認画面に表示される発送スケジュールを薬剤師が承認しない場合には、薬剤師により修正されたスケジュールを発送スケジュール生成部６２が受信し、その発送スケジュールを正式な発送スケジュールとしてもよい。例えば図２３の例では、薬剤師が編集ボタンを押下して送信される発送スケジュール確認結果に基づいて、発送スケジュール生成部６２が修正された発送スケジュールを薬剤師に入力させる画面を生成し、その画面に入力された発送スケジュールを発送スケジュール生成部６２が受信する。その後はステップＳ４０６以降の処理が実行されればよい。また、発送スケジュール生成部６２が実行する、発送スケジュールを生成する処理や薬剤師が発送スケジュールを確認するための処理を、薬剤師が説明文を作成する際に（または直前または直後に）行ってもよい。こうすると、ユーザが説明文を確認してから発送までの時間を短くすることができる。

なお、発送スケジュールの案が発送スケジュール生成部６２により生成されなくてもよい。薬局システム１を操作するユーザが希望する発送スケジュールを受信し、その発送スケジュールをそのまま発送管理に用いてもよい。

また、発送スケジュール生成部６２は、同じユーザの過去の注文の注文情報に関連づけられた発送スケジュールに基づいて担当者の承認なしにスケジュールを生成してもよい。より具体的には、発送スケジュール生成部６２はこのユーザが過去に薬を購入した注文において薬の種類および量が同じであるか否か判定し、同じである場合に発送スケジュール生成部６２はその過去の注文の発送スケジュールと発送間隔が同じとなるスケジュールを正式な発送スケジュールとして生成してよい。

ステップＳ４０２において、分割対象リストに属する薬がない場合には（ステップＳ４０２のＮ）、発送スケジュール生成部６２は電子処方箋にかかる薬を一括で発送することを示す情報（例えば画面の情報）を薬剤師に向けて出力し（ステップＳ４０７）、それを薬剤師が確認したことを示す情報を受信したら、発送管理部６３は注文情報格納部７３に格納される注文情報に含まれる発送ステータスを「発送待ち」に変更する（ステップＳ４０８）。そして発送管理部６３は発送スケジュールと日付に応じて薬局に発送指示情報を送信する（ステップＳ４０９）。

発送スケジュール生成部６２や発送管理部６３の処理により、薬を分割して発送することが可能となる。処方薬の中には、例えばシロップのように保存の難しい薬や、向精神薬のように飲み過ぎによる事故の発生が懸念される薬が存在する。これらの薬については分割発送により、仮に一度に処方する期間を長くしても、劣化した薬による事故の発生や、薬の飲み過ぎによる事故の発生を抑えることが可能になる。また、処方できる期間を短くする場合に比べて患者に受診の手間を減らすことも可能となる。

なお、処方日数のうち一部について、患者の自己判断で処方薬の服用を止めてよいか否かを医師が電子処方箋にて指定できるようにしてもよい。この場合、電子処方箋にいずれかの処方薬の服用を止めてよいことを示す情報が含まれ、かつその処方薬について電子商店街サーバ２の発送管理部６３が、ユーザの希望に基づく薬の発送のキャンセルを指示する情報（発送キャンセル指示情報）を受信した場合に、発送管理部６３は、発送キャンセル指示情報を受信した後の発送スケジュールにおける薬の発送を行わないように薬局システム１を制御してよい。

さらに、発送管理部６３は、発送キャンセル指示により未発送の薬の発送が停止された場合に、薬の販売の一部または全部がキャンセルされたことを示す情報により、その薬の販売にかかる注文情報のステータス情報を更新してもよい。その更新された注文情報は注文情報格納部７３に格納される。

これにより、医師の診察後に薬を服用しているうちに病気が治った場合に、患者の手元にある余分な薬を減らすことが可能になる。それにより実質的な医療費の削減や、不要な薬を所有することによる事故や不正の発生を防ぐこともできる。また、薬の発送が停止され、販売の一部または全部がキャンセルされた注文について、注文情報格納部７３に格納された注文情報に基づいて、販売制御部５４が返金やポイント還元を実現する処理を行ってもよい。この場合には、販売制御部５４は、病院サーバ４における電子処方箋にかかる販売状況は電子処方箋が利用済を示す情報のままとなるよう制御する。

キャンセルに関連して、発送ステータスが「発送待ち」となる前にユーザにより注文がキャンセルされた場合が考えられる。この場合、販売制御部５４は、病院サーバ４における電子処方箋にかかる販売状況がこの薬局が利用済を示す場合には、その販売状況を未利用を示すように更新するよう制御する。この場合にはユーザが他の薬局を利用する可能性があるからである。このキャンセルがされかつ決済済の場合には販売制御部５４は返金の処理を行う。

さらに、発送ステータスが「発送待ち」となったあとに実際に発送されるまでの間に注文がキャンセルされた場合には、販売制御部５４は、そのキャンセルの指示とともにユーザに理由を示す情報を取得し、その取得された理由に応じて病院サーバ４の販売状況を未利用に更新するか否かを制御してもよい。また薬局システム１を操作する薬剤師の判断により、病院サーバ４の販売状況を薬剤師が人手で更新してもよい。これにより、例えば他の病院でさらに薬を処方され薬が不要になった場合には販売状況を利用済のままとし、単に他の薬局を利用したい場合には他の薬局の利用を可能にするといった柔軟な対応が可能となる。

このように、注文のキャンセル時の発送のステータスに応じてキャンセルに関する病院サーバ４の販売状況を更新する処理を異ならせてよい。

これまでの説明では、電子処方箋に応じた説明文のデータをユーザが電子処方箋を送信した後に行っているが、これをユーザから電子処方箋を受信する前に行うようにしてもよい。以下ではそのための処方箋事前受信部６４等の動作や、処方薬販売システムによる処方薬の販売の流れの例について説明する。以下では図４，５の例との相違点を中心に説明する。

図２４は、処方薬の販売過程の他の一例を概略的に示す図である。また、図２５は、図２４の例における、ユーザ端末３、電子商店街サーバ２、薬局システム１、病院サーバ４の間での通信を示すシーケンス図である。図２４および図２５の例は、予め、病院サーバ４に患者が普段利用するかかりつけ薬局が登録されており、病院サーバ４に向けて電子処方箋を開示することを了承している場合の例である。

この場合には、病院にて医師が電子処方箋を発行すると（図２４の「１.処方箋発行」）、病院サーバ４は電子処方箋を示す情報（この例では処方箋ＩＤであるが、電子処方箋でもよい）をユーザ端末３に向けて送信する（図２４の「２．処方箋ＩＤ送信」、図２５の「処方箋ＩＤ」）とともに、電子処方箋を薬局システム１に送信する（図２４の「３.処方箋送信」、図２５の「電子処方箋」）。すると、電子処方箋を受信した薬局システム１を操作する薬剤師は説明文を作成する（図２４の「４.説明文作成」）。

この事前の処方箋の受信と、説明文作成について詳細を説明する。処方箋事前受信部６４は、主に電子商店街サーバ２に属するコンピュータに含まれるプロセッサ１１、記憶部１２および通信部１３により実現される。処方箋事前受信部６４は、処方箋受信部５２がユーザから電子処方箋を示す情報を取得する前に、前記ユーザと異なる送信元（病院サーバ４や薬局システム１）から電子処方箋に含まれる薬および患者に関する情報を受信する。ここで、電子処方箋に含まれる薬および患者に関する情報は、電子処方箋そのものであってもよいし、別のフォーマットの情報であってもよい。電子商店街サーバ２が電子処方箋に含まれる薬および患者に関する情報を受信する方法は、病院サーバ４から電子商店街サーバ２に直接プッシュ的に送信する方法であってもよいし、電子商店街サーバ２が定期的に病院サーバ４にアクセスし、この薬局に対する電子処方箋がある場合にその電子処方箋をダウンロードする方法であってもよい。また、薬局システム１に属するコンピュータが病院サーバ４から受信した電子処方箋をさらに電子商店街サーバ２に送信することで、処方箋事前受信部６４が電子処方箋に含まれる薬および患者に関する情報を受信してもよいし、また処方箋事前受信部６４が薬局システム１に属するコンピュータにより実現されてもよい。

属性取得部６５は、電子商店街サーバ２に含まれるプロセッサ１１、記憶部１２および通信部１３を中心として実現される。属性取得部６５は、ユーザと異なる送信元である病院サーバ４から受信された電子処方箋にかかる患者の属性情報を、ユーザの属性情報を格納するユーザ情報格納部７１から取得する。より具体的には、属性取得部６５は、薬局システム１に含まれるコンピュータから電子処方箋に含まれる患者に関する情報（例えば病院コード、患者ＩＤ、保険者番号、氏名などの患者を特定する情報）を取得し、その患者に関する情報に基づいて、ユーザの属性（例えばアレルギー歴、副作用履歴等）をユーザ情報格納部７１から取得する。なお、この際に電子商店街サーバ２に含まれる属性取得部６５は電子処方箋を取得し、記憶部１２に格納してもよい。

そして、説明文入力部５９は、電子処方箋に含まれる患者に対応するユーザの属性の情報であって属性取得部６５により取得されたユーザの属性の情報と、受信された薬に関する情報とを薬剤師に提示し、電子処方箋にかかる説明文を入力させる説明文入力画面の情報を送信する。説明文入力画面の構成については、図１８の例と同様であり、説明文入力画面はユーザから注文の申込を受ける前に生成される。

そして、薬局システム１はその説明文を電子商店街サーバ２に保存する（図２４の「説明文保存」、図２５の「説明文入力データ」）。説明文入力部５９が注文にかかる薬局の薬剤師から入力された注文にかかる説明文入力データを受付ける処理は、図５の例と同様である。

図２７は、説明文出力画面の他の一例を示す図である。図２７に示す説明文出力画面は、事前に作成され、説明文入力部５９が記憶部１２に保存した説明文を出力する画面である。事前に説明文が作成される場合には、その説明文はユーザの属性に関する情報と、その情報が現在変化したか否かを入力させるチェックボックス３２とを含む。このチェックボックス３２は、属性に関する情報の項目毎に設定されてもよい。この場合、より確実にユーザの状態を確認することができる。説明文入力部５９は、図２７に示す説明文出力画面を表示させるために、これらのユーザの属性に関する情報と、それをユーザが確認したことを示す情報を送信させる情報とを含む説明文のテンプレートを含む、説明文入力画面の情報を生成してよい。

図５の例の「薬リスト問合せ」の代わりに、薬局システム１は説明文を送信するとともに薬局が提供する処方薬のリストである薬種類データを送信してよい。このリストは、先発薬中心のリストと、後発薬中心のリストの２種類のリストであってよい。電子商店街サーバ２に含まれる選択情報生成部５６は、この薬種類データを受信してよいし、あわせて電子処方箋も受信して記憶部１２または他のコンピュータが実行するデータベースに格納してよい。また選択情報生成部５６は、処方箋受信部５２が電子処方箋を示す情報を受信する前に、薬種類データに含まれる薬の１または複数のリストを記憶部１２（または他のコンピュータが実行するデータベース）に格納してよい。

そして、ユーザはユーザ端末３を用いて電子商店街サーバ２が提供する処方薬販売サービスにログインする（図２４の「６．ログイン」、図２５の「ログイン画面」、「ユーザ認証情報」）。ユーザ認証部５１の処理は図５の例と同様である。ユーザは電子商店街サーバ２へユーザを認証する認証情報に紐付けられた処方箋ＩＤを送信する（図２４の「７．処方箋ＩＤ送信」、図２５の「処方箋ＩＤデータ」）。すると、電子商店街サーバ２は受信した電子処方箋に含まれる薬の１または複数のリストの情報をユーザ端末３に送信する（図２４の「８．薬種類提示」、図２５の「薬種類選択画面」）。

以下では処方箋ＩＤを受信した後、薬種類選択画面が生成されるまでの処理について説明する。ユーザが電子処方箋を示す情報である処方箋ＩＤを送信した後に、処方箋確認部５３は、電子処方箋に紐付けられたユーザ認証情報と、電子処方箋に含まれる患者の情報とが対応するか否か確認するための処理を実行する。より具体的には、処方箋確認部５３はセッションＩＤ等のユーザ認証情報と電子処方箋とを紐付ける情報に基づいてユーザを特定する情報を取得し、そのユーザについて予め薬局システム１からされ送信格納されている電子処方箋を特定する情報（例えば処方箋ＩＤ）と、ユーザから処方箋受信部が受信した処方箋を特定する情報とが一致するか否かを判定し、それらが一致する場合にユーザ認証情報に対応するユーザの情報と、電子処方箋に含まれる患者の情報とが対応すると確認する。そして、販売制御部５４は、その確認の処理の結果に基づいて、電子処方箋に応じた薬の販売処理が実行されるよう制御する。

ユーザ認証情報に対応するユーザの情報と、電子処方箋に含まれる患者の情報とが対応する場合に、販売制御部５４の制御に基づいて、選択情報生成部５６は、薬局システム１から受信した薬のリストに基づいて、先発薬と後発薬のいずれかをユーザに選択させるための情報である薬種類選択画面の情報を生成する。薬種類選択画面は、予め説明文を受付けた薬局のうち、先発薬中心の薬のリストと、後発薬中心の薬のリストとのうち、どちらを選ぶかをユーザに選択させる画面である。薬種類選択画面は、例えば図１４に示す画面から、かかりつけ薬局以外の薬局についての薬のリストを除いた画面になる。

そして、ユーザはそのリストに含まれる薬のリストのいずれかを選択し、ユーザ端末３は選択されたリストの情報（図２５の「薬種類選択データ」）を電子商店街サーバ２に送信する（図２４の「９．薬種類選択」）。電子商店街サーバ２に含まれる選択部５７が薬種類選択データを受信し、説明文出力部６０は、予め薬剤師が入力し、記憶部１２等に記憶された説明文をユーザに向けて送信する（図２４の「１０．説明文送付」、図２５の「説明文データ」）。説明文出力部６０は、薬種類選択画面と同じセッションにおいて、その薬種類選択画面に続く画面として、図２７に示すような説明文出力画面の情報を出力する。説明文出力画面の情報の生成については説明を省略する。

ユーザがその説明文を確認すると、確認結果取得部６１は、ユーザが確認したことを示す情報を受信し（図２５の「説明確認データ」）、薬剤師がそれを確認する（図２４の「１１．確認」、図２５の「説明ステータス確認」）。これにかかる確認結果取得部６１の処理は図５の例と同様であるので説明を省略する。そして、薬局システム１は、処方箋を管理する病院サーバ４にこの電子処方箋により他の薬局等が処方薬を販売するか問い合せる（図２４の「１１．処方箋利用状況確認」図２５の「処方箋利用状況確認」）。販売状況確認部５５は、ここで図５と同様の処理を実行する。

この電子処方箋による処方薬が他の薬局により販売されない場合には、決済処理部５８は決済処理を実行し、薬局は処方薬をユーザに向けて発送する（図２４の「１１．発送」、図２５の「発送指示情報」）。なお、図２５において、決済処理部５８が行う決済処理、販売状況確認部５５が処方薬販売状況を確認し販売制御部５４がその確認結果に応じて薬の販売を制御する処理や、発送スケジュール生成部６２が発送スケジュールを生成する処理、発送管理部６３が発送を管理する処理については、決済処理部５８や販売状況確認部５５の処理の順序が異なる点を除き図５の例と同様であるので詳細の説明を省略する。

処方箋事前受信部６４により、ユーザが電子処方箋を示す情報を送信する前に電子処方箋を受信すると、薬局システム１を操作する薬剤師はその送信の前に説明文を入力することが可能になる。これにより、ユーザが薬の種類を選択するなどにより薬の購入の申込をしてから説明文を確認するまでの時間を削減し、ユーザの利便性を向上させることができる。特に、薬剤師が夜間に常駐しておらず、かつユーザの薬の購入の申込や説明の確認の操作が夜間しかできないような場合には、申込から発送までの時間を１日以上短縮することが可能になる。

なお、図２４，２５の例では、電子商店街サーバ２がユーザとのやりとりを行っているが、これらのやりとりを薬局システム１に含まれるサーバコンピュータが行ってもよい。この場合、電子商店街サーバ２の機能を実現するプログラムは薬局システム１に配置され、薬局システム１に含まれるサーバコンピュータにより実行される。

１ 薬局システム、２ 電子商店街サーバ、３ ユーザ端末、４ 病院サーバ、５ ネットワーク、１１ プロセッサ、１２ 記憶部、１３ 通信部、１４ 入出力部、３１，３２ チェックボックス、５１ ユーザ認証部、５２ 処方箋受信部、５３ 処方箋確認部、５４ 販売制御部、５５ 販売状況確認部、５６ 選択情報生成部、５７ 選択部、５８ 決済処理部、５９ 説明文入力部、６０ 説明文出力部、６１ 確認結果取得部、６２ 発送スケジュール生成部、６３ 発送管理部、６４ 処方箋事前受信部、６５ 属性取得部、７１ ユーザ情報格納部、７２ 説明文格納部、７３ 注文情報格納部。

Claims (14)

1. ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信する受信手段と、
   前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行する処方箋確認手段と、
   前記処方箋確認手段による確認のための処理の結果に従って、前記セッション中に前記電子処方箋に応じた薬の販売処理の実行を制御する制御手段と、
   前記電子処方箋に応じた薬の販売の進行状況を示す情報を前記電子処方箋に紐づけて記憶する手段と、
   を含む処方薬販売システム。
2. 請求項１に記載の処方薬販売システムにおいて、
   前記電子処方箋に応じた薬が既に販売されているか否かを前記販売の進行状況を示す情報に基づいて確認するための処理を実行する販売確認手段をさらに含み、
   前記制御手段は、まだ前記薬が販売されていないと確認された場合に前記電子処方箋に応じた薬の販売処理が実行されるよう制御する、
   処方薬販売システム。
3. 請求項１に記載の処方薬販売システムにおいて、
   前記電子処方箋がいずれかの薬局により使用されたか否かを示す使用情報を受信する手段をさらに含み、
   前記制御手段は、前記使用情報がまだ前記電子処方箋が使用されていないことを示す場合に前記電子処方箋に応じた薬の販売処理が実行されるよう制御する、
   処方薬販売システム。
4. 請求項１から３のいずれかに記載の処方薬販売システムにおいて、
   前記電子処方箋にかかる患者の属性情報を、ユーザの属性情報を格納する記憶手段から取得する属性取得手段と、
   前記電子処方箋と前記読み出されたユーザの属性情報とを薬剤師に提示し、その提示に基づいて薬剤師から入力された説明文を受け付け、当該説明文を記憶手段に記憶させる説明文受付手段と、
   前記受信手段が前記電子処方箋を示す前記情報を受信した場合に前記説明文を前記ユーザに向けて出力する説明文出力手段と、をさらに含む、
   処方薬販売システム。
5. 請求項４に記載の処方薬販売システムにおいて、
   前記受信手段により前記電子処方箋を示す前記情報を前記ユーザから取得する前に別途前記ユーザと異なる送信元から前記電子処方箋に含まれる薬および患者に関する情報を受信する事前受信手段を有し、
   前記属性取得手段は、ユーザと異なる送信元から受信された前記患者に関する情報に基づき前記電子処方箋にかかる患者の属性情報を、ユーザの属性情報を格納する記憶手段から取得し、
   前記説明文受付手段は、前記ユーザと異なる送信元から受信された前記薬に関する情報と前記読み出されたユーザの属性情報とを薬剤師に提示し、その提示に基づいて薬剤師から入力された説明文を受け付け、当該説明文を記憶手段に記憶させる、
   処方薬販売システム。
6. 請求項４または５に記載の処方薬販売システムにおいて、
   ユーザが前記説明文を確認したことを示す確認データを受信する確認データ受信手段をさらに含み、
   前記確認データが受信された場合に前記制御手段による前記電子処方箋に応じた薬の販売処理が実行される、
   処方薬販売システム。
7. 請求項１から６のいずれかに記載の処方薬販売システムにおいて、
   前記電子処方箋により指定される薬を複数の選択肢からユーザに選択させるための情報を生成する生成手段をさらに含み、
   前記制御手段は、前記販売処理を実行する際に前記ユーザに選択された選択肢に基づいて前記電子処方箋に応じた薬の販売処理の実行を制御する、
   処方薬販売システム。
8. 請求項１から６のいずれかに記載の処方薬販売システムにおいて、
   前記電子処方箋に含まれる薬の情報と薬局の在庫情報とに基づいて、当該電子処方箋に指定される薬を販売する薬局のうちいずれかをユーザに選択させるための情報を生成する生成手段、をさらに含み、
   前記制御手段は、ユーザに選択された前記薬を販売する薬局に基づいて前記電子処方箋に応じた薬の販売処理の実行を制御する、
   処方薬販売システム。
9. 請求項１から８のいずれかに記載の処方薬販売システムにおいて、
   前記電子処方箋に応じた薬の情報及びユーザの希望のうち少なくとも一方に基づいて、前記薬を一回で、または複数回に分けて発送するスケジュールを生成する発送スケジュール生成手段をさらに含む、
   処方薬販売システム。
10. 請求項９に記載の処方薬販売システムにおいて、
    前記生成された発送スケジュールに基づいて、前記薬の発送を管理する発送管理手段をさらに含む、
    処方薬販売システム。
11. 請求項１０に記載の処方薬販売システムにおいて、
    前記発送管理手段は、前記薬の発送スケジュールとユーザの希望とに基づいて、未発送の前記薬の発送を停止可能であり、
    前記発送管理手段により前記薬の発送が停止された場合に、その発送状況に基づき、薬の販売が一部または全部キャンセルされたことを前記電子処方箋に応じた薬の販売の進行状況を示す情報の更新内容として前記薬の販売の進行状況を示す情報を記憶する手段に記憶する、
    処方薬販売システム。
12. 受信手段が、ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信するステップと、
    処方箋確認手段が、前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行するステップと、
    制御手段が、前記ユーザの情報と前記患者の情報とが対応するか否か確認するための処理の結果に従って、前記セッション中に前記電子処方箋に応じた薬の販売処理の実行を制御するステップと、
    記憶手段が、前記電子処方箋に応じた薬の販売の進行状況を示す情報を前記電子処方箋または前記電子処方箋を示す前記情報に紐づけて記憶するステップと、
    を含む処方薬販売方法。
13. ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信する受信手段、
    前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行する処方箋確認手段、および、
    前記処方箋確認手段による確認のための処理の結果に従って、前記セッション中に前記電子処方箋に応じた薬の販売処理の実行を制御する制御手段、
    前記電子処方箋に応じた薬の販売の進行状況を示す情報を前記電子処方箋または前記電子処方箋を示す前記情報に紐づけて記憶する手段、
    としてコンピュータを機能させるためのプログラム。
14. ユーザを認証する認証情報と電子処方箋を示す情報とを前記ユーザからひとつのセッション中に受信する受信手段、
    前記受信された認証情報に対応するユーザの情報と前記電子処方箋に含まれる患者の情報とが対応するか否かを確認するための処理を実行する処方箋確認手段、および、
    前記処方箋確認手段による確認のための処理の結果に従って、前記セッション中に前記電子処方箋に応じた薬の販売処理の実行を制御する制御手段、
    前記電子処方箋に応じた薬の販売の進行状況を示す情報を前記電子処方箋または前記電子処方箋を示す前記情報に紐づけて記憶する手段、
    としてコンピュータを機能させるためのプログラムを格納する情報記憶媒体。

Images