CN114467142A - 通过声音分析的肺部健康感测 - Google Patents

Abstract

本发明涉及一种患者监测***，包括收集来自患者的音频数据的麦克风。音频数据用于生成音频特性以归类音频数据并分析音频数据，从而确定患者健康状态。随时间跟踪音频特性和患者健康状态，并将其用于监测患者呼吸状况。基于音频特性和与各个患者的记录健康状态相关联的音频特性的数据库之间的比较，该***确定患者健康状态。基于音频特性的数据库和相关联的健康状态，该***生成当前患者健康状态的报告。

Description

通过声音分析的肺部健康感测

相关申请的交叉引用

本申请要求申请日为2020年9月2日、申请号为63/073,561的美国临时专利申请的优先权，其全文通过引用归并本文。

技术领域

本申请涉及医疗装备，具体地涉及与确定肺部健康信息、患者康复状态和/或其他参数相关联的***及方法。

背景技术

许多呼吸疾病和呼吸状况都与影响患者呼吸道(例如，鼻腔、口腔、气管、支气管、肺部等)的症状相关联。此外，基于与呼吸疾病和呼吸状况相关联的症状，可能减弱、改变或以其他方式影响患者说话和呼吸的能力。另外地，基于与呼吸疾病和呼吸状况相关联的症状，患者正经受的症状可能导致发生人类可听或不可听的音频事件。这类疾病可包括哮喘、慢性阻塞性肺病(COPD)、支气管炎、肺气肿、肺癌、囊性纤维化、肺炎和胸膜积液。呼吸疾病和呼吸状况导致的症状可包括呼吸道炎症、肺活量改变和/或减小、粘液产生、咳嗽、呼吸困难和其他呼吸症状状。据此，医师可以基于一个或多个上述症状来诊断患者，并可以针对呼吸病提供医疗。

然而，尽管医师可以通过对患者的检查和检验观察上述症状，但也只能在患者在医疗环境内主动接受诊断和/或治疗时观察患者的症状。此外，治疗和康复过程中对患者症状的监测一般是通过在医疗环境内医师观察和/或使用监测设备来实现。这类设备典型地包括耦合到患者的物理引线和/或附件，以便有效监测患者呼吸活动。这类设备对医师来说可能繁琐且难以使用。如果这类设备的引线或其他附件长时间耦合到患者，它们还可能引起不适。患者接受的持续被动监测涉及到使用医疗环境本地的技术和设备，因此这类设备的使用也可能受到限制。

本公开各实例涉及解决上述一个或多个缺点。

发明内容

在本公开一实例中，一种***可以包括可操作为从源自患者和/或个体的噪声中生成音频数据的麦克风。与所述***相关联的麦克风所捕获的音频数据可以产生自人类声带、人类肺部、人类运动和/或与患者和/或个体相关联的其他来源。特别地，患者肺部吸入和呼出空气可能影响患者声带的语音产生。此外，当患者患有呼吸病、呼吸疾病和/或呼吸状况时，可能影响患者的声带和肺部，从而改变患者产生的语音。基于患者的声音和患者的其他呼吸声，与***相关联的麦克风可以生成声音参数。声音参数至少表征与患者相关联的音调、音色、节奏、音量和语速。所述***可以利用声音识别算法来分析与患者相关联的声音参数，以患者的当前状态与患者的先前状态和/或与第二患者相关联的附加状态进行匹配和比较。

一种示例性***可以包括存储器、一个或多个处理器和计算机可执行指令，这些计算机可执行指令存储在存储器中并可由一个或多个处理器执行以执行各种操作。例如，所述操作可以包括：从用户设备接收与患者相关联的当前语音数据；以及至少基于当前语音数据，标识患者的人声话语和呼吸序列中的至少一项。此外，所述操作可以包括：基于人声话语和呼吸序列中的至少一项并基于与患者相关联的先前人声话语和与患者相关联的先前呼吸序列中的至少一项，确定一个或多个音频事件。另外，所述操作可以包括：确定与一个或多个音频事件相关联的一个或多个第一音频特性；以及至少基于一个或多个第一音频特性，确定与一个或多个音频事件相关联的音频事件类别，其中与第二音频特性相关联的音频事件类别指示患者的呼吸状况。据此，可以至少基于一个或多个音频事件与音频事件类别的比较，确定患者与呼吸状况相关联的当前健康状态。

一种由患者监测***执行的示例性方法可以包括：促使麦克风记录来自患者的当前音频数据，该当前音频数据包括患者人声话语和患者呼吸序列；以及从麦克风接收当前音频数据；此外，所述方法可以包括：至少基于先前音频数据，标识与患者人声话语相关联的当前人声特性和与患者呼吸序列相关联的当前呼吸特性；以及使用先前音频数据、与患者相关联的先前人声特性和与患者相关联的先前呼吸序列来训练机器学习算法。另外，所述方法可以包括：基于当前人声特性与先前人声特性的比较，使用机器学习算法来确定患者的当前健康状态。

一种附加示例性患者监测***可以执行操作，包括：促使与用户设备相关联的麦克风收集第一音频录音，其中该第一音频录音包括患者讲话或患者呼吸中的至少一项；从用户设备接收第一音频录音；至少基于第一音频录音，确定与第一音频录音相关联的音频类别，该音频类别与共有一个或多个音频特性的一个或多个人声话语相关联。此外，至少基于音频类别，所述操作可以包括：确定第一患者健康状态，该第一患者健康状态与患者的一种或多种呼吸症状相关联。另外，所述操作可以包括：促使与用户设备相关联的麦克风收集第二音频录音；至少基于第二音频录音，标识一个或多个音频特性与第一音频录音和第二音频录音相关联；以及至少基于一个或多个音频特性，确定第二患者健康状态，其中该第二患者健康状态指示相对于第一患者健康状态的一个或多个健康状态变化。

附图说明

结合附图考虑以下具体实施方式，本公开的特征、本质和各种优点将更加清楚。

图1示出了本公开一种示例性***。在某些实施方式中，图1所示的示例性***的组件可用于监测患者的当前健康状态。

图2示出了本公开另一种示例性***。

图3示出了本公开数据处理工作流程。在某些实施方式中，图1和图2所示的示例性***可以利用配置为标识和分类来自传入音频数据的患者数据的一系列算法。

图4提供了示出本公开一种示例性方法的流程图。

图5提供了示出本公开另一种示例性方法的流程图。

图6提供了本公开可以操作为监测患者当前健康状态的示例性用户设备和服务器。

附图中，附图标记最左边一位数字指示该附图标记首次出现的附图。不同附图中使用相同的附图标记指示相似或相同的项目或特征。附图未按比例绘制。

具体实施方式

本公开部分地涉及一种患者监测***及相应方法。这种示例性患者监测***可以配置为收集与患者或个体相关联的语音数据和音频数据，分析语音数据和音频数据，并将分析结果输出给设备的用户，诸如医师或医师助理。例如，患者监测***可以利用与医疗设备、用户设备、患者设备或配置为收集语音数据和音频数据的其他设备相关联的一个或多个麦克风。所述***可以接收语音数据和音频数据，并通过声音识别算法进行比较与匹配分析。此外，所述***可以基于比较与匹配分析，针对患者确定语音数据和音频数据是否与先前语音数据和先前音频数据相匹配，并确定语音数据和音频数据与先前语音数据和先前音频数据的比较结果。据此，所述***可用于通过分析患者产生的各种人声特性和附加音频特性来监测患者状态。此外，所述***可以生成与患者相关联的建议/或诊断以便显示给患者监测***的用户。例如，利用标准检验数据和/或机器学习技术，所述***可以评估***确定的测量结果以关于患者的健康(例如，患者是否满足一个或多个阈值，是否将完成对患者的附加监测等)向用户提供建议。如此，本文所述的***可以提供自动诊断建议以协助医师或患者监测***的其他用户。

在本文所述的任一实例中，所述患者监测***可以配置为监测诊断患有一种或多种呼吸病的患者。例如，患者可能诊断患有哮喘、慢性阻塞性肺病(COPD)、支气管炎、肺气肿、肺癌、囊性纤维化、肺炎、胸膜积液或其他呼吸病。此外，所述患者监测***可以配置为跟踪患者所患的一种或多种呼吸病可改变的人声特性。例如，所述患者监测***可以配置为从收集自患者的音频数据中确定一个或多个人声特性，一个或多个人声特性包括与患者相关联的音调、音色、节奏、音量、语速、音频事件和其他人声特性。另外地，所述患者监测***可以配置为监测与一种或多种呼吸疾病相关联的一个或多个人声特性。一个或多个人声特性可以被动地收集自患者(例如，无需触发事项或短语即可收集)以监测与呼吸疾病相关联的康复或治疗进程。例如，一种或多种呼吸病可以与一个或多个症状相关联，该症状可以与患者改变的人声特性相关。在某些实例中，哮喘可能与患者呼吸道炎症相关联；COPD可能与无法正常完全呼气和/或正确呼气相关联；支气管炎可能与患者呼吸道中粘液过多和慢性咳嗽相关联；肺气肿可能与患者难以将患者肺部中的空气呼出相关联；肺癌可能与慢性咳嗽、患者声音变化、呼吸声粗重和咳血相关联；囊性纤维化可能与慢性咳嗽、频繁肺部感染、患者呼吸道中粘液积聚、频繁呼吸道感染、喘息和气促相关联；肺炎可能与气促相关联；胸腔积液可能与胸闷和气促相关联；等等。据此，所述患者监测***可以至少基于患者的一个或多个人声特性来确定患者是否对治疗有反应、患者状况是否正在改善以及患者当前状态如何。

此外，在本文任一实例中，所述患者监测***可以利用一个或多个算法、神经网络、机器学习组件和/或配置为随时间跟踪一个或多个人声特性的其他组件。具体地，所述患者监测***可以配置为使得一个或多个人声特性的变化可与患者状态相关联。此外，所述患者监测***可以接收患者状态指示，并将患者状态与在与该指示相关联的时刻所捕获的一个或多个人声特性相关联。据此，所述患者监测***可以在第二时刻基于一个或多个人声特性来标识患者与该状态相关联，或基于一个或多个人声特性来识别患者不再与该状态相关联。另外地，所述患者监测***可以设置有患者状态指示的数据库，其中来自该数据库的患者状态指示可以与患者监测***用来确定当前患者状态是否与患者状态指示相匹配的人声特性集相关联。

下面参照图1至图6描述了有关上述技术的附加细节。应当理解，这些附图描绘了可以利用本公开要求保护的方法的示例性***和设备，而本文所述的方法、过程、功能、操作和/或技术同样也可应用于其他设备、***等。

图1示出了根据某些实施方式的示例性***100，诸如患者监测***。如图1所示，一种示例性患者监测***可用于至少基于患者102产生的呼吸声104监测患者102的当前状态。例如，医疗设备106可以配置为针对呼吸病、呼吸道损伤和/或一种或多种其他呼吸状况来提供治疗。在至少某些实例中，医疗设备106可以是提供呼吸辅助的背心或其他设备、呼吸机设备、持续气道正压通气(CPAP)设备、给药设备、气道清理设备和可用来治疗、监测或以其他方式协助患者的其他呼吸设备。如本文所述，医疗设备106可以包括麦克风108或与麦克风108相关联。此外，控制单元110可以配置为与麦克风108对接，使得麦克风所记录的音频数据可以传输到控制单元110。另外地，麦克风108可以安装、附接、附着或以其他方式物理连接到医疗设备106。

在某些实例中，麦克风112可以配置为监测患者产生的呼吸声104，并从呼吸声104中生成音频数据。此外，用户设备114可以包括麦克风112，并配置为接收和/或记录麦克风112所生成的音频数据。另外地，用户设备114可以是与患者102相关联的个人设备、与医疗设备106相关联的附加设备和/或配置为监测患者102的另外设备。麦克风112可以是与用户设备114相关联的内部麦克风或已经与用户设备114通信地相关联的外部麦克风。

应当理解，图1描绘了***100包括单台医疗设备106和单台用户设备114，在某些附加实例中，***100可以包括任意数目的与医疗设备106和用户设备114基本相似的本地或远程医疗设备和/或用户设备，它们配置为独立和/或组合操作，并配置为通过网络116进行通信。在另外某些实例中，***100可以包括一个或多个数据库118以及一个或多个音频分析***120，其包括一个或多个处理器122、一个或多个网络接口124和/或音频筛选组件126。音频筛选组件126可以包括一个或多个程序、模块、引擎、指令、算法、神经网络、机器学习组件和/或其他处理器122可执行的音频筛选组件。

如本文所述，医疗设备106、控制单元110、用户设备114和/或音频分析***120可以配置为在对患者102治疗之前、期间或之后监测患者102。例如，监测患者102可以包括：在一段时间段内收集来自患者102的呼吸声104；分析生成自呼吸声104的音频数据；确定音频数据中的一个或多个声音/人声特性；在该时间段内跟踪一个或多个声音/人声特性变体；以及确定一个或多个声音/人声特性变体中的患者健康信息。具体地，医疗设备106、控制单元110和/或用户设备114可以配置为从麦克风108和/或麦克风112中的至少一个接收生成自呼吸声104的音频数据。此外，医疗设备106、控制单元110和/或用户设备114可以配置为本地分析音频数据以确定一个或多个人声特性并随时间跟踪一个或多个人声特性。替代地或附加地，医疗设备106、控制单元110和/或用户设备114可以包括能够将生成自呼吸声104的音频数据传输到与患者监测***(即医疗设备106、控制单元110、用户设备114和/或音频分析***120)相关联的其他设备的无线和/或有线通信能力。应当注意，麦克风108和/或麦克风112可以包括包含换能器(例如，能够将声响或机械运动转化为电信号的组件)的录音组件、将声响转化为机械运动的隔膜、信号输出(例如，端口、线缆或其他信号携带组件)、麦克风外壳和/或配置为至少收集呼吸噪声104并提供可记录为音频数据的信号的任何其他音频设备。在另外某些实例中，麦克风108和/或麦克风112可以是电容式麦克风、射频(RF)电容式麦克风、驻极体麦克风、动圈式麦克风、铝带式麦克风、压电式麦克风、光纤麦克风或能够捕捉呼吸噪声104的其他麦克风。无论上述设备使用的麦克风类型如何，可以基于进行高保真记录的能力(例如，记录人类可听和不可听声响的同时准确捕捉可听和不可听声响的音频配置文件的能力)选择与患者监测***相关联使用的麦克风。

在一些实例中，与医疗设备106、控制单元110、用户设备114和/或音频分析***120相关联的存储器可以配置为存储和/或访问与患者102相关联的数据。例如，患者102和/或患者监测***的用户可以在发起患者监测时提供数据(本文中称为“患者数据”)。例如，当医疗设备106、控制单元110、用户设备114和/或音频分析***120用于监测与患者102相关联的呼吸声104时，患者数据文件可以是针对生成自患者的音频数据创建，并包括患者数据。此外，患者102可以提供患者数据或用户可以请求患者数据，患者数据包括关于患者102的人口统计信息、身体特性、偏好和类似信息。例如，患者102可以提供姓名、年龄、种族、性别等人口统计信息。患者102还可以提供患者102的身高等身体特性信息。在这些实例中，监测患者102同时，或监测开始之前，用户可以请求患者数据。在某些实例中，可以向用户提供与患者102相关联的预定类别，诸如预定年龄范围(例如，6到12个月、1到5岁等)，并且用户可以请求患者数据以便选择与患者102相关联的适当类别。在其他实例中，用户可以提供与患者数据相关联的自由形式输入。在又一些实例中，可以直接将输入元素提供给患者102。

在某些实例中，医疗设备106、控制单元110、用户设备114和/或音频分析***120可以配置为在患者监测过程开始时生成与患者102相关联的音频数据。例如，医疗设备106和/或用户设备114可以包括一个或多个麦克风、音频传感器或配置为随时间从患者102的呼吸声104中生成音频数据的其他音频捕捉设备。替代地或附加地，医疗设备106和/或用户设备114可以包括一个或多个麦克风、音频传感器或配置为随时间从患者产生的语音中生成附加音频数据的其他音频捕捉设备。另外地，医疗设备106和/或用户设备114的一个或多个处理器可以分析收集的音频数据以确定例如一个或多个音频特性，其包括与患者相关联的音调、音色、节奏、音量和语速中的至少一项。替代地或附加地，医疗设备106和/或用户设备114可以分析收集的附加音频数据以确定一个或多个声音参数，其包括与患者相关联的音调、音色、节奏、音量和语速中的至少一项。

替代地或附加地，医疗设备106、控制单元110和/或用户设备114可以配置为将音频数据、附加音频数据和/或任何其他收集的信息通过网络116传输到音频分析***120来进行分析。在任何这些实例中，音频分析***120可以将这些信息存储在音频筛选组件126和/或外部数据库118中。例如，数据库118可以包括和与音频筛选组件126相关联的计算机可读介质基本相似和/或相同的存储器或计算机可读介质。音频分析***120和/或医疗设备106、麦克风108、控制单元110和/或用户设备114可以通过网络116访问数据库118。在任何这些实例中，数据库118可以配置为将患者数据与患者ID(例如，姓名、社会保险号、字母数字代码等)或其他唯一患者标识符相关联地存储。当患者102和/或用户输入患者ID时，音频筛选组件126可以访问或接收与患者ID相关联地存储的患者数据。

如本文所用，网络116通常是任何类型的无线网络或本领域已知的其他通信网络。网络116的实例包括互联网、内联网、广域网(WAN)、局域网(LAN)、虚拟专用网(VPN)、蜂窝网络连接和使用诸如802.11a、b、g、n和/或ac等协议建立的连接。

在某些实例中，医疗设备106、麦克风108、控制单元110和/或用户设备114可以包括配置为执行存储在计算机可读介质中的指令以执行各种操作和方法的微处理器或控制单元。例如，医疗设备106和/或控制单元110可以包括配置为操作性控制麦克风108的一个或多个处理器和/或其他硬件和/或软件组件。类似地，用户设备114可以包括配置为操作性控制麦克风112的一个或多个处理器和/或其他硬件和/或软件组件。此外，医疗设备106、麦克风108、控制单元110和/或用户设备114的一个或多个处理器可以配置为提供用户界面、声音识别算法和患者监测***的其他组件。在某些附加实例中，医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120可以包括单个处理单元(例如，单处理器)或数个处理单元(例如，多处理器)，并可以包括单计算单元或多计算单元和/或多处理核。医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120的处理器122可以实现为一个或多个微处理器、微计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或任何基于操作指令操控信号的设备。例如，医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120的处理器122可以是任何合适类型的一个或多个硬件处理器和/或逻辑电路，其具体编程或配置为执行本文所述的算法、操作和方法。医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120的处理器122可以配置为提取和执行存储在音频筛选组件126中的计算机可读指令，它们可以对处理器122进行编程以执行本文所述的功能。附加地或替代地，医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120的处理器122可以配置为提取和执行存储在计算机可读介质和/或各个设备的/本地的其他存储器中的计算机可读指令。

如本文所述，处理器(如处理器122)可以是单个处理单元或数个处理单元，并可以包括单计算单元或多计算单元或多处理核。处理器122可以实现为一个或多个微处理器、微计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或任何基于操作指令操控信号的设备。例如，处理器122可以是任何合适类型的一个或多个硬件处理器和/或逻辑电路，其具体编程或配置为执行本文所述的算法和过程。处理器122可以配置为通过网络接口发送、接收和传输通信。此外，处理器122可以配置为提取和执行存储在音频筛选组件126中的计算机可读指令，它们可以对处理器122进行编程以执行本文所述的功能。

与医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120相关联的网络接口可以使能患者监测***100中显示出的组件和/或设备之间和/或与一个或多个其他远程***以及其他联网设备之间的有线和/或无线通信。例如，至少一些网络接口可以包括个域网组件以使能通过一个或多个近程无线通信信道的通信。另外地，至少一些网络接口可以包括广域网组件以使能通过广域网的通信。这类网络接口可以例如通过网络116使能医疗设备106、麦克风108、控制单元110、用户设备114和/或音频分析***120和/或***100的其他组件之间的通信。

音频筛选组件126可以包括易失性和非易失性存储器和/或可移动和不可移动介质，其在任何类型的技术中实现以存储计算机可读指令、数据结构、程序模块或其他数据等信息。存储器可以包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、光存储、固态存储、磁带、磁盘存储、RAID存储***、存储阵列、附网存储、存储区域网、云存储或可用来存储期望信息并可由计算设备访问的任何其他介质。音频筛选组件126可以包括各种计算机可读存储介质和/或可以是有形非暂态介质，提及时，非暂态计算机可读介质不包括能量、载波信号、电磁波和信号本身等介质。

音频筛选组件126可以包括任何数目的处理器122可执行的功能组件。在许多实施方式中，这些功能组件包括处理器122可执行的指令或程序，它们当被执行时将一个或多个处理器122具体配置为执行与监测患者健康状态相关联的动作。

图1中虽未示出，但在某些实例中，音频筛选组件126可以包括配置为存储音频数据分析组件的计算机可读介质。在这些实例中，音频数据分析组件可以配置为接收、访问和/或分析患者监测过程中由医疗设备106和/或用户设备114收集和/或检测的音频数据。例如，音频数据分析组件可以配置为通过网络116接收音频数据。音频数据可以由上述各种设备和/或麦克风在患者监测过程中生成自患者所产生的呼吸声104和/或语音。音频数据分析组件可以分析音频数据以确定与患者102相关联的一个或多个人声特性、呼吸特性和/或音频特性，诸如与患者102相关联的音调、音色、节奏、音量和语速。

另外地，图1中虽未示出，但音频筛选组件126还可以包括配置为存储诊断数据组件的计算机可读介质。诊断数据组件可以配置为接收、访问和/或分析与患者102相关联的诊断数据和与患者相关联的健康状态。例如，在这些实施例中，诊断数据组件可以配置为访问或接收来自一个或多个附加数据库(例如，数据库118、第三方数据库等)的数据，该附加数据库存储检验数据、医师评估、先前测量数据和/或指示确定自音频数据且与患者102相关联的音频特性和人声特性应当落入的各个阈值或范围的一系列值。这些阈值或范围可以与患者102的初始健康状态、患者102的目标健康状态和/或相对于患者102的先前健康状态的患者102的当前健康状态。例如，诊断数据组件可以访问或接收个体和/或标准化诊断数据，个体和/或标准化诊断数据可用于与上述音频数据分析组件所生成和存储的音频数据/音频数据特性相比较。例如，与患者102相关联的诊断数据可以包括评估患者102为健康和/或处于目标健康状态时所获得的标准测量结果(例如，与患者102相关联的音调、音色、节奏、音量和语速)。附加地或替代地，与患者102相关联的诊断数据可以包括评估患者102患有呼吸病和/或呼吸状况(即，哮喘、COPD、支气管炎、肺气肿、肺癌、囊性纤维化、肺炎和胸膜积液)并确定患者具有与该评估相关联的初始健康状态时所获得的标准测量结果(例如，与患者102相关联的音调、音色、节奏、音量和语速)。据此，标准测量结果可以标识当前音频特性和/或人声特性应当达到(即，与目标健康状态相关联的标准测量结果)和/或需要提升(例如，与初始健康状态相关联的标准测量结果)的音频特性和/或人声特性值的阈值范围。另外地，标准测量结果可以整合来自其他患者的诊断数据以确定患者102是否正常从初始健康状态中康复，患者102是否正朝向目标健康状态发展，患者102的健康是否已降至低于目标健康状态，和/或其他监测患者102的辅助。

图2示出了本公开一种附加示例性***200。在某些实例中，***200可以包括包含在***100之内的一个或多个相同组件。在某些附加实例中，***200可以包括提供与包含在***100中的组件相似的功能的不同组件。如图2所示，***200可用于确定在一段时间内监测医疗环境208或非医疗环境214内的患者202。医疗环境208内，患者202可以与医疗设备204和麦克风206相关联。非医疗环境214内，可以通过辅助设备210和个人设备212监测患者202。应当注意，辅助设备210和个人设备212可以包括与麦克风206相同或不同的一个或多个附加麦克风。此外，医疗设备206、辅助设备210和个人设备212可以将音频数据通过通信网络216传输到音频分析环境218。音频分析环境218可以包括配置为存储生成自患者202的音频数据的数据库、声音识别算法222、音频特征算法224和患者状态组件226。

在图2的示例性***200中，如图1所述，与医疗设备204相关联的麦克风206可以在治疗期间监测患者202。例如，麦克风206可以收集和记录一个或多个人声话语、呼吸样本、音频事件和/或患者202产生的其他话语。一个或多个人声话语可以包括对话、请求短语和/或至少部分地由患者202的声带产生的其他声响。类似地，一个或多个呼吸样本可以包括长时间患者呼吸、患者睡眠周期中的呼吸模式、患者202治疗期间的呼吸模式和/或至少部分地由患者202吸入和呼出肺部空气产生的其他声响。另外地，一个或多个音频事件可以包括哀叹、哀鸣、急剧吸气/呼气、喘气、窒息事件和/或可以指示患者202呼吸道状态的其他音频事件。

在图2的示例性***中，麦克风206可用于收集来自医疗环境208内患者202的音频数据。此外，麦克风206收集的音频数据可以通过通信网络216传输到音频分析环境218。另外地，音频数据可以与音频数据的上下文信息相关联地存储在数据库220中。上下文数据可以包括设备信息、时间信息、医疗设备关联、位置信息、医疗数据和与患者202或医疗环境208相关联的其他信息。音频分析环境218可以配置为从医疗环境208内收集的音频数据中确定来自音频数据的一个或多个音频特性。例如，音频特性可以包括与一个或多个人声话语相关联的人声特性，其中人声特性可以包括音调、音色、节奏、音量和/或语速作为数据点。此外，人声特性可以由声音识别算法222从获得自患者202的音频数据中确定。另外地，患者状态组件226可以配置为从人声特性中确定医疗环境208内患者202的初始健康状态。

在图2的示例性***中，声音识别算法222可以配置为利用数字信号处理和一个或多个音频过滤器来将音频样本分解为音频特性(例如，音调、节奏、能谱、音量等)。例如，声音识别算法222可以将确定自音频样本的音频特性用作与音频样本相关联的患者202的标识符。此外，声音识别算法222可以将来自音频样本的音频特性和/或标识符与健康患者音频特性和不健康患者音频特性的预定义库进行比较。替代地或附加地，声音识别算法222可以将来自音频样本的音频特性和/或标识符和与患者202相关联的历史患者音频样本集进行比较。与健康和/或生病患者相关联的音频特性的预定义库可以包括收集自健康/生病患者的大量患者音频样本。类似地，历史患者音频样本集可以包括获得自患者202的大量历史音频样本和历史音频特性。另外地，声音识别算法222可以利用预定义库和/或历史患者音频特性集比较和/或匹配音频样本的音频特性与预定义库中的患者音频样本和/或历史患者音频特性集和历史音频数据集。预定义库和/或历史患者音频特性集可以存储在数据库220中。据此，历史患者音频数据集和预定义库可用于标识收集自患者202且与患者202的声音相关联的音频数据内的模式和特征、与患者202的声音相关联的音频特性以及与患者202的声音相关联的其他音频信息。

在至少一个示例性***中，声音识别算法222可以配置为接收来自患者202的音频数据，并确定音频数据是否包括一个或多个人声话语。例如，声音识别算法222可以配置为分析音频数据，并标识与人类语音相关联的音频模式，其中音频模式可以包括患者202产生的人声特性(例如，音调、音色、节奏、音量和/或语速)中的音素和/或模式化变体。此外，声音识别算法222可以配置为利用神经网络算法和机器学习算法来标识音频数据内的音频模式，并将其与数据库220内的患者202相关联。据此，声音识别算法222可以配置为解析麦克风206记录的音频数据，并确定患者202是否正在讲话。另外地，当确定患者202正在讲话，声音识别算法222可以配置为标识患者202的人声话语中的各个音素，其中音素代表人类语音的各个分量，这些分量可以组合成词语和与人类语音和交流相关联的其他人声话语。替代地或附加地，声音识别算法222可以配置为识别音频数据内所标识的患者202的人声特性中的模式化变体。

例如，声音识别算法222可以利用机器学习算法、神经网络、人工智能(AI)和/或其他技术来识别与由麦克风206从患者202捕获的音频数据中的声音样本和/或声音模式相关联的模式。例如，声音识别算法222可以配置为从音频数据的音频特性中确定人声特性。此外，可以基于预定义库和/或历史患者音频特性集合来训练声音识别算法222以标识和/或识别音频数据内的人声模式/人声特性。当标识和/或接收到诸如来自音频特征算法224的音频特性(例如，仅接收标识为与患者202的声音相关联的音频数据)，声音识别算法222可以确定音频数据的音频特性是否与预定义库和/或历史患者音频特性集合所存储的音频样本相匹配。替代地或附加地，声音识别算法222可以配置为通过分析与音频数据相关联的声谱图来标识和/或识别与音频数据相关联的音频特性。另外地，声音识别算法222可以配置为基于音频数据的音频样本与预定义库和/或历史患者音频特性集合相匹配，记录与患者202生成的人类语音相关联的人声特性(例如，音调、音色、人声清晰度、语音节奏等)。

在至少一个附加示例性***中，音频特征算法224可以配置为接收来自患者202的音频数据，并确定音频数据是否包括音频事件和/或呼吸样本。例如，音频特征算法224可以配置为分析音频数据并标识与呼吸模式相关联的音频模式和与患者202相关联的音频事件。具体地，音频特征算法可以配置为标识哀叹、哀鸣、急剧吸气/呼气、喘气和窒息事件等音频事件。音频事件可以被标识并记录在数据库中，标记出患者健康状态的潜在指标。附加地或替代地，音频特征算法224可以配置为标识与患者202的呼吸相关联的呼吸模式和音频特性。另外地，患者202的呼吸的音频特性可以包括患者202的音调、音色、节奏、音量和/或呼吸频率。类似地，音频特征算法224可以配置为标识与医疗环境208内患者202的初始健康状态相关联的一种或多种呼吸模式。

例如，音频特征算法224可以分析由麦克风206或与***200相关联的其他设备捕获的音频数据。可以基本连续地和/或被动地(例如，独立于启动信号连续收集音频数据，***200通电时连续收集音频数据等)从环境和/或患者202捕捉音频数据。应当注意，还可以周期性、非周期性、响应于指示和/或基于要从患者202收集音频数据的其他指示收集音频数据。麦克风206可以将音频数据提供给音频特征算法224，包括分贝数据、能量数据、声谱图和/或其他音频数据表示。音频特征算法224可以执行多阶段分析(例如，预处理、分析、后处理等)。音频特征算法224的初始阶段(例如，预处理)可以包括：接收来自麦克风206的音频数据；以及量化、采样并过滤音频数据以从分贝数据、能量数据、声谱图和/或其他音频数据表示中去噪。此外，音频特征算法的初始阶段可以利用与***200相关联的一个或多个附加麦克风。另外地，来自麦克风206和附加麦克风的音频数据可以合并和归一化以进一步提升音频特征算法224分析的音频数据的质量。

在音频特征算法224的某些实例中，音频特征算法224可以利用信号处理技术和自然语言处理来将部分音频数据分类为“词语”音频特性(例如，人类语音)和“非词语”音频特性(例如，哀叹、哀鸣等)。例如，自然语言处理可以优先处理与人类声音产生的最常见词语和声响相关联的常见音素和音频数据模式的标识。标识出的高优先级音频模式可用于标识与词语音频特性相关联的“词语”音频数据。类似于上述声音识别算法222，音频特征算法224(或声音识别算法222)可以利用存储的常见音素和音频数据模式的音频样本来训练自然语言处理算法，以标识高优先级音频模式，从而标识从词语音频数据中提取出的词语音频数据和词语音频特性。据此，音频特征算法224可以将具有相对较高优先级/常见音频模式的音频数据分类为具有词语音频特性的词语音频数据。

在音频特征算法224的某些实例中，可以进一步分析非词语音频特性以检测呼吸模式和疼痛噪声的事例。例如，可以基于标识出非词语音频数据内的周期性和/或定期性音频特性，从非词语音频特性中标识出呼吸模式。此外，可以分析标识出的呼吸模式以获得呼吸参数，诸如吸气和呼气的峰值位，呼吸期间噪声幅度，吸气和呼气的时长以及可用于标识呼吸***紊乱和/或疾病的其他呼吸特性。另外地，监测呼吸频率和检测自呼吸模式的其他指标可以提供呼吸疾病和/或状况的附加指标。经比较，可以基于非词语音频数据中的非周期性、独立和/或孤立音频特性来标识非词语音频特性中的疼痛噪声事例(例如，哀叹、哀鸣、喘气、呼噜等)。在音频特征算法224的最终阶段，可以存储各个词语音频特性、非词语音频特性、呼吸模式、疼痛噪声事例和其他检测到的音频特征，以供***中进一步分析和使用(例如，声音识别算法222可以利用词语音频特性)。

在音频特征算法224的某些附加实例中，非词语音频特性和/或词语音频特性可用于创建滤声器以从音频数据中去除和/或减少各种音频特征的音频信号。例如，音频数据波形可以包括确定为与患者202的呼吸模式相关联的周期性音频特征。此外，音频数据可以包括音频噪声和/或不应包含在音频数据中的无关音频特征。据此，对音频数据的初步分析可以揭示与感兴趣的音频数据(例如，呼吸模式)无关或最低限度相关的音频频率。另外地，可以基于初步分析来创建滤声器以去除与感兴趣的音频数据无关或最低限度相关的音频频率。例如，通过初步分析可以确定呼吸模式主要与频率范围150-1000Hz内的音频特征相关联。据此，可以生成滤声器以去除150-1000Hz范围之外的音频特征，并减少音频特征算法224正分析的音频数据内的噪声量和/或无关音频数据量。

在音频特征算法224的另外某些实例中，音频特征算法224可以配置为标识音频特征的标准音频配置文件中的变体。例如，可以基于与高频率高幅度音频数据相关联的初始阶段(例如，爆发阶段)、高频率低幅度音频数据的中间阶段以及中频率中幅度的发声阶段来标识咳嗽。此外，音频特征(例如，咳嗽)可以与音长相关联。然而，基于与患者相关联的一个或多个症状、状况和/或疾病，可以改变与患者202相关联的三个咳嗽阶段。三个阶段中幅度、频率和音长的增加或减少可以与呼吸状况/疾病的症状相关联。这样改变患者202的音频数据可以指示呼吸道狭窄、梗阻、呼吸道扩张、肺部受创、肺活量受限、充液肺和其他呼吸疾病和/或状况的症状。

在至少一个另外的示例性***中，患者状态组件226可以配置为检索来自医疗设备204和/或麦克风206的音频数据以确定患者202的初始患者状态。具体地，患者状态组件226可以配置为至少基于存储在数据库220中的上下文数据来确定患者202的初始健康状态。例如，患者状态组件226可以至少基于医师提供的健康评估、患者202提供的指示或与其他患者相关联的健康信息来确定患者202的初始健康状态。替代地或附加地，患者状态组件可以确定患者健康状态范围，其中患者健康状态范围可以包括最佳健康状态(例如，患者未患有呼吸病或经受与呼吸状况相关联的阴性症状时的健康状态)、目标健康状态(例如，患者正因呼吸病和/或呼吸状况而经受最轻负面影响时的健康状况)、初始健康状态(例如，指示呼吸病和/或呼吸状况治疗之前的呼吸状况的健康状态)、阈值健康状态(例如，指示可引发采取进一步动作的呼吸状况的健康状态)和/或代表报告和/或标记为将来有待解决的患者状况的其他健康状态。初始健康状态可以在医疗设备204为医疗环境208内患者202提供治疗之前确定，并可以与麦克风206记录的一个或多个人声话语、呼吸模式和/或音频事件相关联。类似地，附加健康状态可以在医疗设备204为医疗环境208内患者202提供治疗之后确定，并可以与麦克风206记录的一个或多个附加人声话语、附加呼吸模式和/或附加音频事件相关联。另外地，健康状态可以由患者状态组件基于医师、患者202、医疗设备204或与患者监测***相关联的其他***提供给音频分析***的指示来建立。

在图2的示例性***200中，***200中与辅助设备210、个人设备212和/或其他设备相关联的一个或多个麦克风可以配置为收集来自非医疗环境214(例如，住所、工作场所、公共场所、远程医疗等)中患者202的音频数据。例如，***200可以配置为监测非医疗环境214中患者202的健康状态。具体地，一个或多个麦克风与辅助设备210和/或个人设备212中的至少一个相关联。应当注意，麦克风可以包括与参照图1描述那些相似的组件。此外，辅助设备210和/或个人设备212可以相互配合地和/或相互独立地操作为收集来自非医疗环境214内患者202的音频数据，并将音频数据传输到音频分析环境218。另外地，音频数据可以与音频数据的上下文信息相关联地存储在数据库220中。来自非医疗环境214的上下文数据可以包括设备信息、时间信息、位置数据和与患者202或非医疗环境214相关联的其他信息。音频分析环境218可以配置为从非医疗环境214内收集的音频数据中确定音频数据中的一个或多个音频特性。例如，音频分析环境218可以配置为从患者202产生的音频数据中确定一个或多个人声话语、呼吸模式、音频事件和/或其他话语。应当注意，音频数据的音频特性可以类似于上文针对医疗环境208中捕获的音频数据论述的相似方式来确定。

在图2的示例性***中，通信网络216可以配置为使能对医疗环境208和非医疗环境214内患者的持续监测。此外，音频分析环境218可以配置为以基本连续性方式监测患者202，这独立于患者202在医疗环境208和非医疗环境214之间移动以及进入或离开与***200相关联的各个设备的范围。另外地，音频分析环境218可以配置为确定来自医疗设备204、辅助设备210、个人设备212和/或附加设备的传入音频数据是否与任何存储在数据库200中的记录健康状态相匹配。例如，数据库220可以包括一个或多个健康状态阈值、记录患者健康状态和/或音频特性与患者202健康状态之间的关联性。此外，当确定音频分析环境218接收到的音频数据满足一个或多个健康状态阈值和/或与一个或多个记录健康状态相匹配，音频分析环境218可以配置为传输音频数据满足健康状态阈值和/或与记录健康状态相匹配的指示。

在某些实例中，音频分析环境218可以通过通信网络216接收来自医疗设备204、麦克风206、辅助设备210、个人设备212和/或与***200相关联的其他设备的音频数据。此外，音频分析环境218可以对音频数据和存储在数据库220中的患者健康状态数据(例如，患者健康状态阈值、记录患者健康状态、患者健康状态数据等)进行比较分析和匹配分析。例如，数据库220可以填充有初始健康状态、目标健康状态、最佳健康状态和/或与患者相关联且以上述相似方式确定自音频数据的其他健康状态。应当注意，尽管上述是关于收集自医疗环境208内患者的音频数据，但音频分析环境可以至少部分地基于收集自非医疗环境214中的音频数据来确定患者健康状态。此外，通过接收自与***200相关联的设备的当前音频数据和与患者健康状态相关联的先前音频数据的比较和匹配分析，患者状态组件226可以确定患者202的当前健康状态。

在某些附加实例中，音频分析环境218可以至少部分地基于接收自与***200相关联的一个或多个设备的当前音频数据来确定患者202的当前健康状态。如上所述，患者状态组件226可以配置为从当前音频数据中标识患者202的当前健康状态，并确定是否要将通知传输给患者202和/或医师。例如，患者状态组件226可以将当前音频的音频特性和与存储在数据库220中的患者健康状态数据相关联的先前音频数据的音频特性进行比较。此外，患者状态组件226可以确定当前音频特性基本与数据库220存储的先前音频特性相匹配。另外地或替代地，患者状态组件226可以确定当前音频特性满足与数据库220存储的患者健康数据相关联的一个或多个音频特性阈值。应当注意，患者状态组件226可以配置为利用机器学习算法和/或神经网络技术来形成与各种呼吸病和/或呼吸状况相关联的音频特性值类别。此外，患者状态组件226可以从先前音频特性中确定与呼吸病和/或呼吸状况的症状相关联的音频特性值范围和阈值。据此，患者状态组件226可以配置为至少基于当前音频特性确定患者202的当前健康状态和/或指示患者202正经受的一种或多种呼吸病和/或呼吸状况。

在图2的示例性***中，通信接口可以配置为通过参照图1所述的通信网络116为医疗设备204、辅助设备210、个人设备212、音频分析设备218和与***200相关联的其他设备提供数据连接和网络通信。例如，通信网络216可以使能各种设备连接到外部数据库(例如，数据库118)以使用无线连接来接收、访问和/或发送音频数据。无线连接可以包括蜂窝网络连接和使用802.11a、b、g和/或ac等协议建立的连接。在其他实例中，使用蓝牙、WiFiDirect、射频识别(RFID)、红外信号和/或Zigbee等一个或多个有线或无线协议，可以直接实现音频分析环境218与外部显示器之间的无线连接。也可能有其他配置。到外部数据库118或外部***的数据通信可以使能打印患者202的音频数据和/或健康状态的报告，或进一步对其进行评估。例如，收集的数据和分析结果可以无线传输并存储到授权医疗专家可访问的远程数据库中。

图3示出了本公开示例性数据处理工作流程。图3虽未示出，但在某些实例中，该工作流程可以由示例性***100和/或示例性***200执行。在图3的某些附加实例中，当示例性***接收到传入音频数据302时，可以启动该工作流程。此外，当接收到传入音频数据302，可以调用、激活或以其他方式启动分类算法304以分析传入音频数据302并标识传入音频数据302的相关部分。例如，分类算法可以配置和/或训练为区分人声话语306、呼吸数据308和/或包含在传入音频数据集302中的其他音频数据。当解析传入音频数据集302并将相关部分分类为人声话语306、呼吸数据308和其他音频数据类型，示例性***可以激活附加算法以进一步分析数据。例如，声音识别算法310和/或音频事件识别算法312可以配置为接收人声话语数据306并标识可用于标识和/或监测患者健康状态的人声特性316和/或音频事件数据318。类似地，可以执行呼吸模式分析314以标识可用于标识和/或监测患者健康状态的呼吸特性320。

在图3的某些实例中，传入音频数据302可以是收集自患者和/或患者所在环境的未处理和/或原始音频数据。传入音频数据302可以包括患者语音、患者呼吸和与患者相关联的其他音频事件。然而，传入音频还可以包括其他个体的讲话和呼吸、环境声(例如，环境内移动的对象、其他个体走动、电子音频源等)和与患者健康状态无关的其他音频数据。

在图3的某些实例中，分类算法304可用于标识传入音频数据302中的人声话语306和呼吸数据308。例如，分类算法304可以配置为利用机器学习技术和神经网络来解析传入音频数据302以标识相关的人声话语和呼吸数据。具体地，与示例性***相关联的数据库可以包括充分包括患者讲话时产生的全部音素的多个记录。附加地或替代地，数据库可以包括充分代表患者说话期间的音质的附加多个记录。另外地或替代地，数据库可以包括与多个个体相关联的人声记录，其中人声记录可用于标识传入音频数据302内的讲话音频数据。据此，分类算法304可以包括已经训练为识别音素、与患者相关联的音质和/或传入音频数据302内的人类语音的机器学习算法和/或神经网络。

在某些附加实例中，与上述类似地，数据库可以进一步包括代表患者和/或其他个体的呼吸模式的数据。数据库中的呼吸模式可以包括患者和/或其他个体的被动呼吸、患者和/或其他个体说话时的呼吸模式以及其他呼吸模式。据此，分类算法可以包括已经训练为标识传入音频数据302所记录的吸气和呼气的机器学习算法和/或神经网络。

在图3的某些实例中，分类算法304可用于处理传入音频数据302。例如，分类算法304可以配置为利用数字信号处理工具，诸如快速傅立叶变换(FFT)滤波器、音频信号滤波器、频谱分析工具和其他信号处理工具。例如，传入音频数据302可以传递通过FFT滤波器，其配置为将传入音频数据302分解为与音调幅度和/或音调音量相关联的幅频组件。此外，音频特征的节奏可以由所产生的声响的模式代表。例如，通过从音频数据的波形中提取密集/波峰和稀疏/波谷并比较/分析音频数据的密集/波峰和稀疏/波谷，可以确定音频特征的节奏。另外地，分类算法304可以提取与音频样本相关联的密集和稀疏的平均时长，以分类音频样本。在附加实例中，可以基于与相对于音频波形的其他频率极高的幅度相关联的音频波形的一个或多个特定频率，确定音频样本的音色。经FFT分析时，音频数据分解为频率和幅度分量可用来确定与音频数据相关联的音色。在另外实例中，分类算法可以利用线性预测编码(LPC)、感知线性预测(PLP)、梅尔频率倒谱系数(MFCC)和其他技术等技术来提取记录音频样本中的音频特征。例如，MFCC可以基于患者声道的形状确定并可以基于MFCC代表的声道形状所产生的声音用作患者的标识符。此外，MFCC可以基于音频数据分解为重叠帧来确定，并可以将一系列FFT和滤波器应用于音频数据以提取/标识音频数据和患者的MFCC。据此，LPC、PLP和MFCC可用作分类与患者相关联的音频样本的指标。另外地，LPC、PLP和MFCC中的变体还可以分类为一个或多个症状/呼吸状况或与一个或多个症状/呼吸状况相关联。音频数据可以包括音频能量、音频频谱、音频幅度、音频强度和/或MFCC(和/或其他指标)，其可用于标识特征以供分类算法304提取和分类。据此，上述标识出的各种指标可以被跟踪并用于标识一段音频数据是否将被分类为人声话语数据306或呼吸数据308。

在图3的某些实例中，在分类算法304的分类之后，人声话语数据306可以进一步由声音识别算法310来分析。例如，声音识别算法310可以配置为标识人声话语306内患者的人声/人声特性316。类似于分类算法，声音识别算法310可以访问包含与患者相关联的多个语音样本的数据库。此外，声音识别算法310可以利用基于多个患者语音样本训练过的机器学习算法和神经网络来标识与患者相关联的部分人声话语。另外地，声音识别算法可以配置为标识可包括与患者相关联的音调、音色、节奏、音量和语速的人声特性316。应当注意，机器学习算法和神经网络可以训练为还标识人声特性316与存储患者人声特性之间的偏差，和/或标识与标识出的人声特性316相匹配的存储患者人声特性。

在图3的某些实例中，在分类算法304的分类之后，人声话语数据306可以进一步由音频事件识别算法312来分析。例如，音频事件识别算法312可以配置为标识人声话语306内与患者相关联的音频事件318。类似于分类算法，音频事件识别算法312可以访问包含与患者相关联的多个过去音频事件的数据库。如上所述，音频事件可以包括哀叹、哀鸣、喘息、呻吟、咳嗽和不与语音相关联但指示患者呼吸道状态的其他话语。此外，音频事件识别算法312可以利用基于多个过去音频事件样本训练过的机器学习算法和神经网络来标识部分人声话语，这些正是患者产生的音频事件。据此，音频事件识别算法312可以标识人声话语306中的音频事件318。

在图3的某些实例中，分类算法标识出的呼吸数据308可以进一步由呼吸模式分析算法314来分析。例如，呼吸数据308可以包括说话、休息和活动期间患者反复的吸气和呼气。此外，呼吸模式分析算法314可以配置为跟踪时长、速率、力度和与呼吸数据308相关联的其他呼吸特性320。另外地，呼吸模式分析算法314可以配置为标识指示患者健康状态的呼吸模式。例如，与上述类似地，呼吸模式分析算法314可以利用机器学习技术和/或神经网络从传入音频数据302中标识呼吸特性320和/或相关呼吸模式。呼吸模式分析算法314可以访问数据库，数据库包括与呼吸病和/或呼吸状况相关联的呼吸模式(例如，因生病等原因经受哮喘发作和咳嗽的个体和/或患者的录音)、指示与患者相关联的先前呼吸特性的录音以及与患者呼吸模式相关联的其他录音。

图4提供了示出监测患者健康状态的示例性方法400的流程图。方法400示为逻辑流程图中的方框集合，方框代表可以在硬件、软件或它们的组合中实现的一系列操作。在软件的情况下，方框代表存储在一个或多个计算机可读存储介质上的计算机可执行指令，这些指令被计算机处理器(CPU)执行时执行所述操作。通常，计算机可执行指令包括执行特定功能或实施特定抽象数据类型的例程、程序、对象、组件、数据结构等。描述操作顺序不旨在理解为作出限制，任何数目的所述方框可以任何顺序和/或并行地组合实施方法400。在某些实施例中，方法400的一个或多个方框可以完全省略。

在方框402，患者监测***的CPU可以从用户设备接收与具有呼吸状况的患者相关联的当前音频数据。如上所述，用户设备可以是医疗设备、个人设备、辅助设备或与患者监测***相关联的其他设备。在某些示例性方法中，与患者监测***相关联的各种设备可以进一步与麦克风相关联，并可以配置为将当前音频数据通过通信网络传输到患者监测***。当前音频数据可以由设备在基本周期性、非周期性或连续性基础上传输到患者监测***。在周期性基础上传输可以包括以基本规则的间隔(例如，自当前音频数据先前传输经过若干秒、分钟、小时、天数等之后)将当前音频数据传输到患者监测***。在非周期性基础上传输可以包括当满足一个或多个音频数据阈值时、当请求信息传输时或当不会在基本定期性基础上发生的情况下，传输当前音频数据。连续性基础上传输可以包括在用户设备捕捉/记录当前音频数据的基本相同时间传输当前音频数据。

在方框402，在某些附加实例中，可以在针对患者呼吸状况的治疗期间收集或在与患者相关联的非医疗环境中收集当前音频数据。例如，当患者接受医师的治疗、建议和/或会诊时，可以由与医疗设备相关联的麦克风捕捉当前音频数据。替代地或附加地，当患者在家中、公共场合和/或以其他方式完成日常活动时(例如，交谈、进餐、睡觉等)，可以由与患者的个人设备相关联的麦克风捕捉当前音频数据。

在方框404，患者监测***的CPU可以解析当前音频数据以标识与患者相关联的人声话语和/或呼吸序列。如参照图3所述，患者监测***可以利用各种算法(例如，语音识别、机器学习、神经网络等)标识当前音频数据内感兴趣的部分。应当注意，解析当前音频数据以标识人声话语和呼吸序列可以包括：CPU执行配置为从当前音频数据的背景音频中区分当前音频数据内由患者产生的人声话语和呼吸序列的分类算法。此外，从当前音频数据中标识感兴趣的部分(例如，人声话语、呼吸序列和/或由患者生成的其他声响)可以包括：患者监测***调用训练为识别当前音频数据中过量音频数据(例如，其他个体讲话和呼吸)和环境噪声(例如，对象移动、设备输出音频内容、机械噪声等)内由患者产生的口语和其他噪声。另外地，患者监测***CPU可以在标识患者的人声话语和呼吸序列的同时执行参照图1至图3描述的各种算法和方法中的操作。

在方框404的某些实施例中，这些算法可以利用机器学习技术来标识部分音频数据作为当前患者健康状态的指标。具体地，可以基于从数据库存储的多个音频样本中所提取的音频数据特征集来训练机器学习算法。基于当前音频特征和与过去患者音频数据和过去患者健康状态相关联的音频特征集之间的比较，音频数据特征集可用于确定患者健康状态。例如，机器学习算法可以从匹配与患者的过去音频数据和过去健康状态相关联的一个或多个音频特征的当前音频样本中确定患者的当前健康状态。此外，音频数据特征集可以包括发声段的音调、音频数据幅度、音频能量和与过去音频数据相关联的其他音频特性。替代地或附加地，特征集可以与MFCC相关联，MFCC与过去音频数据的音频数据特征集生成期间的声带道形状相关联。据此，基于当前音频特征与音频特征集中的一个或多个音频特征相匹配，机器学习算法可以确定患者的当前健康状态。例如，机器学习算法可以比较当前音频数据的音频特性/MFCC和与音频特征集相关联的过去音频特性/过去MFCC。另外地，机器学习算法可以返回一个或多个过去音频特征和与一个或多个过去音频特征相关联的过去健康状态。基于一个或多个过去音频特征与当前音频特征之间的最接近匹配，机器学习算法可以配置为从过去健康状态中标识当前健康状态。类似地，来自过去音频样本的归一化音频音调、幅度、能量、强度和MFCC可用于训练配置为预测过去音频样本与当前音频样本之间最接近匹配的分类器。

在方框406，患者监测***的CPU可以至少基于与患者相关联的先前人声话语和先前呼吸序列来从人声话语和/或呼吸序列中确定一个或多个音频事件。在某些实例中，人声话语可以包括一个或多个音频事件，包括与患者相关联的对话、请求短语、可听疼痛事件和/或惊叫。替代地或附加地，呼吸序列可以包括一个或多个附加音频事件，包括与患者相关联的吸气、呼气、咳嗽、喷嚏和/或呼吸困难。另外地，一个或多个音频事件可以包括患者产生的附加可听声响，包括喘气、喘息、哀鸣、哭泣和与患者的呼吸困难、疼痛和呼吸状况/生病相关联的其他声响。

在方框408，患者监测***的CPU可以确定与一个或多个音频事件相关联的一个或多个音频特性。如上参照图1至图3所述，一个或多个音频特性可以包括人声话语的音调、人声话语的音色、人声话语的节奏、人声话语的音量、与人声话语相关联的语速、与呼吸序列相关联的吸气时长、与呼吸序列相关联的呼气时长和/或与呼吸序列相关联的呼吸频率。此外，在某些实例中，音频特性可以包括与讲话和呼吸困难、讲话和呼吸痛苦、讲话和呼吸吃力相关联的附加音频特性和/或与患者健康状态相关联的其他人类可听/人类不可听音频特性。另外地，各种音频特性可以由配置为将人类语音/声响分解为组成分量、部分和/或变量的声音识别算法来标识。基于分析声谱图(例如，记录音频数据的可视表示)和/或与当前音频数据相关联的其他电子数据格式，可以确定包括人类语音的各个方面。

在方框410，患者监测***的CPU可以至少基于一个或多个音频特性来确定与一个或多个音频事件相关联的过去音频事件类别。此外，过去音频事件类别可以包括与呼吸状况和多个患者健康状态相关联的过去音频录音集。在某些实例中，过去音频事件类别可以包括与人声话语类型和/或呼吸序列类型相关联的多个记录音频事件。应当注意，人声话语类型和/或呼吸序列类型可以至少表征为选自上述各种音频特性的音频特性集。例如，过去音频事件类别可以与惊叫相关联，惊叫和与包括惊叫类别的人声话语相关联的各种音频特性集相关联。此外，可以至少基于至少包括该音频特性集的一个或多个音频特性来确定一个或多个音频事件类别。例如，当与一个或多个音频事件相关联的一个或多个音频特性匹配与惊叫类别相关联的音频特性集，该一个或多个音频事件可以确定为包括一个或多个惊叫。另外地，一个或多个音频事件的具体音频事件可以因其与音频特性集相关联而标记为惊叫。

在方框412，至少基于一个或多个音频事件与过去音频事件类别的比较，患者监测***的CPU可以确定患者与呼吸状况相关联的当前健康状态。在某些实例中，确定患者的当前健康状态可以进一步包括：确定与患者的呼吸状况相关联的一个或多个记录健康状态，以及确定与患者的呼吸状况相关联的当前健康状态。如上所述，过去音频事件类别可以包括与人声话语类型和/或呼吸序列类型相关联的多个记录音频事件。可以先前分析多个记录音频事件以标识与多个记录音频事件的音频特性相关联的一个或多个记录健康状态。据此，基于与当前音频数据的一个或多个音频事件相关联的当前呼吸症状，患者监测***的CPU可以利用各种呼吸症状与一个或多个记录健康状态之间的关联性来确定患者的当前健康状态。

在方框412，在某些实例中，患者监测***的CPU可以配置为确定与音频数据的一个或多个音频事件相关联的一个或多个音频特性与患者的呼吸症状之间的对应关系。例如，与过去音频事件类别相关联的记录健康状态可以包括与多个记录音频事件相关联的一种或多种呼吸症状，该一种或多种呼吸症状至少包括以下至少一项：患者呼吸道炎症、吸气困难、呼气困难、患者呼吸道中粘液过多、慢性咳嗽、患者产生的一个或多个改变的音频特性、咳血、气促和胸闷/胸痛。据此，通过标识过去音频事件类别的呼吸症状与可应用于一个或多个音频特性的一个或多个过去音频特性之间的对应关系，患者监测***的CPU可以确定一个或多个音频事件的目前症状。替代地或附加地，一个或多个记录健康状态可以包括与医疗呼吸状况之前记录的初始音频特性和初始患者症状相关联的初始健康状态；与有效治疗呼吸状况或患者与呼吸状况不相关联时记录的目标音频特性和目标患者病症相关联的目标健康状态；以及与阈值音频特性相关联的阈值健康状态，其中，所述***至少基于一个或多个音频特性满足阈值音频特性来将指示传输给患者或医师。

图5提供了示出如本文所述监测患者健康状态的示例性方法500的流程图。方法500示为逻辑流程图中的方框集合，方框代表可以在硬件、软件或它们的组合中实现的一系列操作。在软件的情况下，方框代表存储在一个或多个计算机可读存储介质上的计算机可执行指令，这些指令被CPU执行时执行所述操作。通常，计算机可执行指令包括执行特定功能或实施特定抽象数据类型的例程、程序、对象、组件、数据结构等。描述操作顺序不旨在理解为作出限制，任何数目的所述方框可以任何顺序和/或并行地组合实施方法500。在某些实施例中，方法500的一个或多个方框可以完全省略。

在方框502，患者监测***的CPU可以激活患者监护仪或激活患者监测过程，其中患者监护仪可以是与用户设备(例如，医疗设备、个人设备、辅助设备等)相关联并配置为收集与患者的呼吸功能相关联的当前音频数据的麦克风。患者的呼吸功能可以与患者呼吸、讲话或以其他方式利用患者呼吸道的能力相关联。如上所述，至少部分地取决于患者因呼吸状况(例如，呼吸病、呼吸疾病、呼吸问题等)而经受的呼吸症状严重程度，呼吸状况可能削弱患者的呼吸功能。在某些实例中，患者监测***可以配置为收集并存储来自多个患者的音频数据。

在方框504，患者监测***的CPU可以促使麦克风记录来自患者人声话语和患者呼吸序列的当前音频数据。如上所述，患者的呼吸功能可以受到患者因呼吸状况而经受的呼吸症状严重程度所影响。据此，促使麦克风监测并记录患者讲话(例如，对话、自言自语、响应于提示等)、呼吸或以其他方式生成人类可听或不可听的声响会产生来自患者人声话语和呼吸序列的当前音频数据。

在方框506，患者监测***的CPU可以标识与患者人声话语相关联的当前人声特性和与患者呼吸序列相关联的当前呼吸特性。在某些实例中，可以由CPU以上述方式执行对当前人声特性和当前呼吸特性的标识。在某些附加实例中，当前人声特性和当前呼吸特性的标识可以从一个或多个音频声谱图中确定。例如，CPU可以从与患者讲话相关联的一个或多个音频声谱图中确定与患者相关联的音调、音色、节奏、音量和语速。此外，CPU可以从与患者呼吸序列相关联的一个或多个附加声谱图中确定呼吸频率和平均呼吸音量。另外地，CPU可以从一个或多个另外声谱图中标识一个或多个疼痛事件，其中一个或多个疼痛事件与一个或多个哀鸣、一个或多个哀叹或一个或多个呼噜相关联。

在方框508，患者监测***的CPU可以分析与患者相关联的多个先前人声特性和呼吸序列和先前音频数据以训练机器学习算法。例如，多个先前人声特性和呼吸序列可以包括先前患者人声特性、先前患者呼吸序列、与一个或多个附加患者相关联的人声特性和与一个或多个附加患者相关联的呼吸序列。先前人声特性和呼吸序列可以包括声频图或其他音频数据录音，其反映患者或一个或多个附加患者经受一组呼吸症状时讲话和呼吸的能力。据此，每组人声特性和呼吸序列可以与患者健康状态和一组呼吸症状相关联。另外地，该组人声特性和呼吸序列可以进一步与上下文或人口统计信息相关联，以更准确地匹配患者正经受的症状和与多个先前人声特性和呼吸序列相关联的患者经受的一组呼吸症状。

在方框508，在某些实例中，分析多个先前声特性和呼吸序列以训练机器学习算法可以包括：根据先前评估音频录音或先前诊断音频录音来训练机器学习算法。例如，患者监测***的CPU可以接收一个或多个诊断音频录音，其中该一个或多个诊断音频录音中的一个诊断音频录音与呼吸状况、记录健康状态和先前人声特性集相关联。此外，CPU可以将记录健康状态和一个或多个诊断音频录音中的一个诊断音频录音的先前人声特性集提供给机器学习算法。另外地，CPU可以调用机器学习算法，以至少基于一个或多个诊断音频录音中的每个个体诊断音频录音的记录健康状态和先前人声特性集，使多个先前人声特性和呼吸序列相互关联。通常，一个或多个诊断音频录音可以包括记录自患者和/或一个或多个附加患者的人声话语和/或呼吸序列的录音，其中一个或多个附加患者可以共有呼吸症状、人口统计信息、上下文信息和/或与患者的其他关联。一个或多个诊断音频录音可以先前被评估、分级和/或诊断，并与一种或多种呼吸状况、一种或多种呼吸症状、呼吸状况/症状的严重程度和与诊断音频录音的来源(例如，患者和/或一个或多个附加患者)的记录健康状态相关联的其他信息相关联。据此，机器学习算法可以接收一个或多个诊断音频录音的数字信息并生成诊断音频录音的音频特性与诊断音频录音的来源的症状之间的对应关系。

在方框510，患者监测***的CPU可以利用机器学习算法来确定与患者相关联的当前健康状态。例如，患者的当前健康状态可以从当前人声特性与多个先前人声特性的比较中确定。在某些实例中，确定与患者相关联的当前健康状态可以基于与一个或多个诊断音频录音相关联的一个或多个健康状态，利用训练过的机器学习算法来确定当前健康状态。例如，CPU可以比较患者的当前人声特性与多个先前人声特性和呼吸序列。此外，CPU可以标识与确定为基本匹配当前人声特性的先前人声特性集相关联的诊断音频录音。基于分析与诊断音频录音和当前音频数据相关联的相应声谱图，该先前人声特性集可以确定为基本匹配当前人声特性。替代地或附加地，CPU可以利用记录患者健康状态/症状与一个或多个诊断音频录音之间的对应关系来确定与当前音频数据所指示的症状相关联的严重程度。换而言之，一个或多个诊断音频录音可以指示与不同严重程度相关联的各组呼吸症状引起的数据源(例如，患者或一个或多个附加患者)人声特性的一系列变化。据此，CPU可以至少基于记录健康状态(例如，记录呼吸症状严重程度)来确定患者的当前健康状态。

图6示出了如本文所述的示例性患者监测***。该患者监测***可以利用通过通信网络616与服务器618通信的用户设备602。具体地，用户设备602可以包括计算机处理单元(CPU)604、存储器606、通信接口608、功率管理组件610、显示器612和用户界面614。此外，服务器618可以包括CPU 620、存储器622、通信接口624、数据库626、机器学习组件628和神经网络组件630。

在图6的某些实例中，CPU 604和CPU 620可以配置为执行或部分执行参照图1至图5所述的方法。附加地或替代地，CPU 604可以操作为控制与用户设备相关联的麦克风以捕捉与患者有关的音频数据。CPU 604可以与CPU 320进行通信，CPU 620可以通过通信接口608和通信接口624与CPU 640进行通信以接收待执行例程和/或算法的指示，并在执行例程和/或算法期间传输捕获的音频数据。

在图6所示的实例中，用户设备602的CPU 604可以包括一个或多个控制器、处理器和/或其他硬件和/或软件组件，其配置为操作性控制与用户设备602相关联的麦克风、通信接口608、功率管理组件610、显示器612、用户界面614和用户设备602的其他组件。例如，图6所示的CPU 604可以包括单个处理单元(例如，单处理器)或数个处理单元(例如，多处理器)，并可以包括单计算单元或多计算单元或多处理核。图6所示的CPU 602可以实现为一个或多个微处理器、微计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或任何基于操作指令操控信号的设备。例如，图6所示的CPU 602可以是任何合适类型的一个或多个硬件处理器和/或逻辑电路，其具体编程或配置为执行本文所述的算法、操作和方法。图6所示的CPU 602可以配置为提取和执行存储在存储器606中的计算机可读指令，其可以对CPU 602进行编程以执行本文所述的功能。附加地或替代地，图6所示的CPU 602可以配置为提取和执行存储在音频分析***120(图1)的音频筛选组件126中的计算机可读指令。

在某些方面，图6所示的存储器606可以与上文关于音频分析***120(图1)所述的音频筛选组件126相似。例如，存储器606可以包括易失性和非易失性存储器和/或可移动和不可移动介质，其在任何类型的技术中实现以存储计算机可读指令、数据结构、程序模块或其他数据等信息。这种存储器606可以包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、光存储、固态存储、磁带、磁盘存储、RAID存储***、存储阵列、附网存储、存储区域网、云存储或可用来存储期望信息并可由计算设备访问的任何其他介质。存储器606可以是一种计算机可读存储介质和/或可以是有形非暂态介质，提及时，非暂态计算机可读介质不包括能量、载波信号、电磁波和信号本身等介质。

存储器606可用于存储任何数目的可执行功能组件以及由CPU 604处理和/或通过通信接口608传输的音频数据。在许多实施方式中，这些功能组件包括CPU 602可执行的指令或程序，它们被执行时使一个或多个CPU 602具体配置为执行本文所述与监测患者当前健康状态相关联的动作。

存储在存储器606中的其他功能组件可以尤其包括图形表示数据组件、测量数据组件、阈值数据组件、通知组件、麦克风数据组件、机器学习组件、神经网络组件和/或与患者监测***的操作相关联的其他功能组件。

在某些实例中，图6所示的通信接口608可以配置为将信息通过通信网络616传输到通信接口624。例如，通信接口608和通信信息624可以使能用户设备602和服务器618使用有线或无线连接来交换音频数据指示、患者健康状态、待收集音频数据指示和/或其他信息。无线连接可以包括蜂窝网络连接和使用802.11a、b、g和/或ac等协议建立的连接。在其他实例中，使用蓝牙、WiFi Direct、射频识别(RFID)、红外信号和/或Zigbee等一个或多个有线或无线协议，可以实现音频用户设备与服务器之间的无线连接。也可能有其他配置。类似地，通信网络616通常是任何类型的无线网络或本领域已知的其他通信网络。网络616的实例包括互联网、内联网、广域网(WAN)、局域网(LAN)、虚拟专用网(VPN)、蜂窝网络连接和使用诸如802.11a、b、g、n和/或ac等协议建立的连接。

在本文所述的任何实例中，图6所示的CPU 602可以配置为从与用户设备602、显示器612、用户界面614和/或用户设备602的其他组件相关联的麦克风接收各种信息、信号和/或其他输入。在某些实例中，用户界面614可以接收来自用户、患者和/或医师的这些输入，一个或多个这些输入可以包括用于使患者监测***生成、显示、提供和/或以其他方式输出一个或多个患者健康状态、音频数据、患者症状报告和/或监测患者期间所生成的其他输出的命令或请求。在某些附加实例中，显示器612可以例如包括液晶显示器(LCD)、发光二极管(LED)显示器、有机发光二极管(OLED)显示器或有源矩阵有机发光显示器(AMOLED)。此外，显示器612可以是配置为接收针对用户界面614的触摸输入的交互式显示器。替代地或附加地，用户界面614可以通过键盘、鼠标或其他输入设备接收用户输入。

在图6所示的实例中，服务器618的CPU 620可以包括一个或多个控制器、处理器和/或其他硬件和/或软件组件，其配置为操作性控制与服务器618相关联的麦克风、通信接口624、数据库626、机器学习组件628、神经网络组件和服务器618的其他组件。例如，如图6所示的CPU 620可以与CPU 602基本相似。此外，存储器622可以包括与用户设备602的存储器606相似的计算机可执行指令。另外地，数据库626可以采取如上参照图1至图5所述的配置。

在图6所示的实例中，机器学习组件628可以采取如上参照图1到图5所述的配置。通常，机器学习组件628代表一系列指令，用于促使服务器处理训练数据集以基于记录患者症状的记录音频特性建立传入音频数据的音频特性和与各种呼吸状况相关联的先前记录患者症状之间的对应关系。训练数据集越大，基于先前记录患者症状和记录音频特性对患者当前健康状态的确定一般会更准确。据此，机器学习组件可以提供能够基于先前针对患者和/或共有相似归类信息的其他患者所分析和表征的音频数据来监测来自患者的传入音频数据并跟踪当前健康状态的算法。在某些附加实例中，机器学习组件628可以包括利用神经网络来归类来自患者的传入音频数据并基于传入音频数据的音频特性来确定患者的当前健康状态的算法。例如，神经网络可以开发自训练数据集，该训练数据集建立与个人呼吸症状、呼吸状况和患者产生的声响的类型相关联的音频数据特性的分支类别。

应当注意，虽然上述主要涉及分析与用户讲话、呼吸和/或以其他方式通过患者呼吸道和声带生成话语相关的音频数据，但***还可以分析其他声响。例如，可以由麦克风跟踪患者的脚步以标识可能因疼痛、缺乏呼吸和其他问题引起的步态变化。替代地或附加地，患者产生的人声话语的音频特性能够指示呼吸状况以外的潜在健康问题。另外地，可以通过音频特性跟踪与患者相关联的当前健康状态的其他方面。例如，通过跟踪患者的不同呼吸方式，可以跟踪睡眠习惯模型，并且睡眠期间呼吸模式的重要事件或变化可用于指示患者的当前健康状态。据此，本公开不限于明确披露的方法、***和装置，而是旨在包括在所附权利要求精神内对其所做的变更和修改。

上文仅为本公开原理的说明，本领域技术人员在不背离本公开范围的前提下可以做出各种修改。上述实例的呈现仅出于说明而非限制目的。本公开还可以采取本文明确描述形式以外的许多形式。据此，需要强调，本公开不限于明确披露的方法、***和装置，而是旨在包括在所附权利要求精神内对其所做的变更和修改。

作为另外实例，如本文图示和描述，可以做出装置变体或过程限制(例如，维度、配置、组件、过程步骤顺序等)以进一步优化所提供的结构、设备和方法。无论如何，本文描述的结构和设备以及相关方法应用广泛。因此，本公开主题不应限制于本文描述的任何单个实例，而应根据所附权利要求采取广义范围上的解释。

Claims (20)

1.一种***，包括：存储器；

一个或多个处理器；以及

存储在所述存储器中且能由所述一个或多个处理器执行以执行操作的计算机可执行指令，所述操作包括：

从用户设备接收与患者相关联的当前音频数据；至少基于所述当前音频数据，标识所述患者的人声话语和呼吸序列中的至少一项；

基于所述人声话语和呼吸序列中的至少一项并基于与所述患者相关联的先前人声话语和与所述患者相关联的先前呼吸序列中的至少一项，确定一个或多个音频事件；

确定与所述一个或多个音频事件相关联的一个或多个第一音频特性；

至少基于所述一个或多个第一音频特性，确定与所述一个或多个音频事件相关联的音频事件类别，其中，与一个或多个第二音频特性相关联的音频事件类别指示所述患者的呼吸状况；以及

至少基于所述一个或多个音频事件与所述音频事件类别的比较，确定所述患者与所述呼吸状况相关联的当前健康状态。

2.根据权利要求1所述的***，其中，所述用户设备包括医疗设备，所述当前音频数据通过操作性连接到所述用户设备的麦克风来收集，所述医疗设备配置为在基本周期性、非周期性或连续性基础上将所述当前音频数据传输到所述***。

3.根据权利要求1所述的***，其中，

在与所述呼吸状况相关联的治疗或诊断之后，所述当前音频数据收集自所述患者；以及

跟踪所述患者的当前健康状态以监测从所述呼吸状况康复。

4.根据权利要求1所述的***，其中，至少部分地基于所述人声话语来确定所述一个或多个音频事件，所述一个或多个音频事件包括与所述患者相关联的对话、请求短语、可听疼痛事件和/或惊叫中的至少一项。

5.根据权利要求1所述的***，其中，至少部分地基于所述呼吸序列来确定所述一个或多个音频事件，所述一个或多个音频事件包括与所述患者相关联的吸气、呼气、咳嗽、喷嚏或呼吸困难中的至少一项。

6.根据权利要求1所述的***，其中，标识所述人声话语和所述呼吸序列中的至少一项进一步包括：从所述当前音频数据的背景音频中区分所述当前音频数据内的人声话语和呼吸序列中的至少一项。

7.根据权利要求1所述的***，其中，所述一个或多个第一音频特性包括：

所述人声话语的音调；

所述人声话语的音色；

所述人声话语的节奏；

所述人声话语的音量；

与所述人声话语相关联的语速；

与所述呼吸序列相关联的吸气时长；

与所述呼吸序列相关联的呼气时长；以及

与所述呼吸序列相关联的呼吸频率。

8.根据权利要求1所述的***，其中，

所述音频事件类别包括与人声话语类型或呼吸序列类型相关联的记录音频事件，所述人声话语类型或所述呼吸序列类型至少由所述一个或多个第二音频特性表征；且

至少基于所述一个或多个第一音频特性至少包括所述一个或多个第二音频特性来确定所述音频事件类别。

9.根据权利要求8所述的***，其中，确定所述患者的当前健康状态进一步包括：

至少基于所述记录音频事件，确定与所述患者的呼吸状况相关联的记录健康状态；以及

至少基于所述记录音频事件，确定与所述患者的呼吸状况相关联的当前健康状态。

10.根据权利要求9所述的***，其中，所述记录健康状态包括与所述记录音频事件相关联的一种或多种呼吸症状，所述一种或多种呼吸症状包括以下至少一项：

患者呼吸道炎症；

吸气困难；

呼气困难；

患者呼吸道中粘液过多；

慢性咳嗽；

所述患者产生的一个或多个改变的音频特性；

咳血；气促；以及胸闷。

11.根据权利要求9所述的***，其中，所述记录健康状态包括：

与医疗所述呼吸状况之前记录的初始音频特性和初始患者症状相关联的初始健康状态；

与有效治疗所述呼吸状况或所述患者与所述呼吸状况不相关联时记录的目标音频特性和目标患者症状相关联的目标健康状态；或者

与阈值音频特性相关联的阈值健康状态，其中，所述***至少基于所述一个或多个音频特性满足所述阈值音频特性来将指示传输给所述患者或医师。

12.根据权利要求1所述的***，其中，

所述呼吸状况包括哮喘、慢性阻塞性肺病、支气管炎、肺气肿、肺癌、囊性纤维化、肺炎或胸膜积液中的至少一项；且

所述当前健康状态包括与所述呼吸状况相关联的症状严重程度的指示。

13.一种由处理器执行的方法，所述方法包括：

促使麦克风记录来自患者的当前音频数据，所述当前音频数据包括患者人声话语和患者呼吸序列；

从所述麦克风接收所述当前音频数据；

至少基于先前音频数据，标识与所述患者人声话语相关联的当前人声特性和与所述患者呼吸序列相关联的当前呼吸特性；

使用所述先前音频数据、与所述患者相关联的先前人声特性和与所述患者相关联的先前呼吸序列来训练机器学习算法；以及

基于所述当前人声特性与所述先前人声特性的比较，使用所述机器学习算法来确定所述患者的当前健康状态。

14.根据权利要求13所述的方法，其中，所述先前人声特性和所述先前呼吸序列包括与一个或多个附加患者相关联的人声特性和与所述一个或多个附加患者相关联的呼吸序列。

15.根据权利要求13所述的方法，其中，使用所述先前音频数据、所述先前人声特性和所述先前呼吸序列来训练所述机器学习算法进一步包括：

接收一个或多个诊断音频录音，其中，所述一个或多个诊断音频录音中的一个诊断音频录音与呼吸状况、记录健康状态和所述先前人声特性相关联；

将所述记录健康状态和所述先前人声特性提供给所述机器学习算法；以及

促使所述机器学习算法至少基于所述一个或多个诊断音频录音中的先前人声特性使所述先前音频数据、所述先前人声特性和所述先前呼吸序列与所述记录健康状态相互关联。

16.根据权利要求15所述的方法，其中，确定与所述患者相关联的当前健康状态进一步包括：

比较所述当前人声特性与至少所述先前音频数据、所述先前人声特性和所述先前呼吸序列；

标识所述一个或多个诊断音频录音中与确定为基本匹配所述当前人声特性的先前人声特性相关联的诊断音频录音；以及

至少基于所述记录健康状态，确定所述患者的当前健康状态。

17.根据权利要求13所述的方法，其中，标识所述当前人声特性和所述当前呼吸特性进一步包括：

至少基于所述当前音频数据的音频声谱图，确定与所述患者相关联的音调、音色、节奏、音量和语速；

至少基于所述音频声谱图，确定呼吸频率和平均呼吸音量；以及

至少基于所述音频声谱图，标识一个或多个疼痛事件，其中，所述一个或多个疼痛事件与一个或多个哀鸣、一个或多个哀叹或一个或多个呼噜相关联。

18.一种***，包括：

一个或多个处理器；

存储器；以及

存储在所述存储器中且能由所述一个或多个处理器执行以执行操作的计算机可执行指令，所述操作包括：

促使与用户设备相关联的麦克风收集第一音频录音，其中，所述第一音频录音包括患者讲话或患者呼吸中的至少一项；

从所述用户设备接收所述第一音频录音；

至少基于所述第一音频录音，确定与所述第一音频录音相关联的音频类别，所述音频类别与所述第一音频录音中共有一个或多个音频特性的一个或多个人声话语相关联；至少基于所述音频类别，确定第一患者健康状态，所述第一患者健康状态与所述患者的呼吸症状相关联；

促使与所述用户设备相关联的麦克风收集第二音频录音；

至少基于所述第二音频录音，标识所述一个或多个音频特性与所述第一音频录音和所述第二音频录音相关联；以及

至少基于所述一个或多个音频特性，确定第二患者健康状态，其中，所述第二患者健康状态指示相对于所述第一患者健康状态的健康状态变化。

19.根据权利要求18所述的***，其中，确定与所述第一音频录音相关联的音频类别进一步包括：促使机器学习算法标识与所述第一音频录音相关联的人声话语类型，其中，所述人声话语类型标识与所述人声话语相关联的来源、人口统计或内容中的至少一项。

20.根据权利要求18所述的***，所述操作进一步包括：

至少基于健康状态阈值，确定所述第二患者健康状态满足所述健康状态阈值，所述健康状态阈值与相较于所述第一患者健康状态的呼吸症状加重相关联；以及

将所述第二患者健康状态的指示从所述***传输到所述患者的个人设备。

Images