1. 平台工程导论

患者全生命周期管理（Patient Lifecycle Management，PLM）并不是“把患者信息存进系统”这么简单。它指的是围绕一名患者从接触、建档、就诊、诊断、治疗、随访、康复、慢病管理到失访或结案的完整过程，用统一的身份、连续的数据和可追踪的任务，把分散在不同科室、不同时间点、不同系统里的医疗行为串成一条可管理的主线。理解这一章，关键要抓住三个问题：管理对象是谁、管理边界在哪里、平台工程要解决什么。

一、定义：以“患者主线”组织医疗过程

在传统医院信息化中，患者往往以“一次挂号”“一次住院”“一份检验报告”为单位被记录。同一个患者在不同系统中可能有多个 ID，门诊、住院、体检、随访数据彼此割裂。患者全生命周期管理要做的，是建立一个以患者唯一主索引（EMPI）为核心的主线：无论患者从哪个入口进入，都能归并到同一个人；无论发生多少次诊疗事件，都能按时间轴还原其健康轨迹。

因此，PLM 的最小管理单元不是“一次就诊”，而是“一名患者 + 一条时间轴 + 一组可执行任务”。例如，一位 58 岁男性患者，因血糖升高首次到内分泌科就诊，随后经历门诊调药、住院并发症处理、出院随访、社区复查。平台需要把这条链路上的关键事件、指标、用药、随访计划和异常预警关联起来，而不是让医生在多个界面中手工拼接。

二、边界：管什么、不管什么

明确边界是平台工程能否落地的前提。患者全生命周期管理平台通常管以下内容：患者主索引与身份归并、诊疗事件时间轴、关键临床指标趋势、随访计划与执行状态、跨机构/跨科室任务流转、患者分组与风险分层、数据权限与审计。它不直接替代医院核心业务系统（HIS、EMR、LIS、PACS）的诊疗记录职责，也不应成为另一个“大而全”的电子病历。平台更像一层协调与编排层：从各业务系统获取事件与数据，形成患者主线，再把需要执行的任务推回业务系统或随访工具。

三、核心价值：从“记录”走向“连续管理”

PLM 的核心价值可以归纳为四点。第一，连续性：患者在不同时间、不同机构的数据能按人归并，减少重复检查和信息丢失。第二，可追踪：每一次随访、用药调整、异常处理都有状态和责任人，避免“计划了但没人执行”。第三，风险前置：通过指标趋势和规则引擎，把事后补救变为事前提醒，例如糖化血红蛋白连续两次升高时自动触发随访任务。第四，可度量：平台能统计随访完成率、失访率、异常闭环时间等指标，为科室管理和质量改进提供依据。

下面这张图展示了患者全生命周期管理平台的核心结构：左侧是患者进入平台的各类入口，中间是平台的主索引、时间轴、任务编排与规则引擎，右侧是面向不同角色的输出。它强调的不是线性流程，而是“多源接入—统一主线—多端协同”的结构关系。

四、平台化工程思维：从“做功能”到“做能力”

平台化工程思维与普通项目开发最大的区别在于：不是为某一个科室、某一次随访活动写一套专用功能，而是把共性能力沉淀为可复用的平台服务。具体来说，需要建立四种思维。

• 主数据思维：患者身份是全局主数据，必须统一管理。任何业务系统接入时，都要先解决“这个患者是谁”的问题，而不是各自维护一套患者表。
• 事件思维：把就诊、检验、用药、随访等视为不可变事件，按时间追加写入患者时间轴。事件一旦产生，不轻易修改，保证轨迹可追溯。
• 编排思维：平台不直接完成所有业务动作，而是定义“什么条件下、由谁、在什么时间、完成什么任务”，把任务分发给合适的执行端。
• 度量思维：平台能力是否有效，要用随访完成率、异常闭环时长、失访率等指标衡量，而不是只看功能是否上线。

五、一个可参考的落地判断示例

假设某医院希望上线“糖尿病出院患者随访”场景。按照平台化思路，不应直接开发一个“糖尿病随访模块”，而应先拆解为平台能力：患者主索引归并出院患者；从 EMR 获取出院诊断、用药和出院时间；规则引擎根据糖化血红蛋白和出院医嘱生成 1 周、1 个月、3 个月随访任务；任务推送到随访护士工作台和患者端；患者上报血糖后写回时间轴；若连续两次空腹血糖高于设定阈值，自动升级为异常任务并提醒医生。这样，同一套主索引、时间轴、任务编排和规则引擎，后续可以复用到高血压、术后康复等场景，而不是每个病种重新建设。