JP2022529886A - 医療デバイス及び医療デバイスに遠隔アクセスするための方法 - Google Patents

Abstract

本開示は、医療デバイスの分野に関し、より具体的に、自動医療デバイスに遠隔アクセスするための技術に関する。第１態様によれば、本開示は、医療処置を実行するように構成された医療デバイス（１０）に遠隔アクセスするための方法に関する。本方法は、遠隔通信プロセス（ＰＣＯＭＭ）が、医療デバイスに遠隔アクセスするための少なくとも１つのアクセス基準を構成するステップ（Ｓ１）と、医療デバイスと遠隔システムとの間のセキュアな接続を確立するステップ（Ｓ２）とを有する。本方法は、遠隔通信プロセス（ＰＣＯＭＭ）が、遠隔システムから、１つ以上の医療プロセスにアクセスすることの要求を受信するステップ（Ｓ３）と、医療デバイス（１０）に遠隔アクセスするための構成された少なくとも１つのアクセス基準を要求が満たすと、要求を１つ以上の医療プロセスに転送するステップ（Ｓ５ａ）と、をさらに有する。

Description

本開示は医療デバイスの分野に関し、より具体的には、セキュアな方法で自動医療デバイスを遠隔アクセスするための技術に関する。

自動医療デバイスは、単独で使用されても組み合わせて使用されても、製造者によって医療目的で人間又は動物に使用されることが意図された機械である。このような医療目的は、病気、怪我、又はハンディキャップの診断、予防、観察、治療又は緩和を含んでもよい。

自動医療デバイスは、ヘルスケア部門でしばしば使用され、安全かつ効率的であることを保証するために厳格な規制の枠組みの対象となる。

一般に、自動医療デバイスは、健康的意義を有しうる誤動作のリスクを軽減するように慎重に設計される必要がある複雑なシステムであるソフトウェア・システム（例えば、医療デバイスにインストールされるもの）によって動作される。ソフトウェア・システムは典型的に、医療治療又は医療診断のような医療処置を医療デバイスに実行させるように構成されたソフトウェアを備える。また、ソフトウェア・システムは、典型的に、保守及びサービス機能のような、医療処置に関連するサポート手順を実行するように構成されたソフトウェアを含む。いくつかの状況では、ソフトウェア更新を実行するため、又はテストを実行するため、又はサービス目的で、医療デバイスを遠隔から制御又はアクセスする、例えば医療デバイスを再構成することが望ましい場合がある。

しかし、遠隔システムに医療デバイスへのアクセスを提供することは、外部パーティが通信を傍受し、又は他のように干渉し、医療デバイスの制御を引き継ごうとするかもしれないので、リスクを伴いうる。また、遠隔アクセス可能な医療デバイスは、到来する要求が非常に高速で受信される過負荷攻撃を受けるかもしれず、これは、意図された又は指定された医療処置及び／又は関連するサポート手順を重要な内部コンポーネントが実行することを妨げる。したがって、医療デバイスへの遠隔アクセスを導入することは、医療デバイスを種々のタイプのサイバー攻撃（すなわち、許可されていないアクセス）に対して脆弱にすることによって、患者の安全性を危険にさらすかもしれない。

さらに、医療処置及び関連するサポート手順を実行している間の自動医療デバイスの性能が典型的には影響を受けないでいる必要があるので、医療デバイスにサイバーセキュリティを導入することは典型的には困難である。したがって、遠隔からアクセス可能な自動医療デバイスのサイバーセキュリティを扱う改善された方法が必要とされている。

したがって、医療デバイスに遠隔アクセスすることに関連する従来技術の制限を回避することが本開示の目的である。特に、医療デバイスにおいてサイバーセキュリティを提供すると同時に、医療デバイスによって実行される医療処置及び関連するサポート手順の安全性及び性能を保証するシステム、方法、及び装置を提供することが目的である。

第１態様によれば、本開示は、医療処置を実行するように構成された医療デバイスに遠隔アクセスするための方法に関し、医療デバイスは、ソフトウェア・システムによって制御される。ソフトウェア・システムは、医療デバイスの動作に関与する１つ以上の医療プロセスと、１つ以上の医療プロセスとは別個の遠隔通信プロセスとを含む。遠隔通信プロセスは、医療デバイスと１つ以上の遠隔システムとの間の通信を管理するように構成される。さらに、１つ以上の医療プロセスは、遠隔通信プロセスよりも高いプライオリティを有する。本方法は、遠隔通信プロセスが、医療デバイスに遠隔アクセスするための少なくとも１つのアクセス基準を構成するステップと、医療デバイスと遠隔システムとの間のセキュアな接続を確立するステップとを実行することを含む。本方法は、遠隔通信プロセスが、遠隔システムから、１つ以上の医療プロセスにアクセスすることの要求を受信するステップと、医療デバイスに遠隔アクセスするための構成された少なくとも１つのアクセス基準を要求が満たすと、要求を１つ以上の医療プロセスに転送するステップとを実行することをさらに含む。いくつかの実施形態において、遠隔通信プロセス及び１つ以上の医療プロセスが別個のものであることは、それらが別個のメモリ空間、個別のプロセス状態を有し、及び／又はプロセス間通信を使用して通信していることを意味する。したがって、１つ（又は場合によっては複数）の別個のプロセスにおいて遠隔システムとの通信に関する機能を分離することによって、通信のセキュリティ処理を単純化し、強化できる。遠隔要求の受信及び構文解析はかなりの処理リソース（例えば、プロセッサ・パワー及びメモリ）を必要とするかもしれないので、着信遠隔要求は潜在的に、重要な内部コンポーネントがそれらの作業を行うこと、例えば、医療処置又は関連するサポート・プロセスを実行することを枯渇しうる。しかし、それ自体の実行コンテキストで動作し、他の実行コンテキストよりも低いプライオリティを有する遠隔通信プロセスを有することによって、重要な内部コンポーネントが枯渇するリスクが軽減される。

さらに、機能を分離することによって、コードを重複させる必要性がなくなる。機能を分離しない例では、医療デバイスの異なる内部コンポーネントは、ネットワーク通信自体を処理するために適切なコードで構成されなければならない。さらに、１つの（又は少数の）プロセスにおいて分離されている場合にサイバーセキュリティ機能をテストすることがより容易でありうるので、品質（すなわち、セキュリティのレベル）が改善されうる。

さらに、本方法は、遠隔通信プロセスにおいて外部通信のための新たなプロトコルが追加されうるので、改善された移植性を提供する。

遠隔通信機能の分離は例えば、サイバーセキュリティ要件が満たされているかどうかを分析する場合に、ソフトウェア開発の観点からも有益である。セキュリティ要件のバリデーションのために、レビュアは、ソフトウェア・システムの限定された部分の設計を考慮するだけでよいかもしれない。

いくつかの実施形態において、本方法は、医療デバイスをスタート・アップすることを含む。スタート・アップ中、１つ以上の医療プロセスにアクセスすることのすべての要求は、遠隔通信プロセスによってブロックされる。したがって、スタート・アップ中に医療デバイスを攻撃することは不可能である。

いくつかの実施形態において、本方法は、構成された少なくとも１つのアクセス基準を満たさない、１つ以上の医療プロセスにアクセスすることの要求をブロックすることを含む。したがって、望ましくない（又は未知の／認識されていない）要求がブロックされてもよく、それによってサイバー攻撃を軽減する。したがって、望まれていない及び有効にされていない要求が処理されないので、望まれている及び有効にされている要求のみを受諾することによって、システム負荷が低減されうる。言い換えれば、遠隔通信プロセスは、望まれていない要求をフィルタリングするフィルタ（又はファイアウォール）として動作する。

いくつかの実施形態において、少なくとも１つのアクセス基準は、要求の送信者又は発信元が認証されることを含む。これにより、未知のシステムからの要求がブロックされる。

いくつかの実施形態において、少なくとも１つのアクセス基準は、要求が、許可された要求タイプを有することを含む。これにより、未知の又は無効にされたアクセス・タイプがブロックされる。

いくつかの実施形態において、少なくとも１つのアクセス基準は、要求が、許可された機能に関することを含む。これにより、遠隔アクセスが無効にされている機能へアクセスすることの要求がブロックされる。

いくつかの実施形態において、少なくとも１つのアクセス基準は、単位時間当たりに受信される要求の数が閾値を超えないことを含む。したがって、潜在的に１つ以上の医療プロセスを枯渇させることを意味する着信要求が非常に高速で受信されるならば、それらはこの速度で１つ以上の医療プロセスに転送されない。非常に高速で受信された要求をブロックすることによって、重要な内部コンポーネントが枯渇するリスクが軽減されうる。

いくつかの実施形態において、少なくとも１つのアクセス基準は、異なる送信者、要求のタイプ、及び／又は機能についての個別の規則を含む。これにより、どの要求を許可するかを正確に制御できる。

いくつかの実施形態において、構成することは、オペレータから構成データを受信し、及び／又は医療デバイスに記憶された構成データを読み出し、受信された構成データに基づいて少なくとも１つのアクセス基準を構成することとを含む。したがって、オペレータは、医療デバイスがどのように、誰によってアクセスされうるかを制御しうる。あるいは、例えば、製造者又はオーナーによって医療デバイスに事前にロードされた所定の構成によって、アクセスが制御されてもよい。

いくつかの実施形態において、転送することは、医療デバイスと遠隔システムとの間の通信に使用されるプロトコルとは異なる及び／又はそれから独立したプロトコルを使用して要求を転送することを含む。したがって、遠隔システムによって使用されるネットワークは、物理的に別個のものであり、医療デバイスの内部ネットワークにルーティング不可能である。

いくつかの実施形態において、医療デバイスは、プロセッサの集合を含み、１つ以上の医療プロセス及び遠隔通信プロセスは両方とも、プロセッサの集合うちの同じ１つ以上のプロセッサによって実行される。したがって、遠隔通信は、遠隔通信が分離されたコンテキストで実行されている限り、安全上重要な患者データを扱う同じプロセッサによって扱われてもよい。医療デバイスで使用される高度なプロセッサはしばしば、遠隔システムとの通信のためのサポートを内蔵している。したがって、遠隔通信を扱うために追加のプロセッサが必要とされないので、提案される解決策は、追加のハードウェアを追加することなく実現されうる。

いくつかの実施形態において、１つ以上の医療プロセスにアクセスすることの要求は、医療デバイスを遠隔制御することの要求と、医療デバイス内のソフトウェアを更新することの要求と、医療デバイスの時刻を設定することの要求と、医療デバイスからログ・データを受信することの要求と、医療デバイスの構成を更新することの要求と、及び／又は医療デバイスのクレデンシャルを更新することの要求とを含む。したがって、提案される技術は、種々のタイプの要求に適用されてもよい。

いくつかの実施形態において、本方法は、１つ以上の医療プロセスに、遠隔通信プロセスよりも、医療デバイスの処理能力に対して高いプライオリティを与えることを含む。したがって、医療処置及び関連するサポート手順の動作は、常に最高のプライオリティを有する。

第２態様によれば、本開示は、医療処置を実行するための医療デバイスに関し、医療デバイスは、プロセッサの集合と、プロセッサの集合による実行のためのソフトウェア・システムを記憶するメモリ・ユニットの集合と、１つ以上の遠隔システムとの通信を可能にする通信インタフェースとを備える。ソフトウェア・システムは、プロセッサの集合によって実行される場合に、医療処置及び関連するサポート手順を実行するように医療デバイスを動作させるように構成される。ソフトウェア・システムは、医療デバイスの動作に関与する１つ以上の医療プロセスと、１つ以上の医療プロセスとは別個の遠隔通信プロセスとを含む。遠隔通信プロセスは、医療デバイスと１つ以上の遠隔システムとの間の通信を管理するように構成され、１つ以上の医療プロセスは、遠隔通信プロセスよりも高いプライオリティを有する。さらに、ソフトウェア・システムは、プロセッサの集合によって実行される場合に、第１態様による方法を実行する。

第３態様によれば、本開示は、医療処置を実行するための医療デバイスに遠隔アクセスするためのソフトウェア・システムを備えるコンピュータ可読媒体に関する。ソフトウェア・システムは、医療デバイスの動作に関与する１つ以上の医療プロセスと、１つ以上の医療プロセスとは別個の遠隔通信プロセスとを含む。遠隔通信プロセスは、医療デバイスと１つ以上の遠隔システムとの間の通信を管理するように構成される。さらに、１つ以上の医療プロセスは、遠隔通信プロセスよりも高いプライオリティを有する。さらに、ソフトウェア・システムは、医療デバイスのプロセッサの集合によって実行される場合に、第１態様による方法を実行する。

、 、 開示された技術の実施形態を実施してもよい医療デバイスを説明する。 、 図１ａ～図１ｃの医療デバイスの任意のもの制御システムをより詳細に説明する。 医療デバイスに遠隔アクセスするための例示的なソフトウェア・システムを概念的に説明する。 医療デバイスに遠隔アクセスするための方法のフローチャートである。 １つの例示的な実装による、提案された方法を実行する場合の医療デバイスのソフトウェア・システムのプロセス間の内部シグナリングのシーケンス図である。

ここで、本発明のいくつかの、しかしすべてではない実施形態が示されている添付の図面を参照して、本発明の実施形態が以下により十分に説明される。実際に、本発明の解決策は、多くの異なる形態で実施されてもよく、本書に記載の実施形態に限定されるものと解釈すべきではなく、むしろ、これらの実施形態は、この開示が、適用可能な法的要件を満たしうるように提供される。同様の参照符号は全体を通して同様の要素を指す。

この開示は、遠隔システムとの通信を管理する医療デバイスにおけるすべての対話及び機能が、本書で遠隔通信プロセスと呼ばれる、別個の文脈で実行される別個のソフトウェア・プロセス（又はソフトウェア・コンポーネント）においてアーキテクチャ的に分離されることを提案する。これは、医療アプリケーションを扱う内部ソフトウェア・プロセスからサイバーセキュリティの詳細を抽象化し、また、内部ソフトウェア・プロセスが通信プロトコルの詳細を知りえなくする。遠隔通信プロセス・コンポーネントはまた、所望の有効にされた要求のみを受諾することによって、システム負荷を低減しうる。例えば、いくつかの実施形態において、遠隔システムからの要求は、医療デバイスにとって安全な速度でのみサービスされ、医療デバイスの内部ソフトウェア・プロセスに転送される。無効化された要求及び通信の拒否は例えば、医療デバイスのファイアウォールを防御的に構成することによって行われ、これは、性能のニーズを低減する効率的な設計である。したがって、提案される遠隔通信プロセスは、１つ以上の医療プロセスの残りのものから分離され、低いプライオリティを有する点で、標準インタフェースとは異なる。遠隔通信プロセスは、医療処置の実行に関与せず、基本的に遠隔通信のみを扱う。すべての着信要求は、遠隔通信プロセスを通過する必要がある。その結果、たとえ遠隔通信プロセスが攻撃され、害されても、医療処置は影響を受けない。

提案される技術をより良く理解するために、いくつかの例示的な医療デバイスが最初に記載される。医療デバイスは、オプションで１つ以上の他の医療デバイスと組み合わせて、人間又は動物の対象に関して医療処置を実行するように動作するように構成された自動装置又は機械である。本書で使用されるように、医療処置は、病気、怪我、又はハンディキャップの診断、予防、観察、処置若しくは緩和、又はそれらの検出のための観察のうちの１つ以上を含んでもよい。

図１ａは、例えば血液透析、血液透析濾過、血液濾過、又は単離限外濾過のような腎機能代替療法の一部として、体外血液処置を行う医療処置に関与してもよい２つの例示的な医療デバイス１０、１０´を説明する。１０で示される医療デバイスは血液処理装置であり、これは、例えば血管アクセスにおいて、対象１００の循環系に接続するための血液採取ライン１１Ａ及び血液戻りライン１１Ｂを備える。矢印で示されるように、医療デバイス１０は、対象１００から血液を採取し、透析器（図示せず）内で血液を処理し、処理された血液を、例えば血液ポンプによって制御された方法で対象１００に戻すように動作可能である。透析器では、血液は半透膜の一方の側を通過し、透析流体は当該膜の他方の側を通過する。膜は廃棄粒子及び水が血液から透析流体に移動することを可能にし、所望の粒子が透析流体から血液に移動することを可能にする。血液処理装置１０はまた、シリンジ・ポンプによって駆動されるシリンジを含んでもよく、シリンジは、ヘパリン注入又はカルシウム注入のために使用される。１０´で示される医療デバイスは、血液処理装置１０によって使用される流体を準備するように動作可能であり、流体を血液処理装置１０に供給するための流体ライン１１を備える。１つの例で、医療デバイス１０´は水調製装置であり、流体は精製水である。例えば、水処理装置１０´は、当技術分野で知られているように、逆浸透によって入ってくる水を濾過してもよい。

説明される例において、医療デバイス１０は、ディスプレイ１２（場合によってはタッチ・ディスプレイ）と、制御ボタン１３（１つが示されている）と、インジケータ・ランプ１４と、ラウドスピーカ１５と、制御システム１６と、血液採取ライン１１Ａ及び血液戻りライン１１Ｂを介して対象１００への血液の制御された採取、処理、及び戻りを行うための１つ以上のアクチュエータ１７と、血液処理装置によって行われる医療処置を示すセンサ・データを提供するための１つ以上のセンサ１８とを備える。医療処置はまた、例えば、プライミング及び機能チェックを含んでもよい。アクチュエータ１７及びセンサ１８は、医療デバイス１０の内部コンポーネント（破線で示す）又は外部コンポーネント、あるいはその両方を含んでもよい。

アクチュエータ１７は例えば、医療処置が実行される間、バルブ、ポンプ、及び／又はヒータを制御するように構成される。言い換えると、アクチュエータ１７は、医療処置を制御するように構成される。アクチュエータ１７及びセンサ１８はまた、医療処置を監督するため、及び場合によっては予防動作を行うために使用される補助センサ１８´及び補助アクチュエータ１７´を備えてもよい。補助アクチュエータ１７´は例えば、医療手順を中断するための緊急バルブ又は緊急ブレーキを制御するように構成される。例えば流体流速を変更するために、ユーザは典型的に、ディスプレイ１２上に生成された、例えばグラフィカル・ユーザ・インタフェース（ＧＵＩ）を介して、又は制御ボタン１３を使用して、流体流量の設定値を入力する。その後、この設定値は１つ以上のアクチュエータ設定値、すなわち、対応するアクチュエータを制御する値に変換される。例えば、３００ｍｌ／分の流体流速（設定値）は例えば、ｒｐｍ又はパーセントのポンプ速度（アクチュエータ設定値）に変換される。

制御システム１６は、血液処理装置の意図された医療処置を実行するために、ならびに医療処置に関連して必要に応じてディスプレイ１２、インジケータ・ランプ１４、及びラウドスピーカ１５を動作させるために、アクチュエータ１７及びセンサ１８の動作を調整し、制御ボタン１３を介してユーザ入力を取得するように構成される。例えば、ディスプレイ１２は医療デバイス１０のユーザに命令を提示するように動作されてもよく、インジケータ・ランプ１４は医療デバイス状態を示すように動作されてもよく、ラウドスピーカ１５はアラーム信号などを生成するように動作されてもよい。

医療デバイス１０は、遠隔システム２０（１つのみが示されているが、複数であってもよい）に接続されている。遠隔システム２０は例えば、医療デバイスを遠隔監視及び／又は制御するように構成される。遠隔システム２０については、図２ｂでさらに説明される。

医療デバイス１０´は、説明される詳細さのレベルにおいて、医療デバイス１０と同様のコンポーネントの集合を有してもよく、これ以上説明しない。医療デバイス１０´は、医療デバイス１０と同様に、遠隔システム２０にも接続されている。医療デバイス１０、１０´は、簡潔にするために本書では説明しない、図示されているよりも多くのコンポーネントを含んでもよい。

図１ｂは、制御された方法で、対象１００の腹腔に透析液を輸送し、続いて、両頭矢印によって示されるように、そこから透析液を除去するように動作可能である別の例示的な医療デバイス１０を説明する。この医療処置は一般に自動腹膜透析として知られており、医療デバイス１０はしばしば「ＰＤサイクラ」と呼ばれる。ＰＤサイクラは例えば、透析液の混合、輸送及び除去のいずれかのためのポンプを含む。図１ｂの医療デバイス１０は、図１ａの医療デバイス１０と比較して、説明される詳細さのレベルで同様の（しかし、典型的には減少された）コンポーネントの集合を有してもよく、また、遠隔システム２０に接続されてもよい。図１ｂの医療デバイス１０は、簡潔にするために本書で説明されない、図示されているよりも多い又は少ないコンポーネントを含んでもよい。医療デバイス１０はまた、透析液を混合するために使用される精製水を得るために、図１ａに示されるように、別の医療デバイス１０´に接続されてもよい。

図１ｃは、矢印によって示されるように、制御された方法で、例えば対象１００の循環系に、人間のような対象１００の身体に医療流体を輸送するように動作可能であるさらなる例示的な医療デバイス１０を説明する。医療流体は薬物及び／又は栄養素を含むが、これらに限定されない任意の適切な流体であってもよい。このタイプの医療デバイス１０は、一般に「注入ポンプ」として知られている。注入ポンプの１つ以上のアクチュエータは、指定された速度で薬物及び／又は栄養素を対象１００に送り込むように１つ以上のポンプを制御するように構成される。ライン・オクルーダ及び／又はバルブは、ポンピング中に流体流量を制御するために作動される。図１ｃの医療デバイス１０は、同様の（しかし、典型的には減少された）コンポーネントの集合を有してもよく、説明される詳細さのレベルで図１ｂの医療デバイス１０のように遠隔システム２０に接続されてもよく、さらに説明されない。図１ｃの医療デバイス１０は、簡潔にするために本書では説明されない、図示されているよりも多くのコンポーネントを含んでもよい。

図２ａは、１つの例示的な実施形態による、図１ａ～ｃの例示的な医療デバイスのいずれかの制御システム１６をより詳細に説明する。制御システム１６は、プロセッサ１６１と、通信インタフェース１６２と、メモリ１６３とを備える。プロセッサ１６１は、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、マイクロコントローラ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、又はそれらの組合せのような任意の市販の処理デバイスであってもよい。

通信インタフェース１６２は、遠隔システム２０（図１ａ～ｃ）との通信を可能にするように構成される。通信は、ワイヤレス及び／又は有線であってもよい。有線通信は、有線イーサネット（登録商標）接続、ＲＳ－２３２、ＲＳ－４８５、又はＵＡＲＴを使用して実行されてもよい。ワイヤレス通信は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、Ｚ－Ｗａｖｅ（登録商標）、ワイヤレス・ユニバーサル・シリアル・バス（「ＵＳＢ」）、赤外線プロトコルのいずれか、又はその他の適切なワイヤレス通信技術を介して実行されてもよい。通信インタフェース１６２は例えば、プロセッサ１６１によって制御されるように構成されたＢｌｕｅｔｏｏｔｈチップである。遠隔システム２０と医療デバイスとの間の通信は、インターネット・プロトコル又は独自のプロトコルのような、任意の適切な通信プロトコルを使用して実行されてもよい。いくつかの実施形態において、通信インタフェースは、例えば事前共有鍵アプローチを使用してセキュアな通信を実装し、ＳＳＬ／ＴＬＳを使用してセキュアなＤＮＳ通信を実装し、遅延認証及び事前共有鍵を使用してセキュアなＤＨＣＰ通信を実装し、ＳＳＬ／ＴＬＳを使用して他のアプリケーション固有のプロトコルを実装してもよい。

メモリ１６３は、リード・オンリ・メモリ（ＲＯＭ）、プログラマブル・リード・オンリ・メモリ（ＰＲＯＭ）、電気的消去可能プログラマブル・リード・オンリ・メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、リムーバブル・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、スタティックＲＡＭ、キャッシュ・メモリ、ハード・ドライブ、記憶媒体などを含んでもよいがこれらに限定されない、不揮発性メモリ又は揮発性メモリ、あるいはこれらの組合せを含んでもよい。メモリ１６３は、プロセッサ１６１による実行のためのソフトウェア・システムを記憶する。ソフトウェア・システムは、特定の機能又は機能の集合を実現するように編成されたソフトウェア・アイテムの統合された集まりであり、医療デバイスに関するＩＳＯ規格ＩＥＣ６２３０４を参照されたい。ソフトウェア・システムは、アプリケーション・ソフトウェアと、ソフトウェア・アプリケーションを管理し、医療デバイスのアプリケーションとハードウェアとの間の仲介として機能するソフトウェア・プラットフォーム（典型的には、オペレーティング・システムを含む）とを含む。ソフトウェア・システムは、通信インタフェース１６２を介して遠隔システム２０によってアクセスされてもよい。

ソフトウェア・システムは、本書に記載する動作を実行するためにプロセッサ１６１によって実行可能なメモリ１６３に記憶された１つ以上の命令によって特定される。ソフトウェア・システムは、例えば医療処置を実行するように医療デバイス１０を制御するように構成される。言い換えると、ソフトウェア・システムは、医療デバイス１０の動作に関与する１つ以上の医療プロセスＰ_ＭＥＤを含む。ソフトウェア・システムはまた、プロセッサ１６１によって実行される場合に、以下に詳細に説明する第１態様（図４）の方法を実行するように構成される。

プロセッサ１６１及びメモリ１６３は、それらが個別に動作可能なユニットであるという意味で「別個」であるが、それらは例えば集積回路のような共通の基板上に任意の組合せで配置されてもよいし、配置されなくてもよい。簡単にするために、図２ａの制御システム１６は、１つのプロセッサ１６１及びメモリ１６３のみを備えるものとして示されている。しかし、医療デバイス１０は、１つ以上のプロセッサ１６１を備えるプロセッサの集合を備えてもよく、メモリ１６３は１つ以上の記憶デバイスによって実装されてもよいことが理解されるべきである。

図２ｂは、例示的な遠隔システム２０をさらに詳細に説明する。遠隔システム２０は、医療デバイスの一体化された部分ではない任意のシステムであり、より具体的に、医療デバイス１０の制御システム１６のプロセッサ１６１の集合によって実行されるソフトウェア・システムである。遠隔システム２０は例えば、サービス又はサポート・システムである。遠隔システム２０は、サーバ、ワークステーション・ラップトップ、コンピュータ等のうちの１つ以上を含んでもよい。遠隔システムは、オンサイトに配置されてもよいし、オフサイトに配置されてもよい。最も単純な形態では、遠隔システムは、タブレット又はパーソナル・コンピュータのような単純なユーザ・デバイスであり、これはそこに設置された医療デバイス１０に遠隔アクセスするように構成されたソフトウェアを有する。遠隔システム２０は、プロセッサ２１と、通信インタフェース２２と、メモリ２３とを備える。プロセッサ２１は、ＣＰＵ、ＤＳＰ、マイクロプロセッサ、ＦＰＧＡ、ＡＳＩＣ、又は任意の他の電子プログラマブル論理デバイス、又はそれらの組合せなどのような任意の市販の処理デバイスであってもよい。

通信インタフェース２２は、医療デバイス１０との通信を可能にするように構成される。通信は、ワイヤレス及び／又は有線であってもよい。有線通信は、有線イーサネット接続、ＲＳ－２３２、ＲＳ－４８５、又はＵＡＲＴを使用して実行されてもよい。ワイヤレス通信は、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、Ｚｉｇｂｅｅ、Ｚ－Ｗａｖｅ、ワイヤレス・ユニバーサル・シリアル・バス（「ＵＳＢ」）、赤外線プロトコルのいずれか、又はその他の適切なワイヤレス通信技術を介して実行されてもよい。短距離通信インタフェース２２は例えば、プロセッサ２１によって制御されるように構成されたＢｌｕｅｔｏｏｔｈチップである。遠隔システム２０と医療デバイス１０との間の通信は、インターネット・プロトコル又は独自のプロトコルのような任意の適切な通信プロトコルを使用して実行されてもよい。

メモリ２３は、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、リムーバブル・メモリ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、キャッシュ・メモリ、ハード・ドライブ、記憶媒体等を含むがこれらに限定されない不揮発性メモリ又は揮発性メモリ、又はこれらの組合せを含んでもよい。メモリ２３は、プロセッサ２１による実行のためのソフトウェアを記憶する。ソフトウェアは例えば、例えばサービス、サポートを実行するように医療デバイス１０を制御するように構成される。

簡単にするために、図２ｂの遠隔システム２０は、ただ１つのプロセッサ２１及びメモリ２３を備えるものとして示されている。しかし、遠隔システム２０はいくつかのプロセッサを含んでもよく、メモリ２３は１つ以上の記憶デバイスによって実装されてもよいことが理解されるべきである。

遠隔システム２０は、通信インタフェース２２を介して、医療デバイス１０から、例えばセンサ１８によって提供されるセンサ・データのような情報を受信するように構成される。遠隔システム２０はまた、例えば種々の目的で医療デバイス１０に遠隔アクセスするために、情報を医療デバイス１０へ送信してもよい。通信は、典型的には通信インタフェース２２を介して通信されるメッセージを用いて実施される。メッセージは種々のコマンド（アクセス要求）を示してもよく、又はデータ（例えば、遠隔要求）を搬送してもよい。

他のタイプの動作から治療を分離するために、医療デバイスは、しばしば、治療モード及びサービス・モードのような異なるモードで動作できる。サービス・モードは典型的に、治療ではない処置、例えばサービス又はサポートのために使用される。遠隔アクセスの１つの例は、遠隔システム２０が、医療デバイス１０をサービス・モードに設定させるために医療デバイス１０にアクセスしうることである。別の例は、遠隔システム２０が、サービス・モード・データを遠隔システム２０に送信すること、又は言語、警報閾値などのような設定を変更することを医療デバイス１０に要求しうることである。サービス・モード・データは、医療デバイス１０の、現在の設定、最後に行われた保守の情報、インストールされたソフトウェア・バージョンの情報などを含んでもよい。

遠隔アクセスはまた、医療デバイス１０上でソフトウェア更新を実行するために、遠隔システム２０によって使用されてもよい。これは、更新されたソフトウェアが利用可能であるという情報を送信することによって行われてもよく、これは治療モードで行われてもよい。その後、オペレータは、例えばディスプレイ１２を介して、利用可能なソフトウェア更新について知らされてもよい。その後、オペレータは、適切な時間にソフトウェア更新のダウンロード及びインストールをトリガできる。遠隔アクセスはまた、更新されたソフトウェアを医療デバイス１０にインストールするために使用されてもよい。

遠隔アクセスの別の例は、種々の目的で医療デバイスのアクチュエータ１７又は内部手順への遠隔アクセスである。実際には、医療デバイス１０の任意の手順を、医療処置自体でさえも、遠隔から実行することが可能である。

ここで、図３～図５を参照して、提案される技術を説明する。

図３は、提案される技術の非限定的な例による、医療デバイス１０を制御するように構成された例示的なソフトウェア・システムのブロック図である。

説明されるソフトウェア・システムは、ＳＳ１～ＳＳ４と表される４つのサブシステムを含む。サブシステムＳＳ１～ＳＳ４は、医療処置及びサポート手順を実行する際の医療デバイスの動作に関して特定の機能を提供するために独立して開発され、テストされうるコンピュータ実行可能命令のソフトウェア・モジュールであると考えられてもよい。各個別のサブシステムは、個別のサブシステムの文脈内で実行されるソフトウェア・プロセス（又はスレッド）で構成される。したがって、サブシステム内のソフトウェア・プロセスは、サブシステムの特定の機能を提供するために、調整されたプロセスのグループを実行するように設計されてもよい。本書のソフトウェア・プロセス（又は単にプロセス）は、スケジューラによって独立して管理されうる命令のシーケンスを含むソフトウェア・コンポーネントを指し、スケジューラは典型的に、医療デバイス１０の制御システム１６のプロセッサ１６１によって実行されるソフトウェア・システムのオペレーティング・システムの一部である。プロセスの実装は、オペレーティング・システムによって異なる。異なるプロセスは、通常、メモリ空間のようなリソースを共有しない。ソフトウェア・プロセスは、Ｌｉｎｕｘ（登録商標）プロセスやグリーン・ヒルズ・インテグリティ・プロセスなどである。オペレーティング・システムは典型的に、所定のセキュリティ・ルールに基づいて着信及び発信ネットワーク・トラフィックを監視し、制御する、Ｎｅｔｆｉｌｔｅｒのような標準のファイアウォールを含む。

また、サブシステムが、医療処置の実行に関与しない１つ以上のプロセスを含むことも考えられる。さらに、サブシステムは、他のサブシステムとの通信を管理するための通信スタック、技術的エラーを管理するためのエラー・マネージャ、通知を管理するための通知マネージャなどのような、ソフトウェア・システムにおける基本的な機能又はサービスを実行するミドルウェア及び／又は低レベル・ソフトウェア・コンポーネントのような、さらなるソフトウェア・コンポーネントを含んでもよい。サブシステムのうちの１つ以上は、ハードウェア及びソフトウェア・リソースに関してオペレーティング・システムによって提供されるサービスを利用するために、１つ以上のオペレーティング・システムの上で動作されてもよい。実装に応じて、プロセッサ１６１によって実行されるソフトウェア・システムのサブシステムのオペレーティング・システムは例えば、リアルタイム・オペレーティング・システム、組み込みオペレーティング・システム、シングル・タスキング・オペレーティング・システム、又はマルチ・タスキング・オペレーティング・システム、あるいはそれらの任意の組合せを含んでもよい。

提案される技術に関連するソフトウェア・プロセスが、図３の例示的なアーキテクチャを参照して説明される。第１サブシステムＳＳ１は、医療デバイスの動作を制御するように、例えば透析治療のような医療処置、又はサポート手順を実行するように構成された１つ以上の医療プロセスＰ_ＭＥＤを備える。したがって、１つ以上の医療プロセスＰ_ＭＥＤは、サポート及び／又はサービスのような、医療処置に関連する医療デバイス１０の動作を制御するように構成されたプロセスを含んでもよい。したがって、第１サブシステムＳＳ１は、本書では医療デバイス１０のメイン・システムと呼ばれる。

メイン・システムＳＳ１はまた、遠隔通信プロセスＰ_ＣＯＭＭを備える。遠隔通信プロセスＰ_ＣＯＭＭは、医療システム１０と１つ以上の遠隔システム２０との間の通信を管理するように構成される。言い換えれば、遠隔通信プロセスＰ_ＣＯＭＭは、遠隔システム２０へのセキュアな（適用可能であれば、認証され暗号化された）接続を確立することを担当する。遠隔通信プロセスＰ_ＣＯＭＭはまた、遠隔システム２０との通信を担当する。遠隔システム２０とのすべての通信はメイン・システムＳＳ１内の遠隔通信プロセスＰ_ＣＯＭＭによって処理されるので、１つ以上の医療プロセスＰ_ＭＥＤの機能への遠隔アクセスは、常に遠隔通信プロセスＰ_ＣＯＭＭを介して行われる。言い換えると、メイン・システムの１つ以上の医療プロセスＰ_ＭＥＤ又は他のプロセスに遠隔アクセスすることのすべての要求は、遠隔通信プロセスＰ_ＣＯＭＭを通じてルーティングされる（すなわち、遠隔通信プロセスＰを介して受信され、又はこれを通じて入る）。

提案される技術を説明するために使用される医療デバイス１０が１つの単一の遠隔通信プロセスＰ_ＣＯＭＭを含む場合であっても、他の例では、２つ以上の遠隔通信プロセスＰ_ＣＯＭＭが存在してもよいことが理解されるべきである。例えば、医療デバイスは、種々のタイプの遠隔要求及び／又はプロトコルを扱うための複数の遠隔通信プロセスＰ_ＣＯＭＭを含んでもよい。この場合に、上記のように、これらの遠隔通信プロセスＰ_ＣＯＭＭのそれぞれ１つは、１つ以上の医療プロセスＰ_ＭＥＤから分離されていなければならず、１つ以上の医療プロセスＰ_ＭＥＤよりも低いプライオリティを有する。

遠隔通信プロセスＰ_ＣＯＭＭは、１つ以上の医療プロセスＰ_ＭＥＤとは別個のものである。プロセスが別個のものであるとは、例えば、それらが別個のメモリ空間、個別のプロセス状態を有し、及び／又はプロセス間通信を使用して通信していることを意味する。別の言い方をすれば、この考え方は、遠隔通信を扱う１つのプロセス（又は、場合によっては複数のプロセス）、ここではＰ_ＣＯＭＭ、を分離することであり、これは、何を行うことが許可されているかの点で制限される。いくつかの実施形態において、遠隔通信プロセスＰ_ＣＯＭＭは、遠隔システムとの通信に必要なものを除いて、システム資源へアクセスできない。いくつかの実施形態において、その唯一のタスクは、有効にされた要求を処理することである。今後は、１つの遠隔通信プロセスＰ_ＣＯＭＭについてのみ議論する。しかし、いくつかの遠隔通信プロセスＰ_ＣＯＭＭが存在するならば、それらのそれぞれに同じ要件が適用される。

図２ａに関連して上述したように、医療デバイス１０は、１つ以上のプロセッサ１６１を含んでもよい。プロセスが別個であるので、１つ以上の医療プロセスＰ_ＭＥＤ及び遠隔通信プロセスＰ_ＣＯＭＭは、同一の１つ以上のプロセッサによって実行されてもよく、依然として分離されたままである。言い換えれば、一方のプロセスにおけるエラーは、他方のプロセスに伝播しない。

さらに、１つ以上の医療プロセスＰ_ＭＥＤは、遠隔通信プロセスＰ_ＣＯＭＭよりも高いプライオリティを有する。これは、ソフトウェア・システムが、例えば処理能力やメモリ・アクセスの観点から、１つ以上の医療プロセスＰ_ＭＥＤを常に優先することを意味する。具体的に、各プロセスにプライオリティが割り当てられる。プロセス・プライオリティの概念は、コンピュータ科学において周知である。この概念は、最高のプライオリティを有するプロセスが、低いプライオリティを有する任意のプロセスよりも先に実行され、又はリソースを割り当てられることを意味する。同じプライオリティを有するプロセスは例えば、先着順で実行される。プライオリティは、メモリ要件、時間要件、又は他のリソース要件に基づいて決定されうる。したがって、遠隔通信プロセスＰ_ＣＯＭＭに過負荷が存在するならば、それは１つ以上の医療プロセスＰ_ＭＥＤに影響しないだろう。

さらなる例として、遠隔通信プロセスＰ_ＣＯＭＭは、所定のファイルにアクセスすることが許可されない。しかし、１つ以上の医療プロセスＰ_ＭＥＤは、当該所定のファイルにアクセスすることを許可されてもよい。

医療処置を制御するメイン・システム、又はこのようなメイン・システムによって使用されるハードウェア・コンポーネントのいずれかにおける動作障害の場合に対象に健康リスクをもたらす医療処置を実行する多くの医療デバイスは、並列に動作し、メイン・システムから独立している保護システム（監督システムとも呼ばれる）を含んでもよい。保護システムが潜在的な動作障害を検出するときはいつでも、医療デバイスは安全な動作状態に切り替えられる。したがって、この例では、第３サブシステムＳＳ３は、医療処置の動作を監督するように構成された監督プロセスＰ_Ｓを含む。第３サブシステムＳＳ３は、本書では医療デバイス１０の保護システムとも呼ばれる。

サブシステムＳＳ２及びＳＳ４は、それぞれ、メイン・システムＳＳ１及び保護システムＳＳ３によって生成されたコマンド／信号に基づいて、医療デバイス１０のアクチュエータ１７及び／又はセンサ１８の種々の集合と通信するように構成されたＩ／Ｏシステムである。このために、サブシステムＳＳ２、ＳＳ４のそれぞれは、個別のサブシステムＳＳ２、ＳＳ４に接続された周辺機器（例えば、アクチュエータ１７及び／又はセンサ１８（図１ａ～ｃ））へのアクセスを提供するためのソフトウェア・プロセスを備えてもよい。図３では、これらのプロセスは、Ｐ_Ｉ／Ｏ（Ｉ／Ｏプロセスの略）及びＰ_{Ｓ‐Ｉ／Ｏ}（監督Ｉ／Ｏプロセスの略）と示される。

サブシステムＳＳ１～ＳＳ４のプロセスは、プロセス間通信（ＩＰＣ）を使用して通信し、ＩＰＣは、プロセスが共有データを管理できるようにするオペレーティング・システムのメカニズムを指す。プロセス間通信は典型的に、メッセージ・ベースのプロトコルを使用する。例えば、プロセス間通信は、クライアント及びサーバを使用し、クライアントはデータを要求し、サーバはクライアントの要求に応答する。プロセス間通信の設計は実装次第である。

この例では、それぞれのサブシステムはまた、個別の内部通信プロセスＰ_{Ｉ‐ＣＯＭ}を備える。通信プロセスＰ_{Ｉ‐ＣＯＭ}は、受信機を修正することの要求をルーティングし、アクティブな通信セッションを維持することを担当し、例えば、異なるサブシステムＳＳ１～ＳＳ４のプロセス間の通信を扱う。遠隔システム２０とのすべての通信はメイン・システムＳＳ１内の遠隔通信プロセスＰ_ＣＯＭＭを介して行われるので、他のサブシステムＳＳ２～ＳＳ４の機能への遠隔アクセスは、通信プロセスＰ_{Ｉ‐ＣＯＭ}によって処理される、言い換えると、医療デバイス１０に遠隔アクセスすることのすべての要求は、メイン・システムＳＳ１の遠隔通信プロセスＰ_ＣＯＭＭを通じてルーティング又は通過される。

提案される技術は、保護システムＳＳ３及び対応するＩ／ＯシステムＳＳ４を含まない医療デバイスにおいても同様に実施されうることに留意されたい。また、Ｉ／Ｏシステムが別個のサブシステムではなく、メイン・システムＳＳ１及び保護システムＳＳ３（存在する場合）に統合される設計を有することも可能である。したがって、サブシステムＳＳ２、ＳＳ３、ＳＳ４は、図３に破線で示されている。

ここで、図４のフローチャートを参照して、提案される技術をさらに詳細に記載する。図４は、図１ａ～１ｃの任意のものの医療デバイス１０のような、医療処置を実行するように構成された医療デバイス１０に遠隔アクセスするための例示的な方法を説明する。本方法は例えば、医療デバイス１０が例えば患者を治療するために使用される、病院のような医療環境に配置された医療デバイス１０において実行される。本方法はまた、患者の自宅の医療デバイス１０において実行されてもよい。本方法は、医療環境の内部又は外部に位置する遠隔システム（及びそのようなシステムのオペレータ）が、例えば医療デバイス１０を診断するために、セキュアな方法で機械にアクセスすることを可能にする。

上述したように、医療デバイス１０は、ソフトウェア・システムと、医療デバイス１０の動作に関与する１つ以上の医療プロセスＰ_ＭＥＤと、遠隔通信プロセスＰ_ＣＯＭＭとによって制御される。遠隔通信プロセスＰ_ＣＯＭＭは、医療システム１０と１つ以上の遠隔システム２０との間の通信を管理するように構成される。遠隔通信プロセスＰ_ＣＯＭＭは、１つ以上の医療プロセスＰ_ＭＥＤとは別個のものである。さらに、１つ以上の医療プロセスＰ_ＭＥＤは、図３に関連して説明されるように、遠隔通信プロセスＰ_ＣＯＭＭよりも高いプライオリティを有する。

本方法は典型的に、プロセッサの集合によってプログラムが実行される場合に、コンピュータに本方法を実行させる命令を含むコンピュータ・プログラムとして実施される。いくつかの実施形態によれば、コンピュータ・プログラムは、プロセッサの集合によって実行される場合に、コンピュータに本方法を実行させる命令を含むコンピュータ可読媒体に記憶される。

本方法は、医療デバイス１０がスイッチ・オンされる場合にいつでも実行されてもよい。本方法を実行できるための前提条件は、典型的に、医療デバイス１０の通信インタフェース１６２が有効にされることである。

医療デバイスがスイッチ・オンされた場合に、スタート・アップ手順が開始される。いくつかの実施形態において、本方法は、医療デバイス１０をスタート・アップするステップＳ０を含み、これは典型的に、医療デバイス１０が電源オンされた場合に行われる。遠隔システム２０からのすべての要求（すなわち、着信要求メッセージ）は、典型的に、スタート・アップ手順が完了するまで拒否される。言い換えると、いくつかの実施形態において、１つ以上の医療プロセスＰ_ＭＥＤにアクセスすることの要求は、スタート・アップＳ０中に、遠隔通信プロセスＰ_ＣＯＭＭによってブロックされる。要求がブロックされているということは、スタート・アップ手順が完了するまで、これらが破棄されるか、又は場合によっては記憶されることを意味する。

スタート・アップ中に、遠隔通信プロセスＰ_ＣＯＭＭは、医療デバイス１０に遠隔アクセスするための少なくとも１つのアクセス基準を構成するＳ１。例えば、遠隔システム２０の通信設定は、医療デバイス１０において構成される。構成データは、医療デバイス１０のＧＵＩを介してオペレータから受信されてもよい。あるいは、医療デバイス１０に記憶された構成データが、遠隔通信プロセスＰ_ＣＯＭＭによって読み出されてもよい。したがって、構成データは、製造時に又は医療デバイス１０が使用される際に追加されてもよい。

通信設定は例えば、医療デバイス１０がアクセスする必要がある遠隔システムのＩＰアドレスを含む。それはまた、医療デバイスにアクセスすることを許可される遠隔システム２０のアドレスを含んでもよい。この例では、遠隔システム２０のＩＰアドレスが、医療デバイス１０内に構成されてもよい。いくつかの実施形態において、登録されていないデバイスは、医療デバイス１０にアクセスすることを許可されない。

これに加えて又はこれに代えて、通信設定は、遠隔システム２０の真正性を検証するための認証データを含んでもよい。言い換えれば、いくつかの実施形態において、遠隔システム２０が使用するクレデンシャルが医療デバイス１０内に構成される。これは、例えば、医療デバイス１０内に構成され、例えば、秘密公開鍵暗号を使用して遠隔システム２０によって共有されるクレデンシャルを含んでもよい。このようにして、医療デバイス１０は、特定の遠隔システム２０が信頼され、医療デバイス１０にアクセスすることが許可されるべきであることを保証してもよい。言い換えれば、いくつかの実施形態において、少なくとも１つのアクセス基準は、要求の送信者又は発信元が認証されることを含む。例えば、医療デバイス１０に遠隔的にアクセスすることの要求は、受諾されるために、医療デバイス１０に知られている暗号鍵で署名されなければならない。

さらに、医療デバイスの所定の機能が、遠隔システム２０による遠隔アクセスのために有効にされる。例えば、遠隔システム２０は、所定のセンサ１８を読み取ること、所定のアクチュエータ１７を制御すること、又は所定のコマンドを実行することが可能である。言い換えると、少なくとも１つのアクセス基準は、要求が、許可された要求タイプを有すること、又は要求が、許可された機能に関することを含む。例えば、許可された要求タイプは、ＳＷ更新を行うことの要求を含んでもよく、又は、要求は、医療デバイス１０からログ・データを受信することの要求を含む。

言い換えれば、いくつかの実施形態において、少なくとも１つのアクセス基準は、異なる送信者、要求のタイプ、及び／又は機能についての個別の規則を含む。

また、遠隔通信プロセスＰ_ＣＯＭＭは、システムに損害を与えるかもしれない速度で要求を転送しないように構成されてもよい。別の言い方をすれば、遠隔通信プロセスＰ_ＣＯＭＭは、必ず安全な速度で要求を転送するように構成されてもよい。このようにして、過負荷攻撃の場合に医療デバイス１０の他のプロセスが枯渇することが回避される。リソース不足は、並行コンピューティングで発生する問題であり、例えば、オペレーティング・システムは、プロセスがそのタスクを実行するために必要な（メモリやコンピューティング・リソースのような、プロセスに必要なリソースを常に提供できない場合などである。医療デバイス１０の枯渇は、医療デバイス１０に多数の要求を送信し、医療デバイス１０に、医療処置を実行する代わりに要求の処理に医療デバイス１０のリソースを割り当てさせることによって、遠隔システム２０によって意図的に引き起こされうる。言い換えれば、いくつかの実施形態において、少なくとも１つのアクセス基準は、単位時間当たりに受信される要求の数が閾値を超えないことを含む。閾値は、例えば、遠隔通信プロセスＰ_ＣＯＭＭの受信容量に依存する１秒あたりの要求数である。典型的に、毎秒約１又は数ダースである。速度は、要求タイプ又は機能ごとに規定されてもよい。

構成することＳ１は、システムをセットアップする際に行われてもよいし、後の時点で行われてもよい。いくつかの実施形態において、医療デバイス１０が再構成され、例えば、必要に応じて、許可された（又は信頼された）遠隔システムとなるように、ＧＵＩを介してオペレータによって別の遠隔システムが構成されてもよい。

医療デバイスに遠隔アクセスするために、医療デバイス１０と遠隔システム２０との間に接続が確立される必要がある。接続は、典型的に、クレデンシャルの交換によって、又はＶＰＮ接続を使用して交換のために確立されたセキュアな接続である。接続は、暗号化されてもよい。より具体的に、医療デバイス１０の通信インタフェース１６２と遠隔システム２２の通信インタフェースとの間に遠隔接続が確立される。接続は例えば、異なる下層のトランスポート・プロトコルを使用してもよいＩＰ接続である。接続は、ワイヤレス又は有線通信、あるいはそれらの組合せを使用してもよい。いくつかの実施形態において、接続は、インターネットを介して、例えば別の場所に配置された遠隔システム２０と確立される。したがって、接続は、サイバー攻撃を受けるかもしれない。言い換えると、本方法は、遠隔通信プロセスＰ_ＣＯＭＭが、医療デバイス１０と遠隔システム２０との間にセキュアな接続を確立することＳ２を含む。

遠隔システム２０が医療デバイス１０にアクセスすることを望む場合に、要求は、典型的に、医療デバイス１０へ送信される。要求は、遠隔通信プロセスＰ_ＣＯＭＭによって受信される。したがって、本方法は、遠隔通信プロセスＰ_ＣＯＭＭが、遠隔システムから、１つ以上の医療プロセスＰ_ＭＥＤにアクセスすることの要求（すなわちメッセージ）を受信することＳ３を含む。医療デバイスは、目的に応じて、種々のフォーマットを有する要求をサポートしてもよい。典型的に、医療デバイス１０は、遠隔システム２０がサポートするように構成された１つ以上のプロトコルを有する。しかし、要求は、典型的に、要求タイプと、場合によってはさらに（又は代替として）センサ又は内部機能のような医療デバイス内の内部宛先とを含む。さらに、要求は、設定値又は他のパラメータのようなデータを含んでもよい。

種々のタイプの要求が遠隔システム２０から受信されてもよい。いくつかの実施形態において、１つ以上の医療プロセスにアクセスすることの要求は、医療デバイス１０を遠隔制御することの要求を含む。遠隔制御は例えば、医療デバイス１０のサービス又はサポートのために使用されてもよい。いくつかの実施形態において、１つ以上の医療プロセスＰ_ＭＥＤへの要求は、医療デバイス１０内のソフトウェアを更新することの要求を含む。このタイプのアクセスは、追加のセキュリティ対策を必要としてもよい。いくつかの実施形態において、１つ以上の医療プロセスにアクセスすることの要求は、医療デバイス１０の時刻を設定することの要求、又は医療デバイス１０からログ・データを受信することの要求を含む。いくつかの実施形態において、１つ以上の医療プロセスにアクセスすることの要求は、医療デバイス１０の構成を更新することの要求を含む。構成は、遠隔アクセス構成に関連してもよい（ステップＳ１を参照）。いくつかの実施形態において、１つ以上の医療プロセスにアクセスすることの要求は、医療デバイス１０のクレデンシャルを更新することの要求を含む。

しかし、遠隔通信プロセスＰ_ＣＯＭＭは、構成された少なくとも１つのアクセス基準を満たさない要求を転送しない。したがって、本方法は、受信された要求が、医療デバイス１０に遠隔アクセスするための構成された少なくとも１つのアクセス基準を満たすかどうかを遠隔通信プロセスＰ_ＣＯＭＭが評価することＳ４を含む。

要求が事前に決定された基準を満たすならば、例えば、遠隔システム２０がそれ自体を認証でき、要求が安全な速度で受信されるならば、要求は関連するソフトウェア・プロセスに転送される。言い換えると、本方法は、医療デバイス１０に遠隔アクセスするための構成された少なくとも１つのアクセス基準を要求が満たすと、遠隔通信プロセスＰ_ＣＯＭＭが、要求を１つ以上の医療プロセスＰ_ＭＥＤに転送することＳ５ａを含む。別の言い方をすれば、遠隔通信プロセスＰ_ＣＯＭＭは、着信要求についてのフィルタを含む。

遠隔通信プロセスＰ_ＣＯＭＭは、典型的に、ＩＰなどの標準化されたプロトコルを使用して遠隔システムから要求を受信する。しかし、典型的に、機械内で内部的に、別のプロトコル、例えば製造者の独自のプロトコルが使用されてもよい。言い換えると、いくつかの実施形態において、遠隔通信プロセスＰ_ＣＯＭＭは、医療デバイス１０と遠隔システム２０との間の通信に使用されるプロトコルとは異なる及び／又はこれから独立したプロトコルを使用して、要求を転送する。これは、遠隔システム２０との外部通信及び医療デバイス１０内の内部通信が直接的にルーティング可能ではないが、内部通信に使用されるプロトコルに要求を翻訳及び／又は変換し、さらに少なくとも１つの構成されたアクセス基準が満たされていることをチェックする遠隔通信プロセスＰ_ＣＯＭＭを常に経由することを意味する。

上述したように、遠隔通信プロセスＰ_ＣＯＭＭが多量の処理能力を必要とする状況において、１つ以上の医療プロセスＰ_ＭＥＤが枯渇しないことが重要である。したがって、１つ以上の医療プロセスＰ_ＭＥＤの動作は、最高のプライオリティを有する。言い換えると、いくつかの実施形態において、本方法は、１つ以上の医療プロセスＰ_ＭＥＤに、遠隔通信プロセスＰ_ＣＯＭＭよりも、医療デバイス１０の処理能力に対するより高いプライオリティを与えることを含む。これは、オペレーティング・システムにおいて１つ以上の医療プロセスＰ_ＭＥＤにより高いプライオリティを割り当てることによって実装されてもよい。

アクセス基準を満たさない要求は、典型的に、プロセスＰ_ＣＯＭＭによってブロックされる。言い換えると、いくつかの実施形態において、本方法は、遠隔通信プロセスＰが、構成された少なくとも１つのアクセス基準を満たさない、１つ以上の医療プロセスＰ_ＭＥＤにアクセスすることの要求をブロックすることＳ５ｂを含む。ブロックすることは、それらが医療デバイス１０内の他のプロセスに転送されないことを意味する。いくつかのシナリオにおいて、ブロックすることは、一時的なものであってもよい。例えば、要求が安全でない速度で受信されたならば、要求はしばらくの間（例えば、バッファ内で）ブロックされ、その後、安全な速度で転送されてもよい。したがって、バッファ内の時間は、着信速度及び安全な速度に依存する。

悪意のある遠隔システムがそのタイプの情報を得ることは望ましくないので、遠隔システム２０は、典型的に、要求がブロックされたかどうかを知らされない。

その後、医療デバイス１０と遠隔システム２０との間のセキュアな接続が、例えばＧＵＩを介して又は接続が他の方法で切断されるために終了されるまで、医療デバイス１０にアクセスすることの着信要求について、ステップＳ３～Ｓ５が繰り返されてもよい。接続はさらに（又は代替的に）、遠隔システム２０と医療デバイス１０との間の「トランザクション」が完了した場合に、自動的に終了／停止されてもよい。

図５は、例示の実装に係る提案される方法を実行する場合の医療デバイス１０のメイン・システムＳＳ１のプロセス間の内部シグナリングのシーケンス図である。

この例示的な実装はまた、図１ａ～１ｃの医療デバイス、及び上記の図３に関連して記載された例示的なソフトウェア・アーキテクチャ（特に、メイン・システムＳＳ１）も参照する。

メイン・システムとも呼ばれる第１サブシステムＳＳ１は、医療デバイス１０の異なる機能を管理する複数のＳＷアイテムによって実装される。ＳＷアイテムは、ソフトウェア・アーキテクチャの機能部分である。ＳＷアイテムは、１つ以上のソフトウェア・プロセスによってデプロイされうる。あるいは、ソフトウェア・プロセスは、１つ以上のＳＷアイテムを実装してもよい。簡略化のために、医療デバイスに遠隔アクセスするための提案される方法に関与するＳＷアイテムのみが、図５に示されている。

メイン・システムＳＳ１は、１つ以上の医療プロセスＰ_ＭＥＤ（図５には示されていない）に加えて、遠隔システム通信と、構成マネージャと、クレデンシャル・マネージャとを備える。この例において、２つのＳＷアイテムによって実装されるＲＳＣを除くすべてのプロセスが１つの対応するＳＷアイテムによって実装される。

構成マネージャは、システム内の構成パラメータの管理を担当する。構成マネージャは構成パラメータを記憶し、要求に応じてそれらを更新し、更新をログに記録し、構成パラメータをクライアントに提供する。

クレデンシャル・マネージャは、証明書、秘密鍵、及び公開鍵のようなサイバーセキュリティ・クレデンシャルを記憶すること、ならびにクライアントにクレデンシャルを提供することを担当する。

遠隔システム通信ＲＳＣは、上述の遠隔通信プロセスＰ_ＣＯＭＭに対応する。したがって、ＲＳＣは、遠隔システム２０へのセキュアな（適用可能であれば、認証され暗号化された）接続を確立することを担当する。ＲＳＣはまた、遠隔システム２０とのデータ通信を担当する。この例において、ＲＳＣが以下のＳＷアイテムに分割される。
・ＲＳＣマネージャ：遠隔システムに対して（構成マネージャから読み出された）有効にされた機能をアクティブ化し、それを内部プロトコルに変換することを担当する。
・ＲＳＣトランスポート：一般的に、外部プロトコルのフォーマット及び暗号化を担当する。

遠隔システム通信は、典型的に、クライアントからデバイスへの内部ＳＷアイテムである。したがって、医療デバイス内部ＳＷアイテムが典型的には遠隔システム通信の存在に依存しないので、遠隔システム通信はサーバに作用しない。

ここで、図５を参照して、セキュアな接続のセットアップ中のメイン・システムＳＳ１内のプロセス間のシグナリングの例が説明される。

典型的に、アクティブ化が開始される前にいくつかの前提条件が満たされる必要がある。例えば、ＧＵＩなどを介して構成マネージャでＩＰ（インターネット・プロトコル）設定が構成されている必要がある。さらに、典型的に、遠隔システム２０又はＧＵＩのいずれかを介して遠隔アクセスについて所定の機能が有効／無効にされるべきである。代替的に、使用されてもよいデフォルト構成が存在してもよい。さらに、セキュアな接続によって使用される暗号鍵が、例えば製造時に医療デバイスにインストールされる。

最初に、医療デバイス１０をブートしている間、遠隔システム２０から受信されたすべての要求（ステップ５０）は、典型的には（ＲＳＣトランスポートにおける）ファイアウォールによってブロックされる（ステップ５１）。これらのステップは、図４のステップＳ０に対応する。

医療デバイス１０が立ち上がり動作すると（すなわち、ブートが完了すると）、ＲＳＣマネージャは、ＩＰ設定及び有効にされた通信機能を構成マネージャから読み出し（ステップ５２）、クレデンシャル・マネージャからクレデンシャルを読み出す（ステップ５３）。その後、ＲＳＣマネージャは、提供されたクレデンシャルと有効にされた通信機能とを用いて、セキュアな接続を開始することをＲＳＣトランスポートに要求する（ステップ５４）。したがって、ＲＳＣトランスポートは、ＲＳＣマネージャから受信された、現在有効になっている通信機能によって使用されるポート及びプロトコルのみ受諾するようにファイアウォールを構成する（ステップ５５）。医療デバイス１０に遠隔アクセスするための少なくとも１つのアクセス基準は、ここで、ＲＳＣトランスポートにおいて構成される。したがって、これらのステップは、図４のステップＳ１に対応する。

セキュアな接続を確立するために、遠隔システム２０は、まず、ＲＳＣマネージャから受信されたクレデンシャルを使用して、それ自体を認証する必要がある（ステップ５６）。これにより、遠隔システム２０とセキュアな接続が確立され、ＲＳＣマネージャに知らされる（ステップ５７）。したがって、これらのステップは、図４のステップＳ２に対応する。

ここで、医療デバイスは、構成された少なくとも１つのアクセス基準を満たすアクセス要求を受諾する。したがって、要求が受信される場合に（ステップ５８）、構成されたＩＰ設定及び有効にされた機能に一致するという条件で、それは、ファイアウォールによって受諾され（ステップ５９）、ＲＳＣマネージャに転送される（ステップ６０）。これらのステップは、図４のステップＳ３及びＳ４に対応する。

その後、ＲＳＣマネージャは、医療デバイス１０内の正しい受信者（典型的には別のプロセス）に要求を転送、又は渡す（ステップ６１）。例えば、要求は、１つ以上の医療プロセスＰ_ＭＥＤ又は他のサブシステムＳＳ２～ＳＳ４のうちの１つに転送される。このステップは、図４のステップＳ５ａに対応する。

本発明は現在最も実用的で好ましい実施形態であると考えられるものに関連して説明されてきたが、本発明は開示された実施形態に限定されるべきではなく、反対に、添付の特許請求の範囲の精神及び範囲内に含まれる種々の変形及び均等な構成を包含することが意図されることを理解されたい。

Claims (13)

1. 医療処置を実行するように構成された医療デバイス（１０）に遠隔アクセスするための方法であって、前記医療デバイス（１０）は、
   前記医療デバイス（１０）の動作に関与する１つ以上の医療プロセス（Ｐ_ＭＥＤ）と、
   前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）とは別個の遠隔通信プロセス（Ｐ_ＣＯＭＭ）であって、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）は、前記医療デバイス（１０）と１つ以上の遠隔システム（２０）との間の通信を管理するように構成される、遠隔通信プロセス（Ｐ_ＣＯＭＭ）と、
   を含むソフトウェア・システムによって制御され、
   前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）は、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）よりも高いプライオリティを有し、前記方法は、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）が、
   ‐前記医療デバイス（１０）に遠隔アクセスするための少なくとも１つのアクセス基準を構成すること（Ｓ１）と、
   ‐前記医療デバイス（１０）と遠隔システム（２０）との間のセキュアな接続を確立すること（Ｓ２）と、
   ‐前記遠隔システムから、前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）にアクセスすることの要求を受信すること（Ｓ３）と、
   ‐前記医療デバイス（１０）に遠隔アクセスするための前記構成された少なくとも１つのアクセス基準を前記要求が満たすと、前記要求を前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）に転送すること（Ｓ５ａ）と、を有する、方法。
2. 請求項１に記載の方法であって、前記方法は、
   ‐前記医療デバイスをスタート・アップすること（Ｓ０）を有し、
   前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）にアクセスすることのすべての要求は、前記スタート・アップ中に前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）によってブロックされる、方法。
3. 請求項１又は２に記載の方法であって、前記方法は、前記構成された少なくとも１つのアクセス基準を満たさない、前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）にアクセスすることの要求をブロックすること（Ｓ５ｂ）を有する、方法。
4. 請求項１乃至３の何れか１項に記載の方法であって、前記少なくとも１つのアクセス基準は、
   ‐前記要求の送信者又は発信元が認証されることと、
   ‐前記要求メッセージが、許可された要求タイプを含むことと、
   ‐前記要求メッセージが、許可された機能に関することと、
   ‐単位時間当たりの受信要求数が閾値を超えないことと、
   のうちの少なくとも１つを含む、方法。
5. 請求項１乃至４の何れか１項に記載の方法であって、前記少なくとも１つのアクセス基準は、異なる送信者、要求のタイプ、及び／又は機能についての個別の規則を含む、方法。
6. 請求項１乃至５の何れか１項に記載の方法であって、前記構成すること（Ｓ１）は、オペレータから前記構成データを受信し、及び／又は前記医療デバイス（１０）に記憶された構成データを読み出し、前記受信された構成データに基づいて前記少なくとも１つのアクセス基準を構成することを含む、方法。
7. 請求項１乃至６の何れか１項に記載の方法であって、前記転送すること（Ｓ５ａ）は、前記医療デバイス（１０）と遠隔システム（２０）との間の通信に使用されるプロトコルとは異なる及び／又は当該プロトコルから独立したプロトコルを使用して前記要求を転送することを含む、方法。
8. 請求項１乃至７の何れか１項に記載の方法であって、前記医療デバイスは、プロセッサ（１６１）の集合を備え、前記１つ以上の医療プロセス及び前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）は両方とも、プロセッサ（１６１）の前記集合のうちの同じ１つ以上のプロセッサによって実行される、方法。
9. 請求項１乃至８の何れか１項に記載の方法であって、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）と前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）とが別個であることは、それらが別個のメモリ空間、個別のプロセス状態を有し、及び／又はプロセス間通信を使用して通信していることを意味する、方法。
10. 請求項１乃至９の何れか１項に記載の方法であって、前記１つ以上の医療プロセスにアクセスすることの前記要求は、
    ‐前記医療デバイス（１０）を遠隔制御することの要求と、
    ‐前記医療デバイス（１０）内のソフトウェアを更新することの要求と、
    ‐前記医療デバイス（１０）の時刻を設定することの要求と、
    ‐前記医療デバイス（１０）からログ・データを受信することの要求と、
    ‐前記医療デバイス（１０）の構成を更新することの要求と、
    ‐前記医療デバイス（１０）のクレデンシャルを更新することの要求と、
    のうちの少なくとも１つを含む、方法。
11. 請求項１乃至１０の何れか１項に記載の方法であって、前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）に、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）よりも、前記医療デバイス（１０）の処理能力に対する高いプライオリティを与えることを有する、方法。
12. 医療処置を実行するための医療デバイスであって、
    ‐プロセッサ（１６１）の集合と、
    ‐プロセッサ（１６１）の前記集合による実行のためのソフトウェア・システムを記憶するメモリ・ユニット（１６３）の集合と、
    ‐１つ以上の遠隔システム（２０）との通信を可能にする通信インタフェース（１６２）と、を備え、
    前記ソフトウェア・システムは、プロセッサ（１６１）の前記集合によって実行される場合に、前記医療デバイスを動作させるように構成され、
    前記ソフトウェア・システムは、前記医療デバイス（１０）の動作に関与する１つ以上の医療プロセス（Ｐ_ＭＥＤ）と、前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）とは別個の遠隔通信プロセス（Ｐ_ＣＯＭＭ）とを備え、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）は、前記医療デバイス（１０）と１つ以上の遠隔システム（２０）との間の通信を管理するように構成され、前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）は、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）よりも高いプライオリティを有し、
    前記ソフトウェア・システムは、プロセッサの前記集合（Ｐ１～Ｐ４）によって実行される場合に、請求項１乃至１１の何れか１項に記載の方法を実行する、医療デバイス。
13. 医療デバイス（１０）に遠隔アクセスするためのソフトウェア・システムを含むコンピュータ可読媒体であって、前記ソフトウェア・システムは、
    前記医療デバイス（１０）の動作に関与する１つ以上の医療プロセス（Ｐ_ＭＥＤ）と、
    前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）とは別個の遠隔通信プロセス（Ｐ_ＣＯＭＭ）であって、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）は、前記医療デバイス（１０）と１つ以上の遠隔システム（２０）との間の通信を管理するように構成される、遠隔通信プロセス（Ｐ_ＣＯＭＭ）と、を含み、
    前記１つ以上の医療プロセス（Ｐ_ＭＥＤ）は、前記遠隔通信プロセス（Ｐ_ＣＯＭＭ）よりも高いプライオリティを有し、前記ソフトウェア・システムは、前記医療デバイス（１０）のプロセッサの集合によって実行される場合に、請求項１乃至１１の何れか１項に記載の方法を実行する、コンピュータ可読媒体。

Images