现场实录：在“密封”的内网里做集成
上周在南方某市中心医院，信息科的张主任指着那台还在跑 Windows 7 系统的挂号机对我说：“小王，语音识别能上，但 HIS 厂家开出的 WebService 接口费要 15 万，你觉得这钱该出吗？”
这就是医疗 ASR 本地部署最真实的尴尬：技术不难，难在“进不去”。很多 10 年前开发的 HIS（医院信息系统）就像一个黑盒，既不支持现代的 Restful API，也没有文档。如果你想让医生口述的病历直接“蹦”进输入框，除了交保护费，难道只能手动 Ctrl+C / Ctrl+V 吗？
方案一：虚拟键盘注入（最省钱的“暴力美学”）
在灵声智库的很多项目中，如果客户明确表示不想动 HIS 源码，我们会采用“虚拟键盘映射”技术。
简单来说，我们的本地 ASR 引擎在后台运行，当识别出文本后，直接通过系统底层的 SendInput 函数模拟键盘按键。对于 HIS 系统来说，它根本不知道这是 AI 在说话，它只觉得自己接到了一串极快的键盘输入。
避坑指南：这种方案虽然省掉了 15 万接口费，但要注意“输入焦点”丢失的问题。如果医生在说话时手滑点了下桌面，文字就会乱串。我们在 V12.8 版本中引入了“进程锁定计数器”，强制让识别流只发往特定的 EMR.exe 句柄，解决了这个低级错误。
方案二：中间表（Database Buffer）同步
如果医院的数据库（通常是 Oracle 11g 或 SQL Server 2008）权限还算开放，中间表是比 WebService 更稳妥的选择。
我们在院内内网服务器上架设一个轻量级的中间库。ASR 识别结果实时写入 Voice_Buffer 表，HIS 侧通过一个触发器或定时轮询来抓取。这种方案的优势在于“数据可追溯”，即使 HIS 挂了，语音原文和转写稿还在，方便后续质控。
方案三：剪贴板拦截与 COM 组件注入
这是最硬核的做法。针对某些基于 Delphi 或 VB 开发的“骨灰级”HIS 客户端，我们利用 COM 接口或者 DLL 注入技术，直接获取其 RichEdit 控件的内存地址。
虽然开发工作量大，但它能实现真正的“结构化填充”。比如医生说“主诉：头痛三日”，系统能自动拆分，把“头痛三日”填入主诉框，而不是一股脑堆在现病史里。
这种事，别找云端 ASR
很多大厂的云端 ASR 方案在这里会彻底哑火。为什么？因为医院内网是物理隔离的。你想用外网 API？对不起，先过等保、再申请防火墙策略，折腾半年，院长都换届了。
灵声智库的优势就是“纯离线”。一个 1U 的国产化服务器塞进机房，网线一插，所有的识别流都在局域网里跑。不仅延迟低（响应时间压到了 200ms 以内），最重要的是：不用给 HIS 厂家交那一笔天价的“过路费”。
最后的建议
如果你也是三甲医院的信息科运维，面对老旧 HIS 系统，我的建议是： 1. 先试虚拟键盘方案，成本几乎为零； 2. 如果医生反馈要自动分段，再谈数据库中间表； 3. 千万不要一上来就去走厂商的 WebService 流程，那往往是项目烂尾的开始。
相关专题： 医疗语音病历录入与私有化部署专题