匿名化声明
应客户要求，本案例不披露机构名称、域名与内网地址。文中所有数据均来自该项目生产环境的实际运行结果，可提供脱敏录屏与截图核验。 * 以下为单一消毒供应中心的生产运行数据，截至 2026 年 10 月。
1. 一句话答案
这套系统不是先有产品再找客户，而是反过来：由消毒供应中心的一线岗位人员把自己的日常工作讲清楚，我们把它写成代码，再回到岗位上被纠正、被推翻、被改掉。研发始于 2018 年，至今在同一个中心连续生产运行 5 年——期间的每一个修改，都是某个具体问题逼出来的。
2. 项目概况
| 项 | 数据 |
|---|---|
| 研发起始 | 2018 年 |
| 生产运行 | 5 年（截至 2026 年 10 月） |
| 接入外院机构与科室 | 929 家 家 |
| 在管包种类 | 16128 |
| 在管条码 | 708310 |
| 年增长率 | 约 20% |
| 组织形态 | 区域化消毒供应中心（对外服务多家医疗机构） |
* 以上为单一消毒供应中心的生产运行数据，截至 2026 年 10 月。
3. 五个真实难点，以及它们如何变成了字段
这一节是案例页的核心。每一条都不是"需求"，是当时真的卡住了。
3.1 一炉混装：数据结构必须重做
卡在哪：区域化中心的灭菌器一天要处理多家客户的包。最早的做法是想办法区分"这锅是谁的"，但物理上一锅就是一锅，装进去的六家医院谁也不比谁多。
怎么解的：把物理层与商务层分开——灭菌批次不含机构字段，客户维度落在回收明细上。想要知道锅里有哪些客户的包，就按批次下钻；想知道某客户的包在哪一锅，就按机构上溯。
代价：初期看这个设计很别扭（查个"谁的锅"要多跳一层），五年下来证明它是对的——如果当初把「所属机构」直接写在灭菌批次上，规模化之后只能拆批次或者丢客户维度，那才是真的改不动。
3.2 同一个包，三百种叫法
卡在哪：标准字典里叫"A 包"，A 医院叫它"a"，B 医院叫它"甲型"，C 医院按自己的编号叫。强行统一名称，客户不干；给每家复制一套字典，标准就废了。
怎么解的：字典只有一套，显示名走三级回落——机构 + 科室 → 机构 → 字典默认。
📌 一个附带教训：这张显示名表的「机构」字段，源码注释里写的是"外院标识"。这个注释是误导的，本院也在用。它的真实语义是「某机构的某科室看到这个包时显示什么名字」。我们是在一次对接时才发现这个注释不对的。
3.3 调价不能重算上个月的账
卡在哪：客户合同一年一签，价格每年调。定价挂在字典上时，一改价，历史单据跟着变，上个月的对账单和发出去的发票对不上。
怎么解的：一客户一张价格表管当期定价，实际成交的折后价固化到回收明细上。
3.4 预约取包：一个只有并发才会暴露的 bug
卡在哪：外部机构在线预约取包，规则是「同一机构同一天只能有一条未结束预约」。最初在应用层做"先查后插"，正常情况下没问题——直到两家在同一个毫秒点提交，两个请求都查到"今天还没有预约"，于是双双放行。
怎么解的：把判定下沉到数据库，建一个只对未结束记录生效的筛选唯一索引：
约束建在「机构 + 预约日期」上，只对未结束的那一条生效， 并发去重由数据库把住，应用层不再做「先查后插」。
这个故事我们讲了很多次，因为它最能说明"深耕"的含义——不是年限，是踩过的坑。没真跑过几百家机构，写不出这条索引。
3.5 外来器械：责任必须能分开
卡在哪：外来器械跟着急诊手术走，时间紧，流程最容易跳步。出问题时最常见的结果是"大家都碰过，谁也说不清"。
怎么解的：接收、清洗、包装、核对四个岗位各自记名（不是一个人签全过程）。植入物在三个地方独立标记。紧急情况允许提前放行，但必须留下放行医生、授权人、原因、依据的完整授权链。
需要如实说明的一点：这四个岗位目前只有人名，没有各自独立的签署时间戳。若本地评审细则要求分环节时间戳，属于可定制增强。
4. 一天是怎么跑的
| 时点 | 在发生什么 |
|---|---|
| 早上 | 各机构提交/确认预约取包（含取消截止时间） |
| 上午 | 车辆到点取包；回收登记扫码交接，损坏/丢失当场登记 |
| 上午–下午 | 清洗（篮筐/清洗架绑定）→ 配包核对 → 包装 → 灭菌（含三类监测） |
| 下午 | 上架（储存记录记货架定位）→ 发放（按下送单位开单） |
| 傍晚 | 配送至各机构，签收交接 |
| 全天 | 任何一步都写进操作流水；任一批次出问题可按召回单逐条码召回 |
| 月末 | 按机构出账单，客户可按明细质疑，逐条回溯到原始凭据 |
5. 如果重来一次，我们会改的三件事
| # | 想改的事 |
|---|---|
| 1 | 早期日志只写"做了什么"，没写"依据哪张单据"。后来补上单据出处那组指针（单据编号 + 单据名称），才真正能回应数据核查。早这么做会省很多事。 |
| 2 | 事件类型用了自由文本。要看某个环节的状态得靠日志正文做内容匹配，不如一开始就用枚举。这也是我们正在把流水重构成「事件类型 + 批次键」结构的原因。 |
| 3 | 有一张表里那个「机构」字段的注释写错了（写成"外院标识"），误导过后面接手的人。注释写错比代码写错更难发现。 |
6. 客户说 / 可核验的细节
可核验材料清单（可索取）：
- 灭菌不合格登记的 7 项原因勾选界面（脱敏录屏）
- WS/T 879—2025 数据元对照的字段级截图
- 60 秒全流程操作录屏（从回收登记到使用登记）
- 一次完整召回演练的时间线
7. CTA
标题：想看这套系统真跑起来是什么样？
副文：我们准备了脱敏演示环境，你可以指定任意环节让我们当场演示——包括上面说的那三个"想改的事"，我们也会如实告诉你现在改成什么样了。
- 主按钮：预约演示 →
/demo - 次链接：更多区域化运营细节见 《区域化消毒供应中心建设与运营手册》 ｜或看 区域化方案
FAQ（配 FAQPage JSON-LD）
Q1：为什么案例不写客户名字？ A：应客户要求匿名。我们不做未经授权的客户背书。但可以应你的要求提供脱敏录屏与截图，并由你在保密前提下判断是否可信。
Q2：这些数据是可核实的吗？ A：是的。所有数据来自该项目生产环境的实际运行。演示时可以当场展示各模块的真实界面状态（脱敏）。
Q3：「929 家」是指医院还是科室？ A：接入的外部机构与科室合计数，包含医院、卫生院与外部科室。这是 2026 年 10 月的单一中心口径。
Q4：你们说"由一线员工参与研发"，具体是什么意思？ A：需求来源不是市场调研报告，而是消毒供应中心在岗人员描述自己的日常工作，我们再据此设计。这也解释了为什么系统会细到"标签作废要留痕""损坏和丢失要分开登记"这种颗粒度——这些是外人想不到、但岗位上天天碰到的事。
Q5：如果我们的场景和这个中心不一样，这套经验还适用吗？ A：部分适用。如果是单院供应室，很多区域化复杂度用不上；如果是第三方中心或县域医共体，重合度会很高。判断的最好方式是把你的实际结构告诉我们，我们指出哪些是现成的、哪些要改。