CN101821741A - 用于被调用事件的医学诊断、治疗和预后系统及其方法 - Google Patents

Abstract

公开了诊断、治疗和预后系统(DTPS)及其方法以帮助医疗服务提供者或者患者诊断、处理以及解释数据。装置提供基于方案的数据采集、以及用于测试数据完整性和准确性的机制。所述数据然后通过分析引擎被驱动以在定量意义上表征该患者身体的代谢状态。所述表征然后被用于诊断该患者、确定治疗、评价算法策略、以及提供对潜在用例场景的预后。

Description

用于被调用事件的医学诊断、治疗和预后系统及其方法

技术领域

本发明总体上涉及慢性病管理，并且尤其涉及一种计算机化医学诊断、治疗和预后系统及其方法，其分析所采集的个体人类生理以帮助医生诊断所述个体的慢性病，并且其基于使用专门的数据采集段、分析段和评价段的混合而被执行的分析来提供特定于患者的治疗和所建议治疗的预后。

背景技术

传统上，治疗/疗法基于单独的临床测试和测量设备来诊断疾病或病症(ailments)。对于大部分情况而言，使用这些测试和设备的目的是获得单独的、优质的测量。这样的测量提供了快照(snap-shot)。然而，为了理解该疾病的系统动态和潜在的系统特性，需要一系列的测量。

一系列的测量显然会产生更多的数据。然而，将这些数据转换成可操作的信息并不总是容易的。实际上，识别什么问题可以被解决以及需要什么先决条件是一个很重要的任务，从而能够使得通过连续或频繁的测量所提供的更充足的数据对医学实践有用。此外，制药公司执行描述药物的代谢活动的特征以及确定药物剂量规划(shema)的任务。通常，制药公司执行精细的临床试验以确定对于目标人群的药物作用强度和药效。但是严格地说，药物的药代动力学和药效学二者都是特定于患者的。基于人群的方法由于该慢性病的变异性而不能理想地适于确定对病症(例如在每天都使用胰岛素药物的情况下的糖尿病患者)的药物治疗。在这种情况下，医疗人员常常要从特定的准则出发对剂量规划进行微调。通常，医疗服务提供者在患者的帮助下进行受控的监视和胰岛素剂量调节方案。

糖尿病的最普遍形式是由于胰岛素的制造减少(1型糖尿病，第一种被识别的类型)、或者由于身体组织对胰岛素的敏感度降低(2型糖尿病，更常见的形式)造成的。前者的治疗需要注射胰岛素，而后者则通常通过口服药物来控制，并且仅当口服药物无效时才需要胰岛素。其它加快糖尿病的破坏性影响的健康问题是吸烟、高胆固醇水平、肥胖、高血压以及缺乏有规律的锻炼。因此，由于血糖水平是不断变化的，所以患者对于治疗的理解和参与很重要。

控制葡萄糖是减缓葡萄糖对器官的破坏性影响的最好方法。常规治疗(CT)、强化常规治疗(ICT)和针对泵用户(pump users)的强化常规治疗(CSII)是用于控制葡萄糖的常用方法。这些治疗的局限在于，它们不利用考虑患者特有因素的工具，这些因素例如是生理变异性、代谢差异以及压力、锻炼、疾病和膳食的影响。

葡萄糖浓度是通常被测量用于正常血糖(euglycemic)控制的基本参数(例如为了提供血液中的葡萄糖的正常水平)。其它用于确定更佳治疗的可用信息涉及由各种活动(例如摄取膳食、进行体力活动、与工作有关的压力等)所导致的代谢负荷。胰岛素给药、其它药物治疗等是用于目标生理参数的进一步调节机制。该治疗规则在葡萄糖测量、胰岛素敏感度、胰岛素-碳水化合物比、基础胰岛素率(basal insulin rate)和其它因素(例如压力水平和锻炼影响)方面被定义。除了葡萄糖测量之外，当前的方法还基于拇指规则、经验法则和基于葡萄糖测量的反复评估来确定所述参数。

鉴于以上所述，在当前解决糖尿病患者日常生活需要的临床方法中存在严重的缺点。没有一个解决方案综合了各个可用的方法。迄今为止所提供的方法都不能直接评估特定于患者的需要，相反，在一段时间内通过试错法来解决特性(specifics)。此外，简单地综合本领域可用的各个方法并不能达到所期望的效果。对于每种方法，都存在必须在整个过程中加以开发和调整的特定元素，从而以所期望等级的安全性、准确性和鲁棒性来发生作用。此外，所期望的是，给医疗人员提供一种工具，其用于采集特定于患者的随时间的信息，并且在设计针对这些慢性病和/或疾病的治疗时将所采集的信息应用于动态的、特定于患者的模型。

发明内容

本发明可以包括所附权利要求中所记载的一个或多个特征、和/或一个或多个以下特征及其组合。

在一个实施例中，在一个实施例中，公开了一种用于在计算机上提供具有慢性病的患者的医学诊断、治疗和预后的计算机化的方法。该方法包括：在该计算机上指定针对该患者的特定诊断和治疗需求的一个或多个方案(protocol)；在该计算机上指定患者模型；在该计算机上执行分析以确定该患者模型的参数；在该计算机上执行所述参数的模型验证以进一步保证该患者模型已经捕获了针对该患者的特定诊断和治疗需求的适当的动态；应用按照所述一个或多个方案所采集的数据以使用该患者模型在计算机上进行分析，从而提供至少一个推荐的特定于患者的治疗；以及在该计算机上提供该推荐的特定于患者的治疗以供认可。

在另一实施例中，公开了一种在计算机上评价特定患者的药代动力学效果和治疗功效的计算机化的方法。该方法包括：向该计算机提供患者数据，所述患者数据包括关于该患者的代谢信息、生理信息和生活方式信息；在该计算机上对所述患者数据执行有效性检验，以提供经验证的数据；在该计算机上使用一个或多个患者模型分析所述经验证的数据，以使病情进展量化，从而通过考虑所述代谢信息、生理信息和生活方式信息来确定适合于该患者的治疗，并确定治疗预后；以及提供所述适合的治疗和治疗预后。

在另一实施例中，公开了一种用于提供具有慢性病的患者的医学诊断、治疗和预后的计算机化的系统。该系统包括：采集方案和患者模型的数据采集；第一软件模块，其用于测试按照所述采集方案之一所采集的数据的完整性和准确性；第二软件模块，其用于利用至少一个患者模型来分析所采集的数据，以表征该患者的特定代谢需求；以及第三软件模块，其在对该患者诊断中使用所表征的患者的特定代谢需求，以确定特定于患者的治疗，并提供所述特定于患者的治疗的预后。

根据以下对于本发明各个实施例的结合附图所作出的说明，将会更彻底地理解本发明的这些和其它特征和优点。

附图说明

当结合以下附图阅读时，可以更好地理解本发明的实施例的以下具体说明，在附图中相同的结构用相同的附图标记来表示，并且在附图中：

图1是各种糖尿病管理实用工具/设备的框图，所述工具/设备用于捕获患者活动且辅助可能传送信息的胰岛素治疗；

图2是示出了根据本发明的、用于基于对患者生理的动态建模来开发特定于患者的治疗的诊断、治疗和预后系统(DTPS)的实施例的框图；

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

图4是根据本发明的、用于开发特定于患者的治疗的处理的一个示例性实施例的流程图；

图5是根据本发明实施例的、用在图2的系统中的软件构件的框图，所述软件构件用于提供自动胰腺系统(APS)以开发特定于患者的治疗；

图6是根据本发明实施例的、用在图2的系统中的软件构件、设备和交互的框图，所述软件构件、设备和交互使得图5的软件能够作为使用葡萄糖测量的闭环系统，以基于特定于患者的治疗来提供合适的控制动作；

图7是根据本发明实施例的、用在图2的系统中的软件构件、设备和交互的框图，所述软件构件、设备和交互使得图5的软件能够作为开环系统，以基于特定于患者的治疗来提供合适的控制动作；

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

图10是示出了在一天的不同时刻胰岛素和葡萄糖之间的设定点(setpoint)关系的图；

图11和12是图形化地示出了根据本发明来分别为第一和第二处理功能选择时间间隔的示图；

图13是示出了不同葡萄糖区域场景(scenarios)的两个图；

图14是示出了针对快速作用的碳水化合物摄取的葡萄糖增加(push)的图；

图15是示出了针对快速作用的碳水化合物增加的、随时间的血糖反应的图；

图16是根据本发明的碳水化合物校正模块的处理的示图；

图17是示出了胰岛素残余药效学的图；

图18是示出了针对单位推注(a unit bolus)的、随时间的胰岛素变化的图；

图19是示出了胰岛素脉冲(impulse)预测的图；

图20是示出了根据本发明的算法所使用的定时(timing)描述的图；

图21是作为例子被提供以示出根据本发明的模型参数标识的图；

图22是用于根据本发明的自动胰腺控制算法测试套件(APCATS)软件的图形用户界面的示意图，该软件在图2的系统上实施以用于开发特定于患者的治疗；

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

图24是根据本发明的、给仿真环境提供用于改变患者模型参数的设备(plant)菜单窗口的图形用户界面示图；

图25是根据本发明的、给仿真环境提供故障菜单窗口的图形用户界面示图；

图26是根据本发明的、给仿真环境提供事件项表格的图形用户界面示图；

图27是根据本发明的、给仿真环境提供选择饮食/累计锻炼表格的图形用户界面示图；

图28是根据本发明的、给仿真环境提供连接端口表格的图形用户界面示意图；

图29是图22的图形用户界面的运行/存储窗格(pane)部分的示图，所述窗格部分提供了用于加载数据、保存数据和运行仿真的基本功能；

图30是根据本发明的、给仿真环境提供仿真参数表格的图形用户界面的示图，所述图形用户界面允许用户设定仿真的开始和停止时间、选择积分例程(routine)和步长、以及运行仿真；

图31是图22的图形用户界面的绘图窗格(pane)部分的示图，所述绘图窗格部分允许用户在显示屏上用图表示实验数据或者用图表示实验数据作为硬拷贝；

图32是根据本发明的、给仿真环境提供启动项表格的图形用户界面的示图；

图33是示出了根据本发明实施例的软件构件的运行序列的处理流；

图34是示出了根据本发明实施例的控制周期的图；和

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

具体实施方式

总体上，本发明是通过如下方式来帮助分析对本质上是慢性的疾病(比如糖尿病、哮喘和心脏病)的治疗和管理的计算机体系结构和处理，所述方式为：在动态系统中分析个体的人类生理和代谢活动，并且使用户能够定义方案、分析所采集的数据、微调治疗需求，并提供特定于患者的诊断、治疗建议和预后。虽然本文是在帮助一个患者的方面来讨论本发明，但是可以理解，本发明也可用于帮助多个患者。

在一个实施例中，本发明通过测试所提出的解决方案并提供围绕该解决方案的置信区间来增强治疗效果。在一些情况下，所提出的解决方案是特别针对一个效果(或者在一些情况下为多个效果)的表征和/或控制的专门方案。代替于使用基于人群的规则来解决该问题，本发明的方法从一开始就假设特定于患者的疾病状态，由此使得治疗适合于该患者的代谢、生理和生活方式的考虑事项。

在一个实施例中，本发明提供一种直接处理确定特定于患者的胰岛素治疗的需求的系统工具。应当理解，本发明的处理适用于开环、闭环和半闭环系统，并且可以适于各种葡萄糖测量方法和各种胰岛素给药方法。在其它实施例中，本发明适用于其它需要连续药物治疗的慢性病。

本发明基于药物的药代动力学和药效学以及相关参数来将生理模型、代谢模型和数学用于确定药物剂量。本领域技术人员能够理解，药代动力学是对于药物的吸收、分布、代谢和排泄的研究，而药效学是对于药物的生化和生理效应和它们的作用机理、以及药物浓度与药效的相关性的研究。在一个实施例中，本发明使药效学方法计算机化以对输入数据进行操作，并提供如下事项作为输出，所述事项为：例如不利的或者所期望的药代动力学和药理作用之间的关系。

本发明帮助用户理解各种生理状态的药理作用，并且帮助诊断疾病、提炼治疗，并且不仅允许开发特定于患者的疗法，而且还允许开发比现有疗法更严格的(stringent)疗法。本发明的系统及其方法被进一步扩展以提供所述个体的慢性病的预后。

在一个实施例中，本发明从通用(generic)输入项和/或通用输出项的角度公开了一种装置，其用于接收/命令(i)设备、(ii)算法以及(iii)向用户通知信息性/可操作的/警告的结果。事件信息可以是连续更新或以离散的方式发生。因而一个事件是一个事务(transaction)。该方法还描述了使疗法能够生成的算法结构。

在另一实施例中，本发明公开了一种使用所采集的葡萄糖数据和其它可用信息来合成特定于患者的模型以及使用该模型来确定治疗参数的方法。该处理可以包括：(1)识别特定于患者的模型；以及(2)定义各个生理参数。对所识别的模型进行仿真，或者应用特定的分析工具来满足所述生理参数的定义，从而推断它们的值。所确定的参数是特定于患者的，因为它们是从特定于患者的模型获得的。

在另一实施例中，本发明还使用户能够执行各种分析，包括通过仿真来评估临界情况以保证稳定和鲁棒的解决方案，所述解决方案满足例如ADA准则的要求和/或将关键参数(例如HbA1C)保持在该主体(subject)的预期目标的范围内。

因而本发明使得执业医生能够利用帮助分析患者的特征行为并且又使用该分析来确定治疗、检验治疗效果以及了解患者特征的工具。本发明是集成系统，其收藏各个系统构件——患者数据存储器、数学分析工具、数据呈现方法、与外部设备的集成、数据符合(data compliancy)技术、对于稳定性和鲁棒性而被测试的治疗方法——它们一起提供了一种为糖尿病患者进行诊断、治疗确定和预后的高级方法。下文中用糖尿病作为示例，对本发明进行更具体的详细阐述。特别地，现在提供关于测量、分析以及本发明所使用的其它信息的论述。

测量&分析

众所周知，糖尿病是一种代谢综合症，其中身体的生理机能由于各种病因而不能正常工作以调节血糖。为了管理该病，存在许多用于捕获患者活动和辅助胰岛素治疗的糖尿病管理输入、实用工具和设备。例如，图1示出了用于管理糖尿病的典型的疾病管理构件，其需要相互作用和交换信息以确定和评价所指定的胰岛素治疗的有效性。该疾病管理构件包括：个人计算机；集中式数据库，其用于数据管理；算法，其提供用于基于用户输入，葡萄糖测量和胰岛素给药量，经由用户界面、测量、测试等的用户输入，经由用户界面、测量、测试等的医疗人员(HCP)输入来管理泵输注的程序；以及智能胰岛素泵；智能血糖(bG)仪；以及其它手持设备，其可以是集成的或者是独立运转的独立设备。通常，这些疾病管理构件进行交互以互相交换信息，这在图1中通过箭头示出。这样的信息(数据)交换是在与所述构件相关联/由所述构件提供的程序进行函数调用并且通常与输入/输出变元(argument)一起调用该函数调用时的常规需要。所述变元表示结构化的内容，并且理想地，至少全部设备疾病管理构件都应该理解这样的结构及其潜在/实质的内容。然而，在这样的系统中，将事件已经发生通知给各个构件是一个问题。事件是由一个构件生成的可以被另一构件使用的信息单元(例如bG测量、低血糖事件、低血糖事件值、剂量调节、方案改变、算法改变等)。特别地，问题在于提供下述信息结构，所述信息结构从使用该疾病管理构件的大量用例(use case)中捕获必要信息。另一个问题在于这样的事实：当管理慢性病(比如糖尿病)时，信息交换是时间关键和内容关键的。此外，所交换的信息必须能够被该设备用于机器解释以及被人类用于人类解释。

交换信息的特征也是另一个问题。例如，慢性病管理中的信息特性被表示如下。时间具有许多变型，例如，事件何时发生、一个事件相对于另一事件何时发生、以及事件可以发生多长时间。事件本身具有特征性质，并且需要以下方面：什么事件被触发，该事件的强度(strength)或幅度(magnitude)如何。事件可以由在指定时间的发生或者具有相应幅度的指定操作的一系列发生构成。一旦事件已经被启动，能否将其关闭(turn OFF)，或者更一般的问题是，能否在为删除的特定情况下来修改之前的事件。还需要知道该事件的频率。在同步调用或异步调用的环境中如何触发该事件。本发明解决这些问题，这通过下文中提供的论述将会变得显而易见。

生理参数的测量构成了DTPS的基干。例如，存在可容易测量的参数，比如体温、血压、体重等。另一些参数可以通过精心设计的实验室测试(例如用于识别特定成分的血液样本测试、尿液分析和被执行以识别微生物的培养等)来提供。然而，测量任何生理参数都有局限性。例如，复杂和昂贵的装置会限制诸如由类似HbA1C或胰岛素化验的测试提供的信息的可用性。关于影响人类生理的活动(比如锻炼、食物摄取(即碳水化合物的摄入)、以及压力)的定量的和/或定性的信息可能被歪曲。另外，这些参数可以表现为被指定为ON/OFF的效果，而不是被量化的效果。此外，可以预期，由于各种限制因素，不可能精确地获得量化的信息。还存在技术上的限制，例如，由于访问生理参数(例如比如葡萄糖异生或肠道葡萄糖吸收的量)的物理或伦理限制而不能进行测量。而且，数学上构造的参数(例如生物利用度和药效)通常是基于人群的，并且对于某些个别患者而言可能不是足够特定的。

对于糖尿病的护理，通常使用葡萄糖仪所获得的葡萄糖测量结果是用于指导治疗管理的主要参数。存在多个与管理糖尿病相关的次要参数、比如HbA1C、酮和FFA。然而，这些测量不需要有规律地进行。此外，存在关于活动的信息(例如膳食消耗和锻炼的量和执行速度)，其对于调节和纠正治疗很重要。可以帮助分析患者特定的需求的本发明，应用这些关于测量和分析的数据来建立模型，该模型用于估计不能被直接测量的生理参数并且表示患者的潜在生理和代谢。本发明还允许在这些生理参数不断发展时使所述参数可视化，从而使用户可以了解该慢性病的潜在的动态行为。本发明的这样的分析和可视化提供了对系统(糖尿病患者)的运行的更深入的了解，并且可以利用诊断、治疗确定和预后来帮助医疗服务提供者。因此，本发明增强了医疗服务提供者分析数据、诊断疾病、确定治疗和得出对该治疗的预后的能力。为了帮助说明本发明的实用性，下文中提供了如下例子。

为了测试个体中的糖尿病，通常使用的方案需要个体断食至少8小时。测量空腹葡萄糖，然后该个体经受口服葡萄糖耐量测试，该测试需要摄入浓缩的葡萄糖饮料，随后是通常在2小时的过程中的多次葡萄糖测量。基于所采集的数据来确定对于糖尿病的诊断。使用频繁或连续的数据与使用稀疏的测量结果相比提供了以下优点：数据可以被绘图以使模式和趋势可视化；数据可以被用于预测或预期测量结果的变化；以及数据可以被用于建立模型和表示潜在的药代动力学和药效学。通常，使用定义明确的方案来采集上述数据。本发明的方法覆盖了以下方面。采集特定于患者的数据以支持本发明的诊断、治疗和预后工具。在认识到该方案是特定于分析的并且每个方案被专用于识别或确定该疾病的特定方面(因果关系)的情况下，提出数据分析。所提出的数据分析旨在对该患者的疾病系统如何运行进行最佳地量化，以及识别特定于患者的参数。接着，在认识到基于人群的研究表示平均效应而不一定针对特定于患者的需求的情况下，通过本发明来定义该患者的疾病系统动态行为。本发明还考虑到，虽然了解动态系统如何运转所需的原理可能在特定情形下是清楚的，但是指望人来智力地进行关键的数学分析是不合理的。

例如，药物、特别是日常使用和/或规律地需要的那些药物与诸如锻炼的活动、压力、不同食物、以及其它药物相互作用，所有的这些都会对药物的效果产生实质影响。在下文中稍后的章节中所描述的本发明的系统工具(其完成确定这些效果的数学方面)将帮助医疗服务提供者评价和量化上述效果。这些效果还被转换到用药计划中，针对给定的效果，选择相应的治疗。所述效果可以被用于预测该效果的影响力(impact)，以及帮助生成警告和警报。下文的描述解释本发明的系统(装置)和方法。

总体系统

考虑到上述测量和分析，DTPS是硬件-软件系统，其在运行于PC平台上的典型的客户端-服务器环境下工作，并且在图2的框图中被示出。该总体系统被想像为在地理上是分布式的，并且可以通过内联网和/或因特网机构来访问。在一个所示实施例中，系统10提供服务器计算机12和客户端计算机14。服务器计算机12包括常规的处理器16，其可操作地连接到输入设备18、监视器20、以及存储器22(例如RAM、ROM和(一个或多个)硬盘驱动器)。输入设备18可以是常规键盘、常规点击设备、麦克风等中的任意之一或其组合，并且监视器20可以是任何常规的计算机监视器。服务器计算机12的处理器16还可操作地连接到数据库24，该数据库24位于计算机12内部或者可替换地位于计算机12的外部。服务器计算机12的处理器16还可操作地连接到常规的通信接口26。

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

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

客户端计算机14的处理器34通过设备接口46向外部设备48(其比如为患者数据测量和/或采集设备的形式)提供信息或者从外部设备48接收信息。该患者数据测量和/或采集设备48的例子可以包括但不限于：血液或组织葡萄糖传感器或其它葡萄糖测量设备、体温感测或测量设备、体重测量设备、血压监测设备、HbA1C监测设备、可植入或外部佩戴的药物输注泵(其例如用于管理胰岛素或者一种或多种其它的降低或提高血糖的药物)、手持或其它数据采集设备(其用于监测患者膳食摄取数据、患者锻炼数据，患者疾病数据等)等等。

客户端计算机14的处理器34还可操作地连接到常规的通信接口32。该通信接口26和32可以是提供服务器计算机12与客户端计算机14之间的电子通信的任何常规通信接口。例如，在所示实施例中，通信接口26和32被配置成以常规方式通过万维网(WWW)、因特网和/或内联网来提供服务器计算机12与客户端计算机32之间的电子通信。可替换地或附加地，该通信接口26和32可以是或包括电话调制解调器，使得该服务器计算机12和客户端计算机32可以通过电话进行通信。本公开所构思的有：服务器计算机12与客户端计算机14之间的电子通信可以可替换地通过其它常规有线或无线通信链接来实现。在任何情况下都能够理解：系统10可以包括可以是或可以不是地理上分布式的多个联网的服务器计算机12，并且每个服务器计算机12都可以服务于可以是地理上分布式的多个客户端计算机14。此外，基于用例情况，本处理(即软件部分)可以在客户端或服务器端进行配置，这将在下文中进行论述。

软件部分

参考图3，示出了根据本发明的由图2的系统10所使用的软件50的一个示例性实施例。可以认为该软件50被以常规的方式配置为允许客户端计算机14与服务器计算机12之间的适当交互，以用于执行用户鉴权、获取和/或将数据存储在数据库中以及实施辅助性活动(比如数据的后台处理、触发事件的自动化等)。在所示实施例中，软件50包括操作系统和网络协议部分52、核心应用部分54、以及功能模块部分56。该操作系统和网络协议部分52被以常规方式配置为允许各个计算机、设备、和/或数据库之间的交互。该核心应用和功能模块部分54和56可以分别位于服务器计算机12、客户端计算机14上或者至少部分在这两者上。

通常，核心应用部分54包括多个常规的软件算法和其它常规的数据管理软件(其可以是市售的)。作为一个特定的例子，核心应用部分54可以包含常规的数学软件包。一般地，这样的核心数学工具将包括：一个或多个优化工具、一个或多个统计分析工具、一个或多个仿真工具、一个或多个灵敏度工具、一个或多个可视化工具、以及一个或多个用于提取信息的工具(比如常规的模式识别工具、包络识别工具等)。特定的例子包括但不限于：LAPACK、线性代数包、IMSL(独立媒体解决方案有限公司(IndependentMedia Solutions 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中的数学包和库提供调用例程(call routines)；提供用于分析数据的例程和用于以文本和图形的形式呈现数据的图形例程；以及提供用于与各个外部设备48进行通信的驱动器。可替换地或附加地，该功能模块部分56可以被配置成执行更多或更少的功能。

为了开发总体上针对疾病、以及专门针对慢性病的特定于患者的治疗，采集专门与该患者相关的数据。一般地，待采集的特定于患者的数据的类型和其将被采集的方式取决于许多因素，其包括但不限于：正被开发的治疗所针对的特定疾病、疾病的严重性、治疗方案的类型和可用性、患者的年龄、体重和性别、患者的一个或多个个人习惯(比如患者遵循严格饮食时间表和/或规律地锻炼、遵循一个或多个可用的治疗时间表的习性)等等。该数据采集方案模块70包含多个不同的数据采集方案，其中每个都被设计成以特定的方式来提供对待采集的一个或多个特定类型的特定于患者的数据的采集。更具体而言，该数据采集方案模块70中所包含的每个数据采集方案都指定了待采集的数据、采集数据的方式(即执行该数据采集的方式)、对该数据采集方案的任何限制、将在采集所述数据时使用的电子的或其它形式的任何专用工具和/或设备、以及将保证和/或提高所采集数据的质量的任何安全措施(safeguard)和/或数据采集技术。示例性地，根据各种数据采集方案中的任一方案而被采集的特定于患者的数据被存储在数据库24中(图2)，但是该被采集的数据中的一些或全部可以可替换地被存储在一个或多个其它数据库中、和/或可以被服务器计算机12和/或客户端计算机14访问的存储单元中。

存储在数据采集方案模块70中的每个数据采集方案都针对特定的目的而被定义，并且包括经过测试和评价达到至少一个特定目标的数据采集计划，假定已经满足常规的数据符合性和完整性检验。为此，每个数据采集方案可以包括或者访问例如具有数学模块形式的数据符合性程序(procedure)，该模块检验所采集数据中的不一致性，以及检验针对已经被采集的特定数据所定义的要求。这种要求的例子包括但不限于：时间戳符合性、(一个或多个)数据值范围、(一个或多个)日期范围等等。附加地，每个数据采集方案都可以包括或访问例如具有数学模块形式的数据质量程序，该模块在所采集的数据的性能和/或统计特性方面检查所采集数据的质量。

规则/准则集模块78提供规则集，其根据数据采集方案模块70中可用的各个数据采集方案来管理特定于患者的数据的采集。此外，该规则/准则集模块78还根据各个数据采集方案来提供用于采集特定于患者的数据的准则。该准则例如可以提供但不限于：各个数据采集方案的计算机可读描述、关于下述内容的指导，所述内容为：什么时候、即在什么情况下使用或者什么时候不使用一个或多个特定方案、使用方案的优点和/或缺点、通过使用方案可以达到或不能达到的目标、方案的限制或方案的适用性的限制等等。

一般地，可以使用各种常规技术以各种方式来采集针对数据采集方案模块70中的各个数据采集方案中的任一方案而被采集的数据。例子包括但不限于：使用一个或多个常规测量设备来测量特定于患者的一个或多个状态；患者正经历的事件或状况等等。可以使用文本所述的一个或多个电子设备48来使特定于患者的数据的测量结果可供客户端计算机14使用。附加地或者可替换地，可以使用常规的电子或非电子测量设备和/或系统来进行对特定于患者的数据的测量，并且可以使用输入设备40(例如键盘、点击设备、麦克风或其它常规输入设备或机构)将结果人工键入或输入到客户端计算机14中。例如，患者正在经历的事件或状况可以包括但不应当限于：摄取膳食或零食、锻炼、疾病、压力等。可以通过一个或多个电子设备48和/或通过使用所述常规输入设备之一进行人工输入来使得这些信息可供客户端计算机14使用。

在数据采集方案模块70中可能可用的数据采集方案的例子包括但不限于一个或多个数据采集方案，该方案提供：根据时间对患者血液或组织葡萄糖测量结果的采集；根据时间对患者体温测量结果的采集；根据时间对环境温度测量结果(患者身体周围)的采集；根据时间对患者心跳速率和/或脉搏率的采集；根据时间对患者血压的采集；对一个或多个其它患者生理状况参数(例如体重、月经、压力、疾病等)的采集；根据时间对膳食或零食(即碳水化合物摄取)信息的采集；根据时间对患者体力活动的采集；随时间对胰岛素给药信息的采集；根据时间对干预(intervention)信息的采集；根据时间对患者到诊所和/或医院就诊的采集；对关于一次或多次膳食摄取、运动能力等的特定信息的采集；对专业仪器和/或设备的使用；对一个或多个纸张复印件(paper copies)、电话、因特网通信的使用以交换和/或记录信息等等。

图2的系统10示例性地被设计成以人类为目标，但是根据本公开也可以构思以其它动物为目标的系统10的实施例。一般地，人类所表现出的一些行为特性是物种所共有的，而其它个别的行为特性依赖于其它因素，比如性别、年龄、种族等。人类生理行为的模型可以被构造为人类生理的数学表示，并且可以示例性地按照微分方程来加以定义。这样的患者模型还可以被开发成在所有患者的范围内都总体上相同，同时也可以预期行为的变异性。在这种情况下，模型参数将具有特定于患者的值。

患者模型模块72(图3)使多个这样的患者模型可用，其中所述患者模型被配置成对人类生理的一个或多个方面在数学上进行建模，这提供了到不同生理状态、状况和/或参数的映射。例如，该患者模型模块72可以对人体中的葡萄糖吸收进行建模，而一个或多个其它模块可以对管理胰岛素(或者其它提高或降低葡萄糖的药物)的一个或多个效果进行建模。该患者模型模块72可以包括被配置成对同一生理方面进行建模的竞争模型，并且每个这样的模型都可以具有用于定义特定模型参数、用于采集与患者有关的数据和/或用于分析特定数据的某些优点或缺点。在这一点上，规则/准则集模块78可以包括：与一个模型针对特定生理方面、针对特定患者类型(例如年龄、性别、种族等)和/或使用场景与另一模型相比的特定的适用性或不适用性相关的规则和/或准则；与关于任何特定模型的使用的限制相关的规则和/或准则；与在建模工作可能还处于开发过程中的情况下的源的链接相关的规则和/或准则等等。所述一个或多个模型还可以包括伴随的用例(use-case)信息。通过该患者模型模块72可用的多个不同患者模型允许将模型和/或模型参数映射到特定的生理状态、状况或参数。

所述患者模型可以被患者模型模块72从便携式存储设备44、计算机存储器38、和/或计算机可读介质(诸如，例如光盘、数字视频盘等)直接地存储和/或访问。所述患者模型可以被患者模型模块72从数据库24或连接到服务器12的其它存储单元和/或因特网30间接地访问和/或存储。例如，该数据库24或其它存储单元可以包括具有到文献和/或其它相关技术文档的相关链接的模型类型和/或结构的数据库。可替换地或附加地，该数据库24或其它存储单元可以包括临床试验结果(例如示踪研究)和/或到与这些临床试验相关的信息的相关链接的数据库，从该数据库中可以获得潜在的模型结构。在二者中的任一情况下，一个或多个适当的患者模型可以通过经由患者模型模块72访问与该一个或多个模型的结构、参数和/或开发相关的信息而被直接或间接地访问。一般地，于是，该患者模型模块72可以包含特定于人类生理的一个或多个特定方面的一个或多个开发出的患者模型，和/或可以包含这样的信息，根据该信息可以定位、确定和/或开发一个或多个该模型。所述一个或多个开发出的患者模型可以是或包含一个或多个专有(proprietary)的患者模型(即由特定人和/或组织开发出的、并且其使用受到该人和/或组织的限制的患者模型)、和/或一个或多个商业的或以其他方式公共可用的患者模型(即可从一个或多个第三方获得)。

当已经使用患者模型模块72选择了特定的模型时，则必须确定模型参数的值。为了实现这点，患者模型模块72还可以包括提供对这些模型参数进行确定的一个或多个子模块。该一个或多个参数确定子模块的例子可以包括但不限于：用于识别模型参数的一个或多个子模块；用于提供输入、输出、状态和/或参数描述的一个或多个子模块；用于确定参数范围的一个或多个子模块；用于确定模型参数灵敏度(例如模型参数增益值)的一个或多个子模块；用于提供前面开发出的、推导出的或定义的模型参数的一个或多个子模块等等。

用于识别模型参数的一个或多个子模块可以使用隐式或显示地确定参数值的数据拟合技术。该子模块的一般例子包括但不限于如下子模块，所述子模决提供：贝叶斯分析，其提供初始猜测值(initial guess)和提供参数估计的先验分布；代价函数，其求出参数估计(后验分布)；统计分析；数值分析；用于范围分析(range analysis)的迭代/非迭代技术；增益值分析；测试场景分析、建模；以及提供预先已知的参数描述(输入、输出、状态等)、范围和灵敏度(例如增益值)的那些。可替换地或附加地，用于识别模型参数的一个或多个子模块可以指定用于识别模型参数的程序或架构。一个该模型参数识别程序或架构的例子(无论如何都不应将所述例子理解为限制性的)是这样的模型参数识别程序或架构，其：i)提供模型参数和针对所述参数的初始猜测值，ii)如果遵循贝叶斯方法，则提供用于参数估计的先验(priors)，iii)设置、选择或使用特定的代价函数，iv)选择或使用特定的代价函数求解技术或架构，和v)迭代或非迭代地求解模型参数估计。

用于确定参数范围的一个或多个子模块可以使用统计、数值、迭代或非迭代技术中的一个或多个来隐式或显式地确定一个或多个模型参数的可接受范围，和/或确定模型参数变异性。一个或多个该子模块可以例如使用常规技术来创建表示模型参数范围的测试场景，在该模型参数范围内可以测试和评估所述模型。例如，在一个实施例中，本发明可用于在计算机上定义和实施测试场景，其帮助测试所推荐的特定于患者的治疗，并且对使用所推荐的特定于患者的治疗可获得的潜在的治疗质量进行量化。在其它实施例中，当指定治疗时，本发明可用于评估场景以及给所述治疗增加诸如例如对生活方式的约束：如限制食量、限定快速吸收的膳食等。

用于确定模型参数灵敏度的一个或多个子模块可以使用一个或多个统计、数值、迭代或非迭代的技术来隐式或显式地确定模型参数增益值。一个或多个这样的子模块可以例如使用常规技术来分析模型参数灵敏度，以在一个或多个模型参数范围内和/或响应于模型参数确定中的误差来评价所述模型的稳定性。

尤其是对于糖尿病护理，使用各种已知血液和/或组织葡萄糖测量技术所获得的葡萄糖测量结果提供基本参数，围绕所述参数来试图通过常规糖尿病治疗实现正常血糖控制(euglycemic control)。本公开认识到，其它参数也与管理糖尿病相关，并且可能规律地或定期地需要或不需要动态或静态确定这些参数。该其它参数的例子包括但不限于：HbA1C(糖基化或糖化血红蛋白——可用于随时间识别血浆葡萄糖浓度的一种形式的血红蛋白)、FFA(游离脂肪酸)、酮体(脂肪酸分解的副产物)等等。虽然可以通过参数测量来监测一些这样的参数，但是另一些可能需要通过测量其它参数和适当的建模(即虚拟测量)来估计。还可以使用与患者活动相关的附加信息来修改、调节或纠正糖尿病治疗。例子包括但不限于：膳食量、消耗频率、和/或执行速率、锻炼频率、持续时间和/或负荷、患病频率、持续时间和/或严重性等等。能够设想，通过刚才所述的患者模型模块72可用的患者模型中的至少一些将在此结合一个或多个这样的生理参数和/或其它信息，从而使得可以使用这样的一个或多个模型来估计不能直接测量或难以直接测量的一个或多个生理参数。所产生的患者模型将提供动态地或静态地监测患者的潜在生理机能(例如患者的代谢)的能力。

功能模块部分56还包括模型验证模块74，其提供了对一个或多个基于计算机的仿真程序的访问，其中所述仿真程序被配置为分析患者模型的一个或多个方面。一个或多个仿真程序例如可以被存储在数据库24或其它存储单元中，并且在这种情况下，该模型验证模块74提供用于访问这样的程序的接口。可替换地或附加地，该模型验证模块74可以包含到模型验证程序的文献或其它源的链接。在任何情况下，一个或多个基于计算机的仿真程序通常将分析所选择的患者模型在一个或多个特定测试场景下的操作，并且将结果与已知标准、与更广泛的人群数据、与以前所分析模型的结果、与统计预期的结果等相比较。所述一个或多个基于计算机的仿真程序可以附加地标记(flag)和/或报告与所述比较的不一致性。示例性地，该模型验证模块74提供对一个或多个执行以下功能中的任意之一或多个的基于计算机的仿真程序的访问，所述功能为：i)实施与所选择的患者模型相关的基于计算机的仿真；ii)在一个或多个所指定的工作范围内验证所选的患者模型；iii)提供使得易于理解所选择的患者模型的工作空间、限制和误差来源的信息；iv)对所选择的患者模型应用特定的用例并且分析模型结果；v)利用以前已经采集的临床数据测试所选择的患者模型等等。

模型验证模块74可以包括提供特定的分析工具以评估所选择的患者模型的一个或多个子模块。该一个或多个分析工具子模块的例子可以包括但不限于：用于测试特定用例场景的一个或多个子模块；用于在一个或多个所指定的工作范围内测试患者模型的一个或多个子模块；用于以统计方式分析所选择的患者模型的一个或多个子模块等等。该用于测试特定用例场景的一个或多个子模块可以示例性地提供对一个或多个如下软件程序的访问，所述软件程序以将一个或多个被识别的模型特性与如上所述的预先确定的标准相比较的方式来训练该患者模型。用于在一个或多个所指定的工作范围内测试患者模型的一个或多个子模块可以示例性地提供对一个或多个如下软件程序的访问，所述软件程序在一个或多个特定工作范围内分析患者模型以确定在变化的工作范围和/或状况下所述患者模型多好地仿真潜在疾病或病、和/或所述患者模型多好地仿真潜在疾病或病对于规定的治疗的反应。用于以统计方式分析所选择的患者模型的一个或多个子模块可以示例性地提供对于一个或多个如下软件程序的访问，所述软件程序以允许确定一个或多个解决方案是否表示一个或多个预期的统计特性的方式来训练所述患者模型以生成模型的一个或多个解(solution)。

该规则/准则集模块78可以示例性地提供管理一个或多个子模块的操作的规则集，和/或提供：与一个基于计算机的仿真程序相对于另一个程序对于特定的患者模型、模型类型、模型工作范围和/或使用场景的特定适用性或不适用性相关的准则；与对任何特定仿真程序的使用的限制相关的准则；与到源(在那里可以找到相关的基于计算机的仿真程序)的链接相关的准则；和/或与到源(在哪里相关的基于计算机的仿真程序工作可能处于开发过程中)的链接相关的准则等等。

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

分析模块76还可以使其它的数据分析和/或可视化工具可用，所述工具中的一个或多个可以是特定于所试图开发的疗法的。任何这样的其它分析和/或可视化工具都可以被存储在数据库24或其它存储单元中，并且可以通过分析模块76而被直接访问，或者可以在别处使用并且通过分析模块76经由到该工具的相关链接而被间接地访问。示例性地，可以通过分析模块76而被访问的核心数学工具可以包括但不限于：i)一个或多个优化工具；ii)一个或多个统计分析工具；iii)一个或多个仿真工具；iv)一个或多个灵敏度工具；v)一个或多个可视化工具；以及vi)一个或多个用于例如通过模式识别等来提取信息的工具。在一个实施例中，该分析模块76提供如下的分析工具，所述分析工具使得系统能够执行仿真、统计分析、灵敏度分析、可视化、信息提取、优化中的至少之一，并且提供包括剂量给药(dosing)、锻炼和进餐的类型、数量和定时中的至少之一的推荐。在一个实施例中，每个推荐可以包括在当前时刻、在将来时刻或在由该分析确定的时刻或在由终端用户确定的时刻的动作。

示例性地，规则/准则集模块78可以提供管理一个或多个分析的操作和/或通过分析模块76可用的其它工具的操作的规则集，和/或提供：与一个这样的工具相对于另一个在特定工具、工具类型、对任何特定使用的任何限制方面的特定适用性或不适用性相关的准则；与到源(在那里可以找到相关分析、可视化或其它工具)的链接相关的准则；和/或与到源(在那里关于这样的分析、可视化或其它工具的相关工作可能处于开发的过程中)的链接相关的准则等。

使用可通过分析模块76获得的工具，可以将根据数据采集方案模块70中的一个或多个方案采集到的特定于患者的数据应用于一个或多个所选择的患者模型(其通过患者模型模块72而被选择并通过模型验证模块74而被验证)，以提取有用的特定于患者的生理信息。然后，有用的特定于患者的生理信息可用于开发用于治疗特定于患者的疾病或病的一个或多个疗法。例如，在糖尿病治疗的环境中，可通过分析模块76获得的工具可以包括但不应限于：提供对信息(比如模型参数值)的提取的软件工具；提供对糖尿病相关数据的分析的软件工具；优化软件工具；趋势分析软件工具；提供对基础剂量给药和推注剂量给药的确定和/或推荐的软件工具；提供对状况(比如低血糖和高血糖)的警告的确定和应用的软件工具；提供对允许患者输入患者相关数据的一个或多个图形界面的开发的软件工具等等。

在名称为PATIENT INFORMATION INPUT INTERFACE FOR ATHERAPY SYSTEM、具有代理案号ROP0014PA/37554.20/WP23627US的共同未决美国申请第____号中描述了一种示例性的提供对允许患者输入患者相关数据的一个或多个图形界面的开发的软件工具，该申请被转让给本公开的受让人，并且该申请的公开内容通过引用结合于此。在名称为SYSTEM AND METHOD FOR DETERMINING DRUGADMINISTRATION INFORMATION的共同未决美国申请第11/297733号中公开了另一种软件工具，该申请被转让给本公开的受让人，并且该申请的公开内容通过引用结合于此。本领域技术人员会想到提供对允许患者输入患者相关数据的一个或多个图形界面的开发的其它软件工具，并且任何这样的其它软件工具都被本公开构思出。

如上文关于核心应用部分54所描述的那样，软件50的功能模块部分56(图2)还包括设备驱动器管理模块80，其提供对于一个或多个设备驱动器的访问。还包括有结果验证和呈现模块82，其提供对将特定于患者的数据应用于一个或多个所选患者模型的结果的分析和验证，并且提供用于可视地呈现该结果的一个或多个工具。例如，该模块82可以提供对一个或多个如下仿真工具的访问，所述仿真工具可以被选择和执行以测试治疗鲁棒性的临界情况、评估解决方案的稳定性、确定和评估该治疗对于参数变化的灵敏度、和/或通过执行大量仿真来生成置信区间、和/或给出治疗结果位于某个范围内的指示。该模块可以可替换地或附加地提供对一个或多个如下工具的访问，所述工具可以被选择和执行以提供：用于保证安全和鲁棒地使用所述结果的一个或多个故障保险(fail-safes)；对所述结果的有效性(比如功效、效能、亲和力)的分析；对所述结果在治疗趋同性和稳定性方面的分析；一个或多个基于计算机的生物标志物(bio marker)(比如HbA1C)；一个或多个患者监测时间表；一个或多个治疗建议等等。该模块82还可以提供对于一个或多个可视呈现软件工具或软件包的访问，以用于以任意的常规格式(例如文本报告、图表、绘图等)来图形化地呈现所述结果。下文中提供了一个特定示例，其示出了根据本发明的使用图1的系统10以及图2和3的软件50的处理。

处理实施例

现在参照图4，示出了用于开发特定于患者的疗法的处理100的一个示例性实施例的流程图。该处理100有助于保证满足治疗的最小规则、对(多个)选项的选择与实现治疗目标有关、以及保证解决改善患者治疗的特定问题。该处理100不需要被一次全部执行，而是可以在多个入口点(entry point)中的任意之一处被访问，这在下文中将要更具体地描述。

该处理100的第一个入口点推进到步骤102，在该步骤处，根据可以通过数据采集方案模块70访问的一个或多个数据采集方案来采集特定于患者的数据。能够理解的是，在一个实施例中，所述采集方案可以是由管理医学团体(比如ADA或类似的组织)指定的那些方案，而在另一些实施例中，如由医疗专业人员(比如医疗从业人员、医生等)来建立。在步骤102，可以通过使用上面关于图1所述的患者数据测量/采集设备48的任何一个或多个实施例将这些数据输入到客户端计算机14中来采集特定于患者的数据。可替换地或附加地，可以在步骤102通过如下方式来采集特定于患者的数据，所述方式为：测量或在其它情况下以常规方式确定特定于患者的数据，并且然后通过在监视器36包括一个或多个触摸屏按钮或切换键的实施例中的输入设备40或监视器36中的一个或多个将这些数据输入到客户端计算机14中。

在步骤102之后，处理100推进到步骤104，在该步骤处，对所采集的特定于患者的数据的完整性和质量进行检验。例如，在一个实施例中，该数据采集方案模块70包括或者访问具有数学模块形式的数据符合性程序，其检验所采集的数据中的不一致性，并且检验针对已经被采集到的特定数据所定义的要求。该要求的例子包括但不限于：时间戳一致性、一个或多个数据值范围、一个或多个日期范围等。在一个实施例中，该数据符合性程序被预先评价以获得最佳结果。此外，该数据采集方案模块70可以包括或访问例如具有数学模块形式的数据质量程序，其在所采集数据的性能和/或统计特性方面检查所采集数据的质量。例如，为了确定数据质量是否不好，该系统检查所采集的数据的若干方面。在这个实施例中，一个方面是所采集数据的关联性，其中使用从包含查询的数据库模块调用的关联性查询来从所采集的数据中提取数据内容。通过适当的统计模块对所提取的数据内容进行统计分析，所述统计模块接收所提取的数据内容并输出结果，其中所述结果关于每天的测量频率、进餐时间、推注、相对于膳食量的推注量等等预期的基准。另一个方面是所采集的数据的定时，其中在步骤104中，根据将要求基准与患者所采集到的信息相比较来检查数据时间序列，以提供所采集的数据的置信区间。在所示实施例中，客户端计算机14或服务器计算机12可操作以通过访问和执行数据符合性和数据质量模块中的任意之一或二者来在步骤104执行该检验。

在步骤104之后，处理100可选地可以包括：在步骤105中，基于对所采集的数据中的某些数据的数据质量和可用性的当前评估，来在监视器36上向用户呈现用于进行选择操作的推荐和数据可用性状态。在随后的章节中将提供对该步骤的更具体的论述。然后，处理100推进到步骤106，在该步骤处，客户端计算机14或服务器计算机12可操作以确定每个数据采集方案的数据完整性和/或数据质量检验是否已经通过或失败(或者基于在步骤105中所选择的推荐和数据可用性状态来确定是否已经通过/失败)。在所示实施例中，如果一个或多个数据完整性和/或质量检验失败，则算法执行返回到步骤102，从而使得可以根据一个或多个失败的数据采集方案来采集一组新的特定于患者的数据。可选地，如图4中所示，处理100可以包括位于步骤106的“失败”分支与步骤102之间的附加步骤108。在这个实施例中，在步骤108，客户端计算机14或服务器计算机12可操作以仅仅识别需要被重新采集的数据(即在任何一个或多个数据采集方案中的被损坏或者以其它方式未通过数据完整性和/或质量检验的数据)。之后，在步骤102，仅需要重新采集在步骤108被识别的数据。在另一实施例中，提供可选步骤110，其中用户被询问是否需要在此时重新输入被识别的数据。如果回答是是，则处理100返回到步骤102，否则处理100继续使用在图4中标识的第二入口点采集的可用数据进行进一步的分析。

进入处理100中的第二入口点处于步骤106的“通过”分支与随后的步骤120之间。能够理解的是，该第二入口点还充当离开步骤102-108的执行的出口点。在任何情况下，步骤106的“通过”分支和/或入口点2都推进到步骤120，在该步骤处，从可通过患者模型模块72获得的一个或多个特定于患者的模型中选择一个或多个适当的患者模型。在步骤120，可以使用客户端计算机12和/或服务器计算机12通过适当的用户界面(比如输入设备40(例如键盘、点击设备、麦克风或其它适当的用户输入设备))来选择所述一个或多个患者模型。可替换地或附加地，可以使用客户端计算机14和/服务器计算机12通过经由外部存储器存储设备(比如光盘只读存储器(CD-ROM)、软盘、USB-兼容存储设备等)访问一个或多个患者模型来执行步骤120。另外，可替换地或附加地，可以通过如下方式来执行步骤120，所述方式为：访问存储在数据库24或其它存储单元中的适当链接，并且然后通过构成核心应用54的一部分的常规网页浏览器访问该链接的相应网站或其它源。另一方面，如果所存储的链接对应于对一个或多个出版物的引用，则可以通过人工地或经由客户端计算机14和/或服务器计算机12访问所述一个或多个出版物来执行步骤120。在任何情况下，当所述一个或多个患者模型被选择时，步骤120还包括使用上述的技术中的任何一个或多个来识别模型参数值。在一个实施例中，并且参考图21，提供了示出模型参数识别的例子，下文中将对其进行论述。

为了阐述参数确定，例如通过患者模型72(图3)来描述简单的例子以概述步骤120中的处理。考虑临床研究，其中使用胰岛素泵(例如设备48(图2))来采用快速作用的胰岛素类型(比如例如Lyspro)来治疗I型患者。该泵能够伴随人工控制的推注(bolus)来输注基础胰岛素谱(insulinprofile)。为了该临床研究，该泵配备有红外控制，并且可以通过控制算法(比如ALGO 510(图5))以闭环方式而被命令，这将在稍后的章节中讨论。临床试验由使用该泵的一系列大大小小的皮下推注组成。这样就选择了一个脉冲响应模型，其通过方程式(1)描述：

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

方程式(1)的脉冲响应模型由三个主要参数组成。这些参数是：α近似地表示间接地充当滤波器的隔室(compartments)的数量，β是每单位胰岛素分布容积的峰值吸收速率的时间，而K是增益因子。所吸收的胰岛素分布在人体的胰岛素分布容积之内。该胰岛素被组织(比如肌肉、肝脏)利用并还被从循环血液中清除。近似地描述了整个过程的微分方程(2)是：

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

第一项

是清除项，并且被简单假定为与胰岛素浓度成线性比例(一阶指数型衰减)。然而，时间常数τ(分钟)是未知的。方程式(2)右边第二项是所输注的胰岛素推注与胰岛素吸收函数之间的卷积项。该项提供了通过胰岛素推注的任意序列进入到循环中的每单位容积所吸收的净胰岛素。每U/min的输入胰岛素推注u(t)＝0.278u′(t)，其中u′(t)的单位是U/hr。然后问题是确定特定于患者的胰岛素动力学的参数。如图21中所示，需要每U/hr的输入胰岛素推注u′(t)和输出胰岛素浓度观察值C_I ^Observation[k]U/mL(循环)。

该问题通过选择一组参数来解决，所述参数例如使方程式(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个仿真浓度。存在其它可以使用的最小化准则，并取决于问题要求。在这一阶段从数值解角度来看的问题是标准问题。通过使用如应用主体所指示的可用的许多优化例程之一来解决该问题。在这一例子中，可以使用来自名称为

的软件包的被称为“fmincon”的优化例程，比如从核心应用54之一调用和提供(图3)。该“fmincon”函数寻找多变量函数的约束最小值。然后该约束最小函数解出未知参数，其得到以下参数解：α＝1.28，β＝31.1min，τ＝56.7min，K＝1.93。

在步骤120之后，处理100推进到步骤122，在该步骤处，对在步骤120所选择的一个或多个患者模型执行模型验证处理。在所示实施例中，客户端计算机14和/或服务器计算机12可操作以通过访问来自模型验证模块74的一个或多个模型验证软件包来执行步骤122。该验证模块74使用在步骤122中所提供的完整参数解以及在所选患者模型上所使用的方案来进行该验证。

在步骤122之后，处理100推进到步骤124，在该步骤处，客户端计算机14或服务器计算机12可操作以确定在步骤120所选择的一个或多个患者模型是否已经通过模型验证步骤122，以及因而是否为有效的患者模型。如果不是，则在所示实施例中，算法运行返回到步骤120，从而使得可以选择一个或多个新的患者模型。可选地，如图4A中的阴影所示，处理100可以包括在步骤124的“否”分支与步骤120之间的附加步骤126。在这一实施例中，客户端计算机14或服务器计算机12在步骤126可操作以仅仅识别需要修改的一个模型(或多个模型)的部分和/或模型参数值。然后，在步骤120，仅需要在步骤120选择所识别的患者模型的部分，和/或只有所识别的模型参数需要修改。

进入处理100中的第三个入口点位于步骤124的“是”分支与随后的步骤140之间。能够理解的是，第三个入口点还可以充当离开步骤120-126的执行的出口点。在任何情况下，步骤124的“是”分支和/或入口点3推进到步骤140，在该步骤处，将按照步骤102-108在延长的时间段内所采集的特定于患者的数据应用于从步骤120-126得到的一个或多个经过验证的患者模型，以确定一个或多个患者疗法或治疗操作。可以通过客户端计算机14和/或服务器计算机12使用可经由如上文所述的分析模块76访问的分析工具中的任何一个或多个来执行步骤140。例如，所述一个或多个患者疗法或治疗操作可以是或者包括但不限于：对一种或多种药物的管理、对锻炼的推荐、和/或如上所述的其它疗法和/或治疗操作。

在步骤140之后，处理100推进到步骤142，在该步骤处，对于从步骤140所得到的一个或多个患者疗法和/或治疗操作来执行验证分析。在所示实施例中，客户端计算机14和/或服务器计算机12可操作以通过访问来自如上所述的结果验证和呈现模块82的一个或多个结果验证软件包来执行步骤142。在步骤142之后，处理100推进到步骤144，在该步骤处，客户端计算机14或服务器计算机12可操作以确定在步骤140确定的一个或多个患者疗法和/或治疗操作是否已经通过治疗验证步骤142以及因而是否为有效的疗法和/或治疗操作。在所示实施例中，如果不是，则算法执行返回到步骤140，从而使得可以选择一个或多个新的患者疗法和/或治疗操作。可选地，如图4中所示，处理100可以包括在步骤144的“否”分支与步骤140之间的附加步骤146。在这一实施例中，客户端计算机14或服务器计算机12在步骤146可操作以识别所述一个或多个患者疗法和/或治疗操作中需要修改的一个或多个部分。然后，在步骤140，仅需要在步骤140修改所述一个或多个患者疗法和/或治疗操作的被识别的一个或多个部分。

进入处理100中的第四个入口点位于步骤144的“是”分支与随后的步骤160之间。能够理解的是，该第四个入口点还可以充当离开步骤140-146的执行的出口点。在任何情况下，步骤144的“是”分支和/或入口点4推进到步骤160，在该步骤处，通过如上所述的一个或多个呈现设备和/或格式来将所述一个或多个患者疗法和/或治疗操作呈现给系统100的用户。可以通过客户端计算机14和/或服务器计算机12使用可经由如上所述的结果验证和呈现模块82访问的呈现软件包中的一个或多个来执行步骤160。

特定用例示例——示例A

以下是本文所述的一些概念的用例示例。该示例的步骤总体上遵循图4的算法100，并且可以通过常规的向导(即计算机用户界面，经由该计算机用户界面、通过一系列的对话来引导用户完成任务)来实现。该向导是对于糖尿病患者的信息收集和分类的混合，其目的是指引医疗专业人员获得(i)治疗确定的最终目的，和/或(ii)如图4的流程图中所示的中间结果。以下例子将被呈现在由该向导执行的步骤的框架中，但是可以理解，这个例子的步骤可以可替换地通过常规的方法(recipe)或指令集来实现。

在这个第一示例中，患者的病历档案和当前状态如下。主体是糖尿病I型患者，其上一次看医生是4个月以前。该主体是40岁男性，体重80kg(自上次就诊以来没变化)，并且当前正在使用快速作用的胰岛素，例如Lispro(自上次就诊以来没变化)。该主体据称每天平均测量3次bG(自上次就诊以来没变化)。之前就诊的平均进餐量(Mean Meal amount)值是35g、70g、85g和25g，并且当前的进餐量值未知。该主体的碳水化合物-胰岛素比是8gm/U(无变化)，且胰岛素敏感度是40mg/dL/U(无变化)。该主体的体力活动正常(无变化)。在该主体之前就诊时，他的HbA1C是7.5，并且现在是9.5。在这些事实模式下，医疗专业人员被指引去遵循针对典型I型糖尿病的经典(classical)数据采集方案。

在步骤102，该向导提示用户选择患者的糖尿病类型。选项是I型或II型。在这个例子中，选择I型。接着，该向导提示用户选择来就诊的原因。可用的选项是：新患者、临床试验、定期就诊(通常为2-3个月的就诊)、住院治疗后或已完成的重点监测(intensive monitoring)。在这个例子中，选择定期就诊。然后，该向导提示用户以下的输入，并且如果可用，则通过标准消息/数据检索方案执行以下操作：输入患者身高、体重、性别、年龄；获得相关的实验报告(A1C，LDL，HDL，BP，用药(Medication))；从相关设备下载数据：仪表数据、泵数据、PDA等；捕获患者行为(从所采集的数据，生活方式捕获)，诸如例如低血糖事件的数量，高血糖事件的数量，进餐定时分布，碳水化合物成分，胰岛素分布，体力活动，睡眠时间表，和工作时间表；排除标准；输入生理状态(患病，未患病)；输入用药；CSII；MDI；当前的治疗；和当前的治疗规则。在这个例子中，所采集的数据反映：当前的HbA1C＝9.5；上一次的HbA1C＝7.5；(上一次的平均值35g、70g、85g、25g)；由于缺少输入的数据，所以当前的进餐信息未知；bG测量结果很少；bG均值和SD是：(150+/-70)；并且整夜禁食未知，以及剩余的数据值。

基于上述输入/采集的数据，在步骤104中，该系统然后检验该数据的完整性/数据质量。在这个例子中，由于是定期就诊，医疗专业人员之前已经确定了：作为治疗目的，需要定期调整患者的治疗。因此，在该步骤期间，检查各个方面。例如，对于一些所选择的治疗目标，需要必备的数据采集来提供对于实现所选择的治疗目标有意义的结果。因此，在该步骤中，该系统检查以了解在所采集的数据中是否可获得对于特定的算法参数也敏感(sensible)的数据(例如在预先确定的范围内、在某个值以上/以下/是某个值等等)。此外，在步骤104中，统计分析所述数据内容以确定每天的测量频率、进餐时间范围、餐前推注(meal bolus)范围、相对于进餐大小的平均推注量等等。还检查所采集的数据中的数据时间序列。想法是：患者通常遵循下述日常模式，该日常模式由包括进餐、体力活动和工作时间表在内的活动组成。按照由该患者采集的该患者的生活方式、体力活动信息、进餐信息、测量序列和剂量给药信息，这些信息的具体细节将会在任意特定的一天而不同。当在一段时间内分析该改变的信息时，该改变的信息提供对治疗有效性的指示。在一个实施例中，关于预期的患者生活方式和应该被采集的至少最少的信息来检查由患者采集的这样的信息。

在数据分析和数据映射之后推断逻辑推理以解决：(a)下一组分析的关联性，(b)结果的置信区间；和(c)基于阈值的接受/拒绝标准。例如，在一个实施例中，如果考虑用药事件及其对bG的影响，则第一步是确定是否已经按照方案采集了数据。所希望的是，bG数据在大小以及测量时间方面都具有差异性。在一个实施例中，对照经验规则来检验测量结果的数量、测量结果的顺序、以及测量结果的差异性以确定数据的接受。在另一实施例中，应用一组经验规则以确定哪个所采集的数据低于基于阈值的接受标准，从而执行在实现期望目的方面的一定分析。例如，对于上述给定的病历历史示例，根据所述可用的数据和预期的控制质量，经验规则的一个输出将示出：餐后葡萄糖控制所需的bG测量结果与调整患者治疗的目标高度相关，以及需要采集最少的bG测量结果以提供有益的推荐来实现该目标。如果bG测量结果的采集低于该最小值，则在这一示例中，在步骤106中，数据采集质量将失败。

在步骤104中执行了检验后，可选地在步骤105中提供针对该患者的一系列治疗评估/推荐。紧接着每个治疗评估/推荐来提供关联性评定(rating)，该关联性评定所基于的是：基于所采集的数据质量的该治疗评估/推荐的选择将对产生患者治疗的改变所具有的影响。在该给定的示例中，这种治疗评估/推荐及其相关的关联性可以包括：(a)患者治疗采集不好(关联性95％)，(b)患者需要定期的治疗调整(关联性50％)，和(c)患者生活方式改变(关联性15％)。对于推荐(a)，经验规则的输出将得到结论：根据该采集的数据，A1C较差，患者感觉不好；读数指示较大的葡萄糖值；许多高血糖和低血糖事件；以及没有足够的bG测量结果来有效地调整患者治疗。因此，高关联性评定所基于的考虑因素是：新采集的数据有限并且旧数据是大约4-5个月之前的。对于如上所述的调整该患者治疗的推荐(b)，需要利用足够数量的餐前葡萄糖测量结果和餐后测量结果来对A1C加权。该方法还在高血糖和低血糖事件以及该A1C值之中权衡。然而，由于在所采集的数据中没有足够的bG测量结果，并且A1C不满意，因此该推荐的关联性较低，从而可能不是对于所给定的采集数据范围的最佳选择。当患者能够提供更多bG测量结果时，该推荐的关联性则将会增加。对于建议(c)，通过主要比较历史数据、通过比较平均值和/或使用移动窗和比较平均值和/或确定数据的趋势，来观察患者生活方式的变化(例如用药、移动/旅行到一个新的时区、改变体力活动、改变压力水平，或改变膳食摄取)，在这一点上，由于不好的数据采集，因此将给医疗专业人员在调节患者的治疗方面提供(如果有的话)很少的价值。

能够理解，基于所采集的各种数据，可以提供大量的治疗评估/推荐。例如，该治疗评估/推荐可以包括：患者是新诊断的I型糖尿病并需要治疗，或者招募该I型患者去进行闭环临床试验。在该给定的示例中，这些推荐具有0％的关联性，因为该患者既不是新的I型，也没有被招募进行闭环临床试验。于是在步骤105中呈现所生成的这些治疗评估/推荐作为输出，以供医疗专业人员选择。在所提供的示例中，医疗专业人员选择治疗评估/推荐(a)，即该患者治疗采集不好。治疗评估/推荐(b)和(c)在一定程度上对医疗专业人员有益，但是关联性评定表明，在所采集的数据中缺乏总体数据，并且总体数据对于产生新的治疗而言不够好。

接着，在选择所列出的评估/推荐之一之后，在步骤105中，然后还向医疗专业人员提供数据可用性状态以供选择。在该步骤中，系统还确定，对于所选择的评估/推荐(此处在这个示例中是治疗评估/推荐(a))，哪一种进一步的操作如果被采取则与处理/解决/改进所选治疗评估/推荐相关。在这一示例中，提供以下数据可用性状态以供选择：(i)采集数据以改善餐后葡萄糖控制(关联性80％)，(ii)采集数据以改善禁食期间的目标葡萄糖(关联性75％)，(iii)采集数据以获得总体初始治疗参数(关联性70％)，(iv)改变治疗时间安排(timing)(例如由于时区变化的原因)(关联性25％)，(v)改变治疗以调节增加的体力活动，改变状态(关联性15％)，(vi)改变治疗以调节交替的生理状态(关联性5％)，和(vii)识别用于闭环算法的参数(关联性0％)。在这一例子中，其它经验规则根据所采集的数据和所选择的评估/推荐确定：为了最佳地改善餐后葡萄糖控制以及为了有助于改变治疗，需要采集更多的这样的数据，并且这些数据与实现该目标最相关。然而，在这一例子中，医疗专业人员在决定从标准解决方案开始更好的情况下考虑并选择选项(iii)——采集数据以获得总体初始治疗参数。

根据各个选择，所采集的数据因而是不符合的，并且在步骤106中失败。例如，在这个特定实施例中，为了调整该患者治疗，需要利用餐前葡萄糖测量结果和餐后测量结果对HbA1C加权。然而，由于在所采集的数据中可获得很少的葡萄糖测量结果以供该算法有效使用，所以该所需数据的缺乏将导致在步骤106中数据质量失败。然后该向导运行步骤108，在该步骤处，系统通过另一组经验规则来识别需要被重新采集的数据，以给为了将患者治疗调整为所推荐的治疗计划或处方所需的初始治疗参数提供足够的数据。该处方可以针对以下事项的一个或多个：(a)bG测量的数量，(b)碳水化合物计数，(c)测量的时间安排；(d)在设备上通告(notification)；(e)训练推荐，(f)符合性满足标准，(g)下一次就诊时间——该方案可以规定一个日期或持续时间、以及(h)下一次就诊时的潜在入口点。在给定的例子中，步骤108中所提供的处方输出是：需要每天进行3次以上(3+)的bG餐前测量以满足符合性；所有摄入的碳水化合物计数都要存档记录；在设备上通告每个医生的主张；推荐碳水化合物计数帮助指导(或训练/更新类)；下次就诊是从当前就诊日起3周；以及入口点1应该是患者下次来就诊的时候。在步骤108后，在步骤110中，该向导可选地检验以获悉所识别的数据是否将被重新输入。如果是，则该向导对所识别的数据重复步骤102。如果否，则该向导在此时在入口点2处继续算法100。医疗专业人员的问题仍然是患者是否具有还未被解析的良好的治疗参数。但是，之前的采集步骤已经指示缺少必要的数据，并且已经向患者呈现了为了改善性能所需的数据采集要求，在步骤120中，在这个所示示例中，向用户呈现选项：(a)使用相同的参数继续，(b)使用历史数据，或(c)重新初始化数据以用于检查当前的治疗参数。能够理解，可以选择可选步骤105和110(一起或分别)以在软件的设置期间使用(这在该例子中发生)。

在步骤120中，关联性算法(relevancy algorithm)提供了每个选项在有益于解决患者是否具有良好的治疗参数的问题方面的相关性。在这个例子中，使用相同参数的选项(选项(a))是0％，因为之前的步骤已经指示该数据质量不好，并且指示使用历史数据(选项(b))和重新初始化数据(选项(c))的选项分别是60％和80％。为了提供每个选项的关联性，在一个实施例中，关联性算法在步骤120考虑以下信息：患者数据不足以重整理治疗参数；患者的历史数据可用；以及治疗初始化模型可用。该关联性算法估量出(weigh out)患者血糖控制以确定治疗参数以及还确定当患者首次被系统分析时患者如何利用治疗参数的初始估计。然而，由于系统对当前患者有时可能过于保守或激进，所以系统允许医疗专业人员在每一步使用他们自己的判断。在这一例子中，医疗专业人员在步骤120中选择选项(c)“重新初始化数据”，这导致模型的分析和指示在步骤122和124中是有效的。这些简单陈述的步骤意味着基于人群的参数是由医疗专业人员选择的，并且这缺省地表示医疗专业人员所同意的平均人群行为考虑了信息的当前状态。

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

表1-根据模型生成的治疗参数

基础速率	1.1U/h
		碳水化合物-胰岛素比	9gm/U
胰岛素敏感度	30mg/dL/U

在步骤142中，该向导现在对所确定的患者治疗执行验证分析，并向医疗专业人员提供最相关的选项，由此来审阅所确定的患者治疗并提供治疗安全准则。在该给定例子中，给医疗专业人员提供评价生活方式对该患者的慢性病管理的影响的选项。此外，关于治疗安全准则，基于所采集的数据和生活方式结果，在步骤142中向医疗专业人员通知患者具有x低血糖事件和y高血糖事件的可能，从而可以通过附加的后测量(post measurement)和纠正胰岛素来降低高血糖事件。在步骤142中，该系统还基于由所选择的模型生成的参数来推荐治疗。在这个例子中，所推荐的治疗提供：将基础速率设定为所期望的U/hr；将碳水化合物-胰岛素比设定为所期望的gm/U；将胰岛素敏感度设定为所期望的mg/dl；指示所需的bG测量结果数量；要求对摄入的所有膳食进行碳水化合物计数；以及指示需要至少x次每日餐前测量和至少y次餐后测量来改善治疗参数估计。此外，向用户建议：该患者应该在接下来的y周内完成治疗的数据采集并且之后到医疗专业人员那里就诊。在步骤144中，该系统询问医疗专业人员：所推荐的治疗是否有效。如果医疗专业人员希望改变所推荐的治疗的任何一个上述方面，则在步骤144中指示“否”，其使得医疗专业人员能够在步骤146中修改该治疗的一部分。在步骤146中进行所期望的改变之后，然后重复步骤140-144。否则，处理100通过在步骤160中将推荐治疗输出作为处方来完成该推荐治疗，这也是入口点4。能够理解，对于这个例子，当该患者再次到医疗专业人员那里就诊时，该向导会再次在入口点1处被使用并引导用户经过图4的算法100。

特定用例示例-示例B

在第二个用例示例中，主体的病历如下。该主体是与上述示例A中相同的糖尿病I型患者，其上一次来到医疗专业人员那里就诊是24天前。该主体是40岁男性，体重80kg(自上次就诊以来无变化)，并且当前正在使用快速作用的胰岛素(比如Lispro)(自上次就诊以来无变化)。该主体每天平均测量6次血糖(bG)(上次就诊时的次数是每天3次)。之前就诊的平均进餐量值是25g、85g、85g、以及25g，并且当前的进餐量值未知。该主体的碳水化合物-胰岛素比是8gm/U(无变化)，并且胰岛素敏感度是40mg/dL/U(无变化)。该主体的体力活动正常(无变化)。在该主体先前就诊时，他的HbA1C是9.5，并且现在是9.5。在这些事实模式下，医疗专业人员被指引去遵循用于典型的I型糖尿病的重点监测数据采集方案。

在这个例子中，完成步骤102之后，就已经采集了以下数据：I型患者；就诊原因是完成重点监测；当前的A1C＝9.5；上一次的A1C＝9.5；当前的进餐信息(平均值35g±5、70g±15、85g±20和25g±15)；由于缺少数据，上次的膳食信息未知，bG平均值和SD是135±50；整夜禁食是130±30mg/dL；对照所需要的方案来处理数据；并且在该方案的界限内完成对所采集的数据的统计。在步骤104中执行了对于所采集的数据的完整性和质量的检验后，在步骤105中所提供(例如显示)的一系列推荐及其关联性评定如下：(a)患者需要定期的治疗调整(关联性90％)，(b)患者治疗不好、例如A1C较差，患者感觉不好，读数指示大的葡萄糖值，许多高血糖事件(关联性95％)，(c)患者被新诊断为I型糖尿病并且需要治疗(关联性0％)，(d)I型患者已经被招募进行闭环临床试验(关联性0％)，和(f)患者生活方式改变，例如移动到新的时区、增加体力活动等(关联性65％)。

根据上述显示的推荐，医疗专业人员获悉推荐(a)和(b)是最相关的，其中推荐(b)“患者治疗不好”具有最高的关联性。在这个例子中，医疗专业人员在步骤105中选择推荐(b)。接着，在步骤105中向医疗专业人员提供(例如显示)以下关于数据可用性状态和相关联的关联性的可选选项：(i)采集数据以改善餐后葡萄糖控制(关联性15％)，(ii)采集数据以改善禁食期间的目标葡萄糖(关联性10％)，(iii)采集数据以获得总体初始治疗参数(关联性10％)，(i v)重整理患者参数并确定治疗参数(关联性95％)，(v)改变治疗时间安排，例如诸如由于时区变化的原因(关联性25％)，(vi)改变治疗以调节增加的体力活动(关联性0％)，(vii)改变治疗以调节交替的生理状态(关联性0％)，和(viii)识别用于闭环算法的参数(关联性0％)。在这一步骤中，医疗专业人员选择选项(iv)重整理患者参数并确定治疗参数作为相关的操作过程。清楚的是，过去的就诊初始化显示血糖控制不好。尽管患者正在完成获得测量结果和对碳水化合物计数的认真的任务，但是餐前指示膳食控制和/或禁食控制不好。相对于之前的就诊(其中提供了基于人群的参数)，需要进行特定于患者的调整。由于按照基准(baseline)的数据采集因而是符合的，并因而在步骤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测量仪。这里，关联性示出了需要整体治疗。膳食是对于患者的主要外因干扰。在这一点上，锻炼或其它应激源作为次要因素估量，并且可以在未来对于治疗参数的调整中变得相关。

最后，在步骤120中，该向导呈现类型膳食模型以供选择：(a)快速(以碳水化合物为主)；(b)中等(标定的)；(c)慢速(高脂肪含量)，和(d)混合的(相应采集的数据将具有该信息)。医疗专业人员选择第二个膳食模型选项(b)、即中等或标定膳食模型。这里，数据不够充足或存档得不足够好以至于不能适合(do)选项(d)下的混合情况，并且该患者的数据已经指示基准标定(baseline nominal)模型。可以利用更具体的信息来捕获特定的膳食习惯。该膳食模型部分可以是或包括更具体的处理，并且在任何情况下都会导致选择如下的潜在数学模型，所述数学模型可以是标准的或者通过允许医疗专业人员选择或定义可替换的生理模型而被普遍化(generalize)。上面的例子仅仅示出了在步骤120中处理模型选择的一种方式。

在模型选择之后，在步骤122中，处理100对模型进行验证和分析。对于这个步骤，通过基于计算机的仿真在系统10上在计算机里(in silico)仿真特定于患者的用例场景。实际上，对所选择的患者模型的理解可以是，每次确定一个数学模型时，应当对其进行测试以检查其逼真度。步骤122确保：自从测试已被配置为个体主体的特定测试用例以来，存在嵌入到系统10中的检验和平衡，其中然后将所得到的数据与已知标准或更广人群的数据进行比较。根据特定的所选患者模型，步骤122需要以下至少一个步骤：在指定的工作范围内在计算机里验证模型以了解工作空间，以及了解该模型的限制；提供基于该模型的给定假设的错误的合理思想；应用其它测试模块、比如测试膳食、测试胰岛素剂量等；采用已被采集的临床数据(比如胰岛素输入信息和事件输入信息)测试该模型；和应用特定的模型特性(例如指定的谱(profiles)、参数值范围或度量)。任何不正常或奇怪的方面都被标记并呈现给医疗专业人员以进行操作。

在给定的示例中，患者模型拟合被完成，其具有拟合质量＝85％，即该模型和该组参数将解释该模型特性的85％，其是被观察特性(bG测量结果和进餐量)的加权结果。在其它实施例中，可以得到所述参数的置信区间。并且在这个例子中，完成模拟的患者模型响应以核实该模型的生理特性(核实)。这也被称为患者模型表征，其包括：对该模型进行标准测试以得到预先确定的信号以检查所获得的特性；然后将其与所观察的患者特性的一个或多个预期范围相比较。这里的一个目标是保持在可接受的患者特性的指定边界内。在其它实施例中还可以实现该模型复制结果(预测的质量)的能力。这是一个可选的特征，并且可以在复制数据集可用时加以实施。该能力的测量例如可以是归一化最小二乘拟合。

在步骤122中完成对所选模型的分析之后，在步骤124中，执行对于该模型是否有效的确定。在步骤124中，医疗专业人员基于包括以下事项中的至少之一的结果来审查和预期该模型的接受，所述事项为关于参数的置信区间、拟合数据的能力、为基于生理的参数的估计提供置信区间等等。可以为每个参数计算置信区间。这些置信区间基本上确定了置信度，其中采用该置信度计算了这些参数。由于该模型是针对特定方案选择的，因此不希望有过宽的置信区间。但是如果它们太宽这种情况发生的话，则可以得出下述结论，即对于该特定患者和该特定的膳食，利用这种方法没有改善的可能。而且，可以使用经典标准(比如预测与测量结果之间的方差)来检验拟合的优度。如果拟合优度不好，则不应使用所计算的参数来改善膳食控制。如果该模型不能进行较好的验证工作，则可以重新进行这一步骤。此外，人们可能希望与另外一个或多个模型比较以确定是否存在提供更好结果的可替换的一个或多个模型。作为在步骤122中对所选模型执行验证分析(即识别患者参数)的结果，医疗专业人员在步骤124中确定该模型有效。这时，向导在入口点3处继续进行算法100。

在医疗专业人员认可该模型之后，向导将医疗专业人员带入到治疗分析/确定的最后阶段中。在步骤140中，该处理执行在计算机里的仿真以质询(challenge)临界情况的治疗鲁棒性，并且通过考虑监测时间表和故障保护来评估该解决方案的稳定性，确定该治疗对参数变化的灵敏度，通过执行大量仿真来生成置信区间，以及确定各个疗法的有效性(功效，效力，亲和力)以确定所推荐的治疗建议(包括该治疗的安全性和耐受性)。

例如，在步骤140中，在给定示例中，处理100提取/识别患者的生活方式数据，并且基于这些数据为治疗结果提供(一个或多个)置信区间。这里，患者生活方式与测试和评价治疗相关。现在通过具有生活方式选项的向导来给医疗专业人员呈现所采集的信息和识别的模型以审查治疗结果。这里，一个目标是提供治疗安全性准则。在步骤140中可以向医护人员提供以下疗法计算选项：(a)确定用于所指定的算法A(例如CSII)和所指定的生活方式的治疗参数；(b)确定用于所指定的算法B(例如ICT)和所遵守(observed)的生活方式的治疗参数；(c)建议高性能的治疗(CSII+经常测量+生活方式)；和(d)评价具有较差符合性50％对90％符合的生活方式影响(95％)。在步骤140中，由于患者在较早的就诊中是不符合的，所以医疗专业人员选择第一个选项(a)。可选地，医疗专业人员可以实施的另一实践是也选择第四个选项(d)。

这里，使用所遵守的生活方式而略过不符合的情况(即患者没有遵守治疗规则和/或不符合测量结果和碳水化合物计数)，在步骤142中执行随机仿真，并且生成关于潜在结果的比较报告。该报告可以包括：患者具有x低血糖事件和/或y高血糖事件的可能；下次就诊时(例如从现在起3个月)预期的HbA1C；高和低的bG测量结果；由于管理不当的糖尿病治疗而导致的可能的时间损失和不适天数。此外，关于该治疗的推荐可以是：患者测量生活方式应该是至少x次测量；可以通过额外的后测量和纠正胰岛素来降低高血糖事件；患者应该继续进行餐前和餐后测量；以及当患者改变了饮食习惯时，采集和记录关于特定膳食类型的数据，从而使得可以改善进一步的治疗。此外，为了该仿真的目的，还可以以符合率的方式给出符合性，其中该符合率等于事件被确切记录的次数除以事件应被记录的次数。

例如，患者具有103次早餐前测量的记录，并且做出这些测量的时间段是120天。因而该早餐的符合率是103/120或0.86。于是，例如，在这种情况下，满足了所需的早餐禁食符合性0.8或更佳的符合性。医疗专业人员在步骤144中审查该报告和疗法，并且如果没有变化，则认为它有效。现在处理100在入口点4输出160中的该报告和治疗推荐作为处方，并且以电子方式更新该患者的记录。下文中参考图2-9提供根据本发明的特定系统实施方式及其使用。下面讨论本发明的系统和处理如何响应于事件。

通过事件调用软件响应

如前所述，事件是由一个构件生成的可以被该系统的另一构件使用的信息单元。事件单元所固有的是该事件的时间、事件表征描述符(descriptor)、事件操作计划、以及事件值。下面提供进一步的细节。系统中事件的激活与给构成该事件的元素指定值有关。在一个实施例中事件可以是：(i)信息输入(entry)，(ii)活动信息，(iii)要求设备做一些事情，(iv)通知患者完成任务，(v)通知患者可能的生理状态等等。在一个实施例中，事件的结构具有以下字段：绝对事件时间；事件类型；事件的持续时间/操作时间/活动时间；相对于本源(parent)该事件的开始时间；事件的量(强度)；和报告字符串(advisory string)。绝对事件时间提供了事件应该发生的时间，并且具有以下值：预先定确的、由算法确定的、或异步触发的。事件的时间作为通常充当绝对参考的绝对时间而被提供。在特殊情况下，该绝对事件时间被链接到另一事件的绝对时间。绝对UTC时间被用作与该事件相关联的“参考时间”。该参考时间是关联其它事件所必需的。并且，考虑到多个时区和夏时制(day light saving)，唯一的时间确定并非不重要。本地时间和协调世界时(UTC)之间的区别是相对的。本地时间用于显示目的，并且UTC被映射到本地时间。

事件类型描述什么事件已被激发，并且其所具有的值例如是：进餐、锻炼、用药、胰岛素测量、改变状态、纠正事件、以及取消事件。持续时间定义了实施活动(例如胰岛素推注活动、进餐活动、锻炼活动持续时间和改变状态)的长度。被启动的任何活动都应当用持续时间来限定。缺省地，活动具有无限的持续时间。另一个缺省的可能是该活动没有持续时间。这意味着它的影响是瞬间的。从0到无穷的非零值捕获了所有的中间情况。相对时间是相对于绝对参考时间的，该事件在相对于该相对时间而调节的绝对时间处被启动。对于在等于绝对事件时间加上相对时间的时间处被激活的、与进餐相关的推注而言，这可以是相对于进餐事件的测量或者相对于上次bG测量的测量。量描述了该事件的强度或大小，并且可以是胰岛素的量、进餐量和进餐速度。最后，报告字符串是信息的简洁而叙述性的部分。在一个实施例中，该字段以XML或RTF或其它标记语言来输出，以呈现针对终端用户和数据库记录而被特别调整的更详细且描述性的信息。一般地，该报告字符串是关于过去、现在和将来的任务的正在进行的活动的注释。在该字段中使用标记语言的应用增强了向用户提供所有可能的交互工具(比如音频、可视图形、静态和动态链接)的整体能力。动态链接可以包括进度条、柱形图等。例如，进行活动的时间可以被表示为进度条，所给予的胰岛素距离将要给予的量可以被示为进度条等等。

注意，在以上述方式表征事件输入时，可以提供系统中的以下应用(utility)：命令用药配给单元(胰岛素泵)以给定的输入特性来配给药物(胰岛素)；命令测量单元以给定的输入特性来执行测量任务；从患者那里接收关于即将发生的事件活动输入特性的指令集；和向算法模块(即系统的包含血糖控制算法的软件构件)呈现事件输入和/或产生输出事件。该血糖控制算法被用于基于所采集的皮下传感器数据、主体的预定基础谱和用户输入来做出胰岛素推荐以将该主体的葡萄糖水平保持在目标范围内。向(i)设备(ii)算法和(iii)用户呈现特定于方案的时间表以执行任务/事件。存储特性输入和从该数据库中检索特性输入。使用本发明的系统和软件如何工作的示例来进一步解释上述每个应用。

命令药物配给单元以给定的输入特性来配给药物

在这个实施例中，患者数据测量/采集设备48(图2)是药物运送单元(比如可编程胰岛素泵)，其关于系统的所推荐的疗法自动运行，其中所述疗法由医疗专业人员在步骤160(图4)的末尾确定为处方并通过客户端计算机14而被上传。事件自身以下述多种方式中的一种生成，所述多种方式为：(i)算法，(ii)用户，(iii)看门狗(watch-dog)(第三方工具)，(iv)故障保护，(v)数据库触发的事件，和(vi)基于方案。特性曾需要惟一地并且将需要覆盖下次通信可以发生之前的已知或未知的时间长度。用药定时是糖尿病治疗的中心(所有事件定时优选地被保持在具有针对本地时间的适当调节的UTC时间内)。事件类型解释了该事件的环境和/或描述了所触发的事件(例如餐前推注(meal bolus)、所命令的推注、餐前推注谱)。任何被启动的活动一般都被有限的持续时间限定。该持续时间被认为是覆盖了发生的事件的实际持续时间(比如配给所命令的推注物理地花费了有限的时间来运送)，并且该持续时间可以与算法相关联以考虑何时决定下一个推注命令，或者可以捕获胰岛素的持续时间以作为该患者体内的胰岛素活动的持续时间。相对时间允许该事件相对于参考点被错开(stagger)。例如，如果该参考时间是进餐时间，那么就利用相对时间例如通过指定几分钟的负时间(negative time)来进行餐前给药。该数字的序列还将单次给药计划扩展到关于进餐时间的给药分布序列。量(amount)可以指出活动的强度或者其表示数量(quantity)/量。例如，在该特定情况下是待配给的胰岛素量。与持续时间类似，它也可以是数列。该序列中的元素数通常将与相对时间中的元素数匹配。报告字符串以(i)图形(ii)音频格式来呈现信息。此外，该信息如果被存储，则呈现该活动的记录(log)。

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

需要测量以用于人工控制或用于自动反馈控制以获得良好的性能。然后，根据功能性的观点，测量被归纳为另一事件单元。当然，测量具有需要考虑的事项，例如相关成本、在现实意义上能够进行多少测量的限制，如何使用测量来规定(dictate)测量序列，测量还可以与用于完成任务的方案相关，需要测量以改善性能，测量报告(advisory)通过如下方式增加了值，所述方式为：利用理想测量时间、测量和保持安全性的最佳最小时间来帮助用户、医疗专业人员(HCP)(例如医师、RN、LPN或护理人员/EMT)、应急支援小组。各种可能性都被上述的事件特性覆盖并且被重新提出以用于bG测量。测量的定时对提供好的治疗是很重要的。在执行测量时，优选地以UTC捕获测量结果并将测量结果提交到算法和/或数据库。此外，测量报告以本地时间呈现。例如，在一个实施例中，患者数据测量/采集设备48被如上所述地编程，从而以绝对期限(term)告诉患者：根据该系统输出的处方，应该何时以本地时间进行测量。对于该应用，事件类型解释了事件的环境和/或描述了被触发的事件。例如，bG现场(spot)测量表示用于测量的bG测量仪，血液抽取将表示用于分析例如获得bG测量结果、胰岛素血浆浓度或A1C测量结果的血样。所启动的任何活动一般都被持续时间限定。该持续时间被理解为覆盖了发生的事件的实际持续时间(例如测量物理地花费了有限的时间来确定葡萄糖浓度)，并且该持续时间可以与算法相关以考虑例如在连续测量中可以有小到30mts延迟那么多的测量延迟。存在持续时间可能没有意义的情况，并且在这种情况下，该项被留为空白。可以使测量的相对时间覆盖许多用例情形，并且测量的相对时间可以是基于环境的。该相对时间可以充当倒计时或进行测量前所剩余的时间。它可以表示距离上次测量的时间推移。它可以表示自所期望的测量时间以来的时间。它可以表示用于基于方案或基于事件的测量要求的一系列测量时间，其可以由在特定时间段的一系列测量组成。量可以指出活动的强度或其表示数量(quantity)。例如，在该特定的情况下，该量表示测量值。如果设备48配备bG测量单元，则该设备可以显示该测量，并且如果测量时间被指定并且测量还没发生，那么可以很容易地提供用于管理未来项和/或丢失项的逻辑。最后，报告字符串可以同时以图形和音频格式呈现信息。此外，所有信息现在都被存储为该活动的记录。

从患者那里接收关于即将发生的事件活动输入特性的指令集

一般地，需要对事件进行表征以获得更好的性能。目前，膳食(例如只有碳水化合物计数)被利用。在这种情况下，该事件的量字段捕获该膳食的净强度(net strength)。然而，没有处理(address)更完整的特征(例如它的速度或血糖指数)。该事件的持续时间字段可用于捕获进餐速度方面之一。进餐事件还可以被描述为快速、中等或慢速以再次捕获进餐的速度。另一个例子是锻炼，其中，强度和持续时间可以帮助捕获活动水平。这些和其它例子可以被处理100的算法使用以微调：在提供推荐的治疗的过程中应当如何调节背景胰岛素。在锻炼情况下的相对时间字段允许预编程一个事件，该事件可以被处理100的算法使用以预先微调胰岛素从而与即将发生的事件相配。这对于增强治疗效果非常有益，因为存在系统和响应延迟。

需要对摄入膳食、体力活动(比如锻炼)或处于交替状态(比如压力)的定时以进行治疗调节。该活动的识别可以是人工的，并且在这种情况下，通过人工输入来触发事件。所有事件定时优选地被保持在具有针对本地时间的适当调节的UTC时间内。事件类型解释了该事件的环境和/或描述了被触发的事件。例如，可以将膳食描述为高或低血糖指数，它可以由成分(比如脂肪、蛋白质、碳水化合物、纤维素)，或者由描述符(例如快速、中等或慢速进餐)来表征。任何被启动的活动一般都被有限持续时间限定。该持续时间被理解为覆盖了被触发事件的实际持续时间。例如，已知进餐活动的持续时间与慢速吸收的膳食相关。已知该持续时间有助于确定胰岛素分配。类似地，其它表征选择的事件增强了所预期的生理负荷的知识，它被算法使用以解决治疗需求。

相对时间字段允许该事件被相对于参考点错开。在临床研究中，清楚的是：预先的知识能够进一步增强控制器的性能。基于该预期操作胰岛素的胰岛素治疗可以被削减或预给药(pre-dosed)。一般地，对于预期的锻炼，基础胰岛素被削减，并且此外，该算法将产生碳水化合物摄入事件，从而将葡萄糖保持在正常血糖范围内。在快速吸收膳食中，预给药还帮助抑制快速上升的葡萄糖。量字段可以指出活动的强度或数量/量(quantity/amount)。例如，在剧烈锻炼的情况下，将指锻炼事件的强度，并且在进餐情况下，其可以通过碳水化合物的量来描述。与持续时间类似，它也可以是数列。该序列中的元素数将通常与相对时间中的元素数相匹配。报告字符串以(i)图形(ii)音频格式来呈现信息。在锻炼的例子中的报告字符串是对患者的如下建议：消耗快速作用的碳水化合物，从而补充体力负荷以及进而对于碳水化合物的需求。此外，上述事件的信息如果被存储，则呈现该活动的记录。

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

算法是一组用于确定操作或结果的指令。该算法是事件的接收者，它是内部事件的生成器，并且它是外部(输出)事件的制造器。该算法本身被模块化构造以便允许通过结构化方式来处理复杂问题。该结构致力于将问题分解为专用于给定任务中的功能单元。根据问题的需求，该模块性还允许包括或排除影响。最后的性态(behavior)通过附加的试探法(heuristics)被过滤(filtered)。所以在更高的层次上，每个模块都可以被看作是效果的叠加。但是在每个模块如何处理(handles)的核心处是不受限制的。因此高层次模块化功能如下：管理和内务处理(housekeeping)；监测和状态信息；处理主要事件；核心控制操作(提供血糖控制的关键)；和纠正操作。

管理和内务处理

管理和内务处理模块如下：初始化/准备；处理丢失的循环；事件映射；胰岛素储存桶(buckets)；分量无效(component nullification)；数据库；和执行方案。初始化/准备是管理过去、现在和将来信息的状态向量。处理丢失的循环处理所述处理100的重启或因为任何原因而被跳过的算法调用以作为故障保护。事件映射将外部事件集映射到内部事件集。胰岛素储存桶管理来自各个模块的胰岛素推荐作为分量以填满和倒空储存桶。分量无效被解释如下。一般地，当一个解决方案作为当前的解决方案时，其中尽管生理机能输入和输出是各个分量当(i)作为单独的分量或(ii)归类的模块化效应而解决问题时的净效应，该无效步骤允许在所述单独的分量或归类的模块化效应的考虑期间去除不需要的效应。因此，例如，胰岛素无效从最终胰岛素运送中取消来自控制操作的前馈项的任何胰岛素分量。内部推注管理运送由进餐事件引起的前馈推注(feed-forwardboluses)。内部推注管理允许(i)产生内部事件和(ii)归类内部事件。从而普及对治疗元素的管理并且对治疗元素的管理允许如下灵活性：根据改变的需求和新信息的可用性来增加或去除影响。数据库提供了对数据的检索和存储以及记录信息。执行方案是按照通用事件结构设计的方案格式，以允许动态生成如医疗提供者所希望的方案活动。方案的一个方面是支持符合性，以用于生成用于分析和生成特定于患者的信息的最小信息。

监测和状态信息

用于监测和通知状态的模块如下：葡萄糖更新、过期的(outdated)葡萄糖、自推注(self-bolus)、进餐报告、方案报告、故障保护、以及主要事件处理器(handler)。葡萄糖更新跟踪与符合性和测量需求相关的新的葡萄糖测量值的可用性，并且为用户生成信息。过期的葡萄糖通知用户是否需要新的葡萄糖值，其也与符合性和测量需求相关。也为用户生成信息。自推注借助于自推注命令(内部活动)来解决(account for)任何胰岛素差异。进餐报告通知用户开始吃东西。符合性问题覆盖了碳水化合物摄取，并且可以扩展到其它监测和通知。方案报告通过生成内部事件来通知用户即将发生的或迫近的活动。故障保护系统地通知响应者(例如患者或看门狗服务)用户正在关闭设备或系统，并且产生警报创建时间窗，在该时间窗中如果该设备和/或系统未终结(up)或者没有进行调用以忽略该警报，则提供一个用于提供援助的紧急调度或替代形式以用于帮助。主要事件处理器是用于处理主要事件(比如准备锻炼、锻炼、命令的推注和进餐补偿器)的模块。准备锻炼以锻炼控制器的预期来修改基础需求，并在特定的锻炼开始时通知控制器。锻炼在该锻炼持续时间内保持升高的葡萄糖设定点，并且然后返回到其葡萄糖设定点。命令的推注是对于额外的胰岛素推注的要求(用户控制)，并允许异步的命令。进餐补偿器向控制器通知碳水化合物的摄入。交替状态/触发事件覆盖交替状态和触发事件。

核心控制操作

核心控制操作模块形成对于提供血糖控制很重要的核心控制操作，该模块如下：过程传感器数据、胰岛素设定点、葡萄糖预测、胰岛素推荐模块、锻炼补偿器、快速作用的碳水化合物摄入、进餐补偿器、模型选择、模型参数确定/更新、患者表征、管理差异、最终运送的胰岛素、以及最终推荐的胰岛素。过程传感器数据根据可用的所测量的葡萄糖值确定葡萄糖值，该所测量的葡萄糖值例如是通过传感器单元获得的间质液值(isf)值和/或通过外部测量仪获得的血糖(bG)值。胰岛素设定点是用于保持目标基础葡萄糖(即针对给定的基础胰岛素速率所获得的葡萄糖值)的胰岛素输注速率。葡萄糖预测利用过去的葡萄糖测量值、过去的胰岛素测量结果、过去的事件和将来计划的事件来预测用于控制循环的葡萄糖值。丢失的循环是每当控制循环期间没有调用算法时。要注意的是，葡萄糖可以是测量的葡萄糖或预测的葡萄糖，由其被讨论的环境来决定。测量的葡萄糖是从葡萄糖传感器获得的葡萄糖值。预测的葡萄糖是使用模型根据已知的葡萄糖值确定的将来的葡萄糖值。治疗目标葡萄糖是用户希望达到的葡萄糖值。目标葡萄糖/葡萄糖设定点是控制器试图通过反馈来渐进地实现的葡萄糖值。基础控制操作计算用于维持基本葡萄糖的胰岛素剂量。该确定是基于模型和或规则集的。

锻炼补偿器处理增加的体力活动水平。该确定是基于模型和或规则集的。快速作用的碳水化合物摄入处理快速作用的碳水化合物的摄入以补偿预期的葡萄糖降低。该确定是基于模型和或规则集的。进餐补偿器计算针对进餐事件的胰岛素推注分配。该确定是基于模型和或规则集的。开环基础实施方式在开环控制器期间实施基础胰岛素。该确定是基于规则集的。模型选择是对最好地解决患者需求的合适模型的确定、比如上面关于图4所述的处理100的部分。该规则基于生活方式选择、所使用的过去事件、将来的事件和方案和/或简单地基于医疗专业人员的选择。模型参数确定/更新确定所选择的模型的参数。该确定使用先验数据、设备所采集的数据、参数确定设定。患者表征是在特定于患者的参数的选择或使用基于人群的模型被评价时。所确定的模型和参数经过多次检验，并且如果结果满足并且维持某个已知的预期，那么就选择所述确定的参数，否则，利用次优的这样的基于人群的参数集以用于治疗确定、控制葡萄糖。治疗参数确定/更新还如前面关于图4的处理100所述。管理差异在识别出所命令的胰岛素对(versus)所运送的胰岛素之间的差异时管理胰岛素储存桶。最终运送的胰岛素是针对循环所配给的胰岛素量。最终推荐的胰岛素是由算法计算出并传送给医疗专业人员作为推荐的胰岛素剂量。

纠正操作

纠正操作是可用于采取如下纠正操作的模块：碳水化合物校正、高葡萄糖干预、低葡萄糖干预、以及进餐葡萄糖区。碳水化合物校正修改之前输入的进餐事件(碳水化合物值)，并因而校正胰岛素给药。高葡萄糖干预借助于胰岛素给药来纠正高葡萄糖水平。低葡萄糖干预借助于摄入快速作用的碳水化合物来纠正低葡萄糖水平。进餐葡萄糖区将葡萄糖目标定义为带(band)而不是线。在其它实施例中，可以使用其它适当的纠正操作。

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

方案是一系列事件的所计划的执行。对计划的遵守允许(i)改善治疗(ii)能够使用所采集的数据进行特定分析并确定医学操作或者(iii)通用的用例，其中计划生活方式例如饮食计划、锻炼计划、进餐定时、膳食组成。这与仅仅用数据(而数据是利用正确的定时来采集的)和相关联事件(例如具有特定脂肪、蛋白质和碳水化合物成分的膳食)来支持医疗提供者相关。然后，方案是事件单元的特定序列，其中所述事件单元包括bG测量、推注命令、食物摄入和锻炼。事件可以在许多模式(比如手持设备被编程、患者遵守的基于简单纸张的描述，自动服务(例如帮助患者的顺应性顾问))下被触发。

存储特性输入和从数据库中检索特性输入

数据库是中央信息存储单元。数据库用于存储和检索事件和特定于用户的设定。所存储的事件覆盖过去、现在和计划的将来事件。按照存储事件信息以作为正在发生的当前和过去的活动的记录来使用数据库，该数据库被用于检索过去和将来的事件，并且其用于触发计划的事件。下文中提供上述系统、处理和软件模块的特定实施方式以进一步推进对于本发明的理解。

特定实施例

在以下阐明的实施例中统一了上述设备和方法，其增强了医疗提供者进行采集、分析和确定用于解决慢性病(比如糖尿病)的疗法的能力。在应用DTPS方法的第一示例性实施例中，公开了一种自动胰腺测试台(APTS)程序。APTS是用于以临床设定来控制糖尿病主体的软件程序。在也应用DTPS方法的第二示例性实施中，公开了一种自动胰腺-控制算法测试包(APCATS900)程序。APCATS 900是在例如客户端计算机14(图2)上正在运行的仿真环境中分析糖尿病主体的软件程序。参考图5，首先对APTS程序进行论述，随后，在之后的章节中将对APCATS 900程序进行论述。

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

参照图5，APTS程序500在常规计算机(例如膝上型计算机、个人数字助理(PDA)、智能电话等)上运行并提供两个独立的软件构件：自动胰腺软件(APS)502和自动胰腺软件通信应用(APSCOM)504。如在随后章节中所要解释的，APS 502进行周期性调用所包含的算法命令解释程序(shell)(ALGOSHELL)506以获得胰岛素推荐，并与APSCOM 504交互。在下文随后的章节中将提供对于ALGOSHELL 506的论述。APSCOM 504用于从便携式单元(PU)508采集信息、与APS 502交互并存储以及从数据库(例如数据库24(图2))中检索信息。在一个实施例中，PU 508是设备48(图2)，而在另一实施例中是测量葡萄糖浓度的传感器(比如例如皮下连续葡萄糖监视器(SCGM)，其是由Roche Diagnostics Corporation开发的、用于进行频繁葡萄糖测量的、基于微透析的设备。在又一实施例中，便携式单元508是胰岛素泵或胰岛素泵系统(诸如例如Roche Diagnostics’Accu-

Spirit胰岛素泵系统)。在该胰岛素泵系统实施例中，APSCOM 504可以与配备有胰岛素泵系统的PDA上所提供的软件通信，或者如果在同一个PDA上运行APTS，则与胰岛素泵控制软件通信。

还提供一个称为ALGO 510的控制器模块，其确定胰岛素给药计划，并且通过ALGOSHELL 506将药剂传递给APS 502。这里通过图示，它表示时间和值对。该ALGOSHELL 506执行一些标准系统功能、比如状态管理、ALGO调用筛选(screening)、单位转换和确定配给量。APS 502负责以这里被称为控制循环的周期性时间间隔调用ALGOSHELL 506。APS 502还周期性地与APSCOM 504交互。在一个实施例中，APSCOM 504使用COM技术与程序(例如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并获得新的传感器数据集和针对被配给的净胰岛素的数据。现在将关于控制沿(edge)的时间设定为零，并且在事件序列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之后，该推荐窗口返回到APS 502以进行事件序列E。如果用户确认了该推荐，从而完成了事件序列E，则对于事件序列F，APS 502在用户界面512中打开确认窗口516，并等待用户通过使用输入设备(例如设备40)接受或取消该确认。APS 502将等待输入直到确认窗口超时。在完成事件序列F之后，对于事件序列G，该确认窗口返回到APS 502。然后，对于事件序列H，APS 502调用ALGOSHELL 506，其中药剂量是(a)由用户确认的(b)由用户归零的(c)或在超时情况下满足阈值要求的量或者0。该第二个ALGO调用被称为SYNC-2调用。要注意，该阈值要求是被运送到主体的经过协商的所推荐的胰岛素剂量，除非它被医疗专业人员拒绝。在完成事件序列H之后，ALGOSHELL 506将最终命令的量返回给APS 502以进行事件序列I，并且然后APS 502向APSCOM 504发出推注命令以进行事件序列J。这就结束了控制循环周期。

ALGO

这一部分进一步阐明ALGO 510的关键工作。以可靠和适时的方式提供药剂对于治疗而言是很关键的。在以下部分中，提出ALGO 510的以下方面：时间方面——基于索引(index)的ALGO 510如何确定消逝的实际时间(realtime)；存储持续时间——确定新推荐所需要的过去历史(系统存储)的长度；丢失的循环——ALGO 510如何处理丢失的调用；工作模式；以及对在ALGO 510中所提供的经验算法模块(EA)518的调用。该EA 518是一批用于推荐胰岛素剂量的基于规则的强化治疗策略，其调用和/或提供多个功能模块56(图3)。胰岛素剂量推荐基于最近的葡萄糖信息和事件信息、比如进餐、锻炼、干预等。强化治疗是用于胰岛素依赖型糖尿病的一种治疗形式，其中主要目的是将血糖水平保持得尽可能靠近正常范围。治疗包括一天三次或更多次胰岛素注射或使用胰岛素泵；一天四次或更多次血糖测试；基于血糖测试结果的胰岛素调节、食物摄入和活动水平；饮食顾问服务；和通过糖尿病团队管理。EA 518通过以频繁的规则间隔连续监测葡萄糖和实施强化治疗规则来扩展该原理。使用最近的葡萄糖测量、过去的胰岛素给药信息和事件信息(比如进餐、锻炼、干预等)来评估胰岛素剂量推荐。在一个实施例中，通过提供允许利用经过校正的经验算法替代/更新已有的EA 518的开放架构，来便利地进行对EA 518的所述更新。在代理案号为ROP0015PA/37554.21/WP24356US、名称为SYSTEM AND METHOD TO PROVIDE ANOPEN ARCHITECTURE FOR SEMI-OR FULLY-CLOSED LOOP THERAPY DELIVERYSYSTEMS的共同待审的美国申请第____号中描述了可在本发明中实施的一种这样的合适的开放架构方法，该申请被转让给本申请的受让人，并且其公开内容在这里通过引用结合于此。

如本文在定义EA 518的部分和APTS 500的其它模块时所使用的那样，表2中所列出的符号具有以下命名。

表2——命名

定时方面

如所述，APTS是实时系统，其中定时(timing)是剂量给药的关键方面。EA 518使用不依赖于实时的、确定适当的控制量的数字补偿器。EA 518被构造为使得其不具有真实的时间感(sense of time)，而是用存在于变量数组的索引中的定时。换句话说，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中。临界是指所实现的实时控制系统具有软时间(soft time)控制。这意味着对ALGO 510的调用并不精确地在控制循环周期T_C的开始沿处，而是在该开始时间t_s的控制沿附近的某时间精度内。T_A项是距离控制沿的时间偏移，并且是数据请求被发送和被APS502获得的时刻。例如，一个值可以表示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^l}{T_c}\right),---\left(4\right),$

其中n是信息被保持的循环数。为了覆盖丢失的循环的情况，还需要若干额外的控制循环作为缓冲。在这种情况下，n_H被定义为n与预期丢失循环的最大数量的总和。管理ALGO 510所必需(和足够)的范围将在n_H个循环中保持历史。

丢失的循环

ALGO 510负责处理所有新信息输入和用于将该信息转化为疗法。丢失的循环是该控制循环周期，其中ALGO 510未被调用。如果整个APTS 500是完美的，则ALGO 510将在每个控制循环周期T_C被调用。然而，调用会被丢失。如果循环丢失，那么针对每个丢失的循环迭代执行ALGO 510。这意味着，当发生丢失的循环时，治疗被挂起(pending)，直到ALGO 510被调用。ALGO 510在执行当前的调用之前，通过每个丢失的循环检测丢失的调用和步骤。这保证了该事件既未丢失也未被复制，而是被顺序地处理。丢失的循环可以由于各种原因而发生。只要被传送到ALGO 510的信息没有差异，同步就是准确的。在处理这种情形时，ALGO 510首先确定是否丢失调用。如果发现没有丢失的调用，则ALGO 510执行各个EA 518模块。当ALGO 510检测到丢失的调用时，ALGO 510在评价当前的调用之前首先执行所有丢失的调用。

工作模式

ALGO 510所支持的工作模式是Pure-control(纯控制)和Controlled-Obs(控制的Obs)。参考图6，EA 518的工作的Pure-control模式600是使用葡萄糖测量来提供适当的控制操作的闭环系统。ALGO 510的任务是将葡萄糖保持在预先确定的目标葡萄糖水平601。在控制器初始化期间或每当主体被干扰时，预期葡萄糖偏离目标葡萄糖水平601。Pure-control使用葡萄糖测量和所运送的胰岛素信息来“认识”该主体的状态。在图6的右下方，主体方框602被连接到葡萄糖传感器604和胰岛素泵606。这些设备通过用虚线所示的便携式单元502(图5)的RF链接608与APS 502保持间接联系。从事件框612发出的虚线610指示已知事件的发生。这些事件的信息对ALGO 510可用。事件处理器614提供外部事件描述与内部事件模式之间的适当映射。ALGO 510触发适当的模块以处理已知的干扰，其包括命令胰岛素模块616、高葡萄糖干预模块618、进餐补偿器模块620、锻炼补偿器622或低葡萄糖补偿器模块624中的至少一个。葡萄糖预测器626和基础控制器628处理未知的干扰和建模误差。该控制器的初始化是未知干扰的情况。控制器必须在实验开始时和模式从Controlled-Obs模式700切换到Pure-control模式600时稳定初始的葡萄糖值。在这些情况下，该Pure-control模式600的性能依赖于来自过去事件的信息的可用性，以将该主体从一些初始的葡萄糖值平稳地改变为目标葡萄糖值。闭环存储桶管理块630确定和管理净胰岛素推荐。在以下提供的后面部分中将对被运送的胰岛素632、葡萄糖过滤器634和胰岛素剂量无效器636这些模块进行论述。

Pure control模式600是使用葡萄糖测量和内部/外部输入事件以保持血糖控制的胰岛素推荐。医疗专业人员通过接受胰岛素推荐来主动闭合该环，其将开关638转变为这个模式。该工作模式对开环HCP管理的胰岛素推荐与半闭环ALGO确定的胰岛素推荐加以区别。即使这两个模式被医疗专业人员设定，也存在ALGO 510将其自身设置在Controlled-Obs模式700中的情形。当满足以下条件时这会发生，所述条件为：没有bG状况，其发生在由于测量延迟而导致葡萄糖测量不可用时(例如在实验开始时，如果它真的发生的话)；以及过期的bG测量，其表示自上次可用的葡萄糖测量以来的时间超出了可允许的葡萄糖有效期限。下面参考图7来论述该Controlled-Obs模式700。

Controlled-Obs模式700是Pure-control模式600的一种特殊情况，且其由图7中的框图示出。通过使用主体的预编程泵基础速率来实施该用户治疗，并通过使用命令的推注事件来增加该用户治疗。这是开环控制，并且通过医疗专业人员或主体来人工管理该治疗。由于该说明与为Pure-control模式600所提供的说明相似，所以相同的元素用相同的符号表示。ALGO 510主要使用工作方式(working wise)、葡萄糖测量、胰岛素给药和所记录的事件来保持历史和更新状态向量。然而，只有两个事件模块是可应用的，即命令的推注模块616和高葡萄糖干预模块618。这些模块使得主体或医疗专业人员能够管理治疗和执行胰岛素推注。进餐补偿器事件620、锻炼补偿器事件622和低葡萄糖干预事件624在Controlled-Obs模式700中不被执行。基础速率控制628是被编程的泵谱(profile)的复制。

经验算法调用

经验算法(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在开环控制器Controlled-Obs 700(图7)期间实施基础胰岛素。

管理和内务操作(顶层)

在ALGO 510工作的顶层是与管理和内务操作相关的问题。该管理和内务操作模块是：初始化/准备800、处理丢失的循环801、事件映射802、胰岛素存储桶848、和胰岛素无效836。初始化/准备模块800是管理过去、当前和将来信息的ALGO状态向量(ALGO存储器)。在前面章节中描述过的处理丢失循环模块801处理APTS的重启或由于任何原因跳过的ALGO调用。事件映射802将外部事件集映射到内部事件集。胰岛素存储桶848管理来自各个模块的胰岛素推荐作为分量以填满和倒空存储桶。胰岛素无效836从最终胰岛素给药中取消来自控制操作的前馈项的任何胰岛素分量。内部推注管理844运送由进餐事件产生的前馈推注。

监测和状态信息

用于监测和通知状态的模块是：葡萄糖更新808，其跟踪新的葡萄糖测量值的可用性。过期葡萄糖814通知用户是否需要新的葡萄糖值。自推注810通过自推注命令解决任何胰岛素差异。警告没有葡萄糖是故障保护，其报告系统：PU 502(图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接收的事件获得外部干扰信息。例如，在一个实施例中，外部事件被显示在APTS 500的用户界面512中的下拉列表中以供用户选择。ALGO 510对特定于ALGO本身的事件进行操作。这些是被调用的内部事件。由用户选择的每个外部事件被映射到最多一个内部事件。所述外部事件配备有描述符以供终端用户在选择时将其与ALGO操作相关联和/或它们触发ALGO操作。这些描述符可以是特定于用户的，并且可以支持多种语言。

在一个实施例中，可以有与同一内部事件相关的多个外部事件描述符。例如，“自推注”和“起动(priming)推注”是单独的外部事件描述符，但是在内部，这两个事件均指向同一内部事件类型(称为自推注)。因此，可能有指向同一个内部事件的多个外部事件(多对一)。表3列出了ALGO510工作所根据的基本内部事件。

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

内部事件	描述
		零食	碳水化合物摄入
早餐	碳水化合物摄入
		午餐	碳水化合物摄入
晚餐	碳水化合物摄入
		Fast_Carbs	迅速作用的碳水化合物，通常在锻炼期间被触发
Self_Bolus	泵被人工命令以运送胰岛素，未被ALGO 510看到
		准备锻炼	减少胰岛素以在锻炼开始时允许预期的胰岛素下降
锻炼	锻炼活动的实际开始
		HI_BG_Intervention	对于高血糖进行的纠正，其中反馈部分不知道被输入以纠正高血糖的额外命令的胰岛素部分HCP
LO_BG_Intervention	通过造型(sculpting)葡萄糖目标而对低血糖进行的校正
		Infusion_Rate	定义了在实验开始时的基础速率
Prime_Pump	泵被人工地命令以运送胰岛素以用于起动目的

内部事件	描述
		Commanded_Bolus	泵被命令以运送胰岛素
CarbRectification	对上一次进餐项目进行校正

胰岛素设定点

接着，EA 518运行胰岛素设定点模块804。对于这个模块804，基础胰岛素速率(即用于保持葡萄糖值的胰岛素输注速率)是通常针对典型的一天而被定义的基础谱(profile)。然而，如通过主体的生活方式和用于驱动ALGO 510来看，典型的一天是非常不同的。例如，并且如本文所使用的，有两种基础胰岛素谱：(a)泵谱和(b)ALGO定义的谱。对于泵谱，基础速率在该天内变化。预编程的速率可以包括胰岛素以覆盖进餐和其它典型事件的部分。定义的谱是特定于用户的，并且是按照主体的日程表和生活方式定制的。对于ALGO定义的谱，该谱是在分析和去除为了管理事件(比如进餐和锻炼)所需的推注之后确定的。为了确定该ALGO定义的谱，EA 518对新主体使用强化的数据监测。对于已经经历过实验的主体，该临床数据被用于确定ALGO定义的谱。这些通过实验方案和支持工具(比如拆解(raveland unravel)工具)来加以确定。这样确定的所提取的基础速率独立于与事件相关的胰岛素剂量。这样的ALGO定义的谱被保存为基础集。

该基础集被显示为一个三列数组矩阵，其由主体初始化文件(即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))采集数据并将其归类为原始数据。该原始数据与传感器状态一同被处理和分析以确定葡萄糖值和测量时间。例如，该处理应当从过去和当前数据集以及其它信息(比如传感器状态和第二传感器)中去除异常值，以确定最可靠和准确的葡萄糖值。根据提供该原始数据的传感器类型，使用两个处理函数中的一个。

第一个处理函数寻找和使用最近输入的葡萄糖数据点。该函数通过向后遍历每个控制循环来搜索控制循环可用的任何葡萄糖数据，直到它成功地定位(一个或多个)葡萄糖值的集合或者遍历完所有葡萄糖数据为止。如果葡萄糖数据集是空的，则返回空的葡萄糖向量。刚一确定非空葡萄糖集，就将长度为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个循环。所分配的葡萄糖时间戳t_G[K]是所选择的控制循环的结束时间。图11图形化地示出了使用上述变量为第一个处理函数来选择时间间隔。

当目前葡萄糖传感器的工作特性诸如例如通过皮下连续葡萄糖监视器来提供数据范围时，使用第二个处理函数。在这个例子中，数据范围的下限为20mg/dL，而上限为450mg/dL。在这个例子中，未指定其它可能的葡萄糖速率限制。在一个实施例中，传感器通过给数据赋予零值来记录范围之外的无效葡萄糖数据。这样，这些无效葡萄糖值( $g_i^K=0$ )然后就被处理传感器数据模块806从原始数据中剥离出去而将不被包括在任何定量分析中。在一个实施例中，显示弹出消息以警告用户上限和下限。

当为EA计算葡萄糖值时，仅考虑基本的传感器数据。最新的(一个或多个)可用葡萄糖值被选择。将长度为T_C的时间窗定义为(t₁-T_C，t₁]。选择该所选择的窗口上的可用葡萄糖值，并且选择中值： $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).$ 要注意，当需要时，EA 518将会把中值时间t_G[K]舍入到最近的控制循环沿。图12示出了为第二个处理函数选择时间间隔。

葡萄糖更新

在采集和处理原始数据后，EA 518然后继续调用葡萄糖更新模块808。葡萄糖更新解释了葡萄糖可用性及其对ALGO 510的内部工作的蕴含(implication)的一个方面。它不直接与ALGO 510之外的终端用户相关。获得最近的葡萄糖值对于保持血糖控制是很关键的。由于传感器延迟和/或传感器故障，需要葡萄糖预测器来获得对当前葡萄糖的估计。当该传感器提供新的葡萄糖值时，胰岛素推荐模块846使用最近测量的葡萄糖来修改葡萄糖预测。然而，在缺少新的葡萄糖信息的情况下，取而代之使用在控制循环期间确定的预测葡萄糖来预测当前循环的葡萄糖。在这种情况下，状态信息被有效地用于从上一个控制循环推进到当前的新循环以预测葡萄糖。因而该葡萄糖更新模块808识别新的一组葡萄糖测量结果是否可用，以及是否使用上一次预测的葡萄糖并继续。

自推注

然后EA 518调用自推注模块810，以通过从泵访问与自推注命令相关的信息来解决任何胰岛素差异。关于为什么需要物理访问胰岛素泵有多个理由，诸如例如电池改变、胰岛素导管变化、或者用户想要人工命令推注。这些中的一个方面是：在每个控制循环的开始处看到在被运送的净胰岛素项中的任何人工命令的推注。由于ALGO 510不推荐该人工命令的推注，所以EA 518将该推注视为剂量超额。然后通过在将来的控制操作中进行反馈来解决和调节所确定的胰岛素超额。为了系统地处理这种情况，必须在人工推注操作之前触发自推注事件。然后ALGO 510预期等于所输入的自推注量的超额量。使用这一事件还保证了正确地解决所有人工推注。未解决的推注是来自所命令的推注的余量。该未解决的推注具有有限时间窗，在所述时间窗内应该解决自推注量。该量利用剂量超额来加以解决，否则将该未解决的推注(即自推注量的余额(balance))设为零。将事件限制为有限持续时间的另一个原因是为了在用户向测试台通知超额但是并未命令从泵推注的情况下清除存储器以作为安全预防。在将未解决的自推注量设为零之前，通过无葡萄糖报告模块812向用户显示无葡萄糖警告消息。

过期的葡萄糖测量

在采集和处理原始数据并在合适时发送警告后，EA 518然后进行调用过期葡萄糖模块814。葡萄糖预测器的准确性和可靠性随着预测长度的增加而恶化。如果上次接收的葡萄糖值早于某个特定的时间窗，则ALGO 510执行开环Controlled-Obs模式700(图7)以作为安全预防，并实施预编程的基础控制。通过在Controlled-Obs模式700下工作，治疗被约束为被编程到胰岛素泵的基础谱中，并且如果需要，其将通过所公开的功能的子集而被扩充。过期葡萄糖模块814的任务是通过弹出消息来给出关于即将发生的过期葡萄糖状态的信息。当到达过期葡萄糖状态时，该过期葡萄糖模块814切换适当的标志(flag)以执行Controlled-Obs模式700。提供新的基本葡萄糖测量将校正这种情形。因此，过期的葡萄糖表示葡萄糖预测不再有效，并将控制器强行变为Controlled-Obs模式700。

由过期葡萄糖模块814提供以下警告：提前警告操作者、警告操作者、以及过期的葡萄糖测量。针对提前警告操作者，通过记录窗口来提前警告用户该即将发生的到期。在到期之前的倒计时警告循环中，反复向用户通知在届满期限之前还余下n分钟。此外，出现以下消息：“警告：葡萄糖不久将过期。请输入当前的葡萄糖。”针对警告操作者，在最后一个届满期限循环和其后的每个循环中强行显示弹出消息，直到接收到新的葡萄糖测量为止。该消息出现：“警告：葡萄糖在下一个循环将过期。请输入当前的葡萄糖。”针对过期的葡萄糖测量，在过期的葡萄糖条件下，如果ALGO 510正处于闭环Pure-control模式600中，则ALGO 510将强制其自身进入开环Controlled-Obs模式700，并实施用户的基础胰岛素谱。并且，该消息出现：“警告：葡萄糖过期。运行Control Obs！请输入当前的葡萄糖。”接着，EA 518在处理流点816处检查看所采集和处理的数据中是否有足够的bG测量结果以继续。如果没有，则EA进行到处理流点850，这将在随后的章节中讨论。如果有，则EA 518继续到差异管理模块818。

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

差异管理模块818检查看由EA 518确定的所命令的胰岛素是否与从泵配给的胰岛素不同。如果是，则EA 518将其标记为命令的胰岛素差异，并在用户界面512(图5)上向用户呈现提示。然后需要由用户和/或医疗专业人员解决所命令的与所运送的胰岛素之间的差异，因为该差异的原因很可能与APTS 500无关(例如废弃的胰岛素泵)。

膳食葡萄糖区

然后EA 518进行到膳食葡萄糖区模块820。在这时，该膳食葡萄糖区模块820仅仅将葡萄糖目标设定为一个带而不是一条线。该带被ALGO 510在闭环Pure-control模式600中用作目标601，其还提供了被基础控制器628(图6)使用的设定点603。还能够理解，被基础控制器628用作操作输入的葡萄糖预测器626不考虑由于膳食产生的葡萄糖变化。相反，通过预先确定的胰岛素剂量分配来覆盖膳食。该胰岛素剂量分配被确定以最优地最小化葡萄糖升高，以及尽可能快地利用最小下冲(undershoot)来使葡萄糖达到目标葡萄糖水平。对于膳食摄入的葡萄糖升高不能被完全消除。这是被预料到的，因为在峰值胰岛素操作中有大约30-60分钟的延迟。所获得的胰岛素剂量被优化以最小化由于膳食导致的葡萄糖升高。因而与膳食相关的目标葡萄糖区的带被围绕进餐事件定义为由目标葡萄糖上限和下限限定的区域。关于该定义的目标区域，图13显示了四种不同情形：(a)在葡萄糖区域内；(b)在葡萄糖区域上方；(c)在葡萄糖区域下方；(d)没有新的葡萄糖值。

(a)在葡萄糖区域内

如果预测的葡萄糖值位于葡萄糖区域边界内，则主体的葡萄糖被认为处在可接受限度内。在这种情况下，基础控制器628仅需要基础胰岛素以维持血糖控制。

(b)在葡萄糖区域上方

如果预测的葡萄糖位于葡萄糖上边界上方，则主体被认为是运送的胰岛素过少。基础控制器628计算葡萄糖相对于葡萄糖上边界的偏差。该基础控制器628的操作考虑该偏差并将控制该未计入的升高。

(c)在葡萄糖区域下方

如果预测的葡萄糖位于葡萄糖下边界下方，则主体被认为是运送的胰岛素过多。基础控制器628计算葡萄糖相对于葡萄糖下边界的偏差。该基础控制器628的操作考虑该偏差并将控制该未计入的下降。

(d)没有葡萄糖更新

目标区域覆盖了预期的膳食相关响应的升高和降低。当葡萄糖未被更新时将会出现特殊情况。关于葡萄糖测量未被更新，用于当前控制循环T_C的所预测的葡萄糖是不考虑与膳食相关的葡萄糖升高或降低的葡萄糖值。然而，目标区域边界是时间的函数。这通常意味着，当进餐开始(kick in)时预测的葡萄糖较低，而当进餐停止(die out)时预测的葡萄糖较高。在升高的和下降的膳食区域边界时这种影响更明显。EA 518通过保持与上次所接收的葡萄糖测量一起使用的上次的边界限制来处理这种情况。这些上限和下限目标值对于所有将来的控制循环来说被固定地保持，直到获得新的测量。这在一定程度上减轻了该问题。

准备锻炼和锻炼

接着，EA 518通过锻炼模块822评价该患者是否进行锻炼。随着体力活动水平的增加，维持能量的要求也增加。葡萄糖作为能量源，被以更高的速率使用以支持增加的活动。因此，按如下方式作出这三个生理行为的假定。第一个假定是，刚一开始锻炼，葡萄糖水平就会降低。第二个假定是，在体力锻炼开始后大约10分钟，葡萄糖降低迅速开始，在体力锻炼结束后大约10分钟，葡萄糖降低迅速停止。最后一个假定是，一旦体力活动水平回到正常，有一个预期的恢复阶段，因为葡萄糖被存储为肌肉和肝脏中的糖元。因此，分别通过锻炼模块822和准备锻炼模块828来分阶段处理锻炼。

在处理流中随后被EA 518调用的准备锻炼模块828通过增加葡萄糖设定点来提高在锻炼的预期中的葡萄糖，从而可以在锻炼期间安全地降低葡萄糖水平。因此，被预先确定以处理锻炼的正常治疗用于减少在锻炼的预期中的基础胰岛素。该降低的胰岛素对葡萄糖的影响取决于胰岛素的药效学。然后对于锻炼的持续期间保持该较低的基础胰岛素水平。此外，如果在锻炼开始时没有足够地提高葡萄糖水平，则主体可以通过消耗快速作用的碳水化合物来管理他们的葡萄糖水平。这将使得葡萄糖水平迅速升高。

主体通过从在用户界面512(图5)上提供的列表中选择活动和/或活动水平来触发准备锻炼事件，从而准备锻炼。所选择的活动和/或活动水平具有相应的预期葡萄糖降低。直到该锻炼事件被触发，目标葡萄糖的变化由方程式(6)给出：

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

其中ΔG_T是目标葡萄糖值的变化，ΔG_P ^E是葡萄糖浓度的预期增加(升高)，对于锻炼而言，该值是负的，因为锻炼会引起葡萄糖的降低。所以目标葡萄糖(即目标601)由方程式(7)给出：

G_T＝G_T+ΔG_T                               (7)，

再者，一旦锻炼活动开始，则身体会需要更少的胰岛素并在锻炼持续时间期间保持更低的基础胰岛素需求。一旦锻炼完成，减少的基础值会以某种预先定义的渐进方式回到正常的基础设定上来。

在锻炼开始后，锻炼周期模块822在锻炼持续时间内计划(project)葡萄糖的降低。当锻炼事件被触发时，准备锻炼被关闭。在锻炼事件的开始处，基础状态被重新评估。如果准备锻炼没有将葡萄糖水平提高到预期量，则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是用于锻炼的负值。该锻炼和快速作用的碳水化合物的效果被建模为在归一化的葡萄糖增长响应曲线中的相反方向上移动的葡萄糖增加向量。

在锻炼之后，锻炼模块822提供按照基本设定要求逐渐正常化基础速率的锻炼恢复期。在这个实施方式中，锻炼的持续时间被预定义在向量

中。一旦锻炼结束，由于锻炼而导致的葡萄糖增加

就变为0。通过使用

和如果来自基础集的胰岛素基础速率被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是当前时间。

快速作用的碳水化合物

在完成锻炼模块822后，如果患者在用户界面512(图5)上作出指示，则EA 815然后调用快速作用的碳水化合物模块824以提供由于摄入快速作用的碳水化合物而导致的对葡萄糖增加向量的更新。使用预期的葡萄糖增加谱和相关的葡萄糖增加谱来分析葡萄糖增加向量

预期的葡萄糖增加谱是预定义的葡萄糖增加向量，并且其被归一化为每克碳水化合物摄入和每mg/dL升高。相关的葡萄糖增加向量是归一化增加向量

所消耗的快速作用的碳水化合物的量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仍然活动的情况下，ALGO510将看到所测量的葡萄糖的增加，并且将通过推荐额外的胰岛素来潜在地抵消该葡萄糖增加。然而，低葡萄糖干预模块826允许利用更保守的胰岛素推荐来使葡萄糖增加。

在一个实施例中，A^LG被定义为降低葡萄糖水平所需的快速作用的碳水化合物的量。于是预期的葡萄糖增加可以由方程式(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的累积。对于当前的低葡萄糖干预事件，低葡萄糖干预在增加

之前去除上次低葡萄糖干预的残余拖尾部分，而不是增加该效果。在这样的干预后，EA 518调用准备锻炼模块828，由于在之前的题为“准备锻炼和锻炼”部分中已经对其进行了说明，这里不再提供进一步的说明。

命令的推注

当用户通过APS 500命令泵运送额外的胰岛素推注A^CB时，EA 518使用命令推注模块830。然而，EA 518通过ALGO 510针对每个控制模式不同地识别和实施该命令推注事件。对于闭环Pure-control模式600(图6)，该命令推注事件可以强制胰岛素的早期运送，并从而可以修改胰岛素推荐的将来分配。此外，当处于Pure-control模式600中时，该命令的推注A^CB将超过和高于为了实现目标葡萄糖所需的胰岛素量。因此，在将来的控制循环中，EA 518考虑A^CB，并因而调节建议。对于开环Controlled-Obs模式700(图7)，命令的推注模块830使得主体能够通过经由用户界面512(图5)输入输注以在Controlled-Obs模式700期间管理他们个人的治疗，从而覆盖诸如例如膳食摄入和提高葡萄糖水平之类的事件。

高葡萄糖干预

高葡萄糖干预模块832使得EA 518能够纠正高血糖状态。用户通过用户界面512(图5)将纠正量A^HG作为高葡萄糖干预事件输入。两个控制模式600和700运送干预量以及由相应模式生成的推荐。命令的推注是“ALGO所看到的”胰岛素，而被运送以覆盖高葡萄糖干预事件的胰岛素是“ALGO看不到的”。在闭环Pure-control模式600中，ALGO 510的反馈部分不知道胰岛素干预的量。胰岛素无效模块836(下文中将在稍后章节中讨论)去除与高葡萄糖干预相关的胰岛素量。这意味着，该反馈不会从将来的控制操作中减少胰岛素的量。在开环Controlled-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的进餐事件，其需要[2 05 0 0 3 0 0 2]作为胰岛素分配。进餐相关推注(MEAL RELATED BOLUS)直到t＝525均为[315]，而内部推注事件(INTERNAL BOLUS EVENT)是[0 0 3 0 0 2]。进餐相关推注(MEAL RELATED BOLUS)示出存在例如来自在前的进餐的附加胰岛素贡献。它的存在是重要的，并且对于当前问题而言，贡献(contribution)来自何处并不重要。在t_MC＝525，输入对膳食的纠正。现在信息是：对于在t_M＝495时的100g的膳食输入，实际上仅消耗了60g，这就完成了步骤1和2。所以，在步骤3中，该模块834首先确定针对60g的胰岛素，其在步骤4中为[1.5 0 3 0 0 2 0 0 0 1.5]。因为ALGO 510在步骤5中并不记得针对100g的分配是什么，所以在步骤6中针对100g对其重新计算为[2 0 5 0 0 3 0 0 2]。两个向量(60g和100g)在步骤7中被推移到t＝500(由箭头示出)，并且在步骤8和9中重新计算MEAL RELATEDBOLUS和INTERNAL BOLUS EVENT二者。

如果碳水化合物校正是不可应用的，则在用户界面512(图5)中显示以下弹出消息：“警告：进餐纠正未被应用。”如果碳水化合物校正是可应用的，则显示以下弹出消息中的一个(根据所输入的量)：“警告：现在把在(hh:mm)输入的(数量)克的膳食纠正为(数量)克。警告：膳食残余必须在(数量)和(数量)克之间。”

胰岛素无效

在碳水化合物校正模块834后，EA 518调用胰岛素无效模块836。如上所述，该胰岛素无效模块836从最终运送的胰岛素(即为循环配给的胰岛素量)取消前馈胰岛素分量。最终的胰岛素给药是来自所有EA的前馈模块(比如例如自推注命令、膳食相关的推注和反馈分量)的所有胰岛素量。胰岛素无效从该最终胰岛素给药中去除任何前馈的胰岛素量。EA 518的当前实施分别管理各个前馈胰岛素分量。胰岛素无效实际上意味着已经去除所有的前馈胰岛素量。为了获得正确的胰岛素反馈推荐，将所有前馈分量正确去除是绝对必要的。胰岛素无效向量

由方程式(16)给出：

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

其中

是被运送的胰岛素向量，

是膳食相关的和高葡萄糖干预的推注，

是与自推注和起动(priming)相关的推注、前馈分量。要注意，如果在泵运送数据中过去的值不可用，则用基础胰岛素剂量来填充过去的信息。

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

接着，EA 518调用葡萄糖预测模块838。被APTS采集的葡萄糖测量是被延迟的测量，因为传感器具有物理和处理滞后。进入未来的准确葡萄糖预测是提供血糖控制的关键。葡萄糖预测模块838使用过去的胰岛素给药信息、葡萄糖测量结果和使用胰岛素药效学进行预测。图17示出了胰岛素残余药效学。为了实施，在subject.ini文件中定义了对于单位推射残余的胰岛素的药效学，该胰岛素的药效学在这里由

给出。如所示，在T_C＝10mts处对针对单位胰岛素脉冲响应(impulse response)的药效学进行采样。

基础控制器628的基础部分基于与葡萄糖预测中所使用的原理相似的原理。潜在的原理是，葡萄糖水平的变化是由于基础控制器628(图6)所纠正的未建模的设备(plant)干扰造成的。对于胰岛素推注的调节考虑了预测的葡萄糖。来自于提供基础控制的葡萄糖预测器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_l、胰岛素敏感度[mg/dL/U]，则由于胰岛素使用而导致的胰岛素降低由方程式(18)定义：

ΔG[i]＝-K_lΔ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}}_{[-m-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),$

其中

是关于点j的前n个胰岛素运送量的向量，在第j个时刻的葡萄糖降低ΔG[j]，其中j＝K+1，…，k循环。图19图形化地示出了胰岛素脉冲预测。葡萄糖预测模块838使用方程式(20)预测某时刻j的葡萄糖。通过使j从K+1步进到k来实现在k处的葡萄糖预测。葡萄糖预测从3部分计算：(a)被运送的基础胰岛素，(b)预定义的基础胰岛素，和(c)葡萄糖预测。

(a)被运送的基础胰岛素

被运送的基础胰岛素向量

是被无效的胰岛素给药。预期的葡萄糖降低ΔG_N[j]由方程式(21)定义为：

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

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

预定义的基础胰岛素是根据基础集(Basal Set)确定的，并且是无干扰情况下的“将是基础胰岛素”值这是为了保持目标葡萄糖G_T所需要的基础胰岛素分量。预期的葡萄糖降低ΔG_B由方程式(22)所定义的内积给出：

$\mathrm{\Δ}{G}_B\left[j\right]={\stackrel{\→}{I}}_{[-m-1|j]}^B*\mathrm{\Δ}\stackrel{\→}{G},$ j＝K+1，…，k                  (22)。

(c)葡萄糖预测

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

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仅考虑上一次进餐输入。在实施部分中描述了覆盖进餐的所分配的胰岛素推注。一次大的进餐不一定等效于若干小的进餐的和。这可以在进餐计划中加以定义，例如小的进餐＝25gm，常规进餐＝50gm，而大进餐＝75gm。如果当前的基础胰岛素需求是相对的，并且已经触发了进餐，则使用FastCarb谱来调节设定点。预期葡萄糖快速升高，因为膳食增加具有像快速碳水化合物一样的动态特性，而不是像胰岛素药效学那么慢。

进餐报告

接着，当适于提供弹出对话框以通知主体开始吃东西时，EA 518调用进餐报告模块842。如果进餐报告弹出将被显示，则由基础控制器628来设定控制进餐报告模块842的标志。

内部推注管理

此外，如果合适，则EA 518调用内部推注管理844以运送由进餐事件导致的前馈推注。

胰岛素推荐

然后，EA 518调用胰岛素推荐模块846以使用上述当前预测的葡萄糖值来计算胰岛素剂量。特别地，通过设计正在工作(on board)的胰岛素的影响、将来的基础输入和其它输入事件的影响，来计算针对胰岛素剂量的胰岛素推荐。以下步骤确定了基础胰岛素建议：(a)当前葡萄糖，(b)被运送的基础微扰(pertubation)胰岛素，(c)葡萄糖设定点，(d)预定义的基础胰岛素，和(e)葡萄糖增加。

(a)当前葡萄糖

当前葡萄糖根据预测葡萄糖部分来确定并由G[k]给出。

(b)被运送的基础微扰胰岛素

该向量是被无效的胰岛素给药。然后所估计的胰岛素残余是I_r ^N[k]，其由方程式(24)给出：

$I_r^N\left[k\right]={\stackrel{\→}{I}}_{[-m-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给出。因此，胰岛素推荐则由如方程式(26)所定义的I_req给出：

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

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

$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实施最小基础速率(典型地是基础速率的一半)。重要的是，循环的胰岛素浓度绝不会下降到低于阈值以避免反调节。加强最小基础保证了最小循环的胰岛素水平。

胰岛素存储桶

当EA 518调用胰岛素存储桶模块848时，通过组合基础控制和由于所触发的各种事件而导致的开环胰岛素需求而进行最终胰岛素推荐。此外，存在对最终胰岛素推荐施加的约束，比如例如关于每个控制循环的胰岛素量的顶(cap)，其被称为运送上限约束。最后，胰岛素推荐可能不得到实施。例如，医疗专业人员是接受或拒绝推荐的最终权威。最终胰岛素给药是实际的给药。因此，被保持在各个胰岛素存储桶中的胰岛素记录保持构件必须遵从推荐约束。如果最终胰岛素推荐与最终胰岛素给药不同，则ALGO 510重新评估和重新考虑对于被相应地修订的最终胰岛素给药的分量。

在处理点850，EA 518确定开环Pure control 600是否被启动，不足bG测量标志是否被设定(其是从处理点816重新进入的点)，或者bG过期标志是否被设定。如果任何这些条件都为假，则EA 518调用更新存储模块854以保存来自该控制循环的值和状况。如果任何一个条件为真，则EA 518将调用差异管理模块818、命令推注模块830、高bG干预模块832和对最终胰岛素推荐施加约束的运送上限约束模块852。在完成这些调用后，EA 518然后将调用更新存储模块854以保存来自该控制循环的值和状况。然后EA518在重新开始图8和9所示以及上面描述的处理流之前将一直等待，直到ALGO 510的下一控制循环开始。

ALGOSHELL

ALGOSHELL 506提供数据结构管理和位于系统文件夹中的相关宏。特别地，ALGOSHELL 506是对从APS 500调用的给定输入生成输出的函数。该ALGOSHELL 506函数还与在仿真(Simulink)环境中运行的APSe一起工作。如上所述，APS测试台环境是非Simulink环境，其中APSe是仿真该APS测试台环境的包装函数。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、ExperimentStruc、PumpStruc、BGStruc、PatientIniStruc，然后论述输出变量yAMT、yAdvice、yTrace和xk’。

输入变量

t项是针对消逝的时间或仿真时间的时间标量。时间t被预期为Sync1调用的TControl+/-时间增量(delta time)的倍数，并且被定义为当前的控制循环沿。Sync2调用将跟随Sync1，并且将发生在下一个控制循环沿之前。xk项是包含ALGOSHELL所需要的被称为states的一组变量的状态向量。在APSe中，这些是由更新离散状态的控制所保持的离散状态。当APSe被调用时，xk可以作为状态(states)使用。另一方面，APS总是处于控制下，并且负责保持xk。向量xk的长度和细节是依赖于ALGO的。APS不需要知道xk的长度或细节。变量xk应当被APS初始化为空矩阵[]。然后ALGOSHELL 506将确定其第一次被调用时的正确长度。从那时起，实验应该保持xk的长度。APS/APSe不应该修改xk的值或长度。u项是输入向量，并且包含由现场设备(即泵和传感器)输出的信息。APS和APSe二者都需要知道输入向量u的细节。参见表6以获得细节。要注意，“净配给的胰岛素”是用于由泵配给的胰岛素总量的累加计数器。

表6：输入向量u

EventStruc-事件结构

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

表7：EventStruc字段

字段	定义	注解
			trigger_time	事件发生的时间，经历的时间，min	n×1数组，追加新条目(entry)。ALGO 510需要条目以采取任何操作
rxn_time	控制器应该响应事件的时间，经历的时间，min	n×1数组，追加新条目。缺省为NaN
			event_type	由定义在PatientIniStruc.events.type中的事件的行数识别的事件类型	n×1数组，追加新条目。缺省为NaN。在PatientIniStruc.events.type中按事件对event_type编索引
duration	事件(生理的)影响的持续时间，min	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事件的目的的事件；和通知ALGO510考虑事件(例如早餐)和对该事件作出适当反应的事件。

ExperimentStruc-实验结构

这是一个通过APSe参数被预定义并且对APSe可用的结构。APS加载实验结构以用于实验运行。参见表8可得到实验结构字段。

表8：实验结构字段

字段	定义	注解
			operator	登录ID
timestamp	时间戳，min
			algo_used	所使用algo的名字	从PatientIniStruc获得。对于一个实验不变化。
title	实验名称	从PatientIniStruc获得。

字段	定义	注解
			time_int	控制循环的长度，sec(TControl，即连续的第1个ALGO调用之间的时间)	从PatientIniStruc获得。
t_zero	[年 月 日 小时 分钟秒]MATLAB格式时间	以绝对时间的实验起点。APS给该实验起点加上时间戳
			confirm_int	确认时限，sec	缺省mat文件
Confirm_offsetOffset_int[修订的字段名]	确认偏移，sec	缺省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-第2次调用/异步调用5-后推荐	APS设定模式。对于APS3，整个运行是模式3，接着是模式4：Pure-control调用后面跟着第2个调用

字段	定义	注解
			ControlObs	标记：1-被控制的观察2-纯控制	可用于APS3和更高。APS设定该标记并且其是主GUI上的Control按钮的函数
DataPath	存储Rundat mat文件的位置	当ALGO失败时，局部变量被保存在mat文件中
			num_timeouts	确认被丢失/超时
num_asyncs	异步命令的推注的量
			num_recos	Algo推荐的量
num_ovrs	用户超驰(overide)的量
			patientini(i，1)	结构数组	从patient ini mat文件获得
PatientIni_LoadTime	时间数组
			Single_dose_lim	由APS施加的剂量上限，U

PumpStruc-泵结构

除了数据字段之外，该结构的所有字段被预定义且从APCATS 900的用户界面获得。该结构在最初被作为参数传递。在初始化阶段中，PumpStruc变成mat文件。APS具有类似的设置。如这里在表9中所使用的，“离线”表示当按照来自APSCOM 504的上一状态信息泵不可用时所发生的状况。泵结构的字段参见表9。

表9：PumpStruc字段

BGStruc-血糖结构

除了数据字段bg1data和bg1timestamp之外，该结构的所有字段被预定义且从APCATS 900的用户界面获得。该结构在最初被作为参数传递。传感器被编号为0、1、2、3…，其中传感器1被视为虚拟传感器。表10给出了传感器1的传感器结构字段。对于其它传感器编号，用传感器编号替代每个字段中的“1”。最多支持4个传感器：2个SU的，1个外部的和1个虚拟传感器。然而，对于APS-3，我们有以下关于传感器的映射：0对“EXT”，1对“SU 1”，以及2对“SU 2”。

表10：传感器结构字段

字段	定义	注解
			bg1timestamp	流逝时间，min	n×1数组，u(2)，就在ALGO被调用后
bg1chan
			bg1data	葡萄糖浓度	n×1数组，u(1)，就在ALGO被调用后单元由bg1units指定
bg1indx	上一个数据集索引
			bg1units	Bg1data信息的单位(所报告的血糖测量结果的	葡萄糖浓度的内部标准是mg/dL
	单位)，“MG/DL”或“MMOL/L”

字段	定义	注解
			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-文件)中被定义，并且包括对膳食摄入和胰岛素降解的特定于患者的响应向量。该INI-文件向APTS 500和ALGO 510提供特定于研究的和特定于主体的参数。在APS被装入时所加载的主体INI-文件包含特定于主体的数据，其包括算法参数、单个剂量自动确认和三个剂量确认阈值以及事件类型。如上所述的事件类型是在实验期间可以由医疗专业人员通过下拉列表人工选择的活动。普通事件类型包括进餐和外部血糖(bG)仪读数。下拉列表值由主体INI文件确定。如在主体INI文件中指定的连续剂量阈值是在没有医疗专业人员认可的情况下将在三个连续循环中被运送的胰岛素的最大量。如在主体INI文件中指定的自动确认阈值是在没有医疗专业人员认可的情况下将在单个循环中被运送的胰岛素的最大量。实验是从APTS的开始到结束所采集的数据，包括INI-文件中的任何中间重启和变化。该主体INI文件中提供的对字段的字段说明参见表11。

表11：PatientIniStruc字段

字段	定义	注解
			title	名称	15个字符，被显示为APS窗口上的研究ID
pat_id	患者ID	11个字符，被显示为APS窗口上的患者ID
			time_int	秒	TControl
gender	性别，“M”或“F”	1个字符
			ht	高度，in
wt	体重，lb
			Site	“RD”，“01”，或“02”
Version
			ControlNos
AlgoShell	AlgoShell_A2M
			IniFilename		13个字符，被显示为APS窗口上的PATIENT INI
StartDate
			ExpDate
IniCreationDate
			LockoutMode	0-纯控制的obs1-允许用户在控制的obs和pure
	control之间切换

字段	定义	注解
			PlaceOfBirth	N/A	N/A
ExpParam	对于每个ALGO唯一并且用于内部ALGO使用的结构。将所有与ALGO相关的附加变量分组。检查两个字段：algo_used，algodir	“algo_used”：在APS窗口上被显示为ALGO NAME“algodir”是包含由algo_used描述的mfile的目录。MatlabPath设定应该包括两个路径：C:\apsv3_0\algos和C:\apsv3_0\algos\algodir(其中algodir是被存储的字符串)不应该有任何其它algos子文件夹被列出。“USE_ENTRY_INSU_CEILING”“SimuALGOPARAM”“DispALGOPARAM”“LOGFILEMSG_DEBUG”“MildHypo”“SevereHypo”
			dose_confirm_thresh	当前的剂量上限，U
three_dose_confirm_thresh	前三个剂量上限，U
			events		事件映射，且具有以下字段：类型：在事件类型的下拉列表中被显示。用于用户的描述符。单位：用于所选事物(selected)的单位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-推注2-不设定命令	ALGO计算	按原样传递到APSIO
yAMT(4)	U	对于纯观察为0对于pre-reco为0对于Sync1为recco-calcu值对于Sync2为用户值	Sync1：algo推荐的量Sync2：用户认可的量Async：用户要求的附加的量
				yAMT(5)	每控制循环所配给的量，U	在Async调用期间，这是NaN	APSIO提供净配给量u(7)，其被转换为U。然后通过从u(7)中减去sum(pumpdat.amount1delivered)而获得由泵1在前一循环中配给的量

yAdvice项是报告(advisory)字符串，其提供警告和其它可能的由ALGO标记但是由APS执行的故障保护措施。yAdvisory字符串由一个两位数字的报告编号，接下来是空格，接下来是语句构成。该报告编号落在三个种类中：(1)标称(nominal)(范围：00到09)，(2)弹出消息窗口(范围：10到98)，和(3)退出/停止(Exit/Quit)(范围99)。yTrace项是跟踪ALGO执行的步骤的跟踪字符串。ALGO进度被记录在ExperimentStruc文件中定义的、位于DataPath中的记录文件中。xk’是在下次ALGO调用时启动ALGO所需的状态向量。

控制循环停止(breakup)

对于包括同步调用、用户确认窗口和异步调用的推荐模式，每个命令值被约束为泵在控制周期的剩余部分中可配给的量。确认窗口是要求最终确认所命令的胰岛素的对话框，并且在医疗专业人员人工接受或拒绝胰岛素推荐时出现。在所示实施例中，该窗口在45秒后超时。因此，控制周期被分解为如图34所示的三个区域，并且在表13中列出了ALGOSHELL中的参数。在理想情况下的每个控制循环将允许在控制循环开始时调用ALGO。ALGO将处理输入并推荐在控制循环的剩余部分中将配给的量。但是存在硬件限制，因为(1)每个操作需要有限的时间，和(2)内部时钟是离散的。此外，存在人的干预，并且对于开环控制而言，存在控制操作剩余的实际时间的差异性。在把所有这些考虑因素计算在内后，确定将允许整体输送命令的命令值。

表13：ALGOSHELL中的参数

参数	时间，sec
		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)被赋给向量u的来自BGStruc的最近的(上一次)BG测量结果和时间以及传感器状态；(b)从数据库获得并被赋给向量u的上次净胰岛素配给信息；(c)被设定为调用ALGOSHELL 506的时间的时间t；(d)被APS按原样传递的向量xk；和(e)被设定为3的实验泵模式。ALGO 510被再次调用，n＝m+1。ALGOSHELL 506被以模式＝3调用，即作为Sync1调用。

对于该Sync1调用，返回向量yAMT和其它输出变元。APS使用yAMT进行图35中所示的更新。yAdvisory被分析，并且显示适当的消息(发送到记录窗口，弹出消息框，以及退出)。被推荐的量yAMT(4)被APS推荐窗口514(图5)显示。推荐窗口514显示如由ALGO 510确定的、用于当前循环的所推荐的胰岛素剂量。该推荐窗口514在运行循环结束时显示将被输注的胰岛素的被推荐量。如果该量在单剂量或三次剂量的阈值内，则不需要由医疗专业人员确认而被输注。所获得的用户响应是：(a)推荐被拒绝，VALUE＝0，indx＝0；(b)推荐被接受(确认)，VALUE＝yAMT(4)，indx＝1；或(c)超驰，VALUE＝输入值，indx＝2。Pumpdat向量被更新。进行如图35所示的以下赋值：对于pumpdat更新，与传感器相关的u元素为零；u(1)到u(6)为NaN，u(7)被赋予VALUE；u(8)是当前时间t；以及u(9)是泵状态标记。实验模式被设定为4(对于Sync2调用)。ALGO 510被再次调用，n＝m+2。最后，调用ALGO 510作为Sync2调用。对于Sync2，如图35所示地更新Pumpdat向量。然后对于下一控制循环重复该序列。

ALGO-APS流

下面在表14中也提供了一个ALGO-APS处理流的例子。要注意的是，流逝的时间是从实验开始起以分钟计的相对时间t。当发生重启时，开始时间是该实验的开始时间，而不是该重启的开始时间。流逝的时间仍是参照“ExperimentStruc.t_zero”相对测量的。

表14：ALGO-APS流

所关注的方面是，假定Sync2发生在控制循环沿之前，则Sync1紧跟着Sync2，并且由APS正确记录和存储重启yAMT。要注意的是，重启是未完成实验的恢复，其中在先数据被采集以供APTS绘图和供ALGO使用。使用以分钟计的流逝时间将传感器和泵数据赋给BGStruc和PumpStruc。向量u总是发送最近可用的数据以及时间戳。如果没获得新的数据，则获取上次已知的数据。现在将提供对第二个特定实施例的讨论。

APCATS(自动胰腺-控制算法测试套件)

自动胰腺-控制算法测试套件(APCATS)是用作标准化仿真工具、AP测试台模拟器、验证工具和评价工具的软件程序。作为标准化仿真工具，APCATS提供了仿真通用闭环系统所需的基本功能。同样，所述功能允许设计数学模型的人员集中注意该建模本身而不是基本设置和连接的连接和验证的细节。作为AP测试台模拟器，该程序能缩短评估和验证来自于APTS500将要求的算法变化所需的时间。为了达到这一点，它在提供用于ALGO 510的相同仿真环境的同时使用“仿真的”时间(与实时相对照)。而且，通过允许在参数值范围内仿真，APCATS可以扩大评价范围而不会危及患者。此外，APCATS可用于仿真和评价临界情况。例如，可以系统地评价设备故障，或者可以实施和评估故障保护模式。

作为验证工具，APCATS提供如下能力：模拟APTS 500从而允许在开发和预发行场景下对ALGO 510的任何修订进行第一次验证。作为评价工具，APCATS可用于仿真数学模型、控制器、闭环响应等，从而允许评价被仿真项的(1)质量和(2)性能。在所示实施例中，在MATLAB技术计算环境中开发和运行APCATS。在其它实施例中，可以使用其它语言和计算环境例如visual basic和Windows操作系统。前端用户界面提供开发和分析用于略微标准化的自动胰腺系统的控制法则的快速方式。如果硬件被连接在控制环路中，则它提供用于执行分析和仿真以及驱动实时系统的公共平台。因为APCATS是在与APTS 500相似的操作环境中(例如在系统10中)实现的，并且在硬件上实现软件程序也是本领域技术人员很容易理解的，所以以下章节仅关注本发明的该第二个特定实施例的软件构件。

软件构件

APCATS应用包括若干不同的软件构件，其可以分为三类：用户界面、初始化文件、和构件模块。APCATS具有中央核心，其保持数据并形成将所有前端纳入统一应用中的中枢。初始化文件也称为init文件，其通知APCATS核心所需要的模块在哪里以及它需要读取和实施什么模块。基于这些文件中的信息，APCATS动态地创建自身。构件模块以数学方式描述每个构件如何工作。在仿真期间，它们动态地对外部和内部激励作出反应。该构件模块在本文中根据以下主要类型分类：装置(plant)、致动器、传感器、控制器、和外部干扰。在稍后的章节中将更详细的讨论这些构件模块。

用户界面(UI)是允许由用户输入(例如：选项选择、与某些特征的交互、以及输入或修改值)的前端。它还允许用户观察输出。因为该核心被设计成与问题本身相独立，所以问题定义处于构件模块中。通过初始化文件来管理UI与构件模块之间的交互的灵活性。用户界面覆盖了以下核心方面：APCATS主窗口；每个构件的用户输入表格；构件的菜单表格；仿真运行设置表格；仿真链接(Simulink)框图的生成；管理和与数据文件的交互；绘图以显示结果；存储和检索APCATS设置；和连接接口。

参照图22，由符号900总体指示的APCATS提供了用户界面作为主窗口902。该主窗口902提供了三个窗格：运行/存储窗格904；算法窗格906；和绘图窗格908。此外，在底部的状态条910转播(relay)APCATS 900的活动的消息。

算法窗格906是控制算法，其是调整模型患者内的血糖水平的关键。该算法窗格906显示了自动胰腺控制算法，其由与输入/输出连接线X连接的若干块组成。该算法窗格906用于设置整个闭环系统。它允许选择模型、编辑参数值、和修改连接。每个块和连接可以被选择以显示和设定它们的参数。可用的块(block)是：外部干扰块912；装置块914；传感器块916；控制器块918；和致动器块920。如所示，块连接是：外部干扰块/装置块连接；装置块/传感器块连接；传感器块/控制器块连接；控制器块/致动器块连接；致动器块/装置块连接；以及致动器块/控制器块连接。

图23是示出了通用闭环结构的框图，其中该图中的相互连接箭头表示算法窗格906的块之间的接口。所述相互连接箭头还表示块之间的信息流。算法窗格906的每个块在最顶层向用户提供若干选项。如果有的话，与选择相关联的其它选项被作为隐藏的子层展开。这些层对用户开放，并且其在用户从最顶部的可视层进行到较低层时被激活。通过算法窗格906上的多个块912-920和连接，可以修改仿真所需要的参数。它们允许用户从若干可能的模型中选择、根据所选择的模型设置参数、以及设置通过输入/输出连接传递的信息。首先参照装置块，下面将对算法窗格906的各个块进行更具体的说明。

装置块

装置块914提供了多个可选择患者模型的列表(例如图3中的患者模型73)，其反映了有关的生理和代谢相互作用的当前知识。可以建模和提供(添加)具有变化的复杂度和细节的新患者模型以用在装置块914中。通过调节参数界限，装置块914可用于研究和建模大范围的行为。装置块914接收来自致动器的输入和由各种饮食摄入产生的干扰。传感器被用于测量来自于在装置块914中所选择的患者模型的输出。

装置选择和参数设定

通过点击相应的单选按钮之一来通过装置块914选择患者模型。在任何时候仅能选择一个患者模型。对应的单选按钮变为高亮，并且引出一个装置菜单窗口922(如图24所示)。点击已选择的患者模型也会引出该装置菜单窗口922。如果当选择新装置时装置菜单窗口922已经打开，则APCATS900将检查看是否已经保存了输入到其中的参数。如果已经保存，则将关闭当前的装置菜单窗口922，并打开用于新选择的模型的新的装置菜单窗口。如果该参数未被保存，则将在主窗口902底部的消息条中显示该影响的消息，并且不会关闭已经激活的装置菜单窗口922。对应于所选择的患者模型的参数被显示在窗口中，并且被加载上存储在存储器中的已保存值。参数值可以被编辑并将被用以下颜色显示以指示它们的编辑状态：黑色——缺省或未编辑的值；红色——经过编辑的值；蓝色——被冻结的不可编辑的值。

如果患者模型选择被改变，则与装置块914相链接的块之间的之前存在的连接将被破坏，并且用户将需要重新连接它们。(参见下面提供的连接部分)。与装置块914相关联的输入和输出被更新。而且，选择新的患者模型将导致绘图设置中的自变量和因变量的更新的列表(参见部分6)。装置菜单窗口922中的每个参数都被列出在其自己的行中。该装置菜单窗口922中的列是：用于每行的“Nos.(编号)”列924；用于参数名称的“Parameter(参数)”列926；和用于输入参数值的“Edit Value(编辑值)”列928。输入的值必须是在“Slide Value(滑动值)”列930之后所提供的两列中的参数的指定的最小和最大值之间，该值的变化也将被反映在相邻滑动块932中。

“Slide Value”列930提供了设定参数的值的一种可替代方法，其中滑动块932的左和右端分别对应于该参数的最小和最大值。当滑动块932被移动时，在该滑动块的左边的列中、即在Edit Value列中将更新参数的数值。“Edit Min.”列932提供了最小可允许的参数值。该值可以被编辑，其中变化也将反映在滑动块932上。“Edit Max”列936提供了关于该参数值的上限。大值应当被用于不具有上限的参数。该值可以被编辑，其中变化也将反映在滑动块932上。

“No.of Div”列938用于指示参数值的数量，关于该参数来执行仿真(例如参数研究)。必须输入非零的正整数。非整数值被舍入到最接近的有效整数。对于Div的下述值，将被用于实验仿真的参数值是：0或1表示使用所输入的参数值；2表示使用最小和最大值；3表示使用最小、平均和最大值；n(n是正整数)表示使用最小、最大和n-2个等间隔的中间值。注意，参数研究将包括参数值的每种组合，并且如果使用若干参数的多个值，则可能导致运行过多次数。为了确定组合的数量，乘以为所有参数选择的划分(divisions)数量。利用APCATS 900，可以执行两种不同类型的参数研究：(a)参数范围的系统跨度；和(b)参数范围的随机跨度。

(a)参数研究(系统地)

为了对给定参数进行参数研究，用户将参数的划分数量设定为要研究的值的数量。将要进行运行的参数值将是被输入的最小和最大值以及足以给出规定数量(stated number)的值的多个均匀间隔的中间值。例如，如果一个参数的划分数被设定为5，则将对最小和最大值以及三个其它值(即在所述最小和最大值之间的距离的四分之一、二分之一和四分之三处)进行运行。如果多于一个参数被设置为使用多个值，则将对所有参数值的每种可能组合进行运行。在设置“Nos.of Div”时应该谨慎，因为其会很容易产生过多数量的组合/运行。

(b)参数研究(随机)

为了使用随机的参数选择，用户选取“选择参数值@随机”复选框(checkbox)940。“Number of runs(运行次数)”和“SEED(种子)”字段942和944将分别被激活。在“Number of runs”字段942中，用户输入将在实验仿真期间运行的仿真数目。在“SEED”字段944中，用户输入正整数作为随机数生成器的种子。该SEED值被用于重新创建随机数序列，并被存储在实验的文档中以允许再次生成随机值。随机数生成假定在参数范围上的均匀分布。对于每次运行，用于所述参数的随机值被存储在文档文件中。在装置菜单窗口922底部的命令行菜单946提供了以下功能：保存(save)、取消(cancel)、帮助(help)和关闭(close)。“save”保存任何参数改变，并且仅当至少一个值自从它们上次被保存后发生改变时被激活。“cancel”恢复上一次保存的值。仅当至少一个值自从它们上次被保存后发生改变时，该按钮被激活。“help”打开帮助窗口，而“close”如果有任何改变的话保存改变并关闭窗口922。

传感器和致动器

因为传感器和致动器块(分别为916和920)的表述是相似的，并且它们在算法窗格906中的用户界面也相似，因此这里将它们一起讨论并统称为设备块。致动器块920(图22)仿真从控制器块918接收命令的泵单元。这激活致动器块920。来自于致动器块920的(一个或多个)输出被发送到装置块914。另一方面，传感器块916测量来自在装置块915中所选择的患者模型的信号，并向控制器块918发送信息。设备块916和920具有以下特征：由数学关系描述的设备动态特性、设备参数、(一个或多个)输入、和(一个或多个)输出。传感器和致动器块916和920中的每一个都提供以下设置选择：设备数；设备/设备模型的类型；和设备系数。注意，由于在函数中内置有噪声和非线性，所以可以列出它们的参数以及其它设备系数。

从算法窗格906中的设备块916和920中的下拉列表948中选择设备。在对设备进行选择时，在相应的设备块中列出特定于设备的参数、也称为系数950。缺省值通常被紧接在系数描述之后列出。系数值是可编辑的。如果任何值被编辑，则Save和Cancel按钮就被激活。要恢复到上次保存的值，点击Cancel按钮。要保存输入值，则点击Save按钮。这些操作中的任何一个会使按钮禁用，直到进行下一次编辑。注意，如果Save和Cancel按钮是活动的，即如果在相应设备块中有任何未保存的系数，则不会执行新的仿真。APCATS 900的允许若干设备单元并行运行的能力允许同时仿真多个传感器或泵。

为了实现多个同时发生的单元，用户必须在设备菜单的右上数量选项卡(tab)952中输入单元的预期数量，其表示多少控制通道处于工作中。每个单元将具有其自身的设备表格，其可以通过左上方的已编号的选项卡954来选择。当前选择的设备的已编号的选项卡954将被高亮。用户可以在这些表格中的每个上编辑系数950。设备数量的增加将在下拉列表948的末尾添加新设备。同样，减少将会从该列表948的末尾去除设备(即较高编号的设备)。如果用户决定在保存表格之前切换到另一个选项卡，则将向他提示保存该表格并且在继续之前必须保存或取消修改。用户可以随时改变选项卡和设备的数量。如果他输入了超过设备的预定义最大数量的数，则该数将回复为在先值。任何时候当设备被改变时，之前存在的针对该设备的输入和输出连接都被破坏。在运行仿真之前，用户必须在设备与提供其输入和接受其输出的模块之间建立新的连接。类似地，对于任何新添加的设备也必须建立连接。注意，在不需要检查参数是否需要被保存或丢弃的情况下切换设备的能力尚未被完成。目前，APCATS 900丢弃从上次保存以来所做的任何改变。

设备块916和920可以在两种模式下工作：(1)无故障模式，其为正常无中断的设备工作，和(2)故障模式。故障模式允许仿真设备中断，即把设备输出冻结为破坏状态，而其它子块(sub-block)继续正常工作。在故障结束时，设备通过重新初始化自身来恢复。可以通过指定哪个设备发生故障、其所经历的故障的类型以及故障持续时间来计划故障。为了实现故障保护/故障模式以及允许计划故障，用户选中故障模式按钮958左边的复选框956。如果控制器块918上的测试台模拟器(APSe)按钮962的复选框960已经被选中，则该故障模式复选框956被自动选中且被禁用，从而使其不能被改变。如果在控制器块918上没选中用于该测试台模拟器按钮962(其是所模拟的(仿真的)APS)的复选框960，则用户可以使用故障模式复选框956来选择故障保护/故障模式。如果故障模式被激活，则创建指示故障类型的附加输出。缺省地，0(零)值表示正常设备工作。

为了计划故障，用户点击相应设备块916或920上的故障模式按钮958(如果故障模式已被激活)。相应的设备故障菜单964窗口将打开，其在图25中为传感器故障菜单窗口。由于致动器故障菜单窗口是类似的，因此仅讨论故障菜单窗口964。该故障菜单窗口964包含用于不同预定义故障的按钮966。点击这些按钮966以将故障输入到故障计划968中。该计划列出了用于所选择的故障模式的各种参数，其中一些是可编辑的。参数是：“Nos.(序号)”970、“Failure Mode(故障模式)”972、“Tab Nos.(选项卡序号)”974、“Failure Start Time(故障开始时间)”976、“Failure End Time(故障结束时间)”978，和“Association(关联性)”980。“Nos.”参数970是故障条目的序列号。“Failure Mode”参数972是故障的名称，而“Tab Nos.”参数974是要将故障分配给的设备的选项卡序号。设备必须存在以便该故障发生作用)。“Failure Start Time”参数976是以日、小时、和分钟计的开始时间。任何非数字的字符都可用于分离数字。如果仅输入了单个数字，则它被假定为表示分钟。如果输入了两个数字，则它们被假定为表示小时和分钟。“Failure End Time”参数978是以日、小时、和分钟计的结束时间。该输入数字的解释遵循与用于开始时间相同的模式。

“Association”参数980用于捕获注释。当故障按钮被点击时，故障序号和名称被输入。这些字段是不可编辑的。如果未输入开始时间，则该故障决不会被启动。如果输入的开始时间早于结束时间，则故障在开始时间开始，且在结束时间截止。如果该开始时间大于或等于结束时间，则该故障在开始时间开始并一直持续直到仿真时间的结束。故障菜单窗口964还在底部具有命令行按钮982，其是：“Reorder(重排序)”，其按照开始时间的升序重新排序所述故障；“Save(保存)”，其保留任何被改变的值；“Cancel(取消)”，其恢复上次保存的值；“Help(帮助)”，其打开帮助窗口；和“Close(关闭)”其保存任何改变并且关闭该窗口。该Save和Cancel按钮仅当该计划上的任何信息自从上次被保存后已经被改变时才被激活。故障菜单窗口964上所示的其它项是显然的。

控制器

控制器块918与装置块914相似。它将所有可用的控制器作为单选按钮选择列出，以允许一次仅能选择一个。为了选择控制器模型，点击模型的单选按钮984。要注意的是，由控制器模块来控制和纠正自动护理，该自动护理将使患者对于外部激励的可变影响保持稳定。这是通过以连续方式正确管理用药来实现的。虽然APCATS 900提供将被试验的标准控制算法的列表，但是它还有引入用户定义的控制器的选项。基本的思想是：提供一个即插即运行控制器(plug-in-and-run-the-controller)类型的情形。该选项可以看做如下：控制器1(修改参数)；和控制器2(修改参数)…；和控制器n(修改参数)。在选择控制器模型之后，将出现控制器参数窗口。由于控制器参数窗口与装置菜单922(图24)相似，所以不示出该控制器参数窗口并且也不提供对于如何调整所列出的控制器参数的进一步论述。每当控制器被改变时，在先存在的输入和输出连接都被破坏。在运行仿真之前，用户必须建立控制器与提供其输入和接受其输出的模块之间的新的连接。

测试台模拟器

在控制器块918(图22)中选中复选框960将激活测试台模拟器按钮962，该按钮在被点击时引出测试台模拟器窗口986(比如如图26所示)。测试台模拟器窗口986用于将干扰链接到事件类型。测试台模拟器窗口986上半部处包含事件类型按钮990，其被分组为四列。给定列中的按钮990与事件的相同特定方面相关，并且表示可以被触发的事件函数。每个按钮990都与通过干扰模块而被定义的干扰相关联。点击这些按钮990之一将把相应的事件(称为被触发的事件)输入到事件计划992中，其中事件计划位于该窗口的下部。事件计划992是包含如下内容的时间表：事件(干扰)被计划为何时发生、它们的持续时间以及大小。为了将干扰与该计划中的事件相关联，用户首先左键点击干扰以将其选中。该行将变为黄色的高亮。接着，点击按钮990中的相关联的之一以将事件类型输入到该行中。然后用户继续输入该行中的剩余值。

在被触发时，所触发的事件仅仅作用于在装置块914(图22)中所选中的所选患者模型。通过将干扰与合适的被触发事件相关联来使控制器块918得知该干扰。在“事件列表”列之下列出的被触发事件具有若干性质：触发时间，其被示出为“Event Start Time(事件开始时间)”；“Event type(事件类型)”；相对触发时间，其被示出为“ALGO Action Time(ALGO操作时间)”；事件的持续时间，其被示出为“Action Span Time(操作跨度时间)”；以及“Amount(量)”。Event Type是算法所使用的事件代码。其可以通过点击Event Type按钮之一或者输入相应的代码(在该按钮的括号中给出)而被输入。相对触发时间是相对于事件在物理上发生的时间而言的，其中该控制器块918(即ALGO 500)得知被触发事件。控制器块918可以在如下时间被告知该发生：(a)在实际事件发生以前(负数)；(b)在该事件发生的同时；(c)在实际事件之后的某个时间(正数)。事件的持续时间被用于选择事件在被触发以后保持活动的持续时间。事件量被用于选择事件的大小(magnitude)。

测试台模拟器窗口986的底部包括命令菜单按钮994。按钮994和其功能如下。“Patient Ini”显示初始化文件PatientIni的路径和名称。“PatientIni”文件包括该控制器(例如APS 500)所使用的患者参数。“ExperimentDirectory(实验目录)”显示数据将会存在于的目录的位置，并且“Save(保存)”保存值并将值更新到当前改变。“Cancel(取消)”拒绝改变并且重新加载上次保存的值，而“Help(帮助)”显示帮助屏幕。“Close(关闭)”保存任何经过更新的值并关闭该窗口。如果需要，也可以提供刷新按钮。

外部干扰

外部干扰块912(图22)提供对由过着正常和健康生活的人所预期的对于碳水化合物消耗、体力活动以及其它活动的响应进行仿真的方式。对于能够过正常生活的糖尿患者而言，必须调节他的或她的身体机能以应付这样的干扰/激励。闭环系统的鲁棒性、有效性、以及稳定性通过调查如下内容来评估：(1)模型参数值在工作范围内的改变以及(2)外部干扰/激励的所有可能的情况。点击APCATS主窗口902上的外部干扰块912，将显示如图27所示的外部干扰菜单窗口996。如图27所示，在名称标明“SELECT DIETCUM EXERCISE OPTIONS”之下提供有一组预定义的激励函数按钮998。通过编写新的函数(如将在后面部分中描述的)以及修改初始化文件DietInit来容易地在列表中引入附加的激励函数。选项可用于测试各种场景、标准的测试用例集、或者任意的用户范例。这些通过使用干扰函数以及计划其发生来加以建立。

按钮998可以被激活或者禁用，由于可供选择的干扰取决于所选的患者(装置)模型。因此，对于给定的患者模型，仅有针对该患者模型定义的干扰被激活并且可供选择。干扰可以以任意的顺序被输入。外部干扰菜单窗口996还提供外部干扰计划1000以设置仿真的长度。外部干扰计划1000以列的形式列出如下项目：干扰的数目；干扰的名称；缩放强度(scale strength)；开始时间；结束时间；以及关联性。干扰的数目和名称是不可编辑的，而是在干扰选择按钮被用于将干扰输入到表中时被设定。缩放强度值允许用户根据某因子来缩放输出值。缺省缩放值1指示标定的干扰。由于计划1000的剩余列在其将干扰(激励)计划为发生在仿真期间内的用法方面类似于测试台模拟器窗口986(图26)的计划，因此不提供对其的进一步论述。此外，由于外部干扰菜单窗口996底部的命令菜单按钮1002同样类似于在故障菜单952上所提供的那些按钮，因此也不提供进一步的论述。

干扰输出与装置参数的相互链接(interlink)

通常，外部激励驱动装置参数以及到该装置的输入。在该特定情况下，每个干扰函数都被认为是具有包括如下项目的输出的模块：(1)需要被连接到装置块914的输出；以及(2)与装置参数处于一一对应的干扰参数。(一个或多个)干扰输出加上来自干扰的参数输出被传递而成为装置模型的输入和参数。然而，当多个干扰同时发生时，存在重要的考虑因素。多个干扰函数的效应通过把来自所有干扰的输出相加而被叠加以形成单个向量式(vectored)输出，所述向量式输出成为到装置块914的输入。为了能够实现该点，所需要的是：在干扰模型当中，每个干扰输出在输出数量和其顺序方面都与其它干扰输出一致。然而，从干扰块912的角度来看，不存在对输出数目或者其顺序的约束。另一方面，参数输出必须在顺序方面以及数目方面与所选装置达成一致。当多个干扰同时作用时，与上述输出不同，未使所述参数相加，而是解析根据每个干扰而设置的参数，并且确定单个参数值集合。管理该情形的函数是过滤函数。

在将外部干扰输入到外部干扰菜单窗口996中以后，过滤函数从所选的患者模型中得到参数的数目。所有饮食的工作状态(工作＝1，不工作＝0)与来自所述饮食的参数值相复用(multiplex)。通过使用下面的逻辑来计算饮食的数目：饮食的数目＝输入向量的长度/(1+参数长度)。外部干扰的所输入的开始和结束时间成为该函数被激活的时间以及其停止的时间。描述该饮食的数学函数不依赖于开始时间。至于结束时间，该函数可以具有设定的时间过程并且在这种情况下，存在几种处理结束时间的方法。通常，该函数是微分方程，其中其所有的初始条件和参数都在该函数中被描述。函数行为(behavior)是归一化的响应。由在“Scale Strength(缩放强度)”列下面的事件计划1000中所提供的所输入的缩放值来缩放输出。尽管通常期望正的缩放值，但是可以输入负值以仿真负的效应。

连接端口表格

点击APCATS主窗口902中所示的连接线，将引出连接端口表格1004，其由图28示出。在其左侧，连接端口表格(Connect Ports form)1004列出可用的输出1006并对其编号。输出1006由发送信息的块生成。右侧显示接收信息的块的输入1008以及空的编辑框。为了创建特定输出1006与特定输入1008之间的连接，用户将对应于所述输出的数字键入到与将接收所述输出的输入字段(input field)相邻的编辑框中。任何未被连接到输出1006(即具有空白的编辑框)的输入1008都被设定为零。还要注意，输入1008不能被连接到一个以上的输出1006。不必将每个输出都连接到输入。该仿真将为所有列出的输出生成数据，但是被留为未连接的那些输出将简单地未被用作到下一模块的输入。可以将输出连接到一个以上的输入。在完成所有期望的连接以后，点击右上角中的“X”(关闭窗口)按钮以保存所述连接并关闭该表格。

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

APCATS主窗口902的运行/存储窗格904(其被图29放大)提供用于加载数据、保存数据、以及运行仿真的基本功能。此外，其显示实验设置，允许用户输入实验摘要，并且最后允许用户从APCATS 900退出。运行/存储窗格904最左边的列显示在启动条目(Startup Entry)表格1010(图32)中所制订和修改的条目。其从上到下显示的三条信息是：用户姓名、实验组、以及实验标识数字；以及使用中的范例(静脉注射-静脉注射，皮下注射-皮下注射，静脉注射-皮下注射)。为了输入关于该实验的细节和注释，点击输入实验摘要(Enter Experiment Brief)按钮1012。这样做将引出“APCATS 900-添加关于当前实验的细节”窗口(未示出)。被输入到该窗口中的信息被存储在实验的文档(doc)文件中。该信息可以被更新任意次。

为了编译当前的APCATS 900设置并且将其保存，用户点击查看状态(View Status)按钮1014。在这样做之后，所述状态信息被写到临时位置(工作区)并且被显示在编辑器中。为了保存对文件的输入变量的当前设置，用户点击保存Cum文档运行(Save Cum Document Run)按钮1016。还保存在查看状态按钮1014被点击时所显示的设置文档。为了重新创建实验所需的当前初始化设置被写到工作区中的临时文件。如果APCATS 900发生故障，则通过点击启动条目表格(图32)上的Old按钮1015、并且在所列出的文件目录中搜索暂时归档(filing)可以恢复保存在该文件中的设置。为了在任何时间引出启动条目表格1010，点击STARTUP FORM按钮1018。启动条目表格1010(图32)用于编辑为了定义实验范围并保持合适的记录所需的细节。为了退出APCATS 900，点击“EXIT APCATS”按钮120。“从APCATS退出”对话框(未示出)出现，其允许用户返回到APCATS 900并取消退出命令。点击继续(Continue)按钮将进行关闭应用。在关闭主APCATS窗口900以前，其将关闭所有的APCATS生成的窗口。

为了开始仿真，用户点击开始仿真(Start Simulation)按钮1022。这样做将引出图30所示的仿真参数(Simulation Parameters)窗口1024。仿真参数窗口1024允许用户设定仿真的开始和结束时间、选择积分例程和步长、以及运行仿真。大多数栏都是不言自明的。缺省地，仿真运行开始于时间0。输入非零值提供与开始时间的偏移。为了设定仿真运行的结束时间，用户将值输入到停止时间(Stop Time)文本框中。停止时间必须大于执行仿真的开始时间。为了设置将被用在仿真中的积分例程，用户从求解程序(solver)下拉菜单1026中选择该例程。为了设置积分步长，用户从步长下拉菜单1028中选择步长。对于保存数据的时间段，用户输入数据保存之间的时间段。相对公差是一种积分收敛判据。绝对公差也是一种积分收敛判据。用户从下拉框1030中选择值以设置将在仿真期间被显示的时间窗。可用的选择是：每小时、每四分之一天、每半天或者每天、以及整个仿真。对于Simulink模型文件名称，被定义在init文件中的标记控制用户是否能够重命名仿真模型文件。如果被授权，则用户可以在Simulink Model Name editbox(Simulink模型名称编辑框)中输入Simulink文件的名称。仅仅针对BuildModel(建立模型)，被定义在init文件中的标记控制用户是否可以建立并查看模型。如果被授权，则用户可以点击Build Model按钮1032以建立Simulink模型，对于该Simulink模型，文件名被输入到Simulink模型名称文本框(Simulink Model Name text box)中。用户然后可以通过打开模型(mdl)文件来查看该模型。

仿真运行

为了开始仿真，用户点击开始按钮1034。点击该按钮将触发如下操作：创建并保存文档和初始化文件；设定参数研究环；创建并仿真Simulink块图表；并且保存所产生的数据。针对系统的(S)或探索的(E)实验，生成实验标识数字，并且将适当命名的数据文件保存到系统目录。如果在此处存储文件有问题，则取而代之，它们被移动到暂停(parked)数据目录，该目录通常位于用户的本地硬盘驱动器上。对于运转(play)(P)组中的实验，用户被请求提供实验标识数字。对于系统的(S)或者探索的(E)实验，记录信息被添加到被保持在网络驱动器上的记录文件中。点击继续按钮1036将从已经完成的状态继续仿真以扩展该仿真。点击暂停/重新开始按钮1038将使正在运行的仿真暂停或者重新开始被暂停的仿真。为了停止正在进行的仿真，用户点击停止按钮1040。如果仿真被用户停止，则将不保存来自该部分仿真的数据。这防止了创建不完整的数据集。仿真时钟(SimulationClock)显示仿真时钟时间。这允许用户监测仿真的进程。当前/总运行序号(Current/Total Run Nos.)以十六进制记数法显示当前的运行序号和实验的总运行序号。

在仿真运行以后，APCATS 900将生成输出。如下的选项对用户可用：生成性能度量；在仿真前决定将生成和保存什么样的输出；生成所有可能的输出并且之后决定将保存什么样的输出；生成并存储所有输出；使输出可视化；以及将输出保存到以ASCII、二进制格式、或者任意其它数目的合适电子格式的文件中。以二进制形式保存数据具有的优点是简洁，但是数据的传输变得受限。另一方面，保持ASCII数据文件使其处于可读形式，并且还使其可以容易地传输给其它软件以进行进一步的数据分析。

绘图窗格(Plot pane)

APCATS主窗口902的绘图窗格908允许用户在屏幕上用图形表示实验数据或者将其作为硬拷贝，并且该绘图窗格由图31放大。运行序号(RunNumber)控制1042具有两个目的：(a)在仿真期间，其显示当前正在被仿真的实验运行的序号；以及(b)在仿真之外，其被用于选择数据将被绘图所针对的(一个或多个)运行序号。运行序号被以十六进制形式显示。为了在选择将被绘图的数据时选择多个邻近的运行，用户在按住shift键的同时使用鼠标左键来选择将被绘图的运行范围的第一和最后一个序号。为了选择多个离散的运行，在按住Ctrl键的同时使用鼠标左键来点击将被绘图的各个运行序号。最小(Min)和最大(Max)控制1044和1046分别以十六进制的形式显示最小和最大运行序号。滑动块1048提供选择将被绘图的运行序号的可替换方法。该滑动块的左端和右端分别表示最小和最大的运行序号。

绘图平面908可以被分解成较小的按行和列排列的子绘图。为了选择行的数目和列的数目，用户将所期望的值输入到Nos.of Rows(行数)和Nos.of Columns(列数)文本框中。例如，输入2作为行数以及3作为列数将创建六个子绘图，2行中每行三个。一旦子绘图的数目被建立，则用户选择将被显示在每个子绘图上的信息。为了设置给定的子绘图，用户从选择子绘图(Select Sub-Plot)下拉框1050中选择子绘图。所述子绘图使用矩阵表示法而被列出，其中括号中的第一数字表示子绘图的行，而第二数字表示列。对于每个子绘图，将所需信息输入到选择子绘图下拉框下面的控制中。

为了设定x轴的标签，用户在标签X轴(Label X-Axis)文本框中输入标签。如果该文本框被留为空白，则所选自变量(x)的名称将被用作标签。用户从位于标签X轴控制下面的下拉菜单1052中选择自变量，其中将按照所述自变量来对数据绘图。可以为每个子绘图选择不同的自变量。缺省选择是时间。

为了设定y轴的标签，用户在标签Y轴(Label Y-Axis)文本框中输入标签。如果该文本框被留为空白，并且只有一个自变量(y)被选择，则所选变量(y)的名称将被用作标签。如果该文本框被留为空白并且一个以上的自变量被选择，则y轴标签将是“＊＊＊”。用户选择因变量以根据就位于Plot It按钮之上的列表框1054进行绘图。为了选择多个邻近的变量，用户按住shift键的同时使用鼠标左键来选择该范围内的第一变量和最后的变量。为了选择多个离散的变量，用户按住Ctrl键的同时使用鼠标左键来点击各个变量。可以为每个子绘图选择多达五个因变量。所选变量将在选择列表之上的文本框中列出。

一旦已经输入了用于每个子绘图的参数，则所述绘图可以被显示和打印。绘图在仿真已经结束运行以前不能被创建。然而，可以对来自前面的仿真的数据进行绘图。为了在屏幕上显示(一个或多个)绘图，用户点击PlotIt按钮1056。绘图窗口将出现，显示图形。为了创建所述绘图的打印的(硬)拷贝，用户点击打印按钮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

function[DIET_TYPE，DIET_FUN]＝DietInit％List Descriptive Titles and then function names％First all Diet DescriptorsDIET_TYPE＝{…′Balanced Diet′         ％1′Sweet Diet′            ％2′Carbohydrates′         ％3′Beverage′              ％4′Alcoholic Drink′       ％5′Cardio Exercise-Steady′％6′Cardio Exercise-Ramp′  ％7′Cardio Exercise-Hectic′％8′Heavy Weight′          ％9′Mental Stress′}；      ％10％Location of the corresponding diet function files％Each column corresponds to a particular model type％The order is col#1 corresponds to model#1 listed in ModelInit file％col#2corresponds to model#2listed in ModelInit file％…and so on％If a row has quotes with no character within，it signifies that％corresponding DIET_TYPE row is not availableDIET_FUN＝{…′diet1m1′，′diet1m2′，′diet1m3′    ％1′diet2m1′，′diet2m2′，′diet2m3′    ％2′diet3m1′，′diet1m2′，′diet1m3′    ％3′diet4m1′，″，′diet1m3′         ％4′diet5m1′，′diet1m2′，″         ％5″，′diet1m2′，′diet1m3′         ％6′diet7m1′，″，′diet1m3′         ％7′diet3m1′，′diet1m2′，′diet1m3′％8′diet6m1′，′diet1m2′，″         ％9′diet7m1′，′diet1m2′，′diet1m3′}；％10

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 fiesSENSOR_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 Descri ptive 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％Initialization 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′；ACTFAIL_TYPE{4，1}＝′Battery Low′；ACTFAIL_TYPE{5，1}＝′Pause′；％Use Flag Definition File(C:\testbed\FlagDefFile)to map％above descrriptorsACTFAIL_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 disrurbance 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，para1)This is a template.You may add sub functions or functions to implenent 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 Conditions

x0＝[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％para1 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’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 VA RIABLES’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)swi tch 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 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，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 (35)

1.一种用于在计算机上提供慢性病患者的医学诊断、治疗以及预后的计算机化的方法，该方法包括：

在该计算机上指定一个或多个方案，所述方案针对该患者的特定诊断和治疗需求；

在该计算机上指定患者模型；

在该计算机上执行分析以确定该患者模型的参数；

在该计算机上执行对所述参数的模型验证以进一步保证该患者模型已经捕获了适当的动态特性，所述动态特性针对该患者的特定诊断和治疗需求；

应用按照所述一个或多个方案所采集的数据以使用该患者模型在计算机上执行分析，以提供至少一种推荐的特定于患者的治疗；以及

在该计算机上提供该推荐的特定于患者的治疗以供批准。

2.根据权利要求1所述的计算机化的方法，进一步包括：调整该推荐的特定于患者的治疗。

3.根据权利要求1所述的计算机化的方法，进一步包括：在计算机上定义和实施测试场景，其帮助测试所述推荐的特定于患者的治疗，并且对使用所述推荐的特定于患者的治疗可能获得的治疗质量进行量化。

4.根据权利要求1所述的计算机化的方法，进一步包括：在计算机上定义和实施测试场景，其帮助执行参数的模型检验。

5.根据权利要求1所述的计算机化的方法，进一步包括：提供多个推荐的特定于患者的治疗，以及对照多个临界测试场景来测试所述推荐的特定于患者的治疗，以及评价预期的治疗结果以基于所述推荐的特定于患者的治疗中的所选择的一种治疗来提供预后。

6.根据权利要求1所述的计算机化的方法，进一步包括：执行数学分析以评价稳定性、灵敏度、鲁棒性，并且提供对所述推荐的特定于患者的治疗的置信度的指示。

7.根据权利要求1所述的计算机化的方法，进一步包括：通过仿真特定测试用例来确认所述患者模型的动态特性，以对照文献数据和临床数据中的至少一个来评价动态响应。

8.根据权利要求1所述的计算机化的方法，进一步包括：提供数学分析工具、可视化工具、以及数据呈现工具以帮助在该计算机上执行所述分析。

9.根据权利要求1所述的计算机化的方法，进一步包括：提供仿真环境以在该计算机上定义和实施测试场景，其帮助执行参数的模型检验。

10.根据权利要求1所述的计算机化的方法，进一步包括：在便携式单元上实施所述推荐的特定于患者的治疗。

11.根据权利要求1所述的计算机化的方法，进一步包括：按照所述一个或多个方案从患者数据采集设备采集数据。

12.根据权利要求1所述的计算机化的方法，进一步包括：在该计算机上使用算法来管理：数据的采集、执行对所述数据的分析、将所述数据应用到患者模型、以及提供所述推荐的特定于患者的治疗。

13.根据权利要求1所述的计算机化的方法，其中所采集的数据包括事件活动和生理测量结果中的至少一个，其更新对于所提供的所述推荐的特定于患者的治疗的分析。

14.根据权利要求1所述的计算机化的方法，进一步包括：批准所述推荐的特定于患者的治疗作为处方，并且在该计算上使用算法来管理所述处方的计划、控制、以及监测。

15.根据权利要求1所述的计算机化的方法，进一步包括：批准所述推荐的特定于患者的治疗作为处方，并且在该计算上使用算法来开环控制利用便携式设备的处方实施，其中所述便携式设备直接给患者提供对所述处方的管理。

16.根据权利要求1所述的计算机化的方法，进一步包括：批准所述推荐的特定于患者的治疗作为处方，并且在该计算上使用算法来闭环控制利用便携式设备的处方实施，其中所述便携式设备直接给患者提供对所述处方的管理。

17.根据权利要求15所述的计算机化的方法，进一步包括：所述算法命令所述便携式单元根据所述处方来配给用药并执行测量任务。

18.根据权利要求16所述的计算机化的方法，进一步包括：所述算法命令所述便携式单元每次以给定的输入特性来配给用药并执行测量任务，并且使用所述输入特性来更新该算法。

19.根据权利要求1所述的计算机化的方法，进一步包括：在客户端服务器计算机系统环境中提供权利要求1。

20.一种在计算机上评价特定患者中的药代动力学效果和治疗功效的计算机化的方法，该方法包括：

向该计算机提供患者数据，所述患者数据包括关于该患者的代谢信息、生理信息、以及生活方式信息；

在该计算机上对所述患者数据执行有效性检验以提供经过验证的数据；

在该计算机上使用一个或多个患者模型分析所述经过验证的数据以使疾病发展量化，以通过考虑所述代谢信息、生理信息、以及生活方式信息来确定适合于该患者的治疗，并确定治疗预后；以及

提供所述适合的治疗和治疗预后。

21.根据权利要求20所述的方法，其中所述一个或多个患者模型包括生理模型、代谢模型、以及数学以用于基于药物的药代动力学和药效学来确定药物剂量。

22.根据权利要求20所述的方法，其中所述治疗预后包括特定操作是否将具有不利的或者期望的效果。

23.一种用于提供慢性病患者的医学诊断、治疗以及预后的计算机化的系统，该系统包括：

采集方案和患者模型的数据采集；

第一软件模块，其用于测试按照所述采集方案之一所采集的数据的完整性和准确性；

第二软件模块，其用于利用所述患者模型中的至少一个来分析所采集的数据，以表征该患者的特定代谢需求；以及

第三软件模块，其在对该患者的诊断中使用所表征的患者的特定代谢需求，以确定特定于患者的治疗和提供所述特定于患者的治疗的预后。

24.根据权利要求23所述的计算机化的系统，进一步包括第四软件模块，其提供工具来定义与该患者的所表征的特定代谢需求一致的处方，并且评估保证该特定于患者的治疗的稳定性和鲁棒性的临界场景。

25.根据权利要求23所述的计算机化的系统，进一步包括测试台程序，其提供仿真环境，所述仿真环境用于定义和实施帮助测试推荐的特定于患者的治疗的测试场景，并且对使用所述推荐的特定于患者的治疗可能获得的治疗质量进行量化。

26.根据权利要求23所述的计算机化的系统，进一步包括测试台程序，其提供仿真环境，所述仿真环境用于定义和实施帮助执行参数的模型检验的测试场景。

27.根据权利要求23所述的计算机化的系统，进一步包括测试台程序，其提供仿真环境，所述仿真环境用于仿真特定测试用例以对照文献数据和临床数据中的至少一个来评价所述患者模型的动态响应。

28.根据权利要求23所述的计算机化的系统，进一步包括实施特定于患者的治疗的便携式单元。

29.根据权利要求23所述的计算机化的系统，进一步包括患者数据采集设备，其按照所述采集方案中的一个或多个来采集数据。

30.根据权利要求23所述的计算机化的系统，其中所采集的数据包括事件活动和生理测量结果中的至少一个，其被算法使用以更新针对所提供的特定于患者的治疗的分析。

31.根据权利要求23所述的计算机化的系统，进一步包括算法，其管理特定于患者的治疗的计划、控制和监测。

32.根据权利要求23所述的计算机化的系统，进一步包括算法，其开环控制利用便携式设备的特定于患者的治疗的实施，其中所述便携式设备直接给患者提供对特定于患者的治疗的管理。

33.根据权利要求23所述的计算机化的系统，进一步包括算法，其闭环控制利用便携式设备的处方实施，其中所述便携式设备直接给患者提供对特定于患者的治疗的管理。

34.根据权利要求23所述的计算机化的方法，进一步包括便携式单元，其用于在被算法命令时遵循特定于患者的治疗来配给用药并执行测量。

35.根据权利要求23所述的计算机化的方法，进一步包括便携式单元，其用于在被算法命令时遵循特定于患者的治疗来执行操作，所述操作包括配给用药和执行测量，每个操作在被执行时提供给定的输入特性，以更新该系统中的、用于控制和监测特定于患者的治疗的应用的算法。

Images