# Missed Diagnosis Recall — 漏诊召回

> **scenario key**(候选):`missed_diagnosis_recall`
> **版本**:v6+(占位,**enum 暂未加**)
> **状态**:⏳ 依赖 AI Gateway + 影像分析模型,W6+ 才能启动

---

## 1. 业务定位

> **PAC 帮诊所发现"影像/历史有信号,但医生没诊断"的患者。**

跟其他场景的根本区别 —— **触发不来自医生 EMR,来自 AI 推断**:

| 维度 | aftercare / disruption / initiation | missed_diagnosis(本)|
|---|---|---|
| **触发数据来源** | host EMR(医生已记录的事实)| **AI 推断**(医生没记录的事实)|
| **PAC 角色** | 漏召回的客户跟客服(已知信息)| 发现医生没看出来的问题(未知信息) |
| **依赖能力** | 仅事实层 | AI Gateway + 影像分析模型 |
| **启用阶段** | W3+ | **W6+** |
| **合规复杂度** | 低(诊断已在 EMR) | **高**(AI 推断是否能作为召回依据需法规澄清) |

### 例子

> 患者 36 牙 X 光显示透射区(隐裂或深龋早期信号),医生当次接诊未诊断;
> AI 影像分析推断"36 牙疑似龋齿/隐裂",建议二次评估。
> PAC 召回 → 客服建议患者回来给医生再看一次。

---

## 2. 触发条件

### 2.1 数据要求(W6+ 才有)

```
1. AI 影像分析结果(新模型输出):
   image_record.content.ai_findings[] = [
     { tooth_position: "36", suggestion: "suspected_caries", confidence: 0.78 },
     ...
   ]

2. 医生 EMR 诊断(已有):
   encounter_record.content.diagnoses[] = [...]

3. 时间窗:影像生成后 30-180 天医生没补诊断
```

### 2.2 SQL 形态(W6+ 实施时,示意)

```sql
SELECT DISTINCT p.external_id
FROM patients p
JOIN patient_facts pf_img ON pf_img.patient_id = p.id
WHERE pf_img.type = 'image_record'
  AND pf_img.content ? 'ai_findings'
  AND EXISTS (
    SELECT 1 FROM jsonb_array_elements(pf_img.content->'ai_findings') f
    WHERE (f->>'confidence')::float >= 0.7         -- AI 置信度阈值
  )
  AND pf_img.occurred_at BETWEEN <180 天前> AND <30 天前>
  -- 医生 EMR 没补对应诊断
  AND NOT EXISTS (
    SELECT 1 FROM patient_facts pf_dx
    WHERE pf_dx.patient_id = p.id
      AND pf_dx.type = 'encounter_record'
      AND pf_dx.occurred_at >= pf_img.occurred_at
      AND EXISTS (
        SELECT 1 FROM jsonb_array_elements(pf_dx.content->'diagnoses') d,
                       jsonb_array_elements(pf_img.content->'ai_findings') f
        WHERE d->>'tooth_position' = f->>'tooth_position'
          -- 诊断码跟 AI 建议覆盖(应用层模糊匹配)
      )
  )
```

---

## 3. 跟其他 scenario 的根本不同

| | aftercare / disruption / initiation | missed_diagnosis |
|---|---|---|
| fact A 是什么 | 医生记录的治疗 / 诊断 | **AI 推断的"应有诊断"** |
| fact B 是什么 | 应执行的下一步 / 应启动的治疗 / 应做的复查 | 医生**应补的诊断** |
| 召回意图 | 找回客户做下一步 | **建议医生再看一次**(对客户来说是体检建议) |
| 客服话术 | "您该来做 X" | "AI 检查您的片子有发现,建议您回来给医生再看看" |

**核心**:其他 3 个 scenario 是"客户层动作召回"(去做治疗 / 去做复查),本 scenario 是"**医患层动作召回**"(让医生再评估)。

业务上,客服话术 / Plan 路由 / 沟通管控都不同。

---

## 4. 法规 + 合规约束(关键!)

1. **AI 推断是否能作为召回理由?** — 国内 NMPA / 医疗 AI 监管框架尚未统一,需法务确认
2. **客服怎么传达 AI 的建议?** — 不能直接说"AI 诊断你有 X 病"(会被认定为非法行医)
3. **召回话术必须中性** — "我们的体检建议系统提示您回来给医生再检查一下"
4. **触达对象** — 是否能直接打电话 / 还是要先经过医生审核

### 合规设计

- AI 输出 → **医生审核站点**(必须有医生 review 才能进客服触达池)
- 医生 confirm → 转 PAC 召回(等于变成"医生发起的随访")
- 医生 reject → 不进召回

这是个**完全独立的工作流**,跟其他 scenario 的"算法直出召回名单"差距很大。

---

## 5. 实施前置条件(W6+)

| # | 条件 | 当前状态 |
|---|---|---|
| 1 | AI Gateway 接通 | W4+ 接通 LLM,影像 AI 模型 W6+ |
| 2 | 影像分析模型(龋齿 / 牙周 / 缺牙识别)| W6+ |
| 3 | image_record fact 含 `ai_findings[]` 形态 | 待 schema 扩展 |
| 4 | "医生审核环节"工作流 | 待产品设计 |
| 5 | 法务对 AI 召回的合规结论 | 待 |
| 6 | 召回话术中性化 + 客服培训 | 待 |

---

## 6. 跟 initiation 的微妙边界

| | initiation(漏治新链)| missed_diagnosis(漏诊)|
|---|---|---|
| 诊断状态 | **医生已诊断**了 X | **医生没诊断** X |
| 治疗状态 | 患者没启动 X 治疗 | 不一定 |
| 数据 | EMR `diagnoses[]` 含 X | EMR `diagnoses[]` 不含 X,但 AI 影像有信号 |
| PAC 怎么知道 | 比对 diagnosis ↔ treatment | 比对 AI signal ↔ diagnosis |
| 召回对象 | 客户(去启动治疗)| 医生(再看一次)/ 客户(去复诊)|

简言之:
- **initiation** = "医生看出来了,患者没行动"(行动漏斗)
- **missed_diagnosis** = "医生没看出来,患者也不知道"(发现漏斗)

---

## 7. 业务方拍板清单(W6+ 启动前)

| # | 项 | 待答 |
|---|---|---|
| 1 | 是否做漏诊 scenario?| ? |
| 2 | AI 推断的置信度阈值(0.7 / 0.8 / 0.9?)| ? |
| 3 | 医生审核工作流的 SLA(几天内 review?)| ? |
| 4 | 合规话术红线 — 客服能说什么 / 不能说什么 | ? |
| 5 | 是否限制特定治疗类别(只做种植 / 龋齿,不做牙周等模糊诊断)| ? |

---

## 8. 文档关联

- 疗效保障(主战场) → `scenarios/treatment_aftercare_recall.md`
- 启治召回 → `scenarios/treatment_initiation_recall.md`
- 链内中断(候选)→ `scenarios/treatment_chain_disruption_recall.md`
- 4 scenario 对比 → `scenarios/README.md`
