ホーム > 特許ランキング > 楽天グループ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-10-30
(45)【発行日】2024-11-08
(54)【発明の名称】通知制御装置及び端末プログラム
(51)【国際特許分類】
G16H 20/10 20180101AFI20241031BHJP
【ＦＩ】
G16H20/10
【請求項の数】
11
(21)【出願番号】P 2023101782
(22)【出願日】2023-06-21
【審査請求日】2023-06-21
(73)【特許権者】
【識別番号】399037405
【氏名又は名称】楽天グループ株式会社
(74)【代理人】
【識別番号】110000958
【氏名又は名称】弁理士法人インテクト国際特許事務所
(74)【代理人】
【識別番号】100120189
【弁理士】
【氏名又は名称】奥 和幸
(74)【代理人】
【識別番号】100135518
【弁理士】
【氏名又は名称】青木 隆
(72)【発明者】
【氏名】金岡 尚利
(72)【発明者】
【氏名】山木 修一郎
(72)【発明者】
【氏名】椎葉 竜生
【審査官】早川 学
(56)【参考文献】
【文献】特開２０１９－０３２７７５（ＪＰ，Ａ）
【文献】特開２００５－２６６８５３（ＪＰ，Ａ）
【文献】特開２０１４－１９４７１６（ＪＰ，Ａ）
【文献】特開２００７－１２２１８３（ＪＰ，Ａ）
【文献】特開２００９－０３１８８９（ＪＰ，Ａ）
【文献】特開２００３－１０４５１０（ＪＰ，Ａ）
【文献】国際公開第２０２０／１６６１０２（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ１６Ｈ １０／００－８０／００
(57)【特許請求の範囲】
【請求項1】
調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得手段と、前記取得された薬情報により示される前記処方日数に応じた残日数を決定する決定手段と、
前記取得された薬情報により示される前記調剤日から経過した日数と前記決定された残日数との和が、前記取得された薬情報により示される前記処方日数となる通知日に、前記調剤された薬の残量の減少に関連する通知を実行させる通知制御手段と、
を備えることを特徴とする通知制御装置。
【請求項2】
前記決定手段は、前記通知日を更に決定し、前記決定された通知日に基づいて、前記通知を実行させるか否かを日ごとに判定する判定手段を更に備え、
前記通知制御手段は、前記通知を実行させると判定された場合、前記通知を実行させることを特徴とする請求項１に記載の通知制御装置。
【請求項3】
前記決定手段は、前記処方日数が所定の第１処方日数以上である場合に決定する前記残日数を、前記処方日数が前記第１処方日数未満である場合に決定する前記残日数よりも多くすることを特徴とする請求項１又は２に記載の通知制御装置。
【請求項4】
前記決定手段は、前記処方日数が所定の第１処方日数以上である場合、前記残日数を、所定の第１残日数及び該第１残日数よりも少ない所定の第２残日数に決定し、前記処方日数が前記第１処方日数未満である場合、前記残日数を前記第２残日数に決定し、前記通知制御手段は、前記残日数が前記第１残日数及び前記第２残日数に決定された場合、前記第１残日数に応じて定められる前記通知日及び前記第２残日数に応じて定められる前記通知日のそれぞれに、前記通知を実行させることを特徴とする請求項３に記載の通知制御装置。
【請求項5】
前記通知制御手段は、前記処方日数が、前記第１処方日数よりも少ない第２処方日数以上である場合、前記通知を出力し、前記処方日数が前記第２処方日数未満である場合、前記通知を実行させないことを特徴とする請求項３に記載の通知制御装置。
【請求項6】
前記調剤された薬の入手困難度を示す困難度情報を取得する困難度情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された困難度情報により示される前記入手困難度に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記入手困難度が所定度以上である場合に決定する前記残日数を、前記入手困難度が前記所定度未満である場合に決定する前記残日数よりも多くすることを特徴とする請求項１又は２に記載の通知制御装置。
【請求項7】
前記取得される薬情報は、前記薬を調剤した施設を更に示し、前記取得された薬情報により示される前記施設での前記調剤された薬の在庫量を特定可能な在庫情報を取得する在庫情報取得手段を更に備え、
前記決定手段は、前記処方日数に応じるとともに前記取得された在庫情報により特定される前記在庫量に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記在庫量が所定量未満である場合に決定する前記残日数を、前記在庫量が前記所定量以上である場合に決定する前記残日数よりも多くすることを特徴とする請求項１又は２に記載の通知制御装置。
【請求項8】
前記取得される薬情報は、前記薬を調剤した施設及び前記薬を処方した病院のうち少なくとも何れか一方の施設を更に示し、前記取得された薬情報により示される前記少なくとも何れか一方の施設の予約状況を示す予約状況情報であって、前記少なくとも何れか一方の施設の予約困難度を特定可能な予約状況情報を取得する予約状況情報取得手段を更に備え、
前記決定手段は、前記処方日数に応じるとともに前記取得された予約状況情報から特定される前記予約困難度に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記予約困難度が所定度以上である場合に決定する前記残日数を、前記予約困難度が前記所定度未満である場合に決定する前記残日数よりも多くすることを特徴とする請求項１又は２に記載の通知制御装置。
【請求項9】
前記通知制御手段は、前記調剤された薬の提供先のユーザの端末装置に前記通知を実行させることを特徴とする請求項１又は２に記載の通知制御装置。
【請求項10】
前記実行される通知は、前記薬の残量が少なくなったこと及び病院に行くことを勧めることのうち、少なくとも何れか一方を示す通知情報を出力することを含むことを特徴とする請求項１又は２に記載の通知制御装置。
【請求項11】
端末装置のコンピュータに、調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得手段と、
前記取得された薬情報を、所定の通知制御装置へ送信する薬情報送信手段と、
前記送信された薬情報を受信した前記通知制御装置から、前記端末装置のユーザ向けの通知を示す通知情報を受信する通知情報受信手段と、
前記通知情報受信手段により前記通知情報が受信されたとき、前記通知を実行する通知手段、
として機能させ、
前記通知制御装置は、前記端末装置から受信された前記薬情報により示される前記処方日数に応じた残日数を決定し、前記受信された薬情報により示される前記調剤日から経過した日数と前記決定された残日数との和が、前記受信された薬情報により示される前記処方日数となる通知日に、前記端末装置へ前記通知情報を送信することを特徴とする端末プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、調剤された薬の残量が減少することに応じて通知を行う方法に関する。
【背景技術】
【0002】
従来、処方若しくは調剤された薬を管理して、薬の残量が減少した場合に通知を行う技術が知られている。例えば、特許文献１には、処方箋情報に基づいて患者に薬を提供した薬局の薬局端末が、その薬についての服薬スケジュールを患者の携帯通信端末に送信し、携帯通信端末は、服薬スケジュールに基づいて、服薬タイミングになったと判定した場合、患者に服薬を指示することが開示されている。また、特許文献１には、携帯通信端末が、薬の残量から服用を指示した量を減算し、残量が所定量以下になった場合、処方箋情報の作成を依頼する旨の情報を、病院端末へ送信することが開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００５－２６６８５３号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、通知を行うタイミングを、画一的に薬の残量が所定量以下となったタイミングとすることは、必ずしも適切であるということはできない。例えば、調剤された薬の処方日数が多いほど、その薬の提供を受けたユーザは、継続してその薬を使用する必要性が高い傾向にある。すなわち、処方日数が多いほど、その薬を継続して入手する必要性が高い。提供された薬の処方日数が比較的に多く、それ故その薬の全量が多い場合、その全量に対して薬の残量が相当程度減少した段階で、通知が行われることになる。通知を受けた段階で、ユーザが再度薬を入手するための行動を起こしていたのでは、現在ユーザの手元にある薬が無くなるまでに次の薬を入手することができない可能性がある。その一方で、処方日数が比較的に少ない場合、提供された薬の全量に対して十分な量の薬が残っている段階で通知が行われてしまう。このタイミングでの通知は、効果的であるということはできない。
【0005】
本発明は以上の点に鑑みてなされたものであり、その課題の一例は、調剤された薬の処方日数に応じたタイミングで通知を行うことを可能とする通知制御装置及び端末プログラムを提供することにある。
【課題を解決するための手段】
【0006】
（適用例１）本適用例に係る通知制御装置は、調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得手段と、前記取得された薬情報により示される前記処方日数に応じた残日数を決定する決定手段と、前記取得された薬情報により示される前記調剤日から経過した日数と前記決定された残日数との和が、前記取得された薬情報により示される前記処方日数となる通知日に、前記調剤された薬の残量の減少に関連する通知を実行させる通知制御手段と、を備えることを特徴とする。
【0007】
本適用例によれば、調剤された薬の処方日数に応じた残日数が決定される。調剤日から処方日数後の日には、調剤されてユーザに提供された薬はなくなる予定である。調剤日から例えば何日か経過した日から、薬がなくなる予定の日までの日数が、決定された残日数となると、調剤された薬の残量の減少に関連する通知がその日に実行される。そのため、調剤された薬の処方日数に応じたタイミングで通知を行うことができる。
【0008】
（適用例２）本適用例に係る通知制御装置は、前記決定手段は、前記通知日を更に決定し、前記決定された通知日に基づいて、前記通知を実行させるか否かを日ごとに判定する判定手段を更に備え、前記通知制御手段は、前記通知を実行させると判定された場合、前記通知を実行させることを特徴とする。
【0009】
本適用例によれば、調剤日から経過した日数と残日数との和が処方日数となる通知日が決定される。決定された通知日に基づいて、通知を実行させるか否かが日ごとに判定される。これにより、通知日が到来したときに、通知が実行される。
【0010】
（適用例３）本適用例に係る通知制御装置は、前記決定手段は、前記処方日数が所定の第１処方日数以上である場合に決定する前記残日数を、前記処方日数が前記第１処方日数未満である場合に決定する前記残日数よりも多くすることを特徴とする。
【0011】
本適用例によれば、処方日数が所定の第１処方日数以上である場合、処方日数が第１処方日数未満である場合よりも、調剤日から処方日数後の日を基準としてより早いタイミングで通知が実行される。そのため、調剤された薬の処方日数に応じたタイミングで通知を行うことができる。
【0012】
（適用例４）本適用例に係る通知制御装置は、前記決定手段は、前記処方日数が所定の第１処方日数以上である場合、前記残日数を、所定の第１残日数及び該第１残日数よりも少ない所定の第２残日数に決定し、前記処方日数が前記第１処方日数未満である場合、前記残日数を前記第２残日数に決定し、前記通知制御手段は、前記残日数が前記第１残日数及び前記第２残日数に決定された場合、前記第１残日数に応じて定められる前記通知日及び前記第２残日数に応じて定められる前記通知日のそれぞれに、前記通知を実行させることを特徴とする。
【0013】
本適用例によれば、処方日数が第１処方日数以上である場合、調剤日からの処方日数後の日までに現時点で残された日数が第１残日数となる日に通知が実行される。その後、調剤日からの処方日数後の日までに現時点で残された日数が、処方日数が第１処方日数未満である場合に決定される第２残日数となる日に再度通知が実行される。そのため、一度通知が実行されたにも関わらずユーザが薬の入手を忘れていた場合に、そのことをユーザに思い出させることができる。
【0014】
（適用例５）本適用例に係る通知制御装置は、前記通知制御手段は、前記処方日数が、前記第１処方日数よりも少ない第２処方日数以上である場合、前記通知を出力し、前記処方日数が前記第２処方日数未満である場合、前記通知を実行させないことを特徴とする。
【0015】
本適用例によれば、処方日数が、第１処方日数よりも少ない所定の第２処方日数未満である場合、通知は実行されない。そのため、処方日数が少ないために必要性が低い通知をなくすことができる。
【0016】
（適用例６）本適用例に係る通知制御装置は、前記調剤された薬の入手困難度を示す困難度情報を取得する困難度情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された困難度情報により示される前記入手困難度に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記入手困難度が所定度以上である場合に決定する前記残日数を、前記入手困難度が前記所定度未満である場合に決定する前記残日数よりも多くすることを特徴とする。
【0017】
本適用例によれば、調剤された薬の入手困難度に更に応じて残日数が決定される。処方日数が同一である条件下においては、入手困難度が所定度以上である場合、入手困難度が所定度未満である場合よりも早いタイミングで通知が実行される。そのため、入手困難度がより高い薬について、その薬を次に入手する時期により余裕を持たせることで、その薬の入手を比較的に容易にすることができる。
【0018】
（適用例７）本適用例に係る通知制御装置は、前記取得される薬情報は、前記薬を調剤した施設を更に示し、前記取得された薬情報により示される前記施設での前記調剤された薬の在庫量を特定可能な在庫情報を取得する在庫情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された在庫情報により特定される前記在庫量に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記在庫量が所定量未満である場合に決定する前記残日数を、前記在庫量が前記所定量以上である場合に決定する前記残日数よりも多くすることを特徴とする。
【0019】
本適用例によれば、薬を調剤した施設におけるその薬の在庫量に更に応じて残日数が決定される。処方日数が同一である条件下においては、在庫量が所定量未満である場合、在庫量が所定量以上である場合よりも早いタイミングで通知が実行される。そのため、在庫量がより少ない薬について、その薬を次に入手する時期により余裕を持たせることで、在庫がある間にその薬を入手することができる可能性を高めることができる。
【0020】
（適用例８）本適用例に係る通知制御装置は、前記取得される薬情報は、前記薬を調剤した施設及び前記薬を処方した病院のうち少なくとも何れか一方の施設を更に示し、前記取得された薬情報により示される前記少なくとも何れか一方の施設の予約状況を示す予約状況情報であって、前記少なくとも何れか一方の施設の予約困難度を特定可能な予約状況情報を取得する予約状況情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された予約状況情報から特定される前記予約困難度に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記予約困難度が所定度以上である場合に決定する前記残日数を、前記予約困難度が前記所定度未満である場合に決定する前記残日数よりも多くすることを特徴とする。
【0021】
本適用例によれば、薬を調剤した施設及びその薬を処方した病院のうち少なくとも何れか一方の施設の予約困難度に更に応じて残日数が決定される。処方日数が同一である条件下においては、予約困難度が所定度以上である場合、予約困難度が所定度未満である場合よりも早いタイミングで通知が実行される。そのため、予約がより困難な施設又は病院について、その施設で次に薬を調剤させる時期又はその病院で次に診察させる時期により余裕を持たせることで、予約を比較的に容易にすることができる。
【0022】
（適用例９）本適用例に係る通知制御装置は、前記通知制御手段は、前記調剤された薬の提供先のユーザの端末装置に前記通知を実行させることを特徴とする。
【0023】
（適用例１０）本適用例に係る通知制御装置は、前記実行される通知は、前記薬の残量が少なくなったこと及び病院に行くことを勧めることのうち、少なくとも何れか一方を示す通知情報を出力することを含むことを特徴とする。
【0024】
（適用例１１）本適用例に係る端末プログラムは、端末装置のコンピュータに、調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得手段と、前記取得された薬情報を、所定の通知制御装置へ送信する薬情報送信手段と、前記送信された薬情報を受信した前記通知制御装置から、前記端末装置のユーザ向けの通知を示す通知情報を受信する通知情報受信手段と、前記通知情報受信手段により前記通知情報が受信されたとき、前記通知を実行する通知手段、として機能させ、前記通知制御装置は、前記端末装置から受信された前記薬情報により示される前記処方日数に応じた残日数を決定し、前記受信された薬情報により示される前記調剤日から経過した日数と前記決定された残日数との和が、前記受信された薬情報により示される前記処方日数となる通知日に、前記端末装置へ前記通知情報を送信することを特徴とする。
【発明の効果】
【0025】
本発明によれば、調剤された薬の処方日数に応じたタイミングで通知を行うことができる。
【図面の簡単な説明】
【0026】
【図1】一実施形態に係る通信システムＳの概要構成の一例を示す図である。
【図2】一実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。
【図3】健康管理サーバ１のデータベースに記憶される情報の例を示す図である。
【図4】一実施形態に係るユーザ端末２の概要構成の一例を示すブロック図である。
【図5】一実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。
【図6】処方日数と通知残日数との対応関係の一例を示す図である。
【図7】残量不足通知を行うタイミングの例を示す図である。
【図8】一実施形態に係るユーザ端末２におけるシステム制御部２１の機能ブロックの一例を示す図である。
【図9】残量不足通知メッセージの表示例を示す。
【図10】一実施形態に係る通信システムＳの処理例を示すシーケンス図である。
【図11】一実施形態に係るシステム制御部１１による通知日決定処理の一例を示すフローチャートである。
【図12】処方日数と通知残日数との対応関係の一例を示す図である。
【図13】残量不足通知を行うタイミングの例を示す図である。
【図14】一実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。
【図15】医薬品ＤＢ１４ｄに記憶される情報の一例を示す図である。
【図16】一実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。
【図17】処方日数と入手困難度との組み合わせと、通知残日数と、の対応関係の一例を示す図である。
【図18】一実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。
【図19】薬局ＤＢ１４ｅ及び在庫ＤＢ１４ｆに記憶される情報の一例を示す図である。
【図20】一実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。
【図21】処方日数と在庫量との組み合わせと、通知残日数と、の対応関係の一例を示す図である。
【図22】一実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。
【図23】病院ＤＢ１４ｇ、薬局予約状況ＤＢ１４ｈ、及び病院予約状況ＤＢ１４ｉに記憶される情報の一例を示す図である。
【図24】一実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。
【図25】処方日数と予約不可能率との組み合わせと、通知残日数と、の対応関係の一例を示す図である。
【発明を実施するための形態】
【0027】
［１．第１実施形態］
［１－１．通信システムの構成］
以下、図面を参照して本発明の実施形態について詳細に説明する。先ず、本実施形態に係る通信システムＳの構成及び機能概要について、図１を参照して説明する。図１は、本実施形態に係る通信システムＳの概要構成の一例を示す図である。図１に示すように、通信システムＳは、健康管理サーバ１と、複数のユーザ端末２と、を含んで構成される。健康管理サーバ１及び各ユーザ端末２はネットワークＮＷに接続される。ネットワークＮＷは、例えばインターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
［１－１．通信システムの構成］
以下、図面を参照して本発明の実施形態について詳細に説明する。先ず、本実施形態に係る通信システムＳの構成及び機能概要について、図１を参照して説明する。図１は、本実施形態に係る通信システムＳの概要構成の一例を示す図である。図１に示すように、通信システムＳは、健康管理サーバ１と、複数のユーザ端末２と、を含んで構成される。健康管理サーバ１及び各ユーザ端末２はネットワークＮＷに接続される。ネットワークＮＷは、例えばインターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
【0028】
健康管理サーバ１は、ユーザの健康管理に関する健康管理サービスを提供するための処理を実行するサーバ装置であってもよい。例えば、健康管理サーバ１は、薬局や病院で調剤されてユーザに提供された薬を服用（または使用）するタイミングとなったときに、ユーザへ服用を通知するための処理を行ってもよい。本実施形態においては、便宜上、主に内服薬が調剤されることを前提として説明を行うが、外用薬や注射薬が調剤されてもよい。また、健康管理サーバ１は、ユーザに提供された薬の残量が減少することに応じて、そのユーザへ通知するための処理を行ってもよい。この通知を、残量不足通知という。残量不足通知は、例えば薬の残量が減少することに関連する通知であってもよい。例えば、残量不足通知は、薬の残量が減少することそれ自体を示す通知であってもよいし、次の薬を処方してもらうために病院へ行くことを勧める旨の通知であってもよい。ユーザは、必要があれば、同じ薬又は次の診察で処方される薬を入手するための行動をとることとなる。その行動は、診察の予約、受診のための病院への通院若しくはオンラインでの受診、調剤の予約、服薬指導の予約、薬局での薬の受け取り若しくはオンラインでの薬の注文を含み得る。ここでの残量不足とは、薬を入手するための行動が遅れると、次の薬を入手する前に、現在ユーザの手元にある薬がなくなる可能性があるということを意味してもよい。健康管理サーバ１は、更に病院での診察の予約や薬局での調剤若しくは服薬指導の予約をオンラインで実現するための処理を行ってもよい。また更に、健康管理サーバ１は、オンラインでの診察や服薬指導を実現するための処理を行ってもよい。
【0029】
各ユーザ端末２は、健康管理サービスを利用可能なユーザが利用する端末装置であってもよい。各ユーザ端末２は、携帯可能な端末装置であってもよい。ユーザ端末２の例として、スマートフォン等の携帯電話機、タブレット式コンピュータ、ウェアラブルコンピュータ、ＰＤＡ（Personal Digital Assistant）等が挙げられる。各ユーザ端末２は、撮像部を備えてもよい。ユーザ端末２は、撮像部により、静止画や動画を撮像可能であってもよい。また、ユーザ端末２は、撮像部で二次元コードを撮像することにより、その二次元コードにエンコードされた情報を読み取り可能であってもよい。例えば、薬局等が、調剤した薬をユーザへ提供するとき、その薬に関する提供薬情報を示す二次元コードが印刷された紙片等もそのユーザへ提供してもよい。提供薬情報は、例えば処方内容を示す情報若しくは調剤された薬に関する情報であってもよい。ユーザ端末２は、読み取った提供薬情報を、健康管理サーバ１へ送信してもよい。各ユーザ端末２には、健康管理アプリのインストールが可能であってもよい。ユーザ端末２が健康管理アプリを実行することで、ユーザは健康管理サービスを利用可能であってもよい。或いは、ウェブブラウザで健康管理サービスのコンテンツを表示することを通じて、ユーザは健康管理サービスを利用可能であってもよい。
【0030】
［１－２．装置構成］
［１－２－１．健康管理サーバ］
次に、健康管理サーバ１の構成について、図２及び図３を参照して説明する。図２は、本実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。図２に示すように、健康管理サーバ１は、システム制御部１１と、システムバス１２と、入出力インタフェース１３と、記憶部１４と、通信部１５と、を備えている。システム制御部１１と入出力インタフェース１３とは、システムバス１２を介して接続されている。
［１－２－１．健康管理サーバ］
次に、健康管理サーバ１の構成について、図２及び図３を参照して説明する。図２は、本実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。図２に示すように、健康管理サーバ１は、システム制御部１１と、システムバス１２と、入出力インタフェース１３と、記憶部１４と、通信部１５と、を備えている。システム制御部１１と入出力インタフェース１３とは、システムバス１２を介して接続されている。
【0031】
システム制御部１１は、ＣＰＵ（Central Processing Unit）１１ａ、ＲＯＭ（Read Only Memory）１１ｂ、ＲＡＭ（Random Access Memory）１１ｃ等により構成されている。
【0032】
入出力インタフェース１３は、記憶部１４及び通信部１５とシステム制御部１１との間のインタフェース処理を行う。
【0033】
記憶部１４は、例えば、ハードディスクドライブ等により構成されている。この記憶部１４には、ユーザＤＢ１４ａ、提供薬情報ＤＢ１４ｂ、通知予定ＤＢ１４ｃ等のデータベースが記憶されてもよい。「ＤＢ」は、データベースの略語である。少なくとも一のデータベースは、健康管理サーバ１と異なるサーバ装置に記憶されてもよい。健康管理サーバ１は、そのサーバ装置を介してデータベースにアクセス可能であってもよい。
【0034】
図３は、健康管理サーバ１のデータベースに記憶される情報の例を示す図である。ユーザＤＢ１４ａには、健康管理サービスを利用可能な各ユーザに関するユーザ情報が記憶されてもよい。例えば、ユーザＤＢ１４ａには、ユーザ情報として、ユーザＩＤ、氏名、性別、生年月日、住所、及び電子メールアドレス等が、互いに関連付けて記憶されてもよい。ユーザＩＤは、ユーザを識別する識別情報である。
【0035】
提供薬情報ＤＢ１４ｂには、各ユーザ端末２から送信されてきた各提供薬情報が記憶されてもよい。例えば、提供薬情報ＤＢ１４ｂには、提供薬情報として、提供薬情報ＩＤ、ユーザＩＤ、処方病院名、処方日、診療科目名、調剤薬局名、調剤日、医薬品名、剤形、用法、１回量、及び処方日数等が、互いに関連付けて記憶されてもよい。提供薬情報ＩＤは、提供薬情報を識別する識別情報である。ユーザＩＤは、その提供薬情報を健康管理サーバ１へ送信してきたユーザを示す。提供薬情報ＩＤ及びユーザＩＤは、ユーザ端末２が提供薬情報を読み取った後にその提供薬情報に追加された情報であってもよい。その他の情報は、二次元コードをデコードすることにより得られた情報であってもよい。処方病院名は、調剤された薬を処方した病院の名称を示す。処方日は、その処方が行われた日付を示す。診療科目名は、その処方を行った診療科の名称を示す。調剤薬局名は、その薬を調剤した薬局の名称を示す。本実施形態は、薬を調剤する施設は薬局であることを前提としている。しかしながら、薬を調剤する施設は、処方された薬を調剤して外来患者に提供する病院を含んでもよい。その場合、例えば調剤薬局名はその病院の名称を示すことがあってもよい。調剤日は、その調剤が行われた日付を示す。医薬品名は、調剤された薬の名称を示す。剤形は、調剤された薬の形態を示す。用法は、その薬の服用方法を示す。例えば用法は、１日当たりの薬の服用回数、薬を服用するタイミング等を含んでもよい。１回量は、１回分の服用当たりのその薬の服用量を示す。処方日数は、提供された薬が何日分の薬であるかを示してもよい。或いは、処方日数は、その薬の残量がなくなるまでにその薬を服用可能な日数を示してもよい。処方日数は、全量とも呼ばれる。一度に複数の薬が調剤された場合、提供薬情報は、各薬について、医薬品名、剤形、用法、１回量及び処方日数を含んでもよい。ここで、処方日数が互いに異なる複数の薬が調剤された場合、健康管理サーバ１は、処方日数ごとに分けて提供薬情報を提供薬情報ＤＢ１４ｂに記憶させてもよい。
【0036】
通知予定ＤＢ１４ｃには、調剤されてユーザに提供された薬について残量不足通知を行う予定に関する通知予定情報が、提供薬情報ＤＢ１４ｂに記憶された提供薬情報ごとに記憶されてもよい。例えば、通知予定ＤＢ１４ｃには、通知予定情報として、提供薬情報ＩＤ、ユーザＩＤ、及び通知予定日等が、互いに関連付けて記憶されてもよい。提供薬情報ＩＤは、通知予定情報に対応する提供薬情報を示す。ユーザＩＤは、通知先のユーザを示す。通知予定日は、残量不足通知が行われることが予定されている日付を示す。
【0037】
記憶部１４には、更に、オペレーティングシステム、ＤＢＭＳ（Database Management System）、サーバプログラム等の各種プログラムが記憶されている。サーバプログラムは、健康管理サービスに関する処理をシステム制御部１１に実行させるプログラムである。サーバプログラムは、例えば、他の装置からネットワークＮＷを介して取得されるようにしてもよいし、磁気テープ、光ディスク、メモリカード等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【0038】
通信部１５は、例えばネットワークインタフェースカード等により構成されている。通信部１５は、ネットワークＮＷを介して、ユーザ端末２等と接続し、接続された装置との通信状態を制御する。
【0039】
［１－２－２．ユーザ端末］
次に、ユーザ端末２の構成について、図４を参照して説明する。図４は、本実施形態に係るユーザ端末２の概要構成の一例を示すブロック図である。図４に示すように、ユーザ端末２は、システム制御部２１と、システムバス２２と、入出力インタフェース２３と、記憶部２４と、通信部２５と、操作入力部２６と、表示部２７と、撮像部２８と、音声出力部２９と、振動部３０と、を備えている。システム制御部２１と入出力インタフェース２３とは、システムバス２２を介して接続されている。
次に、ユーザ端末２の構成について、図４を参照して説明する。図４は、本実施形態に係るユーザ端末２の概要構成の一例を示すブロック図である。図４に示すように、ユーザ端末２は、システム制御部２１と、システムバス２２と、入出力インタフェース２３と、記憶部２４と、通信部２５と、操作入力部２６と、表示部２７と、撮像部２８と、音声出力部２９と、振動部３０と、を備えている。システム制御部２１と入出力インタフェース２３とは、システムバス２２を介して接続されている。
【0040】
システム制御部２１は、ＣＰＵ２１ａ、ＲＯＭ２１ｂ、ＲＡＭ２１ｃ等により構成されている。
【0041】
入出力インタフェース２３は、記憶部２４、通信部２５、操作入力部２６、表示部２７、撮像部２８、音声出力部２９及び振動部３０と、システム制御部２１との間のインタフェース処理を行う。
【0042】
記憶部２４は、例えばソリッドステートドライブ等の不揮発性メモリにより構成されている。この記憶部２４には、例えばオペレーティングシステム、健康管理アプリ、ウェブブラウザ等のプログラムが記憶されてもよい。健康管理アプリは、例えば、健康管理サーバ１若しくはその他の所定のサーバ装置からネットワークＮＷを介して取得されるようにしてもよいし、磁気テープ、光ディスク、メモリカード等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【0043】
通信部２５は、例えばネットワークインタフェースカード等により構成されている。通信部２５は、ネットワークＮＷを介して健康管理サーバ１等と接続し、接続された装置との通信状態を制御する。
【0044】
操作入力部２６は、例えばタッチパネル、ボタン等により構成されている。操作入力部２６は、ユーザによる操作を受け付けて、その操作内容を示す信号をシステム制御部２１へ出力する。
【0045】
表示部２７は、例えば液晶パネル又は有機パネルやビデオＲＡＭ等に構成されている。表示部２７は、システム制御部２１による制御に基づいて、文字や画像等の情報を表示する。
【0046】
撮像部２８は、ＣＣＤ（Charge-Coupled Device）又はＣＭＯＳ（Complementary Metal-Oxide-Semiconductor）等のイメージセンサやレンズ等により構成されるカメラであってもよい。撮像部２８は、静止画や動画等の画像を撮像して、その画像の信号を、システム制御部２１へ出力する。
【0047】
音声出力部２９は、例えばスピーカ等により構成されている。音声出力部２９は、システム制御部２１から送信されてきた音声信号を音声に変換して、その音声を出力する。
【0048】
振動部３０は、バイブレーション機能を実現するメカニズムである。振動部３０は、ユーザ端末２を振動させる。
【0049】
［１－３．機能概要］
［１－３－１．健康管理サーバ］
次に、図５乃至図７を参照して、健康管理サーバ１におけるシステム制御部１１の機能概要について説明する。図５は、本実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。システム制御部１１は、ＣＰＵ１１ａが、サーバプログラムに含まれる各種プログラムコードを読み出し実行することにより、図５に示すように、薬情報取得部１１０１、残日数決定部１１０２、通知判定部１１０３、及び通知制御部１１０４等として機能してもよい。
［１－３－１．健康管理サーバ］
次に、図５乃至図７を参照して、健康管理サーバ１におけるシステム制御部１１の機能概要について説明する。図５は、本実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。システム制御部１１は、ＣＰＵ１１ａが、サーバプログラムに含まれる各種プログラムコードを読み出し実行することにより、図５に示すように、薬情報取得部１１０１、残日数決定部１１０２、通知判定部１１０３、及び通知制御部１１０４等として機能してもよい。
【0050】
薬情報取得部１１０１は、提供薬情報を取得してもよい。本実施形態においては、提供薬情報は少なくとも調剤日及び処方日数を含めばよい。薬情報取得部１１０１は、例えば、提供薬情報を取得したユーザ端末２から提供薬情報を取得してもよい。或いは、薬情報取得部１１０１は、薬局の薬剤師等が利用する図示せぬ端末装置から、その薬局が調剤した薬についての提供薬情報を取得してもよい。或いは、薬情報取得部１１０１は、病院の医師等が利用する図示せぬ端末装置から、その病院が処方した薬についての提供薬情報を取得してもよい。薬情報取得部１１０１は、取得した提供薬情報を、提供薬情報ＤＢ１４ｂに記憶させてもよい。
【0051】
残日数決定部１１０２は、薬情報取得部１１０１により取得された提供薬情報により示される処方日数に応じて、通知残日数を決定してもよい。例えば、提供薬情報により示される調剤日から処方日数後の日を、服用終了予定日という。ユーザは、調剤日に薬の服用を開始するか、調剤日の次の日に服用を開始すると想定される。従って、服用終了予定日の前日から服用終了予定日の当日までの間に、薬はなくなる。通知残日数は、服用終了予定日の何日前に残量不足通知を行うかを示してもよい。換言すると、通知残日数は、残量不足通知を行ってから、服用終了予定日までに残しておく日数を示してもよい。
【0052】
通知残日数は、例えば１日以上且つ処方日数未満であってもよい。また、処方日数が多くなるほど通知残日数が多くなってもよい。例えば通知残日数は、処方日数が多くなるに従って段階的に多くなってもよい。残日数決定部１１０２は、例えば処方日数が所定数以上である場合に決定する通知残日数を、処方日数が所定数未満である場合に決定する通知残日数よりも多くしてもよい。例えば、残日数決定部１１０２は、処方日数が所定の第１処方日数以上である場合、通知残日数を所定の第１残日数に決定してもよい。また、残日数決定部１１０２は、処方日数が第１処方日数未満である場合、通知残日数を、所定の第２残日数に決定してもよい。ここで、第２残日数は第１残日数よりも少ない。処方日数が多いほど、その薬の提供を受けたユーザは、継続してその薬を服用する必要性が高い傾向にある。例えば、処方日数が多いほど、その薬が慢性疾患用の薬である可能性が高い。慢性疾患をもつユーザは、継続して薬を服用する必要があり、それ故、定期的に薬を入手する必要がある。また、処方日数が多いほど、次に入手すべき薬の量も多くなる傾向にある。現在手元にある薬が残りわずかになってから次の薬を入手するための行動をとっても、実際に入手される前に、手元にある薬がなくなる可能性がある。例えば、ユーザが忙しい状況にある場合、薬を入手するための予定を早々に組むことができない場合がある。また、病院を予約することができない場合がある。また、薬局にて薬の在庫がない場合がある。そこで、処方日数が比較的に多い場合には、余裕をもって残量不足通知を行うことが効果的である。その逆に、処方日数が少ないほど、その薬が急性疾患用の薬である可能性が高い。慢性疾患と比較して、急性疾患をもつユーザは、継続して薬を服用する必要性が低い。また、急性疾患の場合、或る程度薬を服用してユーザの病状やけがの状況等を確認してから、再度診察を受けるか否か若しくは次の薬を入手すべきか否かを判断する必要がある場合がある。また、早い段階でユーザが次の薬を入手すると、最初に処方された薬の全量に対して十分な残量がある状況で、その残量が増加することとなる。こうした事情を鑑みると、処方日数が比較的に短い場合にあまりにも早い段階で残量通知を行うことは効果的ではない。
【0053】
残日数決定部１１０２は、処方日数が前述の第１処方日数未満であり、且つ、処方日数が、所定の第２処方日数以上である場合、通知残日数を前述の第２残日数に決定してもよい。ここで、第２処方日数は第１処方日数より少ない。そして、残日数決定部１１０２は、処方日数が第２処方日数未満である場合、通知残日数を特に決定しなくてもよい。この場合、後述するように、残量不足通知は行われない。前述したように、処方日数が少ないほど、継続して薬を服用する必要性が低い。また、処方日数が十分に少ない場合、ユーザの手元にある薬がなくなる服用終了予定日は、調剤日から十分に近い。そのため、もし次の薬を入手する必要がある場合であれば、ユーザがそのことを覚えている可能性が高い。そうしたユーザにとっては、残量不足通知が不要である可能性が高いと考えられる。そうしたユーザにとって煩わしくも思える可能性がある通知がなくなる。
【0054】
図６は、処方日数と通知残日数との対応関係の一例を示す図である。図６に示すように、処方日数が１日以上で且つ４日以下である場合、残量不足通知は行われない。処方日数が５日以上で且つ１３日以下である場合、通知残日数は３日である。処方日数が１４日以上で且つ２７日以下である場合、通知残日数は７日である。処方日数が２８日以上である場合、通知残日数は１０日である。記憶部１４には、例えば処方日数と通知残日数との対応関係を示すテーブルが予め記憶されてもよい。残日数決定部１１０２は、このテーブルを参照して、通知残日数を決定してもよい。
【0055】
通知残日数を決定すると、残日数決定部１１０２は、通知残日数と、提供薬情報により示される調剤日及び処方日数に基づいて、通知予定日を決定してもよい。例えば、残日数決定部１１０２は、通知予定日を、服薬終了予定日の通知残日数前の日に決定してもよい。残日数決定部１１０２は、決定された通知予定日を、通知予定ＤＢ１４ｃに記憶させてもよい。
【0056】
通知判定部１１０３は、残日数決定部１１０２により決定された通知予定日に基づいて、残量不足通知を実行させるか否かを日ごとに行ってもよい。例えば、通知判定部１１０３は、通知予定日と今日の日付とに基づいて判定を行ってもよい。例えば、通知判定部１１０３は、通知予定日が到来したか否かを日ごとに判定してもよい。例えば、毎日所定の時刻にこの判定が行われてもよい。或いは、通知判定部１１０３は、今日の日付を示す通知予定日を含む通知予定情報を、通知予定ＤＢ１４ｃから検索してもよい。通知判定部１１０３は、この検索を日ごとに行ってもよい。通知判定部１１０３は、該当する通知予定情報が発見された場合、残量不足通知を実行させると判定してもよい。
【0057】
通知制御部１１０４は、残量不足通知を実行させてもよい。例えば、通知制御部１１０４は、薬情報取得部１１０１により取得された提供薬情報により示される調剤日から経過した日数と残日数決定部１１０２により決定された通知残日数との和が、薬情報取得部１１０１により取得された提供薬情報により示される処方日数となる通知予定日に、残量不足通知を実行させてもよい。午前０時を超えると、１日が経過したとみなされてもよい。本実施形態においては、通知予定日は残日数決定部１１０２により決定されるので、通知制御部１１０４は、決定された通知予定日に残量不足通知を実行させてもよい。また、通知制御部１１０４は、残量不足通知を実行させると通知判定部１１０３により判定されたときに、残量不足通知を実行させてもよい。
【0058】
本実施形態において、通知制御部１１０４は、ユーザ端末２に残量不足通知を実行させてもよい。例えば、通知制御部１１０４は、通知予定日に、ユーザ端末２へ通知情報を送信してもよい。通知情報は、残量不足通知の実行の指示を示す情報であってもよい。通知情報は、ユーザ端末２に表示されるメッセージを含んでもよい。通知制御部１１０４は、例えばプッシュ通知で通知情報を送信してもよい。例えば通知制御部１１０４は、ＦＣＭ（Firebase Cloud Messaging）、ＡＰＮｓ（Apple Push Notification Server）、又はＰＷＡ（Progressive Web Apps）等を利用して、プッシュ通知を行ってもよい。これとは別の実施形態として、通知制御部１１０４は、例えば通知予定日を含む情報を予めユーザ端末２へ送信してもよい。ユーザ端末２は、健康管理サーバ１から受信した通知予定日を記憶してもよい。ユーザ端末２は、記憶された通知予定日が到来したとき、残量不足通知を実行してもよい。この場合、ユーザ端末２のシステム制御部２１は、通知判定部１１０３として機能してもよい。
【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】
また、健康管理サーバ１は、第２実施形態と同様の方法で、入手困難度に基づいて、一の提供薬情報について残量不足通知を複数回実行させてもよい。例えば、残日数決定部１１０２は、入手困難度が所定度以上である場合、通知残日数を、所定の第３残日数及び第４残日数に決定してもよい。第４残日数は第３残日数よりも少ない。また、残日数決定部１１０２は、入手困難度が所定度未満である場合、通知残日数を、第４残日数に決定してもよい。すなわち、残日数決定部１１０２は、予め定められた複数の入手困難度（または入手困難度の範囲）のうち、取得された入手困難度に本来対応する残日数と、取得された入手困難度よりも低い入手困難度に本来対応する残日数とを、決定する通知残日数に含めてもよい。残日数決定部１１０２は、処方日数及び入手困難度の両方を用いて通知残日数を決定する場合にも、複数の通知残日数を決定してもよい。例えば、図１７に示す例において、処方日数が２８以上である場合、レベル１の入手困難度に対する通知残日数は８日である。レベル２の入手困難度に対する通知残日数は、１０日及び８日である。レベル３の入手困難度に対する通知残日数は１２日、１０日及び８日であってもよいし、１２日及び１０日であってもよい。
【0095】
以上説明したように、本実施形態によれば、調剤された薬の入手困難度に更に応じて通知残日数が決定される。処方日数が同一である条件下においては、入手困難度が所定度以上である場合、入手困難度が所定度未満である場合よりもより早いタイミングで通知が実行される。そのため、入手の困難度がより高い薬について、その薬を次に入手する時期により余裕を持たせることで、その薬の入手を比較的に容易にすることができる。
【0096】
［４．第４実施形態］
次に、第４実施形態について説明する。以下に説明する点を除き、第４実施形態は第１実施形態～第３実施形のうち少なくとも何れか一つと同一であってもよい。
次に、第４実施形態について説明する。以下に説明する点を除き、第４実施形態は第１実施形態～第３実施形のうち少なくとも何れか一つと同一であってもよい。
【0097】
［４－１．健康管理サーバの構成］
先ず、健康管理サーバ１の構成について、図１８及び図１９を参照して説明する。図１８は、本実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。図１８において、図１４と同一の要素については同一の符号が付されている。図１８が図１４と異なる点は、図１８において、記憶部１４に薬局ＤＢ１４ｅ及び在庫ＤＢ１４ｆが更に記憶されている点である。
先ず、健康管理サーバ１の構成について、図１８及び図１９を参照して説明する。図１８は、本実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。図１８において、図１４と同一の要素については同一の符号が付されている。図１８が図１４と異なる点は、図１８において、記憶部１４に薬局ＤＢ１４ｅ及び在庫ＤＢ１４ｆが更に記憶されている点である。
【0098】
図１９は、薬局ＤＢ１４ｅ及び在庫ＤＢ１４ｆに記憶される情報の一例を示す図である。薬局ＤＢ１４ｅには、各薬局に関する薬局情報が記憶されてもよい。例えば、薬局ＤＢ１４ｅには、薬局情報として、薬局ＩＤ、薬局名、及び住所等が、互いに関連付けて記憶されてもよい。薬局ＩＤは、薬局を識別する識別情報である。薬局名は、その薬局の名称を示す。
【0099】
在庫ＤＢ１４ｆには、各薬局における薬の在庫状況を示す在庫情報が、薬局と薬との組み合わせごとに記憶されてもよい。例えば、在庫ＤＢ１４ｆには、在庫情報として、薬局ＩＤ、医薬品ＩＤ、及び在庫数等が、互いに関連付けて記憶されてもよい。薬局ＩＤは、在庫状況が示される薬局を示す。医薬品ＩＤは、在庫状況が示される薬を示す。在庫数は、在庫としてその薬局にあるその薬の個数を示す。例えばその薬が錠剤である場合、在庫数は錠単位で示されてもよい。健康管理サーバ１は、薬の在庫の管理機能を各薬局に提供してもよい。例えば、薬局が利用する図示せぬ端末装置に、薬剤師等が各薬の在庫数や仕入れた薬の個数を入力可能であってもよい。健康管理サーバ１は、入力された情報に基づいて、在庫情報を生成して在庫ＤＢ１４ｆに記憶させたり、在庫ＤＢ１４ｆに記憶されている在庫数を更新したりしてもよい。また、薬局が薬を販売すると、薬剤師等は、販売された薬の個数等をその端末装置に入力可能であってもよい。健康管理サーバ１は、入力された情報に基づいて、在庫ＤＢ１４ｆに記憶されている在庫数を更新してもよい。本実施形態は、薬を調剤する施設は薬局であることを前提としている。しかしながら、薬を調剤する施設は、処方された薬を調剤して外来患者に提供する病院を含んでもよい。その場合、在庫ＤＢ１４ｆには、その病院での薬の在庫状況を示す在庫情報状況が記憶されてもよい。
【0100】
［４－２．機能概要］
次に、図２０及び図２１を参照して、健康管理サーバ１におけるシステム制御部１１の機能概要について説明する。図２０は、本実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。図２０において、図５と同一の要素については同一の符号が付されている。図２０が図５と異なる点は、図２０において、システム制御部１１が更に在庫情報取得部１１０６として機能する点である。
次に、図２０及び図２１を参照して、健康管理サーバ１におけるシステム制御部１１の機能概要について説明する。図２０は、本実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。図２０において、図５と同一の要素については同一の符号が付されている。図２０が図５と異なる点は、図２０において、システム制御部１１が更に在庫情報取得部１１０６として機能する点である。
【0101】
本実施形態において、薬情報取得部１１０１により取得される提供薬情報は、調剤された薬を識別する情報を含んでもよい。この情報は、例えば医薬品名であってもよい。また、提供薬情報は、その薬を調剤した施設を示す情報を含んでもよい。この情報は、例えば調剤薬局名であってもよい。
【0102】
在庫情報取得部１１０６は、調剤された薬の在庫量であって、薬情報取得部１１０１により取得された提供薬情報により示される施設での在庫量を特定可能な在庫情報を取得してもよい。例えば、在庫情報取得部１１０６は、薬情報取得部１１０１により提供薬情報が取得されたときに、在庫情報を取得してもよい。在庫情報取得部１１０６は、例えば提供薬情報から医薬品名及び調剤薬局名を取得してもよい。在庫情報取得部１１０６は、医薬品ＤＢ１４ｄから、その医薬品名に関連付けられた医薬品ＩＤを取得してもよい。本実施形態における医薬品ＤＢ１４ｄは、医薬品ＩＤの検索のために用いられる。そのため、医薬品ＤＢ１４ｄには入手困難度が記憶されていなくてもよい。在庫情報取得部１１０６は、薬局ＤＢ１４ｅから、調剤薬局名と同一の薬局名に関連付けられた薬局ＩＤを取得してもよい。そして、在庫情報取得部１１０６は、在庫ＤＢ１４ｆから、取得された医薬品ＩＤと薬局ＩＤとの組み合わせを含む在庫情報を検索してもよい。
【0103】
在庫情報により示される在庫数と在庫量とは異なる場合があってもよい。後述するように、在庫量は通知残日数の決定に用いられる。そのため、在庫量は、例えば調剤された薬が提供されたユーザにとって、その薬が何日分の薬であるかを示してもよい。すなわち、在庫量は、在庫としてある薬がなくなるまでに、そのユーザがその薬を服用可能な日数を示してもよい。提供薬情報に含まれる１日当たりの薬の服用回数及び１回量を用いて、在庫量が計算されてもよい。例えば、在庫情報取得部１１０６は、１日当たりの薬の服用回数に１回量を乗算することにより、１日当たりの服用数を計算してもよい。在庫情報取得部１１０６は、在庫数から、１日当たりの服用数を除算することにより、在庫量を計算してもよい。
【0104】
残日数決定部１１０２は、在庫情報取得部１１０６により取得された在庫情報に基づいて、残日数を決定してもよい。例えば、在庫情報から特定される在庫量が少なくなるほど通知残日数が多くなってもよい。通知残日数は、在庫量が少なくなるに従って段階的に多くなってもよい。ユーザは、次に薬を入手する場合、前回行った薬局と同じ薬局に行って、その薬を調剤しもらう可能性がある。その薬局においてその薬の在庫量が少ないほど、その薬の在庫が早い段階でなくなる可能性が高い。在庫量がより少ない場合には、より早いタイミングで残量不足通知が実行されることで、ユーザは、在庫がある間にその薬を入手することができる。そのため、入手が困難な薬であっても、現在ユーザの手元にある薬がなくなる前に余裕をもって次の薬を入手することができる。
【0105】
残日数決定部１１０２は、処方日数及び在庫量の両方に基づいて、通知残日数を決定してもよい。このとき、残日数決定部１１０２は、処方日数に応じるとともに前記取得された在庫量に応じた通知残日数を決定してもよい。例えば、残日数決定部１１０２は、処方日数が同一である条件下においては、在庫量が所定量未満である場合に決定する通知残日数を、在庫量が所定度以上である場合に決定する通知残日数よりも多くしてもよい。また例えば、残日数決定部１１０２は、在庫量が同一である条件下においては、処方日数が第１処方日数以上である場合に決定する通知残日数を、処方日数が第１処方日数未満である場合に決定する通知残日数よりも多くしてもよい。
【0106】
図２１は、処方日数と在庫量との組み合わせと、通知残日数と、の対応関係の一例を示す図である。図２１に示すように、処方日数が１日以上で且つ４日以下である場合、在庫量に関係なく、残量不足通知は行われない。処方日数が５日以上で且つ１３日以下であって、尚且つ在庫量が１０００日分以上である場合、通知残日数は２日である。同じ処方日数の範囲において、在庫量が５００日分以上で且つ９９９日分以下である場合の通知残日数は３日である。同じ処方日数の範囲において、在庫量が４９９日分以下である場合の通知残日数は４日である。処方日数が１４日以上で且つ２７日以下である場合であって、尚且つ在庫量が１０００日分以上である場合、通知残日数は５日である。同じ処方日数の範囲において、在庫量が５００日分以上で且つ９９９日分以下である場合の通知残日数は７日である。同じ処方日数の範囲において、在庫量が４９９日分以下である場合の通知残日数は９日である。処方日数が２８以上である場合であって、尚且つ在庫量が１０００日分以上である場合、通知残日数は８日である。同じ処方日数の範囲において、在庫量が５００日分以上で且つ９９９日分以下である場合の通知残日数は１０日である。同じ処方日数の範囲において、在庫量が４９９日分以下である場合の通知残日数は１２日である。記憶部１４には、例えば処方日数と在庫量との組み合わせと、通知残日数と、の対応関係を示すテーブルが予め記憶されてもよい。
【0107】
なお、残日数決定部１１０２は、処方日数及び在庫情報のうち在庫情報のみに基づいて、通知残日数を決定してもよい。また例えば、残日数決定部１１０２は、在庫情報及び薬の入手困難度のみに基づいて、通知残日数を決定してもよい。また例えば、残日数決定部１１０２は、処方日数、在庫情報及び薬の入手困難度に基づいて、通知残日数を決定してもよい。
【0108】
また、健康管理サーバ１は、第２実施形態と同様の方法で、在庫量に基づいて、一の提供薬情報について残量不足通知を複数回実行させてもよい。例えば、残日数決定部１１０２は、在庫量が所定量未満である場合、通知残日数を、所定の第５残日数及び第６残日数に決定してもよい。第６残日数は第５残日数よりも少ない。また、残日数決定部１１０２は、在庫量が所定量以上である場合、通知残日数を、第６残日数に決定してもよい。すなわち、残日数決定部１１０２は、予め定められた複数の在庫量の範囲うち、在庫情報から特定された在庫量を含む範囲に本来対応する残日数と、在庫情報から特定された在庫量を含む範囲よりも少ない範囲に本来対応する残日数とを、決定する通知残日数に含めてもよい。残日数決定部１１０２は、処方日数及び在庫量の両方を用いて通知残日数を決定する場合にも、複数の通知残日数を決定してもよい。例えば、図２１に示す例において、処方日数が２８以上である場合であって、尚且つ在庫量が１０００日分以上である場合、通知残日数は８日である。在庫量が５００日分以上で且つ９９９日分以下である場合の通知残日数は、１０日及び８日である。在庫量が４９９日分以下である場合の通知残日数は１２日、１０日及び８日であってもよいし、１２日及び１０日であってもよい。
【0109】
以上説明したように、本実施形態によれば、薬を調剤した施設におけるその薬の在庫量に更に応じて通知残日数が決定される。処方日数が同一である条件下においては、在庫量が所定量未満である場合、在庫量が所定量以上である場合よりも早いタイミングで通知が実行される。そのため、在庫量がより少ない薬について、その薬を次に入手する時期により余裕を持たせることで、在庫がある間にその薬を入手することができる可能性を高めることができる。
【0110】
［５．第５実施形態］
次に、第５実施形態について説明する。以下に説明する点を除き、第５実施形態は第１実施形態～第４実施形のうち少なくとも何れか一つと同一であってもよい。本実施形態において、健康管理サーバ１は、診察の予約、調剤の予約、及び服薬指導の予約のうち少なくとも何れか一つをユーザから受け付け可能であってもよい。予約可能な診察は、オフラインでの診察であってもよいし、オンラインでの診察であってもよい。調剤が予約可能である場合、ユーザは、調剤された薬を受け取りに薬局に行く。ユーザが薬局へ薬を取りに行く場合、服薬指導もその薬局で行われてもよい。予約可能な服薬指導は、オンラインでの指導であってもよい。オンラインで服薬指導が行われる場合、調剤された薬は、例えば薬局からユーザの住所へ配送されてもよい。
次に、第５実施形態について説明する。以下に説明する点を除き、第５実施形態は第１実施形態～第４実施形のうち少なくとも何れか一つと同一であってもよい。本実施形態において、健康管理サーバ１は、診察の予約、調剤の予約、及び服薬指導の予約のうち少なくとも何れか一つをユーザから受け付け可能であってもよい。予約可能な診察は、オフラインでの診察であってもよいし、オンラインでの診察であってもよい。調剤が予約可能である場合、ユーザは、調剤された薬を受け取りに薬局に行く。ユーザが薬局へ薬を取りに行く場合、服薬指導もその薬局で行われてもよい。予約可能な服薬指導は、オンラインでの指導であってもよい。オンラインで服薬指導が行われる場合、調剤された薬は、例えば薬局からユーザの住所へ配送されてもよい。
【0111】
［５－１．健康管理サーバの構成］
先ず、健康管理サーバ１の構成について、図２２及び図２３を参照して説明する。図２２は、本実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。図２２において、図１４と同一の要素については同一の符号が付されている。図２２が図１４と異なる点は、図２２において、記憶部１４には、病院ＤＢ１４ｇ、薬局予約状況ＤＢ１４ｈ、及び病院予約状況ＤＢ１４ｉが更に記憶されているとともに、医薬品ＤＢ１４ｄは記憶されていなくてもよい点である。
先ず、健康管理サーバ１の構成について、図２２及び図２３を参照して説明する。図２２は、本実施形態に係る健康管理サーバ１の概要構成の一例を示すブロック図である。図２２において、図１４と同一の要素については同一の符号が付されている。図２２が図１４と異なる点は、図２２において、記憶部１４には、病院ＤＢ１４ｇ、薬局予約状況ＤＢ１４ｈ、及び病院予約状況ＤＢ１４ｉが更に記憶されているとともに、医薬品ＤＢ１４ｄは記憶されていなくてもよい点である。
【0112】
図２３は、病院ＤＢ１４ｇ、薬局予約状況ＤＢ１４ｈ、及び病院予約状況ＤＢ１４ｉに記憶される情報の一例を示す図である。
【0113】
病院ＤＢ１４ｇには、各病院に関する病院情報が記憶されてもよい。例えば、病院ＤＢ１４ｇには、病院情報として、病院ＩＤ、病院名、住所、及び診療科目リスト等が、互いに関連付けて記憶されてもよい。病院ＩＤは、病院を識別する識別情報である。病院名は、その病院の名称を示す。診療科目リストは、その病院にある診療科目を識別する科目ＩＤのリストである。
【0114】
薬局予約状況ＤＢ１４ｈには、薬局での調剤若しくは服薬指導の予約の状況を示す薬局予約状況情報が、予約枠ごとに記憶されてもよい。予約枠は、例えば薬局と日付と時間帯との組み合わせであってもよい。予約枠の単位で、調剤若しくは服薬指導の予約が可能であってもよい。例えば、薬局予約状況ＤＢ１４ｈには、薬局予約状況情報として、予約枠ＩＤ、薬局ＩＤ、対象日、開始時刻、営業フラグ、予約フラグ、及び予約者ＩＤ等が、互いに関連付けて記憶されてもよい。予約枠ＩＤは、予約状況が示される予約枠を識別する識別情報である。薬局ＩＤは、その予約枠に対応する予約対象となる薬局を示す。対象日は、その予約枠に対応する予約対象となる日付を示す。開始時刻は、その予約枠に対応する予約対象となる時間帯の開始時刻を示す。時間帯の長さは、例えば予め定められていてもよい。時間帯の長さの例として、１０分、１５分、３０分等が挙げられる。営業フラグは、その予約枠に対応する日付及び時間帯にその薬局が営業するか否かを示す。営業フラグは、例えば「営業中」及び「非営業中」のうち何れか一方に設定されてもよい。「営業中」は、営業中であることを示す。「非営業中」は、非営業中であることを示す。営業フラグが「非営業中」に設定されている予約枠を予約することはできない。予約フラグは、その予約枠が予約済みであるか否かを示す。予約フラグは、例えば「未予約」及び「予約済み」のうち何れかに設定されてもよい。「未予約」は、予約されていないことを示す。「予約済み」は、予約されていることを示す。予約フラグは、営業フラグが「営業中」である場合に有効である。予約者ＩＤは、その予約枠を予約したユーザのユーザＩＤである。予約者ＩＤは、予約フラグが「予約済み」である場合に有効である。
【0115】
健康管理サーバ１は、ユーザ端末２からの要求に応じて、薬局の検索や予約を行ってもよい。例えば、ユーザが検索条件を入力する。検索条件の例として、薬局名、住所、日付、時間帯等が挙げられる。健康管理サーバ１は、例えば薬局名や住所等の検索条件を満たす薬局を薬局ＤＢ１４ｅから検索してもよい。健康管理サーバ１は、検索された各薬局について、日付や時間帯等の検索条件を満たし、且つ予約可能な予約枠を検索してもよい。健康管理サーバ１は、検索結果として、検索された各薬局について予約可能な予約枠の日付や時間帯を示す情報をユーザ端末２へ送信してもよい。ユーザが何れかの予約枠を選択すると、健康管理サーバ１は、選択された予約枠に対応する薬局予約状況情報の予約フラグを「予約済み」に変更してもよい。また、健康管理サーバ１は、各薬局が利用する図示せぬ端末装置に、その薬局の予約状況を示す情報を送信してもよい。薬局の従業員は、その端末装置で予約状況を確認することができる。
【0116】
病院予約状況ＤＢ１４ｉには、病院での診察の予約の状況を示す病院予約状況情報が、予約枠ごとに記憶されてもよい。予約枠は、例えば病院と診療科と日付と時間帯との組み合わせであってもよい。予約枠の単位で、診察の予約が可能であってもよい。例えば、病院予約状況ＤＢ１４ｉには、病院予約状況情報として、予約枠ＩＤ、病院ＩＤ、科目ＩＤ、対象日、開始時刻、診察可不可フラグ、予約フラグ、及び予約者ＩＤ等が、互いに関連付けて記憶されてもよい。予約枠ＩＤは、予約状況が示される予約枠を識別する識別情報である。病院ＩＤは、その予約枠に対応する予約対象となる病院を示す。科目ＩＤは、その予約枠に対応する予約対象となる診療科を示す。対象日は、その予約枠に対応する予約対象となる日付を示す。開始時刻は、その予約枠に対応する予約対象となる時間帯の開始時刻を示す。時間帯の長さは、例えば予め定められていてもよい。診察可不可フラグは、その予約枠で診察が実施可能であるか否かを示す。診察可不可フラグは、例えば「診察可」及び「診察不可」のうち何れか一方に設定されてもよい。「診察可」は、診察可能であることを示す。「診察不可」は、診察不可能であることを示す。各病院は休診日を設けている場合がある。対象日が休診日である場合、診察可不可フラグは「診察不可」に設定されている。また、病院ごとに、１日のうち診察可能な時間帯が定められている。予約枠の時間帯が、診察可能な時間帯に含まれる場合、診察可不可フラグは「診察可」に設定されている。予約枠の時間帯が、診察不可能な時間帯に含まれる場合、診察可不可フラグは「診察不可」に設定されている。診察可不可フラグが「診察不可」に設定されている予約枠を予約することはできない。予約フラグは、その予約枠が予約済みであるか否かを示す。予約フラグは、例えば「未予約」及び「予約済み」のうち何れかに設定されてもよい。「未予約」は、予約されていないことを示す。「予約済み」は、予約されていることを示す。予約フラグは、診察可不可フラグが「診察可」である場合に有効である。予約者ＩＤは、その予約枠を予約したユーザのユーザＩＤである。予約者ＩＤは、予約フラグが「予約済み」である場合に有効である。
【0117】
健康管理サーバ１は、ユーザ端末２からの要求に応じて、病院の検索や予約を行ってもよい。例えば、ユーザが検索条件を入力する。検索条件の例として、病院名、住所、診療科目、日付、時間帯等が挙げられる。健康管理サーバ１は、例えば病院名、住所、診療科目等の検索条件を満たす病院を病院ＤＢ１４ｇから検索してもよい。健康管理サーバ１は、検索された各病院について、日付や時間帯等の検索条件を満たし、且つ予約可能な予約枠を検索してもよい。健康管理サーバ１は、検索結果として、検索された各病院について予約可能な予約枠の日付や時間帯を示す情報をユーザ端末２へ送信してもよい。ユーザが何れかの予約枠を選択すると、健康管理サーバ１は、選択された予約枠に対応する病院予約状況情報の予約フラグを「予約済み」に変更してもよい。また、健康管理サーバ１は、各病院が利用する図示せぬ端末装置に、その病院の予約状況を示す情報を送信してもよい。病院の従業員は、その端末装置で予約状況を確認することができる。
【0118】
なお、記憶部１４には、薬局予約状況ＤＢ１４ｈ及び病院予約状況ＤＢ１４ｉのうち何れか一方のみが記憶されていてもよい。
【0119】
［５－２．機能概要］
次に、図２４及び図２５を参照して、健康管理サーバ１におけるシステム制御部１１の機能概要について説明する。図２４は、本実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。図２４において、図５と同一の要素については同一の符号が付されている。図２４が図５と異なる点は、図２４において、システム制御部１１が更に予約状況情報取得部１１０７として機能する点である。
次に、図２４及び図２５を参照して、健康管理サーバ１におけるシステム制御部１１の機能概要について説明する。図２４は、本実施形態に係る健康管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。図２４において、図５と同一の要素については同一の符号が付されている。図２４が図５と異なる点は、図２４において、システム制御部１１が更に予約状況情報取得部１１０７として機能する点である。
【0120】
本実施形態において、薬情報取得部１１０１により取得される提供薬情報は、その薬を調剤した施設及びその薬を処方した病院のうち少なくとも何れか一方を示す情報を含んでもよい。この情報は、例えば調剤薬局名及び処方病院名のうち少なくとも何れか一方であってもよい。
【0121】
予約状況情報取得部１１０７は、薬情報取得部１１０１により取得された提供薬情報により示される施設であって、その薬を調剤した施設及びその薬を処方した病院のうち、少なくとも何れか一方の施設の予約状況を示す予約状況情報を取得してもよい。取得される予約状況情報は、例えば薬局予約状況情報及び病院予約状況情報のうち、少なくとも何れか一方を含んでもよい。例えば、予約状況情報取得部１１０７は、薬情報取得部１１０１により提供薬情報が取得されたときに、予約状況情報を取得してもよい。薬局予約状況情報を取得する場合、予約状況情報取得部１１０７は、例えば提供薬情報から調剤薬局名を取得してもよい。予約状況情報取得部１１０７は、薬局ＤＢ１４ｅから、その調剤薬局名に関連付けられた薬局ＩＤを取得してもよい。予約状況情報取得部１１０７は、薬局予約状況ＤＢ１４ｈから、取得された薬局ＩＤを含む薬局予約状況情報を検索してもよい。なお、調剤薬局名から、薬を調剤した施設が、薬局及び病院の何れであるかを特定可能である。調剤薬局名が病院名を示す場合、予約状況情報取得部１１０７は、病院予約状況情報の方を取得してもよい。病院予約状況情報を取得する場合、予約状況情報取得部１１０７は、例えば提供薬情報から処方病院名及び診療科目名を取得してもよい。予約状況情報取得部１１０７は、病院ＤＢ１４ｇから、その病院名に関連付けられた病院ＩＤを取得してもよい。また、予約状況情報取得部１１０７は、診療科目名に対応する科目ＩＤを取得してもよい。予約状況情報取得部１１０７は、病院予約状況ＤＢ１４ｉから、取得された病院ＩＤと科目ＩＤとを含む病院予約状況情報を検索してもよい。
【0122】
予約状況情報取得部１１０７は、例えば予め定められた参照期間内の対象日を含む予約状況情報を取得してもよい。この参照期間は、過去の期間であってもよいし、未来の期間であってもよい。参照期間の長さは予め定められていてもよいし、処方日数に応じて決定されてもよい。参照期間が未来の期間である場合、予約状況情報取得部１１０７は、例えば服用終了予定日以前の日付の範囲内で、参照期間を決定してもよい。例えば、参照期間は、服用終了予定日の所定日数前の日から服用終了予定日の前日までの期間等であってよい。
【0123】
取得される予約状況情報は、薬を調剤した施設又は薬を処方した病院の予約困難度を特定可能な情報であってもよい。予約困難度は、調剤、服薬指導若しくは診察の予約の困難度を示してもよい。予約困難度が高いほど、より予約か困難である。予約困難度は、例えば予約不可能率で示されてもよい。予約不可能率は、予約不可能時間長を、参照時間長で除算することにより計算されてもよい。参照時間長は、参照期間内の所定の時間帯の長さの合計であってもよい。所定の時間帯は、例えば１日のうち、薬局又は病院の利用が比較的に多い時間帯であってもよい。例えば、所定の時間帯は、８時から２０時までの時間帯等であってもよい。予約不可能時間長は、参照期間内の所定の時間帯のうち、予約が不可能な時間帯の長さの合計であってもよい。予約不可能率が高いほど、予約困難度が高い。予約不可能率が高いほど、予約可能な予約枠が少ないので、それらの予約枠の範囲内でユーザが受診したり薬を調剤してもらったり服薬指導を受けたりすることができる可能性が低くなる。また予約不可能率が１００パーセントになると、予約自体が不可能となる。予約状況情報取得部１１０７は、例えば参照期間の日数に、所定の時間帯の長さを乗算して、参照時間長を計算してもよい。薬局予約状況情報を取得した場合、予約状況情報取得部１１０７は、取得した薬局予約状況情報から、例えば営業フラグが「営業中」であり且つ予約フラグが「未予約」である薬局予約状況情報を抽出してもよい。予約状況情報取得部１１０７は、例えば抽出された薬局予約状況情報の個数に基づいて、予約可能な時間帯の長さの合計を計算し、その合計と予約不可能時間長とに基づいて、予約不可能時間長を計算してもよい。病院予約状況情報を取得した場合、予約状況情報取得部１１０７は、取得した病院予約状況情報から、例えば診察可不可フラグが「診察可」であり且つ予約フラグが「未予約」である病院予約状況情報を抽出してもよい。予約状況情報取得部１１０７は、例えば抽出された病院予約状況情報の個数に基づいて、予約可能な時間帯の長さの合計を計算し、その合計と予約不可能時間長とに基づいて、予約不可能時間長を計算してもよい。
【0124】
残日数決定部１１０２は、予約状況情報取得部１１０７により取得された予約状況情報に基づいて、残日数を決定してもよい。例えば、予約状況情報から特定される予約困難度が高くなるほど通知残日数が多くなってもよい。通知残日数は、予約困難度が高くなるに従って段階的に多くなってもよい。ユーザは、次に薬を入手する場合、前回行った病院と同じ病院に行って、その薬を処方しもらう可能性がある。また、ユーザは、前回行った施設と同じ施設に行って、その薬を調剤しもらう可能性がある。その施設の予約困難度が高いほど、現在手元にある薬がなくなる前に次の薬を入手することができる可能性が低くなる。予約困難度がより高い場合には、より早いタイミングで残量不足通知が実行されることで、ユーザは、薬がなくなる前に余裕をもって病院又は薬局を予約することができる。
【0125】
残日数決定部１１０２は、処方日数及び予約困難度の両方に基づいて、通知残日数を決定してもよい。このとき、残日数決定部１１０２は、処方日数に応じるとともに予約困難度に応じた通知残日数を決定してもよい。例えば、残日数決定部１１０２は、処方日数が同一である条件下においては、予約困難度が所定度以上である場合に決定する通知残日数を、予約困難度が所定度未満である場合に決定する通知残日数よりも多くしてもよい。また例えば、残日数決定部１１０２は、予約困難度が同一である条件下においては、処方日数が第１処方日数以上である場合に決定する通知残日数を、処方日数が第１処方日数未満である場合に決定する通知残日数よりも多くしてもよい。
【0126】
薬局予約状況情報及び病院予約状況情報の両方を用いる場合、残日数決定部１１０２は、例えば薬局予約状況情報及び病院予約状況情報のそれぞれについて予約困難度を特定してもよい。残日数決定部１１０２は、例えばそれらの予約困難度のうち、より高い方の予約困難度を用いて、通知残日数を決定してもよい。
【0127】
図２５は、処方日数と予約不可能率との組み合わせと、通知残日数と、の対応関係の一例を示す図である。図２５に示す例では、予約困難度として予約不可能率が用いられる。処方日数が１日以上で且つ４日以下である場合、予約不可能率に関係なく、残量不足通知は行われない。処方日数が５日以上で且つ１３日以下であって、尚且つ予約不可能率が７０パーセント未満である場合、通知残日数は２日である。同じ処方日数の範囲において、予約不可能率が７０パーセント以上で且つ９０パーセント未満である場合の通知残日数は３日である。同じ処方日数の範囲において、予約不可能率が９０パーセント以上である場合の通知残日数は４日である。処方日数が１４日以上で且つ２７日以下である場合であって、尚且つ予約不可能率が７０パーセント未満である場合、通知残日数は５日である。同じ処方日数の範囲において、予約不可能率が７０パーセント以上で且つ９０パーセント未満である場合の通知残日数は７日である。同じ処方日数の範囲において、予約不可能率が９０パーセント以上である場合の通知残日数は９日である。処方日数が２８以上である場合であって、尚且つ予約不可能率が７０パーセント未満である場合、通知残日数は８日である。同じ処方日数の範囲において、予約不可能率が７０パーセント以上で且つ９０パーセント未満である場合の通知残日数は１０日である。同じ処方日数の範囲において、予約不可能率が９０パーセント以上である場合の通知残日数は１２日である。記憶部１４には、例えば処方日数と予約不可能率との組み合わせと、通知残日数と、の対応関係を示すテーブルが予め記憶されてもよい。
【0128】
なお、残日数決定部１１０２は、処方日数及び予約状況情報のうち予約状況情報のみに基づいて、通知残日数を決定してもよい。また例えば、残日数決定部１１０２は、予約状況情報と、薬の入手困難度及び在庫情報の両方若しくは何れか一方と、に基づいて、通知残日数を決定してもよい。また例えば、残日数決定部１１０２は、処方日数及び予約状況情報と、薬の入手困難度及び在庫情報の両方若しくは何れか一方と、に基づいて、通知残日数を決定してもよい。
【0129】
また、健康管理サーバ１は、第２実施形態と同様の方法で、予約困難度に基づいて、一の提供薬情報について、残量不足通知を複数回実行させてもよい。例えば、残日数決定部１１０２は、予約困難度が所定度以上である場合、通知残日数を、所定の第７残日数及び第８残日数に決定してもよい。第８残日数は第７残日数よりも少ない。また、残日数決定部１１０２は、予約困難度が所定度未満である場合、通知残日数を、第８残日数に決定してもよい。すなわち、残日数決定部１１０２は、予め定められた複数の予約困難度の範囲うち、予約状況情報から特定された予約困難度を含む範囲に本来対応する残日数と、予約状況情報から特定された予約困難度を含む範囲よりも低い範囲に本来対応する残日数とを、決定する通知残日数に含めてもよい。残日数決定部１１０２は、処方日数及び予約困難度の両方を用いて通知残日数を決定する場合にも、複数の通知残日数を決定してもよい。例えば、図２５に示す例において、処方日数が２８以上である場合であって、尚且つ予約不可能率が７０パーセント未満である場合、通知残日数は８日である。予約不可能率が７０パーセント以上で且つ９０パーセント未満である場合の通知残日数は、１０日及び８日である。予約不可能率が９０パーセント以上である場合の通知残日数は、１２日、１０日及び８日であってもよいし、１２日及び１０日であってもよい。
【0130】
以上説明したように、本実施形態によれば、薬を調剤した施設及びその薬を処方した病院のうち少なくとも何れか一方の施設の予約困難度に更に応じて通知残日数が決定される。処方日数が同一である条件下においては、予約困難度が所定度以上である場合、予約困難度が所定度未満である場合よりもより早いタイミングで通知が実行される。そのため、予約がより困難な施設又は病院について、その施設で次に薬を調剤させる時期又はその病院で次に診察させる時期により余裕を持たせることで、予約を比較的に容易にすることができる。
【0131】
（付記１）調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得手段と、前記取得された薬情報により示される前記処方日数に応じた残日数を決定する決定手段と、前記取得された薬情報により示される前記調剤日から経過した日数と前記決定された残日数との和が、前記取得された薬情報により示される前記処方日数となる通知日に、前記調剤された薬の残量の減少に関連する通知を実行させる通知制御手段と、を備えることを特徴とする通知制御装置。
【0132】
（付記２）前記決定手段は、前記通知日を更に決定し、前記決定された通知日に基づいて、前記通知を実行させるか否かを日ごとに判定する判定手段を更に備え、前記通知制御手段は、前記通知を実行させると判定された場合、前記通知を実行させることを特徴とする付記１に記載の通知制御装置。
【0133】
（付記３）前記決定手段は、前記処方日数が所定の第１処方日数以上である場合に決定する前記残日数を、前記処方日数が前記第１処方日数未満である場合に決定する前記残日数よりも多くすることを特徴とする付記１又は２に記載の通知制御装置。
【0134】
（付記４）前記決定手段は、前記処方日数が所定の第１処方日数以上である場合、前記残日数を、所定の第１残日数及び該第１残日数よりも少ない所定の第２残日数に決定し、前記処方日数が前記第１処方日数未満である場合、前記残日数を前記第２残日数に決定し、前記通知制御手段は、前記残日数が前記第１残日数及び前記第２残日数に決定された場合、前記第１残日数に応じて定められる前記通知日及び前記第２残日数に応じて定められる前記通知日のそれぞれに、前記通知を実行させることを特徴とする付記３に記載の通知制御装置。
【0135】
（付記５）前記通知制御手段は、前記処方日数が、前記第１処方日数よりも少ない第２処方日数以上である場合、前記通知を出力し、前記処方日数が前記第２処方日数未満である場合、前記通知を実行させないことを特徴とする付記３又は４に記載の通知制御装置。
【0136】
（付記６）前記調剤された薬の入手困難度を示す困難度情報を取得する困難度情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された困難度情報により示される前記入手困難度に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記入手困難度が所定度以上である場合に決定する前記残日数を、前記入手困難度が前記所定度未満である場合に決定する前記残日数よりも多くすることを特徴とする付記１乃至５の何れか一に記載の通知制御装置。
【0137】
（付記７）前記取得される薬情報は、前記薬を調剤した施設を更に示し、前記取得された薬情報により示される前記施設での前記調剤された薬の在庫量を特定可能な在庫情報を取得する在庫情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された在庫情報により特定される前記在庫量に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記在庫量が所定量未満である場合に決定する前記残日数を、前記在庫量が前記所定量以上である場合に決定する前記残日数よりも多くすることを特徴とする付記１乃至６の何れか一に記載の通知制御装置。
【0138】
（付記８）前記取得される薬情報は、前記薬を調剤した施設及び前記薬を処方した病院のうち少なくとも何れか一方の施設を更に示し、前記取得された薬情報により示される前記少なくとも何れか一方の施設の予約状況を示す予約状況情報であって、前記少なくとも何れか一方の施設の予約困難度を特定可能な予約状況情報を取得する予約状況情報取得手段を更に備え、前記決定手段は、前記処方日数に応じるとともに前記取得された予約状況情報から特定される前記予約困難度に応じた前記残日数を決定し、前記処方日数が同一である条件下においては、前記予約困難度が所定度以上である場合に決定する前記残日数を、前記予約困難度が前記所定度未満である場合に決定する前記残日数よりも多くすることを特徴とする付記１乃至７の何れか一に記載の通知制御装置。
【0139】
（付記９）前記通知制御手段は、前記調剤された薬の提供先のユーザの端末装置に前記通知を実行させることを特徴とする付記１乃至８の何れか一記載の通知制御装置。
【0140】
（付記１０）前記実行される通知は、前記薬の残量が少なくなったこと及び病院に行くことを勧めることのうち、少なくとも何れか一方を示す通知情報を出力することを含むことを特徴とする付記１乃至９の何れか一に記載の通知制御装置。
【0141】
（付記１１）端末装置のコンピュータに、調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得手段と、前記取得された薬情報により示される前記調剤日から経過した日数と、前記取得された薬情報により示される前記処方日数に応じて決定された残日数と、の和が、前記処方日数となる通知日に、前記端末装置のユーザ向けの通知を実行する通知手段、として機能させることを特徴とする端末プログラム。
【符号の説明】
【0142】
１ 健康管理サーバ
２ ユーザ端末
１１ システム制御部
１２ システムバス
１３ 入出力インタフェース
１４ 記憶部
１４ａ ユーザＤＢ
１４ｂ 提供薬情報ＤＢ
１４ｃ 通知予定ＤＢ
１４ｄ 医薬品ＤＢ
１４ｅ 薬局ＤＢ
１４ｆ 在庫ＤＢ
１４ｇ 病院ＤＢ
１４ｈ 薬局予約状況ＤＢ
１４ｉ 病院予約状況ＤＢ
１５ 通信部
２１ システム制御部
２２ システムバス
２３ 入出力インタフェース
２４ 記憶部
２５ 通信部
２６ 操作入力部
２７ 表示部
２８ 撮像部
２９ 音声出力部
３０ 振動部
１１０１ 薬情報取得部
１１０２ 残日数決定部
１１０３ 通知判定部
１１０４ 通知制御部
１１０５ 入手困難度取得部
１１０６ 在庫情報取得部
１１０７ 予約状況情報取得部
２１０１ 薬情報取得部
２１０２ 薬情報送信部
２１０３ 通知情報受信部
２１０４ 通知部
ＮＷ ネットワーク
Ｓ 通信システム
２ ユーザ端末
１１ システム制御部
１２ システムバス
１３ 入出力インタフェース
１４ 記憶部
１４ａ ユーザＤＢ
１４ｂ 提供薬情報ＤＢ
１４ｃ 通知予定ＤＢ
１４ｄ 医薬品ＤＢ
１４ｅ 薬局ＤＢ
１４ｆ 在庫ＤＢ
１４ｇ 病院ＤＢ
１４ｈ 薬局予約状況ＤＢ
１４ｉ 病院予約状況ＤＢ
１５ 通信部
２１ システム制御部
２２ システムバス
２３ 入出力インタフェース
２４ 記憶部
２５ 通信部
２６ 操作入力部
２７ 表示部
２８ 撮像部
２９ 音声出力部
３０ 振動部
１１０１ 薬情報取得部
１１０２ 残日数決定部
１１０３ 通知判定部
１１０４ 通知制御部
１１０５ 入手困難度取得部
１１０６ 在庫情報取得部
１１０７ 予約状況情報取得部
２１０１ 薬情報取得部
２１０２ 薬情報送信部
２１０３ 通知情報受信部
２１０４ 通知部
ＮＷ ネットワーク
Ｓ 通信システム
【要約】 （修正有）
【課題】調剤された薬の処方日数に応じたタイミングで通知を行う通知制御装置及び端末プログラムを提供する。
【解決手段】健康管理サーバ及び各ユーザ端末がネットワークに接続される通信システムにおいて、健康管理サーバのシステム制御部１１は、調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得部１１０１と、薬情報により示される処方日数に応じた残日数を決定する残日数決定部１１０２と薬情報により示される調剤日から経過した日数と決定された残日数との和が、薬情報により示される処方日数となる通知日に、調剤された薬の残量の減少に関連する通知を実行させる、通知制御部１１０４と、を有する。
【選択図】図５
【解決手段】健康管理サーバ及び各ユーザ端末がネットワークに接続される通信システムにおいて、健康管理サーバのシステム制御部１１は、調剤された薬の調剤日及び処方日数を示す薬情報を取得する薬情報取得部１１０１と、薬情報により示される処方日数に応じた残日数を決定する残日数決定部１１０２と薬情報により示される調剤日から経過した日数と決定された残日数との和が、薬情報により示される処方日数となる通知日に、調剤された薬の残量の減少に関連する通知を実行させる、通知制御部１１０４と、を有する。
【選択図】図５
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】