识别接受生物制剂的适当的患者亚组的系统和方法与流程

识别接受生物制剂的适当的患者亚组的系统和方法
1.相关申请的交叉引用
2.本技术要求于2020年5月1日提交的第63/018,695号美国临时专利申请的优先权和权益，在此将其全文引入作为参考。
技术领域
3.本公开总体上涉及改善对具有潜在呼吸系统疾病的患者的治疗的方法，并且更具体地涉及确定接受生物制剂治疗的适当的患者亚组。


背景技术：

4.呼吸道疾病如哮喘仍然是重要的和昂贵的公共健康问题。例如，在美国，超过2200万人患有哮喘。在世界范围内，世界卫生组织估计患有哮喘的人口可能是235,000,000，并预测未来哮喘将上升。类似地，疾病控制和预防中心最近的研究已经将copd列为美国的第三大死亡原因，同时估计接近1500万人可能具有copd诱导的肺功能受损(wheaton,a.g.,cunningham,t.j.,ford,e.s.,croft,j.b.,患有慢性阻塞性肺病的成人的工作和活动限制-美国(employment and activity limitations among adults with chronic obstructive pulmonary disease-united states),2013.mmwr morb.mortal wkly.rep.,2015,64(11),290-295)。
5.尽管开发了新的药物，但住院率和急诊室就诊率没有下降。在美国，哮喘每年造成约200万急诊科就诊，50万住院和5000人死亡。此外，哮喘造成估计520万学校失学日和870万工作日(nurmagambetov,t.,kuwahara,r.,garbe,p.,美国哮喘的经济负担(the economic burden of asthma in the united states),2008-2013.,ann.am.thorac.soc.,2018,15(3),348-356)。美国健康保险公司和雇主每年的总费用超过820亿美元(同上)。copd每年导致大约715,000例住院和134,000例死亡。此外，最近预计全国copd的费用约为49.9亿美元，包括直接保健支出29.5亿美元，间接发病率费用8.0亿美元和间接死亡率费用12.4亿美元。
6.目前可用的治疗可以预防许多哮喘恶化，然而，5名哮喘患者中只有1名具有受控制的疾病。这样的治疗通常依赖于确定哮喘状况的触发状况和适当地施用诸如药物的治疗。患者自施用的一种机构是吸入器。当触发事件发生时，患者可以通过来自吸入器的抽吸来施用药物。
7.修订的国家指南敦促医生更密切地监测哮喘的处方治疗是否控制日常症状和改善生活质量。然而，医疗服务提供者受到每天评估他们的患者做得如何的工具的可用性的限制。越来越多的医生开始使用定期的书面问卷(例如哮喘控制测试(act))来监测患者并确定他们的控制水平。这些仪器要求患者准确地回忆和报告症状的频率，药物装置(例如吸入器)的使用，以及在一段时间内(通常为2至4周)的活动水平和限制。结果，所收集的与呼吸障碍的管理相关的信息遭受由偏倚(例如，易错的回忆)、症状和行为的不同解释(例如，不一致)以及极其有限的数据收集频率所引入的错误，使得数据具有有限的效用。
8.存在标准急救性吸入器药物可能对某些呼吸系统疾病无效的罕见情况。一种令人兴奋的新疗法是使用生物制剂治疗严重呼吸系统疾病，特别是呼吸区中的哮喘。生物制品是在生物来源中制造的、从生物来源提取的或半合成的药物产品。本文所用的术语“生物”是指任何基于生物的治疗或疗法，因此包括任何生物医疗产品或药物。生物制剂处方的挑战在于它们是昂贵的，并且需要自我施用或访问护理提供者以进行待施用的治疗。还难以评估可施用何种类型的有效生物制剂，因为其取决于多种因素，例如血液和痰嗜酸性粒细胞计数。因此，医疗服务从业者在向正确的患者群体施用生物制剂方面受到挑战。
9.需要一种系统，其允许有效地选择一组患者来施用生物制剂。还需要一种系统，其允许收集基于哮喘控制性药物使用和哮喘急救性药物使用的数据，以识别和支持患者亚组的授权，用于有效的生物应用。还需要在给患者施用生物制剂的同时，通过急救性药物的使用和对控制性药物的依从性来监测症状。


技术实现要素：

10.一个公开的示例是用于确定对呼吸系统疾病的强化治疗的适用性的系统。该系统包括通信接口，该通信接口用于收集呼吸药物装置向患者递送控制性呼吸药物或急救性呼吸药物的使用数据。该系统包括存储所收集的使用数据的存储装置。数据分析模块可操作以基于所收集的使用数据确定患者在呼吸药物装置的使用中是否超过依从性的第一阈值水平。该模块基于所收集的使用数据确定患者是否具有超过第二阈值水平的急救性呼吸药物使用。如果患者超过第一阈值和第二阈值，则该模块提供建议强化治疗的通知。
11.示例性系统的另一实现是其中呼吸系统疾病是哮喘。另一种实现是强化治疗是基于生物的治疗或疗法的处方。另一种实现是其中第一阈值是至少约65％依从性的百分比依从性值，例如至少约70％、75％、80％或85％依从性。在一种实现中，第一阈值是至少约75％依从性的百分比依从性值。另一实现是第二阈值为一周内使用急救性药物至少约15次，例如一周内使用急救性药物至少约22或28次。在一种实现中，第二阈值是一周内使用急救性药物至少约28次。另一实现是其中系统包括移动计算装置，并且移动计算装置与存储装置和通信接口通信。另一实现是移动计算装置包括用于帮助患者应用强化治疗的应用。另一实现是将通知以电子方式提供给患者、护理者或医疗服务提供者之一。另一实现是系统包括与移动计算装置通信的增强处理模块引擎。强化治疗模块可操作以跟踪患者对强化治疗的使用。另一种实现是其中强化治疗模块可操作以为所述患者订购附加的强化治疗。另一种实现是强化治疗是可注射生物制剂的处方。该应用包括在至少一种注射技术上指导患者的界面。另一种实现是接口包括记录生物制剂的注射的区域的界面。另一实现是系统包括用于监测患者的健康监测器。数据分析模块从健康监测器收集数据以确定患者对强化治疗的反应。
12.另一个公开的示例是确定患者是否应该接受呼吸系统疾病的强化治疗的方法。经由通信接口收集呼吸药物装置向患者递送控制性呼吸药物或急救性呼吸药物的使用数据。使用数据被传输到存储装置。使用数据存储在数据分析模块可访问的存储装置中。基于所收集的使用数据确定患者在呼吸药物装置的使用中是否超过依从性的第一阈值水平。基于所收集的使用数据确定患者是否具有超过第二阈值水平的急救性呼吸药物使用。如果患者超过第一阈值和第二阈值，则提供建议强化治疗的通知。
13.示例方法的另一实现是呼吸系统疾病是哮喘。另一种实现是强化治疗是基于生物的治疗或疗法的处方。另一种实现是其中第一阈值是至少约65％依从性的百分比依从性值，例如至少约70％、75％、80％或85％依从性。在一种实现中，第一阈值是至少约75％依从性的百分比依从性值。另一实现是第二阈值为一周内使用急救性药物至少约15次，例如一周内使用急救性药物至少约22或28次。在一种实现中，第二阈值是一周内使用急救性药物至少约28次。另一实现是其中该方法包括与存储装置和通信接口建议到移动计算装置的通信。另一实现是移动计算装置包括用于帮助患者应用强化治疗的应用。另一实现是将通知以电子方式提供给患者、护理者或医疗服务提供者之一。另一实现是该方法包括跟踪患者对强化治疗的使用。另一实现是其中强化治疗模块可操作以为所述患者订购附加的强化治疗。另一种实现是强化治疗是可注射生物制剂的处方。该应用包括在至少一种注射技术上指导患者的界面。另一种实现是界面包括记录生物制剂的注射的区域的界面。另一实现是该方法包括经由用于监测患者的健康监测器监测患者。该方法还包括从健康监测器收集数据以确定患者对强化治疗的反应。
14.以上概述并不旨在表示本公开的每个实施例或每个方面。相反，前述发明内容仅提供本文所阐述的一些新颖方面和特征的示例。当结合附图和所附权利要求考虑时，通过以下对用于实现本发明的代表性实施例和模式的详细描述，本发明的上述特征和优点以及其他特征和优点将变得显而易见。
附图说明
15.从以下结合附图对示例性实施例的描述中将更好地理解本公开，在附图中：
16.图1示出了呼吸系统疾病分析系统，其用于监测准确的，实时的药物装置使用，对该数据执行分析，以及提供对可能是用于强化治疗的对象的患者的分析；
17.图2是示出在客户端装置、应用服务器和/或数据库服务器中使用的计算装置的示例的高级框图；
18.图3是用于确定生物制剂的亚组的患者组的图；
19.图4示出了示例性形式的屏幕图像，其可以从所收集的数据中创建以用于强化治疗的授权；
20.图5示出了由示例应用生成的屏幕图像，用于患者报告生物制剂的注射；
21.图6a示出了患者群体结果图的屏幕图像，其可以用于使用电子药物监测器演示来自给定患者群体的结果；
22.图6b是与使用电子药物监测器的患者人群的急救性抽吸相关的依从性表；并且
23.图7是基于药物数据的收集选择患者亚组的过程的流程图。
24.本公开容许各种修改和替代形式。在附图中以示例的方式示出了一些代表性实施例，并且将在此对其进行详细描述。然而，应当理解，本发明不限于所公开的特定形式。相反，本公开将覆盖落入由所附权利要求限定的本发明的精神和范围内的所有修改、等同物和替换。
具体实施方式
25.本发明可以以许多不同的形式实施。在附图中示出了代表性实施例，并且在此将
对其进行详细描述。本公开内容是本公开内容的原理的示例或说明，并且不旨在将本公开内容的广泛方面限制于所说明的实施例。在此程度上，例如在摘要、发明内容和详细描述部分中公开但未在权利要求书中明确阐述的要素和限制不应以暗示、推断或其它方式单独或共同并入权利要求书中。出于本详细描述的目的，除非明确放弃，否则单数包括复数，反之亦然；词语“包括”是指“包括但不限于”。此外，例如“约”、“几乎”、“基本上”、“近似”等近似词在本文中可用于表示例如“在”、“接近”或“几乎在”或“在3-5％内”或“在可接受的制造公差内”或其任何逻辑组合。
26.本公开涉及收集与急救性吸入器使用和控制性药物依从性的个体级模式相关的数据的系统。该数据可用于识别和描述患有呼吸系统疾病(例如哮喘)的患者的亚组，用于使用生物制剂治疗的潜在干预。这样的患者亚组包括那些需要除急救性药物外的进一步治疗的患者和那些最可能依从处方生物制剂治疗的患者。
27.图1示出了根据一个实施例的呼吸系统疾病分析系统100，该呼吸系统疾病分析系统100用于监测准确的，实时的药物装置事件，对该数据执行分析，并且基于与一般患者群体相关的主要患者的触发标识来提供呼吸系统疾病恶化风险通知。这种呼吸系统疾病可以是哮喘事件，其可以通过吸入器对药物的迅速治疗来解决。
28.呼吸系统疾病分析系统包括客户端计算装置110、药物装置传感器120、药物装置160、应用服务器130、数据库服务器140和网络150。诸如健康提供者服务器170和药物供应服务器180的其它服务器可以耦合到网络150。尽管图1仅示出了呼吸系统疾病分析系统100的大多数部件的单个实例，但是实际上可以存在多于一个的每个部件，并且可以使用附加的或更少的部件。
29.客户端装置110在其用户的胸口处经由网络150与呼吸系统疾病分析系统100交互。出于解释和清楚的目的，识别至少两种不同类型的用户是有用的。患者111是负担诸如哮喘的呼吸系统疾病的用户，其至少部分地利用呼吸系统疾病分析系统100来获得由服务器130提供的个性化急救事件风险通知以及在该示例中由其医疗服务提供者112创建的管理通知。患者111可以由作为附加或替代用户的护理者支持。护理者可以具有他们自己的应用115和客户端装置110，其接收与患者111相同的通知(图1中未示出)，或者代表患者接收通知(例如，患者111的父母/监护人，如果他们自己的客户端装置110与他们的孩子的客户端装置不同，他们也可能想要接收通知)。可以提供这种通知以交换用户允许呼吸系统疾病分析系统100监测患者111的药物装置160的使用的许可。如下面将解释的，由与药物装置160和用户的客户端装置110相关联的传感器120检测药物事件，传感器120又向应用服务器130报告药物事件，应用服务器130又可以启动生成通过客户端装置110提供给用户的风险通知的过程。在该示例中，患者111表示患者群体，针对该群体中的每个患者获取个体数据。
30.另一种类型的用户是医疗服务提供者112，其同样在患者111的明确许可下，还接收关于患者哮喘管理的通知，以及关于哮喘事件和其它相关数据的聚集的哮喘社区急救事件数据和导出的统计。可以设想其它类型的用户。
31.客户端装置110是计算机系统，其可以是诸如智能电话、平板电脑或膝上型电脑的便携式计算装置。客户端装置110还可以是电视(例如智能连接的电视)或扬声器系统(例如智能连接的扬声器)。下面参考图2更完整地描述示例物理实现。客户端装置110被配置为经由网络150与呼吸系统疾病分析系统100进行无线通信。通过网络150访问，客户端装置110
将药物使用事件的时间以及描述从相关联的药物装置传感器120(通篇称为“传感器120”)接收的事件的信息发送到系统100。用户的地理位置也可以被发送到呼吸系统疾病分析系统100。
32.关于用户位置和事件时间，客户端装置110可以通过使用关于其所连接的蜂窝或无线网络150的信息来确定急救事件的地理位置和时间。例如，可以通过直接查询提供网络150连接的软件栈来确定客户端装置110的当前地理位置。可替换地，可以通过查验经由网络150可访问的外部web服务(图1中未示出)来获得地理位置信息。事件的时间可以由传感器120作为事件数据的一部分来提供，或者通过查询可客户端装置的本地操作系统的一部分可用的适当软件例程来添加到事件数据。
33.除了与应用服务器130通信之外，无线地连接到呼吸系统疾病分析系统100的客户端装置110还可以与其他连接的客户端装置110交换信息。例如，通过客户端软件应用115、医疗服务提供者112或护理者可以接收描述关于患者111的最近急救事件的风险恶化通知，然后作为响应向患者111发送用于哮喘后急救事件治疗的建议。类似地，通过应用115，患者111可以与其医疗服务提供者112和其他患者111或护理者通信。
34.应用115提供显示在客户端装置110的屏幕上的用户界面(这里称为“仪表板”)，并允许用户输入命令来控制应用115的操作。仪表板是医疗服务提供者112、护理者和患者111访问呼吸系统疾病分析系统100的机构。例如，仪表板允许患者111、护理者和提供者112彼此交互，接收哮喘急救事件风险通知，交换关于治疗的消息，提供和接收附加的事件和非事件数据等。应用115可以被编码为网页、网页系列，或者被编码为在因特网浏览器内呈现的内容。应用115还可被编码为被配置为在客户端装置110的本机操作系统上操作的专用应用。
35.除了提供仪表板之外，应用115还可以在通过网络150发送经处理的数据之前使用客户端装置110的资源在本地对哮喘急救事件数据执行一些数据处理。通过网络150发送的事件数据由应用服务器130接收，在那里它被分析和处理以便与数据库服务器140一起存储和检索。应用服务器130可以根据客户应用115的需要将检索和存储请求定向到数据库服务器140。如将要解释的，该分析可以扩展为包括来自多个患者111的事件数据。
36.客户端装置110使用网络适配器和有线或无线通信协议与传感器120通信，该协议的示例是蓝牙低能量(btle)协议。btle是在短程无线网络中通过无线电链路无线地传输数据的短程、低功率协议标准。在传感器120和客户端装置110已经使用btle万能钥匙彼此配对之后，传感器120自动地与客户端装置110同步并传送与药物装置使用相关的信息。如果传感器120在急救性药物事件之前没有与客户端装置110配对，则信息被本地存储，直到这种配对发生。在配对时，传感器120将任何存储的事件记录传送到客户端装置110。在其它实现中，使用其它类型的无线连接(例如，红外或ieee 802.11)。
37.虽然客户端装置110和药物装置160在上文中被描述为分离的物理装置(例如分别为智能电话和吸入器)，但是在将来，预期药物装置160不仅可以包括与药物装置160集成到单个壳体中的传感器120，而且可以包括客户端装置110的多个方面。例如，药物装置160可以包括视听接口，该视听接口包括显示器或其他照明元件以及用于呈现视觉可听信息的扬声器。在这种实现中，代替或除了通过客户端装置110呈现通知内容之外，药物装置160本身可以直接呈现由服务器130提供的通知内容。
38.药物装置160是用于向经历呼吸系统疾病急救事件的用户的肺递送药物的医疗装置。不同的药物用于哮喘。不同的药物也可用于哮喘的急救和控制。药物装置(例如，吸入器)通常是便携式的，并且足够小以由手携带，以便在治疗呼吸发作时接近。在一个实施例中，药物以气雾剂形式通过药物装置160如计量剂量吸入器递送。计量剂量吸入器包括气雾剂药物的加压推进剂罐，用于递送调节的药物剂量的计量阀，以及保持加压罐并且还形成用于递送药物的吸嘴的塑料保持器。在另一个实施例中，药物以干粉形式通过药物装置160如干粉吸入器递送。干粉吸入器可具有容纳轮和齿轮机构的笛卡尔卵形体，所述轮和齿轮机构使得用户能够通过干粉药物带进行分度。干粉吸入器的主体还包括歧管和吸嘴以将干粉输送给用户。由控制性药物装置160分配的控制性药物的示例包括二丙酸倍氯米松、二丙酸倍氯米松hfa布地奈德、环索奈德、氟尼缩松、糠酸氟替卡松、丙酸氟替卡松、莫米松、糠酸莫米松hfa 100或200mcg，和曲安奈德，以及这些药物与长效支气管扩张剂如沙美特罗或福莫特罗的组合。其它药物可包括长效β激动剂(laba)，例如硫酸沙丁胺醇、富马酸福莫特罗、昔萘酸沙美特罗、酒石酸阿福特罗和奥达特罗。长效β-激动剂还可包括组合，例如布地奈德与福莫特罗的组合；糠酸氟替卡松、umeclidinium和vilanterol；丙酸氟替卡松和沙美特罗；糠酸氟替卡松100mcg和vilanterol 25mcg；格隆溴铵/富马酸福莫特罗；茚达特罗/格隆溴铵；莫米松与福莫特罗的组合；噻托溴铵2.5mcg和奥达特罗2.5mcg；以及umeclidinium和vilanterol。由急救性药物装置160分配的急救性药物的示例包括硫酸沙丁胺醇、硫酸沙丁胺醇hfa、硫酸沙丁胺醇吸入和雾化溶液、沙丁胺醇、盐酸左旋沙丁胺醇、奥西那林和特布他林。
39.每个患者可以与多于一个的药物装置160相关联。例如，患者可以具有分配急救性药物的急救性药物装置160和分配控制性药物的控制性药物装置160。类似地，每个患者可以与多于一个的传感器120相关联，每个传感器被选择成与患者的药物装置160之一一起操作。
40.通常，传感器120是监测药物装置160的使用的物理装置。传感器120可移除地附接到药物装置而不妨碍药物装置的操作，或者传感器120是集成部件，该集成部件是由其制造商提供的药物装置160的固有部分。
41.传感器120包括其自己的网络适配器(未示出)，该网络适配器通过有线连接或者更典型地通过无线射频连接与客户端装置110通信。在一个实施例中，网络适配器是蓝牙低能量(btle)无线发射机，然而在其它实施例中，可以使用其它类型的无线通信(例如，红外，ieee 802.11)。
42.传感器120还可以被配置为更直接地与应用服务器130通信以传输收集的数据。例如，如果传感器120的网络适配器被配置为经由诸如ieee 802.11或lte的无线标准进行通信，则适配器可以与诸如无线路由器的无线接入点交换数据，无线接入点进而可以与应用服务器130进行通信，而不必在每次数据交换中涉及客户端装置110。这两种通信方法不是互相排斥的，并且传感器120可以被配置为与客户端装置110和应用服务器130两者通信，例如使用冗余传输来确保事件数据到达应用服务器130，或者在应用服务器130确定响应于事件提供什么通知时直接向客户端装置110提供信息。
43.如上所述，传感器120捕获关于药物装置160的使用的数据。具体地，每个传感器120捕获急救性药物事件的时间和地理位置，即患者111对急救性药物装置160的使用。每个
传感器120实时地或一旦实现网络连接就自动地传输事件数据，而无需来自患者111、护理者或医疗服务提供者112的输入。药物治疗事件信息被传输到应用服务器130，用于分析、哮喘急救事件通知的生成，以及多个患者的事件数据的综合分析。
44.为了实现这个目标，有多种不同的方式来构造传感器120，并且部分地该构造将取决于药物装置自身160的构造。通常，所有传感器120将包括板载处理器、永久存储器和上述网络适配器，它们一起用于记录、存储和向客户端装置110和/或服务器130报告药物治疗事件信息。传感器120还可以包括用于记录事件的时间和日期的时钟。
45.关于传感器120的具体结构，传统的吸入器，例如机械剂量计数器，不考虑传感器120而设计，因此传感器120可以相应地构造。以这种方式的一些实现包括机械、电或光学传感器，以检测装置160的运动、装置的起动、装置的激活、用户的吸入等。相反，诸如可偏转的薄膜剂量计数器的现代吸入器包括电路，该电路可以将事件信息报告为电数据信号，传感器120设计成接收和解释该电数据信号，例如药物装置160本身可以将运动、起动和激活报告给传感器120。
46.关于传感器120和药物装置160的硬件和软件部件的更多信息，以及它们之间的交互以记录急救性药物事件可以在2009年1月1日提交的美国专利申请第12/348,424号和2014年5月21日提交的国际申请第pct/us2014/039014号中找到，这两个申请通过引用整体并入本文。
47.应用服务器130是计算机或计算机网络。尽管在图2中示出了简化的示例，但是典型地，与例如用作客户端装置110的典型计算系统相比，应用服务器将是使用强大处理器、大存储器和更快网络部件的服务器类系统。服务器通常具有大的辅助存储器，例如，使用raid(独立磁盘的冗余阵列)阵列和/或通过建立与独立内容分发网络(cdn)的关系来存储、交换和传输数据，诸如上述考虑的哮喘通知。另外，计算系统包括操作系统，例如unix操作系统、linux操作系统或windows操作系统。操作系统管理应用服务器130的硬件和软件资源，并且还提供各种服务，例如过程管理、数据的输入/输出，外围装置的管理等。操作系统提供用于管理存储在装置上的文件的各种功能，例如，创建新文件、移动或复制文件、将文件传送到远程系统等。
48.应用服务器130包括用于支持许多不同的客户端装置110通过网络150访问和使用分析系统100的软件架构，并且因此在高层级上通常可以表征为基于云的系统。应用服务器130通常为患者111和医疗服务提供者112提供平台，以报告由与其药物装置160相关联的传感器记录的数据，包括急救性药物和控制性药物事件，在呼吸系统疾病治疗计划上协作，浏览和获得关于其状况和地理位置的信息，并利用各种其它功能。
49.通常，应用服务器130被设计成处理各种各样的数据。应用服务器130包括执行各种功能的逻辑例程，这些功能包括检查输入数据的有效性，在必要时对数据进行解析和格式化，将经处理的数据传递到数据库服务器140以供存储，以及确认数据库服务器140已被更新。
50.应用服务器130至少部分地基于患者地存储和管理数据。为此，应用服务器130为每个用户创建患者简档。患者简档是表征呼吸系统疾病分析系统100的患者111的一组数据。患者简档可以包括关于患者的身份信息，诸如年龄、性别、当前急救性药物、当前控制性药物、通知偏好、控制性药物依从性计划、相关医疗历史和被授权访问患者简档的非患者用
户的列表。简档还可以指定装置标识符，例如唯一的媒体访问控制(mac)地址，其标识被授权为患者提交数据(例如控制性和急救性药物事件)的一个或多个客户端装置110或传感器120。
51.简档可以指定向患者111或护理者及其个人医疗服务提供者112提供哪些不同类型的通知，以及提供通知的频率。例如，患者111或护理者可以授权医疗服务提供者112接收指示急救事件的通知。患者111或护理者还可以授权他们的医疗服务提供者112访问他们的患者简档和急救事件历史。如果医疗服务提供者112被提供对患者111的患者简档的访问，则医疗服务提供者可以为相应的哮喘病症指定控制性药物依从性或急救性药物计划。药物治疗计划包括每天用于控制性药物的规定剂量数。
52.应用服务器130还为医疗服务提供者112创建简档。医疗服务提供者简档可包括关于医疗服务提供者112的标识信息，诸如办公室位置、资格和证书等。医疗服务提供者简档还包括关于他们的患者群体的信息。提供者简档可包括对提供者的患者的所有简档的访问，以及从那些简档导出的数据，诸如聚集人口统计信息、急救性和控制性药物事件模式等。该数据可以根据存储在患者简档中的任何类型的数据被进一步细分，诸如按地理区域(例如，邻域、城市)按时间段(例如，每周、每月或每年)。
53.应用服务器130从客户端装置110或传感器120接收急救性药物事件信息，触发应用服务器130上的各种例程。在下面描述的示例性实现中，数据分析模块131执行例程以访问呼吸系统疾病事件数据以及包括患者简档的其他数据，分析数据，并将其分析结果输出给患者111或护理者和提供者112。该过程通常被称为呼吸系统疾病风险分析。在该示例中，针对患者111的哮喘执行风险分析。哮喘风险分析可以在任何时间点执行，响应于急救事件，由于患者环境的相关变化，以及响应于下面进一步讨论的多种触发条件中的任何一种。
54.其它分析也是可能的。例如，可以对多个患者的急救性和控制性药物使用进行风险分析，以基于来自个体、地理、临床、流行病学、人口统计或空间或时间基线或预测或预期值的历史上显著的排列，基于药物使用的空间/时间聚类(或爆发)来识别。其他类型的分析可以包括每日/每周的依从性趋势，随时间的依从性变化，与其他相关群体(例如，所有患者，关于特定急救性药物或控制性药物或其组合的患者)的依从性比较，触发(空间、时间、环境)的识别，随时间的急救使用趋势，以及与其他相关群体的急救使用比较。因此，特定患者的依从性百分比通过在特定日采用的控制性抽吸次数除以规定的每日抽吸次数来计算。然后在指定的时间段内对该每日度量进行平均，以获得平均每日依从性。所规定的控制性抽吸次数基于患者的药物治疗计划，该计划被输入到应用中。
55.响应于所执行的任何分析，应用服务器130准备并递送推送通知以发送到患者111、经授权的医疗服务提供者112和/或提供对患者简档的访问的其它用户，例如护理者。通知可以提供关于药物急救事件中涉及的定时、位置和受影响的患者111的细节。通知还可以包括请求被分发给紧急援助提供者112的紧急援助的遇险或紧急信号。通知还可以包括由数据分析模块131执行的哮喘风险分析的结果。下面进一步描述关于可以发送的通知的类型以及它们可以包含的内容的更多信息。
56.除了响应于哮喘风险分析而提供推送通知之外，还可以在特定时间间隔将通知提供为拉取通知。另外，一些通知(推或拉)可以不响应于响应于急救性药物事件而执行的哮喘风险分析而被触发，而是响应于响应于哮喘风险分析变化中的潜在因素之一而执行的风
险分析而被触发，从而保证更新的通知。例如，如果天气条件指示空气污染正在增加或即将增加，则这可触发对位于污染正在发生的特定地理区域中的所有患者进行哮喘风险分析。
57.通知通过网络150以专门设计用于客户应用的数据格式提供给客户应用115，并且附加地或可选地可以作为短消息服务(sms)消息、电子邮件、电话或以使用其它通信介质通信的其它数据格式提供。
58.数据库服务器140存储与患者和提供者数据相关的数据，诸如简档、药物治疗事件、患者医疗历史(例如，电子医疗记录)。为安全起见，患者和提供者数据被加密，并且至少是密码保护的，否则是安全的，以满足所有健康保险便携性和责任法案(hipaa)要求。合并来自多个患者的数据(例如，汇总急救性药物事件数据)并提供给用户的任何分析(例如，哮喘风险分析)被去识别，使得个人识别信息被去除以保护患者隐私。
59.数据库服务器140还存储用于哮喘风险分析的非患者数据。该数据包括关于多个地理区域的区域数据，所述地理区域例如是患者身体上所处并可能暴露于污染物的住宅或商业区中的公共空间。该数据可以特别地包括或被处理以获得患者对绿色空间(包括集中数量的树和植物的区域)的接近度。区域数据的一个示例包括地理参考天气数据，诸如温度、风模式、湿度、空气质量指数等。另一个示例是地理参考污染数据，包括在时间实例或经验测量的各种污染物的微粒计数。区域数据包括关于急救事件的时间和地点的当前天气状况的信息，例如温度、湿度和空气质量指数。以上所有数据项可以随时间变化，并且同样地，数据本身可以按时间索引，例如单独的数据点可以按一天中的时间(包括按分钟或小时)，或在更长的时间段内(例如按天、星期、月或季节)可用。虽然数据库服务器140在图1中被示为与应用服务器130分离的实体，但是数据库服务器140也可以是作为诸如服务器130的另一服务器的一部分的硬件部件，使得数据库服务器140被实现为一个或多个持久存储装置，其中用于与数据库中所存储的数据进行接口的软件应用层是另一服务器130的一部分。
60.数据库服务器140根据定义的数据库模式存储数据。通常，由于底层数据库结构中的实现差异，即使当存储包括云应用事件日志和日志度量的相同类型的数据时，跨不同数据源的数据存储模式也显著变化。数据库服务器140还可以存储不同类型的数据，例如结构化数据、非结构化数据或半结构化数据。数据库服务器140中的数据可以与患者、患者组和/或实体相关联。数据库服务器140提供对查询语言(例如，用于关系数据库、json nosql数据库的sql等)中的数据库查询的支持，用于指定管理由数据库服务器140表示的数据库对象，从数据库服务器140读取信息或向数据库服务器140写入的指令。
61.网络150表示客户端装置110、传感器120、应用服务器130和数据库服务器140之间的各种有线和无线通信路径。网络150使用标准因特网通信技术和/或协议。因此，网络150可以包括使用诸如以太网，ieee 802.11、综合服务数字网络(isdn)、异步传输模式(atm)等技术的链路。类似地，在网络150上使用的联网协议可以包括传输控制协议/因特网协议(tcp/ip)、超文本传输协议(http)、简单邮件传输协议(smtp)、文件传输协议(ftp)等。通过网络150交换的数据可以使用包括超文本标记语言(html)、可扩展标记语言(xml)等的技术和/或格式来表示。此外，可以使用诸如安全套接字层(ssl)、安全http(https)和/或虚拟专用网(vpn)之类的传统加密技术来加密所有或一些链路。在另一实施例中，实体可以使用定制和/或专用数据通信技术来代替或附加于上述技术。
62.图2是示出根据一个实施例的可用作图1的客户端装置110、应用服务器130和/或
数据库服务器140的一部分的示例计算机200的物理部件的高级框图。示出了耦合到至少一个处理器205的芯片组210。耦合到芯片组210的是易失性存储器215、网络适配器220、输入/输出(i/o)装置225、代表非易失性存储器的存储装置230和显示器235。在一个实施例中，芯片组210的功能由存储控制器211和i/o控制器212提供。在另一个实施例中，存储器215直接耦合到处理器205而不是芯片组210。在一些实施例中，存储器215包括高速随机存取存储器(ram)，例如dram、sram、ddr ram或其它随机存取固态存储器装置。
63.存储装置230是任何非瞬时计算机可读存储介质，例如硬盘驱动器、光盘只读存储器(cd-rom)、dvd或固态存储装置。存储器215保存由处理器205使用的指令和数据。i/o装置225可以是触摸输入表面(电容性的或其他的)、鼠标、跟踪球或其他类型的定点装置、键盘或其他形式的输入装置。显示器235显示来自计算机200的图像和其它信息。网络适配器220将计算机200耦合到网络150。
64.如本领域中已知的，计算机200可以具有与图2所示的部件不同的部件和/或其它部件。此外，计算机200可以缺少某些示出的部件。在一个实施例中，充当服务器140的计算机200可以缺少专用i/o装置225和/或显示器218。此外，存储装置230可以是本地的和/或远离计算机200(诸如在存储区域网络(san)中实现的)，并且在一个实施例中，存储装置230不是cd-rom装置或dvd装置。
65.通常，在客户端装置110中使用的确切物理部件将在尺寸、功率要求和性能上不同于在应用服务器130和数据库服务器140中使用的部件。例如，通常是家用计算机、平板计算机、膝上型计算机或智能电话的客户端装置110将包括相对较小的存储容量和处理能力，但将包括输入装置和显示器。这些部件适合于数据的用户输入和接收，显示以及与由应用服务器130提供的通知的交互。相反，应用服务器130可以包括许多物理上分离的，本地联网的计算机，每个计算机具有大量的处理能力，用于执行上面介绍的哮喘风险分析。在一个实施例中，应用服务器130的处理能力由诸如亚马逊网络服务
tm
的服务提供。此外，相反，数据库服务器140可以包括许多物理上分离的计算机，每个计算机具有用于存储与应用服务器相关联的数据的大量持久存储容量。
66.如本领域中已知的，计算机200适于执行用于提供这里描述的功能的计算机程序模块。模块可以用硬件、固件和/或软件来实现。在一个实施例中，程序模块存储在存储装置230上，加载到存储器215中，并由处理器205执行。
67.在该示例中，在应用服务器130上执行的应用可以从诸如图1中的装置160的药物装置收集诸如使用数据的数据。本技术从患者群体对药物装置的使用收集数据，所述患者群体可用于鉴定具有中度/重度呼吸系统疾病如哮喘的患者，所述患者符合生物治疗。合适的生物治疗可包括例如奥马珠单抗(xolair)、美泊利单抗(nucala)、瑞替珠单抗(cinqair)、贝那利珠单抗(fasenra)和度普利尤单抗(dupixent)。
68.例如，收集的数据可用于确定诸如以下的因素：a)吸入性皮质类固醇(ics)或支气管扩张药如laba的使用；b)ics/laba的使用证明；和c)控制性依从性的证明。可以分析与哮喘控制有关的另外的吸入皮质类固醇数据。这种与哮喘有关的数据可以包括急救性吸入器使用、夜间症状、哮喘控制得分(act)、由act控制的哮喘，以及诸如肺活量测定读数的外部传感器读数。
69.图3是基于所收集的诸如控制性和急救性吸入器的药物装置的使用数据的潜在患
者的分解图300。如这里所解释的，使用数据可以由图1中的分析系统100收集。在该示例中，第一条310示出了所有患者。条310被分解成具有相关联的控制性药物数据的患者312和控制性药物数据不可用的患者314。第二条320表示对具有控制性药物数据的患者312的选择。这些患者被分成与他们的控制性药物说明书依从性超过75％的那些患者322和依从性低于75％的那些患者324。当然，可以使用其它阈值来分离患者群体。例如，任何合适的阈值可以选自约65％以上的依从性。例如，可以使用65％和85％之间的阈值。这样的值可以是至少约65％、70％、80％或85％依从性。在该示例中，收集2至3个月(例如，60或90天)的患者数据以确定阈值，但是可以使用更长或更短的时间段。
70.第三条330表示没有报告急救事件的第一组患者332，具有低于特定阈值(例如每周28次抽吸)的急救事件的第二组患者334，具有高急救使用的第三组患者336。可以使用其它用于急救使用的阈值，例如在一周内超过15次使用急救性药物的任何阈值。例如，这样的值可以在使用15-28次之间的范围内，例如一周内使用急救性药物15或22次。在这个示例中，第一组患者332和第二组患者334应该继续急救性药物处方治疗。第三组患者336可被考虑接受生物制剂治疗的建议。
71.在该示例中，图1中的系统100可用于经由包括医疗服务提供者服务器370的医疗服务系统通知用户及其护理者和临床医生，基于以上解释的所收集的数据，患者可以是生物制剂的适当候选者。如上所述，由于所收集的数据是为了证明生物制剂的处方而必须由提供者收集的相同数据，所以系统可保留所收集的数据并使其可用于生物制剂的候选患者以使应用过程流线化。此类数据可包括ics/长效β激动剂(laba)的使用证据；缺乏疾病控制的证据；加重史；以及对治疗的反应/改善的证明。
72.图4示出了示例先前授权表400和示例呼吸系统疾病报告450的屏幕图像，其都可以从患者和由系统100收集的使用数据生成。先前的授权表400包括可以从由系统100收集的数据中填充的数据，以使用于增强处理的应用过程流线化。
73.在这个示例中，呼吸系统疾病报告450涉及哮喘，并且可以用于记录强化治疗的处方。呼吸系统疾病报告450包括患者细节字段460、健康状态字段470和药物使用字段490。患者详情字段460包括关于患者和当前处方的药物类型的信息。健康状态字段470包括控制状态图472、夜间急救使用数据字段474、控制依从性字段476、急救趋势图478和哮喘控制测试结果字段480。该示例中的对照状态图472提供了显示在预定时间段(例如30天)内良好控制、未良好控制和不良控制的哮喘状态的百分比的图。夜间急救使用数据字段474示出了患者要求急救使用吸入器的预定时间段内的夜间数。控制依从性字段476示出了在预定时间段内使用一个或多个吸入器的依从性百分比。急救趋势图形478示出了不同的图形，这些图形示出了急救使用的一天中的时间和急救使用的一周中的天。哮喘控制测试结果字段480示出了哮喘控制测试的结果。
74.药物使用字段490包括急救性药物使用图492，其示出在预定时段期间发生的急救性药物使用的天数以及在夜晚期间的时间和在特定日期间的总时间量。药物使用字段490还包括控制性药物使用图494，其示出对不同控制性药物的依从性。
75.一旦指定了生物制剂，系统100就可以经由在图1中的患者计算装置110上执行的应用来继续监测这种生物制剂的使用。系统100还可以基于药物治疗计划向患者提供提醒，即鼓励依从性。系统100还可提供有帮助的信息，例如提供用户界面，该用户界面包括输入
注射位置的视觉或书面指示，并使它们走过注射步骤。
76.这样的应用可以包括仪表板界面，其允许患者输入将生物制剂作为强化治疗的一部分的事件。该界面还可以从生物制剂的施用收集患者报告的结果。该数据可以与来自药物供应服务器180的处方和分配信息一起报告给应用服务器130，以跟踪特定患者的生物制剂。在患者计算装置110上执行的应用可以被定制为生物制剂的特定应用，并且因此提供生物特定内容以帮助用户理解如何管理生物制剂，提供教育内容以帮助用户更好地理解生物制剂的益处，提供教育内容以帮助用户更好地理解他们的哮喘。
77.图5示出了由在患者计算装置110上执行的示例应用生成的界面的屏幕图像，以报告生物制剂的注射。注射界面500示出了位置图502，该位置图502表示注射可能发生的身体图形上的区域。患者选择适当的区域，并且显示指示注射被记录和注射位置的确认消息504。最近站点界面510示出了身体图形512，该身体图形512示出了最近和预计的未来注射的位置。该应用还可以显示关于如何进行注射的指示和/或提供音频指示。汇总表514列出按日期和身体位置的最近注射以及下一次预定注射。确认界面520提供允许患者确认报告的注射已经发生的按钮522。该应用可以包括提醒功能，其将提醒患者何时注射生物制剂，并且包括诸如弹出窗口或倒计时时钟的特征。该应用可包括允许用户选择生物制剂并设置注射生物制剂的时间表和相应的提醒的界面。该应用可包括显示先前注射历史记录的趋势图。这样的历史记录可以与诸如act历史或吸入器剂量的其它患者数据一起插入。该应用可以允许用户获得进一步的细节，例如身体位置、时间和过去注射的药物。该应用还可以包括与关于呼吸系统疾病和诸如特定生物制品的治疗的教育信息的界面。系统100可接收来自应用的数据，跟踪注射部位，并基于历史数据提出未来注射的建议。系统100还可以分析从应用接收的与历史趋势相关的数据，并推断诸如恶化的事件。
78.系统100可用于流线化生物药物的重新排序，并提供提醒以重新排序药物。系统100可以跟踪运送状态以增加药物的履行和依从性。使用数据以及其他患者数据可以被发送到可以包括药物供应服务器180的药物分配系统。患者的跟踪和生物制剂的使用允许将通知发送给患者、护理者、医疗服务提供者或其他方以预测生物制剂的重新排序。
79.由系统100收集的患者报告的结果(pro)和传感器数据可以用于测量和潜在地预测对特定生物制品的反应。可用于哮喘治疗的患者报告的结果的示例可包括血液嗜酸性粒细胞计数、feno、过敏原驱动的症状、儿童发作性哮喘、在先前时间段中的恶化、成人发作性哮喘、鼻息肉病和轻度/重度特应性皮炎。如果数据表明对规定的生物制品有不显著的反应，则系统可以建议在给定的时间量之后改变为不同的生物制品。系统100还可以分析/识别对不同生物制剂最敏感的患者的亚组。对生物制剂的反应可以基于吸入器的使用，和/或与其它传感器数据相关联，例如呼吸率、心率、支气管收缩或呼吸中的生物标记。因此，可以通过传感器收集数据，所述传感器可以包括传感器报告的急救性吸入器使用、传感器报告的夜间醒来以及传感器导出的呼吸控制。夜间醒来和夜间使用急救性吸入器可以是夜间醒来以缓解症状的代表。夜间觉醒与哮喘的不良结果相关。通过急救使用模式(白天和夜晚)和哮喘控制测试，可以具体确定哮喘控制。
80.如上所述，应用可以包括用于患者自我报告的界面。这样的数据可以包括自我报告的act数据、自我报告的生活质量，以及自我报告的恶化，例如住院治疗、ocs的处方，或与医疗服务提供者的约定。其它传感器数据可以由系统100收集，其可以包括在对特定生物的
反应性的分析中。这些可能包括被动活动、睡眠数据、家中肺活量测定读数以及对污染物和刺激物的反应。因此，夜间觉醒可以通过夜间吸入器使用或睡眠跟踪传感器来表征。例如，该系统可以链接到来自诸如fitbit的可佩戴传感器的睡眠数据，或诸如可从睡眠计分实验室(sleep score labs)获得的应用的电话应用。另一个数据源可以包括到智能注射器的数据连接。这样的智能注射器在本领域中是已知的，并且可以连接到当前系统以确认生物制品的使用、使用的时间和日期、药物的量、药物的批次等。
81.图6a示出了患者群体结果图600的示例屏幕图像，其总结了针对给定患者群体收集的数据。图600和所收集的数据可用于确定某些患者对生物制剂治疗的适合性，即通过查看群体水平特征并将群体分类成不同的依从性和急救使用类别，其可用于作出与生物制剂治疗有关的临床决策(如图6b所示)，和/或分析已经或正在接受生物制剂治疗的患者群体的结果。
82.在一个示例中，18岁以上的具有自我报告的哮喘的患者在18个月期间被纳入数字健康计划。该程序包括电子药物监测器(emm)，其客观地和被动地监测患者使用的吸入器。患者使用控制性和急救性吸入器治疗他们的哮喘。由吸入器产生的使用数据被传送到与每个患者相关的专用智能电话应用。在该示例中，使用超过90天emm的患者根据控制性药物依从性和急救使用被分类成组。图6b是与患者群体的急救性抽吸相关的依从性的表650。依从性组包括0-24、25-49、50-74和75-100％依从性的四分位数。急救使用组包括每周使用1-3次抽吸、4-14次抽吸、15-28次抽吸和大于28次抽吸的患者。多变量逻辑回归确定了年龄、性别、哮喘控制测试(act)评分(5-15、16-19、≥20)，每日应用开放和人口普查地区级人口统计是否与依从性和急救使用组相关。置信水平为α＝0.05。
83.如表650中所示，具有75-100％的依从性和大于28次急救性抽吸/周并且两者都分别为18％、6％和1.5％的研究患者(n＝1263，平均年龄：39岁，79％女性)的百分比。模型确定，年龄较大，act评分大于20且应用开放性较高与75-100％依从性相关，而act评分为5-15且应用开放性较高的那些模型与大于28次急救性抽吸/周相关。
84.图1的系统中的连续监测可用于确定患者以选择生物制剂来治疗除了哮喘之外的多种呼吸障碍，例如copd、囊性纤维化和支气管扩张。然而，应当理解和明白，上述原理不限于这种使用。
85.图7是根据本公开的某些方面的用于确定诸如生物制剂的强化治疗的患者的数据收集和分析例程的流程图700。图7中的流程图表示用于收集数据和选择用于强化治疗的患者的过程的示例性机器可读指令。在该示例中，机器可读指令包括由以下执行的算法：(a)处理器；(b)控制器；和/或(c)一个或多个其它合适的处理装置。该算法可以包含在存储在有形介质或计算机程序产品上的软件中，例如闪存、cd－rom、软盘、硬盘驱动器、数字视频(通用)盘(dvd)或具有非暂时性计算机可读介质的其它存储装置。然而，所属领域的技术人员将容易了解，整个算法和/或其部分可替代地由不同于处理器的装置执行和/或以众所周知的方式实施于固件或专用硬件中(例如，其可由专用集成电路[asic]、可编程逻辑装置[pld]、现场可编程逻辑装置[fpld]、现场可编程门阵列[fpga]、离散逻辑等实现)。例如，接口的任何或所有部件可由软件、硬件和/或固件来实现。此外，可以手动实现由流程图表示的一些或全部机器可读指令。此外，尽管参考图7中所示的流程图描述了示例性算法，但是本领域普通技术人员将容易理解，可替换地可以使用实现示例机器可读指令的许多其他方
法。例如，可以改变块的执行顺序，和/或可以改变、消除或组合所描述的一些块。
[0086]
例程首先从使用呼吸药物的患者的一般群体收集控制性和急救性使用数据(710)。在一段时间(例如90天)内收集使用数据。该例程识别具有与急救性和控制性使用相关的足够数据的那些患者(712)。然后该例程检查有足够数据的患者。该例程分析使用数据并确定在设定时间段内依从性超过第一阈值的患者(714)。在该示例中，第一阈值是超过75％依从性的患者。
[0087]
然后，例程分析那些具有超过依从性的第一阈值的患者，以确定那些具有高急救使用的患者(716)。在该示例中，高急救使用的定义是超过第二阈值的急救使用，例如每周超过28次抽吸。然后该例程存储那些具有高急救使用的患者(718)。检索任何相关医学数据以与患者相关联(720)。然后，该例程提供最后一组中的患者符合进行诸如生物制剂的强化治疗的通知(722)。
[0088]
如本技术中所使用的，术语“部件”、“模块”、“系统”等一般是指计算机相关的实体，或者是硬件(例如，电路)、硬件和软件的组合、软件，或者是与具有一个或多个特定功能的操作机器相关的实体。例如，部件可以是，但不限于，在处理器(例如，数字信号处理器)上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。作为说明，在控制器上运行的应用以及控制器都可以是部件。一个或多个部件可驻留在进程和/或执行线程内，并且部件可位于一个计算机上和/或分布在两个或更多个计算机之间。此外，“装置”可以以特别设计的硬件的形式出现；通过在其上执行使硬件能够执行特定功能的软件而专门化的通用硬件；存储在计算机可读介质上的软件；或其组合。
[0089]
这里使用的术语仅用于描述特定实施例的目的，并不旨在限制本发明。如本文所用，单数形式“一个”、“一种”和“该”也旨在包括复数形式，除非上下文另外明确指出。此外，就在详细说明和/或权利要求书中使用的术语“包括”、“包含”、“具有”、“有”、“带有”或其变体而言，此类术语旨在以类似于术语“包含”的方式为包含性的。
[0090]
除非另有定义，本文使用的所有术语(包括技术和科学术语)具有与本领域普通技术人员通常理解的相同的含义。此外，诸如在通常使用的词典中定义的那些术语的术语应当被解释为具有与其在相关技术的上下文中的含义一致的含义，并且将不以理想化或过度正式的意义来解释，除非在此明确地如此定义。
[0091]
虽然上面已经描述了本发明的各种实施例，但是应当理解，它们仅仅是作为示例而非限制来呈现的。尽管已经参照一个或多个实现示出和描述了本发明，但是在阅读和理解了本说明书和附图之后，本领域的其他技术人员将想到或知晓等同的替换和修改。此外，虽然本发明的特定特征可能仅相对于若干实现中的一个被公开，但是这种特征可以与其他实现的一个或多个其他特征组合，这对于任何给定或特定应用可能是期望的和有利的。因此，本发明的宽度和范围不应受到上述任何实施例的限制。相反，本发明的范围应当根据所附权利要求及其等同物来限定。