IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ アイシーユー・メディカル・インコーポレーテッドの特許一覧

特許7080008患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法
<>
  • 特許-患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法 図1
  • 特許-患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法 図2
  • 特許-患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法 図3
  • 特許-患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法 図4
  • 特許-患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法 図5
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-05-26
(45)【発行日】2022-06-03
(54)【発明の名称】患者への薬剤を監視および供給するシステム、およびそれを使用して、自動化した治療に伴うリスクを最小化させる方法
(51)【国際特許分類】
   A61M 5/168 20060101AFI20220527BHJP
   A61M 5/36 20060101ALI20220527BHJP
   G16H 10/00 20180101ALI20220527BHJP
【FI】
A61M5/168 520
A61M5/168 550
A61M5/36 500
G16H10/00
【請求項の数】 8
(21)【出願番号】P 2016573781
(86)(22)【出願日】2015-06-16
(65)【公表番号】
(43)【公表日】2017-08-31
(86)【国際出願番号】 US2015036058
(87)【国際公開番号】W WO2015195683
(87)【国際公開日】2015-12-23
【審査請求日】2018-05-23
【審判番号】
【審判請求日】2021-01-08
(31)【優先権主張番号】62/012,756
(32)【優先日】2014-06-16
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】14/739,840
(32)【優先日】2015-06-15
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】508004797
【氏名又は名称】アイシーユー・メディカル・インコーポレーテッド
(74)【代理人】
【識別番号】100118902
【弁理士】
【氏名又は名称】山本 修
(74)【代理人】
【識別番号】100106208
【弁理士】
【氏名又は名称】宮前 徹
(74)【代理人】
【識別番号】100173565
【弁理士】
【氏名又は名称】末松 亮太
(72)【発明者】
【氏名】デイ,ウィリアム
(72)【発明者】
【氏名】ルッティ,ティモシー
【合議体】
【審判長】千壽 哲郎
【審判官】村上 聡
【審判官】倉橋 紀夫
(56)【参考文献】
【文献】米国特許出願公開第2013/0158504(US,A1)
【文献】米国特許出願公開第2014/0163517(US,A1)
【文献】特開2014-68283(JP,A)
【文献】米国特許出願公開第2012/0283630(US,A1)
【文献】米国特許出願公開第2009/0177146(US,A1)
【文献】特開2012-011204(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
A61M5/168-5/175
(57)【特許請求の範囲】
【請求項1】
患者に薬剤を供給するシステムであって、
閉ループ制御アルゴリズムを有し、前記閉ループ制御アルゴリズムを監視する自動化リスク・モニタを備えるコントローラと、
前記コントローラおよび前記自動化リスク・モニタと通信するセンサであって、前記患者の医療状態を監視するように構成されるセンサと、
前記自動化リスク・モニタのルール・ベース・アプリケーションであって、
前記薬剤を供給している間に、前記センサおよび前記閉ループ制御アルゴリズムからデータを受け取り、
前記データを所定の医療情報と比較して、前記閉ループ制御アルゴリズムを動作させることの前記患者に対するリスクを判断する、ルール・ベース・アプリケーションと、
ネットワーク、前記コントローラおよび前記自動化リスク・モニタと通信するシステム・モニタと、
マルチ・チャネル注入システムと、
を備え、
前記システム・モニタが、
前記ネットワークを介してメッセージング・システムと通信し、
前記通信の中断を検出する
ように構成され
前記通信の中断が前記システム・モニタによって検出された場合に、前記ルール・ベース・アプリケーションによって設定される、前記閉ループ制御アルゴリズムとは異なるプロトコルを用いて、前記薬剤の供給継続されることを特徴とする、システム。
【請求項2】
前記システム・モニタがラインの閉塞圧レベルを検出する、請求項1記載のシステム。
【請求項3】
前記システム・モニタがラインのエア・レベルを検出する、請求項1または2記載のシステム。
【請求項4】
請求項1から3の何れか一項記載のシステムにおいて、前記コントローラが薬剤供給デバイスを制御して、前記リスクの所定のリスク閾値との比較に基づいて薬剤を前記患者に供給する、システム。
【請求項5】
請求項4記載のシステムにおいて、前記システム・モニタが充分なエアの量または充分に大きな閉塞を検出する場合に、前記コントローラが、バックアップ・システムをアクティブ化させて、前記患者への前記薬剤の供給を、前記薬剤供給デバイスから前記バックアップ・システムに移行させるように構成され、
前記バックアップ・システムがアクティブ化されると、前記バックアップ・システムが、前記薬剤供給デバイスの注入パラメータを維持し、前記注入パラメータを用いて前記薬剤を継続して前記患者に供給するように構成される、システム。
【請求項6】
前記システム・モニタが、前記患者に対する前記リスクに基づいて判断される、臨床医が応じるべき失敗を検出する、請求項1から5の何れか一項記載のシステム。
【請求項7】
前記患者に対する前記リスクが、前記センサおよび前記システム・モニタからのデータに基づいて、前記自動化リスク・モニタによって判断される、請求項1から6の何れか一項記載のシステム。
【請求項8】
前記システム・モニタがシステムのアクティビティを監視する、請求項1から7の何れか一項記載のシステム。
【発明の詳細な説明】
【背景技術】
【0001】
本発明は、患者への薬剤を監視および供給するシステムに関するものである。具体的には、本発明は、自動化した治療の判断について患者に対するリスクを監視し、臨床医によってルールをカスタマイズするのを可能にするデバイスに向けられるものである。当該ルールは、治療において変更が自動化されることが許可されるか、またはユーザ/臨床医の介入が、自動化およびカスタマイズされたルールのリスクに基づいて必要とされるべきかについて判断する。
【0002】
糖尿病は、世界中で何千万の人々をも悩ます代謝性疾患である。糖尿病は、糖質(特に、グルコース)を適切に利用および代謝させる身体の不全による結果である。通常、血液中のグルコースおよび身体組織細胞中のグルコースの間で微細に調整されるバランスはインスリンによって維持され、ホルモンは、とりわけ血液から身体組織細胞へのグルコースの輸送を制御する膵臓によって分泌される。このバランスを乱すことは、心臓病、冠状動脈および末梢動脈の硬化症、末梢性神経障害、並びに低血糖ショックからの死亡を含む、数多くの合併症および病状を引き起こす。
【0003】
インスリンに依存した糖尿病を有する患者において、疾患の症状は、注射により、または、外部若しくは植込み型のインスリン・ポンプにより、追加のインスリン(または類似の効果を奏する他の薬品)を投与することで制御することができる。正確なインスリンの投薬量は、血液中のグルコースのレベルの関数となる。理想的には、インスリンの投与は、血液のグルコース・レベルの変化に応じて、継続的に再調整がなされるべきである。糖尿病の管理では、インスリンは、身体の細胞による血液からのグルコースの取り込みを可能にする。グルカゴンはインスリンとは対照的に作用し、肝臓に、グルコースの血流への放出を行わせる。基本速度(basal rate)は、インスリン送給用デバイス(ポンプ)により提供されるインスリンの継続供給の速度である。ボーラスは特定量のインスリンであり、(継続的ではなく)必要に応じてインスリンの血中濃度を有効レベルに引き上げるために与えられる。
【0004】
現在のところ、グルコース感受性プローブを患者の皮下層または血管区画に挿入することによって、或いは、血管アクセス・ポイントからセンサまで周期的に出血させることによって、血液グルコース・レベルを継続的に監視するシステムが利用可能である。このようなプローブでは、血液、または、光吸収、電気化学ポテンシャルおよび酵素生成物を含む他の組織が有する様々な特性を測定する。このようなセンサの出力はハンド・ヘルド・デバイスに通信することができる。ハンド・ヘルド・デバイスは、幾らかの要因(例えば、患者の現在のグルコース・レベルおよび変化率、インスリン投与率、消費されることになる炭水化物、ステロイド使用、腎臓や肝臓の状態、および運動)に鑑みて、血流に供給されることになるインスリンの適切な適用量を計算するのに使用される。次いで、これら計算を用いて、ポンプが、制御された基本速度で、或いは周期的または一度のボーラスのいずれかで、インスリンを供給することを制御することができる。統合化されたシステムとして提供される場合、継続的なグルコース・モニタ、コントローラ、およびポンプが協働する結果、継続的なグルコースの監視およびインスリンのポンプ制御を提供することができる。
【0005】
現在のところ、このようなシステムは、供給されることになるインスリンの量を計算および制御するために、患者または臨床医による介入を必要とする。しかしながら、患者がインスリンの供給を調整することができない期間が存在することもある。例えば、患者が睡眠中のとき、彼または彼女はインスリンの供給に介入することができないにも拘わらず、患者のグルコース・レベルの制御は尚も必要とされる。グルコースの監視および制御されたインスリンの供給についての機能を統合および自動化することが可能なシステムは、特にそれらに介入できない日の期間中において、患者によるそれらグルコース・レベルの維持を支援するのに有用となろう。
【0006】
或いは、病院環境において最適なグルコース管理システムは、インスリンの供給速度を、上述した変数に応じて頻繁に調整することを含む。しかしながら、臨床医側の恒常的な介入は重荷であり、ほとんどのグルコース管理システムでは、インスリンの更新の間の時間間隔を最大化するように設計されている。インスリン供給のための低リスクの判断を安全に自動化できるシステムは、患者のインスリン治療を改善し、臨床医のワークフローをサポートするのに有用となろう。
【0007】
2000年から、少なくとも5つの継続的または半継続的なグルコース・モニタが、規制認可を受けた。継続的な皮下インスリン注入(CSII)と組み合わせて、これらデバイスは、閉ループ・システムへの研究を促進してきた。グルコース・レベルの変更へのリアル・タイムの応答に欠く開ループ・システムとは対照的に、閉ループ・システムは、リアル・タイムのニーズに従ってインスリンを供給する。閉ループ・システムはまた、人工膵臓とも称され、3つの構成要素から成る。即ち、グルコース監視デバイス(例えば、皮下グルコース濃度(SC)を測定する継続的なグルコース・モニタ(CGM))、分析物(例えば、供給されることになるインスリンおよび/またはグルカゴン)の量を計算する滴定アルゴリズム、および計算された分析物の投与量を皮下に供給する1つ以上の分析物ポンプである。幾らかのプロトタイプ・システムが開発され、テストされ、そして、臨床およびシミュレーションされた家庭環境での評価に基づいてレポートされている。この強力による効果は、閉ループ・システムの家庭でのテストに向けて、進展の加速を約束するものである。
【0008】
同様に、閉ループ・システムは、病院環境についても提案されており、主に動物実験を通じて、研究中のデバイスが開発され、テストされている。加えて、幾らかの製造業者は、入院患者へのテストのために設計された、FDA自動化グルコース測定システムを開発している段階にあるか、またはこれを受け入れている。このようなシステムは、入院患者のグルコース管理について完全に自動化されたシステムの開発を加速することになる。
【0009】
インスリン治療についての閉ループ制御または完全自動化が有する第一の課題は、コンピュータ化された判断システムに遅れて(behind)患者の状態が想定から変化し、または想定とは異なるものとなる場合に、見込まれる結果に関して高リスクとなり得る決定を、コンピュータ化されたシステムが行うということである。自動化した結果として、リスクが認識され、患者が容認できない医療状態を示すまで、これら高リスクな決定は発見(uncover)されない。第二に、デバイスの障害、または薬剤投与管理システムすなわちMMSの障害が生じた場合に、情報の潜在的な不足にも拘わらず、自動化システムによってアクションが要求される。第三に、グルコース測定値が頻繁に自動収集されるものの自動化が望まれていないというシナリオでは、グルコース測定値が収集されるのと同じ頻度で注入を更新するというのは望ましいことではない。第四に、ユーザによる介入が必要とされるときに、臨床医がベッドサイドで応じることは望ましくなく、または困難となる場合がある。例えば、患者が隔離部屋にいるものの観察可能である場合に、臨床医は部屋に入ることなく注入速度を更新することを望む場合がある。
【発明の概要】
【発明が解決しようとする課題】
【0010】
従って、本発明の原則的な目的は、治療を提供する前にリスクの判断を行う、患者への薬剤を監視および供給するための改良システムを提供することである。
【0011】
本発明の別の目的は、デバイス障害、患者の状態および状況、並びに不確実性をマップすることにより、患者のリスクを最小化するシステムを提供することである。
【0012】
本発明の更なる別の目的は、患者へのリスクを最小化する、患者への薬剤を監視および供給するためのシステムを提供することである。
【0013】
本発明の別の目的は、ユーザの介入を選択的に要求することができる、薬剤を監視および供給するシステムを提供することである。
【0014】
本発明のこれらの、または他の目的、特徴、または利点は、本明細書および特許請求の範囲から明らかになる。
【課題を解決するための手段】
【0015】
患者への薬剤を監視および供給するシステム、並びにそれを使用する方法が提供される。本システムは、調整または制御アルゴリズムを有するコントローラと、制御アルゴリズムを監視する自動化リスク・モニタと、を有する。具体的には、本発明は、自動化された治療の決定について患者へのリスクを監視し、また、臨床医がルールをカスタマイズするのを可能にするシステムおよび方法に向けられる。当該ルールは、治療において自動化された変更が許されることになるか、または、ユーザ/臨床医の介入が、自動化のリスクおよびカスタマイズされたルールに基づいて必要とされるべきかについて判断する。つまり、患者の状態が変化する場合、或いは患者の状態がコンピュータ化または自動化された決定システムに遅れて想定とは異なるものとなる場合に、患者に対して潜在的に不都合な結果となるリスクを最小化することができる。
【0016】
コントローラと通信するセンサは、医療状態を監視し、当該コントローラのルール・ベース・アプリケーションにデータを供給する。加えて、ルール・ベース・アプリケーションは、閉ループ制御からデータを受け取り、該データを所定の医療情報と比較して、患者に対するリスクを判断する。リスクが所定のリスク閾値未満である場合は、薬剤すなわち治療の調整が、閉ループ・アルゴリズムによって自動化された手法で発生することが許可される。或いは、リスクが所定のリスク閾値を超える場合は、コントローラは、ユーザの介入の要求をトリガし、または、許可された自動化された治療の程度を減少させる。
【0017】
コントローラと通信するシステム・モニタは、システムおよびリモート・システムの状態およびアクティビティを監視する。システム障害の検出に応じて、システム・モニタはデータをコントローラに供給し、処置を調整すべきかを判断して、臨床医にメッセージを送り、また、アラームを送る。同様に、システムは、ネットワーク・アクティビティを追跡し、ネットワーク障害またはリモート・システム(例えば臨床医メッセージング・システム)の障害を検出する。提示される状態に応じて、アラーム・システムは、送られるアラームをエスカレートさせる。
【図面の簡単な説明】
【0018】
図1図1は、本発明の自動化リスク・モニタによって拡張される閉ループ制御システムの概略ブロック図である。
図2図2は、本発明のための例示のメッセージング図である。
図3図3は、準自動化グルコース管理システムのアーキテクチャを示す概略ブロック図である。
図4図4は、自動化リスク監視システムの概略ブロック図である。
図5図5は、本発明のシステム・モニタによって拡張される閉ループ制御システムの概略ブロック図である。
【発明を実施するための形態】
【0019】
図1に、患者12に対する薬剤(例えばインスリン)の監視および供給を行うシステム10を示す。システム10は、制御アルゴリズムおよび自動化リスク・モニタ15を利用するコントローラ14を含み、全てが閉ループで示される。センサ16はコントローラ14と通信し、また、患者12の医療状態を監視する。コントローラ14が有する自動化リスク・モニタのルール・ベース・アプリケーション18(例えば、図4参照)は、センサ16からデータを受け取り、該データを所定の医療情報と比較して、患者12に対するリスクを判断して、薬剤の供給を自動化することができる。
【0020】
ルール・ベース・アプリケーション18は、投与されている治療およびそのクリティカル度(criticality)を評価するように設定することができる。更に、ルール・ベース・アプリケーション18は、現在投与されている薬および患者12の特性(例えば、食物摂取、流体摂取、および疾患の状態)を評価することができる。患者の生理的反応変数(例えば、枢要部、ラボ(lab)、および認知の評価)はまた、ルール・ベース・アプリケーション18によって使用されて、患者へのリスクを判断するように設定することもできる。ルール・ベース・アプリケーション18はまた、患者のリスク・パラメータ(例えば患者の状態の変化および治療の遷移(例えば治療の開始、継続、変更、または終了))に関するファクタを含めるようにセットすることもできる。
【0021】
一実施形態におけるルール・ベース・アプリケーション18は、自動化が受け入れられるときについて医師または臨床医に入力される状態を含む。医師が入力する状態は、治療の重要性(例えばクリティカル、生命維持、補足、および良性)を含むことができる。更に、臨床医は、薬剤について、フェイル・セーフ、フェイル・オペレート、およびフェイル・ストップの状態を確立することができる。これら状態は、厳格なルールに基づく、または状態の範囲に基づくものである。つまり、システム10は、臨床医メッセージング・システム20と通信し、自動化のリスクを受け入れることができないときに臨床医に通信する。好適な実施形態では、メッセージング・システムは、システム10からリモートにある。
【0022】
ルール・ベース・アプリケーション18は、一実施形態では、リスク・プロファイルを含むことができる。臨床医は、測定基準にしたがってリスク・プロファイルを実装する。測定基準は、質的なもの(低、中、または高)、或いは量的なもの(10を最高リスクとして1から10まで)としてもよく、また、介入を要するときを規定する閾値としてもよい。何れの場合でも、量的な測定基準は、内部的に計算され、量的閾値と比較される。例えば、低、中、または高のそれぞれの質的測定基準は、例えば、2、5、7のような量的な値がそれぞれ割り当てられる。従って、リスク・スケールが特定され、閾値を超過すると介入が要求される。ルール・ベース・アプリケーション18はまた、リスクの判断を可能にするために開発されたリスク・マトリクスを含むこともできる。マトリクスは、最終的には内部的に格納されるが、マトリックスはユーザによってパラメータ化することができる。リスク・マトリクスの一例を以下に示す。
【0023】
【表1】

【0024】
具体的には、2番目の列は、計算されたインスリン・レベル、または閉ループ・コントローラから要求されたインスリン・レベルである。表は、処理状態がどのようにリスク・レベルにマップされるかについての例である。この情報を実装するための他の方法は多数存在する。この情報は、連続写像関数(continuous mapping function)、ファジー論理、確率計算などを含んでもよい。
【0025】
この種別のシステムを提供する2番目の方法は、以下に示すように将来のグルコース・レベルを予測するインスリン/グルコースの薬物生体反応学/薬理学(pharmacokinetic/pharmacodynamic)のモデルを採用することである。臨床医は、次いで、グルコース・レベルおよび派生物(derivative)ではなく、或いはことに加えて、予測モデルを使用することができる。
【数1】
【0026】
数式(1)~(3)では、G(t)[mmol/L]は、総血漿グルコース濃度を表す。また、I(t)[mU/L]は血漿インスリン濃度である。時間と共に利用されてきたこれまでに注入済みのインスリンの効能は、本システムにおいてインスリンの有効耐用期間の主要因となるk[l/min]を用いて、Q(t)[mU/L]で表される。外因的な(Exogenous)インスリン注入速度がuex(t)[mU/min]によって表される一方、P(t)[mmol/Lmin]が外因的なグルコース注入速度である。時間を通じた患者の外因的なグルコース除去およびインスリン感受性は、それぞれ、p(t)[l/min]およびS(t)[L/mUmin]で表される。パラメータV[L]およびV[L]は、インスリンおよびグルコースの配分量を表し、n[l/min]は、血漿からのインスリンの第1順序の減衰速度である。プラズマ・インスリン定数が、血漿インスリン取り込みにおける浸透(saturation)に使用されるα[L/mU]、およびインスリン依存のグルコースのクリアランスにおける浸透のためのα[L/mU]と共に、浸透を説明するために使用される。
【0027】
このように、ルール・ベース・アプリケーション18は、所定のリスク閾値を決めることにより、患者12へのリスクを判断する。所定のリスク閾値未満では、低リスクが検出されるので、システム10は自動化による手法で前進させて(move forward)、必要に応じて薬剤を供給する。リスクが所定のリスク閾値を超過すことになると判断される場合、コントローラは、自動化により前進させるのではなく、臨床医メッセージング・システム20にコンタクトすることによって、ユーザの介入の要求をトリガする。
【0028】
システム10はまた、ヘパリン注入の間における血液凝固阻止の監視、モルヒネのような鎮痛剤の注入の間における呼吸器監視、および心血管疾患のサポートのために血管作動性の薬物投与の間における血流力学的な監視を含む、如何なる注入の形態も監視に使用することができる。
【0029】
図1から図5を参照して最善に理解されるように、代替の実施形態では、システム10は、コントローラ14と通信するシステム・モニタ22を含む。1つの構成では、システム・モニタ22は、ネットワーク30に対し、ネットワークのアクティビティを追跡して、ネットワーク障害が生じているかを判断することができる。システム22はまた、リモート・システム23によって提供される決定サポートと通信して中断(interruption)を検出する。同様に、システム・モニタ22は、ネットワーク・アクティビティを追跡して、本システム10と臨床医メッセージング・システム20との間、または、臨床医による本システム10のリモート操作を可能にする、或いは、医療記録追跡のような他のサポートに基づく他のリモート・システム23との間で、中断が発生しているかを判断する。中断が検出される場合に、本システム10は、臨床医により、またはルール・ベース・アプリケーション18により設定された何れかのバックアップの注入速度で注入を継続することを可能にする。代替として、本システム10は、デフォルト設定に基づいて注入を設定するように構成することができる。デフォルト設定は、患者12の生理的状態および施されている治療にしたがう最小速度または最大速度を含むことができる。
【0030】
別の実施形態では、システム・モニタ22は、ライン・レベルのエアを検出する。この実施形態22では、システム・モニタ22は、ラインに存在するエアの量が、注入を中止する必要があるクリティカルなレベルであるかについて判断する。ラインのエアが検出されると、システム・モニタ22はデータをコントローラ14に送る。コントローラ14は、自動化リスク・モニタ15を使用して、システテム10に動作を継続させるのに処置のクリティカル度が十分であるかを判断する。1つの構成では、エアがシステム・モニタ22によって検出されると、アラームが臨床医メッセージング・システム20を介して送られ、またはシステム10からローカルに発せられる。システム・モニタ22はまた、ラインのエアの検出が偽陽性であるかを判断し、更に、偽陽性が検出される場合にアラームが自動クリアされる。システム・モニタ22はまた、存在するエアの量がクリティカルではない場合に、アラームを送らないように設定することもできる。
【0031】
加えて、システム・モニタ22は、閉塞が存在するかについて検出する。閉塞が検出される場合は、システム・モニタ22は、データをコントローラ14に送り、当該閉塞が、注入速度を調整するのに充分なリスクを提起するかについて判断する。或いは、閉塞による充分なリスクが存在することをコントローラ14が判断する場合は、アラームをトリガし、または臨床医メッセージング・システム20を介してメッセージを送ることができる。1つの構成では、閉塞の存在は閉塞圧レベルに基づく。
【0032】
システム・モニタ22が充分なエアの量または充分に大きな閉塞を検出する場合に、システム10はバックアップ・システム24をアクティブ化することができる。例えば、生命維持の状況では、バックアップ・システム24がイネーブルされ、注入速度がコントローラ14によって設定されることになる。1つの構成では、バックアップ・システム24は、システム10によって設定される注入パラメータを維持し、その結果、介入なしで処置を移行させることができる。
【0033】
別の構成では、システム10はマルチ・チャネル注入システム26を含み、多数の処置経路すなわちチャネル27を可能にする。1つのチャネル27が故障したことをシステム・モニタ22が検出すると、システム10は、代替チャネル27に切り替えて、薬剤を供給することができる。一実施形態では、システム10は現在注入されている薬剤の注入量を調整して、チャネル27の故障を補償することができる。例えば、デキストロース注入が低血糖患者12で失敗した場合に、システム10は、栄養素の注入を増加させて、注入されているデキストロースの不足を補償することができる。
【0034】
一実施形態では、システム・モニタ22は、治療調整の入力または確認のために、臨床医が臨床医監視システム20を介してコンタクトを受けた後に、臨床医から入力を受けたかについて追跡する。臨床医が応答できなかった場合、システム・モニタ22は、データをコントローラ14に送り、上述したような自動化リスク・モニタ15からの情報に基づいて処置を調整する。
【0035】
また、アラーム・システム28を、システム10に含めることもできる。アラーム・システム28は、患者リスク、不確実性および予測した結果についてのレベルにしたがって適切なアラームを送ることを判断する。この手法では、アラーム・システム28は、最高程度のアラームを、即時の注意を要するクリティカルなイベントに関連付けて供給する。
動作中に、システム10は、コントローラ14の制御アルゴリズムを監視して、データを受け取る。コントローラ14はまた、グルコース・レベルのような医療状態に関する継続的なデータをセンサ16から受け取る。次いで、コントローラ14は、制御アルゴリズムおよびセンサ16からのデータを所定の医療情報と比較し、その結果、コントローラ14は、薬剤の供給を自動化する所定のリスク閾値を判断することができる。次いで、このデータに基づいて、リスクが所定の閾値未満である場合に、自動化が許可される。また、薬剤すなわちインスリンについての命令または要求がインスリン・ポンプに供給される。つまり、インスリン供給速度は、アルゴリズム・モデルまたは使用する閉ループ・コントローラに従って自動的に更新される。或いは、リスクが所定の閾値であるかそれ未満である場合に、ユーザの介入についての要求がトリガされ、メッセージが臨床医メッセージング・システム20に送られる。その結果、ユーザが介入して、薬剤が供給されるべきかについて判断を行うことができる。介入の要求が発生すると、双方向のメッセージング・システムを通じてユーザに直接送られる。メッセージ・システム20は、情報を提供して、ユーザ応答を要求する。応答が治療の変更に関するものであるときは認証ステップが含まれる。
【0036】
要求への応答は、システムのユーザ・インタフェースを通じて直接的にユーザによって供給される。或いは、肯定的または否定的な応答に特有の一意の識別子を含む認証済みのメッセージング・システムを通じて、応答を返すことができる。臨床医が応答することができない場合は、より低い速度で治療が継続されるか、または全体的に中止してもよい。任意には、アラームは、アラーム・システム28によって発生することができる。
【0037】
通常の動作の過程において、グルコースの測定を受け、リコメンドされたインスリンの変更を生じさせることができる。しかしながら、この変更は、患者に対し治療的な利点を提供する一方、看護師からの確認を要求する重荷を与えるのに充分に重要でない場合もある。従って、自動更新または看護師による介入の要求をトリガするために、治療の変更を評価するルール・ベース・アプリケーション18が提供される。ルール・ベース・アプリケーション18への入力は、血液グルコース・レベル、グルコースの変更、インスリン注入、インスリン注入のリコメンドされた変更、推定された投与中のインスリン、および将来に予測されるグルコースを含む。閾値、回帰式、および計算との比較を含むルールが生成される。ルールは、入力に基づいて治療の更新をトリガする。
【0038】
システム10、リモート・システム23、またはネットワーク30の通常の動作への介入がシステム・モニタ22によって検出された場合に、本システムは、システム10の注入速度を変更することによって、またはバックアップ・システム24に切り替えることによって、治療を調整する。加えて、本システム10においてマルチ・チャネルの注入26を用いて介入が検出されると、システム10は、注入速度、または注入に使用されるチャネル27を変更し、その結果、チャネル27の故障を補償することができる。
【0039】
命令の要求が行われるときに、または、通常の動作への介入が検出されるときに、アラーム・システム28は、送るべき適切なアラームを決定する。最高位のアラームは、システム10における最もクリティカルな障害または患者12へのリスクに基づいて、アラーム・システム28によって送られる。
【0040】
つまり、本システムを使用して、診断値、診断値の変更、現在の薬注入速度、更新された薬注入速度、処置目標範囲、ネットワーク障害、システム障害、および臨床医の活動休止(inactivity)に基づいて、ユーザの介入を必要とする処置決定の判断を行うことができる。加えて、本システムは、介入を必要とすることを臨床医に通知し、また、該通知に応じて実施する臨床医指示を受ける。
【0041】
本システム10は、臨床医の介入が必要であるとき、および不要であるときを判断するので、追加の利点が示される。具体的には、本システム10は、適応型の制御アルゴリズムまたはコンピュータ化されたプロトコルからは独立している。本システム10は、閉ループ・システムのパフォーマンスをウォッチするスーパバイザとして機能する。その結果、閉ループ・システムおよび診断センサ16からのデータがルール・ベース・アプリケーション18に供給される。ルール・ベース・アプリケーション18はマトリクスを使用して、リスクの量的レベルを生成することができる。リスクのレベルは、上述した表に示される「高」「低」「中」の値のような別個の全般レベルとして表現することができ、或いは、リスクのレベルは、数値、スコア、インデックスまたはパーセンテージとすることができる。リスクは、特定のリスク閾値と比較され、治療に進むために「オーケー」を生成および/または供給するか、或いは、ユーザの介入のために要求をトリガすることができる。
【0042】
当該動作は、自動化のリスクを判断しない現在のシステムとは異なる。従来技術のシステムは、潜在的なリスクに関係なく自動化を生じさせるのを可能にし、次いで、患者が受け入れることができない医療状態を経験していることをセンサが示すときに、臨床医がアラートされる。それ故、本システム10は、自動化プロセスおよび自動化の所定のリスクを監視する結果として、受け入れることができない医療状態を、第1の場所で生じるのを防止するという利点を提供する。
【0043】
本システム10は、システム10、リモート・システム23、ネットワーク30、および臨床医の活動休止の障害を検出するという点で更なる利点が見いだされる。これら障害または患者に晒されるリスクの内の1つの検出に応じて、アラーム・システム28は、患者12またはシステム10への変更に基づき患者12に晒される1または複数のリスクに基づいて、アラームをエスカレートさせる。このように、上述した目的の少なくとも全てが完全に満たされている。
図1
図2
図3
図4
図5