CN113424267A - 用于使用分散式计算平台按优先级来分析跨地理区域的健康数据的系统架构和方法 - Google Patents

Abstract

公开了用于在分散式云计算平台上分析健康数据的系统和方法。一种用于在分散式云计算平台上分析健康数据的方法包括：接收包含一个或多个匿名DICOM对象的唯一病例文件以用于分析；基于与所述一个或多个匿名DICOM对象相关联的优先级来设置所述唯一病例文件的优先级水平；对所述一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，所述分析是根据所述唯一病例文件的优先级水平而完成的。

Description

用于使用分散式计算平台按优先级来分析跨地理区域的健康 数据的系统架构和方法

（一个或多个）相关申请

本申请要求2019年2月22日提交的美国临时申请No.62/809,139的优先权，该申请的全部公开内容通过引用整体地并入本文中。

背景技术（介绍）

医院生成并且存储了与患者相关的大量健康数据记录。传统上，对健康数据（例如，医学记录、X射线、CT扫描、MRI等）的分析由医院处的医学专业人员实行。然而，医院可能没有被配备成实行涉及尖端技术的预测性健康数据分析。在这些情况下，健康数据可能需要由第三方供应商或服务来分析。

健康数据分析的各个方面越来越多地在医院外部实行。当使用医院外部的一个或多个第三方处理系统来分析健康数据时，可能需要考虑各种因素以用于在医院之外传递和分析健康数据，该各种因素例如是文件大小、类型、路由、文件充分性（例如，图像质量）、被用于便于选择要传递的文件的应用用户接口（API）、以及隐私。

附加地，（一个或多个）第三方处理系统可能需要鲁棒的平台架构，以便有效地分析和组织来自不同区域（或国家）的许多不同医院的数据。例如，一组特定的健康数据分析、存储和管理能力可能仅存在于与医院区域不同的某个区域中。该所选区域外部的医院可能无权访问分析服务，这是因为患者隐私法规可能规定患者健康数据不能够被传递到所选区域。

因此，期望一种分散式健康数据平台，该平台创建了安全、可缩放、鲁棒、弹性的基础设施，以用于对跨境健康数据的端到端自动化摄取、分析和处理、以及对分析的报告。进一步期望用于提供经指导的分析员工作流程的分散式健康数据平台，以便增强数据分析并且向（一个或多个）医院报告。前述一般描述和以下详细描述仅仅是示例性和解释性的，而不是对本公开的限制。本公开的各种实施例涉及根据一个实施例的在有效地分析、管理和存储在不同地理区域中生成的健康数据的同时保留患者隐私的系统和方法。

发明内容

根据本公开的某些方面，公开了用于在分散式云计算平台上管理跨境健康数据的系统和方法。

一种用于在分散式云计算平台上分析健康数据的方法，该方法包括：接收包含一个或多个匿名DICOM对象的唯一病例文件（case file）以用于分析；基于与一个或多个匿名DICOM对象相关联的优先级来设置该唯一病例文件的优先级水平；对一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，该分析是根据唯一病例文件的优先级水平而完成的。

根据另一个实施例，一种用于在分散式云计算平台上分析健康数据的系统包括：数据存储设备，其存储用于在分散式云计算平台上分析健康数据的指令；以及处理器，其被配置成用于：接收包含一个或多个匿名DICOM对象的唯一病例文件以用于分析；基于与一个或多个匿名DICOM对象相关联的优先级来设置所述唯一病例文件的优先级水平；对一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，该分析是根据唯一病例文件的优先级水平而完成的。

根据另一个实施例，一种在包含计算机可执行编程指令的计算机系统上使用的非暂时性计算机可读介质，该计算机可执行编程指令用于实行在分散式云计算平台上分析健康数据的方法，该方法包括：接收包含一个或多个匿名DICOM对象的唯一病例文件以用于分析；基于与一个或多个匿名DICOM对象相关联的优先级来设置唯一病例文件的优先级水平；对一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，该分析是根据唯一病例文件的优先级水平而完成的。

所公开的实施例的附加目的和优点将部分地在下面的描述中阐述，并且部分地将从该描述中变得明显，或者可以通过实践所公开的实施例而习得。所公开的实施例的目的和优点将借助于在所附权利要求中特别指出的元件和组合来实现和获得。

要理解的是，前述一般描述和以下详细描述两者都仅仅是示例性和解释性的，而不是对所要求保护的公开实施例的限制。

附图说明

图1A描绘了根据本公开的示例性实施例的分散式健康数据管理系统的示例性框图。

图1B描绘了根据本公开的示例性实施例的图1A的健康数据IO系统的示例性示意图。

图1C描绘了根据本公开的示例性实施例的图1A的健康数据分析系统的示例性示意图。

图2图示了根据本公开的示例性实施例的图1C的健康数据分析系统的详细框图。

图3是根据本公开的示例性实施例的用于在图1A的健康数据IO系统101中使网络负载均衡的示例性方法的框图。

图4是根据本公开的示例性实施例的用于接收、分析和报告健康数据的方法的序列图。

图5是根据本公开的示例性实施例的用于管理病例处理的次序的示例性方法的流程图。

图6是根据本公开的示例性实施例的用于使用分散式云计算平台来分析跨境健康数据的方法的流程图。

图7是根据本公开的示例性实施例的用于对来自健康数据分析系统的结果文件进行后处理和报告的示例性方法的流程图。

具体实施方式

现在将详细参考本公开的示例性实施例，其示例在附图中被图示。只要有可能，遍及附图将使用相同的参考数字来指代相同或相似的部分。

本文中使用的术语“示例性”是以“示例”而不是“理想”的含义使用的。此外，本文中的术语“一（a和an）”并不表示对数量的限制，而是表示存在一个或多个所引用的项。出于本公开的目的，“患者”可以指代正在对其实行诊断或治疗分析（例如，数据分析）的任何个体或个人，或者与一个或多个个体的诊断或治疗分析相关联的任何个体或个人。

术语“健康数据”可以包括在一个实践中针对患者所收集的医学数据（例如，医学数字成像和通信（DICOM）对象）、以及由任何医疗保健服务提供者、实验室、专家、临床医生等针对患者所收集的健康数据。健康数据可以与特定患者相关联，其中该患者可经由患者隐私信息来标识。患者隐私信息可以是将健康数据链接到特定个体的任何信息。可以客观地（作为将个体与其健康数据联系起来的信息）和/或根据规章制度和法规来定义患者隐私信息。各个区域可能包括对构成患者隐私信息的信息内容的不同定义。

“区域”可以指代具有由保护患者隐私的法规所限定的边界的任何环境。在一个实施例中，“区域”可以指代由保护患者隐私/个人数据的一组法规所管理的已知地理区域。例如，“区域”可以指代州（例如，加利福尼亚州）、国家（例如，美国、日本、加拿大等）、或根据单独一套患者隐私法运行的一群国家（例如，欧洲）。对于美国而言，患者隐私信息可以包括受保护的健康信息（PHI）。对于美国和各种其他区域而言，患者隐私信息可以包括个人健康信息、患者标识信息等（例如，CT、MRI、超声等）。用于在传输健康数据的同时保护患者健康信息的各种系统和方法在例如2017年6月27日提交的且题为“Systems and Methods forModifying and Reacting Health Data Across Geographic Regions”的美国非临时申请No.15/635,127中被公开，该申请由此通过引用整体地并入本文中。

替代地或此外，“区域”可以指代给定物理设施、给定实体的计算系统、或给定云平台。在这样的情况下，健康数据在它们之间被编校的各个区域可能仍然存在于单个国家、州或省内。例如，区域可以包括医院，该医院可以在将健康数据传递到另一个区域（例如，云平台）以用于数据分析之前，从所收集的健康数据中移除患者隐私信息。医院和云平台可能存在于相同的地理上定义的区域（例如，美国）中。

本公开包括：一种用于在分散式云计算平台上管理健康数据的系统和方法。在一个实施例中，可以使用一个或多个基于云的web服务对健康数据进行预处理、分析和后处理以用于报告。健康数据管理系统可以从一个或多个医院接收健康数据，实行自动健康数据摄取，准备用于分析的健康数据，分析/变换健康数据以准备分析，选择或标识要传递以用于分析的文件，对用于分析的健康数据文件的传递进行定时，确定健康数据文件是否相关，监测健康数据分析的进度或状态，确定对健康数据的所完成分析，以及以其他方式便于医院或DICOM模态与（一个或多个）各种基于云的数据分析web服务之间的交互。在一个实施例中，健康数据可以采用DICOM对象的形式。

在一个实施例中，健康数据管理系统可以将健康数据（例如，DICOM对象）从客户地点（例如，医院、诊所等）传递到（一个或多个）云计算web服务。例如，该系统可以使用DICOM协议直接从CT扫描仪、CT工作站或图片存档和通信系统（PACS）接收健康数据，并且将接收到的健康数据安全传递到云服务。云计算服务可以包括数据分析服务，该数据分析服务可以基于接收到的健康数据导出一个或多个诊断度量或患者推荐。该系统可以进一步检索对所传递的健康数据的所完成分析，从一个或多个云服务聚合分析结果，生成报告，和/或将报告推送到医院系统。

在一个实施例中，健康数据可以包括患者特定的图像数据。在一个场景中，图像数据可以包括关于患者心脏的几何形状的数据，例如，患者主动脉的至少一部分、连接到主动脉的主冠状动脉的近侧部分（以及从其延伸的分支）、以及心肌。在一个实施例中，患者特定的图像数据可以采用DICOM文件的形式。患者特定的解剖数据可以非侵入式地获得，例如，使用非侵入式成像方法。例如，CCTA是一种成像方法，其中用户可以操作计算机断层摄影（CT）扫描仪来查看和创建结构的图像，这些结构例如是心肌、主动脉、主冠状动脉、以及与其连接的其他血管。CCTA数据可以是时变的，例如，以示出脉管形状在心动周期上的改变。CCTA可以用于产生患者心脏的图像。

替代地，可以使用包括磁共振成像（MRI）或超声（US）的其他非侵入式成像方法、或者诸如数字减影血管造影术（DSA）之类的侵入式成像方法来产生患者解剖结构的图像。成像方法可以涉及向患者静脉内注射造影剂，以使得能够标识解剖结构。涉及（例如，由CCTA、MRI等提供的）图像的健康数据可以由第三方供应商（诸如放射学实验室或心脏病专家）、由患者的医师等提供。

也可以非侵入式地根据患者来确定其他患者特定的解剖数据。例如，可以测量生理数据，诸如患者的血压、基线心率、身高、体重、血细胞比容、每搏输出量等。血压可以是患者肱动脉中的血压（例如，使用压力袖带），诸如最大（收缩压）和最小（舒张压）压力。示例性健康数据因此可以包括从成像模态、可穿戴设备、血压袖带、温度计、健身跟踪器、血糖计、心率监测器等收集的数据。

在一个实施例中，准备用于分析的文件和检索所分析的数据可以涉及保留患者隐私。例如，文件准备可以包括从文件中移除患者隐私信息。在一个这样的情况下，健康数据文件可能在生成文件时自动包括患者隐私信息。示例性患者隐私信息可以包括受保护的健康信息（PHI）或等同于PHI的患者隐私数据。在一个场景中，文件准备可以包括在健康数据从医院被传递到健康数据分析系统以用于分析之前剥离患者隐私信息的健康数据文件。在一个实施例中，可以在没有患者隐私信息的情况下生成包括所分析的健康数据的结果报告。报告可以被推送到医院/医院接口，其中报告可以耦合到对应的患者隐私信息。以这种方式，可以在不将患者隐私信息传输到遥远区域的情况下在该遥远区域中实行数据分析。

图1A是根据本公开的示例性实施例的用于在云平台上管理和分析健康数据的分散式健康数据管理系统100的框图。健康数据基础设施可以包括一个或多个健康数据输入输出（IO）系统101（101a-101n）和健康数据分析系统105，其中每一个健康数据输入-输出系统可以是健康数据分析系统105的客户。例如，健康数据分析系统105可以提供服务，该服务包括从健康数据生成所分析的数据（例如，诊断度量、治疗仿真、治疗优化或推荐等）。健康数据输入-输出系统101然后可以将健康数据发送到健康数据分析系统105，以使该服务在所提供的健康数据上实行。

在一个实施例中，一个或多个健康数据IO系统101中的每一个可以位于与健康数据分析系统105的位置不同的区域中。一个或多个健康数据系统101可以通过无线网络103将健康数据作为输入传达到健康数据分析系统105。替代地，健康数据可以通过有线连接被传达到健康数据分析系统105。健康数据IO系统101还可以通过无线网络103接收从健康数据分析系统105输出的所分析的健康数据的报告。

在一个实施例中，（一个或多个）健康数据IO系统101可以均表示不同的预定区域，其中患者隐私信息可能不会从一个区域自由传递到另一个区域。在一个实施例中，可以定义区域的边界，使得患者隐私信息可以在该区域的边界内自由通过，并且一旦通过该区域的边界，患者隐私信息就不能够自由地传递。例如，区域的边界可以基于关于患者隐私信息传递的政府法规。在这样的情况下，区域可以指代物理地理区域（例如，欧洲、日本和美国），其中每个区域的政府可能关于患者隐私信息的传递规定了不同的规则。替代地或此外，健康数据IO系统101可以表示其中边界由健康规范、保险政策、医院政策、和/或地方/州/省法规来规定的区域。例如，健康数据IO系统101可以表示各种设施（例如，不同的医院、医院网络、实验室设施、患者群组等）。健康数据IO系统101与健康数据分析系统105之间的示例性界限（demarcation）可以包括如下实施例：其中在健康数据IO系统101处生成健康数据，并且存在将健康数据传递到健康数据分析系统105以用于分析的技术和法律障碍。

在一个实施例中，每个健康数据IO系统101可以与预设的优先级水平相关联。优先级水平可以规定健康数据被提交以用于审查（例如，如图2中所描述的）、被传输以用于分析（例如，由健康数据分析系统105来分析）的次序、以及所分析的数据的报告可以被集成或递送（例如，从健康数据分析系统105递送到健康数据IO系统101）的次序。一个示例性场景可以包括：健康数据IO系统101a与“高优先级”优先级水平相关联，并且健康数据IO系统101b与“低优先级”优先级水平相关联。在这样的情况下，即使第一健康数据集在第二健康数据集由健康数据IO系统101b生成的同时由健康数据IO系统101a生成，在来自健康数据IO系统101b的第二健康数据集被传递到健康数据分析系统105或由健康数据分析系统105分析之前，第一数据集可以被传递到健康数据分析系统105，并且健康数据分析系统105可以将所分析的数据的报告往回传达到健康数据IO系统101a。

替代地或此外，每个健康数据IO系统101可以与多个优先级水平相关联。例如，健康数据IO系统101a可以包括例如由任务项目（例如，“动作”）、优先级状态（例如，“低优先级”、“高优先级”、“紧急状态”）或标准过程（例如，“检查更新”、“监测更新”等）组织的多个优先级设置。该优先级设置可以在配置健康数据IO系统101a与健康数据分析系统105之间的数据传输通道时被预设。优先级不仅可以指代数据传输的优先级状态，而且还指代要实行数据处理的次序。替代地或此外，优先级设置可以与生成健康数据的设备相关联，该设备由临床医生/医疗保健提供者在生成健康数据时规定、由所请求的分析来规定等。换句话说，DICOM对象的病例文件的优先级可以基于生成一个或多个DICOM对象（与一个或多个匿名DICOM对象相关联）的实体和/或分析病例文件的一个或多个匿名DICOM对象的实体。

健康数据可以由健康数据分析系统105以根据每个健康数据IO系统101内的健康数据集的优先级水平（例如，相对于由健康数据IO系统101产生的其他健康数据集的优先级水平）和根据健康数据IO系统的优先级水平（例如，相对于其他健康数据IO系统的优先级水平）的次序来分析。在一个实施例中，健康数据的类型也可以影响优先级状态。例如，如果发现特定的健康数据集与所存储或先前创建的健康数据集相关联，则无论所存储或先前创建的健康数据集的优先级水平如何，该特定的健康数据集都可以被自动视为“优先的”或“高优先级”。换句话说，优先级设置可以由各种因素组成并且受各种因素影响，并且在健康数据管理系统100中可以存在若干层优先级。

在一个实施例中，在初始化健康数据管理系统100时、或者在初始化健康数据IO系统101与健康数据分析系统105之间的通信时，用户可以规定优先级设置并且定义各种因素如何影响或改变优先级。替代地或此外，健康数据分析系统105可以预定义至少一个或多个优先级设置，使得一些优先级设置跨健康数据分析系统105的所有健康数据IO系统101客户是一致的或默认使用的。

除了优先级之外，在将健康数据从每个健康数据IO系统101上传到健康数据分析系统105期间，其他属性可以与健康数据相关联。与健康数据相关联的属性可以包括例如成像模态、转诊医师、实验测试代码、实验室代码、计费代码、患者健康计划、保险计划等。在一个实施例中，在上传健康数据期间确定的属性可以提示将由健康数据分析系统105运行一个或多个特定算法，这些特定算法要么直接在分析数据时运行、要么以辅助方式运行（例如，在准备数据的报告时运行或在其中接收或报告数据的时序中运行）。

应当领会的是，健康数据IO系统101和健康数据分析系统105可以包括任何类型或组合的计算系统，例如，手持式设备、个人计算机、服务器、集群式计算机器和/或云计算系统。在一个实施例中，健康数据IO系统101和健康数据分析系统105可以包括硬件组装件，包括存储器、中央处理单元（“CPU”）和/或用户接口。存储器可以包括体现在物理存储介质中的任何类型的RAM或ROM，诸如包括软盘、硬盘或磁带的磁存储装置；半导体存储装置，诸如固态盘（SSD）或闪速存储器；光盘存储装置；或磁光盘存储装置。CPU可以包括一个或多个处理器，用于根据存储在存储器中的指令处理数据。

图1B是根据本公开的示例性实施例的图1A的示例性健康数据IO系统101的详细示意性框图。健康数据IO系统101可以由医院接口和移动用户接口109组成，该医院接口包括一个或多个医院计算设备106、数据传输系统（“连接系统”）107。健康数据IO系统101的一个实施例还可以包括web服务112、（一个或多个）报告数据库113和患者健康信息数据库（例如，PHI数据库114）。客户支持用户接口111可以与web服务112通信。web服务112可以由云服务组成。健康数据IO系统101可以进一步包括元数据数据库。健康数据IO系统101的这些组件可以位于与一个或多个医院相同的区域或国家中。

（一个或多个）医院计算设备106可以包括：被配置成收集、发送和/或接收数据的任何类型的电子设备，这些数据包括网站、模型、医学数据、健康记录、多媒体内容等。示例性医院计算设备可以包括医学设备，例如，医学成像设备、医学监测器等。（一个或多个）医院计算设备106还可以包括一个或多个移动设备、智能电话、个人数字助理（“PDA”）、平板计算机、或任何其他种类的启用触摸屏的设备、个人计算机、膝上型计算机和/或服务器。在一个实施例中，（一个或多个）医院计算设备106中的每一个可以具有为了接收和显示从附属于健康数据IO系统101的一个或多个web服务器接收到的电子内容而安装的web浏览器和/或移动浏览器。（一个或多个）医院计算设备106还可以包括客户端设备，该客户端设备可以具有被配置成执行web或移动浏览器的操作系统，以及任何类型的应用，例如，移动应用。在一个实施例中，（一个或多个）各种医院计算设备106可以配置有网络适配器以传送数据或所分析的报告。替代地或附加地，（一个或多个）各种医院计算设备106可以被配置成通过本地网络连接来传输数据或接收所分析的数据。

在示例性实施例中，医院设备可以是安装在医院内的计算机断层摄影（CT）扫描工作站、CT扫描仪、或图片存档和通信系统（PACS）系统。在一个实施例中，（一个或多个）医院计算设备106可以通过无线网络将健康数据上传到连接系统107。连接系统107可以用作健康数据IO系统101/（一个或多个）医院计算设备106与健康数据分析系统105之间的连接（例如，通过将（一个或多个）医院计算设备106生成的DICOM对象推送到远程健康数据分析系统105）。

在一个实施例中，健康数据可以从医院计算设备106被上传到连接系统107。例如，可以将DICOM研究（包括CT扫描）从DICOM模态医院计算设备106推送到连接系统107。连接系统107可以创建对应于DICOM研究的新病例文件。此外，连接系统107可以提示在健康数据分析系统105处创建新的病例账户或文件。在替代实施例中，连接系统107可以查询（一个或多个）医院计算设备（诸如，CT工作站、CT扫描仪和PACS），并且从（一个或多个）这样的计算设备拉取健康数据（例如，DICOM对象）。在一个实施例中，医院计算设备可以与保存DICOM对象的web服务器通信。连接系统107可以从该web服务器推送或拉取DICOM对象。

在一个实施例中，连接系统107可以以规则的时间间隔与web服务器通信，以经由该服务器拉取任何可用的DICOM对象。替代地或此外，与生成DICOM对象相关联的处理器可以与连接系统107进行本地通信，其中，当生成或存储DICOM对象时，可以提示连接系统107拉取DICOM对象。

替代地或此外，拉取机制可以进一步由针对任何任务的请求（例如，针对DICOM对象的分析）来发起。在一个实施例中，DICOM对象可以与各种数据相关联，该数据例如是分析的优先级、要进行的病例研究的类型、患者扫描/图像、患者隐私信息等。该数据可能是被包括在DICOM对象文件中的元数据或标签。DICOM对象的这种组件可能会影响文件被发送以用于分析的次序。在一个实例中，DICOM对象可以被存储，直到请求了数据分析为止。用于将病例传输到健康数据分析系统105的拉取机制可以由与每个DICOM对象相关联的（一个或多个）病例优先级水平或（一个或多个）病例类型来支配。例如，健康数据可以用“类型”来标记，该“类型”可以基于数据类型或优先级设置所规定的速率或次序来拉取数据以用于分析。示例性类型可以包括以下各项：紧急情况、优先的、回顾性（retrospective）、紧迫的、低优先级、测试、研究、商业、标准、演示、板载（onboarding）、监测、前瞻性、临床研究。类型可以是堆叠式的，例如，“紧迫”病例可以进一步被归类为“紧急情况”或“优先的”，其中“紧急情况”可以指示由于患者的健康状况处于危及状态所致的高优先级，并且“优先的”可以指示针对除了患者的直接健康状况之外的原因而需要加快分析。病例类型的设置可以在（一个或多个）医院计算设备106、移动用户接口109处和/或由连接系统107来设置。拉取机制可以被配置成最小化健康数据IO系统101、连接系统107和健康数据分析系统105的重叠数据拉取或过载。

替代地或此外，医院用户或临床医生可以使用移动用户接口109将健康数据上传到连接系统107。移动用户接口109可以是面向客户的web接口（例如，朝向医院用户）。移动用户接口109可以向一个或多个用户呈现登录接口、实行密码管理、显示病例列表、搜索、显示病例细节，以及显示用户简档。移动用户接口109还可以用于访问包含与患者相关联的所分析数据的报告。移动用户接口109可以包括移动应用。

在一个实施例中，由（一个或多个）医院计算设备106生成的数据可以与患者隐私信息相关联，并且DICOM对象的患者隐私信息可以对于web服务112可获得，但是对于从健康数据IO系统101外部的实体不可获得或不可访问。例如，连接系统107可以从DICOM对象提取患者隐私信息（例如，PHI数据），并且存储患者隐私信息，使得它对于健康数据IO系统101内的web服务112（例如，PHI数据库114）是可获得的。例如，连接系统107可以从DICOM图像中拆分包含患者隐私信息的DICOM标签。包含患者隐私信息的DICOM标签可以用预定义的字符串来替换。作为替代实施例，web服务112可以从连接系统107接收DICOM对象，并且从DICOM对象中提取患者隐私信息。web服务112可以进一步将患者隐私信息存储在数据库（例如，PHI数据库114）中。在示例实施例中，区域特定的客户服务提供者可以有权使用客户支持用户接口111来访问患者隐私信息（PHI）和（一个或多个）患者结果报告。

在一个实施例中，连接系统107可以使用部署在健康数据IO系统101（例如，与医院相关联的区域）中的应用编程接口（API）来创建病例文件以用于数据分析。从该病例的（一个或多个）DICOM文件中剥离的患者隐私信息可以被提交给API，该API可以将所提交的患者隐私信息存储到患者隐私信息数据库（例如，PHI数据库114）。一旦处理了病例（例如，健康数据分析系统105分析了（一个或多个）DICOM文件的数据），病例/分析完成就可以触发在健康数据IO系统101中部署的报告过程，这意味着可以使用所分析的数据以及存储在患者隐私信息数据库（例如，PHI数据库114）中的患者隐私信息来生成报告。在一个实施例中，可以使用API来检索患者隐私信息。

患者隐私信息可能始终保留在其中生成了病例的健康数据（例如，DICOM对象）的区域或从其中推送了健康数据的区域中。患者隐私信息可以被存储在每一个区域（例如，图1A的健康数据IO系统101）中的存储服务桶（bucket）和/或患者隐私信息数据库中。

在一个实施例中，所有患者隐私信息可以在传输中和休息时被加密。在一个实施例中，针对患者隐私信息的存储服务桶可以具有启用的服务器侧加密，使得每次存储新对象时可以发生加密。患者隐私信息数据库（例如，PHI数据库114）也可以提供加密服务，其中患者隐私信息可以在存储时以及在每次访问患者隐私信息时被加密。

在一个实施例中，在其中存储了患者隐私信息的区域外部，可能不能访问该患者隐私信息。例如，在日本提交了病例的用户可能能够在他/她处于另一个区域（例如，欧洲）时访问各种web服务，但是该用户可能不能够在他/她处于另一个区域时访问健康数据管理系统100的患者隐私信息。

在示例实施例中，web服务112可以从健康数据分析系统105接收所分析的数据的报告。例如，web服务112可以确定所完成的报告在报告数据库113中是可获得的。在一个实施例中，所完成的报告可以与唯一病例标识符相关联。在一个实施例中，web服务112可以使用唯一病例标识符从与检索到的病例结果相关联的PHI数据库114中检索患者隐私信息。web服务112可以进一步将PHI数据与结果报告进行集成，和/或将该报告存储在报告数据库113中。web服务112可以进一步将该报告与患者隐私信息一起或与唯一病例标识符一起存储在报告数据库113中。在一个实施例中，健康数据IO系统101可以进一步包括元数据数据库。元数据数据库可以包括与每个报告或健康数据集相关联的元数据。元数据可以包括与在数据创建时已知的健康数据相关联的数据，例如，数据被创建或成像的时间、保险计划、计费信息等。元数据还可以包括在（例如，由健康数据分析系统105）对健康数据的分析过程中创建的数据，例如，来自医师或审查者的笔记或标记物、来自健康数据预处理的销钉物（pin）（例如，如果解剖模型是从健康数据构建的）等。

在一个实施例中，web服务112可以包括报告队列监测器，该报告队列监测器可以应用报告被访问或使报告可供使用（例如，由临床医生、医疗保健人员、患者等使用）的次序或优先级。该优先级可以由（一个或多个）用户或web服务（例如，web服务112）来设置。在一个实施例中，报告队列可以按照病例优先级的次序（由病例“类型”决定的那样）来管理病例。健康数据IO系统101可以进一步包括客户支持用户接口111。客户支持用户接口111可以对于客户支持提供者（例如，客户支持人员）是可访问的。在一个实施例中，患者隐私信息和/或患者报告可以经由虚拟专用网络（VPN）来访问，该虚拟专用网络被配置成用于由客户支持提供者使用。例如，客户支持人员可以具有通过利用VPN服务来单独地登录每个区域的能力。VPN服务可以将对特定区域的患者隐私信息的访问扩展到客户支持提供者，即使客户支持提供者并没有从其处生成了健康数据的特定区域来访问患者隐私信息。

图1C是根据本公开的示例性实施例的健康数据分析系统105的示意性框图。健康数据分析系统105可以由病例处理器121、一个或多个分析web服务123、匿名临时存储装置124a、匿名永久存储装置124b、同步处理器125和建模工作站127组成。健康数据分析系统105可以进一步提供对分析员或客户支持人员的用户接口，用于查看和/或访问来自一个或多个分析web服务123的数据。在一个实施例中，用户接口可以包括生产用户接口129和/或客户支持用户接口131。

健康数据分析系统105可以用作用于分析来自至少一个跨境区域的匿名健康数据（例如，经由连接系统107）的一个或多个云平台。更具体地，（一个或多个）分析web服务123可以计算结果并且生成报告（例如，3D模型、PDF等），以向患者、临床医生或用户呈现分析和结果。例如，一个或多个分析web服务123可以使用从心脏CT扫描接收到的图像数据来计算冠状动脉内的血流。例如，在2012年11月20日授权的题为“Method and System forPatient-Specific Modeling of Blood Flow”的美国专利No.8,315,812中公开了使用图像重建和解剖模型的诊断分析的各种实施例，该专利通过引用整体地并入本文。一个或多个分析web服务123可以提供由（一个或多个）分析web服务123实行的分析的结果的报告。对于上面描述的分析，报告可以包括示出了所计算的血流储备分数（FFR）值的冠状动脉交互式3D模型和/或PDF报告。示例性报告可以包括表面模型、图形、图表、颜色编码、指示器、交互式显示、警报、信号或任何已知的图形对象。例如，在2014年4月22日授权的题为“Methodand System for Providing Information from a Patient-Specific Model of BloodFlow”的美国专利No.8,706,457中公开了图形表示和显示的各种实施例，该专利通过引用整体地并入本文。

在示例实施例中，与病例处理器121相关联的一个或多个处理器可以从接收到的DICOM对象生成一个或多个中间结果。在示例实施例中，同步处理器125可以同步来自一个或多个处理器的中间结果，并且该中间结果可以经由建模工作站127来访问以用于查看。在示例实施例中，同步处理器125可以是从处理病例的人（例如，技术人员或分析员）可访问的用户接口所启动的应用。在一个实施例中，同步处理器125可以进一步针对每个特定病例启动建模工作站127。同步处理器125可以确保一个或多个分析web服务123与建模工作站127之间的正确通信。在示例实施例中，分析员可以查看来自病例处理的中间结果，更新由病例处理器121生成的结果，或者经由病例处理器121提交重新分析病例的请求。

在示例实施例中，健康数据分析系统105可以包括多个前端，该多个前端包括生产用户接口129和客户支持用户接口131。在示例实施例中，生产用户接口129可以用作针对（一个或多个）分析web服务123的质量控制和病例分析员的内部前端。生产用户接口129还可以用作去往健康数据分析系统105的（一个或多个）内部处理应用的门户。在一个场景中，生产用户接口129可以向分析员提供如下能力：即，在将病例提供给客户之前处理病例、管理优先级以及报告和审查病例。生产用户接口129还可以便于分析员验证分析结果，例如，通过标识可能具有相对低的统计置信度的分析结果，并且提示分析员审查分析结果（或对分析结果的审查进行优先级排序）来进行。客户支持用户接口131可以用作针对地点创建、用户管理和仪表板化（dashboarding）的内部前端。客户支持用户接口131可以由支持员工使用，以例如通过连接系统107（在图1B中示出的）来监测和管理地点和机构。在一个实施例中，支持用户接口131还可以管理数据隔离，例如，用于产品测试、开发或其他工具开发功能。例如，病例可能具有一个或多个标签，例如，隔离的、受限的或一般的。这些标签可以在创建病例时生成。每个病例报告完成之后，可以使用或更新这些标签，以查看原始数据或所分析的数据是否可以用于未来的开发/分析。客户支持用户接口131还可以生成在给定或所选时间段内处理的病例的报告，例如，用于内部使用或会计，以运行免费、按合同、为了支付、为了研究等而生成的（一个或多个）病例的报告。

图2描绘了根据本公开的示例性实施例的图1C的健康数据分析系统105的详细框图200。在示例实施例中，连接系统107可以从病例文件的DICOM对象中提取患者隐私信息，使得该病例文件是匿名的。连接系统107然后可以使用HTTP或HTTPS安全超文本传输协议（HTTPS）将匿名病例文件发送到健康数据分析系统105。在一个实施例中，连接系统107可以创建针对匿名病例文件的唯一病例标识符，使得可以使用唯一病例标识符而不是使用患者隐私信息来跟踪匿名病例文件。

在示例实施例中，病例处理器121可以使用预加载处理器202、（建模工作站127）、预求解处理器204、求解处理器206、后求解处理器207和报告处理器208来处理每个病例的DICOM对象。在示例实施例中，可以根据所设置的病例优先级、通过预加载处理器202、预求解处理器204、求解处理器206、后求解处理器207和报告处理器208来处理病例。在示例实施例中，医院临床医生或管理员可以使用web接口来录入针对一个或多个DICOM对象源CT扫描仪、CT工作站或PACS的优先级设置。在替代实施例中，可以根据医院中的医院设备的位置来自动设置优先级。可以使用无状态协议将优先级发送到病例处理器121。在每个阶段或处理中，可以根据优先级对病例进行排队，并且可以在较低优先级的病例之前对高优先级病例进行处理。替代地或此外，可以在该过程的任何阶段处编辑病例优先级。

在一个实施例中，预加载处理器202可以准备或验证接收到的DICOM文件已准备好用于分析。例如，预加载处理器202可以对从连接系统107接收到的DICOM文件进行解压缩（或解压）。在一个实施例中，连接系统107也可以具有对DICOM文件进行解压缩的能力，但是相对于连接系统107，预加载处理器202可以提供用于对DICOM文件进行解压缩的更安全的环境。预加载处理器202还可以对DICOM文件的质量实行以下验证，该验证关于满足将由健康数据分析系统105实行所请求的分析所必需的最小阈值。例如，血流分析可能需要满足最小预定阈值的CT图像质量，以便使所得到的血流度量在临床上是准确的。斑块检测分析可以具有较低的图像质量的预定阈值，以使结果对于患者有用。在一个实施例中，连接系统107可以自动拒绝接收到的健康数据。作为另一个实施例，预加载处理器202还可以具有自动拒绝接收到的健康数据的能力。例如，如果健康数据缺失DICOM图像、具有不正确的图像间隔、不正确的z定位等，则预加载处理器202可以拒绝病例。如果DICOM对象未能满足预加载处理器202的质量评估，则连接系统107可以接收DICOM文件被拒绝用于分析或者不能够使用上传的DICOM对象来实行分析的通知。在一个实施例中，可以提示健康数据IO系统101生成或上传新的或更新的DICOM文件以用于分析。例如，可以提示移动用户接口109将病例显示为“返回”。作为另一个示例，“返回”病例可以包括成像质量拒绝报告，包括健康数据被拒绝用于分析的原因。如果发送了被接受的新健康数据，则可以创建新病例实体，并且可以将任何相关联的数据拷贝到新病例/重复病例。

在一个实施例中，如果经解压缩的DICOM文件具有满足预定阈值准确度或图像质量水平的准确度或图像质量水平，则经解压缩的DICOM文件可以被直接传递到预求解处理器204。如果文件不满足（一个或多个）预定准确度或图像质量阈值水平，则文件可以被传递到建模工作站127以用于手动处理，例如，使用工作站来创建网状物（解剖模型）。在一些实施例中，由建模工作站127创建的网状物模型然后可以被传递到预加载处理器202。

在一个实施例中，预求解处理器204可以实行初步计算以将图像文件转换成用于所请求的分析的形式。例如，健康数据分析系统105的血流分析可以基于患者脉管系统的3维（“3D”）模型。预求解处理器204可以将原始DICOM图像文件转换成用于血流分析的3D体积模型。在一个实施例中，预求解处理器204可以进一步生成四面体元素的网状物和/或确定要用于分析的初始边界条件。在一个实施例中，预求解处理器204可以与建模工作站127通信，以便呈现模型以用于由健康数据分析系统105的分析员来验证。如果所请求的分析包括血流仿真，则预求解处理器204可以确定沿着患者脉管系统的3D模型的各种位置的初始边界条件。

在一个实施例中，求解处理器206可以启动对由预求解处理器204呈现的准备好的模型的分析。例如，求解处理器206可以通过由预求解处理器204产生的3D模型来产生血流仿真。在一个实施例中，求解处理器206可以与（一个或多个）分析web服务123对接以实行分析。在一个实施例中，求解处理器206可以包括后求解处理器，该后求解处理器可以聚合由求解处理器206实行的分析，并且将所聚合的分析打包以用于报告处理器208。例如，后求解处理器可以标识与由求解处理器206实行的当前分析相关的先前分析或所存储的分析。这些分析可以经由所实行的分析类型（例如，血流仿真或灌注仿真）、通过与患者或患者人口统计学的关联而链接的分析等进行相关（尽管数据可以被匿名化（例如，与患者隐私信息脱离），但是通过跟踪或散列化与匿名化数据相关联的唯一ID，各种数据集仍然可以被标识为与相同个体相关联）。分析可以包括用户特定的血流和可能的治疗后果的图像和模型。在一个实施例中，报告处理器208可以生成视图、显示、销钉物、PDF和/或交互式接口和模型，它们可以构成由求解处理器（和后求解处理器）206实行的评估的最终报告。报告处理器208可以允许在求解处理器206所生成的分析中进行审查和修订。

在一个实施例中，病例处理器的每个组件可以具有（一个或多个）对应的队列监测器201（例如，对应于预加载处理器202的预加载队列处理器203、对应于预求解处理器204的预求解队列处理器205、对应于求解处理器206的求解队列处理器207a和后求解队列处理器207b、以及对应于报告处理器208的报告队列处理器209）。（一个或多个）队列监测器201可以通过它们的每一个对应组件来推进病例。例如，预加载队列处理器203可以通过预加载处理器202来规定每个图像数据集的进度。在一个实施例中，API可以用于随着每个病例通过分析的状态而推进时捕获每个病例的状态。

（一个或多个）队列监测器中的每一个可以周期性地轮询可从病例处理器的其相应组件获得的病例的指示，并且从存储装置下载相关数据。例如，预加载队列处理器203可以检测到新的DICOM数据集已经被上传。预加载队列处理器203然后可以下载该新数据集，并且提示预加载处理器202验证该数据集满足图像质量要求。预加载队列处理器203可以从预加载处理器202检测到该数据集满足图像质量标准，并且发起来自预求解处理器204的动作以基于该数据集生成几何或体积模型。同样地，求解队列处理器207a可以检测到几何或体积模型可用并且适合于分析，并且因此提示求解处理器206（和分析web服务123）发起对通过几何或体积模型对血流进行仿真的分析。在一个实施例中，后求解队列处理器207b可以通过求解处理器206来检测分析的完成。后求解队列处理器207b然后可以提示后求解处理器207验证结果。在一些实施例中，该验证可以包括将结果呈现给建模工作站127以供分析员确认分析后果。报告队列处理器209可以发起报告处理器208根据经验证的结果对报告的创建。

在一个实施例中，队列监测器201可以进一步根据针对接收到的病例设置的一个或多个优先级来处理一个或多个接收到的病例（例如，DICOM对象）。例如，优先级可以由健康数据IO系统101设置，和/或优先级可以与针对健康数据所请求的分析相关联地设置。（一个或多个）队列监测器可以管理数据分析的每个阶段，这取决于指派给每个病例的优先级。例如，处于预求解处理器阶段处的低优先级病例可以保留在预求解处理器阶段处，而随后的高优先级病例在低优先级病例之前被路由到求解处理器阶段。（一个或多个）队列监测器进一步监测分析web服务123的带宽，使得以稳定的步伐来处理病例。

图2中的监测处理器210可以负责监测病例处理和分析的状态。当通过预加载处理器202、预求解处理器204、求解处理器206和报告处理器208来处理病例时，监测处理器210可以在每一级别处监测病例的状态（例如，成功、失败等）。在示例实施例中，监测处理器210可以由一个或多个授权的用户使用远程命令来调用或禁用。监测处理器210可以在仅仅出于执行远程命令的目的而被专门创建成具有有限权限的用户的情境下执行命令。监测处理器210可以向与（一个或多个）前端用户接口相关联的一个或多个API通知病例的状态（例如，DICOM对象分析）。监测处理器210可以使用在一个或多个处理阶段处通过唯一病理生成的一个或多个状态消息（例如，成功、失败等）来生成一个或多个自动处理事件。

图3是根据本公开的示例性实施例的负载均衡以便桥接前端（包括临床用户接口（例如，移动用户接口109或客户支持用户接口111、web服务112、分析web服务123、或任何云、本地、分析web服务））、数据库和后端（例如，web服务或病例处理器）之间的通信的示例性框图300。在一个实施例中，健康数据管理系统100可以水平地缩放其API 307（例如，API307a-307c）。例如，健康数据管理系统100可以采用弹性负载均衡器301，该弹性负载均衡器301可以使用在负载均衡器305之后提供的较低简档的多个代理机器303，该负载均衡器305可以跨API 307有效地分配网络负载。替代地或此外，健康数据管理系统100可以包括高级机器硬件，用于处理健康数据管理系统100所遇到的负载。

图4描绘了根据本公开的示例性实施例的用于接收、分析和报告健康数据的示例性方法400的序列图。在示例实施例中，可以将DICOM对象从一个或多个医院计算设备106推送到连接系统107。一旦连接系统107接收到DICOM对象（例如，步骤401），连接系统107就可以创建与DICOM对象相关联的新病例文件。可以遍及DICOM对象分析的进展对该病例文件进行监测。也可以通过分析对病例文件进行监测，直到最终报告可获得为止。

在一个实施例中，连接系统107可以从DICOM对象中提取患者隐私信息（例如，PHI数据）（例如，步骤403）。在这样做时，可以将DICOM对象匿名化。在一个实施例中，可以使用可以允许无状态操作的服务将患者隐私信息发送到区域特定的云平台（例如，web服务112）。例如，可以经由代表性状态转移（REST）应用编程接口（API）将患者隐私信息发送到区域特定的云平台。区域特定的云平台可以将患者隐私信息存储在本地关系数据库（例如，被构造成识别所存储的信息项当中的关系的数据库）中。PHI数据库114是这种本地关系数据库的一个示例。例如，在2017年6月27日提交的题为“Systems and Methods for Modifyingand Reacting Health Data Across Geographic Regions”的美国非临时申请No.15/635,127中公开了用于将DICOM对象匿名化的各种系统和方法，该申请通过引用整体地并入本文中。

在一个实施例中，步骤405可以包括向预加载处理器（例如，预加载处理器202）发送匿名化DICOM对象。在一个实施例中，连接系统107和/或预加载处理器202可以根据预配置的验证标准对DICOM对象进行解压缩和验证。验证标准可以取决于要对DICOM对象实行的分析。

在一个实施例中，预加载处理器202可以进一步从接收到的DICOM对象准备体积图像文件（例如，步骤407）。在一个实施例中，预加载处理器202可以进一步生成可能关于一个或多个体积图像文件的压缩存档文件。在一个实施例中，压缩存档文件可以包含对应于（一个或多个）体积图像文件的信息。该信息可能关于（一个或多个）体积图像文件的分析。例如，压缩存档文件可以包括用户日志、任务状态、可以使用体积图像文件实行的处理的类型等。用户日志可以包括文件的历史，包括对体积图像文件实行的先前处理、（一个或多个）用户对模型实行的动作等。任务状态可以包括用于生成体积图像文件的每个任务的状态、以及在每个任务中花费的时间。示例性任务可以包括以下各项：标识主动脉、标识脉管界标、标识心肌组织、标识中心线、标记脉管系统、审查管腔几何形状、最终确定模型等。可以使用体积图像文件实行的处理的类型可以由健康数据IO系统101、健康数据IO系统101的特定用户、或健康数据分析系统105来规定，或者由接收到的数据的类型来规定。例如，步骤407可以包括校正接收到的数据中的误配准、或具有预设操作，例如，如果接收到的数据仅包括一个对象阶段，则更多地处理文件。在一个实施例中，对经验证的DICOM对象或体积图像文件的操纵准备了经验证的DICOM对象以用于分析（例如，由健康数据分析系统105来分析、或由建模工作站127进行清理）。在一个实施例中，经处理的图像可以被发送到建模工作站127以用于对图像质量进行附加检查。该附加检查可能会导致图像验证的拒绝。在一个实施例中，连接系统107可以实行对接收到的图像的第一级别验证，并且预加载处理器202可以实行图像相关的验证（例如，检查在接收到的数据中是否有任何解剖间隔或厚度是错误的）。在一个实施例中，建模工作站127可以进一步检查图像数据，例如，针对呼呼状（whirring）或图像伪影来检查。在一个实施例中，压缩存档文件与体积图像文件之间的对应性或链接可以使用校验和来维持。校验和可以由预加载处理器202、连接系统107、API、或系统100的任何组件来计算。在一个实施例中，预加载处理器202的体积图像文件可以例如经由建模工作站127呈现给分析员。例如，步骤409可以包括使用建模工作站127的用户接口来呈现一个或多个体积图像文件。在一个实施例中，建模工作站127可以用于生成患者特定的解剖模型（例如，步骤411）。该模型可以包括患者脉管系统的三维（3D）几何形状（例如，患者冠状动脉树的3D网状物模型）。在一个实施例中，可以使用一个或多个自动化图像分析算法从（一个或多个）体积图像文件生成患者特定的3D模型。

在一个实施例中，建模工作站127可以将3D模型呈现给分析员以用于审查（例如，经由生产用户接口129）。建模工作站127可以在一系列验证屏幕中呈现3D模型，并且提示分析员批准或拒绝该模型的各个部分。在一个实施例中，建模工作站127可以接收来自分析员的输入，并且将分析员的响应存储在压缩存档文件中（例如，作为用户日志的一部分）。输入可以包括来自分析员的病例笔记。在示例实施例中，如果该模型未被批准，则建模工作站127可以提示重新上传DICOM对象。例如，一个或多个医院计算设备106可以接收生成（一个或多个）附加DICOM对象的提示（例如，经由移动用户接口109）。在替代实施例中，建模工作站127可以向预加载处理器202传达重新生成体积图像文件的请求。在示例实施例中，建模工作站127可以将3D模型和病例笔记转换成例如可扩展标记语言（XML）文件。来自建模工作站127的输出可以用于分析（例如，对血流进行仿真并且产生一个或多个血流度量）。

一旦3D模型被批准，预求解处理器（例如，预求解处理器204）就可以实行一个或多个操作，以进一步为健康数据分析系统105进行的分析做准备。在一个实施例中，预求解处理器可以接收经批准的3D模型（例如，步骤413），并且生成针对通过3D模型的血流仿真的边界条件（例如，步骤415）。在一个实施例中，预求解处理器可以使用一个或多个分析算法来从3D模型（其可以处于XML文件中）生成四面体元素的网状物。预求解处理器204可以计算要用作对血流仿真计算的输入的初始边界条件集。预求解处理器204然后可以将初始边界条件传达给求解处理器（例如，步骤417）。

在一个实施例中，求解处理器（例如，求解处理器206）可以实行分析（例如，在采用（一个或多个）分析web服务123的同时）。例如，求解处理器206可以使用四面体元素的三维（3D）网状物模型以及初始边界条件来实行血流仿真（例如，步骤419）。在一个场景中，求解处理器206可以基于血流仿真来计算一个或多个血流度量。血流度量可以包括血流储备分数（FFR）、血压、血流速度、灌注、（一个或多个）斑块易损性度量等。

在一个实施例中，求解处理器206的分析结果可以由后求解处理器（例如，后求解处理器207）接收和编译。例如，求解处理器206可以将来自血流仿真分析的所计算的血流度量作为结果发送到后求解处理器（例如，步骤421）。在一个实施例中，后求解处理器（例如，后求解处理器207）可以聚合由求解处理器206生成的一个或多个文件（例如，步骤423）。后求解处理器207可以进一步从分析文件中移除在最终报告中不期望的项，包括该仿真中的可能对最终结果没有贡献的笔记或销钉物。

替代地或此外，报告处理器（例如，报告处理器208）可以聚合结果数据，并且针对所完成的分析准备报告（例如，步骤423）。例如，报告处理器208可以生成所完成的分析的报告，包括具有指向感兴趣区的自动化销钉物的（一个或多个）初始模型视图、以及PDF文件。例如，报告处理器208可以定位所建模的脉管系统中的狭窄区（例如，基于包括血流仿真或计算的分析）。

在一个实施例中，步骤427和429可以包括呈现所生成的报告和销钉物以用于审查和编辑（例如，经由生产用户接口129）。注释可以由报告处理器208自动生成。在一个实施例中，可以例如在生产用户接口129处修改3D模型报告。例如，生产用户接口129可以提示分析员审查该报告，并且调整针对（一个或多个）各种模型视图中的相关性区域（例如，主血管）的一个或多个销钉物的方位。附加地，生产用户接口129可以提供向（一个或多个）报告添加更多销钉物或笔记、创建（一个或多个）相关视图、以及生成包含分析（例如，血流仿真）的细节的（一个或多个）PDF报告的能力。PDF报告可以被提供给健康数据IO系统101以用于存储（例如，在图1B的报告数据库113处）和访问（例如，经由一个或多个移动用户接口109）。附加地，如果分析员对结果不满意，则可以提示进行分析。在示例实施例中，重新触发分析可以将病例往回转变成预加载状态、建模状态、预求解状态、求解状态、后求解状态、或报告状态中的任一个（例如，步骤431）。在一个实施例中，如果接收到的未处理数据的病例满足预设的必需准确度或图像质量水平，则可以绕过手动干预（例如，经由建模工作站127）。在通过了预求解处理器204、求解处理器206和后求解处理器207的操作之后，可以将报告递送给客户（例如，通过报告处理器208）。这样的实施例可以绕过进一步的审查（例如，由建模工作站127对报告或报告中的销钉物的审查）。

在示例实施例中，病例监测器（例如，病例处理器121）429可以向健康数据IO系统101的API通知报告完成。在一个实施例中，报告可以与患者隐私信息（例如，PHI数据库114的PHI）相匹配，并且患者隐私信息可以被集成到报告中。然后，可以将报告推送到做出请求的医院工作站、PACS或HL7引擎/代理者，以便由患者和/或医疗保健专业人员来访问。

图5是根据本公开的示例性实施例的用于（由健康数据分析系统105）管理病例处理的次序的示例性方法的流程图。在一个实施例中，步骤501和503可以包括：接收第一匿名化DICOM对象，并且标识与第一匿名化DICOM对象相关联的优先级水平。匿名化DICOM对象可以包括没有患者隐私信息的一个或多个图像文件。在一个实施例中，优先级水平可以与生成了DICOM对象的健康数据IO系统101相关联。例如，在健康数据IO系统101与健康数据分析系统105之间建立通信时，可以配置（一个或多个）各种优先级水平。优先级水平可以进一步由分析或请求分析的医疗保健服务提供者来设置。例如，健康数据IO系统101可以提示用户设置与所生成的DICOM对象相关联的优先级水平。

在一个实施例中，步骤505和507可以包括：接收第二匿名化DICOM对象，并且标识与第二DICOM对象相关联的优先级水平。步骤509可以包括：确定首先处理哪个病例（例如，在健康数据分析系统105处）。在一个实施例中，步骤509可以包括将与第一匿名化DICOM对象相关联的优先级水平与跟第二匿名化DICOM对象相关联的优先级水平进行比较。如果第一匿名化DICOM对象的优先级水平高于与第二匿名化DICOM对象相关联的优先级水平，则可以在对第二匿名化DICOM对象的分析之前针对第一匿名化DICOM对象发起分析（例如，步骤511）。例如，步骤511可以包括（例如，图2的）队列监测器201在通过病例处理器121的步骤进展来推动第二匿名化DICOM对象之前，通过病例处理器121的各种组件对第一匿名化DICOM对象进行排队以用于处理。例如，第一匿名化DICOM对象可以在第二匿名化DICOM对象之前经历由预加载处理器202进行的验证、针对预求解处理器204进行的分析的准备、由求解处理器206进行的分析、或其组合的步骤之一。基于第一匿名化DICOM对象的分析的报告也可以在基于第二匿名化DICOM对象的最终报告完成之前被生成并且使其对于健康数据IO系统101是可获得的。

如果第一匿名化DICOM对象的优先级水平低于与第二匿名化DICOM对象相关联的优先级水平，则可以在对第一匿名化DICOM对象的分析之前针对第二匿名化DICOM对象发起分析（例如，步骤513）。例如，第二匿名化DICOM对象可以在第一匿名化DICOM对象之前经历通过预加载处理器202、预求解处理器204、求解处理器206、报告处理器208或其组合的处理中的至少一个。

图6是根据本公开的示例性实施例的用于在云计算平台上有效地分析跨境健康数据的示例性方法的流程图。在一个实施例中，步骤601可以包括：接收健康数据作为包含一个或多个DICOM对象的唯一病例文件。该病例文件可以包括与其相关联的一个或多个优先级水平，其中（一个或多个）优先级水平可以规定病例在健康数据分析系统105处通过分析的次序。在一个实施例中，可以针对接收到的健康数据（例如，DICOM对象）生成唯一病例标识符。

在一个实施例中，步骤603可以包括：从接收到的数据来解压缩和提取DICOM图像。在一个实施例中，步骤603可以包括：针对每个唯一病例，从所提取的DICOM图像来生成压缩存档文件。该压缩存档文件可以包括定制文件，该定制文件包含报头文件、一个系列选择文件、历史文件（例如，用户日志）、任务状态文件、过程ID文件、表示已经被处理的一系列计算的一组（n>=1）文件夹等。取决于接收到的健康数据，压缩存档文件还可以包括一个或多个体积图像文件。例如，如果健康数据是由CT扫描仪生成的，则压缩存档文件可以包括一个或多个包括CT扫描的体积图像文件。

在一个实施例中，步骤603可以包括验证接收到的唯一病例的一个或多个DICOM对象。例如，如果DICOM对象缺失DICOM图像，如果DICOM对象的DICOM图像大小超出所定义的范围，或者如果DICOM图像不满足所定义的质量标准，那么DICOM对象可能被视为无效。在一个实施例中，步骤603可以包括：设置与可从健康数据分析系统105（例如，经由（一个或多个）分析web服务123）获得的每个分析相关联的一个或多个质量标准。例如，如果由健康数据分析系统105提供的分析包括：基于从DICOM对象构建的解剖模型来实行血流仿真，则步骤603可以包括用于构建解剖模型的最小图像质量要求，该解剖模型将呈现可以在临床上使用的仿真结果。步骤603可以进一步包括：基于图像质量参数来生成置信度参数。例如，步骤603可以包括：评估接收到的（一个或多个）DICOM对象的图像质量，并且将接收到的（一个或多个）DICOM对象的图像质量得分与预定图像质量要求进行比较。步骤603可以进一步包括：确定（一个或多个）DICOM对象的图像质量得分满足预定图像质量要求，并且基于确定（一个或多个）DICOM对象的图像质量得分来生成包括血流仿真结果的置信度得分的元数据标签。步骤603可以进一步包括：确定（一个或多个）接收到的DICOM对象无效。步骤603然后可以包括：生成提示以重新取得或重新提交用于该用例的健康数据。该提示可以被直接发送到医院计算设备106，或者该提示可以经由用户接口被发送给用户。

在一个实施例中，步骤605可以包括：对DICOM对象进行预处理。例如，步骤605可以包括：确定要使用接收到的DICOM对象实行的分析；步骤605可以进一步包括：对DICOM对象进行预处理，从而为所确定的分析做准备。例如，如果分析包括血流仿真，则预处理步骤可以包括基于DICOM对象来生成解剖模型。该解剖模型可以包括3D网状物模型。在一个场景中，预处理可以包括：从接收到的（一个或多个）DICOM对象中提取DICOM图像，并且从所提取的DICOM图像来生成3D体积模型。然后，可以通过经由所生成的3D网状物模型对血流进行仿真来实行血流仿真分析。例如，在2011年1月25日提交的题为“Method and System forPatient-Specific Modeling of Blood Flow”的美国专利No.8,315,812中公开了用于对血流进行仿真的各种系统和方法，该专利通过引用整体地并入本文中。在一个实施例中，步骤605可以包括：确定对于可从健康数据分析系统105获得的每个分析所期望的预处理。步骤605可以进一步包括：确定预处理结果的使用。例如，所生成的3D网状物模型可以用于除（一个或多个）血流仿真之外的分析。替代地或此外，用于针对一个度量（例如，血压）的分析的3D网状物模型可以用于针对不同度量（例如，斑块易损性）的分析。在一个场景中，步骤605还可以包括：确定对于某个分析所期望的预处理的程度。例如，DICOM对象可以用于补充与病例的唯一病例ID相关联的3D网状物模型，而如果唯一病例标识符还不具有与其相关联的模型，则DICOM对象可以用于生成新的3D网状物模型。

在一个实施例中，3D网状物模型可以采用使用代表性状态转移（REST）HTTP协议创建的3D体积文件的形式。在示例实施例中，体积图像文件可以包括报头、二进制数据、定制报头（例如，（一个或多个）分析web服务123所支持的跟踪机制或标识符）等。报头可以包括系列唯一标识（UID）。可以从与正在分析的病例文件相关联的DICOM对象报头中检索UID。

在一个实施例中，图像数据的每个体积图像文件可以对应于压缩存档文件，压缩存档文件存储了关于基于体积图像文件的图像数据而生成的3D模型的信息。压缩存档文件可以进一步被转换成包括可以是人类可读且机器可读的3D模型的表示的文件（例如，扩展标记语言（XML）文件）。该文件可以包括3D模型网状物和其他信息，包括中心线、脉管边界、脉管直径/半径、组织边界、销钉物（例如，由分析员做出的标记物）、图像质量得分、置信度度量等。

在一个实施例中，每一个体积图像文件可以包含文件校验和。该文件校验和可以用于将系列UID与模型数据（例如，管腔分割和/或心肌质量）进行关联，将压缩存档文件与一个或多个体积图像文件相关联（例如，用于纵向研究或数据跟踪），并且确保一个或多个体积图像文件不随时间推移而损坏。在一个实施例中，可以使用具有现成算法的体积图像文件的原始数据部分来计算校验和。校验和算法的标识符可以被包含在校验和本身中。该布置可以用于处理校验和算法的各种版本或升级。在一个实施例中，压缩存档文件可以包括体积图像文件校验和，以便维持压缩存档文件与图像数据之间的一致链接。在一个实施例中，可以例如使用不同的分割算法从图像数据创建各种模型，从而聚焦于图像数据的不同部分等。

在一个实施例中，步骤607可以包括：提示对预处理结果的分析。例如，如果步骤605的预处理生成了3D模型，则步骤607可以包括提示使用3D模型进行分析。在一个实施例中，可以根据病例文件的所设置的优先级来实行步骤607，如按照图5那样。在一个实施例中，步骤607可以包括向（一个或多个）分析web服务123发送一个或多个经预处理的匿名DICOM对象以用于分析。在示例实施例中，如果校验和尚未被包括在所传输的体积图像文件中，则建模工作站可以计算体积图像文件的校验和。校验和可以用于将体积图像文件与压缩存档文件相匹配。例如，体积图像文件可以基于其自身的校验和来命名，从而便于与压缩存档文件中所包含的信息进行关联。例如，建模工作站可以检索与给定压缩存档文件相关联的体积图像文件的列表。

图7是根据本公开的示例性实施例的用于对来自健康数据分析系统105的结果文件进行后处理的示例性方法700的流程图。在示例实施例中，步骤701可以包括：从分析web服务123接收草拟结果报告。在一个实施例中，可以预先确定用于呈现最终结果报告的预定格式，并且可以移除草拟结果报告中不属于最终结果报告的一部分的任何项。例如，分析web服务123可以返回支架插入的若干仿真以治疗患者脉管系统中的狭窄。可以移除多个仿真结果，使得草拟结果报告仅示出最保守的仿真（例如，可能侵入性最小且产生最高血液动力学影响的支架插入）。在一个实施例中，步骤701可以进一步包括：标识是否存在来自分析web服务123的与草拟结果报告相关的先前结果，并且将草拟结果报告与先前结果进行聚合。

在一个实施例中，步骤703可以包括：向分析员呈现草拟结果报告/聚合报告以用于审查（使用交互式用户接口，例如，图1C的建模工作站127或生产用户接口129）。在一个实施例中，步骤705可以包括：接收对草拟结果报告的一个或多个改变/修改，例如，对草拟报告的视图、销钉物、仿真等的编辑。在一个实施例中，步骤707可以包括：重新触发对草拟结果报告的分析和生成。

在示例实施例中，步骤707可以包括：生成最终结果报告，该最终结果报告并入了由分析员经由用户接口所提供的一个或多个改变/修改。在示例实施例中，最终结果报告可以包括PDF文档和/或交互式3D模型，其具有强调了该模型的相关区和来自该分析的解决方案的销钉物或标记。例如，最终结果报告可以包括患者解剖结构的3D模型、基于3D模型所计算的血流度量、对3D模型的各种几何修改（例如，来自支架或移植物的插入、生理状态中的改变、药物治疗等）的血液动力学影响的比较。在一个实施例中，最终结果报告可以出于纵向研究和/或机器学习目的而被存储（例如，存储在图1C的匿名永久存储装置124b中），以用于分析web服务123的各种分析。

在一个实施例中，步骤709可以包括：将最终结果报告推送到健康数据IO系统101（例如，经由医院系统的预定义网络地址或健康数据IO系统101的web接口）。在示例实施例中，步骤709可以包括：从用于生成最终结果报告的一个或多个DICOM对象中检索预定义网络地址。在示例实施例中，用户（例如，医院技术人员）可以使用web应用（例如，在线门户）和唯一病例标识符来请求病例的结果报告。该结果报告可以以特定格式（例如，PDF格式或3D模型格式）被推送到健康数据IO系统101。健康数据IO系统101可以通过HTTP协议从用户接收针对结果报告的请求。

在替代实施例中，当结果报告准备好时，健康数据分析系统105可以将结果报告推送到医院计算系统（例如，PACS或CT工作站）。例如，一旦病例被转变成已完成状态，就可以监测（例如，通过队列监测器监测）病例状态，并且可以将结果推送到医院系统或（例如，健康数据IO系统101的）临床用户接口。在示例实施例中，将健康数据报告推送到医院计算设备、医院电子记录服务器和预配置的目的地网络地址中的至少一个可以包括：将HL7标准消息发送到医院计算设备、医院电子记录服务器和预配置的目的地网络地址中的至少一个。在一个实施例中，HL7标准消息可以包含健康数据报告作为封装的数据类型或URL。

本公开包括用于分析、存储和管理不同地理区域中的患者健康数据、同时保护患者隐私数据的系统和方法。本公开进一步包括：用于将匿名健康数据发送到医院区域外部的分析云平台并且传输分析结果报告的系统和方法。因此，可以跨区域提供数据分析，同时避免隐私数据从一个区域传递到另一个区域。所描述的实施例中的任一个都可以被修改，例如，被修改成包括可以保存在区域内的数据的变型。所公开的系统和方法可以被修改成建模和评估对循环的任何范围的改变。

与一个或多个基于云的web服务相关联的一个或多个处理器的功能可以由单个专用处理器或由多个处理器提供。此外，处理器可以包括但不限于数字信号处理器（DSP）硬件、或能够执行软件的任何其他硬件。该技术的程序方面可以被认为是通常采用可执行代码和/或相关联数据的形式的“产品”或“制品”，该可执行代码和/或相关联数据被携带或体现在一种类型的机器可读介质中。“存储”类型的介质包括计算机、处理器等等的任何或所有有形存储器或其相关联的模块，诸如各种半导体存储器、磁带驱动器、磁盘驱动器等等，它们可以在任何时间针对软件编程提供非暂时性存储。

软件的全部或部分有时可以通过互联网或各种其他电信网络来传送。例如，这种通信可以使得能够将软件从一个计算机或处理器加载到另一个计算机或处理器中，例如，从移动通信网络的管理服务器或主机计算机加载到服务器的计算机平台中、和/或从服务器加载到移动设备。因此，可以承载软件元素的另一种类型的介质包括光波、电波和电磁波，诸如通过有线和光学陆线网络以及通过各种空中链路跨本地设备之间的物理接口所使用的光波、电波和电磁波。携带这种波的物理元件（诸如，有线或无线链路、光链路等等）也可以被认为是承载软件的介质。如本文中所使用的，除非限于非暂时性的有形“存储”介质，否则诸如计算机或机器“可读介质”之类的术语指代参与向处理器提供指令以供执行的任何介质。

通过对本文中公开的本发明的说明书和实践的考虑，本发明的其他实施例对于本领域技术人员来说将是明显的。所意图的是，本说明书和实施例仅被认为是示例性的，其中本发明的真实范围和精神由所附权利要求来指示。

Claims (20)

1.一种用于在分散式云计算平台上分析健康数据的计算机实现的方法，所述方法包括：

接收包含一个或多个匿名DICOM对象的唯一病例文件以用于分析；

基于与所述一个或多个匿名DICOM对象相关联的优先级来设置所述唯一病例文件的优先级水平；

对所述一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及

传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，所述分析是根据所述唯一病例文件的优先级水平而完成的。

2.根据权利要求1所述的计算机实现的方法，其中，所述分析包括：

基于所述唯一病例文件的（一个或多个）匿名DICOM对象中的至少一个来生成体积图像文件，所述体积图像文件表示三维（3D）体积；

生成包括与所述体积图像文件相关联的分析数据的存档文件；以及

基于所述体积图像文件和所述存档文件来生成患者特定的模型。

3.根据权利要求2所述的计算机实现的方法，其中，所述体积图像文件包括将所述体积图像文件与所述存档文件进行关联的文件校验和。

4.根据权利要求1所述的计算机实现的方法，进一步包括：

监测所述唯一病例文件的状态；以及

基于所述唯一病例文件的状态和优先级水平来推进对所述唯一病例文件的分析。

5.根据权利要求1所述的计算机实现的方法，进一步包括：

基于生成与所述一个或多个匿名DICOM对象相关联的一个或多个DICOM对象的实体和/或分析所述一个或多个匿名DICOM对象的实体来设置所述唯一病例文件的优先级水平。

6.根据权利要求1所述的计算机实现的方法，进一步包括：

基于接收到的分析来生成草拟结果报告；以及

生成所述草拟结果报告的交互式用户接口。

7.根据权利要求1所述的计算机实现的方法，进一步包括：

接收对所述草拟结果报告的修改；

基于修改来生成最终结果报告；以及

存储所述最终结果报告、预定义的所标识的网络地址、或做出请求的web接口。

8.根据权利要求6所述的计算机实现的方法，其中，使用安全超文本传输协议（HTTPS）将所述最终结果报告推送到数据库、预定义的所标识的网络地址、或做出请求的web接口。

9.一种用于在分散式云计算平台上分析健康数据的系统，所述系统包括：

一个或多个数据存储设备，其存储在分散式云计算平台上分析健康数据的指令；以及

一个或多个处理器，其被配置成执行指令以实行方法，所述方法包括：

接收包含一个或多个匿名DICOM对象的唯一病例文件以用于分析；

基于与所述一个或多个匿名DICOM对象相关联的优先级来设置所述唯一病例文件的优先级水平；

对所述一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及

传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，所述分析是根据所述唯一病例文件的优先级水平而完成的。

10.根据权利要求9所述的系统，其中，所述分析进一步由以下各项构成：

基于所述唯一病例文件的（一个或多个）匿名DICOM对象中的至少一个来生成体积图像文件，所述体积图像文件表示三维（3D）体积；

生成包括与所述体积图像文件相关联的分析数据的存档文件；以及

基于所述体积图像文件和所述存档文件来生成患者特定的模型。

11.根据权利要求10所述的系统，其中，所述体积图像文件包括将所述体积图像文件与所述存档文件进行关联的文件校验和。

12.根据权利要求9所述的系统，其中，所述系统进一步被配置成用于：

监测所述唯一病例文件的状态；以及

基于所述唯一病例文件的状态和优先级水平来推进对所述唯一病例文件的分析。

13.根据权利要求9所述的系统，其中，所述系统进一步被配置成用于：

基于生成与所述一个或多个匿名DICOM对象相关联的一个或多个DICOM对象的实体和/或分析所述一个或多个匿名DICOM对象的实体来设置所述唯一病例文件的优先级水平。

14.根据权利要求9所述的系统，其中，所述系统进一步被配置成用于：

基于接收到的分析来生成草拟结果报告；以及

生成所述草拟结果报告的交互式用户接口。

15.根据权利要求9所述的系统，其中，所述系统进一步被配置成用于：

接收对所述草拟结果报告的修改；

基于所述修改来生成最终结果报告；以及

存储所述最终结果报告、预定义的所标识的网络地址、或做出请求的web接口。

16.根据权利要求15所述的系统，其中，使用安全超文本传输协议（HTTPS）将所述最终结果报告推送到数据库、预定义的所标识的网络地址、或做出请求web接口。

17.一种在包含计算机可执行编程指令的计算机系统上使用的非暂时性计算机可读介质，所述可执行编程指令用于在分散式云计算平台上分析健康数据，所述方法包括：

接收包含一个或多个匿名DICOM对象的唯一病例文件以用于分析；

基于与所述一个或多个匿名DICOM对象相关联的优先级来设置所述唯一病例文件的优先级水平；

对所述一个或多个匿名DICOM对象中的至少一个进行解压缩和验证；以及

传输对经解压缩和验证的（一个或多个）匿名DICOM对象中的至少一个的分析，所述分析是根据所述唯一病例文件的优先级水平而完成的。

18.根据权利要求17所述的非暂时性计算机可读介质，其中，所述分析包括：

基于所述唯一病例文件的（一个或多个）匿名DICOM对象中的至少一个来生成体积图像文件，所述体积图像文件表示三维（3D）体积；

生成包括与所述体积图像文件相关联的分析数据的存档文件；以及

基于所述体积图像文件和所述存档文件来生成患者特定的模型。

19.根据权利要求17所述的非暂时性计算机可读介质，所述方法进一步包括：

监测所述唯一病例文件的状态；以及

基于所述唯一病例文件的状态和优先级水平来推进对所述唯一病例文件的分析。

20.根据权利要求17所述的非暂时性计算机可读介质，所述方法进一步包括：

基于生成与所述一个或多个匿名DICOM对象相关联的一个或多个DICOM对象的实体和/或分析所述一个或多个匿名DICOM对象的实体来设置所述唯一病例文件的优先级水平。

Images