印度母婴护理的可审计紧急分诊

# 印度母婴护理的可审计紧急分诊
来源：https://arxiv.org/html/2609.09356
Aman Dalmia, Niharika Priyadarshini, Neelima Devadas, Amrita K Prasen, Nikhil Nalin, Santhosh SJ, Sreeram Nurani Ramasubramanian, Muhammed Afeer K, Anubhav Arora

###### 摘要

在 Noora Health，我们的护士每月在基于 WhatsApp 的服务上回答超过 50,000 个医疗咨询，该服务为护理人员提供按需支持。他们最紧迫的任务是紧急分诊：决定哪些咨询需要立即的面对面处理。为了支持他们，我们构建了一个系统，使用大型语言模型来分类一条消息是否属于紧急情况，并提供可解释的依据。护士可以标记系统是否漏掉了紧急情况或错误地将其标记为紧急情况，这为我们提供了漏诊紧急情况和误报的实时度量。但该系统是不透明的：分析错误意味着要为每条消息阅读推理链，这在我们这个规模下是不可行的。提示的更改意味着需要重新运行完整的评估以防止回归，这既昂贵又具有操作上的挑战性。临床医生遵循决策树来做出这个判断，但它从未被记录下来或传递给模型，模型依赖的是一个扁平的危险体征列表。为了解决这些问题，我们将分诊分解为两个步骤：一个大型语言模型使用临床医生编写的词汇从查询中提取规范症状和患者背景，一个确定性规则引擎捕获表明紧急情况的场景。我们展示了新系统将召回率从 0.565 提高到 0.810，F1 分数从 0.606 提高到 0.702，其中结构化规则驱动了大部分准确性的提升，而这种分解提供了可审计性：临床专家可以检查新系统的每个阶段，以查看查询是否被误解、症状是否被错误提取、患者背景是否被错误推断，或者必要的规则是否缺失。他们可以独立添加新规则而不会引起回归，并避免运行昂贵的评估。自部署以来，新系统已对 152,421 个患者查询进行了分诊，并将 28,535 个（18.7%）标记为紧急情况。过度升级率为 17.8%，漏诊紧急情况没有增加。自部署以来，临床医生还添加了 48 条新规则，这是我们着手构建的更快速纠正循环的证据。

1 Noora Health  
2 The Agency Fund  
[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]

## 1 引言

Noora Health 是一家非营利组织，支持护理伴侣计划的设计与实施。该计划在患者住院期间对家庭进行基本母婴护理培训，并与当地合作伙伴一起在印度九个州的地区医院实施。出院后，家庭通过一个专门的基于 WhatsApp 的平台获得随访，该平台允许双向沟通：他们可以提问并从我们的支持人员（包括医生和护士）那里获得指导。该平台每月收到超过 50,000 个医疗咨询，主要涉及母婴护理，以及 CCP 涵盖的其他疾病，如心脏病和慢性病护理。我们的护士直接回答常规问题，并将紧急情况转介以寻求立即的面对面护理。但及时可靠地识别它们是困难的。

参见标题图 1：我们 AI 辅助紧急分诊系统的演变。初始版本（上）使用 LLM 端到端地预测查询是否表示紧急情况，知识库是一个危险体征列表。TRACE（下）将任务分解为两个步骤：基于 LLM 的症状提取和患者背景推断，随后是确定性规则引擎，因此每个决策都可以追溯到驱动它的具体规则。

大型语言模型正越来越多地部署在医疗保健领域，包括我们这类中低收入国家资源匮乏、多语言环境，其中对临床指导的需求远远超过训练有素的提供者数量。漏诊升级会直接延迟挽救生命的治疗。我们的消息使任务更具挑战性：它们很短，在不同地区语言间语码转换，并用通俗术语而非标准化临床词汇描述症状。它们常常省略背景信息，然而同一症状根据患者背景可能意味着不同级别的紧急程度：新生儿发热是医疗紧急情况，而年龄较大的儿童同样的发热通常不是。利害关系重大：据世界卫生组织等机构估计，2023 年印度孕产妇死亡约 19,000 例，居全球第二；新生儿死亡约占全球 18%，是全球份额最大的国家之一。未能及时识别危险体征是导致可预防死亡的主要原因之一。

我们最初通过提示一个 LLM 并结合一份通常与紧急情况相关的危险体征列表来构建我们的 AI 辅助分诊系统，以分类消息并为决策生成推理链。它在我们最初的测试集上给出了有希望的结果，随后被部署。我们的护士可以看到哪些消息被标记为紧急情况，并可以覆盖错误的预测，这为我们提供了部署中过度升级和漏诊紧急情况的持续度量。由于漏诊紧急情况危害更大，该系统针对更高的召回率进行了优化。它更快地捕捉到了真实的紧急情况，但在我们的规模下，过度升级的数量成为了一个挑战。

该系统也是不透明的。分析错误的唯一方法是逐条阅读 LLM 生成的推理，这在我们这个规模下并不实际。它也不符合我们临床医生的工作方式：他们遵循一个决策树，综合考虑了患者背景和症状组合，这些知识来自他们的培训和经验，而不是记录下来供模型使用。我们的提示只包含一个扁平的危险体征列表，因此任何更改都有降低性能的风险。为防止回归，我们必须在部署任何更改之前运行完整评估，这增加了我们的成本，需要不同团队协调，并延长了解决问题的时间。这些问题有一个共同的根本原因：模型同时在做两项工作，解释患者查询和做出临床决策。

为了解决这个问题，我们构建了 TRACE。它像临床医生一样将这两项工作分开：一个 LLM 从固定的、临床医生策划的词汇表中提取规范症状以及患者背景（如孕期或婴儿年龄），而一个由临床团队拥有的确定性规则引擎决定是否将其标记为紧急情况。症状提取是一项比分诊更窄的任务，并且是唯一需要对查询进行主观解释的步骤。一旦症状和背景被提取出来，规则就是固定的。图 1 比较了原始的端到端 LLM 系统与 TRACE。

我们表明，结构化规则驱动了大部分准确性的提升，将召回率从 0.565 提高到 0.810，F1 分数从 0.606 提高到 0.702（相比 TRACE 替代的系统），而这种分解提供了可审计性，因为每个错误都可追溯到特定步骤：查询的误解、症状未被提取或完全不在词汇表中、错误的患者背景推断，或规则错误或缺失。每个类别都有负责人：缺失的规则或症状由临床医生处理，提取错误与机器学习团队共同分析。自部署以来，它已对 152,421 个患者查询进行了分诊，标记了 28,535 个（18.7%）为紧急情况，过度升级率为 17.8%，漏诊紧急情况没有增加。临床医生添加了新规则（目前已有 48 条）而无需接触 LLM 提示，因此更改不再需要重新运行昂贵的评估。

## 2 相关工作

#### 使用 NLP 和 LLM 进行临床分诊。

最近的工作表明，LLM 可以阅读非结构化的主诉并评估病情危重程度，接近临床医生水平，无论是急诊室记录还是策划的临床案例，其中典型的失败是高估紧急程度。这些结果假设输入是干净的临床数据，而基于它们构建的系统将判断留在模型内部，通过多智能体审议或检索分诊手册达成。最接近我们环境的设置是在资源匮乏地区部署的妇幼健康支持服务：TRIM-AI 在肯尼亚对语码混合的 SMS 进行分诊；一个 WhatsApp 聊天机器人在印度执行具有阶段意识的孕产妇分诊；CLARITY 将确定性状态机与 LLM 智能体配对，在国家级平台上将患者转诊给专科医生。在每一个案例中，要么紧急决策位于生成模型内部，要么确定性组件控制对话而非最终判断。我们的系统则相反，将 LLM 限制在症状提取，并将紧急决策交给临床医生可编辑的规则引擎，这种分离是先前该环境中的分诊系统所没有的。

#### 低资源医疗保健中的多语言 NLP。

患者很少用临床词汇描述症状，这一差距催生了消费者健康词汇表已有二十年历史；我们遵循这一做法，使用临床医生策划的从通俗短语到规范症状关键词的映射。消息简短且在不同地区语言间语码转换，通常使用罗马化文字书写，这对 NLP 仍然具有挑战性。现有的 LLM 在这些语言上性能会下降。Khullar 等人 (2025) 表明，在真实的孕产妇分诊查询中，即使模型推断出正确意图，罗马化文字也会导致高达 24 个 F1 点的损失，其失败在于最终分类而非理解。这正是我们架构将脆弱的步骤移出 LLM 并放入确定性规则层的地方。

#### 可解释性与部署。

对于高风险决策，大量工作认为系统应该是内在可解释的，而非事后解释，因为事后解释对个体临床案例不可靠。每个建议的可审查依据也是决策支持与受监管设备之间的监管界限。标准方法是将 LLM 视为语言前端，并将决策委托给确定性组件，在医生级别，当 LLM 提取与基于规则的专家系统配对时，可以产生完全可追溯的标签。最接近的类比是 DORIS，它根据临床标准对文本进行注释，并在结果上训练确定性分类器；我们共享这种分解，但使用临床医生可编辑的规则，无需重新训练即可更改，并且在推理时在实时消息上运行 LLM。部署研究强化了这一手段的价值：专家纠正提高了 CataractBot 的准确性并减少了工作量；而 ASHABot 的用户将其输出视为权威，这是支持硬性护栏的论据。我们系统中的每个判断都可以追溯到临床医生可以直接审计和修改的具体规则。

## 3 系统设计

### 3.1 问题表述

系统一次对一条消息进行分诊。我们将输入形式化为一个元组 (m, c, P)。这里，m 是患者消息。c 代表患者在我们平台注册的护理类别，是我们支持的八种类别之一：产前护理、产后护理、特殊新生儿护理病房、高危孕妇、一般健康与福祉、非传染性疾病、母婴健康以及普通内科与外科。P 是我们为每位患者维护的档案信息。对于孕妇，它可能包含预产期和当前所处的孕孕期。对于已分娩的患者，它存储分娩日期和婴儿年龄。仅凭消息无法进行分诊：同一症状的紧急程度随患者背景而变化。系统的输出是 y ∈ {紧急情况, 非紧急情况}。

表 1：说明性词汇条目。患者用英语、罗马化印地语以及在一个短语内语码混合地描述同一症状。护理类别 | 症状 | 另需 | 紧急情况？ | 类型
--- | --- | --- | --- | ---
通用 | 惊厥 | 无 | 是 | 单独
高危孕妇 | 发热超过 38.5°C 持续 24 小时 | 无 | 是 | 单独
产前 | 排尿灼痛 | 无发热 | 否 | 组合：症状 + 症状
产前 | 排尿灼痛 | 伴有发热 | 是 | 组合：症状 + 症状
产前 | 腿痛 | 伴有腿部肿胀和发红 | 是 | 组合：症状 + 症状
产后 | 腿部肿胀 | 伴有胸痛或呼吸困难 | 是 | 组合：症状 + 症状
产前 | 胎动减少 | 孕期 1 | 否 | 组合：症状 + 背景
产前 | 胎动减少 | 孕期 2–3 | 是 | 组合：症状 + 背景

表 2：示例规则。规则按护理类别划分范围，因此同一症状根据患者的注册类别映射到不同的规则：孕妇（产前）的腿痛需要伴有肿胀和发红才被视为紧急情况，而产后（产后）的腿肿只有在伴有胸痛或呼吸困难时才成为紧急情况。“单独”规则仅根据症状本身应用。“组合”规则仅在出现第二症状或患者背景匹配（如特定孕期或婴儿年龄）时应用。高危孕妇指已标记为高危的孕妇，而“通用”规则适用于任何护理类别的患者。

### 3.2 两步分解

查询跨越七种语言，通常用罗马文字输入而非其母语文字，这在该任务上会降低质量。因此，每个查询首先使用 Gemini-2.5-Flash 翻译成英语。然后，一个 LLM 提取消息描述的规范症状，以及其中包含的任何患者背景，并给出简短的理由。