ホーム > 特許ランキング > 株式会社ＥＰファーマライン
特開2024-42415流通管理サーバ及び流通管理方法及びコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024042415
(43)【公開日】2024-03-28
(54)【発明の名称】流通管理サーバ及び流通管理方法及びコンピュータプログラム
(51)【国際特許分類】
G06Q 10/08 20240101AFI20240321BHJP
【ＦＩ】
G06Q10/08
【審査請求】有
【請求項の数】11
【出願形態】ＯＬ
(21)【出願番号】P 2022147111
(22)【出願日】2022-09-15
(71)【出願人】
【識別番号】518183354
【氏名又は名称】株式会社ＥＰファーマライン
(74)【代理人】
【識別番号】100109014
【弁理士】
【氏名又は名称】伊藤 充
(74)【代理人】
【識別番号】100141988
【弁理士】
【氏名又は名称】松本 浩一郎
(74)【代理人】
【識別番号】100182154
【弁理士】
【氏名又は名称】吉田 淳一
(72)【発明者】
【氏名】屋代 正直
(72)【発明者】
【氏名】一之瀬（成田） 備恵
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049AA16
5L049CC51
(57)【要約】
【課題】流通管理業務における作業量を低減し、さらに、より迅速な医薬品の納品可否判断を行うことができるシステムを提供することである。
【解決手段】医薬品の流通を管理するための流通管理サーバであって、外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御部と、を備え、前記通信部は、前記制御部が生成した前記判定結果を外部に送信する、ことを特徴とする流通管理サーバである。
【選択図】図１
【解決手段】医薬品の流通を管理するための流通管理サーバであって、外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御部と、を備え、前記通信部は、前記制御部が生成した前記判定結果を外部に送信する、ことを特徴とする流通管理サーバである。
【選択図】図１
【特許請求の範囲】
【請求項1】
医薬品の流通を管理するための流通管理サーバであって、
外部との通信を行う通信部と、
納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、
前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御部と、
を備え、
前記通信部は、前記制御部が生成した前記判定結果を外部に送信する、
ことを特徴とする流通管理サーバ。
外部との通信を行う通信部と、
納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、
前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御部と、
を備え、
前記通信部は、前記制御部が生成した前記判定結果を外部に送信する、
ことを特徴とする流通管理サーバ。
【請求項2】
請求項１記載の流通管理サーバであって、
前記通信部は、前記納品連絡書の情報を入力するＷＥＢページを提供するＷＥＢサーバを含み、
前記外部から送信されてきた納品連絡書には、前記ＷＥＢページ上で情報を入力された納品連絡書を含むことを特徴とする流通管理サーバ。
前記通信部は、前記納品連絡書の情報を入力するＷＥＢページを提供するＷＥＢサーバを含み、
前記外部から送信されてきた納品連絡書には、前記ＷＥＢページ上で情報を入力された納品連絡書を含むことを特徴とする流通管理サーバ。
【請求項3】
請求項１記載の流通管理サーバであって、
前記通信部は、前記納品連絡書の前記判定結果を表示するＷＥＢページを提供するＷＥＢサーバを含み、
前記通信部は、前記制御部が生成した前記判定結果を、前記ＷＥＢページ上の表示を用いて外部に送信することを特徴とする流通管理サーバ。
前記通信部は、前記納品連絡書の前記判定結果を表示するＷＥＢページを提供するＷＥＢサーバを含み、
前記通信部は、前記制御部が生成した前記判定結果を、前記ＷＥＢページ上の表示を用いて外部に送信することを特徴とする流通管理サーバ。
【請求項4】
請求項１記載の流通管理サーバであって、
前記制御部は、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新処理を実行することを特徴とする流通管理サーバ。
前記制御部は、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新処理を実行することを特徴とする流通管理サーバ。
【請求項5】
請求項４記載の流通管理サーバであって、
前記納品連絡書を記憶する納品連絡書データベース、
を備え、
前記制御部は、前記判定結果として、納品可能を意味する「可」、又は、納品不可を意味する「不可」のいずれかの値をフラグとして前記納品連絡書に設定し、設定後の「可」又は「不可」のフラグを設定された納品連絡書を前記納品連絡書データベースに記憶させ、
前記制御部は、前記更新処理を実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成し、
前記通信部は、前記制御部が生成した前記判定結果が「可」である場合は、その判定結果を外部に送信する、
ことを特徴とする流通管理サーバ。
前記納品連絡書を記憶する納品連絡書データベース、
を備え、
前記制御部は、前記判定結果として、納品可能を意味する「可」、又は、納品不可を意味する「不可」のいずれかの値をフラグとして前記納品連絡書に設定し、設定後の「可」又は「不可」のフラグを設定された納品連絡書を前記納品連絡書データベースに記憶させ、
前記制御部は、前記更新処理を実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成し、
前記通信部は、前記制御部が生成した前記判定結果が「可」である場合は、その判定結果を外部に送信する、
ことを特徴とする流通管理サーバ。
【請求項6】
請求項１記載の流通管理サーバを用いて、流通管理を行う流通管理方法であって、
前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成するステップと、
前記通信部は、前記制御部が生成した前記判定結果を外部に送信するステップと、
を含むことを特徴とする流通管理方法。
前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成するステップと、
前記通信部は、前記制御部が生成した前記判定結果を外部に送信するステップと、
を含むことを特徴とする流通管理方法。
【請求項7】
請求項６記載の流通管理方法であって、
前記制御部が、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新処理を実行する更新ステップ、
を含むことを特徴とする流通管理方法。
前記制御部が、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新処理を実行する更新ステップ、
を含むことを特徴とする流通管理方法。
【請求項8】
請求項７記載の流通管理方法であって、
前記流通管理サーバは、前記納品連絡書を記憶する納品連絡書データベース、を備え、
前記制御部が、前記更新ステップを実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成するステップと、
前記通信部が、前記制御部が生成した前記判定結果を外部に送信するステップと、
を含むことを特徴とする流通管理方法。
前記流通管理サーバは、前記納品連絡書を記憶する納品連絡書データベース、を備え、
前記制御部が、前記更新ステップを実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成するステップと、
前記通信部が、前記制御部が生成した前記判定結果を外部に送信するステップと、
を含むことを特徴とする流通管理方法。
【請求項9】
外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、制御部と、を備えたコンピュータを、請求項１記載の流通管理サーバとして動作させるコンピュータプログラムであって、前記コンピュータに、
前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御手順と、
前記通信部が、前記制御手順で生成した前記判定結果を外部に送信する手順と、
を実行させることを特徴とするコンピュータプログラム。
前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御手順と、
前記通信部が、前記制御手順で生成した前記判定結果を外部に送信する手順と、
を実行させることを特徴とするコンピュータプログラム。
【請求項10】
請求項９記載のコンピュータプログラムであって、前記コンピュータに、
外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新手順、
を実行させることを特徴とするコンピュータプログラム。
外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新手順、
を実行させることを特徴とするコンピュータプログラム。
【請求項11】
外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、制御部と、納品連絡書を記憶する納品連絡書データベースと、を備えたコンピュータを、請求項５記載の流通管理サーバとして動作させるコンピュータプログラムであって、前記コンピュータに、
前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御手順と、
前記制御部が、前記判定結果として、納品可能を意味する「可」、又は、納品不可を意味する「不可」のいずれかの値をフラグとして前記納品連絡書に設定し、設定後の「可」又は「不可」のフラグを設定された納品連絡書を前記納品連絡書データベースに記憶させる手順と、
外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新手順と、
前記制御部が、前記更新処理を実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成する第２制御手順と、
前記通信部は、前記第２制御手順で生成した前記判定結果が「可」である場合は、その判定結果を外部に送信する手順と、
ことを特徴とするコンピュータプログラム。
前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御手順と、
前記制御部が、前記判定結果として、納品可能を意味する「可」、又は、納品不可を意味する「不可」のいずれかの値をフラグとして前記納品連絡書に設定し、設定後の「可」又は「不可」のフラグを設定された納品連絡書を前記納品連絡書データベースに記憶させる手順と、
外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新手順と、
前記制御部が、前記更新処理を実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成する第２制御手順と、
前記通信部は、前記第２制御手順で生成した前記判定結果が「可」である場合は、その判定結果を外部に送信する手順と、
ことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、流通管理システムに用いられる流通管理サーバに関する。特に、医薬品を納品可能か否か迅速に判断できる流通管理サーバ及び流通管理方法に関する。さらに、流通管理サーバに関連するコンピュータプログラムに関する。
【背景技術】
【0002】
流通管理業務
医薬品（処方薬）の中には、流通上納品条件が設定された医薬品が存在する。その条件がクリアできているか管理する業務を流通管理業務という。このような医薬品の流通管理業務は、国民の健康に直結するものであるため、極めて重要である。
従来の流通管理業務の説明図が図１５に示されている。この図に示すように、まず、病院・薬局から医薬品の注文を受けて、それに対応して医薬品の納品を行う特約店１０は、納品連絡書１２を流通管理者１４に送信する。そして、流通管理者１４は、納品の条件が満たされているか否かを確認して、納品可、又は、納品不可の回答を特約店１０に送信する。そして、特約店１０は、この回答を受信し、回答の内容が納品可の場合に、病院・薬局に医薬品を納品する。
医薬品（処方薬）の中には、流通上納品条件が設定された医薬品が存在する。その条件がクリアできているか管理する業務を流通管理業務という。このような医薬品の流通管理業務は、国民の健康に直結するものであるため、極めて重要である。
従来の流通管理業務の説明図が図１５に示されている。この図に示すように、まず、病院・薬局から医薬品の注文を受けて、それに対応して医薬品の納品を行う特約店１０は、納品連絡書１２を流通管理者１４に送信する。そして、流通管理者１４は、納品の条件が満たされているか否かを確認して、納品可、又は、納品不可の回答を特約店１０に送信する。そして、特約店１０は、この回答を受信し、回答の内容が納品可の場合に、病院・薬局に医薬品を納品する。
【0003】
納品可否の判定基準（流通制限）の例としては、以下のような事例が挙げられる。
・適正な情報提供が病院・薬局に対して行われているか。
・指定された所定のセミナーを受講しているか。
・専門医なのか。
・必要な書類は揃っているか。
流通管理者１４は、製薬会社に代わって、納品の可否を判断し、適正な医薬品の流通を管理する者である。この流通管理者１４は、流通管理業務を遂行する企業体（及びその担当者）でよい。また、特約店１０とは、医薬品を病院・薬局に納品する者であり、いわゆる医薬品卸売会社でよい。上述した納品連絡書１２は、例えばファクシミリ（以下、ＦＡＸと称する）で送信してよく、また、上述した回答も同様にＦＡＸで送信してよい。
さて、流通管理業務は、上述のように、流通の条件がクリアできているか管理する業務であるが、その納品可否判断の結果、納品可と判断されたことを「ロック解除」と呼ぶ。
・適正な情報提供が病院・薬局に対して行われているか。
・指定された所定のセミナーを受講しているか。
・専門医なのか。
・必要な書類は揃っているか。
流通管理者１４は、製薬会社に代わって、納品の可否を判断し、適正な医薬品の流通を管理する者である。この流通管理者１４は、流通管理業務を遂行する企業体（及びその担当者）でよい。また、特約店１０とは、医薬品を病院・薬局に納品する者であり、いわゆる医薬品卸売会社でよい。上述した納品連絡書１２は、例えばファクシミリ（以下、ＦＡＸと称する）で送信してよく、また、上述した回答も同様にＦＡＸで送信してよい。
さて、流通管理業務は、上述のように、流通の条件がクリアできているか管理する業務であるが、その納品可否判断の結果、納品可と判断されたことを「ロック解除」と呼ぶ。
【0004】
このような従来の流通管理業務における問題点が図１６に示されている。図１６（及び図１５）に示すように、流通管理者１４は、納品連絡書１２等をＦＡＸで受領する。したがって、その情報をさらにデータ化してコンピュータに入力する等の作業が必要となり、人件費や作業量が過大なものとなりがちである。
また、図１６に示すように、従来から特約店１０は、病院・薬局１６に納品してよいか否かを、ＦＡＸを介して流通管理者１４に確認している。そのため、繁忙期には、流通管理者１４から回答が返ってくるまでに時間がかかる場合もある。その結果急配に間に合わず、病院・薬局１６への医薬品の納品も時間がかかる場合も考えられる。
また、図１６に示すように、従来から特約店１０は、病院・薬局１６に納品してよいか否かを、ＦＡＸを介して流通管理者１４に確認している。そのため、繁忙期には、流通管理者１４から回答が返ってくるまでに時間がかかる場合もある。その結果急配に間に合わず、病院・薬局１６への医薬品の納品も時間がかかる場合も考えられる。
【0005】
図１７には、従来の流通管理業務の詳細な処理の流れが示されている。
まず、図１７の白丸１において、病院・薬局１６が、特約店１０に医薬品の発注を行う。
白丸２において、特約店１０は、納品連絡書１２をＦＡＸで流通管理者１４に送信する。
白丸３において、流通管理者１４は、納品可否判定（可能）の連絡をＦＡＸで特約店１０に送信する。この連絡を受領した特約店１０は、白丸５において、納品を行う。
また、白丸４において、流通管理者１４は、納品可の連絡をＭＲ（Medical Representatives（医療情報担当者））１８に対して行う。
まず、図１７の白丸１において、病院・薬局１６が、特約店１０に医薬品の発注を行う。
白丸２において、特約店１０は、納品連絡書１２をＦＡＸで流通管理者１４に送信する。
白丸３において、流通管理者１４は、納品可否判定（可能）の連絡をＦＡＸで特約店１０に送信する。この連絡を受領した特約店１０は、白丸５において、納品を行う。
また、白丸４において、流通管理者１４は、納品可の連絡をＭＲ（Medical Representatives（医療情報担当者））１８に対して行う。
【0006】
一方、納品不可の場合は、上述した白丸３において、流通管理者１４は、納品可否判定（不可）の連絡をＦＡＸで特約店１０に送信する。この連絡を受領した特約店１０は、その時点では、納品を行うことはできない。この場合、黒丸１において、流通管理者１４は、納品可否判断基準の聴取依頼をＭＲ１８に対して送信する。
黒丸２において、上記依頼を受信したＭＲ１８は、納品可否判断基準の聴取を病院・薬局１６に対して行う。そして、黒丸３において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判断基準の情報）を流通管理者１４に送信する。
黒丸４において、流通管理者１４は、ＭＲ１８から入手した新たな情報に基づき判断を行い、新たな納品可否判定（納品不可→可能）の連絡をＦＡＸで特約店１０に送信する。
この連絡を受領した特約店１０は、黒丸５において、納品を行う。従来の流通管理業務は、このように行われている。
黒丸２において、上記依頼を受信したＭＲ１８は、納品可否判断基準の聴取を病院・薬局１６に対して行う。そして、黒丸３において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判断基準の情報）を流通管理者１４に送信する。
黒丸４において、流通管理者１４は、ＭＲ１８から入手した新たな情報に基づき判断を行い、新たな納品可否判定（納品不可→可能）の連絡をＦＡＸで特約店１０に送信する。
この連絡を受領した特約店１０は、黒丸５において、納品を行う。従来の流通管理業務は、このように行われている。
【0007】
先行特許文献
医薬品の流通管理には、様々な側面があり、種々の目的で改良された様々な流通の手法が提案されている。本発明とは直接関係しないが、同分野における一般的な背景技術を示す発明を以下説明する。
下記特許文献１には、本願発明と同様に医薬品の流通管理に関する発明が開示されている。この特許文献１記載の発明によれば、特別なインクで認証コードを発行することによって、偽造医薬品の防止を実現できるとされている。
医薬品の流通管理には、様々な側面があり、種々の目的で改良された様々な流通の手法が提案されている。本発明とは直接関係しないが、同分野における一般的な背景技術を示す発明を以下説明する。
下記特許文献１には、本願発明と同様に医薬品の流通管理に関する発明が開示されている。この特許文献１記載の発明によれば、特別なインクで認証コードを発行することによって、偽造医薬品の防止を実現できるとされている。
【0008】
また、下記特許文献２にも、薬の流通を監視する監視システムが開示されている。この特許文献２記載の発明によれば、管理システムが許可コードを発行した場合にのみ薬局の調剤が可能となる。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特表２０１５－５０８５１９号公報
【特許文献2】特開２０１５－２７４７７号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
このように、従来の流通管理業務は、人件費や作業量が膨大なものとなりがちであった。また、医薬品の納品可否判断が遅れて、病院・薬局１６への納品も時間がかかる場合もあった。
本発明は係る課題に鑑みなされたものであり、その目的は、流通管理業務における作業量を低減し、さらに、より迅速な医薬品の納品可否判断を行うことができるシステムを提供することである。
本発明は係る課題に鑑みなされたものであり、その目的は、流通管理業務における作業量を低減し、さらに、より迅速な医薬品の納品可否判断を行うことができるシステムを提供することである。
【課題を解決するための手段】
【0011】
かかる課題を解決するために、本願発明者は、鋭意研究を重ねた結果、納品可否判定基準情報を流通管理サーバに登録して、納品可否の判断を自動的に行うシステムを構築するというアイデアに至った。
【0012】
（１）本発明は、上記課題を解決するために、医薬品の流通を管理するための流通管理サーバであって、外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御部と、を備え、前記通信部は、前記制御部が生成した前記判定結果を外部に送信する、ことを特徴とする流通管理サーバである。
【0013】
（２）また、本発明は、（１）記載の流通管理サーバであって、前記通信部は、前記納品連絡書の情報を入力するＷＥＢページを提供するＷＥＢサーバを含み、前記外部から送信されてきた納品連絡書には、前記ＷＥＢページ上で情報を入力された納品連絡書を含むことを特徴とする流通管理サーバである。
【0014】
（３）また、本発明は、（１）記載の流通管理サーバであって、前記通信部は、前記納品連絡書の前記判定結果を表示するＷＥＢページを提供するＷＥＢサーバを含み、前記通信部は、前記制御部が生成した前記判定結果を、前記ＷＥＢページ上の表示を用いて外部に送信することを特徴とする流通管理サーバである。
【0015】
（４）また、本発明は、（１）記載の流通管理サーバであって、前記制御部は、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新処理を実行することを特徴とする流通管理サーバである。
【0016】
（５）また、本発明は、（４）記載の流通管理サーバであって、前記納品連絡書を記憶する納品連絡書データベース、を備え、前記制御部は、前記判定結果として、納品可能を意味する「可」、又は、納品不可を意味する「不可」のいずれかの値をフラグとして前記納品連絡書に設定し、設定後の「可」又は「不可」のフラグを設定された納品連絡書を前記納品連絡書データベースに記憶させ、前記制御部は、前記更新処理を実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成し、前記通信部は、前記制御部が生成した前記判定結果が「可」である場合は、その判定結果を外部に送信する、ことを特徴とする流通管理サーバである。
【0017】
（６）また、本発明は、（１）記載の流通管理サーバを用いて、流通管理を行う流通管理方法であって、前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成するステップと、前記通信部は、前記制御部が生成した前記判定結果を外部に送信するステップと、を含むことを特徴とする流通管理方法である。
【0018】
（７）また、本発明は、（６）記載の流通管理方法であって、前記制御部が、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新処理を実行する更新ステップ、を含むことを特徴とする流通管理方法である。
【0019】
（８）また、本発明は、（７）記載の流通管理方法であって、前記流通管理サーバは、前記納品連絡書を記憶する納品連絡書データベース、を備え、前記制御部が、前記更新ステップを実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成するステップと、前記通信部が、前記制御部が生成した前記判定結果を外部に送信するステップと、を含むことを特徴とする流通管理方法である。
【0020】
（９）また、本発明は、上記課題を解決するために、外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、制御部と、を備えたコンピュータを、（１）記載の流通管理サーバとして動作させるコンピュータプログラムであって、前記コンピュータに、前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御手順と、前記通信部が、前記制御手順で生成した前記判定結果を外部に送信する手順と、を実行させることを特徴とするコンピュータプログラムである。
【0021】
（１０）また、本発明は、（９）記載のコンピュータプログラムであって、前記コンピュータに、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新手順、を実行させることを特徴とするコンピュータプログラムである。
【0022】
（１１）また、本発明は、上記課題を解決するために、外部との通信を行う通信部と、納品可否判定基準情報を記憶する納品可否判定基準情報データベースと、制御部と、納品連絡書を記憶する納品連絡書データベースと、を備えたコンピュータを、（５）記載の流通管理サーバとして動作させるコンピュータプログラムであって、前記コンピュータに、前記制御部が、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、外部から送信されてきた納品連絡書に対する納品可否判定を実行し、その判定結果を生成する制御手順と、前記制御部が、前記判定結果として、納品可能を意味する「可」、又は、納品不可を意味する「不可」のいずれかの値をフラグとして前記納品連絡書に設定し、設定後の「可」又は「不可」のフラグを設定された納品連絡書を前記納品連絡書データベースに記憶させる手順と、外部から送信されてきた納品可否判定基準情報を、前記納品可否判定基準情報データベースに記憶させ、前記納品可否判定基準情報データベースの内容を更新する更新手順と、前記制御部が、前記更新処理を実行した後、前記納品可否判定基準情報データベースに記憶されている納品可否判定基準情報に基づき、前記納品連絡書データベースに記憶されている納品連絡書の中で「不可」の判定をした「不可」納品連絡書に対して、再度納品可否判定を実行し、その判定結果を生成する第２制御手順と、前記通信部は、前記第２制御手順で生成した前記判定結果が「可」である場合は、その判定結果を外部に送信する手順と、を実行させることを特徴とするコンピュータプログラムである。
【発明の効果】
【0023】
このように、本発明によれば、納品可否判断を流通管理サーバで自動的に行わせたので、さらに、より迅速な医薬品の納品可否判断を行うことが可能である。
【図面の簡単な説明】
【0024】
【図1】本実施形態における流通管理サーバ１００の構成図である。
【図2】本実施形態における流通管理業務の説明図である。
【図3】本実施形態におけるアクセス権限の説明図である。
【図4】流通管理業務の詳細な動作を表すフローチャートである。
【図5】流通管理業務の詳細な動作を表すフローチャートである。
【図6】流通管理業務の詳細な動作を表すフローチャートである。
【図7】流通管理業務の詳細な動作を表すフローチャートである。
【図8】流通管理業務の詳細な動作を表すフローチャートである。
【図9】流通管理業務の詳細な動作を表すフローチャートである。
【図10】流通管理業務の詳細な動作を表すフローチャートであり、特に納品「可」の対応を表すフローチャートである。
【図11】流通管理業務の詳細な動作を表すフローチャートであり、特に納品「不可」の対応を表すフローチャートである。
【図12】流通管理業務の詳細な動作を表すフローチャートであり、特にロック解除の動作を表すフローチャートである。
【図13】ロック解除データ（データファイル出力）が出力される様子を示す説明図である。
【図14】本実施形態の効果を説明する説明図である。
【図15】従来の医薬品流通管理業務の説明図である。
【図16】従来の流通管理業務の処理動作の課題を示す説明図である。
【図17】従来の流通管理業務の処理動作の説明図である。
【発明を実施するための形態】
【0025】
以下、本発明の好適な実施形態に係る流通管理システム及びそれを構成する流通管理サーバ等の構成、さらにそれらを用いた流通管理業務の処理動作の様子を図面に基づき説明する。
【0026】
Ａ．流通管理サーバ
本実施形態に係る流通管理システム９０は、流通管理サーバ１００を中心に構成されている。この流通管理サーバ１００の構成図が図１に示されている。
この図に示すように、流通管理サーバ１００は、通信部１０２と、制御部１０４と、納品連絡書データベース１０６と、納品可否判定基準情報データベース１０８と、各種情報データベース１１０と、管理マスタ１１２と、を備えている。
通信部１０２は、外部との通信を司る通信インターフェースであり、種々の通信規格を採用してよい。通信部１０２は、所定の通信路１２０を介して、種々の外部装置と通信することができる。例えば、特約店端末１３０や、流通管理者端末１４０、ＭＲ端末１５０と通信を行うことができる。
本実施形態に係る流通管理システム９０は、流通管理サーバ１００を中心に構成されている。この流通管理サーバ１００の構成図が図１に示されている。
この図に示すように、流通管理サーバ１００は、通信部１０２と、制御部１０４と、納品連絡書データベース１０６と、納品可否判定基準情報データベース１０８と、各種情報データベース１１０と、管理マスタ１１２と、を備えている。
通信部１０２は、外部との通信を司る通信インターフェースであり、種々の通信規格を採用してよい。通信部１０２は、所定の通信路１２０を介して、種々の外部装置と通信することができる。例えば、特約店端末１３０や、流通管理者端末１４０、ＭＲ端末１５０と通信を行うことができる。
【0027】
また、通信部１０２は、ＷＥＢサーバ１０２ｂを備えている。そして、このＷＥＢサーバ１０２ｂが提供するＷＥＢページを介して、種々の情報を外部に発信し、また種々の情報を外部から入力することもできる。
例えば、ＷＥＢサーバ１０２ｂが提供するＷＥＢページ上で納品連絡書１２の情報を入力することによって、納品連絡書１２を流通管理サーバ１００へ「送信」したとすることも好適である。
また、例えば、制御部１０４が、ＷＥＢサーバ１０２ｂが提供するＷＥＢページ上で「納品可能」の表示をすることによって、納品連絡書１２の納品可否結果を外部（例えば特約店１０）に「送信」（連絡）することも好適である。
例えば、ＷＥＢサーバ１０２ｂが提供するＷＥＢページ上で納品連絡書１２の情報を入力することによって、納品連絡書１２を流通管理サーバ１００へ「送信」したとすることも好適である。
また、例えば、制御部１０４が、ＷＥＢサーバ１０２ｂが提供するＷＥＢページ上で「納品可能」の表示をすることによって、納品連絡書１２の納品可否結果を外部（例えば特約店１０）に「送信」（連絡）することも好適である。
【0028】
制御部１０４は、いわゆるＣＰＵと、そのＣＰＵが実行するコンピュータプログラムとから構成してよい。このＣＰＵが当該コンピュータプログラムを実行することによって、制御部が実現される。これによって、流通管理サーバ１００の動作が実行されている。つまり、流通管理サーバ１００は、コンピュータであり、制御部１０４はそのＣＰＵに相当し、流通管理サーバ１００の動作を実行する。すなわち、当該コンピュータプログラムは、流通管理サーバの動作を規定するプログラムである。また、コンピュータプログラムは所定の記憶装置に記憶しておいて良いし、記憶装置はどこに位置していてもよい。この記憶装置は、後述する各種データベースと同じ記憶装置を用いてもよいし、それらとは別の記憶装置でもよい。また、ここでいうコンピュータプログラムは、請求の範囲のコンピュータプログラムの好適な一例に相当する。
【0029】
納品連絡書データベース１０６は、納品連絡書１２を記憶するデータベースである。納品可否判定基準情報データベース１０８は、納品可否判定基準情報を記憶するデータベースである。各種情報１１０データベースは、後述する各種情報を記憶するデータベースである。また、管理マスタ１１２は、種々のマスタ情報を記憶するがその詳細は後述する。
これらの納品連絡書データベース１０６、納品可否判定基準情報データベース１０８、各種情報１１０データベース、及び管理マスタ１１２は、所定の記憶装置で構成してよく、ハードディスクや、各種半導体記装置で構成してよい。
また、図１に示すように、通信部１０２、制御部１０４、納品連絡書データベース１０６、納品可否判定基準情報データベース１０８、各種情報１１０データベース、及び管理マスタ１１２は、所定の内部通信路１１６を介してデータの送受信が可能である。
これらの納品連絡書データベース１０６、納品可否判定基準情報データベース１０８、各種情報１１０データベース、及び管理マスタ１１２は、所定の記憶装置で構成してよく、ハードディスクや、各種半導体記装置で構成してよい。
また、図１に示すように、通信部１０２、制御部１０４、納品連絡書データベース１０６、納品可否判定基準情報データベース１０８、各種情報１１０データベース、及び管理マスタ１１２は、所定の内部通信路１１６を介してデータの送受信が可能である。
【0030】
通信路１２０は、流通管理サーバ１００と、特約店端末１３０と、ＭＲ端末１５０と、を結ぶ通信路である。
特約店端末１３０は、通信路１２０を介した通信が可能な通信インターフェースを備えたコンピュータ端末である。特約店１０(の担当者）は、納品連絡書１２をこの特約店端末１３０から流通管理サーバ１００に送信する。
流通管理端末１４０は、通信路１２０を介した通信が可能な通信インターフェースを備えたコンピュータ端末である。流通管理者１４は、流通管理者端末１４０を介して流通管理サーバ１００にアクセスする。
ＭＲ端末１５０は、通信路１２０を介した通信が可能な通信インターフェースを備えたコンピュータ端末である。ＭＲ１８は、ＭＲ端末１５０を介して流通管理サーバ１００にアクセスする。
特約店端末１３０は、通信路１２０を介した通信が可能な通信インターフェースを備えたコンピュータ端末である。特約店１０(の担当者）は、納品連絡書１２をこの特約店端末１３０から流通管理サーバ１００に送信する。
流通管理端末１４０は、通信路１２０を介した通信が可能な通信インターフェースを備えたコンピュータ端末である。流通管理者１４は、流通管理者端末１４０を介して流通管理サーバ１００にアクセスする。
ＭＲ端末１５０は、通信路１２０を介した通信が可能な通信インターフェースを備えたコンピュータ端末である。ＭＲ１８は、ＭＲ端末１５０を介して流通管理サーバ１００にアクセスする。
【0031】
Ｂ．流通管理業務
本実施形態に係る流通管理業務の概要が図２に示されている。この図は従来の流通管理業務を表す図１７と対応する図である。以下、図２及び他の図を用いて、本実施形態の流通管理業務の特徴を説明する。
流通管理サーバ１００内の情報の更新
まず、図２の白丸１において、ＭＲ１８は、納品可否判断基準の聴取を病院・薬局１６に対して行う。
その後、白丸２において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判断基準の情報）を流通管理サーバ１００に送信する。流通管理サーバ１００は、受信した納品可否判断基準の情報を、納品可否判定基準情報データベース１０８に記憶する。
本実施形態では、このＭＲ１８が実行する「送信」は、流通管理サーバ１００が提供するＷｅｂサイト（Ｗｅｂ画面）上で、ＭＲ１８が、納品可否判断基準の情報を入力することによって行われる。これによって、流通管理サーバ１００は、納品可否判断基準の情報に基づき、納品可否判定を実行することができる。
本実施形態に係る流通管理業務の概要が図２に示されている。この図は従来の流通管理業務を表す図１７と対応する図である。以下、図２及び他の図を用いて、本実施形態の流通管理業務の特徴を説明する。
流通管理サーバ１００内の情報の更新
まず、図２の白丸１において、ＭＲ１８は、納品可否判断基準の聴取を病院・薬局１６に対して行う。
その後、白丸２において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判断基準の情報）を流通管理サーバ１００に送信する。流通管理サーバ１００は、受信した納品可否判断基準の情報を、納品可否判定基準情報データベース１０８に記憶する。
本実施形態では、このＭＲ１８が実行する「送信」は、流通管理サーバ１００が提供するＷｅｂサイト（Ｗｅｂ画面）上で、ＭＲ１８が、納品可否判断基準の情報を入力することによって行われる。これによって、流通管理サーバ１００は、納品可否判断基準の情報に基づき、納品可否判定を実行することができる。
【0032】
納品可否判断基準の情報が、流通管理サーバ１００に到達するまでのルートは２種類存在する。すなわち、図２において、白丸２は２カ所示されている。１カ所目（第１のルート）は、上述したようにＭＲ１８から直接に流通管理サーバ１００に至るルートである。
２カ所目（第２のルート）は、ＭＲ１８から製薬会社のクライアントＤＢ（データベース）１６０を経由して流通管理サーバ１００に至るルートである。この第２のルートは、従前のＭＲ１８が実行していた手順を踏襲したルートである。すなわち、従来、ＭＲ１８は、自己が入手した納品可否判断基準の情報を、製薬会社のクライアントＤＢ（データベース）１６０に入力していたので、この第２のルートによれば、ＭＲ１８は新しい操作（流通管理サーバ１００に情報を送信する動作）を覚える必要がなく、本システムの導入を容易にすることができるというメリットがある。
２カ所目（第２のルート）は、ＭＲ１８から製薬会社のクライアントＤＢ（データベース）１６０を経由して流通管理サーバ１００に至るルートである。この第２のルートは、従前のＭＲ１８が実行していた手順を踏襲したルートである。すなわち、従来、ＭＲ１８は、自己が入手した納品可否判断基準の情報を、製薬会社のクライアントＤＢ（データベース）１６０に入力していたので、この第２のルートによれば、ＭＲ１８は新しい操作（流通管理サーバ１００に情報を送信する動作）を覚える必要がなく、本システムの導入を容易にすることができるというメリットがある。
【0033】
製薬会社のクライアントＤＢ（データベース）１６０には、医薬品に対して設定されている納品可否判定基準情報、各種マスタ情報が格納されている。納品可否判定基準情報は、ＭＲ１８から提供された情報、その他の情報が記憶される。
本実施形態においては、クライアントＤＢ１６０のこれらの情報が、流通管理者１４を介して、流通管理サーバ１００内に収容されていく。
本実施形態においては、クライアントＤＢ１６０のこれらの情報が、流通管理者１４を介して、流通管理サーバ１００内に収容されていく。
【0034】
白丸３において、流通管理者１４は、製薬会社のクライアントＤＢ１６０にアクセスし、そこから納品可否判定基準情報と、各種マスタ情報とを読み出す。
次に、白丸４において、流通管理者１４は、白丸３で読み出した納品可否判定基準情報と、各種マスタ情報とを、流通管理サーバ１００内のデータベースに格納する。具体的には、納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶させて内容を更新させる。また、マスタ情報を、管理マスタ１１２や各種情報データベース１１０に記憶させて、その内容を更新させている。
このように、本実施形態の流通管理者１４の役割には、流通管理サーバ１００に格納されている各種情報を適宜更新させる役割が含まれている。
このような処理によって、上述した第２のルートが形成されている。
次に、白丸４において、流通管理者１４は、白丸３で読み出した納品可否判定基準情報と、各種マスタ情報とを、流通管理サーバ１００内のデータベースに格納する。具体的には、納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶させて内容を更新させる。また、マスタ情報を、管理マスタ１１２や各種情報データベース１１０に記憶させて、その内容を更新させている。
このように、本実施形態の流通管理者１４の役割には、流通管理サーバ１００に格納されている各種情報を適宜更新させる役割が含まれている。
このような処理によって、上述した第２のルートが形成されている。
【0035】
納品可否判定
次に、図２の白丸５において、病院・薬局１６が、特約店１０に医薬品の発注を行う。
白丸６において、特約店１０は、納品連絡書１２を流通管理サーバ１００に送信する。本実施形態では、この「送信」は、流通管理サーバ１００が提供するＷｅｂサイト上で納品連絡書１２の情報を入力することによって行われる。
白丸７において、流通管理サーバ１００は、納品可否結果（例えば「可」や「可能」）の連絡（送信）を特約店１０に対してＥメールで行う。さらに同白丸７において、流通管理サーバ１００は、納品可否結果の連絡を同様にＥメールでＭＲ１８に対して行う。これらの連絡は、一つの同報メールで行ってもよい。
白丸８において、上記納品可否結果（可能）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行う。
上記例では、納品可否結果を、Ｅメールで送信しているが、他の方法で連絡してもよい。例えば、ＷＥＢサーバ１０２ｂが提供する画面上で納品連絡書１２の番号と共に「可」／「不可」等の表示を行ってもよい。このような動作も納品可否結果の「送信」の一種に該当する。
次に、図２の白丸５において、病院・薬局１６が、特約店１０に医薬品の発注を行う。
白丸６において、特約店１０は、納品連絡書１２を流通管理サーバ１００に送信する。本実施形態では、この「送信」は、流通管理サーバ１００が提供するＷｅｂサイト上で納品連絡書１２の情報を入力することによって行われる。
白丸７において、流通管理サーバ１００は、納品可否結果（例えば「可」や「可能」）の連絡（送信）を特約店１０に対してＥメールで行う。さらに同白丸７において、流通管理サーバ１００は、納品可否結果の連絡を同様にＥメールでＭＲ１８に対して行う。これらの連絡は、一つの同報メールで行ってもよい。
白丸８において、上記納品可否結果（可能）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行う。
上記例では、納品可否結果を、Ｅメールで送信しているが、他の方法で連絡してもよい。例えば、ＷＥＢサーバ１０２ｂが提供する画面上で納品連絡書１２の番号と共に「可」／「不可」等の表示を行ってもよい。このような動作も納品可否結果の「送信」の一種に該当する。
【0036】
納品可否判定その２
さて、上記白丸７において、納品可否結果が「不可」であった場合も、Ｅメールで、特約店１０及びＭＲ１８に対して連絡を行う。その場合は、上記納品可否結果（不可）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行わない。
この場合、黒丸９において、ＭＲ１８が再び、納品可否判断基準の聴取を病院・薬局１６に対して行う。この処理は基本的に白丸１と同様の処理であるが、ＭＲ１８は、白丸７において、納品可否結果が「不可」であった連絡を受け取っているので、それに応じた聴取を行うことによって、効率的な聴取が可能となる。
さて、上記白丸７において、納品可否結果が「不可」であった場合も、Ｅメールで、特約店１０及びＭＲ１８に対して連絡を行う。その場合は、上記納品可否結果（不可）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行わない。
この場合、黒丸９において、ＭＲ１８が再び、納品可否判断基準の聴取を病院・薬局１６に対して行う。この処理は基本的に白丸１と同様の処理であるが、ＭＲ１８は、白丸７において、納品可否結果が「不可」であった連絡を受け取っているので、それに応じた聴取を行うことによって、効率的な聴取が可能となる。
【0037】
その後、黒丸１０において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判断基準の情報）を流通管理サーバ１００に送信する。流通管理サーバ１００は、受信した納品可否判断基準の情報を、納品可否判定基準情報データベース１０８に記憶する。
この黒丸１０の動作は、既に説明した白丸２の動作と同様であり、第１のルート又は第２のルートによって、納品可否判断基準の情報を、流通管理サーバ１００に送信（入力）することができ、流通管理サーバ１００は、新しい更新された納品可否判断基準の情報に基づき、本システムの特徴的な動作である納品可否判定を実行することができる。
ここで、納品可否判断基準の情報を、流通管理サーバ１００に送信（入力）する方法としては、ＷＥＢサーバ１０２ｂが提供するＷＥＢ画面上で納品可否判断基準の情報を入力するように構成してもよい。
この黒丸１０の動作は、既に説明した白丸２の動作と同様であり、第１のルート又は第２のルートによって、納品可否判断基準の情報を、流通管理サーバ１００に送信（入力）することができ、流通管理サーバ１００は、新しい更新された納品可否判断基準の情報に基づき、本システムの特徴的な動作である納品可否判定を実行することができる。
ここで、納品可否判断基準の情報を、流通管理サーバ１００に送信（入力）する方法としては、ＷＥＢサーバ１０２ｂが提供するＷＥＢ画面上で納品可否判断基準の情報を入力するように構成してもよい。
【0038】
黒丸１１において、流通管理者１４は、製薬会社のクライアントＤＢ１６０にアクセスし、そこから納品可否判定基準情報と、各種マスタ情報とを読み出す。この処理は、白丸３と同様の処理である。
黒丸１２において、流通管理者１４は、白丸３で読み出した納品可否判定基準情報と、各種マスタ情報とを、流通管理サーバ１００内のデータベースに格納する。この処理は、白丸４と同様の処理である。すなわち、納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶させて内容を更新させる。また、マスタ情報を、管理マスタ１１２や各種情報データベース１１０に記憶させて、その内容を更新させている。
黒丸１２において、流通管理者１４は、白丸３で読み出した納品可否判定基準情報と、各種マスタ情報とを、流通管理サーバ１００内のデータベースに格納する。この処理は、白丸４と同様の処理である。すなわち、納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶させて内容を更新させる。また、マスタ情報を、管理マスタ１１２や各種情報データベース１１０に記憶させて、その内容を更新させている。
【0039】
次に、黒丸１３において、流通管理サーバ１００は、納品可否判定基準情報データベース１０８の内容が更新された場合、これまでに「不可」処理とした納品連絡書１２の内容を再び判断し、納品可否判定を実行する。流通管理サーバ１００は、受信した納品連絡書１２を納品連絡書データベース１０６に記憶させている。特に、判定結果である「可」「不可」は、その納品連絡書１２にフラグとして付随させているので、納品連絡書データベース１０６中の、納品連絡書１２は、判定結果も含めて記憶されている。したがって、制御部１０４は、「不可」の判定をした納品連絡書１２を納品連絡書データベース１０６から抽出することは容易である。
【0040】
そして、流通管理サーバ１００は、一度、「不可」の判定をした納品連絡書１２に対して再び判定を行い「可」となる納品可否結果の連絡を特約店１０に対してＥメールで行うことができる。具体的には、制御部１０４が納品可否結果の連絡を伴うＥメールを作成し、通信部１０２がこれを送信することができる。いわゆる自動メールの仕組みで実行してよい。
さらに同黒丸１３において、流通管理サーバ１００は、納品可否結果（可）の連絡を同様にＥメールでＭＲ１８に対して行う。このＥメールの送信も、制御部がＥメールを作成し、通信部１０２がこれを送信する自動メールで実行してよい。
これらの連絡は、一つの同報メールで行ってもよい。ここでは、Ｅメールの例を説明したが、他の通信方法でもよく、例えばＷＥＢ上で送信（連絡）してもよい。
黒丸１４において、上記納品可否結果（可）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行う。
さらに同黒丸１３において、流通管理サーバ１００は、納品可否結果（可）の連絡を同様にＥメールでＭＲ１８に対して行う。このＥメールの送信も、制御部がＥメールを作成し、通信部１０２がこれを送信する自動メールで実行してよい。
これらの連絡は、一つの同報メールで行ってもよい。ここでは、Ｅメールの例を説明したが、他の通信方法でもよく、例えばＷＥＢ上で送信（連絡）してもよい。
黒丸１４において、上記納品可否結果（可）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行う。
【0041】
Ｃ．アクセス権限
ここで、本実施形態における流通管理サーバ１００のアクセス権限に関して説明する。
図３には、流通管理サーバ１００内の各データベースに対するアクセス権限を説明する図が示されている。
ここでは、説明を理解しやすくするために、製薬会社Ａの医薬品（１）と、製薬会社Ｂの医薬品（２）と、を扱う例を説明する。図１等で説明したように、流通管理サーバ１００は各種データベースを備えているが、そのデータベースは、扱う医薬品毎に内部データが分けて管理されている。つまり、実質的には、医薬品毎に各種データベースが存在するのと同様である。
ここで、本実施形態における流通管理サーバ１００のアクセス権限に関して説明する。
図３には、流通管理サーバ１００内の各データベースに対するアクセス権限を説明する図が示されている。
ここでは、説明を理解しやすくするために、製薬会社Ａの医薬品（１）と、製薬会社Ｂの医薬品（２）と、を扱う例を説明する。図１等で説明したように、流通管理サーバ１００は各種データベースを備えているが、そのデータベースは、扱う医薬品毎に内部データが分けて管理されている。つまり、実質的には、医薬品毎に各種データベースが存在するのと同様である。
【0042】
図３の例では、製薬会社Ａの医薬品（１）と、製薬会社Ｂの医薬品（２）と、を扱う例を説明しているので、各種データベースとして２種類存在するものとして模式的に図３は描かれている。
すなわち、製薬会社Ａの医薬品（１）向けに、納品連絡書データベース１０６ａと、納品可否判定基準情報及び各種情報データベース１１４ａと、管理マスタ１１２ａと、が備えられている。ここで、納品可否判定基準情報及び各種情報データベース１１４ａとは、図１に示した納品可否判定基準情報データベース１０８と各種情報データベース１１０とを合わせて表現したものであり、これら両方のデータベースを含むものである。
同様に、製薬会社Ｂの医薬品（２）向けに、納品連絡書データベース１０６ｂと、納品可否判定基準情報及び各種情報データベース１１４ｂと、管理マスタ１１２ｂと、が備えられている。
すなわち、製薬会社Ａの医薬品（１）向けに、納品連絡書データベース１０６ａと、納品可否判定基準情報及び各種情報データベース１１４ａと、管理マスタ１１２ａと、が備えられている。ここで、納品可否判定基準情報及び各種情報データベース１１４ａとは、図１に示した納品可否判定基準情報データベース１０８と各種情報データベース１１０とを合わせて表現したものであり、これら両方のデータベースを含むものである。
同様に、製薬会社Ｂの医薬品（２）向けに、納品連絡書データベース１０６ｂと、納品可否判定基準情報及び各種情報データベース１１４ｂと、管理マスタ１１２ｂと、が備えられている。
【0043】
納品連絡書データベース１０６ａ、１０６ｂは、納品連絡書１２のデータの他に、特約店１０が入力する納品先の病院・薬局１６の情報を含んでよい。
納品可否判定基準情報及び各種情報データベース１１４ａ、１１４ｂは、契約書情報や、ＭＲ１８の活動情報など、納品可否判定基準に関わる情報が記憶されている。
管理マスタ１１２ａ、１１２ｂは、特約店１０、ＭＲ１８、病院・薬局１６製薬会社担当者情報を含めてよい。
納品可否判定基準情報及び各種情報データベース１１４ａ、１１４ｂは、契約書情報や、ＭＲ１８の活動情報など、納品可否判定基準に関わる情報が記憶されている。
管理マスタ１１２ａ、１１２ｂは、特約店１０、ＭＲ１８、病院・薬局１６製薬会社担当者情報を含めてよい。
【0044】
図３に示すような状況の下では、アクセス権限は以下のように規定される。
流通管理者１４は、流通管理サーバ１００の管理・運用を行うので、全てのデータベースにアクセスすることができる。
特約店１０は、製薬会社から承認され、自己が取り扱っている医薬品に関するデータベースであれば、全てのデータベースにアクセスすることができる。図３の例では、特約店１０は医薬品（１）及び医薬品（２）を扱っているので、両方の全てのデータベースにアクセスすることができる。
流通管理者１４は、流通管理サーバ１００の管理・運用を行うので、全てのデータベースにアクセスすることができる。
特約店１０は、製薬会社から承認され、自己が取り扱っている医薬品に関するデータベースであれば、全てのデータベースにアクセスすることができる。図３の例では、特約店１０は医薬品（１）及び医薬品（２）を扱っているので、両方の全てのデータベースにアクセスすることができる。
【0045】
各製薬会社は、それぞれ自社に関する医薬品に関するデータベースにのみアクセスすることができる。製薬会社Ａの本社担当者１８０ａは、自社の医薬品（１）に関するデータベースには全てアクセスすることができる。しかし、製薬会社ＡのＭＲ１８ａは、管理マスタ１１２ａにはアクセスできず、他の納品連絡書データベース１０８ａと、納品可否判定基準情報及び各種情報データベース１１４ａにしかアクセスすることができない。
同様に、製薬会社Ｂの本社担当者１８０ｂは、自社の医薬品（２）に関するデータベースには全てアクセスすることができる。しかし、製薬会社ＢのＭＲ１８ｂは、管理マスタ１１２ｂにはアクセスできず、他の納品連絡書データベース１０８ｂと、納品可否判定基準情報及び各種情報データベース１１４ｂにしかアクセスすることができない。
同様に、製薬会社Ｂの本社担当者１８０ｂは、自社の医薬品（２）に関するデータベースには全てアクセスすることができる。しかし、製薬会社ＢのＭＲ１８ｂは、管理マスタ１１２ｂにはアクセスできず、他の納品連絡書データベース１０８ｂと、納品可否判定基準情報及び各種情報データベース１１４ｂにしかアクセスすることができない。
【0046】
Ｄ．詳細な動作
以下、フローチャートに基づき、本実施形態に係る流通管理システム９０の詳細な動作を説明する。
以下、フローチャートに基づき、本実施形態に係る流通管理システム９０の詳細な動作を説明する。
【0047】
（１）準備処理その１
図４には、本流通管理システム９０の準備処理のフローチャートが示されている。
特に、図４は、図２の白丸３、黒丸１１に相当する処理を表している。
ステップＳ４－１は、クライアントＤＢ１６０内の施設マスタを表している。このデータは、社内施設マスタであり、必要に応じ適宜更新される。このデータは、後述するようにファイル共有にて、流通管理者１４によって流通管理サーバ１００内に取り込まれる。
ステップＳ４－２は、クライアントＤＢ１６０内の「担当ＭＲ情報メールアドレス一覧」を表している。このデータは、必要に応じ適宜更新される。このデータは、流通管理者１４（流通管理者端末１４０）に対してメールで送信される。
ステップＳ４－３において、ステップＳ４－２において送信されたメールが流通管理者１４（流通管理者端末１４０）によって受信される。そして、流通管理サーバ１００のデータベースにそのメールで送られてきた「担当ＭＲメール情報」を登録する。
図４には、本流通管理システム９０の準備処理のフローチャートが示されている。
特に、図４は、図２の白丸３、黒丸１１に相当する処理を表している。
ステップＳ４－１は、クライアントＤＢ１６０内の施設マスタを表している。このデータは、社内施設マスタであり、必要に応じ適宜更新される。このデータは、後述するようにファイル共有にて、流通管理者１４によって流通管理サーバ１００内に取り込まれる。
ステップＳ４－２は、クライアントＤＢ１６０内の「担当ＭＲ情報メールアドレス一覧」を表している。このデータは、必要に応じ適宜更新される。このデータは、流通管理者１４（流通管理者端末１４０）に対してメールで送信される。
ステップＳ４－３において、ステップＳ４－２において送信されたメールが流通管理者１４（流通管理者端末１４０）によって受信される。そして、流通管理サーバ１００のデータベースにそのメールで送られてきた「担当ＭＲメール情報」を登録する。
【0048】
ステップＳ４－４は、クライアントＤＢ１６０内の「上長担当ＭＲ紐付け一覧」を表している。このデータは、必要に応じ適宜更新される。このデータは、流通管理者１４（流通管理者端末１４０）に対してメールで送信される。
ステップＳ４－５において、ステップＳ４－４において送信されたメールが流通管理者１４（流通管理者端末１４０）によって受信される。そして、流通管理サーバ１００のデータベースにそのメールで送られてきた「上長－ＭＲ紐付け情報」を登録する。
ステップＳ４－１、ステップＳ４－２、ステップＳ４－４は、マスタ情報と呼ばれ、主として情報マスタ１１２に記憶される。
ステップＳ４－５において、ステップＳ４－４において送信されたメールが流通管理者１４（流通管理者端末１４０）によって受信される。そして、流通管理サーバ１００のデータベースにそのメールで送られてきた「上長－ＭＲ紐付け情報」を登録する。
ステップＳ４－１、ステップＳ４－２、ステップＳ４－４は、マスタ情報と呼ばれ、主として情報マスタ１１２に記憶される。
【0049】
ステップＳ４－６は、クライアントＤＢ１６０内の「契約データ」を表している。このデータは、納品可否判定基準情報の１種であり、後述するようにファイル共有にて、流通管理者１４によって流通管理サーバ１００内の主に納品可否判定基準情報データベース１０８に記憶される。
図４の説明においては、メールの送信やファイル共有等の手法を説明したが、クライアント側の要望によっては、ＷｅｂＡＰＩ等を用いてデータを自動連携させることも好適である。この場合は、図２における白丸３、黒丸１１の処理が自動処理されるが、同連携によって、白丸４、黒丸１２の処理も含めて連携をとることも好適である。
また、図４及びその説明において示された種々の情報・書類は、一例であって、他の様々な情報・書類を利用してよい。また、図４中の納品判定基準情報としても、図４以外の他の様々な情報・書類を利用してよい。
図４の説明においては、メールの送信やファイル共有等の手法を説明したが、クライアント側の要望によっては、ＷｅｂＡＰＩ等を用いてデータを自動連携させることも好適である。この場合は、図２における白丸３、黒丸１１の処理が自動処理されるが、同連携によって、白丸４、黒丸１２の処理も含めて連携をとることも好適である。
また、図４及びその説明において示された種々の情報・書類は、一例であって、他の様々な情報・書類を利用してよい。また、図４中の納品判定基準情報としても、図４以外の他の様々な情報・書類を利用してよい。
【0050】
図４のフローチャートの続きの処理が、図５のフローチャートに示されている。
図５のステップＳ５－１は、図４で説明した各種データを用いた、流通管理サーバ１００内のデータベースの更新が行われる。この更新は流通管理者１４が、流通管理者端末１４０を介して実行される。
上述した施設マスタ（Ｓ４－１）や、契約データ（Ｓ４－６）は、ファイル共有で流通管理サーバ１００内のデータベースの更新に用いられるが、他の方法でデータ更新を行ってもよい。担当ＭＲメール情報（Ｓ４－３）や、上長～ＭＲ紐付け情報（Ｓ４－５）は、流通管理者１４がデータ更新してもよい。また、例えば、上述のように、ＷｅｂＡＰＩ等を用いた自動連携を行わせてもよい。
図５のステップＳ５－１は、図４で説明した各種データを用いた、流通管理サーバ１００内のデータベースの更新が行われる。この更新は流通管理者１４が、流通管理者端末１４０を介して実行される。
上述した施設マスタ（Ｓ４－１）や、契約データ（Ｓ４－６）は、ファイル共有で流通管理サーバ１００内のデータベースの更新に用いられるが、他の方法でデータ更新を行ってもよい。担当ＭＲメール情報（Ｓ４－３）や、上長～ＭＲ紐付け情報（Ｓ４－５）は、流通管理者１４がデータ更新してもよい。また、例えば、上述のように、ＷｅｂＡＰＩ等を用いた自動連携を行わせてもよい。
【0051】
Ｄ５－１は、流通管理ＤＢ（施設情報）であり、流通管理サーバ１００内のデータベースであって、特に施設情報に関するものである。具体的には、主として管理マスタ１１２が該当する。ステップＳ５－１においては、Ｄ５－１の流通管理ＤＢ（施設情報）が更新される。
ステップＳ５－２は、申請書・協力確認書保留分一時保管処理である。これは処理を保留した申請書等を一時保管する処理である。申請書等は、各種情報データベース１１０に一時保管しておいてよい。この一時保管は、流通管理者１４が、流通管理者端末１４０を用いて流通管理サーバ１００中のデータベースを操作することによって実行される。
ステップＳ５－３において、保留分の申請書・協力確認書を流通管理サーバ１００のデータベースに反映させる処理が実行される。この処理は流通管理者１４が流通管理者端末１４０を用いて、流通管理サーバ１００中のデータベースを操作することによって実行される。ステップＳ５－１と同様にＤ５－１の流通管理ＤＢ（施設情報）が更新の対象となる。
ステップＳ５－２は、申請書・協力確認書保留分一時保管処理である。これは処理を保留した申請書等を一時保管する処理である。申請書等は、各種情報データベース１１０に一時保管しておいてよい。この一時保管は、流通管理者１４が、流通管理者端末１４０を用いて流通管理サーバ１００中のデータベースを操作することによって実行される。
ステップＳ５－３において、保留分の申請書・協力確認書を流通管理サーバ１００のデータベースに反映させる処理が実行される。この処理は流通管理者１４が流通管理者端末１４０を用いて、流通管理サーバ１００中のデータベースを操作することによって実行される。ステップＳ５－１と同様にＤ５－１の流通管理ＤＢ（施設情報）が更新の対象となる。
【0052】
ステップＳ５－４において、上記ステップＳ５－３において処理した書類（データ）に契約情報が記載されているかどうか確認が行われる。この処理も流通管理者１４が、流通管理者端末１４０を用いて、流通管理サーバ１００内のデータベースを確認することによって行われる。その結果、契約情報が記載されていれば、ステップＳ５－５に処理が移行し、契約情報が記載されていない場合は、ステップＳ５－６に処理が移行する。
ステップＳ５－５において、申請書・協力確認書の保留分を登録する。この処理は流通管理者１４が流通管理者端末１４０を用いて、流通管理サーバ１００中のデータベースを操作することによって実行される。
ステップＳ５－６において、申請書・協力確認書の保留分を一時保管する。この処理は、ステップＳ５－２と同様の処理である。
このように、契約情報（納品可否判定基準情報）が（流通管理サーバ１００に）インポートされ、インポート前後で比較した際に、契約情報「無」のものが「有」となった場合、図２における白丸２や黒丸１０の登録ができるようになるものがある可能性がある。次節では、この白丸２や黒丸１０の処理をフローチャートに基づき説明する。
ステップＳ５－５において、申請書・協力確認書の保留分を登録する。この処理は流通管理者１４が流通管理者端末１４０を用いて、流通管理サーバ１００中のデータベースを操作することによって実行される。
ステップＳ５－６において、申請書・協力確認書の保留分を一時保管する。この処理は、ステップＳ５－２と同様の処理である。
このように、契約情報（納品可否判定基準情報）が（流通管理サーバ１００に）インポートされ、インポート前後で比較した際に、契約情報「無」のものが「有」となった場合、図２における白丸２や黒丸１０の登録ができるようになるものがある可能性がある。次節では、この白丸２や黒丸１０の処理をフローチャートに基づき説明する。
【0053】
（２）準備処理その２
次に、図２における白丸２や黒丸１０に相当し、そして白丸３、黒丸１１にも相当する処理を、図７のフローチャートに基づき説明する。
（２）－１ 様々な納品判定基準情報
図７のＤ７－１の実施施設責任医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－２で表されている。また、流通管理者１４（流通管理者端末１４０に）にメールを送信した状態がＤ７－３で表されている。
同様に、Ｄ７－４の分担医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－５で表されている。また、流通管理者１４（流通管理者端末１４０）にメールを送信した状態がＤ７－６で表されている。
また、Ｄ７－７で示される協力確認書（医師用）は、病院・薬局１６からＭＲ１８に提供される。ＭＲ１８に提供された状態がＤ７－８で示されている。このＤ７－８をＭＲ１８がクライアントＤＢに入力する。入力した状態がＤ７－９で表されている。また、流通管理者１４に（流通管理者端末１４０に）メールを送信した状態がＤ７－１０で表されている。
次に、図２における白丸２や黒丸１０に相当し、そして白丸３、黒丸１１にも相当する処理を、図７のフローチャートに基づき説明する。
（２）－１ 様々な納品判定基準情報
図７のＤ７－１の実施施設責任医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－２で表されている。また、流通管理者１４（流通管理者端末１４０に）にメールを送信した状態がＤ７－３で表されている。
同様に、Ｄ７－４の分担医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－５で表されている。また、流通管理者１４（流通管理者端末１４０）にメールを送信した状態がＤ７－６で表されている。
また、Ｄ７－７で示される協力確認書（医師用）は、病院・薬局１６からＭＲ１８に提供される。ＭＲ１８に提供された状態がＤ７－８で示されている。このＤ７－８をＭＲ１８がクライアントＤＢに入力する。入力した状態がＤ７－９で表されている。また、流通管理者１４に（流通管理者端末１４０に）メールを送信した状態がＤ７－１０で表されている。
【0054】
また、Ｄ７－１１で示される協力確認書（薬剤部用）は、病院・薬局１６からＭＲ１８に提供される。ＭＲ１８に提供された状態がＤ７－１２で示されている。このＤ７－１２をＭＲ１８がクライアントＤＢに入力する。入力した状態がＤ７－１３で表されている。また、流通管理者１４にメールを送信した状態がＤ７－１４で表されている。
図７で示す例では、ＭＲ１８が、入手した情報をクライアントＤＢ１６０に入力する動作例を示している。この動作は上述したように、図２における白丸２、黒丸１０の動作、さらに流通管理者１４に至る白丸３、黒丸１１に動作に該当する。
図７で示す例では、ＭＲ１８が、入手した情報をクライアントＤＢ１６０に入力する動作例を示している。この動作は上述したように、図２における白丸２、黒丸１０の動作、さらに流通管理者１４に至る白丸３、黒丸１１に動作に該当する。
【0055】
なお、ＭＲ１８は、クライアントＤＢ１６０ではなく、流通管理サーバ１００に直接入力することも好適である。この場合、ＭＲ１８は、ＭＲ端末１５０を用いて、流通管理サーバ１００にアクセスし、画面上で必要なデータを入力することによって、図７に示すような情報を直接流通管理サーバ１００に入力することができる。
【0056】
具体的には、流通管理サーバ１００が、データ入力のためのＷｅｂサイトをＭＲ１８に対して提供することが好ましい。つまり、通信部１０２のＷＥＢサーバ１０２ｂがこのようなＷＥＢサイトの画面を提供し、ＭＲ１８はその画面上で所定のデータを入力することによって、所定のデータを直接流通管理サーバ１００の各種データベースに記憶させることができる。ＷＥＢ１０２ｂは、入力されたデータを制御部１０４に送り、制御部１０４は、そのデータを種類に応じて納品判定基準情報データベース１０８等の各種情報データベース１１０等のデータベースに記憶させる。このようにして、納品判定基準情報データベース１０８等の更新が行われる。
さて、納品判定基準情報データベース１０８に格納されるデータは、納品判定基準情報である。図７及びその説明（主として（２）－１準備処理その２の説明）において示された種々の納品判定基準情報は、一例であって、他の様々な情報を、納品判定基準情報として利用してよい。
さて、納品判定基準情報データベース１０８に格納されるデータは、納品判定基準情報である。図７及びその説明（主として（２）－１準備処理その２の説明）において示された種々の納品判定基準情報は、一例であって、他の様々な情報を、納品判定基準情報として利用してよい。
【0057】
（２）－２ データベースの更新
図７のフローチャートの続きの処理が、図８のフローチャートに示されている。図８のステップＳ８－１において、図７で説明した各種データを用いて流通管理サーバ１００内のデータベースの更新が行われる。この更新は流通管理者１４が、流通管理者端末１４０を介して実行してよい。
上述した種々の申請書（Ｄ７－３、Ｄ７－６）や、確認書（Ｄ７－１０、Ｄ７－１４）は、流通管理ＤＢ（施設情報）Ｄ８－１と突き合わせて更新処理が行われる。この処理は、流通管理者１４が、流通管理者端末１４０を用いて、流通管理サーバ１００のデータベースを操作して更新する。なお、流通管理ＤＢ（施設情報）Ｄ８－１は、図５の流通管理ＤＢ（施設情報）Ｄ５－１と同様のデータベースである。
ステップＳ８－２において、上記ステップＳ８－１において更新したデータについて契約情報が記載されているかどうか確認される。この処理も流通管理者１４が、流通管理者端末１４０を用いて、流通管理サーバ１００内のデータベースを確認することによって行われる。その結果、契約情報が記載されていれば、ステップＳ８－４に処理が移行し、契約情報が記載されていない場合は、ステップＳ８－３に処理が移行する。
図７のフローチャートの続きの処理が、図８のフローチャートに示されている。図８のステップＳ８－１において、図７で説明した各種データを用いて流通管理サーバ１００内のデータベースの更新が行われる。この更新は流通管理者１４が、流通管理者端末１４０を介して実行してよい。
上述した種々の申請書（Ｄ７－３、Ｄ７－６）や、確認書（Ｄ７－１０、Ｄ７－１４）は、流通管理ＤＢ（施設情報）Ｄ８－１と突き合わせて更新処理が行われる。この処理は、流通管理者１４が、流通管理者端末１４０を用いて、流通管理サーバ１００のデータベースを操作して更新する。なお、流通管理ＤＢ（施設情報）Ｄ８－１は、図５の流通管理ＤＢ（施設情報）Ｄ５－１と同様のデータベースである。
ステップＳ８－２において、上記ステップＳ８－１において更新したデータについて契約情報が記載されているかどうか確認される。この処理も流通管理者１４が、流通管理者端末１４０を用いて、流通管理サーバ１００内のデータベースを確認することによって行われる。その結果、契約情報が記載されていれば、ステップＳ８－４に処理が移行し、契約情報が記載されていない場合は、ステップＳ８－３に処理が移行する。
【0058】
ステップＳ８－３において、申請書・協力確認書の保留分を一時保管する。この処理は、ステップＳ５－２、Ｓ５－６と同様の処理である。
本実施形態に係る流通管理業務を行う場合は、契約情報に紐付いて（ユーザの）登録をさせるため、契約情報がない場合は、ＭＲ１８は、（流通管理サーバ１００に）直接登録をすることはできない。施設情報を取得する前に、施設と契約を締約する必要がある。すなわち、かかる契約が締結されるまでは、流通管理サーバ１００への（直接）登録を行うことが保留となる。
本実施形態に係る流通管理業務を行う場合は、契約情報に紐付いて（ユーザの）登録をさせるため、契約情報がない場合は、ＭＲ１８は、（流通管理サーバ１００に）直接登録をすることはできない。施設情報を取得する前に、施設と契約を締約する必要がある。すなわち、かかる契約が締結されるまでは、流通管理サーバ１００への（直接）登録を行うことが保留となる。
【0059】
ステップＳ８－４においては、ステップＳ８－５の処理が完了後、各種の申請書や確認書の記載内容の確認を行う。この処理は、流通管理者１４が、流通管理者端末１４０を介して流通管理サーバ１００にアクセスして所定のデータベースの内容の確認を行うことによって実行される。
なお、このステップＳ８－５において、申請書・協力確認書の保留分の登録が実行される。この処理は流通管理者１４が流通管理者端末１４０を用いて、流通管理サーバ１００中のデータベースを操作することによって実行される。この処理は、図５のＳ５－５と同様である。
なお、このステップＳ８－５において、申請書・協力確認書の保留分の登録が実行される。この処理は流通管理者１４が流通管理者端末１４０を用いて、流通管理サーバ１００中のデータベースを操作することによって実行される。この処理は、図５のＳ５－５と同様である。
【0060】
ステップＳ８－４における記載内容の確認の処理が行われた後、ステップＳ８－６において、データベースへの入力が行われる。
図８におけるＤ８－２は、申請書や協力確認書に関する流通管理ＤＢ（データベース））である。
図８におけるＤ８－２は、申請書や協力確認書に関する流通管理ＤＢ（データベース））である。
【0061】
（２）－３ ロック解除条件
なお、本実施形態における流通管理においては、納品可否判定が「不可」となり、納品が許可されていない状態をロック状態、又は単にロックと呼ぶ。
このロック状態を解除する条件は、以下の情報が全て揃っていることである。
・契約締結
・契約医師データ（責任医師）
・契約医師データ（分担医師）
・施設申請書
・医師申請書（責任医師、分担医師）
・協力確認書（薬剤部用）
・協力確認書（医師用）
ここで挙げる情報は一例であり、他の情報を利用してもよい。
製剤毎に条件は異なる。実際の運用に当たっては、製剤毎に上記情報をカスタマイズすることになる。
なお、本実施形態における流通管理においては、納品可否判定が「不可」となり、納品が許可されていない状態をロック状態、又は単にロックと呼ぶ。
このロック状態を解除する条件は、以下の情報が全て揃っていることである。
・契約締結
・契約医師データ（責任医師）
・契約医師データ（分担医師）
・施設申請書
・医師申請書（責任医師、分担医師）
・協力確認書（薬剤部用）
・協力確認書（医師用）
ここで挙げる情報は一例であり、他の情報を利用してもよい。
製剤毎に条件は異なる。実際の運用に当たっては、製剤毎に上記情報をカスタマイズすることになる。
【0062】
（３）納品連絡書１２の処理
次に、特約店１０が病院・薬局１６へ医薬品の納品を行おうとする場合の処理をフローチャートに基づき説明する。図９には、このようなフローチャートが示されている。
Ｄ９－１は、納品連絡書１２を表す。特約店１０は、流通管理サーバ１００にＤ９－１の納品連絡書１２のファイルを入力することによって、納品連絡書１２を流通管理サーバ１００に「送信」している。
次に、特約店１０が病院・薬局１６へ医薬品の納品を行おうとする場合の処理をフローチャートに基づき説明する。図９には、このようなフローチャートが示されている。
Ｄ９－１は、納品連絡書１２を表す。特約店１０は、流通管理サーバ１００にＤ９－１の納品連絡書１２のファイルを入力することによって、納品連絡書１２を流通管理サーバ１００に「送信」している。
【0063】
図１で説明したように、流通管理サーバ１００の通信部１０２は、ＷＥＢサーバ１０２ｂを備えており、外部にＷＥＢサイトを提供することができる。特約店１０の担当者は、特約店端末１３０から、流通管理サーバ１００にアクセスすることができ、上述したＷＥＢサーバ１０２ｂの提供する入力画面で納品連絡書Ｄ９－１のデータを入力することができる。この入力動作は、図２の白丸６に該当する。
次に、御御部１０４は、入力されたデータに基づき、納品連絡書１２（というコンピュータファイル）を作成し、納品連絡書データベース１０６に格納する。
次に、御御部１０４は、入力されたデータに基づき、納品連絡書１２（というコンピュータファイル）を作成し、納品連絡書データベース１０６に格納する。
【0064】
納品連絡書
本実施形態では、納品連絡書１２は、コンピュータファイルであり、例えば、発行日、特約店１０の名称、納品したい医薬品（の名称・数量）、納品先の病院・薬局１６の名称、等を含むコンピュータファイルである。この納品連絡書１２は、判定結果フラグが設けられており、判定結果を表すことができる。例えば、
「可」 ：判定結果が納品可能である。
「不可」：判定結果が納品不可である。
とすることができる。納品連絡書１２の発行（作成）時点では、判定結果フラグは「値なし」としてよい。
本実施形態では、「判定結果「フラグ」」と称しているが、そのコンピュータファイル（納品連絡書１２）に属性（可、不可、（値なし）等）を付与するものであればどのようなものでもよく、そのコンピュータファイルのヘッダ部分等に含まれていてもよい。
本実施形態では、納品連絡書１２は、コンピュータファイルであり、例えば、発行日、特約店１０の名称、納品したい医薬品（の名称・数量）、納品先の病院・薬局１６の名称、等を含むコンピュータファイルである。この納品連絡書１２は、判定結果フラグが設けられており、判定結果を表すことができる。例えば、
「可」 ：判定結果が納品可能である。
「不可」：判定結果が納品不可である。
とすることができる。納品連絡書１２の発行（作成）時点では、判定結果フラグは「値なし」としてよい。
本実施形態では、「判定結果「フラグ」」と称しているが、そのコンピュータファイル（納品連絡書１２）に属性（可、不可、（値なし）等）を付与するものであればどのようなものでもよく、そのコンピュータファイルのヘッダ部分等に含まれていてもよい。
【0065】
次に、図９のステップＳ９－１において、流通管理サーバ１００は、納品連絡書Ｄ９－１の受領書を、納品連絡書Ｄ９－１を入力した相手に送り返す。この受領書の送付は、例えば電子メールを用いてよいが、他の通信手法を採用してもよい。
ステップＳ９－２において、処方元の検索が行われる。特約店１０が納品連絡書１２の情報を流通管理サーバ１００に登録（入力）する際に、流通管理サーバ側はその医薬品の処方元を検索しており、処方元の施設情報がない場合（まだ登録されていない場合）は、流通管理サーバ１００上で、施設情報を仮に登録するように構成されている。そして、仮登録後、担当部門への問い合わせのメールが自動配信される。この配信の結果、施設情報に紐付く追加情報は、施設マスタのデータベース（ＤＢ）の更新（図２の白丸３、黒丸１１）で行われる。
ステップＳ９－２において、処方元の検索が行われる。特約店１０が納品連絡書１２の情報を流通管理サーバ１００に登録（入力）する際に、流通管理サーバ側はその医薬品の処方元を検索しており、処方元の施設情報がない場合（まだ登録されていない場合）は、流通管理サーバ１００上で、施設情報を仮に登録するように構成されている。そして、仮登録後、担当部門への問い合わせのメールが自動配信される。この配信の結果、施設情報に紐付く追加情報は、施設マスタのデータベース（ＤＢ）の更新（図２の白丸３、黒丸１１）で行われる。
【0066】
ステップＳ９－２の動作は、流通管理サーバ１００の制御部１０４が実行する。制御部１０４は、流通管理サーバ１００に入力される納品連絡書Ｄ９－１のデータを管理しており、そのデータから処方元を推定し、推定結果に基づいて検索することができる。このような制御部１０４の動作は、所定の記憶媒体に格納されたコンピュータプログラムを制御部１０４が実行することによって実現される。なお、処方元の検索の際には、流通管理ＤＢ（ロック解除）Ｄ９－２のデータベースを検索する。
ステップＳ９－３において、処方元の施設マスタ情報があるかどうかが確認される。施設マスタ情報がない場合は、ステップＳ９－６に処理が移行する。施設マスタ情報がある場合は、ステップＳ９－７に処理が移行する。
ステップＳ９－３において、処方元の施設マスタ情報があるかどうかが確認される。施設マスタ情報がない場合は、ステップＳ９－６に処理が移行する。施設マスタ情報がある場合は、ステップＳ９－７に処理が移行する。
【0067】
ステップＳ９－６において、製薬会社からの回答に従ってマスタ情報に仮登録を行う。これによって、流通管理サーバ１００に対してアクセスすることが可能となる。この仮登録は、流通管理ＤＢ（施設情報）Ｄ９－３に対して行う。この仮登録は、流通管理者１４が、流通管理者端末１４０を用いて、流通管理サーバ１００内のデータベースに仮登録を行うことによって実現される。
【0068】
ステップＳ９－７において、納品連絡書１２の登録が行われる。この処理は流通管理サーバ１００が実行する。特に制御部１０４が実行する。制御部１０４は、通信部１０２が受信した納品連絡書１２を、流通管理ＤＢ（ロック解除）Ｄ９－４に格納する。このデータベースは、図１で言えば、納品連絡書データベース１０６が該当する。
【0069】
ステップＳ９－８において、ロック解除条件が満たされているかどうかを確認する。確認の結果、ロック解除条件が満たされていれば、ステップＳ９－９に処理が移行し、満たされていない場合は、ステップＳ９－１０に処理が移行する。この確認の処理も、流通管理サーバ１００が実行する。特に制御部１０４が実行する。制御部１０４は、流通管理ＤＢ（施設情報）Ｄ９－５の内容を参照して確認作業を実行し、その結果も流通管理ＤＢ（施設情報）の内容に反映させる。流通管理ＤＢ（施設情報）Ｄ９－５は、これまで説明した流通管理ＤＢ（施設情報）Ｄ９－３と同様のものである。このデータベースは、図１で言えば、納品可否判定基準情報データベース１０８に該当する。
【0070】
ステップＳ９－９において、確認の結果が「可」だったので、納品連絡書１２の判定フラグを「可」に設定する。この処理は制御部１０４が実行する。
さらに、制御部１０４は、納品「可」の納品連絡書１２を特約店１０（の特約店端末１３０）及びＭＲ１８（のＭＲ端末１５０）に送信する。この送信は、制御部１０４が、通信部１０２を介して実行する。
本実施形態では、例えば、ＷＥＢ画面上で「可」のフラグが設定された納品連絡書１２を表示することによって各相手方に画面上で確認してもらう方法を採用してもよい。ＷＥＢ画面の表示はもっと簡単にしてもよい。例えば、単に納品連絡書１２の番号と、「納品可」や単に「可」の表示を行って「送信」をしてもよい。
また、当該「送信」は、メールで、「可」のフラグが設定された納品連絡書１２を特約店１０とＭＲ１８に送信してもよい。このような手法でも、納品可の納品連絡書１２の「送信」の一例に該当する。なお、この動作は、図２の白丸７に該当する。
さらに、具体的な納品「可」の対応をするべくステップＳ９－１１に移行する。この納品「可」の対応は、具体的には、図１０のフローチャートに示されている。
さらに、制御部１０４は、納品「可」の納品連絡書１２を特約店１０（の特約店端末１３０）及びＭＲ１８（のＭＲ端末１５０）に送信する。この送信は、制御部１０４が、通信部１０２を介して実行する。
本実施形態では、例えば、ＷＥＢ画面上で「可」のフラグが設定された納品連絡書１２を表示することによって各相手方に画面上で確認してもらう方法を採用してもよい。ＷＥＢ画面の表示はもっと簡単にしてもよい。例えば、単に納品連絡書１２の番号と、「納品可」や単に「可」の表示を行って「送信」をしてもよい。
また、当該「送信」は、メールで、「可」のフラグが設定された納品連絡書１２を特約店１０とＭＲ１８に送信してもよい。このような手法でも、納品可の納品連絡書１２の「送信」の一例に該当する。なお、この動作は、図２の白丸７に該当する。
さらに、具体的な納品「可」の対応をするべくステップＳ９－１１に移行する。この納品「可」の対応は、具体的には、図１０のフローチャートに示されている。
【0071】
ステップＳ９－１０において、確認の結果が「不可」だったので、納品「不可」の通知を特約店１０（の特約店端末１３０）及びＭＲ１８（のＭＲ端末１５０）に送信する。この送信は、制御部１０４が、通信部１０２を介して実行する。
本実施形態では、ＷＥＢ画面上で「不可」のフラグが設定された納品連絡書１２を表示することによって各相手方に画面上で確認してもらう方法を採用してもよい。なお、ＷＥＢ画面上で単に納品連絡書１２の番号と、「納品不可」又は単に「不可」の表示をして、各相手方に画面上で確認してもらってもよい。
また、メールで「不可」の判定結果フラグが設定された納品連絡書１２を特約店１０とＭＲ１８に送信してもよい。このような手法でも、納品不可の納品連絡書１２の「送信」の一例に該当する。なお、この動作は、図２の白丸７に該当する。
さらに、具体的な納品「不可」の対応をするべくステップＳ９－１２に移行する。この納品「不可」の対応は、具体的には、図１１のフローチャートに示されている。
本実施形態では、ＷＥＢ画面上で「不可」のフラグが設定された納品連絡書１２を表示することによって各相手方に画面上で確認してもらう方法を採用してもよい。なお、ＷＥＢ画面上で単に納品連絡書１２の番号と、「納品不可」又は単に「不可」の表示をして、各相手方に画面上で確認してもらってもよい。
また、メールで「不可」の判定結果フラグが設定された納品連絡書１２を特約店１０とＭＲ１８に送信してもよい。このような手法でも、納品不可の納品連絡書１２の「送信」の一例に該当する。なお、この動作は、図２の白丸７に該当する。
さらに、具体的な納品「不可」の対応をするべくステップＳ９－１２に移行する。この納品「不可」の対応は、具体的には、図１１のフローチャートに示されている。
【0072】
（４）納品「可」の対応
納品「可」の対応の動作を表すフローチャートが、図１０に示されている。
ステップＳ１０－１において、納品「可」の対応の処理が開始される。
ステップＳ１０－２において、流通管理サーバ１００は、ＷＥＢ上で流通管理画面を表示する。これは、制御部１０４が、通信部１０２内のＷＥＢサーバ１０２ｂを操作し所望の内容を表示させることによって実現される。
その画面では、判定結果フラグが「可」である納品連絡書１２の内容が表示されている。これによって、特約店１０や、ＭＲ１８は、納品連絡書１２が肯定され、納品「可」となったことを知ることができる。この表示は、特約店端末１３０，ＭＲ端末１５０等の上で閲覧することができる。
納品「可」の対応の動作を表すフローチャートが、図１０に示されている。
ステップＳ１０－１において、納品「可」の対応の処理が開始される。
ステップＳ１０－２において、流通管理サーバ１００は、ＷＥＢ上で流通管理画面を表示する。これは、制御部１０４が、通信部１０２内のＷＥＢサーバ１０２ｂを操作し所望の内容を表示させることによって実現される。
その画面では、判定結果フラグが「可」である納品連絡書１２の内容が表示されている。これによって、特約店１０や、ＭＲ１８は、納品連絡書１２が肯定され、納品「可」となったことを知ることができる。この表示は、特約店端末１３０，ＭＲ端末１５０等の上で閲覧することができる。
【0073】
ステップＳ１０－３において、特約店１０から、病院・薬局１６へその医薬品の納品が行われる。これは特約店１０が行い、従来と同様の方法で行われる。
ステップＳ１０－４において、「可」納品連絡書１２が、自動メール送付される。なお、本実施形態では、「可」納品連絡書１２とは、判定結果フラグが「可」の納品連絡書１２を表す。
これは流通管理サーバ１００の制御部１０４が実行する。この自動メールは、ＭＲ１８のＭＲ端末１５０に送られる。またこの自動メールは、クライアント（製薬会社）の担当の個人アドレスへ送られる。また、この自動メールは、特約店１０の特約店端末１３０に送られる。
この自動メールは、ＭＲ１８（のＭＲ端末１５０）向けをＤ１０－１、クライアント（製薬会社）の担当の個人アドレス向けをＤ１０－２、特約店１０（の特約店端末１３０）向けをＤ１０－３と名付けているが、いずれも同様の内容である。
ステップＳ１０－５において、ステップＳ１０－４で送付したものと同様のＤ１０－４で示される「可」納品連絡書１２が、別途保管される。この処理は、制御部１０４が、判定結果フラグが「可」となった「可」納品連絡書１２を、納品連絡書データベース１０６中に記憶させることによって実行される。
ステップＳ１０－４において、「可」納品連絡書１２が、自動メール送付される。なお、本実施形態では、「可」納品連絡書１２とは、判定結果フラグが「可」の納品連絡書１２を表す。
これは流通管理サーバ１００の制御部１０４が実行する。この自動メールは、ＭＲ１８のＭＲ端末１５０に送られる。またこの自動メールは、クライアント（製薬会社）の担当の個人アドレスへ送られる。また、この自動メールは、特約店１０の特約店端末１３０に送られる。
この自動メールは、ＭＲ１８（のＭＲ端末１５０）向けをＤ１０－１、クライアント（製薬会社）の担当の個人アドレス向けをＤ１０－２、特約店１０（の特約店端末１３０）向けをＤ１０－３と名付けているが、いずれも同様の内容である。
ステップＳ１０－５において、ステップＳ１０－４で送付したものと同様のＤ１０－４で示される「可」納品連絡書１２が、別途保管される。この処理は、制御部１０４が、判定結果フラグが「可」となった「可」納品連絡書１２を、納品連絡書データベース１０６中に記憶させることによって実行される。
【0074】
（５）納品「不可」の対応
納品「不可」の対応の動作を表すフローチャートが、図１１に示されている。
ステップＳ１１－１において、納品「不可」の対応の処理が開始される。
ステップＳ１１－２において、流通管理サーバ１００は、ＷＥＢ上で流通管理画面を表示する。これは、制御部１０４が、通信部１０２内のＷＥＢサーバ１０２ｂを操作し所望の内容を表示させることによって実現される。
その画面では、判定結果フラグが「不可」である納品連絡書１２の内容が表示されている。これによって、特約店１０や、ＭＲ１８は、納品連絡書１２が拒否され、納品「不可」となったことを知ることができる。この表示は、特約店端末１３０、ＭＲ端末１５０等の上で閲覧することができる。判定結果フラグが「不可」である納品連絡書１２を「不可」納品連絡書１２と呼ぶ。
上記画面では、判定結果フラグが「不可」である納品連絡書１２が表示される。例えば、その納品連絡書１２に係る医薬品名称や、納品先である病院・薬局１６の名称等が表示されることが好ましい。さらに、「不可」となった要因、すなわちロック解除のために満たすべきであった情報の中で、満たされなかった（欠落した）情報を、表示することが好ましい。このように、「不可」となった要因（情報の欠落）を表示することによって、ＭＲ１８は、その要因に対して速やかに対処することができる。
例えば、所定の契約書が揃っていなかった場合、ＭＲ１８は、当該契約書を携えて病院・薬局１６に聴取に行き、契約書を交わすことができる。また、聴取の結果、契約書は交わしているが、流通管理サーバ１００内のデータベース（納品可否判定基準データベース１０８）に登録されていなかったことが判明する場合もある。その場合は、ＭＲ１８は、その契約書を、流通管理サーバ１００内の納品可否判定基準データベース１０８に登録することができる。
このように、「不可」となった要因となる情報を画面に表示することによって、ＭＲ１８は種々の対応を速やかに実行することができる。
納品「不可」の対応の動作を表すフローチャートが、図１１に示されている。
ステップＳ１１－１において、納品「不可」の対応の処理が開始される。
ステップＳ１１－２において、流通管理サーバ１００は、ＷＥＢ上で流通管理画面を表示する。これは、制御部１０４が、通信部１０２内のＷＥＢサーバ１０２ｂを操作し所望の内容を表示させることによって実現される。
その画面では、判定結果フラグが「不可」である納品連絡書１２の内容が表示されている。これによって、特約店１０や、ＭＲ１８は、納品連絡書１２が拒否され、納品「不可」となったことを知ることができる。この表示は、特約店端末１３０、ＭＲ端末１５０等の上で閲覧することができる。判定結果フラグが「不可」である納品連絡書１２を「不可」納品連絡書１２と呼ぶ。
上記画面では、判定結果フラグが「不可」である納品連絡書１２が表示される。例えば、その納品連絡書１２に係る医薬品名称や、納品先である病院・薬局１６の名称等が表示されることが好ましい。さらに、「不可」となった要因、すなわちロック解除のために満たすべきであった情報の中で、満たされなかった（欠落した）情報を、表示することが好ましい。このように、「不可」となった要因（情報の欠落）を表示することによって、ＭＲ１８は、その要因に対して速やかに対処することができる。
例えば、所定の契約書が揃っていなかった場合、ＭＲ１８は、当該契約書を携えて病院・薬局１６に聴取に行き、契約書を交わすことができる。また、聴取の結果、契約書は交わしているが、流通管理サーバ１００内のデータベース（納品可否判定基準データベース１０８）に登録されていなかったことが判明する場合もある。その場合は、ＭＲ１８は、その契約書を、流通管理サーバ１００内の納品可否判定基準データベース１０８に登録することができる。
このように、「不可」となった要因となる情報を画面に表示することによって、ＭＲ１８は種々の対応を速やかに実行することができる。
【0075】
ステップＳ１１－４において、「不可」納品連絡書１２が、自動メール送付される。これは流通管理サーバ１００の制御部１０４が実行する。この自動メールは、ＭＲ１８のＭＲ端末１５０に送られる。またこの自動メールは、クライアント（製薬会社）の担当の個人アドレスへ送られる。また、この自動メールは、特約店１０の特約店端末１３０に送られる。
この自動メールは、ＭＲ１８（のＭＲ端末１５０）向けをＤ１１－１、クライアント（製薬会社）の担当の個人アドレス向けをＤ１１－２、特約店１０（の特約店端末１３０）向けをＤ１１－３と名付けているが、いずれも同様の内容である。
このような自動メールの送付により、ＭＲ１８は、図２における黒丸９や、黒丸１０の働きを開始することができ、「不可」納品連絡書１２を再度の審査で「可」とすることができる場合もある。
ステップＳ１１－５において、ステップＳ１１－４で送付したものと同様の「不可」納品連絡書Ｄ１１－４が、別途保留扱いとなり、一時保管されている。この処理は、制御部１０４が、「不可」納品連絡書１２を、納品連絡書データベース１０６中に保管しておくことにおより行われる。
この自動メールは、ＭＲ１８（のＭＲ端末１５０）向けをＤ１１－１、クライアント（製薬会社）の担当の個人アドレス向けをＤ１１－２、特約店１０（の特約店端末１３０）向けをＤ１１－３と名付けているが、いずれも同様の内容である。
このような自動メールの送付により、ＭＲ１８は、図２における黒丸９や、黒丸１０の働きを開始することができ、「不可」納品連絡書１２を再度の審査で「可」とすることができる場合もある。
ステップＳ１１－５において、ステップＳ１１－４で送付したものと同様の「不可」納品連絡書Ｄ１１－４が、別途保留扱いとなり、一時保管されている。この処理は、制御部１０４が、「不可」納品連絡書１２を、納品連絡書データベース１０６中に保管しておくことにおより行われる。
【0076】
保留扱い・一時保管の意義
保留扱い連絡書データベース１０６中の「不可」納品連絡書１２は、基本的に全て一時保管と考えてよく、基本的には一時保管のための別の特別な場所を用意する必要はない。制御部１０４は、納品連絡書データベース１０６中を、種々の条件で検索することができ、判定結果フラグが「不可」の納品連絡書１２のみを抽出すれば、一時保管の納品連絡書１２を取り出すことは容易である。
しかし、データが膨大になる場合や、古いデータを日時によって適宜整理する必要性、等から一時保管のための場所を準備して、そこに一時保管することも好適である。
保留扱い連絡書データベース１０６中の「不可」納品連絡書１２は、基本的に全て一時保管と考えてよく、基本的には一時保管のための別の特別な場所を用意する必要はない。制御部１０４は、納品連絡書データベース１０６中を、種々の条件で検索することができ、判定結果フラグが「不可」の納品連絡書１２のみを抽出すれば、一時保管の納品連絡書１２を取り出すことは容易である。
しかし、データが膨大になる場合や、古いデータを日時によって適宜整理する必要性、等から一時保管のための場所を準備して、そこに一時保管することも好適である。
【0077】
（６）ロック解除
次に、一旦、判定が「不可」となった「不可」納品連絡書１２が、納品可否判定基準情報を更新することによって、判定が「可」となる場合の動作について図６～図１２のフローチャートに基づき説明する。
まず、既に説明した図５のフローチャートのステップＳ５－１においてデータベースが更新されると、それに伴い納品可否判定も影響を受ける可能性がある。図５の矢印Ｂは、図６に接続している。
次に、一旦、判定が「不可」となった「不可」納品連絡書１２が、納品可否判定基準情報を更新することによって、判定が「可」となる場合の動作について図６～図１２のフローチャートに基づき説明する。
まず、既に説明した図５のフローチャートのステップＳ５－１においてデータベースが更新されると、それに伴い納品可否判定も影響を受ける可能性がある。図５の矢印Ｂは、図６に接続している。
【0078】
そこで、図６に示されたフローチャートから説明を行う。
図６のステップＳ６－１において、契約情報確認と、責任医師確認と、が行われる。これらの処理は流通管理者１４が実行してよい。ここで、契約情報確認とは、契約締結済みであることを確認することをいう。期間満了の場合は、更新手続開始済みであることを確認する。また、責任医師確認とは、責任医師が、契約データに記載がある責任医師であることを確認することをいう。
図６のステップＳ６－１において、契約情報確認と、責任医師確認と、が行われる。これらの処理は流通管理者１４が実行してよい。ここで、契約情報確認とは、契約締結済みであることを確認することをいう。期間満了の場合は、更新手続開始済みであることを確認する。また、責任医師確認とは、責任医師が、契約データに記載がある責任医師であることを確認することをいう。
【0079】
ステップＳ６－２において、契約の締結と、責任医師の存在とが確認される。特に、契約情報がインポートされ、インポート前後で比較したときに、契約情報が「無」のものが「有」になった場合のみ、納品不可→可の確認を流通管理サーバ１００が実行する。具体的には、制御部１０４が係る判断を行う。変化がなかった場合は、ステップＳ６－３において、何もしない。一方、無から有に変化した場合は、ステップＳ６－４において、不可 → 可に変更が可能な否か確認される。これらの処理は、制御部１０４が行ってよい。 ステップＳ６－５において、不可／保留分の納品連絡書１２の確認が行われる。これは流通管理ＤＢ（データベース）Ｄ６－１を用いて行われる。この確認処理は、制御部１０４が行ってよい。
【0080】
次にステップＳ６－７において、「不可」と判断された「不可」納品連絡書１２が保留分として一時保管されているかどうか判断される。この判断も制御部１０４が行ってよい。また、これを判断するために、「不可」納品連絡書１２の保留分一時保管処理を用いて調べる（ステップＳ６－６参照）。なお、この動作は、上述のように、制御部１０４が判定した結果フラグが「不可」のデータを検索することにより行うことができる。
この判断の結果、一時保管されていない場合は、ステップＳ６－８に移行し、特に何もしない。また、この判断の結果、保留分が一時保管されていた場合は、ステップＳ６－９に処理が移行する。
この判断の結果、一時保管されていない場合は、ステップＳ６－８に移行し、特に何もしない。また、この判断の結果、保留分が一時保管されていた場合は、ステップＳ６－９に処理が移行する。
【0081】
ステップＳ６－９においては、いわゆるロックが解除される。すなわち納品連絡書が「不可」から「可」に変わることを意味する。この処理は、制御部１０４が、納品連絡書データベース１０６中に一時保管されている納品連絡書１２が存在した場合に、その納品連絡書１２の判定結果フラグを「不可」から「可」に書き換えることで行ってよい。
【0082】
図６の処理の後、図１２のフローチャートに移行する。図１２のフローチャートでは、ロック解除「不可」→「可」への処理の詳細が記されている。
まず、ステップＳ１２－１から、「不可」を「可」に変更する処理を開始する。
ステップＳ１２－２において、制御部１０４は、「不可」納品連絡書１２を、納品連絡書データベース１０６から抽出する。
ステップＳ１２－３において、制御部１０４は、「不可」納品連絡書１２の判定結果フラグを「不可」から「可」に書き換える。これによって、ロック解除がなされる。なお、納品連絡書１２は、Ｄ１２－１で示される流通管理ＤＢ（ロック解除）中に記憶されているので、その中の「不可」納品連絡書１２を取り出して、「可」納品連絡書１２に書き換えている。このＤ１２－１で示される流通管理ＤＢ（ロック解除）は、図１における納品連絡書データベース１０６に相当する。
まず、ステップＳ１２－１から、「不可」を「可」に変更する処理を開始する。
ステップＳ１２－２において、制御部１０４は、「不可」納品連絡書１２を、納品連絡書データベース１０６から抽出する。
ステップＳ１２－３において、制御部１０４は、「不可」納品連絡書１２の判定結果フラグを「不可」から「可」に書き換える。これによって、ロック解除がなされる。なお、納品連絡書１２は、Ｄ１２－１で示される流通管理ＤＢ（ロック解除）中に記憶されているので、その中の「不可」納品連絡書１２を取り出して、「可」納品連絡書１２に書き換えている。このＤ１２－１で示される流通管理ＤＢ（ロック解除）は、図１における納品連絡書データベース１０６に相当する。
【0083】
ステップＳ１２－４において、制御部１０４は、判定結果フラグを書き換えた納品連絡書１２を、Ｄ１２－２で示される流通管理ＤＢ（ロック解除）に登録する。これは、納品連絡書１２をＤ１２－２で示される流通管理ＤＢ（ロック解除）に記憶させることを意味する。
ステップＳ１２－５において、制御部１０４は、上記登録の後、その新しく「可」納品連絡書１２となった納品連絡書１２の内容を、流通管理画面を流通管理者端末１４０上で表示する。これはロック解除が行われたことを、流通管理者に報告するためである。
ステップＳ１２－６において、新しくロック解除した後の「可」納品連絡書１２をコンピュータファイルとして流通管理ＤＢ（ロック解除）から取り出す。
ステップＳ１２－５において、制御部１０４は、上記登録の後、その新しく「可」納品連絡書１２となった納品連絡書１２の内容を、流通管理画面を流通管理者端末１４０上で表示する。これはロック解除が行われたことを、流通管理者に報告するためである。
ステップＳ１２－６において、新しくロック解除した後の「可」納品連絡書１２をコンピュータファイルとして流通管理ＤＢ（ロック解除）から取り出す。
【0084】
ステップＳ１２－７において、制御部１０４は、上のステップＳ１２－６で取り出した「可」納品連絡書１２を、自動メールによってＭＲ１８等に送付する。この自動メールには、ステップＳ１２－６で取り出した「可」納品連絡書１２が添付される。制御部１０４は、このようにして作成した自動メールを、通信部１０２を介して、ＭＲ１８等に送付する。
図１２に示すように、「可」納品連絡書１２が自動メールで特約店１０に送られる。制御部１０４が、当該自動メールを作成し、通信部１０２に送る。通信部１０２はその自動メールの宛先に自動的にメールを送信する。図１２では、送信された自動メールがＤ１２－６で示されている。
また、「可」納品連絡書１２は、同様に自動メールでＭＲ１８（のＭＲ端末１５０）に送ってよい。この送信も、特約店１０向けと同様に制御部１０４、通信部１０２が実行する。図１２では、送信された自動メールがＤ１２－５で示されている。
また、「可」納品連絡書１２は、同様に自動メールで製薬会社本社担当者の個人アドレスに送ってよい。この送信も、特約店１０向けと同様に制御部１０４、通信部１０２が実行する。図１２では、送信された自動メールがＤ１２－４で示されている。
ステップＳ１２－８において、制御部１０４は、「可」納品連絡書１２を納品連絡書データベース１０６に保管する。
図１２に示すように、「可」納品連絡書１２が自動メールで特約店１０に送られる。制御部１０４が、当該自動メールを作成し、通信部１０２に送る。通信部１０２はその自動メールの宛先に自動的にメールを送信する。図１２では、送信された自動メールがＤ１２－６で示されている。
また、「可」納品連絡書１２は、同様に自動メールでＭＲ１８（のＭＲ端末１５０）に送ってよい。この送信も、特約店１０向けと同様に制御部１０４、通信部１０２が実行する。図１２では、送信された自動メールがＤ１２－５で示されている。
また、「可」納品連絡書１２は、同様に自動メールで製薬会社本社担当者の個人アドレスに送ってよい。この送信も、特約店１０向けと同様に制御部１０４、通信部１０２が実行する。図１２では、送信された自動メールがＤ１２－４で示されている。
ステップＳ１２－８において、制御部１０４は、「可」納品連絡書１２を納品連絡書データベース１０６に保管する。
【0085】
以上のようにして、一旦「不可」と判断された納品連絡書１２でも、納品可否判定基準情報の更新により、「可」とすることができ、利便性の向上した医薬品の納品許可を行うことができる。
【0086】
（７）データファイル出力
本実施形態の流通管理サーバ１００は、日々の流通管理業務の結果として、所定の頻度で規定のデータファイル出力を実行する。所定の頻度とは、１日１回でもよいし、週に１回でもよく、月に１回でもよく、自由に周期を定めてよい。また、実施しない業務は、頻度「０」と設定してよく、この頻度を「０」に設定した場合、「製薬会社の指定する頻度・出力仕様でデータファイルの出力を実行する」ことにしてよい。
このデータファイルは、許可された納品連絡書１２の一覧であることが好ましいが、他の種類のデータが含まれていてもよい。例えば、納品連絡書１２の番号、発行日付、許可日付、特約店１０の名称、医薬品の名称及び数量、納品先の病院・薬局１６、等が含まれてよい。許可された納品連絡書１２を抽出するので、許可日付は必須項目とすることが好ましいが、その他の項目は必要に応じて設ければよい。このデータファイル出力の様子が図１３に示されている。
この図に示すように、流通管理サーバ１００（の制御部１０４）は、Ｄ１３－２で表される流通管理データベースから許可となった（「可」）納品連絡書１２を抽出し、その値を例えば表としてデータファイルを作成する。作成したデータファイルが、Ｄ１３－２で表されるロック解除データである。このファイルは自動メールやファイル共有等でクライアントＤＢに送信される。このデータを便宜上Ｄ１３－１と呼ぶが、ロック解除データである。なお、Ｄ１３－３で表される流通管理データベースは、図１における納品連絡書データベース１０６を含むデータベースである。
本実施形態の流通管理サーバ１００は、日々の流通管理業務の結果として、所定の頻度で規定のデータファイル出力を実行する。所定の頻度とは、１日１回でもよいし、週に１回でもよく、月に１回でもよく、自由に周期を定めてよい。また、実施しない業務は、頻度「０」と設定してよく、この頻度を「０」に設定した場合、「製薬会社の指定する頻度・出力仕様でデータファイルの出力を実行する」ことにしてよい。
このデータファイルは、許可された納品連絡書１２の一覧であることが好ましいが、他の種類のデータが含まれていてもよい。例えば、納品連絡書１２の番号、発行日付、許可日付、特約店１０の名称、医薬品の名称及び数量、納品先の病院・薬局１６、等が含まれてよい。許可された納品連絡書１２を抽出するので、許可日付は必須項目とすることが好ましいが、その他の項目は必要に応じて設ければよい。このデータファイル出力の様子が図１３に示されている。
この図に示すように、流通管理サーバ１００（の制御部１０４）は、Ｄ１３－２で表される流通管理データベースから許可となった（「可」）納品連絡書１２を抽出し、その値を例えば表としてデータファイルを作成する。作成したデータファイルが、Ｄ１３－２で表されるロック解除データである。このファイルは自動メールやファイル共有等でクライアントＤＢに送信される。このデータを便宜上Ｄ１３－１と呼ぶが、ロック解除データである。なお、Ｄ１３－３で表される流通管理データベースは、図１における納品連絡書データベース１０６を含むデータベースである。
【0087】
（８）本実施形態の全体的な効果
以上、本実施形態の構成・動作を説明してきたが、その全体的な効果を概観した図が図１４に示されている。この図に示すように、特約店１０は、流通管理システム９０の流通管理サーバにアクセスし、流通管理サーバ１００に納品連絡書１２を送信する（入力する）。すると、流通管理サーバ１００の制御部１０４は、その内部の納品可否判定基準情報データベース１０８等を参照しながら判定を行う。そして、判定の結果を特約店に送信する（画面上で表示）する。特約店１０は、迅速に医薬品を病院・薬局１６に納品することができる。
そのため、流通管理システム９０システム上で納品して良いか否かの判定結果が自動で出るため、人件費と手間を削減することができる。また、流通管理者１４を介さず、病院・薬局１６に納品可否結果がスピーディに分かる為、迅速な納品へ貢献できる。
以上、本実施形態の構成・動作を説明してきたが、その全体的な効果を概観した図が図１４に示されている。この図に示すように、特約店１０は、流通管理システム９０の流通管理サーバにアクセスし、流通管理サーバ１００に納品連絡書１２を送信する（入力する）。すると、流通管理サーバ１００の制御部１０４は、その内部の納品可否判定基準情報データベース１０８等を参照しながら判定を行う。そして、判定の結果を特約店に送信する（画面上で表示）する。特約店１０は、迅速に医薬品を病院・薬局１６に納品することができる。
そのため、流通管理システム９０システム上で納品して良いか否かの判定結果が自動で出るため、人件費と手間を削減することができる。また、流通管理者１４を介さず、病院・薬局１６に納品可否結果がスピーディに分かる為、迅速な納品へ貢献できる。
【0088】
（９）本実施形態における特徴的な技術事項である再判定についての効果
ここで、本実施形態の「再判定」の特徴的な効果と運用上の工夫等を説明する。
（９ａ）納品連絡書１２の再判定
従来用いられていたシステムでは、納品連絡書１２について「不可」の判定が出された場合は、その判定結果は、特約店１０だけでなく、ＭＲ１８にも通知される（画面表示される）ので、ＭＲ１８がすぐに、判定基準を整えるための聴取等を実行することができる。その結果、可否判定基準を満たすための対応処理が迅速に行え、その結果、「不可」となった納品判定書１２が「可」となる為の対応が取りやすい。
ここで、本実施形態の「再判定」の特徴的な効果と運用上の工夫等を説明する。
（９ａ）納品連絡書１２の再判定
従来用いられていたシステムでは、納品連絡書１２について「不可」の判定が出された場合は、その判定結果は、特約店１０だけでなく、ＭＲ１８にも通知される（画面表示される）ので、ＭＲ１８がすぐに、判定基準を整えるための聴取等を実行することができる。その結果、可否判定基準を満たすための対応処理が迅速に行え、その結果、「不可」となった納品判定書１２が「可」となる為の対応が取りやすい。
【0089】
そこで、上述したように、「不可」納品判定書１２をそのまま保存して、その後、納品可否判定基準情報が更新された場合に、流通管理サーバ１００が自動的にその都度（更新される度に）再判定を実行している。その結果、「不可」→「可」となるものがあれば、速やかに「可」とすることができ、迅速な納品連絡書１２の処理を行うことができる。
【0090】
（９ｂ）時期的制限（運用上の工夫）
上述した実施形態では、いわば再判定のための特段時期的・時間的制限はないが、医薬品によってはある程度時間が経過すると再判定を行う意義が小さくなる医薬品も存在する。そこで、納品連絡書１２の項目に、有効期限を設けておくことも好ましい。そして、制御部１０４が、納品連絡書データベース１０６から納品連絡書１２を抽出する際に、「不可」の納品連絡書１２であって、且つ、有効期限が経過していないものを抽出するように構成することも好適である。
上述したように、納品連絡書１２はコンピュータファイルであり、その内容として上述したように発行日付等が含まれているが、それらに加えて有効期限を設けることは容易である。有効期限はどのように定めてもよい。３日でも１年でも自由に定めてよい。特約店１０が納品連絡書１２を作成する時に定めてもよいし、医薬品の種別から自動的に設定されるようにしてもよい。また、他者が後日、医薬品の種別・特性等から有効期限を定めてもよい。
上述した実施形態では、いわば再判定のための特段時期的・時間的制限はないが、医薬品によってはある程度時間が経過すると再判定を行う意義が小さくなる医薬品も存在する。そこで、納品連絡書１２の項目に、有効期限を設けておくことも好ましい。そして、制御部１０４が、納品連絡書データベース１０６から納品連絡書１２を抽出する際に、「不可」の納品連絡書１２であって、且つ、有効期限が経過していないものを抽出するように構成することも好適である。
上述したように、納品連絡書１２はコンピュータファイルであり、その内容として上述したように発行日付等が含まれているが、それらに加えて有効期限を設けることは容易である。有効期限はどのように定めてもよい。３日でも１年でも自由に定めてよい。特約店１０が納品連絡書１２を作成する時に定めてもよいし、医薬品の種別から自動的に設定されるようにしてもよい。また、他者が後日、医薬品の種別・特性等から有効期限を定めてもよい。
【0091】
Ｅ．変形例
（１）上述した実施形態では、ＭＲ１８から流通管理サーバ１００中の納品可否判定基準情報データベース１０８等に、直接納品可否判定基準情報を入力するルートと、クライアントＤＢ１６０に入力するルートの２種のルートがあると説明した。ＭＲ１８の好みによりいずれかのルートを選べるように構成してよい。
しかし、本流通管理サーバ１００を中心とする流通管理システム９０の運用開始当初は、ＭＲ１８はまだ流通管理サーバ１００への入力に慣れていない可能性も高い。そのため、運用開始当初は、従前通り、クライアントＤＢ１６０に納品可否判定基準情報を入力するような運用を行うことも好適である。その上で、アクセス権限が整いＭＲ１８が流通管理サーバ１００への入力を習得した後は、ＭＲ１８は流通管理サーバ１００への入力に（ルートを）切り替えるように構成することも好適である。
（１）上述した実施形態では、ＭＲ１８から流通管理サーバ１００中の納品可否判定基準情報データベース１０８等に、直接納品可否判定基準情報を入力するルートと、クライアントＤＢ１６０に入力するルートの２種のルートがあると説明した。ＭＲ１８の好みによりいずれかのルートを選べるように構成してよい。
しかし、本流通管理サーバ１００を中心とする流通管理システム９０の運用開始当初は、ＭＲ１８はまだ流通管理サーバ１００への入力に慣れていない可能性も高い。そのため、運用開始当初は、従前通り、クライアントＤＢ１６０に納品可否判定基準情報を入力するような運用を行うことも好適である。その上で、アクセス権限が整いＭＲ１８が流通管理サーバ１００への入力を習得した後は、ＭＲ１８は流通管理サーバ１００への入力に（ルートを）切り替えるように構成することも好適である。
【0092】
（２）上述した実施形態では、（１）で説明したように、ＭＲ１８は流通管理サーバ１００中の種々のデータベースに、納品可否判定基準情報を入力することができる。このルートを採用する場合、流通管理サーバ１００内の各種データベースと、クライアントＤＢ１６０との内容をファイル共有やファイル同期等の技術を用いて接続しておくことも好適である。
このように構成すれば、ＭＲ１８が流通管理サーバ１００へ入力した納品可否判定基準情報を、自動的にクライアントＤＢに反映させることができ、製薬会社（クライアントＤＢの「クライアント」）にとって最新のデータを容易に取得できるので便利である。また、ＭＲ１８にとって、一度の入力で、２種のデータベースにデータを入力することができるので、入力の手間を減らすことができ便利である。
このように構成すれば、ＭＲ１８が流通管理サーバ１００へ入力した納品可否判定基準情報を、自動的にクライアントＤＢに反映させることができ、製薬会社（クライアントＤＢの「クライアント」）にとって最新のデータを容易に取得できるので便利である。また、ＭＲ１８にとって、一度の入力で、２種のデータベースにデータを入力することができるので、入力の手間を減らすことができ便利である。
【0093】
Ｆ．まとめ（実施形態全体）
以上、本発明の実施形態について詳細に説明したが、前述した実施形態は、本発明を実施するにあたっての具体例を示したに過ぎない。本発明の技術的範囲は、上記実施形態に限定されるものではない。本発明は、その趣旨を逸脱しない範囲において種々の変更が可能であり、それらも本発明の技術的範囲に含まれる。
以上、本発明の実施形態について詳細に説明したが、前述した実施形態は、本発明を実施するにあたっての具体例を示したに過ぎない。本発明の技術的範囲は、上記実施形態に限定されるものではない。本発明は、その趣旨を逸脱しない範囲において種々の変更が可能であり、それらも本発明の技術的範囲に含まれる。
【符号の説明】
【0094】
１０ 特約店
１２ 納品連絡書
１４ 流通管理者
１６ 病院・薬局
１８、１８ａ、１８ｂ ＭＲ
９０ 流通管理システム
１００ 流通管理サーバ
１０２ 通信部
１０２ｂ ＷＥＢサーバ
１０４ 制御部
１０６、１０６ａ、１０６ｂ 納品連絡書データベ－ス
１０８ 納品可否判定基準情報データベース
１１０ 各種情報データベース
１１２、１１２ａ、１１２ｂ 管理マスタ
１１４ａ、１１４ｂ 納品可否判定基準情報及び各種情報データベース
１１６ 内部通信路
１２０ 通信路
１３０ 特約店端末
１４０ 流通管理者端末
１５０ ＭＲ端末
１８０ａ、１８０ｂ 本社担当者
１２ 納品連絡書
１４ 流通管理者
１６ 病院・薬局
１８、１８ａ、１８ｂ ＭＲ
９０ 流通管理システム
１００ 流通管理サーバ
１０２ 通信部
１０２ｂ ＷＥＢサーバ
１０４ 制御部
１０６、１０６ａ、１０６ｂ 納品連絡書データベ－ス
１０８ 納品可否判定基準情報データベース
１１０ 各種情報データベース
１１２、１１２ａ、１１２ｂ 管理マスタ
１１４ａ、１１４ｂ 納品可否判定基準情報及び各種情報データベース
１１６ 内部通信路
１２０ 通信路
１３０ 特約店端末
１４０ 流通管理者端末
１５０ ＭＲ端末
１８０ａ、１８０ｂ 本社担当者
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【手続補正書】
【提出日】2024-01-24
【手続補正1】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【0006】
一方、納品不可の場合は、上述した白丸３において、流通管理者１４は、納品可否判定（不可）の連絡をＦＡＸで特約店１０に送信する。この連絡を受領した特約店１０は、その時点では、納品を行うことはできない。この場合、黒丸１において、流通管理者１４は、納品可否判定基準情報の聴取依頼をＭＲ１８に対して送信する。
黒丸２において、上記依頼を受信したＭＲ１８は、納品可否判定基準情報の聴取を病院・薬局１６に対して行う。そして、黒丸３において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判定基準情報）を流通管理者１４に送信する。
黒丸４において、流通管理者１４は、ＭＲ１８から入手した新たな情報に基づき判断を行い、新たな納品可否判定（納品不可→可能）の連絡をＦＡＸで特約店１０に送信する。
この連絡を受領した特約店１０は、黒丸５において、納品を行う。従来の流通管理業務は、このように行われている。
黒丸２において、上記依頼を受信したＭＲ１８は、納品可否判定基準情報の聴取を病院・薬局１６に対して行う。そして、黒丸３において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判定基準情報）を流通管理者１４に送信する。
黒丸４において、流通管理者１４は、ＭＲ１８から入手した新たな情報に基づき判断を行い、新たな納品可否判定（納品不可→可能）の連絡をＦＡＸで特約店１０に送信する。
この連絡を受領した特約店１０は、黒丸５において、納品を行う。従来の流通管理業務は、このように行われている。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【0010】
このように、従来の流通管理業務は、人件費や作業量が膨大なものとなりがちであった。また、医薬品の納品可否判定が遅れて、病院・薬局１６への納品も時間がかかる場合もあった。
本発明は係る課題に鑑みなされたものであり、その目的は、流通管理業務における作業量を低減し、さらに、より迅速な医薬品の納品可否判定を行うことができるシステムを提供することである。
本発明は係る課題に鑑みなされたものであり、その目的は、流通管理業務における作業量を低減し、さらに、より迅速な医薬品の納品可否判定を行うことができるシステムを提供することである。
【手続補正3】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【0011】
かかる課題を解決するために、本願発明者は、鋭意研究を重ねた結果、納品可否判定基準情報を流通管理サーバに登録して、納品可否判定を自動的に行うシステムを構築するというアイデアに至った。
【手続補正4】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】変更
【補正の内容】
【0023】
このように、本発明によれば、納品可否判定を流通管理サーバで自動的に行わせたので、さらに、より迅速な医薬品の納品可否判定を行うことが可能である。
【手続補正5】
【補正対象書類名】明細書
【補正対象項目名】００３１
【補正方法】変更
【補正の内容】
【0031】
Ｂ．流通管理業務
本実施形態に係る流通管理業務の概要が図２に示されている。この図は従来の流通管理業務を表す図１７と対応する図である。以下、図２及び他の図を用いて、本実施形態の流通管理業務の特徴を説明する。
流通管理サーバ１００内の情報の更新
まず、図２の白丸１において、ＭＲ１８は、納品可否判定基準情報の聴取を病院・薬局１６に対して行う。
その後、白丸２において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判定基準情報）を流通管理サーバ１００に送信する。流通管理サーバ１００は、受信した納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶する。
本実施形態では、このＭＲ１８が実行する「送信」は、流通管理サーバ１００が提供するＷｅｂサイト（Ｗｅｂ画面）上で、ＭＲ１８が、納品可否判定基準情報を入力することによって行われる。これによって、流通管理サーバ１００は、納品可否判定基準情報に基づき、納品可否判定を実行することができる。
本実施形態に係る流通管理業務の概要が図２に示されている。この図は従来の流通管理業務を表す図１７と対応する図である。以下、図２及び他の図を用いて、本実施形態の流通管理業務の特徴を説明する。
流通管理サーバ１００内の情報の更新
まず、図２の白丸１において、ＭＲ１８は、納品可否判定基準情報の聴取を病院・薬局１６に対して行う。
その後、白丸２において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判定基準情報）を流通管理サーバ１００に送信する。流通管理サーバ１００は、受信した納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶する。
本実施形態では、このＭＲ１８が実行する「送信」は、流通管理サーバ１００が提供するＷｅｂサイト（Ｗｅｂ画面）上で、ＭＲ１８が、納品可否判定基準情報を入力することによって行われる。これによって、流通管理サーバ１００は、納品可否判定基準情報に基づき、納品可否判定を実行することができる。
【手続補正6】
【補正対象書類名】明細書
【補正対象項目名】００３２
【補正方法】変更
【補正の内容】
【0032】
納品可否判定基準情報が、流通管理サーバ１００に到達するまでのルートは２種類存在する。すなわち、図２において、白丸２は２カ所示されている。１カ所目（第１のルート）は、上述したようにＭＲ１８から直接に流通管理サーバ１００に至るルートである。
２カ所目（第２のルート）は、ＭＲ１８から製薬会社のクライアントＤＢ（データベース）１６０を経由して流通管理サーバ１００に至るルートである。この第２のルートは、従前のＭＲ１８が実行していた手順を踏襲したルートである。すなわち、従来、ＭＲ１８は、自己が入手した納品可否判定基準情報を、製薬会社のクライアントＤＢ（データベース）１６０に入力していたので、この第２のルートによれば、ＭＲ１８は新しい操作（流通管理サーバ１００に情報を送信する動作）を覚える必要がなく、本システムの導入を容易にすることができるというメリットがある。
２カ所目（第２のルート）は、ＭＲ１８から製薬会社のクライアントＤＢ（データベース）１６０を経由して流通管理サーバ１００に至るルートである。この第２のルートは、従前のＭＲ１８が実行していた手順を踏襲したルートである。すなわち、従来、ＭＲ１８は、自己が入手した納品可否判定基準情報を、製薬会社のクライアントＤＢ（データベース）１６０に入力していたので、この第２のルートによれば、ＭＲ１８は新しい操作（流通管理サーバ１００に情報を送信する動作）を覚える必要がなく、本システムの導入を容易にすることができるというメリットがある。
【手続補正7】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】変更
【補正の内容】
【0036】
納品可否判定その２
さて、上記白丸７において、納品可否結果が「不可」であった場合も、Ｅメールで、特約店１０及びＭＲ１８に対して連絡を行う。その場合は、上記納品可否結果（不可）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行わない。
この場合、黒丸９において、ＭＲ１８が再び、納品可否判定基準情報の聴取を病院・薬局１６に対して行う。この処理は基本的に白丸１と同様の処理であるが、ＭＲ１８は、白丸７において、納品可否結果が「不可」であった連絡を受け取っているので、それに応じた聴取を行うことによって、効率的な聴取が可能となる。
さて、上記白丸７において、納品可否結果が「不可」であった場合も、Ｅメールで、特約店１０及びＭＲ１８に対して連絡を行う。その場合は、上記納品可否結果（不可）のＥメールを受領した特約店１０は、医薬品の納品を、病院・薬局１６に対して行わない。
この場合、黒丸９において、ＭＲ１８が再び、納品可否判定基準情報の聴取を病院・薬局１６に対して行う。この処理は基本的に白丸１と同様の処理であるが、ＭＲ１８は、白丸７において、納品可否結果が「不可」であった連絡を受け取っているので、それに応じた聴取を行うことによって、効率的な聴取が可能となる。
【手続補正8】
【補正対象書類名】明細書
【補正対象項目名】００３７
【補正方法】変更
【補正の内容】
【0037】
その後、黒丸１０において、ＭＲ１８は、病院・薬局１６から入手した情報（納品可否判定基準情報）を流通管理サーバ１００に送信する。流通管理サーバ１００は、受信した納品可否判定基準情報を、納品可否判定基準情報データベース１０８に記憶する。
この黒丸１０の動作は、既に説明した白丸２の動作と同様であり、第１のルート又は第２のルートによって、納品可否判定基準情報を、流通管理サーバ１００に送信（入力）することができ、流通管理サーバ１００は、新しい更新された納品可否判定基準情報に基づき、本システムの特徴的な動作である納品可否判定を実行することができる。
ここで、納品可否判定基準情報を、流通管理サーバ１００に送信（入力）する方法としては、ＷＥＢサーバ１０２ｂが提供するＷＥＢ画面上で納品可否判定基準情報を入力するように構成してもよい。
この黒丸１０の動作は、既に説明した白丸２の動作と同様であり、第１のルート又は第２のルートによって、納品可否判定基準情報を、流通管理サーバ１００に送信（入力）することができ、流通管理サーバ１００は、新しい更新された納品可否判定基準情報に基づき、本システムの特徴的な動作である納品可否判定を実行することができる。
ここで、納品可否判定基準情報を、流通管理サーバ１００に送信（入力）する方法としては、ＷＥＢサーバ１０２ｂが提供するＷＥＢ画面上で納品可否判定基準情報を入力するように構成してもよい。
【手続補正9】
【補正対象書類名】明細書
【補正対象項目名】００４３
【補正方法】変更
【補正の内容】
【0043】
納品連絡書データベース１０６ａ、１０６ｂは、納品連絡書１２のデータの他に、特約店１０が入力する納品先の病院・薬局１６の情報を含んでよい。
納品可否判定基準情報及び各種情報データベース１１４ａ、１１４ｂは、契約情報や、ＭＲ１８の活動情報など、納品可否判定基準情報が記憶されている。
管理マスタ１１２ａ、１１２ｂは、特約店１０、ＭＲ１８、病院・薬局１６製薬会社担当者情報を含めてよい。
納品可否判定基準情報及び各種情報データベース１１４ａ、１１４ｂは、契約情報や、ＭＲ１８の活動情報など、納品可否判定基準情報が記憶されている。
管理マスタ１１２ａ、１１２ｂは、特約店１０、ＭＲ１８、病院・薬局１６製薬会社担当者情報を含めてよい。
【手続補正10】
【補正対象書類名】明細書
【補正対象項目名】００４９
【補正方法】変更
【補正の内容】
【0049】
ステップＳ４－６は、クライアントＤＢ１６０内の「契約情報」を表している。このデータは、納品可否判定基準情報の１種であり、後述するようにファイル共有にて、流通管理者１４によって流通管理サーバ１００内の主に納品可否判定基準情報データベース１０８に記憶される。
図４の説明においては、メールの送信やファイル共有等の手法を説明したが、クライアント側の要望によっては、ＷｅｂＡＰＩ等を用いてデータを自動連携させることも好適である。この場合は、図２における白丸３、黒丸１１の処理が自動処理されるが、同連携によって、白丸４、黒丸１２の処理も含めて連携をとることも好適である。
また、図４及びその説明において示された種々の情報・書類は、一例であって、他の様々な情報・書類を利用してよい。また、図４中の納品可否判定基準情報としても、図４以外の他の様々な情報・書類を利用してよい。
図４の説明においては、メールの送信やファイル共有等の手法を説明したが、クライアント側の要望によっては、ＷｅｂＡＰＩ等を用いてデータを自動連携させることも好適である。この場合は、図２における白丸３、黒丸１１の処理が自動処理されるが、同連携によって、白丸４、黒丸１２の処理も含めて連携をとることも好適である。
また、図４及びその説明において示された種々の情報・書類は、一例であって、他の様々な情報・書類を利用してよい。また、図４中の納品可否判定基準情報としても、図４以外の他の様々な情報・書類を利用してよい。
【手続補正11】
【補正対象書類名】明細書
【補正対象項目名】００５０
【補正方法】変更
【補正の内容】
【0050】
図４のフローチャートの続きの処理が、図５のフローチャートに示されている。
図５のステップＳ５－１は、図４で説明した各種データを用いた、流通管理サーバ１００内のデータベースの更新が行われる。この更新は流通管理者１４が、流通管理者端末１４０を介して実行される。
上述した施設マスタ（Ｓ４－１）や、契約情報（Ｓ４－６）は、ファイル共有で流通管理サーバ１００内のデータベースの更新に用いられるが、他の方法でデータ更新を行ってもよい。担当ＭＲメール情報（Ｓ４－３）や、上長～ＭＲ紐付け情報（Ｓ４－５）は、流通管理者１４がデータ更新してもよい。また、例えば、上述のように、ＷｅｂＡＰＩ等を用いた自動連携を行わせてもよい。
図５のステップＳ５－１は、図４で説明した各種データを用いた、流通管理サーバ１００内のデータベースの更新が行われる。この更新は流通管理者１４が、流通管理者端末１４０を介して実行される。
上述した施設マスタ（Ｓ４－１）や、契約情報（Ｓ４－６）は、ファイル共有で流通管理サーバ１００内のデータベースの更新に用いられるが、他の方法でデータ更新を行ってもよい。担当ＭＲメール情報（Ｓ４－３）や、上長～ＭＲ紐付け情報（Ｓ４－５）は、流通管理者１４がデータ更新してもよい。また、例えば、上述のように、ＷｅｂＡＰＩ等を用いた自動連携を行わせてもよい。
【手続補正12】
【補正対象書類名】明細書
【補正対象項目名】００５３
【補正方法】変更
【補正の内容】
【0053】
（２）準備処理その２
次に、図２における白丸２や黒丸１０に相当し、そして白丸３、黒丸１１にも相当する処理を、図７のフローチャートに基づき説明する。
（２）－１ 様々な納品可否判定基準情報
図７のＤ７－１の実施施設責任医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－２で表されている。また、流通管理者１４（流通管理者端末１４０に）にメールを送信した状態がＤ７－３で表されている。
同様に、Ｄ７－４の分担医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－５で表されている。また、流通管理者１４（流通管理者端末１４０）にメールを送信した状態がＤ７－６で表されている。
また、Ｄ７－７で示される協力確認書（医師用）は、病院・薬局１６からＭＲ１８に提供される。ＭＲ１８に提供された状態がＤ７－８で示されている。このＤ７－８をＭＲ１８がクライアントＤＢに入力する。入力した状態がＤ７－９で表されている。また、流通管理者１４に（流通管理者端末１４０に）メールを送信した状態がＤ７－１０で表されている。
次に、図２における白丸２や黒丸１０に相当し、そして白丸３、黒丸１１にも相当する処理を、図７のフローチャートに基づき説明する。
（２）－１ 様々な納品可否判定基準情報
図７のＤ７－１の実施施設責任医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－２で表されている。また、流通管理者１４（流通管理者端末１４０に）にメールを送信した状態がＤ７－３で表されている。
同様に、Ｄ７－４の分担医師申請書は、ＭＲ１８が入手し、ＭＲ１８がクライアントＤＢ１６０に入力する。入力した状態がＤ７－５で表されている。また、流通管理者１４（流通管理者端末１４０）にメールを送信した状態がＤ７－６で表されている。
また、Ｄ７－７で示される協力確認書（医師用）は、病院・薬局１６からＭＲ１８に提供される。ＭＲ１８に提供された状態がＤ７－８で示されている。このＤ７－８をＭＲ１８がクライアントＤＢに入力する。入力した状態がＤ７－９で表されている。また、流通管理者１４に（流通管理者端末１４０に）メールを送信した状態がＤ７－１０で表されている。
【手続補正13】
【補正対象書類名】明細書
【補正対象項目名】００５６
【補正方法】変更
【補正の内容】
【0056】
具体的には、流通管理サーバ１００が、データ入力のためのＷｅｂサイトをＭＲ１８に対して提供することが好ましい。つまり、通信部１０２のＷＥＢサーバ１０２ｂがこのようなＷＥＢサイトの画面を提供し、ＭＲ１
８はその画面上で所定のデータを入力することによって、所定のデータを直接流通管理サーバ１００の各種データベースに記憶させることができる。ＷＥＢ１０２ｂは、入力されたデータを制御部１０４に送り、制御部１０４は、そのデータを種類に応じて納品可否判定基準情報データベース１０８等の各種情報データベース１１０等のデータベースに記憶させる。このようにして、納品可否判定基準情報データベース１０８等の更新が行われる。
さて、納品可否判定基準情報データベース１０８に格納されるデータは、納品可否判定基準情報である。図７及びその説明（主として（２）－１準備処理その２の説明）において示された種々の納品可否判定基準情報は、一例であって、他の様々な情報を、納品可否判定基準情報として利用してよい。
８はその画面上で所定のデータを入力することによって、所定のデータを直接流通管理サーバ１００の各種データベースに記憶させることができる。ＷＥＢ１０２ｂは、入力されたデータを制御部１０４に送り、制御部１０４は、そのデータを種類に応じて納品可否判定基準情報データベース１０８等の各種情報データベース１１０等のデータベースに記憶させる。このようにして、納品可否判定基準情報データベース１０８等の更新が行われる。
さて、納品可否判定基準情報データベース１０８に格納されるデータは、納品可否判定基準情報である。図７及びその説明（主として（２）－１準備処理その２の説明）において示された種々の納品可否判定基準情報は、一例であって、他の様々な情報を、納品可否判定基準情報として利用してよい。
【手続補正14】
【補正対象書類名】明細書
【補正対象項目名】００６１
【補正方法】変更
【補正の内容】
【0061】
（２）－３ ロック解除条件
なお、本実施形態における流通管理においては、納品可否判定が「不可」となり、納品が許可されていない状態をロック状態、又は単にロックと呼ぶ。
このロック状態を解除する条件は、以下の情報が全て揃っていることである。
・契約情報
・契約医師データ（責任医師）
・契約医師データ（分担医師）
・施設申請書
・医師申請書（責任医師、分担医師）
・協力確認書（薬剤部用）
・協力確認書（医師用）
ここで挙げる情報は一例であり、他の情報を利用してもよい。
製剤毎に条件は異なる。実際の運用に当たっては、製剤毎に上記情報をカスタマイズすることになる。
なお、本実施形態における流通管理においては、納品可否判定が「不可」となり、納品が許可されていない状態をロック状態、又は単にロックと呼ぶ。
このロック状態を解除する条件は、以下の情報が全て揃っていることである。
・契約情報
・契約医師データ（責任医師）
・契約医師データ（分担医師）
・施設申請書
・医師申請書（責任医師、分担医師）
・協力確認書（薬剤部用）
・協力確認書（医師用）
ここで挙げる情報は一例であり、他の情報を利用してもよい。
製剤毎に条件は異なる。実際の運用に当たっては、製剤毎に上記情報をカスタマイズすることになる。
【手続補正15】
【補正対象書類名】明細書
【補正対象項目名】００６４
【補正方法】変更
【補正の内容】
【0064】
本実施形態では、納品連絡書１２は、コンピュータファイルであり、発行日、特約店１０の名称、納品したい医薬品（の名称・数量）、納品先の病院・薬局１６の名称、を含むコンピュータファイルである。この納品連絡書１２は、判定結果フラグが設けられており、判定結果を表すことができる。例えば、
「可」 ：判定結果が納品可能である。
「不可」：判定結果が納品不可である。
とすることができる。納品連絡書１２の発行（作成）時点では、判定結果フラグは「値なし」としてよい。
本実施形態では、「判定結果「フラグ」」と称しているが、そのコンピュータファイル（納品連絡書１２）に属性（可、不可、（値なし）等）を付与するものであればどのようなものでもよく、そのコンピュータファイルのヘッダ部分等に含まれていてもよい。
「可」 ：判定結果が納品可能である。
「不可」：判定結果が納品不可である。
とすることができる。納品連絡書１２の発行（作成）時点では、判定結果フラグは「値なし」としてよい。
本実施形態では、「判定結果「フラグ」」と称しているが、そのコンピュータファイル（納品連絡書１２）に属性（可、不可、（値なし）等）を付与するものであればどのようなものでもよく、そのコンピュータファイルのヘッダ部分等に含まれていてもよい。
【手続補正16】
【補正対象書類名】明細書
【補正対象項目名】００７４
【補正方法】変更
【補正の内容】
【0074】
（５）納品「不可」の対応
納品「不可」の対応の動作を表すフローチャートが、図１１に示されている。
ステップＳ１１－１において、納品「不可」の対応の処理が開始される。
ステップＳ１１－２において、流通管理サーバ１００は、ＷＥＢ上で流通管理画面を表示する。これは、制御部１０４が、通信部１０２内のＷＥＢサーバ１０２ｂを操作し所望の内容を表示させることによって実現される。
その画面では、判定結果フラグが「不可」である納品連絡書１２の内容が表示されている。これによって、特約店１０や、ＭＲ１８は、納品連絡書１２が拒否され、納品「不可」となったことを知ることができる。この表示は、特約店端末１３０、ＭＲ端末１５０等の上で閲覧することができる。判定結果フラグが「不可」である納品連絡書１２を「不可」納品連絡書１２と呼ぶ。
上記画面では、判定結果フラグが「不可」である納品連絡書１２が表示される。例えば、その納品連絡書１２に係る医薬品名称や、納品先である病院・薬局１６の名称等が表示されることが好ましい。さらに、「不可」となった要因、すなわちロック解除のために満たすべきであった情報の中で、満たされなかった（欠落した）情報を、表示することが好ましい。このように、「不可」となった要因（情報の欠落）を表示することによって、ＭＲ１８は、その要因に対して速やかに対処することができる。
例えば、所定の契約情報が揃っていなかった場合、ＭＲ１８は、当該契約情報を携えて病院・薬局１６に聴取に行き、契約情報を交わすことができる。また、聴取の結果、契約情報は交わしているが、流通管理サーバ１００内のデータベース（納品可否判定基準情報データベース１０８）に登録されていなかったことが判明する場合もある。その場合は、ＭＲ１８は、その契約情報を、流通管理サーバ１００内の納品可否判定基準情報データベース１０８に登録することができる。
このように、「不可」となった要因となる情報を画面に表示することによって、ＭＲ１８は種々の対応を速やかに実行することができる。
納品「不可」の対応の動作を表すフローチャートが、図１１に示されている。
ステップＳ１１－１において、納品「不可」の対応の処理が開始される。
ステップＳ１１－２において、流通管理サーバ１００は、ＷＥＢ上で流通管理画面を表示する。これは、制御部１０４が、通信部１０２内のＷＥＢサーバ１０２ｂを操作し所望の内容を表示させることによって実現される。
その画面では、判定結果フラグが「不可」である納品連絡書１２の内容が表示されている。これによって、特約店１０や、ＭＲ１８は、納品連絡書１２が拒否され、納品「不可」となったことを知ることができる。この表示は、特約店端末１３０、ＭＲ端末１５０等の上で閲覧することができる。判定結果フラグが「不可」である納品連絡書１２を「不可」納品連絡書１２と呼ぶ。
上記画面では、判定結果フラグが「不可」である納品連絡書１２が表示される。例えば、その納品連絡書１２に係る医薬品名称や、納品先である病院・薬局１６の名称等が表示されることが好ましい。さらに、「不可」となった要因、すなわちロック解除のために満たすべきであった情報の中で、満たされなかった（欠落した）情報を、表示することが好ましい。このように、「不可」となった要因（情報の欠落）を表示することによって、ＭＲ１８は、その要因に対して速やかに対処することができる。
例えば、所定の契約情報が揃っていなかった場合、ＭＲ１８は、当該契約情報を携えて病院・薬局１６に聴取に行き、契約情報を交わすことができる。また、聴取の結果、契約情報は交わしているが、流通管理サーバ１００内のデータベース（納品可否判定基準情報データベース１０８）に登録されていなかったことが判明する場合もある。その場合は、ＭＲ１８は、その契約情報を、流通管理サーバ１００内の納品可否判定基準情報データベース１０８に登録することができる。
このように、「不可」となった要因となる情報を画面に表示することによって、ＭＲ１８は種々の対応を速やかに実行することができる。
【手続補正17】
【補正対象書類名】明細書
【補正対象項目名】００７８
【補正方法】変更
【補正の内容】
【0078】
そこで、図６に示されたフローチャートから説明を行う。
図６のステップＳ６－１において、契約情報確認と、責任医師確認と、が行われる。これらの処理は流通管理者１４が実行してよい。ここで、契約情報確認とは、契約締結済みであることを確認することをいう。期間満了の場合は、更新手続開始済みであることを確認する。また、責任医師確認とは、責任医師が、契約情報に記載がある責任医師であることを確認することをいう。
図６のステップＳ６－１において、契約情報確認と、責任医師確認と、が行われる。これらの処理は流通管理者１４が実行してよい。ここで、契約情報確認とは、契約締結済みであることを確認することをいう。期間満了の場合は、更新手続開始済みであることを確認する。また、責任医師確認とは、責任医師が、契約情報に記載がある責任医師であることを確認することをいう。
【手続補正18】
【補正対象書類名】明細書
【補正対象項目名】００８８
【補正方法】変更
【補正の内容】
【0088】
（９）本実施形態における特徴的な技術事項である再判定についての効果
ここで、本実施形態の「再判定」の特徴的な効果と運用上の工夫等を説明する。
（９ａ）納品連絡書１２の再判定
従来用いられていたシステムでは、納品連絡書１２について「不可」の判定が出された場合は、その判定結果は、特約店１０だけでなく、ＭＲ１８にも通知される（画面表示される）ので、ＭＲ１８がすぐに、判定基準を整えるための聴取等を実行することができる。その結果、可否判定基準を満たすための対応処理が迅速に行え、その結果、「不可」となった納品連絡書１２が「可」となる為の対応が取りやすい。
ここで、本実施形態の「再判定」の特徴的な効果と運用上の工夫等を説明する。
（９ａ）納品連絡書１２の再判定
従来用いられていたシステムでは、納品連絡書１２について「不可」の判定が出された場合は、その判定結果は、特約店１０だけでなく、ＭＲ１８にも通知される（画面表示される）ので、ＭＲ１８がすぐに、判定基準を整えるための聴取等を実行することができる。その結果、可否判定基準を満たすための対応処理が迅速に行え、その結果、「不可」となった納品連絡書１２が「可」となる為の対応が取りやすい。
【手続補正19】
【補正対象書類名】明細書
【補正対象項目名】００８９
【補正方法】変更
【補正の内容】
【0089】
そこで、上述したように、「不可」納品連絡書１２をそのまま保存して、その後、納品可否判定基準情報が更新された場合に、流通管理サーバ１００が自動的にその都度（更新される度に）再判定を実行している。その結果、「不可」→「可」となるものがあれば、速やかに「可」とすることができ、迅速な納品連絡書１２の処理を行うことができる。
【手続補正20】
【補正対象書類名】図面
【補正対象項目名】図２
【補正方法】変更
【補正の内容】
【図2】
【手続補正21】
【補正対象書類名】図面
【補正対象項目名】図４
【補正方法】変更
【補正の内容】
【図4】