企业官网建设流程全解析

简介：天健云HIS解决方案文档面向基层医疗机构信息化负责人、医院IT运维人员及医疗信息化方案设计者，针对传统PC终端成本高、维护频繁、操作者技能要求高等痛点，提供一套基于云计算与B/S架构的标准化医院信息管理系统方案。资源包共1个docx文件，大小约1.12MB，内容涵盖云计算解决方案、系统设计、门诊诊疗流程等核心模块，详细阐述云终端替代传统PC的部署思路、服务器集群与负载均衡策略，以及挂号、就诊、收费、取药、退费等完整门诊业务闭环。文档还涉及健康档案统一存储、医疗数据共享交换与区域卫生信息化平台建设等关键议题，可帮助读者理解云HIS的架构选型、终端部署与运维优化路径。目前已有261人学习下载，适合需要编制医疗信息化方案或评估云终端改造可行性的技术人员参考。

1. 天健云 HIS 解决方案到底解决什么问题：从一台打印机引发的全院停摆说起

凌晨两点，住院部护士站打来电话说医嘱下不下去，我赶到现场发现是前置机的服务卡死了，重启后一切恢复。这件事让我彻底想明白一件事：医院信息系统最怕的不是功能少，而是关键链路断掉之后没有兜底。天健云 HIS 解决方案这个标题，本质上讲的就是一套面向医院的云端医院信息系统怎么落地——它把挂号、门诊、住院、收费、药房、医嘱、电子病历这些核心业务串成一条链，用云化的部署方式替代过去每个医院自己买服务器、自己装数据库、自己维护的老路子。

这套方案适合谁？一是医院信息科里要接手云 HIS 的运维人员，二是 his 实施工程师需要掌握从环境准备到上线切换的全流程，三是做医疗信息化的集成商技术负责人。它解决的核心诉求就三个：业务不中断、数据不丢、上线能回退。接下来我按自己实际推过的项目节奏，把选型理由、部署步骤、参数配置和踩过的坑一条条讲清楚，你照着能复现个七八成。

2. 天健云 HIS 的部署架构与最小可跑通环境

2.1 为什么是云化架构而不是传统 C/S 堆服务器

传统 HIS 大多是 C/S 架构，每个科室装客户端，数据库放院内机房，升级一次要挨个科室跑。天健云 HIS 走的是 B/S 加微服务的方向，前端浏览器直接访问，后端按业务域拆成挂号服务、医嘱服务、计费服务等独立模块，数据库用主从加读写分离。这么选的理由很实在：升级只推服务端，科室不用动；某个模块挂了不影响挂号；扩容加节点就行，不用换整机。

但云化不是没有代价。网络抖动会直接反映到医生开医嘱的体验上，所以院内网络必须做双链路，核心交换机到服务器之间不能有单点。我一般会要求院方把 HIS 所在的 VLAN 单独隔离，QoS 里给 HIS 流量最高优先级，这一步不做，后面卡顿的锅全在你头上。

2.2 最小可跑通环境清单与依赖版本

先给一份我实际用过的环境清单，版本号按你拿到的安装包为准，这里写的是常见搭配：

内存方面，应用节点至少 16G，数据库节点 32G 起步，磁盘用 SSD，日志盘和数据盘分开。别用机械盘跑数据库，我见过因为 IO 跟不上导致医嘱保存超时的案例，查了两天才定位到磁盘。

2.3 用 Docker Compose 拉起最小验证环境

正式环境一般用 K8s，但验证阶段我习惯先用 Compose 把链路跑通，确认服务间调用没问题再上集群。下面这份 compose 文件是我简化过的，只保留核心依赖：

version: "3.8" services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: His@2024 MYSQL_DATABASE: tjhis command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:6.2 ports: - "6379:6379" rabbitmq: image: rabbitmq:3.9-management ports: - "5672:5672" - "15672:15672" his-app: image: tjhis/app:latest depends_on: - mysql - redis - rabbitmq environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/tjhis?useUnicode=true&characterEncoding=utf8 SPRING_REDIS_HOST: redis SPRING_RABBITMQ_HOST: rabbitmq ports: - "8080:8080"

逻辑说明：mysql 初始化时直接建好 tjhis 库并指定 utf8mb4，避免后期改字符集；his-app 通过环境变量注入连接信息，不写死在配置文件里，方便换环境。参数上注意MYSQL_ROOT_PASSWORD换成你自己的，tjhis/app:latest换成实际镜像名。启动后访问 8080 能看到登录页，说明基础链路通了。

提示：验证环境不要用 latest 标签上生产，镜像版本必须固定，否则回滚时找不到对应版本。

3. 核心业务模块的配置与数据初始化

3.1 字典数据初始化的顺序不能乱

天健云 HIS 上线前最耗时的是字典初始化。科室、人员、收费项目、药品目录、诊疗项目这几类字典有依赖关系：人员要挂科室，收费项目要挂诊疗项目，药品要挂收费项目。顺序错了就报外键约束失败。我一般按这个顺序导：科室 → 人员 → 诊疗项目 → 收费项目 → 药品 → 耗材。

导入用命令行比界面快得多，下面是我常用的批量导入脚本：

#!/bin/bash # 按依赖顺序导入字典，失败即停 set -e DB="tjhis" USER="root" PASS="His@2024" for table in dept staff diagnosis charge_item drug material; do echo "正在导入 ${table} ..." mysql -u${USER} -p${PASS} ${DB} < ./dict/${table}.sql echo "${table} 导入完成" done

逻辑说明：set -e保证任何一步失败就终止，避免脏数据继续灌入。每个 sql 文件里我习惯先DELETE FROM再INSERT，保证可重复执行。参数上把 USER 和 PASS 换成实际值，dict 目录放导出的 sql 文件。导入完用SELECT COUNT(*)核对条数，和源系统对不上就查是不是有隐藏字符导致主键冲突。

3.2 医嘱与计费联动的参数配置

医嘱开立后要自动生成计费记录，这个联动靠配置表控制。核心参数在sys_config表里，几个关键项：

order.cancel.window这个参数特别容易踩坑。设太大，护士误操作撤销后费用已经产生，退费麻烦；设太小，医生开错想改都来不及。我一般设 30 分钟，并且要求撤销必须走审批。charge.batch.size影响计费性能，200 是压测出来的平衡点，太小频繁提交，太大事务锁等待。

改完参数要重启应用服务，天健云 HIS 的配置是启动时加载的，热更新支持有限。重启命令：

# 进入应用容器后执行 sh /opt/tjhis/bin/restart.sh # 查看启动日志确认配置生效 tail -f /opt/tjhis/logs/startup.log | grep "config loaded"

看到config loaded且后面列出你改的参数键，说明生效了。没看到就检查配置文件路径是不是被环境变量覆盖了。

3.3 数据库主从同步的验证方法

数据不丢的前提是主从同步正常。配置好主从后，别只看SHOW SLAVE STATUS里的Yes，要实际验证。我一般插一条测试数据，然后从库查：

-- 主库执行 INSERT INTO sync_test (id, note, create_time) VALUES (9999, 'sync_check', NOW()); -- 从库执行，等 1 秒后查 SELECT * FROM sync_test WHERE id = 9999;

从库能查到说明同步链路通。如果Seconds_Behind_Master持续大于 5，检查网络延迟和从库 IO。我遇到过从库磁盘满导致同步中断，但状态还显示 Yes 的情况，所以定期用脚本核对数据条数差是必要的。

4. 上线切换与回退方案：怎么做到业务不中断

4.1 灰度切换的科室选择策略

全院一次性切换风险太大，我一般分三批：第一批选体检科或康复科这种业务相对独立、量小的科室；第二批选门诊；第三批住院和急诊。每批观察 3 天，重点看医嘱保存成功率、计费准确率、打印是否正常。

切换当天要做的第一件事不是开新系统，而是把旧系统的数据做一次增量同步。天健云 HIS 一般提供迁移工具，但工具跑完必须人工核对关键表：患者主索引、未结算费用、在院患者列表。这三张表对不上，后面全是纠纷。

4.2 回退触发条件与操作步骤

回退不是失败，是保命手段。我设的触发条件是：核心业务中断超过 15 分钟，或数据不一致条数超过 10 条，或医生集体反馈无法开医嘱。满足任一条立即回退。

回退步骤：

# 1. 停止新系统写入，避免数据继续分叉 sh /opt/tjhis/bin/stop_write.sh # 2. 把切换后新系统产生的数据导出 mysqldump -uroot -p tjhis > /backup/tjhis_rollback_$(date +%Y%m%d%H%M).sql # 3. 切回旧系统，恢复旧系统服务 systemctl start oldhis # 4. 通知科室继续用旧系统，新系统数据待后续合并

逻辑说明：先停写再导出，保证导出的数据是完整的。导出的 sql 留着，等新系统问题修复后可以把这部分数据补进去，不用重头再来。参数上备份路径要提前建好并确认有空间，我见过回退时磁盘满导致备份失败的，那真是后悔药都没得吃。

注意：回退脚本必须提前演练一遍，别等真出事才第一次跑。

4.3 切换后的数据核对清单

切换完成后 24 小时内，我会跑一遍核对脚本，重点比对这些：

• 在院患者数与旧系统一致
• 当日挂号量与收费金额匹配
• 药品库存扣减与处方量对应
• 未结算费用无遗漏

核对脚本用 Python 写比较灵活：

import pymysql def compare_count(old_conn, new_conn, table, where=""): with old_conn.cursor() as c: c.execute(f"SELECT COUNT(*) FROM {table} {where}") old_n = c.fetchone()[0] with new_conn.cursor() as c: c.execute(f"SELECT COUNT(*) FROM {table} {where}") new_n = c.fetchone()[0] status = "OK" if old_n == new_n else "DIFF" print(f"{table}: old={old_n} new={new_n} [{status}]") old = pymysql.connect(host="oldhis", user="read", password="xxx", database="his") new = pymysql.connect(host="newhis", user="read", password="xxx", database="tjhis") compare_count(old, new, "patient", "WHERE status='在院'") compare_count(old, new, "charge", "WHERE DATE(create_time)=CURDATE()")

逻辑说明：只读账号连接，避免误写。where条件按实际业务加，比如只比在院患者。输出 DIFF 就人工介入查原因，常见的是时间边界导致统计口径不同，不一定是真丢数据。

5. 天健云 HIS 实施中最容易翻车的五个坑

5.1 坑一：字符集不统一导致患者姓名乱码

现象：迁移后部分患者姓名显示问号或方块。原因：旧库是 GBK，新库建成了 utf8mb4，迁移工具没做转码。解决：迁移前统一确认源库和目标库字符集，用SHOW VARIABLES LIKE 'character%'查。已经乱码的，用CONVERT(BINARY CONVERT(name USING gbk) USING utf8mb4)尝试修复，但成功率看数据，最好还是重新迁。

5.2 坑二：医嘱撤销后费用未同步冲红

现象：医生撤销医嘱，但收费记录还在，患者投诉多收费。原因：撤销走的是异步消息，消息丢失或消费失败没重试。解决：检查 RabbitMQ 的死信队列，把失败消息重新入队；同时在sys_config里把order.cancel.retry设为 3，并加告警监控死信数量。

5.3 坑三：打印模板错位导致发票打不出来

现象：收费发票打印出来金额和项目错位。原因：新系统打印模板用的 CSS 和旧打印机驱动不兼容。解决：打印模板改用固定像素单位，别用百分比；打印机驱动统一换成医院实际型号的官方驱动，别用系统自带的通用驱动。这个坑很玄学，同一模板在不同打印机上表现不一样，必须现场调。

5.4 坑四：主从延迟导致刚开的医嘱查不到

现象：医生开完医嘱，护士站刷新看不到。原因：写主库读从库，主从延迟几百毫秒。解决：关键业务查询强制走主库，在代码里加/* master */提示，或者把医嘱查询的读库指向主库。延迟持续大就要查从库负载和网络。

5.5 坑五：回退时旧系统数据已被覆盖

现象：想回退发现旧系统数据库被新系统迁移工具清空了。原因：迁移工具默认先清目标库，操作前没备份。解决：迁移前必须对旧库做全量备份，并且备份文件异地存一份。这个坑一旦踩了就是血泪教训，没有后悔药。

6. 用压测和监控把问题挡在上线之前

上线前我必做一轮压测，不是走形式，是实打实模拟门诊高峰。用 JMeter 模拟 200 个并发医生同时开医嘱，持续 10 分钟，看响应时间和错误率。天健云 HIS 的医嘱接口在 200 并发下响应应该控制在 500ms 以内，超过 1s 就要查数据库慢查询和连接池。

压测脚本关键配置：

# JMeter 命令行压测，生成报告 jmeter -n -t order_test.jmx -l result.jtl -e -o ./report # 查看聚合报告里的 99% 线和错误率

参数上线程数按实际医生数的 1.5 倍设，ramp-up 设 60 秒让压力逐步上来。压测完看result.jtl里的错误请求，逐条分析是超时还是业务异常。

监控方面，我习惯用 Prometheus 加 Grafana 盯几个核心指标：JVM 堆内存、数据库连接数、RabbitMQ 队列深度、接口 P99 延迟。队列深度持续增长说明消费跟不上，要加消费者或优化逻辑。P99 突然飙升先看数据库慢查询日志。

最后一个技巧：把每次上线的配置变更、数据库变更、脚本执行都记到一个变更日志里，格式就三列——时间、操作、影响范围。出问题时翻这个日志，比问谁都管用。我带过的项目里，凡是坚持记变更日志的，排障时间至少省一半。希望帮到你。

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