1. 一句话答案
三条自动采集通道：RFID 标签绑定（绑定粒度可到单件器械）、灭菌设备数据（原始运行数据以 XML 结构入库，可还原灭菌温度曲线）、生物监测判读（独立服务对接阅读器，结果自动回写）。另有数字大屏汇总 20+ 运营指标。
2. 为什么这几条通道值钱
手抄是消毒供应中心差错的最大来源之一。它有三个特点：抄错不会被立刻发现、抄错之后无法还原当时的真实值、抄写的人往往不是最有判断力的人。
因此我们的判断很简单：凡是设备或标签自己能说的话，就不要让人说。
| 通道 | 替代了什么人工动作 |
|---|---|
| RFID 标签绑定 | 逐件核对包内器械清单时的目视与手工勾选 |
| 灭菌设备数据采集 | 灭菌后抄录温度/时间/压力，以及"大概合格"的口头判断 |
| 生物监测判读服务 | 把培养结果从阅读器转录到系统这一步 |
3. 三条通道分别怎么做
3.1 RFID 标签绑定
| 项 | 说明 |
|---|---|
| 绑定关系 | 标签与包 / 器械的对应关系单独建表 |
| 标签唯一性 | 标签值上带唯一索引——一枚标签不可能同时绑在两个器械上 |
| 绑定粒度 | 器械编号 + 包条码 → 到单件器械，不只是到包 |
到器械这件事为什么重要？ 包级追溯只能回答"这个包在哪"；器械级才能回答"这套器械里的某某持针器今天经过了什么处理"。外来器械清点、精密器械追踪、丢失定责，都要靠后者。
3.2 灭菌设备数据采集
| 项 | 说明 |
|---|---|
| 存储位置 | 设备数据里专门存原始运行数据的那一列（结构化文本，XML） |
| 数据形态 | 有标记区分：0 = 结构化文本，1 = 图片；图片形态另存一列 |
| 如何还原 | 库内有现成的读法直接解析这份结构化文本，取出每一行的阶段与温度 → 重建灭菌过程的温度曲线 |
| 设备自述错误 | 设备原生错误代码与错误文本原样留存 —— 设备自己报的错不会被过滤掉 |
| 预设参数 | 预设灭菌时间、预设灭菌温度 |
关键在于这是原始过程数据，不是一个被压缩过的结论。评审要求「还原数据路径」时，原始曲线的价值远高于一个"合格"印章。
3.3 生物监测判读服务
独立 Windows 服务形态的程序对接生物监测阅读器：
| 项 | 说明 |
|---|---|
| 形态 | 一个常驻的 Windows 服务（带安装组件，可注册成后台服务） |
| 动作 | 初始化阅读器 → 读取判读结果 → 回写系统 |
| 价值 | 消除「从阅读器到系统」这一段人工转录，同时消除转录带来的时间差 |
3.4 （附带）容器级绑定
| 记录项 | 含义 |
|---|---|
| 清洗架编号 | 一级容器：这批器械挂在哪个清洗架上 |
| 篮框编号 | 二级容器：具体放在哪个篮框里 |
| 绑定时间 | 什么时候绑的 |
| 清洗类型 | 1：手工清洗，2：机械清洗 |
| 清洗单号 / 清洗员 / 清洗时间 | 这次清洗的单号、责任人与时间 |
4. 数字大屏
独立于业务系统之外的前端项目：Vue 3 + ECharts 5 + SignalR（实时推送）。
指标由后端 DashboardLogic 的 20+ 个方法供给，包括：
| 组 | 指标（部分） |
|---|---|
| 当日核心 | 当日回收量、当日灭菌量、当日发放量、当前库存、加急待处理 |
| 环节在制/完成 | 待清洗、已清洗、待检查、待配包、待包装、待灭菌、已灭菌、待发放 |
| 质量三率 | 物理监测合格率、化学监测合格率、生物监测合格率、最近一次生物监测结果 |
| 趋势与不合格 | 周物理/化学趋势、当日不合格原因分布、月度不合格趋势 |
| 排行与预警 | 科室使用排行、实时流水、滚动预警、月度趋势、过期数量 |
前端组件包括 KPI 卡、环节流量监控、设备状态、质量监测、科室排行、实时流水、滚动预警、趋势图等。
大屏的作用是管理，不是装饰。 所有指标都来自同一套业务数据，不存在"大屏显示 A、系统里是 B"的情况。
5. 能力边界（必看，也是本页最诚实的一节）
| 项 | 实际状态 |
|---|---|
| 手持移动扫码设备（PDA） | 仓库内存在一个 Android 工程壳，但它只包含一个 Activity 与一个文本控件，不含任何 RFID 扫描或绑定逻辑；仓库中也没有任何打包产物或手持设备相关代码。因此我们不会宣称"自有 Android PDA"。 实际做法是：桌面读写器 + 打印条码 + 现有扫码设备；移动端如需定制（uni-app 形态），按项目评估。 |
| RFID 读卡器形态 | 现有能力集中在 .NET Framework 类库 + ReaderAPI.dll + USB 读卡器这一条路径上（桌面/工作台场景），不是 UHF 远距离批量群读的场景。若你需要的是「一秒钟盘完一车」那种远距离群读，需要先做标签与读写器的实地验证，我们不承诺这种能力已具备。 |
| 周转箱级绑定 | 无。当前容器绑定只有清洗架与篮框两级，没有周转箱这个概念。 |
| 设备数据的采集方式 | 走 XML/图片的存储与解析路径；未见 CSV 类采集通道。具体到你的设备型号能否对接，需按厂商开放能力评估。 |
这四条的共同点：都不是 "能不能做" 的问题，而是 "现在有没有" 的问题。 我们不拿"可以定制"冒充"已经具备"。
6. CTA
标题：把你的读写器和设备型号拿来，我们对一遍
副文：物联这块最容易翻车的就是"以为都能接"。演示前先告诉我你的设备型号与标签方案，能接的我会说能，要定制的我会说要多久。
- 主按钮：预约演示 →
/demo - 次链接：设备与灭菌数据相关另见 灭菌与监测。
FAQ（配 FAQPage JSON-LD）
Q1：你们有手持 PDA 吗？ A：没有。仓库里的 Android 工程只是一个空壳（一个 Activity、一个文本控件），没有任何扫描与绑定逻辑，也没有打包产物。现有 RFID 能力是 USB 读写器 + 桌面端的路径。如果你的场景必须要手持设备，属于按需定制项。
Q2：RFID 能一秒钟盘完一车器械吗？ A：这是 UHF 远距离群读的场景。我们现有验证过的能力不在这个形态上，不做这个承诺。可行做法是先验证标签与读写器的实际表现，再决定是否纳入方案。
Q3：绑定粒度到什么级别？ A：数据模型支持到单件器械（标签与器械的绑定单独记录），并且标签值上有唯一索引防止一枚标签重复绑定。实际能做到什么粒度，取决于标签粘贴方案与读取场景。
Q4：灭菌设备数据是所有品牌都能接吗？ A：取决于设备厂商是否开放数据输出与输出格式。现有实现是把设备原始数据按结构化文本（XML）或图片存入并在库内解析；具体到你的设备型号能否对接，需按厂商能力评估——我们不预先承诺品牌清单。
Q5：大屏是单独的收费项吗？
A：是的，属于可选模块。它读取的是同一套业务数据，不存在两套数据口径。报价见 /pricing 。