医院信息化项目的失败率，远高于绝大多数行业的统计数据。一项常被引用的内部数据是：约 30% 的医院软件项目在实施完成后一年内被弃用或部分弃用。智慧药房和处方点评系统这一类工具，因为涉及临床流程改造，失败率甚至更高。
失败的原因极少是技术上的——技术问题大多能被工程师解决。真正的失败几乎都源于选型阶段的判断失误：要么把销售的承诺当成产品的能力，要么把功能列表当成实际效用，要么忽略了实施和运维的隐性成本。
这篇文章不是产品对比，也不是品牌推荐。它是给即将启动智慧药房或处方点评系统采购的医院决策人——通常是药剂科主任、信息科长或医务科分管副院长——的一份"提问清单"。在签合同之前，这 24 个问题最好都得到清晰、可验证的答案。
维度一：需求评估（4 个问题）
这个维度的问题不是问供应商，是问自己。在打开任何产品手册之前，先把内部需求理清楚。
1. 我们到底想解决什么问题？
这不是一句空话。常见的真实需求包括：
- 应对即将到来的医保飞检
- 满足三级医院评审中的合理用药指标
- 缓解药剂科人力不足的压力
- 降低不合理用药导致的医疗纠纷
- 对接上级监管部门的数据上报要求
- 院领导层面的"智慧医院"建设任务
不同需求对应的产品形态完全不同。"应对飞检"的核心是历史数据全量留痕和闭环证据；"缓解人力压力"的核心是 AI 预筛能力和工作台效率；"智慧医院建设"的核心是大屏看板和领导驾驶舱。如果需求没想清楚，最容易陷入"功能多就是好"的陷阱，最后买回来一堆用不上的模块。
2. 我们的处方量是多少？人力配置是多少？
这两个数字决定了你需要的工具档次。一家日均处方 500 张的二级医院，和一家日均处方 5000 张的三级医院，对系统的需求是数量级的差异。
更重要的是人力。如果你只有 2 名临床药师，那么任何"需要药师每天花 3 小时配置规则"的系统都不适合你——人力本身就不够。这种情况下应当优先考虑开箱即用、规则库已预置的产品。
3. 我们准备投入多少预算？分几年支付？
这个问题的关键不在数字，在支付方式。一次性买断、按年订阅、按使用量付费的产品形态有本质差异。
- 一次性买断：前期投入大，但长期成本低。资产归医院所有，符合公立医院的资产管理逻辑。但要警惕"买断"是否包含未来的版本升级、规则库更新、技术支持。
- 按年订阅 / SaaS：前期投入小，可按预算节奏调整。但每年的续费压力是常态，且数据不在医院手中。需要评估退订后的数据所有权。
- 按处方量付费：极少见，但有些供应商会用这种方式。听起来很灵活，实际上你越用越被动。慎选。
4. 这个项目的真正决策人是谁？
在公立医院，名义上的决策人和实际上的决策人经常不是同一个人。一个项目可能：
- 药剂科提出需求
- 信息科做技术评估
- 医务科做合规评估
- 采购科走流程
- 分管副院长签字
- 院长最终拍板
在与供应商谈判前，先把每个环节的关键人物及其关切点想清楚。如果信息科长担心运维负担，那 demo 阶段就要重点演示运维便利性；如果医务科主任担心数据合规，那就要提前准备好等保测评报告。否则项目大概率会在某个环节被搁置。
维度二：HIS 对接难度（4 个问题）
这是技术评估的核心。一个不能稳定从 HIS 拿到数据的处方点评系统，再好的 AI 也是空转。
5. 对接方式是什么？需要 HIS 厂商配合改造吗？
这一条直接决定项目能否落地。市面上的对接方式分三种：
| 对接方式 | 特点 | 风险 |
|---|---|---|
| HIS 接口对接 | 调用 HIS 提供的标准接口 | 需要 HIS 厂商配合，改造费用 3-15 万，周期 1-3 个月 |
| 数据库只读对接 | 从 HIS 数据库直接拉取 | 需要 HIS 厂商授权数据库账号，但无需修改 HIS |
| 视图层对接 | HIS 提供专门的只读视图 | 最干净，但要求 HIS 厂商提供视图，少数 HIS 不支持 |
最理想的是数据库只读或视图层对接——不动 HIS 一根线，部署速度从月级缩短到周级。如果供应商坚持要走 HIS 接口对接，先确认 HIS 厂商的配合意愿和报价。这两边的博弈是医院信息化项目最大的隐性成本。
6. 病历快照能不能拿到？拿到的是哪一份？
处方合理性判断依赖于诊断信息，而诊断信息来自门诊病历。供应商必须明确回答：能拿到哪一部分病历——只有诊断字段？还是包括主诉、现病史、既往史、过敏史、查体、辅助检查结果？
没有完整病历快照的"AI 审方"基本只能做剂量校验和重复用药识别，对真正复杂的合理性判断无能为力。这是判断 AI 能力虚实的第一道关口。
7. 数据延迟是多少？是实时的还是 T+1？
这个问题关系到反馈周期。如果系统是 T+1 的（今天的处方明天才能分析），那"24 小时内问题预警"就只能是"昨天问题、今天反馈"——比月度反馈强，但仍然不是真正的实时。
真正的实时系统应当能在处方开出后分钟级完成分析并触发预警，最好是医生还在门诊的时候就能收到提醒。这对架构和数据通路的要求高得多。
8. 如果医院更换 HIS 厂商，对接成本是多少？
大多数医院都会经历 HIS 更换——可能是 5 年一次，可能是 10 年一次，但一定会有。问清楚：换 HIS 后，你们的处方点评系统需要重新对接吗？重新对接的成本是多少？是否需要重新购买？
如果供应商的产品强依赖某个 HIS 厂商（例如只支持东华、只支持创业慧康），那这是一个长期风险信号。优秀的产品应当能适配主流的所有 HIS。
维度三：AI 能力虚实（4 个问题）
"带 AI"已经成了医疗软件的标配宣传语。但 AI 这个词在不同供应商口中的含义千差万别，必须问到细节。
9. 你们的 AI 是规则引擎、传统机器学习、还是大语言模型？
三者性质完全不同：
- 规则引擎：预设的 if-then 规则。优点是可解释、稳定；缺点是只能处理已知场景，对复杂情形无能为力。市面上 80% 的"AI 审方"实际就是这个。
- 传统机器学习：基于历史数据训练的分类器。能处理一定的复杂度，但对训练数据的依赖很强，新医院新场景需要大量重新训练。
- 大语言模型：能理解自然语言病历、做复杂推理。但成本高、有幻觉风险、需要人工复核兜底。这才是真正意义上的"AI"。
真正先进的产品通常是"规则引擎打底 + 大语言模型补充"的双层架构——简单情形规则秒级判断，复杂情形交给大模型推理。
10. AI 部署在哪里？数据要不要出院？
这一条对公立医院尤其敏感。问清楚三种可能：
- AI 模型本地化部署：在医院内网跑国产开源大模型，数据完全不出院。最合规但硬件成本高。
- 安全代理访问外部 API：通过医院信息科批准的安全通道访问外部大模型 API，数据经脱敏处理。中等合规，成本低。
- 直接调外部 API：处方数据直接发到供应商或第三方的云端。这种方式在公立医院基本无法通过等保审查，但仍有一些供应商在做。
11. AI 的准确率是多少？怎么验证？
任何说"我们 AI 准确率 99%"的供应商，都应当被追问两个细节：
- 这个 99% 是在哪一类场景下测的？（剂量校验和复杂联合用药的难度天差地别）
- 这个 99% 能在我们医院重现吗？能不能用我们的真实数据做一次验证？
负责任的供应商会愿意做一次"真实数据验证"——给医院一段试用期，用医院自己的处方跑一遍，输出准确率报告。如果供应商拒绝这种验证，要警惕。
12. 如果 AI 判断错了，怎么纠正？谁负责？
AI 一定会出错——这是必然。问题是：
- 系统是否记录每一次药师对 AI 建议的采纳/驳回？
- 这些反馈数据是否反哺规则库或模型？
- 是否有自学习闭环让系统越用越准？
- 如果 AI 建议导致错过一张真正的违规处方，责任在医院还是供应商？
最后这个责任问题很多供应商不愿意正面回答，但合同中应当有明确条款：AI 建议仅为辅助，最终判断权在药师。这是双方都需要的责任边界。
维度四：部署模式与本地化（4 个问题）
13. 部署需要几台服务器？什么配置？
有些供应商会给一个夸张的配置清单——8 核 32G 起步、要 GPU、要高速 SSD、要 200G 内存——目的是把"硬件采购"作为一项额外收入。
实际上，一套服务于年处方量 30 万的智慧药房系统，合理配置是 8 核 16G 普通虚拟机即可。如果供应商开出的硬件清单明显超标，要追问："为什么需要这么高的配置？哪一个组件需要 GPU？"
14. 安装和升级流程是怎样的？需要供应商现场吗？
理想的部署是容器化、一键安装，整个过程不超过半天。后续升级也是容器镜像替换，无需停机。
如果供应商说"我们要派工程师现场安装一周"，那其实在说"我们的产品工程化程度不够"。现场安装意味着每次升级都要再来一次，每次都是一笔实施费用。
15. 如果断网或服务器故障，临床业务会受影响吗？
这是判断"系统耦合度"的关键问题。理想状态下，处方点评系统应当与 HIS 完全解耦——系统挂了，HIS 照常出方，只是暂时没有事后点评。供应商如果说"我们的系统挂了医生开方会受影响"，那就要警惕了——意味着他们做了某种深度耦合，故障域被拉大了。
16. 系统能纯内网运行吗？还是必须有外网连接？
大多数三级医院的核心区域都是纯内网。如果系统的某些功能（比如 AI 调用）必须有外网连接，那就要看供应商有没有提供"内网代理"或"离线大模型"方案。
不要相信"我们的系统支持纯内网部署"这种笼统的话——必须问清楚：纯内网下哪些功能可用、哪些不可用、AI 部分怎么处理。
维度五：信创与合规（4 个问题）
17. 是否适配国产操作系统、芯片、数据库？
2026 年的公立医院信息化项目，信创适配几乎是硬性要求。具体要问到型号：
- 操作系统：是否支持统信 UOS、麒麟（银河 / 中标）、华为欧拉？
- CPU 架构：是否支持鲲鹏（ARM）、飞腾、龙芯、海光？
- 数据库：是否支持达梦、人大金仓、神舟通用、华为 GaussDB？
注意区分"理论上支持"和"实际部署过"。最好要求供应商提供已经在信创环境中跑过的实际案例。
18. 是否取得相关安全认证？
采购清单上常见的认证包括：
- 软件著作权（基础门槛）
- 三级等保测评报告
- 信创生态认证（华为鲲鹏认证、麒麟兼容性认证等）
- ISO 27001 信息安全管理体系认证
这些认证不能证明产品好用，但能证明产品具备进入公立医院采购流程的基本资质。缺哪一项都可能在招标环节被卡。
19. 数据归属权如何界定？
这是 SaaS 模式必问的问题。明确写入合同：
- 所有医院数据（处方、点评结果、规则库）的所有权属于医院
- 供应商不得未经授权使用或共享医院数据
- 合同终止后，供应商应当在约定时间内将所有数据完整交付医院并销毁副本
- 数据迁移格式应当是开放标准（如 CSV、JSON），而非专有格式
20. 是否符合医保飞检与等级评审的检查要求？
这一条的本质是问："你们的系统设计是不是真的对照过监管要求？"。让供应商列出系统中哪些功能直接对应飞检的扣分项、哪些指标直接对应等级评审的合理用药条款。如果供应商对这些细节含糊其辞，说明他们的产品是从技术角度做的，不是从合规角度做的。
维度六：商务条款与服务（4 个问题）
21. 报价包含哪些？不包含哪些？
这是最容易出问题的一项。"包含"通常指：软件授权、首次安装、首年维保、基础培训。"不包含"经常包括：
- HIS 对接的实施费
- 规则库定制费
- 报表定制费
- 等保测评配合费
- 数据迁移费
- 专业服务（驻场、二次开发）
- 第二年起的维保费
这些"不包含"的项目如果一一加起来，可能是软件授权价的 1-2 倍。在签合同前必须把所有"可能产生的额外费用"列成清单，明确每一项是包含还是不包含、不包含的话价格是多少。
22. 维保的响应时间是多少？
响应时间不只是数字，要看有没有 SLA（服务等级协议）。区分严重程度：
- P0（系统全停）：理想响应 ≤ 30 分钟，恢复 ≤ 4 小时
- P1（重要功能异常）：响应 ≤ 2 小时，恢复 ≤ 1 工作日
- P2（一般问题）：响应 ≤ 1 工作日，恢复 ≤ 5 工作日
这些 SLA 必须写入合同，并约定违约责任。否则"7×24 服务"很可能只是销售口头承诺。
23. 培训内容、对象、方式是什么？
培训是项目落地的关键环节，但常被忽略。问清楚：
- 培训对象：药剂科全员还是只培训管理员？
- 培训方式：线下集中、线上录播、还是 1 对 1 实操？
- 培训次数：一次性还是定期重复？
- 培训材料：是否提供完整的用户手册、操作视频、常见问题文档？
- 新员工培训：未来新入职的药师，培训费用谁承担？
24. 如果不满意，退出机制是怎样的？
不要把这个问题看作"不吉利"。任何严肃的采购都应当有退出机制：
- 试用期内不满意：可以无条件退款吗？
- 正式使用后发现不符合需求：有没有部分退款机制？
- 合同到期不再续约：数据如何交付？历史报表能否长期访问？
- 供应商破产或停止支持：是否有源代码托管或开源版本兜底？
能在合同中接受这些条款的供应商，往往是对自己产品最有信心的。反过来，刻意回避这些条款的供应商，需要警惕。
最终决策：一份打分表
把上面 24 个问题转化为一份打分表，每个问题 0-5 分。建议把每个候选供应商的得分填进去，不要凭感觉做决策：
| 维度 | 权重 | 最高分 |
|---|---|---|
| 需求评估匹配度 | 15% | 20 |
| HIS 对接难度 | 20% | 20 |
| AI 能力虚实 | 20% | 20 |
| 部署模式与本地化 | 15% | 20 |
| 信创与合规 | 15% | 20 |
| 商务条款与服务 | 15% | 20 |
权重可以根据自家医院的实际情况调整。如果你们医院已经在准备医保飞检，"信创与合规"的权重就该上调；如果你们的 HIS 系统极其复杂、对接困难是已知风险，"HIS 对接难度"的权重就该上调。
把候选供应商的得分一一填进表里，往往会发现：那个销售最热情、demo 最炫目的供应商，并不一定是综合得分最高的那个。这就是结构化决策的价值——把感性的"好印象"还原为理性的"得分项"。
最后一句话：智慧药房系统选型是一次长期决策。一旦上线，迁移成本是天文数字。多花一周时间做尽职调查，比上线后再后悔要划算得多。
这 24 个问题不是要让你为难供应商，而是让你和供应商一起把所有不确定性提前暴露——这对双方都是好事。最好的供应商会感谢你提出这些问题，因为他们会用清晰的回答证明自己。最差的供应商会回避这些问题，让你避免一次错误的采购。