JP2004358052A

JP2004358052A - 家庭用健康管理システム

Info

Publication number: JP2004358052A
Application number: JP2003162129A
Authority: JP
Inventors: Hideaki Katayama; 秀昭片山; Kaneyasu Chiyou; 金保趙
Original assignee: Hitachi Maxell Ltd
Current assignee: Maxell Holdings Ltd
Priority date: 2003-06-06
Filing date: 2003-06-06
Publication date: 2004-12-24

Abstract

【課題】サーバ側のシステムに接続することなくユーザ側のシステムでバイタル・データの解析結果を得る。
【解決手段】バイタル・データを測定するセンサ部と、センサ部により測定されたバイタル・データを記憶する記憶装置と、記憶装置に格納されたバイタル・データを送信する送信部とを含むバイタル・データ測定装置と、バイタル・データ測定装置から送信されたバイタル・データを受信する受信部と、受信部により受信されたバイタル・データを記憶する記憶部と、記憶部に記憶されたバイタル・データを解析し、解析結果を記憶部に記憶する解析プログラムと、解析プログラムの解析結果を表示する表示部とを含むユーザ端末とを有する。これにより、ユーザは、ユーザ側のシステムのみによってバイタル・データの解析結果を得ることができる。
【選択図】図１

Description

【０００１】
【発明が属する技術分野】
本発明は、個人の健康管理に用いられる家庭用健康管理システムに関する。
【０００２】
【従来の技術】
近年、国民の健康指向の高まりとともに、健康食品や健康器具等、健康を指向した商品が数多く開発され市場に出回ってきている。また、病院等の医療機関に出向くことなく在宅で健康を管理するための技術も多数存在する。
【０００３】
例えば、患者であるユーザが任意の場所で迅速に診断結果を得ることを可能とし、各患者のデータを集中管理することで、診断の合理化を図る技術が存在する（例えば、特許文献１参照）。すなわち、端末装置の計測器によって所定の生態を計測し、この生態計測情報を中央処理装置側に通信ネットワークを通して送信すると、中央処理装置は通信ネットワークを通してこの生態計測情報を診断検査できる診断検査装置に対し生態計測情報を送信し、診断検査装置は診断検査部によりその生態計測情報を診断検査すると、通信ネットワークを通して中央処理装置側に送信し、中央処理装置は診断検査装置よりの診断結果情報を通信ネットワークを通して端末装置側に送信する在宅健康管理システムが存在する。
【０００４】
また例えば、ユーザが健康を害する可能性があるか又は害した際に、適切な時に適切な医療、又は介護が受けられるように常時、個人の健康を管理するための技術が存在する（例えば、特許文献２参照）。すなわち、生体検査データ又は検体検査データを収集する収集手段と、前記収集手段により収集された検査データに基づいて、健康状態の異常を示す異常値を検出する異常値検出手段と、異常値検出手段による異常値の検出に応じて、検出結果を病院に通知するための通信手段とを具備する、病院の外部に設けられるパーソナル健康管理システムが存在する。
【０００５】
また例えば、潜在患者の多い生活習慣病患者及び予備軍に対し、医療機関等とのネットワークを構築し、自ら或いは医師などによる日常の健康管理をサポートし、健康管理に必要な医療情報の提供サービスを行うための技術が存在する（例えば、特許文献３参照）。すなわち、健康管理センタは、情報通信回線を介して、ユーザと医療機関と接続されており、高血圧症、高脂血症、糖尿病または喘息／ＣＯＰＤ（慢性閉塞性肺疾患）等の生活習慣病患者及びその予備軍（患者ではないが発症する可能性の高い人）であるユーザの家には、バイタルセンサ制御部を中心として、ユーザの各疾病の測定に必要なバイタルセンサが選択され接続されたシステムがあり、健康管理センタは、記憶部とサーバとを有し、各ユーザから送信されるバイタルセンサのデータの記憶部への格納や、ユーザの検査結果のデータを評価し、ユーザの自己管理をサポートする健康管理システムが存在する。
【０００６】
また例えば、個人の日頃の生活習慣や健康度合いを十分に把握でき、個人に必要な生活改善のアドバイスのみを随時通知することで、より確実に極度の負荷なく生活改善を促すための技術が存在する（例えば、特許文献４参照）。すなわち、アドバイス装置によって健康管理対象者に応じたアドバイスを健康管理端末へ通知し、このアドバイスに対して健康管理対象者がアドバイス装置に返した応答内容を用いて、健康管理対象者に応じた健康安定点に近づけるアドバイスに修正を行ってアドバイスを健康管理端末へ通知することを繰り返す健康管理方法、アドバイス装置及び健康管理システムが存在する。
【０００７】
また例えば、個人の健康管理を日常的にサポートし、且つビジネスとして成立させるための技術が存在する（例えば、特許文献５参照）。すなわち、個人ユーザとデータ処理センタと医療機関との間で通信ネットワークを構築し、個人ユーザは、周知の健康管理端末を使用して自身の健康管理に係わる情報を検出または計測し、その個人情報をデータ処理センタへ送信し、データ処理センタは、個人ユーザから送信された個人情報を入力して解析するコンピュータを備え、解析した加工情報を医療機関へ送信し、医療機関は、データ処理センタから送信された加工情報に医師の判断を加えて、個人ユーザに健康指導（生活習慣の改善指導等）を行う健康管理システムが存在する。
【０００８】
【特許文献１】
特開平８−３８４３５号公報
【特許文献２】
特開平９−２８６８２号公報
【特許文献３】
特開２００２−５６０９９号公報
【特許文献４】
特開２００２−１４９８３０号公報
【特許文献５】
特開２００２−１６３３６９号公報
【０００９】
【発明が解決しようとする課題】
しかしながら以上のような従来技術では、いずれも医療機関が主体の遠隔医療システムとなっており、例えばユーザ端末とサーバとが接続されているネットワークに不具合が発生した場合には、ユーザはバイタル・データの解析結果を得ることができない。また、医療機関固有のネットワークで構成されているため、ユーザは、診療予約等を他の医療機関について行うことができない。
【００１０】
従って本発明の目的は、家庭用健康管理システムにおいて、サーバ側のシステムに接続することなくユーザ側のシステムでバイタル・データの解析結果を得ることを可能とするための新規な技術を提供することである。
【００１１】
また、本発明の他の目的は、家庭用健康管理システムにおいて、サービスの提供を受ける医療機関の選択を可能とする新規な技術を提供することである。
【００１２】
【課題を解決するための手段】
本発明に係る家庭用健康管理システムは、バイタル・データを測定するセンサ部と、センサ部により測定されたバイタル・データを記憶する記憶装置と、記憶装置に格納されたバイタル・データを送信する送信部とを含むバイタル・データ測定装置と、バイタル・データ測定装置から送信されたバイタル・データを受信する受信部と、受信部により受信されたバイタル・データを記憶する記憶部と、記憶部に記憶されたバイタル・データを解析し、解析結果を記憶部に記憶する解析プログラムと、解析プログラムの解析結果を表示する表示部とを含むユーザ端末とを有する。
【００１３】
これにより、ユーザは、例えばユーザの家庭内に設置されたユーザ側のシステムのみによって、バイタル・データの解析結果を得ることができる。
【００１４】
また、解析プログラムが、記憶部に記憶されているユーザのバイタル・データの正常範囲に関するデータを用いて、受信部により受信され且つ記憶部に記憶されたバイタル・データが正常範囲にあるか判定する機能を有するようにしてもよい。
【００１５】
これにより、例えばユーザの身長、体重、年齢及び性別等のデータから算出されるバイタル値の正常範囲内に、測定結果であるバイタル値が含まれていない場合には異常を検出することができる。また、バイタル値が正常な範囲にあった場合でも、そのことをユーザは確認することができ、サーバ側のシステムに接続することなく健康チェックを終えることができる。
【００１６】
また、センサ部は、１回の測定操作により少なくとも血糖値、中性脂肪値及びコレステロール値を測定可能なものであってもよい。なるべく多くの種類のバイタル・データを一度に計測可能とすることにより、ユーザの負担を軽減することができる。
【００１７】
また、上記家庭用健康管理システムが、ユーザ端末とネットワークを介して接続された管理システムをさらに有し、ユーザ端末が、ネットワークに接続するための手段をさらに備え、管理システムが、バイタル・データの詳細な解析及び医師からのアドバイスの少なくともいずれかの依頼データをユーザ端末から受信し且つ医療機関用システムから当該依頼への応答データを受信した場合、依頼への応答データを応答データ記憶部に記憶する手段と、応答データ記憶部に記憶された依頼への応答データをユーザ端末に送信する手段とを備えていてもよい。
【００１８】
これにより、ユーザは、計測したバイタル値に異常が検出されて自己の健康状態に不安を感じた場合等には、バイタル・データの詳細な解析及び医師からのアドバイスの少なくともいずれかを要求することができ、またオンラインで医師からの応答を得ることができる。
【００１９】
また、管理システムが、ユーザ端末から診療予約についての入力データを受信した場合、診療予約データを生成し、診療予約データ記憶部に記憶する診療予約処理手段と、診療予約データ記憶部に記憶された診療予約データを医療機関用システムに送信する手段とをさらに備えていてもよい。
【００２０】
これにより、ユーザは、計測したバイタル値に異常が検出されて自己の健康状態に不安を感じた場合等には、診療の予約をオンラインで行うことができる。
【００２１】
また、診療予約処理手段が、ユーザに少なくとも医療機関の選択を促す手段と、ユーザ端末から、少なくとも医療機関の選択データを受信した場合、選択された医療機関についての診療予約データを生成し、診療予約データ記憶部に記憶する手段と備えていてもよい。これにより、ユーザは、複数の医療機関の中から、自己の希望する医療機関を選択して診療予約を行うことができる。
【００２２】
また、管理システムが、バイタル・データの詳細な解析及び医師からのアドバイスに対する費用をオンラインで決済するための手段をさらに備えていてもよい。これにより、決済の際のユーザの負担を軽減することができる。
【００２３】
また、送信部と受信部とが、ブルー・トゥース（Ｂｌｕｅｔｏｏｔｈ：近距離無線伝送技術。詳しくは、ｈｔｔｐ：／／ｗｗｗ．ｂｌｕｅｔｏｏｔｈ．ｃｏｍ／を参照のこと）規格に従った構成を有している場合もある。接続の煩雑さ、コードの取り回し等の観点から好ましいためである。
【００２４】
なお、解析プログラム、及び本発明に係る家庭用健康管理システムを構成するコンピュータに実行させるその他のプログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００２５】
【発明の実施の形態】
本発明の一実施の形態に係るシステム構成図を図１に示す。例えばインターネットであるネットワーク１には、管理サーバ５と、医療機関１００の医療機関ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）１１と、例えばパーソナル・コンピュータである１又は複数のユーザ端末３とが、無線又は有線によって接続されている。
【００２６】
管理サーバ５には、決済処理部５０１と予約処理部５０３と医療機関仲介処理部５０５とが含まれている。決済処理部５０１は、ユーザが本システムを利用して発生した費用の電子決済処理を行う。電子決済可能な費用には、例えば医師による詳細なバイタル・データの解析やアドバイス等への対価が含まれる。
【００２７】
予約処理部５０３と医療機関仲介処理部５０５との処理内容については処理フローの説明において述べるが、管理サーバ５は、この他に図示していないウェブ（Ｗｅｂ）サーバ機能を有しており、Ｗｅｂページ・データの生成・送信処理等を行えるようになっている。
【００２８】
さらに、管理サーバ５は、ファイル格納部５０を管理しており、ファイル格納部５０には、ユーザ・データ・ファイル５０７とバイタル・データ・ファイル５０９と医師・医療機関データ・ファイル５１１と予約データ・ファイル５１３と詳細結果・アドバイス・ファイル５１５とが含まれている。
【００２９】
ユーザ・データ・ファイル５０７には、ユーザＩＤ、氏名、住所等、本システムのユーザに関するデータが格納されている。また、バイタル・データ・ファイル５０９には、ユーザ端末３からユーザのバイタル・データを受信した場合に、ユーザのバイタル・データが格納される。なお、バイタル・データには、例えば血圧、脈拍、体温、血糖値、中性脂肪値及びコレステロール値等、ユーザの健康状態を把握するために測定された値が含まれている。
【００３０】
また、医師・医療機関データ・ファイル５１１には、医療機関の所在地、診療科、所属する医師、診療可能日等、医師及び医療機関に関するデータが格納されている。なお、本実施の形態においては、医師に関するデータとして、少なくとも診療科と経験値と詳細解析・アドバイス回数とが格納されている。なお、経験値には、医師の経験年数、手術回数等に基づく値が予め格納されており、詳細解析・アドバイス回数には、ユーザからの依頼に応答して医師がバイタル・データの詳細な解析又はアドバイスを行った回数が格納される。
【００３１】
また、予約データ・ファイル５１３には、ユーザが本システムを通じて医療機関への診療予約を行った場合に、診療予約データが格納される。診療予約データには、例えば受付番号、ユーザＩＤ、医療機関、担当医師、予約日時等のデータが含まれる。また、詳細結果・アドバイス・ファイル５１５には、ユーザからの依頼に応答して医師がバイタル・データの詳細な解析又はアドバイスを行った場合に、当該バイタル・データの詳細な解析又はアドバイスに関するデータが格納される。例えば、ユーザＩＤ、応答医師、応答内容等が含まれている。
【００３２】
また、医療機関１００には、医療機関ＬＡＮ１１に加え、医療機関端末７と医療機関サーバ９とが含まれており、それらは無線又は有線によって医療機関ＬＡＮ１１に接続されている。医療機関端末７はファイル格納部７０を管理しており、ファイル格納部７０には、ユーザ・データ・ファイル７１とバイタル・データ・ファイル７３と詳細結果・アドバイス・ファイル７５と予約データ・ファイル７７とが含まれている。これらのファイルは、上で述べた管理サーバ５のファイル格納部５０に含まれている各ファイルと同様の構成となっており、例えば医療機関端末７を利用する医師が取り扱うデータが格納される。
【００３３】
また、医療機関サーバ９は、スケジュール・データベース（ＤＢ）９０を管理しており、スケジュールＤＢ９０には、その医療機関の診療スケジュールに関するデータが格納されている。なお、本システムを利用していない患者の診療予約データも含まれている場合もある。
【００３４】
また、ユーザ端末３には、例えばブルー・トゥース規格に従った構成を有する測定結果受信部３０７と、解析プログラム３０９と、例えばＴＣＰ／ＩＰでネットワークを介して通信を行うための通信処理部３１１とが含まれている。測定結果受信部３０７及び解析プログラム３０９の処理内容については処理フローの説明において述べるが、解析プログラム３０９はＷｅｂブラウザ機能を有しており、通信処理部３１１を介してＷｅｂサーバにアクセスすることにより、Ｗｅｂページを表示させることが可能となっている。また、ユーザ端末３は、この他に図示していないメーラ機能を有し、メールの送受信及び閲覧を可能とさせている。さらに、ユーザ端末３には、表示装置３１３と入力装置３１５と出力装置３１７とが接続されている。
【００３５】
また、ユーザ端末３は、ファイル格納部３２０を管理しており、ファイル格納部３２０には、測定結果ファイル３２１と解析結果ファイル３２３と詳細結果・アドバイス・ファイル３２４とが含まれている。
【００３６】
測定結果ファイル３２１には、ユーザが測定したバイタル・データ及び測定日時が格納される。なお、本実施の形態においては、測定結果ファイル３２１には、例えばユーザの身長、体重、年齢及び性別等のデータ及びこれらのデータから算出されるバイタル値の正常範囲に関するデータも格納されるが、異なるファイルに格納するようにしてもよい。
【００３７】
また、解析結果ファイル３２３には、解析プログラム３０９によるバイタル・データの解析結果が格納される。また、詳細結果・アドバイス・ファイル３２４には、ユーザがバイタル・データの詳細な解析又はアドバイスを医師に依頼して、医師からの応答があった時に、応答内容であるバイタル・データの詳細な解析結果又はアドバイスのデータが格納される。なお、バイタル・データの詳細な解析及びアドバイスの、依頼及び応答は、どちらか一方だけではなく、併行して処理される場合もある。
【００３８】
また、ユーザ端末３には、１又は複数のバイタル測定器３０が、例えばブルー・トゥースにより接続される。バイタル測定器３０には、測定結果記憶部３０１と、例えばブルー・トゥース規格に従って構成されている測定結果送信部３０３とが含まれており、１又は複数のセンサ３０５が接続されている。これらの処理内容については処理フローの説明において述べるが、センサ３０５には、可能な限りにおいて、１回の測定操作により、より多くの種類のバイタル・データを測定可能なものを用いるようにする。例えば、少なくとも血糖値、中性脂肪値及びコレステロール値を１回で測定可能なものを用いるものとする。
【００３９】
次に、図２乃至図１２を用いて図１に示したシステムの処理内容について説明する。図２には、バイタル測定器３０においてユーザのバイタル・データを測定し、ユーザ端末３においてバイタル・データの解析を行う際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【００４０】
まず、バイタル測定器３０のセンサ３０５は、ユーザによるバイタル・データ測定指示操作に従い、バイタル・データを取得・測定し、測定結果記憶部３０１に格納する（図２：ステップＳ１）。
【００４１】
そして、バイタル測定器３０の測定結果送信部３０３は、自動で又はユーザからのバイタル・データ送信指示に従い、測定結果記憶部３０１に格納されたバイタル・データをユーザ端末３に対してブルー・トゥース規格のプロトコルに従って送信する（ステップＳ３）。ユーザ端末３の測定結果受信部３０７は、バイタル・データをバイタル測定器３０からブルー・トゥース規格のプロトコルに従って受信し、測定結果ファイル３２１に格納する（ステップＳ５）。
【００４２】
そして、ユーザ端末３のＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）は、ユーザからのバイタル・データ解析指示を受け付けると、解析プログラム３０９を起動する（ステップＳ７）。ユーザ端末３の解析プログラム３０９は、測定結果ファイル３２１に格納されたバイタル・データの解析処理を行う（ステップＳ９）。
【００４３】
ここで、図３に、解析処理の詳細についての処理フローを示す。なお、解析処理は、上で述べたとおり、解析プログラム３０９によって行われる。また、解析処理には、例えばユーザの身長、体重、年齢及び性別等のユーザの基礎データを用いるため、解析処理の開始時にユーザからの基礎データの入力を受け付け、一旦ワーク・メモリ領域等の記憶装置に格納しておく。予め、図示しない基礎データ記憶部等に格納しておいてもよい。
【００４４】
まず、ユーザ端末３の測定結果ファイル３２１に格納されたバイタル・データ、すなわち、今回測定されたバイタル値のうち、例えば血糖値等の特定のバイタル値をユーザ端末３の表示装置３１３に表示する（図３：ステップＳ２１）。そして、上で述べたユーザの基礎データを用いてバイタル値の正常範囲を計算し、ユーザ端末３の測定結果ファイル３２１に格納する（ステップＳ２３）。ユーザの基礎データを用いてバイタル値の正常範囲を計算する処理については周知の技術を利用するため詳述しないが、バイタル値の正常範囲のデータを何らかの方法で取得しておくようにしてもよい。また、計算結果を測定結果ファイル３２１以外の記憶部に格納するようにしてもよい。
【００４５】
そして、ステップＳ２１において特定されたバイタル値が、正常値であるかどうか判定する（ステップＳ２５）。ステップＳ２３において計算された範囲に含まれていれば正常値である。正常値であると判定された場合（ステップＳ２５：Ｙｅｓルート）、例えば「正常値」という文字列等、正常である旨をユーザ端末３の表示装置３１３に表示する（ステップＳ２７）。そして後に述べるステップＳ３１の処理に移行する。
【００４６】
一方、正常値ではないと判定された場合（ステップＳ２５：Ｎｏルート）、警告及び正常範囲からのずれをユーザ端末３の表示装置３１３に表示する（ステップＳ２９）。例えば、標準値のＸ倍等と示してもよいし、正常範囲より何単位多い又は少ない等と示すようにしてもよい。
【００４７】
そして、これまでの処理により、全てのバイタル値についての表示処理が行われたかどうか判定する（ステップＳ３１）。全てのバイタル値についての表示処理が終了していないと判定された場合（ステップＳ３１：Ｎｏルート）、ステップＳ２１の処理に戻り、次のバイタル値を特定して表示する。なお、表示するバイタル値をユーザが選択できるようにしてもよい。例えば血糖値及び中性脂肪値についてのみ表示する等の設定を行うことができるような構成を採用してもよい。
【００４８】
一方、全てのバイタル値についての表示処理が行われたと判定された場合（ステップＳ３１：Ｙｅｓルート）、表示した画面（以下に述べるバイタル・データ表示画面）においてグラフ表示の指示がなされたかどうか判定する（ステップＳ３３）。
【００４９】
図４に、バイタル・データ表示画面の一例を示す。図４の例には、操作メニュー・バー４００とバイタル・データ表示部４１０と終了ボタン４２０とが含まれている。
【００５０】
操作メニュー・バー４００には、「バイタル・データ」ボタン４０２と「グラフ」ボタン４０４と「医師への依頼」ボタン４０６と「診療予約」ボタン４０８とが含まれている。操作メニュー・バー４００では、各ボタンがクリックされることにより、各ボタンで示される画面に移行する指示を受け付ける。
【００５１】
「バイタル・データ」ボタン４０２がクリックされると、本バイタル・データ表示画面（図４）への移行指示を受け付け、「グラフ」ボタン４０４がクリックされると、後で述べるグラフ表示画面への移行指示を受け付ける。この場合、グラフ表示の指示がなされたと判定され、図３のステップＳ３３においてＹｅｓルートへ進む。また、「医師への依頼」ボタン４０６がクリックされると、後で述べる医師への依頼画面への移行指示を受け付け、「診療予約」ボタン４０８がクリックされると、後で述べる診療予約画面への移行指示を受け付ける。
【００５２】
また、バイタル・データ表示部４１０には、バイタル・データａ表示部４１２とバイタル・データｂ表示部４１４と、・・・バイタル・データｎ表示部４１６とが含まれている。例えばバイタル・データａが血糖値であり、バイタル・データｂが中性脂肪値であるというように、このようなバイタル・データの表示部は、測定するバイタル・データの種類分設けられている。図示していないが、この他にも他の種類のバイタル・データについての表示部が含まれている場合もある。
【００５３】
また、終了ボタン４２０がクリックされると、解析プログラム３０９の終了指示を受け付ける。ユーザは、バイタル・データ表示部４１０に示されている各バイタル値を確認し、操作メニュー・バー４００のいずれかのボタン又は終了ボタン４２０をクリックする。
【００５４】
図３の処理フローに戻り、ステップＳ３３（図３）においてグラフ表示ではないと判定された場合（ステップＳ３３：Ｎｏルート）、元の処理（図２）に戻る。一方、グラフ表示であったと判定された場合（ステップＳ３３：Ｙｅｓルート）、グラフの枠、縦軸及び横軸を表示装置３１３に表示する（ステップＳ３５）。
【００５５】
そして、測定結果ファイル３２１から、過去の所定の期間における特定のバイタル値を読み込み、一旦ワーク・メモリ領域等の記憶装置に格納する（ステップＳ３７）。例えば、過去１ヶ月分の血糖値データを読み込む。
【００５６】
そして、読み込んだバイタル値をグラフの表示画面にプロットする（ステップＳ３９）。さらに、当該バイタル値の正常範囲をグラフの表示画面にプロットする（ステップＳ４１）。
【００５７】
そして、これまでの処理により、全てのバイタル値についてのグラフ表示処理が行われたかどうか判定する（ステップＳ４３）。全てのバイタル値についてのグラフ表示処理が終了していないと判定された場合（ステップＳ４３：Ｎｏルート）、ステップＳ３７の処理に戻り、次のバイタル値を特定して読み込む。なお、グラフ表示するバイタル値をユーザが選択できるようにしてもよい。例えば血糖値及び中性脂肪値についてのみ表示する等の設定を行うことができるような構成を採用してもよい。
【００５８】
一方、全てのバイタル値についてのグラフ表示が行われたと判定された場合（ステップＳ４３：Ｙｅｓルート）、元の処理（図２）に戻る。このようにして解析処理が行われる。
【００５９】
図５に、グラフ表示画面の一例を示す。図５の例には、操作メニュー・バー５００とグラフ表示部５１０と終了ボタン５２０とが含まれている。操作メニュー・バー５００は図４に示した操作メニュー・バー４００と同様の構成であり、終了ボタン５２０は図４に示した終了ボタン４２０と同様のボタンである。
【００６０】
グラフ表示部５１０には、バイタル値ａの折れ線グラフ５１２とバイタル値ａの正常値の範囲５１４とバイタル値ｂの折れ線グラフ５１６とバイタル値ｂの正常値の範囲５１８とが示されている。図示していないが、この他にも他の種類のバイタル値についてのグラフが示されている場合もある。
【００６１】
横軸は時間を表しており、グラフの右端が最新のバイタル値である。図５の例では、バイタル値ｂの折れ線グラフ５１６が、バイタル値ｂの正常値の範囲５１８からはみ出している箇所があるが、最新の測定では正常値の範囲内に戻ったことが分かる。
【００６２】
ユーザは、グラフ表示部５１０に示されている各折れ線グラフを確認し、操作メニュー・バー５００のいずれかのボタン又は終了ボタン５２０をクリックする。
【００６３】
図２の処理フローに戻り、ユーザ端末３の解析プログラム３０９は、ユーザからの指示が終了であったかどうか判定する（図２：ステップＳ１１）。図４の終了ボタン４２０又は図５の終了ボタン５２０がクリックされた場合には、ユーザからの指示は終了と判定される。
【００６４】
終了であったと判定された場合（ステップＳ１１：Ｙｅｓルート）、解析プログラム３０９は処理を終了し、表示されている画面を閉じる（ステップＳ１３）。一方、終了ではなかったと判定された場合（ステップＳ１１：Ｎｏルート）、処理は端子Ａを介して図６の処理に移行する。なお、ここでは、バイタル・データ表示及びグラフ表示は既に行っているため、終了ではない場合、診療予約又は医師への依頼のいずれかが選択指示されたものとする。
【００６５】
図６に、端子Ａを介して移行した後の処理フローを示す。まず、ユーザ端末３の解析プログラム３０９は、ユーザからの指示が診療予約であったかどうか判定する（図６：ステップＳ５１）。図４の「診療予約」ボタン４０８又は図５の操作メニュー・バー５００の「診療予約」ボタンがクリックされた場合には、ユーザからの指示は診療予約と判定され、図４の「医師への依頼」ボタン４０６又は図５の操作メニュー・バー５００の「医師への依頼」ボタンがクリックされた場合には、ユーザからの指示は診療予約ではなかったと判定される。
【００６６】
診療予約であったと判定された場合（ステップＳ５１：Ｙｅｓルート）、処理は端子Ｂを介して図９の処理に移行する。一方、診療予約ではなかったと判定された場合（ステップＳ５１：Ｎｏルート）、ユーザ端末３の解析プログラム３０９は、医師への依頼画面を表示装置３１３に表示し、ユーザからの選択入力を受け付ける（ステップＳ５３）。
【００６７】
図７に、医師への依頼画面の一例を示す。図７の例には、操作メニュー・バー７００と「詳細な解析を希望する」ボタン７１０と「医師のアドバイスを希望する」ボタン７２０と「詳細な解析と医師のアドバイスを希望する」ボタン７３０とが含まれている。操作メニュー・バー７００は図４に示した操作メニュー・バー４００と同様の構成となっている。そして、ユーザは「詳細な解析を希望する」ボタン７１０と「医師のアドバイスを希望する」ボタン７２０と「詳細な解析と医師のアドバイスを希望する」ボタン７３０とのうち、いずれかのボタンをクリックすることにより、医師への依頼を入力する。
【００６８】
図６の処理フローに戻り、医師への依頼画面（図７）においてユーザからの医師への依頼を受け付けると、ユーザ端末３の解析プログラム３０９は、測定結果ファイル３２１に格納されているバイタル・データを管理サーバ５に対して送信する（図６：ステップＳ５５）。本実施の形態においては、最新のバイタル・データを送信するようにしているが、過去の所定の期間におけるバイタル・データを送信するようにしてもよい。なおこの際、ユーザＩＤ等、ユーザを特定するためのデータ及び医師への依頼内容（クリックされたボタン）のデータも併せて送信する。
【００６９】
管理サーバ５の医療機関仲介処理部５０５は、ユーザのバイタル・データをユーザ端末３から受信し、バイタル・データ・ファイル５０９に格納する（ステップＳ５７）。その際、併せて受信したデータをワーク・メモリ領域等の記憶装置に格納する。そして、医療機関仲介処理部５０５は、ユーザからの依頼に対応する医師を選定する医師選定処理を行う（ステップＳ５９）。
【００７０】
ここで、図８に、医師選定処理の詳細についての処理フローを示す。なお、上で述べたとおり、医師選定処理は管理サーバ５の医療機関仲介処理部５０５によって行われる。
【００７１】
まず、ユーザ端末３から受信したユーザのバイタル・データが全て正常値であるか判定する（ステップＳ９１）。受信したユーザのバイタル・データに基づき、全種類のバイタル値が当該ユーザについての正常値の範囲内にあれば、正常値であると判定する。なお、正常値の範囲については、例えばユーザ・データ・ファイル５０７に格納されているユーザのデータや、バイタル・データに加えて送信されてきたユーザのデータを用いてこの時点で算出してもよいし、ユーザ端末３がバイタル・データの送信に併せて正常値の範囲のデータを送信するようにしてもよい。
【００７２】
正常値ではないものがあると判定された場合（ステップＳ９１：Ｎｏルート）、正常値ではないバイタル・データの種類に基づき、診療科を特定する（ステップＳ９３）。該当するバイタル・データの種類が複数あった場合には、例えば、正常値の範囲から逸脱している度合いに基づき診療科を特定する。そして後に述べるステップＳ９７の処理に移行する。
【００７３】
一方、全て正常値であると判定された場合（ステップＳ９１：Ｙｅｓルート）、例えば内科等、総合的な診療科を特定する（ステップＳ９５）。本実施の形態においては、このようにして診療科を特定しているが、他の方法で診療科を特定してもよい。
【００７４】
そして、特定された診療科に属する医師のデータを、医師・医療機関データ・ファイル５１１から抽出する（ステップＳ９７）。そして、抽出された医師のデータから、各々の医師の経験値を特定する（ステップＳ９９）。また同様に、各々の医師の詳細分析・アドバイスの回数を特定する（ステップＳ１０１）。
【００７５】
そして、詳細分析・アドバイス回数が最も少ない医師のうち、経験値が最も高い医師を特定し、当該医師のデータをワーク・メモリ領域等の記憶装置に格納する（ステップＳ１０３）。なお、例えば単純にラウンド・ロビン方式で特定していく等、他の方法で医師を選出してもよい。
【００７６】
そして、特定された医師の詳細分析・アドバイス回数を１増やす（ステップＳ１０５）。すなわち、医師・医療機関データ・ファイル５１１の該当箇所を更新する。なお、この更新処理は、後に続く処理において医師が依頼に応答したことを検知したタイミングで行うようにしてもよい。
【００７７】
このようにして、医師選定処理が行われる。そして元の処理（図６）に戻る。
【００７８】
図６の処理フローに戻り、管理サーバ５の医療機関仲介処理部５０５は、詳細な解析・アドバイスの依頼通知のデータを生成し、図８に示した医師選定処理によって特定された医師宛てに送信する（図６：ステップＳ６１）。例えばメールで送信する。図示しないが、この依頼通知には、ユーザが詳細な解析を希望しているのか又はアドバイスを希望しているのか或いはその両方を希望しているのかを示すデータと、応答用のＷｅｂページのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）とが含まれている。
【００７９】
例えば医療機関端末７は、医師の操作に従って、図示しないメール・サーバを介して管理サーバ５からの依頼通知のメール・データを受信し、表示装置に表示する（ステップＳ６３）。
【００８０】
そして、医療機関端末７は、ＵＲＬの指定等の医師の操作に従って、応答用ページ・データの要求を管理サーバ５に対して送信する（ステップＳ６５）。管理サーバ５の医療機関仲介処理部５０５は、応答用ページ・データの要求を医療機関端末７から受信する（ステップＳ６７）。そして、医療機関仲介処理部５０５は、応答用ページ・データを生成し、医療機関端末７に対して送信する（ステップＳ６９）。
【００８１】
医療機関端末７は、応答用ページ・データを管理サーバ５から受信し、表示装置に表示する（ステップＳ７１）。図示しないが、応答用ページ・データには、依頼を行ったユーザのデータ及び当該ユーザのバイタル・データが含まれている。医療機関端末７は、例えば医師の操作に従って、ユーザのデータをユーザ・データ・ファイル７１に格納し、当該ユーザのバイタル・データをバイタル・データ・ファイル７３に格納する。
【００８２】
そして、医療機関端末７は、応答用ページに対する医師からの詳細解析結果やアドバイスの入力を受け付け、応答内容データとして管理サーバ５に対して送信する（ステップＳ７３）。併せて、詳細結果・アドバイス・ファイル７５に応答内容データを格納しておく。
【００８３】
管理サーバ５の医療機関仲介処理部５０５は、応答内容データを医療機関端末７から受信し、詳細結果・アドバイス・ファイル５１５に格納する（ステップＳ７５）。なお、応答用ページに関する通信には、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔＬａｙｅｒ）の利用等、セキュリティを考慮した通信方法が用いられる。
【００８４】
そして、管理サーバ５の医療機関仲介処理部５０５は、ユーザ端末３からの要求に応じて、応答内容データをユーザ端末３に対して送信する（ステップＳ７７）。ユーザ端末３の解析プログラム３０９は応答内容データを管理サーバ５から受信し、表示装置３１３に表示する（ステップＳ７９）。
【００８５】
なお、ステップＳ７７及びステップＳ７９ではステップを簡略化しているが、実際には、管理サーバ５の医療機関仲介処理部５０５は、依頼通知メールを医師宛てに送信したのと同様に、医師からの応答があったことを通知するメールをユーザ宛てに送信する。そして、ユーザ端末３の解析プログラム３０９は、ＵＲＬの指定等のユーザの操作に従って、応答内容データを含むＷｅｂページにアクセスし、応答内容データを受信する。
【００８６】
このようにして、バイタル・データの詳細な解析及びアドバイスの医師への依頼処理と、医師からの応答内容の受信処理とが行われる。
【００８７】
図９に、端子Ｂを介して移行した後の処理フローを示す。以下、説明する処理は、診療予約が選択指示された場合における処理である。まず、ユーザ端末３の解析プログラム３０９は、診療条件入力ページを表示装置３１３に表示し、ユーザからの診療条件の選択入力を受け付ける（ステップＳ１１１）。図示しないが、診療条件入力ページでは、診療日時や診療科等、ユーザの希望条件を選択入力することができるようになっている。医療機関を指定できるようにしている場合もある。
【００８８】
そして、ユーザ端末３の解析プログラム３０９は、ユーザから選択入力された診療条件データを管理サーバ５に対して送信する（ステップＳ１１３）。なおこの際、ユーザＩＤ等、ユーザを特定するためのデータも併せて送信する。管理サーバ５の予約処理部５０３は、診療条件データをユーザ端末３から受信し、一旦ワーク・メモリ領域等の記憶装置に格納する（ステップＳ１１５）。
【００８９】
そして、管理サーバ５の予約処理部５０３は、医療機関の指定があったか判定する（ステップＳ１１７）。医療機関の指定があったと判定された場合（ステップＳ１１７：Ｙｅｓルート）、後に述べるステップＳ１２９の処理に移行する。一方、医療機関の指定がなかったと判定された場合（ステップＳ１１７：Ｎｏルート）、管理サーバ５の予約処理部５０３は、医療機関抽出処理を行う（ステップＳ１１９）。
【００９０】
ここで、図１０に、医療機関抽出処理の詳細についての処理フローを示す。まず、管理サーバ５の予約処理部５０３は、医師・医療機関データ・ファイル５１１に格納されているデータを用いて、ユーザの希望する診療科を有する医療機関を抽出する（ステップＳ１４１）。そして、予約処理部５０３は、抽出された１又は複数の医療機関のサーバに対して診療条件データを送信する（ステップＳ１４３）。例えば医療機関１００の医療機関サーバ９に対して送信する。
【００９１】
医療機関サーバ９は、診療条件データを受信し、一旦ワーク・メモリ領域等の記憶装置に格納する（ステップＳ１４５）。そして、医療機関サーバ９は、スケジュールＤＢ９０に格納されている診療スケジュールのデータを参照する（ステップＳ１４７）。そして、医療機関サーバ９は、受信した診療条件データと、診療スケジュールのデータとに基づき、予約の可否データ及び予約可能時間データを管理サーバ５に対して送信する（ステップＳ１４９）。本実施の形態においては、希望診療時間と予約可能時間とが完全に一致しなくても、前後の例えば２時間は予約可能とするようにしているため、予約が可能な場合には、予約可能時間データを併せて送信する。なお、ステップＳ１４５乃至ステップＳ１４９の処理を医療機関端末７が行うようにしてもよい。例えばステップＳ１４７の処理を、医療機関端末７が医療機関サーバ９にアクセスして行う。
【００９２】
管理サーバ５の予約処理部５０３は、予約の可否データ及び予約可能時間データを医療機関サーバ９から受信し、一旦ワーク・メモリ領域等の記憶装置に格納する（ステップＳ１５１）。そして、予約処理部５０３は、予約可能であると応答のあった医療機関を特定する（ステップＳ１５３）。
【００９３】
さらに、予約処理部５０３は、特定された医療機関に対し、診療を希望するユーザの住所に近い順にポイント付けを行う（ステップＳ１５５）。また同様に、希望診療日時と予約可能時間との差が少ない順にポイント付けを行う（ステップＳ１５７）。そして、予約処理部５０３は、ステップＳ１５５及びステップＳ１５７において付されたポイントの合計値を各医療機関に対応付けてワーク・メモリ領域等の記憶装置に格納しておく（ステップＳ１５９）。このようにして医療機関抽出処理が行われ、元の処理（図９）に戻る。
【００９４】
図９の処理フローに戻り、管理サーバ５の予約処理部５０３は、図１０に示した医療機関抽出処理によって生成された医療機関及び医療機関に対応付けられたポイントのデータを用いて、医療機関選択ページのデータを生成し、ユーザ端末３に対して送信する（図９：ステップＳ１２１）。例えばポイントの多い順に医療機関を並べたリストを含むページ・データを生成する。ユーザ端末３の解析プログラム３０９は、医療機関選択ページのデータを管理サーバ５から受信し、表示装置３１３に表示する（ステップＳ１２３）。
【００９５】
図１１に、医療機関選択ページの一例を示す。図１１の例には、操作メニュー・バー１１００と「予約する」ボタン１１１０とラジオボタンを含む医療機関リスト表示部１１２０と予約確認ボタン１１３０とが含まれている。操作メニュー・バー１１００は図４に示した操作メニュー・バー４００と同様の構成となっている。
【００９６】
そして、ユーザは、医療機関リスト表示部１１２０に示されている医療機関から、対応するラジオボタンをアクティブにすることによって診療を予約したい医療機関を選択する。さらに「予約する」ボタン１１１０をクリックすることにより、選択した医療機関に対しての診療予約指示を入力する。なお、担当する医師を選択できるようにしてもよい。
【００９７】
また、ユーザが自己の診療予約状況を確認したい時には、予約確認ボタン１１３０をクリックすることにより、予約確認指示を入力する。なお、一般的には、予約処理を行った後、予約の確認処理を行うため、以下の処理フローの説明においては、そのような順番でステップを説明していく。
【００９８】
図９の処理フローに戻り、ユーザ端末３の解析プログラム３０９は、医療機関選択ページに対するユーザからの選択入力を受け付け、選択入力データを管理サーバ５に送信する（図９：ステップＳ１２５）。なお、ここでのユーザの選択入力は、ラジオボタンでの医療機関の選択及び「予約する」ボタン１１１０（図１１）のクリックであるものとする。
【００９９】
管理サーバ５の予約処理部５０３は、選択入力データをユーザ端末３から受信し、一旦ワーク・メモリ領域等の記憶装置に格納する（ステップＳ１２７）。そして、予約処理部５０３は、受信した選択入力データ及びユーザのデータに基づき診療予約データを生成し、選択された医療機関のサーバに対して診療予約データを送信する（ステップＳ１２９）。例えば医療機関１００の医療機関サーバ９に対して送信する。
【０１００】
医療機関サーバ９は、診療予約データを受信し、スケジュールＤＢ９０に登録する（ステップＳ１３１）。具体的には、受信した診療予約データと、スケジュールＤＢ９０に格納されている診療スケジュールのデータとを照合し、予約登録することが可能であれば、受信した診療予約データに基づき診療スケジュールのデータを更新する。
【０１０１】
その際、担当する医師が決まっていれば、担当する医師が利用している例えば医療機関端末７の予約データ・ファイル７７にも診療予約データを登録する。そして、医療機関サーバ９は、予約登録確認通知を生成し、管理サーバ５に対して送信する（ステップＳ１３３）。図示しないが、予約登録確認通知には、診療予約のデータと予約処理が完了したことを示すデータとが含まれている。ここでの診療予約のデータには、受付番号等の識別データのみが含まれているようであってもよい。
【０１０２】
なお、ステップＳ１３１及びステップＳ１３３の処理を医療機関端末７が行うようにしてもよい。例えばステップＳ１３１の処理を、医療機関端末７が医療機関サーバ９にアクセスして行う。
【０１０３】
管理サーバ５の予約処理部５０３は、予約登録確認通知を医療機関サーバ９から受信し、一旦ワーク・メモリ領域等の記憶装置に格納する（ステップＳ１３５）。そして、予約処理部５０３は、受信した予約登録確認通知に基づき、診療予約データを予約データ・ファイル５１３に格納する（ステップＳ１３７）。ここで、予約処理部５０３は、予約が完了したことを示すデータをユーザ端末３に送信するようにしてもよい。そして、処理は端子Ｃ及び端子Ｄを介して図１２の処理に移行する。
【０１０４】
図１２に、端子Ｃ及び端子Ｄを介して移行した後の処理フローを示す。ユーザ端末３の解析プログラム３０９は、医療機関選択ページ（図１１）においてユーザからの予約確認指示を受け付ける（図１２：ステップＳ１７１）。具体的には、予約確認ボタン１１３０（図１１）がクリックされることによって予約確認指示を受け付ける。
【０１０５】
そして、ユーザ端末３の解析プログラム３０９は、予約確認ページ・データの要求を管理サーバ５に対して送信する（ステップＳ１７３）。なおこの際、ユーザＩＤ等、ユーザを特定するためのデータも併せて送信する。管理サーバ５の予約処理部５０３は、予約確認ページ・データの要求をユーザ端末３から受信する（ステップＳ１７５）。また、予約処理部５０３は、併せて受信した、ユーザを特定するためのデータを一旦ワーク・メモリ領域等の記憶装置に格納する。
【０１０６】
そして、予約処理部５０３は、ユーザを特定するためのデータに基づき、当該ユーザの診療予約データを予約データ・ファイル５１３から抽出し、予約確認ページ・データを生成してユーザ端末３に対して送信する（ステップＳ１７７）。
【０１０７】
ユーザ端末３の解析プログラム３０９は、予約確認ページ・データを管理サーバ５から受信し、表示装置３１３に表示する（ステップＳ１７９）。図示しないが、予約確認ページには、医療機関名や予約日時等、登録済みの診療予約に関するデータが含まれている。そして、ユーザは、自己の診療予約状況を確認する。なお、診療予約のキャンセルや変更が可能なようにしてもよい。このようにして、診療予約処理が行われる。
【０１０８】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図１に示した各ファイル格納部におけるファイル構成は一例であって、同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。
【０１０９】
また、図４、図５、図７及び図１１に示した画面構成は一例であって、同様の内容を別の態様にて表現することも可能である。また、管理サーバ５や医療機関サーバ９が各々複数のサーバによって構成されていてもよい。
【０１１０】
さらに、図１に示した管理サーバ５及びユーザ端末３の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。例えば、ユーザ端末３の解析プログラム３０９がＷｅｂブラウザ機能を有している例を示したが、別個に専用のＷｅｂブラウザを使用するようにしてもよい。また、ユーザ端末３と、医療機関サーバ９又は医療機関端末７とが、管理サーバ５を仲介せずに直接データをやりとりするようにしてもよい。また、ユーザ端末３とバイタル測定器３０との通信をブルー・トゥースに準拠して行う例を示したが、ＩｒＤＡ（ＩｎｆｒａｒｅｄＤａｔａＡｓｓｏｃｉａｔｉｏｎ：赤外線データ通信規格）やその他の規格に従って通信するようにしてもよい。
【０１１１】
また、図２、図３、図６、図８、図９、図１０及び図１２に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。
【０１１２】
【発明の効果】
以上述べたように、本発明によれば、サーバ側のシステムに接続することなくユーザ側のシステムでバイタル・データの解析結果を得ることができる。また、サービスの提供を受ける医療機関の選択を可能とすることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態におけるシステム概要図である。
【図２】本発明の実施の形態における処理フロー（その１）を示す図である。
【図３】本発明の実施の形態における処理フロー（その２）を示す図である。
【図４】バイタル・データ表示画面の一例を示す図である。
【図５】グラフ表示画面の一例を示す図である。
【図６】本発明の実施の形態における処理フロー（その３）を示す図である。
【図７】医師への依頼画面の一例を示す図である。
【図８】本発明の実施の形態における処理フロー（その４）を示す図である。
【図９】本発明の実施の形態における処理フロー（その５）を示す図である。
【図１０】本発明の実施の形態における処理フロー（その６）を示す図である。
【図１１】医療機関選択ページの一例を示す図である。
【図１２】本発明の実施の形態における処理フロー（その７）を示す図である。
【符号の説明】
１ネットワーク３ユーザ端末５管理サーバ
７医療機関端末９医療機関サーバ
１１医療機関ＬＡＮ３０バイタル測定器
５０，７０，３２０ファイル格納部
７１，５０７ユーザ・データ・ファイル
７３，５０９バイタル・データ・ファイル
７５，３２４，５１５詳細結果・アドバイス・ファイル
７７，５１３予約データ・ファイル
９０スケジュールＤＢ１００医療機関
３０１測定結果記憶部３０３測定結果送信部
３０５センサ３０７測定結果受信部
３０９解析プログラム３１１通信処理部
３１３表示装置３１５入力装置３１７出力装置
３２１測定結果ファイル３２３解析結果ファイル
５０１決済処理部５０３予約処理部
５０５医療機関仲介処理部
５１１医師・医療機関データ・ファイル

Claims

バイタル・データを測定するセンサ部と、当該センサ部により測定されたバイタル・データを記憶する記憶装置と、前記記憶装置に格納されたバイタル・データを送信する送信部とを含むバイタル・データ測定装置と、
前記バイタル・データ測定装置から送信されたバイタル・データを受信する受信部と、当該受信部により受信されたバイタル・データを記憶する記憶部と、当該記憶部に記憶されたバイタル・データを解析し、解析結果を前記記憶部に記憶する解析プログラムと、当該解析プログラムの解析結果を表示する表示部とを含むユーザ端末と、
を有する家庭用健康管理システム。
前記解析プログラムが、
前記記憶部に記憶されている前記ユーザのバイタル・データの正常範囲に関するデータを用いて、前記受信部により受信され且つ前記記憶部に記憶されたバイタル・データが正常範囲にあるか判定する機能を含むことを特徴とする
請求項１記載の家庭用健康管理システム。
前記センサ部は、１回の測定操作により少なくとも血糖値、中性脂肪値及びコレステロール値を測定可能であることを特徴とする
請求項１又は２記載の家庭用健康管理システム。
前記ユーザ端末とネットワークを介して接続される管理システムをさらに有し、
前記ユーザ端末が、前記ネットワークに接続するための手段をさらに備え、
前記管理システムが、
バイタル・データの詳細な解析及び医師からのアドバイスの少なくともいずれかの依頼データを前記ユーザ端末から受信し且つ医療機関用システムから当該依頼への応答データを受信した場合、前記依頼への応答データを応答データ記憶部に記憶する手段と、
前記応答データ記憶部に記憶された前記依頼への応答データを前記ユーザ端末に送信する手段と、
を備えていることを特徴とする
請求項１乃至３のいずれか１つに記載の家庭用健康管理システム。
前記管理システムが、
前記ユーザ端末から診療予約についての入力データを受信した場合、診療予約データを生成し、診療予約データ記憶部に記憶する診療予約処理手段と、
前記診療予約データ記憶部に記憶された前記診療予約データを前記医療機関用システムに送信する手段と、
をさらに備えていることを特徴とする
請求項４記載の家庭用健康管理システム。
前記診療予約処理手段が、
ユーザに少なくとも医療機関の選択を促す手段と、
前記ユーザ端末から、少なくとも医療機関の選択データを受信した場合、選択された医療機関についての診療予約データを生成し、診療予約データ記憶部に記憶する手段と、
を備えていることを特徴とする
請求項５記載の家庭用健康管理システム。
前記管理システムが、
前記バイタル・データの詳細な解析及び医師からのアドバイスに対する費用をオンラインで決済するための手段
をさらに備えていることを特徴とする
請求項４乃至６のいずれか１つに記載の家庭用健康管理システム。
前記送信部と前記受信部とが、ブルー・トゥース規格に従った構成を有することを特徴とする
請求項１乃至７のいずれか１つに記載の家庭用健康管理システム。