主要医疗API：类型、提供商和用例

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

但现实看起来却大不相同。来自美国 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 数据资源

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

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

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

USCDI 标准

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

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

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

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

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 访问的 FHIR 元素。

Apple Health Records API

Apple 的 Health Records API 与 500 多个健康系统集成，并将数据整合到一个文档中，以便在 iOS 设备上显示。它使用 OAuth 2.0 协议进行身份验证，并定期从患者的 EHR 中提取新记录，并通知用户更新。

传输中的数据是加密的，不会通过 Apple 的网络。在休息时，内容受患者的 iPhone 密码、Touch ID 或 Face ID 保护。

Human APIs

Human Clinical API 连接到美国各地的实验室、EHR 系统、药房和患者门户，覆盖超过 2.64 亿患者。单独的可穿戴 API 从近 300 个健康设备中提取数据。他们一起从 40,000 多个来源提取信息，并在 AI 算法的帮助下将其转换为与 FHIR 兼容的格式。

Particle Health API

Particle Health API 通过单个入口点提供对来自大多数 EHR 系统的超过 3 亿条患者记录的访问。它还与美国的大多数药房和实验室预先集成。独立的数据转换 API 通过提取 USCDI 元素将传统临床数据集转换为 FHIR 文件。

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

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

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

阅读主要文章 Health Data APIs

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

Amazon Comprehend Medical APIs

Amazon Comprehend Medical API 连接到 NLP 引擎，该引擎会自动从各种类型的临床文档（例如 EHR、医生笔记或试验报告）中提取有意义的组件。然后将这些组件与医疗编码系统中的相应实体连接起来。除此之外，Amazon API 还提供识别和删除受保护健康信息（PHI）的服务。

Google Cloud Healthcare API

Google 的Cloud Healthcare API 支持所有主要的医疗保健标准，并允许对数据进行广泛的操作。这包括

从各种来源导入数据，从 EHR 到可穿戴设备
将数据转换为 FHIR 格式
去除 PHI
以 DICOM（医学数字成像和通信）格式存储、管理和分析文件
将各种格式的数据合并到一个文档中
更多

与 Amazon 类似，Google 通过独立的 NLP API 提供自然语言处理功能。

适用于 FHIR 的 Microsoft Azure API

Microsoft Azure API for FHIR 可帮助卫生系统将其存储在不同存储库中的旧文档移动到云存储。它负责受保护的健康信息，并使用 FHIR 标准规范化医疗数据。此外，Microsoft 还有一个特殊的 IoT 连接器，用于从医疗设备中提取生物识别信息、对其进行分析并构建 IoMT 系统。

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

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

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

阅读主要文章 Health Data APIs

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

ODPHP MyHealthfinder Content API

MyHealthfinder Content API 可以轻松地与医院网站集成，根据年龄、性别和习惯为患者提供健康提示。由疾病预防和健康促进办公室（ODPHP）监督的建议至少每两年审查一次。API 适用于 JSON 和 XML 文件。

WHO data API

Athena API 由世界卫生组织构建，用于将第三方应用程序与全球数据门户 — 全球健康观察站（GHO）集成。它按国家/地区收集统计数据，涵盖从儿童营养到免疫接种再到特定疾病的广泛主题。默认情况下，API 以 XML 格式检索数据，但也对 JSON 提供基本支持。

HHS Content Syndication APIs

美国卫生与公众服务部（HHS）的Content Syndication APIs 整合了来自 HHS 合作伙伴（例如美国食品和药物管理局（FDA）或美国国家癌症研究所（NCI））的新闻、文章、调查和其他内容。数据以 JSON 和 XML 格式返回，以显示在网站、社交媒体页面、移动应用程序等上。

免费的药物数据、药物数据库和交互检查器 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，旨在提高开放性和教育消费者。

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

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

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

openFDA APIs

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

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

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

DailyMed RESTful API

DailyMed RESTful API 检索 SPL 信息，包括

NDC 代码
产品级 RxCUI 代码
代码打包描述
药物名称
药物类

该服务支持 XML 和 JSON 格式。

RxNorm API

RxNorm API 从美国国家医学图书馆（NLM）、美国国立卫生研究院（NIH）和卫生与公众服务部的公开来源中提取 JSON 和 XML 格式的信息。除了当前的 RxNorm 词汇外，该平台还连接到药物相互作用数据集。

DrugBank API

DrugBank 是一个制药知识库，销售一套支持 JSON、XML 和 SQL 格式的独立集成就绪 API。该解决方案允许通过 NDC 编号、RxNorm 代码和其他标识符搜索超过 100,000 种药物。其药物相互作用数据库列出了超过 140 万次相互作用，并且每天更新。

第一个 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 的几个示例。

Infermedica API

Infermedica API 是一个AI 诊断引擎，具有 NLP 功能，可捕获患者消息中的症状和风险因素。其知识库涵盖 1,500 种症状和 800 种病症。该解决方案的准确率为达到93%。API 不要求提供个人信息，以符合 HIPAA 的规定。

Mayo Clinic API

Mayo Clinic symptom triage API 还使用 AI 算法将知识库中的数据与实时患者输入连接起来。它确定了 300 多种常见症状，并返回可操作的指导，以节省不必要的护理成本。API 支持 JSON 和 XML 格式。

Isabel Healthcare API

Isabel Symptom Checker API 涵盖 10,000 多种疾病，并承诺 96% 的准确率。作为回应，它整合了一份可能的诊断清单，并说明了患者的年龄、性别甚至居住地。该模块预先集成了许多流行的 EHR 系统，包括 Cerner 和 Epic。它支持 XML 和 JSON 格式。

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

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

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

阅读主要文章： Telehealth APIs

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

API 和远程医疗