JP6033347B2 - 治療法管理開発プラットホーム - Google Patents

Description

（背景）
本特許は、治療法管理システムおよび方法の開発を対象とし、具体的には、治療法と併せて使用される医療デバイスまたはシステムの構造および／または動作の修正を伴う治療法管理システムおよび方法の開発を対象とする。

病状への治療法または治療は、多くの異なる方法を特徴とし得る。例えば、治療法は、患者の状態の変化に影響を及ぼすように使用される薬物または放射線等の薬剤に関して説明され得る。別の例として、治療法は、投与方法または経路に関して説明され得る。

注入治療法（治療法の静脈内送達（すなわち、血管内への送達））は、当該技術分野において周知である。その最も単純な形態では、注入治療法は、点滴チャンバ、投与セット、およびカテーテルを介して患者に接続された容器またはバックを使用して実施され得る。かかるシステムでは、かかる方法に従い、流体は、重力の影響を受けてバックから患者まで通過する。より複雑なシステムでは、ポンプまたはカフを使用して患者への流体の流動を制御し得る。

注入治療法で使用されるポンプシステムへの改良は、ポンプコントローラの導入を含んできた。ポンプコントローラは、１つ以上のポンプをプログラムするための中心点として使用され得る。ポンプコントローラはまた、ポンプおよび関連するセンサの動作に関する情報を表示するための中心点としても使用され得る。さらに、ポンプコントローラは、ポンプと、センサと、遠隔コンピュータシステム（患者情報および薬学的情報のデータベースのための記録管理システム等）との間の通信のための中心点として使用され得る。

ポンプコントローラの包含に関わらず、注入治療法は、従来、処置を施す１人以上の臨床医の形式で人の介入を伴ってきた。例えば、臨床医は、ポンプからの履歴データまたは治療法に関する患者のチャート（流速、注入された量等）を調査し得る。次いで、臨床医は、このデータを機器から得られ得るデータ等の患者の状態に関する付加的なデータ（例えば、血圧計カフ、心臓モニタ等）、患者のチャート、または直接患者と組み合わせ得る。最終的に、臨床医は、治療法の変更に関して医学的な決断を下す。

したがって、新規の治療法管理技術の開発は、一般的には、臨床医の専門知識に頼り、厳密な調節スキームの課題にも対応しなければならない。薬物送達を例に挙げると、開発は、特定の薬物および特定の送達経路に関して行われる傾向がある。治療法のある変更が自動化されている（例えば、センサ読取りに従って、ポンプがその動作を自動的に修正する）これらの例でさえも、開発は、特定の薬物に対して分離されているか、および／またはシステムを管理するために継続的な集中的な臨床医の関与を必要としている。確実に、焦点の本質は、治療法の広域な普及前に規制承認を得る必要性により影響され、その承認は、かかる独自のシステムの独占的開発および試験後にのみ得られる。開発の単独の本質の１つの影響は、これらのデバイスのそれぞれの供給および支持の付随する問題を抱える、独自の単回使用システムまたは限定的な使用システム、方法および／またはデバイスのまん延である。

下記により詳細に記載するように、本開示は、上述の従来のデバイスおよび方法に対する有利な代替物を実装する、改良されたアセンブリを記載する。

本開示の一態様に従い、治療法管理開発を提供する方法を提供する。該方法は、複数の機能性レベルを有する治療法管理開発プラットホームを提供するステップを含み、該プラットホームは、治療法管理を提供する医療デバイスに対して機能性への第１のアクセスレベルにプラットホームを設定すること、およびプラットホームを使用して医療デバイスの動作を修正することが可能な医療デバイスを含む。該方法はまた、プラットホームの機能性へのアクセスレベルを第２のアクセスレベルに変更する承認の指示を受信するステップと、承認の指示の受信に応じて、プラットホームの機能性への第２のアクセスレベルにプラットホームを設定するステップとを含む。

本開示の別の態様に従い、治療法管理開発プラットホームは、ポンプコントローラに連結されるポンプ入力／出力インターフェースを有する、ポンプコントローラと、インターフェースモジュールコントローラと、モジュールセンサ入力／出力インターフェースとを含む、インターフェースモジュールとを含み、モジュールセンサ入力／出力インターフェースは、少なくとも１つの標準化入力ポートと、少なくとも１つの標準化出力ポートと、少なくとも１つの標準化電力接続とを有する。インターフェースモジュールコントローラは、モジュールセンサ入力／出力インターフェースに連結されたセンサから、およびポンプコントローラからデータを受信し、ポンプコントローラに命令を提供して、ポンプコントローラに連結されたポンプの動作を変化させるように、カスタマイズ可能にプログラムされる。
本発明は例えば、以下の項目を提供する。
（項目１）
治療法管理開発を提供する方法であって、該方法は、
複数の機能性レベルを有する治療法管理開発プラットホームを提供することであって、該プラットホームは、治療法管理を提供することが可能な医療デバイスを含む、ことと、
該医療デバイスに対して該プラットホームを該機能性への第１のアクセスレベルに設定することと、
該プラットホームを使用して、該医療デバイスの動作を修正することと、
該プラットホームの該機能性へのアクセスレベルを第２のアクセスレベルに変更する承認の指示を受信することと、
該承認の指示の受信に応じて、該プラットホームの該機能性への該第２のアクセスレベルに該プラットホームを設定することと
を含む、方法。
（項目２）
各アクセスレベルは、前記医療デバイスの試験における段階に対応し、該段階は、ベンチ試験、動物試験、ヒト臨床試験、およびヒトでの使用のうちの１つを含む、項目１に記載の方法。
（項目３）
前記アクセスレベルを変更する前記承認の指示は、地理的位置と関連し、前記方法は、前記医療デバイスが該地理的位置に配置されているか否かを決定することをさらに含む、項目１または２に記載の方法。
（項目４）
前記医療デバイスの前記動作を修正することは、プロトタイプセンサを有する該医療デバイスを使用すること、または治療法管理を制御するために該医療デバイスによって使用される制御アルゴリズムの動作を変更することを含む、項目１〜３のうちのいずれか一項に記載の方法。
（項目５）
前記医療デバイスの前記動作を修正した後に、前記プラットホームを使用して該医療デバイスを試験することをさらに含む、項目１〜４のうちのいずれか一項に記載の方法。
（項目６）
前記プラットホームを使用して前記医療デバイスを試験することは、仮想の生理学的モデルおよびセンサモデルを使用することを含む、項目５に記載の方法。
（項目７）
前記医療デバイスは、ポンプと、ポンプコントローラとを備える、項目１〜６のうちのいずれか一項に記載の方法。
（項目８）
前記プラットホームの前記アクセスレベルに従って、顧客料金を設定することをさらに含む、項目１〜７のうちのいずれか一項に記載の方法。
（項目９）
（ｉ）ポンプ入力／出力インターフェースを有するポンプコントローラであって、該ポンプ入力／出力インターフェースは該ポンプコントローラに連結される、ポンプコントローラと、
（ｉｉ）インターフェースモジュールコントローラと、モジュールセンサ入力／出力インターフェースとを含むインターフェースモジュールであって、該モジュールセンサ入力／出力インターフェースは、少なくとも１つの標準化入力ポートと、少なくとも１つの標準化出力ポートと、少なくとも１つの標準化電力接続とを有する、インターフェースモジュールと
を備え、
該インターフェースモジュールコントローラは、該モジュールセンサ入力／出力インターフェースに連結されたセンサから、および該ポンプコントローラからデータを受信し、該ポンプコントローラに命令を提供して、そこに連結されたポンプの動作を変化させるように、カスタマイズ可能にプログラムされる、治療法管理開発プラットホーム。
（項目１０）
前記インターフェースモジュールコントローラをカスタマイズ可能にプログラムするために使用されるべきグラフィックユーザインターフェースを有する開発ツールキットをさらに備える、項目９に記載のプラットホーム。
（項目１１）
演算デバイスをさらに備え、前記ツールキットは、該演算デバイス上で動作する、項目１０に記載のプラットホーム。
（項目１２）
前記ツールキットは、コマンドの標準化ライブラリを備える、項目１０または１１に記載のプラットホーム。
（項目１３）
前記ポンプコントローラおよび前記インターフェースモジュールは、無線周波または赤外線の伝送器および受信器を介して無線で通信する、項目９〜１２のうちのいずれか一項に記載のプラットホーム。
（項目１４）
前記インターフェースモジュールは、地理的位置と関連したアクセスレベルの指示を受信し、前記ポンプコントローラおよび該インターフェースモジュールが該地理的位置に配置されているか否かを決定する、項目９〜１３のうちのいずれか一項に記載のプラットホーム。
（項目１５）
前記アクセスレベルの前記指示は、前記ポンプコントローラと関連したポンプの試験における段階に対応し、該段階は、ベンチ試験、動物試験、ヒト臨床試験、およびヒトでの使用のうちの１つを含む、項目１４に記載のプラットホーム。

本開示は、付属の図面と併せてなされる以下の説明からより完全に理解されると考えられる。図面のうちのいくつかは、他の要素をより明確に示す目的のために、選択した要素の省略により簡素化されている場合がある。いくつかの図面における、かかる要素の省略は、対応する書面の説明に明確に記述され得る場合を除き、例示的実施形態のうちのいずれかにおける、特定の要素の存在または欠如を必ずしも示さない。図面のすべては、必ずしも原寸大ではない。
図１は、本開示に従う、治療法管理開発プラットホームの概略図である。 図２は、図１のプラットホームのブロック図である。 図３は、図１に従う、システムのセンサモジュールのためにプログラムを作成する方法のフローチャートである。 図４は、センサモジュールをプログラムする際に使用する開発ツールの例示である。 図５は、本開示に従う、代替的治療法管理開発プラットホームの概略図である。 図６は、図５のプラットホームのブロック図である。 図７は、本開示に従う、さらなる代替的治療法管理開発プラットホームのブロック図である。 図８は、デバイスの承認のための制御された試験フォーマットを提供するための、先述の実施形態に従うシステムを使用する方法のフローチャートである。 図９は、先述の実施形態に従う、システムにより使用される動作プロセスのフローチャートである。 図１０は、例えば、図９の動作プロセスを実施する際に、先述の実施形態に従うシステムにより使用される試験サブプロセスのフローチャートである。 図１１は、例えば、図１０の試験サブプロセスを実施する際に、先述の実施形態に従うシステムにより使用されるプログラム構造サブプロセスのフローチャートである。

以下の文章は、本発明の異なる実施形態の詳細な説明を記載するが、本発明の法的範囲は、本特許の最後に記載される請求項の言葉で規定されることを理解されたい。詳細な説明は、例示目的のみとして解釈されるものであり、不可能ではないにしても、すべての考えられる実施形態を説明することは、実用的ではないので、本発明のすべての考えられる実施形態を説明しない。多くの代替的実施形態は、現在の技術または本特許の出願日後に開発された技術のいずれかを使用して実施することができ、それは、依然として、本発明を規定する請求項の範囲に含まれる。

「本明細書において使用するとき、「＿＿」という用語は、・・・を意味するように規定される」という文章、または同様の文章を使用して用語が本特許において明確に規定されない限り、その用語の意味を、その単純または通常の意味を超えて、明確に、または含蓄的に限定することを意図せず、かかる用語は、本特許の任意のセクションでなされる任意の記述（請求項の言語以外）に基づく範囲に限定されるものと解釈されてはならないことも理解されたい。本発明の最後における請求項に引用される任意の用語が、単一の意味と整合した態様で本明細書において参照される範囲まで、読者を混乱させないように、明確性目的のみのために行われ、かかる請求項の用語は、含蓄的または別様にその単一の意味に限定されることを意図しない。最後に、請求項の要素が「意味する」という単語、および任意の構造の説明を有しない機能を説明することにより定義されない限り、任意の請求項の要素の範囲が、米国特許法第１１２条第６段落の出願に基づいて解釈されることを意図しない。

上述のように、新規の治療管理システムおよび方法の開発は、一般に、臨床医に焦点を置いてきた。この焦点は、多くの治療管理システムおよび方法の実施を誘導する臨床医の経験の程度によって影響され得る。確かに、この焦点は、限界を有し、その限界を、臨床医は、例えば、特定の病状の治療、または特定の送達システムもしくは薬物の使用の際に感じ得る一方、臨床医は、使用する送達システムの実際の設計および動作の際には感じ得ない。実行されなければならない厳密な試験、したがって、必要とされるシステムの構造および動作の知識レベルを考慮すると、新規治療法の一部としての送達システムの変化に対する障壁は、特に、ポンプコントローラ等の高性能な制御デバイスの出現において高い。

一方、医療科学の進歩は、少なくとも機器の変化に関しては、臨床医の技術および経験から、医療デバイス製造者の技術および経験へのシフトから利益を得るであろう。医療デバイスの製造者は、特定の治療法に対する患者の反応を理解する臨床医の高度な知識が欠いているが、医療デバイスおよびシステムの構造および動作についての深い十分な知識を有する。そのため、デバイスの構造および動作の変化は、臨床医よりも製造者にとって、大きな障壁になり得ない。

臨床医／製造者の開発のための従来のモデルが、双方の間の徹底したパートナーシップに関与してきたことを認識しながら、治療法管理開発の問題へのより標準化されたアプローチは、両当事者に利点を提供し得ると考えられる。具体的には、本明細書に提示される、組織化およびツールセット、ハードウエアおよびソフトウエアの両方が、臨床医により優れたアクセスを提供するが、同時に、日常的に製造者との徹底した相互作用に対する必要性を低減すると考えられる。さらに、セーフガードは、開発が既存の規制の枠組みを覆す可能性を低減するように包含され得る。

図１は、治療法管理開発プラットホームの一実施形態を概略的に例示する。特に、このプラットホームは、静脈（ＩＶ）内注入治療法において使用するための、特に、ＩＶ薬物制御等の閉ループＩＶ注入治療法のためのポンプと併せて使用されるようにセンサを設計することに有用である。しかしながら、本明細書において認識され、説明されるように、治療法管理開発プラットホームはまた、他の医療デバイスによって提供される他の治療法と併せて使用され得る。

図１および２に見られるような、本開示に従う治療法管理開発プラットホーム、またはシステム１００を例示する。システム１００は、ポンプコントローラ１０２と、インターフェースモジュール１０４と、センサ１０６とを含み得る。ポンプコントローラ１０２とインターフェースモジュール１０４とは、インターフェースモジュール１０４とセンサ１０６とが実行するように、相互に通信する。システム１００の各要素を下記により詳細に説明する。

図１および２に例示するように、ポンプコントローラ１０２は、筐体１１０内に配置または載置され得る。筐体１１０は、治療法要素などを支持するために使用され得るものなどのスタンドに取り付けられるように構成され得る。代替的には、筐体１１０は、デスクトップなどの表面に置くように構成され得る。

ポンプコントローラ１０２は、プロセッサおよびメモリを含み得る。メモリは、読取り専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）の形態であり得る。ＲＯＭは、消去プログラム可能ＲＯＭ（ＥＰＲＯＭ）、および電気的消去プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）を含む、多くの異なる形態を成し得る。

ポンプコントローラ１０２は、ポンプ入力／出力（Ｉ／Ｏ）インターフェース１１２に連結され得る。ポンプＩ／Ｏインターフェース１１２は、ポンプコントローラ１１０が、ポンプコントローラ１０２と関連した１つ以上のポンプ１１４と通信することを可能にするように構成される。ポンプまたはポンプ（複数）１１４と、コントローラ１０２との間の通信は、例えば、無線周波（ＲＦ）または赤外線（ＩＲ）の伝送器の使用を介して、配線接続で、または無線で実施され得る。有線イーサーネット、無線イーサーネット（Ｗｉ−Ｆｉ）、ジグビー、およびブルートゥース等の多種多様な通信プロトコルを使用し得る。

ポンプコントローラ１００はまた、ユーザＩ／Ｏインターフェース１１６に連結され得る。ユーザＩ／Ｏインターフェース１１６は、視覚ディスプレイ（液晶ディスプレイ（ＬＣＤ）または発光ダイオード（ＬＥＤ）ディスプレイ等）、および／または可聴ディスプレイ（圧電ブザー等）等の１つ以上の出力デバイスを含み得る。かかる出力デバイスを、重要な相互作用事象を提供するために使用して、治療法制御が結果パラメータ、例えば、顕著な事象を有する多変数グラフにどのように影響を及ぼすかを記述し得る。ユーザＩ／Ｏインターフェース１１６はまた、プッシュボタン、タッチスクリーンパネル、キーボードなどの１つ以上の入力デバイスを含み得、入力デバイスはまた、バーコード、ＲＦＩＤ、磁気ストライプ、またはホログラフィー画像技術とともに使用するための読取り器を含み得る。ユーザＩ／Ｏインターフェース１１６を使用して、ポンプコントローラ１０２内に記憶された情報（流動履歴、送達された容量、送達割り込み、流速、および薬物感受性情報）にアクセスする、および／またはポンプコントローラ１０２をプログラムして、１つ以上のポンプ１１４の動作を制御し得る。

インターフェースモジュール１０４はまた、多くの異なるサブシステムを含み得、それらのすべては、筐体１２０内に配置または載置され得る。例示するように、インターフェースモジュール１０４は、モジュールコントローラ１２２と、電力供給１２４と、ポンプコントローラモジュールＩ／Ｏインターフェース１２６と、モジュールセンサＩ／Ｏインターフェース１２８と、ユーザＩ／Ｏインターフェース１３０とを含む。筐体１２０は、筐体１１０と同様に、スタンドに接続またはその上に載置されるように構成され得るか、または、筐体１１０に接続またはその上に載置されるようにも構成され得る。

ポンプコントローラ１０２のように、モジュールコントローラ１２２は、プロセッサおよびメモリを含み得る。メモリは、読取り専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）の形態であり得る。ＲＯＭは、消去プログラム可能ＲＯＭ（ＥＰＲＯＭ）および電気的消去プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）を含む、多くの異なる形態を成し得る。

ポンプコントローラモジュールＩ／Ｏインターフェース１２６は、モジュールコントローラ１２２に連結され、おそらく、医療連携のための情報統合化（ＩＨＥ）プロセスの取込みを介して国際標準化機構（ＩＳＯ）および（ＩＥＥＥ）によって定式化されるもの等の１つ以上の標準化通信プロトコルに従って、ポンプＩ／Ｏインターフェース１１２との通信を可能にする。ポンプ（複数）１１４の場合でもそうであったように、ポンプコントローラモジュールＩ／Ｏインターフェース１２６とポンプＩ／Ｏインターフェース１１２との間の通信は、配線または無線接続の形態を成し得る。ポンプコントローラモジュールＩ／Ｏインターフェース１２６は、ポンプコントローラ製造者の特定の専有ハードウエアおよびソフトウエアの仕様に対して構成され得る。

モジュールセンサＩ／Ｏインターフェース１２８は、少なくとも１つの標準化入力ポートと、少なくとも１つの標準化出力ポートと、少なくとも１つの電力接続とを有する。モジュールセンサＩ／Ｏインターフェース１２８はまた、コントローラ１２２がセンサ１０６と通信することを可能にするインターフェース１２８とコントローラ１２２との通信、およびセンサ１０６に電力を供給するためのインターフェース１２８と電力供給１２４との間の接続によって、モジュールコントローラ１２２および電力供給１２４に連結される。

ユーザＩ／Ｏインターフェース１３０は、モジュールコントローラ１２２に連結され、ユーザＩ／Ｏインターフェース１１６と同様である。ユーザＩ／Ｏインターフェース１３０は、視覚的ディスプレイ（液晶ディスプレイ（ＬＣＤ）または発光ダイオード（ＬＥＤ）ディスプレイ等）、および／または可聴ディスプレイ（圧電ブザー等）等の１つ以上の出力デバイスを含み得る。かかる出力デバイスを、重要な相互作用事象を提供するために使用して、治療法制御が結果パラメータ、例えば、顕著な事象を有する多変数グラフにどのように影響を及ぼすかを記述し得る。ユーザＩ／Ｏインターフェース１３０はまた、プッシュボタン、タッチスクリーンパネル、キーボードなどの１つ以上の入力デバイスを含み得る。しかしながら、ユーザＩ／Ｏインターフェース１１６とは異なり、ユーザＩ／Ｏインターフェース１３０は、出力デバイスと関連した専用のテキストベースのインターフェースまたはグラフィカルユーザインターフェース（ＧＵＩ）、または入力デバイスに割り当てられる専用のアイコンもしくはピクトグラムを有し得ない。かかる専用の割当ての欠如を、下記により詳細に説明する。

インターフェース１２６、１２８、１３０に連結される他に、モジュールコントローラ１２２はまた、演算デバイス１４０と通信し得る。演算デバイス１４０との通信は、配線または無線であり得る。通信はまた、連続的または離散的であり得る、つまり、コントローラ１２２は、ケーブルまたは伝送器／受信器接続の使用を介して、演算デバイス１４０に連結され得るか、または１つ以上のメモリデバイス（例えば、メモリスティック）を使用して、演算デバイス１４０を使用して生成されたプログラムを、コントローラ１２２に転送し得る。示されないが、さらなるインターフェースは、コントローラ１２２と演算デバイス１４０との間に配置され、デバイス間の通信を可能にし得る。

特に、演算デバイス１４０は、コントローラ１２２のプログラミングを促進する１つ以上のアプリケーション（開発ツールキットとして集合的に称され得る）を含み得る。これらのアプリケーションは、標準化入力コマンド、出力コマンド、およびプロシージャコマンドのライブラリと組み合わせるＧＵＩの操作を介して、ユーザによりプログラムが書き取られるのを可能にする。したがって、ユーザは、アプリケーションが、コントローラ１２２により理解される言語に自動的に変換されるプログラムを構成するために、入力コマンド、出力コマンド、およびプロシージャコマンドから選択することができる。これは、開発ツールキットを使用しない場合よりも、それを使用してより効率的に達成され得る。

例えば、ユーザは、入力および出力コマンドを選択して、センサ１０６からの信号、ポンプコントローラ１０２からの信号、およびユーザＩ／Ｏインターフェース１３０からの信号を受信するためのデータチャネルを確立し得る。ユーザはまた、標準化コマンドを使用して、センサ１０６およびポンプコントローラ１０２からの信号出力の範囲に従い、入力をスケールし得る。さらに、ユーザは、プロシージャコマンドからフィルタリングアルゴリズムを選択して、例えば、センサ１０６およびポンプコントローラ１０２から受信されたデータをフィルタ処理し得る。ユーザはまた、１つ以上の標準化制御モデルを実施する制御アルゴリズムを選択し得る。さらに、これらの制御アルゴリズムは、これらの複合アルゴリズムの複雑な表現ではなく、むしろ直観的な表示および象徴表現の使用を介して、ＧＵＩに表すことができる。単位補正は、選択された入力コマンド、出力コマンド、およびプロシージャコマンドに基づいて、自動的に処理することができる。

さらに特定の例として、ユーザは、閉ループ薬物送達制御システムに使用される新規グルコースセンサを有し得る。ユーザは、開発ツールキットを使用して、ポンプデータを検索するためのポンプコントローラＩ／Ｏインターフェース１２６のあるチャネルを指定し、センサデータを検索するためのセンサモジュールＩ／Ｏインターフェース１２８のあるチャネルを指定し、対象パラメータ（血糖、グリコシル化ヘモグロビン、インスリンＩＶ注射の流速、ならびに経口およびＩＶ栄養輸送）についての情報またはそのための制御を表示するように、ユーザＩ／Ｏインターフェース１３０を構成し得る。ユーザは、スケーリングツールを使用して、センサ１０６への最小および最大の電圧出力に従うグルコース読取り値、選択された栄養スケールに従うポンプ流速および入力をスケールし得る。ユーザはまた、フィルタリングアルゴリズムを選択して、センサデータからノイズを除去し（例えば、３極、ローパスフィルタ）、入力データからデータ入力エラーを除去し得る。ユーザはまた、モデルの各構成要素のためのループゲインおよびフィードバック源の選択である入力のみによって、ライブラリから使用可能な制御モデルを選択し得る。次いで、アプリケーションは、自動的に整合性チェック（数値単位の一貫性および変換等）を実行し、プログラムを生成し、コントローラ１２２にアップロードすることができる必要なシステム方程式によって完了するであろう。

勿論、演算デバイス１４０が、コントローラ１２２と同一の一般的領域に配置され、ローカル配線または無線接続を介するアップロード、または同一の部屋の中に空間を占めるデバイス間で移動する携帯型メモリデバイスからコントローラ１２２へのプログラムのアップロードを可能にし得るという上記の考察から示唆され得るが、これは、システム１００のすべての実施に従う場合である必要はない。例えば、演算デバイス１４０は、システム１００に対して遠隔の位置に配置され得、プログラムは（一度生成されると）、コンピュータネットワーク（広域ネットワーク、イントラネット、またはインターネット）にわたって電子的に伝送され得る。その結果、アップロードのアクションは、演算デバイス１４０とシステム１００との間の広い地理的距離にわたるプログラムの移動に関与し得る。

したがって、図３は、本開示に従う簡略化された方法２００を示し、そこで、ユーザは、開発ツールキットアプリケーションを作動する演算デバイス１４０を使用して、ブロック２０２においてモジュールコントローラ１２２をプログラムするために、コマンドの標準ライブラリからコマンドを選択する。次いで、演算デバイス１４０は、ブロック２０４において選択されたコマンドに対してあるチェックを実行し、コマンドを変換して、ブロック２０６においてモジュールコントローラ１２２により理解される言語のプログラムを生成する。次いで、プログラムは、ブロック２０８において、モジュールコントローラ１２２にアップロードされ得る。

図４は、演算デバイス１４０上で動作する開発ツールキットによりユーザに表示されたグラフィカルユーザインターフェース２２０の典型である。グラフィックユーザインターフェース２２０は、単に、例示的一実施形態であり、他のインターフェースも可能であることを認識するであろう。

例示された実施形態に従い、インターフェース２２０は、複数のユーザオプションを含む。実施の便宜上、および簡便性のために、ユーザオプションは、３つのグループまたはカテゴリー（治療法制御オプション２２２、センサ構造オプション２２４、およびフィルタ構造オプション２２６）に整理される。例示するように、各グループ２２２、２２４、２２６内に、複数のユーザオプションが存在し得る。しかしながら、単一のユーザオプションにより規定されるグループを有することも可能であり、単一グループに整理されたユーザオプションのうちのすべてを有することも可能である。

各グループ２２２、２２４、２２６内のユーザオプションのそれぞれは、１つ以上のオブジェクト、ルーティン、プログラム等と関連し得、これらのオブジェクト、ルーティン、プログラム等の構成は、１つ以上のグループ２２２、２２４、２２６内で選択または修正されたユーザオプションにより影響される。例えば、治療法制御オプショングループ２２２内に、線形ＰＩＤ制御２３０、非線形制御２３２、モデル予測制御２３４、適応制御２３６、およびファジー論理制御２３８のためのオプションが存在する。オプション２３０、２３２、２３４、２３６、２３８のうちの任意の１つを選択するステップは、他のオプションのためのオブジェクト、ルーティン、プログラム等を除去するために、特定のオブジェクト、ルーティン、プログラム等を使用し得る。そのため、ユーザが、オプション２３０、２３２、２３４、２３６、２３８のうちの１つのみを選択し得るように、ラジオボタンが使用され得る。

その上、ユーザオプションは、他のオプションが除去されている間に、第１のユーザオプションの選択が、ユーザに使用可能であるさらなるオプションにつながり得るように、ツリー構造を使用して整理され得る。例えば、線形ＰＩＤ制御オプション２３０が選択される場合、比例因子、積分因子、または導関数因子を設定するためのさらなるオプション２４０、２４２、２４４が存在する。さらなるオプション２４０、２４２、２４４は、オプション２３０、２３２、２３４、２３６、２３８と同時に表示されて例示されるが、オプション２４０、２４２、２４４は、線形ＰＩＤ制御オプション２３０が選択される場合のみに表示され得る。別のオプションとして、プルダウンリストまたは他のＧＵＩ制御を使用して、線形ＰＩＤ制御オプション２３０（または、その方法のための他のオプションのうちのいずれか）内で使用可能なオプションを表示し得る。

ユーザオプション２３０、２３２、２３４、２３６、および２３８は、ポンプ１１４を含む、治療法管理システムの閉ループ制御のためのすべてのオプションであることも認識されるであろう。また、制御グループ２２０内に、臨床医制御も存在する。また、これは、各グループ２２０内で、ユーザオプションがサブグループにさらに整理され得ることを示す。臨床医制御では、ユーザオプションは、臨床医によるユーザのための情報の表示、ならびに不用意なユーザエラーを防止するための境界条件の設定に集中し得る。

例えば、臨床医制御の下でのユーザオプションは、ディスプレイオプション２５０およびアラームオプション２５２を含む。ディスプレイオプション２５０は、流速および容量、ならびにポンプ動作に関する履歴情報の表示を含み得る。アラームオプション２５２は、センサ出力、または薬物感受性等の他の条件の変更に関して、可聴および／または視覚アラームを鳴らすタイミングのためのオプションを含み得る。オプション２５０、２５２はまた、ユーザオプションが、数値形態の入力またはプルダウンリストを必ずしも必要としないが、単に、チェックボックスの形態であり得るという事実に焦点を合わせる。

センサグループ２２２に関しては、センサ入力２６０、ディスプレイ２６２、およびゲイン２６４のためのユーザオプションは、選択され得る。制御グループ２２０内のユーザオプションの場合でもそうであったように、入力２６０、ディスプレイ２６２、およびゲイン２６４のためのユーザオプションは、行われた選択モードにより影響される、オブジェクト、ルーティン、プログラム等に関連した。さらに、オプションのうちのいくつかは、相互排他的な増幅／非増幅オプションであり、ディスプレイサブグループ２６２下のフィルタ／非フィルタオプションが例である。他のオプションは、ユーザがゲインサブグループ２６４等の数値を提供することを必要とする。

最後に、フィルタグループ２２４に関しては、ユーザオプションは、それが制御アルゴリズム内で使用される前に、センサ１０６からのデータのフィルタリングを実行する、オブジェクト、ルーティン、プログラム等を選択するために使用可能である。考えられるオプションは、ローパスサブグループ２７０、ハイパスサブグループ２７２、およびバンドパスサブグループ２７４に整理され得る。高速フーリエ変換（ＦＦＴ）の使用に関するユーザオプションのためのサブグループ２７６もまた、提供され得る。例示するように、サブグループのうちそれぞれは、それと関連した複数のオプションを有し得る。

したがって、考察したシステム１００、開発ツールキットの使用方法２００、および開発ツールキットに関連したＧＵＩ２５０の例示的一実施形態を考慮して、システム１００が、１つ以上の付加的な側面を含み得、その側面は、システム１００に付加的な利点を提供し得ることを認識されるであろう。

例えば、システム１００は、センサ１０６がセンサモジュールＩ／Ｏインターフェース１３０に接続されることを可能にする、センサ１０６のための標準センサプラットホームとともに使用され得る。カテーテルの形態であり得る、プラットホームは、データ収集および電力分配のための標準リードを含み得る。その結果、ユーザは、位置、電力、および／または患者に対してセンサとの通信のための機構ではなく、むしろ、センサまたはトランスデューサの開発に集中し得る。

加えて、システム１００は、インターフェースモジュールの使用なく、センサまたはプログラムが、ポンプコントローラ１０２とともに使用されることを防止する、ロックアウトプロセスを特徴とし得る。ロックアウトプロセスは、ハードウエア構成要素および／またはソフトウエア構成要素を含み得る。より一般的には、ロックアウトプロセスは、パスワードまたは暗号化等のソフトウエア構成要素の形態である。ロックアウトは、下記により詳細に説明するように、規制承認前の特定の位置におけるシステムの使用を不可能または防止し得る。

この方法で、ロックアッププロセスは、異なるアクセスレベルを可能にするように構成され得る。例えば、第１のレベルにおいて、システム１００は、システム１００への任意の動作的権限を拒否し得る。第２のレベルにおいて、システム１００は、調査使用のみのためにシステム１００が使用されることを可能にし得る。最終的に、第３のレベルにおいて、システム１００は、規制承認が得られると、システム１００の使用を可能にし得る。

図１〜４は、本開示に従う治療法管理開発プラットホームの一実施形態を表すが、他の代替的実施形態も可能であることも認識されるであろう。例示的な付加的な実施形態を図５〜７に例示する。

図５および６は、モジュールがポンプコントローラの筐体の外側に存在しない、例示的な代替的実施形態を例示する。そのため、依存としてそれ自体の処理およびメモリを保持し得るモジュールは、装置要件および費用を低減するために、ポンプコントローラの積算電力供給等のポンプコントローラの他の側面を用い得る。モジュールの処理とメモリとの分離は、システムのサブシステム間に境界を確立することによって、図５および６の実施形態が、システムの論理分解、ならびに安全性および有効性を促進することを可能にする。

次いで、図５および６を参照すると、治療法管理開発システム３００は、ポンプコントローラ３０２と、インターフェースモジュール３０４と、センサ３０６とを含むことを認識されるであろう。ポンプコントローラ３０２とインターフェースモジュール３０４とは、インターフェースモジュール３０４とセンサ３０６とが実行するように、互いに通信する。

上述のように、ポンプコントローラ３０２およびインターフェースモジュール３０４は、単一の筐体３１０内に定置または載置され得る。筐体３１０は、治療法要素などを支持するために使用され得るもの等のスタンドに取り付けられるように構成され得る。代替的には、筐体３１０は、デスクトップなどの表面上に置かれるように構成され得る。

ポンプコントローラ３０２およびモジュール３０４の両方は、プロセッサおよびメモリを含み得る。ポンプコントローラ３０２の例では、プロセッサ３１２およびメモリ３１４は、別個に表されるが、モジュール３０４の処理およびメモの能力は、モジュールコントローラ３１６の形態で表される。メモリは、読取り専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）の形態であり得る。ＲＯＭは、消去プログラム可能ＲＯＭ（ＥＰＲＯＭ）、および電気的消去プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）を含む、多くの異なる形態を成し得る。

ポンプコントローラ３０２は、ポンプ入力／出力（Ｉ／Ｏ）インターフェース３１８に連結され得る。ポンプＩ／Ｏインターフェース３１８は、ポンプコントローラ３０２が、ポンプコントローラ３０２に関連した１つ以上のポンプ３２０と通信することを可能にするように構成される。ポンプまたはポンプ（複数）３２０と、コントローラ３０２との間の通信は、配線接続を介して、または無線（例えば、無線周波（ＲＦ）または赤外線（ＩＲ）の伝送器および受信機の使用を介する）で実施され得る。

ポンプコントローラ３０２はまた、ユーザＩ／Ｏインターフェース３２２に連結され得る。ユーザＩ／Ｏインターフェース３２２は、視覚ディスプレイ（液晶ディスプレイ（ＬＣＤ）または発光ダイオード（ＬＥＤ）ディスプレイ）、および／または可聴ディスプレイ（圧電ブザー等）等の１つ以上の出力デバイスを含み得る。かかる出力デバイスを重要な相互作用事象を提供するために使用して、治療法制御が結果パラメータ、例えば、顕著な事象を有する多変数グラフにどのように影響を及ぼすかを記述し得る。ユーザＩ／Ｏインターフェース３２２はまた、ボタン、タッチスクリーンパネル、キーボードなどの１つ以上の出力デバイスを含み得る。ユーザＩ／Ｏインターフェース３２２を使用して、ポンプコントローラ３０２内に記憶された情報（流動履歴、送達された容量、送達割り込み、流速、および薬物感受性情報等）にアクセスする、および／またはポンプコントローラ３０２をプログラムして、１つ以上のポンプ３２０の動作を制御し得る。

インターフェースモジュール３０４はまた、ポンプコントローラ３０２上のカードスロット内に受容されるカード上のモジュールコントローラ３１６を用いて配置または載置され得る多くの異なるサブシステムを含み得る。例示するように、インターフェースモジュール３０４は、モジュールセンサＩ／Ｏインターフェース３２４を含む。また、例示するように、インターフェースモジュール３０４は、ポンプコントローラ３０２と同一の筐体３１０内に実質的に定置され得る。

モジュールセンサＩ／Ｏインターフェース３２４は、少なくとも１つの標準化入力ポートと、少なくとも１つの標準化出力ポートと、少なくとも１つの標準化電力接続とを有し得る。モジュールセンサＩ／Ｏインターフェース３２４はまた、モジュールコントローラ３１６および電力供給３２６に連結され、その電力供給３２６はまた、ポンプコントローラ３０２によって使用される。この方法で、インターフェースモジュール３０４は、モジュール３０４の全体の装置要件および費用を低減するために、ポンプコントローラ３０２に一般的に関連した要素を使用することが可能になる。

加えて、モジュールコントローラ３１６は、ポンプコントローラ３０２に関連したユーザＩ／Ｏインターフェース３２２と通信するように、ポンプコントローラ３０２とインターフェースし得る。そのため、図５および６の実施形態は、ポンプコントローラ３０２の既存の装置を利用し、モジュール３０４の費用を低減することができる。勿論、ポンプコントローラ３０２の最小の要件は、コントローラ１０２の要件と異なり、モジュール３０４は、例示するように、コントローラ３０２を介してユーザインターフェース３２２にアクセスする必要がある。さらなる代替的実施形態に従い、ユーザＩ／Ｏインターフェース３２２は、モジュールコントローラ３１６が、ポンプコントローラ３０２を介して直列的ではなくむしろ、ポンプコントローラ３０２と並列的にインターフェース３２２と通信し得るように構成され得ることを認識されるであろう。

モジュールコントローラ３１６のプログラミングについては、モジュールコントローラ３１６はまた、演算デバイス３４０と通信し得る。演算デバイス３４０との通信は、配線または無線であり得る。通信はまた、連続的または離散的であり得、すなわち、コントローラ３１６は、ケーブルまたは伝送器／受信器接続の使用を介して演算デバイス３４０に連結され得るか、または１つ以上のメモリデバイス（例えば、メモリスティック）が、演算デバイス３４０を使用して作成されたプログラムをコントローラ３１６に転送するために使用され得る。この方法で、モジュールコントローラ３１６は、演算デバイス３４０上で動作する開発ツールキットを操作する能力を有するユーザＩ／Ｏインターフェース３２２に頼る必要なく、プログラムされ得る。

治療法管理開発システム４００のよりさらなる実施形態を、図７に例示する。本実施形態に従い、ポンプコントローラ４０２は、ポンプコントローラ１０２、３０２と同様に動作するように構成されるが、モジュール４０４をポンプコントローラ４０２内のソフトウエア動作に変えて、モジュール４０４が、別個の演算デバイスを用いることなく、プログラムされることを可能にするよう、十分なＩ／Ｏインターフェース、処理能力、およびメモリ能力を用いて構成される。そのため、ポンプコントローラ４０２は、有意に、ポンプコントローラ１０２、３０２よりも、モジュール４０４との使用に専念させられ、それは、モジュール１０４、３０４から分離され、それらのより従来的な役割で使用され得る。

例示するように、システム４００は、ポンプコントローラ４０２と、モジュール４０４と、センサ４０６とを含む。上記に留意するように、モジュール４０４は、ポンプコントローラ４０２と関連したメモリ４０８内に存在し、メモリ４０８に関連したプロセッサ４１０上で動作可能である。メモリ４０８はまた、センサ４０６を用いるデータ取得、およびポンプ４１４を有する潜在的に修正された治療法管理ルーティンを実施するようにモジュールをプログラムするために、モジュール４０４とともに使用するための開発ツールキット４１２を含み得る。

ポンプコントローラ４０２が、ツールキット４１２の使用を介してモジュール４０４をプログラムすることに使用されることを可能にするために、ユーザＩ／Ｏインターフェース４１６が、図１および５の実施形態のユーザＩ／Ｏインターフェースと異なって構成されることが必要であり得る。同様に、Ｉ／Ｏインターフェース４１８が、関連した電力供給４２０からセンサ４０６に電力を供給するために使用される場合、次いで、インターフェース４１８は、図１および５の実施形態のインターフェースの能力と異なる能力、およびそれに加えた能力を有し得る。

したがって、考察した、治療法管理開発プラットホーム、および開発者／臨床医によるそれらの使用の種々の異なる実施形態を考慮して、図８は、プラットホームを使用して開発された医療デバイスまたは方法に対する承認を得るための制御された標準化検査方法５００の一部として、これらのプラットホームの使用を例示する。認識されるように、多くの医療デバイスまたはシステムは、販売前に承認を必要とする。ある管轄では、この承認は行政体によって提供されるが、他所では、行政体に対して責任がある独立した商業組織によって提供され得る。この承認プロセスは、一連の検査段階（ベンチ、動物、ヒト臨床試験、およびヒトへの完全に可能にされた使用（「ヒトでの使用」））を必要とし得、ステップは、明確に規定されたフェーズ（パイロット、ピボット）さえも有し得る。方法５００は、上述のプラットホームを使用して、治療法管理開発の制御を補助し、適切な試験が実行されていることを確実にする。

ブロック５０２において、プラットホームは、プラットホーム製造者または製造者に関連した関係者によって、治療法管理開発者に提供される。プラットホームは、例えば、図１〜７において、上記に例示する実施形態のうちの１つに従って設計され得る。認識されるように、これらのプラットホームは、注入治療法において、関連したポンプの動作を変化させるように、ポンプコントローラと併せて、またはポンプコントローラとして使用される能力を有する。下記に詳細に説明されるように、例えば、腎臓治療法または吸入治療法を用いて有用である、他のプラットホームもまた、提供され得る。

認識されるように、これらのプラットホームは、プラットホームがベンチ検査、動物検査または試験、および臨床（またはヒト）検査または試験に使用されることを可能にする、医療デバイス（例えば、ポンプコントローラおよびポンプ）に対して複数の機能性レベルを有し得る。しかしながら、一般的には、ベンチ検査および動物試験が臨床試験に先行し、臨床試験の範囲内でさえ、デバイスまたはシステムのための承認を得るプロセスにおいて、異なるフェーズが、連続して通過され得る。その上、承認を得るために、必要な方法で、検査または試験が進行されていることを確実にするために、プラットホームの使用の制御が重要であると考えられている。

したがって、ブロック５０４において、プラットホームは、医療デバイスに対する機能性への初期のアクセスレベルに設定されたプラットホームを用いて、ユーザに提供される。初期のアクセスレベルは、多くの場合において、ユーザ規定のセンサまたは制御アルゴリズムを使用して、ベンチ試験を実施するために好適であり得る。しかしながら、ある利点が、必要な検査（ベンチ、動物、臨床）のうちのすべてのためのプラットホームを使用することによって得られ得るが、他の利点もまた、例えば、初期のベンチ検査が完了すると、プラットホームを用いることによって得られ得ることを理解されたい。したがって、初期のアクセスレベルは、すべての場合において、プラットホームを用いるベンチ検査のためのプラットホームの使用と一致し得ない。

デバイスのある機能性レベルへのアクセスは、上述のロックアウトを介して達成され得る。つまり、特定のパスワードまたは暗号化キーは、動物試験または臨床試験ではなく、ベンチ試験に有用なデバイスの機能性へのアクセスを開発者に提供し得る。異なるパスワードまたは暗号化キーは、ベンチ試験、動物試験、臨床試験等のために機能性へのアクセスを提供し得る。

次いで、開発者は、上述のように、プラットホームを使用して、医療デバイスの動作を修正することが可能である。例えば、開発者は、プラットホームの使用を介して、医療デバイスとともに、プロトタイプセンサを使用し得る。代替的には、開発者は、医療デバイスによって使用される制御アルゴリズムの動作に変更を行い得、具体的には、開発者ツールキットを使用して治療法管理を制御し得る。さらなる代替として、開発者は、プロトタイプセンサを使用し、制御アルゴリズムの動作を変更し得る。任意の事象において、本開示に従い、プラットホームを使用する医療デバイスの動作の修正は、患者に提供される治療法の量または速度を単に変化させる（すなわち、修正は、それらにおいて、かつそれらの非外科的および非治療的である）ように、医療デバイスの動作を変更することを意味しない。本開示に従い、医療デバイスは、プラットホームを使用する修正前の第１の機能性（あるセンサまたは制御アルゴリズムを使用する能力）、およびプラットホームを使用する修正後の第２の機能性（付加的または異なるセンサおよび／または制御アルゴリズムを使用する能力）を提供することが可能である。勿論、医療デバイス自体を使用して、患者に有益な治療法を提供し得るが、請求する方法は、ヒトまたは動物に任意の治療的利点を提供することなく実行される、すなわち、請求する方法は、非治療的である。また、請求する方法は、ヒトまたは動物の身体に実行される任意の外科的工程を含まない、すなわち、請求する方法は、非外科的である。

次いで、方法５００は、ブロック５０６に続き、そこでは、プラットホームの機能性へのアクセスを制御する関係者は、さらなる試験を行うことを可能にする、開発者がプラットホームの機能性への新規のアクセスレベルに進行する承認を受信したという指示を受信したか否かの決定を行う。この指示は、開発者によって、または開発者と協力して作業する関係者（例えば、施設内論理委員会）によって、または上述の政府機関／独立組織によって提供され得る。その点において、承認は、プラットホームへのアクセスを制御する関係者によって決定され得、したがって、プラットホームへのアクセスを制御する関係者と別個であるか、またはそれと無関係の関係者である必要はない。

次のアクセスレベルに進む承認が受信されていない場合、方法５００は、ブロック５０６に留まる。承認が受信された場合、次いで、方法５００は、ブロック５０８に進み、そこでは、プラットホームへのアクセスを制御する関係者は、承認の指示の受信に応じて、プラットホームの機能性への増加したアクセスレベルにプラットホームを設定する。例えば、以前、ベンチ検査のみに有用であったプラットホームは、動物研究に有用であるように修正されたアクセスレベルを有し得る。加えて、プラットホームへのアクセスを制御する関係者は、プラットホームのアクセスレベルに従い、顧客料金（例えば、アクセスレベル当たりのある量の通貨または価値の）を設定し得、その料金は、増加したアクセスレベルが設定される前か、それと同時か、またはその後に評価され得る。顧客料金は、許可されたアクセスレベルに従って異なり得るか、またはアクセスレベルの各増加に対する設定量であり得る。

ブロック５０６に戻る前に、承認プロセスが完了したか否かの決定が行われ得る。例えば、ブロック５１０において、受信された承認レベルが医療デバイスを販売するために承認されたことが決定され得る。かかる承認は、アクセスを制御する関係者によって制御されるように、プラットホームの制限された使用が完了したことを示す。かかる状況では、方法５００は、ブロック５１２に続き、そこでは、新規センサおよび／または制御アルゴリズムが販売される。代替的には、方法は、ブロック５０６に戻る。

上記に注記するように、方法５００は、センサおよび／または治療法管理アルゴリズムの最終的な承認に必要とされる検査の標準化を促進し得る。方法５００はまた、均一な品質を有するシステムを用いて、より一貫した開発プロセスを提供し得る。さらに、方法５００は、製造者が、製造者の商業用装置とともに使用される、新規センサおよび／または治療法管理アルゴリズムのために、上述のシステムの大多数のユーザのイノベーションを利用することを可能にし得る。引き換えに、方法５００は、革新者が、上述の実施形態におけるポンプおよびポンプコントローラ等の製造者の装置の構造および動作の革新者に必要とされる知識レベルを低下させて、センサおよび／またはアルゴリズム開発のために安定した標準化システムの形態の製造者の専門知識を利用することを可能にし得る。さらに、上述のシステムおよび方法５００は、革新者がより容易にそれらのイノベーションを市場に移行することを可能にし得、製造者により提供されるそのシステムの使用は、製造者が、彼らの既存の製品ラインおよび製造工程にイノベーションをより容易に統合することを可能にしなければならない。

治療法管理開発プラットホームの動作（および、したがって、プログラミング）のさらなる例示は、図９〜１１で確認し得る。先述の考察ならびに図９〜１１に関する開示から、プラットホームのプログラミングが多くの別個のデバイスまたはプロセッサのプログラミングに関与し得ることを理解されるであろう（図１〜６の実施例を参照）。その上、プログラミングは、ソフトウエアを含み得、ファームウエアもまた含み得る。さらに、プログラミングは、異なるプログラミング言語であり得、それぞれは、プログラミングを実行するか、またはプログラミングに従い動作するデバイスに従う。高水準において、プログラミングは、手続き型、オブジェクト指向、イベントドリブン等であり得る。しかしながら、プラットホームのプログラミングが、単一のプログラミング言語を使用して単一のデバイスまたはプロセッサのプログラミングに関与することも可能である（例えば、図７の実施形態に関する）。

ここで、図９〜１１を詳細に参照すると、図９は、例えば、患者のいる医療の場において、システム１００の使用への開発の開始からの、例えば、システム１００の動作の概要を提供する。図１０は、検査および開発フェーズ中のシステム１００の動作を例示し、検査および開発の反復が、システム１００を使用して実行され得る。図１１は、検査および開発フェーズのいずれかの最中に実行される制御プログラミング、または通常の商業用の使用中のシステム１００を構築するための、システム１００、および特にツールキットの動作を例示する。

次いで、図９から開始すると、動作６００のプロセス（上述のように、システム１００のプログラミングに反映し得る）は、ブロック６０２において開始する。ブロック６０２において、システム１００は、システムが、ベンチ試験が行われることを可能にするためのアクセスレベルを提供することを可能にする、パスワード、暗号化キーなどを受信する。ある例では、システム１００は、システム１００の製造時点において、パスワード、暗号化キーなどを受信し得る。他の例では、システム１００は、以前に使用されたシステム１００の検査および開発の側面を伴わずに、通常の商業用の使用に使用された後に、パスワード、暗号化キーなどを受信し得る。さらに他の例では、パスワード、暗号化キーなどを使用して、異なるアクセスレベル（例えば、動物試験）において以前使用されていたシステム１００のアクセスレベルを変更し得る。

実際、上述の考察に反映されるように、例えば、動物試験におけるパスワードまたは暗号化キーの特定のシステム１００（すなわち、システム１００の例）による受信が、ベンチ試験のアクセスレベルに応じて第１の受信されたパスワードまたはキーを有するために特定のシステムを必要としないことに留意することが重要である。同様に、システム１００の特定の例は、ベンチ試験または動物試験のパスワードを受信せずに、ヒトの臨床試験またはさらにはヒトへの使用（特定の地理的位置内）に対する機能性へのアクセスを可能にするパスワードを受信し得る。したがって、システム１００のそれぞれの例が、それぞれのアクセスレベルにおいて、必ずしも、検査および開発のために使用されるか、またはそれぞれの例がヒトへの使用前の検査および開発に使用される必要はない。

さらに、図９に例示するプロセス６００は、それがすべての試験方法において、かつ通常の商業的なヒトへの使用において使用されることを可能にする、より高い程度の可撓性を有するシステム１００の例のプログラミングの代表である。しかしながら、プロセス６００の１つ以上のブロックが、システム１００のある例において省略され得るが、システム１００のその例が、本開示の範囲内のままであることを認識されるであろう。例えば、システム１００のある例は、（ヒト臨床試験またはヒトへの使用ではなく）ベンチ試験および動物試験のための機能性を含み得るが、システム１００の他の例は、（ベンチ試験および動物試験ではなく）ヒト臨床試験に使用され得る。しかしながら、これらの例のそれぞれでは、システム１００は、依然として、システム１００によって受信されたパスワード、キー等に基づき、機能性への異なるアクセスレベル間を変更するためにプログラミングされる。

ブロック６０４に続き、システム１００は、ここでベンチ検査に使用され得る。プロセス６００においてブロック６０４によって表される検査および開発の側面に関して、図１０のプロセス７００への参照を行う。その上、プロセス７００の初期ブロック７０２（プログラミング構造）を、ブロック８０２においてアクセスレベルの決定から開始する、図１１のプロセス８００により詳細に例示する。したがって、考察は、プロセス８００のブロック８０２において継続する。

先に注記したように、アクセスレベルは、あるロックアウトに関連し得る。つまり、システム１００は、開発プロセスのすべてのフェーズ中に使用不可能であり得る、ある機能性レベルを含み得る。アクセスレベル（キーまたはパスワードに関連した）を適用することにより、製造者（または、キーまたはパスワードの適用に責任のあるその開発パートナー）は、規制承認がまだ得られていないときに機能性が使用されることを防止しながら、（プログラミングおよび／またはハードウエアに関して）かなりの機能性を有するシステム１００を提供することができる。

アクセスレベルを決定する際に、ブロック８０２におけるシステム１００の正確な動作は、キー、パスワード等の特性によって異なる。例えば、システム１００は、内部メモリ内に記憶された一連のパスワードを有し得、パスワードのうちの１つ以上は、特定のアクセスレベルに関連した。次いで、システム１００により受信されたパスワードは、内部的に記憶されたパスワードのうちの１つと比較され、アクセスが可能にされるべきか否か、および可能にされる場合、どのレベルかを決定し得える。代替的には、公開・秘密暗号化キーを使用して、アクセスが可能にされるべきか否か、および可能にされる場合、どのレベルかを決定し得る。

これが決定されると、プロセス８００は、ブロック８０４に続き、そこで、システム１００は、可能にされたアクセスレベルに従い、あるセーフガードが実施される必要があるか否かを決定する。特定のアクセスレベルにおいてセーフガードが実施される必要がある場合、次いで、プロセス８００は、ブロック８０６に続く。必要でない場合、次いで、プロセス８００は、ブロック８０８に続く。

上記に注記するように、これらのセーフガードは、低いアクセスレベルにおけるシステム１００の機能性に対してロックアウトの形態であり得る。この種のセーフガードの一例として、システム１００は、ベンチ試験中に、視覚的（生理学的およびセンサ）データのみが、制御プログラミングとともに使用されることを可能にし得る。別の制限として、システム１００は、可能にされたアクセスレベルに従い、ツールキットのある部分（例えば、機能性のあるライブラリ、フィルタ等）へのアクセスのみを提供し得る。

しかしながら、セーフガードはまた、ヒト臨床試験またはヒトへの使用が関与されるため、高いアクセスレベルで実施される警告または機能的制限の形態を成し得る。この種のセーフガードの一例として、警告メッセージは、ポンプの開始前に表示され得るか、またはベンチ試験または動物試験中に可能にされたポンプ動作のある範囲は、そのアクセスレベルにおけるポンプの規定の動作範囲を超過する制御信号を阻止することにより禁止される。

したがって、セーフガードは、ある実行の防止またはある機能性の制限だけでなく、ある実行が取られる要求も表し得る。さらに、セーフガードは、より低いアクセスレベルにおける機能性（より高いアクセスレベルでは、より大きなフリーダム）を制限するだけでなく、システム１００は、代わりに、より高いアクセスレベル上の機能性により大きな制限を課し得る。

セーフガードが必要であり、ブロック８０４、８０６におけるセーフガードの組み込みが、図１１に例示するプロセス８００内の特定の位置に限定されないか否かの決定が認識されるであろう。例えば、セーフガードは、ユーザセレクションに応じて生成されたプログラミングに対するチェックとして、プロセス８００の後期の段階に組み込まれ得る（ブロック８０８〜８１４を参照）。代替的には、セーフガードが組み込まれるか否かの決定、および／またはプログラミングへのそれらの組み込みは、ブロック８０８〜８１４の実行が、ブロック８０８−８１４の実行と直列的ではなく、フォアグラウンドで動作する間に、バックグラウンドのプロセスと並列的に動作し得る。さらなる代替として、ブロック８０４、８０６の実行は、各ユーザセレクションがブロック８１０、８１４におけるシステム１００により受信されると、行われ得る。

セーフガードが、（該当する場合）、ブロック８０６において組み込まれると、プロセス８００は、ブロック８０８〜８１４に続く。ブロック８０８〜８１４の特定の配列が、例示および考察のために選択されているが、ブロック８０８〜８１４により表されるアクションのシーケンシャル順序は、ブロック８０４、８０６としてのセーフガードの決定および組込みの場合でもそうであったように、単に、説明の簡易目的であり、本明細書の開示に限定する目的ではないことを認識するであろう。ブロック８１２、８１４は、すべての例において、ブロック８０８、８１０に先行し得るか、またはブロック８０８、８１２は、ユーザからの入力のシステム１００による受信に従って生じるブロック８１０、８１４の順序と並列に生じ得る（例えば、図４を参照）。

ブロック８０８において、システム１００は、１つ以上（一般的には、複数）の治療法オプションをユーザに提供する。上述のように、図４を参照して、オプションは、複数の潜在的な治療法制御アルゴリズムを含み得、ユーザに対して出力デバイス上でグラフィックで表示され得る。ユーザは、チェックボックス、または入力デバイス（例えば、マウス、スタイラス、パッド等）を使用する他の入力表示をトグリングすることにより、治療法オプションから特性のアイテムの選択を表し得る。システム１００は、ブロック８１０においてユーザ入力を受信し、プロセス８００は、ブロック８１２に進む。

ブロック８０８、８１０と同様に、ブロック８１２、８１４のアクションは、１つ以上（再度、一般的には、複数）のセンサオプションを提供し、システム１００のプログラミングに組み込まれる望ましいオプションに対するユーザ入力を受信するステップに関与する。図４を参照すると、オプションは、複数のセンサパラメータオプション、および複数のセンサデータフィルタリングオプションを含み得る。ユーザは、再度、チェックボックス、または入力デバイス（例えば、マウス、スタイラス、パッド等）を使用する他の入力表示を切り換えることによって、治療法オプションから特定のアイテムの彼らの選択を表し得る。システム１００は、ブロック８１４においてユーザ入力を受信し、プロセス８００は、ブロック８１６に進む。

ブロック８１６において、システム１００は、ユーザが、制御およびセンサオプションの選択（または、提供される場合、ディスプレイオプション等の付加的なオプション）を完了したか否かを決定する。システム１００は、入力デバイスを介して特定の入力がユーザから受信されたか否かを決定することにより、選択プロセスが完了したか否かを決定し得る。例えば、システム１００は、ユーザが選択を完了したシステム１００に入力を送信するように出力デバイス（例えば、マウス）を介してユーザが操作し得る、関連する出力デバイス（例えば、モニタ）上のグラフィカルユーザインターフェース内のボタンを表示し得る。代替的には、ボタンは、システム１００に接続される物理的入力（例えば、プッシュボタン）の形態であり得、それを使用して、ユーザがプロセスを完了したシステム１００に入力を提供する。よりさらなる代替として、システム１００は、システムが、治療法および／またはセンサオプションの選択のユーザ入力表示が受信されたときに、ユーザがプロセスを完了したことを決定し得る。

ユーザがブロック８１６において選択プロセスを完了していないとシステム１００が決定する場合、プロセス８００は、ブロック８０８に戻る。代替的には、ユーザが選択を完了したと、システム１００が決定する場合、プロセス８００は、ブロック８１８に進む。

ブロック８１８において、システム１００は、ブロック８１２、８１４において受信されたユーザ入力に従って組み立てられたプログラミングを再検討し、プログラミングが、プロセス７００に戻る前にチェックされるものであるか否かを決定する。プログラムがチェックされるものである場合、次いで、プロセスは、ブロック８２０に進む。一方、プログラムがチェックされる必要がない場合、プロセスは、プロセス７００に戻る。例えば、変更が特定の出力でディスプレイのスケーリングを表すとき、プログラムは、プロセス７００に戻る前にチェックされることが不必要であり得、代替的には、完全に異なる制御アルゴリズムが選択されている場合、チェックが必要であり得る。

ブロック８２０において、システム１００は、例えば、プロセッサが検査中にプログラミングに従って動作するか、またはプログラミングを実行することを防止する、任意のエラーに対して組み立てられたプログラミングをチェックし得る。上述のセーフガードでは、プログラムが比較的エラーフリー（または、エラーを起こしやすい）であるか否かの決定の位置は、必ずしも、図１１のフローチャートに配置されるまさにその場所において生じる必要はない。認識されるように、例えば、エラーに対してプログラムをチェックするアクションは、ブロック８０８〜８１４のアクションと並列的に生じ得る。しかしながら、容易な説明のために、ブロック８１８、８２０は、図１１のフローチャートの最後に定置されている。

これから、図１０に戻ると、プロセス７００は、システム１００が、ブロック７０２で生じたプログラミング構成の完了後に、残りのシステム１００を構成し得る、ブロック７０４に進み得る。例えば、システム１００は、ブロック７０２において調製されたプログラミングをシステム１００の構造の一部として、プロセッサのメモリにアップロードし得る。加えて、システム１００は、コントローラにアップロードされたプログラミングに従い、センサ入力を起動し得るか、またはセンサ入力を検索して、センサ等が存在するか否かを決定し得る。システム１００はまた、システム１００と関連した電力供給からセンサに電力を供給することが必要であるか否かも決定し得る。他のアクションは、この時点において、ある専有または標準化プロトコルに従ってシステム１００の要素間の通信を作成するために、システム１００によって行われ得る。

システム１００が、ブロック７０４において構成されると、検査は、ブロック７０６において開始し得る。検査が継続中であると、ブロック７０６において、システム１００が決定する場合、次いで、プロセス７００は、ブロック７０８、７１０に続き、そこで、システムは、選択された制御オプションに従い、それに関連したポンプを制御し、選択されたセンサオプションに従い、センサからのデータを収集する。検査が完了したとシステム１００が決定する場合、次いで、システム１００は、ブロック７１２に進む。

ブロック７１２において、システム１００は、ユーザがセンサに変更のみを行うことを望むか、またはそれに変更のみを行ったか否かを決定する。例えば、システム１００は、センサが分離され、システム１００に再連結されていることを検出することにより、センサ変更のみが行われたか否か、新規プログラムがコントローラにアップデートされていないか否かを決定し得る。代替的には、ユーザは、センサのみを変化させるユーザの決定の入力指示を提供する入力デバイスを操作し得、システム１００は、その入力の受信時にセンサのみが変更されるものであることを決定し得る。センサ変更のみが行われた場合、次いで、プロセス７００は、構成ブロック７０４に戻り、検査の新規サイクルは、ブロック７０６、７０８、７１０において生じ得る。

同様に、ブロック７１４において、システム１００は、ユーザが、システム１００のセンサおよびプログラミングに、またはプログラミングのみに変更を行うことを望むか、変更を行ったか否かを決定し得る。ブロック７１２の場合でもそうであったように、システム１００は、コントローラのプログラミング、およびセンサ１００へのシステムの接続を監視して、プログラミング、またはプログラミングおよびセンサの両方が変更されているか否かを決定し得る。代替的には、ユーザは、入力デバイスを操作し得、システム１００は、入力デバイスからの入力の受信に従い、ユーザがプログラミング、またはプログラミングおよびセンサを修正したことを決定し得る。修正した場合、プロセス７００は、ブロック７０２に戻り得、修正しなかった場合、プロセス７００は、プロセス６００に戻り得る。

次いで、プロセス６００、特に、ブロック６０６に戻ると、システム１００は、さらなる規制承認が受信されたか否かを決定し得る。システム１００は、新規アクセスが受信されていない場合に規制承認が受信されていないか否かを決定し得る。代替的には、システム１００は、さらなる規制承認に関連した新規アクセスレベルに関連した新規キーまたはパスワードが受信された場合、承認が受信されていることを決定し得る。システム１００は、ブロック６０８において、動物試験アクセスに関連したキーまたはパスワードを受信し得る。

プロセス６００は、ブロック６１０におけるさらなる検査に続き、ブロック６１０における検査のプロセスは、再度、プロセス７００（および、潜在的には、プロセス８００）に反映される。システム１００が、以前に、ベンチ試験のための制御プログラミングおよびセンサの開発のために使用された場合（ブロック６０２、６０４において、この実施形態に従うように）では、システム１００は、プロセス７００内に含まれた、あるアクションを迅速に通過し得る。例えば、ベンチ検査の結果に基づいて、ユーザは、制御プログラミング、またはセンサの構成を再構成することを望み得ない。そのため、システム１００は、比較的迅速に、プロセス７００のブロック７０２、７０４のアクションを実行し、プロセスは、ほぼ直接、ブロック７０６に進み得る。

しかしながら、上述のように、異なるセーフガードは、異なるアクセスレベルが達成されるときに含まれ得る。そのような場合において、ユーザが、プログラミングに必要な任意の望ましい変更を有し得ないにもかかわらず、システム１００は、これらのセーフガードをプログラミングに組み込むように、プロセス８００の部分を実行することを必要とし得る。その結果、これは、ブロック８０６において、システムによって組み込まれたセーフガードのために、新規オプションが含まれるか、またはそれが課せられ得るので、システム１００がブロック８０８〜８１４のアクションを実施することにつながり得、システムがブロック８１６〜８２０のアクションも実行することをさらに要求する。

ブロック６１０において、検査が完了すると、システム１００は再度、ブロック６１２における承認を待つ。ヒト臨床試験アクセス（ブロック６１４において）を受信すると、システム１００は、プロセス６００がブロック６１６に進み得るかを決定し得る。

ブロック６１６において、システム１００は、ブロック６１４において受信されたアクセスが、システム１００が位置する地理的位置に適切であるか否かを決定し得る。つまり、ある種の規制承認、特に、ヒト臨床試験またはヒトへの使用に関与する規制承認は、通常、制限された地理的領域（単一の国家機関に関連した地理的領域に一致し得るか、または一致し得ない）に与えられる。そのため、例えば、米国において、特定の制御プログラミングおよびセンサとともに動作するシステム１００の例は、同様のプログラミングおよびセンサを有するシステム１００が欧州における使用に承認されているにもかかわらず、ヒト臨床試験に承認され得ない。したがって、システム１００が特定のアクセスレベルで機能性を許可する前に、アクセスの種類がシステム１００の正しい地理的配置と関連していることが必要であり得る。

システム１００が、適切な地理的位置に配置されるか否かについての決定は、多くの異なる方法で実行され得る。例えば、システム１００は、単に、検査が行われる（および、したがって、システム１００が位置する）地理的位置に関する情報に対するプロンプトに応じて、ユーザからの入力の受信を必要とし得る。次いで、システム１００は、得られた承認に対応するキーまたはパスワードに関連した、許可される地理的位置に関する情報を有する入力をチェックし得る。

かかる決定は、ある規制当局に対して不十分であり得が、「信用（ｈｏｎｏｒ）」システム上で明らかに動作する。したがって、システム１００は、システム１００がシステム１００の地理的位置を決定することを可能にするように、衛星ベースのナビゲーションシステムを用いて、関連システム１００に関する情報の測位を高精度で提供し得る全地球測位システム（ＧＰＳ）受信器を含み得るか、またはそれを実装し得る。次いで、システム１００は、得られた承認に対応するキーまたはパスワードに関連した許可された地理的位置に対して、ＧＰＳ受信器から得られた情報をチェックし得る。ＧＰＳ受信器の使用は、単に、ユーザ入力を伴わず（または、それに頼らず）に、システム１００の位置を決定するために使用され得る多くのオプションのうちの１つであることを認識するであろう。

上記に説明するように、システム１００が、同一の地理的位置に物理的に位置しない１つ以上の要素を含み得ることも認識するであろう。そのために、システム１００のある要素の地理的位置は、他のブロックよりもブロック６１６の決定において重要であり得る。例えば、システム１００の一部であり、プロセス８００を実施する際に使用され得るツールキットは、ポンプ１１４、ポンプコントローラ１１０、センサ１０６、およびインターフェース１０４に対して物理的に遠隔にあるコンピュータ１４０上に位置し得る。さらに、ポンプ１１４、ポンプコントローラ１１０、センサ１０６、およびインターフェース１０４の位置は、本開示のツールキットに従って動作するコンピュータ１４０の位置よりも、与えられた承認により大きく（または、独占的に）関係するものであり得る。したがって、システム１００は、全体のシステム１００の地理的位置の決定ではなく、むしろ、与えられた承認に対して地理的位置を決定するようにシステム１００の部分または要素をプログラムされ得る。そのために、システム１００がシステム１００の地理的位置を決定することを可能にするように、ＧＰＳ受信器がシステム１００に関連付けられている実施形態では、ＧＰＳ受信器は、（共通の筐体内での取付け、または配置により）システム１００が適切な地理的位置に位置するか否かについての決定に関連性があるシステム１００のこれらの要素と関連付けられ得る。

システム１００が、ブロック６１６の問合わせを完了すると、プロセスは、ブロック６０４、６１０と同様である、ブロック６１８に進み得る。検査が完了した後に、プロセス６００は、承認が、臨床試験の設定の外側のヒトの使用に対して得られたか否かをシステム１００が決定するブロック６２０に続く。かかる承認が得られる場合、プロセス６００は、システム１００がヒトへの使用アクセスを受信する、ブロック６２２に進む。

上記に注記するように、ブロック６２２においてシステム１００によって受信されたヒトへの使用アクセスは、特定の地理的位置に従って制限される可能性が高い。したがって、システム１００は、システム１００（または、システム１００の関連部分）が、得られた承認および与えられたアクセスに対して、適切な地理的位置に位置するか否かについて、ブロック６１６の決定と同様の決定を実施し得る。そのために、ブロック６１６に対して、上述の同一の種類のアクションもまた、ブロック６２２において行われ得る。

上記に注記するように、治療法管理開発プラットホームが、注入治療法管理に対して説明されているが、治療法管理開発の他の形態は、同様のプラットホームの使用を介して促進され得る。例えば、吸引治療法管理および腎臓治療法管理開発は、下記により詳細に説明する同様の治療法管理開発プラットホームの使用を介して利益がもたらされ得る。

吸引治療法管理に関しては、吸引治療法管理のためのシステムは、麻酔剤源に接続される、気化器を含み得る。気化器は、それをキャリアガスと混合して、麻酔剤を気化して、ガスを生成し、それは、吸引治療法の一部（例えば、集中治療室にいる患者に投与され得る等）として患者により吸引される。特に、ガスは、患者の口内に配置された気管内管を通過し得、代替的には、ガスは、患者の口および鼻の上に配置されたマスクを通過し得る。管またはマスクは、センサと関連し得、吸着媒体と関連付けられ得る。センサは、センサから受信された信号に従って、気化器により、管またはマスクを介して患者に投与されるガスの量を変化させ得る、気化器コントローラに連結される。

動作中、患者は、管またはマスクを介して、気化器によって提供されたガスを吸引する。呼気時において、おそらく吸引したガスの７０〜８０パーセントは、患者によって放出される。管またはマスクと関連した吸着媒体は、わずかな呼気された麻酔剤を捕捉し得る。次の患者の吸引時に、媒体によって捕捉された麻酔剤は、患者によって吸引される。吸引治療法管理システムは、管またはマスクと関連したセンサの使用を介して、各呼気または吸引に含有される麻酔剤の量を決定し得る。この決定に基づいて、気化器コントローラは、気化器からさらなるガスを追加し得る。

かかる吸引治療法管理システムは、上述の注入治療法管理システムとのある類似点を有する。特に、吸引治療法管理は、治療法または患者の特徴を決定する１つ以上のセンサに依存する。例えば、上述のシステムは、吸引または呼気の麻酔剤含有量／濃度を決定するためのセンサを含む。潜在的には、他のセンサもまた、例えば、血中酸素センサ、血圧センサ等のために使用し得る。さらに、気化器コントローラは、制御アルゴリズムを使用して、これらのセンサから受信された信号に応じて、気化器から患者に提供されるガスを変化させる。

結果として、図１〜７の実施形態のうちのいずれかに従う治療法管理開発システムの使用は、吸引治療法管理システムの開発においても有用であり得る。ポンプコントローラと相互作用するより、むしろ、治療法管理開発モジュールは、気化器コントローラとインターフェースする。使用されるセンサおよび制御アルゴリズムの特質が異なり得るが、かかる吸引治療法管理開発システムおよび方法の使用の一般的な枠組みおよび方法は、注入治療法管理開発システムに対して上述のものと同様の経路で動作する。したがって、異なる実施形態および上述のこれらの実施形態への変更は、吸引治療法管理に対する開発システムの設計および使用に等しい効果を及ぼす。

腎臓治療法および腎臓治療法管理については、上述の注入治療法管理システムに対する腎臓治療法管理システムの動作、およびかかる腎臓治療法管理システムによって使用するための治療法管理開発システムの有用性に関して同様の批評をすることができる。

例えば、１つの従来の腎臓治療法は、血液透析である。血液透析では、血液ポンプを使用して、患者から採血し、透析器を通して血液を通過させ、次いで、第１の回路に沿って血液を患者に戻す。第２の別個の回路において、別個のポンプを使用して、透析器を通して透析物を循環させる。透析器内において、老廃物は、血液から透析器へと膜／フィルタを通って通過する。コントローラは、ポンプおよび両方の回路内に配置されたセンサの両方に連結され得る。センサは、流速、ならびに透析物の伝導率、温度、およびｐＨを監視し得る。コントローラは、センサから受信された信号に従って、ポンプのうちの１つまたは両方の動作を変化させ得る。

吸引治療法の場合そうであったように、センサデータに従って構成要素の動作を変化させるコントローラの包含（血液統制の場合、血液ポンプおよび透析物ポンプ）は、腎臓管理法について有用な吸引治療法に関連して説明される上述の開発システムおよびツールを作成すると考えられる。その上、血液透析と語頭音消失との間の類似点を考慮すると、上述の治療法管理システムおよび方法は、語頭音消失治療法管理に関しても有用であり得ると考えられる。

Claims (8)

1. 治療法管理を提供する医療デバイスを備える治療法管理システムの開発を促進する方法であって、該方法は、
   コンピュータ化した治療法管理開発プラットホームを提供することであって、該コンピュータ化した治療法管理開発プラットホームは、該治療法管理システムと通信可能なように連結されるように構成されることと、
   該治療法管理システムの非治療機能性への第１のアクセスレベルを提供するように、該コンピュータ化した治療法管理開発プラットホームを構成することであって、ここで、該第１のアクセスレベルは、該治療法管理システムを用いて該医療デバイスを試験または開発するためのものである、ことと、
   該コンピュータ化した治療法管理開発プラットホームにおいて、該コンピュータ化した治療法管理開発プラットホームを構成する承認の指示を受信して、該治療法管理システムの非治療機能性への第２のアクセスレベルを提供することであって、ここで、該第２のアクセスレベルは、該治療法管理システムを用いて該医療デバイスを試験または開発するためのものであり、該第１のアクセスレベルとは異なる、ことと、
   該承認の指示の受信に応じて、該治療法管理システムの非治療機能性への該第２のアクセスレベルを提供するように、該コンピュータ化した治療法管理開発プラットホームを構成することと
   を含む、方法。
2. 前記第１のアクセスレベルは、前記医療デバイスの試験における段階に対応し、該段階は、ベンチ試験、動物試験、および、ヒト臨床試験での使用のうちの１つを含む、請求項１に記載の方法。
3. 前記治療法管理システムの前記非治療機能性への該第２のアクセスレベルを提供するように前記コンピュータ化した治療法管理開発プラットホームを構成する前記承認の指示は、地理的位置と関連し、前記方法は、前記医療デバイスが該地理的位置に配置されているか否かを決定することをさらに含む、請求項１または２に記載の方法。
4. 前記治療法管理システムの試験または開発は、プロトタイプセンサを有する該治療法管理システムを使用すること、または治療法管理を制御するために該治療法管理システムによって使用される制御アルゴリズムの動作を変更することを含む、請求項１〜３のうちのいずれか一項に記載の方法。
5. 前記治療法管理システムの前記非治療機能性への第１のアクセスレベルを提供するように、前記プラットホームを構成している間に、前記コンピュータ化した治療法管理開発プラットホームを使用して前記医療デバイスを試験することをさらに含む、請求項１〜４のうちのいずれか一項に記載の方法。
6. 前記コンピュータ化した治療法管理開発プラットホームを使用して前記医療デバイスを試験することは、仮想の生理学的モデルおよびセンサモデルを使用することを含む、請求項５に記載の方法。
7. 前記医療デバイスは、ポンプと、ポンプコントローラとを備える、請求項１〜６のうちのいずれか一項に記載の方法。
8. 前記コンピュータ化した治療法管理開発プラットホームの前記アクセスレベルに従って、顧客料金を設定することをさらに含む、請求項１〜７のうちのいずれか一項に記載の方法。

Images