JP2017123064A - 通知装置、通知方法、および通知プログラム - Google Patents

Abstract

【課題】ユーザの健康状態の変化を察知可能にすること。【解決手段】通知装置１０１は、記憶部１１０に記憶された診断履歴情報を参照して、ユーザの通院サイクルまたは診断結果の変化を検出する。ユーザは、グルーピングされた複数のユーザのいずれかのユーザである。グルーピングされた複数のユーザは、例えば、家族や親しい友人同士などである。通知装置１０１は、ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う。所定の通知先は、グルーピングされた複数のユーザのうちの当該ユーザとは異なる他のユーザを含む。【選択図】図１

Description

本発明は、通知装置、通知方法、および通知プログラムに関する。

日常生活のなかで、家族の健康状態の変化を察知し、適切なフォローアクションをとることは大切である。

先行技術としては、例えば、携帯端末が、患者の通院ランクに基づき設定される周期で通院通知を繰り返し表示し、同時に親族、ホームヘルパーなどの関係者の携帯端末に患者の通院通知を通知するものがある。また、患者に処方された薬剤の処方日および処方期間に基づいて、薬剤の処方終了日を算出し、算出した薬剤の処方終了日と患者の患者ＩＤとを関連付けてディスプレイに出力する技術がある。

また、モバイル通信会社のサーバが、ユーザの家族のような特定関連者に同報通信を発して、共有することが望まれる医用データを特定関連者に伝送する技術がある。また、タイマが検出した時刻情報と住居人の生活行動の検出結果をもとに、登録された生活行動のうち所定の時間帯に行われなかった生活行動を検出し、その重要度に応じてテレビを用いた住居人への報知やＥメールによる介護ヘルパーへの報知を行う技術がある。

特開２０１４−１０６６４４号公報 特開２０１２−２０３８９１号公報 特開２００６−１３６４７８号公報 特開２０１０−２０７５３７号公報

しかしながら、従来技術では、家族の健康状態の変化を察知することが難しい場合がある。例えば、少子高齢化に伴う親世代の独居、地域経済の崩壊による単身赴任、多忙な共働き世帯の増加により、家族が互いの健康状態を日常生活で察知することが難しくなっている。

一つの側面では、本発明は、ユーザの健康状態の変化を察知可能にする通知装置、通知方法、および通知プログラムを提供することを目的とする。

本発明の一態様によれば、ユーザの診断履歴情報を記憶する記憶部を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出し、前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う通知装置、通知方法、および通知プログラムが提案される。

本発明の一側面によれば、ユーザの健康状態の変化を察知可能にすることができるという効果を奏する。

図１は、実施の形態にかかる通知方法の一実施例を示す説明図である。 図２は、通知システム２００のシステム構成例を示す説明図である。 図３は、通知装置１０１のハードウェア構成例を示すブロック図である。 図４は、クライアント端末Ｃｊのハードウェア構成例を示すブロック図である。 図５は、グループＤＢ２２０の記憶内容の一例を示す説明図である。 図６は、診断履歴ＤＢ２３０の記憶内容の一例を示す説明図である。 図７は、通知先テーブル２４０の記憶内容の一例を示す説明図である。 図８は、詳細判定テーブル２５０の記憶内容の一例を示す説明図である。 図９は、傷病状態テーブル２６０の記憶内容の一例を示す説明図である。 図１０は、通知装置１０１の機能的構成例を示すブロック図である。 図１１は、ユーザの定期通院化の検出例を示す説明図である。 図１２は、第１の通知情報の具体例を示す説明図である。 図１３は、第２の通知情報の具体例を示す説明図である。 図１４は、第３の通知情報の具体例を示す説明図である。 図１５は、第４の通知情報の具体例を示す説明図である。 図１６は、第５の通知情報の具体例を示す説明図である。 図１７は、第６の通知情報の具体例を示す説明図である。 図１８は、簡易表示した通知情報の具体例を示す説明図である。 図１９は、通知情報の重要度に応じた通知方式の具体例を示す説明図（その１）である。 図２０は、通知情報の重要度に応じた通知方式の具体例を示す説明図（その２）である。 図２１は、通知装置１０１の第１の通知処理手順の一例を示すフローチャート（その１）である。 図２２は、通知装置１０１の第１の通知処理手順の一例を示すフローチャート（その２）である。 図２３は、通知装置１０１の第１の通知処理手順の一例を示すフローチャート（その３）である。 図２４は、通知情報生成処理の具体的処理手順の一例を示すフローチャートである。 図２５は、通知装置１０１の第２の通知処理手順の一例を示すフローチャートである。

以下に図面を参照して、本発明にかかる通知装置、通知方法、および通知プログラムの実施の形態を詳細に説明する。

（実施の形態）
図１は、実施の形態にかかる通知方法の一実施例を示す説明図である。図１において、通知装置１０１は、記憶部１１０を有し、ユーザの通院サイクルまたは診断結果の変化を検出した場合に、所定の通知先に、ユーザの通院サイクルまたは診断結果の変化に応じた通知を行うコンピュータである。

記憶部１１０は、ユーザの診断履歴情報を記憶する。ユーザの診断履歴情報は、医療機関において診断されたユーザの診断結果を特定する情報である。診断履歴情報には、例えば、医師の診察を受けた日（受診日）や、医師により診断された傷病名を特定する情報が含まれる。医療機関は、例えば、病院やクリニック（診療所）である。

通院サイクルとは、例えば、定期的に通院する際の通院間隔（周期）や頻度（例えば、単位期間当たりの通院回数）を示す。以下の説明では、通院サイクルは、定期的に通院する際の通院間隔を示すこととする。この場合、通院サイクルの変化は、定期的に通院する際の通院間隔の変化となる。また、診断結果の変化は、例えば、新たな傷病の診断や、病状の変化を含む。

ここで、家族の健康状態の変化をいち早く察知し、適切なフォローアクションを早期にとることは大切である。一方で、少子高齢化に伴う親世代の独居、地域経済の崩壊による単身赴任、多忙な共働き世帯の増加により、家族が互いの健康状態を日常生活で察知することが難しくなっている。

そこで、本実施の形態では、ユーザの通院サイクルまたは診断結果の変化を検出して所定の通知先に通知することで、例えば、離れて暮らす家族や、同居していても生活スタイルが異なるような家族の健康状態の変化を察知可能にする通知方法について説明する。以下、通知装置１０１の処理例について説明する。

（１）通知装置１０１は、記憶部１１０に記憶された診断履歴情報を参照して、ユーザの通院サイクルまたは診断結果の変化を検出する。ここで、ユーザは、グルーピングされた複数のユーザのいずれかのユーザである。グルーピングされた複数のユーザは、例えば、家族や親しい友人同士などである。家族は、例えば、夫婦とその血縁関係者を中心に構成される集団である。ただし、家族であっても別々の場所で生活している場合もある。

ここでは、グルーピングされたユーザＡ、ユーザＢおよびユーザＣを含む家族ＦのうちのユーザＡの通院サイクルの変化を検出する場合を例に挙げて説明する。ユーザＡは、傷病名「糖尿病」で定期的に通院している。また、ユーザＢおよびユーザＣは、ユーザＡの子であり、ユーザＡから独立して、それぞれ別々に家を構えている。したがって、ユーザＢおよびユーザＣは、日常生活のなかでユーザＡの健康状態を察知することが難しい状況である。

この場合、通知装置１０１は、ユーザＡの診断履歴情報を参照して、ユーザＡの通院サイクルの変化を検出する。具体的には、例えば、通知装置１０１は、ユーザＡの通院サイクルと、今回の通院間隔との差異が所定の時間幅ｗよりも大きい場合に、ユーザＡの通院サイクルの変化を検出する。所定の時間幅ｗは、任意に設定可能である。

図１の例では、ユーザＡの傷病名「糖尿病」での今回の通院の受診日（最終受診日）は「５月２４日」である。ユーザＡは、これまで受診日「１月１０日，３月１０日，５月１０日」に、傷病名「糖尿病」で定期的に通院している。このため、傷病名「糖尿病」で定期的に通院しているユーザＡのこれまでの通院サイクルは「２ヶ月」となる。一方、今回の通院の受診日「５月２４日」は、前回の通院の受診日「５月１０日」から２週間後である。このため、今回の通院間隔は「２週間」となる。

ここで、所定の時間幅ｗを「１週間」とすると、ユーザＡの通院サイクル「２ヶ月」と今回の通院間隔「２週間」との差異「６週間（１ヶ月と２週間）」は、所定の時間幅ｗ「１週間」よりも大きくなる。この場合、通知装置１０１は、ユーザＡの通院サイクルの変化を検出する。

（２）通知装置１０１は、ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う。ここで、所定の通知先は、グルーピングされた複数のユーザのうち、当該ユーザとは異なる他のユーザを含む。

図１の例では、所定の通知先は、例えば、家族ＦのうちのユーザＡとは異なるユーザＢまたは／およびユーザＣである。この場合、通知装置１０１は、例えば、ユーザＢまたは／およびユーザＣ宛に通知情報１２０を送信する。通知情報１２０は、ユーザＡの通院サイクルの変化を通知する情報、例えば、傷病名「糖尿病」で定期的に通院しているユーザＡの通院サイクルが短くなったことを通知する情報である。

このように、通知装置１０１によれば、ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、ユーザの通院サイクルまたは診断結果の変化に応じた通知を行うことができる。これにより、ユーザの健康状態の変化を、当該ユーザとグルーピングされた他のユーザに通知することができる。このため、例えば、家族が離れて暮らしている、あるいは、生活スタイルが異なるような状況であっても、家族が互いの健康状態の変化を察知することができるようになる。

図１の例では、ユーザＢまたは／およびユーザＣは、傷病名「糖尿病」で定期的に通院しているユーザＡの通院サイクルが短くなったことを察知することができる。このため、ユーザＢまたは／およびユーザＣは、ユーザＡの病状が悪化した可能性があることに気付くことができ、例えば、ユーザＡに電話して安否を気遣うなどのフォローアクションをとることができる。

（通知システム２００のシステム構成例）
つぎに、実施の形態にかかる通知システム２００のシステム構成例について説明する。

図２は、通知システム２００のシステム構成例を示す説明図である。図２において、通知システム２００は、通知装置１０１と、医療機関端末Ｔ１〜Ｔｎと、クライアント端末Ｃ１〜Ｃｍと、を含む。通知システム２００において、通知装置１０１、医療機関端末Ｔ１〜Ｔｎ、およびクライアント端末Ｃ１〜Ｃｍは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

通知装置１０１は、グループＤＢ（データベース）２２０、診断履歴ＤＢ２３０、通知先テーブル２４０、詳細判定テーブル２５０および傷病状態テーブル２６０を有する。通知装置１０１は、例えば、サーバである。なお、各種ＤＢ等２２０，２３０，２４０，２５０，２６０の記憶内容については、図５〜図９を用いて後述する。

医療機関端末Ｔ１〜Ｔｎは、各医療機関Ｍ１〜Ｍｎに対応付けて設置されるコンピュータである。以下の説明では、医療機関端末Ｔ１〜Ｔｎのうちの任意の医療機関端末を「医療機関端末Ｔｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。また、医療機関端末Ｔｉに対応する医療機関を「医療機関Ｍｉ」と表記する場合がある。

医療機関端末Ｔｉは、例えば、サーバであってもよく、また、医療機関Ｍｉの職員により使用されるＰＣ（パーソナル・コンピュータ）であってもよい。医療機関Ｍｉは、例えば、病院やクリニック（診療所）である。なお、クリニックとは、病院よりも規模の小さい、例えば、入院用ベッド数が１９以下の医療機関である。

医療機関端末Ｔｉは、医療機関Ｍｉにおいて診断されたユーザの診断結果を特定する診断情報を通知装置１０１に送信する。診断情報は、例えば、電子カルテや診療明細書などの情報をもとに作成される。電子カルテは、診療録を電子化したものであり、例えば、医療機関Ｍｉにおいて診断された傷病名を含む。また、診療明細書は、患者に交付される情報であり、例えば、初診料、再診料、在宅医療、検査、投薬など診療報酬の算定区分ごとの具体的な診療行為の項目名や保険点数などを含む。

診断情報の送信タイミングは、任意に設定可能である。例えば、医療機関端末Ｔｉは、医療機関Ｍｉにおける医師の診察が終了すると、その都度、電子カルテや診療明細書の情報をもとに診断情報を作成して通知装置１０１に送信することにしてもよい。また、例えば、医療機関端末Ｔｉは、深夜に実行される日次処理により、当日に医療機関Ｍｉにおいて医師の診察を受けたユーザの診断結果を特定する診断情報を通知装置１０１に送信することにしてもよい。

クライアント端末Ｃ１〜Ｃｍは、通知システム２００のユーザ（例えば、患者）が使用するコンピュータである。クライアント端末Ｃ１〜Ｃｍは、例えば、スマートフォン、ＰＣ、タブレットＰＣなどである。以下の説明では、クライアント端末Ｃ１〜Ｃｍのうちの任意のクライアント端末を「クライアント端末Ｃｊ」と表記する場合がある（ｊ＝１，２，…，ｍ）。

（通知装置１０１のハードウェア構成例）
図３は、通知装置１０１のハードウェア構成例を示すブロック図である。図３において、通知装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、ディスクドライブ３０４と、ディスク３０５と、を有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、通知装置１０１の全体の制御を司る。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

Ｉ／Ｆ３０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、図２に示した医療機関端末Ｔ１〜Ｔｎ、クライアント端末Ｃ１〜Ｃｍ）に接続される。Ｉ／Ｆ３０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。Ｉ／Ｆ３０３には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリード／ライトを制御する。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する。ディスク３０５としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

なお、通知装置１０１は、上述した構成部のほか、例えば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、キーボード、マウス、ディスプレイなどを有することにしてもよい。また、図２に示した医療機関端末Ｔ１〜Ｔｎについても、通知装置１０１と同様のハードウェア構成により実現することができる。

（クライアント端末Ｃｊのハードウェア構成例）
図４は、クライアント端末Ｃｊのハードウェア構成例を示すブロック図である。図４において、クライアント端末Ｃｊは、ＣＰＵ４０１と、メモリ４０２と、ディスクドライブ４０３と、ディスク４０４と、Ｉ／Ｆ４０５と、ディスプレイ４０６と、入力装置４０７とを有する。また、各構成部はバス４００によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、クライアント端末Ｃｊの全体の制御を司る。メモリ４０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。

ディスクドライブ４０３は、ＣＰＵ４０１の制御に従ってディスク４０４に対するデータのリード／ライトを制御する。ディスク４０４は、ディスクドライブ４０３の制御で書き込まれたデータを記憶する。ディスク４０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

Ｉ／Ｆ４０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他の装置（例えば、図２に示した通知装置１０１）に接続される。そして、Ｉ／Ｆ４０５は、ネットワーク２１０と自装置内部とのインターフェースを司り、他の装置からのデータの入出力を制御する。

ディスプレイ４０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ４０６として、例えば、液晶ディスプレイ、有機ＥＬ（ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）などを採用することができる。

入力装置４０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置４０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。なお、クライアント端末Ｃｊは、上述した構成部のうち、例えば、ディスクドライブ４０３およびディスク４０４を有していなくてもよい。

（各種ＤＢ等２２０，２３０，２４０，２５０，２６０の記憶内容）
つぎに、図５〜図９を用いて、通知装置１０１が有する各種ＤＢ等２２０，２３０，２４０，２５０，２６０の記憶内容について説明する。各種ＤＢ等２２０，２３０，２４０，２５０，２６０は、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶装置により実現される。

図５は、グループＤＢ２２０の記憶内容の一例を示す説明図である。図５において、グループＤＢ２２０は、グループＩＤ、ユーザＩＤ、医療機関ＩＤ、医療機関名、診察券ＩＤ、氏名、通知区分、親等およびメールアドレスのフィールドを有する。各フィールドに情報を設定することで、グループ情報（例えば、グループ情報５００−１，５００−２）がレコードとして記憶される。

グループＩＤは、グルーピングされた複数のユーザを含むグループＧを一意に識別する識別子である。グループＧは、グルーピングされた複数のユーザの中のある一人に着目し、その人を「本人」として形成される。したがって、グループＩＤが異なるグループＧであっても、各グループＧに含まれるユーザの組み合わせが同一の場合もある。

ここでは、グルーピングされた複数のユーザを「家族」とする。ただし、グループＧには、家族の中の誰かの介護者や介助者が含まれていてもよい。さらに、グループＧには、家族の中の成年被後見人の保護を行う成年後見人が含まれていてもよい。

ユーザＩＤは、通知システム２００のユーザを一意に識別する識別子である。以下の説明では、ユーザＩＤ「Ｐ＃」のユーザを「ユーザＰ＃」と表記する場合がある。医療機関ＩＤは、ユーザが利用する医療機関Ｍｉを一意に識別する識別子である。医療機関名は、ユーザが利用する医療機関Ｍｉの名称である。診察券ＩＤは、医療機関Ｍｉにおいて診察を受けるために必要なユーザの診察券の番号であり、医療機関Ｍｉの患者を一意に識別する識別子である。

氏名は、ユーザの氏名である。通知区分は、通知区分「本人」のユーザについての通知情報の通知先を特定する際に用いられる情報である。通知区分には、例えば、「本人」、「同居」、「非同居」のいずれかが設定される。通知区分「同居」は、通知区分「本人」のユーザと同居している家族（あるいは、介護者や介助者など）を示す。通知区分「非同居」は、通知区分「本人」のユーザと同居していない家族を示す。

親等は、通知区分「本人」のユーザとの親族関係の遠近を表す親等情報である。親等数が小さいほど、通知区分「本人」のユーザと近い関係であることを示す。ただし、通知区分「本人」のユーザの配偶者の親等には、「０」が設定される。また、通知区分「本人」のユーザと親族関係を有していないユーザの親等には、「−（Ｎｕｌｌ）」が設定される。メールアドレスは、ユーザのメールアドレスである。

なお、ユーザが利用する医療機関Ｍｉが複数存在する場合は、グループ情報には、例えば、ユーザが利用する各医療機関Ｍｉの医療機関ＩＤ、医療機関名および診察券ＩＤが設定される。また、グループ情報には、例えば、グループＧ内の各ユーザの電話番号が含まれていてもよい。

また、グループＧ内には、通知区分「本人」のユーザと親族関係を有していない者、例えば、通知区分「本人」のユーザの介護者や介助者が含まれる場合がある。これらユーザに対応する医療機関ＩＤ、医療機関名および診察券ＩＤの各フィールドには、例えば、「−（Ｎｕｌｌ）」が設定される。

図６は、診断履歴ＤＢ２３０の記憶内容の一例を示す説明図である。図６において、診断履歴ＤＢ２３０は、ユーザＩＤ、受診日、医療機関ＩＤ、診察券ＩＤ、傷病名および処方箋情報のフィールドを有し、各フィールドに情報を設定することで、診断履歴情報（例えば、診断履歴情報６００−１，６００−２）をレコードとして記憶する。

ユーザＩＤは、通知システム２００のユーザを一意に識別する識別子である。受診日は、医療機関Ｍｉをユーザが受診した日（年月日）、すなわち、医療機関Ｍｉにおいて医師の診察を受けた日を示す。医療機関ＩＤは、ユーザが受診した医療機関Ｍｉを識別する識別子である。

診察券ＩＤは、医療機関Ｍｉにおいて診察を受けるために必要なユーザの診察券の番号である。傷病名は、医療機関Ｍｉにおいて診断された傷病の名称である。処方箋情報は、医療機関Ｍｉにおいて医師の診察を受けた際に処方された薬を特定する情報（例えば、薬名）である。

例えば、診断履歴情報６００−１は、医療機関Ｍ１においてユーザＰ１が診察を受けた受診日「２０１５／３／２８」、その際に診断された傷病名「急性腸炎」、および、その際に処方された薬剤「整腸剤」を示す。また、診断履歴情報６００−１は、医療機関Ｍ１におけるユーザＰ１の診察券ＩＤ「３００００１」を示す。なお、図１に示した記憶部１１０は、例えば、診断履歴ＤＢ２３０に相当する。

図７は、通知先テーブル２４０の記憶内容の一例を示す説明図である。図７において、通知先テーブル２４０は、通知区分「本人」のユーザの傷病状態ごとの通知情報の通知先を示す通知先情報（例えば、通知先情報７００−１，７００−２）を記憶する。

グループＩＤ「Ｄｅｆａｕｌｔ」の通知先情報７００−１は、初期設定された通知先を示す。例えば、通知先情報７００−１は、通知区分「本人」のユーザの傷病状態「新規罹患」についての通知情報の通知先が、同一グループＧ内の通知区分「同居」および「非同居」のユーザであることを示す。

また、グループＩＤと対応付けて通知先情報を新規登録することにより、各グループＧ固有の通知先を設定することができる。例えば、通知先情報７００−２は、グループＧ１固有の通知先を示す情報である。通知先情報７００−２では、傷病状態「通院忘れ」および「完治」についての通知情報の通知先が変更されている。

図８は、詳細判定テーブル２５０の記憶内容の一例を示す説明図である。図８において、詳細判定テーブル２５０は、通知区分「本人」のユーザと通知先のユーザとの関係に応じて、どのような情報（例えば、傷病名、傷病状態など）の表示を通知先のユーザに対して許可するのかを特定するための情報である。

例えば、ある傷病の発症時は、通知区分「本人」のユーザから見て２親等以下のユーザに対して、その傷病名の表示を許可することを示している。一方、通知区分「本人」のユーザから見て３親等以上のユーザおよび親族以外のユーザに対しては、発症の通知は許可するが、その傷病名の表示は許可しないことを示している。

図９は、傷病状態テーブル２６０の記憶内容の一例を示す説明図である。図９において、傷病状態テーブル２６０は、ユーザＩＤ、医療機関ＩＤ、氏名、傷病名、傷病状態、通院サイクルおよび最終受診日のフィールドを有する。各フィールドに情報を設定することで、ユーザの傷病状態を特定する傷病状態情報（例えば、傷病状態情報９００−１〜９００−５）がレコードとして記憶される。

ユーザＩＤは、通知システム２００のユーザを一意に識別する識別子である。医療機関ＩＤは、ユーザが受診した医療機関Ｍｉを一意に識別する識別子である。氏名は、ユーザの氏名である。傷病名は、ユーザの傷病名である。傷病状態は、ユーザの傷病状態である。通院サイクルは、ユーザが定期的に通院している場合の通院間隔を示す。最終受診日は、ユーザが対応する傷病名で最後に受診した受診日を示す。

例えば、傷病状態情報９００−１は、医療機関Ｍ１において診断されたユーザＰ１（氏名：富士 田吾作）の傷病名「糖尿病」、傷病状態「慢性疾患」、通院サイクル「２ヶ月」および最終受診日「２０１５／３／１１」を示す。

（通知装置１０１の機能的構成例）
図１０は、通知装置１０１の機能的構成例を示すブロック図である。図１０において、通知装置１０１は、取得部１００１と、検出部１００２と、生成部１００３と、出力部１００４と、を含む構成である。取得部１００１〜出力部１００４は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、Ｉ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０５などの記憶装置に記憶される。

取得部１００１は、ユーザの診断履歴情報を取得する。診断履歴情報は、例えば、医療機関Ｍｉにおいて診断されたユーザの診断結果および受診日を特定する情報を含む。具体的には、例えば、まず、取得部１００１は、医療機関端末Ｔｉから診断情報を受信することにより、当該診断情報を取得する。診断情報は、例えば、受診日、医療機関ＩＤ、診察券ＩＤ、傷病名および処方箋情報を含む。

受診日は、医療機関Ｍｉをユーザが受診した日（年月日）を示す。医療機関ＩＤは、ユーザが受診した医療機関Ｍｉを識別する識別子である。診察券ＩＤは、医療機関Ｍｉにおけるユーザの診察券の番号である。傷病名は、医療機関Ｍｉにおいて診断された傷病名である。処方箋情報は、医療機関Ｍｉにおいて医師の診察を受けた際に処方された薬剤を特定する情報である。

取得された診断情報は、例えば、ユーザＩＤと対応付けて診断履歴ＤＢ２３０（例えば、図６参照）に記憶される。ユーザＩＤは、例えば、診断情報に含まれる医療機関ＩＤおよび診察券ＩＤの組合せをもとにグループＤＢ２２０から特定される。ただし、医療機関端末Ｔｉから取得される診断情報にユーザＩＤが含まれていてもよい。

これにより、新たな診断履歴情報が取得されて診断履歴ＤＢ２３０にレコードとして記憶される。なお、上述した説明では、医療機関端末Ｔｉから診断情報を受信することにしたが、これに限らない。例えば、取得部１００１は、医療機関端末Ｔｉから電子カルテや診療明細書などの情報を取得し、当該情報をもとに診断情報を作成することにしてもよい。

検出部１００２は、ユーザの診断結果の変化を検出する。具体的には、例えば、検出部１００２は、新たな診断履歴情報が取得されたことに応じて、診断履歴ＤＢ２３０から、新たな診断履歴情報とユーザＩＤおよび傷病名が同一の他の診断履歴情報を検索する。ここで、他の診断履歴情報が検索されなかった場合、検出部１００２は、新たな傷病に罹患したことを検出する。一方、他の診断履歴情報が検索された場合、検出部１００２は、過去に罹患した傷病と同一の傷病に罹患したことを検出する。

また、検出部１００２は、所定の期間Ｔ内の診断履歴情報を参照して、ユーザの定期通院化を検出する。ここで、ユーザの定期通院化とは、ユーザが定期的に通院する状態に変化したことを示す。また、所定の期間Ｔ内の診断履歴情報とは、所定の期間Ｔ内に受診日が含まれる診断履歴情報である。所定の期間Ｔは、任意に設定可能であり、例えば、当日（ユーザの定期通院化を検出する日）から遡って数ヶ月（例えば、６ヶ月）以内の期間に設定される。

具体的には、例えば、検出部１００２は、新たな診断履歴情報が取得されたことに応じて、診断履歴ＤＢ２３０から、所定の期間Ｔ内の診断履歴情報のうち、新たな診断履歴情報とユーザＩＤおよび傷病名が同一の診断履歴情報を検索する。そして、検出部１００２は、所定数以上（例えば、３以上）の診断履歴情報が検索されたか否かを判断する。

ここで、所定数以上の診断履歴情報が検索された場合、検出部１００２は、検索した診断履歴情報（新たな診断履歴情報を含む）を参照して、所定の期間Ｔ内の連続する受診日の間隔をそれぞれ算出する。この連続する受診日の間隔は、ユーザが同一の傷病名で通院する通院間隔を示す。

そして、検出部１００２は、算出した通院間隔（連続する受診日の間隔）同士の差異が所定の時間幅ｗ以内の場合に、ユーザの定期通院化を検出する。なお、所定の時間幅ｗは、上述したように、任意に設定可能であり、例えば、１週間程度に設定される。

これにより、ユーザが同一の傷病名で定期的に通院する状態に変化したことを検出することができる。なお、ここでは同一の傷病名での定期通院化を検出することにしたが、これに限らない。例えば、傷病名にかかわらず、ユーザの定期的な通院を検出する場合には、検出部１００２は、診断履歴ＤＢ２３０から、所定の期間Ｔ内の診断履歴情報のうち、新たな診断履歴情報とユーザＩＤが同一の診断履歴情報を検索することにしてもよい。

また、慢性疾患による定期通院時は、毎回の通院時に薬が処方される可能性が高い。このため、検出部１００２は、ユーザの定期通院化を検出し、かつ、検索した診断履歴情報の処方箋情報に薬名が設定されている場合は、慢性疾患でのユーザの定期通院化を検出することにしてもよい。これにより、ユーザが慢性疾患で定期的に通院する状態に変化したことを検出することができる。

ここで、図１１を用いて、ユーザの定期通院化の検出例について説明する。

図１１は、ユーザの定期通院化の検出例を示す説明図である。ここでは、新たな診断履歴情報として、診断履歴情報１１００−３が取得された場合を例に挙げて説明する。また、所定の期間Ｔを、当日（２０１５／３／１１）から遡って６ヶ月以内の期間とする。

この場合、検出部１００２は、診断履歴ＤＢ２３０から、所定の期間Ｔ内の診断履歴情報のうち、診断履歴情報１１００−３とユーザＩＤおよび傷病名が同一の診断履歴情報を検索する。ここでは、診断履歴ＤＢ２３０から、診断履歴情報１１００−１〜１１００−３が検索された場合を想定する。

つぎに、検出部１００２は、検索した診断履歴情報１１００−１〜１１００−３を参照して、所定の期間Ｔ内の連続する受診日の間隔（通院間隔ｔ１，ｔ２）をそれぞれ算出する。ここでは、通院間隔ｔ１は、「２ヶ月」となる。また、通院間隔ｔ２は、「２ヶ月１日」となる。

そして、検出部１００２は、算出した通院間隔ｔ１，ｔ２同士の差異が所定の時間幅ｗ以内の場合に、ユーザＰ１の定期通院化を検出する。ここでは、所定の時間幅ｗを「１週間」とする。この場合、検出部１００２は、通院間隔ｔ１，ｔ２同士の差異「１日」が所定の時間幅ｗ以内のため、ユーザＰ１の定期通院化を検出する。

また、各診断履歴情報１１００−１〜１１００−３の処方箋情報には、薬名「インスリン」が設定されている。この場合、検出部１００２は、慢性疾患でのユーザＰ１の定期通院化を検出する。これにより、ユーザＰ１が慢性疾患「糖尿病」で定期的に通院する状態に変化したことを検出することができる。

図１０の説明に戻り、検出部１００２は、ユーザの定期通院化を検出した場合、傷病状態テーブル２６０に傷病状態情報を新規登録する。ここで、図１１に示した慢性疾患でのユーザＰ１の定期通院化を例に挙げて、傷病状態情報の新規登録例について説明する。

まず、検出部１００２は、新たな診断履歴情報１１００−３を参照して、傷病状態テーブル２６０の各フィールドに、ユーザＩＤ「Ｐ１」、医療機関ＩＤ「Ｍ１」、氏名「富士 田吾作」、傷病名「糖尿病」および最終受診日「２０１５／３／１１」を設定する。

この結果、図９に示したような傷病状態情報９００−１が傷病状態テーブル２６０にレコードとして記憶される。そして、検出部１００２は、傷病状態情報９００−１の傷病状態に「慢性疾患」を設定する。この時点では、傷病状態情報９００−１の通院サイクルは未設定である。

つぎに、検出部１００２は、所定の期間Ｔ内の連続する受診日の間隔（通院間隔）に基づいて、ユーザＰ１の通院サイクルを算出する。具体的には、例えば、検出部１００２は、連続する受診日の間隔（通院間隔）の平均値を通院サイクルとして算出する。そして、検出部１００２は、傷病状態情報９００−１に、算出した通院サイクルを設定する。

図１１の例では、連続する受診日の間隔（通院間隔）の平均値は「２ヶ月」である（ただし、１日未満は切り捨て）。このため、傷病状態情報９００−１の通院サイクルに「２ヶ月」が設定される。ユーザＰ１が慢性疾患以外で定期通院している場合は、傷病状態情報９００−１の傷病状態には「定期通院」が設定される。

なお、検出部１００２は、新たな傷病に罹患したことを検出した場合に、傷病状態テーブル２６０に傷病状態情報を新規登録することにしてもよい。具体的には、例えば、検出部１００２は、新たな診断履歴情報を参照して、傷病状態テーブル２６０の各フィールドに、ユーザＩＤ、医療機関ＩＤ、氏名、傷病名および最終受診日を設定する。

この結果、新たな傷病状態情報が傷病状態テーブル２６０にレコードとして記憶される。そして、検出部１００２は、新たな傷病状態情報の傷病状態に「新規罹患」を設定する。この場合、新たな傷病状態情報の通院サイクルは「−（Ｎｕｌｌ）」となる。これにより、ユーザが新たな傷病にいつ罹患したのかを特定することが可能となる。

また、検出部１００２は、過去に罹患した傷病と同一の傷病に罹患したことを検出した場合に、傷病状態テーブル２６０に傷病状態情報を新規登録することにしてもよい。具体的には、例えば、検出部１００２は、新たな診断履歴情報を参照して、傷病状態テーブル２６０の各フィールドに、ユーザＩＤ、医療機関ＩＤ、氏名、傷病名および最終受診日を設定する。

この結果、新たな傷病状態情報が傷病状態テーブル２６０にレコードとして記憶される。そして、検出部１００２は、新たな傷病状態情報の傷病状態に「再発」を設定する。この場合、新たな傷病状態情報の通院サイクルは「−（Ｎｕｌｌ）」となる。これにより、ユーザが過去に罹患した傷病がいつ再発したのかを特定することが可能となる。

検出部１００２は、ユーザの通院サイクルの変化を検出する。具体的には、例えば、検出部１００２は、新たな診断履歴情報が取得されたことに応じて、傷病状態テーブル２６０を参照して、新たな診断履歴情報の傷病名が、慢性疾患または定期通院の傷病名であるか否かを判断する。

より詳細に説明すると、例えば、検出部１００２は、傷病状態テーブル２６０から、新たな診断履歴情報とユーザＩＤおよび傷病名が同一の傷病状態情報のうち、傷病状態が慢性疾患または定期通院の傷病状態情報を検索する。ここで、傷病状態情報が検索された場合、検出部１００２は、新たな診断履歴情報の傷病名が、慢性疾患または定期通院の傷病名であると判断する。

つぎに、慢性疾患または定期通院の傷病名である場合、検出部１００２は、ユーザの通院サイクルが短くなったか否かを判断する。より詳細に説明すると、例えば、まず、検出部１００２は、検索した傷病状態情報の最終受診日から、新たな診断履歴情報の受診日までの間隔（通院間隔）を算出する。この間隔は、今回の通院間隔に相当する。

そして、検出部１００２は、検索した傷病状態情報の通院サイクル（ユーザの通院サイクル）から、算出した間隔（今回の通院間隔）を減算した値（日数）が所定の時間幅ｗよりも大きい場合に、ユーザの通院サイクルが短くなったと判断する。ただし、１ヶ月を「３０日」とし、１年を「３６５日」とする。

これにより、通院サイクルの変化として、ユーザの通院サイクルが短くなったことを検出することができる。なお、所定の時間幅ｗは、例えば、傷病状態情報の通院サイクルが長くなるほど大きくなるように適宜設定されることにしてもよい。

また、検出部１００２は、ユーザの通院忘れを検出することにしてもよい。具体的には、例えば、まず、検出部１００２は、ユーザの傷病状態が慢性疾患または定期通院の場合、当該ユーザの次回の通院予定期間を特定する。より詳細に説明すると、例えば、検出部１００２は、傷病状態テーブル２６０を参照して、傷病状態が慢性疾患または定期通院のユーザの最終受診日から通院サイクル分の期間が経過した日を、次回の通院予定日として特定する。

つぎに、検出部１００２は、特定した次回の通院予定日から一定日数（例えば、７日）分の期間を、次回の通院予定期間として特定する。そして、検出部１００２は、特定した次回の通院予定期間が経過したか否かを判断する。ここで、次回の通院予定期間が経過した場合、検出部１００２は、定期通院しているユーザの通院忘れを検出する。

これにより、次回の通院予定日から一定日数（例えば、７日）が経過しても新たな通院履歴がない場合に、定期通院しているユーザの通院忘れを検出することができる。

また、検出部１００２は、ユーザが完治したことを検出することにしてもよい。具体的には、例えば、検出部１００２は、次回の通院予定期間の末日から一定日数（例えば、１０日〜３０日）経過した日を基準日として特定する。そして、検出部１００２は、特定した基準日を経過したか否かを判断する。ここで、基準日を経過した場合、検出部１００２は、定期通院していたユーザが完治したことを検出する。

これにより、次回の通院予定期間の末日から一定日数（例えば、１０日〜３０日）が経過しても新たな通院履歴がない場合に、定期通院していたユーザが完治したことを検出することができる。なお、検出部１００２は、ユーザが完治したことを検出した場合には、傷病状態テーブル２６０から、当該傷病についての傷病状態情報を削除することにしてもよい。

生成部１００３は、検出されたユーザの通院サイクルまたは診断結果の変化に応じた通知情報を生成する。具体的には、例えば、生成部１００３は、ユーザが新たな傷病に罹患したことが検出された場合、ユーザが新たな傷病に罹患したことを通知する第１の通知情報を生成することにしてもよい。なお、第１の通知情報の具体例については、図１２を用いて後述する。

また、生成部１００３は、例えば、ユーザが過去に罹患した傷病と同一の傷病に罹患したことが検出された場合、ユーザが過去に罹患した傷病を再発もしくは流行性疾患に罹患したことを通知する第２の通知情報を生成することにしてもよい。なお、第２の通知情報の具体例については、図１３を用いて後述する。

また、生成部１００３は、例えば、（慢性疾患での）ユーザの定期通院化が検出された場合、ユーザが（慢性疾患で）定期的に通院する状態に変化したことを通知する第３の通知情報を生成することにしてもよい。なお、第３の通知情報の具体例については、図１４を用いて後述する。

また、生成部１００３は、例えば、ユーザの通院サイクルが短くなったことが検出された場合、ユーザの通院回数が増加したことを通知する第４の通知情報を生成することにしてもよい。なお、第４の通知情報の具体例については、図１５を用いて後述する。

また、生成部１００３は、例えば、ユーザの通院忘れが検出された場合、ユーザの通院忘れを通知する第５の通知情報を生成することにしてもよい。なお、第５の通知情報の具体例については、図１６を用いて後述する。

また、生成部１００３は、例えば、ユーザの完治が検出された場合、ユーザの完治を通知する第６の通知情報を生成することにしてもよい。なお、第６の通知情報の具体例については、図１７を用いて後述する。

また、生成部１００３は、生成した通知情報の通知先を設定する。具体的には、例えば、生成部１００３は、通知先テーブル２４０を参照して、検出されたユーザの通院サイクルまたは診断結果の変化に応じた通知先を設定する。

より詳細に説明すると、例えば、グループＧ固有の通知先が未設定の場合は、生成部１００３は、通知先情報７００−１を参照して通知先を設定する。一方、グループＧ固有の通知先が設定済みの場合は、生成部１００３は、グループＧ固有の通知先情報（例えば、通知先情報７００−２）を参照して通知先を設定する。

ここで、ユーザＰ１の通院サイクルまたは診断結果の変化に応じた通知先の設定例について説明する。通知先テーブル２４０には、ユーザＰ１を通知区分「本人」とするグループＧ１固有の通知先情報７００−２が記憶されている。この場合、生成部１００３は、通知先情報７００−２を参照して通知先を設定する。

例えば、生成部１００３は、通知先情報７００−２を参照して、新たな傷病に罹患したことを通知する第１の通知情報（新規罹患）の通知先として、通知区分「同居」および「非同居」のユーザのメールアドレスに設定する。なお、各ユーザのメールアドレスは、例えば、グループＤＢ２２０から特定される。

また、例えば、生成部１００３は、通知先情報７００−２を参照して、（慢性疾患で）定期的に通院する状態に変化したことを通知する第３の通知情報（定期通院または慢性疾患）の通知先として、通知区分「同居」および「非同居」のユーザのメールアドレスに設定する。

また、例えば、生成部１００３は、通知先情報７００−２を参照して、ユーザの通院回数が増加したことを通知する第４の通知情報（病状悪化）の通知先として、通知区分「同居」および「非同居」のユーザのメールアドレスに設定する。

また、例えば、生成部１００３は、通知先情報７００−２を参照して、ユーザの通院忘れを通知する第５の通知情報（通院忘れ）の通知先として、通知区分「本人」および「同居」のユーザのメールアドレスに設定する。

また、例えば、生成部１００３は、通知先情報７００−２を参照して、ユーザの完治を通知する第６の通知情報（完治）の通知先として、通知区分「同居」および「非同居」のユーザのメールアドレスに設定する。

また、生成部１００３は、ユーザと通知先のユーザとの親族関係の遠近を表す親等情報に基づいて、通知情報の内容を変更することにしてもよい。具体的には、例えば、まず、生成部１００３は、グループＤＢ２２０を参照して、通知先のユーザの親等を特定する。そして、生成部１００３は、詳細判定テーブル２５０を参照して、特定した親等に応じて通知情報の内容を変更することにしてもよい。

例えば、生成部１００３は、発症時には、ユーザ（通知区分「本人」のユーザ）から見た親等が３親等以上または親族以外であれば、発症した傷病名については非表示とする通知情報を生成する。なお、発症時とは、例えば、新たな傷病に罹患、過去に罹患した傷病と同一の傷病に罹患、（慢性疾患での）ユーザの定期通院化、通院サイクルが短くなったことのいずれかが検出されたときである。

また、生成部１００３は、完治時には、ユーザから見た親等が３親等以上または親族以外であれば、完治した傷病名については非表示とする通知情報を生成する。また、生成部１００３は、通院忘れ時には、親族以外であれば、簡易表示した通知情報を生成する。簡易表示とは、例えば、傷病名、傷病状態、前回通院日、通院サイクル等の情報は非表示とし、通院忘れの通知のみ行うことである。なお、簡易表示した通知情報の具体例については、図１８を用いて後述する。

また、生成部１００３は、検出されたユーザの通院サイクルまたは診断結果の変化の内容に応じて、生成した通知情報に重要度を設定することにしてもよい。具体的には、例えば、生成部１００３は、新たな傷病に罹患、過去に罹患した傷病と同一の傷病に罹患、通院忘れ、通院サイクルが短くなったことのいずれかが検出された場合は、通知情報に重要度「高」を設定することにしてもよい。また、例えば、生成部１００３は、（慢性疾患での）ユーザの定期通院化または完治が検出された場合は、通知情報に重要度「低」を設定することにしてもよい。

出力部１００４は、生成された通知情報を出力する。具体的には、例えば、出力部１００４は、設定された通知先のメールアドレス宛に通知情報を送信する。また、出力部１００４は、通知情報に重要度が設定されている場合には、通知情報の重要度に応じて通知方式を変更することにしてもよい。

より詳細に説明すると、例えば、出力部１００４は、通知情報に重要度「高」が設定されている場合は、通知情報をプッシュ通知で送信し、通知情報の内容を確認するまでバナー（あるいは、ダイアログ）の表示が消えないような通知方式を用いることにしてもよい。一方、通知情報に重要度「低」が設定されている場合は、出力部１００４は、通知情報をプッシュ通知で送信し、バナー（あるいは、ダイアログ）をタップすると、通知情報の内容を確認しなくても当該バナーの表示が消えるような通知方式を用いることにしてもよい。

なお、通知情報に設定された重要度に応じた通知方式の具体例については、図１９および図２０を用いて後述する。また、通知情報に重要度「高」が設定されている場合には、出力部１００４は、例えば、通知先のユーザの電話番号に自動で電話をかけて、通知情報の内容を読み上げるようにすることにしてもよい。

（通知情報の具体例）
つぎに、図１２〜図１８を用いて、通知先のユーザのクライアント端末Ｃｊのディスプレイ４０６に表示される通知情報の具体例について説明する。

図１２は、第１の通知情報の具体例を示す説明図である。図１２において、第１の通知情報１２００は、ユーザＰ１（氏名：富士 田吾作）が新たな傷病に罹患したことを通知する情報である。

第１の通知情報１２００によれば、例えば、ユーザＰ１の家族は、ユーザＰ１が２０１４年９月１０日にＡクリニックを受診して、傷病「喘息」と診断されたことを把握することができる。また、傷病「喘息」は、ユーザＰ１が初めて罹患した傷病であることがわかる。

図１３は、第２の通知情報の具体例を示す説明図である。図１３において、第２の通知情報１３００は、ユーザＰ３（氏名：富士 太郎）が過去に罹患した傷病を再発もしくは流行性疾患に罹患したことを通知する情報である。

第２の通知情報１３００によれば、例えば、ユーザＰ３の家族は、ユーザＰ３が２０１５年５月１２日にＢクリニックを受診して、傷病「インフルエンザ」と診断されたことを把握することができる。また、傷病「インフルエンザ」は、ユーザＰ３が過去に罹患した傷病または流行性疾患であることがわかる。

図１４は、第３の通知情報の具体例を示す説明図である。図１４において、第３の通知情報１４００は、ユーザＰ１（氏名：富士 田吾作）が慢性疾患で定期的に通院する状態に変化したことを通知する情報である。

第３の通知情報１４００によれば、例えば、ユーザＰ１の家族は、ユーザＰ１が慢性疾患である傷病「糖尿病」で定期的にＡクリニックに通院するようになったことを把握することができる。さらに、今回の通院日（受診日）「２０１５年３月１１日」と前回通院日「２０１５年１月１０日」を確認することができる。

図１５は、第４の通知情報の具体例を示す説明図である。図１５において、第４の通知情報１５００は、ユーザＰ１（氏名：富士 田吾作）の通院回数が増加したことを通知する情報である。

第４の通知情報１５００によれば、例えば、ユーザＰ１の家族は、傷病「糖尿病」の慢性疾患で定期通院しているユーザＰ１の通院サイクルが短くなっており、ユーザＰ１の病状が悪化した可能性があることを把握することができる。

図１６は、第５の通知情報の具体例を示す説明図である。図１６において、第５の通知情報１６００は、ユーザＰ１（氏名：富士 田吾作）の通院忘れを通知する情報である。

第５の通知情報１６００によれば、例えば、ユーザＰ１の家族は、傷病「糖尿病」の慢性疾患で定期通院しているユーザＰ１が通院し忘れている可能性があることを把握することができる。また、ユーザＰ１本人が通院し忘れていることに気付くことができる。

図１７は、第６の通知情報の具体例を示す説明図である。図１７において、第６の通知情報１７００は、ユーザＰ１（氏名：富士 田吾作）の完治を通知する情報である。

第６の通知情報１７００によれば、例えば、ユーザＰ１の家族は、傷病「糖尿病」の慢性疾患で定期通院していたユーザＰ１が完治したことを把握することができる。

図１８は、簡易表示した通知情報の具体例を示す説明図である。図１８において、第５の通知情報１８００は、ユーザＰ１（氏名：富士 田吾作）の通院忘れを通知する情報であり、図１６に示した第５の通知情報１６００を簡易表示したものに相当する。

第５の通知情報１８００によれば、例えば、ユーザＰ１の介護者や介助者は、慢性疾患で定期通院しているユーザＰ１が通院し忘れている可能性があることを把握することができる。すなわち、介護者や介助者などの親族以外のユーザに対しては、ユーザＰ１が罹患している傷病の詳細を伝えることなく、ユーザＰ１の通院忘れを通知することができる。

（通知方式の具体例）
つぎに、図１９および図２０を用いて、通知情報の重要度に応じた通知方式の具体例について説明する。

図１９は、通知情報の重要度に応じた通知方式の具体例を示す説明図（その１）である。図１９において、クライアント端末Ｃｊは、通知装置１０１から重要度「低」の通知情報を受信すると、ディスプレイ４０６の通知域（例えば、画面上部）にバナー１９００をポップアップ表示する。

また、クライアント端末Ｃｊは、例えば、バナー１９００がタッチされると、バナー１９００を非表示とする。この場合、ユーザは、例えば、メール画面などから通知情報の内容を確認することができる。このように、通知情報の重要度が「低」の場合は、ユーザには通知情報を受信したことのみ通知して、通知情報の内容を確認するか否かはユーザに委ねることができる。

図２０は、通知情報の重要度に応じた通知方式の具体例を示す説明図（その２）である。図２０において、クライアント端末Ｃｊは、通知装置１０１から重要度「高」の通知情報を受信すると、ディスプレイ４０６の通知域（例えば、画面上部）にバナー２０００をポップアップ表示する。

この際、クライアント端末Ｃｊは、図１９に示したバナー１９００と異なる色でバナー２０００を表示することにしてもよい。これにより、バナー色から重要度の異なる通知情報を区別することができるようになる。

また、クライアント端末Ｃｊは、例えば、バナー２０００がタッチされると、ディスプレイ４０６に通知情報（例えば、図１２〜図１８参照）を含む通知画面２００１を表示する。この場合、クライアント端末Ｃｊは、ボタン２００２がタッチされるまで、通知画面２００１を継続して表示する。すなわち、ボタン２００２がタッチされるまで通知画面２００１は消えない。

このように、通知情報の重要度が「高」の場合は、ボタン２００２がタッチされるまで、ディスプレイ４０６に通知画面２００１を表示し続けることで、ユーザに通知情報の内容を強制的に確認させることができる。

（通知装置１０１の通知処理手順）
つぎに、通知装置１０１の通知処理手順について説明する。まず、第１の通知処理手順について説明する。第１の通知処理は、新たな診断履歴情報が取得されると、その都度実行される処理である。

図２１〜図２３は、通知装置１０１の第１の通知処理手順の一例を示すフローチャートである。図２１のフローチャートにおいて、まず、通知装置１０１は、新たな診断履歴情報を取得したか否かを判断する（ステップＳ２１０１）。ここで、通知装置１０１は、新たな診断履歴情報を取得するのを待つ（ステップＳ２１０１：Ｎｏ）。

そして、通知装置１０１は、新たな診断履歴情報を取得した場合（ステップＳ２１０１：Ｙｅｓ）、傷病状態テーブル２６０を参照して、新たな診断履歴情報の傷病名が、慢性疾患または定期通院の傷病名であるか否かを判断する（ステップＳ２１０２）。

ここで、慢性疾患または定期通院の傷病名の場合（ステップＳ２１０２：Ｙｅｓ）、通知装置１０１は、傷病状態テーブル２６０を参照して、ユーザの通院サイクルに対する今回の通院間隔の差異が所定の時間幅ｗよりも大きいか否かを判断する（ステップＳ２１０３）。

ここで、所定の時間幅ｗ以下の場合（ステップＳ２１０３：Ｎｏ）、通知装置１０１は、本フローチャートによる一連の処理を終了する。一方、所定の時間幅ｗよりも大きい場合（ステップＳ２１０３：Ｙｅｓ）、通知装置１０１は、ユーザの通院サイクルが短くなったことを検出する（ステップＳ２１０４）。

つぎに、通知装置１０１は、通知情報生成処理を実行する（ステップＳ２１０５）。通知情報生成処理は、ユーザの通院サイクルまたは診断結果の変化に応じた通知情報を生成する処理である。通知情報生成処理の具体的な処理手順については、図２４を用いて後述する。

そして、通知装置１０１は、生成した通知情報に設定された重要度に応じた通知方式により、通知情報を通知先に送信して（ステップＳ２１０６）、本フローチャートによる一連の処理を終了する。また、ステップＳ２１０２において、慢性疾患または定期通院の傷病名でない場合（ステップＳ２１０２：Ｎｏ）、通知装置１０１は、図２２に示すステップＳ２２０１に移行する。

図２２のフローチャートにおいて、まず、通知装置１０１は、診断履歴ＤＢ２３０から、所定の期間Ｔ内の診断履歴情報を取得する（ステップＳ２２０１）。つぎに、通知装置１０１は、取得した所定の期間Ｔ内の診断履歴情報から、新たな診断履歴情報とユーザＩＤおよび傷病名が同一の診断履歴情報を検索する（ステップＳ２２０２）。

そして、通知装置１０１は、所定数以上の診断履歴情報が検索されたか否かを判断する（ステップＳ２２０３）。ここで、所定数以上の診断履歴情報が検索された場合（ステップＳ２２０３：Ｙｅｓ）、通知装置１０１は、検索した所定数以上の診断履歴情報を参照して、所定の期間Ｔ内の通院間隔同士の差異が所定の時間幅ｗ以内であるか否かを判断する（ステップＳ２２０４）。

ここで、所定の時間幅ｗ以内の場合（ステップＳ２２０４：Ｙｅｓ）、通知装置１０１は、検索した各診断履歴情報の処方箋情報に薬名が設定されているか否かを判断する（ステップＳ２２０５）。ここで、薬名が設定されている場合（ステップＳ２２０５：Ｙｅｓ）、通知装置１０１は、慢性疾患でのユーザの定期通院化を検出して（ステップＳ２２０６）、ステップＳ２２０８に移行する。

一方、薬名が設定されていない場合（ステップＳ２２０５：Ｎｏ）、通知装置１０１は、ユーザの定期通院化を検出する（ステップＳ２２０７）。つぎに、通知装置１０１は、通知情報生成処理を実行する（ステップＳ２２０８）。そして、通知装置１０１は、生成した通知情報に設定された重要度に応じた通知方式により、通知情報を通知先に送信して（ステップＳ２２０９）、本フローチャートによる一連の処理を終了する。

また、ステップＳ２２０３において、所定数以上の診断履歴情報が検索されなかった場合（ステップＳ２２０３：Ｎｏ）、通知装置１０１は、図２３に示すステップＳ２３０１に移行する。また、ステップＳ２２０４において、所定の時間幅ｗ以内ではない場合（ステップＳ２２０４：Ｎｏ）、通知装置１０１は、図２３に示すステップＳ２３０１に移行する。

図２３のフローチャートにおいて、まず、通知装置１０１は、診断履歴ＤＢ２３０から、新たな診断履歴情報とユーザＩＤおよび傷病名が同一の他の診断履歴情報を検索する（ステップＳ２３０１）。つぎに、通知装置１０１は、他の診断履歴情報が検索されたか否かを判断する（ステップＳ２３０２）。

ここで、他の診断履歴情報が検索された場合（ステップＳ２３０２：Ｙｅｓ）、通知装置１０１は、過去に罹患した傷病と同一の傷病に罹患したことを検出して（ステップＳ２３０３）、ステップＳ２３０５に移行する。

一方、他の診断履歴情報が検索されなかった場合（ステップＳ２３０２：Ｎｏ）、通知装置１０１は、新たな傷病に罹患したことを検出する（ステップＳ２３０４）。つぎに、通知装置１０１は、通知情報生成処理を実行する（ステップＳ２３０５）。そして、通知装置１０１は、生成した通知情報に設定された重要度に応じた通知方式により、通知情報を通知先に送信して（ステップＳ２３０６）、本フローチャートによる一連の処理を終了する。

これにより、ユーザの通院サイクルまたは診断結果の変化を検出した場合、同一グループＧ内の他のユーザに、ユーザの通院サイクルまたは診断結果の変化に応じた通知を行うことができる。

つぎに、図２１に示したステップＳ２１０５、図２２に示したステップＳ２２０８、および図２３に示したステップＳ２３０５の通知情報生成処理の具体的な処理手順について説明する。

図２４は、通知情報生成処理の具体的処理手順の一例を示すフローチャートである。図２４のフローチャートにおいて、まず、通知装置１０１は、検出したユーザの通院サイクルまたは診断結果の変化に応じた通知情報を生成する（ステップＳ２４０１）。

つぎに、通知装置１０１は、ユーザの通院サイクルまたは診断結果の変化の内容に応じて、生成した通知情報に重要度を設定する（ステップＳ２４０２）。そして、通知装置１０１は、通知先テーブル２４０を参照して、生成した通知情報の通知先を設定して（ステップＳ２４０３）、通知情報生成処理を呼び出したステップに戻る。

これにより、ユーザの通院サイクルまたは診断結果の変化に応じた通知情報を生成することができる。なお、ステップＳ２４０１において、通知装置１０１は、詳細判定テーブル２５０を参照して、ユーザから見た通知先の親等に応じて通知情報の内容を変更することにしてもよい。

つぎに、通知装置１０１の第２の通知処理手順について説明する。第２の通知処理は、予め決められた日時（例えば、毎日の深夜）に定期的に実行される処理である。

図２５は、通知装置１０１の第２の通知処理手順の一例を示すフローチャートである。図２５のフローチャートにおいて、まず、通知装置１０１は、グループＤＢ２２０を参照して、未選択のグループＧを選択する（ステップＳ２５０１）。つぎに、通知装置１０１は、傷病状態テーブル２６０を参照して、選択したグループＧの通知区分「本人」のユーザの傷病状態を特定する（ステップＳ２５０２）。

そして、通知装置１０１は、特定した傷病状態が慢性疾患または定期通院であるか否かを判断する（ステップＳ２５０３）。ここで、慢性疾患または定期通院ではない場合（ステップＳ２５０３：Ｎｏ）、通知装置１０１は、ステップＳ２５０９に移行する。

一方、慢性疾患または定期通院の場合（ステップＳ２５０３：Ｙｅｓ）、通知装置１０１は、傷病状態テーブル２６０を参照して、ユーザの次回の通院予定期間を特定する（ステップＳ２５０４）。そして、通知装置１０１は、特定した次回の通院予定期間を経過したか否かを判断する（ステップＳ２５０５）。

ここで、次回の通院予定期間を経過していない場合（ステップＳ２５０５：Ｎｏ）、通知装置１０１は、ステップＳ２５０９に移行する。一方、次回の通院予定期間を経過した場合（ステップＳ２５０５：Ｙｅｓ）、通知装置１０１は、ユーザの通院忘れを検出する（ステップＳ２５０６）。

つぎに、通知装置１０１は、通知情報生成処理を実行する（ステップＳ２５０７）。そして、通知装置１０１は、生成した通知情報を通知先に送信する（ステップＳ２５０８）。つぎに、通知装置１０１は、グループＤＢ２２０を参照して、未選択のグループＧがあるか否かを判断する（ステップＳ２５０９）。

ここで、未選択のグループＧがある場合（ステップＳ２５０９：Ｙｅｓ）、通知装置１０１は、ステップＳ２５０１に戻る。一方、未選択のグループＧがない場合（ステップＳ２５０９：Ｎｏ）、通知装置１０１は、本フローチャートによる一連の処理を終了する。

これにより、ユーザの通院忘れを検出した場合には、グループＧ内の他のユーザに、ユーザが定期的な通院を忘れていることの通知を行うことができる。なお、ステップＳ２５０５において、通知装置１０１は、次回の通院予定期間の末日から一定日数（例えば、１０日〜３０日）経過した日（基準日）を経過した場合には、ユーザが完治したことを検出することにしてもよい。

以上説明したように、実施の形態にかかる通知装置１０１によれば、グループＧ内のユーザの通院サイクルまたは診断結果の変化を検出した場合、グループＧ内の他のユーザに、ユーザの通院サイクルまたは診断結果の変化に応じた通知を行うことができる。

これにより、グループＧ内のユーザ同士が互いの健康状態の変化をいち早く察知して、適切なフォローアクションを早期にとることが可能となる。例えば、家族が離れて暮らしている、あるいは、生活スタイルが異なるような状況であっても、家族が互いの健康状態の変化を察知することができるようになる。

また、通知装置１０１によれば、ユーザと他のユーザとの親族関係の遠近を表す親等情報に基づいて、ユーザの通院サイクルまたは診断結果の変化に応じた通知の内容を変更することができる。これにより、ユーザから見て遠い親族や親族以外の他のユーザに対しては、ユーザが罹患している傷病の詳細を伝えることなく、通院サイクルまたは診断結果の変化を通知することができる。

また、通知装置１０１によれば、ユーザの通院サイクルが短くなったことを検出した場合には、グループＧ内の他のユーザに、ユーザの通院回数が増加したことの通知を行うことができる。これにより、家族の病状が悪化したことをいち早く察知して、その家族に電話したり会いに行くなどして安否を気遣うことができる。

また、通知装置１０１によれば、ユーザが新たな傷病に罹患したことを検出した場合には、グループＧ内の他のユーザに、ユーザが新たな傷病に罹患したことの通知を行うことができる。これにより、家族が新たな傷病に罹患したことをいち早く察知することができる。

また、通知装置１０１によれば、ユーザが過去に罹患した傷病と同一の傷病に罹患したことを検出した場合には、グループＧ内の他のユーザに、ユーザが過去に罹患した傷病を再発もしくは流行性疾患に罹患したことの通知を行うことができる。これにより、家族が再発もしくは流行性疾患に罹患したことをいち早く察知することができる。

また、通知装置１０１によれば、ユーザの定期通院化を検出した場合には、グループＧ内の他のユーザに、ユーザが定期的に通院する状態に変化したことの通知を行うことができる。これにより、家族が定期的な通院が必要な状態となったことをいち早く察知することができる。

また、通知装置１０１によれば、ユーザの通院忘れを検出した場合には、グループＧ内の他のユーザに、ユーザが定期的な通院を忘れていることの通知を行うことができる。これにより、定期通院している家族が通院し忘れている可能性があることをいち早く察知することができ、その家族に電話で確認するなどして通院を促すことができる。

また、通知装置１０１によれば、ユーザの通院サイクルまたは診断結果の変化の内容に応じて、通知を行う通知方式を変更することができる。これにより、他のユーザにすぐに気付いてもらいたい重要度が高い内容の通知であれば、他のユーザによる内容の確認を強制するような通知方式で通知を行うことができる。一方、重要度が高くない内容の通知であれば、他のユーザが任意のタイミングで内容を確認できるような通知方式で通知を行うことができる。

これらのことから、通知装置１０１によれば、日常生活のなかで顔を合わせて話をする機会が少ないような家族であっても、家族の健康状態の変化にいち早く気付くことができる。これにより、例えば、家族が体調を崩したり、病状が悪化した場合などに、その家族に電話したり会いに行って安否を気遣うなどの適切なフォローアクションをとることができるようになる。

また、医療機関のサービスとして、家族の健康状態の変化にいち早く気付くことができるというサービスを提供することができる。これにより、その医療機関が高く評価され、家族単位で患者を取り込むことができるようになる。さらに、医療機関単体だけでなく、診療科が異なる複数のクリニックが同じ建物や敷地に同居する医療モールのような施設全体で情報を共有することで、より相互に患者を呼び込むことが可能となる。

なお、本実施の形態で説明した通知方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本通知プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本通知プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）ユーザの診断履歴情報を記憶する記憶部と、
前記記憶部に記憶された前記診断履歴情報を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う制御部と、
を有することを特徴とする通知装置。

（付記２）前記ユーザは、グルーピングされた複数のユーザのうちのいずれかのユーザであり、
前記所定の通知先は、前記複数のユーザのうちの前記ユーザとは異なる他のユーザを含む、ことを特徴とする付記１に記載の通知装置。

（付記３）前記制御部は、
前記ユーザと前記他のユーザとの親族関係の遠近を表す親等情報に基づいて、前記通知の内容を変更する、ことを特徴とする付記２に記載の通知装置。

（付記４）前記制御部は、
前記ユーザの通院サイクルが短くなったことを検出した場合には、前記所定の通知先に、前記ユーザの通院回数が増加したことの通知を行う、ことを特徴とする付記１〜３のいずれか一つに記載の通知装置。

（付記５）前記制御部は、
前記ユーザが新たな傷病に罹患したことを検出した場合には、前記所定の通知先に、前記ユーザが新たな傷病に罹患したことの通知を行う、ことを特徴とする付記１〜４のいずれか一つに記載の通知装置。

（付記６）前記制御部は、
前記ユーザが過去に罹患した傷病と同一の傷病に罹患したことを検出した場合には、前記所定の通知先に、前記ユーザが過去に罹患した傷病を再発もしくは流行性疾患に罹患したことの通知を行う、ことを特徴とする付記１〜５のいずれか一つに記載の通知装置。

（付記７）前記制御部は、
前記ユーザの定期通院化を検出した場合には、前記所定の通知先に、前記ユーザが定期的に通院する状態に変化したことの通知を行う、ことを特徴とする付記１〜６のいずれか一つに記載の通知装置。

（付記８）前記制御部は、
前記ユーザの通院忘れを検出した場合には、前記所定の通知先に、前記ユーザが定期的な通院を忘れていることの通知を行う、ことを特徴とする付記１〜７のいずれか一つに記載の通知装置。

（付記９）前記制御部は、
前記ユーザの通院サイクルまたは診断結果の変化の内容に応じて、前記通知を行う通知方式を変更する、ことを特徴とする付記１〜８のいずれか一つに記載の通知装置。

（付記１０）前記診断履歴情報は、医療機関において診断されたユーザの診断結果および受診日を特定する情報であり、
前記制御部は、
前記記憶部に記憶された前記診断履歴情報を参照して、所定の期間内の連続する受診日の間隔をそれぞれ算出し、
算出した前記間隔同士の差異に基づいて、前記ユーザの定期通院化を検出する、ことを特徴とする付記７に記載の通知装置。

（付記１１）前記制御部は、
前記ユーザの定期通院化を検出した場合、前記間隔に基づいて、前記ユーザが定期的に通院する際の通院間隔を算出し、
算出した前記通院間隔に基づいて、前記ユーザの通院サイクルの変化を検出する、ことを特徴とする付記１０に記載の通知装置。

（付記１２）前記ユーザの定期通院化を検出した場合、前記ユーザの最終受診日と、前記ユーザの通院サイクルとに基づいて、前記ユーザの次回の通院予定期間を特定し、
特定した前記次回の通院予定期間が経過した場合に、前記ユーザの通院忘れを検出する、ことを特徴とする付記１０または１１に記載の通知装置。

（付記１３）前記他のユーザは、前記ユーザの親族を含む、ことを特徴とする付記２に記載の通知装置。

（付記１４）前記他のユーザは、前記ユーザの介護者、介助者および成年後見人のいずれかを含む、ことを特徴とする付記１３に記載の通知装置。

（付記１５）コンピュータが、
ユーザの診断履歴情報を記憶する記憶部を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出し、
前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う、
処理を実行することを特徴とする通知方法。

（付記１６）コンピュータに、
ユーザの診断履歴情報を記憶する記憶部を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出し、
前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う、
処理を実行させることを特徴とする通知プログラム。

１０１ 通知装置
１１０ 記憶部
１２０ 通知情報
２００ 通知システム
２２０ グループＤＢ
２３０ 診断履歴ＤＢ
２４０ 通知先テーブル
２５０ 詳細判定テーブル
２６０ 傷病状態テーブル
１００１ 取得部
１００２ 検出部
１００３ 生成部
１００４ 出力部
１２００ 第１の通知情報
１３００ 第２の通知情報
１４００ 第３の通知情報
１５００ 第４の通知情報
１６００，１８００ 第５の通知情報
１７００ 第６の通知情報
Ｃ１〜Ｃｍ クライアント端末
Ｔ１〜Ｔｎ 医療機関端末

Claims (10)

1. ユーザの診断履歴情報を記憶する記憶部と、
   前記記憶部に記憶された前記診断履歴情報を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う制御部と、
   を有することを特徴とする通知装置。
2. 前記ユーザは、グルーピングされた複数のユーザのうちのいずれかのユーザであり、
   前記所定の通知先は、前記複数のユーザのうちの前記ユーザとは異なる他のユーザを含む、ことを特徴とする請求項１に記載の通知装置。
3. 前記制御部は、
   前記ユーザと前記他のユーザとの親族関係の遠近を表す親等情報に基づいて、前記通知の内容を変更する、ことを特徴とする請求項２に記載の通知装置。
4. 前記制御部は、
   前記ユーザの通院サイクルが短くなったことを検出した場合には、前記所定の通知先に、前記ユーザの通院回数が増加したことの通知を行う、ことを特徴とする請求項１〜３のいずれか一つに記載の通知装置。
5. 前記制御部は、
   前記ユーザが新たな傷病に罹患したことを検出した場合には、前記所定の通知先に、前記ユーザが新たな傷病に罹患したことの通知を行う、ことを特徴とする請求項１〜４のいずれか一つに記載の通知装置。
6. 前記制御部は、
   前記ユーザが過去に罹患した傷病と同一の傷病に罹患したことを検出した場合には、前記所定の通知先に、前記ユーザが過去に罹患した傷病を再発もしくは流行性疾患に罹患したことの通知を行う、ことを特徴とする請求項１〜５のいずれか一つに記載の通知装置。
7. 前記制御部は、
   前記ユーザの定期通院化を検出した場合には、前記所定の通知先に、前記ユーザが定期的に通院する状態に変化したことの通知を行う、ことを特徴とする請求項１〜６のいずれか一つに記載の通知装置。
8. 前記制御部は、
   前記ユーザの通院忘れを検出した場合には、前記所定の通知先に、前記ユーザが定期的な通院を忘れていることの通知を行う、ことを特徴とする請求項１〜７のいずれか一つに記載の通知装置。
9. コンピュータが、
   ユーザの診断履歴情報を記憶する記憶部を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出し、
   前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う、
   処理を実行することを特徴とする通知方法。
10. コンピュータに、
    ユーザの診断履歴情報を記憶する記憶部を参照して、前記ユーザの通院サイクルまたは診断結果の変化を検出し、
    前記ユーザの通院サイクルまたは診断結果の変化を検出した場合、所定の通知先に、前記ユーザの通院サイクルまたは診断結果の変化に応じた通知を行う、
    処理を実行させることを特徴とする通知プログラム。

Images