# PAC 治疗链、自动随访与人工召回业务形态说明

> 版本:v0.1  
> 对象:PAC / 疗效保障项目业务口径说明  
> 目的:说明 medical treatment chain、automated follow-up、manual recall、exception escalation 的关系。  
> 核心口径:PAC 不只是生成"回访任务",而是判断患者处在哪个治疗服务状态,并决定后续动作应自动化还是进入人工。

---

## 1. 总体业务目标

疗效保障项目的目标不是增加人工回访任务数量。

更准确的目标是:


```text
识别患者当前所处的治疗服务状态;
把治疗链内可标准化的 follow-up 自动化;
把真正需要人工介入的患者分流到人工任务池。
```



因此,PAC 需要先判断患者处于哪类状态:


```text
1. 未进入治疗链 / 沉睡 / 流失 / 待转化
2. 已在 medical treatment chain 内
3. 已在 treatment chain 内,但出现 broken / abnormal / no-response / risk
```



对应动作:


```text
未进入治疗链 / 沉睡客户
    → manual_recall_plan

治疗链内正常随访
    → automated_clinical_followup_plan

治疗链内异常 / 断点 / 无响应 / 高风险
    → exception_escalation_plan
    → 必要时转 manual_recall_plan
```



---

## 2. medical treatment chain 的定义

medical treatment chain 指围绕一次治疗机会形成的完整医疗服务链条。

它不是单个 diagnosis,也不是单个 treatment 字段。

它至少包含:


```text
1. 发现治疗机会
   - 影像资料
   - EMR 检查记录
   - 医生判断
   - 医嘱 / Doctor Order
   - 收费单项目

2. 治疗链进入
   - 治疗计划形成
   - 收费单提交
   - 收款完成
   - 预约计划形成
   - 患者被接诊

3. 治疗执行
   - procedure / 处置 / 手术 / 治疗动作
   - medication / 用药
   - EMR 记录
   - 医生处置记录
   - 收费 / 退费 / 补费

4. 术后与复查管理
   - post-op instruction / 术后医嘱
   - medication reminder / 用药提醒
   - review plan / 复查计划
   - post-op follow-up / 术后随访
   - complication watch / 并发症观察
   - patient education / 患教
   - adherence check / 依从性确认

5. 治疗链闭环
   - 应完成的 procedure 已完成
   - 应有的复查已安排或已完成
   - 应有的术后随访已完成
   - 无未处理风险信号
```



因此,medical treatment chain 是一组 facts / assertions / assessments 的组合结果,而不是某一张表或某一个字段。

---

## 3. follow-up 与 recall 的区别

### 3.1 Clinical Follow-up:治疗链内随访

Clinical Follow-up 是治疗链的一部分。

它的目标不是"邀约患者回来",而是:


```text
保证治疗服务连续性;
完成术后管理;
提醒患者按医嘱执行;
收集患者反馈;
发现异常后升级人工。
```



典型场景:


```text
拔牙后 24 小时注意事项提醒
种植术后第 1 天 / 第 3 天 / 第 7 天随访
根管治疗后疼痛观察
术后用药提醒
复查前提醒
正畸佩戴依从性提醒
洁牙后注意事项
牙周维护提醒
```



这类 follow-up 优先自动化:


```text
企微自动消息
短信
小程序问卷
AI 随访
患者自填反馈
自动患教材料推送
```



只有出现异常时,才升级人工。

---

### 3.2 Manual Recall:人工召回

Manual Recall 是把患者重新带回治疗服务链条。

它的目标是:


```text
让未进入治疗链、治疗链中断、长期沉睡、存在待治疗机会的患者重新回到服务流程中。
```



典型场景:


```text
沉睡客户
咨询后未转化
检查/影像/病历提示有治疗机会但未进入治疗链
收费单提交后未支付
治疗开始后无后续预约
治疗链中断
长期未到诊
复查计划过期未预约
```



这类场景通常进入人工任务池:


```text
人工电话
人工企微
客服邀约
诊所前台跟进
医生助理跟进
```



---

### 3.3 Exception Escalation:异常升级

Exception Escalation 是治疗链内自动随访发现异常后的人工升级。

它的来源是自动化 follow-up 或 treatment chain 状态监控。

典型触发:


```text
患者反馈疼痛/出血/肿胀异常
患者连续未响应自动随访
术后随访问卷出现风险答案
医生医嘱要求复查,但无预约计划
复查计划过期
治疗链应有下一步,但无 appointment_plan
收费/治疗/病历之间断裂
术后管理节点未完成
```



升级对象可能是:


```text
客服
医生助理
医生
诊所管理人员
```



---

## 4. 三类 Plan

PAC 的 Plan 层建议区分三类。

### 4.1 automated_clinical_followup_plan

治疗链内自动化随访计划。

适用:


```text
患者已进入 medical treatment chain;
当前节点有标准化随访动作;
该动作可自动化完成;
无需人工判断。
```



执行方式:


```text
企微消息
短信
AI 随访
自动问卷
患教内容推送
```



示例:


```text
种植术后第 1 天自动发送术后注意事项;
第 3 天自动问询疼痛、肿胀、出血情况;
患者反馈正常,则继续自动随访;
患者反馈异常,则生成 exception_escalation_plan。
```



---

### 4.2 manual_recall_plan

人工召回计划。

适用:


```text
患者未进入治疗链;
患者治疗链中断;
患者长期沉睡;
存在待治疗机会但未转化;
需要人工邀约、解释、沟通或协调。
```



执行方式:


```text
电话
人工企微
前台跟进
客服中心跟进
医生助理跟进
```



示例:


```text
影像/EMR/收费单综合判断患者存在待治疗项目;
但无收费、无预约、无后续治疗计划;
生成人工召回任务,由客服邀约患者回诊。
```



---

### 4.3 exception_escalation_plan

异常升级计划。

适用:


```text
患者本来处于 treatment chain 内;
但自动随访或事实监控发现异常;
需要人工确认或医疗人员介入。
```



执行方式:


```text
人工客服确认
医生助理介入
医生处理
诊所管理人员处理
```



示例:


```text
患者术后自动问卷反馈持续出血;
系统生成 exception_escalation_plan;
由医生助理或医生跟进。
```



---

## 5. 状态分流模型

PAC 可以先判断患者状态,再决定 Plan 类型。


```text
Patient Facts
  ↓
判断是否存在 treatment opportunity
  ↓
判断是否已进入 medical treatment chain
  ↓
判断 chain 是否正常推进
  ↓
判断是否需要自动随访 / 人工召回 / 异常升级
```



### 5.1 未进入治疗链

条件示例:


```text
存在治疗机会
但没有收费单
没有付款
没有预约计划
没有治疗计划
没有后续接诊记录
```



Plan 类型:


```text
manual_recall_plan
```



---

### 5.2 已进入治疗链,且正常推进

条件示例:


```text
有治疗计划
有收费/收款
有 appointment_plan
有 procedure / EMR 记录
有 post-op instruction 或 review_plan
```



Plan 类型:


```text
automated_clinical_followup_plan
```



---

### 5.3 治疗链内出现 broken

broken 示例:


```text
应有复查计划,但无 appointment_plan
应有后续治疗,但无治疗计划
收费完成但无后续接诊 / EMR
治疗完成但无术后随访
自动随访连续未响应
患者反馈异常
```



Plan 类型:


```text
exception_escalation_plan
```



必要时进入:


```text
manual_recall_plan
```



---

## 6. 业务判断链条

PAC 需要判断的不是"有没有 diagnosis",而是:


```text
是否存在治疗机会;
是否进入治疗链;
治疗链是否闭环;
follow-up 是否完整;
是否需要人工。
```



可以按以下顺序组织:


```text
1. 从 image / EMR / doctor order / charge order 中识别 treatment opportunity
2. 从 charge order / payment / appointment / EMR 中判断是否进入 treatment chain
3. 从 procedure / medication / doctor order / review_plan / appointment_plan 中判断 chain 是否继续推进
4. 从 post-op instruction / patient response / followup result 中判断 clinical follow-up 是否完整
5. 若标准化动作可自动化 → automated_clinical_followup_plan
6. 若 chain 未进入 / 中断 / 长期沉睡 → manual_recall_plan
7. 若 chain 内异常 / 无响应 / 高风险 → exception_escalation_plan
```



---

## 7. 与 Fact / Assertion / Assessment 的关系

### 7.1 Fact 层

Fact 层承接记录和安排。

示例:


```text
emr_record
doctor_order_record
image_record
charge_order_record
payment_record
refund_record
appointment_plan
review_plan
followup_plan
patient_received_record
```



### 7.2 Assertion 层

Assertion 层承接从记录中解析出的语义断言。

示例:


```text
image_detected_treatment_need
emr_exam_finding
doctor_order_treatment_intent
charge_confirmed_treatment_item
post_op_instruction_assertion
medication_instruction_assertion
```



### 7.3 Assessment / Persona 层

Assessment 层承接综合评价。

示例:


```text
treatment_opportunity_signal
treatment_chain_entry_status
medical_treatment_chain_status
treatment_chain_broken_signal
followup_completeness
automation_eligibility
manual_recall_required
exception_escalation_required
```



### 7.4 Plan 层

Plan 层承接行动计划。

示例:


```text
automated_clinical_followup_plan
manual_recall_plan
exception_escalation_plan
```



---

## 8. PlanReason 建议增加 reason_type

PlanReason 不只表达"为什么召回",也要表达为什么生成某类计划。

建议 reason_type 包括:


```text
dormant_customer
treatment_opportunity_not_entered
charge_order_unpaid
treatment_chain_broken
review_plan_expired
post_op_followup_required
auto_followup_no_response
auto_followup_risk_answer
patient_reported_abnormal
manual_recall_required
exception_escalation_required
```



这些 reason_type 用于区分:


```text
人工召回理由
自动随访理由
异常升级理由
```



---

## 9. 业务约束


```text
follow-up 不等于 recall。
recall 不等于所有患者触达。
```




```text
治疗链内 follow-up 优先自动化。
治疗链外沉睡/未进入链条/中断场景进入人工召回。
治疗链内异常、无响应、高风险场景升级人工。
```




```text
PAC 的目标不是多生成任务。
PAC 的目标是把能自动化的 follow-up 自动化,把需要人工的患者留给人工。
```



---

## 10. 一句话总结


```text
medical treatment chain 内的标准化 follow-up,优先自动化;
medical treatment chain 外的沉睡、未转化、链条中断,进入人工召回;
medical treatment chain 内的异常、无响应、高风险,升级人工。
```
