医疗API深度解析：2024年类型、提供商和用例指南

想象一下理想的医疗环境，在那里健身追踪器、患者应用程序、医院系统、药房软件和实验室工具可以毫不费力地交换数据。在这个想象的世界中，任何相关方（从患者到医生再到医学研究人员）都可以通过智能手机即时访问相应的文件。

但现实看起来却大不相同。来自美国 50 个州的 90% 以上的患者抱怨缺乏数据共享，其中 67% 的患者计划因此更换护理提供者。更令人惊讶的是，传真和电话，尽管互联网已经普及，仍然是全国各地卫生部门首选的通信方式。

为了解决这个问题，于2020 年推出了互操作性规则。这些规则旨在实现医疗领域的无缝数据传输，预计将禁止使用过时的设备。医疗保健利益相关者将主要依赖应用程序编程接口或 API，而不是传真机。

本文介绍了 API 在整个行业中的当前使用情况。也就是说，我们将进行调查

• EHR APIs
• consolidated APIs to access patient data
• clinical data management and analytics APIs
• public health content APIs
• drug data and drug interaction checking APIs
• symptom checker APIs
• telehealth APIs

主要医疗 API 类型和示例。

但首先，我们将探讨特定于医疗保健的数据交换标准，这些标准对于了解医疗保健 API 的工作原理至关重要。

医疗保健数据交换的关键标准

医疗保健行业坚持数据标准，帮助行业系统和专业人士保持一致。您可以从我们的文章《医疗保健数据标准》中了解有关整个行业使用的代码和格式的更多信息。在这里，我们将只关注与通过 API 进行数据交换相关的最关键规范。

FHIR API 及其在互操作性中的作用

FHIR 是 Fast Healthcare Interoperability Resources 的缩写，是主要的行业标准，专为共享医疗保健数据而开发，特别是电子健康记录。它利用在 HTTPS （HTTP Secure） 协议上实施的 REST API 架构，使卫生系统能够以 JSON 和 XML 格式交换数据。

FHIR 背后的理念是将患者记录表示为一组资源，或具有相同大小和结构的独立数据块。每个资源都有一个唯一的 ID，并包含一小部分信息（例如，化验结果或药物详细信息）。根据查询，基于 FHIR 的 API 检索合并到较大文档中的单个资源或组合。

FHIR 数据模型。来源： HL7 FHIR 版本 4

根据互操作性规则，医疗保健提供商和付款人必须实施 FHIR，才能通过健康应用程序向患者提供临床和索赔数据的某些元素。

但是，预计随着时间的推移，该标准将在整个行业中得到广泛采用，所有医疗数据都将构建为小型、离散的资源。

USCDI 标准

USCDI 代表 United States Core Data for Interoperability。它定义了一组强制性数据片段，这些数据应患者的请求通过其 FHIR API 公开。

USCDI 中的数据元素与 FHIR 中的数据元素一致，并属于更大的数据类，例如

• 过敏和不耐受
• 评估和治疗计划
• 护理团队成员
• 临床笔记
• 目标
• 健康问题
• 免疫 接种
• 实验室检查和结果
• 药物
• 患者人口统计学
• 问题
• 程序
• 种源
• 吸烟状况
• 患者植入式设备的唯一设备标识符
• 生命体征

USCDI 的第二个版本现在处于草案阶段，包含两个新类别：诊断成像和遭遇信息。

USCDI 第二版中的数据类和元素。来源： HeathIT.gov

安全标准

通常，通过医疗保健 API 的数据可以归类为受保护的健康信息 （PHI）。 因此，它受隐私和安全标准的约束，旨在防止未经授权访问和滥用敏感信息。

在美国，这些标准由《健康保险流通与责任法案》（HIPAA） 规定。除其他外，它解释了必须使用哪些技术和程序来保证适当的安全级别。在欧盟，健康数据受《通用数据保护条例》（GDPR） 保护。

这两项法律都授予患者访问其个人信息的权利，并要求大多数医疗保健 API 符合 HIPAA 或 GDPR 标准。这意味着数据必须仅对授权用户开放，并在传输前进行加密。

SMART on FHIR

SMART是 Substitutable Medical Apps & Reusable Technology（可替代的医疗应用程序和可重复使用的技术）的缩写。其目的是概述如何安全地将使用 FHIR 的 EHR 系统与第三方应用程序集成。除其他外，SMART 规定应用 OAth2.0 身份验证协议。不过，HIPAA 和其他法规的合规性不在其范围之内。

该框架支持患者和提供者应用程序，这些应用程序可以作为独立解决方案启动，也可以直接插入 EHR 系统。

牢记标准，让我们继续讨论 FHIR API 在医疗保健领域的预期用例 — 访问电子健康记录。

EHR API：从健康记录中提取数据元素

公开的数据：存储在一个健康 IT 系统中的USCDI 数据元素和其他患者信息

使用它们构建什么：面向患者的健康应用程序、远程医疗平台、用于跟踪和监控治疗计划的患者管理解决方案、对现有患者门户的增强。

自然，领先的 EHR 供应商早在互操作性规则生效之前就率先遵守这些规则。在这里，我们将回顾来自市场份额最大的 EHR 系统的 FHIR 资源，即

• Epic （29%）、
• Cerner（26%）
• MEDITECH （17%）
• Allscripts （7%）。

四大医院和卫生系统加起来覆盖了近 80% 的美国医院和卫生系统，因此它们的 API 值得更仔细研究。

Epic on FHIR API

超过 2.5 亿美国患者的健康记录在 Epic 生态系统中。通过 Epic on FHIR API 提供对此数据的访问。开发人员可以创建将检索 50 多个数据元素的应用程序，包括但不限于 USCDI 集。

Epic 提供了一个自助式测试沙盒，用于在上线之前尝试集成并了解其行为。响应和支持的操作（搜索、读取、创建）因使用应用程序的用户（患者或医务工作者）而异。

Epic 不会验证开发人员或使用 FHIR API 设计软件的许可。因此，您对您的产品及其对所有适用法规的遵守情况负全部责任。

Cerner Ignite API

Cerner 覆盖近 1 亿美国患者，提供支持 30 多种 FHIR 资源的 Ignite API。可以搜索、读取它们，在某些情况下，还可以创建或更新它们。

除此之外，Cerner 还有一个单独的 API 可以从其人口健康管理平台 Healthelntent 检索数据。它能从多个数据源自动生成病人记录，而不是从单一文件中提取信息片段。API 仅适用于企业对企业解决方案。

该公司的开放沙盒允许开发人员在没有身份验证的情况下测试他们的应用程序。完成后，软件必须经过可能需要 10 到 14 周的验证过程。

针对 Cerner API 构建的应用程序的验证过程。来源：Cerner 的开放开发人员计划

MEDITECH Patient Health Data API

排名第一的急症护理和家庭健康 EHR 使客户端应用程序能够通过Patient Health Data APIs与其数据库进行交互。这些API允许对16种与USCDI数据类别相一致的数据资源进行只读访问。

为了针对真实的 MEDITECH EHR 测试项目，该公司有一个名为 Greenfield 的开发环境。该沙盒包括详细的文档、来自获得许可的 MEDITECH 开发人员的技术支持以及在线论坛。

但是，此选项仅适用于 MEDITECH Expanse 客户。要获得此身份，您必须通过特殊表单提交有关您和应用程序用途的数据。然后，只需等待并希望您的提交获得批准。

Allscripts FHIR API

2020 年，Allscripts 被评为门诊和住院医院的顶级 EHR 供应商。该公司总共连接了 2000 万患者。其 FHIR API 将第三方链接到 Allscripts 的所有产品。

目前，API 适用于 14 个 USCDI 类。开发人员可以在相应的沙盒环境中测试他们的集成。要使用支持 FHIR 的 API，您只需注册 Open Allscripts Developer Program （ADP） 即可。但是，此选项仅允许构建患者端应用程序。想要连接到 Allscripts 产品的健康公司必须成为 ADP 集成商，这将授予他们使用公司专有 API 的权利。

整合的患者数据 API：整合来自 EHR、实验室、可穿戴设备等的数据

公开的数据：从各种来源收集的患者 USCDI 和非 USCDI 数据

用它们构建什么：健康和保健应用程序、疾病和药物管理工具、远程医疗平台。

阅读主要文章 Health Data APIs

这个基于 FHIR 的 API 系列的代表是供应商中立的，这意味着它们从广泛的来源提取患者数据，包括 EHR 系统和可穿戴设备。以下是此类整合患者数据 API 的三个示例。

可通过不同 API 访问的 FHIR 元素。

临床数据管理 API：利用 Amazon、Google 和 Microsoft 分析的强大功能

公开的功能：NLP 引擎和机器学习算法，用于从非结构化医疗文档中获取见解

使用它们构建什么：健康分析解决方案、临床决策支持系统、精准医疗工具。

阅读主要文章 Health Data APIs

Amazon、Google 和 Microsoft等科技巨头也努力通过推出强大的 API 来摄取和分析不同格式的医疗数据，从而扩大其在数字医疗保健领域的影响力。

公共卫生内容 API：从 WHO、HHS、FDA 和其他机构获取调查和统计数据

暴露的数据： 关于疾病、健康风险和保持健康方法的循证内容

用它们构建什么：网站、门户和扩展，以教育患者和医生、患者参与解决方案。

阅读主要文章 Health Data APIs

公共卫生信息 API 处理建议、统计数据、调查和其他有价值的数据，这些数据由医学专家系统地审查。

免费的药物数据、药物数据库和交互检查器 API：获取有关药物的可靠信息

数据公开： 有关药物、其副作用和药物相互作用的详细信息

用它们构建什么：药房管理系统、电子处方和 EHR 系统的临床决策支持模块、计算机化医嘱输入 （CPOE） 系统、患者门户、处方依从性应用程序。

阅读主要文章 Medicine and Drug Data APIs和 Drug Interaction Checker APIs

药物数据在哪里积累，可信度如何？要回答这些问题，我们必须追踪医药信息的旅程，从制药商到医疗专业人员、普通消费者和卫生系统。

注册。 药品制造商、重新包装商或重新贴标商必须向美国食品药品监督管理局 （FDA） 注册新药商品。为此，制药公司以结构化商品贴标 （SPL） 格式提交注册和上市信息。

获得 NDC。根据提交的内容，商品将获得唯一的 10 位或 11 位国家药品代码 （NDC）。它由贴标机代码、产品代码和包装代码组成。FDA 在 NDC 目录中发布所有列出的标识符，该目录每天更新。但分配 NDC 代码并不意味着该药物已获得 FDA 批准。

NDC 格式示例。来源：NDC 列表

DailyMed 出版物。 FDA 将在美国销售的药物信息发送到其官方网站 DailyMed，该网站由美国国家医学图书馆 （NLM） 于 2005 年推出。通过 DailyMed，卫生系统、医生和普通用户可以公开获得有关处方药及其副作用的可靠数据。

将 NDC 代码与 RxNorm 名称连接。 除了 DailyMed，NLM 还维护和更新 RxNorm 临床药物词汇表。与 NDC 相比，RxNorm 概念唯一标识符 （RxCUI） 与药物成分、强度和剂型相关联。例如，盐酸西替利嗪 5 MG 口服片剂具有单个 RxCUI （1014676），但与 25 个 NDC 代码相关联，分别对应于不同的标签和包装规格。

RxNorm 旨在促进互操作性，是卫生系统之间数据交换的首选标准。

因此，关键药物数据 API 以某种方式与上述组织之一相关并支持 SPL、NDC 和/或 RxNorm 标准也就不足为奇了。

所有参与药品数据标准化和推广的主要联邦参与者都拥有免费的公共 API，旨在提高开放性和教育消费者。

反过来，商业技术提供商使用广泛的数据源，从上述公共数据集到研究数据库和医学期刊。通常，此类服务还提供药物相互作用检查功能。

openFDA APIs

通过 API 进行药物相互作用检查。

openFDA API 是一个开源平台，可以访问有关动物和人类药物、医疗设备、食品、烟草等的数据。至于人类药物，该平台涵盖

• 不良事件和医疗差错报告
• SPL 格式的药物标签
• NDC 编号，其中包含在美国销售的药物的相关信息
• 有关药物召回或某些药物从市场上撤出的事件的数据

所有 API 都以 JSON 格式返回响应。值得注意的是，并非 openFDA API 提供的所有信息都经过临床或生产用途的验证。

第一个 DataBank Cloud 连接器 API

First DataBank （FDB） 维护着广泛使用的药物数据库，称为 MedKnowledge。它包含

• 药物图像
• 剂量和订购数据
• 定价信息
• 药物-药物、药物-食物和药物-过敏相互作用
• 其他细节

第三方开发人员可以使用 FDB Cloud Connector API 将数据库连接到现有的卫生系统

IBM Micromedex API

IBM Micromedex 是最大的药物信息在线数据库之一。它为不同的目标群体提供了两个基于 JSON 的 API 选项。Summary Drug API 使护士、保险公司和患者能够获得有关药物的一般问题的答案。In-Depth Drug API 适用于需要有关复杂护理详细信息的医疗专业人员。

症状检查器 API：改进诊断和分类工作流程

暴露的数据： 可能的病症、护理建议

用它们构建什么：诊断前决策支持工具、呼叫中心和急诊科护理的分诊解决方案、健康聊天机器人和自我诊断患者应用程序。

阅读主要文章 Symptom Checker APIs

本模块的目标是告知患者病情的可能原因，并帮助医生在诊断前阶段做出更好的决策。

症状检查器 API 的工作原理。

典型的症状检查器结合了

• 包含疾病和治疗程序数据的知识库
• 一个诊断引擎，用于根据患者输入生成可能的情况和建议的列表

以下是高级症状检查器 API 的几个示例。

远程医疗 API：嵌入远程护理功能

功能和公开的数据： 医疗文件操作、预约管理、患者记录、安全视频访问。

使用它们构建什么：远程医疗系统、调度工具、用于远程护理的医生和患者应用程序。

阅读主要文章： Telehealth APIs

在谈到远程护理服务时，远程医疗和远程医疗是两个经常互换使用的术语。这包括但不限于患者数据交换、远程访问、预约安排和实验室测试订购。让我们看看一些在设计时考虑了远程医疗的 API。

远程医疗软件的 API。

截止日期和疫情加速了 API 的采用

目前，医疗保健在 API 使用方面仍然落后于其他行业。专家列举的主要障碍包括

• 缺乏双向数据交换。目前，患者对其健康记录具有只读访问权限，无法通过 FHIR API 进行任何更改
• 对 API 实施过程的混淆
• 与通过 API 使用 Web 服务相关的隐藏成本
• 容易受到网络攻击

客户通常使用金融或travel APIs来一键访问其个人数据并更改服务提供商。医疗保健何时会看到这种级别的 API 采用？没有人知道，但 2022 年即将到来的互操作性截止日期和 COVID-19 带来的挑战显然正在将这一日期拉近。

医疗API使用场景有哪些？

1. 智能化诊疗：AI大模型通过分析海量医疗数据，辅助医生进行更准确的诊断。例如，百度灵医大模型利用其数据处理能力，在医疗机构中提升诊断的准确性和效率。
2. 个性化治疗：AI大模型能够对患者进行精准画像，制定个性化治疗方案，实现千人千面的患者管理策略。例如，圆心科技的源泉大模型通过用户标签管理，提供定制化疾病科普和药品服务。
3. 药物研发：AI大模型在药物研发领域加速候选药物筛选，优化临床试验设计。晶泰科技的XpeedPlay平台利用大模型技术超高速生成苗头抗体，加速药物研发流程。
4. 医学影像分析：AI大模型通过深度学习技术自动识别医学影像中的病变区域，提升医疗服务效率。北京天坛医院联合北京理工大学团队合作推出的“龙影”大模型（RadGPT）能够快速生成多种疾病的诊断意见。
5. 医疗质控：AI大模型能够生成规范的医疗文书模板，快速检测文书和影像的缺陷，提高医疗质量和效率。惠每科技推出的医疗大模型在病历质控场景中应用，模拟人工专家分析病历文书中的内涵缺陷。
6. 患者服务：AI大模型为患者提供智能导诊、症状自查、就医指导等服务，改善患者体验。百度文心大模型与灵医大模型支撑的AI药品说明书，支持患者阅读药品说明，并通过文字、语音的方式进行提问。
7. 远程医疗：医疗API支持远程医疗服务，如患者数据交换、远程访问、预约安排和实验室测试订购。例如，DrChrono API允许用户在DrChrono EHR系统上安排预约、交换患者病历数据。
8. 临床数据管理和分析：科技巨头如亚马逊、谷歌和微软推出的API，帮助医疗机构使用分析、NLP和机器学习的力量来管理数据和提取见解。例如，Amazon Comprehend Medical API从临床文档中提取临床信息，并将其与医疗编码系统中的相应实体连接起来。

医疗API常见问题有哪些？

1. 问：什么是医疗服务API？
   答：医疗服务API（Application Programming Interface，应用程序接口）是一组预定义的函数、协议和工具，允许软件开发者在不同的软件应用程序之间进行交互，特别是在医疗健康领域。这些API可以提供对医疗数据的访问、处理医疗信息、集成医疗服务和功能，如电子健康记录（EHR）、预约调度、在线问诊、药物信息查询等。
2. 问：医疗服务API有哪些用途？
   答：医疗服务API的用途包括患者资料管理、预约挂号、在线咨询服务、药物信息查询、电子健康记录集成、辅助疾病诊断、健康数据分析、医疗设备集成、保险理赔处理以及公共卫生监控等。
3. 问：如何使用医疗服务API？
   答：使用医疗服务API通常需要以下步骤：注册开发者账号、获取API密钥、根据API文档构建请求、发送请求并处理返回的数据。API请求通常通过HTTP协议发送，返回的数据格式可能是JSON或XML。
4. 问：医疗服务API是否需要付费？
   答：不同的医疗服务API提供商可能有不同的定价策略。有些API是完全免费的，而有些可能需要付费。具体是否需要付费，需要查看API提供商的服务条款或联系客服咨询。
5. 问：医疗服务API的数据更新频率是多久一次？
   答：医疗服务API的数据更新频率取决于API提供商。一些API可能实时更新，而另一些则可能每天、每周或每月更新。为了确保数据的准确性，建议查看API提供商的文档或联系他们获取具体信息。
6. 问：医疗服务API是否提供技术支持？
   答：大多数医疗服务API提供商会提供一定程度的技术支持。这可能包括在线文档、FAQ、电子邮件支持或电话支持。具体的支持服务和联系方式通常可以在提供商的官方网站上找到。
7. 问：医疗服务API的安全性如何？
   答：医疗服务API处理的数据通常涉及敏感的健康信息，因此安全性非常重要。API提供商通常会采取加密、认证和其他安全措施来保护数据的安全。使用API时，应确保遵循最佳安全实践，如使用HTTPS、保护API密钥等。
8. 问：医疗服务API是否支持多种编程语言？
   答：是的，大多数医疗服务API都支持多种编程语言，因为它们通常基于标准的HTTP协议。开发者可以使用Java、Python、JavaScript等语言来调用API。
9. 问：如何确保医疗服务API的合规性？
   答：确保医疗服务API的合规性需要遵循相关的法律法规，如HIPAA（健康保险流通与责任法案）或GDPR（通用数据保护条例）。这可能包括确保数据的隐私和安全、获取患者的同意以及遵守数据存储和传输的规定。
10. 问：医疗服务API在智慧医疗中扮演什么角色？
    答：医疗服务API在智慧医疗中扮演着至关重要的角色，它们使得医疗信息的共享、管理和应用更加高效和便捷。通过API，可以实现医疗服务的智能化、便捷化，提升患者就医体验，并推动医疗技术的创新和发展。

原文链接：https://www.altexsoft.com/blog/healthcare-api-overview/