4. 全生命周期阶段划分

患者全生命周期管理平台的核心难点，不在于把“健康管理、门诊、住院、康复、随访、临终关怀”这六个词写进菜单，而在于把每个阶段真正拆解成可被系统承载的工程对象：谁在什么触发条件下进入该阶段、阶段内产生哪些数据、数据以什么标识关联、阶段之间靠什么事件完成流转、流转失败时如何回退与补偿。阶段划分本质上是业务语义到工程模型的映射，而不是页面导航的划分。

先明确一个贯穿全平台的参照约定：本文以“患者主索引（EMPI）+ 就诊流水号 + 阶段实例”三层标识为参照系。EMPI 标识“这个人”，就诊流水号标识“这一次就医”，阶段实例标识“这个人在这一阶段的一段连续管理过程”。所有阶段数据都挂在这三层标识上，方向由“当前阶段实例”指向“历史阶段实例”，即新阶段产生时旧阶段实例被置为 closed，而不是删除或覆盖。

六个阶段的工程语义与关键对象

健康管理阶段面向未就诊或低风险人群，工程对象是健康档案、风险分层、随访计划模板、指标采集任务。触发进入的典型条件是建档、体检报告回传或风险评分越界。该阶段的数据以“时间序列指标”为主，例如血压、血糖、BMI，写入频率低但跨度长，因此存储上更适合列式或时序库，而不是事务型明细表。

门诊阶段由挂号或预约触发，核心对象是挂号单、分诊记录、门诊病历、处方、检验检查申请。门诊阶段的特点是“短时高频、并发集中”，同一患者一天内可能产生多次就诊流水号。工程上必须保证就诊流水号与 EMPI 的绑定在挂号瞬间完成，否则后续处方和报告无法归集。

住院阶段由入院登记触发，核心对象是住院号、床位、医嘱、护理记录、手术记录、费用明细。住院阶段的数据密度最高，医嘱与执行记录之间存在明确的“开立—审核—执行—计费”状态链，任何一环缺失都会导致费用或质控异常。因此住院阶段通常需要独立的状态机来管理医嘱生命周期。

康复阶段可由出院医嘱或康复评估触发，核心对象是康复评定表、训练计划、训练执行记录、功能评分（如 Barthel 指数、MMSE）。康复阶段的关键工程问题是“计划与执行分离”：计划由治疗师制定，执行由患者或设备完成，系统需要同时记录计划版本和执行偏差。

随访阶段由随访计划或出院后时间窗触发，核心对象是随访任务、随访表单、失访记录、预警事件。随访阶段最容易被做成“定时发短信”，但工程上真正需要的是任务状态机：待执行、已联系、已完成、失访、超期关闭。失访不是删除任务，而是进入独立状态并触发人工干预。

临终关怀阶段由病情评估或患者/家属意愿触发，核心对象是舒缓治疗记录、疼痛评分、心理支持记录、家属沟通记录、意愿书。该阶段的数据敏感度最高，权限控制必须细到“单条记录可见范围”，且需要与伦理审查和知情同意绑定。

阶段流转的触发条件与状态机设计

阶段之间不是靠人工点击“下一步”流转，而是靠业务事件驱动。工程上建议为每个阶段实例定义统一状态字段：active、suspended、closed。当新阶段事件到达时，系统先关闭当前 active 实例，再创建新实例，并写入 from_stage 与 to_stage 字段，形成可追溯的阶段链。

以“住院→康复”为例，触发事件是出院医嘱审核通过。此时系统执行三步：第一，将住院阶段实例置为 closed，记录出院时间与出院诊断；第二，根据出院诊断匹配康复计划模板，若匹配成功则创建康复阶段实例；第三，若患者同时满足随访条件，则并行创建随访任务，但随访阶段实例在康复结束后才置为 active。这里的关键是阶段实例可以并行存在，但同一时刻只有一个 active 主阶段，否则权限和费用归属会混乱。

再以“随访→临终关怀”为例，触发条件不是时间，而是病情评估结果或家属意愿书签署。工程上应设置独立的评估表单项，例如“预期生存期评估”与“舒缓治疗意愿”，当两项同时满足时，系统自动创建临终关怀阶段实例，并将随访任务置为 suspended，而不是直接关闭，以便后续可能回退。

数据归属与权限的工程约束

阶段划分直接决定数据归属。门诊数据归属就诊流水号，住院数据归属住院号，康复数据归属康复阶段实例，随访数据归属随访任务。若归属关系错乱，最典型的后果是：同一患者的检验报告在门诊和住院两个阶段重复展示，或者出院后随访看不到住院期间的用药记录。

权限方面，临终关怀阶段必须与其它阶段隔离。建议采用“阶段级权限 + 记录级权限”双层模型：阶段级控制谁能进入该阶段模块，记录级控制单条意愿书、心理支持记录对哪些角色可见。健康管理阶段则相反，权限可以相对宽松，但需要重点控制数据导出与批量查询，防止人群级隐私泄露。

可落地的阶段映射配置示例

下面给出一份可直接参考的阶段映射配置片段，用于在平台中定义阶段编码、触发事件、数据归属与默认状态。字段命名可按实际系统调整，但结构建议保持一致。

stage_mapping:
  - stage_code: HM
    stage_name: 健康管理
    trigger_event: patient_archive_created | risk_score_exceeded
    data_owner: empi_id
    default_state: active
    close_event: outpatient_registered | inpatient_admitted
  - stage_code: OP
    stage_name: 门诊
    trigger_event: outpatient_registered
    data_owner: visit_serial_no
    default_state: active
    close_event: visit_finished
  - stage_code: IP
    stage_name: 住院
    trigger_event: inpatient_admitted
    data_owner: inpatient_no
    default_state: active
    close_event: discharge_order_approved
  - stage_code: RE
    stage_name: 康复
    trigger_event: rehab_plan_created
    data_owner: rehab_instance_id
    default_state: active
    close_event: rehab_goal_achieved | rehab_terminated
  - stage_code: FU
    stage_name: 随访
    trigger_event: followup_task_created
    data_owner: followup_task_id
    default_state: pending
    close_event: followup_completed | lost_to_followup
  - stage_code: PC
    stage_name: 临终关怀
    trigger_event: palliative_assessment_passed & consent_signed
    data_owner: palliative_instance_id
    default_state: active
    close_event: patient_deceased | consent_revoked

配置完成后，判断映射是否正确的依据有三条：第一，任意一条业务数据都能通过 data_owner 反查到唯一阶段实例；第二，任意一次阶段流转都能在阶段链中看到 from_stage 与 to_stage；第三，失访、终止、撤销等异常结束都能落到明确的 close_event，而不是被静默删除。满足这三条，阶段划分才算真正完成了工程化映射，而不是停留在业务名词的排列组合上。