JP2005285033A - 通院アラートシステム - Google Patents

Abstract

【課題】在宅療法患者の通院予定日に対する「通院忘れの通知機能」をより的確なものとする通院アラートシステムを提供する。
【解決手段】通信網を通して接続されるデータセンターと、医療機関側端末と、患者側端末を有し、前記データセンターには、前記患者側端末から前記医療機関側端末を介して送られる患者基本情報を登録し、前記登録された患者基本情報の該当する患者の前記医療機関に通院する予定日を登録するデータベースサーバと、前記患者の前記医療機関に通院する予定日を管理するアプリケーションサーバと、メールサーバを備え、前記アプリケーションサーバは、前記データベースサーバに登録された患者基本情報の該当する患者の通院予定日に基づき、前記メールサーバに対し、前記通院予定日より所定日数以前に前記患者の患者側端末宛に通院予定日を通知する通知メールの送信を要求し、前記メールサーバは、前記アプリケーションサーバからの通知メールの送信要求に従い、前記該当する患者の患者側端末宛に通院予定日を通知する通知メールの送信を行う。
【選択図】 図１

Description

本発明は、通院アラートシステムに関する。特に、通信手段を利用して患者の身近に接する患者側端末に通院予定日を通知する通院アラートシステムに関する。

近年、医療機器開発の進展に伴い、医療機器を使用して在宅療法（治療）を行うことが可能となっている。かかる医療機器を使用しての在宅療法が適切に行われるためには、医師による病態改善度合いの確認並びに、医学的指導を行うために適時に医療機関に通院を行うことが必要である。

在宅療法の対象となる疾病の一つとして睡眠時無呼吸症候群（ＳＡＳ：Sleep Apnea Syndrome）がある。このＳＡＳは、睡眠中に無呼吸を繰り返す病態を総称し、良質な睡眠が得ることが不可能となる。これにより、日中の活動や思考、労働の質、運転能力などが低下するとともに、高血圧や糖尿病といった成人病、更には心筋梗塞や脳卒中などの重篤な病気を高率で引き起こすことも明らかになっている。

上記ＳＡＳの一つとして、閉塞型睡眠時無呼吸症候群（ＯＳＡＳ：Obstructive Sleep Apnea Syndrome）がある、これは、胸部や腹部の呼吸運動が行われているのも関わらず上気道の閉塞のために鼻、口での呼吸が無く無呼吸となる病態である。

かかるＯＳＡＳに対する治療として、ＣＰＡＰ（Continuous Positive Airway Pressure） 療法が知られている。この療法は、1981年C.E. Sullivan（シドニー大学）らによって、導入されたものであり、この療法に用いる装置として持続陽圧呼吸療法（ＣＰＡＰ）装置（例えば、本出願人により開発のスリープメイト（登録商標）Ｓ６、医療用具製造承認番号21300BZY00092000）がある。ＣＰＡＰ装置は本体からエアチューブ、鼻マスクを介して、予め設定した圧力（陽圧）を気道に送り、気道を常に陽圧に保つことにより気道の閉塞を防ぐものである。

そして、前記気道に送られる圧力（陽圧）の設定値は、病態に応じて、医師により処方されるものである。したがって、医師により定期的に在宅療法の効果を診て、適切な処方及び医学的指導を行うことが重要である。かかる点は、上記のＳＡＳに対する場合に限られない。

上記に鑑みて、在宅療法を支援するためのシステムを、本出願人により先に提案している（特許文献１）。

かかる先に本出願人により提案された在宅療法を支援するためのシステムは、基幹病院と地域医療機関とが、より強固に連携して在宅治療を実行可能とするものである。医療支援システムが備えられるサーバ装置は、在宅医療機器の運転情報、患者のコンプライアンス情報、患者の生態情報、あるいは各医療機関における診療情報を蓄積記録し、基幹病院端末及び地域医療機関の地域医療機関端末双方から閲覧可能とする。これにより在宅治療に関わる情報の共有化と、医療従事者間の情報伝達の迅速化、容易化を図るものである。

ここで、先に言及したように、在宅療法においては、医師により定期的に在宅療法の効果を診て、適切な処方及び医学的指導を受けることが重要である。このために、在宅療法患者は処方を受けている医療機関に適時に通院することが必要である。そして、一般に通院のためには、予め通院予定日を医療機関との間で設定予約しておくことが行われる。

しかし、患者は予約した通院予定日を失念してしまうことが多くある。かかる場合、その後の在宅療法に対して効果的な処方ができないことになる。

かかる点に鑑みて、上記特許文献1では、在宅療法を支援するためのシステムにおいて「通院忘れの通知機能」を設けることを示している。すなわち、「患者が地域医療機関に通院して在宅治療のための医学的指導を受けるべき予定日を登録しておくための記憶手段と、実際に通院した日を登録する記憶手段とをサーバ装置内に備え、予定日を過ぎているにもかかわらず、患者が実際に通院していない場合には、上記２つの記憶手段の記憶内容を照合して、確実に検知し、通院予定日を過ぎてもまだなされていないことを各端末に表示する」（特許文献１、欄[０１２３]参照）ことを開示している。
特開２００３-３０８３８９号公報

しかし、上記特許文献１に記載の発明では、「通院忘れの通知機能」において、通院予定日を徒過した場合に、患者にその旨が表示されることを提示するのみである。このような態様では、通院忘れの通知を受けた際、医療機関との間で通院予定日の再設定が必要となり、患者にとってその手続きは煩わしく、結局未来院のままとなってしまう可能性が高い。そのために、在宅療法による適切な治療効果を期待することができない。

したがって、本発明の目的は、「通院忘れの通知機能」をより的確なものとする通院アラートシステムを提供することにある。

さらに、本発明の目的は、通院忘れを予防し、在宅療法患者及び、医療機関側での通院予定日の再設定の機会をより少なくし得る通院アラートシステムを提供することにある。

上記本発明の課題を達成する通院アラートシステムの第１の態様は、通信網を通して接続されるデータセンターと、医療機関側端末と、患者側端末を有し、前記データセンターには、前記医療機関側端末から送られる患者基本情報を登録し、前記登録された患者基本情報の該当する患者の前記医療機関に通院する予定日を登録するデータベースサーバと、前記患者の前記医療機関に通院する予定日を管理するアプリケーションサーバと、メールサーバを備え、前記アプリケーションサーバは、前記データベースサーバに登録された患者基本情報の該当する患者の通院予定日に基づき、前記メールサーバに対し、前記通院予定日より所定日数以前に前記患者の患者側端末宛に通院予定日を通知する通知メールの送信を要求し、前記メールサーバは、前記アプリケーションサーバからの通知メールの送信要求に従い、前記該当する患者の患者側端末宛に通院予定日を通知する通知メールの送信を行うことを特徴とする。

上記本発明の課題を達成する通院アラートシステムの第２の態様は、第１の態様において、前記アプリケーションサーバは、前記通知メールを送信した患者側端末の該当する患者について、前記データベースサーバに登録された通院予定日の更新の有無を検知し、前記通院予定日の更新がされていない場合に、前記メールサーバに対し、前記該当する患者の患者側端末宛に前記通院予定日以前の所定の期間毎に前記通知メールの再送を要求することを特徴とする。

上記本発明の課題を達成する通院アラートシステムの第３の態様は、第１または、第２の態様において、前記データベースサーバは、登録された通院予定日が前記アプリケーションサーバにより検索された患者の患者基本情報に基づく属性データを前記メールサーバに送り、前記メールサーバは、前記通院予定日を通知する通知メールに前記属性データを付加して送信することを特徴とする。

上記本発明の課題を達成する通院アラートシステムの第４の態様は、第３の態様において、前記属性データは、前記通知メールの送信先患者の疾病の改善に寄与する情報であることを特徴とする。

上記本発明の課題を達成する通院アラートシステムの第５の態様は、第１または、第２の態様において、前記医療機関側端末は、通院予定日を経過して未来院である患者を特定する未来院患者リストを有し、前記未来院患者リストから通院を促す患者を特定して、前記アプリケーションサーバを介して、前記データベースサーバに外来を促進するメール内容を登録し、前記アプリケーションサーバは、前記医療機関側端末から外来を促進するメールの送信要求に対し、前記メールサーバに外来を促進するメールの送信を指示し、前記メールサーバは、前記アプリケーションサーバからの外来を促進するメールの送信指示に対し、前記データベースから登録された外来を促進するメール内容を受け、該当する患者側端末に送信することを特徴とする。

さらに、上記本発明の課題を達成する通院アラートシステムの第６の態様は、前記在宅療法患者の使用する機器のデータを直接通信手段を通して、定期的に前記データセンターに送信され、前記医療機関側端末で、前記データセンターから前記機器のデータを取得して前記医療者側端末に表示可能とされることを特徴とする。

本発明の特徴は、以下に図面に従い説明される実施の形態例から更に明らかになる。

上記本発明の特徴により、通院予定日の通知を事前に受けることが可能であるので、患者は通院の機会を徒過することが少なくなり、従って、再度の通院予定日の設定の煩わしさを回避することが可能である。これにより、医療機関において定期的に在宅療法の効果を診て、適切な処方及び医学的指導を行うことがより確実となり、在宅療法の効果を高めることができる。

以下図面に従い本発明の実施の形態例を説明する。なお、実施の形態例は、本発明の理解のためのものであって、本発明の技術的範囲が、これらに限定されるものではない。

図１は、本発明を適用した通院アラートシステムの実施の形態例を示す図である。

通信網としてインターネット１を通して接続されるデータセンター２、医療機関側端末３と、患者側端末４を有している。なお、図において、インターネット１には、それぞれ１つの医療機関端末３及び患者側端末４が示されているが、これらは１つに限られない。

データセンター２は、アプリケーションサーバ２０、データベースサーバ２１、メールサーバ２２を有している。データセンター２において、これらのアプリケーションサーバ２０、データベースサーバ２１、メールサーバ２２は、ファイアウオール機能を有するルータ２３を通してインターネット１に接続される。

さらに、データベースサーバ２１の一部としてストレージ２４と必要によりバックアップ用にテープドライブ２５を有している。

データセンター２において、上記３種のサーバ２０,２１,２２（以下、個別的に説明を要しないときは、単にサーバ２０〜２２という）がサーバ管理者によりアクセス操作される。医療機関側端末３は、医療機関に置かれ、本発明に関連して該当の医師により操作される。一方、患者側端末４は、在宅療法患者宅に在宅療法患者に近接して置かれる端末であり、好ましくは、在宅療法患者が、容易に個人的にアクセス可能な携帯電話等である。

図２に実施例として、上記サーバ２０〜２２、医療機関側端末３及び患者側端末４のそれぞれの利用者と、それぞれにおける機能の名とその詳細機能の内容がテーブルとして示されている。

かかる機能を使用して本発明の通院アラートシステムが運用される。一例としてその運用におけるシーケンスフローが図３に示される。以下に図３に従い、本発明の通院アラートシステムの実施例動作を説明する。

先ず医療機関は通院アラームの運用サービスを受けるために、医療機関端末３からデータセンター２に対し、医療機関の登録を実行する（ステップＳI）。医療機関の登録の工程は、次のようである。

医療機関側端末３を通して、あるいは事前に書面の提供によりデータセンター２に対して医療機関基本情報を申請する（ステップＳ１）。これに基づいて、データセンター２のサーバ管理者により、管理者側サイトにログインして（ステップＳ２）、申請された医療機関基本情報を入力する（ステップＳ３）。

図４は、図示省略されているがデータセンター２に置かれるサーバ管理者用端末の画面例である。図５は、図４のサーバ管理者用端末の画面を用いる医療機関情報を入力する手順を説明する図である。

上記ステップＳ３において、サーバ管理者は、サーバ管理者用端末の画面（図５Ａ）において、医療機関の新規登録メニュー４０を指定すると、医療機関の新規登録画面（図５Ｂ）が開き、先に申請された医療機関基本情報である病院名、担当医師名、病院所在地、ログインＩＤ，ログインパスワード、メールアドレス等の入力が可能となる。

さらに、図５Ａにおいて更新、削除メニュー４１を指定すると、登録済み医療機関一覧表（図５Ｃ）が開く。この登録済み医療機関一覧表において、変更・削除を行う対象の担当医師名を指定すると、医療機関修正画面（図５Ｄ）が開き、修正・削除が可能となる。

新規登録、修正・削除に対する入力結果を確認すると、医療機関側での更新入力が完了する。これをアプリケーションサーバ２０が受信し（ステップＳ４）、データベースサーバ２１に送られ、ストレージ２４に登録格納される（ステップＳ５）。

一方、患者側が、通院アラームのサービスを受けるためには、データセンター２に対し、患者基本情報の登録が必要である（ステップＳII）。この患者基本情報の登録は、治療指導を受けている医療機関を通じて行なわれる。

患者は、患者側端末４により患者基本情報として必要な情報として、患者氏名、患者生年月日、患者性別、患者住所、患者の固定電話番号、患者の携帯電話番号、患者のメールアドレス、患者の合併症、患者の症状（自覚症状）などの情報を医療機関側端末３に送る（ステップＳ６）。かかる情報は、医療機関側において、医療機関が行う患者情報登録に用いられる。

さらに、医療機関では各患者に固有な患者IDを付与し、初診日の日付の情報も記録し
ておき、これらの情報もまた患者基本情報に付加して、医療機関側端末３において、医療起案用管理サイトにログインして（ステップＳ７）、患者側から提供された患者基本情報の入力が行なわれる（ステップＳ８）。

図６は、医療機関側端末３に表示される担当医師用の画面例である。図７は、この担当医師用の画面を用いて患者基本情報の入力手順を説明する図である。

ステップＳ８において、担当医師は、通院アラームサービスを受ける申請があった患者を登録するために、図６に示す担当医師用の画面における患者情報の新規登録メニュー６０を指定する（図７Ａ）。新規登録メニュー６０を指定により患者新規当力用画面が表示され（図７Ｂ）、患者基本情報として患者名、メールアドレス、属性が入力される。なお、ここで、患者基本情報における属性とは、患者の病態、例えば、高血圧である等の情報である。この様な患者基本情報が入力されると、データセンター２に送られる。

ここで、医療機関側端末３により、患者基本情報をデータセンター２に送るに際し、事前に、患者側から通院アラームサービス受ける申請を受け付けておく必要がある。このための方法として、例えば、患者が初診診療、あるいは再診察を受けるために医療機関に外来で訪れた際に、問診表のような通常の記入書類とともに「アラートシステム利用同意書」によりサービスを受けることの同意を患者側に記入確認してもらうことが必要である。

あるいは、初診時等の問診表記入の機会に、医療機関側に患者のメールアドレスが知らされる場合、データセンター２側あるいは医療機関側から「アラートシステムの内容説明と、システム利用の可否を問うメール」を送信し、このメールに対し、患者側からサービスを受けることの確認を得る方法が可能である。

図３に戻り、データセンター２において、アプリケーションサーバ２０が患者基本情報を受信すると（ステップＳ９）、これをデータベースサーバ２１に送り、先に登録されている医療機関基本情報と関連して患者基本情報が登録される（ステップＳ１０）。

図８は、上記処理により先の処理でデータベースサーバ２１によりストレージ２４に格納されている医療機関基本情報（図８Ａ）と患者基本情報（図８Ｂ）の登録例である。

図８Ａにおいて、医療機関基本情報は、医療機関管理テーブルに医療機関ごと、更に同一の医療機関のうち、担当医師名別に登録されている。図８Ｂの患者管理テーブルは、図８Ａの担当医師ごとに担当する患者名が登録されたリストであり、医療機関管理テーブルと、リレーショナルに連結されている。

したがって、図８Ａの医療機関管理テーブルにおいて、一の医師が指定されると、該当の医師が担当している、図８Ｂの患者名リストが抽出される。

図３に戻り説明する。上記の処理により、医療機関基本情報と患者基本情報がデータベース２１に登録されると、ついで、通院予定日が登録される（ステップＳIII）。

医療機関側端末３により、医療機関に対し予約している患者の次回通院予定日が入力され（ステップＳ１１）、データセンター２に送られる。

アプリケーションサーバ２０がこれを受信し（ステップＳ１２）、データベースサーバ２１に転送される。データベースサーバ２１により、アプリケーションサーバ２０を通して送られた次回通院予定日が、先に登録されている患者基本情報（図８Ｂ）の通院予定日欄に登録される（ステップＳ１３）。

上記の処理により登録された情報に基づき本発明の特徴とする通信予定日の予告通知（アラーム）処理が行われる（ステップＳIV）。

データセンター２において、アプリケーションサーバ２０が、通院予定日を監視する（ステップＳ１４）。アプリケーションサーバ２０は、図８Ｂの患者管理テーブルを参照して、実日を基準に所定日以降に通院予定日となる患者名を抽出し、メールサーバ２２に対しメール配信を指示する（ステップＳ１５）。

アプリケーションサーバ２０は、同時にデータベースサーバ２１に抽出したメール対象の患者名を通知する。データベースサーバ２１は、アプリケーションサーバ２０から通知されたメール対象の患者名を基に、患者管理テーブル（図８Ｂ）から該当患者の属性を検索する。検索した属性情報から更に、該当する患者向けのメールニュースを検索する。

図９は、メールサーバ２２から送信されるメール本文を説明する図である。図９Ａは、患者向けの医療機関メールニューステーブルである。この医療機関メールニューステーブルは、先に（ステップＳI）において、医療機関の登録が行われる際に、医療機関が患者へのメールに添付して送りたい情報をデータベースサーバ２１に登録しておくことが可能である。図９Ａにおいて、医療機関メールニュースは、送信先対象とする属性と、配信開始日及びニュースの内容（タイトル及び本文）がテーブル化されている。

図９Ｂは、データセンター２で作成された、患者へのメールに添付して送りたい情報であり、同様にメールの送信先対象属性と、配信開始日及びニュースの内容（タイトル及び本文）がテーブル化されている。

したがって、データベースサーバ２１は、アプリケーションサーバ２０から通知されたメール対象の患者名から通院予定日を患者管理テーブルから検索し、図９Ａ、図９Ｂのテーブルから配信開始日以降で、且つ対象属性が一致しているニュースを抽出してメールサーバに提供する（ステップＳ１６）。図において、例えば、対象属性がallは、全ての属性が対象であり、従って、全ての患者側端末４に共通に送られるメッセージである。

図９Ｃは、データセンター２から医療機関向けに送られる通知メールの例であり、随時システム運用に必要な場合、医療機関側に送られるメール本文である。

メールサーバ２２は、アプリケーションサーバ２０からのメール配信指示と、データベースサーバ２１からのメールニュースデータを受け（ステップＳ１７）、通信予告メールを送信する（ステップＳ１８）。

したがって、該当の患者は、このメールを患者側端末４により通院予定を通知される（ステップＳ２１）。

ここで、通院予定日までに次回通院予定日が更新されていない場合、未だ通院していないことを意味する。したがって、変形例として必要によりアプリケーションサーバ２０による通院予定日の監視（ステップＳ１４）において、次回通院予定日の更新を検知しない場合、通院予定日以前に、メール送信指示から所定期間経過毎に再度のメール送信指示（ステップＳ１５）を繰り返し、上記したと同様にメールサーバ２２によりメール送信（ステップＳ１８）を行うようにすることも可能である。

このときの通知は、通院予定日以前に行なわれるので、在宅療法患者は改めて通院予定日を確認することになり、通院予定日を忘れ、未来院となる機会を減らすことが可能である。

さらに、アプリケーションサーバ２０は、通院予定日を認識し、当日に通院予定日であることを通知するメールを送信指示してメールサーバ２２により通院予告メールの送信が行なわれる（ステップＳ１９）。これにより通院予定日に通院を見過ごすことを回避できる可能性が高くなる。

図１０は、患者側端末４のメール受信画面の例である。患者側端末４の表示エリア４０に、図示されるように通院予定日を担当医が知らせるメッセージが表示される。この内容は、図９Ａの患者向け医療機関メールニューステーブルに用意された内容に対応する。さらに、患者側端末４の表示エリアの大きさにより異なるが、表示画面をスクロールすることにより、当該患者の属性に対応する予めデータベースサーバ２１に登録されているメッセージ（図９Ａ参照）が表示される。

このようにして、通院予告メールが患者側端末４に送られ、当該患者が在宅療法の指導を受けている医療機関に外来通院すると、次回の通院予定日が患者と担当医との間で決められる（ステップＳ２２）。したがって、ステップＳ７に戻り、医療機関側端末３により医療機関用管理サイトにログインして、新たな次回通院予定日が入力され上記した処理が繰り返されることになる。

上記により通院予定日に至るまで通院予定日を通知するアラームを複数回送信したにもかかわらず、事情により通院が行なわれない場合がある。かかる場合、そのまま放置するときは、在宅療法の効果を損なうことになる。

したがって、本発明では、更に通院を促すメッセージの送信が行なわれる。

図１１は、図３に続く処理フローであり、通院予定日以降も未来院である場合の処理を説明する図である。この未来院の状態は、医療機関側端末３で検知される（ステップＳ２３）。

かかる場合、医療機関側端末３は、外来促進メールを登録する（ステップＳV）。この処理において、未来院者の中から促進メール配信先を選択して（ステップＳ２４）、アプリケーションサーバ２０を介して（ステップＳ２５）、データベースサーバ２１に通知する（ステップＳ２６）。これにより、データベースサーバ２１は、図８Bに示す患者管理テーブルにおいて、通知された未通院者の欄に未通院である旨のフラグを付ける。

医療機関側端末３は、更に外来を促す促進メールの登録要求を生成し（ステップＳ２７同様にアプリケーションサーバ２０を介して（ステップＳ２８）、データベース２１に登録する（ステップＳ２９）。

ついで、外来メール促進メールの送信を行なう（ステップＳVI）。この処理は、医療機関側端末３で外来促進メール送信指示を生成し（ステップＳ３０）、アプリケーションサーバ２０を介して、メールサーバ３２に外来促進メールの送信を要求することにより進められる。

メールサーバ２２は、この送信要求に基づき、データベースサーバ２１に登録してある外来促進データを受け（ステップＳ３３）、外来促進メールを送信する。これにより該当の患者側端末４で、外来促進メールを受けることができる（ステップＳ３４）。

したがって、外来促進メールを受けることにより、先の通院予定日を見過ごしてしまっているが、通院の必要性を感じ医療機関に外来の次回通院予定日の設定する（ステップＳ３５）意欲を在宅療法患者に与えることができる。

図１２は、医療機関側端末３に表示される、ＣＰＡＰ（Continuous Positive Airway Pressure） 療法使用される患者別呼吸装置の使用状況の表示である。図４に示した医療機関側端末３のメニュー画面において、患者情報管理メニューの患者検索欄６１を指定する（図１２Ａ）ことにより、検索された患者の在宅療法において使用している機器の情報が表示される（図１２Ｂ）。

この機器情報は、図1において、患者の使用機器から通信手段を用いてデータセンター２に定期的に直接送られ、蓄積されている情報である。医療機関は、これをインターネット１を通してデータセンター２から得ることができ、医療機関側端末３に表示される。

さらに、医療機関で機器情報項目を特定すると、例えば、その月間推移データが表示される（図１２Ｃ）。

したがって、医療機関側において、在宅療法患者の状態を医療機関側端末3に表示される機器情報から判断できるので、通院予定日に通院してくる患者に対し適切に在宅療法を指導することが可能となる。

ところで、最近明らかとなった鉄道運転士の睡眠障害による運行障害事故を契機として睡眠時無呼吸症候群に関する治療の重要性の啓蒙が進み、睡眠時無呼吸症候群が疑われる患者に対する確定診断を行うための睡眠時の検査の受診者が顕著に増加してきている。

このために、このような睡眠時検査を行う医療施設（スリープラボと呼ばれる）での検査待ちが数ヶ月にも及んでいる。

睡眠時検査を受ける患者は、迅速化且つ効率的にこのようなスリープラボで検査を受けるための手段として、公衆通信網であるインターネットで接続可能なサーバにアクセスすることで得られる情報をもとに、受診に最適なスリープラボの探索をしたり、更に見つけたスリープラボに対して睡眠時検査の申し込みをすることが多い。

上記の状況の下、本発明は、以下のように変形して実施することも可能である。

すなわち、スリープラボが、情報公開サーバとして当該スリープラボの名称や所在地、睡眠時検査の予約状況や検査待ち日数などの情報をワールドワイドウェブ上に公開掲示する。したがって、公衆通信網であるインターネット１に接続したパーソナルコンピュータ等の端末からこのワールドワイドウェブ上に掲示された前記のスリープラボの公開情報が閲覧可能となる。

これにより、患者は、閲覧を行った情報に基づき前記スリープラボに睡眠時検査の効率的に予約申し込みを行うことが可能である。そして、スリープラボにおいて、上記の睡眠時検査の申し込み時に患者が入力した、この患者に関する情報、例えば患者の氏名、住所、メールアドレス、合併症、既往症などの情報を、患者の同意の下に、データセンター２のデータベースサーバ２１へ転送して蓄積しておくことが考えられる。

そしてこの患者が睡眠時検査の結果、睡眠時無呼吸症候群であることが確定し、いずれかの医療施設にて通院治療を行うこととなった場合に、図３において、説明したと同様にデータベースサーバ２１へ転送された患者の情報を用いて、本発明に従い通院アラームメールが送信されたり、合併症に対して有益な情報などが、メールサーバ２２により、当該患者へ送信されたりするように構成することも可能である。

かかる構成とすることにより、患者についての情報の入力回数が削減されて医療機関側および患者側の利便性が向上するともに、治療時の患者の脱落を予防して確実な治療効果が得られる。

上記に図面に従って説明したように、本発明により在宅療法患者に対し、通院予定日以前に通院予定日をメールにより通知することができる。さらに、通院予定日を経過した後も通院を促すメールを送信することができる。したがって、患者に対し通院の必要をより強く意識させることができるので、未来院となることを回避することができ、適切な医師の指導の下に在宅療法を行いその効果を高めることが可能である。

なお、先に在宅療法として、ＣＰＡＰ（Continuous Positive Airway Pressure） 療法について触れたが、本発明の適用は在宅療法一般に適用可能であることはいうまでもない。

本発明を適用した通院アラートシステムの実施の形態例を示す図である。 サーバ２０〜２２、医療機関側端末３及び患者側端末４の機能の例を示す図である。 通院アラートシステムの運用におけるシーケンスフローを示す図である。 データセンター２に置かれるサーバ管理者用端末の画面例である。 図４のサーバ管理者用端末の画面を用いる医療機関情報を入力する手順を説明する図である。 医療機関側端末３に表示される担当医師用の画面例である。 担当医師用の画面を用いて患者基本情報の入力手順を説明する図である。 医療機関基本情報（図８Ａ）と患者基本情報（図８Ｂ）の登録例である。 メールサーバ２２から送信されるメール本文を説明する図である。 患者側端末４のメール受信画面の例である。 図３に続く処理フローであり、通院予定日以降も未来院である場合の処理を説明する図である。 医療機関側端末３に表示される患者別呼吸装置の使用状況の表示である。

符号の説明

１ インターネット
２ データセンター
３ 医療機関側端末
４ 患者側端末
２０ アプリケーションサーバ
２１ データベースサーバ
２２ メールサーバ
２３ ルータ
２４ ストレージ
２５ テープドライブ

Claims (6)

1. 通信網を通して接続されるデータセンターと、医療機関側端末と、患者側端末を有し、
   前記データセンターには、患者基本情報を登録し、前記登録された患者基本情報の該当する患者の前記医療機関に通院する予定日を登録するデータベースサーバと、前記患者の前記医療機関に通院する予定日を管理するアプリケーションサーバと、メールサーバを備え、
   前記アプリケーションサーバは、前記データベースサーバに登録された患者基本情報の該当する患者の通院予定日に基づき、前記メールサーバに対し、前記通院予定日より所定日数以前に前記患者の患者側端末宛に通院予定日を通知する通知メールの送信を要求し、
   前記メールサーバは、前記アプリケーションサーバからの通知メールの送信要求に従い、前記該当する患者の患者側端末宛に通院予定日を通知する通知メールの送信を行い、更に
   前記アプリケーションサーバは、前記通知メールを送信した患者側端末の該当する患者について、前記データベースサーバに登録された通院予定日の更新の有無を検知し、前記通院予定日の更新がされていない場合に、前記メールサーバに対し、前記該当する患者の患者側端末宛に前記通院予定日以前の所定の期間毎に前記通知メールの再送を要求することを特徴とする通院アラートシステム。
2. 請求項１において、
   前記データベースサーバは、患者の前記医療機関に通院する予定日を登録する際に、前記患者の属性を付して登録し、通院予定日が前記アプリケーションサーバにより検索された患者の前記属性データに関連する患者に対する情報を前記メールサーバに送り、
   前記メールサーバは、前記通院予定日を通知する通知メールに前記属性データに関連する患者に対する情報を付加して送信することを特徴とする通院アラートシステム。
3. 請求項２において、
   前記属性データは、前記通知メールの送信先患者の疾病を特定するデータであることを特徴とする通院アラートシステム。
4. 請求項１乃至３の何れかにおいて、
   前記医療機関側端末は、通院予定日を経過して未来院である患者を特定する未来院患者リストを有し、前記未来院患者リストから通院を促す患者を特定して、前記アプリケーションサーバを介して、前記データベースサーバに外来を促進するメール内容を登録し、
   前記アプリケーションサーバは、前記医療機関側端末から外来を促進するメールの送信要求に対し、前記メールサーバに外来を促進するメールの送信を指示し、
   前記メールサーバは、前記アプリケーションサーバからの外来を促進するメールの送信指示に対し、前記データベースから登録された外来を促進するメール内容を受け、該当する患者側端末に送信することを特徴とする通院アラートシステム。
5. 請求項1乃至４の何れかにおいて、
   さらに、前記在宅療法患者の使用する機器のデータを直接通信手段を通して、定期的に前記データセンターに送信され、前記医療機関側端末で、前記データセンターから前記機器のデータを取得して前記医療者側端末に表示可能とされることを特徴とする通院アラートシステム。
6. 請求項1乃至５の何れかにおいて、
   さらに、睡眠時無呼吸症候群が疑われる患者のための診断用検査に関する情報を前記通信網よりアクセス可能に公開し、且つ前記アクセスを行う端末より送信された患者情報の取得を行う情報公開サーバを備え、
   前記データベースサーバは前記情報公開サーバが取得した患者情報を利用して前記患者基本情報の登録を行うよう構成したことを特徴とする通院アラートシステム。

Images