(57)【要約】【課題】個人ごとのヘルスケアに有用な情報を提供すること。【解決手段】サーバ装置１０は、少なくとも１のユーザについてのイベントが登録されたスケジュール情報から取得したイベントの種別に応じて算出した負荷の時系列変化を示すグラフを表示するとともに、１のユーザについて登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報をグラフと時間的に対応づけて表示する。【選択図】図２
2016053761.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１のユーザについてのイベントが登録されたスケジュール情報から取得したイベントの種別に応じて算出した負荷の時系列変化を示すグラフを表示するとともに、前記１のユーザについて登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を前記グラフと時間的に対応づけて表示する、
処理をコンピュータにより実行されることを特徴とする表示方法。
【請求項２】
表示された前記支払対象又は支払対象に関連する体の部位若しくは症状を示す情報の指定を受けると、指定された前記情報と同じ又は所定の類似範囲に属する支払対象又は支払対象に関連する体の部位又は症状を示す情報に対応するグラフ部分を前記グラフから抽出して表示する、
処理をコンピュータに実行させることを特徴とする請求項１記載の表示方法。
【請求項３】
抽出して表示する前記グラフ部分は、指定された前記情報と同じ又は所定の類似範囲に属する支払対象又は支払対象に関連する体の部位又は症状を示す各情報に対応する時間から所定期間前までのグラフ部分である、ことを特徴とする請求項２記載の表示方法。
【請求項４】
表示された前記グラフのうち、指定されたグラフ部分と所定の類似度で一致する過去の１又は複数のグラフ部分を特定し、特定したグラフ部分と同じ時間期間内の時間に対応づけられた支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を出力する、ことを特徴とする請求項１記載の表示方法。
【請求項５】
表示された前記グラフのうち、指定されたグラフ部分と所定の類似度で一致する過去の１又は複数のグラフ部分を特定し、特定したグラフ部分に対応する時間より所定時間後の時間範囲内の時間に対応づけられた支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を出力する、ことを特徴とする請求項１記載の表示方法。
【請求項６】
出勤及び退勤時刻が登録された就業情報に基づいて算出した勤務時間長の時系列変化を示すグラフを表示するとともに、登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を前記グラフと時間的に対応づけて表示する、
処理をコンピュータに実行させることを特徴とする表示方法。
【請求項７】
通信履歴に応じて算出した負荷の時系列変化を示すグラフを表示するとともに、登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を前記グラフと時間的に対応づけて表示する、
処理をコンピュータに実行させることを特徴とする表示方法。
【請求項８】
前記通信履歴は、送信メールの件数、受信メールの件数、送受信メールの件数、電子メールの送信または受信で通信されるデータ量、もしくは、これらの組合せであることを特徴とする請求項７記載の表示方法。
【請求項９】
少なくとも１のユーザについてのイベントが登録されたスケジュール情報から取得したイベントの種別に応じて算出した負荷の時系列変化を示すグラフを表示するとともに、前記１のユーザについて登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を前記グラフと時間的に対応づけて表示する、
処理をコンピュータに実行させることを特徴とする表示プログラム。
【請求項１０】
少なくとも１のユーザについてのイベントが登録されたスケジュール情報から取得したイベントの種別に応じて算出した負荷の時系列変化を示すグラフを表示するとともに、前記１のユーザについて登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を前記グラフと時間的に対応づけて表示する表示制御部
を有することを特徴とする表示制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、表示方法、表示プログラム及び表示制御装置に関する。
【背景技術】
【０００２】
体調管理や健康維持、いわゆるヘルスケアに関する情報通信技術の一例として、ユーザインタフェースシステムやスケジュール管理システムなどが挙げられる。
【０００３】
例えば、ユーザインタフェースシステムでは、操作入力部及び生体情報獲得部にて入力される情報によりユーザの状態及びユーザによる作業を監視し、ユーザの疲労を検出して疲労低減のための支援措置を決定し、出力部及びユーザインタフェース制御部を制御してユーザの疲労低減のための支援措置を実行する。これによって、ユーザの作業環境、作業状態、物理的状態、心理的状態及びユーザの作業内容に応じて、個別的な手段でユーザの疲労を軽減することを目指す。
【０００４】
また、スケジュール管理システムでは、従業員の携帯電話機で検出された体調データを閾値と比較し、比較結果に基づいて改編後スケジュールデータを作成する。その上で、スケジュール管理システムでは、改編前スケジュールデータと改編後スケジュールデータとに基づき、従業員のスケジュールの変更を表す変更内容データを作成し、該当する従業員の携帯電話機へと送信する。これによって、従業員等の長期的な疲労の度合いを少なくさせつつ、生産性を向上させることを目指す。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１８４１３９号公報
【特許文献２】特開２００５−５６０６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記の技術では、以下に説明するように、ヘルスケアを有効に支援できるとは限らない。
【０００７】
すなわち、上記のユーザインタフェースシステム及びスケジュール管理システムは、いずれもユーザに掛かる身体面または精神面の負荷に応じてその対策を実施するものである。ところが、負荷が体調に与える影響には個人差がある。例えば、同程度の負荷であっても体調に影響を受ける者もいれば、体調に影響を受けない者も存在する。これら前者及び後者の各人に同一の対策を画一的に実施したとしても限定的な効果しか発揮できない。このように、各々のユーザによってその適切な対処にもばらつきが生じるので、上記のユーザインタフェースシステム及びスケジュール管理システムでは、ヘルスケアを有効に支援できるとは限らない。
【０００８】
１つの側面では、本発明は、個人ごとのヘルスケアを有効に支援できる表示方法、表示プログラム及び表示制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
一態様の表示方法は、少なくとも１のユーザについてのイベントが登録されたスケジュール情報から取得したイベントの種別に応じて算出した負荷の時系列変化を示すグラフを表示するとともに、前記１のユーザについて登録された支払データから抽出した支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を前記グラフと時間的に対応づけて表示する、処理をコンピュータに実行させる。
【発明の効果】
【００１０】
ヘルスケアを有効に支援できる。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施例１に係るヘルスケア支援システムの構成例を示す図である。
【図２】図２は、実施例１に係るサーバ装置の機能的構成を示すブロック図である。
【図３】図３は、スケジュールデータの一例を示す図である。
【図４】図４は、支払データの一例を示す図である。
【図５】図５は、集計結果の一例を示す図である。
【図６】図６は、グラフの一例を示す図である。
【図７】図７は、実施例１に係る表示処理の手順を示すフローチャートである。
【図８】図８は、重回帰分析に用いる学習データの一例を示す図である。
【図９】図９は、分析結果の一例を示す図である。
【図１０】図１０は、分析結果の通知例を示す図である。
【図１１】図１１は、実施例１及び実施例２に係る表示プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して本願に係る表示方法、表示プログラム及び表示制御装置について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１３】
［システム構成］
図１は、実施例１に係るヘルスケア支援システムの構成例を示す図である。図１に示すヘルスケア支援システム１は、サーバ装置１０がクライアント端末３０の使用者であるユーザに掛かる身体面または精神面の負荷の時系列変化と体調変化の相関をクライアント端末３０に表示させるヘルスケア支援サービスを実施するものである。これによって、ユーザの個人特性に合ったヘルスケアの情報を提供し、もってヘルスケアを有効に支援する。
【００１４】
図１に示すように、ヘルスケア支援システム１には、サーバ装置１０と、クライアント端末３０Ａ〜３０Ｃとが収容される。なお、図１には、３つのクライアント端末が収容される場合を図示したが、サーバ装置１０が収容するクライアント端末の数は、図示の例に限定されず、任意の数のクライアント端末を収容できる。なお、以下では、クライアント３０Ａ〜３０Ｃの各装置を区別なく総称する場合には、「クライアント端末３０」と記載する場合がある。
【００１５】
これらサーバ装置１０及びクライアント端末３０の間は、ネットワーク５を介して相互に通信可能に接続される。かかるネットワーク５には、有線または無線を問わず、一例として、インターネット（Internet）を始め、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）などの任意の種類の通信網を採用できる。
【００１６】
サーバ装置１０は、クライアント端末３０に上記のヘルスケア支援サービスを提供するコンピュータである。
【００１７】
一実施形態として、サーバ装置１０は、パッケージソフトウェアやオンラインソフトウェアとして上記のヘルスケア支援サービスを実現する表示プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、サーバ装置１０は、上記のヘルスケア支援サービスを提供するＷｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記のヘルスケア支援サービスを提供するクラウドとして実装することとしてもかまわない。
【００１８】
クライアント端末３０は、サーバ装置１０から上記のヘルスケア支援サービスの提供を受けるコンピュータである。
【００１９】
一実施形態として、クライアント端末３０には、パーソナルコンピュータを採用できる。クライアント端末３０には、上記のパーソナルコンピュータなどの据置き型の端末のみならず、各種の携帯端末装置をクライアント端末３０として採用することもできる。例えば、携帯端末装置の一例として、スマートフォン、携帯電話機やＰＨＳ（Personal  Handyphone  System）などの移動体通信端末、さらには、ＰＤＡ（Personal  Digital  Assistants）などのスレート端末などがその範疇に含まれる。
【００２０】
［サーバ装置１０の構成］
図２は、実施例１に係るサーバ装置１０の機能的構成を示すブロック図である。図２に示すように、サーバ装置１０は、通信Ｉ／Ｆ（interface）部１１と、記憶部１３と、制御部１５とを有する。なお、サーバ装置１０は、図２に示す機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力デバイスなどの機能部を有することとしてもかまわない。
【００２１】
通信Ｉ／Ｆ部１１は、他の装置、例えばクライアント端末３０との間で通信制御を行うインタフェースである。
【００２２】
一実施形態として、上記の通信Ｉ／Ｆ部１１には、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部１１は、クライアント端末３０から負荷の時系列変化と体調変化の相関を示すグラフに関する表示要求を受信したり、あるいは上記の表示要求に対応するグラフの表示用データをクライアント端末３０へ送信したりする。
【００２３】
記憶部１３は、制御部１５で実行されるＯＳ（Operating  System）を始め、上記の表示プログラムなどの各種プログラムに用いられるデータを記憶する記憶デバイスである。
【００２４】
一実施形態として、記憶部１３は、サーバ装置１０における主記憶装置として実装される。例えば、記憶部１３には、各種の半導体メモリ素子、例えばＲＡＭ（Random  Access  Memory)、ＲＯＭ（Read  Only  Memory）やフラッシュメモリを採用できる。また、記憶部１３は、補助記憶装置として実装することもできる。この場合、ＨＤＤ（Hard  Disk  Drive）、光ディスクやＳＳＤ（Solid  State  Drive）などを採用できる。
【００２５】
記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、スケジュールデータ１３ａと、支払データ１３ｂとを記憶する。これらスケジュールデータ１３ａ及び支払データ１３ｂ以外にも、他の電子データ、例えばクライアント端末３０の識別情報、例えばアドレスなども併せて記憶することもできる。
【００２６】
スケジュールデータ１３ａは、イベントに関するスケジュールのデータである。
【００２７】
一実施形態として、スケジュールデータ１３ａには、スケジュールの開始時間、終了時間、期間、主題およびカテゴリなどの項目が対応付けられたデータを採用することができる。ここで言う「期間」とは、イベントの開始時間および終了時間によって定まる時間幅を指す。また、「カテゴリ」とは、イベントがユーザに与える負荷の分類を指す。例えば、「休み」、「日常業務」、「非日常業務」、「重要（お客様先等）」などが挙げられる。このうち、「休み」とは、公的でない私的なイベントに割り当てられる分類を指す。かかる「休み」は、ユーザの休息時間であり、心身共にリフレッシュが可能であるので、一面でマイナスの負荷として計上することもできる。また、「日常業務」とは、ユーザの職務の中でも日常的に行われる業務に割り当てられる分類を指す。また、「重要（お客様等）」とは、ユーザの職務の中でも他の業務よりも重要な業務に割り当てられる分類を指す。精神的な負荷に関し、特に高い負荷として計上することもできる。さらに、「非日常業務」とは、ユーザの職務の中でも日常業務および重要（お客様先等）を除く業務に割り当てられる分類を指す。かかる「非日常業務」は、日常業務および重要（お客様等）に比べれば、一面で業務における重要度は低いので、精神的な負荷に関し、マイナスの負荷として計上することもできる。なお、上記のスケジュールデータ１３ａを定義する項目は、上記の例示列挙に限らず、さらに項目を追加することもできるし、一部の項目を削除することもできる。
【００２８】
図３は、スケジュールデータ１３ａの一例を示す図である。図３には、あるユーザに関する２０１３年９月７日から２０１３年１１月７日までの３ヶ月分のスケジュールが抜粋して示されている。ここで、図３に示すカテゴリの値が「１」である場合にはイベントのカテゴリが「休み」であることを示し、「２」である場合にはイベントのカテゴリが「日常業務」であることを示し、「３」である場合にはイベントのカテゴリが「非日常業務」であることを示し、「４」である場合にはイベントのカテゴリが「重要（お客様等）」であることを示すこととする。なお図３では、あるユーザに関するレコードのみを示しているが、各レコードと対応づけてユーザの識別子を記憶し、複数のユーザについてのレコードを同じデータテーブル内で記憶しても構わない。その場合には、グラフの表示対象とするユーザの識別子と対応づけられたレコードのみを抽出して処理対象とすればよい。
【００２９】
例えば、図３に示す上から１番目のレコードを例に挙げれば、ユーザが２０１３年９月７日の８時３０分から１７時３０分までの５４０分間にわたって休みであり、このイベントがカテゴリ「休み」の範疇にあることを示す。この他、２番目以降のレコードについても、各項目の値は異なれども、コンピュータがイベントの識別、スケジュールの時間長やイベントが属するカテゴリの識別を実行できる点は同様である。また、図３に示すスケジュールデータ１３ａの全体で見れば、各レコードのうち、上から１番目、２番目、１３番目及び１４番目のレコード、さらに、下から７番目及び８番目のレコードのカテゴリが「休み」に属することを意味する。また、上から３番目から６番目までのレコード、８番目から１０番目までのレコード、１２番目のレコード、１５番目及び１６番目のレコード、さらに、下から２番目から５番目までのレコード、９番目のレコード、１２番目及び１３番目のレコードのカテゴリが「日常業務」に属することを意味する。他のカテゴリについても、カテゴリの属性値によってコンピュータがイベントを分類できる点に違いはない。
【００３０】
支払データ１３ｂは、健康に関する支払のデータである。
【００３１】
一実施形態として、支払データ１３ｂには、日付、区分、主題および費用などの項目が対応付けられたデータを採用できる。ここで言う「区分」とは、支払対象に関する区分けを指す。かかる支払対象の一例としては、健康維持や健康回復を目的とする措置への対価、いわゆる医療費の支払先を指し、例えば、ユーザが診療報酬を支払う医療機関や薬材料等を支払う薬局などが挙げられる。また、「主題」とは、上記の措置に関する主題を指し、例えば、支払対象に関連する体の部位若しくは症状などが挙げられる。また、「費用」とは、各種の医療費を指し、例えば、医療機関による診療報酬または薬局による薬材料などが挙げられる。なお、支払データ１３ｂを定義する項目は、上記の例示列挙に限らず、さらに項目を追加することもできるし、一部の項目を削除することもできる。
【００３２】
図４は、支払データ１３ｂの一例を示す図である。図４には、図３に示したスケジュールデータ１３ａを登録するユーザに関する支払データが示されている。図４に示す上から１番目のレコードを例に挙げれば、ユーザが２０１３年５月２日にコンタクトレンズの処方および緑内障の検査などの診療を眼科で受け、その費用が２３４６円であることを意味する。この他、２番目以降のレコードについても、各項目の値は異なれども、コンピュータが支払対象や費用などを識別できる点は同様である。
【００３３】
制御部１５は、各種のプログラムや制御データを格納する内部メモリを有し、これらによって種々の処理を実行するものである。
【００３４】
一実施形態として、制御部１５は、中央処理装置、いわゆるＣＰＵ（Central  Processing  Unit）として実装される。なお、制御部１５は、必ずしも中央処理装置として実装されずともよく、ＭＰＵ（Micro  Processing  Unit）として実装されることとしてもよい。また、制御部１５は、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などのハードワイヤードロジックによっても実現できる。
【００３５】
制御部１５は、各種のプログラムを実行することによって下記の処理部を仮想的に実現する。例えば、制御部１５は、図２に示すように、第１の取得部１５ａと、第２の取得部１５ｂと、受付部１５ｃと、集計部１５ｄと、表示制御部１５ｅとを有する。
【００３６】
第１の取得部１５ａは、スケジュールデータを取得する処理部である。
【００３７】
一実施形態として、第１の取得部１５ａは、次に挙げる経路を通じて、各ユーザのスケジュールデータを取得することができる。例えば、第１の取得部１５ａは、ユーザが所属する組織によって運用される基幹システムが有するサーバ装置等で実行されるグループウェアからスケジュールデータを取得することができる。なお、上記のサーバ装置１０が基幹システムの一部として実装される場合、必ずしも外部装置からスケジュールデータを取得せずともよく、上記のヘルスケア支援サービスには、記憶部１３に予め記憶させたスケジュールデータを用いることとすればよい。また、第１の取得部１５ａは、クライアント端末３０にインストールされたスケジューラ等のアプリケーションプログラムからスケジュールデータを取得することもできる。
【００３８】
第２の取得部１５ｂは、支払データを取得する処理部である。
【００３９】
一実施形態として、第２の取得部１５ｂは、次に挙げる経路を通じて、各ユーザの支払データを取得することができる。例えば、ユーザが医療機関で診療または薬局で調剤を受ける場合、医療機関等からユーザが所属する組織、いわゆる事業主の健康保険組合へ保険請求がなされる。この場合、第２の取得部１５ｂは、健康保険組合へ保険請求された診療報酬または薬材料等が電子化された支払データを管理するサーバ装置から支払データを取得することができる。なお、上記の第１の取得部１５ａと同様、サーバ装置１０が基幹システムの一部として実装される場合、必ずしも外部装置から支払データを取得せずともよく、上記のヘルスケア支援サービスには、記憶部１３に予め記憶させた支払データを用いることとすればよい。また、第２の取得部１５ｂは、クライアント端末３０にインストールされた家計簿系のアプリケーションプログラムに入力された支払データを取得することもできる。
【００４０】
これら第１の取得部１５ａ及び第２の取得部１５ｂによるデータの取得は、一定期間が経過する度、あるいは規定時間になる度に、クライアント端末３０からのリクエストを介さずに実行することもできるし、クライアント端末３０から上記のグラフの表示要求を受け付ける度にオンデマンドで実行することもできる。
【００４１】
受付部１５ｃは、クライアント端末３０から表示要求を受け付ける処理部である。
【００４２】
一実施形態として、受付部１５ｃは、クライアント端末３０が有するユーザインタフェースを介して上記のグラフの表示要求を受け付けることができる。例えば、サーバ装置１０が基幹システムの一部として実装される場合、受付部１５ｃは、基幹システムが実行するグループウェア等によって提供されるメニュー画面上に上記のグラフの表示要求に対応するＧＵＩを追加することができる。また、上記のヘルスケア支援サービスを提供する基盤のフロントエンドとしてクライアント向けのアプリケーションプログラムがクライアント端末３０にインストールされている場合、受付部１５ｃは、アプリケーションプログラムが提供するＧＵＩを介して上記のグラフの表示要求を受け付けることもできる。なお、アプリケーションプログラムがバックグラウンドで動作する場合、アプリケーションプログラムが自動的に発行するグラフの表示要求を受け付けることもできる。
【００４３】
なお、ここでは、サーバ装置１０がプル型の通知を行う場合を例示したが、必ずしも上記のヘルスケア支援サービスがオンデマンドで提供されずともよく、サーバ装置１０はプッシュ型の通知を行うこともできる。例えば、上記のグラフを定期的に通知することもできるし、また、記憶部１３に記憶された支払データに変更がある場合に上記のグラフを通知することもできる。この場合、サーバ装置１０は、必ずしも受付部１５ｃを有さずともかまわない。
【００４４】
集計部１５ｄは、スケジュールデータからカテゴリ別の負荷を集計する処理部である。
【００４５】
一実施形態として、集計部１５ｄは、受付部１５ｃによって上記のグラフの表示要求が受け付けられた場合に、所定のスパンに対応するスケジュールデータ１３ａのレコードを読み出す。例えば、集計部１５ｄは、記憶部１３に記憶されたスケジュールデータ１３ａのうち、スケジュールの開始時間として登録された日付がクライアント端末３０から表示要求を受け付けた時点から所定の遡及期間、例えば３ヶ月間まで遡及されたスパンに含まれるレコードを読み出す。その上で、集計部１５ｄは、先に読み出したレコードのうち同一のカテゴリを持つレコード同士の期間を日次の単位で集計する。これによって、カテゴリ別の期間の集計値が日次の単位で算出される。このようにしてカテゴリ別に算出された期間の集計値は、その日に各カテゴリに対応するイベントで発生した負荷の一態様となる。なお、ここでは、集計の単位を日次としたが、それよりも集計の粒度を大きくして週次、月次としてもよいし、集計の粒度を小さくして所定の時間帯ごととしてもかまわない。
【００４６】
図５は、集計結果の一例を示す図である。図５には、図３に示した２０１３年９月７日から２０１３年１１月７日までの３ヶ月分のスケジュールデータ１３ａが集計された場合の集計結果が示されている。例えば、上記の３ヶ月のうち９月１０日における負荷を集計する場合、図３に示したスケジュールデータ１３ａが有するレコードのうち上から４番目のレコードから上から７番目のレコードまでの４つのレコードが集計の対象となる。この場合、４つのレコードの中にカテゴリが「１」または「４」であるレコード、すなわちカテゴリが「休み」または「重要（お客様等）」であるレコードは存在しない。よって、９月１０日における休み及び重要（お客様等）の集計値はいずれも「０」と算出される。一方、４つのレコードの中にカテゴリが「２」であるレコードは、３つ存在する。すなわち、カテゴリが「日常業務」であるレコードは、上から４番目のレコード、上から５番目のレコード及び上から６番目のレコードの３つである。したがって、９月１０日における日常業務の集計値は「２４０（＝１２０＋６０＋６０）ｍｉｎ」と算出される。また、４つのレコードの中にカテゴリが「３」であるレコードは、１つ存在する。すなわち、カテゴリが「非日常業務」であるレコードは、上から７番目のレコードの１つである。したがって、９月１０日における非日常業務の集計値は「６０ｍｉｎ」と算出される。このように、他の日付においても、集計結果は違えども同様のロジックで期間の集計値がカテゴリごとに算出される。
【００４７】
表示制御部１５ｅは、負荷の時系列変化を示すグラフと、支払対象又は支払対象に関連する体の部位若しくは症状を示す情報とを時間的に対応付けてクライアント端末３０に表示させる処理部である。
【００４８】
一実施形態として、表示制御部１５ｅは、集計部１５ｄによって日次の単位で集計されたカテゴリ別の負荷を日付順に整列させることによってカテゴリ別の負荷の時系列変化を示すグラフを生成する。このとき、表示制御部１５ｅは、負荷の時系列変化を示すグラフをカテゴリごとに生成することもできるが、各カテゴリに対応する負荷の時系列変化が１つに集約されたグラフを生成することもできる。具体的には、表示制御部１５ｅは、グラフを形成する負荷および時間の２つの成分に関する座標軸のうち負荷の座標軸に対応する方向に向けて各カテゴリの期間の集計値を所定の順序で堆積させる。例えば、「休み」、「日常業務」、「重要（お客様先等）」、「非日常業務」のカテゴリ順に期間の集計値を累積すると共に各カテゴリ間で期間の集計値を塗りつぶす表示色を変えることによって各カテゴリが層に分かれたグラフを生成できる。
【００４９】
これと並行して、表示制御部１５ｅは、記憶部１３に記憶された支払データ１３ｂのうち上記のスパンに対応するレコードを読み出す。続いて、表示制御部１５ｅは、グラフの時間軸上で先に読み出された支払データ１３ｂの各レコードが持つ日付に対応する位置に、当該レコードに含まれる支払対象の区分又は主題のいずれかを示す標示を対応付ける。かかる標示の形状には、任意の記号や図形を採用することができ、また、標示の寸法も任意のサイズとすることができる。例えば、費用が大きくなるにしたがって標示のサイズも大きくすることができる。このようにしてユーザに掛かる身体面及び精神面の負荷の時系列変化と体調変化の相関を示すグラフが生成されることになる。なお、以下では、支払対象又は支払対象に関連する体の部位若しくは症状を示す標示のことを「体調標示」と記載し、グラフの中でも体調標示が対応付けられたグラフのことを「体調標示付きグラフ」と記載する場合がある。
【００５０】
図６は、グラフの一例を示す図である。図６には、図５に示したスケジュールデータ１３ａの集計結果と、図４に示した支払データ１３ｂとから生成された体調標示付きグラフが示されている。この例では、横軸の時間軸目盛として１週間おきの日付が表示されているが、時間軸の目盛を例えば１日などのもっと短い区間で分けるか、１０日とか１か月といったもっと長い区間で分けるかは、ユーザの指定により設定されても構わないし、表示期間の長さに応じて設定されても構わない。さらに、図６には、「休み」、「日常業務」、「重要（お客様先等）」、「非日常業務」のカテゴリ順に各カテゴリの期間の集計値を累積すると共に各カテゴリ間で期間の集計値を塗りつぶす表示色が変えられたグラフが図示されている。
【００５１】
図６に示す体調標示付きグラフの場合、図４に示した支払データ１３ｂに含まれるレコードのうち下から１番目のレコード及び下から２番目のレコードが表示の対象とする２０１３年９月７日から２０１３年１１月７日までの３ヶ月のスパンに含まれる。このため、図６に示す体調標示付きグラフでは、「休み」、「日常業務」、「重要（お客様先等）」、「非日常業務」の負荷の時系列変化を示すグラフと共に、当該グラフの時間軸上の２０１３年１１月２日に相当する位置に診療及び調剤に関するマークが体調標示として対応付けられる。
【００５２】
上記の負荷の時系列変化の表示によって、「非日常業務」、「日常業務」及び「重要（お客様先等）」の負荷や、勤務時間の長さと、身体的な負荷との相関をユーザに自覚させやすくできる。加えて、上記の体調標示の対応付けによって、ユーザに、各カテゴリの負荷から該ユーザが感じた精神的な負荷という、業務負荷の精神的な負荷に対する影響についての自分の傾向についても把握しやすくできる。例えば、同じ勤務時間長であっても、カテゴリ間、すなわち日常業務以外の業務であって重要な客先の業務を除いた「非日常業務」と「日常業務」との間あるいは「日常業務」と日常業務よりも丁寧な対応が求められる「重要（お客様等）」との間で精神面の負荷は異なる。例えば、ユーザに対して、「非日常業務」が多いほど一面で重圧から解放された新鮮な精神状態に近づいていることを自覚させたり、また、「重要（お客様等）」が多いほど一面で重圧を受けて精神的な疲労が蓄積していることを自覚させたりする。
【００５３】
例えば、図６に示す体調標示付きグラフからは、ユーザが体調変化が生じる２０１３年１１月２日以前に「重要（お客様等）」の業務に従事し、その後に「非日常業務」の業務に従事して「休み」のスケジュールに入った事実を読み取ることができる。どのような業務負荷が、どのような精神面の負荷になるかは、ユーザごとに異なる。体調標示付きグラフを出力することによって、ユーザに対して、自分は重圧から解放された直後に風邪で体調を崩しやすいという負荷と体調変化の相関傾向を把握しやすくさせることができる。これによって、ユーザは、体調変化の原因を究明したり、あるいは上記の負荷の傾向をたどる場合に風邪への対処を予め行ったりすることができる。したがって、体調標示付きグラフによれば、個人ごとのヘルスケアを有効に支援することが可能になる。
【００５４】
その上で、表示制御部１５ｅは、このようにして作成された体調標示付きグラフの表示用データをクライアント端末３０へ送信することによって体調標示付きグラフをクライアント端末３０に表示させる。
【００５５】
［処理の流れ］
図７は、実施例１に係る表示処理の手順を示すフローチャートである。この表示処理は、一定期間が経過する度、あるいは規定時間になる度に、クライアント端末３０からのリクエストを介さずに実行することもできるし、クライアント端末３０から上記のグラフの表示要求を受け付ける度に実行することもできる。
【００５６】
図７に示すように、集計部１５ｄは、記憶部１３に記憶されたスケジュールデータ１３ａのうち、スケジュールの開始時間として登録された日付がステップＳ１０１の実行時点の日付から所定の遡及期間まで遡ったスパンに含まれるレコードを読み出す（ステップＳ１０１）。
【００５７】
続いて、集計部１５ｄは、ステップＳ１０１で読み出したレコードのうち同一のカテゴリを持つレコード同士の期間を所定の時間幅、例えば日次の単位で集計する（ステップＳ１０２）。これによって、カテゴリ別の期間が負荷として日次の単位で集計される。
【００５８】
その後、表示制御部１５ｅは、ステップＳ１０２で日次の単位で集計されたカテゴリ別の負荷を日付順に整列させることによってカテゴリ別の負荷の時系列変化を示すグラフを生成する（ステップＳ１０３）。
【００５９】
また、表示制御部１５ｅは、記憶部１３に記憶された支払データ１３ｂのうち上記のステップＳ１０１でスケジュールデータ１３ａのレコードが読み出されたスパンに対応するレコードを読み出す（ステップＳ１０４）。
【００６０】
その後、表示制御部１５ｅは、グラフの時間軸上でステップＳ１０４で読み出された支払データ１３ｂの各レコードが持つ日付に対応する位置に、当該レコードに含まれる支払対象の区分又は主題のいずれかを示す標示を対応付ける（ステップＳ１０５）。これによって、体調標示付きグラフ、すなわちユーザに掛かる身体面及び精神面の負荷の時系列変化と体調変化の相関を示すグラフが生成されることになる。
【００６１】
その上で、表示制御部１５ｅは、ステップＳ１０５の体調標示の対応付けにより生成された体調標示付きグラフの表示用データをクライアント端末３０へ送信することによって体調標示付きグラフをクライアント端末３０に表示させ（ステップＳ１０６）、処理を終了する。
【００６２】
［効果の一側面］
上述してきたように、本実施例に係るサーバ装置１０は、１のユーザについての、業務等の負荷に関する時系列変化を示すグラフと共に、健康に関する支払対象又は支払対象に関連する体の部位若しくは症状を示す情報をグラフに時間的に対応付けて表示する。それ故、本実施例に係るサーバ装置１０では、ユーザに掛かる身体面及び精神面の負荷の時系列変化と体調変化の相関を可視化できる。したがって、本実施例に係るサーバ装置１０によれば、個人ごとのヘルスケアを有効に支援できる。さらに、本実施例に係るサーバ装置１０では、通常の業務を行うだけで自然に蓄積されるデータ、例えばスケジュールや健康保険に関するデータを上記の体調標示付きグラフの生成に用いるので、グラフの生成に伴って特段の情報を入力させずともよい。
【実施例２】
【００６３】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００６４】
［体調変化の項目指定］
上記の実施例１では、上記の表示処理の実行開始時点から所定の遡及期間にわたって遡ったスパンのスケジュールデータ及び支払データから体調標示付きグラフを生成する場合について例示したが、グラフの生成に用いるスパンはこれに限定されない。例えば、サーバ装置１０は、支払対象又は支払対象に関連する体の部位若しくは症状を示す情報の指定を受けることによってグラフの生成に用いるスパンを決定することもできる。
【００６５】
具体的には、サーバ装置１０は、クライアント端末３０から表示要求を受け付ける場合に、診療科、体の部位または症状のうち少なくともいずれか１つを指定できるＧＵＩコンポーネントをクライアント端末３０が表示要求を受け付けるメニュー画面に設けることができる。例えば、診療科に関するＧＵＩコンポーネントとして、眼科、皮膚科、内科や外科などの選択肢が設けられたラジオボタンやプルダウンメニューを設けることができる。また、体の部位に関するＧＵＩコンポーネントとして、頭部、胸部、腹部、あるいは、五体よりも粒度が小さい目、鼻、口などなどの選択肢が設けられたラジオボタンやプルダウンメニューを設けることができる。さらには、症状に関するＧＵＩコンポーネントとして、風邪、皮膚炎症などの選択肢が設けられたラジオボタンやプルダウンメニューを設けることができる。
【００６６】
その上で、サーバ装置１０は、記憶部１３に記憶された支払データ１３ｂのレコードの中から、上記のＧＵＩコンポーネントを介して指定を受け付けた診療科、体の部位または症状と同一または所定の類似範囲に属する支払対象又は支払対象に関連する体の部位又は症状を含むレコードを検索する。例えば、サーバ装置１０は、上記のＧＵＩコンポーネントを介して指定を受け付けた診療科、体の部位または症状と一致する支払対象、体の部位または症状、さらには、これらとキーワードが関連または類語となる支払対象、体の部位または症状を検索する。その後、サーバ装置１０は、検索結果として得られた支払対象、体の部位または症状を含む支払データ１３ｂのレコードが持つ日付から所定の遡及期間にわたって遡ったスパンを負荷の時系列変化を示すグラフの生成に用いるスパンと設定し、体調標示付きグラフを生成することができる。このとき、健康に関する支払日付の当日から直前数日前の負荷が体調変化の原因である可能性が高いので、その期間を上記のスパンの設定に用いる遡及期間とすることができる。
【００６７】
これによって、サーバ装置１０は、クライアント端末３０を介して指定された体調不良と同じ体調不良が過去に発生した時の、仕事の負荷量を表示できる。ひいては、どのような負荷量の時に、同じ体調不良が発生しやすいかをユーザに知らしめることができる。例えば、頭痛お薬や頭痛に関する指定を受け付けて、過去に頭痛が発生した直前２週間の業務負荷の時系列変化を示すグラフを生成することができる。このようなグラフを見ることで、ユーザに対して、自分はどのような業務負荷がかかった場合に頭痛という症状を発症しやすいかを知らしめることができる。
【００６８】
［負荷の集計方法１］
上記の実施例１では、負荷をカテゴリ別に集計する場合を例示したが、必ずしも負荷をカテゴリ別に集計せずともかまわない。例えば、サーバ装置１０は、カテゴリの相違を問わず、所定の時間幅、例えば日次の単位ごとに当該時間幅に含まれるカテゴリ「２」〜「４」に対応するイベントがスケジュール登録された期間を集計することによってカテゴリ総合の負荷を算出するもできる。また、サーバ装置１０は、カテゴリ「２」〜「４」のうち少なくともいずれか１つ以上のカテゴリ、例えば日常業務の１つまたは日常業務と重要（お客様等）の２つに該当するイベントがスケジュール登録された期間に絞って集計し、その集計値を当該時間幅における負荷とすることもできる。
【００６９】
［負荷の集計方法２］
上記の実施例１では、カテゴリ「１」〜「４」の期間をいずれも正の値として集計する場合を例示したが、必ずしも全てのカテゴリの期間を正の値として集計せずともかまわない。例えば、カテゴリ「１」〜「４」のうちカテゴリ「１」及びカテゴリ「３」、すなわち「休み」及び「非日常業務」の期間については負の値として集計することもできる。すなわち、サーバ装置１０は、日付ごとに当該日付を持つスケジュールデータ１３ａのレコードの期間のうちカテゴリ「２」及びカテゴリ「４」、すなわち「日常業務」及び「重要（お客様等）」の期間を正の値として加算する一方で、カテゴリ「１」及びカテゴリ「３」、すなわち「休み」及び「非日常業務」の期間を負の値として減算することによって日次の負荷を集計することとしてもよい。これによって、負荷をプラスマイナスの両面で評価できる結果、より実効的な負荷を算出することができる。なお、ここでは、正の集計値から負の集計値を減算する場合を例示したが、負の集計値による減算を実行せずに、カテゴリ別の負の集計値を負荷の座標軸が持つ負の方向へ堆積させて負荷の時系列変化を示すグラフを生成することもできる。
【００７０】
［負荷の収集方法］
上記の実施例１では、イベントが登録されたスケジュールデータから負荷を取得する場合を例示したが、必ずしも負荷の収集源がスケジュールデータでなくともかまわない。
【００７１】
例えば、ユーザが所属する組織によって運営される基幹システムが実行するグループウェア等で出勤時刻および退勤時刻が電子的にタイムカードとして管理される場合、スケジュールデータの代わりにタイムカードデータを取得することとしてもかまわない。この場合、サーバ装置１０は、出勤時刻および退勤時刻の差を計算することによって勤務時間長を日付ごとに算出することができる。かかる日次の勤務時間長を負荷として用いることもできる。このようにタイムカード情報を用いる場合、タイムカードが打刻されていない日付は休みと見なして服務と休みに分けて集計することもできる。なお、組織では、給与または労務の観点からも出勤時刻および退勤時刻が電子的に管理される場合が多い。このことから、必ずしもタイムカードデータから勤務時間長を求めずともよく、給与データまたは労務データから勤務時間長を求めることとしてもかまわない。
【００７２】
また、上記のタイムカード以外で電子的に管理された情報から勤務時間長を求めることもできる。例えば、ユーザが所属する組織では、セキュリティの観点から、ＩＣ（Integrated  Circuit）カードを通じて、組織が有する施設への入退場が管理されるケースも多い。このことから、サーバ装置１０は、ユーザごとに入場時刻および退場時刻が対応付けられた入退場データを用いて、入場時刻および退場時刻の差を計算することによって勤務時間長を日付ごとに算出することもできる。
【００７３】
［通信履歴の適用］
上記の実施例１では、負荷として勤務時間長を用いる場合を例示したが、必ずしも勤務時間長を負荷として用いずともかまわない。例えば、サーバ装置１０は、通信履歴を負荷として算出することもできる。一例として、サーバ装置１０は、電子メールの通信履歴を負荷の算出に用いることができる。かかる電子メールの通信履歴の一例としては、送信メールの件数、受信メールの件数、送受信メールの件数、電子メールの送信または受信で通信されるデータ量、もしくは、これらの組合せを用いることができる。
【００７４】
例えば、電子メールの通信履歴を用いる一例として、送信メール及び受信メールのカテゴリごとに件数を集計して各カテゴリの件数を負荷として用いる場合を例示する。この場合、サーバ装置１０は、上記のスパンに含まれる日付ごとに、当該日付に送信が行われた送信メール及び受信が行われた受信メールを集計の対象とし、送信メールの件数及び受信メールの件数を集計する。このようにして上記のスパンに含まれる日付ごとに得られた送信メールの件数及び受信メールの件数をカテゴリ別の負荷とし、上記の実施例１と同様に、体調標示付きグラフを生成することができる。なお、ここでは、送信メール及び受信メールを区別して集計する場合を例示したが、上記の負荷の集計方法１と同様に、総量、すなわち送受信メールの件数を集計することができるのは言うまでもない。
【００７５】
ここで、送信メール及び受信メールは、互いの件数が同じであっても業務に関する負荷が必ずしも同一であるとは限らない。すなわち、受信メールの場合、ユーザは、受信メールの内容を確認する手順だけで済む場合もあるが、送信メールの場合、ユーザは、文面の推敲、タイピング、宛先の設定などの手順を慎重に確認しながら行う。このように、１件あたりの負荷で言えば、「受信メール＜送信メール」であるとみなすことができる。
【００７６】
このことから、サーバ装置１０は、送信メール及び受信メールのカテゴリ間で各カテゴリの件数を正規化してカテゴリ総合の負荷を算出することもできる。例えば、サーバ装置１０は、受信メールの重みを「１」、送信メールの重みを「３」とし、互いの件数に加重平均を行うことによって得た送信メール及び受信メールの加重平均値をカテゴリ総合の負荷とすることができる。このとき、サーバ装置１０は、送信メールの宛先によってさらに異なる重みを付与することもできる。例えば、社内を宛先とする場合と、社外を宛先とする場合では、メールを送信する手順が同一であっても各手順で求められる正確性は「社内＜社外」であると言える。このため、サーバ装置１０は、送信メールの宛先が社内である場合の重みを「３」とし、社外である場合の重みを「４」として送信メール及び受信メールの加重平均値を算出することもできる。
【００７７】
このように、電子メールの通信履歴を負荷の算出に用いる場合にも、上記の実施例１と同様に、ヘルスケアを有効に支援できると共に、グラフの生成に伴って特段の情報を入力させずともよいという効果を得ることができる。
【００７８】
なお、ここでは、一例として、送信メール及び受信メールのカテゴリごとに件数を集計する場合を例示したが、送信メールのデータ量、受信メールのデータ量または送受信メールのデータ量を集計する場合も、件数をデータ量と読み替えることによってカテゴリ別の負荷、さらには、カテゴリ総合の負荷を算出できる。
【００７９】
また、ここでは、一例として、電子メールの通信履歴を負荷の算出に用いる場合を例示したが、適用範囲が電子メールの通信履歴に限定される訳ではない。かかる電子メールの通信履歴の他、通話やチャットの履歴を負荷の算出に用いることができるは言うまでもない。例えば、通話履歴を用いる場合、上記のスパンに含まれる日付ごとに発信回数、着信回数、送話時間、受話時間、通話時間またはこれらの組合せを負荷として集計すればよいし、チャット履歴を用いる場合、上記のスパンに含まれる日付ごとにメッセージの送信回数、受信回数またはこれらの組合せを負荷として集計すればよい。
【００８０】
［データマイニング］
上記の実施例１では、体調標示付きグラフをクライアント端末３０に表示させる場合を例示したが、体調標示付きグラフの代わりに、あるいは体調標示付きグラフと共に、体調標示付きグラフに関する分析結果を通知することもできる。
【００８１】
例えば、サーバ装置１０は、体調標示付きグラフに各種のデータマイニングを実行することができる。かかるデータマイニングの一例として、サーバ装置１０は、機械学習、例えば重回帰分析を適用することができる。この場合、一例として、スケジュールデータ１３ａ及び支払データ１３ｂから導出される下記の学習データを重回帰分析に用いることができる。かかる学習データの一例としては、日付ごとに重回帰分析に用いる１つの目的変数に対し、複数の説明変数が対応付けられたデータを採用できる。
【００８２】
図８は、重回帰分析に用いる学習データの一例を示す図である。図８に示す学習データは、目的変数の一例として、健康注意度合を含む。かかる健康注意度合とは、ユーザが健康に注意した方がよい度合いを指す。例えば、健康注意度合は、支払データ１３ｂに含まれる支払対象又は支払対象に関連する体の部位若しくは症状などの体調変化に関する項目を量的データへ数値化できる。具体例を挙げれば、支払対象の区分に０〜１までの値に正規化された重みを付与できる。例えば、内科の重みを「0.5」、眼科の重みを「0.4」、皮膚科の重みを「0.3」、歯科の重みを「0.3」とする。このとき、支払データ１３ｂのレコードが有する日付と同一である当日の健康注意度合には、その健康注意度合の値として支払対象の区分に対応する重みの値がそのまま付与される。さらに、当日の前後の日付の健康注意度合には、当日の健康注意度合の値の所定の割合、例えば１／３が付与される。
【００８３】
さらに、図８に示す学習データは、説明変数の一例として、スケジュールデータ１３ａの各レコードが有する日付ごとに、当該日付から遡及させる「期間別」、例えば直近３０日や直近ｎ週間など、「カレンダ属性別」、例えば曜日、全日、祝日や休日など、並びに、「カテゴリ別」の期間の平均値及び最大値を含む。すなわち、説明変数として、休み_Sun_30_平均、休み_Mon_30_平均、休み_Tue_30_平均、休み_Wed_30_平均、休み_Thu_30_平均、休み_Fri_30_平均、休み_Sat_30_平均、・・・、重要（お客様等）_休日_7_最大などが含まれる。このうち、例えば、「休み_Sun_30_平均」は、日付から３０日にわたって遡った期間に含まれる日曜日におけるカテゴリ「休み」の平均値を指す。また、「重要（お客様等）_休日_7_最大」は、日付から７日にわたって遡った期間に含まれる休日、すなわち土日及び祝祭日を含む日にちにおけるカテゴリ「重要（お客様等）」の最大値を指す。
【００８４】
例えば、図８に示すレコードのうち２０１３年６月８日のレコードの例で言えば、図４に示した支払データ１３ｂの上から４番目のレコードに支払対象の区分「皮膚科」が登録されていることを背景に、皮膚科に対応する重み「0.3」が健康注意度合に設定されていることを示す。さらに、「休み_Sun_30_平均」には、２０１３年６月８日から３０日にわたって遡った期間に含まれる日曜日におけるカテゴリ「休み」の平均値として「540（min）」が算出されていることを示す。この他、「重要（お客様等）_休日_7_最大」には、２０１３年６月８日から７日にわたって遡った期間に含まれる休日、すなわち土日及び祝祭日を含む日にちにおけるカテゴリ「重要（お客様等）」の最大値として「0（min）」が算出されていることを示す。他のレコードについても、各項目の値は異なれども、各項目の値が算出される方法は同様である。
【００８５】
ここで、サーバ装置１０は、図８に示した学習データのうち健康注意度合を左辺の目的変数に設定すると共にその他の項目を右辺の説明変数に設定することによって学習データのレコード数に対応する数の連立方程式を生成する。このとき、各連立方程式の間で同一の説明変数には、共通する値の係数が付与されるものとする。すなわち、説明変数「休み_Sun_30_平均」の係数は、各連立方程式において共通する。その上で、サーバ装置１０は、各説明変数の係数等を始めとするパラメータを重回帰分析を実行することによって算出する。
【００８６】
このようにして重回帰分析を行った結果が図９の通りとなる。図９は、分析結果の一例を示す図である。図９には、各説明変数の係数及び影響度の逆数が影響度の逆数が小さい順、すなわち健康注意度合への影響が大きい順に示されている。ここで言う「影響度の逆数」とは、説明変数の係数が各日付の説明変数の分散で除算されたものを指す。図９に示す分析結果から、図３に示したスケジュールデータ１３ａ及び図４に示した支払データ１３ｂを持つユーザの場合、上位３つが「非日常業務_休日_7_平均」、「非日常業務_全日_30_最大」、「非日常業務_平日_30_最大」であるので、健康注意度合に大きな影響を与える一因が非日常業務であることがわかる。
【００８７】
この場合、サーバ装置１０は、下記のメッセージをクライアント端末３０へ出力することもできる。すなわち、一例としては、“健康アドヴァイス「○○さんにとって［非日常業務］は元気の源です。疲れを感じてきたら気分転換をしましょう。また、休日出勤はストレスの元となるので適度な範囲に留める方がよいでしょう．．．」”といったメッセージが挙げられる。
【００８８】
また、サーバ装置１０は、図１０に示すグラフ表示を行うこともできる。図１０は、分析結果の通知例を示す図である。図１０には、２０１４年１月２０日時点での分析結果から健康に関するアラートの標示がグラフ上に示されている。すなわち、図９に示した分析結果で得られた各説明変数の係数と、２０１４年１月２０日のレコードに含まれる各説明変数とを乗算して足し合わせることによって健康注意度合を算出し、健康注意度合がゼロ以上、あるいは所定の閾値、例えば０．３以上である場合には、図１０に示すように、「体調に注意！」といったアラートの標示を表示させることができる。
【００８９】
このように、クライアント端末３０に体調標示付きグラフの分析結果を通知することによって、目視だけでは把握が困難な情報、例えばユーザの健康にとってどのようなイベントのカテゴリが重要であるか、あるいは現時点での健康状態が良い傾向にあるのかどうかを容易に把握させることができる。
【００９０】
なお、ここでは、支払対象の各区分を共通して数値化する場合を例示したが、上記の重回帰分析を支払対象の区分ごとに実行することによって区分ごとの分析を行って通知を行うようにしてもかまわない。
【００９１】
［類似グラフ部分の特定］
また、上記のサーバ装置１０は、体調標示付きグラフのうちクライアント端末３０から指定されたグラフ部分と所定の類似度で一致する過去の１又は複数のグラフ部分を特定し、特定したグラフ部分に対応する時間より所定時間後の時間範囲内の時間に対応づけられた支払対象又は支払対象に関連する体の部位若しくは症状を示す情報を出力することもできる。
【００９２】
例えば、サーバ装置１０は、類似度の一例として相関係数を算出することによってクライアント端末３０から指定されたグラフ部分と類似するグラフ部分を特定することもできる。
【００９３】
これを具体的に説明すると、サーバ装置１０は、クライアント端末３０からグラフ部分の指定を受け付ける。例えば、サーバ装置１０は、負荷の時系列変化を示すグラフ上でポインティングデバイス等によって点の指定を受け付けたり、あるいは日付等の入力を受け付けることによって時点の指定を受け付けることができる。この場合、指定を受け付けた時点を含む所定の部分、例えば指定の時点を基準とする前後の所定の区間、指定の時点から所定の期間にわたって遡った区間または指定の時点から所定の期間にわたって時間を進めた区間をグラフ部分とすることできる。また、サーバ装置１０は、グラフ上でドラッグ＆ドロップ等による範囲指定の操作を受け付けることによってグラフ部分そのものを受け付けるようにしてもかまわない。
【００９４】
その後、サーバ装置１０は、負荷の時系列変化を示すグラフの波形上で先に指定を受け付けたグラフ部分と同一の時間長を持つ窓をシフトさせる。そして、サーバ装置１０は、負荷の時系列変化を示すグラフ上で上記の窓をシフトさせる度に、先に指定を受け付けたグラフ部分の波形と、当該窓に含まれるグラフ部分の波形との間で相関係数を算出する。その後、サーバ装置１０は、相関係数が最大もしくは閾値以上となるシフト量を抽出する。
【００９５】
このように相関係数を算出する場合、サーバ装置１０は、各カテゴリの負荷の時系列変化を表すグラフの中からいずれか１つのグラフを上記の相関係数の算出を実行する対象とするグラフとして択一的に用いるか、あるいは上記の負荷の集計方法１で説明したカテゴリ総合の負荷の時系列変化を表すグラフを上記の相関係数の算出に用いることができる。
【００９６】
その上で、サーバ装置１０は、このようにして得た１又は複数のシフト量で定まる類似のグラフ部分と共に、当該類似のグラフ部分に対応する時間より所定時間後の時間範囲内の時間に対応づけられた支払対象又は支払対象に関連する体の部位若しくは症状の標示をクライアント端末３０に表示させる。
【００９７】
これによって、クライアント端末３０から指定を受け付けたグラフ部分の負荷の傾向と類似する傾向を持つ過去のグラフ部分でどのような体調不良が発生したかを表示できる。なお、ここでは、類似のグラフ部分と共に支払データ１３ｂから得られる体調変化の標示を表示させる場合を例示したが、体調変化の標示だけを表示させることとしてもかまわない。
【００９８】
［スタンドアローン］
上記の実施例１では、クライアントサーバシステムを構築することによって上記のヘルスケア支援サービスを提供する場合を例示したが、必ずしもクライアントサーバシステムが構築されずともかまわない。例えば、クライアント端末３０に図７に示した表示処理を始めとする各種処理をスタンドアローンで実行させることもできる。この場合、図７に示した表示処理を始めとする各種処理を実現する表示プログラムをプリインストールしたり、ネットワークや記録媒体を介してインストールさせればよい。すなわち、集計部１５ｄ及び表示制御部１５ｅと同様の処理を実行する処理部をクライアント端末３０に実装することとすればよい。この場合、第１の取得部１５ａ及び第２の取得部１５ｂの各処理部をクライアント端末３０にさらに実装することによってスケジュールデータ及び支払データを取得するか、あるいはクライアント端末３０が有する記憶部にスケジュールデータ１３ａ及び支払データ１３ｂを予め記憶させておくことができる。
【００９９】
さらに、上記の実施例では、ユーザが自身についての業務負荷と体調との関係を参照する例を用いて説明を行ったが、これに限る必要はない。例えば、第一のユーザによる操作によって、第二のユーザの指定を受け付けて、第二のユーザについてのグラフを表示してもよい。例えば、業務の管理者が、部下の業務や体調への影響を把握するために、本システムを利用することもできる。
【０１００】
［表示プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１１を用いて、上記の実施例と同様の機能を有する表示プログラムを実行するコンピュータの一例について説明する。
【０１０１】
図１１は、実施例１及び実施例２に係る表示プログラムを実行するコンピュータの一例について説明するための図である。図１１に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１０２】
ＨＤＤ１７０には、図１１に示すように、上記の実施例１で示した集計部１５ｄ及び表示制御部１５ｅと同様の機能を発揮する表示プログラム１７０ａが予め記憶される。この表示プログラム１７０ａについては、図２に示した各々の集計部１５ｄ及び表示制御部１５ｅの各構成要素と同様、適宜統合又は分離してもよい。すなわち、ＨＤＤ１７０に格納される各データは、必ずしも全てのデータがＨＤＤ１７０に格納されておらずともよく、処理に用いるデータのみがＨＤＤ１７０に格納されればよい。
【０１０３】
そして、ＣＰＵ１５０が、表示プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１１に示すように、表示プログラム１７０ａは、表示プロセス１８０ａとして機能する。この表示プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データをＲＡＭ１８０上の表示プロセス１８０ａに割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、表示プロセス１８０ａは、図２に示した集計部１５ｄ及び表示制御部１５ｅにて実行される処理、例えば図７に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、必ずしも全ての処理部がＣＰＵ１５０上で動作せずともよく、処理に用いる処理部のみが仮想的に実現されればよい。
【０１０４】
なお、上記の表示プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておかずともよい。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１０５】
１    ヘルスケア支援システム
５    ネットワーク
１０    サーバ装置
１１    通信Ｉ／Ｆ部
１３    記憶部
１３ａ  スケジュールデータ
１３ｂ  支払データ
１５    制御部
１５ａ  第１の取得部
１５ｂ  第２の取得部
１５ｃ  受付部
１５ｄ  集計部
１５ｅ  表示制御部
３０Ａ，３０Ｂ，３０Ｃ    クライアント端末
【図１】
2016053761.tif 000003
【図２】
2016053761.tif 000004
【図３】
2016053761.tif 000005
【図４】
2016053761.tif 000006
【図５】
2016053761.tif 000007
【図６】
2016053761.tif 000008
【図７】
2016053761.tif 000009
【図８】
2016053761.tif 000010
【図９】
2016053761.tif 000011
【図１０】
2016053761.tif 000012
【図１１】
2016053761.tif 000013