基于Java+Vue+ElementUI的电子病历产科管理系统设计与实现

跑过几个妇幼保健院和综合医院产科的信息化项目之后，你会发现需求书里几乎都会写一句话：“构建以电子病历为核心的数字产科管理系统”。这句话听起来像标准话术，真正落地时涉及的却是一整套从门诊建档、产检记录、高危评估、待产住院、产程分娩再到产后随访的业务闭环。我基于 Java + Vue + ElementUI 技术栈把这套系统的源码完整梳理并重构过一遍，今天把它拆开讲清楚：它到底在解决什么业务问题，核心模块怎么设计，技术方案为什么这么选，以及联调部署时最容易踩哪些坑。

无论你是医院信息科负责选型和验收的工程师，还是做医疗软件外包想快速搭出专科系统的团队，或者是刚入行想拿一个真实业务场景练手的学生，这套系统的设计思路都值得完整过一遍。它不只是一个普通的 CRUD 后台，而是把产科的业务规则、质控口径和数据流转逻辑都塞进了每一层代码里。接下来我按自己的实战视角，把这套系统的设计全过程、核心模块拆解和部署实录分享出来。

1. 为什么产科一定要做“以电子病历为核心”的系统

1.1 产科业务与其他科室的本质差异

产科在整个医院信息系统里一直是个比较特殊的存在。普通科室的病人通常是一次住院对应一份病历，出院归档之后就基本结束；产科则完全不同，一个孕妇从首次建档到分娩结束，跨度长达十个月，中间可能经历十几次门诊产检、若干次住院保胎、一次分娩住院、还有产后 42 天复查。这些数据散落在门诊、住院、产房、新生儿科多个环节，如果没有一套以患者为主索引的电子病历系统串起来，信息的断裂几乎是必然的。

我见过不少医院之前的状态：门诊产检还靠纸质母子健康手册，住院部又说找不到完整产检记录，产房助产士只能临时翻本子确认孕周和风险等级。纸质模式带来的问题不只是效率低，更重要的是高危妊娠的漏管。妊娠期高血压、妊娠期糖尿病、胎盘前置这类风险因素，如果早期发现但没有被系统持续跟踪，到分娩时可能就是完全不同的结局。电子病历在这种场景下承担的不只是“无纸化”任务，它要成为产科医疗行为的完整数据底座。

另外产科病历还有一个特点，就是“一个患者、两个对象”。产妇和胎儿都需要独立评估和记录，胎心监护曲线、胎儿超声数据、Apgar 评分、新生儿出生信息都要纳入同一套病历体系。这意味着数据模型不能简单照搬普通住院病历的表结构，得有专门的产科专科设计。

1.2 电子病历驱动下的信息流转闭环

以电子病历为核心，本质上做的是信息流转的闭环管理。孕妇在门诊建档时录入基础信息，这些信息自动带入后续的每一次产检记录；产检发现异常后，系统自动生成高危因素标记并调整风险等级；到了住院待产环节，住院医生打开病历就能看到完整的产检时间线和风险演变过程；分娩结束后，分娩记录和新生儿评分又反向补充到产妇档案中，形成一条完整的纵向链条。

在实际交付过程中，我最深的一个体会是：产科电子病历的难点不在录入界面，而在状态流转。比如一个孕妇从门诊转住院，她的产检档案和风险等级要能无缝衔接到住院医嘱；住院期间做了一次剖宫产，术后恢复和新生儿信息要能自动生成对应的病历文书。如果系统中的每一次转移都要人工重新录入一遍，医生很快就会失去使用信心。所以源码设计里，患者主索引（EMPI）和孕产次编号是全局的核心关联键，所有模块都围绕这两条线展开。

这套闭环带来的直接收益是质控和统计口径的统一。比如医院要统计剖宫产率、巨大儿发生率、妊娠期糖尿病筛查率，如果底层病历数据不是结构化存储，这些指标只能靠人工翻病历再统计，费时费力还容易出错。一旦产检字段、分娩结局字段全部结构化，报表模块可以直接从数据库聚合，指标口径也能在系统层面统一起来。

2. 技术选型拆解：Java + Vue + ElementUI 这套组合怎么定下来的

2.1 后端选型：Spring Boot + MyBatis-Plus 的实践路线

这套源码的后端采用 Java 技术栈，具体实现是 Spring Boot + MyBatis-Plus。做医疗信息化项目，技术选型首先要考虑的不是“哪个框架最酷”，而是团队上手速度、交付效率、后期维护成本。Spring Boot 在这几个维度上都非常成熟，自动配置降低了大量 XML 配置的工作量，内嵌 Tomcat 也让部署变得简单。哪怕是没写过 Java 的人，看懂 Spring Boot 项目的结构也不会太费劲。

MyBatis-Plus 的选择理由更直接：它把单表 CRUD 和常规分页查询做到了极致，而且对复杂 SQL 的兼容性很好。产科系统里大量数据查询都是“按患者 ID 查产检记录”“按孕周范围查高危档案”这类相对固定的模式，MyBatis-Plus 的 LambdaQueryWrapper 写起来非常顺手。这里强调一点，不要迷信“大而全”的框架，PostgreSQL 的 JSONB、JPA 的实体映射固然强大，但在产科这种业务边界清晰、报表需求固定的场景里，简单直接的 SQL 方案反而更可控，后期人员更替也更容易交接。

在模块划分上，我通常把源码拆成几个核心 Maven 模块：system 负责用户、角色、权限和操作日志；patient 负责患者主索引和孕产档案；visit 负责门诊产检和住院记录；delivery 负责产程、分娩和新生儿数据；report 负责统计报表和数据导出。这种按业务域划分的方式，比单纯按三层架构划分要清晰得多，也为后续微服务拆分预留了边界。

2.2 前端选型：Vue + ElementUI 对医疗后台系统的天然适配

前端技术栈选择 Vue + ElementUI，这个组合在后台管理系统领域几乎是用脚投票的结果。ElementUI 提供的表格、表单、日期选择器、弹窗、步骤条等组件，和医疗系统常见的密集数据录入、列表查询、状态审批场景高度匹配。特别是 el-table 的固定列、合并单元格和自定义模板能力，在产检记录列表、五色分级看板这类页面上非常实用。

我见到不少团队纠结于要不要上更现代的 Vue 3 + Element Plus，或者干脆换 React 生态。从我实际交付过的项目来看，如果源码目标是“快速落地、稳定交付”，Vue 2 + ElementUI 2.x 是更稳妥的选择，因为 ElementUI 的中文文档、社区案例和踩坑记录都极其丰富。团队新人接手时，遇到表格回显、表单校验这类问题，基本都能直接搜到现成方案，不用从零摸索。

当然这不是说 Vue 3 不行。如果你是从零开始的新项目，团队成员对组合式 API 很熟悉，上 Vue 3 + Element Plus 完全没问题。但如果你拿到的是一套已有源码需要二次开发，那最好先看清楚原项目用的版本，不要贸然混用。我遇到过把 ElementUI 升级到 Element Plus 之后，大量组件 API 不兼容导致页面白屏的案例，那种返工成本非常肉疼。

2.3 源码目录结构与工程模块划分

一个结构清晰的源码工程目录，对后期维护和团队协作的帮助是立竿见影的。我按这套系统的实际布局给你一个参考：

obstetric-emr ├── ob-emr-admin # 后台管理端前端工程（Vue + ElementUI） │ ├── src │ │ ├── api # 接口请求封装 │ │ ├── assets # 静态资源 │ │ ├── components # 通用组件（动态表单、时间轴、打印模板等） │ │ ├── router # 前端路由（含动态路由配置） │ │ ├── store # 状态管理（登录信息、权限缓存） │ │ ├── views # 页面视图（档案、产检、分娩、报表等） │ │ └── utils # 工具函数（日期处理、数据校验） ├── ob-emr-server # 后端服务工程（Spring Boot） │ ├── src/main/java │ │ ├── controller # 接口层 │ │ ├── service # 业务逻辑层 │ │ ├── mapper # 数据访问层 │ │ ├── entity # 实体对象 │ │ ├── dto # 数据传输对象 │ │ └── config # 配置类（权限、拦截器、全局异常） │ └── src/main/resources │ ├── mapper # MyBatis XML 文件 │ └── application.yml ├── sql # 数据库初始化脚本 └── docs # 设计文档和接口说明

这个目录结构看起来平淡无奇，但它划定了一条非常重要的边界：前端只通过 api 模块访问后端接口，后端把业务逻辑全部收敛在 service 层，mapper 层只做数据持久化。很多二次开发项目最后变成一锅粥，就是因为 controller 里直接写 SQL、前端页面里到处塞接口请求，混到最后谁都不敢动。

3. 核心模块与数据模型设计：产科病历的差异化打底

3.1 孕产妇档案与五色分级管理模块

孕产妇档案是整个产科系统的数据起点。建档时录入的基础信息包括夫妻双方身份信息、孕产次、末次月经、预产期、既往病史、手术史、过敏史等。这里有个业务细节容易被忽略：预产期的计算。系统需要根据末次月经（LMP）自动算出预产期（EDD），同时允许医生根据早期 B 超结果修正。源码里我建议把“预产期修正记录”单独存一张表，每次修正留痕，否则后期因为预产期不准导致的入出院纠纷很难追溯。

五色分级管理是产科电子病历里最具专科特色的模块，也是卫健委在孕产妇管理方面要求落地的核心功能。系统把妊娠风险分为绿、黄、橙、红、紫五个等级：绿色代表低风险，黄色代表一般风险，橙色代表较高风险，红色代表高风险，紫色代表患传染性疾病。每个孕妇建档后必须完成风险评估，评估结果直接决定后续随访频率和管理路径。

数据模型上，我用一张preg_risk_records表记录历次评估结果，包含风险等级、评估时间、评估医生、风险因素标签。关键设计是：风险等级不是覆盖式更新，而是每次新增一条记录，保留历史轨迹。这样医生打开档案就能看到这个孕妇的风险演变过程，比如从绿色变成橙色是哪次产检发现的、触发因素是什么。前端在孕妇列表和档案首页用五色标签展示当前风险状态，视觉上一目了然。

3.2 结构化产检记录与产检时间轴设计

产科产检记录的字段数量非常多，孕周、宫高、腹围、胎心、血压、体重、尿蛋白、水肿情况、胎位、头盆评分，每一项都是后续判断的基础。如果把这些字段全部平铺成表的列，产检项目一旦调整就要改表结构，后患无穷。所以我更倾向于“模板 + 结构化字段”的混合方案：公共字段放在产检主表，扩展字段以 JSON 格式存储在明细表中，打印时再根据模板解析。

这种设计在源码层面是怎么落地的？核心思路是定义一张模板表record_template，记录模板类型、版本号和字段 Schema；前端拿到 Schema 后动态渲染表单，用户提交时把数据打包成 JSON 存入record_data。查询历史产检时，后端再把 JSON 按模板还原成结构化对象返回给前端。这样做的好处是新增一种产检文书时，不需要动 Java 代码，只需要在后台配置新模板即可。

产检时间轴是这个模块在交互层面的亮点。前端用纵向时间线展示该孕妇历次产检记录，每条记录显示孕周、主要异常项和风险等级变化。医生不需要逐个打开旧病历，扫一眼时间轴就能掌握全貌。这个功能的实现难点在数据聚合接口：一次查询要同时返回产检记录、高危评估、住院记录和分娩记录，再按时间排序。如果前端拿到数据后自己排序拼接，容易出现时间格式不一致的问题，更好的做法是后端统一返回按时间戳排序的事件流。

3.3 产程记录、分娩记录与新生儿 Apgar 评分

产房模块是产科系统里操作频率最高、数据录入时效要求最强的部分。助产士在产程中要持续记录宫口扩张、胎头下降、宫缩间隔、羊水性状等信息，传统纸质产程图是画在坐标纸上的，电子化后用结构化表单加趋势曲线来还原。源码实现上，产程记录用高频录入模式，每条记录只需填写当前孕周、时间点和几个关键数值，系统自动生成产程进展曲线，若出现异常趋势则触发提醒。

分娩记录需要覆盖的分娩方式、分娩时间、会阴情况、出血量、胎盘胎膜是否完整等信息，这些字段在质控和后续纠纷处理中非常关键。有个细节是：分娩记录和产程记录要能够互相引用，比如第二产程时长是通过产程记录中的时间点自动计算的，不应该让助产士再手动填一遍。前端在分娩记录页面隐藏了这些自动计算字段，减少录入量，也避免手工算错。

新生儿 Apgar 评分是产科系统另一个专科模块。评分包括肤色、心率、反射、肌张力、呼吸五项，每项 0 到 2 分，分别在出生后 1 分钟、5 分钟和 10 分钟各评分一次。源码里这个功能做成一个快速录入卡片：五项的点击按钮就是 0、1、2 三档，选完自动计算总得分，并生成新生儿出生记录。值得注意的是，Apgar 评分数据必须支持修改留痕，因为新生儿情况变化快，医生可能纠正评分，每次修改都要记录操作人和时间。

4. 关键功能实现细节：从页面到接口的硬骨头

4.1 动态表单：一套代码支撑几十种产科文书

产科病历文书种类很多，首次建档、复诊产检、入院记录、分娩记录、产后观察等都有不同的字段组合。如果每种文书都单独写一个 Vue 页面和对应的实体类，开发和维护成本会迅速失控。动态表单方案是这类系统的标配解法，把“页面”变成“数据”，代码量可以压缩一半以上。

实现思路分成三步。第一步，在模板表里定义每个字段的类型、标签、校验规则、默认值和占位提示；第二步，前端写一个动态渲染组件，根据字段类型渲染对应的 ElementUI 控件；第三步，提交时把整个表单的值序列化为 JSON，提交到后端存档。下面是一段简化后的 Schema 示例：

[ { "key": "gestational_week", "label": "孕周", "type": "input", "rules": [{ "required": true, "message": "请输入孕周" }] }, { "key": "blood_pressure", "label": "血压mmHg", "type": "input", "placeholder": "收缩压/舒张压" }, { "key": "fetal_heart", "label": "胎心率", "type": "number", "min": 60, "max": 220 }, { "key": "edema", "label": "水肿", "type": "select", "options": ["无", "+", "++", "+++", "++++"] } ]

前端动态组件这样处理：

<el-form :model="formData" :rules="formRules" ref="dynamicForm"> <el-form-item v-for="field in schema" :key="field.key" :label="field.label" :prop="field.key"> <el-input v-if="field.type === 'input'" v-model="formData[field.key]" :placeholder="field.placeholder" /> <el-input-number v-else-if="field.type === 'number'" v-model="formData[field.key]" :min="field.min" :max="field.max" /> <el-select v-else-if="field.type === 'select'" v-model="formData[field.key]"> <el-option v-for="opt in field.options" :key="opt" :label="opt" :value="opt" /> </el-select> </el-form-item> </el-form>

这套方案看起来简单，实际落地有两个坑需要提前处理。第一个是数据回显时的类型丢失问题，比如数字类型的字段在 JSON 序列化和反序列化后变成了字符串，导致 el-input-number 的校验直接报错。解决方式是在后端序列化时显式声明字段类型，或者前端回显时根据 Schema 中的 field.type 做一次类型转换。第二个是模板版本变更后，旧数据的渲染兼容问题。我的建议是模板表的字段一旦投入使用，就不允许物理删除，只能标记为废弃，否则历史病历打开时会因为字段缺失而报错或显示错乱。

4.2 产科预警规则与风险提示的实现思路

预警规则是让电子病历系统产生实际业务价值的关键功能。产科最常见的预警场景是：该做糖耐量筛查的孕妇到 28 周还没做检查、血压持续偏高达到子痫前期诊断标准、胎心监护结果异常等。如果这些判断完全靠医生人工从一堆病历记录里发现，漏诊风险非常大。

源码里我采用“规则配置 + 定时任务 + 页面触发”三路并行的方式。规则配置层用一张字典表存储预警阈值和提示文案，比如收缩压大于等于 140 或舒张压大于等于 90 时触发妊娠期高血压提醒；定时任务每天扫描所有在管孕妇的产检记录，找出漏检或异常情况生成待办任务；页面触发则是医生打开病人档案时，前端调用接口实时计算当前风险状态，在页面上方用警示条展示。

有个经验方面的提醒：预警规则最好是可与业务人员共同维护的配置化数据，不要把它硬编码在 Java 代码里。不同医院妇产科的诊断标准、筛查节点可能存在差异，比如有的医院把 24 到 28 周作为糖耐量筛查窗口，有的可能提前到 20 周。配置化规则让实施人员可以在上线后根据医院要求微调，而不需要重新编译部署整个服务。

4.3 病历打印、PDF 归档与“可修改”边界处理

电子病历系统绕不开打印和归档两个环节。门诊产检记录需要打印出来给孕妇留存，住院病历需要按规范打印归档，出院后病历要进入只读状态。很多开发者在写打印功能时只做浏览器 window.print()，结果一打印表格线丢失、分页错乱、页眉页脚缺失，打印出来的东西没法进病历档案。

我的做法是为打印单独设计一套 CSS 样式，核心几点：使用 @media print 定义打印专用布局，隐藏导航栏和按钮；用 @page 设置纸张方向和页边距；表格使用固定边框样式并避免跨页断行。对于需要长期保存的病历文书，推荐后端集成 iText 生成 PDF 文件，归档时把 PDF 文件路径存入病历表，这样即使前端页面样式变化，历史病历的打印副本依然保持原貌。

归档后的修改控制是个合规性重点。病历一旦归档，原则上不允许直接覆盖修改，只允许通过“病历修正申请”流程在保留原记录的基础上进行补充或更正。源码实现上用状态字段控制病历状态，比如 draft、active、archived 三种状态。处于 archived 状态时所有更新接口都先做状态校验，非管理员角色直接返回不可操作。后端接口做了状态校验还不够，前端也要把编辑按钮隐藏掉，两条线同时控制才能防止绕过 UI 直接调接口的情况。

4.4 多端协作与并发编辑的数据一致性

产科病房是多医生、多护士协作场景，同一个产妇的病历可能被管床医生、护士、助产士同时操作。前端页面同时打开多人编辑同一份档案时，后提交的人很容易覆盖先提交的数据。这个问题的解决方案我用的是乐观锁：病历主表增加 version 字段，每次更新时要求前端提交读取时的版本号，后端用 update 语句的 where 条件加上版本号校验，受影响行数为 0 时提示“数据已被他人修改，请刷新后重试”。

这个方案比悲观锁（SELECT FOR UPDATE）更适合医疗场景，因为它不会长时间占用数据库连接，只是在冲突发生时让用户重试。实际使用中，我给前端页面里的编辑操作都加了冲突提示引导，比如让系统自动刷新最新数据，并把用户已填内容缓存到本地草稿，等用户重新打开时再做比对和合并。这个“草稿 + 冲突检测”的组合，比单纯抛一个错误让用户手动重填要友好得多。

5. 部署上线与典型问题排查实录

5.1 本地开发环境搭建与初始化记录

这套源码的本地跑通流程，我按实际经验整理成了一份可以直接照做的清单。后端要求 JDK 8 或以上、Maven 3.6+、MySQL 5.7 或 8.0；前端要求 Node.js 14 以上，使用 npm 或 yarn 安装依赖。先把 sql 目录下的初始化脚本导入数据库，脚本会创建库、表结构和基础字典数据。然后修改后端 application.yml 里的数据库连接、文件上传路径和日志级别，启动 Spring Boot 主类，确认 8080 端口正常响应。

前端部分的顺序是：进入 ob-emr-admin 目录执行 npm install，依赖装完后 npm run dev 启动开发服务器。这里有个常见的小问题，npm install 时不同依赖之间的版本冲突会导致安装失败，建议直接使用 package-lock.json 锁定版本环境。开发模式下前端通过 Vite 或 Webpack 的代理转发 /api 请求到后端，需要把配置文件里的代理地址指向 127.0.0.1:8080。如果代理配置不对，前端能打开但登录接口会报网络错误或跨域错误。

5.2 生产环境部署踩坑实录

生产环境我踩得最多的一个坑是 MySQL 8.0 的认证插件。MySQL 8 默认使用 caching_sha2_password，而项目里依赖的 JDBC 驱动版本如果偏老，连接时直接报 Unable to load authentication plugin。解决办法有两个：要么升级 MySQL Connector/J 到 8.0 以上版本，要么在创建用户时指定 mysql_native_password 插件。前者是正路，后者只是权宜之计。

Nginx 部署前端时也有一个高频坑：Vue 路由使用 history 模式后，刷新页面会出现 404。原因是前端路由的 URL 在服务端找不到对应文件，需要在 Nginx 配置里加上 try_files 指令。我的配置大致是这样的：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

还有一个容易被忽略的问题，是接口报错日志全部打到后台控制台，前端只看到一个“网络异常”。后续排查效率太低了。建议在全局异常处理器里把错误码、堆栈和请求参数记录到独立的 error.log 文件，并返回给前端一个符合接口规范的错误对象，这样前端可以根据 errorCode 做针对性提示。

5.3 常见问题速查表

我把这套系统交付过程中反复出现的病状整理成一张速查表，遇到类似问题可以直接对照定位。

5.4 联调阶段的数据准备与测试技巧

这个经验我认为很值得单独说。产科系统的功能联调，最大的痛点是缺真实数据。随便造几条测试数据进系统，产检时间轴、风险等级变化、产程曲线这些功能根本看不出来效果。我习惯用一条完整的虚拟孕妇数据走完整个生命周期：建档时录入一个 12 周孕妇，生成预产期；然后按时间顺序补 6 到 8 次产检记录，中间故意加上一次血压偏高和一次糖耐量异常；再录入一次 38 周入院记录、一次分娩记录和 Apgar 评分结果。这样一套数据走完之后，前端的时间轴、五色分级、预警提示、分娩闭环全部都能验证到。

这套测试数据在项目里非常值钱，建议存成 SQL 脚本放进项目的 test-data 目录，新同事入职做环境自测时直接导入，省掉大量手工造数的时间。甚至我在给医院做演示时，用的也是这套脚本，演示效果比只截几张静态页面图好得多。

最后再分享一个落地层面非常关键的体会

做完这套产科电子病历系统后，我最大的感受是：医疗软件的技术难点从来不在框架，而在业务模型的还原度。Java、Vue、ElementUI 这些技术选型谁都能做，但把产科的五色分级、产程曲线、Apgar 评分、病历归档状态这些专科逻辑梳理清楚，才是系统真正能不能在医院用起来的分水岭。源码的价值也不在代码本身，而在于它把一套完整的业务规则和状态流转用工程化的方式固定了下来。

最后再给一个小建议：如果你准备基于这套源码做二次开发，不要一头扎进代码里，先拿着文档去产科跟医生交流几天，把他们的工作流程和痛点摸清楚。我见过太多开发团队把界面做得很好看，但产房录入流程和助产士的习惯完全不符，最终被弃用的案例。技术是为业务流程服务的，理解了业务，源码里的每一处设计才会变得顺理成章。