(57)【特許請求の範囲】
【請求項１】
患者の慢性疾患管理のためのシステム（１０）であって、
該システムが、プロセッサ（１６、３４）を備え、
該プロセッサが、
最新のグルコース情報と、過去のインスリン放出情報と、前記患者の食事、運動、治療介入のうち少なくとも１つを含むイベント情報とを含む、情報入力に基づく治療推奨を提供する経験的アルゴリズム（ＥＡ）モジュール（５１８）と、
前記治療推奨を決定するために、すべての新しい情報入力を処理し、前記ＥＡモジュール（５１８）に前記新しい情報入力を供給するＡＬＧＯコントローラ（５１０）とを実行し、
該ＡＬＧＯコントローラ（５１０）が、操作の閉ループモードおよび開ループモード（６００、７００）をサポートし、前記ＡＬＧＯコントローラ（５１０）が、測定遅延によりグルコース測定が利用できないことと、最後の利用可能なグルコース測定が許容可能なグルコース使用期限より古いために、その時間を示したｂＧ測定が期限切れであることとの両方が存在するとき、前記閉ループモード（６００）から前記開ループモード（７００）に入り、
前記閉ループモード（６００）において、前記ＡＬＧＯコントローラ（５１０）が、上限および下限の目標グルコースによって境界が示される所定の目標領域（６０１）でグルコースを維持するために、グルコース測定を用いて、コマンドインスリンモジュール（６１６）、高グルコース治療介入モジュール（６１８）、食事補償器モジュール（６２０）、運動補償器（６２２）および低グルコース補償器モジュール（６２４）のうちの少なくとも１つをトリガーして、わかっている障害を処理し、グルコース予測器（６２６）および基礎制御装置（６２８）のうちの少なくとも１つをトリガーして、不明な障害およびモデル化エラーを処理することを特徴とするシステム。
【請求項２】
前記食事補償器モジュール（６２０）、運動補償器モジュール（６２２）および低グルコース治療介入モジュール（６２４）は、前記開ループモード（７００）で実行されないことを特徴とする請求項１記載のシステム（１０）。
【請求項３】
患者の慢性疾患管理のためのシステム（１０）であって、
該システムが、プロセッサ（１６、３４）を備え、
該プロセッサが、
最新のグルコース情報と、過去のインスリン放出情報と、前記患者の食事、運動、治療介入のうち少なくとも１つを含むイベント情報とを含む、情報入力に基づく治療推奨を提供する経験的アルゴリズム（ＥＡ）モジュール（５１８）と、
前記治療推奨を決定するために、すべての新しい情報入力を処理し、前記ＥＡモジュール（５１８）に前記新しい情報入力を供給するＡＬＧＯコントローラ（５１０）とを実行し、
該ＡＬＧＯコントローラ（５１０）が、操作の閉ループモードおよび開ループモード（６００、７００）をサポートし、前記ＡＬＧＯコントローラ（５１０）が、測定遅延によりグルコース測定が利用できないことと、最後の利用可能なグルコース測定が許容可能なグルコース使用期限より古いために、その時間を示したｂＧ測定が期限切れであることとの両方が存在するとき、前記閉ループモード（６００）から前記開ループモード（７００）に入り、
前記ＥＡモジュール（５１８）は、プロセスセンサデータモジュール（８０６）、インスリン設定点モジュール（８０４）、グルコース予測モジュール（８３８）、インスリン推奨モジュール（８４６）、運動補償器モジュール（８２２）、即効性の炭水化物摂取モジュール（８２４）、食事補償器モジュール（８４０）および開ループ基礎実行論理モジュール（８５０）を含む主要制御行為用モジュールを有し、前記プロセスセンサデータモジュール（８０６）は、利用可能な測定グルコース値からグルコース値を決定し、前記インスリン設定点モジュール（８０４）は、目標基礎グルコースを維持するために用いられるインスリン注入速度であり、前記グルコース予測モジュール（８３８）は、最後のわかっているグルコース測定値から制御サイクル用の前記グルコース値を予測し、前記インスリン推奨モジュール（８４６）は、基礎グルコースを維持するためにインスリン投与量を計算し、前記運動補償器モジュール（８２２）は、増大した身体活動レベルを処理し、前記即効性の炭水化物摂取モジュール（８２４）は、予想されるグルコース低下を補償するために即効性の炭水化物の摂取を処理し、前記食事補償器モジュール（８４０）は、食事イベント用のインスリンボーラス分布を計算し、および前記開ループ基礎実行論理モジュール（８５０）は、前記開ループモード（７００）中、基礎インスリンを実行することを特徴とするシステム。
【請求項４】
患者の慢性疾患管理のためのシステム（１０）であって、
該システムが、プロセッサ（１６、３４）を備え、
該プロセッサが、
最新のグルコース情報と、過去のインスリン放出情報と、前記患者の食事、運動、治療介入のうち少なくとも１つを含むイベント情報とを含む、情報入力に基づく治療推奨を提供する経験的アルゴリズム（ＥＡ）モジュール（５１８）と、
前記治療推奨を決定するために、すべての新しい情報入力を処理し、前記ＥＡモジュール（５１８）に前記新しい情報入力を供給するＡＬＧＯコントローラ（５１０）とを実行し、
該ＡＬＧＯコントローラ（５１０）が、操作の閉ループモードおよび開ループモード（６００、７００）をサポートし、前記ＡＬＧＯコントローラ（５１０）が、測定遅延によりグルコース測定が利用できないことと、最後の利用可能なグルコース測定が許容可能なグルコース使用期限より古いために、その時間を示したｂＧ測定が期限切れであることとの両方が存在するとき、前記閉ループモード（６００）から前記開ループモード（７００）に入り、
前記ＥＡモジュール（５１８）は、初期化／準備モジュール（８００）、欠けたサイクル処理モジュール（８０１）、イベントマッピングモジュール（８０２）、インスリンバケットモジュール（８４８）およびインスリン無効化モジュール（８３６）を含む管理およびハウスキーピング用モジュールを有し、前記初期化／準備モジュール（８００）は、過去、現在および未来の情報を管理する、前記ＡＬＧＯコントローラ（５１０）の状態ベクトルであり、前記欠けたサイクル処理モジュール（８０１）は、任意の理由からスキップされた呼び出しの再起動を処理し、前記イベントマッピングモジュール（８０２）は、外部イベント設定を内部イベント設定にマッピングし、前記インスリンバケットモジュール（８４８）は、バケットを満たすための成分およびバケットを空にするための成分として種々のモジュールから前記インスリン推奨を管理し、および前記インスリン無効化モジュール（８３６）は、最後のインスリン放出から制御行為のフィードフォーワード条件から生じる任意のインスリン成分を無効にすることを特徴とするシステム。
【請求項５】
前記ＥＡモジュール（５１８）の行為が、インデックスベースであり、実時間に依存しないことを特徴とする請求項１〜４のいずれか１項に記載のシステム（１０）。
【請求項６】
前記アルゴリズム（ＡＬＧＯ）コントローラ（５１０）が、任意の所与の相対時間ｔで、前記ＡＬＧＯコントローラ（５１０）が、現在の時間Ｔに対して、前記ＡＬＧＯコントローラ（５１０）への呼び出しがどの制御サイクル期間Ｔcに参加するかを決定するように、ソフト時間制御を実行することを特徴とする請求項１〜５のいずれか１項に記載のシステム（１０）。
【請求項７】
前記情報入力が必要とされる時間期間が、インスリン活動の効果を消去する時間と、前記ＡＬＧＯコントローラ（５１０）が呼び出されない欠けた制御サイクルを補うためのバッファとしての複数の余分の制御サイクルとに依存することを特徴とする請求項１〜６のいずれか１項に記載のシステム（１０）。
【請求項８】
欠けた制御サイクルの場合、呼び出される前記ＡＬＧＯコントローラ（５１０）が、現在の呼び出しを実行する前に、前記欠けた制御サイクルのそれぞれを通して、欠けた呼び出しおよび工程を検出することを特徴とする請求項７記載のシステム（１０）。
【請求項９】
前記開ループモードが、手動で制御され、前記患者の予めプログラムされたポンプ基礎速度を用いて実行され、コマンドによるボーラスイベントの使用により増強され、前記ＡＬＧＯコントローラ（５１０）が、新しいグルコース測定の入力により、開ループモードに切り替わった後に閉ループモードで作動することが可能であることを特徴とする請求項１〜８のいずれか１項に記載のシステム（１０）。
【請求項１０】
前記ＥＡモジュール（５１８）は、新しいグルコース測定値の利用可能性を追跡するグルコース更新モジュール（８０８）、新しいグルコース値の必要性があるかどうかを前記患者に通知する期限切れグルコースモジュール（８１４）、自己ボーラスコマンドによって任意のインスリン不一致を説明する自己ボーラスモジュール（８１０）、および前記患者に食事の開始を通知する食事注意書モジュール（８４２）を含む、状態を監視して通知するためのモジュールを有することを特徴とする請求項１〜９のいずれか１項に記載のシステム（１０）。
【請求項１１】
前記ＥＡモジュール（５１８）は、炭水化物修正モジュール（８３４）、高グルコース治療介入モジュール（８３２）、低グルコース治療介入モジュール（８２６）、食事グルコース領域モジュール（８２０）および不一致管理モジュール（８１８）を含む補正行為用モジュールを有し、前記炭水化物修正モジュール（８３４）は、前に入力された食事イベント（炭水化物値）を改訂し、したがって、インスリン放出が補正され、前記高グルコース治療介入モジュール（８３２）は、インスリン放出によって高いグルコースレベルを補正し、前記低グルコース治療介入モジュール（８２６）は、即効性の炭水化物の摂取を推奨することによって低いグルコースレベルを補正し、前記食事グルコース領域モジュール（８２０）は、下および上の設定点の範囲を有する領域としてグルコース目標を定義し、前記不一致管理モジュール（８１８）は、コマンドによるインスリンと放出されたインスリンとの間の不一致が特定されたときに、インスリンバケットを管理することを特徴とする請求項１〜１０のいずれか１項に記載のシステム（１０）。
【請求項１２】
前記ＥＡモジュール（５１８）は、準備運動モジュール（８２８）およびコマンドによるボーラスモジュール（８３０）を含む、主要イベントを処理するためのモジュールを有し、前記準備運動モジュール（８２８）は、運動制御装置の予想した基礎要件を改訂し、特定の運動の開始で前記制御装置（５１０）に通知し、前記コマンドによるボーラスモジュール（８３０）は、さらなるインスリンボーラスを要求することを特徴とする請求項１〜１１のいずれか１項に記載のシステム（１０）。
【請求項１３】
シミュレート時間は、シミュレート環境が提供されるように、前記ＡＬＧＯコントローラ（５１０）に提供されることを特徴とする請求項１〜１２のいずれか１項に記載のシステム（１０）。
【請求項１４】
シミュレート環境において前記ＥＡモジュール（５１８）および前記ＡＬＧＯコントローラ（５１０）を使用するシミュレーションを設定し、実行して、患者に固有の治療法を作成するために、ユーザからの入力を可能にするユーザインターフェイス（９００）をさらに有することを特徴とする請求項１〜１３のいずれか１項に記載のシステム（１０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、慢性疾患管理に関し、さらに詳細には、患者生理学の動的モデル化に基づき、慢性疾患管理に関する各患者に固有の治療法を作成するためのコンピュータ化システムおよびその方法に関する。
【背景技術】
【０００２】
伝統的に、治療／処置は、疾患または病気を診断するための１回の臨床検査および測定デバイスに基づいて行なわれている。大概において、そのような検査およびデバイスの使用意図は、１つの定性測定結果を入手することである。そのような測定によれば、概要は得られる。しかし、システムダイナミクスおよび疾患の根本的なシステム特性を理解するためには、一連の複数の測定が必要となる。
【０００３】
一連の測定によれば、明らかに、多くのデータが結果として生じる。しかし、そのようなデータをすぐに使用可能な情報に変換することは、常に容易であるとは限らない。医療活動において有用な連続的測定または頻繁な測定によって提供される、より豊富なデータを作成するために、どんな問題に対応することができるかおよびどんな要件が必要とされるかを識別することは、実際には決して些細な行為ではない。さらに、製薬会社は、薬剤の代謝活性を特徴付けて、薬剤用量計画を決定する行為を行う。一般に、製薬会社は、目標母集団に関する力価および薬効を決定するために、複雑な治験を行う。しかし、厳密に言えば、薬剤に関する薬物動態学および薬力学はいずれも、各患者に固有である。慢性疾患の変動性により、インスリン薬剤が日常的に用いられる糖尿病患者などの病気のための投薬決定には、母集団に基づく手法は理想的に適しているわけではない。そのような場合には、投与計画が通常は、所与の指針から始まり、実施医療従事者によって微調整される。通常、医療提供者は、患者と協力して、制御監視およびインスリン用量調整計画を見守る。
【０００４】
糖尿病の最も頻度の高い形態は、インスリンの産生の低下（１型糖尿病、第１の認識形態）またはインスリンの生体組織の感受性の低下（２型糖尿病、よく見られる形態）による。前者の処置は、インスリン注射であるのに対して、後者は一般に、経口薬によって管理され、経口薬が有効でない場合に、インスリンを必要とするに過ぎない。糖尿病の損傷効果を加速する他の健康問題は、喫煙、コレステロール高値、肥満、高血圧および定期的な運動の欠如である。したがって、処置を理解して参加する患者は、血糖値が連続的に変化するため、元気である。
【０００５】
グルコースの制御は、臓器におけるグルコースの損傷効果を緩和するための最適な方法である。通常治療（ＣＴ）、強化通常治療（ＩＣＴ）およびポンプユーザ用の強化通常治療（ＣＳＩＩ）が、グルコースを制御するために用いられる一般的な対処法である。そのような治療の限界は、生理的変動性、代謝の差、ストレス、運動、疾病および食事の影響などの各患者に固有の要因を考慮するツールを利用しないことである。
【０００６】
グルコース濃度は、正常血糖の制御のため（たとえば、血液中のグルコースの正常値を提供するため）に通常は測定される一次パラメータである。よりよい処置を決定するための他の利用可能な情報は、食事の摂取、身体活動の実行、仕事関連のストレスなどの種々の活動から生じる代謝負荷に関連する。インスリン放出、他の投薬などは、対象となる生理的パラメータに関する別の調整機構である。治療基準は、グルコース測定、インスリン感受性、インスリン対糖質の比、基礎インスリン速度、ストレスレベルおよび運動の効果などの他の要因に関して定義される。グルコース測定以外は、現在の対処法は、グルコース測定に基づき、経験則、実験則および反復評価に基づくパラメータを決定する。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記を鑑みて、日常生活において糖尿病患者の必要性に対処するために、現在の臨床的対処法における深刻な欠点がある。利用可能な多様な対処法を統合する１つの解決策は存在しない。現在までに提案された方法は、各患者に固有の必要性を直接的に評価するのではなく、試行およびエラーを通じて長期にわたって特質に対処している。さらに、当業界において利用可能な種々の対処法を統合するだけでは、所望の効果を実現しないであろう。安全性、精度および堅牢性の所望のレベルと連動させるために、全般的なプロセスに関して、作成し調整されなければならない方法のそれぞれについて特有の要素がある。さらに、そのような慢性病および／または疾患に関する治療法を策定するときに、時間をかけて各患者に固有の情報を収集し、収集された情報を各患者に固有の動的なモデルに適用するためのツールを医療実行者に提供することが望ましい。
【課題を解決するための手段】
【０００８】
本発明は、添付の請求項に記載の特徴のうちの１つまたは複数および／または以下の特徴およびその組み合わせの１つまたは複数を含むことができる。
【０００９】
一実施形態において、患者の慢性疾患管理のための各患者に固有の治療法を作成するために、ユーザによって用いられるコンピュータ化システムが、開示される。システムは、システムがデータ収集手順に基づき、各患者に固有のデータを収集し、各患者に固有のデータにおける完全性および品質検査を行うことを可能にするデータ収集モジュールと、ユーザがシステムによって提供された複数の患者モデルから患者モデルを選択することを可能にするユーザインターフェイスと、選択された患者モデルをシステムが検証することを可能にするモジュール検証モジュールと、有用な各患者に固有の生理的情報を抽出し、抽出された各患者に固有の生理的情報を使用して、患者の慢性疾患に処置を施すための１つまたは複数の各患者に固有の治療法を作成するために、選択された患者モデルに各患者に固有のデータをシステムが適用することを可能にする分析モジュールと、システムが１つまたは複数の各患者に固有の治療法を検証し、承認のためにユーザインターフェイスに１つまたは複数の各患者に固有の治療法のうちの検証された治療法を提示することを可能にする結果検証および提示モジュールとを含む。
【００１０】
別の実施形態において、各患者に固有の生理学の動的モデル化に基づき、各患者に固有の治療法を作成するためのコンピュータ化システムが、開示される。システムは、少なくとも１つのデータベースまたは他のメモリユニットに格納される複数のソフトウェアモジュールへのアクセスを提供するように構成されるコンピュータを備える。多数のソフトウェアモジュールは、少なくとも収集される各患者に固有のデータのタイプおよび各患者に固有のデータが収集される態様を定義する１つまたは複数のデータ収集手順へのコンピュータを介したアクセスを提供するように構成される第１のソフトウェアモジュールと、患者の生理学の１つまたは複数の態様をシミュレートするように構成される１つまたは複数の各患者に固有のモデルを作成する情報へのコンピュータを介したアクセスを提供するように構成される第２のソフトウェアモジュールと、そこから１つまたは複数の各患者に固有の治療法を決定するために、１つまたは複数のデータ収集手順に基づき収集された各患者に固有のデータを１つまたは複数の作成された各患者に固有のモデルに適用する１つまたは複数のソフトウェアツールへのコンピュータを介したアクセスを提供するように構成される第３のソフトウェアモジュールと、各患者に固有の治療法を検証する１つまたは複数のソフトウェア検証ツールへのコンピュータを介したアクセスを提供し、コンピュータに１つまたは複数の各患者に固有の治療法を提示するように構成される第４のソフトウェアモジュールとを含む。
【００１１】
さらに別の実施形態において、コンピュータ化システムにおける患者の慢性疾患管理のための各患者に固有の治療法を作成するコンピュータ実行方法が、開示される。その方法は、システムがデータ収集手順に基づき、各患者に固有のデータを収集し、各患者に固有のデータにおける完全性および品質検査を行うことを可能にするデータ収集モジュールを提供することと、ユーザがシステムによって提供される複数の患者モデルから患者モデルを選択することを可能にするユーザインターフェイスを提供することと、選択された患者モデルをシステムが検証することを可能にするモジュール検証モジュールを提供することと、有用な各患者に固有の生理的情報を抽出し、抽出された各患者に固有の生理的情報を使用して、患者の慢性疾患に処置を施すための１つまたは複数の各患者に固有の治療法を作成するために、選択された患者モデルに各患者に固有のデータをシステムが適用することを可能にする分析モジュールを提供することと、システムが１つまたは複数の各患者に固有の治療法を検証し、承認のためにユーザインターフェイスに１つまたは複数の各患者に固有の治療法のうちの検証された治療法を提示することを可能にする結果検証および提示モジュールを提供することとを含む。
【００１２】
さらに別の実施形態において、コンピュータにおける各患者に固有の生理学の動的モデル化に基づき、各患者に固有の治療法を作成するためのコンピュータ実行方法が、開示される。その方法は、少なくとも１つのデータベースまたは他のメモリユニットに格納される複数のソフトウェアモジュールへのアクセスを提供するようにコンピュータを構成することと、少なくとも収集される各患者に固有のデータのタイプおよび各患者に固有のデータが収集される態様を定義する１つまたは複数のデータ収集手順へのコンピュータを介したアクセスを提供するようにソフトウェアモジュールのうちの第１のソフトウェアモジュールを構成することと、患者の生理学の１つまたは複数の態様をシミュレートするように構成される１つまたは複数の各患者に固有のモデルを作成する情報へのコンピュータを介したアクセスを提供するようにソフトウェアモジュールのうちの第２のソフトウェアモジュールを構成することと、そこから１つまたは複数の各患者に固有の治療法を決定するために、１つまたは複数のデータ収集手順に基づき収集された各患者に固有のデータを１つまたは複数の作成された各患者に固有のモデルに適用する１つまたは複数のソフトウェアツールへのコンピュータを介したアクセスを提供するようにソフトウェアモジュールのうちの第３のソフトウェアモジュールを構成することと、各患者に固有の治療法を検証する１つまたは複数のソフトウェア検証ツールへのコンピュータを介したアクセスを提供し、コンピュータに１つまたは複数の各患者に固有の治療法を提示するように構成されるソフトウェアモジュールのうちの第４のソフトウェアモジュールを構成することとを含む。
【００１３】
本発明のこれらの特徴および利点および他の特徴および利点は、添付図面と共に考慮すれば、本発明の種々の実施形態の以下の説明からさらに十分に理解されるであろう。
【００１４】
本発明の実施形態の以下の詳細な説明は、以下の図面を照らして読めば、最もよく理解されることができる。類似の構造は、同様の参照符号によって表される。
【図面の簡単な説明】
【００１５】
【図１】情報を通信することができ、患者の活動を捕捉し、インスリン治療において援助するために用いられる種々の糖尿病管理ユーティリティツール／デバイスのブロック図である。
【図２】本発明による患者生理学動的モデル化に基づく各患者に固有の治療法を作成するための診断、治療および予測システム（ＤＴＰＳ）の実施形態を示すブロック図である。
【図３】図２のシステムにおいて用いられるソフトウェア実施形態のブロック図であり、本発明による機能的モジュール部分を示す。
【図４】本発明による各患者に固有の治療法を作成するためのプロセスの１つの例示の実施形態のフローチャートである。
【図５】本発明の実施形態による各患者に固有の治療法を作成するための自動膵臓システム（ＡＰＳ）を提供するために、図２のシステムにおいて用いられるソフトウェア構成要素のブロック図である。
【図６】本発明の実施形態によるグルコース測定を用いる閉ループシステムとして、図５のソフトウェアが各患者に固有の治療法に基づき、適切な制御行動を提供することを可能にするために、図２のシステムにおいて用いられるソフトウェア構成要素、デバイスおよびインタラクションのブロック図である。
【図７】本発明の実施形態による開ループシステムとして、図５のソフトウェアが各患者に固有の治療法に基づき、適切な制御行動を提供することを可能にするために、図２のシステムにおいて用いられるソフトウェア構成要素、デバイスおよびインタラクションのブロック図である。
【図８】本発明の経験的アルゴリズムの実施形態によるモジュール実行のシーケンスを示すプロセス流れ図である。
【図９】本発明の経験的アルゴリズムの実施形態によるモジュール実行のシーケンスを示すプロセス流れ図である。
【図１０】一日の異なる時間におけるインスリンとグルコースとの間の設定点関係を示すグラフである。
【図１１】本発明による第１の処理機能に関する時間間隔の選択をグラフによって示す図である。
【図１２】本発明による第２の処理機能に関する時間間隔の選択をグラフによって示す図である。
【図１３】異なるグルコースゾーンシナリオを示す１対のグラフである。
【図１４】即効性の炭水化物摂取のためのグルコースプッシュを示すグラフである。
【図１５】時間に関する即効性の炭水化物プッシュに対する血糖応答を示すグラフである。
【図１６】本発明による炭水化物修正モジュールの処理の表示である。
【図１７】インスリン残留薬力学を示すグラフである。
【図１８】時間に関する単位ボーラス投与に関するインスリンに対する変化を示すグラフである。
【図１９】インスリンインパルス予測を示すグラフである。
【図２０】本発明によるアルゴリズムによって用いられるタイミング図を示すグラフである。
【図２１】本発明によるモデルパラメータ識別を示すために、実施例として提供されるグラフである。
【図２２】各患者に固有の治療法を作成するための図２のシステムにおいて実行する本発明による自動膵臓制御アルゴリズム試験項目群（ＡＰＣＡＴＳ）ソフトウェア用のグラフィカルユーザインターフェイスの図である。
【図２３】本発明によるＡＰＣＡＴＳソフトウェアのモジュールブロック間の接続およびブロック間の情報の流れを示すブロック図である。
【図２４】本発明によるシミュレーション環境に関する患者モデルパラメータを変更するために用いられるプラントメニューウィンドウを提供するグラフィカルユーザインターフェイスの図である。
【図２５】本発明によるシミュレーション環境に関する故障メニューウィンドウを提供するグラフィカルユーザインターフェイスの図である。
【図２６】本発明によるシミュレーション環境に関するイベント入力フォームを提供するグラフィカルユーザインターフェイスの図である。
【図２７】本発明によるシミュレーション環境に関する選択治療食／累積的運動を提供するグラフィカルユーザインターフェイスの図である。
【図２８】本発明によるシミュレーション環境に関する接続ポート形態を提供するグラフィカルユーザインターフェイスの図である。
【図２９】データの読み込み、データの保存およびシミュレーションの実行のための基本的機能性を提供する図２２のグラフィカルユーザインターフェイスの実行／格納ペイン部分の図である。
【図３０】ユーザが、シミュレーションの開始時間および停止時間を設定し、統合ルーチンおよび工程のサイズを選択し、シミュレーションを実行することを可能にする本発明によるシミュレーション環境用のシミュレーションパラメータフォームを提供するグラフィカルユーザインターフェイスの図である。
【図３１】ユーザが、スクリーン上またはハードコピーとして実験データをグラフ化することを可能にする図２２のグラフィカルユーザインターフェイスのプロットペイン部分の図である。
【図３２】本発明によるシミュレーション環境用の起動入力フォームを提供するグラフィカルユーザインターフェイスの図である。
【図３３】本発明の実施形態によるソフトウェア構成要素の実行シーケンスを示すプロセスの流れである。
【図３４】本発明の実施形態による制御期間を示すグラフである。
【図３５】本発明によるアルゴリズム呼び出しに対するパラメータの更新を示す。
【発明を実施するための形態】
【００１６】
一般に、本発明は、動的システムにおいて人間の生理学および個人の代謝活性を分析し、ユーザが手順を定義して、収集データを分析し、治療要件を微調整し、各患者に固有の診断、治療アドバイスおよび予測を提供することを可能にすることによって、糖尿病、喘息および心臓疾患などの事実上慢性である疾患の分析処置および管理を助けるコンピュータアーキテクチャおよびプロセスである。本願明細書における本発明は、１人の患者を助けることに関して記載されているが、本発明は、複数の患者を助けるために用いられてもよいことは理解されたい。
【００１７】
一実施形態において、本発明は、提案された解決策を試験し、その信頼区間を提供することによって、治療成績を向上させる。場合によっては、提案された解決策は、特に、１つの効果または場合によっては複数の効果の特徴付けおよび／または制御に対処するための特殊な手順である。母集団に基づく基準を用いて問題に対処するのではなく、本発明の方法は、最初から、各患者に固有の疾患状態を想定し、患者の代謝の検討事項、生理的検討事項および生活様式の検討事項に治療法を合わせる。
【００１８】
一実施形態において、本発明は、各患者に固有のインスリン治療法を決定するための必要性に直接的に対処する体系的ツールを提供する。本発明のプロセスは、開ループシステム、閉ループシステムおよび半閉ループシステムに適用可能であり、種々のグルコース測定方法および種々のインスリン放出方法に適合可能なことを認識すべきである。他の実施形態において、本発明は、連続的薬剤治療を必要とする他の慢性病に適用可能である。
【００１９】
本発明は、生理的モデル、代謝モデルおよび薬剤の薬物動態学および薬力学および関連パラメータに基づく薬剤投与量を決定するための数学を用いる。当業者は、薬物動態学が薬剤の吸収、分布、代謝および排出の研究であるのに対して、薬力学が薬剤の生化学的効果および生理的効果、作用および薬剤効果に対する薬剤濃度の相関のメカニズムの研究であることを理解されよう。一実施形態において、本発明は、入力データに作用するために薬力学の方法論をコンピュータ化し、不利または有利のいずれであれ、薬物動態学と薬理学的効果との間の関係を出力として提供する。
【００２０】
本発明は、ユーザが種々の生理的状態の薬理学的効果を理解することを助け、疾患の診断および治療の改善を助け、各患者に固有である治療法のほか、既存の治療法より厳密な治療法の作成も可能にする。本発明のそのシステムおよび方法は、個人の慢性疾患に関する予測を提供するために、さらに拡張される。
【００２１】
一実施形態において、本発明は、（ｉ）デバイスおよび（ii）アルゴリズムの受信／命令、（iii）情報結果／すぐに使用可能な結果／警告の結果のユーザへの通知のための一般的な入力項目および／または一般的な出力項目の観点から装置を開示する。イベント情報は、連続的な更新であってもよく、または個別の方式で発生されてもよい。したがって、イベントは、トランザクションである。方法はさらに、治療法の生成を可能にするアルゴリズム構造について記載する。
【００２２】
別の実施形態において、本発明は、収集されたグルコースデータおよび他の利用可能な情報を用いて、各患者に固有のモデルを合成し、そのモデルを用いて治療パラメータを決定する方法を開示する。このプロセスは、（１）各患者に固有のモデルを特定することと、（２）種々の生理的パラメータを定義することと、を含んでもよい。特定されたモデルは、シミュレートされるか、または生理的パラメータの定義を満たし、それらの値を推論するように特異的分析ツールが適用される。決定されたパラメータは、各患者に固有のモデルから導出されるため、各患者に固有である。
【００２３】
別の実施形態において、本発明はさらに、ＡＤＡ指針などの要件を満たす安定かつ堅牢な解決策を確保するために、シミュレーションを介した重大なシナリオの評価を含めた種々の分析をユーザが行うことを可能にし、および／またはたとえば、ＨｂＡ１Ｃなどの一次パラメータをその対象の所望の目標範囲内に維持する。
【００２４】
したがって、本発明は、患者の特徴的な挙動の分析を助け、今度はこの分析を用いて、治療法の決定、治療結果の考察および患者特性の理解を行うツールを医療実行者が有することを可能にする。本発明は、患者データの格納、数学的分析ツール、データ表示方法、外部デバイスとの統合、データ整合性手法、安定性および堅牢性のために試験される治療アプローチなどの種々のシステム構成要素を内蔵する統合システムであり、合わせて糖尿病患者に関する診断、治療決定および予測に対する優れた手法を提示する。以下では、実施例として糖尿病を用い、本発明は、さらに詳細に述べられる。特に、本発明によって用いられる測定、分析および他の情報に関する説明が、ここで提供される。
【００２５】
測定および分析
周知であるように、糖尿病は、身体の生理学が種々の病因的理由のために、血糖を調整することが正常に機能していない代謝症候群である。この疾患を管理するために、患者の活動を捕捉し、インスリン治療において援助するために用いられる多くの糖尿病管理入力、ユーティリティツールおよびデバイスがある。たとえば、図１は、所定のインスリン治療の有効性を決定して評価するために、相互に作用して、情報を交換することを必要とする糖尿病を管理するための代表的な疾患管理構成要素の図である。疾患管理構成要素としては、パーソナルコンピュータと、データ管理用の集中型データベースと、ユーザ入力、グルコース測定およびインスリン供給量に基づくポンプ注入を管理するための手段を提供するアルゴリズムと、測定、検査などのユーザインターフェイスを介したユーザ入力と、測定、検査などのユーザインターフェイスを介した医療従事者（ＨＣＰ）入力と、スマートインスリンポンプと、スマート血糖（ｂＧ）測定計と、独立に機能する一体型デバイスまたは独立型デバイスのいずれであってもよい他のハンドヘルド型デバイスと、が挙げられる。一般に、これらの疾患管理構成要素は、互いと情報を交換するために相互に作用し、これは図１において矢印によって示される。そのような情報（データ）交換は、構成要素に関連するプログラム／構成要素によって関数呼び出しが提供されるプログラムによって行われ、入力引数／出力引数と共に呼び出されるときの正規の要件である。引数は、構造的コンテンツを表し、デバイス疾患管理構成要素の少なくともすべてが理想的には、そのような構造およびその潜在的なコンテンツ／実際のコンテンツを理解すべきである。しかし、そのようなシステムにおいて、イベントが生じたことを種々の構成要素に知らせることは、問題である。イベントは、１つの構成要素によって生成される情報の単位であり、別の構成要素によって用いられ得る（たとえば、ｂＧ測定、低血糖発作値、高血糖発作値、投薬量の調整、手順の変更、アルゴリズムの変更など）。特に、問題は、そのような疾患管理構成要素を用いる大量の集合の使用事例から必要な情報を捕捉する情報構造を提供することにある。さらなる問題は、糖尿病などの慢性疾患の管理時の情報の交換は、時間が肝心である上に、中身も肝心であるという点にある。さらに、交換された情報は、機械解釈用のデバイスのほか、人間解釈用の人間によって使用可能でなければならない。
【００２６】
交換情報の特性もまた、別の問題である。たとえば、慢性疾患の管理における情報の特性は、以下のように注記された。時間には、さまざまな変動があり、たとえば、イベントが起こったとき、１つのイベントが別のイベントに対して生じたとき、イベントが生じたのがどのくらいの長さであるかなどである。イベント自体が、特性を有し、次の見方、すなわち、どんなイベントが誘発されたのか、イベントの強さまたは規模はどれくらいかが必要とされる。イベントは、特定の時刻における出来事または特定の行為の対応する規模を有する一連の出来事からなってもよい。一旦、イベントが始まると、イベントを停止させることができるか、さらに一般的な疑問は、削除される特定の事例に関して、前のイベントを修正することができる。イベントの頻度もまた、周知であることが必要である。同期呼び出しまたは非同期呼び出しのいずれかに関連して、イベントがどのように誘発されたかである。本発明は、以下で提供される説明において明らかになるように、これらの問題に対処する。
【００２７】
生理的パラメータの測定は、ＤＴＰＳの根幹を成す。たとえば、体温、血圧、体重などの容易に測定可能なパラメータがある。他のパラメータは、特異成分を特定するために用いられる血液試料試験、検尿、細菌を特定するために行われる培養などの複雑な実験室試験から提供される可能性がある。しかし、任意の生理的パラメータの測定には限界がある。たとえば、複雑で高価な設置は、ＨｂＡ１Ｃまたはインスリンの分析などの試験から提供される情報の利用可能性を制限する可能性がある。運動、食事摂取（すなわち、炭水化物の摂取）およびストレスなどの人間の生理学に影響を及ぼす活動に関する定量的情報および／または定性的情報は、歪曲される可能性がある。さらに、そのようなパラメータは、定量化されるのではなく、有／無として指定される効果として現れる可能性がある。さらに、定量化された情報は、種々の制限要因に関して厳格に達成されなくてもよいことが求められる。また、技術的制限、たとえば、糖新生量または腸のグルコース吸収などの生理的パラメータにアクセスする際の物理的制限または倫理的制限により利用可能でない測定もまた存在する。さらに、生物学的利用率および薬効などの数学的に構成されるパラメータは通常は、母集団に基づいており、ある個人の患者に十分な程度に固有ではない可能性がある。
【００２８】
糖尿病ケアの場合には、グルコース測定計を用いて通常は得られるグルコース測定は、治療管理を行うための一次パラメータである。ＨｂＡ１Ｃ、ケトンおよびＦＦＡなどの糖尿病の管理に関連する複数の二次パラメータがある。しかし、そのような測定は、定期的には必要とされない。さらに、治療の調整および補正に重要である活動に関する情報（食事消費および運動に関する量および実行速度など）がある。各患者に固有の必要性の分析を助けることができる本発明は、測定および分析にそのようなデータを利用し、直接的に測定されることができない生理的パラメータを推定し、患者の根本的な生理学および代謝を表すために用いられるモデルを構築する。本発明はまた、ユーザが慢性疾患の根本的な動的挙動を理解することができるようにするために、連続的に展開されるとき、そのような生理的パラメータの可視化を可能にする。本発明のそのような分析および可視化は、システムの仕組みについてのさらなる洞察をもたらし（糖尿病の人）、医療提供者が、診断、治療決定および予測を行うことを助けることができる。したがって、本発明は、データを分析し、疾患を診断し、治療を決定し、治療に関する予測に達する医療提供者の能力を向上させる。本発明のユーティリティの例示を助けるために、以下の実施例が以下で提供される。
【００２９】
１人の個人における糖尿病に関する試験を行うために、一般に用いられる手順は、個人が少なくとも８時間絶食することが必要である。絶食中のグルコースが測定され、次に、その個人は、高濃度のブドウ糖飲料の摂取を伴い、続いて通常は２時間にわたって複数回のグルコース測定が行われる経口ブドウ糖負荷試験を受ける。収集されたデータに基づき、糖尿病に関する診断が、決定される。頻繁なデータまたは連続データの使用により、疎らな測定の使用に比べて、以下の利点を提供する。パターンおよび傾向を可視化するために、データをプロットすることができることと、測定における変化を予測または予想するために、データを用いることができることと、モデルを構築し、根本的な薬物動態学および薬力学を表すために、データを用いることができることである。一般に、上述のデータは、明確な手順を用いて収集される。本発明の方法は、以下の態様を包含する。各患者に固有のデータは、本発明の診断、治療および予測ツールを支援するために収集される。データ分析は、手順が分析に特有であることと、各手順が疾患の特定の態様（因果関係）の特定または決定を行うために特殊化されることを認識して提案される。提案されたデータ分析は、患者の疾患系がどのような作用しているかを最もよく定量化し、各患者に固有のパラメータを特定することを意図している。次に、患者の疾患系の動的挙動は、母集団に基づく研究が平均効果を表し、各患者に固有の必要性に必ずしも対処しないことを認識し、本発明によって定義される。動的な系の挙動が特定の状況においてどのように明確であるかを理解するために必要とされる原理であるが、人が重要な数学的分析を精神的に行うことを期待することは合理的ではないことを、本発明はまた考慮に入れる。
【００３０】
たとえば、投薬、特に、日常的に用いられる投薬および／または定期的に必要とされる投薬は、運動、ストレス、異なる食べ物および他の投薬などの活動と相互に作用し、そのすべてが投薬の効果に実質的な影響を及ぼす可能性がある。そのような効果を決定する数学的な態様を展開する後の節において以下に記載する本発明の体系的ツールは、医療提供者が、効果を評価して定量化することを助ける。効果はさらに、選択された治療に対応する所与の効果に関する投薬計画に変換されることができる。効果を用いて、効果の影響を予測し、警告および警報の生成を助けることができる。以下の説明は、本発明のシステム（装置）および方法論を説明する。
【００３１】
全般的なシステム
上述の測定および分析を考慮して、ＤＴＰＳは、ＰＣプラットフォームで実行する代表的なクライアント−サーバ環境で動作するハードウェア−ソフトウェアシステムであり、図２によってブロック図で示されている。全般的なシステムは、イントラネットおよび／またはインターネット設置を介して地理的に分布およびアクセス可能であるものとして想定される。１つの例示の実施形態において、システム１０は、サーバコンピュータ１２およびクライアントコンピュータ１４を提供する。サーバコンピュータ１２は、入力デバイス１８、モニタ２０およびメモリ２２（たとえば、ＲＡＭ、ＲＯＭおよびハードドライブ）に動作可能に接続される従来のプロセッサ１６を含む。入力デバイス１８は、従来のキーボード、従来のポイント・アンド・クリック・デバイス、マイクロホンまたは類似物の任意の１つまたは組み合わせであってもよく、モニタ２０は、任意の従来のコンピュータモニタであってもよい。サーバコンピュータ１２のプロセッサ１６もまた、コンピュータ１２の内部またはコンピュータ１２の外部であってもよいデータベース２４に動作可能に接続される。サーバコンピュータ１２のプロセッサ１６はさらに、従来の通信インターフェイス２６に動作可能に接続される。
【００３２】
クライアントコンピュータ１４も同様に、従来のモニタ３６、従来のメモリ３８（たとえば、ＲＡＭ、ＲＯＭおよびハードドライブ）および従来の入力デバイス４０に動作可能に接続される従来のプロセッサ３４を含み、従来の入力デバイス４０は、従来のキーボード、従来のポイント・アンド・クリック・デバイス、マイクロホンまたは類似物の任意の１つまたは組み合わせであってもよい。または、入力はまた、実施形態において１つまたは複数のタッチスクリーンボタンまたはスイッチを含むモニタ３６を介してもよい。クライアントコンピュータ１４はさらに、プロセッサ３４に動作可能に接続される１つまたは複数の従来のスピーカ４２を含んでもよい。クライアントコンピュータ１４のプロセッサ３４はさらに、ワイヤレスまたは有線接続のいずれかによって、１つまたは複数の外部デバイスに動作可能に接続されるように構成されるデバイスインターフェイス４６に動作可能に接続される。
【００３３】
一実施形態において、たとえば、デバイスインターフェイス４６は、外部デバイスへの有線接続のために構成される従来の入力／出力ポートであってもよく、従来の入力／出力ポートを含んでもよい。そのような従来の入力／出力ポートの実施例としては、従来のユニバーサル・シリアル・バス（ＵＳＢ）ポート、従来のＲＳ−２３２ポートまたは類似物が挙げられるがこれらに限定されるわけではない。さらに、デバイスインターフェイス４６は、外部デバイスの類似の送受信機とワイヤレス通信するように構成される従来のワイヤレス送受信機であってもよく、従来のワイヤレス送受信機を含んでもよい。そのような従来のワイヤレス送受信機の実施例としては、赤外線（ＩＲ）送受信機、無線周波数（ＲＦ）送受信機、誘導送受信機、音響送受信機または類似物が挙げられるがこれらに限定されるわけではない。
【００３４】
クライアントコンピュータ１４のプロセッサ３４は、患者データ測定および／または収集デバイスの形態などで、デバイスインターフェイス４６を介して外部デバイス４８への情報の提供または外部デバイス４８からの情報の受信を行う。患者データ測定および／または収集デバイス４８の実施例としては、血液または組織のグルコースセンサまたは他のグルコース測定デバイス、体温感知または測定デバイス、体重測定デバイス、血圧監視デバイス、ＨｂＡ１Ｃ監視デバイス、インスリンまたは１つまたは複数の他の血糖降下剤または血糖上昇剤の投与（例示）のための埋め込み可能または外部に着用可能な薬剤注入ポンプ、患者の食事摂取データ、患者の運動データ、患者の病気データなどを監視するためのハンドヘルド型または他のデータ収集デバイスが挙げられる。
【００３５】
クライアントコンピュータ１４のプロセッサ３４はさらに、従来の通信インターフェイス３２に動作可能に接続される。通信インターフェイス２６および３２は、サーバコンピュータ１２とクライアントコンピュータ１４との間に電子通信を提供する任意の従来の通信インターフェイスであってもよい。示された実施形態において、たとえば、通信インターフェイス２６および３２は、従来の態様におけるワールド・ワイド・ウェブ（ＷＷＷ）インターネットおよび／またはイントラネットを介して、サーバコンピュータ１２とクライアントコンピュータ１４との間に電子通信を提供するように構成される。さらに、通信インターフェイス２６および３２は、サーバコンピュータ１２およびクライアントコンピュータ３２が、電話を介して通信することができるように、電話モデムであってもよく、または電話モデムを含んでもよい。この開示は、サーバコンピュータ１２とクライアントコンピュータ１４との間の電子通信が、または、他の従来の有線またはワイヤレスの通信リンクを介して達成されてもよいことを検討している。いずれの場合でも、システム１０は、各サーバコンピュータ１２が地理的に分散されてもよく、または地理的に分散されなくてもよい複数のネットワーク型サーバコンピュータ１２を含んでもよく、各サーバコンピュータ１２は、地理的に分散されてもよい複数のクライアントコンピュータ１４に作用してもよいことは理解されよう。さらに、本発明のプロセス（すなわち、ソフトウェア部分）は、以下で説明される使用事例のシナリオに応じて、クライアント側またはサーバ側に構成されてもよい。
【００３６】
ソフトウェア部分
図３に関連して、図２のシステム１０によって用いられ、本発明によるソフトウェア５０の１つの例示の実施形態が示されている。ソフトウェア５０は、ユーザ認証の実行、データベースにおけるデータの取得および／または格納、データの背景処理などの補助的な行為の実行、誘発イベントの自動化などのために、クライアントコンピュータ１４とサーバコンピュータ１２との間の適切なインタラクションを可能にするために、従来の態様において構成されていることが理解されよう。示された実施形態において、ソフトウェア５０は、オペレーティングシステムおよびネットワーク手順部分５２、主要アプリケーション部分５４および機能的モジュール部分５６を含む。オペレーティングシステムおよびネットワーク手順部分５２は、種々のコンピュータ、デバイスおよび／またはデータベースの間のインタラクションを可能にするように、従来の態様において構成される。主要アプリケーション部分５４および機能的モジュール部分５６はそれぞれ、サーバコンピュータ１２、クライアントコンピュータ１４または両方のコンピュータの少なくとも一部に常駐してもよい。
【００３７】
一般に、主要アプリケーション部分５４は、複数の従来のソフトウェアアルゴリズムおよび他の従来のデータ管理ソフトウェアを含み、ソフトウェアは市販であってもよい。１つの具体的な実施例として、主要アプリケーション部分５４は、従来の数学ソフトウェアパッケージを含んでもよい。一般に、そのような主要数学ツールは、１つまたは複数の最適化ツール、１つまたは複数の統計分析ツール、１つまたは複数のシミュレーションツール、１つまたは複数の感度ツール、１つまたは複数の可視化ツールおよび情報を抽出するための１つまたは複数のツール（従来のパターン認識ツール、エンベロープ認識ツールなど）を含む。具体的な実施例としては、ＬＡＰＡＣＫ、線形代数パッケージ、ＩＭＳＬ（Independent Media Solutions Limited）ソフトウェアツールおよびライブラリ、ＯＰＴＩＭＡクライアント／サーバツール、ＳＴＡＴＳ統計ツール、グラフィカルプレゼンテーションツールなどの任意の１つまたは複数が挙げられるがこれらに限定されるわけではない。特に収集された患者データ用のデータベース構成およびセキュリティソフトウェアアルゴリズムは、従来のソフトウェアアルゴリズムおよび他の従来のデータ管理ソフトウェアの他の具体的な実施例であり、主要アプリケーション部分５４に含まれてもよい。そのようなデータベース構成およびセキュリティソフトウェアアルゴリズムは一般に、たとえば、ＨＩＰＡＡ準拠、データ完全性、セキュリティおよび認証、他のシステムアプリケーションとの相互運用性を保証する。種々のデータベース活動を支援するための従来のドライバおよび／または種々の電子データ測定／収集デバイス４８（図２参照）との相互作用を行なうためのドライバは、従来のソフトウェアアルゴリズムおよび他の従来のデータ管理ソフトウェアの別の具体的な実施例であり、主要アプリケーション部分５４のほか、種々のコンピュータ、データベースおよび適切なウェブサイトとのインタラクションを可能にするために、１つまたは複数の従来のウェブブラウザに含まれてもよい。そのような従来のウェブブラウザの実施例としては、インターネットエクスプローラ（Internet Explorer）、ネットスケープ（Netscape）、モジラ（Mozilla）、オペラ（Opera）、リンクス（Lynx）などが挙げられるがこれらに限定されるわけではない。主要アプリケーション部分５４は、より多数のソフトウェアアルゴリズムおよび／またはデータ管理ソフトウェアまたはより少数のソフトウェアアルゴリズムおよび／またはデータ管理ソフトウェアを含んでもよいこと、上記の実施例は、例示の目的のためだけに提供されており、なんら制限するものと考えるべきではないことは理解されよう。
【００３８】
機能的モジュール
図３によって示されているように、示された実施形態において、機能的モジュール部分５６は、データ収集手順ブロック７０、患者モデルモジュール７２、モデル検証モジュール７４および分析モジュール７６を含み、いずれも基準／指針設定モジュール７８に接続される。機能的モジュール部分５６はさらに、デバイスドライバ管理モジュールおよび結果検証および表示モジュール８２を含む。例示的に、機能的モジュール部分５６は、データを管理し、データを照会し、データを格納して検索し、主要アプリケーション部分５４に位置する数学パッケージおよびライブラリへの呼び出しルーチンを提供し、データの分析のためのルーチンと、テキストおよびグラフの形でデータを表示するためのグラフィカルルーチンと、を提供し、種々の外部デバイス４８との通信のためのドライバを提供するように動作する。さらに、機能的モジュール部分５６は、より多数の機能またはより少数の機能を実行するように構成されてもよい。
【００３９】
一般に病気および具体的に言えば慢性病に関して、各患者に固有の治療法を作成するために、具体的に言えば患者に関連するデータが、収集される。一般に、収集される各患者に固有のデータのタイプおよび収集される態様は、多くの要因に左右される。要因は、治療法が作成される特定の病気、病気の深刻度、治療解決策のタイプおよび利用可能性、患者の年齢、体重および性別、厳格な食事療法スケジュール、および／または、定期的な運動、１つまたは複数の利用可能な治療スケジュールに従う患者の性癖などの患者の個人的習慣の１つまたは複数が挙げられるがこれらに限定されるわけではない。データ収集手順モジュール７０は、複数の異なるデータ収集手順を含み、各手順は特定の態様で収集される各患者に固有のデータの１つまたは複数の特定のタイプの収集を提供するように設計される。さらに具体的に言えば、データ収集手順モジュール７０に含まれる各データ収集手順は、収集されるデータ、データが収集される態様、すなわち、データ収集が行われる態様、データ収集手順における任意の制限、任意の特殊ツールおよび／またはデバイス、データを収集する際に用いられる電子機器または他の装置、収集データの品質を保証するか、および／または向上させる任意のセーフガードおよび／またはデータ収集手法を指定する。例示的に、種々のデータ収集手順のいずれかに基づいて収集される各患者に固有のデータは、データベース２４（図２）に格納されるが、この収集データの一部またはすべてはまたは、サーバコンピュータ１２および／またはクライアントコンピュータ１４によってアクセス可能な１つまたは複数の他のデータベースおよび／またはメモリにユニットに格納されてもよい。
【００４０】
データ収集手順モジュール７０に格納される各データ収集手順は、従来のデータ適合性および完全性検査が満たされたという条件であれば、特定の目的のために定義され、少なくとも１つの特定の目標を達成するために試験および評価が行われたデータ収集計画を含む。この目的を達成するために、各データ収集手順は、たとえば、収集データにおける不一致に関して確認し、収集された特定のデータに関して定義される要件を確認する数学モジュールの形のデータ適合性手順を含んでもよく、またはデータ適合性手順にアクセスしてもよい。そのような要件の実施例としては、タイムスタンプの一致、データ値の範囲、日付範囲などが挙げられるがこれらに限定されるわけではない。さらに、各データ収集手順は、その性能および／または統計的特性に関して収集データの品質を調査する数学的モジュールの形のデータ品質手順を含んでもよく、またはデータ品質手順にアクセスしてもよい。
【００４１】
基準／指針設定モジュール７８は、データ収集手順モジュール７０において利用可能な種々のデータ収集手順に基づき、各患者に固有のデータの収集を左右する規準を提供する。さらに、基準／指針設定モジュール７８は、種々のデータ収集手順に基づき、各患者に固有のデータを収集するための指針を提供する。そのような指針は、たとえば、種々のデータ収集手順のコンピュータ読出し可能な記述、また、いつ、すなわち、どのような状況下で、１つまたは複数の特定の手順の使用を行なうかまたは行なわないかに関する指針、手順の使用の利点および／または欠点、手順を用いることによって達成可能または達成不可能と考えられる目的、手順または手順の適用可能性の限界などを提供してもよいが、これに限定されるわけではない。
【００４２】
一般に、データ収集手順モジュール７０において、種々のデータ収集手順のいずれかに関して収集されるデータは、種々の従来の手法を用いて種々の方式で収集されてもよい。実施例としては、１つまたは複数の従来の測定デバイスを用いた各患者に固有の１つまたは複数の状態の測定、患者が被るイベントまたは状況などが挙げられるがこれらに限定されるわけではない。各患者に固有のデータの測定は、本願明細書に記載される電子デバイス４８のうちの任意の１つまたは複数のデバイスを用いて、クライアントコンピュータ１４で利用可能であるようにしてもよい。さらに、各患者に固有のデータの測定は、従来の電子測定デバイスおよび／またはシステムまたは非電子測定デバイスおよび／またはシステムを用いて行われてもよく、結果は、手動で入力されてもよく、たとえば、キーボード、ポイント・アンド・クリック・デバイス、マイクロホンまたは他の従来の入力デバイスまたは機構などの入力デバイス４０を用いて、クライアントコンピュータ１４に入力されてもよい。患者が被るイベントまたは状況としては、たとえば、食事および間食の摂取、運動、病気、ストレスなどが挙げられるがこれらに限定されるわけではない。そのような情報は、１つまたは複数の電子デバイス４８を介して、および／または従来の入力デバイスのうちの１つを用いた手動入力を介して、クライアントコンピュータ１４で利用可能であるようにしてもよい。
【００４３】
データ収集手順モジュール７０において利用可能であると考えられるデータ収集手順の実施例としては、時間の関数としての患者の血液または組織のグルコース測定、時間の関数としての患者の体温測定、時間の関数としての（患者の身体の周囲の）周囲温度の測定、時間の関数としての患者の心拍数および／または脈拍数、時間の関数としての患者の血圧、体重、月経、ストレス、病などの１つまたは複数の他の患者の生理的状態パラメータ、時間の関数としての食事または間食、すなわち、炭水化物摂取情報、時間の関数としての患者の身体活動、時間に関するインスリン放出情報、時間の関数としての治療介入情報、時間の関数としての診療所および／または病院への患者の来訪、食事摂取、運動能力などの１つまたは複数のことに関する特定の情報、専用機器および／またはデバイスの使用、情報の交換および／または記録のための紙のコピー、電話呼び出し、インターネット通信などのうちの１つまたは複数のものの使用の収集を提供する１つまたは複数のデータ収集手順が挙げられるがこれらに限定されるわけではない。
【００４４】
図２のシステム１０は、人間を対象とするように例示的に設計されているが、他の動物を対象とするシステム１０の実施形態が、この開示によって検討される。一般に、人間によって示される挙動特性のいくつかは、種を越えて共通であり、他の個別の挙動特性は、性別、年齢、人種などの他の要因に左右される。人間の生理的挙動のモデルは、人間生理学の数学的表現として考案されることができ、例示的に、微分方程式に関して定義されてもよい。そのような患者モデルはさらに、すべての患者に渡って略同一であるように作成されてもよく、挙動の変動性も予想される。そのような事例において、モデルパラメータは、各患者に固有の値を有する。
【００４５】
患者モデルモジュール７２（図３）は、人間生理学の１つまたは複数の態様を数学的にモデル化するように構成される複数のそのような患者モデルを利用可能にして、異なる生理的状態、状況および／またはパラメータへのマッピングを提供する。たとえば、患者モデルモジュール７２は、人間におけるグルコース吸収をモデル化してもよく、１つまたは複数の他のモデルは、インスリン（または他の血糖降下剤または血糖上昇剤）の管理の１つまたは複数の効果をモデル化してもよい。患者モデルモジュール７２は、同一の生理的態様をモデル化するように構成される競合モデルを含んでもよく、それぞれのそのようなモデルは、特定のモデルパラメータの定義、患者に関連するデータの収集および／または具体的データの分析のために、一定の利点または欠点を有する可能性がある。これに関連して、基準／指針設定モジュール７８は、具体的な生理的態様、具体的な患者タイプ（たとえば、年齢、性別、人種など）および／または使用のシナリオに関して、別のモデルに対する１つのモデルの具体的な適用性または非適用性に関連する基準および／または指針、任意の具体的なモデルの使用における制限に関連する基準および／または指針、モデル化作業が作成のプロセスにあるソースへのリンクに関連する基準および／または指針などを含んでもよい。モデルのうちの１つまたは複数はさらに、付随する使用事例情報を含んでもよい。患者モデルモジュール７２を介して利用可能な複数の異なる患者モデルは、特定の生理学的状態、状況またはパラメータへのモデルおよび／またはモデルパラメータのマッピングを可能にする。
【００４６】
患者モデルは、携帯可能なメモリデバイス４４、コンピュータメモリ３８および／またはコンピュータ読み出し可能媒体、たとえば、コンパクトディスク、ディジタルビデオディスクなどから患者モデルモジュール７２に格納されてもよく、および／または患者モデルモジュール７２によって直接的にアクセスされてもよい。患者モデルは、サーバ１２および／またはインターネット３０に接続されるデータベース２４または他のメモリユニットから、パテントモデルモジュール７２によってアクセスされてもよく、および／またはパテントモデルモジュール７２によって間接的に格納されてもよい。たとえば、データベース２４または他のメモリユニットは、文献および／または他の関連技術文書への関連リンクを有するモデルタイプおよび／または構造のデータバンクを含んでもよい。さらに、データベース２４または他のメモリユニットは、たとえば、トレーサ研究などの治験結果のデータバンクおよび／またはそのような治験に関連する情報への関連リンクを含んでもよく、そこから根本的なモデル構造を得られてもよい。いずれの場合も、１つまたは複数の適切な患者モデルは、患者モデルモジュール７２を介して、そのような１つまたは複数のモデルの構造、パラメータおよび／または作成に関連する情報にアクセスすることによって、直接的にまたは間接的にアクセスされてもよい。一般に、次に、患者モデルモジュール７２は、人間生理学の１つまたは複数の特定の態様に特有である１つまたは複数の作成された患者モデルを含んでもよく、および／または１つまたは複数のそのようなモデルが位置し、決定されおよび／または作成された情報を含んでもよい。１つまたは複数の作成された患者モデルは、１つまたは複数の所有権のある患者モデル、すなわち特定の人および／またはエンティティによって作成され、その人および／またはエンティティによって使用が制限された患者モデル、および／または１つまたは複数の市販または他の方法で公的に利用可能な患者モデル、すなわち、１つまたは複数の第三者によって利用可能な患者モデルを含んでもよい。
【００４７】
特定のモデルが、患者モデルモジュール７２を用いて選択されたとき、次にモデルパラメータの値が決定されなければならない。これを達成するために、患者モデルモジュール７２はさらに、そのようなモデルパラメータの決定を提供する１つまたは複数のサブモジュールを含んでもよい。そのような１つまたは複数のパラメータ決定サブモジュールの実施例としては、モデルパラメータを特定するための１つまたは複数のサブモジュール、入力、出力、状態および／またはパラメータ記述を提供するための１つまたは複数のサブモジュール、パラメータ範囲を決定するための１つまたは複数のサブモジュール、モデルパラメータ感度（たとえば、モデルパラメータゲイン値）を決定するための１つまたは複数のサブモジュール、既に作成、導出または定義されたモデルパラメータを提供するための１つまたは複数のサブモジュールなどが挙げられるがこれらに限定されるわけではない。
【００４８】
モデルパラメータを特定するためのサブモジュールのうちの１つまたは複数のサブモジュールは、パラメータ値を暗黙的にまたは明示的に決定するデータ適合手法を利用してもよい。そのようなサブモジュールの一般的な実施例としては、最初の推測を提供し、パラメータ推定のための事前分布を提供するためのベイズ分析、パラメータ推定量を求めるためのコスト関数（事後分布）、統計分析、数値分析、範囲分析のための反復的／非反復的手法、ゲイン値分析、試験シナリオ分析、モデル化を提供するサブモジュール、事前の既知パラメータ記述（入力、出力、状態など）、範囲および感度（たとえば、ゲイン値）を提供するサブモジュールなどが挙げられるがこれらに限定されるわけではない。さらに、モデルパラメータを特定するためのサブモジュールのうちの１つまたは複数のサブモジュールは、モデルパラメータを特定するための手順または枠組みを指定してもよい。１つのそのようなモデルパラメータ特定手順または枠組みの実施例は、なんら制限するものと考えるべきではないが、ｉ）モデルパラメータおよびパラメータのための最初の推測を提供するもの、ii）ベイズ手法が採用される場合には、パラメータ推定のために事前のものを提供するもの、iii）特定のコスト関数を設定するか、選択するか、または用いるもの、iv）特定のコスト関数解法手法または枠組みを選択するか、または用いるもの、ｖ）モデルパラメータ推定量のために反復的または非反復的に求めるものが挙げられる。
【００４９】
パラメータ範囲を決定するためのサブモジュールのうちの１つまたは複数のサブモジュールは、モデルパラメータのうちの１つまたは複数のモデルパラメータのための許容可能な範囲を暗黙的にまたは明示的に決定するため、および／またはモデルパラメータの変動性を決定するために、統計的手法、数値手法、反復的手法または非反復的手法のうちの任意の１つまたは複数を利用してもよい。１つまたは複数のそのようなサブモジュールは、たとえば、モデルが試験されて評価されることができるモデルパラメータ範囲を表す試験シナリオを作成するために従来の手法を用いてもよい。たとえば、一実施形態において、本発明は、コンピュータに試験シナリオを定義して実行するために用いられてもよく、推奨された各患者に固有の治療法を試験して、推奨された各患者に固有の治療法を用いて潜在的に達成可能である治療の品質を定量化する際に役立つ。他の実施形態において、治療法が指定されると、本発明は、シナリオを評価し、たとえば、生活様式における制約、たとえば、食事量の制限、吸収の早い食事の制限などによって、治療を向上させるために用いられてもよい。
【００５０】
モデルパラメータ感度を決定するためのサブモデルのうちの１つまたは複数のサブモデルは、モデルパラメータゲイン値を暗黙的にまたは明示的に決定するために、１つまたは複数の統計的手法、数値手法、反復的手法または非反復的手法を利用してもよい。１つまたは複数のそのようなサブモジュールは、たとえば、モデルパラメータ感度を分析して、１つまたは複数のモデルパラメータ範囲に関して、および／またはモデルパラメータ決定におけるエラーに応じて、モデルの安定性を評価するために、従来の手法を用いてもよい。
【００５１】
糖尿病ケアの場合には、特に、種々の周知の血液および／または組織におけるグルコース測定手法を用いて得られるグルコース測定は、正常血糖の制御が従来の糖尿病治療を介して達成されることが求められる一次パラメータを提供する。この開示は、他のパラメータもまた、糖尿病の管理に関連することと、そのようなパラメータの動的決定または静的決定が、規則的または周期的に必要とされてもよく、または必要とされなくてもよいことを認識する。そのような他のパラメータの実施例としては、ＨｂＡ１Ｃ（グリコシル化ヘモグロビンまたは糖化ヘモグロビン、時間に関する血奬グルコース濃度を特定するために用いられてもよいヘモグロビンの形態）、ＦＦＡ（遊離脂肪酸）、ケトン体（脂肪酸の分解の副生成物）などが挙げられるがこれらに限定されるわけではない。一部のそのようなパラメータは、パラメータ測定を介して監視されてもよく、他のパラメータは、他のパラメータの測定および適切なモデル化、すなわち仮想測定を介して推定する必要がある可能性がある。患者の活動に関連するさらなる情報はさらに、糖尿病治療の修正、調整または補正を行うために用いられてもよい。実施例としては、食事量、消費頻度および／または実行速度、運動の頻度、持続時間および／または負荷、病の頻度、持続時間および／または深刻度などが挙げられるがこれらに限定されるわけではない。ちょうど記載した患者モデルモジュール７２を介して利用可能な患者モデルの少なくとも一部は、その中に１つまたは複数のそのような生理的パラメータおよび／または他の情報を組み込み、そのような１つまたは複数のモデルが、直接的に測定されることができない１つまたは複数の生理的パラメータまたは直接的に測定することが困難である１つまたは複数の生理的パラメータを推定するために用いられ得ることが想定される。結果として生じる患者モデルは、動的にまたは静的に、患者の代謝などの患者の根本的な生理学を監視する能力を提供する。
【００５２】
機能的モジュール部分５６はさらに、患者モデルの１つまたは複数の態様を分析するように構成される１つまたは複数のコンピュータに基づくシミュレーションプログラムへのアクセスを提供するモデル検証モジュール７４を含む。１つまたは複数のシミュレーションプログラムは、たとえば、データベース２４または他のメモリユニットに格納されてもよく、そのような場合において、モデル検証モジュール７４は、そのようなプログラムにアクセスするためのインターフェイスを提供する。さらに、モデル検証モジュール７４は、モデル検証プログラムの文献または他のソースへのリンクを含んでもよい。いずれの場合でも、１つまたは複数のコンピュータに基づくシミュレーションプログラムは一般に、１つまたは複数の特定の試験シナリオの元で、選択された患者モデルの動作を分析し、その結果を周知の標準、データのより広い母集団、前に分析したモデルの結果、統計的に予測された結果などと比較する。１つまたは複数のコンピュータに基づくシミュレーションプログラムはさらに、比較との不一致にフラグを立ててもよく、および／または比較との不一致を報告してもよい。例示的に、モデル検証モジュール７４は、ｉ）選択された患者モデルに関連するコンピュータに基づくシミュレーションを行うこと、ii）１つまたは複数の指定された動作範囲にわたって選択された患者モデルの妥当性を確認すること、iii）動作空間、選択された患者モデルに関する限界およびエラーの原因の把握を容易にする情報を提供すること、iv）選択された患者モデルに具体的な使用事例を適用し、モデルの結果を分析することと、ｖ）前に収集された臨床データを用いて選択された患者モデルの試験を行うことと、のうちの任意の１つまたは複数を行う１つまたは複数のコンピュータに基づくシミュレーションプログラムへのアクセスを提供する。
【００５３】
モデル検証モジュール７４は、選択された患者モデルを評価するための特定の分析ツールを提供する１つまたは複数のサブモジュールを含んでもよい。そのような１つまたは複数の分析ツールサブモジュールの実施例としては、具体的な使用事例のシナリオを試験するための１つまたは複数のサブモジュール、１つまたは複数の指定された動作範囲にわたって患者モデルを試験するための１つまたは複数のサブモジュール、選択された患者モデルを統計的に分析するための１つまたは複数のサブモジュールが挙げられるがこれらに限定されるわけではない。具体的な使用事例のシナリオを試験するための１つまたは複数のサブモジュールは、上述したように、１つまたは複数の特定されたモデル特性を所定の標準と比較する態様において、患者モデルを働かせる１つまたは複数のソフトウェアプログラムへのアクセスを例示的に提供してもよい。１つまたは複数の指定された動作範囲にわたって患者モデルを試験するための１つまたは複数のサブモジュールは、患者モデルが根本的な病または疾患をどのようにシミュレートするか、および／または患者モデルが、変化する動作範囲および／または状況に関して、所定の治療に対する根本的な病または疾患の反応をどのようにシミュレートするかを決定するために、１つまたは複数の指定された動作範囲にわたって患者モデルを分析する１つまたは複数のソフトウェアプログラムへのアクセスを例示的に提供してもよい。選択された患者モデルを統計的に分析するための１つまたは複数のサブモジュールは、いずれの解決策が１つまたは複数の予想される統計的特性を表すかの決定を可能にする態様において、１つまたは複数の解決策のモデルを生成するために、患者モデルを働かせる１つまたは複数のソフトウェアプログラムへのアクセスを例示的に提供してもよい。
【００５４】
基準／指針設定モジュール７８は、サブモジュールの１つまたは複数の動作を左右する規準設定を例示的に提供してもよく、および／または具体的な患者モデル、モデルタイプ、モデル動作範囲および／または使用のシナリオに関して、別のモデルに対する１つのコンピュータに基づくシミュレーションプログラムの具体的な適用性または非適用性に関連する指針、任意の具体的なシミュレーションプログラムの使用における制限に関連する指針、関連するコンピュータに基づくシミュレーションプログラムが見つけられる可能性があるソースへのリンクに関連する指針および／または関連するコンピュータに基づくシミュレーションプログラム作業が作成のプロセスにある可能性があるソースへのリンクに関連する指針を提供してもよい。
【００５５】
ソフトウェア５０（図３）の機能的モジュール部分５６はさらに、１つまたは複数の分析ツールへのアクセスを提供する分析モジュール７６を含み、その少なくとも一部は、データベース２４または他のメモリユニットに、本願明細書において上述したように、主要アプリケーション部分５４を介してアクセス可能である１つまたは複数の従来の数学的ソフトウェアパッケージの形で常駐している。一般的な実施例としては、１つまたは複数の最適化ツール、１つまたは複数の統計分析ツール、１つまたは複数のシミュレーションツール、１つまたは複数の感度ツール、１つまたは複数の可視化ツールおよび情報を抽出するための１つまたは複数のツール（従来のパターン認識ツール、エンベロープ認識ツールなど）が挙げられるがこれらに限定されるわけではない。具体的な実施例としては、ＬＡＰＡＣＫ、線形代数パッケージ、ＩＭＳＬ（Independent Media Solutions Limited）ソフトウェアツールおよびライブラリ、ＯＰＴＩＭＡクライアント／サーバツール、ＳＴＡＴＳ統計ツール、ＧＲＡＰＨＩＣＡＬプレゼンテーションツールなどの任意の１つまたは複数が挙げられるがこれらに限定されるわけではない。
【００５６】
分析モジュール７６はさらに、他のデータ分析および／または可視化ツールを利用可能にしてもよく、その１つまたは複数が、作成されることが求められる治療法に特有であってもよい。任意のそのような他の分析および／または可視化ツールは、データベース２４または他のメモリユニットに格納されてもよく、分析モジュール７６を介して直接的にアクセスされてもよく、またはどこか他の場所で利用可能であり、分析モジュール７６を介してそのようなツールへの関連リンクを介して間接的にアクセスされてもよい。例示的に、分析モジュール７６を介してアクセス可能であってもよい主要な数学的ツールは、ｉ）１つまたは複数の最適化ツール、ii）１つまたは複数の統計分析ツール、iii）１つまたは複数のシミュレーションツール、iv）１つまたは複数の感度ツール、ｖ）１つまたは複数の可視化ツールおよびvi）たとえば、パターン認識などを介して情報を抽出するための１つまたは複数のツールが挙げられるがこれらに限定されるわけではない。一実施形態において、分析モジュール７６は、システムがシミュレーション、統計分析、感度分析、可視化、情報抽出、最適化のうちの少なくとも１つを行い、投与、運動および食事に関して、タイプ、量およびタイミングのうちの少なくとも１つを含む推奨を提供することを可能にする分析ツールを提供する。各推奨は、一実施形態において、現在の時刻、将来の時刻または分析によって決定される時刻またはエンドユーザによって決定される時刻における行為を含んでもよい。
【００５７】
基準／指針設定モジュール７８は、分析モジュール７６を介して利用可能な分析および／または他のツールのうちの１つまたは複数の動作を左右する規準設定を例示的に提供してもよく、および／または具体的なツール、ツールタイプ、任意の具体的なツールの使用における任意の制限に関して、別のツールに対する１つのそのようなツールの具体的な適用性または非適用性に関連する指針、関連する分析、可視化または他のツールが見つけられる可能性があるソースへのリンクに関連する指針および／またはそのような分析、可視化または他のツールにおける関連作業が作成のプロセスにある可能性があるソースへのリンクに関連する指針などを提供してもよい。
【００５８】
分析モジュール７６を介して利用可能なツールを用いて、データ収集手順モジュール７０における手順の１つまたは複数に基づいて収集された各患者に固有のデータは、有用な各患者に固有の生理的情報を抽出するために、１つまたは複数の選択された患者モデルに適用され、患者モデルモジュール７２を介して選択され、モデル検証モジュール７４を介してその妥当性が確認されることができる。有用な各患者に固有の生理的情報は次に、各患者に固有の病または疾患に処置を施すための１つまたは複数の治療を提供するために用いられてもよい。糖尿病治療に関連して、たとえば、分析モジュール７６を介して利用可能なツールとしては、モデルパラメータ値などの情報の抽出を提供するソフトウェアツール、糖尿病に関連するデータの分析を提供するソフトウェアツール、最適化ソフトウェアツール、傾向分析ソフトウェアツール、基礎投与およびボーラス投与の決定および／または推奨を提供するソフトウェアツール、低血糖および高血糖などの状況に関する警告の決定および適用を提供するソフトウェアツール、患者に関連するデータの患者入力を可能にする１つまたは複数のグラフィカルインターフェイスの作成を提供するソフトウェアツールなどが挙げられるがこれらに限定されるわけではない。
【００５９】
実施例では、患者に関連するデータの患者入力を可能にする１つまたは複数のグラフィカルインターフェイスの作成を提供するソフトウェアツールが、ＩＮＦＯＲＭＡＴＩＯＮ  ＩＮＰＵＴ  ＩＮＴＥＲＦＡＣＥ  ＦＯＲ  Ａ  ＴＨＥＲＡＰＹ  ＳＹＳＴＥＭという名称で、代理人整理番号ＲＯＰ００１４ＰＡ／ＷＰ２３６２７ＵＳを有する同時係属中の米国特許出願第＿号に記載され、この特許は、本開示の譲受人に譲渡され、その開示内容は、参照によって本願明細書に援用されるものとする。別の実施例は、ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＤＥＴＥＲＭＩＮＩＮＧ  ＤＲＵＧ  ＡＤＭＩＮＩＳＴＲＡＴＩＯＮ  ＩＮＦＯＲＭＡＴＩＯＮという名称の同時係属中の米国特許出願第１１／２９７，７３３号に記載され、この特許は、本開示の譲受人に譲渡され、その開示内容は、参照によって本願明細書に援用されるものとする。患者に関連するデータの患者入力を可能にする１つまたは複数のグラフィカルインターフェイスの作成を提供する他のソフトウェアツールが、当業者には思い浮かぶであろう。任意のそのような他のソフトウェアツールは、本開示内容によって予想される。
【００６０】
ソフトウェア５０（図２）の機能的モジュール部分５６はさらに、主要アプリケーション部分５４に関して本願明細書において上述したように、１つまたは複数のデバイスドライバへのアクセスを提供するデバイスドライバ管理モジュール８０を含む。また、１つまたは複数の選択された患者モデルに各患者に固有のデータを適用した結果の分析および検証を提供し、そのような結果を視覚的に表示するための１つまたは複数のツールを提供する結果検証および表示モジュール８２も、含まれる。たとえば、モジュール８２は、治療法の堅牢性に関する重態事例の試験、解決策の安定性の評価、パラメータ変動に対する治療法の感度の決定および評価および／または大量のシミュレーションを行うことによる信頼区間の生成および／または治療成果が一定の範囲内にあるという兆候の表示を行うために、選択および実行されてもよい１つまたは複数のシミュレーションツールへのアクセスを提供してもよい。モジュールはさらに、結果の安全で堅牢な使用を確保するための１つまたは複数のフェイルセーフ機構、たとえば、有効性、効能、親和性などの結果の有効性の分析、治療の収束および安定性に関する結果の分析、たとえば、ＨｂＡ１Ｃなどの１つまたは複数のコンピュータに基づくバイオマーカ、１つまたは複数の患者の監視スケジュール、１つまたは複数の治療提案などを提供するために、選択および実行されてもよい１つまたは複数のツールへのアクセスを提供してもよい。モジュール８２はさらに、１つまたは複数の視覚表示ソフトウェアツールまたはたとえば、テキスト報告、チャート、プロットなどの任意の従来のフォーマットにおける結果をグラフィカルに表示するためのパッケージへのアクセスを提供してもよい。図１のシステム１０および図２および図３のソフトウェア５０を用いて本発明によるプロセスを示す特定の実施例が、以下で提供される。
【００６１】
プロセス実行実施例
ここで図４を参照すると、各患者に固有の治療法を作成するためのプロセス１００の例示の一実施形態のフローチャートが、示されている。プロセス１００は、治療に関する最小基準が満たされ、選択肢の選択が治療目的の達成に関連することと、患者の治療を改善するために、特定の問題点が対処されることを確保することを助ける。プロセス１００は、一度にその全体を実行する必要はなく、代わりに、以下でさらに詳細に述べるように複数の入口点のいずれかにアクセスしてもよい。
【００６２】
プロセス１００の第１の入口点は、データ収集手順モジュール７０を介してアクセス可能なデータ収集手順の２つ以上に基づいて、各患者に固有のデータが収集される工程１０２に進む。収集手順は、一実施形態において、ＡＤＡまたは類似の団体などの医療団体を運営することによって指定される収集手順であってもよく、他の実施形態において、医療実行者、医師などの医療従事者によって確立されたものとして指定される収集手順であってもよいことを認識すべきである。工程１０２において、各患者に固有のデータは、図１に関して本願明細書において上述した患者データ測定／収集デバイス４８の任意の１つまたは複数の実施形態を用いて、そのようなデータをクライアントコンピュータ１４に入力することによって収集されてもよい。さらに、各患者に固有のデータは、工程１０２で、従来の態様で各患者に固有のデータの測定または他の方法による決定を行い、次に、モニタ３６が１つまたは複数のタッチスクリーンボタンまたはスイッチを含む実施形態において、入力デバイス４０またはモニタ３６のうちの１つまたは複数を介してそのようなデータをクライアントコンピュータ１４に入力することによって、収集されてもよい。
【００６３】
工程１０２に続いて、プロセス１００は、収集された各患者に固有のデータの完全性および品質に関する検査が行われる工程１０４に進む。一実施形態において、たとえば、データ収集手順モジュール７０は、収集されたデータにおける不一致を検査する数学的モジュール、収集された具体的なデータに関して定義される要件を検査する数学的モジュールの形でデータ適合性手順を含んでもよく、またはデータ適合性手順へのアクセスを有してもよい。そのような要件の実施例としては、タイムスタンプの一致、データ値範囲、日付範囲などが挙げられるがこれらに限定されるわけではない。一実施形態において、データ適合性手順は、最適な成果のために予め評価される。さらに、データ収集手順モジュール７０は、たとえば、その性能および／または統計的特性に関して、収集されたデータの品質を調べる数学的モジュールの形でデータ適合性手順を含んでもよく、またはデータ適合性手順へのアクセスを有してもよい。たとえば、データ品質が不良であるかどうかを決定するために、システムは、収集されたデータの複数の態様を調べる。この実施形態において、一態様は、収集されたデータの関連性であり、照会からなるデータベースモジュールから呼び出される関連性照会が、収集されたデータからのデータ内容を抽出するために利用される。抽出されたデータ内容は、抽出されたデータ内容を受信し、所望の基準に対して、１日当たりの測定頻度、食事時間、ボーラス、食事サイズに対するボーラスの量などについての結果を出力する適切な統計的モジュールを介して、統計的に分析される。別の態様は、収集されたデータのタイミングであり、工程１０４において、データ時系列が、収集されたデータに関する信頼区間を提供するために、どのような患者が収集されたかに対する基準と要件との比較に関して調べられる。示された実施形態において、クライアントコンピュータ１４またはサーバコンピュータ１２は、工程１０４で、データ適合性モジュールおよびデータ品質モジュールのいずれかまたは両方にアクセスして実行することによって、そのような検査を行うように動作可能である。
【００６４】
工程１０４に続いて、任意に、プロセス１００は、工程１０５において収集されたデータにおけるデータ品質の現在の評価および一定のデータの利用可能性に基づき、行為およびデータ利用可能性状態の選択に進行するための推奨をモニタ３６でユーザに対して表示することを含んでもよい。この工程におけるさらなる詳細を与える説明は、後の節において提供される。プロセス１００は次に、各データ収集手順のデータ完全性および／またはデータ品質検査が、合格または不合格のいずれであったか（または、工程１０５における選択された推奨およびデータ利用可能性状況に基づく合格／不合格）をクライアントコンピュータ１４またはサーバコンピュータ１２が決定するように動作可能である工程１０６に進む。１つまたは複数のデータ完全性検査および／または品質検査が不合格であった場合には、アルゴリズム実行は、示された実施形態において、工程１０２に戻るように進み、その結果、１つまたは複数の不合格のデータ収集手順に基づいて、各患者に固有のデータの新たな集合が収集されてもよい。任意に、図４に示されているように、プロセス１００は、工程１０６の「不合格」分岐と工程１０２との間に、さらなる工程１０８を含んでもよい。この実施形態において、クライアントコンピュータ１４またはサーバコンピュータ１２は、工程１０８で、再収集される必要があるデータのみ、すなわち、破損した任意の１つまたは複数のデータ収集手順の中のデータまたはデータ完全性検査および／または品質検査に他の理由で合格しない任意の１つまたは複数のデータ収集手順の中のデータを特定するように動作可能である。その後で、工程１０２で、工程１０８で特定されたデータのみが、再収集される必要がある。別の実施形態において、オプションの工程１１０が、設けられ、特定されたデータがこの時点で再入力される必要があるかどうかをユーザが、尋ねる。答えがはいである場合には、プロセス１００は、工程１０２に戻り、そうでない場合には、プロセス１００は、図４において特定される第２の入口点で収集される利用可能なデータを用いて、さらなる分析へと続く。
【００６５】
プロセス１００への第２の入口点は、工程１０６の「合格」分岐と次の工程１２０との間に存在する。第２の入口点もまた、工程１０２〜１０８の実行からの出口点として機能してもよいことは理解されよう。いずれの場合でも、工程１０６の「合格」分岐および／または入口点２は、患者モデルモジュール７２を介して利用可能な１つまたは複数の各患者に固有のモデルから１つまたは複数の適切な患者モデルが選択される工程１２０に進む。工程１２０で、１つまたは複数の患者モデルは、入力デバイス４０（たとえば、キーボード、ポイント・アンド・クリック・デバイス、マイクロホンまたは他の適切なユーザ入力デバイス）などの適切なユーザインターフェイスを通じて、クライアントコンピュータ１２および／またはサーバコンピュータ１２を用いて選択されてもよい。さらに、工程１２０は、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、フロッピディスク、ＵＳＢ互換可能なメモリデバイスなどの外部メモリ記憶デバイスを介して１つまたは複数の患者モデルにアクセスすることによって、クライアントコンピュータ１２および／またはサーバコンピュータ１２を用いて実行されてもよい。さらに、工程１２０は、データベース２４または他のメモリユニットに格納される適切なリンクにアクセスし、次に、主要アプリケーション５４の一部を形成する従来のウェブブラウザを介して、リンクの対応するウェブサイトまたは他のソースにアクセスすることによって、実行されてもよい。他方、格納されたリンクが、１つまたは複数の出版物への参照に対応する場合には、工程１２０は、手動でまたはクライアントコンピュータ１４および／またはサーバコンピュータ１２を介してのいずれかで１つまたは複数の出版物にアクセスすることによって、実行されてもよい。いずれの場合でも、１つまたは複数の患者モデルが選択されると、工程１２０はさらに、本願明細書において上述した手法の任意の１つまたは複数を用いて、モデルパラメータ値を特定することを含む。一実施形態においておよび図２１を参照して、モデルパラメータ特定を示すための実施例が、提供され、以下で説明される。
【００６６】
パラメータ決定を示すために、たとえば、患者モデル７２（図３）によって、工程１２０における処理の概要を示す簡単な実施例が、記載される。Ｉ型の患者がたとえば、デバイス４８（図２）などのインスリンポンプを用いて、Ｌｙｓｐｒｏなどの即効性のインスリンタイプによって処置が施されている臨床研究を考える。ポンプは、基礎インスリンプロファイルに加えて、手動で命令されるボーラスを注入することができる。臨床研究の場合には、ポンプは、赤外線制御を備え、たとえば、ＡＬＧＯ５１０（図５）（後の節で説明する）などの制御アルゴリズムによって、閉ループ方式で命令され得る。治験は、ポンプを用いて、皮下に一連の少量のボーラスおよび大量のボーラスを投与することからなる。そのようなインパルス応答モデルが選択されると、式（１）によって記載される。
【００６７】
【数１】
0005529307.tif 000002
【００６８】
式（１）のインパルス応答モデルは、３つの主要パラメータからなる。これらのパラメータは、フィルタとして直接的に作用する区画の概数を表すα、単位インスリン分布容積当たりのピーク吸収速度の時間であるβ、ゲイン因子であるＫである。吸収されたインスリンは、身体のインスリン分布容積の中に分散される。インスリンは、筋肉、肝臓などの組織によって利用され、循環血液からも除去される。略全体のプロセスを記述する微分方程式（２）は、
【数２】
0005529307.tif 000003
である。
【００６９】
第１項
【数３】
0005529307.tif 000004
は、清掃率の項であり、インスリン濃度（第１次指数関数的減衰）に線形に比例していると簡単に仮定される。しかし、時間定数τ（分）は、未知である。式（２）の右側の第２項は、インスリン吸収関数を用いた注入されたインスリンボーラスの間の畳み込み演算項である。この項は、任意の一連のインスリンボーラスによって循環する単位容積当たりの吸収される正味のインスリンを提供する。Ｕ／分当たりの投入されるインスリンボーラスｕ（ｔ）＝０．２７８ｕ’（ｔ）であり、式中、ｕ’（ｔ）は、Ｕ／時単位である。問題は次に、各患者に固有のインスリン動態に関するパラメータを決定することである。図２１に示されているように、Ｕ／時当たりに投入されるインスリンボーラスｕ’（ｔ）および排出されるインスリン濃度観測Ｃ観測I［ｋ］Ｕ／ｍＬ（円）が必要とされる。
【００７０】
問題は、たとえば、式（３）によって記載される判断基準を最小限に抑えるパラメータの集合を選択することによって解決される。
【００７１】
【数４】
0005529307.tif 000005
式中、Ｃ観測I［ｉ］のｉ番目は、時間ウィンドウにおける補間されるインスリン濃度であり、ＣI［ｉ］は、対応するｉ番目にシミュレートされた濃度である。使用してもよい他の最小判断基準があり、問題要件に左右される。数値解法の観点からこの段階における問題は、標準的な問題である。問題は、アプリケーションの本体によって示されるように利用可能な多くの最適化ルーチンの１つを用いることによって解決される。この実施例において、ＭＡＴＬＡＢ（登録商標）と呼ばれるソフトウェアパッケージから「ｆｍｉｎｃｏｎ」として呼び出される最適化ルーチンが、用いられ得、主要アプリケーション５４（図３）の１つへの呼び出しなど、主要アプリケーション５４（図３）の１つから提供される。「ｆｍｉｎｃｏｎ」関数は、複数の変数の関数の制約付き最小値を求める。制約付き最小関数は次に、未知のパラメータを求め、以下のパラメータの解、α＝１．２８、β＝３１．１分、τ＝５６．７分およびＫ＝１．９３を結果として生じる。
【００７２】
工程１２０に続いて、プロセス１００は、工程１２０で選択された１つまたは複数の患者モデルにおいて、モデル検証プロセスが行われる工程１２２に進む。示された実施形態において、クライアントコンピュータ１４および／またはサーバコンピュータ１２は、モデル検証モジュール７４から１つまたは複数のモデル検証ソフトウェアパッケージにアクセスすることによって、工程１２２を実行するように動作可能である。検証モジュール７４は、この検証に関して選択された患者モデルで用いられた手順に加えて、工程１２２において提供される全体的なパラメータの解を用いる。
【００７３】
工程１２２に続いて、プロセス１００は、工程１２０で選択された１つまたは複数の患者モデルが、モデル検証工程１２２を合格し、したがって、妥当な患者モデルであるかどうかを決定するように、クライアントコンピュータ１４またはサーバコンピュータ１２が動作可能である工程１２４に進む。合格しない場合には、アルゴリズム実行は、示された実施形態において、工程１２０に戻り、その結果、１つまたは複数の新しい患者モデルが、選択されてもよい。任意に、図４に示されているように、プロセス１００は、工程１２４の「いいえ」分岐と工程１２０との間に、さらなる工程１２６を含んでもよい。この実施形態において、クライアントコンピュータ１４またはサーバコンピュータ１２は、修正を必要とする１つのモデル（または複数のモデル）の部分および／またはモデルパラメータ値のみを特定するように、工程１２６で動作可能である。その後で、工程１２０で、患者モデルの特定された部分のみが、工程１２０で選択される必要があり、および／または特定されたモデルパラメータのみが修正を必要とする。
【００７４】
プロセス１００への第３の入口点は、工程１２４の「はい」分岐と次の工程１４０との間に存在する。第３の入口点はまた、工程１２０〜１２６の実行から出口点として機能してもよいことは理解されよう。いずれの場合でも、工程１２４の「はい」分岐および／または入口点３は、１つまたは複数の患者の治療または治療行為を決定するために、工程１０２〜１０８にしたがって長期間にわたって収集された各患者に固有のデータが、工程１２０〜１２６から生じる１つまたは複数の妥当性が確認された患者モデルに適用される工程１４０に進む。工程１４０は、本願明細書において上述したように、分析モジュール７６を介してアクセス可能な分析ツールのうちの任意の１つまたは複数を用いて、クライアントコンピュータ１４および／またはサーバコンピュータ１２を介して実行されてもよい。１つまたは複数の患者の治療または治療行為としては、たとえば、本願明細書において上述したように、１つまたは複数の薬剤の管理、運動および／または他の治療行為の推奨であってもよく、１つまたは複数の薬剤の管理、運動および／または他の治療行為の推奨が挙げられるがこれらに限定されるわけではない。
【００７５】
工程１４０に続いて、プロセス１００は、検証分析が、工程１４０から生じる１つまたは複数の患者の治療および／または治療行為に対して実行される工程１４２に進む。示された実施形態において、クライアントコンピュータ１４および／またはサーバコンピュータ１２は、本願明細書において上述したように、結果検証および表示モジュール８２から１つまたは複数の結果検証ソフトウェアパッケージにアクセスすることによって、工程１４２を実行するように動作可能である。工程１４２に続いて、プロセス１００は、クライアントコンピュータ１４またはサーバコンピュータ１２が、工程１４０で決定された１つまたは複数の患者の治療および／または治療行為が、治療検証工程１４２を合格し、したがって、妥当な治療および／または治療行為であるかどうかを決定するように動作可能である工程１４４に進む。合格しない場合には、アルゴリズム実行は、示された実施形態において、工程１４０に戻り、その結果、１つまたは複数の新しい患者の治療および／または治療行為が、選択されてもよい。任意に、図４に示されているように、プロセス１００は、工程１４４の「いいえ」分岐と工程１４０との間に、さらなる工程１４６を含んでもよい。この実施形態において、クライアントコンピュータ１４またはサーバコンピュータ１２は、修正を必要とする１つまたは複数の患者の治療および／または治療行為の１つまたは複数の部分を特定するように、工程１４６で動作可能である。その後で、工程１４０で、１つまたは複数の患者の治療および／または治療行為の特定された部分のみが、工程１４０で修正される必要がある。
【００７６】
プロセス１００への第４の入口点は、工程１４４の「はい」分岐と次の工程１６０との間に存在する。第４の入口点はまた、工程１４０〜１４６の実行から出口点として機能してもよいことは理解されよう。いずれの場合でも、工程１４４の「はい」分岐および／または入口点４は、本願明細書において上述したように、１つまたは複数の患者の治療および／または治療行為が、１つまたは複数の表示デバイスおよび／またはフォーマットを介して、システム１００のユーザに表示される工程１６０に進む。工程１６０は、本願明細書において上述したように、結果検証および表示モジュール８２を介してアクセス可能な表示ソフトウェアパッケージのうちの任意の１つまたは複数を用いて、クライアントコンピュータ１４および／またはサーバコンピュータ１２を介して実行されてもよい。
【００７７】
特定の使用事例の実施例−実施例Ａ
以下は、本願明細書に記載される概念の一部の使用事例の実施例である。この実施例の工程は一般に、図４のアルゴリズム１００に従い、従来のウィザード、すなわち、ユーザが行為を達成するために一連の対話を通じて導かれるコンピュータユーザインターフェイスを介して実行される。ウィザードは、図４のフローチャートに示されているように、医療従事者を（ｉ）治療決定の最終目的および／または（ii）中間成果にナビゲートするという目的のために、糖尿病患者の情報収集および分類を混合したものである。以下の実施例は、そのようなウィザードによって実行される工程の枠組みにおいて提示されるが、この実施例の工程はまたは、従来の処方箋または指示の設定を介して実行されてもよいことは理解されよう。
【００７８】
この第１の実施例において、患者の病歴ファイルおよび現在の状態は、以下の通りである。被験者は、医療従事者の最後の診察が４ヶ月前のＩ型糖尿病患者である。被験者は、４０歳男性、体重８０ｋｇ（最後の診察以降、変化なし）、現在、Ｌｉｓｐｒｏなどの即効性のインスリンを使用中である（最後の診察以降、変化なし）。被験者は記録によれば、１日当たり平均３回、ｂＧを測定している（最後の診察以降、変化なし）。前の診察のときの平均食事量の値は、３５ｇ、７０ｇ、８５ｇおよび２５ｇであり、現在の食事量の値は、未知である。被験者の炭水化物対インスリン比は、８ｇｍ／Ｕ（変化なし）であり、インスリン感受性は、４０ｍｇ／ｄＬ／Ｕ（変化なし）である。被験者の身体活動は、標準（変化なし）である。被験者の前の診察時のＨｂＡ１Ｃは、７．５であり、現在は９．５である。この事例を受けて、医療従事者は、代表的なＩ型糖尿病の場合の伝統的なデータ収集手順に従うように指示する。
【００７９】
工程１０２において、ユーザは、ウィザードによって、患者の糖尿病タイプを選択するように促される。選択肢は、Ｉ型またはＩＩ型のいずれかである。この実施例において、選択は、Ｉ型である。次に、ユーザは、診察理由を選択するように促される。利用可能な選択肢は、新しい患者、治験、通常は２〜３ヶ月の診察である定期的な診察、入院後または集中監視終了である。この実施例において、選択は、定期的な診察である。ウィザードは次に、ユーザに補足入力を促し、利用可能であれば、標準的なメッセージ／データ検索手順を通じて以下の行為を行う。患者の身長、体重、性別、年齢の入力、関連実験報告（Ａ１Ｃ、ＬＤＬ、ＨＤＬ、ＢＰ、投薬）の入手、測定計データ、ポンプデータ、ＰＤＡなどの関連デバイスからのデータのダウンロード、たとえば、低血糖イベントの数、高血糖イベントの数、食事のタイミング分布、炭水化物の構成、インスリン分布、身体活動、睡眠スケジュールおよび労働スケジュールなどの患者の挙動（収集されたデータ、生活様式の捕捉から）の捕捉、排除判断基準、生理的状態（病、病なし）の入力、投薬の入力、ＣＳＩＩ、ＭＤＩ、現在の治療および現在の治療基準である。この実施例において、収集されたデータは、以下を反映している。現在のＨｂＡ１Ｃ＝９．５、最後のＨｂＡ１Ｃ＝７．５、（最後の平均量３５ｇ、７０ｇ、８５ｇ、２５ｇ）、現在の食事情報は、入力データの欠如のため、未知である。ｂＧ測定はほとんどなく、ｂＧ平均およびＳＤは、（１５０＋／−７０）であり、夜間絶食のほか、残りのデータ値は未知である。
【００８０】
上述の入力／収集データに基づき、工程１０４において、システムは次に、データ完全性／データ品質を検査する。この実施例において、定期的な診察であるため、医療従事者は、患者の治療の定期的な調整が、治療目的として必要であると既に決定している。したがって、この工程中、種々の態様が調べられる。たとえば、いくつかの選択された治療目的に関して、選択された治療目的の達成に対して有意義な結果を提供するために必要とされるデータ収集の必要条件がある。したがって、この工程において、システムは、データが収集データにおいて利用可能であり、具体的なアルゴリズムパラメータに関して（たとえば、所定の範囲、一定値より上／下／一定値など）目的に適っているかどうかもを確認するために検査する。さらに、工程１０４において、１日当たりの測定頻度、食事時間の範囲、食事のボーラスの範囲、食事サイズに対する平均ボーラスの規模などを決定するために、データ内容が統計的に分析される。収集されたデータにおけるデータ時系列もまた、調べられる。発想は、患者が通常は、食事、身体活動および労働スケジュールを含む活動からなる日常的なパターンに従うことにある。患者によって収集される患者の生活様式、身体活動情報、食事情報、測定シーケンスおよび投与情報により、そのような情報の詳細は、任意の所与の日で変化する。一定の時間期間にわたって分析されると、この変化する情報は、治療の有効性の指標を提供する。一実施形態において、患者によって収集されるそのような情報は、所望の患者の生活様式および収集されるべき少なくとも最小の情報に対して調べられる。
【００８１】
（ａ）分析の次の設定の関連性、（ｂ）結果に関する信頼区間、（ｃ）許容／拒絶の判断基準に基づく閾値に対応するために、データ分析およびデータマッピング後に論理的推理が、推測される。たとえば、一実施形態において、イベント投薬およびｂＧにおけるその影響が考慮される場合には、第１の工程は、データが手順ごとに収集されたかどうかを決定することである。ｂＧデータには、規模のほか、測定の時刻の両方における変動性があることを予想すべきである。一実施形態において、測定の数、測定のシーケンスおよび測定における変動性は、データの許容を決定するために、経験的基準に対して検査される。別の実施形態において、所望の目的の達成時に一定の分析を行うために、収集されたデータのいずれが、許容判断基準に基づく閾値未満であるかを決定するために、一連の経験的基準が、適用される。たとえば、上記の所与の病歴実施例の場合には、利用可能なデータおよび制御の予想品質から、経験的基準の１つの出力は、食後のグルコース制御のために必要なｂＧ測定が、患者の治療を調整する目的に大いに関連していることと、その目的を達成するための有用な推奨を提供するために、最小ｂＧ測定の収集が、必要とされることを示す。この実施例において、ｂＧ測定の収集が、最小値未満である場合には、次に、工程１０６において、データ収集品質は、不合格である。
【００８２】
工程１０４において検査を行った後、患者に関する一連の治療評価／推奨が、任意に、工程１０５において提供される。収集されたデータ品質に基づくそのような治療評価／推奨の効果選択に基づいている各治療評価／推奨の次に、関連度等級が、提供され、患者の治療に対する変更を生じる。所与の実施例において、そのような治療評価／推奨およびそれらの関連する関連性としては、（ａ）患者の治療の収集が、不良である（関連度９５％）、（ｂ）患者が定期的な治療の調整を必要とする（関連度５０％）および（ｃ）患者の生活様式の変化（関連度１５％）が挙げられうる。推奨（ａ）の場合には、経験的基準の出力は、収集されたデータからＡ１Ｃが不良であり、患者が具合が悪いと感じ、読み出しが大きなグルコース値、多くの高血糖インシデント（incident）および低血糖インシデントを示し、患者の治療を効果的に調整するほどｂＧ測定が十分ではないという結論を導く。したがって、高い関連度等級は、新たに収集されたデータが制限され、古いデータが約４〜５月前であるという考慮に基づいている。推奨（ｂ）の場合には、患者の治療を調整するために上述したように、Ａ１Ｃは、十分な回数の食前のグルコース測定および食後の測定によって、計量される必要がある。方法はまた、高血糖インシデントおよび低血糖インシデントおよびＡ１Ｃ値を計量する。しかし、収集されたデータにおいて不十分なｂＧ測定が提示され、Ａ１Ｃが不十分であるため、この推奨に関する関連性は低く、したがって、収集されたデータの範囲に鑑みて、恐らく最適な選択ではない。患者がより多くのｂＧ測定を提供することができる場合には、この推奨の関連性が増大するであろう。推奨（ｃ）の場合には、主に履歴データを比較することによって、平均値を比較することによって、およびまたは移動ウィンドウを用いて、平均値を比較することによって、およびまたはデータにおける傾向を決定することによって、患者の生活様式における変更（たとえば、投薬、新たな時間領域への移動／移行、身体活動の変化、ストレスレベルの変更または食事摂取の変更）を見ると、不良なデータ収集により、この時点で、患者の治療に対する調整を行う際に、医療従事者に提供する価値は、あったとしてもほとんどないであろう。
【００８３】
治療評価／推奨の全体的なホストは、収集された種々のデータに基づいて提供されることが可能であることを認識すべきである。たとえば、そのような治療評価／推奨は、患者が新たに診断されたＩ型糖尿病患者であり、治療を必要とすること、またはＩ型患者が閉ループ治験のために募集されていることを含んでもよい。所与の実施例において、患者が新たなＩ型でなく、閉ループ治験のために募集されているわけではないため、そのような推奨は、０％の関連度を有する。生成されたこれらの治療評価／推奨は次に、医療従事者による選択のために、工程１０５における出力として提示される。提供された実施例において、医療従事者は、患者の治療収集が不良である治療評価／推奨（ａ）を選択する。治療評価／推奨（ｂ）および（ｃ）は、医療従事者にとってある程度有用である可能性があるが、関連性等級は、全般的なデータが収集されたデータに欠けており、新しい治療を生成するほど十分ではないことは明白である。
【００８４】
次に、列挙された評価／推奨の１つを選択した後、データ利用可能性状態が次に、これも工程１０５における選択のために、医療従事者に提供される。この工程において、システムはまた、選択された評価／推奨に関して決定し（この実施例では、これは治療評価／推奨（ａ））、選択された治療評価／推奨に対する対応／決定／改善に関連性を取れば、さらなるタイプの行為がある。この実施例において、以下のデータ利用可能性状態は、選択のために提供される。（ｉ）食後のグルコース制御を改善するためのデータの収集（関連度８０％）、（ii）絶食中の目標グルコースを改善するためのデータの収集（関連度７５％）、（iii）全体的な初期治療パラメータを獲得するためのデータの収集（関連度７０％）、（iv）時間領域変さらによるなどの治療タイミングの変更（関連度２５％）、（ｖ）増大した身体活動を別の状態に調整するための治療の変更（関連度１５％）、（vi）別の生理的状態に調整するための治療の変更（関連度５％）および（vii）閉ループアルゴリズム用のパラメータの特定（関連度０％）である。この実施例において、食後のグルコース制御を最適に改善するために、およびより多くのそのようなデータが収集される必要があり、そのようなデータがその目的の達成に最も関連性があることから、治療の変さらに有用であるために、収集されたデータおよび選択された評価／推奨からさらなる経験的基準を決定する。しかし、この実施例において、医療従事者は、オプション（iii）標準的な解決策から始めることがよりよいと決定する全体的な初期治療パラメータを獲得するためにデータを収集することを考慮して選択する。
【００８５】
したがって、種々の選択から、収集されたデータは、工程１０６において、不適合性かつ不合格である。たとえば、この特定の実施形態において、患者の治療を調整するためにＨｂＡ１ｃが、食前のグルコース測定および食後の測定によって計量される必要がある。しかし、アルゴリズムに関して収集されたデータにおいてグルコース測定が効果的に用いられることがほとんどないために、必要なデータのこの欠如は、工程１０６において、データ品質不合格という結果を生じる。ウィザードは次に、経験的基準の別の設定を介してシステムが、推奨される治療プランまたは処方として患者の治療を調整するために必要な初期治療パラメータに関する十分なデータを提供するために、再収集されることが必要なデータを特定する工程１０８を実行する。処方は、以下、すなわち、（ａ）ｂＧ測定の回数、（ｂ）炭水化物集計、（ｃ）測定のタイミング、（ｄ）デバイスにおける通知、（ｅ）トレーニング推奨、（ｆ）適合性満足判断基準、（ｇ）次の診察時間、手順が日付または持続時間を指示することができる、（ｈ）次の診察における潜在的な入口点のうちの１つまたは複数に対応してもよい。所与の実施例において、工程１０８において提供される処方出力は、１日当たり３＋ｂＧ食前測定が適合性を満たすために必要とされる。すべての摂取された炭水化物の集計は、記録されるものとする。医師の主張ごとのデバイスの通知、推奨される炭水化物集計は、ガイド（またはトレーニング／再教育クラス）を助け、次の診察が、現在の視察日から３週間であり、入口点１は、患者が次の診察に来るときであるものとする。
【００８６】
工程１０８の後で、ウィザードは任意に、特定されたデータが、工程１１０において再入力されるべきかどうかを確認するために検査する。そうであるならば、ウィザードは、特定されたデータに関して工程１０２を繰り返す。そうでない場合には、ウィザードは、この時点で入口点２におけるアルゴリズム１００を続行する。医療従事者に関する論点は、患者が決定されなかった良好な治療パラメータを有するかどうかである。前の収集工程は、必要なデータの欠如を示し、工程１２０において性能を改善するために、患者に必要なデータ収集要件を提示したが、この示された実施例において、ユーザには、オプション（ａ）同一のパラメータを用いて続行する、（ｂ）履歴データを用いる、または（ｃ）現在の治療パラメータを調べるために、データを再初期化する、が提示される。ソフトウェアの設定中に使用するために、この実施例において生じた任意の工程１０５および１１０を（共にまたは個別に）選択することができることを認識すべきである。
【００８７】
工程１２０において、関連度アルゴリズムが、患者が良好な治療パラメータを有するかどうかについての質問を解決するために有用である各オプションの関連性を提供する。この実施例において、前の工程が、データ品質が不良であることと、履歴データを用いるというオプション（オプション（ｂ））およびデータを再初期化するというオプション（オプション（ｃ））がそれぞれ、６０％および８０％であることを示しているために、同一のパラメータを用いるというオプション（オプション（ａ））は、０％である。各オプションの関連性を提供するために、工程１２０における関連度アルゴリズムは、一実施形態において、以下の情報、すなわち、患者データが治療パラメータを再実行するのには不十分であること、患者の履歴データが利用可能であること、治療初期化モデルが利用可能であることを考慮している。関連度アルゴリズムは、治療パラメータを決定するために、患者の血糖管理制御を検量し、患者がシステムによって最初に分析されたときの治療パラメータの初期推定量によってどのように処置されたかを検量する。しかし、システムは時折、現在の患者に関して過度に保守的または積極的である可能性があるため、システムは、医療従事者が、各工程における自身の判断を用いることを可能にする。この実施例において、医療従事者は、オプション（ｃ）工程１２０における「データの再初期化」を選択し、工程１２２および１２４において妥当であるモデルの分析および目安を結果として生じる。これらの工程は、母集団に基づくパラメータが医療従事者によって選択され、これがデフォルトで医療従事者が情報の現在の状態を考慮することに同意している平均母集団挙動を表すことを簡単に意味する。
【００８８】
工程１２４の後で、ウィザードは、入口点３におけるアルゴリズム１００と続く。工程１４０において、プロセス１００は、この実施形態において、患者の治療法を決定するために、収集されたデータを母集団に基づくパラメータに適用し、表１に示されている。
【００８９】
【表１】
0005529307.tif 000006
【００９０】
工程１４２において、ウィザードは今度は、決定された患者の治療に検証分析を行い、どの決定された患者の治療を再検討し、治療の安全性指針を提供すべきかによって、最も関連性のあるオプションを医療従事者に提供する。医療従事者には、所与の実施例において、慢性疾患の患者の管理における生活様式の影響を評価するためのオプションが提供される。さらに、治療の安全性指針に関して、収集されたデータおよび生活様式の結果に基づき、医療従事者は、工程１４２において、患者がｘ回の低血糖発作およびｙ回の高血糖発作に関する可能性を有し、それにより、高血糖発作は、さらなる事後測定および中和インスリンによってもたらされる可能性があることを通知される。システムはまた、工程１４２において、選択されたモデルから生成されたパラメータに基づく治療を推奨する。この実施例において、推奨された治療は、所望のＵ／時に基礎速度を設定し、炭水化物対インスリン比に所望のｇｍ／Ｕを設定し、インスリン感受性を所望のｍｇ／ｄｌに設定し、ｂＧ測定の必要な回数を指示し、摂取された全食事の炭水化物集計を要求し、少なくともｘ回の毎日の食前の測定および少なくともｙ回の食後の測定が、治療パラメータ推定量を改善するために必要とされることを示すことを提供する。さらに、ユーザは、患者が、次のｙ週間で治療に関するデータ収集を終了し、その後で医療従事者の診断を受けるべきであることをアドバイスする。工程１４４において、医療従事者は、推奨された治療が妥当であるかどうかをシステムによって尋ねられる。医療従事者が推奨された治療の上記の態様のいずれかを変更したい場合には、工程１４４において「いいえ」を示し、結果として工程１４６において、医療従事者は治療の部分を修正することができる。工程１４６において、所望の変更後、工程１４０〜１４４が次に繰り返される。そうでない場合には、プロセス１００は、入口点４でもある工程１６０において処方としてそれを出力することによって、推奨治療を最終決定する。この実施例の場合には、患者が再び医療従事者の診察をうけるとき、ウィザードが再び入口点１を利用し、図４のアルゴリズム１００を通じてユーザをナビゲートすることを認識すべきである。
【００９１】
特定の使用事例の実施例−実施例Ｂ
第２の使用事例の実施例において、被験者の病歴は、以下の通りである。被験者は、上記の実施例Ａと同様のＩ型糖尿病患者であり、医療従事者の最後の診察が２４日前であった。被験者は、４０歳男性、体重８０ｋｇ（最後の診察以降、変化なし）、現在、Ｌｉｓｐｒｏなどの即効性のインスリンを使用中である（最後の診察以降、変化なし）。被験者は、１日当たり平均６回、血糖（ｂＧ）を測定している（最後の診察のときは１日当たり３回）。前の診察のときの平均食事量の値は、２５ｇ、８５ｇ、８５ｇおよび２５ｇであり、現在の食事量の値は、未知である。被験者の炭水化物対インスリン比は、８ｇｍ／Ｕ（変化なし）であり、インスリン感受性は、４０ｍｇ／ｄＬ／Ｕ（変化なし）である。被験者の身体活動は、標準（変化なし）である。被験者の前の診察時のＨｂＡ１Ｃは、９．５であり、現在は９．５である。この事例を受けて、医療従事者は、代表的なＩ型糖尿病の場合の集中監視型データ収集手順に従うように指示する。
【００９２】
この実施例において、工程１０２の終了後、以下のデータが収集される。患者はＩ型であり、診察理由は、集中監視終了であり、現在のＡ１Ｃ＝９．５であり、最後のＡ１Ｃ＝９．５であり、現在の食事情報（平均３５ｇ±５、７０ｇ±１５、８５ｇ±２０、２５ｇ±１５）であり、最後の食事情報は、データ欠場のため、未知であり、ｂＧ平均およびＳＤは、１３５±５０であり、夜間絶食は、１３０±３０ｍｇ／ｄＬであり、データは、必要な手順に対して処理され、統計的に、収集されたデータは、手順の範囲内で行われた。工程１０４において収集されたデータの完全性および品質の検査を行った後、工程１０５において、提供された（たとえば、表示された）一連の推奨は、それらの関連性等級と共に、以下の通りであった。（ａ）患者が定期的な治療の調整を必要とする（関連度９０％）、（ｂ）患者の治療が不良であり、たとえば、Ａ１Ｃが不良であり、患者が具合が悪いと感じ、読み出しが大きなグルコース値、多くの高血糖インシデントを示す（関連度９５％）、（ｃ）患者が新たに診断されたＩ型糖尿病患者であり、治療を必要とする（関連度０％）、（ｄ）Ｉ型患者が、閉ループ治験のために募集されている（関連度０％）、（ｆ）患者の生活様式が変化する、たとえば、新たな時間領域への移動、身体活動の増大など（関連度６５％）である。
【００９３】
上記で表示した推奨から、医療従事者は、推奨（ａ）および（ｂ）が、最も関連性があり、その中で、推奨（ｂ）「患者の治療が不良である」ことは、最も高い関連度を有することが分かる。この実施例において、医療従事者は、工程１０５において推奨（ｂ）を選択する。次に、データ利用可能性状態および関連する関連性における以下の選択可能なオプションが、工程１０５において医療従事者に提供される（たとえば、表示される）。（ｉ）食後のグルコース制御を改善するためのデータの収集（関連度１５％）、（ii）絶食中の目標グルコースを改善するためのデータの収集（関連度１０％）、（iii）全体的な初期治療パラメータを獲得するためのデータの収集（関連度１０％）、（iv）患者パラメータの再決定および治療パラメータの決定（関連度９５％）、（ｖ）時間領域変さらによるなどの治療タイミングの変更（関連度２５％）、（vi）増大した身体活動を調整するための治療の変更（関連度０％）、（vii）別の生理的状態に調整するための治療の変更（関連度０％）および（viii）閉ループアルゴリズム用のパラメータの特定（関連度０％）である。この工程で、医療従事者は、関連行動方針として、オプション（iv）患者パラメータの再決定および治療パラメータの決定を選択する。過去の診察の初期化は、血糖管理制御が不良であることを示していることは明白である。患者が、炭水化物の測定および集計の測定を熱心に行っているとしても、食前が、不良な食事制御および／または絶食制御を示している。母集団に基づくパラメータが提供された前の診察とは対照的に、各患者に固有の調整が必要とされる。したがって、基準に関するデータ収集が、準拠され、工程１０６において合格するため、プロセス１００が、モデル選択のための入口点２に続く。
【００９４】
工程１２０において、プロセス１００は、収集されたデータが利用可能であり、十分であり、履歴データもまた利用可能であるという決定と、経験的初期化モデルもまた利用可能であるという決定を提供する。したがって、医療従事者には、工程１２０において、これに関連して、以下のオプションおよびそれらの関連する関連性が提供される。（ａ）患者パラメータを特定する（関連度９５％）、（ｂ）履歴データを用いる（関連度５０％）および（ｃ）データを再初期化する（関連度５０％）である。この実施例において、医療従事者は、オプション（ａ）患者パラメータを特定することを選択する。医療従事者は、パターンおよび傾向が分析されて提示される履歴データを用いる手法を選択することが可能である。しかし、この実施例において、利用可能な詳細なデータを用いて、医療従事者は、各患者に固有の生理学特性を調べる詳細な工程を選ぶ。次に、工程１２０において、以下の特定されたモデルパラメータが、医療従事者によって選択可能なオプションとして、それらの評価された関連性と共に表示される。（ａ）食事関連モデル  ＋ＣＳＩＩ＋ｂＧ測定計（関連性９９％）、食事関連モデル＋ＭＤＩ＋ｂＧ測定計（関連性０％）および食事関連モデル＋ＣＳＩＩ＋連続（関連性０％）である。工程１４０において、医療従事者は、第１のオプション（ａ）ウィザードにおける食事＋ＭＤＩ＋ｂＧ測定計を選択する。ここで、関連度は、治療全体が必要とすることを示している。食事は、患者にとって主要な外因性の外乱である。運動または他のストレス因子は、この時点で二次的なものとして検量され、治療パラメータの将来の調整に関連するようになる可能性がある。
【００９５】
最後に、工程１２０において、ウィザードは、食事モデルのタイプ、すなわち、（ａ）速い（主に炭水化物）、（ｂ）中程度（公称）、（ｃ）遅い（高脂肪成分）および（ｄ）混合（したがって、収集されたデータは、そのような情報を有する）の選択を提示する。医療従事者は、第２の食事モデルオプション（ｂ）中程度または公称の食事モデルを選択する。ここで、データは、オプション（ｄ）の混合事例および患者のデータが基準の公称のモデルを示している事例を行うほど十分に豊富ではなく、十分に記録されていない。特定の食事習慣が、より詳細な情報と共に捕捉される可能性がある。食事モデル部分は、より詳細なプロセスであってもよく、またはより詳細なプロセスを含んでもよく、いずれの場合でも、医療従事者が代替の生理的モデルを選択または定義することを可能にすることによって、標準または一般化されてもよい根本的な数学モデルの選択につながる。上記の実施例は、工程１２０において、モデル選択に対応する唯一の方法を示している。
【００９６】
モデル選択後、工程１２２において、プロセス１００は、モデルの検証および分析を行う。この工程に関して、各患者に固有の使用事例シナリオは、コンピュータに基づくシミュレーションを介してシステム１０におけるコンピュータ内でシミュレートされる。選択された患者モデルの理解も同然で、数学モデルが決定されるたびに、その忠実度を調べるために試験される必要がある。工程１２２は、個別の被験者に対して構成された特殊な試験事例を試験し、結果として生じるデータが次に、周知の標準またはデータのより広い母集団のいずれかと比較されるために、システム１０に組み込まれる検査およびバランスがあることを保証する。工程１２２は、特定の選択された患者モデルに左右されるものとして以下のうちの少なくとも１つを伴う。すなわち、動作空間を理解するため、およびモデルの限界を理解するために特定の動作範囲にわたって、コンピュータ内でモデルの妥当性を確認すること、モデルの所与の仮定の根底にあるエラーの合理的な考えを提供すること、試験食、試験インスリン投与などの他の試験モジュールを適用すること、インスリン入力情報およびイベント入力情報などの収集された臨床データによってモデルを試験すること、特定のプロファイル、パラメータ値範囲または評価指標などの特定のモデル特性を適用することである。任意の異常な態様または普通でない態様にはフラグを立て、行動に関して医療従事者に提示される。
【００９７】
所与の実施例において、適合度品質＝８５％を有する患者モデル適合が、行われる。すなわち、モデルおよびパラメータの集合が、観測された特性（ｂＧおよび食事量の測定）の計量結果であるモデル特性の８５％を説明する。他の実施形態において、パラメータに関する信頼区間が、利用可能であってもよい。また、この実施例において、偽りの患者モデル応答が、モデルの生理的特性を検証する（検証）ために行われる。これはまた、患者モデル特徴付けとも呼ばれ、得られた特性を調べるために所定の信号に対するモデルの標準的な試験を含み、観測された患者特性の１つまたは複数の予想範囲に対して比較される。この時点における１つの目的は、許容可能な患者特性の指定された限度以内にとどまることである。結果（予測の品質）を再現するモデルの性能もまた、他の実施形態において実現されてもよい。これは、任意の特徴であり、再現データ集合が利用可能であるときに行われてもよい。この性能の測定は、たとえば、正規化された最小二乗適合であってもよい。
【００９８】
工程１２２において、選択されたモデルにおける分析の終了後、工程１２４において、モデルが妥当であるかどうかに関する決定が、実行される。工程１２４において、医療従事者は、以下、すなわち、パラメータにおける信頼区間、データを適合させる能力、信頼区間を有するパラメータに基づく生理学の推定量の提供などのうちの少なくとも１つを含む結果に基づいて、モデルの許容度を再検討して考える。信頼区間は、パラメータのそれぞれに関して計算されてもよい。これらの信頼区間は基本的には、これらのパラメータが計算された信頼度を決定する。モデルが具体的な手順に関して選択されたときには、過度に広い信頼区間は想定されない。しかし、信頼区間が過度に広いことが起こった場合には、この具体的な患者およびこの具体的な食事に関して、この方法を用いて改善の可能性はないと結論付けられ得る。また、適合度が、予測と測定値との間の平方差のような伝統的な判断基準を用いて検査されてもよい。適合度が不良である場合には、計算されるパラメータは、食事制御を改善するために用いられるべきではない。モデルが良好な検証ジョブを行わない場合には、この工程を再実行することができる。さらに、より良好な結果を提供する１つまたは複数の代替モデルがあるかどうかを決定するために、１つまたは複数の別のモデルとの比較を望んでもよい。工程１２２において、選択されたモデルで行われた検証分析の結果（すなわち、患者パラメータの特定）として、医療従事者は、工程１２４において、モデルが妥当であることを決定する。ウィザードは、この時点で入口点３におけるアルゴリズム１００と続く。
【００９９】
医療従事者がモデルを承認した後、ウィザードは次に、治療の分析／決定の最終段階に医療従事者を進める。工程１４０において、プロセスは、スケジュールおよび不合格／合格の監視を考慮することによって、治療の堅牢性および解決策の安全性の評価のために、重態事例に挑むために、コンピュータ内でシミュレーションを行い、パラメータの変動に対する治療の感度を決定し、大量のシミュレーションを行うことによって、信頼区間を生成し、種々の治療の有効性（有効性、効能、親和性）を決定し、推奨された治療提案（治療の安全性および許容差を含む）を決定する。
【０１００】
たとえば、工程１４０において、プロセス１００は、所与の実施例において、患者の生活様式データを抽出／特定し、そのようなデータに基づき、治療結果に信頼区間を提供する。患者の生活様式は、ここでは、治療の試験および評価に関連している。収集された情報および特定されたモデルは今度は、治療の成果を再検討するために、ウィザードを介して医療関係者に生活様式のオプションを提示する。ここで、１つの目的は、治療の安全性の指針を提供することである。医療提供者は、工程１４０において、以下の治療計算のオプションを提供してもよい。（ａ）特定のアルゴリズムＡに関する治療パラメータ（たとえば、ＣＳＩＩ）および特定の生活様式の決定、（ｂ）特定のアルゴリズムＢに関する治療パラメータ（たとえば、ＩＣＴ）および観測された生活様式の決定、（ｃ）好成績の治療の示唆（ＣＳＩＩ＋頻度測定＋生活様式）、（ｄ）不良の適合性５０％対９０％の適合性に関する生活様式の影響の評価（９５％）である。工程１４０において、患者が、以前の診察で適合性を有していないため、医療従事者は、第１のオプション（ａ）を選択する。任意に、医療従事者によって行われてもよいさらなる運動もまた、第４のオプション（ｄ）を選択することである。
【０１０１】
ここで、観測された生活様式を用いるが、非適合のシナリオを実行すること（すなわち、患者は治療基準を観測していないか、および／または測定および炭水化物集計に適合していない）により、確率的シミュレーションが、工程１４２において、実行され、比較報告が、潜在的な成果から生成される。そのような報告としては、患者にはｘ回の低血糖発作および／またはｙ回の高血糖発作の可能性があること、次の診察（たとえば、今から３ヶ月後）に予測されるＨｂＡ１Ｃ、高いｂＧ測定および低いｂＧ測定、誤った糖尿病処置による失われた潜在的な時間および病気の日数が挙げられる。さらに、治療に関する推奨は、患者測定の生活様式が、少なくともｘ回の測定である必要があること、高血糖発作が、さらなる事後測定および中和インスリンによって減少されることができること、患者が、食前測定および食後測定を行い続ける必要があること、患者が可変の食習慣を有するときには、さらなる治療を改善することができるように、特別な食事タイプに関するデータを収集して記録すべきであることなどであってもよい。さらに、このシミュレーションの目的のための適合性は、適合性比に関して、与えられてもよく、適合性比は、イベントが記録される回数で除算したイベントが実際に記録される回数に等しい。
【０１０２】
たとえば、患者は、１０３回の食前の朝食測定を記録し、測定が行われた時間期間は１２０日である。したがって、朝食に関する適合性比は、１０３／１２０すなわち０．８６である。次に、実施例として、必要な朝食空腹時適合性は、０．８またはそれより良好で、この場合には満たされている。医療従事者は、工程１４４において、この記録および治療を再検討し、変化がない場合には、妥当だと分かる。ここで、入口点４におけるプロセス１００は、処方として１６０において、報告および治療推奨を出力し、患者の記録を電子的に更新する。本発明による特定のシステム実行およびその使用は、図２〜図９を参照して以下で提供される。イベントに対する本発明応答のシステムおよびプロセスが、どのようなものかは、以下で説明される。
【０１０３】
イベントを介したソフトウェア応答の呼び出し
上記で前述したように、イベントは、システムの別の構成要素によって用いられ得る１つの構成要素によって生成される情報の単位である。イベント単位に固有のものは、イベントの時間、イベント特徴記述子、イベント行為計画およびイベント値である。さらなる詳細については、後述する。システムにおけるイベントの起動は、イベントを構成する要素に関する値の指定に関係がある。イベントは一実施形態において、（ｉ）情報項目、（ii）活動情報、（iii）何かを行うためのデバイスへの命令、（iv）患者への行為の通知、（ｖ）潜在的な生理的状態の患者への通知などであってもよい。イベントの構造は、一実施形態において、以下のフィールド、すなわち、絶対イベント時間、イベントのタイプ、イベントの持続時間／行為時間／活動時間、親に対するイベントの開始時間、イベントの量（強度）および注意書の文字列である。絶対イベント時間は、イベントが生じる時間を提供し、以下の値、すなわち、アルゴリズムによって決定されるか、または非同期的に誘発される所定の値を有する。イベントの時間は、絶対参照として一般に作用する絶対時間として提供される。特殊な場合には、絶対イベント時間は、別のイベントの絶対時間にリンクされる。絶対ＵＴＣ時間は、イベントが関連付けられる「参照時間」として用いられる。参照時間は、他のイベントと相関する際に不可欠である。一意の時間決定は、複数の時間領域および昼間の節約を考慮すると、些細なことではない。現地時間および協定世界時（ＵＴＣ）との間の区別が、関連している。現地時間は、表示目的のために用いられ、ＵＴＣは、現時時間にマッピングされる。
【０１０４】
イベントのタイプは、どんなイベントが引き起こされ、食事、運動、投薬、インスリン測定、代替状態、中和イベントおよびイベントの中止などの値を有する。持続時間は、インスリンボーラス活動、食事活動、運動活動持続時間および代替状態などの活動の効果の長さを定義する。開始された任意の活動は、持続時間によって境界が示される必要がある。デフォルトで、活動は、無限の持続時間を有する。他のデフォルトの可能性は、活動の持続時間がないことである。これは、その影響が瞬間的であることを意味する。０〜無限までの非ゼロの値は、介在する事例のすべてを捕捉する。相対時間は、イベントが相対時間に対して調整される絶対時間で開始される絶対参照時間に対する。これは、絶対イベント時間＋相対時間に等しい時間に作動される食事関連のボーラスの場合には、食事イベントに対する測定または最後のｂＧ測定に対する測定であってもよい。量は、イベントの強度または規模を記述し、インスリンの量、食事のサイズおよび食事の速度に関するものであってもよい。最後に、注意書の文字列は、簡単であるが、情報の説明部分である。一実施形態において、このフィールドは、ＸＭＬまたはＲＴＦまたは他のマークアップ言語で出力され、特に、エンドユーザおよびデータベース記録用に調整されたさらなる詳細および記述的な情報を提示する。一般に、注意書の文字列は、過去、現在および未来の行為における進行中の活動の注釈である。このフィールドにおいてタグ付きの言語を用いる利用により、音声、視覚的グラフィックス、静的リンクおよび動的リンクなどと対話するすべての潜在的なツールをユーザに提供するための全体的な能力を強化する。動的リンクとしては、プログレスバー、棒グラフなどが挙げられる。たとえば、活動に対する時間は、プログレスバーによって表され、投薬されるべき量から投薬されるインスリンは、プログレスバーなどとして示されることも可能である。
【０１０５】
上記の態様におけるイベント入力を特徴付けることに留意すると、システムにおいて以下のユーティリティが、提供されてもよい。所与の入力特性を有する薬剤（インスリン）を投薬するための薬剤投薬ユニット（インスリンポンプ）へのコマンド、所与の入力特性を有する測定行為を行うための測定ユニットへのコマンド、差し迫ったイベント活動入力特性に関する患者からの命令の集合の受信、および、アルゴリズムモジュール（すなわち、血糖管理制御アルゴリズムを含むシステムのソフトウェア構成要素）へのイベント入力の提示および／または出力イベントの増大である。血糖管理制御アルゴリズムは、被験者のグルコースレベルを目標範囲内に維持するために、収集された皮下センサデータ、被験者の所定の基礎プロファイルおよびユーザ入力に基づき、インスリン推奨を構成するために用いられる。タスク／イベントを行うために、（ｉ）デバイス（ii）アルゴリズムおよび（iii）ユーザに手順に特有のスケジュールを提示する。特性入力を格納し、データベースから特性入力を検索する。上述のユーティリティのそれぞれはさらに、本発明のシステムおよびソフトウェアがどのように機能するかの実施例を用いて説明される。
【０１０６】
所与の入力特性を有する薬剤を投薬するための薬剤投薬ユニットへのコマンド
この実施形態において、患者データ測定／収集デバイス４８（図２）は、薬剤投薬ユニットであり、たとえば、工程１６０（図４）の終わりで医療従事者による処方として割り当てられ、クライアントコンピュータ１４を介してアップロードされるようなシステムの推奨された治療に自動的に動作するプログラム可能なインスリンポンプである。イベント自体は、以下の多くの方法、すなわち、（ｉ）アルゴリズム、（ii）ユーザ、（iii）ウォッチドッグ（第３者ツール）、（iv）フェイルセーフ機構、（ｖ）データベース誘発イベントおよび（vi）手順に基づくもののうちの１つで生成される。一意に必要とされる特性は、次の通信が生じる前の周知または未知の時間長さに及ぶ必要があるものとする。投薬のタイミングは、糖尿病治療にとって重要である（すべてのイベントタイミングは好ましくは、現地時間に関する適切な調整によって、ＵＴＣ時間で維持される）。イベントのタイプは、イベントの内容を説明するか、および／または誘発されるイベント（たとえば、食事ボーラス、コマンドボーラス、食事ボーラスプロファイル）を記載する。開始される任意の活動は一般に、有限の持続時間によって境界が示される。持続時間は、コマンドボーラスの投薬を送出するために測定に物理的に有限の時間をとるように、定められるイベントの実際の持続時間に及ぶものと理解され、この持続時間は、アルゴリズムにとって、次のボーラスコマンドが決定されるときを考慮するために、または患者の身体におけるインスリン活動の持続時間であるべきインスリンの持続時間を捕捉することができるようにすることと関係がある可能性がある。相対時間は、イベントを基準点に対してずらすことを可能にする。たとえば、参照時間が食事の時間である場合には、相対時間は、たとえば、分単位のマイナス時間を指定することによって、食前投与を行うために利用される。そのような数のシーケンスはさらに、１回の投与計画を食事時間に対して投薬されるシーケンスの投与に拡張する。量は、活動の強度を指すことができ、または数量／量を表す。たとえば、この具体的な事例では、投薬されるインスリンの量である。持続時間と同様に、これもまた数のシーケンスであってもよい。シーケンスにおける要素の数は通常、相対時間における要素の数と一致する。注意書の文字列は、（ｉ）グラフィカルフォーマット、（ii）音声フォーマットにおける情報を提示する。さらに、格納されている場合には、情報は、活動のログを提示する。
【０１０７】
所与の入力特性を有する測定行為を行うための測定ユニットへのコマンド
良好な性能を達成するために、測定は、手動制御または自動フィードバック制御に関して必要とされる。次に、機能的な視点から、測定は、別のイベント単位として一般化される。当然のことながら、測定は、関連コスト、現実的な意味において測定することができる回数の制限、測定がどのように用いて、測定のシーケンスを命令するかなどの検討事項があり、測定はまた、行為を達成するために、手順に関連していてもよく、測定は、性能を改善するために必要とされ、測定の注意書は、測定するのに理想的な時間、安全性を測定して維持するのに最良の最小時間で、ユーザ、医療従事者（ＨＣＰ）（たとえば、医師、ＲＮ、ＬＰＮまたは救急医療隊員／ＥＭＴ）、緊急支援チームを支援することによって、値を追加する。種々の可能性は、上述したイベント特性を補い、ｂＧ測定のために、再対応される。測定のタイミングは、良好な治療を提供するために重要である。測定がいつ行われたかは好ましくは、ＵＴＣで捕捉され、アルゴリズムおよびまたはデータベースにサブミットされる。さらに、測定の注意書は、現地時間で提示される。たとえば、一実施形態において、患者データ測定／収集デバイス４８は、上述したように、システムによって出力された処方に基づいて、測定が現地時間で行われる必要があるときを但し書きで、患者に知らせるように、プログラムされる。このユーティリティの場合には、イベントのタイプは、イベントの内容を説明するか、および／または誘発されるイベントを記載する。たとえば、ｂＧスポット測定は、測定のために用いられるｂＧ測定計を表し、採血は、ｂＧ測定、インスリン血奬濃度またはＡ１Ｃ測定の獲得などの分析のための血液試料を表す。開始される任意の活動は一般に、持続時間によって境界が示される。持続時間は、グルコース濃度を決定するために、測定に物理的に有限の時間をとるように、定められるイベントの実際の持続時間に及ぶものと理解され、この持続時間は、アルゴリズムにとって、継続的な測定において、３０ｍｔｓ遅延程度の小さな測定遅延を有する可能性があることなどを考慮することと関係がある可能性がある。持続時間が有意でない可能性がある事例があり、そのような場合には、項目は、空いたままである。測定に関する相対時間は、多くの使用事例のシナリオを網羅するように行われることができ、文脈的であってもよい。相対時間は、カウントダウンまたは測定を行う残りの時間として作用することができる。相対時間は、最後の測定以降の経過時間を表すことができる。相対時間は、測定の所望の時間以降の時間を表すことができる。相対時間は、手順に基づく測定要件またはイベントに基づく測定要件に関する測定のための時間のシーケンスを表すことができ、特定の時間における持続時間で測定のシーケンスからなってもよい。量は、活動の強度を表すことができ、または数量を表す。たとえば、この具体的な事例において、量は、測定値を表す。デバイス４８がｂＧ測定ユニットを備える場合には、デバイスは、測定を表示することができ、測定時間が指定され、測定がまだ行われていない事例では、未来の項目および／または欠けている項目を管理するための論理回路を容易に設けることができる。最後に、注意書の文字列は、グラフィックフォーマットおよび音声フォーマットの両方の情報を提示することができる。さらに、すべての情報は、活動のログとして格納される。
【０１０８】
差し迫ったイベント活動入力特性についての患者からの命令の受信集合
一般に、よりよい性能を得るために、イベントは、特徴付けられる必要がある。現在、食事、たとえば、炭水化物集計のみが、利用される。そのような場合には、イベントの量フィールドは、食事の正味強度を捕捉する。しかし、その速度指数またはその血糖管理指数などの全機能には、対処されていない。イベントの持続時間フィールドは、食事速度の態様の１つを捕捉するために用いられ得る。食事イベントはさらに、食事の速度を再び捕捉するために、速い、中程度または遅いとして記載されてもよい。別の実施例は、運動であり、強度および持続時間が活動レベルを捕捉するのに役立つことができる。これらの実施例および他の実施例は、バックグラウンドのインスリンが、推奨された治療を提供する際にどのように調整されるべきかを微調整するために、プロセス１００のアルゴリズムで用いられ得る。運動の場合には、相対時間フィールドは、イベントを予めプログラムすることを可能にし、プロセス１００のアルゴリズムは、来るべきイベントと調和するように前もって、インスリンを微調整するために用いることができる。これは、システム遅延および応答遅延があるために、治療の性能を向上させる際にきわめて有用である。
【０１０９】
食事摂取、運動などの身体活動またはストレスなどの代替状態にあるタイミングは、治療調整を行うために必要とされる。そのような活動の特定は、手動であってもよく、この場合には、イベントは、手動項目によって誘発される。すべてのイベントタイミングは好ましくは、現地時間に関する適切な調整によって、ＵＴＣ時間で維持される。イベントのタイプは、イベントの内容を説明するか、および／または誘発されるイベントを記載する。たとえば、食事は、高いまたは低い血糖管理指数として記載されることができ、脂肪、蛋白質、炭水化物、食物繊維などの成分によって、または速い、中程度または遅い食事などの記述子によって特徴付けられ得る。開始される任意の活動は一般に、有限の持続時間によって境界が示される。持続時間は、誘発されるイベントの実際の持続時間を網羅するものと理解される。たとえば、食事活動の持続時間を知ることは、吸収の遅い食事に関連している。持続時間を知ることは、インスリン分布の決定に役立つ。同様に、他のイベント特徴付け選択は、治療の必要性に対処するために、アルゴリズムによって用いられる予想生理的負荷の知識を向上させる。
【０１１０】
相対時間フィールドは、イベントを基準点に対してずらすことを可能にする。臨床研究において、予備知識が制御装置の性能をさらに向上させることができることは明白である。予想される行為のインスリンに基づくインスリン治療は、中止または事前投与が可能である。一般に、予想される運動に関して、基礎インスリンは、削減され、さらに、アルゴリズムは、正常血糖の範囲内にグルコースを維持するために、炭水化物摂取イベントを増大させる。吸収の速い食事において、事前投与もまた、急上昇するグルコースを抑制するのに役立つ。量フィールドは、活動の強度または数量／量のいずれかを指すことができる。たとえば、激しい運動の場合には、運動イベントの強度を指し、食事の場合には、炭水化物の量によって記載されることができる。持続時間と同様に、これもまた数のシーケンスであってもよい。シーケンスにおける要素の数は通常、相対時間における要素の数と一致する。注意書の文字列は、（ｉ）グラフィカルフォーマット、（ii）音声フォーマットにおける情報を提示する。運動の場合における注意書の文字列は、物理的負荷および炭水化物の必要性を補償するために、即効性の炭水化物を消費するようにという患者へのアドバイスである。さらに、格納されている場合には、イベントの上記の情報は、活動のログを提示する。
【０１１１】
アルゴリズムモジュールへのイベント入力の提示および出力イベントの増大
アルゴリズムは、行為または結果を決定するための命令の集合である。アルゴリズムは、イベントの受信器であり、内部イベントの生成器であり、外部（出力）イベントの作成器である。アルゴリズム自体は、構造化された態様における複雑な問題の処置を可能にするように、モジュール構造化される。構造は、所与の行為に特殊化される機能ユニットに問題を分解することに集中する。モジュール化はさらに、問題の必要性に応じて、効果を含むことも可能であり、または効果を排除することも可能である。最終的な挙動は、さらなる発見的手法を通じてフィルタリングされる。したがって、より高いレベルで、各モジュールは、効果の重ね合わせとして見られることもできる。しかし、モジュールのそれぞれがどのように処理されるかの中心で制限されない。したがって、高レベルのモジュール機能性は、以下の通りである。管理およびハウスキーピング、監視および状態情報、主要イベントの処理、主要制御行為（血糖管理制御を提供するために重要である）および補正行為である。
【０１１２】
管理およびハウスキーピング
管理およびハウスキーピングモジュールは、以下の通りである。初期化／準備、欠けたサイクルの処理、イベントマッピング、インスリンバケット、構成要素破棄、データベースおよび実行手順である。初期化／準備は、過去、現在および未来の情報を管理する状態ベクトルである。欠けたサイクルの処理は、フェイルセーフとして任意の理由からスキップされたプロセス１００またはアルゴリズム呼び出しの再始動を処理する。イベントマッピングは、外部イベント集合を内部イベント集合にマッピングする。インスリンバケットは、バケットを満たすため、およびバケットを空にするために、構成要素として種々のモジュールからインスリン推奨を管理する。構成要素破棄は、以下のように説明される。一般に、現在の解法として、入力および出力が種々の構成要素の純粋な影響となる場合でさえも、生理学が問題を（ｉ）個別の構成要素として、または、（ii）グループ化されたモジュール効果として解く場合に、破棄工程は、個別の構成要素またはグループ化されたモジュール効果の検討中に必要とされない効果の除去を可能にする。したがって、たとえば、インスリン破棄は、最後のインスリン放出から制御行為のフィードフォーワードの項目から生じる任意のインスリン構成要素を否定している。内部ボーラス管理は、食事イベントから結果として生じるフィードフォーワードボーラスを投薬する。内部ボーラス管理は、（ｉ）内部イベントの作成および（ii）内部イベントのグループ化を可能にする。治療要素の管理は、それにより一般化され、偏光の必要性および新たな情報の利用可能性に応じて、効果の追加または効果の除去の自由度を可能にする。データベースは、データの検索および格納および情報の記録のために提供される。実行手順は、一般的なイベント構造に関して設計される手順フォーマットであり、医療提供者によって所望とされる手順活動の動的作成を可能にする。手順の一態様は、各患者に固有の情報を分析して生成するための最小情報を生成するための適合性を支援することである。
【０１１３】
監視および状態情報
状態の監視および通知のためのモジュールは、以下の通りである。グルコース更新、期限切れのグルコース、自己ボーラス、食事注意書、手順注意書、フェイルセーフ機構および主要イベントハンドラである。グルコース更新は、適合性および測定の必要性に関連する新たなグルコース測定値の利用可能性を追跡し、ユーザ向けの情報を生成する。期限切れのグルコースは、これも適合性および測定の必要性に関連する新しいグルコース値に関する必要がある場合に、ユーザに通知する。情報はまた、ユーザ向けに生成される。自己ボーラスは、自己ボーラスコマンド（内部活動）によって、任意のインスリン不一致を説明する。食事注意書は、ユーザに食事の開始を通知する。炭水化物摂取を取り上げる適合性問題は、他の監視および通知にまで拡張してもよい。手順注意書は、内部イベントを生成することによって、来るべき活動または差し迫った活動をユーザに通知する。フェイルセーフ機構は体系的に、ユーザがデバイスまたはシステムを停止しており、アラームが設定されることを応答者（たとえば、親またはウォッチドッグサービス）に通知し、その間中、時間ウィンドウを作成し、デバイスおよび／またはシステムが作動していないか、または呼び出しがアラームを無効にするために行われていない場合には、緊急の送り出しまたは接触を図るための代替形態が、ヘルプ用に提供される。主要イベントハンドラは、準備運動、運動、コマンドボーラスおよび食事補償器などの主要イベントを処理するためのモジュールである。準備運動は、運動制御装置を予想した基礎要件を改訂し、特定の運動の開始で制御装置に通知する。運動は、運動の持続時間の間、高血糖設定点を維持し、次に、その血糖設定点に戻る。コマンドボーラスは、さらなるインスリンボーラスのための要求（ユーザ制御）であり、非同期コマンドを可能にする。食事補償器は、炭水化物摂取の制御装置に通知する。代替状態／誘発イベントは、代替状態を取り上げ、イベントを誘発する。
【０１１４】
主要制御行為
主要制御行為モジュールは、血糖管理制御を提供するために重要な主要制御行為を形成し、以下の通りである。プロセスセンサデータ、インスリン設定点、グルコース予測、インスリン推奨モジュール、運動補償器、即効性の炭水化物摂取、食事補償器、モデル選択、モデルパラメータ決定／更新、患者の特徴付け、不一致の管理、最後に投薬されたインスリンおよび最後に推奨されたインスリンである。プロセスセンサデータは、利用可能な測定グルコース値、たとえば、センサユニットを介して得られた間質液値（ｉｓｆ）値および／または外部測定計から得られた血糖（ｂＧ）値からグルコース値を決定する。インスリン設定点は、目標基礎グルコース（すなわち、所与の基礎インスリン速度のために達成されるグルコース値）を維持するために用いられるインスリン注入速度である。グルコース予測は、過去のグルコース測定値、過去のインスリン測定、過去のイベントおよび未来のスケジュール化されたイベントを利用して、制御サイクルに関するグルコース値を予測する。欠けたサイクルは、アルゴリズムが制御サイクル中に呼び出されないときには必ず含まれる。グルコースは、説明する文脈によって決定されるように、測定グルコースであってもよく、または予測グルコースであってもよい。測定グルコースは、グルコースセンサから得られたグルコース値である。予測グルコースは、モデルを用いて、周知のグルコース値から決定された未来のグルコース値である。治療目標グルコースは、ユーザが達成したいグルコース値である。目標グルコース／グルコース設定点は、制御装置がフィードバックを通じて漸近的に達成したいグルコース値である。基礎制御行為は、基礎グルコースを維持するためにインスリン投与量を計算する。決定は、モデルおよびまたは基準設定に基づく。
【０１１５】
運動補償器は、増大する身体活動レベルを処理する。決定は、モデルおよびまたは基準設定に基づく。即効性の炭水化物摂取は、予想されるグルコース低下を補償するために即効性の炭水化物の摂取を処理する。決定は、モデルおよびまたは基準設定に基づく。食事補償器は、食事イベントに関するインスリンボリ（insulin boli）分布を計算する。決定は、モデルおよびまたは基準設定に基づく。開ループ基礎実行は、開ループ制御装置の中で基礎インスリンを実施する。決定は、基準設定に基づく。モデル選択は、図４に関して上述したプロセス１００の部分などの患者の必要性に最もよく対応する適切なモデルの決定である。基準は、生活様式の選択、用いられる過去のイベント、未来のイベントおよび手順に基づき、および／または単に医療従事者の選択に基づく。モデルパラメータ決定／更新は、選択されたモデルに関するパラメータを決定する。決定は、前のデータ、デバイスによって収集されたデータ、パラメータ決定設定を用いる。患者の特徴付けは、各患者に固有のパラメータの選択時または母集団に基づくモデルが評価されるときである。決定されたモデルおよびパラメータは、複数の検証を経て、結果が一定の周知の予測を満たして維持している場合には、決定されたパラメータが選択され、そうでない場合には、次善のそのような母集団に基づくパラメータ設定が、治療決定のために利用され、グルコースを制御する。治療パラメータ決定／更新はまた、図４のプロセス１００に関して上記で前述される。不一致の管理は、命令されたインスリンと投薬されたインスリンとの間の不一致が特定されたときに、インスリンバケットを管理する。最後に投薬されたインスリンは、サイクルのために投薬されたインスリンの量である。最後に推奨されたインスリンは、アルゴリズムによって計算され、推奨として医療従事者に供給されたインスリンの投与量である。
【０１１６】
補正行為
補正行為は、以下の通りの補正行為をとるために用いられ得るモジュールである。炭水化物修正、高グルコース治療介入、低グルコース治療介入および食事グルコース領域である。炭水化物修正は、前に入力された食事イベント（炭水化物値）を改訂し、したがって、インスリン放出が補正される。高グルコース治療介入は、インスリン放出によって高いグルコースレベルを補正する。低グルコース治療介入は、即効性の炭水化物の摂取によって低いグルコースレベルを補正する。食事グルコース領域は、線としてではなく、帯としてグルコース目標を定義する。他の実施形態において、他の適切な補正行為が用いられてもよい。
【０１１７】
タスク／イベントを行うための（ｉ）デバイス、（ii）アルゴリズムおよび（iii）ユーザに対する手順に特有のスケジュールの提示
手順は、イベントのシーケンスの計画された実行である。プランの順守により、（ｉ）改善した処置を可能にするか、（ii）具体的な分析に関して収集されたデータを用い、医療行為を決定することができるか、または（iii）生活様式が、治療食プラン、運動プラン、食事のタイミング、食事の成分などを計画する場合の一般的な使用事例を可能にする。これは、適切なデータで医療提供者を支援することに関連しているが、正しいタイミングで収集されたデータおよび特定の脂肪、蛋白質および炭水化物の成分を有する食事などの関連イベントも医療提供者を支援することに関連している。手順は次に、ｂＧ測定、ボーラスコマンド、食事摂取および運動から構成されるイベント単位の特定のシーケンスである。イベントは、多くのモードで誘発されることができ、たとえば、ハンドヘルド型デバイスがプログラムされる、患者が従う簡単な紙に基づく記述、患者を支援する適合性カウンセラなどの自動サービスなどがある。
【０１１８】
特性入力の格納およびデータベースからの特性入力の検索
データベースは、中央情報記憶ユニットである。データベースは、イベントおよびユーザに特有の設定を格納して検索するために用いられる。格納されたイベントは、過去のイベント、現在のイベント、スケジュール化された未来のイベントに及ぶ。データベースは、進行中の現在の活動および過去の活動のログとしてイベント情報の格納に関して用いられ、過去のイベントおよび未来のイベントを検索するために用いられ、スケジュール化されたイベントを誘発するために用いられる。上述のシステム、プロセスおよびソフトウェアモジュールの特定の実行は今度は、本発明の理解をさらに深めるために、以下で提供される。
【０１１９】
特定の実行の実施例
上述した装置および方法論は、以下の例示の実施形態において統一され、糖尿病などの慢性疾患に対処するための治療の収集、分析および決定を行う医療提供者の能力を向上させる。ＤＴＰＳ方法論を利用する第１の例示の実施形態において、自動膵臓試験ストランド（ＡＰＴＳ）プログラムが、表示される。ＡＰＴＳは、臨床設定において、糖尿病被験者を制御するために用いられるソフトウェアプログラムである。これもＤＴＰＳ方法論を利用する第２の例示の実施形態において、自動膵臓−制御制御アルゴリズム試験項目群（ＡＰＣＡＴＳ９００）プログラムが、表示される。ＡＰＣＡＴＳ９００は、たとえば、クライアントコンピュータ１４（図２）において実行中のエミュレート環境において、糖尿病被験者を分析するソフトウェアプログラムである。図５を参照して、ＡＰＴＳプログラムが最初に説明され、次に後の節で、ＡＰＣＡＴＳ９００プログラムに関する説明が以下に続く。
【０１２０】
自動膵臓試験ストランド（ＡＰＴＳ）プログラム
図５を参照して、ＡＰＴＳプログラム５００は、従来のコンピュータ（たとえば、ラップトップ、携帯情報端末（ＰＤＡ）、スマートフォンなど）で実行し、２つの独立のソフトウェア構成要素、すなわち、自動膵臓ソフトウェア（ＡＰＳ）５０２および自動膵臓ソフトウェア通信アプリケーション（ＡＰＳＣＯＭ）５０４を提供する。後の節で説明されるように、ＡＰＳ５０２は、インスリン推奨のための包含アルゴリズムシェル（ＡＬＧＯＳＨＥＬＬ）５０６への定期的な呼び出しを行い、ＡＰＳＣＯＭ５０４と対話する。ＡＬＧＯＳＨＥＬＬ５０６に関する説明は、後の節で以下で提供される。ＡＰＳＣＯＭ５０４は、形態ユニット（ＰＵ）５０８から情報を収集し、ＡＰＳ５０２と対話し、データベース２４（図２）などのデータベースに情報を格納して、情報を検索する役割を担う。一実施形態において、ＰＵ５０８は、デバイス４８（図２）であり、別の実施形態において、皮下連続グルコースモニタ（ＳＣＧＭ）などのグルコース濃度を測定するセンサである。この皮下連続グルコースモニタ（ＳＣＧＭ）は、頻繁なグルコース測定を行うために、Ｒｏｃｈｅ  Ｄｉａｇｎｏｓｔｉｃｓ  Ｃｏｒｐｏｒａｔｉｏｎによって開発された微小透析に基づくデバイスである。さらに別の実施形態において、携帯可能なユニット５０８は、インスリンポンプまたはインスリンポンプシステムであり、たとえば、Ｒｏｃｈｅ  ＤｉａｇｎｏｓｔｉｃｓのＡｃｃｕ−Ｃｈｅｋ（登録商標）Ｓｐｉｒｉｔインスリンポンプ  システムである。インスリンポンプシステムの実施形態において、ＡＰＳＣＯＭ５０４は、インスリンポンプシステムを備えるＰＤＡ上に提供されるソフトウェアと通信してもよく、または同一のＰＤＡでＡＰＴＳが実行される場合には、インスリンポンプ制御ソフトウェアと通信してもよい。
【０１２１】
インスリン放出計画を決定し、ＡＬＧＯＳＨＥＬＬ５０６を介して投与量をＡＰＳ５０２に通信する制御装置モジュール呼び出しＡＬＧＯ５１０もまた、提供される。ここでの計画によって、時間および値のペアを意味している。ＡＬＧＯＳＨＥＬＬ５０６は、状態管理、ＡＬＧＯ呼び出し選別、単位変換および投与量の決定などの標準的なシステム機能性のいくつかを行う。ＡＰＳ５０２は、制御サイクルと本願明細書において呼ばれる時間の定期的な間隔でＡＬＧＯＳＨＥＬＬ５０６を呼び出す役割を担っている。ＡＰＳ５０２はまた、ＡＰＳＣＯＭ５０４と定期的に対話する。一実施形態において、ＡＰＳＣＯＭ５０４は、一実施形態において、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ａｃｃｅｓｓデータベースとして実行されてもよいＡＰＳ５０２およびデータベース２４（図２）などのプログラムと通信するためのＭｉｃｒｏｓｏｆｔ（登録商標）ＣＯＭ技術を用いる。他の実施形態において、他の通信フレームワークおよびデータベースアプリケーションは、．ｎｅｔ  ｆｒａｍｅｗｏｒｋ、Ｕｎｉｘ（登録商標）、Ｏｒａｃｌｅ、ＳＱＬ、Ｊａｖａ（登録商標）などの本発明を実行するために用いられてもよい。ＡＰＴＳプログラム５００はまた、ＡＰＳ５０２がデータの表示およびＨＣＰおよび／または患者からのイベント情報の受信のために用いるユーズインターフェイス５１２を提供する。
【０１２２】
システムワークフロー
この節は、システムの作用およびワークフローを示し、制御装置ＡＬＧＯ５１０に直接関連する種々の高度ＡＰＳ−ＡＬＧＯ呼び出しシーケンスの作用およびワークフローを示す。制御サイクル期間Ｔcごとのシステムにおけるイベントのシーケンスは、図５の円で囲まれた文字Ａ〜Ｊに対応する。ＡＰＳ５０２は、規則的な方式でシステムを駆動し、主要時間記述子のいくつかが、図５に詳細に示されている。イベントＡ（時間−ＴΔ）で、ＡＰＳ５０２は、ＡＰＳＣＯＭ５０４を呼び出し、新たなセンサデータ集合および投与される正味のインスリンに関するデータを取得する。制御エッジに関する時間はここでは、ゼロに設定され、イベントシーケンスＢで、ＡＰＳ５０２は、ＡＬＧＯＳＨＥＬＬ５０６を呼び出す。ＡＬＧＯＳＨＥＬＬ５０６は次に、状態情報を更新し、単位変換を行い、モードを検証して、インスリン推奨に関してＡＬＧＯ５１０を呼び出す。ＡＬＧＯ５１０は、推奨をＡＬＧＯＳＨＥＬＬ５０６に返す。ＡＬＧＯＳＨＥＬＬ５０６は、変換を行い、次に、状態を更新し、ＡＰＳ５０２に返す。イベントシーケンスＢの終了後、ＡＬＧＯＳＨＥＬＬ５０６は、推奨をＡＰＳ５０２に返し、これがイベントシーケンスＣである。これは、ＳＹＮＣ−Ｉ呼び出しと呼ばれる。
【０１２３】
イベントシーケンスＣの終了後、イベントシーケンスＤにおいて、ＡＰＳ５０２は、ユーザインターフェイス５１２において推奨ウィンドウ５１４を開き、デバイス４０（図２）などの入力デバイスの使用を介してユーザが推奨の許容または中止を行うのを待つ。ＡＰＳ５０２は、推奨ウィンドウが時間切れになるまで入力を待つ。イベントシーケンスＤの終了後、推奨ウィンドウは、イベントシーケンスＥでは、ＡＰＳ５０２に返す。ユーザが推奨を承認し、したがって、イベントシーケンスＥを終了した場合には、イベントシーケンスＦでは、ＡＰＳ５０２は、ユーザインターフェイス５１２において承認ウィンドウ５１６を開き、入力デバイス（たとえば、デバイス４０）を介してユーザが承認の許容または中止を行うのを待つ。ＡＰＳ５０２は、承認ウィンドウが時間切れになるまで入力を待つ。イベントシーケンスＦの終了後、イベントシーケンスＧでは、承認ウィンドウが、ＡＰＳ５０２に返す。次に、イベントシーケンスＨでは、ＡＰＳ５０２は、（ａ）ユーザによって承認される用量、（ｂ）ユーザによってゼロにされる用量、（ｃ）または、時間切れの場合には、閾値要件を満たす量、他の場合には０でＡＬＧＯＳＨＥＬＬ５０６を呼び出す。第２のＡＬＧＯ呼び出しは、ＳＹＮＣ−２呼び出しと呼ばれる。閾値要件は、医療従事者によって拒否されない限り、被験者に投与される承認済みの推奨インスリン投与量であることに留意されたい。イベントシーケンスＨの終了後、ＡＬＧＯＳＨＥＬＬ５０６は、イベントシーケンスＩでは、最終的なコマンド量をＡＰＳ５０２に返し、次に、ＡＰＳ５０２は、イベントシーケンスＪでボーラスコマンドをＡＰＳＣＯＭ５０４に与える、これが、制御サイクル期間を終了させる。
【０１２４】
ＡＬＧＯ
この節はさらに、ＡＬＧＯ５１０の主要な作用を明らかにする。投与量が確実かつタイムリーに提供されることが治療には重要である。以下の節において、ＡＬＧＯ５１０の以下の態様が、対処される。タイミング態様−ＡＬＧＯ５１０に基づく指数が、経過した実時間をどのように決定するか；メモリ持続時間−新たな推奨を決定するために必要な過去の履歴（システムメモリ）の長さ；欠けたサイクル−ＡＬＧＯ５１０が欠けた呼び出しをどのように処理するか；動作モード；およびＡＬＧＯ５１０において提供される経験的アルゴリズムモジュール（ＥＡ）５１８に対する呼び出し。ＥＡ５１８は、複数の機能的モジュール５６（図３）に要求し、および／または複数の機能的モジュール５６（図３）を提供する、インスリン投与量を推奨するためのルールベースの集中治療戦略の収集物である。インスリン用量推奨は、最新のグルコース情報と、食事、運動、治療介入などのイベント情報と、に基づく。集中治療は、インスリンに左右される糖尿病用の処置の形態であり、主要な目標は、可能な限り正常範囲に近い値に血糖値を維持することである。処置は、１日に３回以上のインスリン注射またはインスリンポンプの使用、１日に４回以上の血糖検査、血糖検査結果に基づくインスリン、食事摂取および活動レベルの調整、食事相談、および糖尿病チームによる管理からなる。ＥＡ５１８は、頻繁な規則的間隔におけるグルコースの連続的監視および集中治療基準の実行によって、この原理を拡張する。インスリン投与量推奨は、最新のグルコース測定、過去のインスリン放出情報、および食事、運動、治療介入などのイベント情報を用いて評価される、一実施形態において、ＥＡ５１８に対するそのような更新は、改訂された経験的アルゴリズムによる既存のＥＡ５１８の交換／更新を可能にするオープンアーキテクチャを提供することによって好都合に行われる。本発明の中で実行されることができる１つのそのような適切なオープンアーキテクチャ方法は、＿という名称で代理人整理番号ＲＯＰ００１５ＰＡ／ＷＰ＿ＵＳを有する同時係属中の米国特許出願第＿号に記載される。この特許は、本開示の譲受人に譲渡され、その開示内容は、参照によって本願明細書に援用されるものとする。
【０１２５】
ＡＰＴＳ５００のＥＡ５１８および他のモジュールの部分を定義する際に、本願明細書で用いられるとき、表２に列挙された記号は、以下の命名法を有する。
【０１２６】
【表２】
0005529307.tif 000007
0005529307.tif 000008
【０１２７】
タイミング態様
上述したように、ＡＰＴＳは、タイミングが投与における主要な態様である実時間システムである。ＥＡ５１８は、適切な制御量を決定する実時間とは無関係なディジタル補償器を用いる。ＥＡ５１８は、時間の現実の感覚を有さず、変数配列の指数に存在するタイミングを用いるように構造化される。言い換えれば、ＥＡ５１８の行為は、ある意味では指数に基づき、時間の認識は、制御サイクル期間Ｔcの選択によって暗黙に構成される。たとえば、インスリン薬力学は、インスリン残留Ｉr［ｉ］の１次元配列として定義される。ここで、ｉ番目の要素が経過時間ｔ＝（ｉ−１）Ｔcで残留するインスリンを間接的に示す。したがって、ｉ番目の指数と時間ｔとの間に依存性がある。
【０１２８】
図２０に示されているように、ＡＬＧＯ５１０制御装置のタイミング記述は、時刻に依存するだけでなく、実験開始（たとえば、処方として実行される治療推奨の開始）以来の経過時間にも依存する。項ＴA0は、ＡＰＳ５０２によって、実験が開始され、記録される時間を表す。時間は、分に変換され、真夜中からの分単位の時間を表す。項ｔaは、真夜中からの分単位の実際の時刻である。項ｔは、実験開始に対する経過時間であり、相対時間ｔ＝０は、実験の開始を示す。Ｋ＝１項は、第１の制御サイクルを指す。すべての次のサイクルは、１ずつ増分される。項ｋは、現在のｋ番目のサイクルを表す。各制御サイクル期間Ｔcは、開始時間ｔsおよび終了時間ｔeの１対の制御エッジを有する。任意の所与の相対時間ｔで、ＡＬＧＯ５１０は、現在の時間Ｔの場合に現在の呼び出しがどの制御サイクル期間Ｔcに参加するかを決定する。重要なことは、実行される実時間制御システムが、ソフト時間制御を有することである。このことは、ＡＬＧＯ５１０に対する呼び出しが、厳密に制御サイクル期間Ｔcの開始エッジにあるのではなく、開始時間ｔsの制御エッジのある程度の時間精度の範囲内にあることを意味する。項ＴΔは、制御エッジからの時間オフセットであり、ＡＰＳ５０２によって、データ要求が送信され、取得される瞬間である。たとえば、値は、ＰＵ５０８が種々のデバイスから収集されたデータをＡＰＳＣＯＭ５０４を介してＡＰＳ５０２に伝送する時間を表してもよい。項Ｔ▽は、ＡＰＳ５０２がコマンドによるインスリンをＰＵ５０８に伝送する時間である。項Ｔδは、推奨ウィンドウおよび承認ウィンドウが制御サイクル期間Ｔcの開始時間ｔsのエッジに対して表示される時間切れ最大持続時間である。
【０１２９】
メモリ持続時間
ＥＡ５１８は、過去の情報および現在の情報を用いて、ＡＬＧＯ５１０のためにインスリン推奨を計算する。情報が必要とされる時間期間は、システムが入力の効果を消去するのにどれくらいかかるかに左右される。インスリン活動持続時間がＴDI分である場合には、式（４）によって与えられる、
【数５】
0005529307.tif 000009
式中、ｎは、情報が維持されるサイクルの数である。欠けたサイクルの事例を取り上げるために、複数の余分の制御サイクルもまた、バッファとして必要とされる。この場合には、ｎHは、ｎと予想される欠けたサイクルの最大数の和として定義される。ＡＬＧＯ５１０を管理するために必要な（かつ十分な）範囲は、ｎHサイクルにわたって履歴を維持することである。
【０１３０】
欠けたサイクル
ＡＬＧＯ５１０は、すべての新たな情報入力を処理し、情報を治療に変換する役割を担っている。欠けたサイクルは、ＡＬＧＯ５１０が呼び出されない制御サイクル期間である。ＡＰＴＳ５００全体が完全であった場合には、ＡＬＧＯ５１０は、すべての制御サイクル期間Ｔcで呼び出されるであろう。しかし、呼び出しが、欠ける可能性がある。サイクルが欠けている場合には、ＡＬＧＯ５１０は、欠けたサイクルのそれぞれについて反復的に実行される。このことは、欠けたサイクルが生じたときには、ＡＬＧＯ５１０が呼び出されるまで、治療が保留中であることを意味する。ＡＬＧＯ５１０が、現在の呼び出しを実行する前に、欠けたサイクルのそれぞれを通じて、欠けた呼び出しおよび工程を検出する。これは、イベントが欠けずに、および重複しないで、順に対処されることを保障する
。欠けたサイクルは、種々の理由から生じる可能性がある。ＡＬＧＯ５１０に供給された情報に不一致がない限り、同期は正確である。このシナリオを処理する際には、ＡＬＧＯ５１０は、呼び出しが欠けていないかどうかを最初に決定する。欠けた呼び出しが見つからない場合には、ＡＬＧＯ５１０は、種々のＥＡ５１８モジュールを実行する。ＡＬＧＯ５１０が欠けた呼び出しを検出する場合には、ＡＬＧＯ５１０は、現在の呼び出しを評価する前に、欠けた呼び出しのすべてを最初に実行する。
【０１３１】
動作モード
ＡＬＧＯ５１０によってサポートされる動作モードは、Ｐｕｒｅ−ｃｏｎｔｒｏｌおよびＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓである。図６を参照すると、ＥＡ５１８に関する動作のＰｕｒｅ−ｃｏｎｔｒｏｌモード６００は、グルコース測定を用いて適切な制御行為を提供する閉ループシステムである。ＡＬＧＯ５１０の役割は、所定の目標グルコースレベル６０１にグルコースを維持することである。制御装置の初期化中、または被験者に障害が生じた場合には常に、グルコースは、目標グルコースレベル６０１から逸脱することが予想される。Ｐｕｒｅ−ｃｏｎｔｒｏｌは、グルコース測定および放出されたインスリン情報を用い、被験者の状態を「把握する」。図６右下で、被験者ブロック６０２が、グルコースセンサ６０４およびインスリンポンプ６０６に接続されている。これらのデバイスは、破線で示される携帯可能ユニット５０２（図５）のＲＦリンク６０８を介して、ＡＰＳ５０２と間接的に接触状態にある。イベントブロック６１２から始まる破線６１０は、知られたイベントの発生を示す。これらのイベントの情報は、ＡＬＧＯ５１０に利用可能に構成される。イベントハンドラ６１４は、外部イベント記述の間で内部イベント計画への適切なマッピングを提供する。ＡＬＧＯ５１０は、適切なモジュールをトリガーして、わかっている障害を処理する。適切なモジュールは、コマンドインスリンモジュール６１６、高グルコース治療介入モジュール６１８、食事補償器モジュール６２０、運動補償器６２２または低グルコース補償器モジュール６２４のうちの少なくとも１つを含む。グルコース予測器６２６および基礎制御装置６２８が、不明な障害およびモデル化エラーを処理する。制御装置の初期化は、不明な障害の場合である。制御装置は、実験が始まり、モードがＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００からＰｕｒｅ−ｃｏｎｔｒｏｌモード６００に切り替わるときに、初期のグルコース値を安定化しなければならない。そのような場合において、Ｐｕｒｅ−ｃｏｎｔｒｏｌモード６００の動作は、いくつかの初期グルコース値から目標グルコース値に被験者をスムーズに移行させるために、過去のイベントからの情報が利用可能であることに頼ることになる。閉ループバケット管理ブロック６３０は、正味のインスリン推奨を決定して管理する。インスリン放出モジュール６３２、グルコースフィルタ６３４およびインスリン投与量無効器６３６については、以下に提供される後の節で説明される。
【０１３２】
Ｐｕｒｅ−ｃｏｎｔｒｏｌモード６００は、グルコース測定および内部／外部入力イベントを用いて血糖管理制御を維持するインスリン推奨である。医療従事者は、このモードにスイッチ６３８を変更するインスリン推奨を許容することによって、能動的にループを閉じる。動作モードは、開ループＨＣＰ管理インスリン推奨と半閉ループＡＬＧＯ決定インスリン推奨との間を区別する。これらの２つのモードが医療従事者によって設定される場合であっても、ＡＬＧＯ５１０は、Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００に入る場合がある。これは、以下の状況が満たされるときに起こる。測定遅延（たとえば、たとえ起こったとしても実験の開始時）によりグルコース測定が利用できなくなるｂＧのない状況、最後の利用可能なグルコース測定が許容可能なグルコース使用期限より古いために、その時間を示したｂＧ測定が期限切れの状況である。Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００について、今度は、図７を参照して以下で説明される。
【０１３３】
Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００は、Ｐｕｒｅ−ｃｏｎｔｒｏｌモード６００の特殊な事例であり、図７におけるブロック図によって示される。ユーザ治療は、被験者の予めプログラムされるポンプ基礎速度を用いて実行され、コマンドによるボーラスイベントの使用によって増強される。これは、開ループ制御であり、治療は、医療従事者または被験者によって手動管理される。記述は、Ｐｕｒｅ−ｃｏｎｔｒｏｌモード６００に関して提供された記述と類似であるため、類似の要素は、類似の記号で表される。操作に関して、履歴および更新状態ベクトルを維持するために、グルコース測定、インスリン放出および記録されるイベントは主に、ＡＬＧＯ５１０によって用いられる。しかし、コマンドによるボーラスモジュール６１６および高グルコース治療介入モジュール６１８の２つのイベントモジュールのみが適用可能である。これらのモジュールは、被験者または医療従事者が治療を管理し、インスリンボーラスを投与することを可能にする。食事補償器イベント６２０、運動補償器イベント６２２および低グルコース治療介入イベント６２４は、Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００では実行されない。基礎速度制御６２８は、プログラムされるポンププロファイルの再現である。
【０１３４】
経験的アルゴリズム呼び出し
経験的アルゴリズム（ＥＡ）５１８は、モジュールのグループとして構造化される。各モジュールは、治療推奨の態様を処理する。図８および図９は、本発明の実施形態によるすべてのモジュールおよび実行の順序を示すＥＡ５１８のフローチャートである。これは、例示目的のためだけに提示されており、実施形態に応じて複数の方式で順序付けされることができる。図８および図９において、円で示される点９Ｘおよび点９Ｙは、図の間のリンクである。各モジュールは、最終的な治療推奨に寄与する独立の挙動として構造化される。したがって、各モジュールは、効果の重ねあわせとみなされることができる。モジュールのそれぞれに符号をつけた文字Ａ〜Ｅは、モデルグループを表し、それぞれの説明文と共に、構造化情報を提供する。モジュールグループおよび関連する文字は、「Ａ」−主要制御行為（血糖管理制御を提供するために重要である）、「Ｂ」−管理およびハウスキーピング（最上位）、「Ｃ」−監視および状態情報、「Ｄ」−補正行為および「Ｅ」−主要イベントの処理である。これらのモジュールグループそれぞれに関する一般的な説明は、以下で提供される。
【０１３５】
主要制御行為
血糖管理制御を提供するために重要である主要制御行為用のモジュールは、プロセスセンサデータ８０６、インスリン設定点８０４、グルコース予測８３８、インスリン推奨モジュール８４６、運動補償器８２２、即効性の炭水化物摂取８２４、食事補償器８４０および開ループ基礎実行論理８５０である。プロセスセンサデータ８０６は、利用可能な測定グルコース値からグルコース値を決定するための戦略を含む。インスリン設定点８０４は、目標基礎グルコースを維持するために用いられるインスリン注入速度である。グルコース予測８３８は、最後に知られたグルコース測定値から制御サイクル用のグルコース値を予測する。インスリン推奨モジュール８４６は、基礎グルコースを維持するために、インスリン投与量を計算する。運動補償器８２２は、増大した身体活動レベルを処理する。即効性の炭水化物摂取８２４は、予想されるグルコース低下を補償するために、即効性の炭水化物の摂取を処理する。食事補償器８４０は、食事イベント用のインスリンボーラス分布を計算する。開ループ基礎実行論理８５０は、開ループ制御装置ｃｏｎｔｒｏｌｌｅｄ−ｏｂｓ７００（図７）中、基礎インスリンを実行する。
【０１３６】
管理およびハウスキーピング（最上位）
ＡＬＧＯ５１０の最上位で、操作は、管理およびハウスキーピングに関連する問題である。管理およびハウスキーピングモジュールは、初期化／準備８００、欠けたサイクルの処理８０１、イベントマッピング８０２、インスリンバケット８４８およびインスリン無効化８３６である。初期化／準備モジュール８００は、過去、現在および未来の情報（ＡＬＧＯメモリ）を管理するＡＬＧＯ状態ベクトルである。前の節で上述した欠けたサイクルの処理モジュール８０１は、任意の理由からスキップされたＡＰＴＳまたはＡＬＧＯ呼び出しの再起動を処理する。イベントマッピング８０２は、外部イベント設定を内部イベント設定にマッピングする。インスリンバケット８４８は、バケットを満たすための成分およびバケットを空にするための成分として種々のモジュールからインスリン推奨を管理する。インスリン無効化８３６は、最後のインスリン放出から制御行為のフィードフォーワード条件（terms）から生じる任意のインスリン成分を無効にする。内部ボーラス管理８４４は、食事イベントから結果として生じるフィードフォーワードボーラスを放出する。
【０１３７】
監視および状態情報
状態を監視して通知するためのモジュールは、新たなグルコース測定値の利用可能性を追跡するグルコース更新８０８である。期限切れのグルコース８１４は、新しいグルコース値の必要性があれば、ユーザに通知する。自己ボーラス８１０は、自己ボーラスコマンドによって任意のインスリン不一致を説明する。前の節で上述したように、グルコースがないことを警告するのは、フェイルセーフ機構であり、ＰＵ５０２（図５）が応答しないことおよびウォッチドッグ回路がタイマカウントダウンを開始する必要があることをシステムに忠告する。食事注意書８４２は、ユーザに食事の開始を通知する。
【０１３８】
補正行為
補正行為用のモジュールは、炭水化物修正８３４、高グルコース治療介入８３２、低グルコース治療介入８２６、食事グルコース領域８２０および不一致の管理８１８である。炭水化物修正８３４は、前に入力された食事イベント（炭水化物値）を改訂し、したがって、インスリン放出が補正される。高グルコース治療介入８３２は、インスリン放出によって高いグルコースレベルを補正する。低グルコース治療介入８２６は、即効性の炭水化物の摂取によって低いグルコースレベルを補正する。食事グルコース領域８２０は、線としてではなく、帯としてグルコース目標を定義する。不一致の管理８１８は、コマンドによるインスリンと放出されたインスリンとの間の不一致が特定されたときに、インスリンバケットを管理する。
【０１３９】
主要イベントハンドラ
主要イベントを処理するためのモジュールは、準備運動８２８およびコマンドによるボーラス８３０である。準備運動８２８は、運動制御装置の予想した基礎要件を改訂し、特定の運動の開始で制御装置に通知する。コマンドによるボーラス８３０は、さらなるインスリンボーラスのために要求する。ＥＡ５１８の上記のモジュール記述は事実上、一定のモジュールに関して一般的であるが、そのようなモジュールについてのさらに詳細な説明は、以下で提供される。
【０１４０】
イベントマッピング
初期化および準備モジュール８００および欠けたサイクルの処理モジュール８０１を実行した後で、ＡＬＧＯ５１０は、ＡＰＳ５０２によって受信されるイベントを通じて、外部の障害情報を獲得するために、イベントマッピングモジュール８０２を実行する。たとえば、一実施形態において、外部イベントは、ユーザ選択のために、ＡＰＴＳ５００のユーザインターフェイス５１２においてドロップダウンリストで表示される。ＡＬＧＯ５１０は、ＡＬＧＯ自体に特有であるイベントで動作する。これらは、呼び出される内部イベントである。ユーザによって選択された各外部イベントは、せいぜい１つの内部イベントにマッピングされる。外部イベントは、エンドユーザが関連する記述子が提供され、および／または選択時にＡＬＧＯ行為をトリガーする。これらの記述子は、ユーザに特有であり、複数の言語をサポートすることが可能である。
【０１４１】
一実施形態において、同一の内部イベントに関連する複数の外部イベント記述子があってもよい。たとえば、「自己ボーラス」および「プライミングボーラス」は、個別の外部イベント記述子であるが、内部でこれらのイベントの両方は、同一の内部イベントタイプ（自己ボーラス（Self_Bolus）と呼ぶ）を指す。したがって、同一の内部イベントを指す複数の外部イベントを有する（多対一）ことが可能である。表３は、ＡＬＧＯ５１０が作用する基本的な内部イベントを列挙している。
【０１４２】
【表３】
0005529307.tif 000010
【０１４３】
インスリン設定点
次に、ＥＡ５１８は、インスリン設定点モジュール８０４を実行する。このモジュール８０４の場合には、基礎インスリン速度（すなわち、グルコース値を維持するために用いられるインスリン注入速度）は、代表的な１日に関して通常は定義される基礎プロファイルである。しかし、被験者の生活様式によって見られるような代表的な１日は、ＡＬＧＯ５１０を駆動するために用いられる１日とは、かなり異なる。たとえば、本願明細書で用いられるとき、（ａ）ポンププロファイルおよび（ｂ）ＡＬＧＯ定義のプロファイルの２種類の基礎インスリンプロファイルがある。ポンププロファイルの場合には、基礎速度は、１日にわたって変化する。予めプログラムされた速度は、食事および他の代表的なイベントの部分を対象とするインスリンを含んでもよい。定義されたプロファイルは、ユーザに特有であり、被験者の日常のスケジュールおよび生活様式に対してカスタマイズされる。ＡＬＧＯ定義のプロファイルの場合には、プロファイルは、食事および運動のようなイベントを管理するために必要なボーラスを分析して除去した後に、決定される。ＡＬＧＯ定義のプロファイルを決定するために、ＥＡ５１８は、新たな被験者に関する集中的なデータ監視を用いる。実験を経験した被験者の場合には、この臨床データは、ＡＬＧＯ定義のプロファイルを決定するために用いられる。これらは、実験的手順および解決（ravel）および解明（unravel）ツールなどの支援ツールによって決定される。したがって、抽出された基礎速度は、イベントに関連するインスリン投与量とは独立である。このＡＬＧＯ定義のプロファイルは、基礎設定として保存される。
【０１４４】
基礎設定は、３列の配列行列として示され、被験者初期化ファイル（すなわち、Subject-iniファイル）によって定義される。行列は、時間、基礎速度および基礎グルコースを含む。表４は、被験者の初期化ファイルにおける基礎設定の実施例である。
【０１４５】
【表４】
0005529307.tif 000011
【０１４６】
基礎速度は、１日の目標グルコース値および時刻の両方の関数である。日常の基礎速度プロファイルは、時間ｔaに関して、Ｕ／時単位のインスリンの一定の流速として定義される。時間ｔaは、真夜中から分単位で定義され、インスリンプロファイルは、時間に基づいて、昇順に配置される。一定の流速は、インスリン流速の次の設定に達するまで実行される。基礎速度プロファイルは、各２４時間周期にわたって繰り返される。基礎インスリン速度は、目標グルコースの維持管理に不可欠である。所与のインスリン速度および対応するグルコース値は、所与の目標グルコース値を維持するために必要とされるインスリン速度を決定する。インスリン速度は、目標グルコースの一次関数と仮定すると、式（５）に基づいて与えられる。
【０１４７】
【数６】
0005529307.tif 000012
式中、ＧBは、目標グルコース値であり、ＩBは、ＧBのグルコース値を維持するためのインスリン速度であり、
【数７】
0005529307.tif 000013
は、１日のうちの所与の時刻に関する基礎設定において定義されたグルコース値であり、
【数８】
0005529307.tif 000014
は、
【数９】
0005529307.tif 000015
のグルコース値を維持するために必要とされるインスリン速度であり、
【数１０】
0005529307.tif 000016
は、グルコースの変化当たりのインスリン速度である。たとえば、図１０は、上記の設定点関係をグラフによって示す。特に、図１０における線Ｘは、
【数１１】
0005529307.tif 000017
が一定であると定義されると、グルコース設定点の関数として、正午における基礎インスリン速度を示す。類似の線Ｙは、真夜中であるがより低い設定点（０．８対１．３）における基礎インスリン速度の場合を同様に示す。しかし、勾配は、このインスリンとグルコースの関係を示すために誇張されており、例示の実施例に過ぎないことを留意されたい。
【０１４８】
プロセスセンサデータ
インスリン設定点モジュール８０４による実行後、ＥＡ５１８は今度は、プロセスセンサデータモジュール８０６の呼び出しに進む。データは、プロセスデータモジュール８０６によってたとえば、グルコースセンサ６０４（図７）などのセンサから収集され、生データとして分類される。センサ状態と共に、生データは、グルコース値および測定時間を決定するために、処理されて分析される。たとえば、プロセスは、最も信頼性がある正確なグルコース値を決定するために、過去のデータ集合および現在のデータ集合と、センサ状態などの他の情報および二次センサから外れ値を除去する必要がある。２つの処理機能のうちの１つは、生データを提供したセンサのタイプに応じて用いられる。
【０１４９】
第１の処理機能は、最も新しく入力されたグルコースデータ点を見つけて用いる。機能は、グルコース値の集合の位置決めに成功するまで、またはグルコースデータが尽きるまで、各制御サイクルを通じて逆行することによって、制御サイクルに関して利用可能な任意のグルコースデータを探索する。グルコースデータ集合が空である場合には、空のグルコースベクトルが返される。空でないグルコース集合の決定時には、長さＴcの時間ウィンドウが（ｔG−Ｔc，ｔG］と定義される。グルコース値の平均、
【数１２】
0005529307.tif 000018
が記録される。ｋ番目のサイクルに関するＫ番目の指数におけるグルコース値である。割り当てられるグルコースタイムスタンプｔG［Ｋ］は、選択された制御サイクルの終了時間である。図１１は、上記の変数を用いて、第１の処理機能の場合の時間間隔の選択をグラフによって示す。
【０１５０】
第２の処理機能は、現在のグルコースセンサの動作特性が、たとえば、皮下連続グルコースモニタによってデータ範囲などを提供する場合に用いられる。この実施例において、データ範囲は、２０ｍｇ／ｄＬの下限および４５０ｍｇ／ｄＬの上限を有する。この実施例において、他の可能なグルコース速度制限は、指定されていない。一実施形態において、センサは、データにゼロの値を割り当てることによって、範囲外の無効なグルコースデータを記録する。これらの無効なグルコース値
【数１３】
0005529307.tif 000019
は、プロセスセンサデータモジュール８０６によって生データから取り除かれるため、任意の定量分析には含まれない。一実施形態において、ポップアップメッセージが表示されて、上限および下限をユーザに警告する。
【０１５１】
ＥＡではグルコース値を計算するとき、一次センサデータのみが考慮される。最も新しく利用可能なグルコース値が、選択される。長さＴcの時間ウィンドウが（ｔ−Ｔc，ｔ1］と定義される。選択されたウィンドウにわたって利用可能なグルコース値が選択され、中央値が選択される。
【０１５２】
【数１４】
0005529307.tif 000020
ｋ番目のサイクルに関するＫ番目の指数におけるグルコース値である。時間に関する中央値が計算され、
【数１５】
0005529307.tif 000021
として返される。中央時間ｔG［Ｋ］は、必要に応じてＥＡ５１８による最も近い制御サイクルエッジに丸められるものとすることを留意されたい。図１２は、第２の処理機能の場合の時間間隔の選択を示す。
【０１５３】
グルコース更新
生データを収集して処理した後、ＥＡ５１８は、グルコース更新モジュール８０８の呼び出しに進む。グルコース更新は、グルコース利用可能性の態様およびＡＬＧＯ５１０の内部操作に対するその意味合いを説明する。これは、ＡＬＧＯ５１０の外側にいるエンドユーザには直接関係しない。最も新しいグルコース値を入手することは、血糖管理制御を維持するためにきわめて重要である。センサの遅延および／またはセンサ故障により、グルコース予測器は、現在のグルコースの推定量を得ることが必要とされる。センサが、新しいグルコース値を提供するとき、インスリン推奨モジュール８４６は、最も新しい測定グルコースを用いてグルコース予測を改訂する。しかし、新たなグルコース情報がない場合には、制御サイクル中に決定される予測グルコースは代わりに、現在のサイクルに関するグルコースを予測するために用いられる。この場合には、状態情報は、グルコースを予測するために、最後の制御サイクルから現在の新しいサイクルまで工程を進めるために効率的に用いられる。したがって、グルコース更新モジュール８０８は、グルコース測定の新しい集合が利用可能であるかどうかと、最後の予測グルコースを用いて続行するかどうかを特定する。
【０１５４】
自己ボーラス
ＥＡ５１８は、自己ボーラスコマンドに関するポンプからの情報にアクセスすることによって、任意のインスリン不一致を説明するために、自己ボーラスモジュール８１０を呼び出す。インスリンポンプへの物理的アクセスが必要とされる理由は複数あり、たとえば、バッテリの交換、インスリンチューブの交換または、ユーザがボーラスに手動で指示した場合などがある。この一態様は、任意の手動でのコマンドによるボーラスが、正味の投与されるインスリンに関して、各制御サイクルの開始で見られるものである。ＡＬＧＯ５１０は、手動でのコマンドによるボーラスを推奨しなかったため、ＥＡ５１８は、このボーラスを投与過多量と見なす。インスリンの決定された過多量は次に、説明され、未来の制御行為中のフィードバックによって、調整される。この事例を体系的に処理するために、自己ボーラスイベントは、手動ボーラス行為の前に誘発されなければならない。ＡＬＧＯ５１０は次に、入力された自己ボーラス量に等しい過多量を予測している。このイベントを用いることはまた、手動ボーラスのすべてを適切に説明することを保証する。未解明のボーラスは、コマンドによるボーラスからの残りである。未解明のボーラスは、自己ボーラス量が分解される必要がある有限の時間ウィンドウを有する。その量は、過多投与量で分解される。そうでない場合には、未解明のボーラス（すなわち、自己ボーラス量のバランス）は、ゼロに設定される。イベントを有限の持続時間に制限するための別の理由は、ユーザが過多量のテストスタンドを通知するが、ポンプからのボーラスを指示しない場合には、安全性予防措置としてメモリを消去することである。グルコースがない警告メッセージが、未解明の自己ボーラス量をゼロに設定する前に、ユーザにグルコース無しの注意書モジュール８１２によって表示される。
【０１５５】
期限切れのグルコース測定
生データを収集して処理し、適切であれば警告を送信した後で、ＥＡ５１８は、期限切れのグルコースモジュール８１４への呼び出しに進む。グルコース予測器の精度および信頼性が、予測の長さが増大するにつれて劣化する。受信された最後のグルコース値が、一定の特定の時間ウィンドウより古い場合には、ＡＬＧＯ５１０は、安全性予防措置として開ループＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００（図７）を実行し、予めプログラムされた基礎制御を実行する。Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００における操作によって、治療は、インスリンポンプの基礎プロファイルの中にプログラムされるものに制限され、必要に応じて、公開される機能性の部分集合によって増大される。期限切れのグルコースモジュール８１４の行為は、ポップアップメッセージによって保留中の期限切れのグルコース状態に関する情報を与えることである。期限切れのグルコース状態に達すると、期限切れのグルコースモジュール８１４は、Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００を実行するために、適切なフラグに切り替える。新たな一次グルコース測定を提供することは、事態を改善する。したがって、期限切れのグルコースは、グルコース予測がもはや妥当ではなく、制御装置をＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００に押し進めることを示す。
【０１５６】
以下の警告が、期限切れのグルコースモジュール８１４によって提供される。作業者への予備警告、作業者への警告およびグルコース測定の期限切れである。作業者への予備警告の場合には、ユーザは、ログウィンドウによって保留中の期限切れを予め警告される。期限切れ前のカウントダウン警告サイクルにおいて、ユーザは、期限切れの前にｎ分残っていることを反復的に通知される。さらに、以下のメッセージが現れる。「警告：グルコースがまもなく時間切れです。現在のグルコースを入力してください」。作業者への警告の場合には、ポップアップメッセージが、最後の期限切れ期間のサイクルおよび新たなグルコース測定が受信されるまでその後のサイクルごとに強制的に現れる。このメッセージは、「警告：グルコースが次のサイクルで時間切れになります。現在のグルコースを入力してください」と現れる。グルコース測定の期限切れの場合には、期限切れのグルコース状況中に、ＡＬＧＯ５１０が閉ループＰｕｒｅ−ｃｏｎｔｒｏｌモード６００にある場合には、ＡＬＧＯ５１０は、開ループＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００に強制的にして、ユーザの基礎インスリンプロファイルを実行する必要がある。また、このメッセージは、「警告：グルコースが時間切れです。Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓを実行してください。現在のグルコースを入力してください」と現れる。次に、ＥＡ５１８は、プロセスフロー点８１６に続けるために、収集および処理が行われたデータにおいて、十分なｂＧ測定があるかどうかを確認するために検証する。十分にない場合には、ＥＡは、プロセスフロー点８５０に進み、これについては後の節で説明される。その場合には、ＥＡ５１８は、不一致管理モジュール８１８に続く。
【０１５７】
予想結果と実際の結果との間の不一致の管理
不一致管理モジュール８１８は、ＥＡ５１８によって決定されたコマンドによるインスリンがポンプから投与されるインスリンと異なるかどうかを確認するために検証する。その場合には、ＥＡ５１８はこれにコマンドによるインスリン不一致というフラグを立て、ユーザインターフェイス５１２（図５）でユーザへの通知を提示する。不一致の原因が、ＡＰＴＳ５００（たとえば、無効化されたインスリンポンプ）とは無関係である傾向があるため、コマンドによるインスリンと投与されたインスリンとの間の不一致は次に、ユーザおよび／または医療従事者によって解明される必要がある。
【０１５８】
食事グルコース領域
ＥＡ５１８は次に、食事グルコース領域モジュール８２０に進む。この時点で、食事グルコース領域モジュール８２０は、線ではなく、帯としてグルコース目標を単に設定する。この帯は、閉ループＰｕｒｅ−ｃｏｎｔｒｏｌモード６００において、目標６０１としてＡＬＧＯ５１０によって用いられ、基礎制御装置６２８（図６）によって用いられる設定点６０３も提供する。行為入力として基礎制御装置６２８として用いられるグルコース予測器６２６は、食事によるグルコースの変化を説明していないことを認識すべきである。代わりに、食事は、所定のインスリン投与量分布によって取り上げられている。このインスリン投与量分布は、グルコース上昇を最もよく最小限に抑え、最小のアンダショットで、可能な限り迅速にグルコースを目標グルコースレベルにするために、決定される。食事摂取に対するグルコース上昇は、完全に排除することはできない。これは、ピークインスリン行為において約３０〜６０分の遅延があるため、予想される。得られたインスリン用量は、食事によるグルコース上昇を最小限に抑えるために最適化される。したがって、食事に関連する目標グルコース領域の帯は、上限および下限の目標グルコースによって境界が示される領域として、食事イベントに関して定義される。定義された目標領域に関して、図１３は、４つの異なるシナリオ、すなわち、（ａ）グルコース領域内、（ｂ）グルコース領域より上、（ｃ）グルコース領域より下および（ｄ）新しいグルコース値無しを示している。
【０１５９】
（ａ）グルコース領域内
予測グルコース値がグルコース領域範囲内にある場合には、被験者のグルコースは、許容可能な限度の中にあると考えられる。基礎制御装置６２８は、この場合には、血糖管理制御を維持するために、基礎インスリンのみを必要とする。
【０１６０】
（ｂ）グルコース領域より上
予測グルコース値がグルコース上限より上にある場合には、被験者は、インスリンにおける不十分な投与（under-delivered）として考えられる。基礎制御装置６２８は、グルコース上限に対してグルコースにおける偏差を計算する。基礎制御装置６２８の行為は、この偏差を説明し、この説明されていない上昇を抑制する。
【０１６１】
（ｃ）グルコース領域より下
予測グルコース値がグルコース下限より下にある場合には、被験者は、インスリンにおける過剰投与（over-delivered）として考えられる。基礎制御装置６２８は、グルコース下限に対してグルコースにおける偏差を計算する。基礎制御装置６２８の行為は、この偏差を説明し、この説明されていない降下を抑制する。
【０１６２】
（ｄ）グルコース更新なし
目標領域は、予想される食事に関連する応答の上昇および下降を対象とする。特殊な事例は、グルコースが更新されないときに生じる。グルコース測定における更新がない場合には、現在の制御サイクルＴcの場合の予測グルコースが、グルコースにおける食事に関連する上昇または下降を説明しないグルコース値である。しかし、目標領域範囲は、時間の関数である。これは一般に、予測グルコースが、食事開始時に低くなり、食事終了時に高くなることを意味する。この降下は、食事領域範囲の上昇および下降とは際立っている。ＥＡ５１８は、最後に受信されたグルコース測定によって最後に用いられた境界の限界を保持することによって、この事例を処理する。新たな測定が行われるまで、これらの上限および下限の目標値は、すべての未来の制御サイクルの場合に一定に保持される。これは、問題をある程度緩和する。
【０１６３】
準備運動および運動
次に、ＥＡ５１８は、運動モジュール８２２を介して患者が運動に参加しているかどうかを評価する。身体活動の増大レベルに関して、エネルギを維持するための要件もまた、増大する。エネルギ源であるグルコースは、増大した活動を支援するために、より高速で用いられる。したがって、生理的挙動の３つの仮定が、以下のように行われる。第１の仮定は、運動の開始時に、グルコースレベルに降下がある。第２の仮定は、グルコース降下が急速であり、物理的運動の開始および終了後、約１０分で始まって終わる。最後の仮定は、一旦、身体活動レベルが正常に戻ると、グルコースが筋肉および肝臓にグリコーゲンとして蓄えられるため、期待される回復期間にある。したがって、運動は、運動モジュール８２２および予備運動モジュール８２８によってそれぞれ段階的に処理される。
【０１６４】
ＥＡ５１８が、プロセスフローにおいて後に呼び出す準備運動モジュール８２８は、グルコースレベルが運動中に安全に減少することができるようにするために、グルコース設定点を上昇させることによって、運動を予想したグルコースを高める。したがって、運動を処理するための所定の正常な治療法は、運動を予想して、基礎インスリンを減少させることである。グルコースにおけるインスリンの減少の効果は、インスリンの薬力学に左右される。より低い基礎インスリンレベルが次に、運動の持続時間の間、維持される。さらに、グルコースレベルが、運動の開始時に十分に上昇していない場合には、被験者は、即効性の炭水化物の消費によって、自分のグルコースレベルを管理することができる。これは、グルコースレベルを急速に上昇させる。
【０１６５】
被験者は、ユーザインターフェイス５１２（図５）において提供されるリストから活動および／または活動レベルを選択することによって、準備運動イベントを誘発することによって、運動を準備する。選択された活動および／または活動レベルは、対応する予想グルコース降下を有する。運動イベントが誘発されるまで、目標グルコースにおける変化は、式（６）によって与えられる。
【０１６６】
【数１６】
0005529307.tif 000022
式中、ΔＧTは、目標グルコース値における変化であり、
【数１７】
0005529307.tif 000023
は、グルコース濃度において予想されるプッシュ（上昇）であり、運動はグルコースにおける降下を生じるため、運動の場合には、この値は負である。したがって、目標グルコース（すなわち、目標６０１）は、式（７）によって与えられる。
【０１６７】
ＧT＝ＧT＋ΔＧT                                              （７）
また、一旦、運動活動が始まると、身体は、より少ないインスリンを必要とする可能性があり、運動の持続時間に関してより低い基礎インスリン要件を維持する可能性がある。運動の終了時には、減少した基礎インスリンが、ある所定の段階的な方式で、正常な基礎設定まで戻す。
【０１６８】
運動を開始した後、運動期間モジュール８２２が、運動の持続時間の場合のグルコース降下を推定する。運動イベントが誘発されると、準備運動は、ＯＦＦになる。基礎状態は、運動イベントの開始時に再評価される。予備運動は、グルコースレベルを所望の量まで上昇しないため、被験者は、ユーザインターフェイス５１２（図５）で、上昇を補足するために、即効性の炭水化物を消費するようにＡＬＧＯ５１０によって促される。（「即効性の炭水化物」という名称の節で、以下で説明されるように）グルコースプッシュベクトルは、即効性の炭水化物の消費による成分を獲得する。身体活動によって生じた予想されるグルコース降下は、式（８）に基づいて表現される。
【０１６９】
【数１８】
0005529307.tif 000024
式中、
【数１９】
0005529307.tif 000025
は、必要とされる基礎インスリン（すなわち、グルコースプッシュ）を計算するために用いられる。
【０１７０】
【数２０】
0005529307.tif 000026
は、運動の場合には負の値であることを留意されたい。運動および即効性の炭水化物の効果は、正規化グルコース上昇応答曲線において、逆方向に移動するグルコースプッシュベクトルとしてモデル化される。
【０１７１】
運動後、運動モジュール８２２は、基礎設定要件により、基礎速度を徐々に正規化する運動回復期間を提供する。この実行において、運動の持続時間は、ベクトル
【数２１】
0005529307.tif 000027
によって予め定義される。一旦、運動が終わると、運動
【数２２】
0005529307.tif 000028
によるグルコースプッシュは、０となる。不連続性は、
【数２３】
0005529307.tif 000029
および
【数２４】
0005529307.tif 000030
を用いることによって滑らかになる。基礎設定からのインスリン基礎速度は、
【数２５】
0005529307.tif 000031
によって与えられる場合には、式（９）を用いて決定されることができる。
【０１７２】
【数２６】
0005529307.tif 000032
式中、
【数２７】
0005529307.tif 000033
は、運動が終了した時間であり、ｔは、現在の時間である。
【０１７３】
即効性の炭水化物
運動モジュール８２２が終了した後、ユーザインターフェイス５１２（図５）で患者に示された場合には、即効性の炭水化物の摂取によるグルコースプッシュベクトルへの更新を提供するために、ＥＡ８１５は次に、即効性の炭水化物モジュール８２４を呼び出す。グルコースプッシュベクトル
【数２８】
0005529307.tif 000034
は、予想グルコースプッシュプロファイルおよび相対グルコースプッシュプロファイルを用いて分析される。予想グルコースプッシュプロファイルは、予め定義されたグルコースプッシュベクトルであり、グラム当たり炭水化物摂取およびｍｇ／ｄＬ当たりの上昇で正規化される。相対グルコースプッシュベクトルは、正規化されたプッシュベクトル
【数２９】
0005529307.tif 000035
と、ＡηFC［ｇ］で消費される即効性の炭水化物の量、炭水化物グラム当たりの予想されるグルコース上昇
【数３０】
0005529307.tif 000036
の積である。したがって、グルコースプッシュベクトルは、式（１０）によって記述され、決定されることができる。
【０１７４】
【数３１】
0005529307.tif 000037
【０１７５】
低グルコース治療介入
次に、ＥＡ５１８は、グルコース値の上昇を正当化する状況を定義することによって、ユーザ安全性を維持する低グルコース治療介入モジュール８２６を呼び出す。タイムリーに許容可能な血糖管理範囲より上にグルコースレベルを維持するためにＡＬＧＯ５１０が不合格にしたときなどの低グルコース事態において、ＥＡ５１８は、このモジュールから提供された情報に基づいて治療介入する。この治療介入の目的は、即効性の炭水化物の摂取によって被験者を正常な血糖管理範囲に戻すことである。ＥＡが依然としてアクティブである場合には、ＡＬＧＯ５１０は、測定グルコースにおける増大を確認し、さらなるインスリンを推奨することによって、このグルコースプッシュを潜在的に無効にする必要がある。しかし、低グルコース治療介入モジュール８２６は、さらに慎重なインスリン推奨によってグルコースを上昇させることが可能である。
【０１７６】
一実施形態において、ＡLGは、グルコースレベルを下げるために必要とされる即効性の炭水化物の量として定義される。次に、予想されるグルコースプッシュは、式（１１）によって与えられる。
【０１７７】
【数３２】
0005529307.tif 000038
式中、
【数３３】
0005529307.tif 000039
は、即効性の炭水化物の摂取によるグルコースプッシュであり、ＡLGは、低グルコース治療介入のための即効性の炭水化物の量であり、
【数３４】
0005529307.tif 000040
は、炭水化物グラム当たりのグルコース上昇である。図１４は、即効性の炭水化物摂取の場合のグルコースプッシュをグラフによって示す。グルコース設定点Ｇspを予想される上昇
【数３５】
0005529307.tif 000041
に等しい量に修正することによって、ＡＬＧＯ５１０は、即効性の炭水化物の摂取によって生じる上昇を無効にしない。また、Ｇspは、最終的には元の設定点に戻される必要がある。設定点プッシュベクトルは、
【数３６】
0005529307.tif 000042
と線形に減少するゲインの項
【数３７】
0005529307.tif 000043
の積として定義され、式（１２）によって与えられる。
【０１７８】
【数３８】
0005529307.tif 000044
【０１７９】
したがって、設定点は、式（１３）に基づいて与えられる。
【０１８０】
【数３９】
0005529307.tif 000045
【０１８１】
図１５は、時間に関する相対的な設定点の変化をグラフによって示す。グルコースがあまり急速に上昇しない場合に、複数の低グルコース治療介入を生じることができることが考えられる。これはまた、複数の低グルコース治療介入イベントによるＧspの増加につながる。効果を加えるのではなく、低グルコース治療介入は、現在の低グルコース治療介入イベントに関する
【数４０】
0005529307.tif 000046
を追加する前に、最後の低グルコース治療介入の残りの立下り部分を除去する。そのような治療介入後、ＥＡ５１８は、準備運動モジュール８２８を呼び出す。準備運動モジュール８２８は、「準備運動および運動」という名称の前の節で上述したため、さらなる説明は提供しない。
【０１８２】
コマンドによるボーラス
ＥＡ５１８は、ユーザがＡＰＳ５００によってインスリンＡCBのさらなるボーラスを投与することをポンプに指示するとき、コマンドによるボーラスモジュール８３０を用いる。しかし、ＥＡ５１８は、制御モードのそれぞれでは異なるように、ＡＬＧＯ５１０を介してコマンドによるボーラスイベントを認識して実行する。閉ループＰｕｒｅ−ｃｏｎｔｒｏｌモード６００（図６）の場合には、コマンドによるボーラスイベントは、インスリンの早期投与を強制的に行うことができ、したがって、インスリン推奨の未来の分布を修正することができる。さらに、Ｐｕｒｅ−ｃｏｎｔｒｏｌモード６００にあるときには、コマンドによるボーラスＡCBが、過剰であり、目標グルコースを達成するために必要とされる必要インスリン量を上回る。したがって、未来の制御サイクルに関して、ＥＡ５１８は、ＡCBを考慮して、その結果、推奨を調整する。開ループＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００（図７）の場合には、コマンドによるボーラスモジュール８３０は、たとえば、食事摂取および高血糖レベルなどのイベントを取り上げるために、ユーザインターフェイス５１２（図５）を介してボーラスを入力することによって、Ｃｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００中に、被験者が個別の治療を管理することを可能にする。
【０１８３】
高グルコース治療介入
高グルコース治療介入モジュール８３２は、ＥＡ５１８が高血糖の状態を補正することを可能にする。ユーザが、ユーザインターフェイス５１２（図５）を介して高グルコース治療介入イベントとして補正量ＡHGを入力する。２つの制御モード６００および７００は、それぞれのモードによって生成される推奨に加えて治療介入量を投与する。コマンドによるボーラスは、「ＡＬＧＯによって確認される」インスリンであるのに対して、高グルコース治療介入イベントを取り上げるために投与されるインスリンは、「ＡＬＧＯによって確認されない」。閉ループＰｕｒｅ−ｃｏｎｔｒｏｌモード６００において、ＡＬＧＯ５１０のフィードバック部分は、インスリン治療介入の量を認識しない。インスリン無効化モジュール８３６（後の節において以下で説明される）高グルコース治療介入に関連するインスリンの量を除去する。これは、フィードバックが未来の制御行為からインスリンの量を減少させないことを意味する。開ループＣｏｎｔｒｏｌｌｅｄ−Ｏｂｓモード７００において、高グルコースレベルの場合の治療介入量は、正味のインスリン推奨を提供するために、開ループ推奨と共に合計される。
【０１８４】
炭水化物修正：最後の食事摂取の改訂
被験者が、ＡMグラムの炭水化物の食事の消費をＡＬＧＯ５１０に示した後、入力された量が、複数の潜在的な理由の１つにより、訂正されなければならない可能性がある場合が存在する。これらの理由としては、計算間違い／前の項目の間違い、被験者が当初の予想ほど多く消費できなかった（または予想より多く消費された）、食品の消費がさらに長時間にわたって伸び、したがって治療を再度送り込む必要がある、極端な事例では、食事の中止が挙げられる。上記の理由を念頭において、ＥＡ５１８は、炭水化物修正モジュール８３４を呼び出し、以下の状況下で実行する。第一に、時間ｔMで量ＡMの食事イベントが存在しなければならない。第二に、時間ｔMCおよび量
【数４１】
0005529307.tif 000047
の食事補正イベントが、ユーザによって入力された。別の実施形態において、食事イベントは、
【数４２】
0005529307.tif 000048
が残っている食事として定義される。いずれの状況も満たされる場合には、式（１４）の以下のさらなる状況が満たされるのであれば、インスリン量および分布に対する補正が行われる。
【０１８５】
【数４３】
0005529307.tif 000049
式中、ＴCMは、分単位の時間であり、最後の食事項目を補正するための許容された時間ウィンドウであり、
【数４４】
0005529307.tif 000050
である（食事が残っている事例の場合のみ）。上記の最後の状況が満たされる場合には、炭水化物修正モジュール８３４がさらに実行され、そうでない場合には、モジュールは、何の行為も行わず、ＥＡ５１８に返す。
【０１８６】
さらなる処理において、モジュール８３４は、時間ｔMでＡMに関して得られたインスリン分布を、新たな食事量
【数４５】
0005529307.tif 000051
に関して計算された新たなインスリン分布によって置き換える。分布は、時間ｔMに対して実行され、ｔMCに対しては実行されない。食事が残っている事例
【数４６】
0005529307.tif 000052
の場合には、
【数４７】
0005529307.tif 000053
は、式（１５）によって与えられる。
【０１８７】
【数４８】
0005529307.tif 000054
【０１８８】
モジュール８３４は、（ａ）起こった時間および（ｂ）量に対して生じる最後の食事イベントを特定する。仮定１および２が満たされる場合には、モジュールの計算は、以下のようになる。
【０１８９】
【数４９】
0005529307.tif 000055
の場合には、インスリン分布を求める。最後の食事が生じた時間に分布を時間シフトする。ＡMの場合には、インスリン分布を求める。最後の食事が生じた時間に分布を時間シフトする。対応する時間勾配から以下の操作が行われる。食事に関連するボーラスベクトルから、
【数５０】
0005529307.tif 000056
に関連するインスリン分布を減算し、ＡM分布を加算する。内部ボーラスイベントベクトルから、
【数５１】
0005529307.tif 000057
に関連するインスリン分布を減算し、ＡM分布を加算する。炭水化物修正モジュール８３４のこの追加処理が、図１６に示される実施例によってさらに明確にされ、以下で説明される。
【０１９０】
食事は、食事イベントであり、食事補正は、炭水化物修正モジュール８３４によって行われるイベントである。提供された実施例において、時間ｔM＝４９５で、１００ｇの食事イベントが、入力され、インスリン分布として［２  ０  ５  ０  ０  ３  ０  ０  ２］を必要とする。ｔ＝５２５までの食事に関連するボーラスが、［３  １  ５］であり、内部ボーラスイベントが［０  ０  ３  ０  ０  ２］である。食事に関連するボーラスは、たとえば、前の食事から生じるさらなるインスリン寄与があることを示している。その存在は、重要であり、現在の問題では、寄与がどこからやってくるかは重要ではない。ｔMC＝５２５で、食事に対する補正が入力される。情報はここで、ｔM＝４９５での１００ｇの食事項目の場合には、工程１および２が終わるまでに６０ｇのみが実際に消費されたことである。したがって、工程３において、モジュール８３４は、６０ｇの場合のインスリンを最初に決定し、工程４において、［１．５  ０  ３  ０  ０  ２  ０  ０  ０  １．５］である。１００ｇの場合の分布が工程５においてどのようであるかをＡＬＧＯ５１０が覚えていないため、工程６において、１００ｇの場合には、［２  ０  ５  ０  ０  ３  ０  ０  ２］として再計算された。両方のベクトル（６０ｇおよび１００ｇ）は、工程７において（矢印によって示されるように）ｔ＝５００にシフトされ、食事に関連するボーラスおよび内部ボーラスイベントの両方が、工程８および９において再計算される。
【０１９１】
炭水化物修正が適用可能でない場合には、以下のポップアップメッセージが、ユーザインターフェイス５１２（図５）に表示される。「警告：食事補正が適用されない」。炭水化物修正が適用可能である場合には、（入力される量に応じて）以下のポップアップメッセージのうちの１つが表示される。「警告：（ｈｈ：ｍｍ）で入力された（数量）ｇの食事は今、（数量）ｇに補正される」「警告：残っている食事は、（数量）ｇ〜（数量）ｇの間でなければならない」
【０１９２】
インスリン無効化
炭水化物修正モジュール８３４の後、ＥＡ５１８は、インスリン無効化モジュール８３６を呼び出す。上述したように、インスリン無効化モジュール８３６は、最後に投与されたインスリン、すなわち、サイクルで分散されたインスリンの量からフィードフォーワードインスリン成分を無効にする。最後のインスリン放出は、たとえば、自己ボーラスコマンド、食事に関連するボーラスおよびフィードバック成分などのＥＡのフィードフォーワードモジュールのすべてから生じるインスリン全量である。インスリン無効化は、最後のインスリン放出から任意のフィードフォーワードインスリン量を除去する。ＥＡ５１８の現在の実行は、種々のフィードフォーワードインスリン成分を個別に管理する。インスリン無効化は、実際に、フィードフォーワードインスリン成分のすべてを除去したことを示唆する。正しいインスリンフィードバック推奨を得るためには、すべてのフィードフォーワード成分が正しく除去されることが必須である。インスリン無効化ベクトル
【数５２】
0005529307.tif 000058
は、式（１６）によって与えられる。
【０１９３】
【数５３】
0005529307.tif 000059
式中、
【数５４】
0005529307.tif 000060
は、投与されるインスリンベクトルであり、
【数５５】
0005529307.tif 000061
は、食事に関連するボーラスおよび高グルコース治療介入ボーラスであり、
【数５６】
0005529307.tif 000062
は、自己ボーラスおよびプライミング、フィードフォーワード成分に関連するボーラスである。過去の値がポンプ投与データにおいて利用可能でない場合には、過去の情報は、基礎インスリン投与量で満たされることを留意されたい。
【０１９４】
グルコース予測および基礎制御行為
次に、ＥＡ５１８は、グルコース予測モジュール８３８を呼び出す。センサは、物理的ラグおよびプロセスラグを有するため、ＡＰＴＳによって収集されたグルコース測定は、遅延測定である。未来に対する正確なグルコース予測は、血糖管理制御を提供するために重要である。グルコース予測モジュール８３８は、過去のインスリン放出情報、グルコース測定およびインスリン薬力学を用いて、予測を行う。図１７は、インスリン残留薬力学を示す。実行するために、単位ボーラスに関して残っているインスリンの薬力学は、ｓｕｂｊｅｃｔ．ｉｎｉファイルで定義され、ここでは、
【数５７】
0005529307.tif 000063
によって与えられる。図示されているように、単位インスリンインパルス応答に関する薬力学は、ＴC＝１０分である。
【０１９５】
基礎制御装置６２８の基礎部分は、グルコース予測に用いられる原理と類似の原理に基づいている。根本的な原理は、グルコースレベルにおける変化が、基礎制御装置６２８（図６）が補正するモデル化されていないプラントの障害によることである。インスリンボーラスに対する調整は、予測グルコースを考慮する。グルコース予測器６２６および基礎制御を提供する設定点６０３からの出力は、基礎制御装置６２８のフィードバック部分を共に形成する。要約すると、閉ループフィードバック推奨の計算は、（ａ）最近の予測グルコース値および（ｂ）投与されたインスリンの履歴を必要とする。
【０１９６】
現在の時間におけるグルコースを予測するために、グルコース予測モジュール８３８は、以下の情報を用いる。処理されたグルコース値Ｇ［Ｋ］および対応する処理時間ｔG［Ｋ］、ｊに対して最後のＴD分にわたって無効化されたインスリンの情報
【数５８】
0005529307.tif 000064
式中、ＴDは、インスリンの効果の持続時間である。Ｔcが制御期間である場合には、ＴD＝ｎＴcである。インスリン薬力学
【数５９】
0005529307.tif 000065
を得る。グルコース降下が、利用されるインスリンに直接比例すると仮定すると
【数６０】
0005529307.tif 000066
であり、式中、ｉ＝１，２，・・・，ｎである。単位ボーラスに関して利用されるインスリン
【数６１】
0005529307.tif 000067
は、ベクトル
【数６２】
0005529307.tif 000068
で行われる前方差分として得られる。ベクトル
【数６３】
0005529307.tif 000069
は、式（１７）によって与えられる。
【０１９７】
【数６４】
0005529307.tif 000070
図１８は、単位ボーラスの時間に関する利用インスリン
【数６５】
0005529307.tif 000071
に対する変化をグラフによって示す。比例定数がＫI、インスリン感受性［ｍｇ／ｄＬ／Ｕ］である場合には、インスリン利用によるグルコース降下は、式（１８）として定義される。
【０１９８】
【数６６】
0005529307.tif 000072
【０１９９】
グルコース降下ベクトルは、式（１９）として定義される。
【０２００】
【数６７】
0005529307.tif 000073
【０２０１】
時間ｊにおけるグルコース降下を予測するために、最新のグルコース測定Ｇ［Ｋ］を与え、Ｋは、グルコース値が現在利用可能である時間であるとすると、
【数６８】
0005529307.tif 000074
として式（２０）によって定義される
【数６９】
0005529307.tif 000075
と無効化されるインスリンボーラスベクトル
【数７０】
0005529307.tif 000076
の畳み込み演算によって与えられる。
【０２０２】
式中、
【数７１】
0005529307.tif 000077
は、点ｊに対して最後のｎ回に投与されるインスリン量のベクトルであり、ｊ番目の瞬間におけるグルコース降下ΔＧ［ｊ］、ｊ＝Ｋ＋１，・・・，ｋサイクルである。図１９は、インスリンインパルス予測をグラフによって示す。グルコース予測モジュール８３８は、式（２０）を用いてある瞬間ｊのグルコースを予測する。ｋにおけるグルコースの予測は、Ｋ＋１からｋまでのｊを段階的に行うことによって行われる。グルコース予測は、３つの部分、すなわち、（ａ）投与される基礎インスリン、（ｂ）予め定義される基礎インスリンおよび（ｃ）グルコース予測から計算される。
【０２０３】
（ａ）投与される基礎インスリン
投与される基礎インスリンのベクトル
【数７２】
0005529307.tif 000078
は、無効化されるインスリン放出である。予想されるグルコース降下ΔＧN［ｊ］は、
【数７３】
0005529307.tif 000079
として式（２１）によって定義される。
【０２０４】
（ｂ）予め定義される基礎インスリン
予め定義される基礎インスリンは、基礎設定から決定され、障害のないシナリオを用いて「基礎インスリンとなる」値
【数７４】
0005529307.tif 000080
である。これは、目標グルコースＧTを維持するために必要な基礎インスリン成分である。予想されるグルコース降下ΔＧBは、
【数７５】
0005529307.tif 000081
として式（２２）によって定義される内積によって与えられる。
【０２０５】
（ｃ）グルコース予測
次に、ｊ番目の工程におけるグルコース値Ｇ［ｊ］が与えられると、予測グルコースＧ［ｊ＋１］は、
【数７６】
0005529307.tif 000082
として式（２３）によって与えられる。式（２３）
式中、ΔＧp［ｊ＋１］は、周知の障害から推定されるグルコースプッシュである。グルコース予測は次に、時間ｔkにおける最後の周知のグルコース値から現在の時間ｔkまでに前進して行われる。ＥＡ５１８は次に、食事補償器モジュール８４０に進む。
【０２０６】
食事補償器
食事補償器モジュール８４０は、呼び出されるときは炭水化物の摂取に関係している。蛋白質および脂肪は、等価な炭水化物の量に変換される。食事タイプは、時刻のほか、炭水化物摂取のサイズに関連付けられる。種々の食事タイプの定義が、表５に列挙される。
【０２０７】
【表５】
0005529307.tif 000083
【０２０８】
腸のグルコース吸収の速度（すなわち、食事の速度）に影響を及ぼす因子の１つが、食事成分であることは認識されている。食事の速度は、食事量選択を間接的に説明している。制御サイクルにおいて、複数の食事イベントが誘発される場合には、ＥＡ５１８は、最後の食事項目のみを考慮する。食事を取り上げるために送り込まれるインスリンボーラスについては、実行の節で記載される。大量の食事は必ずしも、複数の少量の食事の和に等しいわけではない。食事計画において、たとえば、少量の食事＝２５ｇ、正規の食事＝５０ｇおよび大量の食事＝７５ｇと定義されることができる。現在の基礎インスリンが相対的であり、食事が誘発されるとすると、設定点は、ＦａｓｔＣａｒｂプロファイルを用いて調整される。グルコースは、即効性の炭水化物のような動的なものの食事プッシュのために急激に上昇し、インスリン薬力学のようにゆっくりではないと予想される。
【０２０９】
食事注意書
次に、ＥＡ５１８は、被験者に食事の開始を通知するポップアップダイアローグボックスを提供するために、適宜、食事注意書モジュール８４２を呼び出す。食事注意書のポップアップが表示される場合には、食事注意書モジュール８４２を制御するフラグが、基礎制御装置６２８によって設定される。
【０２１０】
内部ボーラス管理
さらに、食事イベントから生じるフィードフォーワードボーラスを供給するために、適宜、ＥＡ５１８は、内部ボーラス管理８４４を呼び出す。
【０２１１】
インスリン推奨
後に、上述したように、現在の予測グルコース値を用いてインスリン投与量を計算するために、ＥＡ５１８は、インスリン推奨モジュール８４６を呼び出す。特に、インスリン投与量に関するインスリン推奨は、ボード上のインスリンの効果、未来の基礎入力および入力される他のイベントの効果を投影することによって計算される。以下の工程は、基礎インスリン推奨、すなわち、（ａ）現在のグルコース、（ｂ）投与される基礎摂動インスリン、（ｃ）グルコース設定点、（ｄ）予め定義される基礎インスリンおよび（ｅ）グルコースプッシュを決定する。
【０２１２】
（ａ）現在のグルコース
現在のグルコースは、予測グルコースの節から決定され、Ｇ［ｋ］によって与えられる。
【０２１３】
（ｂ）投与される基礎摂動インスリン
この
【数７７】
0005529307.tif 000084
ペクトルは、無効化されるインスリン放出である。次に、残っていると推定されるインスリンは、
【数７８】
0005529307.tif 000085
として式（２４）によって与えられる。
【０２１４】
（ｃ）グルコース設定点
これは、目標グルコースであり、ＧTによって与えられる。
【０２１５】
（ｄ）予め定義される基礎インスリン
これは、基礎設定から決定され、「基礎インスリンとなる」値
【数７９】
0005529307.tif 000086
である。これは、目標グルコースＧTを維持するために必要とされる基礎インスリン成分である。残っていると予想されるインスリン
【数８０】
0005529307.tif 000087
は、
【数８１】
0005529307.tif 000088
として式（２５）によって定義される内積によって与えられる。
【０２１６】
（ｅ）グルコースプッシュ
グルコースプッシュは、ΔＧpによって与えられる。したがって、インスリン推奨は次に、
【数８２】
0005529307.tif 000089
として式（２６）によって定義されるＩreqによって与えられ、式中、Ｇestimateは、
【数８３】
0005529307.tif 000090
として式（２７）によって与えられ、工程（ａ）〜（ｅ）を考慮することによって決定される。
【０２１７】
インスリン推奨を修正する以下の事例は、目標領域および最小基礎要件を満たすグルコースである。前の節において上述したように、目標領域（すなわち、目標６０１）は、単に１つの点ではなく、下および上の設定点の範囲を有する設定領域として定義される。たとえば、
【数８４】
0005529307.tif 000091
はそれぞれ、上の設定点および下の設定点を定義する。推定されるグルコースＧestimateが目標領域内にある場合には、Ｉreqは、単なる基礎インスリンである。最小基礎要件の事例では、Ｉreqが負であるとき、被験者は現在、インスリン過剰投与の状態にあるとＥＡ５１８は予測した。最小基礎速度（通常、基礎速度の２分の１）は、そのような過剰投与状況中で、ＡＬＧＯ５１０によって実行される。循環するインスリン濃度は、カウンタ調整を回避するために、閾値未満に下降しないことが重要である。最小基礎速度を強制することにより、最小循環インスリンレベルを保証する。
【０２１８】
インスリンバケット
ＥＡ５１８がインスリンバケットモジュール８４８を呼び出すとき、最終的なインスリン推奨は、誘発される種々のイベントによる基礎制御要件および開ループインスリン要件の組み合わせから構成される。さらに、たとえば、送り込み上限の制約条件と呼ばれる各制御サイクルに関するインスリン量の上限などの最終的なインスリン推奨に課せられる制約条件がある。最後に、インスリン推奨は、実行されなくてもよい。たとえば、医療従事者が、推奨の許容または拒否を行う最終的な権限者である場合である。最終的なインスリン放出は、実際の送り込みである。したがって、インスリン記録維持成分は、種々のインスリンバケットにおいて提示され、推奨の制約条件に適合しなければならない。最終的なインスリン推奨が、最終的なインスリン放出とは異なる場合には、ＡＬＧＯ５１０は、その結果、改訂された最終的なインスリン放出を再評価して、成分を再度検討する。
【０２１９】
プロセス点８５０で、ＥＡ５１８は、開ループＰｕｒｅ−ｃｏｎｔｒｏｌ６００が有効であるかどうか、（プロセス点８１６から再度入る点である）十分でないｂＧ測定フラグが設定されていないかどうか、またはｂＧの時間切れフラグが設定されていないかどうかを決定する。任意のそのような状況が偽である場合には、ＥＡ５１８は、この制御サイクルから値および状況を保存するために、更新格納モジュール８５４を呼び出す。状況のいずれかが真である場合には、ＥＡ５１８は、不一致管理モジュール８１８、コマンドによるボーラスモデル８３０、高ｂＧ治療介入モジュール８３２、最終的なインスリン推奨に制約条件を課す送り込み上限制約条件モジュール８５２を呼び出す。これらの呼び出しの終了で、ＥＡ５１８は次に、この制御サイクルから値および状況を保存するために、更新格納モジュール８５４を呼び出す。ＥＡ５１８は次に、図８および図９に示され、上述したプロセスフローを再起動する前に、ＡＬＧＯ５１０の次の制御サイクルの開始まで待機する。
【０２２０】
ＡＬＧＯＳＨＥＬＬ
ＡＬＧＯＳＨＥＬＬ５０６は、データ構造管理と、システムフォルダに位置する関連マクロと、を提供する。特に、ＡＬＧＯＳＨＥＬＬ５０６は、ＡＰＳ５００から呼び出される所与の入力に対する出力を生成する関数である。ＡＬＧＯＳＨＥＬＬ５０６関数はまた、シミュレーション（Simulink）環境で実行するＡＰＳｅによって機能する。上述したように、ＡＰＳテストスタンド環境は、非Ｓｉｍｕｌｉｎｋ環境であり、ＡＰＳｅは、ＡＰＳテストスタンド環境をシミュレートするラッパ関数である。ＡＬＧＯＳＨＥＬＬ５０６は、シミュレーション環境において、ＡＰＳ、実時間のテストスタンドおよびＡＰＳｅとインターフェイスをとる。標準化されたＡＬＧＯＳＨＥＬＬ５０６呼び出しは、以下の通りである。［ｙＡＭＴ、ｙＡｄｖｉｃｅ、ｙＴｒａｃｅ、ｘｋ’］＝ＡＬＧＯＳＨＥＬＬ＿ｘｘｘ（t, xk u, EventStruc, ExperimentStrue, PumpStruc, BGStruc, PatientlniStruc）である。図３３は、変数がＡＬＧＯ５１０に関して更新されるときを示す。ＡＬＧＯＳＨＥＬＬ５０６呼び出しの入力変数ｔ、ｘｋ  ｕ、ＥｖｅｎｔＳｔｒｕｃ、ＥｘｐｅｒｉｍｅｎｔＳｔｒｕｅ、ＰｕｍｐＳｔｒｕｃ、ＢＧＳｔｒｕｃ、ＰａｔｉｅｎｔｌｎｉＳｔｒｕｃが、以下で最初に説明され、出力変数ｙＡＭＴ、ｙＡｄｖｉｃｅ、ｙＴｒａｃｅおよびｘｋ’へと続く。
【０２２１】
入力変数
項ｔは、経過時間またはシミュレーション時間に関する時間スカラである。時間ｔは、Ｓｙｎｃ１呼び出しの場合にＴＣｏｎｔｒｏｌ＋／−Δ時間の倍数であると予想され、現在の制御サイクルエッジとして定義される。Ｓｙｎｃ２呼び出しは、Ｓｙｎｃ１に続き、次の制御サイクルエッジの前に生じる。項ｘｋは、ｓｔａｔｅｓと呼ばれるＡＬＧＯＳＨＥＬＬによって必要とされる変数の集合を含む状態ベクトルである。ＡＰＳｅにおいて、これらは、個別の状態の更新を制御によって維持される個別の状態である。ＡＰＳｅが呼び出されるとき、ｘｋは、状態として利用可能である。他方、ＡＰＳは常に、制御状態にあり、ｘｋを維持する役割を担っている。ベクトルｘｋの長さおよび比は、ＡＬＧＯに依存している。ＡＰＳは、ｘｋの長さまたは比を知る必要はない。変数ｘｋは、ＡＰＳによって行列［  ］を空にするために初期化される必要がある。ＡＬＧＯＳＨＥＬＬ５０６は次に、最初に呼び出されたときに、その正しい長さを決定する。次から、実験で、ｘｋの長さを維持する必要がある。ＡＰＳ／ＡＰＳｅは、ｘｋの値または長さを修正する必要はない。項ｕは、入力ベクトルであり、フィールドデバイス、すなわち、ポンプおよびセンサによって出力される情報からなる。ＡＰＳおよびＡＰＳｅはいずれも、入力ベクトルｕの詳細を知る必要がある。詳細に関しては、表６を参照されたい。「正味の投与されるインスリン」は、ポンプによって投与されるインスリンの総量に関する累積カウンタであることを留意されたい。
【０２２２】
【表６】
0005529307.tif 000092
【０２２３】
ＥｖｅｎｔＳｔｒｕｃ−イベント構造
これは、所定の誘発スケジュールを含む構造である。パラメータの１つとしてＡＰＳｅに利用可能である。他方、ＡＰＳは、スケジュールを得てＡＰＳメインウィンドウ９０２から誘発されたイベントからＥｖｅｎｔＳｔｒｕｃを更新する。イベント構造フィールドに関して表７を参照されたい。
【０２２４】
【表７】
0005529307.tif 000093
【０２２５】
表７において提供されるフィールドＰａｔｉｅｎｔｌｎｉＳｔｒｕｃ．ｅｖｅｎｔｓ．ｕｎｉｔｓは、ＡＰＳ  ＧＵＩによって表示されるイベント単位の配列である。ＥｖｅｎｔＳｔｒｕｃにおけるフィールドのそれぞれは、行配列である。行配列のすべては、同一の長さからなる。特定の列が情報を有していない場合には、非数が入力され、列の長さが維持される。ＡＰＳにおいて、イベントが記録されるとき、ＥｖｅｎｔＳｔｒｕｃが更新される。ＡＰＳｅにおいて、ＥｖｅｎｔＳｔｒｕｃは、前から存在する。イベントのすべてが、実行前にスケジュール化される。本質的に、実行には差がない。ＡＬＧＯＳＨＥＬＬ５０６は、現在のシミュレーション時間以下である登録されたイベントのみを確認する。誘発時間または制御装置応答時間の少なくとも１つは、有意のイベントとしてイベントを許容するために、ＡＬＧＯ５１０に関して非ゼロである必要がある。時間がまったく入力されない場合には、ＡＬＧＯ５１０は、具体的なイベントが生じて無視するときを判断することができない。ｅｖｅｎｔ＿ｔｙｐｅ項目は、「ｐａｔｉｅｎｔｉｎｉ．ｅｖｅｎｔｓ」構造によって列挙される項目であり、ｔｙｐｅ、ｕｎｉｔｓおよびＩｎｔｅｒｎａｌＮａｍｅのフィールドを有する。これらは、実験ごとに変化することができる。イベントは、２種類からなり、たとえば、それのみを記録目的のためだけに用いられるイベント、たとえば、採血イベントおよびＡＬＧＯ５１０にイベントを考慮してイベントに適切に反応するように通知するイベント、たとえば、食事である。
【０２２６】
ＥｘｐｅｒｉｍｅｎｔＳｔｒｕｃ−実験構造
これは、予め定義され、ＡＰＳｅパラメータを介してＡＰＳｅに対して利用可能である構造である。ＡＰＳは、実験実行のために実験構造を読み込む。実験構造フィールドに関しては、表８を参照されたい。
【０２２７】
【表８】
0005529307.tif 000094
【０２２８】
ＰｕｍｐＳｔｒｕｃ−ポンプ構造
データフィールド以外は、この構造のすべてのフィールドは、予め定義され、ＡＰＣＡＴＳ９００のユーザインターフェイスから獲得される。この構造は最初にパラメータとして供給される。初期化ステージにおいて、ＰｕｍｐＳｔｒｕｃは、ｍａｔファイルになる。ＡＰＳは、類似の設定を有する。表９において本願明細書で用いられるとき、「オフライン」なる語は、ポンプがＡＰＳＣＯＭ５０４からの最後の状況情報につき利用可能でない場合に生じる状況を意味する。ポンプ構造フィールド構造に関しては、表９を参照されたい。
【０２２９】
【表９】
0005529307.tif 000095
0005529307.tif 000096
【０２３０】
ＢＧＳｔｒｕｃ−血糖構造
データフィールドｂｇ１ｄａｔａおよびｂｇ１ｔｉｍｅｓｔａｍｐ以外は、この構造のすべてのフィールドは、予め定義され、ＡＰＣＡＴＳ９００のユーザインターフェイスから獲得される。この構造は最初にパラメータとして供給される。センサには、０、１、２、３・・・の番号が付けられ、センサ１は、仮想センサと見なされる。表１０は、センサ１に関するセンサ構造フィールドを与える。他のセンサの番号に関して、フィールドのそれぞれにおける「１」は、センサ番号によって置き換えられる。４までのセンサが、サポートされ、２個のＳＵセンサ、１個の外部センサおよび１個の仮想センサである。しかし、ＡＰＳ−３の場合には、センサに関して、以下のマッピングが行われる。０には「ＥＸＴ（外部）」、１には「ＳＵ１」および２には「ＳＵ２」である。
【０２３１】
【表１０】
0005529307.tif 000097
【０２３２】
ＰａｔｉｅｎｔｌｎｉＳｔｒｕｃ−患者初期化構造
この構造は、初期化ファイル（ＩＮＩ−ファイル）で定義され、食事摂取およびインスリン低下に対する各患者に固有の応答ベクトルを含む。ＩＮＩ−ファイルは、ＡＰＴＳ５００およびＡＬＧＯ５１０に研究特有のパラメータおよび被験者特有のパラメータを提供する。アルゴリズムパラメータ、１回投与量の自動確認、３回投与量の承認閾値およびＥｖｅｎｔ  Ｔｙｐｅをはじめとする被験者特有のデータを含むＡＰＳが、起動されると、Ｓｕｂｊｅｃｔ  ＩＮＩファイルが読み込まれる。Ｅｖｅｎｔ  Ｔｙｐｅは、上記で説明したように、ドロップダウンリストを通じて医療従事者による実験中に手動で選択されることができる活動である。共通のＥｖｅｎｔ  Ｔｙｐｅとしては、食事および外部血糖（ｂＧ）測定計の読み出しがあげられる。ドロップダウンリストの値は、Ｓｕｂｊｅｃｔ  ＩＮＩファイルによって決定される。Ｃｏｎｓｅｃｕｔｉｖｅ−Ｄｏｓｅ  Ｔｈｒｅｓｈｏｌｄは、Ｓｕｂｊｅｃｔ  ＩＮＩファイルにおいて表されるように、医療従事者の承認なしで、３回の連続サイクルにおいて投与されるインスリンの最大量である。Ａｕｔｏ−ｃｏｎｆｉｒｍ閾値は、Ｓｕｂｊｅｃｔ  ＩＮＩファイルにおいて表されるように、医療従事者の承認なしで、１回のサイクルにおいて投与されるインスリンの最大量である。実験は、任意の中間再起動およびＩＮＩ−Ｆｉｌｅにおける変更をはじめとするＡＰＴＳのはじめから終わりまでに収集されるデータである。Ｓｕｂｊｅｃｔ  ＩＮＩファイルにおいて提供されるフィールドのフィールド記述に関しては、表１１を参照されたい。
【０２３３】
【表１１】
0005529307.tif 000098
【０２３４】
出力変数
項ｙＡＭＴは、ポンプおよびディスプレイコマンドベクトルであり、ポンプに関するコマンドを含む。表１２は、コマンドベクトルｙＡＭＴに含まれるコマンドに関する詳細を提供する。
【０２３５】
【表１２】
0005529307.tif 000099
【０２３６】
項ｙＡｄｖｉｃｅは、警告およびＡＬＧＯによってフラグを立てられたが、ＡＰＳによって実行される他の考えられるフェイルセーフ基準を提供する注意書の文字列である。ｙＡｄｖｉｓｏｒｙの文字列は、２桁の注意書きの数字、続いてスペース、続いて命令文となる。注意書の数字は、３つのカテゴリに分類される。（１）名目上（範囲：００〜０９）、（２）ポップアップメッセージウィンドウ（範囲：１０〜９８）および（３）終了／中止（範囲９９）である。項ｙＴｒａｃｅは、ＡＬＧＯ実行の工程を追跡する追跡文字列である。ＡＬＧＯの進行は、ＥｘｐｅｒｉｍｅｎｔＳｔｒｕｃファイルに定義されるＤａｔａＰａｔｈに位置するログファイルに記録される。ｘｋ’は、次のＡＬＧＯ呼び出しでＡＬＧＯの起動のために必要とされる状態ベクトルである。
【０２３７】
制御サイクルの分割
同期化された呼び出しを含む推奨モードの場合には、ユーザ承認ウィンドウ、非同期化された呼び出しの場合には、各コマンドによる値が、制御期間の残りの部分でポンプが投与することができる量に制限される。承認ウィンドウは、コマンドによるインスリンの最終的な承認を要求し、医療従事者がインスリン推奨を手動で許容または拒否するときに現れるダイアローグボックスである。例示の実施形態において、このウィンドウは、４５秒経つと時間切れになる。したがって、制御期間は、図３４に示されているように、３つの領域に分割され、ＡＬＧＯＳＨＥＬＬにおけるパラメータが、表１３に列挙される。理想的な事例における各制御サイクルは、制御サイクルの始まりでＡＬＧＯが呼び出されることを可能にする。ＡＬＧＯは、入力を処理し、制御サイクルの残りの部分で投与される量を推奨する。しかし、（１）各行為が有限の時間で行われるため、（２）内部時間クロックが個別であるために、ハードウェア制限がある。さらに、開ループ制御の場合には、人間の治療介入があり、制御行為に関して残った実際の時間には変動がある。これらの検討事項のすべてを考慮した後で、全体でコマンドの送り出しを可能にするコマンドによる値が、決定される。
【０２３８】
【表１３】
0005529307.tif 000100
【０２３９】
空白のブロックのすべてが、囲まれた変数が更新されることを示している。図３３は、ＡＰＳの観点から見たものである。入力データは、「Ｓｙｎｃ１」呼び出しの前後で示される。
【０２４０】
純粋な推奨のシナリオ
ｍが制御下でｍ番目の呼び出しと（ｍ＋１）番目の呼び出しとの間のＡＬＧＯＳＨＥＬＬ５０６の最後の呼び出しである場合には、ＢＧＳｔｒｕｃは、新たな測定によって更新される。これらの測定は、データベースから得られる。ｍ＋１番目のＡＬＧＯ５１０呼び出しの前に、以下が続く。（ａ）最新（最後）のＢＧ測定および時間のほか、ベクトルｕに割り当てられるＢＧＳｔｒｕｃからセンサ状態、（ｂ）データベースから得られ、ベクトルｕに割り当てられる最後の正味のインスリン投与情報、（ｃ）ＡＬＧＯＳＨＥＬＬ５０６が呼び出される時間に設定される時間ｔ、（ｄ）ベクトルｘｋが、そのままＡＰＳによって供給される、（ｅ）実験ポンプモードが３に設定される。ＡＬＧＯ５１０が、再び呼び出され、ｎ＝ｍ＋１となる。ＡＬＧＯＳＨＥＬＬ５０６は、モード＝３、すなわち、Ｓｙｎｃ１呼び出しとして呼び出される。
【０２４１】
Ｓｙｎｃ１呼び出しの場合には、ベクトルｙＡＭＴおよび他の出力引数が、返される。ＡＰＳは、ｙＡＭＴを用いて図３５に示されるように更新を行う。ｙＡｄｖｉｓｏｒｙは、分析され、適切なメッセージが表示される（ログウィンドウへの送信、メッセージボックスのポップおよび中止）。推奨される量ｙＡＭＴ（４）が、ＡＰＳによる推奨ウィンドウ５１４（図５）によって表示される。推奨ウィンドウ５１４は、ＡＬＧＯ５１０によって決定されたように、現在のサイクルに関する推奨されるインスリン投与量を表示する。推奨ウィンドウ５１４は、点滴されるインスリンの推奨量と共に、実行サイクルの終わりで現れる。量が１回投与量閾値以内または３回投与量閾値以内である場合には、点滴する医療従事者によって確認される必要はない。ユーザ応答は、（ａ）推奨拒否、ＶＡＬＵＥ＝０、ｉｎｄｘ＝０、（ｂ）推奨許容（承認）、ＶＡＬＵＥ  ＝ｙＡＭＴ（４）、ｉｎｄｘ＝１または（ｃ）無効化、ＶＡＬＵＥ  ＝ＥｎｔｅｒＶａｌｕｅ、ｉｎｄｘ＝２）が得られる。Ｐｕｍｐｄａｔベクトルが、更新される。図３５によって示されるような以下の割り当てがおこなわれる。ｐｕｍｐｄａｔ更新の場合には、センサに関連するｕ要素がゼロである。ｕ（１）〜ｕ（６）は、非数であり、ｕ（７）は、割り当てられた値であり、ｕ（８）は、現在の時間ｔであり、ｕ（９）は、ポンプの状態フラグである。Ｅｘｐｅｒｉｍｅｎｔモードは４に設定される（Ｓｙｎｃ２呼び出しの場合）。ＡＬＧＯ５１０が、再び呼び出され、ｎ＝ｍ＋２となる。最後に、呼び出しが、Ｓｙｎｃ２呼び出しとしてＡＬＧＯ５１０に対して行われる。Ｓｙｎｃ２の場合には、図３５に示されているように、Ｐｕｍｐｄａｔベクトルが更新される。シーケンスは次に、次の制御サイクルに関して繰り返される。
【０２４２】
ＡＬＧＯ−ＡＰＳフロー
ＡＬＧＯ−ＡＰＳプロセスフローの実施例もまた、表１４において以下で提供される。経過時間は、実験の開始以来、分単位の相対時間ｔであることを留意すべきである。再起動が行われるとき、開始時間は、実験の開始時間であり、再起動の開始時間ではない。経過時間は依然として、「ＥｘｐｅｒｉｍｅｎｔＳｔｒｕｅ．ｔ＿ｚｅｒｏ」を対して相対的に測定される。
【０２４３】
【表１４】
0005529307.tif 000101
0005529307.tif 000102
0005529307.tif 000103
【０２４４】
Ｓｙｎｃ２が制御サイクルのエッジの前に生じ、再起動  ｙＡＭＴが記録され、ＡＰＳによって正確に格納されるという条件であれば、関心態様は、Ｓｙｎｃ１の後にＳｙｎｃ２が続くことである。再起動は、ＡＰＴＳがグラフにするために、ＡＬＧＯが用いるために収集された前のデータを用いて、未完成の実験の再開であることを留意すべきである。センサおよびポンプデータは、分単位の経過時間を用いてＢＧＳｔｒｕｃおよびＰｕｍＳｔｒｕｃに割り当てられる。ベクトルｕは常に、タイムスタンプと共に、一番新しい利用可能なデータを送信する。新しいデータが得られない場合には、最後の周知のデータが得られる。第２の仕様（specification）の実行実施形態に関する説明がここで、提供される。
【０２４５】
ＡＰＣＡＴＳ（自動膵臓制御アルゴリズム試験項目群）
自動膵臓制御アルゴリズム試験項目群（ＡＰＣＡＴＳ）は、標準化されたシミュレーションツール、ＡＰテストスタンドエミュレータ、検証ツールおよび評価ツールとして機能するソフトウェアプログラムである。標準化されたシミュレーションツールとして、ＡＰＣＡＴＳは、一般的な閉ループシステムをシミュレートするために必要な基本的な機能性を提供する。したがって、この機能性により、接続の詳細および基本的な設定および接続の検証ではなく、モデル化そのものに焦点を当てて数学モデルを設計することが可能である。ＡＰテストスタンドエミュレータとして、プログラムは、ＡＰＴＳ５００によって必要とされるものからアルゴリズムの変更を評価して検証するために必要な時間を短縮することができる。これを達成するために、（実時間とは対照的に）「シミュレート」時間を用いると同時に、ＡＬＧＯ５１０に関して同一のシミュレート環境を提供する。また、パラメータ値の範囲にわたってシミュレーションを可能にすることによって、ＡＰＣＡＴＳは、患者を危険に曝すことなく、評価の範囲を広げることができる。さらに、ＡＰＣＡＴＳは、重要なシナリオをシミュレートして評価するために用いられ得る。たとえば、デバイスの故障が体系的に評価されることができ、またはフェイルセーフモードが実行されて評価されることができる。
【０２４６】
検証ツールとして、ＡＰＣＡＴＳは、ＡＰＴＳ５００をエミュレートする能力を提供し、それにより、開発および事前公開のシナリオの下で、最初に検証されるＡＬＧＯ５１０に対して任意の改訂を行うことを可能にする。評価ツールとして、ＡＰＣＡＴＳは、数学モデル、制御装置、閉ループ応答などをシミュレートするために用いられ得、したがって、シミュレートされた項目の（１）品質および（２）性能を評価することを可能にする。示された実施形態において、ＡＰＣＡＴＳは、ＭＡＴＬＡＢ技術計算環境で開発され、実行する。他の実施形態において、ｖｉｓｕａｌ  ｂａｓｉｃおよびＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムなどの他の言語および計算環境を用いてもよい。フロントエンドユーザインターフェイスは、ある程度標準化された自動膵臓システムのための制御規則を開発して分析する迅速な手段を提供する。ハードウェアが、制御ループに接続される場合には、分析およびシミュレーションを行うほか、実際のシステムを駆動するための共通のプラットフォームを提供する。ＡＰＣＡＴＳは、当業者によって十分に認識されているシステム１０およびハードウェアにおけるソフトウェアプログラムの実行などのＡＰＴＳ５００のような類似の動作環境で実行されるため、以下の節では、本発明のこの第２の仕様の実行実施形態のソフトウェア構成要素にのみ焦点を当てる。
【０２４７】
ソフトウェア構成要素
ＡＰＣＡＴＳアプリケーションは、ユーザインターフェイス、初期化ファイルおよび構成要素モジュールの３つのカテゴリに分割される複数の個別のソフトウェア構成要素を備える。ＡＰＣＡＴＳは、データを保持し、フロントエンドのすべてを統一アプリケーションにする根幹を成す中心コアを有する。初期化ファイルはまた、ｉｎｉｔファイルとも呼ばれ、ＡＰＣＡＴＳコアに必要なモジュールがどこにあり、読み出しおよび実行のためにどのようなモジュールが必要とされるかを通知する。これらのファイルの情報に基づき、ＡＰＣＡＴＳは、それ自体を動的に作成する。構成要素モジュールは、構成要素のそれぞれがどのように振る舞うかを数学的に記述する。シミュレーション中、構成要素モジュールは、外部励起および内部励起に動的に反応する。構成要素モジュールは、以下の主要なタイプの下に本願明細書において分類される。プラント、アクチュエータ、センサ、制御装置および外部の障害である。これらの構成要素モジュールのそれぞれは、後の節でさらに詳細に説明される。
【０２４８】
ユーザインターフェイス（ＵＩ）は、オプションの選択、一定の特徴および項目とのインタラクションまたは値の修正などのユーザからの入力を可能にするフロントエンドである。また、ユーザに出力を観測させることも可能にする。コアは、問題そのものに関係なく設計されるため、問題の定義は、構成要素モジュールに含まれる。ＵＩと構成要素モジュールとの間のインタラクションの自由度は、初期化ファイルを通じて管理される。ユーザインターフェイスは、以下の主要な態様を取り上げる。ＡＰＣＡＴＳメインウィンドウ、各構成要素に関するユーザエントリフォーム、構成要素に関するメニューフォーム、シミュレーション実行設定フォーム、シミュレーションリンク（Simulink）ブロック図の生成、データファイルの管理およびインタラクション、結果を表示するためのプロット、ＡＰＣＡＴＳ設定の格納および検索および接続インターフェイスである。
【０２４９】
図２２を参照すると、ＡＰＣＡＴＳは、記号９００によって一般に示され、メインウィンドウ９０２としてユーザインターフェイスを提供する。メインウィンドウ９０２は、実行／格納ペーン９０４、アルゴリズムペーン９０６およびプロットペーン９０８の３つのペーンを提供する。さらに、下部にあるステータスバー９１０は、ＡＰＣＡＴＳ９００活動のメッセージを中継している。
【０２５０】
アルゴリズムペーン９０６は、モデル患者の中の血糖値の調整に重要である制御アルゴリズムである。アルゴリズムペーン９０６は、入力／出力接続線Ｘと接続される複数のブロックからなる自動膵臓制御アルゴリズムを表示する。アルゴリズムペーン９０６は、全体的な閉ループシステムを設定するために用いられる。アルゴリズムペーン９０６は、モデルの選択、パラメータ値の編集および接続の修正を可能にする。ブロックおよび接続のそれぞれは、それらのパラメータを表示して設定するために選択されてもよい。利用可能なブロックは、外部障害ブロック９１２、プラントブロック９１４、センサブロック９１６、制御装置ブロック９１８およびアクチュエータブロック９２０である。図示されているように、ブロックの接続は、外部障害ブロック／プラントブロック接続、プラントブロック／センサブロック接続、センサブロック／制御装置ブロック接続、制御装置ブロック／アクチュエータブロック接続、アクチュエータブロック／プラントブロック接続およびアクチュエータブロック／制御装置ブロック接続である。
【０２５１】
図２３は、一般的な閉ループ構造を示すブロック図であり、図における相互接続する矢印は、アルゴリズムペーン９０６のブロック間のインターフェイスを表している。相互接続する矢印はまた、ブロック間の情報の流れを表している。アルゴリズムペーン９０６のブロックのそれぞれは、最上層に、ユーザへの複数のオプションを提供する。あるのであれば、選択に関連するさらなるオプションが、隠された副層として展開される。これらの層は、ユーザに解放されており、目に見える最上層から下層までユーザが進むときに起動される。アルゴリズムペーン９０６における種々のブロック９１２〜９２０および接続を通じて、シミュレーションに必要なパラメータを修正することが可能である。ユーザは、パラメータを複数の可能なモデルから選択して、選択されたモデルに対応するパラメータを設定し、入力／出力接続を通じて供給された情報を設定することが可能である。アルゴリズムペーン９０６の種々のブロックについては、最初にプラントブロックを参照して、以下でさらに詳細に記載される。
【０２５２】
プラントブロック
プラントブロック９１４は、複数の選択可能な患者モデル（たとえば、図３における患者モデル７３）のリストを提供し、関連する生理学および代謝のインタラクションの現在の知識を反映する。可変の複雑度および詳細を有する新たな患者モデルは、プラントブロック９１４において用いるためにモデル化され、提供（追加）されることができる。パラメータ範囲を調整することによって、プラントブロック９１４は、広範囲の挙動を研究してモデル化するために用いられ得る。プラントブロック９１４は、アクチュエータから入力を受信し、種々の食事摂取によって生成される障害を受信する。センサは、プラントブロック９１４において選択された患者モデルから出力を測定するために用いられる。
【０２５３】
プラント選択およびパラメータ設定
患者モデルは、対応するラジオボタンの１つをクリックすることによって、プラントブロック９１４によって選択される。１つのみの患者モデルが、任意の時間に選択されることができる。対応するラジオボタンは、反転表示になっており、図２４によって示されているように、プラントメニューウィンドウ９２２を提示することができる。既に選択された患者モデルをクリックすることもまた、プラントメニューウィンドウ９２２を上に持ってくる。新たなプラントが選択されるときに、プラントメニューウィンドウ９２２が既に開いている場合には、ＡＰＣＡＴＳ９００は、入力されたパラメータが保存されたかどうかを確認するために検証する。保存されている場合には、現在のプラントメニューウィンドウ９２２を閉じ、新たに選択されたモデルのために新たなプラントメニューウィンドウ９２２が開かれる。パラメータが保存されていない場合には、その影響に対するメッセージが、メインウィンドウ９０２の下部にあるメッセージバーに表示され、既にアクティブ状態のプラントメニューウィンドウ９２２は、閉じられない。選択された患者モデルに対応するパラメータが、ウィンドウに表示され、メモリに格納された保存値が読み込まれる。パラメータ値は、編集されることができ、編集状態を表す以下の色で表示される。黒−デフォルトまたは未編集の値、赤−編集された値、青−フリーズした編集可能でない値である。
【０２５４】
患者モデルの選択が変更される場合には、プラントブロック９１４とリンクされるブロック間の既に存在する接続は、切り離され、ユーザはブロックを再接続する必要がある（以下で提供される接続の節を参照されたい。）プラントブロック９１４に関連する入力および出力が、更新される。また、新たな患者モデルの選択は、プロット設定における独立変数および従属変数の更新リストを結果として生じる。（６節を参照されたい。）プラントメニューウィンドウ９２２における各パラメータは、それ自身の列に列挙される。プラントメニューウィンドウ９２２における行は、各列に関する「番号」行９２４、パラメータ名に関する「パラメータ」行９２６およびパラメータ値に入力するための「値を編集する」行９２８である。「値をスライドする」行９３０の値への変更もまた、隣接するスライダ９３２において反映される場合には、入力される値は、「値をスライドする」行９３０の後で提供される２つの行におけるパラメータの特定の最小値と最大値との間でなければならない。
【０２５５】
「値をスライドする」行９３０は、パラメータに関する最小値および最大値のそれぞれに対応するスライダ９３２の左端および右端を用いて、パラメータの値を設定する代替方法を提供する。スライダ９３２が動かされると、パラメータの数値が、「値を編集する」行において、スライダの左にある行で更新される。「最小値を編集する」行９３４は、最小の許容可能なパラメータ値を提供する。変更がスライダ９３２でも反映される場合には、この値は、編集されてもよい。「最大値を編集する」行９３６は、パラメータ値の上限を提供する。大きな値は、上限を有していないパラメータの場合に用いられる必要がある。変更がスライダ９３２でも反映される場合には、この値は、編集されてもよい。
【０２５６】
「分割数」行９３８は、シミュレーション（たとえば、パラメータの研究）が行われるパラメータの値の数を示すために用いられる。非ゼロの正の整数が、入力されなければならない。非整数の値は、最も近い妥当な整数に丸められる。以下の「分割数」の場合には、実験シミュレーションにおいて用いられるパラメータ値は、０または１は、入力されたパラメータ値を用いることを意味し、２は、最小値および最大値を用いることを意味し、３は、最小値、平均値、および最大値を意味し、ｎ（ｎは正の整数）は、最小値、最大値およびｎ−２個の等しい間隔の中間値を用いることを意味する。パラメータの研究は、パラメータ値のあらゆる組み合わせを含み、複数のパラメータの倍数の値が用いられる場合には、過剰な数の実行につながる可能性があることを周囲されたい。組み合わせの数を決定するために、すべてのパラメータに関して選択された分割数を乗算する。ＡＰＣＡＴＳ９００の場合には、（ａ）パラメータ範囲の体系的な広がりおよび（ｂ）パラメータ範囲のランダムな広がりの２つの異なるタイプのパラメータの研究を行うことができる。
【０２５７】
（ａ）パラメータの研究（体系的）
所与のパラメータにおいてパラメータの研究を行うために、ユーザは、パラメータのための分割数を研究対象の値の数に設定する。実行するパラメータの値は、値の規定数を与えるのに十分である入力される最小値および最大値と、複数の均等な間隔の中間値である。たとえば、パラメータのための分割数が、５に設定される場合には、最小値および最大値と、最小値と最大値との間の距離の１／４、１／２および３／４である３つの他の値に関して実行される。２つ以上のパラメータが、複数の値に用いるために設定される場合には、すべてのパラメータの値の各可能な組み合わせに関して実行する。過剰な数の組み合わせ／実行を容易に作成する可能性があるため、「分割数」を設定する際には、注意を払わなければならない。
【０２５８】
（ｂ）パラメータの研究（ランダム）
ランダムなパラメータ選択を用いるためには、ユーザは、「ランダムにパラメータ値を選択する」のチェックボックス９４０をチェックする。「実行数」フィールド９４２および「ＳＥＥＤ」フィールド９４４はそれぞれ、有効になる。「実行数」フィールド９４２には、ユーザは、実験のシミュレーション中に実行すべきシミュレーションの数を入力する。「ＳＥＥＤ」フィールド９４４には、ユーザは、乱数発生器用のシードとして正の整数を入力する。ＳＥＥＤ値は、乱数シーケンスを再作成するために用いられ、実験の文書に格納されて、乱数値を再生成可能にする。乱数発生は、パラメータ範囲にわたる一様な分布を仮定する。各実行に関して、パラメータのために用いられる乱数値は、文書ファイルに格納される。プラントメニューウィンドウ９２２の下部にあるコマンドラインメニュー９４６は、以下の機能性、保存、キャンセル、ヘルプおよび閉じるを提供する。「保存」は、任意のパラメータの変更を保存し、保存された最後の時間から少なくとも１つの値が、変更される場合に限り、アクティブになる。「キャンセル」は、最後に保存された値を復元する。このボタンは、保存された最後の時間から少なくとも１つの値が、変更される場合に限り、アクティブになる。「ヘルプ」は、ヘルプウィンドウを開き、「閉じる」は、もしあるのであれば、変更を保存して、ウィンドウ９２２を閉じる。
【０２５９】
センサおよびアクチュエータ
センサブロック９１６およびアクチュエータブロック９２０の構築はそれぞれ、アルゴリズムペーン９０６におけるそれらのユーザインターフェイスと類似であるために、本願明細書において共に説明され、デバイスブロックと総称される。アクチュエータブロック９２０（図２２）は、制御装置ブロック９１８からコマンドを受信するポンプユニットをシミュレートする。これは、アクチュエータブロック９２０を起動する。アクチュエータブロック９２０からの出力は、プラントブロック９１４に送信される。他方、センサブロック９１６は、プラントブロック９１５において選択された患者モデルから信号を測定し、情報を制御装置ブロック９１８に送信する。デバイスブロック９１６および９２０は、以下の特性を有する。数学的関係によって記述されるデバイス動力学は、デバイスパラメータ、入力および出力である。センサブロック９１６およびアクチュエータブロック９２０のそれぞれは、以下の設定の選択を提供する。デバイスの数、デバイス／デバイスモデルのタイプおよびデバイス係数である。雑音および非線形性が関数を構成するため、それらのパラメータは、他のデバイス係数と共に列挙されることができる。
【０２６０】
デバイスは、アルゴリズムペーン９０６においてデバイスブロック９１６および９２０のプルダウンリスト９４８から選択される。デバイスの選択時に、係数９５０とも呼ばれるデバイスに特有のパラメータが、それぞれのデバイスブロックにおいて列挙される。デフォルト値は通常は、係数記述の次に列挙される。係数値は、編集可能である。値のいずれかが編集される場合には、保存ボタンおよびキャンセルボタンが、有効となる。最後に保存された値に戻すためには、キャンセルボタンをクリックする。入力された値を保存するためには、保存ボタンをクリックする。これらの行為のいずれも、次の編集が行われるまでボタンを無効にする。保存ボタンおよびキャンセルボタンがアクティブである場合には、すなわち、それぞれのデバイスブロックにおいて係数がまったく保存されない場合には、新たなシミュレーションは実行されないことを留意されたい。複数のデバイスユニットを並列に実行可能にするＡＰＣＡＴＳ９００の能力は、複数のセンサまたはポンプを同時にシミュレートすることも可能にする。
【０２６１】
複数の同時ユニットを実行するためには、ユーザは、どれだけの数の制御チャネルが動作中であるかを示すデバイスメニューの右上の数タブ９５２にユニットの所望の数を入力しなければならない。各ユニットは、左上側にある番号タブ９５４によって選択可能なそれ自体のデバイスフォームを有する。現在選択されているデバイスの番号タブ９５４は、反転されている。ユーザは、これらのフォームのそれぞれで、係数９５０を編集することができる。デバイスの数の増大は、新たなデバイスをドロップダウンリスト９４８の終わりに追加する。同様に、減少は、リスト９４８の終わりからデバイス（すなわち、より高い数のデバイス）を除去する。ユーザが、フォームを保存する前に別のタブに切り替えたい場合には、フォームを保存するように促され、進む前に修正を保存またはキャンセルしなければならない。ユーザは、任意の時間で、タブおよびデバイスの数を変更することができる。デバイスの所定の最大数を超える数を入力した場合には、数は、前の値に戻される。デバイスが変更されるときはいつでも、そのデバイスに関してすでに存在している入力接続および出力接続は、切り離される。シミュレーションを実行する前に、ユーザは、デバイスとその入力を提供し、その出力を受け入れるモジュールとの間で新たに接続しなければならない。同様に、任意の新たに追加されるデバイスのためにも接続が行われなければならない。パラメータが、保存される必要があるか、または破棄される必要があるかを検証することなく、デバイスを切り替える能力は、まだ、完成してないことを留意されたい。現在、ＡＰＣＡＴＳ９００は、最後の保存以降に行われた任意の変更を破棄する。
【０２６２】
デバイスブロック９１６および９２０は、（１）正常な連続デバイスである非故障モードおよび（２）故障モードの２つのモードで動作することができる。故障モードは、デバイス中断のシミュレーション、すなわち、他のサブブロックが正常な動作を続行している間、デバイス出力のフリーズにより故障状態となることを可能にする。故障の終わりで、デバイスは、再初期化することによって回復する。故障は、どのデバイスが機能しなくなったか、経験した故障のタイプおよび故障の持続時間を特定することによってスケジュール化され得る。フェイルセーフ／故障モードを可能にし、故障をスケジュール化するために、ユーザは、故障モードボタン９５８の左にあるチェックボックス９５６をチェックする。制御装置ブロック９１８におけるテストスタンドエミュレータ（ＡＰＳｅ）ボタン９６２用のチェックボックス９６０が、チェックされた場合には、故障モードチェックボックス９５６が、自動的にチェックされ、変更できないように無効化される。エミュレート（シミュレート）ＡＰＳであるテストスタンドエミュレータボタン９６２用のチェックボックス９６０が、制御装置ブロック９１８でチェックされない場合には、ユーザは、故障モードチェックボックス９５６を用いてフェイルセーフ／故障モードを選択してもよい。故障モードが有効である場合には、故障タイプを表すさらなる出力が、作成される。デフォルトで、０（ゼロ）の値は、正常なデバイス動作を表す。
【０２６３】
故障をスケジュール化するために、ユーザは、それぞれのデバイスブロック９１６または９２０で故障モードボタン９５８（故障モードが有効であった場合）をクリックする。図２５ではセンサ故障メニューウィンドウであるそれぞれのデバイス故障メニュー９６４ウィンドウが、開く。アクチュエータ故障メニューウィンドウは類似であるため、故障メニューウィンドウ９６４のみが説明される。故障メニューウィンドウ９６４は、異なる所定の故障用のボタン９６６を含む。これらのボタン９６６をクリックすることにより、故障スケジュール９６８に故障を入力する。スケジュールは、選択された故障モードに関する種々のパラメータを列挙し、その一部は編集可能である。パラメータは、「番号」９７０、「故障モード」９７２、「タブ番号」９７４、「故障開始時間」９７６、「故障終了時間」９７８および「関連付け」９８０である。「番号」パラメータ９７０は、故障項目のシリアル番号である。「故障モード」パラメータ９７２は、故障の名前であり、「タブ番号」パラメータ９７４は、故障に割り当てられるデバイスのタブ番号である。デバイスは、実施すべき故障のために存在しなければならない。「故障開始時間」パラメータ９７６は、日、時間および分単位の開始時間である。任意の非数字の文字は、数字を分離するために用いられてもよい。１つの数字のみが入力される場合には、分を表すものと仮定される。２つの数字が入力される場合には、時間および分を表すものと仮定される。「故障終了時間」パラメータ９７８は、日、時間および分単位の終了時間である。入力される数の解釈は、開始時間の場合に用いられるものと同一のパターンに従う。
【０２６４】
「関連付け」パラメータ９８０は、コメントを捕捉するために用いられる。故障の数および名前は、故障ボタンがクリックされると入力される。これらのフィールドは、編集可能ではない。開始時間が入力されない場合には、故障は始まっていない。入力された開始時間が終了時間まで進む場合には、故障は、開始時間で始まり、終了時間で打ち切られる。開始時間が終了時間以上である場合には、故障は、開始時間で始まり、シミュレーション時間の終わりまでそのままである。故障メニューウィンドウ９６４もまた、下部にコマンドラインボタン９８２を有する。コマンドラインボタン９８２は、昇順の開始時間の順序に故障を並べ替える「並べ替え」、任意の変更された値を保持する「保存」、最後に保存された値を回復する「キャンセル」、ヘルプウィンドウを開く「ヘルプ」、任意の変更を保存してウィンドウを閉じる「閉じる」である。保存ボタンおよびキャンセルボタンは、スケジュールにおける情報の何かが、最後に保存された後、変更された場合に限り、有効である。故障メニューウィンドウ９６４に示される残りの項目は、一目瞭然である。
【０２６５】
制御装置
制御装置ブロック９１８は、プラントブロック９１４に類似である。一度に１回のみ選択可能であるラジオボタン選択として、すべての利用可能な制御装置を列挙する。制御装置モデルを選択するために、モデルのラジオボタン９８４をクリックする。患者を外部励起の多様な影響に対して安定化する自動ケアが、制御装置モジュールによって制御され、補正されることを留意すべきである。これは、連続方式で投薬を正しく管理することによって行われる。ＡＰＣＡＴＳ９００は、試用する標準的な制御アルゴリズムのリストを提供するが、ユーザ定義の制御装置を導入するためのオプションも有する。基本的概念は、プラグインおよび制御装置実行タイプの状況を提供することである。オプションは、以下のように見えてもよい。制御装置１（パラメータを修正する）および制御装置２（パラメータを修正する）および制御装置ｎ（パラメータを修正する）。制御装置モデルの選択後、制御装置パラメータウィンドウが現れる。制御装置パラメータウィンドウは、プラントメニュー９２２（図２４）と類似であるため、制御装置パラメータウィンドウは、図示せず、列挙された御装置パラメータをどのように調整するかに関するさらなる説明は、提供されない。制御装置が変更されるときはいつでも、そのデバイスに関してすでに存在している入力接続および出力接続は、切り離される。シミュレーションを実行する前に、ユーザは、制御装置とその入力を提供し、その出力を受け入れるモジュールとの間で新たに接続しなければならない。
【０２６６】
テストスタンドエミュレータ
制御装置ブロック９１８（図２２）においてチェックボックス９６０をチェックすることは、テストスタンドエミュレータプッシュボタン９６２を有効にし、図２６に示されているように、クリックすると、テストスタンドエミュレータウィンドウ９８６を提示する。テストスタンドエミュレータウィンドウ９８６は、障害をイベントタイプにリンクするために用いられる。上半分のテストスタンドエミュレータウィンドウ９８６は、４行でグループ化されたイベントタイプボタン９９０を含む。所与の行におけるボタン９９０は、イベントの同一の特定の態様に関連し、誘発されることができるイベント関数を表す。各ボタン９９０は、障害モジュールによって定義される障害に関連する。これらのボタン９９０の１つをクリックすることにより、誘発されたイベントを呼び出し、対応するイベントをウィンドウの下部分に位置するイベントスケジュール９９２に入力する。イベントスケジュール９９２は、イベント（障害）が生じるとスケジュール化されるとき、その持続時間および規模からなるタイムテーブルである。障害をスケジュールにおけるイベントと関連付けるために、最初に残ったユーザは、障害を選択するために、障害をクリックする。列は、黄色で強調されるようになっている。次に、その列で入力されるイベントタイプに関して、ボタン９９０の関連する１つをクリックする。ユーザは次に、その列で残っている値の入力に進む。
【０２６７】
誘発されるとき、誘発されるイベントは、プラントブロック９１４（図２２）においてチェックされた選択された患者モデルに単に作用するだけである。制御装置ブロック９１８は、適切な誘発イベントと関連付けることによって、障害に気付かせる。「イベントリスト」行に列挙された誘発イベントは、複数のプロパティを有する。「イベント開始時間」として示される誘発時間、「イベントタイプ」、「ＡＬＧＯ行為時間」として示される相対的な誘発時間、「行為拡張時間」として示されるイベントの持続時間および「量」である。「イベントタイプ」は、アルゴリズムによって用いられるイベントコードである。「イベントタイプ」ボタンの１つをクリックするか、または対応するコード（ボタンで括弧で与えられる）を入力することによって、イベントコードは、入力されることができる。相対的な誘発時間は、制御装置ブロック９１８（すなわち、ＡＬＧＯ５００）が誘発イベントに気付く物理的に発生したイベントの時間に対するものである。制御装置ブロック９１８は、（ａ）実際のイベントが発生する前（負の数）、（ｂ）イベントの発生と同時、（ｃ）実際のイベントの数時間後（正の数）に、発生を知らされることができる。イベントの持続時間は、誘発された後、イベントがアクティブ状態のままである持続時間を選択するために用いられる。イベント量は、イベントの規模を選択するために用いられる。
【０２６８】
テストスタンドエミュレータウィンドウ９８６の下部は、コマンドメニューボタン９９４を含む。ボタン９９４およびそれらの関数は、以下の通りである。「Ｐａｔｉｅｎｔ  Ｉｎｉ」は、初期化ファイルＰａｔｉｅｎｔＩｎｉのパスおよび名前を表示する。ＰａｔｉｅｎｔＩｎｉファイルは、制御装置（たとえば、ＡＰＳ５００）によって用いられる患者パラメータを含む。「実験ディレクトリ」は、データが常駐するディレクトリの位置を表示し、「保存」は、現在の変さらに値を保存して更新する。「キャンセル」は、変更を却下し、最後に保存された値を再読み込みし、「ヘルプ」はヘルプスクリーンを表示する。「閉じる」は、任意の更新された値を保存して、ウィンドウを閉じる。所望であれば、リフレッシュボタンもまた、提供されてもよい。
【０２６９】
外部障害
外部障害ブロック９１２（図２２）は、普通の生活および健康的な生活を過ごしている人から予想される炭水化物消費、身体活動および他の活動に対する応答をシミュレートするための手段を提供する。普通の生活を過ごすことができる糖尿病患者の場合には、身体機能は、そのような障害／励起に対処するように調整しなければならない。閉ループシステムの堅牢性、有効性および安定性は、（１）動作範囲にわたるモデルパラメータ値における変更および（２）外部障害／励起のすべての考えられるシナリオを調査することによって、評価される。ＡＰＣＡＴＳメインウィンドウ９０２で、外部障害ブロック９１２をクリックすることにより、図２７によって示されているように、外部障害メニューウィンドウ９９６を表示する。予め定義される一連の励起機能ボタン９９８は、図２７によって示されているように、「ＳＥＬＥＣＴ  ＤＩＥＴ  ＣＵＭ  ＥＸＥＲＣＩＳＥ  ＯＰＴＩＯＮＳ」と表されたタイトルの下で提供される。さらなる励起機能は、後の節に記載するように、新たな機能を書き込み、初期化ファイルＤｉｅｔｌｎｉｔを修正することにより、リストに容易に導入される。種々のシナリオ、標準的な一連の試験事例または任意のユーザ事例を試験するためのオプションが、利用可能である。これらは、障害関数を用い、それらの発生をスケジュール化することによって構成される。
【０２７０】
選択のために利用可能な障害が選択された患者（プラント）モデルに左右されるため、ボタン９９８は、有効であってもよく、または無効であってもよい。したがって、所与の患者モデルの場合には、その患者モデルに関して定義される障害のみが、有効であり、選択のために利用可能である。障害は、任意の順序で入力されてもよい。外部障害メニューウィンドウ９９６はまた、シミュレーションの長さに関して設定するために、外部障害スケジュール１０００を提供した。外部障害スケジュール１０００は、行フォームにおいて以下のものを列挙する。障害の数、障害の名前、スケール強度、開始時間、終了時間および関連付けである。障害の数および名前は、編集可能ではないが、障害選択ボタンが、障害を表に入力するために用いられる場合には設定される。スケール強度の値は、ユーザが、因子によって出力値をスケーリングすることを可能にする。デフォルトのスケール値１は、名目上の障害を示す。スケジュール１０００の残りの行は、シミュレーションの期間中に生じる障害（励起）をスケジュール化するために、使用においてテストスタンドエミュレータウィンドウ９８６（図２６）のスケジュールと類似であるため、さらなる説明は提供されない。さらに、外部障害メニューウィンドウ９９６の下部におけるコマンドメニューボタン１００２もまた、故障メニュー９５２で提供されるそれらのボタンと類似であるため、さらなる説明は提供されない。
【０２７１】
障害出力とプラントパラメータの連結
外部励起は一般に、プラントパラメータのほか、プラントへの入力を駆動する。この具体的な事例において、障害関数のそれぞれは、（１）プラントブロック９１４に接続される必要がある出力および（２）プラントパラメータと一対一対応にある障害パラメータからなる出力を有するモジュールであると見なされる。障害出力に障害からのパラメータ出力をあわせたものは、プラントモデルの入力およびパラメータになるようにするために、供給される。しかし、複数の障害が同時に発生する場合には、重要な検討事項がある。複数の障害関数の効果は、プラントブロック９１４への入力となる１つのベクトルによる出力を形成するために、障害のすべてから出力を加算することにより、重ね合わせられる。これを実現することができるようにするためには、障害モデルの中で、障害出力のそれぞれが、出力の数およびそれらの順序において、他の障害出力に適合することが必要である。しかし、障害ブロック９１２の観点から、出力の数またはそれらの順序に制限はない。他方、パラメータ出力は、選択されたプラントと順序のほか、数において一致しなければならない。複数の障害が同時に作用する場合には、上述した出力とは異なり、パラメータは、追加されるのではなく、障害のそれぞれから設定されるパラメータが、決定され、パラメータ値の１つの設定が、決定される。このシナリオを管理する関数は、フィルタ関数である。
【０２７２】
外部障害メニューウィンドウ９９６において外部障害を入力した後で、フィルタ関数は、選択された患者モデルからパラメータの数を得る。すべての食事の動作状態（動作中＝１、非動作中＝０）は、食事から生じるパラメータ値によって多重化される。食事の回数は、以下の論理、すなわち、食事の回数＝入力ベクトルの長さ／（１＋パラメータの長さ）を用いることによって計算される。外部障害の入力される開始時間および終了時間は、関数が起動される時間および関数が停止する時間となる。食事を記述する数学的関数は、開始時間とは独立である。終了時間に関して、関数は、設定時間経過を有してもよく、そのような事態において、終了時間を扱うための方法がいくつかある。関数は一般に、微分方程式であり、その初期の状況およびパラメータのすべてが、関数の中で記載される。関数挙動は、正規化応答である。出力は、「スケール強度」行の下で、イベントスケジュール１００において提供される入力スケール値によってスケーリングされる。正のスケール値が通常は、予想されるが、負の効果をシミュレートするために、負の値が入力されてもよい。
【０２７３】
接続ポートフォーム
ＡＰＣＡＴＳメインウィンドウ９０２に示される接続線をクリックすることにより、図２８によって示される接続ポートフォーム１００４を提示する。その左側に接続ポートフォーム１００４が列挙され、利用可能な出力１００６の数を定める。出力１００６は、情報を送信するブロックによって生成される。右側は、空白の編集ボックスと共に、情報を受信するブロックの入力１００８を表示する。特定の出力１００６と特定の入力１００８との間の接続を作成するために、ユーザは、出力を受信する入力フィールドに隣接する編集ボックスに、出力に対応する数をタイプする。出力１００６に接続されない任意の入力１００８、すなわち、空白の編集ボックスを有する入力１００８は、ゼロに設定される。また、入力１００８は、２つ以上の出力１００６に接続されることができないことを留意されたい。あらゆる出力に関して、入力に接続されることが必要ではない。シミュレーションは、すべての列挙された出力に関してデータを生成するが、接続されないままである出力は、次のモジュールへの入力として簡単に用いられない。出力は、２つ以上の入力に接続されることができる。すべての所望の接続の終了時には、接続を保存して、フォームを閉じるために、右上隅にある「Ｘ」（ウィンドウを閉じる）ボタンをクリックする。
【０２７４】
実行／格納ペーン
図２９によって拡大されるＡＰＣＡＴＳメインウィンドウ９０２の実行／格納ペーン９０４は、データの読み込み、データの保存およびシミュレーションの実行のための基本的な機能性を提供する。さらに、実験設定を表示し、ユーザが実験の要約を入力することを可能にし、最後に、ユーザがＡＰＣＡＴＳ９００から出ることを可能にする。実行／格納ペーン９０４の最も左の行は、開始項目フォーム１０１０（図３２）において行われて修正される項目を表示する。一番上から一番下まで表示する情報の３つの部分は、ユーザ名、実験グループおよび実験識別番号および使用の実例（静注−静注、皮下−皮下、静注−皮下）である。実験に関する詳細およびコメントを入力するため、「実験概要入力」ボタン１０１２をクリックする。これを行うことにより、「ＡＰＣＡＴＳ９００−現在の実験に関する細目を追加する」ウィンドウ（図示せず）を提示する。このウィンドウにおいて入力された情報は、実験の文書（ｄｏｃ）ファイルに格納される。この情報は、任意の回数更新されることができる。
【０２７５】
現在のＡＰＣＡＴＳ９００設定をコンパイルして保存するために、ユーザは、「状態表示」ボタン１０１４をクリックする。これを行うと、状態情報が、一時的な位置（作業領域）に書き込まれ、エディタで表示される。ファイルへの入力パラメータの現在の設定を保存するために、ユーザは、「Ｃｕｍ文書実行を保存」ボタン１０１６をクリックする。「状態表示」ボタン１０１４がクリックされると、表示される設定文書もまた、保存される。実験を再作成するために必要な現在の初期化設定が、作業領域において一時ファイルに書き込まれる。ＡＰＣＡＴＳ９００が故障している場合には、このファイルに保存された設定は、開始項目フォーム（図３２）で「古い」ボタン１０１５をクリックし、列挙されたファイルディレクトリにおける一時ファイルを探索することによって復元されることができる。任意の時間に開始項目フォーム１０１０を提示するために、「開始フォーム」ボタン１０１８をクリックする。開始項目フォーム１０１０（図３２）は、実験の範囲を定義するために必要な詳細を編集し、正確な記録を維持するために用いられる。ＡＰＣＡＴＳ９００を編集するために、「ＡＰＣＡＴＳから出る」ボタン１２０をクリックする。「ＡＰＣＡＴＳから出る」ダイアローグボックスが、立ち上がり（図示せず）、ユーザは、ＡＰＣＡＴＳ９００に戻り、出るコマンドをキャンセルすることを可能にする。「続行」ボタンをクリックすることにより、アプリケーションを閉じるに進む。メインＡＰＣＡＴＳウィンドウ９００を閉じる前に、すべてのＡＰＣＡＴＳが生成したウィンドウを閉じる。
【０２７６】
シミュレーションを開始するために、ユーザは、「シミュレーション開始」ボタン１０２２をクリックする。これを行うことにより、図３０によって示されるシミュレーションパラメータウィンドウ１０２４を提示する。シミュレーションパラメータウィンドウ１０２４は、ユーザが、シミュレーションの開始時間および停止時間を設定し、統合ルーチンおよび工程サイズを選択し、シミュレーションを実行することを可能にする。大部分のフィールドは、一目瞭然である。デフォルトで、シミュレーションは、時刻０に開始実行する。非ゼロの値を入力することにより、開始時間に対するオフセットを提供する。シミュレーションの実行に関する終了時間を設定するために、ユーザは、「終了時間」テキストボックスに値を入力する。終了時間は、実行するためのシミュレーションの開始時間を超えなければならない。シミュレーションにおいて用いられる統合ルーチンを設定するためには、ユーザは、ソルバドロップダウン１０２６から統合ルーチンを選択する。統合工程サイズを設定するためには、ユーザは、工程サイズドロップダウンメニュー１０２８から工程サイズを選択する。データを保存するための期間に関して、ユーザは、データ保存の期間を入力する。相対許容差は、統合収束判断基準である。絶対許容差もまた、統合収束判断基準である。ユーザは、ドロップダウンボックス１０３０から値を選択して、シミュレーション中に表示される時間ウィンドウを設定する。利用可能な選択は、１時間ごと、４分の１日ごと、半日ごとまたは毎日およびシミュレーション全体である。Ｓｉｍｕｌｉｎｋモデルファイル名に関して、ｉｎｉｔファイルにおいて定義されるフラグは、ユーザがシミュレーションモデルファイルの名前を変えることができるかどうかを制御する。権限を与えられている場合には、ユーザは、「Ｓｉｍｕｌｉｎｋモデル名」編集ボックスにおいてＳｉｍｕｌｉｎｋファイルの名前を入力してもよい。「構成モデルのみ」である場合には、ｉｎｉｔファイルにおいて定義されるフラグは、ユーザがモデルを構築して見ることができるかどうかを制御する。権限を与えられている場合には、ユーザは、「構成モデル」ボタン１０３２をクリックして、ファイル名が「Ｓｉｍｕｌｉｎｋモデル名」テキストボックスに入力されたＳｉｍｕｌｉｎｋモデルを構築してもよい。ユーザは次に、モデル（ｍｄｌ）ファイルを開くことによって、モデルを見てもよい。
【０２７７】
シミュレーション実行
シミュレーションを始めるために、ユーザは、「開始」ボタン１０３４をクリックする。このボタンをクリックすることにより、以下の行為を誘発する。文書ファイルおよび初期化ファイルの作成および保存、パラメータの研究ループの設定、Ｓｉｍｕｌｉｎｋブロック図の作成およびシミュレート、結果として生じたデータの保存である。体系的な（Ｓ）実験または予備的な（Ｅ）実験に関して、実験識別番号が生成され、適切に名前の付いたデータファイルが、システムディレクトリに保存される。ここでファイルの保存に問題がある場合には、代わりにユーザのローカルハードドライブに通常配置しているパークト（ｐａｒｋｅｄ）データディレクトリに移動される。再生（Ｐ）グループにおける実験の場合には、ユーザは、実験識別番号を供給することが尋ねられる。体系的な（Ｓ）実験または予備的な（Ｅ）実験の場合には、ネットワークドライブに維持されるファイルを記録するために情報記録が追加される。続行ボタン１０３６をクリックすることにより、既に終了した状態からシミュレーションを続行し、シミュレーションを拡張する。一時停止／再開ボタン１０３８をクリックすることにより、実行シミュレーションを一時停止するか、または一時停止されたシミュレーションを再開するかが行われる。進行中のシミュレーションを停止するためには、ユーザは、「停止」ボタン１０４０をクリックする。シミュレーションがユーザによって停止される場合には、部分シミュレーションからのデータは、保存されない。これは、不完全なデータ集合の作成を防止する。シミュレーションクロックは、シミュレーションクロック時間を表示する。これは、ユーザが、シミュレーションの進行を監視することを可能にする。現在の実行数／合計実行数が、１６進数表記で、実験の現在の実行数および合計実行数を表示する。
【０２７８】
シミュレーション実行後、ＡＰＣＡＴＳ９００は、出力を生成する。以下のオプションが、ユーザには利用可能である。性能尺度の生成、シミュレーション前に、どのような出力が生成されて保存されるかの決定、すべての可能な出力の生成およびどのような出力が保存されるかについての後の決定、すべての出力の生成および保存、出力の可視化およびＡＳＣＩＩフォーマット、バイナリフォーマットまたは任意の他の多数の適切な電子フォーマットにおけるファイルへの出力の保存である。バイナリ形式でデータを保存することは、簡潔であるという利点があるが、データの輸送が制限されることになる。他方、ＡＳＣＩＩデータファイルを維持することは、読出し可能な形態にして、さらなるデータ分析のための他のソフトウェアに容易に輸送可能にもする。
【０２７９】
プロットペーン
ＡＰＣＡＴＳメインウィンドウ９０２のプロットペーン９０８は、ユーザが、スクリーン上またはハードコピーとして実験データをグラフ化することを可能にし、図３１によって拡大される。実行数制御１０４２は、２つの目的を有する。（ａ）シミュレーション中に、現在シミュレートされている実験実行数を表示することと、（ｂ）シミュレーション外で、データがプロットされる実行数を選択するために用いられることである。実行数は、１６進数形式で表示される。プロットされるデータを選択するときに、複数の連続実行を選択するために、ユーザは、プロットされる実行範囲の最初の番号および最後の番号を選択するために、左マウスボタンを用いながら、シフトキーを押し下げる。複数の個別の実行を選択するためには、プロットされる実行の個別の番号をクリックするために、左マウスボタンを用いながら、Ｃｔｒｌキーを押し下げる。最小制御１０４４および最大制御１０４６はそれぞれ、１６進数形式で最小実行数および最大実行数を表示する。スライダ１０４８は、プロットされる実行数を選択する代替方法を提供する。スライダの左端および右端はそれぞれ、最小実行数および最大実行数を表す。
【０２８０】
プロットペーン９０８は、列および行に整列するより小さなサブプロットに分割されることができる。列数または行数を選択するために、ユーザは、「列数」テキストボックスおよび「行数」テキストボックスに所望の値を入力する。たとえば、列数として２、行数として３を入力すると、２列に３行ずつの６つのサブプロットを作成する。一旦、サブプロットの数が確立されると、ユーザは、各サブプロットに表示されることになる情報を選択する。所与のサブプロットを設定するために、ユーザは、「サブプロットを選択する」ドロップダウンボックス１０５０からサブプロットを選択する。サブプロットは、行列表記を用いて列挙され、括弧内の第１の数が、サブプロットの列を表し、第２の数が行を表す。各サブプロットに関して、「サブプロットを選択する」ドロップダウンボックスの下の制御に必要な情報を入力する。
【０２８１】
ｘ軸に関するラベルを設定するために、ユーザは、「ラベルＸ軸」テキストボックスにラベルを入力する。テキストボックスが空白のままである場合には、選択された独立（ｘ）変数の名前が、ラベルとして用いられる。ユーザは、「ラベルＸ軸」制御の下に位置しているドロップダウンメニュー１０５２から、データがプロットされる独立変数を選択する。サブプロットのそれぞれに関して、異なる独立変数が、選択されてもよい。デフォルトの選択は、時間である。
【０２８２】
ｙ軸に関するラベルを設定するために、ユーザは、「ラベルＹ軸」テキストボックスにラベルを入力する。テキストボックスが空白のままであり、唯一の独立（ｙ）変数が選択される場合には、選択された変数の名前が、ラベルとして用いられる。テキストボックスが空白のままであり、２つ以上の独立変数が選択される場合には、ｙ軸ラベルは「＊＊＊」である。ユーザは、「それをプロットする」ボタンの真上に位置するリストボックス１０５４からプロットするための従属変数を選択する。複数の連続変数を選択するために、ユーザは、範囲の最初の変数および最後の変数を選択するために、左マウスボタンを用いながら、シフトキーを押し下げる。複数の個別の変数を選択するためには、ユーザは、個別の変数をクリックするために、左マウスボタンを用いながら、Ｃｔｒｌキーを押し下げる。各サブプロットに関して、５つまでの従属変数が、選択されてもよい。選択された変数は、選択リストの上のテキストボックスに列挙される。
【０２８３】
一旦、サブプロットのそれぞれに関するパラメータが、入力されると、プロットが表示されて印刷されることができる。プロットは、シミュレーションの実行終了まで作成されることはできない。しかし、前のシミュレーションからデータをプロットすることは可能である。スクリーン上にプロットを表示するために、ユーザは、「それをプロットする」ボタン１０５６をクリックする。プロットウィンドウが現れ、グラフを表示する。プロットを印刷した（ハード）コピーを作成するために、ユーザは、「印刷」ボタン１０５８をクリックする。ダイアローグボックスが現れ（図示せず）、ユーザが種々の印刷オプションを選択することを可能にする。
【０２８４】
初期化ファイルの修正
ＡＰＣＡＴＳ９００が初期化されると、すべての利用可能なモデルが、デフォルト値によって読み込まれる。値に対する次の変更は、これらのオブジェクトによって維持される。デフォルト値は、ＡＰＣＡＴＳメインウィンドウ９０２の種々のグラフィカルオブジェクトによって保持される。各グラフィカルオブジェクトは、種々のプロパティを有し、それぞれに関して２つの最も重要な特性が、ＵｓｅｒＤａｔａおよびＶａｌｕｅである。次の小節は、ブロックのそれぞれに関するプロパティによって管理される情報を詳述する。以下の小節は、任意のユーザ修正の前に種々の初期化ファイルの内容を表示する。
【０２８５】
0005529307.tif 000104
0005529307.tif 000105
0005529307.tif 000106
【０２８６】
障害モデルの定義
以下は、さらなる障害を作成するために、テンプレートとして用いられ得る外部障害のための部分コードである。
【０２８７】
0005529307.tif 000107
【０２８８】
患者モデルの定義
以下は、さらなる患者モデルを作成するために、テンプレートとして用いられることもできるプラントモデルのためのコードの実施例である。
【０２８９】
0005529307.tif 000108
0005529307.tif 000109
【０２９０】
デバイスモデルの定義
以下は、さらなるデバイスモデルを作成するために、用いられることもできるデバイスのための部分コードを与える。
【０２９１】
0005529307.tif 000110
【０２９２】
制御モデルの定義
以下は、さらなる制御装置モデルを作成するために、テンプレートとして用いられ得る制御装置モデルのための部分コードを与える。
【０２９３】
0005529307.tif 000111
【０２９４】
上述したように、シミュレーション（ｍｄｌ）ファイルを示した実施例は、ユーザによって所望であるときに修正されてもよい。
【０２９５】
0005529307.tif 000112
【０２９６】
本発明の前述の説明は、例示および説明の目的のために提示されている。開示された正確な形態に、本発明を網羅するもの、または本発明を限定することを意図しているわけではなく、上述の教示を踏まえて、他の修正および変更が可能であってもよい。開示された上述の実施形態は、本発明の原理およびその実際の適用を説明するために選択されて記述され、それにより、当業者が本発明を最もよく理解することが可能である。添付の特許請求の範囲は、従来技術によって限定されるものを除き、本発明の他の別の実施形態を含むものと見なされることを意図している。
【符号の説明】
【０２９７】
１０  システム
１６  プロセッサ
３４  プロセッサ
５１０  ＡＬＧＯコントローラ
５１８  経験的アルゴリズム（ＥＡ）モジュール
６００  閉ループモード
６０１  目標領域
６１６  コマンドインスリンモジュール
６１８  高グルコース治療介入モジュール
６２０  食事補償器モジュール
６２２  運動補償器モジュール
６２４  低グルコース補償器モジュール
６２６  グルコース予測器
６２８  基礎制御装置
７００  開ループモード
８００  初期化／準備モジュール
８０１  欠けたサイクル処理モジュール
８０２  イベントマッピングモジュール
８０４  インスリン設定点モジュール
８０６  プロセスセンサデータモジュール
８０８  グルコース更新モジュール
８１０  自己ボーラスモジュール
８１４  期限切れグルコースモジュール
８１８  不一致管理モジュール
８２０  食事グルコース領域モジュール
８２２  運動補償器モジュール
８２４  即効性の炭水化物摂取モジュール
８２６  低グルコース治療介入モジュール
８２８  準備運動モジュール
８３０  コマンドによるボーラスモジュール
８３２  高グルコース治療介入モジュール
８３４  炭水化物修正モジュール
８３６  インスリン無効化モジュール
８３８  グルコース予測モジュール
８４０  食事補償器モジュール
８４２  食事注意書モジュール
８４６  インスリン推奨モジュール
８４８  インスリンバケットモジュール
８５０  開ループ基礎実行論理モジュール
９００  ユーザインターフェイス
【図１】
0005529307.tif 000113
【図２】
0005529307.tif 000114
【図３】
0005529307.tif 000115
【図４】
0005529307.tif 000116
【図５】
0005529307.tif 000117
【図６】
0005529307.tif 000118
【図７】
0005529307.tif 000119
【図８】
0005529307.tif 000120
【図９】
0005529307.tif 000121
【図１０】
0005529307.tif 000122
【図１１】
0005529307.tif 000123
【図１２】
0005529307.tif 000124
【図１３】
0005529307.tif 000125
【図１４】
0005529307.tif 000126
【図１５】
0005529307.tif 000127
【図１６】
0005529307.tif 000128
【図１７】
0005529307.tif 000129
【図１８】
0005529307.tif 000130
【図１９】
0005529307.tif 000131
【図２０】
0005529307.tif 000132
【図２１】
0005529307.tif 000133
【図２２】
0005529307.tif 000134
【図２３】
0005529307.tif 000135
【図２４】
0005529307.tif 000136
【図２５】
0005529307.tif 000137
【図２６】
0005529307.tif 000138
【図２７】
0005529307.tif 000139
【図２８】
0005529307.tif 000140
【図２９】
0005529307.tif 000141
【図３０】
0005529307.tif 000142
【図３１】
0005529307.tif 000143
【図３２】
0005529307.tif 000144
【図３３】
0005529307.tif 000145
【図３４】
0005529307.tif 000146
【図３５】
0005529307.tif 000147