CN117063244A - 具有可配置的数据采集和处理的健康监测系统 - Google Patents

Abstract

公开了一种在用户设备执行的用于获得健康相关数据的计算机实现的方法。该方法包括通过通信网络从健康监测系统接收数据采集配置，该数据采集配置包括调度数据，该调度数据定义要在用户设备执行数据采集活动的调度，每个数据采集活动用于在用户设备获取相应的健康相关数据。基于调度数据确定要执行每个数据采集活动的目标时间；根据数据采集活动各自的确定的目标时间在用户设备启动数据采集活动，以获得用于数据采集活动的健康相关数据。然后，基于获得的健康相关数据向健康监测系统发送结果数据。

Description

具有可配置的数据采集和处理的健康监测系统

技术领域

本发明涉及健康监测，例如临床研究的背景下的健康监测。具体示例涉及使用集成到个人用户设备(例如智能手机)中或可连接到个人用户设备的传感器，该传感器用于采集供中央健康监测系统处理的健康状态信息。

背景技术

现代个人计算机/通信设备(例如智能手机、智能手表、以及个人健身监测器)包括用于监测用户健康状态的多种传感器。例如，加速度计可以用于监测体育锻炼，红外传感器可以用于测量心率。许多智能手机厂商使用从这些传感器采集的数据来提供健康和健身监测应用和服务。还可以用更专业的医疗传感器设备，该医疗传感器设备可以通过蓝牙、Wi-Fi、或类似设备(例如肺活量计和温度计)连接到智能手机，并且可以使用智能手机显示和处理设备产生的传感器数据。

一些医疗保健和临床研究行业开发的系统能够经由智能手机跟踪疾病症状，并将数据传输到中央系统以供患者和医疗服务供应商使用。典型的方法包括广泛采集许多不同的健康测量以供临床医生理解，或者实施智能手机应用以使用一组预定的测量跟踪特定疾病的解决方案。因为需要为任何新健康监测应用或临床研究开发定制的解决方案，所以这限制了现有解决方案对新问题的适应性。如果用户设备的健康监测能力可以被有效利用，则原则上可以为临床研究和其他健康监测应用(例如多发性硬化、帕金森病、哮喘等)提供新的机会，并且降低临床研究和其他健康监测应用的成本，但是为这些应用开发定制的移动设备应用和相应的服务器端数据采集处理基础设施的成本可能非常高昂，并且得到的系统通常不灵活，无法适应变化的需求(包括新疾病、复杂调度、不断发展的试验设计、以及新设备和传感器技术)。

除设备和传感器技术的不断发展外，不同设备厂商的设备和相关的应用编程接口(application programming interface，API)通常还会以不兼容的格式生成和处理数据，进一步使集成各种设备到一个健康监控系统中变得复杂。

发明内容

本发明的各个方面在独立权利要求中阐述，某些优选特征在从属权利要求中阐述。附加的方面和特征在说明书后的编号条款中阐述。

公开了一种在用户设备执行的用于获取健康相关数据的计算机实现的方法。健康相关数据可以包括指示用户健康的数据和可从中导出指示用户健康的数据的源数据中的一个或多个。该方法包括通过通信网络从健康监测系统接收数据采集配置，该数据采集配置包括调度数据，调度数据定义要在用户设备执行的数据采集活动的调度，每个数据采集活动用于在用户设备获取相应的健康相关数据；对于上述数据采集活动中的每个数据采集活动，基于调度数据确定要执行数据采集活动的目标时间；根据数据采集活动各自的确定的目标时间在用户设备启动数据采集活动，以获得用于数据采集活动的健康相关数据；基于获得的健康相关数据向健康监测系统发送结果数据。

还公开了包括器件的用户设备、系统、或装置，上述用户设备、系统、或装置可选地包括至少一个处理器和相关联的存储器，用于执行本文所述的任何方法，并且公开了一种包括软件代码的非暂时性计算机可读介质，当在数据处理装置被执行时，软件代码适于执行本文所述的任何方法。

附图说明

现在将参照附图对本发明的示例性实施例进行描述，在附图中：

图1示出了研究管理系统的概况。

图2A至2E示出了使用研究管理系统建立和进行临床研究的过程。

图3示出了详细的系统组件。

图4示出了在用户设备上实现的研究配置。

图5A至5B示出了使用系统支持跨不同设备的多个研究。

图6A至6C示出了系统的数据摄取架构(data ingestion architecture)。

图7示出了数据处理流水线(data processing pipeline)。

图8示出了数据处理插件的操作。

图9A示出了特定健康研究的服务器端配置和处理。

图9B至9C示出了健康研究的客户端配置和处理，包括在用户设备上的移动应用调度数据采集活动。

图10A至10C示出了调度过程的其他方面。

图11示出了用于实现描述的技术的用户设备和中央数据采集服务器。

在附图中，相似的附图标记用于表示相似的元件。

具体实施方式

概述

本发明的各实施例提供了用于管理来自用户设备(例如智能手机)和不同健康传感器设备的数据采集以支持临床研究的系统。然而，虽然该技术主要被描述为临床研究管理系统，但是可以用于其他健康监测环境，例如用于监测长期疾病患者以支持其治疗。

该系统包括中央研究管理系统和用于智能手机、平板电脑、以及类似的个人计算/通信设备(本文通常称为用户设备)的移动应用，该移动应用高度可配置以支持同时或随时间变化地支持各种可能的临床研究，同一个移动应用中支持不同研究。应用和服务器基础设施还被设计在有限带宽和间歇性连接的情况下有效工作，以在各种场景中支持各种可能的用户。

移动应用可以被部署到智能手机或与大量研究参与者(本文也称为患者)相关联的其他用户设备，并且可以被动态地配置为同时且具体地研究多种疾病的症状或单个疾病的不同症状，而不是局限于一种特定疾病的一组固定症状。

中央研究管理系统允许构建特定研究配置，然后将其发布到用户设备上的应用实例。然后，系统处理从同一个应用实例接收的数据，并且将数据与发布的配置进行匹配，从而使研究者可以使用这些数据。

中央研究管理系统还支持使用可配置的分配调度从不同传感器设备(集成到用户设备中的传感器设备和单独连接的传感器设备)以及直接用户输入(例如经由症状问卷)采集不同类型的数据，。该系统可以同时管理跨多个研究/疾病领域的多个研究配置，将信息近乎实时地发送到中央监测系统，在中央监测系统对信息进行遵从性跟踪、质量检查、以及分析。

例如，该应用可以支持跨两个不同疾病领域的同时研究。在一个示例中，应用可以用于使用患者每天、每周或每月回答的特定屏幕问卷来研究一种疾病。同一个移动应用还可以用于从用户设备采集传感器数据以研究第二种疾病，将两种研究配置的数据提交到中央系统，并且在中央系统中根据各自的研究配置独立地存储和处理数据。数据采集调度可以明确地和单独地被配置用于不同的研究配置和不同的数据源(例如不同的传感器)。

在具体的示例中，应用可以用于结合与智能手机(或其他用户设备)连接的腕戴加速度计来研究一种疾病的步态和平衡，其中，该应用通过从智能手机加速度计采集时间点数据的每日分配进行配置，并且连接的腕戴加速度计采集数日(包括患者在智能手机上完成分配的时刻)的连续数据。使用计算行走距离和行走速度的步态和平衡算法来处理来自智能手机和腕戴设备的数据。同时，同一个移动应用和同一个设备可以用于研究睡眠，该应用通过睡眠日志和腕戴设备记录的数据进行配置，以确定患者的睡眠时间和患者夜间醒来的次数。在第二个示例中，用睡眠算法处理腕戴设备的数据。

另一个示例，为了支持单个疾病领域(例如帕金森病)，应用可以用于使用特定问卷，研究对象每周或每月回答该特定问卷，以支持一个研究。对于第二个研究，同样用于研究帕金森病，同一个应用还可以用于结合每天回答的一组不同的问题采集加速度计传感器数据。每个研究配置的数据被上传到中央监控系统，供相关研究者使用。

本文描述的实施例可以允许药物研究者和医疗服务供应商在大量研究参与者群体中通过单个系统中的单个应用和一个或多个连接的设备同时研究多种疾病，而不是为不同的研究或健康状况部署多个应用、设备、以及系统(例如，提供一个应用的实例和设备以研究帕金森病，又提供另一个应用的实例和不同设备以研究哮喘)。在典型情况下，任何一名患者在任何时候只能参加一项针对一种疾病的研究，但系统可能会同时对不同的患者队列进行多个研究。本文描述的系统可以允许管理这种复杂性。同时，单个患者的数据采集可以被简化，减轻患者的负担，并且可以通过将移动应用配置为减少的一组基于传感器的分配和专门针对特定研究症状的手动用户输入来简化研究的管理。

系统的各实施例还可以通过允许研究者便捷且远程地进行精确研究并且仅研究其想要和需要的东西，来简化研究的设计和实现。研究者可以在一个系统中以通用的数据模型和格式集中地采集和分析来自不同类型的分配和设备的所有数据。

图1示出了系统的示例实施方式的概况。该系统包括中央研究管理系统100，中央研究管理系统100和与研究对象或患者102相关联的设备交互。设备包括用户设备(例如，智能手机104或其他计算/通信设备)，用户设备运行移动应用106以执行数据采集并与中央研究管理系统100交互。在该示例中，用户还使用具有一个或多个传感器的智能手表108来获取健康数据。研究者(例如110、114)还使用相应的用户设备112、116(例如，台式/笔记本/平板个人电脑)与中央研究管理系统交互。

虽然本文的特定示例指使用智能手机作为用户设备，但是也可以使用任何其他合适类型的用户设备，例如平板电脑、可穿戴设备等。因此，在本文提及智能手机时，应该理解这仅仅是举例说明并且其他类型的计算/通信设备也可以替代。

优选实施例将疾病研究所需分配的选择和调度与部署以采集数据的用户设备104和应用106分开。特别地，应用106被设计为与任何特定研究所需的分配无关，而是提供可配置的数据采集功能，该功能可以被动态配置以支持特定研究的特定要求、传感器设备、数据采集调度等。应用的同一实例可以用不同的分配集重新配置(不像以前的方法，以前的方法通常基于唯一的、定义的设备和特定的数据元素将研究分配和调度封装到单个系统中的单个模型中)。不同的分配配置和调度由中央研究管理系统100协调和调节，使得不同的分配配置和调度与同一个患者匹配，并在相同的时间基础上为该患者操作。

中央研究管理系统可以接收和处理来自具有不同分配配置和不同分配调度配置的应用的不同实例的数据。在现有的方法中，采集传感器数据的应用可以记录例如加速度计值的JavaScript对象简谱(JavaScript object notation，JSON)文件，问卷响应可以生成逗号分隔值(comma-separated value，CSV)数据文件，患者日志可以提交web表单。每个数据文件都是单独存储的，在分析组合的数据集之前，需要对每个患者和每个研究的不同数据文件和格式进行编译。优选实施例可以精简化来自多个数据源和研究配置的数据采集。

使用上述系统的临床研究的配置和操作涉及多个阶段(在图1中标记为阶段1至5)，上述阶段将在以下部分中参考图1和图2A至图2E进行详细讨论。

阶段1：研究设计被配置、公布、以及分配给患者

在第一阶段，研究者114使用由研究管理系统提供的研究设置仪表板120(例如，作为在研究者的计算机设备116上访问的web界面)来设置新研究。

在图2A中更详细地说明上述过程。在步骤212，研究者从可用分配目录中选择其研究需要的研究分配，可用分配目录包括通过移动应用提供的分配。例如，在帕金森病的研究中，可以评估患者的震颤症状。这些分配可以包括基于设备的分配中的任何分配，例如，使用并入或连接到用户设备104的传感器(例如加速度计)、患者日志、标准临床问卷、功能状态分配等，所有这些都采用移动应用来采集并将数据转发到中央系统。分配目录优选地是可扩展的，例如支持新的传感器类型和用户设备以及用于分析传感器数据以获得有用的临床相关信息的新处理算法(例如，基于加速度计数据的震颤分析算法)。

如下文将更详细地描述的，分配可以被构造成子任务。给定的分配(或分配子任务)可以与一个或多个数据采集活动(基于传感器的和/或非基于传感器的，例如用户输入)相关联。基于传感器的数据采集活动与用于采集数据的特定传感器设备类型相关联，并且还可以与用于处理原始传感器数据以导出一个或多个导出的测量(例如，从加速度计数据导出的步数)的预定处理算法相关联。这些方面可以基于用户从目录中选择特定的分配来预定义和自动配置。然而，系统也可以允许用户明确地指定配置，例如选择特定的传感器设备或特定的处理算法。

在步骤214，研究者接下来为选择的分配定义分配调度，分配调度可以是每天、每周、每月、或根据研究要求以其他方式配置。例如，在睡眠研究中，可能要求患者完成每日睡眠日志。

研究者接下来定义质量和遵从性度量，在步骤216，该度量确定采集的患者数据是否满足完成分配的研究要求。例如，在一项研究中，患者可能被要求佩戴腕戴加速度计，该加速度计在连续7天中的每一天记录至少12小时的运动。在另一项研究中，患者可能被要求每周的每天至少佩戴设备12小时。这些要求可以被指定作为遵从性度量，之后可以根据这些度量评估实际数据。

在步骤218，研究者接下来基于添加的分配将研究设计发布到中央系统。在研究级别启用数据摄取插件以支持将为本研究摄取的数据类型。研究设计作为配置存储在系统中，除了将配置部署到移动应用的每个适用实例之外，其他负责招募、同意、以及筛选参加研究的患者的研究者还可以查看和选择该配置。该系统可以允许创建同一个研究配置的多个独立实例(例如，以支持不同的患者群体，或在不同的时间运行)。

阶段2：将患者添加到研究中并将研究发布到应用

在第二阶段，研究者110使用研究对象仪表板122招募、同意和筛选参与研究的患者(参与者)。

该过程如图2B所示。在步骤222，研究者将患者添加到中央系统中已发布研究的实例中。然后，研究者经由智能手机或类似的用户设备和移动应用设置患者访问。在一种方法中，应用连接到患者，而在另一种方法中，设备连接到患者，然后为患者在应用上创建一个账户。

例如，研究者将安装有应用的用户设备(例如智能手机)分配给患者(步骤224)，以及支持研究所需的任何其他设备，例如，腕戴加速度计、肺活量计、或其他设备。作为该步骤的一部分，安装在智能手机上的应用实例的激活码会被生成。激活码被输入到移动应用，因此移动应用实例/设备被分配给患者。研究者或患者可以执行其他配置步骤来完成用户账户创建，例如设置密码、接受用户协议等。

可选地，可以给患者的设备上的应用提供访问(例如，通过向用户发送激活码等，用户可以从应用商店、从系统提供的网络服务器下载应用)。输入激活码使应用实例连接到患者，患者可以如上所述完成帐户设置。

一旦患者账户设置完成，那么接下来，应用实例将研究配置下载到智能手机(步骤226)，研究配置包括分配列表和分配调度。

阶段3：执行分配

在第三阶段，研究调度的分配由患者使用其设备根据调度完成(例如，在特定调度的研究分配日)。

该过程如图2C所示。在由研究分配调度定义的任何给定的研究分配日，患者通过智能手机接收分配被调度完成的通知(步骤232)。在步骤234，患者使用密码或另一种认证机制(例如指纹认证)登录到其智能手机上的应用实例，以确认完成分配的用户对应于研究注册的患者。然后向用户显示要求的分配列表，并且在步骤236，患者完成要求的分配任务。

例如，在哮喘研究中，患者可能被要求在移动肺活量计上完成肺功能测试，然后移动肺活量计将数据传输到智能手机上的应用实例。患者可能还被要求完成相关的问卷，如哮喘控制问卷(asthma control questionnaire，ACQ)，该问卷记录患者未服药或服药后哮喘的控制程度。

数据最初存储在移动应用/用户设备的本地数据库中，并且系统在本地数据库和中央系统之间实现数据同步。在优选实施例中，在步骤238，数据被批量上传到中央系统。例如，给定的肺功能测试和完成的问卷，应用实例传输来自移动肺活量计的原始流速容积环(raw flow volume loop)以及对问卷的响应。在诸如帕金森病的研究的其他示例中，患者可能被要求完成步行分配，在步行分配中，手机放在口袋或包里，患者的运动被智能手机加速度计记录。患者可能还被要求完成评估其帕金森病症状严重程度的问卷。随后上传的数据可以包括在特定时间段内获取的加速度计读数的数据集和问卷输入。

数据上传根据研究配置定期进行，但是优选地频率不低于每天一次，如果需要的话上传会被延迟直到合适的网络连接可用。研究配置可以指定控制批量上传的各种标准，例如，执行传输的时间/时间窗口、传输频率、要被分组为同批的数据采集活动、带宽、或连接性要求，例如，指定所需的最小带宽和/或要使用的优选网络接口等。例如，应用可以优先经由本地Wi-Fi传输数据，并且可以延迟传输直到经由Wi-Fi(或另一个优选接口)的连接可用，和/或如果优选网络不可用，可以使用另一种连接(例如蜂窝服务)作为备份。批量传输可以基于研究配置中提供的显式定时信息被调度(例如，使用下面讨论的动态调度机制)，传输在配置中指定的时间被执行。

该应用需要中央研究管理系统收到的确认，并且会在没有收到的情况下尝试重新传输数据。应用可以在从中央系统接收到确认时(或一段时间后，例如保留延迟(retentiondelay)后)删除本地存储的数据。虽然结果数据的分批传输尤其对于具有受限带宽或间歇连接性的设备可能是有利的，但是替代的实施例可以实时或接近实时地转发数据，或者可以基于用户设备的连接性在立即传输和分批传输之间进行选择。可以使用合适的加密和/或消息认证机制来保护传输的数据。在一个示例中，哈希运算消息认证码(hash-basedmessage authentication code，HMAC)报头被添加到传输的数据中以确保消息的真实性和完整性。

移动应用为用户使用外部设备提供需要的提示和指令。例如，分配调度可以提示患者戴上或取下用于分配的腕戴加速度计。完成分配任务和如何使用专用传感器设备的指令可以通过文本、动画、视频等形式提供给用户。

例如智能手表108和专用传感器设备(例如肺活量计)的外部设备经由本地连接(例如蓝牙、Wi-Fi、USB、或其他有线或无线通信信道)将传感器数据传输到智能手机上的移动应用。然而，在一些情况下，外部设备可以不直接集成到移动应用中，而是可以经由智能手机上的独立应用/子系统(例如，由设备供应商提供的)和/或经由外部第三方系统(例如，使用绕过智能手机104的独立网络连接)传输传感器数据。系统架构100提供用于支持这种独立外部数据源的接口，下文将详细描述。

阶段4：数据处理

在下一阶段，由中央系统的数据处理模块124处理每个患者和研究的分配数据。该过程如图2D所示。

如上所述，患者完成的分配的数据最初存储在智能手机上，然后在网络连接可用时传输到中央系统。一旦接收到数据，则中央研究管理系统首先确定与数据相关联的当前患者、状态和研究(步骤241)。因为不能确认同意，所以与活动研究患者不匹配的数据优选地不被保存(可选地，这种数据可以单独存储，例如用于审计或调查目的)。

如果识别出匹配的活动研究患者，则在步骤242，接收的数据作为原始数据存储在数据库中。接收的数据包含关于患者、分配名称、使用的设备和时间戳的元数据。接收的数据还包含被提取的分配数据(步骤243)。根据分配的不同，数据本身会有所不同。例如，在一个实施方式中，分配数据可以是连续的加速度计传感器文件。在另一个实施方式中，分配数据可以是睡眠日志中的一个条目，记录在床上的时间、第二天下床的时间、以及患者晚上醒来的次数。

一旦从接收到的响应中提取了原始分配数据，则在步骤244，检查分配数据质量。

在示例中，接收步行分配的传感器数据文件。步行分配要求患者步行6分钟，这是慢性阻塞性肺疾病(chronic obstructive pulmonary disease，COPD)和心脏病中评估患者功能状态的常见测试。对接收的原始数据文件的质量检查可能显示仅接收到1分钟的有价值数据。这可能是由于患者没有完成活动，或是由于技术问题，例如腕戴加速度计有故障或电量低，并且在6分钟的步行过程中仅捕捉到间歇性片段。还例如，信号分析可以揭示心率传感器或其他传感器有故障或没有正确使用或佩戴，导致间歇性或低质量的信号。在这种情况下，因为分配没有按要求完成和/或所需数据缺失或质量不足，所以分配被标记为“未完成(incomplete)”。在一些实施方式中，未完成的分配在中央系统中被记录为“未完成”，并向临床人员发出通知以跟踪患者。在其他实施方式中，未完成的分配可以触发对患者分配的自动重新调度。然后将通过数据质量检查的分配提交给算法，以根据原始数据，在步骤245，计算需要的测量。上述需要的测量在本文也被称为导出的或聚合的测量，并且可以经由各种聚合和其他处理技术来导出，例如根据涉及的传感器、研究的症状或其他特征等。这一步骤可以包括对原始数据的简单重新格式化或聚合到复杂的信号处理算法的任何事情。此外，对于某些类型的数据，例如直接用户输入(例如问卷)和某些类型的传感器数据，可能不需要额外的处理，并且可以省略该步骤，所以导出的测量与原始数据相同。

作为该步骤的示例，对于同一个6分钟步行测试，该算法可以从原始加速度计数据计算消耗的步数、步行距离、以及步行速度。

导出的测量可以包括与研究相关的健康指标，即提供一些对参与者健康状况的指示的计算值。这种健康指标可以基于单个数据源(例如，来自特定传感器的传感器数据或特定交互式评估的结果)，而其他指标可以从多个源导出(例如，从心率测量、肺活量计测量和问卷导出的健康指标)。一些计算的健康指标可能对应于研究的研究终点(study endpoint)(例如，与手头研究的研究对象相关的特定结果测量)。

一旦执行了任何需要的处理，那么导出的测量就会被存储在数据库中。

在步骤246，计算分配遵从性(compliance，也称为遵守性)。这可以例如涉及确定是否已经执行了分配的所有需要的测量和其他输入。例如，如果一项分配包括多项数据采集活动(例如，步行分配、呼吸分配、以及问卷)，并且如果其中一项活动尚未完成，则可能会被标记为未遵从。

在步骤247，更新中央系统中的患者记录以显示分配的完成(或部分完成/未完成)。

与分配未通过数据质量检查的情况一样(步骤244)，如果识别出遵从性问题，则可以在步骤248，通知研究者，例如，以能够对患者进行随访。未遵从的分配也可以被重新调度。

当发现问题时，研究者可以根据问题的类型确定适当的应对措施。例如，研究者的应对可能会有所不同，这取决于识别的问题是未遵从(例如，用户没有完全遵从分配要求和指示)，或特定的分配的数据不完整/低质量(这可能是由于技术问题)。

第5阶段：编译研究数据集

在最后阶段，来自所有分配和患者/设备的数据被研究数据集处理模块126编译成研究数据集。该过程如图2E所示。

研究数据集可以在研究期间和/或在研究结束的间隔被编译。该数据集包含为所有已完成的对象分配记录的所有测量。该数据通常包含任何导出的测量和健康指标，在适用的情况下，还包含原始传感器或用户输入数据(例如，不需要进一步处理的原始传感器测量或用户输入数据)。优选实施例使用用于所有数据的通用健康数据模型(下面称为“通用测量模型”)，这有助于组合来自多个来源的数据，这将在后面更详细地描述。

在步骤252，研究管理系统经由数据库查询，并且在适当的情况下，为注册为研究参与者的所有患者提供额外的内部分析、所有采集的相关数据的测量数据。查询可能被限制在要求的日期/时间范围内。在某些情况下，查询也可能被限制在参与者的子集中。

检查初始数据集的质量和完整性(步骤254)，这可以包括根据研究者的要求去除重复数据或去除遗漏或未完成分配/任务相关的记录。完成质量检查后，在步骤256，以研究者要求的文件格式输出数据，然后在步骤258，将文件传输给研究者(例如，通过将输出文件传输给研究者的用户设备116，或使输出文件可供研究者在web/文件服务器上下载)。

数据采集活动的类型

该系统支持由用户和/或其设备执行的作为调度的分配的一部分的各种类型的数据采集活动。每个分配可以对应于可使用用户设备执行的一个或多个数据采集活动。

给定的数据采集活动被设计以采集一组特定的健康相关数据。采集的健康相关数据可以包括与用户健康相关或指示用户健康的数据(例如，来自心率传感器的心率)，和/或可以从中导出与用户健康相关或指示用户健康的数据的源数据(例如，可以从中计算睡眠质量数据的加速度计数据)。因此，术语“健康相关数据”或“指示用户健康的数据”包括适用于提供或导出关于用户健康的某些方面的信息的任何形式的数据。

在优选实施例中，支持的数据采集活动类型包括基于传感器的数据采集活动、数据输入活动、以及交互式评估。

基于传感器的数据采集活动使用一个或多个设备传感器和/或连接到用户设备(或连接到外部数据采集平台)的外部传感器来获得传感器数据形式的健康相关数据。传感器可以包括通用传感器(例如智能手机内置的加速度计)和/或专用医疗传感器(例如肺活量计、血压传感器等)。

数据输入活动基于与健康相关的数据值的直接用户输入，例如患者问卷和健康日志。在这种活动中，提示用户提供特定信息，特定信息可以包括主观症状评估以及使用非连接设备获得的测量(例如，使用常规体重秤获得的体重测量)的手动输入。数据输入活动可以以电子化患者报告结果(electronic patient reported outcome，ePRO)、临床医生报告结果(clinician-reported outcome，ClinRO)、或等效形式实现对健康相关数据的捕获。数据输入活动可以被实现为显示在用户设备的显示器上的输入表单，输入表单具有预定义的一组输入字段，该输入字段将由用户经由用户设备上的数据输入来完成(例如，使用触摸屏和屏幕键盘/手写识别、语音识别等)。

交互式评估可用于提供更高级形式的基于用户输入的数据采集活动。这些形式可以是在用户设备执行的交互活动的形式，该形式要求对象通过与设备和设备的用户界面(例如，与设备的触摸屏)交互来查看和响应提示(例如，在用户设备的显示器上显示的提示、经由设备扬声器输出的声音提示等)。该活动的输出可能不仅限于用户响应提示而输入的数据。相反的，活动可以测量交互的其他特征以产生相关的测量，例如响应准确性(例如，用户是否或多长时间从可用的响应中选择正确的响应)、响应时间(例如，用户响应提示花费的时间)、受试者在完成/最终确定响应之前是否编辑响应、输入响应的速度(不同于响应时间，例如，打字速度)等。由交互式评估生成的健康相关数据是基于用户交互的测量特征。

交互式评估评估用户健康或能力的某些方面。例如，交互式评估可以实施认知测试、感知测试，例如，视觉敏锐度测试或听觉测试、灵巧度测试、或任何其他形式的交互式测试，用于基于受试者的健康和/或能力对其进行评估和/或分层。

斯特鲁普测验(Stroop test)是这类认知测试的示例。斯特鲁普测验的一种已知形式是基于显示颜色名称与其显示颜色不匹配的颜色的名称，并且测量测试对象识别颜色名称和显示颜色花费的时间。还例如，灵巧度测试可以包括要求用户在屏幕的不同高亮区域上交替点击两个手指，测量响应时间和响应准确性(例如，是否点击了正确的区域、点击时正确交替手指的一致性、或点击与高亮区域的距离)，并且作为交互式评估的输出来提供。

上述数据采集活动类型也可以被组合以创建更复杂的分配。例如，交互式用户输入活动(例如认知测试)可以另外从一个或多个传感器采集传感器数据。作为另一个示例，基于传感器的活动(例如与心率测量相关联的身体活动)可以用评估患者对活动的主观体验的问卷问题来增强。

因此，根据活动的性质，为特定数据采集活动采集的健康相关数据可以包括传感器数据、用户输入数据、交互式评估数据、或组合。

用户设备的移动应用支持不同模式的数据采集，以支持不同类型的数据采集活动。特别地，该应用支持在基于传感器的数据采集模式下从内部或外部传感器采集数据，在数据输入模式下显示用于数据输入活动的直接数据输入的输入表单，以及在交互式评估模式下运行交互式评估。在每种情况下，要采集的数据在从中央研究管理系统接收的数据采集配置中定义。因此，对于基于传感器的数据采集活动，数据采集配置指定将使用哪些传感器来获得传感器数据。对于数据输入活动，配置指定要获取数据的数据字段(以及要显示的相关提示)。交互式评估可以作为可执行脚本/代码提供给设备，可执行脚本/代码可以在用户设备被执行。这些数据可以直接包括在传输的配置中，或该配置可以包括到评估脚本或类似数据的连接。

给定的健康研究可能包括上述任何类型的数据采集活动，以及任何组合。例如，研究可以将基于传感器的数据采集活动与用户输入活动或交互式评估(或两者)相结合。还可以使用给定类型的多个数据采集活动(例如，不同传感器、多个不同的问卷、或其他输入活动、和/或多个交互式评估的多个不同的基于传感器的活动)。该系统还可以扩展到支持其他类型的数据采集活动。

系统架构

系统架构的更多细节如图3所示。数据从智能手机104和外部传感器设备108(左)流向中央研究管理系统100(右)。标有星号(*)的组件可根据每个研究和疾病进行配置。

如图所示，智能手机104(或其他个人/移动通信/计算设备)包括一个或多个传感器302(例如加速度计、红外传感器等)适于获得对监测患者健康的某些方面有用的测量，以用于临床研究和其他健康评估。智能手机还包括用于在移动设备操作数据采集过程的可配置的移动应用106。

可以提供一个或多个外部传感器设备108，包括相关传感器304，相关传感器304可以连接到智能手机104(例如，经由蓝牙或另一个本地有线或无线连接)。可选地，外部传感器设备可以无需与智能手机104连接，直接向中央系统100提供测量数据。在这种情况下，测量数据可以(例如，经由第三方网络服务或类似服务(未示出))被传送。这种设备在本文也被称为独立传感器设备。

移动应用106经由研究配置被配置用于从内部传感器302和/或外部测量设备108获得作为患者分配的一部分的测量数据。在外部测量设备108是不经由用户设备104和移动应用108通信的独立设备的情况下，移动应用可以用于指示用户在适当的时间操作独立的外部传感器设备以获得测量，然后该测量经由单独的网络连接直接提供给中央系统100。

中央研究管理系统100包括数据处理器网关318，数据处理器网关318用于从智能手机的移动应用接收数据，并将原始数据存储在原始数据存储312中。如上所述，对于未用于与移动应用106集成的外部设备，网关还可以经由外部系统(例如设备供应商网络服务)从独立外部设备108接收测量数据。原始数据在本文可以指从移动应用或外部设备接收的未处理的数据，因为在一些实施方式中，原始数据可能在存储数据之前或在移动应用/外部传感器设备处被执行过一些预处理或重新格式化。

中央研究管理系统100还包括web应用314，web应用314提供实现研究设置仪表板120和研究对象仪表板的web界面，web界面用于管理研究参与者(如上所述)。研究设置仪表板允许配置分配和分配任务，包括定义传感器数据采集活动、创建问卷等。仪表板界面还可以被提供，例如，用于查看和查询采集的数据和生成的报告。仪表板优选地是可配置的，例如，允许根据研究配置和调度提供数据的不同视图。

此外，可以提供设备管理界面(未示出)以允许跨多个供应商管理用户和传感器设备。这可以通过使用设备供应商应用编程接口(application programming interface，API)的模块化方法来实现，其允许经由设备管理接口创建用户和管理设备(例如，以允许将设备分配给用户、移除分配等)。

如前所述，从原始数据存储312采集的数据由一个或多个数据处理器模块316处理，例如，如前所述，以从原始传感器数据(例如，来自加速度计数据的步数、疾病症状评分等)导出需要的健康度量或健康度量318。中央系统还执行数据质量检查320，并生成研究数据集322，用于导出给研究者进行如前所述的研究。

需要注意的是，在实践中，中央系统100可以被实现为实现各种模块的单个服务器，或可选地可以分布在多个计算设备上，例如，一个或多个数据库服务器、web服务器、数据处理服务器等。

虽然出于说明的目的示出了单个智能手机104和外部传感器设备108，但在实践中，中央系统100通常与许多这样的设备交互，这些设备与许多不同的用户(研究参与者/患者)相关联。

不同的内部传感器302和外部传感器设备108以及不同的处理模块316可以作为不同的研究要求的功能被选择。例如，在睡眠研究中，活动记录设备可用于采集夜间活动数据。然后该活动数据通过合适的算法(例如，可以使用公开的可用的和有效的算法)来处理，该算法导出睡眠的属性，例如总睡眠时间、清醒次数等。在另一示例中，外部传感器设备108可以是移动肺活量计。患者对着移动肺活量计吹气两次或多于两次，移动肺活量计记录患者通过设备的呼吸流量。然后流量数据被处理以计算肺功能测量。在其他示例中，外部传感器设备108可以是单导联心电图(electrocardiogram，ECG)传感器，单导联心电图传感器是经由贴片施加的传感器，患者将贴片贴在其靠近心脏的胸部。在这个示例中，心跳的电信号被记录下来，算法处理数据以得出每分钟心跳的次数和其他支持的测量。

在智能手机104处，分配由功能分配模块306执行。如下文更详细地所述，功能分配模块306包括用于调度分配和单个数据采集活动的基于事件的调度引擎。除了基于传感器的数据采集之外，其他形式的数据采集可以作为分配的一部分来执行。例如，移动应用可以包括用于实现数据输入活动的患者日志模块308和症状问卷模块310，以及用于执行交互式评估的交互式评估模块311。与基于传感器的分配一样，这些分配使用调度引擎进行调度。从传感器、患者日志、症状问卷、以及交互式评估中采集的数据可用于每项研究。

移动应用配置

图4示出了特定研究的用户设备和移动应用的示例配置。患者登录到智能手机104，并且显示分配的任务列表402。一个或多个分配可以使用智能手机传感器404(在该示例中，陀螺仪和加速度计被用于步行测试)。

在所示的示例中，患者需要完成三个任务：步行分配406(基于传感器数据)、睡眠日志408(基于用户数据输入)、以及症状严重性问卷410(基于用户数据输入)。用户数据输入通常是文本输入的形式(例如，经由屏幕键盘/触摸界面)或经由语音识别。其他疾病的其他研究可以实现不同的任务列表配置。例如，虽然在该示例中只有分配任务中的一个是基于传感器数据的，但是在其他研究中，可以存在多个基于传感器数据的分配任务，多个分配任务可以使用不同的传感器或相同的传感器(例如，在这种情况下，可以执行基于传感器的睡眠监测，而不是睡眠日志)。

根据分配的性质，数据采集可以涉及主动用户任务(例如在这个示例中，通过显示在设备屏幕上的信息提示用户执行特定的任务，例如步行，然后使用传感器监控该任务)和/或可以涉及被动数据采集(例如睡眠监测、特定时间段内的步数监测)。此外，根据研究配置，单个分配任务(包括多个基于传感器的任务)可以同时或在不同时间执行。

图5A至5B示出了如何从中央研究管理系统配置多个研究。图5A示出了设置阶段，其中不同的分配配置506、508(在这个示例中，涉及两种不同的疾病)被推送到两个智能手机502、504。在这个示例中，这涉及在安装在智能手机“一”上的应用的实例中，为患者“一”的疾病“一”配置一组分配和研究分配调度(502)；以及在安装在智能手机“二”上的应用的实例中，为患者“二”的疾病“二”分开配置分配和相关联的调度(504)。

在图5B所示的部署/数据采集阶段，每个智能手机接下来执行由其各自的研究任务配置指定的数据采集活动，并将结果数据传输回中央系统。在这个示例中，患者“一”在安装在智能手机“一”上的应用的实例中完成分配，患者“二”在智能手机“二”上的应用的实例中完成分配。数据从智能手机“一”和智能手机“二”提交，并由中央系统处理。

系统实施方式

以下部分更详细地讨论上述系统的技术实施方式的各个方面。

在优选的实施方式中，描述的系统基于可扩展架构，可扩展架构适于与用户设备、外部传感器设备、以及外部服务的可扩展范围交互。该架构可经由插件进行扩展，以支持新的设备和服务。中央数据处理系统被设计为与设备无关。

设备无关是部分地通过数据摄取流水线实现的，数据摄取流水线用于从移动、可穿戴、以及其他的传感器设备的可扩展列表中获取设备和传感器数据。无论数据传输方法如何，该流水线都可以运行，支持可扩展列表，可扩展列表包括蓝牙、超文本传输协议(hypertext transfer protocol，HTTP)、超文本传输安全协议(hypertext transferprotocol over secure socket layer，HTTPS)、以及安全文件传送协议(secure sockets/SSH file transfer protocol，SFTP)。该流水线还可以在不考虑数据格式的情况下运行，支持包含JavaScript对象简谱(JavaScript object notation，JSON)、逗号分隔值(comma-separated value，CSV)和制表符分隔值(tab-separated value，TSV)的可扩展列表。需要注意的是，支持的数据传输和格式仅作为示例给出，并且可以使用任何合适的格式和传输协议。

用于设备集成的模块化架构使用可通过配置扩展的通用流水线，允许系统通过可变的传输方法集以可变的格式从可变的来源集接收数据，并以等效的方式处理所有数据。在特定实施例中，所描述的架构可以帮助解决各种技术挑战并支持各种复杂功能，例如：

·数据可搜索性(Data Searchability)：以相同的方式查询来自任何来源的数据的能力。

·数据有效性(Data Validity)：将任何测量与可配置的可靠性阈值进行比较以在初始处理期间确定来自特定测量的数据是否可靠，并为低质量的输入数据生成适当的警报的能力。

·数据稀疏性(Data Sparsity)：检测数据集中是否有缺失数据并自动使用回填算法以完整数据集的能力，包括决定何时/是否执行回填以及如何实施回填。

·设备比较：比较和使用来自多个来源的数据，而无需为设备的每个配置或组合定制处理模块的能力。

·任务遵从性(Task Compliance)：任何测量类型上运行统一的遵从性引擎，并为每个用户生成高度可见的遵从性(high-visibility compliance)以确定用户是否按照不同方案下的指示使用传感器的能力。

·可配置性(Configurability)：从分配任务和测量列表中配置不同的组合，并在同一平台上将其部署给不同的用户/研究参与者的能力。每个研究方案通常需要不同的配置且任何单个研究都可能需要多种配置，所有这些带来了以下的模块描述的技术挑战。

·动态演变和决策(Dynamic Evolution and Decision Making)：经由配置，允许单个人的测量组合在观察期内发生变化。

·模块化：输入和处理来自X源的Y格式的经由Z传输方法的每个配置的数据的能力，这种能力以数据摄取插件的可扩展接口的方式被提供，和选择现有插件或创建新插件以支持特定研究方案的能力。这种方法通常比为每种数据类型创建不同的数据流水线更具可伸缩性。模块化的、可扩展的流水线优选地允许为不同的数据源配置源、传输和格式。该系统定义由数据摄取插件使用的标准接口模式，允许创建支持的传感器设备的可扩展列表。

在实施例中，架构包括以下组件中的一个或多个：

·通用的测量模型。

·外部设备和服务应用编程接口(API)，用于从独立外部传感器设备获取数据(例如，经由第三方/设备供应商服务)。

·移动应用API，用于从用户设备(例如智能手机)及其集成传感器和/或直接连接到用户设备的传感器设备获得数据。

通用测量模型

构成统一数据接收流水线的基础是通用测量模型。该模型由包装器(wrapper)组成，该包装器具有时间戳、完成元数据、以及将测量连接到生成测量的原始数据文件的信息，随后是数据字段，该字段包含与单个测量相关的所有传感器读数。因此，该模型中的单个“测量”可以包括来自相同或不同传感器的多个传感器读数。每个传感器读数包括：

·值(value)：传感器读数的值。

·单位(unit)：从可扩展的单位列表中选择的读数单位。

·类型(type)：值的数据类型(例如，整数、浮点数、文本、百分比等)。

·检测(measure)：该读数的可读标识符(即“FEV1”)。

虽然主要针对传感器读数进行讨论，但是相同格式可用于非来源于传感器的其他数据，例如，由用户手动输入的数据值或从交互式评估中获得的健康相关数据。因此，在这种情况下，“测量”一词可以表示，但不一定表示已经进行了测量；因此，“测量”可以指其他形式的数据采集，并且测量模型可以用于表示来自任何来源的任何种类的健康相关数据(通用测量模型也可以称为通用健康数据模型)。

如果一个完整的测量由来自多个传感器或源的数据组成，每个传感器或源导致测量中不同的读数。任何导出的测量也保存在读数部分。然而，在简单的情况下，测量也可以包括来自单个传感器的单个传感器读数或其他单个值。

由于每个测量都以相同的格式存储，因此这些测量都可以以相同的方式进行处理和配置。当设置需要接收测量的研究时，用户从已经支持的测量列表中进行配置，或者可以为新的测量类型添加模块，提供一些关于应该如何摄取测量(例如，格式、传输)的元信息，并且可以设置其处理配置。然后，如下文更详细地所述，该配置在两个外部接口之一的数据摄取流水线中使用。

在一个实施方式中，测量作为基于事件的处理流水线中的事件被存储、传输、以及处理。基于事件的处理流水线允许系统组件生成事件(例如测量事件)并将这些事件提交给事件处理系统。其他系统组件可以订阅特定事件。当接收到与事件订阅匹配的事件时，该事件被转发到订阅系统组件，然后订阅系统组件可以处理该事件(例如，包含测量)。仅作为示例，这种订阅的一些可能结果可以是：

·更新参与者一周的遵从情况。

·更新参与者的最新数据，以便研究者可以查看参与者最近的测量

·触发数据科学算法，例如，以处理传感器数据。

测量事件模式包括派生的唯一键和包含读数(单个数据值)的事件值。下面的示例1(使用伪代码)说明了事件键的模式：

示例1

下面的示例2(使用伪代码)说明了事件值的模式，存储传感器测量事件(在这种情况下，来自加速度计)的原始传感器读数：

示例2

下面的示例3(使用伪代码)说明了事件值的模式，存储派生或聚合的测量数据，在这种情况下，存储从原始传感器数据派生的测量数据：

示例3

示例3的导出/聚合的测量可能已经通过聚合模块从原始传感器读数中获得，如下更详细地所述。在这个示例中，测量包括三个“读数”或子值：穿戴率、步数和睡眠时间，这些“读数”或子值可以从一组加速度计测量(如示例2所示)。

需要注意的是，上面给出的代码示例旨在提供代表性示例，在实践中，可以根据实施方式的要求调整特定的数据结构。此外，具体的数据源(例如苹果健康(AppleHealth^TM))、事件类型、以及测量可能会因实施方式、应用背景、以及正在进行的研究而异。

键数据(key data)和值日期(value date)共同定义了一个测量事件。测量事件可以以这种格式(例如，作为基于事件的处理架构中的事件)在处理模块之间传输，并且优选地也以这种格式(例如，作为键值存储中的键值对)保存到测量数据库。然而，也可以使用用于通信和存储数据的其他格式。例如，可以使用一组用于存储上述键信息和值信息的表字段将测量存储在关系数据库表中。

该系统优选地能够基于一个或多个键数据元素(例如，用于检索特定用户标识符或设备标识符的数据)来搜索、查询、和/或整理测量数据。

数据摄取流水线架构

数据摄取流水线如图6A至图6C所示，并且包括以下子系统：

·设备接口，与独立外部传感器设备的设备供应商API连接(图6A)。

·构成移动应用(106)的一部分的移动应用接口，与用户设备的传感器和相关子系统以及连接到用户设备的外部传感器设备连接(图6B)。

·统一的数据摄取接口，与设备接口和移动应用接口连接以接收测量，并且根据需要处理、存储、和/或转发测量数据。(图6C)。

这些子系统将在下面的部分中描述。

设备接口

设备接口以基于web的模块化API和一组插件形式的相关接口模块的形式提供，这些插件与第三方设备供应商API通信，以基于研究配置从独立传感器设备采集数据。当研究开始时，系统识别需要的独立传感器设备，并且使用现有插件或(如果插件尚不存在)通过将需要的新插件附加到设备API为每个设备创建数据通道。

研究的每个活动插件都将用于以特定方式检索数据。当创建研究时，可以提供任何(带有预定义接口的，例如，传输方法、回填方法、相关URL等)自定义插件。

图6A在一些示例插件及其配置的背景下示出了设备接口。

设备API 602包括一组可扩展的插件604(或与之通信)，该插件604负责将原始测量数据引入设备接口。数据来源于独立传感器设备，通常经由第三方服务(例如，由设备供应商提供)。在该示例中，示出了向设备供应商系统606提供传感器数据的独立传感器设备612。例如，独立设备可以是腕戴健身监测器或智能手表，并且向设备供应商的远程数据采集系统上传数据，例如加速度计数据、步数数据、脉搏测量等。不同的供应商提供各自的数据采集系统606，每个系统都有自己的用于访问采集的数据的API。

相关插件604与设备供应商API连接以检索测量数据。每个插件都专门适用于特定服务，以使用适当的传输机制、查询格式、数据格式等来检索数据。一些示例包括使用常用工具(例如，亚马逊简单存储服务(Amazon simple storage service)“S3”(608))和传输方法，例如超文本传输协议(hypertext transfer protocol，HTTP)(例如，使用HTTP POST或HTTP GET进行查询)，以及远程过程调用(remote procedure call，RPC)机制(例如gRPC)。然而，这些工具/传输方法可以与任何类似的工具/传输方法互换。

插件从相应的设备供应商系统/API接收数据，并且将原始传感器数据提供给设备API 602。如前所述，“原始”数据通常是指从设备供应商系统收到的数据。因此，“原始”数据可能已经或可能没有被这些系统预处理，例如，原始数据可能对应于由传感器生成的原始传感器数据，或对应于由设备供应商系统处理和提供的数据(例如，已经被转换、格式化、聚合等的数据)。由设备API 602接收的原始数据的副本被上传到备份系统或数据库610(在这种情况下是S3存储桶(S3 bucket)，但是也可以使用任何合适的存储技术)。

除了传感器数据的接收和初始处理之外，设备API的部分配置还围绕着监控和警报外部系统的正常运行时间。因为设备API在许多情况下依赖于第三方设备供应商API，所以设备API为每个插件使用可配置的监控引擎，以确保外部API受到监控，并且如果外部API中的一个出现故障并且系统在一段时间内无法检索数据，则系统会发出适当的警报。优选地为每个插件定义回填方法，该方法被定义为当系统重新联机以读取缺失数据并完成测量数据记录时运行。

移动应用接口

移动应用接口如图6B所示。移动应用接口履行与上述设备接口类似的角色，但是移动应用接口用于由移动应用在用户设备直接获得的传感器数据。

移动应用接口包括移动应用API 622，该API622与插件624形式的一组接口模块一起构成用户设备(例如智能手机)104上的移动应用106的一部分(参见图1)。移动应用API622在移动应用内提供移动模块化接口，该接口经由插件与用户设备的内部设备传感器以及经由蓝牙、Wi-Fi、NFC、或其他本地无线或有线连接直接连接到用户设备的传感器设备通信，以采集传感器数据并将数据发送到中央系统进行处理。像图6A的设备接口一样，移动应用接口在设计上是模块化的，并且可通过一组插件624扩展，以与不同的传感器和用户设备子系统通信。每个插件可以与不同的设备类型，和/或不同的数据传输机制和/或设备接口相关联。

本示例示出了蓝牙连接的肺活量计626，该肺活量计具有经由API/软件开发工具包(software development kit，SDK)访问肺活量数据的插件624，API/SDK由肺活量计供应商提供。示出了Healthkit^TM插件628，该插件用于访问来自Apple^TM智能设备上提供的Apple^TM的健康应用的数据(该数据可以来自集成到用户设备中的传感器或来自外部传感器)。还例如，示出了用于Wi-Fi温度计630的插件。可以提供其他插件(例如加速度计)以支持内部传感器。具体的插件/设备仅作为示例示出。该系统可以配置有插件，插件用于从连接到用户设备的任何合适的外部传感器设备、设备的内部传感器、或用户设备的其他内部子系统(例如，健康或传感器API或应用子系统)获取数据。因此，数据可以直接从传感器或经由其他(例如第三方)应用、API和子系统，经由相关插件间接地提供给移动应用API 622。

该系统是模块化和可扩展的。可以配置现有插件或添加新插件以与新设备和子系统(例如API、SDK)连接，从而为特定传感器设备或数据源生成数据摄取流水线。

在实施例中，经由移动应用API摄取的数据被提供到通用测量模型中，该通用测量模型在整个移动应用中用于所有数据采集任务，包括问卷调查、交互式评估、移动传感器的使用、以及外部设备传感器。经由移动应用API 622获得的传感器数据和其他数据通过移动网关被发送到中央研究管理系统，然后被进一步处理到如上更详细地所述的通用测量模型中。

图6C示出了设备API 602和移动应用API 622统一通过共享的数据摄取API 640。数据摄取API(和随后的数据处理流水线)在中央研究管理系统处实现，并经由移动应用API622从设备API 602(其可以在中央系统或单独的数据采集系统实现)和移动应用(和因此从用户设备的传感器或直接连接到用户设备的其他传感器设备)的独立传感器设备接收传感器数据。数据摄取API还接收由移动应用本身直接生成的数据(不使用内部设备传感器或外部传感器)，例如，基于直接用户输入(例如健康问卷)或由应用执行的交互式评估。基于接收到的数据，数据摄取API生成测量事件，并将这些测量事件发布到测量主题642下的事件处理子系统(在该系统中，主题标识特定事件类型，可以针对特定事件类型发布事件且该事件可以被事件消费者订阅)。测量事件随后由后续流水线组件处理，如下更详细地所述。

然而，虽然示例实施例使用基于事件的模型来传输测量，但是可以采用其他合适的传输方法来实现流水线。例如，数据摄取API可以将传感器数据存储在关系数据库中，在该关系数据库中，传感器数据随后可以被处理流水线的其他组件检索。

在由数据摄取API接收传感器数据并且存储原始传感器数据和其他数据之后，测量处理流水线中的下一步是将原始传感器数据和其他数据转换至通用测量模型中(如上所述)。可选地，传感器数据和其他数据可以通过设备API 602和移动应用API 622或其各自的插件转换至通用测量模型中。

转换至通用测量模型中后，执行数据聚合。术语“聚合”在本文用于表示对原始传感器数据和其他数据的任何处理，以确定一个或多个导出的测量；尽管其他形式的处理(例如单位转换)可以附加地或可选地在过程的该阶段执行，但由于通常从多个原始传感器读数计算导出的测量(例如，从加速度计数据计算步数的情况)，这个阶段被称为聚合。导出的测量可以包括一组与正在进行的健康研究相关的健康指标。

聚合流水线(aggregation pipeline)本身是另一种模块化服务，能够处理不同类型的原始传感器数据和其他数据，通过一组可扩展的插件实现不同的聚合和其他处理算法。

图7还示出了聚合流水线，并且聚合流水线包括聚合服务702，该聚合服务702在事件处理系统消费来自测量主题642的测量事件，并且生成包含处理的测量数据(例如，从原始传感器数据获得的聚合和/或导出的测量)的新测量事件，该处理的测量数据被提交给事件处理系统。聚合服务采用临时数据库712来临时存储正在处理的数据。例如，在可以计算导出/聚合的数据(例如步数)并且可以在暂存数据库中采集需要的数据之前，可能需要采集(可能很大的)一组原始传感器读数(例如加速度计读数)。此外，原始和/或聚合的/处理的数据可以被写入单独的数据库714用于长期存储，例如，供外部数据科学应用使用。

聚合服务702对测量数据的处理是模块化并且可经由插件配置的。在示例中，示出了数据科学活动记录插件704，用于导出来自原始传感器数据(例如加速度计数据)的活动记录测量，例如睡眠持续时间、睡眠阶段数据等。然而，根据相关的传感器和测量，任何合适的聚合和处理算法都可以在聚合阶段通过合适的插件来实现，以获得聚合或导出的测量。聚合/导出的数据由插件反馈给聚合服务，聚合服务可以存储测量(例如，在数据库712/714中)，并且在聚合测量主题706下生成聚合测量事件并将该事件提交给事件系统。

聚合的测量事件由测量API 708接收并存储在测量数据库710中。如上所述，可以从测量数据库710编译和导出研究数据集以供研究者使用。

基于事件的处理流水线还可以允许链接多个处理/聚合插件(一个插件处理前一个插件的输出)。

例如图7的活动记录插件704的数据聚合插件是数据处理模块，数据处理模块在聚合服务702接收到特定的测量类型而被触发，并且使用通用测量模型，使用特定的聚合/处理算法，将该测量类型的原始传感器数据转换成指定的导出/聚合的测量。对于许多不同的研究、研究参与者、以及设备，可以提供不同的插件来同时支持不同的测量类型。

图8示出了一个示例插件，该插件用于从原始活动数据中计算步数、穿戴覆盖率(wear coverage)、以及睡眠数据。

在这个示例中，插件作为一组亚马逊网络服务(Amazon Web Service，AWS)lambda函数被实现，使用S3数据存储进行数据交换。聚合服务702将通用测量模型格式的原始测量数据上传到S3存储桶802，生成由一组lambda函数804使用的S3事件。每个lambda函数可能负责从聚合服务上传的原始数据生成特定类型的导出/聚合的数据。在上述示例中，三个lambda函数804可以负责使用合适的算法分别从原始活动记录数据生成步数、穿戴覆盖率、以及睡眠数据。每个lambda函数将其计算结果以通用测量模型格式上传到另一个S3存储桶806以获得计算数据。这再次生成由另一个lambda函数808消费的S3事件，该lambda函数808经由HTTP POST操作将导出的数据(在这种情况下，为包括穿戴覆盖率、步数、以及睡眠持续时间值的测量)发送回聚合服务702。

描述的架构允许新数据类型和/或聚合算法的新插件被简单且有效地实现和部署。然而，也可以使用其他插件架构。例如，虽然描述的插件(例如，用于数据交换的S3对象存储、用于数据处理的AWS lambda函数、以及用于传输的HTTP)的实施方式使用了特定的云计算架构，但是其他存储、处理和传输技术也可以替代。

该系统可以扩展以支持其他类型的数据源和传输，例如电子邮件。例如，一批传感器数据读数可以作为文件附加到电子邮件中，该电子邮件发送到与研究管理系统相关联的预定地址，该研究管理系统提取数据(例如，使用所述架构中的合适插件)并且将数据摄取到处理流水线中。

数据摄取流水线可以由多个服务器设备实现，将传感器数据直接导向可用的服务器实现负载平衡，并且防止特定服务器过载。

处理流水线也可以被扩展以结合报告功能，例如，从测量数据库中自动提取相关数据，并将信息放入标准的统一报告格式中。

图9A还示出了在中央健康研究管理系统中采集和处理数据的中央配置和后续操作。

配置是基于上述的模块化数据摄取子系统和模块化数据处理子系统的提供(步骤900)。此外，维护存储数据采集活动目录的数据库(901)。这包括定义可以在用户设备上执行的数据采集活动的任务定义(下文进一步讨论)，包括上文讨论的各种类型，例如，基于传感器的活动、数据输入活动、以及交互式评估。

在步骤902中，配置开始，接收要执行的健康研究的配置。这可能是由研究者使用上文讨论的配置仪表板界面创建的。该配置定义使用本系统的特定健康研究方案的实际实现。特别地，该配置指定作为研究的一部分要执行的一组数据采集活动，这些活动可以是从目录中选择的预定义的数据采集活动。为特定研究可选地或附加地定义定制的数据采集活动。数据采集活动可以对应于本文其他地方讨论的分配或分配任务(例如，分配可以包括单个数据采集活动，或可以包括作为子任务的多个数据采集活动)。每个数据采集活动旨在为研究采集各自的健康相关数据，其中健康相关数据可以包括任何健康相关信息，包括指示用户健康的数据和原始源数据(例如，用户输入、传感器数据等)，从中可以导出指示用户健康的数据。

健康研究配置还可以指定关于研究实施例的附加信息，例如，定义调度数据采集活动的调度信息、研究参与者、需要的用户设备特征(例如需要的技术能力)、传感器设备等。

在步骤903中，通过从相关数据源(例如，传感器、直接输入、或交互式评估)中选择摄取和处理指定数据采集活动的健康相关数据所需的相关服务器端数据摄取和/或数据处理插件，基于健康研究配置(包括从目录获得的任务定义)来配置数据摄取和数据处理子系统。配置步骤用于使用接口插件和/或处理插件的适当集合来配置用于数据采集活动的数据流，以便能够摄取和处理从用户设备接收的结果数据。

具体地，该步骤可以为与数据采集活动相关联的数据源(例如，特定传感器)配置数据摄取子系统的特定接口插件，以从给定源接收健康相关数据和/或处理子系统的特定处理插件，以处理来自该源的健康相关数据。例如，对于涉及步行测试的数据采集活动，接口插件可以用于从用户设备接收加速度计数据，并且处理插件可以用于处理加速度计数据以计算步态和平衡。需要注意的是，中央系统执行任何服务器端插件和处理插件的选择/配置。可以在用户设备执行附加配置，例如，配置在用户设备运行的特定传感器插件。

在步骤904中，为与研究参与者相关联的每个用户设备生成数据采集配置。数据采集配置可以是多个用户设备/参与者共有的，或在一些情况下，可以为不同的设备/参与者生成单独的配置。数据采集配置指定要在设备执行的数据采集活动(使用从目录中获得的任务定义)、数据采集活动(如下文更详细地所述)的调度(例如目标时间)、以及其他相关信息，例如，用户如何执行特定的任务或评估的指示。可以基于用户或设备的特定标准来定制配置，例如，为特定用户设备/参与者配置语言(例如，选择所需语言的教学信息、输入表单、交互式评估等)。

在步骤905中，系统从一些或所有用户设备接收结果数据。结果数据包括由数据采集活动采集的健康相关数据，并且经由配置的数据摄取子系统摄取，例如，使用用于传感器设备的特定选择插件和正在采用的其他源。在步骤906中，接收的数据被转换或重新格式化至通用测量模型中。

在步骤908中，使用配置的处理子系统(例如，包括特定选择的处理插件)处理接收的数据，以执行聚合数据或其他计算导出的测量。导出的测量包括一组与研究相关的导出的健康指标，例如，与正在研究的特定健康度量和健康结果相关的导出的健康指标。导出的健康指标可以基于来自单个源(例如，特定传感器)的数据，或者可以组合来自多个源/数据采集活动的信息。

在步骤909中，基于从用户设备获得的结果数据和/或任何相关联的导出的测量和健康指标生成研究数据集，并输出(例如，以用于存储、传输至研究者、进一步分析等)。

在某些情况下，健康研究配置可能会在研究进行期间发生变化，例如，为反映研究方案设计的变化。这种改变可以包括改变执行的数据采集活动(例如，删除、添加、或替换一个或多个数据采集活动)，修改由一个或多个数据采集活动采集的特定数据(例如，改变问卷格式)，修改数据采集活动的调度(例如，执行这些活动的时间和/或频率)，或改变服务器端处理(例如，添加、改变、或删除从结果数据计算的导出健康指标，或改变应用的处理算法)。如果发生这种情况，则系统在步骤907接收研究配置中的变化，并且根据需要重新配置数据摄取/处理子系统(步骤903)和/或根据需要生成被发送到一个或多个用户设备的更新的数据采集配置(步骤904)。在重新配置之后，系统继续接收和格式化结果数据(步骤905、906)，并且计算导出的测量/健康指标和生成研究数据集(步骤908、步骤909)可以基于在重新配置之前和之后接收的结果数据，允许在研究正在进行的同时调整研究设计。

研究管理系统可以支持多个并发的健康研究。因此，可以重复上述过程，以为多个健康研究中的每一个配置服务器端架构和相应的用户设备群，并且同时操作对这些研究的数据的采集和处理。

为了支持广泛的测量列表、设备集成、以及其他任务，使用统一的“任务定义”模型来定义可以在用户设备执行的数据采集活动。该模型配置传感器读数、分配级决策、遵从性阈值、分配时间以及用户如何与分配进行交互，并且无论使用哪种特定类型的用户设备，都以相同的方式工作。

该任务定义模型包括用于表示分配任务(例如，特定数据采集活动)的数据结构，该分配任务包括其中存储各种配置值的“选项(options)”字段、任务标识符、运行任务或在完成任务过程中向用户提供指导所需的外部文件(例如，为URL/URI)、以及运行任务本身所需的信息，例如：

·用于基于传感器的任务的传感器(或用于其他类型的任务采集的数据)的定义；

·随着传感器读数的进行，将显示给用户的用户界面屏幕的定义；

·为涉及直接输入健康数据值(例如在问卷中)的任务获得的输入值的定义，例如，通过定义用户输入表单/字段和相关联的用户提示；

·在用户设备运行的交互式评估的定义。

在由中央系统生成的配置包中指定数据采集活动，并且使用上述任务模型作为任务定义传输给用户设备。在优选实施例中，所有任务定义都是设备不可知的。对于目录中预定义的任务，任务定义优选地也以这种格式存储在目录中。从目录中选择后，配置可以直接从任务定义中生成，或如果需要的话，任务定义可以由研究者定制。

移动应用的配置和调度

移动应用是高度可配置的，以支持不同的研究，并且可以摄取由中央系统提供的专用配置包，以生成调度的分配、传感器读数、以及通知的持续流(ongoing flow)。

除经由任务定义指示移动设备如何运行分配外，该配置还指定调度信息，该调度信息由应用的调度引擎解释以基于事件的方式动态地调度分配，其中传感器读数、用户特定的医疗条件、以及外部事件可以改变分配的流程。虽然解决该问题的一种方法可以是将所有可能性发送到客户端并将所有处理卸载到移动应用，但是由于用户设备的带宽和处理能力的限制，这种方法可能是有问题的。优选实施例解决这些问题和其他技术挑战，例如：

·运行移动应用的任何智能手机或其他用户设备应该优选地能够为任何用户运行用于处理任何分配的任何调度。整个系统优选地是完全可配置的。

·由于移动应用可配置为与任何研究配置一起工作，并且可以动态地使任务对用户可用，因此配置应该优选地包含基于分配结果的动态调度的所有信息、需要基于用户输入、传感器数据、或用户条件做出的决策的信息、以及应该如何做出这些决策的信息。此外，移动应用可以摄取研究方案参数，以确定特定的分配的结果是否符合。

·该配置优选地可由研究协调者远程更新，并且用户设备优选地能够在相对较短的时间内(例如一天内)远程检索和摄取新的或修改的方案参数。

·然而，还需要能够服务于低带宽、低连通性区域。因此，复杂配置优选地满足严格的大小要求，并且可以被压缩成相对较小的配置包，例如，在优选的中，配置包的大小不超过5kB。

·为了确保方案遵从性以及支持成功的临床研究，可能需要对任务进行近乎实时的远程监控。因此，应用优选地生成全面的审计跟踪，审计跟踪解释应用做出的所有决定、所有遗漏的和完成的分配、以及用户操作，被传输到中央研究管理系统进行监控。审计跟踪的传输也受到严格的尺寸要求的限制，以服务于低带宽、低连通性区域。

·所有分配优选地以时区无关的方式调度，因为分配受到外部事件(例如用药时间)的限制。使用标准日期/时间格式(例如，存储和处理日期的ISO 8601标准)表示时间可能会导致困难。因此，优选实施例使用另一种格式来定义时间，以允许生成动态日期，以使如果用户正在改变时区或改变其日常事务，则客户端包含描述如何处理这些变化行为的指令集。

提出的解决方案允许对分配运行的方式和时间进行高效和可配置的管理，同时还支持生成审计跟踪。通过创建虚拟的动态分配调度来满足低带宽环境中复杂的逻辑需求。调度由配置包中的调度数据指定，并由调度解析器解析，以生成任何可配置的分配集和相关联的数据采集活动。

移动应用的配置和后续操作如图9B所示。

在步骤910中，移动应用在用户设备运行。该应用根据对应于不同类型的数据采集活动的多种不同的数据采集模式提供数据采集功能，包括基于传感器的数据采集、通过直接用户输入的数据采集、以及运行交互式评估。

在步骤911中，从中央研究管理系统的移动应用接收包括任务定义和调度数据的配置数据包。调度数据定义要在用户设备执行的数据采集活动的调度。数据采集活动可以包括形成分配的一部分的任何类型的任务(例如任务定义中定义的任务)，包括被动传感器数据测量或指示用户执行活动(例如步行)并且在活动期间获得传感器数据的任务。如上所述，数据采集活动还可以包括请求和获取用户输入(例如症状问卷等)以及运行交互式评估。

在步骤912中，解析调度数据并且确定数据采集活动的调度。在步骤913，基于特定数据采集活动和调度数据集来配置移动应用。需要注意的是，数据采集活动的目标时间可以完全以绝对值或能在最初执行调度时解决的形式指定。然而，如下所述，该系统还支持动态解析的调度时间，由此数据采集活动(以及例如通知或数据上传的其他动作)的目标时间相对于特定事件的发生来表示，动作的实际目标时间仅在检测到该事件后确定。因此，对于这样的数据采集活动，最初生成的调度包括未解析的、动态确定的目标时间(如下更详细地所述，以基于事件的时间戳的形式)，目标时间将在稍后的某个时刻解析为具体的定时(concrete timing)。

在调度之后，数据采集应用根据确定的调度执行数据采集活动。这包括对每个调度的数据采集活动，基于调度数据识别(步骤914)执行给定的数据采集活动的目标时间(这可以在调度阶段确定，但是对于任何动态的基于事件的时间戳，一旦时间戳被解析，例如，以响应于检测到的时间戳的触发事件，则发生识别)，以及识别要从中获取数据的相关数据源(例如，用于基于传感器的数据采集活动的传感器)。

在步骤915中，在相关的目标时间启动数据采集活动，然后，在步骤916，基于指定的数据采集模式执行数据采集活动，以获取健康相关数据。例如，对于基于传感器的数据采集活动，在数据采集活动的执行期间从识别的传感器获得传感器数据。该步骤可以包括向用户提供指令以执行动作(例如，完成步行测试、使用例如肺活量计等的外部传感器设备等)，并且获得的传感器数据可以包括来自单个传感器的单个读数(例如温度测量)、来自单个传感器的多个读数(例如，在指定时间段内的加速度计的多个读数)、或者来自一组多个不同传感器中的每一个的一个或多个读数。对于直接数据输入活动(例如症状问卷)，应用显示配置中指定的输入表单，并获取一组指定的健康相关数据值的用户输入。对于交互式分配，该分配由移动应用运行，并且记录用户交互，并且从检测到的用户交互中导出健康相关数据(例如，通过测量响应时间、响应准确性、或如上所述的交互的其他合适特征)。

在步骤917中，应用采集由数据采集活动生成的健康相关数据，并将其临时存储在用户设备的本地数据库中。在步骤918，将获得的健康相关数据作为结果数据发送到中央研究管理系统。如本文其他地方所述，这可以包括在批处理传输中传输来自多个数据采集活动的数据和/或在调度的时间(该调度的时间可以基于动态的基于事件的时间戳来预定)或基于网络连接来执行传输。可选地，一旦来自数据采集活动的结果数据可用，则可以以接近实时的方式传输该结果数据。可选地，一些客户端预处理可以应用于由数据采集活动获得的健康相关数据，以获得传输的结果数据。

需要注意的是，确定目标时间、启动和运行数据采集活动、以及采集和传输数据的步骤(步骤914至918)可以在健康研究的持续时间内重复发生。例如，如调度数据中指示的，给定的数据采集活动可以周期性地重复(例如，每周、每天、或一天多次)。如果使用批量传输，传输步骤可以以不同于数据采集活动的频率发生(例如，传输一批一天内获得的所有结果)。

在健康研究期间，如果从研究管理系统接收到更新的配置数据(例如，在如上所述的研究方案改变之后)，则移动应用更新本地存储的配置并相应地重新配置应用(根据步骤911至913中的每一步)。重新配置可以修改执行的数据采集活动、相关联的调度等。然后，数据采集根据更新的配置继续进行。

根据活动的类型，数据采集活动的启动可能采取不同的形式。例如，在一些情况下，数据采集活动可以由用户设备在确定的目标时间自动执行(例如，在不需要用户交互的情况下)。这可以是包括无用户参与的被动传感器数据采集的任务情况。对于其他活动，可以在确定的目标时间在用户设备提示用户开始数据采集活动，例如，通过应用内或应用外的通知(例如系统级推送通知)。选择通知可以启动应用和/或应用内的相关数据采集活动。作为另一个示例，数据采集活动可以在确定的目标时间可用，以供用户经由显示在用户设备的菜单进行选择和启动(例如，该活动可以被添加到应用中的即将到来的任务的菜单中，或任务的状态可以从不活动变为活动并且在菜单中变得可选择)。在这些情况下，启动可能因此发生在调度的时间(通过某种形式的用户提示)，但是可能需要进一步的用户交互来开始执行数据采集活动。无论如何启动(无论是完全自动还是在用户控制下)，一旦数据采集活动本身开始，则任何相关指令、用户输入表单、或交互式评估屏幕都会显示在用户设备上，并且应用会从相关来源捕获健康相关数据。

基于事件的时间戳

如上所述，传统的时间戳(例如ISO 8601或Unix时间戳)通常不允许动态调度。因此，实施例使用不同的方法来指定用于调度活动的定时信息。

基于时间量、时间单位、以及一个或多个触发事件被指定定时信息。时间量、时间单位、以及一个或多个触发事件定义基于事件的时间戳。通过检测与指定触发事件匹配的事件(或如果指定多个可选触发事件，则检测指定事件之一)来确定时间戳的参考时间。事件时间(例如，事件的接收或创建时间，可以由事件的事件时间戳指定)定义解析时间戳的参考时间。然后，通过将指定的时间量(根据需要基于指定的单位转换的所需的时基(timebase))添加到参考时间来解析时间戳的目标时间。该解析的目标时间被存储为时间戳的一部分，并且随后可以被引用并用于启动调度的数据采集活动(例如，特定的分配或分配任务)或触发通知或其他动作。下面列出了用于存储动态的基于事件的时间戳的示例数据格式：

表1基于事件的时间戳模式

解析包括通过将“amount”和“unit”字段指定的时间段添加到参考时间(触发解析的时间，即检测到相关触发事件的时间)来计算绝对时间值(例如，作为传统的ISO 8601时间戳或类似的时间戳)。例如，这可以被计算为通过检测“from”中指定的触发事件确定的参考时间，加上时间“amount”乘以解析为一些基本时间增量(例如毫秒)的时间“unit”。因此，“amount”和“unit”字段一起指定相对于触发事件的相对时间量(或者说，延迟周期)，该时间量在触发事件发生时被解析为绝对时间(resolvedDate)。解析的时间可以是用户设备的本地时间或世界时格式，例如协调世界时(coordinated universal time，UTC)。

触发事件优选地是从预定义事件的可扩展集合中选择的特定命名事件。该系统支持一系列事件类型和来源，例如包括：

·对应于传感器测量的传感器事件；特定传感器事件可以指示从特定传感器获得的任何测量，或可以指示满足特定标准的测量，例如预定的传感器值阈值；

·用户输入事件，例如，定义接收预定的用户输入或激活应用中的特定命令或菜单选项(例如，用户确认该用户已服用药物)；

·识别用户设备或移动应用的状态或状态变化的状态事件，例如，识别网络连接的丢失或恢复、电池状态等；以及

·定时事件，例如，可以在每天或每周开始时生成一个事件。

·由中央研究管理系统生成并通过通信网络传输到用户设备的事件(例如，指示中央系统的状态或状态变化、研究配置的变化、在传感器数据的服务器端处理期间检测的数据质量问题等)。

在适用的情况下，事件可以包括与事件相关联的附加数据(例如，从传感器获得的传感器数据、用户输入、或设备状态信息等)

在临床研究和其他健康监测活动的背景下，基于事件的时间戳的一些具体示例包括“服药后1小时(1hour after taking medication)”、“<特定传感器读数阈值>后35分钟(35minutes after<specific sensor reading threshold>)”、或“午夜后7小时(7hoursafter midnight)”。

因为事件可以源自可扩展的源列表，所以实现时间戳解析很有意义。例如，一些事件可以包括主动输入，例如用户输入或传感器读数，而其他事件则完全是被动的，例如移动应用不在线的某段时间。事件优选地也与研究配置相关联，以确保仅处理相关事件，例如，特定传感器读取事件只有在特定传感器被配置用于当前配置的研究时才会发生。为了支持这些事件，系统提供了一个事件处理流水线，可以主动和被动地更新许多不同事件的状态。

另一个问题是确定何时应该评估这些时间戳。在优选实施例中，同一事件有可能被多次触发，并且由于支持被动事件，接收事件的系统被设计成无状态的。因此，在事件触发之前或之后的任何给定时间，都会静态评估时间戳。未来时间戳(触发事件尚未发生)会自动被视为“unresolved”，这是一种定义的状态，会被跟踪和管理直到解决为止。

这些动态解析的基于事件的时间戳用于解析分配启动和到期时间，调度推送和SMS通知、触发单个数据采集活动(例如获取传感器读数)，以及将传感器数据从移动应用上传到研究管理系统。然而，该系统可以被扩展以允许时间戳被用来触发任何编程动作。

例如，给定的分配通常与指定启动时间的基于事件的时间戳相关联，也就是说，分配变为“活动(active)”(可供用户完成)的时间。一旦时间戳被解析并且解析的时间出现，则移动应用提示用户现在应该执行分配。分配还可以接收未来的“完成时间(completeby)”时间戳，然后被相应地跟踪。一旦时间戳的时间出现，则可以基于分配的状态进行和处理额外的评估(例如，以注意到分配现在已经过期)。

虽然设计为允许指定动态解析的目标时间，但时间戳也可用于指定静态目标时间。例如，目标时间本身可以在创建时间戳时在resolvedDate字段中被指定。在这种情况下，时间戳在创建时被有效地解析，而不需要在以后动态地解析该时间戳。如上所述的另一个示例，可以在“unit”字段中指定特殊的上下文变量或函数调用，以提供不是基于事件的时间参考。

图9C详细地示出了调度和时间戳解析子系统。子系统包括调度服务920和事件时间戳服务922。

此外，外部服务924生成可触发时间戳解析的各种事件。在本文中，移动网络接口950、传感器数据接口952、以及用户输入954被显示为可能的事件源，但是这些仅是示例性的，并且任何子系统或外部系统原则上都可以生成事件，这些事件通过向事件发布接口946发送事件通知或消息来发布到事件处理子系统，事件发布接口946管理与特定事件主题944相关联的事件。事件消息标识事件，并且该事件可以包括与事件相关联的任何数据内容(例如，测量事件的传感器数据)。事件消费者可以在事件处理系统中订阅特定的事件主题。当事件被发布到存在订阅者(例如，移动应用的特定软件组件)的事件处理系统时，事件处理系统在对应于接收的事件消息的事件通知或消息中通知订阅者，并且识别事件并且该事件包括与事件相关联的任何数据。然后，订阅者可以处理该事件和相关联的数据。

需要注意的是，包括的事件处理系统可以包括在移动应用中或与移动应用分开在用户设备中，并且可以与在中央系统实现的事件处理系统(例如，用于控制数据处理流水线的)分开，或可以集成到该中央事件处理系统中，以允许在中央系统生成事件并在移动应用中消费事件，从而触发时间戳解析。如果没有集成，则优选地提供单独的机制，该单独的机制允许事件从中央研究管理系统传输到移动应用。

调度服务920从在移动应用处接收的配置包接收调度数据，定义特定研究的分配和数据采集活动。具体而言，调度定义统称为动作的一组分配和相关联的数据采集活动以及用户通知，与定义执行每个特定动作的时间的相应基于事件的时间戳相关联(例如，调度的动作可以是主动的分配任务，例如，在其期间采集传感器读数的步行测试、被动传感器数据采集、用户问卷等。)调度数据由调度解析器926处理。在步骤928中，调度服务准备调度下一个动作(调度中指定的每个动作在实践步骤928至步骤932是重复的；为了清楚起见，示出了单个动作的处理)。

在步骤930中，调度服务确定时间戳是否已经被解析(例如，时间戳可以简单地是具有如上所述的创建时指定的绝对解析时间的静态时间戳)。如果时间戳已经被解析，则在步骤932中，在指定的时间调度动作。例如，调度服务可以维护要执行的动作的调度表，该调度表具有要执行这些动作的解析目标时间。然后，调度服务将调度中指定的动作和时间戳的解析时间存储在表中。执行服务(未示出)监测调度表并且在指定的时间启动指定动作。例如，对于对应于分配任务的动作，系统启动相关任务(例如，提示用户执行步行测试并记录相关传感器数据)。对于通知动作，系统发起通知(例如，通过与用户设备的推送通知服务或与SMS/电子邮件或其他消息服务接口)。

如果在步骤930中确定时间戳尚未被解析，则经由事件订阅接口934将时间戳提交给动态解析的事件时间戳服务。接收到未解析的时间戳时，事件时间戳服务922首先确定时间戳是否是静态的(步骤936)。静态但未解析的时间戳是指解析的时间不依赖于事件，但可以根据时间戳中的信息计算，例如，根据“amount”和“unit”字段计算。如上所述，“unit”字段可以指定绝对时间单位(例如毫秒)或可以提供动态可计算的时间参考。在上文给出的示例中，unit可以是“$day”，其中“$”符号表示可计算的时间参考(例如，作为外部函数或上下文变量的参考)指定当前周的日期，而“amount”字段指示日期，(amount＝2，unit＝“$day”)解析为当前周的星期二。这种时间戳仍然参考外部函数或上下文变量来解析，但是因为这种时间戳不依赖于特定事件的发生，所以这种时间戳仍然是静态的。这些事件在调度时被解析，并且可以例如由“from”字段中的特殊值来表示，例如“isStatic(是静态的)”。因此，在步骤936中，如果识别出静态时间戳，则在步骤938中通过基于“amount”和“unit”字段中的信息计算作为UTC时间戳的绝对目标时间值来解析时间戳。然后，这被返回到调度服务920，以如前所述在步骤932调度动作。

如果事件不是静态的(步骤936)，这意味着时间戳解析由特定事件触发。事件在“from”字段中指定。因此，事件时间戳服务在步骤942中为指定的事件(事件主题944)创建事件主题消费者。事件主题消费者本质上是对事件处理系统中指定的事件的订阅。此时，假设与触发事件匹配的事件还没有被发布到事件处理系统，时间戳的解析是未完成的，等待相关事件的检测。在检测到触发事件之前，时间戳保持未解析状态(并且因此，不会调度任何相关的数据采集活动或其他操作)。

一旦事件发布接口946产生与在步骤942创建的事件消费者匹配的事件(并且因此与触发事件匹配)，则事件消费者接收该事件并在步骤940触发时间戳解析的完成。解析的参考时间事件的时间决定。系统将“amount”和“unit”字段指定的时间段(例如2天、4000毫秒等)添加到参考时间，以确定解析的目标时间。这存储在时间戳的“resolvedDate”字段中，例如作为UTC时间戳。然后将解析的时间戳返回到调度服务，调度服务如前所述地(例如，通过将动作和时间戳添加到调度表)更新调度以调度与时间戳相关联的动作(步骤932)。

上述时间戳解析还考虑了在解析时间戳时的夏令时(daylight saving time，DST)。可能出现的一种特殊情况是，参考日期在夏令时转换的一侧，而目标日期在夏令时转换的另一侧。例如，切换到DST当天午夜后的11小时应该是上午10点，而不是通过简单地添加时间偏移量获得的上午11点。

为解决这个问题，系统还从参考日期和目标日期获得DST偏移量，找到两者之间的差异，并应用该差异以获得正确的目标时间。如果偏移量相同，则不会对目标时间进行校正。

本文描述的调度服务和时间戳解析系统可用于调度数据采集活动(例如分配和任务)，以及调度给用户的通知。

此外，调度服务可用于调度数据传输。例如，不是简单地在完成分配/任务时将数据传输到服务器，而是可以在用户设备采集数据，并且在由动态或静态的时间戳指定的预定时间批量传输。这允许优化带宽利用(例如，在非高峰时段传输结果)。

研究配置结构

在一些实施例中，数据采集活动在研究配置中被构造为虚拟访问和分配。虚拟访问(提供虚拟模拟，例如，在常规研究期间，患者访问医学研究者、诊所、或其他医疗从业者进行评估)可以包括一个或多个分配。每个分配又可以被构造成一个或多个任务，对应于不同的数据采集活动。因此，分配可以定义为完成该分配的任务的特定工作流。该调度还可以包括通知和重新调度访问的配置。这些调度组成部分将在以下部分详细描述。

上述访问级配置(visit-level configuration)提供在哪一天运行分配和采集传感器数据的指令。该指令根据一个循环周期来定义，该循环周期通过使用基于事件的时间戳(例如“每1天(every 1day)”或“每2周(every 2weeks)”)来定义该周期循环的开始和结束日期，以及从周期的开始或结束(即“在该周期的第4天(on the 4th day of theperiod)”)偏移的“虚拟访问(virtual visits)”列表。以这种方式，移动应用的调度服务可以仅用很小的信息组动态地生成调度的“virtual visits”的大量的日程安排。

上述分配级配置(assignment-level configuration)提供关于给定的“virtualvisits”流程的指示。该给定的“virtual visits”由分配流组成，分配流为运行当天分配的状态引擎提供配置。每个任务包含：

·独立的“启动(launch)”和“到期(due)”事件时间戳(例如“上一分配完成后45分钟(45minutes after the previous assignment is complete)”)移动应用使用它来确定任务当前是可用的(基于“launch”时间戳)还是过期的(遗漏的(missed)，基于“due”时间戳)。系统至少支持以下处理这些时间戳的方法(可配置为调度的一部分)：

ο独立地解析这些时间戳，使得即使其启动条件的先例从未发生，也可以通过其“due”时间戳将分配解析为“missed”。

ο根据彼此解析这些时间戳，使得如果分配的启动条件的先例从未发生，则该任务被标记为不适用(not applicable，N/A)，并且不会是遗漏的。

·用于基于用户特定条件(例如，特定医疗状况的存在/不存在)或用户设备能力(例如，分配/任务需要的特定集成的传感器或连接的传感器设备的可用性)来确定特定的分配集、任务、或传感器读数是否适用于当前用户的条件。

·遵从性度量，遵从性度量为如何完成任务设定了附加规则。一些示例可以是从第一次分配开始时开始的时间限制，或需要时指示用户分配之前服用或未服用药物的读数。

·任务列表，连接到应该可以在启动到期窗口中完成的任务定义。例如，任务列表可以包括步行测试和症状问卷。

通过使用基于事件的时间戳和多种条件类型，包括基于用户输入、传感器读数、以及其他因素的条件，该系统能够实时动态地创建和更新分配调度，以确保每个患者符合适用于该患者的研究方案。

通知级配置使用基于事件的时间戳来触发向移动设备发送本机推送通知。上述优选地是完全基于事件的，并且可以通过事件时间戳服务以相同的方式由不同的条件和事件触发分配及其数据采集活动。

在优选实施例中，除了本地推送通知之外或代替本地推送通知，应用可以调度其他类型的通知，例如电子邮件或SMS。如果特定的调度请求额外的通知类型，应用可能会尝试通过web API来调度这些通知类型。通过web API，web服务将按类型处理通知并且调度发送。应用可以经由同一API上的不同端点取消调度这些通知。

重新调度级别的配置使用基于事件的时间戳和调度中的“重新调度的最大次数(maximum times to reschedule)”字段，将一整天的“virtual visits”重新调度到某个后续的日期，同时保持符合研究方案中定义的参数。从所有实例跟踪所有结果，并生成清晰的审计跟踪，将所有重新调度的传感器数据连接回原始“virtual visits”。

以下伪代码示出了虚拟访问的重新调度：

示例4

如伪代码所示，系统跟踪访问被重新调度的次数，并且只允许重新调度有限的次数(该次数特定于配置)。

任务结果

无论源设备或传感器如何，来自分配任务(即数据采集活动，例如传感器测量、用户数据输入、交互式分配等)的结果在统一的包装器中发送，该包装器包含“执行ID(Execution ID)”，该ID根据以下参数将结果链接回该结果来自的调度：

·调度ID(Schedule ID)

·访问日期(Visit Date)

·分配索引(Assignment Index)

·任务键(Task Key)

·重新调度的次数(Times Rescheduled)

这些结果连同调度可以用于在任何给定的时间确定用户需要做什么、用户还没有做什么、以及任何过期的事情。

图10A至图10C使用上述配置的各种不同方面，更详细地示出了一个实施例中在移动应用/用户设备运行的调度服务的操作。

图10A显示了访问和分配日期的计算。在步骤1002，调度服务从调度web服务器1004获取更新的调度。如果接收到更新的调度(决策1006)，则这些调度被本地存储在调度数据库1008中。因此，这些步骤允许研究者在研究期间改变调度，用户设备的本地调度根据需要更新。在更新之后，或如果没有更新的调度，过程继续到步骤1010，其中从调度数据库中读取一个或多个调度以调度访问和分配。

在步骤1012中，从调度计算分配日期。这包括使用如上所述的基于事件的时间戳服务来解析任何未解析的动态的基于事件的时间戳。例如，调度可以为特定的分配(或分配任务)指定基于动态事件的时间戳，(一旦触发事件发生)时间戳服务提供与动态时间戳相对应的绝对UTC时间戳(absolute UTC timestamp)，该时间戳被添加到调度。

在步骤1014中，调度服务确定是否存在过期任务(即，尚未完成且其到期日期已过的任务)。如果存在过期任务，则在步骤1016将这些记录为遗漏的结果。如果分配是预定访问的一部分，则调度服务确定是否可以重新调度访问；如果可以重新调度访问，则该过程返回到步骤1012以计算新的分配日期。如果不可以重新调度访问，则简单地将分配标记为未完成，并且过程继续到步骤1018。还可以调度(或立即生成)一个或多个通知，以通知用户(例如，患者和/或研究者)遗漏的任务。

尽管在这些示例中，分配被描述为访问的一部分(其中，访问可能包括多个分配)，但是需要注意的是，分配可以在没有访问的情况下发生。例如，一些分配可能需要由用户在访问发生之前完成(根据协议要求)。因此，分配可以作为访问的一部分或独立地被调度(如果需要的话则重新调度)。

如果没有过期的任务(1014)，过程继续到步骤1018，以计算预定期间(例如在接下来的30天内)的即将到来的访问日期。在步骤1022中，确定用户对即将到来的分配的资格。例如，这可以包括确定：

·用户是否满足特定的分配或任务需要的特征，例如，是否存在特定的健康状况。

·用户设备是否符合要求的技术特征(例如，分配或任务需要的传感器的可用性)。

如果基于指定的适用性标准，分配对用户不适用(1024)，但是当前有效，也就是说可用于完成(启动日期已过，到期日期尚未过，检查1026)，则记录“不适用(notapplicable)”结果(步骤1028)。

应该注意的是，如果在未来调度的分配(不是“active”)目前不适用，则该分配也可能在调度的时间之前变为适用，因此在这种情况下，此时不会记录“not applicable”的结果。但是，如果分配是活动的(可用的)但被视为不适用，则记录“not applicable”结果。

如果分配适用于该用户/用户设备，则过程继续到步骤1040(图10B)。

图10B示出了调度过程的其他步骤。在步骤1040中，调度即将到来的通知(例如，向用户推送通知以提醒用户特定的访问/任务何时到期等)。这再次使用时间戳服务来解析动态时间戳。

在随后的步骤1042至步骤1048，基于预定的分配的预定时间来执行预定的分配。

在步骤1042中，系统确定分配是否是活动的(即如上所述可用于完成的)。这种分配在用户界面中显示为可选择的，其中，分配可以被扩展以显示组成的任务，并且分配/任务可以通过用户选择来激活以启动分配/任务(步骤1046)。虽然不活动的(即未来的)分配可以被显示但不能与之交互(例如，上述分配变灰)，但是显示上述分配以向参与者提供其在未来几天中需要做什么以及何时做的视图(步骤1044)。

在步骤1048中，用户完成分配的任务。任务的结果(例如传感器测量)被传输到结果服务(如图10C所示，并且如下讨论)。在步骤1050，调度服务确定分配的所有任务是否已经完成。如果没有完成，过程返回到步骤1002，继续调度和任何新分配/任务，以及继续执行当前分配的现有任务，直到分配被识别为完成。

如果确定分配的所有任务都已完成，则通过取消调度“遗漏(miss)”通知和调度指定分配已完成的通知(例如对患者和/或研究者)来更新分配的通知(1052)。

在步骤1054中，该过程确定访问的所有任务是否已经完成。如果没有完成，该过程重复上述的调度和分配循环。如果已经完成，随后则类似步骤1052，在步骤1056调度通知，包括取消调度指定遗漏或访问未完成的任何通知，以及调度指示访问完成的一个或多个通知。然后，该过程重复调度循环，以调度未来的访问/分配。

在上述示例中，调度发生在访问/分配级别。根据调度信息(例如，基于事件的时间戳)，一旦虚拟访问的特定的分配到期，则该分配的所有子任务都到期。然而，在可选的方法中，可以使用相同的基于事件的调度机制来单独调度子任务。

一旦分配/任务的预定时间到达，则该任务可以自动执行(例如，对于被动传感器数据采集任务，系统可以在预定时间自动开始传感器数据采集)。对于不能自动执行的交互式任务，例如，通过生成通知和/或生成并输出用于该任务的适当用户界面(例如，活动指令或问卷界面)，提示用户执行该任务。如上所述，移动应用可以显示供用户选择的“active”分配和子任务的列表，并且响应于选择显示分配/任务的任何进一步需要的指令或界面。然后，一旦任务已经完成用户就进行确认，或提交适于任务的正在输入的任何信息。

图10C示出了结果服务的操作。在步骤1060中，结果服务等待新的结果(例如，新的结果可以是由步骤1048生成的已完成任务的结果、或指示遗漏的任务(1016)的结果、或指示不适用的任务(1028)的结果(其中特定任务被识别为不适用于特定的用户/设备)。接收的结果存储在结果数据库(1068)中，并最初标记为未发送。过程1062从结果数据库读取新接收的结果，并且将结果发送到结果网络服务器1070(形成中央研究管理系统的一部分)。可以基于如前所述的批量传输标准来累积和批量传输结果。一旦从结果web服务器接收到接收确认(测试1064)，则结果在结果数据库中被标记为已发送(步骤1066)，并且最终可以被删除。该进程继续监测数据库中未发送的结果，并将尝试重新发送尚未收到确认的结果。该过程可以确保一旦任务完成，即使存在传输问题(例如，由于有限的带宽或间歇性连接)，结果数据(例如传感器数据、问卷输入等)也能被正确地从移动应用上传到中央系统。

在服务器端，还可以解析调度以查看用户应该做什么。如果没有明确的未完成/完成等任务的状态，系统将任务显示为“待定(outstanding)”，指示用户设备可能离线，并且系统期望到现在已经从用户设备接收到结果数据。研究协调者可以使用这一提示联系患者以查看是否有能被解决的任何问题(如连接问题)。

这种方法不仅仅处理传输问题，因为该系统还能够跟踪预期的结果和时间并且能够提醒研究协调者结果采集的状态。这种方法为系统和研究协调者提供了研究进展和实现数据采集目标过程中的任何问题的高度可见性。系统还可以区分完全遗漏(例如，患者未完成任务)和系统未接收数据(例如，由于连接问题)。

时区处理

该系统可以提供在整个应用中启用适当时区处理的功能。在一个实施例中，当用户注册时，其提供存储在数据库中的时区。然而，这个时区每天都在变化。在严格监管的环境中，系统能够在对象在系统中的整个生命周期中自动应用其适当的时区是有用的，但是时区数据的恒定馈送通常不能从用户设备获得。

各实施例实现了处理时区的分层方法。构建时区日历可以清楚地识别用户所在的时区，这可以容易地在可穿戴设备上回填和验证。它考虑了设备的可靠性，无论是否佩戴/使用设备，并且能够创建一系列后备时区，最后一个时区是在受试者注册时输入的时区。这允许不知道用户位置的系统从用户设备及其外部设备识别时区。

该系统能够向最终用户的设备发送时序要求严格的文本/电子邮件通知。当时区数据不可靠时，保证能够在与用户当前位置和时区相关的精确时间发送通知变得具有挑战性。该系统从可用设备和外部设备编译时区数据，以便正确调度通知和分配。该系统还能够经由这种方法调度时序要求严格的传感器数据采集窗口。在可能的情况下，该系统依赖于智能手机上的本地通知，这些通知由调度、移动分配、或外部设备生成。

计算机系统

图11示出了用于实现描述的过程和技术的计算机系统的元件。图11示出了一个代表性的用户设备104，例如智能手机(尽管实际上该系统将包括许多这样的设备)，以及用于实现研究管理系统的各种功能的数据采集服务器1100。

用户设备104包括一个或多个处理器1102以及用于存储临时数据和被执行的软件代码的易失性/随机存取存储器1104。

网络接口1106(例如，Wi-Fi和/或用于经由移动通信网络通信的蜂窝接口)被提供用于通过一个或多个网络(例如，局域网或广域网，包括互联网)与其他系统组件(包括服务器1100)通信。

用户设备的内部传感器1108可以包括例如加速度计、陀螺仪、红外传感器等。用户设备还可以包括有线和无线外部传感器接口，例如USB接口或无线本地接口(例如蓝牙或NFC)。需要注意的是，在一些情况下，外部传感器设备也可以经由网络接口1106(例如支持Wi-Fi的传感器设备)进行通信。

永久存储器(persistent storage，也称为持久存储器)1120(例如，以闪存或固态硬盘(solid-state drive，SSD)存储器的形式)永久地存储用户设备使用的软件，包括移动应用106、传感器API 1116、以及移动应用API 1126(后者可选地被认为形成应用本身的一部分)。移动应用可以被构造成子组件，包括例如用于调度分配和数据采集活动、通知、数据上传、以及其他动作的调度引擎1112，以及用于执行调度的分配、任务、以及数据采集活动的任务执行引擎1114。永久存储器还存储由移动应用使用和产生的数据，包括配置数据1122(例如，研究配置和相关联的调度数据)和采集的结果数据1124，例如，传感器数据、用户输入数据、以及交互式评估数据(其可以被临时存储，然后在如上所述的批处理中上传到服务器1100)。永久存储器还包括其他用户设备软件和数据(未示出)，例如设备操作系统。

用户设备将包括本领域技术人员已知的其他传统硬件和软件组件(例如用户界面元件，例如触摸屏和按钮)，并且这些组件通过数据总线互连(这实际上可以包括几条不同的总线，例如存储器总线和I/O总线)。

数据采集服务器1100包括一个或多个处理器1030以及用于存储临时数据和正在执行的软件代码的易失性/随机存取存储器1032。

提供一个或多个网络接口1034，用于通过一个或多个通信网络与用户设备、外部/第三方系统、以及其他系统组件进行通信。

永久存储器1036(例如，以硬盘存储器、光存储器、SSD存储器等的形式)永久存储器用于管理临床研究和相关联的数据采集活动的服务器软件。这包括研究管理系统1044，用于配置研究，并基于采集和处理的数据(包括上述各种配置和管理仪表板)生成研究数据集，以及实现数据摄取流水线的各种元件，例如数据采集API和插件1038、数据处理/聚合插件1040和用于管理基于事件的数据摄取流水线的事件处理系统1042。

永久存储器还包括由软件使用和生成的数据，例如接收的结果数据和处理/导出的数据1046，以及研究配置和用户数据(未示出)。

永久存储器还包括其他服务器软件和数据(未示出)，例如服务器操作系统。服务器将包括本领域技术人员已知的其他常规硬件和软件组件，并且这些组件通过数据总线互连(这实际上可以包括几条不同的总线，例如存储器总线和I/O总线)。

虽然以示例的方式示出了特定的架构，但是可以采用任何适当的硬件/软件架构。

此外，被指示为单独的功能部件可以被组合，反之亦然。例如，数据采集服务器的功能可以分布在多个计算机设备上，每个计算机设备处理处理任务的子集和/或从用户设备群接收的数据的子集(根据需要实现负载平衡)。作为具体示例，研究配置和/或接收/处理的结果数据可以存储在服务器1100可访问的单独的数据库服务器中。类似地，用户界面功能(例如，配置仪表板)可以由单独的web服务器实现。

功能可以以任何合适的方式分布在系统元件之间；例如，显示为在用户设备执行的一些处理任务可以在服务器上执行，反之亦然。

需要理解的是，上文已经仅通过示例的方式描述了本发明，并且可以在本发明的范围内进行细节的修改。

需要注意的是，术语Amazon^TM、亚马逊网络服务、S3、Apple^TM、AppleHealth^TM、HealthKit^TM、蓝牙、以及Wi-Fi是注册商标，应在本文中按照注册商标理解。

本发明的各方面和各特征在以下编号条款中阐述。

1.一种在用户设备执行的用于获得健康相关数据的计算机实现的方法，所述方法包括：

在所述用户设备运行用于获得所述健康相关数据的数据采集应用，所述健康相关数据包括指示用户健康的数据和可从中导出所述指示用户健康的数据的源数据中的一个或多个，其中，所述数据采集应用用于支持多种数据采集模式中的数据采集，所述多种数据采集模式包括基于传感器的数据采集模式，所述基于传感器的数据采集模式用于从包括在所述用户设备中或与所述用户设备通信的一个或多个传感器接收所述健康相关数据，以及以下模式中的至少一个：

用户数据输入模式，所述用户数据输入模式用于基于用户输入的一个或多个健康相关数据值的可配置集合获得健康相关数据；以及

交互式健康评估模式，所述交互式健康评估模式用于基于用户与所述用户设备的交互执行可配置的交互式评估，获得健康相关数据；

并且其中，所述方法还包括：

通过通信网络从健康监测系统接收数据采集配置，所述数据采集配置指定要在所述用户设备执行的多个数据采集活动，每个数据采集活动用于获得相应的健康相关数据，并且与所述多种数据采集模式中的至少一个相关联；

通过所述数据采集应用，根据与所述数据采集活动相关联的所述至少一个数据采集模式，执行每个数据采集活动，获得健康相关数据，所述获得的健康相关数据包括：传感器数据、用户输入数据、以及交互式评估数据中的一个或多个；以及

基于所述获得的健康相关数据向所述健康监测系统发送结果数据。

2.根据条款1所述的方法，其中，在所述交互式健康评估模式下执行数据采集活动包括：

运行所述数据采集配置中指定的交互式评估；

响应于经由所述用户设备的用户界面提供的交互提示，检测与用户设备的用户交互；以及

基于所述检测到的用户交互生成健康相关数据。

3.根据条款2所述的方法，包括测量所述用户交互的一个或多个特征，并且基于测量的特征生成所述健康相关数据，所述一个或多个特征可选地包括：响应时间和响应准确性中的一个或多个。

4.根据前述条款中任一项所述的方法，其中，给定的交互式评估包括用于评估用户的一个或多个能力的能力测试，可选地是认知测试、感知测试(例如视觉敏锐度测试或听觉测试)、灵巧度测试、或其他交互式测试中的一个，用于基于受试者的健康和/或能力对其进行评估和/或分层。

5.根据前述条款中任一项所述的方法，其中，在所述用户输入模式下执行数据采集活动包括显示在所述数据采集配置中指定的一个或多个数据输入字段，并且经由所述用户设备的界面接收来自用户的每个字段的相应数据输入值。

6.根据前述条款中任一项所述的方法，其中，在所述数据输入模式下执行的数据采集活动包括用于输入一个或多个健康相关数据值的数据输入活动，例如健康状态或症状问卷。

7.根据前述条款中任一项所述的方法，其中，在所述基于传感器的数据采集模式中执行数据采集包括基于数据采集配置识别包括在所述用户设备中或与所述用户设备通信的至少一个传感器，并且从所述识别的至少一个传感器中获得传感器数据。

8.根据前述条款中任一项所述的方法，其中，可从中导出指示用户健康的数据的所述源数据包括以下中的一个或多个：用户输入数据；传感器数据；以及从交互式评估中获得的评估数据。

9.根据前述条款中任一项所述的方法，其中，所述数据采集配置还包括调度数据，所述调度数据定义要在所述用户设备执行的所述数据采集活动的调度，所述配置包括基于所述调度数据，确定所述数据采集应用执行每个所述数据采集活动的目标时间；以及由所述数据采集应用根据所述确定的目标时间发起所述数据采集活动。

10.一种在用户设备执行的计算机实现的方法，包括用于从包括一个或多个传感器的一个或多个数据源获得健康相关数据的数据采集应用，所述健康相关数据包括指示用户健康的数据和可从中导出所述指示用户健康的数据的源数据中的一个或多个，所述方法包括：

通过通信网络从健康监测系统接收数据采集配置，所述数据采集配置包括调度数据，所述调度数据定义要在所述用户设备执行的数据采集活动的调度，每个数据采集活动用于在所述用户设备获取相应的健康相关数据；

基于接收的所述数据采集配置配置所述数据采集应用，所述配置包括基于所述调度数据，确定所述数据采集应用执行每个所述数据采集活动的目标时间；

通过所述数据采集应用根据所述确定的目标时间启动所述数据采集活动，获得每个数据采集活动的健康相关数据，其中，至少一个所述数据采集活动包括使用包括在所述用户设备中或与所述用户设备通信的一个或多个传感器获得传感器数据，用于所述数据采集活动的所述健康相关数据包括传感器数据；以及

基于为所述数据采集活动获得的所述健康相关数据向所述健康监测系统发送结果数据。

11.根据条款9或10所述的方法，其中，所述调度数据指定给定的数据采集活动的相对时间信息，并且其中确定所述给定的数据采集活动的所述目标时间包括：

确定参考时间；以及

基于所述参考时间和所述调度数据中指定的所述相对时间信息计算目标时间。

12.根据条款11所述的方法，其中，所述相对时间信息定义了一个时间段，所述时间段被添加到所述确定的参考时间，获得所述目标时间。

13.根据条款9至12中任一项所述的方法，其中，所述相对时间信息指定触发事件，其中所述参考时间基于所述触发事件的发生被确定。

14.根据条款13所述的方法，其中，所述触发事件是由事件处理系统在事件消息中传送的事件，其中，基于从所述事件处理系统接收的所述事件消息确定所述参考时间。

15.根据条款9至14中任一项所述的方法，其中，所述调度数据包括与给定的数据采集活动相关联的基于事件的动态时间戳数据结构，所述基于事件的动态时间戳数据结构指定触发事件和相对所述触发事件的发生的时间段，所述方法包括在检测到所述触发事件时，解析所述基于事件的动态时间戳，其中解析所述基于事件的动态时间戳包括：

根据所述事件的事件时间和时间段计算目标时间，以及

将所述计算的目标时间添加到所述基于动态事件的时间戳数据结构。

16.根据条款15所述的方法，其中，所述用户设备、数据采集应用、以及健康监测系统中的一个或多个包括事件处理系统，所述方法包括：

从所述基于事件的动态时间戳数据结构中识别所述触发事件；以及

在所述事件处理系统订阅触发事件。

17.根据条款16所述的方法，还包括：

从所述事件处理系统中接收与所述指定触发事件匹配的事件；以及

响应于接收事件，解析所述时间戳。

18.根据条款13至17中任一项所述的方法，其中，所述触发事件是从一组预定的事件中选择的命名事件，并且可选地包括与所述事件相关联的数据。

19.根据条款13至18中任一项所述的方法，其中，所述触发事件包括：

对应于传感器测量的传感器事件，所述传感器测量可选地满足预定标准，例如传感器值阈值；

定义用户输入的接收的用户输入事件；

识别所述用户设备或移动应用的状态或状态变化的状态事件；

定时事件；以及

由所述健康监控系统生成，并通过所述通信网络传送给所述用户设备的事件。

20.根据条款11至19中任一项所述的方法，其中，确定所述给定的数据采集活动的所述目标时间包括：确定参考时间和所述目标时间相应的时间偏移量，可选地为夏令时偏移量，并且如果所述偏移量不同，则基于所述偏移量校正所述目标时间。

21.根据条款9至20中任一项所述的方法，其中，所述数据采集配置包括：对于给定的数据采集活动，指定所述给定的数据采集活动适用的设备和/或用户的适用性标准，所述方法包括：评估所述适用性标准，以及根据所述评估调度和/或执行所述数据采集活动，其中，所述适用性标准可选地包括一个或多个设备特征和/或用户特征。

22.根据条款9至21中任一项所述的方法，其中，所述调度数据进一步指定给定的数据采集活动的截止日期，所述方法包括：检测所述数据采集活动未在所述指定的截止日期之前完成，并且作为响应，重新调度所述数据采集活动，和/或生成识别所述数据采集活动为未完成的通知。

23.根据条款22所述的方法，包括确定所述数据采集活动是否满足一个或多个重新调度标准，所述标准优选地基于所述数据采集活动已被重新调度的次数，并且如果满足，则通过计算所述数据采集活动的新目标时间重新调度所述数据采集活动。

24.根据前述条款中任一项所述的方法，其中，所述调度数据定义用户分配的调度，每个用户分配与一个或多个分配任务相关联，并且其中每个分配任务包括至少一个数据采集活动，其中每个用户分配优选地定义要完成的所述分配的分配任务的工作流。

25.根据条款9至24中任一项所述的方法，包括响应于在所述健康监测系统对健康研究配置的改变，在所述用户设备接收更新的配置数据，其中，所述数据采集应用优选地基于所述更新的配置数据，更新本地存储的所述配置和/或修改设备采集活动的调度。

26.根据条款9至25中任一项所述的方法，包括基于所述调度数据调度和启动一个或多个通知，优选地，基于为一个或多个通知指定的可动态解析的基于事件的时间戳，所述通知可选地包括推送通知、或用于在所述用户设备输出的其他电子消息。

27.根据条款9至26中任一项所述的方法，包括基于所述调度数据，调度用于所述结果数据的发送的时间，并且在所述调度的时间执行发送步骤。

28.根据条款9至27中任一项所述的方法，其中，启动数据采集活动包括以下的至少一个：

由所述用户设备在所述确定的目标时间自动执行所述数据采集活动；

在所述确定的目标时间提示在所述用户设备的用户开始所述数据采集活动；以及

可选地经由显示在所述用户设备的菜单，使所述数据采集活动可用于在确定的目标时间由用户选择和启动。

29.根据条款9至28中任一项所述的方法，其中，所述数据采集活动包括一个或多个基于用户输入的数据采集活动，所述基于用户输入的数据采集活动包括：经由所述用户设备的界面接收一个或多个用户输入，并且其中发送的所述结果数据包括基于接收的所述用户输入的结果数据。

30.根据条款29所述的方法，其中，所述一个或多个基于用户输入的数据采集活动包括以下中的一个或多个：

数据输入活动，所述数据输入活动用于输入一个或多个健康相关数据值，例如健康状态或症状问卷；

基于用户交互的基于界面的交互式健康评估，可选地包括响应于经由所述用户设备的用户界面的交互式提示来检测用户交互，所述方法包括从一个或多个用户交互中导出健康相关数据。

31.根据前述条款中任一项所述的方法，其中，所述数据采集活动包括至少一个基于传感器的数据采集活动和至少一个从包括以下各项的组中选择附加的数据采集活动：附加的基于传感器的数据采集活动、数据输入活动、以及基于界面的交互式健康评估。

32.根据前述条款中任一项所述的方法，其中，所述数据采集活动包括以下中的一个或多个：

交互式分配任务，包括指示用户执行活动，并且从一个或多个传感器接收与活动的执行相关的传感器数据；以及

可选地在预定时间段内，从一个或多个传感器被动获取传感器数据。

33.根据前述条款中任一项所述的方法，其中，所述配置数据包括将输出给所述用户的指示信息，所述指示信息指示在一个或多个数据采集活动期间由所述用户执行的一个或多个任务。

34.根据前述条款中任一项所述的方法，所述发送步骤包括为在所述用户设备的多个所述数据采集活动采集健康相关数据，并根据一个或多个批量传输标准对采集的数据执行批量传输。

35.一种在用户设备执行的计算机实现的方法，所述方法包括用于获得健康相关数据的数据采集应用，所述健康相关数据包括指示用户健康的数据和可从中导出指示用户健康的数据的源数据中的一个或多个，所述方法包括：

通过通信网络从健康监测系统接收数据采集配置，所述数据采集配置定义要在所述用户设备执行的多个数据采集活动，每个数据采集活动用于在所述用户设备获取相应的健康相关数据；

所述数据采集应用根据所述数据采集配置执行所述数据采集活动，获得每个数据采集活动的健康相关数据；以及

基于采集的所述健康相关数据向所述健康监测系统发送结果数据，所述发送包括：

在用户设备为多个数据采集活动采集健康相关数据，并且根据一个或多个批量传输标准对采集的数据执行批量传输。

36.根据条款34或35所述的方法，其中，在所述数据采集配置中指定所述一个或多个批量传输标准。

37.根据条款34至36中任一项所述的方法，其中，所述批量传输标准指定以下中的一个或多个：

数据采集活动组，所述数据采集活动组的结果数据将被批量传输；

时间信息，指定要执行批量传输的时间；

上传频率信息，指定要执行批量传输的频率；以及

连接标准，可选地指定优选网络连接的可用性。

38.根据条款34至37中任一项所述的方法，包括根据所述批量传输标准确定传输时间；以及在确定的时间执行批量传输。

39.根据条款38所述的方法，包括基于包括在所述数据采集配置中的调度数据确定所述传输时间，优选地，其中所述调度数据指定用于执行数据传输的相对时间信息，并且其中确定所述传输时间包括：确定参考时间；以及基于所述参考时间和所述调度数据中指定的相对时间信息计算传输时间。

40.根据条款39所述的方法，其中，所述相对时间信息指定触发事件，其中基于在所述用户设备的所述触发事件的检测确定所述参考时间，可选地，其中所述相对时间信息包括可动态解析的基于事件的时间戳。

41.根据条款34至40中任一项所述的方法，包括基于网络连接状态和/或可用带宽确定所述传输时间。

42.根据条款34至41中任一项所述的方法，其中，所述批量传输标准在所述用户设备识别可用的多个网络接口中的一个作为优选网络接口，并且选择所述优选网络接口用于执行所述批量传输和/或在经由所述优选网络接口可获得网络连接性的时间执行传输。

43.根据条款34至42中任一项所述的方法，包括监测来自所述健康监测系统的确认消息的接收，所述确认消息指示在健康监测系统批量传输的接收，并且进一步执行以下至少一项：

如果没有接收到确认消息，则在预定时间段之后重复所述采集的数据的批量传输；以及

响应于所述确认消息的接收，删除采集的所述健康相关数据。

44.一种用户设备，所述用户设备包括至少一个处理器和相关联的存储器，用于执行根据条款1至43中的任一项所述的方法。

45.一种非暂时性计算机可读介质，所述非暂时性计算机可读介质包括软件代码，当在数据处理装置上被执行时，所述软件代码适于执行根据条款1至43中任一项所述的方法。

46.一种在健康研究管理系统执行的用于从多个数据源采集健康相关数据的计算机实现的方法，所述健康相关数据包括指示用户健康的数据和可从中导出指示用户健康的数据的源数据中的一个或多个，所述数据源包括与被监控的系统用户相关联的传感器设备，所述方法包括：

提供模块化数据摄取子系统，所述模块化数据摄取子系统包括一组可扩展的接口模块，每个接口模块适于从相应类型的数据源接收健康相关数据；

提供模块化数据处理子系统，所述模块化数据处理子系统包括一组可扩展的处理模块，每个处理模块适于处理健康相关数据，从所述健康相关数据确定一个或多个导出的健康指标；以及

使用所述健康研究管理系统接收用于待实施的健康研究的配置信息，所述配置信息指定多个数据采集活动，每个数据采集活动用于从一个或多个数据源采集相应的健康相关数据，所述数据采集活动包括与用于采集传感器数据的传感器设备类型相关联的至少一个基于传感器的数据采集活动，以及对采集的传感器数据执行处理，

根据用于所述健康研究的所述配置信息，配置所述数据摄取子系统和所述数据处理子系统；

经由所述配置的数据摄取子系统，从所述数据源采集健康相关数据；

使用所述配置的数据处理子系统，处理所述采集的健康相关数据；

基于所述处理的健康相关数据生成研究数据集；以及

输出所述研究数据集。

47.根据条款46所述的方法，其中，所述配置步骤包括：基于所述配置数据，通过选择用于处理健康相关数据的一个或多个接口模块和/或处理模块，来配置用于数据采集活动的数据流。

48.根据条款46或47所述的方法，其中，所述配置步骤包括与给定的数据源(给定源)相关联的以下的至少一个：

所述数据摄取子系统的选定的接口模块，所述选定的接口模块用于在所述健康研究管理系统输入来自所述给定源的健康相关数据；以及

所述处理子系统的处理模块，所述处理模块用于处理来自所述给定源的健康相关数据；

所述系统还用于使用配置的所述接口模块和/或配置的所述处理模块接收和/或处理来自所述给定源的健康相关数据。

49.根据条款46至48中任一项所述的方法，其中，所述配置步骤包括为所述至少一个基于传感器的数据采集活动选择所述数据摄取子系统的接口模块，所述接口模块适于接收来自所述相关联的传感器设备类型的数据，以及用于执行来自所述传感器设备类型的传感器数据的处理的所述数据处理子系统的处理模块的数据。

50.根据条款48或49所述的方法，其中，所述数据源还包括以下中的一个或多个：经由与被监测的系统用户相关联的用户设备提供的数据输入；以及从在与被监测的系统用户相关联的用户设备上运行的交互式健康评估中获得的交互式健康评估数据。

51.根据条款50所述的方法，其中，所述数据采集活动还包括一个或多个基于用户输入的数据采集活动，所述基于用户输入的数据采集活动包括：经由与被监测的系统用户相关联的用户设备的界面接收一个或多个用户输入，其中，所述一个或多个基于用户输入的数据采集活动可选地包括以下中的一个或多个：

数据输入活动，所述数据输入活动用于输入一个或多个健康相关数据值，例如健康状态或症状问卷；

基于用户交互的基于界面的交互式健康评估，可选地包括响应于经由所述用户设备的用户界面的交互提示来检测用户交互。

52.根据条款46至51中任一项所述的方法，其中，所述处理模块包括：

处理模块，所述处理模块用于处理来自多个不同类型的数据源的数据，可选地，包括多个传感器设备类型；以及

处理模块，所述处理模块用于实现多个不同的处理算法，所述处理算法用于确定从健康相关数据导出的健康指标。

53.根据条款46至52中任一项所述的方法，其中，所述配置步骤包括：向所述数据摄取子系统添加一个或多个接口模块和/或向所述数据处理子系统添加一个或多个处理模块，以根据所述配置信息实现给定的数据采集活动的数据流。

54.根据条款46至53中任一项所述的方法，包括接收从数据采集活动的目录中选择的一个或多个预定义的数据采集活动，并且基于所述选择的预定义的数据采集活动执行配置。

55.根据条款46至54中任一项所述的方法，其中，所述配置信息指定要为其采集数据的研究参与者，所述配置步骤包括将用户设备和/或一个或多个传感器设备与每个研究参与者相关联，并且配置所述数据摄取子系统从所述用户设备和/或一个或多个传感器设备接收数据。

56.根据条款46至55中任一项所述的方法，还包括将研究配置发送到与一组研究参与者中的每一个相关联的相应用户设备，以配置所述用户设备执行所述数据采集活动，所述研究配置优选地包括调度数据，所述调度数据定义由所述用户设备上的健康监测应用执行的数据采集活动的调度。

57.根据条款46至56中任一项所述的方法，包括接收与相应健康研究相关联的多个健康研究配置；并且，对于每个健康研究，配置至少一个：所述数据摄取子系统；所述数据处理子系统；以及与健康研究的参与者相关联的相应用户设备组。

58.根据条款46至57中任一项所述的方法，包括在所述数据摄取子系统中提供以下之一或全部：

第一接口，所述第一接口用于和与研究参与者的用户设备相关联的传感器设备通过接口连接，其中第一接口优选地包括一组可扩展模块，所述一组可扩展模块用于与包括在所述用户设备中的、或适于与所述用户设备通信的相应类型的传感器或传感器子系统通过接口连接；

第二接口，所述第二接口用于与适于从独立传感器设备采集数据的一个或多个远程数据采集服务通过接口连接，所述第二接口优选地包括用于从所述远程数据采集服务接收数据的一组可扩展模块，可选地包括相应的网络服务接口。

59.根据条款58所述的方法，包括在所述数据摄取子系统中提供通用数据摄取接口，所述通用数据摄取接口用于经由所述第一接口从所述用户设备接收传感器数据，并且经由所述第二接口使用所述远程数据采集服务从独立传感器设备接收传感器数据。

60.根据条款59所述的方法，其中，所述数据摄取和/或数据处理子系统实现事件驱动的数据摄取流水线，所述方法包括：在所述数据摄取子系统，生成包括采集的健康相关数据的事件，并且将所述事件发布到事件处理系统；以及，在所述处理子系统，消费来自所述事件处理系统的所述事件，并且处理包括在所述事件中的所述采集的健康相关数据，所述处理子系统可选地生成包括从健康相关数据导出的健康指标的其他事件。

61.根据条款46至60中任一项所述的方法，还包括根据通用健康数据模型格式化来自多个数据源和/或导出的健康指标的健康相关数据，和/或所述使用通用健康数据模型输出、处理、和/或存储所述数据。

62.一种系统，所述系统包括至少一个处理器和相关联的存储器，所述处理器用于执行根据条款46至61中任一项所述的方法。

63.一个或多个非暂时性计算机可读介质，所述非暂时性计算机可读介质包括软件代码，当被一个或多个数据处理设备执行时，所述软件代码用于执行条款46至61中任一项所述的方法。

64.一种在用户设备执行的用于获得健康相关数据的计算机实现的方法，所述健康相关数据包括指示用户健康的数据和可从中导出所述指示用户健康的数据的源数据中的一个或多个，所述方法包括：

通过通信网络从健康监测系统接收数据采集配置，所述数据采集配置包括调度数据，所述调度数据定义要在所述用户设备执行的数据采集活动的调度，每个所述数据采集活动用于在所述用户设备获取相应的所述健康相关数据；

基于所述调度数据，对于每一个所述数据采集活动，确定要执行所述数据采集活动的目标时间；

根据所述数据采集活动各自的所述确定的目标时间，在所述用户设备启动所述数据采集活动，获得用于所述数据采集活动的所述健康相关数据；以及

基于所述获得的健康相关数据向所述健康监测系统发送结果数据。

65.根据条款64所述的方法，其中，所述调度数据指定给定的数据采集活动的相对时间信息，并且其中，确定所述给定的数据采集活动的所述目标时间包括：

确定参考时间；以及

基于所述参考时间和所述调度数据中指定的所述相对时间信息，计算所述目标时间，其中，所述相对时间信息优选地定义被添加到所述确定的参考时间的时间段，以获得所述目标时间。

66.根据条款65所述的方法，其中，所述相对时间信息指定触发事件，其中，所述参考时间基于所述触发事件的发生确定。

67.根据条款66所述的方法，其中，所述触发事件是由事件处理系统在事件消息中传送的事件，其中，所述参考时间基于来自所述事件处理系统的所述事件消息的接收确定。

68.根据条款64至67中任一项所述的方法，其中，所述调度数据包括与给定的数据采集活动相关联的基于事件的动态时间戳、所述基于事件的动态时间戳指定触发事件、以及所述触发事件的发生对应的时间段，所述方法包括检测到所述触发事件时，解析所述基于事件的动态时间戳，其中，解析所述基于事件的动态时间戳信息包括：

根据所述触发事件的事件时间和所述时间段，计算目标时间，以及

将所述计算的目标时间添加到所述基于事件的动态时间戳中。

69.根据条款67或68所述的方法，其中，所述用户设备和/或健康监控系统实现事件处理系统，所述方法包括：

从所述基于事件的动态时间戳中识别所述触发事件；以及

订阅在所述事件处理系统的所述触发事件；并且可选地，还包括：

从所述事件处理系统接收与所述指定触发事件匹配的事件；以及

响应于接收所述事件，解析所述基于事件的动态时间戳。

70.根据条款66至69中任一项所述的方法，其中，所述触发事件是从一组预定的事件中选择的命名事件，并且可选地包括与所述事件相关联的数据。

71.根据条款66至70中任一项所述的方法，其中，所述触发事件包括：

对应于传感器测量的传感器事件，可选地，所述传感器测量满足预定标准，例如传感器值阈值；

定义用户输入的接收的用户输入事件；

识别所述用户设备的状态或状态变化的状态事件；

定时事件；以及

由所述健康监测系统生成，并通过所述通信网络传送给所述用户设备的事件。

72.根据条款65至71中任一项所述的方法，其中，确定所述给定的数据采集活动的所述目标时间包括：确定所述参考时间和所述目标时间相应的时间偏移量，可选地为夏令时偏移量，并且如果所述偏移量不同，则基于所述偏移量校正所述目标时间。

73.根据条款64至72中任一项所述的方法，其中，对于给定的数据采集活动，所述数据采集配置包括指定所述给定的数据采集活动适用的设备和/或用户的适用性标准，所述方法包括评估所述适用性标准，以及根据所述评估来调度和/或执行所述数据采集活动，其中所述适用性标准可选地包括一个或多个设备特征和/或用户特征。

74.根据条款64至73中任一项所述的方法，其中，所述调度数据进一步指定给定的数据采集活动的截止日期，所述方法包括：检测所述数据采集活动未在所述指定的截止日期之前完成，并且作为响应，重新调度所述数据采集活动，和/或生成识别所述数据采集活动为未完成的通知。

75.根据条款74所述的方法，包括确定所述数据采集活动是否满足一个或多个重新调度标准，所述标准优选地基于所述数据采集活动已被重新调度的次数，并且如果满足，则通过计算所述数据采集活动的新目标时间重新调度所述数据采集活动。

76.根据条款64至75中任一项所述的方法，包括基于所述调度数据，优选地基于为一个或多个通知指定的可动态解析的基于事件的时间戳，调度和启动一个或多个通知所述通知可选地包括推送通知、或用于在所述用户设备输出的其他电子消息。

77.根据条款64至76中任一项所述的方法，包括基于所述调度数据，调度用于所述结果数据的发送的时间，并且在所述调度的时间将所述结果数据发送到所述健康监测系统。

78.根据条款64至77中任一项所述的方法，包括在所述用户设备配置数据采集应用，以根据所述确定的目标时间执行所述数据采集活动。

79.根据条款64至78中任一项所述的方法，其中，启动数据采集活动包括以下的至少一项：

由所述用户设备在所述确定的目标时间自动执行所述数据采集活动；

在所述用户设备提示用户开始所述数据采集活动；以及

使所述数据采集活动可供用户经由显示在所述用户设备的菜单进行选择和启动。

80.根据条款64至79中任一项所述的方法，其中，所述数据采集活动包括一个或多个基于用户输入的数据采集活动，所述基于用户输入的数据采集活动包括：经由所述用户设备的界面接收一个或多个用户输入，并且其中获得的所述健康相关数据基于接收的用户输入。

81.根据条款80所述的方法，其中所述一个或多个基于用户输入的数据采集活动包括以下的一个或多个：

数据输入活动，所述数据输入活动用于输入一个或多个健康相关数据值，例如健康状态或症状问卷；

基于用户交互的基于界面的交互式健康评估，可选地包括响应于经由所述用户设备的用户界面的交互提示来检测用户交互，所述方法包括从一个或多个用户交互中导出健康相关数据。

82.根据条款81所述的方法，其中，所述交互式健康评估包括基于所述检测的用户交互的一个或多个测量特征生成健康相关数据，所述一个或多个特征可选地包括：响应时间和响应准确性中的一个或多个。

83.根据条款81或82所述的方法，其中，所述交互式健康评估包括用于评估用户的一个或多个能力的能力测试，可选地是认知测试、感知测试(例如视觉敏锐度测试或听觉测试)、灵巧度测试、或其他交互式测试中的一个，用于基于受试者的健康和/或能力对其进行评估和/或分层。

84.根据条款64至83中任一项所述的方法，其中，至少一个所述数据采集活动包括从包括在所述用户设备中或与所述用户设备通信的一个或多个传感器获取传感器数据，其中获得的健康相关数据包括获取的传感器数据。

85.根据条款64至84中任一项所述的方法，其中，所述数据采集配置包括指示信息，所述方法包括向所述用户输出指示在一个或多个数据采集活动期间由所述用户执行的一个或多个任务的所述指示信息。

86.根据条款64至85中任一项所述的方法，包括从所述健康监测系统接收更新的配置数据，以及基于所述更新的配置数据，更新本地存储的数据采集配置和/或修改设备采集活动的调度。

87.根据条款64至86中任一项所述的方法，其中所述调度数据定义了用户分配的调度，每个用户分配与一个或多个分配任务相关联，并且其中每个分配任务包括至少一个数据采集活动，其中每个用户分配优选地定义了要为所述分配完成的分配任务的工作流。

88.一种用户设备，所述用户设备包括至少一个处理器和相关联的存储器，用于执行条款64至87中任一项所述的方法。

89.一种非暂时性计算机可读介质，所述非暂时性计算机可读介质包括软件代码，当在数据处理装置上执行时，所述软件代码适于执行根据条款64至88中任一项所述的方法。

90.一种在健康研究管理系统中执行的用于从与健康研究参与者相关联的多个用户设备采集健康相关数据的方法，所述健康相关数据包括指示用户健康的数据和可从中导出所述指示用户健康的数据的源数据中的一个或多个，所述方法包括：

接收健康研究配置，所述健康研究配置指定用于健康研究的数据采集活动、以及用于所述数据采集活动的调度信息；

为每个研究参与者生成数据采集配置，所述数据采集配置包括基于与所述研究参与者相关联的用户设备的所述健康研究配置的调度数据、定义要在用户设备执行的数据采集活动的调度的调度数据、用于获得所述研究参与者的相应健康相关数据的每个数据采集活动；以及

向每个用户设备发送为所述用户设备生成的所述数据采集配置，以配置要在所述用户设备执行的数据采集活动。

91.根据条款90所述的方法，还包括：

在所述健康研究管理系统，从多个所述用户设备接收健康相关数据，所述健康相关数据是在每个用户设备处，基于为所述用户设备生成的数据采集活动的所述调度获得的；

处理所述健康相关数据；

编译来自所述处理的健康相关数据的用于所述健康研究的研究数据集；以及输出所述研究数据集。

92.根据条款90或91所述的方法，其中，所述数据采集活动包括一个或多个基于用户输入的数据采集活动，所述基于用户输入的数据采集活动包括：经由所述用户设备的界面接收一个或多个用户输入，其中所述一个或多个基于用户输入的数据采集活动可选地包括以下中的一个或多个：

数据输入活动，所述数据输入活动用于输入一个或多个健康相关数据值，例如健康状态或症状问卷；

基于用户交互的基于界面的交互式健康评估，可选地包括响应于经由所述用户设备的用户界面的交互提示来检测用户交互。

93.根据条款90至92中任一项所述的方法，其中，所述数据采集活动包括用于从一个或多个传感器获得传感器数据的至少一个基于传感器的数据采集活动，所述一个或多个传感器可选地包括：一个或多个集成到用户设备中的传感器、一个或多个可配置为与用户设备通信的外部传感器、以及一个或多个可配置为向所述健康研究管理系统提供传感器数据的外部传感器设备。

94.根据条款90至93中任一项所述的方法，其中，所述调度数据定义多个数据采集活动的目标时间。

95.根据条款94所述的方法，其中，所述调度数据为给定的数据采集活动指定相对于参考时间的相对时间信息，所述参考时间优选地包括要添加到所述确定的参考时间的时间段，其中，所述相对时间信息可选地指定触发事件，其中，所述触发事件在所述用户设备的发生确定所述参考时间。

96.根据条款95所述的方法，还包括：生成与所述指定的触发事件匹配的事件，并且将所述事件传送给所述用户设备，触发对所述动态定时信息的解析。

97.根据条款90至96中任一项所述的方法，包括基于所述健康研究配置在所述健康研究管理系统配置结果处理系统，执行来自所述用户设备的对所述健康相关数据的处理。

98.根据条款97所述的方法，包括在所述结果处理系统中提供以下中的一个或多个：

模块化数据摄取子系统，所述模块化数据摄取子系统包括一组可扩展的接口模块，每个接口模块适于从相应的数据源接收健康相关数据；

模块化数据处理子系统，所述模块化数据处理子系统包括一组可扩展的处理模块，每个处理模块适于处理健康相关数据，从所述健康相关数据确定一个或多个导出的健康指标；

所述方法包括根据所述健康研究配置，配置所述模块化数据摄取子系统和/或所述模块化数据处理子系统。

99.根据条款98所述的方法，包括基于所述健康研究配置，通过选择一个或多个接口模块和/或处理模块，为多个数据采集活动中的每一个配置数据流，所述接口模块和/或处理模块用于处理由每个数据采集活动生成的健康相关数据。

100.根据98或99所述的方法，其中，所述处理模块包括用于实现多个不同的处理算法以从健康相关数据确定导出的健康指标的模块，可选地，其中给定的处理模块执行聚合功能，基于所述健康相关数据的多个数据值生成导出的健康指标。

101.根据条款90至100中任一项所述的方法，其中，接收健康研究配置包括接收从数据采集活动的目录中选择的一个或多个预定义的数据采集活动，并且基于所述选择的预定义的数据采集活动，执行所述结果处理系统的配置和/或为用户设备生成数据采集配置。

102.根据条款90至101中任一项所述的方法，还包括根据通用健康数据模型格式化来自多个源的健康相关数据，和/或使用通用健康数据模型输出、处理、和/或存储健康相关数据。

103.一种在健康研究管理系统中执行的用于从与健康研究参与者相关联的多个用户设备采集健康相关数据的方法，所述健康相关数据包括指示用户健康的数据，以及可以从中导出指示用户健康的数据的源数据中的一个或多个，所述方法包括：

接收健康研究配置，所述健康研究配置指定用于所述健康研究的要在用户设备上执行的数据采集活动；

向所述多个用户设备中的每一个发送配置数据，配置所述用户设备执行所述指定的数据采集活动；

根据配置的数据采集活动，从所述用户设备接收第一组健康相关数据；

接收对所述健康研究配置的一个或多个更改；

根据对健康研究配置的一个或多个更改，为一个或多个所述用户设备生成更新的配置数据；

将所述更新的配置数据发送到所述一个或多个用户设备，以根据所述更改的健康研究配置在所述一个或多个设备重新配置数据采集；

在所述用户设备的重新配置之后接收第二组健康相关数据；以及

基于所述第一组和第二组健康相关数据，生成和输出用于所述健康研究的研究数据集。

104.根据条款103所述的方法，其中，所述一个或多个更改包括对要执行的数据采集活动的更改、和/或对要由一个或多个所述数据采集活动采集的数据的更改。

105.根据条款104所述的方法，其中，所述一个或多个更改包括以下中的一个或多个：中止所述指定的数据采集活动之一；以及向所述指定的数据采集活动添加新数据采集活动。

106.根据条款103至105中任一项所述的方法，其中，所述健康研究配置包括用于所述数据采集活动的调度信息，所述生成的配置数据包括指定在用户设备执行数据采集活动的时间的调度数据，并且其中一个或多个更改包括对所述调度信息的更改。

107.根据条款106所述的方法，其中，生成更新的配置数据包括：更改为给定的数据采集活动在用户设备执行数据采集的时间或频率。

108.根据条款103至107中任一项的方法，包括基于对所述健康研究配置的更改，重新配置要应用于接收的健康相关数据的处理。

109.根据条款108所述的方法，其中，所述处理由健康研究管理系统的可配置处理子系统执行，所述方法包括依赖于对健康研究配置的改变来重新配置所述可配置处理子系统，可选地配置一个或多个接口模块和/或处理模块，用于接收和/或处理来自用户设备的健康相关数据。

110.一种在健康研究管理系统中执行的用于配置从与健康研究参与者相关联的多个用户设备采集到的健康相关数据的方法，所述健康相关数据包括指示用户健康的数据，和可从中导出所述指示用户健康的数据的源数据中的一个或多个，所述方法包括：

维护数据库中预定义的数据采集活动的目录，每个数据采集活动可在用户设备上执行，以获得健康相关数据；

接收用于健康研究的健康研究配置，所述健康研究配置识别来自所述目录的选定的数据采集活动组，所述数据采集活动组中的每一个用于获取用于所述健康研究的相应健康相关数据；

基于所述目录和所述选定的数据采集活动组，为与研究参与者相关联的多个用户设备中的每一个生成数据采集配置，所述数据采集配置指定要在用户设备执行的所述数据采集活动；以及

向每个用户设备发送所述生成的数据采集配置，以配置所述用户设备执行所述指定的数据采集活动。

111.根据条款110所述的方法，其中，所述目录中定义的所述数据采集活动包括以下中的一个或多个：

数据输入活动，其中，数据输入活动包括输入一个或多个健康相关数据值，例如以健康状态或症状问卷的形式；

交互式健康评估，其中，交互式健康评估包括基于用户交互获得健康相关数据，可选地包括响应于经由所述用户设备的用户界面的交互提示来检测用户交互，并且从一个或多个用户交互中导出健康相关数据；以及

基于传感器的数据采集活动，所述基于传感器的数据采集活动用于从包括在所述用户设备中或与所述用户设备通信的一个或多个传感器获取传感器数据，其中，所述获得的健康相关数据包括所述获取的传感器数据。

112.根据条款110或111所述的方法，其中，所述健康研究管理系统包括结果处理系统，所述结果处理系统用于基于在所述用户设备的所述数据采集活动的执行，处理从用户设备接收的结果数据，所述方法还包括：基于所述选择的预定义的数据采集活动，配置所述结果处理系统。

113.根据条款112所述的方法，包括在所述结果处理系统中提供以下中的一个或多个：

模块化数据摄取子系统，所述模块化数据摄取子系统包括一组接口模块，每个接口模块适于从相应的数据源接收健康相关数据；

模块化数据处理子系统，所述模块化数据处理子系统包括一组处理模块，每个处理模块适于处理健康相关数据，从健康相关数据确定一个或多个导出的健康指标；

所述方法包括根据所述健康研究配置，配置所述模块化数据摄取子系统和/或所述模块化数据处理子系统。

114.根据条款113所述的方法，包括基于所述健康研究配置，通过选择一个或多个接口模块和/或处理模块，为多个数据采集活动中的每一个配置数据流，所述接口模块和/或处理模块用于处理由每个数据采集活动生成的健康相关数据。

115.根据条款110至114中任一项所述的方法，其中，所述调度数据包括基于在所述健康研究配置中的调度信息的所述数据采集配置中的调度数据，所述调度数据定义用于在用户设备执行的所述数据采集活动的调度。

116.根据115所述的方法，其中，所述调度数据包括指定要执行数据采集活动的一个或多个时间的时间信息，所述时间信息可选地包括可在所述用户设备解析的可解析的动态目标时间。

117.根据条款110至116中任一项所述的方法，包括基于所述选择的数据采集活动和每个用户设备选择的语言，生成所述数据采集配置。

118.根据条款110至117中任一项所述的方法，包括从所述目录中检索所述选择的数据采集活动组中每一个数据采集活动的规范数据，所述数据采集活动的规范数据指定以下中的一个或多个：由所述数据采集活动采集的数据、用于获取基于传感器的数据采集活动的数据的传感器设备类型、从用户处获得的数据输入活动的输入值；为交互式评估活动运行的交互式评估、以及对通过所述数据采集活动获得的健康相关数据执行的处理，所述方法还包括为每个用户设备生成所述数据采集配置，和/或基于所述检索的规范数据配置结果处理系统。

119.一种在健康研究管理系统中执行的用于为健康研究采集健康相关数据的计算机实现的方法，所述健康相关数据包括指示用户健康的数据，和可从中计算指示用户健康的数据的源数据中的一个或多个，所述方法包括：

从一个或多个设备接收与研究参与者相关联的健康相关数据，所述健康相关数据包括由使用所述一个或多个设备执行的多个数据采集活动生成的数据；

处理为每个数据采集活动接收的所述健康相关数据，根据通用健康数据模型格式化所述数据；

从格式化的健康相关数据确定一个或多个导出的健康指标；

使用所述导出的健康指标生成研究数据集；以及

输出所述研究数据集。

120.根据条款119的方法，其中，所述数据采集活动包括与在用户设备处提供的数据采集应用的多个数据采集模式相关联的数据采集活动，其中，所述处理步骤包括根据所述通用数据模型，格式化由所述多个数据采集模式生成的数据。

121.根据条款120所述的方法，其中，所述数据采集模式包括以下中的一个或多个：

基于传感器的数据采集模式，所述基于传感器的数据采集模式用于从包括在所述用户设备中或与所述用户设备通信的一个或多个传感器接收健康相关数据；

用户数据输入模式，所述用户数据输入模式用于基于用户输入的一组一个或多个健康相关数据值，获取健康相关数据；以及

交互式健康评估模式，所述交互式健康评估模式用于基于用户与所述用户设备的交互，执行用于获得健康相关数据的交互式评估。

122.根据条款119至121中任一项所述的方法，其中，所述数据采集活动包括与多个传感器相关联的数据采集活动，所述处理步骤包括根据所述通用数据模型，格式化由所述多个传感器生成的数据。

123.根据条款119至122中任一项的方法，其中，所述确定步骤包括基于多个数据采集活动接收的健康相关数据，计算至少一个导出的健康指标。

124.根据条款119至123中任一项所述的方法，其中，所述通用健康数据模型包括值数据，所述值数据至少包括指定的健康测量的值的值字段、以及指定的可应用于所述值的测量单元的单位字段，并且优选地还包括：数据类型字段、以及标识所述健康测量的类型的标识符字段中的一个或多个。

125.根据条款124所述的方法，其中，所述通用健康数据模型包括与所述值数据相关联的键数据，所述键数据包括：源、测量事件类型、用户标识符、设备标识符、以及一个或多个采集时间戳中的一个或多个，所述采集时间戳可选地包括采集周期的开始和结束时间戳。

126.根据条款125所述的方法，包括将包括键和值数据的格式化的健康相关数据存储在数据库中，并且使基于一个或多个所述键数据元素的健康相关数据的搜索、查询和/或整理可行。

127.根据条款119至126中任一项的方法，包括为多个研究参与者中的每一个重复接收、处理、以及确定步骤，并且使用为每个研究参与者导出的所述健康指标，生成所述研究数据集。

128.根据条款119至127中任一项所述的方法，其中，所述导出的健康指标包括与所述研究的一个或多个结果测量或终止相关联的一个或多个健康度量。

129.根据条款119至128中任一项所述的方法，包括接收用于所述健康研究的研究配置，以及根据所述研究配置执行所述接收、处理、以及确定步骤。

130.一种具有装置的系统，所述装置可选地包括至少一个处理器和相关联的存储器，所述装置用于执行根据条款90至129中任一项所述的方法。

131.一个或多个非暂时性计算机可读介质，所述非暂时性计算机可读介质包括软件代码，当被一个或多个数据处理设备执行时，所述软件代码执行根据条款90至129中任一项所述的方法。

在上述编号条款中列出的不同方面的各特征可以与符合上述公开的任何合适的组合进行组合。因此，一个方面的相关特征可以应用于任何其他方面。

Claims (15)

1.一种在用户设备执行的用于获得健康相关数据的计算机实现的方法，所述健康相关数据包括指示用户健康的数据和可从中导出所述指示用户健康的数据的源数据中的一个或多个，所述方法包括：

通过通信网络从健康监测系统接收数据采集配置，所述数据采集配置包括调度数据，所述调度数据定义要在所述用户设备执行的数据采集活动的调度，每个所述数据采集活动用于在所述用户设备获取相应的所述健康相关数据；

对于所述数据采集活动中的每个数据采集活动，基于所述调度数据确定要执行所述数据采集活动的目标时间；

根据所述数据采集活动各自的所述确定的目标时间在所述用户设备启动所述数据采集活动，以获得用于所述数据采集活动的健康相关数据；以及

基于所述获得的健康相关数据向所述健康监测系统发送结果数据。

2.根据权利要求1所述的方法，其中，所述调度数据指定给定的数据采集活动的相对时间信息，并且其中，确定所述给定的数据采集活动的所述目标时间包括：

确定参考时间；以及

基于所述参考时间和所述调度数据中指定的所述相对时间信息，计算所述目标时间，其中，所述相对时间信息优选地定义用于获得所述目标时间的被添加到所述确定的参考时间的时间段。

3.根据权利要求2所述的方法，其中，所述相对时间信息指定触发事件，其中，所述参考时间基于所述触发事件的发生来确定，其中，所述触发事件优选地是由事件处理系统在事件消息中传输的事件，其中，所述参考时间基于来自所述事件处理系统的所述事件消息的接收来确定。

4.根据权利要求2或3所述的方法，其中，所述调度数据包括与给定的数据采集活动相关联的动态的基于事件的时间戳、所述动态的基于事件的时间戳指定触发事件和所述触发事件的发生对应的时间段，所述方法包括在检测到所述触发事件时解析所述动态的基于事件的时间戳，其中，解析所述动态的基于事件的时间戳信息包括：

根据所述触发事件的事件时间和所述时间段，计算目标时间，以及

将所述计算的目标时间添加到所述动态的基于事件的时间戳中。

5.根据权利要求4所述的方法，其中，所述用户设备和/或所述健康监测系统实现事件处理系统，所述方法包括：

从所述动态的基于事件的时间戳中识别所述触发事件；以及

在所述事件处理系统订阅所述触发事件；并且可选地，所述方法还包括：

从所述事件处理系统接收与所述指定的触发事件匹配的事件；以及

响应于接收所述事件，解析所述动态的基于事件的时间戳。

6.根据权利要求3至5中任一项所述的方法，其中，所述触发事件是从一组预定的事件中选择的命名事件，并且可选地包括与所述事件相关联的数据。

7.根据权利要求3至6中任一项所述的方法，其中，所述触发事件包括以下之一：

对应于传感器测量的传感器事件，可选地，所述传感器测量满足预定标准，例如传感器值阈值；

定义用户输入的接收的用户输入事件；

识别所述用户设备的状态或状态变化的状态事件；

定时事件；以及

由所述健康监测系统生成并通过所述通信网络传输至所述用户设备的事件。

8.根据权利要求2至7中任一项所述的方法，其中，确定所述给定的数据采集活动的所述目标时间包括确定所述参考时间和所述目标时间的相应时间偏移量，可选地为夏令时偏移量，并且如果所述偏移量不同，则基于所述偏移量校正所述目标时间。

9.根据前述权利要求中任一项所述的方法，其中，所述数据采集配置包括：对于给定的数据采集活动，指定所述给定的数据采集活动适用的设备和/或用户的适用性标准，所述方法包括：

评估所述适用性标准，以及

根据所述评估调度和/或执行所述数据采集活动，其中，所述适用性标准可选地包括一个或多个设备特征和/或用户特征。

10.根据前述权利要求中任一项所述的方法，其中，所述调度数据还指定给定的数据采集活动的截止日期，所述方法包括：检测所述数据采集活动未在指定的所述截止日期之前完成，并且作为响应，重新调度所述数据采集活动和/或生成将所述数据采集活动识别为未完成的通知，所述方法可选地包括确定所述数据采集活动是否满足一个或多个重新调度标准，所述标准优选地基于所述数据采集活动已被重新调度的次数，并且如果所述数据采集活动满足所述一个或多个重新调度标准，则通过计算所述数据采集活动的新目标时间来重新调度所述数据采集活动。

11.根据前述权利要求中任一项所述的方法，包括以下至少之一：

基于所述调度数据，优选地基于为一个或多个通知指定的可动态解析的基于事件的时间戳，来调度和启动一个或多个通知，所述通知可选地包括推送通知或用于在所述用户设备输出的其他电子消息；以及

基于所述调度数据，调度用于发送所述结果数据的时间，并且在调度的所述时间向所述健康监测系统发送所述结果数据。

12.根据前述权利要求中任一项所述的方法，其中，启动数据采集活动包括以下的至少之一：

由所述用户设备在所述确定的目标时间自动执行所述数据采集活动；

在所述用户设备提示用户开始所述数据采集活动；以及

使所述数据采集活动可供用户经由显示在所述用户设备的菜单进行选择和启动。

13.根据前述权利要求中任一项所述的方法，其中，所述数据采集活动包括一个或多个基于用户输入的数据采集活动，所述基于用户输入的数据采集活动包括经由所述用户设备的界面接收一个或多个用户输入，并且其中，所述获得的健康相关数据基于接收的所述用户输入，其中，所述一个或多个基于用户输入的数据采集活动优选地包括以下中的一个或多个：

数据输入活动，所述数据输入活动用于输入一个或多个健康相关数据值，例如健康状态或症状问卷；

基于用户交互的基于界面的交互式健康评估，可选地包括响应于经由所述用户设备的用户界面的交互提示而检测用户交互，所述方法包括从一个或多个用户交互导出健康相关数据。

14.根据前述权利要求中任一项所述的方法，其中，所述数据采集活动中的至少一个包括从一个或多个传感器获取传感器数据，所述一个或多个传感器包括在所述用户设备中或与所述用户设备通信，其中，所述获得的健康相关数据包括获取的所述传感器数据。

15.一种系统或设备，所述系统或设备具有用于执行根据前述权利要求中任一项所述的方法的装置或计算机程序或计算机可读介质，所述计算机程序或计算机可读介质包括软件代码，当被执行时，所述软件代码适于执行根据前述权利要求中任一项所述的方法。