# Treatment Initiation Recall — 启治召回(漏治新链)

> **scenario key**:`treatment_initiation_recall`
> **版本**:v1(占位,W3+ host 数据丰富后实施)
> **状态**:⏳ enum 已占位,**SelectorService 未实施**,等业务拍板 + host 真实诊断数据

---

## 1. 业务定位 — 一句话

> **PAC 帮诊所追上"诊断了 X 病,但患者从没启动 X 治疗"的客户。**

跟疗效保障召回的关键区别:

| 维度 | `treatment_aftercare_recall` | `treatment_initiation_recall`(本) |
|---|---|---|
| 触发 | 治疗链**已完成** + 后续保养漏掉 | 诊断存在 + **从未启动过**对应治疗 |
| 数据 | 治疗 fact + 时间窗 | 诊断 fact + 缺对应治疗 fact |
| 时间窗 | 节点完成后 30-540 天 | 诊断后 30-180 天 |
| 业务价值 | 长效粘性、防失败 | 转化漏斗、新单转化 |

### 例子

> CT 显示 36 牙缺失,医生 EMR 诊断"缺失牙(K08.1)",但患者从没启动 implant / 桥 / 义齿任何治疗 → PAC 召回客服跟进。

> 医生在咨询单写"建议正畸",但患者一年没启动正畸治疗 → PAC 召回。

> 病历记录"龋齿 27",但未做填充 → PAC 召回。

---

## 2. 跟漏诊的区别(都"漏",但完全不同)

| | 漏治新链(本场景)| 漏诊(W6+) |
|---|---|---|
| **触发** | 医生**诊断了**,患者**没治** | 影像/历史有信号,医生**没诊断** |
| 谁的"错" | 患者(没回来 / 没决定)| 医生(看漏)|
| PAC 怎么知道 | 比对 `diagnosis fact` ✗ 没对应 `treatment fact` | **AI 看影像** + 比对 EMR |
| 数据来源 | host EMR 已有 | 需要 PAC AI 影像分析 |
| 启用阶段 | W3+(host 诊断数据足够清晰) | W6+(AI Gateway + 影像模型) |

---

## 3. 实施前置条件

### 3.1 数据 — host 必须提供清晰的诊断信号

`encounter_record.content.diagnoses[]` 当前形态:
```json
{
  "code": "K04.0",
  "name": "不可复性牙髓炎",
  "tooth_position": "11"
}
```

需要增强为**可机器消费的诊断分类**(下方为目标形态,待 host 提供 + assembler.yaml 映射):
```json
{
  "code": "K08.1",                       // ICD-10 或 host 内码
  "name": "牙缺失",                       // 中文
  "category": "missing_tooth",           // ⭐ 待加:可枚举的诊断分类
  "tooth_position": "36",
  "suggested_treatment_category": "implant"  // ⭐ 待加(可推断):诊断 → 建议治疗类型
}
```

### 3.2 时间窗(待业务拍板默认值)

| 诊断 → 治疗类型 | 默认窗口 | 业务问题 |
|---|---|---|
| 缺失牙 → 种植/桥/义齿 | 诊断后 60-180 天 | 几天内能完成首次咨询?多久没回来算"漏"? |
| 龋齿 → 填充 | 诊断后 30-90 天 | 龋齿应快补 |
| 牙周问题 → 牙周治疗 | 诊断后 30-90 天 | 同上,牙周可能急性加重 |
| 正畸建议 → 正畸主治 | 咨询后 90-365 天 | 正畸决策周期长 |
| 美白咨询 → 美白治疗 | 咨询后 30-180 天 | 弹性大,业务自定 |

---

## 4. 召回 SQL 形态(待实施,示意)

```sql
-- 缺失牙诊断,无对应种植/桥/义齿治疗(示意)
SELECT DISTINCT p.external_id
FROM patients p
JOIN patient_profiles pp ON pp.patient_id = p.id
JOIN patient_facts pf_dx ON pf_dx.patient_id = p.id
WHERE pf_dx.status = 'active'
  AND pf_dx.type = 'encounter_record'
  AND EXISTS (
    SELECT 1 FROM jsonb_array_elements(pf_dx.content->'diagnoses') d
    WHERE d->>'category' = 'missing_tooth'
  )
  AND pf_dx.occurred_at BETWEEN <180 天前> AND <60 天前>
  AND p.active = true AND pp.do_not_contact = false AND pp.deceased = false
  AND p.phone IS NOT NULL AND p.phone <> ''
  -- 无对应种植 / 桥 / 义齿治疗
  AND NOT EXISTS (
    SELECT 1 FROM patient_facts pf_tx
    WHERE pf_tx.patient_id = p.id
      AND pf_tx.type = 'encounter_record'
      AND EXISTS (
        SELECT 1 FROM jsonb_array_elements(pf_tx.content->'treatments') t
        WHERE t->>'treatment_category' IN ('implant', 'prosthodontic')
      )
  )
```

---

## 5. priorityScore 算法(默认基线)

```
priorityScore =
    sub_scenario_base_weight       // 缺失牙→种植 90,龋齿 50,正畸 60 等
  + value_bonus(persona.value)
  + recency_bonus(daysSinceDiagnosis)
```

| 子场景 | 默认基线 | 理由 |
|---|---|---|
| 缺失牙 → 种植 | 90 | 高单价高 LTV |
| 龋齿 → 填充 | 50 | 单价低但量大 |
| 正畸咨询 → 启动 | 60 | 高单价但决策长 |

---

## 6. 启用时间表

| 阶段 | 状态 | 输入 |
|---|---|---|
| W2 | enum 占位 | 当前 |
| W3 | 待 host 提供清晰诊断分类 + 业务拍板时间窗 | host 数据字典更新 |
| W4 | 实施 SelectorService + mock 加"漏治新链"正负例 | mock 重生成 |
| W5 | 联调上线 | |

---

## 7. 业务方拍板清单

| # | 项 | 待答 |
|---|---|---|
| 1 | 哪些诊断类型 PAC 召回(缺失牙 / 龋齿 / 牙周病 / 正畸 / ...)| ? |
| 2 | 每类诊断的时间窗(默认值见上)| ? |
| 3 | 是否区分"医生诊断"vs"患者咨询"(后者更不严谨)| ? |
| 4 | 是否合规边界 — 诊断信息发给客服触达是否需患者同意 | ? |

---

## 8. 文档关联

- 疗效保障召回(主战场) → `docs/scenarios/treatment_aftercare_recall.md`
- DB 模型 → `docs/db-design-v2.md`(FollowupPlan / PlanReason)
- 数据请求 → `docs/host-data-request-checklist.md`(host 数据字典)
