前言
县域医院信创改造，不是 "所有组件都选同一个品牌" 才最好。很多人迷信全栈同厂商，实际落地反而容易踩坑。
我们的核心目标就 3 条：
- 能承载 HIS、云药房、医保结算，门诊高峰不卡顿；
- 出现问题，有原厂技术支持兜底，信息科不用硬啃底层问题；
- 尽量减少特殊适配工作量，降低项目实施和后期运维成本。
很多信息科自己也分不清鲲鹏、飞腾、海光到底怎么选，只听过名字。你把本章这套逻辑讲给他，对方会觉得你是干过现场的，不是只会念 PPT 的售前。
一、服务器芯片选型（核心硬件，最先定）
鲲鹏（ARM 架构）
优点：国内落地案例最多，医疗行业 HIS、药房系统适配成熟；服务器整机厂商选择多。ARM 功耗低，机房散热压力小，适合县域老旧机房。医疗软件厂商大多都做过鲲鹏适配，POC 阶段踩坑概率偏低。
缺点：ARM 指令集和传统 x86 差异大，一些小众外设、第三方小工具适配麻烦；如果后续要对接一些老旧小系统，很容易卡住。另外，鲲鹏生态基本锁定 ARM，后期想换 x86 路线迁移成本高。
适合场景：HIS + 云药房为主，没有大量老旧第三方小系统，预算中等，追求稳定，优先选鲲鹏。县域医共体主生产服务器最常用。
飞腾（ARM 架构）
优点：信创资质齐全，国产化纯度高，部分地区卫健招标会优先推荐飞腾。单机性能不错。
缺点：医疗 HIS 案例总量少于鲲鹏，部分老版本中间件、数据库适配会出小问题；不同批次主板、固件版本差异不小，POC 必须拿和投标同型号机器实测，不能拿样机简单跑一下就拍板。
适合场景：地方招标有明确导向，要求高国产化指标，预算充足。不推荐预算紧、工期短的项目，适配调试工作量会多一些。
海光（x86 兼容架构）
优点：最大优势，兼容传统 x86 的使用习惯。很多原来跑在 Intel 服务器上的程序，少量修改甚至不用改就能跑。数据库、第三方工具、运维脚本几乎不用大改，迁移难度最低。信息科上手最快，运维习惯不用重新学。
缺点：国产化评审部分地区会有争议，个别地区卫健验收打分上会吃亏；长期看 x86 兼容生态的迭代风险。
适合场景：医院系统复杂，一堆老旧第三方小系统，工期很紧、不想花大量时间做应用适配。一定要提前跟信息科、监理、卫健确认当地验收是否认可海光，这个是红线，不确认千万别选。
一线选型结论：
县域 HIS + 云药房核心生产节点，优先鲲鹏 ；招标硬性要求高国产化，选飞腾；系统杂、老应用多，提前确认当地政策后再考虑海光。
不要图省事，直接所有服务器选同一种芯片。可以拆分：主业务 HIS、云药房用鲲鹏；一些辅助查询、归档服务器，根据实际情况调整。
二、服务器操作系统选型：麒麟 vs 统信 UOS 服务器版
麒麟服务器操作系统
医疗行业绝对主流，卫健、医院信息科最熟悉。
优点：医疗项目案例海量，数据库、中间件、HIS 厂商适配优先适配麒麟；售后技术支持团队对医院场景熟悉，遇到问题，厂商客服能快速定位。运维文档、故障案例多，网上能找到大量医疗项目的排障经验。监理、验收专家认可度最高，基本不会在操作系统层面卡验收。
缺点：版本坑比较多，不同小版本之间差异大，千万别随便选最新未经过大量项目验证的版本。固定一个稳定版本，全程不随意升级。
适合场景：县域医院核心业务服务器，HIS、云药房、医保结算节点首选。
统信 UOS 服务器版
优点：界面友好，操作逻辑贴近传统 Linux，新手运维上手快。
缺点：医疗 HIS 落地案例远少于麒麟。很多老的 HIS、药房软件厂商，对统信服务器版适配投入不足。一旦遇到兼容性问题，排障周期更长。监理和卫健验收人员接触的少，偶尔会被追问。
适合场景：办公、非核心业务、归档查询服务器。不建议把 HIS、云药房这种生产核心业务部署在统信服务器版。
实操提醒：选定操作系统版本之后，锁定版本号，禁止上线后随意升级内核。很多项目后期莫名其妙的 bug，都是运维顺手升级内核搞出来的。
三、数据库选型：达梦 vs 人大金仓，县域医院怎么取舍
核心业务 HIS、云药房，二选一为主，基本不会考虑其他。
达梦数据库
县域医疗项目占有率最高，Oracle 语法高度兼容，这是最大亮点。
优点：原来旧系统如果是 Oracle，迁移改写工作量小，存储过程、函数改动量可控。医疗 HIS、药房库存结算场景案例非常多，数据迁移工具成熟。技术支持响应在医疗行业整体靠谱。
缺点：授权费用偏高；高并发复杂场景调优需要经验，信息科自己很难搞定，需要厂商 / 实施方驻场调优。
适合场景：旧库是 Oracle，HIS + 云药房核心业务，大量存储过程，不想大规模改写 SQL。县域医共体首选。
人大金仓
优点：授权方案更灵活，同等规模下成本通常低于达梦；稳定性不错，对于标准 SQL 业务表现稳定。
缺点：和 Oracle 语法差异更大，大量存储过程、自定义函数要重写。如果旧系统是 Oracle，改造工作量会明显增加。
适合场景：原有系统是 MySQL，业务逻辑简单，存储过程少，预算压力大。
避坑提醒：不要指望数据库厂商帮你改业务 SQL。数据库只负责存储，HIS 和药房业务的 SQL 改写，是软件厂商的责任。合同边界一定要写清楚，很多项目在这里扯皮。
四、中间件选型：东方通、宝兰德、金蝶天燕
HIS、云药房 web 应用，这三个是医疗项目最常见。
东方通
医疗行业标杆，案例最多。HIS 厂商适配优先做东方通。监理、验收认可度高，踩坑少。
缺点：价格偏高，老旧版本偶尔会有连接池、长连接泄漏问题，上线前 POC 要重点压测并发。
宝兰德
性能表现不错，高并发场景稳定，并发连接管理做的好。
缺点：医疗案例少于东方通，部分小众 HIS 适配需要调试。
金蝶天燕
价格优势明显，预算紧张的时候可以考虑。
缺点：医疗落地案例偏少，遇到复杂业务场景，适配工作量会增加。
一线建议：核心 HIS、云药房、医保结算 web 服务，优先东方通；预算紧张，业务并发压力不大，再考虑宝兰德。不建议把金蝶天燕放在核心生产业务上，可用于非核心查询模块。
五、推荐的 3 套落地组
方案 A（县域医共体主推，稳妥首选，大部分项目都用这套）
- 服务器：鲲鹏
- OS：麒麟服务器（锁定稳定版本）
- 数据库：达梦
- 中间件：东方通
适用：HIS + 云药房、医保结算核心业务；旧数据库是 Oracle；工期常规，不想冒适配风险。
优点：案例多，验收最稳；迁移工具成熟；信息科、监理认可度最高。
缺点：整体采购成本偏高。
方案 B（预算压缩版，业务逻辑简单，存储过程不多）
- 服务器：鲲鹏
- OS：麒麟服务器
- 数据库：人大金仓
- 中间件：东方通
适用：医院业务简单，旧系统不是 Oracle，预算有限，SQL、存储过程量不大。
优点：整体成本下降，稳定性足够支撑门诊、药房日常业务。
缺点：Oracle 迁移场景下，代码改造工作量增加。
方案 C（旧系统复杂、大量老应用，提前确认当地政策）
- 服务器：海光
- OS：麒麟服务器
- 数据库：达梦
- 中间件：东方通
适用：院内一堆老旧第三方小系统，不想大规模改代码，工期短。
硬性前置动作：提前书面确认卫健、监理认可海光，否则直接放弃这套方案。
六、POC 测试重点，不是跑起来就算完事
很多 POC 就是部署一套系统，打开页面能登录，就判定通过。这种 POC 毫无意义，上线之后必出问题。
POC 必须测下面这几项，现场记录数据，形成 POC 报告给信息科留存：
- 并发压测：模拟门诊高峰，同时多窗口挂号、收费、药房发药，持续跑 2~4 小时。观察 CPU、内存、连接池，有没有连接堆积、页面卡顿。
- 数据库压力测试：批量处方写入、库存扣减、盘点查询，重点测试并发下库存事务一致性，不能出现超扣库存。
- 外设联动测试：信创终端 + 条码打印机、处方打印机，连续批量打印，测试驱动稳定性。这个很多 POC 直接漏掉，上线药房直接瘫痪。
- 故障演练：模拟服务器重启、数据库异常断开，看业务是否可以自动恢复，有没有出现库存、收费脏数据。
- 备份恢复演练：执行一次完整备份，然后把备份文件恢复到另一台机器，验证数据完整。只备份不做恢复测试等于没有备份。
POC 报告要写清楚测试环境型号、版本、测试用例、结果，信息科签字留存，后续验收可以直接作为支撑材料。
七、选型最容易踩的坑，都是现场踩出来的
- 盲目追求 "全栈国产同品牌"，为了凑品牌，牺牲软件适配稳定性。品牌统一只是加分项，业务稳定才是底线。
- 只看硬件在信创目录，不查 HIS、云药房软件是否已经完成该硬件 + OS + 数据库组合的适配。硬件合规，业务软件不适配，项目直接卡住。
- 选最新版本操作系统、数据库。新版本 bug 多，医疗项目优先选已经在上百个医院跑过的稳定旧版本。
- 忽略授权边界。数据库、中间件授权，是按 CPU 核数、并发连接还是用户数？合同写清楚，后期扩容会不会额外收费。很多项目后期被追加授权费用。
- 把归档、查询库和核心生产库混在一起部署。查询报表大量读操作会挤占 HIS、药房的业务资源，门诊高峰造成卡顿。建议分离部署。
- 跳过 POC 外设打印测试，上线才发现条码打印机驱动不兼容。药房窗口一旦打不出药品条码，门诊直接停摆。
本章小结
信创选型不是比参数、比宣传页。县域医院的核心诉求是稳、少折腾、出问题有人兜底，验收能顺利通过 。
优先方案 A 鲲鹏 + 麒麟 + 达梦 + 东方通，是经过大量县域医共体验证的成熟组合，信息科接受度最高，适配踩坑最少。预算有限再考虑人大金仓。海光方案一定要提前确认当地政策，不要盲目选用。
选型阶段一定要配套完整 POC，不光测业务页面，还要压测并发、做备份恢复、测试外设打印。POC 不是走过场，是提前暴露风险，避免割接上线翻车。