企业官网建设流程全解析

简介：这份PDF资料系统介绍卫宁健康新一代医疗数字化转型平台WiNEX，面向医院信息科人员、医疗IT产品经理及关注智慧医疗的开发者，聚焦解决医疗机构在流程再造、信息共享、系统集成与数据标准化等方面的共性痛点。资源为单文件PDF，共4.32MB，内容覆盖临床业务重塑、数据标准模型、开放服务层和数字化场景创新等核心模块，并结合SNOMED-CT、HL7 FHIR等国际标准与“1+X”中台架构进行说明，便于快速建立对WiNEX整体方案的认知。目前已有858人学习下载。通过阅读可掌握WiNEX在医生工作站、电子病历、医嘱闭环、数据资产治理及互联网医疗场景中的设计逻辑，适合作为产品选型、需求调研或院内系统数字化转型的参考材料。

1. WiNEX 是平台，不是又一个 HIS

第一次接触 WiNEX 的人，十有八九会把它当成一套“升级版 HIS”来看。实际上去年医共体项目里，我陪医院信息科做选型评估，前二十分钟听到的全是“临床工作站”“住院医嘱”“电子病历”，等看到交付清单里还有集成引擎、CDR 数据中心、低代码配置台和消息路由，才知道 WiNEX 走的是平台路线，而不是单机版业务软件换皮。卫宁健康把 WiNEX 定位成新一代医疗健康数字化底座，本质上是要把原来耦合在旧 HIS 里的业务能力拆开、重组、标准化，让门诊、住院、急诊、药事、检验、数据上报都能在一个底座上长出来。

它适合两类人深度关注：一类是医院信息科和临床信息化负责人，关心的是能不能从旧系统平滑迁移；另一类是医疗软件公司、集成商和独立实施工程师，关心的是集成怎么对接、数据怎么治理、上线后出了故障怎么排查。WiNEX 能解决的问题也很具体：老系统接口散、数据口径乱、厂商绑定深、新需求排期慢。不是说换一套 HIS 就自动解决，而是它给了你一套可配置、可组装、可观测的框架，能不能发挥出来，取决于实施方怎么拆业务、怎么定编码、怎么做数据迁移。

2. 用云原生底座拆掉单体 HIS：WiNEX 的分层与部署形态

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 数据完整率、集成接口日失败率。

这四个指标不是越高越好，而是要先在旧系统上跑出基线值。比如旧系统接口日失败率可能从来没统计过，那就先定一个可接受的底线，比如低于 0.5%。对比时遵循同一统计时间段，不要用门诊旺季的数据对比淡季的数据。指标下降时，先定位是哪条链路的问题，再决定是调参数还是改流程，切忌直接改报表规避波动。

我自己的习惯是每周一早上花二十分钟把这些指标拉出来看一眼，哪个骤降就去翻对应链路的日志。WiNEX 这类平台最大的特点就是链路长、组件多、可观测性强，只要你会看链路日志，绝大多数问题都能找到根源。上线不是一个结果，而是一个持续调优的过程，谁能在运营期把指标用好，谁才算真正把这个新平台接住了。希望这份踩坑经验能帮你少绕几段弯路。

本文还有配套的精品资源，点击获取