# 共享医疗设备修理小程序 - 业务逻辑说明
> 规范同步：以 `momo-kit/specs/通用规范.md` 为准。
> 本模板中的流程图、时序图、架构图需与页面结构、接口契约、数据库设计保持一致。
---
## 1. 概述
本文档详细描述「共享医修通」省级医疗设备维修共享平台小程序的核心业务规则、状态流转逻辑和关键算法。平台连接医院科室、维修工程师、备件供应商和运营管理方，实现报修 → 派工 → 维修 → 验收 → 结算的闭环管理。数据表前缀：`medfix_`。
---
## 2. 用户角色与权限
### 2.1 角色定义
| 角色 | 标识 | 说明 | 主要权限 |
|------|------|------|----------|
| 科室报修员 | dept_reporter | 医院科室操作人员，发起设备报修 | 扫码报修、查看工单进度、验收签字、评价反馈 |
| 维修工程师 | engineer | 持证维修技术人员 | 接单、现场诊断、备件申领、维修记录、完工上报 |
| 仓库管理员 | warehouse | 备件仓库管理人员 | 备件入库/出库、库存盘点、低库存预警处理 |
| 院方设备科 | hospital_admin | 医院设备管理科室负责人 | 设备档案管理、工单审核、月度对账确认、数据报表 |
| 运营管理员 | operator | 平台运营管理人员 | 工程师管理、合同管理、结算审核、统计分析 |
| 系统管理员 | admin | 系统超级管理员 | 全部权限 |
### 2.2 权限矩阵
| 功能 | 科室报修员 | 维修工程师 | 仓库管理员 | 院方设备科 | 运营管理员 | 系统管理员 |
|------|-----------|-----------|-----------|-----------|-----------|-----------|
| 扫码/拍照报修 | ✅ | ❌ | ❌ | ✅ | ❌ | ✅ |
| 查看工单详情 | ✅(本科室) | ✅(本人) | ❌ | ✅(本院) | ✅ | ✅ |
| 接单/退单 | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ |
| 维修记录填写 | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ |
| 备件申领 | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ |
| 备件出入库 | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| 验收签字 | ✅ | ❌ | ❌ | ✅ | ❌ | ✅ |
| 设备档案管理 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
| 结算对账 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
| 工程师管理 | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
| 统计报表 | ❌ | ❌ | ❌ | ✅(本院) | ✅ | ✅ |
| 用户管理 | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
### 2.3 多身份入驻角色映射（新增）
| 申请身份 | applyType | 平台角色码(roleCode) | 小程序路由角色(roleType) | 审核责任方 |
|------|------|------|------|------|
| 工程师 | engineer | engineer | engineer | 运营管理员 + 系统管理员 |
| 供应商 | supplier | supplier | vendor | 运营管理员 + 财务复核 |
| 服务商 | service_provider | service_provider | vendor | 运营管理员 + 系统管理员 |
| 医院管理员 | hospital | hospital_admin | department | 平台超管 |
| 科室报修员 | department_user | dept_user | department | 医院管理员 |
**口径约束**：
- `applyType`：决定所需资质字段与审核流（例如工程师需证书，供应商需营业执照与结算账户）。
- `roleCode`：决定权限边界（菜单、接口、数据域）。
- `roleType`：决定小程序端展示入口（`department` / `engineer` / `vendor`）。
---
## 3. 核心业务状态流转
### 3.1 工单状态定义
| 状态 | 标识 | 说明 |
|------|------|------|
| 待派工 | 0 | 工单已创建，等待系统/运营派工 |
| 已派工 | 1 | 已分配工程师，等待工程师接单确认 |
| 维修中 | 2 | 工程师已到达现场，正在诊断或维修 |
| 待验收 | 3 | 维修完成，等待科室/设备科验收签字 |
| 已完成 | 4 | 验收通过，工单正常结束 |
| 已关闭 | 5 | 工单异常关闭（设备报废、重复报修等） |
| 已取消 | 6 | 报修方主动取消 |
### 3.2 状态流转规则
```
待派工(0) ──智能派工──> 已派工(1) ──工程师接单+到场──> 维修中(2) ──完工上报──> 待验收(3) ──验收通过──> 已完成(4)
│ │ │ │
└───报修取消──> 已取消(6) └───退单/转单──> 待派工(0) └───验收不通过──> 维修中(2) └───结算──> 已关闭(5)
```
**流转条件**：
- `待派工(0) → 已派工(1)`：系统智能派工或运营手动指派，需满足工程师持证且未超负载(≤5单)
- `已派工(1) → 维修中(2)`：工程师点击"到达现场"并通过GPS打卡(偏差≤500m)
- `维修中(2) → 待验收(3)`：工程师填写诊断记录、维修方案、完工照片，点击"完工上报"
- `待验收(3) → 已完成(4)`：科室报修员或设备科在小程序签字确认
- `待验收(3) → 维修中(2)`：验收不通过，需注明原因，工单回退继续维修
- `已派工(1) → 待派工(0)`：工程师退单(需注明原因)或运营转单
- `待派工(0) → 已取消(6)`：报修方取消，仅在未派工前允许
- `已完成(4) → 已关闭(5)`：结算完成或30天无活动自动关闭
### 3.3 状态流转 Mermaid 图
```mermaid
stateDiagram-v2
[*] --> 待派工
待派工 --> 已派工 : 智能派工/手动指派
待派工 --> 已取消 : 报修方取消
已派工 --> 维修中 : 工程师到场打卡
已派工 --> 待派工 : 退单/转单
维修中 --> 待验收 : 完工上报
待验收 --> 已完成 : 验收通过签字
待验收 --> 维修中 : 验收不通过
已完成 --> 已关闭 : 结算完成/超期自动关闭
已取消 --> [*]
已关闭 --> [*]
```
### 3.4 入驻申请状态机（新增）
| 状态 | 标识 | 说明 |
|------|------|------|
| 草稿 | draft | 用户已创建申请单但未提交 |
| 待初审 | pending_initial | 平台资料完整性校验 |
| 待复审 | pending_business | 业务资质复核（资质、合作关系、结算信息） |
| 待补件 | need_more | 审核驳回，等待补充材料 |
| 已通过 | approved | 审核通过，进入账号激活 |
| 已拒绝 | rejected | 审核不通过且流程终止 |
| 已激活 | activated | 账号开通并完成角色绑定 |
| 申请人已撤销 | revoked | 申请人在未通过前主动撤销 |
| 平台已作废 | voided | 审核端作废（重复申请、黑名单、长期不合规） |
```mermaid
stateDiagram-v2
[*] --> 草稿
草稿 --> 待初审 : 提交申请
待初审 --> 待复审 : 资料完整
待初审 --> 待补件 : 缺少材料
待复审 --> 已通过 : 复审通过
待复审 --> 待补件 : 资质补正
待复审 --> 已拒绝 : 不符合准入标准
待初审 --> 申请人已撤销 : 申请人撤销
待复审 --> 申请人已撤销 : 申请人撤销
待补件 --> 申请人已撤销 : 申请人撤销
待初审 --> 平台已作废 : 平台作废
待复审 --> 平台已作废 : 平台作废
待补件 --> 平台已作废 : 平台作废
待补件 --> 待初审 : 重新提交
已通过 --> 已激活 : 开通账号+角色绑定
已拒绝 --> [*]
已激活 --> [*]
申请人已撤销 --> [*]
平台已作废 --> [*]
```
**审核分流规则**：
- 工程师/服务商：必须提交执业资质与服务区域；复审校验资质有效期。
- 供应商：必须提交营业执照、对公结算信息、主营品类。
- 医院管理员：由平台超管审核医院主体，审核通过后可邀请科室报修员。
- 科室报修员：由院方管理员审核并绑定科室。
### 8.3 审核管理与作废逻辑（新增）
| 场景 | 动作 | 状态流转 | 约束 |
|------|------|----------|------|
| 申请人主动取消 | revoke | `pending_initial/pending_business/need_more -> revoked` | 已通过、已激活状态禁止撤销 |
| 平台人工作废 | void | `pending_initial/pending_business/need_more -> voided` | 必填作废原因、作废人、作废时间 |
| 重复申请作废 | void_duplicate | 新申请作废，保留最早有效申请 | 同手机号+同身份+同主体 30 天仅保留 1 个有效单 |
| 黑名单命中作废 | void_blacklist | 直接作废并记录风险标签 | 命中黑名单后禁止再次提交，需人工解封 |
| 补件超时作废 | void_timeout | `need_more -> voided` | 超过补件时限（默认 7 天）自动作废 |
**审计要求**：
- 所有 `revoke/void` 动作必须写入 `medfix_join_apply_audit`；
- `voided` 申请单不可重新激活，只能新建申请单；
- 前端必须展示作废原因与历史审核记录。
### 3.5 关键时序图
#### 3.5.1 报修工单流程
```mermaid
sequenceDiagram
autonumber
actor Dept as 科室报修员
participant MP as 小程序
participant API as API网关
participant WO as 工单服务
participant Dispatch as 派工引擎
participant Queue as 消息队列
participant DB as MySQL/Redis
actor Eng as 维修工程师
Dept->>MP: 扫描设备二维码/拍照
MP->>API: POST /app/medfix/workOrder/create
API->>WO: 参数校验+幂等检查(userId+deviceId+24h)
WO->>DB: 创建工单(status=0)
WO->>Queue: 发布 event:workorder.created
Queue->>Dispatch: 触发智能派工
Dispatch->>DB: 查询可用工程师(技能+位置+负载)
Dispatch->>DB: 更新工单(status=1, engineerId)
Dispatch->>Queue: 发布 event:workorder.dispatched
Queue-->>Eng: 微信模板消息推送
API-->>MP: 返回工单编号
MP-->>Dept: 显示报修成功+预计响应时间
Eng->>MP: 查看工单详情，点击"接单"
Eng->>MP: 到达现场，GPS打卡
MP->>API: POST /app/medfix/workOrder/arrive
API->>WO: 校验GPS距离(≤500m)
WO->>DB: 更新工单(status=2, arriveTime)
WO->>Queue: 发布 event:workorder.arrived
Queue-->>Dept: 推送"工程师已到达"
Eng->>MP: 填写诊断记录+维修方案
alt 需要备件
Eng->>MP: 发起备件申领
MP->>API: POST /app/medfix/parts/requisition
end
Eng->>MP: 上传完工照片，点击"完工上报"
MP->>API: POST /app/medfix/workOrder/complete
API->>WO: 更新工单(status=3)
WO->>Queue: 发布 event:workorder.completed
Queue-->>Dept: 推送"维修完成待验收"
Dept->>MP: 查看维修结果，签字验收
MP->>API: POST /app/medfix/workOrder/accept
API->>WO: 更新工单(status=4, acceptTime)
WO->>Queue: 发布 event:workorder.accepted
Queue-->>Eng: 推送"验收通过"
```
#### 3.5.2 备件申领流程
```mermaid
sequenceDiagram
autonumber
actor Eng as 维修工程师
participant MP as 小程序
participant API as API网关
participant Parts as 备件服务
participant DB as MySQL
actor WH as 仓库管理员
Eng->>MP: 选择所需备件+数量
MP->>API: POST /app/medfix/parts/requisition
API->>Parts: 校验库存是否充足
Parts->>DB: 创建申领单(status=pending)
Parts-->>API: 返回申领单号
API-->>MP: 显示申领提交成功
Parts->>WH: 推送审批通知
WH->>MP: 查看申领单，审批通过
MP->>API: POST /admin/medfix/parts/approve
API->>Parts: 更新申领单(status=approved)
Parts->>DB: 扣减库存+创建出库记录
alt 库存低于阈值
Parts->>DB: 触发低库存预警
end
Parts-->>Eng: 推送"备件已出库"
Eng->>MP: 安装使用，确认消耗
MP->>API: POST /app/medfix/parts/confirm
API->>Parts: 更新申领单(status=used)
alt 有旧件退回
Eng->>MP: 登记旧件退回
MP->>API: POST /app/medfix/parts/return
API->>Parts: 创建退件记录
end
```
### 3.5 端到端流程图
```mermaid
flowchart TD
A[科室扫码/拍照报修] --> B[前端参数校验]
B --> C{幂等检查}
C -->|重复| C1[返回已有工单]
C -->|通过| D[创建工单 status=0]
D --> E[智能派工引擎]
E --> F{匹配工程师}
F -->|成功| G[工单派工 status=1]
F -->|无可用| F1[进入等待队列+告警运营]
G --> H[工程师接单确认]
H --> I[到场GPS打卡 status=2]
I --> J[诊断+维修]
J --> K{需要备件?}
K -->|是| L[备件申领→审批→出库]
K -->|否| M[继续维修]
L --> M
M --> N[完工上报 status=3]
N --> O{科室验收}
O -->|通过| P[工单完成 status=4]
O -->|不通过| J
P --> Q[费用汇总→月度结算]
Q --> R[工单关闭 status=5]
```
### 3.5.0 系统上下文图（C4-Context）
> **用途**：向院方信息科、运营方说明「共享医修通」与医院、工程师、供应商及外部系统之间的边界与数据交换；**关注点**：谁发起报修、谁执行维修、谁供货、哪些能力依赖微信/地图/OSS。
```mermaid
flowchart TB
subgraph actors [外部参与者]
HDept[医院科室与设备科]
Eng[持证维修工程师]
Sup[备件供应商与厂家]
Ops[平台运营方]
end
subgraph medfix [共享医修通软件系统]
Core[工单派工维修结算内核]
end
subgraph external [外部系统]
Wx[微信开放平台
登录与订阅消息]
Map[地图服务
定位与派工距离]
Oss[对象存储
照片与报告]
Sms[短信网关
验证码与告警]
His[可选 HIS 或资产系统
设备台账同步]
end
HDept -->|报修验收评价| Core
Eng -->|接单打卡维修记录| Core
Sup -->|报价发货对账| Core
Ops -->|配置监管统计| Core
Core --> Wx
Core --> Map
Core --> Oss
Core --> Sms
Core -.->|二期可选| His
```
### 3.5.1 架构视图说明（四类架构 + 4+1，与 C4 并存）
> 本文档要求：**业务架构**、**逻辑视图**与 **C4 Context/Container** 并存——Context 描述系统与外部环境边界；**逻辑视图**描述**功能组件**及其关系（不必等同于部署上的单个进程）；**容器视图**（原系统架构图）描述典型运行容器与分层。术语与映射以 `momo-kit/specs/通用规范.md` 阶段二为准，不在项目文档中引用外部文章链接。
| 四类架构 | 本文档中的位置 | 说明 |
|---------|----------------|------|
| 业务架构（产品架构） | 3.5.2 | 设备管理域、报修服务域、维修执行域、备件供应域、结算域、运营域 |
| 应用架构 | 3.5.3 + 3.6 容器视图 | 逻辑组件 + 运行分层 |
| 数据架构 | 以 `database_schema.md` / ER 为准 | medfix_ 前缀表结构 |
| 技术架构 | `tech_reference.md` | Cool Admin Midway + uni-app x + MySQL + Redis |
| 4+1 视图 | 本文档中的位置 |
|---------|----------------|
| 场景视图（+1） | 3.5 端到端流程、本节主场景列表、`interaction_map.html` |
| 逻辑视图 | **3.5.3** |
| 处理视图 | 3.4 时序图、3.5 活动图 |
| 物理视图 | `tech_reference.md` 部署章节 |
| 开发视图 | `code/README.md` / `code/todos.plan.md` |
**主场景路径（1~3 条，阶段二必填）**：
1. 报修 → 派工 → 维修 → 验收闭环（核心主流程）
2. 备件申领 → 审批出库 → 安装使用 → 旧件退回
3. 月度结算 → 院方确认 → 开票付款
### 3.5.2 业务架构（产品架构）
```mermaid
flowchart TB
root[共享医修通产品边界]
root --> domainA[设备管理域]
root --> domainB[报修服务域]
root --> domainC[维修执行域]
root --> domainD[备件供应域]
root --> domainE[结算域]
root --> domainF[运营域]
domainA --> capA1[设备档案管理]
domainA --> capA2[设备二维码生成]
domainA --> capA3[合同/保修管理]
domainA --> capA4[设备生命周期追踪]
domainB --> capB1[扫码/拍照报修]
domainB --> capB2[工单创建与跟踪]
domainB --> capB3[紧急度分级]
domainB --> capB4[报修历史查询]
domainC --> capC1[智能派工引擎]
domainC --> capC2[工程师接单管理]
domainC --> capC3[现场诊断记录]
domainC --> capC4[维修过程拍照]
domainC --> capC5[验收签字确认]
domainD --> capD1[备件库存管理]
domainD --> capD2[备件申领审批]
domainD --> capD3[出入库管理]
domainD --> capD4[低库存预警]
domainD --> capD5[旧件回收]
domainE --> capE1[工时费用计算]
domainE --> capE2[备件费用汇总]
domainE --> capE3[月度对账单]
domainE --> capE4[院方确认与开票]
domainF --> capF1[工程师管理与认证]
domainF --> capF2[服务合同管理]
domainF --> capF3[SLA监控与预警]
domainF --> capF4[数据统计大屏]
domainF --> capF5[系统配置管理]
```
### 3.5.3 逻辑视图（功能组件关系）
```mermaid
flowchart LR
subgraph presentation [展现与接入层]
miniApp[科室报修小程序]
engApp[工程师端小程序]
adminPanel[运营管理后台]
gw[API网关]
end
subgraph application [应用服务层]
woSvc[工单服务]
dispatchSvc[派工引擎]
deviceSvc[设备服务]
partsSvc[备件服务]
settleSvc[结算服务]
statsSvc[统计服务]
end
subgraph domain [领域层]
woEntity[工单聚合根]
deviceEntity[设备实体]
engEntity[工程师实体]
partsEntity[备件实体]
contractEntity[合同实体]
settleEntity[账单实体]
end
subgraph crossCut [横切能力]
auth[认证授权]
notify[消息通知]
location[定位服务]
file[文件存储]
end
subgraph infra [基础设施层]
db[(MySQL)]
cache[(Redis)]
oss[(对象存储)]
mq[消息队列]
end
miniApp --> gw
engApp --> gw
adminPanel --> gw
gw --> auth
auth --> woSvc
auth --> deviceSvc
gw --> woSvc
gw --> deviceSvc
gw --> partsSvc
gw --> settleSvc
gw --> statsSvc
woSvc --> dispatchSvc
woSvc --> notify
woSvc --> location
dispatchSvc --> location
partsSvc --> notify
settleSvc --> notify
woSvc --> woEntity
deviceSvc --> deviceEntity
dispatchSvc --> engEntity
partsSvc --> partsEntity
settleSvc --> settleEntity
woEntity --> db
deviceEntity --> db
engEntity --> cache
partsEntity --> db
settleEntity --> db
notify --> mq
file --> oss
```
### 3.6 容器视图（C4-Container / 运行态架构）
```mermaid
flowchart LR
subgraph Client["客户端层"]
C1[科室报修小程序
uni-app x]
C2[工程师端小程序
uni-app x]
C3[运营管理后台
Cool Admin Vue]
end
subgraph Gateway["接入层"]
G1[Nginx + API网关]
end
subgraph Service["业务服务层
Cool Admin Midway"]
S1[工单模块]
S2[设备模块]
S3[备件模块]
S4[结算模块]
S5[派工引擎]
S6[统计模块]
end
subgraph Data["数据层"]
D1[(MySQL
medfix_*)]
D2[(Redis
缓存/队列)]
D3[(OSS
图片/文件)]
end
C1 --> G1
C2 --> G1
C3 --> G1
G1 --> S1
G1 --> S2
G1 --> S3
G1 --> S4
G1 --> S6
S1 --> S5
S1 --> D1
S1 --> D2
S2 --> D1
S2 --> D2
S3 --> D1
S4 --> D1
S5 --> D2
S6 --> D1
S1 --> D3
S2 --> D3
```
### 3.7 架构路线决策与客户选择
| 项目 | 填写值 |
|------|------|
| 当前业务类型 | 企业协同型（多角色协作工单驱动） |
| 当前部署环境 | 单云（阿里云） |
| 目标负载档位 | L1（省级平台、中等并发） |
| 主推荐路线 | R1（单体 + 模块化） |
| 次推荐路线（可选） | R2（微服务拆分，备件/结算独立） |
| 客户最终选择 | R1 |
| 选择原因 | 交付效率优先，初期用户量可控，模块化架构支持后续拆分 |
```mermaid
flowchart TD
collectCtx[收集环境与业务约束
省级平台/多医院/多角色] --> loadTier[确定L1标准档位
QPS≤500 并发≤200]
loadTier --> recommendRoutes[主推R1单体模块化
次推R2微服务]
recommendRoutes --> showCards[展示R1快速交付优势
R2扩展性优势]
showCards --> customerConfirm[客户确认R1路线]
customerConfirm --> bindArtifacts[绑定出图清单
上下文图+容器图+关键时序图]
```
> 路线示意图与简介卡片统一维护在 `doc/tech_reference.md`，本节仅记录业务决策结果与原因。
### 3.8 负载档位与出图清单
| 档位 | 必出图 | 核心目标 |
|------|------|------|
| L0 | 上下文图 + 容器图（简版）+ 单点部署图 | 明确边界与基础链路 |
| L1 | L0 + 关键时序图 | 明确关键流程与失败分支 |
| L2 | L1 + 可观测性闭环图 + 集群拓扑图 | 支撑自动治理与扩缩容 |
| L3 | L2 + 多租户隔离图 + 跨区容灾图 + 安全分级图 | 满足合规与高可用 |
| 升级触发指标 | 当前值 | 预警阈值 | 严重阈值 | 处理动作 |
|------|------|------|------|------|
| QPS | 50 | 300 | 500 | 接口限流 + Redis 缓存前置 |
| P95 延迟 | 120ms | 500ms | 1000ms | 慢查询优化 / 隔离热点接口 |
| 错误率 | 0.1% | 1% | 5% | 降级统计大屏 / 回滚最近发布 |
| 租户数(医院) | 5 | 50 | 200 | 升级为按院隔离 Schema |
| 队列积压 | 0 | 1000 | 5000 | 扩容消费者 / 限流报修入口 |
### 3.9 开发任务关系图（开发视图）
> 数据来源建议：`code/todos.plan.md`、`doc/plan/*.plan.md`、`code/plans/*.plan.md`。
> 要求：任务节点使用英文/camelCase 作为 ID，中文写在 `[]` 标签中；任务状态变更后需同步更新本图与 `index.html` 扩展区入口说明。
```mermaid
flowchart TD
subgraph iter1 [迭代1 - 基础能力]
reqReview[需求评审与口径冻结]
docBaseline[文档基线补齐]
deviceArchive[设备档案管理]
deviceQrcode[设备二维码生成]
repairCreate[报修工单创建]
repairTrack[工单进度跟踪]
end
subgraph iter2 [迭代2 - 核心流程]
dispatchEngine[智能派工引擎]
engineerAccept[工程师接单管理]
onSiteRepair[现场维修记录]
acceptSign[验收签字确认]
orderStateMachine[工单状态机完善]
end
subgraph iter3 [迭代3 - 供应链]
partsInventory[备件库存管理]
partsRequisition[备件申领审批]
partsInOut[出入库管理]
partsAlert[低库存预警]
oldPartsReturn[旧件回收]
end
subgraph iter4 [迭代4 - 运营结算]
costCalc[工时与备件费用计算]
monthlySettle[月度结算对账]
invoiceFlow[开票付款流程]
statsDashboard[统计分析大屏]
slaMonitor[SLA监控预警]
contractMgmt[合同到期管理]
end
reqReview --> docBaseline
docBaseline --> deviceArchive
docBaseline --> deviceQrcode
deviceArchive --> repairCreate
deviceQrcode --> repairCreate
repairCreate --> repairTrack
repairTrack --> dispatchEngine
repairTrack --> orderStateMachine
dispatchEngine --> engineerAccept
engineerAccept --> onSiteRepair
onSiteRepair --> acceptSign
orderStateMachine --> acceptSign
onSiteRepair --> partsRequisition
partsInventory --> partsRequisition
partsRequisition --> partsInOut
partsInOut --> partsAlert
partsInOut --> oldPartsReturn
acceptSign --> costCalc
partsInOut --> costCalc
costCalc --> monthlySettle
monthlySettle --> invoiceFlow
acceptSign --> statsDashboard
costCalc --> statsDashboard
statsDashboard --> slaMonitor
docBaseline --> contractMgmt
contractMgmt --> slaMonitor
```
---
## 4. 核心业务规则
### 4.1 设备二维码唯一性规则
**规则描述**：每台设备在同一医院内拥有唯一二维码标识，二维码编码规则为 `{hospitalId}-{deviceTypeCode}-{序列号}`，全局唯一。
**触发条件**：
- 设备入档时生成二维码
- 设备转院时旧码作废、新院重新编码
**处理逻辑**：
1. 校验 `hospitalId + deviceCode` 组合在 `medfix_device` 表中唯一
2. 生成二维码图片并存储至 OSS
3. 设备档案关联二维码 URL
**异常处理**：
- 二维码重复：拒绝入档，提示"该设备编码已存在"
- 二维码损坏：支持设备科通过后台重新生成（旧码失效）
### 4.2 工单自动关闭规则
**规则描述**：工单状态为"已完成"后超过30天无结算活动，系统自动关闭工单并归档。
**触发条件**：
- 定时任务每日 02:00 扫描 `status=4` 且 `updateTime < NOW() - 30天` 的工单
**处理逻辑**：
1. 批量更新工单状态为"已关闭(5)"
2. 生成关闭日志记录原因为"超期自动关闭"
3. 已关闭工单的维修记录和费用数据保留，不可再修改
### 4.3 工程师并发工单上限
**规则描述**：单个工程师同时持有的进行中工单（status=1或2）不超过5个。
**触发条件**：
- 智能派工引擎分配工单时
- 运营手动指派工单时
**处理逻辑**：
1. 查询该工程师 `status IN (1,2)` 的工单数量
2. 若 ≥ 5，该工程师不参与本次派工候选
3. 手动指派时提示"该工程师当前工单已满"
### 4.4 备件低库存自动预警
**规则描述**：当备件库存数量低于预设阈值时，自动触发预警通知仓库管理员和运营。
**触发条件**：
- 备件出库后库存变动时实时检测
- 每日 08:00 定时扫描全量备件库存
**处理逻辑**：
1. 比较 `currentStock` 与 `alertThreshold`
2. 若 `currentStock ≤ alertThreshold`，创建预警记录
3. 推送微信模板消息给仓库管理员
4. 预警状态持续直到补货入库后库存恢复
**异常处理**：
- 阈值未设置：使用默认阈值 5 件
- 消息推送失败：写入延迟队列重试
### 4.5 合同到期预警规则
**规则描述**：设备维保合同到期前自动分级预警，提醒院方和运营续约。
**触发条件**：
- 每日 09:00 定时任务扫描合同到期时间
**处理逻辑**：
1. 到期前 30 天：推送提醒（info 级别）
2. 到期前 15 天：推送预警（warning 级别）
3. 到期前 7 天：推送紧急通知（danger 级别）+ 短信
4. 已过期合同：标记为"已过期"，相关设备报修时提示"合同已过期"
### 4.6 结算周期与确认规则
**规则描述**：费用按月汇总结算，次月5日前由院方确认。
**触发条件**：
- 每月1日 00:00 自动生成上月结算单
**处理逻辑**：
1. 汇总上月所有 `status=4或5` 工单的工时费用和备件费用
2. 按医院维度生成对账单（medfix_settlement）
3. 推送院方设备科确认
4. 院方5日前完成确认，超期未确认的自动标记"待催办"
5. 确认后生成开票申请
### 4.7 SLA 响应时效规则
**规则描述**：根据报修紧急度分级，要求不同的响应时效和到场时效。
| 紧急度 | 标识 | 响应时效 | 到场时效 | 说明 |
|--------|------|---------|---------|------|
| 普通 | normal | 4小时 | 8小时 | 常规故障，不影响诊疗 |
| 紧急 | urgent | 2小时 | 4小时 | 影响科室正常工作 |
| 特急 | critical | 30分钟 | 1小时 | 急诊/ICU等关键设备 |
**处理逻辑**：
1. 工单创建时根据设备所在科室和故障描述自动判定紧急度
2. 超过响应时效未派工：自动升级并通知运营管理员
3. 超过到场时效未到达：工单标记"SLA超时"，纳入月度考核
4. SLA 达标率纳入统计大屏实时展示
### 4.8 高负载与稳定性控制规则
#### 4.8.0 分级策略开关（L0~L3）
| 能力域 | L0 入门 | L1 标准 | L2 增强 | L3 企业 |
|------|---------|---------|---------|---------|
| 幂等与防重 | 创建类接口必选 | 关键交易全覆盖 | 全链路覆盖 | 全链路 + 跨服务一致性 |
| 缓存治理 | 基础TTL | TTL+抖动+热点保护 | 分层缓存+自动失效策略 | 多级缓存+容量治理 |
| 错误治理 | 基础捕获 | 分级告警 | 自动恢复闭环 | 错误预算治理 |
| 演练机制 | 可选 | 月度演练 | 双周演练 | 周度演练+季度容灾 |
| 数据库安全 | 最小权限 | TLS+脱敏 | 存储加密+审计 | 行列级权限+KMS+容灾 |
#### 4.8.1 幂等与防重
| 场景 | 幂等键建议 | 防重策略 | 失败补偿 |
|------|-----------|----------|----------|
| 报修工单创建 | `reportUserId + deviceId + 24h时间窗口` | Redis SET NX 300ms去重 + DB唯一索引 | 返回已有工单信息 |
| 备件申领 | `engineerId + workOrderId + partsId` | 数据库唯一约束 | 提示重复申领 |
| 验收签字 | `workOrderId + acceptUserId` | 状态机校验(仅status=3可验收) | 返回当前工单状态 |
| 结算确认 | `settlementId + confirmUserId` | 状态机 + 乐观锁版本号 | 重试后人工对账 |
#### 4.8.2 缓存与一致性
| 策略项 | 默认做法 | 说明 |
|------|---------|------|
| 设备信息缓存 | Cache Aside，TTL 60min + 随机抖动±5min | 设备档案读多写少 |
| 工程师位置缓存 | Redis GEO，TTL 30s 覆盖更新 | 支撑派工距离计算 |
| 工单列表缓存 | 不缓存，直接查DB | 状态频繁变更，缓存收益低 |
| 备件库存 | Cache Aside，TTL 5min | 出入库时主动失效 |
| 统计大屏数据 | 预计算写入Redis，TTL 5min | 降级时返回静态快照 |
#### 4.8.2.1 多地一致性与冲突处理
| 业务对象 | 一致性要求 | 默认策略 | 冲突处理 | 容忍延迟 |
|------|------|------|------|------|
| 工单状态流转 | 强一致优先 | 单主写入 + 状态机校验 + 乐观锁 | 版本冲突拒绝 + 提示刷新 | 秒级 |
| 工程师位置上报 | 最终一致 | 异步覆盖写入Redis GEO | LWW（最后写入胜出） | 30秒级 |
| 统计报表 | 最终一致 | 定时批处理聚合 | 重算覆盖 | 小时级 |
#### 4.8.2.2 Outbox/Inbox 与补偿
| 链路 | 机制 | 关键规则 | 风险控制 |
|------|------|------|------|
| 工单创建→派工通知 | Outbox | 工单写入与Outbox同事务提交 | 轮询重试3次 + 死信队列 |
| 派工结果→工程师推送 | Inbox | 以 `workOrderId+engineerId` 去重 | 去重窗口24h + 过期清理 |
| 验收→结算汇总 | Saga补偿 | 前向执行验收确认 + 反向补偿取消验收 | 超时1h终止 + 人工补单 |
#### 4.8.3 可观测性与错误捕获
| 维度 | 采集内容 | 最低要求 |
|------|---------|----------|
| 前端事件 | 报修提交、验收签字、页面停留时长、扫码成功率 | 报修+验收路径全覆盖 |
| 后端事件 | 接口耗时、派工匹配时间、备件出库延迟、SLA超时率 | 所有核心接口全覆盖 |
| 错误捕获 | JS异常、接口5xx、派工失败、推送失败、GPS定位异常 | 接入 Sentry |
| 保全字段 | `traceId`、`hospitalId`、`workOrderId`、脱敏参数快照 | 便于回放与复盘 |
#### 4.8.4 错误节点恢复
1. 自动检测：通过派工失败率、推送成功率、接口错误率识别异常节点。
2. 自动处置：派工引擎降级为手动派工模式；推送失败进入延迟重试队列；接口异常触发限流。
3. 数据保全：保留故障窗口内所有工单创建和状态变更事件。
4. 自动恢复：异常服务恢复后灰度回流流量，派工引擎自动切回智能模式。
5. 人工接管：自动恢复失败时告警运营管理员，切换为全手动派工模式。
#### 4.8.5 数据库安全与合规联动
| 项目 | 默认要求 | 说明 |
|------|---------|------|
| 权限控制 | 应用账号仅授予 medfix_* 表的 CRUD 权限 | 禁止 DROP/ALTER |
| 数据脱敏 | 报修人手机号、工程师身份证号导出时脱敏 | 中间四位替换为 **** |
| 审计留痕 | 工单状态变更、备件出入库、结算确认均记录操作人和时间 | 保留180天 |
| 备份恢复 | RPO 1小时 / RTO 4小时，月度恢复演练 | 增量备份每小时 |
| 租户隔离 | 按 hospitalId 做数据行级隔离 | 所有查询附带 hospitalId 条件 |
#### 4.8.6 流量治理与读写优化（高并发）
| 策略 | 适用场景 | 默认做法 |
|------|----------|----------|
| 网关限流 | 报修接口保护 | 令牌桶：单用户10次/min，全局1000 QPS |
| 热点隔离 | 大型医院集中报修 | 按 hospitalId 独立限流，热点医院单独队列 |
| 熔断降级 | 派工引擎/推送服务故障 | 派工降级为手动模式，推送降级为延迟队列 |
| 削峰填谷 | 上班高峰期集中报修 | MQ缓冲 + 异步派工 |
| 多级缓存 | 设备信息/工程师列表 | 本地缓存(Caffeine) + Redis |
| 批处理 | 月度结算/统计报表 | 凌晨定时任务，与在线链路隔离 |
---
## 5. 关键算法
### 5.1 智能派工算法
**用途**：根据工单紧急度、工程师技能匹配度、地理距离和当前工作负载，自动选择最优工程师。
**算法描述**：
```
function dispatch(workOrder):
candidates = getAvailableEngineers(workOrder.hospitalArea)
candidates = candidates.filter(e => e.activeOrders < 5)
candidates = candidates.filter(e => e.skills.includes(workOrder.deviceType))
if candidates.isEmpty():
return MANUAL_DISPATCH_QUEUE
for each engineer in candidates:
urgencyScore = getUrgencyWeight(workOrder.urgency)
skillScore = calcSkillMatch(engineer.skills, workOrder.deviceType, workOrder.brand)
distanceScore = calcDistanceScore(engineer.location, workOrder.hospital.location)
loadScore = calcLoadScore(engineer.activeOrders, MAX_ORDERS=5)
engineer.totalScore = urgencyScore * 0.3
+ skillScore * 0.35
+ distanceScore * 0.2
+ loadScore * 0.15
bestEngineer = candidates.sortByScoreDesc().first()
if bestEngineer.totalScore < THRESHOLD(60):
return MANUAL_DISPATCH_QUEUE
return assignWorkOrder(workOrder, bestEngineer)
```
**参数说明**：
| 参数 | 类型 | 说明 |
|------|------|------|
| urgencyScore | number(0-100) | 紧急度权重：普通=30, 紧急=70, 特急=100 |
| skillScore | number(0-100) | 技能匹配度：完全匹配=100, 同品类=60, 仅基础=30 |
| distanceScore | number(0-100) | 距离得分：≤5km=100, ≤15km=70, ≤30km=40, >30km=10 |
| loadScore | number(0-100) | 负载得分：0单=100, 1单=80, 2单=60, 3单=40, 4单=20 |
| THRESHOLD | number | 派工最低分数阈值，低于此值转人工派工 |
### 5.2 SLA 超时检测算法
**用途**：实时检测工单是否超过 SLA 规定的响应时效和到场时效。
**算法描述**：
```
function checkSlaTimeout():
openOrders = query("SELECT * FROM medfix_work_order WHERE status IN (0, 1)")
for each order in openOrders:
sla = getSlaConfig(order.urgency)
elapsed = NOW() - order.createTime
if order.status == 0 AND elapsed > sla.responseTime:
markSlaTimeout(order, 'response_timeout')
escalateToOperator(order)
if order.urgency != 'critical':
upgradeUrgency(order)
if order.status == 1 AND elapsed > sla.arriveTime:
markSlaTimeout(order, 'arrive_timeout')
notifyEngineerAndOperator(order)
```
**参数说明**：
| 参数 | 类型 | 说明 |
|------|------|------|
| sla.responseTime | duration | 响应时效：普通4h/紧急2h/特急30min |
| sla.arriveTime | duration | 到场时效：普通8h/紧急4h/特急1h |
| escalateToOperator | function | 升级通知运营管理员 |
| upgradeUrgency | function | 自动升级紧急度等级 |
---
## 6. 数据校验规则
### 6.1 报修工单数据校验
| 字段 | 规则 | 说明 |
|------|------|------|
| deviceId | 必填，存在于 medfix_device 表 | 设备必须已入档 |
| faultDesc | 必填，5~500字 | 故障描述 |
| faultPhotos | 至少1张，最多9张 | 现场照片 |
| urgency | 必填，枚举: normal/urgent/critical | 紧急度 |
| contactName | 必填，2~20字 | 报修联系人 |
| contactPhone | 必填，手机号正则 `/^1[3-9]\d{9}$/` | 联系电话 |
| reportUserId | 必填，JWT自动注入 | 报修人 |
### 6.2 设备档案数据校验
| 字段 | 规则 | 说明 |
|------|------|------|
| deviceName | 必填，2~100字 | 设备名称 |
| deviceCode | 必填，同一 hospitalId 下唯一 | 设备编码 |
| brand | 必填 | 品牌厂商 |
| model | 必填 | 型号规格 |
| hospitalId | 必填，存在于医院表 | 所属医院 |
| deptId | 必填，存在于科室表 | 所属科室 |
| purchaseDate | 选填，不晚于今天 | 购置日期 |
| warrantyExpiry | 选填，晚于 purchaseDate | 保修截止日 |
### 6.3 维修记录数据校验
| 字段 | 规则 | 说明 |
|------|------|------|
| diagnosisDesc | 必填，10~2000字 | 诊断描述 |
| repairMethod | 必填，枚举: replace/repair/adjust/clean/other | 维修方式 |
| repairPhotos | 至少2张(维修前+维修后) | 维修照片 |
| workHours | 必填，0.5~48，精确到0.5 | 工时(小时) |
### 6.4 备件申领数据校验
| 字段 | 规则 | 说明 |
|------|------|------|
| workOrderId | 必填，存在且 status=2 | 关联工单 |
| partsId | 必填，存在于备件表 | 备件编号 |
| quantity | 必填，正整数，≤当前库存 | 申领数量 |
| reason | 必填，10~200字 | 申领原因 |
---
## 7. 通知与消息
### 7.1 消息类型
| 类型 | 触发场景 | 接收方 | 渠道 |
|------|---------|--------|------|
| 报修成功通知 | 工单创建成功 | 科室报修员 | 微信模板消息 |
| 新工单派工通知 | 智能派工完成 | 维修工程师 | 微信模板消息 + 站内消息 |
| 工程师到场通知 | 工程师GPS打卡 | 科室报修员 | 微信模板消息 |
| 维修完成待验收 | 工程师完工上报 | 科室报修员 + 院方设备科 | 微信模板消息 |
| 验收结果通知 | 验收通过或不通过 | 维修工程师 | 微信模板消息 |
| 备件申领审批通知 | 工程师提交申领 | 仓库管理员 | 微信模板消息 + 站内消息 |
| 备件出库通知 | 审批通过出库 | 维修工程师 | 站内消息 |
| 低库存预警 | 库存低于阈值 | 仓库管理员 + 运营管理员 | 微信模板消息 |
| SLA 超时预警 | 响应/到场超时 | 运营管理员 | 微信模板消息 + 短信 |
| 合同到期预警 | 到期前30/15/7天 | 院方设备科 + 运营管理员 | 微信模板消息 |
| 月度结算通知 | 对账单生成 | 院方设备科 | 微信模板消息 |
| 结算确认催办 | 超期未确认 | 院方设备科 | 微信模板消息 + 短信 |
| 稳定性告警 | 错误率超阈值、派工引擎异常、推送服务故障 | 运维/开发负责人 | 企业微信/钉钉/邮件/webhook |
---
## 8. 多身份入驻审核逻辑（新增）
### 8.1 入驻流程规则
| 阶段 | 处理方 | 关键规则 |
|------|------|----------|
| 提交申请 | 申请人（小程序） | 按 `applyType` 校验必填资料，支持草稿与提交 |
| 平台初审 | 运营管理员 | 检查基础字段与附件完整性，不完整则驳回补件 |
| 业务复审 | 运营/财务/超管 | 按身份差异化校验（资质有效期、结算账户、医院主体） |
| 结果处理 | 审核端 | 通过则进入激活；拒绝则归档并通知原因 |
| 账号激活 | 系统管理员 | 创建账号、绑定 `roleCode` 与 `roleType`、发送激活通知 |
### 8.2 审核分流
- `engineer`：校验证书、执业范围、服务区域；
- `supplier`：校验营业执照、主营品类、对公账户；
- `service_provider`：校验机构资质与可挂靠工程师名单；
- `hospital`：校验医院主体信息与管理员授权；
- `department_user`：由已审核通过的医院管理员进行二次确认绑定。
---
## 9. 销售推广与归因逻辑（新增）
### 9.1 推广主流程
```mermaid
flowchart TD
A[创建推广活动] --> B[渠道投放]
B --> C[线索进入小程序]
C --> D[提交入驻申请]
D --> E[审核通过]
E --> F[账号激活]
F --> G[归因报表汇总]
```
### 9.2 关键业务规则
| 规则 | 说明 |
|------|------|
| 渠道唯一编码 | 每个推广活动生成 `campaignCode`，用于线索与转化归因 |
| 线索去重 | 同手机号 + 同身份 30 天内去重，避免重复统计 |
| 转化定义 | 至少统计注册、提交申请、审核通过、激活四级转化 |
| 归因口径 | 以“最后有效触点”作为主口径，支持“首次触点”对比 |
| 成本核算 | 活动预算 / 激活数 = CAC；活动预算 / 审核通过数 = CPL（通过） |
### 9.3 推广字段约束
| 字段 | 规则 | 说明 |
|------|------|------|
| campaignCode | 必填，唯一 | 推广活动编码 |
| leadType | 枚举：engineer/supplier/service_provider/hospital/department_user | 线索身份 |
| eventType | 枚举：visit/register/apply_submit/apply_approved/activated | 转化事件类型 |
| eventTime | 必填，UTC+8 时间戳 | 用于漏斗排序与归因窗口 |
---
## 12. 补充基座能力（竞品调研）
> 基于医修帮、易售后、青鸟报修云、售后宝、天成 TECEV、Fixmms、OxMaint、Accruent TMS、TRIMEDX RSQ 等国内外 CMMS / 医疗设备维修平台的功能调研，梳理以下补充能力并标注版本计划。
### 12.1 巡检管理模块（V1.2 新增）
| 能力 | 说明 | 对标竞品 |
|------|------|---------|
| 巡检计划创建 | 按设备 / 区域 / 周期自由组合，支持日、周、月、季度巡检模板 | 青鸟报修云、天成 TECEV、Fixmms |
| 扫码执行巡检 | 工程师到达现场扫码开始巡检，逐项打勾 + 拍照存档，自动生成 PDF 报告 | OxMaint、Fixmms |
| 巡检异常转工单 | 检查项标记"异常"时一键生成报修工单，自动关联设备与巡检记录 | 易售后、天成 TECEV |
| 巡检路线规划 | 后台配置巡检路线顺序，GPS 签到校验到达 | OxMaint |
**新增数据表**：
| 表名 | 说明 | 核心字段 |
|------|------|---------|
| medfix_inspection_plan | 巡检计划 | id, planName, hospitalId, areaId, cycleType(daily/weekly/monthly/quarterly), checkItems(JSON), engineerId, startDate, endDate, status |
| medfix_inspection_record | 巡检执行记录 | id, planId, engineerId, executeTime, gpsLat, gpsLng, checkResults(JSON), abnormalCount, autoWorkOrderIds, reportUrl, status |
**巡检流程时序**：
```mermaid
sequenceDiagram
autonumber
actor Eng as 巡检工程师
participant MP as 小程序
participant API as API网关
participant InsSvc as 巡检服务
participant WoSvc as 工单服务
participant DB as MySQL
actor Admin as 设备科管理
Admin->>MP: 创建巡检计划（设备/区域/周期）
MP->>API: POST /admin/medfix/inspection/plan/create
API->>InsSvc: 校验参数+创建计划
InsSvc->>DB: 写入 medfix_inspection_plan
Note over Eng,DB: === 巡检执行 ===
Eng->>MP: 扫描设备二维码开始巡检
MP->>API: POST /app/medfix/inspection/start
API->>InsSvc: 校验 GPS + 加载检查项
InsSvc->>DB: 创建执行记录(status=executing)
Eng->>MP: 逐项检查+拍照+标注
MP->>API: PUT /app/medfix/inspection/record/update
API->>InsSvc: 更新检查结果
alt 存在异常项
Eng->>MP: 标记异常，一键转报修
MP->>API: POST /app/medfix/inspection/toWorkOrder
API->>WoSvc: 自动创建工单(关联巡检记录)
WoSvc->>DB: 写入 medfix_work_order
end
Eng->>MP: 完成巡检提交
MP->>API: POST /app/medfix/inspection/complete
API->>InsSvc: 生成巡检报告PDF
InsSvc->>DB: 更新记录(status=completed)
InsSvc-->>Admin: 推送巡检报告
```
### 12.2 知识库与远程诊断（V1.5 新增）
| 能力 | 说明 | 对标竞品 |
|------|------|---------|
| 维修知识库 | 按设备品牌/型号分类的故障排查手册，支持图文 + 视频 | 青鸟报修云、TRIMEDX RSQ |
| 常见故障 FAQ | 结构化 FAQ 数据 + 关键词搜索 + AI 语义匹配 | Accruent TMS |
| 远程视频诊断 | 工程师发起远程视频通话，专家实时指导（集成腾讯云 TRTC 或声网） | 医修帮、售后宝 |
| 维修案例分享 | 工程师上传经典案例，平台审核后发布，支持评分与收藏 | TRIMEDX RSQ |
**数据表**：
| 表名 | 说明 |
|------|------|
| medfix_knowledge_article | 知识库文章：id, title, deviceTypeId, brandId, modelId, content(富文本), tags, viewCount, status |
| medfix_knowledge_faq | FAQ 条目：id, question, answer, deviceTypeId, sortOrder, helpfulCount |
| medfix_repair_case | 维修案例：id, engineerId, workOrderId, title, faultDesc, solution, photos, score, status |
### 12.3 工程师轨迹追踪（增强）
| 能力 | 说明 | 对标竞品 |
|------|------|---------|
| 实时 GPS 轨迹 | 工程师端小程序在接单后持续上报 GPS 坐标（频率 30s），写入 Redis GEO + 冷存落盘 | 易售后 |
| 到达自动打卡 | 进入设备所在医院围栏（半径 500m）时自动触发到场打卡，无需手动操作 | 售后宝 |
| 工作时长统计 | 基于轨迹 + 打卡数据自动计算每日有效工作时长，支持加班标记 | OxMaint |
| 轨迹回放 | 管理后台可按日期回放工程师全天轨迹，结合工单节点标注 | 易售后 |
**数据表**：
| 表名 | 说明 |
|------|------|
| medfix_engineer_track | 轨迹点：id, engineerId, lat, lng, accuracy, timestamp, workOrderId(nullable), source(gps/wifi/cell) |
| medfix_engineer_checkin | 打卡记录：id, engineerId, workOrderId, hospitalId, lat, lng, checkinType(arrive/leave/auto), checkinTime |
### 12.4 满意度调查（V1.0 新增）
| 能力 | 说明 | 对标竞品 |
|------|------|---------|
| 自动推送评价 | 工单验收通过后 2 小时自动推送评价链接（微信模板消息） | 售后宝、青鸟报修云 |
| 五维评分 | 响应速度、技术能力、服务态度、维修效果、整体满意（各 1-5 星） | 易售后 |
| NPS 净推荐值 | 每季度统计 NPS（0-10 分制），纳入运营大屏 | Accruent TMS |
| 差评触发回访 | 任意维度 ≤ 2 星时自动创建"回访工单"，指派客服跟进 | 售后宝 |
**数据表**：
| 表名 | 说明 |
|------|------|
| medfix_satisfaction | 满意度评价：id, workOrderId, userId, responseScore, skillScore, attitudeScore, effectScore, overallScore, npsScore, comment, createTime |
| medfix_callback_order | 回访工单：id, sourceWorkOrderId, satisfactionId, callbackUserId, callbackResult, status, createTime |
**满意度流程**：
```mermaid
flowchart TD
A["工单验收通过 status=4"] --> B["延迟2小时推送评价"]
B --> C{"用户是否评价?"}
C -->|"是"| D["提交五维评分+NPS+评语"]
C -->|"否(48h超时)"| E["标记未评价，纳入统计"]
D --> F{"任意维度 ≤ 2星?"}
F -->|"是"| G["自动创建回访工单"]
F -->|"否"| H["评价数据入库"]
G --> I["客服跟进处理"]
I --> J["回访完成关闭"]
H --> K["NPS/满意度报表聚合"]
```
### 12.5 多渠道报修入口（增强）
| 渠道 | 说明 | 优先级 | 版本 | 对标竞品 |
|------|------|--------|------|---------|
| 微信小程序扫码 | 扫设备二维码直达报修页，主推渠道 | P0 | V1.0 | 医修帮、青鸟报修云 |
| 微信公众号 H5 | 关注公众号后通过菜单进入 H5 报修页 | P1 | V1.0 | 易售后 |
| 电话报修 | 运营/设备科接听电话后在管理后台手动录入 | P1 | V1.0 | 天成 TECEV |
| IoT 设备自动报警 | 传感器检测到异常参数后自动生成预警工单 | P2 | V2.0 | 天成 TECEV、OxMaint |
| 邮件报修 | 发送至指定邮箱，系统解析后自动创建工单 | P3 | V2.0 | Accruent TMS |
| API 对接 | 开放 API 对接医院 HIS/设备管理系统 | P3 | V2.0 | TRIMEDX RSQ |
**多渠道统一入口架构**：
```mermaid
flowchart LR
subgraph Channels["报修渠道"]
CH1["微信小程序扫码"]
CH2["公众号 H5"]
CH3["电话(人工录入)"]
CH4["IoT 设备告警"]
CH5["邮件解析"]
CH6["HIS API 对接"]
end
subgraph Normalize["统一适配层"]
NM["渠道适配器
参数标准化
去重校验"]
end
subgraph Core["工单核心"]
WO["工单创建服务"]
DP["智能派工引擎"]
end
CH1 --> NM
CH2 --> NM
CH3 --> NM
CH4 --> NM
CH5 --> NM
CH6 --> NM
NM --> WO
WO --> DP
```
### 12.6 IoT 设备预警（V2.0 新增）
| 能力 | 说明 | 对标竞品 |
|------|------|---------|
| MQTT 设备接入 | 通过 MQTT Broker（EMQX）接入医疗设备传感器 | 天成 TECEV、OxMaint |
| 实时数据采集 | 采集温度、振动频率、运行时长、错误日志等指标 | OxMaint |
| 阈值告警 | 超过预设阈值时自动产生告警事件，推送设备科 + 运营 | 天成 TECEV |
| 预测性维护 | 基于历史数据训练 AI 模型，预测故障概率，提前生成保养工单 | TRIMEDX RSQ、Accruent TMS |
| 设备健康度评分 | 综合传感器数据 + 维修记录 + 使用年限，输出 0-100 健康评分 | OxMaint |
**数据表**：
| 表名 | 说明 |
|------|------|
| medfix_iot_device | IoT 设备注册：id, deviceId(FK), mqttClientId, sensorTypes(JSON), thresholds(JSON), status |
| medfix_iot_data | 传感器数据流水：id, iotDeviceId, sensorType, value, unit, timestamp |
| medfix_iot_alert | 告警事件：id, iotDeviceId, alertType, sensorType, thresholdValue, actualValue, autoWorkOrderId, status |
| medfix_device_health | 设备健康度：id, deviceId, healthScore, factors(JSON), calculateTime |
**IoT 预警流转架构**：
```mermaid
flowchart TD
subgraph IoTLayer["IoT 接入层"]
DEV["医疗设备传感器"]
MQTT["EMQX MQTT Broker"]
end
subgraph ProcessLayer["数据处理层"]
INGEST["数据采集服务
解析+校验+写入"]
RULE["规则引擎
阈值判定"]
AI["AI 预测模型
故障概率分析"]
end
subgraph ActionLayer["动作层"]
ALERT["告警通知
推送设备科+运营"]
AUTO_WO["自动创建工单
预防性维护"]
HEALTH["健康度更新
评分重算"]
end
subgraph Store["存储层"]
TS_DB["时序数据
medfix_iot_data"]
BIZ_DB["业务数据
medfix_iot_alert"]
end
DEV -->|"MQTT publish"| MQTT
MQTT -->|"subscribe"| INGEST
INGEST --> TS_DB
INGEST --> RULE
RULE -->|"超阈值"| ALERT
RULE -->|"超阈值"| AUTO_WO
INGEST --> AI
AI -->|"故障概率>80%"| AUTO_WO
AI --> HEALTH
ALERT --> BIZ_DB
AUTO_WO --> BIZ_DB
```
---
## 13. 四类架构图（业务 / 应用 / 数据 / 技术）
### 13.1 业务架构图（Business Architecture）
```mermaid
graph TB
subgraph BizDomain["业务架构 - 业务域划分"]
subgraph D1["设备资产域"]
B1["设备档案管理"]
B2["设备分类与标签"]
B3["设备二维码管理"]
B4["设备生命周期"]
end
subgraph D2["报修服务域"]
B5["多渠道报修入口"]
B6["智能派工调度"]
B7["工单流转与状态机"]
B8["验收与评价"]
end
subgraph D3["维修执行域"]
B9["现场故障诊断"]
B10["维修记录与拍照"]
B11["工程师管理与KPI"]
B12["远程诊断支持"]
end
subgraph D4["备件供应域"]
B13["多仓库库存管理"]
B14["备件申领与出库"]
B15["供应商协同门户"]
B16["采购与入库"]
end
subgraph D5["运营管理域"]
B17["合同维保管理"]
B18["费用结算中心"]
B19["数据统计大屏"]
B20["巡检管理"]
end
subgraph D6["平台支撑域"]
B21["用户与权限"]
B22["消息通知中枢"]
B23["知识库"]
B24["应用配置"]
end
end
```
### 13.2 应用架构图（Application Architecture）
```mermaid
graph TB
subgraph Clients["接入层"]
C1["科室端小程序
报修/查询/验收"]
C2["工程师端小程序
接单/维修/备件"]
C3["厂家端小程序
备件/订单/结算"]
C4["管理后台 Web
全功能管理"]
C5["IoT 设备
传感器数据"]
end
subgraph Gateway["网关层"]
GW["Nginx 负载均衡
+ SSL 终止
+ 限流防护"]
end
subgraph AppLayer["应用服务层 - Midway.js"]
subgraph CoreSvc["核心服务"]
S1["工单服务"]
S2["派工服务"]
S3["设备服务"]
S4["工程师服务"]
end
subgraph BizSvc["业务服务"]
S5["备件服务"]
S6["供应商服务"]
S7["合同服务"]
S8["结算服务"]
end
subgraph SupportSvc["支撑服务"]
S9["用户认证服务"]
S10["消息推送服务"]
S11["文件上传服务"]
S12["统计分析服务"]
end
subgraph NewSvc["增强服务"]
S13["巡检服务"]
S14["知识库服务"]
S15["满意度服务"]
S16["IoT 数据服务"]
end
end
subgraph DataLayer["数据层"]
DB[("MySQL 主从
业务数据")]
REDIS[("Redis Sentinel
缓存/队列")]
OSS[("OSS 对象存储
图片/文档")]
MQ["Bull 任务队列
异步处理"]
end
C1 --> GW
C2 --> GW
C3 --> GW
C4 --> GW
C5 --> GW
GW --> CoreSvc
GW --> BizSvc
GW --> SupportSvc
GW --> NewSvc
CoreSvc --> DB
CoreSvc --> REDIS
BizSvc --> DB
SupportSvc --> DB
SupportSvc --> OSS
SupportSvc --> MQ
NewSvc --> DB
NewSvc --> REDIS
```
### 13.3 数据架构图（Data Architecture）
```mermaid
graph LR
subgraph SourceData["数据采集"]
SD1["小程序用户操作"]
SD2["管理端操作"]
SD3["IoT 传感器数据"]
SD4["微信开放平台"]
end
subgraph DataStore["数据存储"]
DS1[("MySQL 主库
事务写入")]
DS2[("MySQL 从库
读取分离")]
DS3[("Redis
热数据缓存")]
DS4[("OSS
非结构化文件")]
end
subgraph DataProcess["数据处理"]
DP1["实时统计聚合
工单/SLA/备件"]
DP2["定时任务汇总
月度结算/报表"]
DP3["异步消息处理
通知/推送/事件"]
DP4["AI 模型计算
设备健康度/派工优化"]
end
subgraph DataConsume["数据消费"]
DC1["API 查询响应"]
DC2["统计大屏展示"]
DC3["导出报表 Excel/PDF"]
DC4["消息推送"]
DC5["设备健康度仪表盘"]
end
SD1 --> DS1
SD2 --> DS1
SD3 --> DS3
SD3 --> DS1
SD4 --> DS1
DS1 --> DS2
DS1 --> DS3
DS1 --> DP1
DS2 --> DP2
DS3 --> DP1
DS4 --> DP3
DP1 --> DC1
DP1 --> DC2
DP2 --> DC3
DP2 --> DC2
DP3 --> DC4
DP4 --> DC5
```
**核心数据域与表映射**：
| 数据域 | 核心表 | 数据量级预估(年) | 存储策略 |
|--------|--------|----------------|---------|
| 工单域 | medfix_work_order, medfix_repair_record | 5 万~20 万行 | 热数据 MySQL + 冷数据归档 |
| 设备域 | medfix_device, medfix_device_health | 1 万~5 万行 | 全量 MySQL |
| 备件域 | medfix_parts, medfix_parts_stock_log | 10 万~50 万行 | MySQL + 按月分区 |
| 轨迹域 | medfix_engineer_track | 500 万~2000 万行 | MySQL 按日分区 + 90 天冷归档 |
| IoT 域 | medfix_iot_data | 亿级 | 时序数据库(TDengine/InfluxDB) + 30 天热存 |
| 结算域 | medfix_settlement, medfix_settlement_detail | 5 千~2 万行 | 全量 MySQL |
### 13.4 技术架构图（Technology Architecture）
```mermaid
graph TB
subgraph TechStack["技术架构全景"]
subgraph FrontEnd["前端技术"]
T1["uni-app x
微信/H5 小程序"]
T2["Vue 3 + Element Plus
管理后台"]
T3["ECharts 5
数据可视化"]
T4["Leaflet / 腾讯地图
轨迹与地图派工"]
end
subgraph BackEnd["后端技术"]
T5["Midway.js 3
TypeScript IOC"]
T6["TypeORM
数据访问层"]
T7["Bull + Redis
任务队列"]
T8["Socket.io
实时通信"]
T9["EMQX
MQTT IoT 接入"]
end
subgraph Infra["基础设施"]
T10["Nginx 1.24
反向代理/负载均衡"]
T11["MySQL 8.0
主从复制/分区表"]
T12["Redis 7
Sentinel 高可用"]
T13["阿里云 OSS
对象存储 CDN"]
end
subgraph DevOps["运维与安全"]
T14["PM2 / Docker
进程/容器管理"]
T15["Let's Encrypt
SSL 证书自动续期"]
T16["Sentry
错误追踪"]
T17["Loki + Grafana
日志与监控"]
end
subgraph ThirdParty["三方服务"]
T18["微信开放平台
登录/模板消息/支付"]
T19["腾讯云 TRTC
远程视频诊断"]
T20["阿里云短信
SMS 通知"]
T21["企业微信 Webhook
运维告警"]
end
end
```
---
## 14. 4+1 视图
### 14.1 场景视图（用例视图 / +1 View）
```mermaid
graph TB
subgraph Actors["参与者"]
A1["科室报修员"]
A2["维修工程师"]
A3["院方设备科"]
A4["运营管理员"]
A5["备件供应商"]
A6["仓库管理员"]
end
subgraph Scenarios["核心用例"]
UC1["UC-01 扫码报修"]
UC2["UC-02 智能派工"]
UC3["UC-03 维修执行"]
UC4["UC-04 备件申领"]
UC5["UC-05 验收评价"]
UC6["UC-06 月度结算"]
UC7["UC-07 巡检管理"]
UC8["UC-08 统计分析"]
UC9["UC-09 满意度调查"]
UC10["UC-10 远程诊断"]
UC11["UC-11 合同管理"]
end
A1 --> UC1
A1 --> UC5
A1 --> UC9
A2 --> UC3
A2 --> UC4
A2 --> UC7
A2 --> UC10
A3 --> UC5
A3 --> UC6
A3 --> UC11
A4 --> UC2
A4 --> UC6
A4 --> UC8
A4 --> UC11
A5 --> UC4
A6 --> UC4
A6 --> UC7
```
**核心场景路径（阶段二）**：
| # | 场景 | 主要参与者 | 关键步骤数 | 版本 |
|---|------|-----------|-----------|------|
| 1 | 报修 → 派工 → 维修 → 验收闭环 | 科室、工程师、设备科 | 12 | V1.0 |
| 2 | 备件申领 → 审批出库 → 安装 → 旧件退回 | 工程师、仓库 | 8 | V1.0 |
| 3 | 月度结算 → 院方确认 → 开票付款 | 运营、设备科 | 6 | V1.0 |
| 4 | 巡检计划 → 扫码执行 → 异常转工单 | 工程师、设备科 | 7 | V1.2 |
| 5 | IoT 告警 → 自动工单 → 预防性维护 | 系统、工程师 | 5 | V2.0 |
### 14.2 逻辑视图（Logical View）
> 与 3.5.3 逻辑视图互补，此处聚焦增强模块的组件关系。
```mermaid
flowchart LR
subgraph EnhancedModules["增强功能组件"]
insSvc["巡检服务"]
kbSvc["知识库服务"]
satSvc["满意度服务"]
iotSvc["IoT 数据服务"]
trackSvc["轨迹追踪服务"]
remoteSvc["远程诊断服务"]
end
subgraph CoreModules["核心组件(已有)"]
woSvc["工单服务"]
devSvc["设备服务"]
engSvc["工程师服务"]
notifySvc["消息通知"]
end
subgraph SharedInfra["共享基础设施"]
db[("MySQL")]
redis[("Redis")]
oss[("OSS")]
mqtt["EMQX MQTT"]
end
insSvc -->|"异常转工单"| woSvc
insSvc -->|"设备信息"| devSvc
kbSvc -->|"故障匹配"| devSvc
satSvc -->|"工单完成触发"| woSvc
satSvc -->|"差评回访"| woSvc
iotSvc -->|"自动报警工单"| woSvc
iotSvc -->|"健康度更新"| devSvc
trackSvc -->|"位置数据"| engSvc
remoteSvc -->|"诊断记录"| woSvc
insSvc --> db
kbSvc --> db
kbSvc --> oss
satSvc --> db
iotSvc --> mqtt
iotSvc --> redis
iotSvc --> db
trackSvc --> redis
remoteSvc --> oss
satSvc --> notifySvc
iotSvc --> notifySvc
```
### 14.3 处理视图（Process View）
**关键并发处理流程**：
#### 14.3.1 工单处理管道
```mermaid
flowchart LR
subgraph Pipeline["工单处理管道"]
P1["接收报修请求"] --> P2["幂等校验
Redis SETNX"]
P2 --> P3["写入工单
MySQL 事务"]
P3 --> P4["发布事件
Outbox 模式"]
P4 --> P5["异步派工
Bull Queue"]
P5 --> P6["候选评分
技能+距离+负载"]
P6 --> P7["分配工程师
更新工单"]
P7 --> P8["推送通知
微信模板消息"]
end
```
#### 14.3.2 实时通知扇出
```mermaid
flowchart TD
EVT["业务事件触发"] --> ROUTER["通知路由器"]
ROUTER --> CH_WX["微信模板消息
科室/工程师"]
ROUTER --> CH_SMS["短信通知
紧急/SLA超时"]
ROUTER --> CH_WEB["站内消息
管理后台"]
ROUTER --> CH_BOT["企业微信 Bot
运维告警"]
CH_WX --> RETRY_Q["失败重试队列
最多3次"]
CH_SMS --> RETRY_Q
```
#### 14.3.3 月度结算批处理
```mermaid
flowchart TD
CRON["每月1日 00:00
定时触发"] --> SCAN["扫描上月已完成工单"]
SCAN --> GROUP["按医院维度分组"]
GROUP --> CALC["计算工时费 + 备件费"]
CALC --> GEN["生成结算单
medfix_settlement"]
GEN --> NOTIFY["推送院方确认"]
NOTIFY --> WAIT["等待确认
超期自动催办"]
WAIT --> INVOICE["确认后生成开票申请"]
```
#### 14.3.4 IoT 数据摄入管道
```mermaid
flowchart LR
SENSOR["设备传感器"] -->|"MQTT QoS 1"| BROKER["EMQX Broker"]
BROKER --> CONSUMER["数据消费服务"]
CONSUMER --> PARSE["协议解析
JSON/Modbus"]
PARSE --> STORE["写入时序存储"]
PARSE --> CHECK["阈值检测"]
CHECK -->|"超限"| ALERT["产生告警"]
ALERT --> WO_CREATE["自动创建工单"]
PARSE --> ML["定期批量
AI 模型推理"]
ML --> HEALTH["更新健康评分"]
```
### 14.4 物理视图（Deployment View / L2 增强拓扑）
```mermaid
graph TB
subgraph Internet["互联网"]
USER["用户终端
微信/浏览器"]
IOT_GW["IoT 网关
医院侧"]
end
subgraph ALB["阿里云 SLB"]
LB["负载均衡
HTTPS 443"]
end
subgraph AppCluster["应用集群"]
subgraph Node1["ECS 节点 1"]
N1_NGINX["Nginx"]
N1_APP["Midway.js 实例 A
PM2 管理"]
end
subgraph Node2["ECS 节点 2"]
N2_NGINX["Nginx"]
N2_APP["Midway.js 实例 B
PM2 管理"]
end
end
subgraph DataCluster["数据集群"]
subgraph MySQLCluster["MySQL 主从"]
DB_M[("MySQL Master
写入")]
DB_S[("MySQL Slave
读取")]
end
subgraph RedisCluster["Redis 哨兵"]
R_M[("Redis Master")]
R_S1[("Redis Slave 1")]
R_S2[("Redis Slave 2")]
end
end
subgraph MQTTCluster["MQTT 集群"]
EMQX1["EMQX Node 1"]
EMQX2["EMQX Node 2"]
end
subgraph Storage["存储服务"]
ALI_OSS["阿里云 OSS
+ CDN"]
end
subgraph Monitor["监控体系"]
SENTRY["Sentry
错误追踪"]
GRAFANA["Grafana + Loki
日志监控"]
end
USER --> LB
IOT_GW --> EMQX1
IOT_GW --> EMQX2
LB --> N1_NGINX
LB --> N2_NGINX
N1_NGINX --> N1_APP
N2_NGINX --> N2_APP
N1_APP --> DB_M
N1_APP --> DB_S
N2_APP --> DB_M
N2_APP --> DB_S
N1_APP --> R_M
N2_APP --> R_M
R_M --> R_S1
R_M --> R_S2
DB_M --> DB_S
N1_APP --> ALI_OSS
N2_APP --> ALI_OSS
N1_APP --> SENTRY
N2_APP --> SENTRY
EMQX1 --> N1_APP
EMQX2 --> N2_APP
```
### 14.5 开发视图（Development View）
**Cool Admin 模块依赖关系**：
```mermaid
graph TD
subgraph FrameworkLayer["框架层 (Cool Admin)"]
FW_BASE["@cool-midway/core
基础框架"]
FW_CRUD["@cool-midway/crud
通用 CRUD"]
FW_FILE["@cool-midway/file
文件上传"]
FW_TASK["@cool-midway/task
任务调度"]
end
subgraph BizModules["业务模块层 (src/modules/)"]
MOD_WO["medfix/workOrder
工单模块"]
MOD_DEV["medfix/device
设备模块"]
MOD_ENG["medfix/engineer
工程师模块"]
MOD_PARTS["medfix/parts
备件模块"]
MOD_SETTLE["medfix/settlement
结算模块"]
MOD_STATS["medfix/stats
统计模块"]
MOD_INS["medfix/inspection
巡检模块"]
MOD_KB["medfix/knowledge
知识库模块"]
MOD_SAT["medfix/satisfaction
满意度模块"]
MOD_IOT["medfix/iot
IoT 模块"]
end
subgraph SharedModules["共享模块"]
SH_USER["base/user
用户认证"]
SH_NOTIFY["base/notify
消息通知"]
SH_DICT["base/dict
字典管理"]
end
FW_BASE --> MOD_WO
FW_BASE --> MOD_DEV
FW_CRUD --> MOD_WO
FW_CRUD --> MOD_DEV
FW_CRUD --> MOD_PARTS
FW_CRUD --> MOD_SETTLE
FW_FILE --> MOD_WO
FW_FILE --> MOD_KB
FW_TASK --> MOD_SETTLE
FW_TASK --> MOD_STATS
FW_TASK --> MOD_IOT
MOD_WO --> MOD_DEV
MOD_WO --> MOD_ENG
MOD_WO --> MOD_PARTS
MOD_WO --> SH_NOTIFY
MOD_SETTLE --> MOD_WO
MOD_SETTLE --> MOD_PARTS
MOD_STATS --> MOD_WO
MOD_STATS --> MOD_PARTS
MOD_STATS --> MOD_SAT
MOD_INS --> MOD_DEV
MOD_INS --> MOD_WO
MOD_KB --> MOD_DEV
MOD_SAT --> MOD_WO
MOD_SAT --> SH_NOTIFY
MOD_IOT --> MOD_DEV
MOD_IOT --> MOD_WO
MOD_IOT --> SH_NOTIFY
MOD_ENG --> SH_USER
```
---
## 15. 竞品功能对比矩阵
> 数据来源：各平台官网功能介绍、应用商店描述、行业分析报告（2024-2026）。
| 功能 | 共享医修通 | 医修帮 | 易售后 | 青鸟报修云 | 天成 TECEV | Fixmms | OxMaint | Accruent TMS | TRIMEDX RSQ |
|------|-----------|--------|--------|-----------|-----------|--------|---------|-------------|-------------|
| 微信小程序报修 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| 扫码报修 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 智能派工 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ |
| 地图派工 | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
| 备件供应链 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 供应商门户 | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
| 多医院共享 | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
| 合同维保 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 巡检管理 | ✅(V1.2) | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 知识库 | ✅(V1.5) | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ |
| 远程视频诊断 | ✅(V1.5) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| IoT 预警 | ✅(V2.0) | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ✅ | ✅ |
| 预测性维护 | ✅(V2.0) | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
| 满意度调查 | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ |
| 工程师轨迹 | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
| 数据大屏 | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ |
| SLA 管理 | ✅ | ❌ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ |
| NPS 统计 | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
| 设备健康度评分 | ✅(V2.0) | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
| SaaS 多租户 | ✅(V3.0) | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ❌ |
| 开放 API | ✅(V2.0) | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
**差异化优势总结**：
| 维度 | 共享医修通差异化 | 说明 |
|------|-----------------|------|
| 多院共享模式 | 省级平台覆盖多家医院共享工程师资源 | 国内竞品多为单院部署，无共享调度能力 |
| 微信生态深度集成 | 小程序 + 公众号 + 模板消息 + 微信支付全链路 | 国际竞品无微信生态 |
| 供应商协同门户 | 厂家独立入口管理备件、订单、结算 | 多数竞品仅支持内部备件管理 |
| 全链路可观测 | 工单 + 轨迹 + SLA + NPS + 健康度多维度闭环 | 竞品通常仅覆盖 1-2 个维度 |
---
## 16. 版本演进路线
```mermaid
gantt
title 共享医修通版本演进计划
dateFormat YYYY-MM
axisFormat %Y-%m
section V1.0 核心闭环
设备档案管理 :v1a, 2026-04, 2026-05
报修工单与派工 :v1b, 2026-05, 2026-06
维修执行与验收 :v1c, 2026-06, 2026-07
备件供应链 :v1d, 2026-06, 2026-07
结算与统计 :v1e, 2026-07, 2026-08
满意度调查 :v1f, 2026-07, 2026-08
section V1.2 巡检增强
巡检计划与执行 :v12a, 2026-08, 2026-09
轨迹追踪增强 :v12b, 2026-08, 2026-09
供应商协同门户 :v12c, 2026-09, 2026-10
section V1.5 知识与诊断
知识库体系 :v15a, 2026-10, 2026-11
远程视频诊断 :v15b, 2026-11, 2026-12
AI 故障搜索 :v15c, 2026-11, 2026-12
section V2.0 IoT 与智能
IoT 设备接入 :v20a, 2027-01, 2027-02
预测性维护 :v20b, 2027-02, 2027-03
设备健康度评分 :v20c, 2027-02, 2027-03
开放 API :v20d, 2027-03, 2027-04
section V3.0 SaaS 化
多租户架构改造 :v30a, 2027-05, 2027-07
租户计费体系 :v30b, 2027-06, 2027-08
```
---
**文档版本**：v2.0
**创建日期**：2026-04-16
**最后更新**：2026-04-16