Docs 菜单
Docs 主页
/
Atlas 架构中心
Docs 主页
/
Atlas 架构中心
Docs 主页
/
Atlas 架构中心

混合 FHIR 操作数据层

使用案例： 智能搜索

行业： 医疗保健

产品： MongoDB Atlas、 MongoDB Community Server Edition、 MongoDB Enterprise Advanced

合作伙伴： Tapdata

解决方案概述

该项目开发了适用于医疗保健的 FHIR 混合 ODL模式。主节点 (primary node in the replica set)目标是创建一个单一的高性能运营存储，为客户 Web 服务提供支持。此外，该设计还为作用域内的资源公开与 FHIR 兼容的 端点，因此可以使用 FHIR REST API而不是新的自定义服务来构建未来的功能。

ODL 的核心是使用MongoDB Atlas作为灵活且可扩展的数据库，以结构化的三区块格式存储 Patient 或 Encounter 等资源。这包括：

  • 存在映射时的规范 FHIR 表示形式。

  • 其他特定于应用程序的字段。

  • 预索引搜索字段针对查询性能进行了优化。

由于映射是 FHIR 优先定义的，因此与 FHIR 对齐的字段使用标准结构存储，而其余属性则保存在单独的应用程序区块中。这种混合结构保留了互操作性，而无需强制解决方案充当完整的 FHIR服务器。

后端使用 FastAPI 并公开两个 API 系列：

  • 应用程序API ：使用 ODL 作为共享后端，实现客户的操作端点，示例患者搜索、病例搜索或本地标识符服务。

  • FHIR API：重复使用相同的信封模型和索引，为定义的资源子集（例如 Patient和Encounter ）提供与 FHIR 兼容的搜索。它被设计为实用的 FHIR 门面，而不是完整的、配置文件驱动的 FHIR服务器。

前端使用 Next.js，其中包含交互式API演示器，因此团队可以同时尝试应用程序端点和 FHIR 式查询。

对于演示和开发，ODL 可以生成合成的临床数据集，从而允许在不暴露真实患者数据的情况下进行实际测试。

参考架构

该架构侧重于 FHIR 混合 ODL，这是一种数据模型方法，支持自定义操作访问权限模式和对同一数据集的 FHIR 兼容访问权限。这种方法不是复制数据，而是为操作查询的有价值信息建立索引并维护完整的 FHIR资源。

该使用案例源自现实世界的客户挑战，涉及一家运营多个 EHR 平台的大型医疗机构。每个系统独立提供患者访问权限服务，导致数据访问碎片化、逻辑重复且缺乏语义互操作性。

为了简化这一过程，该机构引入了 ODL 来集中临床数据访问并提供共享的 MDM 服务，而无需中断现有应用程序。

这种情况为我们提供了一个机会，可以通过采用 FHIR 作为通用语言来转向行业最佳实践，而不是从零开始重新定义数据结构和语义。通过将 ODL数据模型设计为 FHIR 优先，该组织避免了对患者和就诊等核心概念的“重复发明轮子”。它还与标准资源定义保持一致，使其成为该字段其他公司的潜在模型。

该参考架构展示了医疗保健公司如何使用MongoDB Atlas来统一不同的数据源、支持自定义流程以及提供高性能 API。该界面分为多个标签页，每个标签页显示架构的特定功能。

显示Atlas与 FHIR ODL 集成的参考架构

图 1。 FHIR 混合 ODL 参考架构

首先，映射部分显示传统医疗保健数据字段如何映射到 ODL数据模型，该模型是围绕以 FHIR 为中心的模式设计的。每个文档存储：

  • 规范 FHIR资源（当存在 FHIR 映射时）

  • 当前工作流程所需的特定于应用程序的字段

  • API 使用的搜索优化字段

用户可以在交互式表中浏览跨实体（例如 Patient 和 Encounter）的完整设立字段。这有助于他们了解哪些字段来自 FHIR 规范，哪些字段被建模为应用程序或搜索字段。这种映射策略可以更轻松地追踪数据沿袭并评估与标准的一致性。

显示Atlas与 FHIR ODL 集成的参考架构

图 2。混合 FHIR ODL 演示中的“映射”标签页

该平台包括一个内置生成器，可以为存储和检索测试创建合成临床数据，从而允许团队测试功能。用户可以自定义合成内容，包括患者数量、每位患者的就诊次数、医生和护理团队。

显示Atlas与 FHIR ODL 集成的参考架构

图 3：合成临床数据创建器

填充数据后，数据查看器部分允许用户探索存储在MongoDB中的 FHIR 资源。它将规范的 FHIR 内容和附加的 ODL 字段显示在一个位置，阐明标准数据和操作数据如何共存。

客户数API部分将传统医疗保健系统与平台集成。 API测试器允许用户调用特定于客户的 MDM 和操作端点。通过选择端点并输入所需参数，用户可以执行查询并查看自定义系统所期望的格式化响应。

最后，FHIR API测试器部分允许用户对根本的数据集执行 FHIR 标准搜索。结果显示MongoDB查询管道和 FHIR 响应。此视图重点介绍了平台如何维护符合 FHIR 标准的输出、提供性能见解并提供调试详细信息。

双API层（核心模式）

双API层是该架构的核心。该平台会公开以 FHIR 为中心的数据模型中的两种类型的端点：

  • 应用程序 API：与现有集成服务匹配的自定义端点。

  • FHIR API：对同一数据集进行 FHIR 式查询，实现基于标准的访问权限。

这两个 API 都包含一组设立义的示例查询，因此用户只需单击一下即可触发典型查询。

通过演练这些现成的场景，团队可以快速了解一种 ODL模式如何同时为传统兼容和 FHIR 兼容的 API提供服务，而无需额外的ETL 管道或单独的数据库。了解MongoDB合作TapData 如何在其平台中使用双API层模式。在此处了解详情。

数据模型方法

该架构围绕存储在MongoDB中的以 FHIR 为中心的 ODL模式构建。每条记录都保存为包含三个部分的单个文档，而不是将患者和遇到的数据分散在许多表中。 ODL 中的每个部分都有特定用途：

  • resource 用于规范 FHIR 内容：包含有效的R4 FHIR对象，例如 Patient或Encounter 。此区块可由 FHIR 样式端点直接返回，无需额外转换。

  • app 用于应用程序元数据：包含工作流所需的字段，但它们是基本 FHIR资源的一部分。它包括内部代码、分类标志或其他客户特定属性等字段。

  • search 用于非规范化查询表面：展平查询中最常用的属性，包括名称、关键日期、组织或位置引用等标识符。它还将关系键转换为易于索引和供API层使用的字段。

下面是 Encounter资源的带注释的JSON示例：

{
   "_id": "ObjectId",
   "tenant": "tenant-1",
   "resourceType": "Encounter",
   // 1 Canonical FHIR block
   "resource": {
      "resourceType": "Encounter",
      "id": "036fcfcd-797c-4ae2-a30f-49226357deb2",
      ...,
      "status": "onhold",
      "class": {
         "code": "EMER"
      },
      "serviceType": {
         ...
      },
      "period": {
         "start": "2025-10-31T17:43:00",
         "end": "2025-11-02T17:43:00"
      },
      "serviceProvider": {},
      "hospitalization": {},
      "participant": [],
      "location": [],
      "type": [
         { ... }
      ]
   },
   // 2 Application block
   "app": {
      "caseNum": "QH-1761928980-83",
      "doctorCode": "DR100",
      "specialistCode": "DR100",
      ...,
      "sourceIndicator": "SELF",
      "patientGroup": "G2"
   },
   // 3 Search block
   "search": {
      "start": "2025-10-31T17:43:00",
      "end": "2025-11-02T17:43:00",
      "local_id": "A108548(0)",
      ...,
      "caseNum": "QH-1761928980-83",
      "statusCode": "onhold",
      "caseType": "E"
   }
}

构建解决方案

README有关详细的设置说明，请按照此 GitHub存储库的 中概述的步骤进行操作。此存储库托管此演示的后端和前端。

要在自己的环境中重现此演示，请按照以下步骤操作：

1

在Atlas上或本地设置MongoDB

登录到MongoDB Atlas门户，为此项目创建一个名为 fhir_demo 的数据库和一个名为 fhir 的集合。

保存用于后续步骤的连接字符串，并将您的IP解决添加到访问权限列表中。

2

克隆Github存储库

在终端上使用以下命令将存储存储库到首选位置：

git clone https://github.com/mongodb-industry-solutions/hybrid-fhir-odl.git
cd hybrid-odl
3

配置环境变量

Go/backend目录并创建一个包含以下连接详细信息的 .env文件。使用在步骤 1 中保存的 MONGODB_URI连接字符串。

MONGODB_URI=mongodb+srv://<user>:<password>@<cluster-url>/?retryWrites=true&w=majority
MONGODB_DB=fhir_demo
MONGODB_COLLECTION=fhir
MONGODB_TENANT=tenant-1

然后，浏览到 /frontend目录并使用以下信息创建 .env文件：

NEXT_PUBLIC_ENABLE_FHIR = true
BACKEND_URL=http://localhost:3100
4

安装所需的依赖项

Gohybrid-odl目录并使用以下命令安装这两个服务的依赖项：

make install
5

使用生成文件部署这两项服务

打开两个单独的终端，并使用以下命令独立启动每项服务：

终端 1：后端

make backend

终端 2：前端

make frontend

完成这些步骤后，您将获得一个可用的混合 FHIR ODL 演示。您可以通过以下 URL访问权限资源：

关键要点

  • 实现传统医疗保健系统的现代化：该解决方案展示了医院如何在不放弃操作工作流程的情况下更新其临床数据基础架构。这种方法不需要机构维持其完全自定义的服务或完全切换到 FHIR，而是可以增量集成这些系统。数据仍然可作为 FHIR 资源使用，自定义应用程序端点和现有查询模式将继续通过应用程序API层运行。使用该解决方案的医院可以逐步实现基础设施的现代化，以自己的速度移动临床团队和合作系统。

  • 优化临床数据性能：这种方法允许 FHIR 数据在资源区块中保持不变，以实现标准合规，而应用程序信息则驻留在高使用率属性中，并进行索引以提高搜索性能。该系统适用于实时临床仪表盘、操作分析以及挂号、分流和床位管理期间的快速查找。

  • 加快互操作性并提高开发者工作效率：双API架构、内置合成数据生成和交互式API测试工具可帮助团队快速原型设计、验证和部署符合 FHIR 的解决方案，而无需中断现有的医院流程。

作者

  • Patricia Renart Carnicero， MongoDB

  • Francesc Mateu Amengual, MongoDB

了解详情

  • 利用 MongoDB 和 Microsoft 实现 AI 驱动的医疗保健

  • AI 驱动的零售：个性化和准确性

  • 适用于技术Docs的上下文感知 RAG

后退

AI 驱动的医疗保健

来年

AI 驱动式呼叫中心智能

在此页面上