急诊科大概是医院里最真实的信息系统考场。抢救室心电监护的滴滴声、分诊台前越排越长的队伍、120救护车刚推进来的担架车、走廊上加床的留观患者这些同时发生的动作最终都会落到同一套系统上。我今天想聊的就是这个方向——“智慧急诊系统源码建设”一个面向“十五五”规划周期的数字化新基建项目。它不是把门诊挂号系统改个名字搬过来也不是只上一个会叫号的排队大屏而是把急诊全流程预检分诊、抢救、留观、输液、转归、质控上报全部沉淀到一套可自主掌控的源码底座上。这篇文章会从需求逻辑、架构设计、核心模块实现到运维排查完整拆解一个智慧急诊系统源码工程到底该怎么建。适合医院信息科的工程师、医疗信息化厂商的研发同学以及准备接手此类系统的开发朋友参考。你可以把它当成设计复盘来看也可以当成开发清单来用。1. 需求解剖急诊流程为什么要单独建一套源码系统1.1 急诊业务的三个特殊性高并发、强时序、多角色先纠正一个常见误区很多人觉得急诊系统就是门诊系统的子集功能上少挂几个号、少开几个药方就行。真在医院蹲过急诊的人会告诉你急诊对信息系统的要求完全不亚于手术麻醉系统甚至更难。第一个词是高并发。晚高峰、节假日、突发群体伤半小时内涌入几百号患者是常态。普通门诊的排队模型是“一个患者对多个窗口”急诊是“多个患者对多个窗口但每个患者的紧急程度还不同”。分诊台、收费处、抢救室、检验科、药房、影像科所有节点都要同时感知同一个患者的流转状态。门诊系统可以按号叫急诊系统不能按号叫——按号叫的前提是每个人都一样紧急而急诊恰恰相反。第二个词是强时序。胸痛中心要求记录“进门到心电图”“进门到肌钙蛋白”“进门到球囊扩张”的节点卒中中心要求记录“进门到CT平扫”“进门到溶栓”的节点创伤中心要抓“黄金一小时”。这些时间戳是医疗质控的核心依据也是胸痛中心、卒中中心认证评审时的硬指标。节点不能靠护士事后补记系统必须在事件发生的瞬间以近乎无感的方式自动捕获时间同时允许人工确认关键节点。第三个词是多角色协同。分诊护士、急诊医生、抢救室护士、检验技师、影像技师、药师、收费员、护工、120随车医生这么多人同时在为一个患者服务。任何一个角色的信息滞后都会造成抢救路径的延误。比如120在转运途中已经测得的心电图和生命体征如果能提前送达急诊大屏院内医生就能提前启动预案如果靠手机拍照发微信群信息就断了。这三种特性叠加导致急诊系统在数据模型上必须同时支持“流程状态机”和“时间轴事件溯源”两种语义这是普通门诊HIS模块很难承载的。1.2 源码级建设到底解决了什么市面上成熟的急诊成品软件不少但我仍然建议有条件的医院选择源码级建设核心原因有三个。一是流程差异适配。每家医院的急诊流程差异大到惊人。有的医院分诊和挂号是两个环节分诊台独立于收费处有的医院先挂号后分诊有的医院胸痛中心走绿色通道先抢救后结算还有的医院设置了创伤复苏单元患者直接从120车进抢救室。成品软件改流程的成本极高常常只能做“反向适配”——用系统逻辑强行约束现实流程最后逼着临床改习惯。二是数据模型扩展性。急诊质控是持续进化的。今天要加一个脓毒症筛查评分明天要加一个脑卒中NIHSS评分后天可能要根据最新指南调整MEWS分诊阈值。代码里面写死逻辑很简单难的是在不重启、不停机的状态下热更新规则并且保证历史数据口径不破坏。源码在自己手里这种扩展能力才能实实在在握在手里。三是数据主权与安全合规。急诊数据涉及患者生命体征、时间节点、转运记录等敏感信息必须支持完整的审计追踪。谁在什么时间创建了节点、谁修改过评分、分诊等级为什么从II级调整为III级都要有不可抵赖的记录。源码级建设等于把数据模型的最终解释权握在自己手里出了纠纷能自查、能举证。当然源码建设不等于从零造轮子。数据库、缓存、消息队列、ORM框架这些基础设施直接用成熟开源组件源码级建设解决的是“业务模型和流程编排”这一层的自主可控。1.3 项目目标与建设边界做源码建设最怕需求无限扩大把急诊系统做成大而全的HIS。这个项目开始之前我们明确了几条边界。范围上覆盖从120院前信息接入急救车的患者基础信息、生命体征、心电图图片到院内预检分诊、急诊挂号、医生站、抢救室、留观、输液、转归、质控统计的完整链路。院前和院内之间用接口打通不另起炉灶。流程上以“一次急诊就诊”为主线建立统一的急诊就诊主索引。所有业务动作都挂在这个主索引下分诊评估、时间节点、医嘱、费用、床位、检验检查结果全部围绕主索引展开。口径上所有时间节点以服务端时间为准所有评分数据存储原始分项数据而非只存总分——这个后面会详细讲是踩坑踩出来的经验。建设节奏上按“分诊与排队 → 抢救与时间轴 → 留观与输液 → 统计质控”四期推进。一期先把患者生命通道跑通二期再考虑报表和质控避免一次性铺太大。2. 系统整体设计与架构拆解2.1 模块划分跟着抢救流程走我见过不少团队做功能拆解时按“用户角色”来划分模块比如护士工作站、医生工作站、收费工作站。这种划分方式在门诊没问题在急诊会割裂数据流。正确的做法是按患者的事件流走模块边界对应急诊业务流程的节点。核心模块一共分成七块模块核心功能关键数据院前急救对接120车辆信息、上车生命体征、院前心电图传输院前时间节点、生命体征序列预检分诊生命体征采集、MEWS评分、五级分诊、批量伤员分诊评估表、评分明细、分诊等级急诊登记挂号身份核验、绿色通道先救治后结算、医保身份信息急诊就诊主表、费用账户抢救室管理床位管理、抢救记录、时间轴节点、医嘱执行抢救床位表、时间轴节点表急诊医生站急诊病历、处方、检验检查申请、会诊急诊病历、医嘱留观输液留观床位、输液执行、巡回记录留观记录、输液单统计质控时间节点达标率、分诊符合率、七大中心指标质控报表、指标快照这套划分最直观的好处是每个模块的业务边界刚好对应急诊流程中的一个物理节点。分诊台上做分诊评估抢救室里点时间节点留观区管床位逻辑清晰接口边界也不容易乱。2.2 技术选型为什么这么组合技术选型上我推荐“模块化单体 关键扩展点微服务化”的渐进式架构而不是一上来就拆十几二十个微服务。理由很现实急诊系统对链路延迟敏感分诊、呼叫、节点记录都是低频但高实时性的操作单体应用以内网直连数据库的方式响应性能最稳定。而且大多数医院的运维团队撑不起微服务全家桶的运维成本。具体组合如下后端Spring Boot 3.x MyBatis/MyBatis-Plus缓存与队列Redis分布式锁、排队队列、规则缓存、RabbitMQ异步通知、事件解耦存储MySQL 8.x 或 PostgreSQL建议InnoDB、utf8mb4按时间轴归档历史数据前端Vue3 Element Plus大屏用 TypeScript ECharts集成HTTP REST WebService对接HIS/LIS/PACSHL7可选为什么要单独用Redis急诊排队模型和普通门诊区别很大。普通门诊队列只是“先进先出”急诊队列要按“分诊等级 到达时间 特殊标记”动态排序。用Redis的ZSET有序集合实现优先级队列score由分诊等级和到达时间戳联合计算既快又灵活。为什么要用RabbitMQ而不是直接用RPC同步调用因为检验结果回传、药房发药通知、短信提醒这类动作都不该阻塞主流程。比如LIS回传肌钙蛋白结果如果同步调用导致分诊台界面卡住两秒在急诊场景是不可接受的。用消息队列做削峰填谷主流程永远优先。2.3 源码工程结构与核心数据模型源码工程不推荐一上来就按业务模块拆目录然后各写各的。参考DDD的分层思想但不要搞得太重。实际可落地的结构如下emergency-triage/ ├── emergency-api/ # REST接口层只做参数校验和DTO转换 ├── emergency-domain/ # 领域模型实体、值对象、事件定义 ├── emergency-service/ # 业务服务层规则引擎、流程编排、事务管理 ├── emergency-infra/ # 基础设施层Redis、MQ、外部HIS/LIS/PACS适配 ├── emergency-job/ # 定时任务超时提醒、床位清核、报表生成 ├── emergency-web/ # 管理后台前端Vue3 Element Plus └── emergency-screen/ # 急诊大屏前端TS ECharts这种分层的好处是依赖方向单向向下api依赖serviceservice依赖domain和infradomain不依赖任何外部框架。换数据库、换消息队列业务层基本不动。核心数据模型是整套系统的地基我挑三张最重要的表说明。急诊就诊主表emergency_visit一个患者一次急诊就诊一条记录。包含visit_sn就诊流水号唯一索引、patient_id、arrival_time到院时间、tri_level分诊等级、bed_id当前床位、visit_status状态机分诊中/候诊/就诊中/抢救中/留观中/离院/收住院。这张表是整个系统的活地图。分诊评估表triage_assessment一次分诊一条记录只存原始采集数据。字段包含heart_rate、resp_rate、sbp、temperature、consciousness、spo2、chief_complaint以及total_score和tri_level。特别注意必须存每一项原始值不能只存总分。因为事后质控要复盘“这个分诊等级怎么评出来的”有原始数据才能回溯否则就是无源之水。时间轴节点表timeline_node一次就诊多条记录。包含visit_id、node_type节点类型编码、node_time服务端时间、operator操作人、source自动/手动/接口导入、payloadJSON扩展字段。这张表只追加、不修改、不删除这就是后面要讲的“时间不可篡改”设计。3. 核心模块源码实现与实操要点3.1 预检分诊规则引擎的落地实现预检分诊是整个急诊系统的入口规则引擎是分诊台的核心大脑。这里最容易犯的错是把规则写死在if-else里。过两个月指南更新要调阈值只能提版本、发版、重启急诊还等不了这就是事故。我的做法是规则配置化 运行时热刷新。分诊规则表triage_rule设计如下id : 规则唯一编码如 MEWS_HR_01 dimension : 维度如 HR心率/ RR呼吸/ SBP血压/ TEMP体温/ AVPU意识 condition : 匹配条件如 value 130 或 value 40 score : 命中后加分比如心率超过130加3分 critical : 是否触发紧急标志比如 spo2 90 直接标记为I级规则引擎核心实现我给一段简化但可直接参考的代码Component public class TriageRuleEngine { // 规则缓存volatile保证多线程可见性支持运行时刷新 private volatile ListTriageRule cache new ArrayList(); private final TriageRuleMapper ruleMapper; public TriageRuleEngine(TriageRuleMapper ruleMapper) { this.ruleMapper ruleMapper; loadRules(); } public void refresh() { loadRules(); } private void loadRules() { cache ruleMapper.selectAll(); } public TriageResult evaluate(PatientTriageModel model) { int totalScore 0; ListString hitRules new ArrayList(); Level level Level.IV; for (TriageRule rule : cache) { if (rule.match(model)) { totalScore rule.getScore(); hitRules.add(rule.getCode()); // 任意紧急规则命中直接提升为I级 if (rule.isCritical()) { return new TriageResult(Level.I, totalScore, hitRules); } } } // 阈值按院内指南配置此处为示例 if (totalScore 7) { level Level.I; } else if (totalScore 4) { level Level.II; } else if (totalScore 1) { level Level.III; } return new TriageResult(level, totalScore, hitRules); } }这里有两个关键设计决策。第一critical规则优先返回。比如血氧饱和度低于90、意识障碍、胸痛持续不缓解这些症状本身就有极高的危险信号不应该再等MEWS总分算完必须立刻升为I级。总分规则解决的是“整体状态越来越差”的渐变性风险critical规则解决的是“单点事件直接致命”的突变性风险两种要分开处理。第二阈值必须可配置且基于院内数据校准。MEWS评分原始阈值来自国外文献不同人群的基线差异很大。二级医院老年患者心率偏快心率110可能很常见三甲综合医院有大量危重患者涌入阈值太宽松会把抢救室堵死。我建议上线前拉取过去至少一年的急诊就诊数据用留一法回算不同阈值下的敏感度和异物率把阈值调到“漏掉一个危重患者”的风险可接受范围内。这个校准工作不要省是分诊台能不能被临床信任的关键。关于五级分诊另外说明一下。国家推荐标准是“一级濒危、二级危重、三级急症、四级非急症”有的地方加了五级“非急诊”。“非急诊”患者会被引导到门诊避免占用急诊通道。规则引擎里要留一个“转门诊建议”的判定分支这是很多系统容易忽略的细节。3.2 时间轴节点胸痛中心、卒中中心的抢救留痕时间轴是智慧急诊系统最“值钱”的功能模块。胸痛中心认证、卒中中心评审、创伤中心质控全部指标都建立在准确的时间节点上。我在实际项目里见过最痛的问题护士在抢救结束后半小时补录“溶栓开始时间”填写全凭记忆误差可能达到十几分钟。这种数据拿到质控会上根本站不住脚。时间轴节点要分成两类。自动节点系统通过接口或设备自动捕获。比如患者到达急诊大门通过腕带扫码触发、心电图完成心电图机接口回传、检验样本合格LIS回传、CT扫描开始RISPACS回传。自动节点的优势是客观不以人的意志为转移适合做质控基准。手动节点由医护人员在关键动作发生瞬间点击确认。比如“溶栓开始”“导管室启动”“紧急气管插管”。手动节点需要设计成操作简单到极致抢救室大屏上放一个常驻的“节点记录”悬浮按钮护士点击后选择节点类型系统立即记录时间不允许也不应该要求护士再输入任何说明文字。核心实现代码如下几个设计细节值得注意Transactional public TimelineNode append(TimelineAppendCmd cmd) { TimelineNode node new TimelineNode(); node.setVisitId(cmd.getVisitId()); node.setNodeType(cmd.getNodeType()); // 只使用服务端时间不使用客户端时间防止各设备时钟偏差 node.setNodeTime(serverTimeProvider.now()); node.setOperator(currentUserId()); node.setSource(cmd.getSource()); // AUTO / MANUAL / IMPORT node.setPayload(JSON.toJSONString(cmd.getPayload())); // 只追加不修改不删除 timelineNodeMapper.insert(node); return node; }第一时间以服务端为准。医院各电脑的系统时钟通常差个几十秒如果用客户端时间戳不同医生站的记录就可能出现“后发生的节点时间早于先发生的节点”这类逻辑错误。所有节点时间的生成必须由服务端完成客户端只传事件类型、不传时间。第二只追加、不修改、不删除。质控审查要求时间节点具备不可篡改属性。如果护士录错节点比如把“溶栓开始”误点成“溶栓结束”系统只能新增一条“更正记录”并把原记录标记为“已更正”而不是直接改原值。这样既能保证数据的原始性又允许业务纠错。第三payload存JSON扩展字段。不同节点的附带信息差异很大心电图节点要带心电图报告编号溶栓节点要带药物名称和剂量转ICU节点要带ICU科室编码。设计一个payload字段统一承接避免每加一个新节点类型就要加表字段。历史数据保留原样即使新格式变化也不回溯修改这是事件溯源的基本思路。3.3 候诊队列、过号处理与床位占用的状态机急诊候诊队列不是简单队列它要解决三个门诊系统不会遇到的问题动态优先级、反复呼叫、床位虚实映射。队列模型我用Redis的ZSET实现。score计算规则是score 分级权重 到达时间戳的取倒数折算简单说就是“I级权重最高同一级别内先到先得”。但注意不是直接拿时间戳当score而是用一个二进制位组合高几位放优先级低几位放时间。这样排序时先按优先级、再按时间一次ZREVRANGE就能拿到下一个该被呼叫的患者。过号处理要设计成状态机否则很容易出现“人叫了三遍没来叫下一个下一个看完之前那个又回来了”的混乱。我的状态转义设计如下CREATED已取号→ CALLED呼叫中→ VISITING就诊中→ FINISHED完成 CALLED呼叫中→ OVERDUE过号→ CALLED二次呼叫 CREATED已取号→ CANCELLED取消过号处理有几个关键参数要可配置单次呼叫响铃次数比如3次广播、等待时长比如5分钟、过号后可重新呼叫的次数比如1次。过号患者二次呼叫时要插入到当前排队队列的队首位置但插入位置不能早于当前正在呼叫的患者。这个细节如果不处理就会出现“过号患者插队把正在就诊的人挤掉”的纠纷。床位占用是另一个容易踩坑的点。抢救室的床位状态不是简单的“空闲/占用”二态而是包含“实体床位”和“临时床位”两个池子。实体床位指物理上存在的固定抢救床临时床位指走廊加床、观察区临时床。系统里必须把两种床位分开管理否则会出现“床位满了但实际还有几个加床空位”的报表失真。床位状态建议用四个状态空闲、占用中、消毒中、停用。患者离开床位时必须通过明确的流程节点转科、收住院、离院触发释放不允许直接改床位状态。我后面在运维部分会讲不这样设计就会出现“空床但系统占用”的老大难问题。3.4 与HIS、LIS、PACS的接口协同与容错智慧急诊系统不可能独立存在它一定与院内HIS挂号收费、LIS检验、PACS影像、EMR电子病历互联。集成这块做得不好系统再漂亮也跑不起来。核心原则是主流程不能挂在外部接口上。我先说主索引。每个患者必须先在院内统一患者主索引EMPI中建档急诊系统用全局唯一patient_id关联。不能按身份证号强行匹配因为急诊经常来无主患者、三无人员要以腕带号为准建立临时主索引后续再合并。然后说接口调用的分级处理挂号收费患者到院时先查HIS是否已有档案。如果没有走防重机制本地建档延后补挂号单。不能让分诊台等HIS响应超时。检验检查申请医生站开单后同步写入HIS并获取检查申请号LIS回传结果用MQ异步推送本地消息表保证最终一致。影像报告PACS回传报告通知异步处理大屏轮询本地缓存不要实时调PACS接口。每个外部接口都要做三层防护第一层是超时。统一设置HTTP连接超时和读超时比如连接3秒、读取10秒超时立即降级。第二层是熔断。用一个简单的计数器实现1分钟内某个外部接口失败超过10次直接熔断该接口5分钟期间返回降级结果不再继续打已经不可用的下游。第三层是幂等。所有外部系统回调必须带唯一消息ID比如HIS推送挂号结果带visit_sn retry_id本地表加唯一索引重复回调直接忽略防止网络重试导致重复处理。4. 高频问题排查与部署避坑清单4.1 并发冲突类问题实录分诊和挂号同时发生时最容易出现重复建档、重复取号、分诊等级丢失等问题。我用一张问题速查表梳理一下实际运维中遇到的场景。问题现象根因解决方案同一患者出现两条就诊流水号分诊台和收费窗口并发建档数据库对visit_sn加唯一索引程序捕获DuplicateKeyException后回查已有记录两个护士同时给同一患者提交分诊等级不一致缺少分诊中状态的互斥锁Redis分布式锁锁的key用patient_id visit_sn提交完成后释放患者已进入候诊队列又被重复呼叫大屏刷新和排队服务并发读取队列呼叫动作用Redis原子操作执行完立即更新队列状态不允许重复CALLED批量伤员模式下分诊漏人批量录入时没有和登记台同步批量分诊必须走“生成临时就诊记录”流程先建档后评分防止只有分诊记录没有就诊记录排查这类问题有一个通用思路先查数据表里的唯一约束和状态字段再查Redis里有没有对应的锁或队列残留。急诊系统上线初期每天定时跑一个“数据一致性巡检任务”很管用把“有分诊记录但没有就诊记录”“有就诊记录但没有分诊记录”“床位上标记占用但患者状态已离院”这几类脏数据全部扫出来。4.2 集成与数据类问题实录HIS系统做升级、LIS接口不稳定、PACS突然变慢都是常态。我在实际项目中总结的经验是把集成依赖当成“可能会断的网线”来设计而不是当成“永远稳定的水管”。问题现象根因解决方案HIS升级导致挂号接口超时分诊台排队积压外部系统不可用没有降级策略接口熔断降级先本地建档患者先走抢救流程HIS恢复后自动补录LIS回传检验报告延迟大屏不刷新同步调用PACS/LIS接口等待时间过长改为MQ异步回调本地消息表记录事件ID前端轮询本地缓存图像报告已出但大屏无提示PACS报告回调未成功定时任务补偿每5分钟扫一次“已申请但未回传”的检查任务重新拉取报告状态胸痛中心时间轴缺“首份心电图”节点心电图机接口未接入或接入失败设计手动节点兜底但自动节点缺失要在大屏上醒目标记提醒护士人工确认稳定性有一个细节很重要消息队列不能变成消息黑洞。本地消息表要带“发送状态”字段pending / sent / failed定时任务把超过1分钟仍未成功的消息重新投递。同时配置死信队列同一消息重试超过5次进入人工处理通道。否则一旦MQ积压整个系统的接口都会慢慢卡死。4.3 流程口径与运维复盘最后讲三个容易被忽略但影响日常使用的细节。第一个是过号规则的口径。呼叫响铃次数、过号判定时长、二次呼叫次数这三个参数每个医院都要按实际人流调整。大型三甲医院晚高峰过号现象少因为排队人多患者不敢走远二级医院候诊区小患者经常在门口站着呼叫三次不来就要及时过号。参数要支持界面上直接调整不要改代码。第二个是数据报表的口径统一。急诊质控报表里“到院时间”到底是用预检分诊时间还是挂号时间胸痛中心要求的“first medical contact”到底是哪个节点如果不统一口径胸痛中心评审时自己都解释不清。我建议在时间轴节点表里增加一个“标准事件”映射把业务节点映射到质控标准事件报表只读映射后的标准事件不直接读原始节点。第三个是压测不要只在测试环境做。急诊系统最大的流量冲击不是高并发的接口调用而是“大屏轮询 队列刷新 时间轴写入”同时发生时数据库的连接池耗尽。上线前一定要在准生产环境用真实数据量做压测重点看连接池参数、Redis连接数、慢查询阈值。我见过一个系统在模拟50人同时分诊时数据库连接池被打满整个分诊台全部白屏——这种事故在急诊现场是绝对不能接受的。我个人在实际操作中最深的体会是智慧急诊系统的建设难点不在写代码而在理解急诊科每一个动作背后的时间敏感性和责任边界。ICU里的每一个节点、每一次分诊调整将来都可能被翻出来做医疗质量复盘。所以这套系统的设计核心永远是“可解释、可追溯、不可抵赖”——规则要能解释数据要能追溯流程要不可抵赖。最后再分享一个小技巧也是踩过几次坑之后养成的习惯分诊规则引擎的阈值千万不能拍脑袋定上线前一定要用本院过去一年的历史数据回跑一遍把“被系统评为III级、但最终进了抢救室”的患者比例调到一个你能接受的水平。这个比例决定了分诊台敢不敢信任这套系统。数据回跑这个动作比写一万行代码都值钱。