2. 全生命周期概述
做样本追踪系统，最怕的就是「盲人摸象」。
我见过太多项目，单个环节做得特别精细，结果上下游一对接，数据对不上、状态丢失、时间戳乱跳。说白了，根源都在于没把「全生命周期」这根线拎清楚。
这一章，我们就来捋一捋，一个样本从诞生到归档，到底经历了哪些关键节点。
为什么需要全生命周期视角？
你想想看，一个样本在医院里，可能被抽血、分装、运输、检测、复核、冻存。每个环节都有操作人、时间、设备、环境数据。如果每个环节各管各的，数据就是一座座孤岛。
我早期在改造某大型生物样本库项目时，就踩过这个坑。病理科的说「样本到了」，物流的说「还没签收」，两个系统吵了半年。后来我把所有节点串起来，才找到问题——他们用的样本ID根本是两套编码规则。
所以，全生命周期视角，就是要给每个样本一个统一的、可追溯的「数字旅程」。从它还在试管里那一刻，到最终变成冻存管入库，每一步都有记录、有签名、有状态切换。
核心流程概览
我把完整的生命周期拆成六大阶段。每个阶段都有明确的输入、输出和关键控制点。下面这个图，就是我常用的流程框架：
这张图看起来是直线，实际上每条边都可逆。样本不合格，要从「接收验收」退回到「样本采集」。系统设计时，别忘了留「回退」的接口。
各阶段详解
1. 检测申请
一切从这里开始。医生开医嘱、委托单，或者系统自动触发。
我认为这个阶段最容易被忽视的是「前置条件检查」。比如某些样本需要空腹采集，有些要特殊容器。如果申请时没填，后面采集员得打电话问，耽误时间。
一个规范的系统，应该在申请时就锁定：样本类型、采集要求、运输条件、预计检测项目。
2. 样本采集
这是物理实体的诞生点。采样人员拿到空管，核对信息，采集，马上贴条码。
我建议这里采用「先打印条码，后采集」的流程。为什么？因为贴好码的管子一旦离开视线，就有混淆风险。我曾经见过一位护士先采了血，再去找标签，结果搞混了两份——后来全靠系统里的时间戳比对才纠正过来。
采集记录至少应包含：
- 样本ID（全局唯一）
- 患者/受检者ID
- 采集时间（精确到秒）
- 采集人（工号+姓名）
- 采集部位/方式
- 样本类型（血、尿、组织……）
- 原始容器条码
# 一个典型的采集记录 JSON
{
"sample_id": "SMP-20250317-001234",
"patient_id": "P202403001",
"collection_time": "2025-03-17T08:32:15.000Z",
"collector": "nurse_zhang",
"site": "左肘静脉",
"type": "全血",
"container_barcode": "TUBE-882302"
}严禁在采集环节使用「手工录入」替代「扫码」。手工输条码，错误率随疲劳指数线性上升——这可不是开玩笑，我在医院实测过，夜班时手工录入错误率高达4%。
3. 接收验收
样本从采集点运到实验室/检测中心。交接是最容易出问题的环节。
我做过一个统计：停摆事件中，有37%是因为「接收方没收到，发送方以为已送达」。所以我的系统里一定有个「签收」动作，接收员扫码那一刻，状态从「运输中」变为「已接收」。
验收时重点检查：
- 条码是否清晰、可读
- 样本量是否足够
- 有无溶血、凝块、污染
- 运输温度是否合规（冷链的话要看记录仪）
不合格样本直接标记「退样」，系统触发退回流程，原路返回。
4. 检测处理
这个阶段内部又可以拆成很多子步骤：分装、离心、提取、上机检测等等。
嗯，这里要注意：有些系统把整个「检测处理」当作一个黑盒，只记录最终结果。我的建议是，至少要保留「分装」和「上机」两个子节点。因为如果后续发现数据异常，回溯到「分装时间」和「上机时间」，往往能定位问题。
如果做基因测序，还需要记录文库构建、质控、上机等更多子步骤。理论上每个步骤都可以生成子样本（比如一份血分装成三管DNA），这时候还要维护父子关系。
5. 结果复核
检测出数据后，不是直接发报告的。需要审核、复核、双签。
代码层面，一个样本在这个阶段的状态应该是：
状态枚举 (生命周期的阶段状态)
- PENDING_REVIEW 待审核
- REVIEW_PASSED 审核通过
- REVIEW_FAILED 审核不通过（退回重测或重新采集）
- REPORT_GENERATED 报告已生成
- REPORT_ISSUED 报告已发放我建议状态变更必须绑定「操作人签名」和「审核人签名」，二者不能是同一个人。这是最基本的分权原则，很多合规检查都会查这个。
6. 归档存储
报告发出后，样本去哪了？要么销毁，要么进冰箱、液氮罐、-80度超低温冰箱。
归档不是终点，而是另一个生命周期的起点。归档后，样本可以出库用于科研、回顾性检测、质控复查等。
一个完整的归档记录应该包括：
| 字段 | 说明 |
| 存储位置 | 冰箱号+架号+盒号+孔位 |
| 存储条件 | 温度/湿度/环境数据 |
| 入库时间 | 精确到秒 |
| 操作人 | 执行入库的人员 |
| 预期寿命 | 有效期或建议保存年限 |
| 剩余体积/数量 | 已消耗的记录 |
全流程数据模型
讲完流程，我一般会画一张数据表结构图。简单来说，核心模型只需要三张表：
sample_event
- event_id 事件ID（主键）
- sample_id 样本ID（外键）
- event_type 事件类型（采集、接收、检测、归档……）
- timestamp 事件发生时间
- operator_id 操作人
- operator_name 操作人姓名（冗余便于查询）
- location 发生地点（可选）
- metadata 扩展属性（JSON格式存放）
sample_state
- state_id 状态ID（主键）
- sample_id 样本ID（外键）
- state 状态值
- timestamp 状态变更时间
- operator_id 操作人
- is_current 是否当前状态（1/0）
sample_relation
- relation_id 关系ID（主键）
- parent_sample_id 父样本ID
- child_sample_id 子样本ID
- relation_type 关系类型（分装、提取……）为什么用事件表和状态表分开？因为「事件」是不可篡改的审计日志，「状态」是当前快照。一个样本可能经历10次状态变更，但事件表里记录了每一步，状态表只保留最新一条。这是追踪系统的基本设计模式。
关键设计原则
- 全局唯一ID：样本ID绝对不能重复，建议用「前缀+日期+自增序列」或UUID。
- 时间戳由服务器生成：别信客户端时间，不然一个跨时区的项目就能让你崩溃。
- 每次操作都要记录「谁+什么时间+做了什么」：审计需求早晚会来。
- 允许逆向流程：样本退回、作废、补采，都要有对应的状态和事件。
- 归档后保留只读访问：数据不能修改，但可以加「备注」或「勘误」。
全生命周期说起来简单，做起来全是细节。我个人习惯是先画一张「状态机图」，把所有可能的状态和转换条件都写清楚，再开始设计表和API。这样后面返工的几率会小很多。