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

本文要点

医疗保健行业收集了大量与个人健康相关的数据，但这些数据都处于孤岛状态，难以为每个人的利益服务。
在广泛的受众群体中共享健康信息时，数据隐私是一个主要问题。在围绕健康信息而构建的平台中，全面实施适当的安全措施至关重要。
建立一个连接医疗保健行业所有利益相关者的平台可以提高整个护理流程的效率，连接不同利益相关者的事件为建立有效的医疗保健市场起到重要作用。
以患者为中心的 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 类型中详细讨论这些功能。

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

API 市场的利益相关者

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

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

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

医疗保健 API 市场的组件

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

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。

参考实施

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

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

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

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

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

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

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

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

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

<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 系统的数据。

以下的 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>