本文要点

医疗保健行业收集了大量与个人健康相关的数据，但这些数据都处于孤岛状态，难以为每个人的利益服务。
在广泛的受众群体中共享健康信息时，数据隐私是一个主要问题。在围绕健康信息而构建的平台中，全面实施适当的安全措施至关重要。
建立一个连接医疗保健行业所有利益相关者的平台可以提高整个护理流程的效率，连接不同利益相关者的事件为建立有效的医疗保健市场起到重要作用。
以患者为中心的API对于降低人类死亡率来说至关重要。驻留在EHR / EMR系统中的现有原始数据需要转换并汇总成更多以患者为中心的API，这将有助于现代应用程序开发人员构建创新的医疗保健产品和应用程序。
选择技术合作伙伴来构建有效的医疗保健平台是一项需要得到充分理解和需要关注细节的任务。有许多技术供应商可以为医疗保健市场的要求提供支持，最终的选择应该取决于各个组织的技术、财务和文化。

为什么医疗保健需要API市场？

医疗保健行业是一个主要的技术采用者先驱，它们让利益相关者更接近数据，从而加快了决策过程，并逐步改善了预期人口寿命和健康。越来越明显的是，数据的质量和可用性在建立透明、以患者为中心的医疗保健行业中发挥着重要作用。根据斯坦福医学2017年健康趋势报告，在过去的十年中，医疗保健行业的数据量有了大幅增长。这源于许多原因，例如政府采取的“有意义使用”等政策举措、电子病历（EMR）平台的广泛可用性、直接从设备（X射线、MRI、CT等）对医疗记录进行数字化，以及无处不在的个人健康/健身监测仪器（Fitbit、Apple Watch等）。

医疗行业的一个关键问题是有价值的数据点被隐藏和孤立了，虽然这些数据点是人为产生的，但是人们却无法获得这些数据点，或者没有有效的方式来使用这些数据点。如今，个人提供者和医疗机构是这些数据的保管者，数据被放在数据库中，却很少被利用。

为了解决这个问题，本文讨论了API市场方法。通过API市场，我们可以安全地公开这些数据点，医疗保健行业的利益相关者和公民都可以访问它们，从而提高行业效率，并实现人口健康技术的创新。

数据太多带来的问题

拥有海量数据是一个很好的“问题”。在很多情况下，各个行业在进行数据分析时缺乏有意义的数据点。从这个意义上讲，医疗保健行业处于领先地位。如今，世界各地的许多医疗机构和医疗保健机构都在记录、总结并根据患者数据做出决策。这些数据通常驻留在一个或多个EMR系统中，具体多少取决于护理组织的大小，并且通常孤立在该机构内，或者更糟糕的是，孤立在应用程序内，我们很难看到这些数据可以变成消费品。当我们尝试进一步解决这个问题，就会发现一些相关的问题：首先，健康应用程序和机构不会优先考虑超出其已知范围的数据共享；其次，目前的人口健康数据是不可消费的。

从医疗保健应用领域来看，我们看到了高水平的专业化，例如癌症护理、糖尿病患者、心脏病学或儿科提供者机构所使用的特定领域的EMR平台。因此，以患者为中心的综合视角非常重要。

无法共享数据在很大程度上是保护性公共政策造成的。由于法律非常关注隐私问题，大多数国家/地区都有保护个人身份健康记录的政策指令（如HIPAA）。因此，来自EMR的原始数据不能也不应该被暴露，这在无意之中导致医疗保健数据被禁锢在医疗保健组织和专业医疗保健应用程序中。

现代的EMR平台是API驱动的，在暴露临床数据会时遵循医疗行业标准，如HL7和FHIR，这是积极正面的。尽管这些举措使数据访问标准化，但没有解决开放访问数据可用性的问题。

医疗保健行业的众包潜力是另一个容易被忽视的机会。我们并没有看到有太多医疗初创公司会关注人口健康，因为进入壁垒很高，或者更重要的是，数据访问的障碍太大。如果健康数据更加大众化并可以进行消费，那将带来大量的创新，使该行业的所有利益相关者都受益。

API市场成为解决方案

在当今以平台为中心的商业世界里，API被视为数字的连接器。各行各业的组织都采用API优先的开发方法，我们在医疗保健领域也看到了这一点，例如几乎所有以数据为中心的数据访问临床平台都采用了FHIR标准。然而，关键的缺失部分是API市场的可用性，以及基于API网关的生态系统。API市场解决了如何发现健康数据的问题，API与利益相关者交互，促进他们进行创新。市场将鼓励健康机构思考如何公开、组织所保管的数据，并通过开放的API计划提供健康数据。

在实际意义上，医疗保健API市场主要将医疗数据消费者与生产者联系起来。该解决方案的愿景是建立一个以市场为基础、以医疗保健交易为导向的经济体。它还讨论了一个全面的API管理平台，为市场化这个概念提供了动力。该平台使提供商机构能够设计、发布和管理API，在保证安全性的同时，进行应用治理和数据收集分析。

该解决方案特别强调了API的管理功能，因为它可以解决与医疗保健数据相关的一些问题。网关上的数据授权等功能可以向提供商机构提供保证，即保证为消费者传输的数据是在正确的范围内。我们将在健康API类型中详细讨论这些功能。

图1 解决方案架构

通过描述上面的解决方案，我们可以对医疗保健IT领域的利益相关者有所了解。工程师和业务领导者拥有数据访问渠道标准化和治理的平台；一些利益相关者会产生需要发布的数据，因此他们会联系感兴趣的相关方；有些利益相关者为最终用户建立价值渠道。这些利益相关者聚合多个数据源并创建有价值的产品，然后由最终用户消费这些数据并得出结论、做出决定。

API市场的利益相关者

图2：利益相关者分析

API生产者群体 涵盖了负责设计、开发、发布和测试医疗保健API的设计师、架构师、医疗保健产品开发人员和API测试人员，这个小组负责定义API范围（内部、外部、限制和授权）。在大型医疗保健API数据交换中，生产者可以来自不同的医疗保健机构。

平台拥有者群体 保证了API市场的正常运作，他们维护组件，促进API使用者之间的协作，并向API生产者提供使用者的反馈。他们承担了平台宣传、平台支持和社区建设等任务。

API使用者群体 来自应用程序的开发社区。他们是愿意利用医疗数据并从中获取价值的创新者。他们可以是人口健康驱动的倡议者、医疗保健初创企业、医疗保健机构、医院集团和政府，热衷于改善多方面的医疗保健环境。

医疗保健API市场的组件

成功的医疗保健API市场应该包含三个方面的东西：

API管理
开发者门户
活动

图3：健康API市场的组件

API管理 是这个平台的基本要素，解决了跨领域的架构问题。它封装了运行库（网关）、安全层、治理层、分析层和许可管理层。

API网关的运行库充当了平台的入口点，最终与实际数据后端的EHR系统连接。它与安全层无缝集成，提供基于令牌的安全性和基于策略的授权。

鉴于通过这些API公开的数据的敏感性，API市场为API的开发、发布和全生命周期维护提供了强有力的治理是至关重要的。API的暴露方式、人员驱动的治理模型、策略管理和依赖性分析都是通过API治理层来控制的。

开发人员发布API后，他们应该能够监控、测量和管理已发布的API，此功能由API的分析组件提供。除了基于批处理的分析之外，该层还可以为API调用失败、响应时间突然增加或API资源访问模式变更等方案创建警报。

许可管理层实现工作流程，确保为数据共享、存储和使用提供必要的许可。这是策略驱动的，有时依赖于基于机器的决策或人为参与。

开发者门户 发布API。它让所有相关方都能够发现可用的数据流并了解如何使用它们。开发者门户解决了医疗平台健康数据的可见性问题。所有专门的医疗保健系统都可以在由提供者机构、医院或公共医疗保健交易所维护的中央开发者门户中检索API。

使用技术组件构建一个出色的API市场只是整个过程的一部分，为了建立成功的医疗保健API市场，平台所有者可以参与以下这些活动：

研讨会——研讨会为API消费者提供了一个教育平台，可以解决一些入门问题。主题应包括：如何在医疗监管范围内使用数据？采用哪些安全协议和策略？许可管理如何运作？
激励性黑客攻击——建立市场的主要目标之一是实现医疗保健领域的创新，激励性黑客攻击被认为是朝这个方向移动的一个推动因素。平台所有者可以托管黑客攻击，并根据健康数据产生新的想法。
布道——内部和外部的布道使平台更受欢迎。
排行榜和分析仪表板——展示创新项目、启动产品并提供API使用模式的可视化。

医疗保健API

市场中的API可以根据其消费模式进行产品分类。在医疗保健领域，常见的模式包括患者注册、调度、财务和计费、保险、临床、辅助、公共健康和物联网。

注册API

注册API用来管理与EMR系统相关的注册功能。通过这些注册API，开发人员可以开发与不同EMR系统进行集成的接口，用来管理患者特定的数据交换。身份验证和授权是这些API的关键需求，因为它们提供了与消费者数据相关的所有后续活动的入口。API市场中的API管理层可以为这些API活动提供关键的安全构造。

调度API

调度API的功能包括：安排预约、发送预约提醒、检查预约时间段以及更新、取消或重新安排预约。调度是医疗保健市场中常用的功能之一，它与各种系统（包括账单、消息和通知）集成在一起。API网关运行库以及集成层可以在这些系统之间提供所需的桥梁，从而为患者提供轻松的调度体验。

财务API

财务API用来管理护理提供者机构和各当事方之间的资金交易。这些财务API可以进一步细分，例如可以分为计费API、索赔API等。医疗保险在医疗保健行业的财务部门发挥着重要作用。索赔管理系统有助于检查索赔状态、取消或调整以及自动付款过账，它公开的API使支付方能够连接到合作伙伴系统。安全性是这些API的关键需求之一，特别是强身份验证和授权。为了支持其中的一些需求，需要有一个能够与外部身份提供者（IDP）交互的API管理平台。

临床API

临床API将基于不同的标准（如HL7v2、HL7v3和FHIR）通过EHR/EMR系统来管理临床数据交换。成熟的API平台具有数据格式转换功能，因此它可以连接到多个系统，并根据使用者的要求提供数据传送。这些系统包括一些特殊的数据流，如患者用药数据、治疗计划、免疫详细信息和家庭病史，医生利用这些数据来决定病人的健康状况。患者可以借助API驱动的以患者为中心的应用程序来查看他们的药物、诊断和病史。这样可以鼓励患者更多地参与个人健康诊断，也符合公共医疗政策，例如“有意义使用”政策。

辅助API

辅助API用来管理与核心临床功能（如药房、实验室、放射科等）相分离的系统的信息。这里有一些示例，包括与外部药房就用药处方和续药请求进行通信、用不同的信息系统交换实验室结果的数据，以及用外部营养系统来管理膳食订单。通过安全通道（B2B）与外部系统连接是这些API的关键需求，支持各种安全协议（如OAuth2、SAML、OIDC）的API管理系统将有助于与这些第三方系统安全连接。

公共健康API

公共健康API可以用于指导通过交换公众、联邦或专业注册机构可报告临床数据来跟踪公共健康。这些API能够提供公共卫生监督所需的数据。公共健康API向政府和其他研究机构提供存储在电子病历（EMR）中的临床健康数据，并从这些机构获取数据，以丰富本地的临床记录。这两项事务都是在给定的标准下进行的，以确保健康数据的隐私。当提供此类数据流时，API运行库可以对记录进行清洗和去识别化，以确保这些数据是匿名的，这是一个成熟API运行库必备的实用功能之一。

物联网/活动跟踪API

近年来，可穿戴健康/活动监测设备呈指数增长。这些数据流开启了个人健康监控的新维度，通过可消费的平台公开这些流，可以加速以患者为中心的健康应用程序的创新。

技术选择

在所提议的解决方案中，我们将系统集成和API管理视为两个不同的组件，需要经过深思熟虑的分析。集成组件应该通过不同的协议和消息格式与不同的医疗保健系统集成。然后，它需要通过统一的接口来转换和规范化数据。集成层应根据某些策略在必要时清理和匿名化数据，有多个技术栈和框架可用于执行这个任务，比如一些领先的开源产品，如Apache Camel、Apache Synapse、Apache ServiceMix、Spring Integration和Ballerina。

API管理组件由一组功能组成，包括高性能网关、用于身份验证的密钥服务器、用于限制和分析的事件处理器、用于显示API列表的开发者门户，以及用于许可管理的工作流引擎。一些流行的开源产品封装了这些功能，包括WSO2 API Manager，Kong API Gateway和Tyk API Gateway。

参考实施

出于概念验证的目的，参考实现显示了每种技术可以被用在什么地方。它偏向于开源平台和框架，因为它们为不断发展的平台提供了很大的灵活性。

图4：包含技术选型的实现架构

在这个实现中，API管理器支持完整的API生命周期管理功能，包括API实现、管理、货币化、安全和路由API流量。这样一来，来自公开API的请求可以通过API网关路由到集成组件。

参考实现考虑到了API的生命周期——一旦发布API，就必须弃用以前的版本，并且必须通知订户。API管理解决方案通过生命周期执行器来处理这个问题，因此每个API生命周期阶段都可以与要采取的操作相关联，如图5所示。

图5：API生命周期视图示例

API安全也是主要的考虑因素，虽然身份验证和授权是通过令牌完成的，但细粒度的授权是通过OAuth令牌作用域来实现的。作用域可以通过用户组进行验证，也可以通过健康数据消费者的一组属性进行验证，例如设备、位置等。

图6：为API操作应用授权OAuth作用域的示例

API平台可以控制如何向第三方公开数据，允许无限或受限访问策略。API管理平台的限制引擎定义了与被允许的请求数和数据使用率相关的规则，并强制执行。

图7：如何将限制策略应用于API订阅示例

API管理组件的开发者门户提供了一个中央枢纽，可以在这里发现、试用和订阅所有API。开发者门户提供了一个创新平台，记录了每个API可以使用的内容以及如何使用这些数据。开发者门户对本文中描述的API进行分类，允许相关方订阅这些API并将其集成到应用程序中。

图8：具有病人/提供者 FHIR API的开发者门户示例

API管理分析提供了访问最频繁的API及其使用方式的视图，为多个受众提供了有用的见解。对于平台维护人员来说，他们可以知道有关技术能力规划的决策。API用户可以了解健康数据的可用性，API提供商可以了解在哪里可以得到更多关于数据采集的信息。

图9：医疗保健API分析视图示例

一旦API调用将请求委托给解决方案的集成层，ApacheSynapse、Camel、Spring Integration或Ballerina等框架就可以执行集成功能。一旦集成框架接收到请求，它将检查本地注册表条目，以确定医院属于哪个EHR系统。这些值可以存储为文本字符串、XML或URL。这也可以通过在文件或数据库中查找来实现。

图10：根据用户属性进行系统查找

通过本地条目检查之后，将使用消息过滤器来执行验证，检查医院名称是否保存在本地注册表条目中。如果未找到医院，则会将故障信息作为错误消息发送回API，表示该医院不可用。

图11：过滤/验证过程

<inSequence>
<!--Obtain the value for the respected hospitalName parameter from the local registry-->
        <propertyexpression="get-property($url:hospitalName)"name="ehrSystem"scope="default"type="STRING"xmlns:ns="http://org.apache.synapse/xsd"/>

<!--Check if the hospital-Name is located in the local registry entry-->
       <filterxpath="boolean(get-property('ehrSystem'))">
              <then>
              ...
	          </then>		 	 	 	
              <else>
                      <logdescription="Fault"level="custom"separator=",">
                               <propertyname="STATUS"value="Invoke fault "/>
                      </log>
                      <payloadFactorymedia-type="json">
                             <format>{ "Error":{      "errorType":"InvalidParameter","details":"The Hospital-Name parameter is invalid" } }
                             </format>
                             <args/>
                      </payloadFactory>
                      <propertyname="HTTP_SC"scope="axis2"type="STRING"value="400"/>
                      <respond/>
              </else>
     </filter>
</inSequence>

代码块1：使用Apache Synapse进行医院名称验证

集成框架使用一个或多个连接器访问来自不同EHR平台的数据，从而允许用户与第三方健康供应商（如Epic、Cerner等）进行交互。基于EHR系统，集成器将确定请求被路由到何处，并调用Cerner连接器或Epic连接器来获取来自各自EHR系统的数据。

图12：路由请求

以下的Synapse配置（XML）用于初始化Epic和Cerner连接器并获取诊断报告数据。

<switchsource="$ctx:ehrSystem">
<caseregex="Cerner">
	<!--Initialize the Cerner Connector-->	 	 	
<cerner.init>
<base>https://fhir-open.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca</base>
</cerner.init>

<!--Search DiagnosticReport Operation→
<cerner.searchDiagnosticReport>
		<patient>{$ctx:patient}</patient>
<subject>{$ctx:subject}</subject>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
<count>{$ctx:count}</count>
</cerner.searchDiagnosticReport>	 	 	 	
<respond/>
</case>
<case regex="Epic">
<!--Initialize the Epic Connector--> 	 	 	
<epic.init>
		<base>https://open-ic.epic.com/FHIR/api/FHIR/DSTU2</base>
</epic.init>

<!--SearchDiagnosticReportOperation→<epic.searchDiagnosticReport>
		<id>{$ctx:id}</id>
<patient>{$ctx:patient}</patient>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
</epic.searchDiagnosticReport>	 	 	 	
<respond/>
</case>
<default/>
</switch>

代码块2：使用Apache Synapse路由到相应的EHR系统

基于EHR系统检索到的响应通过API网关发送到API。

未来的改进

我们在前一节中讨论的参考实现考虑到了一个简单的场景，用以展示医疗保健API市场的实际使用。为了支持医疗保健行业的广泛需求，可以对这个参考实现进行改进，包括：

与个人数字健康设备集成；
与第三方医疗保健服务提供商集成；
构建以患者为中心的移动应用程序；
与医疗保健研究机构集成，提供有价值的数据。

随着医疗保健服务和技术的发展，医疗保健API市场将在数字医疗行业中发挥主导作用。

作者简介

Nuwan Bandara是一名解决方案架构师，在集成和消息传递软件项目上与财富1000强全球企业紧密合作。他是WSO2的董事，并且领导着北美的方案解决工程师团队。Nuwan致力于医疗保健、政府和金融行业的项目，简化系统集成。他是一名程序员、演讲者和作家。

Chanaka Fernando是WSO2的解决方案架构师。他与金融、教育、医疗保健和电信等各个领域的企业客户密切合作。他在WSO2的整合平台团队中担任技术主管和产品负责人，这是他最长的一段职业生涯。

Sachini Samson是斯里兰卡信息技术学院的三年级软件工程专业学生，目前正在WSO2进行软件工程实习。Samson是本文提到的参考实现的核心开发人员。

查看英文原文：Transforming the Healthcare Industry Through API Marketplaces

创作场景

API 市场带来了医疗保健行业的巨大转变