JP6423716B2 - 配送管理装置及び配送管理方法 - Google Patents

Description

本発明は、放射性医薬品の配送を管理する技術に関する。

放射性医薬品は、ＳＰＥＣＴ検査、ＰＥＴ検査等のような病気の診断や検査、放射性治療等に用いられている。放射性医薬品は、放射性物質であることから、生産、配送、廃棄等の全ての場面で安全性が十分に確保される必要がある。一方で、放射性医薬品は、放射能の半減期により有効期間が比較的短いため、医療機関に安定的に供給されることが求められる。

このような特殊な制約を持つ放射性医薬品の配送は、その他の物品の配送と比べて、より慎重に行われることが望まれる。下記特許文献１及び２は、放射性医薬品、放射性薬剤を迅速及び効率よく配送するための手法を提案する。特許文献１の配送システムでは、サーバが、荷主端末からの受注情報を記憶すると共に、その受注情報に基づいて、ログインした運送会社に対して割り当てられた出荷拠点及び顧客情報を運送会社端末に表示させる。更に、サーバは、その運送会社端末から入力された、集荷日時、配送日時、配送者情報を含む手配データを記憶し、出荷拠点に手配表及び引渡表の作成を指示する。各出荷拠点は、到着した配送者に渡された引渡表と製品との照合により出荷の可否を判定する。下記特許文献２の手法は、放射性薬剤の配送拠点及び検査施設の所在地と、検査施設での検査スケジュールとに基づいて、各配送車両がそれぞれ配送拠点から一以上の検査施設へ放射性薬剤を配送するための配送ルート及び各検査施設への配達時刻を含む配送スケジュールを自動生成する。

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

放射性医薬品の配送は、輸送トラブルや生産トラブルにより影響を受ける。配送スケジュールに影響を与える輸送トラブルは、台風、暴風雨、豪雪、地震等の自然現象や交通事故等により偶発的に起こり得る。例えば、輸送障害には、航空機、列車、船舶の運行停止、高速自動車道や一般道の一部区間の通行止め、渋滞等がある。一方で、医療機関での放射性医薬品を用いた医療行為は、このようなトラブルの有無に関わらず実施される。配送が遅延し、放射性医薬品を予定時刻に納品できない場合、医療施設での医療行為が滞ってしまい、重大な問題となり得る。

そこで、メーカの物流部門や運送会社は、トラブルが発生した場合、既定の配送ルートを見直し、医療機関での医療スケジュールに合うように新たな配送ルートを迅速に決定する必要がある。更に、トラブル発生時には、通常時よりも増して、放射性医薬品の配送状況が顧客である医療機関に対して迅速に通知されるべきである。医療機関がそのトラブルに対して迅速に対応することができるからである。

医療機関に対して配送状況が迅速に通知されるためには、メーカ内の物流部門や営業部門、並びに外部の運送会社等の間で配送状況が迅速に共有されることが望ましい。ところが、上述の特許文献１では、配送状況を管理する点については特に言及されていない。また、特許文献２の提案手法は、一台の配送車両が複数の検査施設に対して配送することができるように、配送ルートをどのように作成するかにフォーカスしており、配送状況を複数の部門間で如何に共有するかについては特に言及されていない。

本発明は、このような事情に鑑みてなされたものであり、放射性医薬品の配送スケジュールを迅速に複数部門間で共有可能とする。

本発明の各側面では、上述した課題を解決するために、それぞれ以下の構成を採用する。

第一の側面は、配送管理装置に関する。第一の側面に係る配送管理装置は、出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する情報格納手段と、この情報格納手段に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる表示処理手段と、を有する。上記表示処理手段は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す一配送単位の配送スケジュール情報を各クライアント装置にそれぞれ表示させる。

第二の側面は、少なくとも一つのコンピュータにより実行される配送管理方法に関する。第二の側面に係る配送管理方法は、出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する情報格納部を参照し、この情報格納部に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる、ことを含む。そして、一配送単位の配送スケジュール情報は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す。

なお、本発明の他の側面は、上記第二の側面の方法を少なくとも１つのコンピュータに実行させるプログラムや、このようなプログラムを記録したコンピュータが読み取り可能な記録媒体である。この記録媒体は、非一時的な有形の媒体を含む。

上記各側面によれば、放射性医薬品の配送スケジュールを迅速に複数部門間で共有することができる。

第一実施形態における配送管理装置の処理構成例を概念的に示す図である。 配送単位の態様を概念的に示す図である。 第一実施形態における配送管理装置の動作例を示すフローチャートである。 第二実施形態における配送管理システムのシステム構成例を概念的に示す図である。 第二実施形態における配送管理サーバの処理構成例を概念的に示す図である。 第二実施形態における情報格納部の例を示す図である。 配送スケジュール情報の表示画面の一部の例を示す図である。 関連画面の例を示す図である。 配送スケジュール情報の単票表示画面の例を示す図である。 配送スケジュール情報の更新履歴画面の一部の例を示す図である。 更新通知の例を示す図である。 第二実施形態における配送管理システムの主な活用方法を示す図である。 各ユーザ端末が配送スケジュール情報を閲覧する際の、第二実施形態における配送管理サーバの動作例を示すフローチャートである。 ユーザ端末が配送スケジュール情報を更新する際の、第二実施形態における配送管理サーバの動作例を示すフローチャートである。 配送スケジュール情報が所定期間更新されない場合の、第二実施形態における配送管理サーバの動作例を示すフローチャートである。

以下、本発明の実施の形態について説明する。なお、以下に挙げる各実施形態はそれぞれ例示であり、本発明は以下の各実施形態の構成に限定されない。

［第一実施形態］
〔処理構成〕
図１は、第一実施形態における配送管理装置１００の処理構成例を概念的に示す図である。図１に示されるように、配送管理装置１００は、表示処理部１０１、情報格納部１０２等を有する。情報格納部１０２は、出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する。ここで、末端拠点とは、一以上の各納入先まで移動する配送車が、各納入先にそれぞれ同時に納品する放射性医薬品を積んで出発する最後の輸送拠点を意味する。データ項目が時間を示す輸送ルート上の拠点の数は１以上であれば、特に制限されない。当該拠点は、異なる出荷元からの複数の輸送ルートが合流し得る輸送拠点を意味する。当該拠点は、末端拠点を含み、空港、駅等の輸送手段が切り替わる場所を含み得る。

表示処理部１０１は、情報格納部１０２に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる。区分け表示の実装手法は制限されない。例えば、区分け表示は、リスト表示の各行のように線分により実現されてもよいし、単票表示のように表示切り替えやスライド表示により実現されてもよい。

表示処理部１０１は、一納入先に同時に納品する放射性医薬品の配送を「配送単位」として扱い、放射性医薬品の配送スケジュール情報をこの「配送単位」に区分けして表示する。区分け表示される一つの配送単位は、図２に示されるような配送態様を含む。
図２は、配送単位の態様を概念的に示す図である。図２に示されるように、当該配送単位には大きく分けて３つの態様があり得る。もちろん、各態様の組み合わせもあり得る。
（態様１）一出荷元から同時に出荷された放射性医薬品が一納入先に同時に納品される配送。
（態様２）複数の出荷元から出荷された放射性医薬品が輸送ルート上の或る拠点で合流し、一納入先に同時に納品される配送。
（態様３）一出荷元から異なる時間に出荷された放射性医薬品が輸送ルート上の或る拠点で合流し、一納入先に同時に納品される配送。

配送単位が（態様２）を示す場合、表示処理部１０１は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す一配送単位の配送スケジュール情報を各クライアント装置にそれぞれ表示させる。

配送単位は、情報格納部１０２に格納される一つのデータレコードに対応してもよいし、複数のデータレコードに対応してもよい。（態様２）及び（態様３）では、合流拠点より前の輸送ルートは枝分かれしているため、前者の場合、一つのデータレコードで複数の輸送ルートが示される。また、後者の場合には、一配送単位に対応する複数のデータレコードを関連付ける必要があるため、各データレコードに関連付けＩＤが含まれればよい。

配送管理装置１００は、一般的なコンピュータであり、例えば、後述する第二実施形態における配送管理サーバ１０と同様のハードウェア構成を有する。その配送管理サーバ１０と同様にプログラムが処理されることで、上述の各処理モジュールが実現される。上述の各クライアント装置は、携帯型又は据え置き型の一般的なコンピュータであり、例えば、後述する第二実施形態における営業者端末５、物流部門端末６、運送会社端末７等である。

〔動作例／配送管理方法〕
図３は、第一実施形態における配送管理装置１００の動作例を示すフローチャートである。第一実施形態における配送管理方法は、図３に示されるように、配送管理装置１００のような少なくとも一つのコンピュータにより実行される。配送管理方法は、上述の情報格納部１０２を参照し（Ｓ１０１）、情報格納部１０２に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる（Ｓ１０２）ことを含む。区分け表示される配送単位には上述のような態様があり得る。よって、一配送単位の配送スケジュール情報は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す場合がある。

〔第一実施形態における作用及び効果〕
上述のように、第一実施形態では、情報格納部１０２に格納されるデータレコードにより示される放射性医薬品の配送スケジュール情報が、一納入先に同時に納品する配送単位に区分けされて、各クライアント装置にそれぞれ表示される。例えば、配送スケジュール情報は、放射性医薬品のメーカの物流部門及び営業部門、並びに運送会社の各クライアント装置にそれぞれ表示される。配送スケジュール情報は、出荷される放射性医薬品、末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間等を示す。従って、第一実施形態によれば、放射性医薬品の配送スケジュールを複数部門間で迅速に共有することができる。

更に、第一実施形態では、一納入先に同時に納品される放射性医薬品の配送が「配送単位」として扱われ、放射性医薬品の配送スケジュール情報がこの「配送単位」に区分けされて表示される。これにより、閲覧者は、一納入先に同時に納品される放射性医薬品の配送ごとの配送スケジュールを容易に把握することができる。

上述の配送態様で示されるように、一納入先に同時に納品される放射性医薬品は、末端拠点又はそれより前の拠点で合流するまで、複数の輸送ルートで配送される場合があり得る。特に、輸送トラブルや生産トラブルが生じた場合には、このような複雑な輸送ルートが選択される可能性が高くなる。トラブル発生時においても、納入先での検査や診断等に間に合わせる必要があるため、あらゆる手段が選択されるからである。本実施形態によれば、一納入先に同時に納品される放射性医薬品が複数の輸送ルートで配送される場合であっても、その輸送ルート上の拠点毎の時間等が一つの配送単位として他と区切られて表示されるため、閲覧者は、各輸送ルートでの配送スケジュールを容易に把握することができる。即ち、トラブル発生時においても、放射性医薬品の配送スケジュールを複数部門間で迅速かつ容易に共有することができる。

以下、上述の第一実施形態について更に詳細を第二実施形態として説明する。以下には、放射性医薬品メーカが運送会社の輸送手段を用いて放射性医薬品を納入先である医療機関に納品する配送モデルが例示される。但し、以下の第二実施形態は、このような配送モデルのみに適用が制限されるものではない。運送会社の輸送手段は用いられなくてもよいし、納入先は医療機関でなくてもよい。

［第二実施形態］
〔システム構成〕
図４は、第二実施形態における配送管理システム１のシステム構成例を概念的に示す図である。図１に示されるように、配送管理システム１は、配送管理サーバ１０、営業者端末５、物流部門端末６、運送会社端末７、物流サーバ８等を有し、メーカから出荷される放射性医薬品の配送状況を管理する。

配送管理サーバ１０は、上述の配送管理装置１００に相当する。
配送管理サーバ１０は、いわゆるコンピュータであり、図４に示されるように、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インタフェース（Ｉ／Ｆ）１３、通信ユニット１４等を有する。メモリ１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ハードディスク等である。入出力Ｉ／Ｆ１３は、表示装置（図示せず）、入力装置（図示せず）等のユーザインタフェース装置と接続可能である。通信ユニット１４は、他のコンピュータとの通信網２を介した通信や、他の機器との信号のやりとり等を行う。通信ユニット１４には、可搬型記録媒体等も接続され得る。配送管理サーバ１０は、図４に図示されないハードウェア要素を含んでもよく、配送管理サーバ１０のハードウェア構成は制限されない。

配送管理サーバ１０は、通信網２と通信可能に接続される。配送管理サーバ１０は、通信網２を介して、営業者端末５、物流部門端末６、運送会社端末７、物流サーバ８等の他のコンピュータと通信可能である。通信網２は、Ｗｉ−Ｆｉ（Wireless Fidelity）回線網、インターネット通信網、専用回線網、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等の組み合わせにより形成される。但し、第二実施形態では、通信網２を介したコンピュータ間の通信形態は制限されない。

営業者端末５、物流部門端末６及び運送会社端末７は、携帯型又は据え置き型の一般的なコンピュータである。各端末５、６及び７は、ＣＰＵ１１、メモリ１２、入出力Ｉ／Ｆ１３、通信ユニット１４、表示装置（図示せず）、入力装置（図示せず）等をハードウェア要素としてそれぞれ有する。これら各端末は、配送管理サーバ１０との通信、画面表示、表示される画面に対するユーザ操作の検出等を行うことができれば、そのハードウェア構成は制限されない。以降、各端末５、６及び７をユーザ端末と総称する場合がある。

第二実施形態では、説明の便宜のため、各ユーザ端末のユーザを次のように仮定する。営業者端末５のユーザは、放射性医薬品メーカの医薬情報担当者であり、物流部門端末６のユーザは、同メーカの物流部門の担当者であり、運送会社端末７のユーザは、運送会社の担当者である。但し、各端末５、６及び７のユーザは制限されない。以降、営業者端末５はＭＲ（Medical Representative）端末５と、物流部門端末６はＤＡ（Distribution Arm）端末６と、運送会社端末７はＴＣ（Transport Company）端末７と略称する場合もある。また、各端末５、６、及び７のユーザである医薬情報担当者、物流部門の担当者、及び運送会社の担当者は、ユーザＭＲ、ユーザＤＡ、ユーザＴＣと表記される場合もある。

物流サーバ８は、放射性医薬品メーカにおける出荷情報を管理する。放射性医薬品を出荷するまでの間に、メーカと顧客である医療機関との間で、出荷すべき放射性医薬品、納入先施設及び納入時間が決められており、メーカは出荷すべき放射性医薬品の生産拠点（出荷元）を決めている。よって、物流サーバ８により管理される出荷情報には、出荷すべき放射性医薬品、生産拠点（出荷元）、納入先施設及び納入時間が少なくとも含まれる。物流サーバ８は、管理される出荷情報に基づいて、出荷明細データファイルを出力する。出力される出荷明細データファイルにも、出荷すべき放射性医薬品、出荷元、納入先及び納入時間が少なくとも含まれる。

〔処理構成〕
図５は、第二実施形態における配送管理サーバ１０の処理構成例を概念的に示す図である。図５に示されるように、配送管理サーバ１０は、情報格納部２０、取り込み部２１、アクセス制御部２２、表示処理部２３、更新処理部２４、検出部２５、通知部２６、統計処理部２７、取込処理部２８、情報抽出部２９等を有する。これら各処理モジュールは、例えば、ＣＰＵ１１によりメモリ１２に格納されるプログラムが実行されることにより実現される。そのプログラムは、例えば、ＣＤ（Compact Disc）、メモリカード等のような可搬型記録媒体や他のコンピュータから通信ユニット１４を介してインストールされ、メモリ１２に格納されてもよい。

図６は、第二実施形態における情報格納部２０の例を示す図である。情報格納部２０は、上述の第一実施形態における情報格納部１０２に相当する。情報格納部２０は、上述の「配送単位」の配送スケジュール情報を一データレコードとして格納する。情報格納部２０に格納される各データレコードには、図６に示される複数のデータ項目がそれぞれ含まれる。但し、各データレコードには、全てのデータ項目のデータ（値）が設定されなくてもよく、データ無し（値無し）のデータ項目が含まれていてもよい。

上述の（態様２）及び（態様３）のように、一つの配送単位に複数の輸送ルートが含まれる場合がある。即ち、データ項目においては、輸送ルート毎に異なるデータ（値）が設定される場合がある。第二実施形態では、複数の輸送ルートの情報が改行コードにより区別された状態で各データ項目にそれぞれ格納される。但し、輸送ルートを区別するコードは、改行コードに限らず、タブコード、空白のコード等のような他のコードであってもよい。

各データレコードに含まれるデータ項目は、大きく、基本情報、配送振替情報、配送進捗状況情報、納入完了報告情報に分類される。基本情報のデータ項目は、当初予定されていた基本的な配送計画を示す。基本情報のデータ項目には、出荷日、出荷元、納入先名（病院名）、製品情報、納入時間（ＦＲＯＭ）、納入時間（ＴＯ）、出荷時間、空港名及び担当店名が含まれる。「出荷元」には例えば出荷される放射性医薬品を生産する工場名が設定される。「製品情報」には出荷される放射性医薬品の名称等が設定される。「納入時間（ＦＲＯＭ）」及び「納入時間（ＴＯ）」には、納入予定時間の時間幅を指定する各時間がそれぞれ設定される。「空港名」にはそのデータレコードが示す「配送単位」が空輸の輸送ルートを含む場合に納入先に最も近い空輸ルートの着陸空港名が設定される。「担当店名」には上述の末端拠点の名称が設定される。

配送振替情報のデータ項目は、トラブル等により当初予定されていた配送計画から変更された情報を示す。配送振替情報のデータ項目には、公開レベル、振替空港、搭載便名、空港発時間（空港発と図示）、航空機着時間（航空機着と図示）、幹線出発時間（幹線出発と図示）、幹線到着時間（幹線到着と図示）、振替担当店名、末端出発時間（末端到着と図示）及び予想納入時間が含まれる。「公開レベル」には、非公開、非公開（調整）及び公開の三つの公開レベルを示す公開レベルデータのうちの一つが設定される。以降の説明では、非公開、非公開（調整）及び公開の順に高い公開レベルを示すと仮定する。後述の取り込み部２１により生成されるデータレコードにおける配送振替情報の「公開レベル」には非公開を示す公開レベルデータが設定される。「幹線出発時間」及び「幹線到着時間」には、「航空機着時間」で示される時間に航空機が着陸した空港からの出発時間及び「振替担当店名」により示される末端拠点への到着時間が設定される。「末端出発時間」には「振替担当店名」により示される末端拠点からの出発時間が設定される。配送振替情報における各時間のデータ項目には、実績時間又は予定（予想）時間が設定される。

配送進捗状況情報のデータ項目は、配送の進捗状況を示す。配送進捗状況情報のデータ項目には、配送ステータス、配送状況及び時刻が含まれる。「配送ステータス」には空輸中、陸送中、完了等を示すフラグデータが設定される。「配送状況」には、現在位置、移動速度や渋滞状況、次の拠点への予想到着時間等、配送の近況を表す任意のテキストデータが設定される。「時刻」には「配送ステータス」又は「配送状況」を入力した時刻が設定される。
納入完了報告情報のデータ項目は、納入完了に関する情報を示す。納入完了報告情報のデータ項目には、実納入時間、納入場所、納入サインが含まれる。「納入サイン」には納入確認者の名前が設定される。

但し、上述のデータ項目は例示であり、他のデータ項目が含まれてもよい。例えば、基本情報のデータ項目には、運送会社名、製品コード、納入先ＩＤ、出荷元ＩＤ等が含まれていてもよい。

情報格納部２０は、ユーザと納入先との対応関係を示す情報を更に格納する。この対応関係は、後述の通知部２６による更新通知の宛先を特定するために利用されるため、第二実施形態では、納入先と対応付けられるユーザは、基本的には、ＭＲユーザ（医薬情報担当者）となる。また、一つの納入先に対して、ＭＲユーザ及びＤＡユーザを含む複数のユーザが対応付けられてもよい。また、納入先（医療機関）の端末のユーザのアドレス情報が納入先ＩＤと対応付けられてもよい。

例えば、情報格納部２０は、上記対応関係を示す情報として、ユーザのアドレス情報及び納入先ＩＤを相互に関連付けた状態で格納する。この場合、上記データレコードには、納入先ＩＤが含まれる。ユーザのアドレス情報は、後述する通知部２６による通知の宛先に設定され得る情報である。その通知が電子メールで行われる場合には、ユーザのアドレス情報は、Ｅメールアドレスであればよい。また、その通知がＳＮＳ（Social Networking Service）、グループウェア等の通知機能で実現される場合には、ユーザのアドレス情報は、ＳＮＳやグループウェア等のユーザＩＤであってもよい。この場合には、ユーザのアドレス情報及び納入先ＩＤに加えて、ＳＮＳやグループウェアのサイト（サーバ）を特定する情報が更に関連付けられる。

取り込み部２１は、物流サーバ８から出力された出荷明細データファイルを取得し、その出荷明細データファイルを参照して、そのファイルから取り込むべき各項目のデータをそれぞれ抽出する。例えば、出荷明細データファイルは、ＣＳＶ（Comma-Separated Value）形式で出力される。但し、出荷明細データファイルの形式は、各データ項目のデータ（値）が区別可能であれば、任意である。

取込処理部２８は、取り込み部２１により抽出された各項目のデータに基づいて、情報格納部２０に格納すべきデータレコードを生成し、その生成されたデータレコードを情報格納部２０に格納する。取り込み部２１及び取込処理部２８は、取り込み手段と呼ぶこともできる。

出荷明細データファイル内には、上述したとおり、出荷される放射性医薬品、出荷元、納入先及び納入時間をそれぞれ示す複数の項目を少なくとも含むレコードが少なくとも１つ格納される。図６に示される基本情報のデータ項目は、出荷明細データファイル内のレコードに含まれてもよい。このように、出荷明細データファイルに格納されるレコードには、情報格納部２０に格納される全てのデータ項目が含まれていなくてもよい。この場合、取り込み部２１及び取込処理部２８は、出荷明細データファイルから読み込まれるレコードに存在しないデータ項目については初期値又は値無し（ＮＵＬＬ等）を設定すればよい。

また、出荷明細データファイルに格納されるレコードは、情報格納部２０に格納される一データレコードが示す配送単位に対応していなくてもよい。例えば、出荷明細データファイルに格納される各レコードは、受注毎に分けられていてもよいし、放射性医薬品毎に分けられていてもよい。この場合、取り込み部２１及び取込処理部２８は、出荷明細データファイルから読み取られる複数のレコードを納入先及び納入時間でグルーピングすることにより、情報格納部２０に格納すべき配送単位のデータレコードを生成することができる。

アクセス制御部２２は、各ユーザ端末から送られるユーザＩＤを用いて、各ユーザ端末からのアクセスを制御する。具体的には、アクセス制御部２２は、アクセスしてきたユーザ端末から取得されたユーザＩＤに対応する公開レベルを特定し、その公開レベルを表示処理部２３に知らせる。例えば、アクセス制御部２２は、ユーザＩＤと所属グループ（ＭＲユーザグループ、ＤＡユーザグループ、ＴＣユーザグループ等）との対応情報、及び所属グループと公開レベルとの対応情報を保持しており、これら対応情報を用いて、取得されたユーザＩＤに対応する公開レベルを特定する。また、アクセス制御部２２は、ユーザＩＤと公開レベルとの対応情報を保持していてもよい。

第二実施形態では、ＤＡユーザ、ＴＣユーザ、ＭＲユーザの順で高い公開レベル（非公開、非公開（調整）、公開）が特定される。これにより、公開レベルが非公開を示す配送スケジュール情報は、ＤＡユーザのみに閲覧され、公開レベルが非公開（調整）を示す配送スケジュール情報は、ＤＡユーザ及びＴＣユーザに閲覧され、公開レベルが公開を示す配送スケジュール情報は、ＤＡユーザ、ＴＣユーザ及びＭＲユーザに閲覧され得る。

更に、アクセス制御部２２は、ユーザ端末から取得されるユーザＩＤ又はそのユーザＩＤから得られる情報（例えば、所属グループ情報）に基づいて、表示された配送スケジュール情報の変更を許可するか否かを判断することもできる。例えば、ＤＡユーザ及びＴＣユーザに対してのみ、配送スケジュール情報の変更が許可され、ＭＲユーザに対しては配送スケジュール情報の閲覧のみが許可される。更に、アクセス制御部２２は、各ユーザ端末から送られるユーザＩＤに基づいて、そのユーザの正当性を確認することもできる。正当性の確認には、パスワード等のＰＩＮ（Personal Identification Number）認証が行われてもよいし、生体認証が行われてもよい。

表示処理部２３は、上述の第一実施形態における表示処理部１０１に相当する。表示処理部２３は、アクセス制御部２２により特定された公開レベルにより許可される配送単位の配送スケジュール情報のみを、その特定された公開レベルに対応するユーザ端末に表示させる。これにより、ユーザＩＤを用いて特定された公開レベルより高い公開レベルを示すデータレコードにより示される配送スケジュール情報は、ユーザ端末に表示されない。逆に、ユーザＩＤを用いて特定された公開レベル以下の公開レベルを示すデータレコードにより示される配送スケジュール情報はユーザ端末に表示される。

図７は、配送スケジュール情報の表示画面の一部の例を示す図である。例えば、表示処理部２３は、閲覧用の画面として、図７に示されるビューのように、配送単位の配送スケジュール情報を各行に表すリスト画面をユーザ端末に表示させる。なお、図７では、図面の大きさの制約から複数のデータ項目が省略されている。図７には、２つの配送単位が２行で表示されている。配送単位１は、２つの「製品１」が出荷元「千葉工場」から納入先「地方病院１」へ一度に配送されることを示す。即ち、配送単位１は、上述の（態様１）に相当する。一方、配送単位２は、出荷元「千葉工場」から「製品１」が出荷され、出荷元「兵庫工場」から「製品２」が出荷され、「製品１」及び「製品２」が末端拠点で合流して、納入先「地方病院２」へ一度に配送されることを示す。配送単位２は、２つの輸送ルートを含むため、上述の（態様２）に相当する。また、基本情報の空港名には「仙台空港」が２つ設定されているが、配送振替情報の振替空港には１つの「仙台空港」しか設定されていないため、当初、「製品１」も空輸を使って仙台空港に降り立つ予定であったところ、空輸を使わない輸送ルートに変更されている。

図７に示されるように、表示処理部２３は、単一の輸送ルートのみからなる配送単位だけでなく、複数の輸送ルートを含む配送単位についても一行に表示される。表示処理部２３は、一配送単位内の各輸送ルートの情報を、区分けされた行内の各行（各段）にそれぞれ表示する。図７の例では、出荷元「千葉工場」から出荷される「製品１」の輸送ルートは、「配送単位２」を表示する行内の上段に表示され、出荷元「兵庫工場」から出荷される「製品２」の輸送ルートは、同行内の下段に表示される。しかしながら、一配送単位に含まれる複数の輸送ルートの表示方法は、各輸送ルートを区別可能に表示されれば、特に制限されない。

図８は、関連画面の例を示す図である。図８に示されるように、表示処理部２３は、各納入先について、納入先名称及び後述の統計処理部２７によりカウントされた配送単位の数をそれぞれ示す画面をユーザ端末に表示させることもできる。この画面においてユーザ操作で一つの納入先が選択された場合に、表示処理部２３は、そのユーザ操作で選択された納入先を特定し、その特定された納入先に関する配送スケジュール情報のリスト画面をそのユーザ端末に表示させてもよい。

図９は、配送スケジュール情報の単票表示画面の例を示す図である。表示処理部２３は、図９に示されるように、配送単位毎に、単票形式で配送スケジュール情報を表示することもできる。また、表示処理部２３は、或る配送単位の配送スケジュール情報を編集するための画面として、図９に示される単票表示画面を表示してもよい。例えば、表示処理部２３は、上述のようなリスト表示画面において、ユーザ操作により対象の配送単位が選択され編集ボタンが押下された場合に、編集画面として、単票表示画面を表示する。

図１０は、配送スケジュール情報の更新履歴画面の一部の例を示す図である。図１０に示されるように、表示処理部２３は、更新されたデータ項目及び更新後のデータを識別可能な状態で、一配送単位の配送スケジュール情報の更新履歴をユーザ端末に表示させることもできる。図１０の例では、星マークが付されているデータ項目が更新されたことを示し、星マークが付されているデータ項目の値が更新後のデータを示す。但し、更新されたデータ項目及び更新後のデータを識別可能とする表示方法は制限されない。そのデータの文字の色を変えてもよいし、そのデータ項目の背景色を変えてもよい。なお、配送スケジュール情報の更新履歴は、後述の更新処理部２４により蓄積される。

更新処理部２４は、各ユーザ端末でのユーザ操作に起因して情報格納部２０に格納されているデータレコードを更新する。例えば、更新処理部２４は、図９に示される単票形式の画面に対するユーザ操作に応じて、変更対象の配送単位、データ項目、及び変更後のデータ（値）を取得し、情報格納部２０の中からその変更対象の配送単位を示すデータレコードを特定する。更新処理部２４は、この特定されたデータレコードの、当該変更対象のデータ項目を当該取得された変更後のデータに更新する。データレコードの更新をする度に、更新処理部２４は、更新されたデータレコードを時系列に別途蓄積する。この時系列に蓄積されたデータレコードを用いて、図１０に示される更新履歴画面が生成される。

通知部２６は、更新処理部２４により情報格納部２０内のデータレコードが更新された場合に、その更新されたデータレコードにより示される一配送単位の配送スケジュール情報の少なくとも一部を、更新されたデータ項目を区別可能な状態でユーザ端末に通知する。以降、この通知を更新通知と表記する。通知部２６は、更新された配送スケジュール情報の全部を通知してもよいし、一部を通知してもよい。通知部２６による通知手法は制限されない。通知部２６は、電子メール、ＳＮＳ等の通知機能、メッセージ、掲示板、チャット等、あらゆる通知手法を利用することができる。

通知部２６は、情報格納部２０に格納されるユーザと納入先との対応関係を示す情報を用いて、その更新されたデータレコードにより示される一配送単位の一納入先に対応付けられたユーザのアドレス情報をその更新通知の宛先として抽出する。

図１１は、更新通知の例を示す図である。図１１の例では、更新通知が電子メールで行われている。また、更新されたデータ項目には、他のデータ項目と区別可能となるように、「＊」が付されている。但し、更新されたデータ項目を他のデータ項目と区別し得る表示方法は制限されない。

更に、通知部２６は、後述の検出部２５により所定期間更新されていないことが検出された配送単位の配送スケジュール情報の更新を促す情報をユーザ端末に通知する。通知部２６は、更新を促す情報として、対象の配送単位の配送スケジュール情報を全て通知してもよいし、その情報の中の、他の配送単位と区別し得る代表的なデータ項目のデータのみを通知してもよい。また、通知部２６は、所定期間更新されていない旨を示す文字列や図形のみを通知してもよい。以降、この通知は、上述の更新通知と区別されるために、未更新通知と表記される。

この未更新通知は、更新を促すためのものであるため、第二実施形態では、未更新通知の宛先は、基本的には、ＴＣユーザとなる。未更新通知の宛先は固定的に決められていてもよい。また、配送単位毎に異なる運送会社が輸送を担当する場合には、情報格納部２０に格納されるデータレコードには運送会社のＩＤが格納される。そして、情報格納部２０は、運送会社ＩＤとそのＴＣユーザのアドレス情報とを対応付けて保持する。通知部２６は、このような情報を用いて、未更新通知の宛先を特定することが出来る。

通知部２６は、配送進捗状況情報の配送ステータスが完了（納品完了）を示す配送単位については、未更新通知及び更新通知の対象から除外する。即ち、通知部２６は、更新処理部２４により更新されたデータレコード内の配送ステータスが完了を示す場合には、そのデータレコードにより示される配送スケジュール情報の更新通知を行わない。また、通知部２６は、後述の検出部２５により所定期間更新されていないことが検出されたデータレコード内の配送ステータスが完了を示す場合には、そのデータレコードにより示される配送スケジュール情報の未更新通知を行わない。

検出部２５は、情報格納部２０に格納されるデータレコードの更新状況を監視することにより所定期間更新されていない配送単位を検出する。第二実施形態では、情報格納部２０に格納されるデータレコードが一配送単位を示すため、検出部２５は、所定期間更新されていないデータレコードを検出する。この所定期間は、顧客がトラブル発生時又は通常時に配送状況を確認したいと感じる時間幅に設定されることが望ましく、例えば、２０分に設定される。

統計処理部２７は、情報格納部２０に格納される複数のデータレコードを参照することにより、納入先毎の配送単位の数をカウントする。第二実施形態では、情報格納部２０に格納されるデータレコードが一配送単位を示すため、統計処理部２７は、納入先毎のデータレコード数を配送単位の数としてカウントする。

情報抽出部２９は、表示処理部２３、統計処理部２７等にとって所望のデータレコードを情報格納部２０から抽出する。また、情報抽出部２９は、通知部２６にとって所望の情報（宛先情報）を情報格納部２０から抽出する。例えば、情報抽出部２９は、表示処理部２３、通知部２６、統計処理部２７等の他の処理部から抽出条件（クエリ情報）を取得し、その抽出条件に対応するＳＱＬ文を情報格納部２０に対して発行する。表示処理部２３及び情報抽出部２９の組み合わせは表示処理手段と呼ぶことができ、統計処理部２７及び情報抽出部２９の組み合わせは統計処理手段と呼ぶことができ、通知部２６及び情報抽出部２９の組み合わせは通知手段と呼ぶことができる。

〔動作例／配送管理方法〕
以下、第二実施形態における配送管理方法について、図１２から図１５を用いて説明する。図１２は、第二実施形態における配送管理システム１の主な活用方法を示す図である。図１３、図１４及び図１５は、第二実施形態における配送管理サーバ１０の動作例を示すフローチャートである。図示されるように、第二実施形態における配送管理方法は、配送管理サーバ１０のような少なくとも１つのコンピュータにより実行される。例えば、図示される各工程は、配送管理サーバ１０が有する上述の各処理モジュールにより実行される。各工程は、配送管理サーバ１０が有する上述の各処理モジュールの処理内容と同様であるため、各工程の詳細は、適宜省略される。

まず、図１２を用いて、ＤＡユーザ、ＴＣユーザ及びＭＲユーザによる配送管理システム１の主な活用方法の例を説明する。

まず、ＤＡユーザは、配送状況を管理する必要のある出荷明細データを物流サーバ８に出力させ、そのデータを配送管理サーバ１０に取り込ませる（Ｓ１２１）。このとき、配送管理サーバ１０は、物流サーバ８から出力された出荷明細データファイルを参照して情報格納部２０に格納すべきデータレコードを生成し、生成されたデータレコードを情報格納部２０に格納する。これは、上述の取り込み部２１により行われる。ＤＡユーザは、各配送の輸送ルート及び配送スケジュールを設計し、手動で出荷明細データファイルを編集することもできる。情報格納部２０に新たに格納されたデータレコードには、非公開を示す公開レベルデータが設定される。

続いて、ＤＡユーザは、ＤＡ端末６を操作して、（Ｓ１２１）で新たに情報格納部２０に格納されたデータレコードが示す新たな配送スケジュール情報の公開レベルを非公開から非公開（調整）に変更する。この変更により、新たな配送スケジュール情報は、ＤＡユーザだけでなく、ＴＣユーザにも閲覧可能となる。但し、この状態では、ＭＲユーザは、当該新たな配送スケジュール情報を閲覧できない。

ＤＡユーザは、ＴＣユーザと協力しながら、新たな配送スケジュール情報に関し、輸送ルート及び配送スケジュール等を設計する（Ｓ１２２）。
ＤＡユーザ又はＴＣユーザは、（Ｓ１２２）で設計された情報に基づいて、ＤＡ端末６又はＴＣ端末７を操作して、当該新たな配送スケジュール情報を更新する（Ｓ１２３）。ここでは、配送スケジュール情報内の振替空港、搭載便名、各時間情報、振替担当店名等が変更される。

ＤＡユーザは、ＭＲユーザに混乱を生じさせない程度に配送スケジュール情報が固まったと判断すると、ＤＡ端末６を操作して、公開レベルを非公開（調整）から公開に変更する（Ｓ１２４）。これにより、ＭＲユーザもその配送スケジュール情報を閲覧可能となる。

以降、ＤＡユーザ、ＴＣユーザ及びＭＲユーザは、各自のユーザ端末５、６及び７を用いて、その配送スケジュール情報を適宜更新する（Ｓ１２５）。ここでは、配送スケジュール情報の配送振替情報の各時間情報及び配送進捗状況が主に更新される。例えば、空輸便の航空機が出発した場合には、ＤＡユーザ又はＴＣユーザは、配送振替情報の空港発に設定されていた時間をその実績時刻に更新する。また、ＴＣユーザは、自社の配送車の移動状況を把握して、配送進捗状況の配送ステータス、配送状況及び時刻を適宜更新する。

ＴＣユーザは、納入が完了すると、ＴＣ端末７を操作して、その配送スケジュール情報の配送ステータスを完了に更新し、実納入時間及び納入場所を実績で更新する（Ｓ１２６）。
このような各ユーザの利用に伴い、配送管理サーバ１０は、図１３、図１４及び図１５に示されるように動作する。

《閲覧時》
図１３のフローチャートは、各ユーザ端末が配送スケジュール情報を閲覧する際のフローを示す。上述のように、情報格納部２０にデータレコードが格納される状態で、配送管理サーバ１０は、ＭＲ端末５、物流部門端末６及び運送会社端末７からアクセスを受け付ける（Ｓ１３１）。このとき、配送管理サーバ１０は、アクセスしてきた各ユーザ端末からユーザＩＤをそれぞれ取得する。配送管理サーバ１０は、このユーザＩＤに基づいて、そのユーザの正当性を確認してもよい。

配送管理サーバ１０は、その取得されたユーザＩＤに対応する公開レベルを特定する（Ｓ１３２）。ユーザＩＤに対応する公開レベルの特定方法は上述したとおりである。

配送管理サーバ１０は、情報格納部２０に格納されるデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各ユーザ端末にそれぞれ表示させる（Ｓ１３３）。このとき、配送管理サーバ１０は、（Ｓ１２２）で特定された公開レベルにより許可される配送単位の配送スケジュール情報のみを、その特定された公開レベルに対応するユーザ端末に表示させる。第二実施形態では、配送管理サーバ１０は、公開レベルに基づいて、次のように配送スケジュール情報の閲覧制御を行う。配送管理サーバ１０は、公開レベルが非公開を示す配送スケジュール情報をＤＡユーザのＤＡ端末６のみに表示させる。配送管理サーバ１０は、公開レベルが非公開（調整）を示す配送スケジュール情報をＤＡユーザ及びＴＣユーザのＤＡ端末６又はＴＣ端末７に表示させる。配送管理サーバ１０は、公開レベルが公開を示す配送スケジュール情報をＭＲ端末５、ＤＡ端末６又はＴＣ端末７に表示させる。

（Ｓ１３３）において、配送管理サーバ１０は、各納入先について、納入先名称及び配送単位の数をそれぞれ示す画面をユーザ端末に表示させることもできる（図８参照）。また、配送管理サーバ１０は、図１４の（Ｓ１４２）で蓄積されるデータレコードを用いて、図１０に示されるような配送スケジュール情報の更新履歴画面をユーザ端末に表示させることもできる。

《データ更新時》
図１４のフローチャートは、ユーザ端末が配送スケジュール情報を更新する際のフローを示す。配送管理サーバ１０は、図１３に示される動作に並行して、図１４に示される動作を実行することができる。

配送管理サーバ１０は、各ユーザ端末でのユーザ操作に起因して情報格納部２０に格納されているデータレコードを更新する（Ｓ１４１）。例えば、データレコードを更新するためのユーザ操作は、図９に示される単票形式画面に対して行われる。図１２の（Ｓ１２１）の実行直後は、ＤＡユーザのみが更新可能であり、（Ｓ１２２）から（Ｓ１２４）の実行前までは、ＤＡユーザ及びＴＣユーザが更新可能であり、（Ｓ１２４）の実行後は、ＤＡユーザ、ＴＣユーザ及びＭＲユーザが更新可能となる。

配送管理サーバ１０は、更新後のデータレコードを蓄積する（Ｓ１４２）。この蓄積されたデータレコードを用いて、配送管理サーバ１０は、図１０に示される更新履歴画面を表示させることができる。但し、配送管理サーバ１０は、更新後のデータレコードではなく、常に、更新直前のデータレコードを蓄積するようにしてもよい。これによっても、同様に、更新履歴画面を表示することができる。

配送管理サーバ１０は、更新されたデータレコードの配送ステータスが納品完了を示しているか否かを判断する（Ｓ１４３）。配送ステータスが納品完了を示す場合（Ｓ１４３；ＹＥＳ）、配送管理サーバ１０は、処理を終える。一方、配送管理サーバ１０は、配送ステータスが納品完了を示さない場合（Ｓ１４３；ＮＯ）、更新されたデータレコードが示す納入先に対応付けられたユーザのアドレス情報を取得する（Ｓ１４４）。ユーザのアドレス情報及びその取得方法については上述したとおりである。

配送管理サーバ１０は、（Ｓ１４４）で取得されたアドレス情報を用いて、当該更新されたデータレコードにより示される配送スケジュール情報の少なくとも一部を、更新されたデータ項目を区別可能な状態でユーザ端末に通知する（Ｓ１４５）。これにより、ＭＲユーザは、納入完了が入力されるまで、（Ｓ１２５）が実行される度に、更新通知を受けることができる。配送管理サーバ１０は、ＭＲユーザに置き換えて又はＭＲユーザと共に、納入先（医療機関）のユーザ（端末）に対して更新通知を送信してもよいし、ＴＣユーザ又は運送会社の配送ドライバー（端末）に対して更新通知を送信してもよい。前者によれば、納入先である医療機関は、ＭＲユーザからの連絡を待たずに迅速に検査スケジュールを調整する等の対応が可能になる。後者によれば、配送ドライバーは自己の業務状況を確認するとともに納品先の医療機関に配送状況を迅速に連絡することができる。

《配送スケジュール情報が更新されない場合》
図１５のフローチャートは、配送スケジュール情報が所定期間更新されない場合のフローを示す。配送管理サーバ１０は、図１３及び図１４に示される動作に並行して、図１５に示される動作を実行することができる。

配送管理サーバ１０は、情報格納部２０に格納されるデータレコードの更新状況を監視する（Ｓ１５１）。これは、情報格納部２０に対する更新トランザクションを監視することで実現することができる。また、（Ｓ１４２）で示されるような更新に伴い蓄積されるデータレコードを確認することでも実現できる。

配送管理サーバ１０は、所定期間更新されていない配送単位を検出する（Ｓ１５２）。この所定期間については上述したとおりである（検出部２５）。配送管理サーバ１０は、所定期間更新されていない配送単位が検出されると（Ｓ１５２；ＹＥＳ）、更に、その配送単位の配送ステータスを確認する（Ｓ１５３）。配送管理サーバ１０は、その配送ステータスが納品完了を示さない場合（Ｓ１５３；ＮＯ）、ユーザ端末に、所定期間更新されていないことが検出された配送単位の配送スケジュール情報の更新を促す情報を通知する（Ｓ１５４）。第二実施形態では、未更新通知の宛先は、基本的には、ＴＣユーザとなる。

配送管理サーバ１０は、所定期間更新されていない配送単位が検出されていない場合（Ｓ１５２；ＮＯ）、及び所定期間更新されていない配送単位の配送ステータスが納品完了を示す場合（Ｓ１５２；ＹＥＳ）（Ｓ１５３；ＹＥＳ）、未更新通知（Ｓ１５４）を実行せず、処理を終える。

図１３、図１４及び図１５では、複数の工程（処理）が順番に表されているが、第二実施形態で実行される工程及びその工程の実行順序は、各図に示される例のみに限定されない。例えば、図１４の（Ｓ１４２）は、（Ｓ１４５）の後で実行されてもよい。また、図１５の（Ｓ１５３）は実行されなくてもよい。この場合、同図の（Ｓ１５１）は、配送ステータスが納品完了以外を示すデータレコードの更新状況を監視するようにすればよい。また、図１２に示される活用方法においても、（Ｓ１２２）及び（Ｓ１２３）は行われなくてもよい。

〔第二実施形態における作用及び効果〕
上述したように第二実施形態では、配送単位の配送スケジュール情報が一データレコードとして情報格納部２０に格納され、配送スケジュール情報が配送単位に区分けされて各ユーザ端末に表示される。これにより、複数の出荷元からの放射性医薬品が同時に一つの納入先（医療施設）に届けられる配送や、一つの出荷元から異なる時間に出荷された放射性医薬品が同時に一つの納品先（医療施設）に届けられる配送も、一配送単位として、区分け表示される。この区分け表示により、ＭＲユーザは、複雑な輸送ルートを含む配送であったとしても、自身が担当する納入先の医療機関に同時に納入される放射性医薬品の配送状況を容易に把握することができる。

更に、第二実施形態では、配送単位に対して公開レベルが設定され、ユーザ端末のユーザに関して特定された公開レベルにより許可される配送単位の配送スケジュール情報のみがそのユーザ端末に表示される。これにより、物流部門や運送会社による配送設計状況に応じて、顧客との接点となるＭＲユーザへの公開及び非公開を配送単位毎に制御することができる。従って、輸送ルートや配送スケジュールが頻繁に変更されるような状況をＭＲユーザに見せなくすることができ、そのような状況で顧客が混乱することを防ぐことができる。

第二実施形態では、配送単位の配送スケジュール情報は、ＭＲ端末５、ＤＡ端末６及びＴＣ端末７の各々により更新することもできる。よって、ＤＡユーザやＴＣユーザは、配送状況を逐次入力することができ、ＭＲユーザは、いつでも最新の配送状況を把握することができる。従って、第二実施形態によれば、物流部門の担当者による、運送会社からの電話連絡を受け、その連絡を納入先を担当する医薬情報担当者に更に連絡するといった煩雑な連絡の手間を省くことができる。結果、物流部門の担当者は、輸送ルート及び配送スケジュールの設計といった本来の業務に注力することができる。

更に、第二実施形態では、配送スケジュール情報が更新された場合、その更新された配送スケジュール情報の少なくとも一部が、更新されたデータ項目を区別可能な状態でユーザ端末に通知することができる。これにより、各ユーザは、他のユーザにより更新された配送スケジュール情報のデータ項目、即ち、最新の配送状況を即座に把握することができる。加えて、ユーザと納入先との対応関係を示す情報が情報格納部２０に格納されることにより、そのような更新通知の宛先を、更新された配送単位の納入先に対応付けられたユーザのみに制限することができる。例えば、更新通知の宛先を、更新された配送単位の納入先を担当するＭＲユーザのみに制限することができ、各ユーザに不要な多くの通知が届く事態を回避することができる。

更に、第二実施形態では、所定期間更新されていない配送単位が検出され、その検出された配送単位の配送スケジュールの更新を促す情報がユーザ端末に通知される。例えば、配送車が渋滞により長い時間一所に停滞している場合、ＴＣユーザは、配送状況が変わらないため、入力を控える可能性がある。しかしながら、そのような配送車の状況を知らない顧客は、その間、何の情報も得られない場合、不安になる可能性がある。第二実施形態によれば、上述の未更新通知により、配送の近況を知っているユーザ（例えば、ＴＣユーザ）に最新の配送状況の逐次入力を強制することができ、最新の配送状況をユーザ間で共有することができる。ひいては、顧客にも最新の配送状況を連絡することができ、顧客が不安となるのを防ぐことができる。一方で、配送ステータス情報が納品完了を示す配送単位については、上述のような更新通知及び未更新通知の対象から除外されるため、不要な通知をなくすことができる。

また、第二実施形態では、情報格納部２０内のデータレコードの更新情報を蓄積することで、一配送単位の配送スケジュール情報の更新履歴をユーザ端末に表示させることもできる。これにより、配送単位毎に、輸送ルートや配送スケジュールの変更や実績を後で振り返ることができ、その後の配送設計のスキルの向上に役立てることができる。

更に、第二実施形態では、情報格納部２０に格納されるデータレコードに基づいて、納入先毎の配送単位の数をカウントすることで、各納入先について、納入先名称及びそのカウントされた配送単位の数をそれぞれ示す画面をユーザ端末に表示させることもできる。この画面によれば、複数の納入先（医療機関）を担当する医薬情報担当者やその上司等が、留意すべき納入先毎の配送単位の数を容易に把握することができる。更に、この画面から納入先毎の配送スケジュール情報のリスト画面を表示させるようにすることもできる。

［変形例］
上述の第二実施形態では、情報格納部２０に格納される一データレコードが一配送単位を示したが、一データレコードは、一輸送ルートを示すようにしてもよい。この場合、上述の（態様２）及び（態様３）のような配送態様を持つ一配送単位は、複数のデータレコードにより示され、上述の内容は例えば次のように変形される。

情報格納部２０内の各データレコードは、属する配送単位を示す配送単位ＩＤをそれぞれ含む。各データレコードは公開レベルデータを持つ必要がなく、例えば、配送単位ＩＤとその配送単位の公開レベルを示す公開レベルデータとが対応付けられて情報格納部２０に格納される。また、配送単位ＩＤと配送ステータス情報とが対応付けられて情報格納部２０に格納される。検出部２５は、同一配送単位ＩＤを含む一以上のデータレコードの全てが所定期間更新されないことを以て、所定期間更新されていない配送単位を検出する。

また、第二実施形態では、特に言及されなかったが、配送スケジュール情報の一部は、ユーザ操作により更新されず、コンピュータ処理により更新されてもよい。例えば、空輸の出発時刻「空港発」や到着時刻「航空機着」については、配送管理サーバ１０が空輸会社のサーバから自動的に取得されたデータにより更新されてもよい。また、運送会社のサーバが各配送車の各拠点への実績到着時刻を管理し、更に、各配送車の位置から各拠点への到着時刻を予想する場合には、配送管理サーバ１０はそのサーバから各データを取得することもできる。また、運送会社のサーバが、配送担当が所持するハンディターミナルと通信することで、そのハンディターミナルにより読み取られた検品関連情報を取得することができる場合、配送管理サーバ１０は、その検品関連情報をそのサーバから取得することで、実納入時間等を自動で更新することもできる。この場合、配送管理サーバ１０は、配送担当が所持するハンディターミナルから検品関連情報を取得してもよい。更に、配送管理サーバ１０は、末端拠点の出発時刻「末端出発」から予想納入時間を予測し、その予測された時刻で更新してもよい。

また、通知部２６は、更新通知のタイミングを制御することもできる。通知部２６は、更新されたデータ項目の更新幅が所定幅を超える場合にのみ、更新通知を行うようにする。小さい更新幅で連続して情報が更新された場合に、都度、更新通知を受けたのでは、ユーザにとって煩わしい可能性がある。そこで、例えば、ジャスト５時から５時５分に「幹線出発」のデータ項目の値が更新された場合には、通知部２６は、その更新幅が５分であり、所定幅（例えば、１５分）を超えないため、更新通知を控える。通知部２６は、このような更新通知を行うための所定更新幅をデータ項目毎に保持することもできるし、出荷される放射性医薬品種毎に保持することもできる。放射性医薬品毎にその有効期間が異なるため、同じ遅延時間であっても、顧客の問題意識に違いが生じ得る。よって、有効期間が短い放射性医薬品の配送については、更新通知を行うための所定更新幅を、有効期間が長い放射性医薬品の配送よりも小さくする。また、通知部２６は、その所定更新幅を配送遅延度合により順次切り替えることもできる。例えば、通知部２６は、予想納入時間の、基本情報の納入時間（ＴＯ）に対する近さ、又は予想納入時間が納入時間（ＴＯ）を超えている時間を用いて配送遅延度合を決定することができる。通知部２６は、決定された配送遅延度合が大きい程、更新通知を行うための所定更新幅を小さく設定する。このようにすれば、ユーザが望む更新通知のみを通知することができる。

また、検出部２５は、未更新の検出タイミングを制御することもできる。即ち、検出部２５は、上記所定期間を動的に変更する。例えば、検出部２５は、出荷される放射性医薬品種毎に所定期間を変える。検出部２５は、効期間が短い放射性医薬品の配送については、所定期間を、有効期間が長い放射性医薬品の配送よりも短くすればよい。また、検出部２５は、その所定期間を配送遅延度合により順次切り替えることもできる。配送遅延度合の決定方法は上述のとおりである。検出部２５は、決定された配送遅延度合が大きい程、所定期間を短く設定する。このようにすれば、更新通知を受けるユーザには所望の通知のみを送ることができ、更新を要求されるユーザにとっては必要な更新のみを行えばよくなる。

上述の配送管理装置１００及び配送管理サーバ１０は、情報格納部１０２及び情報格納部２０を有さず、他のコンピュータが情報格納部１０２及び情報格納部２０を有してもよい。この場合。配送管理装置１００及び配送管理サーバ１０は、当該他のコンピュータにアクセスすることで、情報格納部１０２及び情報格納部２０を参照及び編集することができる。

また、上述の各実施形態及び各変形例は、内容が相反しない範囲で組み合わせることができる。

上記の各実施形態及び各変形例の一部又は全部は、以下のようにも特定され得る。但し、各実施形態及び各変形例が以下の記載に限定されるものではない。

１． 出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する情報格納手段と、
前記情報格納手段に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる表示処理手段と、
を備え、
前記表示処理手段は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す一配送単位の配送スケジュール情報を各クライアント装置にそれぞれ表示させる、
配送管理装置。
２． クライアント装置から送られるユーザ識別情報に基づいて、クライアント装置からのアクセスを制御するアクセス制御手段、
を更に備え、
前記情報格納手段は、配送単位に関して複数の公開レベルのいずれか１つを示す公開レベルデータを更に格納し、
前記アクセス制御手段は、前記ユーザ識別情報に対応する公開レベルを特定し、
前記表示処理手段は、前記特定された公開レベルにより許可される配送単位の配送スケジュール情報のみを前記クライアント装置に表示させる、
１．に記載の配送管理装置。
３． クライアント装置でのユーザ操作に起因して前記情報格納手段に格納されているデータレコードを更新する更新処理手段と、
前記更新処理手段により更新されたデータレコードにより示される一配送単位の配送スケジュール情報の少なくとも一部を、更新されたデータ項目を区別可能な状態で他のクライアント装置に通知する通知手段と、
を更に備える１．又は２．に記載の配送管理装置。
４． 前記情報格納手段は、ユーザと納入先との対応関係を示す情報を更に格納し、
前記通知手段は、前記情報格納手段を参照することにより、前記更新されたデータレコードにより示される前記一配送単位の一納入先に対応付けられたユーザのアドレス情報を前記通知の宛先として抽出する、
３．に記載の配送管理装置。
５． 前記情報格納手段に格納されるデータレコードの更新状況を監視することにより所定期間更新されていない配送単位を検出する検出手段、
を更に備え、
前記通知手段は、前記検出手段により前記所定期間更新されていないことが検出された配送単位の配送スケジュール情報の更新を促す情報をクライアント装置に通知する、
３．又は４．に記載の配送管理装置。
６． 前記情報格納手段は、配送単位に関して納品完了か否かを少なくとも示す配送ステータス情報を更に格納し、
前記通知手段は、前記配送ステータス情報が納品完了を示す配送単位については通知対象から除外する、
３．から５．のいずれか１つに記載の配送管理装置。
７． 前記表示処理手段は、更新されたデータ項目及び更新後のデータを識別可能な状態で、一配送単位の配送スケジュール情報の更新履歴をクライアント装置に表示させる、
３．から６．のいずれか１つに記載の配送管理装置。
８． 出荷される放射性医薬品、出荷元、納入先及び納入時間をそれぞれ示す複数の項目を少なくとも含む複数のレコードを格納するファイルから複数のレコードを読み取り、読み取られた複数のレコードを納入先及び納入時間でグルーピングすることにより、一納入先に同時に納品する配送単位のデータレコードを生成し、生成されたデータレコードを前記情報格納手段に格納する取り込み手段、
を更に備える１．から７．のいずれか１つに記載の配送管理装置。
９． 前記情報格納手段に格納される複数のデータレコードを参照することにより、納入先毎の配送単位の数をカウントする統計処理手段、
を更に備え、
前記表示処理手段は、各納入先について、納入先名称及び前記統計処理手段によりカウントされた配送単位の数をそれぞれ示す画面をクライアント装置に表示させる、
１．から８．のいずれか１つに記載の配送管理装置。

１０． 少なくとも一つのコンピュータにより実行される配送管理方法において、
出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する情報格納部を参照し、
前記情報格納部に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる、
ことを含み、
一配送単位の配送スケジュール情報は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す、
配送管理方法。
１１． 前記情報格納部は、配送単位に関して複数の公開レベルのいずれか１つを示す公開レベルデータを更に格納し、
前記配送管理方法は、
クライアント装置から送られるユーザ識別情報に対応する公開レベルを特定し、
前記特定された公開レベルにより許可される配送単位の配送スケジュール情報のみを前記クライアント装置に表示させる、
ことを更に含む１０．に記載の配送管理方法。
１２． クライアント装置でのユーザ操作に起因して前記情報格納部に格納されているデータレコードを更新し、
前記更新されたデータレコードにより示される一配送単位の配送スケジュール情報の少なくとも一部を、更新されたデータ項目を区別可能な状態で他のクライアント装置に通知する、
ことを更に含む１０．又は１１．に記載の配送管理方法。
１３． 前記情報格納部は、ユーザと納入先との対応関係を示す情報を更に格納し、
前記配送管理方法は、
前記情報格納部を参照することにより、前記更新されたデータレコードにより示される前記一配送単位の一納入先に対応付けられたユーザのアドレス情報を前記通知の宛先として抽出する、
ことを更に含む１２．に記載の配送管理方法。
１４． 前記情報格納部に格納されるデータレコードの更新状況を監視することにより所定期間更新されていない配送単位を検出し、
前記所定期間更新されていないことが検出された配送単位の配送スケジュール情報の更新を促す情報をクライアント装置に通知する、
ことを更に含む１２．又は１３．に記載の配送管理方法。
１５． 前記情報格納部は、配送単位に関して納品完了か否かを少なくとも示す配送ステータス情報を更に格納し、
前記配送管理方法は、
前記配送ステータス情報が納品完了を示す配送単位については通知対象から除外する、
ことを更に含む１２．から１４．のいずれか１つに記載の配送管理方法。
１６． 更新されたデータ項目及び更新後のデータを識別可能な状態で、一配送単位の配送スケジュール情報の更新履歴をクライアント装置に表示させる、
１２．から１５．のいずれか１つに記載の配送管理方法。
１７． 出荷される放射性医薬品、出荷元、納入先及び納入時間をそれぞれ示す複数の項目を少なくとも含む複数のレコードを格納するファイルから複数のレコードを読み取り、
前記読み取られた複数のレコードを納入先及び納入時間でグルーピングすることにより、一納入先に同時に納品する配送単位のデータレコードを生成し、
前記生成されたデータレコードを前記情報格納部に格納する、
ことを更に含む１０．から１６．のいずれか１つに記載の配送管理方法。
１８． 前記情報格納部に格納される複数のデータレコードを参照することにより、納入先毎の配送単位の数をカウントし、
各納入先について、納入先名称及び前記カウントされた配送単位の数をそれぞれ示す画面をクライアント装置に表示させる、
ことを更に含む１０．から１７．のいずれか１つに記載の配送管理方法。

１９． １０．から１８．のいずれか１つに記載の配送管理方法を少なくとも一つのコンピュータに実行させるプログラム。

１ 配送管理システム
５ 営業者端末（ＭＲ端末）
６ 物流部門端末（ＤＡ端末）
７ 運送会社端末（ＴＣ端末）
８ 物流サーバ
１０ 配送管理サーバ
１１ ＣＰＵ
１２ メモリ
２０、１０２ 情報格納部
２１ 取り込み部
２２ アクセス制御部
２３、１０１ 表示処理部
２４ 更新処理部
２５ 検出部
２６ 通知部
２７ 統計処理部
２８ 取込処理部
２９ 情報抽出部
１００ 配送管理装置

Claims (10)

1. 出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する情報格納手段と、
   前記情報格納手段に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる表示処理手段と、
   を備え、
   前記表示処理手段は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す一配送単位の配送スケジュール情報を各クライアント装置にそれぞれ表示させる、
   配送管理装置。
2. クライアント装置から送られるユーザ識別情報に基づいて、クライアント装置からのアクセスを制御するアクセス制御手段、
   を更に備え、
   前記情報格納手段は、配送単位に関して複数の公開レベルのいずれか１つを示す公開レベルデータを更に格納し、
   前記アクセス制御手段は、前記ユーザ識別情報に対応する公開レベルを特定し、
   前記表示処理手段は、前記特定された公開レベルにより許可される配送単位の配送スケジュール情報のみを前記クライアント装置に表示させる、
   請求項１に記載の配送管理装置。
3. クライアント装置でのユーザ操作に起因して前記情報格納手段に格納されているデータレコードを更新する更新処理手段と、
   前記更新処理手段により更新されたデータレコードにより示される一配送単位の配送スケジュール情報の少なくとも一部を、更新されたデータ項目を区別可能な状態で他のクライアント装置に通知する通知手段と、
   を更に備える請求項１又は２に記載の配送管理装置。
4. 前記情報格納手段は、ユーザと納入先との対応関係を示す情報を更に格納し、
   前記通知手段は、前記情報格納手段を参照することにより、前記更新されたデータレコードにより示される前記一配送単位の一納入先に対応付けられたユーザのアドレス情報を前記通知の宛先として抽出する、
   請求項３に記載の配送管理装置。
5. 前記情報格納手段に格納されるデータレコードの更新状況を監視することにより所定期間更新されていない配送単位を検出する検出手段、
   を更に備え、
   前記通知手段は、前記検出手段により前記所定期間更新されていないことが検出された配送単位の配送スケジュール情報の更新を促す情報をクライアント装置に通知する、
   請求項３又は４に記載の配送管理装置。
6. 前記情報格納手段は、配送単位に関して納品完了か否かを少なくとも示す配送ステータス情報を更に格納し、
   前記通知手段は、前記配送ステータス情報が納品完了を示す配送単位については通知対象から除外する、
   請求項３から５のいずれか１項に記載の配送管理装置。
7. 前記表示処理手段は、更新されたデータ項目及び更新後のデータを識別可能な状態で、一配送単位の配送スケジュール情報の更新履歴をクライアント装置に表示させる、
   請求項３から６のいずれか１項に記載の配送管理装置。
8. 出荷される放射性医薬品、出荷元、納入先及び納入時間をそれぞれ示す複数の項目を少なくとも含む複数のレコードを格納するファイルから複数のレコードを読み取り、読み取られた複数のレコードを納入先及び納入時間でグルーピングすることにより、一納入先に同時に納品する配送単位のデータレコードを生成し、生成されたデータレコードを前記情報格納手段に格納する取り込み手段、
   を更に備える請求項１から７のいずれか１項に記載の配送管理装置。
9. 前記情報格納手段に格納される複数のデータレコードを参照することにより、納入先毎の配送単位の数をカウントする統計処理手段、
   を更に備え、
   前記表示処理手段は、各納入先について、納入先名称及び前記統計処理手段によりカウントされた配送単位の数をそれぞれ示す画面をクライアント装置に表示させる、
   請求項１から８のいずれか１項に記載の配送管理装置。
10. 少なくとも一つのコンピュータにより実行される配送管理方法において、
    出荷される放射性医薬品、出荷元、納入先、末端拠点及び末端拠点を経由した出荷元から納入先までの輸送ルート上の拠点毎の時間をそれぞれ示す複数のデータ項目をそれぞれ少なくとも含む複数のデータレコードを格納する情報格納部を参照し、
    前記情報格納部に格納される少なくとも一つのデータレコードにより示される放射性医薬品の配送スケジュール情報を、一納入先に同時に納品する配送単位に区分けして、各クライアント装置にそれぞれ表示させる、
    ことを含み、
    一配送単位の配送スケジュール情報は、複数種の放射性医薬品、複数の出荷元、一納入先、一末端拠点及び一末端拠点を経由して複数の出荷元から一納入先までの複数の輸送ルート上の拠点毎の実績時間又は予想時間を示す、
    配送管理方法。

Images