你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
发行说明 2024：Azure Health Data Services
本文介绍 2024 年针对 Azure Health Data Services 中 FHIR® 服务、DICOM® 服务和 MedTech 服务发布的功能、增强功能和 bug 修复。
2024 年 11 月
Azure 健康状况数据服务
导入操作的改进
- 错误日志记录增强功能：在导入操作期间，错误日志现在报告在引入 FHIR 服务期间失败的特定文件。 此改进提供有关失败导入的更详细的反馈。
- 导入作业取消：标识了取消导入作业时未触发关联子作业取消的 bug。 此问题已解决，现在取消导入作业也会取消当前业务流程协调程序中的所有相关子作业。
- 导出验证改进：尽管搜索参数无效，但发现导出继续进行的问题。 实施更改以防止在这些条件下导出。 这是默认行为，但客户可以使用宽大标志替代它。 此更改上个月传达给客户。
- 捆绑性能增强：捆绑包执行期间的配置文件刷新过程已简化。 如果捆绑包包含对
ValueSetStructureDefinition/> 和/或 CodeSystem的更改，则在捆绑包完全完成之前不会进行配置文件刷新。 更改通过减少处理这些资源类型的更改时多次刷新导致的延迟来提高捆绑包的性能。 - 内容类型标头分析：已解决并解决与分析
application/x-www-form-urlencoded内容类型标头相关的问题。 - 重新编制索引增强功能：通过删除以前限制处理大型历史数据集或客户请求有限查询大小的人为限制来改进重新编制索引操作。 此外，在处理具有默认查询大小的许多连续历史或删除资源时，重新编制索引过程将错误地报告为“已完成”。 此问题已得到解决，以确保重新编制索引过程正确完成并报告相应的状态。
2024 年 10 月
Azure 健康状况数据服务
FHIR 服务
Bug 修复
- 导出验证：尽管搜索参数无效，但已确定导出继续进行的问题。 我们正在引入一项更改，防止在这些条件下导出。 此功能目前落后于严格的验证标志，并将成为 10 月 30 日或之后的默认行为。
- 搜索参数包含：我们解决了其他搜索参数（例如，
_include）_has未返回所有预期结果的问题，有时省略下一个链接。 - 导出作业执行：通过防止过早退出来解决导出作业完成期间很少出现
System.ObjectDisposedException的情况。 - HTTP 状态代码更新：作业创建期间
$reindex无效参数的 HTTP 状态代码现已更新为 400，确保更好地处理错误。 - 搜索参数清理：已实施修复，以确保在通过删除 API 调用触发时，在数据库中完成搜索参数的清理，解决与不完整删除相关的问题。
- 降序排序问题：解决了以下问题：如果已排序的字段没有数据库中的数据，即使相关资源存在，降序排序操作也不会返回任何资源。
- 身份验证失败处理：添加了一个新的 catch 块，用于管理导入请求时禁用托管标识时发生的身份验证失败。
2024 年 9 月
Azure 健康状况数据服务
FHIR 服务
增强的导出效率
改进了导出功能以优化内存使用情况。 通过此更改，导出过程现在一次将数据推送到 Blob 存储，从而减少内存消耗。
2024 年 8 月
Azure 健康状况数据服务
FHIR 服务
导入操作错误处理
- 当通过导入过程引入搜索参数资源时，导入操作将返回 HTTP 400 错误。 此更改旨在防止使用导入操作引入时搜索参数处于被置于无效状态。
- 如果存储帐户出现配置问题，导入操作将返回 HTTP 400 状态代码，而不是以前的 HTTP 500 状态代码。 此更新旨在改进导入操作期间与托管标识关联的错误处理。
2024 年 7 月
Azure 健康状况数据服务
FHIR 服务
允许在转换数据操作中将 JSON 数据中的日期视为字符串
JSON 数据中提供的日期可能以与所提供的格式不同的格式返回。 在对标识为日期的 JSON 有效负载字符串进行反序列化期间，这些字符串将转换为 .NET DateTime 对象。 然后，这些对象在通过 Liquid 模板引擎之前被转换回字符串。 此转换可能会导致日期值重新格式化，并在 FHIR 服务的本地时区中表示。
可以使用布尔参数 jsonDeserializationTreatDatesAsStrings禁用字符串到 .NET DateTime 对象的强制。 设置为
导入操作增强功能
FHIR 服务现在允许引入数据，而无需在资源级别指定版本。 使用 lastUpdated 值维护资源的顺序。 此增强功能引入了“allowNegativeVersions”标志。 设置标志 true 允许 FHIR 服务为具有显式 lastUpdated 值且未指定版本的资源记录分配负版本。
缺陷修复
- 修复了在使用 _security：not search 参数 时，在搜索操作中使用 _security：not search 参数时，软删除资源的 ID 包含在搜索结果中。 我们修复了此问题，以便软删除的资源现在已从搜索结果中排除。
- 将数据导出为 SMART 用户以 SMART 用户 身份导出数据不再需要写入范围。 以前，有必要向 SMART 用户授予“写入”权限，以导出数据，这意味着更高的特权级别。 若要以 SMART 用户身份启动导出作业，请确保该用户是 RBAC 中的 FHIR 导出角色的成员，并请求“读取”SMART 临床范围。 将状态代码从 HTTP 500 更新到 HTTP 400
- 如果在修补操作期间将状态代码从 HTTP 500 更新到 HTTP 400 ，如果有效负载请求更新了参数以外的资源类型，则最初引发了内部服务器错误（HTTP 500）。 这已更新为改为引发 HTTP 400 错误。
性能增强
使用数据范围搜索 FHIR 资源时，会添加查询优化。 此查询优化有助于高效查询，因为生成了一个组合的 CTE。
2024 年 5 月
Azure 健康状况数据服务
FHIR 服务
对导入操作的缩放增强功能
改进了导入操作的缩放逻辑，使多个作业能够并行执行。 此更改会影响导入操作的审核日志。 单个导入作业的审核日志具有多个行，每一行对应于内部处理作业。
Bug 修复
- 已修复：长时间运行的请求的 HTTP 状态代码。 执行时间超过 100 秒的 FHIR 请求返回 HTTP 408 状态代码，而不是 HTTP 500。
- 已修复：捆绑包中的历史记录请求。 在修复之前，捆绑包中的历史记录请求返回 HTTP 状态代码 404。
独立 FHIR 转换器（预览版）
可用于预览的独立 FHIR 转换器 API 与 FHIR 服务分离，并打包为容器（Docker）映像。 除了使你能够将数据从记录源转换为 FHIR R4 捆绑包之外，FHIR 转换器还提供：
- 从记录源到 FHIR R4 捆绑包的双向数据转换。 例如，FHIR 转换器可以将数据从 FHIR R4 格式转换回 HL7v2 格式。
- 改进了自定义 默认 Liquid 模板的体验。
- 演示如何使用 Azure 数据工厂 （ADF） 创建 ETL（提取、转换、加载）管道的示例。
若要实现 FHIR 转换器容器映像，请参阅 FHIR 转换器 GitHub 项目。
2024 年 4 月
DICOM 服务
增强的 Upsert 操作
增强的 Upsert 操作使你可以将 DICOM 映像上传到服务器，并无缝替换它（如果它已存在）。 在此增强功能之前，用户必须执行 Delete 操作，然后执行 STOW-RS 来实现相同的结果。 通过增强的 Upsert 操作，管理 DICOM 映像的效率更高且简化。
所需属性的扩展存储
DICOM 服务允许用户上传大小高达 4 GB 的 DICOM 文件。 单个请求中不允许单个 DICOM 文件或文件组合超过此限制。
FHIR 服务
批量删除操作已正式发布
批量删除操作允许跨不同级别删除 FHIR 资源，使医疗保健组织能够遵守数据保留策略，同时提供异步处理功能。 批量删除操作的优点包括：
- 在不同级别执行批量删除：批量删除操作允许异步从 FHIR 服务器中删除资源。 可以在不同级别执行批量删除：
- 系统级别：允许在所有资源类型中删除 FHIR 资源。
- 单个资源类型：允许删除特定的 FHIR 资源。
- 可自定义：查询参数允许筛选目标删除的原始资源。
- 异步处理：操作是异步的，提供用于跟踪进度的轮询终结点。
了解详细信息：
2024 年 3 月
DICOM 服务
与 Azure Data Lake Storage 的集成已正式发布
Azure Health Data Services 中 DICOM 服务的 Azure Data Lake Storage 集成已正式发布。 DICOM 服务使用 DICOMweb 标准为医疗成像数据提供云规模存储。 借助 Azure Data Lake Storage 的集成，组织可以完全控制其映像数据，并增强通过 Azure 存储生态系统和 API 访问和处理这些数据的灵活性。
通过将 Azure Data Lake Storage 与 DICOM 服务配合使用，组织能够：
- 使用 Azure 存储 API 和 DICOMweb API 实现对 DICOM 服务存储的医疗成像数据的直接访问，从而提供访问和使用数据的灵活性。
- 打开整个医疗成像数据生态系统，以便使用 Azure 存储，包括 AzCopy、Azure 存储 资源管理器和数据移动库。
- 通过使用与 Azure Data Lake Storage 本机集成的服务（包括 Azure Synapse、Azure Databricks、Azure 机器学习 和 Microsoft Fabric）来解锁新的分析和 AI/ML 方案。
- 授予控制来管理存储权限、访问控制、层和规则。
了解详细信息：
FHIR 服务
捆绑并行化 （GA）
默认情况下，捆绑包在 FHIR 服务中串行执行。 为了提高捆绑调用的吞吐量，我们启用了并行处理。
了解详细信息：
导入操作接受单个文件中的多个资源类型
允许在请求参数中使用每个输入文件的资源类型导入操作。 借助此功能，可以在单个文件中传递多个资源类型。
Bug 修复
已修复：导入操作引入具有相同资源类型和 lastUpdated 字段值的资源。 在此更改之前，在批处理中执行的资源的类型相同，
lastUpdated字段值未引入到 FHIR 服务中。 此 bug 修复解决了该问题。 请参阅 PR#3768。已修复：具有 3 个或多个自定义搜索参数的 FHIR 搜索。 在修复之前，根目录中具有三个或多个自定义搜索参数的 FHIR 搜索查询导致 HTTP 状态代码 504。 请参阅 PR#3701。
已修复：提高捆绑处理的性能。 对任务执行方法的更新，可实现捆绑包处理性能改进。 请参阅 PR#3727。
2024 年 2 月
FHIR 服务
启用所有版本的资源计数
查询参数 _summary=count ， _count=0 可添加到 _history 终结点以获取所有版本控制资源的计数。 此计数包括历史删除和软删除的资源。
Revinclude 搜索可以使用通配符引用所有资源
FHIR 服务支持使用 revinclude通配符搜索。 添加到 *.* 查询中的 revinclude 查询参数，以指示 FHIR 服务引用映射到源资源的所有资源。
Bug 修复
已修复：通过性能增强改进改进 FHIR 查询响应时间。 为了提高性能，可以为用于排序的搜索参数指定缺少的修饰符。 请参阅 PR#3655。
已修复：导入操作遵循非顺序资源版本的引入。 在此更改之前，操作中的
import增量模式假定版本是顺序整数。 修复此 bug 后，版本可以按非查询顺序引入。 请参阅 PR#3685。
2024 年 1 月
DICOM 服务
批量更新文件
批量更新操作允许更改 DICOM 服务中存储的多个文件的映像元数据。 例如，通过批量更新，可以在单个异步操作中修改一个或多个研究的 DICOM 属性。 可以使用 API 对患者人口统计信息执行更新，并避免重复上传耗时的成本。
除了效率提升之外，批量更新功能还保留更改源中的更改记录，并保留原始的未修改实例以供将来检索。
了解详细信息：
FHIR 服务
可选择的搜索参数（预览版）
可用于预览版的可选搜索参数功能可用于自定义和优化 FHIR 资源的搜索。 此功能允许你选择为 FHIR 服务启用或禁用哪些内置搜索参数。 通过仅启用所需的搜索参数，可以存储更多 FHIR 资源，并可能提高 FHIR 搜索查询的性能。
了解详细信息：
将 FHIR 服务与 Azure Active Directory B2C 集成
医疗保健组织可以将 Azure Health Data Services 中的 FHIR 服务与 Azure Active Directory B2C（Azure AD B2C）配合使用。 组织获得一种安全便捷的方式，可针对不同用户或组授予对 FHIR 服务的访问权限，而无需在其组织的 Microsoft Entra ID 租户中创建或传出用户帐户。 通过此集成，组织可以：
- 使用其他标识提供者通过 SMART on FHIR 范围进行身份验证和访问 FHIR 资源。
- 使用 SMART on FHIR 范围管理和自定义用户访问权限或权限，这些范围支持精细的访问控制、FHIR 资源类型和交互，以及用户的基础权限。
相关内容：
- 使用 Azure Active Directory B2C 授予对 FHIR 服务的访问权限
- 为 FHIR 服务配置多个服务标识提供者
- 排查 FHIR 服务的标识提供者配置问题
- 为 FHIR 服务启用 SMART on FHIR
- 示例：Azure ONC （g）（10） SMART on FHIR
请求高达 100 TB 的存储
FHIR 服务可以存储和交换大量运行状况数据，每个 FHIR 服务实例默认的存储限制为 4 TB。 如果有更多数据，可以要求 Microsoft 为 FHIR 服务增加多达 100 TB 的存储。
借助更多存储，组织可以处理大型数据集，以实现分析方案。 例如，可以使用更多存储来管理人口健康、进行研究，并从运行状况数据中获得新的见解。 此外，更多的存储使具有大容量数据的 Azure API for FHIR 客户（大于 4 TB）能够迁移到 Azure Health Data Services 中的 FHIR 服务。
若要请求大于 4 TB 的存储，请在Azure 门户创建支持请求，并使用问题类型服务和订阅限制（配额）。
注意
由于存储的计费指标出现问题，选择超过 4 TB 存储容量的客户在解决问题之前不会对存储计费。