作者：杭州沐昀科技有限公司技术团队 阅读对象：验证与 CSV 工程师、QA 数据完整性负责人、微生物实验室与 QC 判读人员、IT/OT 与设备工程人员，以及正在上线"自动判读型生物指示剂培养阅读器"或"BI 电子记录系统"的无菌保障团队
过去，生物指示剂（BI）的判读是一支一支看颜色、一笔一笔签名的动作，它的"计算机化"程度几乎为零，因此也几乎从不进入计算机化系统验证（CSV）的视野。现在不同了：荧光型快速 BI 的阅读器会自动给出阴/阳结论，培养箱开始联网上传温度曲线，BI 的批号、培养起止时间、判读结果被写进 LIMS 或 MES，审计追踪取代了纸质签名。当判读结论由软件而不是由人给出，这个结论就从"观察记录"变成了"由计算机化系统产生的数据"——它必须像其他 GMP 数据一样被验证、被追溯、被复核。
但在实际项目里，最常见的一幕是：CSV 文件包做得漂亮，URS、风险评估、IQ/OQ/PQ、追溯矩阵一应俱全，检查员却仍然开了缺陷项。原因往往不是文件缺失，而是验证的对象错了——他们证明了"软件能安装、能登录、能出报告"，却没有证明"这支 BI 是阳性时它一定报阳性、是阴性时它一定报阴性、并且它给出的结论可以被人独立复核"。前者是 IT 的事，后者才是灭菌验证的事。
本文要讲清楚三件事：BI 相关系统该怎么按 GAMP 5 分类、自动判读系统的验证要证明什么（以及它为什么不能替代微生物学的方法学验证）、电子记录与审计追踪在 BI 场景下的具体落点。核心结论先说：CSV 证明的是"系统可靠地产出结论"，方法学验证证明的是"这个结论在微生物学上成立"；两者是两条腿，缺一条就站不住。
一、先划边界：BI 流程里哪些东西算"计算机化系统"
CSV 项目最容易走偏的第一步，是把边界划得太大或太小。划太大，把培养箱、阅读器、LIMS、灭菌柜 PLC 全塞进一个验证包，最后每个都只验了个皮毛；划太小，只验了"阅读器软件"，却漏掉了它依赖的时间源、账号体系与结果去向。判断标准其实很朴素：凡是会创建、修改、保存、传输或删除 GMP 记录的部分，都在边界内；纯粹的物理过程（培养、灭菌）不在 CSV 边界内，但它产生的数据接口在。
| BI 流程环节 | 典型载体 | 是否属计算机化系统 | CSV 关注点 |
|---|---|---|---|
| BI 选型与批号登记 | LIMS / ERP / Excel | 是（Excel 若用于 GMP 记录需按受控方式管理） | 字段完整性、批号唯一性、与 COA 的关联 |
| 培养箱温控 | 独立温控器 / 带数据记录的培养箱 | 部分是（有电子记录与报警的即为是） | 温度记录采样间隔、报警延迟、数据导出不可篡改 |
| 判读（人工目视） | 人眼 + 纸质/电子记录 | 否（记录载体是） | 记录模板、双人复核、更正留痕 |
| 判读（自动阅读器） | 荧光/图像/颜色识别阅读器 + 软件 | 是（核心） | 算法判定、阈值管理、结果可复核性 |
| 结果传输与归档 | LIMS / MES / 中间件 / 共享目录 | 是 | 接口验证、传输完整性、失败重传与队列 |
| 趋势分析与 APR | 统计软件 / BI 报表 | 视用途而定 | 若用于放行或趋势判定则为是；仅辅助分析需说明 |
一个常被忽略的点：时间源。BI 判读的合法性高度依赖"培养起始时刻"与"判读时刻"这两个时间戳。如果阅读器、培养箱、LIMS 三者的时钟各自漂移，或者允许操作员手工改系统时间，那么"培养了 7 天"这句话在数据上是无法成立的——这是审计追踪缺陷里最高频的一类，也是最容易被检查员一句话问倒的一类。系统边界里必须明确：时间由谁提供、是否与 NTP 同步、是否禁止手动改时、改时是否留痕。
二、GAMP 5 分类：把 BI 场景落进软件类别
GAMP 5 第 2 版（2022）虽然在措辞上弱化了"按类别决定验证工作量"的机械做法，强调基于风险和批判性思维，但软件类别的划分在实践中依然是沟通与裁剪的共同语言。对 BI 场景，分类的结果直接决定了你要写多少文件、做多少测试。
| 类别 | 定义 | BI 场景中的典型例子 | 验证策略 |
|---|---|---|---|
| 类别 1 | 基础设施软件（操作系统、数据库引擎、虚拟化、备份） | Windows / SQL Server / 虚拟机平台 | 不单独做应用级验证，通过配置基线、补丁管理与供应商支持记录控制 |
| 类别 3 | 不可配置的商用成品软件（COTS） | 固定算法的荧光阅读器固件、只输出 PDF 的记录仪软件 | 基于供应商测试证据 + 使用场景的功能确认，重点在"用对了没有" |
| 类别 4 | 可配置的商用软件 | 可设判读阈值/培养时长的阅读器软件、可配置的 LIMS 模块 | 配置项逐条验证（这是 BI 场景的主战场），配置清单与版本冻结 |
| 类别 5 | 定制开发的应用 | 自研的 BI 结果自动汇总/趋势看板、与 MES 的定制接口 | 完整生命周期：需求、设计、代码评审、单元/集成/系统测试 |
最需要提醒的是类别 4 的"配置即验证对象"。同一款阅读器，A 厂用默认阈值、培养 7 天；B 厂把阈值调紧、培养 48 h 判读——这两套配置实际上是两个不同的"判读方法"，B 厂的验证不能引用 A 厂或供应商的通用验证报告。凡是能改变"阴/阳"结论的参数，都是必须被冻结、被验证、被变更控制的参数，包括但不限于：荧光阈值或颜色差异判据、判读时间点（单点/多点）、培养温度上下限与超温处理逻辑、阳性自动锁定的时间窗口、复核（二次判读）是否强制。
另一个实务细节：固件也是软件。快速 BI 阅读器的核心判定常写在固件里，用户界面上看不到任何可配置项，于是很容易被当成"黑盒硬件"跳过验证。正确姿势是把它当作类别 3 处理：索取固件的版本号、发布说明与算法变更记录，验证"当前固件版本 + 当前 BI 型号"这一组合，并在变更控制里把固件升级列为触发再评估的事件（详见第七节）。
三、自动判读系统的核心：把"图像"变成"结论"的那一段
人工判读时，判读员看的是培养基的颜色或荧光强度，凭经验与对照管比较；自动判读时，这一判断被替换成一条判定规则。这条规则通常长这样：在培养到 t 时刻，测量荧光信号（或颜色差值 ΔE），与阈值 T 比较，超过则判阳，未超过则判阴。看上去只是一个不等式，实际上它藏着四个必须被验证的环节。需要先说明的是，自动化判读在 BI 领域并不是"要不要上"的问题，而是"上了之后可靠性由谁来背书"的问题——技术演进路径本身见 数字化与自动判读专题。
环节一：测量的稳定性
同一个样本、同一台设备、连续测三次，读数应当一致到可接受范围内；不同孔位、不同批次试剂、不同环境光（对图像型阅读器）也应一致。这属于系统的重复性与再现性，通常用已知阴性/阳性样本做多水平重复测试。要注意的是：对荧光型 BI，信号会随培养时间单调增长，因此重复性测试必须固定在同一个培养时长上做，否则测的是动力学而不是重复性。
环节二：阈值的来历
阈值不是一个可以"用默认值"的参数。它应当来自方法学验证：用一组已知菌量（含接近检出限的低菌量）的样本，测出阳性分布与阴性分布，再选一个把两者分开的切点。阈值定在哪里，直接决定了假阳性率与假阴性率的取舍——把阈值调低（更易判阳），假阴性少了，但假阳性多了；调高则相反。对无菌保障而言，两者的代价并不对称：漏判一个真阳性（假阴性）可能导致污染产品放行，误判一个阴性为阳性（假阳性）则引发一次偏差调查。这个取舍必须由 QA 与微生物室共同书面确认，而不是由设备工程师在安装时"调到一个看起来合适的值"。
环节三：结论的可复核性
这是 CSV 检查中最容易被追问的一点。系统给出"阳性"之后，人还能不能独立复核？如果系统只存一个最终结论、不存原始信号（荧光值、图像、曲线），那么复核就变成了"相信软件"，一旦结论被质疑，企业拿不出任何可以重新判断的原始数据。合规的做法是：原始测量值、判读时刻、所用阈值、软件版本、操作员、样本标识，六项一并留档，并且原始值在保存期内不可被覆盖。这也是数据完整性里"原始记录（original record）"要求的具体化。
环节四：与人工判读的一致性
自动化替代人工，必须证明"替代得上"。做法是用一批样本（覆盖真阳性、真阴性、以及弱阳性/亚致死这种边界样本）同时做自动判读与人工判读，计算一致率；对二分类结果，建议用 Kappa 系数而不只是"符合率"——因为当阳性率很低时（BI 阴性占绝大多数），符合率天然很高，90% 的符合率可能只反映"阴性都判对了"。边界样本的处理尤其关键：弱阳性是自动判读最容易出错、也是微生物学上最有意义的一类（亚致死损伤复苏慢、信号出现晚），若系统在固定时间点判读，就可能把"还没长起来"误判为阴性。
| 验证环节 | 要证明的命题 | 典型方法 | 常见缺陷 |
|---|---|---|---|
| 测量稳定性 | 同一条件下读数可复现 | 同一样本多次测量、多孔位/多批次比对 | 未固定培养时长，把动力学差异当成重复性差 |
| 阈值合理性 | 阈值能把阳性与阴性分开 | 已知菌量梯度样本，绘制阳/阴分布，确定切点 | 沿用出厂默认值，无本实验室数据支持 |
| 可复核性 | 结论可被第三方独立重判 | 原始信号留档抽查、盲样复核 | 只存结论不存原始值 |
| 与人工一致性 | 自动化结论不劣于人工 | 双盲平行判读，计算一致率与 Kappa | 样本全是强阳性/强阴性，未覆盖边界样本 |
| 阴性对照 | 未接种 BI 不产生假信号 | 每批随行阴性对照，跨培养周期观察 | 对照管与样本管不同批试剂或不同孔位条件 |
四、系统验证与方法学验证：两条腿，不能互相顶替
这是本文最想强调的一节。BI 自动判读这件事，横跨两个完全不同的专业领域，各自有各自的一套证据，而项目里最常见的错误就是拿一套去顶另一套。
| 维度 | 计算机化系统验证（CSV） | 方法学验证（微生物学） |
|---|---|---|
| 回答的问题 | 这套系统是否按预期稳定运行、数据是否可信可追溯 | 这个判读方法能否正确区分阳性与阴性、检出能力如何 |
| 主要依据 | GAMP 5、EU GMP Annex 11、21 CFR Part 11、中国药品记录与数据管理要求 | ISO 11138 系列、ISO 14161、中国药典 2025 通则（灭菌法/微生物检定）、ISO 11138-8（RIT） |
| 典型输出 | URS、风险评估、IQ/OQ/PQ 报告、追溯矩阵、配置清单 | 检出限、重复性、耐用性、与参考方法比对、边界样本表现 |
| 执行者 | 验证/IT/工程，QA 审核 | 微生物实验室，QA 批准 |
| 变更频率 | 软件版本、配置、接口变更时 | BI 品牌/型号、培养基批次体系、培养条件变更时 |
| 失效后果 | 数据不可信、无法追溯、审计缺陷 | 结论错误：漏判阳性（放行风险）或误判阳性（偏差成本） |
两者的衔接点只有一个，但非常关键：方法学验证确定的参数（阈值、培养时长、判读时点），必须通过 CSV 的配置管理被"锁住"。方法学验证说"7 天判读、阈值 T"，CSV 要保证"系统里就是 7 天、就是 T，任何人改不了，改了有记录"。反过来，CSV 做得再完美，也不能证明 T 这个数字是对的——那是微生物学的事。
一句可以拿去回答检查员的话："我们有两份报告。一份证明这个判读方法在微生物学上成立（检出限与边界样本表现），一份证明这套系统忠实执行了该方法且数据完整可追溯（配置冻结与审计追踪）。两份报告互相引用，但不能互相替代。"
还有一层容易被忽略的交叉：缩短培养时间（RIT）。快速 BI 的价值就在于把 7 天压到 24–48 h，而这个"压缩"本身需要专门的确认——证明在缩短的时间点判读，不会漏掉那些复苏慢的亚致死芽孢（ISO 11138-8 给出了 RIT 的确认框架）。在系统层面，RIT 表现为一个软件参数（判读时点）；在方法层面，它是一个需要数据支撑的科学结论。把 RIT 当成"在软件里把 168 小时改成 24 小时"，是这个领域最危险的一类误操作（快速 BI 与传统 BI 的取舍逻辑见 快速 BI vs 传统 BI；判读方法本身的验证要点见 判读方法的方法学验证）。
五、电子记录与数据完整性：ALCOA+ 在 BI 场景的落点
ALCOA+ 这九个字母在培训里被念过无数遍，但在 BI 系统里究竟落在哪个按钮、哪个字段上，往往说不清。下面把它逐条对应到具体功能。
| 原则 | 在 BI 系统中的具体落点 | 检查时常见的追问 |
|---|---|---|
| 可归属 Attributable | 每条记录绑定唯一账号（禁止共用账号）、操作员与复核人分离 | "这个账号有三个人在用吗？" |
| 清晰可溯 Legible | 原始信号与结论同屏可查，导出件含全部字段 | "导出的 PDF 里为什么没有荧光值？" |
| 同步 Contemporaneous | 时间戳由系统自动生成，不可回填、不可手改 | "培养起始时间是谁填的？能改吗？" |
| 原始 Original | 原始测量值保存，不以截图/二次整理件替代 | "这个 Excel 是从系统导出的，还是手工录的？" |
| 准确 Accurate | 计算与判定逻辑经 OQ 验证，边界值测试覆盖 | "阈值 ±1 个单位时系统怎么判？测过吗？" |
| 完整 Complete | 删除/作废为逻辑标记，不物理删除；中断记录保留 | "中途停电那次的记录在哪？" |
| 一致 Consistent | 时间格式、单位、批号规则全系统统一；与其他系统时钟同步 | "阅读器和 LIMS 的时间差多少？" |
| 持久 Enduring | 保存期覆盖产品效期 +1 年（或按法规要求），介质迁移有验证 | "十年后这些数据还读得出来吗？" |
| 可获得 Available | 授权人员可随时调阅，审计期间可快速检索 | "现场调一份两年前的 BI 记录看看？" |
审计追踪（audit trail）是这一节的硬核部分。合规的审计追踪要满足四条：由系统自动生成、用户不能关闭或编辑、记录"谁/何时/做了什么/原值是什么"、与记录同等保存期。在 BI 场景里，必须被追踪的动作至少包括：判读结果的创建与修改、阈值的查看与修改、培养参数的修改、结果的手工录入或覆盖、记录作废与重新激活、数据导出、账号与权限变更。特别提醒：只记录"结果被改了"而不记录"改前的值"，等于没有追踪——这条在检查中几乎是一击必中。
电子签名方面，若系统用于 GMP 决策（如放行判定），签名应满足：签名与记录永久绑定、包含签名人姓名/时间/含义（审核、批准）、签名后记录不可再被无痕修改。中国 GMP 附录《计算机化系统》与《药品记录与数据管理要求（试行）》的取向与 EU GMP Annex 11、21 CFR Part 11 基本一致，但在"混合记录"（纸质+电子并存）场景下的要求更强调一致性：不能出现"电子系统里有原始值，纸质记录上写的是另一个结论"这种双轨。BI 记录体系怎么把纸与电子缝起来，见 SOP 与记录体系；数据完整性的整体框架见 数据完整性 ALCOA+ 专题。
六、验证生命周期：从 URS 到定期回顾的实际做法
BI 判读系统的验证不该被做成一次性的"上线考试"，而应是一条闭环。下面这条链是可落地的顺序，每一步的产出都是下一步的输入。
| 阶段 | 关键动作 | 产出文件 | BI 场景的特别提示 |
|---|---|---|---|
| 需求 URS | 写清"必须能做什么"，含数据完整性要求与判读功能要求 | 用户需求说明 | 必须写明：原始信号留存、阈值不可由操作员改、培养时长锁定 |
| 风险评估 | 按对产品质量的影响定验证深度（GxP 影响 + 功能风险） | 风险评估报告 | 判读与结果传输为高风险；报表美化类为低风险 |
| 供应商评估 | 评估其质量体系、算法变更通知机制、版本支持周期 | 供应商评估/审计记录 | 重点问：算法升级会不会改变历史数据的判读？会不会通知我？ |
| 设计/配置 | 配置清单冻结，参数来源可追溯至方法学验证报告 | 配置规格与清单 | 每个阈值旁标注"依据文件编号" |
| IQ | 安装正确性：版本、组件、环境、时钟源、备份 | IQ 报告 | 记录固件版本，纳入基线 |
| OQ | 功能正确性：判定逻辑、边界值、权限、审计追踪、报警 | OQ 报告 | 用已知样本做端到端判定，而不只是点按钮 |
| PQ | 实际使用条件下连续运行，与人工判读平行比对 | PQ 报告 | 必须覆盖边界样本与阴性对照 |
| 追溯矩阵 | URS 每条要求 → 测试用例 → 结果，双向可查 | 追溯矩阵 | 不留"未覆盖"项，或说明理由并做风险接受 |
| 放行使用 | 培训、权限开通、SOP 生效、变更控制上线 | 放行说明 | 培训记录要覆盖"异常时怎么办" |
| 定期回顾 | 按周期回顾：变更、偏差、审计追踪抽查、备份恢复演练 | 周期性回顾报告 | 与 APR 联动，把 BI 结果趋势一并看（见 APR 专题） |
关于 OQ 的边界值测试，值得多说一句。判定逻辑的不等式在边界附近最脆弱：信号恰好等于阈值时判什么？连续两次测量跨阈值怎么办？样本在判读窗口之外才出现信号，系统是忽略还是回看？这些都必须有明确的、被测试过的规则。没有测过边界值的 OQ，等于没有测判定逻辑。
七、变更与再验证：最容易被漏掉的五类触发
系统上线后，真正的风险才刚开始。以下五类变更在 BI 场景中极常见，却经常被当成"小改动"直接放行。
| 变更类型 | 为什么危险 | 建议的评估动作 |
|---|---|---|
| 软件/固件升级 | 判定算法可能被"优化"，历史结论与新结论口径不一致 | 索取发布说明与算法变更声明；重跑边界样本；必要时做并行期 |
| 判读阈值调整 | 直接改变假阳/假阴平衡，等于换了一个方法 | 回归方法学验证（至少边界样本 + 一致率）；QA 书面批准 |
| 更换 BI 品牌/型号 | 荧光动力学、初始信号本底不同，原阈值未必适用 | 新老 BI 平行测试；确认阈值与判读时点；更新配置基线 |
| 培养基/试剂批次体系变更 | 生长促进与信号强度变化，影响弱阳性表现 | 批次验收 + 生长促进试验（判读条件的整体要求见 培养基与培养判读）；观察是否需调阈值 |
| 接口或数据库迁移 | 字段截断、时区错位、精度丢失，数据"看起来在"其实已失真 | 迁移前后逐字段比对；抽样回读；保留迁移前只读副本 |
第五类值得单列：数据库或平台迁移。很多"数据完整性"缺陷不是发生在使用期，而是发生在系统换代时——旧系统的数据被导出成 CSV 或 PDF，字段丢了、时间戳变成字符串、审计追踪整段消失，企业却认为"数据已经归档"。正确做法是：迁移前做只读快照，迁移后做逐字段比对与抽样回读，并把"迁移后数据仍可检索、仍能重现原判读"作为验收条件写进方案。
八、八类高频缺陷与审计现场问答
以下八类是 BI 自动判读与电子记录系统在检查中最常见的发现项，按出现频率排列。
| # | 缺陷描述 | 根因 | 纠正方向 |
|---|---|---|---|
| 1 | 审计追踪可被管理员关闭或删除 | 系统默认允许，未在配置阶段关闭 | 配置锁定 + OQ 验证"无法关闭" |
| 2 | 只保存判读结论，不保存原始信号 | 把"结果"当"数据" | 开启原始值留存；导出模板补字段 |
| 3 | 账号共用、无唯一性 | 人手不足或嫌麻烦 | 一人一号；离职即时停用；定期复核权限 |
| 4 | 时间戳可手工修改或与 NTP 不同步 | 未把时间源纳入验证范围 | 强制 NTP；禁改时；改时留痕 |
| 5 | 阈值沿用出厂默认，无本实验室数据 | 把方法学问题当设备设置 | 补做阈值确认并纳入方法学验证报告 |
| 6 | 系统验证报告引用供应商通用报告，无场景化测试 | 把类别 4 当类别 3 处理 | 补配置项逐条测试 |
| 7 | 异常/中断记录缺失（停电、卡板、中途取出） | 系统只记录成功路径 | 补异常场景测试；SOP 规定补记与评估 |
| 8 | 备份做了但从未做过恢复演练 | 把"有备份"当"可恢复" | 定期恢复演练并留记录 |
审计现场最容易被问倒的三个问题，建议提前准备答案：
① "这套系统判出阳性，你们的人还会再看一遍吗？看的是什么？"——答案应包含：复核原始信号、复核培养条件、必要时做菌种鉴定（阳性调查的完整逻辑见 阳性调查与偏差处理）。
② "阈值是谁定的？依据是什么文件？"——答案应指向方法学验证报告的具体章节，而不是"厂家推荐"或"一直这么用"。
③ "如果我今天把软件升级了，昨天的结论还作数吗？"——答案应说明算法变更的评估机制与历史数据的处理方式。
九、落地清单与结论
下面这份清单可以直接拿去对照现有系统，逐条打勾。
- 系统边界是否书面划定，并明确包含时间源、账号体系、接口与归档？
- 软件类别是否判定，类别 4 的配置项是否逐条验证并冻结？
- 固件版本是否记录在基线中，升级是否纳入变更控制？
- 每个判读阈值旁，是否标注了方法学验证报告的编号与章节？
- OQ 是否做了边界值测试（等于阈值、跨阈值、窗口外信号）？
- 原始信号（荧光值/图像/曲线）是否与结论一同留存，保存期是否覆盖要求？
- 审计追踪是否覆盖阈值修改、结果覆盖、记录作废、数据导出，且记录原值？
- 账号是否一人一号，复核人与操作人是否分离，权限是否定期复核？
- 时钟是否与 NTP 同步，改时是否留痕并禁止普通用户操作？
- 是否做过与人工判读的双盲比对，并覆盖弱阳性/边界样本？
- 停电、卡板、中途取出等异常路径是否有记录与评估规则？
- 备份是否做过恢复演练，演练记录是否可查？
- 定期回顾是否把 BI 结果趋势、偏差、变更、审计追踪抽查合并审视？
结论一句话：BI 的数字化把"看一眼"变成了"算一下"，这既是效率的跃升，也是责任的转移——当结论由软件给出，企业就必须同时具备两套能力：证明软件忠实执行了方法（CSV），以及证明方法本身经得起推敲（方法学验证）。只做前者，系统很漂亮但结论不可信；只做后者，方法很扎实但执行不可控。而真正让检查员信服的，往往不是厚厚的文件包，而是那句能脱口而出的回答：这个阈值来自哪份报告，这个结论谁能复核，这条记录改过没有。
法规依据说明：本文涉及的主要文件包括 GAMP 5（ISPE 良好自动化生产实践指南第 2 版，2022）、EU GMP Annex 11（计算机化系统）、EU GMP Annex 15（确认与验证）、21 CFR Part 11（电子记录与电子签名）、中国 GMP（2010 年修订）附录《计算机化系统》与附录 1 无菌药品、《药品记录与数据管理要求（试行）》（2020）、中国药典 2025 年版通则（灭菌法、微生物检定相关通则）、ISO 11138 系列（生物指示剂通用要求及各分部）、ISO 11138-8（缩短培养时间生物指示剂的确认）、ISO 14161（生物指示剂选择、使用与结果解释指南）、ISO 13485 与 ISO 14971（若涉及器械体系）、PDA TR-33 / TR-80（计算机化系统与数据完整性参考）。文中阈值、周期与频次为行业常见实践口径，具体应以设备制造商说明书、企业验证方案及所适用法规的规定为准；本文不替代法规原文，也不构成对特定系统或工艺的合规判定。
版权声明：本文由杭州沐昀科技有限公司技术团队原创，著作权归本公司所有。欢迎基于非商业学习目的的引用与转载，但须注明出处（杭州沐昀科技有限公司 www.muyon.cn）并保持内容完整；未经书面授权，不得用于商业用途、不得摘编改写后二次发布。
客服1