使用案例: 智能搜索
行业: 医疗保健
产品: MongoDB Atlas,MongoDB Community 服务器版,MongoDB Enterprise Advanced
合作伙伴: Tapdata
解决方案概述
该项目为医疗保健场景开发 FHIR 混合 ODL 模式。其主要目标是创建一个为客户 Web 服务提供支持的单一高性能操作存储。此外,该设计公开了FHIR 兼容终结点,以便未来的功能可以使用 FHIR REST API 而不是新的自定义服务来构建。
ODL 的核心使用 MongoDB Atlas 作为灵活、可扩展的数据库,以三块结构化格式存储资源,例如 Patient 或 Encounter。这包括:
存在映射时的规范 FHIR 表示形式。
额外的应用程序专有字段。
针对查询性能优化的预索引搜索字段。
由于映射是以 FHIR 为先定义的,与 FHIR 对齐的字段使用标准结构存储,而其余属性保存在单独的应用程序块中。这种混合结构保留了互操作性,而无需强制解决方案充当完整的 FHIR 服务器。
后端使用 FastAPI 并公开了两个系列的 API:
应用程序 API:以 ODL 作为共享后端,实现客户的操作端点,例如患者搜索、病例搜索或本地标识符服务。
FHIR API:为已定义的资源子集(例如
Patient和Encounter)提供 FHIR 兼容的搜索,重用相同的信封模型和索引。它被设计为务实的 FHIR 门面层,而非完整的、基于 profile 的 FHIR 服务器。
前端使用 Next.js,其中包含交互式 API 演示工具,因此团队可以同时尝试应用程序终结点和 FHIR 式查询。
用于演示和开发,ODL 可以生成合成临床数据集,从而在不暴露真实患者数据的情况下进行更贴近真实的测试。
参考架构
该架构侧重于 FHIR Hybrid ODL,这是一种参考数据模型方法,支持自定义操作访问模式和对同一数据集进行 FHIR 兼容访问。这种方法不是复制数据,而是为运营查询索引关键字段,并维护完整的 FHIR 资源。
该用例源自真实客户难题:一家大型医疗机构运营多个 EHR 平台。每个系统独立提供患者访问服务,导致数据访问碎片化、逻辑重复以及语义互操作性缺失。
为了简化这一过程,该机构引入了 ODL,以集中管理临床数据访问并提供共享 MDM 服务,而不会中断现有应用程序。
这种情况创造了一个机会,可以通过采用 FHIR 作为公共语言向行业最佳实践转变,而不是从头开始重新定义数据结构和语义。通过将 ODL 数据模型设计为 FHIR 优先,该组织避免对“患者”和“就诊”等核心概念重复造轮子。它还与标准资源定义保持一致,使其成为业内其他组织可参考的潜在范式。
参考架构展示了医疗保健公司如何利用 MongoDB Atlas 统一不同的数据源、支持自定义流程并提供高性能 API。界面分为多个标签页,每个标签页显示架构的特定功能。
图 1. FHIR 混合 ODL 参考架构
首先,映射部分显示了旧版医疗保健数据字段如何映射到 ODL 数据模型中,该模型围绕以 FHIR 为中心的架构而设计。每个文档存储:
规范 FHIR 资源(当存在 FHIR 映射时)
当前工作流所需的应用程序特定字段
API 使用的搜索优化字段
用户可以在交互式表格中浏览 Patient 和 Encounter 等实体的完整字段映射。这有助于他们理解哪些字段来自 FHIR 规范,哪些字段是建模为应用程序或搜索字段。这种映射策略可以更轻松地跟踪数据沿袭和评估与标准的一致性。
图 2. 混合 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" } }
构建解决方案
有关详细设置说明,请按此 GitHub 存储库 中 README 列出的步骤操作。此存储库托管此演示的后端和前端。
要在自己的环境中重现此演示,请按照以下步骤操作:
配置环境变量
转到 /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
关键要点
现代化旧版医疗系统: 该解决方案展示了医院如何在不放弃运营流程的情况下更新临床数据基础设施。这种方法不需要机构维持其完全自定义的服务或完全切换到 FHIR,而是可以增量集成这些系统。数据作为 FHIR 资源仍然可用,自定义应用程序终结点和现有查询模式继续在应用程序 API 层工作。使用此解决方案的医院可以逐步实现基础设施的现代化,让临床团队和合作伙伴系统以自己的速度前进。
优化临床数据性能:这种方法允许 FHIR 数据在资源块中保持不变,以确保合规;而应用程序信息则位于高使用率属性中,并建立索引以实现更快的搜索性能。该系统适用于注册、分流和床位管理期间的实时临床仪表盘、操作分析以及快速查找。
提高互操作性和开发者生产力:双 API 架构、内置的合成数据生成和交互式 API 测试工具可帮助团队快速原型设计、验证和部署符合 FHIR 标准的解决方案,而不会中断现有的医院流程。
作者
Patricia Renart Carnicero, MongoDB
Francesc Mateu Amengual, MongoDB