CN114901150A - 针对自管临床校验、验证以及注册的应用程序 - Google Patents

Abstract

本发明介绍的是一个分布式计算***，旨在有效地连接医疗保健***中涉及的各种利益相关者。在分布式计算***上运行的应用程序可能负责以安全的方式执行活动，以加速各种利益相关者之间的信息积累和共享。这些活动可以由应用程序使用分布式***实现的迭代协议(例如，区块链协议)管理。

Description

针对自管临床校验、验证以及注册的应用程序

技术领域

本发明是有关于被设计为得出可共享的医疗相关见解(healthcare-relatedinsights)的分布应用程序，特别是有关于一种针对自管临床校验、验证以及注册的应用程序。

背景技术

校验、验证以及注册是在开发与部署医疗设备以及用作为医疗设备的软件的重要步骤。术语「作为医疗设备的软件(Software as a Medical Device)」以及「SaMD」是用于医疗目的且在不参与医疗设备的情况下执行这些目的软件。为了方便起见，可以将这样的软件简称为「医疗软件」。

然而，很难收集用于校验、验证以及注册的必要信息。这些困难包括以下问题：获取建立(或确保遵守)良好药品临床试验规范(GCP)标准所需的临床数据以及关键持有人的知情同意，以及储存患者健康信息(也称为「受保护的健康信息」)或「个人健康信息」)。这些是开发与部署医疗设备和医疗软件的重大障碍。

附图说明

图1A为包括电子听诊器***的输入单元的顶部透视图。

图1B至图1C为包括输入单元的底部透视图，其中输入单元包括具有远端部分以及近端部分的结构体。

图2为包括电子听诊器***的输入单元的横截面侧视图。

图3绘示如何将一个或多个输入单元连接到集线器单元(hub unit)以形成电子听诊器***。

图4绘示电子听诊器***的输入单元以及集线器单元的示范性元件的高阶方块图。

图5说明了分布式***与集中式***的不同之处。

图6说明了医疗***中的各利益相关者(stakeholders)。

图7为包括一个应用程序的例子，其中应用程序用以促进在分布式***上运行的共享，且此共享为这些利益相关者之间的信息共享。

图8绘示促进医疗***中的各利益相关者的通信的应用程序的几个示范性特征。

图9A至图9D为包括智能合约的几个例子。

图10为包括应用程序在多个利益相关者之间共享信息的过程的高阶示意图。

图11为包括一个过程的高阶示意图，其中借由此过程，由电子听诊器***所产生的数据可共享于对病患感兴趣的利益相关者。

图12描绘了一个例子的工作流程，其绘示了要如何在医疗***中的各成员之间共享数据。

图13描绘了对病患的健康感兴趣的实体(entity)共享医疗设备设备所产生的数据的过程的流程图。

图14描绘了将关于病患的呼吸异常的信息分配给对病患的健康感兴趣的实体之过程的流程图。

图15描绘了参与检伤分类、诊断或治疗病患的实体共享诊断相关见解(diagnostically relevant insights)的过程的流程图。

图16绘示了由在分布式***上运行的应用程序实现的工作流程的例子。

图17绘示了可实现本文描述的至少一些操作的处理***的例子的方块图。

实施例在附图中以示例而非限制的方式示出。尽管出于说明的目的，附图描绘了多个实施例，但是本领域技术人员将认识到可采用替代的实施例而不偏离本技术的原理。因此，虽然在附图中示出了特定实施例，但本技术可以进行多种修改。

具体实施方式

这里介绍的是一种分布式计算***(或简称为「分布式***」)，旨在有效地连接医疗***中涉及的各利益相关者(stakeholders)。如下面进一步讨论的，在分布式***上运行的应用程序(也称为“平台(Platform)”)可负责以安全的方式执行活动，以加快各利益相关者之间信息的积累与共享。

这些活动可以由应用程序使用分布式***实现的迭代协议(例如，区块链协议)来管理。作为例子，假定应用程序获得包括个人(也称为「病患」)的呼吸音的音频文件。在这种情况下，应用程序可以借由检查音频文件，以获得医疗相关见解(healthcare-relatedinsight)。应用程序可以与诸如医疗机构(例如，医院与诊所)以及保险提供者之类的实体共享医疗相关见解，以促进诊断程序。

为了说明目的，可以在便于开发以及/或部署能够产生包括病患的呼吸音的音频文件的电子听诊器***的背景下描述应用程序。然而，本领域技术人员将认识到，本文描述的技术可以用于促进其他医疗设备以及医疗软件的开发以及/或部署。

可以参照特定医疗设备、计算设备以及网络以对实施例进行描述。然而，本领域技术人员将认识到，这些特征类似地适用于其他医疗设备、计算设备以及网络。例如，当将应用程序为用以获取并检查包含呼吸音的音频文件的应用程序时，应用程序可用以获取并检查数字影像(例如，眼睛、肺等)。因此，可执行高阶方法来改善医疗***中各利益相关者之间的通信，并忽略由应用程序执行的分析之类型。

此外，当在计算机所执行指令的文本中对实施例进行描述时，可经由软件、固件或硬件以实现技术的各个方面。作为例子，可在推理服务器(inference server)上实现应用程序的各个方面，以简化计算机实现之模型(models)(或简称为「模型」)的大规模部属。这样的方法可允许由各固件以及储存媒体(storage medium)(例如，本地内存或基于云端的内存)部署模型(例如，用于发现呼吸音中的呼吸异常)。

术语

以下给出整个发明中所使用的术语、缩写以及片语的简要定义。

术语「连接」、「耦接」或其任何变化旨在包括两个或多个元件之间的任何连接或耦接(无论是直接的还是间接的)。连接或耦接可以是实体(physical)的、逻辑的或其组合。例如，尽管不共享实体连接，但是物件可以彼此电连接或通信连接。

术语「模组(module)」可以用来广泛地指经由软件、固件或硬件实现的组件。通常，模组是基于输入来生成输出的功能元件。一种计算机程序可包括一个或多个模组。因此，计算机程序可包括负责完成不同任务的多个模组或负责完成所有任务的单个模组。

电子听诊器***概述

电子听诊器***可用以，在诊查以及周围环境中同时监控来自活体(或简称为「身体」)内部的声音。一种电子听诊器***可包括连接到集线器单元(hub unit)的一个或多个输入单元。各输入单元可以具有谐振器以及/或膜片，此谐振器以及/或膜片用以，将声波导向至少一个麦克风，此麦克风用以产生指示内部声音的音频数据。这些麦克风可称为「听诊麦克风」。此外，各输入单元可以包括至少一麦克风，此至少一麦克风用以在诊察时产生指示身体外部之声音的音频数据。这些麦克风可以称为「环境麦克风(ambientmicrophones)」或「周围环境麦克风(environmental microphones)」。

为了说明目的，「环境麦克风」可被描述为，可用以产生指示「环境声音」的音频数据。然而，这些「环境声音」通常包括由三种不同来源所产生之声音的组合：(1)来自周围环境内的声音(例如，周围环境噪音)；(2)借由谐振器泄漏的声音；(3)在诊查中穿透身体的声音。环境声音的例子包括，直接源自输入单元的结构体的声音(例如，手指或胸部的抓挠)以及穿透输入单元的结构体的低频周围环境噪音。

图1A为包括电子听诊器***的输入单元100的顶部透视图。为了方便起见，输入单元100可以被称为「听诊器贴片」，然而，如下文进一步描述的，输入单元可以仅包括听诊所必需的元件的子集。输入单元100也可以被称为「胸件(chestpiece)」，因为它通常将被固定到身体的胸部。然而，本领域技术人员将可得知，输入单元100也可以固定到身体的其他部分(例如，腹部或背部)。

如下面进一步描述的，输入单元100可在诊查中收集代表身体内的生物活动的声波，将声波转换成电子信号，以及数字化电子信号(例如，为了更容易传输、为了确保更高的保真度等)。输入单元100可以包括结构体102，此结构体102由诸如不锈钢、铝、钛或另一种合适的金属合金的金属构成。为了制造结构体102，通常将熔融金属压铸，然后机械加工或挤压成合适的形式。

在一些实施例中，输入单元100可包括壳体，此壳体防止结构体102暴露于周围环境。例如，壳体可以防止污染、提高清洁性等。通常，除了沿其底侧设置的锥形谐振器(conical resonator)之外，壳体基本上封装了所有结构体102。下面参照图1B至图C可更深地描述锥形谐振器。壳体可以由硅橡胶、聚丙烯、聚乙烯或任何其他合适的材料组成。此外，在一些实施例中，壳体可含有添加剂，此添加剂的存在限制了微生物的生长、紫外线(UV)的劣化等。

图1B至图1C包括输入单元100的底部透视图，其中输入单元100包括具有远端部分104以及近端部分106的结构体102。为了启动听诊程序，个体(例如，医疗人员(例如，医师或护士))将输入单元100的近端部分106固定在诊查中的身体表面上。输入单元100的近端部分106可包括锥形谐振器110的较宽开口108。锥形谐振器110可被设计为，将借由较宽开口108所收集的声波引导向较窄开口112，这可形成听诊麦克风。一般而言，较宽开口108大约为30～50毫米(mm)、35～45mm或38～40mm。但是，因为这里描述的输入单元100可以具有自动增益控制功能，所以可以使用较小的锥形谐振器。例如，在一些实施例中，较宽开口108小于30mm、20mm或10mm。因此，本文所述的输入单元能够支持针对不同应用等之各种不同尺寸的锥形谐振器。

关于术语「远端」和「近端」，除非另有说明，否则这些术语是指输入单元100相对于身体的相对位置。例如，当提到适合固定于身体的输入单元100时，「远端」可以指第一位置，且此位置靠近于，适合传输数字信号的电缆与输入单元100连接的位置，以及「近端」可以指的是第二位置，且此第二位置靠近输入单元100接触身体的位置。

图2为包括电子听诊器***的输入单元200的横截面侧视图。输入单元200通常包括结构体202，此结构体202具有定义在其中的内部空腔。输入单元200的结构体202可具有锥形谐振器204，此锥形谐振器204被设计为，将声波引导至内部空腔内的麦克风。在一些实施例中，膜片212(也称为「振动膜」)延伸并横跨锥形谐振器204的较宽开口(也称为「外部开口」)。膜片212可用以收听高音调的声音(例如，经常由肺部产生的声音)。膜片212可由包括环氧玻璃纤维化合物或玻璃纤维的薄塑料盘制成。

为了提高由锥形谐振器204收集之声波的清晰度，可将输入单元200设计为同时监控源自不同位置的声音。例如，输入单元200可以被设计为于诊查中同时监控源自体内的声音以及源自周围环境的声音。因此，输入单元200可包括用以产生指示内部声音的音频数据的至少一麦克风206(被称为「听诊麦克风」)以及用以产生指示环境声音的音频数据的至少一麦克风208(被称为「环境麦克风」)。听诊与环境麦克风中的每一者都包括可将声波转换成电子信号的换能器(transducer)。此后，电子信号可以在传输到集线器单元前被数字化。数字化将使集线器单元能够轻松地计时或同步从多个输入单元接收到的信号。数字化还可以确保集线器单元从输入单元接收的信号具有比其他方式更高的保真度。

这些麦克风可设计为，从所有方向提取声音的全向麦克风，也可设计为，提取来自特定方向的声音的定向麦克风。例如，输入单元200可以包括听诊麦克风206，此听诊麦克风206被定向为，提取源自与锥形谐振器204的外部开口相邻的空间的声音。在这样的实施例中，环境麦克风208可以是全向或定向麦克风。作为另一个例子，一组环境麦克风208可在输入单元200的结构体202内等距地分隔开，以形成相位阵列(phased array)，此相位阵列可捕获高度定向的环境声音以减少噪音以及干扰。因此，听诊麦克风206可被设置以聚焦在即将进入的内部声音的路径上(也称为「听诊路径」)，而环境麦克风208可以被设置以聚焦在即将进入的环境声音的路径上(也称为「环境路径」)。

传统上，电子听诊器对指示声波的电子信号进行数字信号处理(digital signalprocessing，DSP)演算法，其中此演算法负责过滤失真(artifact)的信号成分。然而，此动作可以抑制在特定频率范围(例如100～800Hz)内的几乎所有声音，从而极大地使所关注的内部声音(例如，与心跳、吸气或呼气对应的那些声音)失真。然而，于此，处理器可以采用噪音消除演算法(noise cancellation algorithm)，其中此演算法分别检查由听诊麦克风206所产生的音频数据以及由环境麦克风208所产生的音频数据。更具体地，处理器可以解析由环境麦克风208产生的音频数据，以判断(如果有的话)应该如何修改由听诊麦克风206产生的音频数据。例如，处理器可发现某些数字特征应该被放大(例如，因为它们对应于内部声音)、减小(例如，因为它们对应于环境声音)或被完全去除(例如，因为它们代表噪音)。可以使用这种技术来改善输入单元200记录的声音的清晰度、细节以及质量。例如，噪音消除演算法的应用可以是，由包括至少一输入单元200的电子听诊器***所采用的去噪处理的一个组成部分。

为了隐私目的，当锥形谐振器204被引导远离身体时，听诊麦克风206以及环境麦克风208都不会进行记录。因此，在一些实施例中，直到输入单元200附着到身体，听诊麦克风206以及/或环境麦克风208才开始进行记录。在这样的实施例中，输入单元200可包括一个或多个附着感测器210a～210c，其用于确定结构体202是否已经适当地固定到身体的表面。

输入单元200可包括于此示出的附着感测器的任何子集。例如，在一些实施例中，输入单元200可仅包括附着感测器210a～210b，其位于锥形谐振器204的较宽开口附近。作为另一例子，在一些实施例中，输入单元200可仅包括附着感测器210c，其位于锥形谐振器204的较窄开口(也称为「内部开口」)附近。此外，输入单元200可包括不同类型的附着感测器。例如，附着感测器210c可以是光学接近感测器，其被设计成借由锥形谐振器204发射光线(例如，红外光)，并基于反射回到锥形谐振器204中的光线判断输入单元200与身体的表面之间的距离。作为另一例子，附着感测器210a～210c可以是音频感测器，其被设计为借由用以判断高频信号下降的演算法，以基于环境噪音(也称为「周围环境噪声」)的存在来判断结构体202是否被牢固地密封在身体的表面上。作为另一例子，附着感测器210a～210b可以是压力感测器，其被设计为基于施加的压力的量，以判断结构体202是否被牢固地密封在身体的表面上。输入单元200的一些实施例包括这些不同类型的附着感测器中的每一者。借由考虑这些附着感测器210a～210c的输出以及上述主动噪音消除演算法，处理器可动态地确定附着状态。即，处理器可以基于这些附着感测器210a～210c的输出判断输入单元200是否已经相对于身体形成密封。

图3绘示如何将一个或多个输入单元302a～302n连接到集线器单元304以形成电子听诊器***300。在一些实施例中，多个输入单元连接到集线器单元304。例如，电子听诊器***300可包括四个输入单元、六个输入单元或八个输入单元。通常，电子听诊器***300可包括至少六个输入单元。具有多个输入单元的电子听诊器***可以称为「多通道听诊器」。在其他实施例中，可仅有一个输入单元连接到集线器单元304。例如，可以模拟多个输入单元的阵列的方式在身体上移动单个输入单元。具有一个输入单元的电子听诊器***可以称为「单通道听诊器」。

如图3所示，每个输入单元302a～302n可以经由相应的电缆306a～306n连接到集线器单元304。通常，经由相应的电缆306a～306n在每个输入单元302a～302n与集线器单元304之间形成的传输路径可被设计为基本无干扰。例如，可在输入到集线器单元304之前借由输入单元302a～302n将电子信号数字化，并且可以借由禁止电磁噪音的产生/污染来确保信号的保真度。电缆的例子包括带状电缆、同轴电缆、通用序列总线(universal serialbus，USB)电缆、高解析多媒体接口(high definition multimedia interface，HDMI)电缆、RJ45以太网络电缆以及任何其他适合传输数字信号的电缆。每条电缆可包括(例如，经由实体端口)连接至集线器单元304的第一端以及(例如，经由实体端口)连接至对应的输入单元的第二端。因此，每个输入单元302a～302n可包括单个实体端口，并且集线器单元304可包括多个实体端口。或者，可以使用一条电缆将所有输入单元302a～302n连接到集线器单元304。在这样的实施例中，电缆可以包括能够与集线器单元304接触的第一端以及一组第二端，其中每个第二端可与单个输入单元接触。基于第二端的数量，这种电缆例如可被称为「一对二电缆」、「一对四电缆」或「一对六电缆」。

当连接到集线器单元304的所有输入单元302a～302n处于听诊模式时，电子听诊器***300可采用用以将内部声音与环境声音进行比较的自适应增益控制演算法(adaptive gain control algorithm)。自适应增益控制演算法可分析目标听诊声音(例如，正常呼吸、喘息、爆裂声等)，以判断是否已经达到足够的声音位准。例如，自适应增益控制演算法可判断声音位准是否超过预定阈值。可将自适应增益控制演算法设计为实现高达100倍的增益控制(例如，在两个不同的阶层)。可以基于输入单元阵列308中的输入单元的数量以及每个输入单元中的听诊麦克风所记录的声音的位准，自适应地调节增益位准。在一些实施例中，自适应增益控制演算法可被程序化为，部署反馈回路的一部分。因此，自适应增益控制演算法可将增益应用于输入单元所记录的音频，判断音频是否超过预程序化的强度阈值，以及基于此判断动态地判断是否需要附加增益。

由于电子听诊器***300可在后处理程序中部署自适应增益控制演算法，故可允许输入单元阵列308收集有关由心脏、肺等所产生的多种声音的信息。由于输入单元阵列308中的输入单元302a～302n可沿着身体表面(或在完全不同的身体上)放置于不同的解剖位置，故电子听诊器***300可同时监视不同的生物特征(例如呼吸频率、心率或喘息、爆裂声的程度等)。

图4绘示电子听诊器***的输入单元400以及集线器单元450的示范性元件的高阶方块图。输入单元400以及集线器单元450的实施例可包括图4所示的元件的任何子集以及这里未示出的附加元件。例如，输入单元400可以包括生物感测器，其中此生物感测器可监控身体的生物特征，例如，出汗(例如，基于皮肤湿度)、温度等。附加地或可替代地，生物特征感测器可被设计为监控图式(breathing pattern/respiratory pattern)，其可记录心脏的电子信号的活动等。作为另一例子，输入单元400可包括惯性测量单元(inertialmeasurement unit，IMU)，其中此惯性测量单元可产生由手势、方位或位置推导出的数据。IMU是设计用于测量物体的力、角速度、倾角/倾斜度以及/或磁场的电子元件。通常，IMU可包括加速度计、陀螺仪、磁力计或其任意组合。

输入单元400可包括一个或多个处理器404、无线收发器406、一个或多个麦克风408、一个或多个附着感测器410、内存412以及/或电耦接到功率接口(power interface)416的功率元件(power component)414。这些元件可位于壳体402(也称为「结构体」)内。

如上所述，麦克风408可以将声波转换为电子信号。麦克风408可包括用以产生指示内部声音的音频数据的听诊麦克风、用以产生指示环境声音的音频数据的环境麦克风、或其任何组合。代表电子信号的值的音频数据可至少临时地储存在内存412中。在一些实施例中，处理器404可在向下传到集线器单元450之前处理音频数据。例如，处理器404可应用用以进行数字信号处理、去噪、增益控制、噪音消除、失真移除(artifact removal)、特征识别等的演算法。在其他实施例中，在向下传到集线器单元450之前，可由处理器404执行最少处理(minimal processing)。例如，处理器404可简单地将元数据(metadata)附加到指定输入单元400的识别的音频信息，或者测试已由麦克风408添加到音频数据的元数据。

在一些实施例中，输入单元400以及集线器单元450经由连接在对应的数据接口418、470之间的电缆传输数据。例如，由麦克风408产生的音频数据可被传送到输入单元400的数据接口418，以传送到集线器单元450的数据接口470。替代地，数据接口470可以是无线收发器456的一部分。无线收发器406可用以自动地与集线器单元450的无线收发器456建立无线连接。无线收发器406、456可以经由例如近场通信(Near Field Communication，NFC)、USB、蓝牙、Wi-Fi、蜂窝数据协议(例如，LTE、3G，4G或5G)之类的双向通信协议或专有的点对点(point-to-point)协议彼此通信。

输入单元400可包括功率元件414，其中此功率元件414可根据需要向位于壳体402内的其他元件提供功率。类似地，集线器单元450可包括可向位于壳体452内的其他元件提供功率的功率元件466。功率元件的例子包括可充电锂离子(Li-Ion)电池、可充电镍氢(NiMH)电池、可充电镍镉(NiCad)电池等。在一些实施例中，输入单元400可不包括专用功率元件，因此，其必须从集线器单元450接收电力。在输入单元400的功率接口416以及集线器单元450的功率接口468之间可连接以设计成便于进行电源传输(例如，借由电接头(electrical contacts)的实体连接)的电缆。

仅出于说明的目的，将功率通道(即，功率接口416与功率接口468之间的通道)以及数据通道(即，数据接口418与数据接口470之间的通道)表示为单独的通道。本领域技术人员将认识到，这些通道可以被包括在同一电缆中。因此，可在输入单元400与集线器单元450之间耦接能够承载数据以及电力的单根电缆。

集线器单元450可包括一个或多个处理器454、无线收发器456、显示器458、编解码器(codec)460、一个或多个发光二极体(light-emitting diode，LED)指示器462、内存464以及功率元件466。这些元件可位于壳体452(也称为「结构体」)内。如上所述，集线器单元450的实施例可包括这些元件的任何子集以及这里未示出的附加元件。例如，集线器单元450的一些实施例可包括显示器458，其中显示器458可用以呈现信息，例如，在诊察中的个体的呼吸状态或心、网络连接状态、电源连接状态、输入单元400的连接状态等。可以借由触觉输入机制(例如，沿着壳体452的表面设置的可接触的按钮)、音频输入机制(例如，语音命令)等来控制显示器458。作为另一例子，集线器单元450的一些实施例可包括用以执行指示的LED指示器462而不是显示器458。在这样的实施例中，LED指示器462可以传达与显示器458类似的信息。作为另一例子，集线器单元450的一些实施例可同时包括显示器458以及LED指示器462。

当接收到指示由输入单元400的麦克风408所产生的电子信号的音频数据时，集线器单元450可将音频数据提供给负责解码输入数据的编解码器460。编解码器460例如可解码音频数据(例如，借由反转(reversing)由输入单元400执行的编码)，以准备编辑、处理等。编解码器460可以被设计为，依序或同时处理由输入单元400中的听诊麦克风所产生的音频数据以及由输入单元400中的环境麦克风所产生的音频数据。

此后，处理器454可处理音频数据。与输入单元400的处理器404非常相似，集线器单元450的处理器454可应用用以进行数字信号处理、去噪、增益控制、噪音消除、失真移除、特征识别等的演算法。如果输入单元400的一个或多个处理器404已应用了这些演算法，则这些演算法中的某些算法可能不是必需的。例如，在一些实施例中，集线器单元450的处理器454应用演算法来发现音频数据中的诊断相关特征，而在其他实施例中，如果输入单元400的处理器404已发现了诊断相关特征，则这种动作可能是不必要的。可替换地，集线器单元450可以将音频数据传送到目的地(例如，在分布式***上运行的诊断服务)以进行分析(如下文进一步讨论的)。通常，诊断相关特征可对应于与预设图式定义参数(predetermined pattern-defining parameter)匹配的音频数据中的值的图式。作为另一例子，在一些实施例中，集线器单元450的处理器454应用演算法以减少音频数据中的噪音从而改善讯噪比(signal to noise ratio，SNR)，而在其他实施例中，这些演算法由输入单元400的处理器404应用。

除了功率接口468之外，集线器单元450还可以包括功率端口。功率端口(也称为「功率插孔」)可使集线器单元450实体连接到电源(例如，电源插座)。功率端口可与不同的连接器类型(例如C13，C15，C19)连接。另外地或可替代地，集线器单元450可包括具有集成电路(「晶片(chip)」)的功率接收器，其中集成电路能够从外部电源无线地接收电力。功率接收器可用以接收根据由无线电力联盟开发的Qi标准或一些其他无线电力标准发送的功率。

在一些实施例中，集线器单元450的壳体452包括音频端口。音频端口(也称为「音频插孔」)可用以将信号(例如，音频)传送到附件(例如，耳机)的适当插头的插孔。音频端口通常包括两个、三个或四个接头(contact)，且当将适当的插头***音频端口时，这些接头可使音频信号易于传输。例如，大多数耳机都包括设计用于3.5毫米(mm)音频端口的插头。附加地或替代地，集线器单元450的无线收发器456可将音频信号直接传送到无线耳机(例如，经由NFC、蓝牙等)。

如上所述，输入单元400的处理器404以及/或集线器单元450的处理器454可以应用各种演算法以支持不同的功能。此类功能的例子包括音频数据中丢失的数据封包的传输衰减、与噪音相关的音量控制、动态范围压缩、自动增益控制、等化、噪音抑制以及回声消除。

每个功能可对应于驻留在内存(例如，输入单元400的内存412或集线器单元450的内存464)中的单独模组。因此，输入单元400以及/或集线器单元450可包括传输衰减模组、音量控制模组、压缩模组、增益控制模组、等化模组、噪音抑制模组、回声消除模组或其任何组合。

关于电子听诊器***的其他信息可以在美国专利号10，555，717中找到，其中此专利可借由引用整体以并入本文。

应用程序概述

校验、验证以及注册是开发与部署医疗设备以及医疗软件的重要步骤。然而，很难收集校验、验证以及注册所需的信息。现在，尤其如此，因为许多实体已经开始开发用以与给定医疗设备一同使用的医疗软件。作为例子，图1A至图4所讨论的电子听诊器***可由诊断服务支持，其中诊断服务可提供，对的分析音频数据，其中音频数据可由电子听诊器***产生。

此处介绍一种分布式计算***(或简称为「分布式***」)，用以有效地连接医疗***所涉及的各利益相关者。在分布式***上运行的应用程序可负责加速各利益相关者之间的数据积累以及共享，以便于向个体(也称为「病患」)提供服务。

图5说明了分布式***与集中式***的不同之处。术语「集中式」和「分布式」是指对***的控制级别。在集中式***中，控制是由单个实体执行的。在分布式***中，不是执行单个控制实体的控制，而是执行在几个实体之间共享的控制。例如，本文描述的分布式***可由医疗保健***中的各利益相关者控制。这些利益相关者可包括病患以及医疗人员(healthcare professionals)(统称为应用程序的「使用者」)、医疗设备与医疗软件的制造商(manufacturers of medical devices and medical software)、处理实体(processingentities)、管理人员与医疗机构(regulatory professionals and medical facilities)(统称为「管理员」)以及付款人(payers)(例如，保险公司以及政府实体(例如，医疗保险以及医疗补助服务中心))(如图6所示)。

图7为包括一个应用程序700的例子，其中应用程序700用以促进在分布式***上运行的共享，且此共享为这些利益相关者之间的信息共享。应用程序700(也称为「分布式程序」或「分布式平台」)可包括在分布式点对点网络上运行的代码(code)。在一些实施例中，借由向校验应用程序700的那些利益相关者提供符记(token)来触发应用程序。

如图7所示，应用程序700可包括可以驻留在分布式***中的不同节点上的一组客户端。例如，设备客户端(device client)702可驻留在与使用者(例如，病患或医疗人员)相关的医疗设备上，且管理客户端(administration client)704可驻留在由管理人员(例如，管理人员或医疗机构(例如，医院、诊所或实验室))管理的计算设备上。给付客户端(reimbursement client)706可驻留在由付款人(例如，政府实体、基金会或保险公司)管理的计算设备上。同时，管理总账(administrative ledger)708可以驻留在由处理实体管理的计算设备上。设备客户端702、管理客户端704、给付客户端706以及管理总账708共同支持由应用程序700提供的诊断服务。

图8绘示促进医疗***中的各利益相关者的通信的应用程序800的几个示范性特征。应用程序800的一个关键方面是，其从利益相关者获取输入并将适当的输出传达给其他利益相关者的能力。为此，应用程序800可以利用智能合约。术语「智能合约」是用以根据协议项目(terms of an agreement)自动执行、控制或记录相关事件的计算机程序。在较高的层级上，智能合约是具有指令的自动化(即，自我执行的)合约，其中此指令可为用底层代码编写的指令，且仅在满足某些条件时才执行。借由使用智能合约，上述利益相关者可以可信的、无冲突的方式交换数据，而无需依赖第三方。在一些实施例中，应用程序所实现或实施的智能合约可被储存在区块链上。如此，那些智能合约需要像常规交易一样进行验证，如下文进一步讨论。

请注意，智能合约也可以用于医疗设备以及医疗软件的校验、验证和注册。这种智能合约的几个例子在图9A图至图9D中示出。如图9A所示，基于作为输入所提供的数据，智能合约可指示，根据非临床校验与验证协议(non-clinical validation and verificationprotocol)或临床校验与验证协议(clinical validation and verification protocol)应该执行哪些步骤(如果有的话)。可替代地，智能合约可指示如何对真实世界证明中的数据进行提取、处理或传达。如下进一步讨论的，智能合约的项目的执行可由共识协议(consensus protocol)来控制，并由证书发行与校验服务(certificate issuing andvalidating service)来监督。

图9B描绘了针对注册医疗设备(在此为电子听诊器***)的智能合约的例子，其中医疗设备是根据非临床校验以及验证协议进行注册的。如在图9B中所示，当由应用程序执行时，智能合约可基于与医疗设备相关的信息判断是否允许注册。对于电子听诊器***，此信息可包括动态范围、频率响应以及放大振幅，也可包括固件版本以及应用程序(DApp)版本。此信息可借由医疗设备的非临床测试判断以及/或导出。智能合约可要求此信息符合预定的阈值或范围。如果智能合约指示适当的注册，则可使用由应用程序提供的数字证书(digital certificate)以正式建立通道。应用程序所提供的数字证书可指定或指示非临床校验以及验证已完成。

图9C描绘了针对注册医疗设备(在此为电子听诊器***)的智能合约的例子，其中医疗设备是根据非临床校验以及验证协议进行注册的。如在图9C中所示，当由应用程序执行时，智能合约可基于指标准确度(accuracy of metrics)判断是否允许注册，其中指标准确度是由医疗设备所产生或取决于医疗设备所产生的数据。在电子听诊器***的案例中，智能合约可要求以足够的准确度计算呼吸频率。因此，智能合约可要求演算法被设计为产生指示呼吸频率的输出，其中呼吸频率可应用于现实世界证明(例如，医疗设备所产生的数据)以及校验集。可借由应用程序化接口(application programming interface，API)或巨量数据接口提供此数据。应用程序可提供数字证书，其中此数字证书指定或指示临床校验以及验证已完成。

图9D描绘了针对注册医疗设备(在此为电子听诊器***)的智能合约的例子，其中医疗设备是根据非临床校验以及验证协议进行注册的。如在图9D所示，当由应用程序执行时，智能合约可基于医疗设备是否符合认证协议判断是否允许注册。随着时间的流逝，可提取医疗设备所产生的数据，并对其进行检测，以判断此数据是否指示符合认证协议。响应于判断医疗设备不符合认证协议，医疗设备可被禁止以防止进一步使用。例如，应用程序可阻止医疗设备的进一步使用(例如，借由向设备客户端发送停止操作的指令)，或者是，应用程序可借由阻止进一步的数据上载以及/或分析限制通信直到医疗设备符合认证协议。

请注意，这些智能合约可以应用程序进行一系列的执行。因此，可在成功完成图9C中的智能合约之后，执行图9D中的智能合约，并且可在成功完成图9B中的智能合约之后，执行图9C中的智能合约。因此，图9B、9C以及9D中的智能合约可以被实现为，用以注册诸如电子听诊器***之医疗设备的序列式的步骤。在成功完成先前的智能合约之前，可能不会「强制执行(enforce)」这些智能合约中的每一者。因此，在图9B至图9C所示的智能合约已经成功完成之前，图9D所示的智能合约可能不会被「强制执行」。

应用程序800的另一方面是，其按照各种利益相关者所同意的共识协议(或简称为「协议」)进行操作的能力。如上所述，应用程序800可以分布在各节点(例如，计算设备)上，其中这些节点的任务是验证以及/或记录交易。因为任何利益相关者都可以提交要记录的信息，所以重要的是，要有适当的规则来指定应记录哪些信息和应丢弃哪些信息。这些规则被称为「协议」，应用程序800借由此协议进行操作。在较高层级中，协议定义了验证应用程序800记录的交易是否真实的方法。可在应用程序800提供诊断服务之前完整定义协议，或者可在应用程序800提供诊断服务时更改协议。因此，可在应用程序800「活跃」时调整协议。

在一些实施例中，应用程序800可用以实施证书发行与校验服务，以对各种利益相关者进行校验。作为例子，应用程序800可支持以及/或利用分布式公钥基础架构(publickey infrastructure PKI)，其中区块链可用作键-值存储(key-value storage)。如本文所使用的，术语「区块链」是指包含信息的分布式数字总账，其中此信息可在上述分布式***中同时被使用与共享。分布式PKI消除了对校验机构进行之密钥管理的依赖，取而代之的是，其依靠分布式***来维护数字证书(例如，授权存取给定的利益相关者的数据)。

可根据基于证明决策协议(evidence-based decision protocol)由应用程序800做出决策。为了做出基于证明决策，应用程序800可考虑各种形式的证明，并在给定的情况下评估证明的适当性。例如，假定应用程序800获得音频数据，其中音频数据包括建议进行诊断的病患的呼吸音。在此情况下，除了从分析音频数据得出的任何见解之外，应用程序800还可考虑关于病患的个人健康信息。音频数据以及个人健康信息可从相同来源(例如，设备客户端)或不同来源(例如，设备客户端以及管理客户端)获得。

如上所述，交易可以由应用程序800记录在分布式数字总账上。分布式数字总账可代表应用程序800的骨干，因为它代表了分布在多个节点(例如，与不同利益相关者相关的计算设备)上的信息的共识。

图10为包括应用程序1000在多个利益相关者之间共享信息的过程的高阶示意图。在此，多个利益相关者包括病患1002、医疗人员1004、医疗机构1006以及付款人1008。这些利益相关者参与医疗***的各种不同方面。例如，医疗人员1004可负责对病患1002进行检伤分类、监控或诊断，而医疗机构1006可负责记录关于病患1002的信息。同时，付款人1008可负责对医疗人员1004以及/或医疗机构1006所提供的服务进行补偿。

如图10所示，设备客户端1010可驻留在医疗人员1104用来治疗以及/或诊断病患1002的医疗设备1012上。医疗设备的一个例子是上面图1A至图4讨论的电子听诊器***。设备客户端1010可将医疗设备1012产生的数据提供给应用程序1000。在一些实施例中，数据被实时地且连续地(即，当数据被生成时)传输到应用程序1000。在其他实施例中，数据被周期性地传送到应用程序1000。例如，设备客户端1010可用以根据预定时间表(例如，每15分钟、30分钟等)传送数据，或者是，设备客户端1010可用以在接收到指示发送数据的指令之后(例如，在由医疗人员1004进行的诊断疗程结束之后)发送数据。

然后，应用程序1000可借由使用智能合约判断是否允许存取医疗机构1006的数据。如果应用程序1000判断医疗机构1006被授权存取数据，则可以将数据传输到驻留在医疗机构1006上且可存取计算设备1016的管理客户端1014。计算设备1016可例如是个人计算机或计算机服务器。在借由管理客户端1014接收到数据之后，医疗机构1006可将数据储存在与病患1002相关的电子医疗记录中。电子医疗记录还可包括从其他来源获得的数据(例如，由医疗人员1004直接输入)。

类似地，应用程序1000可借由使用智能合约以判断是否允许向付款人1008存取数据。如果应用程序1000判断付款人1008被授权存取数据，则可以将数据传输到付款人1008可存取的计算设备1020上的给付客户端1018。计算设备1016可例如是个人计算机或计算机服务器。在借由给付客户端1018接收到数据之后，付款人1008可检测此数据以判断给付是否合适。

尽管在共享由医疗设备1012产生的数据的背景下描述了图10所示的实施例，然而，本领域技术人员将认识到，若除了数据之外还可共享了数据的分析，或者是仅共享了数据的分析(直接代替数据)，则此过程也类似地适用。作为例子，假设设备客户端1010如上述将医疗设备1012所产生的数据传送到应用程序1000。然而，应用程序1000可将数据的分析传输到管理客户端1014，而不是将数据直接传输到管理客户端1014。例如，如果医疗设备1012可以是用以产生包括病患1002的呼吸声的音频数据的电子听诊器***，则应用程序1000(并且更具体地，由应用程序实现的诊断服务)可检测音频数据，以判断呼吸异常，并将有关那些呼吸异常的信息提供给管理客户端1014。类似地，应用程序1000可将与数据有关的信息提供给给付客户端1018。例如，应用程序1000可向给付客户端1018提供与医疗人员1004所执行的活动相关的信息，而不是医疗设备1012所产生的数据。

在一些实施例中，参与该过程的利益相关者可借由应用程序1000所实施的证书发行与校验服务来验证。如图10所示，证书发行与校验服务可使利益相关者能够与应用程序1000相互交换数字证书(或简称为「证书」)，以建立信任关系。如本文中所使用的，术语「证书」是指用以提供加密密钥的所有权的电子文档。在较高层级上，证书代表数字证书，其中此证书将所有者(例如，利益相关者)的身份绑定到可用于加密数据的一对加密密钥(一个公钥和一个私钥)。证书可包括有关加密密钥的信息以及有关其所有者的信息，因此，可以在分布式***中作为建立真实性的手段。

图11为包括一个过程的高阶示意图，其中借由此过程，由电子听诊器***1112所产生的数据可共享于对病患1102感兴趣的利益相关者。最初，医疗人员1104可使用电子听诊器***1112以尝试诊断病患1102。在诊断疗程的过程中，电子听诊器***1112可以产生音频数据，其中此音频数据包括病患1102在一定时间间隔内产生的呼吸音。例如，医疗人员1104可使用电子听诊器***1112以记录呼吸音(持续10～60秒、10～30秒或10～15秒)。通常，医疗人员1104会试图记录至少三个完整的呼吸周期(即，吸气然后呼气)。驻留在电子听诊器***1112上的设备客户端1110可负责将音频数据传输到应用程序1100，以进行进一步的分析。

如上所述，应用程序1100可用以在接收到音频数据时执行诊断服务。例如，应用程序1100可将模型应用于音频数据，其中此模型被设计与训练为用以计算呼吸频率、识别呼吸异常或推荐适当治疗。此模型的这些输出可以被称为音频数据的「分析」。

之后，应用程序1100可以判断是否允许存取利益相关者(例如医疗机构1106或付款人1108)。通常，这是借由使用智能合约(如上所述)完成的。如果应用程序1100判断对给定的利益相关者授权存取，则可以共享分析以及/或音频数据。例如，在图11中，对两个利益相关者(即，医疗机构1106以及付款人1108)授权存取。可以在与每个利益相关者对应的智能合约中指定适合共享的信息。例如，授权存取医疗机构1106的智能合约可指定将音频数据的分析，提供给驻留在计算设备1116上的管理客户端1114，其中医疗机构1106可存取计算设备1116。作为另一个例子，授权存取付款人1108的智能合约可以指定将与医疗人员1104所执行的活动相关的信息，提供给驻留在计算设备1120上的给付客户端1118，其中付款人1108可存取计算设备1120。这样的信息可以指定用以诊断的医疗设备的类型、病患1102的姓名、医疗人员1104的姓名、进行诊断的医疗机构1106的名称等。

在图10至图11中，应用程序以通信方式连接到单个设备客户端、管理客户端以及给付客户端。但是，本领域技术人员将认识到，应用程序可包括多个设备客户端、管理客户端以及给付客户端。图12描绘了一个例子的工作流程，其绘示了要如何在医疗***中的各成员之间共享数据。有一些成员(例如，医疗人员、医疗机构以及付款人)可能会密切参与向病患提供护理的工作，而其他成员(例如，管理人员)可能会更专注于，确保以适当的方式提供护理(例如，使用经过适当校验的医疗设备)。

使用应用程序促进数据共享的方法

图13描绘了对病患的健康感兴趣的实体共享医疗设备所产生的数据之过程1300的流程图。如上所述，此过程1300可由在分布式***上运行的应用程序来实现。

首先，应用程序可接收指示认证音频数据之请求的第一输入，其中音频数据包括病患的呼吸音(步骤1301)。可以各种方式接收第一输入。例如，第一输入可从驻留在医疗设备上的客户端(例如，设备客户端)获得。作为另一个例子，可借由应用程序产生以及/或支持的接口提供第一输入。例如，假设应用程序可产生可借由计算机程序(例如移动应用程序，桌面应用程序或Web浏览器)存取的接口。在这种情况下，个体可借由将音频文件经由接口上传到应用程序，以寻求认证。个体可以是病患或其他人(例如，医疗人员或家庭成员)。

接着，应用程序可验证音频数据，藉以授权对音频数据的共享或对音频数据的分析给对病患健康感兴趣的实体(或对音频数据的分析)(步骤1302)。例如，应用程序可获取与负责产生音频数据的医疗设备相关的信息，并检测此信息以确保医疗设备满足一个或多个规范。此类规范的例子包括动态范围、频率响应、放大振幅、固件版本以及DApp版本。在判断医疗设备满足规范时，应用程序可产生音频文件的分析。如上所述，此分析可以包括关于呼吸频率、呼吸异常等的信息。作为另一例子，应用程序可检测音频数据以确保音频数据满足一个或多个规范。这种规范的例子包括最小持续时间、最小呼吸周期数、最小讯噪比(SNR)等。当判断音频数据满足规范时，应用程序可产生音频文件的分析。

接着，应用程序可从实体接收指示存取音频数据的分析之请求的第二输入(步骤1303)。此第二输入可由驻留在与医疗设备分开的计算设备上的客户端接收。客户端可以是与医疗机构或管理人员相关的管理客户端，也可以是与政府组织或保险公司相关的给付客户端。然后，应用程序可响应于判断实体满足智能合约所包括的项目(terms)，执行智能合约，其中此智能合约允许实体存取音频数据的分析。作为例子，智能合约可要求实体持有有效数字证书，其中有效数字证书可以是储存在分布式***中的，或者是在分布式***中可存取的，且在分布式***中可运行应用程序。

图14描绘了将关于病患的呼吸异常的信息分配给对病患的健康感兴趣的实体之过程1400的流程图。首先，应用程序可产生可在第一计算设备上存取的接口(步骤1401)。接着，应用程序可接收指示认证音频文件之请求的输入，其中音频文件是经由第一计算设备上的接口上传(步骤1402)。音频文件可以包括由患者在一定时间间隔内产生并由电子听诊器***记录的呼吸声。同时，第一计算设备可以是移动电话、平板计算机、个人计算机或移动计算机工作站(workstation)(也称为「车载移动计算机(mobile computer cart)」)。通常，计算设备的类型取决于存取接口的个体。例如，若病患自己上传音频文件，则她更可能借由移动电话或平板计算机上传音频文件。然而，若医疗人员上载了音频文件，则她更可能借由个人计算机或移动计算机机工作站来上载音频文件。

接着，应用程序可检测音频文件以识别呼吸异常，其中呼吸异常借由分析呼吸音发现(步骤1403)。例如，应用程序可将算演法应用于音频文件，其中此演算法借由训练可以识别比方说喘息、爆裂声、喘鸣以及鼾音。接着，应用程序可将有关呼吸异常的信息发送至客户端，其中客户端在与实体相关的第二计算设备上执行(步骤1404)。此实体可以是负责产生音频文件的医疗设备的制造商、负责治疗患病的医疗机构或为个人治疗付费的保险公司。虽第一计算设备以及第二计算设备都可以代表运行应用程序的分布式***中的节点，然而，第一以及第二计算设备不必是相同类型的计算设备。例如，此音频文件可借由接口上载，且此分析可转发给在计算机服务器上执行的客户端，其中此接口可由网络浏览器或移动电话或个人计算机存取。

图15描绘了参与检伤分类、诊断或治疗病患的实体共享诊断相关见解(diagnostically relevant insights)的过程1500的流程图。最初，应用程序可获取数据，其中数据由医疗设备在涉及病患的诊断疗程中产生(步骤1501)。通常，诊断疗程由例如在医疗机构(例如，医院或诊所)内的医疗人员进行监督。然而，诊断疗程也可在其他设置(setting)中发生。例如，病患可自行(例如，在她的家中)完成诊断疗程。同时，数据类型将取决于医疗设备的性质。例如，如果医疗设备是电子听诊器***，则数据可包括音频内容。作为另一例子，若医疗设备是成像仪器(例如，视网膜相机或X光机)，则数据可包括数字影像形式的可视内容。

接着，应用程序可进行数据分析，以得出对病患的健康的诊断相关见解(步骤1502)。例如，应用程序可检测音频内容，以识别呼吸异常或心血管异常。作为另一个例子，应用程序可检测可视内容，以识别异常的生长与损伤。在一些实施例中，应用程序可记录诊断相关见解的证明，其中证明是作为分布式***所维护的数字总账上的交易而导出的，且在分布式***中可运行应用程序。

此外，应用程序可建立实体存取诊断相关见解的授权(步骤1503)。例如，应用程序可响应于判断实体满足智能合约所包含的项目，执行授权存取给实体的智能合约。可替代地，应用程序可基于与病患相关的信息(例如，姓名或出生日期)、诊断疗程(例如，位置、时间、监督医疗人员)或医疗设备(例如，制造商)，判断可与实体共享诊断相关见解，并确认数字证书(建立实体的真实性的数字证书)是有效的。此数字证书可储存于由分布式***维护的数字总账中。

接着，应用程序可提供诊断相关见解给实体(步骤1504)。例如，应用程序可以将诊断相关见解(或与诊断相关见解相关的信息)转发给位于可由实体存取的计算设备上的客户端。在一些实施例中，应用程序记录诊断相关见解的证明，其中此证明被提供给实体，以作为分布式***所维护的数字总账上的交易。

图16绘示了由在分布式***上运行的应用程序实现的工作流程1600的例子。首先，使用者可以到达登陆页面(Landing Page)，借由登陆页面可以存取由应用程序提供的诊断服务(或简称为“服务”)(步骤1601)。登录页面可包括数据输入提示(Data EntryPrompts)，使用者可以在其中输入医疗数据以供服务分析。例如，如果服务旨在分析音频文件(例如，包括患者的呼吸音)，则接口可包括上传图形元素(也称为“上传按钮”)以及进度条，指示是否音频文件已成功上传。在一些实施例中，指令素材(例如，视频)可借由登陆页面获得，以帮助使用者记录和/或输入医疗数据，或以其他方式操作服务。

如上所述，在使用者借由登陆页面以必要格式输入和/或上传医疗数据之后，服务将获取医疗数据(步骤1602)。为确保正确完成此操作，使用者可以简单地上传医疗数据(例如，借由选择音频文件)，或者使用者可以查看指令素材以确保正确上传医疗数据。

此后，使用者输入的医疗数据可以借由分布过程(Decentralized Process)进行验证(步骤1603)，分布过程的一部分或全部发生在使用者用来存取登陆页面的计算设备上。如果验证失败，使用者可能会被带回之前的步骤以进行第二次尝试输入医疗数据。分布式验证的方法可能包括但不限于对数回归。附加地或替代地，服务可对照一个或多个评估参数(例如，由用于生成医疗数据的医疗设备的制造商定义)来验证使用者上传的医疗数据的品质。

如果确定医疗数据满足评估参数，则医疗数据可由计算设备传输到负责分析医疗数据的另一计算设备(例如，计算机服务器)(步骤1604)以及产生适当的报告(步骤1605)。例如，医学数据可借由互联网传输到计算机服务器，且在计算机服务器上，由人工智能(Artificial Intelligence，AI)或机器学习(Machine Learning，ML)执行的演算法执行呼吸音识别并编译报告。例如，可以借由推送通知、文本消息、电子邮件等将报告传达给使用者。附加地或替代地，报告可借由网络浏览器下载或仅用于在线查看。报告可能包括代表使用者解释的分析或结果，以及建议的后续行动。例如，报告可以基于在包含患者呼吸音的音频文件中发现的呼吸异常，建议患者存取医疗保健提供者。

除非与实际上的可能性相反，否则可设想以各种顺序与组合来执行上述步骤。例如，当与一个病患相关的数据共享于第一实体集而与另一病患相关的数据共享于第二实体集时，应用程序可执行过程1300、1400、1500的多个例子。在一些实施例中还可包括其他步骤。例如，除了负责诊断病患的医学人员之外，或者是作为负责诊断病患的医学人员的代替，还可将诊断相关见解(例如，存在呼吸异常)发布到接口以供病患检查。

处理***

图17绘示了可实现本文描述的至少一些操作的处理***1700的例子的方块图。例如，处理***1700的元件可被托管在代表应用程序之节点的计算设备上，其中在分布式***中可运行应用程序。此节点的例子包括医疗设备以及其他计算设备，例如，移动电话、平板计算机、个人计算机以及计算机服务器。

处理***1700可包括处理器1702、主内存1706、非挥发性内存1710、网络适配器(network adapter)1712(例如，网络接口)、视频显示器1718、输入/输出设备1720、控制设备1722(例如，键盘、定点设备或机械输入器(例如，按钮)、驱动单元1724(包括储存媒体1726)或信号产生设备1730，它们可通信地连接到总线(bus)1716。总线1716被绘示为一个抽象概念，其代表经由适当的桥接器(bridge)、适配器或控制器连接的一个或多个实体总线以及/或点对点连接。因此，总线1716可包括***总线、外部元件互连(peripheralcomponent interconnect，PCI)总线、高速外部元件互连(peripheral componentinterconnect express，PCI-Express)总线、HT(HyperTransport)总线、工业标准结构(industry standard architecture，ISA)总线、小型计算机***接口(small computersystem interface，CSI)总线、通用串行总线(universal serial bus，USB)、积体总线电路(inter-integrated circuit，I2C)总线或符合电机电子工程师学会(institute ofelectrical and electronics engineers，IEEE)标准1394的总线。

处理***1700可共享与计算机服务器、路由器、桌上型计算机、平板计算机、移动电话、电视游戏机、可穿戴式电子设备(例如，手表或健身手环)、网络连接(network-connected)(「智能型」)设备(例如电视或家庭助理设备)、增强或虚拟实境***(例如，头戴式显示器)或能够执行指定处理***1700要采取的动作的一组指令(一系列的或以其他方式)的另一电子设备。

尽管主内存1706、非挥发性内存1710以及储存媒体1726可被绘示为单个媒体，术语「储存媒体」以及「机器可读媒体(machine-readable medium)」也应被认为，可包括储存一个或多个指令的集合的单个或多个媒体1726。术语「储存媒体」以及「机器可读媒体」也应被认为，可包括能够储存、程序化或携带一组指令以由处理***1700执行的任何媒体。

通常，被执行以实现本发明的实施例的程序可被实现为作业***或特定应用程序、元件、程序、物件、模组或指令序列(统称为「计算机程序」)中的一部分。此计算机程序通常可包括在不同时间的计算设备中的各种内存以及储存设备中设定的一个或多个指令(例如，指令1704、1708、1728)。当由处理器1702读取并执行时，这些指令使处理***1700执行操作，以执行本发明的各个方面。

尽管已在上下文中描述了计算设备的完整运作的实施例，本领域技术人员也将理解，各种实施例能够以各种形式作为程序产品来发表。不管用于实际发表的机器可读的或计算机可读的媒体之特定类型如何，本发明都会适用。机器可读的以及计算机可读的媒体的其他例子可包括可记录类型(recordable-type)的媒体(例如，挥发性以及非挥发性内存设备1710、可移磁盘(removable disks)、硬盘驱动器(hard disk drives)、光碟(例如，唯独记忆光碟(compact disk read-only memory，CD-ROMS)以及数字多功能影音光碟(digital versatile disc，DVD))、基于云端的储存器)以及传输类型(transmission-type)的媒体(例如，数字与模拟通信连接(digital and analogcommunication links))。

网络适配器1712使处理***1700能够借由处理***1700与外部实体所支持的任何通信协议，在网络1714中将数据中继到处理***1700外部的实体。网络适配器1712可以包括网络适配器卡、无线网络接口卡、交换器、协议转换器(protocol converter)、闸道器、桥接器、集线器(hub)、接收器、中继器(repeater)或包括积体电路(例如，能够借由蓝牙或Wi-Fi的通信)的收发器。

备注

为了说明与描述的目的，前述已提供了本技术的各种实施例的描述。其不旨在穷举或将要求保护的主题限制为所揭露的精确形式。

许多修改与变化对于本领域技术人员将是显而易见的。选择与描述实施例是为了最好地描述此技术的原理及其实际应用，从而使相关领域的其他技术人员能够理解所要求保护的标的、各种实施例以及适合于所设想的特定用途的各种修改。

Claims (20)

1.一种由运行在分布式计算***上的应用程序实现的方法，其特征在于，所述方法包括：

借由应用程序从第一客户端接收指示请求的第一输入音频数据以验证包括个人的呼吸音的音频数据；

借由所述应用程序验证所述音频数据，进而授权所述应用程序与对所述个人的健康感兴趣的多个实体共享所述音频数据的分析；

借由所述应用程序从第二客户端接收指示来自实体的请求的第二输入以存取所述音频数据的所述分析；以及

借由所述应用程序执行智能合约，所述智能合约响应于判断所述实体满足所述智能合约中包含的项目，允许所述实体存取所述音频数据的所述分析。

2.根据权利要求1所述的方法，其特征在于，其中所述验证包括：

借由所述应用程序获取与负责产生所述音频数据的医疗设备相关的信息；

借由所述应用程序检测所数信息以确认所述医疗设备满足规范；以及

响应于判断所述医疗设备满足所述标准，借由所述应用程序产生对所述音频文件的所述分析。

3.根据权利要求1所述的方法，其特征在于，其中所述验证包括：

借由所述应用程序检测所数音频数据以确认所述音频数据符合标准；以及

响应于判断所述音频文件满足所述标准，借由所述应用程序产生对所述音频文件的所述分析。

4.根据权利要求3所述的方法，其特征在于，其中所述预定标准是最小持续时间或最小呼吸周期数。

5.根据权利要求1所述的方法，其特征在于，其中所述第一客户端驻留在负责产生所述音频数据的医疗设备中。

6.一种方法，其特征在于，所述方法包括：

借由运行在分布式计算***上的应用程序产生在第一计算设备中存取的接口；

借由所述应用程序接收指示请求的输入以验证经由所述第一计算设备中的所述接口上传的音频文件，其中所述音频文件包括由电子听诊器***记录的个人的多个呼吸音；

借由所述应用程序检测音频文件以识别经由呼吸音的分析发现的呼吸异常；以及

借由所述应用程序将与所述呼吸异常相关的信息转发给在与实体相关的第二计算设备上执行的客户端。

7.根据权利要6所述的方法，其特征在于，其中所述实体是所述电子听诊器***的制造商。

8.根据权利要6所述的方法，其特征在于，其中所述实体是负责治疗所述个人的医疗机构。

9.根据权利要6所述的方法，其特征在于，其中所述实体是参与支付所述个人的治疗费用的保险公司。

10.根据权利要6所述的方法，其特征在于，还包括：

借由所述应用程序从所述客户端接收指示来自所述实体的请求的第二输入以存取所述信息；以及

响应于判断所述实体满足智能合约中包含的项目，借由所述应用程序执行授权所述实体的存取的所述智能合约；

其中响应于所述执行，所述转发被执行。

11.一种方法，其特征在于，所述方法包括：

借由所述应用程序获取医疗设备产生的数据以作为涉及个人的诊断疗程的一部分；

借由所述应用程序对所述数据进行分析，以获得对所述个人的健康的诊断相关见解；

借由所述应用程序建立实体有权存取所述诊断相关见解；以及

借由所述应用程序向所述实体提供所述诊断相关见解。

12.根据权利要11所述的方法，其特征在于，其中所述建立包括：

响应于判断所述实体满足智能合约中包含的项目，执行授权所述实体存取的所述智能合约。

13.根据权利要11所述的方法，其特征在于，其中所述建立包括：

基于与所述个人、所述诊断疗程或所述医疗设备相关的信息，判断将所述诊断相关见解共享于所述实体，以及

确认建立所述实体的真实性的数字证书是有效的。

14.根据权利要11所述的方法，其特征在于，还包括：

借由所述应用程序记录所述诊断相关见解的证明，所述证明是作为数字总账上的交易获得的，所述总账数字是由运行所述应用程序的分布式计算***维护。

15.根据权利要11所述的方法，其特征在于，还包括：

借由所述应用程序接收指示来自所述实体的请求以存取所述诊断相关见解的输入；

其中响应于所述接收，所述建立被执行。

16.根据权利要15所述的方法，其特征在于，还包括：

借由所述应用程序记录所述诊断相关见解的证明，所述证明是作为数字总账上的交易提供的，所述总账是由运行所述应用程序的分布式计算***维护。

17.根据权利要11所述的方法，其特征在于，其中所述医疗设备是电子听诊器***，所述电子听诊器***用以在所述诊断疗程的过程中将所述数据传送至所述应用程序。

18.一种方法，其特征在于，所述方法包括：

获取与医疗设备相关的信息；

响应于基于对所述信息的分析判断所述医疗设备满足包含在第一智能合约中的第一项目，借由执行验证所述医疗设备的所述第一智能合约以完成第一验证程序；

在涉及患者的诊断疗程的过程中获取由所述医疗设备产生的数据；以及

响应于基于对所述数据的分析判断所述医疗设备满足包含在第二智能合约中的第二项目，借由执行验证所述医疗设备的所述第二智能合约以完成第二验证程序。

19.根据权利要18所述的方法，其特征在于，其中所述信息包括所述医疗设备的识别符、动态范围、频率响应、放大幅度、固件版本或应用程序版本。

20.根据权利要18所述的方法，其特征在于，还包括：

响应于完成所述第一验证程序，提供具有第一数字证书的医疗设备；以及

响应于完成所述第二验证程序，为所述医疗设备提供第二数字证书。

Images