用于预测治疗装置流失的系统和方法与流程

用于预测治疗装置流失的系统和方法
1.相关申请的交叉引用
2.本技术要求于2020年10月2日提交的第63/086,924号美国临时专利申请的权益和优先权，该申请在此通过引用整体并入本文。
技术领域
3.本公开总体上涉及用于改进对运行医疗装置的应用程序的依从性的方法，并且更具体地涉及确定和预测影响药物装置的用户的流失的因素。


背景技术：

4.诸如哮喘和慢性阻塞性肺病(copd)的呼吸疾病仍然是显著且昂贵的公共健康问题。例如，在美国，超过2200万人患有哮喘。在世界范围内，世界卫生组织估计患有哮喘的人口可能是3亿，并预测到2025年将上升到4亿。同样，疾病控制和预防中心最近的研究已将copd列为美国的第三大死亡原因，同时估计约1300万人可能患有copd诱导的肺功能受损。
5.尽管开发了新的药物，但住院率和急诊室就诊率没有下降。在美国，哮喘每年造成约200万急诊科就诊，50万住院和5000人死亡。此外，哮喘造成估计1500万天的误学和1200万天的工作。美国健康保险公司和雇主每年花费的总费用超过180亿美元。copd每年导致大约715,000例住院和134,000例死亡。此外，最近预计全国copd的费用约为499亿美元，包括295亿美元的直接保健支出、80亿美元的间接发病率费用和124亿美元的间接死亡率费用。
6.目前可用的治疗可以预防大多数哮喘恶化，然而，每5名哮喘患者中只有1名的疾病得到控制。这样的治疗通常依赖于确定哮喘病状的触发状况以及适当地施用诸如药物的治疗。患者自给药的一种机构是吸入器。当出现呼吸症状时，患者可以通过从吸入器抽吸来施用药物。
7.类似地，患有copd的人通常携带吸入药物以在症状发生的任何时候或任何地方立即缓解症状。患者使用这些药物的频率和位置是疾病控制和治疗的良好程度的重要指标。目前，吸入器可包括内置传感器或附加传感器，以收集关于吸入器使用的信息。然后可以将该信息发送到中央服务器以确定依从性。
8.然而，许多患者不依从正确使用吸入器和传感器的组合，导致流失率高。缺乏依从性意味着患者不能正确地接受呼吸疾病的治疗。许多数字健康应用和装置相对于其他消费应用和设备经历高流失率。目前，付款者、提供者和卫生保健专业人员理解、预测和干预关于诸如吸入器的治疗装置何时用户可能即将流失的能力有限。缺乏依从性和高流失率降低了这种治疗的成本效率和跟踪和理解吸入器使用的能力。
9.需要一种系统，其允许分析以减少治疗装置的高流失率。需要一种系统，其收集多种数据以确定用于确定使用治疗装置的患者的流失可能性的因素。还需要一种系统，其确定具有高流失风险的患者，以针对该患者提供预防措施和解决方法。


技术实现要素：

10.所公开的分析系统允许对患者的行为和静态数据进行组织，以便训练和部署关于增加依从性的预测模型。分析允许使用治疗装置来分析患者的流失。
11.一个公开的实例是一种用于预测与患者对治疗装置的使用相关的流失的系统。该系统包括通信接口，通信接口用于收集关于监测治疗装置的操作的事件数据。存储装置存储患者的事件数据和临床数据。流失分析模块输入事件数据和临床数据，并应用机器学习模型，以根据输入的事件数据和临床数据确定患者在预定时间段内的流失可能性。机器学习模型是根据机器学习流水线训练的，机器学习流水线具有来自使用治疗装置的患者群体的事件数据和临床数据作为输入，以确定针对患者流失的至少一个触发。分析模块确定流失可能性是否超过阈值。如果流失可能性超过阈值，则该模块触发与患者相关的动作。
12.示例性系统的另一实现方式是其中治疗装置是急救吸入器或控制吸入器的实施例。另一种实现方式是其中通信接口与患者的移动设备通信。将与治疗装置通信的传感器与移动设备执行的应用程序同步以提供事件数据。另一实现方式是其中机器学习流水线是根据与患者群体相关的客户服务数据训练的。另一实现方式是其中动作是患者警报、健康护理提供者警报、或治疗装置制造商警报中的一者。另一实现方式是其中机器学习流水线以预测终点作出响应，预测终点包括确定的流失可能性，处理的临床数据和事件数据的值，以及值如何影响确定的流失可能性的量化影响。
13.另一个公开的实例是一种用于确定由患者操作的治疗装置的流失的方法。收集患者的临床数据。经由通信接口收集与监测治疗装置的操作有关的事件数据。应用机器学习模型来根据输入事件数据和临床数据确定患者在预定时间段内的流失可能性。机器学习模型是根据机器学习流水线训练的，机器学习流水线具有来自使用治疗装置的患者群体的事件数据和临床数据作为输入，以确定针对患者流失的至少一个触发。确定流失可能性是否超过阈值。如果流失可能性超过阈值，则触发与患者相关的动作。
14.示例性方法的另一实现方式是其中治疗装置是急救吸入器或控制吸入器的实施例。另一实现方式是其中该示例性方法包括经由通信接口与患者的移动设备通信；以及将与治疗装置通信的传感器与移动设备执行的应用程序同步以提供事件数据。另一实现方式是其中机器学习流水线是根据与患者群体相关的客户服务数据训练的。另一实现方式是其中动作是患者警报、健康护理提供者警报、或治疗装置制造商警报中的一者。另一实现方式是其中机器学习流水线以预测终点作出响应，预测终点包括确定的流失可能性，处理的临床数据和事件数据的值，以及值如何影响确定的流失可能性的量化影响。
15.另一个公开的实例是一种用于训练机器学习模型的流水线方法，机器学习模型用于预测操作治疗装置的患者的流失。从患者群体收集数据输入。数据输入包括与监测治疗装置的操作有关的临床数据和事件数据。组织数据输入以产生数据表。根据数据表训练机器学习模型以对影响流失的多个输入因素进行加权，并在确定流失可能性时确定输入因素的影响以产生预测端点。存储经训练的机器学习模型。
16.示例性方法的进一步实现方式是包括通过预处理模块细化数据表，以排除与治疗装置交互不充分的患者相关的数据；以及转换数据以用于输入到训练模块的实施例，其中治疗装置是急救吸入器或控制吸入器。另一实现方式是其中数据输入包括来自由患者群体操作的移动设备的数据，来自在移动设备上执行的应用程序的数据，与治疗装置接口的应
用程序，以及客户服务数据。另一实现方式是其中存储的模型由预测端点模块执行，以基于单个患者的治疗装置的临床数据和事件数据来提供与单个患者相关的流失可能性的预测。
17.另一个公开的实例是一种用于训练机器学习模型的机器学习流水线系统，机器学习模型用于预测操作治疗装置的患者的流失。数据输入接口从患者群体收集数据输入。数据输入包括与监测治疗装置的操作有关的临床数据和事件数据。组织模块组织数据输入并产生数据表。训练模块根据数据表训练机器学习模型以对影响流失的多个输入因素进行加权，并在确定流失可能性时确定输入因素的影响以产生预测端点。存储装置存储经训练的机器学习模型。
18.示例性机器学习流水线系统的另一实现方式是包括预处理模块的实施例，预处理模块细化数据表以排除与治疗装置的交互不充分的患者有关的数据，并转换数据以用于输入到训练模块，其中治疗装置是急救吸入器或控制吸入器。另一实现方式是其中数据输入包括来自由患者群体操作的移动设备的数据，来自在移动设备上执行的应用程序的数据，与治疗装置接口的应用程序，以及客户服务数据。另一实现方式是其中存储的模型由预测端点模块执行，以基于单个患者的治疗装置的临床数据和事件数据来提供与单个患者相关的流失可能性的预测。
19.以上发明内容并不旨在表示本公开的每个实现方式或每个方面。相反，前述发明内容仅提供本文所阐述的一些新颖方面和特征的实例。当结合附图和所附权利要求考虑时，通过以下对用于实现本发明的代表性实施例和模式的详细描述，本发明的上述特征和优点以及其他特征和优点将变得显而易见。
附图说明
20.根据以下结合附图对示范性实施例的描述，将更好地理解本公开，在附图中：
21.图1示出了用于提供使用治疗装置的患者的流失预测的流失分析系统；
22.图2是示出在客户端设备、应用服务器和/或数据库服务器中使用的计算设备的实例的高层框图；
23.图3是示例性机器学习流水线的框图；
24.图4是由图3中的示例性机器学习流水线产生的组织的数据表的实例；
25.图5是图3中的机器学习流水线的模型训练和开发模块的框图；以及
26.图6是由图3中的机器学习流水线产生的服务端点。
27.本发明容许各种修改和替代形式。在附图中以示例的方式示出了一些代表性实施例，并且将在此对其进行详细描述。然而，应当理解，本公开并不旨在限于所公开的特定形式。相反，本公开将覆盖落入由所附权利要求限定的本公开的精神和范围内的所有修改、等同物和替换。
具体实施方式
28.本发明可以以许多不同的形式实施。在附图中示出了代表性实施例，并且在此将对其进行详细描述。本公开是本公开的原理的实例或说明，并且不旨在将本公开的广泛方面限制于所示出的实施例。在此程度上，例如在摘要、发明内容和具体实施方式部分中公开但未在权利要求书中明确阐述的要素和限制不应以暗示、推断或其他方式单独或共同并入
权利要求书中。出于本详细描述的目的，除非明确放弃，否则单数包括复数，反之亦然；词语“包括”是指“包括但不限于”。此外，例如“约”、“几乎”、“基本上”、“近似”等近似词在本文中可用于表示例如“在”、“接近”或“几乎在”或“在3％至5％内”或“在可接受的制造公差内”或其任何逻辑组合。
29.本公开涉及一种系统，该系统收集诸如药物吸入器的治疗装置的流失的相关数据。通过机器学习流水线从收集的数据确定与流失率相关的因素。
30.流失分析的一个益处是治疗装置的改进，因为该分析使得产品和工程团队能够设计解决与未来流失相关的情况和行为的特征。另一个益处是，所识别的与流失相关的因素可以应用于更个性化的通信、内容和特征，用于个体患者以降低流失率。能够预测用户在下一个预定时间(例如30天)流失的概率以及影响该概率的因素使得能够与易受影响的患者进行主动通信。这允许提前解决任何问题，或为行为改变提供某些激励，导致更强的保留，并因此得到更好的长期临床结果。更好地依从个人治疗装置如吸入器可以在12个月的时间内显著减少紧急就诊和住院。因此，通过这种服务改善患者保留极有可能降低医疗保健的利用率。该分析允许以显著的裕度改善依从性。因此，保留患者导致药物伴侣的药物填充增加。这些药物转而被证明改善临床结果。
31.图1示出了根据一个实施例的流失分析系统100，该系统用于基于监测准确实时的药剂装置事件来收集数据，对该数据执行分析，并且基于对一般患者群体的特定治疗装置的高流失指示的识别来提供输出。
32.分析系统100包括客户端计算设备110、药剂装置传感器120、药剂装置160、应用服务器130、数据库服务器140和网络150。尽管图1仅示出了分析系统100的大多数组件的单个实例，但是实际上每个组件可以存在多于一个，并且可以使用附加的或更少的组件。
33.客户设备110在其用户的支持下经由网络150与分析系统100交互。出于解释和清楚的目的，识别至少两种不同类型的用户是有用的。患者111是患有诸如哮喘或copd的呼吸疾病的用户，其至少部分地利用呼吸疾病分析系统100来获得在该实例中由服务器130提供的个性化急救事件风险通知以及由其健康护理提供者112创建的管理通知。可以提供这种通知以交换用户的许可以允许呼吸疾病分析系统100监测患者111的药剂装置160的使用。如下面将解释的，由与药剂装置160和用户的客户端设备110相关联的传感器120检测药物事件，传感器120又向应用服务器130报告。在该实例中，患者111表示患者群体，针对该群体中的每个患者获取个体数据。另一种类型的使用者可以使用用于控制药物的药剂装置160以控制呼吸疾病的症状。
34.客户端设备110是计算机系统。下面参考图2更完整地描述示例性物理实现方式。客户端设备110被配置为经由网络150与呼吸疾病分析系统100进行无线通信。通过网络150访问，客户端设备110向系统100发送用户的地理位置和急救或控制药物事件的时间，以及描述从相关联的药剂装置传感器120(通篇称为“传感器120”)接收的事件的信息。
35.关于用户位置和事件时间，客户端设备110可以通过使用关于其连接到的蜂窝或无线网络150的信息来确定急救或控制事件的地理位置和时间。例如，可以通过直接查询提供网络150连接的软件栈来确定客户端设备110的当前地理位置。可替代地，可以通过查验经由网络150可访问的外部web服务(图1中未示出)来获得地理位置信息。事件的时间可以由传感器120作为事件数据的一部分来提供，或者通过查询作为客户端设备的本地操作系
统的一部分可用的适当软件例程来添加到事件数据。
36.应用程序115提供显示在客户端设备110的屏幕上的用户界面(这里称为“仪表板”)，并允许用户输入命令来控制应用程序115的操作。仪表板是医疗健康护理提供者112和患者111访问由系统100管理的资源的机制。例如，仪表板允许患者111和提供者112彼此交互、接收哮喘急救事件风险通知、交换关于治疗的消息、提供和接收附加事件和非事件数据等。应用程序115可以被编码为网页、网页系列，或者被编码为在因特网浏览器内呈现的内容。应用程序115还可被编码为被配置为在客户端设备110的本机操作系统上操作的专用应用程序。
37.除了提供仪表板之外，应用程序115还可以在通过网络150发送经处理的数据之前使用客户端设备110的资源在本地对急救或控制事件数据执行一些数据处理。因此，在该实例中，应用程序115允许来自传感器120的与药剂装置160的操作相关的事件数据的通信。通过网络150发送的事件数据由应用服务器130接收，在那里它被分析和处理以便与数据库服务器140一起存储和检索。根据客户应用程序115的需要，应用服务器130可以将检索和存储请求定向到数据库服务器140。如将要解释的，该分析可以扩展为包括来自多个患者111的事件数据。
38.客户端设备110使用网络适配器和有线或无线通信协议与传感器120通信，该协议的实例是蓝牙低能量(bluetooth low energy，btle)协议。btle是在短程无线网络中通过无线电链路无线地传输数据的短程低功率协议标准。在传感器120和客户端设备110已经使用btle万能钥匙彼此配对之后，传感器120自动地与客户端设备110同步并传送与药剂装置使用相关的信息。如果传感器120在急救药物事件之前没有与客户端设备110配对，则信息被本地存储，直到这种配对发生。在配对时，传感器120将任何存储的事件记录传送到客户端设备110。在其他实现方式中，使用其他类型的无线连接(例如，红外或ieee 802.11)。
39.虽然客户端设备110和药剂装置160在上文中被描述为分离的物理装置(例如分别为智能电话和吸入器)，但是在将来，预期药剂装置160不仅可以包括与装置160集成到单个外壳中的传感器120，而且可以包括客户端设备110的多个方面。例如，药剂装置160可以包括视听接口，视听接口包括显示器或其他照明元件以及用于呈现视觉可听信息的扬声器。在这种实现方式中，药剂装置160本身可以直接呈现由服务器130提供的通知的内容，而代替或附加于通过客户端设备110呈现它们。
40.示例性的药剂装置160是用于将药物输送到经历呼吸疾病急救事件的用户的肺的医疗装置。不同的药剂用于哮喘和copd。不同的药剂也可用于哮喘和copd的急救和控制。药剂装置(例如吸入器)通常是便携式的并且足够小，以便用手携带，以便在治疗呼吸症状时容易接近。在一个实施例中，药物以气雾剂形式通过药剂装置160如计量剂量吸入器输送。计量剂量吸入器包括气溶胶药物的加压推进剂罐、用于输送调节的药物剂量的计量阀、保持加压罐同时形成用于输送药物的吸嘴的塑料保持器。在另一实施例中，药物以干粉形式通过药剂装置160如干粉吸入器输送。干粉吸入器可具有容纳轮和齿轮机构的笛卡尔卵形体，轮和齿轮机构使得使用者能够通过干粉药物带进行分度。干粉吸入器的主体还包括歧管和吸嘴以将干粉输送给使用者。尽管在该实例中使用了药剂装置，但是应当理解，流失分析可以用于需要用户定期使用该装置的任何个人治疗装置。此外，尽管上述实例涉及呼吸障碍，但本文所述的原理可应用于其他类型疾病的治疗方案。
41.每个患者可以与多于一个的药剂装置160相关联。例如，患者可以具有分配急救药物的急救药剂装置160和分配控制药物的控制药剂装置160。类似地，每个患者可以与多于一个的传感器120相关联，每个传感器被选择以与患者的药剂装置160之一一起操作。
42.通常，传感器120是监测药物分配器160的使用的物理装置。传感器120可移除地连接到药物分配器而不妨碍药物分配器的操作，或者传感器120是集成组件，其为由其制造商提供的药物分配器160的固有部分。
43.传感器120包括其自己的网络适配器(未示出)，网络适配器通过有线连接或者更典型地通过无线射频连接与客户端设备110通信。在一个实施例中，网络适配器是蓝牙低能量(btle)无线发射机，然而在其他实施例中，可以使用其他类型的无线通信(例如，红外、ieee 802.11)。
44.传感器120还可以被配置为更直接地与应用服务器130通信。例如，如果传感器120的网络适配器被配置为经由诸如ieee 802.11或lte的无线标准进行通信，则适配器可以与诸如无线路由器的无线接入点交换数据，无线接入点进而可以与应用服务器130进行通信，而不必在每次数据交换中涉及客户端设备110。这两种通信方法不是互相排斥的，并且传感器120可以被配置为与客户端设备110和应用服务器130两者通信，例如使用冗余传输来确保事件数据到达应用服务器130，或者在应用服务器130确定响应于事件提供什么通知时直接向客户端设备110提供信息。
45.如上所述，传感器120捕获关于药剂装置160的使用的数据。具体地，每个传感器120捕获急救药物事件的时间和地理位置，即患者111对急救药剂装置160的使用。每个传感器120实时地或一旦实现网络连接就自动地发送事件数据，而无需来自患者111或健康护理提供者112的输入。药物事件信息被发送到应用服务器130，用于分析、哮喘急救事件通知的生成，以及用于多个病人的事件数据的汇总分析，以便确定流失。
46.为了实现这个目标，有多种不同的方式来构造传感器120，并且该构造将部分地取决于药剂装置160自身的构造。通常，所有传感器120将包括板载处理器、永久存储器和上述网络适配器，它们一起用于记录、存储和向客户端设备110和/或服务器130报告药物事件信息。传感器120还可以包括用于记录事件的时间和日期的时钟。
47.关于具体的传感器120结构，传统的吸入器，例如机械剂量计数器，设计时并不考虑传感器120，因此传感器120可以相应地构造。以这种方式的一些实现方式包括机械、电或光学传感器，用于检测装置160的运动、装置的预注、装置的激活、使用者的吸入等。相反，诸如可偏转薄膜剂量计数器的现代吸入器包括电路，电路可将事件信息报告为电数据信号，传感器120被设计成接收和解释该电数据信号，例如药剂装置160本身可将运动、预注和激活报告给传感器120。
48.关于传感器120和药剂装置160的硬件和软件组件的更多信息，以及它们之间的交互以记录急救药物事件可以在于2009年1月1日提交的美国专利申请第12/348,424号和于2014年5月21日提交的国际申请第pct/us2014/039014中找到，这两个申请通过引用整体并入本文。
49.应用服务器130是计算机或计算机网络。尽管在图2中示出了简化的实例，但是典型地，与例如用作客户端设备110的典型计算系统相比，应用服务器将是使用强大处理器、大存储器和更快网络组件的服务器类系统。服务器通常具有大的辅助存储器，例如，使用
raid(独立磁盘的冗余阵列)阵列和/或通过建立与独立内容传递网络(cdn)的关系来存储、交换和发送数据，诸如上述考虑的哮喘通知。另外，计算系统包括操作系统，例如unix操作系统、linux操作系统或windows操作系统。操作系统管理应用服务器130的硬件和软件资源，并且还提供各种服务，例如过程管理、数据的输入/输出、外围设备的管理等。操作系统提供用于管理存储在设备上的文件的各种功能，例如，创建新文件、移动或复制文件、将文件传送到远程系统等。
50.应用服务器130包括用于支持许多不同的客户端设备110通过网络150访问和使用分析系统100的软件架构，并且因此在高层级上通常可以表征为基于云的系统。应用服务器130通常为患者111和健康护理提供者112提供平台，以报告由与其药剂装置160相关联的传感器记录的数据，包括急救药物和控制药物事件，在呼吸疾病治疗计划上协作，浏览和获得关于其状况和地理位置的信息，并利用各种其他功能。
51.通常，应用服务器130被设计成处理各种各样的数据。应用服务器130包括执行各种功能的逻辑例程，这些功能包括检查输入数据的有效性，在必要时对数据进行解析和格式化，将经处理的数据传递到数据库服务器140以供存储，以及确认数据库服务器140已被更新。
52.应用服务器130至少部分地基于患者进行存储和管理数据。为此，应用服务器130为每个用户创建患者简档。患者简档是表征呼吸疾病分析系统100的患者111的一组数据。患者简档可以包括关于患者的身份信息，诸如年龄、性别、当前急救药物、当前控制药物、通知偏好、控制药物依从计划、相关医疗历史和被授权访问患者简档的非患者用户的列表。简档还可以指定设备标识符，例如唯一的媒体访问控制(mac)地址，其标识被授权为患者提交数据(例如控制和急救药物事件)的一个或多个客户端设备110或传感器120。
53.简档可以指定向患者111及其个人健康护理提供者112提供哪些不同类型的通知，以及提供通知的频率。例如，患者111可以授权健康护理提供者112接收指示急救事件的通知。患者111还可以授权他们的健康护理提供者112访问他们的患者简档和急救事件历史。如果健康护理提供者112被提供对患者111的患者简档的访问，则健康护理提供者可以为相应的copd或哮喘病状指定控制依从或急救药物计划。药物计划包括针对控制药物的每天规定剂量数。
54.应用服务器130还为健康护理提供者112创建简档。健康护理提供者简档可包括关于健康护理提供者112的标识信息，诸如办公室位置、资格和证书等。健康护理提供者简档还包括关于他们的病人群体的信息。提供者简档可包括对提供者的患者的所有简档的访问，以及从那些简档导出的数据，诸如汇总人口统计信息、急救和控制药物事件模式等。该数据可以根据存储在患者简档中的任何类型的数据被进一步细分，诸如按地理区域(例如，社区、城市)、按时间段(例如，每周、每月或每年)。
55.应用服务器130从客户端设备110或传感器120接收急救药物事件信息，触发应用服务器130上的各种例程。在下面描述的示例性实现方式中，数据分析模块131执行例程以访问事件数据、同步数据以及包括患者简档的其他数据，分析数据，并将其分析结果输出给患者111和提供者112。该过程通常称为流失风险分析。在该实例中，相对于诸如吸入器160的治疗装置的使用执行流失风险分析。可替代地，可以针对特定患者或患者子组执行流失风险。
56.其他类型的分析可以包括每日/每周的依从性趋势、随时间的依从性变化、与其他相关群体(例如，所有患者、关于特定急救药物或控制药物或其组合的患者)的依从性比较、触发(空间、时间、环境)的识别、随时间的急救使用趋势，以及与其他相关群体的急救使用比较。
57.响应于所执行的任何分析，应用服务器130准备并输送推送通知，以发送到患者111、经授权的健康护理提供者112和/或被提供对患者简档的访问的其他用户。通知可以提供关于药物急救事件中涉及的定时、位置和受影响的患者111的细节。通知还可以包括请求被分发给紧急援助提供者112的紧急援助的遇险或紧急信号。通知还可以包括由数据分析模块131执行的流失分析的结果。下面进一步描述关于可以发送的通知的类型以及它们可以包含的内容的更多信息。
58.除了响应于哮喘或copd恶化风险分析而提供推送通知之外，还可以在特定时间间隔将通知提供为拉取通知。另外，一些通知(推送或拉取)可以不响应于响应于急救药物事件而执行的哮喘或copd恶化风险分析而被触发，而是响应于响应于哮喘或copd恶化风险分析中的潜在因素之一的改变而执行的风险分析而被触发，从而适当地更新的通知。例如，如果天气状况表明空气污染正在增加或即将增加，则这可触发对位于污染正在发生的特定地理区域中的所有患者进行哮喘加重风险分析。
59.通知通过网络150以专门设计用于客户应用程序的数据格式提供给客户应用程序115，并且附加地或可替代地可以作为短消息服务(sms)消息、电子邮件、电话或以使用其他通信介质通信的其他数据格式提供。
60.数据库服务器140存储与患者和提供者数据相关的数据，诸如简档、药物事件、患者医疗历史(例如，电子医疗记录)。为了安全起见，患者和提供者的数据是经过加密的，并且至少有密码保护和其他安全保障，以满足所有健康保险可携性和责任法案(health insurance portability and accountability act，hipaa)的要求。合并来自多个患者的数据(例如，汇总急救药物事件数据)并提供给用户的任何分析(例如，哮喘风险分析)被去识别化，使得个人识别信息被去除以保护患者隐私。数据库服务器140还可以包括来自健康护理提供者112的关于患者的客户服务信息，例如询问、请求帮助等。
61.数据库服务器140还可以存储非患者数据。该数据包括关于多个地理区域的区域数据，地理区域例如是患者物理上所处并可能暴露于污染物的住宅或商业区中的公共空间。该数据可以特别地包括或被处理以获得患者对绿色空间(包括集中的树和植物的区域)的接近度。区域数据的一个实例包括地理参考天气数据，诸如温度、风模式、湿度、空气质量指数等。另一个实例是地理参考污染数据，包括在一个时间实例或经验测量的各种污染物的微粒计数。区域数据包括关于急救事件的时间和地点的当前天气状况的信息，例如温度、湿度、空气质量指数。以上所有数据项可以随时间变化，并且同样地，数据本身可以按时间索引，例如单独的数据点可以按一天中的时间(包括按分钟或小时)、或在更长的时间段内(例如按天、星期、月或季节)可用。虽然数据库服务器140在图1中被示为与应用服务器130分离的实体，但是数据库服务器140也可以是作为诸如服务器130的另一服务器的一部分的硬件组件，使得数据库服务器140被实现为一个或多个持久存储装置，其中用于与数据库中存储的数据进行接口的软件应用层是另一服务器130的一部分。
62.数据库服务器140根据定义的数据库模式存储数据。通常，由于底层数据库结构中
的实现方式差异，即使当存储包括云应用事件日志和日志度量的相同类型的数据时，跨不同数据源的数据存储模式也显著变化。数据库服务器140还可以存储不同类型的数据，例如结构化数据、非结构化数据或半结构化数据。数据库服务器140中的数据可以与患者、患者组和/或实体相关联。数据库服务器140提供对查询语言(例如，用于关系数据库、json nosql数据库等的sql)中的数据库查询的支持，用于指定管理由数据库服务器140表示的数据库对象、从数据库服务器140读取信息或向数据库服务器140写入的指令。
63.网络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)的常规加密技术来加密所有或一些链路。在另一实施例中，实体可以使用定制和/或专用数据通信技术来代替或附加于上述技术。
64.图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或其他随机存取固态存储器装置。
65.存储装置230是任何非暂时性计算机可读存储介质，例如硬盘驱动器、光盘只读存储器(cd-rom)、dvd或固态存储装置。存储器215保存由处理器205使用的指令和数据。i/o装置225可以是触摸输入表面(电容性的或其他的)、鼠标、跟踪球或其他类型的定点装置、键盘或其他形式的输入装置。显示器235显示来自计算机200的图像和其他信息。网络适配器220将计算机200耦合到网络150。
66.如本领域所公知的，计算机200可以具有与图2所示的组件不同的组件和/或其他组件。此外，计算机200可以缺少某些示出的组件。在一个实施例中，充当服务器140的计算机200可以缺少专用i/o装置225和/或显示器218。此外，存储装置230可以是本地的和/或远离计算机200(诸如在存储区域网络(san)中实现的)，并且在一个实施例中，存储装置230不是cd-rom装置或dvd装置。
67.通常，在客户端设备110中使用的确切物理组件将在大小、功率要求和性能上不同于在应用服务器130和数据库服务器140中使用的组件。例如，客户端设备110通常是家用计算机、平板计算机、膝上型计算机或智能电话，其将包括相对较小的存储容量和处理能力，但将包括输入装置和显示器。这些组件适合于数据的用户输入和接收、显示以及与由应用服务器130提供的通知交互。相反，应用服务器130可以包括许多物理上分离的本地联网的计算机，每个计算机具有大量的处理能力，用于执行上面介绍的流失风险分析。在一个实施例中，应用服务器130的处理能力由诸如amazon web services
tm
的服务提供。此外，相反，数
据库服务器140可以包括许多物理上分离的计算机，每个计算机具有用于存储与应用服务器相关联的数据的大量持久存储容量。
68.如本领域中已知的，计算机200适于执行用于提供本文描述的功能的计算机程序模块。模块可以用硬件、固件和/或软件来实现。在一个实施例中，程序模块存储在存储装置230上，加载到存储器215中，并由处理器205执行。
69.作为用于捕获特定装置160/传感器120组合的这种事件的过程的实例，在症状开始时，传感器120可检测药物分配器160的盖是否打开。当药物分配器的盖打开时，传感器120可检测与分配器160的预注相关的加速度。对于一些类型的药剂分配器，“预注”包括启动机构以从包装释放一定剂量的药物。在其他类型的药物分配器中，“预注”包括药物罐的快速摇动。
70.在检测到预注动作之后，传感器120被配置为将与急救或控制事件相关联的数据存储在传感器120的活动存储器中。急救或控制事件数据可以包括描述与急救事件相关联的时间和日期、药剂装置160的状态或状况(例如电池电平)、剩余药物剂量的数量(在事件之前或之后)、自测结果以及由传感器120测量的用药剂装置160治疗的患者的生理数据的信息。一旦传感器建立与客户端设备110或网络150的网络连接，传感器就向客户端设备110或应用服务器130发送任何本地存储的急救或控制事件数据。如果首先将事件数据发送到客户端设备110，则一旦客户端设备110建立与网络150的网络连接，客户端设备110就将急救或控制事件数据发送到应用服务器130。根据实现方式，客户端设备110或传感器120将事件发生的地理位置添加到发送到应用服务器130的事件数据。
71.在接收和存储急救使用事件数据时，应用服务器130可以向患者请求描述急救或控制使用事件的进一步信息。为了获得该信息，应用服务器130生成推送通知，包括待询问的问题，以发送到患者的客户端设备110。患者可以通过提供响应应用程序的输入来响应请求。可替代地，患者111可以选择不响应请求。这是允许的，信息中的任何空白可以通过稍后的推送通知获得，或者在与患者111会面之后由提供者112输入时获得。在一个实现方式中，未能收到响应请求的附加请求数据并不妨碍分析的剩余部分。
72.除了请求附加事件数据之外，应用服务器130还从数据库服务器140访问所存储的上下文数据。通常，上下文数据是指除了事件数据之外的数据，上下文数据包括但不限于：对于大气状况、天气状况、空气质量状况、花粉数据、从过去的急救使用事件记录的患者数据以及在急救使用事件时药剂装置没有直接检测到的任何其他考虑因素。相反，事件数据是指与急救事件相关并由药剂装置报告的任何参数，例如药物剂量、事件的时间、事件的位置和相关的依从性数据。两种形式的数据可以包括时间上的当前信息以及存储的历史数据。因此，作为获得上下文数据的一部分，应用服务器130还访问患者111的历史急救使用事件数据。这个历史数据可以包括病人在过去各种时间窗口的所有过去的控制或急救药物事件数据，每个历史事件可以包括与此事件报告相同的所有信息项目，以及此后随访时收集的任何数据。
73.在正常过程中，数据库140接收关于发生的急救使用事件的数据，并更新主要患者数据存储和一般患者群体数据存储，以反映与主要患者和患者群体中的所有患者的最近当前急救使用事件相关联的上下文数据。用新的急救使用事件更新数据存储器的频率可以根据许多因素而变化，这些因素包括但不限于患者的情况、他们对控制药物的依从性方案、环
境状况等。患者对规定的控制药物治疗方案的依从性是患者每日使用控制吸入器单元的频率与患者每日被指示使用控制吸入器单元的频率之间的比较，并且可以基于控制吸入器单元的使用来测量。
74.该系统包括在包括不同接口的便携式计算设备110上执行的应用程序115。可以显示数据收集调查以收集与吸入器160的操作有关的主观患者数据。系统存储患者输入的调查数据。
75.在一个实例中，预测治疗装置或病人的流失的过程是由图1中分析系统100的数据分析模块131根据对主要病人背景数据、病人报告的结果和其他相关数据的分析来进行的。分析系统100在应用服务器130上包括数据分析模块131，分析由系统收集的各种数据，如以上介绍并在以下进一步讨论的，以预测病人或装置的流失率。
76.在该实例中，基于数据分析模块131的分析系统通过aws glue提取、转换和加载服务使用spark数据处理引擎来组织来自传感器、电话、应用程序、与联系健康护理提供者或设备制造商有关的服务数据以及临床/静态病人数据的数十亿不同的数据点，以便在日常水平上创建全面的患者视图。
77.为了示例性预测建模的目的，将流失事件定义为连续30天(或更多)中传感器没有与移动设备110上的应用程序115同步的第一天，表明传感器120没有与应用程序115进行通信。这可以被认为是指示患者没有使用药剂分配器160的事件数据，因为不能从应用程序接收到传感器数据。同步允许传感器120收集与药剂吸入器160的使用有关的附加数据。可以选择不同长度的连续天数。示例性分析系统的目的是预测在接下来的30天内发生流失事件的概率。除了30天之外的其他时间段也可用于预测概率。
78.如上所述，流失概率阈值可以被设置在任何水平以触发诸如文本消息、电子邮件或推送通知的动作。这种阈值将在概率分数超过该阈值时触发动作。触发的准确性可以用流失事件召回和触发/警报精度来表征，其中流失事件召回被定义为在流失事件发生之前的前30天内至少创建一次触发的事件的比例，而触发/警报精度被定义为在随后的30天内发生事件的触发的比例。例如，该实例中的预测引擎具有超过75％的流失事件召回和超过30％的触发/警报精度。
79.在该实例中，机器学习的产生优选地包括最佳实践。这些实践包括数据、模型和代码的完整版本控制，以实现再现性/分析。另一最佳实践是丰富的作业、模型、变量和样本元数据，以实现再现性/分析。在本实例中，可从提取、转换和加载(etl)glue服务产生的glue表容易地实现性能监测。再训练、再调整和可变变化是常规释放周期的一部分。
80.本实例中的机器学习模型使用shapley相加解释，这是对模型不可知(在这种情况下，梯度提升树)可解释性的最先进的技术，不仅可以呈现出病人在过去30天内存在的特征或行为，还可以看出每个单独行为对流失的概率有什么影响。这些解释可以帮助我们更好地理解行为的影响，不管是在整个人群中还是在病人的日常水平上。示例性服务中的技术栈(除了数据之外)可以用于未来的机器学习流水线。
81.数据包括数据源的宽度、分析的深度和对不同情况的模块性。在该实例中，相对于源的宽度，将来自分析系统100的数十亿个数据点换算为每患者日50+个变量，然后进一步预处理为总结过去30天的500+个预处理的行为变量。例如，一个组织的变量可以是“今天打开的应用程序的数目”。预处理变量可能是“周平均应用程序打开次数的变化”。
82.关于深度，来自预测端点的主要响应包含在接下来的30天内的流失概率、预处理的输入变量以及这些预处理的输入变量的影响。关于模块性，数据源、流水线和服务本身各自支持多种使用情况。数据源包括因果分析(数据科学)和行为仪表板(数据分析)。机器学习流水线可以预测任何行为，例如应用程序使用或对极其有限的代码变化的依从性。服务包括客户/患者服务工作流程、条件营销内容、个性化产品特征和通知。
83.图3示出了示例性机器学习流水线300。机器学习流水线包括一组数据输入310、数据组织模块312、预处理模块314、模型训练/开发模块316、预测端点模块318和预测cron模块320。输出包括输入/输出表330和服务端点332。在该实例中，数据输入310包括传感器数据输入340、应用程序收集数据输入342、临床数据输入344、移动设备数据输入346和客户服务数据输入348。在该实例中，数据组织模块312、预测cron模块320以及输出330和332是glue etl的一部分。在该实例中，预处理模块314、模型训练/开发模块316、预测端点模块318和预测cron 320是sagemaker服务的一部分。
84.数据组织模块312允许对来自不同源的数据进行组织。这样的源可以包括但不限于产品后端、第三方产品分析服务、第三方客户体验服务、数据湖中的现有表以及数据仓库中的现有表。这些源可以使用涉及并行处理的多个提取－变换－加载(etl)作业来组织，例如，apache spark和aws glue。最终etl作业将来自不同源的所有数据转换为单个表，其中每行表示一个患者的一天，并且每列表示关于该患者天的元数据(例如，用户id或日期字段)或总结该天患者的特定特征或行为的数据点。
85.在该实例中，输入到数据组织模块312的输入数据包括用户id和日期以及数据输入310。在该实例中，传感器数据输入340是从由应用程序收集的来自药剂吸入器160或传感器120的事件数据导出的。传感器数据点的实例包括：自第一次急救传感器与应用程序115同步以来的天数，自第一次控制传感器与应用程序114同步以来的天数，同步次数，重试同步次数，所服用的控制剂量数，控制依从性(所服用的处方剂量的比例)，急救使用次数，以及该天是否包含流失事件(基于后续使用和同步模式)。
86.应用数据输入342是对来自应用程序115的事件数据和从患者收集的主观数据的进一步分析。在该实例中，这样的输入可以包括从应用程序首次打开以来的天数、应用打开的次数、应用程序打开的持续时间、不同特征与交互的次数，例如添加触发、查看趋势标签、使用我的吸入器特征，不同特征交互的持续时间，对应用程序中反馈的响应的次数，接收到的推送通知的次数，以及打开的推送通知的次数。
87.移动设备数据输入346是从移动设备导出的数据，诸如患者的时间、位置和移动。在该实例中，数据输入346可以包括操作系统(即android、ios，哪个版本)、电话模型、启用蓝牙的应用程序心跳的百分比、启用位置的应用程序心跳的百分比以及位置的变化。
88.临床数据输入344和客户服务数据输入348可以从示例性数据库140中的患者相关健康记录和服务记录导出。在该实例中，临床数据输入可以包括疾病、疾病状态、处方药物、剂量和诸如cat或act分数的临床度量。在该实例中，客户服务数据输入可以包括与提供者112的用户交互数据，提供者向用户发送的电子邮件的数量，用户打开的电子邮件的数量，以及用户例如经由电话、电子邮件、文本、聊天与支持团队交互的次数。
89.图4是由示例性数据组织模块312产生的示例性组织的数据表。数据表包括每行中的用户id和日期。每列包括为特定用户id和日期记录的各种事件。例如，第一行包括用户id
和日期以及应用程序打开的次数(4)，应用程序打开的持续时间(300秒)，急救吸入器药物传感器的同步次数(8)，自第一次控制吸入器同步以来的天数(10)，以及今天是否表示流失事件(如果真，则为1，如果假，则为0，在本情况下为0)。
90.图3中的预处理模块314使用来自数据组织模块312的最终表，并且进一步预处理数据，使得其可以由机器学习模型直接用于训练、交叉验证和一般开发。该预处理包括但不限于：1)排除未与产品或服务充分交互的任何用户(例如，他们没有传感器同步或没有app打开)；2)从日期字段(例如年、月和星期几)推断时间变量；3)将分类变量一位独热编码为可由机器学习模型解释的二进制数组；4)将某些变量复制到模型输入表，其中唯一的相关数据点是当前值(例如，自第一次传感器同步以来的天数、星期几、移动平台)；5)在定义的拖尾窗口(例如30天)上创建汇总动态行为的输入变量；6)基于预定的向前窗口(例如30天)创建二进制目标变量，以及在该窗口内是否发生流失事件(定义为至少连续30天中没有传感器同步的第一天)；以及7)根据规则排除任何用户天。
91.总结动态行为的输入值可以包括但不限于：a)1、2、3、7、14和30天组合的移动平均数的差异；b)1、2、3、7、14和30天组合的移动标准差的差异；c)1、2、3、7和14天组合的连续平均数的差异(例如，过去7天与之前7天的对比)；d)1、2、3、7和14天组合的连续标准差的差异；e)2、3、7、14和30天内每个病人天的平均值；以及f)2、3、7、14和30天内每个病人天的标准差。
92.排除任何用户天的规则可包括但不限于：a)如果用户天在该用户的最后一次流失事件之后超过30天；b)如果在拖尾或前向窗口中存在任何错误数据点，例如空值或显著偏远值；以及c)如果在前向或后向窗口中存在用户id改变。然后，预处理模块314将最终的输入和输出阵列连同其他相关元数据一起保存到诸如aws s3桶的数据存储中。
93.模型训练和开发模块316利用来自预处理模块314的数据并执行标准机器学习实践以开发预测模型。开发可以包括但不限于：1)将每个用户天样本分配到不同的交叉验证折叠中，基于用户id、日期或两者进行划分(非样本的随机分配)；2)基于启发式或更复杂方法选择变量/特征，包括但不限于基于相关、基于信息增益、基于聚类的方法；3)机器学习模型的训练；4)基于交叉验证性能选择模型超参数和/或模型类；以及5)在每个折叠上生成诸如训练时间和预测性能的其他相关作业数据和元数据。然后，模型训练和开发模块316将模型工件保存在诸如aws s3桶的数据存储中。该模型工件包含模型文件本身以及所有相关作业、样本和变量元数据。
94.图5是模型训练和开发模块316的框图。模块316包括交叉验证折叠分配子模块510，其中每个用户天样本被分配不同的分组以实现交叉验证的目的。子模块的输出被馈送到模型选择子模块512，在模型选择子模块512中选择模型类，例如梯度提升树、随机森林；在超参数选择子模块514中选择超参数，在该实例中包括但不限于最大深度、学习速率、分割方法，l1或l2正则化的强度、最大叶数和子采样比；以及3)在特征选择子模块516中基于诸如基于相关性的方法、基于信息增益的方法或基于聚类的方法的特征选择方法来选择候选输入变量。选择子模块512、514和516的输出被馈送到训练和交叉验证子模块520中。子模块520的输出被馈送到校准子模块522，校准子模块522校正预测得分中的任何系统过置信度或欠置信度，以确保这些得分表示真实概率得分。校准子模块522的输出被馈送到模型解释子模块524中，模型解释子模块524通过使用shapley相加值对不同用户组、单个用户或单
个用户天的每个输入变量的影响进行综合分析。输出是一组模型工件530，存储在模型创建中涉及的所有相关信息。
95.预测端点模块318接受与最终组织表的模式相匹配的输入，并且包含在由预处理模块314定义的相同拖尾窗口上的数据。端点可以是由模型训练开发模块316产生的预处理代码和模型工件的形式，可以被预测cron作业直接消费和使用。它也可以是api的形式，其中可以将拖尾窗口上的输入数据张贴到端点，并且端点将以与预处理模块相同的方式对数据进行预处理，并且以在做出和理解预测的流失概率时所涉及的相关数据进行响应。
96.预测端点模块318响应的相关数据点包括，但不限于：1)用户id；2)日期；3)在定义的向前窗口(例如30天)中发生流失事件的预测概率或可能性；4)经过处理的输入变量的值(例如，当前日值和趋势值，即移动和顺序平均数和标准偏差)；以及5)这些值如何影响预测概率的量化影响，使用模型解释方法(例如shapley相加值)推断出来。在图6中可以看到示例性预测端点响应。应当理解，示例性流水线模块不限于图6中的变量，并且可以存在图6中未示出的许多其他变量。
97.预测cron模块320以预定的时间和频率(例如，在每天上午2点)执行，并对来自组织表的每个用户的数据进行迭代，以提取在预处理模块中定义的行为的最近拖尾窗。利用该数据，预测cron模块320然后与预测端点交互以生成预测概率和其他相关信息，并将该信息保存在诸如aws s3桶或aws glue表等一个或多个数据存储中。
98.示例性输入/输出表330可以是aws s3桶或aws glue表。不同的存储或表可以用于不同的目的。在这个实例中，几个表可以包含不同的信息并且服务于不同的目的，包括但不限于：1)表格，其中每行表示一个用户天，其中一列包含用户id，一列包含作为字符串的整个预处理的输入响应，以及一列包含流失概率；2)表格，每行表示特定用户天的特定预处理输入值，一列包含用户id，一列包含预测日期，一列包含预处理输入变量名，一列包含值；以及3)表格，其中每行表示特定用户天的特定shapley相加值，一列包含用户id，一列包含预测日期，一列包含预处理的输入变量名，以及一列包含该特定变量－用户－天组合的shapley相加值。
99.服务端点332使得关于每个用户的流失概率的最新信息可用于产品或组织的其他部分，包括但不限于客户体验产品和服务，以及用于供电的营销自动化工具，用于定制用户体验的产品个性化工具。服务端点可以采取经由诸如aws athena的另一产品对aws glue表的直接查询的形式。它可能涉及允许终端用户查询信息的api层，包括但不限于：用户id将流失的概率，关于用户id的行为和流失概率的其他相关数据，在某个概率范围内的所有用户id，在流失概率的某个百分位数范围内的所有用户id。这些查询可以包含用户id的其他条件，包括但不限于特定的程序、区域、疾病、年龄范围和临床状态。
100.如本技术中所使用的，术语“组件”、“模块”、“系统”等一般是指计算机相关的实体，是硬件(例如，电路)、硬件和软件的组合、软件，或者是与具有一个或多个特定功能的操作机器相关的实体。例如，组件可以是，但不限于，在处理器(例如，数字信号处理器)上运行的进程、处理器、对象、可执行程序、执行线程、程序和/或计算机。作为说明，在控制器上运行的应用程序以及控制器都可以是组件。一个或多个组件可驻留在进程和/或执行线程内，并且组件可位于一个计算机上和/或分布在两个或更多个计算机之间。此外，“装置”可以以特别设计的硬件的形式出现；通过在其上执行使硬件能够执行特定功能的软件而专门化的
通用硬件；存储在计算机可读介质上的软件；或其组合。
101.这里使用的术语仅用于描述特定实施例的目的，并不旨在限制本发明。如本文所用，单数形式“一(a)”、“一个(an)”和“该(the)”也旨在包括复数形式，除非上下文另外明确指出。此外，就在详细说明和/或权利要求书中使用的术语“包括(including/includes)”、“具有(having/has)”、“带有(with)”或其变体而言，此类术语旨在以类似于术语“包括(comprising)”的方式为包含性的。
102.除非另有定义，本文使用的所有术语(包括技术和科学术语)具有与本领域普通技术人员通常理解的相同的含义。此外，诸如在通常使用的词典中定义的那些术语的术语应当被解释为具有与其在相关技术的上下文中的含义一致的含义，并且将不以理想化或过度正式的意义来解释，除非在此明确地如此定义。
103.来自以下权利要求1至20中任一项中的一者或多者的一个或多个元素或方面或步骤或其任意部分可以与来自其他权利要求1至20中任一项中的一者或多者或其组合的一个或多个元素或方面或步骤或其任意部分组合，以形成本公开的一个或多个附加实现方式和/或权利要求。
104.虽然上面已经描述了本发明的各种实施例，但是应当理解，它们仅仅是作为实例而非限制来呈现的。尽管已经参照一个或多个实施例示出和描述了本发明，但是在阅读和理解了本说明书和附图之后，本领域的其他技术人员将想到或知晓等同的替换和修改。此外，虽然本发明的特定特征可能仅相对于若干实现方式中的一个被公开，但是这种特征可以与其他实现方式的一个或多个其他特征组合，这对于任何给定或特定应用可能是期望的和有利的。因此，本发明的宽度和范围不应受到上述任何实施例的限制。相反，本发明的范围应当根据所附权利要求及其等同物来限定。

技术特征：
1.一种用于预测与患者对治疗装置的使用相关的流失的系统，所述系统包括：通信接口，所述通信接口用于收集与监测所述治疗装置向所述患者输送药物的操作有关的事件数据；存储装置，所述存储装置存储所述患者的所述事件数据和临床数据；流失分析模块，所述流失分析模块能够操作以：输入所述事件数据和临床数据；应用机器学习模型以根据所输入的事件数据和临床数据确定所述患者在预定时间段内的流失可能性，其中所述机器学习模型是根据机器学习流水线训练的，所述机器学习流水线具有来自使用所述治疗装置的患者群体的事件数据和临床数据作为输入，以确定针对患者流失的至少一个触发；确定所述流失可能性是否超过阈值；以及如果所述流失可能性超过阈值，则触发与所述患者相关的动作。2.根据权利要求1所述的系统，其中所述治疗装置是急救吸入器或控制吸入器。3.根据权利要求1至2中任一项所述的系统，其中所述通信接口与所述患者的移动设备通信，并且其中将与所述治疗装置通信的传感器与由所述移动设备执行的应用程序同步，以提供事件数据。4.根据权利要求1至3中任一项所述的系统，其中所述机器学习流水线是根据与所述患者群体相关的客户服务数据训练的。5.根据权利要求1至4中任一项所述的系统，其中所述动作是患者警报、健康护理提供者警报、或治疗装置制造商警报中的一者。6.根据权利要求1至5中任一项所述的系统，其中所述机器学习流水线以预测端点作出响应，所述预测端点包括所确定的流失可能性，处理的临床数据和事件数据的值，以及所述值如何影响所确定的流失可能性的量化影响。7.一种用于确定由患者操作的治疗装置的流失的方法，所述方法包括：收集所述患者的临床数据；经由通信接口收集与监测所述治疗装置的操作相关的事件数据；应用机器学习模型以根据所输入的事件数据和临床数据确定所述患者在预定时间段内的流失可能性，其中所述机器学习模型是根据机器学习流水线训练的，所述机器学习流水线具有来自使用所述治疗装置的患者群体的事件数据和临床数据作为输入，以确定针对患者流失的至少一个触发；确定所述流失可能性是否超过阈值；以及如果所述流失可能性超过阈值，则触发与所述患者相关的动作。8.根据权利要求7所述的方法，其中所述治疗装置是急救吸入器或控制吸入器。9.根据权利要求7至8中任一项所述的方法，还包括：经由所述通信接口与所述患者的移动设备通信；以及将与所述治疗装置通信的传感器与由所述移动设备执行的应用程序同步，以提供所述事件数据。10.根据权利要求7至9中任一项所述的方法，其中所述机器学习流水线是根据与所述患者群体相关的客户服务数据训练的。
11.根据权利要求7至10中任一项所述的方法，其中所述动作是患者警报、健康护理提供者警报、或治疗装置制造商警报中的一者。12.根据权利要求7至11中任一项所述的方法，其中所述机器学习流水线以预测端点作出响应，所述预测端点包括所确定的流失可能性，处理的临床数据和事件数据的值，以及所述值如何影响所确定的流失可能性的量化影响。13.一种用于训练机器学习模型的流水线方法，所述机器学习模型用于预测操作治疗装置的患者的流失，所述方法包括：从患者群体收集数据输入，所述数据输入包括临床数据和与监测所述治疗装置的操作相关的事件数据；组织所述数据输入并产生数据表；根据所述数据表训练所述机器学习模型以对影响流失的多个输入因素进行加权，并在确定流失可能性时确定所述输入因素的影响以产生预测端点；以及存储经训练的机器学习模型。14.根据权利要求13所述的方法，还包括：通过预处理模块细化数据表，以排除与所述治疗装置交互不充分的患者相关的数据；以及转换数据以用于输入到训练模块。15.根据权利要求13至14中任一项所述的方法，其中所述数据输入包括来自由所述患者群体操作的移动设备的数据，来自在所述移动设备上执行的应用程序的数据，与所述治疗装置接口的应用程序，以及客户服务数据。16.根据权利要求13至15中任一项所述的方法，其中所存储的模型由预测端点模块执行，以基于单个患者的所述治疗装置的临床数据和事件数据来提供与所述单个患者相关的流失可能性的预测。17.一种用于训练机器学习模型的机器学习流水线系统，所述机器学习模型用于预测操作治疗装置的患者的流失；数据输入接口，所述数据输入接口从患者群体收集数据输入，所述数据输入包括临床数据和与所述治疗装置的操作相关的事件数据；组织模块，所述组织模块组织所述数据输入并产生数据表；训练模块，所述训练模块根据所述数据表训练所述机器学习模型以对影响流失的多个输入因素进行加权，并在确定流失可能性时确定所述输入因素的影响以产生预测端点；以及存储装置，所述存储装置存储经训练的机器学习模型。18.根据权利要求17所述的系统，还包括预处理模块，所述预处理模块细化所述数据表以排除与所述治疗装置的交互不充分的患者相关的数据，并转换数据以用于输入到所述训练模块。19.根据权利要求17至18中任一项所述的系统，其中所述数据输入包括来自由所述患者群体操作的移动设备的数据，来自在所述移动设备上执行的应用程序的数据，与所述治疗装置接口的应用程序，以及客户服务数据。20.根据权利要求17至19中任一项所述的系统，其中所存储的模型由预测端点模块执
行，以基于单个患者的所述治疗装置的临床数据和事件数据来提供与所述单个患者相关的流失可能性的预测。

技术总结
公开了一种用于预测与患者对治疗装置的使用相关的流失的系统和方法。通信接口收集与操作治疗装置向患者输送药物有关的事件数据。存储患者的事件数据和临床数据。流失分析模块输入事件数据和临床数据，并应用机器学习模型，以根据输入的事件数据和临床数据确定患者在预定时间段内的流失可能性。机器学习模型是根据机器学习流水线训练的，机器学习流水线具有来自使用治疗装置的患者群体的事件数据和临床数据作为输入，以确定针对患者流失的至少一个触发。确定流失可能性是否超过阈值。如果流失可能性超过阈值，则触发与患者相关的动作。作。作。


技术研发人员：尼古拉斯
受保护的技术使用者：互惠实验室公司
技术研发日：2021.10.01
技术公布日：2023/8/5