简介这份PDF资料系统介绍卫宁健康新一代医疗数字化转型平台WiNEX面向医院信息科人员、医疗IT产品经理及关注智慧医疗的开发者聚焦解决医疗机构在流程再造、信息共享、系统集成与数据标准化等方面的共性痛点。资源为单文件PDF共4.32MB内容覆盖临床业务重塑、数据标准模型、开放服务层和数字化场景创新等核心模块并结合SNOMED-CT、HL7 FHIR等国际标准与“1X”中台架构进行说明便于快速建立对WiNEX整体方案的认知。目前已有858人学习下载。通过阅读可掌握WiNEX在医生工作站、电子病历、医嘱闭环、数据资产治理及互联网医疗场景中的设计逻辑适合作为产品选型、需求调研或院内系统数字化转型的参考材料。1. WiNEX 是平台不是又一个 HIS第一次接触 WiNEX 的人十有八九会把它当成一套“升级版 HIS”来看。实际上去年医共体项目里我陪医院信息科做选型评估前二十分钟听到的全是“临床工作站”“住院医嘱”“电子病历”等看到交付清单里还有集成引擎、CDR 数据中心、低代码配置台和消息路由才知道 WiNEX 走的是平台路线而不是单机版业务软件换皮。卫宁健康把 WiNEX 定位成新一代医疗健康数字化底座本质上是要把原来耦合在旧 HIS 里的业务能力拆开、重组、标准化让门诊、住院、急诊、药事、检验、数据上报都能在一个底座上长出来。它适合两类人深度关注一类是医院信息科和临床信息化负责人关心的是能不能从旧系统平滑迁移另一类是医疗软件公司、集成商和独立实施工程师关心的是集成怎么对接、数据怎么治理、上线后出了故障怎么排查。WiNEX 能解决的问题也很具体老系统接口散、数据口径乱、厂商绑定深、新需求排期慢。不是说换一套 HIS 就自动解决而是它给了你一套可配置、可组装、可观测的框架能不能发挥出来取决于实施方怎么拆业务、怎么定编码、怎么做数据迁移。2. 用云原生底座拆掉单体 HISWiNEX 的分层与部署形态2.1 单体 HIS 为什么越来越难改医院信息科最怕的不是系统宕机而是“改一个字段要连带通知五个厂商”。传统 HIS 是典型单体应用医嘱、收费、病历、药房、检验申请全在一个库里业务表动一张影响面就是全院。WinEX 的思路是把这些能力拆成独立的业务域每个域有自己的服务、自己的库、自己的发布节奏。这样做的好处很直接门诊发布新版本不需要把住院一起停掉药房要改发药逻辑也不用等病历模块一起排期。但代价也很明显微服务化之后原来一次事务能解决的问题现在要跨服务协调接口数量从几十个涨到几百个。交付实施方如果心里没有“领域划分”这张图项目就会被服务间的依赖关系拖死。这也是我在跟医院交流时反复强调的一点WiNEX 能不能跑得顺不取决于服务数量多不多而取决于业务域拆得是否干净、数据归属是否明确。2.2 WiNEX 的几层核心能力从我接触到的交付形态来看WiNEX 通常可以按四层来理解。最底层是技术底座主要是容器化运行环境、注册中心、配置中心、日志链路和网关往上一层是数据平台负责把分散在各个业务域的数据沉淀到 CDR也就是临床数据中心再往上是集成平台统一接待外部系统的请求把消息转换成标准格式再路由到目标服务最上层才是医护真正看到的应用比如门诊医生站、住院护士站、急诊预检分诊。理解这四层对实施特别重要。举个例子老 HIS 里“检验申请”只是某张表里的一行记录外部 LIS 来取数时直接连数据库读。WiNEX 里你要走的是“应用层发起申请、集成平台发消息、检验系统回写结果、数据平台归集指标”这条链路。表面上绕了一圈但换来的是每个环节都可监控、可重放、可追溯。上线后查问题第一件事不是跑到数据库去捞数而是先看集成平台里的消息流转日志。2.3 部署环境怎么选从 K8s 到客户机房的妥协WiNEX 这类平台型产品对运行环境是有要求的最简单的情况是医院采购超融合或私有云资源用 K8s 编排。也有一些客户机房只有几台物理服务器交付方会退而求其次用 Docker Compose 方式把服务拉起来。不管哪种方式我建议实施方提前确认三个底线CPU 和内存够不够跑业务服务及中间件、存储有没有做 RAID 或分布式副本、网络交换机有没有做链路聚合。下面是一段简化的部署编排示意真实交付时镜像名和资源数值以厂商发版为准但结构可以拿来做容量估算apiVersion: apps/v1 kind: Deployment metadata: name: winex-clinical-service spec: replicas: 2 selector: matchLabels: app: winex-clinical template: metadata: labels: app: winex-clinical spec: containers: - name: clinical image: registry.internal/winex/clinical:release-2024.06 env: - name: SPRING_PROFILES_ACTIVE value: prod - name: DB_SCHEMA value: winex_clinical resources: requests: cpu: 4 memory: 8Gi limits: cpu: 8 memory: 16Gi readinessProbe: httpGet: path: /actuator/health port: 8080这里的逻辑是replicas: 2保证临床服务至少有两个副本避免发布或单点故障时直接断诊SPRING_PROFILES_ACTIVE定义了生产环境配置数据库连接、Redis 地址、消息队列这些不会写死在镜像里readinessProbe是就绪探针服务没做好准备前流量不会打进来。资源参数里 requests 和 limits 的差距不要拉太大否则 K8s 调度时会高估节点容量高峰期容易出现 CPU 节流。医院场景里 I/O 经常是瓶颈我给客户的建议是先在测试环境压一遍门诊高频操作再决定要不要把存储换成 SSD。2.4 中间件和数据库的配套规划WiNEX 落地时不会只有一个数据库。按业务域拆分后临床域、主数据域、集成日志域、CDR 域通常各自有库再加上 Redis 做会话和缓存、RabbitMQ 或类似消息队列做异步通知、Elasticsearch 做日志检索。实施方拿到部署文档后先不要急着搭环境应该把依赖关系画出来重点看哪些服务是强依赖、哪些服务挂了可以降级。我在这里吃过亏。有一回测试环境内存只有 32G把全部服务按默认参数拉起来还没开始测用例几个基础服务就因为缺内存接连重启。后来我把非核心服务的内存限制降到 1G把 CDR 的定时任务先关掉才把环境救回来。所以做容量规划时宁可先砍功能也不能砍基础组件配置中心、网关、注册中心这三个是绝对不能省资源的。3. 把临床业务配成可用主数据、医嘱闭环和关键参数3.1 主数据初始化科室、人员、服务编码WiNEX 的平台上跑业务前最先要干的是主数据初始化。医院里同一件事经常有多个编码财务科叫“门诊诊查费”临床科室叫“挂号费”医保接口里又是另一个码。WiNEX 的CDR 和医嘱域靠统一的编码来关联初始化做得越干净后面报表和医保上传越省事。我一般会要求实施团队先做“三码映射表”也就是院内码、医保码、平台标准码三个字段对齐。下面这段 SQL 表达的是科室主数据初始化时的一张基础表结构CREATE TABLE md_department ( dept_code VARCHAR(32) PRIMARY KEY COMMENT 院内科室编码, dept_name VARCHAR(128) NOT NULL COMMENT 科室名称, dept_type VARCHAR(32) NOT NULL COMMENT 业务类型: CLINICAL/IMAGING/LAB/ADMIN, parent_code VARCHAR(32) NULL COMMENT 上级科室编码, enabled_flag CHAR(1) DEFAULT 1 COMMENT 是否启用, gb_code VARCHAR(64) NULL COMMENT 医保或国家编码 );科室编码一旦定下来尽量避免上线后再改。因为 WiNEX 的消息路由、CDR 的患者就诊记录、医嘱归属都会引用这个编码改一个科室码牵一发动全身。如果必须改统一走主数据修改接口让下游服务监听变更消息不要直接 SQL 批量更新业务表。人员主数据也是一样的逻辑医生工号、护士工号、排班资源、签名证书都建议用同一个自然人主键关联。3.2 医嘱闭环用状态节点卡住每个执行环节医嘱闭环是 WiNEX 这类新一代系统里最容易被验收组抓指标的模块也是实施工作量比较大的地方。闭环不是一句“开医嘱、发药、执行”就完事而是要把一条医嘱从开立、审核、复核、配药、发药、执行、停药切成多个状态节点每个节点记录操作人、操作时间和消息内容。下面是一个简化后的闭环状态配置样例实际系统里这些节点通常维护在配置中心或数据库字典里不需要写代码但理解了结构才能正确勾选{ orderLinkCode: MEDICATION, linkName: 口服药执行闭环, nodeList: [ { nodeCode: ORDER_OPEN, nodeName: 医嘱开立, needSign: false }, { nodeCode: ORDER_AUDIT, nodeName: 医嘱审核, needSign: true }, { nodeCode: DISPENSING, nodeName: 药品调配, needSign: true }, { nodeCode: DELIVER, nodeName: 药品送达, needSign: true }, { nodeCode: EXECUTE, nodeName: 患者执行, needSign: true } ], timeoutRules: { AUDIT_TIMEOUT: 1800, DISPENSING_TIMEOUT: 1200 } }这个配置的核心逻辑是每个节点都有一个状态码、一个是否需要签名确认的开关以及一个超时时间。超时规则解决的是“医嘱开了但一直没人审核”这种监管问题超时后 WiNEX 会把消息推到护士站或药师工作台。实施时最容易踩的坑是把“发药”和“执行”合并成一个节点看起来闭环节点少了实际上漏掉了病区签收环节护理部一看统计就会提意见。3.3 必调参数频次、用药规则和消息提醒WiNEX 立项时讲得最多的是“可配置”可真正开工后你会发现配置项藏在菜单里你不问实施顾问就不知道有。我的习惯是拿到环境后先把医嘱域参数过一遍重点看三类默认频次、最大药品数量、用药规则开关。order: defaultFrequency: BID maxMedicationsPerOrder: 7 allergyCheckEnabled: true antibioticRuleEnabled: true infusionRateCheckEnabled: true timeoutAlert: true这里的defaultFrequency控制新建医嘱时默认带出的用药频次推荐 BID 即每日两次具体按医院习惯调。maxMedicationsPerOrder是单条医嘱最大药品数量设太大容易导致临床开“套餐医嘱”设太小又会打断正常的联合用药。antibioticRuleEnabled建议保持开启很多医院的抗菌药物管理要求就靠这个开关配合后台规则实现。参数配置完成后建议在测试环境模拟一次“越权开药”和“过敏史冲突”确认系统真的拦得住再跟临床科室宣导。3.4 医护工作台的个性化配置上线后医护抱怨最多的一句话往往是“界面没有以前顺手”。这不是 WiNEX 不行而是老 HIS 里医生已经习惯了个人排版。WiNEX 把页面布局、常用诊断、常用医嘱、病历模板都做成了可配置对象实施阶段要留出至少两个工作日做用户化调整。我会让每个科室选一个高年资医生和一个高年资护士把他们日常高频操作列成清单比如门诊医生要看“最近三次就诊记录”、住院护士要看“今日出院名单”然后按清单调整工作台组件。这个环节做得越细上线后临床的抵触情绪越小。别指望培训能解决习惯问题把界面调到贴近原有习惯才是最快的上手路径。4. 用 WiNEX 的数据中心做报表CDR 建模与可落地的指标口径4.1 CDR 里有什么以患者为中心的数据组织CDR 是 WiNEX 数据平台的核心它把所有业务域的数据按患者维度重新组织一遍。大概能看到这几类数据患者基本信息、就诊记录、诊断、医嘱、检查报告、检验结果、手术记录、费用明细等。数据模型不再关心业务表怎么存而是关心临床查询怎么取。实施中要特别留意“患者主索引”这个概念。同一个患者可能在门诊挂一次号、住院住一次院、体检中心做一次检查在旧的业务系统里是三套号。CDR 里如果没有把这三套号合并成同一个患者主键做出来的人力资源统计就会失真。WiNEX 一般会提供主索引匹配服务按身份证号、姓名、出生日期、手机号这些组合去重。实施团队要在上线前把历史数据的重复患者跑一遍该合并的合并该标记的标记。4.2 指标口径不一致报表战争的最大来源很多医院建完 CDR 后发现信息科出的报表和财务科出的报表对不上最根本的原因是口径不一致。比如“门诊人次”有的口径是“挂号笔数”有的是“实际接诊人次”有的是“缴费人次”三个数字各不相同。WiNEX 只能提供标准的数据元不替你做业务规则决策所以实施时必须把指标口径固化下来。我在项目里会组织一场“指标定义会”让医务科、财务科、病案室各派一个人每个指标都写清楚含义、公式、统计时点、数据来源。这不只是写文档而是要把口径落到 CDR 的视图或配置上。常见做法是建立一个指标字典表把指标编码、名称、分子、分母、过滤条件都维护进去后续报表统一从这里取定义。4.3 从 CDR 取数的最小 SQL医嘱完成率为例医嘱完成率是临床比较关注的指标它计算的是一段时间内已执行医嘱占应执行医嘱的比例。WiNEX 的 CDR 中通常会有一张医嘱事实表字段比业务表干净一些。下面这段 SQL 用来在报表工具里快速验证数据完整度SELECT COUNT(*) AS total_count, SUM(CASE WHEN execute_time IS NOT NULL THEN 1 ELSE 0 END) AS executed_count, ROUND(SUM(CASE WHEN execute_time IS NOT NULL THEN 1 ELSE 0 END) / COUNT(*), 4) AS execute_rate FROM cdr_order WHERE order_time 2025-06-01 00:00:00 AND order_time 2025-06-08 00:00:00 AND order_type IN (MEDICATION, TREATMENT);这段 SQL 的逻辑是先圈定一个统计时间窗口然后只看药品和治疗类医嘱最后用execute_time是否为空来判断这条医嘱有没有被执行。这里要注意execute_time必须从闭环消息里同步过来如果某条医嘱一直处于“待执行”状态说明闭环链路有问题要先排查集成平台的执行消息而不是修报表。对实施人员来说CDR 报表查出来数据不对百分之七十的问题在前端业务没有产生闭环消息而不是报表 SQL 写错。4.4 数据质量检查清单上线 CDR 之后我建议每个月跑一次数据质量检查重点关注四个维度患者主索引匹配了多少重复记录、当天就诊记录是否完整进入 CDR、检查报告是否与医嘱关联成功、费用明细有没有缺失分类。这四个维度对应四类常见问题重复主索引导致统计虚高消息丢失导致报表少数据关联错误导致漏检分类缺失导致财务分析不可用。WiNEX 的运维后台一般会有数据质量看板但更可靠的还是自己写检查脚本。做法是每天凌晨把 CDR 的关键表行数和业务系统源表行数做一次对账对不上的就往告警平台推消息。不要等到月底发现数据差了再回头补数那是最痛苦的“后悔药”补数补到天亮是常有的事。5. 老 HIS 切换到 WiNEX 的踩坑记录五类高频问题排查5.1 接口字段语义不一致同一个“性别”都敢对不上现象WiNEX 与检验系统对接后LIS 收到的性别字段大部分是对的但总有一部分患者显示“未知”。原因是老 HIS 的性别字典里有“男、女、未知、未说明”四项而 WiNEX 标准化字典只映射了“男、女”剩下两项映射不上集成平台就默认填充了“未知”。处理办法不要急着改集成平台的 ESB 映射脚本先两边拉出完整字典做一次差异对比把旧系统所有字段值都过一遍。性别、民族、婚姻状况、职业这类字段最容易出现脏数据。解决时保留旧系统原值在映射层做白名单而不是直接在 CDR 里改源数据。数据迁移阶段跑一遍统计把映射失败的记录全部捞出来逐条处理。5.2 历史医嘱迁移后闭环状态断裂现象切换后临床医生查看老患者的历史医嘱能看到内容所有医嘱都显示“已完成”。护士站统计上个月执行率时数字高得离谱。原因是迁移脚本把历史闭环记录的终末状态都置为完成却丢失了每个节点的真实操作时间。这类问题在新老系统切换中非常常见。我的建议是迁移历史医嘱时只迁移医嘱主表和关键执行记录不为凑“闭环完成率”而伪造节点数据。CDR 统计口径上把迁移数据单独打一个来源标签报表默认不把这些历史数据纳入强度指标。否则验收时数据好看真正复盘运营时全部失真。5.3 双写期间集成平台消息重复现象切换期间医院通常会有一段时间让 WiNEX 和老 HIS 并行运行WiNEX 发出的医嘱消息和排队系统里的历史任务同时处理导致同一笔检查申请被推送两次患者做了两次检查。原因在于消息没有设计幂等键。解决方法是让每条业务消息都带上一个全局唯一键建议使用“系统编码业务类型业务主键操作时间戳”组合集成平台在消费端按这个键去重。咨询WiNEX集成平台能否设置消息去重策略时不仅要在 WiNEX 侧做还要同步改造接收方接收方如果不去重投递多少次都白搭。这种问题我最常跟实施团队说的一句话是别迷信集成平台接收端不做幂等就是血泪经验。5.4 打印机、扫码枪和电子签名驱动不兼容现象某个科室切换完 WiNEX 后发现病区腕带打印机打出来全是乱码扫码枪扫医保电子凭证没反应。原因不是 WiNEX 业务问题而是客户端环境的浏览器版本、打印组件和外部设备驱动不兼容。这类问题最容易在试点科室爆发。我们一般会给病房做“终端基线检查”明确浏览器版本、分辨率、打印机驱动版本、扫码枪录入方式。WiNEX 的打印通常走统一打印服务如果页面无法调用本地打印机优先检查打印服务在不在运行然后看浏览器是否允许弹窗。别一上来就怪产品先用其它网页测试打印组件定位到底是业务接口的问题还是环境的锅。5.5 主数据同步首次加载大量失败现象WiNEX 上线后第一天科室字典、人员字典、收费项目字典同步任务显示完成但第二天医生开医嘱时找不到中药饮片项目护士站排班看不到部分护士。原因分析同步任务默认遇到错误会跳过而且日志级别是 info大量失败记录被淹没。首次全量同步一定要先跑小样本验证比如选一个科室、一个收费目录子集试跑确认主键映射稳定后再全量执行。全量执行后同步结果必须核对“成功数、失败数、失败原因TOP10”不能只看“已执行完成”四个字。另外主数据同步不是一次性工作。WiNEX 上线后一个月内医院仍在修正历史数据每天都会有人改科室、改人员、改项目编码。如果同步任务没有定时重跑业务系统里很快就会积累孤儿数据。我给客户定的规范是上线后第一周每天自动同步一次第二周开始每三天一次一个月后每周一次同时保留变更日志以便回滚。6. 怎么验收“值得做”四个可量化的落地指标WiNEX 上线三个月后管理层一定会问一句话这套系统到底带来什么变化。与其用“效率提升”这种词搪塞不如把四个指标拿出来量化对比门诊医生站关键操作平均耗时、医嘱闭环完成率、CDR 数据完整率、集成接口日失败率。指标计算公式数据来源验收意义门诊关键操作耗时从患者接诊到医嘱开立的总时长WiNEX 操作日志反映界面和流程是否顺滑医嘱闭环完成率已执行节点数 / 应执行节点数CDR 医嘱事实表反映业务闭环有没有跑通CDR 数据完整率当天入 CDR 记录数 / 源系统记录数定时对账脚本反映数据链路是否有丢失接口日失败率当日失败消息数 / 当日总消息数集成平台监控台反映外部系统对接稳定性这四个指标不是越高越好而是要先在旧系统上跑出基线值。比如旧系统接口日失败率可能从来没统计过那就先定一个可接受的底线比如低于 0.5%。对比时遵循同一统计时间段不要用门诊旺季的数据对比淡季的数据。指标下降时先定位是哪条链路的问题再决定是调参数还是改流程切忌直接改报表规避波动。我自己的习惯是每周一早上花二十分钟把这些指标拉出来看一眼哪个骤降就去翻对应链路的日志。WiNEX 这类平台最大的特点就是链路长、组件多、可观测性强只要你会看链路日志绝大多数问题都能找到根源。上线不是一个结果而是一个持续调优的过程谁能在运营期把指标用好谁才算真正把这个新平台接住了。希望这份踩坑经验能帮你少绕几段弯路。本文还有配套的精品资源点击获取