# 区域化消毒供应中心建设与运营手册

### 从「一家医院一个供应室」到「一个中心服务几百家机构」：业务、系统与落地路径

**编制**：深圳市易企动力科技有限公司
**品牌**：易企动力CSSD追溯平台
**版本**：v1.0 ｜ **日期**：2026 年 9 月
**联系**：13510239158 ｜ info@sze7.com ｜ www.sze7.com

---

## 关于本手册

### 写给谁

- **县域医共体牵头医院**的消毒供应中心管理者——你们要承接乡镇卫生院、社区卫生服务中心的器械
- **第三方 / 社会化医疗消毒供应中心**的运营负责人——你们要同时服务几十到几百家医疗机构
- **医院集团 / 区域医疗中心**分管消毒供应的管理者
- 正在做区域化可行性论证的**卫健行政部门与医院管理层**

### 这份手册和别的材料有什么不同

市面上讲区域化消毒供应的材料，多数停留在"为什么要做"（政策、效率、成本）和"应该做什么"（制度、流程、质控）。**中间的"具体怎么做"是空白的**——尤其是一旦机构数量上到几十家、包种类上到几千种，业务上会冒出哪些具体问题、系统该怎么支撑。

本手册回答的是后者。所有系统能力均对应到**真实的数据表与字段**（可在演示环境验证），所有业务难点均来自**一个已运行多年、接入外院机构与科室 929 家、管理 16128 种消毒包、708310 个条码的区域化中心**（单一中心运行数据，截至 2026 年 10 月；按公司对外口径，案例主体匿名化处理）。

### 一个提醒

区域化最难的不是灭菌技术——那是 WS 310 已经解决的事。最难的是：**当你的客户从 1 个变成 300 个，每一件小事都会被乘以 300**。一个包的命名分歧、一次价格调整、一张对账单的争议，在单院只是几分钟沟通，在区域化就是每天的运营成本。

本手册第三部分专门讲这些"被乘以 300 之后"的问题。

---

## 第一部分　政策窗口与三种组织形态

### 1.1 两份国家级文件，把区域化推到了台前

| 文件 | 时间 | 关键意义 |
|---|---|---|
| **《紧密型县域医共体消毒供应中心建设与服务指南（试行）》**（国卫办基层函〔2026〕184 号） | 2026-05-19 印发 | 第一次为"一个中心服务多家机构"给出**完整的建设、服务、质量、考核框架** |
| **WS/T 879—2025《医院消毒供应监测基本数据集》** | 2025-12-12 发布<br>2026-06-01 施行 | 第一次为消毒供应数据定国家标准，并写明**「社会化医疗消毒供应中心可参照执行」** |

第二份文件的意义容易被低估。在此之前，第三方消毒供应中心在标准体系里处于"没人管、也没人认"的位置；现在它**第一次被写进国家级标准的适用范围**。WS/T 879 的 110 个数据元里，"回收对象类型"与"发放对象类型"都把**「院外医疗机构」单列为一类**——这个设计不是为单院供应室做的，**是为同时服务多家机构的中心做的**。

> 关于 WS/T 879 的 110 个数据元逐条对照，见本系列另一份白皮书《WS/T 879—2025 数据元逐条对照表》。

### 1.2 指南要点速览

以下摘录自《紧密型县域医共体消毒供应中心建设与服务指南（试行）》原文。

**设置原则**

> 消毒供应中心以县域为单位进行设置，原则上一个县域设置一个消毒供应中心。对于建有 2 个及以上县域医共体的县域，可明确由综合实力最强的县域医共体牵头医院作为消毒供应主中心，其他县域医共体牵头医院可作为消毒供应分中心。

**适用范围**

> 本指南适用于县域医共体牵头医院、成员单位，包括县域医共体内县级医院、乡镇卫生院、社区卫生服务中心等。县域医共体成员单位中的非基层医疗卫生机构，如县级中医院、妇幼保健院等，根据自身能力开展消毒供应，不具备消毒供应能力的，参照基层成员单位执行。

**四项服务内容**

| # | 内容 | 原文要点 |
|---|---|---|
| 1 | 消毒供应前置服务 | 对成员单位复用医疗器械**名称及数量进行统计、评估**，逐步实现器械统一管理 |
| 2 | 规范处理各类复用医疗器械 | 实现消毒供应集中共享，**确保灭菌物品合格率达 100％** |
| 3 | 统一复用医疗器械监管 | 对转运、储存、使用及使用后预处理进行**不定期现场监管** |
| 4 | 消毒供应存在问题集中干预 | 成员单位**通过平台申领**各类复用医疗器械；临床医务人员可及时反馈质量及要求 |

**七项信息化功能**（原文）

> 具体功能：**物品申领、物品追溯、无菌物品发放、转运监管、成本核算、质量控制、统计分析**等。

**核心功能要求**（原文）

> 无菌包外追溯码与患者信息关联，实现无菌物品全程可追溯……系统可连接医院 HIS 系统，也可独立运行使用。对于具备打印功能的清洗工作站、全自动清洗消毒机、灭菌器等，应支持追溯运行参数及打印参数；**对于使用单位申领物品，支持申请、更换、调配三种模式**。

**不良事件报告时限**

> 一般不良事件 24 小时内上报，重大不良事件立即上报（**≤2 小时**），不得迟报、漏报、瞒报。

**运行保障**

> 县域医共体应建立**内部财务核算机制**，确保消毒供应中心可持续运行。

> ⚠ **注意最后这一条**。它意味着区域化中心不能只算"业务账"，还要算得清"每个成员单位的成本与收益"。这是很多中心上线两年后才发现自己没做好的事——本手册第三部分第 4 节专门讲这个。

### 1.3 三种组织形态，难点各不相同

| 形态 | 典型规模 | 客户性质 | 最突出的难点 |
|---|---|---|---|
| **A. 县域医共体中心**<br>（牵头医院承建，主中心+分中心） | 1 家牵头 + 数家至数十家成员单位（含乡镇卫生院、社区中心） | 同属一个医共体，**内部结算为主** | 成员单位能力参差（有的连暂存间都不达标）；转运距离长；要按指南做满意度评价与绩效考核 |
| **B. 第三方 / 社会化消毒供应中心** | 几十至数百家签约机构 | **独立法人客户，真实收费** | 一客户一套价格与字典；月度对账与回款；合同到期与续签；外来器械厂商对接 |
| **C. 医院集团 / 区域医疗中心内中心** | 数家至数十家院区与科室 | 集团内部 + 少量外院 | 多院区包字典不统一；跨院区调拨；集团层面的成本分摊 |

**本手册以 B 形态（第三方 / 社会化中心）为主线**，因为它的业务复杂度最高——A、C 形态遇到的绝大多数问题，是 B 的子集。各形态的差异点在第 4.1 节单独说明。

### 1.4 区域化 ≠ 单院放大：九个本质差异

这是本手册最重要的一节。**如果你的系统是按单院设计的，下面这九条每一条都是坎。**

| # | 维度 | 单院供应室 | 区域化中心 | 系统必须解决什么 |
|---|---|---|---|---|
| 1 | **包的身份** | 一个包一种叫法 | 同一个包在 300 家机构有 300 种叫法 | 一客户一套包字典与标签 |
| 2 | **灭菌装载** | 一炉一院 | 一炉混装多个客户的包 | 批次回溯要能跨客户 |
| 3 | **价格** | 一个价目表 | 一家一价，还要能临时调价 | 多层级定价与计价引擎 |
| 4 | **结算** | 内部成本，不结算 | 每月要出对账单、要回款 | 按机构/科室/包的明细账 |
| 5 | **资产归属** | 包都是自己的 | 周转包送出去要收回来 | 包归属机构 + 当前所在机构 |
| 6 | **取送** | 固定科室、固定路线 | 几百个取包点、要预约排班 | 取包点与预约时段管理 |
| 7 | **外来器械** | 偶发 | 厂商是常客，有自己的门户 | 厂商账号 + 两级准入控制 |
| 8 | **数据可见性** | 全院都能看 | 外院只能看自己的数据 | 按机构的强制数据隔离 |
| 9 | **客户生命周期** | 不涉及 | 合同到期、续签、停用 | 合同预警与机构停用机制 |

后面第二部分、第三部分逐条展开这九条怎么落地。

---

## 第二部分　指南七项信息化功能逐项对照

《指南》"信息化建设"一节原文列出了七项功能：**物品申领、物品追溯、无菌物品发放、转运监管、成本核算、质量控制、统计分析**。

下面按这七项逐一展开。每一项给出三段内容：**政策原文 → 区域化场景下真正的难点 → 系统怎么支撑（落到表与字段）**。

---

### 2.1 物品申领

**政策原文**

> 县域医共体成员单位通过系统提交申请，消毒供应中心根据申请提供可重复使用手术器械、检查器械、植入耗材的清洗消毒和灭菌等服务。
> 对于使用单位申领物品，支持**申请、更换、调配**三种模式。

**区域化场景下的难点**

单院的"申领"是科室向供应室要包，量小、关系固定。区域化中心的申领有三个新变量：

1. **申领方是外部机构**，中心不知道他们明天要做什么手术，只能靠他们自己提报；
2. **周转包要申领**（中心把包借给客户用，用完收回），这涉及资产与租金，不是普通的消毒服务；
3. **申领与取包是两件事**——申领是"要什么"，取包是"什么时候来拿"，两者要能分开排班。

**系统怎么支撑**

| 能力 | 落点（表.字段） | 说明 |
|---|---|---|
| 申领单 | `APPLY_PACKAGE`（注释"申领消毒包"）+ `APPLY_PACKAGE_DETAILS` | 申领主子表，单据类型区分常规申领与周转包申领 |
| 周转包申领 | `BASE_PACKAGE.BUSINESS_TYPE = 4`（注释原文"业务类别 0：器械包，1：外来器械，2：代灭菌，3：返洗器械，**4：周转包**…"） | 周转包是独立业务类别，可单独列出可选清单 |
| 申领时按客户实时算价 | 函数 `GetDisPackagePriceTotal(@DisPackageID, @CusID)`（注释"获得消毒包包费用的总价"） | **同一个包，传给不同机构 ID 得到不同价**——这是区域化申领的核心 |
| 申领入口（客户端） | `CssdApp` 端「周转包申领」页面 + `api/modules/customer.ts` 接口 | 客户自助提交，不依赖电话与微信 |
| 回挂送消单 | 存储过程 `proc_RecycleAppAdd`（申领单号 `APP-`，`RECYCLE_APP_ID` 回挂送消单） | 申领与后续回收形成闭环，不是两张皮 |
| 预约取包 | `PICKUP_SCHEDULE`（`ORG_ID` / `DEPT_CODE` / `STATION_ID` / `SCHEDULE_DATE` / `STATUS` 0未处理 1已取包 2已关闭） | 申领与取包分离，可分别排班 |

**需注意**：原文提到的"申请、更换、调配"三种模式，系统中「申请」由 `APPLY_PACKAGE` 覆盖，「调配」由 `PACKAGE_BORROW`（借包）支撑（见 3.5）；**「更换」模式的对应关系需结合现场流程确认**，不同中心的业务定义差异较大，我们通常建议定制实现。

---

### 2.2 物品追溯

**政策原文**

> 无菌包外追溯码与患者信息关联，实现无菌物品全程可追溯。
> 消毒供应中心信息追溯系统应采用追溯码进行记录、照相、追溯、管理控制，系统可连接医院 HIS 系统，也可独立运行使用。

**区域化场景下的难点**

"全程可追溯"在单院是一条链，在区域化是**一张网**：同一个包可能昨天在 A 机构、今天在中心、明天送到 B 机构。追溯查询必须能回答"这个包**现在在谁手里**"，而不仅仅是"它经历过哪些环节"。

**系统怎么支撑**

| 能力 | 落点（表.字段） | 说明 |
|---|---|---|
| 一包一码 | `PACKAGE_CODE.BARCODE`（包实例主键） | 条码即身份；`PACKAGE_CODE.TRANS_BARCODE`（周转码）用于周转包 |
| 全链路事件 | `PACKAGE_HISTORY`（含 `SOURCE_TABLE` / `SOURCE_ID` / `CREATE_TIME`） | 每个环节写一条，可反查任一时刻状态 |
| **当前所在机构** | `PACKAGE_CODE.CURRENT_ORG`（注释"当前单位"）+ `CURRENT_DEPT`（"当前科室"） | 与 `ORG_ID`（建档归属）分开存——**这是区域化追溯的关键设计**：归属与所在是两个概念 |
| 患者关联 | `PACKAGE_USAGE.PATIENT_NO`（注释"住院号"） | 使用时登记到患者，实现"包—患者"关联 |
| 照相留痕 | `PACKAGE_PICTURES` + `CUS_PACKAGE_PICTURES`（客户字典配图） | 满足"记录、照相"要求 |
| 独立运行能力 | 系统可脱离 HIS 独立运行，也提供对接接口 | 满足"可连接 HIS，也可独立运行" |
| 责任到人 | 各环节操作人字段（回收 `RECYCLE_BY`、清洗 `CLEAN_BY`、包装 `PACKED_BY`、核包 `INSPECT_BY`、灭菌 `STERILIZED_BY`、消毒 `DISINFECTION_BY`） | 每个环节都能定位到人 |

**成效**：跨机构追溯查询可直接按 `CURRENT_ORG` 检索——"查所有当前在某机构未归还的包"，这是周转包管理的基础（见 3.5）。

---

### 2.3 无菌物品发放

**政策原文**

> 逐步实现物品采购、申领、发放、使用、回收等全流程追溯。
> 应建立完善全流程闭环管理。

**区域化场景下的难点**

发放是区域化最容易出争议的一环：送错了机构、送错了科室、数量对不上、发出去发现是湿包——**每一次争议都要有据可查**。而且发放对象是三类并存的：本院科室、院外医疗机构、器械厂商。

**系统怎么支撑**

| 能力 | 落点（表.字段） | 说明 |
|---|---|---|
| 出库单 | `STOCK_OUT`（注释"出库单"） | 发放主单据 |
| **发放到机构** | `STOCK_OUT.DELIVERY_ORG`（注释"下送单位"）→ 外键指向 `GROUP_COMPANY.COMPANY_CODE` | 区域化的核心字段：发放去向精确到**机构** |
| 发放到科室 | `STOCK_OUT.DELIVERY_DEPT`（"下送科室"）→ `DEPT_DICT.DEPT_CODE` | 机构下的二级去向 |
| 配送载具 | `STOCK_OUT.DELIVERY_CART`（"下送车"） | 可追溯某批货是哪辆车送的 |
| 发放明细 | `STOCK_OUT_DETAILS.QTY` | 数量清点留痕 |
| 客户侧发货查询 | 存储过程 `cus_stat_delivery_summary` / `cus_stat_delivery_detail` | 客户门户可自查"本月收了多少包" |
| 发放后不合格 | `QC_DELIVERY`（注释"无菌物品发放不合格登记表"，含湿包 / 包外化学指示卡变色不合格 / 脏包油包 / 破包 / 标签信息不全 / 过期包 / 发错科室客户） | **闭环的最后一环**：发放之后发现的问题也有登记 |

> 关于 WS/T 879 的对应：标准 090–095 要求"发放对象类型"区分 1.本院科室 / 2.院外医疗机构 / 3.厂商。本系统以 `DELIVERY_ORG` + `DELIVERY_DEPT` 两个字段区分去向，**"院外医疗机构"是原生支持的**；但**类型代码（1/2/3）需要新增枚举位**——这是我们公开标注的缺口之一，见《WS/T 879—2025 数据元逐条对照表》第 093 项。

---

### 2.4 转运监管

**政策原文**

> 应配置……专用密闭运输车辆及密闭转运器具。消毒灭菌后物品和回收物品的转运器具，应当专用、密闭，有警示标识和说明，两者不得混合使用，每次使用后应清洗、消毒，干燥存放。宜洁污分车或同车分区隔断放置运送。
> 转运路线专用，避开高流量人群及公共区域。

**区域化场景下的难点**

转运在单院是一段走廊，在区域化是**几十公里的物流**。要管的东西变成：谁去取、几点取、在哪个点交接、取没取到、器具今天消毒了没有。

**系统怎么支撑**

| 能力 | 落点（表.字段） | 说明 |
|---|---|---|
| 取包点档案 | `PACKAGE_STATION`（注释"取包点"）：`STATION_NAME` 取包点名称 / `ADDRESS` 地址 / `CONTACT_NAME` 联系人 / `CONTACT_NO` 联系电话 | 每个客户可有自己的取包点 |
| 取包点排班规则 | `PACKAGE_STATION.CYCLE_TIME`（周期）/ `DAYS`（日期）/ `END_SCHEDULE_DAY`+`END_SCHEDULE_HOUR`（预约截止）/ `END_CANCEL_DAY`+`_HOUR`+`_MINUTS`（中止取消时限） | **每个取包点可以有自己的周期与截止时间** |
| 可预约时段 | `PACKAGE_STATION_TIME` | 时段级控制 |
| 客户↔取包点 | `CUSTOMER_PICKUP_STATION` / `CUSTOMER_PACKAGE_STATION` | 哪些客户能用哪个取包点 |
| 预约取包单 | `PICKUP_SCHEDULE`：`SCHEDULE_DATE` 预约日期 / `SCHEDULE_TIME` 预约时间 / `SCHEDULE_BY` 预约人 / `STATUS`（0 未处理 / 1 已取包 / 2 已关闭）/ `END_CANCEL_TIME` 取消截止时间 | 取包动作全程有单可查 |

> **⚠ 如实说明一处能力边界**：系统目前提供的是「**取包点 + 周期 + 预约截止**」的**站点级排班**，**没有线路级优化**（全库无 `ROUTE` / `TRANSPORT` 类表）。也就是说，可以按取包点排班，但不能自动规划"这辆车今天走哪条线、按什么顺序取"。如果贵中心的车辆调度是核心痛点，这块需要单独评估定制。
>
> 另外，指南中"器具每次使用后清洗消毒干燥存放""转运路线专用""洁污分车"等属于**线下管理制度**，系统可记录与留痕，但**不能替代制度执行**——这一点我们不回避。

---

### 2.5 成本核算

**政策原文**

> 县域医共体应建立**内部财务核算机制**，确保消毒供应中心可持续运行。
> 具体功能：……成本核算……

**区域化场景下的难点**

这是区域化中心最容易在运营一年后暴雷的地方。难点有四个：

1. **一家一价**：同一服务对不同客户价格不同（合同价、量价、关系价）；
2. **计价单元不统一**：有的按包、有的按件、有的加收材料费、有的收器械折旧；
3. **临时调价**：材料涨价、新增服务，改价要有据可查；
4. **要能出对账单**：客户会逐条核对，差一分钱都要解释。

**系统怎么支撑：四层定价体系**

| 层级 | 落点（表.字段） | 说明 |
|---|---|---|
| **① 字典基准价** | `BASE_PACKAGE`：`INIT_PRICE` 初始消毒价格 / `FACT_PRICE` 实际消毒价格 / `APP_PRICE` 材料费 / `RENTAL_PRICE` 器械折旧 / `COST_PRICE` 成本价 / `DISCOUNT_TYPE` 折扣方法（0无折扣 1全局折扣 2指定折扣）/ `DISCOUNT` 折扣数 | 成本的底账 |
| **② 客户成交价** | `CUSTOMER_PACKAGE_PRICE`（注释"客户价格信息"，主键 `ORG_ID`+`DEPT_ID`+`PACKAGE_ID`）：`PRICE` 价格 / `DISCOUNT` 折扣率 / `FACT_PRICE` 最终价格 / `IS_FIXED` 固定价格 / `IS_RENT` 是否租赁 / `IS_DISABLED` 已禁用 | **支持精确到"某机构某科室某个包"** |
| **③ 附加计价项** | `CUSTOM_PACKAGE_PRICE_ITEM`（注释"消毒包自定义价格项目"）：`PRICE_ITEM` 项目名称 / `PRICE` / `QUANTITY` / `AMOUNT` | 加收项（如特殊包装、加急） |
| **④ 机构级折扣** | `GROUP_COMPANY.DISCOUNT`（注释"消毒费折扣"） | 整单层面的折让 |

**计价引擎**：函数 `GetDisPackagePriceTotal`（文件头注释"获得消毒包包费用的总价"）。读取代码得出的**定价优先级链**：

> **固定价（`IS_FIXED=1`） > 客户成交价 + 材料费 + 附加项 > 字典价 × 折扣因子 + 附加项**

**账务落地**

| 能力 | 落点（表.字段） | 说明 |
|---|---|---|
| 费用账单 | `BILLING`（注释"费用账单"）：`ORG_ID` 机构标识 / `DEPT_CODE` 科室标识 / `SUBJECT` 科目 / `PRICE` 单价 / `DISCOUNT` 折扣 / `FINAL_PRICE` 折扣价 / `QTY` 数量 / `ACCOUNT_DATE` 记账日期 / `SOURCE` 来源（0普通器械 1外来器械 2敷料代消包 3返洗器械 4单件器械 9其它） | 每一笔费用都能归到机构与科室 |
| 单据级价格快照 | `FLOW_RECYCLE_PACKAGE`：`PRICE` 消毒价格 / `DISCOUNT` 折扣 / `FACT_PRICE` 折后价 / `QUANTITY` 数量 | **价格随单固化**——后续调价不影响历史账单，这是避免对账争议的关键 |

> **为什么"价格随单固化"重要**：如果账单是查询时按当前价重新算的，那么一次调价会让过去三个月的账单全部变化。客户拿上个月的对账单来问"为什么和这次不一样"，你就解释不清了。

---

### 2.6 统计分析

**政策原文**

> 具体功能：……统计分析……
> 无菌物品管理信息系统具备通过无菌包接收、使用监控与统计报表模块实现对无菌包使用数据的收集与统计分析功能。

**区域化场景下的难点**

统计需求会分成**两类视角**，而且两类视角要的完全不是同一个东西：

- **中心管理者视角**：我这个月处理了多少包、设备利用率多少、质量指标如何；
- **客户视角**：我这个月送了多少包、花了多少钱、有没有不合格。

**系统怎么支撑**

| 视角 | 能力 | 落点 |
|---|---|---|
| **按机构对账** | 按单位及科室统计各种包的费用 | 存储过程 `proc_statByOrgAndDept`（注释"按单位及科室统计各种包的费用"）——输出字段即**机构→科室→包→单价/折扣/折后价/数量/小计/件数**，可直接作为对账明细 |
| | 各机构回收费用总数 | `proc_stat_org_amount`（注释"统计各机构回收费用总数"） |
| | 机构回收清单 / 器械申领清单 | `proc_stat_org_recycle_list` / `proc_stat_org_apply_instrument_list` |
| **客户门户** | 客户自助查询发货与回收 | `cus_stat_delivery_summary`（注释"获取发货统计信息"）/ `cus_stat_delivery_detail` / `cus_stat_recycle_summary` |
| **质量统计** | 清洗质量 / 灭菌质量 | `proc_statCleanQuality` / `proc_statSterilizeQuality` |
| **工作量** | 工作量与外来器械统计 | `proc_stat_workload` / `proc_stat_foreign_*` |
| **可视化** | 数字大屏 | 独立大屏前端项目 + 后端 8 个统计端点：`/tracking`、`/recycle-apply`、`/in-out-quantity`、`/user-alerts`、`/kpis`、`/dept-apply`、`/recycle-summary`、`/sterilizations` |

**报表底座**：数据库层有 134 个视图、60 个存储过程，作为统计与报表的基础。多数区域化中心的定制报表需求，可以在视图层完成而不必改应用代码。

> ⚠ 关于"大屏指标数量"我们不夸大：可确证的是上述 8 个统计端点，加上视图与存储过程作为底座。具体指标项按现场需求配置。

---

### 2.7 质量控制

**政策原文**

> 消毒供应中心管理信息系统应具备人员、物资、质量控制等方面的管理应用功能和对物品接收、清洗消毒、检查包装及灭菌过程关键环节的质量追溯功能。
> 建立不良事件报告制度……一般不良事件 24 小时内上报，重大不良事件立即上报（≤2 小时）。

**区域化场景下的难点**

区域化中心的质量压力其实比单院更大——**一旦出问题，影响的是几十家机构的手术安排**。而且质量争议要有第三方可验证的证据（设备原始曲线、监测结果），不能只说"我们合格"。

**系统怎么支撑**

| 环节 | 落点（表.字段） | 说明 |
|---|---|---|
| 灭菌前检查 | `QC_BEFORE_STERILIZE`（含 `UNQUALIFIED_PACKAGING` 包装不合格） | 装载前把关 |
| 包装质量检查 | `QC_PACKING`（`F01`–`F16` 共 16 项检查项 + `CHECK_BY` / `CHECK_TIME`） | 逐项检查，不是打一个勾 |
| 灭菌包不合格登记 | `QC_STERILIZE_PACKAGE`：`IS_WET` 包外湿包 / `INDICATOR_INVALID` 包外化学指示物变色不合格 / `IS_DIRTY` 脏包油包 / `IS_BROKEN` 破包 / `IS_LOOSE` 包装松散 / `LABEL_INCOMPLETE` 标签信息不全 / `IS_OTHER` 其他 | 不合格原因结构化 |
| 缺陷类型 | `STERILIZATION_CHECK_DETAIL.FAILED_TYPE` | 包内湿包 / 包外湿包 / 包内容不符 / 标签不符 / 器械清洁度不符 / 包装密合度不符 / 器械功能不符 / 指示物异常 / 其他 |
| 发放后不合格 | `QC_DELIVERY` | 前述发放闭环 |
| **设备原始曲线** | `STERILIZE_DEVICE_DATA`：`PHYSICAL_DATA`（物理数据 XML）/ `PHYSICAL_DATA_IMG` / `PHYS_RESULT` 物理监测结果 / `CHEM_RESULT` / `BIO_RESULT`（**-1 结果未出 / 0 失败 / 1 成功**）/ `PROG_EXPOSURE_TEMP` 预设灭菌温度 / `PROG_EXPOSURE_TIME` 预设灭菌时间 / `PROC_BATCH` / `PROC_COUNT` 当日炉次 | **第三方可验证的证据**：不是人工填的"合格"，是设备跑出来的原始参数 |
| 生物监测 | `BIOMONITORING.RESULT` | 独立登记，三态设计支持"结果未出"的提前放行场景 |
| 召回 | `RECALL_LIST` | 问题批次的召回管理 |

**关于不良事件时限**：`QC_DELIVERY` 同时记录 `CREATE_TIME`（登记时间）与 `CHECKED_TIME`（检查时间），可据此统计"发现到上报"的时间差，用于 24 小时 / 2 小时时限的自查。

---

## 第三部分　区域化运营的九个坑

这一部分是本手册最值钱的部分。前面讲的七项功能，是"应该有什么"；这一节讲的是"**上线之后真正会咬人的地方**"——它们大多不会出现在需求清单里，而是在机构数量涨到几十家之后才暴露。

九节对应第一部分 1.4 的九个本质差异。

---

### 3.1 坑一：同一个包，三百个名字

**现象**

A 医院叫它"腹腔镜器械包"，B 医院叫它"腔镜包"，C 医院叫它"LC 器械"。它们是同一个包，但**对账单上必须是客户自己的叫法**，否则客户不认。同样地，标签上印什么文字，各机构要求也不同。

**系统怎么解决**

三层机制，都以 `(机构, 科室, 包)` 三元组为键：

| 机制 | 落点 | 作用 |
|---|---|---|
| **客户自有字典** | `CUS_BASE_PACKAGE`：`ORG_ID` 机构标识 / `DEPT_ID` 科室标识 / `BASE_PACKAGE_ID` 指向母版 / `PACKAGE_NAME` 客户自己的包名 / `LABEL_CONTENT` 标签内容 / `ACCEPT_STATUS`（0 未接受 1 已接受 2 已驳回）/ `ACCEPT_MESSAGE` 审核意见 | 客户提报自己的包名，**中心审核后生效** |
| **标签内容映射** | `BASE_PACKAGE_LABELS`：`ORG_ID` / `DEPT_ID` / `PACKAGE_ID` / `PACKAGE_NAME` 标签名称 / `LABEL_TEXT` 标签内容 / `ADD_DEPT_NAME` 添加科室外院名（唯一索引建在 `ORG_ID+DEPT_ID+PACKAGE_ID`） | 同一包在不同机构/科室下的标签内容 |
| **可见性控制** | 存储过程 `GetBasePackageByOrgAndDept`（注释"按科室或机构查询可用字典列表"） | **外院看得到的包 = 在 `CUSTOMER_PACKAGE_PRICE` 里配过价且未禁用的包** |

**标签的三级回落链**（存储过程 `proc_get_package_label_content`，注释"根据条码获取标签内容"）：

```
机构 + 科室  →  机构  →  字典默认标签（BASE_PACKAGE.DEFAULT_LABEL_TEXT）
```

先找最精确的，找不到就降级，最后落到母版字典的默认标签。**有回落才不会打不出标签。**

> ⚠ **一个值得记下的命名教训**：`BASE_PACKAGE_LABELS.ORG_ID` 在库里的中文注释是"外院标识"，很容易被理解成"这个标签只属于某外院"。**实际上不是**——它同时被本院科室使用（本院也按科室覆盖包名）。真实语义是"**哪个机构的哪个科室看到这个包时，显示的包名与标签内容**"。
> 我们是在对照标准时才发现这个注释与实现不符的。写在这里，是因为**字典注释的歧义会在几年后变成新人的误解**——如果你正在建自己的字典，字段命名别偷懒。

---

### 3.2 坑二：一炉混装三个客户的包，怎么回溯？

**现象**

区域化中心为了提高设备利用率，一炉灭菌里会混装多个客户的包。这在业务上完全合理，但在追溯上带来一个尖锐问题：**如果这一炉生物监测不合格，要召回的是三个客户的部分包，不是整炉。**

**系统怎么解决**

关键在于**"批次"与"归属"分层存放**：

| 层 | 落点 | 说明 |
|---|---|---|
| 供给侧（炉次） | `STERILIZATION.FID`（批号）+ `STERILIZE_DEVICE_DATA.PROC_BATCH` | **灭菌批次表本身不含机构字段** —— 一炉就是一炉 |
| 需求侧（客户） | `FLOW_RECYCLE_PACKAGE.ORG_ID` / `DEPT_CODE` | 每个包自己带着"我是谁的" |
| 装载明细 | `STERILIZATION_DETAIL` | 炉次 ↔ 包的明细关系 |
| 账务侧 | `BILLING.CSSD_ID`（供给侧维度）+ `FLOW_RECYCLE_PACKAGE` 的机构与价格（需求侧维度） | 一锅多客户、分开结算 |

**所以召回时的路径是**：不合格炉次 → `STERILIZATION_DETAIL` 取出所有包 → 按每个包的 `ORG_ID` 分组 → 分别通知各客户。

> **这是区域化与单院在数据结构上最本质的差别**：单院系统的"批次"可以直接等于"客户批次"；区域化系统必须把**炉次（物理）**与**客户（商务）**拆开，否则一炉混装就无法回溯。

---

### 3.3 坑三：改一次价，三个月的账单全变了

**现象**

材料涨价，中心调整了包的价格。结果客户拿上个月的对账单来问："为什么这次的数和上次不一样？"——如果账单是**查询时按当前价重新计算**的，历史账单会跟着变，这就是一场解释不清的争议。

**系统怎么解决**

| 机制 | 落点 | 说明 |
|---|---|---|
| 价格随单固化 | `FLOW_RECYCLE_PACKAGE`：`PRICE` 消毒价格 / `DISCOUNT` 折扣 / `FACT_PRICE` 折后价 | **每一笔业务发生时把价格写死在单据上**，后续调价不影响历史 |
| 固定价开关 | `CUSTOMER_PACKAGE_PRICE.IS_FIXED`（固定价格） | 某些客户的合同价锁定，不受全局折扣影响 |
| 计价优先级 | 函数 `GetDisPackagePriceTotal` | 固定价 > 客户成交价（+材料费+附加项）> 字典价×折扣+附加项 |

**一句提醒**：上线时一定要确认**计价是"取当前价"还是"取单据快照价"**。这两种做法在试点期看不出差别，在第一次调价之后就会变成纠纷。

---

### 3.4 坑四：对账单出不来，回款就慢

**现象**

几百家客户，每家每月都要一份对账单。如果靠人工导 Excel 拼，财务人员的工作量会随客户数线性增长，而且**客户一质疑就得翻单据重算**。

**系统怎么解决**

对账明细不是从零拼的，数据库里直接就有：

- 存储过程 `proc_statByOrgAndDept`（注释"按单位及科室统计各种包的费用"）输出的字段就是
  **`机构 → 科室 → 包 → 单价 / 折扣 / 折后价 / 数量 / 小计 / 件数`**
  这已经是可以直接发给客户的对账明细格式。
- 总额层：`proc_stat_org_amount`（"统计各机构回收费用总数"）、`proc_statTotalByOrgAndDept`
- 客户侧自助：`cus_stat_delivery_summary` / `cus_stat_delivery_detail` / `cus_stat_recycle_summary` —— **让客户自己查**，减少来回沟通
- 账单实体：`BILLING`（`ACCOUNT_DATE` 记账日期 / `SUBJECT` 科目 / `SOURCE` 来源分类）

**一句提醒**：指南要求"建立内部财务核算机制"。建议在系统上线时就把**科目体系（`BILLING.SUBJECT`）**定好，而不是上线后再补——科目改一次，历史账单的归类就要重做。

---

### 3.5 坑五：周转包送出去，收不回来

**现象**

中心把自己的周转包借给客户使用，客户用完后应该在下次取包时归还。但几个月后你发现：**账上有几百个包在外面，你不知道在谁那儿**。

**系统怎么解决**

| 概念 | 落点（表.字段） | 说明 |
|---|---|---|
| **这个包是谁的资产** | `PACKAGE_CODE.ORG_ID`（机构编号，建档归属） | 所有权 |
| **这个包现在在谁手里** | `PACKAGE_CODE.CURRENT_ORG`（注释"当前单位"）+ `CURRENT_DEPT`（"当前科室"） | 实时位置 |
| 周转标识 | `PACKAGE_CODE.TRANS_BARCODE`（周转码） | 周转包专用编码 |
| 借出登记 | `PACKAGE_BORROW`（注释"借包登记"）：`ORG_ID` 机构编码（借给谁）/ **`ORIGN_ORG_ID` 原机构** / `ORIGN_DEPT_CODE` 原科室 / `IS_RETURNED` 已归还 / `BORROW_BY` 借包人 / `START_TIME` 出借时间 / `END_TIME` 归还时间 | **资产归属 + 应收未收跟踪**的完整实现 |
| 租赁计价 | `CUSTOMER_PACKAGE_PRICE.IS_RENT`（是否租赁） | 周转包可按租赁计价 |
| 申领入口 | `BASE_PACKAGE.BUSINESS_TYPE = 4`（周转包）+ `APPLY_PACKAGE` 申领单 | 客户自助申领 |

> **`ORIGN_ORG_ID`（原机构）这个字段是关键**：它把"借给谁"和"本来是谁的"分开了。没有它，跨机构借包就会变成一笔糊涂账（常见于集团内多院区互借的场景）。

---

### 3.6 坑六：预约取包，同一天被预约了两次

**现象**

客户在小程序上预约明天的取包。两个人同时点了两下——**系统里出现了两条重复预约**。取包车到了现场，发现是同一次需求。

**为什么会发生**（这是真实发生过并被修复的问题）

应用层的去重逻辑是**先查后插**：先查该机构该日期有没有未结束的预约，没有才插入。问题在于——

> 应用层 `PickupAppService.EnsureNoDuplicateAsync` 是**先查后插**，并发下可以被绕过 —— 同一毫秒的两个请求都查到 0 条，于是都放行。

**怎么修的**

把判定**下沉到数据库**，用筛选唯一索引兜底（`升级脚本/PICKUP_SCHEDULE_UX_DAY.sql`）：

```sql
CREATE UNIQUE INDEX UX_PICKUP_SCHEDULE_DAY
ON PICKUP_SCHEDULE (ORG_ID, SCHEDULE_DATE) WHERE STATUS < 2
```

即：**同一机构 + 同一预约日，只允许存在一条未结束（`STATUS < 2`）的预约**；已关闭/已完成的记录不参与唯一性。应用层捕获 SQL 2601/2627 转为 409 冲突返回。

脚本里还写了一段前置检查——**历史脏数据会让 `CREATE UNIQUE INDEX` 直接失败，而 SQL Server 的报错不会指向业务含义**，所以先查再建，有问题就报人话：

> PICKUP_SCHEDULE 存在「同一机构同一天多条未结束预约」。请先人工合并 / 关闭多余记录，再重新执行本脚本。

**为什么把这段写进手册**：这类问题**只有在真实高并发运行过才会遇到、才会修**。它不是设计出来的，是踩出来的。类似的并发兜底在区域化场景里还有不少（多客户同时操作是常态，单院不会）。

---

### 3.7 坑七：外来器械厂商是第三类客户

**现象**

外来器械厂商（器械供应商）既不是本院科室，也不是外院机构，但他们会**主动把器械送到中心来灭菌**，还要自己来取。把他们当普通客户管，权限和流程都会乱。

**系统怎么解决**

| 能力 | 落点 | 说明 |
|---|---|---|
| **厂商独立账号体系** | `SUPPLIER`（注释"供应商"）：`PASSWORD` / `LAST_LOGIN_TIME` / `LOCKOUT_TIME` 锁定时间 / `CONTACT_NAME` / `TEL` | 厂商有自己的登录体系，与医院客户（`CUSTOMER_USER`）并列 |
| 供应商档案 | `SUPPLIER.SUPPLIER_NAME` + `FOREIGN_REG.OWNER_NAME` 中标公司（厂家） | 器械来源可追溯 |
| **两级准入控制** | `GROUP_COMPANY.HAS_FOREIGN`（注释"是否接收外来器械"）+ `DEPT_DICT.ALLOW_FOREIGN`（"是否接受外来器械"） | **机构层面可以收、某科室可以不收** |
| 外来器械登记 | `FOREIGN_REG` / `FOREIGN_REG_DETAILS` / `FOREIGN_REG_PACKAGE`（含 `PACKAGE_SIZE`） | 完整登记链路 |
| 跨机构转移 | 存储过程 `proc_foreign_change_org` | 外来器械登记可跨机构转移 |

**一个容易忽略的运营开关**：`GROUP_COMPANY.DISALLOW_DEPT_MISC`（注释"**是否阻止科室混合发包**"）——控制某客户是否允许一锅/一箱混装其多个科室的包。这种颗粒度的开关，通常只有被客户投诉过才会想到要加。

---

### 3.8 坑八：外院能看到别人的数据

**现象**

给外院客户开了查询账号，结果他们能看到别的机构的包和价格。**在区域化场景里，这是会直接丢客户的严重事故。**

**系统怎么解决**

| 机制 | 落点 | 说明 |
|---|---|---|
| **独立的客户账号表** | `CUSTOMER_USER`（注释"科室用户表"）：`ORG_ID` 机构代码 / `DEPT_CODE` 科室代码 / `ORG_TITLE` 机构简称 / `ROLE_NAME` 所属角色 / `OPEN_ID` 公众号用户ID | ⚠ 注意：**内部员工表 `USERS` 没有 `ORG_ID`**（也没有 `CSSD_ID`），外院登录走的是 `CUSTOMER_USER` |
| 令牌携带机构 | 登录时把 `OrgId` 写进令牌（`AuthAppService`：`CurrentUser(AuthRoles.Customer, ..., user.OrgId, null)`） | **机构 ID 从令牌取，不从请求参数取**——防止改参数越权 |
| 查询强制过滤 | 各查询显式带 `orgId` 条件 | 数据按令牌机构隔离 |
| 契约明文规定 | 接口文档：「全部需登录，且**数据按令牌里的机构隔离**」 | 不是口头约定，写进契约 |

**一段值得公开的经验**：老实现里的机构隔离是**靠 Session 天然满足**的——它并没有错，但它是**隐式依赖**，一旦换架构（比如搬到新平台、改成 API）就会静默失效。

我们在新架构里把它改成了显式强制，并用集成测试钉住：**用两个不同机构 ID（`ZZTEST` / `ZZOTH`）做跨机构断言**，确保 A 机构看不到 B 机构的数据。

> 给你的建议：评估任何区域化系统时，问一句"**机构隔离是靠什么保证的**"。如果答案是"登录时取的是当前机构"，要追问"**有没有测试覆盖跨机构越权**"。

---

### 3.9 坑九：合同到期了没人知道

**现象**

几百家签约机构，合同陆续到期。没有提醒机制的话，往往是客户打电话来问"我们合同是不是该续了"，或者更糟——**服务已经超期提供了三个月，还没续签**。

**系统怎么解决**

| 能力 | 落点（表.字段） | 说明 |
|---|---|---|
| 合同到期日 | `GROUP_COMPANY.CONTRACT_EXPIRE_DATE`（注释"合同过期时间"） | 每家机构一个日期 |
| 到期提醒开关 | `GROUP_COMPANY.CONTRACT_ALERT`（"合同到期提醒"） | 可按机构开关 |
| 预警查询 | 存储过程 `proc_get_customer_alert`（客户预警） | 集中输出待处理客户 |
| 机构停用 | `GROUP_COMPANY.IS_FORBIDDEN` | 停用后不再接单，避免"停了还在送" |
| 客户档案 | `GROUP_COMPANY`：机构编号 / 机构名称 / 所在地址 / 电话 / 联系人 / EMAIL / 排序 | 完整的客户主数据 |

---

## 第四部分　建设与上线路径

### 4.1 三种组织形态的建设重点差异

| 环节 | A. 县域医共体中心 | B. 第三方 / 社会化中心 | C. 医院集团内中心 |
|---|---|---|---|
| **首要工作** | 成员单位能力评估与暂存间改造 | 客户主数据与价格体系 | 多院区包字典统一 |
| **价格** | 内部核算为主，可简化 | **必须做四层定价**（合同价+折扣+附加项） | 集团内结算价 + 成本分摊 |
| **对账** | 内部报表即可 | **每月对账单是刚需**，建议开客户自助查询 | 按院区出报表 |
| **外来器械** | 视牵头医院能力 | 高频，必须开厂商门户 | 中频 |
| **取送** | **距离长、点多**，取包点排班是重点 | 取包点 + 预约排班 | 院内为主，较简单 |
| **满意度与考核** | **指南明确要求**（定期评价、满意度调查、纳入绩效考核） | 客户关系维护 | 集团内部考核 |
| **最易踩的坑** | 成员单位预处理不规范，污染器械到中心 | 对账争议与回款 | 字典不统一导致统计口径混乱 |

### 4.2 上线三阶段

| 阶段 | 时间 | 目标 | 关键交付 |
|---|---|---|---|
| **第一阶段 · 跑通主链路** | 0–30 天 | 一家机构完整跑通回收→清洗→包装→灭菌→发放→使用 | 机构主数据、包字典、条码体系、人员账号、PDA/扫码枪 |
| **第二阶段 · 多机构并行** | 30–90 天 | 5–20 家机构并行，价格与对账可用 | 客户价格表、客户字典与标签、取包点排班、对账报表 |
| **第三阶段 · 规模化运营** | 90–180 天 | 全部机构接入，运营指标可视化 | 合同预警、客户门户、大屏、质量与满意度体系 |

**不要试图一次性铺开。** 第一阶段只选**一家配合度最高、包种类最简单**的机构跑通——区域化的复杂度来自机构数量，先把单链路跑顺，再去乘以 300。

### 4.3 数据初始化清单（上线前必须确认）

| # | 数据 | 落点 | 常见疏漏 |
|---|---|---|---|
| 1 | 机构主数据 | `GROUP_COMPANY`：机构编号 / 名称 / 地址 / 联系人 / 电话 / `CONTRACT_EXPIRE_DATE` / `HAS_FOREIGN` / `DISALLOW_DEPT_MISC` / `DISCOUNT` | 忘了填合同到期日 ⇒ 第九个坑 |
| 2 | 科室 | `DEPT_DICT`：`COMPANY_CODE`（挂机构）/ `ALLOW_FOREIGN` | 科室没挂机构 ⇒ 对账分不开 |
| 3 | 包字典母版 | `BASE_PACKAGE`：`BUSINESS_TYPE` / `UNIT` / `INIT_PRICE` / `FACT_PRICE` / `APP_PRICE` / `RENTAL_PRICE` / `COST_PRICE` | 只填了消毒价，没填材料费与折旧 ⇒ 成本核算不准 |
| 4 | 客户价格 | `CUSTOMER_PACKAGE_PRICE`：`ORG_ID`+`DEPT_ID`+`PACKAGE_ID` → `PRICE` / `DISCOUNT` / `FACT_PRICE` / `IS_FIXED` / `IS_RENT` | 直接改字典价而不建客户价 ⇒ 一家一价做不了 |
| 5 | 客户包名与标签 | `CUS_BASE_PACKAGE`（需 `ACCEPT_STATUS` 审核）+ `BASE_PACKAGE_LABELS` | 客户乱填包名，字典被污染 |
| 6 | 取包点 | `PACKAGE_STATION`（周期 / 截止 / 取消时限）+ `PACKAGE_STATION_TIME` + `CUSTOMER_PICKUP_STATION` | 没设截止时间 ⇒ 客户随时改预约 |
| 7 | 账号 | `CUSTOMER_USER`（`ORG_ID`/`DEPT_CODE`/角色）+ `SUPPLIER`（厂商） | 用内部员工表 `USERS` 给外院开账号 ⇒ **它没有 `ORG_ID`，隔离失效** |
| 8 | 包实例 | `PACKAGE_CODE`：`BARCODE` / `ORG_ID`（归属）/ `CURRENT_ORG`（当前）/ `EXPIRE_DATE` | 周转包没标 `TRANS_BARCODE` ⇒ 收不回来 |
| 9 | 科目体系 | `BILLING.SUBJECT` | 上线后再补 ⇒ 历史账单要重分类 |

### 4.4 五种常见失败模式

| # | 失败模式 | 后果 | 怎么避免 |
|---|---|---|---|
| 1 | **字典先上车后补票** | 包字典不统一就开跑，三个月后返工重建，历史数据对不上 | 第一阶段就把母版字典定完，客户字典走审核（`ACCEPT_STATUS`） |
| 2 | **价格体系没定就开单** | 科目缺失、附加项无处记，对账时补不回来 | 上线前定完科目体系与计价优先级链 |
| 3 | **客户字典不做审核** | 客户自行乱填包名，字典被污染，统计口径崩坏 | 强制走 `CUS_BASE_PACKAGE.ACCEPT_STATUS` 审核流 |
| 4 | **机构隔离没做测试** | 外院看到别家数据 —— 区域化场景下的严重事故 | 用两个机构 ID 做跨机构断言测试（见 3.8） |
| 5 | **取送流程照搬单院** | 区域化的物流不是走廊，单院经验直接套用必然出问题 | 按 2.4 建取包点与预约排班；线路优化单独评估 |

---

## 第五部分　监管考核自查表

《指南》附录 B 给出《紧密型县域医共体消毒供应管理质量评价表》，共 **12 项，评价结果为「是 / 否」**。这是主管部门考核时最可能直接使用的表。

下面逐项列出原文，并标注**哪些可以靠信息系统直接支撑、哪些属于线下制度**。

| # | 评价内容（原文） | 系统能否支撑 | 支撑方式 |
|---|---|---|---|
| 1 | 县域医共体内复用医疗器械实现集中处理。 | ✅ 强支撑 | 按机构统计处理量（`proc_stat_org_amount` / `proc_statByOrgAndDept`），可出各成员单位集中处理率 |
| 2 | 工作流程、质量标准遵循 WS 310 有关要求。 | ⚠ 部分 | 流程在系统中固化（环节不可跳过），标准条款本身需制度配套 |
| 3 | 建立并运行覆盖运输服务全过程的质量管理体系，确保医疗器械使用后收集、转运、清洗、包装、灭菌、发放、运输全过程的质量安全和可追溯。 | ✅ 强支撑 | 全链路 `PACKAGE_HISTORY` + 各环节留痕（回收/清洗/包装/灭菌/发放）+ 转运靠 `PICKUP_SCHEDULE` 与取包点 |
| 4 | 外来医疗器械的管理、交接和清洗、消毒、灭菌及提前放行均符合 WS 310 有关要求。 | ✅ 强支撑 | `FOREIGN_REG` 全链路 + 生物监测三态（`BIO_RESULT = -1` 结果未出，支撑提前放行场景） |
| 5 | 信息化流程管理逐步完善。 | ✅ 强支撑 | 本手册第二部分七项功能 |
| 6 | 转运过程中，工作人员严格遵守消毒隔离原则，进行相应的职业防护。 | ❌ 线下 | 属人员行为与制度，系统可记录培训与考核（人员培训模块） |
| 7 | 运送器具及密闭转运车每次使用后进行清洗消毒处理，干燥备用。 | ⚠ 部分 | `STOCK_OUT.DELIVERY_CART`（下送车）可追溯用车；清洗消毒记录需线下登记或定制扩展 |
| 8 | 运送人员和接收人员，在规定的区域内完成交接工作，双人现场核查，清点，签收。 | ⚠ 部分 | 发放有 `STOCK_OUT` 与 `STOCK_OUT_DETAILS.QTY` 清点；**"双人现场核查签收"多为线下动作**，可按需定制双人确认 |
| 9 | 转运路线专用，避开高流量人群及公共区域。 | ❌ 线下 | 属线路规划与管理制度；系统目前无线路级优化（见 2.4 说明） |
| 10 | 每年至少一次对运输管理体系运行情况进行自查，形成自查报告。 | ⚠ 部分 | 可提供取送数据与异常统计作为自查依据；报告需人工出具 |
| 11 | 成员单位使用后医疗器械按规范进行预处理并存放在专用暂存间。 | ❌ 线下 | 属成员单位现场管理；可通过前置评估与监管记录配合 |
| 12 | 成员单位存放无菌物品场所标准符合 WS 310。 | ❌ 线下 | 同上 |

**结论**：12 项中，**5 项可由信息系统强支撑，4 项部分支撑，3 项属线下制度**。

> 这个比例值得记住。区域化建设里，**信息化解决不了所有问题**——它解决的是"可追溯、可统计、可对账、可预警"，而人员操作规范、场所标准、转运路线这类事，要靠制度与管理。
>
> 所以我们的建议一贯是：**先跑通信息化能管的那部分，再用数据去驱动线下改进**。比如用 `QC_DELIVERY` 的不合格登记数据去定位哪个环节问题最多，比开会讨论有效得多。

---

## 附录 A　区域化关键表速查

| 域 | 表 | 作用 |
|---|---|---|
| **机构/客户** | `GROUP_COMPANY` | 机构主数据（含合同到期、折扣、外来器械准入、混合发包控制） |
| | `DEPT_DICT` | 科室，通过 `COMPANY_CODE` 挂机构 |
| | `CUSTOMER_USER` | 外院客户账号（**有 `ORG_ID`**） |
| | `SUPPLIER` | 器械厂商账号（独立登录体系） |
| **包字典** | `BASE_PACKAGE` | 包字典母版（含业务类别、五类价格、有效期） |
| | `CUS_BASE_PACKAGE` | 客户自有字典（含审核状态） |
| | `BASE_PACKAGE_LABELS` | 按机构/科室的包名与标签内容映射 |
| | `ORG_DEPT_BASE_PACKAGE` | 机构科室与包字典对照 |
| **价格与账务** | `CUSTOMER_PACKAGE_PRICE` | 客户成交价（机构+科室+包） |
| | `CUSTOM_PACKAGE_PRICE_ITEM` | 附加计价项 |
| | `BILLING` | 费用账单 |
| | 函数 `GetDisPackagePriceTotal` | 计价引擎 |
| **包实例与流转** | `PACKAGE_CODE` | 包实例（`ORG_ID` 归属 / `CURRENT_ORG` 当前所在 / `TRANS_BARCODE` 周转码） |
| | `PACKAGE_HISTORY` | 全链路事件 |
| | `PACKAGE_BORROW` | 借包登记（含 `ORIGN_ORG_ID` 原机构 / `IS_RETURNED` 已归还） |
| | `PACKAGE_USAGE` | 使用登记（含 `PATIENT_NO` 住院号） |
| **取送** | `PACKAGE_STATION` | 取包点（含周期与截止时间） |
| | `PACKAGE_STATION_TIME` | 可预约时段 |
| | `CUSTOMER_PICKUP_STATION` | 客户↔取包点 |
| | `PICKUP_SCHEDULE` | 预约取包单 |
| **收发** | `STOCK_OUT` / `STOCK_OUT_DETAILS` | 出库单（`DELIVERY_ORG` 下送单位 / `DELIVERY_DEPT` / `DELIVERY_CART` 下送车） |
| | `APPLY_PACKAGE` / `APPLY_PACKAGE_DETAILS` | 申领单 |
| **质量** | `STERILIZE_DEVICE_DATA` | 灭菌设备原始曲线与三类监测结果 |
| | `BIOMONITORING` | 生物监测（三态） |
| | `QC_PACKING` / `QC_STERILIZE_PACKAGE` / `QC_BEFORE_STERILIZE` / `QC_DELIVERY` | 各环节质量检查 |
| | `RECALL_LIST` | 召回 |

---

## 附录 B　政策原文摘录（信息化建设一节）

> **（三）信息化建设。**
>
> 积极倡导信息化建设，优化县域医共体数据共享，推进人工智能、大数据、互联网、5G 等新一代信息技术应用，建立统一信息标准及质控标准的消毒供应中心信息系统。县域医共体成员单位通过系统提交申请，消毒供应中心根据申请提供可重复使用手术器械、检查器械、植入耗材的清洗消毒和灭菌等服务，逐步实现物品采购、申领、发放、使用、回收等全流程追溯。具体功能：物品申领、物品追溯、无菌物品发放、转运监管、成本核算、质量控制、统计分析等。
>
> **1. 基本要求**
>
> 消毒供应中心平台系统的建设，应以患者为中心，以 WS 310 有关要求为基础，县域医共体内各成员单位医院信息系统（HIS）可接入消毒供应中心信息追溯系统，通过信息系统为无菌物品的申请、回收与发放提供支持。
>
> **2. 核心功能要求**
>
> （1）消毒供应中心管理信息系统应具备人员、物资、质量控制等方面的管理应用功能和对物品接收、清洗消毒、检查包装及灭菌过程关键环节的质量追溯功能。无菌包外追溯码与患者信息关联，实现无菌物品全程可追溯，逐步实现人工智能全流程管理。
>
> （2）消毒供应中心信息追溯系统应采用追溯码进行记录、照相、追溯、管理控制，系统可连接医院 HIS 系统，也可独立运行使用。对于具备打印功能的清洗工作站、全自动清洗消毒机、灭菌器等，应支持追溯运行参数及打印参数；对于使用单位申领物品，支持申请、更换、调配三种模式。无菌物品管理信息系统具备通过无菌包接收、使用监控与统计报表模块实现对无菌包使用数据的收集与统计分析功能，持续提高医疗机构复用医疗器械的安全使用及管理。
>
> （3）应配置服务器、计算机、显示器、扫码枪和/或掌上电脑、打印机（包含条码打印机）等。

---

## 关于本手册与下一步

本手册由深圳市易企动力科技有限公司编制。政策原文摘自国家卫生健康委办公厅《紧密型县域医共体消毒供应中心建设与服务指南（试行）》（国卫办基层函〔2026〕184 号，2026-05-19 印发）；系统能力均对应到真实数据表与字段，可在演示环境验证。

**我们可以提供的下一步：**

| 项目 | 内容 |
|---|---|
| 区域化可行性评估 | 按你的机构数量、包种类、取送距离，评估建设规模与阶段划分 |
| 演示环境体验 | 脱敏演示库，可实际操作多机构、多价格、对账与追溯场景 |
| 数据初始化模板 | 机构 / 科室 / 包字典 / 价格 / 取包点 / 账号 的初始化 Excel 模板 |
| 定制能力评估 | 线路优化、双人签收、器具清洗消毒记录等定制项的工作量评估 |

**联系**：13510239158 ｜ info@sze7.com ｜ www.sze7.com

> **免责声明**：本手册政策条文摘自国家卫生健康委办公厅发布的指南原文，仅供对照参考，最终以官方发布文本为准；各地实施细则可能另有要求，请以本省（区、市）卫生健康行政部门的规定为准。系统侧能力基于当前版本，随版本迭代可能调整。运行数据为单一中心的实际运行数据，截至 2026 年 10 月；按公司对外口径，案例主体已匿名化处理。