CN105389619B - 用于改进健康护理生态系统内的连接的方法和系统 - Google Patents

Abstract

本公开涉及用于改进健康护理生态系统内的连接的方法和系统。提供用于改进健康护理生态系统内的连接的系统、方法和设备。示例系统、方法和设备可以方便动态接口定义和配置。

Description

用于改进健康护理生态系统内的连接的方法和系统

技术领域

本公开涉及健康护理接口即服务，并且更特定地涉及用于经由接口即服务来便于改进健康护理生态系统的部件之间的连接的系统、方法和计算机程序产品。

背景技术

该章节中的陈述仅仅提供与本公开有关的背景信息并且可不构成现有技术。

例如医院或诊所等健康护理环境包括例如医院信息系统（HIS）、放射信息系统（RIS）、临床信息系统（CIS）和心血管信息系统（CVIS）等信息系统，和例如图片存档和通信系统（PACS）、图书馆信息系统（LIS）和电子病历（EMR）等存储系统。存储的信息可以例如包括患者用药医嘱、病史、成像数据、测试结果、诊断信息、管理信息和/或调度信息。

发明内容

鉴于上文，需要提供改进健康护理生态系统内的连接的系统、方法和计算机程序产品。示例系统、方法和设备可以便于动态接口定义和配置。上文提到的需要通过本文描述的主旨解决并且将在下列说明书中理解。

该摘要简短描述在下文在详细描述中描述的主旨的方面，并且不意在用于限制本公开中描述的主旨的范围。

附图说明

本文公开的系统和方法的特征和技术方面结合图（其中标号指示相同或功能相似的元件）将在下列详细描述中变得明显。

图1示出示例聚焦健康护理的信息系统的框图。

图2示出包括一个或多个系统的示例健康护理信息基础设施的框图。

图3示出包括多个聚焦健康的系统的示例工业互联网配置。

图4图示便于改进健康护理生态系统中的连接的示例架构。

图5A、5B、5C图示作为接口即服务而提供的IntelliLink 核心服务，其包括可扩展集成总线和消息传递结构。

图6A、6B图示用于经由IntelliLink总线的智能路由的示例企业集成模式示意图。

图7图示对接口定义和配置提供示例基于工厂的模型的系统。

图8A、8B图示用于预备新的接口的示例过程或工作流程的流程图。

图9描绘用于满足某些核心接口功能和邻接的示例软件代理和管理服务。

图10A-B图示使用接口集成的智能转诊的示例。

图11图示在专家之间呈扇形散开的“智能转诊”的示例实现。

图12图示关于患者移动和再入院分析的示例。

图13示出自发形成的护理团队的示例。

图14图示从间接到直接连接的移动的示例。

图15A、15B图示云部署的实验室中心的接口即服务实现的示例示意图。

图16A、16B图示远距ICU技术方案的接口即服务实现的示意图。

图17示出可以用于实现本身描述的系统和方法的示例处理器系统的框图。

具体实施方式

在下列详细描述中，参考形成其一部分并且其中通过说明可实践的特定示例的方式示出的附图。充分详细地描述这些示例以使本领域内技术人员能够实践主旨，并且要理解可利用其他示例并且可进行逻辑、机械、电和其他改变而不偏离本公开的主旨的范围。因此，提供下列详细描述来描述示范性实现并且对在本公开中描述的主旨不意在为限制的。来自下列描述的不同方面的某些特征可组合以形成下文论述的主旨的再新的方面。

当介绍本公开的各种实施例的要素时，冠词“一”、 “该”和“所述”意在表示存在要素中的一个或多个。术语“包括”、“包含”和“具有”意为包容性的并且表示可存在除列出的要素外的附加要素。

I. 综览

本文公开和描述的方面对于健康护理生态系统中的信息技术（IT）系统之间的健康护理数据交换实现智能的基于云的集成平台的端到端系统设计。方面在例如医院、流动诊所和/或专科执业诊所等健康护理设施内部署的源系统（其能够与目标系统交换健康护理相关临床和/或非临床信息）之间提供连接性。目标系统包括一个或多个业务合作伙伴系统，例如健康信息交换（HIE）、付款人、实验室、劳动力和转诊机构、专科诊断实验室、DNA测序实验室、疾病登记处、联邦机构等，其可以发回有意义响应，源系统可以将其嵌入它的业务处理逻辑和/或工作流程内。某些方面提供经由路由引擎和分析的智能仲裁，用于驱动和持续改进健康护理生态系统内的连接。某些方面还促成具有容易配置和部署的新颖且灵活的接口预备方法以允许采用采用“即插即用”的方式集成新的目标系统。接口实现支持例如健康等级七（HL7）v2.x/3.x、HL7 FHIR、医学数字成像和通信（DICOM）、临床文档架构（CDA）/整合CDA（CCDA）等健康护理标准协议，和使健康护理企业（IHE）的跨企业文档共享（XDS）、患者标识符交叉引用/患者人口统计查询（PIX/PDQ）、实验室（LAB）、审核试验和节点验证（ATNA）和其他IHE简档集成。

某些方面尝试通过对实现和患者结果（patient outcome）的成本、时间加以优化/改进来持续改进健康护理生态系统内的连接性。某些方面提供基于云的集成平台，其便于在健康护理生态系统内新的端点、接口和路由的再用和快速预备。为了满足该目标，有许多挑战要克服：1.）隐私遵从-维持动态生态系统内的参与者之间的数据共享协定。2.）业务模型转变-对商品进行集成和连接并且关注增值服务。3.）技术挑战-如何集成完全不同的系统，在这里在HL7标准中存在高度可变性。4.）自动化-如何消除现今需要的人工和劳动力密集型集成工作。5.）实用主义和焦点-如何保持对提高患者结果而不好高骛远的关键目标的关注。6.）如何像病毒一样推动采纳。

在某些示例中，增值服务通过连接的应用系统来实现，其有助于使得健康护理连接成为无所不在的商品。某些示例有助于便于互操作性，其是多年来健康护理行业的最大问题之一。缺乏互操作性在集成技术方案中导致大量冗余和低效，这通过目前描述的技术来克服。

某些示例在跨共同健康护理集成场景使用一致技术方案来解决互操作性问题方面在各种健康护理产品内去除方法中的重叠和冗余。在某些示例中，一致的技术方案包括提供多个个体独立可插拔接口，作为到通过执行相关交互和编排的集中式智能平台而互连的健康护理IT产品的门面。

在某些示例中，新的接口使用标准化治理模型并且通过自动化来创建和预备。某些示例建立连接的健康护理生态系统的图形以能够改进或优化连接并且避免流量路障。某些示例促成灵巧、灵活、可适应的“即插即用”集成策略。

在某些示例中，部署远程ICU（密集型护理单元）作为接口即服务（IaaS）以有助于远程医院的护理提供者向垂危患者提供先进的咨询、护理和监视而不必将他们转移到特级专科医院。通过远程ICU的远程ICU监视技术允许总控中心处的医师在24/7基础上监视来自远程ICU/医院的垂危患者的实时参数。该技术模型（使用围绕接口即服务的概念作为它的中心论题）在可以在远程放射或远程ER空间中启动的产品中具有分支。

尽管其他基于云的健康护理集成技术方案在“云”中使用商品HL7集成引擎来解决特定健康护理集成或连接性问题，某些方面至少部分通过聚焦在连接上并且持续改进健康护理生态系统内的连接同时压低集成的成本并且改进患者结果而有所不同。某些方面采用业务模型创新（例如，免费增值、预测分析、伙伴关系、社交网络、标准化、过程效率、增值、过程自动化和简化，等）、技术创新（例如，支持提到的那类业务模型创新的架构和设计选择）和分析（例如，图形分析加上机器学习来发现模式，等）的组合。

例如在下面论述的那些和如可以由本领域内技术人员在阅读公开的描述时意识到的其他等其他方面也是可能的。

II. 示例操作环境

健康信息（也称为健康护理信息和/或健康护理数据）指由健康护理实体产生和/或使用的信息。健康信息可以是与例如一个或多个患者的健康关联的信息。健康信息可以包括受保护健康信息（PHI），如在健康保险携带和责任法案（HIPAA）中概述的，其可识别为与特定患者关联并且被保护以避免未经授权的公开。健康信息可以组织为内部信息和外部信息。内部信息包括患者就诊（patient encounter）信息（例如，特定患者数据、聚集数据、比较数据等）和一般健康护理操作信息，等。外部信息包括比较数据、专家和/或基于知识的数据等。信息可以既具有临床（例如，诊断、治疗、预防等）又具有行政（例如，调度、收费、管理等）用途。

例如健康护理机构等具有复杂网络支持环境并且有时具有无序驱动过程流的机构利用敏感信息（例如，个人隐私）流的安全处理和安全防护。对于信息的安全处理和安全防护的需要随着对这样的信息交换的灵活性、容积和速度的增长而增加。例如，健康护理机构提供不同位点之间敏感患者PHI和雇员信息的交换和存储的增强控制和安全防护以在典型地具有患者对医院服务的无序驱动需求的操作环境中提高医院运营效率。在某些示例中，患者识别信息可以根据数据存储在哪里以及谁访问该数据而被掩蔽或甚至从某些数据剥离。在一些示例中，已经“去识别”的PHI可以基于密钥和/或其他编码器/解码器而重新识别。

健康护理信息技术基础设施可以适于服务于多个业务集团同时提供临床信息和服务。这样的基础设施可以包括集中能力，其包括例如数据存储库、报告、周密的数据交换/连接性、“智能”算法、个性化/消费者决策支持等。该集中能力向多个用户提供信息和功能性，这些用户包括例如医疗装置、电子档案、访问门户、绩效工资发放（P4P）、慢性病模型和临床健康信息交换/区域健康信息组织（HIE/RHIO）和/或企业医药研究、家庭健康。

多个数据源的互连有助于实现患者护理团队的所有相关成员的衔接并且有助于改进对患者的行政和管理的负担以便管理他或她的护理。特别地，使患者的电子病历和/或其他医疗数据互连可以有助于改进患者护理和患者信息的管理。此外，通过提供自动适于患者的特定和变化的健康状况的工具而便于患者护理遵从并且提供全面教育和遵从工具来推动积极的健康结果。

在某些示例中，健康护理信息可以使用多种数据库和存储技术和数据格式在多个应用之间分布。为了对跨这些应用驻存的数据提供共同接口和访问，可以提供连接性框架（CF），其利用共同数据和服务模型（CDM和CSM）和面向服务技术（例如企业服务总线（ESB））来提供对数据的访问。

在某些示例中，多种用户界面框架和技术可以用于建立对于健康信息系统的应用，其包括但不限于MICROSOFT® ASP.NET、AJAX®、MICROSOFT® Windows PresentationFoundation、GOOGLE® Web Toolkit、MICROSOFT® Silverlight、ADOBE®及其他。应用可以由信息小部件库组成来显示例如多内容和多媒体信息。另外，框架使用户能够定制应用的布局并且与底层数据交互。

在某些示例中，具有现代技术堆栈的先进的面向服务的架构（SOA）有助于提供稳健的互操作性、可靠性和性能。示例SOA包括三重互操作性策略，其包括中央存储库（例如，从健康等级七（HL7）事务构建的中央存储库）、对于在联邦环境中运作的服务和与第三方应用的视觉集成。某些示例提供在健康护理组织之间实现即插即用内容交换的便携式内容。使用共同标准的标准化词汇（例如，LOINC、SNOMED CT、RxNorm、FDB、ICD-9、ICD-10等）用于例如互操作性。某些示例提供直观用户界面以有助于使最终用户培训最小化。某些示例便于直接从桌面界面的用户发起的第三方应用启动以通过共享用户、患者和/或其他上下文而有助于提供无缝工作流程。某些示例提供来自一个或多个信息技术（IT）系统的实时（或呈现某一系统延迟地大致实时）患者数据并且便于与基于证据的最佳实践的比较。某些示例对于特定患者集提供一个或多个仪表板。仪表板可以基于条件、作用和/或其他准则来指示自例如期望实践的变化。

a. 示例健康护理信息系统

信息系统可以定义为信息/数据、过程和信息技术的设置，它们交互来收集、处理、存储和提供信息输出以支持健康医疗到一个或多个患者的交付。信息技术包括计算机技术（例如，硬件和软件）连同数据和电信技术（例如，数据、图像和/或语音网络，等）。

现在转向图，图1示出示例聚焦健康护理的信息系统100的框图。该示例系统100可以配置成实现多种系统和过程，其包括图像存储（例如，图片存档和通信系统（PACS），等）、图像处理和/或分析、放射报告和/或回顾（例如，放射信息系统（RIS），等）、计算机化提供方医嘱录入（CPOE）系统、临床决策支持、患者监视、人群健康管理（例如，人群健康管理系统（PHMS）、健康信息交换（HIE），等）、健康护理数据分析、基于云的图像共享、电子病历（例如，电子病历系统（EMR）、电子健康档案系统（EHR）、电子患者档案（EPR）系统、个人健康档案系统（PHR）等）和/或其他健康信息系统（例如，临床信息系统（CIS）、医院信息系统（HIS）、患者数据管理系统（PDMS）、实验室信息系统（LIS）、心血管信息系统（CVIS）等）。

如在图1中图示的，示例信息系统100包括输入110、输出120、处理器130、存储器140和通信接口150。示例系统100的部件可以在一个装置中集成或在两个或以上装置上分布。

示例输入110可以包括键盘、触屏、鼠标、轨迹球、触控笔（track pad）、光学条形码识别、语音命令等或其组合，用于将指令或数据传输到系统100。示例输入110可以包括系统之间、用户与系统100之间等的接口。

示例输出120可以提供由处理器130产生、用于在监视器或类似物上视觉图示的显示。该显示可采用网络接口或图形用户界面（GUI）的形式以例如经由通信接口150在计算装置上交换数据、指令或图示。示例输出120可以包括监视器（例如，液晶显示器（LCD）、等离子体显示器、阴极射线管（CRT）等）、发光二极管（LED）、触屏、打印机、扬声器或其他常规显示装置或其组合。

示例处理器130包括硬件和/或使硬件配置成执行一个或多个任务和/或实现特定系统配置的软件。示例处理器130处理在输入110接收的数据并且产生可以提供给输出120、存储器140和通信接口150中的一个或多个的结果。例如，示例处理器130可以采取经由输入110提供的关于经由输出120显示的图像的用户注释并且可以基于该注释产生与图像关联的报告。作为另一个示例，处理器130可以处理经由输入110获得的更新患者信息以经由通信接口150向EMR提供更新的患者档案。

示例存储器140可以包括关系数据库、面向对象数据库、数据字典、临床数据存储库、数据仓库、数据集市、供应商中立存档、企业存档等。示例存储器140存储图像、患者数据、最佳实践、临床知识、分析、报告等。示例存储器140可以存储数据和/或指令以供处理器130访问。在某些示例中，存储器140可以由外部系统经由通信接口150访问。

在某些示例中，存储器140存储并且控制对加密信息的访问，例如患者档案、对于患者病历的加密更新-事务，其包括使用历史等。在示例中，病历可以在不使用病历特定的逻辑结构的情况下存储。采用这样的方式，存储器140是不可搜索的。例如，患者的数据可以用唯一的患者所拥有的密钥在数据源处加密。数据然后上传到存储器140。存储器140不处理或存储未加密数据，从而使隐私问题最小化。可以下载患者的数据并且用加密密钥对其本地解密。

例如，存储器140可以根据提供者、患者、患者/提供者关联和文档来构造。提供者信息可以包括例如标识符、名字和地址、公钥和一个或多个安全类别。患者信息可以包括例如标识符、密码哈希和加密电子邮件地址。患者/提供者关联信息可以包括提供者标识符、患者标识符、加密密钥和一个或多个覆盖安全类别。文档信息可以包括例如标识符、患者标识符、临床标识符、安全类别和加密数据。

示例通信接口150便于电子数据在一个或多个系统内和/或之间的传输。经由通信接口150的通信可以使用一个或多个协议来实现。在一些示例中，经由通信接口150的通信根据一个或多个标准（例如，医学数字成像和通信（DICOM）、健康等级七（HL7）、ANSI X12N，等）发生。示例通信接口150可以是有线接口（例如数据总线、通用串行总线（USB）连接，等）和/或无线接口（例如，射频、红外、近场通信（NFC）等）。例如，通信接口150可以经由有线局域网（LAN）、无线LAN、广域网（WAN）等使用任何过去、目前或未来通信协议（例如，BLUETOOTH™、USB 2.0、USB 3.0等）来传送。

在某些示例中，基于Web的门户可便于对信息、患者护理和/或实践管理等的访问。经由基于Web的门户而可用的信息和/或功能性可包括医嘱录入、实验室测试结果回顾系统、患者信息、临床决策支持、药物管理、调度、电子邮件和/或消息传递、医疗资源等中的一个或多个。在某些示例中，基于浏览器的界面可以充当零占用空间、零下载和/或对于客户端装置的其他通用查看器。

在某些示例中，基于Web的门户充当访问例如信息和应用的中央接口。数据可通过例如基于Web的门户或查看器来查看。另外，可例如使用基于Web的门户来操纵和传播数据。可生成、修改、存储和/或使用数据并且然后例如经由基于Web的门户将其传送到另一个应用或系统以供修改、存储和/或使用。

例如，基于Web的门户可本地（例如，在办公室中）和/或远程（例如，经由互联网和/或其他专用网络或连接）访问。例如，基于Web的门户可配置成在访问数据和/或功能以便于在患者护理和实践管理方面帮助或指导用户。在某些示例，基于Web的门户可例如根据某些规则、偏好和/或功能来配置。例如，用户可根据特定期望、偏好和/或要求来定制Web门户。

b. 示例健康护理基础设施

图2示出示例健康护理信息基础设施200的框图，其包括一个或多个子系统，例如在图1中图示的示例健康护理相关信息系统100。示例健康护理系统200包括HIS 204、RIS206、PACS 208、接口单元210、数据中心212和工作站214。在图示的示例中，HIS 204、RIS206和PACS 208容置在健康护理设施中并且本地存档。然而，在其他实现中，HIS 204、RIS206和/或PACS 208可以容置在一个或多个其他适合位点中。在某些实现中，PACS 208、RIS206、HIS 204等中的一个或多个可以经由瘦客户端和/或可下载软件技术方案而远程实现。此外，健康护理系统200的一个或多个部件可以一起组合和/或实现。例如，RIS 206和/或PACS 208可以与HIS 204集成；PACS 208可以与RIS 206集成；和/或三个示例信息系统204、206和/或208可以集成在一起。在其他示例实现中，健康护理系统200包括图示的信息系统204、206和/或208的子集。例如，健康护理系统200可以包括HIS 204、RIS 206和/或PACS208中的仅仅一个或两个。信息（例如，调度、测试结果、检查图像数据、观察、诊断，等）可以由健康护理从业者（例如，放射科医师、医生和/或技术人员）和/或管理者在患者检查之前和/或之后输入HIS 204、RIS 206和/或PACS 208内。

HIS 204存储医疗信息，例如从例如医院、诊所和/或医生的办公室的人员接收的临床报告、患者信息和/或行政信息（例如，EMR、HER、PHR等）。RIS 206存储例如放射报告、放射检查图像数据、消息、警告、警报、患者调度信息、患者人口统计数据、患者跟踪信息和/或医生和患者状态监视器等信息。另外，RIS 206实现检查医嘱录入（例如，对患者开出x射线诊单）以及图像和胶片跟踪（例如，跟踪已经检验胶片的一个或多个人的身份）。在一些示例中，RIS 206中的信息根据HL-7（健康等级七）临床通信协议而格式化。在某些示例中，医学检查分配器定位在RIS 206中以便于对放射科医师工作负荷分配放射检查以供例如管理者回顾和管理检查分配。

PACS 208将医学图像（例如，x射线、扫描、三维渲染等）作为例如数字图像存储在数据库或存储库中。在一些示例中，医学图像使用医学数字成像和通信（DICOM）格式存储在PACS 208中。图像在患者医学成像后由健康护理从业者（例如，成像技术人员、医生、放射科医师）存储在PACS 208中和/或自动从医学成像装置传输到PACS 208以用于存储。在一些示例中，PACS 208还可以包括显示装置和/或查看工作站，用于使健康护理从业者或提供者能够与PACS 208通信。

接口单元210包括医院信息系统接口连接216、放射信息系统接口连接218、PACS接口连接220和数据中心接口连接222。接口单元210便于HIS 204、RIS 206、PACS 208和/或数据中心212之间的通信。接口连接216、218、220和222可以由例如广域网（WAN）（例如专用网络或互联网）实现。因此，接口单元210包括一个或多个通信部件，例如以太网装置、异步传输模式（ATM）装置、802.11装置、DSL调制解调器、电缆调制解调器、蜂窝调制解调器等。进而，数据中心212经由在多个位点（例如，医院、诊所、医生的办公室、其他医护办公室或终端，等）处实现的网络224而与工作站214通信。网络224由例如互联网、内联网、专用网络、有线或无线局域网和/或有线或无线广域网实现。在一些示例中，接口单元210还包括代理（例如，Mitra Imaging的PACS代理）以允许医疗信息和医学图像一起传输并且一起存储。

接口单元210经由接口连接216、218、220从信息系统204、206、208接收图像、医学报告、行政信息、检查工作负荷分配信息和/或其他临床信息。如果必要的话（例如，在不同格式的接收信息不兼容时），接口单元210将例如医学报告等医疗信息转换或重新格式化（例如，成为结构化查询语言（“SQL”）或标准文本）以正确存储在数据中心212处。重新格式化的医疗信息可以使用传输协议传输以使不同的医疗信息能够共享共同识别元素，例如患者名字或社会安全号码。接着，接口单元210经由数据中心接口连接222将医疗信息传输到数据中心212。最后，医疗信息采用例如DICOM格式存储在数据中心212中，这使医学图像和对应的医疗信息能够一起传输和存储。

医疗信息稍后在工作站214处可查看且能容易检索（例如，通过它们的共同识别元素，例如患者名字或记录号）。工作站214可以是能够执行准许采集、存储或传输电子数据（例如，医学报告）和/或电子医学图像（例如，x射线、超声、MRI扫描等）以供查看和操作的软件的任何设备（例如，个人计算机）。工作站214经由例如键盘、鼠标、轨迹球、麦克风等从用户接收命令和/或其他输入。工作站214能够实现用户界面226以使健康护理从业者和/或管理者能够与健康护理系统200交互。例如，响应于来自医生的请求，用户界面226呈现患者病史。在其他示例中，放射科医师能够检索并且管理分配的检查工作负荷以经由用户界面226供放射科医师回顾。在另外的示例中，管理者经由用户界面226回顾与检查分配关联的放射科医师工作负荷、检查分配和/或操作统计信息。在一些示例中，管理者经由用户界面226调整一个或多个设置或结果。

图2的示例数据中心212是用于存储例如图像、数据、医学报告和/或更一般地患者病历等信息的存档。另外，数据中心212对于定位在例如本地存档、医院信息系统/放射信息系统（例如，HIS 204和/或RIS 206）或医学成像/存储系统（例如，PACS 208和/或连接的成像模态）等其他源处的信息还可充当中央管道。即，数据中心212可以存储到信息的链接或指示符（例如，识别号、患者名字或记录号）。在图示的示例中，数据中心212由应用服务器提供商（ASP）管理并且定位在可以被多个系统和设施（例如，医院、诊所、医生的办公室、其他医护办公室和/或终端）访问的集中式位点中。在一些示例中，数据中心212可以在空间上远离HIS 204、RIS 206和/或PACS 208（例如，在GENERAL ELECTRIC®总部）。

图2的示例数据中心212包括服务器228、数据库230和记录组织器232。服务器228接收、处理来自健康护理系统200的部件的信息，以及将信息传送传达到健康护理系统200的部件。数据库230存储本文描述的医疗信息并且提供对其的访问。图2的示例记录组织器232管理例如患者病史。记录组织器232还可以帮助例如规程调度。

某些示例可以实现为基于云的临床信息系统和关联的使用方法。示例基于云的临床信息系统使健康护理实体（例如，患者、临床医生、站点、群组、社团和/或其他实体）能够经由基于web的应用、云存储和云服务而共享信息。例如，基于云的临床信息系统可使第一临床医生能够将信息安全上传到基于云的临床信息系统以允许第二临床医生经由web应用查看和/或下载信息。从而，例如，第一临床医生可将x射线图像上传到基于云的临床信息系统内，并且第二临床医生可经由web浏览器查看x射线图像和/或将x射线图像下载到第二临床医生所采用的本地信息系统上。

在某些示例中，例如，用户（例如，患者和/或护理提供者）可以经由软件即服务（SaaS）实现在云或其他计算机网络上访问由系统200提供的功能性。在某些示例中，系统200的全部或部分还可以经由平台即服务（PaaS）、基础设施即服务（IaaS）等来提供。例如，系统200可以实现为云交付的移动计算集成平台即服务。例如，消费者面向的基于Web的移动和/或其他应用集使用户能够与PaaS交互。

c. 工业互联网示例

物联网（也称为“工业互联网”）指可以使用互联网连接来与网络上的其他装置谈话的装置之间的互连。使用连接，装置可以通信以触发事件/动作（例如，改变温度、打开/关闭、提供状态，等）。在某些示例中，机器可以与“大数据”合并来提高效率和操作、提供改进的数据挖掘、便于更好操作等。

大数据可以指如此大且复杂使得使用传统数据处理工具/方法来处理变得困难的数据的集合。与大数据集关联的挑战包括数据捕获、分类、存储、搜索、传输、分析和可视化。趋向更大数据集至少部分是由于从单个大数据集的分析而不是多个独立较小数据集的分析可得到的额外信息。通过分析单个大数据集，可以在数据中找到相关，并且可以评估数据质量。

图3图示示例工业互联网配置300。示例配置300包括多个聚焦健康的系统310-312，例如经由工业互联网基础设施300通信的多个健康信息系统100（例如，PACS、RIS、EMR等）。示例工业互联网300包括经由云320而与服务器330和关联数据存储340通信的多个健康相关信息系统310-312。

如在图3的示例中示出的，多个装置（例如，信息系统、成像模态等）310-312可以访问云320，其使装置310-312与服务器330和关联的数据存储340连接。信息系统例如包括通信接口，用于经由云320而与服务器330和数据存储340交换信息。例如医学成像扫描仪、患者监视器等其他装置可以装备有传感器和通信接口以使它们能够经由云320彼此并且与服务器330通信。

从而，系统300中的机器310-312作为具有先进传感器、控制和软件应用的网络而变得“智能”。使用这样的基础设施，可以对关联数据提供先进分析。分析结合基于物理的分析、预测算法、自动化和深厚的领域专长。经由云320，装置310-312和关联的人可以连接来支持例如更智能的设计、操作、维护和更高服务器质量和安全。

例如，使用工业互联网基础设施，专有机器数据流可以从装置310提取。基于机器的算法和数据分析应用于提取的数据。数据可视化可以是远程的、集中的等。然后与经授权的用户共享数据，并且任何聚集和/或收集情报反馈到机器310-312内。

d. 数据挖掘示例

成像信息学包括确定如何标记采用逻辑、结构化和机器可读格式在诊断成像中采集的大量数据和对其编索引。通过使数据在逻辑上结构化，信息可以通过代表临床路径和决策支持系统的算法来发现和利用。数据挖掘可以用于帮助确保患者安全、减少治疗中的差异、提供临床决策支持等。从放射报告以及实际图像数据挖掘结构化和非结构化数据两者可以用于既对报告和关联的图像本身成像进行标记又对它们编索引。

e. 示例使用方法

临床工作流程典型地定义成包括响应于一个或多个事件和/或根据调度而采取的一个或多个步骤或动作。事件可包括接收与临床记录的一个或多个方面关联的健康护理消息、对于新的患者打开记录、接收转移患者、关于图像回顾和报告和/或需要或指示响应性动作或处理的任何其他实例和/或情形。临床工作流程的动作或步骤可包括为一个或多个临床测试开诊单、调度规程、请求某些信息来补充接收的健康护理记录、检索与患者关联的额外信息、向患者和/或与患者的治疗关联的健康护理从业者提供指令、放射图像数阅读和/或在处理健康护理信息方面有用的任何其他动作。定义的临床工作流程可以包括要由例如管理者或从业者采取的手动动作或步骤、要由系统或装置采取的电子动作或步骤和/或手动和电子动作或步骤的组合。尽管健康护理企业的一个实体可采用第一方式对某一事件定义临床工作流程，健康护理企业的第二实体可采用第二不同的方式定义该事件的临床工作流程。也就是说，不同的健康护理实体可采用不同样式对待相同事件或情况或对其作出响应。工作流程方法中的差异可源于不同健康护理实体之间的变化的偏好、能力、要求或责任、标准、协议等。

在某些示例中，对患者实施的医学检查可以牵涉由健康护理从业者（例如放射科医师）回顾以从检查获得例如诊断信息。在医院环境中，可以对多个患者开出医学检查单，其中的全部需要由检查从业者回顾。每个检查具有关联的属性，例如模态、在检查的人体的一部分和/或与患者危急程度有关的检查优先级。医院管理者在管理检查的分配以供从业者回顾中可以考虑检查属性以及人员可用性、人员证书和/或例如服务级协定和/或开销成本等制度因素。

可以方便额外工作流程，例如票据处理、收入周期管理、人群健康管理、患者身份、认可管理等。

II. 示例系统和集成架构和关联方法

在某些示例中，可以实现健康护理数据交换以使用智能的基于总线的发现/路由机制来连接内容源和订户目标以创建并且预备支持大的互连生态系统（例如，多个实验室、付款人、HIE等）的基于云的接口。可以创建并且预备示例基于云的接口使得多个源系统（例如，医院、流动诊所、专科诊所，等）可以发送健康护理特定消息有效载荷以智能路由到定义的目标系统。在某些示例中，接口构造和预备的方法包括用户体验（UX）驱动的自助服务和模型驱动的自动预备工作流程的组合。对于接口定义和配置的基于工厂的模型和方法提供一致机制来将接口发布到注册表用于预备和“热部署”系统初始化和启动。

在某些示例中，供在对数据分区（分片）中使用的受保护健康信息（PHI）的去识别（和随后的重新识别）有助于在“大数据”仓库内对患者和人群分析实现更快且更佳的查询。

某些示例提供基于软件的方法以对于系统（例如，称为“IntelliLink”）与互连生态系统内的多个合作伙伴系统之间的公钥基础设施（PKI）安全和信任证书使用智能发现过程来安全传输消息有效载荷。

摄入器机制解析健康护理特定有效载荷结构和临床数据传输对象（DTO）的创建。某些示例提供“大数据”处理，其管理在实现数据的web级处理和分片的平台上建立的高容量和高速率健康护理数据流。流播复杂事件处理（CEP）引擎处理输入的健康护理数据来对数据中的预定义模式产生分析/洞察、动作和警报。机器学习机制学习基于元数据的消息交换模式以在新系统添加到健康护理生态系统和网络时提供上下文感知和优化。

利用上文描述的设计和基础设施，可以提供转诊系统来实现为了患者的便利和结果而优化的智能护理连接。某些示例同时实现对多个专家的转诊请求呈扇形散开来征集可以由患者评估的报价。

某些示例提供自动发现并且建立连接的健康护理生态系统的图形的机制，该生态系统就关系来说包括例如：人对人、患者对提供者、提供者对分包商、系统对接口、消息对系统、机器对机器、患者对提供者拜访、专家对位点、转诊对结果等。某些示例可以预见健康护理生态系统中的流量拥挤和瓶颈并且向护理提供者和患者提供建议。某些示例可以通过从之前的设置学习来推动无摩擦数据交换设置和新接口的预备。

利用上文描述的设计和基础设施，可以提供在CIS、LIS和实验室自动化系统（LAS）之间提供基于IHE标准的连接性的云部署实验室中心的参考实现。

某些示例提供远程ICU监视技术方案（远程ICU）的参考实现，其允许总控中心处的医师在一周7天/24小时基础上监视来自远程ICU/医院的垂危患者的实时装置参数。

基于云的集成（也称为集成平台即服务或IPaaS）是作为解决数据、过程、面向服务架构（SOA）和应用集成使用情况的云服务而交付的系统集成的形式。“云”中的健康护理集成通过例如优化健康护理生态系统内的连接并且通过推动更好患者结果而改进。经由关注推动健康护理生态系统中更紧密的连接并且改进患者结果和体验的智能开关柜和匹配器而便于健康护理集成。下文是在后续章节中更详细解释的示例架构，其连同可以建立在其上的示例技术方案。

图4图示促成健康护理生态系统中的改进连接的示例架构400。示例架构或系统400包括具有学习系统的接口平台即服务（PaaS）401，用于改进护理连接。接口PaaS 401包括IntelliLink核心服务410、图形分析420和管理服务430。

IntelliLink核心服务410是便于云中的系统集成并且使新系统能够快速且容易集成的核心部件。接口注册表和存储库414存储可再用接口和由运行时接口管理器418加载的路由定义以实现消息转换和交换。机器学习引擎416监视消息交换和模式来习得并且预测连接优化器421所使用的流量和利用模式。关于健康护理生态系统中的连接的元数据在由在图4中示出的核心分析服务410使用的图形数据库413中存储和跟踪。

连接优化器421是建议引擎，其在健康护理提供者和患者试图与连接的健康护理生态系统中的各种健康护理提供者和工作人员接洽时提供基于上下文的推荐。

使用422和B2B（业务对业务）423分析用于提供例如对于未连接健康护理提供者的价值主张和关于如何改进连接的生态系统中患者移动的洞察等细节。管理服务和软件代理430的集用于使新系统预备和集成过程采用自助方式自动化。

图5（图5A、5B、5C）图示作为接口即服务（IaaS）501而提供的IntelliLink核心服务500，其包括可扩展集成总线和消息传递结构。可扩展集成总线502（例如，Apache Camel、RabbitMQ，等）在云结构（例如，关于网络570）中部署，从而在医院、门诊和/或专科实习和诊所581-585内部署的源系统之间提供连接性，该源系统应能够与目标系统交换健康护理相关临床和/或非临床信息。目标系统可以包括业务合作伙伴系统560（例如，付款人562、实验室564、诊所、专家、健康护理服务提供者、联邦机构566等）集中的一个或多个，其可以发回有意义响应，源系统将其嵌入它的业务处理逻辑和/或工作流程内。IntelliLink总线502在托管集成技术方案并且提供软件运行时和其他基础设施部件以及其他非关系型存储服务的云570（例如，Microsoft Azure或Amazon EC2）中部署。关于总线502（其包括它所促成的智能仲裁）的细节关于上文的图4详述。

如在图5（图5A、5B、5C）的示例中示出的，IntelliLink核心服务接口501包括具有一系列消息处理管道510的“核心”总线部件502，其在逻辑上抽象为下列层级：消息采集511、消息规格化/充实512、消息仲裁513和路由514。可插拔接口部件520用是逻辑单元的每个接口521-524来补充核心，该逻辑单元可以封装要经由即插即用连接而连接到总线502的目标系统的变换和消息传递工作流程。例如，电子数据互换（EDI）接口521允许一个或多个付款人562与数据分析器530接口。实验室接口522允许一个或多个参考实验室564与数据分析器530接口。健康信息交换（HIE）接口523允许HIE 568与数据分析器530接口。生物监测接口524允许一个或多个联邦机构566与数据分析器530接口。数据分析器530基于经由一个或多个外部合作伙伴560的相应接口521-524与它们的交互而便于关于临床数据仓库531、操作数据仓库532、人群健康数据存储533等中的一个或多个的数据分析和存储。

可插拔接口520允许Iaas 501在逻辑和物理上区分进行例如验证、安全数据采集、接口发现、消息规范化、消息内容充实、消息过滤、消息仲裁、基于内容的路由、错误管理和消息重放等特定动作的核心部件510与接口部件520，每个目标系统一个接口部件，其要连接并且专门定制来适应对于该产品或系统特定的消息处理核协议转换。接口注册表540跟踪可插拔接口520和它们的目标系统连接性。

管理代理550提供多个管理功能，例如安全/信任551、数据摄入器 552、自助服务门户553、审核仪表板554、服务门户555、自动预备服务556、警报仪表板557、接口管理器558等，连同核心处理管道510。

企业患者主索引（EMPI）505便于经由网络570关于一个或多个外部站点581-585的患者数据去识别和/或重新识别。从而，一个或多个医院581、582、585、专科实践583、诊所584等可以经由网络570（例如，互联网、内联网、虚拟专用网络和/或其他网络）与IaaS 501通信。另外，一个或多个增值服务506可以连同IaaS 501提供.

图6（图6A、6B）图示对于经由IntelliLink总线502的智能路由的示例企业集成模式（EIP）示意图600。EIP示意图600示出在系统内由核心智能路由引擎602和若干插入接口603界定的多个逻辑和物理层级。为了实现对“总线”602的消息交换，源系统601的服务层（SL）605处的通道适配器606用作消息传递客户端来构造并且发布消息以供IntelliLink消息采集服务所面对的接口端点服务603来消费。

接口端点服务603遵循合约定义的请求/响应类型（例如，由可扩展标记语言（XML）方案定义（XSD）复杂方案类型表示的）并且应提到例如健康等级七（HL7）、简单对象访问协议（SOAP）、XML/HTTP、表述性状态转移（REST）或公共对象请求代理架构（CORBA）等多种协议，并且通过例如传输控制协议（TCP）（例如，TCP（MINA））、超文本传输协议（HTTP）、Java消息服务（JMS）、高级消息队列协议（AMQP）、数据分配服务（DDS）、受约束应用协议（CoAP）和Java业务集成（JBI）等多个传输来运作。

IntelliLink消息采集通道或网关609使用消息通道企业集成模式，其中源应用601向充当门面的消息通道609发送命令消息607。利用关联的元数据将消息规格化614为规范化数据模型、利用来自外部数据源的内容对其进行充实619并且跨逻辑层级对其仲裁以智能路由622到接口消息通道624。消息采集通道暴露为粗粒度服务，其进行从客户端源的安全消息采集并且将它向前传递到另外的分布式处理下游，从而最终将消息路由到（规范化成标准格式）接口通道624。接口消息通道服务627粒度更细并且智能地结构化以适应是规格化、规范化数据格式化的请求消息625的最终目的地的目标系统604的逻辑和消息协议需求。接口实现支持例如HL7 v2.x/3.x、临床文档架构（CDA）等健康护理标准协议和使健康护理企业的跨企业文档共享（XDS）、患者身份交叉引用/患者人口统计查询（PIX/PDQ）、审核跟踪和节点验证（ATNA）、HL7快速健康护理互操作性资源（FHIR）和其他IHE简档集成。IntelliLink平台实现代表互连产品格局的公共、共享治理模型，以提供一致的系统初始化和接口预备。

IntelliLink包括强大的路由/仲裁引擎。IntelliLink的路由引擎定义路由和消息处理管道，其封装消息流和端点之间的中间处理。路由用借助于域特定语言（DSL）表达实现仲裁和路由规则的企业集成模式（EIP）的组合来开发和配置并且连线在一起。处理器用于在路由期间变换和操纵消息并且实现EIP模式。IntelliLink的消息采集通道例如经由安全Web服务（WS）-*端点或具有已配置的端点接口（和消息合约）（以宣告方式而配置）的RESTful端点来预备。在实施例中，消息采集通道还可以经由可以配置成接收HL7 v2.x消息的TCP（MINA）端点而可用。

消息采集通道609接收封装消息有效载荷的命令消息607连同关于消息要路由到的特定接口端点的元数据。IntelliLink核心602已经设计有智能消息处理管道和中间处理（例如，平台消息端点610、分流器611、调派器613、规整器614、动态路由器616、配置的规则库617、消息处理器通道618、内容充实器619、过程管理器620、过滤器621、基于内容的路由器622、接口通道适配器624），其便于包装消息有效载荷的解组和消息到接口订户的智能的基于内容的路由。

集成平台接口603提供接口消息通道627，其接收规格化、规范化消息625，并且通过接口消息端点628来对在端点633处接收消息并且经由服务层634而交互的目标系统604的消息627反规格化629并且转换630它。

从目标系统604的传出消息被转换器632接收、被反规格化630并且作为规格化、规范化数据格式响应626经由接口消息通道627提供回到核心602。核心602还包括反规格化器615和聚集器612，用于经由平台消息通道609将消息作为响应消息608从目标系统604调派回到源系统601的源通道适配器606和服务层605。

如在图6（图6A、6B）的接口设计示例中图示的，每个接口部署有至少三个部件：消息端点、接口配置和接口工厂。消息端点q在接口路由内定义，该接口路由为该接口的工作流程被专门定制，并且封装消息处理和协议转换来调用目标系统。接口配置qn包括预先定义的消息合约，其从消息内容方面定义接口期望接收什么，以及从消息内容方面接口期望接收的消息，以及接口希望在调用目标系统604后作为响应发回的消息。接口工厂返回接口路由717和接口配置712的具体实例。

图7图示系统700，其提供对于接口定义和配置的示例基于工厂的模型。示例系统700将接口710发布720到接口注册表701内用于一致预备和“热部署”系统初始化和启动。在示例中，接口配置712从接口性质文件714（例如，采用XML而结构化）加载，除其他元素外，还包括实现为定义请求/响应消息对象类型715、716的参数化类的消息处理器713。

接口710设计成可插拔到核心平台部件上并且如此可以实现为自我约束单元。因此，与每个接口710关联的配置714除定义的消息进/出合约外还包括支持接口710充当门面所面对的目标系统所特定的消息处理和协议转换的信息。该信息可以包括目标系统的端点718统一资源定位符（URL）或其他地址信息、对于每个回调充实传入的原始消息的回调服务列表。例如，可以包括目标系统特定的要应用于消息的查询或搜索准则和回调服务URL、消息过滤准则和其他业务规则定义。

IntelliLink IaaS平台然后可以从每个“插入”接口内包含的配置信息得到情报，其包括例如合约输入/输出格式类型、对于消息充实的规则（例如，对调用系统的服务层（和/或经由基于业务过程管理（BPM）或业务过程执行语言（BPEL）的过程管理器等的其他第三方系统）的回调服务列表）连同对于要执行的回调动作的查询/搜索准则、管理消息路由的额外业务级规则和要应用的消息过滤准则。配置可以使用XML语法和/或在一些示例中使用基于自定义表达的语法来实现，并且对于每个接口可是唯一的。

图8（图8A、8B）图示预备新接口的示例过程或工作流程800的流程图。新接口的创建和在上文描述的基于云的基础设施上预备接口包括用户发起的自助服务请求和模型驱动的自动预备工作流程800的组合。在框801处，工作流程800从自助服务门户（其是技术方案的部分）发起。工作流程800的发起触发模型驱动的自动预备服务，其生成伪影和代码以基于图7的工厂模型创建和部署接口。

在框802处，获得可用业务合作伙伴系统的列表。例如，获得一个或多个付款人、实验室、诊所、专家、健康护理服务提供者、联邦机构等的列表。在框803处，基于可用业务合作伙伴系统的列表，识别源和目标合作伙伴系统。

在框804处，显示接口合约定义界面屏幕。例如，便携式电脑、台式机、手持机（例如，智能电话、平板电脑等）和/或其他计算装置上的图形用户界面（GUI）可以用于显示定义接口合约的界面。在框805处，对目标系统接口定义并且输入接口合约要求（例如，请求/响应类型，等）。在框806处，接口消息处理器类响应于合约要求定义而生成。

在框807处，显示接口配置GUI屏幕。在框808处，经由接口配置GUI，定义对于目标系统接口的静态配置值。在框809处，接口配置性质文件基于对接口配置的输入定义而创建。

在框810处，显示业务规则配置屏幕。在框811处，定义对于目标系统接口的业务级规则。在框812处，业务级规则附加到接口配置性质文件。在框813处，接口配置类基于接口配置性质文件而生成。

在框814处，显示接口工作流程组件屏幕。在框815处，使用调色板工具栏，对目标接口组装业务级验证、处理、变换的模型驱动定义和工作流程。在框816处，生成接口路由、验证器、处理器和变换器类。

在框817处，使用编辑器，后端代码对模型驱动组件使用例如Camel集成软件开发工具包（SDK）来构造。在框818处，接口生成的类可用于编辑和定制。

在框819处，显示发布接口GUI以便于组件到云基础设施的部署。在框820处，生成接口工厂。在框821处，接口生成的类被编译、绑定和部署。

在框822处，接口发布到接口注册表内。例如，接口可由组装软件包激活器发布。在某些示例中，可发布接口。接口然后可用于使用。

在框823处，在接口管理器控制通道上接收消息（例如，对于接口的轮询消息）。在框824处，读取接口注册表（例如，云blob服务）。在框825处，接口路由和配置从接口工厂加载。在框826处，加载配置有效载荷（例如，XML配置有效载荷），其包括输入/输出（I/O）类型和处理器。在框827处，启动接口路由，并且例示接口端点和处理器。在框828处，例示接口消息采集通道。在框829处，接口消息采集通道用于倾听。

除消息采集通道外，IntelliLink核心还提供额外接口控制通道。接口管理器部件在该额外接口控制通道上通信。在接口预备时，为了宣告它的存在，每个接口发送发布到接口注册表的消息。在实施例中，对于新近部署的接口的绑定激活器发送消息，该消息在它发布到注册表时包装接口工厂资源路径。

在操作中，注册表可以存储在云存储服务（例如，Azure Blob存储服务或AmazonS3）内以跨部署中的服务结构而共享。在系统起动期间和在支持“热部署”的定期轮询窗口期间，该注册表由接口管理器读取，并且接口路由和配置类的具体实例从工厂加载。加载接口配置，并且启动接口路由并且例示端点。能适用于接口实现、管理消息路由的业务级规则然后被填充到云关系数据库RDB（例如，SQL Azure或Amazon RDB等）中的规则库内。在系统起动时，除读取控制接口行为的配置设置和启动接口路由外，接口管理器还启动在例如消息处理和路由中牵涉的所有中间核心camel路由。

图9描绘用于满足某些核心接口功能和邻接的示例软件代理和管理服务900。例如，软件代理模块901（在云连同IntelliLink上部署）可以连同IntelliLink一起使用来满足某些核心功能和邻接，例如安全、数据摄入、自动接口预备、服务门户、警报和审核。软件代理901包括接口管理器908，用于便于与一个或多个预备接口交互。

如在图9的示例中示出的，提供软件代理901、数据摄入器 907和分析器915。牵涉若干部件，并且软件代理901内的每个部件独立运作，而代理901编排部件之间的相互作用。例如，安全模块2检查并且处理到IntelliLink生态系统内部署的各种外部合作伙伴系统的所有传出/进入消息的安全证书。

在示例中，安全部件902部署为软件包，其在IntelliLink和核心消息传递路由被初始化时插入。安全单元902拦截并且处理要根据在IntelliLink与合作伙伴系统之间定义的安全和信任规范来签名和加密的传出消息。控制反转（IoC）和依赖注入（DI）模式可以用于例如各种部件以便切换绑定、提供者和模块。安全模块902内将经由IoC和DI而加载的一些核心部件包括：安全拦截器903、译解密码者905和证书解析器904以及证书和密钥存储906。

安全拦截器903是根据定义的安全和信任规范来处理进入和传出消息的消息处理器的代理实现。译解密码者905是对于消息加密/解密和消息签名操作的密码套件实现。证书解析器904负责发现（和定位）对于经由信任锚和撤销策略而与信任执行策略一致运作的目标目的地系统的公共和私有X509证书和密钥库。模块902实施有助于确保所有IntelliLink接口端点接收者具有有效证书并且允许IntelliLink根据信任策略发送到每个接收者的安全模型。消息使用为IntelliLink生成的证书和私钥来签名。消息使用随机对称密钥加密并且对称密钥使用接收者目标系统的公钥（对其的证书之前已经加载到系统密钥库并且由证书解析器904定位）来加密。相似地，在响应侧上，代理模块901使用接收者的私有证书和加密对称密钥来对消息905解密。另外，来自目标系统的消息签名也使用发送者的公共证书904、906来验证。

如在图9的示例中示出的，数据摄入器部件907用于分解和解析接收的临床数据内容。如果内容有效载荷是例如有效的综合临床文档架构（CCDA）文档或实验室诊单，则部件907使用例如开放健康工具API来解析结构以提取某些公共临床DTO元素。例如，CCDA可以在过敏段上下文上解析来提取过敏物质、不良反应、反应观察、状态观察和严重程度观察。相似地，还可以解析问题分段上下文来提取问题观察、年龄观察、健康状态和问题状态。同样，可以解析药物分段上下文来提取药物、药品载体、指示、指令、药物分发、药物信息、药物供应单、先决条件、反应观察。连同CCDA托管的某些段（例如过敏、问题列表、药物、规程和结果等），也可以解析某些可选段，例如：预先指示、就诊（encounter）、家族史、功能状态、免疫、医疗设备、付款人、护理计划和生命体征。临床DTO采用JavaScript对象标注（JSON）格式产生并且聚集。聚集的对象然后推入数据分析器平台915内。

数据分析器平台915通过利用大数据技术采用容错方式快速且高效管理高容量和高速率数据流。分布式大数据架构（例如Hadoop）与现代数据仓库/业务智能架构不同。Hadoop是用于在具有分布式节点的大的商用硬件集群上运行应用的开放源框架并且提供数据到Hadoop分布式文件系统（HDFS）、与GFS类似的高容错分布式文件系统、Google的专有文件系统内的高效自动分配。Hadoop的特征在于高容错和可靠性，其中大的文件分成较小的大小相同的块、跨集群散布并且被复制以避免单机失效并且使处理加速。

另外，数据分析器915还包括功能编程模型（例如MapReduce）的实现，其适合于通过将数据分区917成许多独立块的大量数据的并行处理。补充Hadoop/HDFS，广义类的DBMS和入库工具可以用于存储变化的广义分类数据类型，例如：结构化、半结构化和非结构化数据。例如，Apache HBase是在Google的大表之后模型化的开放源非关系数据库并且在HDFS顶部运行，从而提供像大表的存储能力，其具有表列数据的自动化且可配置分片。ApacheHive提供大数据入库工具916以在存储在HDFS中或其他存储系统（例如Hbase）中的数据实现ETL。它使用简单的像SQL的查询语言（叫作HiveQL），其中实际查询执行大量产生MapReduce任务。

在某些示例中，数据分析器915建立在Amazon Elastic MapReduce（EMR）上。Amazon EMR是Web服务，其实现海量数据的容易且web可扩展处理。Amazon EMR利用在Amazon弹性计算云（EC2）、Amazon 简单存储服务（S3）和Apache Hive的web规模基础设施上运行的托管的Hadoop框架。Amazon EMR允许聚焦在咀嚼或分析数据上而没有Hadoop（Hiver）集群或它们所处的计算容量的设置、预备、管理或调谐的时间（和成本）消耗。在解析出临床内容并且采用JSON格式提取DTO中牵涉数据摄入器部件907。提取的临床JSON记录每行一个地存储在日志文件中。因为可以使用默认文本格式（例如，Serde）读取记录，将记录存储在日志文件中使得易于它导入Hive。JSON文件然后由摄入器907推动用于暂时存储（例如，进入Amazon S3）。

Amazon Elastic MapReduce任务流然后将日志文件导入Hive 916内的分区表917。使用分区表917允许规定查询仅读取数据的子集而不是促使Hive 916进行全表扫描。一个分区策略使用当前日期和患者主索引（MPI）上的子分区，其为了更容易且更快查询而通过日期和患者标识符来隔离存在的临床元素。各种Hive脚本916然后可以在合成的“原始数据”上用于生成中间数据并且用“约简结果”填充表。数据可以直接分析、加载到其他非结构化数据库和/或合并到临床数据仓库和/或操作数据仓库923、924、925内并且与结构化数据相关。在传统数据仓库924、925环境中，可以利用常规业务智能报告、统计、语义和相关能力。

在某些示例中，脚本916处理分区表917中的数据连同复杂事件处理（CEP）引擎918和BPM/BPEL引擎919来生成一个或多个工作流过程920。工作流过程920可以经由仪表板921向用户和/或其他系统提供洞察（例如，提供视觉显示、报告、交互等）。例如，工作量过程还可以便于生成有效载荷922来调用IntelliLink接口的动作。

某些示例提供服务门户909来管理部署的消息传递基础设施和配置的路由。示例服务门户909包括自助服务部件910、自动预备服务部件911、警报部件912、审核部件913和可服务性部件914。服务门户909提供已经在生态系统中部署的所有接口的综合仪表板视图。综合仪表板视图还显示关于每个接口状态的元信息和相关度量、传输的消息、失效/出错的消息、最后的完成时间等。接口路由仪表板上的用户界面按钮和关联的点击事件起动和停止接口路由，由此提供对部署的接口的细粒度控制和管理。消息监视器仪表板视图示出已经路由直到接口的入站和出站消息。消息监视器仪表板提供针对数据库的基于过滤器的视图来获得满足某预定义准则的消息，例如开始/结束日期、出错消息、所有消息等。

在某些示例中，护理连接的图形数据库（例如，OrientDB、Neo4J、AllegroGrapth，等）用于存储健康护理生态系统内的关系。这样的关系可包括但不限于：人对人、患者对提供者、提供者对分包商、系统对接口、消息对系统、机器对机器、患者对提供者拜访、专家对位点、诊断对治疗、转诊对结果、患者对位点、提供者对专家、组织对组织、业务对业务和经授权的连接等。

图形数据库将图论应用于关于项之间的关系的信息的存储。图论是图形的研究，这些图形是用于使对象之间的成对关系模型化的数学结构。“图形”在该上下文中由“顶点”或“节点”和连接它们的线（叫作边）组成。节点/顶点代表患者、提供者、资源等，并且边示出例如两个或以上节点之间的连接。图形可是无向的，其意指在与每个边关联的两个顶点没有区分，或它的边可从一个顶点引导到另一个。有向图可以是例如单向和/或双向边。图形可以用于使健康护理系统中的许多类型的关系和过程模型化。

社交网络中人与人之间的关系是关系图的一个示例。推荐引擎中的项与属性之间的关系是另一个示例。因为消息交换保持流过IntelliLink服务总线502，图形数据库动态更新来跟踪健康护理生态系统内的关系和连接。图形还可以用例如来自全国提供者登记处的信息、医学参考信息、代码集、地理信息等参考信息来定期更新。

与传统分析相比，图形可以容易用用于模型化和分析的额外数据和额外关系来更新。图形分析可以用于识别例如数据点的集群或社区、数据点之间的连接和/或关系的模式。在某些示例中，图形分析可以至少在三个截然不同的区域中使用以有助于改进健康护理生态系统中的连接：连接优化、使用分析，和业务对业务（B2B）分析。

连接优化器是决策支持系统部件，其可以确定对于要在生态系统内建立的连接的最佳或改进路由信息和路径。当在健康护理交换生态系统内预备新的接口和系统时，连接优化器还用于优化或改进路由。例如，连接优化器可以解析患者应转诊到的最佳专家（给定患者的偏好、日期/时间、位点、成本、治疗选项等）。例如，连接优化器可以解析调度规程的最佳日期/时间以避免瓶颈。连接优化器可以解析医嘱应发送到的诊断实验室、专家、医院等，接着使请求负载平衡并且避免瓶颈。例如，连接优化器可以解析最可能导致拒绝保险索赔的医嘱模式。例如，连接优化器可以分析数据共享协定，其应在生态系统中的合作伙伴之间建立来改进患者护理。另外，连接优化器可以用于减少网络成本或使其最小化、优化性能和减少转诊网络中的搅动、减少患者移动、减少再次入院等。

使用分析可以提供关于用户和他们的健康护理系统之间的复杂交互的业务智能。使用分析跟踪许多用户、系统配置、应用使用数据等。在某些示例中，使用分析对于服务提供者提供关于系统的用户行为的信息，其可以有助于推动额外业务事务并且增加使用。例如，使用分析可以答复哪些类型的事务是最常见的以及哪些增值服务是最受欢迎的。

B2B分析提供关于有影响力的医生、诊所、组织等的分析信息，并且有助于发现在哪里在健康护理生态系统中存在未满足的需求。该信息可以例如用于直接将市场面向预期业务合作伙伴和系统用户。

某些示例包括机器学习引擎，用于利用分析和聚集的其他信息。机器学习引擎（例如，R引擎）可以训练成发现消息交换中的模式并且被教导来检测大数据集中隐藏的关系。机器学习引擎的预测能力可以用于向用户（提供者和患者）提供推荐。在某些示例中，结合图形分析的机器学习向健康护理系统的健康护理提供者和用户提供推荐和即时上下文信息。

使用接口集成平台系统和方法，可以实现多个技术方案。在示例（在图10A-B中图示的）中，可以便于智能转诊。图10A示出通过主护理提供者的导致不必要的拜访和诊断测试的患者转诊的示例。图10B示出使用智能转诊来减少低效和不必要动作的备选方案。如在图10A中示出的，在找到能够治疗患者的正确专家之前，患者以对各种专家进行六次拜访而结束。缺乏数据共享使导致严重患者不满和反复询问相同问题的情形加重。

如在图10B的示例中示出的，主护理提供者进行到健康护理交换的间接转诊，其中保持转诊记录直到找到理想专家。健康护理交换将区域中满足患者和主护理提供者的要求的建议的专家告知患者。患者具有请求来自每个专家（其经由健康护理交换而仲裁）的额外信息的选项。一旦患者选择要拜访的专家，更新图形数据库，这导致告知专家并且被授予访问来查看来自主护理提供者的转诊信息。

图11图示在专家之间呈扇形散出的“智能转诊”的示例实现。在1处，转诊提供者向健康护理交换提交转诊文档，其中暂时保持并且存储该转诊文档。在2处，患者接收对于区域内多个专家的建议。在3处，患者经由指导从可用专家的最佳专家选择的交换来发起报价征集。在5处，患者选择与转诊提供者连接的专家，并且将该专家添加到患者的护理圈团队。更新对应的图形数据库。可以提供IaaS（例如关于图4、5、9等描述的IaaS）以经由服务总线来便于接口、智能转换和路由、分析（例如，转诊优化器、使用分析、B2B分析，等）和多个服务（例如，通知服务、报价征集服务、调度服务、图像和文档共享服务和/或其他补充服务，等）。图形数据库可以提供提供者注册表（其包括护理过渡）并且对患者和专家授权护理连接。

图12图示关于患者移动和再入院分析的示例。图12的示例允许医院和诊所使在患者出院后产生的患者移动可视化。技术方案可以使用护理连接的图形数据库以及使用图形可视化工具来实现。如在图12中示出的，患者移动图形可以覆盖在地图上来使患者移动可视化。患者移动的复合视图可以帮助规划者和医院质量和遵从专员调查出院后随访中的再次入院和崩溃。

图13示出自发形成护理团队的示例。在图13的示例中，护理提供者可以向其他诊所、专家和转诊病人发出加入健康护理社交图的请求，该健康护理社交图也存储在护理连接图形数据库中。如在图13中示出的，在1-2处，当专家接收并且接受加入转诊交换的请求时，对应的组织在3处也接收用基于云的集成平台和转诊网络设置合适数据流的请求。该过程允许转诊交换经由对于新接口和数据流的自助服务预备过程而快速扩展。在4处，连接的专家然后可以可开出转诊单。

图14图示从间接到直接连接的移动的示例。图14图示断开的提供者如何经由患者和关联事件序列而连接。在1处，主护理提供者经由健康护理交换进行间接转诊并且上传转诊信息。在2处，给予患者转诊单，其具有快速响应（QR）代码和/或URL以传递给专家。在3处，患者拜访专家并且交出转诊单。在4处，专家经由他或她的移动装置扫描代码并且从可以下载转诊信息的地方被引导到健康护理交换门户。在5处，在稍后的时间点，健康护理交换系统向专家发送让他的组织加入交换的请求。在6处，在主护理提供者与专家之间建立数据共享协定。在图形数据库中跟踪双方之间的数据共享协定以在双方之间实现未来直接交换。

某些示例利用文档数据交换。对于数据交换的临床文档格式可以使用综合临床文档架构（CCDA）。CCDA代表来自健康等级七（HL7）的协调努力的结果，使健康企业（IHE）、健康信息技术标准组（HITSP）、来自IHE患者护理协调（PCC）和护理连续性（CCD）的部件集成。综合CDA格式可以用于涵盖下列结构化临床文档：护理连续性文档（CCD）、出院小结、会诊记录、医学数字成像和通信（DICOM）诊断成像报告、病史和体格、手术记录、病程记录和规程记录。CCDA托管对于每个类型的之前提到的文档的特定内容，其包含在分段临床数据元素内。需要编篡分段数据，其中需要支持38个独特词汇（其包括SNOMED-CT和LONIC）。

在某些示例中，医院和/或门诊病人电子健康档案（HER）技术方案可以在每个医院就诊后捕获、创建CCD并且将其传输到文档注册表和存储库（例如可以基于XDS）。

在某些示例中，CCD通过基于XSLT（样式表）的变换服务而生成，该变换服务将数据库生成的专有GXML临床内容结构映射到CCDA数据模型。依据由CCDA规定的词汇要求，查找服务用于从针对CE主概念数据交叉映射且存储在CE数据库内的Lexicon映射表查找词汇。支持RxNorm、LONIC、UCUM和SNOMED-CT术语的词库已经使用支持从美国元词表或任何其他术语知识库加载相应术语的通用加载工具加载到词库映射表。词汇查找服务将运行时绑定词库代码查找调用以在使用Apache Xalan-Java XSLT处理器框架（来自Apache开放源联盟）执行样式表变换期间发生，该处理器框架允许使用基于Java的扩展功能利用对过程式语言的调用来增广XSLT的功能性。用Java编写的扩展由Xalan-Java直接支持。对于存储在词库映射表内的词库代码映射的查找，我们将需要使用Xalan-Java扩展功能。基本模式如下：在变换中牵涉的样式表将使用扩展功能来将输入串作为变元（其包含例如在XML源内包含的药物名称）传递到词汇查找框架，其然后经由DB查找（JDBC/Hibernate）调用来查找词汇代码。查询的结果集传递回到扩展功能，其然后将结果插回运行时XSLT处理上下文内。一旦创建有效的格式化CCDA，它然后可以经由IntelliLink基于云的集成技术方案路由到DRR。

在某些示例中，IntelliLink平台从例如医院或门诊或专科诊所等源系统接收消息交换请求，该源系统向健康信息交换（HIE）发送消息有效载荷（例如，遵循CCDA规范的护理连续性文档CCD）。在示例中，消息有效载荷可以包括要采用标准HL7电子格式输出到实验室服务提供者的包装实验室诊单。还可以相似地促成免疫信息到免疫注册表的批量输出。合适的消息在源系统内生成并且然后采用规范化消息格式包装。在示例中，工业标准接口引擎（例如Mirth Connect、Cloverleaf、Iguana、Intersystems Ensemble、Oracle SOASuite等）可以在现场用于创建消息有效载荷并且采用事务或批量模式将其从源系统安全传输到IntelliLink消息采集通道上。现场接口引擎负责接收、仲裁消息并且将其从内部源应用变换到规范化消息格式上，如由IntelliLink的消息采集通道指示的。消息然后向前安全路由到InterlliLink总线用于随后路由到预订接口。

从源系统发送的消息有效载荷是CCD或实验室诊单，其在包含源系统的临床信息系统/EMR中创建。可再用服务集可以对受保护的健康信息（PHI）去识别（和重新识别）。在示例中，从源系统发送的患者数据首先使用企业患者主索引（EMPI）、对于事务使用亲和域患者ID来去识别。在示例中，企业患者主索引（EMPI）系统可以用于解析患者身份。

EMPI评估来自亲和域内的完全不同系统的数据、对于记录创建企业唯一标识符（EUID）并且维持EUID和与患者关联的所有本地标识符之间的映射。在发送请求之前源系统患者ID的重新识别和来自响应（从目标系统回来）的本地患者ID的后续重新识别将牵涉源系统（接口引擎主要起到PIX消费者的作用）与EMPI系统（起到PIX管理器的作用）之间的患者标识符交叉引用（PIX）查询。在实施例中，PiX查询将在为其创建的IntelliLink接口内路由。PIX查询对应于IHE IT基础设施技术框架的事务ITI-9并且牵涉对于对应于消费者已知的患者标识符的患者标识符列表的患者标识符交叉引用消费者角色的请求。请求由患者标识符交叉引用管理器（EMPI系统）接收。患者标识符交叉引用管理器立即处理请求并且采用对应患者标识符列表（如有的话）的形式返回响应。

某些示例影响生物监测和传染病爆发管理。在某些示例中，存储在Hive 917内的数据被实时处理并且发送到流播复杂事件处理（CEP）引擎918以连续处理进入数据、分析模式并且引发对于数据中的某些预定义模式的事件（如例如在图9中示出的）。CEP 918可以得到业务过程管理（BPM）或业务过程执行语言（BPEL）引擎919（例如Activiti或任何其他BPMN2兼容过程引擎）的支持来定义过程并且基于引发的事件采取合适的动作。实时业务活动监视器（BAM）仪表板921提供立即洞察并且生成动作。

对于使用智能事件检测的使用情况可以包括对于公众健康监测和对于爆发管理的生物监测。生成的动作对于检测的综合病症事件到公众健康监测数据库的提交创建消息和有效载荷。事件检测算法可以基于实验室数据、临床就诊（护理总结）数据和非临床数据，其然后发送到各个国家、州和本地疾病监测系统。

CDC国家法定疾病监测系统（NNDSS）需要从国家定义的传染病列表上的实验室和临床数据输出的报告。相似地，对于来自临床和非临床源的症候数据存在各种州和本地疾病监测系统来检测公众健康威胁事件。有意义的使用后，公众健康监测主要聚焦在症候监测上，其主要聚焦在基于实验室、临床就诊数据和非临床数据的事件检测上。

备份智能事件检测算法的数据牵涉综合CDA（CCDA）：设施人口统计包括对于报告的联系数据和发送者数据、患者人口统计、实验室和放射诊单/结果、生命体征（例如心率、呼吸、血压、身高和体重）、观察、症状和临床发现、分诊记录、妊娠状态、疾病严重度（通风/插管指示）。数据集提交要求多半与如之前在生物监测最小数据集中规定和使用HL7V2.5.1传输的相同。

对疾病爆发或传染病的症候依据检测的有效动作是创建消息有效载荷，其然后需要基于HITSP定义的格式转换成HL7 2.5.x结构并且发送出站到CDC或任何州或本地监测系统或登记处。工作流过程创建生物监测数据集有效载荷，其然后向前路由到预先定义的CDC（或任何其他第三方监测系统）IntelliLink接口，对该接口委授予变换到正确消息协议并且将消息向前路由到目标系统的职责。

图15（图15A、15B）图示云部署的实验室中心的接口即服务实现的示例示意图。例如HL7和IHE等标准可以用于通过基本上在临床信息系统（CIS）、内部和/或外部实验室信息系统（LIS）和实验室自动化系统（LAS）之间提供基于标准的连接性（例如，支持各种客户部署）而实现云部署的中心。CIS的示例可以是主要为医院和医疗中心设计的GE的中心性HER技术方案，或为大的实践和诊所设计的GE的中心性实践技术方案。

IHE提供与临床实验室中的体外诊断测试有关的各种实验室简档寻址信息共享和工作流程。例如，IHE LTW（实验室测试工作流程）简档使开诊单、调度、处理和与由健康护理机构中的临床实验室进行的诊断测试关联的结果报告活动集成。LTW集成简档包含CIS、LIS和LAS之间的各种工作流程和动作（涵盖开诊单、诊单填写、对于诊单结果报告和跟踪的自动化管理器）。简档利用对于最新的患者和就诊数据的IT基础设施简档PAM/PDQ和对于审核和安全的ANTA简档。在实施例中，需要利用外部LIS开出实验室诊单的CIS的预设部署可以将实验室诊单（其包装实验室诊单细节并且传送包装的有效载荷）发送到定义的IntelliLink接口（例如，利用基于云的实验室中心基础设施），其提供将包装的实验室诊单细节变换成LTW的必需LTW简档的组件化工厂实现并且与目标接收者LIS通信。在该工作流程中起到诊单填写者作用的目标LIS将在完成诊单时利用相同IntelliLink基础设施来将结果报告路由回到开诊单者角色CIS。预期所有预设的消息传递（在CIS或LIS内）将通过HL7接口引擎或网关发生。

在某些示例中，接口引擎或网关包括工厂LTW简档（或ILW或IHE实验室简档中的任一个接口）的内部实现并且创建实验室诊单并且在使用该简档创建的包装有效载荷中将其发送到IntelliLink云中心。在该情况下，预订IntelliLink解开请求并且将请求转发到目标接收者而不需要任何工厂简档变换。IHE实验室间工作流程（ILW）简档对于消息传递在使用相同的基于云的实验室中心基础设施的两个（或若干）不同LIS之间发生时的实施例支持在两个实验室之间的测试诊单和结果的交换。一个实验室是请求者；它的LIS实现新的角色“请求者”，其对第二实验室（称作分包实验室）开出测试子诊单。该第二实验室的LIS实现新的角色“分包商”，其将完成子诊单并且将结果发送回到请求者角色。实验室代码集分布（LCSD）简档能够在实验室工作流程中牵涉的系统之间建立、维持和共享共同命名。每当需要对该代码集更新时，拥有实验室代码集-代码集主要角色-的系统将整个代码集发送到任何代码集消费者角色。在实施例中，轻量工作流程和业务过程管理平台（BPM）在用ActivitiBPMN2过程引擎实现的实施例中将需要维持执行序列状态并且确定下一个处理步骤。前面提到的实验室集成简档定义事务，其全部基于HL7 2.5或2.5.1消息标准。每个事务由消息结构的子集组成（基于OML、ORU、ORL和OUL）并且规定应用于每个消息结构的约束集。

图16（图16A、16B）图示远程ICU技术方案的接口即服务实现的示意图。远程ICU技术方案可以由例如GE的高敏锐护理技术方案（中心性急救护理）驱动，并且使远程医院能够对它们的垂危患者提供先进咨询、护理和监视而不必将他们转移到特级专科医院。远程ICU实现的远程ICU监视技术允许总控中心处的医师在24/7基础上监视来自远程ICU/医院的垂危患者的实时参数。远程ICU技术方案通过音频/视频能力（其在示例中连同技术方案提供）帮助与本地医生合作来及时治疗和监视患者。

某些示例提供具有基于嵌入式现有技术规则的引擎的决策支持模块（例如，GE的Care Plus）接口，其允许跟踪临床参数并且将其用于在自动化工作流程中生成临床通知。药物交互模块允许剂量的预定义协议支持并且与决策支持系统集成帮助在不正确护理决策的情况下引发警报/事件。临床通知系统模块（CNS）将收集的海量数据与用户定义的规则相比较、识别潜在相关临床事件并且在XML有效载荷中生成消息，其然后可以路由并且交付给总控中心。GE或非GE商用HL7接口引擎可以在每个远程站点处使用以从生成的XML有效载荷创建HL7消息传输格式、进行从其他专有格式的转换服务并且将HL7传输到基于云的“接口即服务”。装置和患者数据IntelliLink接口用于捕获、解析、聚集和高速缓存对于从每个远程地点流播的装置或患者数据特定的内容。高速缓存的数据然后定期发送到总控中心处的基于web的UI应用，其生成仪表板并且提供关于跨所有远程医院地点的数据的可付诸行动的信息的聚集视图。

在某些示例中，来自每个远程站点的高速缓存数据发送到在命令站点处的web服务器上运行的RESTful服务，其然后聚集数据并且使用Websocket技术的实现将它推到HTML5查看器应用。Websocket对于服务器提供标准化HTML5方式以便在客户端未征集的情况下发送内容到浏览器并且允许消息来回传递同时保持连接打开。这样，双向全双工行进中的会话可以在浏览器与服务器之间发生。集中式仪表板控制台提供关于跨所有远程站点的患者到坐在总控中心的医师和临床医生为了积极主动和咨询护理的聚集信息凝聚。例如，内置到GE的中心性系统的智能警报可以标记患者状况中的趋势，像提取白细胞计数激增、开始低烧等。引发的警报或事件将由生成被HL7变换并且经由接口引擎发送到部署的IntelliLink接口的消息且在其上用于向总控中心仪表板显示的临床通知服务得到。当远程ICU总控中心处的医师将所有这些放在一起时，他们能够推断严重感染是否开始，由此有助于及时干预来改进患者结果。在示例中，聚集的患者/装置数据存储在总控中心处的永久存储中以在瞬态用户界面应用停用的情况下重新创建仪表板用户界面。

III. 示例计算装置和计算机/机器可读指令

在某些示例中，机器可读指令可以用于实现本文公开且描述的示例系统和方法。在这些示例中，机器可读指令包括供处理器执行的程序，例如在下文结合图17论述的示例处理器平台1700中示出的处理器1712。程序可以在例如CD-ROM、软盘、硬驱动器、数字多功能盘（DVD）、BLU-RAY™盘或与处理器1712关联的存储器等有形的计算机可读存储介质上存储的软件中体现，但整个程序和/或其部分可以备选地由除处理器1712以外的装置执行和/或在固件或专用硬件中体现。此外，尽管示例程序参考上文的流程图和示意图描述，可以备选地使用实现示例系统和方法的许多其他方法。例如，框的执行顺序可以改变，和/或描述的框中的一些可以改变、省略或组合。

如上文提到的，上文公开的示例过程可以使用存储在例如以下等有形的计算机可读存储介质上的编码指令（例如，计算机和/或机器可读指令）来实现：硬盘驱动器、闪存、只读存储器（ROM）、压缩盘（CD）、数字多功能盘（DVD）、高速缓存、随机存取存储器（RAM）和/或其中持续任何持续时间（例如，持续延长时段、永久、持续短暂实例、暂时缓冲和/或信息的高速缓存）地存储信息的任何其他存储装置或存储盘。如本文使用的，术语有形的计算机可读存储介质明确定义成包括任何类型的计算机可读存储装置和/或存储盘并且排除传播信号且排除传输介质。如本文使用的，“有形的计算机可读存储介质”和“有形的机器可读存储介质”能互换地使用。另外或备选地，示例过程可以使用存储在例如以下等非暂时性计算机和/或机器可读介质上的编码指令（例如，计算机和/或机器可读指令）来实现：硬盘驱动器、闪存、只读存储器、压缩盘、数字多功能盘、高速缓存、随机存取存储器和/或持续任何持续时间（例如，持续延长时段、永久、持续短暂实例、暂时缓冲和/或信息的高速缓存）地存储信息的任何其他存储装置或存储盘。如本文使用的，术语非暂时性计算机可读介质明确定义成包括任何类型的计算机可读存储装置和/或存储盘并且排除传播信号且排除传输介质。如本文使用的，当短语“至少”在权利要求的前序中用作过渡术语时，它采用与术语“包括”是开放式的相同的方式而是开放式的。

该描述的主旨可以实现为独立系统或作为能够由一个或多个计算装置执行的应用而供执行。采用经由计算装置便于与用户接口（接收输入/指令、生成图形图示）的方式，应用（例如，web页面、可下载的小程序或其他移动可执行文件）可以生成在本文描述为图形用户界面（GUI）或其他视觉表示的各种显示或图形/视觉表示，其可生成为web页面或类似物。

如本文引用的存储器和处理器可以作为各种可编程装置的部分而独立或一体式地构造，这些可编程装置包括例如台式计算机或便携式计算机硬驱动器、现场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、片上系统（SOC）、可编程逻辑装置（PLD）等或类似物或作为计算装置的部分，或其组合，其能操作成执行与实现本文描述的主旨的方法关联的指令。

如本文引用的计算装置可以包括：移动电话；计算机，例如台式机或便携式电脑类型；个人数字助理（PDA）或移动电话；笔记本电脑、平板或其他移动计算装置；或类似物和其任何组合。

如本文引用的计算机可读存储介质或计算机程序产品是有形的（并且备选地，作为非暂时性的（上文定义的））并且可以包括易失性和非易失性、可移动和不可移动介质，用于存储电子格式的信息，例如计算机可读程序指令或指令、数据的模块等，其可以是独立的或作为计算装置的部分。计算机可读存储介质或计算机程序产品的示例包括但不限于，RAM、ROM、EEPROM、闪存、CD-ROM、DVD-ROM或其他光存储、磁盒、磁带、磁盘存储或其他磁存储装置，或可以用于存储期望电子格式的信息并且可以由处理器或计算装置的至少一部分访问的任何其他介质。

如本文引用的术语模块和部件一般代表程序代码或指令，当其在处理器上执行时引起规定任务。程序代码可以存储在一个或多个计算机可读介质中。

如本文引用的网络可以包括但不限于：广域网（WAN）；局域网（LAN）；互联网；有线或无线（例如，光、蓝牙、射频（RF））网络；计算机、路由器、服务器、网关等基于云的计算基础设施；或与之关联的其任何组合，且允许系统或其部分与一个或多个计算装置通信的。

术语用户和/或该术语的复数形式一般用于指能够访问、使用本公开或从其获益的那些人。

图17是能够执行指令来实现本文公开和描述的示例系统和方法的示例处理器平台1700的框图。处理器平台1700可以例如是服务器、个人计算机、移动装置（例如，手机、智能电话、平板电脑（例如IPAD™））、个人数字助理（PDA）、互联网家电或任何其他类型的计算装置。

图示示例的处理器平台1700包括处理器1712。图示示例的处理器1712是硬件。例如，处理器1712可以由来自任何制造期望家族或制造商的一个或多个集成电路、逻辑电路、微处理器或控制器来实现。

图示示例的处理器1712包括本地存储器1713（例如，高速缓存）。图示示例的处理器1712经由总线1718与主存储器（其包括易失性存储器1714和非易失性存储器1716）通信。易失性存储器1714可以由同步动态随机存取存储器（SDRAM）、动态随机存取存储器（DRAM）、RAMBUS动态随机存取存储器（RDRAM）和/或任何其他类型的随机存取存储器装置实现。非易失性存储器1716可以由闪存和/或任何其他期望类型的存储器装置实现。对主存储器1714、1716的访问由存储器控制器控制。

图示示例的处理器平台1700还包括接口电路1720。该接口电路1720可以由任何类型的接口标准实现，例如以太网接口、通用串行总线（USB）和/或PCI高速接口。

在图示的示例中，一个或多个输入装置1722连接到接口电路1720。输入装置1722准许用户将数据和命令输入处理器1712内。输入装置可以由例如音频传感器、麦克风、拍摄装置（静物或视频）、键盘、按钮、鼠标、触屏、跟踪板、轨迹球、等位点（isopoint）和/或语音识别系统实现。

一个或多个输出装置1724也连接到图示示例的接口电路1720。输出装置1724可以例如由显示装置（发光二极管（LED）、有机发光二极管（OLED）、液晶显示器、阴极射线管显示器（CRT）、触屏、触觉输出装置、发光二极管（LED）、打印机和/或扬声器）实现。图示示例的接口电路1720从而典型地包括图形驱动卡、图形驱动芯片或图形驱动处理器。

图示示例的接口电路1720还包括通信装置，例如发送器、接收器、收发器、调制解调器和/或网络接口卡，用于经由网络1726（例如，以太网连接、数字订户线（DSL）、电话线、同轴电缆、蜂窝电话系统，等）便于与外部机器（例如，任何种类的计算装置）的数据交换。

图示示例的处理器平台1700还包括一个或多个大容量存储装置1728，用于存储软件和/或数据。这样的大容量存储装置1728的示例包括软盘驱动器、硬盘驱动器、压缩盘驱动器、蓝光盘驱动器、RAID系统和数字多功能盘（DVD）驱动器。

编码指令1732可以存储在相同大容量存储装置1728中、易失性存储器1714中、非易失性存储器1716中和/或例如CD或DVD等可移动有形计算机可读存储介质中。

IV. 结论

从而，某些示例提供临床知识平台，其使健康护理机构能够提高性能、减少成本、接触更多人以及全局交付更好质量。在某些示例中，临床知识平台使健康护理交付组织能够针对他们的质量目标提高性能，从而以低的合适成本导致更好的患者护理。

某些示例便于提高对数据的控制。例如，某些示例系统和方法使护理提供者能够基于集成的动态接口预备工厂系统/方法从多个目标系统访问数据。某些示例便于对过程的提高控制。例如，某些示例系统和方法在系统与数据之间提供改进的系统接口预备和动态交互。某些示例经由集成接口系统和方法而便于对结果的提高控制。某些示例利用信息技术基础设施来使跨组织的数据标准化且集中。在某些示例中，这包括从单个位点访问多个系统，同时允许跨系统和用户的更大数据一致性。

某些示例通过连接的应用生态系统并且通过使健康护理连接成为无所不在的商品而实现增值服务。互操作性是多年来健康护理行业的最大问题之一并且许多公司得益于缺乏互操作性。有个说法是“如果你看见一个HL7接口，你就看到一个”，其意思是没有两个是类似的。这在提出的集成方案中导致大量冗余和低效。

从而，某些示例通过在互操作性问题方面跨共同健康护理集成场景使用一致解决方案在各种健康护理IT产品内去除方法中的重叠和冗余而解决这些挑战、低效、需求和失效。某些示例提供多个个体独立可插拔接口作为到通过执行相关交互和编排的集中式智能平台而互连的健康护理IT产品的门面。某些示例提供使用标准化治理模型并且通过大量使用自动化而简化的新接口的创建和预备。在某些示例中，建立连接的生态系统的图形，其能够优化连接并且避免交通障碍。

某些示例对于多种健康护理信息系统提供灵巧、灵活、可适应的“即插即用”集成策略，由此为增加的客户满意度和明显的业务胜利增加机会。例如，在远程ICU的上下文内提供接口即服务实现使远程医院处的护理提供者能够对垂危患者提供先进咨询、护理和监视而不必将他们转移到特级专科医院。远程ICU实现的远程ICU监视技术允许总控中心处的医师在24/7基础上监视来自远程ICU/医院的垂危患者的实时参数。该技术模型（使用围绕接口即服务的概念作为它的中心论题）在可以例如在远程放射或远程ER空间中启动的新产品中具有分支。某些示例充当交换或代理，其征集谁可用于患者转诊同时减少多个患者拜访并且使基于云的交换、转诊和另外的动作集中。可以在元层处促成分析、连接和接口来提高相关性同时保护隐私且维持遵从性。

上文描述的主旨的技术效果可以包括但不限于，提供系统和方法以在提高对患者、提供者、资源和数据的了解的情况下建立更好连接的健康护理生态系统。本文公开的主旨提供以下技术效果：变换数据、路由数据、获得系统和接口的知识以及提供分析来理解如何可以基于患者移动、交换的数据、使用的资源等来改进健康护理生态系统和创建接口。此外，用允许由跨不同位点的装置生成的大量数据更容易交换、分类、分析、起作用和从中学习来实现提供更具战略性的决策制定、从技术投入实现更多价值和在交付服务中实现提高的质量和遵从、更好的客户或业务结果和在复杂工作流程环境（其可牵涉跨不同位点的资源约束）内在资产的生产率、维护和管理方面的操作效率的优化这一方式，本文描述的该主旨的系统和方法可以配置成更好理解大量这样的数据的能力。

该书面描述使用示例来公开主旨，并且还使本领域内技术人员能够制作和使用本发明。主旨的专利范围由下列权利要求限定，并且可包括本领域内技术人员想到的其他示例。这样的其他示例如果它们具有不与权利要求的书面语言不同的结构要素，或者如果它们包括与权利要求的书面语言无实质区别的结构要素则规定在权利要求的范围内。

Claims (6)

1.一种改进健康护理生态系统内的连接的方法，所述方法包括：

使用处理器，存储多个可再用接口和路由定义以在健康护理生态系统中的源系统与目标系统之间转换和交换数据消息；

使用所述处理器，经由机器学习系统来监视健康护理环境中的消息交换和模式，以预测所述健康护理生态系统中的流量和利用模式；

使用所述处理器，跟踪关于涉及所述源系统和所述目标系统的连接的元数据，并将所述元数据存储在图形数据库中；

使用所述处理器，基于所监视的消息交换和模式以及来自所述图形数据库的元数据，使用图形分析来建议所述源系统和所述目标系统之间的连接；以及

使用所述处理器，基于建议的连接来预备所述源系统和所述目标系统之间的接口，所述接口基于所述建议的连接从所述多个可再用接口和路由定义中预备。

2.一种改进健康护理生态系统中的实体之间的连接的系统，所述系统包括：

处理器，所述处理器被配置成至少执行以下操作：

存储多个可再用接口和路由定义以在健康护理生态系统中的源系统与目标系统之间转换和交换数据消息；

经由机器学习系统来监视健康护理环境中的消息交换和模式，以预测所述健康护理生态系统中的流量和利用模式；

跟踪关于涉及所述源系统和所述目标系统的连接的元数据，并将所述元数据存储在图形数据库中；

基于所监视的消息交换和模式以及来自所述图形数据库的元数据，使用图形分析来建议所述源系统和所述目标系统之间的连接；以及

基于建议的连接来预备所述源系统和所述目标系统之间的接口，所述接口基于所述建议的连接从所述多个可再用接口和路由定义中预备。

3.一种计算机存储介质，其包括程序指令，供计算装置执行来执行改进健康护理生态系统内的连接的方法，所述方法包括：

存储多个可再用接口和路由定义以在健康护理生态系统中的源系统与目标系统之间转换和交换数据消息；

经由机器学习系统来监视健康护理环境中的消息交换和模式，以预测所述健康护理生态系统中的流量和利用模式；

跟踪关于涉及所述源系统和所述目标系统的连接的元数据，并将所述元数据存储在图形数据库中；

基于所监视的消息交换和模式以及来自所述图形数据库的元数据，使用图形分析来建议所述源系统和所述目标系统之间的连接；以及

基于建议的连接来预备所述源系统和所述目标系统之间的接口，所述接口基于所述建议的连接从所述多个可再用接口和路由定义中预备。

4.一种经由集成平台方便动态接口定义和配置的方法，所述方法包括：

使用处理器，存储多个可再用接口和路由定义以在健康护理生态系统中的源系统与目标系统之间转换和交换数据消息；

使用所述处理器，经由机器学习系统来监视健康护理环境中的消息交换和模式，以预测所述健康护理生态系统中的流量和利用模式；

使用所述处理器，跟踪关于涉及所述源系统和所述目标系统的连接的元数据，并将所述元数据存储在图形数据库中；

使用所述处理器，基于所监视的消息交换和模式以及来自所述图形数据库的元数据，使用图形分析来建议所述源系统和所述目标系统之间的连接；以及

使用所述处理器，基于建议的连接来预备所述源系统和所述目标系统之间的接口，所述接口基于所述建议的连接从所述多个可再用接口和路由定义中预备。

5.一种集成平台系统，便于动态接口定义和配置，所述集成平台系统包括：

处理器，所述处理器被配置成至少执行以下操作：

存储多个可再用接口和路由定义以在健康护理生态系统中的源系统与目标系统之间转换和交换数据消息；

经由机器学习系统来监视健康护理环境中的消息交换和模式，以预测所述健康护理生态系统中的流量和利用模式；

跟踪关于涉及所述源系统和所述目标系统的连接的元数据，并将所述元数据存储在图形数据库中；

基于所监视的消息交换和模式以及来自所述图形数据库的元数据，使用图形分析来建议所述源系统和所述目标系统之间的连接；以及

基于建议的连接来预备所述源系统和所述目标系统之间的接口，所述接口基于所述建议的连接从所述多个可再用接口和路由定义中预备。

6.如权利要求5所述的系统，其中所述系统部署为接口即服务。

Images