简介这是一份面向日常医院管理的Web应用系统源码基于JavaScript技术栈构建适合需要快速上手全栈业务流程的开发者也可作为医疗信息化课程设计的参考项目。系统按角色拆分为患者、医生、管理三大模块患者可在线登录、预约挂号并查看历史记录医生能维护患者档案、开具数字处方、回复预约管理员则统览全部患者、医生、预约及反馈数据并支持医生信息的增删。压缩包共含2000个文件以JS业务逻辑、CSS/SCSS样式、TS类型定义及SVG图标为主另附带PHP接口与SQL数据库脚本整体大小约50.49MB目录结构便于定位与二次开发。当前已有152人学习浏览项目完整呈现了典型医院管理系统的角色权限分配、预约流程与数据管理思路配合AdminLTE风格的前端布局能帮助读者快速理解模块化开发与后台管理系统的设计要点。 两年前接手hospital-management-esystem这个项目时团队里一位老同事跟我说了一句话医院管理系统最重要的不是功能多齐全而是流程不能被绕过。当时我没太理解直到系统上线后有医生为了少点几下按钮宁愿走线下纸质流程才明白这句话的分量。这篇记录的是一套用于日常医院管理的系统从需求拆解、模块划分、数据模型到上线实施一路上真正决定成败的关键节点。如果你是做医疗信息化或者正在规划一个多角色、强流程的后台管理系统这些经验应该能帮你少踩几个坑。1. 医院日常管理系统到底在管理什么1.1 “日常”二字背后的业务范围很多非医疗行业的朋友一听到医院管理系统就以为是某种“医疗ERP”上来就聊采购、库存、进销存。实际上日常医院管理的核心是两条相互咬合的链条诊疗服务链和费用结算链。门诊再简单也要经历建卡、挂号、候诊、医生看诊、开检查或处方、缴费、执行检查、取药、离院住院则多了一条以天为单位的在院时间轴长期医嘱、临时医嘱、护士执行、床位费按天产生出院时还要统一结算。hospital-management-esystem 里的“日常”指的就是这些每天都在发生的动作而不是一个月才跑一次的财务报表。系统需要把这些动作变成线上数据让医生、护士、收费员、药房、管理人员都在同一套信息下协作。1.2 它和普通后台系统的本质区别我在做需求调研时最开始按常规后台系统的思路去设计后来发现完全行不通。医院管理系统和普通业务系统有三个本质差异连续性门诊从早上八点开始系统一旦不可用就是事故没有“晚上维护窗口”这种说法。一致性诊疗行为和费用必须一一对应。漏收费、错收费每天对账都会变成灾难甚至引发医疗纠纷。可追溯性一个操作可能在几个月甚至几年后被拿出来审计所以关键动作的“谁、何时、做了什么、改了哪个字段”必须留下完整痕迹。这三个差异决定了后面所有设计方向。如果你只是把它当成一个“多角色增删改查”系统来做大概率会在联调和上线阶段被反复打回。2. 从角色和流程入手再谈系统模块2.1 六类核心角色每类角色都有一套视图医院系统的用户不是“用户”而是带着明确任务的角色。我梳理下来至少有六类角色每天都在跟系统打交道角色核心目标典型操作系统关注点导诊/挂号人员快速建档挂号建卡、挂号、退号操作速度、号源状态医生高效看诊写病历、开医嘱、开检查结构化录入、历史病历护士/执行科室按医嘱执行执行单、标本交接执行提醒、漏执行药房/收费人员发药和收款审方、发药、收费、退费库存、费用、状态校验管理人员掌握运营情况查排队、查工作量、对账统计报表、异常追踪系统管理员维护系统配用户、配字典、配权限权限、日志、监控每个角色都应当有独立的工作台而不是所有人看同一张表。后来团队复盘时一致认为这是系统“好用”的第一个分水岭。2.2 用一次普通门诊拆解模块联动在动手写代码之前我用一次普通门诊流程把模块间的关系理了一遍这个动作帮了大忙患者到院建档系统创建患者主索引。挂号系统占用当天号源创建一条就诊记录状态变成“已挂号”。分诊/候诊医生工作台自动刷新出待诊队列。医生看诊书写病历录入诊断。医生开检查、开药系统生成医嘱/申请单同时生成待缴费的费用流水。患者缴费费用状态从“待缴”变成“已缴”。检查科室或药房执行校验缴费状态后扣减库存、回填结果。患者回诊或离院就诊状态变成“已完成”。一次简单的“看个病”贯穿了至少五个模块任何环节状态不一致都会导致秩序混乱。比如药房在患者还没缴费时就发了药后面一旦退费账就不好处理。2.3 住院流程多出来的一条时间轴门诊是一个离散的诊疗事件住院更像一条连续的时间轴。患者入院后长期医嘱每天按频次产生执行计划临时医嘱由医生随时下达护士需要把医嘱拆分出今天的执行单执行后记录时间、结果床位费和护理费按天或按次自动计费。到了出院结算系统要汇总所有已执行医嘱、项目费用、医保分摊、预交金算出一笔最终账单。如果状态机和费用流水设计得不好这一层会变得非常痛苦。我在住院模块上花的时间比门诊多了一倍。3. 最值得深入做的几个数据模型决策3.1 患者主索引和就诊记录必须分离一开始有同事提议把患者和就诊信息放在一张表里省事。我没有同意因为一旦同一患者第二次来院就会产生重复档案后续查历史病历、统计复诊率都会乱套。我采用的是patient加visit两层结构patient存基础档案姓名、证件号、性别、出生日期、联系电话。visit存单次就诊患者ID、就诊号、就诊类型、科室、接诊医生、状态、时间。一次就诊天然是一个独立生命周期患者与就诊是 1 对 N 的关系。把主索引抽出来也为以后做重复患者合并留下余地。所有核心查询都从visit出发visit.patient_id必须建索引。3.2 用状态机约束就诊和医嘱很多系统“能用但乱”是因为状态字段靠开发人员自觉维护没有强约束。我看到的状态值五花八门前后端各写一套最后统计口径都对不上。在 hospital-management-esystem 里我把核心实体全部配了状态机。例如就诊状态VISIT_STATUS { registered: {label: 已挂号, next: [waiting, canceled]}, waiting: {label: 候诊中, next: [consulting, canceled]}, consulting: {label: 看诊中, next: [ordered, completed, canceled]}, ordered: {label: 已开具医嘱, next: [paid, canceled]}, paid: {label: 已缴费, next: [completed, refunding]}, refunding: {label: 退费中, next: [completed]}, completed: {label: 已完成, next: []}, canceled: {label: 已取消, next: []}, }这样状态流转有边界业务代码里少了一堆散落的if判断。退费也必须走明确状态不能从“已缴费”直接跳到“已退费”而没有任何中间记录。3.3 费用流水与账单分离医院费用充满逆向操作。患者缴费后可能因为退药、退检查、医保拒付发生部分退费收费项目还有医保覆盖比例和自费比例。所以账面上最好不要直接保存一个“账单总额”而是保存fee_flow费用流水每一笔正数表示应收负数表示冲销账单总额通过按就诊汇总流水实时算出。这样设计有两个直接好处任何一笔调整都有据可查财务对账时能逐笔核对而不是核对一个被覆盖掉的总额。团队起初担心“实时汇总会不会慢”实际上按visit_id加索引后性能开销完全可以接受。3.4 医嘱和执行记录必须分开医生开出的order是“计划”护士执行后的order_execution是“事实”。两者如果不分离会导致退费判断困难、护理绩效考核失真。以发药为例药房发药后写一条执行记录退费时先查询是否已发药如果已发就必须先退药再退费。这个约束看似简单但在表结构没有拆分的情况下很容易出现费用退了、药却已经给患者的纠纷。类似的还有检查申请单和执行结果也应该分开。4. 权限与审计医院场景下不能妥协的两条线4.1 功能权限 数据范围双维度控制医院系统的权限不只是“谁能登录哪个菜单”。更大的风险是数据范围一个住院医师能不能看全院患者一个护士能不能修改医生医嘱如果控制不住合规审查就是大问题。我在 RBAC 之外又加了一层数据范围控制。功能权限决定“能不能点这个按钮”数据范围决定“能看哪些数据”。角色功能权限数据范围医生写病历、开医嘱、看检查结果本人负责的患者科室主任查看本科室工作量和患者本科室护士执行医嘱、记录生命体征本人所在病区收费员收费、退费、日结本收费窗口管理员配置、查询审计日志全院数据范围过滤必须在接口层实现不能只靠前端隐藏按钮。否则绕过前端直接调接口数据就泄露了。4.2 操作日志要按审计标准设计医疗系统最不能省的就是日志。我说的不是框架自动打印的错误日志而是业务审计日志谁查看了某患者的病历、谁退过费、退费原因是什么、谁修改过药品价格、原来的价格是多少。我留的关键字段包括操作人ID、动作、对象类型、对象ID、修改前内容、修改后内容、原因、IP、操作时间。日志表只允许插入不允许更新和删除。为了控制体积建议按月分区但查询能力必须保证。4.3 认证与接口安全按公网标准做医院系统大多部署在院内网络但我仍然建议按公网标准设计认证统一登录入口、密码加盐存储、会话超时、关键接口二次校验。内部服务之间加一层网关或签名校验避免某个请求绕过网关直接访问核心服务。这不是过度设计。医疗数据一旦泄露责任会很重事后审计如果发现连基本防护都没有问题更大。5. 上线实施中真正决定成败的往往是“非功能”问题5.1 基础字典不统一系统再先进也白搭实施阶段最先要统一的是基础字典。同一个药品门诊医生叫“阿莫西林”药房库存里叫“阿莫西林胶囊”系统就会因为名称不一致而对不上账。在上线前药库、收费项目、科室、床位、检验项目必须做统一编码给每个项目一个内部 ID业务数据只存 ID 不存名称。这一步不完成坚决不要开放业务模块否则后面所有统计都是糊涂账。5.2 打印和费用联动是现场体验的隐形杀手医院现场每天有大量纸质单据输出挂号单、处方笺、检查指引单、腕带标签、费用清单。打印模板如果被低估门诊一旦开始排队打印机卡纸、模板错位就会造成现场混乱。建议把常用打印模板按实际纸张尺寸反复走查并把“打印成功”纳入流程确认。费用联动方面药房发药前必须校验已缴费检查执行前必须校验收费状态退费必须考虑是否已执行。钱和物资一旦打架现场会非常难收拾。5.3 门诊高峰压测和降级方案必须提前准备医院系统最典型的压力场景是早上 8 点到 10 点的门诊高峰挂号、分诊、收费、采血同时并发。上线前要做承受能力测试至少模拟高峰期两倍流量。我见过不少系统功能没问题一到门诊高峰就卡死最后整个科室退回手工作业。另外还要准备降级方案当主系统出现问题时挂号、收费能快速切换人工备用模式记录数据在系统恢复后回补。这个方案不一定用得上但一旦用上能避免整个门诊瘫痪。5.4 外部系统对接是隐性工作量的大头日常医院管理不只是一个系统的事还要和检验系统、影像系统、医保平台对接。对接的难点不是联调本身而是数据编码和业务语义的映射。比如外院检验申请单里性别用 1/2本系统可能用 M/F必须做映射表并保留原始值。我的经验是对接任何外部系统前先确定三件事以谁的数据为准、失败时怎么补偿、消息丢失怎么追溯。否则就会出现检查结果回填不完整医生却以为是本系统丢了数据。最后我回头看这个项目真正难的不是哪一段代码而是把流程、状态、权限、费用四个维度同时理顺。如果只能给一条建议在动手编码前拿一张 A4 纸把系统涉及的角色、状态、每一步产生的费用流水画出来。画不清楚的地方就是将来最容易出问题的地方。hospital-management-esystem 这个项目让我学到的远不只是医疗业务还有一套适用于任何带强流程系统的建模方法。后来我再做其他系统第一件事还是画角色和状态流转图。这个习惯比任何框架都值钱。本文还有配套的精品资源点击获取