患者リマインダ生成
在宅介護デバイスを有する複数の患者サイトに関する患者リマインダシステムに関する。これは、デバイス、デバイスの製造業者、および規則セットによって既定される、いくつかの条件下で患者に支払いを提供する支払人のリストに関する情報を含むデータベースを備えた患者サーバを含む。サーバは、支払い、交換、または新たな付属品に関して適格なデバイスを求めて、サイトを監視する。そのようなイベントが検出されると、メッセージが、生成され、患者に送られる。代替として、サーバは、薬剤の提供を監視して、薬剤の処方が有効期限切れになると、または更新を必要とすると、メッセージを生成する。
【発明の詳細な説明】
【発明の分野】
【０００１】
本発明は、在宅介護デバイスの代金支払いを支配する規則のデータベースを保持するシステムに関する。システムは、それらの規則を使用して、患者が、在宅介護デバイス、またはそのデバイスの付属品の代金支払いに関して適格となった際に、そのことを示す患者リマインダを生成する。また、サーバは、患者の薬剤の処方を監視し、処方が更新される必要がある、または有効期限切れになる際に、リマインダを生成するのに使用されることも可能である。
【発明の背景】
【０００２】
多くの疾患に関して、患者自身の自宅において治療を提供する、または患者の状態を観察することが有利である。そのような在宅介護デバイスの例には、睡眠時無呼吸を治療するための呼吸デバイス、血圧モニタ、血糖値モニタ、心臓モニタなどが含まれる。健康保険会社などの各支払人は、支払人が、どのように、いつ、それらの在宅介護デバイスの代金を支払うかを決定する独自の規則セットを有する。
【０００３】
さらに、多くの在宅介護デバイスは、定期的な間隔で交換または補充を必要とする付属品を有する。例えば、睡眠呼吸障害、特に睡眠時無呼吸を治療するデバイスは、定期的な間隔で交換されるべきマスクを含む。また、支払人は、それらの付属品の代金を支払うことに関する特定の規則も有する。
【０００４】
在宅介護デバイスの製造業者および販売業者が、それらの在宅介護デバイスがどこで展開され、使用されるか、患者が、どのようにそれらの在宅介護デバイスを使用しているか、ならびに患者が、いつそれぞれの支払人からの支払いに関して適格となるかを特定することができることが有利である。また、患者も、そのようなシステムから利益を得る。
【０００５】
同様に、患者と製薬会社はともに、患者の薬剤の処方を監視して、薬剤の処方が、有効期限切れになる、または更新を必要とする際に、患者リマインダを生成するシステムから利益を得る。
【発明の概要】
【０００６】
在宅介護デバイスの展開を監視するためのシステムが、開示される。システムは、在宅介護デバイスをそれぞれが有する複数の患者サイトから情報を受け取る患者インタフェースと、その情報を受け取り、患者が、支払い、および／または新たなデバイスもしくは付属品を受け取る資格があるかどうかを判定するプロセッサとを備えた患者サーバを含む。次に、プロセッサは、患者に資格があると判明した場合、リマインダメッセージを生成する。リマインダメッセージは、患者に提示されることが可能である。すると、ユーザは、様々な既知の手段によって患者とコミュニケーションをとり、新たなデバイスまたは付属品の申し出を患者に行う。患者が承諾した場合、ユーザは、適切な宅配サービスを介する、患者からのピックアップ（該当する場合）、および新たなデバイスまたは付属品の配送を自動的にスケジュールするよう、システムに要求することができる。また、リマインダも、自動的に、すなわち、ユーザによる能動的なアクションなしに生成されてもよい。
【０００７】
患者サーバは、ユーザが、様々なレポートを獲得することができるユーザインタフェースと、それらのレポートをユーザに提示するディスプレイとをさらに備える。また、ディスプレイは、リマインダメッセージも提示して、ユーザが、そのメッセージを編集し、次いで、そのメッセージを通常の手紙、ファックス、または電子メールメッセージとして患者に送ることができるようにする。また、ユーザは、患者が、デバイスを定期契約の形で使用しているか否かについての情報を含む、患者についての情報をサーバから獲得する医療提供関係者（例えば、医者）であることも可能である。
【０００８】
在宅介護デバイスは、付属品を含むことが可能であり、プロセッサは、その付属品が、交換の対象となる際に、別のリマインダメッセージを生成することができる。
【０００９】
患者サーバは、在宅介護デバイス、およびデバイスの付属品の代金支払いに関する規則を含むデータベースを含む。
【００１０】
本発明の別の態様では、患者サイトに配置された在宅介護デバイスについての情報を含む、患者サイトからの情報を受け取る患者インタフェースと、適格性規則を含むデータベースと、前記情報を受け取り、適格性規則を使用して、その情報を分析し、前記規則に基づいてデバイスが、支払いに関して適格になると、リマインダメッセージを生成するプロセッサとを含む患者サーバが、説明される。
【００１１】
一部の場合では、在宅介護デバイスが、最初、患者によってリースされ、または賃借され、特別なモニタを使用して、デバイスが、いつ、どれだけの頻度で使用されているかが感知される。その情報が、システムに供給されて、患者が、デバイスを即座に買い、支払人から、その購入の代金の支払いを受け取るのに適格であるかどうかが判定される。
【００１２】
代替の実施形態では、処方を生成すること、前記処方に基づいて患者に薬剤を提供すること、その薬剤についての情報を患者サーバに供給すること、そのサーバを使用して、その情報を定期的に分析すること、および処方が、更新される必要がある、または有効期限切れになる際に、リマインダメッセージを患者に送ることを含む、患者に薬剤を出す方法およびシステムが、説明される。患者が、患者の処方が更新されるのを所望することを示した場合、システムは、宅配業者と自動的に連絡をとり、処方が患者に配送されるように手配する。
【発明の詳細な説明】
【００１３】
図１に示されるとおり、患者サイト１０（患者の自宅、または患者治療および／または患者観察を提供するための他の場所を表す）が、患者デバイス１２、デバイスモニタ１４、および患者インタフェース１６を含む。患者デバイス１２は、呼吸デバイス、心臓モニタ、血圧センサ、または患者の健康に関連するパラメータを測定すること、および／または患者に治療を提供することに使用される他の任意の在宅介護デバイスであることが可能である。デバイスは、定期的な間隔で交換または補充を必要とする可能性がある付属品１２Ａを含む、またはそのような付属品１２Ａに関連することが可能である。例えば、睡眠時無呼吸を治療するためのデバイスは、交換可能なマスクを含むことが可能である。
【００１４】
デバイス１２は、デバイス１２の使用を監視して、モニタ信号をデバイス監視システム１８に生成するデバイスモニタ１４に結合される。デバイス監視システム１８は、好ましくは、遠隔の場所に配置されて、様々なデバイスモニタから情報を収集するのに使用され、オプションとして、その情報を校合して、その情報を様々な形態で表示するのに使用される。情報は、デバイスモニタ１４からデバイス監視システム１８に、任意の周知の有線または無線の通信リンクによって伝送される。デバイスモニタ１４は、患者デバイス１２、およびそれぞれの患者についての様々なタイプの情報を供給することができる。本願では、重要である情報は、患者デバイス１２が使用されているかどうかである。例えば、デバイスモニタ１４は、患者デバイス１２が、過去７日間にどれだけの頻度で使用されたか、およびどれだけの時間、使用されたかについての情報を供給することができる。
【００１５】
さらに、図１に示されるとおり、患者は、患者インタフェース１６を介して患者サーバ２０と通信することができる。このサーバの目的は、様々な患者デバイス、および関連する付属品を常に把握し、以下により詳細に説明するとおり、様々な機能を実行することである。患者サーバ２０とデバイス監視システム１８は、単一のシステムに統合されることも可能であるが、本明細書では、簡明にするために別々の構成要素として示されている。
【００１６】
患者サーバ２０は、患者インタフェース１６を介して患者から直接に情報を獲得する。例えば、患者インタフェース１６は、標準のインターネット接続を介してサーバと通信するＰＣであることが可能である。代替として、患者情報は、ＨＭＥまたは医者から患者サーバによって受け取られてもよい。
【００１７】
最後に、患者サーバは、ユーザステーション２１とも通信する。このステーション２１は、ユーザのサイト、例えば、ＨＭＥオフィスまたは医者のオフィスに配置されて、以下により詳細に説明するとおり、様々なサービスに関して患者サーバ２０へのアクセスを提供する。ユーザステーション２１と患者サーバ２０の間の通信は、インターネットを介して、または他のセキュリティで保護された通信チャネルを介して行われる。
【００１８】
図２に示されるとおり、患者サーバ２０は、マイクロプロセッサ２２と、通信インタフェース２４と、複数のデータベースとを含む。患者データベース２６が、各患者サイト１０における各患者デバイス１２、およびそのデバイス１２の付属品のＩＤを含む、患者サーバ２０によるサービスを受けるクライアント群から受け取られた情報とともに、名前、自宅住所、電子メールアドレス、予後、医者の名前、デバイス１２が配送された日付を含む、患者の個人情報を含む。
【００１９】
製品データベース２８が、様々な患者のサイトにおいて見られるすべてのデバイスのリストを含む。製品製造業者データベース３０が、データベース２８によってリストアップされる製品の製造業者についての情報を含む。支払人データベース３２が、患者デバイス、およびデバイスの付属品に関連する、またはデバイス、および付属品の代金を支払う義務を有する、すべての支払人のリストを含む。最後に、規則データベース３４が、データベース３２の支払人らによって使用される諸規則を含み、どのような条件下で、いつ、各支払人が、データベース２６のデバイス群の代金を支払うかを特定する。
【００２０】
サーバ２０は、通信インタフェース２４を介して、様々な患者から情報を受信する。
【００２１】
ユーザは、ユーザインタフェース３６を介してサーバにアクセスする。
【００２２】
最初、患者が、在宅介護デバイス１２を受け取ると、患者は、サーバ２０に登録するように求められる。登録プロセス（ステップ３００）は、患者の名前、自宅住所、電子メールアドレス、患者の医師の名前、在宅介護デバイスおよび付属品の製造業者およびモデル番号、支払人（ＨＭＯ）の名前などの情報を提供することから成る。その情報は、マイクロプロセッサ２２によって患者データベース２６の中に格納される。次に、ステップ３０２で、図２に示されたデータベース群が、患者からの情報を使用して更新される。さらに、データベース群は、支払人ら、またはデバイス製造業者らから受け取られた情報を使用して、定期的に更新されもする。
【００２３】
データベース群が、セットアップされ、ポピュレートされると、様々なユーザが、データベース群にアクセスして、情報を獲得することができる。様々なクラスのユーザが、定義されることが可能であり、一部のユーザは、データ読み取り能力だけを有し、一部の患者だけに関連する情報を獲得するのに対して、他のユーザらは、すべての患者についての情報を獲得することができ、患者らに通信を送信すること、またはサーバ２０に変更を行うことを許可される。情報は、いくつかの異なるフォーマットでユーザに提示されることが可能である。情報は、データベース群の中に格納されているので、好ましくは、情報は、ＦｏｘＰｒｏのようなデータベース操作ソフトウェアプログラム群を使用して、レポートの形態で提示される。
【００２４】
図４は、図２の装置のユーザによる通常のセッションを示す。ユーザは、ステップ４００で、ログオンして、識別される。ステップ４０２で、ユーザに割り当てられた患者らのリストが、獲得され、提示される。一実施形態では、ステップ４０４で、リストアップされたすべての患者について確認が実行されて、患者らのステータスが変化しているか、すなわち、患者が、患者の医療デバイスの代金の払い戻しに関して、またはデバイス、もしくはデバイスに関連する付属品の交換に関して適格になっているのではないかどうか、判定される。例えば、多くの場合、患者は、在宅介護デバイスを受け取るが、デバイスを全く使用しないことが分かっている。したがって、少なくとも一部の支払人は、患者が、所定の期間、例えば、６ヶ月、または１年にわたって在宅介護デバイスがリースされる、または賃借される、ある種のリースまたは賃借の取り決めを結ぶことを、最初に要求する。患者が、その期間の終わりに、デバイスを購入することへの関心を表明した場合、支払人は、患者に全額の、または一部の金額の払い戻しを行うことができる。また、支払人は、患者が、装置を数回、または所定の期間にわたって使用することを要求することもできる。その情報は、デバイス監視システム１８から獲得されて、患者データベース２６の中に格納される。このプロセスは、変換と呼ばれる。
【００２５】
諸規則が確認されると、結果も、患者データベースの中に格納される。ステップ４０６で、ユーザに、いくつかのメニュー選択肢が提示される。それらのメニューの一部は、患者についての経歴情報を提供する。一部のメニューは、製品群についての情報を提供する。一部のメニューは、規定されたデバイスで、どのような付属品が利用可能についての情報を提供する。
【００２６】
ステップ４０８で、ユーザが、メニュー選択を行う。ステップ４１０で、選択されたメニューが、ステータスが変わる可能性があるアイテムを含む、または参照するかどうかを判定する確認が、実行される。例えば、患者情報は、患者デバイスが転換されることが可能であることを示すエントリを含むことが可能である。そのようなステータス変更が検出されると、ステップ４１２で、患者が、どのような支払いを受ける資格があるか、いずれのデバイスが適格であるか、支払いを得る要求が、いつ提出されるべきかなどの指示を含むレポートが、生成される。
【００２７】
同様の形で、前述したとおり、ユーザは、交換可能な要素である、またはそのような要素を含む付属品に関係するメニューを要求することができる。例えば、呼吸デバイスは、交換可能なマスクを有することが可能である。他のデバイスは、フィルタまたはバッテリが交換されることを要求する可能性がある。その場合、ステップ４１２で、その付属品に関して、同様のレポートが、生成される。一部の場合では、デバイスそのものが、交換されることが可能である。
【００２８】
選択されたメニューが、交換可能なアイテムを全く含まない場合は、ステップ４１４で、ユーザ向けに他のレポートが、生成される。それらのレポートは、患者、売上高、デバイスが販売された、または展開された特定の日付、デバイスが転換された日付などについてのステータスレポートを含む、多種多様な主題を対象に含むことが可能である。
【００２９】
ステップ４１２におけるレポートの形態、およびユーザに提供されるサービスは、行政機関の規制、サーバ２０のプログラミング、ユーザによって行われる選択などに応じて、非常に異なることが可能である。例えば、ユーザは、１名または複数名の患者が、在宅介護デバイスを転換する資格があるという単純な指示またはリマインダを得ることが可能である。指示は、患者のＩＤ、影響を受けるデバイス、支払人、および転換に関連する重要な日付から成ることが可能である。それらの重要な日付は、患者が適格であった最初の日と最後の日を含むことが可能である。
【００３０】
より高度な、または半自動化された実施形態では、単純なリマインダの代わりに、またはそのようなリマインダに加えて、電子形態の手紙が、データベース群からの情報を使用して、サーバ２０によって生成され、ポピュレートされることが可能である。次に、ユーザに、その手紙のコピーがディスプレイ３８上で提示され、ユーザが、その手紙を承認した場合、その手紙が印刷されて、患者に送られることが可能である。手紙は、患者のデバイスを、賃借ではなく、所有権に転換するのに必要とされるすべての情報を患者に提供する。代替として、手紙は、患者のステータスに変化があったこと、または変化が生じること、および患者が、さらなる情報のためにサーバと連絡をとるべきであることを患者に知らせるだけであってもよい。また、手紙は、患者にファックス送信される、または電子メール送信されることも可能である。もちろん、ユーザが患者に通信を送ることも可能である。
【００３１】
前述した実施形態では、サービスを受ける患者のステータスが変化したかどうかを確認するためのプロセスは、その患者に関連するユーザが、サーバ２０にサインオンすると、トリガされる。代替の実施形態では、プロセスは、ユーザによって行われるアクションとは完全に独立であるように、さらに自動化されることも可能である。より具体的には、図５を参照すると、ステップ５００で、サーバを動作させるプログラムが、開始される。（例えば、装置２０が、起動される。）ステップ５０２で、現在の日付が、獲得される。ステップ５０４で、すべてのデータベースが、前述した所定の諸規則を使用することによって調べられて、ステータスが変化している患者が探し出される。このステータス変化は、患者が、転換、払い戻し、交換などに関して資格があることを示す。
【００３２】
ステップ５０６で、そのような適格な患者が見出されたかどうかを判定する確認が、実行される。見出されなかった場合、通常の動作が、継続する。１つまたは複数の適格な患者が識別された場合、リマインダが生成されて、都合の良い時点で、ユーザに提示される、または郵送される。代替として、ステップ５０８で、適切なメッセージが生成され、ステップ５１０で、適格な患者のそれぞれに送られる。メッセージは、ファックスまたは電子メールなどの、任意の適切な形態をとることができる。以上のプロセスは、適格な患者らが、完全に自動的に識別されて、通知を受けるように実施されることも可能である。
【００３３】
患者は、リマインダを受け取ると、それぞれのユーザと連絡をとり、リマインダの中で言及されるアイテムを注文することができる。すると、ユーザは、患者にそのアイテムを郵送することによって、注文を満足させることができる。多くの場合、交換されるアイテムは、廃棄されず、製造業者に返却されなければならない。有利には、患者サーバ２０が、すべての要求される情報を有するので、ユーザが、患者から注文を受け取ると、ユーザは、宅配業者インタフェース３８を介して、ピックアップ要求を宅配サービスに送出するよう、患者サーバに要求することができる。要求は、患者の名前、住所、およびピックアップが行われるべきアイテムを含め、すべての必要な情報を含む。さらに、ユーザの要求で、患者サーバは、販売店インタフェース４０を介して、要求されるアイテムに対する注文を販売業者に対して生成することもできる（また、注文は、要求されるアイテムの製造業者、または地域の販売店に送られることも可能である）。さらに、ユーザは、支払人インタフェース４２を介して、取引全体の詳細を有するドキュメンテーションをそれぞれの支払人に送るよう、患者サーバ２０に要求することもできる。支払人は、支払いをユーザに送る。
【００３４】
患者サーバを使用する通常のシステムは、以下のとおり動作する。数名の患者が、ＣＰＡＰデバイス（睡眠時無呼吸の治療のために使用される）などの、あるデバイスに関して、医者から処方を受け取る。地域の在宅医療機器販売店（ＨＭＥ）および医者らはすべて、患者サーバのユーザである。
【００３５】
各患者は、ＨＭＥ、その患者のＣＰＡＰデバイス１２、マスクなどの付属品、および関連するデバイスモニタ１４を受け取る。次に、患者は、患者のデバイス、付属品、および患者の支払人をリストアップして、患者サーバ２０に登録する。そのデータは、データベース２６、２８、３０、３２に入力される。患者の支払人は、ＣＰＡＰデバイスおよびマスクの初期費用を支払う。さらに、この説明では、一部の支払人は、定期的な間隔で（例えば、毎年）マスクの交換の代金も支払う。
【００３６】
通常、いくつかのＨＭＥが、患者サーバ２０のユーザであり、各ＨＭＥは、患者サーバ２０のそれぞれのデータベースの中ですべてリストアップされる、そのＨＭＥ独自のグループの患者、デバイス、製造業者、および支払人を扱う。
【００３７】
各ＨＭＥは、患者サーバからユーザ権を得ることにより（例えば、ソフトウェアモジュールを獲得することにより）、ユーザとなる。
【００３８】
患者らが、ＣＰＡＰデバイスを使用することを始める。デバイスは、患者の活動に関する収集情報を監視し、ポケットベルシステムを介して、セルラー電話システムを介して、有線通信チャネル上でなど、監視システム１８に記録するために、その情報を送信する。
【００３９】
ＨＭＥの１つがログオンするたびに、患者サーバ２０は、そのＨＭＥの患者らのいずれかの患者のステータスが、変化しているかどうかを判定する。所定の期間の後、例えば、１年の後、数名の患者の付属品が、交換に関して適格になり、ユーザに、サーバによって適切なリマインダが生成される。ＨＭＥは、交換マスクを申し出るメッセージを患者に送信する。患者が、同意した場合、ユーザは、注文を手動で実行することができる。代替として、ユーザは、注文を実行するよう、患者サーバに要求する。すると、患者サーバは、古いマスクをピックアップするよう、宅配サービスに要求を送信する。また、患者サーバは、ＨＭＥ、販売店、または他の供給源から交換マスクをピックアップして、そのマスクを患者に運び、そのマスクを古いマスクと交換するよう、宅配サービスに要求することもできる。古いマスクは、ＨＭＥ、または他の指定された組織に戻される。また、患者サーバは、支払人によるＨＭＥへの支払いを求める要求も送信する。支払人がデバイスの使用の検証を要求することを、データベース支払人データベース１８の中に格納された諸規則が示す場合、そのような検証が、監視システム１８によって収集された情報から、患者データベース２８によって提供される。すると、支払人は、支払いをＨＭＥに送る。
【００４０】
前述したとおり、医者（または他の医療提供関係者）は、例えば、自身のソフトウェアモジュールを獲得することにより、患者サーバのユーザとして署名（契約締結）することもできる。医者は、患者サーバを使用して、医者自身の患者の数名について、他の医者の患者らについてなどの、統計データを収集することができる。また、医者は、医者の患者らの各患者について調べて、監視システム１８からのデータに基づき、処方された治療が守られていたかどうかを判定することもできる。
【００４１】
本発明を、患者の住居における在宅介護デバイスに関連して説明してきた。代替として、健康に関連する他の様々な資材を提供するために使用される。例えば、高齢者を含め、多くの患者が、薬剤の処方を受け取る。乱用を防止するため、処方は、所定の間隔で（例えば、月に１回）、更新され、所定の期間（例えば、１年）の後、有効期限切れにならなければならず、患者は、医者を訪問して、新たな処方を取得しなければならない。本発明は、以上の環境にも適用可能である。そのケースでは、サーバ２０は、患者から、または代替の源（例えば、医師）から、処方の詳細に関して情報を受け取る。また、この情報は、薬剤師によって入力されることも可能である。
【００４２】
サーバ２０は、適宜、処方のステータスを確認し、リマインダを生成することを自動的に行う。例えば、図６に示される一実施形態では、ユーザがログインすることにより、リマインダの計算がトリガされる。その実施形態では、ステップ６０２で、ユーザが、ログインし、ステップ６０４で、患者のリストが、獲得され、ステップ６０６で、確認が実行されて、それぞれの患者の処方が、所定の期間（例えば、今後７日）内に有効期限切れになるかどうかが判定される。有効期限切れにならない場合、ステップ６０８で、所定の間隔（例えば、今後３日）内に、更新を要する患者の処方が存在するかどうかを判定する確認が、実行される。以上のデータは、患者データベース２６などの、データベース群の１つのデータベースに入力される。次に、ユーザに、レポートを選択するためのメニューが提示される（ステップ６１０）。ステップ６１２で、ユーザが、メニューを選択する。ステップ６１４で、選択されたメニューが患者情報を含むかどうかの確認が、行われる。患者情報を含む場合、患者の処方が更新される必要があること、または新たな処方が必要とされていることを、適宜、示すリマインダを含め、レポートが、生成される。次に、ユーザは、その趣旨の通常の手紙、ファックス、または電子メールを患者に送ることができる。ステップ６１６で、例えば、特定の医者によってどのような薬剤が処方されたかについてのレポートを含め、他のレポート群が、生成される。
【００４３】
代替として、サーバ２０が、前述したとおり、確認を実行し、自動化されたリマインダを患者らに直接に生成することができる。
【００４４】
以上の諸実施形態のいずれかにおいて、処方の更新が要求される場合、患者は、前述したとおり、郵便、ファックス、電子メール、電話などによって通知を受けることが可能である。代替の実施形態では、患者は、処方を更新することを所望すると応答することが可能である。すると、薬剤師は、新たな処方を準備して、その処方が、患者によってピックアップされる用意をしておくことができる。代替として、患者サーバが、患者から承認を受け取ると、医薬品をピックアップして、ユーザに即時に発送するよう、宅配業者に要求を発行してもよい。
【００４５】
あまり流通していない特殊なデバイス、付属品、または医薬品には、デバイスデータベース３０によって目印が付けられることが可能である。それらは、ＨＭＥに、通常、置かれていないかもしれない品目である可能性がある。それらの特殊な品目のいずれかに関して、または在庫切れである、もしくはＨＭＥに置かれていない、いずれかの品目に関して、リマインダが生成された場合、患者サーバ２０は、その品目の必要性があることを通知する、販売店、販売業者、製造業者、または他の薬局に対する注文を生成する。すると、以上の他の組織は、その品目を獲得して、患者に発送する必要な措置を取ることを始めることができる。
【００４６】
明らかに、添付の特許請求の範囲において定義される本発明の範囲を逸脱することなく、本発明に様々な変形が行われることが可能である。
【図面の簡単な説明】
【００４７】
【図１】本発明による在宅介護デバイスの展開および使用を監視するためのインターネットベースのシステムを示す図である。
【図２】本発明による、情報を収集し、患者リマインダを提供する患者サーバを示すブロック図である。
【図３】図２のサーバに関するデータ収集に関する流れ図である。
【図４】図２のサーバの動作の流れ図である。
【図５】図２のサーバの代替の動作モードの流れ図である。
【図６】処方に関するリマインダを生成する図２のサーバに関する流れ図である。
【発明の分野】
【０００１】
本発明は、在宅介護デバイスの代金支払いを支配する規則のデータベースを保持するシステムに関する。システムは、それらの規則を使用して、患者が、在宅介護デバイス、またはそのデバイスの付属品の代金支払いに関して適格となった際に、そのことを示す患者リマインダを生成する。また、サーバは、患者の薬剤の処方を監視し、処方が更新される必要がある、または有効期限切れになる際に、リマインダを生成するのに使用されることも可能である。
【発明の背景】
【０００２】
多くの疾患に関して、患者自身の自宅において治療を提供する、または患者の状態を観察することが有利である。そのような在宅介護デバイスの例には、睡眠時無呼吸を治療するための呼吸デバイス、血圧モニタ、血糖値モニタ、心臓モニタなどが含まれる。健康保険会社などの各支払人は、支払人が、どのように、いつ、それらの在宅介護デバイスの代金を支払うかを決定する独自の規則セットを有する。
【０００３】
さらに、多くの在宅介護デバイスは、定期的な間隔で交換または補充を必要とする付属品を有する。例えば、睡眠呼吸障害、特に睡眠時無呼吸を治療するデバイスは、定期的な間隔で交換されるべきマスクを含む。また、支払人は、それらの付属品の代金を支払うことに関する特定の規則も有する。
【０００４】
在宅介護デバイスの製造業者および販売業者が、それらの在宅介護デバイスがどこで展開され、使用されるか、患者が、どのようにそれらの在宅介護デバイスを使用しているか、ならびに患者が、いつそれぞれの支払人からの支払いに関して適格となるかを特定することができることが有利である。また、患者も、そのようなシステムから利益を得る。
【０００５】
同様に、患者と製薬会社はともに、患者の薬剤の処方を監視して、薬剤の処方が、有効期限切れになる、または更新を必要とする際に、患者リマインダを生成するシステムから利益を得る。
【発明の概要】
【０００６】
在宅介護デバイスの展開を監視するためのシステムが、開示される。システムは、在宅介護デバイスをそれぞれが有する複数の患者サイトから情報を受け取る患者インタフェースと、その情報を受け取り、患者が、支払い、および／または新たなデバイスもしくは付属品を受け取る資格があるかどうかを判定するプロセッサとを備えた患者サーバを含む。次に、プロセッサは、患者に資格があると判明した場合、リマインダメッセージを生成する。リマインダメッセージは、患者に提示されることが可能である。すると、ユーザは、様々な既知の手段によって患者とコミュニケーションをとり、新たなデバイスまたは付属品の申し出を患者に行う。患者が承諾した場合、ユーザは、適切な宅配サービスを介する、患者からのピックアップ（該当する場合）、および新たなデバイスまたは付属品の配送を自動的にスケジュールするよう、システムに要求することができる。また、リマインダも、自動的に、すなわち、ユーザによる能動的なアクションなしに生成されてもよい。
【０００７】
患者サーバは、ユーザが、様々なレポートを獲得することができるユーザインタフェースと、それらのレポートをユーザに提示するディスプレイとをさらに備える。また、ディスプレイは、リマインダメッセージも提示して、ユーザが、そのメッセージを編集し、次いで、そのメッセージを通常の手紙、ファックス、または電子メールメッセージとして患者に送ることができるようにする。また、ユーザは、患者が、デバイスを定期契約の形で使用しているか否かについての情報を含む、患者についての情報をサーバから獲得する医療提供関係者（例えば、医者）であることも可能である。
【０００８】
在宅介護デバイスは、付属品を含むことが可能であり、プロセッサは、その付属品が、交換の対象となる際に、別のリマインダメッセージを生成することができる。
【０００９】
患者サーバは、在宅介護デバイス、およびデバイスの付属品の代金支払いに関する規則を含むデータベースを含む。
【００１０】
本発明の別の態様では、患者サイトに配置された在宅介護デバイスについての情報を含む、患者サイトからの情報を受け取る患者インタフェースと、適格性規則を含むデータベースと、前記情報を受け取り、適格性規則を使用して、その情報を分析し、前記規則に基づいてデバイスが、支払いに関して適格になると、リマインダメッセージを生成するプロセッサとを含む患者サーバが、説明される。
【００１１】
一部の場合では、在宅介護デバイスが、最初、患者によってリースされ、または賃借され、特別なモニタを使用して、デバイスが、いつ、どれだけの頻度で使用されているかが感知される。その情報が、システムに供給されて、患者が、デバイスを即座に買い、支払人から、その購入の代金の支払いを受け取るのに適格であるかどうかが判定される。
【００１２】
代替の実施形態では、処方を生成すること、前記処方に基づいて患者に薬剤を提供すること、その薬剤についての情報を患者サーバに供給すること、そのサーバを使用して、その情報を定期的に分析すること、および処方が、更新される必要がある、または有効期限切れになる際に、リマインダメッセージを患者に送ることを含む、患者に薬剤を出す方法およびシステムが、説明される。患者が、患者の処方が更新されるのを所望することを示した場合、システムは、宅配業者と自動的に連絡をとり、処方が患者に配送されるように手配する。
【発明の詳細な説明】
【００１３】
図１に示されるとおり、患者サイト１０（患者の自宅、または患者治療および／または患者観察を提供するための他の場所を表す）が、患者デバイス１２、デバイスモニタ１４、および患者インタフェース１６を含む。患者デバイス１２は、呼吸デバイス、心臓モニタ、血圧センサ、または患者の健康に関連するパラメータを測定すること、および／または患者に治療を提供することに使用される他の任意の在宅介護デバイスであることが可能である。デバイスは、定期的な間隔で交換または補充を必要とする可能性がある付属品１２Ａを含む、またはそのような付属品１２Ａに関連することが可能である。例えば、睡眠時無呼吸を治療するためのデバイスは、交換可能なマスクを含むことが可能である。
【００１４】
デバイス１２は、デバイス１２の使用を監視して、モニタ信号をデバイス監視システム１８に生成するデバイスモニタ１４に結合される。デバイス監視システム１８は、好ましくは、遠隔の場所に配置されて、様々なデバイスモニタから情報を収集するのに使用され、オプションとして、その情報を校合して、その情報を様々な形態で表示するのに使用される。情報は、デバイスモニタ１４からデバイス監視システム１８に、任意の周知の有線または無線の通信リンクによって伝送される。デバイスモニタ１４は、患者デバイス１２、およびそれぞれの患者についての様々なタイプの情報を供給することができる。本願では、重要である情報は、患者デバイス１２が使用されているかどうかである。例えば、デバイスモニタ１４は、患者デバイス１２が、過去７日間にどれだけの頻度で使用されたか、およびどれだけの時間、使用されたかについての情報を供給することができる。
【００１５】
さらに、図１に示されるとおり、患者は、患者インタフェース１６を介して患者サーバ２０と通信することができる。このサーバの目的は、様々な患者デバイス、および関連する付属品を常に把握し、以下により詳細に説明するとおり、様々な機能を実行することである。患者サーバ２０とデバイス監視システム１８は、単一のシステムに統合されることも可能であるが、本明細書では、簡明にするために別々の構成要素として示されている。
【００１６】
患者サーバ２０は、患者インタフェース１６を介して患者から直接に情報を獲得する。例えば、患者インタフェース１６は、標準のインターネット接続を介してサーバと通信するＰＣであることが可能である。代替として、患者情報は、ＨＭＥまたは医者から患者サーバによって受け取られてもよい。
【００１７】
最後に、患者サーバは、ユーザステーション２１とも通信する。このステーション２１は、ユーザのサイト、例えば、ＨＭＥオフィスまたは医者のオフィスに配置されて、以下により詳細に説明するとおり、様々なサービスに関して患者サーバ２０へのアクセスを提供する。ユーザステーション２１と患者サーバ２０の間の通信は、インターネットを介して、または他のセキュリティで保護された通信チャネルを介して行われる。
【００１８】
図２に示されるとおり、患者サーバ２０は、マイクロプロセッサ２２と、通信インタフェース２４と、複数のデータベースとを含む。患者データベース２６が、各患者サイト１０における各患者デバイス１２、およびそのデバイス１２の付属品のＩＤを含む、患者サーバ２０によるサービスを受けるクライアント群から受け取られた情報とともに、名前、自宅住所、電子メールアドレス、予後、医者の名前、デバイス１２が配送された日付を含む、患者の個人情報を含む。
【００１９】
製品データベース２８が、様々な患者のサイトにおいて見られるすべてのデバイスのリストを含む。製品製造業者データベース３０が、データベース２８によってリストアップされる製品の製造業者についての情報を含む。支払人データベース３２が、患者デバイス、およびデバイスの付属品に関連する、またはデバイス、および付属品の代金を支払う義務を有する、すべての支払人のリストを含む。最後に、規則データベース３４が、データベース３２の支払人らによって使用される諸規則を含み、どのような条件下で、いつ、各支払人が、データベース２６のデバイス群の代金を支払うかを特定する。
【００２０】
サーバ２０は、通信インタフェース２４を介して、様々な患者から情報を受信する。
【００２１】
ユーザは、ユーザインタフェース３６を介してサーバにアクセスする。
【００２２】
最初、患者が、在宅介護デバイス１２を受け取ると、患者は、サーバ２０に登録するように求められる。登録プロセス（ステップ３００）は、患者の名前、自宅住所、電子メールアドレス、患者の医師の名前、在宅介護デバイスおよび付属品の製造業者およびモデル番号、支払人（ＨＭＯ）の名前などの情報を提供することから成る。その情報は、マイクロプロセッサ２２によって患者データベース２６の中に格納される。次に、ステップ３０２で、図２に示されたデータベース群が、患者からの情報を使用して更新される。さらに、データベース群は、支払人ら、またはデバイス製造業者らから受け取られた情報を使用して、定期的に更新されもする。
【００２３】
データベース群が、セットアップされ、ポピュレートされると、様々なユーザが、データベース群にアクセスして、情報を獲得することができる。様々なクラスのユーザが、定義されることが可能であり、一部のユーザは、データ読み取り能力だけを有し、一部の患者だけに関連する情報を獲得するのに対して、他のユーザらは、すべての患者についての情報を獲得することができ、患者らに通信を送信すること、またはサーバ２０に変更を行うことを許可される。情報は、いくつかの異なるフォーマットでユーザに提示されることが可能である。情報は、データベース群の中に格納されているので、好ましくは、情報は、ＦｏｘＰｒｏのようなデータベース操作ソフトウェアプログラム群を使用して、レポートの形態で提示される。
【００２４】
図４は、図２の装置のユーザによる通常のセッションを示す。ユーザは、ステップ４００で、ログオンして、識別される。ステップ４０２で、ユーザに割り当てられた患者らのリストが、獲得され、提示される。一実施形態では、ステップ４０４で、リストアップされたすべての患者について確認が実行されて、患者らのステータスが変化しているか、すなわち、患者が、患者の医療デバイスの代金の払い戻しに関して、またはデバイス、もしくはデバイスに関連する付属品の交換に関して適格になっているのではないかどうか、判定される。例えば、多くの場合、患者は、在宅介護デバイスを受け取るが、デバイスを全く使用しないことが分かっている。したがって、少なくとも一部の支払人は、患者が、所定の期間、例えば、６ヶ月、または１年にわたって在宅介護デバイスがリースされる、または賃借される、ある種のリースまたは賃借の取り決めを結ぶことを、最初に要求する。患者が、その期間の終わりに、デバイスを購入することへの関心を表明した場合、支払人は、患者に全額の、または一部の金額の払い戻しを行うことができる。また、支払人は、患者が、装置を数回、または所定の期間にわたって使用することを要求することもできる。その情報は、デバイス監視システム１８から獲得されて、患者データベース２６の中に格納される。このプロセスは、変換と呼ばれる。
【００２５】
諸規則が確認されると、結果も、患者データベースの中に格納される。ステップ４０６で、ユーザに、いくつかのメニュー選択肢が提示される。それらのメニューの一部は、患者についての経歴情報を提供する。一部のメニューは、製品群についての情報を提供する。一部のメニューは、規定されたデバイスで、どのような付属品が利用可能についての情報を提供する。
【００２６】
ステップ４０８で、ユーザが、メニュー選択を行う。ステップ４１０で、選択されたメニューが、ステータスが変わる可能性があるアイテムを含む、または参照するかどうかを判定する確認が、実行される。例えば、患者情報は、患者デバイスが転換されることが可能であることを示すエントリを含むことが可能である。そのようなステータス変更が検出されると、ステップ４１２で、患者が、どのような支払いを受ける資格があるか、いずれのデバイスが適格であるか、支払いを得る要求が、いつ提出されるべきかなどの指示を含むレポートが、生成される。
【００２７】
同様の形で、前述したとおり、ユーザは、交換可能な要素である、またはそのような要素を含む付属品に関係するメニューを要求することができる。例えば、呼吸デバイスは、交換可能なマスクを有することが可能である。他のデバイスは、フィルタまたはバッテリが交換されることを要求する可能性がある。その場合、ステップ４１２で、その付属品に関して、同様のレポートが、生成される。一部の場合では、デバイスそのものが、交換されることが可能である。
【００２８】
選択されたメニューが、交換可能なアイテムを全く含まない場合は、ステップ４１４で、ユーザ向けに他のレポートが、生成される。それらのレポートは、患者、売上高、デバイスが販売された、または展開された特定の日付、デバイスが転換された日付などについてのステータスレポートを含む、多種多様な主題を対象に含むことが可能である。
【００２９】
ステップ４１２におけるレポートの形態、およびユーザに提供されるサービスは、行政機関の規制、サーバ２０のプログラミング、ユーザによって行われる選択などに応じて、非常に異なることが可能である。例えば、ユーザは、１名または複数名の患者が、在宅介護デバイスを転換する資格があるという単純な指示またはリマインダを得ることが可能である。指示は、患者のＩＤ、影響を受けるデバイス、支払人、および転換に関連する重要な日付から成ることが可能である。それらの重要な日付は、患者が適格であった最初の日と最後の日を含むことが可能である。
【００３０】
より高度な、または半自動化された実施形態では、単純なリマインダの代わりに、またはそのようなリマインダに加えて、電子形態の手紙が、データベース群からの情報を使用して、サーバ２０によって生成され、ポピュレートされることが可能である。次に、ユーザに、その手紙のコピーがディスプレイ３８上で提示され、ユーザが、その手紙を承認した場合、その手紙が印刷されて、患者に送られることが可能である。手紙は、患者のデバイスを、賃借ではなく、所有権に転換するのに必要とされるすべての情報を患者に提供する。代替として、手紙は、患者のステータスに変化があったこと、または変化が生じること、および患者が、さらなる情報のためにサーバと連絡をとるべきであることを患者に知らせるだけであってもよい。また、手紙は、患者にファックス送信される、または電子メール送信されることも可能である。もちろん、ユーザが患者に通信を送ることも可能である。
【００３１】
前述した実施形態では、サービスを受ける患者のステータスが変化したかどうかを確認するためのプロセスは、その患者に関連するユーザが、サーバ２０にサインオンすると、トリガされる。代替の実施形態では、プロセスは、ユーザによって行われるアクションとは完全に独立であるように、さらに自動化されることも可能である。より具体的には、図５を参照すると、ステップ５００で、サーバを動作させるプログラムが、開始される。（例えば、装置２０が、起動される。）ステップ５０２で、現在の日付が、獲得される。ステップ５０４で、すべてのデータベースが、前述した所定の諸規則を使用することによって調べられて、ステータスが変化している患者が探し出される。このステータス変化は、患者が、転換、払い戻し、交換などに関して資格があることを示す。
【００３２】
ステップ５０６で、そのような適格な患者が見出されたかどうかを判定する確認が、実行される。見出されなかった場合、通常の動作が、継続する。１つまたは複数の適格な患者が識別された場合、リマインダが生成されて、都合の良い時点で、ユーザに提示される、または郵送される。代替として、ステップ５０８で、適切なメッセージが生成され、ステップ５１０で、適格な患者のそれぞれに送られる。メッセージは、ファックスまたは電子メールなどの、任意の適切な形態をとることができる。以上のプロセスは、適格な患者らが、完全に自動的に識別されて、通知を受けるように実施されることも可能である。
【００３３】
患者は、リマインダを受け取ると、それぞれのユーザと連絡をとり、リマインダの中で言及されるアイテムを注文することができる。すると、ユーザは、患者にそのアイテムを郵送することによって、注文を満足させることができる。多くの場合、交換されるアイテムは、廃棄されず、製造業者に返却されなければならない。有利には、患者サーバ２０が、すべての要求される情報を有するので、ユーザが、患者から注文を受け取ると、ユーザは、宅配業者インタフェース３８を介して、ピックアップ要求を宅配サービスに送出するよう、患者サーバに要求することができる。要求は、患者の名前、住所、およびピックアップが行われるべきアイテムを含め、すべての必要な情報を含む。さらに、ユーザの要求で、患者サーバは、販売店インタフェース４０を介して、要求されるアイテムに対する注文を販売業者に対して生成することもできる（また、注文は、要求されるアイテムの製造業者、または地域の販売店に送られることも可能である）。さらに、ユーザは、支払人インタフェース４２を介して、取引全体の詳細を有するドキュメンテーションをそれぞれの支払人に送るよう、患者サーバ２０に要求することもできる。支払人は、支払いをユーザに送る。
【００３４】
患者サーバを使用する通常のシステムは、以下のとおり動作する。数名の患者が、ＣＰＡＰデバイス（睡眠時無呼吸の治療のために使用される）などの、あるデバイスに関して、医者から処方を受け取る。地域の在宅医療機器販売店（ＨＭＥ）および医者らはすべて、患者サーバのユーザである。
【００３５】
各患者は、ＨＭＥ、その患者のＣＰＡＰデバイス１２、マスクなどの付属品、および関連するデバイスモニタ１４を受け取る。次に、患者は、患者のデバイス、付属品、および患者の支払人をリストアップして、患者サーバ２０に登録する。そのデータは、データベース２６、２８、３０、３２に入力される。患者の支払人は、ＣＰＡＰデバイスおよびマスクの初期費用を支払う。さらに、この説明では、一部の支払人は、定期的な間隔で（例えば、毎年）マスクの交換の代金も支払う。
【００３６】
通常、いくつかのＨＭＥが、患者サーバ２０のユーザであり、各ＨＭＥは、患者サーバ２０のそれぞれのデータベースの中ですべてリストアップされる、そのＨＭＥ独自のグループの患者、デバイス、製造業者、および支払人を扱う。
【００３７】
各ＨＭＥは、患者サーバからユーザ権を得ることにより（例えば、ソフトウェアモジュールを獲得することにより）、ユーザとなる。
【００３８】
患者らが、ＣＰＡＰデバイスを使用することを始める。デバイスは、患者の活動に関する収集情報を監視し、ポケットベルシステムを介して、セルラー電話システムを介して、有線通信チャネル上でなど、監視システム１８に記録するために、その情報を送信する。
【００３９】
ＨＭＥの１つがログオンするたびに、患者サーバ２０は、そのＨＭＥの患者らのいずれかの患者のステータスが、変化しているかどうかを判定する。所定の期間の後、例えば、１年の後、数名の患者の付属品が、交換に関して適格になり、ユーザに、サーバによって適切なリマインダが生成される。ＨＭＥは、交換マスクを申し出るメッセージを患者に送信する。患者が、同意した場合、ユーザは、注文を手動で実行することができる。代替として、ユーザは、注文を実行するよう、患者サーバに要求する。すると、患者サーバは、古いマスクをピックアップするよう、宅配サービスに要求を送信する。また、患者サーバは、ＨＭＥ、販売店、または他の供給源から交換マスクをピックアップして、そのマスクを患者に運び、そのマスクを古いマスクと交換するよう、宅配サービスに要求することもできる。古いマスクは、ＨＭＥ、または他の指定された組織に戻される。また、患者サーバは、支払人によるＨＭＥへの支払いを求める要求も送信する。支払人がデバイスの使用の検証を要求することを、データベース支払人データベース１８の中に格納された諸規則が示す場合、そのような検証が、監視システム１８によって収集された情報から、患者データベース２８によって提供される。すると、支払人は、支払いをＨＭＥに送る。
【００４０】
前述したとおり、医者（または他の医療提供関係者）は、例えば、自身のソフトウェアモジュールを獲得することにより、患者サーバのユーザとして署名（契約締結）することもできる。医者は、患者サーバを使用して、医者自身の患者の数名について、他の医者の患者らについてなどの、統計データを収集することができる。また、医者は、医者の患者らの各患者について調べて、監視システム１８からのデータに基づき、処方された治療が守られていたかどうかを判定することもできる。
【００４１】
本発明を、患者の住居における在宅介護デバイスに関連して説明してきた。代替として、健康に関連する他の様々な資材を提供するために使用される。例えば、高齢者を含め、多くの患者が、薬剤の処方を受け取る。乱用を防止するため、処方は、所定の間隔で（例えば、月に１回）、更新され、所定の期間（例えば、１年）の後、有効期限切れにならなければならず、患者は、医者を訪問して、新たな処方を取得しなければならない。本発明は、以上の環境にも適用可能である。そのケースでは、サーバ２０は、患者から、または代替の源（例えば、医師）から、処方の詳細に関して情報を受け取る。また、この情報は、薬剤師によって入力されることも可能である。
【００４２】
サーバ２０は、適宜、処方のステータスを確認し、リマインダを生成することを自動的に行う。例えば、図６に示される一実施形態では、ユーザがログインすることにより、リマインダの計算がトリガされる。その実施形態では、ステップ６０２で、ユーザが、ログインし、ステップ６０４で、患者のリストが、獲得され、ステップ６０６で、確認が実行されて、それぞれの患者の処方が、所定の期間（例えば、今後７日）内に有効期限切れになるかどうかが判定される。有効期限切れにならない場合、ステップ６０８で、所定の間隔（例えば、今後３日）内に、更新を要する患者の処方が存在するかどうかを判定する確認が、実行される。以上のデータは、患者データベース２６などの、データベース群の１つのデータベースに入力される。次に、ユーザに、レポートを選択するためのメニューが提示される（ステップ６１０）。ステップ６１２で、ユーザが、メニューを選択する。ステップ６１４で、選択されたメニューが患者情報を含むかどうかの確認が、行われる。患者情報を含む場合、患者の処方が更新される必要があること、または新たな処方が必要とされていることを、適宜、示すリマインダを含め、レポートが、生成される。次に、ユーザは、その趣旨の通常の手紙、ファックス、または電子メールを患者に送ることができる。ステップ６１６で、例えば、特定の医者によってどのような薬剤が処方されたかについてのレポートを含め、他のレポート群が、生成される。
【００４３】
代替として、サーバ２０が、前述したとおり、確認を実行し、自動化されたリマインダを患者らに直接に生成することができる。
【００４４】
以上の諸実施形態のいずれかにおいて、処方の更新が要求される場合、患者は、前述したとおり、郵便、ファックス、電子メール、電話などによって通知を受けることが可能である。代替の実施形態では、患者は、処方を更新することを所望すると応答することが可能である。すると、薬剤師は、新たな処方を準備して、その処方が、患者によってピックアップされる用意をしておくことができる。代替として、患者サーバが、患者から承認を受け取ると、医薬品をピックアップして、ユーザに即時に発送するよう、宅配業者に要求を発行してもよい。
【００４５】
あまり流通していない特殊なデバイス、付属品、または医薬品には、デバイスデータベース３０によって目印が付けられることが可能である。それらは、ＨＭＥに、通常、置かれていないかもしれない品目である可能性がある。それらの特殊な品目のいずれかに関して、または在庫切れである、もしくはＨＭＥに置かれていない、いずれかの品目に関して、リマインダが生成された場合、患者サーバ２０は、その品目の必要性があることを通知する、販売店、販売業者、製造業者、または他の薬局に対する注文を生成する。すると、以上の他の組織は、その品目を獲得して、患者に発送する必要な措置を取ることを始めることができる。
【００４６】
明らかに、添付の特許請求の範囲において定義される本発明の範囲を逸脱することなく、本発明に様々な変形が行われることが可能である。
【図面の簡単な説明】
【００４７】
【図１】本発明による在宅介護デバイスの展開および使用を監視するためのインターネットベースのシステムを示す図である。
【図２】本発明による、情報を収集し、患者リマインダを提供する患者サーバを示すブロック図である。
【図３】図２のサーバに関するデータ収集に関する流れ図である。
【図４】図２のサーバの動作の流れ図である。
【図５】図２のサーバの代替の動作モードの流れ図である。
【図６】処方に関するリマインダを生成する図２のサーバに関する流れ図である。
【特許請求の範囲】
【請求項１】
在宅介護デバイスをそれぞれが含む複数のサイトから情報を受け取る患者インタフェースと、
前記情報を受け取り、前記情報に基づき、前記在宅介護デバイスに関連する支払いに関する、サイトに関連する患者の適格性について判定を行い、前記患者が適格であると判明した場合、リマインダメッセージを生成するプロセッサと
を備える患者サーバ。
【請求項２】
前記リマインダメッセージに基づいてユーザにリマインダを生成するディスプレイをさらに備える請求項１に記載の患者サーバ。
【請求項３】
前記プロセッサは、前記リマインダメッセージに基づいて顧客へのリマインダの手紙を生成する、請求項１に記載の患者サーバ。
【請求項４】
前記プロセッサは、前記患者がデバイス転換に関して適格である場合、前記リマインダメッセージを生成する、請求項１に記載の患者サーバ。
【請求項５】
前記デバイスに関連する付属品をさらに備えており、
前記プロセッサは、前記付属品が交換され得る場合、前記リマインダメッセージを生成する、請求項１に記載の患者サーバ。
【請求項６】
前記適格性を判定する規則を定義するデータベースをさらに備える請求項１に記載の患者サーバ。
【請求項７】
患者サイトから、前記患者サイトに配置された在宅介護デバイスについての情報を含む情報を受け取る患者インタフェースと、
適格性規則を含むデータベースと、
前記情報を受け取り、前記適格性規則を使用して前記情報を分析し、前記規則に基づき、前記デバイスが、ステータス変更に関して適格である場合、リマインダメッセージを生成するプロセッサと
を備える患者サーバ。
【請求項８】
前記デバイスは、転換に関して適格である請求項７に記載の患者サーバ。
【請求項９】
前記デバイスに関連する付属品をさらに備えており、
前記メッセージは、前記付属品の交換に関する情報を含む、請求項７に記載の患者サーバ。
【請求項１０】
前記デバイスを作る製造業者を記述するデバイス製造業者データを含むデータベースをさらに備える請求項７に記載の患者サーバ。
【請求項１１】
前記製造業者によって作られた複数のデバイスを記述するデータを有するデバイスデータベースをさらに備える請求項１０に記載の患者サーバ。
【請求項１２】
患者のサイトにおいて在宅介護デバイスを有する患者への支払いを生成する方法であって、
前記デバイスに関する情報を中央ロケーションにおいて格納するステップと、
デバイス支払いを記述する規則セットを格納するステップと、
前記情報を使用して前記規則セットを分析することにより、前記デバイスに関する支払いと関係がある出力メッセージを生成するステップと、
前記メッセージを提示するステップと
を含む方法。
【請求項１３】
前記デバイスを作る製造業者のリストを前記データベースの中に格納し、前記リストに適用される規則を使用して、前記出力メッセージを生成するステップをさらに含む請求項１２に記載の方法。
【請求項１４】
前記デバイスを記述するデバイスデータを格納し、前記デバイスデータを前記規則セットと一緒に使用するステップをさらに含む請求項１３に記載の方法。
【請求項１５】
前記出力メッセージに基づいて前記患者に患者メッセージを送るステップをさらに含む請求項１２に記載の方法。
【請求項１６】
患者に薬剤を出すための方法であって、
処方を生成するステップと、
前記処方に基づいて患者に前記薬剤を提供するステップと、
前記薬剤についての情報を中央ステーションに提供するステップと、
前記中央ステーションにおいて前記情報を分析するステップと、
前記処方が更新される必要がある場合、または交換される必要がある場合、リマインダメッセージを患者に送るステップと
を含む方法。
【請求項１７】
前記リマインダメッセージは、ファックスである、請求項１６に記載の方法。
【請求項１８】
前記リマインダメッセージは、電子メールである、請求項１６に記載の方法。
【請求項１９】
前記リマインダメッセージは、前記処方が有効期限切れになる数日前に送られる、請求項１６に記載の方法。
【請求項２０】
医療デバイス、および関連する付属品を配送する方法であって、
患者らに前記デバイスを提供するステップと、
前記患者ら、対応するデバイス、および前記デバイス、もしくは前記デバイスの付属品の交換を規制する規則セットを患者サーバに登録するステップと、
デバイスまたは付属品が、いつ交換デバイスまたは交換付属品に関して適格になるかを前記患者サーバで確認するステップと、
対応するリマインダメッセージを生成するステップと
を含む方法。
【請求項２１】
前記患者のデバイスもしくは付属品が交換に関して適格であることを示すメッセージを前記患者に送るステップをさらに含む請求項２０に記載の方法。
【請求項２２】
前記患者から応答を受け取り、前記患者サーバによって注文を生成するステップをさらに含む請求項２１に記載の方法。
【請求項２３】
前記デバイスまたは前記付属品は、収集されなければならないものであり、
前記患者サーバによってピックアップ要求を生成し、前記ピックアップ要求を宅配業者に送り、前記宅配業者によって前記デバイスまたは前記付属品をピックアップするステップをさらに含む、請求項２１に記載の方法。
【請求項２４】
前記規則は、適格性のために前記デバイスの所定の使用を要求するものであり、
前記デバイスの使用を監視し、前記使用に関する情報を収集し、前記情報を支払人に提供するステップをさらに含む請求項２０に記載の方法。
【請求項１】
在宅介護デバイスをそれぞれが含む複数のサイトから情報を受け取る患者インタフェースと、
前記情報を受け取り、前記情報に基づき、前記在宅介護デバイスに関連する支払いに関する、サイトに関連する患者の適格性について判定を行い、前記患者が適格であると判明した場合、リマインダメッセージを生成するプロセッサと
を備える患者サーバ。
【請求項２】
前記リマインダメッセージに基づいてユーザにリマインダを生成するディスプレイをさらに備える請求項１に記載の患者サーバ。
【請求項３】
前記プロセッサは、前記リマインダメッセージに基づいて顧客へのリマインダの手紙を生成する、請求項１に記載の患者サーバ。
【請求項４】
前記プロセッサは、前記患者がデバイス転換に関して適格である場合、前記リマインダメッセージを生成する、請求項１に記載の患者サーバ。
【請求項５】
前記デバイスに関連する付属品をさらに備えており、
前記プロセッサは、前記付属品が交換され得る場合、前記リマインダメッセージを生成する、請求項１に記載の患者サーバ。
【請求項６】
前記適格性を判定する規則を定義するデータベースをさらに備える請求項１に記載の患者サーバ。
【請求項７】
患者サイトから、前記患者サイトに配置された在宅介護デバイスについての情報を含む情報を受け取る患者インタフェースと、
適格性規則を含むデータベースと、
前記情報を受け取り、前記適格性規則を使用して前記情報を分析し、前記規則に基づき、前記デバイスが、ステータス変更に関して適格である場合、リマインダメッセージを生成するプロセッサと
を備える患者サーバ。
【請求項８】
前記デバイスは、転換に関して適格である請求項７に記載の患者サーバ。
【請求項９】
前記デバイスに関連する付属品をさらに備えており、
前記メッセージは、前記付属品の交換に関する情報を含む、請求項７に記載の患者サーバ。
【請求項１０】
前記デバイスを作る製造業者を記述するデバイス製造業者データを含むデータベースをさらに備える請求項７に記載の患者サーバ。
【請求項１１】
前記製造業者によって作られた複数のデバイスを記述するデータを有するデバイスデータベースをさらに備える請求項１０に記載の患者サーバ。
【請求項１２】
患者のサイトにおいて在宅介護デバイスを有する患者への支払いを生成する方法であって、
前記デバイスに関する情報を中央ロケーションにおいて格納するステップと、
デバイス支払いを記述する規則セットを格納するステップと、
前記情報を使用して前記規則セットを分析することにより、前記デバイスに関する支払いと関係がある出力メッセージを生成するステップと、
前記メッセージを提示するステップと
を含む方法。
【請求項１３】
前記デバイスを作る製造業者のリストを前記データベースの中に格納し、前記リストに適用される規則を使用して、前記出力メッセージを生成するステップをさらに含む請求項１２に記載の方法。
【請求項１４】
前記デバイスを記述するデバイスデータを格納し、前記デバイスデータを前記規則セットと一緒に使用するステップをさらに含む請求項１３に記載の方法。
【請求項１５】
前記出力メッセージに基づいて前記患者に患者メッセージを送るステップをさらに含む請求項１２に記載の方法。
【請求項１６】
患者に薬剤を出すための方法であって、
処方を生成するステップと、
前記処方に基づいて患者に前記薬剤を提供するステップと、
前記薬剤についての情報を中央ステーションに提供するステップと、
前記中央ステーションにおいて前記情報を分析するステップと、
前記処方が更新される必要がある場合、または交換される必要がある場合、リマインダメッセージを患者に送るステップと
を含む方法。
【請求項１７】
前記リマインダメッセージは、ファックスである、請求項１６に記載の方法。
【請求項１８】
前記リマインダメッセージは、電子メールである、請求項１６に記載の方法。
【請求項１９】
前記リマインダメッセージは、前記処方が有効期限切れになる数日前に送られる、請求項１６に記載の方法。
【請求項２０】
医療デバイス、および関連する付属品を配送する方法であって、
患者らに前記デバイスを提供するステップと、
前記患者ら、対応するデバイス、および前記デバイス、もしくは前記デバイスの付属品の交換を規制する規則セットを患者サーバに登録するステップと、
デバイスまたは付属品が、いつ交換デバイスまたは交換付属品に関して適格になるかを前記患者サーバで確認するステップと、
対応するリマインダメッセージを生成するステップと
を含む方法。
【請求項２１】
前記患者のデバイスもしくは付属品が交換に関して適格であることを示すメッセージを前記患者に送るステップをさらに含む請求項２０に記載の方法。
【請求項２２】
前記患者から応答を受け取り、前記患者サーバによって注文を生成するステップをさらに含む請求項２１に記載の方法。
【請求項２３】
前記デバイスまたは前記付属品は、収集されなければならないものであり、
前記患者サーバによってピックアップ要求を生成し、前記ピックアップ要求を宅配業者に送り、前記宅配業者によって前記デバイスまたは前記付属品をピックアップするステップをさらに含む、請求項２１に記載の方法。
【請求項２４】
前記規則は、適格性のために前記デバイスの所定の使用を要求するものであり、
前記デバイスの使用を監視し、前記使用に関する情報を収集し、前記情報を支払人に提供するステップをさらに含む請求項２０に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００８−５１１９０２（Ｐ２００８−５１１９０２Ａ）
【公表日】平成２０年４月１７日（２００８．４．１７）
【国際特許分類】
【出願番号】特願２００７−５２９８１０（Ｐ２００７−５２９８１０）
【出願日】平成１７年２月１日（２００５．２．１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００２９４９
【国際公開番号】ＷＯ２００６／０２８４８７
【国際公開日】平成１８年３月１６日（２００６．３．１６）
【出願人】（５０００４６４５０）レスメド リミテッド (192)
【公表日】平成２０年４月１７日（２００８．４．１７）
【国際特許分類】
【出願日】平成１７年２月１日（２００５．２．１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００２９４９
【国際公開番号】ＷＯ２００６／０２８４８７
【国際公開日】平成１８年３月１６日（２００６．３．１６）
【出願人】（５０００４６４５０）レスメド リミテッド (192)
[ Back to top ]