特許7455813コンテナベースの医薬品投与ガイダンスを提供して、糖尿病を治療するためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-15
(45)【発行日】2024-03-26
(54)【発明の名称】コンテナベースの医薬品投与ガイダンスを提供して、糖尿病を治療するためのシステムおよび方法
(51)【国際特許分類】
G16H 20/10 20180101AFI20240318BHJP
【ＦＩ】
G16H20/10
【請求項の数】
12
(21)【出願番号】P 2021510651
(86)(22)【出願日】2019-08-27
(65)【公表番号】
(43)【公表日】2021-12-16
(86)【国際出願番号】 EP2019072872
(87)【国際公開番号】W WO2020043734
(87)【国際公開日】2020-03-05
【審査請求日】2022-08-09
(31)【優先権主張番号】62/723,744
(32)【優先日】2018-08-28
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】18208299.0
(32)【優先日】2018-11-26
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】596113096
【氏名又は名称】ノボ・ノルデイスク・エー／エス
(74)【代理人】
【識別番号】110002077
【氏名又は名称】園田・小林弁理士法人
(72)【発明者】
【氏名】ミゲリク， アラン ジョン
(72)【発明者】
【氏名】ミラー， トーマス デデンロース
【審査官】梅岡 信幸
(56)【参考文献】
【文献】特表２０１１－５０１３１１（ＪＰ，Ａ）
【文献】特表２０１８－５２３５４６（ＪＰ，Ａ）
【文献】特表２０１８－５０３８９６（ＪＰ，Ａ）
【文献】国際公開第２０１５／０４９７８９（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１７／００９１４１９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１４／０３１６７５９（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ１６Ｈ １０／００－８０／００
(57)【特許請求の範囲】
【請求項1】
一対象者の所定の血糖目標範囲を達成して、真性糖尿病の症状を治療するためのある用量のインスリン薬剤に関する医薬品投与ガイダンスを、複数の機能を含む多機能投与ガイダンスアルゴリズムを使用して複数の対象者に提供するためのコンピューティングシステムであって、前記複数の機能のうちの各それぞれの機能が、対応するコンテナクラスに関連付けられ、前記コンピューティングシステムが、一つ以上のプロセッサおよびメモリを備え、前記メモリが、－命令を含み、前記命令が、前記一つ以上のプロセッサによって実行されると、前記複数の対象者のうちのある対象者から医薬品投与ガイダンス要求を受信することに応答して方法を実施し、前記方法が、
（ｉ）前記医薬品投与ガイダンス要求を満たすために必要な複数の機能要求を識別するステップであって、前記複数の機能要求のうちのある機能要求が、前記複数の機能のうちの対応する機能によって実行可能である、識別するステップと、
（ｉｉ）エンコーダモジュールを使用して、前記複数の機能要求のうちの各それぞれの機能要求に対して、前記それぞれの機能要求および関連付けられた入力データを、前記それぞれの機能要求に対応する前記機能に関連付けられた前記コンテナクラスのコンテナに埋め込むステップと、
（ｉｉｉ）前記複数の機能要求のうちの各それぞれの機能要求に対して、前記それぞれの機能要求を実行した前記コンテナからの機能結果を収集し、それによって、複数の機能結果を取得するステップと、
（ｉｖ）前記複数の機能結果を使用して、推奨医薬品投与ガイダンスを提供するステップと、を含み、
－所与のコンテナクラスの前記コンテナに対する複合リソース要件が、定期的なベースで評価され、
－前記所与のコンテナクラスの前記コンテナに対する前記複合リソース要件が、前記所与のコンテナクラスに関連付けられたリソース割り当て閾値を満たす場合、前記所与のコンテナクラスの一つ以上の追加のコンテナが追加され、前記所与のコンテナクラスと一致する前記エンコーダモジュールからの機能要求を受理することができ、
－前記所与のコンテナクラスの前記コンテナに対する前記複合リソース要件が、前記所与のコンテナクラスに関連付けられた第２のリソース割り当て閾値を満たす場合、前記所与のコンテナクラスの一つ以上のコンテナが除去され、前記エンコーダモジュールからの機能要求をもはや受理することができず、
－前記医薬品投与ガイダンス要求が、ある用量のインスリン薬剤に関するものであり、
－前記用量のインスリン薬剤が、対象者の所定の血糖目標範囲を達成して、真性糖尿病の症状を治療するためのものである、コンピューティングシステム。
【請求項2】
－前記複数の機能が、第１の機能および第２の機能を含み、－前記第１の機能が、第１のコンテナクラスの各コンテナによって実行可能であり、
－前記第２の機能が、第２のコンテナクラスの各コンテナによって実行可能であり、
－前記第１の機能のハードウェアリソース要件が、前記第２の機能のハードウェアリソース要件とは異なる、請求項１に記載のコンピューティングシステム。
【請求項3】
－前記複数の機能が、第１の機能および第２の機能を含み、－前記第１の機能が、第１のコンテナクラスの各コンテナによって実行可能であり、
－前記第２の機能が、第２のコンテナクラスの各コンテナによって実行可能であり、
－前記第１のコンテナクラスの各コンテナが、第１のサーバのセットのうちのサーバによってホストされ、
－前記第２のコンテナクラスの各コンテナが、前記第１のサーバのセット以外の第２のサーバのセットのうちのあるサーバによってホストされる、請求項１または２のいずれか一項に記載のコンピューティングシステム。
【請求項4】
－所与の機能要求に対応する前記機能に関連付けられたコンテナクラスの所与のコンテナが、機能結果を提供するために前記機能に必要な入力データが前記それぞれの機能要求に含まれているかどうかを評価し、－前記必要な入力データが前記機能要求に含まれていない場合、前記機能に関連付けられた前記コンテナクラスの前記所与のコンテナが、いずれの機能結果も提供しない、請求項１～３のいずれか一項に記載のコンピューティングシステム。
【請求項5】
前記コンピューティングシステムが、前記複数の対象者のうちの各対象者に対して医薬品投与ガイダンス要求を同時実行する、請求項１～４のいずれか一項に記載のコンピューティングシステム。
【請求項6】
前記複数の対象者が、少なくとも１０，０００人の対象者を含む、請求項５に記載のコンピューティングシステム。
【請求項7】
前記複数の機能が、－対象者の推奨医薬品投与ガイダンスを計算すること、
－対象者のインスリン注射履歴を再構成すること、
－対象者の滴定グルコースレベルを計算すること、
－対象者の血糖履歴を再構成すること、および
－対象者の投与ガイダンスパラメータを得ること、のうちの一つ以上を含む、請求項１～６のいずれか一項に記載のコンピューティングシステム。
【請求項8】
前記方法が、－前記医薬品投与ガイダンス要求の品質確認を実施するさらなるステップを含み、
（ａ）対象者からの医薬品投与ガイダンス要求が、低血糖事象の記録を含む場合、または
（ｂ）対象者からの医薬品投与ガイダンス要求が、前記対象者が以前に推奨された医薬品用量を摂取することができなかったことを示す記録を含む場合、前記品質確認が失敗し、結果として、いずれの推奨医薬品投与ガイダンスも提供されない、請求項１～７のいずれか一項に記載のコンピューティングシステム。
【請求項9】
前記エンコーダモジュール（ｉｉ）が、リソース要件に対する各それぞれの機能を評価することをさらに含む、請求項１に記載のコンピューティングシステム。
【請求項10】
対象者に対する少なくとも二つの機能が、同時実行される、請求項１～９のいずれか一項に記載のコンピューティングシステム。
【請求項11】
対象者に対する少なくとも二つの機能が、順次実行される、請求項１～１０のいずれか一項に記載のコンピューティングシステム。
【請求項12】
前記機能要求が必要とする前記入力データが、所与の対象者に対して、少なくとも、－前記対象者の上限目標グルコース範囲、
－前記対象者の血糖履歴、
－前記対象者の基礎注射履歴、および
－最新の推奨医薬品投与ガイダンス、を含み、
かつ任意選択で、
－前記対象者の体重、
－前記対象者の下限目標グルコース範囲、
－前記対象者の過度の基礎化限界、および
－前記対象者の開始インスリン基礎投与、のうちの一つ以上を含む、請求項１～１１のいずれか一項に記載のコンピューティングシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、概して、医薬品用量を管理する際に患者および医療従事者を支援するためのシステムおよび方法であって、処方された医薬品の用量が、各患者に特異的な情報に基づいて計算される、システムおよび方法に関する。
【背景技術】
【0002】
真性糖尿病は、高血糖につながるインスリン分泌障害および様々な程度の末梢インスリン抵抗性を特徴とする。２型真性糖尿病は、正常な生理的インスリン分泌の進行性の妨害を特徴とする。健康な個体では、膵β細胞による基礎インスリン分泌が連続的に起こり、食間で長期間にわたって定常グルコースレベルを維持する。健康な個体ではまた、食事に対応する初期の第一段階スパイクでインスリンが急速に放出され、続いて２～３時間後に基底レベルに戻る長期インスリン分泌が続く。何年も制御不良な高血糖が続くと、複数の健康上の合併症を引き起こす可能性がある。真性糖尿病は、世界中の早期罹患率および死亡率の主な原因の一つである。
【0003】
血糖／血漿グルコースの効果的な制御は、これらの合併症の多くを予防または遅延させることができるが、一度確立されるとそれらを元に戻すことができない可能性がある。したがって、糖尿病の合併症を予防するための努力において良好な血糖制御を達成することは、１型および２型糖尿病の治療における主要な目標である。特に、インスリン用量滴定の頻繁な変化は、患者の血糖値の安定化を助けるための鍵となる（Ｂｅｒｇｅｎｓｔａｌ ｅｔ ａｌ．，“Ｃａｎ ａ Ｔｏｏｌ ｔｈａｔ Ａｕｔｏｍａｔｅｓ Ｉｎｓｕｌｉｎ Ｔｉｔｒａｔｉｏｎ ｂｅ ａ Ｋｅｙ ｔｏ Ｄｉａｂｅｔｅｓ Ｍａｎａｇｅｍｅｎｔ？”Ｄｉａｂｅｔｅｓ Ｔｅｃｈ．ａｎｄ Ｔｈｅｒａ．２０１２，１４（８）６７５－６８２）。インスリン薬剤治療レジメンを施すために、調整可能なステップサイズ、ならびに生理学的パラメータ推定および所定の空腹時血糖目標値を用いるスマートタイトレータが開発されている。長時間作用型基礎インスリンの最適な開始方法および滴定方法は、依然として決定されている。しかしながら、証拠は、多くの患者が、グルコース制御の目標レベルを達成するのに十分に滴定されたインスリン用量を受け取らないこと（最適以下の用量のままであり、治療目標に到達できない）が多いことを示唆している（Ｈｏｌｍａｎ ｅｔ ａｌ．，“１０－ｙｅａｒ ｆｏｌｌｏｗ－ｕｐ ｏｆ ｉｎｔｅｎｓｉｖｅ ｇｌｕｃｏｓｅ ｃｏｎｔｒｏｌ ｉｎ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ，”Ｎ．Ｅｎｇｌ．Ｊ．Ｍｅｄ．２００８，３５９：１５７７－１５８９）。
【0004】
インスリンレジメンに関する主要な問題のうちの一つは、患者の自律性およびエンパワーメントの欠如である。患者はしばしば、新しい滴定量を計算するために診療所を訪問しなければならない。診療所が患者のインスリン用量を滴定しなければならない場合、滴定用量の変更頻度には自然制限がある。自己滴定レジメンは、患者のエンパワーメントを促進し、治療により深く関与することを可能にし、その結果、血糖制御の改善をもたらす可能性がある（Ｋｈｕｎｔｉ ｅｔ ａｌ．，“Ｓｅｌｆ－ｔｉｔｒａｔｉｏｎ ｏｆ ｉｎｓｕｌｉｎ ｉｎ ｔｈｅ ｍａｎａｇｅｍｅｎｔ ｏｆ ｐｅｏｐｌｅ ｗｉｔｈ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ：ａ ｐｒａｃｔｉｃａｌ ｓｏｌｕｔｉｏｎ ｔｏ ｉｍｐｒｏｖｅ ｍａｎａｇｅｍｅｎｔ ｉｎ ｐｒｉｍａｒｙ ｃａｒｅ，”Ｄｉａｂｅｔｅｓ，Ｏｂｅｓ．，ａｎｄ Ｍｅｔａｂｏｌ．２０１２，１５（８）６９０－７００）。糖尿病の管理およびインスリンの滴定に積極的な役割を果たす患者は、自身のセルフケアに責任を持ち、自身の行動が自身の疾患に影響を及ぼすと強く信じ、より良い治療結果をもたらすことができる可能性がある（Ｎｏｒｒｉｓ ｅｔ ａｌ．，“Ｓｅｌｆ－ｍａｎａｇｅｍｅｎｔ ｅｄｕｃａｔｉｏｎ ｆｏｒ ａｄｕｌｔｓ ｗｉｔｈ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ：ａ ｍｅｔａ－ａｎａｌｙｓｉｓ ｏｎ ｔｈｅ ｅｆｆｅｃｔ ｏｆ ｇｌｙｃｅｍｉｃ ｃｏｎｔｒｏｌ．Ｄｉａｂｅｔｅｓ Ｃａｒｅ，”２００２，２５：１１５９－７１，Ｋｕｌｚｅｒ ｅｔ ａｌ．，“Ｅｆｆｅｃｔｓ ｏｆ ｓｅｌｆ－ｍａｎａｇｅｍｅｎｔ ｔｒａｉｎｉｎｇ ｉｎ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ：ａ ｒａｎｄｏｍｉｚｅｄ，ｐｒｏｓｐｅｃｔｉｖｅ ｔｒｉａｌ，”Ｄｉａｂｅｔ．Ｍｅｄ．２００７，２４：４１５－２３，Ａｎｄｅｒｓｏｎ ｅｔ ａｌ．，“Ｐａｔｉｅｎｔ ｅｍｐｏｗｅｒｍｅｎｔ：ｒｅｓｕｌｔｓ ｏｆ ａ ｒａｎｄｏｍｉｚｅｄ ｃｏｎｔｒｏｌｌｅｄ ｔｒｉａｌ，”Ｄｉａｂｅｔｅｓ Ｃａｒｅ．１９９５，１８：９４３－９）。さらに、患者が自身の滴定を制御している場合、滴定の頻度が増加し、それにより、患者が所望の血糖値を達成する可能性が高まる。
【0005】
自律的な患者主導の滴定を可能にするツールを開発するため、多くの努力が本分野に投じられている。また、滴定アルゴリズムの開発において大幅な進歩がなされている（Ｅｄｅｌｍａｎ ｅｔ ａｌ．，“ＡＵＴＯＮＯＭＹ：Ｔｈｅ Ｆｉｒｓｔ Ｒａｎｄｏｍｉｚｅｄ Ｔｒｉａｌ Ｃｏｍｐａｒｉｎｇ Ｔｗｏ Ｐａｔｉｅｎｔ－Ｄｒｉｖｅｎ Ａｐｐｒｏａｃｈｅｓ ｔｏ Ｉｎｉｔｉａｔｅ ａｎｄ Ｔｉｔｒａｔｅ Ｐｒａｎｄｉａｌ Ｉｎｓｕｌｉｎ Ｌｉｓｐｒｏ ｉｎ Ｔｙｐｅ ２ Ｄｉａｂｅｔｅｓ，”２０１４，３７（８）：２１３２－２１４０）。しかしながら、多くの滴定アルゴリズムは、患者ではなく、臨床訪問中に主に医療従事者によって使用され続けており、それに伴って、各患者が受け取る滴定の数が限定されている（Ａｒｎｏｌｄｓ ｅｔ ａｌ．，“Ｃｏｍｍｏｎ Ｓｔａｎｄａｒｄｓ ｏｆ Ｂａｓａｌ Ｉｎｓｕｌｉｎ Ｔｉｔｒａｔｉｏｎ ｉｎ Ｔ２ＤＭ，”Ｊ．Ｄｉａｂｅｔｅｓ Ｓｃｉ．Ｔｅｃｈｎｏｌ．２０１３，７（３）：７７１－７８８）。必要とされるのは、患者が健康診療所での予約を有する場合だけではなく、患者が医療従事者によって推奨されたスケジュールを選択するか、またはそのスケジュールに従っていればいつでも、患者がアクセスすることができる、完全自律型の医薬品投与ガイダンスシステムである。
【0006】
自律型の医薬品投与ガイダンスシステムの構造は、演算の複雑さおよび提供するためのコストを含む、いくつかの困難を提起する。患者がオンデマンドで利用可能な自律型の医薬品投与ガイダンスシステムは、クライアント側のモバイルアプリケーション、およびサーバ側のバックエンドの二つの部分を使用して構築することができる。バックエンドサーバは、データベースおよびエンジンにパーティション化することができ、エンジンは、システムの演算集約型機能の大部分が存在する場所である。サーバ側のバックエンドシステムは、多くの場合、クラウドコンピューティングのスケーラビリティの有利な点を得るために、クラウド環境内で展開される。Ａｍａｚｏｎ（ＡＷＳ）、ＩＢＭ（Ｂｌｕｅｍｉｘ）、Ｍｉｃｒｏｓｏｆｔ（Ａｚｕｒｅ）などの企業が提供するクラウドは、「インフラストラクチャアズアサービス（ＩａａＳ）」として最も一般的にアクセス可能である。より多くの患者が自律型の投与ガイダンスシステムを使用するにつれて、コンピューティングリソースの大部分が必要とされるクラウドベースのエンジンは、システムのタイムアウトを回避するために、必要に応じて追加のリソースを割り当てることになる。クラウドコンピューティングは、演算の複雑さまたはクエリの量（例えば、推奨投与ガイダンスを計算することの難しさ、または投与ガイダンスを要求する患者の数）に応じて、法外に高価で時間がかかる場合がある（Ｂｅｒｒｉｍａｎ ｅｔ ａｌ．，“Ｔｈｅ Ａｐｐｌｉｃａｔｉｏｎ ｏｆ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ ｔｏ Ｓｃｉｅｎｔｉｆｉｃ Ｗｏｒｋｆｌｏｗｓ：Ａ Ｓｔｕｄｙ ｏｆ Ｃｏｓｔ ａｎｄ Ｐｅｒｆｏｒｍａｎｃｅ，”Ｐｈｉｌ．Ｔｒａｎｓ．Ｒ．Ｓｏｃ．Ａ ２０１３，３７１：２０１２００６６）。
【0007】
現状は、モノリシックアーキテクチャを使用してエンジンを開発し、それをクラウドベースのハイパーバイザシステム上で展開することになる（Ｌｉｍ ｅｔ ａｌ．，“Ａｕｔｏｍａｔｅｄ Ｃｏｎｔｒｏｌ ｉｎ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ：Ｃｈａｌｌｅｎｇｅｓ ａｎｄ Ｏｐｐｏｒｔｕｎｉｔｉｅｓ，”ＡＣＤ’０９，Ｂａｒｃｅｌｏｎａ，Ｓｐａｉｎ．２００９）。これらのモノリシックアプリケーションは、仮想マシン（ＶＭ）を動作させるハイパーバイザシステムで展開される。需要が増加する（例えば、より多くの患者が投与ガイダンスの要求を開始する）たびに、ハイパーバイザは需要を満たすために追加のＶＭを作成しなければならない。これは、ＶＭの基礎となるオペレーティングシステム（ＯＳ）には、ＶＭのストレージに必要な時間、メモリ、およびディスク空き容量を必要とするため、相当な演算オーバーヘッドを伴う。一つのエンジンサブ機能が他のサブ機能よりも多くの演算能力を必要とする場合、それは、システム全体のリソースボトルネックとして作用し得、需要に追いつくために、追加のＶＭの無関係で回避可能な充当（ａｖｏｉｄａｂｌｅ ｄｅｖｏｔｉｏｎ）を強いることになる。クラウドベースのシステムを、患者の薬物滴定を計算するために有用なものにするためには、ＶＭのオーバーヘッドレベルを必要としない解決策が必要である。
【0008】
したがって、解決すべき問題は、ＩａａＳクラウドモデルにおいて医薬品投与ガイダンスを与える際に、エンジンの効率と、そのコンピューティングリソースの使用を最大化することである。インスリン滴定用量を計算するための効率的で費用効果の高いモデルにより、より多くの患者がオンデマンドで自律型の医薬品投与滴定にアクセスすることができる。この背景セクションに開示された情報は、本発明の一般的な背景の理解の改良のみを目的としており、この情報が当業者に既に公知の先行技術を形成するという認識またはいかなる形態の提案として解釈されるべきではない。
【0009】
上記の背景を考慮すると、本発明の目的は、医薬品投与ガイダンスに関連して、クラウドコンピューティング環境内の演算集約型タスクの分散型リソース管理のための改善されたシステムおよび方法を提供するためのデバイス、システム、および方法を提供することである。
【先行技術文献】
【非特許文献】
【0010】
【文献】Ｂｅｒｇｅｎｓｔａｌら著、「Ｃａｎ ａ Ｔｏｏｌ ｔｈａｔ Ａｕｔｏｍａｔｅｓ Ｉｎｓｕｌｉｎ Ｔｉｔｒａｔｉｏｎ ｂｅ ａ Ｋｅｙ ｔｏ Ｄｉａｂｅｔｅｓ Ｍａｎａｇｅｍｅｎｔ？」、Ｄｉａｂｅｔｅｓ Ｔｅｃｈ．ａｎｄ Ｔｈｅｒａ出版、２０１２年、１４（８）６７５－６８２
【文献】Ｈｏｌｍａｎら著、「１０－ｙｅａｒ ｆｏｌｌｏｗ－ｕｐ ｏｆ ｉｎｔｅｎｓｉｖｅ ｇｌｕｃｏｓｅ ｃｏｎｔｒｏｌ ｉｎ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ」、Ｎ．Ｅｎｇｌ．Ｊ．Ｍｅｄ．出版、２００８年、３５９：１５７７－１５８９
【文献】Ｋｈｕｎｔｉら著、「Ｓｅｌｆ－ｔｉｔｒａｔｉｏｎ ｏｆ ｉｎｓｕｌｉｎ ｉｎ ｔｈｅ ｍａｎａｇｅｍｅｎｔ ｏｆ ｐｅｏｐｌｅ ｗｉｔｈ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ：ａ ｐｒａｃｔｉｃａｌ ｓｏｌｕｔｉｏｎ ｔｏ ｉｍｐｒｏｖｅ ｍａｎａｇｅｍｅｎｔ ｉｎ ｐｒｉｍａｒｙ ｃａｒｅ」、Ｄｉａｂｅｔｅｓ，Ｏｂｅｓ．，ａｎｄ Ｍｅｔａｂｏｌ．出版、２０１２年、１５（８）６９０－７００
【文献】Ｎｏｒｒｉｓら著、「Ｓｅｌｆ－ｍａｎａｇｅｍｅｎｔ ｅｄｕｃａｔｉｏｎ ｆｏｒ ａｄｕｌｔｓ ｗｉｔｈ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ：ａ ｍｅｔａ－ａｎａｌｙｓｉｓ ｏｎ ｔｈｅ ｅｆｆｅｃｔ ｏｆ ｇｌｙｃｅｍｉｃ ｃｏｎｔｒｏｌ． Ｄｉａｂｅｔｅｓ Ｃａｒｅ」２００２年、２５：１１５９－７１
【文献】Ｋｕｌｚｅｒら著、「Ｅｆｆｅｃｔｓ ｏｆ ｓｅｌｆ－ｍａｎａｇｅｍｅｎｔ ｔｒａｉｎｉｎｇ ｉｎ ｔｙｐｅ ２ ｄｉａｂｅｔｅｓ：ａ ｒａｎｄｏｍｉｚｅｄ，ｐｒｏｓｐｅｃｔｉｖｅ ｔｒｉａｌ」Ｄｉａｂｅｔ．Ｍｅｄ．出版、２００７年、２４：４１５－２３
【文献】Ａｎｄｅｒｓｏｎら著、「Ｐａｔｉｅｎｔ ｅｍｐｏｗｅｒｍｅｎｔ：ｒｅｓｕｌｔｓ ｏｆ ａ ｒａｎｄｏｍｉｚｅｄ ｃｏｎｔｒｏｌｌｅｄ ｔｒｉａｌ」Ｄｉａｂｅｔｅｓ Ｃａｒｅ出版、１９９５年、１８：９４３－９
【文献】Ｅｄｅｌｍａｎら著、「ＡＵＴＯＮＯＭＹ：Ｔｈｅ Ｆｉｒｓｔ Ｒａｎｄｏｍｉｚｅｄ Ｔｒｉａｌ Ｃｏｍｐａｒｉｎｇ Ｔｗｏ Ｐａｔｉｅｎｔ－Ｄｒｉｖｅｎ Ａｐｐｒｏａｃｈｅｓ ｔｏ Ｉｎｉｔｉａｔｅ ａｎｄ Ｔｉｔｒａｔｅ Ｐｒａｎｄｉａｌ Ｉｎｓｕｌｉｎ Ｌｉｓｐｒｏ ｉｎ Ｔｙｐｅ ２ Ｄｉａｂｅｔｅｓ」、２０１４年、３７（８）：２１３２－２１４０
【文献】Ａｒｎｏｌｄｓら著、「Ｃｏｍｍｏｎ Ｓｔａｎｄａｒｄｓ ｏｆ Ｂａｓａｌ Ｉｎｓｕｌｉｎ Ｔｉｔｒａｔｉｏｎ ｉｎ Ｔ２ＤＭ」、Ｊ．Ｄｉａｂｅｔｅｓ Ｓｃｉ．Ｔｅｃｈｎｏｌ．出版、２０１３年、７（３）：７７１－７８８
【文献】Ｂｅｒｒｉｍａｎら著、「Ｔｈｅ Ａｐｐｌｉｃａｔｉｏｎ ｏｆ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ ｔｏ Ｓｃｉｅｎｔｉｆｉｃ Ｗｏｒｋｆｌｏｗｓ：Ａ Ｓｔｕｄｙ ｏｆ Ｃｏｓｔ ａｎｄ Ｐｅｒｆｏｒｍａｎｃｅ」、Ｐｈｉｌ．Ｔｒａｎｓ．Ｒ．Ｓｏｃ．Ａ出版、 ２０１３年、３７１：２０１２００６６
【文献】Ｌｉｍら著、「Ａｕｔｏｍａｔｅｄ Ｃｏｎｔｒｏｌ ｉｎ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ：Ｃｈａｌｌｅｎｇｅｓ ａｎｄ Ｏｐｐｏｒｔｕｎｉｔｉｅｓ」、ＡＣＤ’０９出版、Ｂａｒｃｅｌｏｎａ，Ｓｐａｉｎ、２００９年
【発明の概要】
【課題を解決するための手段】
【0011】
本発明の開示では、上記の目的のうちの一つ以上に対処する、または下記の開示だけでなく例示的な実施形態の説明から明らかな目的に対処する実施形態および態様が説明される。
【0012】
本発明の第１の態様では、複数の機能を含む多機能投与ガイダンスアルゴリズムを使用して、複数の対象者に推奨医薬品投与ガイダンスを提供するためのコンピューティングシステムであって、複数の機能のうちの各それぞれの機能が、対応するコンテナクラスに関連付けられ、コンピューティングシステムが、一つ以上のプロセッサおよびメモリを備える、コンピューティングシステムが提供される。メモリは、命令を含み、命令は、一つ以上のプロセッサによって実行されると、複数の対象者のうちのある対象者から医薬品投与ガイダンス要求を受信することに応答して方法を実施する。本システムは、（ｉ）医薬品投与ガイダンス要求を満たすために必要な複数の機能要求を識別するステップであって、複数の機能要求のうちのある機能要求が、複数の機能のうちの対応する機能によって実行可能である、識別するステップと、（ｉｉ）エンコーダモジュールを使用して、複数の機能要求のうちの各それぞれの機能要求に対して、それぞれの機能要求および関連付けられた入力データを、それぞれの機能要求に対応する機能に関連付けられたコンテナクラスのコンテナに埋め込むステップと、（ｉｉｉ）複数の機能要求のうちの各それぞれの機能要求に対して、それぞれの機能要求を実行したコンテナからの機能の結果を収集し、それによって、複数の機能結果を取得するステップと、（ｉｖ）複数の機能結果を使用して、推奨医薬品投与ガイダンスを提供するステップと、を含む。
【0013】
この配置により、バックエンドエンジンおよびその機能を、分散型マイクロサービスアーキテクチャ内のコンテナに分けることができる。コンテナ（オペレーティングシステムレベルの仮想化）は、アプリケーションが意図したとおりに動作および機能するために必要な必要最低限しか提供しない、仮想化するための難易度が低いアプローチである。エンジンの各サブ機能をコンテナ化することにより、エンジンが、オペレーティングシステムおよび物理インフラを無視することによって、異なる環境で確実に動作することが可能になる。
【0014】
例示的な実施形態では、複数の機能は、第１の機能および第２の機能を含み、第１の機能は、第１のコンテナクラスの各コンテナによって実行可能であり、第２の機能は、第２のコンテナクラスの各コンテナによって実行可能であり、第１の機能のハードウェアリソース要件は、第２の機能のハードウェアリソース要件とは異なる。
【0015】
複数の機能は、第１の機能および第２の機能を含み得、第１の機能は、第１のコンテナクラスの各コンテナによって実行可能であり、第２の機能は、第２のコンテナクラスの各コンテナによって実行可能であり、第１のコンテナクラスの各コンテナは、第１のサーバのセットのうちのサーバによってホストされ、第２のコンテナクラスの各コンテナは、第１のサーバのセット以外の第２のサーバのセットのうちのあるサーバによってホストされる。
【0016】
例示的な実施形態では、所与のコンテナクラスのコンテナに対する複合リソース要件は、定期的なベースで評価され、所与のコンテナクラスのコンテナに対する複合リソース要件が、所与のコンテナクラスに関連付けられたリソース割り当て閾値を満たす場合、所与のコンテナクラスの一つ以上の追加のコンテナが追加され、所与のコンテナクラスと一致するエンコーダモジュールからの機能要求を受理することができる。
【0017】
それに応じて、所与のコンテナクラスのコンテナに対する複合リソース要件が、所与のコンテナクラスに関連付けられた第２のリソース割り当て閾値を満たす場合、所与のコンテナクラスの一つ以上のコンテナが除去され得、エンコーダモジュールからの機能要求をもはや受理することができない場合がある。
【0018】
例示的な実施形態では、所与の機能要求に対応する機能に関連付けられたコンテナクラスの所与のコンテナは、機能結果を提供するために機能に必要な入力データがそれぞれの機能要求に含まれているかどうかを評価し、必要な入力データが機能要求に含まれていない場合、機能に関連付けられたコンテナクラスの所与のコンテナは、いずれの機能結果も提供しない。
【0019】
コンピューティングシステムは、複数の対象者のうちの各対象者に対して医薬品投与ガイダンス要求を同時実行するように操作することができる。複数の対象者は、少なくとも１０，０００人の対象者を含み得る。
【0020】
複数の機能は、対象者の推奨医薬品投与ガイダンスを計算すること、対象者のインスリン注射履歴を再構成すること、対象者の滴定グルコースレベルを計算すること、対象者の血糖履歴を再構成すること、および対象者の投与ガイダンスパラメータを得ること、のうちの一つ以上を含み得る。
【0021】
医薬品投与ガイダンス要求は、対象者の所定の血糖目標範囲を達成して、真性糖尿病の症状を治療するために、ある用量のインスリン薬剤に関するものであってもよい。
【0022】
例示的な実施形態では、本方法は、投与ガイダンス要求の品質確認を実施するさらなるステップを含み、（ａ）対象者からの投与ガイダンス要求が、低血糖事象の記録を含む場合、または（ｂ）対象者からの投与ガイダンス要求が、対象者が以前に推奨された医薬品投与を行うことができなかったことを示す記録を含む場合、品質確認は失敗し、結果として、いずれの推奨医薬品投与ガイダンスも提供されない。
【0023】
エンコーダモジュール（ｉｉ）は、リソース要件に対する各それぞれの機能を評価することをさらに含み得る。
【0024】
対象者に対する少なくとも二つの機能が同時実行され得、かつ／または対象者に対する少なくとも二つの機能が順次実行され得る。
【0025】
例示的な実施形態では、機能要求が必要とする入力には、所与の対象者に対して、少なくとも、対象者の上限目標グルコース範囲、対象者の血糖履歴、対象者の基礎注射履歴、および最新の推奨医薬品投与ガイダンス、が含まれ、任意選択で、対象者の体重、対象者の下限目標グルコース範囲、対象者の過度の基礎化限界、および対象者の開始インスリン基礎投与のうちの一つ以上が含まれる。
【0026】
第２の態様では、本開示は、医薬品用量ガイダンスのための、特に医療従事者を訪問するまでの間に使用するための、システムおよび方法を提供することによって、当技術分野における上記で識別されるニーズに対処する。本開示では、複数の対象者に推奨医薬品投与ガイダンスを提供するためのコンピューティングシステムは、複数の機能を含む多機能投与ガイダンスアルゴリズムを使用する。複数の機能のうちの各それぞれの機能は、複数のコンテナクラスのうちのあるコンテナクラスに関連付けられる。コンピューティングシステムは、一つ以上のプロセッサおよびメモリを備える。メモリは、命令を含み、命令は、一つ以上のプロセッサによって実行されると、複数の対象者のうちのある対象者から医薬品投与ガイダンス要求を受信することに応答して方法を実施する。本方法は、（ｉ）医薬品投与ガイダンス要求を満たすために必要な複数の機能要求を識別することであって、複数の機能要求のうちのある機能要求が、複数の機能のうちの対応する機能によって実行可能である、識別することと、（ｉｉ）エンコーダモジュールを使用して、複数の機能要求のうちの各それぞれの機能要求に対して、それぞれの機能要求を、それぞれの機能要求に対応する機能に関連付けられたコンテナクラスのコンテナに埋め込むことと、（ｉｉｉ）複数の機能要求のうちの各それぞれの機能要求に対して、それぞれの機能要求を実行したコンテナクラスのコンテナからの機能結果を収集し、それによって、複数の機能結果を取得することと、（ｉｖ）複数の機能結果を使用して、推奨医薬品投与ガイダンスを提供することと、を含む。
【0027】
いくつかの実施形態では、複数の機能は、第１の機能および第２の機能を含む。第１の機能は、複数のコンテナクラスのうちの第１のコンテナクラスのコンテナの各インスタンスによって実行可能である。第２の機能は、複数のコンテナクラスのうちの第２のコンテナクラスのコンテナの各インスタンスによって実行可能である。第１の機能のハードウェアリソース要件は、第２の機能のハードウェアリソース要件とは異なる。
【0028】
本開示の一態様では、本システムは、複数の対象者、例えば、少なくとも１０．０００人の対象者のうちの各対象者に対して医薬品投与ガイダンス要求を同時実行する。対象者に対する第１の機能および第２の機能は、同時実行され得るか、または順次実行され得る。
【0029】
本開示の別の態様では、第１のコンテナクラスのコンテナの第１のインスタンスのセットの複合リソース要件は、定期的なベースで評価される。第１のコンテナクラスのコンテナの第１のインスタンスのセットの複合リソース要件が、第１のコンテナのセットに関連付けられた第１のリソース割り当て閾値を満たす場合、コンテナクラスのコンテナの一つ以上の追加のインスタンスが第１のコンテナのセットに追加され、第１のコンテナクラスのタイプと一致するエンコーダモジュールからの機能要求を受理することができる。
【0030】
いくつかの実施形態では、第１のコンテナクラスの第１のインスタンスのセットの複合リソース要件が、第１のコンテナのセットに関連付けられた第２のリソース割り当て閾値を満たす場合、第１のコンテナのセットの一つ以上のコンテナが第１のコンテナのセットから除去され、エンコーダモジュールからの機能要求をもはや受理することができない。
【0031】
いくつかの実施形態では、複数の機能は、第１の機能および第２の機能を含む。第１の機能は、複数のコンテナクラスのうちの第１のコンテナクラスのコンテナの各インスタンスによって実行可能である。第２の機能は、複数のコンテナクラスのうちの第２のコンテナクラスのコンテナの各インスタンスによって実行可能である。第１のコンテナクラスのコンテナの各インスタンスは、第１のサーバのセットのうちのサーバによってホストされる。第２のコンテナクラスのコンテナの各インスタンスは、第２のサーバのセットのうちのあるサーバによってホストされる。
【0032】
コンピューティングシステムの例示的な実施形態では、複数の機能は、第１の機能および第２の機能を含み、第１の機能は、複数のコンテナクラスのうちの第１のコンテナクラスのコンテナの各インスタンスによって実行可能であり、第２の機能は、複数のコンテナクラスのうちの第２のコンテナクラスのコンテナの各インスタンスによって実行可能である。第１のコンテナクラスのコンテナの各インスタンスは、第１のサーバのセットのうちのサーバによってホストされ、第２のコンテナクラスのコンテナの各インスタンスは、第１のサーバのセット以外の第２のサーバのセットのうちのあるサーバによってホストされる。
【0033】
第１の機能は、（ｉ）対象者の推奨医薬品投与ガイダンスを計算すること、（ｉｉ）対象者のインスリン注射履歴を再構成すること、（ｉｉｉ）対象者の滴定グルコースレベルを計算すること、（ｉｖ）対象者の血糖履歴を再構成すること、または（ｖ）対象者の投与ガイダンスパラメータを得ること、のうちの一つを含み得る。
【0034】
対象者の血糖履歴を再構成することは、血糖履歴時間的経過がギャップを含む場合、対象者の再構成された血糖履歴を計算することをさらに含み得、再構成された血糖履歴は、各暦日の対象者の血糖履歴に基づいて計算される。
【0035】
コンピューティングシステムのさらなる例示的な実施形態では、それぞれの機能要求に対応する機能に関連付けられたコンテナクラスのコンテナは、機能結果を提供するために機能に必要な入力データがそれぞれの機能要求に含まれているかどうかを評価し、必要な入力が機能要求に含まれていない場合、機能に関連付けられたコンテナクラスのコンテナは、いずれの機能結果も提供しない。
【0036】
機能要求が必要とする入力には、所与の対象者に対して、少なくとも、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴、が含まれる。
【0037】
推奨医薬品投与ガイダンスを決定するために使用される上限目標グルコース範囲は、８０～１８０ｍｇ／ｄＬ、９０～１８０ｍｇ／ｄＬ、１００～１８０ｍｇ／ｄＬ、９０～２００ｍｇ／ｄＬ、９０～２５０ｍｇ／ｄＬ、または９０～３００ｍｇ／ｄＬの範囲内である。
【0038】
推奨医薬品投与ガイダンスを決定するために使用される下限目標グルコース範囲は、５０～７０ｍｇ／ｄＬ、７０～９０ｍｇ／ｄＬ、７０～１００ｍｇ／ｄＬ、６０～１００ｍｇ／ｄＬ、または６０～９０ｍｇ／ｄＬの範囲内である。
【0039】
コンピューティングシステムのさらなる例示的な実施形態では、医薬品投与ガイダンス要求は、ある用量のインスリン薬剤に関するものであり、本用量のインスリン薬剤は、対象者の所定の血糖目標範囲を達成して、真性糖尿病の症状を治療するためのものである。症状は、２型糖尿病であってもよく、インスリン薬剤は、ＬｙｓＢ２９（Ｎｃ－ヘキサデカンジオイル－ｙ－Ｇｌｕ）ｄｅｓ（Ｂ３０）ヒトインスリン（インスリンデグルデク、Ｔｒｅｓｉｂａ（登録商標））であってもよい。
【0040】
所与の血糖目標範囲は、５０～１８０ｍｇ／ｄＬ、６０～１８０ｍｇ／ｄＬ、７０～１８０ｍｇ／ｄＬ、８０～１８０ｍｇ／ｄＬ、５０～２００ｍｇ／ｄＬ、６０～２００ｍｇ／ｄＬ、７０～２００ｍｇ／ｄＬ、８０～２００ｍｇ／ｄＬ、５０～２５０ｍｇ／ｄＬ、６０～２５０ｍｇ／ｄＬ、７０～２５０ｍｇ／ｄＬ、または８０～２５０ｍｇ／ｄＬである。
【0041】
コンピューティングシステムのなおもさらなる例示的な実施形態では、本方法は、投与ガイダンス要求の品質確認を実施することをさらに含み、品質確認が失敗し、かつ（ａ）対象者が低血糖事象を記録した場合、または（ｂ）対象者が以前に推奨された医薬品用量を摂取することができなかった場合、推奨医薬品投与ガイダンスが提供される。
【0042】
コンピューティングシステムのさらなる例示的な実施形態では、エンコーダモジュール（ｉｉ）は、リソース要件に対する各それぞれの機能を評価することをさらに含む。
【図面の簡単な説明】
【0043】
以下では、本発明の実施形態を、図面を参照しながら説明する。
【0044】
【図4A-4B】図４Ａおよび図４Ｂは、ｈ患者データ（例えば、対象者からのグルコースデータを測定する一つ以上のグルコースセンサからのデータ）を収集するためのデータ収集デバイスと、医薬品投与ガイダンス要求システムと、各々がオーケストレータおよび一つ以上のコンテナを含む一つ以上のコンテナエンジンと、を含み、本開示のある実施形態に従って、上記で識別される構成要素が、任意選択で通信ネットワークを介して、相互接続される、例示的なシステムトポロジを集合的に例示している。
【0045】
図面において、同様の構造物は、主として同様の参照番号によって識別される。
【発明を実施するための形態】
【0046】
糖尿病は、世界の健康に関して流行、拡大している。糖尿病は、確立された滴定治療レジメンおよび医薬品により効果的に管理することができるが、最新の推奨滴定へのアクセスは依然として限られている。本開示は、インスリンおよび他の薬物の両方に対して、自動化された医薬品用量調整および自己滴定を容易にし、それに伴って、患者のエンパワーメントを強化するとともに、治療結果を低下させることなく、投与調整に必要な医師診察の頻度を低減することによって、治療コストを大幅に低減し得る、患者中心の滴定アルゴリズムを提供する。本開示は、患者からの要求に応じて、または自律的にのいずれかで、推奨医薬品投与ガイダンスを提供するシステムを説明する。本開示の一つの態様は、推奨医薬品投与を提供するための統合システムがクラウドエコシステムに基づいていることである。
【0047】
本発明自体の実施形態を説明する前に、保存された命令が実行される場合に、どのように投与ガイダンス要求（ＤＧＲ）が受信され、処理されるかの具体的な例を説明する。機能の数、機能の順序、および特定の機能、例えば、各付与機能に組み込まれたルールは全て例示的なものである。例示的な実施形態では、記載された規則は、Ｎｏｖｏ Ｎｏｒｄｉｓｋ Ａ／ＳからのＴｒｅｓｉｂａ（登録商標）の推奨滴定ラベルに対応する。
【0048】
以下に記載するシステム設定は、クラウドベースの大規模な糖尿病管理システムの一部として使用されるように適合されたバックエンドエンジンとして実装されるように設計されている。このようなクラウドベースのシステムにより、エンジンを常に最新の状態にすることができ（例えば、患者のスマートフォンなどで完全に稼働するアプリベースのシステムとは対照的に）、機械学習および人工知能などの高度な方法を実装することができるか、またデータをより大きな「デジタルヘルス」設定で他のサービスと組み合わせて使用することができる。このようなクラウドベースのシステムは、理想的には、推奨投与を求める大量の患者の要求を処理するため、目的のサービスを可能な限り迅速に提供し、利用可能なリソースを効果的に使用するようにシステムを設定することが重要である。
【0049】
全体として、２型糖尿病を有する患者およびその医療従事者（ＨＣＰ）が、血糖値および以前に記録された投与で記録されたインスリン量に応じて、基礎インスリンを滴定することを支援する、糖尿病管理システムが提供される。完全なシステムは、クライアントおよびオペレーティングシステムの形態で相互作用するシステムと組み合わせて使用される本発明の主要な態様であるバックエンドエンジン（「エンジン」）を含む。
【0050】
クライアントは、エンジンの観点から投与ガイダンスを要求するソフトウェア構成要素である。クライアントは、必要なデータ（例えば、ＣＧＭデータ、注射データ、患者パラメータ）を収集し、エンジンからの要素ガイダンスを要求する。次にクライアントは、エンジンから応答を受信する。典型的な設定では、クライアントは、患者の医療デバイスとクラウドとの間のインターフェースとして作用する専用データハブであってもよく、または患者のスマートフォン上で動作するアプリであってもよい。クラウドオペレーティングシステムは、エンジンに、機能するために必要な最小限のリソース（メモリ、処理など）を提供する。クラウドオペレーティングシステムは、エンジンがインストールされた環境として機能し、その展開を可能にする。
【0051】
以下では、真性糖尿病を治療する対象者のための長時間作用型または超長時間作用型インスリン調整日投与推奨（ＡＤＤＲ）を提供するためのシステムの実施形態であって、システムが、クラウドベースの大規模な糖尿病管理システムとしての実施に好適である、実施形態について説明する。
【0052】
より詳細には、真性糖尿病を治療する対象者のための長時間作用型または超長時間作用型インスリン調整日投与推奨（ＡＤＤＲ）を提供するシステムが提供される。システムは、一つ以上のプロセッサおよびメモリを含み、メモリは、一つ以上のプロセッサによって実行されると、投与ガイダンス要求（ＤＧＲ）の受信に応答して方法を実行する命令を含む。
【0053】
命令は、対象者のグルコース上限目標範囲レベル（ＵＴＲ）、および対象者のグルコース下限目標範囲レベル（ＬＴＲ）を含む第１のデータ構造を取得することと、現在の投与ガイダンスベースライン（ＤＧＢ）、およびどの時点でＤＧＢが作成されたかを表す対応するＤＧＢタイムスタンプを含む第２のデータ構造を取得することと、を提供する。現在のＤＧＢは、最新の調整日投与推奨、または開始基礎投与のいずれか、すなわち患者の担当医によって一般的に設定される基礎投与に対応し得る。上述したように、これらのデータ構造は、それぞれ患者のＢＧレベルの目標範囲である滴定レジメンの開始点（開始投与）を表す。
【0054】
更新されるＡＤＤＲを計算できるようにするために、命令は、第１および第２のデータセットを取得することを提供する。第１のデータセットは、時間的経過にわたって取得された対象者の複数のグルコース測定値を含み、それによって血糖履歴（ＢＧＨ）を確立し、複数のグルコース測定値における各それぞれのグルコース測定が、血糖（ＢＧ）値、および時間的経過中のどの時点でそれぞれのグルコース測定が行われたかを表す対応する血糖タイムスタンプ（ＢＧＴ）を含む。ＢＧ値は、独立のＢＧ値の形態であり得、典型的には、朝に取得され、空腹時のＢＧを表す１日の測定値である。この場合、各ＢＧ値は、更新されるＡＤＤＲの計算の基となる１日滴定グルコースレベル値（ＴＧＬ）と称されるものを表す。あるいは、第１のデータセットは、皮膚装着型連続グルコースモニタリング（ＣＧＭ）デバイス（例えば、５分毎にＢＧ値を提供する）の使用によって、毎日にわたって収集された多数のＢＧ値を含み得る。以下でより詳細に説明するように、ＣＧＭデータに基づいて、適切なアルゴリズムを使用して毎日のＴＧＬを決定することができる。
【0055】
第２のデータセットは、対象者の基礎インスリン注射履歴（ＩＨ）を含み、履歴は、対応する注射量（ＩＡ）、および時間的経過中のどの時点でそれぞれの注射が発生したかを表す注射タイムスタンプ（ＩＴ）により特徴付けされるそれぞれの注射を伴う時間的経過の全てまたは一部の間に複数の注射を含む。注射履歴が最新であることを保証するために、注射履歴再読込タイムスタンプを含む第３のデータ構造を取得することができる。注射データは、患者によって手動で取り込まれたか、または投与記録回路を備えた薬物送達デバイスを使用して取り込まれ得る。後者の場合、排出された投与に留意する必要があり、必ずしも注射された投与が記録されるとは限らない。実際に、この不正確さは、手動で生成された投与ログにも適用される可能性がある。注射されていないプライミング／エアショットの問題については、以下に記載する。
【0056】
命令はさらに、データ構造およびデータセットを評価し、それによって、投与ガイダンス要求に必要な全てのデータタイプが存在し、指定範囲内にあるかを決定することを提供する。これには、ＢＧデータ、注射データ、目標グルコース範囲の上限および下限、ならびに最新の調整日投与推奨または開始基礎投与が含まれる。これは、何かが欠けている、または明らかに間違っている、または不十分である場合に、リソースが要求を処理しようと試みて無駄にならないようにするためである。要求が、データタイプを欠くか、または正常とみなされるものよりも１桁大きいパラメータを有する場合、エンジンは、対応するエラーメッセージを返す。全てのデータタイプが存在し、範囲内にある場合（品質および／または数量はここでは考慮されない）、確認はデータを引き継ぎ、さらなる処理を行う。
【0057】
ＡＤＤＲを計算する前に、いくつかのデータ確認が実行され得、例えば、投与ガイダンス要求が、注射履歴再読込タイムスタンプから所与の制限時間内に受信されたかを確認する再読込確認し、投与ガイダンス要求が、ＤＧＢタイムスタンプから所与の制限時間内に受信されたかを確認する更新確認を実行する。
【0058】
さらに、１回以上の投与事象確認が実行され得、注射履歴（ＩＨ）中の個々の注射の数、タイミング、およびサイズが、予め決定された順守要件のセットに適合するかを決定する。
【0059】
本発明の例示的な実施形態の基本的な構成要素を記載したが、特定の実施形態は、図１を参照して記載され、フローチャートは、保存された命令が実行される場合に、どのように投与ガイダンス要求（ＤＧＲ）が受信され、処理されるかを示す。機能の数、機能の順序、および特定の機能、例えば、各付与機能に組み込まれたルールは全て例示的なものである。例示的な実施形態では、記載された規則は、Ｎｏｖｏ Ｎｏｒｄｉｓｋ Ａ／ＳからのＴｒｅｓｉｂａ（登録商標）の推奨滴定ラベルに対応する。
【0060】
１．１ 有効な要求確認
この機能は、上記に記載され、投与ガイダンス要求に必要な全てのデータタイプ（すなわち、クライアント入力データ）が指定範囲内に存在することを確認する。要求に適切なデータがない場合、機能はエラーメッセージを返す。それ以外の場合、確認はデータに沿って通過する。
この機能は、上記に記載され、投与ガイダンス要求に必要な全てのデータタイプ（すなわち、クライアント入力データ）が指定範囲内に存在することを確認する。要求に適切なデータがない場合、機能はエラーメッセージを返す。それ以外の場合、確認はデータに沿って通過する。
【0061】
所与の設定については、確認に合格する要求には、追加の入力データ、例えばタイムスタンプ、所与の期間の最大基礎限界などを伴う報告されたいかなる低血糖事象を含む「低履歴」、例えば１日または１週間あたり、要求時間（ＴＯＲ）、個々の投与ガイダンス要求の一意の識別子、およびクライアントの一意の識別子を必要とし得る。
【0062】
１．２ 最後の注射データ再読込確認
この機能は、注射履歴データが、例えば、直前の３０秒など、所与の制限時間内に再読込されていることを確認し、これは、注射履歴データの最新の記録があることを確認するためのものである。
この機能は、注射履歴データが、例えば、直前の３０秒など、所与の制限時間内に再読込されていることを確認し、これは、注射履歴データの最新の記録があることを確認するためのものである。
【0063】
１．３ 注射履歴確認
この機能は、過去８時間以内に既に投与事象があったかを確認する。その場合、別の注射を推奨することは、Ｔｒｅｓｉｂａ（登録商標）のラベル表示に違反し（すなわち、１日１回、少なくとも８時間の間隔を空けて注射すること）、ユーザを低血糖事象のリスクにさらすことになる。過去８時間以内に投与事象がない場合、確認はデータに沿って次の機能へ通過する。
この機能は、過去８時間以内に既に投与事象があったかを確認する。その場合、別の注射を推奨することは、Ｔｒｅｓｉｂａ（登録商標）のラベル表示に違反し（すなわち、１日１回、少なくとも８時間の間隔を空けて注射すること）、ユーザを低血糖事象のリスクにさらすことになる。過去８時間以内に投与事象がない場合、確認はデータに沿って次の機能へ通過する。
【0064】
１．４ 補充注射確認
Ｔｒｅｓｉｂａ（登録商標）のラベルには、ユーザは１日１回、少なくとも８時間の間隔を空けて注射を受ける必要があると記載されている。ただし、患者が１日の服用を忘れた場合、その忘れた分は、通常の予定投与（８時間以上間隔を空けて服用）に加えて翌日に服用することができる。これに対応して、この機能は最初に、暦日内に投与事象が既に発生しているかを確認する。その場合は、前の暦日が投与事象のない日であるかを確認し、これが真実であれば確認に合格する。前の暦日に記録された投与事象がある場合、確認はエラーメッセージを返し、推奨投与を示さない。
Ｔｒｅｓｉｂａ（登録商標）のラベルには、ユーザは１日１回、少なくとも８時間の間隔を空けて注射を受ける必要があると記載されている。ただし、患者が１日の服用を忘れた場合、その忘れた分は、通常の予定投与（８時間以上間隔を空けて服用）に加えて翌日に服用することができる。これに対応して、この機能は最初に、暦日内に投与事象が既に発生しているかを確認する。その場合は、前の暦日が投与事象のない日であるかを確認し、これが真実であれば確認に合格する。前の暦日に記録された投与事象がある場合、確認はエラーメッセージを返し、推奨投与を示さない。
【0065】
１．５ 記録された低血糖事象確認
この機能は、要求とともに受信したデータ構造が、一つ以上の記録された低血糖事象に関する指標を含むかを確認する。一つ以上の低血糖事象が、予め設定された制限時間内に記録された場合、新しいＡＤＤＲは計算されないが、現在のＤＧＢは２ ＵＩのインスリンで調整される。低血糖事象は、患者によって手動で記録され得、および／またはＣＧＭがＢＧデータ捕捉に使用される場合に自動的に登録され得る。後者の場合、患者は事象の確認を求められることがある。
この機能は、要求とともに受信したデータ構造が、一つ以上の記録された低血糖事象に関する指標を含むかを確認する。一つ以上の低血糖事象が、予め設定された制限時間内に記録された場合、新しいＡＤＤＲは計算されないが、現在のＤＧＢは２ ＵＩのインスリンで調整される。低血糖事象は、患者によって手動で記録され得、および／またはＣＧＭがＢＧデータ捕捉に使用される場合に自動的に登録され得る。後者の場合、患者は事象の確認を求められることがある。
【0066】
１．６ ＢＧデータ品質確認
ＢＧデータが、個々のＢＧ測定値、例えば、空腹時ＢＧに基づいて提供される場合、機能は、例えば、過去４日間に少なくとも三つの有効なＢＧ値など、有効なＢＧ値が、指定された最近の日数のうち、指定された日数の間記録されていることを確認する。ＢＧデータがＣＧＭ測定値に基づいて提供される場合、ＣＧＭデータ品質確認を実行され得、誤った滴定グルコースレベルの決定につながり得る許容できないデータギャップがないことを確認することができる。許容できないレベルのＣＧＭデータ品質についての例示的な基準を以下に記載する。データ品質が最小閾値を満たすことができない場合、この機能はエラーメッセージを返し、投与ガイダンス要求は続行しない。あるいは、ＣＧＭデータ内のギャップを埋めることも可能である。これは、データ内にギャップがある（例えば、新しいセンサが準備されている）にもかかわらず、投与ガイダンス要求が次のＣＧＭデータ品質確認に合格する確率を増加させるためである。適切な数学的アプローチの例を、以下により詳細に記載する。
ＢＧデータが、個々のＢＧ測定値、例えば、空腹時ＢＧに基づいて提供される場合、機能は、例えば、過去４日間に少なくとも三つの有効なＢＧ値など、有効なＢＧ値が、指定された最近の日数のうち、指定された日数の間記録されていることを確認する。ＢＧデータがＣＧＭ測定値に基づいて提供される場合、ＣＧＭデータ品質確認を実行され得、誤った滴定グルコースレベルの決定につながり得る許容できないデータギャップがないことを確認することができる。許容できないレベルのＣＧＭデータ品質についての例示的な基準を以下に記載する。データ品質が最小閾値を満たすことができない場合、この機能はエラーメッセージを返し、投与ガイダンス要求は続行しない。あるいは、ＣＧＭデータ内のギャップを埋めることも可能である。これは、データ内にギャップがある（例えば、新しいセンサが準備されている）にもかかわらず、投与ガイダンス要求が次のＣＧＭデータ品質確認に合格する確率を増加させるためである。適切な数学的アプローチの例を、以下により詳細に記載する。
【0067】
１．７投与事象の識別
ＮｏｖｏＰｅｎ（登録商標）６などの統合投与記録機能を備えるペン型デバイスでは、その使用説明書に従って、患者はインスリンが押し出されるまでデバイスを刺激する必要がある。これらのプライミング「注射」（または「エアショット」）は、ペンによる実際の身体注射と区別されず、エンジンの観点からは、身体に個別に注射されたものとして見られる。患者が実際に注射した回数は、投与ガイダンスシステムによって、患者が滴定レジメンを順守しているかを判断するために確認することができるパラメータのうちの一つであるため、このようなプライミング「注射」をフィルタで除去できることが妥当である。このフィルタリングは、投与記録回路（ＮｏｖｏＰｅｎ（登録商標）６に統合されたか、またはペン型デバイスに装着されるアドオン記録デバイスとして提供されるかを問わない）において行われ得、患者のスマートフォンアプリにおいて、通常、ＡＤＤＲの要求の一部として送信される前に注射データおよびＢＧデータを受信および収集するよう適合されるデバイス、またはクラウドエンジンにおいて行われる。フィルタリングは通常、投与サイズに基づいて行われる（プライミング投与は通常、注射投与よりも（かなり）小さい、注射間の時間である）。この解析を実行する多くのアルゴリズムは、例えば、ＵＳ ２０１９／００３５５００に開示されるように公知である。フィルタリングは、後続のフィルタリングでは何もフィルタリングされないため、複数のレベルで実装できる。「分割投与」、すなわち、患者が２回に分けて投与する（通常）高投与を「投与事象」に組み合わせる必要がある２回に分けて投与する場合も同様の考慮事項が適用され、投与事象の数に基づいて滴定レジメンを危険にさらす２回の個別の投与として数えないようにするように、以下を参照されたい。
ＮｏｖｏＰｅｎ（登録商標）６などの統合投与記録機能を備えるペン型デバイスでは、その使用説明書に従って、患者はインスリンが押し出されるまでデバイスを刺激する必要がある。これらのプライミング「注射」（または「エアショット」）は、ペンによる実際の身体注射と区別されず、エンジンの観点からは、身体に個別に注射されたものとして見られる。患者が実際に注射した回数は、投与ガイダンスシステムによって、患者が滴定レジメンを順守しているかを判断するために確認することができるパラメータのうちの一つであるため、このようなプライミング「注射」をフィルタで除去できることが妥当である。このフィルタリングは、投与記録回路（ＮｏｖｏＰｅｎ（登録商標）６に統合されたか、またはペン型デバイスに装着されるアドオン記録デバイスとして提供されるかを問わない）において行われ得、患者のスマートフォンアプリにおいて、通常、ＡＤＤＲの要求の一部として送信される前に注射データおよびＢＧデータを受信および収集するよう適合されるデバイス、またはクラウドエンジンにおいて行われる。フィルタリングは通常、投与サイズに基づいて行われる（プライミング投与は通常、注射投与よりも（かなり）小さい、注射間の時間である）。この解析を実行する多くのアルゴリズムは、例えば、ＵＳ ２０１９／００３５５００に開示されるように公知である。フィルタリングは、後続のフィルタリングでは何もフィルタリングされないため、複数のレベルで実装できる。「分割投与」、すなわち、患者が２回に分けて投与する（通常）高投与を「投与事象」に組み合わせる必要がある２回に分けて投与する場合も同様の考慮事項が適用され、投与事象の数に基づいて滴定レジメンを危険にさらす２回の個別の投与として数えないようにするように、以下を参照されたい。
【0068】
１．８ 投与事象確認
この機能は、患者が注射のルーチンを十分に順守しているかを確認する。これは、最新のＡＤＤＲ以降少なくとも３回の投与事象を検出し、今日から過去４暦日のウィンドウまでに発生したことを確認する。確認中のこの追加の暦日は、通常予定される投与に加えて、投与のない日（例えば、忘れた日）を許容し、その後、翌日に服用することができる。この時間枠に３回未満の投与事象がある場合（患者が複数日忘れたため）、この確認は失敗し、最新のＡＤＤＲが再推奨につながる。また、単一のＡＤＤＲのみが分配されることを保証し、それ以降に行われたいかなる注射も伴わないＡＤＤＲに対して繰り返し要求するシナリオでは再推奨のみが続く。
この機能は、患者が注射のルーチンを十分に順守しているかを確認する。これは、最新のＡＤＤＲ以降少なくとも３回の投与事象を検出し、今日から過去４暦日のウィンドウまでに発生したことを確認する。確認中のこの追加の暦日は、通常予定される投与に加えて、投与のない日（例えば、忘れた日）を許容し、その後、翌日に服用することができる。この時間枠に３回未満の投与事象がある場合（患者が複数日忘れたため）、この確認は失敗し、最新のＡＤＤＲが再推奨につながる。また、単一のＡＤＤＲのみが分配されることを保証し、それ以降に行われたいかなる注射も伴わないＡＤＤＲに対して繰り返し要求するシナリオでは再推奨のみが続く。
【0069】
１．９ ＤＧＢ確認
この機能は、いつ最新のＡＤＤＲが作成されたか、またはいつ開始基礎投与（ＳＢＤ）値が設定されたかを確認する。最新のＡＤＤＲが現在および過去７暦日以内に行われた場合、確認は合格となる。最新のＡＤＤＲがこれより古い場合、新しいＳＢＤ量を入力し、投与ガイダンス要求プロセスをこの新しいポイントから再開する必要がある。新しいＳＢＤは、現在のＤＧＢとみなされる。
この機能は、いつ最新のＡＤＤＲが作成されたか、またはいつ開始基礎投与（ＳＢＤ）値が設定されたかを確認する。最新のＡＤＤＲが現在および過去７暦日以内に行われた場合、確認は合格となる。最新のＡＤＤＲがこれより古い場合、新しいＳＢＤ量を入力し、投与ガイダンス要求プロセスをこの新しいポイントから再開する必要がある。新しいＳＢＤは、現在のＤＧＢとみなされる。
【0070】
１．１０ 順守確認
この機能は、データセット内の三つの最新の投与事象の注射量を確認し、それぞれが最新のＡＤＤＲの量と少なくとも同じか、それ以上であることを確認する。いずれかの投与事象がこの量未満である場合、確認は失敗し、最新のＡＤＤＲから量を再推奨する。これにより、過少投与による血糖レベルの上昇に基づいてエンジンが滴定されないことが保証される。
この機能は、データセット内の三つの最新の投与事象の注射量を確認し、それぞれが最新のＡＤＤＲの量と少なくとも同じか、それ以上であることを確認する。いずれかの投与事象がこの量未満である場合、確認は失敗し、最新のＡＤＤＲから量を再推奨する。これにより、過少投与による血糖レベルの上昇に基づいてエンジンが滴定されないことが保証される。
【0071】
１．１１多すぎる投与の確認
この機能は、過去４８時間に、Ｔｒｅｓｉｂａ（登録商標）ラベルの推奨に反する２回を超える投与事象があるかを確認する。過去４８時間に２回を超える投与事象が記録されている場合、エラーメッセージが生成され得る。
この機能は、過去４８時間に、Ｔｒｅｓｉｂａ（登録商標）ラベルの推奨に反する２回を超える投与事象があるかを確認する。過去４８時間に２回を超える投与事象が記録されている場合、エラーメッセージが生成され得る。
【0072】
１．１２ １日のＴＧＬを決定する
ＢＧデータが、個々のＢＧ測定値、例えば、空腹時ＢＧに基づいて提供される場合、機能は、有効なＢＧ値が指定された時間範囲内に記録されていることを確認する。ＢＧデータがＣＧＭ測定値に基づいて提供される場合、この機能はＣＧＭデータセットを見て、可能であれば、例えば、ＴＯＲから４日など、最新のＡＤＤＲからの毎日または最大日数までのＴＧＬを決定し、これは投与ガイダンス期間である。「日」は、暦日（一部の日は部分的）であるか、または例えば、ＴＯＲなどから計算される２４時間の期間であり得、下記を参照されたい。これは、例えば、３時間の「スライドウィンドウ」を、ＣＧＭ測定値の一つのデータポイントにわたって適用することによって行い、図２Ａおよび２Ｂを参照されたく、現在の時刻から最終投与調整時までの各３時間間隔の平均を計算する。例示的な実施形態では、１日のＴＧＬは、以下に記載されるように、ＢＧＨデータ品質試験に合格した日間のみ決定される。各日の３時間の最小平均値は、ＴＧＬ値として記録し、滴定に使用する。
ＢＧデータが、個々のＢＧ測定値、例えば、空腹時ＢＧに基づいて提供される場合、機能は、有効なＢＧ値が指定された時間範囲内に記録されていることを確認する。ＢＧデータがＣＧＭ測定値に基づいて提供される場合、この機能はＣＧＭデータセットを見て、可能であれば、例えば、ＴＯＲから４日など、最新のＡＤＤＲからの毎日または最大日数までのＴＧＬを決定し、これは投与ガイダンス期間である。「日」は、暦日（一部の日は部分的）であるか、または例えば、ＴＯＲなどから計算される２４時間の期間であり得、下記を参照されたい。これは、例えば、３時間の「スライドウィンドウ」を、ＣＧＭ測定値の一つのデータポイントにわたって適用することによって行い、図２Ａおよび２Ｂを参照されたく、現在の時刻から最終投与調整時までの各３時間間隔の平均を計算する。例示的な実施形態では、１日のＴＧＬは、以下に記載されるように、ＢＧＨデータ品質試験に合格した日間のみ決定される。各日の３時間の最小平均値は、ＴＧＬ値として記録し、滴定に使用する。
【0073】
１．１３ １日のＴＧＬ確認
この確認は、目標グルコース範囲パラメータの下限を下回る毎日のＴＧＬを検索する。その場合、最新で与えられたＡＤＤＲから２ＩＵで次のＡＤＤＲが減少する。そうでない場合、確認は次の機能に通過する。
この確認は、目標グルコース範囲パラメータの下限を下回る毎日のＴＧＬを検索する。その場合、最新で与えられたＡＤＤＲから２ＩＵで次のＡＤＤＲが減少する。そうでない場合、確認は次の機能に通過する。
【0074】
１．１４ ＴＧＬ平均決定
投与ガイダンス期間（例えば、過去４日間）について、有効な１日のＴＧＬ値の少なくとも最小数、例えば二つを決定した場合、少なくとも二つのＴＧＬ値の平均が計算される。
投与ガイダンス期間（例えば、過去４日間）について、有効な１日のＴＧＬ値の少なくとも最小数、例えば二つを決定した場合、少なくとも二つのＴＧＬ値の平均が計算される。
【0075】
１．１５ 滴定決定
この機能は全体的なＴＧＬ平均を利用し、それが目標範囲内にある場合、滴定決定は最新のＡＤＤＲから＋０ＩＵとなる。ＴＧＬ平均が目標範囲の上限を上回る場合、次のＡＤＤＲは最新のＡＤＤＲから２ＩＵ増加する。ＴＧＬ平均が目標範囲の上限を下回る場合、次のＡＤＤＲは最新のＡＤＤＲから２ＩＵ減少する。
この機能は全体的なＴＧＬ平均を利用し、それが目標範囲内にある場合、滴定決定は最新のＡＤＤＲから＋０ＩＵとなる。ＴＧＬ平均が目標範囲の上限を上回る場合、次のＡＤＤＲは最新のＡＤＤＲから２ＩＵ増加する。ＴＧＬ平均が目標範囲の上限を下回る場合、次のＡＤＤＲは最新のＡＤＤＲから２ＩＵ減少する。
【0076】
１．１６ 最大制限確認
過量投与を防止するために、この機能は、所与の期間における所与の最大投与、例えば、先週のＴｒｅｓｉｂａ（登録商標）の３００ＩＵの最大投与を超過していないことを確認する。また、患者固有の値も要求データに含まれ得る。あるいは、機能は、次のＡＤＤＲが患者の「過度の基礎化」制限（ＢＷ（ｋｇ）＊ＯＢＬ（ＩＵ／ｋｇ））を超えるかを確認し得る。そのためには、対象者の体重（ＢＷ）、および対象者の過度の基礎化限界（ＯＢＬ）が、要求とともに受信したデータの一部として提供されていることが必要となる。
過量投与を防止するために、この機能は、所与の期間における所与の最大投与、例えば、先週のＴｒｅｓｉｂａ（登録商標）の３００ＩＵの最大投与を超過していないことを確認する。また、患者固有の値も要求データに含まれ得る。あるいは、機能は、次のＡＤＤＲが患者の「過度の基礎化」制限（ＢＷ（ｋｇ）＊ＯＢＬ（ＩＵ／ｋｇ））を超えるかを確認し得る。そのためには、対象者の体重（ＢＷ）、および対象者の過度の基礎化限界（ＯＢＬ）が、要求とともに受信したデータの一部として提供されていることが必要となる。
【0077】
１．１７ 出力
投与ガイダンス要求への応答としてのエンジンからの主出力は、実際はクライアントによって受信されたＡＤＤＲであるが、例えば、ＣＧＭ値および特定のエラーまたは警告メッセージ、または信頼性および安全性を改善するための検証データに基づいてエンジンによって計算されるＴＧＬ値など、患者の治療に直接関連する追加情報は、患者にとって有用であり得る。対応するように、出力は、以下のタイプのデータのうちの一つ以上を含み得る：ユーザＩＤ、処理ＩＤ、ＡＤＤＲ、日ＴＧＬ、全体的なＴＧＬ、投与事象履歴、低血糖症履歴、警告およびエラーコード。
投与ガイダンス要求への応答としてのエンジンからの主出力は、実際はクライアントによって受信されたＡＤＤＲであるが、例えば、ＣＧＭ値および特定のエラーまたは警告メッセージ、または信頼性および安全性を改善するための検証データに基づいてエンジンによって計算されるＴＧＬ値など、患者の治療に直接関連する追加情報は、患者にとって有用であり得る。対応するように、出力は、以下のタイプのデータのうちの一つ以上を含み得る：ユーザＩＤ、処理ＩＤ、ＡＤＤＲ、日ＴＧＬ、全体的なＴＧＬ、投与事象履歴、低血糖症履歴、警告およびエラーコード。
【0078】
上記「１．６ＢＧデータ品質確認」を参照し、以下では、許容できないレベルのＣＧＭデータ品質の例示的な基準について記載する。
【0079】
一般に、ＣＧＭデバイスを使用してＴ２ＤＭ患者にインスリン投与ガイダンスを提供する意思決定支援システムについては、上記のシステムは、インスリン、グルコース、および患者データを取り込み、患者がより正常な生活を送ることができるように、現在の基礎インスリン量を解析し、推奨するための後置投与ガイダンスエンジンである。
【0080】
取り込まれるグルコースデータは、連続的なグルコースモニタからであり得る。Ｄｅｘｃｏｍ Ｇ５などの現在のＣＧＭは、５分ごとに連続的にデータを報告し、この連続するデータのストリームから滴定グルコースレベル（ＴＧＬ）を決定し、最終的に推奨投与を決定するのはエンジンのタスクである。残念ながら、今日のＣＧＭにはデータを保存するメモリがなく、受信側デバイス、例えば、患者のスマートフォンで起動しているモバイルアプリなどが受信していないいずれかのデータは失われる。これは、ＴＧＬを安全に決定しながら、実際の使用で発生する可能性が高いこれらのギャップに対処する上で、課題となる。表１は、ＣＧＭデータのギャップを安全に処理するための実行か中止かを決める第１の例を示す。
【0081】
以下では、さらに例として、ＢＧＨデータ品質試験について記載する。
【0082】
投与ガイダンス期間（ＤＧ＿ＰＥＲＩＯＤ）は、要求時からＤＧＢのタイムスタンプまでの期間として、例えば、最大～９６：００時間として定義できる。ＤＧ＿ＰＥＲＩＯＤのＢＧＨデータは、以下の可能な増分に分割される。ＢＧＨ＿ＰＥＲＩＯＤ＿１：０～２４：００時間、ＢＧＨ＿ＰＥＲＩＯＤ＿２：－２４：００～－４８：００時間、ＢＧＨ＿ＰＥＲＩＯＤ＿３：－４８：００～ＤＧＢ時間／－７２：００時間、およびＢＧＨ＿ＰＥＲＩＯＤ＿４：－７２：００～ＤＧＢ時間／－９６：００時間。
【0083】
データ品質試験を実行するため、各ＢＧＨ＿ＰＥＲＩＯＤは重複しない６時間間隔に分割される。各間隔は、一つ以上のＶＡＬＩＤ＿ＴＧＬの存在が、５０％を超えるＢＧＨデータポイントが存在する時間枠として定義されるか確認される。ウィンドウは、例えば３時間であり得る。６時間間隔に一つ以上のＶＡＬＩＤ＿ＴＧＬがない場合、ＢＧＨ＿ＰＥＲＩＯＤ全体がデータ品質試験に失敗となり、すなわち、各ＢＧＨ＿ＰＥＲＩＯＤは個別に試験され、独自の合否決定が行われる。ＣＧＭデータ品質試験に関するさらなる詳細は、ＷＯ ２０１８／２２８９３２に開示されており、これは参照により本明細書に組み込まれる。
【0084】
上記のように、「投与事象」を作成するために投与を組み合わせる必要があり得る。例示的な実施形態では、例えば６０分の実行中のＤＥ＿ＷＩＮＤＯＷ内に収まるＩＨ内の全ての注射は、現在の時間から始まるＤＯＳＥ＿ＥＶＥＮＴ量に集約される。ＤＧ＿ＰＥＲＩＯＤ内の注射のみがＤＯＳＥ＿ＥＶＥＮＴに集約される。ＤＯＳＥ＿ＥＶＥＮＴタイムスタンプは、例えば、ＤＥ＿ＷＩＮＤＯＷ内の最新の注射のタイムスタンプである。表示されているように、プライミングおよびエアショットの放出事象が、ＤＧＲの一部として提出される前にＩＨから除外されない場合、これらの未注射投与は、注射投与の一部として計算される。あるいは、エンジンは、ＥＰ出願１８１９８４１０．５に記載されるように、例えば、接続型ペンに対するルールベースのフロー確認検出など、その所有者フィルタ機能を備え得る。
【0085】
開示されたエンジンが安全であるだけでなく、対象となる患者の治療にも有効であることを保証するために、以前にＴＧＬを決定できず、システムが推奨投与ガイダンスを決定することができなかったＣＧＭデータの特定のギャップを埋めるために、追加のデータ処理ステップが適用され得る。データギャップ充填方法を利用することにより、エンジンは、基礎インスリン投与ガイダンスを分配するためにシステムが安全かつ有効である一方で、データがギャップを有することができる、より現実的な「現実世界」環境で、基礎投与ガイダンスを計算できる場合がある。
【0086】
より詳細には、以下の方法の主概念は、グルコースプロファイルの最低準定常状態を定義し、それらに関してデータ間隔を埋めることである。提案されているモデルは、患者の一般的な傾向および典型的な行動を考慮に入れている。
【0087】
このモデルは、基礎療法のみを用いた研究開始時の２週間のＣＧＭデータを使用した臨床試験の患者のＣＧＭデータに基づいて開発された。データの解析は、患者の少なくとも３０％がＣＧＭデータにかなり大きなギャップを有することを示した。これらのギャップは、昼および夜の異なる時間であった。プロジェクトのリスク解析によると、これらのギャップは、絶食期間中にギャップが生じる可能性があるため、アルゴリズムの投与決定に重大な影響を及ぼすリスクがあり、その結果、滴定アルゴリズムがＴＧＬを正しく特定できなくなり、誤った推奨を行い得る。解析を実行し、提案されたアプローチがＣＧＭノイズに依存せず、低血糖事象に至らなかったことを確認することがタスクであった。
【0088】
ＣＧＭデータギャップ充填処理ステップは、いくつかのステップで構成される。第１に、ＣＧＭストリームで使用可能なデータ量を確認する。要件は、ＴＧＬの特定および滴定に必要な過去Ｘ日内に少なくとも３０％のデータを有することである（例えば、例示的なアルゴリズムの実装例ではＸ＝３）。第２に、ＣＧＭデータのギャップを特定し、それらをギャップに格納する必要がある。１～７２の欠損点（１欠損点＝２間隔＝１０分間ギャップ）まで補充できる。７２の欠損点のギャップが大きく見えても、ギャップ充填アルゴリズムはＣＧＭデータを正しく再構成できた。
【0089】
データ解析により、９０パーセンタイルおよび７５パーセンタイルの隣接点間の絶対値の差は、血糖変動の大きいユーザでは約１０ｍｇ／ｄｌおよび６ｍｇ／ｄｌであり、一方で血糖変動の少ないユーザでは５ｍｇ／ｄｌおよび３ｍｇ／ｄｌのみであることが示された。
次の論理ステップは、７～３６０分間の全てのギャップを見つけることである。再構成プロセスは、全てのギャップを個別に処理する。アルゴリズムは、以下のとおりである：
・ギャップの前の最後の点および後の最初の一つを取得する
・７５パーセンタイルで特定のユーザの典型的なＣＧＭ変化率（ＲＯＣ）を見つけ、
・最後の（最初の）点の値からＲＯＣを引いたものに欠損点の数（それぞれｘ３およびｘ４で示される）を引いた差として、最後の点および最初の点の差の最大値を計算し、
・二つの線の交点を見つけ、時間ｉの値を保存する。
次の論理ステップは、７～３６０分間の全てのギャップを見つけることである。再構成プロセスは、全てのギャップを個別に処理する。アルゴリズムは、以下のとおりである：
・ギャップの前の最後の点および後の最初の一つを取得する
・７５パーセンタイルで特定のユーザの典型的なＣＧＭ変化率（ＲＯＣ）を見つけ、
・最後の（最初の）点の値からＲＯＣを引いたものに欠損点の数（それぞれｘ３およびｘ４で示される）を引いた差として、最後の点および最初の点の差の最大値を計算し、
・二つの線の交点を見つけ、時間ｉの値を保存する。
【0090】
時として、｜ｘ１－ｘ２｜の差がＲＯＣ×欠損点の数よりも大きい場合、交点は時間間隔（ｔ１、ｔ２）の範囲外となる。９０％パーセンタイルＲＯＣでアルゴリズムルーチンの上記の部分を繰り返す必要がある。アルゴリズムが９０％パーセンタイルＲＯＣとの時間間隔（ｔ１、ｔ２）内で交点を達成できない場合、点は直線で接続される。その数理的な記述は、ギャップの時間が小さく、高血糖指数の食事から上昇している場合、最悪の場合のシナリオは直線（Ｖ字型の線の退化した場合）となる。
【0091】
さらに、データ解析では、真の絶食期間の値が、ある程度の妥当な量の点とともに谷を形成することが示されている。
【0092】
機械学習クラスタリング手法ｋ－平均値を使用すると、点のクラスタを見つけることができる。クラスタ重心の無作為初期化を伴う標準ｋ－平均アルゴリズムを使用した。クラスタを見つけるには、ＣＧＭデータを準備する必要がある。ＣＧＭデータを選別する最も簡単な方法は、ストリームの３０パーセンタイルを超える全てのデータを無視することである。このアプローチの利点は、クラスタを見つけるのに十分なデータポイントが依然として存在する一方で、入力データに基づくカットオフラインがシフトすることである。
【0093】
クラスタ重心を定義することは、非常に強力なツールであり、クラスタ重心の最小値を見つけることで、クラスタの点が、より低く、より接近する傾向にある。最後のステップでは、最小クラスタの最小を定義し、この値ｘｃを格納する。
【0094】
クラスタ重心のギャップを定義した後、Ｖ字型の曲線で再充填することができ、Ｖの頭部は点［ｔｉ、ｘｃ］で定義される。患者の体は完全に再現できないため、全ての非線形は線で近似できる。
【0095】
所与のＢＧデータセットがＢＧデータ品質確認に合格すると、１日のＴＧＬ決定が実行されるであろう。その目的として、以下の二つの概念を記載する。上記の例示的な実施形態とは対照的に、６０分のスライディングウィンドウを利用した。
【0096】
アプローチ１：
６０分間のグルコースレベルの最低平均値（すなわち、２４時間中に５分間隔で連続２８８回、１３回測定した場合の最低値）を選択してＴＧＬを検出する。このアプローチは、以下の式を使用して５分間隔の１３回の連続する測定値の移動平均（ＭＡ）を計算し、
式中、Ｇは、グルコース測定値であり、添字ｉは、現在の試料である。００：００～２３：５９までの２４時間の最小ＭＡ６０分，ｉが、ＴＧＬであると決定される。このアプローチは、ｂ）不規則な日課（シフト勤務者など）を有する人々、およびｃ）日課が通常の習慣から逸脱している人々（朝食をとらないなど）を軽減するという仮説を立てている。
６０分間のグルコースレベルの最低平均値（すなわち、２４時間中に５分間隔で連続２８８回、１３回測定した場合の最低値）を選択してＴＧＬを検出する。このアプローチは、以下の式を使用して５分間隔の１３回の連続する測定値の移動平均（ＭＡ）を計算し、
【0097】
アプローチ２：
０４．００～１０．００の時間間隔で第１の急な曲線を特定することにより、ＴＧＬを検出し、これは朝食を表すと想定され、ＴＧＬを－９０分～－６０分の時間間隔での平均グルコースレベルとして決定する。このアプローチは、Ｄａｓｓａｕらが記載した後方差分を計算する。ＣＧＭデータを使用した食事検出のための［ＸＸ］：
式中、Ｇはグルコース測定値であり、ｔは、時間であり、Δｔは、二つの試料間隔間の時間差であり、ならびに添字ｉ、ｉ－１、およびｉ－２は、現在および二つの以前の試料である。ｄＧ／ｄｔは、予め定義された期間内の全ての点について計算する。食事の開始は、ｄＧ／ｄｔが最大になる場所と定義する。次にＴＧＬは、－９０分～－６０分の時間間隔における測定値の平均として計算される。このアプローチは、ａ）規則的で予測可能な生活習慣を有する人ではより強固であると仮定されているが、生活習慣の不規則性が存在する場合には強固性は低くなる。
０４．００～１０．００の時間間隔で第１の急な曲線を特定することにより、ＴＧＬを検出し、これは朝食を表すと想定され、ＴＧＬを－９０分～－６０分の時間間隔での平均グルコースレベルとして決定する。このアプローチは、Ｄａｓｓａｕらが記載した後方差分を計算する。ＣＧＭデータを使用した食事検出のための［ＸＸ］：
【0098】
この二つのアプローチは、複数のシナリオを作成し、（例えば、「典型的な」で予測可能な生活習慣を有する人々、「非定型的な」日常生活習慣を有する人々、インスリン感受性の変化、およびＣＧＭセンサの偏差について）、各シナリオについて、仮想患者モデルに基づいてＣＧＭデータセットを生成することにより、互いに対して検証した。
【0099】
次に、シミュレータからの継続的なグルコース出力に基づいて、結果の測定値を計算した。結果の測定値は、臨床治験の結果と比較した生理学的モデルの性能を評価し、治療決定アルゴリズムの安全性および性能を比較するために使用した。
結果の測定１：重度の低血糖事象の頻度
結果の測定２：高すぎるまたは低すぎる推奨投与の重症度
結果の測定３：範囲内の時間
結果の測定１：重度の低血糖事象の頻度
結果の測定２：高すぎるまたは低すぎる推奨投与の重症度
結果の測定３：範囲内の時間
【0100】
二つのアプローチをランク付けすると、アプローチ１は全てのシミュレーション試験で最良のパフォーマンスを示した。対応するように、アプローチ１はＴＧＬを検出および決定するための実行可能な手段であると評価され、ＣＧＭに基づく基礎インスリンの滴定を実施するための安全なアプローチであると評価される。
【0101】
アプローチ１の実際的な適用は、インスリン投与要求についての要求に対して２４時間の期間以前の三つを使用することである。すなわち、推奨投与時間＝投与時間＝ｔ０。三つの移動平均は、１）ｔ－２４時間～ｔ０、２）ｔ－４８時間～ｔ－２４時間、および３）ｔ－７２時間～ｔ－４８時間の間に見出される。ＴＧＬ期間の間には、例えばＴＧＬ期間の間に少なくとも８時間など、時間差が必要である。これは、同じＴＧＬ期間が二つの２４時間期間で使用されるシナリオを回避するためである。
【0102】
以下では、推奨基礎インスリン投与を安全かつ確実に実施するために、ＣＧＭからどのようなデータ品質が必要であるかを評価する。以下の前提が適用される：
・適応：Ｔ２ＤＭを有する患者の基礎インスリン滴定
・滴定アルゴリズム：「シンプル」２－０－２アルゴリズム
・ＴＧＬの検出および決定へのアプローチ：アプローチ１、上記を参照されたい
・試験で使用される基礎インスリンはインスリンデグルデクであり、９時間の中央値のｔｍａｘ、およそ２５時間の
を伴う非常に平坦な作用プロファイルを有する。
・適応：Ｔ２ＤＭを有する患者の基礎インスリン滴定
・滴定アルゴリズム：「シンプル」２－０－２アルゴリズム
・ＴＧＬの検出および決定へのアプローチ：アプローチ１、上記を参照されたい
・試験で使用される基礎インスリンはインスリンデグルデクであり、９時間の中央値のｔｍａｘ、およそ２５時間の
【0103】
原則として、これらの前提を考慮すると、ＴＧＬを検出および決定するための保守的なアプローチと組み合わせた保守的な滴定アルゴリズムは、それ自体で安全な自動基礎インスリン滴定を提供する必要がある。しかしながら、以下では、欠失箇所のあるＣＧＭデータを用いて評価する。
【0104】
欠失箇所および最適化されたＣＧＭデータ品質を伴うＧＣＭデータの使用案は、公表済みの臨床治験ＮＮ１２１８－３８５３の既存の臨床ＧＣＭデータを使用して評価する：「２型糖尿病（Ｏｎｓｅｔ（登録商標）２）を有する成人におけるインスリングラルギンおよびメトホルミンと組み合わせたインスリンアスパルトと比較したＦｉａｓｐ（登録商標）の有効性および安全性」。この治験のＣＧＭデータは、以下の理由で適用可能である：
・治験には２型糖尿病患者のみが含まれる
・治験は、基礎インスリンが滴定される８週間の導入期間を有する
・８週間の導入期間終了時には、６７対象者についてのＣＧＭデータが１４日間にわたって存在する
・使用したＣＧＭデバイスはＤｅｘｃｏｍ Ｇ４である
・治験には２型糖尿病患者のみが含まれる
・治験は、基礎インスリンが滴定される８週間の導入期間を有する
・８週間の導入期間終了時には、６７対象者についてのＣＧＭデータが１４日間にわたって存在する
・使用したＣＧＭデバイスはＤｅｘｃｏｍ Ｇ４である
【0105】
食事、運動、睡眠、インスリン注射の典型的なスケジュールでの日常生活における糖尿病患者におけるＢＧの最大頻度（バンドエッジ頻度とも称される）は、０．９ １０～３Ｈｚである（Ｋ．－Ｄ．Ｋ．Ｂ．Ｔ．Ｇｏｕｇｈ ＤＡ，「Ｆｒｅｑｕｅｎｃｙ ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ ｏｆ ｂｌｏｏｄ ｇｌｕｃｏｓｅ ｄｙｎａｍｉｃｓ．Ａｎｎ Ｂｉｏｍｅｄ Ｅｎｇ．２００３；３１：９１－９７」）。したがって、内因性ＢＧ動態は、およそ１８分（バンドエッジ頻度の逆数）より速くはない。したがって、約２０分の連続データよりも短いデータギャップの欠損は、推奨投与の安全性に影響を及ぼさない。
【0106】
これらの考慮事項に基づいて、上記の表１に示すように、欠損ＣＧＭデータに基づくアクションのルールセットを提案できる。
【0107】
９１７個の個々のＣＧＭデータセットＮＮ１２１８－３８５３のうち、１３４個は、３日間連続でＣＧＭデータがない最初の２日間に関するため、アクションは推奨されず、ＣＧＭ値を含まない１６個のデータセットは、以下の表に含まれない。残りの７６７個のデータセットのうち、推奨は表２に示され、継続的に期待できるものを表す必要がある。
【0108】
全体として、エンジンが三つの２４時間のＣＧＭデータに基づいて推奨投与を提供する時間の７６％、アプリが二つの２４時間のＣＧＭデータに基づいて推奨投与を提供する時間の１９％、および４％の時間でのみ、欠損ＣＧＭデータの量に基づく推奨投与を提供するアプリを省略する。
【0109】
保存された命令が実行される場合に、どのように投与ガイダンス要求が受信され、処理されるかの具体的な例を説明してきたが、医薬品投与ガイダンスに関連するクラウドコンピューティング環境内の演算集約型タスクの分散型リソース管理のための改善されたシステムおよび方法を提供するという課題に対処する。
【0110】
提案される解決策は、分散型マイクロサービスアーキテクチャ内で、バックエンドエンジンとその機能をコンテナに分けることである。コンテナ、またはオペレーティングシステムレベルの仮想化としても知られるものは、アプリケーションが意図したとおりに動作および機能するために必要な必要最低限しか提供しない、仮想化するための難易度が低いアプローチである。ある意味では、ハイパーバイザ上で動作していない超ミニマリストの仮想マシンとみなすことができる。エンジンの各サブ機能をコンテナ化することにより、エンジンが、オペレーティングシステムおよび物理インフラを無視することによって、異なる環境で確実に動作することが可能になる。コンテナのサイズは通常、数十メガバイトで測定され（一方、仮想マシンは数ＧＢである）、追加の需要を満たすために一つをプロビジョニングするのに１～２秒しかかからない。負荷が増加しているときに、必要に応じて新しい仮想化を作成することができ、負荷が落ちると、コンテナが破壊される可能性がある。実行するコンテナに埋め込まれる機能を決定し、その後、投与ガイダンスシステムのニーズを満たし、システムのタイムアウトを回避するために、専用の任意の追加のコンピューティングリソースを有するように、オーケストレータがネットワーク内に含まれるものとする。
【0111】
このモデルにより、演算リソースがエンジン全体ではなく、個々の機能レベルに充当されることを確保し、演算上の無駄および最終的には過剰なコストを最小限に抑えながら、最も効率的なリソースの使用を確保する。
【0112】
図２に例示されるように、示されるエンジンは、オーケストレータの呼び出し時にマイクロサービスアーキテクチャに従ってＡＰＩ（アプリケーションプログラミングインターフェース）を介して互いに通信する、埋め込まれた機能を備えるコンテナから構成されている。エンジン機能は、演算集約性のレベル、ならびにそれらの異なる投与ガイダンスシステムにわたる再利用性のレベルに基づいて、コンテナに分離される。例えば、「２．計算機能」は、データセットを再構成するために回帰分析と補間を行うために、一度に数千のデータ点を必要とし得る「５．データ再構成」とは対照的に、非常に単純な数学的機能（例えば、ほんの少しの数の加算／減算）からなるため、コンピューティングリソースはほとんど必要ない。これは、どの機能がいつ必要になるかを識別する「１．オーケストレータ」までであり、これは、必要に応じて任意の追加の演算リソースをトリガし得る。この方法により、「５．データ再構成」は、互いに独立して実行され得るため、「３．順守」の前またはそれと平行してスケジュールされ得、「５．データ再構成」は、専用の追加のリソースを有し、それによって、クライアントへの応答がタイムアウトしないことを確保することができる。
【0113】
図２に示されるように、四つの対応するコンテナクラスに四つの関連付けられたコンテナを有する第１のエンジンに対して、第１のオーケストレータ「ＣＧＭＢｏＴ２０２」が提供されている。このセットアップにより、追加のオーケストレータ、例えば、既に実装されている機能を再使用し得るか、または対応するコンテナクラスに実装される新しい機能を要求し得る、エンジン「ＳＭＢＧＢｏｔ２０２」を実装することができる。実際に、将来のタイプの機能には、新しいコンテナクラスが必要となる場合がある。
【0114】
ＰＲＩＯ図４Ａは、対象者に対する推奨医薬品投与ガイダンスを決定するためのシステム６０２（様々に「コンピュータシステム６０２」、「医薬品投与ガイダンスコンピューティングシステム６０２」、または「医薬品投与ガイダンスシステム６０２」）に依存する、統合システム４８の実施例を例示している。図９は、医薬品投与ガイダンス要求の処理を例示する、システム６０２のさらなる詳細を提供する。コンピュータシステム６０２は、コンテナエンジン７０、オーケストレータ２３０、および一つ以上のコンテナ７４を含む。コンテナは、ユーザ空間インスタンスである。かかるユーザ空間インスタンスは、それらのインスタンス上で動作する機能の視点からは、実コンピュータのように見える。通常のオペレーティングシステム上で動作するコンピュータプログラムは、そのコンピュータの全てのリソース（接続されたデバイス、ファイルおよびフォルダ、ネットワーク共有、ＣＰＵ電源、定量化可能なハードウェア機能）を見ることができる。しかしながら、コンテナの内側で動作するプログラム（例えば、開示される機能）は、コンテナに割り当てられたコンテナのコンテンツおよびデバイスのみを見ることができる。コンテナの例としては、ｃｈｒｏｏｔ、Ｄｏｃｋｅｒ、Ｌｉｎｕｘ－ＶＳｅｒｖｅｒ、ｌｍｃｔｆｙ、ＬＸＣ、Ｓｉｎｇｕｌａｒｉｔｙ、ＯｐｅｎＶＺ、Ｖｉｔｕｏｚｚｏ、Ｓｏｌａｒｉｓ Ｃｏｎｔａｉｎｅｒｓ、ＦｒｅｅＢＳＤ ｊａｉｌ、ｓｙｓｊａｉｌ、ＷＰＡＲｓ、ｉＣｏｒｅ Ｖｉｒｔｕａｌ Ａｃｃｏｕｎｔｓ、Ｓａｎｄｂｏｘｉｅ、Ｓｙｓｔｅｍｄ－ｎｓｐａｗｎ、およびＴｕｒｂｏが挙げられるが、これらに限定されない。参照により本明細書に組み込まれる、Ｈｏｇｇによる“Ｓｏｆｔｗａｒｅ Ｃｏｎｔａｉｎｅｒｓ：Ｕｓｅｄ Ｍｏｒｅ Ｆｒｅｑｕｅｎｔｌｙ ｔｈａｎ Ｍｏｓｔ Ｒｅａｌｉｚｅ，”Ｎｅｔｗｏｒｋ Ｗｏｒｌｄ、２０１６年５月２６日を参照されたい。
【0115】
図４Ｂは、対象者のユーザデバイス（例えば、１１０－１）がグルコースセンサ１０２およびインスリンペン１０４からなる、システム４８の特定のインスタンス化を例示している。統合システム５０２は、対象者のグルコースデータおよび推奨医薬品投与ガイダンスの要求の自律的なアルゴリズム分類を実施するための、一つ以上の接続されたインスリンペン１０４、一つ以上のグルコースモニタ１０２、メモリ５０６、およびプロセッサ（図示せず）を含む。いくつかの実施形態では、グルコースモニタ１０２は、連続グルコースモニタである。
【0116】
ここで、実施形態について詳細に参照し、その実施例を添付図面に図示する。以下の実装例の詳細な説明では、本発明の完全な理解を提供するために多数の特定な詳細が記載されている。しかしながら、本発明はこれらの特定な詳細なしに実施され得ることが、当業者には明らかであろう。
【0117】
定義
本開示で使用される専門用語は、特定の実施形態のみを説明することを目的とし、本発明を限定することを意図していない。本発明の説明および添付の特許請求の範囲において使用される場合、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、別途文脈が明確に示さない限り、複数形も同様に含むことが意図される。本明細書で使用される場合、用語「および／または」とは、関連する列挙された項目のうちの一つ以上の可能性のある任意および全ての組み合わせを指し、包含することも理解されるであろう。本明細書で使用される場合、用語「含む（ｉｎｃｌｕｄｅｓ）」および／または「含む（ｃｏｍｐｒｉｓｉｎｇ）」とは、記載される特徴、整数、ステップ、操作、要素、および／または構成要素の存在を特定するが、一つ以上の他の特徴、整数、ステップ、操作、要素、構成要素、および／またはそれらの群の存在または付加を除外しないことがさらに理解されるであろう。
本開示で使用される専門用語は、特定の実施形態のみを説明することを目的とし、本発明を限定することを意図していない。本発明の説明および添付の特許請求の範囲において使用される場合、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、別途文脈が明確に示さない限り、複数形も同様に含むことが意図される。本明細書で使用される場合、用語「および／または」とは、関連する列挙された項目のうちの一つ以上の可能性のある任意および全ての組み合わせを指し、包含することも理解されるであろう。本明細書で使用される場合、用語「含む（ｉｎｃｌｕｄｅｓ）」および／または「含む（ｃｏｍｐｒｉｓｉｎｇ）」とは、記載される特徴、整数、ステップ、操作、要素、および／または構成要素の存在を特定するが、一つ以上の他の特徴、整数、ステップ、操作、要素、構成要素、および／またはそれらの群の存在または付加を除外しないことがさらに理解されるであろう。
【0118】
第１、第２などの用語は本明細書では様々な要素を説明するために使用され得るが、これらの要素はこれらの用語によって限定されるべきではないことも理解されよう。これらの用語は、一つの要素を別の要素と区別するためにのみ使用される。例えば、第１のフィルタは、本開示の範囲から逸脱することなく、第２のフィルタと称され得、同様に、第２のフィルタは、第１のフィルタと称され得る。第１のフィルタおよび第２のフィルタは両方ともフィルタであるが、同じフィルタではない。
【0119】
本明細書で使用される場合、用語「場合（ｉｆ）」とは、文脈に応じて、「ときに（ｗｈｅｎ）」または「際に（ｕｐｏｎ）」または「決定に応じて（ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｒｍｉｎｉｎｇ）」または「検出に応じて（ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｃｔｉｎｇ）」を意味すると解釈され得る。同様に、語句「決定される場合」または「〔記載の状態または事象〕が検出される場合」とは、文脈に応じて、「決定する際に（ｕｐｏｎ ｄｅｔｅｒｍｉｎｉｎｇ）」、または「決定に応じて（ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｒｍｉｎｉｎｇ）」、または「〔記載の状態または事象〕を検出する際に（ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｃｔｉｎｇ［ｔｈｅ ｓｔａｔｅｄ ｃｏｎｄｉｔｉｏｎ ｏｒ ｅｖｅｎｔ］）」、または「〔記載の状態または事象〕の検出に応じて（ｉｎ ｒｅｓｐｏｎｓｅ ｔｏ ｄｅｔｅｃｔｉｎｇ［ｔｈｅ ｓｔａｔｅｄ ｃｏｎｄｉｔｉｏｎ ｏｒ ｅｖｅｎｔ］）」を意味すると解釈され得る。
【0120】
用語「ｏｒ」は、排他的な「ｏｒ」ではなく、包括的な「ｏｒ」を意味することを意図している。すなわち、別段の指定がない限り、または文脈から明らかでない限り、「ＸはＡまたはＢを採用する」という語句は、自然包括的な順列のいずれかを意味することを意図している。すなわち、「ＸはＡまたはＢを採用する」という語句は、以下の場合のいずれかによって満たされる。ＸはＡを採用する、ＸはＢを採用する、またはＸはＡおよびＢの両方を採用する。さらに、本明細書および添付の特許請求の範囲で使用されるような冠詞「ａ」および「ａｎ」は、別段の指定がない限り、または単数形に向けられる文脈から明らかでない限り、一般に「一つ以上」を意味すると解釈されるべきである。
【0121】
「対象者」、「個体」、および「ユーザ」という用語は、本明細書では互換的に使用され、ヒトを指す。好ましくは、個体は成人個体である。
【0122】
本明細書で使用される場合、用語「薬剤」は、対象者の医学的処置に使用される化学物質を指す。用語「薬剤」、「医薬品」、および「薬物」は、本明細書では互換的に使用される。薬剤は、医師または他の医療従事者によって処方され得る。あるいは、薬剤は、市販の薬物または製品であってもよい。本開示の特定の実施例では、薬剤は、真性糖尿病を治療するために使用されるインスリンである。
【0123】
「糖尿病」または「真性糖尿病」という用語は、１型真性糖尿病、２型真性糖尿病、妊娠糖尿病（妊娠中）、および高血糖を引き起こすその他の状態を含む。この用語は、膵臓が不十分な量のインスリンを産生する、または体の細胞がインスリンに適切に反応せず、細胞がグルコースを吸収するのを妨げる代謝性疾患に対して使用されます。その結果、血中にグルコースが蓄積し、血糖値を制御するために治療が必要となる。
【0124】
本発明によれば、インスリンは、長時間作用型インスリンおよび超長時間作用型インスリンを含むか、またはそれからなる。原則として、インスリンの半減期が長いほど、投与間隔（すなわち、注射間の時間間隔）にわたってグルコース低下作用がより安定し、均等に分布する。本発明によれば、インスリンは、該対象者において有益な血糖制御を達成する量で投与される。本発明によれば、該対象者における有益な血糖制御は、該基礎インスリンの投与後、少なくとも該対象者におけるＨｂＡ１ｃ（グリコシル化ヘモグロビン）レベルによって決定される。本発明による基礎インスリンの使用およびその投与により、それを必要とする患者の割合がＨｂＡ１ｃの目標値に達する改善を達成することができる。
【0125】
インスリンペンという用語は、インスリン製剤の統一性のない投与を適用するのに好適な注射デバイスを意味し、注射デバイスは、投与に関係するデータのログおよび通信のためにも適合される。
【0126】
本明細書で使用される場合、「構成要素」および「システム」という用語、ならびにそれらの様々な形態（例えば、構成要素、システム、サブシステムなど）は、コンピュータ関連のエンティティ、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことが意図されている。例えば、構成要素は、プロセッサ上で動作しているプロセス、プロセッサ、オブジェクト、インスタンス、実行可能なもの、実行スレッド、プログラム、および／またはコンピュータであってもよいが、これらに限定されない。例示として、コンピュータ上で動作しているアプリケーションおよびコンピュータの両方を構成要素とすることができる。一つ以上の構成要素を、拡張可能なクラウドベースのサービスに分散することができる。一つ以上の構成要素が、実行のプロセスおよび／またはスレッド内に存在してもよく、構成要素を、一つのコンピュータ上にローカライズすることができ、かつ／または二つ以上のコンピュータ間で分散することができる。
【0127】
説明
本開示に従って、対象者に対して処方された薬物レジメンで薬剤用量を自律的に計算するためのシステム４８の詳細な説明を、図１および図２と併せて説明する。したがって、図１および図２は、本開示によるシステムのトポロジを集合的に例示している。トポロジには、対象者に対して処方された薬物レジメンで薬剤用量を自律的に調整するための医薬品投与ガイダンスシステム（「医薬品投与ガイダンスコンピュータシステム６０２」）（図１および図２）と、対象者からの情報を収集するためのデバイス（「対象者ユーザデバイス１１０」）と、医薬品投与ガイダンスコンピュータシステム６０２と対象者ユーザデバイス１１０との間で情報を送信するためのデバイス（「データ送信デバイス１５０」）と、がある。
本開示に従って、対象者に対して処方された薬物レジメンで薬剤用量を自律的に計算するためのシステム４８の詳細な説明を、図１および図２と併せて説明する。したがって、図１および図２は、本開示によるシステムのトポロジを集合的に例示している。トポロジには、対象者に対して処方された薬物レジメンで薬剤用量を自律的に調整するための医薬品投与ガイダンスシステム（「医薬品投与ガイダンスコンピュータシステム６０２」）（図１および図２）と、対象者からの情報を収集するためのデバイス（「対象者ユーザデバイス１１０」）と、医薬品投与ガイダンスコンピュータシステム６０２と対象者ユーザデバイス１１０との間で情報を送信するためのデバイス（「データ送信デバイス１５０」）と、がある。
【0128】
図４Ａを参照すると、コンピュータシステム６０２は、対象者に対して調整された薬剤用量を自律的に提供する。コンピュータシステム６０２またはその一部は、（例えば、クラウド内の）サービスから取得される情報を含み得るか、またはクラウドコンピューティング環境で実質的に操作することができる。例えば、参照により本明細書に組み込まれる、Ｍｉｃｒｏｓｏｆｔ Ｔｅｃｈｎｏｌｏｇｙ Ｌｉｃｅｎｓｉｎｇ ＬＬＣに譲渡された「Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」と題する米国特許出願第２０１７／００６３８３３号に記載されるように、クラウドコンピューティング環境は、ネットワーク内の複数のデバイス上に存在する情報を提供する。
【0129】
いくつかの実施形態では、薬剤は、医療従事者によって処方される薬物である。いくつかの実施形態では、薬剤は、市販の薬物である。推奨薬剤投与ガイダンスを計算するために、コンピュータシステム６０２と（データ送信デバイス１５０を介して、通信ネットワーク１０６を介して、または直接のいずれかによって）電気通信する対象者ユーザデバイス１１０は、対象者の薬剤の使用に関連する自律的な対象者特異的情報を受信する。例えば、いくつかの実施形態では、データ送信デバイス１５０は、無線周波数信号を通じて無線でこのデータを受信する。いくつかの実施形態ではこのような信号は、８０２．１１（Ｗｉｆｉ）、Ｂｌｕｅｔｏｏｔｈ、またはＺｉｇｂｅｅ標準に従っている。いくつかの実施形態では、データ送信デバイス１５０は、かかるデータを直接受信し、データをコンピュータシステム６０２に送信し、次いで、データを分析し、（対象者ユーザデバイス１１０に直接、またはデータ送信デバイス１５０を介してのいずれかで）推奨医薬品投与ガイダンスを提供する。いくつかの実施形態では、対象者ユーザデバイス１１０は、ＲＦＩＤタグを含み、ＲＦＩＤ通信を使用して、データ送信デバイス１５０および／または医薬品投与ガイダンスコンピュータシステム６０２と通信する。いくつかの実施形態では、データ送信デバイス１５０および／またはコンピュータシステム６０２はまた、対象者の生理学的測定値を取得または受信する（例えば、着用可能な生理学的測定デバイスから、磁力計またはサーモスタットなどのデータ送信デバイス１５０内の測定デバイスからなど）。
【0130】
いくつかの実施形態では、データ送信デバイス１５０および／またはコンピュータシステム６０２は、対象者に近接していない、および／もしくは無線機能を有していない、またはかかる無線機能がグルコースデータ、インスリン薬剤注射データ、および／もしくは生理学的測定データを取得する目的のために使用されていない。かかる実施形態では、通信ネットワーク１０６を使用して、対象者ユーザデバイス１１０からの対象者情報をデータ送信デバイス１５０および／もしくは医薬品投与ガイダンスコンピュータシステム６０２に、ならびに／または一つ以上の生理学的測定デバイス（図示せず）からの生理学的測定データをデータ送信デバイス１５０および／もしくは医薬品投与ガイダンスコンピュータシステム６０２に通信することができる。
【0131】
図４Ｂを参照すると、いくつかの実施形態では、対象者ユーザデバイス１１０は、グルコースセンサ１０２および／またはインスリンペン１０４からなる。いくつかの実施形態では、医薬品投与ガイダンスコンピュータシステム６０２および／またはデータ送信デバイス１５０は、対象者に継続的に取り付けられる一つ以上のグルコースセンサ１０２に由来するグルコース測定値およびインスリン滴定要求を受信する。いくつかの実施形態では、データ送信デバイス１５０はまた、インスリン薬剤を注射するために対象者が使用する一つ以上のインスリンペン１０４から、インスリン薬剤注射データを受信する。いくつかの実施形態では、データ送信デバイス１５０は、かかるデータを、グルコースセンサ（複数可）１０２および対象者が使用するインスリンペン１０４から直接受信する。いくつかの実施形態では、グルコースセンサ１０２および／またはインスリンペン１０４は、ＲＦＩＤタグを含み、ＲＦＩＤ通信を使用して、データ送信デバイス１５０および／またはコンピュータシステム６０２と通信する。本発明のいくつかの実施形態については、対象者ユーザデバイス１１０は、インスリンペン型デバイスである。いくつかの実施形態では、インスリンペン型デバイスは、ＦｌｅｘＰｅｎ（登録商標）（複数可）またはＦｌｅｘＴｏｕｃｈ（登録商標）（複数可）である。ＦｌｅｘＰｅｎ（登録商標）およびＦｌｅｘＴｏｕｃｈ（登録商標）は、Ｎｏｖｏ Ｎｏｒｄｉｓｋ Ａ／Ｓの商標である。
【0132】
いくつかの実施形態では、図４Ｂに示されるように、データ送信デバイス１５０および／または医薬品投薬ガイダンスコンピュータシステム６０２は、対象者に近接していない、および／もしくは無線機能を有していない、またはかかる無線機能がグルコースデータ、インスリン薬剤注射データ、および／もしくは生理学的測定データを取得する目的のために使用されていない。かかる実施形態では、通信ネットワーク１０６を使用して、グルコースセンサ１０２からのグルコース測定値をデータ送信デバイス１５０および／もしくは医薬品投与ガイダンスコンピュータシステム６０２に、一つ以上のインスリンペン１０４からのインスリン薬剤注射データをデータ送信デバイス１５０および／もしくは医薬品投与ガイダンスコンピュータシステム６０２に、ならびに／または一つ以上の生理学的測定デバイス（図示せず）からの生理学的測定データをデータ送信デバイス１５０および／もしくはコンピュータシステム６０２に通信することができる。
【0133】
ネットワーク１０６（図４Ａおよび図４Ｂに示される）の例としては、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）、イントラネット、および／または無線ネットワーク、例えば、携帯電話ネットワーク、無線ローカルエリアネットワーク（ＬＡＮ）、および／もしくはメトロポリタンエリアネットワーク（ＭＡＮ）、ならびに無線通信による他のデバイスなどが挙げられる、これらに限定されない。ワイヤレス通信は、任意選択的に、限定されないが、汎欧州デジタル移動電話方式（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）（ＧＳＭ）、高速データＧＳＭ環境（ＥＤＧＥ）、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）、高速アップリンクパケットアクセス（ＨＳＵＰＡ）、エボリューションデータオンリー（ＥＶ－ＤＯ）、ＨＳＰＡ、ＨＳＰＡ＋、デュアルセルＨＳＰＡ（ＤＣ－ＨＳＰＤＡ）、ロングタームエボリューション（ＬＴＥ）、近距離無線通信（ＮＦＣ）、広帯域符号分割多元接続（Ｗ－ＣＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、Ｂｌｕｅｔｏｏｔｈ、Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ（Ｗｉ－Ｆｉ）（例えば、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｘ、ＩＥＥＥ８０２．１１ｂ、ＩＥＥＥ ８０２．１１ｇ、および／またはＩＥＥＥ８０２．１１ｎ）、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）、Ｗｉ－ＭＡＸ、電子メール用プロトコル（例えば、インターネットメッセージアクセスプロトコル（ＩＭＡＰ）、および／またはポストオフィスプロトコル（ＰＯＰ））、インスタントメッセージング（例えば、エクステンシブルメッセージングアンドプレゼンスプロトコル（ＸＭＰＰ）、インスタントメッセージングアンドプレゼンスレバレッジングエクステンション用セッション初期化プロトコル（ＳＩＭＰＬＥ）、インスタントメッセージングアンドプレゼンスサービス（ＩＭＰＳ））、および／またはショートメッセージサービス（ＳＭＳ）、または本開示の出願日には未開発である通信プロトコルを含む任意の他の好適な通信プロトコルを含む、複数の通信基準、プロトコル、および技術のうちのいずれかを使用する。
【0134】
いくつかの実施形態では、データ送信デバイス１５０は、対象者ユーザデバイス１１０の一部である。すなわち、いくつかの実施形態では、データ送信デバイス１５０および対象者ユーザデバイス１１０は、単一のデバイスである。いくつかの実施形態では、対象者に取り付けられる単一のグルコースセンサ１０２があり、データ送信デバイス１５０は、グルコースセンサ１０２の一部である。すなわち、いくつかの実施形態では、データ送信デバイス１５０およびグルコースセンサ１０２は、単一のデバイスである。
【0135】
もちろん、システム４８の他のトポロジが可能である。例えば、通信ネットワーク１０６に頼るのではなく、一つ以上の対象者ユーザデバイス１１０は、情報を、データ送信デバイス１５０および／または医薬品投与ガイダンスコンピュータシステム６０２に直接無線で送信し得る。同様に、一つ以上のグルコースセンサ１０２および一つ以上のインスリンペン１０４は、情報を、データ送信デバイス１５０および／または医薬品投与ガイダンスコンピュータシステム６０２に直接無線で送信し得る。さらに、データ送信デバイス１５０および／または医薬品投与ガイダンスコンピュータシステム６０２は、ポータブル電子デバイス、サーバコンピュータを構成し得るか、または実際には、ネットワークで一緒に連結されているいくつかのコンピュータを構成し得るか、もしくはクラウドコンピューティングコンテキストの仮想マシンであり得る。したがって、図１Ａおよび図１Ｂに示される例示的なトポロジは、単に、当業者に容易に理解される様式で本開示の例示的な実施形態の特徴を説明するのに役立つ。
【0136】
【0137】
図５に例示されるように、コンピュータシステム６０２は、好ましくは、分散型マイクロサービスアーキテクチャ内に一つ以上のエンジン７０を備える。図５に例示される構成要素は、例示的なものであり、必要とされ得るか、または含まれ得る、全ての構成要素を全て包括することを意味するものではない。さらに、構成要素の数は、本明細書に記載される主題の態様の趣旨または範囲から逸脱することなく、他の実施形態で異なってもよい。
【0138】
図５を参照すると、いくつかの実施形態では、コンピュータシステム６０２は、一つ以上のシステムを含む。いくつかの実施形態では、対象者に対して処方された薬剤レジメンで推奨医薬品投与ガイダンスを自律的に提供するための機能は、任意の数のネットワーク化されたコンピュータにわたって広がり、かつ／または通信ネットワーク１０６にわたってアクセス可能な遠隔地にあるいくつかのネットワーク化されたコンピュータの各々に存在し、かつ／または一つ以上のクラウドベースの環境でホストされる。広範な異なるコンピュータトポロジのうちのいずれかがアプリケーション用に使用され、全てのかかるトポロジが本開示の範囲内であることを当業者は理解するであろう。
【0139】
いくつかの実施形態では、対象者に対して処方された薬剤レジメンで推奨薬剤用量を自律的に提供するための例示的な医薬品投与ガイダンスコンピュータシステム６０２は、一つ以上の処理ユニット（ＣＰＵ）２０２と、ネットワークまたは他の通信インターフェース２６０と、メモリ２１４（例えば、ランダムアクセスメモリ）と、一つ以上のコントローラ２１８によって任意選択でアクセスされる一つ以上の磁気ディスクストレージおよび／または持続的デバイス２２０と、前述の構成要素を相互接続するための一つ以上の通信バス２１２と、前述の構成要素に電力供給するための電源２２４と、を備える。いくつかの実施形態では、メモリ２１４内のデータは、キャッシュなどの既知の演算技法を使用する、不揮発性メモリ２２０とシームレスに共有される。いくつかの実施形態では、メモリ２１４および／またはメモリ２２０は、中央処理ユニット（複数可）２０２に対して遠隔に位置する大容量ストレージを含む。言い換えれば、メモリ２１４および／またはメモリ２２０に保存されている一部のデータは、実際に、医薬品投与ガイダンスコンピュータシステム６０２の外部であるが、ネットワークインターフェース２１０を使用してインターネット、イントラネット、または他の形態のネットワークもしくは電子ケーブル（図４Ａに要素１０６として例示されている）を介して、医薬品投与ガイダンスコンピュータシステム６０２によって電子的にアクセスされ得るコンピュータ上でホストされ得る。
【0140】
いくつかの実施形態では、複数の対象者に推奨医薬品投与ガイダンスを提供するための医薬品投与ガイダンスコンピュータシステム６０２のメモリ２１４は、
・一つ以上のオーケストレータ２３０および複数のコンテナ７４（例えば、７４－１、７４－２、７４－Ｚ）を備える、エンジン７０と、
・対象者データ、医薬品投与ガイダンス要求を決定するために必要な機能、およびコンテナ７４への機能要求２５４の分散を組織化する、一つ以上のオーケストレータ２３０と、
・機能２５２をコンテナ７４に埋め込む、エンコーダモジュール２４０と、
・一つ以上のコンテナ７４であって、それらの各々が埋め込まれた機能２５２を含み、機能要求２５４を実行する、一つ以上のコンテナ７４と、を保存する。
・一つ以上のオーケストレータ２３０および複数のコンテナ７４（例えば、７４－１、７４－２、７４－Ｚ）を備える、エンジン７０と、
・対象者データ、医薬品投与ガイダンス要求を決定するために必要な機能、およびコンテナ７４への機能要求２５４の分散を組織化する、一つ以上のオーケストレータ２３０と、
・機能２５２をコンテナ７４に埋め込む、エンコーダモジュール２４０と、
・一つ以上のコンテナ７４であって、それらの各々が埋め込まれた機能２５２を含み、機能要求２５４を実行する、一つ以上のコンテナ７４と、を保存する。
【0141】
いくつかの実施形態では、医薬品投与ガイダンスシステム６０２は、任意のブラウザ（電話、タブレット、ラップトップ／デスクトップ）を介してアクセス可能である。好ましい実施形態では、医薬品投与ガイダンスシステム６０２は、クラウドコンピューティング環境に保存される。
【0142】
いくつかの実装例では、複数の機能を含む多機能投与ガイダンスアルゴリズムを使用して、複数の対象者に推奨医薬品投与ガイダンスを提供するための医薬品投与ガイダンスコンピュータシステム６０２の上記で識別されるデータ要素またはモジュールのうちの一以上は、前述のメモリデバイスのうちの一つ以上に保存され、上述の機能を実施するための命令のセットに対応する。上述の識別されたデータ、モジュール、またはプログラム（例えば、一組の命令）は、別個のソフトウェアプログラム、手順、またはモジュールとして実装される必要はなく、これらのモジュールのさまざまなサブセットを、さまざまな実装で組み合わせるかまたはそうでなければ再配置され得る。いくつかの実装例では、メモリ２１４および／または２２０は、任意選択で、上記で識別されるモジュールのサブセットを保存する。さらに、いくつかの実施形態では、メモリ２１４および／または２２０は、上述されていない追加のモジュールを保存する。
【0143】
いくつかの実施形態では、対象者に対して処方されたインスリンレジメン２１２で長時間作用型インスリン薬剤用量２１６を自律的に調整するための医薬品投与ガイダンス要求は、スマートフォン（例えば、ｉＰｈｏｎｅ）、ラップトップ、タブレットコンピュータ、デスクトップコンピュータ、または他の形態の電子デバイス（例えば、ゲーム機）などのユーザデバイス２７８によって生成される。いくつかの実施形態では、コンピュータシステム６０２は、図５に描かれるコンピュータシステム６０２内に見られる回路、ハードウェア構成要素、およびソフトウェア構成要素のいずれかまたは全てを有する。簡潔性および明瞭性の観点では、コンピュータシステム６０２にインストールされ得る追加のソフトウェアモジュールをより強調するために、コンピュータシステム６０２の可能な構成要素のうちのいくつかのみが示される。
【0144】
複数の機能を含む多機能投与ガイダンスアルゴリズムを使用して、複数の対象者に推奨医薬品投与ガイダンスを提供するためのシステム４８およびデバイス２００の詳細を開示してきたので、本開示の様々な実施形態による、システムのプロセスおよび特徴のフローチャートに関する詳細を、図６を参照して開示する。
【0145】
図６のブロック３０２を参照すると、本開示の目的は、データ送信デバイス１５０およびコンピュータシステム６０２などのデバイスと併せて、複数の機能を含む多機能投与ガイダンスアルゴリズムを使用して、複数の対象者に推奨医薬品投与ガイダンスを提供することである。対象者の各々は、糖尿病症状を有する。
【0146】
ｄＬ
いくつかの実施形態では、糖尿病症状は、２型真性糖尿病である。いくつかの実施形態では、医薬品投与ガイダンス要求は、ある用量のインスリン薬剤に関するものであり、本用量のインスリン薬剤は、対象者の所定の血糖目標範囲を達成して、真性糖尿病を治療するためのものである。
いくつかの実施形態では、糖尿病症状は、２型真性糖尿病である。いくつかの実施形態では、医薬品投与ガイダンス要求は、ある用量のインスリン薬剤に関するものであり、本用量のインスリン薬剤は、対象者の所定の血糖目標範囲を達成して、真性糖尿病を治療するためのものである。
【0147】
いくつかの実施形態では、所与の血糖目標範囲は、５０～１８０ｍｇ／ｄＬ、６０～１８０ｍｇ／ｄＬ、７０～１８０ｍｇ／ｄＬ、８０～１８０ｍｇ／ｄＬ、５０～２００ｍｇ／ｄＬ、６０～２００ｍｇ／ｄＬ、７０～２００ｍｇ／ｄＬ、８０～２００ｍｇ／ｄＬ、５０～２５０ｍｇ／ｄＬ、６０～２５０ｍｇ／ｄＬ、７０～２５０ｍｇ／ｄＬ、または８０～２５０ｍｇ／ｄＬである。
【0148】
いくつかの実施形態では、複数の対象者は、少なくとも１００人の対象者、少なくとも１，０００人の対象者、少なくとも５，０００人の対象者、少なくとも１０，０００人の対象者、少なくとも５０，０００人の対象者、または少なくとも１００，０００人の対象者を含む。いくつかの実施形態では、本システムは、かかる対象者ごとに医薬品投与ガイダンス要求を同時実行する。
【0149】
複数の機能のうちの各それぞれの機能２５２は、複数のコンテナクラスのうちのコンテナクラス２５０に関連付けられる。図５に例示されるように、コンピュータシステム６０２は、一つ以上のプロセッサ２０２およびメモリ２１４／２２０を含む。メモリは、命令を含み、命令は、一つ以上のプロセッサによって実行されると、複数の対象者のうちのある対象者から推奨医薬品投与要求を受信することに応答して方法を実施する。
いくつかの実施形態では、それぞれの機能要求２５４に対応する機能２５２に関連付けられたコンテナクラス２５０のコンテナ７４は、それぞれの機能要求２５４が機能結果２５６を提供するために機能に必要な入力を含むかどうかを評価する。かかる例では、機能要求が必要な入力を含まない場合、機能に関連付けられたコンテナクラスのコンテナは、いずれの機能結果２５６も提供しない。
いくつかの実施形態では、それぞれの機能要求２５４に対応する機能２５２に関連付けられたコンテナクラス２５０のコンテナ７４は、それぞれの機能要求２５４が機能結果２５６を提供するために機能に必要な入力を含むかどうかを評価する。かかる例では、機能要求が必要な入力を含まない場合、機能に関連付けられたコンテナクラスのコンテナは、いずれの機能結果２５６も提供しない。
【0150】
いくつかの実施形態では、本開示は、少なくとも５歳、少なくとも１０歳、少なくとも１１歳、少なくとも１２歳、少なくとも１３歳、少なくとも１４歳、少なくとも１５歳、少なくとも１６歳、少なくとも１７歳、少なくとも１８歳、少なくとも１９歳、または少なくとも２０歳である対象者を治療するために使用される。
【0151】
いくつかの実施形態では、本開示は、ボディマス指数が３２ｋｇ／ｍ２以下である対象者を治療するために使用される。いくつかの実施形態では、本開示は、ボディマス指数が３４ｋｇ／ｍ２以下である対象者を治療するために使用される。いくつかの実施形態では、本開示は、ボディマス指数が３５ｋｇ／ｍ２以下である対象者を治療するために使用される。いくつかの実施形態では、本開示は、ボディマス指数が３６ｋｇ／ｍ２以下である対象者を治療するために使用される。いくつかの実施形態では、本開示は、ボディマス指数が３７ｋｇ／ｍ２以下である対象者を治療するために使用される。いくつかの実施形態では、本開示は、ボディマス指数が３８ｋｇ／ｍ２以下である対象者を治療するために使用される。
【0152】
いくつかの実施形態では、本開示は、ボディマス指数が約２５ｋｇ／ｍ２である対象者を治療するために使用される。いくつかの実施形態では、本開示は、ボディマス指数が２０ｋｇ／ｍ２～３０ｋｇ／ｍ２である対象者を治療するために使用される。
【0153】
いくつかの実施形態では、本開示は、少なくとも１年間、少なくとも５年間、少なくとも７年間、少なくとも９年間、または少なくとも１１年間、糖尿病に罹患している対象者を治療するために使用される。
【0154】
いくつかの実施形態では、本開示は、数週間の治療後に、７％以下の対象者に対してベースラインＨｂＡ１ｃレベルを達成する。いくつかの実施形態では、本開示は、１０～４０週間の治療後、１５～３０週間の治療後、もしくは２０～２８週間の治療後、または２６週間の治療後に、７％以下の対象者に対してベースラインＨｂＡ１ｃレベルを達成する。いくつかの実施形態では、本開示は、数週間の治療後に、６％以下、７％以下、または８％以下の対象者に対してベースラインＨｂＡ１ｃレベルを達成する。いくつかの実施形態では、本開示は、１０～４０週間の治療後、１５～３０週間の治療後、もしくは２０～２８週間の治療後、または２６週間の治療後に、６％以下、７％以下、または８％以下の対象者に対してベースラインＨｂＡ１ｃレベルを達成する。
【0155】
いくつかの実施形態では、薬剤は、インスリンペン型デバイス１０４の使用によるなどの、注射によって送達されるインスリンを含む。いくつかの実施形態では、薬剤は、ＬｙｓＢ２９（Ｎｃ－ヘキサデカンジオイル－ｙ－Ｇｌｕ）ｄｅｓ（Ｂ３０）ヒトインスリン（インスリンデグルデク、Ｔｒｅｓｉｂａ（登録商標））である。
【0156】
本発明によれば、基礎インスリンは、長時間作用型インスリンおよび超長時間作用型インスリンを含むか、またはそれからなる。
【0157】
いくつかの実施形態では、薬剤は、天然に発生するインスリンの誘導体または類似体を含み、天然に発生するインスリンは、
（ａ）生理学的条件において、少なくとも部分的に、天然に発生するインスリンのインスリン受容体結合、好ましくは、天然に発生するインスリンのインスリン受容体結合の少なくとも０．０１％、例えば、天然に発生するインスリンのインスリン受容体結合の少なくとも０．１％、少なくとも１％、少なくとも５％、少なくとも１０％、少なくとも１５％、少なくとも２０％、少なくとも２５％、少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは少なくとも１５０％、および／または少なくとも部分的に、天然に発生するインスリンの能力、好ましくは、天然に存在するインスリンの能力の少なくとも２５％、例えば、天然に発生するインスリンの能力の少なくとも少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは１５０％を示し、かつ
（ｂ）皮下注射した場合、生理学的条件で少なくとも５時間～１８時間未満、例えば、少なくとも７時間、少なくとも８時間、少なくとも１０時間、少なくとも１２．５時間、１２．５時間超、少なくとも１５時間、または少なくとも１７．５時間、および１８時間未満、５～１７．５時間、１０～１７．５時間または１５～１７．５時間の平均終末半減期を示す。
（ａ）生理学的条件において、少なくとも部分的に、天然に発生するインスリンのインスリン受容体結合、好ましくは、天然に発生するインスリンのインスリン受容体結合の少なくとも０．０１％、例えば、天然に発生するインスリンのインスリン受容体結合の少なくとも０．１％、少なくとも１％、少なくとも５％、少なくとも１０％、少なくとも１５％、少なくとも２０％、少なくとも２５％、少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは少なくとも１５０％、および／または少なくとも部分的に、天然に発生するインスリンの能力、好ましくは、天然に存在するインスリンの能力の少なくとも２５％、例えば、天然に発生するインスリンの能力の少なくとも少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは１５０％を示し、かつ
（ｂ）皮下注射した場合、生理学的条件で少なくとも５時間～１８時間未満、例えば、少なくとも７時間、少なくとも８時間、少なくとも１０時間、少なくとも１２．５時間、１２．５時間超、少なくとも１５時間、または少なくとも１７．５時間、および１８時間未満、５～１７．５時間、１０～１７．５時間または１５～１７．５時間の平均終末半減期を示す。
【0158】
いくつかの実施形態では、薬剤は、「長時間作用型インスリン」を含み、これはまた、
（ｃ）対象者の２４時間の期間にわたる平均インスリン濃度（ＡＵＣＦ％）からの最大偏差を、≦±２０、例えば≦±１８、≦±１７、≦±１６、≦±１５、≦±１４、≦±１３、≦±１２、≦±１１、≦±１０、≦±９、≦±８、≦±７、≦±６、≦±５、≦±４、≦±３、≦±２、≦±１、≦±０．５、≦±０．１で誘発する。
（ｃ）対象者の２４時間の期間にわたる平均インスリン濃度（ＡＵＣＦ％）からの最大偏差を、≦±２０、例えば≦±１８、≦±１７、≦±１６、≦±１５、≦±１４、≦±１３、≦±１２、≦±１１、≦±１０、≦±９、≦±８、≦±７、≦±６、≦±５、≦±４、≦±３、≦±２、≦±１、≦±０．５、≦±０．１で誘発する。
【0159】
いくつかの実施形態では、薬剤は、天然に発生するインスリンの誘導体または類似体を含む「長時間作用型インスリン」を含み、これは、
（ａ）生理学的条件において、少なくとも部分的に、天然に発生するインスリンのインスリン受容体結合、好ましくは、天然に発生するインスリンのインスリン受容体結合の少なくとも０．０１％、例えば、天然に発生するインスリンのインスリン受容体結合の少なくとも０．１％、少なくとも１％、少なくとも５％、少なくとも１０％、少なくとも１５％、少なくとも２０％、少なくとも２５％、少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは少なくとも１５０％、および／または少なくとも部分的に、天然に発生するインスリンの能力、好ましくは、天然に存在するインスリンの能力の少なくとも２５％、例えば、天然に発生するインスリンの能力の少なくとも少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは１５０％を示し、
（ｂ）皮下注射した場合、生理学的条件で少なくとも１８時間、例えば、１８時間超、少なくとも２０時間、２０時間超、２２時間超、少なくとも２２．５時間、または２４時間超、少なくとも２５時間、少なくとも２７．５時間、少なくとも３０時間、少なくとも３２．５、少なくとも３５時間、少なくとも３７．５時間、または少なくとも４０時間、または１８～４０時間、２０～４０時間、２４時間～４０時間の平均終末半減期を示す。
（ａ）生理学的条件において、少なくとも部分的に、天然に発生するインスリンのインスリン受容体結合、好ましくは、天然に発生するインスリンのインスリン受容体結合の少なくとも０．０１％、例えば、天然に発生するインスリンのインスリン受容体結合の少なくとも０．１％、少なくとも１％、少なくとも５％、少なくとも１０％、少なくとも１５％、少なくとも２０％、少なくとも２５％、少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは少なくとも１５０％、および／または少なくとも部分的に、天然に発生するインスリンの能力、好ましくは、天然に存在するインスリンの能力の少なくとも２５％、例えば、天然に発生するインスリンの能力の少なくとも少なくとも５０％、少なくとも６５％、少なくとも７５％、少なくとも８５％、少なくとも９５％、少なくとも１００％、少なくとも１１０％、少なくとも１２０％、少なくとも１３０％、少なくとも１４０％、もしくは１５０％を示し、
（ｂ）皮下注射した場合、生理学的条件で少なくとも１８時間、例えば、１８時間超、少なくとも２０時間、２０時間超、２２時間超、少なくとも２２．５時間、または２４時間超、少なくとも２５時間、少なくとも２７．５時間、少なくとも３０時間、少なくとも３２．５、少なくとも３５時間、少なくとも３７．５時間、または少なくとも４０時間、または１８～４０時間、２０～４０時間、２４時間～４０時間の平均終末半減期を示す。
【0160】
いくつかの実施形態では、薬剤は、「長時間作用型インスリン」を含み、これはまた、
（ｃ）対象者の２４時間の期間にわたる平均インスリン濃度（ＡＵＣＦ％）からの最大偏差を、≦±２０、例えば≦±１８、≦±１７、≦±１６、≦±１５、≦±１４、≦±１３、≦±１２、≦±１１、≦±１０、≦±９、≦±８、≦±７、≦±６、≦±５、≦±４、≦±３、≦±２、≦±１、≦±０．５、≦±０．１で誘発する。
（ｃ）対象者の２４時間の期間にわたる平均インスリン濃度（ＡＵＣＦ％）からの最大偏差を、≦±２０、例えば≦±１８、≦±１７、≦±１６、≦±１５、≦±１４、≦±１３、≦±１２、≦±１１、≦±１０、≦±９、≦±８、≦±７、≦±６、≦±５、≦±４、≦±３、≦±２、≦±１、≦±０．５、≦±０．１で誘発する。
【0161】
原則として、インスリンの半減期が長いほど、投与間隔（すなわち、注射間の時間間隔）にわたってグルコース低下作用がより安定し、均等に分布する。
【0162】
本開示によれば、基礎インスリンは、長時間作用型インスリンおよび超長時間作用型インスリンを含むか、またはそれからなる。
【0163】
本開示によれば、基礎インスリンは、対象者において有益な血糖制御を達成する量で投与される。
【0164】
いくつかの実施形態では、薬剤は、１２～２４時間の作用持続時間を有する単一のインスリン薬剤、または集合的に１２～２４時間の作用持続時間を有するインスリン薬剤の混合物からなる。かかるインスリン薬剤の例としては、以下に限定されないが、Ｄｅｇｌｕｄｅｃ（商標名Ｔｒｅｓｉｂａ（登録商標）下でＮＯＶＯ ＮＯＲＤＩＳＫによって開発された）、ＮＰＨ（Ｓｃｈｍｉｄ，２００７，“Ｎｅｗ ｏｐｔｉｏｎｓ ｉｎ ｉｎｓｕｌｉｎ ｔｈｅｒａｐｙ，”Ｊ Ｐｅｄｉａｔｒｉａ（Ｒｉｏ Ｊ）．８３（Ｓｕｐｐｌ ５）：Ｓ１４６－Ｓ１５５）、Ｇｌａｒｇｉｎｅ（ＬＡＮＴＵＳ，Ｍａｒｃｈ ２，２００７）、Ｉｎｓｕｌｉｎ Ｇｌａｒｇｉｎｅ ｉｎｊｅｃｔｉｏｎ（Ｄｕｎｎ ｅｔ ａｌ．２００３，“Ａｎ Ｕｐｄａｔｅｄ Ｒｅｖｉｅｗ ｏｆ ｉｔｓ Ｕｓｅ ｉｎ ｔｈｅ Ｍａｎａｇｅｍｅｎｔ ｏｆ Ｄｉａｂｅｔｅｓ Ｍｅｌｌｉｔｕｓ”Ｄｒｕｇｓ ６３：ｐ．１７４３）、およびＤｅｔｅｒｍｉｒ（Ｐｌａｎｋ ｅｔ ａｌ．，２００５，“Ａ ｄｏｕｂｌｅ－ｂｌｉｎｄ，ｒａｎｄｏｍｉｚｅｄ，ｄｏｓｅ－ｒｅｓｐｏｎｓｅ ｓｔｕｄｙ ｉｎｖｅｓｔｉｇａｔｉｎｇ ｔｈｅ ｐｈａｒｍａｃｏｄｙｎａｍｉｃ ａｎｄ ｐｈａｒｍａｃｏｋｉｎｅｔｉｃ ｐｒｏｐｅｒｔｉｅｓ ｏｆ ｔｈｅ ｌｏｎｇ－ａｃｔｉｎｇ ｉｎｓｕｌｉｎ ａｎａｌｏｇ ｄｅｔｅｍｉｒ，”Ｄｉａｂｅｔｅｓ Ｃａｒｅ ２８：１１０７－１１１２）を含み、これらの各々は、参照により本明細書に組み込まれる。
【0165】
いくつかの実施形態では、複数の機能２５２は、第１の機能および第２の機能を含む（３０４）。いくつかの実施形態では、第１の機能（例えば、２５２－１）は、加算または減算を実施する。いくつかの実施形態では、第２の機能（例えば、２５２－２）は、（例えば、データセットを再構成するために）回帰分析および／または補間を実施する。いくつかの実施形態では、第１の機能（例えば、２５２－１）は、複数のコンテナクラスのうちの第１のコンテナクラス（例えば、２５０－１）のコンテナ（例えば、７４－１）の各インスタンスによって実行可能である。いくつかの実施形態では、コンテナクラスは、データ再構成クラス、順守クラス、計算クラス、および／または滴定グルコースレベルクラスを含む。いくつかの実施形態では、オーケストレータ２３０は、機能要求２５４を、必要なコンテナクラス（例えば、２５０－１）のインスタンスであるコンテナ（例えば、７４－１および７４－２）に分散する。
【0166】
いくつかの実施形態では、第１のコンテナクラス（例えば、２５０－１）のコンテナ（例えば、７４－２および７４－２）の各インスタンスは、第１のサーバのセット（図示せず）のうちのサーバによってホストされ、第２のコンテナクラス（例えば、２５０－Ｗ）のコンテナ（例えば、７４－Ｚ）の各インスタンスは、第２のサーバのセットのうちのあるサーバによってホストされる。かかる実施形態では、第１のサーバのセットは、第２のサーバのセットとは異なる。いくつかの実施形態では、かかるトポロジは、より演算集約型の機能として役立つコンテナのためのより強力な、またはより大きなサーバのセットのプロビジョニングを可能にするという利点を有する。代替的な実施形態では、二つ以上の異なるクラスのコンテナを、同じサーバ上で同時に動作させることが可能である。
【0167】
ブロック３０６を参照すると、いくつかの実施形態では、第１の機能は、複数のコンテナクラスのうちの第１のコンテナクラスのコンテナの各インスタンスによって実行可能である。例えば、第１の機能が滴定グルコースレベルクラスである場合、第１のコンテナクラスのコンテナの各インスタンスは、滴定グルコースレベルクラスを有する。
【0168】
ブロック３０８を参照すると、いくつかの実施形態では、第２の機能は、複数のコンテナクラスのうちの第２のコンテナクラスのコンテナの各インスタンスによって実行可能である。言い換えれば、コンピューティングシステムによって提供されるそれぞれの機能と、それぞれのコンテナクラスとの間に一対一の対応がある。
【0169】
いくつかの実施形態では、複数のコンテナクラスは、二つ以上のコンテナクラス、三つ以上のコンテナクラス、四つ以上のコンテナクラス、または五つ以上のコンテナクラスを含む。
【0170】
ブロック３１０を参照すると、いくつかの実施形態では、第１の機能のハードウェアリソース要件は、第２の機能のハードウェアリソース要件とは異なる。言い換えれば、いくつかの実施形態では、複数の機能は、第１の機能および第２の機能を含み、第１の機能は、複数のコンテナクラスのうちの第１のコンテナクラスのコンテナの各インスタンスによって実行可能であり、第２の機能は、複数のコンテナクラスのうちの第２のコンテナクラスのコンテナの各インスタンスによって実行可能であり、第１の機能のハードウェアリソース要件は、第２の機能のハードウェアリソース要件とは異なる。一つのかかる実施例では、第１の機能は、第２の機能よりも演算的により高価である。例えば、第１の機能を取り扱うコンテナクラスのコンテナは、第２の機能を取り扱うコンテナクラスのコンテナよりも多くのＣＰＵ時間を必要とする。代替的にまたは追加として、第１の機能を取り扱うコンテナクラスのコンテナは、第２の機能を取り扱うコンテナクラスのコンテナよりも多くのランダムアクセスメモリを必要とし得る。したがって、本開示のいくつかの実施形態では、所与のタイプの機能に対して特定のコンテナクラスの別のコンテナを開始するかどうかを決定する際に、コンテナの相対的なリソース要件が考慮される。すなわち、特定の機能に対する要求の数は、経時的な特定の機能に対する要求にわたるハードウェアリソース要件の中心傾向の推定される尺度によって重み付け（スケール化、正規化）される。いくつかの実施形態では、本開示のシステムによって提供される複数の機能の機能ごとの相対的なリソース要件に対する好適なメトリック（スケーリングファクタ）を導き出すために、かかる機能に対する過去の要求にわたって、特定の機能のリソース要件の記録が保持される。いくつかの実施形態では、かかる機能要求のリソース要件の中心傾向の尺度は、経時的に機能ごとに追跡される。いくつかの実施形態では、かかる中心傾向の尺度を演算する場合、より古い機能要求が、より最近の機能要求よりも低く重み付けされる。
【0171】
いくつかの実施形態では、エンコーダモジュールは、（例えば、エンジン７０全体のリソース要件を評価し、それに伴って、最も効率的なリソースの使用を確保し、演算上の無駄を最小限に抑えることとは対照的に）リソース要件に対して、各それぞれの機能を評価することをさらに含む。いくつかの実施形態では、第１のコンテナクラスのコンテナの第１のインスタンスのセットの複合リソース要件は、定期的なベースで評価される。かかる実施形態では、第１のコンテナクラスのコンテナの第１のインスタンスのセットの複合リソース要件が、第１のコンテナのセットに関連付けられた第１のリソース割り当て閾値を満たす場合（例えば、対応する機能で現在割り当てられているコンテナのセットが扱うことができるよりも多くの対応する機能の機能要求が行われている場合）、コンテナクラスのコンテナの一つ以上の追加のインスタンスが第１のコンテナのセットに追加され、第１のコンテナクラスのタイプと一致するエンコーダモジュールからの機能要求を受理することができる。いくつかの実施形態では、所与のコンテナクラスに関連付けられた第１のリソース割り当て閾値は、上述のように、経時的に追跡される所与のコンテナクラスのそれぞれのサービス提供済み機能要求のリソース要件の中心傾向の尺度の評価に基づいて、経時的に調整される。
【0172】
いくつかの実施形態では、所与のコンテナクラスに関連付けられた第１のリソース割り当て閾値は、コンテナクラスのコンテナのセットによって集合的に使用されるランダムアクセスメモリが、＞１ＭＢ、＞５ＭＢ、＞５０ＭＢ、＞５００ＭＢ、＞１ＧＢ、または＞５ＧＢである場合に満たされる。いくつかの実施形態では、所与のコンテナクラスに関連付けられた第１のリソース割り当て閾値は、コンテナクラスのコンテナのセットが、機能結果２５６を返すために、平均、＞０．０５秒、＞０．５秒、＞１秒、＞５秒、＞１０秒、＞１５秒、＞３０秒、＞１分、または＞５分を必要とする場合に満たされる。
【0173】
いくつかの実施形態では、第１のコンテナクラスの第１のインスタンスのセットの複合リソース要件が、第１のコンテナのセットに関連付けられた第２のリソース割り当て閾値を満たす場合、第１のコンテナのセットの一つ以上のコンテナが第１のコンテナのセットから除去され、エンコーダモジュールからの機能要求をもはや受理することができない。いくつかの実施形態では、所与のコンテナクラスに関連付けられた第２のリソース割り当て閾値は、上述のように、経時的に追跡される所与のコンテナクラスのそれぞれのサービス提供済み機能要求のリソース要件の中心傾向の尺度の評価に基づいて、経時的に調整される。
【0174】
いくつかの実施形態では、所与のコンテナクラスに関連付けられた第２のリソース割り当て閾値は、コンテナクラスのコンテナのセットのために集合的に使用されるランダムアクセスメモリが、＜１ＭＢ、＜５ＭＢ、＜５０ＭＢ、＜５００Ｍｂ、＜１ＧＢ、または＜５ＧＢである場合に満たされる。いくつかの実施形態では、所与のコンテナクラスに関連付けられた第２のリソース割り当て閾値は、コンテナクラスのコンテナのセットが、機能結果２５６を返すために、平均、＜０．０５秒、＜０．５秒、＜１秒、＜５秒、＜１０秒、＜１５秒、＜３０秒、＜１分、または＜５分を必要とする場合に満たされる。
【0175】
図６のブロック３１２を参照すると、いくつかの実施形態では、本方法は、特定の対象者に対する医薬品投与ガイダンス要求を満たすために必要な複数の機能要求を識別する。かかる実施形態では、複数の機能要求のうちの機能要求２５４は、複数の機能のうちの対応する機能によって実行可能である。いくつかの実施形態では、複数の機能要求は、二つ以上の対応するコンテナクラスのサービスを必要とする二つ以上の機能に対する要求を含む。いくつかの実施形態では、複数の機能要求は、三つ以上の対応するコンテナクラスのサービスを必要とする三つ以上の機能に対する要求を含む。いくつかの実施形態では、複数の機能要求は、四つ以上の対応するコンテナクラスのサービスを必要とする四つ以上の機能に対する要求を含む。いくつかの実施形態では、複数の機能要求は、五つ以上の対応するコンテナクラスのサービスを必要とする五つ以上の機能に対する要求を含む。
【0176】
いくつかの実施形態では、複数の機能要求は、第１の機能要求を含む。いくつかの実施形態では、この第１の機能要求は、対象者の推奨医薬品投与ガイダンスを計算する（例えば、対象者に新しい、かつ／または更新された推奨投与を提供する）ためのものである。代替的な実施形態では、この第１の機能要求は、対象者のインスリン注射履歴を再構成するためのものである。例えば、いくつかの実施形態では、インスリン注射履歴は、インスリンペン１０４によって収集され、インスリンペン１０４また、対象者のインスリン注射履歴を医薬品投与ガイダンスシステム６０２に送信する。いくつかの実施形態では、インスリン注射履歴は、時間的なギャップ（例えば、データポイントの欠落）または他のエラー（例えば、インスリン注射としての「プライミング」事象のログ）を含む。かかるオカレンスは、参照により本明細書に組み込まれる、２０１７年８月２３日に出願された「Ｐａｔｉｅｎｔ Ｍｏｕｎｔｅｄ Ｍｉｃｒｏ Ｖｅｉｎ Ｅｎｈａｎｃｅｒ」と題する米国特許出願公開第２０１８／００１４７７６（Ａ１）号に記載されている。いくつかの実施形態では、医薬品投与ガイダンスシステム６０２は、推奨インスリン投与ガイダンスを提供する一環として、対象者のインスリン注射履歴を再構成する必要がある。
【0177】
いくつかの実施形態では、第１の機能要求は、対象者の滴定グルコースレベルを計算するためのものである。滴定グルコースレベルは、対象者のグルコースセンサ１０２によって収集される血糖履歴、およびインスリンペン１０４によって投与されるインスリン注射量に基づく。滴定グルコースレベルは、対象者ごとに特異的であり、いくつかの実施形態では、一つ以上の対象者パラメータ５１２にも基づく。いくつかの実施形態では、滴定グルコースレベルを計算する方法は、参照により本明細書に組み込まれる、２０１７年６月２３日に出願された「Ｂａｓａｌ Ｔｉｔｒａｔｉｏｎ ｗｉｔｈ Ａｄａｐｔｉｖｅ Ｔａｒｇｅｔ Ｇｌｕｃｏｓｅ Ｌｅｖｅｌ」と題する国際出願第ＰＣＴ／ＥＰ２０１７／０６５５７８号に記載されるとおりである。
【0178】
いくつかの実施形態では、第１の機能要求は、対象者の血糖履歴を再構成するためのものである。いくつかの実施形態では、対象者の血糖履歴は、グルコースセンサ１０２によって測定され、グルコースセンサ１０２は、いくつかの実施形態では、参照により本明細書に組み込まれる、２００３年１２月９日に出願された「Ｇｒａｐｈｉｃａｌ Ｄｉｓｐｌａｙ ｆｏｒ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｄｉｓｐｌａｙｉｎｇ Ｍｅｄｉｃａｌ Ｉｎｆｏｒｍａｔｉｏｎ」と題する米国特許公開第２００４／０１５３２５７（Ａ１）号に記載されるような連続血糖モニタである。いくつかの実施形態では、血糖履歴は、時間的なギャップ（例えば、データポイントの欠落）を含む。例えば、連続血糖モニタは、血糖値を記憶する際のユーザエラーまたはその他の技術的難しさにより、断続的な期間にわたって対象者の血糖値を記録することができない場合がある。いくつかの実施形態では、グルコース測定値は、グルコースセンサによって自律的に測定される。例えば、いくつかの実施形態では、グルコースセンサ１０２は、対象者の自律的なグルコース測定を行うＡＢＢＯＴＴによるＦＲＥＥＳＴＹＬＥ ＬＩＢＲＥ ＣＧＭ（「ＬＩＢＲＥ」）に代表される。ＬＩＢＲＥは、近づけると、近距離無線通信を介して最高８時間分のデータをリーダーデバイスに送ることができる、皮膚上のコインサイズのセンサを用いる較正不要のグルコース測定を可能にする。ＬＩＢＲＥは１４日間着用することができる。
【0179】
いくつかの実施形態では、第１の機能要求は、対象者の投与ガイダンスパラメータ（例えば、対象者パラメータ５１２）を取得するためのものである。いくつかの実施形態では、投与ガイダンスパラメータは、対象者の体重、対象者の年齢、対象者の上限目標グルコース範囲、対象者の下限目標グルコース範囲、対象者の過度の基礎化限界、最新の推奨医薬品投与ガイダンスおよび／もしくは対象者の開始インスリン基礎投与、ならびに対象者の基礎注射履歴のうちの一つ以上を含む。
【0180】
いくつかの実施形態では、更新される最新の推奨医薬品投与ガイダンスを決定するために使用される上限目標グルコース範囲は、８０～１８０ｍｇ／ｄＬ、９０～１８０ｍｇ／ｄＬ、１００～１８０ｍｇ／ｄＬ、９０～２００ｍｇ／ｄＬ、９０～２５０ｍｇ／ｄＬ、または９０～３００ｍｇ／ｄＬの範囲内である。
【0181】
いくつかの実施形態では、更新される推奨医薬品投与ガイダンスを決定するために使用される下限目標グルコース範囲は、５０～７０ｍｇ／ｄＬ、７０～９０ｍｇ／ｄＬ、７０～１００ｍｇ／ｄＬ、６０～１００ｍｇ／ｄＬ、または６０～９０ｍｇ／ｄＬの範囲内である。
【0182】
いくつかの実施形態では、対象者の血糖履歴を再構成することは、血糖履歴時間的経過が時間的なギャップを含む場合（例えば、対象者の連続グルコースモニタが、センサエラー（ユーザもしくは技術的エラーのいずれか）を有し、断続的な時間にわたって血糖測定値を記録していない場合、または対象者が連続グルコースモニタに影響を及ぼすエラーを犯した場合）、対象者の再構成された血糖履歴を計算することを含む。いくつかの実施形態では、時間的経過のギャップは、いずれの血糖測定値も記録されなかった所与の期間からなる。いくつかの実施形態では、血糖履歴のギャップを定義する所与の期間は、＞５分、＞１０分、＞２０分、＞３０分、または＞１時間である。
【0183】
いくつかの実施形態では、血糖履歴にギャップがある場合、再構成された血糖履歴は、ギャップの直前の過去１時間、ギャップの直前の過去１週間、ギャップの直前の過去２週間、ギャップの直前の過去１ヶ月、またはギャップの直前の過去１年間にわたる対象者の血糖履歴に基づいて計算される。いくつかの実施形態では、再構成された血糖履歴は、ギャップの前後１分、ギャップの前後５分、ギャップの前後１０分、ギャップの前後１５分、ギャップの前後３０分、および／またはギャップの前後１時間の血糖履歴に基づいて計算される。
【0184】
いくつかの実施形態では、機能要求が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／もしくは対象者の開始インスリン基礎投与、ならびに／または（ｖｉｉ）対象者の基礎注射履歴、が含まれる。一部の機能要求は、この情報のサブセットのみを必要とする。一部の機能要求は、追加のデータを必要とする。
【0185】
いくつかの実施形態では、機能要求が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴のうちのいずれか一つが含まれる。かかる機能要求の一部は、追加のデータを必要とする。
【0186】
いくつかの実施形態では、機能要求が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴のうちのいずれか二つが含まれる。かかる機能要求の一部は、追加のデータを必要とする。
【0187】
いくつかの実施形態では、機能要求が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴のうちのいずれか三つが含まれる。かかる機能要求の一部は、追加のデータを必要とする。
【0188】
いくつかの実施形態では、機能要求が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴のうちのいずれか三つが含まれる。かかる機能要求の一部は、追加のデータを必要とする。
【0189】
ブロック３１４を参照すると、いくつかの実施形態では、本方法は、エンコーダモジュール２４０を使用して、複数の機能要求のうちの各それぞれの機能要求２５４に対して、それぞれの機能要求２５４を、それぞれの機能要求２５４に対応する機能に関連付けられたコンテナクラスのコンテナに埋め込む。いくつかの実施形態では、それぞれの機能要求に対応する機能に関連付けられたコンテナクラスの所与のコンテナは、２人以上、３人以上、４以上、５人以上、６人以上、７人以上、８人以上、１０人以上、５０人以上、１００人以上、１０００人以上、または１０，０００人の対象者に対して、同じクラスの二つ以上、三つ以上、四つ以上、五つ以上、六つ以上、七つ以上、八つ以上、１０個以上、５０個以上、１００個以上、１０００個以上、または１０，０００個以上の要求を同時にサービス提供する。
【0190】
ブロック３１６を参照すると、いくつかの実施形態では、本方法は、複数の機能要求のうちの各それぞれの機能要求２５４に対して、それぞれの機能要求２５４を実行したコンテナクラスのコンテナからの機能結果２５６を収集し、それによって、複数の対象者のうちの単一の対象者に対する複数の機能結果を取得する。この目的のために、いくつかの実施形態では、対象者に対して第１の機能および第２の機能が、同時実行される。代替的な実施形態では、対象者に対して第１の機能および第２の機能が、順次実行される。さらに他の実施形態では、ブール論理を使用して、所与の対象者に対して特定の機能要求を行うかどうかをゲート制御する。例えば、いくつかの実施形態では、第１のコンテナクラスに対応する第１の機能要求の機能結果が、モニタリング条件を満たさないという結果をもたらす場合、対象者に対して、第２のコンテナクラスに対応する第２の機能要求は発出されない。
【0191】
ブロック３１８を参照すると、いくつかの実施形態では、本方法は、複数の機能結果を使用して推奨医薬品投与ガイダンスを提供する。ブロック３１８は、全ての要求された機能要求が、対象者に対する有効な推奨用量を計算するために処理され得る好適な機能結果を返した場合に、達成される。いくつかの実施形態では、本方法は、投与ガイダンス要求の品質確認を実施することをさらに含み、品質確認が失敗した場合（例えば、品質確認により、機能要求が、機能要求を処理するための対応する機能に対して必要な情報、例えば、対象者パラメータ５１２に関する情報もしくは必要な機能に関する情報を欠いていることが明らかになった場合、または機能要求のサイズが、利用可能なコンピューティングリソースを圧倒している場合）、いずれの推奨医薬品投与ガイダンスも提供されない。いくつかの実施形態では、データ品質確認が失敗した場合、および対象者が低血糖事象を記録するか、または対象者が以前に推奨された医薬品用量を摂取することができなかったかのいずれかの場合、推奨医薬品投与ガイダンスが提供される。いくつかの実施形態では、対象者は、対象者の血糖値が７０ｍｇ／Ｌ、７５ｍｇ／Ｌ、８０ｍｇ／Ｌ、６５ｍｇ／Ｌ、６０ｍｇ／Ｌ、５５ｍｇ／Ｌ、５０ｍｇ／Ｌ、４５ｍｇ／Ｌ、または４０ｍｇ／Ｌを下回る場合に、低血糖事象を記録する。いくつかの実施形態では、対象者は、対象者が投与を行うのを忘れた場合、または対象者が誤った投与量を摂取した場合、以前に推奨された医薬品投与を行うことができない。
【0192】
図７は、対象者に推奨医薬品投与ガイダンスを提供するための（例えば、電子デバイスで実施される）例示的な方法４００の例示している。いくつかの実施形態では、図７の方法は、対象者が推奨医薬品投与ガイダンスを以前に提供されていない場合に実施される。いくつかの実施形態では、図７の方法は、以前に提供された推奨医薬品投与ガイダンスの再推奨を提供する。いくつかの実施形態では、図７の方法を実施して、更新される推奨医薬品投与ガイダンスを提供し、その後、一つ以上の以前の推奨医薬品投与ガイダンスを提供する。
【0193】
図７を参照すると、コンピュータシステム６０２は、医薬品投与ガイダンス要求４０２を受信する。いくつかの実施形態では、医薬品投与ガイダンス要求は、ユーザデバイス（例えば、対象者ユーザデバイス１１０）によって自動的に（人が介在することなく）生成される。いくつかの実施形態では、ユーザは、医薬品投与ガイダンスに対して特定の要求を行う。本方法は、続行され、要求が有効であることの確認４０４を行う（例えば、システムは、必須のまたは必要なデータ、例えば、対象者の体重、対象者の上限目標グルコース範囲、対象者の下限目標グルコース範囲、対象者の過度の基礎化限界、最新の推奨医薬品投与ガイダンスおよび／もしくは開始基礎インスリン投与、対象者の血糖履歴、対象者の基礎インスリン注射履歴、ならびに／または対象者の注射データ再読込のうちの一つ以上が、要求に含まれていることを確認する）。いくつかの実施形態では、機能要求２５４が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨医薬品投与ガイダンスおよび／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴のうちのいずれか一つ以上、これらのうちのいずれか二つ以上、これらのうちのいずれか三つ以上、これらのうちのいずれか四つ以上、これらのうちのいずれか五つ以上、これらのうちのいずれか六つ以上、これらの七つ全て、これらのうちの少なくとも七つ全て、が含まれる。いくつかの実施形態では、機能要求２５４が必要とする入力には、所与の対象者に対して、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、（ｉｖ）対象者の過度の基礎化限界、（ｖ）対象者の血糖履歴、（ｖｉ）最新の推奨インスリン滴定および／または対象者の開始インスリン基礎投与、ならびに（ｖｉｉ）対象者の基礎注射履歴、のサブセットが含まれる。
【0194】
投与ガイダンス要求に必要なデータが含まれていない場合、本方法は終了し４０５、ガイダンスは提供されず、任意選択で、適切なデータを後で返すようにユーザに通知する。いくつかの実施形態では、デバイスは、どのデータが欠落しているかをユーザに通知するか、またはユーザがその医療デバイスについて支援を求めることを提案する。医薬品投与ガイダンス要求に適切な情報が含まれている場合、本方法は、要求された推奨医薬品投与ガイダンスを提供するために必要な機能要求２５４（例えば、投与ガイダンス要求内に含まれる機能要求）を識別し４０６、複数の機能要求のうちの各機能要求２５４は、複数の機能のうちの対応する機能によって実行可能である。本方法は、各機能要求に対して初期ハードウェアリソース要件（例えば、メモリ要件、計算の複雑さなど）の決定４０８を行う。いくつかの実施形態では、本方法は、必要なコンテナの数および／または機能要求のタイプによるコンテナの分割を決定する。いくつかの実施形態では、オーケストレータ２３０は、ハードウェアリソース決定を実施する。いくつかの実施形態では、ハードウェアリソース決定は、対象者に推奨医薬品用量を提供するために必要な機能要求を実施するのに必要な機能に関連付けられたコンテナクラスのコンテナをインスタンス化することを含む。
【0195】
本方法は、続行され、機能要求に関連する機能を、選択された（例えば、インスタンス化された）コンテナに埋め込む（４１０）。いくつかの実施形態では、オーケストレータ２３０は、埋め込みを実施する。機能要求は、適切な埋め込まれた機能を有するコンテナに割り当てられる４１２。各機能要求２５４は、機能を実施するために必要なデータセットを含めるために評価される４０７。必要なデータが機能要求２５４に含まれていない場合、本方法はプロセスを終了し４０５、ガイダンスは提供されず、任意選択で、後で返すようにユーザに通知する。
【0196】
コンテナに割り当てられており、必要なデータセットが含まれている各機能要求２５４に対して、それぞれのコンテナは、機能要求を実行する４１４。本方法によって、システムが機能要求２５４を実施するためにはより多くの演算リソースが必要であると決定された場合４０９、それぞれのコンテナクラスのより多くのコンテナが、それぞれの機能要求を実施するために割り当てられる４１１。本方法によって、機能要求を実行するために十分な演算リソースが利用可能であると決定された場合、方法は続行される。
【0197】
コンテナは、機能要求に結果を返す４１６。いくつかの実施形態では、コンテナは、各投与ガイダンス要求５１０に対して機能要求を同時実行する。いくつかの実施形態では、コンテナは、各投与ガイダンス要求５１０に対して機能要求を順次実行する。いくつかの実施形態では、コンテナは、投与ガイダンス要求５１０に対して機能要求のサブセットを同時実行し、機能要求の別のサブセットを順次実行する。本方法は、続行され、複数の機能結果（例えば、２５６－１－１、２５６－１－Ｖなど）を使用して、対象者に結果（例えば、推奨医薬品投与ガイダンス）を提供する４１８。いくつかの実施形態では、結果は、ユーザ（例えば、対象者ユーザデバイス１１０）に直接提供される。いくつかの実施形態では、結果は、データ送信デバイス１５０を介してユーザに提供される。
【0198】
図８を参照すると、本開示のいくつかの実施形態では、医薬品投与ガイダンス要求５１０は、真性糖尿病を治療するために血糖値を低下させるためのインスリン用量の滴定に関するガイダンスのための要求である。かかる実施形態では、対象者ユーザデバイス１１０は、グルコースセンサ１０２およびインスリンペン１０４のうちの一つ以上からなり得る。統合システム５０２は、対象者のタイムスタンプ付きインスリン注射および血糖測定値を（例えば、グルコースセンサ１０２および／またはインスリンペン１０４から）自律的に取得する５２０。また、いくつかの実施形態では、対象者が処方されたインスリンレジメンを適用するために使用する一つ以上のインスリンペン１０４からのデータが、複数の注射履歴記録として取得される５４０。各注射履歴データポイントは、対象者が処方されたインスリン薬剤用量レジメンの一部として受け取った、注射されたインスリン薬剤の量を特定するタイムスタンプ付き事象を含む。グルコース測定値（例えば、血糖履歴）は、品質評価５０４で評価され、必要に応じて、再構成された血糖履歴が計算される。血糖履歴または再構成された血糖履歴は、非一時的メモリ５０６に保存される。メモリ５０６は、命令を含み、命令は、一つ以上のプロセッサによって実行されると、投与ガイダンス要求を受信することに応答して方法を実施する。本開示の方法に従って、推奨投与ガイダンス要求をコンピュータシステム６０２に送って５１０、推奨医薬品投与ガイダンス６１０を提供する。
【0199】
いくつかの実施形態では、医薬品投与ガイダンス要求は、少なくとも、（ｉ）対象者の体重、（ｉｉ）対象者の上限目標グルコース範囲、（ｉｉｉ）対象者の下限目標グルコース範囲、および（ｉｖ）対象者の過度の基礎化限界、を含む、対象者パラメータ５１２を取得することを含む。いくつかの実施形態では、医薬品投与ガイダンス要求はまた、少なくとも、（ｉ）最新の推奨医薬品投与ガイダンス、および／または（ｉｉ）開始基礎投与、が含まれる、第２のデータセット５２２（医薬品投与ガイダンスベースライン）を取得することを含む。いくつかの実施形態では、医薬品投与ガイダンス要求はまた、血糖データセット５２０を取得することを含み、血糖データセットは、血糖履歴を確立するために時間的経過にわたって得られた対象者の複数のグルコース測定値と、複数のグルコース測定値のうちの各それぞれのグルコース測定値に対する、時間的経過の中でそれぞれのグルコース測定がいつ行われたかを表す対応するグルコースタイムスタンプと、を含む。いくつかの実施形態では、医薬品投与ガイダンス要求はまた、注射履歴データセット５４０を取得することを含み、注射履歴データセットは、（ｉ）注射履歴が、時間的経過の全てまたは一部の間の複数の注射を含む、対象者の基礎インスリン注射履歴、ならびに複数の注射のうちの各それぞれの注射について、（ｉｉ）対応する投与事象量、および（ｉｉｉ）時間的経過の中でそれぞれの注射事象がいつ行われたかを表す投与事象タイムスタンプ、を含み、第２のデータセットは、（ｉｖ）対象者の最後の注射データ再読込をさらに含む。
【0200】
いくつかの実施形態では、推奨医薬品投与ガイダンスを決定するために使用される上限目標グルコース範囲は、８０～１８０ｍｇ／ｄＬ、９０～１８０ｍｇ／ｄＬ、１００～１８０ｍｇ／ｄＬ、９０～２００ｍｇ／ｄＬ、９０～２５０ｍｇ／ｄＬ、または９０～３００ｍｇ／ｄＬの範囲内である。いくつかの実施形態では、推奨医薬品投与ガイダンスを決定するために使用される下限目標グルコース範囲は、５０～７０ｍｇ／ｄＬ、７０～９０ｍｇ／ｄＬ、７０～１００ｍｇ／ｄＬ、６０～１００ｍｇ／ｄＬ、または６０～９０ｍｇ／ｄＬの範囲内である。
【0201】
いくつかの実施形態では、グルコース測定値５２２は、自律的に測定される。ＡＢＢＯＴＴ（「ＬＩＢＲＥ」）によるＦＲＥＥＳＴＹＬＥ ＬＩＢＲＥ ＣＧＭは、対象者の自律的なグルコース測定を行うためにグルコースセンサ１０２として使用され得る、グルコースセンサの例である。ＬＩＢＲＥは、近づけると、近距離無線通信を介して最高８時間分のデータをリーダーデバイス（例えば、データ送信デバイス１５０および／またはコンピュータシステム６０２）に送ることができる、皮膚上のコインサイズのセンサを用いる較正不要のグルコース測定を可能にする。ＬＩＢＲＥは、全日常生活活動において１４日間着用することができる。
【0202】
いくつかの実施形態では、医薬品投与ガイダンス要求はまた、評価情報のセットに少なくとも、（ｉ）対象者の体重、（ｉｉ）時間的経過にわたって得られた対象者の複数のグルコース測定値、（ｉｉｉ）対象者の注射履歴、（ｉｖ）最後の推奨医薬品投与ガイダンスおよび／または対象者の開始長時間作用型もしくは超長時間作用型インスリン投与、（ｖ）対象者の過度の基礎化限界、（ｖｉ）対象者の最後の注射データ再読込、（ｖｉｉ）対象者の上限目標グルコース範囲、ならびに（ｖｉｉｉ）対象者の下限目標グルコース範囲、が含まれるかどうかについて、提供された対象者情報を評価することを含む。提供された対象者情報に必要な評価情報のセットが含まれていないとの決定がなされた場合、いずれの推奨医薬品投与ガイダンスも行われない。適切な評価情報が利用可能であるとの決定がなされた場合、コンピューティングシステム６０２の方法は、推奨医薬品投与ガイダンス６１０を提供することを含む。
【0203】
いくつかの実施形態では、達成および維持がインスリン滴定の主要目標である目標の血糖目標範囲は、５０～１８０ｍｇ／ｄＬ、６０～１８０ｍｇ／ｄＬ、７０～１８０ｍｇ／ｄＬ、８０～１８０ｍｇ／ｄＬ、５０～２００ｍｇ／ｄＬ、６０～２００ｍｇ／ｄＬ、７０～２００ｍｇ／ｄＬ、８０～２００ｍｇ／ｄＬ、５０～２５０ｍｇ／ｄＬ、６０～２５０ｍｇ／ｄＬ、７０～２５０ｍｇ／ｄＬ、または８０～２５０ｍｇ／ｄＬである。
【0204】
インスリンの投与は、例えば、体重（および／もしくは身長）、空腹時血糖、ならびに性別（以後、高速血糖および／もしくはＨｂＡ１ｃレベルの結果に従って経験的に調整される）に基づいて計算され得る、様々な方法を介して決定され得る。初期投与標準または経験的に決定された投与を施した後、必要に応じて、目標血糖／血漿および／またはＨｂＡ１ｃレベルに到達して維持するために、血糖／血漿測定値に基づいて、さらなる投与が事前に決定された増分によって調整される滴定法（例えば、滴定アルゴリズム）を使用することがますます一般的になっている。ただし、かかる滴定モデルは、常にガイダンスとしてのみ提供され、個々の調整は（例えば、推奨インスリン滴定ガイダンスを介して）ケースバイケースを基本として適用可能である。
【0205】
図９を参照すると、コンピューティングシステム６０２は、１人以上の対象者から医薬品投与ガイダンス要求５１０を受信し、各対象者に対して推奨医薬品投与ガイダンス６１０を提供する。好ましい実施形態では、医薬品投与ガイダンスシステム６０２は、クラウド環境内に存在する。コンテナエンジン７０は、医薬品投与ガイダンス要求５１０を受信する。いくつかの実施形態では、エンジン機能は、演算集約性のレベル、ならびに異なる投与ガイダンスシステムにわたるコンテナの再利用性のレベル（例えば、複数の機能のうちのそれぞれの機能がどれだけ頻繁に使用されるか）に基づいて、コンテナ７４に分離される。医薬品投与ガイダンス要求５１０には、対象者情報５１２が含まれる。いくつかの実施形態では、対象者情報５１２－１は、少なくとも、対象者の血糖履歴、最新の推奨インスリン滴定および／または対象者の開始インスリン基礎投与、ならびに対象者の基礎注射履歴を含む。いくつかの実施形態では、対象者パラメータ５１２は、少なくとも、対象者の体重、時間的経過にわたって得られた対象者の複数のグルコース測定値、対象者の注射履歴、対象者の過度の基礎化限界、対象者の最後の注射データ再読込、対象者の上限目標グルコース範囲、および対象者の下限目標グルコース範囲、を含む。
【0206】
オーケストレータ２３０は、コンテナエンジン７０内で、対象者パラメータ５１２に基づいて、医薬品投与ガイダンス要求５１０に応答して、医薬品投与ガイダンス要求５１０の機能要求２５４を組織化する。オーケストレータ２３０は、対象者パラメータ５１２に基づいて、どの機能６０８が必要かを識別する。必要な機能は、エンコーダモジュール２４０（図示せず）によって、選択されたコンテナ７４に埋め込まれる。オーケストレータ２０３は、機能を実施する必要がある順序が存在するかどうかをさらに決定する。例えば、データ再構成埋め込み型機能６０８－４を有するコンテナ７４－４は、順守埋め込み型機能６０８－２を有するコンテナ７４－２の前に、またはそれと並行して機能要求を実行するようにスケジュールされ得る、これは、これらの機能が互いに独立して実行され得るためである。しかしながら、いくつかの実施形態では、コンテナ７４－２、７４－３、および７４－４のセットのうちのあるコンテナは、計算埋め込み型機能６０８－１を有するコンテナ７４－１に依存し得る（例えば、コンテナ７４－２内の順守埋め込み型機能６０８－２は、いくつかの計算を必要とする場合があり、これらの計算は、いくつかの実施形態では、コンテナ７４－１内の計算埋め込み型機能６０８－１によって実施され得る）。オーケストレータ２３０は、必要に応じて、演算リソースの追加（例えば、任意の特定のコンテナクラスにおける追加のコンテナ７４）をトリガし得る。例えば、データ再構成のための埋め込み型機能６０８－４を有するコンテナ７４－４は、専用の追加リソース（例えば、同じコンテナクラスのより多くのコンテナ７４）を有し、それによって、医薬品投与ガイダンス要求５１０に対する応答がタイムアウトしないことを確保することができる。
【0207】
いくつかの実施形態では、機能要求により多くの演算リソースが必要な場合、オーケストレータ２３０は、その機能要求に対してそれぞれの機能を実行することができる、コンテナクラスのコンテナをインスタンス化する。
【0208】
オーケストレータ２３０は、各コンテナ７４の進捗を監視し、コンテナは、コンテナ間で情報を交換して、コンテナのそれぞれの機能要求２５４の実行を容易にすることができる。複数のコンテナのうちの各コンテナ７４は、オーケストレータ２３０の呼び出し時にマイクロサービスアーキテクチャに従って、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して他のコンテナと通信する。いくつかの実施形態では、オーケストレータ２３０は、Ａｚｕｒｅ Ｓｅｒｖｉｃｅ Ｆａｂｒｉｃ、Ｋｕｂｅｒｎｅｔｅｓ、Ｄｏｃｋｅｒ Ｓｗａｒｍ、およびＭｅｓｏｓｐｈｅｒｅ ＤＣ／ＯＳを含むが、これらに限定されない、複数の市販のオーケストレータのいずれかである。いくつかの実施形態では、オーケストレータ２３０は、市販されていない専有のオーケストレータである。
【0209】
各コンテナ７４は、それぞれの機能要求２５４に対して機能結果２５６を生み出す。複数の機能結果を使用して、推奨医薬品投与ガイダンス６１０を提供する。いくつかの実施形態では、別のコンテナ（例えば、７４－５、図示せず）を使用して、複数の機能要求をコンパイルし、対象者に対する推奨医薬品投与ガイダンス６１０に組み合わせることができる。いくつかの実施形態では、オーケストレータ２３０は、機能結果のコンパイルを実施し、対象者に推奨医薬品投与ガイダンス６１０を提供する。
【0210】
引用された参考文献および代替的な実施形態
本明細書に引用された全ての参考文献は、各個々の出版物、または特許、または特許出願が、全て目的のためにその全体が参照により組み込まれるように具体的かつ個々に示されるのと同じ程度の範囲で、それらの全体が参照により、全ての目的のために本明細書に組み込まれる。
本明細書に引用された全ての参考文献は、各個々の出版物、または特許、または特許出願が、全て目的のためにその全体が参照により組み込まれるように具体的かつ個々に示されるのと同じ程度の範囲で、それらの全体が参照により、全ての目的のために本明細書に組み込まれる。
【0211】
全ての見出しおよび小見出しは、本明細書では便宜上使用されているだけであり、決して本発明を限定するものとして解釈されるべきではない。
【0212】
本明細書で提示する任意のおよびいっさいの例または例示的な語句（例えば「など（ｓｕｃｈ ａｓ）」）の使用は、単に本発明をより明瞭にするという意図しかなく、特に明記しない限り、本発明の範囲を制限するものではない。本明細書中のいずれの語句も、特許の範囲にない任意の要素が本発明の実施に必須であることを示すと解釈すべきではない。
【0213】
本明細書の特許文書の引用および組み込みは、便宜上行われているだけであり、こうした特許文書の有効性、特許性および／または執行可能性のいっさいの観点を反映するものではない。
【0214】
本発明は、非一時的コンピュータ可読ストレージ媒体に埋め込まれたコンピュータプログラム機構を備えるコンピュータプログラム製品として実装されてもよい。例えば、コンピュータプログラム製品には、図１および図２の任意の組み合わせで示され、かつ／または図８に描かれるプログラムモジュールが含まれ得る。これらのプログラムモジュールは、ＣＤ－ＲＯＭ、ＤＶＤ、磁気ディスクストレージ製品、ＵＳＢキー、または任意の他の非一時的コンピュータ可読データもしくはプログラムストレージ製品に保存することができる。
【0215】
本発明の多くの修正および変形を、当業者に明らかであるように、その趣旨および範囲を逸脱することなく行うことができる。本明細書に記載される特定の実施形態は、例証としてのみ提供される。本発明およびその実用的用途の原理を最もよく説明するために実施形態を選択して説明したが、それにより、特定の用途に適した様々な修正を用いて、当業者が本発明および様々な実施形態を最良に利用できるようになる。本発明は、添付の特許請求の範囲の条件と、そのような請求の範囲が適用されるあらゆる等価物によってのみ限定される。
【図1A】
【図1B】
【図2A】
【図2B】
【図3】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9】