特許 7509766 移植可能医療デバイスからのデータ転送を開始するための方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-24

(45)【発行日】2024-07-02

(54)【発明の名称】移植可能医療デバイスからのデータ転送を開始するための方法

(51)【国際特許分類】

   A61N 1/372 20060101AFI20240625BHJP

   G16H 80/00 20180101ALI20240625BHJP

【ＦＩ】

A61N1/372

G16H80/00

【請求項の数】 13

(21)【出願番号】P 2021522493

(86)(22)【出願日】2019-09-23

(65)【公表番号】

(43)【公表日】2022-01-14

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

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

(87)【国際公開日】2020-04-30

【審査請求日】2022-07-25

(31)【優先権主張番号】62/750,833

(32)【優先日】2018-10-26

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

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

(32)【優先日】2019-03-07

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

(73)【特許権者】

【識別番号】512158181

【氏名又は名称】バイオトロニック エスエー アンド カンパニー カーゲー

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

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

(74)【代理人】

【識別番号】110000855

【氏名又は名称】弁理士法人浅村特許事務所

(72)【発明者】

【氏名】ホートン、ジェイムズ

(72)【発明者】

【氏名】ビルダオ、ハンス － ユルゲン

(72)【発明者】

【氏名】ケッペル、ユルゲン

(72)【発明者】

【氏名】カメンツ、ウベ

(72)【発明者】

【氏名】トレンツ、トーマス

(72)【発明者】

【氏名】シュテファン、エンリコ

(72)【発明者】

【氏名】シュピラー、トーマス

(72)【発明者】

【氏名】ベンツラフ、トールステン

【審査官】槻木澤 昌司

(56)【参考文献】

【文献】米国特許出願公開第２００１／００２３３６０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／０３３１９８０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１０／０２９２５５６（ＵＳ，Ａ１）

【文献】特表２００８－５２１５７６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／００６５０４７（ＵＳ，Ａ１）

【文献】特開２０１６－１２２４２６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０２５９０７２（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６１Ｎ １／００－ １／４４

Ｇ１６Ｈ １０／００－８０／００

(57)【特許請求の範囲】

【請求項1】

移植可能医療デバイス（４１）からのデータ転送を開始するための方法であって、
リモート・デバイス（２、１１）においてリレー・データ要求を生成するステップであって、前記リレー・データ要求が、問合せデータ・セットを作成するための前記移植可能医療デバイス（４１）に対する要求を表すインプラント問合せ要求を含んでいる、生成するステップと、
前記リレー・データ要求を患者デバイス（５）に転送するステップと、
前記インプラント問合せ要求を前記移植可能医療デバイス（４１）に送信するために前記患者デバイス（５）と前記移植可能医療デバイス（４１）との間の通信リンクを確立するステップと、
前記移植可能医療デバイス（４１）から前記患者デバイス（５）にインプラント問合せ応答を転送するステップであって、前記インプラント問合せ応答が、前記問合せデータ・セットを含んでいる前記移植可能医療デバイス（４１）からの応答を表す、転送するステップと、
前記患者デバイス（５）から前記リモート・デバイス（２、１１）に前記インプラント問合せ応答を転送するステップと
を含み、
前記通信リンクが、ＭＩＣＳ（Ｍｅｄｉｃａｌ Ｉｍｐｌａｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ）／ＭｅｄＲａｄｉｏ（Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｒａｄｉｏｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ）／ＭＥＤＳ（Ｍｅｄｉｃａｌ Ｄａｔａ Ｓｅｒｖｉｃｅ）、ＩＳＭ（Ｉｎｄｕｓｔｒｉａｌ， Ｓｃｉｅｎｔｉｆｉｃ ａｎｄ Ｍｅｄｉｃａｌ）又はＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）リンクであり、
前記患者デバイス（５）が、前記インプラント問合せ応答を受信すると、前記リモート・デバイス（２、１１）への通信接続を確立し、前記インプラント問合せ応答を前記リモート・デバイス（２、１１）に転送する、方法。

【請求項2】

前記リレー・データ要求を転送する前記ステップ、前記通信リンクを確立する前記ステップ、前記インプラント問合せ応答を転送する前記ステップ、及び前記インプラント問合せ応答を転送する前記ステップが、ユーザ（１）又は患者（４）によるいかなる行為をも必要とすることなしに、前記リモート・デバイス（２、１１）と、前記患者デバイス（５）と、前記移植可能医療デバイス（４１）とによって実行される、請求項１に記載の方法。

【請求項3】

前記リモート・デバイスがユーザ・デバイス（２）又はサービス・センター（１１）である、請求項１又は２に記載の方法。

【請求項4】

前記リレー・データ要求が、前記インプラント問合せ要求に加えて、前記移植可能医療デバイス（４１）と通信するために前記患者デバイス（５）によって使用されるべき優先度値、インプラント起動トークン、及びインプラント固有キーのうちの少なくとも１つを含んでいる、請求項１から３までのいずれか一項に記載の方法。

【請求項5】

前記リレー・データ要求を前記患者デバイス（５）に転送する前記ステップの前に、前記リモート・デバイス（２、１１）が少なくとも１つの患者デバイス起動要求を前記患者デバイス（５）に送信し、前記少なくとも１つの患者デバイス起動要求が、前記リモート・デバイスに接続するための前記患者デバイス（５）に対する要求を表す、請求項１から４までのいずれか一項に記載の方法。

【請求項6】

前記少なくとも１つの患者デバイス起動要求を受信すると、前記患者デバイス（５）が前記リモート・デバイス（２、１１）への通信接続（７、１０）を確立し、そうすると、前記リモート・デバイス（２、１１）が、前記通信接続（７、１０）を使用して前記リレー・データ要求を前記患者デバイス（５）に転送する、請求項５に記載の方法。

【請求項7】

前記通信接続（７、１０）がモバイル・ネットワーク接続として確立される、請求項６に記載の方法。

【請求項8】

前記患者デバイス（５）と前記移植可能医療デバイス（４１）との間の前記通信リンクを確立する前記ステップが、前記患者デバイス（５）によって、少なくとも１つのインプラント起動要求を前記移植可能医療デバイス（４１）に送信することを含む、請求項１から７までのいずれか一項に記載の方法。

【請求項9】

前記移植可能医療デバイス（４１）が、前記少なくとも１つのインプラント起動要求を受信するためのタイム・ウィンドウを一定の間隔で与える、請求項８に記載の方法。

【請求項10】

前記患者デバイス（５）と前記移植可能医療デバイス（４１）との間の前記通信リンクは、前記少なくとも１つのインプラント起動要求が前記移植可能医療デバイス（４１）によって受信されたときに前記移植可能医療デバイス（４１）によって確立される、請求項８又は９に記載の方法。

【請求項11】

前記移植可能医療デバイス（４１）が、前記インプラント問合せ要求を受信すると、前記インプラント問合せ応答中に含まれるべき前記問合せデータ・セットを生成するために、前記インプラント問合せ要求において定義されているようにデータを収集する、請求項１から１０までのいずれか一項に記載の方法。

【請求項12】

前記移植可能医療デバイス（４１）は、前記通信リンクが前に終了している場合に、前記インプラント問合せ応答を前記患者デバイス（５）に転送するための前記通信リンクを再確立する、請求項１から１１までのいずれか一項に記載の方法。

【請求項13】

移植可能医療デバイス（４１）からのデータ転送を開始するためのシステムであって、前記システムは、リモート・デバイス（２、１１）と、患者デバイス（５）と、移植可能医療デバイス（４１）とを備え、
前記リモート・デバイス（２、１１）が、リレー・データ要求を生成するように構成され、前記リレー・データ要求が、問合せデータ・セットを作成するための前記移植可能医療デバイス（４１）に対する要求を表すインプラント問合せ要求を含んでおり、
前記リモート・デバイスが、さらに、前記リレー・データ要求を前記患者デバイス（５）に転送するように構成され、
前記患者デバイス（５）及び前記移植可能医療デバイス（４１）が、前記インプラント問合せ要求を前記移植可能医療デバイス（４１）に送信するために、前記患者デバイス（５）と前記移植可能医療デバイス（４１）との間の通信リンクを確立するために協働するように構成され、
前記移植可能医療デバイス（４１）が、前記患者デバイス（５）にインプラント問合せ応答を転送するように構成され、前記インプラント問合せ応答が、前記問合せデータ・セットを含んでいる前記移植可能医療デバイス（４１）からの応答を表し、
前記患者デバイス（５）が、前記患者デバイス（５）から前記リモート・デバイス（２、１１）に前記インプラント問合せ応答を転送するように構成され、
前記通信リンクが、ＭＩＣＳ（Ｍｅｄｉｃａｌ Ｉｍｐｌａｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ）／ＭｅｄＲａｄｉｏ（Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｒａｄｉｏｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ）／ＭＥＤＳ（Ｍｅｄｉｃａｌ Ｄａｔａ Ｓｅｒｖｉｃｅ）、ＩＳＭ（Ｉｎｄｕｓｔｒｉａｌ， Ｓｃｉｅｎｔｉｆｉｃ ａｎｄ Ｍｅｄｉｃａｌ）又はＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）リンクであり、
前記患者デバイス（５）が、前記インプラント問合せ応答を受信すると、前記リモート・デバイス（２、１１）への通信接続を確立し、前記インプラント問合せ応答を前記リモート・デバイス（２、１１）に転送する、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移植可能医療デバイスからのデータ転送を開始するための方法、及び移植可能医療デバイスからのデータ転送を開始するためのシステムに関する。

【背景技術】

【0002】

当技術分野で知られている移植可能医療デバイスは、データを交換するために様々な外部デバイスと結合され得る。たとえば、移植可能医療デバイスは、臨床医が移植可能医療デバイスの設定を調整することを可能にするプログラミング・デバイスと結合され得る。結合のために、たとえば、移植可能医療デバイスの上に配置される磁気スイッチが使用され得る。磁気スイッチは永久磁石を有し、永久磁石の磁界は、移植可能医療デバイスによって検出され、移植可能医療デバイスを、移植可能医療デバイスがプログラミング・デバイスに結合された結合状態に入れる。

【0003】

さらに、ワイヤレス監視システムにおいて、患者トランシーバとも呼ばれる患者デバイスは、移植可能医療デバイスの近くに位置するとき、移植可能医療デバイスにワイヤレスで接続することが知られている。そのような患者デバイスは、たとえば、移植可能医療デバイスから患者データを一定の間隔で（たとえば毎日）ダウンロードし、それをサービス・センターに転送するために使用される。サービス・センターにおいて、データは前処理され、必要な場合、ユーザ、たとえば専門臨床医に転送される。

【0004】

患者デバイスには、たとえば、移植可能医療デバイスとの通信リンクを確立するために、関連付けられた移植可能医療デバイスを休止状態からアクティブ状態に切り替える起動（wake-up）機能が装備され得る。患者デバイスは、たとえば、無線周波数（ＲＦ：radio frequency）レンジにおいて起動信号を発し、起動信号は移植可能医療デバイスによって受信され、そうすると、移植可能医療デバイスが患者デバイスとのデータ通信のためにアクティブ化される。

【0005】

移植可能医療デバイスを起動する一般的な起動機能の潜在的欠点は、患者デバイスの通信方式及び方法を実装する第三者デバイスによって移植可能医療デバイスへの望まれないアクセスが潜在的に得られ得ることである。特に、ペースメーカー及び移植可能心臓除細動器（cardioverter defibrillator）など、生命維持に不可欠な治療機能をもつ移植可能医療デバイスの分野では、サイバー・セキュリティへの需要が一般的に高い。

【0006】

別の潜在的欠点は、移植可能医療デバイスが、移植可能医療デバイスのバッテリー・レベルを考慮することなしに起動させられ、通信チャネルが確立されることである。これは、エネルギー資源が優先度の高い治療機能のためにもはや利用可能でなくなるという結果をもたらし得る。たとえば、第三者による攻撃によって故意に、又はソフトウェア・エラーによって移植可能医療デバイスを頻繁に起動することによって移植可能医療デバイスのバッテリーを使い果たす危険がある。

【0007】

さらに、患者が移植可能医療デバイスによるデータの記録を開始する可能性を与えるシステムが存在する。たとえば、ペースメーカー患者が気分がすぐれない場合、たとえば、患者が目まいがするか、又は頻脈を覚える場合、患者は、たとえばリモート・コントロールを作動させることによって、移植可能医療デバイスによるＥＣＧ（electrocardiogram）の記録をトリガすることができる。このようにして記録されたデータは、直接臨床医に、又はサービス・センターに転送され、今度、たとえば、臨床医における検査、又は患者デバイスの自動クエリを介した検査中に、移植可能医療デバイスからデータが取り出される。

【0008】

一般に、移植可能パルス生成器（ＩＰＧ：implantable pulse generator）など、移植可能医療デバイスからリアルタイム・ステータス・データにアクセスするプロセスは、今のところ、診療所内フォローアップにおいて収集された問合せデータ、又は、限定された例では、患者によってトリガされた報告に限定される。これらのプロセスには臨床医管理がない。いくつかの移植可能医療デバイスは、患者が臨床医からリモートにいるときに問合せをトリガするための手段を有するが、患者は、一般に、リモート問合せをトリガすることが可能なアクターとして関与して、臨床医は、現在、自分自身でリモート問合せをトリガする能力が限定されている。

【0009】

典型的なワークフローにおいて、現在入手可能ないくつかの製品によって与えられるように、症候を訴える患者は、診療所に報告を送ることを望み得るか、又は診療所は、患者が報告を生成することを要求し得る。いずれの場合も、患者は、問合せをトリガするために患者デバイスを開始するプロセスに従う。これは、患者が、移植された医療デバイスの上に問合せワンドを配置するか、又は利用可能な場合、患者デバイスが、ワイヤレス手段を介して移植された医療デバイスに接続することができるかのいずれかを必要とする。移植された医療デバイスは、問合せを処理し、患者デバイスにデータを送信する。患者は、次いで、問合せメッセージを、たとえばサービス・センターに送信するために、患者デバイスをトリガするか、又は、利用可能な場合、患者デバイスが自動的にサービス・センターへの送信を開始する。

【0010】

したがって、そのようなソリューションは、臨床医が、データ収集を、場合によってはデータ送信をも開始することを患者に依拠しなければならず、したがって、データがどのように又はいつキャプチャされるかを管理していないという意味で、患者トリガ型（patient-triggered）である。さらに、診療所は、インプラントから送信された情報の受信を制御することができないので、臨床医は、データが受信された時間にデータの受信に応答することが必ずしも可能であるとは限らない。これは、データの診療所レビューに関して最適でないワークフローにつながる。患者によってトリガされたデータの送信と、診療所による受信及びレビューとは互いに切り離されているので、診療所が適時に応答しない場合、潜在的に、責任が問われる状況が引き起こされ得る。

【0011】

文献米国特許第７，３６９，８９７号は、移植可能なスティミュレータ、インターフェース・ユニットと、変形ＰＤＡ（personal digital assistant）又は携帯電話などのモバイル・デバイスとを備える、神経組織に電気パルスを与えるための移植されたスティミュレータを遠隔制御する方法及びシステムを開示している。

【先行技術文献】

【特許文献】

【0012】

【文献】米国特許第７，３６９，８９７号

【発明の概要】

【発明が解決しようとする課題】

【0013】

本発明の目的は、移植可能医療デバイスによって記録された患者パラメータが、それによって患者又は移植可能医療デバイスからリモートにいる臨床医にとって利用可能にされる、移植可能医療デバイスからのデータ転送を開始するための方法及びシステムを提供することである。

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

【0014】

この目的は、請求項１に記載の特徴を備える方法と、請求項１５に記載の特徴を備えるシステムとによって達成される。

【0015】

本方法によれば、移植可能医療デバイスからのデータ転送を開始するために、リレー・データ要求がリモート・デバイス（たとえばユーザ・デバイス又はサービス・センター）において生成され、リレー・データ要求は、問合せデータ・セットを作成するための移植可能医療デバイスに対する要求を表すインプラント問合せ要求を含んでいる。リレー・データ要求は患者デバイスに転送される。前記インプラント問合せ要求を移植可能医療デバイスに送信するために、患者デバイスと移植可能医療デバイスとの間に通信リンクが確立される。インプラント問合せ応答が移植可能医療デバイスから患者デバイスに転送され、インプラント問合せ応答は、前記問合せデータ・セットを含んでいる移植可能医療デバイスからの応答を表す。インプラント問合せ応答は患者デバイスからリモート・デバイスに転送される。

【0016】

本方法によって、一実施例では、（患者デバイスが移植可能医療デバイスに十分に近く、接続性（たとえばネットワーク接続性）を有する限り）患者対話が必要とされないので、データ収集の制御を改善すること、診療所ワークフローを改善すること、及び／又は所望のケアを実現するための患者への移動需要を低減することが可能になる、移植可能医療デバイスの問合せのための方式が提供される。

【0017】

本明細書で説明する技術は、患者トリガ型の問合せが可能な移植可能医療デバイスでも機能し得ることに留意されたい。

【0018】

本方法は、病院にいる臨床医など、ユーザが、リモート・デバイスを使用して、患者に移植された医療デバイスに問い合わせることを可能にする。これのために、ユーザは、たとえばモバイル・デバイス、ラップトップ・コンピュータ、タブレット・コンピュータ、固定パーソナル・コンピュータなどのユーザ・デバイスを使用して、リモート・デバイスにおいてリレー・データ要求の生成をトリガし得、ユーザは、ユーザ・デバイス自体の上でリレー・データ要求の生成をトリガし得るか、又はリレー・データ要求がサービス・センターにおいて生成されるように、ユーザ・デバイスを介してサービス・センターにアクセスし得る。

【0019】

リモート・デバイスにおいて、たとえばユーザ・デバイスにおいて又はサービス・センターにおいて、リレー・データ要求が生成されると、リレー・データ要求が患者デバイスに送られ、患者デバイスは、リレー・データ要求を受信すると、患者デバイスと移植可能医療デバイスとの間に通信リンクが確立されるように移植可能医療デバイスとの通信を開始する。

【0020】

リレー・データ要求を生成するとき、リモート・デバイスはまた、リレー・データ要求の一部として患者デバイスに転送されるインプラント問合せ要求を生成する。患者デバイスは、リレー・データ要求からインプラント問合せ要求を抽出し、インプラント問合せ要求を移植可能医療デバイスに転送し、移植可能医療デバイスは、このようにして、インプラント問合せ要求中に含まれる仕様に従ってデータを収集させられ、データの収集は、潜在的に、測定値の伝達、又は、たとえば前の測定値から以前に取得されたデータの収集を含む。

【0021】

インプラント問合せ要求は、リモート・デバイスにおいて問合せをトリガするユーザ、たとえば臨床医の仕様に従って、リモート・デバイスにおいて生成されるので、移植可能医療デバイスにおけるデータの収集は、リモート・デバイスを介してユーザによってトリガされ、制御される。移植可能医療デバイスは、したがって、インプラント問合せ要求を介して、移植可能医療デバイスにデータの特定のセットを収集させる指定された要求を取得して、問合せデータ・セットを生成し、問合せデータ・セットは、たとえば、患者の不満及び患者に存在する物理的状態に鑑みて診断を促進するように調整される。

【0022】

データが移植可能医療デバイスによって収集されると、移植可能医療デバイスは、データをインプラント問合せ応答中に含め、インプラント問合せ応答を患者デバイスに転送し、患者デバイスは、ユーザがデータを検査することが可能になるように、インプラント問合せ応答をリモート・デバイスに転送する。

【0023】

一実施例では、リレー・データ要求を転送するステップ、通信リンクを確立するステップ、インプラント問合せ要求を転送するステップ、及びインプラント問合せ応答を転送するステップが、ユーザ及び／又は患者によるいかなる行為をも必要とすることなしに、リモート・デバイスと、患者デバイスと、移植可能医療デバイスとによって実行される。特に、ユーザは、リモート・デバイスにおいて問合せをトリガした後に、リレー・データ要求と、インプラント問合せ要求と、インプラント問合せ応答とを生成するコンテキストにおいてさらなる行動を取る必要がない。患者は、一実施例では、たとえば、問合せプロセスにまったく参加しなくてもよく、患者は、問合せが行われることさえ知らない可能性がある。

【0024】

たとえば、患者デバイスが、患者に移植された医療デバイスと通信することが可能であるような位置にすでにある場合、リアルタイム問合せが患者の関与なしに行われ得る。患者デバイスが、リレー・データ要求を受信する時間に、患者に移植された医療デバイスと通信することが可能であるような位置にない場合、通信リンクの確立及びインプラント問合せ要求の転送は、この場合も患者の意識的関与なしに、（たとえば夜間に）患者デバイスが移植可能医療デバイスと通信することが可能になるまで遅延され得る。

【0025】

一実施例では、リレー・データ要求は、インプラント問合せ要求に加えて、移植可能医療デバイスと通信するために患者デバイスによって使用されるべき優先度値、インプラント起動トークン、及びインプラント固有キー（又はいくつかのインプラント固有キー）のうちの少なくとも１つを含み得る。優先度値は、本明細書では、問合せの優先度を示し、たとえば、「不急」、「中間」、「急」、「特急」及び「リアルタイム」の値を有し得る。優先度値に従って、リレー・データ要求及びインプラント問合せ要求は、リモート・デバイス、患者デバイス、及び移植可能医療デバイスにおいて処理される。インプラント起動トークンは、インプラント問合せ要求ごとに異なり、移植可能医療デバイスが要求の信ぴょう性（authenticity）及び要求するユーザの承認（authorization）を検証することを可能にし得る。患者デバイスと移植可能医療デバイスとの間の通信（たとえば守秘、信ぴょう性及び／又は承認）を保障するために１つ又は複数のキーが使用され得る。患者デバイス及び／又は移植可能医療デバイスが、非対称暗号のために必要な処理能力を有しない場合、患者デバイスは、リレー・データ要求中に含まれているインプラント固有キーを使用し得る。

【0026】

一実施例では、リレー・データ要求を患者デバイスに転送する前に、リモート・デバイスは、少なくとも１つの患者デバイス起動要求を患者デバイスに送信し得る。患者デバイスとリモート・デバイスとの間の通信が可能になるように、患者デバイス起動要求によって、患者デバイスはアクティブ化され、リモート・デバイスへの通信接続が確立される。

【0027】

通信接続が確立されると、リモート・デバイスは、患者デバイスがそれの中に含まれるリレー・データ要求とインプラント問合せ要求とを受信するように、通信接続を使用してリレー・データ要求を患者デバイスに転送し得る。

【0028】

患者デバイス起動要求は、たとえばモバイル・ネットワークを使用して、たとえばワイヤレス通信チャネルを介して送られ得る。たとえば、患者デバイス起動要求はテキスト・メッセージとして（たとえば、ショート・メッセージング・サービス、すなわちＳＭＳに従って）送られ得る。

【0029】

一実施例では、リモート・デバイスは、特に、たとえばＳＭＳの場合のように、送信技術が信頼できる受信フィードバック方式を含まない場合、患者デバイスが患者デバイス起動要求を受信しないリスクを低減するために、たとえば患者デバイス起動要求のバースト中で、多様な患者デバイス起動要求を送り得る。

【0030】

リモート・デバイスは患者デバイス起動要求を概略的順序で送り得る。たとえば、リモート・デバイスは、たとえば１分と２０分との間、たとえば１０分と１５分との間続く、第１の持続時間の間、繰り返される様式で、第１の起動シーケンス中で患者デバイス起動要求を送り得る。患者デバイスが、この初期の第１の起動シーケンス中に起動させられ得ない場合、患者デバイス起動要求の送信は、休止され、次いで、たとえば、３０分と２時間との間の休止持続時間をもつ休止後、改めて開始される。次いで、患者デバイス起動要求が、たとえば、１分と１０分との間、たとえば５分と８分との間の第２の持続時間をもつ第２の起動シーケンス中に送られる。これは、患者デバイスが正常にアクティブ化されるまで繰り返され得る。３日後、そのときまで不成功の場合、起動試みは終了される。

【0031】

患者デバイス起動要求は、患者デバイスの起動試みごとに異なる患者デバイス起動トークンを含み得る。患者デバイス起動トークンは、患者デバイスに送られるべき各リレー・データ要求について患者デバイスが１回のみ接続することが確かにされるように、患者デバイスが、それがすでに起動試みに応答したかどうかを決定することを可能にする。

【0032】

一実施例では、リモート・デバイスと患者デバイスとの間のデータ通信のために患者デバイスによって確立される通信接続は、ワイヤレス接続、たとえばモバイル・ネットワーク接続を使用して確立される。データ通信のために、たとえばＴＣＰプロトコルに基づくモバイル通信プロトコルが使用され得る。有効なリモート・デバイスと有効な患者デバイスとの間の接続のみが確立され、通信が秘密であり、第三者によって改ざんされ得ないように、通信プロトコルによって、たとえば、好適な暗号化、認証（authentication）及び／又は承認機構を適用することによって、セキュアな接続が確立され得る。

【0033】

リレー・データ要求中に含まれる優先度値に基づいて、患者デバイスは、リモート・デバイスとの他の接続を終了し得、特に、高い優先度を示す優先度値のために、移植可能医療デバイスとの通信リンクをすぐに確立する。このようにして、移植可能医療デバイスの問合せを優先させるために、たとえば進行中のファームウェア更新など、遅い動作がスキップされるか又は遅延させられ得る。

【0034】

患者デバイスが、高い優先度をもつリレー・データ要求、及びリレー・データ要求中に含まれるインプラント問合せ要求を受信すると、患者デバイスは患者デバイスと移植可能医療デバイスとの間の通信リンクを確立させる。このために、患者デバイスは、たとえば、１つ又は複数のインプラント起動要求を移植可能医療デバイスに送信し、それにより移植可能医療デバイスがアクティブ化され、前記通信リンクを確立し得る。通信リンクを介して、次いで、患者デバイスは、インプラント問合せ要求を移植可能医療デバイスに転送し、そうすると、移植可能医療デバイスは、インプラント問合せ応答中に含まれるべき前記問合せデータ・セットを生成するために、インプラント問合せ要求において定義されているようにデータを収集する。

【0035】

インプラント起動要求は、たとえばＭＩＣＳ（Medical Implant Communication Service）、ＭｅｄＲａｄｉｏ（Medical Device Radiocommunication Service）、ＭＥＤＳ（Medical Data Service）、ＩＳＭ（Industrial, Scientific and Medical）又はＢＬＥ（Bluetooth Low Energy）通信を使用して送られ得る。同様に、インプラント起動要求に応答して確立される通信リンクは、ＭＩＣＳ、ＭｅｄＲａｄｉｏ、ＭＥＤＳ、ＩＳＭ又はＢＬＥリンクであり得る。通信リンクは、リモート・デバイスから患者デバイスに転送されるリレー・データ要求中に含まれるキーを使用して、（たとえば、守秘、信ぴょう性及び／又は承認を）保障され得る。

【0036】

たとえば、一実施例では、ＭＩＣＳ／ＭｅｄＲａｄｉｏ／ＭＥＤＳ方式中の最も干渉が少ないチャネルが使用され得る。

【0037】

インプラント起動要求はインプラント起動トークンと一緒に送信され得る。インプラント起動トークンを使用して、移植可能医療デバイスは、リプレイ・アタックに対してそれ自体を保護し得、また、患者デバイスの承認、リモート・デバイスの承認、及び／又は要求するユーザの承認が移植可能医療デバイスとの通信中に行われ得る。たとえば、患者起動トークンは、移植可能医療デバイスによって選定されたトークン値（たとえば乱数によって初期化され、各問合せの後に増分されるカウンタ）を含み得る。トークン値は、たとえば毎晩、移植可能医療デバイスとリモート・デバイスとの間の定期報告の間に、移植可能医療デバイスからリモート・デバイスに定期の様式で送信される。問合せを開始するとき、リモート・デバイスは、トークン値を含んでいるインプラント起動トークンを作成し、それを、たとえば、要求の信ぴょう性及び／又は要求するユーザの承認を証明するためのキーを用いて保障する。インプラント起動トークンは、リレー・データ要求の一部として患者デバイスに送られ、患者デバイスはインプラント起動トークンを移植可能医療デバイスに転送し、移植可能医療デバイスは、送信された起動トークンの有効性を検証する。一実施例では、移植可能医療デバイスは、起動トークンが有効である場合のみ、患者デバイスとの通信リンクを確立するが、これは、送信されたトークン値が、移植医療可能デバイスによって予想された値に一致し（たとえば、カウンタ値の場合、同値）、要求の信ぴょう性、及び／又は患者デバイス、リモート・デバイス及び／又は要求するユーザの承認が、リモート・デバイス及び／又は患者デバイスによって使用されるキーに基づいて正常に検証され得る（たとえば、トークンがリモート・デバイスによって署名されており、及び／又は、トークン、並びに現在の通信リンクのために使用されるＭＩＣＳ／ＭｅｄＲａｄｉｏ／ＭＥＤＳ方式のチャネルをカバーするメッセージ認証コードが患者デバイスによって生成されている）ことを意味する。

【0038】

移植可能医療デバイスによるデータの収集は、インプラント問合せ要求中で指定された通りに行われる。データが収集されると、問合せデータ・セットが作成され、インプラント問合せ応答中に含まれ、インプラント問合せ応答は、患者デバイスに送られ、患者デバイスを介してリモート・デバイスに送られる。

【0039】

データの収集は、移植可能医療デバイスによって実行される測定を含み得る。データの収集は、加えて又は代替的に、進行中のＩＥＧＭ（intracardiac electrogram）記録又は統計データなど、移植可能医療デバイス中にすでに記憶されているデータのアセンブルを含み得る。

【0040】

インプラント問合せ要求によってトリガされたアクティビティが、通信プロトコルによってサポートされる持続時間内にある場合、患者デバイスと移植可能医療デバイスとの間の通信リンクは維持され得、データ収集の後に、インプラント統合応答が患者デバイスに送られる。移植可能医療デバイスのアクティビティの持続時間が、通信プロトコルによってサポートされる時間よりも長い場合、通信リンクの再確立の後に、インプラント問合せ応答が患者デバイスに転送されるように、接続は、インプラント問合せ要求を送った後に終了され、データの収集が完了した後に再確立される。

【0041】

インプラント問合せ応答を受信すると、一実施例では、患者デバイスは移植可能医療デバイスとの接続を終了し、たとえばモバイル接続を使用してリモート・デバイスへの接続を開始する。患者デバイスとリモート・デバイスとの間の通信接続は、したがって、一実施例では、改めて確立され、インプラント問合せ応答がリモート・デバイスに転送される。

【0042】

患者デバイスと移植可能医療デバイスとの間の通信リンクと同様に、インプラント問合せ応答をリモート・デバイスに転送するために、通信プロトコルが、問合せのコンテキストにおける移植可能医療デバイスのアクティビティのために必要とされる持続時間にわたって接続をサポートし、患者デバイスと移植可能医療デバイスとの間の通信リンクと干渉しない場合、リレー・データ要求をリモート・デバイスから患者デバイスに送るために使用されたものと同じ通信接続が使用され得る。

【0043】

インプラント問合せ応答を受信すると、リモート・デバイス、たとえばサービス・センターは、次いで、インプラント問合せ応答中に含まれているデータに基づいて新しい患者ステータスを計算し得る。

【0044】

リモート・デバイスが、たとえば、ユーザがウェブサイトなどを使用して接続することができるサービス・センターである場合、問合せに関するデータが利用可能であるように、リモート・デバイスはユーザに通知し得、そうすると、ユーザは、リモート・デバイスに接続することができ、データを検査することができる。ユーザの通知は、たとえば、ＳＭＳメッセージ又は電子メールなど、テキスト・メッセージによって行われ得る。

【0045】

移植可能医療デバイスからのデータ転送を開始するためのシステムは、リモート・デバイスと、患者デバイスと、移植可能医療デバイスとを備え得る。リモート・デバイスは、リレー・データ要求を生成するように構成され、リレー・データ要求は、問合せデータ・セットを作成するための移植可能医療デバイスに対する要求を表すインプラント問合せ要求を含んでいる。リモート・デバイスは、さらに、リレー・データ要求を患者デバイスに転送するように構成される。患者デバイス及び移植可能医療デバイスは、前記インプラント問合せ要求を移植可能医療デバイスに送信するために、患者デバイスと移植可能医療デバイスとの間の通信リンクを確立するために協働するように構成される。移植可能医療デバイスは、患者デバイスにインプラント問合せ応答を転送するように構成され、インプラント問合せ応答は、前記問合せデータ・セットを含んでいる移植可能医療デバイスからの応答を表す。患者デバイスは、患者デバイスからのインプラント問合せ応答をリモート・デバイスに転送するように構成される。

【0046】

上記によって、リアルタイムの、移植可能医療デバイスからリモートでトリガされるデータ更新のためのシステム及び方法が提供され得る。本システムは、移植可能医療デバイス（たとえばＩＰＧ）と、患者デバイス（患者トランシーバと呼ばれることもある）と、リモート・デバイス、たとえば中央処理システム（及び随意に管理システム）を備え、臨床医ユーザ・インターフェース（たとえばコンピュータ、タブレット又はノートブック）を介したアクセスを可能にするサービス・センターとを備える。本システムは、たとえば、リモート分析のための患者の移植可能医療デバイスの現在のデータのリアルタイム問合せをトリガするために使用される。本発明は、ＩＰＧ医療デバイス・アプリケーション、たとえばＳＣＳ、ＣＲＭなどの複数の分野において使用され得る。

【0047】

一実施例では、患者トリガ型ではなく、インプラントの問合せのための臨床医トリガ型要求が可能になる（しかし、このスキーマは、患者トリガ型問合せが可能なインプラントでも動作し得る）。問合せの臨床医トリガ型要求は、一実施例では、臨床医ユーザ・インターフェースからリモートで開始され得、データは、複数のユーザ・インターフェースにおいてリモートで同時に閲覧され得る。通信のシーケンスにおける１つ又は複数の（たとえばすべての）ステップは、セキュアな通信を保証し、各構成要素間の通信が完了していることを保証するために自動データ永続性及び通信反復を行う「ハンドシェイク」処理を伴い得る。

【0048】

本方法及びシステムは、第三者による攻撃を受ける危険がなく、移植可能医療デバイスのバッテリーのためにエネルギー節約になり得る、患者デバイスと移植可能医療デバイスとの間のデータ送信を保証するものである。

【0049】

別の一般的な態様では、（ａ）リモート・デバイスを介してユーザによってインプラント問合せ要求をトリガするステップと、（ｂ）インプラント問合せ要求をリレー・データ要求の一部としてリモート・デバイスから患者デバイスに転送するステップと、（ｃ）患者デバイスと患者の移植可能医療デバイスとの間の通信リンクを確立するステップと、（ｄ）問合せデータ・セットを含んでいるインプラント問合せ応答を移植可能医療デバイスから患者デバイスに転送するステップと、（ｅ）インプラント問合せ応答を患者デバイスからリモート・デバイスに転送するステップとを含む、移植可能医療デバイスとリモート・デバイスとの間でデータを転送するためのプロシージャが提案される。本明細書では、ステップ（ｂ）～（ｅ）は、ユーザ又は患者の任意の行動を必要とせずにリモート・デバイスと患者デバイスと移植可能医療デバイスとによって実行される。

【0050】

ユーザは、たとえば、担当する臨床医、又は、臨床又は医療業務の訓練された人員である。

【0051】

リモート・デバイスは、たとえば、インターネット接続をもつコンピュータ、又は十分な処理能力とユーザによる動作のためのディスプレイとをもつ任意の他の好適なデバイスである。リモート・デバイスはまた、ウェブサイトなどを使用してユーザによってアクセスされ得るサービス・センターであり得る。

【0052】

プロシージャは、移植可能医療デバイスによって記録された患者パラメータを、インプラント問合せ要求がユーザによって開始された患者又は移植可能医療デバイスからリモートにいるユーザにとって記録直後に利用可能にする。プロシージャ全体は、一実施例では、セッション中に行われ得、すなわち、初めから終わりまで、ユーザはリモート・デバイスと連絡又は対話することができる。たとえば、リモート・デバイスのスクリーン上のアニメーション化されたグラフィックは、たとえばプログレス・バー又は同様のものによって、プロセスの進行を可視化することができる。

【0053】

ユーザがインプラント問合せ要求をトリガした時間から、インプラント問合せ応答がリモート・デバイスにおいて受信されるまで、一実施例では、ユーザ又は患者による入力は必要とされない。すべてのデータ転送ステップは、リモート・デバイス、患者デバイス、又は移植可能医療デバイスによって自動的に実行される。これは、たとえば、ユーザ又は患者によるさらなる入力ステップ又は確認ステップによる遅延を防ぐ。

【0054】

一実施例では、ステップ（ｂ）は、インプラント問合せ要求をサービス・センターを介してユーザ・デバイスから患者デバイスへのリレー・データ要求の一部として転送することを伴う。代替又は追加として、ステップ（ｄ）は、インプラント問合せ応答をサービス・センターを介して患者デバイスからユーザ・デバイスに転送することを含み得る。要求及び／又は応答はサービス・センターによって前処理され、及び／又は記憶される。

【0055】

随意に、一態様によれば、ステップ（ａ）は、患者がユーザに連絡する先行するステップを有する。

【0056】

たとえば、患者が異常（たとえば、移植可能医療デバイスがペースメーカーである場合、目まい又は頻脈）を覚えた場合、患者はユーザに連絡することができる。この目的で、患者は、ユーザを呼び出すか、ショート・メッセージを書くか、又は患者デバイス上の機能をアクティブ化することができる。ユーザとの直接連絡において、患者は彼／彼女の病状を述べ、そうすると、ユーザは適切な処置を開始する。病状がただならない場合、ユーザは、たとえば、医療緊急サービスに直接通知することができる。顕著でない病状の場合、ユーザは、何も行動を取ることなしに患者を安心させ得る。本発明によれば、すべての他のケースにおいて、ユーザは、本発明によるプロシージャを介して、患者の移植可能医療デバイスにデータ転送を要求し、それを短い時間内にリモート・デバイス上で呼び出すことができる。このようにして、患者が異常を感じる状況では、ユーザとの直接連絡がある。ユーザは、状況に関するすべての情報がユーザにとって利用可能であるように、移植可能医療デバイス・データを直接取り出す。さらに、直接連絡によって、ユーザは、患者デバイスの範囲中にとどまるように患者に指示し、患者に心理的支援を与えることができる。

【0057】

さらに、一実施例によれば、ステップ（ｃ）は、患者デバイスが、少なくとも１つのインプラント起動要求を移植可能医療デバイスに送り、移植可能医療デバイスが、前記要求を受信するためのタイム・ウィンドウを一定の間隔で与えることを含む。このようにして、移植可能医療デバイスは、患者デバイスからのインプラント起動要求があるかどうかを確かめるために、タイム・ウィンドウ内に「リッスン」する。

【0058】

本発明の態様によれば、間隔は１０秒から１０分までの間のどこかであり、及び／又はタイム・ウィンドウは０．１ミリ秒から５ミリ秒までの持続時間を有する。たとえば、間隔は、１０秒、２０秒、３０秒、４０秒、５０秒、１分、１．５分、２分、３分、４分、５分、６分、７分、８分、９分又は１０分であり、及び／又はタイム・ウィンドウは０．５ミリ秒又は１ミリ秒の持続時間を有する。間隔の長さ及びタイム・ウィンドウの持続時間は、本発明によるプロシージャの合計持続時間がユーザ及び患者にとって許容できる限度内にとどまり、移植可能医療デバイスのバッテリーが消耗しすぎないように、インプラント起動要求が妥当な時間期間内に移植可能医療デバイスによって受信されるように、選定されなければならない。

【0059】

一態様によれば、患者デバイスと移植可能医療デバイスとの間の通信リンクは、インプラント起動要求がタイム・ウィンドウ内に受信されたときに、移植可能医療デバイスによって確立される。一実施例によれば、移植可能医療デバイスは、通信リンクを確立することを拒否するか又は遅延させ得る。通信リンクを拒否するか又は遅延させることによって、移植可能医療デバイスが、たとえばそれのバッテリー・ステータス又はデバイス機能の優先度付けに応じて、通信リンクが好適であるかどうかを決定することができることが達成され得る。たとえば、バッテリー・レベルが低く、及び／又は他のインプラント機能がより高い優先度を与えられている場合（たとえば治療機能）、移植可能医療デバイスは、通信リンクを確立しないことを決定し得るか、又は通信リンクの確立を延期し得る。このようにして、移植可能医療デバイスのエネルギー管理は移植可能医療デバイス自体によって制御され得る。

【0060】

一態様によれば、インプラント問合せ要求を受信すると、移植可能医療デバイスは新しいデータの測定を実行し、新しいデータは、少なくとも１つの患者パラメータ、インプラント・パラメータ、又は別のパラメータに関する。測定において取得された新しいデータは、患者デバイスに転送されるべきインプラント問合せ応答に追加され得る。このようにして、ユーザは、患者パラメータ、インプラント・パラメータ、及び／又は別のパラメータの現在測定されているデータを受信する。ユーザは、一実施例では、あらかじめ新しいデータの測定がそれについて実行されるべきパラメータを選択することができる。これにより、ユーザは、患者によって述べられた病状に潜在的に関係するパラメータを選択することが可能になる。ペースメーカー又は移植可能な心臓除細動器をもつ心臓病患者が頻脈を訴える場合、ユーザは、たとえば、心電図（ＥＣＧ）を再測定させることを選定することができる。

【0061】

インプラント問合せ応答は、一実施例では、少なくとも、以下のパラメータ、すなわち、患者パラメータ、技術インプラント・パラメータ、若しくは別のパラメータ、又はこれらの組合せのデータを含む。

【0062】

患者パラメータは、一実施例では、心電図と、インピーダンス心電図（impedance cardiogram）と、脳波図（ＥＥＧ：electroencephalogram））と、アクティビティ・データと、血圧測定値と、生化学的又は他の知覚データと、記録された測定データ及び／又は治療送達及び／又は治療効率の統計又は概観と、記憶された患者及び個人のデータとのうちの少なくとも１つを含み得る。

【0063】

インプラント・パラメータは、一実施例では、バッテリー電圧と、電極インピーダンスと、信号振幅と、データ送信統計と、バッテリー消耗又はバックアップ・モードなど特殊なデバイス状態に関する統計と、移植可能医療デバイスの現在のプログラミング設定とのうちの少なくとも１つを含み得る。

【0064】

他のパラメータは、一実施例では、外部センサー及びウェアラブルなど、移植可能医療デバイスによってキャプチャされた情報ユニットからのさらなるデータ、自動的に検出されたＭＲＩ検査など、行われた診断又は治療手順に関するデータ、移植可能医療デバイスによって記録されたボイス・メッセージなど、患者によってもたらされた他の情報のうちの少なくとも１つを含み得る

【0065】

一態様によれば、データ及び／又は通信の少なくとも１つの送信（transmission）／受信／送信（sending）がワイヤレスである。固定電話ネットワーク又はモバイル無線ネットワークなど、リモート通信のためのネットワーク・システムは、ユーザ・デバイスから直接患者デバイスに、又はユーザ・デバイスからサービス・センターを介して患者デバイスに要求を送信するために使用され得る。患者デバイスと移植可能医療デバイスとの間の通信及びデータ交換は、医療インプラント通信サービス（ＭＩＣＳ）、ＭｅｄＲａｄｉｏ（医療デバイス無線通信サービス）、ＭＥＤＳ（医療データサービス）、産業科学医療（ＩＳＭ）、又はＢｌｕｅｔｏｏｔｈ低エネルギー（ＢＬＥ）周波数帯域を使用して実行され得る。ＭＩＣＳ／ＭｅｄＲａｄｉｏ／ＭＥＤＳ及びＩＳＭ帯域は、医療データ送信専用の特殊な周波数帯域であり、したがって通信と干渉する干渉信号がほとんどないので、有利である。

【0066】

さらに、他の態様によれば、ステップ（ａ）～（ｅ）、すなわちインプラント問合せ要求をトリガすることからインプラント問合せ応答までの実行は、リモート・デバイス上のユーザにとって利用可能であり、ユーザと患者との間のセッションの許容できる時間枠内にとどまらなければならず、ユーザ及び患者の経験に基づく最大５～１５分がそのような時間枠を超えない。

【0067】

ステップ（ａ）～（ｅ）は、本発明のさらなる形態に従って、２つ以上の移植可能医療デバイスに対してリモート・デバイスを介して実行され得ることが想到できる。このようにして、ユーザは、並列プロセスによって診療所又は医院における時間管理を最適化するために、複数の移植可能医療デバイスに対してデータを転送するための複数の要求をトリガすることができる。

【0068】

態様によれば、リモート・デバイスと患者デバイスと移植可能医療デバイスとを備えるシステムが、本発明によるプロシージャを実行するために提案される。

【0069】

一実施例によれば、移植可能医療デバイスの平均電流消費量は、本発明によるプロシージャを可能にするための機能を与え、実行することによって、３Ｖバッテリーを使用するとき、最大０．１μＡ、０．５μＡ、１μＡ、２μＡ、３μＡ、４μＡ、５μＡ又は１０μＡになる。平均電流消費量はデバイス寿命を著しく短縮しない。

【0070】

代替又は追加として、移植可能医療デバイスのデバイス・ランタイムは、発明的プロセスを可能にするための機能を与え、実行することによって、合計デバイス・ランタイムの最大１％、２％、５％、又は１０％だけ短縮される。

【0071】

代替的に又は加えて、移植可能医療デバイスのデバイス寿命は、本発明によるプロシージャを可能にするための機能を与え、実行することによって、１０年の予想合計デバイス寿命に対して最大１、２、３又は６カ月だけ短縮される。

【0072】

本明細書で説明する方法及びシステムによって、移植可能医療デバイスは、患者とのやりとりがないか又は少なくとも減少した、臨床医による問合せの改善された方法を提供しながら、デバイス・バッテリーの合計実行時間に対して許容できるエネルギー・コストで動作させられ得る。

【0073】

移植可能医療デバイスは、たとえば、ペースメーカー、移植可能な心臓除細動器、心臓再同期療法（ＣＲＴ：Cardiac Resynchronization Therapy））デバイス、脳ペースメーカー、脊髄スティミュレータ（spinal cord stimulator）、治療機能なしの心臓監視デバイス、又は患者パラメータを記録するための機能をもつ任意の他のタイプの移植可能デバイスであり得る。

【0074】

続いて、図に示される実施例を参照しながら、本発明の概念についてより詳細に説明する。ここで、図面の簡単な説明は以下の通りである。

【図面の簡単な説明】

【0075】

【図1】データを移植可能医療デバイス（ＩＭＤ：implantable medical device））から直接ユーザ・デバイスに転送するためのシステムの実施例の概略図を示す図である。

【図2】サービス・センターを介してデータを移植可能医療デバイス（ＩＭＤ）からユーザ・デバイスに転送するためのシステムの別の実施例の概略図を示す図である。

【図3】問合せのコンテキストにおける、サービス・センターの形態のリモート・デバイスと患者デバイスと移植可能医療デバイスとの間の通信の概略図を示す図である。

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

【0076】

図１は、データを移植可能医療デバイス４１からユーザ・デバイス２の形態のリモート・デバイスに転送するためのシステムの実施例を概略的に示す。

【0077】

図１の実施例において、一般的なセットアップ内で、ユーザ１、たとえば、病院８にいる臨床医は、臨床医のユーザ・デバイス２を介して移植可能医療デバイス４１に対するインプラント問合せ要求をトリガする。トリガに応答して、患者デバイス５へのワイヤレス接続１０が確立される。患者デバイス５と患者４の移植可能医療デバイス４１との間の通信接続が確立され、インプラント問合せ要求が、最初にユーザ・デバイス２から患者デバイス５に転送され、次いで患者デバイス５から移植可能医療デバイス４１に転送される。インプラント問合せ要求に応答して、インプラント問合せ応答が、最初に移植可能医療デバイス４１から患者デバイス５に転送され、次いで患者デバイス５からユーザ・デバイス２に転送される。たとえば、ユーザ１は病院８の心臓専門医（cardiologist）であり、患者４は自宅９にいる。

【0078】

患者４は、以前にユーザ１と連絡を取ったことがあり、たとえば電話でユーザ１に何らかの病状を通知していることがある。代替的に、患者４は、以前にユーザ１と連絡を取ったことがなく、ユーザ・デバイス２と患者デバイス５と移植可能医療デバイス４１との間のデータ交換に気づいてすらいない可能性がある。

【0079】

図２は、サービス・センター１１を介してデータを移植可能医療デバイス４１からユーザ・デバイス２に転送するためのシステムの別の実施例を概略的に示す。図２のシステムは、たとえば、ユーザ・デバイス２を介してインプラント問合せ要求をトリガするためにサービス・センター１１への接続６を確立することによって、ユーザ１がユーザ・デバイス２によってサービス・センター１１にアクセスするという点で、図１のシステムと異なる。したがって、インプラント問合せ要求がサービス・センター１１によって生成され、ワイヤレス接続７を介して患者ユニット５に送信される。移植可能医療デバイス４１から患者デバイス５に送られたインプラント問合せ応答は、次いでサービス・センター１１に返信され、サービス・センター１１によってユーザ・デバイス２に転送され得るか、又は、たとえばウェブサイトなどを使用して、サービス・センター１１においてユーザ・デバイス２を介してユーザ１によって閲覧され得る。外部サービス・センター１１は要求情報とデータ・パケットの両方を前処理し、及び／又は記憶することができる。

【0080】

次に図３を参照しながら、例示的な一実施例に従って、移植可能医療デバイス４１からのデータ転送を開始するための方式について説明する。この方式では、移植可能医療デバイス４１（以後手短にインプラントとも呼ぶ）からのデータがそれに転送されるリモート・デバイスがサービス・センター１１によって実装され、サービス・センター１１にデータが転送され、サービス・センター１１においてユーザ１は、自分のユーザ・デバイス２を介して検査及び診断のためにデータを閲覧し得る。

【0081】

図３の方式内で、一実施例では、インプラント４１の問合せを可能にするために様々なメッセージが利用され得る。本明細書で、リレー・データ要求（ＲＤＱ：relay data request）は、インプラント４１にデータを中継するための患者デバイス５に対する要求を表し、患者デバイス起動要求（ＰＷＱ：patient device wake-up request）は、サービス・センター１１に接続する患者デバイス５に対する要求を表し、インプラント起動要求（ＩＷＱ：implant wake-up request）は、患者デバイス５に接続するインプラント４１に対する要求を表し、インプラント問合せ要求（ＩＩＱ：implant interrogation request）は、問合せデータ・セットを作成するためのインプラント４１に対する要求を表し、インプラント問合せ応答（ＩＩＳ：implant interrogation response）は、問合せデータ・セットを含んでいるインプラント４１からの応答を表す。

【0082】

図３に示されているように本方式内で、ユーザ１、たとえば臨床医は、ユーザ・デバイス２上でたとえばサービス・センター１１のウェブサイトを介して、たとえばボタン・クリックを実行することによって、インプラント問合せ要求をトリガし得る（ステップＳ１）。

【0083】

サービス・センター１１は、以前に受信したメッセージに基づいて、インプラント４１に対するメッセージを中継している患者デバイス５を（たとえば、通し番号を使用して）決定する（ステップＳ２）。サービス・センター１１は、選定された患者デバイス５に対するリレー・データ要求（ＲＤＱ）をアセンブルする。リレー・データ要求は、インプラント問合せ要求（ＩＩＱ）と、優先度値と、インプラント起動トークンと、インプラント起動要求（ＩＷＱ）を保証するために患者デバイス５によって使用されるべきインプラント固有キーとを含んでいる。インプラント起動トークンは起動試みごとに異なる。

【0084】

本明細書でリレー・データ要求に割り当てられた優先度は２つの目的を果たす。優先度の実効値は、サービス・センター１１からインプラント４１への途中でキュー中により優先度の低い値を有する他のメッセージよりもメッセージを優先するために使用される。さらに、優先度値は、潜在的に要求の送達を高速化するために使用される。その目的のために、可能な優先度値の範囲は、いくつかのカテゴリー、たとえば「不急」、「中間」、「急」、「特急」及び「リアルタイム」に分割され得る。たとえば、カテゴリー「特急」からの優先度値がサービス・センター１１によって選定される。このカテゴリーからの優先度は患者デバイス５とインプラント４１の両方の起動をトリガする。

【0085】

優先度値／カテゴリーによって要求に優先度を付けることに加えて、これ以降、サービス・センター１１はまた、進行中の問合せがない患者デバイス５又はインプラント４１からのメッセージよりも高い優先度をもつ、アドレス指定された患者デバイス５及びインプラント４１から受信するすべてのメッセージを処理する。

【0086】

カテゴリー、たとえば「特急」の優先度の場合、サービス・センター１１は、たとえばＳＭＳ又はワイヤレス送信を介して、選定された患者デバイス５に患者デバイス起動要求（ＰＷＱ）のバーストを送る（ステップＳ３）。（たとえば、ＳＭＳの場合のように）輸送媒体／技術が信頼できる受信フィードバックをサポートしない場合、２つ以上の患者デバイス起動要求を送ることにより、完全な損失の危険が低減し得る。患者デバイス起動要求は、起動のために使用される通信チャネル、たとえばＳＭＳよりも信頼できるセキュアなチャネルを介してサービス・センター１１に接続するために患者デバイス５をトリガする働きをする。患者デバイス起動要求は、起動試みごとに異なる患者デバイス起動トークンを含んでいる。

【0087】

患者デバイス５が、予想された患者デバイス起動トークンをもつ患者デバイス起動要求を受信するとすぐに、患者デバイス５は、たとえば、モバイル・ネットワークを介してサービス・センター１１に接続する（ステップＳ４）。接続はセキュアなプロトコル（たとえば、ＴＣＰの上のプロプライエタリなプロトコル）を使用する。患者デバイス起動トークンは、患者デバイス５がすでに所与の起動試みに応答したかどうかを患者デバイス５が決定することを可能にする。これにより、患者デバイス５が各リレー・データ要求について１回のみ接続することが確実になる。

【0088】

ステップＳ４において確立された接続を使用して、サービス・センター１１はリレー・データ要求を患者デバイス５に転送する（ステップＳ５）。リレー・データ要求中に含まれている優先度がカテゴリー「特急」である場合、患者デバイス５は、ファームウェア更新などのような潜在的に不急の動作をスキップしながら、（他の目的のためにも働き得る）サービス・センター１１へのすべての現在の接続を直ちに終了するようにトリガされる。

【0089】

さらに、優先度が「特急」である場合、患者デバイス５は、たとえばリレー・データ要求からのキーで保障された、インプラント起動トークンを含んでいる、ＭＩＣＳ／ＭｅｄＲａｄｉｏ／ＭＥＤＳを介して、インプラント起動要求（インプラント起動要求）を送ることを直ちに開始する（ステップＳ６）。インプラント４１が、有効なインプラント起動トークンを含んでいるインプラント起動要求を受信するとすぐに、（たとえば、（随意にプロプライエタリなプロトコルを使用して）ＭＩＣＳ／ＭｅｄＲａｄｉｏ／ＭＥＤＳを介して、又はＢｌｕｅｔｏｏｔｈを介して）患者デバイス５とインプラント４１との間の接続が確立される。インプラント起動トークンは、インプラント４１が、起動要求の信ぴょう性、及びユーザ１／サービス・センター１１／患者デバイス５の承認を検証し、それがすでに所与の起動試みに応答したかどうかを決定することを可能にする。これにより、インプラント４１が各インプラント問合せ要求に１回のみ応答することが確実になる。

【0090】

ステップＳ６において確立された接続中に、リレー・データ要求中に含まれているインプラント問合せ要求がインプラント４１に転送される（ステップＳ７）。インプラント問合せ要求によってトリガされたインプラント４１内でのアクティビティが、通信プロトコルによってサポートされる時間よりも長くかかる場合、接続は終了される。他の場合、接続は開いたままにされる。

【0091】

インプラント４１は、インプラント問合せ要求（ＩＩＱ）中に定義されているようにデータを収集し、ステップＳ７中に接続が開いたままでなかった場合、患者デバイス５への接続を再確立する（ステップＳ８）。

【0092】

ステップＳ６において確立された、又はステップＳ８において再確立された接続中に、インプラント４１は、それのインプラント問合せ応答（ＩＩＳ）を患者デバイス５に転送する（ステップＳ９）。

【0093】

インプラント問合せ応答を受信すると、患者デバイス５は、接続を終了し、たとえばモバイル・ネットワークを介してサービス・センター１１への接続を直ちに開始する（ステップＳ１０）。

【0094】

ステップＳ１０において確立された接続中に、患者デバイス５は、インプラント問合せ応答をサービス・センター１１に転送する（ステップＳ１１）。

【0095】

サービス・センター１１は、インプラント問合せ応答中に含まれているデータに基づいて新しい患者ステータスを計算する（ステップＳ１２）。この処理は、ステップＳ２における患者デバイス５及びインプラント４１からのメッセージの優先度付けにより促進される。今後、アドレス指定された患者デバイス５又はインプラント４１から受信されたメッセージは（問合せのための次の要求まで）それ以上優先度を付けられない。

【0096】

サービス・センター１１は、たとえばＳＭＳ及び／又は電子メールを介して、インプラント問合せ応答の受信についてユーザ１に通知する（ステップＳ１３）。

【0097】

ユーザ１は、ここで、最新の患者ステータスを閲覧することができる（ステップＳ１４）。

【0098】

本システム及び／又は本方法は、（患者の送信機がインプラント４１に十分近く、ネットワーク接続性を有する限り）患者対話を伴わないか、又は極めて限定された患者対話を伴う問合せを提供し得る。さらに、データ収集の制御が改善され得る。さらに、診療所ワークフローが改善され得、及び／又は所望のケアを実現するための患者への移動需要が低減され得る。利点のうちの１つ又は複数は、通常のシステムの外部に追加の患者機器を必要とすることなしに生じ得る。

【0099】

本システムに関して開示されている特徴は本方法にも適用し得、逆もまた同様である。

【符号の説明】

【0100】

１ ユーザ
２ ユーザ・デバイス（リモート・デバイス）
４ 患者
５ 患者デバイス
６ 通信リンク（ワイヤード又はワイヤレス接続）
７ 通信リンク（ワイヤレス接続）
８ 病院
９ 自宅
１０ 通信リンク（ワイヤレス接続）
１１ サービス・センター（リモート・デバイス）
４１ 移植可能医療デバイス（ＩＭＤ）
Ｓ１～Ｓ１４ ステップ

【図1】

【図2】

【図3】