3. 随访计划与规则引擎设计
随访计划不是一张静态的“时间表”，而是一套可执行、可分支、可终止的业务规则集合。在患者随访系统中，计划由随访模板定义“随访什么”，由周期与触发条件定义“什么时候随访”，由分支路径定义“不同结果走哪条路”，由终止规则定义“什么时候结束”。这四者共同构成随访计划模型，而规则引擎负责在运行时对它们进行求值与调度。
一、随访模板：把随访内容结构化
随访模板是计划的最小可复用单元，通常包含随访类型、适用病种/术式、随访项集合、随访方式（电话、App 问卷、门诊、短信）、责任角色（专科护士、医生、AI 外呼）以及默认周期。模板设计的关键是把“问什么”与“怎么问”分离：随访项只描述临床语义，例如“术后 7 天切口疼痛评分（NRS 0–10）”“服药依从性（是/否/部分）”“是否出现发热（体温≥38.5℃）”，而具体呈现形式、选项编码、是否必填由模板配置决定。
一个可用的模板示例（教学示例，非实测数据）：
template: 胃癌术后随访-基础版
disease: 胃癌
stage: 术后
items:
- id: pain_nrs
label: 切口疼痛评分
type: int
range: [0, 10]
required: true
- id: fever
label: 是否发热
type: bool
required: true
- id: compliance
label: 服药依从性
type: enum
options: [完全依从, 部分依从, 不依从]
- id: weight
label: 体重(kg)
type: float
range: [30, 150]
default_cycle: 7d
channel: [app, phone]
owner_role: 随访护士
模板的价值在于复用与版本化。同一病种在不同阶段（术后、辅助治疗期、康复期）应使用不同模板，并通过 template_id + version 绑定到患者计划，避免模板修改后历史计划被“追溯篡改”。
二、随访周期与触发条件
周期决定“多久随访一次”，触发条件决定“什么事件发生时立即随访”。两者是“定时”与“事件驱动”的组合。常见周期表达方式有三种：
- 固定间隔：如术后第 7、14、30、90 天，适合术后早期。
- 相对锚点：以手术日、出院日、化疗周期开始日为锚点，偏移量可为负（术前）或正（术后）。
- 动态调整：根据上次随访结果自动缩短或延长，例如疼痛评分≥7 分时，下次随访间隔由 7 天缩短为 2 天。
触发条件通常来自三类信号：时间信号（到达计划时间点）、临床信号（检验值异常、体温上报、症状问卷触发阈值）、业务信号（出院、入组、转科、用药变更）。例如“体温≥38.5℃ 且持续 2 次上报”可触发一次即时电话随访。触发条件必须可配置、可测试，避免硬编码在业务代码中。
三、分支路径与终止规则
分支路径是随访计划的“决策树”。一次随访结束后，系统根据随访项结果决定下一步：继续原周期、进入强化随访、转人工、或终止。例如疼痛评分 0–3 分走常规路径，4–6 分走加密随访，≥7 分走“立即转医生 + 24 小时内电话”路径。分支条件应使用明确的布尔表达式，并保留求值日志，便于复盘。
终止规则同样重要，常见包括：完成预设随访次数、患者退出/失访、死亡、转入其他机构、达到临床终点（如术后 5 年无复发）。终止不是“删除”，而是将计划状态置为 terminated 并记录原因，保证数据可追溯。
四、规则引擎选型与可配置化设计
规则引擎的选型取决于规则的复杂度、变更频率与团队技术栈。常见方案有三类：
| 方案 | 适用场景 | 优点 | 注意点 |
|---|---|---|---|
| 硬编码 + 配置表 | 规则少、变更低频 | 实现简单、性能好 | 变更需发版，难追溯 |
| 表达式引擎（如 Aviator、SpEL） | 条件判断为主 | 轻量、可动态求值 | 需限制表达式能力，防注入 |
| 规则引擎（如 Drools、Easy Rules） | 多规则、多分支、需审计 | 规则与代码分离、可热更新 | 学习成本高，需治理规则冲突 |
可配置化的核心是把规则从代码中抽离为数据。建议采用“模板 + 规则集 + 计划实例”三层模型：模板定义随访项，规则集定义触发与分支表达式，计划实例绑定患者与锚点。规则表达式建议使用受限 DSL，例如：
rule: 术后疼痛升级
when:
item.pain_nrs >= 7
then:
action: escalate
assign_to: 主管医生
next_interval: 2d
notify: sms + app
规则求值必须记录输入、命中规则、输出动作与时间戳，形成求值日志。当患者对随访安排有异议，或临床需要复盘“为什么这次没有按时随访”时，日志是唯一可信依据。同时，规则变更应走版本管理，新版本先灰度到少量患者，观察任务生成量与异常率，再全量发布。
最后需要强调：规则引擎不是越复杂越好。对于大多数随访场景，“配置表 + 表达式引擎 + 求值日志”已经足够覆盖 80% 的需求；只有当规则数量超过数百条、需要多规则冲突仲裁与热更新时，才引入完整规则引擎。选型的判断标准始终是：规则变更频率、可追溯要求和团队维护成本，而不是技术先进性。