JP2020166859A - 需要予測装置、需要予測方法、需要予測プログラム - Google Patents

Abstract

【課題】医薬品の需要を適切に予測することのできる需要予測装置、需要予測方法及び需要予測プログラムを提供すること。【解決手段】医薬品の需要を予測するための需要予測装置であって、医薬品の出庫情報を取得する出庫情報取得部と、出庫情報取得部で取得される医薬品の出庫の推移を学習する学習部と、学習部での学習結果に応じて医薬品の需要を予測する需要予測部と、を備える。【選択図】図１

Description

本発明は、需要予測装置、需要予測方法及び需要予測プログラムに関し、特に、医薬品の需要を予測するための需要予測装置、需要予測方法、および需要予測プログラムに関する。

医療機関はレセプト（診療報酬明細書）を支払機関（受診者が国民健康保険被保険者ならば国民健康保険団体連合会、それ以外の被保険者ならば都道府県の社会保険診療報酬支払基金）へ提出する事で、診療報酬を得ている。従来、明細書の作成には高度な専門知識と複雑な計算が必要であり、医療機関にとっては重い負担となっていたが、レセプトコンピュータ（以下、レセコンともいう）が登場し、始診療報酬点数を計算し、レセプトをオンラインで請求できるようになり、業務負担が大幅に改善されるようになった。

現在では、レセプトを提出するだけの機能に収まらなくなっており、調剤薬局における医薬品の在庫を管理する方法として、レセコンを用いた在庫管理方法が提案されている。例えば、特許文献１には、医療機関又は調剤薬局で消化された各医薬品の消化データが医薬品卸業務管理用コンピュータに通信手段（主にインターネット）を通して入力されており、医薬品卸業務管理用コンピュータは、消化データの時系列消化データを作成し、この時系列消化データを医薬品の消化間隔と消化量とによって、複数の消化パタンに分類し、複数に分類された消化パタンから各医薬品の最適な補充パタンを選択し、医療機関又は調剤薬局に補充される医薬品の補充量を算出して適正在庫を維持するようにした適正在庫管理方法が提案されている。

特開２００４−２８４６８９号公報

特許文献１に開示される適正在庫管理方法では、複数に分類された消化パタンには、消化間隔と消化量とに特徴を有しない医薬品をも分類する消化パタンが含まれており、各医薬品は、何れかの消化パタンに属し、医薬品の適正在庫を維持するための演算式により自動的に処理されて、補充量とが設定されるので、極めて種類の多い医薬品の一品毎の在庫管理が容易に実施できる作用を有するとしている。

しかしながら、特許文献１に開示される適正在庫管理方法では、消化パタンの分類が不十分であり、いまだ需要予測に改善の余地がある。

本発明は、上記課題を鑑みてなされたものであり、医薬品の需要を適切に予測することのできる需要予測装置、需要予測方法及び需要予測プログラムを提供することを目的とする。

上記の課題を解決すべく、本発明の需要予測装置は、医薬品の需要を予測するための需要予測装置であって、医薬品の出庫情報を取得する出庫情報取得部と、出庫情報取得部で取得される医薬品の出庫の推移を学習する学習部と、学習部での学習結果に応じて医薬品の需要を予測する需要予測部と、を備える。

本発明によれば、医薬品の需要を適切に予測することのできる需要予測装置、需要予測方法及び需要予測プログラムを提供することができる。

第１実施形態に係る在庫管理システム１の概略構成図である。 第１実施形態に係るユーザ端末３の構成及び機能の一例を示す図である。 第１実施形態に係るユーザ端末４の構成及び機能の一例を示す図である。 第１実施形態に係る需要予測サーバ５（需要予測装置）の構成及び機能の一例を示す図である。 第１実施形態に係る在庫管理システム１の処理を示すフローチャート図である（入庫処理）。 第１実施形態に係る在庫管理システム１の処理を示すフローチャート図である（適正在庫のアラート処理）。 第１実施形態に係る在庫管理システム１の処理を示すフローチャート図である（使用期限のアラート処理）。 第２実施形態に係る需要予測サーバ５（需要予測装置）の構成及び機能の一例を示す図である。 第２実施形態に係る在庫管理システム１の処理を示すフローチャート図である（予製オーダデータ生成処理）。

以下、図面を参照して本発明の各実施形態を説明する。なお、以下の説明では、本発明の需要予測装置、需要予測方法及び需要予測プログラムを、医薬品の在庫管理システムに適用した例について説明する。また、以下の説明では、レセプトを作成するためのレセプトコンピュータが出力する調剤実績データを出庫情報として取得する例について説明する。しかし、医薬品の入出庫情報を取得するための情報は調剤実績データだけに限られない。例えば、医薬品の包装に付された表示体（例えば、文字列、デザイン、ＧＳ１コード（例えば、ＧＴＩＮ（ＪＡＮコード標準タイプ（ＧＴＩＮ−１３）、ＪＡＮコード短縮タイプ（ＧＴＩＮ−８）、北米地域で利用されるＵ．Ｐ．Ｃ．（ＧＴＩＮ−１２）、集合包装用商品コード（ＧＴＩＮ−１４））や合成シンボル、製造番号、使用期限などの情報を含む）を読み取り入出庫情報として利用しても良いし、ユーザが、入出庫情報を入力するようにしてもよい。また、その他、監査システム、自動調剤機、電子カルテ、電子薬歴、電子お薬手帳などの他、店舗間移動や廃棄、医薬品の卸業者の納品データ（返品データを含む）など、外部のシステムから入出庫情報を取得するようにしてもよい。また、以下では、調剤薬局における需要予測及び在庫管理について説明するが、調剤薬局以外にも病院、診療所、介護老人保健施設、その他の医療を提供する施設など、医薬品を扱う全ての施設・機関（医薬品の卸業者、医薬品メーカーを含み、医療機関（医療法で定められた医療提供施設）に限られない）において適用可能である。

[第１実施形態]
初めに、図１を参照して在庫管理システム１の構成について説明する。在庫管理システム１は、レセコン２（レセプトコンピュータ）、ユーザ端末３、ユーザ端末４及び需要予測サーバ５（需要予測装置）などを備える。レセコン２、ユーザ端末３及びユーザ端末４は、需要予測サーバ５とネットワーク６を介して通信可能に接続されている。なお、在庫管理システム１が具備するレセコン２、ユーザ端末３、ユーザ端末４、需要予測サーバ５のそれぞれの数は任意である。ネットワーク６は、レセコン２、ユーザ端末３及びユーザ端末４が需要予測サーバ５と通信できればよく、どのような通信網で構成されていてもかまわない。また、ネットワーク６は、図示しないＷＥＢサイトと接続されており、需要予測サーバ５は、ネットワーク６を介してＷＥＢサイトへアクセスし、種々の情報を取得できるように構成されている。

（レセコン２）
レセコン２は、レセプト（診療報酬明細書）を作成するコンピュータであり、例えば、保険請求の為のレセプト作成、診療内容の入力、窓口会計（患者の支払い料金）の計算、処方箋の発行、処方使用量の管理、お薬手帳、薬剤情報の発行、領収書発行、明細型領収書発行などの機能を有する。レセプトには、患者情報及び処方内容が記載される。患者情報としては、例えば、診察日、保険者番号・保険証の記号番号、患者の名前、生年月日、性別、住所、医療機関、診療科、病名、診療日などの情報が記載され、処方内容としては、例えば、初診（再診）の回数および点数、指導の回数および点数、処方した医薬品の品目、用法および処方量（用量、数量）と点数、処置の回数および点数、検査の回数と点数、合計の請求点数（薬剤一部負担金額）などの情報が記載される。レセコン２は、これらの情報を調剤実績データ（出庫情報）として需要予測サーバ５へ送信する。

（ユーザ端末３）
ユーザ端末３は、例えば、調剤薬局に勤務するユーザが利用する端末（例えば、スマートフォン、タブレット型ＰＣなど）である。ユーザは、ユーザ端末３を利用して、店舗への医薬品の入出庫処理を行うことができる。ユーザ端末３に入力された医薬品の入庫情報は、調剤薬局の店舗の識別子（以下、店舗ＩＤともいう）とともに需要予測サーバ５へ送信される。ユーザ端末３の構成及び機能の詳細については後述する。なお、本実施形態では、ユーザ端末３が備えるカメラやバーコードリーダなどの装置（以下、撮像装置ともいう）で医薬品の包装に付された表示体を読み取ることで入出庫情報を入力してもよいし、ユーザが、ユーザ端末３の入力装置を操作して入出庫情報を入力するようにしてもよい。また、医薬品の卸業者の納品データを入庫データとしてもよい（返品データを含む）。この場合、外部より電子データとして提供される入出庫データを取り込むようにしてもよい。ユーザ端末３に入力された入出庫情報は、需要予測サーバ５へ送信される。ユーザ端末３の構成及び機能の詳細については後述する。

（ユーザ端末４）
ユーザ端末４は、ユーザが利用する端末であり、ユーザ端末４が配置された調剤薬局の医薬品の在庫量などを確認するための端末として機能する。ユーザは、ユーザ端末４で医薬品の在庫量が適正であるかを確認することができ、ユーザ端末４の医薬品の在庫量が適正でない場合、ユーザ端末４にアラートが提示される。また、ユーザは、ユーザ端末４を利用して、医薬品のうち新規患者（以下、新患ともいう）を考慮しない品目の入力を行うことができる。新患を考慮しない医薬費の品目としては、例えば、特定の症状にしか用いられない特殊な医薬品などが該当する。また、ユーザは、ユーザ端末４を利用して、医薬品の需要を予測する期間を入力することができる。また、ユーザは、ユーザ端末４を利用して、店舗情報（店舗名、住所、連絡先（電話番号、メールアドレスなど）など）を入力することができる。なお、本実施形態では、ユーザ端末３と、ユーザ端末４とを別の端末としているが、ユーザ端末３とユーザ端末４とを同一の端末としてもよい。ユーザ端末４の構成及び機能の詳細については後述する。

（需要予測サーバ５）
需要予測サーバ５は、調剤薬局の各店舗の医薬品の需要を予測する。なお、本実施形態では、需要予測サーバ５は、予測した需要に基づいて、調剤薬局の各店舗の医薬品の在庫管理も行う。具体的には、需要予測サーバ５は、ネットワーク６を介して、レセコン２から送信される調剤実績データを取得し、医薬品の品目ごとの出庫の推移を学習し、学習結果に応じて医薬品の品目ごとの需要を予測する。次いで需要予測サーバ５は、予測した医薬品の品目ごとの需要に応じて、医薬品の適正な在庫量（以下、適正在庫量ともいう）を品目ごとに算出する。また、需要予測サーバ５は、ネットワーク６を介して、ユーザ端末３から送信される医薬品の品目ごとの入出庫情報を取得して、医薬品の入庫量と出庫量との差分から、調剤薬局における医薬品の品目ごとの在庫量を算出し、算出された医薬品の品目ごとの在庫量が、適正在庫量の範囲内（適正在庫量との差異の上限と下限を個数で決めてもよいし、％できめてもよい）であるか否かを判定する。需要予測サーバ５は、判定結果に応じて、アラートを報知する。例えば、在庫量が適正在庫量に対して不足している場合は、在庫量が不足していることを報知したり、不足分の発注を行う。また、在庫量が適正在庫量に対して超過している場合は、超過していることを報知する。また、需要予測サーバ５は、医薬品の使用期限の切迫も報知する。需要予測サーバ５の構成及び機能の詳細については後述する。なお、本実施形態では、需要予測サーバ５が在庫管理も行う構成となっているが、需要予測の機能と、在庫管理の機能とを別のサーバで実現するようにしてもよい。例えば、需要予測サーバ５で医薬品の需要予測を行い、需要予測サーバ５とは異なる在庫管理サーバで在庫管理を行うようにしてもよい。

（ユーザ端末３の詳細）
図２（ａ）は、ユーザ端末３の構成の一例を示す図、図２（ｂ）は、ユーザ端末３の機能の一例を示す図である。図２（ａ）に示すように、ユーザ端末３は、通信ＩＦ３００Ａ、記憶装置３００Ｂ、入力装置３００Ｃ、表示装置３００Ｄ、撮像装置３００Ｅ及びＣＰＵ３００Ｆなどがバス（ＢＵＳ）などを介して接続された構成を備える。

通信ＩＦ３００Ａは、他の装置（本実施形態では、需要予測サーバ５）と通信するためのインターフェースである。記憶装置３００Ｂは、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの半導体記憶装置である。記憶装置３００Ｂには、店舗ＩＤ、在庫管理システム１に必要なプログラムなどが記憶されている。

店舗ＩＤは、店舗ごとに異なる識別子であり、ユーザ端末３から送信される情報に付与される。これにより、需要予測サーバ５は、受信した情報がどの店舗のユーザ端末３から送信されたものであるかを認識することができる。なお、店舗ＩＤは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスなどを利用してもよく、需要予測サーバ５がユーザ端末３を含む各ユーザ端末に対して付与するようにしてもよい。

入力装置３００Ｃは、例えば、タッチパネル、キーボード、マウスなどであり、ユーザは、入力装置３００Ｃを操作して、必要な情報を入力したり、撮像装置３００Ｅを利用して医薬品の包装に付された表示体を撮像したりすることができる。

表示装置３００Ｄは、例えば、液晶モニタや有機ＥＬモニタなどである。表示装置３００Ｄは、在庫管理システム１の利用に必要な画面を表示する。

撮像装置３００Ｅは、例えば、ＣＣＤ（電荷結合素子）イメージセンサやＣＭＯＳ（相補型ＭＯＳ）イメージセンサ等の個体撮像素子やバーコードスキャナである。ユーザは、撮像装置３００Ｅを利用して、販売対象である医薬品の包装体に付された表示体を撮像する。上述したように、この表示体には、ＧＴＩＮが含まれており、ＧＴＩＮには、事業者コード、商品アイテムコードなどの情報が含まれている。このため、表示体に含まれるＧＴＩＮを読み取ることで、どの事業者のどの商品かがわかるようになっている。

また、ＧＴＩＮの特徴として、1つの取引単位に対して1つのＧＴＩＮが設定される。例えば、２つの異なる商品（単品）や、ある商品の単品とケースのように取引単位として異なるものに、同一のＧＴＩＮを設定することはできない。つまり、レセコン２から送信される調剤実績データでは、医薬品の品目が同じであれば、包装量の異なる商品であっても同じ識別番号が付与されているため、包装量の異なる商品まで在庫を管理することが難しいが、ＧＴＩＮを読み取り、レセコンから出力される調剤実績データと照合することで、医薬品の品目が同じであって包装量の異なる商品についても在庫の管理が可能となる。

ＣＰＵ３００Ｆは、ユーザ端末３を制御し、図示しないＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を備えている。

図２（ｂ）に示すように、ユーザ端末３は、記憶装置制御部３０１、入力受付部３０２、表示装置制御部３０３、撮像装置制御部３０４、コード読取部３０５、送信部３０６及び受信部３０７などの機能を有する。なお、図２（ｂ）に示す機能は、ユーザ端末３のＲＯＭ（不図示）に記憶されたプログラムをＣＰＵ３００Ｆが実行することにより実現される。

記憶装置制御部３０１は、記憶装置３００Ｂを制御する。具体的には、記憶装置制御部３０１は、記憶装置３００Ｂを制御して情報の書き込みや読み出しを行う。

入力受付部３０２は、入力装置３００Ｃでの入力操作を受け付ける。

表示装置制御部３０３は、表示装置３００Ｄを制御する。具体的には、表示装置制御部３０３は、在庫管理システム１の利用に必要な画面などを表示装置３００Ｄに表示させる。

撮像装置制御部３０４は、撮像装置３００Ｅの撮像を制御する。

コード読取部３０５は、撮像装置３００Ｅを利用して撮像された医薬品の包装体に付された表示体を読み取る。また、コード読取部３０５は、読み取った表示体の情報に、読み取った日時の情報を入庫情報として付与する。

送信部３０６は、入力受付部３０２で受け付けられた情報などを需要予測サーバ５へ送信する。また、送信部３０６は、コード読取部３０５で読み取られたＧＴＩＮや使用期限、製造番号の情報及び読み取った日時の情報を入出庫情報として需要予測サーバ５へ送信する。なお、送信部３０６は、上記情報を送信する際に記憶装置３００Ｂに記憶されている店舗ＩＤを付与して需要予測サーバ５へ送信する。

受信部３０７は、需要予測サーバ５から送信される情報を受信する。

（ユーザ端末４の詳細）
図３（ａ）は、ユーザ端末４の構成の一例を示す図、図３（ｂ）は、ユーザ端末４の機能の一例を示す図である。図３（ａ）に示すように、ユーザ端末４は、通信ＩＦ４００Ａ、記憶装置４００Ｂ、入力装置４００Ｃ、表示装置４００Ｄ及びＣＰＵ４００Ｅがバス（ＢＵＳ）などを介して接続された構成を備える。

通信ＩＦ４００Ａは、他の装置（本実施形態では、需要予測サーバ５）と通信するためのインターフェースである。記憶装置４００Ｂは、例えば、ＨＤＤやＳＳＤなどの半導体記憶装置である。記憶装置４００Ｂには、店舗ＩＤ、在庫管理システム１に必要なプログラムなどが記憶されている。

入力装置４００Ｃは、例えば、マウス、キーボード、タッチパネルなどであり、ユーザは、入力装置４００Ｃを操作して、必要な情報を入力することができる。ユーザは、入力装置４００Ｃを操作して、新患を考慮しない医薬品の品目の情報の入力及び医薬品の需要を予測する期間の情報の入力を行うことができる。

表示装置４００Ｄは、例えば、液晶モニタや有機ＥＬモニタなどである。表示装置４００Ｄは、在庫管理システム１の利用に必要な画面などを表示する。

ＣＰＵ４００Ｅは、ユーザ端末４を制御し、図示しないＲＯＭ及びＲＡＭを備えている。

図３（ｂ）に示すように、ユーザ端末４は、記憶装置制御部４０１、入力受付部４０２、表示装置制御部４０３、送信部４０４及び受信部４０５などの機能を有する。なお、図３（ｂ）に示す機能は、ユーザ端末４のＲＯＭ（不図示）に記憶されたプログラムをＣＰＵ４００Ｅが実行することにより実現される。

記憶装置制御部４０１は、記憶装置４００Ｂを制御する。具体的には、記憶装置制御部４０１は、記憶装置４００Ｂを制御して情報の書き込みや読み出しを行う。

入力受付部４０２は、入力装置４００Ｃでの入力操作を受け付ける。入力受付部４０２は、例えば、ユーザが入力した新患を考慮しない医薬品の品目の情報及び医薬品の需要を予測する期間の情報を受け付ける。

表示装置制御部４０３は、表示装置４００Ｄを制御する。具体的には、表示装置制御部４０３は、在庫管理システム１の利用に必要な画面などを表示装置４００Ｄに表示させる。

送信部４０４は、入力受付部４０２で受け付けられた情報などを需要予測サーバ５へ送信する。なお、送信部４０４は、上記情報を送信する際に記憶装置４００Ｂに記憶されている店舗ＩＤを付与して需要予測サーバ５へ送信する。

受信部４０５は、需要予測サーバ５から送信される情報を受信する。

（需要予測サーバ５の詳細）
図４（ａ）は、需要予測サーバ５の構成の一例を示す図、図４（ｂ）は、需要予測サーバ５の機能の一例を示す図である。図４（ａ）に示すように、需要予測サーバ５は、通信ＩＦ５００Ａ、記憶装置５００Ｂ及びＣＰＵ５００Ｃがバス（ＢＵＳ）などを介して接続された構成を備える。また、需要予測サーバ５は、図示しないＲＴＣを備え、日時を計測する。

通信ＩＦ５００Ａは、他の装置（本実施形態では、レセコン２、ユーザ端末３及びユーザ端末４）と通信するためのインターフェースである。

記憶装置５００Ｂは、例えば、ＨＤＤやＳＳＤなどの半導体記憶装置である。記憶装置５００Ｂには、店舗情報（店舗名、住所、連絡先など）、入庫情報、出庫情報、在庫情報、在庫されている医薬品の使用期限、適正在庫量などの情報が店舗ごとに店舗ＩＤに関連付けて記憶されている。また、サーバＩＤ、需要予測プログラム及び在庫管理プログラムなどが記憶されている。

ここで、在庫情報は、後述の在庫量算出部５１０で算出される医薬品の品目ごとの在庫量である。また、使用期限は、後述の使用期限取得部５１１で取得される店舗に在庫されている各医薬品の使用期限である。また、適正在庫量は、後述の適正在庫量算出部５０９で算出される店舗の適正在庫量である。なお、店舗情報、入庫情報、出庫情報については既に説明したため重複する説明を省略する。

ＣＰＵ５００Ｃは、需要予測サーバ５を制御し、図示しないＲＯＭ及びＲＡＭを備えている。

図４（ｂ）に示すように、需要予測サーバ５は、受信部５０１、入庫情報取得部５０２、出庫情報取得部５０３、受付部５０４（第１，第２受付部）、天候情報取得部５０５、施設情報取得部５０６、学習部５０７、需要予測部５０８、適正在庫量算出部５０９、在庫量算出部５１０、使用期限取得部５１１、判定部５１２（第１，第２判定部）、アラート報知部５１３、記憶装置制御部５１４、発注部５１５及び送信部５１６などの機能を有する。なお、図４（ｂ）に示す機能は、需要予測サーバ５のＲＯＭ（不図示）に記憶された需要予測プログラム及び在庫管理プログラムをＣＰＵ５００Ｃが実行することにより実現される。

受信部５０１は、レセコン２、ユーザ端末３、ユーザ端末４から送信される情報を受信する。

入庫情報取得部５０２は、受信部５０１で受信した情報から、ユーザ端末３から送信された入庫情報を取得する。取得された入庫情報は、店舗ＩＤに関連付けて記憶装置制御部５１４により記憶装置５００Ｂに記憶される。

出庫情報取得部５０３は、受信部５０１で受信した情報から、レセコン２から送信された出庫情報を取得する。取得された出庫情報は、店舗ＩＤに関連付けて記憶装置制御部５１４により記憶装置５００Ｂに記憶される。

受付部５０４は、受信部５０１で受信した情報から、ユーザ端末４から送信された新患を考慮しない医薬品の品目の情報を受け付ける。また、受付部５０４は、受信部５０１で受信した情報から、ユーザ端末４から送信された医薬品の需要を予測する期間の情報を受け付ける。

天候情報取得部５０５は、ＷＥＢサイトにアクセスし、店舗住所の地域の天気、気圧、気温の少なくとも一方の情報を含む天候情報を日付情報とともに取得する。なお、この天候情報は、ユーザがユーザ端末４へ入力したものを利用するようにしてもよい。

施設情報取得部５０６は、ＷＥＢサイトにアクセスし、店舗周辺の施設情報、例えば、医療機関、学校、など、医薬品の需要に影響を有する施設の種別及び規模（人数など）の情報を取得する。店舗の住所は、店舗情報から取得できる。なお、この施設情報は、ユーザがユーザ端末４へ入力したものを利用するようにしてもよい。また、将来的に建築される施設の情報でもよい。

学習部５０７は、出庫情報取得部５０３で取得される各店舗の医薬品の出庫の推移を学習する。具体的には、学習部５０７は、以下の（１）から（５）の関係を学習する。なお、学習部５０７は、新たな入庫情報や出庫情報が取得されると下記（１）から（５）の関係を逐次学習する。

（１）学習部５０７は、調剤実績データに含まれる日付情報、患者情報、及び患者への医薬品の品目ごとの処方量の情報から、患者の来局間隔と該患者の医薬品の品目ごとの処方量との関係を学習する。これにより、後述の需要予測部５０８において、患者の来局間隔から前記患者の今後の来局予定を推定することが可能となる。そして、需要予測部５０８は、推定した患者の今後の来局予定に基づいて、医薬品の需要を予測する。

（２）学習部５０７は、調剤実績データに含まれる日付情報及び医薬品の品目ごとの処方量の情報から、医薬品の品目ごとの処方量と季節（春夏秋冬）との関係、換言すると、春（例えば、３月―５月）、夏（例えば、６月―８月）、秋（例えば、９月―１１月）、冬（例えば、１２月―２月）、のそれぞれについて、医薬品の品目ごとの処方量を学習する。これにより、後述の需要予測部５０８において、季節に基づいて、春、夏、秋、冬ごとの医薬品の需要を予測することができる。なお、四季（春夏秋冬）には、一般的に決まった区切りがないため、上記区切りはあくまで一例であり、春夏秋冬のそれぞれをいつからいつまでにするかは、任意に決めてもよい。

（３）学習部５０７は、天候情報取得部５０５で取得される天候情報（天気（例えば、晴れ、雨、霧など）、気圧、気温の情報）、調剤実績データに含まれる日付情報、及び医薬品の品目ごとの処方量の情報から、医薬品の品目ごとの処方量と天候との関係を学習する。これにより、後述の需要予測部５０８において、天候情報に基づいて、医薬品の需要を予測することができる。

（４）学習部５０７は、調剤実績データに含まれる日付情報、患者情報、及び患者への前記医薬品の品目ごとの処方量の情報から、新規患者の来局頻度（新規患者が来局する確率）と新規患者へ処方される医薬品の品目ごとの処方量との関係を学習する。これにより、後述の需要予測部５０８は、新規患者の来局頻度に基づいて、医薬品の需要を予測することができる。
なお、学習部５０７は、受付部５０４で受け付けられた医薬品の品目については、新患の来局頻度を考慮しない。換言すると、学習部５０７は、受付部５０４で受け付けられた医薬品の品目については、学習の際に、新規患者の来局頻度を考慮しない。これにより、特定の症状にしか用いられない特殊な医薬品などの過剰在庫が発生することを防止できる。

（５）学習部５０７は、施設情報取得部５０６で取得される施設情報（医療機関、学校など、医薬品の需要に影響を有する施設の種別及び規模の情報）、及び医薬品の品目ごとの処方量の情報から、施設情報と医薬品の品目ごとの処方量との関係、換言すると、どのような施設（種別と規模）があればどれだけ医薬品の需要があるかを医薬品の品目ごとに学習する。これにより、後述の需要予測部５０８は、施設情報に基づいて、医薬品の需要を予測することができる。この場合、需要予測部５０８は、将来、店舗の周辺に建設される予定の施設の種別及び規模から医薬品の品目ごとの需要を予測することが可能となる。

需要予測部５０８は、学習部５０７での学習結果に応じて各店舗の医薬品の需要を予測する。ここで、需要予測部５０８は、受付部５０４で受け付けられた医薬品の需要を予測する期間に基づいて、医薬品の需要を予測する。具体的には、需要予測部５０８は、受付部５０４で受け付けられた期間の医薬品の需要を品目ごとに予測する。

適正在庫量算出部５０９は、需要予測部５０８で予測される医薬品の需要に応じて、医薬品の適正在庫量を品目ごとに算出する。

在庫量算出部５１０は、入庫情報取得部５０２で取得される医薬品の入庫量と、出庫情報取得部５０３で取得される医薬品の出庫量との差分から、各店舗における医薬品の在庫量を品目ごとに算出する。

使用期限取得部５１１は、受信部５０１で受信した情報から、ユーザ端末３から送信された入庫情報から医薬品の使用期限と製造番号を取得する。

判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量の範囲内であるか否かを判定する。
より具体的には、判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量の範囲を超えているか、適正在庫量の範囲内であるか、適正在庫量の範囲未満であるかを判定する。
また、判定部５１２は、各店舗に在庫されている医薬品の使用期限までの期間が所定期間（例えば、使用期限まで１カ月、１週間など）内であるか否かを医薬品の品目ごとに判定する。具体的には、判定部５１２は、記憶装置５００Ｂに記憶されている各店舗の入庫情報に含まれている医薬品の使用期限と、現在日時とを比較し、医薬品の使用期限までの期間が所定期間内であるか否かを判定する。判定部５１２は、所定の周期で上記判定を行う。

アラート報知部５１３は、判定部５１２での判定結果に応じてアラートを報知する。具体的には、判定部５１２での判定結果が、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量の範囲内でない場合、その旨をアラートとして該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。
より具体的には、判定部５１２での判定結果が、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量の範囲を超えている場合、過剰在庫である旨（例えば、「品目○○の在庫量が、○○錠だけ適正在庫量を超えています」）のアラートを該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。
また、判定部５１２での判定結果が、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量の範囲未満である場合、在庫が足りない旨（例えば、「品目○○の在庫量が、○○錠だけ適正在庫量を下回っていましたので、発注しました。」）のアラートを該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。
また、アラート報知部５１３は、判定部５１２での判定結果が、各店舗に在庫されている医薬品の使用期限までの期間が所定期間内である場合、その旨をアラートとして該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。なお、予め登録された連絡先（例えば、メールアドレス等）にもアラートを送信するようにしてもよい。

記憶装置制御部５１４は、記憶装置５００Ｂを制御する。具体的には、記憶装置制御部５１４は、記憶装置５００Ｂを制御して情報の書き込みや読み出しを行う。

発注部５１５は、判定部５１２での判定結果が、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量を下回る場合、適正在庫量を下回った品目の医薬品を適正在庫量の上限となるまで発注する発注情報を医薬品の卸業者の端末へ送信するように送信部５１６へ指示する。なお、発注量は、予め医薬品の品目ごとに決めておいてもよい。また、発注部５１５は、医薬品の卸業者の端末以外に、近隣の調剤薬局の端末（例えば、ユーザ端末４）に対して発注情報を送信するように送信部５１６へ指示するようにしてもよい。

送信部５１６は、適正在庫量算出部５０９で算出された各店舗の医薬品の品目ごとの適正な在庫量、在庫量算出部５１０で算出された各店舗における品目ごとの医薬品の在庫量、アラート報知部５１３によるアラートを該当するユーザ端末４へ送信する。また、送信部５１６は、発注部５１５による医薬品の発注情報を医薬品の卸業者の端末や近隣の調剤薬局の端末（例えば、ユーザ端末４）へ送信する。

（在庫管理システム１の処理）
以下、図５から図７を参照して、第１実施形態に係る在庫管理システム１の処理について説明する。

（入庫処理）
初めに、在庫管理システム１の入庫処理の一例について図５を参照して説明する。

（ステップＳ１０１）
ユーザは、ユーザ端末３を利用して、入庫した医薬品の包装体を読み取る。具体的には、ユーザ端末３の撮像装置３００Ｅを入庫した医薬品の包装体にかざし、入力装置３００Ｃを操作して包装体に印字又は貼付された表示体を撮像する。ユーザによる撮像操作は入力受付部３０２で受け付けられ、撮像装置制御部３０４は、入力受付部３０２で受け付けられた撮像操作に基づいて、撮像装置３００Ｅを制御して撮影を行う。記憶装置制御部３０１は、撮影された画像（撮影画像）を記憶装置３００Ｂへ記憶する。

（ステップＳ１０２）
ユーザ端末３のコード読取部３０５は、記憶装置３００Ｂへ記憶された表示体の撮影画像から包装体に収納されている医薬品の品目（薬品名、メーカ名、販売会社名、ＧＴＩＮ、製造番号など）を読み取る。

（ステップＳ１０３）
ユーザ端末３のコード読取部３０５は、記憶装置３００Ｂへ記憶された表示体の撮影画像から包装体に収納されている医薬品の使用期限を取得する。

（ステップＳ１０４）
ユーザ端末３は、撮影回数に基づいて、各医薬品の入庫個数を取得する。なお、ユーザが入力した個数を取得するようにしてもよい。

（ステップＳ１０５）
ユーザ端末３の送信部３０６は、取得した医薬品の品目と個数、製造番号及び使用期限などの入庫情報に店舗ＩＤを付して需要予測サーバ５へ送信する。なお、ステップＳ１０１からＳ１０４に代えて手作業で入庫情報を作成するほか、医薬品の卸業者などから電子データとして提供される入庫情報を取得するなどしてもよい。

（ステップＳ１０６）
需要予測サーバ５の受信部５０１は、ユーザ端末３から送信される入庫情報及び店舗ＩＤを受信する。需要予測サーバ５の記憶装置制御部５１４は、受信部５０１で受信した入庫記録を店舗ＩＤに関連付けて記憶装置５００Ｂへ記憶する。

（適正在庫のアラート処理）
次に、在庫管理システム１の適正在庫のアラート処理の一例について図６を参照して説明する。なお、図６に示す適正在庫のアラート処理は、定期的及び／又は不定期（例えば、新たな入庫情報や出庫情報が取得された際や、受付部５０４で情報が受け付けられた際など）に実行される。

（ステップＳ２０１）
需要予測サーバ５の需要予測部５０８は、学習部５０７での学習結果に応じて各店舗の医薬品の需要を予測する。なお、需要予測部５０８は、受付部５０４で受け付けられた医薬品の需要を予測する期間に基づいて、医薬品の需要を予測する。

（ステップＳ２０２）
適正在庫量算出部５０９は、需要予測部５０８で予測される医薬品の需要に応じて、医薬品の適正な在庫量を品目ごとに算出する。

（ステップＳ２０３）
在庫量算出部５１０は、入庫情報取得部５０２で取得される医薬品の入庫量と、出庫情報取得部５０３で取得される医薬品の出庫量との差分から、各店舗における医薬品の在庫量を品目ごとに算出する。

（ステップＳ２０４）
判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された在庫量の範囲内であるか否かを判定する。判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された在庫量の範囲内にある場合（ＹＥＳ）、適正在庫のアラート処理を終了する。また、判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された在庫量の範囲内にない場合（ＮＯ）、ステップＳ２０５の処理へ移行する。

（ステップＳ２０５）
判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された在庫量の範囲内を超えているか、換言すると在庫量が過剰であるか否かを判定する。判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された在庫量の範囲を超えている場合（ＹＥＳ）、ステップＳ２０６の処理へ移行する。また、判定部５１２は、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された在庫量の範囲を超えていない場合（ＮＯ）、ステップＳ２０７の処理へ移行する。

（ステップＳ２０６）
アラート報知部５１３は、過剰在庫である旨（例えば、「品目○○の在庫量が、○○錠だけ適正在庫量を超えています」）のアラートを該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。このアラートは、ユーザ端末４の受信部４０５で受信され、表示装置制御部４０３により表示装置４００Ｄに表示される。なお、予め登録された連絡先（例えば、メールアドレス等）にもアラートを送信するようにしてもよい。

（ステップＳ２０７）
発注部５１５は、判定部５１２での判定結果が、在庫量算出部５１０で算出された医薬品の品目ごとの在庫量が適正在庫量算出部５０９で算出された適正在庫量を下回る場合、適正在庫量を下回った品目の医薬品を適正在庫量の上限となるまで発注する発注情報を医薬品の卸業者の端末へ送信するように送信部５１６へ指示する。送信部５１６は、発注部５１５による医薬品の発注情報を医薬品の卸業者の端末へ送信する。なお、医薬品の卸業者の端末以外に、近隣の調剤薬局の端末（例えば、ユーザ端末４）に対して発注情報を送信するようにしてもよい。

（ステップＳ２０８）
アラート報知部５１３は、在庫が足りない旨（例えば、「品目○○の在庫量が、○○錠だけ適正在庫量を下回っていましたので、発注しました。」）のアラートを該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。このアラートは、ユーザ端末４の受信部４０５で受信され、表示装置制御部４０３により表示装置４００Ｄに表示される。なお、予め登録された連絡先（例えば、メールアドレス等）にもアラートを送信するようにしてもよい。

（使用期限のアラート処理）
次に、在庫管理システム１の使用期限のアラート処理の一例について図７を参照して説明する。なお、図７に示す使用期限のアラート処理は、定期的及び／又は不定期（例えば、新たな入庫情報や出庫情報が取得された際や、受付部５０４で情報が受け付けられた際など）に実行される。

（ステップＳ３０１）
判定部５１２は、各店舗に在庫されている医薬品の使用期限までの期間が所定期間内であるか否かを医薬品ごとに判定する。具体的には、判定部５１２は、記憶装置５００Ｂに記憶されている各店舗の入庫情報に含まれている医薬品の使用期限と、現在日時とを比較し、医薬品の使用期限までの期間が所定期間内であるか否かを判定する。需要予測サーバ５は、医薬品の使用期限までの期間が所定期間内でない場合（ＮＯ）、使用期限のアラート処理を終了する。また、需要予測サーバ５は、医薬品の使用期限までの期間が所定期間内である場合（ＹＥＳ）、ステップＳ３０２の処理へ移行する。

（ステップＳ３０２）
アラート報知部５１３は、判定部５１２での判定結果が、各店舗に在庫されている医薬品の使用期限までの期間が所定期間内である場合、その旨をアラートとして該当する店舗のユーザ端末４へ送信するように送信部５１６へ指示する。このアラートは、ユーザ端末４の受信部４０５で受信され、表示装置制御部４０３により表示装置４００Ｄに表示される。なお、予め登録された連絡先（例えば、メールアドレス等）にもアラートを送信するようにしてもよい。

以上のように、需要予測サーバ５は、調剤薬局における医薬品の在庫を管理するための需要予測装置である。需要予測サーバ５は、医薬品の出庫情報を取得する出庫情報取得部５０３と、出庫情報取得部５０３で取得される医薬品の出庫の推移を学習する学習部５０７と、学習部５０７での学習結果に応じて医薬品の需要を予測する需要予測部５０８とを備えている。このため、医薬品の需要を適切に予測することができ、需要予測サーバ５を在庫管理に利用にした場合、医薬品の過剰在庫や欠品リスクを抑制して、各店舗にあった適正な在庫量を保つことができる。

また、需要予測サーバ５の出庫情報取得部５０３は、レセプトを作成するためのレセプトコンピュータや電子カルテなどが出力する調剤実績データを取得する。既に調剤薬局の各店舗、各医療機関に導入されているレセコンや電子カルテから出力される調剤実績データを利用するので、導入コストを抑制することができる。

また、需要予測サーバ５の学習部５０７は、調剤実績データに含まれる日付情報、患者情報、及び患者への医薬品の品目ごとの処方量の情報から、患者の来局間隔と該患者の医薬品の品目ごとの処方量との関係を学習する。このため、需要予測部５０８において、患者の来局予定に基づいて、医薬品の需要を予測することができる。

また、需要予測サーバ５の学習部５０７は、調剤実績データに含まれる日付情報及び医薬品の品目ごとの処方量の情報から、医薬品の品目ごとの処方量と季節との関係を学習する。このため、需要予測部５０８において、季節に基づいて、医薬品の需要を予測することができる。

また、需要予測サーバ５は、天気及び気温の少なくとも一方の情報を含む天候情報を日付情報とともに取得する天候情報取得部５０５を備えている。そして、需要予測サーバ５の学習部５０７は、天候情報取得部５０５で取得される天候情報、調剤実績データに含まれる日付情報、及び医薬品の品目ごとの処方量の情報から、医薬品の品目ごとの処方量と天候との関係を学習する。このため、需要予測部５０８は、天候に基づいて、医薬品の需要を予測することができる。

また、需要予測サーバ５の学習部５０７は、調剤実績データに含まれる日付情報、患者情報、及び患者への前記医薬品の品目ごとの処方量の情報から、新規患者の来局頻度と新規患者へ処方される医薬品の品目ごとの処方量との関係を学習する。このため、需要予測部５０８は、新規患者の来局頻度に基づいて、医薬品の需要を予測することができる。

また、需要予測サーバ５は、医薬品の品目を受け付ける受付部５０４（第１受付部）を備えている。そして、需要予測サーバ５の学習部５０７は、医薬品のうち受付部５０４で受け付けられた品目について、学習の際に新規患者の来局頻度を考慮しない。これにより、特定の症状にしか用いられない特殊な医薬品などの過剰在庫が発生することを防止できる。

また、需要予測サーバ５は、店舗周辺の施設情報を取得する施設情報取得部５０６を備えている。そして、需要予測サーバ５の学習部５０７は、施設情報取得部５０６で取得される施設情報、及び医薬品の品目ごとの処方量の情報から、施設情報と医薬品の品目ごとの処方量との関係を学習する。このため、需要予測部５０８は、施設情報に基づいて、医薬品の需要を予測することができる。

また、需要予測サーバ５は、医薬品の需要を予測する期間を受け付ける受付部５０４（第２受付部）を備えている。そして、需要予測サーバ５の需要予測部５０８は、受付部５０４で受け付けられた期間の医薬品の需要を予測する。このため、必要な在庫量を予測する期間を自由に変更することができ、利便性が向上する。

また、需要予測サーバ５は、医薬品の入庫情報を取得する入庫情報取得部５０２と、入庫情報取得部５０２で取得される医薬品の入庫量と、出庫情報取得部５０３で取得される医薬品の出庫量との差分から、医薬品の在庫量を算出する在庫量算出部５１０と、在庫量算出部５１０で算出された医薬品の在庫量が、適正在庫量算出部５０９で算出された在庫量の範囲内であるか否かを判定する判定部５１２と、判定部５１２での判定結果に応じて、アラートを報知するアラート報知部５１３とを備えている。このため、医薬品の過剰在庫や欠品リスクを防止して、各店舗にあった適正な在庫量を確保することができる。

また、需要予測サーバ５は、医薬品の使用期限を取得する使用期限取得部５１１と、使用期限までの期間が所定期間内であるか否かを判定する判定部５１２（第２判定部）と、判定部５１２での判定結果に応じて、アラートを報知するアラート報知部５１３とを備えている。このため、使用期限までの期間が所定期間内である医薬品を事前に知ることができ、該医薬品を必要としている他の店舗で利用したり、業者へ返品・転売することができ、使用期限が過ぎることによる損失が生じることを抑制することができる。

[第１実施形態の変形例]
また、需要予測サーバ５に調剤薬局、医療機関及び医薬品の卸業者の少なくとも１以上の休日情報を取得する休日情報取得部を備え、学習部５０７は、休日情報取得部で取得される休日情報、調剤実績データに含まれる日付情報、及び医薬品の品目ごとの処方量の情報から、休日情報と医薬品の品目ごとの処方量との関係を学習するようにしてもよい。これにより、需要予測部５０８において、休日情報に基づいて、医薬品の需要を予測することができる。なお、休日情報は、ユーザがユーザ端末４へ入力したものを利用するようにしてもよい。また、これら休日情報をもとに発注すべきタイミングと量をも考慮した発注を行うことができる。

また、ある患者に処方されていた医薬品が変更になった場合（例えば、ジェネリックに変更になった場合など）、需要予測部５０８は、前記患者に処方される医薬品の需要を変更後の医薬品で予測することが好ましい。

また、需要予測サーバ５の学習部５０７が医師毎に処方する医薬品の傾向（例えば、漢方薬を多く処方する医師であるなど）を学習するようにしてもよい。これにより、需要予測部５０８は、医師を考慮して、医薬品の需要を予測することができる。

また、外部システムから訃報情報を訃報情報取得部が取得して、訃報情報により死亡が確認された患者については、需要予測部５０８による医薬品の需要の予測から外すようにしてもよい。

また、需要予測部５０８は、疾患名を考慮して医薬品の需要を予測するようにしてもよい。疾患名から必要な医薬品の品目と用量や再度の来局確率が予めわかる為、疾患名と、必要な医薬品の品目及び用量、再度の来局確率を予め格納したデータベースを参照する等することにより、需要予測部５０８は、疾患名を考慮して医薬品の需要を予測することができる。なお、再度の来局確率は、例えば、急性か慢性かで異なる（急性の代表的なものは、例えば、インフルエンザであり、インフルエンザで来局した場合、基本的に再度の来局はない（再度の来局確率がゼロ又は非常に低い）と考えることができる。

[第２実施形態]
通常、医薬品の予製（来局と処方される医薬品が略確定している患者に対して、予め医薬品を調製しておくこと。慢性期や施設の患者に対して多く、調剤量も著しく多いこともあり処方箋を受け付けてから調剤を行うとその他の患者を長時間待たせてしまうため前もって空き時間に行われることが多い。）を行う場合、余剰在庫から必要な医薬品をピックアップして予製を行なっている。しかし上記第１実施形態では、需要予測部５０８を備え、医薬品の需要を予測しているため余剰在庫が略又はあまり生じないことから、医薬品の予製を行う際に、予製に必要な医薬品を揃えられない、又は仮に揃えられたとしても別の患者に対して欠品が発生してしまうという虞がある。本実施形態では、このような事態を回避できる実施形態について説明する。

図８は、第２実施形態に係る需要予測サーバ５（需要予測装置）の機能の一例を示す図である。なお、第２実施形態に係る需要予測サーバ５の構成は、図４（ａ）を参照して説明した第１実施形態に係る需要予測サーバ５と同じであるため、同一の符号を付して重複する説明を省略する。図８に示すように、需要予測サーバ５は、受信部５０１、入庫情報取得部５０２、出庫情報取得部５０３、受付部５０４（第１〜第３受付部）、天候情報取得部５０５、施設情報取得部５０６、学習部５０７、需要予測部５０８、適正在庫量算出部５０９、在庫量算出部５１０、使用期限取得部５１１、判定部５１２（第１，第２判定部）、アラート報知部５１３、記憶装置制御部５１４、発注部５１５、送信部５１６、履歴取得部５２１（履歴情報取得部）、予製オーダデータ生成部５２２などの機能を有する。なお、図８に示す機能は、需要予測サーバ５のＲＯＭ（不図示）に記憶された需要予測プログラム及び在庫管理プログラムをＣＰＵ５００Ｃが実行することにより実現される。

本実施形態では、需要予測サーバ５の記憶装置５００Ｂには、予製の履歴（以下、予製履歴ともいう）が記憶されている。予製履歴は、例えば、過去に行った予製の作成日付（以下、予製日ともいう）、予製に必要となった医薬品の品目とその数量、予製を行った患者ＩＤ、などの情報である。なお、予製履歴の情報は、必ずしも需要予測サーバ５の記憶装置５００Ｂに記憶されている必要はなく、ネットワーク６を介して接続された他のサーバ等に記憶されていてもよい。

履歴取得部５２１は、調剤実績データ（処方履歴、調剤実績データ）及び予製履歴の情報を取得する。なお、履歴取得部５２１は、レセコン２（レセプトコンピュータ）及び需要予測サーバ５以外から調剤実績データ及び予製履歴の情報を取得するようにしてもよい。

予製オーダデータ生成部５２２は、ユーザ端末３又はユーザ端末４から予製オーダデータ生成の申請（患者及び予製日の指定情報）が送信されると、指定された患者の調剤実績データ及び予製履歴の情報を、予製オーダデータ生成を申請したユーザ端末３又はユーザ端末４へ送信する。
また、予製オーダデータ生成部５２２は、ユーザ端末３又はユーザ端末４から送信された予製オーダデータ生成の申請内容（医薬品等の情報）に基づいて、医薬品を発注するためのデータ（予製オーダデータ）を生成する。

（在庫管理システム１の処理）
以下、図９を参照して、第２実施形態に係る在庫管理システム１の処理について説明する。

（予製オーダデータ生成処理）
在庫管理システム１の予製オーダデータ生成処理の一例について図９を参照して説明する。
（ステップＳ４０１）
需要予測サーバ５の受付部５０４（第３受付部）は、予製オーダデータ生成の申請（患者及び予製日の指定情報）を受け付ける。

（ステップＳ４０２）
需要予測サーバ５の予製オーダデータ生成部５２２は、受付部５０４で予製オーダデータ生成の申請（患者及び予製日の指定情報）が受け付けられると、指定された患者の調剤実績データ及び予製履歴の情報を、予製オーダデータ生成を申請したユーザ端末３又はユーザ端末４へ送信する。送信された情報は、ユーザ端末３の表示装置３００Ｄ又はユーザ端末４の表示装置４００Ｄに表示される。なお、提示される履歴情報は、前回分だけを提示してもよいし、複数回分を提示するようにしてもよい。また、所定期間分の履歴情報を提示してもよいし、ユーザが回数や期間を指定できるように構成してもよい。

（ステップＳ４０３）
ユーザは、提示された履歴情報を必要に応じて変更する操作を行う。具体的には、ユーザは、提示された履歴情報の内容を必要に応じて変更する。この変更には、例えば、医薬品の変更（例えば、効果・効能が同じ他の医薬品（例えば、ジェネリック医薬品）に切り替える場合など）、用法（服薬方法の変更など）および処方量（用量、数量）の変更、医薬品の追加、医薬品の削除などが含まれる。変更内容は、ネットワーク６を介して需要予測サーバ５へ送信され、需要予測サーバ５の受付部５０４で受け付けられる。

（ステップＳ４０４）
需要予測サーバ５の予製オーダデータ生成部５２２は、受付部５０４で受け付けられた情報（変更内容）に基づいて、発注用データである予製オーダデータを生成する。この予製オーダデータには、予製に必要な医薬品（品目）とその数量及び予製日の情報が含まれる。
なお、発注部５１５は、予製オーダデータ生成部５２２により生成された予製オーダデータに基づいて、発注情報を医薬品の卸業者の端末へ送信するように送信部５１６へ指示する。また、発注部５１５は、医薬品の卸業者の端末以外に、近隣の調剤薬局の端末（例えば、ユーザ端末４）に対して発注情報を送信するように送信部５１６へ指示するようにしてもよい。なお、発注部５１５は、予製オーダデータに含まれる予製日前に予製に必要な医薬品の在庫が確保されるように、発注を行う。

なお、上記説明では患者を指定して患者ごとに予製オーダデータを生成しているが、医薬品の変更、削除、用法および処方量の変更などは、患者ごとではなく一括して行うことができるように構成しても良い。例えば、同じ医薬品が複数の患者の予製に使用されており、この医薬品を変更する場合、患者ごとに医薬品の変更を行うのは大変であるが、一括して医薬品を変更できるため利便性が向上する。

また、需要予測サーバ５の受付部５０４は、予製から除外する患者や医薬品を受け付けるようにしてもよい。予製オーダデータ生成部５２２は、受付部５０４で受け付けられた患者や医薬品を予製オーダデータの生成から除外する。このように、予製の必要が無くなった患者や医薬品（例えば、該患者が完治、引っ越し、死去した場合、医薬品の場合は、頓服のような性質のものや高額なもの、その他特殊な医薬品など）を除外して予製オーダデータを生成すれば利便性が向上する。

また、履歴情報（調剤実績データ及び予製履歴）に基づいて、予製オーダデータを作成すべき患者や予製に必要な医薬品の品目とその数量を予測し、提示する（リコメンドする）構成としてもよい。具体的には、需要予測サーバ５に予製予測部を備える。予製予測部は、履歴情報に含まれる日付情報、患者情報に基づいて、患者の来局間隔と該患者の医薬品の品目ごとの処方量、用法等の関係を学習し、次回来局予定日を予測する。次いで、該予測された患者の次回来局予定時に必要となる医薬品の品目とその処方量、用法等を予測し、ユーザ端末３及びユーザ端末４の少なくとも一方に、予製オーダデータを作成すべき患者とその内容を、該次回来局予定日より一定期間前からリコメンド情報として提示することで、利便性が向上する。

[その他の実施形態]
上記第１，第２実施形態及び第１実施形態の変形例では、入庫情報として、ユーザ端末３の撮像装置で医薬品に付された表示体を読み取った情報を利用しているが、店舗の店員がユーザ端末３の入力装置３００Ｃを操作して入庫情報を入力する構成としてもよい。また、出庫情報として、レセコン２から出力される調剤実績データを利用しているが、店舗の店員がユーザ端末３の入力装置３００Ｃを操作して出庫情報を入力する構成としてもよい。また、監査システム、自動調剤機、電子カルテ、電子薬歴、電子お薬手帳などの他、店舗間移動や廃棄、医薬品の卸業者の納品データ（返品データを含む）など、外部のシステムから入出庫情報を取得するようにしてもよい。また、上記実施形態では、調剤薬局における需要予測及び在庫管理について説明したが、調剤薬局以外にも病院、診療所、介護老人保健施設、その他の医療を提供する施設など、医薬品を扱う全ての施設・機関（医薬品の卸業者、医薬品メーカーを含み、医療機関（医療法で定められた医療提供施設）に限らない）において適用可能である。

また、第１実施形態において、需要予測サーバ５の受付部５０４は、医薬品の変更を受け付け、医薬品の一括変更を受け付けた場合、変更対象の医薬品を変更後の医薬品に一括して変更し、需要予測部５０８は、変更後の内容で、学習部５０７での学習結果に応じて各店舗の医薬品の需要を予測するようにしてもよい。
また、需要予測サーバ５の受付部５０４は、医薬品の変更を受け付け、医薬品の個別変更を受け付けた場合、医薬品変更の対象となる患者を受け付け、受け付けた患者について、変更対象の医薬品を変更後の医薬品に一括して変更し、需要予測部５０８は、変更後の内容で、学習部５０７での学習結果に応じて各店舗の医薬品の需要を予測するようにしてもよい。

以上説明したように、本発明によれば、医薬品の需要を適切に予測することのできる需要予測装置、需要予測方法及び需要予測プログラムを提供することができる。

１ 在庫管理システム
２ レセコン（レセプトコンピュータ）
３ ユーザ端末
３００Ａ 通信ＩＦ
３００Ｂ 記憶装置
３００Ｃ 入力装置
３００Ｄ 表示装置
３００Ｅ 撮像装置
３００Ｆ ＣＰＵ
３０１ 記憶装置制御部
３０２ 入力受付部
３０３ 表示装置制御部
３０４ 撮像装置制御部
３０５ コード読取部
３０６ 送信部
３０７ 受信部
４ ユーザ端末
４００Ａ 通信ＩＦ
４００Ｂ 記憶装置
４００Ｃ 入力装置
４００Ｄ 表示装置
４００Ｆ ＣＰＵ
４０１ 記憶装置制御部
４０２ 入力受付部
４０３ 表示装置制御部
４０４ 送信部
４０５ 受信部
５ 需要予測サーバ（需要予測装置）
５００Ａ 通信ＩＦ
５００Ｂ 記憶装置
５００Ｃ ＣＰＵ
５０１ 受信部
５０２ 入庫情報取得部
５０３ 出庫情報取得部
５０４ 受付部（第１〜第３受付部）
５０５ 天候情報取得部
５０６ 施設情報取得部
５０７ 学習部
５０８ 需要予測部
５０９ 適正在庫量算出部
５１０ 在庫量算出部
５１１ 使用期限取得部
５１２ 判定部（第１，第２判定部）
５１３ アラート報知部
５１４ 記憶装置制御部
５１５ 発注部
５１６ 送信部
５２１ 履歴取得部
５２２ 予製オーダデータ生成部
６ ネットワーク

Claims (20)

1. 医薬品の需要を予測するための需要予測装置であって、
   前記医薬品の出庫情報を取得する出庫情報取得部と、
   前記出庫情報取得部で取得される前記医薬品の出庫の推移を学習する学習部と、
   前記学習部での学習結果に応じて前記医薬品の需要を予測する需要予測部と、
   を備えることを特徴とする需要予測装置。
2. 前記学習部は、
   前記出庫情報に含まれる日付情報、患者情報、及び患者への前記医薬品の品目ごとの処方量の情報から、前記患者の来局間隔と該患者の前記医薬品の品目ごとの処方量との関係を学習し、
   需要予測部は、
   前記患者の来局予定に基づいて、前記医薬品の需要を予測することを特徴とする請求項１に記載の需要予測装置。
3. 前記学習部は、
   前記出庫情報に含まれる日付情報及び前記医薬品の品目ごとの処方量の情報から、前記医薬品の品目ごとの処方量と季節との関係を学習し、
   前記需要予測部は、
   前記季節に基づいて、前記医薬品の需要を予測することを特徴とする請求項１又は請求項２に記載の需要予測装置。
4. 天気及び気温の少なくとも一方の情報を含む天候情報を日付情報とともに取得する天候情報取得部を備え、
   前記学習部は、
   前記天候情報取得部で取得される天候情報、前記出庫情報に含まれる日付情報、及び前記医薬品の品目ごとの処方量の情報から、前記医薬品の品目ごとの処方量と前記天候との関係を学習し、
   前記需要予測部は、
   前記天候情報に基づいて、前記医薬品の需要を予測することを特徴とする請求項１乃至請求項３のいずれかに記載の需要予測装置。
5. 前記学習部は、
   前記出庫情報に含まれる日付情報、患者情報、及び患者への前記医薬品の品目ごとの処方量の情報から、新規患者の来局頻度と前記新規患者へ処方される前記医薬品の品目ごとの処方量との関係を学習し、
   前記需要予測部は、
   前記新規患者の来局頻度に基づいて、前記医薬品の需要を予測することを特徴とする請求項１乃至請求項４のいずれかに記載の需要予測装置。
6. 前記医薬品の品目を受け付ける第１受付部を備え、
   前記学習部は、
   前記医薬品のうち前記第１受付部で受け付けられた品目について、前記学習の際に、前記新規患者の来局頻度を考慮しないことを特徴とする請求項５に記載の需要予測装置。
7. 調剤薬局、医療機関及び前記医薬品の卸業者の少なくとも１以上の休日情報を取得する休日情報取得部を備え、
   前記学習部は、
   前記休日情報取得部で取得される前記休日情報、前記出庫情報に含まれる日付情報、及び前記医薬品の品目ごとの処方量の情報から、前記休日情報と前記医薬品の品目ごとの処方量との関係を学習し、
   前記需要予測部は、
   前記休日情報に基づいて、前記医薬品の需要を予測することを特徴とする請求項１乃至請求項６のいずれかに記載の需要予測装置。
8. 店舗周辺の施設情報を取得する施設情報取得部を備え、
   前記学習部は、
   前記施設情報取得部で取得される前記施設情報、及び前記医薬品の品目ごとの処方量の情報から、前記施設情報と前記医薬品の品目ごとの処方量との関係を学習し、
   前記需要予測部は、
   前記施設情報に基づいて、前記医薬品の需要を予測することを特徴とする請求項１乃至請求項７のいずれかに記載の需要予測装置。
9. 前記医薬品の需要を予測する期間を受け付ける第２受付部を備え、
   前記需要予測部は、
   前記第２受付部で受け付けられた期間の前記医薬品の需要を予測することを特徴とする請求項１乃至請求項８のいずれかに記載の需要予測装置。
10. 前記医薬品の入庫情報を取得する入庫情報取得部と、
    前記入庫情報取得部で取得される前記医薬品の入庫量と、前記出庫情報取得部で取得される前記医薬品の出庫量との差分から、前記医薬品の在庫量を算出する在庫量算出部と、
    前記在庫量算出部で算出された前記医薬品の在庫量が、前記適正在庫量算出部で算出された在庫量の範囲内であるか否かを判定する判定部と、
    前記判定部での判定結果に応じて、アラートを報知するアラート報知部と、
    を備えることを特徴とする請求項１乃至請求項９のいずれかに記載の需要予測装置。
11. 訃報情報を取得する訃報情報取得部を備え、
    前記需要予測部は、
    前記訃報情報取得部により取得された訃報情報により死亡が確認された患者については、前記医薬品の需要の予測から除外することを特徴とする請求項１乃至請求項１０のいずれかに記載の需要予測装置。
12. 前記需要予測部は、前記出庫情報に含まれる疾患名に基づいて、前記医薬品の需要を予測することを特徴とする請求項１乃至請求項１１のいずれかに記載の需要予測装置。
13. 予製の履歴情報及び調剤実績情報の少なくとも一方の情報を取得する履歴情報取得部と、
    患者の指定を受け付ける第３受付部と、
    前記予製の履歴情報及び前記調剤実績情報の少なくとも一方から指定された前記患者の処方履歴を抽出し、前記患者の予製に必要な医薬品及び数量を発注するための予製オーダデータを生成する予製オーダデータ生成部と、
    を備えることを特徴とする請求項１乃至請求項１２のいずれかに記載の需要予測装置。
14. 前記予製オーダデータ生成部をユーザへ提示させる提示部を備え、
    前記第３受付部は、
    前記予製オーダデータの変更を受け付け、
    前記予製オーダデータ生成部は、
    前記第３受付部で受け付けた変更に基づいて、前記予製オーダデータを変更することを特徴とする請求項１３に記載の需要予測装置。
15. 前記第３受付部は、
    前記予製オーダデータの生成から除外する患者を受け付け、
    前記予製オーダデータ生成部は、
    前記第３受付部で受け付けられた患者を除外して、前記予製オーダデータを生成することを特徴とする請求項１４に記載の需要予測装置。
16. 前記第３受付部は、
    前記予製オーダデータの生成から除外する医薬品を受け付け、
    前記予製オーダデータ生成部は、
    前記第３受付部で受け付けられた医薬品を除外して、前記予製オーダデータを生成することを特徴とする請求項１４又は請求項１５に記載の需要予測装置。
17. 前記第３受付部は、
    前記医薬品の変更を受け付ける、
    前記予製オーダデータ生成部は、
    前記第３受付部で受け付けられた医薬品を一括して変更することを特徴とする請求項１４乃至請求項１６のいずれかに記載の需要予測装置。
18. 前記履歴取得部の情報に基づいて、予製オーダデータを作成すべき患者及び該患者の予製に必要な医薬品の品目とその処方量を予測する予製予測部を備え、
    前記予製予測部は、
    患者の来局間隔から前記患者の来局予定を推定し、該推定された前記患者の来局予定に応じて、一定期間前に該予製オーダデータを予測する作成を推奨することを特徴とする請求項１３乃至請求項１７のいずれかに記載の需要予測装置。
19. 医薬品の需要を予測するための需要予測方法であって、
    出庫情報取得部が、前記医薬品の出庫情報を取得する工程と、
    学習部が、前記出庫情報取得部で取得される前記医薬品の出庫の推移を学習する工程と、
    需要予測部が、前記学習部での学習結果に応じて前記医薬品の需要を予測する工程と、
    を有することを特徴とする需要予測方法。
20. 医薬品の需要を予測するための需要予測プログラムであって、
    コンピュータを、
    前記医薬品の出庫情報を取得する出庫情報取得部、
    前記出庫情報取得部で取得される前記医薬品の出庫の推移を学習する学習部、
    前記学習部での学習結果に応じて前記医薬品の需要を予測する需要予測部、
    として機能させることを特徴とする需要予測プログラム。

Images