CN112567470A - 用于提供基于药物剂量指导的容器以治疗糖尿病的系统和方法 - Google Patents

Abstract

用于使用包括多个功能的多功能剂量指导算法向多个受试者提供药物剂量指导推荐的计算系统，其中该多个功能中的每个相应功能与对应的容器类别相关联。该系统适于执行以下步骤：（i）标识满足该药物剂量指导请求所需的多个功能请求，其中该多个功能请求中的功能请求能由该多个功能中的对应功能执行，（ii）针对该多个功能请求中的每个相应功能请求，使用编码器模块将该相应功能请求和相关输入数据嵌入与对应于该相应功能请求的功能相关联的容器类别的容器中，（iii）针对该多个功能请求中的每个相应功能请求，从执行该相应功能请求的容器中收集功能结果，从而获得多个功能结果，以及（iv）使用该多个功能结果提供药物剂量指导推荐。

Description

用于提供基于药物剂量指导的容器以治疗糖尿病的系统和 方法

本公开总体上涉及用于协助患者和医疗保健从业者管理药物剂量的系统和方法，其中基于特定于每个患者的信息来计算处方药物的剂量。

背景技术

糖尿病的特征在于胰岛素分泌和外周胰岛素抵抗的可变程度受损，从而导致高血糖症。2型糖尿病的特征在于正常生理胰岛素分泌的进行性破坏。在健康的个体中，胰腺β细胞的基础胰岛素分泌持续发生，以在两餐之间的延长期内维持稳定的葡萄糖水平。在健康个体中还存在餐时分泌，其中胰岛素响应进餐在最初的第一相峰值中快速释放，随后为在2-3小时后恢复至基础水平的延长胰岛素分泌。多年控制不良的高血糖症可能引起多种健康并发症。糖尿病是全世界过早发病和死亡的主要原因之一。

有效控制血糖/血浆葡萄糖可以预防或延缓这些并发症中的许多，但一旦确定，可能无法逆转。因此，在预防糖尿病并发症的努力中实现良好的血糖控制是治疗1型和2型糖尿病的主要目标。特别地，胰岛素剂量滴定的频繁变化是帮助稳定患者血糖水平的关键（Bergenstal等人, “Can a Tool that Automates Insulin Titration be a Key toDiabetes Management

” Diabetes Tech. and Thera. 2012, 14(8) 675-682）。已经开发了具有可调步长和生理参数估计值以及预定义的空腹血糖目标值的智能滴定仪，以施用胰岛素药剂治疗方案。长效基础胰岛素的最优初始化和滴定方法仍在确定中。然而，有证据表明，许多患者通常未接受足够滴定剂量的胰岛素以达到血糖控制的目标水平（仍处于次优剂量且未能达到治疗目标）（Holman等人, “10-year follow-up of intensive glucosecontrol in type 2 diabetes,” N. Engl. J. Med. 2008, 359: 1577–1589）。

胰岛素方案的主要问题之一是患者缺乏自主权和授权。患者通常必须去诊所计算新的滴定度。当诊所必须为患者滴定胰岛素剂量时，改变滴定剂量的可能频率受到自然限制。自我滴定方案有助于患者的授权，使他们更多地参与到他们的治疗中，这可以改善血糖控制（Khunti等人, “Self-titration of insulin in the management of people withtype 2 diabetes: a practical solution to improve management in primary care,”Diabetes, Obes., and Metabol. 2012, 15(8) 690-700）。在其糖尿病管理和其胰岛素滴定中发挥积极作用的患者可能会感到更有能力负责其自我护理，并且更坚信其行为可以影响其疾病，从而带来更好的治疗效果（Norris等人, “Self-management education foradults with type 2 diabetes: a meta-analysis on the effect of glycemiccontrol. Diabetes Care,” 2002, 25:1159–71, Kulzer等人, “Effects of self-management training in type 2 diabetes: a randomized, prospective trial,”Diabet. Med. 2007, 24:415–23, Anderson等人, “Patient empowerment: results ofa randomized controlled trial,” Diabetes Care. 1995, 18:943–9）。此外，当患者控制其自身的滴定时，滴定的频率会增加，这会增加患者达到所需血糖水平的可能性。

在该领域已投入大量工作来开发工具，以实现自主的、患者驱动的滴定。在滴定算法的开发中也取得了重大进展（Edelman等人, “AUTONOMY: The First Randomized TrialComparing Two Patient-Driven Approaches to Initiate and Titrate PrandialInsulin Lispro in Type 2 Diabetes,” 2014, 37(8): 2132-2140）。然而，许多滴定算法仍然主要由医疗保健提供者在临床就诊期间使用而不是由患者使用，因而限制了每个患者接收的滴定次数（Arnolds等人, “Common Standards of Basal Insulin Titration inT2DM,” J. Diabetes Sci. Technol. 2013, 7(3): 771-788）。所需要的是一种完全自主的药物剂量指导系统，患者在选择时或按照医疗保健提供者推荐的时间表可访问该系统，而不仅在他们预约医疗诊所时可访问该系统。

自主药物剂量指导系统的结构带来了许多困难，包括计算复杂性和提供成本。可以使用两个部分构建患者可按需获得的自主药物剂量指导系统：客户端移动应用程序和服务器端后端。后端服务器可以分为数据库和引擎，其中引擎是系统的大部分计算密集型功能所驻留的位置。服务器端后端系统通常部署在云环境中，以利用云计算的可扩缩性。由Amazon（AWS）、IBM（Bluemix）、Microsoft（Azure）等公司提供的云通常被称为“基础设施即服务”（IaaS）。随着越来越多的患者使用自主剂量指导系统，需要大部分计算资源的基于云的引擎将根据需要分配附加资源，以避免系统超时。取决于计算复杂性或查询量（例如，计算剂量指导推荐的难度或请求剂量指导的患者的数量），云计算可能会非常昂贵且耗时（Berriman等人, “The Application of Cloud Computing to Scientific Workflows: AStudy of Cost and Performance,” Phil. Trans. R. Soc. A 2013, 371: 20120066）。

现状将是使用单片架构开发引擎并将其部署在基于云的超管理器系统上（Lim等 人, “Automated Control in Cloud Computing: Challenges and Opportunities,”ACD’09, Barcelona, Spain. 2009）。这些单片应用程序部署在运行虚拟机（VM）的超管理器系统中。每当需求增加时（例如，越来越多的患者开始请求剂量指导），超管理器必须创建附加VM来满足需求。这会带来大量的计算开销，因为VM中的底层操作系统（OS）占用了VM存储所需的时间、存储器和磁盘空间。如果一个引擎子功能要求比其他子功能多的计算能力，则它可能会充当整个系统的资源瓶颈，并将迫使无关紧要地和可避免地奉献附加VM，以满足需求。需要一种不要求VM中的开销水平的解决方案，以使基于云的系统可用于计算患者药物滴定度。

因此，要解决的问题是当在IaaS云模型中给出药物剂量指导时，最大化引擎的效率及其对计算资源的使用。利用一种高效且具有成本效益的模型来计算胰岛素滴定剂量，更多的患者将可以按需获得自主药物剂量滴定度。在该背景技术部分中公开的信息仅用于增强对本发明的一般背景的理解，并且不应被视为对该信息构成本领域技术人员已知的现有技术的承认或任何形式的暗示。

在上述背景下，本发明的目的是提供用于提供改进的系统和方法的装置、系统和方法，所述改进的系统和方法用于与药物剂量指导有关的云计算环境内的计算密集型任务的分布式资源管理。

发明内容

在本发明的公开内容中，将描述多个实施方案和方面，它们将解决上述目标中的一个或多个，或者将解决从下面的公开内容以及从示例性实施方案的描述将显而易见的目标。

在本发明的第一方面，提供了一种用于使用包括多个功能的多功能剂量指导算法向多个受试者提供药物剂量指导推荐的计算系统，其中所述多个功能中的每个相应功能与对应的容器类别相关联，并且其中所述计算系统包括：一个或多个处理器；和存储器。所述存储器包括指令，所述指令在由所述一个或多个处理器执行时执行响应于从所述多个受试者中的受试者接收到药物剂量指导请求的方法。所述方法包括以下步骤：（i）标识满足所述药物剂量指导请求所需的多个功能请求，其中所述多个功能请求中的功能请求能由所述多个功能中的对应功能执行，（ii）针对所述多个功能请求中的每个相应功能请求，使用编码器模块将所述相应功能请求和相关输入数据嵌入与对应于所述相应功能请求的功能相关联的容器类别的容器中，（iii）针对所述多个功能请求中的每个相应功能请求，从执行所述相应功能请求的容器中收集功能结果，从而获得多个功能结果，以及（iv）使用所述多个功能结果提供药物剂量指导推荐。

通过这种布置，可以将后端引擎及其功能分解为分布式微服务架构内的容器。容器（操作系统级虚拟化）是一种轻量的虚拟化方法，仅提供应用程序按预期运行和起作用所需的最低限度。其通过容器化引擎的每个子功能，通过抽象化操作系统和物理基础设施，使其能够在不同的环境中可靠地运行。

在示例性实施方案中，所述多个功能包括第一功能和第二功能，所述第一功能能由第一容器类别的每个容器执行，所述第二功能能由第二容器类别的每个容器执行，并且所述第一功能的硬件资源要求不同于所述第二功能的硬件资源要求。

所述多个功能可以包括第一功能和第二功能，其中所述第一功能能由第一容器类别的每个容器执行，所述第二功能能由第二容器类别的每个容器执行，所述第一容器类别的每个容器由第一组服务器中的服务器托管，并且所述第二容器类别的每个容器由第二组服务器中的服务器托管而不是由所述第一组服务器中的服务器托管。

在示例性实施方案中，反复评估给定容器类别的容器的复合资源要求，并且当所述给定容器类别的容器的复合资源要求满足与所述给定容器类别相关联的资源分配阈值时，添加所述给定容器类别的一个或多个附加容器，并且容许所述给定容器类别的一个或多个附加容器接受来自所述编码器模块的与所述给定容器类别相匹配的功能请求。

相应地，当所述给定容器类别的容器的复合资源要求满足与所述给定容器类别相关联的第二资源分配阈值时，可以移除所述给定容器类别的一个或多个容器，并且不再容许所述给定容器类别的一个或多个容器接受来自所述编码器模块的功能请求。

在示例性实施方案中，与对应于给定功能请求的功能相关联的容器类别的给定容器评估所述相应功能请求是否包含所述功能提供功能结果所需的输入数据，并且当所述功能请求未能包含所需的输入数据时，与所述功能相关联的所述容器类别的给定容器不会提供功能结果。

所述计算系统可以操作为针对所述多个受试者中的每个受试者同时执行药物剂量指导请求。所述多个受试者包括至少10,000个受试者。

所述多个功能包括以下各项中的一项或多项：计算受试者的药物剂量指导推荐，重构受试者的胰岛素注射历史，计算受试者的滴定葡萄糖水平，重构受试者的血糖历史，以及得到受试者的剂量指导参数。

所述药物剂量指导请求可以是针对胰岛素药剂的剂量，以便达到治疗糖尿病病症的受试者的预确定血糖目标范围。

在示例性实施方案中，所述方法还包括以下步骤：执行所述剂量指导请求的质量检查，其中在以下情况下所述质量检查失败并导致不提供药物剂量指导推荐：（a）来自受试者的剂量指导请求包括低血糖事件的记录，或（b）来自受试者的剂量指导请求包括指示所述受试者未服用先前推荐的药物剂量的记录。

所述编码器模块（ii）还可以包括：针对资源要求评估每个相应功能。

针对受试者的至少两个功能可以被同时执行，和/或针对受试者的至少两个功能可以被循序执行。

在示例性实施方案中，所述功能请求所需的输入针对给定的受试者至少包括：所述受试者的上限目标葡萄糖范围，所述受试者的血糖历史，所述受试者的基础注射历史，以及最近的药物剂量指导推荐，以及可选的以下各项中的一项或多项：所述受试者的体重，所述受试者的下限目标葡萄糖范围，所述受试者的过度基础化极限（overbasalisationlimit），以及所述受试者的起始胰岛素基础剂量。

在第二方面，本公开通过提供用于药物剂量指导的系统和方法（特别是用于在两次就诊医疗保健从业者之间使用）来解决本领域中的上述需求。在本公开中，用于向多个受试者提供药物剂量指导推荐的计算系统使用包括多个功能的多功能剂量指导算法。所述多个功能中的每个相应功能与多个容器类别中的容器类别相关联。所述计算系统包括：一个或多个处理器；和存储器。所述存储器包括指令，所述指令在由所述一个或多个处理器执行时执行响应于从所述多个受试者中的受试者接收到药物剂量指导请求的方法。所述方法包括：（i）标识满足所述药物剂量指导请求所需的多个功能请求，其中所述多个功能请求中的功能请求能由所述多个功能中的对应功能执行，（ii）针对所述多个功能请求中的每个相应功能请求，使用编码器模块将所述相应功能请求嵌入与对应于所述相应功能请求的功能相关联的容器类别中的容器中，（iii）针对所述多个功能请求中的每个相应功能请求，从执行所述相应功能请求的所述容器类别中的容器中收集功能结果，从而获得多个功能结果，以及（iv）使用所述多个功能结果提供药物剂量指导推荐。

在一些实施方案中，所述多个功能包括第一功能和第二功能。所述第一功能能由所述多个容器类别中的第一容器类别的容器的每个实例执行。所述第二功能能由所述多个容器类别中的第二容器类别的容器的每个实例执行。所述第一功能的硬件资源要求不同于所述第二功能的硬件资源要求。

在本公开的一方面，所述系统针对所述多个受试者（例如，至少10.000个受试者）中的每个受试者同时执行药物剂量指导请求。针对受试者的所述第一功能和所述第二功能可以被同时或循序执行。

在本公开的另一方面，反复评估第一容器类别的容器的第一组实例的复合资源要求。当所述第一容器类别的容器的第一组实例的复合资源要求满足与所述第一组容器相关联的第一资源分配阈值时，将所述容器类别的容器的一个或多个附加实例添加到所述第一组容器，并且容许所述容器类别的容器的一个或多个附加实例接受来自所述编码器模块的与所述第一容器类别的类型相匹配的功能请求。

在一些实施方案中，当所述第一容器类别的第一组实例的复合资源要求满足与所述第一组容器相关联的第二资源分配阈值时，从所述第一组容器中移除所述第一组容器中的一个或多个容器，并且不再容许所述第一组容器中的一个或多个容器接受来自所述编码器模块的功能请求。

在一些实施方案中，所述多个功能包括第一功能和第二功能。所述第一功能能由所述多个容器类别中的第一容器类别的容器的每个实例执行。所述第二功能能由所述多个容器类别中的第二容器类别的容器的每个实例执行。所述第一容器类别的容器的每个实例由第一组服务器中的服务器托管。所述第二容器类别的容器的每个实例由第二组服务器中的服务器托管。

在所述计算系统的示例性实施方案中，所述多个功能包括第一功能和第二功能，所述第一功能能由所述多个容器类别中的第一容器类别的容器的每个实例执行，并且所述第二功能能由所述多个容器类别中的第二容器类别的容器的每个实例执行。所述第一容器类别的容器的每个实例由第一组服务器中的服务器托管，并且所述第二容器类别的容器的每个实例由第二组服务器中的服务器托管而不是由所述第一组服务器中的服务器托管。

所述第一功能可以包括以下各项中的一项：（i）计算受试者的药物剂量指导推荐，（ii）重构受试者的胰岛素注射历史，（iii）计算受试者的滴定葡萄糖水平，（iv）重构受试者的血糖历史，或者（v）得到受试者的剂量指导参数。

所述重构受试者的血糖历史还可以包括：当血糖历史时间进程包含间隙时，计算所述受试者的重构的血糖历史，并且其中基于所述受试者每个日历日的血糖历史来计算所述重构的血糖历史。

在所述计算系统的另一示例性实施方案中，与对应于相应功能请求的功能相关联的容器类别中的容器评估所述相应功能请求是否包含所述功能提供功能结果所需的输入，其中当所述功能请求未能包含所需的输入时，与所述功能相关联的所述容器类别中的容器不会提供功能结果。

针对给定的受试者，所述功能请求所需的输入至少包括：（i）所述受试者的体重，（ii）所述受试者的上限目标葡萄糖范围，（iii）所述受试者的下限目标葡萄糖范围，（iv）所述受试者的过度基础化极限，（v）所述受试者的血糖历史，（vi）所述受试者的最近的药物剂量指导推荐和/或起始胰岛素基础剂量，以及（vii ）所述受试者的基础注射历史。

用于确定所述药物剂量指导推荐的所述上限目标葡萄糖范围可以在以下范围内：80-180mg/dL、90-180 mg/dL、100-180mg/dL、90-200mg/dL、90-250mg/dL或90-300mg/dL。

用于确定所述药物剂量指导推荐的所述下限目标葡萄糖范围可以在以下范围内：50-70mg/dL、70-90 mg/dL、70-100mg/dL、60-100mg/dL或60-90mg/dL。

在所述计算系统的另一示例性实施方案中，所述药物剂量指导请求是针对胰岛素药剂的剂量，其中所述胰岛素药剂的剂量是为了达到治疗糖尿病病症的受试者的预确定血糖目标范围。所述病症可以是2型糖尿病，并且所述胰岛素药剂可以是LysB29（Nc-十六烷二酰基-y-Glu）des（B30）人胰岛素（德谷胰岛素，Tresiba®）。

所述预确定血糖目标范围为50-180mg/dL、60-180mg/dL、70-180mg/dL、80-180mg/dL、50-200mg/dL、60-200mg/dL、70-200mg/dL、80-200mg/dL、50-250mg/dL、60-250mg/dL、70-250mg/dL或80-250mg/dL。

在所述计算系统的又一示例性实施方案中，所述方法还包括：执行所述剂量指导请求的质量检查，其中所述质量检查失败，并且其中（a）所述受试者记录低血糖事件，或者（b）所述受试者未服用先前推荐的药物剂量，提供药物剂量指导推荐。

在所述计算系统的另一示例性实施方案中，所述编码器模块（ii）还包括针对资源要求评估每个相应功能。

附图说明

将参考附图描述本发明的以下实施方案，其中

图1A和图1B示出了提供剂量指导推荐的系统的第一实施方案的过程和特征的流程图，

图2A和图2B示出了如何基于CGM数据确定TGL值，

图3示出了根据本公开实施方案的用于自主提供药物剂量指导推荐的容器组织的示例系统，

图4A和图4B共同示出了根据本公开的实施方案的示例性系统拓扑，所述系统拓扑包括：用于收集患者数据（例如，来自对来自受试者的葡萄糖数据进行测量的一个或多个葡萄糖传感器的数据）的数据收集装置；药物剂量指导请求系统；以及一个或多个容器引擎，每个所述容器引擎包括协调器和一个或多个容器，其中上述部件可选地通过通信网络互连，

图5示出了根据本公开的实施方案的用于自主地提供药物剂量指导推荐的计算机系统。

图6提供了根据本公开的各种实施方案的用于自主地提供药物剂量指导推荐的装置的过程和特征的流程图，

图7示出了根据本公开的实施方案的针对受试者的药物剂量指导请求，

图8示出了根据本公开的实施方案的以下各项的示例集成系统：连接的一个或多个胰岛素笔、一个或多个连续葡萄糖监测器、存储器以及用于自主地提供药物剂量指导推荐的处理器，以及

图9示出了根据本公开的另一实施方案的用于自动地提供药物剂量指导推荐的容器组织的示例系统。

在附图中，类似的结构主要由类似的附图标记标识。

具体实施方式

糖尿病是日益增长的世界卫生流行病。尽管可以用已制定的滴定治疗方案和药物有效地控制糖尿病，但获得最新滴定推荐的途径仍然有限。本公开提供了一种以患者为中心的滴定算法，该算法将有助于胰岛素和其他药物的自动药物剂量调整和自滴定，从而通过在不降低治疗效果的情况下降低针对剂量调整的所需医生咨询的频率来增强患者授权以及显著降低治疗成本。本公开描述了一种系统，该系统根据来自患者的请求或自主地提供药物剂量指导推荐。本公开的一个方面是用于提供药物剂量推荐的集成系统基于云生态系统。

在描述本发明本身的实施方案之前，将描述在执行所存储的指令时如何接收和处理剂量指导请求（DGR）的具体示例。每个给定功能中嵌入的功能的数量，功能的顺序和特定功能性（例如规则）都是示例性的。在示例性实施方案中，所描述的规则对应于来自NovoNordisk A/S的Tresiba®的滴定标签推荐。

将在下面描述的系统设置被设计为实现为后端引擎，该后端引擎适于用作基于云的大规模糖尿病管理系统的一部分。这样的基于云的系统将允许引擎始终为最新的（与完全在例如患者的智能手机上运行的基于应用程序的系统相比），将允许实现诸如机器学习和人工智能之类的先进方法，并且将允许在更大的“数字健康”设置中将数据与其他服务结合使用。由于这样的基于云的系统理想地将处理大量患者对剂量推荐的请求，因此重要的是，该系统被设置为尽快提供预期服务并有效利用可用资源。

总体而言，提供了糖尿病管理系统，该系统可帮助患有2型糖尿病的人及其健康护理提供者（HCP）响应于血糖值和以前记载的剂量中记录的胰岛素量来滴定基础胰岛素。完整的系统包括后端引擎（“引擎”），这是本发明的主要方面，与客户端和操作系统形式的交互系统结合使用。

从引擎的角度来看，客户是请求剂量指导的软件部件。客户收集必要的数据（例如，CGM数据，注射数据，患者参数），并从引擎请求剂量指导。然后，客户端从引擎接收响应。在典型的设置中，客户端可以是专用数据集线器，以用作患者的医疗装置和云之间的接口，也可以是在患者智能手机上运行的应用程序。云操作系统为引擎提供运行所必要的最少资源（例如，存储器、处理）。云操作系统充当其中安装了引擎的环境，并允许对引擎进行部署。

在系统的以下实施方案中，将描述用于为要治疗糖尿病的受试者提供长效或超长效胰岛素调整日剂量推荐（ADDR）的系统，该系统适合于实现为基于云的大规模的糖尿病管理系统。

更具体地，提供了用于为要治疗糖尿病的受试者提供长效或超长效胰岛素调整日剂量推荐（ADDR）的系统。该系统包括一个或多个处理器和存储器，该存储器包括指令，该指令在由一个或多个处理器执行时响应于接收剂量指导请求（DGR）而执行方法。

该指令规定获得第一数据结构，该第一数据结构包括受试者的葡萄糖上限目标范围水平（UTR）和受试者的葡萄糖下限目标范围水平（LTR），并且获得了第二数据结构，该第二数据结构包括当前剂量指导基线（DGB），以及表示何时产生DGB的对应DGB时间戳。当前DGB可能对应于最近调整的日剂量推荐或起始基础剂量，即，由患者的医生通常设置的基础剂量。如上所述，这些数据结构分别表示滴定方案的起始点（起始剂量）和患者的BG水平的目标范围。

为了能够计算更新的ADDR，指令规定获得第一数据集和第二数据集。第一数据集包括在一定时间过程中获取的对受试者的多个葡萄糖测量，从而建立血糖历史（BGH），每个相应的葡萄糖测量包括血糖（BG）值，以及表示在时间过程中何时进行相应葡萄糖测量的对应葡萄糖时间戳（BGT）。BG值可以是独立的BG值的形式，通常是在早晨获取的每日测量，并且表示空腹BG。在这种情况下，每个BG值表示可以称为每日滴定葡萄糖水平值（TGL）的值，基于该值可以计算更新的ADDR。另选地，第一数据集可包括通过使用皮肤安装的连续葡萄糖监测（CGM）装置在每天内编译的大量BG值，例如每5分钟提供BG值。基于CGM数据，可以使用适当的算法来确定每日TGL，如将在下面更详细地描述。

第二数据集包括受试者的基础胰岛素注射历史（IH），该历史包括在时间过程的所有部分或一部分期间的多次注射，其中每次相应注射的特征在于注射量（IA），以及表示在时间过程中何时发生相应注射的注射时间戳（IT）。为了确保注射历史是最新的，可以获得包括注射历史刷新时间戳的第三数据结构。注射数据可能已经由患者手动捕获，或者可能已经使用设置有剂量记载电路的药物递送装置捕获。在后一种情况下，应当注意，记录排出剂量而不一定是注射剂量。实际上，这种不准确性也可能适用于手动导出的剂量日志。未注射的灌注/空气注射的问题将在下面讨论。

指令进一步规定对数据结构和数据集进行评估，从而确定剂量指导请求中必需的所有数据类型是否存在并且在指定范围内。这包括BG数据，注射数据，目标葡萄糖范围上限和下限以及最近的调整日剂量推荐或起始基础剂量。这是为了确保如果缺少某些东西，或者明显是错误的或不足的，则不会浪费资源来尝试处理请求。在请求缺少数据类型或具有比被认为正常的参数高一个数量级的参数的情况下，引擎将返回相应的错误消息。如果所有数据类型都存在且在范围内（此处未考虑质量和/或数量），则检查会将数据传递以进行进一步处理。

在计算ADDR之前，可以执行许多数据检查，例如，执行刷新检查以检查是否在给定时限内从注射历史刷新时间戳接收到剂量指导请求，以及执行更新检查以检查是否在给定时限内从DGB时间戳接收到剂量指导请求。

此外，可以执行一次或多次剂量事件检查以确定所述注射历史（IH）中的单独注射的次数、定时和大小是否符合一组预定的依从性要求。

已经描述了本发明的示例性实施方案的基本组成，将参考图1来描述具体实施方案，其中流程图示出了当执行所存储的指令时如何接收和处理剂量指导请求（DGR）。每个给定功能中嵌入的功能的数量，功能的顺序和特定功能性（例如规则）都是示例性的。在示例性实施方案中，所描述的规则对应于来自Novo Nordisk A/S的Tresiba®的滴定标签推荐。

1.1 有效请求检查

该功能在上文有所描述，并检查剂量指导请求中必需的所有数据类型（即，客户端输入数据）是否存在并且在指定范围内。在请求缺少适当的数据的情况下，该功能将返回错误消息。否则，检查将传递数据。

对于给定的设置，可能需要附加输入数据来请求通过检查，例如“低血糖历史”，包括任何报告的低血糖事件，该低血糖事件具有时间戳、给定时间段内的最大基础极限（例如，每天或每周，请求时间（TOR））、单独剂量指导请求的唯一标识符以及客户端的唯一标识符。

1.2 最后注射数据刷新检查

该功能检查注射历史数据是否已在预定的时限内刷新，例如在最后30秒内，这是为了确保它具有注射历史数据的最新记录。

1.3 注射历史检查

该功能检查在过去8个小时内是否已经有剂量事件。如果是这样，推荐再次注射会违反Tresiba®标签（即，每天至少间隔8小时注射一次），并会使用户有发生低血糖事件的风险。如果在前8小时内没有剂量事件，则检查将会将数据传递到下一个功能。

1.4 补偿注射检查

Tresiba®标签规定用户应每天注射一次，并且间隔至少8小时。但是在患者忘记摄取每日剂量的情况下，除了定期安排的剂量（间隔至少8小时）之外，第二天还可以摄取被遗忘的剂量。相应地，该功能首先检查日历日内是否已经有剂量事件。如果有，则它会检查以查看前一个日历日是否没有剂量事件，并且如果是，则它将通过检查。如果从前一个日历日记录了剂量事件，则检查将返回错误消息，并且不给出剂量推荐。

1.5 记录的低血糖事件检查

该功能检查与请求一起接收的数据结构是否包括一个或多个记录的低血糖事件的指示符。如果在预设的时限内记录了一个或多个低血糖事件，则不会计算新的ADDR，但将用2UI的胰岛素将当前的DGB调低。低血糖事件可由患者手动记录和/或可在将CGM用于BG数据捕获时可以自动登记。在后一种情况下，可能会要求患者确认事件。

1.6 BG数据质量检查

在基于单独的BG测量提供BG数据（例如，空腹BG）的情况下，该功能将检查在指定数量的最近几天中的指定天数内是否记录有效BG值（例如，最后4天内至少有3个有效BG值）。在基于CGM测量提供了BG数据的情况下，可以执行CGM数据质量检查以确保数据中没有不可接受的间隙，这些间隙可能导致错误的滴定葡萄糖水平确定。下面描述CGM数据质量的不可接受水平的示例性标准。在数据质量不能够满足最小阈值的情况下，该此功能将返回错误消息，并且剂量指导请求将不会继续进行。另选地，有可能填充CGM数据内的间隙。这是为了增加尽管数据中存在间隙（例如，新传感器正在准备中），但剂量指导请求仍将通过下一次CGM数据质量检查的概率。合适的数学方法的示例将在下面更详细地描述。

1.7 剂量事件识别

在具有集成的剂量记载功能的笔装置（诸如NovoPen® 6）中，根据其使用说明，患者应该对该装置进行灌注直到他们看到胰岛素喷出。这些灌注“注射”（或“空气注射”）与笔的实际身体注射没有区别，并且将从引擎的角度看作摄入体内的单独注射。由于患者进行的实际注射次数是可以由剂量指导系统检查以确定患者是否依从滴定方案的参数之一，因此能够过滤出此类“灌注”注射是重要的。这种过滤可以在患者的智能手机应用程序中的剂量记载电路中进行（无论是集成在NovoPen® 6中集成还是作为安装在笔装置上的附加的记载装置来提供），该应用程序通常是适合于接收的装置并收集注射数据和BG数据，然后再将其作为对ADDR的请求的一部分或在云引擎中进行传输。过滤通常将基于剂量大小（灌注剂量通常比注射剂量小（更多））以及注射之间的时间。执行该分析的多个算法是已知的，例如，如US 2019/0035500中所公开的。过滤可以在不止一个的级别上实现，因为随后的过滤将只是什么也不过滤。相同的注意事项适用于“分次剂量”，即患者（通常）将其分为两次单独注射的大剂量，其应当组合为“剂量事件”，参见下文，以便不计数为两个单独剂量，这将危害基于剂量事件数量的滴定方案。

1.8 剂量事件检查

该功能是检查以查看患者是否已充分依从他/她的注射方案。自最近的ADDR以来，它至少查找3个剂量事件，并且它们已经在今天和直到前4个日历日窗口内发生。正在检查的这个额外日历日允许没有剂量的一天（例如，他/她忘记了），随后除了正常计划的剂量外，第二天也要摄取。如果在此时间范围内少于3个剂量事件（因为患者忘记了多天），则此检查将失败，这将导致重新推荐最近进行的ADDR。此外，在重复请求ADDR而没有进行任何注射的情况下，这将确保仅分配单个ADDR并且仅遵循重新推荐。

1.9 DGB检查

该功能检查以查看何时进行了最近的ADDR，或何时设置了起始基础剂量（SBD）值。如果最近的ADDR是在当前和之前的7个日历日内进行的，则检查通过。如果最近的ADDR早于此，则必须输入新的SBD量，并且必须从该新的点重新开始剂量指导请求过程。然后，新的SBD将被视为当前DGB。

1.10 依从性检查

该功能检查数据集中三个最近剂量事件的注射量，以确保它们各自至少等于或大于最近ADDR的量。如果任何剂量事件小于该量，则检查将失败，并将从最近的ADDR中重新推荐量。这确保了引擎不会因剂量不足导致的葡萄糖水平升高而增加滴定。

1.11 过多剂量检查

该功能检查在最后48小时内是否有超过两个剂量事件，这与违反Tresiba®标签的推荐。如果在过去48小时内记录了多于两次的剂量事件，则可能会生成错误消息。

1.12 每日TGL确定

在基于单独的BG测量提供了BG数据（例如，空腹BG）的情况下，该功能将检查在指定的时间范围内是否记录了有效BG值。在基于CGM测量提供了BG数据的情况下，该功能会查看CGM数据集，并在可能的情况下确定自最近ADDR以来或直到最大天数（例如，从TOR起的4天）的每天的TGL，这是剂量指导周期。“天”可以是日历日（在这种情况下，某些天可能是不负的），也可以是从例如TOR计算的24小时周期，参见下文。这通过以下方式来完成：在CGM读数上应用例如3小时“滑动窗口”，此时为一个数据点，参见图2A和图2B，计算从当前时间直到最后剂量调整时间的每个3小时间隔的平均值。在示例性实施方案中，仅针对已经通过如下所述的BGH数据质量测试的几天确定每日TGL。每天的最低3小时平均值将记录为TGL值，并用于滴定。

1.13 每日TGL检查

该检查查找低于目标葡萄糖范围参数下限的任何每日TGL。如果是，则下一个ADDR比给定的最近ADDR减少2IU。如果不是，则检查传递到下一个功能。

1.14 平均TGL确定

如果在剂量指导周期（例如最后4天）内已经确定了至少最小数量的有效每日TGL值，例如2，则计算至少2个TGL值的平均值。

1.15 滴定确定

该功能利用总TGL平均值，如果其在目标范围内，则滴定确定将为从最近ADDR +0IU。如果TGL平均值高于目标范围的上限，则下一个ADDR从最近的ADDR增加2IU。如果TGL平均值低于目标范围的上限，则下一个ADDR从最近的ADDR下降2IU。

1.16 最大极限检查

为了防止剂量过量，该功能检查在给定时间段内的给定剂量最大值没有超过，例如在最后一周内Tresiba®的最大值为300IU。患者特定值也可以包括在请求数据中。另选地，该功能可以检查下一个ADDR是否会超过患者的“过度基础化”极限（BW（kg）* OBL（IU/kg））。这将要求提供受试者的体重（BW）和受试者的过度基础化极限（OBL）作为随请求接收的数据的一部分。

1.17 输出

引擎对剂量指导请求的作为答复的主要输出确实是客户端接收到的ADDR，然而，附加信息可能对患者有用，直接与患者的治疗相关，例如引擎基于CGM值以及特定的错误或警告消息而计算出的TGL值，或者验证数据以提高可靠性和安全性。相应地，输出可以包括以下类型的数据中的一种或多种：用户ID、事务ID、ADDR、每日TGL、总TGL、剂量事件历史、低血糖记录、警告和错误代码。

参考上面的“1.6 BG数据质量检查”，下面将描述用于CGM数据质量的不可接受水平的示例性标准。

通常，对于希望使用CGM装置为T2DM患者提供胰岛素剂量指导的决策支持系统，上述系统是后端剂量指导引擎，其吸收胰岛素、葡萄糖和患者数据以分析并推荐现在要摄取多少基础胰岛素，使得患者可以生活得更正常。

吸收的葡萄糖数据可以来自连续的葡萄糖监测器。当前CGM（诸如Dexcom G5）每5分钟连续报告数据，并且引擎的任务是从该连续数据流中确定滴定葡萄糖水平（TGL），以最终做出剂量推荐。不幸的是，当今的CGM没有用以存储数据的存储器，并且接收装置（例如，在患者的智能电话上的移动应用程序）没有接收到的任何数据都丢失了。这在处理这些间隙的同时安全地确定TGL方面产生了挑战，这些间隙可能在实际使用中出现。表1描述了用于安全处理CGM数据中的间隙的通过/不通过标准的第一示例。

表1：基于丢失的CGM数据的动作的概述

。

在下文中，将描述BGH数据质量测试的另外示例。

剂量指导周期（DG_PERIOD）可以定义为从请求时间开始的时间到DGB时间戳的时间段，直到例如-96:00小时的最大值。DG_PERIOD中的BGH数据分为以下可能的增量：BGH_PERIOD_1：0至-24:00小时，BGH_PERIOD_2：-24:00至-48:00小时，BGH_PERIOD_3：-48:00至DGB时间/-72:00小时，以及BGH_PERIOD_4：-72:00小时至DGB时间/-96:00小时。

为了进行数据质量测试，每个BGH_PERIOD被分为不重叠的6小时间隔。检查每个间隔中是否存在至少1个VALID_TGL，其被定义为存在>50%的BGH数据点的时间窗口。窗口可以是例如3小时。如果任何6小时间隔都没有至少1个VALID_TGL，则整个BGH_PERIOD均未通过数据质量测试，即每个BGH_PERIOD均经过单独测试，并且将具有自身的通过/失败确定。关于CGM数据质量测试的另外细节在WO 2018/228932中公开，该文献据此以引用方式并入。

如上所述，可能有必要组合剂量以产生“剂量事件”。在示例性实施方案中，落入运行DE_WINDOW（例如，60分钟）内的IH中的所有注射聚集成从当前时间开始的DOSE_EVENT量。仅将DG_PERIOD内的注射聚集成DOSE_EVENT。DOSE_EVENT时间戳是例如DE_WINDOW中最近注射的时间戳。如出现的那样，在将IH作为DGR的一部分提交之前未将灌注和空气注射排出事件从IH滤出的情况下，则将这些非注射剂量计算为注射剂量的一部分。另选地，引擎可设置有其所有者过滤器功能，例如，对连接笔进行基于规则的流检查检测，如EP申请18198410.5中所述。

为了确保所公开的引擎不仅安全，而且可以有效地治疗患者以达到目标，可以应用额外的数据处理步骤来填充CGM数据中的某些间隙，其中先前不能确定TGL并且系统不能确定剂量指导推荐。通过使用数据间隙填充方法，引擎可能能够在数据可能具有间隙的更现实的“真实世界”环境中计算基础剂量指导，而系统仍然可以安全有效地分配基础胰岛素剂量指导。

更具体地讲，在下文中，该方法的主要思想是定义葡萄糖曲线的最低拟稳定状态，并相对于它们填充数据间隙。提出的模型考虑了患者的大致趋势和典型行为。

该模型是基于来自临床试验的患者的CGM数据开发的，在研究开始时使用仅基础治疗的CGM数据为2周。数据分析表明，至少30%的患者在CGM数据中存在相当大的间隙。这些间隙是白天和晚上的不同时间。根据该项目的风险分析，存在以下风险：这些间隙可能严重影响算法剂量决定，因为间隙可能在空腹周期期间出现，因此防止滴定算法能够正确地识别TGL并给出错误的推荐。任务是执行分析并确保提出的方法对于CGM噪声是不可知的，并且不会导致降血糖事件。

CGM数据间隙填充处理步骤由若干步骤组成。首先，它检查CGM流中有多少可用数据。要求是在标识TGL和针对滴定所需的最后X天之内拥有至少30％的数据（例如，针对示例性算法实施方式，X=3）。其次，它需要识别CGM数据中的间隙并将它们存储在间隙阵列中。可以再填充1至72个丢失点（1个丢失点=2个间隔=10分钟间隙）。即使72个丢失点间隙看起来很大，间隙填充算法仍能够正确地重构CGM数据。

数据分析表明，第90百分位和第75百分位上的所有相邻点之间的绝对值差值对于具有高血糖变异性的用户将是大约10mg/dl和6mg/dl，而对于具有低血糖变异性的用户仅是5mg/dl和3mg/dl。

接下来的逻辑步骤是找到7分钟至360分钟之间的所有间隙。重构过程单独处理每一个间隙。算法如下：

· 取间隙之前的最一点和间隙之后的第一点

· 查找特定用户在第75百分位上的典型CGM变化率（ROC），

· 计算最后点与第一点的差值的最大值，作为最后（第一）点值减去ROC乘以丢失点的数目（相应地表示为×3和×4）之间的差值，

· 找到两条线之间的交点并存储时间t_i的值，

有时，如果差值|×1 – ×2|大于ROC乘以丢失点的数目，则相交点将在时间间隔（t1、t2）之外。必须用90%百分位ROC重复算法例程的上述部分。如果算法不能在时间间隔（t1、t2）内以90%百分位ROC达到相交点，则其将点与直线连接。对此的数学描述如下，当间隙的时间较小并且人正在从高升糖指数餐食上升时，最坏的情况将是直线（V形线的退化情况）。

此外，数据分析表明，真正的空腹周期值与一些合理数量的点形成谷。

机器学习聚类方法k平均值允许找到点的聚类。使用具有聚类质心的随机初始化的标准k平均值算法。需要准备CGM数据以查找聚类。过滤CGM数据的最简单方法是忽略大于流的第30百分位的所有数据。这种方法的优点是，基于输入数据的截止线被移位，同时仍存在足够的数据点以找到聚类。

定义聚类质心是非常强大的工具，并且所谓找到最小聚类质心值，可以说是聚类的点趋向于更低和更靠近在一起。最后步骤是定义最低聚类的最小值，并存储该值x_c。

在定义聚类质心后，可以用V形曲线重新填充间隙，其中V的头部由点[t_i、x_c]定义。由于患者的身体不能被完全再现，因此所有的非线性都可以用线近似。

当给定的BG数据集通过BG数据质量检查后，将执行每日TGL确定。在下面，将描述用于此目的的两个概念。与上述示例性实施方案相反，使用了60分钟的滑动窗口。

方法1：

通过选择60分钟葡萄糖水平的最低平均值（即，24小时周期期间，5分钟间隔的13次连续测量中最低为288）来检测TGL。这种方法计算5分钟间隔的13次连续测量的移动平均值（MA），

其中

是葡萄糖测量，并且下标

是当前样本。

00:00和23:59之间的24小时期间的最小值被确定为TGL。假设该方法使b)具有不规则日常例程的人（轮班工人等）和c)其日常例程偏离常规（例如，不吃早餐）的人缓解。

方法2：

通过识别时间间隔04.00至10.00（假定为代表早餐）中的第一条陡曲线来检测TGL，然后将TGL确定为-90分钟至-60分钟之间的平均葡萄糖水平。该方法计算后向差值，如Dassau等人所述。[XX]对于使用CGM数据的餐食检测：

其中

是葡萄糖测量，

是时间，

是两个样本间隔之间的时间差，并且下标

、

和

是当前样本和前两个样本，dG/dt是对于预定义时间周期内的所有点计算的。进餐的开始被定义为dG/dt最大的地方。然后，将TGL计算为-90分钟至-60分钟时间间隔内的测量平均值。假设该方法对具有a)规则和可预测的生活方式的人而言更为稳健，但在存在生活方式不规律时则不太稳健。

两种方法通过创建多个场景来相互挑战（例如，对于具有“典型”和可预测的生活方式的人，具有“不规则的”日常例程的人，胰岛素敏感度变化和CGM传感器偏差），并且对于每个场景基于虚拟患者模型生成CGM数据集。

然后基于来自模拟器的连续葡萄糖输出来计算结果量度。结果量度用于评估生理模型与临床试验结果相比的性能，并且比较治疗决策算法的安全性和性能。

结果量度1：严重降血糖事件的频率

结果量度2：太高或太低的剂量推荐的严重程度

结果量度3：范围内的时间

对这两种方法进行排列时，方法1在所有模拟测试中最佳地执行。相应地，方法1被评估为检测和确定TGL的可行方式，并且被评估为执行基于CGM的基础胰岛素滴定的安全方法。

方法1的实际应用是在对胰岛素剂量请求的请求之前使用3个24小时周期。即，剂量推荐时间=剂量时间=t0。在1) t-24h至t0、2) t-48h至t-24h和3) t-72h至t-48h期间找到3个移动平均值。TGL周期之间必须存在时间差，例如在TGL周期期间为至少8小时。这是为了避免在两个24小时周期中使用相同TGL周期的情况。

接下来，从CGM评估需要什么数据质量，以便安全可靠地执行基础胰岛素剂量推荐。以下假设适用：

· 适应症：T2DM患者的基础胰岛素滴定

· 滴定算法：“简单”2-0-2算法

· TGL的检测和确定方法：方法1，参见上文

· 试验中使用的基础胰岛素为德谷胰岛素，其具有非常平坦的动作曲线，其中t_max为9小时的中值，并且t_½为大约25小时。

原则上，考虑到这些假设，将保守滴定算法与保守方法结合来检测和确定TGL本质上应提供安全的自动基础胰岛素滴定。然而，在下面，将评估具有丢失部分的CGM数据的使用。

使用来自已发表的标题为：“Efficacy and safety of Fiasp® compared toinsulin aspart in combination with insulin glargine and metformin in adultswith type 2 diabetes (Onset® 2)”的临床试验NN1218-3853的现有临床GCM数据对具有丢失部分的GCM数据和优化的CGM数据质量的建议使用进行评估。该试验的CGM数据适用，因为：

· 试验仅包括2型糖尿病患者

· 试验具有8周的磨合期，其中基础胰岛素被滴定

· 在8周磨合期结束时，在14天期间有67位受试者的CGM数据

· 所使用的CGM装置是Dexcom G4

在具有饮食、运动、睡眠和胰岛素注射的典型时间表的日常生活中，糖尿病患者中的BG的最大频率（也称为带边缘频率）为0.9 10^–3 Hz（K.-D. K. B. T. Gough DA,“Frequency characterization of blood glucose dynamics. Ann Biomed Eng. 2003,31: 91–97”）。因此，固有BG动态不快于大约18分钟（频带边缘频率的倒数）。因此，短于连续数据大约20分钟的丢失数据间隙不会影响剂量推荐的安全性。

基于这些考虑，可以提出基于丢失CGM数据的动作的规则集，如上表1所列出的。

在917个单独的CGM数据集NN 1218-3853中，134个属于前2天，其中不存在连续3天的CGM数据，并且因此不能推荐任何动作。不包含CGM值的16个数据组不包括在下表中。在其余的767个数据集中，推荐在表2中提出，并且应表示在连续的基础上可以预期的内容。

表2：基于NN1218-3853 CGM数据的建议动作的分类

。

总体而言，在76%的时间中，引擎将基于CGM数据的3个24小时周期提供剂量推荐，在19%的时间中，应用程序将基于CGM数据的2个24小时周期提供剂量推荐，并且仅在4%的时间中，应用程序将基于丢失CGM数据的量而省略提供剂量推荐。

已经描述了当执行存储的指令时如何接收和处理剂量指导请求的具体示例，下面将解决关于药物剂量指导在云计算环境中提供用于计算密集型任务的分布式资源管理的改进的系统和方法的问题。

所提出的解决方案是在分布式微服务架构中将后端引擎及其功能分解为多个容器。容器，或称为操作系统级虚拟化，是一种虚拟化的轻量方法，其仅提供应用程序按预期运行和起作用所需的最低限度。从某种意义上说，它们可以被视为不在超管理器上运行的超级极简虚拟机。通过容器化引擎的每个子功能，其通过抽象化操作系统和物理基础设施，使其能够在不同的环境中可靠地运行。容器的大小通常以数十兆字节来衡量（而虚拟机为数GB），并且仅花1-2秒就可以提供一个以满足附加需求。当负载增加时，可以根据需要创建新的虚拟化，而当负载下降时，可以销毁容器。网络中应包括协调器，以确定要执行的嵌入在容器中的功能，然后再使任意附加计算资源专用于它，以便满足剂量指导系统的需求并避免系统超时。

该模型确保了将计算资源专用于单个功能级别，而不是整个引擎，从而确保最高效地利用资源，同时将计算浪费和最终超额成本降至最低。

如图2所示，示出的引擎由具有嵌入式功能的容器组成，这些容器在协调器调用时根据微服务架构经由API（应用程序编程接口）彼此通信。引擎功能根据计算强度水平及其在不同剂量指导系统上的可重用性水平被分为多个容器。例如，“2. 计算功能”要求的计算资源非常少，因为它由非常简单的数学函数（例如，仅几个数字的加/减）组成，相反，“5. 数据重构”一次可能需要数千个数据点，以便进行回归分析和内插，从而重构数据集。取决于“1. 协调器”来标识需要哪个功能以及何时、哪个功能可以根据需要触发任何附加计算资源。通过这种方法，可以在“3. 依从性”之前或与其并行地安排“5.数据重构”，因为它们可以彼此独立地被执行，并且“5.数据重构”可以具有其专用的附加资源，从而确保对客户端的响应不会超时。

如图2所示，已经为第一引擎提供了第一协调器“CGMBoT202”，该第一协调器具有在4个对应的容器类别中的4个关联的容器。该设置允许附加协调器，例如针对要实现的引擎“SMBGBot202”，该引擎可以重用已经实现的功能，或者可能需要在对应的容器类别中实现新的功能。实际上，针对将来的功能类型可能需要新的容器类别。

PRIO图4A示出了集成系统48的示例，该集成系统依赖于系统602（各种“计算机系统602”、“药物剂量指导计算系统602”或“药物剂量指导系统602”）来确定针对受试者的药物剂量指导推荐。图9提供了系统602的更多细节，其示出了药物剂量指导请求的处理。计算机系统602包括容器引擎70、协调器230和一个或多个容器74。容器是用户空间实例。从在其上运行的功能的角度来看，此类用户空间实例看起来像真实的计算机。在普通操作系统上运行的计算机程序可以查看该计算机的所有资源（连接的装置、文件和文件夹、网络共享、CPU能力、可量化的硬件功能）。然而，在容器内运行的程序（例如，公开的功能）只能看到容器的内容物和分配给该容器的装置。容器的示例包括但不限于chroot、Docker、Linux-VServer、lmctfy、LXC、Singularity、OpenVZ、Vituozzo、Solaris Containers、FreeBSDjail、sysjail、WPARs、iCore Virtual Accounts、Sandboxie、Systemd-nspawn和Turbo。参 见, Hogg, “Software Containers: Used More Frequently than Most Realize,”Network World, 2016年5月26日，其通过引用并入本文。

图4B示出了系统48的特定实例，其中受试者用户装置（例如110-1）由葡萄糖传感器102和胰岛素笔104组成。集成系统502包括：一个或多个连接的胰岛素笔104；一个或多个葡萄糖监测器102；存储器506；以及处理器（未示出），用于对受试者的自主葡萄糖数据执行算法分类并请求药物剂量指导推荐。在一些实施方案中，葡萄糖监测器102是连续葡萄糖监测器。

现在将详细参考实施方案，其实例在附图中示出。在实施方式的以下详细描述中，阐述了许多具体细节以便提供对本发明的透彻的理解。然而，对于本领域的普通技术人员将显而易见的是，可以在没有这些具体细节的情况下实践本发明。

定义

在本公开中使用的术语仅出于描述特定实施方案的目的，而并非旨在限制本发明。如在本发明的描述和所附权利要求书中所用，单数形式的“一”、“一个”和“该”也旨在包括复数形式，除非上下文另外明确指出。还应理解，如本文所用，术语“和/或”是指并涵盖相关联的列出项目中的一个或多个项目的任何和全部可能的组合。将进一步理解的是，术语“包括”和/或“包含”当在本说明书中使用时指定所陈述的特征、整数、步骤、操作、元件和/或部件的存在，但是不排除存在或者添加一个或多个其他特征、整数、步骤、操作、元件、部件和/或它们的组。

还应理解，尽管术语第一、第二等可以在本文中用于描述各种元件，但是这些元件不应受到这些术语的限制。这些术语仅用于区分一个元件和另一个元件。例如，在不脱离本公开的范围的情况下，第一滤波器可以被称为第二滤波器，并且类似地，第二滤波器可以被称为第一滤波器。第一过滤器和第二过滤器都是过滤器，但是它们不是同一过滤器。

如本文所用，术语“如果”可以被解释为意指“当……时”或“在……后”或“响应于确定”或“响应于检测”，这取决于上下文。类似地，短语“如果确定”或“如果检测到[陈述的条件或事件]”可以被解释为意指“在确定后”或“响应于确定”或“在检测到[陈述的条件或事件]后”或“响应于检测到[陈述的条件或事件]”，这取决于上下文。

术语“或”旨在表示包含性的“或”而不是排他性“或”。也就是说，除非另有说明或从上下文中清楚得知，否则短语“X采用A或B”旨在表示任何自然的包含性排列。也就是说，以下任何一种实例都满足短语“X采用A或B”：X采用A、X采用B、或者X采用A和B两者。此外，除非另有说明或从针对单数形式的上下文中清楚得知，否则本申请和所附权利要求书中所使用的冠词“一”和“一个”通常应解释为表示“一个或多个”。

术语“受试者”、“个体”和“用户”在本文中可互换使用，并且是指人类。优选地，个体是成年个体。

如本文所使用的，术语“药剂”是指用于受试者的医学治疗的化学物质。术语“药剂”、“药物”和“药品”在本文中可互换使用。所述药剂可以由医师或其他医疗保健提供者开处方。另选地，所述药剂可以是非处方药品或产品。在本公开的具体示例中，所述药剂是胰岛素，其用于治疗糖尿病。

术语“多尿症”或“糖尿病”包括1型糖尿病、2型糖尿病、妊娠糖尿病（妊娠期间）和引起高血糖症的其他状态。该术语用于其中胰腺产生不足量的胰岛素，或其中人体的细胞对胰岛素没有适当反应从而阻止细胞吸收葡萄糖的代谢紊乱。结果，葡萄糖在血液中积聚，需要治疗以控制血糖水平。

根据本发明，胰岛素包括长效胰岛素和超长效胰岛素或由其组成。原则上，胰岛素的半衰期越长，葡萄糖降低效果在给药间隔（即，注射之间的时间间隔）内越稳定和均匀地分布。根据本发明，以在所述受试者中实现有益的血糖控制的量施用胰岛素。根据本发明，所述受试者中的有益血糖控制至少由施用所述基础胰岛素后所述受试者中的HbA_1c（糖基化血红蛋白）的水平确定。通过使用根据本发明的基础胰岛素及其施用，可以实现达到HbA_1c目标的需要其的患者比例的改善。

术语胰岛素笔是指适合于施加离散剂量的胰岛素制剂的注射装置，并且其中所述注射装置还适于记录和传送与剂量有关的数据。

如本文中所使用的，术语“部件”和“系统”及其各种形式（例如，部件、系统、子系统等）旨在指代与计算机有关的实体、或硬件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于在处理器上运行的进程、处理器、对象、实例、可执行文件、执行线程、程序和/或计算机。通过例示，在计算机上运行的应用程序和计算机都可以是部件。一个或多个部件可以分布在可扩展的基于云的服务中。一个或多个部件可以驻留在执行的进程和/或线程中，并且部件可以本地化于一台计算机上和/或分布在两个或更多个计算机之间。

描述

结合图1和图2描述了根据本公开的用于根据受试者的处方药品方案自主地计算药剂剂量的系统48的详细描述。因此，图1和图2共同示出了根据本公开的系统的拓扑。在所述拓扑中具有：用于根据受试者的处方药品方案自主地调整药剂剂量的药物剂量指导系统（“药物剂量指导计算机系统602”）（图1和图2）；用于从受试者收集信息的装置（“受试者用户装置110”）；以及用于在药物剂量指导计算机系统602和受试者用户装置110之间传输信息的装置（“数据传输装置150”）。

参考图4A，计算机系统602自主地为受试者提供经调整的药剂剂量。计算机系统602或其部分可以包括从服务（例如，在云中）获得的信息，或者可以基本上在云计算环境中操作。如例如在转让给Microsoft Technology Licensing LLC的标题为“ApplicationService Architecture”的美国专利申请2017/0063833中所描述的（其通过引用并入本文），云计算环境提供了用于驻留在网络中的多个装置上的信息。

在一些实施方案中，所述药剂是由医疗保健提供者开处方的药品。在一些实施方案中，所述药剂是非处方药品。为了计算药剂剂量指导推荐，与计算机系统602进行电通信（通过数据传输装置150，通过通信网络106，或直接地）的受试者用户装置110接收与受试者的药剂使用情况有关的自主受试者具体信息。例如，在一些实施方案中，数据传输装置150通过射频信号无线地接收该数据。在一些实施方案中，此类信号符合802.11 (WiFi)、蓝牙或ZigBee标准。在一些实施方案中，数据传输装置150直接接收这样的数据，并将所述数据传输到计算机系统602，然后该计算机系统分析所述数据并提供药物剂量指导推荐（直接提供给受试者用户装置110或通过数据传输装置150提供）。在一些实施方案中，受试者用户装置110包括RFID标签，并且使用RFID通信与数据传输装置150和/或药物剂量指导计算机系统602通信。在一些实施方案中，数据传输装置150和/或计算机系统602还获得或接收受试者的生理测量值（例如，从可穿戴的生理测量装置，从数据传输装置150内的测量装置（诸如磁力计或恒温器），等等）。

在一些实施方案中，数据传输装置150和/或计算机系统602不靠近受试者和/或不具有无线能力，或者这样的无线能力不用于获取葡萄糖数据、胰岛素药剂注射数据和/或生理测量数据。在这样的实施方案中，通信网络106可以用于将受试者信息从受试者用户装置110传送到数据传输装置150和/或药物剂量指导计算机系统602，和/或将生理测量数据从一个或多个生理测量装置（未示出）传送到数据传输装置150和/或药物剂量指导计算机系统602。

参考图4B，在一些实施方案中，受试者用户装置110由葡萄糖传感器102和/或胰岛素笔104组成。在一些实施方案中，药物剂量指导计算机系统602和/或数据传输装置150持续接收源自附接到受试者的一个或多个葡萄糖传感器102的葡萄糖测量值和胰岛素滴定请求。在一些实施方案中，数据传输装置150还从受试者注射胰岛素药剂所使用的一个或多个胰岛素笔104接收胰岛素药剂注射数据。在一些实施方案中，数据传输装置150直接从受试者使用的葡萄糖传感器102和胰岛素笔104接收这样的数据。在一些实施方案中，葡萄糖传感器102和/或胰岛素笔104包括RFID标签，并且使用RFID通信与数据传输装置150和/或计算机系统602通信。对于本发明的一些实施方案，受试者用户装置110是胰岛素笔装置。在一些实施方案中，胰岛素笔装置是一个或多个FlexPen^®或者一个或多个FlexTouch^®。FlexPen^®和/或FlexTouch^®是Novo Nordisk A/S的商标。

在一些实施方案中，如图4B所示，数据传输装置150和/或药物剂量指导计算机系统602不靠近受试者和/或不具有无线能力，或者这样的无线能力不用于获取葡萄糖数据、胰岛素药剂注射数据和/或生理测量数据。在这样的实施方案中，通信网络106可以用于将葡萄糖测量值从葡萄糖传感器102传送到数据传输装置150和/或药物剂量指导计算机系统602，将胰岛素药剂注射数据从所述一个或多个胰岛素笔104传送到数据传输装置150和/或药物剂量指导计算机系统602，和/或将生理测量数据从一个或多个生理测量装置（未示出）传送到数据传输装置150和/或计算机系统602。

网络106的示例（如图4A和图4B所示）包括但不限于万维网（WWW）、内联网和/或无线网络（诸如蜂窝电话网络、无线局域网（LAN）和/或城域网（MAN）、以及通过无线通信的其他装置）。无线通信任选地使用多种通信标准、协议和技术中的任一种，包括但不限于全球移动通信系统(GSM)、增强型数据GSM环境(EDGE)、高速下行分组接入(HSDPA)、高速上行分组接入(HSUPA)、演进、仅数据(EV-DO)、HSPA、HSPA+、双小区HSPA(Dual-Cell HSPA) (DC-HSPDA)、长期演进(LTE)、近场通信(NFC)、宽带码分多址(W-CDMA)、码分多址(CDMA)、时分多址(TDMA)、蓝牙、无线保真(Wi-Fi)（例如，IEEE 802.11a、IEEE 802.11ac、IEEE 802.11ax、IEEE 802.11b、IEEE 802.11g和/或IEEE 802.11n）、基于IP的语音传输(VoIP)、Wi-MAX、电子邮件协议（例如，互联网信息访问协议(IMAP)和/或邮局协议(POP)）、即时消息（例如，可扩展消息与存在协议(XMPP)、针对即时消息和呈现业务的利用扩展的会话初始化协议(Session Initiation Protocol for Instant Messaging and Presence LeveragingExtensions) (SIMPLE)、即时消息和出席服务(IMPS)和/或短消息服务(SMS)或任何其他合适的通信协议，包括截至本公开内容的申请日尚未开发的通信协议。

在一些实施方案中，数据传输装置150是受试者用户装置110的一部分。即，在一些实施方案中，数据传输装置150和受试者用户装置110是单个装置。在一些实施方案中，存在附接到受试者的单个葡萄糖传感器102，并且数据传输装置150是葡萄糖传感器102的一部分。即，在一些实施方案中，数据传输装置150和葡萄糖传感器102是单个装置。

当然，系统48的其他拓扑是可能的。例如，所述一个或多个受试者用户装置110可以不依赖于通信网络106，而直接将信息无线地传输到数据传输装置150和/或药物剂量指导计算机系统602。类似地，所述一个或多个葡萄糖传感器102和所述一个或多个胰岛素笔104可以直接将信息无线地传输到数据传输装置150和/或药物剂量指导计算机系统602。此外，数据传输装置150和/或药物剂量指导计算机系统602可以构成便携式电子装置、服务器计算机，或者实际上构成在网络中链接在一起的若干个计算机或者是云计算环境中的虚拟机。这样，图1A和图1B中所示的示例性拓扑仅用于以本领域技术人员将容易理解的方式描述本公开的示例实施方案的特征。

虽然图1A和图1B中公开的系统48可以独立工作，但是在一些实施方案中，它还可以与电子病历链接，从而以任何方式交换信息。

如图5所示，计算机系统602优选地包括分布式微服务架构内的一个或多个引擎70。图5中所示的部件是示例性的，并不意味着将可能需要或包括的所有部件全部包括在内。此外，在不脱离本文所述主题的各方面的精神或范围的情况下，在其他实施方式中部件的数量可以不同。

参考图5，在一些实施方案中，计算机系统602包括一个或多个系统。在一些实施方案中，用于根据受试者的处方药剂方案自主地提供药物剂量指导推荐的功能分布在任意数量的联网计算机上、和/或驻留在通过通信网络106可访问的远程位置处的若干个联网计算机中的每一个联网计算机上、和/或被托管在一个或多个基于云的环境中。本领域的技术人员将理解，各种不同计算机拓扑中的任一种都可用于该应用，并且所有此类拓扑都在本公开的范围内。

在一些实施方案中，用于根据受试者的处方药剂方案自主地提供药剂剂量推荐的示例性药物剂量指导计算机系统602包括：一个或多个处理单元（CPU）202；网络或其他通信接口260；存储器214（例如，随机存取存储器）；一个或多个磁盘存储器和/或持久性装置220（可选地由一个或多个控制器218访问）；一个或多个用于将上述部件互连的通信总线212；以及为上述部件供电的电源224。在一些实施方案中，使用已知的计算技术（诸如缓存）与非易失性存储器220无缝地共享存储器214中的数据。在一些实施方案中，存储器214和/或存储器220包括相对于一个或多个中央处理单元202远程定位的大容量存储器。换句话说，存储在存储器214和/或存储器220中的一些数据实际上可以被托管在这样的计算机上：所述计算机在药物剂量指导计算机系统602的外部，但是可以由药物剂量指导计算机系统602利用网络接口210通过互联网、内联网或其他形式的网络或电子线缆（在图4A中示为元件106）进行电子访问。

在一些实施方案中，用于向多个受试者提供药物剂量指导推荐的药物剂量指导计算机系统602的存储器214存储：

· 引擎70，该引擎包括一个或多个协调器230和多个容器74（例如74-1、74-2、74-Z），

· 一个或多个协调器230，所述一个或多个协调器对以下各项进行组织：受试者数据，用于确定药物剂量指导请求所需的功能，以及向容器74分配功能请求254，

· 编码器模块240，该编码器模块将功能252嵌入到容器74中，以及

· 一个或多个容器74，所述一个或多个容器中的每个容器包含嵌入式功能252并执行功能请求254。

在一些实施方案中，经由任意浏览器（电话、平板电脑、膝上型电脑/台式电脑）可访问药物剂量指导系统602。在优选的实施方案中，药物剂量指导系统602被存储在云计算环境中。

在一些实施方式中，用于使用包括多个功能的多功能剂量指导算法向多个受试者提供药物剂量指导推荐的药物剂量指导计算机系统602的上述标识的数据元件或模块中的一个或多个存储在一个或多个前述存储器装置中，并且对应于用于执行上述功能的一组指令。以上标识的数据、模块或程序（例如，指令集）不需要被实现为单独的软件程序、过程或模块，并且因此，这些模块的各种子集可以在各种实施方式中被组合或以其他方式重新布置。在一些实施方式中，存储器214和/或220可选地存储以上标识的模块的子集。此外，在一些实施方案中，存储器214和/或220存储以上未描述的附加模块。

在一些实施方案中，由用户装置278（诸如智能电话（例如，iPhone）、膝上型计算机、平板计算机、台式计算机、或其他形式的电子装置（例如游戏机））产生用于根据受试者的处方胰岛素方案212自主调整长效胰岛素药剂剂量216的药物剂量指导请求。在一些实施方案中，计算机系统602具有在图5所示的计算机系统602中发现的任何或全部电路、硬件部件和软件部件。为了简洁和清楚起见，仅示出了计算机系统602的一些可能的部件，以便更好地强调可以安装在计算机系统602上的附加软件模块。

现在已经公开了用于使用包括多个功能的多功能剂量指导算法向多个受试者提供药物剂量指导推荐的系统48和装置200的细节，参考图6公开了根据本公开的各种实施方案的与该系统的过程和特征的流程图有关的细节。

参考图6中的框302，本公开的目的是结合诸如数据传输装置150和计算机系统602之类的装置，使用包括多个功能的多功能剂量指导算法来向多个受试者提供药物剂量指导推荐。每个受试者都具有糖尿病病症。

dL

在一些实施方案中，该糖尿病病症是2型糖尿病。在一些实施方案中，药物剂量指导请求是针对胰岛素药剂的剂量，其中胰岛素药剂的剂量应达到治疗糖尿病的受试者的预确定血糖目标范围。

在一些实施方案中，所述预确定血糖目标范围为50-180mg/dL、60-180mg/dL、70-180mg/dL、80-180mg/dL、50-200mg/dL、60-200mg/dL、70-200mg/dL、80-200mg/dL、50-250mg/dL、60-250mg/dL、70-250mg/dL或80-250mg/dL。

在一些实施方案中，所述多个受试者包括至少100个受试者、至少1,000个受试者、至少5,000个受试者、至少10,000个受试者、至少50,000个受试者或至少100,000个受试者。在一些实施方案中，所述系统同时为每个这样的受试者执行药物剂量指导请求。

所述多个功能中的每个相应功能252与多个容器类别中的容器类别250相关联。如图5所示，计算机系统602包括一个或多个处理器202和存储器214/220。存储器包括指令，所述指令在由所述一个或多个处理器执行时执行响应于从所述多个受试者中的受试者接收到药物剂量推荐请求的方法。

在一些实施方案中，与对应于相应功能请求254的功能252相关联的容器类别250中的容器74评估相应功能请求254是否包含该功能提供功能结果256所需的输入。在这样的情况下，当功能请求未能包含所需的输入时，与功能相关联的容器类中的容器将不会提供功能结果256。

在一些实施方案中，本公开用于治疗至少5岁、至少10岁、至少11岁、至少12岁、至少13岁、至少14岁、至少15岁、至少16岁、至少17岁、至少18岁、至少19岁或至少20岁的受试者。

在一些实施方案中，本公开用于治疗体重指数不大于32 kg/m²的受试者。在一些实施方案中，本公开用于治疗体重指数不大于34 kg/m²的受试者。在一些实施方案中，本公开用于治疗体重指数不大于35 kg/m²的受试者。在一些实施方案中，本公开用于治疗体重指数不大于36 kg/m²的受试者。在一些实施方案中，本公开用于治疗体重指数不大于37kg/m²的受试者。在一些实施方案中，本公开用于治疗体重指数不大于38 kg/m²的受试者。

在一些实施方案中，本公开用于治疗体重指数为约25 kg/m²的受试者。在一些实施方案中，本公开用于治疗体重指数在20 kg/m²至30 kg/m²之间的受试者。

在一些实施方案中，本发明用于治疗患有糖尿病至少1年、至少5年、至少7年、至少9年或至少11年的受试者。

在一些实施方案中，本公开在治疗数周后达到不超过7％的受试者的基线HbA_1c水平。在一些实施方案中，本公开在治疗10至40周后、治疗15至30周后、或治疗20至28周后、或治疗26周后达到不超过7％的受试者的基线HbA_1c水平。在一些实施方案中，本公开在治疗数周后达到不超过6％、不超过7％或不超过8％的受试者的基线HbA_1c水平。在一些实施方案中，本公开在治疗10至40周后、治疗15至30周后、或治疗20至28周后、或治疗26周后达到不超过6%、不超过7%或不超过8%的受试者的基线HbA_1c水平。

在一些实施方案中，所述药剂包括通过注射（诸如通过使用胰岛素笔装置104）递送的胰岛素。在一些实施方案中，所述药剂是LysB29（Nc-十六烷二酰基-y-Glu）des（B30）人胰岛素（德谷胰岛素，Tresiba®）。

根据本发明，基础胰岛素包括长效胰岛素和超长效胰岛素或由其组成。

在一些实施方案中，所述药剂包括天然存在的胰岛素的衍生物或类似物，所述衍生物或类似物：

(a) 在生理条件下至少部分地表现出天然存在的胰岛素的胰岛素受体结合，优选地，天然存在的胰岛素的胰岛素受体结合的至少0.01％，例如天然存在的胰岛素的胰岛素受体结合的至少0.1％、至少1％、至少5％、至少10％、至少15％、至少20％、至少25％、至少50％、至少65％、至少75％、至少85％、至少95％、至少100％、至少110％、至少120％、至少130％、至少140％或至少150％，和/或至少部分地表现出天然存在的胰岛素的效力，优选地，天然存在的胰岛素的效力的至少25％，例如天然存在的胰岛素的效力的至少50％、至少65％、至少75％、至少85％、至少95％、至少100％、至少110％、至少120％、至少130％、至少140％或至少150％。

(b) 在例如皮下注射时，在生理条件下，表现出至少5小时且小于18小时的平均终末半衰期，例如至少7小时、至少8小时、至少10小时、至少12.5小时、大于12.5小时、至少15小时或至少17.5小时和小于18小时、介于5小时和17.5小时之间、介于10小时和17.5小时之间或介于15小时和17.5小时之间。

(c) 在一些实施方案中，所述药剂包括“长效胰岛素”，其还：

(d) 导致受试者在24小时周期内平均胰岛素浓度（AUCF%）的最大偏差≤±20，例如≤±18、≤±17、≤±16、≤±15、≤±14、≤±13、≤±12、≤±11、≤±10、≤±9、≤±8、≤±7、≤±6、≤±5、≤±4、≤±3、≤±2、≤±1、≤±0.5、≤±0.1。

在一些实施方案中，所述药剂包括“长效胰岛素”，其包括天然存在的胰岛素的衍生物或类似物，所述衍生物或类似物：

(a) 在生理条件下至少部分地表现出天然存在的胰岛素的胰岛素受体结合，优选地，天然存在的胰岛素的胰岛素受体结合的至少0.01％，例如天然存在的胰岛素的胰岛素受体结合的至少0.1％、至少1％、至少5％、至少10％、至少15％、至少20％、至少25％、至少50％、至少65％、至少75％、至少85％、至少95％、至少100％、至少110％、至少120％、至少130％、至少140％或至少150％，和/或至少部分地表现出天然存在的胰岛素的效力，优选地，天然存在的胰岛素的效力的至少25％，例如天然存在的胰岛素的效力的至少50％、至少65％、至少75％、至少85％、至少95％、至少100％、至少110％、至少120％、至少130％、至少140％或至少150％，

(b) 皮下注射时，在生理条件下表现出至少18小时的平均终末半衰期，例如，大于18小时、至少20小时、大于20小时、大于22小时、至少22.5小时、或大于24小时、至少25小时、至少27.5小时、至少30小时、至少32.5、至少35小时、至少37.5小时、或至少40小时、或介于18至40小时之间、介于20至40小时之间、介于24至40小时之间。

在一些实施方案中，所述药剂包括“长效胰岛素”，其还：

(c) 导致受试者在24小时周期内平均胰岛素浓度（AUCF%）的最大偏差≤±20，例如≤±18、≤±17、≤±16、≤±15、≤±14、≤±13、≤±12、≤±11、≤±10、≤±9、≤±8、≤±7、≤±6、≤±5、≤±4、≤±3、≤±2、≤±1、≤±0.5、≤±0.1。

原则上，胰岛素的半衰期越长，葡萄糖降低效果在给药间隔（即，注射之间的时间间隔）内越稳定和均匀地分布。

根据本公开，基础胰岛素包括长效胰岛素和超长效胰岛素或由其组成。

根据本公开，以在受试者中实现有益的血糖控制的量施用基础胰岛素。

在一些实施方案中，所述药剂由以下组成：单一胰岛素药剂，其具有的作用时间在12至24小时之间；或胰岛素药剂的混合物，其具有的总作用时间在12至24小时之间。这样的胰岛素药剂的示例包括但不限于：德谷胰岛素（由NOVO NORDISK开发，商品名为Tresiba®）、NPH（Schmid, 2007, “New options in insulin therapy,” J Pediatria (Rio J).83(Suppl 5): S146–S155）、甘精胰岛素（LANTUS, 2007年3月2日）、甘精胰岛素注射液（Dunn等人 2003, “An Updated Review of its Use in the Management of DiabetesMellitus” Drugs 63: 第 1743页）和地特胰岛素（Plank等人, 2005, “A double-blind,randomized, dose-response study investigating the pharmacodynamic andpharmacokinetic properties of the long-acting insulin analog detemir,”Diabetes Care 28:1107–1112），其每一个通过引用并入本文。

在一些实施方案中，所述多个功能252包括第一功能和第二功能（304）。在一些实施方案中，第一功能（例如252-1）执行加法或减法。在一些实施方案中，第二功能（例如252-2）执行回归分析和/或内插（例如以重构数据集）。在一些实施方案中，第一功能（例如252-1）能由所述多个容器类别中的第一容器类别（例如250-1）的容器（例如74-1）的每个实例执行。在一些实施方案中，容器类别包括：数据重构类别、依从性类别、计算类别和/或滴定葡萄糖水平类别。在一些实施方案中，协调器230将功能请求254分配给容器（例如74-1和74-2），所述容器是必要容器类别（例如250-1）的实例。

在一些实施方案中，第一容器类别（例如250-1）的容器（例如74-2和74-2）的每个实例由服务器托管在第一组服务器（未示出）中，并且第二容器类别（例如250-W）的容器（例如74-Z）的每个实例由第二组服务器中的服务器托管。在这样的实施方案中，第一组服务器与第二组服务器不同。在一些实施方案中，这样的拓扑具有的优点是允许为容器提供更强大的服务器或更大的服务器集合，其具有更多的计算密集型功能。在另选的实施方案中，容许两个或更多个不同类别的容器在同一服务器上同时运行。

参考框306，在一些实施方案中，第一功能能由所述多个容器类别中的第一容器类别的容器的每个实例执行。例如，当第一功能是滴定葡萄糖水平类别时，第一容器类别的容器的每个实例具有滴定葡萄糖水平类别。

参考框308，在一些实施方案中，第二功能能由所述多个容器类别中的第二容器类别的容器的每个实例执行。换句话说，在由计算系统提供的相应功能与相应容器类别之间存在一一对应关系。

在一些实施方案中，所述多个容器类别包括两个或更多个容器类别、三个或更多个容器类别、四个或更多个容器类别、或者五个或更多个容器类别。

参考框310，在一些实施方案中，第一功能的硬件资源要求不同于第二功能的硬件资源要求。换句话说，在一些实施方案中，所述多个功能包括第一功能和第二功能，第一功能能由所述多个容器类别中的第一容器类别的容器的每个实例执行，第二功能可由所述多个容器类别中的第二容器类别的容器的每个实例执行，并且第一功能的硬件资源要求不同于第二功能的硬件资源要求。在一个这样的示例中，第一功能在计算上比第二功能更昂贵。例如，处理第一功能的容器类别的容器比处理第二功能的容器类别的容器要求更多的CPU时间。另选地或附加地，处理第一功能的容器类别的容器可能比处理第二功能的容器类别的容器要求更多的随机存取存储器。这样，在决定是否针对给定类型的功能初始化具体容器类别的另一个容器时，在本公开的一些实施方案中考虑了容器的相对资源要求。也就是说，通过对特定功能的请求随时间推移的硬件资源要求的集中趋势的估计测量，对特定功能的请求数量进行加权（缩放、归一化）。在一些实施方案中，对跨针对此类功能的历史请求的特定功能的资源要求进行记录，以便得出由所公开的系统提供的多个功能中的每个功能的相对资源要求的合适度量（缩放因子）。在一些实施方案中，随着时间的推移，逐个功能地追踪此类功能请求的资源要求的集中趋势的测量。在一些实施方案中，在计算此类集中趋势的测量时，较旧的功能请求相对于较新的功能请求被降低权重。

在一些实施方案中，编码器模块还包括：针对资源要求评估每个相应功能（例如，与评估整个引擎70的资源要求相反，从而确保最高效地使用资源并使计算浪费最小化）。在一些实施方案中，反复评估第一容器类别的容器的第一组实例的复合资源要求。在这样的实施方案中，当第一容器类别的容器的第一组实例的复合资源要求满足与第一组容器相关联的第一资源分配阈值时（例如，当做出与由具有对应功能的一组当前分配的容器可以处理的相比较多的对应功能的功能请求时），将容器类别的容器的一个或多个附加实例添加到第一组容器中，并容许其接受来自编码器模块的与第一容器类别的类型相匹配的功能请求。在一些实施方案中，基于如上所述的给定容器类别的随时间推移追踪的相应服务功能请求的资源要求的集中趋势的测量的评估，随时间推移调整与给定容器类别相关联的第一资源分配阈值。

在一些实施方案中，当由容器类别中的一组容器共同使用的随机存取存储器为>1MB、>5MB、>50MB、>500MB、>1GB或>5GB时，满足与给定容器类别相关联的第一资源分配阈值。在一些实施方案中，当容器类别中的一组容器要求平均>0.05秒、>0.5秒、>1秒、>5秒、>10秒、>15秒、>30秒、>1分钟或>5分钟来返回功能结果256时，满足与给定容器类别相关联的第一资源分配阈值。

在一些实施方案中，当所述第一容器类别的第一组实例的复合资源要求满足与所述第一组容器相关联的第二资源分配阈值时，从所述第一组容器中移除所述第一组容器中的一个或多个容器，并且不再容许所述第一组容器中的一个或多个容器接受来自所述编码器模块的功能请求。在一些实施方案中，基于如上所述的给定容器类别的随时间推移追踪的相应服务功能请求的资源要求的集中趋势的测量的评估，随时间推移调整与给定容器类别相关联的第二资源分配阈值。

在一些实施方案中，当用于容器类别中的一组容器的集体随机存取存储器为<1MB、<5MB、<50MB、<500Mb、<1GB或<5GB时，满足与给定容器类别相关联的第二资源分配阈值。在一些实施方案中，当容器类别中的一组容器要求平均<0.05秒、<0.5秒、<1秒、<5秒、<10秒、<15秒、<30秒、<1分钟或<5分钟来返回功能结果256时，满足与给定容器类别相关联的第二资源分配阈值。

参考图6的框312，在一些实施方案中，所述方法标识满足特定受试者的药物剂量指导请求所需的多个功能请求。在这样的实施方案中，所述多个功能请求中的功能请求254能由所述多个功能中的对应功能执行。在一些实施方案中，所述多个功能请求包括针对两个或更多个功能的请求，所述两个或更多个功能要求两个或更多个对应的容器类别的服务。在一些实施方案中，所述多个功能请求包括针对三个或更多个功能的请求，所述三个或更多个功能要求三个或更多个对应的容器类别的服务。在一些实施方案中，所述多个功能请求包括针对四个或更多个功能的请求，所述四个或更多个功能要求四个或更多个对应的容器类别的服务。在一些实施方案中，所述多个功能请求包括针对五个或更多个功能的请求，所述五个或更多个功能要求五个或更多个对应的容器类别的服务。

在一些实施方案中，所述多个功能请求包括第一功能请求。在一些实施方案中，该第一功能请求用于计算受试者的药物剂量指导推荐（例如，向受试者提供新的和/或更新的剂量推荐）。在另选的实施方案中，该第一功能请求用于重构受试者的胰岛素注射历史。例如，在一些实施方案中，胰岛素注射历史由胰岛素笔104收集，该胰岛素笔还将受试者的胰岛素注射历史传输至药物剂量指导系统602。在一些实施方案中，胰岛素注射历史包含时间间隙（例如，丢失的数据点）或其他错误（例如，将“启动”事件记录为胰岛素注射）。此类情况在2017年8月23日提交的题为“Patient Mounted Micro Vein Enhancer”的美国专利申请公开号2018/0014776 A1中有描述，其通过引用并入本文。在一些实施方案中，药物剂量指导系统602必须重构受试者的胰岛素注射历史，作为提供胰岛素剂量指导推荐的一部分。

在一些实施方案中，第一功能请求用于计算受试者的滴定葡萄糖水平。滴定葡萄糖水平是基于由受试者的葡萄糖传感器102收集的血糖历史和由胰岛素笔104施用的胰岛素注射量。滴定葡萄糖水平对于每个受试者是特定的，并且在一些实施方案中，其还基于一个或多个受试者参数512。在一些实施方案中，计算滴定葡萄糖水平的方法如2017年6月23日提交的题为“Basal Titration with Adaptive Target Glucose Level”的国际申请号PCT/EP2017/065578中所述，其通过引用并入本文。

在一些实施方案中，第一功能请求用于重构受试者的血糖历史。在一些实施方案中，受试者的血糖历史由葡萄糖传感器102测量，该葡萄糖传感器在一些实施方案中是持续血糖监测器，诸如2003年12月9日提交的题为“Graphical Display for Medical Devicesand Methods for Displaying Medical Information”的美国专利公开号2004/0153257A1所描述的，其通过引用并入本文。在一些实施方案中，血糖历史包含时间间隙（例如，丢失的数据点）。例如，持续血糖监测器可能由于用户在记录血糖水平时的错误或其他技术困难而未能在间歇的时间段内记录受试者的血糖水平。在一些实施方案中，葡萄糖测量值由葡萄糖传感器自主测量。例如，在一些实施方案中，葡萄糖传感器102由ABBOTT的FREESTYLELIBRE CGM（“LIBRE”）示例，其进行受试者的自主葡萄糖测量。LIBRE允许利用皮上硬币大小的传感器进行免标定的葡萄糖测量，当距离很近时，该传感器可以经由近场通信将达八个小时的数据发送到读取器装置。LIBRE可以佩戴十四天。

在一些实施方案中，第一功能请求用于获得受试者的剂量指导参数（例如，受试者参数512）。在一些实施方案中，剂量指导参数包括以下各项中的一项或多项：受试者的体重，受试者的年龄，受试者的上限目标葡萄糖范围，受试者的下限目标葡萄糖范围，受试者的过度基础化极限，受试者最近的药物剂量指导推荐和/或起始胰岛素基础剂量，和/或受试者的基础注射历史。

在一些实施方案中，用于确定更新的最近药物剂量指导推荐的上限目标葡萄糖范围为80-180mg/dL、90-180 mg/dL、100-180mg/dL、90-200mg/dL、90-250mg/dL或90-300mg/dL。

在一些实施方案中，用于确定更新的药物剂量指导推荐的下限目标葡萄糖范围为50-70mg/dL、70-90 mg/dL、70-100mg/dL、60-100mg/dL或60-90mg/dL。

在一些实施方案中，重构受试者的血糖历史包括：当血糖历史时间过程包含时间间隙时（例如，如果受试者的持续血糖监测器有传感器错误——来自用户或技术错误——并且在间歇的时间段内未记录血糖测量值，或者如果受试者犯了会影响持续血糖监测器的错误），计算受试者的重构的血糖历史。在一些实施方案中，时间过程中的间隙包括预确定的时间段，其中未记录血糖测量值。在一些实施方案中，对血糖历史记录中的间隙进行定义的预确定时间段为>5分钟、>10分钟、>20分钟、>30分钟或>1小时。

在一些实施方案中，当血糖历史中存在间隙时，基于紧接该间隙之前的过去一小时、紧接该间隙之前的过去一周、紧接该间隙之前的过去两周、紧接该间隙之前的过去一个月、或紧接该间隙之前的过去一年的受试者的血糖历史来计算重构的血糖历史。在一些实施方案中，基于该间隙之前和之后1分钟、该间隙之前和之后5分钟、该间隙之前和之后10分钟、该间隙之前和之后15分钟、该间隙之前和之后30分钟、和/或该间隙之前和之后1小时的血糖历史来计算重构的血糖历史。

在一些实施方案中，针对给定受试者的功能请求所需的输入包括：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标葡萄糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最新的药物剂量指导推荐和/或起始胰岛素基础剂量，和/或（vii）受试者的基础注射历史。某些功能请求仅要求该信息的子集。某些功能请求要求附加数据。

在一些实施方案中，针对给定受试者的功能请求所需的输入包括以下各项中的任意一项：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标血糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最近的药物剂量指导推荐和/或起始胰岛素基础剂量，以及（vii）受试者的基础注射历史。一些此类功能请求要求附加数据。

在一些实施方案中，针对给定受试者的功能请求所需的输入包括以下各项中的任意两项：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标血糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最近的药物剂量指导推荐和/或起始胰岛素基础剂量，以及 （vii）受试者的基础注射历史。一些此类功能请求要求附加数据。

在一些实施方案中，针对给定受试者的功能请求所需的输入包括以下各项中的任意三项：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标血糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最近的药物剂量指导推荐和/或起始胰岛素基础剂量，以及 （vii）受试者的基础注射历史。一些此类功能请求要求附加数据。

在一些实施方案中，针对给定受试者的功能请求所需的输入包括以下各项中的任意三项：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标血糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最近的药物剂量指导推荐和/或起始胰岛素基础剂量，以及 （vii）受试者的基础注射历史。一些此类功能请求要求附加数据。

参考框314，在一些实施方案中，针对多个功能请求中的每个相应功能请求254，该方法使用编码器模块240将相应功能请求254嵌入与对应于相应功能请求254的功能相关联的容器类别中的容器中。在一些实施方案中，与对应于相应功能请求的功能相关联的容器类别中的给定容器针对两个或更多个、三个或更多个、四个或更多个、五个或更多个、六个或更多个、七个或更多个、八个或更多个、10个或更多个、五十个或更多个、100个或更多个、1000个或更多个、或10,000个受试者同时服务同一类别的两个或更多个、三个或更多个、四个或更多个、五个或更多个、六个或更多个、七个或更多个、八个或更多个、10个或更多个、五十个或更多个、100个或更多个、1000个或更多个、或者10,000个或更多个请求。

参考框316，在一些实施方案中，该方法针对多个功能请求中的每个相应功能请求254，从执行相应功能请求254的容器类别中的容器收集功能结果256，从而针对多个受试者中的单个受试者获得多个功能结果。为此，在一些实施方案中，针对受试者的第一功能和第二功能被同时执行。在另选的实施方案中，针对受试者的第一功能和第二功能被循序执行。在其他实施方案中，Boolean逻辑被用于选通是否针对给定受试者做出某些功能请求。例如，在一些实施方案中，当与第一容器类别相对应的第一功能请求的功能结果提供不满足监测条件的结果时，不对受试者触发与第二容器类别相对应的第二功能请求。

参考框318，在一些实施方案中，该方法使用多个功能结果提供药物剂量指导推荐。当所有请求的功能请求返回可以被处理的合适的功能结果以便为受试者计算有效的剂量推荐时，则实现了框318。在一些实施方案中，该方法还包括：执行剂量指导请求的质量检查，并且其中当质量检查失败时（例如，当数据质量检查显示功能请求缺少必要信息时——例如关于受试者参数512的信息，或关于所需功能的信息——针对对应功能来处理功能请求，或者当功能请求的大小将使可用的计算资源不堪重负时），不提供药物剂量指导推荐。在一些实施方案中，当数据质量检查失败并且当受试者记录低血糖事件或受试者未服用先前推荐的药物剂量时，提供药物剂量指导推荐。在一些实施方案中，当受试者的血糖水平低于70mg/L、75mg/L、80mg/L、65mg/L、60mg/L、55mg/L、50mg/L、45mg/L或40mg/L时，受试者记录低血糖事件。在一些实施方案中，当受试者忘记服用剂量或当受试者服用了不正确的剂量时，受试者不能服用先前推荐的药物剂量。

图7示出了用于向受试者提供药物剂量指导推荐的示例方法400（例如，在电子装置处执行）。在一些实施方案中，当先前未向受试者提供药物剂量指导推荐时执行图7的方法。在一些实施方案中，图7的方法提供了对先前提供的药物剂量指导推荐的重新推荐。在一些实施方案中，在提供一个或多个先前的药物剂量指导推荐之后，执行图7的方法以提供更新的药物剂量指导推荐。

参考图7，计算机系统602接收药物剂量指导请求402。在一些实施方案中，药物剂量指导请求由用户装置（例如受试者用户装置110）自动产生（无需人工干预）。在一些实施方案中，用户做出对药物剂量指导的具体请求。该方法继续并检查404该请求是否有效（例 如，系统确认该请求中包括必需的或要求的数据——例如以下各项中的一项或多项：受试者的体重，受试者的上限目标血糖范围，受试者的下限目标血糖范围，受试者的过度基础化，最近的药物剂量指导推荐和/或起始基础胰岛素剂量，受试者的血糖历史，受试者的基础胰岛素注射历史，和/或受试者的注射数据刷新）。在一些实施方案中，针对给定受试者的功能请求254所需的输入包括以下各项中的任意一项或多项、任意两项或多项、任意三项或三项、任意四项或多项、任意五项或多项、任意六项或多项、所有七项、至少所有七项：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标葡萄糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最近的药物剂量指导推荐和/或起始胰岛素基础剂量，以及（vii）受试者的基础注射历史。在一些实施方案中，针对给定受试者的功能请求254所需的输入包括以下各项的子集：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标血糖范围，（iv）受试者的过度基础化极限，（v）受试者的血糖历史，（vi）受试者的最近的胰岛素滴定推荐和/或起始胰岛素基础剂量，以及（vii）受试者的基础注射历史。

如果药物剂量指导请求不包含必要的数据，则该方法结束405，不提供指导，并且可选地，稍后以适当的数据建议用户返回。在一些实施方案中，装置通知用户哪些数据丢失或建议用户寻求关于其医疗装置的帮助。如果药物剂量指导请求包含适当的信息，则该方法标识406提供所请求的药物剂量指导推荐所需的功能请求254（例如，剂量指导请求中包含的功能请求），其中所述多个功能请求中的每个功能请求254能由所述多个功能中的对应功能执行。该方法针对每个功能请求做出初始硬件资源要求（例如，存储器要求、计算复杂度等）确定408。在一些实施方案中，该方法确定所需容器的数量和/或按功能请求的类型划分容器。在一些实施方案中，协调器230执行硬件资源确定。在一些实施方案中，硬件资源确定包括：实例化与执行向受试者提供药物剂量推荐所必要的功能请求所需的功能相关联的容器类别的容器。

该方法继续并将与功能请求有关的功能嵌入选定的（例如，实例化的）容器中（410）。在一些实施方案中，协调器230执行嵌入。将功能请求分配412给具有适当嵌入式功能的容器。评估407每个功能请求254以包含执行功能所需的数据集。如果功能请求254不包含所需的数据集，则该方法结束过程405，不提供指导，并且可选地稍后建议用户返回。

对于已经被分配给容器并且包含所需数据集的每个功能请求254，相应的容器执行414功能请求。如果该方法确定409系统需要更多计算资源来执行功能请求254，则分配411相应容器类别中的更多容器以执行相应的功能请求。如果该方法确定有足够的计算资源可用于执行功能请求，则该方法继续。

容器将结果返回416到功能请求。在一些实施方案中，容器针对每个剂量指导请求510同时执行功能请求。在一些实施方案中，容器针对每个剂量指导请求510循序执行功能请求。在一些实施方案中，容器针对剂量指导请求510同时执行功能请求的子集，并且循序执行功能请求的另一子集。该方法继续并使用多个功能结果（例如256-1-1、256-1-V等）向受试者提供418结果（例如药物剂量指导推荐）。在一些实施方案中，将结果直接提供给用户（例如，提供给受试者用户装置110）。在一些实施方案中，结果经由数据传输装置150提供给用户。

参考图8，在本公开的一些实施方案中，药物剂量指导请求510是用于指导滴定胰岛素剂量以降低血糖来治疗糖尿病的请求。在这样的实施方案中，受试者用户装置110可以由葡萄糖传感器102和胰岛素笔104中的一个或多个组成。集成系统502自主地获得520受试者的带时间戳的胰岛素注射和血糖测量值（例如，从葡萄糖传感器102和/或胰岛素笔104获得）。而且，在一些实施方案中，由受试者使用以施加处方胰岛素方案的来自一个或多个胰岛素笔104的数据被获得540作为多个注射历史记录。每个注射历史数据点包括带有时间戳的事件，该事件指定了受试者作为处方胰岛素药剂剂量方案的一部分而接受的注射胰岛素药剂的量。对葡萄糖测量值（例如，血糖历史）进行质量评估504，并且在必要时计算重构的血糖历史。血糖历史或重构的血糖历史被存储在非瞬态存储器506中。存储器506包括指令，该指令在由一个或多个处理器执行时响应于接收剂量指导请求而执行方法。根据本公开的方法，剂量指导推荐请求被发送510到计算机系统602以提供药物剂量指导推荐610。

在一些实施方案中，药物剂量指导请求包括获得受试者参数512，所述受试者参数至少包括：（i）受试者的体重，（ii）受试者的上限目标葡萄糖范围，（iii）受试者的下限目标葡萄糖范围，以及（iv）受试者的过度基础化极限。在一些实施方案中，药物剂量指导请求还包括获得第二数据集522（药物剂量指导基线），所述第二数据集至少包含：（i）最近的药物剂量指导推荐，和/或（ii）起始基础剂量。在一些实施方案中，药物剂量指导请求还包括获得血糖数据集520，所述血糖数据集包括在时间过程中获取的受试者的多个葡萄糖测量值以建立血糖历史，以及针对所述多个血糖测量值中的每个相应葡萄糖测量值的对应的葡萄糖时间戳，其表示在时间过程中何时进行相应的葡萄糖测量。在一些实施方案中，药物剂量指导请求还包括获得注射历史数据集540，所述注射历史数据集包括：（i）受试者的基础胰岛素注射历史，其中该注射历史包括在全部或部分时间过程中的多次注射，以及针对所述多个注射中的每个相应注射，（ii）对应的剂量事件量，以及（iii）剂量事件时间戳，其表示在时间过程中何时发生相应的注射事件，并且其中第二数据集还包括：（iv）受试者的最后的注射数据刷新。

在一些实施方案中，用于确定药物剂量指导推荐的上限目标葡萄糖范围为80-180mg/dL、90-180 mg/dL、100-180mg/dL、90-200mg/dL、90-250mg/dL或90-300mg/dL。在一些实施方案中，下限目标葡萄糖范围用于确定药物剂量指导推荐，并且为50-70mg/dL、70-90 mg/dL、70-100mg/dL, 60-100mg/dL或60-90mg/dL。

在一些实施方案中，葡萄糖测量值522是自主测量的。ABBOTT的FREESTYLE LIBRECGM（“LIBRE”）是可以用作葡萄糖传感器102以便进行受试者的自主葡萄糖测量的葡萄糖传感器的示例。LIBRE允许利用皮上硬币大小的传感器进行免标定的葡萄糖测量，当距离很近时，该传感器可以经由近场通信将达八小时的数据发送到读取器装置（例如，数据传输装置150和/或计算机系统602）交流。LIBRE可在所有日常生活活动中佩戴十四天。

在一些实施方案中，药物剂量指导请求还包括针对一组评估信息是否至少包含以下各项来评估所提供的受试者信息：（i）受试者的体重，（ii）在时间过程中获取的受试者的多个血糖测量值，（iii）受试者的注射历史，（iv）受试者的最后的药物剂量指导推荐和/或起始长效或超长效胰岛素剂量，（v）受试者的过度基础化极限，（vi）受试者的最后的注射数据刷新，（vii）受试者的上限目标葡萄糖范围，以及（viii）受试者的下限目标葡萄糖范围。当确定所提供的受试者信息未包含所需的评估信息集时，则不做出药物剂量指导推荐。当确定适当的评估信息可用时，计算系统602的方法包括：提供药物剂量指导推荐610。

在一些实施方案中，目标血糖目标范围（其实现和维持是胰岛素滴定的主要目标）为50-180mg/dL、60-180mg/dL、70-180mg/dL、80-180mg/dL、50-200mg/dL、60-200mg/dL、70-200mg/dL、80-200mg/dL、50-250mg/dL、60-250mg/dL、70-250mg/dL或80-250mg/dL。

可以通过多种方法确定胰岛素剂量，例如，可以基于体重（和/或身高）、空腹血糖和性别（此后根据空腹血糖和/或HbA_1c水平结果根据经验进行调整）来计算胰岛素剂量。使用滴定方法越来越普遍，其中在施用初始剂量标准或根据经验确定的剂量后，根据需要，基于血糖/血浆测量值，以预确定的增量（例如，滴定算法）对其他剂量进行调整，以便达到并维持目标血糖/血浆和/或HbA_1c水平。然而，此类滴定模型始终仅作为指导给出，并且个别调整（例如，经由胰岛素滴定指导推荐）适用于具体情况。

参考图9，计算系统602从一个或多个受试者接收药物剂量指导请求510，并且向每个受试者提供药物剂量指导推荐610。在优选的实施方案中，药物剂量指导系统602驻留在云环境中。容器引擎70接收药物剂量指导请求510。在一些实施方案中，基于计算强度水平以及跨不同剂量指导系统的容器的可重用性水平（例如，使用所述多个功能中的相应功能的频率），将发动机功能分离到容器74中。药物剂量指导请求510包含受试者信息512。在一些实施方案中，受试者信息512-1至少包括：受试者的血糖历史，受试者的最近的胰岛素滴定推荐和/或起始胰岛素基础剂量，以及受试者的基础注射历史。在一些实施方案中，受试者参数512至少包括：受试者的体重，在时间过程中获取的受试者的多个葡萄糖测量值，受试者的注射历史，受试者的过度基础化极限，针对受试者的最后的注射数据刷新，受试者的上限目标葡萄糖范围，以及受试者的下限目标葡萄糖范围。

容器引擎70内的协调器230基于药物剂量指导请求510中的功能请求254的受试者参数512来组织对药物剂量指导请求510的响应。协调器230基于受试者参数512来标识需要哪些功能608。所需功能通过编码器模块240（未示出）被嵌入选定的容器74中。协调器203还确定是否存在需要执行功能的顺序。例如，具有数据重构嵌入式功能608-4的容器74-4可以被安排为在具有依从性嵌入式功能608-2的容器74-2之前或并行执行功能请求，因为这些功能可以被彼此独立地执行。然而，在一些实施方案中，容器74-2、74-3和74-4的集合中的容器可以依赖于具有计算嵌入式功能608-1的容器74-1（例如，容器74-2中的依从性嵌入式功能608-2可能需要一些计算，在一些实施方案中，这些计算由容器74-1中的计算嵌入式功能608-1执行）。协调器230可以根据需要触发计算资源的添加（例如，任何特定容器类别中的附加容器74）。例如，具有用于数据重构的嵌入式功能608-4的容器74-4 可以具有专用于其的附加资源（例如，同一容器类别中的更多容器74），从而确保对药物剂量指导请求510的响应不会超时。

在一些实施方案中，当功能请求要求更多的计算资源时，协调器230实例化容器类别中可以为该功能请求执行相应功能的容器。

在协调器230监督每个容器74的进度的同时，容器可以在它们之间交换信息以促进其相应功能请求254的执行。所述多个容器中的每个容器74根据协调器230的调用处的微服务架构，经由应用程序编程接口（API）与其他容器进行通信。在一些实施方案中，协调器230是多种市售协调器中的任何一种，包括但不限于Azure Service Fabric、Kubernetes、Docker Swarm和Mesosphere DC/OS。在一些实施方案中，协调器230是非市售的专有协调器。

每个容器74为相应的功能请求254产生功能结果256。所述多个功能结果用于提供药物剂量指导推荐610。在一些实施方案中，可以使用另一个容器（例如，74-5，未示出）来将所述多个功能请求编译并组合成针对受试者的药物剂量指导推荐610。在一些实施方案中，协调器230执行功能结果的汇编，并将药物剂量指导推荐610提供给受试者。

参考文献和其他实施方案

本文中引用的全部参考文献均以引用方式全文并入本文，并且出于所有目的，其程度如同每个单独的公布或专利或专利申请被具体和单独地指示成出于所有目的而以引用方式全文并入。

所有标题和子标题在本文中仅为了方便而被使用，并且不应当被解释为以任何方式限制本发明。

除非另外声明，否则本文提供的任何和所有示例或示例性语言（例如，“诸如”）的使用仅旨在更好地说明本发明，而不是对本发明的范围进行限制。本说明书中的任何语言都不应被视为表明任何未声明的要素对于本发明的实践是必不可少的。

本文中引用和并入专利文献仅是为了方便，并不反映这样的专利文献的有效性、可专利性和/或可执行性的任何观点。

本发明可被实现为计算机程序产品，其包括嵌入非瞬态计算机可读存储介质中的计算机程序机构。例如，计算机程序产品可以包含以图1和图2的任意组合示出和/或图8中所述的程序模块。这些程序模块可以存储在CD-ROM、DVD、磁盘存储产品、USB密钥或任何其他非瞬态计算机可读数据或程序存储产品中。

如对于本领域技术人员而言显而易见的那样，在不脱离本发明的实质和范围的情况下，可对本发明进行许多修改和变化。本文所述的具体实施方案仅作为实例提供。选择和描述上述实施方案是为了最好地解释本发明的原理及其实际应用，从而使本领域的其他技术人员能够通过适于所设想的特定用途的各种修改最好地利用本发明和各种实施方案。本发明仅受所附权利要求的条款以及这些权利要求所赋予的等同物的全部范围的限制。

Claims (15)

1.一种用于使用包括多个功能的多功能剂量指导算法向多个受试者提供药物剂量指导推荐的计算系统，其中所述多个功能中的每个相应功能与对应的容器类别相关联，并且其中所述计算系统包括：一个或多个处理器，和存储器，所述存储器包括：

- 指令，所述指令在由所述一个或多个处理器执行时执行响应于从所述多个受试者中的受试者接收到药物剂量指导请求的方法，所述方法包括以下步骤：

（i）标识满足所述药物剂量指导请求所需的多个功能请求，其中所述多个功能请求中的功能请求能由所述多个功能中的对应功能执行，

（ii）针对所述多个功能请求中的每个相应功能请求，使用编码器模块将所述相应功能请求和相关输入数据嵌入与对应于所述相应功能请求的功能相关联的容器类别的容器中，

（iii）针对所述多个功能请求中的每个相应功能请求，从执行所述相应功能请求的容器中收集功能结果，从而获得多个功能结果，以及

（iv） 使用所述多个功能结果提供药物剂量指导推荐。

2.如权利要求1所述的计算系统，其中：

- 所述多个功能包括第一功能和第二功能，

- 所述第一功能能由第一容器类别的每个容器执行，

- 所述第二功能能由第二容器类别的每个容器执行，并且

- 所述第一功能的硬件资源要求不同于所述第二功能的硬件资源要求。

3.如权利要求1或2中任一项所述的计算系统，其中：

- 所述多个功能包括第一功能和第二功能，

- 所述第一功能能由第一容器类别的每个容器执行，

- 所述第二功能能由第二容器类别的每个容器执行，

- 所述第一容器类别的每个容器由第一组服务器中的服务器托管，并且

- 所述第二容器类别的每个容器由第二组服务器中的服务器托管而不是由所述第一组服务器中的服务器托管。

4.如权利要求1至3中任一项所述的计算系统，其中：

- 反复评估给定容器类别的容器的复合资源要求，并且

- 当所述给定容器类别的容器的复合资源要求满足与所述给定容器类别相关联的资源分配阈值时，添加所述给定容器类别的一个或多个附加容器，并且容许所述给定容器类别的一个或多个附加容器接受来自所述编码器模块的与所述给定容器类别相匹配的功能请求。

5.如权利要求4所述的计算系统，其中：

- 当所述给定容器类别的容器的复合资源要求满足与所述给定容器类别相关联的第二资源分配阈值时，移除所述给定容器类别的一个或多个容器，并且不再容许所述给定容器类别的一个或多个容器接受来自所述编码器模块的功能请求。

6.如权利要求1至5中任一项所述的计算系统，其中：

- 与对应于给定功能请求的功能相关联的容器类别的给定容器评估所述相应功能请求是否包含所述功能提供功能结果所需的输入数据，并且

- 当所述功能请求未能包含所述所需的输入数据时，与所述功能相关联的所述容器类别的所述给定容器不会提供功能结果。

7.如权利要求1至6中任一项所述的计算系统，其中所述系统针对所述多个受试者中的每个受试者同时执行药物剂量指导请求。

8.如权利要求7所述的计算系统，其中所述多个受试者包括至少10,000个受试者。

9.如权利要求1至8中任一项所述的计算系统，其中所述多个功能包括以下各项中的一项或多项：

- 计算受试者的药物剂量指导推荐，

- 重构受试者的胰岛素注射历史，

- 计算受试者的滴定葡萄糖水平，

- 重构受试者的血糖历史，以及

- 得到受试者的剂量指导参数。

10.如权利要求1至9中任一项所述的计算系统，其中：

- 所述药物剂量指导请求是针对胰岛素药剂的剂量，并且

- 所述胰岛素药剂的剂量应达到治疗糖尿病病症的受试者的预确定血糖目标范围。

11.如权利要求1至10中任一项所述的计算机系统，其中所述方法还包括以下进一步的步骤：

- 执行所述剂量指导请求的质量检查，其中在以下情况下所述质量检查失败并导致不提供药物剂量指导推荐：

（a）来自受试者的剂量指导请求包括低血糖事件的记录，或

（b）来自受试者的剂量指导请求包括指示所述受试者未服用先前推荐的药物剂量的记录。

12.如权利要求1所述的计算系统，其中所述编码器模块（ii）还包括：针对资源要求评估每个相应功能。

13.如权利要求1至12中任一项所述的计算系统，其中针对受试者的至少两个功能被同时执行。

14.如权利要求1至13中任一项所述的计算系统，其中针对受试者的至少两个功能被循序执行。

15.如权利要求1至14中任一项所述的计算系统，其中所述功能请求所需的所述输入针对给定的受试者至少包括：

- 所述受试者的上限目标葡萄糖范围，

- 所述受试者的血糖历史，

- 所述受试者的基础注射历史，以及

- 最近的药物剂量指导推荐，

以及可选的以下各项中的一项或多项：

- 所述受试者的体重，

- 所述受试者的下限目标葡萄糖范围，

- 所述受试者的过度基础化极限，以及

- 所述受试者的起始胰岛素基础剂量。

Images