CN116209385A - 用于心力衰竭患者的治疗性管理的组合物和方法 - Google Patents

Abstract

本文公开了用于管理和施用用于心力衰竭患者的治疗性治疗方案的系统和方法。在一些实例中，这包括使用可佩戴心率传感器监测患者的心率和心电图以向决策树模型中提供输入，以提供有效的治疗方案。此外，可以将常规血压测量值输入到所述模型中。所述系统可以另外地基于患者对先前施用的治疗物的响应通过各种心力衰竭治疗物进行迭代。

Description

用于心力衰竭患者的治疗性管理的组合物和方法

相关申请的交叉引用

本申请要求2020年9月4日提交的题为“COMPOSITIONS AND METHODS FORTHERAPEUTIC MANAGEMENT OF HEART FAILURE PATIENTS”的美国临时申请第63/074,805号的优先权，该临时申请的内容通过引用方式并入本文。

技术领域

本说明书涉及用于管理心力衰竭患者的心力衰竭治疗的组合物、系统和方法。

背景技术和发明内容

以下说明书包括可能有助于理解本发明的信息。并不是承认本文提供的任何信息是现有技术或与目前所要求保护的发明有关，也不是承认具体地或隐含地引用的任何出版物是现有技术。

尽管不断努力和开发治疗心力衰竭(HF)的新治疗剂，但HF的患病率在全球范围内还是有所增加并继续增加。进一步地，自2011年以来，与心力衰竭相关的总体死亡率有所上升。

进一步地，随着新型药物治疗剂的数目不断增加，以及处于不同开发阶段的研究性治疗剂越来越多，包括HF治疗剂的处方和管理在内的临床决策制定变得越来越具有挑战性和耗时。

此外，当临床医生未能启动或加强循证疗法(evidence-based therapy)或未能在其患者中达到规定的目标(诸如，血压或血糖)时出现的临床惯性会降低HF临床结局的潜在改善。

由于上面提到的因素中的至少一些因素，尽管用于降低HF相关死亡率的新HF疗法正在被开发并且被批准使用，但总体的HF相关死亡率和/或住院率似乎并未下降，而且可能正在增加。

本文中发明人已经识别出了上面提到的问题，并且已经开发了用于至少部分地解决上面提到的问题中的一些问题的系统和方法。因此，提供了用于确定和管理HF治疗剂的治疗方案的系统和方法。在一个实例中，方法包括：从一个或多个生理传感器获取患者的生理传感器数据；接收参考该患者的患者概况，该患者概况包括治疗剂量方案，该治疗剂量方案包括至少一种治疗剂和相关剂量；使用模型处理生理传感器数据以修改治疗剂量方案并输出经更新的治疗剂量方案；以及向患者施用经更新的治疗剂量方案。

以这种方式，通过使用远程监测数据和患者数据不断评估和更新HF患者的治疗方案，以改进的效率实现给定HF治疗剂的目标剂量，从而改善HF患者的临床结局并降低住院和死亡风险。

作为一个实例，临床医生可以开具使用数字治疗决策引擎的处方来评估和/或管理心力衰竭患者的治疗方案。在监测期期间，该决策引擎可以从患者的电子健康记录(EHR)和一个或多个远程监测设备(例如，可佩戴设备和/或非可佩戴设备)接收患者数据输入。使用患者数据和远程监控数据，该决策引擎可以确定患者是否稳定到足以改变他或她的药物的程度。如果患者在临床上稳定，该决策引擎可以确定是否需要临床医生输入，并且如果不需要，该决策引擎可以自动地提供更新以以相关剂量启动至少一种药物或者改变(例如增加或减少)至少一种其他药物的剂量或者停用至少一种其它药物以及/或者检查实验室。

在一些实例中，如果决策引擎启动药物或改变治疗方案中的药物剂量或停用药物，则患者可能会接收到就作出决策的根本原因教育患者的信息和请求患者认收的通知中的一者或多者。一旦获得批准并且进行了药物改变，来自可佩戴设备的数据和/或经由嵌入在患者侧应用程序中的患者问卷输入的患者响应可被用于监测患者是否在患者响应监测期内有任何药物副作用和/或不耐受。

以这种方式，剂量滴定期间的持续远程监测可确保在患者稳定时启动药物、作出改变和/或更新剂量，并且监测患者的药物副作用以便能够快速地检测到它们。如果检测到一种或多种副作用和不耐受，决策引擎的安全性决策组件可被执行，其中安全决策组件基于肾功能、高钾血症、低血压和/或心动过缓的阈值评估治疗方案，并且提供为了停用或减少药物(例如，启动的药物)的剂量而对治疗方案进行的更新。在一些实例中，可能会提供建议，该建议然后在临床医生批准后被更新。

以这种方式，本文描述的方法和系统合并从远程患者监测设备导出的数据，以确定有效的治疗性治疗方案或修改现有方案或维持现有方案，或启动一个或多个实验室测试程序。进一步地，通过在更新治疗方案之前以及之后监测患者，并根据患者响应调整药物，高效地执行了定制的个性化的心力衰竭疗法。因此，HF患者的患者结局得到改善，从而降低了死亡风险和住院率。

作为另一个实例，决策引擎可以处理由可佩戴心率监测器收集的心率数据以输出新的或经修改的治疗性治疗方案。这可能包括在一段时间(例如1、2、3、4、5或6小时、天、周)内对平均心率进行监测，这在临床访视中是不可能的。因此，纵向心率、心电图和血压数据的利用将允许递送可降低患者群体中的死亡率的治疗性治疗方案。因此，公开了用于基于来自可佩戴心率监测设备的反馈和血压袖带测量结果等其他输入数据来确定和实施治疗剂量方案的系统和方法。

应当理解，提供以上发明内容是为了以简化的形式介绍具体实施方式中进一步描述的一些概念。这并不意味着识别所要求保护的主题的关键或基本特征，所述主题的范围由具体实施方式后的权利要求唯一地限定。此外，所要求保护的主题并不限于解决上文或本公开的任何部分中指出的任何缺点的实施方式。

附图说明

并入本专利说明书并且构成本专利说明书的一部分的附图举例说明了本发明的实施方案，并且连同具体实施方式一起用来解释和说明本发明的原理。附图意图以图解方式说明示例性实施方案的主要特征。附图并非意图描绘实际实施方案的每个特征或所描绘元件的相对尺寸，并且未按比例绘制。

图1示出根据本公开的实施方案的用于管理被诊断患有心力衰竭的患者的治疗方案的系统的实例的示意图；

图2示出根据本公开的实施方案的用于基于来自一个或多个生理传感器的输入和来自患者的健康记录的患者数据来管理患者的治疗方案的示例方法的高级流程图；

图3示出根据本公开的实施方案的用于基于患者稳定性管理患者的治疗方案的示例方法的高级流程图；

图4A示出根据本公开的另一个实施方案的用于基于患者稳定性管理患者的治疗方案的示例方法的高级流程图；

图4B是图4A的延续；

图5示出根据本公开的实施方案的用于基于患者响应更新治疗方案的示例方法的高级流程图；

图6A示出根据本公开的实施方案的用于在患者稳定时管理患者的治疗方案的示例启动和给药引擎的高级流程图；

图6B是图6A的延续；

图6C是图6B的延续；

图6D是图6C的延续；

图7示出用于在患者的稳定性小于稳定性阈值时以及/或者在监测患者对经更新的治疗方案的响应时管理患者的治疗方案的示例安全性决策引擎的高级流程图；

图8A和图8B示出根据本公开的各种实施方案的示例临床医生界面，包括从患者的健康记录获取的示例患者数据、示例建议/更新以及示例警报；

图9A和图9B是针对心力衰竭患者给出的示例治疗物(therapeutics)和不同水平的表格；

图10A和10B示出在患者治疗方案的相应更新期间为患者生成的示例输入、示例决策状态指示和示例输出；以及

图11A至图11C示出在患者治疗方案的相应更新期间为另一名患者生成的示例输入、示例决策状态指示和示例输出。

在附图中，为了易于理解和方便，相同的附图标记和任何首字母缩略词标识具有相同或相似结构或功能的元件或动作。为了轻松识别任何特定元件或动作的讨论，附图标记中的一个或多个最高有效数字是指首次引入该元件的图号。

具体实施方式

除非另外限定，否则本文所用的技术和科学术语都具有与本发明所属领域普通技术人员通常理解的含义相同的含义。Szycher'sDictionary of Medical Devices CRCPress,1995可以为本文使用的许多术语和短语提供有用的指导。本领域技术人员将认识到可以用于本发明的实践中的与本文所述描述的方法和材料类似或等同的许多方法和材料。事实上，本发明绝不限于具体描述的方法和材料。

在一些实施方案中，用于描述和要求保护本发明的某些实施方案的特性诸如尺寸、形状、相对位置等应被理解为由术语“约”修饰。

现在将描述本发明的各种实例。以下描述提供了具体细节，以便透彻理解和实现对这些实例的具体实施方式。然而，本领域技术人员将理解本发明可以在没有这些细节中许多细节的情况下被实践。同样，相关领域的技术人员也将理解，本发明可以包括许多其他未在本文中详细描述的显而易见的特征。此外，一些众所周知的结构或功能可能不会在下文中详细示出或描述，以避免不必要地模糊相关描述。

下面使用的术语将以其最广泛合理的方式解释，即使它与本发明的某些特定实例的具体实施方式结合使用。事实上，下面甚至可能对某些术语进行了强调；然而，任何意图以任何受限制的方式解释的术语都将在体实施方式章节中被明确具体地定义为如此。

虽然本专利说明书含有许多具体实施方式细节，但这些不应被解读为对任何发明的范围或可能要求保护的内容的范围的限制，而应解读为对特定发明的特定实施方式所特有的特征的描述。本专利说明书中在单独实施方式的背景下描述的某些特征还可以在单一实施方式中以组合实施。相反地，在单一实施方式的背景下描述的各个特征还可单独地或以任何合适的子组合在多个实施方式中实施。此外，尽管特征可能在上文中被描述为以某些组合起作用，并且甚至最初以这样的方式要求保护，但来自所要求保护的组合的一个或多个特征可在一些情况下从该组合中删除，并且所要求保护的组合可以涉及子组合或子组合的变型。

类似地，尽管操作可能在附图中是以特定次序被描绘，但这不应理解为要求此类操作以所示的特定次序或按顺序次序执行，或者要求全部图示操作都要被执行以达到期望结果。在某些情况中，多任务执行和并行处理可能是有利的。此外，上文描述的实施方式中的各个系统组件的分离不应理解为在全部实施方式中需要这种分离，且应理解为所描述的程序组件和系统一般可一起整合在单一软件产品中或包装在多个软件产品中。

综述

本说明书涉及用于评估和/或管理被诊断患有心力衰竭并正在接受一种或多种心力衰竭(HF)治疗剂治疗的患者的治疗方案的系统和方法。在一个实例中，提供了用于使用来自一个或多个远程患者监测设备的远程患者监测数据和使用来自患者的电子健康记录的患者健康数据来定期评估和更新被诊断患有心力衰竭的患者的治疗方案的系统和方法。例如，使用如本文讨论的决策树模型和循证方法根据指南指导的药物疗法定期评估和更新治疗方案。用于评估和/或管理HF患者的治疗方案的示例系统在图1中示出。

在全国范围内，指南指导的药物疗法(GDMT)在心力衰竭患者中未得到充分利用。不到四分之一的患者接受了全部三种建议的类别的GDMT(血管紧张素转换酶抑制剂(ACEi)/血管紧张素II受体阻滞剂(ARB)、血管紧张素受体脑啡肽酶抑制剂(ARNI)、β阻滞剂(BB)和盐皮质激素受体拮抗剂(MRA))的治疗。进一步地，之前的研究已证明，只有1％接受了目标剂量的全部3种类别的药物。最近，已发现钠-葡萄糖协同转运蛋白2(SGLT2i)抑制剂也可以改善HF患者的结局。GDMT未被充分利用的主要原因是由于临床惯性，当临床医生未能启动或加强循证疗法或未能在患者身上达到规定的目标(如血压或血糖)时，就会发生这种情况。临床惯性构成改善HF患者临床结局的最大障碍之一。本文提供的方法和系统改进了GDMT的利用，以无缝且高效的方式实现HF药物的目标剂量，同时能够监测患者的任何药物更新或改变。进一步地，这些方法和系统提供了循证方法(evidenced-based approach)，该循证方法利用从一个或多个远程监测设备输出的生理数据以及来自电子健康记录的患者健康数据来管理HF疗法。基于决策树的模型，在本文中称为决策引擎，是由用于评估和管理被诊断患有心力衰竭并正在接受一种或多种HF治疗剂治疗的患者的治疗方案的治疗方案评估处理系统实施。用于管理治疗方案的示例方法在图2中示出。进一步地，在一些实例中，来自一个或多个远程监测设备的远程患者监测数据被用于评估患者的稳定性，并且治疗方案更新可以基于患者的稳定性。在一个实例中，决策引擎的操作模式可以基于患者的临床稳定性。用于确定决策引擎的操作模式的示例方法在图3中讨论。进一步地，根据治疗方案是否正被更新或患者对经更新的治疗引擎的响应是否被评估，可以选择决策引擎的期望操作模式。用于基于临床稳定性更新治疗方案并评估患者对经更新的方案的响应的示例方法在图4A、图4B和图5中示出和描述。进一步地，图6A至图6D描述了示例的基于决策树的方法，该方法可以在用于向上滴定(up-titration)、启动、减少剂量或停用治疗剂的启动和给药引擎中实施。进一步地，可以提供重新检查实验室测试的一个或多个警报。进一步地，图7示出可以在安全性决策引擎中实施以确定当前开具给患者的一种或多种治疗剂的处方是否要减少剂量或停用的示例方法。特别地，安全性决策引擎可以使用远程患者监测(RPM)数据检查与药物副作用、急性肾损伤、高钾血症、低血压和心动过缓的症状相关的阈值。如果RPM检测到患者已达到任何关键安全性阈值，则安全性决策引擎可以更新治疗方案以减少或停用一种或多种药物的剂量。在一些实例中，该安全性决策引擎可建议患者停用或减少药物剂量，并且可以相应地更新治疗方案。图8A和图8B示出决策引擎的示例临床医生侧界面。图9A和图9B是示出示例HF药物和相关剂量的表格。图10A、图10B、图11A、图11B和图11C示出各种治疗方案更新的示例输入、决策状态和输出建议。

本文所述的方法和系统的技术优势包括改进的患者治疗方案监测和临床环境之外的患者响应监测。本文描述的方法和系统的另一个技术优势是安全高效地启动和向上滴定基于GDMT的治疗剂，这允许该治疗方案高效且快速地达到目标剂量。因此，GDMT利用增加，从而改善了患者结局并降低了死亡风险。进一步地，在治疗方案更新之后的患者响应监测允许有效地监测副作用，并且实现用于调整药物的快速响应。本文描述的方法和系统减少临床惯性。又一个技术优势是基于患者当前的生理状况(包括既往病史和以前的GDMT不耐受或过敏)通过快速高效的途径有效定制HF疗法从而实现并管理HF药物的目标水平。

以这种方式，通过利用来自远程监测设备、电子健康记录(EHR)和应用程序(例如，用于接收来自患者的输入、就开具的药物更新的处方指导和/或教育患者、提供通知等)的数据，本文描述的方法和系统使临床医生能够在慢性心力衰竭(HF)和射血分数降低(HFrEF)患者中个性化和优化指南指导的药物疗法(GDMT)。因此，患者结局得到改善，并且HF患者的死亡风险和住院率降低。因此，本文所述的方法和系统提供了心力衰竭疗法的改进。

示例系统

图1示出示例数字治疗系统100的框图，该系统可以被执行用于确定和/或更新被诊断患有心血管疾病病状诸如心力衰竭的患者的治疗方案。该治疗方案可包括一种或多种治疗剂和该一种或多种治疗剂用于心血管疾病病状的相应剂量。本文的实例将针对心力衰竭(HF)进行描述；然而，应当理解，类似的系统和方法可以被实施于任何心血管疾病病状或健康护理提供者可为其开具包括一种或多种治疗剂(例如，药物)的治疗方案的处方的任何健康状况。

数字治疗系统100包括一个或多个生理传感器106，该生理传感器用于从患者获取生理传感器数据。来自一个或多个生理传感器的生理参数的指示被输入到决策引擎152中，从而提供用于评估和/或管理心力衰竭患者的治疗方案的更准确且可靠的患者健康评估，如下文进一步讨论的。

在一个实例中，所述一个或多个生理传感器106可以被配置为用于监测患者的一个或多个生理参数的远程监测传感器。该远程监测传感器可包括一个或多个可佩戴传感器和/或设备、一个或多个非可佩戴传感器和/或设备，或它们的任何组合。进一步地，所述一个或多个可佩戴传感器可直接或间接置于人体上。所述一个或多个可佩戴传感器可被配置为身体佩戴设备(诸如腕戴设备(例如，智能手表、腕带等)、颈戴设备(例如，项链等)、耳塞、戒指、条带等)、身体附着设备(例如，可佩戴贴片、具有多个附着模块的设备)、位于衣服(例如，紧身衣、背心、裤子)中的嵌入式设备、眼镜、钥匙链、鞋子等。非可佩戴传感器和/或设备可包括但不限于智能手机(包括应用程序)、手持设备、台式血压监测器、葡萄糖计量器、床旁睡眠监测器等。

所述一个或多个生理传感器106可包括一个或多个用于获取血压数据的血压传感器108、一个或多个用于获取PPG数据的光学体积描记图(PPG)传感器110、一个或多个用于获取ECG数据的心电图(ECG)传感器112、一个或多个用于获取患者活动性和/或稳定性数据的稳定性传感器114以及一个或多个用于获取听诊数据的音频传感器116中的一者或多者。在一些实例中，所述一个或多个生理传感器106可另外地包括其他传感器117，诸如肌电图(EMG)传感器、EEG传感器、温度传感器、生化传感器、生物力学传感器和可植入传感器。

血压传感器

高血压病或高血压是一种增加心血管疾病和其他疾病的风险的医学病状。高血压病患者可能需要定期或持续监测血压以防止进展为心力衰竭。进一步地，血压监测对已确诊心力衰竭的患者也很重要。因此，为了评估HF患者的治疗方案、更新该治疗方案和/或提供有助于持续评估和/或更新该治疗方案的一个或多个警报，使用血压测量值。因此，所述一个或多个血压传感器108可从患者获取血压数据，该血压数据用于获得血压测量值，包括动态血压测量值和/或标准血压测量值。所述一种或多种血压测量值可包括收缩压(SBP)和舒张压(DBP)中的一者或多者。所述一个或多个血压传感器108可被配置为可佩戴设备或基于家庭的监测设备。在一个实例中，可以训练并且/或者指导患者使用基于家庭的血压监测设备来执行基于家庭的血压测量。例如，可以就家庭监测设备的血压袖带的定位对患者进行引导，并且可经由家庭监测设备获取血压数据，该家庭监测设备可自动输出一个或多个血压测量值。在另一个实例中，当血压传感器被配置为可佩戴设备(例如，腕表)时，可以自动获取血压数据并自动计算血压。在又一实例中，来自传感器组合的数据(例如，ECG和PPG数据)或来自另一类型传感器的数据(单独的ECG数据或PPG数据)可用于测量SBP和/或DBP。

ECG传感器

ECG监测可用于估计和/或测量各种心脏参数，包括但不限于心率(HR)、心率变异性(HRV)、心节律异常(QT间期改变、QRS不规则、ST段改变等)房性心律失常和室性心律失常。所述一个或多个ECG传感器112可获取ECG数据，该ECG数据被用于确定患者的心率和心节律测量值中的一者或多者。进一步地，所述一个或多个ECG传感器可被配置为获取单导联或多导联数据(例如，双导联、三导联、六导联、十导联、十二导联等)。此外，所述一个或多个ECG传感器112可被配置为可佩戴或非可佩戴ECG监测设备。在一个实例中，包括一个或多个ECG传感器的可佩戴ECG监测设备可被患者佩戴或附接到患者，并且患者的ECG数据可经由该可佩戴设备以连续方式或以预定的时间间隔或作为对用户启动的响应获取。在另一个实例中，手持式ECG监测设备可被用于获取ECG数据。例如，根据设备配置，所述ECG监测设备可被放置在身体的特定解剖学位置处以获取多导联数据。

PPG传感器

PPG传感器可包括至少一个光源(例如，LED)和至少一个光检测器(例如，光电二极管)。使用光检测器，可以生成指示血流通过血管的PPG信号，该PPG信号可以用于测量和/或估计患者的一个或多个生理参数(例如，心率、呼吸率、心率变异性、脉动血氧合估计值(SpO2)、血压等)。PPG传感器可作为ECG传感器的补充或替代使用。PPG传感器可被配置为可佩戴或非可佩戴设备，并且可被放置在诸如耳垂和指尖的解剖学位置处，在这些位置可以以更高的质量收集所需的PPG信号。

稳定性和/或活动性传感器

患者稳定性(例如，处于直立姿势时的患者平衡、姿势摇摆等)和患者活动性(例如，步态变化)的评估可以使用所述一个或多个稳定性和/或活动性传感器112来执行。在一些实施方案中，患者活动性和/或稳定性评估可被用于确定用于HF治疗方案管理的决策引擎的操作模式，如下文进一步详细讨论的。简而言之，患者活动性和/或稳定性评估可经由从一个或多个稳定性和/或活动性传感器112获取的数据来执行。在一些实例中，可导致治疗剂的启动或治疗剂的向上滴定的决策引擎的操作模式可基于稳定性评估是否指示患者达到期望的稳定性阈值。在一些其他实例中，如果患者的稳定性低于低阈值，该决策引擎可以以可评估一种或多种治疗剂是否可以停用或减少或者是否需要一项或多项实验室测试的模式操作。下面进一步讨论该决策引擎的不同模式的细节。

所述一个或多个稳定性和/或活动性传感器112可包括一个或多个加速度计和/或一个或多个陀螺仪。在一个实例中，嵌入智能设备中的惯性传感器可用于测量患者稳定性和/或患者活动性。作为非限制性实例，从智能手机(例如iPhone)、智能手表(例如Apple手表)或智能平板电脑(例如iPAD)内包括的加速度计和/或陀螺仪获取的数据可用于评估患者的稳定性。例如，来自加速度计和/或陀螺仪的数据可用于计算可指示患者的摇摆程度的平衡得分。在一些实例中，可佩戴设备可包括可用于获取稳定性数据和评估患者的稳定性的一个或多个加速度计(例如，双轴加速度计、三轴加速度计等)和/或一个或多个陀螺仪(例如，双轴陀螺仪、三轴陀螺仪等)。进一步地，在一些实例中，所述一个或多个稳定性和/或活动性传感器112可被配置为包括加速度计、陀螺仪和磁力计的惯性测量单元(IMU)。IMU可被放置在腿上的特定位置(例如小腿、脚等)，并且来自IMU的数据可用于评估步态不规则性和/或稳定性。

音频传感器

在一些实例中，一个或多个音频传感器116可用于评估患者的心音。所述一个或多个音频传感器116可用于执行听诊，并且来自所述一个或多个音频传感器116的音频数据可用于确定是否维持或更新治疗方案或生成一个或多个警报(例如，执行特定实验室测试的警报、执行基础代谢小组(basic metabolic panel)的警报，等)。

其他传感器

在一些实例中，来自其他传感器诸如生化传感器和生物力学传感器的数据可用于评估和/或管理HF的治疗方案。生化传感器包括电化学式传感器，该电化学式传感器被配置为测量体液电解质参数，诸如分析物浓度。例如，可使用被配置成分析汗液、唾液和/或水合作用的传感器。诸如基于心脏射血容量描记图的传感器、基于心脏振动描记图的传感器和介电传感器的生物力学传感器可用于连续测量诸如心输出量、肺液体积和重量的变量。例如，放置在患者胸部的加速度计可用于生成心脏振动描记图(SCG)，该心脏振动描记图是对由跳动的心脏产生的胸廓加速度的测量。通过SCG，可以评估心动周期的不同机械事件，包括主动脉瓣和二尖瓣的打开和关闭、心房收缩和/或等容收缩和舒张。因此，在一些实例中，SCG数据可另外地用于评估和/或管理HF的治疗方案。进一步地，在一些实例中，来自一个或多个另外的传感器诸如EMG、EEG、温度传感器和/或可植入心脏监测器(例如，用于AF检测、监测肺动脉压力等)的数据可用于评估和/或管理HF的治疗方案。

在一些实例中，包括多个生理传感器的多传感器模块可被用于同时从各种传感器获取多传感器数据，并处理多传感器数据以估计和/或测量多个生理参数(心率、收缩压、舒张压、体重、温度、稳定性、氧饱和度、呼吸率、稳定性等)，这些参数可用作配置为评估和/或管理HF治疗方案的决策引擎的输入参数。

在一些实例中，一个或多个监测设备可用于从患者获取生理传感器数据，在此种情况下所述一个或多个监测设备中的每一个均包括一个或多个生理传感器106。作为非限制性实例，患者的生理参数可使用第一监测设备(其可为血压监测设备)、第二监测设备(其可为ECG和/或心音监测设备)和第三监测设备(其可为稳定性监测设备)来估计和/或测量。来自所述设备中的每个设备的生理传感器数据可在期望的时间窗内依序地或同时地获取以用于评估和/或管理HF的治疗方案。

在一些实例中，来自所述传感器中的一些传感器的数据可以同时获取。例如，来自生成波形数据的传感器的数据可以同时并以时间同步的方式获取(例如，ECG和音频传感器；ECG和PPG；ECG、音频和PPG；ECG、PPG和ECG；等)。进一步地，当获取用于评估和管理治疗方案的传感器数据时，来自其他生理传感器诸如血压传感器的数据可以独立地但在期望的时间窗内获取。

进一步地，在一些实例中，所述一个或多个生理传感器中的每一个或所述一个或多个监测设备中的每一个(所述一个或多个监测设备中的每一个包括一个或多个生理传感器)可包括与相应传感器(或设备)集成在一起的集成处理器。相应的集成处理器可处理经由相应传感器获取的相应数据并生成相应的输出，该相应的输出然后被传输到决策引擎以用于确定是否可以对当前治疗方案进行任何修改。

在一些实例中，计算设备120可通信地耦接到所述一个或多个生理传感器(和/或监测设备)106和治疗方案评估服务器150。进一步地，计算设备120可经由连接118从所述一个或多个生理传感器106接收数据并且向该生理传感器发送数据，该连接可以是有线的、无线的(例如，WiFi、ZigBee、蓝牙、5G等)或它们的组合。进一步地，计算设备120可经由通信网络140向服务器150发送数据并且从该服务器接收数据，该通信网络可以是有线的、无线的或它们的组合。计算设备120可以是任何合适的计算设备，包括计算机、膝上型计算机、移动电话、平板电脑等。计算设备120包括一个或多个处理器126、一个或多个存储器132和用于接收用户输入和/或向用户显示信息的用户界面134。

在一个实施方式中，计算设备120可被配置为移动设备并且可包括患者侧应用程序136，该患者侧应用程序以软件、固件或它们的组合的形式表示机器可执行指令。在应用程序136中标识的组件可为移动设备的操作系统的一部分或者可为开发为使用该操作系统运行的应用程序。在一个示例中，应用程序136可为移动应用程序。应用程序136还可包括网络应用程序，该网络应用程序可以做移动应用程序的镜像，例如，提供与移动应用程序相同或相似的内容。

在一个实例中，应用程序136可包括患者界面并且可帮助患者获取用于评估和/或管理HF的治疗方案的生理传感器数据、输入基于由患者进行的远程监测的一个或多个生理参数的估计值和/或测量值，以及接收来自决策引擎的通知和/或警报。例如，通过应用程序136，患者可执行以下：接收启动用于治疗方案评估的生理传感器数据获取的通知、输入用于经由决策引擎152进一步处理的估计和/或测量的生理参数值、接收基于来自决策引擎的关于治疗方案的任何更新的输出的通知、提供更新的确认和/或认收、输入对经更新方案的反应，以及接收关于评估和/或管理治疗方案可能需要的待定和/或另外的实验室测试的通知，以及其他功能。

在一些实例中，患者可通过应用程序136从服务器接收治疗方案更新、建议、通知、警报和其他HF治疗方案。通过患者界面，应用程序136可以(1)显示生命体征，(2)显示活动，(3)显示药物列表，(4)显示药物提醒，(5)治疗和剂量建议，(6)患者内容，包括教学视频，(7)允许输入患者的副作用，(8)启用治疗方案通知/更新/改变确认，和(9)其他HF治疗方案相关信息。

在一些实施方式中，应用程序136可以用于启动来自所述一个或多个生理传感器106(和/或一个或多个监测设备)的生理传感器数据获取以用于评估和/或管理HF的治疗方案。进一步地，在一个实例中，应用程序136可被配置为接收来自所述一个或多个生理传感器106(和/或一个或多个监测设备)的生理传感器数据、预处理生理传感器数据(例如，应用过滤、归一化化以提高信号质量和降低噪声)并且将经预处理的传感器数据传输到治疗方案服务器150(由144指示)以用于由该生理传感器数据估计和/或测量一个或多个生理参数。然后可将估计和/或测量的生理参数(心率、稳定性、收缩压、舒张压等)用作决策引擎152的输入以用于评估和/或管理HF的治疗方案。

在另一个实例中，来自所述一个或多个生理传感器106(和/或一个或多个监测设备)的相应生理传感器数据可以经由计算设备102中的相应移动或网络应用程序(以及经由相应应用程序编程接口(API))来处理，并且来自相应生理传感器的估计的和/或测量的生理参数可以用作决策引擎152的输入。在一个实例中，经由每个生理传感器估计和/或测量的一个或多个相应生理参数可被自动传输到决策引擎152。在另一个实例中，用户可经由应用程序136输入一个或多个估计的和/或测量的生理参数。在又一实例中，用户可输入所述生理参数中的一些生理参数，而其余估计的和/或测量的生理参数可被自动输入到决策引擎中。在一些实例中，计算设备102可包括一个或多个传感器(例如，陀螺仪128、加速度计124等)，并且来自所述一个或多个传感器的原始或经预处理的数据可经由相应的框架或API访问。例如，来自计算设备120的陀螺仪和/或加速度计数据可用于确定患者的一个或多个稳定性参数(例如，摇摆程度)，该参数可被自动输入(例如，经由应用程序136被输入到服务器150或根据原始数据或经预处理数据如何被处理以获得生理参数而从服务器150被输入)到决策引擎。

在一些实例中，来自所述一个或多个生理传感器106的一个或多个生理传感器数据集可以经由计算设备120和/或通信网络140传输到治疗方案评估服务器150，并且预处理步骤(例如，用于去除噪声)可在服务器150或计算设备102处执行。换句话说，服务器150可被配置为经由计算设备120和/或网络140接收来自所述一个或多个生理传感器106的一个或多个生理传感器数据集(原始的或经预处理)。网络140可以是有线的、无线的，或有线和无线的各种组合的。进一步地，所述一个或多个生理传感器106可以预先与治疗方案评估服务器150关联。进一步地，在一些实例中，所述一个或多个生理传感器106可以是预先与治疗方案评估服务器150关联的互连设备的网络。

在一些实例中，中间网关可用于将生理传感器106与服务器150连接，并且服务器150可经由中间网关接收估计的和/或测量的生理参数值。在一些其他实例中，服务器150可以与相应生理传感器的一个或多个相应平台交互，并且所选定的信息诸如使用经由相应生理传感器获取的数据估计和/或测量的一个或多个生理参数可由服务器150从传感器平台接收。作为非限制性实例，血压监测平台可基于经由血压传感器108获取的数据估计和/或测量患者的SBP和DBP中的一者或多者，并且SBP值和/或DBP值可由服务器150从血压监测平台接收。

治疗方案服务器150包括一个或多个处理器149和一个或多个非暂时性存储器151。所述一个或多个处理器149可包括存储在非暂时性存储器151中的机器可读指令。所述一个或多个存储器151可存储用于执行HF患者的治疗方案的评估和/或管理的决策引擎152。在一个实例中，决策引擎152包括用于评估患者稳定性的稳定性处理逻辑153。在一些实例中，可以以期望的间隔周期性地评估患者的稳定性以确定是否启动治疗方案的评估。在一些其他实例中，可以评估患者的稳定性以确定决策引擎的操作模式，如下文进一步讨论的。

决策引擎152还包括安全性决策引擎154，该安全性决策引擎用于确定治疗方案中的一种或多种治疗剂(即，药物)是否可以减少或停用，或者患者是否需要另一项实验室测试。决策引擎还包括启动和剂量引擎(IDE)155，该启动和剂量引擎(IDE)用于确定治疗方案的更新，包括新药物的启动和一种或多种治疗剂的向上滴定。因此，基于IDE的治疗方案的更新还可以包括维持当前方案、向下滴定或停用一种或多种治疗剂，以及执行一项或多项实验室测试的一个或多个警报。在一些实例中，基于一个或多个患者条件，决策引擎152可以以执行IDE 155的第一模式或以仅执行安全性决策引擎154的第二模式操作。下面将讨论决策引擎的细节，包括决策引擎的不同操作模式。

决策引擎152还包括用于接收来自EHR系统162的患者信息的电子健康记录(EHR)处理逻辑156。EHR系统162包括EHR服务器166和存储患者健康信息的EHR数据库。在一些实例中，EHR系统162还可包括用于与治疗方案评估服务器150连接的EHR接口服务器(未示出)。在一些实例中，决策引擎152可以集成在EHR系统162内。例如，决策引擎152经由网络141从EHR接收患者数据。进一步地，临床医生计算设备170可经由网络141通信地耦接到治疗方案评估服务器150。网络141可以是无线网络、有线网络或无线网络和有线网络的任意组合。

治疗方案评估服务器150可包括用于存储每个患者的治疗方案信息的心脏健康数据库160。治疗方案信息可包括当前治疗方案、由决策引擎和/或临床医生对当前治疗方案作出的更新、开具给患者的所有治疗方案的处方的历史、每个治疗方案的更新的历史、关于已接受的改变的信息、有关传输到药房系统190的处方的信息，等。

临床医生计算设备170包括至少一个处理器176、至少一个非暂时性存储器182和用户界面184，所述用户界面184可为用户输入设备。用户界面184可以是用户输入设备，并且可包括以下中的一者或多者：触摸屏、键盘、鼠标、触控板、运动传感摄像机和其他被配置成使用户能够与处理系统102交互并且操纵该处理系统内的数据的设备。用户界面可包括显示器部分(未示出)。显示器可与共享外壳中的处理器176、非暂时性存储器182和/或用户界面184组合，或者可以是外围显示设备并且可包括监视器、触摸屏、投影仪或本领域已知的其他显示设备，这可以使用户能够查看患者传感器数据、患者EHR数据以及/或者与存储在非暂时性存储器182和/或数据库160中的各种数据进行交互。

进一步地，临床医生计算设备170可以是例如经由网络141通信地耦接到EHR系统162的工作站。临床医生计算设备170还包括临床医生应用程序186。类似于患者侧计算设备120处的应用程序136，临床医生应用程序186以软件、固件或它们的组合形式表示机器可执行指令。进一步地，在应用程序186中标识的组件可为计算设备170的操作系统的一部分或者可为开发为使用该操作系统运行的应用程序。进一步地，应用程序186可包括临床医生界面，该临床医生界面允许经认证的临床医生开具治疗方案的处方、审查治疗方案、确认治疗方案和/或作出对治疗方案的任何改变。进一步地，应用程序186可允许经认证的临床医生审查患者的EHR，将来自EHR的数据输入到决策引擎中，并且/或者将患者监测数据(例如，来自临床访视)输入到决策引擎中。还进一步地，应用程序186可使临床医生能够在任何时候通过决策引擎152选择性地启动治疗方案评估。在一个实例中，临床医生界面可以：(1)显示患者的生命体征，包括使用一个或多个生理传感器估计和/或测量的生理参数；(2)显示相关病史；(3)显示包括剂量在内的药物列表；(4)显示生成的指令；(5)治疗和剂量建议；(6)显示警报；(7)允许临床医生输入副作用；以及(8)显示导致生成的指令和/或警报的逻辑。临床医生界面的非限制性实例示于图8A和图8B。

在一个实施方案中，用于实施所公开技术的示例系统可包括具有显示器的计算设备、通信网络、患者、一个或多个远程监测传感器以及服务器和关联数据库，其中服务器和关联数据库是经由通信网络通信地耦接到计算设备。计算设备可以是任何合适的计算设备，包括计算机、膝上型计算机、移动电话等。网络可以是有线的、无线的或有线和无线的各种组合。服务器和关联数据库可以是本地的、远程的，并且可以是服务器和数据库的组合，或者可以是本地处理器和存储器。所述一个或多个远程监测传感器可以是智能手机、智能手表、智能脚踝镯、智能眼镜、智能戒指、贴片、带子或其他可以适当地保留在患者身上并且从患者输出生理参数数据的设备。生理参数数据可包括但不限于心率数据、血压数据、身体温度数据、氧饱和度数据、呼吸率数据、患者平衡稳定性数据和患者活动性数据。在其他实例中，当患者在医院时远程监测设备可以是临床级ECG系统。在一些实例中，远程监测设备可以是位于移动设备上的摄像头，并且可以通过由摄像头检测到的毛细血管颜色的波动来记录心率数据。

在一些实例中，决策引擎可以在远程临床访视期间和/或在与临床医生进行远程访视之前执行。在一些其他实例中，决策引擎可以在临床访视之前执行。

图2是高级流程图，示出了根据本公开的实施方案的用于评估和/或管理HF患者的治疗方案的示例方法200。特别地，方法200和本文描述的所有方法都可基于存储在处理系统的非暂时性存储器(诸如治疗方案评估服务器150、连接到处理系统的边缘设备、与处理系统通信的云或它们的任何组合)中的指令来实施。方法200将针对图1来描述；然而，应当理解，方法200可在不脱离本公开的范围的情况下使用类似系统来实施。

方法200在202处开始。在202处，方法200包括确定是否达到用于对HF患者执行治疗方案评估和/或管理的进入条件。进入条件可基于患者的期望时间表中的一个或多个。例如，一个或多个生理参数(例如，收缩压、平均收缩压、心率、平均心率等)和/或患者数据(来自EHR)可根据患者的期望时间表进行监测以确定是否达到进入条件。在一个实例中，可以每天使用远程监测数据来监测患者，因此，期望的时间表可包括每天许多次，其中次数可为每天1、2、3、4、5、6或更多次。在一些实例中，可以执行一个或多个生理参数的连续监测。在一些实例中，期望的时间表可以是每周、每2周、每3周或每4周。在一些实例中，当患者的EHR中指示出新的实验室结果时可以达到进入条件。因此，方法200可以是迭代的并且可以考虑心力衰竭治疗物、剂量和/或施用时间(或其他因素)的周期性变化。在一个实例中，期望的时间表可由临床医生指定。在另一个实例中，期望的时间表可基于患者的心脏健康状况自动生成。因此，在一些实例中，期望的时间表可以针对每个患者来定制(自动定制或基于临床医生的建议定制)。进一步地，如果新的实验室测试结果和/或心脏成像结果已在EHR中生成，则可以达到进入条件。实验室可包括基本代谢测试或综合代谢小组和/或全血细胞计数。进一步地，心脏成像结果可包括指示经更新的左心室射血分数(LVEF)的新超声心动图，或任何心脏成像结果(例如，核灌注研究、心脏单光子发射计算机断层扫描、心脏磁共振成像等)。在一些实例中，如果射血分数小于40％并且和/或者收缩压大于140，则可以达到进入条件。如果未达到进入条件，则在202处的回答为否，并且方法200行至进204。在204处，方法200包括不启动启动和给药引擎，诸如图1处讨论的启动和给药引擎152。下面将在图6A至图6D处描述启动和给药引擎的更多细节。

如果在202处达到进入条件，则方法200进行至210和220。在210处，该方法包括接收来自HF患者的传感器数据。在一个实例中，传感器数据可包括从经由一个或多个预先与启动和决策引擎关联的生理传感器(诸如所述一个或多个生理传感器106)获取的数据估计和/或测量的一个或多个生理参数值。在另一个实例中，传感器数据可包括一个或多个来自所述一个或多个生理传感器的数据集。所述一个或多个数据集可包括经由所述一个或多个生理传感器获取的原始数据或预处理数据，并且因此，在一个实例中，启动和给药引擎可基于所述一个或多个数据集估计和/或确定一个或多个生理参数。

在一些实例中，传感器数据可包括ECG数据212(经由ECG传感器获取)、血压数据214(经由BP传感器获取)、稳定性数据216(经由陀螺仪获取)和其他传感器数据218，诸如PPG、SCG、音频传感器数据等。可替代地，在一些实例中，传感器数据可包括超过阈值持续时间的心率和/或平均心率(基于一个或多个传感器数据诸如ECG数据和PPG数据估计和/或测量)。传感器数据还可包括阈值持续时间内的平均SBP、阈值持续时间内的平均DBP以及阈值持续时间内估计和/或测量的最低收缩压。传感器数据还可包括基于陀螺仪数据计算的稳定性程度。在一些其他实例中，传感器数据可包括数据集的组合。例如，原始数据或被预处理成去除了噪声的数据等可从一些生理传感器接收，而估计值和/或测量值可从其余生理传感器接收。作为非限制性实例，在远程血压传感器处确定的平均SBP值、平均DBP值和最低DBP值可以被接收，而ECG数据集和陀螺仪数据集可从ECG传感器和陀螺仪接收。因此，处理系统(例如，服务器150)可使用从相应的传感设备接收到的ECG和陀螺仪数据集来确定患者的平均心率和稳定性程度。

在一个实例中，响应于达到进入条件，指示可被传输至患者计算设备(例如，计算设备120)或经由在患者计算设备处运行的应用程序(例如，应用程序136)自动生成。该指示可包括用于从所述一个或多个生理传感器获取一个或多个传感器数据的通知和/或关联指令。在一些实例中，患者可经由应用程序(即，决策引擎的患者界面)自动启动来自所述一个或多个生理传感器的数据获取。此外，当需要从非可佩戴设备诸如台式血压监测器获取数据时，可以提供时间窗，患者可以在该时间窗内获取所有必要的生理传感器数据。在一些实例中，当所述一个或多个生理传感器被配置为可佩戴设备并且与患者接合时，以及当所述一个或多个生理传感器被配置为互连医疗设备的网络时，传感器数据的获取可响应于所达到的进入条件自动启动(通过患者经由应用程序(例如，经由单击)启动从所有互连传感器的自动获取来自动启动，或在没有患者启动的情况下自动启动)。

在一些情况下，方法200可包括接收周期性传感器数据读数，包括每5秒、每30秒、每分钟、每五分钟、每小时、每天或其他合适时间(包括在所列举时间之间)的心率。因此，传感器读数的平均值可在更长的时间段内确定，而无需患者在他们选择的时间有意识地测量心率。

同时，在220处，方法200包括接收参考存储器、数据库或其他合适的存储系统(例如，EHR)中的特定患者概况的患者数据。该患者数据可包括治疗物和剂量222、身高和体重224、病史226、射血分数228、副作用230和其他数据。在一些实例中，治疗物和剂量222可包括施用于患者的心力衰竭治疗物的历史、剂量和伴随的传感器数据210以及特定治疗物和剂量的副作用。此外，病史可含有关于患者的状况的各种信息以及其他与心力衰竭病状相关的信息。

各种副作用230可由患者通过界面(例如，图1中的应用程序136)进入并且/或者可由传感器监测并且从传感器数据210检测。例如，启动和剂量引擎可从心电图数据212、可接受阈值之外的心率变化或可接受阈值之外的血压变化检测心脏事件。其他定性副作用可由患者进入，包括恶心、头晕、疲倦等。在一些实例中，患者将以固定时间间隔被提示检查或进入他们正在经历的任何副作用(包括来自标准列表的副作用)。

以这种方式，来自一个或多个远程监测设备(诸如远程血压监测设备、可佩戴智能手表等)的可包括心电图和/或脉搏和活动数据在内的数据可被输入到启动和剂量引擎中。进一步地，数据可从电子健康记录系统输入到启动和剂量引擎中。例如，传感器和EHR数据可被输入到启动和决策引擎中以评估和/或输出经更新的治疗方案。来自电子健康记录系统的信息可包括各种患者数据，包括(1)基本代谢信息，诸如钾、肌酐、δ肌酐、估计肾小球滤过率(eGFR)等，(2)身高和体重，(3)治疗史(过去和现在)，(4)目前和过去的状况(activeand past condition)，(5)手术史，(6)射血分数数据，(7)药物过敏，和(8)其他信息。

接下来，在232处，传感器数据(来自210)和患者数据(来自220)可被输入到启动和给药引擎中并且被处理以输出经更新的治疗方案234，该经更新的治疗方案234可包括至少一种治疗剂或多种治疗剂和伴随剂量236。启动和给药引擎(IDE)可包括利用各种生理参数的阈值的决策树。在一个实例中，IDE可利用如作为来自所述一个或多个生理传感器(或包括一个或多个生理传感器的一个或多个远程监测设备)的输入而接收到的生理传感器数据(包括平均心率、平均收缩压、最低收缩压、呼吸率、氧饱和度和温度)和来自陀螺仪的稳定性信息，并且可以利用患者数据(例如，诸如来自实验室测试的代谢小组数据、心脏成像等)，该患者数据包括来自EHR的钾水平、肌酐水平、δ肌酐水平、eGFR水平、射血分数水平等。上面提到的生理传感器数据和患者数据中的一个或多个生理传感器数据和患者数据的相应阈值或范围可在开具IDE的处方时启动或在治疗方案过程期间的任何时间更新。例如，如果一段延长的时间段(例如四小时)的平均心率超过某个水平，则系统可以确定是否滴定或改变药物。启动和剂量引擎的细节将在下面的图6A至图6D中讨论。

在确定经更新的治疗方案后，在238处，方法200包括通过向患者施用经更新的治疗方案所需的治疗物和剂量来治疗患者。在一些实例中，这可包括给患者开具治疗物的处方并且要求患者按一定的间隔以一定的剂量服用药物(例如，每12小时12mg)。

接下来，在一些实例中，传感器可在施用新治疗方案后监测患者，并且新数据可在稍后时间由启动和剂量引擎再次处理(例如，每天、1周、2周、3周、4周等n次(其中，n＝1,2,3,4))或者可在治疗方案已更新并且患者已开始实施该更新之后的期望患者响应监测期内是持续的。

转至图3，其示出高级流程图，示出了根据本公开的实施方案的用于操作决策引擎以评估和/或监测HF患者的治疗方案的示例方法300。特别地，方法300可基于来自一个或多个生理传感器(诸如一个或多个生理传感器106)以及来自患者的EHR(诸如，EHR系统162)的输入确定决策引擎(诸如决策引擎152)的操作模式。

方法300在302处开始。在302处，方法300包括接收来自一个或多个生理传感器和患者EHR的输入。来自所述一个或多个生理传感器的输入可包括使用经由所述一个或多个生理传感器获取的数据估计和/或测量的一个或多个生理参数。来自所述一个或多个生理传感器和EHR的输入的细节在前文针对图2处的步骤210和步骤220进行了讨论，并且为简洁起见不作重复。简而言之，所述一个或多个生理参数可包括但不限于平均心率、心率变异性、平均SBP、平均DBP、最低SBP、当前体重、稳定性程度、临床稳定性、呼吸率、氧饱和度和温度。进一步地，来自EHR的患者数据可包括但不限于植入设备(例如，ICD、起搏器)的存在、当前和过去的健康状况(例如，糖尿病、高血压)、药物不耐受、性别、体重、肌酐水平(Cr)、与之前的肌酐(dCr)相比的变化、钾水平(K)、eGFR值(eGFR)、当前的治疗剂(即药物)及它们的相应的剂量。

进一步地，在一些实例中，生理参数中的一些，诸如经由相应生理传感器和/或远程监测设备远程监测的收缩压和心率读数可以通过指定的监测周期取平均值。监测周期可为5秒、30秒、1分钟、5分钟、30分钟、1-24小时、1-6天、1-2周或其他合适的时间，包括上面提到的时间之间的时间。

接下来，在304处，方法300包括确定患者对一种或多种药物的向上滴定或启动是否稳定。在一个实例中，稳定性可基于在稳定性监测持续时间内的远程监测数据来确定。特别地，临床稳定性可基于平均心率(例如，基于ECG数据和PPG数据中的一者或多者确定)、平均收缩压(例如，基于血压数据确定)、平均呼吸率(例如，基于PPG数据确定)、平均氧饱和度(例如，基于PPG数据确定)和平均温度(例如，基于身体温度数据确定)。进一步地，在一些实例中，稳定性程度可相对于站立姿势、行走平稳性、步长、行走速度、行走不对称和晕厥迹象中的一者或多者来确定。

在一些实例中，临床稳定性可基于大于阈值得分的临床稳定性得分来确定，该临床稳定性得分基于平均心率、平均收缩压、平均呼吸率、平均氧饱和度、平均温度和稳定性程度来确定，每一者都与相应的阈值或相应的阈值范围相比较。

在一些实例中，该稳定性可基于稳定性监测期间保持在相应阈值或阈值范围内的临床稳定性参数(即，平均心率、平均收缩压、平均呼吸率、平均氧饱和度、平均温度和稳定性程度)中的每一个来确认。在一些其他实例中，两个或更多个稳定性参数可用于稳定性监测。即，平均心率、平均收缩压、平均呼吸率、平均氧饱和度、平均温度和稳定性程度中的两者或更多者可用于稳定性评估。作为非限制性实例，平均心率和平均收缩压可用于稳定性监测。例如，临床稳定性可基于保持在相应阈值范围内的平均心率和平均收缩压来确认。作为另一个非限制性实例，作为对平均心率和平均收缩压的补充或替代，基于陀螺仪和/或加速计数据的稳定性程度可以考虑用于稳定性监测。在一些实例中，稳定性指示可从被配置为计算站立姿势、行走平稳性、步长、行走速度、行走不对称性和晕厥指示中的一者或多者的可佩戴设备诸如智能手表获得。在一些实例中，在确定稳定性时也可考虑来自患者的指示。例如，患者可经由患者侧应用程序(例如，应用程序136)指示关于一种或多种与稳定性相关的状况，诸如昏眩、头晕目眩、昏厥等。因此，处理器可在考虑到患者提供的稳定性输入的情况下评估患者的稳定性。

如果稳定性被确认，则304处的回答为是，并且方法300进行至308。在308处，该方法包括运行启动和给药引擎，其还包括安全性决策引擎。启动和给药引擎可使用患者的远程监测设备数据(即，来自一个或多个生理传感器的数据)和EHR数据基于指南指导的药物疗法(GDMT)自动地启动、停用和/或更新(增加或减少)一种或多种治疗剂的剂量。启动和给药引擎的细节将针对下面的图6A至图6D讨论。

在运行启动和给药引擎后，方法300进行至330。在330处，方法300包括产生启动和给药引擎输出。该输出包括维持当前治疗方案或更新当前治疗方案的建议。在一个实例中，更新当前治疗方案可包括执行以下中的一者或多者：启动一种或多种新治疗剂(332)、停用(338)或改变一种或多种先前施用的治疗剂的剂量(即，改变当前被开具的并且被患者服用的一种或多种治疗剂的处方的剂量)以及重新检查实验室和/或成像测试(340)(例如，基本代谢谱、重新检查LVEF、eGFR等)。改变所述一种或多种先前开具的治疗剂的处方的剂量可包括增加(334)或减少(336)与治疗剂相关的剂量。所述一种或多种新治疗剂中的每一种和所述一种或多种先前施用的治疗剂中的每一种可选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。在一些实例中，每种治疗剂可选自由以下组成的组：比索洛尔、卡维地洛、琥珀酸美托洛尔、卡托普利、依那普利、福辛普利、赖诺普利、培哚普利、喹那普利、雷米普利、群多普利(trandolapril)、坎地沙坦、氯沙坦、缬沙坦、奥美沙坦、沙库巴曲/缬沙坦、螺内酯、依普利酮、达格列净、恩格列净、卡格列净、艾托格列净和其他用于心力衰竭的治疗剂。

在一个实例中，检查实验室输出可响应于以下中的一者或多者来生成：钾水平高于钾水平阈值、δ肌酐水平高于δ肌酐水平阈值、启动MRA类治疗剂、启动血管紧张素转换酶(ACE)抑制剂、启动血管紧张素受体阻滞剂(ARB)以及启动血管紧张素受体脑啡肽酶抑制剂(ARNi)。

接下来，在342处，方法300包括基于启动和给药引擎(IDE)输出在EHR内生成药物更新和/或实验室订单(lab order)。特别地，在EHR内生成药物和/或实验室订单可包括自动批准该订单。以这种方式，如果患者已被确定为在临床上适合于一种或多种治疗剂的向上滴定或启动，则不需要另外的临床医生审查(除非临床医生在开具治疗方案评估和/或管理的处方时指示)。

接下来，在344处，方法300包括将生成的药物更新和/或实验室订单传输到患者EHR。在传输后，方法300进行至346，在此处通知被发送给患者(例如，经由应用程序136的患者界面)以供认收。特别地，由IDE生成的关于药物更新和/或实验室订单的通知可被直接地发送给患者，无需等待临床医生审查。在一个实例中，一旦被临床医生开具处方，启动和给药算法就可在某些预先指定的血压、心率和实验室参数内启动和改变药物剂量而无需临床医生的输入，如下文在图4处进一步所讨论的。进一步地，给患者的通知可包括一个或多个视频或幻灯片的链接以就以建议的剂量采用建议的治疗方案的重要性教育患者，使患者不仅能够理解建议的根本原因，而且还主张改善他们自己的治疗。在任何时候，患者都可以访问提供有关特定治疗剂的教育的相关视频和/或幻灯片。

此外，临床医生可被通知(例如，经由应用程序186的临床医生界面)由IDE生成的药物更新和/或实验室订单。临床医生界面可包括指示IDE输出和DE输出背后的逻辑的决策引擎工作表。例如，对于IDE提供的每个建议，访问的决策条件(在此也称为状态)和决策条件背后的逻辑被显示给临床医生。示出决策引擎访问的状态的示例性临床医生界面示于图8A和图8B中。该临床医生界面还可以针对IDE的每次运行显示生成的一个或多个治疗剂订单以及生成的一个或多个警报(例如，在5天内重新检查代谢实验室)。

如果没有更新并且没有生成实验室订单，则患者和临床医生可被通知已经执行IDE并且此时不需要改变，并且患者可以继续当前的药物而不作任何改变。在患者作出关于药物更新和/或实验室订单的确认或认收后，方法300包括监测患者对IDE处方的响应，诸如由药物更新引起的副作用。监测患者的副作用的细节将在下文图5处描述。

参考图5，其示出流程图，该流程图示出用于在治疗方案更新后监测患者响应的高级方法500。特别地，当用于评估和/或管理治疗方案的决策引擎(诸如启动和给药引擎或安全性决策引擎)在EHR内生成处方并且被患者认收时，使用一个或多个远程监测设备(诸如一个或多个生理传感器106)和/或来自患者的一个或多个指示在阈值处方后监测期(也称为患者响应监测期)内监测患者响应。在一个实例中，阈值处方后监测期可基于经更新的药物类型和/或已知副作用的病史和/或患者的药物不耐受。

方法500在502处开始。在502处，方法500包括接收来自患者的的响应。在一个实例中，来自一个或多个远程监测设备的远程监测数据可用于自动评估患者对治疗方案更新的响应。例如，在患者已经开始经更新的治疗方案后，在处方后监测期间获取的远程监测数据可用于患者响应分析。在另一个实例中，问卷可由IDE或SDE基于药物更新来生成，并且被传输给患者(例如，经由应用程序136)。在开始经更新的治疗方案后，患者可执行自我评估或在护理人员的帮助下，经由患者侧应用程序的患者界面提供对问题的答复。综上所述，接收来自患者的响应可包括以下中的一者或多者：接收来自一个或多个远程监测设备的远程监测数据和接收对问卷的答复。

接下来，方法500进行至504和506。在504处，方法500包括确定患者是否能够耐受药物更新，并且在506处，方法500包括确定患者是否正在经历任何副作用。在一个实例中，如果一个或多个生理参数(例如，心率、SBP、氧饱和度、温度、呼吸率、稳定性程度等)在处方后监测期间处于各自的阈值和/或阈值范围内，并且如果患者的问卷未指示副作用或不耐受，则方法500可确定患者能够耐受药物更新并且不存在副作用。进一步地，在一些实例中，在启动一种或多种药物(例如，MRA、ACEi、ARB、ARNi)之后，决策引擎可生成检查实验室输出。因此，如果在参考患者的患者的健康记录中指示出了实验室结果，则方法500可监测来自EHR的患者数据以及基于实验室结果评估患者是否能够耐受治疗方案更新(例如，启动药物)。

如果患者能够耐受药物更新(即，如果504处的回答为是)并且如果药物更新没有副作用(即，如果506处的回答为否)，则方法500结束，而不对最新的治疗方案更新作任何进一步改变。如果504处的回答为否或506处的回答为是，则方法500进行至510。

在510处，方法500包括运行SDE以确定是否可以停用一种或多种药物或者是否可以减少剂量以提高对药物更新的耐受性和/或减少副作用。方法500还包括在EHR内生成SDE输出。也就是说，可以生成治疗方案的第二次更新。接下来，在512处，临床医生确认EHR内生成的SDE输出。在临床医生确认后，在514处，SDE输出被发送给患者以供认收。进一步地，在患者认收后，对治疗方案作出的SDE输出(即第二处方更新)被自动发送到药房。方法500返回到502以获得另一个处方后监测期。

以这种方式，在治疗方案经更新后监测HF患者，并且如果需要，提供对治疗方案的另外的更新，直到患者能够耐受具有减少的副作用的治疗方案。

返回到308，如果稳定性未得到确认，则方法300进行至306。在一个实例中，如果稳定性未得到确认，则方法300可包括评估临床稳定性是否高于第二下阈值。如果答案为是，则方法300可进行至306；否则方法300可结束并且可向患者和临床医生提供关于更新治疗方案尝试失败的一个或多个指示。

在306处，方法300包括运行安全性决策引擎，在这里可停用或减少治疗剂。例如，安全性决策引擎可监测药物副作用、急性肾损伤、高钾血症、低血压和心动过缓的症状。如果来自远程患者监测设备的数据表明患者已达到任何关键安全性阈值，则SDE将建议患者停用或减少一种或多种药物(GDMT或非GDMT药物)的剂量。安全性决策引擎的细节将参考图7进行描述。

接下来，在308处，方法300包括生成安全性决策引擎(SDE)输出。SDE输出包括维持当前治疗方案或更新当前治疗方案以减少一种或多种先前施用的治疗剂(310)(基于GDMT的治疗剂或非基于GDMT的治疗剂)或停用一种或多种先前施用的治疗剂(312)(基于GDMT的治疗剂或非基于GDMT的治疗剂)以及/或者重新检查实验室测试(314)(例如，基本代谢谱、eGFR测试、心脏成像等)。

在一个实例中，重新检查实验室测试输出可响应于以下中的一者或多者来生成：钾水平高于钾水平阈值、δ肌酐水平高于δ肌酐水平阈值、启动MRA类治疗剂、启动血管紧张素转换酶(ACE)抑制剂、启动血管紧张素受体阻滞剂(ARB)以及启动血管紧张素受体脑啡肽酶抑制剂(ARNi)。

在生成SDE输出后，在318处，方法300包括在EHR内生成药物更新和/或实验室订单。在这种情况下，由于执行了SDE，因此临床医生可以审查和批准EHR中的药物更新和/或订单(即，临床医生审查和批准由单独SDE产生的药物更新和/或实验室订单)。因此，在320处，方法300包括将来自SDE的已生成的药物更新和/或实验室订单传输到临床医生以供批准。在接收到临床医生批准后，方法300进行至322。在一些实例中，在某些条件下(诸如收缩压在阈值SBP范围内并且/或者心率在阈值心率范围内)，安全性决策引擎的输出(即，经更新的治疗方案)可被自动批准，并且该方法可从318进行至322。在一些实例中，在确定经更新的方案是否被自动批准时可以考虑其他生理参数诸如呼吸率、氧饱和度和/或温度。在322处，方法300包括将通知传输给患者(例如，经由应用程序136的患者界面)以供认收。该通知可包括仅执行了SDE以及药物更新和/或实验室检查订单已被临床医生审查和批准的指示(或响应于如上文所讨论达到一个或多个条件而自动生成的指示)。方法300然后进行至348以监测患者对SDE处方的响应，其细节在上文图5处进行了讨论。

以这种方式，来自可佩戴设备的数据整合使得能够在稳定时自动作出决策，并且还使临床医生能够在稳定性水平较低时基于比单次办公室内访视可用的数据量更大的数据量作出GDMT决策。进一步地，剂量滴定过程中的持续远程监测确保当患者稳定时启动或改变药物，并监测患者的药物副作用以便能够快速检测它们。进一步地，还识别了不可能自动启动或向上滴定的临床情形。在这些情况下，执行安全性决策引擎以确定是否需要任何停用或减少以及临床医生将需要在何处作出最终决策。

进一步地，远程监测和远程治疗方案调节使临床医生能够接触到遥远区域，在这种情况下到诊所的重复访视可能不会更具挑战性。还进一步地，通过整合远程监测设备、EHR和/或患者响应的治疗管理减少了患者疲劳，这可以进一步改善患者结局。进一步地，当在临床医生访视(远程或亲自)期间或之前实施时，本文描述的治疗管理方法和系统改进了可用于临床医生-患者交互的时间。

在一个实施方案中，临床医生开具使用数字治疗决策引擎的处方来评估和/或管理心力衰竭患者的治疗方案。开具使用数字治疗决策引擎的处方可包括为各种生理参数(例如，平均心率、平均SBP、最低SBP、稳定性等)和/或通过实验室和/或成像测试获得的各种参数(例如，钾水平、δ肌酐水平、eGFR水平、LVEF百分比等)设置阈值范围和/或阈值。在一些实例中，基于患者的心脏健康状况(其可以基于患者数据(年龄、性别、BMI等)和患者的病史)，可以自动设置开具处方时的阈值范围和/或阈值。

进一步地，在基于来自EHR和远程监测设备(例如，可佩戴设备和/或非可佩戴设备)的输入开具数字治疗决策引擎的处方后，决策引擎可以确定患者是否在临床上稳定到足以改变他或她的药物的程度。如果患者在临床上稳定，该决策引擎确定是否需要临床医生输入，并且如果不需要，该决策引擎自动提供以特定剂量启动一种药物或增加一种药物的剂量以及/或者自动停用或减少药物的剂量以及/或者检查实验室的建议。如果决策引擎启动或增加治疗方案中的药物剂量，患者应用程序可以(1)就作出决策的根本原因教育患者，以及(2)征求患者的认收。一旦获得批准并且作出了药物改变，来自可佩戴设备和患者问卷的数据将被嵌入患者应用程序中，并且将被用于监测患者在患者响应监测期间的任何不良药物副作用。剂量滴定期间的持续远程监测可确保当患者稳定时启动或改变药物，并监测患者的药物副作用以便能够快速检测它们。如果检测到任何不良副作用，则可以执行决策引擎的安全性决策组件，在这种情况下安全性决策组件基于预先指定的参数自动地或通过临床医生输入提供停用特定药物或减少特定药物的剂量的建议等待患者的同意。

在另一个实施方案中，系统包括一个或多个生理传感器，所述生理传感器被配置为从患者获取生理传感器数据的集合；处理系统，所述处理系统包括通信地耦接到存储决策引擎的至少一个非暂时性存储器的至少一个处理器，所述至少一个非暂时性存储器存储可执行指令，所述可执行指令在被执行时使处理器：从所述一个或多个生理传感器获取生理传感器数据的集合；从通信地耦接到所述处理器的电子健康记录系统获取患者数据的集合，所述电子健康记录系统存储参考所述患者的患者数据，所述患者数据包括一种或多种治疗剂和相关剂量；在第一条件期间，当所述患者的稳定性高于第一阈值时，根据所述决策引擎的第一操作模式处理所述生理传感器数据的集合和所述患者数据的集合，并且输出基于所述治疗方案的第一经更新的治疗方案，所述治疗方案包括所述一种或多种治疗剂和相关剂量；以及在第二条件期间，当所述患者的稳定性低于第一阈值时，根据所述决策引擎的第二操作模式处理所述生理传感器数据的集合和所述患者数据的集合，并且输出基于所述治疗方案的第二经更新的治疗方案。在一个实例中，根据决策引擎的第一操作模式的处理包括运行启动和给药引擎，并且根据第二操作模式的处理包括运行安全性决策引擎。在一个实例中，该生理传感器数据的集合包括心电图(ECG)数据、血压数据、光学体积描记图(PPG)数据、陀螺仪数据、加速度计数据和身体温度数据中的一者或多者。进一步地，在一个实例中，患者的稳定性是基于该生理传感器数据的集合确定的。进一步地，在一些实例中，所述决策引擎的所述第一操作模式包括更新所述治疗方案以提供所述一种或多种治疗剂的相关剂量的改变和/或启动一种或多种新治疗剂，或提供所述一种或多种治疗剂的停用和/或启动所述一种或多种新治疗剂；并且所述决策引擎的所述第二操作模式更新所述治疗方案以在不启动所述一种或多种新治疗剂的情况下提供所述一种或多种治疗剂的减少或所述一种或多种治疗剂的停用中的一者或多者。在一些实例中，所述一种或多种治疗剂和所述一种或多种新治疗剂中的每一者均选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

转向图4A，其示出高级流程图，该图例示出根据本公开的另一个实施方案的用于响应于临床医生开具评估和/或维持HF患者的治疗方案的处方而启动启动和给药引擎的示例方法400。

方法400在402处开始。在402处，方法400包括接收来自患者的一个或多个生理传感器数据以及来自患者EHR的一个或多个患者数据。步骤402类似于302，并且为了简洁将不作重复。

接下来，在404处，方法400包括从EHR接收启动或向上滴定一种或多种GDMT药物的多次不成功尝试。例如，如果患者在临床上不稳定，则启动和给药引擎可能不会被启动，因此，不成功的尝试可能会被指示(例如，经由计数器)，并且该患者的导致不成功尝试的一个或多个生理参数可能会被指示，并且存储在一个或多个心脏健康数据库和EHR中以供以后检索。在一些实例中，如果启动和给药引擎被启动，但是由于对启动的或向上滴定的治疗剂引起的不耐受和副作用中的一者或多者，启动的或向上滴定的治疗剂可以基于患者响应而被停用或减少。因此，此类其中患者对启动的或向上滴定的治疗剂的响应导致第二次更新以停用或减少治疗剂的剂量的事件可被视为启动或向上滴定一种或多种GDMT药物的不成功尝试。进一步地，对于每次不成功的启动或向上滴定的尝试，可以指示在不成功事件时一个或多个生理参数的相应原因和/或状态。

进一步地，在404处，方法400包括经由EHR获取一种或多种已知的对基于GDMT的治疗剂的不耐受。

接下来，在405处，该方法包括确定不成功尝试的次数大于零。如果在405的回答为否，则方法400进行至406。在406处，该方法包括在运行启动和给药引擎之前，自动设置一个或多个滴定参数，包括平均SBP范围，平均DBP范围，最低SBP范围，平均心率范围以及包括钾、肌酐、δ肌酐和eGFR在内的实验室参数的范围和/或阈值。在一个实例中，自动滴定参数可基于临床医生在开具自动启动和给药引擎的处方时的初始指示。

如果在405处的回答为是，则方法进行至408。在408处，方法400包括响应于检测到先前不成功的尝试(即，当不成功尝试的次数大于零时)，接收一个或多个滴定参数的临床医生确认和/或规范。

在设置一个或多个滴定参数后，方法400进行至410。在410处，该方法包括基于远程监测传感器数据确定患者稳定性。患者稳定性的确定在方法300的步骤304中有讨论，因此将不作重复。在确定患者稳定性后，方法400进行至412以评估患者的临床稳定性是否得到确认或者患者的稳定性得分是否大于阈值稳定性得分。如果在412处的回答为是，则方法400进行至420以运行启动和给药引擎。如果在412处的回答为否，则方法400不启动IDE，并且随后在416处，方法400包括指示启动或向上滴定GDMT药物的不成功尝试。

在一个实例中，响应于启动或向上滴定GDMT的不成功尝试，如图3所讨论的，可以启动安全性决策引擎。然而，在一些实例中，可在阈值持续时间内连续监测患者的稳定性，并且响应于患者的稳定性降低到低于第二下阈值，可以向临床医生和/或患者提供指示稳定性状况不佳的一个或多个警报，从而促使临床医生和/或患者(或护理人员)立即采取行动来改善患者的稳定性(例如，经由住院)。

返回到420，在运行启动和给药引擎后，方法400进行至在图4B处继续的424。

在424处，方法400包括确定处方和/或实验室订单是否在EHR内由启动和给药引擎生成。该处方可以是启动一种或多种药物、增加一种或多种药物的剂量、减少一种或多种药物的剂量以及/或者停用一种或多种药物。如果在424处的回答为否，则该方法进行至426以维持当前的治疗方案。然后方法400结束。

如果在424处的回答为是，则方法400进行至428。在428处，方法400包括确定一个或多个选定的生理参数是否在相应的期望范围内。所述一个或多个选定的生理参数可包括平均SBP、平均DBP和平均心率中的一者或多者。此步骤的阈值可能更严格。例如，阈值血压范围和阈值心率范围可以更窄以便执行经更新的治疗方案的自动批准。如果在428处的回答为是，则方法400进行至430以基于启动和给药引擎的输出，在EHR内基于经更新的治疗方案(基于IDE的输出)自动生成(和批准)相应处方。如果在428处的回答是否，则方法400进行至432。在432处，方法400包括传输相应的处方给临床医生并接收临床医生的批准。

在(自动地或经由临床医生)批准后，方法400进行至434以通知患者。接下来，在436处，响应于接收到来自患者的认收，方法400包括将经批准的处方传输到药房。

接下来，在438处，方法400包括确定患者是否已经启动经更新的治疗方案。如果是，方法400进行至440，以监测对经更新的治疗方案的响应，如图5所讨论的。监测对经更新的治疗方案的响应可包括(在442处)基于经由一个或多个远程监测设备监测的患者响应和/或患者对问卷答复的指示进一步更新治疗方案，如图5所讨论的。如果在438处的回答为否，方法400可继续监测来自患者的启动经更新的治疗剂的指示。

以这种方式，可以高效地为心力衰竭患者提供基于指南的药物疗法。通过监测患者在更新治疗方案之前和之后的生理参数，并利用来自EHR的输入以及来自患者(或护理人员)的输入，可以高效地监测患者对任何药物调整的耐受性，这又允许有效的药物更新达到HF疗法的目标剂量。因此，HF疗法不仅可在逐例患者的基础上高效地定制和/或个性化，而且还根据患者的进展以纵向方式(随时间)为每个患者进行更新。在一些情况下，通过组合这些各种输入(来自传感器、患者EHR、患者输入等)，如果总体患者参数显示不需要药物更新或改变，则可以减少不必要的药物改变，这也可以改善患者结局。进一步地，决策引擎还使临床医生能够减少临床惯性。还进一步地，作出决策的效率得到改善，这使临床医生有更多时间用于疗法的其他方面。

作为非限制性实例，具有慢性肾病、缺血性心肌病、射血分数降低20％的正在接受心力衰竭疗法的患者目前被开具包含一种或多种治疗剂的第一治疗方案的处方。响应于稳定状况(例如，从一个或多个远程患者监测传感器测量的生理参数和患者报告的对当前药物和相关剂量的耐受性)，决策引擎可生成第二治疗方案以包括新治疗剂。在施用新治疗方案并患者确认摄入新治疗剂后，决策引擎可以经由一个或多个远程患者监测传感器和患者报告数据(经由应用程序输入)监测患者对新治疗剂的响应。在患者响应监测期间，响应于指示不耐受和副作用(例如，头晕或晕厥)中的一者或多者的远程监测数据和/或患者报告数据，决策引擎可以以第二模式(例如，安全性决策引擎)运行决策引擎并且生成第三治疗方案以减少新治疗剂的剂量或停用新治疗剂。决策引擎可继续监测患者对第三治疗方案的响应以确定是否需要进一步更新或维持第三治疗方案。在一些实例中，在生成经更新的治疗方案并确定患者能够耐受经更新的治疗方案之后，可能有一段监测患者响应但不进行更新的时间(在下一次更新之前)。

作为另一个实例，监测正在接受HF疗法且当前处于第一治疗方案下的患者的决策引擎可以使用来自一个或多个生理传感器的数据来识别心脏状况事件(例如，房颤)。响应于此，决策引擎可以生成具有启动血液稀释剂的经更新的治疗方案。决策引擎在接收到摄入/施用经更新治疗方案的确认后可以执行如上所讨论的患者响应监测。

作为又另一实例，决策引擎可以管理患有前壁心肌梗塞的42岁HF患者的HF疗法。该患者可以启动包含卡维地洛和诺欣妥以及相关剂量的治疗方案。响应于指示对更高剂量的诺欣妥不耐受的实验室结果，决策引擎可生成具有更低剂量的诺欣妥的经更新的方案。

接下来转向图6A至图6D，其示出用于更新HF患者的治疗方案的示例方法600。特别地，方法600示出启动和给药引擎(IDE)的操作。在启动IDE之前，可以执行稳定性检查，并且可以向IDE提供(自动地或基于临床医生指示)一种或多种基于GDMT的治疗剂的治疗剂量限度，如图3、图4A和图4B处所讨论的。进一步地，只有当患者被确认为在临床上稳定时，才能启动IDE以启动治疗剂和/或向上滴定当前开具的治疗剂的处方。

进一步地，下面的方法600将针对各种生理参数(经由一个或多个生理传感器估计和/或测量)和实验室参数(从患者的EHR获取)的示例阈值和/或范围来描述；然而，应当理解，范围和阈值可基于患者的给定健康状况来定制。

方法600在602处开始。在602处，方法600包括确定基于GDMT的治疗剂和非基于GDMT的治疗剂的组合是否包括在HF患者的治疗方案中。基于GDMT的治疗剂是根据指南指导的药物疗法(GDMT)开具给HF患者的治疗剂的处方。非基于GDMT的治疗剂是GDMT中未指明的治疗剂。

如果在602处的回答为是，则方法600进行至604以停止组合药物并且随后进行至606以开始除沙库巴曲/缬沙坦之外的成分，然后进行至608。如果在602处的回答为否，则方法600直接进行至608。

在608处，方法600包括运行安全性决策引擎(SDE)。SDE可监测急性肾损伤、高钾血症、低血压和心动过缓中的一者或多者的指征。进一步地，如果远程患者监测数据表明患者已达到任何关键安全性阈值，则SDE可能会建议患者停用或减少治疗剂的剂量，或者提供重新检查一项或多项实验室测试的指示。因此，在增加治疗剂的剂量和/或启动新治疗剂之前，可以执行SDE。SDE的细节参照图7进行描述。

在运行SDE后，方法600进行至610。在610处，方法600包括确定SDE是否已经指示减少或停用一种或多种药物。如果是，方法600进行至614以基于SDE输出更新治疗方案以减少治疗剂和/或停用第二治疗剂。如果SDE输出指示没有滴定(即，如果在610处的回答为否)，则方法600进行至612以在SDE输出之后维持当前治疗方案。方法600在SDE之后更新或维持治疗方案后进行至616。

在616处，方法600包括确定收缩压(SBP)是否小于或等于140mm Hg。如果是，方法600进行至618。在618处，方法600包括确定患者是否正在用非GDMT高血压药物。如果患者正在用非GDMT高血压药物，则在618处的回答为是，并且该方法进行至620。在620处，方法600包括减少非GDMT高血压药物或停用非GDMT高血压药物。例如，如果SBP小于或等于120mmHg，则停用非GDMT高血压药物，或者如果SBP在120和140mm Hg之间，则将非GDMT高血压药物降低一个水平。

返回到616，如果在616处的答案为否(即，如果SBP大于140mm Hg)，则方法600进行至在图6B处继续的622。现在参考图6B，在622处，方法600包括确定患者是否正在用非二氢吡啶钙通道阻滞剂。如果在622处的回答为是，则方法600进行至624。在624处，方法600包括基于SBP和当前BB类型和剂量调整血压药物或β阻滞剂(BB)药物。例如，如果SBP大于或等于110，则可以启动GDMT BB或可以增加GDMT BB的剂量，或者可以将非GDMT BB转化为等剂量的GDMT BB。进一步地，如果SBP大于或等于100但小于110，则向美托洛尔的转化或剂量增加可以被执行直至水平3。如果SBP小于100，可以停用非二氢吡啶。方法600随后返回至626。

返回至626，方法600包括确定是否达到MRA启动和/或SLGT2调整的条件。在一个实例中，用于MRA和/或SLGT2调整的条件可包括1)患者正在用GDMT BB和血管紧张素受体-脑啡肽酶抑制剂(ARNi)并且SBP小于140且心率(HR)小于80，或2)患者对ARNi不耐受且正在用GDMT BB且正在用(血管紧张素转换酶抑制剂(ACEi)水平3、4或5，或正在用血管紧张素II受体阻滞剂(ARB)水平2、3、4或5)并且收缩压低于140且HR小于80。

如果在626处的回答为是，则方法600进行至628；否则方法600进行至图6C处继续的636。在628处，方法600包括确定SBP是否大于95以及δ肌酐水平是否小于0.5。如果在628处的回答为否，则该方法进行至图6C处的636。如果在628处的回答为是，则方法600进行至630以确定是否能够启动螺内酯(MRA)和/或达格列净(SLGT2)(即，如果患者的EHR中没有指示出MRA和/或SLGT2的既往不耐受或副作用)。如果否，则方法600进行至图6C处的636。如果在630处的回答为是，则方法600进行至632以确定当前是否开具MRA和SLGT2的处方。如果在632处的回答为是，则方法600进行至图6C处的636；否则，如果当前未开具MRA或SLGT2的处方，则方法600进行至634。在634处，方法600包括基于钾、δ肌酐、射血分数、性别、肌酐和当前达格列净(SLGT2)或螺内酯(MRA)处方中的一者或多者启动SLGT2或MRA。

参考图6C，其从图6B继续。在636处，方法600包括确定HR是否大于或等于65以及是否能够增加GDMT BB。如果在636处的回答为是，则方法600进行至638以确定患者当前是否正在用BB药物。如果在638处的答案为否，则患者没有正在用BB，并且方法进行至660以基于收缩压、永久起搏器的存在、是否正在用ACEi/ARB/ARNi，和/或心率启动美托洛尔或卡维地洛或者确定不滴定。如果在638处的回答为是，则方法600进行至640以确定患者是否正在用GDMT BB。如果患者没有正在用GDMT BB，则在640处的回答为否，并且方法600进行至642。在642处，方法600包括基于SBP和/或HR转换为GDMT BB或停用非GDMTBB。返回到640，如果患者正在用GDMT BB，则方法600进行至图6D处的670。

返回到636，如果HR小于或等于65并且不能增加GDMT BB，则在636处的回答为否，并且该方法进行至644。在644处，方法600包括确定患者是否正在用非GDMT BB。如果在644处的回答为是，则该方法进行至642以基于SBP和/或HR转换为GDMT BB或停用非GDMT BB。如果在644处的回答为否，则方法600进行至646以确定患者是否正在用ACEi/ARNi/ARB。如果在646处的回答为否，则方法600进行至652。在652处，方法600包括基于SBP、钾、δ肌酐和/或ARNi不耐受开始沙库巴曲/缬沙坦，或以水平2开始ACEi，或以水平3开始ACEi，或开始赖诺普利或者不执行滴定。如果在646处的回答为是，则方法进行至648以首先确定患者是否正在用GDMT BB，并且如果是，则方法600进行至654以优化ACEi/ARNi/ARB。如果在648处的回答为否，则方法600进行至659以确定患者是否正使用起搏器。如果是，则方法600进行至660。如果在659处的回答为否，则方法600进行至662。在662处，方法600包括响应于心率大于60启动美托洛尔；否则，方法600包括确定是否能够启动SGLT2和/或MRA。方法600随后进行至664。如果达到664处的条件，则方法600进行至666以基于SBP≥100向上滴定GDMT BB或ARNI；否则不执行滴定。如果没达到664处的条件，则方法600进行至图6D处的680。

现在参考图6D，它是图6C的继续。在670处，方法600包括确定患者是否正在用ACEi、ARB和ARNI中的一者或多者。如果在670处的回答为否，则方法进行至674。在674处，方法600包括如果可耐受，则基于SBP、K和dCr启动ARNi；否则启动ACEi。如果不满足SBP>95并且K<5.0&dCr 0.5，则无需滴定。如果在670处的回答为是，则方法600进行至672以确定HR是否大于或等于80以及SBP和/或GDMT BB条件是否指示向上滴定。如果是，则方法600进行至676以基于快速心率来向上滴定GDMT BB。如果在672处的回答为否，则方法600进行至678以更新GDMT BB，或启动或更新ARNi，或更新ARNi，或如果患者为ARNi不耐受，则更新ACE或ARB。

接下来，方法600进行至680。在680处，方法600包括如果不能优化GDMT BB、ARNi、ACEi或ARB，则启动MRA，或者如果尚未用SGTL2，则启动SGTL2。然后600方法结束。

接下来参考图7，它示出高级流程图，该高级流程图例示出用于减少或停用HF患者的治疗方案中的一种或多种治疗剂的示例方法700。特别地，方法700可在决策引擎以安全性决策引擎(SDE)模式(也称为决策引擎的第二模式)操作时实施，诸如在患者稳定性低于阈值时实施，或者为了监测患者对治疗方案的改变(例如，在治疗剂自先前的治疗方案更新起已被增加或启动或减少或停用后)的响应而实施。因此，方法700可被实施用于监测药物副作用、急性肾损伤、高钾血症、低血压和心动过缓的症状。如果来自一个或多个生理传感器的指示(例如，远程监测数据)显示患者已经达到任何生理参数阈值，则方法700可生成经更新的治疗方案，其中经更新的治疗方案包括与一种或多种治疗剂相关的剂量的停用或减少。在一些实例中，方法700可建议更新，然后临床医生可以批准该用于更新治疗方案的建议。在一些其他实例中，方法700可以自动生成对治疗方案的更新。

方法700在702处开始。在702处，方法700包括确定钾水平是否大于或等于5nmol/L或者δ肌酐值是否大于或等于0.5mg/dL。如果是，则方法700进行至704以确定患者是否正在用KCl。如果是，则方法700进行至706以更新治疗方案以停用KCl，然后返回到760。如果患者没有正在用KCl，则方法700从704进行至760。

在760处，方法700包括基于δ肌酐水平和/或钾水平，以及是否正在用MRA、ACEi或ARB或ARNi来更新以调整治疗方案以减少或停用MRA剂量(752)，或减少或停用ACEi剂量(754)，或减少或停用ARB剂量(756)，或减少或停用ARNi剂量(758)。特别地，如果患者的钾水平在5.5和6之间，并且如果患者正在用MRA，那么如果当前处于水平5、4、3或2，则更新MRA剂量以降低到较低水平。如果MRA剂量目前处于水平1，则该更新包括停用MRA。进一步地，如果患者正在用MRA并且δ肌酐水平大于或等于0.5，或者如果患者正在用MRA并且钾水平大于6，则方法700更新治疗方案以停用MRA。类似地，基于患者是否正在用ACEi、ARB或ARNi，并且基于患者的钾和δ肌酐水平，可以停用ACEi、ARB或ARNi，或者可以减少相应的剂量。

以这种方式，基于可从来自患者EHR的患者数据获得的患者的钾(K)和/或δ肌酐水平(dCr)的实验室结果，并且基于也可从来自患者EHR的患者数据获得的当前治疗方案，方法700提供更新以减少剂量到较低水平或停用治疗剂。因此，在对治疗方案进行更新以减少或停用治疗剂时考虑由钾和δ肌酐水平指示的肾功能。

返回到702，如果回答为否，则方法700进行至708。在708处，方法700包括确定平均SBP是否小于或等于95以及最低SBP是否小于90。如上所讨论，在一个实例中，血压值(例如，平均SBP、最低SBP、平均DBP)可以从远程血压监测设备接收，并且可以指示监测期内的血压值。在一些实例中，处理系统(例如，服务器150)可以从远程血压监测设备接收原始或经预处理的数据，并且计算监测期内的血压值。在任何情况下，远程监测的血压数据都用于提供对治疗方案的调整。

如果在708处的回答为是，则方法700进行至720。在720处，方法700包括基于心率(HR)小于心动过缓阈值以及/或者最低SBP小于90mm Hg，以及是否正在用非GDMT高血压药物或BB或ACEi或ARB或ARNi来提供更新。特别地，提供更新以调整治疗方案以停用非GDMT高血压药物(722)，或减少或停用BB(724)，或减少或停用ACEi(726)，或减少或停用ARB(730)，或减少或停用ARNi(732)。也就是说，如果患者仅正在用BB，或仅正在用ACEi，或仅正在用ARB，或仅正在用ARNi，则基于最低SBP小于90以及/或者心率小于阈值(例如，60)将相应的药物减少至较低水平或停用。

接下来，方法700进行至740。在740处，方法700包括基于患者是否正在用β阻滞剂(BB)和ACEi、ARB或ARNi的组合，以及最低SBP小于90且HR小于第二阈值(例如，65)(其可以大于720处的阈值)更新治疗方案，其中所述更新包括减少或停用BB或ACEi、ARB或ARNi中的一者。也就是说，提供更新以减少或停用BB(742)，或减少或停用ACEi(744)，或减少或停用ARB(746)，或减少或停用ARNi(748)，或不滴定(750)。然后方法700结束。

以这种方式，方法700使用来自EHR的患者数据检查血清电解质(钾)和代谢物(δ肌酐)水平以检查高钾血症和异常肾功能的指征，使用远程监测数据检查生理参数(例如，最低SBP、平均SBP、HR)以检查低血压和心动过缓的指征，并且提供治疗方案的更新，例如，减少或停用一种或多种治疗剂。

虽然以上实例描述了由安全性决策引擎执行的更新，但在一些实例中，以上讨论的更新中的一个或多个更新可以作为对治疗方案的建议提供。进一步地，在临床医生审查和批准后，可以按安全性决策引擎提供的建议来更新治疗方案。

在一个实施方案中，方法包括：基于经由一个或多个远程监测设备获取的患者的一个或多个生理参数以及经由患者的健康记录获取的患者数据的集合来为心力衰竭患者生成经更新的治疗方案；以及向所述患者施用经更新的治疗方案；其中所述经更新的治疗方案包括至少一种先前施用的治疗剂的剂量的增加和新治疗剂的启动中的一者或多者，所述新治疗剂不同于所述先前施用的治疗剂。替代地，所述经更新的方案包括减少或停用先前施用的治疗剂的剂量。

在另一个实施方案中，方法包括：接收从可佩戴传感器输出的患有心力衰竭病状的患者的心率数据的集合；接收参考所述患者的患者概况，所述患者概况包括治疗剂量方案，所述治疗剂量方案包括至少一种治疗剂和相关剂量；使用模型处理所述心率数据的集合以修改治疗剂量方案并输出经更新的治疗剂量方案；以及向患者施用经更新的治疗剂量方案。在所述方法的第一实例中，使用所述模型处理所述心率数据的集合以修改治疗剂量方案还包括：接收从血压传感器输出的血压数据的集合；以及使用所述模型处理所述血压数据的集合。在所述方法的任选地包括所述第一实例的第二实例中，所述心率数据的集合包括1、2、3、4、5或6小时内的平均心率。在所述方法的任选地包括所述第一实例和所述第二实例中的一者或多者的第三实例中，所述心率数据的集合包括平均每周心率。在所述方法的任选地包括所述第一至第三实例中的一者或多者的第四实例中，所述模型包括将所述心率数据的集合与预定的阈值心率进行比较。在所述方法的任选地包括第一至第四实例中的一者或多者的第五实例中，所述至少一种治疗剂是至少一种选自阿替洛尔、倍他洛尔、比索洛尔、卡维地洛、艾司洛尔、拉贝洛尔、美托洛尔、纳多洛尔、吲哚洛尔、普萘洛尔、索他洛尔、噻吗洛尔、醋丁洛尔、氧烯洛尔、卡维地洛和喷布洛尔的β阻滞剂。在所述方法的任选地包括第一至第四实例中的一者或多者的第六实例中，所述至少一种治疗剂是比索洛尔、卡维地洛、琥珀酸美托洛尔、卡托普利、依那普利、福辛普利、赖诺普利、培哚普利、喹那普利、雷米普利、群多普利、坎地沙坦、氯沙坦、缬沙坦、奥美沙坦、沙库巴曲/缬沙坦、螺内酯或依普利酮中的至少一者或多者。在所述方法的任选地包括第一至第六实例中的一者或多者的第七实例中，所述患者概况包括先前施用于所述患者的至少一种第一治疗剂，并且其中所述经更新的治疗剂量方案包括不同于所述至少第一治疗剂的至少第二治疗剂。在所述方法的任选地包括第一至第九实例中的一者或多者的第八实例中，所述心率数据的集合包括平均每周心率，并且所述预定阈值心率包括55、56、57、58、59、60、61、62、63、64或65bpm。在所述方法的任选地包括所述第一至第八实例中的一者或多者的第九实例中，所述模型包括以预定顺序依序施用的治疗物的集合。在所述方法的任选地包括第一至第九实例中的一者或多者的第十实例中，所述心率数据的集合包括至少4小时的平均心率，并且所述预定阈值心率包括低于50bpm。在所述方法的任选地包括第一至第十实例中的一者或多者的第十一实例中，所述模型包括基于至少一种治疗物的类别和先前施用于所述患者的治疗物的类别的集合确定所述至少一种治疗物。

在另一个实施方案中，提供了一种用于管理被诊断患有心力衰竭的患者的治疗方案的方法，所述方法包括：接收在第一时间段期间从患者获取的生理传感器数据的第一集合，所述生理传感器数据的第一集合经由一台或多台远程监测设备输出；从参考所述患者的患者概况接收患者数据的集合，所述患者数据的集合包括治疗方案，所述治疗方案包括至少一种治疗剂和相关剂量；基于患者稳定性处理所述生理传感器数据的第一集合和所述患者数据的集合以输出经更新的治疗方案；以及向所述患者施用所述经更新的治疗方案。在所述方法的第一实例中，基于患者稳定性处理所述生理传感器数据的第一集合和所述患者数据的集合包括基于所述生理传感器数据的第一集合确定患者的稳定性得分，以及响应于所述稳定性得分大于阈值得分而输出经更新的治疗方案；否则，继续施用所述治疗方案于患者而不更新。在所述方法的任选地包括所述第一实例的第二实例中，所述经更新的治疗方案包括所述至少一种治疗剂或至少第二治疗剂的相关剂量和用于所述第二治疗剂的第二相关剂量的改变，所述第二治疗剂不同于所述至少一种治疗剂。在所述方法的任选地包括所述第一实例和所述第二实例中的一者或多者的第三实例中，所述经更新的治疗方案包括所述至少一种治疗剂的停用。在所述方法的任选地包括所述第一至第三实例中的一者或多者的第四实例中，处理所述生理传感器数据的第一集合和所述患者数据的集合以输出经更新的治疗方案还包括生成一个或多个警报，所述一个或多个警报包括执行实验室测试和成像测试中的一者或多者的指示。在所述方法的任选地包括所述第一至第四实例中的一者或多者的第五实例中，通过从患者接收到的指示的集合和在第二时间段期间从患者获取的生理传感器数据的第二集合中的一者或多者监测患者对经更新的治疗方案的响应，所述生理传感器数据的第二集合经由所述一个或多个远程监测设备输出；并且响应于指示对经更新方案不耐受和经更新方案有副作用中的一者或多者的患者响应，处理所述生理传感器数据的第二集合和所述患者数据的集合以输出第二经更新的治疗方案，以及向患者施用第二经更新的治疗方案；否则，继续施用经更新的治疗方案。在所述方法的任选地包括所述第一至第五实例中的一者或多者的第六实例中，所述第二经更新的治疗方案包括所述第二治疗剂的第二相关剂量的改变或所述第二治疗剂的停用。在所述方法的任选地包括所述第一至第六实例中的一者或多者的第七实例中，处理所述生理传感器数据的第二集合和所述患者数据的集合以输出第二经更新的治疗方案是基于钾水平、δ肌酐水平、最低收缩压、平均收缩压和平均心率中的一者或多者。在所述方法的任选地包括所述第一至第七实例中的一者或多者的第八实例中，处理所述生理传感器数据的第一集合和所述患者数据的集合以输出经更新的治疗方案是基于指南指导的药物疗法(GDMT)。在所述方法的任选地包括所述第一至第八实例中的一者或多者的第九实例中，所述生理传感器数据的第一集合包括用于测量患者的平均心率的心电图(ECG)数据和用于测量平均收缩压、平均舒张压和最低收缩压的血压数据中的一者或多者；并且其中所述患者数据包括钾水平、δ肌酐水平、肌酐水平、eGFR水平、左心室射血分数、心力衰竭类型、患者身高、患者体重和患者性别中的一者或多者。在所述方法的任选地包括所述第一至第九实例中的一者或多者的第十实例中，所述生理传感器数据的第一集合还包括用于测量患者摇摆程度的陀螺仪数据和加速度计数据中的一者或多者。在所述方法的任选地包括所述第一至第十实例中的一者或多者的第十一实例中，其中稳定性得分是基于患者的平均心率、平均收缩压和摇摆程度中的一者或多者。在所述方法的任选地包括所述第一至第十一实例中的一者或多者的第十二实例中，所述一个或多个远程监测设备中的至少一个是可佩戴设备。在所述方法的任选地包括所述第一至第十二实例中的一者或多者的第十三实例中，所述至少一种治疗剂是至少一种选自阿替洛尔、倍他洛尔、比索洛尔、卡维地洛、艾司洛尔、拉贝洛尔、美托洛尔、纳多洛尔、吲哚洛尔、普萘洛尔、索他洛尔、噻吗洛尔、醋丁洛尔、氧烯洛尔、卡维地洛和喷布洛尔的β阻滞剂。在所述方法的任选地包括第一至第十三实例中的一者或多者的第十四实例中，所述至少一种治疗剂是比索洛尔、卡维地洛、琥珀酸美托洛尔、卡托普利、依那普利、福辛普利、赖诺普利、培哚普利、喹那普利、雷米普利、群多普利、坎地沙坦、氯沙坦、缬沙坦、奥美沙坦、沙库巴曲/缬沙坦、螺内酯、依普利酮、达格列净、恩格列净、卡格列净和艾托格列净中的至少一者或多者。在所述方法的任选地包括第一至第十四实例中的一者或多者的第十五实例中，所述至少一种治疗剂和所述至少第二治疗剂中的每一者都选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

在另一个实施方案中，方法包括：基于经由一个或多个远程监测设备获取的患者的生理参数的第一集合以及经由所述患者的健康记录获取的患者数据的集合为被诊断患有心力衰竭的患者生成经更新的治疗方案；以及向所述患者施用所述经更新的治疗方案；其中所述经更新的治疗方案包括至少一种先前施用的治疗剂的剂量的改变和/或一种新治疗剂的启动，所述新治疗剂不同于先前施用的治疗剂。在所述方法的第一实例中，生成所述经更新的治疗方案是基于患者耐受所述至少一种先前施用的治疗剂的向上滴定和/或所述至少一种新治疗剂的启动的稳定性。在所述方法的任选地包括所述第一实例的第二实例中，所述患者的稳定性是基于在阈值心率范围内的平均心率、在阈值收缩压范围内的平均收缩压以及在阈值范围内的所述患者的摇摆程度中的一者或多者。在所述方法的任选地包括所述第一实例和所述第二实例中的一者或多者的第三实例中，所述方法还包括通过在施用经更新的治疗方案之后从患者接收到的副作用的指示的集合和经由所述一个或多个远程监测设备从患者获取的生理参数的第二集合中的一者或多者监测患者对经更新治疗方案的响应；并且响应于指示对经更新方案不耐受和经更新方案有副作用中的一者或多者的患者响应，基于所述生理参数的第二集合和所述患者数据的集合生成第二经更新的治疗方案，以及向所述患者施用第二经更新的治疗方案；否则，继续施用所述经更新的治疗方案。在所述方法的任选地包括所述第一至第三实例中的一者或多者的第四实例中，所述生理传感器数据的第一集合包括平均心率、平均收缩压、平均舒张压和最低收缩压中的一者或多者；并且其中患者数据包括钾水平、δ肌酐水平、肌酐水平、eGFR水平、左心室射血分数、心力衰竭类型、患者身高、患者体重和患者性别中的一者或多者。在所述方法的任选地包括所述第一至第四实例中的一者或多者的第五实例中，其中向患者施用所述经更新的方案包括将所述经更新的治疗方案自动存储在患者的健康记录内并且向患者传输通知，所述通知包括所述经更新方案中的新治疗剂和关于所述新治疗剂的指导性指示。在所述方法的任选地包括所述第一至第五实例中的一者或多者的第六实例中，所述方法包括将所述经更新的治疗方案自动传输至在所述患者的健康记录中提及的相关药房计算系统。在所述方法的任选地包括第一至第六实例中的一者或多者的第七实例中，所述至少一种先前施用的治疗剂和所述至少一种新治疗剂中的每一者都选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

在另一个实施方案中，用于管理患有心力衰竭的患者的治疗方案的系统包括一个或多个生理传感器，所述生理传感器被配置为从患者获取生理传感器数据的集合；处理系统，所述处理系统包括通信地耦接到存储决策引擎的至少一个非暂时性存储器的至少一个处理器，所述至少一个非暂时性存储器存储可执行指令，所述可执行指令在被执行时使处理器：从所述一个或多个生理传感器获取生理传感器数据的集合；从通信地耦接到所述处理器的电子健康记录系统获取患者数据的集合，所述电子健康记录系统存储参考所述患者的患者数据，所述患者数据包括一种或多种治疗剂和相关剂量；在第一条件期间，当所述患者的稳定性高于第一阈值时，根据所述决策引擎的第一操作模式处理所述生理传感器数据的集合和所述患者数据的集合，并且输出基于所述治疗方案的第一经更新的治疗方案，所述治疗方案包括所述一种或多种治疗剂和相关剂量；以及在第二条件期间，当所述患者的稳定性低于第一阈值时，根据所述决策引擎的第二操作模式处理所述生理传感器数据的集合和所述患者数据的集合，并且输出基于所述治疗方案的第二经更新的治疗方案。在所述系统的第一实例中，所述生理传感器数据的集合包括心电图(ECG)数据、血压数据、光学体积描记图(PPG)数据、陀螺仪数据、加速度计数据和身体温度数据中的一者或多者。在所述系统的任选地包括所述第一实例的第二实例中，其中所述患者的稳定性是基于所述生理传感器数据的集合来确定的。在所述系统的任选地包括所述第一实例和所述第二实例中的一者或多者的第三实例中，所述决策引擎的所述第一操作模式包括更新所述治疗方案以提供所述一种或多种治疗剂的相关剂量的改变和/或启动一种或多种新治疗剂，或提供所述一种或多种治疗剂的停用和/或启动所述一种或多种新治疗剂；并且其中所述决策引擎的所述第二操作模式更新所述治疗方案以在不启动所述一种或多种新治疗剂的情况下提供所述一种或多种治疗剂的减少或所述一种或多种治疗剂的停用中的一者或多者。在所述系统的任选地包括第一至第三实例中的一者或多者的第四实例中，所述一种或多种治疗剂和所述一种或多种新治疗剂中的每一者都选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

在一种表示中，一种用于治疗被诊断患有心力衰竭的患者的方法，所述方法包括：基于来自一个或多个远程患者监测设备的一个或多个输出和/或来自参考患者的患者电子概况的一个或多个患者数据经由处理器调节所述患者的当前治疗方案；其中所述当前治疗方案包括一种或多种治疗剂和相关剂量；并且其中所述一个或多个患者监测设备包括一个或多个血压传感器、一个或多个ECG传感器、一个或多个陀螺仪和/或一个或多个加速度计。在一个实例中，所述方法还包括向所述患者施用所述经调节的治疗方案。在任选地包括所述第一方法的第二实例中，所述方法还包括基于所述一个或多个远程监测设备和/或来自所述患者的一个或多个患者数据和/或输入经由通信地耦接到所述处理器的患者门户监测对所述经调节的治疗方案的响应。在任选地包括所述第一方法和所述第二方法中的一者或多者的第三实例中，调节当前治疗方案包括增加或减少或停用所述一种或多种治疗剂的相关剂量。在任选地包括所述第一至第三实例中的一者或多者的第四实例中，调节当前治疗方案包括启动一种或多种新治疗剂，所述一种或多种新治疗剂不同于所述一种或多种治疗剂。在任选地包括所述第一至第四实例中的一者或多者的第五实例中，响应于确定所述患者稳定性不低于阈值稳定性水平，调节当前治疗方案以减少或停止所述一种或多种治疗剂的剂量；否则调节当前治疗方案以增加所述一种或多种治疗剂的剂量和/或启动所述一种或多种新治疗剂。在任选地包括所述第一至第五实例中的一者或多者的第六实例中，所述一种或多种治疗剂选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。在任选地包括所述第一至第六实例中的一者或多者的第七实例中，所述一种或多种新治疗剂选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。在任选地包括所述第一至第七实例中的一者或多者的第八实例中，所述一个或多个远程患者监测设备是可佩戴设备。

实施例

提供了以下实施例以更好地说明所要求保护的发明，并且不打算解释为限制本发明的范围。就具体材料或步骤被提及的程度来说，它仅仅为了说明的目的并且不打算限制本发明。本领域技术人员可在不发挥创造性能力且不脱离本发明的范围的情况下开发等效的手段或反应物。

图8A和图8B例示出包括各种患者信息、患者病史和治疗史的应用程序用户界面的实例。因此，系统然后可以通过界面(例如，以虚线示出的显示器)输出新治疗方案。如所示，临床医生界面包括可供临床医生设置各种阈值(包括各种药物的限制)的选项。进一步地，临床医生界面输出包括调节或更新给定治疗方案所涉及的决策状态的一个或多个警报。

图9A和图9B例示出示出用于治疗心力衰竭患者的各种类别的药物和各种剂量水平的表格。例如，在一些实例中，公开了各种决策引擎，该决策引擎可以基于系统所接收到的传感器数据和如本文公开的其他数据将治疗物的剂量滴定至表格中列出的不同水平。

图10A和图10B是例示出供第一心力衰竭患者用的第一治疗方案更新和第二治疗方案更新的框图。图10A和图10B示出供第一患者用的示例决策引擎输入、包括驱动输出建议的逻辑的决策引擎评估状态，以及决策引擎输出建议。

图11A、图11B和图11C是例示出供第二心力衰竭患者用的第一治疗方案更新、第二治疗方案更新和第三治疗方案更新的框图。图11A、图11B和图11C示出供第二患者用的实例决策引擎输入、包括驱动输出建议的逻辑的决策引擎评估状态，以及决策引擎输出建议。

本公开的计算机和硬件实施方式

最初应当理解，本文的公开内容可以用任何类型的硬件和/或软件来实施，并且可以是预编程的通用计算设备。例如，该系统可使用服务器、个人计算机、便携式计算机、精简型客户端或一种或多种任何合适的设备来实施。本公开和/或其组件可以是在单个位置处的单个设备，或在单个或多个位置处的多个设备，所述多个设备使用任何适当的通信协议通过任何通信介质诸如电缆、光纤电缆或以无线方式连接在一起。

还应当注意，本公开在本文中被例示和讨论为具有多个执行特定功能的模块。应当理解，这些模块只是为了清楚起见而仅基于它们的功能被示意性地例示出，并且不一定代表具体的硬件或软件。在这方面，这些模块可以是被实施用于实质上执行所讨论的特定功能的硬件和/或软件。此外，所述模块可以在本公开内组合在一起，或者基于期望的特定功能被划分成另外的模块。因此，该公开内容不应被解读为限制本发明，而仅应被理解为例示出本发明的一个示例实施方式。

计算系统可包括客户端和服务器。客户端和服务器一般彼此远离并且通常通过通信网络进行交互。客户端和服务器的关系通过在各自计算机上运行且相互具有客户端-服务器关系的计算机程序而产生。在一些实施方式中，服务器传输数据(例如，HTML网页)到客户端设备(例如，为了将数据显示给与客户端设备交互的用户以及从与客户端设备交互的用户接收用户输入的目的)。在客户端设备产生的数据(例如，用户交互的结果)可在服务器上从客户端设备接收。

本专利说明书中描述的主题的实施可在计算系统中实施，所述计算系统包括后端组件(例如作为数据服务器)，或包括中间件组件(例如应用服务器)，或包括前端组件(例如，具有图形用户界面或网页浏览器的客户端计算机，用户可通过该图形用户界面或网页浏览器与本专利说明书中描述的主题的实施进行交互)，或一个或多个此类后端、中间件或前端组件的任何组合。系统的组件可通过任何形式或介质的数字数据通信(例如，通信网络)互连。通信网络的实例包括局域网(“LAN”)和广域网(“WAN”)、互联网络(例如，互联网)和对等网络(例如，专用对等网络)。

本专利说明书中描述的主题和操作的实施可在数字电子电路中或在计算机软件、固件或硬件(包括本专利说明书中公开的结构及其结构等同物)中或在它们的一者或多者的组合中实施。本专利说明书中描述的主题的实施可作为一个或多个计算机程序(即，编码在计算机存储介质上以用于由数据处理装置执行或控制数据处理装置的操作的计算机程序指令的一个或多个模块)来实施。替代地或另外地，程序指令可以被编码在人工生成的传播信号(例如，为了编码用于传输到合适的接收器装置以由数据处理装置执行的信息而生成的机器生成的电、光或电磁信号)上。计算机存储介质可以是计算机可读存储设备、计算机可读存储基底、随机或串行存取存储器阵列或设备，或它们中的一者或多者的组合，或者包含在计算机可读存储设备、计算机可读存储基底、随机或串行存取存储器阵列或设备，或它们中的一者或多者的组合中。此外，虽然计算机存储介质不是传播信号，但计算机存储介质可以是编码在人工生成的传播信号中的计算机程序指令的源或目的地。计算机存储介质也可以是一个或多个单独的物理组件或介质(例如，多个CD、磁盘或其他存储设备)，或者包含一个或多个单独的物理组件或介质(例如，多个CD、磁盘或其他存储设备)中。

本专利说明书中描述的操作可以被实施为由“数据处理装置”对存储在一个或多个计算机可读存储设备上或从其他来源接收到的数据执行的操作。

术语“数据处理装置”涵盖用于处理数据的所有种类的装置、设备和机器，包括例如可编程处理器、计算机、片上系统或前述中的多个或组合。所述装置可以包括专用逻辑电路，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)。所述装置除了包括硬件之外，还可包括为所讨论的计算机程序创建执行环境的代码，例如，构成处理器固件、协议栈、数据库管理系统、操作系统、跨平台运行时(runtime)环境、虚拟机或它们中一者或多者的组合的代码。所述装置和执行环境可以实现各种不同的计算模型基础设施，诸如网络服务、分布式计算和网格计算基础设施。

计算机程序(还称为程序、软件、软件应用程序、脚本或代码)可以任何形式的编程语言(包括编译或解释语言、声明性或过程性语言)编写，并且它可以任何形式(包括作为独立程序或作为模块、组件、子例程、对象或适用于计算环境的其他单元)部署。计算机程序可以但不需要对应于文件系统中的文件。程序可以存储在保存其他程序或数据的文件的一部分(例如，存储在标记语言文档中的一个或多个脚本)中，存储在专用于所讨论的程序的单个文件中，或者存储在多个协调文件(例如，存储一个或多个模块、子程序，或代码的部分的文件)中。计算机程序可被部署为在一台计算机上或者在位于一个站点或分布在多个站点并且通过通信网络互连的多台计算机上执行。

本专利说明书中描述的过程和逻辑流程可以由一个或多个执行一个或多个计算机程序的可编程处理器执行，以通过对输入数据进行操作并生成输出来执行动作。过程和逻辑流程也可以由专用逻辑电路，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)执行，并且装置也可以被实施为专用逻辑电路，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)。

适用于执行计算机程序的处理器包括，例如，通用和专用微处理器，以及任何类型的数字计算机的任何一个或多个处理器。一般来说，处理器将从只读存储器或随机存取存储器或两者接收指令和数据。计算机的基本元件是用于根据指令执行动作的处理器和一个或多个用于存储指令和数据的存储设备。通常，计算机还将包括一个或多个用于存储数据的大容量存储设备(例如，磁盘、磁光盘或光盘)，或者被可操作地耦接成从一个或多个用于存储数据的大容量存储设备(例如，磁盘、磁光盘或光盘)接收数据或向该大容量存储设备传递数据或两者兼而有之。然而，计算机不需要具有此类设备。此外，计算机可以嵌入在另一个设备中，该另一个设备为例如移动电话、个人数字助理(PDA)、移动音频或视频播放器、游戏机、全球定位系统(GPS)接收器或便携式存储设备(例如，通用串行总线(USB)闪存驱动器)，仅举几例。适用于存储计算机程序指令和数据的设备包括所有形式的非易失性存储器、介质和存储设备，包括例如半导体存储设备，例如，EPROM、EEPROM和闪存设备；磁盘，例如，内部硬盘或可移动磁盘；磁光盘；以及CD-ROM和DVD-ROM磁盘。处理器和存储器可以由专用逻辑电路补充或并入到专用逻辑电路中。

结论

上文描述的各种方法和技术提供了许多方式来执行本发明。当然，应当理解，根据本文中描述的任何特定实施方案不一定可以实现所描述的所有目标或优点。因此，例如，本领域技术人员将认识到，所述方法可以以实现或优化如本文中所教导的一个优点或一组优点，而不一定会实现如本文中所教导或提出的其他目标或优点的方式执行。本文中提到了多种替代方案。应当理解，一些实施方案明确包括一个、另一个或若干个特征，而其他实施方案明确排除一个、另一个或若干个特征，而还有一些其他实施方案通过包括一个、另一个或若干个有利特征来削弱特定特征。

此外，本领域技术人员将认识到来自不同实施方案的各种特征的适用性。类似地，本领域的普通技术人员可以以各种组合采用上面讨论的各种要素、特征和步骤以及每个此类要素、特征或步骤的其他已知等同物来执行根据本文所描述的原理的方法。在各种要素、特征和步骤中，在不同的实施方案中，一些要素、特征和步骤将被明确包括，而另一些将被明确排除。

虽然已经在某些实施方案和实例的上下文中公开了本申请，但是本领域技术人员将理解，本申请的实施方案超出明确公开的实施方案而扩展到其他替代实施方案和/或它们的使用和修改以及等效形式。

在一些实施方案中，在描述本申请的特定实施方案的上下文中使用的术语“一个/种(a)”、“一个/种an”和“该/所述(the)”以及类似指代词(references)(特别是在所附权利要求的某些权利要求的上下文中)可以被解读为涵盖单数和复数两者。本文中的值的范围的列举仅仅意图充当单独提及落在该范围内的每个不同值的速记方法。除非本文另外指出，否则每个单个值均被并入到本专利说明书中，如同它在本文中被单独列举一样。除非本文中另外指出或以其他方式与上下文明显矛盾，否则本文中所描述的所有方法都可以按任何合适的顺序执行。针对本文中的某些实施方案提供的任何和所有实例或示例性语言(例如，“诸如”)的使用仅旨在更好地阐明本申请，而不对以其他方式要求保护的本申请的范围构成限制。本专利说明书中的语言不应解读为指示出任何未要求保护的实施本申请的必需要素。

本文描述了本申请的某些实施方案。在阅读前述说明书后，对于本领域的普通技术人员来说，那些优选实施方案的变型将变得显而易见。可以预期，本领域的技术人员可以在适当时采用此类变型，并且本申请可以通过本文明确描述以外的方式来实践。因此，只要适用的法律允许，本申请的许多实施方案包括本申请的所附权利要求中叙述的主题的所有修改和等效物。此外，除非本文另外指示或以其他方式明显地与上下文矛盾，否则本申请涵盖其所有可能变型中的上述要素的任何组合。

已经描述了主题的特定实施方式。其他实施方式在所附权利要求的范围内。在一些情况中，权利要求中叙述的行为可以不同次序实施且仍达到期望结果。此外，当附图中描绘的过程不一定需要所示的特定次序或按顺序次序来达到期望结果。

本文引用的所有专利、专利申请、专利申请的公布和其他材料(诸如文章、书籍、专利说明书、出版物、文档、物品等)均出于所有目的通过引用方式以它们的全文并入本文，但与它们相关的任何起诉文件历史、它们中的与本发明的文档不一致或冲突的任何内容，或它们中的可能对现在或以后与本发明的文档相关的权利要求的最广泛范围具有限制影响的任何内容除外。举例来说，如果一个术语的与任何并入的材料相关的描述、定义和/或使用与该术语的与本发明的文档相关的描述、定义和/或使用之间存在任何不一致或冲突，则应以该术语在本发明的文档中的描述、定义和/或使用为准。

最后，应当理解，本文公开的本申请的实施方案举例说明了本申请的实施方案的原理。其它可采用的修改可以在本申请的范围内。因此，举例来说而非限制地，可以依照本文的教导使用本申请的实施方案的替代配置。因此，本申请的实施方案不限于精确地如所示和所描述的实施方案。

Claims (29)

1.一种用于管理被诊断患有心力衰竭的患者的治疗方案的方法，所述方法包括：

接收在第一时间段期间从所述患者获取的生理传感器数据的第一集合，所述生理传感器数据的第一集合经由一台或多台远程监测设备输出；

从参考所述患者的患者概况接收患者数据的集合，所述患者数据的集合包括治疗方案，所述治疗方案包括至少一种治疗剂和相关剂量；

基于患者稳定性处理所述生理传感器数据的第一集合和所述患者数据的集合以输出经更新的治疗方案；以及

向所述患者施用所述经更新的治疗方案。

2.如权利要求1所述的方法，基于所述患者稳定性处理所述生理传感器数据的第一集合和所述患者数据的集合包括基于所述生理传感器数据的第一集合确定所述患者的稳定性得分，以及响应于所述稳定性得分大于阈值得分而输出所述经更新的治疗方案；否则，继续向所述患者施用所述治疗方案而不更新。

3.如权利要求1所述的方法，其中所述经更新的治疗方案包括所述至少一种治疗剂或至少第二治疗剂的相关剂量和用于所述第二治疗剂的第二相关剂量的改变，所述第二治疗剂不同于所述至少一种治疗剂。

4.如权利要求1所述的方法，其中所述经更新的治疗方案包括所述至少一种治疗剂的停用。

5.如权利要求1所述的方法，其中处理所述生理传感器数据的第一集合和所述患者数据的集合以输出所述经更新的治疗方案还包括生成一个或多个警报，所述一个或多个警报包括执行实验室测试和成像测试中的一者或多者的指示。

6.如权利要求1所述的方法，其还包括：

通过在第二时间段期间从所述患者接收到的指示的集合和从所述患者获取的生理传感器数据的第二集合中的一者或多者监测患者对所述经更新的治疗方案的响应，所述生理传感器数据的第二集合经由所述一个或多个远程监测设备输出；以及

响应于指示对所述经更新的方案不耐受和所述经更新的方案有副作用中的一者或多者的患者响应，处理所述生理传感器数据的第二集合和所述患者数据的集合以输出第二经更新的治疗方案，并且向所述患者施用所述第二经更新的治疗方案；否则，继续施用所述经更新的治疗方案。

7.如权利要求6所述的方法，其中所述第二经更新的治疗方案包括所述第二治疗剂的所述第二相关剂量的改变或所述第二治疗剂的停用。

8.如权利要求6所述的方法，其中处理所述生理传感器数据的第二集合和所述患者数据的集合以输出所述第二经更新的治疗方案是基于钾水平、δ肌酐水平、最低收缩压、平均收缩压和平均心率中的一者或多者。

9.如权利要求1所述的方法，其中处理所述生理传感器数据的第一集合和所述患者数据的集合以输出所述经更新的治疗方案是基于指南指导的药物疗法(GDMT)。

10.如权利要求1所述的方法，其中所述生理传感器数据的第一集合包括用于测量所述患者的平均心率的心电图(ECG)数据和用于测量平均收缩压、平均舒张压和最低收缩压的血压数据中的一者或多者；并且其中所述患者数据包括钾水平、δ肌酐水平、肌酐水平、eGFR水平、左心室射血分数、心力衰竭类型、患者身高、患者体重和患者性别中的一者或多者。

11.如权利要求10所述的方法，其中所述生理传感器数据的第一集合还包括用于测量所述患者的摇摆程度的陀螺仪数据和加速度计数据中的一者或多者。

12.如权利要求11所述的方法，其中所述稳定性得分是基于所述患者的所述平均心率、所述平均收缩压和所述摇摆程度中的一者或多者。

13.如权利要求1所述的方法，其中所述一个或多个远程监测设备中的至少一个是可佩戴设备。

14.如权利要求1所述的方法，其中所述至少一种治疗剂是至少一种选自阿替洛尔、倍他洛尔、比索洛尔、卡维地洛、艾司洛尔、拉贝洛尔、美托洛尔、纳多洛尔、吲哚洛尔、普萘洛尔、索他洛尔、噻吗洛尔、醋丁洛尔、氧烯洛尔、卡维地洛和喷布洛尔的β阻滞剂。

15.如权利要求1所述的方法，其中所述至少一种治疗剂是比索洛尔、卡维地洛、琥珀酸美托洛尔、卡托普利、依那普利、福辛普利、赖诺普利、培哚普利、喹那普利、雷米普利、群多普利、坎地沙坦、氯沙坦、缬沙坦、奥美沙坦、沙库巴曲/缬沙坦、螺内酯、依普利酮、达格列净、恩格列净、卡格列净和艾托格列净中的至少一者或多者。

16.如权利要求1所述的方法，其中所述至少一种治疗剂和所述至少第二治疗剂中的每一者均选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

17.一种方法，其包括：

基于经由一个或多个远程监测设备获取的患者的生理参数的第一集合和经由所述患者的健康记录获取的患者数据的集合为被诊断患有心力衰竭的患者生成经更新的治疗方案；以及

向所述患者施用所述经更新的治疗方案；

其中所述经更新的治疗方案包括至少一种先前施用的治疗剂的剂量的改变和/或至少一种新治疗剂的启动，所述新治疗剂不同于所述先前施用的治疗剂。

18.如权利要求17所述的方法，其中生成所述经更新的治疗方案是基于患者耐受所述至少一种先前施用的治疗剂的向上滴定和/或所述至少一种新治疗剂的启动的稳定性。

19.如权利要求18所述的方法，其中所述患者的所述稳定性是基于在阈值心率范围内的平均心率、在阈值收缩压范围内的平均收缩压以及在阈值范围内的所述患者的摇摆程度中的一者或多者。

20.如权利要求17所述的方法，其还包括：

通过在施用所述经更新的治疗方案之后从所述患者接收到的副作用的指示的集合和经由所述一个或多个远程监测设备从所述患者获取的生理参数的第二集合中的一者或多者监测所述患者对所述经更新的治疗方案的响应；以及

响应于指示对所述经更新的方案不耐受和所述经更新的方案有副作用中的一者或多者的患者响应，基于所述生理参数的第二集合和所述患者数据的集合生成第二经更新的治疗方案，以及向所述患者施用所述第二经更新的治疗方案；否则，继续施用所述经更新的治疗方案。

21.如权利要求17所述的方法，其中所述生理参数的第一集合包括平均心率、平均收缩压、平均舒张压和最低收缩压中的一者或多者；并且其中所述患者数据包括钾水平、δ肌酐水平、肌酐水平、eGFR水平、左心室射血分数、心力衰竭类型、患者身高、患者体重和患者性别中的一者或多者。

22.如权利要求17所述的方法，其中向所述患者施用所述经更新的方案包括将所述经更新的治疗方案自动存储在所述患者的健康记录内并且向所述患者传输通知，所述通知包括所述经更新的方案中的所述新治疗剂和关于所述新治疗剂的指导性指示。

23.如权利要求22所述的方法，其还包括将所述经更新的治疗方案自动传输到所述患者的健康记录中引用的相关药房计算系统。

24.如权利要求17所述的方法，其中所述至少一种先前施用的治疗剂和所述至少一种新治疗剂中的每一者均选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

25.一种用于管理患有心力衰竭的患者的治疗方案的系统，所述系统包括：

一个或多个生理传感器，所述生理传感器被配置为从所述患者获取生理传感器数据的集合；

处理系统，所述处理系统包括通信地耦接到存储决策引擎的至少一个非暂时性存储器的至少一个处理器，所述至少一个非暂时性存储器存储可执行指令，所述可执行指令在被执行时使所述处理器：

从所述一个或多个生理传感器获取所述生理传感器数据的集合；

从通信地耦接到所述处理器的电子健康记录系统获取患者数据的集合，所述电子健康记录系统存储参考所述患者的患者数据，所述患者数据包括一种或多种治疗剂和相关剂量；

在第一条件期间，当所述患者的稳定性高于第一阈值时，根据所述决策引擎的第一操作模式处理所述生理传感器数据的集合和所述患者数据的集合，并且基于所述治疗方案输出第一经更新的治疗方案，所述治疗方案包括所述一种或多种治疗剂和相关剂量；以及

在第二条件期间，当所述患者的稳定性低于所述第一阈值时，根据所述决策引擎的第二操作模式处理所述生理传感器数据的集合和所述患者数据的集合，并且基于所述治疗方案输出第二经更新的治疗方案。

26.如权利要求25所述的系统，其中所述生理传感器数据的集合包括心电图(ECG)数据、血压数据、光学体积描记图(PPG)数据、陀螺仪数据、加速度计数据和身体温度数据中的一者或多者。

27.如权利要求25所述的系统，其中所述患者的稳定性是基于所述生理传感器数据的集合来确定。

28.如权利要求27所述的系统，其中所述决策引擎的所述第一操作模式包括更新所述治疗方案以提供所述一种或多种治疗剂的相关剂量的改变和/或启动一种或多种新治疗剂，或者以提供所述一种或多种治疗剂的停用和/或启动所述一种或多种新治疗剂；并且其中所述决策引擎的所述第二操作模式更新所述治疗方案以在不启动所述一种或多种新治疗剂的情况下提供所述一种或多种治疗剂的减少或所述一种或多种治疗剂的停用中的一者或多者。

29.如权利要求28所述的系统，其中所述一种或多种治疗剂和所述一种或多种新治疗剂中的每一者均选自由以下组成的组：β阻滞剂、血管紧张素转化酶(ACE)抑制剂、血管紧张素受体阻滞剂(ARB)、血管紧张素受体-脑啡肽酶抑制剂(ARNi)、醛固酮受体拮抗剂(MRA)、钠-葡萄糖转运蛋白(SGLT2)抑制剂和其他用于治疗心力衰竭的治疗剂。

Images