JP2014170510A - 申請管理方法及びシステム - Google Patents

Abstract

【課題】健康管理に関するサービスに関連付けられた見舞金制度を可能にする。
【解決手段】本方法は、体調に関する所定の項目についての蓄積データに基づき検出された、特定のユーザについての受診勧奨事象を特定するステップと、ユーザ毎にサービス加入日と過去の受診勧奨事象に基づく見舞金支払いに係る過去の特定の日とを含むデータを格納するデータ格納部から特定のユーザについて読み出されたデータに基づき、サービス加入期間が第１の所定期間以上となっており且つ過去の特定の日から第２の所定期間以上経過しているという条件を満たしているか否かを判断する判断ステップと、上記条件を満たしていると判断された場合に、特定のユーザについて検出された受診勧奨事象に基づく受診に対する見舞金申請が可能な状態に設定する設定ステップとを含む。
【選択図】図１

Description

本発明は、見舞金申請に関連する情報処理技術に関する。

一般的に、保険における通院補償は、入院給付金の対象となる入院の存在を前提として入院の前後に通院を行った場合に給付金が支払われる場合、所定の傷病の治療のために通院された場合に支払われることが多い。いずれにせよ、入院の必要性又は所定の傷病に対する治療の必要性については、医師による診断書により証明されて保険会社により保険金が支払われる。従って、診断書の発行による費用が発生するため、給付される保険金の金額と比較考量することになる。

また、例えば定期的な会費の支払いを条件として所定の場合に見舞金を支払うという制度も存在している。所定の場合は、主に災害、事故、盗難、傷害、妊娠といった場合が多く、疾病については例えば休業を補償するような形で支給される場合が多い。なお、疾病の予兆に着目して見舞金を支払うという発想自体が存在していない。

また、基礎体温管理サーバにより女性の健康管理を支援する健康管理支援システムも存在している。このシステムにおいて、クライアント端末から送信された電子メールの送信元アドレスが電子メールアドレスデータベースに登録された電子メールアドレスである場合には、電子メールの件名に記載された基礎体温情報を基礎体温情報データベースに登録を行う。また、基礎体温情報データベースに登録された基礎体温情報に基づいて、月経期、卵胞期、排卵期及び黄体期の開始タイミングを算出し、各開始タイミングには開始タイミング通知手段によって通知を行うものである。しかしながら、収集したデータを女性特有の疾病の蓋然性検出に用いるようなものではない。

近年、インターネットを介して様々な健康管理に関するサービスが提供されており、付帯的に上記のような見舞金制度を導入しているものも存在しているが、見舞金制度と健康管理に関するサービスとが密接に関連付けられているわけではない。

特開２００８−２７６６７０号公報

従って、本発明の目的は、一側面によれば、健康管理に関するサービスに関連付けられた見舞金制度を可能にするための情報処理技術を提供することである。

本発明に係る申請管理方法は、（Ａ）体調に関する所定の項目についての蓄積データに基づき検出された、特定のユーザについての受診勧奨事象を特定するステップと、（Ｂ）ユーザ毎にサービス加入日と過去の受診勧奨事象に基づく見舞金支払いに係る過去の特定の日とを含むデータを格納するデータ格納部から特定のユーザについて読み出されたデータに基づき、サービス加入期間が第１の所定期間以上となっており且つ過去の特定の日から第２の所定期間以上経過しているという条件を満たしているか否かを判断する判断ステップと、（Ｃ）上記条件を満たしていると判断された場合に、特定のユーザについて検出された受診勧奨事象に基づく受診に対する見舞金申請が可能な状態に設定する設定ステップとを含む。

このように受診勧奨事象の特定に応じて第１段階目の判定を行った上で、受診勧奨事象に基づく受診に対する見舞金申請を可能とすることで、無駄な申請を抑制して審査効率を向上させることができるようになる。

また、上で述べたデータ格納部が、他の申請の審査状況を表すデータをさらに格納している場合もある。この場合には、上記条件が、他の申請が審査中ではないという条件を含むようにしても良い。重複申請を防止するためである。

さらに、上記申請管理方法は、（Ｄ）データ格納部に、特定のユーザについて受診勧奨事象の発生日又は特定のユーザへの提示日を格納するステップと、（Ｅ）データ格納部において特定のユーザについて格納されている受診勧奨事象の発生日又は特定のユーザへの提示日から第３の所定期間経過している場合に、見舞金申請が可能な状態を不可能な状態へ設定を変更するステップとをさらに含むようにしても良い。受診勧奨事象の発生日等からあまりに長く時間が経過した場合には、特定のユーザの体調も変化している可能性が高く、受診が適切ではない可能性が高くなるためである。

さらに、上記申請管理方法は、（Ｆ）前回月経日から算出される第４の所定期間において行われた乳房の確認結果に基づき検出された、特定のユーザについての第２の受診勧奨事象を特定する第２特定ステップをさらに含むようにしても良い。この場合、第２特定ステップに応じて、判断ステップ及び特定ステップが実行されるようにしても良い。基礎体温及び月経日だけではなく、乳房の確認結果によっても受診勧奨事象が検出される場合もある。

また、上で述べた蓄積データが、生理の量と、おりものの量と、生理の量の変化パターンと、おりものの変化パターンとのうち少なくともいずれかを含むようにしても良い。この場合、上記申請管理方法は、（Ｇ）特定のユーザについて、ある期間における生理の総量又はおりものの総量が閾値を超えた場合、生理の量の変化パターンが予め定められた異常時の変化パターンの特徴を有する場合、若しくはおりものの変化パターンが予め定められた異常時の変化パターンの特徴を有する場合に、特定のユーザについての受診勧奨事象を検出するステップとをさらに含むようにしても良い。基礎体温及び月経日だけではなく、このようなデータに基づき受診勧奨事象が検出できる場合もある。

さらに、上記申請管理方法は、（Ｈ）データ格納部に、特定のユーザについて受診勧奨事象の発生日又は特定のユーザへの提示日を格納するステップと、（Ｉ）特定のユーザについて、受診に対する見舞金申請に係る受診日と、受診が初診か否かを表すデータと、受診が公的保険対象であるか否かを表すデータと、受診についての領収書イメージデータとを含む申請データを取得した場合、当該取得された申請データとデータ格納部に格納されている、特定のユーザについてのデータとに基づき、受診日が受診勧奨事象の発生日又は特定のユーザへの提示日から第５の所定期間内であり、受診が初診であり且つ公的保険対象であるという第２の条件を満たしているかを判断するステップと、第２の条件を満たしていると判断された場合には、申請データを審査対象に設定するステップとをさらに含むようにしても良い。

受診勧奨事象に係る受診が適切なものであるか否かを審査の前に判断することで、効率的な審査が行われるようになる。なお、受診日が受診勧奨事象の発生日等のあまりに後であると、受診と受診勧奨事象との因果関係が曖昧になるためである。

さらに、上記申請管理方法は、（Ｊ）特定のユーザについて申請データを取得した日付と当該申請データに基づく審査結果とを、データ格納部に格納するステップと、（Ｋ）データ格納部に格納されているデータに基づき、サービス加入期間が第１の所定期間以上経過しており、審査結果が審査通過を表しており且つ申請データを取得した日付が現在から第６の所定期間内であり、受診勧奨事象の発生日又は特定のユーザへの提示日から第７の所定期間内であるという第３の条件を満たしているか判断するステップと、（Ｌ）第３の条件を満たしていると判断された場合には、特定のユーザについて精密検査に対する見舞金の申請を可能な状態に設定するステップとをさらに含むようにしても良い。

受診勧奨事象に基づき受診すると医師により精密検査が必要というような診断がなされる場合もある。このような精密検査に対して見舞金を支払う場合にも、前もって判定を行った上で、精密検査に対する見舞金申請を可能とすることで、無駄な申請を抑制して審査効率を向上させることができるようになる。

さらに、上で述べたデータ格納部が、精密検査に対する見舞金の申請状況についてのデータをさらに格納している場合もある。この場合、上で述べた第３の条件が、精密検査に対する見舞金の他の申請が審査中ではないという条件と、精密検査に対する見舞金支払いの元となる精密検査の受診日から第８の所定期間経過後の受診勧奨事象の発生日又は特定のユーザへの提示日の発生という条件との少なくともいずれかを含むようにしても良い。重複申請や頻繁な申請は許容できないためである。

また、上記申請管理方法は、（Ｍ）特定のユーザについて、精密検査に対する見舞金申請に係る受診日と、精密検査の項目と、受診が公的保険対象であるか否かを表すデータと、精密検査についての領収書イメージデータとを含む第２の申請データを取得した場合、当該取得された第２の申請データとデータ格納部に格納されている、特定のユーザについてのデータとに基づき、精密検査に対する見舞金申請に係る受診日が受診勧奨事象の発生日又は特定のユーザへの提示日から第９の所定期間内であり、精密検査が公的保険対象であり、精密検査の項目が所定の項目であるという第４の条件を満たしているかを判断するステップと、（Ｎ）第４の条件を満たしていると判断された場合には、第２の申請データを審査対象に設定するステップとをさらに含むようにしても良い。

精密検査を受けた後において得られるデータについて上で述べたような判定を行うことで、審査を効率的に実行できるようになる。

さらに、本発明に係るシステムは、第１の情報処理装置と、第２の情報処理装置とを有する。そして、上記第１の情報処理装置は、（Ａ）体調に関する所定の項目についての蓄積データに基づき検出された、特定のユーザについての受診勧奨事象を特定し、（Ｂ）ユーザ毎にサービス加入日と過去の受診勧奨事象に基づく見舞金支払いに係る過去の特定の日とを含むデータを格納するデータ格納部から特定のユーザについて読み出されたデータに基づき、サービス加入期間が第１の所定期間以上となっており且つ過去の特定の日から第２の所定期間以上経過しているという条件を満たしているか否かを判断し、上記条件を満たしていると判断された場合に、特定のユーザについて検出された受診勧奨事象に基づく受診に対する見舞金申請が可能であることを表すデータを、第２の情報処理装置に送信する。また、上記第２の情報処理装置は、（Ｃ）第１の情報処理装置から受診勧奨事象に基づく受診に対する見舞金申請が可能であることを表すデータを受診すると、特定のユーザについての受診勧奨事象に関するデータと、当該受診勧奨事象に基づく受診に対する見舞金申請を行うためのデータを表示するためのデータを生成する。

第２の情報処理装置は、サーバのようなコンピュータの場合もあれば、アプリケーションがインストールされた携帯端末のような端末装置の場合もある。

さらに、上で述べた第２の情報処理装置は、受診勧奨事象を検出した第３の情報処理装置から受診勧奨事象についてのメッセージを受信し、当該メッセージに関するデータを第１の情報処理装置に送信するようにしても良い。

なお、上で述べたような処理をハードウエアに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

一側面によれば、健康管理に関するサービスに関連付けられた見舞金制度が可能となる。

図１は、本発明の実施の形態に係るシステム構成図である。 図２は、携帯端末の機能ブロック図である。 図３は、検出サーバの機能ブロック図である。 図４は、判定サーバの機能ブロック図である。 図５は、判定サーバのユーザＤＢに格納されるデータの一例を示す図である。 図６は、第１の実施の形態における処理フローを示す図である。 図７は、第１判定処理の処理フローを示す図である。 図８は、携帯端末における表示例を示す図である。 図９は、第１の実施の形態における処理フローを示す図である。 図１０は、第１の実施の形態における処理フローを示す図である。 図１１は、女性疾患見舞金申請時の処理フローを示す図である。 図１２は、申請入力画面の一例を示す図である。 図１３は、要精密検査見舞金申請時の処理フローを示す図である。 図１４は、申請入力画面の一例を示す図である。 図１５は、申請入力画面の一例を示す図である。 図１６は、第２の実施の形態における処理フローを示す図である。 図１７は、生理の量についての基準パターンの一例を示す図である。 図１８Ａは、異常を示すレベル遷移パターンの一例を示す図である。 図１８Ｂは、異常を示すレベル遷移パターンの一例を示す図である。 図１８Ｃは、異常を示すレベル遷移パターンの一例を示す図である。 図１８Ｄは、異常を示すレベル遷移パターンの一例を示す図である。 図１９は、おりものの量についての基準パターンの一例を示す図である。 図２０Ａは、異常を示すレベル遷移パターンの一例を示す図である。 図２０Ｂは、異常を示すレベル遷移パターンの一例を示す図である。 図２１は、コンピュータの機能ブロック図である。

［実施の形態１］
本実施の形態に係るサービスでは、基礎体温及び月経日等のデータを蓄積して、当該データから疾患の疑い（以下、受診勧奨事象と呼ぶ）を検出すると受診勧奨を行う。そして、該当するユーザが当該受診勧奨に応じて医療機関に受診し且つ条件を満たしている場合には、女性疾病見舞金を支払うものである。さらに、このような受診勧奨に応じて医療機関に受診すると、精密検査が必要になる場合もある。このような場合にも、条件を満たせば、要精密検査見舞金を支払うものである。なお、基礎体温及び月経日等のデータだけではなく、月経日に基づき特定される所定期間において乳がんのセルフチェックを行って、セルフチェックの結果に基づき受診勧奨事象を検出する。

図１に、本実施の形態に係るサービスのためのシステムの概要を示す。インターネット及び携帯電話通信網を含むネットワーク１には、ユーザの携帯端末３と、検出サーバ５と、判定サーバ７と、決済サーバ９とが接続されている。本実施の形態では、携帯端末３と、検出サーバ５と、判定サーバ７と、決済サーバ９とが連携して、本実施の形態に係るサービスが提供される。

携帯端末３は、例えばスマートフォンであり、図２に示すように、健康管理アプリケーション３００がインストールされている。健康管理アプリケーション３００は、携帯端末３で実行されると、表示処理部３１０と、基礎データ処理部３２０と、乳がんチェック支援部３３０と、受診勧奨処理部３４０と、申請処理部３５０と、データ格納部３６０とが実現される。

表示処理部３１０は、他の処理部と連携して携帯端末３の表示部に、以下で説明する画面表示を行わせる。基礎データ処理部３２０は、例えば月経日データ及び基礎体温等を、基礎体温計やユーザの入力から収集して、検出サーバ５へ送信する処理等を行う。

乳がんチェック支援部３３０は、ユーザによる乳がんチェックを支援し、所定の項目についてのデータをユーザの入力から収集して、検出サーバ５へ送信する処理等を行う。受診勧奨処理部３４０は、検出サーバ５から受診勧奨通知を受信した場合に、判定サーバ７へ受診勧奨データを送信すると共に、受診勧奨メッセージを表示部に表示させる処理等を実行する。さらに、受診勧奨処理部３４０は、判定サーバ７からの判定結果通知に含まれる見舞金申請可否の判定結果に基づき、見舞金申請ボタンのアクティブ化又は非アクティブ化を行う。

申請処理部３５０は、見舞金申請が可能な状態においてユーザから指示された場合にユーザからの入力により申請データを収集して、判定サーバ７に送信する処理等を実行する。データ格納部３６０は、各処理部において用いられるデータの少なくとも一部が格納される。

また、検出サーバ５は、図３に示すように、第１検出処理部５１と、第２検出処理部５２と、第３検出処理部５３と、第４検出処理部５４と、データベース（ＤＢ）５５とを有する。

データベース５５は、例えば、ユーザ毎に、ユーザＩＤ、生年月日、月経日及び基礎体温データを蓄積し、乳がんチェック項目のデータを格納する。

第１検出処理部５１及び第２検出処理部５２は、ＤＢ５５に格納された月経日及び基礎体温データに基づき受診勧奨事象の検出処理を実行し、受診勧奨事象を検出した場合には、受診勧奨通知を該当するユーザの携帯端末３へ送信する。

第３検出処理部５３は、ＤＢ５５に格納された、乳がんチェック項目のデータに基づき受診勧奨事象の検出処理を実行し、受診勧奨事象を検出した場合には、受診勧奨通知を該当するユーザの携帯端末３へ送信する。

第４検出処理部５４については、本実施の形態では用いられないが、ＤＢ５５に格納された他のデータに基づき受診勧奨事象の検出処理を実行し、受診勧奨事象を検出した場合には、受診勧奨通知を該当するユーザの携帯端末３へ送信する。

さらに、判定サーバ７は、図４に示すように、第１判定処理部７１と、第２判定処理部７２と、第３判定処理部７３と、第４判定処理部７４と、審査支援処理部７５と、ユーザＤＢ７６と、申請データ格納部７７とを有する。

第１判定処理部７１は、以下で述べる女性疾患診断時見舞金の申請可否についての判定処理を実行する。第２判定処理部７２は、女性疾患診断時見舞金の申請時における判定処理を実行する。第３判定処理部７３は、以下で述べる要精密検査時見舞金の申請可否についての判定処理を実行する。第４判定処理部７４は、要精密検査時見舞金の申請時における判定処理を実行する。

審査支援処理部７５は、携帯端末３から受信した申請データを用いた審査を支援する処理等を実行する。申請データ格納部７７は、各見舞金についての申請データを格納する。

ユーザＤＢ７６は、例えば図５に示すようなデータを格納する。図５の例では、ユーザＩＤと、氏名と、住所と、サービス開始日と、受診勧奨通知日と、受診勧奨コードと、女性疾病見舞金の申請状況を表す申請状況１と、女性疾病見舞金の審査１に係る受診日と、女性疾病見舞金の審査１に係る申請日と、女性疾病見舞金の審査１の審査結果と、要精密検査見舞金の申請状況を表す申請状況２と、要精密検査見舞金の審査２に係る受診日と、要精密検査見舞金の審査２に係る申請日と、要精密検査見舞金の審査２の結果とが登録されるようになっている。

次に、図６乃至図１５を用いて図１に示したシステムの処理内容について説明する。携帯端末３の健康管理アプリケーション３００における基礎データ処理部３２０は、ユーザからの指示に応じて基礎体温データの入力を受け付け、ユーザＩＤと共に検出サーバ５へ送信する（図６：ステップＳ１）。このステップでは、ユーザの入力又は基礎体温計からの入力を受け付ける。これに対して、検出サーバ５は、携帯端末３からユーザＩＤ及び基礎体温データを受信すると、ユーザＩＤに対応付けてＤＢ５５に格納する（ステップＳ３）。

また、携帯端末３の健康管理アプリケーション３００における基礎データ処理部３２０は、ユーザからの指示に応じて月経日の入力を受け付けて、ユーザＩＤと共に検出サーバ５へ送信する（ステップＳ５）。なお、直近月経日については、データ格納部３６０にも格納される。

これに対して、検出サーバ５は、携帯端末３からユーザＩＤ及び月経日データを受信すると、ユーザＩＤに対応付けてＤＢ５５に格納する（ステップＳ７）。

ここで、検出サーバ５は、第１検出処理部５１及び第２検出処理部５２に処理開始を指示し、第１検出処理部５１及び第２検出処理部５２は、第１検出処理を実行する（ステップＳ９）。

上でも述べたように、第１検出処理部５１は、基礎体温についての蓄積データを基に受診勧奨事象の有無を判断する。例えば、第１検出処理部５１は、（１）直近１〜３の月経周期において、基礎体温が正常な２層パターンと異なるか、もしくは周期異常（例えば２４日未満又は３９日以上）か否かを判断する。この判断については、従来から用いられている方法を使用しても良いので、詳細な説明については省略する。

第２検出処理部５２は、月経日についての蓄積データを基に受診勧奨事象の有無を判断する。例えば、第２検出処理部５２は、（２）直近月経周期が、１２日未満である場合、（３）直近月経周期が、９１日以上である場合、（４）直近月経３周期が、３９日以上又は２４日未満である場合のいずれかに該当するか否かを判断する。

なお、第１検出処理部５１及び第２検出処理部５２は、ユーザＩＤに対応付けて格納されている生年月日から１８歳乃至４５歳であるか否かを判断した上で、上記の判断を行う。

第１検出処理部５１又は第２検出処理部５２が受診勧奨事象を検出しなかった場合又はユーザが年齢の条件を満たさない場合には（ステップＳ１１：Ｎｏルート）、この段階で処理は終了する。

一方、第１検出処理部５１又は第２検出処理部５２のいずれかが受診勧奨事象を検出しており且つユーザが年齢の条件を満たしている場合には（ステップＳ１１：Ｙｅｓルート）、第１検出処理部５１又は第２検出処理部５２は、検出した受診勧奨事象を表すコードを含む受診勧奨通知を生成し、携帯端末３へ送信する（ステップＳ１３）。受診勧奨通知に、受診勧奨事象を表すコードに対応する、ユーザに提示すべきメッセージを含める場合もあれば、メッセージ自体は携帯端末３の健康管理アプリケーション３００が保持しているか又は別途取得するようにしても良い。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、検出サーバ５から受診勧奨通知を受信すると（ステップＳ１５）、受診勧奨通知に含まれる受診勧奨コード及びユーザＩＤを含む受診勧奨データを、判定サーバ７へ送信する（ステップＳ１７）。判定サーバ７による事前判定が完了しないと、見舞金の申請を可能にすることはできないので、判定サーバ７へ受診勧奨データを送信する。なお、受診勧奨処理部３４０は、受診勧奨通知受信に応じて、受診勧奨通知日をデータ格納部３６０に格納する場合もある。

判定サーバ７は、携帯端末３から受診勧奨データを受信すると（ステップＳ１９）、第１判定処理部７１及び第３判定処理部７３に処理を開始させる。また、ユーザＩＤに対応付けて、ユーザＤＢ７６に、受診勧奨通知日及び受診勧奨コードを登録する。

そして、第１判定処理部７１及び第３判定処理部７３は、第１判定処理を実行する（ステップＳ２１）。第１判定処理については、図７を用いて説明する。

第１判定処理部７１は、ユーザＤＢ７６に格納されているデータに基づき女性疾病見舞金についての第１申請可否事前判定処理を実行する（ステップＳ３１）。具体的には、以下のような判定を実行する。
（Ａ１）待機期間中か否か
サービス開始日後所定期間日以内の受診勧奨事象の検出については、申請を受け付けない。疾患発生状態でのサービス加入が疑われるケースについては見舞金支払いの対象外とするものである。
（Ａ２）申請期限内か否か
受診勧奨通知日から所定期間経過後は、申請を受け付けない。受診勧奨事象が既に存在していない場合もあるためである。
（Ａ３）審査の重複があるか否か
後に述べるように乳がんセルフチェックに応じて別の受診勧奨事象が検出される場合もあり、本実施の形態では別の受診勧奨事象に基づく女性疾病見舞金の申請も可能となっている。但し、見舞金の重複支給を認めていないので、別の受診勧奨事象に基づく女性疾病見舞金の申請を審査している状態であれば、今回の受診勧奨事象については申請を許可しない。ユーザＤＢ７６における申請状況１のデータに基づき判定する。
（Ａ４）過去の女性疾病見舞金の支給の有無
過去に審査ＯＫとなった女性疾病見舞金の受診日（図５における審査１に係る受診日）から所定期間内については、申請を許可しない。なお、受診日ではなく、見舞金の支払日、見舞金の申請日などを基準として用いる場合もある。

このように、第１判定処理部７１は、ユーザＤＢ７６に格納されているデータに基づき女性疾病見舞金についての第１申請可否事前判定処理を実行する。

次に、第３判定処理部７３は、要精密検査見舞金についての第２申請可否事前判定処理を実行する（ステップＳ３３）。具体的には、以下のような判定を実行する。
（Ｂ１）待機期間中か否か
サービス開始日後所定期間日以内の受診勧奨事象の検出については、申請を受け付けない。疾患発生状態でのサービス加入が疑われるケースについては見舞金支払いの対象外とするものである。
（Ｂ２）申請期限内か否か
受診勧奨通知日から所定期間経過後は、申請を受け付けない。受診勧奨事象が既に存在していない場合もあるためである。なお、受診後さらに精密検査を行うことになるので、（Ａ２）の所定期間より長い所定期間が設定される。
（Ｂ３）審査の重複があるか否か
要精密検査見舞金について既になされた申請を審査中であれば、申請を受け付けない。重複支給は行わないためである。ユーザＤＢ７６における申請状況２のデータに基づき判断する。
（Ｂ４）過去の要精密検査見舞金の支給の有無
過去に審査ＯＫとなった要精密検査見舞金の受診日（図５における審査２に係る受診日）から所定期間内については、申請を許可しない。
（Ｂ５）女性疾病見舞金の申請の有無
過去所定期間内に審査ＯＫとなっている女性疾病見舞金の申請がない場合には申請を受け付けない。要精密検査見舞金は、女性疾病見舞金の申請及び支給を条件として支給されるものであるためである。

このように、第３判定処理部７３は、要精密検査見舞金についての第２申請可否事前判定処理を実行する。

図６の処理の説明に戻って、第１判定処理部７１及び第３判定処理部７３は、判定結果を携帯端末３へ送信する（ステップＳ２３）。女性疾病見舞金の申請許可又は拒否、要精密検査見舞金の申請許可又は拒否という判定結果が携帯端末３へ送信される。なお、初期的には要精密検査見舞金の申請は必ず拒否となる。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、判定サーバ７から判定結果を受信し（ステップＳ２５）、表示処理部３１０に、受診勧奨内容及び判定結果に基づき申請ボタン表示を行わせる（ステップＳ２７）。

例えば、女性疾病見舞金についての申請許可となっている場合には、図８に示すような表示がなされる。図８の例では、乳がんチェックについてのメッセージ１（例えば乳がんチェック期間についてのメッセージ）と、乳がんチェックについての画面に遷移するためのボタン１００１と、受診勧奨コードに対応するメッセージ２と、女性疾病見舞金申請のためのボタン１００２と、女性疾病見舞金申請のための受診期限及び申請期限と、要精密検査見舞金申請のためのボタン１００３と、要精密検査見舞金申請のための受診期限及び申請期限とが表示されるようになっている。ボタン１００２及び１００３については、判定結果に基づき、アクティブ化又は非アクティブ化がなされ、図８の例では女性疾病見舞金申請のためのボタン１００２のみがアクティブ化されている。なお、婦人科と乳腺外科とは別タブとなっており、図６の処理では、婦人科についての受診勧奨事象が検出された場合を示している。さらに、受診期限及び申請期限については、受診勧奨通知日から算出されるので、受診勧奨処理部３４０で算出しても良いし、判定サーバ７側で算出して通知するようにしても良い。なお、図８では、４月１日を受診勧奨通知日とした受信期限及び申請期限の一例を示している。

ユーザは、このような画面表示に応じて体調の問題を認識し、受診への動機付けがなされることとなる。

なお、ボタン１００２及び１００３のアクティブ化及び非アクティブ化については、上で述べたように時間の経過、申請状況及び審査状況に応じて変化するので、例えば図９に示すような処理を、健康管理アプリケーション３００起動時、毎日１回などに行って、ボタン１００２及び１００３のアクティブ化及び非アクティブ化を変更する。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、ユーザＩＤを含む確認通知を、判定サーバ７に送信する（図９：ステップＳ４１）。判定サーバ７は、携帯端末３からユーザＩＤを含む確認通知を受信すると（ステップＳ４３）、第１判定処理部７１及び第３判定処理部７３に処理を実行させる。

すなわち、第１判定処理部７１及び第３判定処理部７３は、ユーザＤＢ７６において受信したユーザＩＤに対応付けて格納されているデータを用いて、第１判定処理を実行する（ステップＳ４５）。第１判定処理の内容については、図７に関連して説明した内容と同様である。

そして、第１判定処理部７１及び第３判定処理部７３は、判定結果を、確認通知の送信元携帯端末３へ送信する（ステップＳ４７）。これに対して、携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、判定サーバ７から判定結果を受信すると（ステップＳ４９）、判定結果に基づく申請ボタンの表示を、表示処理部３１０に行わせる（ステップＳ５１）。

このようにすれば時間の経過、申請状況及び審査状況に応じて、申請の可否状態が変化するので、携帯端末３における画面表示を適切に変更することができるようになる。

次に、乳がんチェックについて受診勧奨事象を検出する場合の処理について、図１０を用いて説明する。

まず、携帯端末３の健康管理アプリケーション３００における乳がんチェック支援部３３０は、データ格納部３６０に格納されている直前月経日からセルフチェック期間を特定し、携帯端末３の表示部に表示する（図１０：ステップＳ６１）。例えば、月経開始日から８日乃至１５日目（７日間）を、セルフチェック期間として特定する。なお、一定期間月経日が入力されていない場合には、前回月経開始後３９日目から７日間をチェック期間として算出する。また、月経日が入力されると、上記のように月経開始日から８日乃至１５日目もチェック可能とする。さらに、月経日が入力されず再度３９日経過すると３９日目乃至４６日目もチェック期間とする。

そして、乳がんチェック支援部３３０は、表示処理部３１０に、イラストなどに沿ってチェック項目を提示しつつ、ユーザにセルフチェック結果の入力を促し、入力を受け付ける。チェック項目は、乳房の所定部分にしこりが存在するか否かというものであるが、セルフチェック項目自体については既に知られているものであるから、ここでは詳しく述べない。

セルフチェック結果の入力が完了すると、乳がんチェック支援部３３０は、セルフチェック結果のデータを、ユーザＩＤと共に検出サーバ５へ送信する（ステップＳ６３）。検出サーバ５は、携帯端末３からセルフチェック結果のデータを受信すると（ステップＳ６５）、受信したデータをユーザＩＤに対応付けてＤＢ５５に格納する。

そして、第３検出処理部５３は、第２検出処理を実行する（ステップＳ６７）。本実施の形態における第２検出処理では、受信したセルフチェック結果の各項目のいずれかに、予め異常と定められた回答が含まれているか否かを判断する。いずれかの項目について異常と定められた回答があれば、受診勧奨事象が検出されたことになる。

第３検出処理部５３が受診勧奨事象を検出しなかった場合には（ステップＳ６９：Ｎｏルート）、この段階で処理は終了する。

一方、第３検出処理部５３が受診勧奨事象を検出した場合には（ステップＳ６９：Ｙｅｓルート）、第３検出処理部５３は、検出した受診勧奨事象を表すコードを含む受診勧奨通知を生成し、携帯端末３へ送信する（ステップＳ７１）。受診勧奨通知に、受診勧奨事象を表すコードに対応する、ユーザに提示すべきメッセージを含める場合もあれば、メッセージ自体は携帯端末３の健康管理アプリケーション３００が保持しているか又は別途取得するようにしても良い。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、検出サーバ５から受診勧奨通知を受信すると（ステップＳ７３）、受診勧奨通知に含まれる受診勧奨コード及びユーザＩＤを含む受診勧奨データを、判定サーバ７へ送信する（ステップＳ７５）。判定サーバ７による事前判定が完了しないと、見舞金の申請を可能にすることはできないので、判定サーバ７へ受診勧奨データを送信する。なお、受診勧奨処理部３４０は、受診勧奨通知受信に応じて、受診勧奨通知日をデータ格納部３６０に格納する場合もある。

判定サーバ７は、携帯端末３から受診勧奨データを受信すると（ステップＳ７７）、第１判定処理部７１及び第３判定処理部７３に処理を開始させる。また、ユーザＩＤに対応付けて、ユーザＤＢ７６に、受診勧奨通知日及び受診勧奨コードを登録する。

そして、第１判定処理部７１及び第３判定処理部７３は、第１判定処理を実行する（ステップＳ７９）。第１判定処理については、図７に関連して説明したとおりである。

その後、第１判定処理部７１及び第３判定処理部７３は、判定結果を携帯端末３へ送信する（ステップＳ８１）。女性疾病見舞金の申請許可又は拒否、要精密検査見舞金の申請許可又は拒否という判定結果が携帯端末３へ送信される。なお、初期的には要精密検査見舞金の申請は必ず拒否となる。また、既に婦人科についての判定結果に基づき女性疾病見舞金の申請が行われている場合には、申請拒否ということになる場合もある。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、判定サーバ７から判定結果を受信し（ステップＳ８３）、表示処理部３１０に、受診勧奨内容及び判定結果に基づき申請ボタン表示を行わせる（ステップＳ８５）。図８とほぼ同様の表示が、携帯端末３の表示部になされる。具体的には、乳腺外科のタブが選択された状態になり、受診勧奨コードに対応するメッセージが表示され、判定結果に応じて申請ボタンがアクティブ化又は非アクティブ化される。

このようにすれば、乳がんのセルフチェック結果に応じて、受診勧奨事象が検出され且つ上記のような条件が満たされていれば、女性疾病見舞金の申請ができるようになる。

次に、女性疾病見舞金の申請を行う際の処理フローについて図１１及び図１２を用いて説明する。

携帯端末３の健康管理アプリケーション３００における申請処理部３５０は、女性疾病見舞金の申請ボタン（図８のボタン１００２）の押し下げを検出すると（図１１：ステップＳ９１）、表示処理部３１０に、申請入力画面を表示部に表示させる（ステップＳ９３）。そして、申請処理部３５０は、ユーザからの入力を受け付ける。例えば図１２に示すような画面を表示させる。

図１２の例では、名前（データ格納部３６０に格納されているデータから自動入力）と、住所と、郵便番号と、電話番号と、受診日と、医療機関名と、受診科（選択タブから自動入力）と、受診時の症状と、公的保険の対象か否かと、初診か否かと、領収書写真とが、選択又は入力されるようになっている。受診時の症状については、基礎体温の異常、月経の異常など、受診勧奨事象に応じた項目が選択可能に提示される。また、乳がんチェック結果に基づく受診勧奨事象であれば、乳腺外科のタブにおいて申請すれば、乳房の異常と自動選択される。なお、キャンセルボタン及び確認するボタンも用意されており、キャンセルする場合にはキャンセルボタンを押し、入力内容を確認する場合には確認するボタンを押す。

確認するボタンが押された場合には、図１２のような入力画面に入力されたデータを含む入力確認画面が表示される。例えば、領収書写真についても表示してその鮮明さやサイズなどが適切か確認するように促しても良い。入力確認画面において、申請が指示されると、申請処理部３５０は、ユーザＩＤ、入力データ及び領収書写真データを含む申請データを、判定サーバ７へ送信する（ステップＳ９５）。判定サーバ７は、携帯端末３から申請データを受信すると（ステップＳ９７）、申請データ格納部７７に格納する。

そして、第２判定処理部７２は、申請データ格納部７７及びユーザＤＢ７６に受信したユーザＩＤに対応付けて格納されているデータを用いて第２判定処理を実行する（ステップＳ９９）。第２判定処理は、人手による審査の事前処理であり、以下のような判定処理である。

（Ｃ１）初診か否か
申請データから初診でなければエラーと判定する。既に通院しているような場合には、見舞金を給付するのは不適切であるためである。
（Ｃ２）公的保険の対象か否か
申請データから公的保険の対象でなければエラーと判定する。
（Ｃ３）受診科が婦人科又は乳腺外科（外科）か否か
申請データから受診科が婦人科又は乳腺外科（外科）以外であればエラーと判定する。
（Ｃ４）受診日が受診勧奨通知日から所定期間内であるか否か
申請データに含まれる受診日が、ユーザＤＢ７６に格納されている受診勧奨通知日から所定期間内でない場合には、エラーと判定する。検出された受診勧奨事象に応じた受診であることを確保するためである。

このような判定処理においていずれかでエラーが発生している場合には（ステップＳ１０１：Ｙｅｓルート）、第２判定処理部７２は、携帯端末３へ、判定されたエラーに対応するエラーコードを含むエラー通知を送信する（ステップＳ１０７）。携帯端末３の健康管理アプリケーション３００における申請処理部３５０は、判定サーバ７からエラー通知を受信すると、表示部に、エラーコードに対応するメッセージを表示する（ステップＳ１０９）。ユーザは、エラーメッセージを参照して、申請をやり直すなどの操作を行うことになる。

一方、エラーが検出されない場合には（ステップＳ１０１：Ｎｏルート）、第２判定処理部７２は、審査支援処理部７５に通知することで、審査員による申請データの審査を支援させる。そして、審査員は、申請データ格納部７７に格納されている申請データに基づき審査を実行する（ステップＳ１０３）。この審査自体は人手によるものであるから図１１では点線表示がなされている。なお、この段階で、審査支援処理部７５は、申請データに基づきユーザＤＢ７６を更新する。具体的には、図５の例では、申請状況１に対して今回の受診科を登録し、審査１に係る受診日に対して今回の受診日を登録し、審査１に係る申請日に対して今回の申請日を登録する。

審査は、（ａ）領収書写真が不鮮明ではないこと、（ｂ）領収書写真が切れていないこと、（ｃ）適切な内容の領収書写真であること、（ｄ）領収書写真における氏名が申請データに含まれる氏名と一致すること、（ｅ）領収書写真における受診信日が申請データに含まれる受診日と一致すること、（ｆ）領収書写真における受診科が申請データに含まれる受診日と一致すること、（ｇ）領収書写真における医療機関名が申請データに含まれる医療機関名と一致すること、（ｈ）領収書写真における公的保険対象の有無の表示が申請データに含まれる公的保険対象というデータと一致すること、（ｉ）領収書写真における初診又は最新の表示が申請データに含まれる初診というデータと一致すること、（ｊ）受診日が受診勧奨通知日から所定期間内であること、（ｋ）申請データの受診日が受診勧奨通知日から所定期間内であること、を確認する。（ｊ）及び（ｋ）については再確認となる。

以上述べた審査でＯＫと判定されると、審査支援処理部７５は、審査１の審査結果に対してＯＫを登録する。なお、審査がＯＫとならなかった場合には、この段階でメールその他の手段によりエラーを通知する。そして、例えばユーザＤＢ７６へ行った更新をクリアするなどの処理を行う。

さらに、審査支援処理部７５は、決済サーバ９を介して申請を行ったユーザに対する見舞金の送金処理を実行させる（ステップＳ１０５）。この処理は、様々な方式があり、本実施の形態の主旨ではないので、説明を省略する。なお、この段階で、メールなどによりユーザに対して審査完了を通知するようにしても良い。

このようにすれば、検出サーバ５による受診勧奨事象の検出に応じた医療機関への受診に対して適切に見舞金を支払うことができるようになる。

次に、要精密検査見舞金の申請を行う際の処理フローについて図１３乃至図１５を用いて説明する。

携帯端末３の健康管理アプリケーション３００における申請処理部３５０は、要精密検査見舞金の申請ボタン（図８のボタン１００３）の押し下げを検出すると（図１３：ステップＳ１１１）、表示処理部３１０に、申請入力画面を表示部に表示させる（ステップＳ１１３）。そして、申請処理部３５０は、ユーザからの入力を受け付ける。例えば図１４及び図１５に示すような画面を表示させる。

図１４の例では、名前（データ格納部３６０に格納されているデータから自動入力）と、住所と、郵便番号と、電話番号と、受診日と、医療機関名と、受診科（選択タブから自動入力）と、疑いのあるとされた病気と、公的保険の対象か否かと、精密検査種類と、領収書写真とが、選択又は入力されるようになっている。

疑いのあるとされた病気については、図１５に示すように、ポップアップで選択肢が表示され、いずれかを選択するようになっている。同様に、精密検査種類についても、同様に、ポップアップで選択肢が表示され、いずれかを選択するようになっている。

なお、キャンセルボタン及び確認するボタンも用意されており、キャンセルする場合にはキャンセルボタンを押し、入力内容を確認する場合には確認するボタンを押す。

確認するボタンが押された場合には、図１４のような入力画面に入力されたデータを含む入力確認画面が表示される。例えば、領収書写真についても表示してその鮮明さやサイズなどが適切か確認するように促しても良い。入力確認画面において、申請が指示されると、申請処理部３５０は、ユーザＩＤ、入力データ及び領収書写真データを含む申請データを、判定サーバ７へ送信する（ステップＳ１１５）。判定サーバ７は、携帯端末３から申請データを受信すると（ステップＳ１１７）、申請データ格納部７７に格納する。

そして、第４判定処理部７４は、申請データ格納部７７及びユーザＤＢ７６に受信したユーザＩＤに対応付けて格納されているデータを用いて第３判定処理を実行する（ステップＳ１１９）。第３判定処理は、人手による審査の事前処理であり、以下のような判定処理である。

（Ｄ１）公的保険の対象か否か
申請データから公的保険の対象でなければエラーと判定する。
（Ｄ２）受診科が婦人科又は乳腺外科（外科）か否か
申請データから受診科が婦人科又は乳腺外科（外科）以外であればエラーと判定する。
（Ｄ３）受診日が受診勧奨通知日から所定期間内であるか否か
申請データに含まれる受診日が、ユーザＤＢ７６に格納されている受診勧奨通知日から所定期間内（Ｃ４の所定期間より長い）でない場合には、エラーと判定する。検出された受診勧奨事象に基づく精密検査であることを確保するためである。
（Ｄ４）精密検査項目が所定の精密検査項目であるか否か
申請データに含まれる精密検査項目が、所定の精密検査項目以外であればエラーと判定する。

このような判定処理においていずれかでエラーが発生している場合には（ステップＳ１２１：Ｙｅｓルート）、第４判定処理部７４は、携帯端末３へ、判定されたエラーに対応するエラーコードを含むエラー通知を送信する（ステップＳ１２７）。携帯端末３の健康管理アプリケーション３００における申請処理部３５０は、判定サーバ７からエラー通知を受信すると、表示部に、エラーコードに対応するメッセージを表示する（ステップＳ１２９）。ユーザは、エラーメッセージを参照して、申請をやり直すなどの操作を行うことになる。

一方、エラーが検出されない場合には（ステップＳ１２１：Ｎｏルート）、第４判定処理部７４は、審査支援処理部７５に通知することで、審査員による申請データの審査を支援させる。そして、審査員は、申請データ格納部７７に格納されている申請データに基づき審査を実行する（ステップＳ１２３）。この審査自体は人手によるものであるから図１３では点線表示がなされている。なお、この段階で、審査支援処理部７５は、申請データに基づきユーザＤＢ７６を更新する。具体的には、図５の例では、申請状況２に対して今回の受診科を登録し、審査２に係る受診日に対して今回の受診日を登録し、審査２に係る申請日に対して今回の申請日を登録する。

審査は、上で述べた（ａ）乃至（ｈ）及び（ｊ）及び（ｋ）に加えて、（ｌ）領収書写真における精密検査項目が申請データに含まれる精密検査項目と一致することも確認される。要精密検査見舞金の申請については（ｉ）は除外される。

以上述べた審査でＯＫと判定されると、審査支援処理部７５は、申請データに基づきユーザＤＢ７６を更新する。具体的には、図５の例では、審査２の審査結果に対してＯＫを登録する。なお、審査がＯＫとならなかった場合には、この段階でメールその他の手段によりエラーを通知する。そして、例えばユーザＤＢ７６へ行った更新をクリアするなどの処理を行う。

さらに、審査支援処理部７５は、決済サーバ９を介して申請を行ったユーザに対する見舞金の送金処理を実行させる（ステップＳ１２５）。この処理は、様々な方式があり、本実施の形態の主旨ではないので、説明を省略する。なお、この段階で、メールなどによりユーザに対して審査完了を通知するようにしても良い。

このようにすれば、検出サーバ５による受診勧奨事象の検出に基づき行われた精密検査に対して適切に見舞金を支払うことができるようになる。

［実施の形態２］
検出処理については、以下に述べるような処理を実行するようにしても良い。

まず、携帯端末３の健康管理アプリケーション３００における基礎データ処理部３２０は、ユーザからの指示に応じて状態データの入力を受け付け、ユーザＩＤと共に検出サーバ５へ送信する（図１６：ステップＳ１３１）。

本実施の形態では、生理の量のレベル及びおりものの量のレベルをユーザが入力する。例えば、予め４段階又は５段階で量を規定しておき、例えば毎日どのレベルに該当するのかを入力する。これに対して、検出サーバ５は、携帯端末３からユーザＩＤ及び状態データを受信すると、ユーザＩＤに対応付けてＤＢ５５に格納する（ステップＳ１３３）。

このような状態データの登録を繰り返した後、第３検出処理を実行するのに十分なデータがＤＢ５５に蓄積されると、検出サーバ５は、第４検出処理部５４に処理開始を指示し、第４検出処理部５４は、ＤＢ５５に格納されているデータを用いて第３検出処理を実行する（ステップＳ１３５）。

第４検出処理部５４は、生理の量のレベルについては、生理中のレベルの総和と、レベル遷移パターンとで受診勧奨事象の有無を判断する。例えば、生理の量のレベルが、少ない場合に小さな値、多い場合に大きな値を割り当てるようにして、レベル値の総和を算出した上で所定の閾値と比較し、レベル値の総和が所定の閾値を超えている場合には、受診勧奨事象が発生していると判定する。

また、例えば、ＤＢ５５から、図１７に示すようなレベル遷移パターンの基準パターンを特定する。具体的には、前月の記録を基準にするか、前月までのデータにおいて最大値のパターン又は平均レベルのパターンを基準パターンとして特定する。そして、図１８Ａに示すように、基準パターンにおける最大レベルの日のレベルが２段階以上アップした場合には、受診勧奨事象が発生したと判定する。また、図１８Ｂに示すように、基準パターンと比較して、レベルが１段階アップした日が３日以上となった場合には、受診勧奨事象が発生したと判定する。

さらに、基準パターンを複数月について決定されたパターンとする場合には、図１８Ｃ及び図１８Ｄに示すように、１段階アップした日が２日以上で２ヶ月連続する場合には、受診勧奨事象が発生したと判定する。

このようないずれかの受診勧奨事象を検出したか否かを判断する。

さらに、第４検出処理部５４は、おりものの量のレベルについては、生理後から生理前までのレベルの総和と、レベル遷移パターンとで受診勧奨事象の有無を判断する。例えば、おりものの量のレベルが、小さい場合には小さい値、多い場合には大きな値を割り当てるようにして、レベル値の総和を算出した上で所定の閾値と比較し、レベル値の総和が所定の閾値を超えている場合には、受診勧奨事象が発生していると判定する。

また、例えばＤＢ５５から、図１９に示すようなレベル遷移パターンの基準パターンを特定する。基準パターンは、生理の量の場合と同様に特定する。そして、図２０Ａに示すように、排卵期の量が最も多いレベル４となった場合には、そのレベルが３日以上連続した場合には、受診勧奨事象が発生していると判定する。また、図２０Ｂに示すように、生理前のレベルが２段階以上アップして少なくとも３日間連続する場合には、受診勧奨事象が発生していると判定する。

このようないずれかの受診勧奨事象を検出したか否かを判断する。

なお、これらのレベル遷移パターンは一例であって、他の知見に基づく他のレベル遷移パターンをも受診勧奨事象として検出するようにしても良い。さらに、パターンマッチングのような処理を行うことで受診勧奨事象を検出するようにしても良い。

第４検出処理部５４が受診勧奨事象を検出しなかった場合には（ステップＳ１３７：Ｎｏルート）、この段階で処理は終了する。

一方、第４検出処理部５４が受診勧奨事象を検出した場合には（ステップＳ１３７：Ｙｅｓルート）、第４検出処理部５４は、検出した受診勧奨事象を表すコードを含む受診勧奨通知を生成し、携帯端末３へ送信する（ステップＳ１３９）。受診勧奨通知に、受診勧奨事象を表すコードに対応する、ユーザに提示すべきメッセージを含める場合もあれば、メッセージ自体は携帯端末３の健康管理アプリケーション３００が保持しているか又は別途取得するようにしても良い。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、検出サーバ５から受診勧奨通知を受信すると（ステップＳ１４１）、受診勧奨通知に含まれる受診勧奨コード及びユーザＩＤを含む受診勧奨データを、判定サーバ７へ送信する（ステップＳ１４３）。判定サーバ７による事前判定が完了しないと、見舞金の申請を可能にすることはできないので、判定サーバ７へ受診勧奨データを送信する。なお、受診勧奨処理部３４０は、受診勧奨通知受信に応じて、受診勧奨通知日をデータ格納部３６０に格納する場合もある。

判定サーバ７は、携帯端末３から受診勧奨データを受信すると（ステップＳ１４５）、第１判定処理部７１及び第３判定処理部７３に処理を開始させる。また、ユーザＩＤに対応付けて、ユーザＤＢ７６に、受診勧奨通知日及び受診勧奨コードを登録する。

そして、第１判定処理部７１及び第３判定処理部７３は、第１判定処理を実行する（ステップＳ１４７）。第１判定処理については、図７を用いて説明したとおりであり、ここでは説明を省略する。

第１判定処理部７１及び第３判定処理部７３は、判定結果を携帯端末３へ送信する（ステップＳ１４９）。女性疾病見舞金の申請許可又は拒否、要精密検査見舞金の申請許可又は拒否という判定結果が携帯端末３へ送信される。なお、初期的には要精密検査見舞金の申請は必ず拒否となる。

携帯端末３の健康管理アプリケーション３００における受診勧奨処理部３４０は、判定サーバ７から判定結果を受信し（ステップＳ１５１）、表示処理部３１０に、受診勧奨内容及び判定結果に基づき申請ボタン表示を行わせる（ステップＳ１５３）。

このように第３検出処理によって検出された受診勧奨事象に基づき処理を行うようにしても良い。

この他にも、不正出血の有無、生理時以外の痛み、ＰＭＳ（Premenstrual Syndrome）症状の有無に応じて、受診勧奨事象の検出を行うようにしても良い。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で述べた機能ブロック図は一例であって、プログラムモジュール構成と一致しない場合もある。また、データベース構成についても一例であって、他の構成を採用するようにしても良い。

さらに、システム構成についても、判定サーバ７と検出サーバ５とを別に設ける例を示したが、一体として実施するようにしても良い。さらに、判定サーバ７と検出サーバ５の機能を、より多くのサーバにて機能分担するようにしても良い。また、判定サーバ７及び検出サーバ５のインタフェースとなるＷｅｂサーバを用意して、携帯端末３に健康管理アプリケーション３００をインストールすることなく、ＷｅｂブラウザでＷｅｂサーバにアクセスするような実施の形態を採用することも可能である。

判定処理及び検出処理についても、上で述べた処理の一部は別の処理に入れられる場合もある。例えば、年齢確認については、検出処理ではなく、判定処理において行われる場合もある。

また、受診勧奨通知日の代わりに、受診勧奨をユーザに提示した日を確認できれば、その日を採用するようにしても良い。

なお、検出サーバ５及び判定サーバ７はコンピュータ装置であって、図２１に示すように当該コンピュータ装置においては、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

さらに、携帯端末３の場合には、ドライブ装置２５１３の代わりにフラッシュメモリによるメモリ装置が導入され、通信制御部２５１７は無線通信機となる。さらに、入力装置２５１５と表示装置２５０９は、タッチパネル式の表示装置として実装される場合もある。

３ 携帯端末
３００ 健康管理アプリケーション
３１０ 表示処理部
３２０ 基礎データ処理部
３３０ 乳がんチェック支援部
３４０ 受診勧奨処理部
３５０ 申請処理部
３６０ データ格納部
５ 検出サーバ
５１ 第１検出処理部
５２ 第２検出処理部
５３ 第３検出処理部
５４ 第４検出処理部
５５ ＤＢ
７ 判定サーバ
７１ 第１判定処理部
７２ 第２判定処理部
７３ 第３判定処理部
７４ 第４判定処理部
７５ 審査支援処理部
７６ ユーザＤＢ
７７ 申請データ格納部

Claims (11)

1. 体調に関する所定の項目についての蓄積データに基づき検出された、特定のユーザについての受診勧奨事象を特定するステップと、
   ユーザ毎にサービス加入日と過去の受診勧奨事象に基づく見舞金支払いに係る過去の特定の日とを含むデータを格納するデータ格納部から前記特定のユーザについて読み出されたデータに基づき、サービス加入期間が第１の所定期間以上となっており且つ前記過去の特定の日から第２の所定期間以上経過しているという条件を満たしているか否かを判断する判断ステップと、
   前記条件を満たしていると判断された場合に、前記特定のユーザについて検出された前記受診勧奨事象に基づく受診に対する見舞金申請が可能な状態に設定する設定ステップと、
   を含み、１又は複数のコンピュータにより実行される申請管理方法。
2. 前記データ格納部が、他の申請の審査状況を表すデータをさらに格納しており、
   前記条件が、他の申請が審査中ではないという条件を含む
   請求項１記載の申請管理方法。
3. 前記データ格納部に、前記特定のユーザについて前記受診勧奨事象の発生日又は前記特定のユーザへの提示日を格納するステップと、
   前記データ格納部において前記特定のユーザについて格納されている前記受診勧奨事象の発生日又は前記特定のユーザへの提示日から第３の所定期間経過している場合に、前記見舞金申請が可能な状態を不可能な状態へ設定を変更するステップと、
   をさらに含む請求項１又は２記載の申請管理方法。
4. 前回月経日から算出される第４の所定期間において行われた乳房の確認結果に基づき検出された、前記特定のユーザについての第２の受診勧奨事象を特定する第２特定ステップ
   をさらに含み、
   前記第２特定ステップに応じて、前記判断ステップ及び前記特定ステップが実行される
   請求項２記載の申請管理方法。
5. 前記蓄積データが、生理の量と、おりものの量と、生理の量の変化パターンと、おりものの変化パターンとのうち少なくともいずれかを含み、
   前記特定のユーザについて、ある期間における生理の総量又はおりものの総量が閾値を超えた場合、生理の量の変化パターンが予め定められた異常時の変化パターンの特徴を有する場合、又はおりものの変化パターンが予め定められた異常時の変化パターンの特徴を有する場合に、前記特定のユーザについての受診勧奨事象を検出するステップと、
   をさらに含む請求項１乃至４のいずれか１つ記載の申請管理方法。
6. 前記データ格納部に、前記特定のユーザについて前記受診勧奨事象の発生日又は前記特定のユーザへの提示日を格納するステップと、
   前記特定のユーザについて、前記受診に対する見舞金申請に係る受診日と、受診が初診か否かを表すデータと、前記受診が公的保険対象であるか否かを表すデータと、前記受診についての領収書イメージデータとを含む申請データを取得した場合、当該取得された申請データと前記データ格納部に格納されている、前記特定のユーザについてのデータとに基づき、前記受診日が前記受診勧奨事象の発生日又は前記特定のユーザへの提示日から第５の所定期間内であり、前記受診が初診であり且つ公的保険対象であるという第２の条件を満たしているかを判断するステップと、
   前記第２の条件を満たしていると判断された場合には、前記申請データを審査対象に設定するステップと、
   をさらに含む請求項１記載の申請管理方法。
7. 前記特定のユーザについて前記申請データを取得した日付と当該申請データに基づく審査結果とを、前記データ格納部に格納するステップと、
   前記データ格納部に格納されているデータに基づき、前記サービス加入期間が第１の所定期間以上経過しており、前記審査結果が審査通過を表しており且つ前記申請データを取得した日付が現在から第６の所定期間内であり、前記受診勧奨事象の発生日又は前記特定のユーザへの提示日から第７の所定期間内であるという第３の条件を満たしているか判断するステップと、
   前記第３の条件を満たしていると判断された場合には、前記特定のユーザについて精密検査に対する見舞金の申請を可能な状態に設定するステップと、
   をさらに含む請求項６記載の申請管理方法。
8. 前記データ格納部が、前記精密検査に対する見舞金の申請状況についてのデータをさらに格納しており、
   前記第３の条件が、前記精密検査に対する見舞金の他の申請が審査中ではないという条件と、前記精密検査に対する見舞金支払いの元となる前記精密検査の受診日から第８の所定期間経過後の前記受診勧奨事象の発生日又は前記特定のユーザへの提示日の発生という条件との少なくともいずれかを含む
   請求項７記載の申請管理方法。
9. 前記特定のユーザについて、前記精密検査に対する見舞金申請に係る受診日と、前記精密検査の項目と、前記受診が公的保険対象であるか否かを表すデータと、前記精密検査についての領収書イメージデータとを含む第２の申請データを取得した場合、当該取得された第２の申請データと前記データ格納部に格納されている、前記特定のユーザについてのデータとに基づき、前記精密検査に対する見舞金申請に係る受診日が前記受診勧奨事象の発生日又は前記特定のユーザへの提示日から第９の所定期間内であり、前記精密検査が公的保険対象であり、前記精密検査の項目が所定の項目であるという第４の条件を満たしているかを判断するステップと、
   前記第４の条件を満たしていると判断された場合には、前記第２の申請データを審査対象に設定するステップと、
   をさらに含む請求項８記載の申請管理方法。
10. 第１の情報処理装置と、
    第２の情報処理装置と、
    を有し、
    前記第１の情報処理装置は、
    体調に関する所定の項目についての蓄積データに基づき検出された、特定のユーザについての受診勧奨事象を特定し、
    ユーザ毎にサービス加入日と過去の受診勧奨事象に基づく見舞金支払いに係る過去の特定の日とを含むデータを格納するデータ格納部から前記特定のユーザについて読み出されたデータに基づき、サービス加入期間が第１の所定期間以上となっており且つ前記過去の特定の日から第２の所定期間以上経過しているという条件を満たしているか否かを判断し、
    前記条件を満たしていると判断された場合に、前記特定のユーザについて検出された前記受診勧奨事象に基づく受診に対する見舞金申請が可能であることを表すデータを、前記第２の情報処理装置に送信し、
    前記第２の情報処理装置は、
    前記第１の情報処理装置から前記受診勧奨事象に基づく受診に対する見舞金申請が可能であることを表すデータを受診すると、前記特定のユーザについての受診勧奨事象に関するデータと、当該受診勧奨事象に基づく受診に対する見舞金申請を行うためのデータを表示するためのデータを生成する
    システム。
11. 前記第２の情報処理装置は、
    前記受診勧奨事象を検出した第３の情報処理装置から前記受診勧奨事象についてのメッセージを受信し、当該メッセージに関するデータを前記第１の情報処理装置に送信する
    請求項１０記載のシステム。

Images