用于护理缺口检测的临床决策支持

MongoDB Atlas：主要功能

MongoDB Atlas 专为复杂的医疗工作负载而设计，可以用高度优化的原生数据生态系统替换旧版系统。以下是平台提供实时决策支持的核心功能概要。

图 3。Atlas 关键功能

灵活的 document model：patient_360 collection 将完整的患者记录（包括人口统计数据、病症、药物、实验室、生命体征总结、护理缺口、警报、个性化阈值和数据来源）存储在单个文档中。单个文档可以回答需要对 FHIR 存储进行多资源连接的问题。

时间序列集合：synthetic_vitals 集合使用 MongoDB 的原生时间序列集合来存储可穿戴设备数据。这些集合为高频率、按时间顺序排列的数据提供自动数据分桶、高效的范围查询和专用存储。

变更流：该平台使用变更流实时反应新的生命体征。当读数到达时，系统会评估 CDS 规则并生成临床警报，而无需进行拉取。

Queryable Encryption：MongoDB Queryable Encryption 可以在静止状态下保护敏感患者字段。该应用程序可以查询加密的 PHI 字段，而不会暴露明文，从而满足 HIPAA 要求，并且无需单独的加密层。

聚合管道：该框架处理仪表盘聚合、护理差距计算、生命体征趋势分析和 HEDIS 评分，在几毫秒内解决复杂的临床查询。

AI 和分析的结构：patient_360 文档可以向下游 AI 和分析管道提供规范化的临床事实、结构化的证据和元数据来源，无需进行附加转换。

数据生成管道

初始化后，该解决方案使用多步管道来培育和激活 CDS 系统，如下所示。

图 4。数据生成管道

数据生成管道驱动初始化序列，该序列创建合成和具体化的临床数据，计算个性化阈值和护理缺口，并开始实时监控。该管道的工作方式如下：

1. 生成 FHIR 患者包：创建 FHIR R4 事务包，包括病症、药物、实验观察、就诊和过敏。它将这些包存储在 FHIR 数据存储中，该存储可作为互操作层。

2. 生成生命体征历史：为每位患者生成 24 小时的生命体征时间序列，代表正常、恶化或急性生理模式。它将数据存储在 synthetic_vitals 时间序列集合中。

3. 具体化 patient_360 文档：将每个 FHIR 包转换为 MongoDB Atlas 中的非规范化 patient_360 文档。转换包含一个 data_provenance 块，该块链接回源 FHIR 记录。

4. 种子 CDS 规则：将临床决策支持规则定义插入 cds_rules 集合。

5. 计算个性化阈值：根据活动药物和病症计算每位患者的生命体征阈值。它将这些结果存储在 patient_360 文档中。

6. 评估 CDS 规则：对当前生命体征运行 AlertEngine，并将生成的警报写入 alerts 集合。

7. 计算 HEDIS 关怀差距：对每位患者的临床病历运行 QualityEngine，并将结构化的关怀差距结果写入 patient_360 文档。

8. 种子提供商属性：在 attributions 集合中生成提供商-患者属性关系，确定哪些提供商接收缺口结果和警报。

9. 开始实时监控：激活生命体征模拟工作器，并通过服务器发送的事件开始向临床平台流式传输实时生命体征数据。

CDS 引擎

CDS 引擎分析患者数据，为护理团队提供可操作的见解。该解决方案将临床监控与质量测量计算分离到两个独立引擎中。该架构模式遵循 Da Vinci 企划，该企划是一个用于护理互操作的 HL7 FHIR 加速器程序，建议将实时警报与 HEDIS 间隙逻辑解耦。

护理缺口工作流

医疗差距工作流程是医疗组织用于识别、追踪和解决患者实际临床护理与既定医疗指南之间差异的系统过程。医疗差距检测从识别到关闭遵循结构化路径，包括以下操作：

• 评估：QualityEngine根据 HEDIS 测量标准评估每位患者的临床病史。

• 写入：系统将开放的缺口写入 patient_360文档，并附加其支持证据、推荐操作和优先级。

• 查看：管理员按照优先级和逾期时间查看临床平台中的未开发空白。

• 干预：对于可执行的差距，例如 KED 和 CDC-HBA，平台会打开一个结构化的干预工作区域，协调员可以在其中下达实验室订单、记录完成情况或安排跟进。

• 关闭：干预完成后，间隙状态会在 patient_360 文档中更新，并在下一个周期中对 QualityEngine 进行重新评估。

• 升级：当 AlertEngine 检测到临床警报时，它会提高相关开放缺口的优先级，并通知护理团队。没有相关缺口的警报，例如脓毒警告，会作为独立的临床通知直接路由到护理团队。

作为文档数组的临床数据

在 patient_360 文档中，每个条件都代表 conditions 数组中的一个条目，而每种药物都代表 medications 数组中的一个条目。如下所示，文档以使用的形状存储临床实体，而不是分割到不同的表中：

{
   "conditions": [
      {
         "code": "44054006",
         "display": "Type 2 diabetes mellitus",
         "clinical_status": "active",
         "onset_date": "2017-10-21T21:29:59.716351+00:00"
      },
      {
         "code": "433144002",
         "display": "Chronic kidney disease stage 3",
         "clinical_status": "active",
         "onset_date": "2023-09-12T21:29:59.716372+00:00"
      }
   ],
   "medications": [
      {
         "display": "Insulin glargine 100 units/mL injection",
         "dose": "20.0 units",
         "route": "subcutaneous",
         "frequency": "once daily at bedtime",
         "status": "active"
      },
      {
         "display": "Atenolol 50 mg oral tablet",
         "dose": "50.0 mg",
         "route": "oral",
         "frequency": "once daily",
         "status": "active"
      }
   ]
}

计算操作字段

FHIR 包含标准互操作数据，而 patient_360 文档则包含 FHIR 未定义的操作字段，包括临床标志、护理缺口结果、个性化阈值和活动警报。

例如，嵌入到更广泛的数据生成管道中的具体化管道会从 FHIR 包计算临床标志，并将其直接写入 patient_360 文档。AlertEngine 会读取这些标志，以确定哪些 CDS 规则适用于患者，包括：

• flags.has_beta_blocker：激活β受体阻滞剂心率规则。

• flags.has_insulin: 激活多因素低血糖规则。

• flags.has_ckd: 激活 CKD 代谢性酸中和呼吸规则。

• flags.condition_codes: 所有活动状态的 SNOMED 代码。

护理差距结果使用相同的方法。具体化管道计算护理差距结果，并将其直接添加到 patient_360 文档。每个计算的 HEDIS 度量都与其相关的 status、priority、evidence 和 recommended_action 一起存储在 care_gaps 数组中。与标准 FHIR 不同，document model 将此信息与患者的临床记录一起存储。此结构的示例如下：

{
   "care_gaps": [
      {
         "hedis_measure": "CDC-HBA",
         "measure_name": "Comprehensive Diabetes Care — HbA1c Testing",
         "status": "open",
         "days_overdue": 34,
         "priority": "high",
         "evidence": {
            "found": ["HbA1c 5.13% (2025-10-07)"],
            "missing": []
         },
         "recommended_action": "Schedule or order an HbA1c follow-up"
      }
   ]
}

这种方法提供了更大的灵活性；当临床要求发生变化时，您可以扩展文档。新的 CDS 规则将新字段写入到同一文档，而不影响现有字段。

对源记录的可追溯性

patient_360 文档构成一个衍生的操作视图，而不是 FHIR 记录的替代。具体化管道从 FHIR 资源产生此视图。为了对任何临床决策或护理差距结果进行 Atlas 审核，每个文档都包含一个 data_provenance 块：

{
   "data_provenance": {
      "layer": "cds_operational",
      "source_fhir_collection": "synthetic_patients",
      "source_patient_id": "1b3bbaec-def8-4b55-8e87-9d04b55d6890",
      "materialization_version": "1.0",
      "last_materialized_at": "2026-05-09T21:30:04.873754+00:00",
      "fhir_resource_count": 22
   }
}

FHIR 数据存储是可互操作的权威真实来源，而 MongoDB Atlas 则保持操作视图，维护与其来源数据的直接链接。

在 document model 中加密字段

医疗保健法规要求应用程序对 PHI 进行加密。一种常见的方法是将加密的 PHI 存储在单独的系统中，并仅在需要时才检索。然而，该框架引入了第二个数据存储库、单独的密钥管理层，并增加了每次患者记录检索的延迟。

MongoDB Queryable Encryption 消除了这一开销，将 PHI 保留在同一文档中。它可以保护高度敏感字段，例如患者姓名、MRN 和出生日期，使其只能被持有加密密钥的授权客户端应用程序读取。文档的其余部分可继续查询以进行操作使用：

{
   "demographics": {
      "name": { "$binary": { "base64": "EAXZmoXjO0re...", "subType": "06" } },
      "given": { "$binary": { "base64": "EF1RChFVFEJC...", "subType": "06" } },
      "family": { "$binary": { "base64": "EK18iT8qVki8...", "subType": "06" } },
      "birth_date": { "$binary": { "base64": "EJOsqgLJPEjI...", "subType": "06" } },
      "gender": "female",
      "age": 77
   }
}

例如，AlertEngine 和 QualityEngine 等微服务会读取标志、阈值和关注空白字段，也不会读取加密的人口统计字段。