(57)【要約】患者に対する薬剤の監視および供給のためのシステムおよび方法である。システムは、コントロール・アルゴリズムと、該コントロール・アルゴリズムを監視する閉ループ制御を有する。センサはコントローラと通信し、医療状態を監視する。コントローラのルール・ベース・アプリケーションは、センサからデータを受け取り、そのデータを所定の医療情報と比較して、患者への治療の自動化リスクを判断する。システム・モニタはまた、コントローラと通信して、システム、リモート・システム並びにネットワーク・アクティビティおよび状態を監視する。コントローラは次いで、所定のリスク閾値を供給する。所定のリスク閾値未満の場合、自動化された閉ループの薬剤治療が提供される。所定のリスク閾値が満たし或いはそれを上回ると、自動化された治療の調整は生じず、ユーザ／臨床医の介入が要求される。【選択図】図１
2017524414.tif 000002
【特許請求の範囲】
【請求項１】
患者に薬剤を供給するシステムであって、
制御アルゴリズムを有するコントローラ、および前記制御アルゴリズムを監視する自動化リスク・モニタと、
前記コントローラおよび前記自動化リスク・モニタと通信し、医療状態を監視するセンサと、
前記自動化リスク・モニタのルール・ベース・アプリケーションであって、前記センサおよび閉ループ制御からデータを受け取り、前記データを所定の医療情報と比較して患者に対するリスクを判断する、ルール・ベース・アプリケーションと、
前記コントローラおよび前記自動化リスク・モニタと通信するシステム・モニタと、
を備える、システム。
【請求項２】
前記システム・モニタが閉塞圧レベルを検出する、請求項１記載のシステム。
【請求項３】
前記システム・モニタがライン・レベルのエアを検出する、請求項１記載のシステム。
【請求項４】
前記システム・モニタがネットワーク障害を検出する、請求項１記載のシステム。
【請求項５】
前記システム・モニタがリモート・システム障害を検出する、請求項１記載のシステム。
【請求項６】
請求項１記載のシステムにおいて、前記コントローラが薬剤供給デバイスを制御して、前記リスクの所定のリスク閾値との比較に基づいて薬剤を前記患者に供給する、システム。
【請求項７】
請求項１記載のシステムにおいて、前記コントローラが、薬剤供給デバイスをバックアップ・システムに移行させて、前記リスクの所定のリスク閾値との比較に基づいて薬剤を前記患者に供給する、システム。
【請求項８】
マルチ・チャネル注入システムを更に備える、請求項１記載のシステム。
【請求項９】
前記システム・モニタがシステムの障害を検出したときに、前記コントローラが、薬剤供給を、前記マルチ・チャネル注入システムにおける別のチャネルに移行させる、請求項８記載のシステム。
【請求項１０】
前記システム・モニタがシステムの障害を検出したときに、前記コントローラが、同時に投与されている注入を調整して前記障害を補償する、請求項８記載のシステム。
【請求項１１】
前記システム・モニタが、臨床医が応じるべき失敗を検出する、請求項１記載のシステム。
【請求項１２】
前記患者に対する前記リスクに基づいて、アラームをエスカレートさせるアラーム・システムを更に備える、請求項１記載のシステム。
【請求項１３】
前記患者に対する前記リスクが、前記センサおよび前記システム・モニタからのデータに基づいて、前記自動化リスク・モニタによって判断される、請求項１２記載のシステム。
【請求項１４】
前記システム・モニタがシステム・アクティビティを監視する、請求項１記載のシステム。
【請求項１５】
前記システム・モニタがリモート・システム・アクティビティを監視する、請求項１記載のシステム。
【請求項１６】
前記システム・モニタがネットワーク・アクティビティを監視する、請求項１記載のシステム。
【請求項１７】
患者に対する薬剤を監視および供給する方法であって、
システム・モニタを用いてシステムの状態およびアクティビティを監視するステップと、
データを受け取るために、自動化リスク・モニタを用いて制御アルゴリズムを監視するステップと、
医療状態に関し、センサからの継続的なデータをコントローラで受け取るステップと、
前記制御アルゴリズムおよびセンサからの前記データを所定の医療情報と比較するステップと、
前記制御アルゴリズムおよびセンサからの前記データと前記所定の医療情報との比較の結果、所定のリスク閾値を判断するステップと、
前記所定のリスク閾値に基づいて患者に薬剤を供給するステップと、
を含む、方法。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明は、患者への薬剤を監視および供給するシステムに関するものである。具体的には、本発明は、自動化した治療の判断について患者に対するリスクを監視し、臨床医によってルールをカスタマイズするのを可能にするデバイスに向けられるものである。当該ルールは、治療において変更が自動化されることが許可されるか、またはユーザ／臨床医の介入が、自動化およびカスタマイズされたルールのリスクに基づいて必要とされるべきかについて判断する。
【０００２】
糖尿病は、世界中で何千万の人々をも悩ます代謝性疾患である。糖尿病は、糖質（特に、グルコース）を適切に利用および代謝させる身体の不全による結果である。通常、血液中のグルコースおよび身体組織細胞中のグルコースの間で微細に調整されるバランスはインスリンによって維持され、ホルモンは、とりわけ血液から身体組織細胞へのグルコースの輸送を制御する膵臓によって分泌される。このバランスを乱すことは、心臓病、冠状動脈および末梢動脈の硬化症、末梢性神経障害、並びに低血糖ショックからの死亡を含む、数多くの合併症および病状を引き起こす。
【０００３】
インスリンに依存した糖尿病を有する患者において、疾患の症状は、注射により、または、外部若しくは植込み型のインスリン・ポンプにより、追加のインスリン（または類似の効果を奏する他の薬品）を投与することで制御することができる。正確なインスリンの投薬量は、血液中のグルコースのレベルの関数となる。理想的には、インスリンの投与は、血液のグルコース・レベルの変化に応じて、継続的に再調整がなされるべきである。糖尿病の管理では、インスリンは、身体の細胞による血液からのグルコースの取り込みを可能にする。グルカゴンはインスリンとは対照的に作用し、肝臓に、グルコースの血流への放出を行わせる。基本速度(basal rate)は、インスリン送給用デバイス（ポンプ）により提供されるインスリンの継続供給の速度である。ボーラスは特定量のインスリンであり、（継続的ではなく）必要に応じてインスリンの血中濃度を有効レベルに引き上げるために与えられる。
【０００４】
現在のところ、グルコース感受性プローブを患者の皮下層または血管区画に挿入することによって、或いは、血管アクセス・ポイントからセンサまで周期的に出血させることによって、血液グルコース・レベルを継続的に監視するシステムが利用可能である。このようなプローブでは、血液、または、光吸収、電気化学ポテンシャルおよび酵素生成物を含む他の組織が有する様々な特性を測定する。このようなセンサの出力はハンド・ヘルド・デバイスに通信することができる。ハンド・ヘルド・デバイスは、幾らかの要因（例えば、患者の現在のグルコース・レベルおよび変化率、インスリン投与率、消費されることになる炭水化物、ステロイド使用、腎臓や肝臓の状態、および運動）に鑑みて、血流に供給されることになるインスリンの適切な適用量を計算するのに使用される。次いで、これら計算を用いて、ポンプが、制御された基本速度で、或いは周期的または一度のボーラスのいずれかで、インスリンを供給することを制御することができる。統合化されたシステムとして提供される場合、継続的なグルコース・モニタ、コントローラ、およびポンプが協働する結果、継続的なグルコースの監視およびインスリンのポンプ制御を提供することができる。
【０００５】
現在のところ、このようなシステムは、供給されることになるインスリンの量を計算および制御するために、患者または臨床医による介入を必要とする。しかしながら、患者がインスリンの供給を調整することができない期間が存在することもある。例えば、患者が睡眠中のとき、彼または彼女はインスリンの供給に介入することができないにも拘わらず、患者のグルコース・レベルの制御は尚も必要とされる。グルコースの監視および制御されたインスリンの供給についての機能を統合および自動化することが可能なシステムは、特にそれらに介入できない日の期間中において、患者によるそれらグルコース・レベルの維持を支援するのに有用となろう。
【０００６】
或いは、病院環境において最適なグルコース管理システムは、インスリンの供給速度を、上述した変数に応じて頻繁に調整することを含む。しかしながら、臨床医側の恒常的な介入は重荷であり、ほとんどのグルコース管理システムでは、インスリンの更新の間の時間間隔を最大化するように設計されている。インスリン供給のための低リスクの判断を安全に自動化できるシステムは、患者のインスリン治療を改善し、臨床医のワークフローをサポートするのに有用となろう。
【０００７】
２０００年から、少なくとも５つの継続的または半継続的なグルコース・モニタが、規制認可を受けた。継続的な皮下インスリン注入（ＣＳＩＩ）と組み合わせて、これらデバイスは、閉ループ・システムへの研究を促進してきた。グルコース・レベルの変更へのリアル・タイムの応答に欠く開ループ・システムとは対照的に、閉ループ・システムは、リアル・タイムのニーズに従ってインスリンを供給する。閉ループ・システムはまた、人工膵臓とも称され、３つの構成要素から成る。即ち、グルコース監視デバイス（例えば、皮下グルコース濃度（ＳＣ）を測定する継続的なグルコース・モニタ（ＣＧＭ））、分析物（例えば、供給されることになるインスリンおよび／またはグルカゴン）の量を計算する滴定アルゴリズム、および計算された分析物の投与量を皮下に供給する１つ以上の分析物ポンプである。幾らかのプロトタイプ・システムが開発され、テストされ、そして、臨床およびシミュレーションされた家庭環境での評価に基づいてレポートされている。この強力による効果は、閉ループ・システムの家庭でのテストに向けて、進展の加速を約束するものである。
【０００８】
同様に、閉ループ・システムは、病院環境についても提案されており、主に動物実験を通じて、研究中のデバイスが開発され、テストされている。加えて、幾らかの製造業者は、入院患者へのテストのために設計された、ＦＤＡ自動化グルコース測定システムを開発している段階にあるか、またはこれを受け入れている。このようなシステムは、入院患者のグルコース管理について完全に自動化されたシステムの開発を加速することになる。
【０００９】
インスリン治療についての閉ループ制御または完全自動化が有する第一の課題は、コンピュータ化された判断システムに遅れて(behind)患者の状態が想定から変化し、または想定とは異なるものとなる場合に、見込まれる結果に関して高リスクとなり得る決定を、コンピュータ化されたシステムが行うということである。自動化した結果として、リスクが認識され、患者が容認できない医療状態を示すまで、これら高リスクな決定は発見(uncover)されない。第二に、デバイスの障害、または薬剤投与管理システムすなわちＭＭＳの障害が生じた場合に、情報の潜在的な不足にも拘わらず、自動化システムによってアクションが要求される。第三に、グルコース測定値が頻繁に自動収集されるものの自動化が望まれていないというシナリオでは、グルコース測定値が収集されるのと同じ頻度で注入を更新するというのは望ましいことではない。第四に、ユーザによる介入が必要とされるときに、臨床医がベッドサイドで応じることは望ましくなく、または困難となる場合がある。例えば、患者が隔離部屋にいるものの観察可能である場合に、臨床医は部屋に入ることなく注入速度を更新することを望む場合がある。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
従って、本発明の原則的な目的は、治療を提供する前にリスクの判断を行う、患者への薬剤を監視および供給するための改良システムを提供することである。
【００１１】
本発明の別の目的は、デバイス障害、患者の状態および状況、並びに不確実性をマップすることにより、患者のリスクを最小化するシステムを提供することである。
【００１２】
本発明の更なる別の目的は、患者へのリスクを最小化する、患者への薬剤を監視および供給するためのシステムを提供することである。
【００１３】
本発明の別の目的は、ユーザの介入を選択的に要求することができる、薬剤を監視および供給するシステムを提供することである。
【００１４】
本発明のこれらの、または他の目的、特徴、または利点は、本明細書および特許請求の範囲から明らかになる。
【課題を解決するための手段】
【００１５】
患者への薬剤を監視および供給するシステム、並びにそれを使用する方法が提供される。本システムは、調整または制御アルゴリズムを有するコントローラと、制御アルゴリズムを監視する自動化リスク・モニタと、を有する。具体的には、本発明は、自動化された治療の決定について患者へのリスクを監視し、また、臨床医がルールをカスタマイズするのを可能にするシステムおよび方法に向けられる。当該ルールは、治療において自動化された変更が許されることになるか、または、ユーザ／臨床医の介入が、自動化のリスクおよびカスタマイズされたルールに基づいて必要とされるべきかについて判断する。つまり、患者の状態が変化する場合、或いは患者の状態がコンピュータ化または自動化された決定システムに遅れて想定とは異なるものとなる場合に、患者に対して潜在的に不都合な結果となるリスクを最小化することができる。
【００１６】
コントローラと通信するセンサは、医療状態を監視し、当該コントローラのルール・ベース・アプリケーションにデータを供給する。加えて、ルール・ベース・アプリケーションは、閉ループ制御からデータを受け取り、該データを所定の医療情報と比較して、患者に対するリスクを判断する。リスクが所定のリスク閾値未満である場合は、薬剤すなわち治療の調整が、閉ループ・アルゴリズムによって自動化された手法で発生することが許可される。或いは、リスクが所定のリスク閾値を超える場合は、コントローラは、ユーザの介入の要求をトリガし、または、許可された自動化された治療の程度を減少させる。
【００１７】
コントローラと通信するシステム・モニタは、システムおよびリモート・システムの状態およびアクティビティを監視する。システム障害の検出に応じて、システム・モニタはデータをコントローラに供給し、処置を調整すべきかを判断して、臨床医にメッセージを送り、また、アラームを送る。同様に、システムは、ネットワーク・アクティビティを追跡し、ネットワーク障害またはリモート・システム（例えば臨床医メッセージング・システム）の障害を検出する。提示される状態に応じて、アラーム・システムは、送られるアラームをエスカレートさせる。
【図面の簡単な説明】
【００１８】
【図１】図１は、本発明の自動化リスク・モニタによって拡張される閉ループ制御システムの概略ブロック図である。
【図２】図２は、本発明のための例示のメッセージング図である。
【図３】図３は、準自動化グルコース管理システムのアーキテクチャを示す概略ブロック図である。
【図４】図４は、自動化リスク監視システムの概略ブロック図である。
【図５】図５は、本発明のシステム・モニタによって拡張される閉ループ制御システムの概略ブロック図である。
【発明を実施するための形態】
【００１９】
図１に、患者１２に対する薬剤（例えばインスリン）の監視および供給を行うシステム１０を示す。システム１０は、制御アルゴリズムおよび自動化リスク・モニタ１５を利用するコントローラ１４を含み、全てが閉ループで示される。センサ１６はコントローラ１４と通信し、また、患者１２の医療状態を監視する。コントローラ１４が有する自動化リスク・モニタのルール・ベース・アプリケーション１８（例えば、図４参照）は、センサ１６からデータを受け取り、該データを所定の医療情報と比較して、患者１２に対するリスクを判断して、薬剤の供給を自動化することができる。
【００２０】
ルール・ベース・アプリケーション１８は、投与されている治療およびそのクリティカル度(criticality)を評価するように設定することができる。更に、ルール・ベース・アプリケーション１８は、現在投与されている薬および患者１２の特性（例えば、食物摂取、流体摂取、および疾患の状態）を評価することができる。患者の生理的反応変数（例えば、枢要部、ラボ(lab)、および認知の評価）はまた、ルール・ベース・アプリケーション１８によって使用されて、患者へのリスクを判断するように設定することもできる。ルール・ベース・アプリケーション１８はまた、患者のリスク・パラメータ（例えば患者の状態の変化および治療の遷移（例えば治療の開始、継続、変更、または終了））に関するファクタを含めるようにセットすることもできる。
【００２１】
一実施形態におけるルール・ベース・アプリケーション１８は、自動化が受け入れられるときについて医師または臨床医に入力される状態を含む。医師が入力する状態は、治療の重要性（例えばクリティカル、生命維持、補足、および良性）を含むことができる。更に、臨床医は、薬剤について、フェイル・セーフ、フェイル・オペレート、およびフェイル・ストップの状態を確立することができる。これら状態は、厳格なルールに基づく、または状態の範囲に基づくものである。つまり、システム１０は、臨床医メッセージング・システム２０と通信し、自動化のリスクを受け入れることができないときに臨床医に通信する。好適な実施形態では、メッセージング・システムは、システム１０からリモートにある。
【００２２】
ルール・ベース・アプリケーション１８は、一実施形態では、リスク・プロファイルを含むことができる。臨床医は、測定基準にしたがってリスク・プロファイルを実装する。測定基準は、質的なもの（低、中、または高）、或いは量的なもの（１０を最高リスクとして１から１０まで）としてもよく、また、介入を要するときを規定する閾値としてもよい。何れの場合でも、量的な測定基準は、内部的に計算され、量的閾値と比較される。例えば、低、中、または高のそれぞれの質的測定基準は、例えば、２、５、７のような量的な値がそれぞれ割り当てられる。従って、リスク・スケールが特定され、閾値を超過すると介入が要求される。ルール・ベース・アプリケーション１８はまた、リスクの判断を可能にするために開発されたリスク・マトリクスを含むこともできる。マトリクスは、最終的には内部的に格納されるが、マトリックスはユーザによってパラメータ化することができる。リスク・マトリクスの一例を以下に示す。
【００２３】
【表１】
2017524414.tif 000003
【００２４】
具体的には、２番目の列は、計算されたインスリン・レベル、または閉ループ・コントローラから要求されたインスリン・レベルである。表は、処理状態がどのようにリスク・レベルにマップされるかについての例である。この情報を実装するための他の方法は多数存在する。この情報は、連続写像関数(continuous mapping function)、ファジー論理、確率計算などを含んでもよい。
【００２５】
この種別のシステムを提供する２番目の方法は、以下に示すように将来のグルコース・レベルを予測するインスリン／グルコースの薬物生体反応学／薬理学（pharmacokinetic/pharmacodynamic）のモデルを採用することである。臨床医は、次いで、グルコース・レベルおよび派生物(derivative)ではなく、或いはことに加えて、予測モデルを使用することができる。
【数１】
2017524414.tif 000004
【００２６】
数式（１）〜（３）では、Ｇ（ｔ）［ｍｍｏｌ／Ｌ］は、総血漿グルコース濃度を表す。また、Ｉ（ｔ）［ｍＵ／Ｌ］は血漿インスリン濃度である。時間と共に利用されてきたこれまでに注入済みのインスリンの効能は、本システムにおいてインスリンの有効耐用期間の主要因となるｋ［ｌ／ｍｉｎ］を用いて、Ｑ（ｔ）［ｍＵ／Ｌ］で表される。外因的な(Exogenous)インスリン注入速度がｕｅｘ（ｔ）［ｍＵ／ｍｉｎ］によって表される一方、Ｐ（ｔ）［ｍｍｏｌ／Ｌｍｉｎ］が外因的なグルコース注入速度である。時間を通じた患者の外因的なグルコース除去およびインスリン感受性は、それぞれ、ｐＧ（ｔ）［ｌ／ｍｉｎ］およびＳＩ（ｔ）［Ｌ／ｍＵｍｉｎ］で表される。パラメータＶＩ［Ｌ］およびＶＧ［Ｌ］は、インスリンおよびグルコースの配分量を表し、ｎ［ｌ／ｍｉｎ］は、血漿からのインスリンの第１順序の減衰速度である。プラズマ・インスリン定数が、血漿インスリン取り込みにおける浸透(saturation)に使用されるαＩ［Ｌ／ｍＵ］、およびインスリン依存のグルコースのクリアランスにおける浸透のためのαＧ［Ｌ／ｍＵ］と共に、浸透を説明するために使用される。
【００２７】
このように、ルール・ベース・アプリケーション１８は、所定のリスク閾値を決めることにより、患者１２へのリスクを判断する。所定のリスク閾値未満では、低リスクが検出されるので、システム１０は自動化による手法で前進させて(move forward)、必要に応じて薬剤を供給する。リスクが所定のリスク閾値を超過すことになると判断される場合、コントローラは、自動化により前進させるのではなく、臨床医メッセージング・システム２０にコンタクトすることによって、ユーザの介入の要求をトリガする。
【００２８】
システム１０はまた、ヘパリン注入の間における血液凝固阻止の監視、モルヒネのような鎮痛剤の注入の間における呼吸器監視、および心血管疾患のサポートのために血管作動性の薬物投与の間における血流力学的な監視を含む、如何なる注入の形態も監視に使用することができる。
【００２９】
図１から図５を参照して最善に理解されるように、代替の実施形態では、システム１０は、コントローラ１４と通信するシステム・モニタ２２を含む。１つの構成では、システム・モニタ２２は、ネットワーク３０に対し、ネットワークのアクティビティを追跡して、ネットワーク障害が生じているかを判断することができる。システム２２はまた、リモート・システム２３によって提供される決定サポートと通信して中断(interruption)を検出する。同様に、システム・モニタ２２は、ネットワーク・アクティビティを追跡して、本システム１０と臨床医メッセージング・システム２０との間、または、臨床医による本システム１０のリモート操作を可能にする、或いは、医療記録追跡のような他のサポートに基づく他のリモート・システム２３との間で、中断が発生しているかを判断する。中断が検出される場合に、本システム１０は、臨床医により、またはルール・ベース・アプリケーション１８により設定された何れかのバックアップの注入速度で注入を継続することを可能にする。代替として、本システム１０は、デフォルト設定に基づいて注入を設定するように構成することができる。デフォルト設定は、患者１２の生理的状態および施されている治療にしたがう最小速度または最大速度を含むことができる。
【００３０】
別の実施形態では、システム・モニタ２２は、ライン・レベルのエアを検出する。この実施形態２２では、システム・モニタ２２は、ラインに存在するエアの量が、注入を中止する必要があるクリティカルなレベルであるかについて判断する。ラインのエアが検出されると、システム・モニタ２２はデータをコントローラ１４に送る。コントローラ１４は、自動化リスク・モニタ１５を使用して、システテム１０に動作を継続させるのに処置のクリティカル度が十分であるかを判断する。１つの構成では、エアがシステム・モニタ２２によって検出されると、アラームが臨床医メッセージング・システム２０を介して送られ、またはシステム１０からローカルに発せられる。システム・モニタ２２はまた、ラインのエアの検出が偽陽性であるかを判断し、更に、偽陽性が検出される場合にアラームが自動クリアされる。システム・モニタ２２はまた、存在するエアの量がクリティカルではない場合に、アラームを送らないように設定することもできる。
【００３１】
加えて、システム・モニタ２２は、閉塞が存在するかについて検出する。閉塞が検出される場合は、システム・モニタ２２は、データをコントローラ１４に送り、当該閉塞が、注入速度を調整するのに充分なリスクを提起するかについて判断する。或いは、閉塞による充分なリスクが存在することをコントローラ１４が判断する場合は、アラームをトリガし、または臨床医メッセージング・システム２０を介してメッセージを送ることができる。１つの構成では、閉塞の存在は閉塞圧レベルに基づく。
【００３２】
システム・モニタ２２が充分なエアの量または充分に大きな閉塞を検出する場合に、システム１０はバックアップ・システム２４をアクティブ化することができる。例えば、生命維持の状況では、バックアップ・システム２４がイネーブルされ、注入速度がコントローラ１４によって設定されることになる。１つの構成では、バックアップ・システム２４は、システム１０によって設定される注入パラメータを維持し、その結果、介入なしで処置を移行させることができる。
【００３３】
別の構成では、システム１０はマルチ・チャネル注入システム２６を含み、多数の処置経路すなわちチャネル２７を可能にする。１つのチャネル２７が故障したことをシステム・モニタ２２が検出すると、システム１０は、代替チャネル２７に切り替えて、薬剤を供給することができる。一実施形態では、システム１０は現在注入されている薬剤の注入量を調整して、チャネル２７の故障を補償することができる。例えば、デキストロース注入が低血糖患者１２で失敗した場合に、システム１０は、栄養素の注入を増加させて、注入されているデキストロースの不足を補償することができる。
【００３４】
一実施形態では、システム・モニタ２２は、治療調整の入力または確認のために、臨床医が臨床医監視システム２０を介してコンタクトを受けた後に、臨床医から入力を受けたかについて追跡する。臨床医が応答できなかった場合、システム・モニタ２２は、データをコントローラ１４に送り、上述したような自動化リスク・モニタ１５からの情報に基づいて処置を調整する。
【００３５】
また、アラーム・システム２８を、システム１０に含めることもできる。アラーム・システム２８は、患者リスク、不確実性および予測した結果についてのレベルにしたがって適切なアラームを送ることを判断する。この手法では、アラーム・システム２８は、最高程度のアラームを、即時の注意を要するクリティカルなイベントに関連付けて供給する。
動作中に、システム１０は、コントローラ１４の制御アルゴリズムを監視して、データを受け取る。コントローラ１４はまた、グルコース・レベルのような医療状態に関する継続的なデータをセンサ１６から受け取る。次いで、コントローラ１４は、制御アルゴリズムおよびセンサ１６からのデータを所定の医療情報と比較し、その結果、コントローラ１４は、薬剤の供給を自動化する所定のリスク閾値を判断することができる。次いで、このデータに基づいて、リスクが所定の閾値未満である場合に、自動化が許可される。また、薬剤すなわちインスリンについての命令または要求がインスリン・ポンプに供給される。つまり、インスリン供給速度は、アルゴリズム・モデルまたは使用する閉ループ・コントローラに従って自動的に更新される。或いは、リスクが所定の閾値であるかそれ未満である場合に、ユーザの介入についての要求がトリガされ、メッセージが臨床医メッセージング・システム２０に送られる。その結果、ユーザが介入して、薬剤が供給されるべきかについて判断を行うことができる。介入の要求が発生すると、双方向のメッセージング・システムを通じてユーザに直接送られる。メッセージ・システム２０は、情報を提供して、ユーザ応答を要求する。応答が治療の変更に関するものであるときは認証ステップが含まれる。
【００３６】
要求への応答は、システムのユーザ・インタフェースを通じて直接的にユーザによって供給される。或いは、肯定的または否定的な応答に特有の一意の識別子を含む認証済みのメッセージング・システムを通じて、応答を返すことができる。臨床医が応答することができない場合は、より低い速度で治療が継続されるか、または全体的に中止してもよい。任意には、アラームは、アラーム・システム２８によって発生することができる。
【００３７】
通常の動作の過程において、グルコースの測定を受け、リコメンドされたインスリンの変更を生じさせることができる。しかしながら、この変更は、患者に対し治療的な利点を提供する一方、看護師からの確認を要求する重荷を与えるのに充分に重要でない場合もある。従って、自動更新または看護師による介入の要求をトリガするために、治療の変更を評価するルール・ベース・アプリケーション１８が提供される。ルール・ベース・アプリケーション１８への入力は、血液グルコース・レベル、グルコースの変更、インスリン注入、インスリン注入のリコメンドされた変更、推定された投与中のインスリン、および将来に予測されるグルコースを含む。閾値、回帰式、および計算との比較を含むルールが生成される。ルールは、入力に基づいて治療の更新をトリガする。
【００３８】
システム１０、リモート・システム２３、またはネットワーク３０の通常の動作への介入がシステム・モニタ２２によって検出された場合に、本システムは、システム１０の注入速度を変更することによって、またはバックアップ・システム２４に切り替えることによって、治療を調整する。加えて、本システム１０においてマルチ・チャネルの注入２６を用いて介入が検出されると、システム１０は、注入速度、または注入に使用されるチャネル２７を変更し、その結果、チャネル２７の故障を補償することができる。
【００３９】
命令の要求が行われるときに、または、通常の動作への介入が検出されるときに、アラーム・システム２８は、送るべき適切なアラームを決定する。最高位のアラームは、システム１０における最もクリティカルな障害または患者１２へのリスクに基づいて、アラーム・システム２８によって送られる。
【００４０】
つまり、本システムを使用して、診断値、診断値の変更、現在の薬注入速度、更新された薬注入速度、処置目標範囲、ネットワーク障害、システム障害、および臨床医の活動休止(inactivity)に基づいて、ユーザの介入を必要とする処置決定の判断を行うことができる。加えて、本システムは、介入を必要とすることを臨床医に通知し、また、該通知に応じて実施する臨床医指示を受ける。
【００４１】
本システム１０は、臨床医の介入が必要であるとき、および不要であるときを判断するので、追加の利点が示される。具体的には、本システム１０は、適応型の制御アルゴリズムまたはコンピュータ化されたプロトコルからは独立している。本システム１０は、閉ループ・システムのパフォーマンスをウォッチするスーパバイザとして機能する。その結果、閉ループ・システムおよび診断センサ１６からのデータがルール・ベース・アプリケーション１８に供給される。ルール・ベース・アプリケーション１８はマトリクスを使用して、リスクの量的レベルを生成することができる。リスクのレベルは、上述した表に示される「高」「低」「中」の値のような別個の全般レベルとして表現することができ、或いは、リスクのレベルは、数値、スコア、インデックスまたはパーセンテージとすることができる。リスクは、特定のリスク閾値と比較され、治療に進むために「オーケー」を生成および／または供給するか、或いは、ユーザの介入のために要求をトリガすることができる。
【００４２】
当該動作は、自動化のリスクを判断しない現在のシステムとは異なる。従来技術のシステムは、潜在的なリスクに関係なく自動化を生じさせるのを可能にし、次いで、患者が受け入れることができない医療状態を経験していることをセンサが示すときに、臨床医がアラートされる。それ故、本システム１０は、自動化プロセスおよび自動化の所定のリスクを監視する結果として、受け入れることができない医療状態を、第１の場所で生じるのを防止するという利点を提供する。
【００４３】
本システム１０は、システム１０、リモート・システム２３、ネットワーク３０、および臨床医の活動休止の障害を検出するという点で更なる利点が見いだされる。これら障害または患者に晒されるリスクの内の１つの検出に応じて、アラーム・システム２８は、患者１２またはシステム１０への変更に基づき患者１２に晒される１または複数のリスクに基づいて、アラームをエスカレートさせる。このように、上述した目的の少なくとも全てが完全に満たされている。
【図１】
2017524414.tif 000005
【図２】
2017524414.tif 000006
【図３】
2017524414.tif 000007
【図４】
2017524414.tif 000008
【図５】
2017524414.tif 000009
【国際調査報告】
2017524414.tif 000010