共计 3793 个字符，预计需要花费 10 分钟才能阅读完成。
医疗健康行业无论在国内外都是采用先进技术的先驱者之一，原因在于业内的利益相关者会更加接近数据、重视数据的重要性，从而加快在决策上面的动作，以期更好的患者的预期寿命和增进社会人口的健康。更重要的是，数据的质量和可用性足够的透明，使得以患者数据为中心的模型在医疗行业中发挥起重要的作用。
根据斯坦福医学 2017 年健康趋势报告在过去的十年中，医疗健康行业捕获的数据量大幅增长。这是由于例如政府采取了电子病历（EMR）平台、设备（X 射线，MRI，CT 等）对医疗记录进行数字化，以及无处不在的个人健康 / 健身监视器（智能穿戴设备如 Apple Watch 等）。
接下来我们将讨论如何使用 API 市场（包括其后面的一系列解决方案）作为解决此问题的方法。通过 API 市场，管理者可以安全地开放或者部分开放这些数据（用户的隐私数据和受到法律保护的信息不在描述范围当中），使医疗行业的患者或医疗机构和公民都可以访问这些数据，从而提高医疗健康行业的效率并实现人口健康技术的创新。
API 市场作为解决方案
在当今世界，数据平台已经成为了众多不同商业体系的运转中心，而 API 作为平台的数据连接器起到了关键的作用。各行各业都开始积极采用 API 优先的系统开发方法，我们在医疗健康领域也能很明显的看到这一点。一个健全的 API 市场可以解决医疗健康数据的商用问题，它将与数据使用者进行 API 社交，让他们从数据当中获取更多的信息，以便进行产品和技术的创新。API 市场鼓励医疗机构或者医药企业思考如何更好的使用和保管他们合法的研究数据，并通过高可用性的 API 计划提供医疗数据，并进而产生效益。
从实际出发，医疗健康行业的 API 市场主要担负的，是将医疗数据使用者和产生者建立起联系，而相应解决方案的最终愿景，则是建立一个以 API 市场为基础，以医疗健康数据合法交易为导向的经济体。在这个经济体当中，应该有一个全面的 API 管理平台，它为 API 市场概念提供了动力，而该平台使数据供应商能够设计，发布和管理 API，同时实施安全管理，数据应用治理和收集分析工作。
图 1：解决方案架构
通过该解决方案，我们可以了解医疗健康 IT 领域的整体需求（对于其他行业也有很大一部分数据或者 API 是有共通的用处）。当所有产品的开发者和管理者都在使用基于 API 管理解决方案时，数据供应商会将所获得的合法的数据发布在 API 市场上，有需要的企业则同时会在市场上联系他们感兴趣的 API 供应商；API 市场为供应方和消费方搭建了一个开放而安全的价值交换渠道，使得数据消费方可以根据所获得的数据产生更有价值或者有潜在价值的产品。
API 市场各模块角色
图 2：API 市场角色及数据流向分析
API 生产者： 指的是 API 的设计师、架构师、开发人员、测试人员、发布人员。负责定义每一个 API 的应用范围（内部使用，外部使用，使用限制和使用权利）。在大型医疗项目的 API 生产中，生产者可以来自不同的医疗组织机构或者是企业。
平台拥有者： 指的是 API 市场的维护及搭建人员。他们负责 API 市场模块的维护，并促进 API 使用者之间的协作，并需要及时向 API 提供商报告消费者反馈。他们负责了整个 API 市场的平台宣传、支持和社区建设等任务。
API 使用者 / 消费者： 指的主要是应用程序开发，是愿意利用医疗数据并从中获取价值的创新者；同时，这指代的可能是健康发展项目、医疗健康创业公司、跨国卫生组织、医院团体或者政府，他们热衷于提高医疗健康水平，为行业提供更好的医疗解决方案。
医疗健康 API 市场的组成
图 3：Healthcare API 市场的组件
API 的管理是平台的基础，它包含了 API 的网关、安全、管理、设计发布以及分析部分。
API 网关是整个平台的入口，最终与实际数据后端 EHR 系统相连接。它与 API 安全模块是密不可分的，另外它还将基于安全策略和令牌的信息为整个 API 管理平台提供支持服务。
鉴于 API 数据的敏感性，在开发、发布、维护等每一个阶段都需要进行强有力的管理——通过 API 管理系统和平台管理者的维护，能够很好的强化和控制 API 的使用，并为管理者提供了良好的管理策略和使用模式。
开发人员在发布 API 后，需要能够持续监控、测试和管理已发布的 API，而 API 管理解决方案除了提供这些功能以外，还应该能够针对 API 调用失败，响应时间突然增加或 API 资源访问模式等异常变化，提供建议解决方案并发出报警提醒。
技术选择
在提出的解决方案中，我们将系统集成和 API 管理视为两个不同的必备组件，需要深思的是集成组件应该可以通过不同协议与各种医疗健康系统做到集成。在此之后，它还需要对数据进行转换和规范化，进而提供一个统一的接口以供使用。在底层之上的集成层，应该根据管理者在 API 管理系统上设置的测策略，对所有数据进行脱敏和匿名处理。当然，我们可以找到非常多不同的技术栈和框架达成此目的，比方说 Apache Camel，Apache Synapse，Apache ServiceMix，Spring 集成和 Ballerina 等等。
API 管理模块的组成主要有高性能的网关用于身份验证的密钥服务器，用于限制和分析的事件处理器，和用于 API 列表的开发人员门户以及用于职称管理的工作流引擎。一些流行的开源产品封装了这些功能，包括 eolinker API Manager，GoKu API Gateway、Kong API Gateway 和 Tyk API Gateway。
参考实施
下图是对我们所描述的框架进行了整合，并标出了可以使用这些技术选项的地方。这个图偏向于开源平台和其他框架，这为后期平台的发展和功能的定制提供了极大的灵活性。
图 4：具有技术选择的实现架构
在此实现中，API 管理系统提供了 API 全生命周期管理的功能，包括 API 使用、管理、商业化，数据安全和路由 API 管理，而 API 请求则将通过 API 网关发送到管理平台。
参考图的方案同时兼考虑了 API 的生命周期 – 一旦新 API 发布，那么就必须弃用先前版本，并且将通知到所有 API 订阅者。API 解决方案应当可以通过内部设置处理此问题，因此在 API 生命周期的每个阶段都应可以与该阶段对应的操作相关联，如图 5 所示。
图 5：示例 API 生命周期视图
API 的安全性是整个 API 管理体系首要考虑的因素。虽然身份验证和授权是通过密钥或令牌完成的，但是更高级的权利应当是通过 OAuth 令牌的对应信息进行授权应用的。该信息可以是高级用户组的确认验证，也可以是关于数据使用者的属性判断，距个例子比如是例如使用者的设备或者地理位置等。
图 6：为 API 操作应用授权 OAuth 范围的示例
API 管理平台应当可以控制通过何种方式向第三方公开数据，例如允许无限制访问或受限制策略限制。而于此同时，API 管理平台也应该能对请求数量和速率进行相应的规则限制。
图 7：如何将限制策略应用于 API 订阅的示例视图
API 管理系统的应当为使用者提供一个窗口，让他们可以在当中寻找、试用和订阅所有或者部分的 API。这个门户网站将为产品和开发人员通过获取的数据进行发展创新。这一个平台记录了每一个入驻平台的 API 的功能和使用方法，而同时也允许管理者们对这些 API 进行分类，并推送给所有在此平台上感兴趣的用户，让他们将感兴趣的 API 有偿（或无偿）地集成到他们的应用当中。
图 8：具有 Patient / Provider FHIR API 的开发人员门户的示例视图
API 管理系统的分析功能提供了最常见的 API 使用数据视图，为不同的使用者提供了有足够客观性的数据。而对于平台维护者来说，这可以为相关技术设备升级规划的决策提供更多的资料和信息。这样的好处是，API 消费者可以进一步了解健康数据的可用性和重要性，而 API 提供商则可以提供和数据采集有关的更多数据。
图 9：医疗保健 API 分析视图示例
在国内的 API 接口管理工具中，能完整实现 API 管理全流程并且体验较好的平台和工具就是 EOLINKER 了，而在国外诸如 POSTMAN、Swagger 功能也很强大，EOLINKER 包括接口文档编辑、API 测试、自动化测试和 API 监控和 API 网关等功能，能体验到完整的 API 研发方案。如果要说起其中区别的话，就是 POSTMAN 注重测试，Swagger 注重接口管理，不过国外全英的语言对国人也不是很友好, 而 EOLINKER 相对会更加全面，因此有需求或者感兴趣可以各自了解下 EOLINKER、POSTMAN、Swagger。
未来的改进
我们在上面的讨论中模拟了一个简单的场景，以展示医疗健康 API 市场的实际用途。不单单是医疗健康类 API，所有 API 都可以从基于 API 管理解决方案的基础上，提供更多的价值。数据从来都不应该是封闭的，只有充分的利用数据本身的价值，让其在更多的机构、创业者手中得到灵活运用，才能创造出更大的价值。一方面可以让数据提供方获得更多的服务，另一方面则可以促进服务创新发展。
值得关注的其中一点是，在有效的利用 API 进行服务创新和价值创新的同时，我们要对 API 的安全性投入更多的关注，而随着社会的进步发展，API 经济将逐步被人们所重视，API 的管理和使用将会在各行各业的发展中发挥更大的作用。
参考资料：Sachini Samson，Transforming the Healthcare Industry through API Marketplaces，https://dzone.com/articles/ap…
