2. 样本追踪系统架构设计
样本追踪系统不是一张“记录表”，而是一条贯穿样本全生命周期的数据链。它的核心任务只有一句话：在任何时刻，都能回答“这个样本是谁、从哪来、现在在哪、经历过什么、下一步该去哪”。要做到这一点，系统必须在架构上把物理样本与数字记录一一绑定，并在接收、存储、处理、废弃四个阶段持续写入可追溯的事件。
一、端到端追踪框架的四个阶段
从架构视角看，样本追踪可以拆成四个物理阶段，每个阶段对应不同的数据写入动作：
- 接收（Receive）：样本到达实验室，登记来源、类型、数量、到达时间与状态（如冷链是否完整）。此阶段生成或绑定 UID，并记录“接收事件”。
- 存储（Store）：样本被放入冰箱、液氮罐或暂存架，系统记录位置坐标（设备—层—架—盒—孔）与存储条件（温度、湿度）。
- 处理（Process）：样本被分装、提取、扩增、测序或消耗，系统记录“母样本—子样本”的派生关系、操作人、试剂批次与时间戳。
- 废弃（Discard）：样本被灭活、销毁或移交，系统记录废弃原因、方式、执行人与审批人，并保留历史记录不可删除。
这四个阶段不是线性走完就结束，而是可能反复循环：一个样本可以多次分装、多次存储、多次处理，最终才进入废弃。因此，追踪框架必须支持事件追加，而不是覆盖式修改。
二、UID 体系：让每个样本有唯一身份
UID（Unique Identifier）是追踪系统的锚点。设计 UID 时，需要同时满足三个条件：全局唯一、可读可解析、与物理标签一致。常见的做法是采用分段编码，例如：
BF-2025-06-00123-A01
│ │ │ │ │
│ │ │ │ └─ 子样本序号（A01 表示第一次分装的第 1 管）
│ │ │ └─────── 当日流水号（00123）
│ │ └─────────── 月份（06）
│ └──────────────── 年份（2025）
└──────────────────── 机构/项目前缀（BF = Biofoundry）
这种编码的好处是：人眼能快速读出时间与批次，系统也能通过正则解析出字段。对于子样本，建议采用“母 UID + 派生后缀”的方式，而不是重新生成一个完全无关的编号。这样，任何子样本都能通过字符串截断回溯到母样本。
物理层面，UID 通常以二维码或 RFID 标签承载。二维码适合单管、冻存管；RFID 适合整盒、整架批量读取。无论哪种载体，都必须保证标签与数据库记录在接收环节完成首次绑定，后续所有操作只引用 UID，不再依赖人工抄写。
三、数据模型：事件驱动的核心表结构
追踪系统的数据模型应围绕“样本实体 + 事件日志”来设计，而不是把所有字段塞进一张宽表。推荐的核心实体包括：
- Sample（样本实体）：UID、类型、来源、母样本 UID、当前状态、创建时间。
- Event（事件日志）：事件 ID、UID、事件类型（接收/存储/处理/废弃）、时间戳、操作人、设备、参数 JSON。
- Location（位置）：设备 ID、层、架、盒、孔位，以及当前占用状态。
- Derivation（派生关系）：母 UID、子 UID、分装体积、操作类型。
其中，Event 表是只追加的（append-only）。任何状态变更都通过写入新事件来表达，而不是 UPDATE 旧记录。这样即使操作失误，也能通过事件回放还原历史。例如，一个样本从“存储”变为“处理”，不是修改 Sample 表的 status 字段，而是追加一条 event_type = "process_start" 的记录，再由系统根据最新事件推导当前状态。
四、架构分层与数据流
从系统架构看，追踪系统通常分为三层：采集层、服务层、存储与展示层。采集层负责扫码、RFID 读取、设备接口（如冰箱温度记录仪）；服务层负责 UID 生成、事件校验、权限控制与派生关系维护；存储与展示层负责持久化、履历查询与看板展示。
下面这张图展示了从样本接收到废弃的端到端数据流，以及 UID 在其中的绑定与传递关系：
五、关键设计原则与常见陷阱
在实际落地时，有几个原则值得反复强调：
- UID 一旦生成不可修改。如果标签损坏，应重新打印同一 UID，而不是生成新编号。
- 位置信息必须精确到孔位。只记录“在 -80℃ 冰箱”无法支持快速定位，必须细化到盒与孔。
- 派生关系要双向可查。既能从母样本查到所有子样本，也能从子样本回溯到母样本。
- 废弃不等于删除。废弃样本的记录必须保留，仅标记状态为 discarded，并记录审批链。
总结来说，样本追踪系统的架构设计可以归纳为：以 UID 为锚点，以事件日志为骨架，以位置和派生关系为两翼，覆盖接收、存储、处理、废弃四个阶段。只要这条数据链不断裂，样本的全生命周期就是可追溯、可审计、可复现的。