特表 2024-514048 医療用インプラントからの生理学的データおよび診断デバイスデータを自律的かつ遠隔的に監視、分析および応答するためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-03-28

(54)【発明の名称】医療用インプラントからの生理学的データおよび診断デバイスデータを自律的かつ遠隔的に監視、分析および応答するためのシステムおよび方法

(51)【国際特許分類】

   G16H 80/00 20180101AFI20240321BHJP

   A61B 5/00 20060101ALI20240321BHJP

【ＦＩ】

G16H80/00

A61B5/00 102C

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023556792

(86)(22)【出願日】2022-04-07

(85)【翻訳文提出日】2023-09-14

(86)【国際出願番号】 EP2022059244

(87)【国際公開番号】W WO2022218808

(87)【国際公開日】2022-10-20

(31)【優先権主張番号】63/175,598

(32)【優先日】2021-04-16

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】21173347.2

(32)【優先日】2021-05-11

(33)【優先権主張国・地域又は機関】EP

(81)【指定国・地域】

(71)【出願人】

【識別番号】309035121

【氏名又は名称】ビオトロニーク ソシエタス ヨーロピア ウント コンパニー コマンディートゲゼルシャフト

【氏名又は名称原語表記】ＢＩＯＴＲＯＮＩＫ ＳＥ ＆ Ｃｏ． ＫＧ

【住所又は居所原語表記】Ｗｏｅｒｍａｎｎｋｅｈｒｅ １，Ｄ－１２３５９ Ｂｅｒｌｉｎ，Ｇｅｒｍａｎｙ

(74)【代理人】

【識別番号】100114890

【弁理士】

【氏名又は名称】アインゼル・フェリックス＝ラインハルト

(74)【代理人】

【識別番号】100098501

【弁理士】

【氏名又は名称】森田 拓

(74)【代理人】

【識別番号】100116403

【弁理士】

【氏名又は名称】前川 純一

(74)【代理人】

【識別番号】100134315

【弁理士】

【氏名又は名称】永島 秀郎

(74)【代理人】

【識別番号】100162880

【弁理士】

【氏名又は名称】上島 類

(72)【発明者】

【氏名】ジェームス ホートン

(72)【発明者】

【氏名】ローレン クレーター

(72)【発明者】

【氏名】アンドリュー ビー． キブラー

(72)【発明者】

【氏名】アンドレアス ギュート

(72)【発明者】

【氏名】アドリアン キンバー

(72)【発明者】

【氏名】ブライアン ヒルズ

(72)【発明者】

【氏名】ウォーレン ダブニー

(72)【発明者】

【氏名】ショーン スリー

【テーマコード（参考）】

4C117

5L099

【Ｆターム（参考）】

4C117XB01

4C117XB04

4C117XB11

4C117XC21

4C117XE23

4C117XE26

4C117XJ13

4C117XJ45

4C117XL01

4C117XL06

4C117XL11

5L099AA04

(57)【要約】

本発明は、遠隔患者モニタリングのためのシステムに関する。システムは、少なくとも１つの医療デバイスと、患者遠隔デバイスと、遠隔モニタリングサーバデバイス（ＲＭＳ）と、医療専門家（ＨＣＰ）遠隔デバイスと、を備える。少なくとも１つの医療デバイスは、患者の生理学的データを自動的に収集し、患者遠隔デバイスを介して収集された患者の生理学的データをＲＭＳに伝送するように構成される。ＲＭＳは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介してＨＣＰ遠隔デバイスとのインタフェース接続を形成して、医療専門家がＲＭＳ上で収集された患者の生理学的データにアクセスすることを可能にするように構成される。このようにして、患者とのやり取りを必要とせずに、医療用インプラントからの生理学的データの連続的な遠隔モニタリングを提供することが可能である。モニタリングデータは、オンデマンドでウェブベースおよび／またはアプリベースのユーザポータルを介して医師に利用可能である。ＲＭＳは、生理学的測定値、例えば、睡眠障害、活動レベル、発熱（例えば潜在的な感染症）を表すコア体温の頻繁な（例えば毎日の）自動報告を提供することができる。

【特許請求の範囲】

【請求項1】

遠隔患者モニタリングのためのシステム（１００）であって、前記システム（１００）は、
－少なくとも１つの医療デバイス（１０）と、
－患者遠隔デバイス（１２）と、
－遠隔モニタリングサーバデバイス（ＲＭＳ）（１４）と、
－医療専門家（ＨＣＰ）遠隔デバイス（１６）と、
を備え、
前記少なくとも１つの医療デバイスは、患者の生理学的データを自動的に収集し、前記患者遠隔デバイスを介して収集された前記患者の生理学的データを前記ＲＭＳに伝送するように構成されており、
前記ＲＭＳは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介して前記ＨＣＰ遠隔デバイスとのインタフェース接続を形成して、医療専門家が前記ＲＭＳ上で収集された前記患者の生理学的データにアクセスすることを可能にするように構成されている、
システム。

【請求項2】

前記システムは、前記患者遠隔デバイスを介して、前記医療専門家インタフェースを使用して、前記少なくとも１つの医療デバイスのリアルタイム遠隔プログラミングおよび／またはインタロゲーションを提供するように構成されている、
請求項１記載のシステム。

【請求項3】

前記患者遠隔デバイスは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む患者インタフェースを介して前記ＲＭＳとのインタフェース接続を形成して、
（ｉ）前記患者が患者提供データを提供して前記患者提供データを前記ＲＭＳに伝送することを可能にし、かつ／または
（ｉｉ）前記患者および／または患者介護者が前記患者のための患者に適したデータのサブセットにアクセスすることを可能にする、
ようにさらに構成されている、
請求項１または２記載のシステム。

【請求項4】

前記患者提供データは、
－患者報告遠隔疼痛評価と、
－患者報告遠隔睡眠評価と、
－患者報告症状データと、
のうちの１つ以上を含む、
請求項３記載のシステム。

【請求項5】

前記患者遠隔デバイスは、前記少なくとも１つの医療デバイスの診断デバイスデータのインタロゲーションを提供し、前記診断デバイスデータを前記ＲＭＳに伝送するように構成されている、
請求項１から４までのいずれか１項記載のシステム。

【請求項6】

前記ＲＭＳは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む製造者サポートインタフェースを介して製造者サポートとのインタフェース接続を形成して、前記製造者サポートが収集された前記患者の生理学的データおよび／または前記少なくとも１つの医療デバイスの診断デバイスデータにアクセスすることを可能にするように構成されている、
請求項１から５までのいずれか１項記載のシステム。

【請求項7】

前記ＲＭＳは、
－収集された前記患者の生理学的データおよび／または患者提供データを監視し、予め設定された１つ以上のトリガの発生に応じて、前記患者の健康または精神衛生が変化した可能性が高いことを示すアラートを形成し、かつ／または
－前記診断デバイスデータを監視し、予め設定された１つ以上のトリガの発生時に影響を受ける可能性が高い患者コンプライアンスを示すアラートを形成する、
ように構成されている、
請求項１から６までのいずれか１項記載のシステム。

【請求項8】

前記予め設定された１つ以上のトリガは、前記医療専門家インタフェースおよび／または前記製造者サポートインタフェースを介してコンフィグレーション可能である、
請求項７記載のシステム。

【請求項9】

前記予め設定された１つ以上のトリガは、患者ごとにまたは患者グループごとにコンフィグレーション可能であり、かつ／または
前記予め設定された１つ以上のトリガは、形成された前記アラートの宛先に対してコンフィグレーション可能である、
請求項８記載のシステム。

【請求項10】

前記ＲＭＳは、優先度のレベルを有する前記アラートを形成するように構成されている、
請求項７から９までのいずれか１項記載のシステム。

【請求項11】

前記予め設定された１つ以上のトリガは、初期的には前記医療専門家インタフェースを介してコンフィグレーション可能であり、
前記ＲＭＳは、前記患者の必要性に基づいて前記予め設定された１つ以上のトリガを連続的に更新するように構成されている、
請求項７から１０までのいずれか１項記載のシステム。

【請求項12】

前記ＲＭＳは、予め設定された１つ以上のトリガの発生時にチケットを形成し、前記製造者サポートインタフェースを介して複数の製造者サポートユーザの間で前記チケットを共有するように構成されている、
請求項７から１１までのいずれか１項記載のシステム。

【請求項13】

遠隔患者モニタリングのための方法（２００）であって、前記方法（２００）は、
－少なくとも１つの医療デバイスによって、患者の生理学的データを自動的に収集するステップ（２１０）と、
－前記少なくとも１つの医療デバイスによって、収集された前記患者の生理学的データを、患者遠隔デバイスを介して遠隔モニタリングサーバデバイス（ＲＭＳ）に伝送するステップ（２２０）と、
－ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介して、前記ＲＭＳによって、医療専門家（ＨＣＰ）遠隔デバイスとのインタフェース接続を形成して、医療専門家が前記ＲＭＳ上で収集された前記患者の生理学的データにアクセスすることを可能にするステップ（２３０）と、
を含む方法。

【請求項14】

少なくとも１つの処理ユニットによって実行される際に、前記少なくとも１つの処理ユニットに請求項１３記載の方法のステップを実行させるための命令を含む、
コンピュータプログラム製品。

【請求項15】

請求項１４記載のコンピュータプログラム製品を格納する、
コンピュータ可読データ担体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、遠隔患者モニタリングのためのシステムおよび方法を説明する。

【背景技術】

【0002】

最先端のインプラント式ペースメーカ、心臓モニタ、神経刺激器、および同様のインプラント式医療デバイス（ＩＭＤ：Implanted Medical Device）は、臨床医との対面診療中に臨床医ユーザインタフェース（ＣＵＩ）デバイス（「プログラマ」）と通信している。対面診療の間、プログラマは、診断および技術データのリアルタイムビューを提供する。

【0003】

一般的なシステムでは、データ捕捉能力が不足している。例えば、疼痛管理のための脊髄刺激（ＳＣＳ：Spinal Cord Stimulation）患者の状態の評価は、現在、患者からの定性的、主観的フィードバック、および／または診療所内での経過観察中に収集されたインタロゲーションデータに限定されている。これらのプロセスは、一般的に、統合された患者およびデバイスの現在状態のレビュー、または患者の長期的なデータのレビューのための客観的な評価ツールが欠如している。

【0004】

最新のインプラント式デバイスシステムの多くは、診断データおよび技術データをサーバ（例えば「遠隔モニタリングサーバ」、ＲＭＳ：Remote Monitoring Server）に定期的に伝送することもできる。臨床医は、安全なウェブサイトまたはモバイルアプリを通じてこのデータにアクセスする。これにより、遠隔地から患者の状態を見ることができる。

【0005】

しかしながら、臨床医がこのデータとやり取りするために提供されるユーザインタフェース（ＵＩ：User Interface）は通常、診察室内で、かつ／または遠隔モニタリングを介して収集された患者ＩＭＤのインタロゲーション報告の表示以外のサービスを提供していない。臨床医がその患者に対してより複雑なケアを提供し、または臨床診療管理の他の態様においてこのデータを使用するには、利用できる報告があまりにも限定的であることが多い。

【0006】

さらに、既存の遠隔モニタリング設計におけるデータ伝送遅延は、臨床医がより複雑なケアを患者に提供するには制限が多すぎる。例えば、神経刺激システムは、刺激治療を効果的に調整するために、患者から臨床医への双方向フィードバックを必要とする。こうしたやり取りを遠隔的に提供することは、現在のシステムでは不可能である。心調律管理（ＣＲＭ：Cardiac Rhythm Management）では、患者が診療所に連絡してイベントの発生を報告したときに、心臓内電位図（ＩＥＧＭ：Intracardiac Electrogram）およびデバイスの状態をリアルタイムで見ることができることが望ましい。ＩＥＧＭおよびシステムデータをリアルタイムで見ることにより、臨床医は、患者を正確にトリアージし、必要な次のステップを決定することができる。ＣＲＭデバイスは典型的にはイベントを検出および記録することが可能であるが、デバイスが常に正しくプログラミングされてイベントを検出することを想定すべきではない。さらに、このインプラント式デバイスは通常、内部トリガ（例えば、イベント検出、スケジューリングされた更新伝送）のみに基づいて伝送を行うため、これらから伝送されるデータは通常、診察室でのチェック時には最新のものではない。したがって、デバイスは典型的には任意の外来診療の開始時にインタロゲーションを受けるため、臨床的な人件費および時間の遅れが生じる。インタロゲーションが診療所に対して遠隔で利用可能であれば、この機能を患者の来院の前に実施することができる。

【発明の概要】

【課題を解決するための手段】

【0007】

本開示は、先行技術の欠点を克服する、独立請求項による遠隔患者モニタリングのためのシステム、方法、コンピュータプログラム製品およびコンピュータ可読データ担体を提供する。さらなる実施形態は、従属請求項に組み込まれている。

【0008】

本開示の第１の態様によれば、遠隔患者モニタリングのためのシステムが提供される。システムは、少なくとも１つの医療デバイスと、患者遠隔デバイスと、遠隔モニタリングサーバデバイス（ＲＭＳ）と、医療専門家（ＨＣＰ）遠隔デバイスと、を備える。少なくとも１つの医療デバイスは、患者の生理学的データを自動的に収集し、患者遠隔デバイスを介して収集された患者の生理学的データをＲＭＳに伝送するように構成されている。ＲＭＳは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介してＨＣＰ遠隔デバイスとのインタフェース接続を形成して、医療専門家がＲＭＳ上で収集された患者の生理学的データにアクセスすることを可能にするように構成されている。

【0009】

提案のシステムは、患者とのやり取りを必要とせずに、医療用インプラントからの生理学的データの連続的な遠隔モニタリングを提供することが可能であるという利点を有しうる。モニタリングデータは、オンデマンドでウェブベースおよび／またはアプリベースのユーザポータルを介して医師に利用可能である。ＲＭＳは、生理学的測定値、例えば睡眠障害、活動レベル、発熱（例えば潜在的感染症）を表すコア体温の頻繁な（例えば毎日の）自動報告を提供することができる。モニタリング能力は、以下に説明するように、医療専門家インタフェース、製造者サポートインタフェースおよび／または患者インタフェースを介してオンにすることができる。

【0010】

提案のシステムは、医療デバイス用途の複数の領域、例えば脊髄刺激（ＳＣＳ）、心調律管理（ＣＲＭ）およびインプラント式医療デバイスを利用する多くの他の医療分野、例えば、脳深部刺激（ＤＢＳ）、後頭神経刺激（ＯＮＳ）、三叉神経刺激（ＴＮＳ）、迷走神経刺激（ＶＮＳ）、横隔神経刺激、胃電気刺激および仙骨神経刺激（ＳＮＳ）において使用することができる。

【0011】

本発明の一実施形態によれば、システムは、患者遠隔デバイスを介して、医療専門家インタフェースを使用して、少なくとも１つの医療デバイスのリアルタイム遠隔プログラミングおよび／またはインタロゲーションを提供するように構成される。

【0012】

このようにして、データ捕捉およびデータ伝送の開始が患者に依存しないため、臨床医がデータの捕捉方法および捕捉するタイミングを制御できる。診療所は、インプラントから伝送された情報の受信を制御することができるため、データが受信された時点でデータの受信に応答することができる。これにより、データの臨床的レビューに関するワークフローを改善することができる。

【0013】

さらに、臨床の専門家（例えば企業サービス担当者）が、遠隔で接続し、インプラント式デバイスの状態を確認し、新たなまたは更新された治療プログラムを患者に送信することが可能である。ワークフローは、各医師および患者に対して（例えば、遠隔患者来院に参加するか否かの選択肢につき）カスタマイズすることができる。

【0014】

本発明の一実施形態によれば、患者遠隔デバイスは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む患者インタフェースを介してＲＭＳとのインタフェース接続を形成して、（ｉ）患者が患者提供データを提供して、患者提供データをＲＭＳに伝送することを可能にし、かつ／または（ｉｉ）患者および／または患者介護者が患者のための患者に適したデータのサブセットにアクセスすることを可能にするようにさらに構成される。

【0015】

このようにして、患者遠隔デバイス（例えばスマートフォン）を介して、患者報告症状データを作成し、早期かつ効果的な治療を調整することが可能である。

【0016】

加えて、脊髄刺激の分野では、個別化された配慮が患者に与えられることに伴って、刺激に対する成功の可能性および患者の満足度が高まることが知られている。患者提供データとの遠隔でのやり取りを（たとえ高度な分析がなくても）導入することにより、臨床医／担当者または患者が移動することなく、臨床医／担当者または企業の担当者がより頻繁に、より多くの個別化された配慮を提供できるようになる。

【0017】

本発明の一実施形態によれば、患者提供データは、
－患者報告遠隔疼痛評価、
－患者報告遠隔睡眠評価、および
－患者報告症状データ
のうちの１つ以上を含む。

【0018】

本発明の一実施形態によれば、患者遠隔デバイスは、少なくとも１つの医療デバイスの診断デバイスデータのインタロゲーションを提供し、診断デバイスデータをＲＭＳに伝送するように構成される。

【0019】

これにより、患者のコンプライアンス（例えば、電極インピーダンス、リードシフト、刺激使用量、充電状態（例えばバッテリ状態）、治療のオン／オフ）に影響を及ぼしうる毎日のデバイス診断の自動ルーティングが可能となりうる。

【0020】

本発明の一実施形態によれば、ＲＭＳは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む製造者サポートインタフェースを介して製造者サポートとのインタフェース接続を形成して、製造者サポートが収集された患者の生理学的データおよび／または少なくとも１つの医療デバイスの診断デバイスデータにアクセスすることを可能にするように構成される。

【0021】

本発明の一実施形態によれば、ＲＭＳは、収集された患者の生理学的データおよび／または患者提供データを監視し、予め設定された１つ以上のトリガの発生に応じて、患者の健康または精神衛生が変化した可能性が高いことを示すアラートを形成するように構成される。代替的にもしくは付加的に、ＲＭＳは、ＲＭＳ診断デバイスデータを監視し、予め設定された１つ以上のトリガの発生時に影響を受ける可能性が高い患者コンプライアンスを示すアラートを形成するように構成される。

【0022】

このようにして、遠隔モニタリングが治療を最適化する機会を特定した場合に、モニタリング担当者が患者／ＨＣＰに積極的に働きかけることが可能になる。例えば、アラートは、治療を最適化するために遠隔管理によって行われる特定のアクション（すなわち、再プログラミング、臨床来院および／または紹介）の必要性をトリガすることができる。

【0023】

本発明の一実施形態によれば、予め設定された１つ以上のトリガは、医療専門家インタフェースおよび／または製造者サポートインタフェースを介してコンフィグレーション可能である。

【0024】

本発明の一実施形態によれば、予め設定された１つ以上のトリガは、患者ごとにまたは患者グループごとにコンフィグレーション可能である。代替的にもしくは付加的に、予め設定された１つ以上のトリガは、形成されたアラートの宛先に対してコンフィグレーション可能である。

【0025】

本発明の一実施形態によれば、ＲＭＳは、優先度のレベルを有するアラートを形成するように構成される。

【0026】

例えば、アラートは、構成設定の一部として高優先度または通常優先度として分類することができる。個々のアラート受信者または受信者グループに対するこれらのアラート優先度は、通知が受信されるかどうかおよびどのように受信されるか、ならびに／またはフロントエンドインタフェース上のアラートの編成および外観を制御することができる。

【0027】

本発明の一実施形態によれば、予め設定された１つ以上のトリガは、初期的には医療専門家インタフェースを介してコンフィグレーション可能である。ＲＭＳは、患者の必要性に基づいて予め設定された１つ以上のトリガを自律的におよび／または連続的に更新するように構成される。

【0028】

例えば、自律的なトリガは初期的には臨床医によって設定可能であるが、次いで人工知能（ＡＩ）プロセスが自律的に監視および更新して、個々の患者の必要性のためにプロセスをさらに微調整することができる。

【0029】

本発明の一実施形態によれば、ＲＭＳは、予め設定された１つ以上のトリガの発生時にチケットを形成し、製造者サポートインタフェースを介して複数の製造者サポートユーザの間でチケットを共有するように構成される。

【0030】

チケット発行システムについては、以下に、特に図３に示されている実施形態に関して説明する。

【0031】

本開示の第２の態様によれば、遠隔患者モニタリングのための方法が提供される。本方法は、
－少なくとも１つの医療デバイスによって、患者の生理学的データを自動的に収集することと、
－少なくとも１つの医療デバイスによって、収集された患者の生理学的データを、患者遠隔デバイスを介して遠隔モニタリングサーバデバイス（ＲＭＳ）に伝送することと、
－ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介して、ＲＭＳによって、医療専門家（ＨＣＰ）遠隔デバイスとのインタフェース接続を形成して、医療専門家がＲＭＳ上で収集された患者の生理学的データにアクセスすることを可能にすることと、
を含む。

【0032】

本開示の第３の態様によれば、少なくとも１つの処理ユニットによって実行される際に、少なくとも１つの処理ユニットに、第２の態様による方法のステップを実行させるための命令を含むコンピュータプログラム製品が提供される。

【0033】

本発明の別の態様によれば、コンピュータプログラム製品を記憶するコンピュータ可読データ担体が提供される。

【0034】

本発明を、以下の図面を参照して詳細に説明する。

【図面の簡単な説明】

【0035】

【図1】遠隔患者モニタリングのためのシステムのコンポーネントを示す図である。

【図2】説明しているシステムの、遠隔モニタリングおよび遠隔プログラミングのためのシステムアーキテクチャを示す図である。

【図3】遠隔モニタリングおよび遠隔プログラミングのためのシステムのワークフローの例を示す図である。

【図4A】新たな疼痛マップを完成させるために通知が患者遠隔デバイスに送信されることを示す図である。

【図4B】現在の疼痛に対応する腰部における患者の選択部位を示す図である。

【図5】遠隔患者モニタリングのための方法のフローチャートを示す図である。

【発明を実施するための形態】

【0036】

以下に、本発明を、前述の図を用いて詳細に説明する。図示の例示的な実施形態は例示の目的のために利用するものであり、本発明の主題はこれらの例示的な実施形態によって限定されず、特許請求の範囲の主題によって定義される。

【0037】

以下に、本発明のシステムの実施形態を詳細に説明する。実施形態は、脊髄刺激（ＳＣＳ）デバイスの形態の医療デバイスおよび神経サービスセンタ（ＮＣＳ：Neuro Service Center）の形態の遠隔モニタリングサーバ（ＲＭＳ）に関して、ならびにデータインタロゲーションを含みうる遠隔プログラミングに関して説明する。

【0038】

図１は、システム１００のコンポーネントを示している。システム１００は、少なくとも１つの医療デバイス１０と、患者遠隔デバイス１２と、遠隔モニタリングサーバデバイス（ＲＭＳ）１４と、医療専門家（ＨＣＰ）遠隔デバイス１６と、を備える。

【0039】

少なくとも１つの医療デバイス１０は、「治療デバイス」と称されうるものであり、例えばインプラント式医療デバイス（例えば、インプラント式モニタリングデバイス／ループレコーダ、試験刺激器、刺激器または他のインプラント式パルス発生器）でありうる。少なくとも１つの医療デバイス１０は、患者の生理学的データを自動的に収集し、患者遠隔デバイスを介して収集された患者の生理学的データをＲＭＳに伝送するように構成されている。収集される患者の生理学的データの例として、睡眠障害、活動レベル、発熱を表すコア体温などが挙げられるが、これらに限定されない。

【0040】

患者遠隔デバイス１２は、少なくとも１つの医療デバイス１０とＲＭＳ１４との間の通信をルーティングするためのトランシーバとして機能する。患者遠隔デバイス１２は、治療プロセスのローカル制御のいくつかの態様を患者に提供することができる。例えば、患者遠隔デバイス１２は、医療デバイス、例えば脊髄刺激（ＳＣＳ）のための医療デバイスのアクティブな治療プログラムを変更し、その刺激振幅を制御し、刺激をオン／オフにし、バッテリ状態を見る能力を患者に与えることができる。患者遠隔デバイス１２はまた、医療デバイスのための外部プログラマとしての役割を果たすことができる。

【0041】

ＲＭＳ１４は、例えば、少なくとも１つの医療デバイスの遠隔プログラミング（ＲＰ：Remote Programming）およびデータインタロゲーションを容易にするハードウェアおよび／またはクラウドベースのサービスセンタであり、少なくとも１つの医療デバイスによって収集されたデータの中央データリポジトリを含むことができる。図１の例では、ＲＭＳは神経サービスセンタ（ＮＲＳ）の形態である。ハードウェアは、少なくとも１つのコンピューティングデバイスまたは複数のコンピューティングデバイスのネットワークを含みうる。ＲＭＳは、本明細書で説明するコンピューティング機能をさらに含む。例えば、ＲＭＳは、人間の介入なしに多数の算術演算および論理演算を含む実質的な計算を実行する機能ユニットであり、例えば、デスクトップコンピュータ、サーバコンピュータ、クラスタ／ウェアハウススケールコンピュータ、または組み込みシステムなどを含むことができる。

【0042】

ＨＣＰ遠隔デバイス１６は、臨床医用プログラマとも称されうる。

【0043】

ＨＣＰ遠隔デバイスは、医療デバイスを遠隔でプログラミングするために、医療専門家または現場の技術担当者によって使用可能である。ＲＭＳ１４は、ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介してＨＣＰ遠隔デバイス１６とのインタフェース接続を形成して、医療専門家がＲＭＳ上で収集された患者の生理学的データにアクセスすることを可能にするように構成されている。ＨＣＰ遠隔デバイス１６は、物理的なもの（すなわち専用デバイス）であってもよいし、または仮想的なもの（例えばシステムへのウェブベースのインタフェースを介したもの、セキュア接続されたデータレポータ）であってもよい。

【0044】

図２は、説明しているシステム１００の、遠隔モニタリングおよび／または遠隔プログラミングのためのシステムアーキテクチャを示している。

【0045】

ＳＣＳの実施形態の場合、ＨＣＰ遠隔デバイス１６上の医療専門家インタフェース（ＮＳＣユーザインタフェースとも称される）は、少なくとも１つの医療デバイス１０との閉ループリアルタイム通信を可能にしうる。例えば、臨床医は、患者との経過観察の診察または遠隔支援コールの準備のために患者の状態を知りたいと考えている。臨床医は、ＲＭＳからの「データ更新」要求をトリガし、この要求が患者遠隔デバイス１２（例えば、携帯電話機またはスマートウォッチのようなウェアラブル機器）へ伝送され、患者遠隔デバイス１２は、この要求を、少なくとも１つの医療デバイス１０、例えば図２に示されているインプラント式パルス発生器（ＩＰＧ）に中継する。インプラントは、現在の患者およびデバイスの状態を問い合わせ、患者遠隔デバイス１２を介してＲＭＳ１４に報告を伝送する。次いで、当該報告がＲＭＳによって受信され、処理されうる（すなわち、メッセージが、ＲＭＳによって使用可能な形態に変換され、システムアルゴリズムを使用してアラート条件についてスキャンされ、正しい診療所および患者に割り当てられる）。この時点で、臨床医は直接に面談する前に、新たな報告をレビューすることができる。

【0046】

いくつかの例では、ＲＭＳは、主観的データ（例えば、患者の日記、患者の調査、臨床医のメモなど）および客観的データ（現在の患者の状態、患者の傾向および転帰分析、活動ベースの追跡、薬剤使用追跡、長期疼痛データ、ｅＣａｐなどの統計および治療データなどの生理学的および／または技術的データ）を１つの閲覧可能なデータベースに組み合わせるように構成可能である。組み合わせの対象となるデータは、ＨＣＰ遠隔デバイス、患者遠隔デバイス、ＲＭＳ、医療デバイスおよびその他の複数のデータレポータから読み出すことができる。

【0047】

いくつかの例では、ＲＭＳは、複数のユーザによってアクセス可能な統合データのリアルタイムウェブサイト表示を提供することができる。例えば、医療専門家インタフェース（例えば臨床医のウェブインタフェース）を使用して、
・データを自動的に（毎日、毎月など）収集するための定期的なルーチンを介して、または要求（例えば、外来診療、患者の調整などのための準備）に基づいて受信されるデータ、
・その患者について記憶された全ての定量的データおよび主観的データを示す、ほぼリアルタイムで収集された現在の患者状態の「スナップショット」；リアルタイムデータを収集するために、患者遠隔デバイスおよび／または少なくとも１つの医療デバイスへのオンラインアクセス、
・患者のシステムの状態および経時的に収集された統計（例えば、インプラントされたリードの完全性、現在の刺激設定、ならびに疼痛および／またはシステムの使用に関連する診断傾向）、
・システムが患者遠隔デバイスによって使用されている現在のプログラムパラメータを表示すること、ならびに
・任意選択手段として、異なるデータ傾向がユーザプリファレンスに従って表示に追加されまたは表示から除去されるように、組み合わされたデータの表示をコンフィグレーションする能力をユーザが有しうること
を表示することができる。

【0048】

いくつかの例では、医療専門家インタフェースは、患者画像、ビデオ、および／またはオーディオファイル、ならびに疼痛に対する神経刺激の遠隔評価などの他のデータタイプを受信し、表示するように拡張することができる。

【0049】

いくつかの例では、ＲＭＳは、患者データベースのアクセス制御を可能にするように構成可能である。一例では、ＲＭＳは、臨床医用プログラマユーザを登録し、遠隔経過観察へのそのアクセスを制御する手段を提供することによって、デバイスのアクセスを制御できるように構成可能である。別の例では、ＲＭＳは、個々の患者健康記録（ＰＨＲ：Patient Health Record）へのデータアクセスがユーザごとに制御されるように、コンフィグレーション可能なユーザアクセス権を有効にするように構成可能である。

【0050】

いくつかの例では、ＲＭＳは、患者データベースの接続性を可能にするように構成可能である。例えば、ＮＳＣデータベースは、医療専門家インタフェース、患者インタフェース、製造者サポートインタフェースなどの複数のポータルを介してアクセス可能であってもよい。

【0051】

例えば、システム１００内の内部データコンシューマ１８およびデータレポータ２０は、システムが供給するユーザインタフェースを介してデータベースに対して読み出し／書き込みを行うことができる。例えば、技術サービスは、未加工の患者データをレビューし、患者データベースに書き込む能力を有する。

【0052】

任意選択手段として、ＲＭＳは、システムユーザがＲＭＳ１４からデータをプルすることと患者遠隔デバイスからＲＭＳ１４にデータをプッシュすることとの両方を可能としうる。例えば、電子健康記録（ＥＨＲ：Electronic Health Record）システムなどの外部データコンシューマ２２は、それ自体の内部スケジュールに基づいて、またはリアルタイムセッション中にオンデマンドで、ＲＭＳから患者データをセキュアに問い合わせ、プルすることができる。例えば、ＲＭＳ１４は、ユーザによって以前に構成されたスケジュールに基づいて、予め選択されたデータを外部データコンシューマ２２にエクスポートすることができる。任意選択手段として、外部データコンシューマ２２およびデータレポータ２４（例えばＥＨＲシステム）は、システムが供給するアプリケーションプログラミングインタフェース（ＡＰＩ：Application Programming Interface）を介してＲＭＳに接続することができる。

【0053】

いくつかの例では、ＲＭＳ１４は、その診療所の制御下にある全ての患者およびデバイスの検索可能なデータベースへのクエリを可能にするように構成されうる。

【0054】

いくつかの例では、ＲＭＳ１４は、診療所または個々のユーザのニーズに対するカスタマイズを可能にすることによって、コンフィグレーション可能な報告フォーマットを可能にするように構成可能である。

【0055】

いくつかの例では、ＲＭＳ１４は、「電子署名」または「デジタル署名」機能を可能にして、医師および／または患者が遠隔経過観察に将来参加するための同意を電子的に提供できるように構成可能である。

【0056】

いくつかの例では、ＲＭＳ１４は、全体的な結果または患者特性の関係を見るなど、診療所またはデバイスレジストリのための母集団全体のデータを閲覧する能力を可能にするように構成可能である。

【0057】

図３は、説明しているシステムの、遠隔モニタリングおよび遠隔プログラミングのためのワークフローの例を示している。

【0058】

一般的には、患者情報が作成されるときに、患者が１つ以上の患者グループ（診療所グループまたは現場サポート領域など）に割り当てられうる。これらのグループは、必要に応じて、システム管理ユーザインタフェースを介して後に変更可能である。

【0059】

個々の患者ごとに、モニタリング能力がオンにされる前に同意が文書化されなければならない。任意選択手段として、患者プログラマまたは患者アプリが同意を含んでいてもよい。

【0060】

モニタリング能力は、製造者サポートインタフェース、医療専門家インタフェース、および／または患者インタフェースを介してオンにすることができる。モニタリングデータのユーザは、どの患者グループへのアクセスが自身に許可されるかについて作成された個々のアカウントと、任意選択手段としての、適用可能な場合には連絡先情報を含むアラート通知のプリファレンスと、を有する必要がある。

【0061】

アラート
いくつかの例では、ＲＭＳ１４が、収集された患者の生理学的データおよび／または患者提供データを監視し、予め設定された１つ以上のトリガの発生に応じて、患者の健康または精神衛生が変化した可能性が高いことを示すアラートを形成するように構成されている。代替的にもしくは付加的に、ＲＭＳ１４は、ＲＭＳ診断デバイスデータを監視し、予め設定された１つ以上のトリガの発生時に、影響を受ける可能性が高い患者コンプライアンスを示すアラートを形成するように構成される。

【0062】

例えば、患者の健康または精神衛生が変化した可能性が高いことを示すアラートは、次のうちの１つ以上を含むことができる。
・１日当たりの活動時間（Ｙ日間の移動平均）がＸを下回って低下したか、またはＸを上回って上昇した。
・１日当たりの安静時間（Ｙ日間の平均）がＸを下回って低下したか、またはＸを上回って上昇した。
・１分当たりの心拍数（Ｙ日間の平均）がＸを下回って低下したか、またはＸを上回って上昇した。
・睡眠の不穏スコア（加速度計の運動アルゴリズムによる、Ｙ日間の移動平均）がＸを下回って低下したか、またはＸを上回って上昇した。
・体温がＸを上回って上昇し、発熱または感染の疑いがあることを示した。
・患者報告疼痛スコアがＹ日間にわたってＸを上回って上昇した。
・患者報告睡眠スコアがＹ日間にわたってＸを下回って低下した。
・付加的に、患者の状態を悪化させる可能性を示唆する条件の任意の組み合わせ、例えば患者報告疼痛および加速度計が測定した活動の両方が閾値に達する、など。
・患者データがＸ日間レビューされなかった。
・定期的に予定されている遠隔経過観察が固定日または間隔スケジュールに従って行われている。

【0063】

例えば、影響を受けた患者コンプライアンスを示すアラートは、次のうちの１つ以上を含むことができる。
・治療用電極上のリードインピーダンスが範囲外である。
・Ｘ個のコンタクト部よりも多い、疑わしいリードシフトが発生した。
・刺激使用量は、直近のＹ日間、Ｘ％未満であった。
・バッテリが消耗し、刺激が自動的に遮断されている。
・ＭＲＩモードがＸ日間オンのままである。
・アクティブな治療プログラムが、好ましい治療プログラムから変更されている。
・アクティブな治療プログラムの振幅が、Ｙ日を超えてＸを下回って低下している。

【0064】

別の実施形態では、システムは「アクティブ」な患者アラートを提供する。例えば、システムは、患者遠隔デバイスまたはＨＣＲ遠隔デバイスのユーザインタフェース内のデータの受動的表示／「プル」表示のみを形成することと比較して、システム内で自律的に形成される「プッシュ」アラートを提供する。一実施形態では、患者遠隔デバイスは、治療を安全に実施するための要件に従って、刺激器のバッテリの充電量が低下しているというデータをＲＭＳに伝達する（アラート条件が満たされたという判定のためのトリガ設定は、ＲＭＳまたは患者遠隔デバイス自体のいずれかの中に常駐することができる）。その後、システムは、（例えば患者アプリを介して）患者の個人携帯電話機にメッセージを送信し、患者に充電量が低下した状態を知らせる。

【0065】

さらに、別の実施形態によれば、システムが医療デバイスの充電中に特定の別の問題を検出した場合、システムは、最良の充電プロセス（例えば「充電エデュケーション」）を通して患者を誘導できるエデュケーション情報を患者アプリに自動的に送信する。この充電中の別の問題は、充電が完了する前に頻繁に充電が停止される、または再充電セッション間の過剰な時間、または患者が最良の実践と一致した方法でバッテリを充電していないことを示唆する他の使用パターンとして、観察された挙動から判定することができる。

【0066】

別の実施形態では、システムは、医療デバイスと関連付けられたプログラムのための推定バッテリ使用量を提供する。医療デバイス上で利用可能な治療プログラムの場合、システムは、再充電が必要になるまでの実行時間に関する推定値を計算する。当該情報は、ユーザが必要に応じて見ることのできる「プル」データとしても、または現在のプログラム使用がバッテリの急速な消耗につながりうる場合の「プッシュ」アラートとしても、利用可能でありうる。こうした情報は、ＨＣＰおよび患者遠隔デバイスの両方、または患者パーソナルデバイス（例えば携帯電話機）に利用可能でありうる。この実施形態では、ＲＭＳは、断続的にのみ接続されうるＨＣＰ遠隔デバイス上で計算を行う代わりに、推定バッテリ使用量を計算することになる。一実施形態によれば、推定バッテリ使用量は、医療デバイスのアクティブに実行されている治療プログラムについて計算される。

【0067】

別の実施形態では、システムは、患者の自動的な治療推奨を提供する。例えば、医療デバイスによって取得された、または医療デバイスに関連付けられ、ＲＭＳを介して監視されたデータは、患者遠隔デバイスに送信される自動推奨のためのトリガとして使用される。当該推奨システムは、例えば、決定木に従ってプログラミングされる。一例として、医療デバイスが、疼痛を治療するための神経刺激器であり、患者の疼痛スコアを監視することを含む場合、システムは、再プログラミングセッションの５日後に患者の疼痛スコアがまだ上昇している場合、新たなデフォルトプログラムを試みるように患者に自律的に提案することができる。使用される決定木は、患者特有の特性を使用することができ、または設定された決定木に基づく純粋に一般的な推奨を行うことができる。

【0068】

いくつかの例では、アラートは、フロントエンドユーザインタフェースを通して構成可能である。例えば、医師／診療所チームは、アラートおよびトリガ条件のリストを定義してもよい。

【0069】

いくつかの例では、別個のアラートが、製造者サポートチームおよび医師／診療所チームのためにコンフィグレーション可能でありうる。任意選択手段として、個々のユーザは、個々にカスタマイズされたアラートを持たせるように医師／診療所チーム内で定義されてもよい。例えば、医師には温度変化のみが通知されるが、看護師には全てのアラートが通知される。任意選択手段として、製造者チームは、医師／診療所ユーザを支援する手段として、これらのユーザのアラートにアクセスし、変更することができる。任意選択手段として、製造者チーム内で、個々のユーザが個々にカスタマイズされたアラートを取得するように定義されてもよい。例えば、現地の現場担当者には特定のアラートが通知されるだけであるが、社内顧客サポートチームは全てのアラートを受信する。

【0070】

いくつかの例では、アラートは、患者ごとにカスタマイズすることができる。換言すれば、個々のユーザは、個々にカスタマイズされたアラートを取得するように定義されてもよい。

【0071】

いくつかの例では、アラートは、患者グループごとにカスタマイズすることができる。例えば、臨床ユーザは、診療所に関連する全ての患者にわたって一貫したアラートを設定する選択肢を有することができる。例えば、製造者ユーザは、診療所グループ内の全ての患者にわたって一貫したアラートを設定する選択肢を有する。

【0072】

いくつかの例では、アラートの通知をどこに送信するかもコンフィグレーション可能でありうる。例えば、各臨床ユーザは、通知を送信するためのＳＭＳまたは電子メールなどの入力連絡先情報から選択してもよく、またはウェブインタフェース上にのみ通知を表示させることを選択してもよい。任意選択手段として、通知は、診療所の電子健康記録システムに統合されてもよい。

【0073】

任意選択手段として、アラートは、構成設定の一部として高優先度または通常優先度として分類することができる。これらのアラート優先度は、個々のアラート受信者または受信者グループについて、例えば、通知が受信されるかどうか、またどのように受信されるかを制御することができる。

【0074】

任意選択手段として、自律的なトリガは初期的には臨床医によって設定可能であるが、次いでＡＩプロセスが自律的に監視および更新して、個々の患者の必要性のためにプロセスをさらに微調整することができる。

【0075】

製造者サポートチームのためのポータル、すなわち製造者サポートインタフェース
製造者サポートチームインタフェースの機能の中心は、アラートに基づくチケット発行システムでありうる。このチケット発行システムは、製造者サポートユーザ間で共有することができる。

【0076】

いくつかの例では、アラート条件によって形成された新たな「チケット」が、個々の製造者サポートユーザに割り当てられうる。各個々の製造者サポートユーザは、アラートの優先度および／またはアラートが検出されてからの時間および／または臨床アカウントの優先度によって順序付けられた、閲覧および対処のためのチケットの固有のキューを有することができる。

【0077】

いくつかの例では、各チケットは、患者のモニタリングデータ（例えば、収集された生理学的データ、患者報告データ、および／または診断デバイスデータ）、過去のチケットおよびチケットの解決に関連するメモ、および／または任意の関連する診療所の通信を含む個々の患者マスタ記録にリンクさせることができる。

【0078】

いくつかの例では、チケット発行システムはまた、例えば患者または臨床医がサポートセンタに直接に電話する場合、チケットを手動で追加することもできる。

【0079】

いくつかの例では、チケット発行システムは、例えば、評価、患者への連絡、医師への報告、経過観察などを含む状態をチケットに割り当てることを可能にしうる。チケット発行システムは、選択可能なドロップダウンメニュー選択を伴う特定のプロンプトを提供して完了させることによって、サポートユーザが同じタイプのチケットを一貫して処理することを可能にしうる。例えば、「ニーズ評価」状態のチケットは、「医師を紹介する」、「より多くの情報を得るために患者に連絡する」または「介入不要」の選択肢と共に、「評価結果」に応答するためのドロップダウンを含むことができる。

【0080】

チケット発行システムは、チケットの変更ごとに、時間、関与したユーザ、および／または追加されたデータ／メモの履歴記録を追跡することができる。

【0081】

いくつかの例では、製造者サポートチームポータルはまた、アラートに関連付けられているかどうかにかかわらず、モニタリングデータを閲覧する能力を含むことができる。モニタリングデータのフォーマットは、次のうちの１つ以上を含むことができる。
・診察室での経過観察、遠隔経過観察および他のやり取りなどの患者の重要なイベントに関する履歴リストおよび関連するメモを閲覧する能力；
・最新の測定値およびこれらの測定値が取得された日付のスナップショットを閲覧する能力；
・柔軟なトレンド期間ビューでデータのトレンドプロットを閲覧する能力。任意選択手段として、トレンドプロットは、同じトレンド上に２つ以上の変数を含むようにカスタマイズ可能でありうる。例えば、ユーザは、活動および睡眠の質を同じグラフ上に出現させることを選択することができる。種々の期間ビューをサポートすることに加えて、トレンドプロットは、関心のある個々のデータポイント（例えば日付および特定の値）に関する詳細の提供をサポートすることができる。傾向プロットはまた、診察室での経過観察、遠隔経過観察および患者との他のやり取りなどの重要なイベントを視覚的に含むように変更することができる；
・２つ以上の特定の時点における表形式の比較、例えば、１日もしくは特定のＸ日についてのインプラント前の平均値に対する最新Ｘ日間の平均値を閲覧する能力；
・医療専門家インタフェース（例えば診療所ウェブポータル）を介して医師／診療所に送信するためのカスタマイズされた報告を形成する能力。カスタマイズされた報告の選択肢は、どのモニタリングデータが含まれるか、モニタリングデータのどの期間が含まれるか、チケット発行システムからの含まれるべき特定のメモ、ならびに医師の診察室へのカスタマイズ可能な付加的なメモについて選択可能であってよい。

【0082】

医師／診療所のためのポータル、すなわち医療専門家インタフェース
医師／診療所のためのウェブベースまたはアプリベースのポータルは、製造者のポータルに記載された全ての機能、またはその機能のサブセットを含むことができる。一般的に、診療所ポータルは、上記の可能性に加えて、次のうちの１つ以上を含むこともできる。
・どのデータが表示されるか、表示されるデータの順序、および各タイプのデータの期間を含む、診療所のデフォルトビューを定義する能力。
・個々の患者に対して予め定義された報告のリストを定義する能力。これにつき、診療所ユーザは、（例えば遠隔モニタリング請求のためにＥＨＲにおいて使用するために）迅速な選択およびエクスポートが可能である。
・診療所のプリファレンスによって定義される診療所の全患者の主要な転帰データの概要（例えば、３カ月以内、６カ月以内、１２カ月以内および２４カ月以内の全患者のインプラント実施日ごとのリスト、ならびに直近の疼痛スコアおよび活動値）を閲覧する能力。当該概要において、個々の患者を選択肢してより詳細な患者情報を掘り下げることができる。
・例えば、遠隔モニタリング請求目的のために、ユーザが個々の患者を見るシステム内で費やす時間量を追跡する能力。

【0083】

患者および／または介護者のためのポータル
データのサブセットを選択して、患者遠隔デバイス１２上の患者および／または介護者ウェブポータルまたはアプリ上に患者に使いやすいフォーマットで表示することができる。データのサブセットは、診療所、製造者サポートチームのメンバまたは患者自身もしくは介護者ユーザ自身によって行われる選択に従って定義することができる。

【0084】

本開示の特定の態様は、インプラント式デバイスの使用可能期間にわたって効果的な毎日の疼痛緩和および高いＱｏＬを確実にするために、遠隔管理と組み合わされて利用可能な評価のセットである。これらの評価は、予め設定された基準に基づいて自律的に、または臨床医もしくは患者によって手動で、トリガ可能である。

【0085】

一般的に、これらの評価は、遠隔管理からのアクションを、個別に、または異なる評価からの応答の組み合わせに基づいてトリガすることができる。データの科学的アプローチを利用して、どの評価応答または応答のグループが遠隔管理によって行われる特定のアクション（例えば、再プログラミング、臨床来院、紹介）の必要性を最も大きく予測しているかを判定することができる。当該アプローチは、例えば、とりわけ人工ニューラルネットワーク、線形回帰およびロジスティック回帰、クラスタリングならびに次元削減を含みうる。

【0086】

例えば、実行可能な出力をトリガする評価の技術的プロセスは、次のように要約することができる。
１．患者が評価を完了し、結果をＮＳＣ（クラウドデータベース）にアップロードする。
２．カスタムソフトウェアがデータを読み込み、評価結果を入力変数（英数字またはグラフィックデータでありうる）に変換する。
３．ソフトウェアが入力変数（または入力変数から計算された量）を所定の閾値と比較する。
４．入力が閾値を超える場合、カスタムソフトウェアがアラートを作成して伝送する。

【0087】

患者報告遠隔疼痛評価
いくつかの例では、ＲＭＳ１４などの遠隔管理システムまたはコンポーネントは、患者遠隔デバイス１２を介して患者に通知を送信して、慢性疼痛評価を完了することができる。これは、臨床研究の一部として所定のスケジュールで、患者の要求によって、または医師の要求によって、場合により臨床経過観察の来院の前に実施することができる。

【0088】

遠隔疼痛評価の例を以下に記載する。

【0089】

ステップ１：通知が患者遠隔デバイスに送信される。通知の例は、例えば、
・「０（疼痛なし）から１０（最悪の可能性）までで表すとしたら、背中の疼痛はどの程度ですか？」
・「０（疼痛なし）から１０（最悪の可能性）までで表すとしたら、脚の疼痛はどの程度ですか？」
・「０（疼痛なし）から１０（最悪の可能性）までで表すとしたら、体全体の疼痛はどの程度ですか？」
であってよい。

【0090】

ステップ２：患者が評価を完了する。各質問に応答して、患者は、数字を入力するかまたはスライダを移動させて、現在の疼痛スコアを示すことができる。

【0091】

ステップ３：患者が、セキュアなクラウドベースの遠隔管理を介して調査を提出する。これにより、次の潜在的なアクションのうちの１つ以上がトリガ可能となる。
・疼痛スコアが一貫して増大している場合、経過観察用の遠隔来院または対面来院をトリガすることができる。例えば、閾値が定義されうる（例えば、数値評価尺度（ＮＲＳ）が、前月の連続する３日間の平均を取った日次ＮＲＳを３ポイント上回る）。疼痛の増大に関するアラート（例えばテキストメッセージまたは電子メール）が臨床医に送信されてもよい。メッセージは、患者との経過観察をスケジューリングするためのリンクを含むことができる（これによりＮＳＣはアクションが取られたことを知る）が、代替的に、ＡＩが自動的に分析を行い、疼痛スコアの増大を考慮して適切な調整を患者および／または医師に提案することもできる。
・一貫して減少している場合、パラメータの調整をトリガすることができる（低いエネルギはより長い再充電間隔をもたらしうる）。同様のトリガにより、臨床医にアラートを促すことができる。代替手段として、ＡＩが自動的に分析を行い、疼痛スコアの減少を考慮して、適切な調整を患者および／または医師に提案することもできる。
・試験中、疼痛スコアが高い場合、新たな試験治療を送信するための遠隔プログラミングセッションをトリガすることができる。同様のタイプのトリガ、例えば試験の時間制約に起因するＮＲＳスコアの増大が小さい場合にトリガされる低い閾値により、臨床医にアラートが促される。

【0092】

患者報告遠隔睡眠評価
いくつかの例では、遠隔管理は、睡眠品質評価を完了するために、患者遠隔デバイス１２を介して患者に通知を送信することができる。これは、臨床研究の一部として所定のスケジュールで、患者の要求によって、または医師の要求によって、場合により臨床経過観察の来院の前に実施することができる。評価間隔は、例えば、昨晩、先週、または治療を最適化してから１カ月とすることができる。

【0093】

遠隔睡眠評価の例を以下に説明する。

【0094】

ステップ１：通知が患者遠隔デバイスに送信される。通知の例は、例えば、
「０（最悪の可能性）から１０（最良の可能性）までで表すとしたら、昨夜はどれくらい眠れましたか？」
であってよい。

【0095】

ステップ２：患者が評価を完了する。患者は、数字を入力するか、またはスライダを移動させて、前夜の睡眠スコアを示すことができる。

【0096】

ステップ３：患者が、セキュアなクラウドベースの遠隔管理を介して調査を提出する。これにより、次の潜在的なアクションのうちの１つ以上がトリガ可能となる。
・睡眠スコアが一貫して減少している場合（睡眠不足）、疼痛に関連するものであるかどうかを判定するために、経過観察用の遠隔来院もしくは対面来院、または別の評価をトリガすることができる。例えば、閾値が定義されうる（例えば、１週間の平均を取った睡眠スコアが前月の同じ平均を取った睡眠スコアを３ポイント未満下回る）。次いで、睡眠スコアの変化に関するアラート（例えばテキストメッセージまたは電子メール）が臨床医に送信されうる。メッセージは、睡眠不足が疼痛の増大の結果であるかどうかを評価するための追加の調査を患者に送信するためのリンクを含むことができる。代替的に、ＡＩが、睡眠スコアの減少を考慮して調整を自動的に分析し、患者および／または医師に提案することもできる。
・当該評価または他の評価の結果により、経過観察用の遠隔来院または対面来院をトリガすることができる。
・試験中に、新たな試験治療を送信するための遠隔プログラミングセッションを行うことができ、または睡眠の質と疼痛とが相関しているため、その後の疼痛スコアの解釈を支援するよう臨床医にアラートを行うことができる。

【0097】

患者報告遠隔疼痛マップ
いくつかの例では、遠隔管理は、患者遠隔デバイスを介して患者に通知を送信し、慢性疼痛マップを完成させることができる。これは、臨床研究の一部として所定のスケジュールで、患者の要求によって、または医師の要求によって、場合により臨床経過観察の来院の前に実施することができる。理想的には、患者は、試験インプラント、持続的インプラントまたはその両方の開始時に初期疼痛マップを完成している。

【0098】

患者報告遠隔疼痛マップの例を、以下に記載する。

【0099】

ステップ１：患者は、例えば、試験インプラントまたは持続的インプラントの前に、ベースライン慢性疼痛マップを完成させる。例えば、患者は、慢性疼痛を感じる疼痛マップ上の領域を選択することができる。これは、医療専門家用遠隔デバイス上で利用可能なものなどの標準的グラフィカルソフトウェアおよびタッチスクリーンを使用して達成することができる。

【0100】

図４Ａは、例えば、新たな疼痛マップを完成させるために、通知が患者遠隔デバイスに送信されることを示している。当該マップは、以前に報告されたベースライン疼痛を示すための陰影を含む。

【0101】

ステップ２：患者は、現在の疼痛に対応する部位を選択することによって疼痛マップ評価を完了する。

【0102】

図４Ｂは、例えば、現在の疼痛に対応する下肢および前肢における患者の選択部位を示している。

【0103】

ステップ３：患者が、セキュアなクラウドベースの遠隔管理を介して現在の疼痛を提出する。これにより、次の潜在的なアクションのうちの１つ以上がトリガ可能となる。
・疼痛面積が増大している場合、経過観察用の遠隔来院または対面来院をトリガすることができる。例えば、新たな背中の疼痛が、アクティブなコンタクト部を上方へシフトさせることによる再プログラミングを生じさせることが起こりうる。再プログラミングは、ＡＩまたはＡＩのサポートによって行うことができる。
・疼痛面積が減少している場合、パラメータの調整をトリガすることができる（低いエネルギはより長い再充電間隔をもたらしうる）。アラート（例えばテキストまたは電子メール）が臨床医に送信され、疼痛面積の低減を通知することができる。アラートは、患者との経過観察をスケジューリングするためのリンクを含み、代替として、ＡＩは、自動的に分析し、疼痛面積の減少を考慮して、患者および／または医師に調整を提案する。
・試験中、新たな試験治療を送信するための遠隔プログラミングセッションをトリガすることができる。

【0104】

インプラントからの生理学的および診断デバイスデータを遠隔で監視する能力（患者とのやり取りを必要としない）。

【0105】

日常活動レベルのモニタリング
日常活動レベルは、疼痛管理のためのインプラント式デバイスに組み込まれた運動検出回路／加速検知回路から計算されうる。例えば、運動検出回路は、短いエポック（Ｅ１）、例えば１秒の期間における活動を表すカウント（例えば８Ｈｚでサンプリングされた加速度計カウント）を積分することができる。Ｅ１の終わりに、累積カウント値（Ｃｖ）が複数の閾値レベル、例えばＬ０～Ｌ３と比較されうる。レベルＬ０～Ｌ３を表す一連のカウンタＣ０～Ｃ３が実装され、それぞれのカウンタが、対応する閾値範囲Ｃｖ内に入ったことに応じてインクリメントされてもよい。

【0106】

いくつかの例では、より長いエポックＥ２、例えば１０分を定義することができ、Ｃ０～Ｃ３の現在の値を保存記録Ｒｘに保存することができ、その後Ｃ０～Ｃ３は、Ｅ２の倍数の期間でゼロにリセットされ、活動記録Ｒ０…Ｒｘが得られる。例えば、Ｅ２が１０分の場合、１日当たり１４４件の記録がある。

【0107】

活動記録は、インプラント式デバイス内に記憶され、その後ＲＭＳの中央データベースに伝送することができる。

【0108】

いくつかの例では、データベースに記憶された活動記録は、閾値レベルＬ０～Ｌ３に対応する種々の強度レベルＩ０～Ｉ３での患者の活動を表す表示のために処理されうる。

【0109】

いくつかの例では、データベースに記憶された活動記録は、医療処置中の患者の精神衛生の評価における客観的なパフォーマンス基準として利用されうる。

【0110】

いくつかの例では、データベースに記憶された活動記録を利用して、医療処置中の患者のＱｏＬの改善の尺度として、患者によって設定された活動目標を評価することができる。

【0111】

いくつかの例では、データベースに記憶された活動記録を利用して、「高活動」期間および「低活動」期間を特定することができ、これにより、それぞれの期間の所望のカウントの存在または不在から、介護者またはデバイス管理アシスタントに対し、患者を経過観察せよとのアラートをトリガすることができる。

【0112】

いくつかの例では、データベースに記憶された活動記録は、少なくとも１つの「覚醒」期間および少なくとも１つの「睡眠」期間を表す２４時間の期間へとセグメント化可能であり、これは、「覚醒」期間中の予想される期間の活動の存在または活動の強度もしくは期間の改善を評価し、「睡眠」期間中の活動の不在を評価し、「睡眠」期間中の活動の不在から導出される睡眠の質および効率の複合基準を報告するために使用される。

【0113】

いくつかの例では、計算されたベースライン（例えば履歴平均）または傾向（線形または周期的予測モデル）からの実質的な逸脱が介護者へのアラート（電子メール、テキスト、他の通知システム）をトリガするよう、上述した基準および傾向を利用して、ベースラインと比較した、または履歴傾向と比較した患者の活動挙動の変化を識別することができる。アラートは、患者の健康または精神衛生の変化に関する信頼できる挙動由来の指標を表すことができる。例えば、アラートは、疼痛状態の起こりうる変化、または疼痛患者の疼痛に対処する能力を表すことができる。アラートは、患者ケアのアクションをトリガし、または予約を開始するために使用されてもよい。

【0114】

温度モニタリング
少なくとも１つの医療デバイスは、温度センサを収容するように構成可能であり、当該温度センサは、前述したように、温度データを収集して中央サーバに中継する。

【0115】

いくつかの例では、少なくとも１つの医療デバイスは、例えば、インプラント式デバイスの充電中に、その内部温度の読取値が患者の体温を表さない期間を特定する追加の能力を有することができる。この期間の特定に応じて、システムは、この期間に対応する温度読取値が、記録され、エンドユーザ（例えば、医師など）に表示される代表的な患者体温基準に影響を及ぼすことを防止することができる。こうした方法で記録された温度測定値を使用して、ベースライン傾向（平均）を追跡し、このベースライン傾向からの逸脱を特定することができる。この逸脱は、次いで、潜在的に、感染または変化した代謝状態をもたらす他の原因の可能性として、インプラント式デバイスを取り巻く患者の体温が標準的傾向から逸脱したというアラートを介護者に形成することができる。

【0116】

図５を参照すると、遠隔患者モニタリングのための方法２００のフローチャートが示されている。

【0117】

ステップ２１０において、少なくとも１つの医療デバイスは、患者の生理学的データ（例えば、睡眠障害、活動レベルおよび／または発熱を表すコア体温）を自動的に収集する。

【0118】

ステップ２２０において、少なくとも１つの医療デバイスは、収集された患者の生理学的データを、患者遠隔デバイスを介して遠隔モニタリングサーバデバイス（ＲＭＳ）に伝送する。

【0119】

ステップ２３０において、ＲＭＳは、ウェブベースのポータルおよび／またはアプリベースのポータルを含む医療専門家インタフェースを介して、ＲＭＳによって、医療専門家（ＨＣＰ）遠隔デバイスとのインタフェース接続を形成して、医療専門家がＲＭＳ上で収集された患者の生理学的データにアクセスすることを可能にする。

【0120】

このようにして、患者とのやり取りを必要とせずに、医療用インプラントからの生理学的データの連続的な遠隔モニタリングを提供することが可能である。モニタリングデータは、オンデマンドでウェブベースおよび／またはアプリベースのユーザポータルを介して医師に利用可能である。

【0121】

本発明の別の例示的な実施形態では、適切なシステム上で、前述の実施形態のうちの１つによる方法の方法ステップを実行するように適応化されることを特徴とするコンピュータプログラムまたはコンピュータプログラム要素が提供される。

【0122】

したがって、コンピュータプログラム要素は、本発明の一実施形態の一部でもありうるコンピュータユニットに記憶されうる。このコンピューティングユニットは、上述した方法のステップを実行するかまたはその実行を誘導するように適応化可能である。さらに、上述した装置の構成要素を動作させるように適応化されていてもよい。コンピューティングユニットは、自動的に動作するようにかつ／またはユーザの命令を実行するように適応化可能である。コンピュータプログラムは、データプロセッサのワーキングメモリにロードされてもよい。したがって、本発明の方法を実行するためのデータプロセッサが装備されてもよい。

【0123】

本発明のこうした例示的な実施形態は、本発明を初期的に使用するコンピュータプログラムと、更新によって既存のプログラムを、本発明を使用したプログラムへと変更するコンピュータプログラムと、の両方を包含する。

【0124】

さらに、コンピュータプログラム要素は、上述した方法の例示的な実施形態の手順を実行するために必要な全てのステップを提供することができる。

【0125】

本発明のさらなる例示的な実施形態によれば、ＣＤＲＯＭなどのコンピュータ可読媒体が提供され、当該コンピュータ可読媒体は、上記のセクションに説明したコンピュータプログラム要素を記憶している。

【0126】

コンピュータプログラムは、他のハードウェアと共にまたは他のハードウェアの一部として供給される光記憶媒体または固体媒体のような適切な媒体に記憶および／または分散されてもよいが、インターネットまたは他の有線もしくは無線通信システムを介するような他の形式で分散されてもよい。

【0127】

なお、コンピュータプログラムは、ワールドワイドウェブのようなネットワークを介して提供可能であり、こうしたネットワークからデータプロセッサのワーキングメモリにダウンロード可能である。本発明のさらなる例示的な実施形態によれば、コンピュータプログラム要素をダウンロードのために利用可能にするための媒体が提供され、このコンピュータプログラム要素は、本発明の前述の実施形態のうちの１つによる方法を実行するように構成される。

【0128】

本発明の実施形態はそれぞれ異なる主題を参照して説明されていることに留意されたい。特に、いくつかの実施形態は方法タイプの請求項を参照して説明されており、他の実施形態は装置タイプの請求項を参照して説明されている。しかしながら、当業者は、上記および以下の説明から、別段の注記がない限り、１つのタイプの主題に属する特徴の任意の組み合わせに加えて、異なる主題に関する特徴の間の任意の組み合わせも、本出願により開示されていると見なされることを推測するであろう。なお、全ての特徴を組み合わせて、特徴の単純な合計を超える相乗効果を提供することができる。

【0129】

本発明は、図面および前述の説明において詳細に図示および説明したが、こうした図示および説明は例示または例証であって、限定と見なされるべきではない。本発明は、開示の実施形態に限定されない。開示の実施形態に対する他の変形例は、図面、開示および従属請求項の研究から、特許請求の範囲に記載した発明を実施する際に当業者に理解可能でありかつ達成可能である。

【0130】

特許請求の範囲において、「含む（comprising）」なる単語は他の要素またはステップを排除するものではなく、不定冠詞“a”または“an”は複数を排除するものではない。単一のプロセッサまたは他のユニットが特許請求の範囲に記載したいくつかの項目の機能を果たしてもよい。特定の手段が相互に異なる従属請求項に記載されていることは、単なる事実であって、これらの手段の組み合わせが有利に使用されえないことを示すものではない。特許請求の範囲におけるいかなる参照符号も、範囲を限定するものと解釈されるべきではない。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【国際調査報告】