CN101689224A - 用于根据对患者生理机能进行建模而开发患者特定疗法的系统和方法 - Google Patents

Abstract

本申请公开了一种基于对患者特定生理机能的动态建模而开发患者特定疗法的系统及其方法。该系统包括软件模块，其配置成经由计算机提供对数据收集协议的访问，该数据收集协议限定了至少一类待收集的患者特定数据和患者特定数据待收集的方式，并且提供对信息的访问，利用该信息能够开发配置成模拟患者生理机能的各个方面的特定患者特定模型。该系统的另一个软件模块配置成经由该计算机访问软件工具，所述软件工具将根据数据收集协议所收集的患者特定数据应用于患者特定模型以从中确定患者特定疗法。

Description

用于根据对患者生理机能进行建模而开发患者特定疗法的系统和方法

技术领域

本发明一般涉及慢性病管理，尤其涉及一种用于根据对患者生理机能(physiology)进行动态建模而开发用于慢性病管理的患者特定(patient specific)疗法的计算机化系统及其方法。

背景技术

在传统上，疗法/治疗基于单一的临床测试和测量设备来诊断疾病或病症(ailment)。利用这种试验和设备在极大程度上是为了获得单一的质量测量。这种测量提供快照。但是，为了理解疾病的系统动态学和根本的系统特性，需要一系列的测量。

一系列的测量显然产生更多的数据。但是，将这种数据转变成可发生作用的(actionable)信息未必总是很容易的。事实上，对于识别能够解决什么问题以及需要什么先决条件以便使得连续测量或频繁测量所提供的更充足的数据在医学实践中是有用的，这远非无足轻重的任务。此外，医药公司执行如下任务，即表征药品代谢活动并确定药品用量方案的任务。一般而言，医药公司进行精心制作的临床试验来确定对于目标群体的药力和药效。但是严格来说，一种药品的药物代谢动力学和药效学是患者特定的。基于群体的方法对于确定用于诸如糖尿病患者的病症的药物是不太理想的，其中由于这种慢性病的变化性致使每天都要使用胰岛素药品。在这种情况下，正常情况由从业的保健专业人员从给定的准则开始而对定量给药方案(dosingschema)进行细微调整。通常，保健供给者在患者帮助下执行(follow)受控监视和胰岛素用量调整方案。

最普遍的糖尿病形式是由于胰岛素分泌减少而引起的糖尿病(1型糖尿病，最先认识的形式)，或者是由于体组织对胰岛素的敏感性降低而引起的糖尿病(2型慢性糖尿病，最普通的形式)。前者的治疗需要胰岛素注射，而后者一般用口服药物来控制，并且仅仅在口服药物不起作用的情况下才需要胰岛素。使糖尿病的损害作用加速的其他健康问题是吸烟、胆固醇水平升高、肥胖、高血压和缺乏规律的锻炼。因此，患者了解治疗和参与治疗应当是重要的，因为血糖水平连续不断地发生变化。

控制葡萄糖是减缓葡萄糖对器官的损害作用的最好方法。常规疗法(CT)、增强的常规疗法(ICT)，以及用于泵用户(pump user)的增强的常规疗法(CSII)是控制葡萄糖所使用的常见方法。这些治疗方法的局限性在于其未使用考虑患者特定因素的工具，所述患者特定因素如生理变化性、代谢差异，以及压力、锻炼、患病和进餐的影响。

葡萄糖浓度是正常情况下为正常血糖控制而测量的主要参数(例如，为了提供血液中葡萄糖的正常水平)。其他可用于确定更好的治疗的信息涉及由各种活动所引起的代谢负担，所述活动如摄取食物、进行身体活动、与工作有关的压力，等等。胰岛素输送、其他药物等等正在进一步调整目标生理参数的机制。依据葡萄糖测量、胰岛素敏感性、胰岛素与碳水化合物之比、基础胰岛素率(basal insulin rate)以及诸如压力水平和锻炼效果的其他因素来规定治疗规则。除了葡萄糖测量之外，目前的方法基于无科学依据的、经验规则来确定这些参数，并且基于葡萄糖测量进行反复的评估。

鉴于上面的内容，在为了处理糖尿病患者日常生活需要的当前临床方法中存在严重的缺陷。还没有单独的解决方案将各种可用的方法结合在一起。到目前为止所提供的这些方法没有直接地评估患者特定需要；相反，在一段时间内通过反复实验来处理这些特定需要。此外，在本领域中简单地将各种可用的方法结合起来并没有实现所希望的效果。每种方法都存在特定的要素(element)，必须进行开发并为整个过程进行调整从而具有所希望的安全、准确度和稳健性的水平。此外，所希望的是，当为这种慢性疾病和/或慢性病设计疗法时，为保健从业者提供用于收集随时间的患者特定信息并将所收集的信息应用于动态患者特定模型的工具。

发明内容

本发明可以包括在随附的权利要求中列举的一个或多个特征，和/或下面这些特征及其组合中的一个或多个。

在一个实施例中，公开了一种由用户使用的用于为患者的慢性病管理而开发患者特定疗法的计算机化系统。该系统包括：数据收集模块，其使该系统能够根据数据收集协议而收集患者特定数据，并且对该患者特定数据进行完整性和质量检查；用户接口，其使该用户能够从该系统提供的多个患者模型中选择患者模型；模块确认模块，其使该系统能够确认选择的患者模型；分析模块，其使该系统能够将该患者特定数据应用于选择的患者模型以提取有用的患者特定生理信息，并且利用提取的患者特定生理信息来开发用于医治该患者的慢性病的一个或多个患者特定疗法；结果确认和呈现模块，其使该系统能够确认该一个或多个患者特定疗法并且能够在该用户接口上呈现经确认的一个或多个患者特定疗法中的那些疗法以求批准。

在另一个实施例中，公开了一种基于对患者特定生理机能的动态建模而开发患者特定疗法的计算机化系统。该系统包括计算机，其配置成提供对至少一个数据库或其他存储单元中存储的许多软件模块进行访问。这些软件模块包括：第一软件模块，其配置成经由该计算机提供对一个或多个数据收集协议进行访问，所述数据收集协议限定了至少一类待收集的患者特定数据和收集患者特定数据的方式；第二软件模块，其配置成经由该计算机提供对用于开发一个或多个患者特定模型的信息进行访问，所述患者特定模型配置成模拟该患者的一个或多个方面的生理机能；第三软件模块，其配置成经由该计算机提供对一个或多个软件工具进行访问，所述软件工具将根据一个或多个数据收集协议而收集的患者特定数据应用于一个或多个开发的患者特定模型，以便从中确定一个或多个患者特定疗法；以及第四软件模块，其配置成经由该计算机提供对一个或多个软件确认工具进行访问，其确认这些患者特定疗法，并且在该计算机上呈现该一个或多个患者特定疗法。

在又一个实施例中，公开了一种在计算机化系统上为患者的慢性病管理而开发患者特定疗法的计算机实现的方法。该方法包括：提供数据收集模块，其使该系统能够根据数据收集协议而收集患者特定数据，并且对该患者特定数据进行完整性和质量检查；提供用户接口，其使该用户能够从该系统提供的多个患者模型中选择患者模型；提供模块确认模块，其使该系统能够确认选择的患者模型；提供分析模块，其使该系统能够将该患者特定数据应用于选择的患者模型以提取有用的患者特定生理信息，并且利用提取的患者特定生理信息来开发用于医治该患者的慢性病的一个或多个患者特定疗法；提供结果确认和呈现模块，其使该系统能够确认该一个或多个患者特定疗法并且能够在该用户接口上呈现经确认的一个或多个患者特定疗法中的那些疗法以求批准。

在再一个实施例中，公开了一种用于根据在计算机上对患者特定生理机能进行动态建模而开发患者特定疗法的计算机实现的方法。该方法包括：将该计算机配置成提供对至少一个数据库或其他存储单元中存储的许多软件模块进行访问；将第一软件模块配置成经由该计算机提供对一个或多个数据收集协议进行访问，所述数据收集协议限定了至少一类待收集的患者特定数据和收集患者特定数据的方式；将第二软件模块配置成经由该计算机提供对用于开发一个或多个患者特定模型的信息进行访问，所述患者特定模型配置成模拟该患者的一个或多个方面的生理机能；将第三软件模块配置成经由该计算机提供对一个或多个软件工具进行访问，所述软件工具将根据一个或多个数据收集协议而收集的患者特定数据应用于一个或多个开发的患者特定模型，以便从中确定一个或多个患者特定疗法；以及将第四软件模块配置成经由该计算机提供对一个或多个软件确认工具进行访问，其确认这些患者特定疗法，并且在该计算机上呈现该一个或多个患者特定疗法。

附图说明

本发明的这些和其他特征和优点将根据下文结合附图所描述的本发明各个实施例而得到更充分地理解。

当连同下面的附图一起阅读时能够最好地理解本发明各个实施例的详细说明，其中同样的结构用同样的附图标记来表示，在附图中：

图1是可以传送信息的、用于捕获患者活动并参与胰岛素疗法的各种糖尿病管理实用工具/设备的框图；

图2是说明根据本发明用于根据对患者生理机能进行动态建模而开发患者特定疗法的诊断、疗法(Therapy)和预后(Prognosis)系统(DTPS)的实施例的框图；

图3是图2的系统中使用的软件实施例的框图，其示出了根据本发明的功能模块部分；

图4是根据本发明用于开发患者特定疗法的过程的一个说明性实施例的流程图；

图5是图2的系统中使用的软件组件的框图，该软件组件为了开发根据本发明实施例的患者特定疗法而提供自动胰脏(Pancreas)系统(APS)；

图6是根据本发明实施例的在图2的系统中使用的软件组件、设备和相互作用的框图，该软件组件、设备和相互作用使得图5的软件能实现为闭环系统，该闭环系统利用葡萄糖测量来基于患者特定疗法而提供适当的控制作用(control action)；

图7是根据本发明实施例的在图2的系统中使用的软件组件、设备和相互作用的框图，该软件组件、设备和相互作用使得图5的软件能实现为闭环系统，该闭环系统基于患者特定疗法而提供适当的控制作用；

图8和9是显示出根据本发明的经验算法实施例的模块执行序列的过程流程图；

图10是显示出在某天的不同时间的胰岛素和葡萄糖之间的设定点关系的图表；

图11和12是用图表显示出根据本发明分别为第一和第二处理函数选择时间间隔的绘图；

图13是显示出不同葡萄糖区域场景(scenario)的一对图表；

图14是显示出用于速效(fast-acting)的碳水化合物摄入的葡萄糖推进的图表；

图15是显示出对于随时间的速效的碳水化合物刺激作出相应的血糖的图表；

图16是根据本发明的修正(rectification)模块的处理图；

图17是显示出保持药效学的胰岛素的图表；

图18是显示出单位丸剂(bolus)的胰岛素随时间变化的图表；

图19是显示出胰岛素脉冲预测的图表；

图20是显示出由根据本发明的算法所使用的定时描述的图表；

图21是作为例子提供的用于说明根据本发明的模型参数标识的图表；

图22描绘了用于根据本发明的自动胰脏控制算法测试套件(Automated-Pancreas Control Algorithm Test Suite，APCATS)软件的图形用户接口，其实现在开发患者特定疗法的图2的系统上；

图23是显示出根据本发明的APCATS软件的模块框之间的连接以及在框之间的信息流的框图；

图24描绘了根据本发明的提供用于改变用于模拟环境的患者模型参数的器件(plant)菜单窗口的图形用户接口；

图25描绘了根据本发明的提供用于模拟环境的失效菜单窗口的图形用户接口；

图26描绘了根据本发明的提供用于模拟环境的事件入口表单(event entry form)的图形用户接口；

图27描绘了根据本发明的提供用于模拟环境的选择饮食/累积锻炼表单的图形用户接口；

图28描绘了根据本发明的提供用于模拟环境的连接端口表单的图形用户接口；

图29描绘了图22的图形用户接口的运行/存储窗格(Run/Storepane)部分，其提供了用于加载数据、保存数据和运行模拟的基本功能；

图30描绘了根据本发明的提供用于模拟环境的模拟参数表单(Simulation Parameters form)的图形用户接口，其允许用户设定模拟的起始时间和停止时间、选择积分例程(integration routine)和步长，并运行该模拟；

图31是图22的图形用户接口的曲线图窗格(Plot pane)部分，其允许用户将实验数据绘制在屏幕上或者作为硬拷贝；

图32描绘了根据本发明的提供用于模拟环境的启动入口表单(Start-up Entry form)的图形用户接口；

图33是根据本发明实施例的软件组件的运行序列的过程流；

图34是显示出根据本发明实施例的控制时期的图表；以及

图35描绘了根据本发明实施例的相对于算法调用更新变量(variable)。

具体实施方式

通常，本发明是通过以下来帮助分析如糖尿病、哮喘和心脏病(其实质上是慢性的)的疾病的医治和管理的计算机架构和过程：即通过分析动态系统中个体的人体生理机能和代谢活动，并且使用户能够定义协议、分析所收集的数据、细微调整疗法需要并提供患者特定的诊断、治疗意见和预后。尽管在这里讨论本发明是依据帮助一个患者来进行的，但是应当理解本发明可以用于帮助多个患者。

在一个实施例中，本发明通过测试所提出的解决方案并提供在其周围的置信区间来增强治疗结果。在一些情况下，所提出的解决方案是专门的协议，用以特别处理表征和/或效果的控制，或者在一些情况中是多个效果的控制。代替利用基于群体的规则来解决该问题，本发明的方法从开始就假定一种患者特定的疾病状态，根据该患者特定的疾病状态使疗法适应患者的代谢、生理和生活方式的考虑。

在一个实施例中，本发明提供一种系统工具，其直接处理对于确定患者特定胰岛素疗法的需要。应当理解，本发明的过程可适用于开环、闭环和半闭环系统，并且能够适合于各种葡萄糖测量方法和各种胰岛素输送方法。在其他实施例中，本发明可适用于需要持续的药品疗法的慢性病症。

本发明利用生理模型、代谢模型以及数学来根据药品的药物代谢动力学和药效学以及关联参数来确定药品剂量。本领域技术人员理解药物代谢动力学是对于药品的吸收、分布、代谢和排泄的研究，而药效学是对于药品的生物化学效应和生理效应及其作用机制以及药品浓度对药效的相关性的研究。在一个实施例中，本发明将药效学的方法计算机化从而对输入数据起作用，并且本发明提供作为输出的药物代谢动力学与药理效果之间的关系，如或者是相反的或者是所希望的。

本发明帮助用户理解各种生理状态的药理效果，并帮助诊断疾病、改善疗法，并且不仅允许开发患者特定的疗法，而且允许开发比现有疗法更严谨的疗法。本发明的系统及其方法进一步扩展成为个人的慢性疾病提供预后。

在一个实施例中，从一般的输入入口和/或一般的输出入口的观点来看本发明公开了一种装置，其用于接收/命令(i)设备，(ii)算法和(iii)通知用户结果的信息/可发生作用/警告。事件信息可以是一种连续的更新或者以不连续的方式发生。因此，事件是一种事务(transaction)。该方法还描述了能够生成疗法的算法结构。

在另一个实施例中，本发明公开了一种利用所收集的葡萄糖数据和其他可用信息来合成患者特定模型并用其确定疗法参数的方法。该过程可以包括(1)标识患者特定模型和(2)定义各种生理参数。所标识的模型是模拟的，或者应用特定的分析工具来满足这些生理参数的定义以便推断出它们的值。因为已确定的参数是从患者特定模型得出的，因此，这些参数是患者特定的。

在另一个实施例中，本发明进一步使用户能够进行各种分析，包括经由模拟来评估关键场景(critical scenario)，从而确保稳定和稳健的解决方案，其满足诸如ADA准则的要求和/或将例如HbAlC的关键参数保持在对象的所希望的目标范围内。

本发明因此使执业医生能够利用工具来帮助分析患者的特性行为并反过来利用该分析来确定疗法、检查治疗结果并理解患者特性。本发明是一种集成系统，其容纳各种系统组件-患者数据存储器、数学分析工具、数据呈现方法，与外部设备的集成、数据顺从性(datacompliancy)技术、为稳定性和稳健性而测试的治疗方法-其共同提供一种用于诊断、疗法确定以及糖尿病患者的预后的优质方法。下面利用糖尿病作为实例更详细地阐述本发明。特别是，现在讨论有关本发明所使用的测量、分析和其他信息。

测量和分析

如已知的，糖尿病是一种代谢综合症，其中身体的生理机能因各种病因而不能正常地发挥作用来调节血糖。为了管理这种疾病，有许多用于捕获患者活动并参与胰岛素疗法的糖尿病管理输入装置、实用工具和设备。例如，图1是用于管理糖尿病的典型的疾病管理组件的图示，这些组件需要相互作用并且交换用于确定和评价所规定的胰岛素疗法的疗效的信息。这些疾病管理组件包括：个人计算机、用于数管理的集中式数据库、提供用于根据用户输入、葡萄糖测量和胰岛素输送的量而管理泵输注(pump infusion)的过程(procedure)的算法，经由用户接口的用户输入、测量、测试等，经由用户接口的保健专业人员(HCP)的输入、测量、测试；以及智能胰岛素泵、智能血糖(bG)仪，和其他手持设备，其或者可以是集成的设备或者可以是独立发挥作用的独立的设备。一般来说，这些疾病管理组件相互作用从而彼此交换信息，在图1中用箭头示出。当通过与这些组件相关联的/由这些组件提供的程序进行功能调用时并且一般是与输入/输出变元一起调用时，这种信息(数据)交换是常规的要求。这些变元表示结构内容，并且理想情况是，至少该设备的所有疾病管理组件应当理解这种结构及其潜在的/实际的内容。然而，在这种系统中，通知各种组件已经发生了事件是一个问题。事件是由一个组件所生成的信息的单元，其能够被另一个组件使用(例如bG测量、低血糖事件、高血糖事件值、用量调整、协议变化、算法变化等)。特别是，该问题存在于提供信息结构中，所述信息结构从使用这些疾病管理组件的一大组使用案例中捕获必要的信息。其他问题在于当管理诸如糖尿病的慢性疾病时信息的交换是时间关键以及内容关键的。而且，交换的信息必须是可由这些设备使用来作机器解释以及可由人使用来作人类解释的。

交换信息的特性是另一个问题。例如，在管理慢性疾病中要如下注意信息的特性。时间具有许多变化，例如事件发生的时间、一个事件相对于另一个事件而出现的时间，以及该事件能够持续多长时间。事件本身具有特性，并且需要下面的方面-触发了什么事件、该事件的强度或大小是多少。事件可以由在指定时间发生的事情(occurrence)或者随着指定作用的相应大小的连续发生的事情而组成。一旦事件已经启动能否将其转为OFF，或者更一般的问题是能否在删除的特定情况下来修改前一个事件。还需要知道事件的频率。如何在同步调用或异步调用的情况下触发该事件。本发明解决了这些问题，如在下文提供的讨论中是显而易见的。

生理参数的测量形成DTPS的主干(backbone)。例如，存在许多容易测量的参数，如体温、血压、体重等。其他参数可以从精心制作的实验室测试中提供，如用于识别特定成分的血样测试、尿分析以及为了识别微生物而进行的培养，等。然而，测量任何生理参数都存在限制。例如复杂和昂贵的装置会限制例如从像HbAlC或胰岛素测定之类的测试所提供的信息的可用性。关于影响人体生理机能的活动的定量和/或定性信息可能会失真，所述活动如锻炼、食物摄入(即，碳水化合物的摄取)，以及压力。而且，这些参数可能作为效应来显现，其以ON/OFF表示而不是用数量表示。此外，所期望的是，由于各种限制因素可以不必严格地获得定量信息。还存在技术的限制，例如由于在访问生理参数中的身体或伦理的限制而不能进行测量，如糖质新生或消化道葡萄糖吸收的量。此外，诸如生物利用率和药效的数学构造的参数在正常情况下是基于群体的，对于特定个别患者可能没有足够特定。

对于糖尿病护理来说，正常情况下利用葡萄糖仪获得的葡萄糖测量是实施疗法管理的主要参数。对于管理糖尿病还存在几个相关的次要参数，如HbAlC、酮和FFA。然而，这些测量并不需要是有规律的。另外，还存在关于对调整和校正疗法很重要的活动(如食物消耗和锻炼的量和执行率)有关的信息。本发明能够帮助分析患者特定需要，采用有关测量和分析的这些数据来建立模型，利用该模型来估计(estimate)不能直接测量的生理参数，并且表示患者的基本生理机能和代谢。本发明还允许在这些生理参数持续发展时将其可视化，从而使用户可以理解慢性疾病的基本的动态行为。本发明的这种分析和可视化能够更好地理解该系统(糖尿病患者)的工作方式，并且能够帮助保健供给者进行诊断、疗法确定和预后。因此，本发明增强了保健提供者对于分析数据、诊断疾病、确定疗法以及得出疗法的预后的能力。为了帮助说明本发明的实用性，下文提供了下面的实例。

为了对个人的糖尿病进行测试，常用的协议要求该个人至少禁食8小时。测量禁食期的葡萄糖，然后该个人要经受口服葡萄糖耐量测试，这需要摄入浓缩的葡萄糖饮料，随后在正常情况下以2小时为疗程进行几次葡萄糖测量。基于收集的数据来确定对糖尿病的诊断。使用频繁或连续的数据提供了优于使用稀疏测量的如下优点：能够绘制数据的图表从而可视化图案和趋势；能够利用数据来预测或预期测量的变化；以及能够利用数据来建立模型并表示基本的药物代谢动力学和药效学。一般而言，利用明确规定的协议来收集上面提及的数据。本发明的方法包括下面几方面。收集患者特定数据来支持本发明的诊断、疗法和预后工具。所提出的数据分析已经考虑到这些协议是分析特定的，并且每种协议都专门用于识别或确定疾病的特定方面(因果关系)。所提出的数据分析用来最佳地量化患者的疾病系统如何工作并且用来识别患者特定参数。接着，本发明定义患者的疾病系统动态行为，其已经考虑到基于群体的研究表示平均效应，不一定解决患者特定需要。本发明还考虑尽管对于理解动态系统如何运转所需的原理在特定情况下可能是没有疑问的，但是对于期待个人在精神上进行关键的数学分析是不合理的。

例如，药物，特别是每天使用的和/或有规律地需要的药物与诸如锻炼的活动、压力、不同的食物以及其他药物的活动相互作用，所有这些都可能对该药物的效应具有相当大的影响。后面章节中描述的本发明的系统工具做出了确定这些效应的数学方面，其帮助保健供给者评价该效应并量化该效应。可以将这些效应进一步转变成对于给定效应而选择相应疗法的药物方案。可以利用这些效应来预测该效应的影响并帮助产生警告和报警。下文的描述解释了本发明的系统(装置)和方法。

整体系统

利用上面在思维中的测量和分析，DTPS是一种硬件-软件系统，其在PC平台上运行的典型的客户端-服务器环境中工作，并且在图2的框图中示出。整个系统被想像成是在地理上分布的，并且可经由内联网和/或互联网装置来访问。在一个所示的实施例中，系统10提供服务器计算机12和客户端计算机14。服务器计算机12包括常规的处理器16，其连接到输入设备18、监视器20和存储器22(例如RAM、ROM和(多个)硬盘驱动器)。输入设备18可以是常规的键盘、常规的点击(point-and-click)设备、麦克风等的任一种或其组合，监视器20可以是任何常规的计算机监视器。服务器计算机12的处理器16也可以在工作中连接到数据库24，该数据库在服务器计算机12内部，或者可替换地在服务器计算机12外部。服务器计算机12的处理器16还连接到常规的通信接口26。

客户端计算机14同样包括常规的处理器34，其连接到常规的监视器36、常规的存储器38(例如RAM、ROM和(多个)硬盘驱动器)，以及常规的输入设备40，该常规的输入设备40可以是常规的键盘、常规的点击设备、麦克风等的任一种或其组合。可替换地，在这些实施例中，输入也可以是经由监视器36的，其中监视器36包括一个或多个触摸屏按钮或开关。客户端计算机14还可以包括一个或多个常规的扬声器42，其连接到处理器34。客户端计算机14的处理器34还连接到设备接口46，其配置成在工作中或者是无线地或者经由有线连接而连到一个或多个外部设备。

在一个实施例中，例如设备接口46可以是或者可以包括常规的输入/输出端口，其配置为有线连接到外部设备。这种常规的输入/输出端口的例子包括但不应当限于常规的通用串行总线(USB)端口、常规的RS-232端口等。可替换地或者另外，设备接口46可以是或者可以包括常规的无线收发器，其配置成与外部设备的类似的收发器进行无线通信。这种无线收发器的例子包括但不应当限于红外线(IR)收发器、射频(RF)收发器、感应收发器、声收发器等。

客户端计算机14的处理器34经由设备接口46向外部设备48提供信息或者接收来自外部设备48的信息，外部设备48如以患者数据测量和/或收集设备的形式。患者数据测量和/或收集设备48的例子可以包括但不应当限于血糖或组织葡萄糖传感器或者其他葡萄糖测量设备、体温感测或测量设备、体重测量设备、血压监视设备、HbAlC监视设备、可植入的或外表耐磨的药品输注泵(drug infusion pump)、用于监视患者膳食摄入数据、患者锻炼数据、患者生病数据等的手持或其他数据收集设备等，所述药品输注泵例如用于胰岛素或者一种或多种其他降低或升高血糖的药品的管理(administration)。

客户端计算机14的处理器34还在工作中连接到常规的通信接口32。通信接口26和32可以是任何常规的通信接口，其提供在服务器计算机12和客户端计算机14之间的电子通信。在所示的实施例中，例如通信接口26和32配置成以常规的方式经由环球网(WWW)、互联网和/或内联网而提供在服务器计算机12与客户端计算机32之间的电子通信。可替换地或者另外，通信接口26和32可以是或者可以包括电话调制解调器，从而使服务器计算机12与客户端计算机32可以经由电话进行通信。这一公开内容可以设想，可替换地可以经由其他常规的有线或无线通信链路来实现在服务器计算机12与客户端计算机14之间的电子通信。在任何情况下，应当理解，系统10可以包括多个联网服务器计算机12，其可以是在地理上分布的或者可以不是在地理上分布的，每个服务器计算机12可以为多个客户端计算机14服务，这些客户端计算机14可以是在地理上分布的。此外，根据使用案例场景，本发明的过程(即软件部分)可以配置在客户端侧或者服务器侧，这在后面进行讨论。

软件部分

参考图3，图中示出了根据本发明且由图2的系统10所用的软件50的一个说明性实施例。软件50被理解成按照常规的方式来配置，从而允许在客户端计算机14与服务器计算机12之间的适当的交互作用，以进行用户验证、获取在数据库中的数据和/或在数据库中存储数据，以及实施辅助活动，如数据的后台处理、触发事件的自动化等。在所示的实施例中，软件50包括操作系统和网络协议部分52、核心应用程序部分54以及功能模块部分56。操作系统和网络协议部分52按照常规的方式配置成允许在各种计算机、设备和/或数据库之间发生交互作用。核心应用程序部分54和功能模块部分56分别可以驻留在服务器计算机12上、客户端计算机14上或者至少部分在两者上。

通常，核心应用程序54包括许多常规的软件算法和其他常规的数据管理软件，其可从市场上买到。作为一个特定实例，核心应用程序54可以包含常规的数学软件包。通常，这种核心数学工具包括一个或多个优化工具、一个或多个统计分析工具、一个或多个模拟工具、一个或多个灵敏度工具、一个或多个可视化工具，以及一个或多个用于提取信息的工具(如常规的模式识别工具、包络识别(enveloprecognition)工具等)。特定的例子包括但不限于LAPACK、线性代数包、IMSL(独立媒体解决方案有限公司(Independent MediaSolutions Limited))软件工具和软件库、OPTIMA客户端/服务器工具、STATS统计工具、图象呈现工具等中的任何一个或多个。数据库组织和安全软件算法，特别是用于所收集的患者数据的数据库组织和安全软件算法是常规的软件算法和其他常规的数据管理软件的其他特定例子，所述常规的软件算法和其他常规的数据管理软件可以包含在核心应用程序部分54中。这种数据库组织和安全软件算法通常确保例如HIPAA顺从性(compliance)、数据完整性、安全和验证，以及与其他系统应用程序的互用性。常规的用于支持各种数据库活动的驱动器和/或用于与各种电子数据管理/收集设备48(参见图2)发生交互作用的驱动器是常规的软件算法和其他常规的数据管理软件的另一个特定例子，所述常规软件算法和其他常规数据管理软件可以包含在核心应用程序部分54中，也可以包含在一种或多种常规的网络浏览器中从而与各种计算机、数据库和适当网站进行交互。这种常规的网络浏览器的例子可以包括但不应当限于Internet Explorer、Netscape、Mozilla、Opera、Lynx等。要理解，核心应用程序部分54可以包括更多或更少的软件算法和/或数据管理软件，并且上面的例子仅仅是为图解说明的目的而提供的，不应当被认为以任何方式限制本发明。

功能模块

如图3中所示的，在所示的实施例中，功能模块部分56包括数据收集协议块70、患者模型模块72、模型确认模块74和分析模块76，所有这些模块都连接到规则/准则集模块78。功能模块部分56还包括设备驱动器管理模块以及结果确认和呈现模块82。作为说明，功能模块部分56用来管理数据、查询数据、存储和检索数据，向位于核心应用程序部分54中的数学包和库提供调用例程，提供用于分析数据的例程以及用于以文本和图表形式呈现数据的图形例程，并且提供用于与各种外部设备48通信的驱动器。可替换地或者另外，功能模块部分56可以配置成执行更多或更少的功能。

为了通常为疾病特别是为慢性病开发患者特定疗法，特别是要收集与该患者有关的数据。通常，待收集的患者特定数据的类型和要收集的方式取决于许多因素，这些因素包括但不限于，正在进行开发的疗法所针对的特定疾病、该疾病的严重程度、治疗解决方案的类型和可用性、该患者的年龄、体重和性别、该患者的一个或多个个人习惯，如患者遵守严格的饮食时间表和/或有规律地锻炼、遵守一个或多个可用的治疗时间表的倾向等。数据收集协议模块70包含多个不同的数据收集协议，每一个都被设计成按照特定方式对待收集的一种或多种特定类型的患者特定数据进行收集。更明确地说，数据收集协议模块70中包含的每个数据收集协议都规定了待收集的数据、数据被收集的方式(即进行数据收集的方式)、对数据收集协议的任何限制、要在收集该数据中所用的任何电子的或其他的专用工具和/或设备，以及确保和/或提高所收集的数据的质量的任何防护措施和/或数据收集技术。作为说明，根据各种数据收集协议中任一种来收集的患者特定数据都存储在数据库24中(图2)，虽然可替换地可以将所收集的一些数据或所有数据存储在一个或多个其他数据库和/或存储单元中，所述其他数据库和/或存储单元可由服务器计算机12和/或客户端计算机14进行访问。

数据收集协议模块70中存储的每个数据收集协议都为特定目的而定义，并且包括为实现至少一个特定目的而已经进行测试和评价的数据收集方案，只要满足常规的数据顺从性和完整性检查。为此，每个数据收集协议都可以包括或者可以使用例如数学模块形式的数据顺从性过程，其检查所收集的数据中的不一致性，并且检查为已经收集的特定数据而规定的要求。这种要求的例子包括但不限于时间戳一致性、(多个)数据值范围、(多个)日期范围等。另外，每个数据收集协议可以包括或者可以使用例如数学模块形式的数据质量过程，其检查所收集的数据在其性能和/或统计属性方面的质量。

规则/准则集模块78提供规则集，这些规则集根据在数据收集协议模块70中可用的各种数据收集协议来控制对患者特定数据的收集。另外，规则/准则集模块78根据各种数据收集协议而提供用于收集患者特定数据的准则。这种准则可以提供例如但不限于各种数据收集协议的计算机可读描述、关于什么时候即在什么情况下使用一个或多个特定协议或者什么时候不使用一个或多个特定协议的指导、使用协议的优点和/或缺点、通过使用协议可实现或不可实现的目标、协议的限制或协议适用性的限制等。

通常，针对数据收集协议模块70中的任一种数据收集协议而收集的数据可以利用各种常规的技术以各种方式来收集。例子包括但不限于利用一个或多个常规的测量设备而对一个或多个患者特定状态进行的测量、患者所经受的事件或条件等。利用这里描述的任何一个或多个电子设备48可以使患者特定数据的测量对于客户端计算机14是可用的。另外或者可替换地，利用常规的电子或非电子的测量设备和/或系统可以进行患者特定数据的测量，并且利用输入设备40可以将结果手动地录入或输入到客户端计算机14中，所述输入设备40例如键盘、点击设备、麦克风或其他常规的输入设备或机构。患者所经受的事件或条件可以包括但不限于例如正餐和加餐的摄入、锻炼、生病、压力等。经由一个或多个电子设备48和/或利用一种常规输入设备经由手动输入使客户端计算机14可使用这种信息。

在数据收集协议模块70中可用的数据收集协议的例子包括但不限于一个或多个数据收集协议，所述数据收集协议提供收集作为时间的函数的患者血糖或组织葡萄糖测量、收集作为时间的函数的患者体温测量、收集作为时间的函数的(在患者身体周围的)环境温度测量、收集作为时间的函数的患者心率和/或脉搏率、收集作为时间的函数的患者血压、收集诸如体重、月经、压力、生病等一个或多个其他的患者生理状态参数、收集作为时间的函数的正餐或加餐即碳水化合物摄入的信息、收集作为时间的函数的患者身体活动、收集随时间的胰岛素输送信息、收集作为时间的函数的干预(intervention)信息、收集作为时间的函数的患者就诊和/或看病，收集与膳食摄入、运动性能等中的一个或多个有关的特定信息、利用专门的仪器和/或设备、利用纸件拷贝、电话呼叫、用于交换和/或记录信息的互联网通信等的一个或多个。

为了说明的目的将图2的系统10设计成以人类为目标，尽管由该公开内容可以设想将其他动物作为目标的系统10的实施例。通常，人类所表现的一些行为特性是物种所共有的，而其他的个体行为特性取决于其他因素，如性别、年龄、种族等。人类生理行为的模型可以构造为人体生理机能的数学表示，并且可以说明性地依照微分方程式来定义。这种患者模型可以进一步开发成对于所有患者通常是相同的但也预先考虑行为的变化性。在这些情况下，模型参数将会具有患者特定的值。

患者模型模块72(图3)使多个这种患者模型是可用的，这些患者模型配置成在数学上对人体生理机能的一个或多个方面进行建模，且该患者模型模块提供对不同生理状态、情况和/或参数的映射。例如，患者模型模块72可以对人体内葡萄糖吸收进行建模，而一个或多个其他模型可以对使用胰岛素(或其他葡萄糖升高或降低的药品)的一种或多种效应进行建模。患者模型模块72可以包括竞争模型，其配置成建立相同的生理方面的模型，每个这种模型可以具有对于定义特定模型参数、对于收集与患者有关的数据、和/或对于分析特定数据的某些优点或缺点。在这点上，规则/准则集模块78可以包括涉及对特定生理方面、对于特定患者类型(例如年龄、性别、种族等)和/或使用场景而言一个模型优于另一个的特定适用性或不适用性的规则和/或准则、涉及对使用任何特定模型的限制的规则和/或准则、涉及对建模工作可能是在开发过程中的来源的链接的规则和/或准则等。一个或多个模型还可以包括附加的使用案例信息。经由患者模型模块72可用的多个不同的患者模型允许模型和/或模型的参数到特定的生理状态、情况或参数的映射。

这些患者模型可以直接由患者模型模块72从便携式存储设备44、计算机存储器38和/或计算机可读介质进行存储和/或访问，所述计算机可读介质例如光盘、数字视频盘等。这些患者模型可以间接地由患者模型模块72从连接到服务器12的数据库24或其他存储单元和/或因特网30进行访问和/或存储。例如，数据库24或其他存储单元可以包括模型类型和/或结构以及相关的到文献和/或其他有关技术文件的链接的数据总库。可替换地或者另外，数据库24或者其他存储单元可以包括例如示踪研究的临床试验结果和/或相关的到涉及这种临床试验的信息的链接的数据总库，根据其可以获得基本的模型结构。在任一种情况下，可以通过经由患者模型模块72访问与一个或多个适合的患者模型的结构、参数和/或开发有关的信息而直接地或间接地访问该一个或多个患者模型。因此，通常，患者模型模块72可以包含一个或多个已开发的患者模型，该患者模型对于人体生理机能的一个或多个特定方面来说是特定的，和/或该患者模型可以包含信息，根据该信息可以定位、确定和/或开发一个或多个这种模型。该一个或多个已开发的患者模型可以是或者可以包括一个或多个专有的患者模型(即由特定的人和/或实体开发并且在其使用中受这个人和/或实体限制)，和/或一个或多个商业上或以其他方式公共渠道可买到的患者模型(即从一个或多个第三方买到的)。

当利用患者模型模块72选择了特定模型时，那么必须确定模型参数的值。为了确定模型参数的值，患者模型模块72还可以包括一个或多个子模块，该子模块提供确定这些模型参数。该一个或多个参数确定子模块的例子可以包括但不应当限于用于识别模型参数的一个或多个子模块、用于提供输入、输出、状态和/或参数描述的一个或多个子模块、用于确定参数范围的一个或多个子模块、用于确定模型参数灵敏度(例如模型参数增益值(gain value))的一个或多个子模块、用于提供先前开发的、推导的或定义的模型参数的一个或多个子模块等。

用于识别模型参数的一个或多个子模块可以采用数据拟合(fitting)技术，其隐含地或明确地确定参数值。这种子模块的通常的例子包括但不将其限制为提供以下内容的子模块：用于提供初始猜测并提供参数估计的先验分布的贝叶斯(Bayesian)分析、用于求出参数估计(后验分布)的成本函数(cost function)、统计分析、数值分析、用于范围分析的迭代/非迭代技术、增益值分析、测试场景分析、建模，以及提供预先知道的参数描述(输入、输出、状态等)、范围和灵敏度(例如增益值)的那些子模块。可替换地或者另外，用于识别模型参数的一个或多个子模块可以规定用于识别这些模型参数的过程或框架(framework)。一个这种模型参数识别过程或框架的例子(不应当被认为以任何方式被限制)是：i)提供模型参数和这些参数的初始猜测，ii)如果遵循贝叶斯方法，那么提供参数估计的先验，iii)设立、选择或使用特定的成本函数，iv)选择或利用特定的成本函数求解技术或框架，以及v)迭代地或非迭代地求出该模型参数估计。

用于确定参数范围的一个或多个子模块可以采用统计、数值、迭代或非迭代技术中的任何一种或多种，用以隐含地或明确地确定一个或多个模型参数的可接受范围和/或确定模型参数变化性。一个或多个这种子模块例如可以利用常规的技术来创建测试场景，所述测试场景代表能够对模型进行测试和估计的模型参数范围。例如，在一个实施例中，本发明可以用于在计算机上定义和实现测试场景，该计算机帮助测试所建议的(recommended)患者特定疗法并对利用所建议的患者特定疗法潜在可能达到的疗法质量进行量化。在其他实施例中，当指定了疗法时，本发明可用于评价该测试场景并且例如利用对生活方式的约束来补充该疗法，所述对生活方式的约束例如进餐数量的限制、限制快速(fast)吸收食物等。

用于确定模型参数灵敏度的一个或多个子模块可以采用一种或多种统计、数值、迭代或非迭代技术来隐含地或明确地确定模型参数增益值。一个或多个这种子模块例如可以使用常规的技术来分析模型参数灵敏度从而评价该模型在一个或多个模型参数范围内的稳定性和/或该模型对模型参数确定中的误差作出响应的稳定性。

特别是对于糖尿病护理来说，利用各种已知的血糖和/或组织葡萄糖测量技术而获得的葡萄糖测量提供主要参数，在该主要参数周围经由常规的糖尿病疗法来设法实现血糖正常控制。本发明的公开内容考虑到其他参数对于管理糖尿病也是相关的，并且可能有规律地或周期地需要或者可能不需要这些参数的动态或静态确定。这些其他参数的例子包括但不限于HbAlC(糖基化的或糖化血红蛋白-可用于识别随时间的血浆葡萄糖浓度的一种形式的血红蛋白)、FFA(游离脂肪酸)、酮体(脂肪酸分解的副产品)等。虽然可以经由参数测量来监视一些这种参数，但是其他参数可能需要经由其他参数测量和适当建模即虚测量而进行估计。还可以利用涉及患者活动的附加信息来修改、调整或校正糖尿病疗法。例子包括但不限于进餐量、消耗频率和/或执行率、锻炼频率、持续时间(duration)和/或负荷、生病频率、持续时间和/或严重程度等。可以设想，经由刚刚描述过的患者模型模块72可用的至少一些患者模型在此结合一个或多个这种生理参数和/或其他信息，从而能够利用该一个或多个模型来估计不能直接测量或者很难直接测量的一个或多个生理参数。最后得到的患者模型能够或者动态地或者静态地监视患者的基本生理机能，如患者的代谢。

功能模块部分56还包括模型确认模块74，其提供访问一个或多个基于计算机的模拟程序，该模拟程序配置成分析患者模型的一个或多个方面。一个或多个模拟程序例如可以存储在数据库24或者其他存储单元中，在这种情况下，该模型确认模块74提供用于访问这种程序的接口。可替换地或者另外，该模型确认模块74可以包含到这些模型确认程序的文献或其他源的链接。在任何情况下，该一个或多个基于计算机的模拟程序通常将在一个或多个特定测试场景下分析所选择的患者模型的操作，并且将这些结果与已知标准、与更广泛群体的数据、与先前分析的模型的结果、与统计学上预期的结果等进行比较。另外，该一个或多个基于计算机的模拟程序可以附加地标记和/或报告该比较的不一致性。作为说明，模型确认模块74提供访问一个或多个基于计算机的模拟程序，该一个或多个基于计算机的模拟程序执行下面任何一种或多种：i)实施与所选择的患者模型有关的基于计算机的模拟，ii)确认所选择的患者模型在一个或多个所指定的工作范围内，iii)为所选择的患者模型提供便于理解工作空间(operatingspace)、限制和误差源的信息，iv)将特定的使用案例应用于所选择的患者模型并分析该模型结果，v)利用以前收集的临床数据来测试所选择的患者模型，等。

模型确认模块74可以包括一个或多个子模块，该子模块提供用于对所选择的患者模型进行评价的特定分析工具。该一个或多个分析工具子模块的例子可以包括但不应当限于用于测试特定使用案例场景的一个或多个子模块、用于在一个或多个指定工作范围内测试该患者模型的一个或多个子模块、用于统计学地分析所选择的患者模型的一个或多个子模块，等。作为说明。用于测试特定使用案例场景的一个或多个子模块可以访问一个或多个软件程序，该一个或多个软件程序按照如上所述的将一个或多个已识别的模型特性与预定标准进行比较的方式来运用该患者模型。作为说明，用于在一个或多个指定工作范围内测试该患者模型的一个或多个子模块可以访问一个或多个软件程序，该一个或多个软件程序在一个或多个指定工作范围内分析该患者模型以确定该患者模型在变化的工作范围和/或条件内模拟基本病患或疾病有多好和/或该患者模型模拟该基本病患或疾病对规定疗法的反应有多好。作为说明，用于统计学地分析所选择的患者模型的一个或多个子模块可以访问一个或多个软件程序，该一个或多个软件程序按照允许确定该患者模型的(多个)解是否代表一个或多个预期的统计属性的方式来运用该患者模型以生成该模型的一个或多个解。

作为说明，规则/准则集模块78可以提供支配一个或多个子模块的操作的规则集，和/或提供准则，该准则涉及一个基于计算机的模拟程序相比于另一个而特别适用或不适用于特定的患者模型、模型类型、模型工作范围和/或使用场景、涉及对使用任一个特定模拟程序的限制、涉及到可以找到相关的基于计算机的模拟程序的源的链接和/或涉及到可能在开发过程中的相关基于计算机的模拟程序工作的源的链接，等。

软件50的功能模块部分56(图3)进一步包括分析模块76，该分析模块访问一个或多个分析工具，至少一些分析工具以一个或多个常规的数学软件包的形式而驻留在数据库24或其他存储单元中，所述数学软件包可经由如在上文描述的核心应用程序部分54而访问。通常的例子包括但不限于一个或多个优化工具、一个或多个统计分析工具、一个或多个模拟工具、一个或多个灵敏度工具、一个或多个可视化工具，以及一个或多个用于提取信息的工具(如常规的模式识别工具、包络识别工具，等)。特定的例子包括但不限于LAPACK、线性代数包、IMSL(独立媒体解决方案有限公司)软件工具和软件库、OPTIMA客户端/服务器工具、STATS统计工具、GRAPHICAL呈现工具等种的人和一个或多个。

分析模块76可以进一步使其他数据分析和/或可视化工具是可用的，其中的一个或多个特别针对设法开发的疗法。任何这种其他分析和/或可视化工具都可以存储在数据库24或其他存储单元中，并且可以直接经由该分析模块76来访问，或者可以在其他地方是可用的并且经由分析模块76通过这种工具的相关链接而间接地来访问。作为说明，可以经由分析模块76来访问的核心数学工具可以包括但不限于i)一个或多个优化工具，ii)一个或多个统计分析工具，iii)一个或多个模拟工具，iv)一个或多个灵敏度工具，v)一个或多个可视化工具，以及vi)一个或多个用于提取信息的工具，例如经由模式识别等。在一个实施例中，分析模块76提供分析工具，该分析工具使该系统能够进行模拟、统计分析、灵敏度分析、可视化、信息提取、优化中的至少一个，并且提供建议(recommendation)，该建议包括定量给药的类型、数量和定时、锻炼以及进餐中的至少一个。在一个实施例中，每个建议都可以包括在当前时间、在将来时间或在由该分析所确定的时间，或者在由最终用户所确定的时间的作用。

作为说明，规则/准则集模块78可以提供支配经由分析模块76可用的一个或多个分析和/或其他工具的操作的规则集，和/或提供多个准则，该准则涉及一个这种工具优于另一个工具而特别适用于或不适用于特定工具、工具类型、对利用任何特定工具的任何限制、涉及对于可以找到相关分析、可视化或其他工具的源的链接和/或涉及可能在开发过程中的关于这种分析、可视化或其他工具的相关工作的源的链接。

利用经由分析模块76可用的工具，可以将根据数据收集协议模块70中的一个或多个协议而收集的患者特定数据应用于一个或多个所选择的患者模型从而提取有用的患者特定的生理信息，该所选择的患者模型是经由患者模型模块72选择并且经由模型确认模块74确认的。然后可以利用该有用的患者特定的生理信息来开发一个或多个用于医治患者特定病患或疾病的疗法。在糖尿病疗法的情况下，例如，经由分析模块76可用的工具可以包括但不应当限于提供提取诸如模型参数值的信息的软件工具、提供对与糖尿病有关的数据进行分析的软件工具、优化软件工具、趋势分析软件工具、提供确定和/或建议基本定量给药和丸剂定量给药的软件工具、提供确定和应用针对诸如低血糖和高血糖的条件进行警告的软件工具、提供开发用以允许与患者有关的数据的患者输入的一个或多个图形接口的软件工具等。

提供开发用以允许与患者有关的数据的患者输入的一个或多个图形接口的软件工具的一个例子记载在共同未决的序号为__的美国申请中，该美国申请的发明名称为PATIENT INFORMATIONINPUT INTERFACE FOR A THERAPY SYSTEM(治疗系统的患者信息输入接口)，并且其代理人案号为ROP0014PA/WP23627US，其转让给本申请公开内容的受让人，并且该美国申请的公开内容在此引入作为参考。另一个例子记载在共同未决的序号为11/297733的美国申请中，该美国申请的发明名称为SYSTEM AND METHOD FORDETERMINING DRUG ADMINISTRATION INFORMATION(用于确定药品使用信息的系统和方法)，其转让给本申请公开内容的受让人，并且该美国申请的公开内容在此引入作为参考。提供开发用以允许与患者有关的数据的患者输入的一个或多个图形接口的其他软件工具对本领域技术人员来说是容易想到的，并且由本申请公开内容可以设想任何这种其他的软件工具。

软件50的功能模块部分56(图2)进一步包括设备驱动管理模块80，其提供访问如上面关于核心应用程序部分54所描述的一个或多个设备驱动器。功能模块部分56还包括结果确认和呈现模块82，其提供对该患者特定数据应用于一个或多个所选择的患者模型的结果进行分析和确认，并且提供用于在视觉上呈现这种结果的一个或多个工具。例如，该模块82可以访问一个或多个模拟工具，可以选择和执行该一个或多个模拟工具来测试疗法稳健性的关键案例、评估该解决方案的稳定性、通过进行大量模拟来确定和评估该疗法对参数变化的灵敏度和/或生成置信区间，和/或给出该疗法结果处于某一范围内的表示。可替换地或者另外，该模块可以访问一个或多个工具，可以选择和执行该一个或多个工具来提供用于确保这些结果的安全且稳固使用的故障保险、分析例如疗效、潜力、类同(affinity)的结果有效性、分析治疗收敛(convergence)和稳定性的结果、提供例如HbAlC的一个或多个基于计算机的生物标志、提供一个或多个患者监视时间表、提供一个或多个疗法提议等。模块82可以进一步提供访问一个或多个视觉呈现软件工具或软件包，该一个或多个视觉呈现软件工具或软件包用于按照任何常规格式用图形呈现这些结果，所述常规格式例如文本报告、图表、曲线图等。下文提供了说明利用图1的系统10和图2、3的软件50的根据本发明的过程的特定例子。

方法实现的例子

现在参见图4，示出了用于开发患者特定疗法的过程100的一个说明性实施例的流程图。过程100帮助确保满足用于疗法的最小规则，(多个)选择的选定与实现治疗目标有关，并且解决用以改进患者疗法的特定问题。过程100不需要一次就被全部执行，而是可以在许多入口点中的任一个入口点处进入，如在下文中将要更加详细地描述的。

过程100的第一入口点前进到步骤102，在步骤102，根据经由数据收集协议模块70可访问的一个或多个数据收集协议来收集患者特定数据。要理解，一个实施例中的收集协议可以是通过支配诸如ADA或类似组织的医学团体指定的收集协议，在其他实施例中，是如保健专业人员建立的收集协议，所述保健专业人员诸如医师、医生等。在步骤102，可以利用上面参考图1描述的患者数据测量/收集设备48的任何一个或多个实施例通过将这种数据录入客户端计算机14中来收集患者特定数据。可替换地或者另外，在步骤102，可以通过按照常规的方式测量或确定该患者特定数据然后经由实施例中的输入设备40或监视器36中的一个或多个将这种数据录入到客户端计算机14中来收集该患者特定数据，所述监视器36包括一个或多个触摸屏按钮或开关。

在步骤102之后，过程100前进到步骤104，在步骤104，对所收集的患者特定数据的完整性和质量进行检查。在一个实施例中，例如，数据收集协议模块70包括或者使用数学模块形式的数据顺从性过程，其检查所收集的数据的不一致性，并且检查为已经收集的特定数据所限定的要求。这种要求的例子包括但不限于时间戳一致性、(多个)数据值范围、(多个)日期范围等。在一个实施例中，数据顺从性过程是为最佳结果而预先评价的。另外，数据收集协议模块70可以包括或者可以使用例如数学模块形式的数据质量过程，其检查所收集的数据在其性能和/或统计属性方面的质量。例如，为了确定数据质量是否不足，该系统检查所收集的数据的几个方面。在该实施例中，一个方面是所收集的数据的关联性(relevancy)，其中采用从数据库模块调用的关联性查询来从所收集的数据中提取数据内容，所述数据库模块由查询组成。经由适当的统计模块对所提取的数据内容进行统计分析，该统计模块接收所提取的数据内容并输出结果，所述结果涉及达到所希望的基线而言的每天的测量频率、进餐时间、丸剂、相对于进餐量的丸剂量等等。另一个方面是所收集的数据的定时，在步骤104中，根据将要求基线与已经收集到的患者的内容进行比较来检查数据时间序列从而为所收集的数据提供置信区间。在所说明的实施例中，客户端计算机14或服务器计算机12可用来通过访问和执行数据顺从性和数据质量模块的任一个或两个来进行步骤104的这种检查。

在步骤104之后，任选的是，在步骤105中，该过程100可以包括在监视器36上向用户呈现用于选择一个动作的建议，并基于数据质量的当前评估和所收集的数据中某个数据的可用性而呈现数据可用性状态。如所讨论的，在后面章节中提供有关该步骤的更多细节。然后，过程100前进到步骤106，在步骤106，客户端计算机14或服务器计算机12用来确定每个数据收集协议的数据完整性和/或数据质量检查是否通过或失败(或者基于在步骤105中的所选择的建议和数据可用性状态来确定通过/失败)。如果一个或多个数据完整性和/或质量检查失败了，那么在所说明的实施例中，根据该一个或多个失败的数据收集协议使算法执行返回到步骤102，从而可以收集一组新的患者特定数据。任选的是，如图4中所示，过程100可以包括在步骤106的“FAIL”分支和步骤102之间的附加步骤108。在该实施例中，客户端计算机14或服务器计算机12在步骤108仅可用来识别需要被重新收集的数据，即在任何一个或多个数据收集协议中的数据，其被破坏或没有通过数据完整性和/或质量检查。此后在步骤102，仅仅在步骤108识别的数据需要进行重新收集。在另一个实施例中，提供可选步骤110，其中询问用户是否需要在此时重新录入所识别的数据。如果答案为“是”，那么过程100返回到步骤102，否则过程100利用在图4中标识的第二入口点处收集的可用数据来继续进一步的分析。

过程100中的第二入口点存在于步骤106的“PASS”分支和随后的步骤120之间。要理解，第二入口点也可以起到执行步骤102-108的出口点的作用。在任何情况下，步骤106的“PASS”分支和/或入口点2都前进到步骤120，在步骤120，从经由患者模型模块72可用的一个或多个患者特定模型中选择一个或多个适当的患者模型。在步骤120，可以利用客户端计算机12和/或服务器计算机12通过诸如输入设备40(例如，键盘、点击设备、麦克风或其他合适的用户输入设备)的合适的用户接口来选择该一个或多个患者模型。可替换地或者另外，可以利用客户端计算机12和/或服务器计算机12通过经由外部存储器设备访问一个或多个用户模型来执行步骤120，所述外部存储器设备如光盘只读存储器(CD-ROM)、软盘、USB-兼容存储设备等。可替换地或者另外，可以通过访问在数据库24或其他存储单元中存储的适当链接然后经由形成核心应用程序54一部分的常规网络浏览器访问该链接的相应网站或其他源来执行步骤120。另一方面，如果存储的链接对应于对一个或多个出版物的参考，那么可以通过或者人工地或者经由客户端计算机14和/或服务器计算机12访问该一个或多个出版物来执行步骤120。在任何情况下，当选择了一个或多个患者模型时，步骤120进一步包括利用在上文中描述的任何一个或多个技术来识别模型参数。在一个实施例中并且参考图21，提供了说明模型参数识别的例子，并在下文中进行讨论。

为了说明参数确定，描述了一个简单的例子，其例如通过患者模型72(图3)来概述在步骤120中的处理。考虑临床研究，其中用速效的胰岛素类型来医治类型I的患者，例如利用诸如设备48(图2)的胰岛素泵(insulin pump)的Lyspro。该泵能够注入基础胰岛素分布曲线(profile)以及手动命令的丸剂。对于临床研究来说，向该泵提供红外线控制，并且能够通过诸如ALGO 510(图5)的控制算法以闭环方式来控制该泵，ALGO 510将在后面章节中进行讨论。该临床试验由利用泵在皮下注射连续的小丸剂和大丸剂而组成。同样地，可以选择脉冲响应模型，其用方程式(1)来描述：

$h\left(t\right)=\frac{K}{{\mathrm{\β}}^{\mathrm{\α}}\mathrm{\Γ}\left(\mathrm{\α}\right)}{t}^{\mathrm{\α}-1}{e}^{-t/\mathrm{\β}}m{l}^{-1}{\min }^{-1}---\left(1\right).$

方程式(1)的脉冲响应模型由三个主要参数组成。这些参数是：α、β和K，其中α近似地代表间接地充当过滤器的隔室(compartment)的数量，β是每单位胰岛素分布容积的峰值吸收率的时间，K是增益系数。吸收的胰岛素分布在身体的胰岛素分布容积中。胰岛素被诸如肌肉、肝的组织所利用，并且也从循环血中去除。微分方程(2)描述了整个过程，其近似为：

$\frac{d{C}_I}{\mathrm{dt}}=-\frac{1}{\mathrm{\τ}}{C}_I+\underset{-\∞}{\overset{t}{\∫}}u\left(\mathrm{\η}\right)h(t-\mathrm{\η})\mathrm{d\η}---\left(2\right).$

第一项是去除(clearance)项，且将其简单地假定为与胰岛素浓度成线性比例(一阶指数衰减)。但是，时间常数τ(分钟)是未知的。方程式(2)右边第二项是注入的胰岛素丸剂与胰岛素吸收函数之间的卷积项。该项提供了由胰岛素丸剂的任意序列在每单位体积吸收到循环中的净(net)胰岛素。每U/min的输入胰岛素丸剂u(t)＝0.278u′(t)，其中u′(t)以U/hr为单位。因此，问题是确定患者特定胰岛素动力学的参数。如图21中所示，每U/hr的输入胰岛素丸剂u′(t)和输出胰岛素浓度观察结果C_I ^Observation[k]U/mL(周期(circle))是所需要的。

通过选择参数集来解决该问题，所述参数集例如使方程式(3)所描述的标准减到最小，方程式(3)为：

$\sqrt{\frac{\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{\left(C_I\right[i]-C_I^{\mathrm{Observation}}[i\left]\right)}^2}{n}}---\left(3\right),$

其中C_I ^Observation[i]是时间窗中第i个以内插值替换的胰岛素浓度，C_I[i]是相对应的第i个模拟浓度。存在其他的最小化标准，其可以利用并且取决于问题要求。在这一阶段来自数值解观点的问题是标准问题。该问题通过利用如由应用程序主体所指的可用的许多优化例程之一来解决。在该例子中，可以使用如调用并且从核心应用程序54(图3)之一提供的、来自名为

的软件包的称为“fmincon”的优化例程。“fmincon”函数找到几个变量的函数的约束最小值。随后，约束最小化函数(constrained minimization function)求出未知的参数，其产生下面的参数解：α＝1.28，β＝31.1分钟，τ＝56.7分钟，K＝1.93。

在步骤120之后，过程100前进到步骤122，在步骤122，在步骤120选择的一个或多个患者模型上进行模型确认过程。在所说明的实施例中，客户端计算机14和/或服务器计算机12用来通过访问来自模型确认模块74的一个或多个模型确认软件包来执行步骤122。确认模块74将步骤122中提供的整个参数解连同在所选择的患者模型上使用的协议用于该模型确认。

在步骤122之后，过程100前进到步骤124，在步骤124，客户端计算机14或服务器计算机12确定在步骤120选择的一个或多个患者模型是否已经通过了模型确认步骤122并且因此是有效的患者模型，如果不是，那么在所说明的实施例中，算法执行返回到步骤120，从而可以选择一个或多个新的患者模型。任选的是，如图4中所示，过程100可以包括在步骤124的“NO”分支和步骤120之间的附加步骤126。在该实施例中，客户端计算机14或服务器计算机12在步骤126用来仅仅识别一个模型(或多个模型)的一部分和/或需要修改的模型参数值。此后在步骤120，仅仅需要在步骤120选择该患者模型的已识别部分和/或仅仅是已识别的模型参数需要修改。

过程100的第三入口点存在于步骤124的“YES”分支和随后的步骤140之间。要理解，该第三入口点也可以起到执行步骤120-126的出口点的作用。在任何情况下，步骤124的“YES”分支和/或入口点3都前进到步骤140，在步骤140，将按照步骤102-108在延长的时间段内收集的患者特定数据应用于由步骤120-126产生的一个或多个确认的患者模型，以确定一个或多个患者疗法或疗法作用。可以经由客户端计算机14和/或服务器计算机12利用如上所述由分析模块76可访问的任何一个或多个分析工具来执行步骤140。该一个或多个患者疗法或疗法作用可以是或者可以包括例如但不限于一种或多种药品的管理、锻炼的建议，和/或如上面所述的其他疗法和/或疗法作用。

在步骤140之后，过程100前进到步骤142，在步骤142，对于由步骤140产生的一个或多个患者疗法和/或疗法作用来进行确认分析。在所说明的实施例中，客户端计算机14和/或服务器计算机12可用来通过从如上所述的结果确认和呈现模块82访问一个或多个结果确认软件包来执行步骤142。在步骤142之后，过程100前进到步骤144，在步骤144，客户端计算机14或服务器计算机12用来确定在步骤140所确定的一个或多个患者疗法和/或疗法作用是否已经通过了疗法确认步骤142并且因此是有效的疗法和/或疗法作用。如果不是，那么在所描述的实施例中，算法执行返回到步骤140，从而可以选择一个或多个新的患者疗法和/或疗法作用。任选的是，如图4中所示，过程100可以包括在步骤144的“NO”分支和步骤140之间的附加步骤146。在该实施例中，客户端计算机14或服务器计算机12在步骤146仅用来确认需要修改的一个或多个患者疗法和/或疗法作用的一个或多个部分。此后在步骤140，仅仅需要在步骤140修改一个或多个患者疗法和/或疗法作用的已识别的该部分或多个部分。

过程100的第四入口点存在于步骤144的“YES”分支和随后的步骤160之间。要理解，该第四入口点也可以起到执行步骤140-146的出口点的作用。在任何情况下，步骤144的“YES”分支和/或入口点4都前进到步骤160，在步骤160，经由如上所述的一种或多种呈现设备和/或格式向系统100的用户呈现该一个或多个患者疗法和/或疗法作用。可以经由客户端计算机14和/或服务器计算机12利用如上所述由结果确认和呈现模块82可访问的任何一个或多个呈现软件包来执行步骤160。

特定使用案例实例-例A

下面是这里描述的一些概念的使用案例实例。该实例的步骤一般遵循图4的算法100，并且可以经由常规的向导(wizard)来实现，该常规的向导即计算机用户接口，经由该计算机用户接口引导用户通过连续的对话来完成一项任务。该向导是以该目标对糖尿病患者的信息搜集和分类的混合，从而朝(i)疗法确定的最终目标和/或(ii)如图4的流程图所示的中间结果而引导保健专业人员。下面在由这种向导所执行的步骤框架中呈现该实例，尽管应当理解可替换的是，该实例的步骤可以经由常规的方法或指令集来实施。

在该第一实例中，患者的病历文件和当前状态如下。研究对象是I型糖尿病患者，其上一次去见保健专业人员是在4个月前。该研究对象是40岁的男性，体重80kg(自从上次就诊以来未改变)，目前正在使用速效的胰岛素，如Lispro(自从上次就诊以来未改变)。据说该研究对象每天平均测量3次bG(自从上次就诊以来未改变)。上一次就诊时进餐量的平均值是35g、70g、85g和25g，不知道目前进餐量的值。该研究对象的碳水化合物与胰岛素之比是8gm/U(未变化)，胰岛素敏感性是40mg/dL/U(未变化)。该研究对象的身体活动正常(未变化)。在该研究对象上一次就诊时，其HbAlC是7.5，目前是9.5。在该实际模式下，指示该保健专业人员遵循用于通常I型糖尿病的典型的数据收集协议。

在步骤102中，向导提示用户选择患者的糖尿病类型。选择或者I型或者II型。在该实例中，选择I型。接着，该向导提示该用户选择就诊的原因。可用的选择是：新患者、临床试验、正常情况下2-3个月就诊的定期就诊、住院后(post hospitalization)或者加强监视完成。在该实例中，选择定期就诊。然后该向导提示该用户随后输入并且如果可用的情况下通过标准消息/数据检索协议而采取下面的动作：录入患者身高、体重、性别、年龄；获得相关的实验室报告(AlC、LDL、HDL、BP、药物)；从相关设备下载数据：仪表数据、泵数据、PDA等；捕捉患者行为(从所收集的数据，生活方式捕捉)，例如低血糖事件的数目、高血糖事件的数目、就餐定时分配、碳水化合物组成、胰岛素分布、身体活动、睡眠时间表和工作时间表；排斥标准(exclusion criteria)；输入生理状态(生病、没生病)；输入药物；CSII；MDI；目前的疗法；和目前的疗法规则。在该实例中，所收集的数据反映出：目前的HbAlC＝9.5；上一次HbAlC＝7.5；(上一次的平均值是35g、70g、85g、25g)；目前的进餐信息由于缺少录入的数据而未知；bG测量很少；bG平均值和SD是：(150+/-70)；整夜禁食未知，以及其他数据值未知。

然后，基于上面录入/收集的数据，在步骤104中该系统检查数据完整性/数据质量。在该实例中，由于是定期就诊，因此保健专业人员以前已经确定需要定期调节患者疗法作为治疗目标。因此，在该步骤的过程中，检查各个方面。例如，对于一些选择的治疗目标来说，存在为了提供实现所选择的治疗目标的有意义结果而需要的首要必备的数据收集。因此，在该步骤中，该系统检查以查看在所收集的数据中数据是否可用，其对于特定的算法参数也是切合实际的(例如，在预定的范围中、之上/之下/是某一值等)。此外，在步骤104中，对数据内容进行统计学分析以确定每天的测量频率、进餐时间范围、进食丸剂的范围、相对于进餐量的平均丸剂量等。还检查在所收集的数据中的数据时间序列。其想法是患者正常情况下遵循由活动组成的日复一日的模式，所述活动包括进餐、身体活动和工作时间表。按照由患者所收集的患者生活方式的身体活动信息、进餐信息、测量顺序和定量给药信息，该详细的这种信息在任何指定日子是不同的。当对一段时间内的该不同的信息进行分析时，该不同的信息表示出疗法的疗效。在一个实施例中，相对于所希望的患者生活方式和至少应该收集的最少量的信息来检查由该患者收集的这种信息。

在数据分析和数据映射之后推断逻辑演绎以解决：(a)下一组分析的关联性，(b)结果的置信区间；以及(c)基于阈值的接受/拒绝标准。例如，在一个实施例中，如果考虑事件药物及其对bG的影响，那么第一步骤是确定是否已经收集了每个协议的数据。所期待的是，bG数据在量值以及测量时间方面都具有变化性。在一个实施例中，相对于经验规则而检验测量的数目、测量顺序和测量中的变化性以确定接受数据。在另一个实施例中，应用一组经验规则来确定所收集的数据中的哪个在基于阈值的接受标准之下，以便进行在达到所希望的目标方面的某种分析。例如，对于上面给出的病历的实例，根据可用数据和期待的控制质量，经验规则的一个输出将表现出对于餐后葡萄糖控制所需要的bG测量与调整患者疗法的目标非常相关，并且需要收集最少数量的bG测量以便提供对于达到该目标的有用的建议。如果bG测量的收集低于最少数量，那么在步骤106中，该数据收集质量在该实例中不合格。

在进行了步骤104中的检查之后，在步骤105中任选地为该患者提供一系列的疗法评估/建议。紧跟在每个疗法评估/建议之后提供关联性等级(rating)，其基于这种疗法评估/建议的效果选择，这种疗法评估/建议是基于生成对该患者疗法的改变时将具有的所收集的数据质量。在给定的实例中，这种疗法评估/建议及其连带的关联性可以包括：(a)患者疗法收集是不良的(关联性95％)，(b)患者需要定期的疗法调整(关联性50％)，以及(c)患者生活方式改变(关联性15％)。对于建议(a)，经验规则的输出形成如下结论，即根据所收集的数据，AlC不良，患者感觉不适，读数指示葡萄糖值高、许多高血糖和低血糖事件，以及没有足够的bG测量来有效地调整患者治疗。因此，关联性等级高是基于新收集的数据有限并且旧的数据已经有大约4-5个月的这些考虑。对于建议(b)，如上面所提及的，为了调节患者疗法，需要用充足数量的餐前葡萄糖测量和餐后测量对AlC进行加权。该方法也对高血糖和低血糖事件以及AlC值进行加权。但是，因为在所收集的数据中没有呈现足够的bG测量并且AlC不能令人满意，因此该建议的关联性低，因此在给定的所收集的数据范围内很可能不是最佳的选择。当患者能够提供更多的bG测量时，那么该建议的关联性将会提高。对于建议(c)，通过主要比较历史数据，通过比较平均值和或利用活动窗口并且比较平均值和或确定数据的趋势来考察患者生活方式的变化(例如药物、搬到/旅行到新的时区、改变身体活动、改变压力水平，或者改变进餐摄入)，在这一点上，由于数据收集不良因此会向保健专业人员提供在调整患者疗法方面的很少的值(如果有任何值的话)。

要理解，基于所收集的各种数据能够提供一大堆的疗法评估/建议。例如，这种疗法评估/建议可能包括该患者是最近诊断的I型糖尿病患者并且需要治疗，或者该I型患者因闭环临床试验而恢复(recruits)。在给定的实例中，这些建议具有0％的关联性，因为患者既不是新的I型，也没有因闭环临床试验而恢复。因此，这些生成的疗法评估/建议呈现为步骤105中的输出以由保健专业人员来选择。在提供的实例中，该保健专业人员选择疗法评估/建议(a)，即患者疗法收集不良。疗法评估/建议(b)和(c)在某个程度上对于保健专业人员是有用的，但是关联性等级表明全面的数据在所收集的数据中是不足的，并且不足够好以生成新的疗法。

接着，在选择了一个所列出的评估/建议之后，还在步骤105中向保健专业人员提供数据可用性状态供其选择。在该步骤中，该系统也为所选择的评估/建议(这里在该实例中，是疗法评估/建议(a))确定如果采取其他类型的动作那么哪些动作与处理/解决/改进所选择的疗法评估/建议相关。在该实例中，提供下面的数据可用性状态以供选择：(i)收集数据以改进餐后葡萄糖控制(关联性80％)，(ii)收集数据以改进在禁食过程中的目标葡萄糖(关联性75％)，(iii)收集数据以获得全面的初始疗法参数(关联性70％)，(iv)改变疗法定时，如由于时区改变(关联性25％)，(v)改变疗法以调整已增加的身体活动，改变状态(关联性15％)，(vi)改变疗法以调整到可替换的生理状态(关联性5％)，以及(vii)为闭环算法识别参数(关联性0％)。在该实例中，另外的经验规则根据所收集的数据和所选择的评估/建议确定为了最好地改进餐后葡萄糖控制并且为了有助于改变疗法，那么需要收集更多的这种数据并且该数据与达到该目标最相关。但是，在该实例中，保健专业人员考虑并且选择选项(iii)-收集数据以获得全面的初始疗法参数，其决定从标准解决方案开始是较好的。

因此，根据各种选择，所收集的数据是不顺从的(non-compliant)并且在步骤106中失败。例如，在该特定实施例中，为了调节患者疗法，需要用餐前葡萄糖测量和餐后测量对HbAlc进行加权。然而，由于对于该算法的有效地利用，所收集的数据中很少的葡萄糖测量是可用的，因此所需要的数据的这种缺乏将会导致在步骤106中数据质量不良。然后该向导执行步骤108，在步骤108，该系统经由另一组经验规则识别需要重新收集的数据，以便为调节作为建议的治疗计划或处方(prescription)的该患者疗法所需的初始疗法参数提供充足的数据。该处方可以处理下面的一个或多个：(a)bG测量的数目，(b)碳水化合物计数，(c)测量的定时；(d)关于设备的通知，(e)训练建议，(f)顺从性满意标准，(g)下一次就诊时间-该协议能够指定日期或持续时间，以及(h)下一次就诊时可能的入口点。在给定的实例中，该处方输出提供在步骤108中是：每天需要3+bG餐前测量以满足顺从性，应当记录摄入的所有碳水化合物的计数(count)，每个医生坚持的关于设备的通知、推荐碳水化合物计数帮助指南(或训练/进修班(refresher class))，下一次就诊是从这一次就诊日期开始的3周后，并且当患者下一次就诊时应当是入口点1。

在步骤108之后，该向导任选地检查在步骤110中是否重新录入了所识别的数据。如果重新录入，那么该向导为所识别的数据重复步骤102。如果没有重新录入，那么在这一点上该向导在入口点2继续算法100。对于保健专业人员来说问题仍然是患者是否具有未解决(resolve)的好的疗法参数。尽管，先前的收集步骤已经显示缺乏必要的数据并且已经向患者呈现需要的数据收集要求以改进性能，但是在步骤120中，向所说明的该实例中的用户呈现下面的选项：(a)继续同样的参数，(b)利用历史数据，或者(c)将用于检查当前疗法参数的数据重新初始化。要理解，在软件的编排过程中可以选择任选的步骤105和110(共同或单独地)以供使用，这在该实例中已经出现。

在步骤120中，关联性算法提供对于解决该患者是否具有良好疗法参数的问题有用处的每个选项的关联性。在该实例中，利用同样参数的选项(选项(a))是0％，因为先前的步骤已经表明数据质量不良，利用历史数据的选项(选项(b))和将数据重新初始化的选项(选项(c))分别是60％和80％。为了提供每个选项的关联性，在一个实施例中，关联性算法在步骤120考虑下面的信息：患者数据不足以重做疗法参数；患者的历史数据是可用的；以及疗法初始化模型是可用的。关联性算法量出患者的血糖控制以确定疗法参数以及当该系统首次对患者进行分析时该患者如何利用疗法参数的初始估计。然而，该系统允许保健专业人员在每一步骤都利用其自己的判断，因为该系统有时可能对目前的患者过度保守或激进(aggressive)。在该实例中，保健专业人员在步骤120中选择选项(c)“对数据进行重新初始化”，其产生分析并指示该模型在步骤122和124中是有效的。这些步骤简单地意味着保健专业人员选择了基于群体的参数，并且这缺省地表示平均群体行为，该保健专业人员按照该平均群体行为而一致地考虑信息的当前状态。

在步骤124之后向导在入口点3继续该算法100。在步骤140，该实施例中的过程100将所收集的数据应用于基于群体的参数以确定患者疗法，这在表1中示出。

表1-由模型生成的疗法参数

基本速率(Basal rate)	1.1U/h
		碳水化合物与胰岛素之比	9gm/U
胰岛素敏感性	30mg/dL/U

在步骤142中，该向导现在对已确定的患者疗法进行确认分析，并且向该保健专业人员提供最相关的选项，通过该最相关的选项来审查已确定的患者疗法并提供疗法安全准则。在给定的实例中，向保健专业人员提供用以评价生活方式对患者的慢性病管理的影响的选项。此外，关于疗法安全准则，基于所收集的数据和生活方式结果，在步骤142中通知该保健专业人员该患者具有x个低血糖事件和y个高血糖事件的可能，由此能够通过附加的后期测量和校正性(corrective)的胰岛素来降低高血糖事件。该系统在步骤142中也建议以从所选择的模型生成的参数为基础的疗法。在该实例中，所建议的疗法提供将基础速率设置为所希望的U/hr，将碳水化合物与胰岛素之比设置为所希望的gm/U，将胰岛素敏感性设置为所希望的mg/dl，表示所需要的bG测量的数目、要求在所有进餐中所摄入的碳水化合物计数，并表示需要至少x个每日的餐前测量和至少y个餐后测量以改进疗法参数估计。另外，劝告该用户，患者应当在紧接着的y个星期内完成该疗法的数据收集并且之后到保健专业人员那里就诊。在步骤144中，系统询问该保健专业人员所建议的疗法是否有效。如果该保健专业人员希望改变所建议的疗法的上面的任一方面，那么在步骤144中表明“no”，致使该保健专业人员能够在步骤146中修改疗法的一部分。在步骤146中进行所希望的改变之后，然后重复步骤140-144。否则，过程100通过输出所建议的疗法作为步骤160中的处方而完成所建议的疗法，步骤160也是入口点4。要理解，对于该实例来说，当患者再次到保健专业人员那里就诊时，再次在入口点1采用该向导并且该向导引导该用户通过图4的算法100。

特定使用案例实例-实例B

在第二个使用案例实例中，研究对象的病历如下。该研究对象是与上面实例A中相同的I型糖尿病患者，其上一次去见保健专业人员是在24天前。该研究对象是40岁的男性，体重80kg(自从上次就诊以来未改变)，目前正在使用速效的胰岛素，如Lispro(自从上次就诊以来未改变)。该研究对象每天平均测量6次血糖(bG)(在上次就诊时是每天3次)。上一次就诊时进餐量的平均值是25g、85g、85g和25g，不知道目前进餐量的值。该研究对象的碳水化合物与胰岛素之比是8gm/U(未改变)，胰岛素敏感性是40mg/dL/U(未改变)。该研究对象的身体活动正常(未改变)。在该研究对象的上一次就诊时，其HbAlC是9.5，目前是9.5。在该实际模式下，指示该保健专业人员遵循用于通常I型糖尿病的加强监视的数据收集协议。

在该实例中，在步骤102完成之后，已经收集了下面的数据：患者是I型；就诊原因是加强监视完成；目前的AlC＝9.5；上一次AlC＝9.5；目前的进餐信息(平均35g±5、70g±15、85g±20、25g±15)；上一次进餐信息由于缺乏数据而未知，bG平均值和SD是135±50；整夜禁食是130±30mg/dL；相对于所需的协议而处理数据；以及在该协议的界限内统计地进行数据的收集。在步骤104中对所收集的数据的完整性和质量进行检查之后，在步骤105中提供的一系列建议(例如显示的)连同其关联性等级如下：(a)患者需要定期的疗法调整(关联性90％)，(b)患者疗法不良，例如AlC不足，患者感觉不适，读数显示葡萄糖值高、许多高血糖事件(关联性95％)，(c)患者最近被诊断出是I型糖尿病并且需要治疗。(关联性0％)，(d)I型患者已经因闭环临床试验而恢复。(关联性0％)，以及(f)患者生活方式改变，例如搬到新的时区，增大身体活动等(关联性65％)。

根据上面显示的建议，保健专业人员看到建议(a)和(b)是最相关的，其中建议(b)“患者疗法不良”具有最高的关联性。在该实例中，保健专业人员在步骤105中选择建议(b)。接着，在步骤105中向保健专业人员提供(例如显示)下面可选择的关于数据可用性状态和连带的关联性的选项：(i)收集数据以改进餐后葡萄糖控制(关联性15％)，(ii)收集数据以改进在禁食过程中的目标葡萄糖(关联性10％)，(iii)收集数据以获得全面的初始疗法参数(关联性10％)，(iv)重做患者参数并确定疗法参数(关联性95％)，(v)改变疗法定时，如由于时区改变(关联性25％)，(vi)改变疗法以调整增大的身体活动(关联性0％)，(vii)改变疗法以调整到可替换的生理状态(关联性0％)，以及(viii)为闭环算法识别参数(关联性0％)。在该步骤，保健专业人员选择选项(iv)重做患者参数并确定疗法参数作为相关的行动过程。很明显，过去的就诊初始化显示血糖控制不足。餐前表明进餐控制和/或禁食控制不足，尽管患者正在进行得到测量和对碳水化合物计数的勤奋的任务。与提供基于群体的参数的上一次就诊相比需要患者特定调节。由于按照基线的数据收集是顺从性的并且在步骤106中通过，因此过程100在入口点2继续以进行模型选择。

在步骤120，过程100确定所收集的数据是可用的且其是令人满意的，历史数据也是可用的，并且确定经验的初始化模型也是可用的。因此在这种情况下在步骤120中向保健专业人员提供下面的选项及其连带的关联性：(a)识别患者参数(关联性95％)，(b)利用历史数据(关联性50％)，以及(c)将数据重新初始化(关联性50％)。在该实例中，该保健专业人员选择选项(a)，即识别患者参数。该保健专业人员可能已经选择了利用历史数据的方法，其中分析并呈现模式和趋势。但是，在具有可用的详细数据的该实例中，保健专业人员选择检查患者特定生理机能特性的详细步骤。接着在步骤120中，显示下面的已识别的模型参数连同其评估的关联性作为可由该保健专业人员选择的选项：(a)与进餐有关的模型+CSII+bG仪(关联性99％)；与进餐有关的模型+MDI+bG仪(关联性0％)；以及与进餐有关的模型+CSII+连续的(关联性0％)。在步骤140中，保健专业人员选择第一个选项(a)，即关于向导的进餐+CSII+bG仪。这里，关联性显示出需要全面的治疗。对于患者来说，进餐是主要的外生干扰(disturbance)。在这一点上，估量出锻炼或其他应激源作为其次，并且在将来的疗法参数调整中可能成为相关的。

最后，在步骤120，该向导呈现出进餐类型模型以供选择：(a)快速(碳占优势的)；(b)中等(标称的)；(c)缓慢(高脂肪含量)，以及(d)混合的(相应收集的数据应当具有这种信息)。该保健专业人员选择第二种进餐模型选项(b)，即中等或标称的进餐模型。这里，没有足够的数据或者没有充足的记录来制作选项(d)下的混合案例，并且患者的数据已经表明基线标称模型。利用更详细的信息可以捕获特定的进餐习惯。该进餐模型部分可以是或者包括更详细的过程，并且在任何情况下都导致选择基本的数学模型，其可以是标准的，或者可以通过允许保健专业人员选择或定义可替换的生理模型而归纳出来。上面的实例仅仅说明了在步骤120种处理模型选择的一种方式。

在模型选择之后，在步骤122中，过程100对该模型进行确认和分析。关于该步骤，在系统10上经由基于计算机的模拟而用计算机(in silico)模拟患者特定使用案例的场景。实际上相当于理解选定的患者模型可以是每次确定数学模型时都应当对其进行测试以检查其逼真度(fidelity)。步骤122确保由于对已经配置成各个研究对象的专门测试案例进行测试因此存在建立到该系统10中的检查和平衡，并且其中因此将所得到的数据或者与已知标准进行比较或者与更广泛群体的数据进行比较。步骤122需要如取决于特定的所选择的患者模型的下面至少一个：在指定工作范围内用计算机确认该模型以理解工作空间，并且理解该模型的限制；提供位于模型的给定假设之下的误差的合理概念；应用其他测试模型，如测试进餐、测试胰岛素剂量等；测试具有已经收集的临床数据的模型，所述临床数据如胰岛素输入信息和事件输入信息；以及应用特定模型特性，如指定的分布曲线、参数值范围，或者量度。任何反常的或奇怪的方面都会加上标志并向保健专业人员呈现以进行动作。

在给定的实例中，进行患者模型拟合，其拟合等级(quality of fit)＝85％，即该模型和该组参数将说明85％的模型特性，这是观察到的特性的加权结果(bG和进餐量的测量)。在其他实施例中，参数的置信区间可能是可用的。并且在该实例中，进行模拟的患者模型响应以验证该模型的生理特性(验证)。这也称作患者模型表征，其包括该模型对预先确定的信号的模型的标准测试以检查所获得的特性，然后将其与观察到的患者特性的一个或多个期望范围进行比较。在这一点上，一个目标是保持在可接受的患者特性的指定界限内。在其他实施例中也可以进行模型的复制结果的能力(预测的质量)。这是任选的特征，并且可以在复制数据集可用时实施。该能力的测量可以是例如归一化的最小二乘拟合。

在完成了步骤122中的对所选择的模型的分析之后，在步骤124中确定该模型是否有效。在步骤124中，保健专业人员基于多个结果来审查和考虑是否接受该模型，这些结果包括下面的至少一个：参数的置信区间、拟合该数据的能力、向基于生理机能的参数的估计提供置信区间，等。可以为每个参数而计算置信区间。这些置信区间基本上确定置信度，利用该置信度来计算这些参数。过宽的置信区间是不期望的，因为已经为特定协议选择了该模型。但是如果它们过宽，那么能够推断出，对于该特定患者和该特定进餐而言，利用该方法不存在改进的可能性。并且，利用经典的标准如预测和测量之间的平方差可以检验拟合优度。如果拟合优度不佳，那么不应当利用所计算的参数来改进进餐控制。如果该模型没有进行合适的确认工作，那么可以重做这一步骤。另外，可能想要与另一个或多个模型做比较以确定是否存在提供更好的结果的一个或多个可替换的模型。由于在步骤122中对所选择的模型进行的确认分析(即识别患者参数)，因此该保健专业人员在步骤124中确定该模型有效。在这一点上，该向导在入口点3继续该算法100。

在保健专业人员已经批准了该模型之后，那么该向导将保健专业人员带入到疗法分析/确定的最后阶段中。在步骤140中，该过程用计算机进行模拟以质询用于疗法稳健性的关键情况并且通过考虑监视时间表和故障保险来评估该解决方案的稳定性，确定该疗法对参数变化的灵敏度，通过进行大量模拟来生成置信区间，并确定各种疗法的有效性(功效、潜力、类同)以确定建议的治疗提议(包括疗法的安全和耐受性)。

在给定的实例中，例如在步骤140中，过程100提取/识别患者生活方式数据并且基于这种数据向治疗结果提供(多个)置信区间。患者生活方式在这里对于测试和评价疗法而言是相关的。现在经由带生活方式选项的向导而向保健专业人员呈现所收集的信息和所识别的模型以审查疗法的结果。这里，一个目标是提供疗法安全准则。在步骤140中，可以向保健提供者提供下面的疗法计算选项：(a)为指定的算法A(例如CSII)和指定的生活方式确定疗法参数；(b)为指定的算法B(例如ICT)和观察到的生活方式确定疗法参数；(c)建议高级的执行疗法(CSII+频繁的测量+生活方式)；以及(d)评价生活方式影响(95％)，顺从性不佳的50％对90％的顺从性。在步骤140中，保健专业人员选择第一选项(a)，因为该患者在较早的就诊中是不顺从的。任选的是，可能由保健专业人员实施的附加锻炼也选择第四选项(d)。

这里，利用所观察的生活方式但贯穿(run through)不顺从的场景(即患者没有观察该疗法规则和/或对于测量和碳水化合物计数是不顺从的)，在步骤142执行随机模拟，并且生成潜在结果的比较报告。这种报告可以包括：患者有可能会具有x个低血糖事件和/或y个高血糖事件；在下一次就诊(例如从现在开始的3个月后)的预期的HbAlC；高和低的bG测量；由于对糖尿病医治不当而引起的可能的时机错过和患病的日子。另外，关于该疗法的推荐可以是：患者测量生活方式应当是至少x个测量；通过附加的后测量和校正性胰岛素能够减少高血糖事件；患者应当继续具有餐前和餐后测量；以及由于患者已经改变了进餐饮食习惯，因此在特殊进餐类型附近收集和记录数据，从而能够进一步改进疗法。此外，为了该模拟的目的，根据该顺从性比率(compliancy ratio)，也可以给出顺从性，其中该顺从性比率等于用一个事件将要被记录的次数去除该事件实际被记录的次数。

例如，患者具有103个早餐前测量的记录，进行这些测量所经历的时间段是120天。因此，对于早餐的顺从性比率是103/120，或者0.86。因此，举例来说，在这种情况下，满足了所需的0.8或更好的早餐空腹顺从性。在步骤144中，保健专业人员审查该报告和疗法，如果没有变化，那么认为其是有效的。过程100现在在入口点4输出该报告并在160输出疗法建议作为处方，并且电子地更新该患者的记录。下文参考图2-9提供根据本发明的特定系统实现及其使用。下文中讨论本发明的系统和过程如何对事件作出响应。

经由事件调用软件响应

如上面提及的，事件是由一个组件所生成的信息的单元，其能够由该系统的另一个组件使用。事件单元所固有的是事件的时间、事件表征描述符、事件作用方案，以及事件值。后面提供进一步的细节。在该系统中，事件的激活涉及为产生事件的要素来指定值。在一个实施例中的事件能够是：(i)信息入口，(ii)活动信息，(iii)命令设备做一些事，(iv)通知患者进行任务，(v)通知患者可能的生理状态，等。在一个实施例中，事件的结构具有下面的字段：绝对的事件时间；事件的类型；事件的持续时间/动作时间/活动时间；相对于双亲(parent)的事件的起动时间；时间的量、(强度)；以及忠告字符串(advisorystring)。绝对的事件时间提供时间应当发生的时间，并具有下面的值：预先确定的、由算法确定的，或者异步触发的。事件的时间被提供作为绝对时间，其一般充当绝对参考。在特殊情况下，该绝对事件时间链接到另一个事件的绝对时间。将绝对的UTC时间用作该事件所关联的“参考时间”。参考时间在将其他事件相互关联中是必不可少的。并且唯一的时间确定不是普通地考虑多个时区和日光节约。当地时间和协调世界时(UTC)之间的差别是相关的。当地时间用于显示目的，并将UTC映射到该当地时间。

事件的类型描述了已经激发过什么事件，并且具有多个值，如进餐、锻炼、药物、胰岛素测量、可替换的状态、校正性的事件和取消事件。持续时间定义了实现活动的长度，如胰岛素丸剂活动、进餐活动、锻炼活动持续时间以及可替换的状态。任何所发起的活动都应当被持续时间所界定。缺省的是，活动具有无限的持续时间。另一种缺省的可能性是该活动没有持续时间。这意味着其影响是瞬时的。从0到无穷大的非零值捕获了所有的中间情况。相对时间是相对于该绝对参考时间的，该事件在相对于该相对时间而调整的绝对时间处发起。这可能是在等于绝对事件时间加上相对时间的时刻激活的与进餐有关的丸剂，相对于进餐事件的测量，或者相对于上一次bG测量的测量。数量描述了事件的强度或量值，并且可能是胰岛素的量、进餐的数量和进餐的速度。最后，忠告字符串是简明而叙述的信息的一部分。在一个实施例中，该字段用XML或RTF或其他标记语言来输出，以便呈现为最终用户和数据库记录特别调整的更详细且描述性的信息。通常，忠告字符串是关于过去、现在和将来任务的正在进行的活动的注释。在该字段中利用标记语言增强了向用户提供用于相互作用的所有可能的工具的总能力，所述可能的工具如音频、视觉图形、静态和动态链接。动态链接可以包括进度条、条形图等。例如，活动的时间可以用进度条来表示，根据待配发的量而配发的胰岛素可以显示为进度条等。

注意，按照上面的方式描述该事件输入的特性，可以在该系统中提供下面的功用(utility)：命令药物配发单元(胰岛素泵)利用给定的输入特性配发药物(胰岛素)；命令测量单元利用给定的输入特性执行测量任务；从患者那里接收与即将来临的事件活动输入特性有关的指令集；以及向该算法模块(即，包含Glycemic-ControlAlgorithm(血糖控制算法)的系统的软件组件)呈现事件输入和/或引发输出事件。Glycemic-Control Algorithm(血糖控制算法)用于根据所收集的皮下传感器数据、研究对象的预定义的基础分布曲线和用户输入来构成胰岛素建议，从而保持该研究对象的葡萄糖水平在目标范围内。向(i)设备(ii)算法和(iii)用户呈现协议特定时间表以执行任务/事件。将特性输入存储起来并且从数据库检索该特性输入。利用本发明的系统和软件如何起作用的实例来进一步解释上面提到的每一种功用。

利用给定输入特性来命令药物配发单元对药物进行配发

在该实施例中，患者数据测量/收集设备48(图2)是药物输送单元，该药物输送单元例如是可编程的胰岛素泵，其自动地对按照在步骤160的结尾(图4)由保健专业人员的处方所指定并经由客户端计算机14上载的系统的推荐疗法起作用。该事件本身以下面许多方式中的一种而生成：(i)算法，(ii)用户，(iii)监控器(第三方工具)，(iv)故障保险，(v)数据库触发的事件，以及(vi)基于协议。这些特性需要唯一地并且应当需要覆盖在下一次通信发生之前已知或未知的时间长度。药物的定时对于糖尿病疗法是很重要的(所有事件定时优选以UTC时间来保持并为当地时间做适当调整)。事件的类型解释了事件的上下文(context)和/或描述了触发的事件(例如进餐丸剂、受命令的丸剂(commanded bolus)、进餐丸剂分布曲线)。任何发起的活动一般都由有限的持续时间来界定。该持续时间理解为覆盖了所制定的事件的实际持续时间，如配发受命令的丸剂实际上花费有限时间来输送，并且该持续时间可能与算法有关，从而考虑什么时候决定下一个丸剂命令，或者什么时候能够捕获胰岛素持续时间，该胰岛素持续时间是胰岛素在患者身体内活动的持续时间。相对时间允许该事件错开参考点。例如，如果参考时间是进餐的时间，那么例如通过指定以分钟为单位的负时间而用该相对时间来得到每次进餐剂量。这种数的序列进一步将单一剂量模式扩展到相对于进餐时间的分布的剂量序列。数量可以指的是活动的强度，或者其代表量/数量。例如，在该特定情况下，是待配发的胰岛素的数量。类似于持续时间，其也可以是数的序列。在该数的序列中的要素数在正常情况下与用于相对时间的要素数相匹配。忠告字符串以(i)图形，(ii)音频格式来呈现该信息。另外，如果存储该信息，那么该信息表现出活动的日志。

利用给定的输入特性来命令测量单元执行测量任务

为了手动控制或自动的反馈控制而需要测量来达到良好的性能。因此从功能的观点将这些测量归纳为另一个事件单元。当然，这些测量具有一些考虑，如附带成本、对于在现实意义上能够进行多少测量的限制、如何使用测量来指定测量的顺序、测量也可以与完成任务的协议有关、需要这些测量来提高性能、通过辅助该用户将测量忠告增加值、保健专业人员(HCP)(例如内科医生、RN、LPN，或护理人员/EMT)、紧急支援队(该紧急支援队具有用于测量的理想时间)、用于测量的最小时间并保持安全。各种可能性都被上面提及的事件特性所覆盖，并且为bG测量对其予以重新处理。测量的定时对于提供良好的疗法是很重要的。在测量在进行时，优选以UTC捕获该测量并且将其提交给算法和或数据库。另外，以当地时间呈现测量忠告。例如，在一个实施例中，如上所述将患者数据测量/收集设备48进行编程以便以绝对项告诉患者根据由系统输出的处方应当在当地时间的什么时候进行测量。对于该功用，事件的类型解释了事件的上下文和/或描述了所触发的事件。例如bG Spot(点)测量代表测量所用的bG仪，血液图将代表用于分析的血样，所述分析如获得bG测量、胰岛素血浆浓度或AlC测量。发起的任何活动一般都由持续时间来界定。持续时间理解为覆盖了所制定的事件的实际持续时间，如测量物理上花费了有限时间来确定葡萄糖浓度，并且该持续时间可能与算法有关以考虑如在连续测量中能够具有与30mts延迟一样多的小的测量延迟。持续时间可能不是有意义的情况也存在，在这种情况下录入留下空白。测量的相对时间可以使得覆盖许多使用案例场景并且可以是与上下文有关的。相对时间能够充当递减计数或进行测量的剩余时间。其可以代表自从上一次测量以来的时间推移。其可以代表自从所希望的测量时间以来的时间。其可以代表对于基于协议或基于事件的测量要求的测量时间序列，其可以由在指定持续时间的测量序列组成。数量可以指的是活动的强度或者其代表量。例如，在该特定情况下，数量代表测量值。如果向设备48提供bG测量单元，那么该设备可以显示该测量，并且在指定测量时间和测量尚未发生的情况下，能够很容易地提供用于管理未来录入和/或遗漏录入的逻辑。最后，忠告字符串能够以图形和音频格式来呈现信息。另外，现在将所有信息存储作为活动的日志。

从患者处接收关于即将来临的事件活动输入特性的指令集

一般而言，需要将事件表征以得到更好的性能。目前，利用进餐，例如仅利用碳水化合物计数。在这种情况下，事件的数量字段捕获进餐的净强度(net strength)。然而，未处理更完整的特征，如其速度或其血糖指数(glycemic index)。事件的持续时间字段能够用于捕获进餐速度的多个方面之一。进餐事件可能进一步被描述为快速、适中或缓慢，以便再次捕获进餐速度。另一个实例是锻炼，其中强度和持续时间能够帮助捕获活动水平。这些和其他实例可以使用过程100的算法以便细微调节在提供建议的疗法中应当如何调整背景胰岛素。在锻炼的情况下，相对时间字段允许对事件预编程序，过程100的算法能够用该事件来预先细微调节胰岛素以便与即将到来的事件匹配。这在增强疗法性能方面是非常有帮助的，因为存在系统和响应延迟。

需要对于摄入膳食、诸如锻炼的身体活动或者处于如压力的可替换状态中的定时，以便进行疗法调整。这种活动的识别可以是手动的并且在这种情况下通过手动录入来触发该事件。优选以UTC时间以及对当地时间的适当调整来保持所有的事件定时。事件的类型解释了该事件的上下文和/或描述了所触发的事件。例如，进餐可以描述为高或低的血糖指数，其能够通过组成成分或通过描述符来表现其特性，所述组成成分如脂肪、蛋白质、碳水化合物、纤维，所述描述符如快速、适中或缓慢进餐。发起的任何活动一般都由有限的持续时间来界定。该持续时间理解为覆盖了所触发的事件的实际持续时间。例如已知进餐活动的持续时间与缓慢吸收膳食有关。已知该持续时间帮助确定胰岛素分配。类似的是，表征选择的其他事件加强了对预期生理负荷的认识，通过算法将其用于处理疗法需要。

相对时间字段允许该事件错开参考点。在临床研究中，很明显，超前的认识能够进一步增强控制器的性能。可以将基于预期作用胰岛素的胰岛素疗法削减或者预先给药。通常对于预期的锻炼来说，将基础胰岛素削减，此外该算法将增加碳水化合物摄取事件以便保持葡萄糖在血糖正常的范围内。在快速吸收膳食中，每次给药也帮助抑制快速上升的葡萄糖。数量字段可以指的是活动的强度或者指的是量/数量。例如，在剧烈运动的情况下指的是锻炼事件的强度，在进餐的情况下，其能够用碳水化合物的数量进行描述。如同持续时间一样，其也可以是数的序列。在该数的序列中的要素数在正常情况下与在相对时间内的要素数匹配。忠告字符串以(i)图形，(ii)音频格式来呈现该信息。在锻炼的情况下，忠告字符串是对患者消耗速效的碳水化合物以补偿体力负荷并因此需要碳水化合物的忠告。另外，如果存储上面的事件信息，那么该信息呈现活动的日志。

向算法模块呈现事件输入并且产生输出事件

算法是用以确定作用或结果的指令集。该算法是事件的接收器，其是内部事件的发生器并且是外部(输出)事件的创造者。该算法本身被模块化地构成以便允许按照构造的方式处理复杂的问题。该结构集中在将该问题分成专用于给定任务的多个功能单元。模块性进一步允许包括或排除效果，这取决于问题需要。通过附加的直观推断(heuristics)来过滤最终的行为。因此在较高的程度上，每个模块都能够看作是效果的叠加。但是核心上没有约束每个模块如何处理。因此高级模块化的功能如下：管理和内务处理(housekeeping)；监视和状态信息；处理主要事件；核心控制作用(对于提供血糖控制是很重要的)；以及校正性作用(corrective action)。

管理和内务处理

管理和内务处理模块如下：初始化/准备；处理错过的周期(missedcycle)；事件映射；胰岛素容器(bucket)；组分作废(componentnullification)；数据库；和实现协议。初始化/准备是管理过去、当前和将来的信息的状态向量。处理错过的周期是处理该过程100的重新启动或者出于任何原因(如故障保险)而跳过的算法调用。事件映射将外部事件集映射到内部事件集。胰岛素容器管理来自各个模块(如组件)的胰岛素建议以充满和腾空容器。组分作废解释如下。一般而言，当解决方案作为当前解决方案，其中即使生理机能的输入和输出都是在解决(i)作为单一组分或者(ii)分组的模块效应的问题时各种组分的净效应，该作废步骤也允许除去在考虑该单一组分或分组的模块效应的过程中不需要的效应。因此，例如，胰岛素作废是从最终的胰岛素输送中排除(negate)来自该控制作用的前馈项(feed-forward term)的任何胰岛素组分。内部丸剂管理输送由进餐事件引起的前馈丸剂。内部丸剂管理允许(i)创建内部事件和(ii)将内部事件分组。由此归纳疗法要素的管理，并且该疗法要素的管理允许根据改变的需要和新信息的可用性而灵活地增加或去掉效应。为数据的检索和存储以及记录信息而提供数据库。实现协议是按照一般事件结构而设计的协议格式，用以允许由保健供应者根据需要动态地创建协议活动。该协议的一个方面是支持用于为分析和生成患者特定信息而生成最少信息的顺应性。

监视和状态信息

用于监视和通知状态的模块如下：葡萄糖更新、过期的葡萄糖、自我丸剂(self-bolus)、进餐忠告、协议忠告、故障保险和主要事件处理机。葡萄糖更新跟踪与顺从性和测量需要有关的新的葡萄糖测量值的可用性，并为该用户生成信息。过期的葡萄糖通知用户是否需要也与顺从性和测量需要有关的新的葡萄糖值。并且也为该用户生成信息。自我丸剂说明借助于自我丸剂命令(内部活动)的任何胰岛素差异。进餐忠告通知该用户开始进餐。顺从性问题覆盖碳水化合物摄入，并且可以扩展到其他监视和通知。协议忠告通过生成内部事件来通知该用户即将来临的或迫近的活动。故障保险系统地通知应答者(例如患者或监控器设备)用户正在关闭该设备或者系统，并且建立警报创建时间窗，在此期间如果该设备和/或系统没有起来(up)或没有进行调用以不考虑(override)该警报，那么提供用于伸出(reach out)的紧急调度或可替换的形式来予以帮助。主要事件处理机是用于处理主要事件的模块，主要事件如预备锻炼、锻炼、受命令的丸剂以及进餐补偿器。预备锻炼重做在预期锻炼控制器中的基本需要，并且在特定锻炼的开始通知该控制器。锻炼保持在该锻炼的持续时间内升高的葡萄糖设定点，然后返回到其葡萄糖设定点。受命令的丸剂是附加的胰岛素丸剂的要求(用户控制)，并允许异步命令。进餐补偿器通知该控制器碳水化合物的摄取。可替换的状态/触发事件覆盖可替换的状态和触发事件。

核心控制作用

核心控制作用模块形成对于提供血糖控制很重要的核心控制作用，并且其如下：过程传感器数据、胰岛素设定点、葡萄糖预测、胰岛素建议模块、锻炼补偿器、速效的碳水化合物摄取、进餐补偿器、模型选择、模型参数确定/更新、患者表征、管理差异、最终输送的胰岛素，以及最终建议的胰岛素。过程传感器数据根据可用的测得葡萄糖值来确定葡萄糖值，例如通过传感器单元获得的间质液的值(isf)和/或通过外部仪表获得的血糖(bG)值。胰岛素设定点是用于保持目标基础葡萄糖的胰岛素注入速率(即对于给定的基础胰岛素速率而达到的葡萄糖值)。葡萄糖预测用来利用过去的葡萄糖测量值、过去的胰岛素测量、过去的事件和将来安排的事件来预测控制周期的葡萄糖值。错过的周期是无论什么时候在控制周期中没有调用算法。注意，葡萄糖可以是测得的葡萄糖或者预测的葡萄糖，如通过讨论的上下文中确定的。测得的葡萄糖是从葡萄糖传感器获得的葡萄糖值。预测的葡萄糖是根据已知的葡萄糖值利用模型而确定的将来的葡萄糖值。疗法目标葡萄糖是用户想要达到的葡萄糖值。目标葡萄糖/葡萄糖设定点是控制器设法通过反馈而渐近地达到的葡萄糖值。基础控制作用计算胰岛素剂量以保持基础葡萄糖。这种确定基于模型和或规则集。

锻炼补偿器处理增大的身体活动水平。这种确定基于模型和或规则集。速效的碳水化合物摄取处理速效的碳水化合物的摄取以补偿预期的葡萄糖下降。这种确定是基于模型和或规则集。进餐补偿器计算进餐事件的胰岛素丸剂(boli)分布。这种确定基于模型和或规则集。开环基础实现实现了在开环控制器期间的基础胰岛素。这种确定基于规则集。模型选择是确定最好地解决患者需要的适当模型，如上面关于图4描述的过程100的一部分。这些规则基于生活方式选择、所用的过去的事件、将来的事件，和协议，和/或简单地基于保健专业人员的选择。模型参数确定/更新为所选择的模型而确定参数。该确定利用在先的数据、由设备收集的数据、参数确定设置。患者表征是什么时候评价患者特定参数的选择或利用基于群体的模型。所确定的模型和参数经历许多检查，如果结果满足并保持某个已知的期望值，那么选择所确定的参数，否则将次优的这种基于群体的参数集用于疗法确定，控制葡萄糖。疗法参数确定/更新也如先前在上面关于图4的过程100而描述的。管理差异是当识别受命令的胰岛素对输送的胰岛素之间的差异时管理该胰岛素容器。最终输送的胰岛素是为该周期所配发的胰岛素的量。最终建议的胰岛素是由该算法计算出并传给保健专业人员作为建议的胰岛素的剂量。

校正性作用

校正性作用是能够用于采取校正性作用的模块，这些校正性作用如下：碳水化合物修正、高葡萄糖干预、低葡萄糖干预和进餐葡萄糖区。碳水化合物修正重做以前录入的进餐事件(碳水化合物值)，并且相应地校正胰岛素输送。高葡萄糖干预借助于胰岛素输送而校正高的葡萄糖水平。低葡萄糖干预借助于摄取速效的碳水化合物来校正低的葡萄糖水平。进餐葡萄糖区将葡萄糖目标定义为带而不是定义为线。在其他实施例中，可以使用其他适合的校正性作用。

向(i)设备(ii)算法和(iii)执行任务/事件的用户呈现协议特定时间表

协议是连续的事件的有计划的执行。遵守该计划允许(i)改进的处理(ii)能够将所收集的数据用于特定的分析并且确定医疗作用或者(iii)一般使用情况，其中制定生活方式的计划，如饮食计划、锻炼计划、进餐的定时、膳食的组成成分。这在用刚才的数据(just data)而且是用正确的定时和相关联的事件收集的数据来支持保健供应者是有关系的，所述相关联的事件如具有特定脂肪、蛋白质和碳水化合物含量的进餐。因此协议是特定的连续的事件单元，其由bG测量、丸剂命令、膳食摄取和锻炼组成。这些事件能够以许多模式来触发，如对手持设备进行编程，患者遵循的简单的基于纸件的描述、自动化服务，如帮助患者的顺应性顾问。

对特性输入进行存储并且从数据库检索特性输入

数据库是中央信息存储单元。数据库用于存储并检索事件和用户特定设置。存储的事件覆盖过去的、现在的和安排的将来的事件。在存储事件信息方面，数据库用作正在进行的现在和过去的活动的日志，其用于检索过去的和将来的事件，并且其用于触发安排的事件。现在在下文提供上述系统、过程和软件模块的特定实现，以促进进一步理解本发明。

特定实现的实例

在下面说明性的实施例中，将上述装置和方法成一体地加以描述，所述实施例增强了保健供应者收集、分析和确定用于处理如糖尿病的慢性病的疗法的能力。在第一个说明性的采用DTPS方法的实施例中，公开了一种自动胰脏测试台(APTS)程序。APTS是一种用于控制临床设置中的糖尿病研究对象的软件程序。在第二个说明性的也采用DTPS方法的实施例中，公开了一种自动胰脏控制算法测试套件(APCATS 900)程序。APCATS 900是一种在仿真环境中分析糖尿病研究对象的软件程序，其例如在客户端计算机14(图2)上运行。参考图5，首先讨论APTS程序，随后在后面的章节中讨论APCATS900程序。

自动胰脏测试台(APTS)程序

参考图5，APTS程序500在常规计算机(例如膝上型电脑、个人数字助理(PDA)、智能电话等)上运行，并且提供两个独立的软件组件：自动胰脏软件(APS)502和自动胰脏软件通信应用程序(APSCOM)504。如在后面章节要解释的，APS 502为胰岛素建议而周期地调用所包括的算法壳(algorithm shell，ALGOSHELL)506，并且与APSCOM 504发生相互作用。之后在后面的章节中提供对ALGOSHELL 506的讨论。APSCOM 504负责收集来自便携式单元(PU)508的信息、与APS 502相互作用，以及将信息存储到数据库并从数据库检索信息，所述数据库如数据库24(图2)。在一个实施例中，PU 508是设备48(图2)，在另一个实施例中，PU 508是测量葡萄糖浓度的传感器，例如Subcutaneous Continuous GlucoseMonitor(皮下连续葡萄糖监视器)(SCGM)，其是由RocheDiagnostics Corporation开发的基于微量渗析的设备，用以进行频繁的葡萄糖测量。在又一个实施例中，便携式单元508是胰岛素泵或胰岛素泵系统，例如Roche Diagnostics的

Spirit胰岛素泵系统。在胰岛素泵系统的实施例中，APSCOM 504可以与PDA上提供的软件进行通信，向其提供该胰岛素泵系统，或者如果在同一个PDA上运行APTS，那么向其提供胰岛素泵控制软件。

还提供控制器模块调用ALGO 510，其确定胰岛素输送方案，并且通过ALGOSHELL 506向APS 502传送剂量。根据这里的方案，其意味着时间和值成对。ALGOSHELL 506执行一些标准系统功能，如状态管理、ALGO调用筛选(screening)、单元转换，以及确定配发的量。APS 502负责以周期性的时间间隔调用ALGOSHELL 506，该周期性的时间间隔在这里称为控制周期(control cycle)。APS 502也周期性地与APSCOM 504相互作用。在一个实施例中，APSCOM504利用

技术与诸如APS 502的程序和数据库24(图2)通信，该数据库在一个实施例中可以是以

Access数据库来实现。在其他实施例中，可以利用其他通信框架和数据库应用程序来实现本发明，如.net框架、Unix、Oracle、SQL、java等。APTS程序500也提供用户接口512，该APS 502用于显示数据并接收来自HCP和/或患者的事件信息。

系统工作流程

这一章节说明了系统的工作方式和工作流程，以及直接属于控制器ALGO 510的各种高级APS-ALGO调用顺序。该系统中每个控制周期T_C的事件顺序对应于在图5中用圆圈包围的字母A-J。APS 502以时钟机构的方式来驱动该系统，图5中详述了一些关键时间描述符。在事件A(时间-T_Δ)，APS 502调用APSCOM 504，并且获得新的传感器数据集和配发的净胰岛素的数据。现在将关于控制边缘的时间设定为0，在事件顺序B，APS 502调用ALGOSHELL 506。然后ALGOSHELL 506更新状态信息、进行单元变换、检查该方式，并为胰岛素建议而调用ALGO 510。ALGO 510将该建议返回给ALGOSHELL 506。ALGOSHELL 506进行变换，然后更新状态并返回给APS 502。在事件顺序B完成之后，ALGOSHELL 506将建议返回给APS 502，这是事件顺序C。这称作SYNC-1调用。

在事件顺序C完成之后，在事件顺序D，APS 502打开在用户接口512中的建议窗口514，并等待用户经由使用输入设备来接受或取消该建议，所述输入设备如设备40(图2)。APS 502等候输入，直到建议窗口超时。在事件顺序D完成之后，该建议窗口对于事件顺序E返回APS 502。如果用户确认该建议，那么完成了事件顺序E，那么对于事件顺序F来说，APS 502打开在用户接口512中的确认窗口516并等待用户经由输入设备(例如设备40)接受或取消该确认。APS 502等候输入直到确认窗口超时。在完成事件顺序F之后，对于事件顺序G，该确认窗口返回APS 502。然后，对于事件顺序H，APS502根据用量来调用ALGOSHELL 506，该用量或者是(a)由用户确认的，(b)用户调零的，(c)或者在超时情况下，满足阈值要求的除0之外的量(an amount that meets a threshold requirement，else 0)。第二ALGO调用称为SYNC-2调用。注意，阈值要求是输送给研究对象的取得一致意见的建议的胰岛素剂量，除非保健专业人员否决。在事件顺序H完成之后，ALGOSHELL 506将最终的控制量返回给APS502用于事件顺序I，然后APS 502将丸剂命令发给APSCOM 504用于事件顺序J。这结束了该控制周期。

ALGO

这一章节进一步阐明ALGO 510的关键的工作方式。对于疗法来说，以可靠且及时的方式提供剂量是非常重要的。在下面的章节中，处理ALGO 510的下面的几个方面：定时方面-基于指数(indexbased)的ALGO 510怎样确定经过的真实时间；存储器持续时间-用于确定新的建议所需的既往史的长度(系统存储器)；错过的周期-ALGO 510如何处理错过的调用；操作模式；以及调用在ALGO 510中提供的经验算法模块(EA)518。EA 518是用于建议胰岛素剂量的规则库增强疗法策略的汇集，该汇集调用和/或提供许多功能模块56(图3)。胰岛素用量建议基于最近一次的葡萄糖信息和事件信息，如进餐、锻炼、干预等。增强疗法是对于依赖胰岛素的糖尿病的一种治疗方式，其中主要目的是保持血糖水平尽可能接近正常范围。该治疗由以下组成：一天进行三次或更多次胰岛素注射或利用胰岛素泵；一天四次或更多次血糖测试；基于血糖测试结果来调整胰岛素、食物摄入和活动水平；饮食咨询；以及由糖尿病组的管理。EA 518通过连续监视葡萄糖和以频繁的有规律的间隔实施增强疗法规则来扩展该原理。利用最近的葡萄糖测量、过去的葡萄糖输送信息和诸如进餐、锻炼、干预等的事件信息来评价胰岛素剂量建议。在一个实施例中，通过提供开放式体系结构很方便地进行对EA 518的这种更新，该开放式体系结构允许用修订的经验算法来代替/更新现有的EA 518。可以在本发明中实现的一个这种适合的开放式体系结构方法在共同未决的序号为、发明名称为的美国申请中公开，其代理人案号为ROP0015PA/WP US，其转让给了本申请公开内容的受让人，并且该美国申请的公开内容在此引入作为参考。

如在EA 518的定义部分和APTS 500的其他模块中所用的，表2中列出了这些符号，其具有下面的术语。

表2-术语

定时方面

如所提及的，APTS是实时系统，其中定时是定量给药的关键方面。EA 518利用不依赖于实时的数字补偿器，其确定适当的控制量。EA 518构成为使其不具有实时意义而是利用存在于可变阵列(variable array)的指数中的定时。换句话说，EA 518的作用在某种意义上是基于指数的，时间的概念暗含在通过对控制周期T_C的选择中。例如，胰岛素药效学定义为胰岛素剩余的一维阵列I_r[i]，其中第i个元素间接地表明在经过的时间t＝(i-1)T_C时的胰岛素剩余。因此，在第i个指数和时间t之间存在对应关系。

如图20所示，ALGO 510控制器的定时描述不仅取决于日时而且取决于自从实验开始(例如作为处方的已实施的疗法建议的开始)所经过的时间。项T_A ⁰代表实验开始的时间并且由APS 502来存储。将该时间变换成分钟，并且代表从午夜开始的以分钟为单位的时间。项t_a是从午夜开始的以分钟为单位的实际日时。项t是相对于该实验开始所经过的时间，其中相对时间t＝0表示实验开始。K＝1项指的是第一个控制周期。每个随后的周期都增加1。项k表示目前的第k个周期。每个控制周期T_C都具有一对控制边缘、开始时间t_s和结束时间t_e。在任何给定的相对时间t，ALGO 510都确定对于目前的时间T来说当前调用位于哪个控制周期T_C。关键在于所实施的实时控制系统具有柔和的时间控制。这意味着对ALGO 510的调用并不精确地在控制周期T_C的起始边缘，而是在开始时间t的控制边缘周围的某个时间精度之内。项T_Δ是从控制边缘的时间偏差，并且是瞬时的，在该瞬时由APS 502发送和获得数据请求。例如，一个值可以代表一个时间，在该时间PU 508经由APSCOM 504将从各种设备收集的数据传送到APS 502。项

是APS 502将受命令的胰岛素传送到PU 508的时间。项T_δ是超时-相对于控制周期T_C的开始时间t_s的边缘而显示的用于建议和确认窗口的窗口的最长持续时间。

存储器持续时间

EA 518利用过去的信息和目前的信息来计算用于ALGO 510的胰岛素建议。需要该信息的时间段取决于该系统花费多长时间来清除输入的效应。如果胰岛素活动持续时间是T_D ^I分钟，那么如方程式(4)给出的：

$n=\mathrm{ceil}\left(\frac{T_D^I}{T_c}\right)---\left(4\right),$

其中n是保持该信息的周期数。为了覆盖错过的周期的情况，还需要几个额外的控制周期作为缓冲。在这种情况下，n_H定义为n和预期的错过的周期的最大数的总和。管理ALGO 510的必要的(且充分的)范围是为了保持在n_H个周期中的历史。

错过的周期

ALGO 510负责处理所有新的信息输入并将该信息转变成疗法。错过的周期是ALGO 510未被调用的控制周期。如果全部APTS 500是完整的，那么在每个控制周期T_C都将调用ALGO 510。然而，可能会错过调用。如果错过了周期，那么对于每个错过的周期都迭代地执行ALGO 510。这意味着，当发生错过的周期时，那么疗法是未决的，直到调用ALGO 510。ALGO 510检测错过的调用，并在执行当前调用之前单步调试每个错过的周期。这确保这些事件既不会被错过也不会被重复，并且顺序地处理这些事件。错过的周期可能由于各种原因而出现。只要传到ALGO 510的信息没有差异，那么同步就是准确的。在处理这种场景中，ALGO 510首先确定是否错过了调用。如果发现没有错过调用，那么ALGO 510执行各个EA 518模块。当ALGO 510检测到错过调用时，ALGO 510在评价当前调用之前首先执行所有错过的调用。

操作模式(Mode of Operation)

ALGO 510所支持的操作模式是纯控制(Pure-control)和受控Obs(Controlled-Obs)。参考图6，用于EA 518的纯控制操作模式600是闭环系统，其利用葡萄糖测量来提供适当的控制作用。ALGO510的任务是要保持葡萄糖在预先确定的目标葡萄糖水平601。在控制器初始化过程中或者无论什么时候干扰了研究对象，那么预期葡萄糖会偏离目标葡萄糖水平601。纯控制利用葡萄糖测量和输送的胰岛素信息以“理解”该研究对象的状态。在图6的右下角，研究对象块602连接到葡萄糖传感器604和胰岛素泵606。这些设备经由便携式单元502(图5)的FR链路608而与APS 502间接地接触，该RF链路608用虚线示出。源于事件块612的虚线610表示已知事件的发生。ALGO 510可以使用这些事件的信息。事件处理机614提供在外部事件描述与内部事件方案之间的适当映射。ALGO 510触发适当的模块以处理已知的干扰，其包括命令胰岛素模块616、高葡萄糖干预模块618、进餐补偿器模块620、锻炼补偿器622，或者低葡萄糖补偿器模块624中的至少一个。葡萄糖预测器626和基础控制器628处理未知的干扰和建模误差。控制器的初始化是未知干扰的一种情况。控制器必须使实验开始时以及将模式从受控Obs模式700切换到纯控制模式600时的初始葡萄糖值稳定。在这些情况下，纯控制模式600的性能依靠来自过去事件的信息的可用性以使研究对象从某个初始葡萄糖值平稳地达到目标葡萄糖值。闭环容器管理块630确定和管理净胰岛素建议。在后面的章节中讨论胰岛素输送模块632、葡萄糖过滤器模块634和胰岛素剂量作废模块636。

纯控制模式600是一种胰岛素建议，其利用葡萄糖测量和内部/外部输入事件来保持血糖控制。保健专业人员通过接受胰岛素建议而主动地结束该循环，其将开关638改变为该模式。操作模式产生了在开环HCP管理的胰岛素建议与半闭环ALGO确定的胰岛素建议之间的差别。即使这两种模式由保健专业人员来设定，也会存在ALGO510将其自身放在受控Obs模式700中的情况。这发生在满足下面的条件时：没有bG条件，其发生在由于测量延迟而引起的葡萄糖测量不可用时(例如，在实验的开始，如果其完全出现)；以及过期的bG测量，其表示自从上一次可用的葡萄糖测量开始以后的时间超过可容许的葡萄糖有效期。现在参考图7讨论该受控Obs模式700。

受控Obs模式700是纯控制模式600的一种特定情况，在图7中用框图示出。用户疗法通过使用研究对象的预编程序的泵的基础速率来实现，并且通过利用受命令的丸剂事件而增加。这是开环控制，该疗法由保健专业人员或者研究对象进行手动地管理。因为描述类似于针对纯控制模式600所提供的描述，因此同样的元件用同样的符号来表示。ALGO 510主要利用合理的工作方式、葡萄糖测量、胰岛素输送和记录的事件来保持历史数据并更新状态向量。然而，仅仅两个事件模块是可适用的，即受命令的丸剂模块616和高葡萄糖干预模块618。这些模块使研究对象或保健专业人员能够管理该疗法并控制胰岛素丸剂。在受控Obs模式700中不执行进餐补偿器事件620、锻炼补偿器事件622和低葡萄糖干预事件624。基础速率控制628是编程的泵分布曲线的复制。

经验算法调用

经验算法(EA)518构造为一组模块。每个模块都处理疗法推荐的一个方面。图8和9是EA 518的流程图，其示出根据本发明实施例的所有模块和执行次序。其仅仅用于说明的目的，并且能够在次序实施例中按许多方式排序。图8和9的圆圈中示出的点9X和9Y是图与图之间的链接。每个模块都构成为促成最终的疗法建议的独立的行为。因此，每个模块都能够被看作多个效应的叠加。将每个模块用字母A-E编号，其代表模型组，并且其各自的图注提供了构造信息。这些模块组及其相关联的字母是：“A”-核心控制作用(对于提供血糖控制是很重要的)，“B”-管理和内务处理(顶级)；“C”-监视和状态信息；D-“校正性作用”，以及“E”-处理主要事件。之后提供关于这些模块组中每一个模块组的概括讨论。

核心控制作用

用于核心控制作用并且对于提供血糖控制很重要的模块是：处理传感器数据806、胰岛素设定点804、葡萄糖预测838、胰岛素建议模块846、锻炼补偿器822、速效的碳水化合物摄取824、进餐补偿器840和开环基础实现逻辑850。处理传感器数据806包含根据可用的测得葡萄糖值来确定葡萄糖值的策略。胰岛素设定点804是保持目标基础葡萄糖所使用的胰岛素注入速率。葡萄糖预测838根据最近已知的葡萄糖测量值来预测控制周期的葡萄糖值。胰岛素建议模块846计算胰岛素剂量以保持基础葡萄糖。锻炼补偿器822处理增大的身体活动水平。速效的碳水化合物摄取824处理速效的碳水化合物的摄取以补偿预期的葡萄糖下降。进餐补偿器840为进餐事件计算胰岛素丸剂分配。开环基础实现850在开环控制器的控制obs700(图7)的过程中实现基础胰岛素。

管理和内务处理(顶级)

在ALGO 510工作方式的顶级是与管理和内务处理有关的问题。管理和内务处理模块是：初始化/准备800、处理错过的周期801、事件映射802、胰岛素容器848，和胰岛素作废836。初始化/准备模块800是管理过去、现在和将来的信息(ALGO存储器)的ALGO状态向量。处理错过的周期模块801在前面的章节中已经讨论过，其处理APTS的重新开始或出于任何原因而跳过的ALGO调用。事件映射802将外部事件集映射到内部事件集。胰岛素容器848管理来自各个模块的胰岛素建议作为充满和腾空该容器的组分。胰岛素作废836从最终的胰岛素输送中排除来自控制作用的前馈项的任何胰岛素组分。内部丸剂管理844输送由进餐事件所产生的前馈丸剂。

监视和状态信息

用于监视和通知状态的模块是：胰岛素更新808，其跟踪新的葡萄糖测量值的可用性。过期葡萄糖814通知用户是否需要新的葡萄糖值。自我丸剂810借助于自我丸剂命令来说明任何胰岛素差异。警告没有葡萄糖是一种故障保险，其告知系统该PU502(图5)没有响应并且监控设备电路应当使定时器开始倒数计时，如在前面章节中所描述的。进餐忠告842通知用户开始进餐。

校正性作用

用于校正性作用的模块是：碳水化合物修正834、高葡萄糖干预832、低葡萄糖干预826、进餐葡萄糖区820，和管理差异818。碳水化合物修正834重做前面录入的进餐事件(碳水化合物值)，并相应地校正胰岛素输送。高葡萄糖干预832借助于胰岛素输送来校正高的葡萄糖水平。低葡萄糖干预826借助于摄取速效的碳水化合物来校正低的葡萄糖水平。进餐葡萄糖区820将葡萄糖目标定义为带而非线。当识别在受命令的胰岛素对输送的胰岛素之间的差异时管理差异818管理葡萄糖容器。

主要事件处理机

用于处理主要事件的模块是：预备锻炼828，和受命令的丸剂830。预备锻炼828重做锻炼控制器预期的基础需求，并且在特定锻炼开始时通知该控制器。受命令的丸剂830请求附加的胰岛素丸剂。尽管EA 518的上面的模块描述对于某些模块来说在性质上是概括的，但是之后提供对这些模块的更为详细的讨论。

事件映射

在使初始化和准备模块800以及处理错过的周期模块801运行之后，那么ALGO 510使事件映射模块802运行从而通过由APS 502接收的事件来获得外部干扰信息。例如，在一个实施例中，在APTS500的用户接口512的下拉列表中显示外部事件以供用户选择。ALGO 510对于那些对ALGO本身来说是特定的事件起作用。这些是被调用的内部事件。用户选择的每个外部事件都被映射到至多一个内部事件。向这些外部事件提供用于最终用户所涉及的描述符，和/或当这些外部事件被选择时其触发ALGO作用。这些描述符可以是用户特定的，并且可以支持多种语言。

在一个实施例中，存在与同一个内部事件有关的多个外部事件描述符。例如，“自我丸剂”和“填装丸剂(priming bolus)”是分开的外部事件描述符，但是在内部这两个事件都指向同一个内部事件类型(称为自我丸剂)。因此，具有指向同一个内部事件的多个外部事件是可能的(多对一)。标3列出了基本的内部事件，ALGO 510根据这些内部事件而工作。

表3：用于EA的基本内部事件表

内部事件	描述
		Snake	碳水化合物摄取
Breakfast	碳水化合物摄取
		Lunch	碳水化合物摄取
Supper	碳水化合物摄取
		Fast_Carbs	速效的碳水化合物，通常在锻炼过程中触发

Self_Bolus	手动地命令泵以输送ALGO 510没有看到的胰岛素
		Prep_Exercise	减少胰岛素从而在锻炼开始时允许预期的葡萄糖下降
Exercise	锻炼活动的实际开始
		HI_BG_Intervention	对高血糖所进行的校正，其中反馈部分看不见HCP录入以校正高血糖的附加的受命令的胰岛素部分
LO_BG_Intervention	通过塑造葡萄糖目标而对低血糖所进行的校正
		Insusion_Rate	定义在实验开始时的基础速率
Prime_Pump	手动地命令泵从而为填装的目的而输送胰岛素
		Commanded_Bolus	命令泵输送胰岛素
CarbRectification	对上一次进餐录入进行校正

胰岛素设定点

接着，EA 518运行胰岛素设定点模块804。对于该模块804，基础胰岛素速率(即为保持葡萄糖值而使用的胰岛素注入速率)是在正常情况下为有代表性的一天所定义的基础分布曲线。然而，如研究对象的生活方式所看到的有代表性的一天和用于驱动ALGO 510的有代表性的一天是相当不同的。例如，并且如这里所用的，存在两种基础胰岛素分布曲线：(a)泵分布曲线和(b)ALGO定义的分布曲线。对于泵分布曲线来说，基础速率随日子而变化。预先编程的速率可以包括覆盖部分正餐和其他典型事件的胰岛素。定义的分布曲线是用户特定的，并且定制为研究对象的日程表和生活方式。对于ALGO定义的分布曲线，在对管理如进餐和锻炼的事件所需的丸剂进行分析和去掉之后再确定该分布曲线。为了确定ALGO定义的分布曲线，EA 518将密集的数据监视用于新的研究对象。对于已经经历一个实验的研究对象来说，该临床数据用于确定ALGO定义的分布曲线。这些通过实验协议和支持工具进行确定，支持工具如纠缠(ravel)和解开工具。这样确定的所提取的基础速率不依赖于与事件有关的胰岛素剂量。该ALGO定义的分布曲线保存为基础集(basal set)。

该基础集以三列阵列矩阵示出，其由研究对象初始化文件(即Subject-ini文件)来定义。其包含时间、基础速率，和基础葡萄糖。表4是在研究对象的初始化文件中的基础集的例子。

表4：基础集实例

自午夜开始的时间[分钟]ta	基础速率[U/h]I1 B	葡萄糖[mg/dL]G1 B
			0	0.6	110
480	1.3	110
			960	1.0	110
1290	0.6	110

该基础速率是目标葡萄糖值和日时的函数。每目的基础速率分布曲线定义为对于时间t_a的以U/hr为单位的胰岛素的固定流速。时间t_a从午夜开始以分钟为单位来定义，按照时间的升序来设置胰岛素分布曲线。实施固定流速，直到达到下一组胰岛素流速。基础速率分布曲线在每个24小时的时间段内自我重复。基础胰岛素速率对于维持目标葡萄糖是必须的(integral)。给定的胰岛素速率和相对应的葡萄糖值确定了对于保持给定的目标葡萄糖值所需的胰岛素速率。假定该胰岛素速率是目标葡萄糖的线性函数，并且根据方程式(5)给出：

$I^B=I_1^B+(G^B-G_1^B)\frac{\mathrm{\ΔI}}{\mathrm{\ΔG}}---\left(5\right),$

其中G^B是目标葡萄糖值，I^B是用于保持葡萄糖值G^B的胰岛素速率，G₁ ^B是对于给定的日时在基础集中定义的葡萄糖值，I₁ ^B是用于保持葡萄糖值G₁ ^B所需要的胰岛素速率，是每个葡萄糖变化的胰岛素速率。例如，图10用图表示出了上面的设定点关系。特别是，图10中的线X示出当 $\frac{\mathrm{\ΔI}}{\mathrm{\ΔG}}=\frac{0.1U/\mathrm{hr}}{10\mathrm{mg}/\mathrm{dL}}$ 定义为常数时作为葡萄糖设定点的函数的正午时的基础胰岛素速率。线Y类似地示出相同的正午时的基础胰岛素速率，只不过是在较低的设定点(0.8对1.3)。然而请注意，夸大了斜率以示出这种胰岛素-葡萄糖的关系，并且这仅仅是一个说明性的实例。

处理传感器数据

在通过胰岛素设定点模块804运行之后，EA 518现在继续调用处理传感器数据模块806。处理数据模块806从传感器收集数据，所述传感器例如葡萄糖传感器604(图7)，并且将该数据分类为原始(raw)数据。对该原始数据连同该传感器状态一起进行处理和分析以确定葡萄糖值和测量时间。例如，该过程应当从过去和当前数据集中去掉界离群值(outlier)并且去掉诸如传感器状态和次级传感器的其他信息，以确定最可靠和准确的葡萄糖值。根据已经提供该原始数据的传感器的类型利用两个处理函数之一。

第一处理函数找到并使用最新一次录入的葡萄糖数据点。该函数通过向后经过每个控制周期来搜索控制周期可用的任何葡萄糖数据，直到其成功地找到(多个)葡萄糖值的集合的位置或者用完葡萄糖数据为止。如果葡萄糖数据集为空，那么返回空的葡萄糖向量。在确定非空的葡萄糖集合时，将时间窗长度T_C定义为(t_G-T_C，t_G]。报告(多个)葡萄糖值的平均值， $G\left[K\right]=\frac{\underset{i=1}{\overset{\mathrm{\θ}}{\mathrm{\Σ}}}{g}_i^K}{\mathrm{\θ}}.$ 第k个指数处的葡萄糖值对应第k个周期(Glucose value at K^th index for k^th cycle)。所分配的葡萄糖时间戳t_G[K]为所选择的控制周期的结束时间。图11用图表示出利用上面的变量而为第一处理函数选择时间间隔。

在当前葡萄糖传感器的工作特性提供数据范围时，例如由皮下连续葡萄糖监视器来使用第二处理函数。在该实例中，该数据范围具有20mg/dL的下限和450mg/L的上限。在该实例中，没有规定其他可能的葡萄糖速率限制。在一个实施例中，该传感器通过给该数据赋0值而记录超出该范围的无效的葡萄糖数据。同样，因此由处理传感器数据模块806从原始数据中去掉这些无效的葡萄糖值 $(g_i^k=0)$ ，这些无效的葡萄糖值不会包括在任何定量分析中。在一个实施例中，显示出用以警告用户上限和下限的弹出消息。

当为EA计算葡萄糖值时，仅仅考虑主要的传感器数据。选择最新的(多个)可用的葡萄糖值。时间窗长度T_C定义为：(t₁-T_C，t₁]。选择在选定窗口上的可用的葡萄糖值，并且选择该中间值(median)： $G\left[K\right]=\mathrm{median}(g_{\mathrm{\θ}}^K,...,g_i^K,...,g_2^K,g_1^K).$ 第k个指数处的葡萄糖值对应第k个周期。计算时间的中间值并返回为 $t_G\left[K\right]=\mathrm{median}({\mathrm{\τ}}_{\mathrm{\θ}}^K,...,{\mathrm{\τ}}_i^K,...{\mathrm{\τ}}_2^K,{\mathrm{\τ}}_1^K).$ 注意，中间值时间t_G[K]应当在所需要的地方由EA 518四舍五入成最接近的控制周期边缘。图12示出了为第二处理函数选择时间间隔。

葡萄糖更新

在收集和处理该原始数据之后，那么EA 518继续调用葡萄糖更新模块808。葡萄糖更新解释了葡萄糖可用性的一个方面及其对ALGO 510的内部工作方式的含意(implication)。其不与在ALGO510外面的最终用户直接相关。得到最新的葡萄糖值对于保持血糖控制是至关重要的。由于传感器延迟和/或传感器故障，需要葡萄糖预测器来得到当前葡萄糖的估计。当该传感器提供新的葡萄糖值时，胰岛素建议模块846利用最新测得的葡萄糖来重做葡萄糖预测。然而，在缺乏新的葡萄糖信息时，利用在控制周期过程中确定的预测葡萄糖来代替，从而预测当前周期的葡萄糖。在这种情况下，该状态信息有效地用于从上一个控制周期前进到当前的新的周期以预测葡萄糖。该葡萄糖更新模块808因此识别新的葡萄糖测量集合是否可用，以及是否利用上一次预测的葡萄糖，并继续。

自我丸剂

然后EA 518调用自我丸剂模块810来通过从该泵访问关于自我丸剂命令的信息来说明任何胰岛素差异。需要物理地访问该胰岛素泵有几个原因，例如电池更换、胰岛素管道的变化，或者用户想要手动地控制丸剂。其一个方面在于在每个控制周期开始时在净胰岛素输送项中看到任何手动命令的丸剂。由于ALGO 510不建议手动命令的丸剂，因此EA 518将把该丸剂看作是剂量超出。因此说明确定的胰岛素超出，并且在将来的控制作用期间通过反馈来调整。为了系统地处理这种情况，在手动丸剂作用之前必须触发自我丸剂事件。因此，ALGO 510期望超出量等于录入的自我丸剂量。利用该事件也确保了适当地解释所有的手动丸剂。未解决的丸剂是受命令的丸剂的剩余物。未解决的丸剂具有有限的时间窗，在该时间窗内自我丸剂量应当得到解决。利用剂量超出来解决该量；否则将未解决的丸剂(即自我丸剂数量的余数(balance))设定为零。将该事件限制为有限的持续时间的另一个原因是为了在用户通知测试台过量但是未从泵命令丸剂的情况下清除该存储器作为安全预防措施。在将未解决的自我丸剂量设定为零之前，没有葡萄糖忠告模块812向用户显示没有葡萄糖报警消息。

过期的葡萄糖测量

在收集和处理该原始数据并且如果合适则发送警告之后，那么EA 518继续进行以调用过期的葡萄糖模块814。葡萄糖预测器的准确性和可靠性在预测长度增大时下降。如果所接收的上一次的葡萄糖值比某个规定时间窗更长，那么ALGO 510强制执行开环受控Obs模式700(图7)作为安全预防措施，并实施预先编程的基础控制。通过在受控Obs模式700下工作，该疗法被限制成编程到胰岛素泵的基础分布曲线中，并且如果需要，则通过已揭示的功能的子集而扩充。过期的葡萄糖模块814的任务是借助于弹出消息来提供与待决的过期葡萄糖状态有关的信息。当达到过期的葡萄糖状态时，该过期的葡萄糖模块814切换适当的标志以强制执行受控Obs模式700。提供新的主要葡萄糖测量将修正(rectify)该情况。相应地，过期的葡萄糖表明该葡萄糖预测不再有效，并且迫使该控制器进入受控Obs模式700。

过期的葡萄糖模块814提供下面的警告：预先警告该操作者、警告该操作者，和葡萄糖测量过期。关于预先警告该操作者，借助于日志窗口预先警告用户待决的截止时间。在期满之前的倒数计时的警告周期中，反复地通知用户在截止期限之前还剩下n分钟。此外，出现下面的消息“警告：葡萄糖将马上过期，请录入当前的葡萄糖(WARNING：Glucose will be outdated soon.Please enter currentglucose.)”。关于警告该操作者，在最后一个截止期限周期和之后的每个周期都强行弹出消息，直到接收到新的葡萄糖测量。该消息呈现：“警告：葡萄糖在下个周期将过期。请录入当前的葡萄糖(WARNING：Glucose will be outdated next cycle.Please entercurrent glucose.)”。关于葡萄糖测量过期，在过期的葡萄糖条件的过程中，如果ALGO 510处于闭环纯控制模式600中则ALGO 510应当迫使其进入开环受控Obs模式700中，并且实施该用户的基础胰岛素分布曲线图。并且，该消息呈现：“警告：葡萄糖已过期。运行控制Obs！请录入当前的葡萄糖(WARNING：Glucose Outdated.Running Control Obs！Please enter current glucose.)”。接着，EA 518检查在所收集和处理的数据中是否存在足够的bG测量以在过程流点816继续。如果没有足够的bG测量，那么EA进入过程流点850，其在后面的章节中讨论。如果具有足够的bG测量，那么EA 518继续到差异管理模块818。

管理在预期结果和实际结果之间的差异

差异管理模块818检验由EA 518确定的受命令的胰岛素是否不同于从泵配发的胰岛素。如果不同，那么EA 518将其标记为受命令的胰岛素差异并在用户接口512(图5)上向用户呈现通知。因此需要由用户和/或保健专业人员解决在受命令的胰岛素和输送的胰岛素之间的差异，因为差异的原因很可能不依赖于APTS 500(例如作废的胰岛素泵)。

进餐葡萄糖区

然后EA 518进入到进餐胰岛素区模块820。在这一点上，进餐葡萄糖区模块820简单地将葡萄糖目标设定为带，而不是线。在闭环纯控制模式600中，ALGO 510利用这条带作为目标601，其也提供由基础控制器628(图6)所使用的设定点603。应当理解，基础控制器628使用葡萄糖预测器626作为作用输入并不考虑由于进餐而引起的葡萄糖变化。用预先确定的胰岛素剂量分配覆盖正餐来代替。确定该胰岛素剂量分配以便最大限度地将葡萄糖升高减至最小，并且使葡萄糖尽可能快得达到目标葡萄糖水平，同时略微低于目标值(minimal undershoot)。进餐摄入的葡萄糖升高不能被完全消除。这是期望出现的，因为在峰值胰岛素作用中存在大约30-60分钟的延迟。将所获得的胰岛素用量优化从而将由于进餐而引起的葡萄糖升高减至最小。因此将与进餐有关的目标葡萄糖区的带在进餐事件附近定义为由目标葡萄糖上边界和下边界所界定的区域。关于已定义的目标区，图13示出了四种不同的场景：(a)在葡萄糖区之内；(b)在葡萄糖区之上；(c)在葡萄糖区之下；以及(d)没有新的葡萄糖值。

(a)在葡萄糖区之内

如果预测的葡萄糖值位于葡萄糖区的边界之内，那么认为研究对象的葡萄糖在容许极限内。在这种情况下，基础控制器628仅需要基础葡萄糖来维持血糖控制。

(b)在葡萄糖区之上

如果预测的葡萄糖位于葡萄糖上边界之上，那么把研究对象看作是胰岛素输送不足。基础控制器628计算相对于葡萄糖上边界的葡萄糖偏差。基础控制器628的作用考虑该偏差并抑制这种未考虑的升高。

(c)在葡萄糖区之下

如果预测的葡萄糖位于葡萄糖下边界之下，那么把研究对象看作是胰岛素输送过量。基础控制器628计算相对于葡萄糖下边界的葡萄糖偏差。基础控制器628的作用考虑该偏差并抑制这种未考虑的降低。

(d)没有葡萄糖更新

目标区覆盖预先考虑的与进餐有关的响应的升降。当没有更新葡萄糖时，出现特殊情况。在没有更新葡萄糖测量时，当前控制周期T_C的预测葡萄糖是未考虑与进餐有关的葡萄糖升降的葡萄糖值。然而，目标区的边界是时间的函数。这通常意味着当进餐加速(kick in)时预测的葡萄糖较低并且当进餐停止时预测的葡萄糖较高。利用使进餐区边界上升和下降来强调该效应。EA 518利用上一次接收的葡萄糖测量通过保持上一次使用的边界极限来处理这种情况。对于所有的将来的控制周期来说，使这些较高和较低的目标值保持固定，直到新的测量到达。这在某种程度上减轻了该问题。

预备锻炼和锻炼

接着，EA 518经由锻炼模块822来评价患者是否参与了锻炼。当增大的身体活动水平时，维持能量的需要也增大。葡萄糖是能量源，其以较高的速率用于支撑增大的活动。同样，对生理行为所作的三个假设如下。第一个假设是在锻炼开始时葡萄糖水平下降。第二个假设是在身体锻炼开始之后大约10分钟和结束之后大约10分钟，葡萄糖快速下降。最后一个假设是一旦身体活动水平回到正常状态，就存在预期的恢复阶段，如葡萄糖存储为肌肉和肝脏中的糖原。相应地，分别在锻炼模块822和预备锻炼模块828的阶段中对锻炼进行处理。

EA 518稍后在过程流中调用预先锻炼模块828，该预先锻炼模块828通过增大葡萄糖设定点而在预期到锻炼时使葡萄糖升高，从而在锻炼过程中葡萄糖水平安全地下降。同样，为处理锻炼而预先确定的正常疗法是在预期到锻炼时减少基础胰岛素。降低胰岛素对葡萄糖的影响取决于胰岛素的药效学。然后在锻炼持续时间内维持较低的基础胰岛素水平。此外，如果在锻炼开始时葡萄糖水平没有充分地升高，那么研究对象可能要通过消耗速效的碳水化合物来管理其葡萄糖水平。这引起葡萄糖水平快速上升。

研究对象通过从用户接口512(图5)上提供的列表中选择活动和/或活动水平以触发预备锻炼事件来为锻炼做准备。选择的活动和/或活动水平具有相对应的预计的葡萄糖下降。直到触发了锻炼事件，目标葡萄糖的变化由方程式(6)给出：

$\mathrm{\Δ}{G}_T=-\mathrm{\Δ}{G}_P^E---\left(6\right),$

其中ΔG_T是目标葡萄糖值的变化，而ΔG_PE是葡萄糖浓度的预计推进(上升)，其对于锻炼来说，该值是负的，因为锻炼引起葡萄糖下降。因此，目标葡萄糖(即目标601)由方程式(7)给出：

G_T＝G_T+ΔG_T                (7)。

此外，一旦锻炼活动开始，身体就可能需要较少的胰岛素并在锻炼持续时间内维持较低的基础胰岛素需要。在锻炼结束时，将减少的基础胰岛素需要以某种预定义的逐渐的方式带回到正常的基础设置。

在锻炼开始之后，锻炼周期模块822计划出(project)在锻炼持续时间内的葡萄糖下降。当触发锻炼事件时，将预备锻炼转变成OFF。在锻炼事件开始时重新评价基础状态。如果准备锻炼没有将葡萄糖水平升高到所希望的量，那么ALGO 510在用户接口512(图5)上提示研究对象消耗速效的碳水化合物以增补葡萄糖水平升高。葡萄糖推进向量得到由于消耗速效的碳水化合物而产生的分量(如此后在标题为“速效的碳水化合物”一章中所解释的)。由身体活动而引起的期望的葡萄糖下降根据方程式(8)表示为：

$\mathrm{\Δ}{\stackrel{\→}{G}}_P=\mathrm{\Δ}{\stackrel{\→}{G}}_P+K_P^E\mathrm{\Δ}{\stackrel{\→}{G}}^E---\left(8\right),$

其中

因此用于计算所需要的基础胰岛素(即胰岛素推进)。注意，K_P ^E对于锻炼来说是负值。将锻炼和速效的碳水化合物的效应模拟为在归一化的(normalized)葡萄糖升高响应曲线中沿着相反的方向移动的葡萄糖推进向量。

在锻炼之后，锻炼模块822提供锻炼恢复时期，其按照基础设置需要而使基础速率逐渐地正常化。在这种实现中，锻炼持续时间被预定义在向量

中。一旦锻炼结束，由于锻炼

所引起的葡萄糖推进就变为0。通过利用

(recovery factor)和

(以分钟为单位)使不连续性变平滑。如果来自基础集的基础胰岛素率由I′_B给出，那么其能够利用方程式(9)来确定：

$I_B=I_B^{\′}((1-K_{\mathrm{\η}}^E)\frac{t-t_{\mathrm{\η}}^E}{T_{\mathrm{\η}}^E}+K_{\mathrm{\η}}^E)---\left(9\right),$

其中t_η ^E是完成锻炼的事件，t是当前时间。

速效的碳水化合物(Fast-Acting Carbohydrate)

在结束于锻炼模块822之后，那么EA815调用速效的碳水化合物模块824从而提供由于患者在用户接口512(图5)上所表明的(如果是这样的话)摄取速效的碳水化合物而引起的葡萄糖推进向量的更新。利用期望的葡萄糖推进分布曲线和相对的葡萄糖推进分布曲线对葡萄糖推进向量

进行分析。期望的葡萄糖推进分布曲线是预定义的葡萄糖推进向量，其归一化为每摄入一克碳水化合物的葡萄糖上升(mg/dL)(it is normalized per gram of carbohydrate intakeand per mg/dL rise)。相对的葡萄糖推进向量是归一化的推进向量

在A^FC[g]中消耗的速效的碳水化合物的量，以及期望的每克碳水化合物的葡萄糖上升K_P ^FC[mg/dL/g]的乘积。因此，葡萄糖推进向量能够用方程式(10)来描述和确定：

$\mathrm{\Δ}{\stackrel{\→}{G}}_P=\mathrm{\Δ}{\stackrel{\→}{G}}_P+A^{\mathrm{FC}}{K}_P^{\mathrm{FC}}\underset{i=k}{\overset{\mathrm{end}}{\mathrm{\Σ}}}\mathrm{\Δ}{\stackrel{\→}{G}}_P^{\mathrm{FC}}\left[i\right]---\left(10\right)$

低葡萄糖干预

接着，EA 518调用低葡萄糖干预模块826，其通过限定保证葡萄糖值上升的条件来维护用户安全。在低葡萄糖情况下，如当ALGO 510未能及时地保持葡萄糖水平在容许的血糖边界之上时，EA 518将基于从该模块提供的信息进行干预。该干预的目的是通过摄取速效的碳水化合物而将研究对象带回到正常血糖水平。由于EA仍然是起作用的，因此ALGO 510应当看到测得的葡萄糖增大，并且应当通过建议附加的胰岛素而潜在地抵消该葡萄糖推进。然而，低葡萄糖干预模块826利用更保守的胰岛素建议而允许葡萄糖上升。

在一个实施例中，A^G定义为为了降低葡萄糖水平所需要的速效的碳水化合物的量。因此，期望的葡萄糖推进由方程式(11)给出：

$\mathrm{\Δ}{\stackrel{\→}{G}}_P^{\mathrm{LG}}=\mathrm{\Δ}{\stackrel{\→}{G}}_P^{\mathrm{FC}}{A}^{\mathrm{LG}}{K}_P^{\mathrm{FC}}---\left(11\right),$

其中

是由于摄入速效的碳水化合物而引起的葡萄糖推进，A^LG是用于低葡萄糖干预的速效的碳水化合物的量，K_P ^FC是每克碳水化合物的葡萄糖上升。图14用图表示出对于摄入速效的碳水化合物的葡萄糖推进。通过用等于期望的升高

的量来修改葡萄糖设定点G_SP，ALGO 510将不会抵消因摄入速效的碳水化合物所引起的升高。并且，最终应当将G_SP恢复到原始设定点。该设定点推进向量定义为

和直线下降的增益项

的乘积，并且用方程式(12)给出：

$\mathrm{\Δ}{\stackrel{\→}{G}}_{\mathrm{SP}}^{\mathrm{LG}}\left[j\right]=(1-\frac{j{T}_C}{T_D})A^{\mathrm{LG}}{K}_R^{\mathrm{FC}}\underset{i=1}{\overset{\min (j+1,\mathrm{len}\left(\mathrm{\Δ}{\stackrel{\→}{G}}^{\mathrm{FC}}\right))}{\mathrm{\Σ}}}\mathrm{\Δ}{G}_P^{\mathrm{FC}}\left[i\right]---\left(12\right)$

这样，根据方程式(13)给出该设定点：

${\stackrel{\→}{G}}_{\mathrm{SP}}={\stackrel{\→}{G}}_{\mathrm{SP}}+\mathrm{\Δ}{\stackrel{\→}{G}}_{\mathrm{SP}}^{\mathrm{LG}}---\left(13\right).$

图15用图表示出随时间的相对设定点变化。当葡萄糖没有足够块地上升时，出现多个低葡萄糖干预是可能的。这也导致由于多个低葡萄糖干预事件而引起的G_SP的累积。在为当前低葡萄糖干预事件增加

之前，低葡萄糖干预不是增加效应，而是去掉上一次低葡萄糖干预的剩余结尾(trailing)部分。在这种干预之后，EA 518调用预备锻炼模块828，因为上面在标题为“预备锻炼和锻炼”的前面的章节中讨论过，因此不再讨论。

受命令的丸剂

当用户命令泵输送附加的胰岛素丸剂A^CB时，EA 518通过APS500利用受命令的丸剂的模块830。然而，对于每种控制模式，EA 518经由ALGO 510不同地识别和实施受命令的丸剂事件。对于闭环纯控制模式600(图6)来说，受命令的丸剂事件能够迫使提早输送胰岛素，并因此能够修改将来的胰岛素建议的分配。此外，当在纯控制模式600中时，受命令的丸剂A^CB将会超过达到目标葡萄糖所需要的所需胰岛素量。因此，在将来的控制周期内，EA 518考虑A^CB，并且相应地调整该建议。对于开环受控Obs模式700(图7)来说，受命令的丸剂模块830通过经由用户接口512(图5)录入覆盖例如进餐摄入和升高的葡萄糖水平的事件，而使研究对象能够在受控Obs模式700期间管理其各自的疗法。

高葡萄糖干预

高葡萄糖干预模块832使EA 518能够校正高血糖的状态。用户经由用户接口512(图5)录入校正量A^HG作为高葡萄糖干预事件。两种控制模式600和700都输送干预量以及建议，其由各自的模式生成。受命令的丸剂是“被ALGO察看的(seen by ALGO)”胰岛素，而为覆盖高葡萄糖干预事件而输送的胰岛素是“不被ALGO察看的”胰岛素。在闭环纯控制模式600中，ALGO 510的反馈部分看不见胰岛素干预的量。胰岛素作废模块836(之后在后面的章节中讨论)去掉与高葡萄糖干预有关的胰岛素的量。这意味着该反馈不会从将来的控制作用中减小胰岛素的量。在开环受控Obs模式700中，将用于高葡萄糖水平的干预量与开环建议合计以提供净胰岛素建议。

碳水化合物修正：重做上一次的进餐摄入

在研究对象已经向ALGO 510表明进餐消耗了A^M克碳水化合物之后，存在因几个潜在原因之一而可能不得不修订录入的量的可能性。这些原因包括：计算错误/不正确的在先录入；研究对象不能消耗得与较早预计的一样多(或者消耗得比预计的多)；消耗食物持续更长的时间段并因此需要重新分配疗法；以及在极端的实例中，取消进餐。根据意识到的上面的原因，EA 518调用碳水化合物修正模块834，其根据下面的条件而执行。首先，在时间t_M的进餐事件和量A^M必须存在。其次，用户已经录入了在时间t_MC的进餐校正事件和量A_C ^M。在可选择的实施例中，进餐事件定义为进餐剩余A_r ^M。如果符合上面两个条件，那么只要符合下面方程式(14)的附加条件，就能进行对胰岛素量的校正和分配：

$t_{\mathrm{MC}}-t_M\≤T_C^M---\left(14\right),$

其中T_C ^M是以分钟为单位的时间，并且是用于校正上一次进餐录入的容许的时间窗， $0\≤A_r^M\≤A^M$ (仅仅对于进餐剩余情况)。如果满足上面最后一个条件，那么进一步执行该碳水化合物修正模块834，否则该模块不采取行动地返回到EA 518。

在进一步处理中，模块834利用为新的进餐量A_C ^M而计算的新的胰岛素分配来代替为时间t_M的A^M而获得的胰岛素分配。相对于时间t_M而不相对于t_MC来实施该分配。对于进餐剩余情况A_r ^M，由方程式(15)给出A_C ^M：

$A_C^M=A^M-A_r^M---\left(15\right).$

模块834识别上一个进餐事件，其想到(a)当其出现时的时间和(b)量。如果满足假设1和2，那么该模块计算：对于A_C ^M找到胰岛素分配。时间将该分配变为上一次进餐发生的时间。对于A^M找到胰岛素分配。时间将该分配变为上一次进餐发生的时间。根据对应的时间间隙进行：从MEAL RELATED BOLUS(与进餐相关的丸剂)向量减去与A_C ^M有关的胰岛素分配并加上A^M分配。从INTERNAL BOLUS EVENT(内部丸剂事件)向量减去与A_C ^M有关的胰岛素分配并加上A^M分配。图16中所示的实例进一步阐明了碳水化合物修正模块834的这种进一步处理，并且在之后讨论。

进餐是进餐事件，进餐校正是由碳水化合物修正模块834所执行的事件。在所提供的实例中，在时间t_M＝495录入100g的进餐事件，其需要[205003002]作为胰岛素分配。直到t＝525，MEAL RELATEDBOLUS是[315]，INTERNAL BOLUS EVENT是[003002]。MEAL RELATEDBOLUS表示例如来自前一次进餐的附加的胰岛素作用。其存在是重要的，并且对于当前的问题，作用不会来自这里。在t_MC＝525时，录入对进餐的校正。该信息现在是对于在t_M＝495处的100g进餐录入，实际上只消耗了60g，完成步骤1和2。因此，在步骤3，模块834首先为60g确定胰岛素，这在步骤4中是[1.5030020001.5]。因为ALGO 510不会记得在步骤5中对于100g的分配，因此其在步骤6中为100g重新计算为[205003002]。在步骤7中，这两个向量(60g和100g)都移动到t＝500(用箭头示出)，在步骤8和9中重新计算MEAL RELATED BOLUS和INTERNAL BOLUS EVENT。

如果碳水化合物修正是不适用的，那么在用户接口512(图5)中显示下面的弹出消息：“警告：未应用进餐校正(WARNING：Mealcorrection not applied.)”。如果碳水化合物修正是适用的，那么(根据录入的量)显示下面的弹出消息之一：“警告：现在将在(hh:mm)录入的(数量)克进餐校正为(数量)克。警告：进餐剩余必须在(数量)和(数量)克之间(WARNING：Meal of(number amount)grams entered at(hh:mm)is now corrected to(number amount)grams.WARNING：Meal remaining must be between(number amount)and(number amount)grams.)”。

胰岛素作废

在碳水化合物修正模块834之后，EA 518调用胰岛素作废模块836。如上所述，胰岛素作废模块836从最终输送的胰岛素中排除前馈胰岛素组分，最终输送的胰岛素即该为周期配发的胰岛素的量。最终胰岛素输送是来自所有EA前馈模块的所有胰岛素量，所述所有EA前馈模块例如自我丸剂命令、与进餐有关的丸剂，和反馈分量。胰岛素作废从最终的胰岛素输送中去掉了任何前馈胰岛素的量。EA 518的当前实施单独地管理各种前馈胰岛素组分。胰岛素作废实际上暗示了已经去掉了所有前馈胰岛素量。为了获得正确的胰岛素反馈建议，必须正确地去掉所有前馈分量。方程式(16)给出了胰岛素作废向量

${\stackrel{\→}{I}}_N=\stackrel{\→}{I}-{\stackrel{\→}{I}}_{\mathrm{\η}}-{\stackrel{\→}{I}}_S---\left(16\right),$

其中是输送胰岛素向量，

是与进餐有关的并且是高葡萄糖干预丸剂，

是涉及自我丸剂的丸剂，并且是填装的、前馈分量。注意，如果过去的值在泵输送数据中是不可用的，那么用基础胰岛素剂量来填充过去的信息。

葡萄糖预测和基础控制作用

接着，EA 518调用葡萄糖预测模块838。由APTS收集的葡萄糖测量是延迟的测量，因为传感器具有物理和过程滞后。对未来的准确的葡萄糖预测对于提供血糖控制是很关键的。葡萄糖预测模块838利用过去的胰岛素输送信息、葡萄糖测量并利用胰岛素药效学来进行预测。图17示出了剩余胰岛素药效学。为了实施，在subject.ini文件中定义单位丸剂的剩余胰岛素的药效学，并且在这里用

给出。如图所示，在T_C＝10mts时对于单位胰岛素脉冲响应的药效学进行采样。

基础控制器628的基础部分是基于在葡萄糖预测中使用的类似的原理。基本原理是葡萄糖水平的变化是由于基础控制器628(图6)校正的未建模的器件干扰所引起的。对胰岛素剂量的调整考虑预测的葡萄糖。从葡萄糖预测器626和提供基础控制的设定点603的输出共同形成了基础控制器628的反馈部分。总之，闭环反馈建议的计算需要(a)最近预测的葡萄糖值和(b)输送的胰岛素的历史。

为了在当前时间预测葡萄糖，葡萄糖预测模块838利用下面的信息。处理过的葡萄糖值G[K]和对应的处理时间t_G[K]。在上一个T_D分钟内相对于j的作废胰岛素的信息

其中T_D是胰岛素发生作用的持续时间。如果T_C是控制时期，那么T_D＝nT_C。得到胰岛素药效学

将胰岛素下降假定为与所利用的胰岛素成正比，即ΔG[i]∝ΔI_r[i]，其中i＝1，2，...，n。获得用于单位丸剂的所利用的胰岛素

作为在向量

上进行的前向差分。方程式(17)给出了向量

ΔI_r[i]＝I_r[i+1]-I_r[i]，i＝1，2，...，n-1    (17)。

图18用图表示出了用于单位丸剂的所利用的胰岛素

随时间的变化。如果比例常数是K_I，胰岛素敏感性[mg/dL/U]，那么由于胰岛素利用而引起的葡萄糖下降由方程式(18)定义为：

ΔG[i]＝-K_IΔI_r[i]    (18)。

葡萄糖下降向量由方程式(19)定义为：

$\mathrm{\Δ}\stackrel{\→}{G}=-K_I\mathrm{\Δ}{\stackrel{\→}{I}}_r---\left(19\right).$

为了预测在时间j的葡萄糖下降，假定最近一次的葡萄糖测量G[K]由作废的胰岛素丸剂向量

与

的卷积给出，其中K是当前可用的葡萄糖值的时间，所述卷积由方程式(20)定义为：

$\mathrm{\ΔG}\left[j\right]={\stackrel{\→}{I}}_{[-n:-1|j]}*\mathrm{\Δ}\stackrel{\→}{G}=\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\left(I_{[-n+i|j]}\mathrm{\ΔG}\right[n-i\left]\right)---\left(20\right),$

其中

是最近n个胰岛素输送量相对于点j的向量，ΔG[j]是在第j个瞬间的葡萄糖下降，其中j＝K+1，...，k周期。图19用图表示出了胰岛素脉冲预测。葡萄糖预测模块838利用方程式(20)来为某个瞬间j预测葡萄糖。通过将j从K+1移动到k来进行在k处的葡萄糖预测。葡萄糖预测由三个部分计算：(a)输送的基础胰岛素，(b)预定义的基础胰岛素，和(c)葡萄糖预测。

(a)输送的基础胰岛素

输送的基础胰岛素的向量

是作废的胰岛素输送。期望的葡萄糖下降ΔG_N[j]由方程式(21)定义为：

$\mathrm{\Δ}{G}_N\left[j\right]={\stackrel{\→}{I}}_{[-n:-1|j]}^N*\mathrm{\Δ}\stackrel{\→}{G},j=K+1,...,k---\left(21\right).$

(b)预定义的基础胰岛素

预定义的基础胰岛素根据基础集来确定，并且是具有无干扰场景的“将会是基础胰岛素”的值

这是要保持目标葡萄糖G_T所需要的基础胰岛素组分。期望的葡萄糖下降ΔG_B由方程式(22)定义的内积给出：

$\mathrm{\Δ}{G}_B\left[j\right]={\stackrel{\→}{I}}_{[-n:-1|j]}^B*\mathrm{\Δ}\stackrel{\→}{G},j=K+1,...,k---\left(22\right).$

(c)葡萄糖预测

然后，给定在第j步的葡萄糖值G[j]，然后由方程式(23)给出预测的葡萄糖G[j+1]：

G[j+1]＝G[j]+ΔG_B[j]-ΔG_N[j]+ΔG_P[j+1]  (23)，

其中，ΔG_P[j+1]是根据已知干扰估计的葡萄糖推进。然后葡萄糖预测从时刻t_K的上一个已知葡萄糖值到当前时间t_K推进。然后EA 518继续进入到进餐补偿器模块840。

进餐补偿器

进餐补偿器模块840在调用时与碳水化合物的摄入有关。蛋白质和脂肪转变成相当的碳水化合物数量。进餐类型与日时以及碳水化合物摄入数量相关联。表5中列出了各种进餐类型的定义。

表5：进餐类型的定义

影响内脏葡萄糖吸收速率(即进餐速度)的因素之一是进餐组成成分，这是得到认可的。进餐量选择暗含了考虑进餐的速度。在控制周期中，如果触发了多个进餐事件，那么EA 518只考虑最后的进餐录入。在实施章节中描述了覆盖进餐的分配的胰岛素丸剂。大型进餐不一定相当于几次小型进餐的总和。这可以在进餐方案中定义，例如，Small meal(小型进餐)＝25克，Regular meal(正规进餐)＝50克，Large meal(大型进餐)＝75克。如果目前的基础胰岛素要求是相对的，并且已经触发了进餐，那么利用FastCarb分布曲线来调整设定点。由于具有动力学的进餐推进，因此期望葡萄糖迅速上升，如快速的碳水化合物，而不是缓慢地上升，如胰岛素药效学。

进餐忠告

接着，EA 518在适于提供通知研究对象开始进食的弹出对话框时调用进餐忠告模块842。如果要显示弹出的进餐忠告，那么基础控制器628设置用于控制进餐忠告模块842的标志。

内部丸剂管理

另外，如果适当的话，EA 518调用内部丸剂管理844来输送由进餐事件产生的前馈丸剂。

胰岛素建议

之后，EA 518调用胰岛素建议模块846，从而利用如上所述的当前预测的葡萄糖值来计算胰岛素剂量。特别是，通过计划出对膳食胰岛素的作用、将来的基础输入以及录入的其他事件的作用来计算针对胰岛素剂量的胰岛素建议。下面的步骤确定该基础胰岛素建议：(a)目前的葡萄糖，(b)输送的基础摄动(perturbation)胰岛素，(c)葡萄糖设定点，(d)预定义的基础胰岛素，和(e)葡萄糖推进。

(a)目前的葡萄糖

目前的葡萄糖根据预测葡萄糖章节来确定，并且用G[k]给出。

(b)输送的基本摄动胰岛素

该

向量是作废的胰岛素输送。因此，估计的胰岛素剩余是I_r ^N[k]，由方程式(24)给出：

$I_r^N\left[k\right]={\stackrel{\→}{I}}_{[-n:-1|k]}^N*\mathrm{\Δ}{\stackrel{\→}{I}}_r---\left(24\right)$

(c)葡萄糖设定点

这是目标葡萄糖，并且由G_T给出。

(d)预定义的基础胰岛素

这根据基础集来确定，并且是“将会是基础胰岛素”的值这是为了保持目标葡萄糖G_T所需要的基础胰岛素组分。期望的剩余胰岛素I_r ^B[k]由方程式(25)定义的内积给出：

$I_r^B\left[k\right]={\stackrel{\→}{I}}_k^B*\mathrm{\Δ}{\stackrel{\→}{I}}_r---\left(25\right)$

(e)葡萄糖推进

葡萄糖推进由ΔG_P给出。相应地，因此胰岛素建议由I_req给出，如方程式(26)定义的：

$I_{\mathrm{req}}=\frac{(G_{\mathrm{estimate}}-G_T)}{K_I}---\left(26\right),$

其中方程式(27)给出了G_estimate：

$G_{\mathrm{estimate}}=G\left[k\right]+[-K_I\left(I_r^N\right[k]-I_r^B[k\left]\right)]+\mathrm{\Δ}{G}_P---\left(27\right),$

并且通过考虑步骤(a)到(e)来确定。

下面的修改胰岛素建议的情况是满足目标区的葡萄糖和最小的基础需要。如上面在前面的章节中所提及的，目标区(即，目标601)定义为具有较低和较高设定点范围而不是仅具有单个点的设定区域，例如让G_T ^Hi和G_T ^Lo分别定义较高的设定点和较低的设定点。如果估计的葡萄糖G_estimate在目标区内，那么I_req仅仅是基础胰岛素。对于最小基础需要的情况，当I_req为负时，EA 518预测该研究对象目前处于胰岛素输送过量的状态中。在这种过量输送的情况中，最小基础速率(通常是基础速率的一半)由ALGO 510来实现。重要的是，循环的(circulating)胰岛素浓度不会下降到阈值之下以避免反调节。强制执行的最小基础确保了最小的循环胰岛素水平。

胰岛素容器

当EA 518调用胰岛素容器模块848时，根据基础控制和由于触发的各种事件所引起的开环胰岛素需要的组合来产生最终胰岛素建议。另外，存在强加于最终胰岛素建议的约束，例如给用于每个控制周期的胰岛素量定一个上限(cap)，其称为输送最高限度约束。最终，胰岛素建议也许不会实现。例如，保健专业人员有最终权力接受或拒绝一个建议。最终胰岛素输送是实际的输送。因此，胰岛素记录保持分量保持在各种胰岛素容器中，其必须符合建议约束。如果最终的胰岛素建议与最终的胰岛素输送不同，那么ALGO 510重新评估并重新认为该分量相应地是修正的最终胰岛素输送。

在处理点850，EA 518确定是否能够实现开环纯控制600，是否设定了不足的bG测量标志(其是从处理点616开始的重新入口点)，或者是否设定了bG过期标志。如果任何这种条件是假，那么EA 518调用更新存储模块854以保存来自该控制周期的值和条件。如果任何条件都为真，那么EA 518将调用差异管理模块818、受命令的丸剂模块830、高bG干预模块832和输送最高限度约束模块852，其将约束强加于最终的胰岛素建议。在这些调用完成时，那么EA 518调用更新存储模块854以保存来自该控制周期的值和条件。然后，在重新开始由图8和9所示并且在上面描述的过程流程之前，EA 518等待直到ALGO 510的下一个控制周期开始。

ALGOSHELL

ALGOSHELL 506提供数据结构管理和相关宏(macros)，其位于系统文件夹中。特别是，ALGOSHELL 506是一种功能，其生成到从APS500调用的给定输入的输出。ALGOSHELL 506的功能也是与模拟(Simulink(模拟链接))环境中运行的APSe一起工作。如上所述，APS测试台环境是非Simulink环境，其中APSe是模拟APS测试台环境的包装(wrapper)功能。ALGOSHELL 506与APS、实时测试台和模拟环境中的APSe相接口。归一化的ALGOSHELL 506调用如下：[yAMT，yAdvice，yTrace，xk′]＝ALGOSHELL_xxx(t，xk u，EventStruc，ExperimentStruc，PumpStruc，BGStruc，PatientIniStruc)。图33示出什么时候相对于ALGO 510来更新多个变量。稍后首先讨论ALGOSHELL 506调用的输入变量t、xk u、EventStruc、ExperimenStruc、PumpStruc、BGStruc、PatientIniStruc，随后讨论输出变量yAMT、yAdvice、yTrace和xk′。

输入变量

项t是经过时间或模拟时间的时间标量。期望时间t是Sync1调用的TControl+/-delta时间的倍数，并且定义为当前控制周期边缘。Sync2调用将遵循Sync1并且将在下一个控制周期边缘之前出现。项xk是包含ALGOSHELL所需要的一组变量的状态向量，其称作states(状态)。在APSe中，存在通过控制离散状态的更新而保持的离散状态。当调用APSe时，xk是可用作states。另一方面，APS总是在控制之下，并且负责保持xk。向量xk的长度和细节是依赖于ALGO的。APS不需要知道xk的长度或细节。应当由APS将变量xk初始化为空矩阵[]。然后，ALGOSHELL 506确定其第一次被调用时的正确长度。从那时起，该实验应当保持xk的长度。APS/APSe不应当修改xk的值或长度。项u是输入向量并且由字段设备(即泵和传感器)输出的信息组成。APS和APSe都需要知道输入向量u的细节。参见表6的细节。注意，“净配发的胰岛素(Net Dispensed Insulin)”是用于由泵配发的胰岛素总量的累积计数器。

表6：输入向量u

EventStruc——事件结构

这是包含预定义的触发时间表的结构。APSe可其作为参数之一。在另一方面，APS获得该时间表，并且根据从APS主窗口902触发的事件而更新EventStruc。对于事件结构的字段，参见表7。

表7：EventStruc字段

字段	定义	注释
			trigger_time	事件发生的时间，经过的时间，以分钟为单位	n×1阵列附加新的录入。对于ALGO 510采取任何作用所需的录入。
rxn_time	控制器应当对事件作出响应的时间，经过的时间，以分钟为单位	n×1阵列附加新的录入。缺省是NaN。
			event_type	由在PatientIniStruc.events.type中定义的事件的行数所识别的事件类型。事件强度的单元类型在PatientIniStruc.events.units中定义。	n×1阵列附加新的录入。缺省是NaN。对于每个事件，将event_type编在PatientIniStruc.events.type中。
duration	事件的影响的持续时间(生理的)，以分钟为单位	n×1阵列附加新的录入。缺省是NaN。
			amount	如在事件类型中定义的量化的事件、单位进餐，gm锻炼丸剂，U血糖，mg/dL	n×1阵列附加新的录入。缺省是NaN。

在表7中提供的字段PatientIniStruc.events.units是由APS GUI显示的事件单元的阵列。在EventStruc中的每个字段都是列的阵列。所有列的阵列都具有相同的长度。如果特定的行没有信息，那么将录入NaN并且将保持这些行的长度。在APS中，当将事件记入日志时更新EventStruc。在APSe中，EventStruc是预先存在的。所有事件都在运行之前被安排。在实施中不存在本质上的差别。ALGOSHELL506仅看到已注册的事件，该事件少于或等于目前的模拟时间。对于ALGO 510来说，触发时间或控制器响应时间中的至少一个必须是非零的，以接受该事件作为有意义的事件。如果没有录入时间中的任一个，那么ALGO 510不能判断该特定事件在什么时候发生并且在什么时候将其忽略。Event_type入口是由“patientini.events”结构所列出的那些入口，并具有type、units和InternalName字段。它们可以因不同实验而发生变化。这些事件具有两种：仅为了记录的目的而仅用于例如Blood Draw事件的那些事件；以及通知ALGO 510考虑并且对例如早餐的事件适当地作出反应的那些事件。

ExperimentStruc——实验结构

这是预先定义的并且APSe经由APSe参数而可用的结构。APS加载实验结构以进行实验。参见表8的实验结构字段。

表8：实验结构字段

字段	定义	注释
			operator	登录ID
timestamp	时间戳，以分钟为单位
			algo_used	所用的algo的名称	从PatientIniStruc获得。对于实验不会改变
title	实验标题	从PatientIniStruc获得
			time_int	控制周期的长度，以秒为单位(TControl，即在连续的第一次ALGO调用之间的时间)	从PatientIniStruc获得
t_zero	[年月日时分秒]MATLAB格式的时间	实验开始的绝对时间。APS时间显示实验开始
			confirm_int	确认时限，以秒为单位	缺省的mat文件

confirm_offsetoffset_int[revisedfieldname]	确认偏移量，以秒为单位	缺省的mat文件
			Site	“01”、“02”，或“RD”	从PatientIniStruc获得
Version	Patient ini版本
			algo_used		从PatientIniStruc获得
Algoshell	ALGOSHELL的名称	从PatientIniStruc获得
			Algoshell_version		询问Algoshell并赋值
Algo_version		由APS询问并存储
			Expdate	截止日期	从PatientIniStruc获得
Mode	1-纯观察2-建议前3-纯控制4-第二次调用/async调用5-建议后	APS设定该模式。对于APS3，整个运行是模式3，随后是模式4：纯控制调用，随后是第二次调用
			ControlObs	标记：1-受控观察2-纯控制	可适用于APS3和更高。APS设定该标记并且是主GUI上的控制按钮的功能
DataPath	存储Rundat mat文件的位置	当ALGO失败时，将局部变量保存在mat文件中。
			num_timeouts	确认错过的/超时
num_asyncs	async受命令的丸剂的数量
			num_recos	Algo建议的数量

num_ovrs	用户不考虑的数量
			patientini(i，1)	结构阵列	从patient ini mat文件获得。
PatientIni_LoadTime	时间阵列
			single_dose_lim	由APS强加的剂量最高限度U

PumpStruc-泵的结构

从APCATS 900的用户接口获得并预先定义该结构的除数据字段之外的所有字段。该结构最初按参数传送。在初始化阶段中，PumpStruc变成mat文件。APS具有类似的设置。如这里在表9中所用的，“Offline”表示按照来自APSCOM 504的上一个状态信息而在该泵不可用时所出现的条件。参见表9的泵结构字段。

表9：PumpStruc字段

BGStruc-血糖结构

从APCATS 900的用户接口获得并且预先定义该结构的除数据字段：bg1data和bg1timestamp之外的所有字段。该结构最初被当作参数传送。传感器编号为0、1、2、3......，传感器1被认为是虚(virtual)传感器。表10给出了传感器1的传感器结构字段。至于其他的传感器编号，将每个字段中的“1”用该传感器编号来代替。支持高达4个传感器：2个SU传感器，1个外部传感器和1个虚传感器。但是，对于APS-3，具有下面的传感器映射：0映射为“EXT”；1映射为“SU 1”；2映射为“SU 2”。

表10：传感器结构字段

字段	定义	注释
			bg1timestamp	经过的时间，以分钟为单位	n×1阵列，u(2)，刚好在调用ALGO之后

bg1chan
			bg1data	葡萄糖浓度	n×1阵列，u(1)，刚好在调用ALGO之后由bg1units规定单位
bg1indx	上一次数据集索引
			bg1units	bg1data信息的单位(报告的血糖测量的单位)，“MG/DL”或“MMOL/L”	葡萄糖浓度的内部标准是mg/dL。
bg1device	“Via”、“PR 1”、“SU1”、“SU 2”，或“EXT”
			bg1device_sn	序列号
bg1sensor_lot	批号
			bg1dispo_lot	可任意使用的数
online1	如果存在，那么是联机或脱机，0/1
			available1	传感器的存在，0或1
bg1res	传感器的规定精度，mg/Dl
			bg1PrimeStat	表明哪个传感器目前是主要的
bg1lagtime	滞后时间，以mts为单位
			bg1lagtimeindx	当前的滞后时间的指数
bg1rectime	接收bG数据块的时间，以mts为单位

刚好在ALGO调用之后，APS/APSe更新该BGStruc字段。

PatientIniStruc-患者初始化结构

该结构定义在初始化文件(INI-file)中，并且包括对于进餐摄入和胰岛素降低的患者特定响应矢量。INI-file向APTS 500和ALGO510提供研究特定的和研究对象特定的参数。在APS启动时加载的研究对象INI文件包含研究对象特定数据，其包括算法参数、单一剂量自动确认和三次剂量确认阈值和Event Type(事件类型)。如上面所解释的Event Type可以是在实验过程中由保健专业人员通过下拉列表手动选择的活动。Common Event Type(公共事件类型)包括进餐和外部血糖(bG)仪读数。下拉列表的值由Subject INI(研究对象INI)文件来确定。如在Subject INI文件中指定的Consecutive-DoseThreshold(连续剂量阈值)是未经保健专业人员批准的在三个相继周期中输送的胰岛素的最大量。如在Subject INI文件中指定的自动确认阈值是未经保健专业人员批准的在单个周期中输送的胰岛素的最大量。实验是从APTS开始到结束而收集的数据，包括在INI-File中的任何中间的重新开始和变化。参见表11的在subject INI文件中提供的字段的字段描述。

表11：PatientIniStruc字段

字段	定义	注释
			title	标题	15个字符在APS窗口上显示为Study ID
pat_id	患者ID	11个字符在APS窗口上显示为PATIENT ID
			time_ini	秒	TControl
gender	性别，“M”或“F”	1个字符
			ht	高度，以英寸(in)为单位
wt	重量，以磅为单位
			Site	“RD”、“01”，或“02”
Version
			ControlNos
AlgoShell	AlgoShell_A2M

IniFilename		13个字符在APS窗口上显示为PATIENT ID
			StartDate
ExpDate
			IniCreationDate
LockoutMode	0-纯受控obs1-允许用户在受控obs和纯控制之间切换
			PlaceOfBirth	N/A	N/A
ExpParam	只有每个ALGO才有的结构，并且供内部ALGO使用。对所有附加的与ALGO有关的变量进行分组。检查两个字段：algo_usedalgodir	“algo_used”：在APS窗口上显示为ALGONAME“algodir”是包含由algo_used描述的mfile的目录MatlabPath设置应当包括两个路径：C:\apsv3_0\algos和C:\apsv3_0\algos\algodir(其中algodir是存储的字符串)不应当列出任何其他的algos子文件夹。“USER_ENTRY_INSU_CEILING”“SimuALGOPARAM”“DispALGOPARAM”“LOGFILEMSG_DEBUG”“MildHypo”

		“SevereHypo”
			Dose_confirm_thresh	当前的剂量最高限度，U
Three_dose_confirm_thresh	最后的三个剂量最高限度，U
			events		事件映射并且具有下面的字段：type(类型)：显示在事件类型的下拉列表中。用户所使用的描述符。units(单位)：用于所选择的单位InternalName：ALGO的内部

输出变量：

项yAMT是泵和显示命令向量，并且包含用于该泵的命令。表12提供了关于在命令向量yAMT中包含的命令的细节..

表12：yAMT向量

向量元素	定义
				yAMT(1)	配发的累积量，以U为单位	u(7)+u(10)	转变成U
yAMT(2)	受命令的速率、每个控制周期的U	ALGO计算	传到APSIO，照现在的样子
				yAMT(3)	受命令的类型的补充yAMT(2)0-连续的1-丸剂	ALGO计算	传到APSIO，照现在的样子

	2-设定为无命令
				yAMT(4)	U	对于纯观察是0对于预先搜索是0对于Sync1是recco-calcu值对于Sync2是user-value	Sync1-algo-建议的量Sync2-用户-批准的量Async-附加用户-请求的量
yAMT(5)	每个控制周期配发的量，以U为单位	在Async调用过程中其是NaN	APSIO提供配发的净量，u(7)，将其转变成U。然后通过从u(7)减去sum(pumpdat.amount1delivered)而得到在前一个周期中由泵1配发的量

项yAdvice是忠告字符串，其提供由ALGO标记的但是由APS来实施的警告和其他可能的故障保险的测量。yAdvice由二位忠告数字、随后是空格、随后是语句而组成。忠告数字分成三类：(1)标称的(范围：00到09)，(2)弹出消息窗口(范围：10到98)，和(3)退出/停止(Exit/Quit)(范围是99)。项yTrace是跟踪字符串，其跟踪ALGO执行的步骤。ALGO进度被记录在位于ExperimentStruc文件中定义的DataPath的日志文件中。xk′是在下一个ALGO调用时ALGO的启动所需要的状态向量。

控制周期断开(Control-Cycle Breakup)

对于包括同步调用、用户确认窗口和异步调用的建议模式来说，每个受命令值被限制为该泵在该控制时期的剩余部分中能够配发的量。确认窗口是对话框，其要求对受命令的胰岛素的最终确认，并且出现在保健专业人员手动地接受或拒绝胰岛素建议时。在所说明的实施例中，该窗口在45秒之后超时。同样，如图34所示，该控制时期也被分解为三个区域，并在表13中列出了在ALGOSHELL中的参数。在理想情况下的每个控制周期允许在该控制周期开始时调用该ALGO。ALGO将会处理该输入，并建议在该控制周期的剩余部分中所配发的量。但是存在硬件限制，这是因为(1)每个作用都花费有限的时间并且(2)内部时钟是分立的。此外，存在人为干预，并且对于开环控制来说，存在因控制作用所剩下的实际时间的变化性。在将所有这些考虑因素计算在内之后，确定将要允许整个地发送该命令的受命令的值。

表13：在ALGOSHELL中的参数

参数	时间，以秒为单位
		TSetDev	5
TMonitor	6
		TRecco	20
TSetAPS	10
		TSlack	6
T2Override	30
		SyncCallTime
AsyncOverhead
		AsyncCallDeadline

所有空白的块都表示对圈起的变量进行更新。从APS的观点来看图33。示出了在“Sync1”调用前后的输入数据。

纯建议场景

如果m是在控制之下的ALGOSHELL 506的上一次调用，即在第m次和第(m+1)次调用之间，那么用新的测量来更新BGStruc。这些测量从数据库获得。在第m+1次之前，ALGO 510调用下面：(a)来自BGStruc的最近一次(上一次)BG测量和时间以及传感器状态，将这些分配到向量u；(b)上一次的净胰岛素配发信息，其从数据库获得并且分配到向量u；(c)时间t，将其设置成调用ALGOSHELL 506的时间；(d)照现在的样子由APS传送向量xk；以及(e)将实验泵模式设置成3。再次调用ALGO 510，n＝m+1。利用模式＝3来调用ALGOSHELL 506，即作为Sync1调用。

对于该Sync1调用，返回向量yAMT和其他输出变元。APS利用yAMT进行图35中所示的更新。对yAdvisory进行分析，并且显示适当的消息(发送到日志窗口、弹出消息框，并且停止)。APS建议窗口514(图5)显示所建议的量yAMT(4)。建议窗口514显示当前周期的所建议的胰岛素剂量，如由ALGO 510确定的。建议窗口514在运行周期结尾时出现所建议的要注入的胰岛素量。如果该量在单剂量阈值或三剂量阈值之内，那么不需要由保健专业人员来确认待注入的量。得到如下的用户响应：(a)拒绝建议，VALUE＝0，indx＝0；(b)接受建议(确认)，VALUE＝yAMT(4)，indx＝1；或者(c)不考虑，VALUE＝EnterValue，indx＝2)。对Pumpdat向量进行更新。如图35所示进行下面的赋值：对于pumpdat更新，与传感器有关的u元素是0；u(1)至u(6)是NaN，给u(7)赋值为VALUE；u(8)是当前时间t；u(9)是泵状态标志。实验模式设定为4(对于Sync2调用来说)。再次调用ALGO 510，n＝m+2。最后，如同Sync2调用一样，对ALGO 510进行调用。对于Sync2，如图35所示那样更新Pumpdat向量。然后为下一个控制周期重复该顺序。

ALGO-APS流

之后也在表14中提供了ALGO-APS过程流的实例。要注意，经过的时间是自该实验开始以来的相对时间t，单位为分钟。当重新启动时，起动时间是该实验的起动时间而不是重新启动的起动时间。经过的时间仍然是相对于“ExperimentStruc.t_zero”测量的相对值。

表14：ALGO-APS流

感兴趣的方面是Sync1遵循Sync2，只要Sync2发生在控制周期的边缘之前，并且APS正确地记录并存储重新启动的yAMT。要注意，重新启动是用以前收集的数据对未完成的实验进行恢复以供APTS制图并供ALGO使用。利用以分钟为单位的Lapse时间(经过的时间)将传感器和泵数据赋予GBStruc和PumStruc。向量u总是发送上一次的可用数据以及时间戳。如果没有获得新的数据，那么获得上一次的已知数据。现在对第二个说明实施的实施例进行讨论。

APCATS(自动的胰脏控制算法测试套件)

自动的胰脏控制算法测试套件(APCATS)是一种软件程序，其用作归一化的模拟工具、AP测试台仿真器、验证工具和用作评价工具。作为归一化的模拟工具，APCATS提供对于模拟一般的闭环系统所需要的基本功能。同样，该功能允许设计数学模型的人集中于建模本身而不是集中于连接的细节以及基本设置和连接的验证。作为AP测试台仿真器，该程序能够缩短用于评价和验证算法变化的时间，该变化来自APTS 500所需要的。为了实现这一目的，其利用“模拟”时间(与实时相对)，同时为ALGO 510提供同样的模拟环境。并且，通过允许在参数值范围内的模拟，APCATS能够在不危及患者的情况下扩展评价的范围。此外，可以利用APCATS来模拟和评价关键场景。例如，可以系统地评价设备的故障，或者能够实施和评估故障保险模式。

作为验证工具，APCATS提供仿真APTS 500的能力，由此允许在开发和测试版本(pre-release)的场景下首先验证对ALGO 510进行的任何修正。作为评价工具，能够利用APCATS来模拟数学模型、控制器、闭环响应等，由此允许评价(1)质量和(2)模拟项的性能。在所说明的实施例中，对APCATS进行开发，并且使其在MATLAB技术计算环境中运行。在其他实施例中，可以使用其他语言和计算环境，如visual basic和Windows操作系统。前端用户接口为稍微归一化的自动胰脏系统提供开发分析控制法则的快速装置。其提供用于进行分析和模拟以及驱动实际系统的公共平台，条件是硬件连接在控制环中。由于APCATS在与APTS 500类似的操作环境中(如在系统10中)执行时，并且本领域技术人员完全了解软件程序在硬件上的执行时，以下的章节仅仅集中于本发明的该第二说明实现的实施例的软件组件上。

软件组件

APCATS应用程序包括几个不同的软件组件，这些软件组件分成三类：用户接口；初始化文件；和组件模块。APCATS的中心核心保存该数据并形成主干，其将所有的前端带入到统一的应用程序中。初始化文件也称作init文件，其通知APCATS核心所需要的模块在哪里以及需要读取和执行什么模块。基于在这些文件中的信息，APCATS动态地创建自身。组件模块数学地描述每个组件的表现如何。在模拟过程中，其动态地对外部和内部激励起反应。这些组件模块在这里分成下面的主要类型：设备；致动器(actuator)；传感器(sensor)；控制器；和外部干扰。在后面的章节中更详细地讨论这些组件模块中的每一个。

用户接口(UI)是允许从用户输入下面内容的前端，所述内容如：选项的选择、与某些特征的相互作用，以及值的录入或修改。其也允许用户观察该输出。由于将该核心设计成不依赖于问题本身，因此问题定义存在于组件模块中。通过初始化文件来管理在UI和组件模块之间的相互作用的灵活性。用户接口覆盖下面的核心方面：APCATS的主窗口；对于每个组件的用户录入形式；对于组件的菜单形式；模拟运行设置形式；模拟链接(Simulink)框图的生成；管理并与数据文件的相互作用；用于显示结果的曲线图；APCATS设置的存储和检索；以及连接接口。

参考图22，APCATS通常用附图标记900来表示，其提供用户接口作为主窗口902。主窗口902提供三个窗格：运行/存储窗格904；算法窗格906；以及曲线图窗格908。此外，在底部的状态条(statusbar)910传递APCATS 900活动的消息。

算法窗格906是一种控制算法，其对于调节模型患者内的血糖水平是很重要的。算法窗格906显示自动的胰脏控制算法，其由与输入/输出连接线X相连的几个框组成。算法窗格906用于设置整个比环系统。其允许选择模型、编辑参数值和修改连接。可以选择每个框和连接来显示并设置其参数。可用的框是：外部干扰框(externaldisturbance block)912；器件框914；传感器框916；控制器框918；和致动器框920。如图所示，框的连接是：外部干扰框/器件框的连接；器件框/传感器框的连接；传感器框/控制器框的连接；控制器框/致动器框的连接；致动器框/器件框的连接；以及致动器框/控制器框的连接。

图23是显示一般的闭环结构的框图，图中的互相连接的箭头代表在算法窗格906的各个框之间的接口。这些互相连接的箭头也代表在各个框之间的信息流。算法窗格906的每个框在最上层都向用户提供几个选项。与选择相关联的其他选项(如果有的话)以隐藏的子层的方式布置。在用户从最上面的可见层继续进行到较低的层时向用户展开并且激活这些层。通过算法窗格906上的各种框912-920和连接，修改对于模拟所需要的参数是可能的。其允许用户从几种可能的模型中选择；设定与选定的模型相对应的参数；并且设定经过该输入/输出连接传送的信息。下面更详细地描述算法窗格906的各个框，首先参考器件框。

器件框

器件框914提供许多可选择的患者模型(例如在图3中的患者模型73)的列表，其反映对当前的相关生理机能和新陈代谢相互作用的了解。可以模拟和提供(增加)供器件框914中使用的改变了复杂程度和细节的新的患者模型。通过调整参数界限，可以利用器件框914来研究和模拟各式各样的行为。器件框914接收来自致动器的输入以及由各种饮食摄入产生的干扰。传感器用于测量在器件框914中选择的患者模型的输出。

设备选择和参数设定

通过单击相对应的单选按钮之一而经器件框914选择患者模型。任何时候都只能选择一个患者模型。所对应的单选按钮变为高亮显示，并且引出如图24所示的器件菜单窗口922。点击已经选定的患者模型也将引出该器件菜单窗口922。如果当选择新的器件时该器件菜单窗口922已经展开，那么APCATS 900将检查是否已经保存了录入到其中的参数。如果已经保存了这些参数，那么关闭该当前的器件菜单窗口922，并且为新选择的模型展开新的器件菜单窗口。如果没有保存这些参数，那么将在主窗口902底部的消息条中显示对于该结果的消息，并且不会关闭已经为激活态(active)的器件菜单窗口922。与选定的患者模型相对应的参数显示在该窗口中，并且加载有在存储器中存储的保存的值。可以对这些参数值进行编辑，并且用下面的表示其编辑状态的颜色来显示这些参数值：黑色-缺省的或未编辑的的值；红色-已编辑的值；蓝色-冻结的(frozen)、不可编辑的值。

如果改变了患者模型选择，那么将会断开在与器件框914连接的各个框之间的先前存在的连接，用户需要将其重新连接。(参见下面提供的连接章节。)对与该器件框914相关联的输入和输出进行更新。并且，选择新的患者模型将会产生在绘制设置中自变量和因变量的更新列表。(参见章节6。)器件菜单窗口922中的每个参数都在其自己的行中列出。器件菜单窗口922中的列是：针对每一行的“Nos.”列924、针对参数名的“参数(Parameter)”列926，和用于录入参数值的“编辑值(Edit Value)”列928。录入的值必须是在为“滑动值(Slide Value)”列930之后提供的两列中的参数所规定的最小值和最大值之间，该录入的值变为也将在邻近的滑动块(slider)932中反映的值。

“滑动值”列930提供了设定参数值的可选择的方法，并且滑动块932的左端和右端分别对应于该参数的最小值和最大值。当移动该滑动块932时，该参数的数值将在该列中更新为在编辑值列中滑动块的左边。“Edit Min.”列934提供容许的最小参数值。可以对该值进行编辑，其变化也将在滑动块932上反映出来。“Edit Max”列936提供该参数值的上限。应当将大的值用于不具有上限的参数。可以对该值进行编辑，其变化也将在滑动块932上反映出来。

“No.of Div”列938用于表示进行模拟的参数值的数目(例如参数研究法(parametric study))。必须录入非零的正整数。非整数的值四舍五入为最接近的有效整数。对于下面的Div的值，在实验性模拟中所用的参数值是：0或1，其意味着使用录入的参数值；2，其意味着使用最小值和最大值；3，其意味着使用最小值、平均值和最大值；n(其中n是正整数)，其意味着使用最小值、最大值和n-2个等间隔的中间值。注意，参数研究法包括这些参数值的每种组合，并且如果使用几个参数的多个值那么可能导致运行数过多。为了确定组合数，成倍地增加为所有参数选择的划分(division)数目。根据APCATS 900，能够执行两种不同种类的参数研究法：(a)参数范围的系统生成(spanning)；和(b)参数范围的随机生成。

(a)参数研究法(系统的)

为了对给定的参数进行参数研究法，用户将用于参数的划分数目设定成待研究的值的数目。为其运行的参数的值将是足以给出规定的值的数目的所录入的最小值、最大值和许多均匀间隔的中间值。例如，如果将用于参数的划分数目设定为5，那么为最小值、最大值和三个其他的值而进行运行，所述三个其他的值是在最小值和最大值之间的距离的¹/₄、¹/₂和³/₄处。如果将多于一个参数设定为利用多个值，那么为所有参数的值的每个可能的组合而进行运行。在设定“Nos.ofDiv.”时要谨慎，因为其很容易产生过多的组合/运行数目。

(b)参数研究法(随机)

为了使用随机参数选择，用户选中“Select parameter value@random”复选框940。“Number of runs”字段942和“SEED”字段944将变为激活的。在“Number of runs”字段942中，用户录入在实验的模拟过程中将要运行的模拟数。在“SEED”字段944中，用户录入正整数作为随机数发生器的种子(seed)。SEED的值用于重新创造随机数序列，并且存储在实验的文档资料中以重新生成这些随机值。随机数生成假定在参数范围上的均匀分布。对于每次运行，用于这些参数的随机值都存储在文档资料文件中。在器件菜单窗口922底部的命令行菜单(command line menu)946提供下面的功能：保存、取消、帮助和关闭。“Save(保存)”保存任何参数变化，并且只有当至少一个值自从上一次保存以来发生变化时才是激活态。“Cancel(取消)”恢复上一次保存的值。这一按钮只有当至少一个值自从上一次保存以来发生变化时才是激活态。“Help(帮助)”展开帮助窗口，“关闭”保存变化(如果有的话)并且关闭窗口922。

传感器和致动器

因为传感器框916和致动器框920的系统相应说明是类似的，如在算法窗格906中它们的用户接口，因此，这里将传感器框916和致动器框920一起讨论并且将其共同称作设备框。致动器框920(图22)模拟泵单元，该泵单元接收来自控制器框918的命令。这使致动器框920启动。将来自致动器框920的(多个)输出发送到器件框914。另一方面，传感器框916测量来自在器件框915中选择的患者模型的信号，并将信息发送给控制器框918。设备框916和920具有下面的特性：设备动态特性，其通过数学关系、设备参数、(多个)输入；和(多个)输出来描述。传感器框916和致动器框920中的每一个都提供下面的设置选择：设备的数量；设备/设备模型的类型；和设备系数。注意，由于噪声和非线性构建到这些功能中，因此可以列出其参数连同其他设备系数。

从算法窗格906中的设备框916和920中的下拉列表948选择设备。在各自的设备框中列出了关于该设备的选择和该设备特定的参数的选择，这些参数也称作系数950。缺省值在正常情况下紧接着该系数描述而列出。这些系数值是可编辑的。如果对任何值进行编辑，那么该保存和取消按钮变为激活的。为了恢复到上一次保存的值，单击该取消按钮。为了保存录入的值，单击该保存按钮。这些动作的任一个使这些按钮是禁用的，直到进行下一次编辑。注意，如果该保存和取消按钮是激活态的，即如果在各自的设备框中存在任何未保存的系数，那么不会执行新的模拟。APCATS 900允许并行地运行几个设备单元的能力允许同时地模拟多个传感器或泵。

为了实现多个同时的单元，用户必须在设备菜单的右顶端数量标签(number tab)952中录入所希望的单元数量，其表示在操作中有多少控制通道。每个单元都将具有其自己的设备形式，其可通过左上侧的编号标签(numbered tab)954来选择。当前选择的设备的编号标签954将是高亮显示的。用户能够对这些表格中的每个表格编辑系数950。设备数量的增大将会向下拉列表948的底端增加新的设备。同样，设备数量的减少将从列表948的底端去掉设备(即编号较高的设备)。如果用户决定在保存该表单之前切换到另一个标签，那么将提示该用户保存该表单，并且在继续进行之前保存或取消这些修改。用户能够在任何时候改变标签和设备的数量。如果其录入的数量超过了预定义的设备的最大数量，那么该数量将恢复到前一个值。任何时候改变设备都会断开用于该设备的先前存在的输入和输出的连接。在运行模拟之前，用户必须建立在该设备和提供其输入并接受其输出的模块之间的新的连接。类似地，对于新添加的任何设备同样必须建立连接。注意，在不检查参数是否需要保存或放弃的情况下切换设备的能力尚未实现。目前，APCATS 900放弃自从上一次保存所进行的任何改变。

设备框916和920能够在两种模式下操作：(1)非失效(non-failure)模式，这是正常的不中断的设备操作，和(2)失效模式。失效模式允许对设备中断的模拟，即设备输出冻结在中断状态，同时其他子块继续正常操作。在失效的结尾，该设备通过将其重新初始化而恢复。失效能够通过规定哪个设备已经失效、所经历的失效的类型以及失效的持续时间来排定。为了启用故障保险/失效模式并允许排定失效，用户选中失效模式按钮958的左侧的复选框956。如果已经选中了在控制器框918上的用于测试台仿真器(APSe)按钮962的复选框960，那么自动地选中并禁用失效模式复选框956，从而使其不能改变。如果没有选中控制器框918上的用于测试台仿真器按钮962的复选框960，那么用户可以使用失效模式复选框956来选择故障保险/失效模式，其中测试台仿真器按钮962是仿真的(模拟的)APS。如果启用了失效模式，那么创建表示该失效类型的附加的输出。缺省的是，0(零)值表示正常的设备操作。

为了排定失效，用户单击在各个设备框916或920上的失效模式按钮958(如果失效模式已经启用)。各自的设备失效菜单964窗口将展开，其在图25中是传感器失效菜单窗口。由于致动器失效菜单窗口是类似的，因此仅仅讨论失效菜单窗口964。该失效菜单窗口964包含用于不同的预定义失效的按钮966。单击这些按钮966以将这些失效录入到失效时间表(failures chedule)968中。该时间表列出用于选定的失效模式的各个参数，其中一些参数是可编辑的。这些参数是：“Nos.(编号)”970、“Failure Mode(失效模式)”972、“Tab Nos.(标签号)”974、“Failure Start Time(失效起始时间)”976，“Failure End Time(失效终止时间)”978，和“Association(关联)”980。该“Nos.”参数970是失效录入的序号。“FailureMode”参数972是失效的名字，“Tab Nos.”参数974是指派给该失效的设备的标签号。该设备必须为待实施的失效而存在。“FailureStart Time”参数976是以日、小时和分钟为单位的起始时间。可以使用任何非数字字符来将这些数分开。如果仅仅录入单个数，那么假定其代表分钟。如果录入两个数，那么假定其代表小时和分钟。“Failure End Time”参数978是以日、小时和分钟为单位的终止时间。录入的数的解释遵循用于起始时间的相同的模式。

“Association”参数980用于捕捉注释。当单击失效按钮时，录入失效编号和名称。这些字段是不可编辑的。如果没有录入起始时间，那么不会启动该失效。如果录入的起始时间进行到终止时间，那么该失效在起始时间开始并在终止时间截止。如果起始时间大于或等于终止时间，那么该失效在起始时间开始并且继续保持直到模拟时间的结尾。失效菜单窗口964在底部也具有命令行按钮982，其是：“Reorder(重新排序)”，其按照上升的起始时间的顺序对这些失效进行重新排序；“Save”，其保留任何已改变的值；“Cancel”，其恢复上一次保存的值；“Help”，其展开帮助窗口；以及“Close(关闭)”，其保存任何改变并且关闭该窗口。该Save和Cancel按钮只有在时间表上的任何信息自从上一次保存以来改变时才被启用。在失效菜单窗口964上显示的剩余项目是自明的。

控制器

控制器框(Controller block)918类似于器件框914。其示出如单选按钮选择的所有可用的控制器，所述单选按钮选择允许一次仅选择一个。为了选择控制器模型，单击模型的单选按钮984。要注意，控制器模块控制和校正对于外部激励的变化影响使患者稳定的自动照料(care)。这通过以连续的方式正确地管理给药来进行。尽管APCATS 900提供待尝试的标准控制算法的清单，但是其也具有引入用户定义的控制器的选项。基本思想是提供插入且运行该控制器(plug-in-and-run-the-controller)类型的情况。这些选项显示如下：控制器1(修改参数)；控制器2(修改参数)......；和控制器n(修改参数)。在选择控制器模型之后，将会出现控制器参数窗口。由于控制器参数窗口类似于器件菜单922(图24)，因此未示出该控制器参数窗口，并且未提供关于如何调整列出的控制器参数的进一步讨论。任何时候改变该控制器都会断开先前存在的输入和输出的连接。在运行模拟之前，用户必须建立在该控制器和提供其输入和接受其输出的模块之间的新的连接。

测试台仿真器

选中在控制器框918(图22)的复选框960将启用该测试台仿真器按钮962，在单击该按钮时将引出测试台仿真器窗口986，如图26所示。测试台仿真器窗口986用于将干扰与事件类型链接。测试台仿真器窗口986的上半部包含事件类型按钮(Event type button)990，分组在四列中。在给定列中的按钮990涉及事件的相同的特定方面并且代表能够被触发的事件功能。每个按钮990都与通过干扰模块定义的干扰相关联。单击这些按钮990中的一个而将对应的事件录入到位于该窗口的较低部分中的事件时间表992中，所述对应的事件称为触发事件。事件时间表992是排定事件(干扰)什么时候发生、其持续时间和量值的时间表格。为了将干扰与时间表中的事件相关联，用户首先单击干扰而选定它。这一行将变成黄色的高亮显示。接着，对于在那一行录入的事件类型，单击相关联的一个按钮990。然后用户继续录入在那一行中的剩余值。

该触发事件在被触发时仅仅作用于在器件框914(图22)中选中的选定的患者模型。控制器框918通过使适当的触发事件与其相关联来意识到干扰。在“Event List(事件列表)”列下列出的触发事件具有几个属性：触发时间，如“Event Start Time(触发起始时间)”所示；相对触发时间，如“ALGO Action Time(ALGO作用时间)”所示；时间的持续时间，如“Action Span Time(作用跨度时间)”所示；以及“量”。事件类型是由该算法所使用的事件代码。其或者通过单击事件类型按钮之一来录入，或者通过录入对应的代码(在该按钮的括号中给出)来录入。相对触发时间是相对于物理上发生的事件的时间，在该物理上发生的事件中，控制器框918(即，ALGO 500)注意到该触发事件。控制器框918能够在下面的情况下被告知发生的事件：(a)在实际事件发生之前(负数)；(b)与该事件的发生同时；(c)在实际事件之后的某个时间(正数)。事件的持续时间用于选择在被触发之后事件保持激活态的持续时间。事件的量用于选择事件的量值。

测试台仿真器窗口986的底部包含命令菜单按钮994。按钮994及其功能如下。“PatientIni”显示初始化文件PatientIni的路径和名称。PatientInin文件包含控制器(例如APS500)使用的患者参数。“Experiment Directory(实验目录)”显示数据将存在的目录的位置，“保存”保存和更新当前变化的值。“取消”拒绝变化并且重新加载上一次保存的值，“帮助”显示帮助画面。“关闭”保存任何更新值并关闭该窗口。如果需要，也可以提供“刷新”按钮。

外部干扰

外部干扰框912(图22)提供用于模拟对碳水化合物消耗量、身体活动，以及过正常和健康生活的人所期望的其他活动进行的响应的装置。对于能够过正常生活的糖尿病患者来说，其身体功能必须调整以应付这种干扰/激励。闭环系统的稳健性、有效性和稳定性通过调查(1)在工作范围内的模型参数值的变化和(2)外部干扰/激励的所有可能场景来评价。单击APCATS主窗口902上的外部干扰框912显示出如图27所示的外部干扰菜单窗口(External-Disturbance menuwindow)996。在如图27所示的指定的“SELECT DIET CUM EXERCISEOPTIONS”的标题之下提供预先定义的一组激励功能按钮(excitationfunction button)998。通过写下如稍后章节中描述的新功能并且修改初始化文件DietInit能够很容易地将附加的激励功能引入到该列表中。这些选项对于测试各种场景、一组标准的测试案例，或者任意的用户案例是可用的。这些通过利用干扰功能和排定其发生来建立。

按钮998可以是启用的或者是禁用的，因为对于选择而言可用的干扰取决于选定的患者(器件)模型。因此，对于给定的患者模型来说，仅仅启用为该患者模型而定义的干扰，并且其对于选择而言是可用的。干扰可以以任何顺序来录入。外部干扰菜单窗口996也提供外部干扰时间表1000以设置模拟的长度。外部干扰时间表1000以列的形式列出了下面的内容：干扰的数量；干扰的名称；标度强度(scalestrength)；起始时间；终止时间；和关联。干扰的数量和名称是不可编辑的，而是在利用干扰选择按钮将这些干扰录入到表格中时设定的。标度强度值允许用户利用因数来缩放该输出值。缺省的为1的标度值表示正常的干扰。由于时间表1000的剩余的各列类似于测试台仿真器窗口986(图26)的时间表，在其使用中用于排定在模拟期间发生的干扰(激励)，因此不提供有关剩余各列的进一步讨论。此外，由于在外部干扰菜单窗口996底部的命令菜单按钮1002也类似于在失效菜单952上提供的那些按钮，因此也不提供进一步讨论。

干扰输出与器件参数的互相链接

外部激励一般来说驱动器件参数以及对该器件的输入。在该特定情况下，每个干扰功能都被认为是具有输出的模块，所述输出由以下内容组成：(1)需要连接到器件框914的输出和(2)与器件参数一一对应的干扰参数。使(多个)干扰输出加上来自干扰的参数输出继续传递以变为器件模型的输入和参数。然而，当同时出现多个干扰时存在一个重要的考虑因素。多个干扰功能的效应通过将来自所有干扰的输出求和以形成单个向量性输出而叠加，其变为对器件框914的输入。为了这样做，在干扰模型当中其需要每个干扰输出都与其他干扰输出在输出数量及其顺序方面一致。然而，从干扰框912的观点来看，对于输出的数量及其顺序没有限制。另一方面，参数输出必须在顺序以及数量方面与选定的器件一致。当多个干扰同时发生作用时，不同于上述输出，不是增加参数，而是将来自每个干扰的该参数集解决并确定参数值的单个集。管理这种场景的功能是过滤器功能。

在将外部干扰录入外部干扰菜单窗口996之后，过滤器功能得到来自选定的患者模型的参数的数量。将所有饮食的操作状态(operating status)(操作＝1；非操作＝0)用来自这些饮食的参数值进行复用(multiplex)。饮食的数量通过利用下面的逻辑来计算：饮食的数量＝输入向量的长度/(1+参数的长度)。录入的外部干扰的起始时间和终止时间变成激活该功能的时间和使其停止的时间。描述该饮食的数学函数不依赖于起始时间。关于终止时间，该函数可以具有设定时间过程(course)，并且在这种情况下存在处理终止时间的两种方法。该函数一般来说是微分方程式，具有在该函数中描述的所有的其初始条件和参数。该函数的特性是归一化的响应。通过在时间时间表1000中在“标度强度”列下提供的录入的标度值来缩放该输出。尽管正常情况下期望正的标度值，但是也可以录入负值来模拟负的效应。

连接端口表单(Connect Ports Form)

单击在APCATS主窗口902中示出的连接线引出图28所示的连接端口表单1004。在其左侧，连接端口表单1004列出可用的输出1006并将其编号。输出1006由发送该信息的框来生成。其右侧显示接收该信息的框连同空白编辑框的输入1008。为了建立特定输出1006和特定输入1008之间的连接，用户将对应于该输出的数录入到邻近该输入栏(input field)的编辑框中，其接收该输出。将未连接到输出1006的任何输入1008即具有空白编辑框的任何输入1008都设定为0。并且要注意，输入1008不能连接到多于一个输出1006。每个输出不必连接到输入。模拟将为所有列出的输出而生成数据，但是所留下的不连接的输出仅仅不用作对下一个模块的输入。输出可以连接到多于一个输入。在完成了所有所希望的连接时，单击右上角的“X”(关闭窗口)按钮以保存该连接并关闭该表单。

运行/存储窗格(Run/Store pane)

图29放大了APCATS主窗口902的运行/存储窗格904，其提供加载数据、保存数据和运行模拟的基本功能。此外，其显示实验设定，允许用户录入实验概要，并且最后，允许用户从APCATS 900退出。运行/存储窗格904的最左边的列显示所作出的入口和在起始入口表单(Startup Entry form)1010(图32)中修改的入口。从上到下显示了三条信息：用户名；实验组号和实验标识号；以及在使用中的范例(paradigm)(静脉内-静脉内、皮下-皮下、静脉内-皮下)。为了录入有关该实验的细节和注释，单击录入实验概要(EnterExperiment Brief)按钮1012。单击将会引出“APCATS 900-增加关于当前实验的详细资料”窗口(未示出)。在该窗口录入的信息存储在实验的文档资料(doc)文件中。该信息能够更新任何次数。

为了编译当前的APCATS 900设定并将其保存，用户单击视图状态(View Status)按钮1014。单击之后，向临时位置(工作区)写入状态信息并且在编辑器中显示。为了将输入变量的当前设定保存到文件，用户单击Save Cum Document Run按钮1016。也保存当单击视图状态按钮1014时显示的设置文档资料。将重新创建该实验所需的当前初始化设定写入到工作区的临时文件中。如果APCATS 900故障，那么通过单击起始入口表单(图32)上的Old按钮1015并且搜索在列出的文件目录中编排的该临时文件能够恢复该文件中保存的设定。为了在任何时候引出起始入口表单1010，单击起始表单(STARTUP FORM)按钮1018。起始入口表单1010(图32)用于对定义该实验的范围并保持适当记录所需的细节进行编辑。为了退出APCATS 900，单击“EXIT APCATS”按钮120。出现“Exit from APCATS(从APCATS退出)”的对话框(未示出)，其允许用户返回到APCATS900并且取消该退出命令。单击Continue(继续)按钮将继续关闭该应用程序。其在关闭APCATS主窗口900之前关闭所有APCATS生成的窗口。

为了开始模拟，用户单击Start Simulation(开始模拟)按钮1022。单击之后将引出图30所示的Simulation Parameters window(模拟参数窗口)1024。该模拟参数窗口1024允许用户设定模拟的起始时间和停止时间、选择积分例程和步长，并运行该模拟。大多数字段是自明的。缺省的是，模拟运行起始于时间0。录入非零值向该起始时间提供偏差。为了为模拟的运行设定终止时间，用户在StopTime(停止时间)文本框中录入值。停止时间必须大于开始时间以执行模拟。为了设定在该模拟中使用的积分例程，用户从解算程序(solver)下拉菜单1026中进行选择。为了设定积分步长，用户从步下拉菜单1028中进行选择。对于保存数据的时间，用户录入数据保存之间的时期。相对公差(relative tolerance)是一种积分收敛性判定准则。绝对公差也是一种积分收敛性判定准则。用户从下拉框1030中选择值来设定在模拟过程中显示的时间窗口。可用的选择是每小时、季度日(quarter day)、半天或每天，以及整个模拟。对于Simulink Model File Name(Simulink模型文件名)，在init文件中定义的标记控制用户是否能够对模拟模型文件重命名。如果得到授权，那么用户可以在Simulink Model Name(Simulink模型名称)编辑框中录入Simulink文件的名称。仅仅对于建立模型而言，在ini文件中定义的标记控制用户是否能够建立和观看模型。如果得到授权，那么该用户可以点击Build Model(建立模型)按钮1032以建立Simulink模型，为该Simulink模型在Simulink Model Name(Simulink模型名称)文本框中录入文件名。用户然后可以通过打开模型(mdl)文件来看该模型。

模拟运行

为了开始该模拟，用户单击Start(开始)按钮1034。单击该按钮将触发下面的动作：创建文档资料和初始化文件并将其保存；设定参数研究环；创建并模拟Simulink框图，以及保存最后得到的数据。对于系统的(S)或探索性的(E)实验，生成实验标识号并且将适当命名的数据文件保存到系统目录。如果出现保存文件中的问题，那么取而代之的是将其移动到归位(parked)数据目录(正常情况下位于用户的本地硬盘驱动器上)。对于在播放(P)组中的实验，请求用户提供实验标识号。

对于系统的(S)或探索性的(E)实验，向保持网络驱动器上的日志文件增加日志记录信息。单击继续按钮036将会根据已经完成的状态继续进行模拟，扩展该模拟。单击暂停/恢复按钮1038将会或者暂停运行模拟或者将暂停的模拟恢复。为了停止在进行中的模拟，用户单击Stop(停止)按钮1040。如果用户将该模拟停止，那么不会将来自局部模拟的数据保存。这防止创建不完全的数据集。Simulation Clock(模拟时钟)显示了模拟时钟时间。这允许用户监控模拟的过程。Current/Total Run Nos.(当前/总的运行数)以十六进制计数法显示当前的运行数和实验的总的运行。

在模拟运行之后，APCATS 900生成输出。下面的选项对于用户是可用的：生成性能测量；在模拟之前决定生成和保存什么输出；生成所有可能的输出并且稍后确定保存什么输出；生成并保存所有的输出；显现输出；以及将输出以ASCII、二进制格式，或任何其他数量的适合的电子格式保存到文件。以二进制格式保存数据具有简洁的优点，但是数据的传送变得有限。另一方面，保持ASCII数据文件使其处于可读取的形式，并且也使其容易可传送到其他软件以进行进一步的数据分析。

曲线图窗格(Plot pane)

APCATS主窗口902的曲线图窗格908允许用户将实验数据绘制在屏幕上或者作为硬拷贝，并且由图31放大。Run Number control(运行数控制)1042具有两个目的：(a)在模拟过程中起显示当前正在被模拟的实验运行的数量，和(b)在模拟的外面，起用于选择(多个)运行数，为其绘制数据。运行数以十六进制计数法的形式显示。为了在绘制选择的数据时选择多个毗邻的运行，用户按住换档键同时利用鼠标左按键来选择被绘制的运行范围的第一个数和最后一个数。为了选择多个离散的运行，按住控制键(Ctrl key)同时利用鼠标左按键单击被绘制的运行的各个数。Min(最小)控件1044和Max(最大)控件1046以十六进制计数法分别显示出最小运行数和最大运行数。滑动块1048提供选择被绘制的运行数的可供替换的方法。滑动块的左端和右端分别代表最小和最大运行数。

曲线图窗格908可以被分成按行和列对准的较小的子图区(subplot)。为了选择行数或列数，用户将所希望的值录入到Rows(行)文本框的Nos.(数量)和Columns(列)文本框的数量中。例如，录入2作为行数并录入3作为列数将形成6格子图区，每3个为一行，共2行。一旦已经建立了子图区的数量，用户就选择要在每个子图区上显示的信息。为了设置给定的子图区，用户从SelectSub-Plot(选择子图区)下拉框1050中选择子图区。这些子图区利用矩阵符号来列出，括号中第一个数代表子图区的行，第二个数代表列。对于每个子图区来说，将所需要的信息录入到在选择子图区下拉框之下的控件中。

为了设定x轴的标号，用户在Label X-Axis(标号X轴)文本框中录入标号。如果文本框留下空白，那么选定的自变量(x)的名称将用作标号。用户选择自变量，相对于该自变量从位于标号X轴控件之下的下拉菜单1052绘制数据。可以为每个子图区选择不同的自变量。缺省选择是时间。

为了设定y轴的标号，用户在Label Y-Axis(标号Y轴)文本框中录入标号。如果文本框留下空白并且仅选择一个自变量(y)，那么选定的自变量的名称将用作标号。如果文本框留下空白并且选择了多于一个自变量，那么y轴标号将是“***”。用户选择因变量以便根据刚好位于Plot It按钮至上的列表框1054进行绘制。为了选择多个毗邻的变量，用户按住换档键同时利用鼠标左按键来选择该范围内的第一个变量和最后一个变量。为了选择多个离散的变量，用户按住控制键同时利用鼠标左按键以单击各个变量。可以为每个子图区选择了高达5个因变量。选择变量将在选择列表之上的文本框中列出。

一旦已经为每个子图区录入了参数，就能够显示和打印曲线图。曲线图不能被创建，直到模拟具有完成的运行。然而，根据在前的模拟来绘制数据也是可能的。为了在屏幕上显示(多个)曲线图，用户单击Plot It按钮1056。Plot(曲线图)窗口出现，显示图表。为了创建曲线图的打印的(硬)拷贝，用户单击Print(打印)按钮1058。出现对话框(未示出)，允许用户选择各种打印选项。

修改初始化文件

当对APCATS 900进行初始化时，给所有可用的模型加载其缺省值。由这些对象来保持对这些值的后继改变。缺省值由APCATS主窗口902的各种图形对象来保持。每个图形对象都具有各种属性，每个图形对象的两个最重要的属性是UserData(用户数据)和Value(值)。随后的小节详述了由每个框的属性所管理的信息。下面的小节显示了在任何用户修改之前的各种初始化文件的内容。

ModelInit.m

function[MODEL_TYPE，MODEL_FUN]＝ModelInit％List Descriptive Titles and then function names％First DescriptorsMODEL_TYPE＝{′Model 42′，′Bergman Model′，′User Defined′}；％Location of the corresponding function filesMODEL_FUN＝{′model42′′berg′′usermodel′}；

DietInit.m

SensorInit.m

function[SENSOR_TYPE，SENSOR_FUN]＝SensorInit％List Descriptive Titles of Types of Actuators available％Default＝First Type％DescriptorsSENSOR_TYPE＝{′Sensor 1′，′Sensor 2′，′Sensor 3′}；％Location of the corresponding function filesSENSOR_FUN＝{′sensor1′′sensor2′′sensor3′}；

ActuatorInit.m

function[ACTUATOR_TYPE，ACTUATOR_FUN]＝ActuatorInit％List Descriptive Titles of Types of Actuators available％Default＝First Type％DescriptorsACTUATOR_TYPE＝{′Motor 1′′Motor 2′′Motor 3′}；％Location of the corresponding function filesACTUATOR_FUN＝{′motor1′′motor2′′motor3′}；

ControlInit.m

function[CONTROLLER_TYPE，CONTROLLER_FUN]＝ControllerInit％List Descriptive Titles of Types of Controller available％Default＝First TypeCONTROLLER_TYPE＝{′PID Controller′，′Adaptive Controller′，′GMS Controller′，′User Defined′}；％Location of the corresponding function filesCONTROLLER_FUN＝{′pid′′adap′′gms′′usercontrol′}；

SenFailInit.m

function[SENFAIL_TYPE，SENFAIL_FLAG]＝SenFailInit％Sensor Fail Init％Intialization File％List Descriptive Titles for Failure Modes％Default＝First Type％DescriptorsSENFAIL_TYPE{1，1}＝′Switch On′；SENFAIL_TYPE{2，1}＝′Switch Off′；SENFAIL_TYPE{3，1}＝′Error Beep′；SENFAIL_TYPE{4，1}＝′Pause′；％Use Flag Definition File(C:\testbed\FlagDefFile)to map％above descriptorsSENFAIL_FLAG{1，1}＝′NORMAL′；SENFAIL_FLAG{2，1}＝′NO SIGNAL′；SENFAIL_FLAG{3，1}＝′NO SIGNAL′；SENFAIL_FLAG{4，1}＝′SUSPEND/PAUSE′；

ActFailInit.m

function[ACTFAIL_TYPE，ACTFAIL_FUN]＝ActFailInit％ACTUATOR FAIL INIT％Initialization File％List Descriptive Titles of Types of Sensors available％Default＝First Type％DescriptorsACTFAIL_TYPE{1，1}＝′Switch On′；ACTFAIL_TYPE{2，1}＝′Switch Off′；ACTFAIL_TYPE{3，1}＝′Error Beep′；ACTEAIL_TYPE{4，1}＝′Battery Low′；ACTFAIL_TYPE{5，1}＝′Pause′；％Use Flag Definition File(C:\testbed\FlagDefFile)to map％above descriptorsACTFAIL_FUN{1，1}＝′NORMAL′；ACTFAIL_FUN{2，1}＝′NO SIGNAL′；ACTFAIL_FUN{3，1}＝′NO SIGNAL′；ACTFAIL_FUN{4，1}＝′SUSPEND/PAUSE′；ACTFAIL_FUN{5，1}＝′SUSPEND/PAUSE′；

定义干扰模型

下面是用于外部干扰的部分代码，其能够用作模版来创建附加的干扰。

S-function based	Block-diagram based
		FuncName.m←Name of the mfilefunction sys＝funcName(t，x，u，flag，param，Scale，t_duration)switch flagcase‘IS SIMULINK BLOCK’sys＝0；case‘STATE VARIABLES’case‘OUTPUT VARIABLES’case‘PARAMETER VARIABLES’％Redundant case for disturbance functioncase‘INPUT VARIABLES’case‘EVALUATE DERIVATIVES’case‘EVALUATE OUTPUT’case‘EVALUATE PARAMETERS’case‘EVALUATE MASK PARAMETERS’％Redundant case for non-blk diagramend	FuncName.m←Name of the mfilefunction sys＝funcName(t，x，u，flag，param，Scale，t_start，t_end，DestBlk)switch flagcase‘IS SIMULINK BLOCK’sys＝1；case‘STATE VARIABLES’case‘OUTPUT VARIABLES’case‘PARAMETER VARIABLES’％Redundant case for disturbance functioncase‘INPUT VARIABLES’case‘EVALUATE DERIVATIVES’％Redundant case for disturbance functioncase‘EVALUATE OUTPUT’％Redundant case for disturbance functioncase‘EVALUATE PARAMETERS’％Redundant case for disturbance functioncase‘EVALUATE MASK PARAMETERS’％Define block locationSrcBlkPath＝SrcBlkFileName＝SrcBlkName＝％Define List of Variables to be masked％Following Code is not to be modified％Code to obtain the block diagram，copyingand assignment of Mask Variablesend

定义患者模型

下面是用于器件模型的代码的实例，其也能够用作开发附加的患者模型的模版。

function sys＝model42(t，x，u，flag，paral)This is a template.You may add sub functions or functions to implement pieces of the switches.Thestring names use cell type structure.Each of the names are string characters and on separate rowswitch flag，case′STATE VARIABLES′，％EDIT state descriptor.xN＝{...′Glucose(G)′′Glucose Rate(GDOT)′′Insulin(I)′′Insulin Rate(IDOT)′}；％Default Values，Initial Conditionsx0＝[0030]；sys＝{xN，x0}；case′OUTPUT VARIABLES′，％EDIT output descriptorsys＝{...′Glucose(G)′′Insulin(I)′}；case′PARAMETER VARIABLES′，％EDIT Parameter DescriptorspN＝{...′Glucose Coeff[unit]′′Insulin Coeff[unit]′′Glucose Constant，KG′

′Insulin Constant，KI′}；％Default Parameter Valuesp0＝[25NaN0.12]；％Default Minimum ValuepMin＝[NaN-20NaN-1]；％Default Maximum ValuepMax＝[NaN10NaN1]；sys＝{pN，p0，pMin，pMax}；case′INPUT VARIABLES′，％EDIT Input Descriptorssys＝{...′Glucose Dosage[ml/min]′′Insulin Dosage[ml/min]′；case′EVALUATE DERIVATIVES′，％EDIT System dynamics given by appropriate equations％paral are the parameter values entering and set by external functions in general.If constant theyshould still be visualized as externally set values.k1＝para1(1)；k2＝para1(2)；k3＝para1(3)；k4＝para1(4)；xdot(1)＝x(2)；xdot(2)＝-k1*x(1)-k2*x(2)+u(1)；xdot(3)＝0；xdot(4)＝0；sys＝xdot；case′EVALUATE OUTPUT′，％EDIT Output Equationsy(1)＝x(1)；y(2)＝x(3)；sys＝y；otherwise，％Display Errormsg2disp(′Error：None of the switch options selected′)；end ％ end of switch

定义设备模型

下面给出了用于设备的部分代码，其也可以用于开发额外的设备模型。

S-function based	Block-diagram based
		function sys＝funcName(t，x，u，flag，param，DestBlk)switch flagcase‘IS SIMULINK BLOCK’sys＝0；case‘STATE VARIABLES’case‘OUTPUT VARIABLES’	function sys＝funcName(t，x，u，flag，param，DestBlk)switch flagcase‘IS SIMULINK BLOCK’sys＝1；case‘STATE VARIABLES’case‘OUTPUT VARIABLES’

case‘PARAMETER VARIABLES’case‘INPUT VARIABLES’case‘EVALUATE DERIVATIVES’case‘EVALUATE OUTPUT’case‘EVALUATE PARAMETERS’case‘EVALUATE MASKPARAMETERS’％Redundantcase for non-blk diagramend

case‘PARAMETER VARIABLES’case‘INPUT VARIABLES’case‘EVALUATE DERIVATIVES’％Redundant case for disturbance functioncase‘EVALUATE OUTPUT’％Redundant case for disturbance functioncase‘EVALUATE PARAMETERS’％Redundant case for plant functioncase‘EVALUATE MASKPARAMETERS’％Define block locationSrcBlkPath＝SrcBlkFileName＝SrcBlkName＝％Define List of Variables to be masked％Following Code is not to be modified％Code to obtain the block diagram，copying and assignment of Mask Variablesend

定义控制模型

下面给出了用于控制器模型的部分代码，其可用作开发额外的控制器模型的模版。

S-function based	Block-diagram based
		function sys＝funcName(t，x，u，flag，param，DestBlk)switch flagcase‘IS SIMULINK BLOCK’sys＝0；case‘STATE VARIABLES’case‘OUTPUT VARIABLES’case‘PARAMETER VARIABLES’case‘INPUT VARIABLES’case‘EVALUATE DERIVATIVES’case‘EVALUATE OUTPUT’case‘EVALUATE PARAMETERS’case‘EVALUATE MASKPARAMETERS’％Redundant case for non-blk diagramend	function sys＝funcName(t，x，u，flag，param，DestBlk)switch flagcase‘IS SIMULINK BLOCK’sys＝1；case‘STATE VARIABLES’case‘OUTPUT VARIABLES’case‘PARAMETER VARIABLES’case‘INPUT VARIABLES’case‘EVALUATE DERIVATIVES’％Redundant case for disturbance functioncase‘EVALUATE OUTPUT’％Redundant case for disturbance functioncase‘EVALUATE PARAMETERS’％Redundant case for plant functioncase‘EVALUATE MASKPARAMETERS’％Define block locationSrcBlkPath＝SrcBlkFileName＝SrcBlkName＝％Define List of Variables to be masked％Following Code is not to be modified％Code to obtain the block diagram，copying and assignment of Mask Variablesend

模拟(mdl)文件

下面的实例示出了模拟(mdl)文件，其如上所述可以由用户根据需要进行修改。

function[sys，x0，str，ts]＝modelname(t，x，u，flag，para1，para2，....)switch flagcase′STATE VARIABLES′... ...case′OUTPUT VARIABLES′... ...case′PARAMETER VARIABLES′... ...case′INPUT VARIABLES′... ...case′EVALUATE DERIVATIVE′... ...case′EVALUATE OUTPUT′... ...end％By convention，a cell structure format is maintainedvar＝{′Descriptor field′，Value1，Value2，...}；

上面对本发明的描述是为了说明和描述本发明的目的。其不是穷举或者用来将本发明限制为所公开的明确的形式，根据上面的教导，其他修改和变化是可能的。选择和描述上面所公开的实施例来解释本发明的原理及其实际应用，由此使本领域技术人员能够最好地利用本发明。本发明意在将随附的权利要求解释成除了由现有技术所限定的范围之外还包括本发明其他可选择的实施例。

Claims (24)

1.一种由(多个)用户使用的用于为(多个)患者的慢性病管理而开发患者特定疗法的计算机化系统，该系统包括：

数据收集模块，使该系统能够根据数据收集协议而收集患者特定数据，并且对该患者特定数据进行完整性和质量检查；

用户接口，使该用户能够从该系统提供的多个患者模型中选择患者模型；

模块确认模块，使该系统能够确认选择的患者模型；

分析模块，使该系统能够将该患者特定数据应用于选择的患者模型以提取有用的患者特定生理信息，并且利用提取的患者特定生理信息来开发用于医治该患者的慢性病的一个或多个患者特定疗法；

结果确认和呈现模块，使该系统能够确认该一个或多个患者特定疗法并且能够在该用户接口上呈现经确认的一个或多个患者特定疗法中的那些疗法以求批准。

2.根据权利要求1所述的计算机化系统，其中该数据收集协议指定待收集的特定数据、待收集的方式和顺从性过程。

3.根据权利要求1所述的计算机化系统，其中对于完整性和质量检查，该数据收集模块使该系统能够检查在所收集的患者特定数据与数据收集协议和时间戳之间的不一致性，以确定是否在所需的时间段内进行收集，并且确定对于所收集的患者数据，数据值是否在预定义的范围内并在特定时间窗内提供预先确定的数目的样本。

4.根据权利要求1所述的计算机化系统，其中该系统从客户端计算机、计算机服务器、便携式存储器设备、计算机存储器以及计算机可读介质中的至少一个提供多个患者模型。

5.根据权利要求1所述的计算机化系统，其中该多个患者模型每一个都在数学上表示人体生理机能的至少一个方面，并提供到不同生理状态、条件或参数的映射。

6.根据权利要求1所述的计算机化系统，其中该模块确认模块使该系统能够在所选择的患者模型上进行贝叶斯分析、成本函数分析、参数估计、统计分析、数值分析、范围分析、增益值分析、测试场景分析、模拟和建模中的至少一个。

7.根据权利要求1所述的计算机化系统，其中该模型确认模块使该系统能够确定模型参数，所述模型参数随后被用于确认所选择的患者模型。

8.根据权利要求1所述的计算机化系统，其中该分析模块提供分析工具，所述分析工具使该系统能够进行模拟、统计分析、灵敏度分析、可视化、信息提取、优化中的至少一个，以及提供建议，所述建议包括定量给药的定时、类型、量、锻炼和进餐中的至少一个。

9.根据权利要求1所述的计算机化系统，进一步包括规则/准则集模块，其根据该数据收集协议来支配该系统对患者特定数据的收集。

10.根据权利要求1所述的计算机化系统，其中该结果确认和呈现模块提供模拟工具，所述模拟工具使该系统能够对一个或多个患者特定疗法测试稳健性、稳定性、对参数变化的灵敏度以及有效性中的至少一个，以及生成置信区间。

11.根据权利要求1所述的计算机化系统，其中该系统是客户端/服务器系统。

12.一种基于对患者特定生理机能的动态建模而开发患者特定疗法的计算机化系统，该系统包括计算机，该计算机配置成提供对至少一个数据库或其他存储单元中存储的许多软件模块进行访问，这些软件模块包括：

第一软件模块，配置成经由该计算机提供对一个或多个数据收集协议进行访问，所述数据收集协议限定了至少一类待收集的患者特定数据和收集患者特定数据的方式；

第二软件模块，配置成经由该计算机提供对用于开发一个或多个患者特定模型的信息进行访问，所述患者特定模型配置成模拟该患者的一个或多个方面的生理机能；

第三软件模块，配置成经由该计算机提供对一个或多个软件工具进行访问，所述软件工具将根据一个或多个数据收集协议而收集的患者特定数据应用于一个或多个开发的患者特定模型，以便从中确定一个或多个患者特定疗法；以及

第四软件模块，配置成经由该计算机提供对确认这些患者特定疗法的一个或多个软件确认工具进行访问，并且在该计算机上呈现该一个或多个患者特定疗法。

13.一种在计算机化系统上为(多个)患者的慢性病管理而开发患者特定疗法的计算机实现的方法，该方法包括：

提供数据收集模块，该数据收集模块使该系统能够根据数据收集协议而收集患者特定数据，并且对该患者特定数据进行完整性和质量检查；

提供用户接口，该用户接口使该用户能够从该系统提供的多个患者模型中选择患者模型；

提供模块确认模块，该模块确认模块使该系统能够确认选择的患者模型；

提供分析模块，该分析模块使该系统能够将该患者特定数据应用于选择的患者模型以提取有用的患者特定生理信息，并且利用提取的患者特定生理信息来开发用于医治该患者的慢性病的一个或多个患者特定疗法；

提供结果确认和呈现模块，该结果确认和呈现模块使该系统能够确认该一个或多个患者特定疗法并且能够在该用户接口上呈现经确认的一个或多个患者特定疗法中的那些疗法以求批准。

14.根据权利要求13所述的计算机实现的方法，进一步包括利用该数据收集协议来指定待收集的特定数据、待收集的方式和顺从性过程。

15.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统来检查在所收集的患者特定数据与数据收集协议和时间戳之间的不一致性，以确定是否在所需的时间段内进行收集，并且确定对于所收集的患者数据，数据值是否在预定义的范围内并提供预先确定的数目的样本。

16.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统来从计算机服务器、便携式存储器设备、计算机存储器以及计算机可读介质中的至少一个提供多个患者模型。

17.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统来修改所选择的患者模型并增加新的患者模型，所述患者模型在数学上表示人体生理机能的至少一个方面，并提供到不同生理状态、条件或参数的映射。

18.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统在所选择的患者模型上进行贝叶斯分析、成本函数分析、参数估计、统计分析、数值分析、范围分析、增益值分析、测试场景分析、模拟和建模中的至少一个。

19.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统来确定模型参数，所述模型参数随后被用于确认所选择的患者模型。

20.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统进行模拟、统计分析、灵敏度分析、可视化、信息提取、优化中的至少一个，并且提供建议，所述建议包括定量给药的定时、类型、量、锻炼和进餐中的至少一个。

21.根据权利要求13所述的计算机实现的方法，进一步包括利用规则/准则集模块，该规则/准则集模块根据该数据收集协议来支配该系统对患者特定数据的收集。

22.根据权利要求13所述的计算机实现的方法，进一步包括利用该系统对一个或多个患者特定疗法测试稳健性、稳定性、对参数变化的灵敏度以及有效性中的至少一个，以及生成置信区间。

23.根据权利要求13所述的计算机实现的方法，进一步包括将该系统设置为客户端/服务器系统。

24.一种用于根据在计算机上对患者特定生理机能进行动态建模而开发患者特定疗法的计算机实现的方法，该方法包括：

将该计算机配置成提供对至少一个数据库或其他存储单元中存储的许多软件模块进行访问；

将第一软件模块配置成经由该计算机提供对一个或多个数据收集协议进行访问，所述数据收集协议限定了至少一类待收集的患者特定数据和收集患者特定数据的方式；

将第二软件模块配置成经由该计算机提供对用于开发一个或多个患者特定模型的信息进行访问，所述患者特定模型配置成模拟该患者的一个或多个方面的生理机能；

将第三软件模块配置成经由该计算机提供对一个或多个软件工具进行访问，所述软件工具将根据一个或多个数据收集协议而收集的患者特定数据应用于一个或多个开发的患者特定模型，以便从中确定一个或多个患者特定疗法；以及

将第四软件模块配置成经由该计算机提供对确认患者特定疗法的一个或多个软件确认工具进行访问，并且在该计算机上呈现该一个或多个患者特定疗法。

Images