2. 仪器数据接入需求分析

仪器数据自动接入项目失败，很少是因为接口写不出来，而是因为一开始就没把“要接什么、接成什么样”说清楚。需求分析这一步的目标不是写一份好看的文档，而是把实验室里真实存在的仪器、它们吐数据的方式、数据被谁消费、受什么规则约束，逐条落到可验证的条目上。做完这一步，后面选采集方式、定字段映射、写解析脚本才有依据。

一、先盘清仪器资产，而不是先想接口

需求分析的第一手材料来自仪器台账，但普通台账往往只有名称、型号、位置，不足以支撑接入设计。需要补三类信息：通信能力（有没有网口、串口、USB、是否支持文件导出）、软件形态（工作站软件名称与版本、是否带数据库、是否允许二次开发或目录监听）、数据落点（结果存在软件数据库、导出为 PDF/CSV/TXT，还是只打印纸质报告）。

按数据产出方式，实验室仪器大致可分为四类，接入难度和策略差异很大：

• 文件型：如部分紫外分光光度计、水分测定仪，结果导出为 CSV 或 TXT，通常带固定表头。接入靠目录监听 + 解析。
• 数据库型：如多数色谱工作站（示例：某品牌工作站使用 SQL Server 或 SQLite 存储序列与结果），可通过只读账号查询结果表。
• 接口型：支持 HL7、ASTM、Modbus TCP 或厂商 SDK，可主动推送或应答查询，实时性最好。
• 打印/截图型：无数字出口，只能靠人工录入或 OCR，属于接入的“硬骨头”，需求阶段就要明确是否纳入首期范围。

盘点时建议逐台记录：仪器编号、所属检测项目、产出方式、单次运行时长、日均/周均批次数。这些数字直接决定后续采集频率和调度策略。

二、频率与时效：决定采集架构的关键参数

“多久采一次”不能拍脑袋。要区分三个概念：数据产生频率（仪器多久出一批结果）、业务可接受延迟（结果多久必须进 LIMS）、采集轮询周期（系统多久去取一次）。三者关系应满足：轮询周期 ≤ 可接受延迟，且不宜远小于产生频率以免空转。

例如某理化实验室：ICP-MS 每天约 3 批，每批 20 个样品，业务要求当天出报告，可接受延迟为 2 小时，则轮询周期设为 15 分钟足够；而某微生物鉴定仪每批培养需 18 小时，可接受延迟为 4 小时，轮询周期设为 30 分钟即可。若把两者都设成 1 分钟轮询，只会增加数据库压力，不带来业务价值。

三、合规要求：把法规条款翻译成字段规则

合规要求最终要落到数据字段和操作行为上，否则无法验证。常见来源包括实验室质量体系（如 ISO/IEC 17025）、行业规范（如 GMP 的数据完整性要求）以及客户合同。需要识别：

• 审计追踪：数据从仪器到 LIMS 的每次修改、重传、人工干预是否留痕，记录操作人、时间、原值、新值。
• 原始数据留存：原始文件（如色谱图、原始 CSV）是否必须与结果一并归档，保存期限多长。
• 电子签名：结果审核是否需要符合电子签名要求，接入数据是否携带仪器操作者标识。
• 数据完整性：是否要求 ALCOA+ 原则，即归属、清晰、同步、原始、准确，以及完整、一致、持久、可用。

这些要求会反向决定字段设计。例如要求“归属”，则每条接入记录必须带仪器编号、操作者、采集时间；要求“原始”，则需保存原始文件路径或哈希值，而不仅是解析后的数值。

四、LIMS 侧消费需求：数据进来之后给谁用

同一批仪器数据，在 LIMS 里可能被不同角色消费：检测员要看结果是否齐全，审核人要判断是否超限，报告模块要取值出报告，质量部门要做趋势分析。需求分析要明确每个消费场景需要的字段、精度和单位。

关键字段通常包括：样品编号（与 LIMS 委托单对应）、检测项目、结果值、单位、检出限、判定（合格/不合格/超限）、仪器编号、检测时间、操作者、原始文件引用。其中样品编号的匹配规则最容易出问题——仪器里可能是“20240612-001”，LIMS 里是“S240612001”，必须在需求阶段定义映射或清洗规则，否则接入后大量数据挂不上样品。

五、形成需求规格说明：可验证的条目化交付

需求规格说明不是散文，而是一组可逐条验证的条目。建议每条需求包含：编号、来源（哪台仪器/哪个角色）、需求描述、验收标准、优先级。下面给出一份可直接参考的示例片段，字段和取值均为教学示例，实际项目需按现场情况替换。

写完后要做一次“反向验证”：拿着每条需求去问对应的检测员或审核人——“如果系统这样表现，你能接受吗？”如果对方回答“差不多吧”，说明验收标准还不够具体，需要继续细化到可测量。需求规格说明的完成标志，是每一条都能被测试用例覆盖，而不是文档页数够多。

需求分析完成后，仪器类型决定了采集方式，频率决定了调度参数，合规要求决定了字段与留痕设计，LIMS 消费需求决定了映射与校验规则。这四类信息汇成需求规格说明，成为后续设计、开发和验收的共同基线。