企业官网建设流程全解析

最近被好几个医院信息科的朋友问了同一个问题：AI网关这东西，到底适不适合医疗行业？问的人多了，我觉得这个问题值得认真写一篇。他们不是保守，恰恰相反，手上已经捏着两三个大模型的测试账号，放射科那边更是天天催着上AI辅助诊断，门诊也想搞智能预问诊。可一提到要打通HIS系统、要从电子病历里取数据、要出审计日志，所有AI项目就像被按了暂停键——全部卡在原地。这个场景我太熟了。问题从来不在模型能力，而在"怎么把模型安全地接进医院真实的业务流"。

MAI Gateway这类场景化AI网关方案，就是冲着这个来的。它跟市面上那些通用API网关不是一回事，它更像一层为医疗业务定制的"翻译层+安全闸门"，专门解决大模型和医院存量系统之间"语言不通、权限不清、责任不明"的问题。这篇我打算从医院信息化现状、MAI Gateway的设计思路、几个具体落地场景、合规红线、以及我实际部署中踩过的坑这几个角度，把AI网关在医疗行业的应用彻底讲透。不管你是医院信息科、HIS厂商、做医疗AI的研发，还是想评估技术方案的产品经理，应该都能从里面找到有用的东西。

1. 医院里那堆跑了几十年的老系统，才是AI落地的真正阻力

1.1 大模型作文写得好，可它进不了门诊系统

你随便找个三甲医院的信息科看一眼就会理解我的意思：诊室里医生用的门诊工作站，很多还是C/S架构的老系统，客户端装在Windows机器上，后台连着Oracle或者SQL Server数据库，接口文档大部分是自定义的WebService，有的甚至还在走SQL直连。HIS、LIS、RIS、EMR、PACS，每个系统的厂商不同、开发年代不同、数据标准不同，说它们是"电子病历的孤岛"都算客气了。

而大模型这边是什么生态？标准的HTTPS接口、JSON格式、Token鉴权、Docker部署，模型推理跑在GPU服务器上。一个是最传统的企业级IT架构，一个是最现代的云原生/大模型架构。两边技术栈的差异，大到仿佛是两个时代的产物。让门诊系统直接调模型API，且不说信息安全科会不会签字，光是网络连通性和数据格式转换就能让开发人员崩溃。

1.2 AI网关到底管哪一段

打个比方，医院信息系统好比一栋几十年的老楼，每个房间都有自己的锁和门牌号。大模型是一个个新来的供应商，想进楼里办事，但它们不认识门牌号，也不合规地带着各种敏感数据到处跑。AI网关就是这栋楼的"统一前台+保安+翻译"。所有AI调用先到前台登记，保安检查权限，翻译把老系统的数据和模型需要的数据格式做转换，最后才放行。

具体落到技术层面，AI网关管的是这一段：医院内部业务系统想使用AI能力时，调用方不再直接面对大模型的API地址、Key、Prompt格式，而是统一请求网关。网关负责四件事：一是鉴权，确认调用方是合法的医生工作站、护士站或就诊小程序；二是路由，根据业务场景把请求转发给合适的模型，可能是本地小模型，也可能是云端大模型；三是转换，将HL7、FHIR或医院自定义的数据格式翻译成模型能理解的输入；四是审计，把每一次调用记录下来，谁调的、调了什么模型、传了哪些数据字段、返回了什么结果，全部留痕。

1.3 为什么必须是"网关"，不能是"直连"

有人可能会说，既然要对接，让HIS厂商开发一个接口直连大模型不就完了，何必多一层网关？这个想法我一开始也觉得有道理，直到我亲眼见过直连方案是怎么失控的。直连意味着每一套业务系统都要单独维护对接逻辑，每家模型厂商的鉴权方式、API版本、限流策略全都要硬编码在业务代码里。业务系统一升级，AI联调就瘫痪；模型那边一换版本，医院还得跟着改代码。

网关的价值在于把这种"多对多"的复杂关系收敛成"多对一"和"一对多"。所有业务系统只对接网关，所有模型也只用对接网关，中间的任何变更都在网关这个层面上消化。对医院这种IT力量薄弱、又极其在乎系统稳定性的机构来说，这是唯一现实的做法。这就像家里的路由器，你不会让每台设备直接跟运营商的光猫单独协商配置，而是统一走路由器转达。

2. MAI Gateway的场景化切法：不是通用网关，是医生工作流的翻译层

2.1 场景化，意思是不让你改业务系统

MAI Gateway和我以前折腾过的Kong、APISIX这类通用API网关有个最大的不同：它不按API资源来组织能力，而是按"临床场景"来组织能力。什么叫按场景？比如"智能预问诊"是一个场景，"门诊病历结构化"是另一个场景，"出院随访"又是一个场景。

每个场景背后可能涉及多个模型协作，涉及HIS、EMR、随访系统等多个系统的数据，涉及门诊工作站、患者小程序等不同入口。通用网关让你管理的是一个个接口，而MAI Gateway让你管理的是一个个业务流程。这个差别在医疗场景里极其关键，因为医院信息科真正关心的是"这个场景能不能跑通"，而不是"这个API通不通"。如果按API粒度去配置，医生工作站调完预问诊接口还要自己拼病历数据，科室还得自己写胶水代码，那就又回到系统集成的老路上了。

2.2 几个和通用API网关完全不一样的设计

我梳理了一下MAI Gateway里面几个比较关键的设计点，可以说每一条都是冲着医疗场景去的。

第一个是场景路由配置。它不是简单的"路径转发到某个上游服务"，而是需要支持"一个场景请求进来后，网关先向HIS取患者基本信息，再调用结构化模型，然后判断结果置信度，最后把结果分流到医生审核队列"。这已经不是网关，而是一个轻量级的业务编排引擎了。我在实际用的时候，发现这个编排能力最救命的场景是：门诊高峰期模型服务变慢，网关可以把非紧急的文本生成请求自动降级到备用模型，医生端完全无感。

第二个是院内系统适配器。MAI Gateway带有针对HIS、EMR、LIS、随访系统的连接器，能直接读取常见数据库的表结构，也能解析HL7消息。这个适配器帮我省了至少两周的开发量。医院的老系统接口往往文档不全，有了现成适配器，至少有个能快速二次开发的底子。当然，每家医院都有定制化字段，适配器不是插上就能跑，但起点比从零开始写强太多。

第三个是医学语义处理层。它会做医学术语的标准化，把患者输入的"我胃疼、反酸、吃不下饭"转成结构化的主诉描述，再喂给大模型。还会做数据脱敏，把病案号、身份证号、手机号在出域前动态打码。这两个能力在通用网关上你是找不到的，属于典型的行业Know-how。

2.3 和通用API网关的对比

为了说清楚它跟通用网关的差异，我列了个对比表，看完应该就明白为什么医疗场景不能直接拿通用产品硬改。

说到底，通用API网关解决的是"服务怎么管理"的问题，MAI Gateway解决的是"医疗业务怎么跟AI对接"的问题。后者多出来的那一层，恰恰是医疗AI落地最费劲的部分。

3. 四个具体落地场景：从导诊台到随访中心

3.1 场景一：智能预问诊，患者排队时就开始采集主诉

最典型的场景是患者挂号之后、进诊室之前，在手机上通过医院的微信公众号或小程序完成AI预问诊。患者在候诊的时候输入自己的症状，AI像一位有经验的护士一样追问：持续时间、疼痛性质、有没有伴随发热、有没有药物过敏史。等患者进诊室时，一份结构化主诉摘要已经躺在医生的接诊界面里了。

这个场景里MAI Gateway做的事非常多。第一步，患者身份识别，网关从统一支付平台或挂号系统拿到患者标识，并拉取挂号科室信息。第二步，数据最小化，网关只允许模型访问跟本次问诊相关的字段，比如主诉文本、年龄、性别，不允许访问历史病历和检验结果（除非患者在特定授权流程中明确放开）。第三步，风险拦截，如果患者输入的内容里出现胸痛伴大汗、意识障碍这类高危信号，网关直接放弃常规追问，转入危急值提示流程，不依赖模型自行判断。第四步，结果回写，把AI生成的结构化主诉转换为EMR系统能够导入的数据格式，再推送到医生工作站。没有网关，这个流程里任何一步的接口对接和数据管控都会让项目失去控制。

3.2 场景二：门诊病历结构化，把老C/S系统带进AI时代

很多医院的门诊病历还停留在医生手打大段文字的阶段，医生一天看几百个号，没时间结构化填写。AI辅助的好处显而易见：医生口述或粘贴主诉，模型自动生成规范病历草稿，医生确认、修改、签名。

但在实际集成时有个麻烦——门诊医生工作站的客户端是老的C/S程序，不能随便内嵌SDK。我们的做法是让医生工作站通过一个本地网页微服务调用MAI Gateway，网关再去调模型，生成结果返回网页端，医生点击"一键填入"之后由客户端脚本写入病历系统。这算是网关提供的"间接集成"路径。这个过程中，网关还要绑定医生的工号和工位，把调用行为记到具体人头。因为在医疗场景里，病历是法律文书，谁的电脑、哪个工号、何时生成、模型给出了什么建议，全部要有据可查，否则医务科根本不敢批准这个功能上线。

3.3 场景三：影像报告辅助筛查，只给模型"够用"的数据

影像AI这几年已经很成熟，但医院对它的态度最谨慎。PACS系统里躺着海量的CT、MRI数据，是患者隐私最集中的地方。接入影像AI时，MAI Gateway被要求做成"定向取数"模式：当放射科医生在阅片工作站点开某个检查序列时，网关只允许AI服务通过专用接口获取当前检查ID对应的影像元数据和必要的序列文件，绝对不允许模型直接扫描整个影像库。

这样设计的好处是，即使模型服务被攻击或者内部越权，攻击面也被限制在单次检查的数据范围内，远小于一次数据库拖库的损失。AI的初步标注结果会以图层叠加方式显示在阅片工作站上，标注的记录同样走网关落审计。别小看这个"单次取数"的设计，PACS厂商往往最抵触的就是开放数据库接口，而网关能够把这层敏感交互和业务解耦，让PACS那边只需要提供一个受控的查询视图，谈判难度瞬间降一个档次。

3.4 场景四：出院随访，批量外呼背后的字段级权限控制

随访场景看着简单，其实最容易出事。传统随访是护士打电话，现在想用AI外呼来做慢病患者的出院随访，向几百上千个患者打电话询问恢复情况、提醒复查时间。一旦让AI批量接触患者，敏感数据暴露风险和合规风险呈指数上升。

MAI Gateway在这个场景里做的事是"字段级权限白名单"。随访任务触发时，网关只向外呼模型提供三类信息：患者的称呼（脱敏后的姓氏或尊称）、随访模板编号、该患者的随访计划时间。除此之外，模型拿不到诊断结论、拿不到历次入院记录、拿不到检查报告。同时，外呼内容和患者的语音反馈全部回传网关存档，满足医疗纠纷倒查的举证要求。这个场景如果不用网关，要么得让模型服务商直接对接患者数据库（信息科绝对不批），要么每次随访都靠人工处理（成本上不划算），基本无解。

4. 医疗数据合规：网关必须硬扛的几条线

4.1 最小数据暴露，模型不需要的一律不出域

医疗数据合规这件事，不是一句"做好加密"就能糊弄过去的。加密只解决传输安全问题，解决不了"模型有没有必要看到这份数据"的问题。MAI Gateway在整个链路里强制实施最小数据暴露原则。

举个例子，做预问诊时，模型需要知道患者主诉、年龄、过敏史，但不需要知道患者的住址、配偶信息、医保结算明细。网关在数据出域前做字段级过滤，把不需要的字段直接剥离。这个过滤必须在网关层做，不能依赖模型服务商自觉。因为模型服务商往往希望拿到更多数据来优化效果，而医院方的立场是能不出去就不出去。两层立场天然对立，所以必须由医院可控的网关来做这个闸口。

4.2 权限映射与全链路审计

网关的鉴权不能像互联网应用那样只认Token。在医院里，Token背后必须对应到一个真实的人或一个受控的系统进程。MAI Gateway的做法是建立"人员身份到AI调用身份"的映射：医生工号、科室编码、操作终端、业务类型，组成一个多元组，每次AI调用都带上这个多元组作为审计维度。

医生说"我昨天调用了三次模型生成病历建议"，这句话放在没有网关的时代是无法核实的，但有了全链路审计，信息科可以直接调出三次调用的时间戳、输入数据摘要、模型输出版本、返回内容，以及医生最终是否修改了内部字段。这种透明性在医疗纠纷处理和医务科审查时是硬通货，也是AI项目能过医院伦理委员会评审的必要条件。

4.3 私有化部署与日志留存

云端SaaS模式的大模型再强，很多医院也不会同意把患者主诉文本实时传给第三方训练。所以MAI Gateway的部署形态必须是可私有化的：整个网关可以装在一台2U的服务器上，放在医院的DMZ区或者内网服务器区，模型调用链路全程在医院网络内闭环。外部模型如果确实需要被调用，只能通过网关单向代理访问，且传输内容必须经过脱敏。

另外，日志留存时间这类细节也要盯紧。医院信息安全等级保护要求里对日志留存时间有明确规定的，网关默认要支持半年以上的审计日志归档。很多通用产品默认只留7天、30天日志，拿到医院来根本不符合要求。这个点别说新手，连一些老手都会在采购阶段忽略，等安全测评机构进场时才发现，那就要返工了。

5. 部署实施中的五个坑，每一个都是真金白银换来的

5.1 接口适配永远比预估的复杂

刚接触MAI Gateway的适配器时，我一度以为接一个HIS系统很快。实际上，医院的HIS系统往往经过了十几年、几个厂商的多次改造，同一家医院不同院区的HIS版本都可能不一致。有的表结构根本没有官方文档，字段含义全靠信息科老人凭记忆解释。一个"取号源"的接口，不同院区的参数命名都不一样，这种活只能靠挨个梳理、逐个联调。

我的建议是：实施前先让信息科牵头做一次存量接口盘点，明确哪些系统必须接入、哪些可以先绕过。不要把适配工作寄托在"产品开箱即用"上，而要把适配器当成一个半成品，预留足够的开发工时去填医院特有的坑。否则项目一定会卡在设计阶段，迟迟上不了线。

5.2 网关部署在哪个区，直接决定安全审查过不过

医院网络普遍做了严格的分区：内网区、DMZ区、外网区，区域间有防火墙策略，甚至还有单向网闸。AI网关到底放哪个区，不是技术选型问题，是能不能过信息安全科评审的问题。

我的实际操作体会是：优先把网关放在医院内网核心或DMZ内侧重业务侧的区域。让业务系统访问网关走内网，网关访问模型服务走内网或专线，严禁从外网直接暴露网关管理端口。这样部署虽然让运维稍微麻烦点，但安全评估时省去大量解释工作。如果你图省事把网关注册中心直接暴露在公网，信息安全科那关就可能通不过，更别说后面的等级保护测评。

5.3 门诊高峰的并发比你想象中猛得多

医院业务有明显的潮汐效应，上午九点到十一点是门诊高峰，预问诊请求量可能是平峰时段的十倍以上。网关默认的线程池和连接池配置根本扛不住，如果不提前压测，关键时刻网关直接被击穿，连累的不仅是AI功能，还可能导致门诊系统的接口调用变慢。

我们在上线前做了一次模拟压测，模拟同时三千个患者发起预问诊请求，发现了两个问题：一是网关的日志写入造成IO瓶颈，二是排队策略导致低优先级请求和紧急请求混在一起互相堵塞。后来做了异步日志、分级队列，把危重症识别请求设为最高优先级，才把峰值响应时间压下来。这类调优必须结合医院真实数据做，不能照抄通用网关的默认值。

5.4 模型升级不能用"重启大法"

大模型的迭代速度和医院信息系统的稳字当头，天然是矛盾的。之前我们遇到一次模型服务方版本更新，结果医生反馈生成病历的格式和原来不一样了，部分字段填不进去。排查下来发现是模型输出格式微调，配合固化的前端解析逻辑出了错。

从那以后，我坚持在网关把模型服务按版本管理。同一个场景可以绑定多个模型版本，网关配置灰度权重，先让5%的流量走新版本，观察医生端反馈和无损率指标，再逐步放量。一旦出问题，一键把流量切回旧版本。这套机制通用API网关上都有，但在医疗场景里尤其要重视，因为医生的工作习惯一旦被改变，再改回来是要付出额外信任成本的。

5.5 严格说不是技术坑，但比其他坑更致命

这一条不算技术问题，但我必须提，因为几十个项目下来，它最影响成败——医院内部的多部门协调。AI项目名义上是信息科牵头，实际牵涉临床科室的业务规范、医务科的合规审查、信息安全科的边界审批、数据管理部门的授权，甚至还要过伦理审查。每个部门关心的问题都不一样，临床抱怨不好用，医务科担心出问题谁负责，信息科怕背锅。如果没人把这些诉求翻译成技术方案，项目再硬的技术也推不动。

MAI Gateway的好处是，它天然把权限、审计、脱敏、数据边界这些医务科和信息科关心的问题显式化了，相当于把"责任划分"这件事变得可操作——系统里每一笔调用都能看到谁在用、用在哪、传了什么数据。这让所有审批部门的顾虑都有了制度出口。所以我的经验是，上AI网关之前，先组织一次医务科、信息科、临床、安全部门的联合需求评审，把场景范围内的责任边界讲清楚，这比任何技术文档都管用。

6. 最后说点个人建议：从小场景开始，别想一口吃成胖子

我从头到尾一直在说技术，但说到最后，真正想送给准备上MAI Gateway的医院或厂商同行的一句话是：千万别想一步到位。见过太多项目，第一个版本就想把预问诊、病历生成、影像筛查、随访全场景一次性上线，结果折腾半年，一个场景都没跑利索。

我建议第一台AI网关只接一个场景、一个模型、一个科室，比如先在内分泌科做随访外呼，或者只在心内科做预问诊。这个阶段的核心目标不是"展示AI多强大"，而是把三件事跑顺：数据脱敏规则是否准确、审计链路是否完整、医生端的交互是否符合习惯。等这个最小闭环稳定运行两三周，拿到真实的反馈数据，再考虑往下一个场景扩。这种节奏虽然看起来慢，但医院系统经不起大折腾，稳定压倒一切。网关的架构好处在于，后面的场景扩展只需要新增配置和适配器，前面的基础能力可以复用，越到后面越轻松。

根据我个人的实操体会，AI网关在医疗行业的价值，不在于把多少个大模型接进来，而在于让医院能够在"可控、合规、可解释"的前提下，开始真正使用AI能力。它未必每时每刻都是主角，但少了它，医疗AI的大规模落地就是一句空话。