共享医修通 - 交互流程地图

医疗设备共享维修平台 · 报修派工 · 备件供应 · 结算对账 · 设备全生命周期管理

目录导航

🔧 1. 报修工单主流程(核心流程)
sequenceDiagram autonumber participant KS as 科室用户 participant XCX as 小程序 participant API as API服务 participant DB as 数据库 participant PG as 派工引擎 participant WX as 微信推送 participant ENG as 工程师 participant WH as 仓库管理 participant JS as 结算模块 KS->>XCX: 扫码/拍照报修 XCX->>API: 创建工单(设备ID, 故障描述, 紧急度, 图片) API->>DB: 生成工单(MF+日期+序号) API->>PG: 触发智能匹配 PG->>API: 返回最优工程师(技能匹配+距离+负载) API->>WX: 通知工程师 WX-->>ENG: 派工消息推送 ENG->>XCX: 接单确认 XCX->>API: 更新状态(已派工 → 维修中) ENG->>XCX: 到达现场(GPS打卡) XCX->>API: 记录到达时间+坐标 ENG->>XCX: 故障诊断+拍照记录 XCX->>API: 提交诊断信息 alt 需要备件 ENG->>XCX: 申领备件 XCX->>API: 创建备件申领单 WH->>API: 审批出库 API->>DB: 扣减库存 end ENG->>XCX: 维修完成+提交记录 XCX->>API: 更新状态(维修中 → 待验收) API->>WX: 通知科室验收 WX-->>KS: 验收消息推送 KS->>XCX: 验收签字+评价 XCX->>API: 提交验收结果 API->>DB: 关闭工单 API->>JS: 生成费用明细

流程说明

科室用户通过小程序扫描设备二维码或拍照发起报修,系统自动生成工单编号(MF+日期+序号)并调用派工引擎进行智能匹配。派工引擎综合工程师的技能标签、地理距离和当前工单负载计算最优人选,通过微信服务号推送派工通知。工程师接单后到达现场进行 GPS 打卡签到和故障诊断,如需备件则发起申领流程由仓库管理审批出库。维修完成后系统推送验收通知给科室用户,科室负责人在小程序上完成验收签字和评价,工单关闭后自动生成费用明细进入结算模块。

🔄 2. 工单状态流转图
stateDiagram-v2 [*] --> PendingDispatch : 科室提交报修 PendingDispatch --> Dispatched : 智能/手动派工 PendingDispatch --> Cancelled : 科室取消 Dispatched --> PendingDispatch : 工程师退单 Dispatched --> Repairing : 工程师接单并到达 Repairing --> PendingVerify : 工程师完成维修 PendingVerify --> Repairing : 验收不通过 PendingVerify --> Completed : 验收通过+签字 Completed --> Closed : 结算完成 PendingDispatch --> Closed : 超时自动关闭(30天) state PendingDispatch { [*] --> WaitMatch : 等待匹配 WaitMatch --> Matched : 匹配成功 } state Repairing { [*] --> Diagnosing : 故障诊断 Diagnosing --> PartsApply : 申领备件 Diagnosing --> Fixing : 直接维修 PartsApply --> Fixing : 备件到位 }

状态说明

工单从科室提交开始进入「待派工」状态,经智能或手动派工后流转至「已派工」。工程师接单并到达现场后进入「维修中」子状态(包含故障诊断、备件申领、维修操作)。维修完成进入「待验收」,科室验收通过则标记「已完成」,不通过退回「维修中」。已完成工单经费用结算后变为「已关闭」。异常路径包括:工程师退单(回到待派工重新分配)、科室取消、超时 30 天自动关闭。

📦 3. 备件供应链流程
flowchart TD subgraph apply_phase ["申领与出库"] A1([工程师发起申领]) --> A2[关联工单] A2 --> A3[选择备件+数量] A3 --> A4[提交审批] A4 --> A5{仓库管理审批} A5 -->|驳回| A6[退回修改] A6 --> A3 A5 -->|通过| A7[出库扫码确认] A7 --> A8[库存自动扣减] end subgraph alert_phase ["库存预警与采购"] B1{低库存预警检查} -->|库存充足| B_END([流程结束]) B1 -->|低于安全线| B2[自动生成采购需求] B2 --> B3[厂家报价] B3 --> B4{采购确认} B4 -->|不通过| B3 B4 -->|通过| B5[厂家发货] B5 --> B6[入库登记] end subgraph return_phase ["旧件退回"] C1([维修完成]) --> C2[旧件退回登记] C2 --> C3{旧件可用?} C3 -->|可翻新| C4[翻新入库] C3 -->|报废| C5[报废处理] end A8 --> B1 A8 --> C1

流程说明

备件供应链由三大子流程串联:申领出库——工程师在维修现场关联工单发起备件申领,仓库管理员审批通过后扫码出库,库存实时扣减;库存预警与采购——出库后自动检查库存水位,低于安全阈值时生成采购需求,向厂家询价确认后下单采购,到货入库;旧件退回——维修完成后旧件登记退回,可翻新的回流库存池,报废的走处置流程。三条链路协同确保备件供应的及时性和成本可控。

🤖 4. 智能派工算法流程
flowchart TD D1([工单创建]) --> D2[读取设备类型/故障类型] D2 --> D3[筛选技能匹配工程师] D3 --> D4{匹配工程师数 > 0?} D4 -->|否| D5[通知管理员手动派工] D4 -->|是| D6[筛选服务区域覆盖] D6 --> D7{区域内工程师 > 0?} D7 -->|否| D8[扩大搜索半径] D8 --> D6 D7 -->|是| D9[计算距离分 - GEO] D9 --> D10[计算负载分 - 当前工单数] D10 --> D11[计算历史评分] D11 --> D12[综合加权排名] D12 --> D13{工单紧急度?} D13 -->|紧急| D14[自动派工 - 排名第1] D13 -->|普通| D15[生成推荐列表 - Top 3] D14 --> D16[发送派工通知] D15 --> D17[管理员选择确认] D17 --> D16 style D1 fill:#e8f5e9,stroke:#43a047 style D14 fill:#ffebee,stroke:#e53935 style D15 fill:#e3f2fd,stroke:#1e88e5

算法说明

智能派工引擎采用多维度加权评分机制:首先根据工单的设备类型和故障类型筛选具备对应技能标签的工程师,再按服务区域进行地理过滤(无匹配时逐步扩大搜索半径)。通过的候选人从三个维度打分——距离分(基于 GPS 坐标计算直线距离)、负载分(当前在手工单数量,越少越优)、历史评分(科室用户的历史满意度评价)。综合加权排名后,紧急工单自动派给排名第一的工程师,普通工单则生成 Top 3 推荐列表供管理员确认选择。

💰 5. 结算对账流程
sequenceDiagram autonumber participant CRON as 月初定时任务 participant SYS as 结算系统 participant DB as 数据库 participant WX as 微信推送 participant HOSP as 院方财务 participant SUPP as 供应商/厂家 participant FIN as 平台财务 CRON->>SYS: 触发月度结算 SYS->>DB: 聚合上月已完成工单费用 DB-->>SYS: 返回费用明细(工时/备件/交通) SYS->>SYS: 按医院/供应商分组 SYS->>DB: 生成结算单 SYS->>WX: 推送确认通知 WX-->>HOSP: 结算单待确认 WX-->>SUPP: 结算单待确认 HOSP->>SYS: 确认/提出异议 alt 院方有异议 SYS->>DB: 标记争议项 SYS->>WX: 通知协商 HOSP->>SYS: 重新确认 end SUPP->>SYS: 确认/提出异议 alt 厂家有异议 SYS->>DB: 标记争议项 SYS->>WX: 通知协商 SUPP->>SYS: 重新确认 end SUPP->>SYS: 开具发票 SYS->>DB: 上传发票附件 FIN->>SYS: 确认付款 SYS->>DB: 结算单状态 → 已完成 SYS->>WX: 通知各方结算完成

流程说明

系统在每月初通过定时任务自动汇总上月已完成工单,将费用明细(工时费、备件费、交通费)按医院维度和供应商维度分组,生成对应的结算单并推送确认通知。院方财务和供应商分别审核确认,如有异议可标记争议项进入协商调整流程。双方确认无误后,供应商开具发票并上传附件,平台财务完成付款确认,结算单归档。全流程数据可追溯,支持审计查询。

🏥 6. 设备全生命周期
flowchart LR L1([采购登记]) --> L2[验收入库] L2 --> L3[科室分配] L3 --> L4[正常使用] L4 --> L5[日常巡检] L5 --> L6{巡检结果} L6 -->|正常| L4 L6 -->|异常| L7[报修维护] L7 --> L4 L4 --> L8{到保养周期?} L8 -->|是| L9[预防性保养] L9 --> L4 L8 -->|否| L10{重大故障?} L10 -->|是| L11[大修] L11 --> L12{修复成功?} L12 -->|是| L4 L12 -->|否| L13[评估报废] L10 -->|否| L4 L4 --> L14{达到使用年限?} L14 -->|否| L4 L14 -->|是| L13 L13 --> L15[资产核销] L15 --> L16([设备退役]) style L1 fill:#e8f5e9,stroke:#43a047 style L16 fill:#ffebee,stroke:#e53935 style L4 fill:#e3f2fd,stroke:#1e88e5

生命周期说明

设备从采购登记进入平台建立电子档案,经验收入库后分配至具体科室。在正常使用阶段形成三条循环路径:日常巡检发现异常时自动生成报修工单;预防性保养按设备维保计划周期触发保养任务;大修处理重大故障,修复失败则评估报废。当设备达到使用年限或维修成本超过阈值时,进入报废评估和资产核销流程。全生命周期数据沉淀为设备健康画像,支撑采购决策和维保策略优化。

📋 7. 巡检管理流程
flowchart TD I1([创建巡检计划]) --> I2[配置设备/区域/周期] I2 --> I3[系统自动生成巡检任务] I3 --> I4[推送工程师] I4 --> I5[到达现场GPS签到] I5 --> I6[扫码执行巡检] I6 --> I7[填写巡检表单] I7 --> I8[拍照记录] I8 --> I9{发现异常?} I9 -->|是| I10[自动生成报修工单] I10 --> I11[进入报修主流程] I9 -->|否| I12[提交巡检报告] I12 --> I13{本轮全部完成?} I13 -->|否| I5 I13 -->|是| I14([巡检完成 - 生成统计报表]) subgraph cycle_engine ["周期调度引擎"] CE1[每日定时扫描] --> CE2{今日有到期计划?} CE2 -->|是| CE3[批量生成任务] CE3 --> I4 CE2 -->|否| CE4[等待下次扫描] end style I10 fill:#ffebee,stroke:#e53935 style I14 fill:#e8f5e9,stroke:#43a047

流程说明

巡检管理流程由周期调度引擎驱动:管理员创建巡检计划时配置目标设备/区域和巡检周期(日检、周检、月检等),系统每日定时扫描到期计划并批量生成巡检任务,推送给指定工程师。工程师到达现场后 GPS 签到,扫描设备二维码开始执行巡检,按照预设表单逐项检查并拍照记录。如发现异常,系统自动关联生成报修工单并进入主维修流程;无异常则提交巡检报告。单轮巡检完成后自动生成统计报表(完成率、异常率、平均耗时等)。

👥 8. 用户角色交互矩阵
功能模块 科室用户 工程师 仓库管理员 院方管理员 供应商/厂家 平台管理员
扫码报修 读写 只读 只读
工单管理 只读 读写 读写 只读 读写
智能派工 只读 读写 读写
维修执行 读写 只读 只读
验收签字 读写 只读 只读 只读
备件申领 读写 读写 只读 只读
库存管理 只读 读写 只读 只读 读写
采购管理 读写 读写 读写 读写
结算对账 读写 读写 读写
设备档案 只读 只读 只读 读写 只读 读写
巡检管理 读写 读写 读写
数据报表 只读 只读 读写 只读 读写
评价反馈 读写 只读 只读 只读
系统配置 读写

矩阵说明

科室用户:报修发起方,负责扫码报修、验收签字和评价反馈。工程师:维修执行方,负责接单、现场维修、备件申领和巡检任务。仓库管理员:负责备件出入库管理和采购流程。院方管理员:拥有全局管理视角,可进行派工调配、结算审批和设备资产管理。供应商/厂家:参与采购报价、备件供货和结算对账。平台管理员:拥有最高权限,负责系统配置、数据报表和全业务线监控。

📡 9. 多渠道报修与 SLA 闭环(行业基座扩展)
flowchart TD subgraph channels [报修入口] A1[微信小程序报修] A2[设备二维码直达] A3[管理代报可选] end subgraph intake [接入与归一] B1[身份校验与科室归属] B2[工单模板与紧急度分级] end subgraph sla [SLA与告警] C1[响应时限计时器] C2[派工超时告警] C3[到场超时告警] C4[验收超时提醒] end subgraph close [闭环] D1[状态机推进] D2[订阅消息与短信] D3[运营看板与审计日志] end A1 --> B1 A2 --> B1 A3 --> B1 B1 --> B2 B2 --> C1 C1 --> D1 D1 --> C2 D1 --> C3 D1 --> C4 C2 --> D2 C3 --> D2 C4 --> D2 D1 --> D3

流程说明

对标互联网售后与医院后勤类产品的多渠道归一能力:无论科室从微信首页、设备张贴码或院方代报进入,统一经身份与科室归属校验后落入同一工单池与状态机。SLA 闭环在关键节点(派工、到场、验收)挂载计时与告警,通过订阅消息、短信与运营看板形成可审计的处置链路;详细规则与阈值见 需求评估文档.md §1.6.1 与 business_logic.md 工单状态章节。

🧾 10. 多身份入驻申请与审核
flowchart TD A[选择申请身份] --> B[提交申请资料] B --> C{平台初审} C -->|资料不完整| D[驳回补件] C -->|通过| E{业务复审} D --> B E -->|不通过| F[拒绝并归档] E -->|通过| G[账号开通与角色绑定] G --> H[小程序身份激活]

流程说明

平台统一支持工程师、供应商、服务商、医院管理员、科室报修员五类身份入驻。申请人在小程序选择身份后提交对应资质,平台完成初审与复审流转:资料缺失进入补件闭环,审核通过后自动开通账号并绑定角色(roleCode + roleType),最终进入对应小程序工作台。

📣 11. 推广线索与转化归因
flowchart LR A[活动投放] --> B[访问落地页] B --> C[提交线索] C --> D[提交入驻申请] D --> E[审核通过] E --> F[账号激活] F --> G[归因报表]

流程说明

推广链路将活动、线索、入驻申请与最终激活贯通,支持按渠道、身份、活动做转化归因。系统统一记录访问、线索提交、申请提交、审核通过、账号激活事件,输出 CAC/CPL 与转化漏斗,服务运营决策与销售复盘。

📝 流程总结

共享医修通平台围绕十一大流程视图构建业务闭环:在报修工单主流程、工单状态流转、备件供应链、智能派工、结算对账、设备全生命周期、巡检管理、角色交互矩阵、多渠道报修与 SLA 闭环基础上,新增多身份入驻申请与审核推广线索转化归因流程,形成从获客、准入到履约的全链路治理能力。

← 返回文档总览