SMART在FHIR上

Azure Health Data Services（AHDS）FHIR服务通过实现SMART客户端使用OAuth 2.0和OpenID Connect安全访问FHIR数据所需的关键服务器端行为，支持可替代医疗应用和可重用技术（SMART on FHIR）。 SMART on FHIR是一个实施指南，应用程序可以通过数据存储访问临床信息。 它将基于开放标准（包括 OAuth2 和 OpenID Connect）的安全层添加到 FHIR® 接口，以实现与 EHR 系统的集成。 使用 SMART on FHIR 至少有下面三个重要好处：

• 应用程序有已知的方法来获取 FHIR 存储库的认证和授权。
• 使用 SMART on FHIR 访问 FHIR 存储库的用户只能访问与该用户关联的资源，而不是有权访问存储库中的所有数据。
• 用户可按照 SMART 临床范围仅限应用程序访问其有限的一组数据。

Prerequisites

在开始之前，请确保具备：

1. AHDS FHIR 服务的一个实例。
2. 用于配置 FHIR 身份验证设置的权限。
3. 身份提供者策略：Microsoft Entra ID 结合编排层，或兼容 SMART 标准的第三方身份提供者。
4. 您的 FHIR 存储库中的一名测试患者。
5. 一个SMART客户端应用程序（或用于验证的SmartLauncher示例）。

端到端流程

SMART客户端通常执行以下步骤：

1. 发现：在 FHIR 服务器上调用 /.well-known/smart-configuration 以查找端点和功能。
2. 授权：将用户重定向到授权终结点，并携带请求的 SMART 作用域。
3. 令牌：将授权码换取为访问令牌，然后使用 Bearer 令牌调用 FHIR API。
4. 调用FHIR API：将承载令牌发送到FHIR端点。 访问受限于范围和上下文。

为终端用户配置访问权限

根据以下 Azure 角色分配指南，将用户分配到 FHIR SMART 用户角色：将用户分配到角色。 当请求满足 SMART 要求时，具有此角色的用户可以访问 FHIR 服务。

注意

单靠SMART用户角色本身并不授予访问数据的权限。 每个请求还会受到 fhirUser 上下文和访问令牌中的 SMART 临床作用域的进一步限制。 参见 SMART 用户角色功能。

SMART 用户角色权限

SMART 用户角色支持查看和搜索操作。 访问令牌中的作用域决定请求可访问哪些资源类型，而 fhirUser 声明则决定可访问的是谁的数据。

支持的 FHIR 交互

SMART v2 动词	等同于 SMART v1	允许的交互
r （阅读）	read	按 ID 读取资源（GET [type]/[id]）。
s （搜索）	read	搜索（GET [type]?[params]），以及 $export 适用系统范围的区域。

注意

在 SMART v2 中，r 仅授予按 ID 读取权限。 需要搜索的客户端还必须请求 s。 比如， patient/Observation.r 无法进行搜索。 改用 patient/Observation.rs。

SMART用户角色无法参与的交互

以下交互和操作对仅拥有此角色的用户不可用，即使令牌中的作用域授予了相应的底层交互权限。

交互或操作	Reason
$export 具有 patient/ 或 user/ 作用域，或具有搜索参数约束的作用域	$export 需要不受搜索参数约束的 system/ 作用域。
$member-match	当启用SMART会员匹配限制时，SMART用户无法使用。 系统将请求视为未授权而拒绝。
_include、_revinclude、链式搜索（例如，subject.name），以及到达未涵盖资源类型的反向链式搜索（_has）	当系统返回的资源类型不在令牌中的作用域覆盖时，系统会拒绝搜索。
创建、更新、修补或删除资源（POST， PUT， PATCHDELETE， ）	不支持写作互动。

重要说明

担任FHIR SMART用户角色且提供无SMART临床范围令牌的负责人完全无法访问任何数据，包括读取。

身份提供商支持

FHIR 服务提供与 Microsoft Entra ID 或第三方身份提供程序 (IDP) 的集成，前提是第三方身份提供程序能够理解 SMART 启动上下文和 SMART 作用域语义。

SMART在FHIR规范中将启动上下文定义为一组参数，这些参数在授权流程中传递，并作为令牌响应的一部分返回。 这些参数通常包括识别码，如患者ID、遭遇ID，以及FHIR用户（例如，执业者或患者），以及可选字段。 技术上，这个上下文通过一个称为 launch的参数传递到 SMART 工作流程中，该参数对应用程序有意不透明。 应用程序在授权过程中接收并转发该值。 该 launch 参数映射到存储的上下文记录，其中包含实际的患者和就诊标识符。 在令牌交换步骤中，该上下文会被解析并与访问令牌一同返回，以便应用程序能够正确地进行作用域的 API 调用。 该机制确保应用访问FHIR数据时，运行在明确定义的临床边界内。

身份提供者负责身份验证和发放令牌，但他们无法了解临床工作流程。 应用程序必须确定合适的患者上下文，无论是提示用户、从列表中选择患者，还是从其他系统获取。 无论如何建立该上下文，应用程序都必须将其包含在调用FHIR服务的令牌中。

该架构提供了一个编排层，作为身份提供者、临床系统（如电子健康记录）和FHIR服务之间的桥梁。

示例集成

使用Azure Health Data and AI Samples 开源代码库来设置 SMART on FHIR 体验。 该仓库提供了示例 SMART on FHIR v2——与 IdP 无关的原生示例。

本样本展示了构建一个编排层，作为身份提供者、临床系统（如电子健康记录）和FHIR服务之间的桥梁。 它支持Microsoft Entra ID或外部身份提供者（例如Okta）。 请参阅样本库，了解如何配置和运行样本的详细说明。

注意

示例代码为开源代码，使用前应在GitHub上查看信息和许可条款。 它们不属于 Azure 健康数据服务，Microsoft 支持部门 也不支持。 这些示例展示了如何使用 Azure Health Data Services（AHDS）与其他开源工具结合使用，以 Microsoft Entra ID 作为身份提供者工作流程，演示 §170.315（g）（10） 标准化 API 以符合患者和人群服务标准。

Microsoft Entra ID 集成

Microsoft Entra ID 是一个功能齐全的 OAuth 2.0 和 OpenID Connect 身份提供者。 要将 Microsoft Entra ID 用作身份提供程序，您需要一些额外组件来完成端到端的 SMART on FHIR 体验。 这一要求存在是因为 FHIR 上的 SMART 引入了企业身份提供商如 Entra ID 原生不支持的行为。 为了弥合这一差距，Microsoft提供了参考解决方案（样本）。 该示例提供了SMART客户端与Entra ID之间的编排层。

该示例支持以下 Microsoft Entra ID 场景：

1. 像 的patient/Patient.rs范围值不是注册的 Entra ID 权限，所以 Entra ID 拒绝授权请求。
2. 它不为 SMART 资源动词提供针对每个请求的作用域选择器。 Entra的同意界面反映的是预注册的应用权限，而不是SMART应用每次启动时发送的动态 patient/<Resource>.<verbs> 权限。
3. 它并没有宣传SMART发现文档——智能配置是FHIR服务器的领域，不是IDP的领域。

SMART on FHIR v1/v2 支持

AHDS FHIR 服务支持 SMART v1.0.0 和 SMART v2.0.0。 你不能在同一个客户端应用注册中同时混用 SMART v1.0.0 和 SMART v2.0.0 的范围。 你必须二选一。

后续步骤

现在你已经了解如何在FHIR功能上启用SMART，请查看搜索示例页面，了解如何使用搜索参数、修饰符及其他FHIR搜索方法进行搜索。

FHIR 搜索示例

注意

FHIR® 是 HL7 的注册商标，经 HL7 许可使用。