(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-04
(45)【発行日】2024-10-15
(54)【発明の名称】医療デバイス及び医療デバイスの遠隔制御のための方法
(51)【国際特許分類】
G16H 40/67 20180101AFI20241007BHJP
A61M 1/14 20060101ALI20241007BHJP
A61M 1/28 20060101ALI20241007BHJP
【ＦＩ】
G16H40/67
A61M1/14 100
A61M1/28 130
【請求項の数】
16
(21)【出願番号】P 2021556900
(86)(22)【出願日】2020-04-16
(65)【公表番号】
(43)【公表日】2022-06-27
(86)【国際出願番号】 EP2020060643
(87)【国際公開番号】W WO2020216664
(87)【国際公開日】2020-10-29
【審査請求日】2023-01-23
(31)【優先権主張番号】19170756.1
(32)【優先日】2019-04-24
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】501473877
【氏名又は名称】ガンブロ・ルンディア・エービー
【氏名又は名称原語表記】ＧＡＭＢＲＯ ＬＵＮＤＩＡ ＡＢ
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】ヨハネッソン， カミーラ
(72)【発明者】
【氏名】リンダルト， ミカエル
(72)【発明者】
【氏名】メビウス， ニクラス
【審査官】梅岡 信幸
(56)【参考文献】
【文献】米国特許出願公開第２０１７／０３７２６００（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１９／００２９６３０（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ１６Ｈ １０／００－８０／００
Ａ６１Ｍ １／００－ １／３８
(57)【特許請求の範囲】
【請求項1】
遠隔システム（２０）が医療デバイス（１０）を遠隔制御することを可能にするように前記医療デバイス（１０）を動作させる方法であって、前記医療デバイス（１０）は、医療処置を制御するように構成された１つ以上のアクチュエータ（１７）を備え、前記医療デバイス（１０）は、前記医療処置中の前記医療デバイス（１０）の動作に関与する１つ以上の医療プロセス（ＰＭＥＤ）と、前記１つ以上の医療プロセス（ＰＭＥＤ）とは別個の遠隔制御プロセス（ＰＲＣ）とを含むソフトウェア・システムによって制御され、前記遠隔制御プロセス（ＰＲＣ）は、前記遠隔システム（２０）からの前記医療デバイス（１０）の遠隔制御を管理するように構成され、前記方法は、‐前記遠隔制御プロセス（ＰＲＣ）によって、前記遠隔システム（２０）から、前記１つ以上のアクチュエータ（１７）の遠隔制御を要求するアクティブ化要求を受信すること（Ｓ２）と、
‐前記医療処置がアイドルであることを含む少なくとも１つの事前に決定された第１基準が満たされると（Ｓ３）、前記１つ以上のアクチュエータ（１７）の制御のオーナーシップを前記１つ以上の医療プロセス（ＰＭＥＤ）から前記遠隔制御プロセス（ＰＲＣ）に引き渡すこと（Ｓ６）と、
‐前記１つ以上のアクチュエータ（１７）の制御のオーナーシップが引き渡されたことに応じて、前記遠隔制御プロセス（ＰＲＣ）によって、前記遠隔システム（２０）へアクティブ化確認を送信すること（Ｓ７）であって、前記アクティブ化確認は、前記１つ以上のアクチュエータ（１７）の遠隔制御がアクティブであることを示す、ことと、を有する方法。
【請求項2】
請求項１に記載の方法であって、前記少なくとも１つの事前に決定された第１基準は、
・前記医療デバイスのサービスがアイドルであることと、
・安全性を危険にさらすことなく制御を引き渡すことができることと、
・前記遠隔システム（２０）が既知であり、認可されていることと、
のうちの少なくとも１つを含む、方法。
【請求項3】
請求項１又は２に記載の方法であって、前記１つ以上のアクチュエータ（１７）は、前記医療デバイスがスイッチ・オンされる各個別の時点において、前記１つ以上の医療プロセス（ＰＭＥＤ）又は前記遠隔制御プロセス（ＰＲＣ）のいずれかによって所有される、方法。
【請求項4】
請求項１乃至３の何れか１項に記載の方法であって、前記遠隔制御プロセス（ＰＲＣ）と前記１つ以上の医療プロセス（ＰＭＥＤ）とが別個であることは、それらが別個のメモリ空間、異なるプライオリティ、個別のプロセス状態を有し、及び／又はプロセス間通信を使用して通信していることに対応する、方法。
【請求項5】
請求項１乃至４の何れか１項に記載の方法であって、‐前記１つ以上のアクチュエータ（１７）の制御のオーナーシップを前記１つ以上の医療プロセス（ＰＭＥＤ）から前記遠隔制御プロセス（ＰＲＣ）に引き渡す前に、前記１つ以上のアクチュエータ（１７）を制御された状態に設定すること（Ｓ５）を有する、方法。
【請求項6】
請求項１乃至５の何れか１項に記載の方法であって、‐前記遠隔制御プロセス（ＰＲＣ）によって、前記遠隔システム（２０）から、前記１つ以上のアクチュエータ（１７）を制御するための制御データを受信すること（Ｓ８）と、
‐前記遠隔制御プロセス（ＰＲＣ）によって、遠隔制御がアクティブになると、前記制御データに基づいて前記１つ以上のアクチュエータを制御すること（Ｓ１０）と、を有する、方法。
【請求項7】
請求項６に記載の方法であって、前記制御データは、‐前記１つ以上のアクチュエータによって使用される１つ以上のアクチュエータ設定値と、
‐バルブを開く及び／又は閉じるようにアクチュエータを制御するデータと、
‐前記医療デバイス内のデバイスの回転速度を調整するためにアクチュエータを制御するデータと、
のうちの少なくとも１つを含む、方法。
【請求項8】
請求項１乃至７の何れか１項に記載の方法であって、‐前記遠隔制御プロセス（ＰＲＣ）によって、前記１つ以上のアクチュエータ（１７）の遠隔制御を非アクティブ化することを前記医療デバイス（１０）に要求する非アクティブ化要求を遠隔システム（２０）から受信すること（Ｓ１１）と、
‐前記遠隔制御プロセス（ＰＲＣ）によって、前記１つ以上のアクチュエータ（１７）を制御された状態に設定し（Ｓ１２）、前記１つ以上のアクチュエータのうちの１つ以上のものの制御のオーナーシップを引き戻す（Ｓ１３）ことと、
‐オーナーシップが引き戻されたことに応じて、前記遠隔制御プロセス（ＰＲＣ）から前記遠隔システムへ、前記１つ以上のアクチュエータ（１７）の遠隔制御が非アクティブとなったことを示す解放確認を送信すること（Ｓ１４）と、を有する、方法。
【請求項9】
請求項１乃至８の何れか１項に記載の方法であって、前記医療デバイス（１０）は、前記医療処置を監督するように構成された保護システムを含み、前記方法は、‐前記少なくとも１つの事前に決定された第１基準が満たされると、前記保護システムを非アクティブ化すること（Ｓ４）を有する、方法。
【請求項10】
請求項９に記載の方法であって、前記保護システムは、前記１つ以上の医療プロセス（ＰＭＥＤ）とは別個の監督プロセス（ＰＳ）を含み、前記監督プロセス（ＰＳ）は、１つ以上の補助アクチュエータ（１７´）を使用して前記保護システムを制御するように構成され、前記方法は、‐事前に決定された第２基準が満たされると（Ｓ４１）、前記監督プロセスから前記保護システム（ＳＳ３）の遠隔制御プロセス（ＰＳ‐ＲＣ）に前記１つ以上の補助アクチュエータ（１７´）の制御のオーナーシップを引き渡すこと（Ｓ４３）を有し、
前記保護システムの前記遠隔制御プロセス（ＰＳ‐ＲＣ）が前記監督プロセス（ＰＳ）から前記１つ以上の補助アクチュエータ（１７´）の制御のオーナーシップを引き継ぐことに応じて、前記アクティブ化確認が送信される、方法。
【請求項11】
請求項１０に記載の方法であって、前記事前に決定された第２基準は、‐前記医療処置がアイドルであることと、
‐前記保護システム（Ｐ３）が非アクティブ又はアイドルであることと、
‐安全性を危険にさらすことなく制御を引き渡すことができることと、
‐前記遠隔システム（２０）が既知であり、認可されていることと、
を含む、方法。
【請求項12】
請求項１乃至１１の何れか１項に記載の方法であって、前記１つ以上のアクチュエータ（１７）の制御のオーナーシップは、前記遠隔制御プロセス（ＰＲＣ）が前記１つ以上のアクチュエータ（１７）を制御するパラメータを変更することを可能にするインタフェースへの書き込みのオーナーシップを前記遠隔制御プロセス（ＰＲＣ）に与えることによって引き渡される、方法。
【請求項13】
請求項１乃至１２の何れか１項に記載の方法であって、前記１つ以上のアクチュエータ（１７）は、前記医療処置の実行中に使用されるバルブと、ポンプと、ヒータとのうちの少なくとも１つを制御するように構成される、方法。
【請求項14】
請求項１乃至１３の何れか１項に記載の方法であって、‐前記遠隔システム（２０）が前記医療デバイス（１０）の前記動作を監視することを可能にするセンサ・データを前記遠隔システムに提供すること（Ｓ１）を有する、方法。
【請求項15】
医療処置を実行するように構成された医療デバイス（１０）であって、前記医療デバイス（１０）は、‐前記医療処置を制御するように構成された１つ以上のアクチュエータ（１７）と、
‐遠隔システム（２０）との通信を可能にするように構成された通信インタフェース（１６２）と、
‐プロセッサ（１６１）の集合と、プロセッサの前記集合による実行のためのソフトウェア・システムを記憶するメモリ（１６３）とを備え、前記ソフトウェア・システムは、前記医療処置中に前記医療デバイス（１０）の動作に関与する１つ以上の医療プロセス（ＰＭＥＤ）と、前記１つ以上の医療プロセス（ＰＭＥＤ）とは別個の遠隔制御プロセス（ＰＲＣ）とを含み、前記遠隔制御プロセス（ＰＲＣ）は、前記遠隔システム（２０）からの前記医療デバイス（１０）の遠隔制御を管理するように構成され、前記ソフトウェア・システムは、プロセッサの前記集合によって実行される場合に、請求項１乃至１４の何れか１項に記載の方法を実行する、医療デバイス（１０）。
【請求項16】
医療処置を実行するように医療デバイス（１０）を動作させるためのソフトウェア・システムを含むコンピュータ可読媒体であって、前記ソフトウェア・システムは、前記医療処置中に前記医療デバイス（１０）の動作に関与する１つ以上の医療プロセス（ＰＭＥＤ）と、前記１つ以上の医療プロセス（ＰＭＥＤ）とは別個の遠隔制御プロセス（ＰＲＣ）とを含み、前記遠隔制御プロセス（ＰＲＣ）は、前記遠隔システム（２０）からの前記医療デバイス（１０）の遠隔制御を管理するように構成され、前記ソフトウェア・システムは、前記医療デバイス（１０）のプロセッサの集合によって実行される場合に、請求項１乃至１４の何れか１項に記載の方法を実行する、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は医療デバイスの分野に関し、より具体的には、自動医療デバイスを遠隔制御するための技術に関する。
【背景技術】
【0002】
自動医療デバイスは、単独で使用されても組み合わせて使用されても、製造者によって医療目的で人間又は動物に使用されることが意図された機械である。このような医療目的は、病気、怪我、又はハンディキャップの診断、予防、観察、治療又は緩和を含んでもよい。
【0003】
自動医療デバイスは、ヘルスケア部門でしばしば使用され、安全かつ効率的であることを保証するために厳格な規制の枠組みの対象となる。
【0004】
一般に、自動医療デバイスは、健康的意義を有しうる誤動作のリスクを軽減するように慎重に設計される必要がある複雑なシステムであるソフトウェア・システム（例えば、医療デバイスにインストールされるもの）によって動作される。ソフトウェア・システムは典型的に、医療治療又は医療診断のような医療処置を医療デバイスに実行させるように構成されたソフトウェアを備える。いくつかの状況では、例えば、テストを実行するために、又はサービス目的で、医療デバイスを遠隔で制御することが望ましいかもしれない。
【0005】
しかし、医療デバイスの制御されていない遠隔アクセスは、例えば医療デバイスによって実行される将来の医療処置について、安全性のリスクを意味しうる。このリスクは、種々の方法で対処されうる。例えば、アーバン・バーニック・ステファン・ドブラベック及びマルコ・メザによる「ソフトウェア動作の医療デバイスのためのセキュアな遠隔管理モジュールの設計」（https://doi.org/10.1515/bmt-2017-0005）は、遠隔管理サービスから通常のデバイス機能を厳密に切り離すことにより、遠隔接続リスクを排除する多層機械設計解決策を提案する。より具体的に、この文書は、ソフトウェア動作の医療デバイスの遠隔更新及び管理のためのモジュラ・システムを提示する。モジュラ・システムは、管理機能と通常動作機能を設計により物理的に分離し、これによって保守スタートアップ・モードの間だけ遠隔操作を可能にし、通常動作中に起こりうるリスクを完全に防止する。この解決策は、限られた数の機能への遠隔アクセス、すなわち、デバイスの動作パラメータへの遠隔アクセス、デバイスの遠隔構成及び管理、及び遠隔デバイス・ソフトウェア更新を可能にする。さらに、この解決策はまた、遠隔アクセスがアクティブ化されるために医療デバイスがリブートされることを必要とする。このように、この遠隔制御は、所定の機能の遠隔制御のみをサポートし、また、通常動作と遠隔制御との間のリスタートを必要とする。したがって、制御された方法で医療デバイスを遠隔制御するより柔軟な方法が必要とされている。
【発明の概要】
【0006】
したがって、本開示の目的は、制御された方法で医療デバイスを遠隔制御することに関連する従来技術の制限を回避することである。特に、医療デバイスをその間にリブートする必要なしに、遠隔システムが医療デバイスのアクチュエータを直接制御する方法を提供することが目的である。医療処置の安全性に影響を及ぼすことなく、医療デバイスの通常動作（すなわち、デフォルトのメイン・システム状態）と医療デバイスのアクチュエータの遠隔制御との間の切り替えを可能にする方法を提供することがさらなる目的である。
【0007】
第１態様によれば、本開示は、遠隔システムが医療デバイスを遠隔制御することを可能にするように医療デバイスを動作させる方法に関する。医療デバイスは、医療処置を制御するように構成された１つ以上のアクチュエータを備える。医療デバイスは、医療処置中の医療デバイスの動作に関与する１つ以上の医療プロセスを含むソフトウェア・システムによって制御される。医療デバイスはまた、遠隔制御プロセスを含む。遠隔制御プロセスは、１つ以上の医療プロセスとは別個である。さらに、遠隔制御プロセスは、遠隔システムからの医療デバイスの遠隔制御を管理するように構成される。本方法は、遠隔システムから遠隔制御プロセスによって、１つ以上のアクチュエータの遠隔制御を要求するアクティブ化要求を受信することを含む。本方法は、少なくとも１つの事前に決定された第１基準が満たされると、１つ以上の医療プロセスから遠隔制御プロセスに、１つ以上のアクチュエータの制御のオーナーシップを引き渡すことをさらに含む。本方法は、遠隔制御プロセスによって、アクティブ化確認を遠隔システム及び／又は医療デバイスのユーザ・インタフェースへ送信することをさらに含む。アクティブ化確認は、１つ以上のアクチュエータの制御のオーナーシップが引き渡されることに応じて送信される。アクティブ化確認は、１つ以上のアクチュエータの遠隔制御がアクティブであることを示す。その後、医療デバイスは、１つ以上のアクチュエータを制御するために、遠隔システムからの遠隔要求に対応する。このようにして、遠隔システムは、医療デバイスのアクチュエータを直接制御してもよく、医療デバイスにおけるソフトウェア・アプリケーションに限定されない。したがって、遠隔システム（又は遠隔システムのオペレータ）は、どのような動作が遠隔で実行されるべきかに関して完全な柔軟性を有する。
【0008】
しかし、遠隔制御は、１つ以上の事前に決定された第１基準が満たされる場合にのみ、例えば、安全であると考えられる場合にのみアクティブ化される。したがって、医療処置の安全性は危険にさらされない。さらに、遠隔操作がアクティブ化される場合に、アクチュエータの制御を専用の遠隔操作プロセスに引き渡すことによって、想定されていない場合に、遠隔システムが誤ってアクチュエータを制御することが回避される。
【0009】
したがって、提案される方法は、医療処置の安全性を危険にさらすことなく、また中間のリブートなしに、医療デバイス上で、例えば診断及び製造テスト・シーケンスを遠隔で実行することを可能にする。より具体的に、提案される方法は、遠隔サービス・センタから医療環境（例えば、病院）内の医療デバイスに対して、例えば診断テストを実行することを可能にする。
【0010】
いくつかの実施形態において、少なくとも１つの事前に決定された第１基準は、医療処置がアイドルであること、医療デバイスのサービスがアイドルであること、安全性を危険にさらすことなく制御を引き渡すことができること、及び遠隔システムが既知であり、認可されていることを含む。したがって、遠隔制御は、特定の制御された状況下でのみアクティブ化されてもよい。
【0011】
いくつかの実施形態において、１つ以上のアクチュエータは、医療デバイスがスイッチ・オンされる各個別の時点で、１つ以上の医療プロセスによって、又は遠隔制御プロセスによって所有される。したがって、アクチュエータが複数のソースから、また場合によっては競合する入力で制御されることが回避される。
【0012】
いくつかの実施形態において、遠隔制御プロセス及び１つ以上の医療プロセスが分離されていることは、それらが別個のメモリ空間、異なるプライオリティ、個別のプロセス状態を有すること、及び／又はプロセス間通信を使用して通信していることを意味する。したがって、プロセスのうちの１つにおけるエラーは、医療デバイスにおける他のプロセスに伝播しえない。
【0013】
いくつかの実施形態において、本方法は、１つ以上のアクチュエータの制御のオーナーシップを１つ以上の医療プロセスから遠隔制御プロセスに引き渡す前に、１つ以上のアクチュエータを制御された状態に設定することを含む。したがって、遠隔制御がアクティブ化される前に、医療デバイスが遠隔制御される準備が整っていることが保証される。
【0014】
いくつかの実施形態において、本方法は、遠隔制御プロセスによって遠隔システムから、１つ以上のアクチュエータを制御するための制御データを受信することと、遠隔制御プロセスによって、遠隔制御がアクティブになると、制御データに基づいて１つ以上のアクチュエータを制御することとを含む。したがって、遠隔制御プロセスは、遠隔制御がアクティブ化された場合にのみ、そのような制御データで動作する。
【0015】
いくつかの実施形態において、制御データは、１つ以上のアクチュエータによって使用される１つ以上のアクチュエータ設定値と、バルブを開く及び／又は閉じるためにアクチュエータを制御するデータと、及び／又は医療デバイス内のデバイスの回転速度を調整するためにアクチュエータを制御するデータとを含む。したがって、医療デバイスのコンポーネントを制御するアクチュエータは、制御データに基づいて直接制御されてもよい。言い換えれば、医療デバイスの多様な機能が遠隔制御されてもよい。
【0016】
いくつかの実施形態において、本方法は、遠隔制御プロセスによって、遠隔システムから非アクティブ化要求を受信することを含む。非アクティブ化要求は、医療デバイスに、１つ以上のアクチュエータの遠隔制御を非アクティブ化することを要求する。本方法は、遠隔制御プロセスによって、１つ以上のアクチュエータを制御された状態に設定することと、１つ以上のアクチュエータの制御のオーナーシップを引き戻すこととをさらに含む。本方法は、遠隔制御プロセスから遠隔システムへ、オーナーシップが引き戻されたことに応じて、１つ以上のアクチュエータの遠隔制御が非アクティブとなったことを示す解放確認を送信することをさらに含む。これにより、遠隔システムは、もはや必要とされない場合に遠隔制御を非アクティブ化できる。
【0017】
いくつかの実施形態において、医療デバイスは、医療処置を監督するように構成された保護システムを備え、本方法は、少なくとも１つの事前に決定された第１基準が満たされると、保護システムを非アクティブ化することを含む。したがって、保護システムは、医療デバイスが治療を実行している間のみアクティブである。したがって、遠隔制御は、さもなければ警報などを発する可能性があるアクティブな監督プロセスを有することなく実行されてもよい。
【0018】
いくつかの実施形態において、保護システムは、１つ以上の医療プロセスとは別個の監督プロセスを含み、監督プロセスは、１つ以上の補助アクチュエータを使用して保護システムを制御するように構成され、本方法は、事前に決定された第２基準が満たされると、１つ以上の補助アクチュエータの制御のオーナーシップを監督プロセスから保護システムの遠隔制御プロセスに引き渡すことを含む。これらの実施形態において、監督プロセスから１つ以上の補助アクチュエータの制御のオーナーシップを保護システムの遠隔制御プロセスが引き継ぐことに応じてアクティブ化確認が送信される。したがって、保護システムの遠隔制御状態を制御するのはメイン・システムである。これにより、メイン・システムと保護システムとが異なる遠隔制御状態にある（すなわち、一方が「遠隔制御アクティブ」であり、他方が「遠隔制御非アクティブ」である）ことが回避される。
【0019】
いくつかの実施形態において、事前に決定された第２基準は、医療処置がアイドルであること、保護システムが非アクティブ又はアイドルであること、安全性を危険にさらすことなく制御を引き渡すことができること、及び／又は遠隔システムが既知であり、認可されていることを含む。したがって、１つ以上の医療プロセスはアクティブであり、例えば、サービスが進行中である場合、又はそれが不適切であると考えられる他の状況で治療を実行する間に、監督プロセスは、遠隔制御のためにその監督をオフにすることができないかもしれない。
【0020】
いくつかの実施形態において、１つ以上のアクチュエータの制御のオーナーシップは、遠隔制御プロセスに、インタフェースへの書き込みのオーナーシップを与え、それによって遠隔制御プロセスが１つ以上のアクチュエータを制御するパラメータを変更することを可能にすることによって引き渡される。言い換えれば、オーナーシップは、すべてのプロセスが各時点で誰がオーナーであるかを認識していることを意味する。したがって、プロセスは、それらがアクチュエータの制御のオーナーである場合にのみ、インタフェースに書き込む権限を有する。
【0021】
いくつかの実施形態において、１つ以上のアクチュエータは、医療処置を実行する間に使用されるバルブ、ポンプ、及びヒータのうちの少なくとも１つを制御するように構成される。したがって、遠隔システムは、アクチュエータを制御することによって医療処置を実行する場合に使用されるハードウェアにアクセスしてもよい。それによって、遠隔システムは、医療デバイスのテスト又はサービスを実行してもよい。
【0022】
いくつかの実施形態において、本方法は、遠隔システムが医療デバイスの動作を監視することを可能にするセンサ・データを遠隔システムに提供することを含む。センサ・データはまた、医療デバイスのテスト又はサービスを実行する間に使用されてもよい。
【0023】
第２態様によれば、本開示は、医療処置を実行するように構成された対応する医療デバイスに関する。医療デバイスは、１つ以上のアクチュエータと、通信インタフェースと、プロセッサの集合と、メモリとを備える。１つ以上のアクチュエータは、医療処置を制御するように構成される。通信インタフェースは、遠隔システムとの通信を可能にするように構成される。メモリは、プロセッサの集合による実行のためのソフトウェア・システムを記憶している。ソフトウェア・システムは、医療処置中の医療デバイスの動作に関与する１つ以上の医療プロセスと、１つ以上の医療プロセスとは別個の遠隔制御プロセスとを含む。遠隔制御プロセスは、遠隔システムからの医療デバイスの遠隔制御を管理するように構成される。さらに、ソフトウェア・システムは、プロセッサの集合によって実行されると、第１態様にしたがって方法を実行する。
【0024】
第３態様によれば、本開示は、医療処置を実行するように医療デバイスを動作させるためのソフトウェア・システムを備えるコンピュータ可読媒体に関し、ソフトウェア・システムは、医療処置中の医療デバイスの動作に関与する１つ以上の医療プロセスと、１つ以上の医療プロセスとは別個の遠隔制御プロセスとを含み、遠隔制御プロセスは、遠隔システムからの医療デバイスの遠隔制御を管理するように構成され、ソフトウェア・システムは、医療デバイスのプロセッサの集合によって実行されると、第１態様による方法を実行する。
【図面の簡単な説明】
【0025】
【図1a】、
【図1b】、
【図1c】開示された技術の実施形態を実施してもよい医療デバイスを説明する。
【図2b】医療デバイスを遠隔制御するように構成された遠隔システムを説明する。
【図3a】、
【図3b】医療デバイスを動作させるためのソフトウェア・システムを概念的に説明する。
【図4a】、
【図4b】、
【図4c】遠隔システムが医療デバイスを遠隔制御することを可能にするように医療デバイスを動作させるための方法のフローチャートである。
【図5a】、
【図5b】、
【図5c】１つの例示の実装による提案された方法を実行する場合の医療デバイスのソフトウェア・システムのプロセス間の内部シグナリングのシーケンス図である。
【発明を実施するための形態】
【0026】
本開示は、医療デバイスの制御アクチュエータへの遠隔システム・アクセスを与える柔軟な方法を提案し、これは特別なモードで医療デバイスをリスタートする必要がない。その代わりに、本書では、遠隔制御を扱うために専用プロセスを使用することが提案される。このプロセスは、遠隔システムからの要求を受信し、遠隔制御がアクティブ化される場合にのみこれらの要求に対応するように構成されている。特定のアクティブ化手順は、遠隔制御をアクティブ化するために使用される。アクティブ化手順は、例えば進行中又は将来の治療に対する安全性を危険にさらすことなく、遠隔制御が起動されうることを検証してもよい。医療デバイスは、遠隔制御機能が最初に首尾よくアクティブ化された場合に、医療デバイスのアクチュエータを遠隔制御することの要求を処理するだけである。いくつかの実施形態において、遠隔制御下で実行される動作が将来の医療処置に影響を及ぼさないように、医療デバイスを通常動作モードにするために非アクティブ化手順が使用される。このようにして、制御された条件下で、遠隔システムが医療デバイスのアクチュエータを直接制御することを可能にすることができる。
【0027】
本発明をより良く理解するために、いくつかの例示的な医療デバイスが最初に記載される。医療デバイスは、オプションで１つ以上の他の医療デバイスと組み合わせて、人間又は動物の対象に関して医療処置を実行するように動作するように構成された自動装置又は機械である。本書で使用されるように、医療処置は、病気、怪我、又はハンディキャップの診断、予防、観察、処置若しくは緩和、又はそれらの検出のための観察のうちの１つ以上を含んでもよい。
【0028】
図１ａは、例えば血液透析、血液透析濾過、血液濾過、又は単離限外濾過のような腎機能代替療法の一部として、体外血液処置を行う医療処置に関与してもよい２つの例示的な医療デバイス１０、１０´を説明する。１０で示される医療デバイスは血液処理装置であり、これは、例えば血管アクセスにおいて、対象１００の循環系に接続するための血液採取ライン１１Ａ及び血液戻りライン１１Ｂを備える。矢印で示されるように、医療デバイス１０は、対象１００から血液を採取し、透析器（図示せず）内で血液を処理し、処理された血液を、例えば血液ポンプによって制御された方法で対象１００に戻すように動作可能である。透析器では、血液は半透膜の一方の側を通過し、透析流体は当該膜の他方の側を通過する。膜は廃棄粒子及び水が血液から透析流体に移動することを可能にし、所望の粒子が透析流体から血液に移動することを可能にする。血液処理装置１０はまた、シリンジ・ポンプによって駆動されるシリンジを含んでもよく、シリンジは、ヘパリン注入又はカルシウム注入のために使用される。１０´で示される医療デバイスは、血液処理装置１０によって使用される流体を準備するように動作可能であり、流体を血液処理装置１０に供給するための流体ライン１１を備える。１つの例で、医療デバイス１０´は水調製装置であり、流体は精製水である。例えば、水処理装置１０´は、当技術分野で知られているように、逆浸透によって入ってくる水を濾過してもよい。
【0029】
説明される例において、医療デバイス１０は、ディスプレイ１２と、制御ボタン１３（１つが示されている）と、インジケータ・ランプ１４と、ラウドスピーカ１５と、制御システム１６と、血液採取ライン１１Ａ及び血液戻りライン１１Ｂを介して対象１００への血液の制御された採取、処理、及び戻りを行うための１つ以上のアクチュエータ１７と、血液処理装置によって行われる医療処置を示すセンサ・データを提供するための１つ以上のセンサ１８とを備える。医療処置はまた、例えば、プライミング及び機能チェックを含んでもよい。アクチュエータ１７及びセンサ１８は、医療デバイス１０の内部コンポーネント（破線で示す）又は外部コンポーネント、あるいはその両方を含んでもよい。
【0030】
アクチュエータ１７は例えば、医療処置が実行される間、バルブ、ポンプ、及び／又はヒータを制御するように構成される。言い換えると、アクチュエータ１７は、医療処置を制御するように構成される。アクチュエータ１７及びセンサ１８はまた、医療処置を監督するために使用される補助センサ１８´及び補助アクチュエータ１７´を備えてもよい。補助アクチュエータ１７´は例えば、医療手順を中断するための緊急バルブ又は緊急ブレーキを制御するように構成される。例えば流体流速を変更するために、ユーザは典型的に、ディスプレイ１２上に生成された、例えばグラフィカル・ユーザ・インタフェース（ＧＵＩ）を介して、又は制御ボタン１３を使用して、流体流量の設定値を入力する。その後、この設定値は１つ以上のアクチュエータ設定値、すなわち、対応するアクチュエータを制御する値に変換される。例えば、３００ｍｌ／分の流体流速（設定値）は例えば、ｒｐｍ又はパーセントのポンプ速度（アクチュエータ設定値）に変換される。
【0031】
制御システム１６は、血液処理装置の意図された医療処置を実行するために、ならびに医療処置に関連して必要に応じてディスプレイ１２、インジケータ・ランプ１４、及びラウドスピーカ１５を動作させるために、アクチュエータ１７及びセンサ１８の動作を調整し、制御ボタン１３を介してユーザ入力を取得するように構成される。例えば、ディスプレイ１２は医療デバイス１０のユーザに命令を提示するように動作されてもよく、インジケータ・ランプ１４は医療デバイス状態を示すように動作されてもよく、ラウドスピーカ１５はアラーム信号などを生成するように動作されてもよい。
【0032】
医療デバイス１０は、遠隔システム２０（１つのみが示されているが、複数であってもよい）に接続されている。遠隔システム２０は例えば、医療デバイスを遠隔監視及び／又は制御するように構成される。遠隔システム２０については、図２ｂでさらに説明される。
【0033】
医療デバイス１０´は、説明される詳細さのレベルにおいて、医療デバイス１０と同様のコンポーネントの集合を有してもよく、これ以上説明しない。医療デバイス１０´は、医療デバイス１０と同様に、遠隔システム２０にも接続されている。医療デバイス１０、１０´は、簡潔にするために本書では説明しない、図示されているよりも多くのコンポーネントを含んでもよい。
【0034】
図１ｂは、制御された方法で、対象１００の腹腔に透析液を輸送し、続いて、両頭矢印によって示されるように、そこから透析液を除去するように動作可能である別の例示的な医療デバイス１０を説明する。この医療処置は一般に自動腹膜透析として知られており、医療デバイス１０はしばしば「ＰＤサイクラ」と呼ばれる。ＰＤサイクラは例えば、透析液の混合、輸送及び除去のいずれかのためのポンプを含む。図１ｂの医療デバイス１０は、図１ａの医療デバイス１０と比較して、説明される詳細さのレベルで同様の（しかし、典型的には減少された）コンポーネントの集合を有してもよく、また、遠隔システム２０に接続されてもよい。図１ｂの医療デバイス１０は、簡潔にするために本書で説明されない、図示されているよりも多い又は少ないコンポーネントを含んでもよい。医療デバイス１０はまた、透析液を混合するために使用される精製水を得るために、図１ａに示されるように、別の医療デバイス１０´に接続されてもよい。
【0035】
図１ｃは、矢印によって示されるように、制御された方法で、例えば対象１００の循環系に、人間のような対象１００の身体に医療流体を輸送するように動作可能であるさらなる例示的な医療デバイス１０を説明する。医療流体は薬物及び／又は栄養素を含むが、これらに限定されない任意の適切な流体であってもよい。このタイプの医療デバイス１０は、一般に「注入ポンプ」として知られている。注入ポンプの１つ以上のアクチュエータは、指定された速度で薬物及び／又は栄養素を対象１００に送り込むように１つ以上のポンプを制御するように構成される。ライン・オクルーダ及び／又はバルブは、ポンピング中に流体流量を制御するために作動される。図１ｃの医療デバイス１０は、同様の（しかし、典型的には減少された）コンポーネントの集合を有してもよく、説明される詳細さのレベルで図１ｂの医療デバイス１０のように遠隔システム２０に接続されてもよく、さらに説明されない。図１ｃの医療デバイス１０は、簡潔にするために本書では説明されない、図示されているよりも多くのコンポーネントを含んでもよい。
【0036】
図２ａは、１つの例示的な実施形態による、図１ａ～ｃの例示的な医療デバイスのいずれかの制御システム１６をより詳細に説明する。制御システム１６は、プロセッサ１６１と、通信インタフェース１６２と、メモリ１６３とを備える。プロセッサ１６１は、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、マイクロコントローラ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、又は任意の他の電子プログラマブル論理デバイス、又はそれらの組合せのような任意の市販の処理デバイスであってもよい。
【0037】
通信インタフェース１６２は、遠隔システム２０（図１ａ～ｃ）との通信を可能にするように構成される。通信は、ワイヤレス及び／又は有線であってもよい。有線通信は、有線イーサネット（登録商標）接続、ＲＳ－２３２、ＲＳ－４８５、又はＵＡＲＴを使用して実行されてもよい。ワイヤレス通信は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、Ｚ－Ｗａｖｅ（登録商標）、ワイヤレス・ユニバーサル・シリアル・バス（「ＵＳＢ」）、赤外線プロトコルのいずれか、又はその他の適切なワイヤレス通信技術を介して実行されてもよい。通信インタフェース１６２は例えば、プロセッサ１６１によって制御されるように構成されたＢｌｕｅｔｏｏｔｈチップである。遠隔システム２０と医療デバイスとの間の通信は、インターネット・プロトコル又は独自のプロトコルのような、任意の適切な通信プロトコルを使用して実行されてもよい。
【0038】
メモリ１６３は、リード・オンリ・メモリ（ＲＯＭ）、プログラマブル・リード・オンリ・メモリ（ＰＲＯＭ）、電気的消去可能プログラマブル・リード・オンリ・メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、リムーバブル・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、スタティックＲＡＭ、キャッシュ・メモリ、ハード・ドライブ、記憶媒体などを含んでもよいがこれらに限定されない、不揮発性メモリ又は揮発性メモリ、あるいはこれらの組合せを含んでもよい。メモリ１６３は、プロセッサ１６１による実行のためのソフトウェア・システムを記憶する。ソフトウェア・システムは、特定の機能又は機能の集合を実現するように編成されたソフトウェア・アイテムの統合された集まりであり、医療デバイスに関するＩＳＯ規格ＩＥＣ６２３０４を参照されたい。ソフトウェア・システムは、アプリケーション・ソフトウェアと、ソフトウェア・アプリケーションを管理し、医療デバイスのアプリケーションとハードウェアとの間の仲介として機能するソフトウェア・プラットフォーム（典型的には、オペレーティング・システムを含む）とを含む。ソフトウェア・システムは、通信インタフェース１６２を介して遠隔システム２０によってアクセスされてもよい。
【0039】
ソフトウェア・システムは、本書に記載する動作を実行するためにプロセッサ１６１によって実行可能なメモリ１６３に記憶された１つ以上の命令によって特定される。ソフトウェア・システムは、例えば医療処置を実行するように医療デバイス１０を制御するように構成される。言い換えると、ソフトウェア・システムは、医療処置中の医療デバイス１０の動作に関与する１つ以上の医療プロセスＰＭＥＤと、１つ以上の医療プロセスＰＭＥＤとは別個の遠隔制御プロセスＰＲＣとを含む。プロセスが互いに分離されているというコンセプトは以下の図４ａ～４ｃに関連してさらに説明される。遠隔制御プロセスＰＲＣは、遠隔システム２０からの医療デバイス１０の遠隔制御を管理するように構成される。ソフトウェア・システムは、プロセッサ１６１によって実行される場合に、以下に詳細に説明する第１態様（図４ａ～ｃ）の方法を実行する。
【0040】
プロセッサ１６１及びメモリ１６３は、それらが個別に動作可能なユニットであるという意味で「別個」であるが、それらは例えば集積回路のような共通の基板上に任意の組合せで配置されてもよいし、配置されなくてもよい。簡単にするために、図２ａの制御システム１６は、１つのプロセッサ１６１及びメモリ１６３のみを備えるものとして示されている。しかし、医療デバイス１０は、１つ以上のプロセッサ１６１を備えるプロセッサの集合を備えてもよく、メモリ１６３は１つ以上の記憶デバイスによって実装されてもよいことが理解されるべきである。
【0041】
図２ｂは、例示的な遠隔システム２０をさらに詳細に説明する。遠隔システム２０は、医療デバイスの一体化された部分ではない任意のシステムであり、より具体的に、医療デバイス１０の制御システム１６のプロセッサ１６１の集合によって実行されるソフトウェア・システムである。遠隔システム２０は例えば、サービス又はサポート・システムである。遠隔システムは、サーバ、ワークステーション・ラップトップ、コンピュータ等のうちの１つ以上を含んでもよい。実際には、任意の処置を、医療処置でさえも、遠隔で実行することが可能である。遠隔システム２０は、オンサイトに配置されてもよいし、オフサイトに配置されてもよい。最も単純な形態では、遠隔システムは、タブレット又はパーソナル・コンピュータのようなユーザ・デバイスであり、これはそこに設置された医療デバイス１０を遠隔制御するように構成されたソフトウェアを有する。遠隔システム２０は、プロセッサ２１と、通信インタフェース２２と、メモリ２３とを備える。プロセッサ２１は、ＣＰＵ、ＤＳＰ、マイクロプロセッサ、ＦＰＧＡ、ＡＳＩＣ、又は任意の他の電子プログラマブル論理デバイス、又はそれらの組合せなどのような任意の市販の処理デバイスであってもよい。
【0042】
通信インタフェース２２は、医療デバイス１０との通信を可能にするように構成される。通信は、ワイヤレス及び／又は有線であってもよい。有線通信は、有線イーサネット接続、ＲＳ－２３２、ＲＳ－４８５、又はＵＡＲＴを使用して実行されてもよい。ワイヤレス通信は、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、Ｚｉｇｂｅｅ、Ｚ－Ｗａｖｅ、ワイヤレス・ユニバーサル・シリアル・バス（「ＵＳＢ」）、赤外線プロトコルのいずれか、又はその他の適切なワイヤレス通信技術を介して実行されてもよい。通信インタフェース２２は例えば、プロセッサ２１によって制御されるように構成されたＢｌｕｅｔｏｏｔｈチップである。遠隔システム２０と医療デバイス１０との間の通信は、インターネット・プロトコル又は独自のプロトコルのような任意の適切な通信プロトコルを使用して実行されてもよい。
【0043】
メモリ２３は、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、リムーバブル・メモリ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、キャッシュ・メモリ、ハード・ドライブ、記憶媒体等を含むがこれらに限定されない不揮発性メモリ又は揮発性メモリ、又はこれらの組合せを含んでもよい。メモリ２３は、プロセッサ２１による実行のためのソフトウェアを記憶する。ソフトウェアは例えば、例えばサービス、サポートを実行するように医療デバイス１０を制御するように構成される。
【0044】
簡単にするために、図２ｂの遠隔システム２０は、ただ１つのプロセッサ２１及びメモリ２３を備えるものとして示されている。しかし、遠隔システム２０はいくつかのプロセッサを含んでもよく、メモリ２３は１つ以上の記憶デバイスによって実装されてもよいことが理解されるべきである。
【0045】
遠隔システム２０は、通信インタフェース２２を介して、医療デバイス１０から、例えばセンサ１８によって提供されるセンサ・データのような情報を受信するように構成される。遠隔システム２０はまた、例えばサービス、テスト（例えば、診断テスト又は製造テスト）、又は他のサポート手順を実行するためにアクチュエータ１７を遠隔制御するための遠隔制御情報を医療デバイス１０へ送信してもよい。例えば、遠隔制御情報は、１つ以上のアクチュエータ設定値を含む。したがって、医療デバイス１０は、遠隔制御情報を変換する必要がない。通信は、典型的には通信インタフェース２２を介して通信されるメッセージを用いて実施される。メッセージは種々のコマンド（要求及び応答）を示してもよく、又はデータ（例えば、アクチュエータ制御データ及び／又はセンサ・データ）を搬送してもよい。
【0046】
遠隔制御は例えば、遠隔システム２０において、ソフトウェア・アプリケーション、例えば、診断テスト又は製造テストを実行することによって実行される。したがって、いくつかの実施形態において、遠隔システム２０は、医療デバイス１０のアクチュエータ１７を制御する遠隔制御情報を生成するように構成されたソフトウェア・アプリケーションを備える。このようなソフトウェア・アプリケーションは、医療デバイス１０を変更することなく、ニーズに基づいて追加されてもよく、これにより、診断及びサポートの柔軟性が増すことに留意されたい。
【0047】
代替的に、遠隔システム２０は、遠隔制御がアクティブ化された場合にユーザが医療デバイス１０の個別のアクチュエータ１７を遠隔制御してもよいユーザ・インタフェースを含んでもよい。
【0048】
【0049】
図３ａ及び図３ｂは、提案される技術の非限定的な例による、医療デバイス１０を制御するように構成された例示的なソフトウェア・システムのブロック図である。図３ａは、通常動作中に医療デバイス１０を動作させる場合、例えば医療処置を実行する場合のソフトウェア・システムを示す。図３ｂは、例えばサービス又はテスト目的で医療デバイス１０の動作を遠隔制御する場合のソフトウェア・システムを示す。
【0050】
説明されるソフトウェア・システムは、ＳＳ１～ＳＳ４と表される４つのサブシステムＳＳを含む。サブシステムＳＳ１～ＳＳ４は、医療処置を実行する際の医療デバイスの動作に関して特定の機能を提供するために独立して開発され、テストされうるコンピュータ実行可能命令のソフトウェア・モジュールであると考えられてもよい。各個別のサブシステムは、個別のサブシステムの文脈内で実行されるソフトウェア・プロセス（又はスレッド）で構成される。したがって、サブシステム内のソフトウェア・プロセスは、サブシステムの特定の機能を提供するために、調整されたプロセスのグループを実行するように設計されてもよい。本書のプロセスは、スケジューラによって独立して管理されうる命令のシーケンスを指し、スケジューラは典型的に、医療デバイス１０の制御システム１６のプロセッサ１６１によって実行されるソフトウェア・システムのオペレーティング・システムの一部である。プロセスの実装は、オペレーティング・システムによって異なる。異なるプロセスは、通常、メモリ空間のようなリソースを共有しない。ソフトウェア・プロセスは、Ｌｉｎｕｘ（登録商標）プロセスやグリーン・ヒルズ・インテグリティ・プロセスなどである。オペレーティング・システムは典型的に、所定のセキュリティ・ルールに基づいて着信及び発信ネットワーク・トラフィックを監視し、制御する、Ｎｅｔｆｉｌｔｅｒのような標準のファイアウォールを含む。
【0051】
異なるサブシステムのプロセスは、プロセス間通信（ＩＰＣ）を使用して通信し、ＩＰＣは、プロセスが共有データを管理できるようにするオペレーティング・システムのメカニズムを指す。例えば、プロセス間通信は、クライアント及びサーバを使用し、クライアントはデータを要求し、サーバはクライアントの要求に応答する。プロセス間通信は実装次第である。
【0052】
また、サブシステムが、医療デバイスの動作に関与しない１つ以上のソフトウェア・プロセスを含むことも考えられる。さらに、サブシステムは、他のサブシステムとの通信を管理するための通信スタック、技術的エラーを管理するためのエラー・マネージャ、通知を管理するための通知マネージャなどのような、ソフトウェア・システムにおける基本的な機能又はサービスを実行するミドルウェア及び／又は低レベル・ソフトウェア・コンポーネントのような、さらなるソフトウェア・コンポーネントを含んでもよい。サブシステムのうちの１つ以上は、ハードウェア及びソフトウェア・リソースに関してオペレーティング・システムによって提供されるサービスを利用するために、１つ以上のオペレーティング・システムの上で動作されてもよい。実装に応じて、プロセッサ１６１によって実行されるソフトウェア・システムのサブシステムのオペレーティング・システムは例えば、リアルタイム・オペレーティング・システム、組み込みオペレーティング・システム、シングル・タスキング・オペレーティング・システム、又はマルチ・タスキング・オペレーティング・システム、あるいはそれらの任意の組合せを含んでもよい。また、サブシステムのうちの１つ以上がオペレーティング・システムなしで動作し、医療デバイスのハードウェア・リソースと直接やり取りするように構成されることも考えられる。
【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】
遠隔制御非アクティブ化がデバイス制御又は監督マネージャによって承認されないならば：非アクティブ化要求は、ＳＳ１の遠隔制御マネージャによって拒否され、「遠隔制御非アクティブ化が承認されない」が（ＲＳＣマネージャを介して）遠隔システム２０に返される。
【0131】
遠隔操作されたアクチュエータは、遠隔操作を非アクティブ化する場合に、制御されていない状態である：デバイス制御及び監督は、遠隔制御を非アクティブ化にする場合に、すべてのアクチュエータを制御された状態にする。
【0132】
本発明は現在最も実用的で好ましい実施形態であると考えられるものに関連して説明されてきたが、本発明は開示された実施形態に限定されるべきではなく、反対に、添付の特許請求の範囲の精神及び範囲内に含まれる種々の変形及び均等な構成を包含することが意図されることを理解されたい。
【図1a】
【図1b】
【図1c】
【図2a】
【図2b】
【図3a】
【図3b】
【図4a】
【図4b】
【図4c】
【図5a】
【図5b】
【図5c】