医院门诊系统需求分析：从业务流程到数据库设计的落地指南

简介：医院门诊系统需求分析报告文书是一份面向医院信息化建设人员、系统分析师及软件开发工程师的正式需求文档，用于梳理门诊业务流程与系统功能边界。压缩包内共 1 个 doc 文件，容量约 455KB，内容按照标准需求分析结构展开：先分析医院组织机构、各部门关系与门诊部业务活动，再明确目标用户特点；随后对病人信息、医生信息、各种单据信息和库存信息分别提出管理要求，并给出功能规定、性能规定、安全性与完整性规定。报告还配有分层数据流图，从第一层到第二层逐级细化挂号、诊断、处方、结算等数据流转路径，有助于读者理解系统模块划分与接口关系。目前已有 152 人学习下载，适合作为门诊系统项目启动阶段的需求调研模板或课程设计参考，尤其对需要撰写规范软件需求说明书的初学者，具有直接的借鉴与模仿价值。

1. 一份没有流程图的需求分析书：拆门诊系统，先还原它没说清的业务主链

拿到医院门诊系统需求分析报告文书这类 doc，大多数人第一反应是先翻有没有数据库建表语句和接口定义，翻完发现全是描述性文字，连一张完整的流程图都没有，很容易觉得没含金量。我做门诊信息化项目时反而最看重这类素材，因为最难的不是单表增删改查，而是把挂号、就诊、划价、收费、取药、检查、化验这一整串业务闭环在哪个环节产生数据、数据流向哪里、哪些数据要沉淀到电子病历里全部理清楚。这份文档没有给出字段长度，却把初诊复诊的循环、药房补货预警、检查结果自助打印这些线下链条完整写出来了。对做系统设计、做需求转开发的工程师来说，它是画数据流图、建 E-R 模型、定权限矩阵的现成底稿，也是一次很典型的需求分析落地训练。

2. 组织机构与门诊业务流：把部门关系翻译成模块清单与数据流图

需求分析报告的价值不在于页数多少，而在于能否让人闭着眼睛画出业务发生的先后顺序。这份文档用了大量篇幅描述医院的组织机构情况和门诊业务活动，表面看是背景介绍，实际是整套系统的模块地图。

2.1 组织机构是模块地图，不能照抄成菜单

原文把医院构成列了一长串：门诊部、住院部及下设的口腔科、内科、外科、皮肤科、骨科，还有药库、中心药房、门诊药房、制剂室、设备科、财务科、后勤仓库、门诊收费处、门诊挂号处、问讯处、住院处、检验科室、检查科室、血库、病案室、手术室，以及行政部门。

这串名单的用法不是原样生成菜单，而是归类成模块。我一般会先做一张映射表，把线下部门对应到未来的系统模块：

这张映射表的关键在于：系统菜单不能按原文部门翻译。药房和药库是两级库房，操作权限和业务逻辑完全不同，系统里要分开页面而不是合在一起。如果前期不做归类，后面做“药品申领扣减”时，会分不清“中心药房库存”和“药库库存”，产生连环错账。

2.2 门诊业务活动本质是一个状态机

原文对门诊业务流程的描述可以抽象成一条主线：挂号 → 候诊 → 医生接诊（诊断并开处方或检查检验申请单）→ 划价交费 → 取药/检查/化验 → 复诊 → 离院。这条链路由多个状态节点组成，落到系统设计时，每个节点对应一个业务状态。

这个状态表在后续开发里直接变成数据库中的一个状态字段。常见做法是每个就诊记录加一个状态枚举：0 待挂号、1 待就诊、2 待缴费、3 待取药、4 待检查、5 待复诊、6 已完成。原文没有给字段定义，但这个枚举是落地时绕不开的，提前确定它，后面所有流程分支都好写。

2.3 数据流图怎么还原和补全

原文只在第 7 节写了“第一层数据流图”“第二层数据流图”，实际没有给出图。拿到这类文档第一件事，是根据正文描述把两层数据流图补出来。

第一层数据流图描述顶层系统与外部实体的数据关系。还原结果大致是：

• 外部实体：病人、医生、药房人员、收费人员、库存管理人员、院长/行政人员。
• 顶层加工：门诊系统。
• 主要数据流：病人基本信息、挂号信息、处方信息、收费信息、取药信息、检查申请与结果、库存出入库信息、统计分析报表。

第二层数据流图把门诊系统拆成挂号处、收费处、取药处、化验处四个加工。继续按原文拆解：

• 挂号处加工：接收病人信息，生成挂号单和排队号；复诊病人直接刷卡取号。
• 收费处加工：接收处方或申请单，划价后产生收款单，同时药房系统自动出现该病人的待配药单。
• 取药处加工：接收收费存根与处方，配药、发药，扣减库存，低于临界值生成药库申领单。
• 化验处加工：接收检查申请单，执行检查，结果回写系统并写入电子病历，支持自助机刷卡打印报告。

在没有原始图的情况下，靠正文还原出来的数据流图能直接用来做复查：检查每个加工是否有对应的输入和输出数据流。比如挂号处如果没有输出“病历号”到病人实体，初诊复诊逻辑就断了。这就是这类文档最实用的地方——业务规则写在文字里，比画在图上更耐用，也更容易追溯到原始需求。

3. 需求规定落地：字段实体、权限矩阵与完整性要求怎么写

原文第 4 节把需求规定分为病人信息、医生信息、单据信息、库存信息四大类，但没有给字段结构和类型。进入开发前，这一步是必须补齐的。

3.1 四大信息实体怎么拆

病人信息在原文中分门诊和住院两类。门诊病人需要姓名、性别、出生年月、年龄、家庭住址、联系方式，以及就诊时间、就诊医科、就诊结果、处方记录、检查时间与项目与结果、检验时间与项目与结果。住院病人还要追加入院时间、病区、床位号、主治医师、用药记录、手术记录、病情变化、出院时间。

这里有一个常见冗余点：原文同时列了“出生年月”和“年龄”。实现时不需要存两遍，只存出生日期，年龄由系统实时计算。我在建表时会把 age 做成生成列，彻底避免人工录入不一致。

医生信息也类似。原文把门诊医生和住院医生的属性混在一起，其中挂号单价、当天工作量、出诊时间属于排班和绩效数据，不是医生主档数据。落地时应拆成“医生人员表”和“出诊排班表/工作量表”两张表，不然后续统计工资时要在一张表里复杂聚合。

单据信息原文列了诊断书、处方单、检验申请单、检查申请单、检验结果报告单、检查结果报告单、收款单、病人医疗记录、手术申请单、手术通知单、病人入院登记单、转科申请单、病人情况登记单、药品提领单、药品发放记录、药品出入库单、设备使用记录、器械领用单等十几种。落地时要按类别处理，不能一张“单据表”全部装下。

3.2 七条功能规定的落点

原文第 5 节提了 7 条功能规定，每条背后都有对应开发点，不是一句空话：

原文有一条“根据医生的出诊情况、工龄、工作量、职称等计算工资应得金额”，这条本质是工作量核算，设计上不要做进医生登录页面，而是后台定时任务按排班表和接诊记录每日汇总，月底生成工资明细。原文没有说“定时”，但统计类需求按异步处理是常见做法，同步实时计算会在月底半个月卡死业务。

3.3 五类用户权限矩阵

原文第 6.1 节把用户分成病人、医生、管理人员、系统管理员、院长五类，并规定了各类可看的数据范围。这个权限矩阵可以直接抄进需求规格里：

开发时建议在角色之上再加数据范围控制。比如“医生”只能看本科室病人，不能看全院病历；“管理人员”要细分到岗位，药房管理人员只看药品相关单据，财务只看收费退费记录。按这个思路落地，后面信息科验收时不容易被打回。

3.4 完整性要求要落到唯一录入源

原文第 6.2 节写了三条完整性：信息非空、数据间联系正确、相同数据在不同记录中一致。这三条看着是常识，实际要靠数据库约束兜底：非空字段用 NOT NULL，关联关系用外键，一致性用唯一索引和事务。

但它还隐含一个需求——第 6.3 节说的“一个环节录入信息，其它环节共享”。这意味着同一份数据不能有多个录入入口。病人姓名只在挂号时录一次，医生工作站、收费处、药房都通过病历号关联。如果哪个页面允许科室前台再录一次病人姓名，就会出现两个数据库里同一个病人姓名不一致的情况。开发时要做的不是加校验，而是给每个字段定唯一录入源（Single Source of Truth），这是门诊系统最容易出数据质量问题的地方。

4. 从需求分析书到系统雏形：用结构化提示词和建表 SQL 把文档变成蓝本

现在团队拿到需求分析书后，普遍会尝试让 AI 辅助生成系统初版，但效果方差很大。关键不在模型能力，而在输入方式。

4.1 先把需求文档翻译成结构化提示词

我见过太多人直接把整份 doc 丢给 AI 说“帮我开发一个医院门诊系统”。输出永远是通用模板，跟这份需求对不上。正确做法是让 AI 先做结构化提取，再基于提取结果生成方案。

下面这段提示词可以直接复制使用：

你是一名资深HIS系统架构师。请从以下医院门诊系统需求分析文档中提取全部业务实体、关键字段、业务流程和权限要求，输出三张表： 1. 实体清单表：实体名、核心字段、关联实体、来源章节 2. 流程状态表：流程名称、环节、触发动作、产生的单据 3. 权限矩阵表：角色、可读范围、可写范围 不要添加文档中不存在的功能。提取完成后，基于提取结果给出一个Spring Boot + MySQL的基础模块划分建议。

这里有个参数技巧：“不要添加文档中不存在的功能”这句是防幻觉的关键。需求文档描述容易模糊，比如原文没有明确“退费”流程，AI 往往自行脑补退费接口。风控做法就是把这句写死。如果业务确实需要退费，应该在需求评审阶段补需求，而不是让 AI 顺带生成。

通常可以把这份文档拆成三段让 AI 分步消化：第一段“组织机构+业务活动”生成模块结构；第二段“需求规定+功能规定”生成数据字典；第三段“性能要求+系统结构”生成权限清单和部署建议。这样后面做需求追溯时，能准确说明某段需求落到了哪个模块。

4.2 用实体拆解结果生成核心建表 SQL

把提取结果转成建表语句时，门诊系统核心表一般至少包含病人表、医生表、出诊排班表、挂号表、就诊记录表、医嘱表、收费单表、药品库存表、药房发药表。以原文 4.1 和 4.2 节的病人、医生信息为例，最小可运行版本如下：

CREATE TABLE patient ( medical_record_no VARCHAR(20) PRIMARY KEY COMMENT '病历号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender ENUM('M','F') NOT NULL COMMENT '性别', birth_date DATE NOT NULL COMMENT '出生日期', age TINYINT AS (TIMESTAMPDIFF(YEAR, birth_date, CURDATE())) COMMENT '年龄', home_address VARCHAR(200), phone VARCHAR(20), ic_card_no VARCHAR(50) UNIQUE COMMENT 'IC卡号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT '病人基本信息表'; CREATE TABLE doctor ( doctor_id INT AUTO_INCREMENT PRIMARY KEY COMMENT '工号', name VARCHAR(50) NOT NULL, gender ENUM('M','F') NOT NULL, dept_id INT NOT NULL COMMENT '所在科室', title VARCHAR(30) COMMENT '职称', office_time VARCHAR(100) COMMENT '出诊时间描述', visit_fee DECIMAL(6,2) COMMENT '挂号单价', UNIQUE KEY uk_doctor_name_dept (name, dept_id) ) COMMENT '医生基本信息表'; CREATE TABLE visit_record ( visit_id BIGINT AUTO_INCREMENT PRIMARY KEY, medical_record_no VARCHAR(20) NOT NULL COMMENT '病历号，关联patient', doctor_id INT NOT NULL COMMENT '接诊医生，关联doctor', visit_date DATETIME NOT NULL, visit_status TINYINT DEFAULT 0 COMMENT '0待缴费 1待取药 2已完成', diagnosis_result TEXT COMMENT '诊断结果', FOREIGN KEY (medical_record_no) REFERENCES patient(medical_record_no), FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id) ) COMMENT '门诊就诊记录表';

逻辑说明：patient 表的 age 字段是生成列，由 birth_date 实时计算，避免“年龄”和“出生日期”不一致，这就是前面字段消重的实际落地。visit_status 用数字枚举对应状态机，便于在业务里做分支判断。ic_card_no 单独建唯一索引，因为复诊病人是刷卡挂号，卡片号和病历号必须一一对应。

注意 visit_record 的设计逻辑：处方、检查申请、检验申请这些单据不应该直接挂在 patient 下，而应该挂在 visit_record 下。因为同一个病人的多次就诊会产生多份处方，必须通过 visit_id 关联，才能统计“这次就诊开了哪些药、收了几次费”。

提示：第 4.3 节的挂号单、收费单、医嘱单之间的关系统一要建立在 visit_id 上，不要用就诊时间字符串去关联，字符串关联在夜间跨天时会丢数据。

4.3 两条闭环校验：取药流程和检查结果返回

原文中“病人到门诊收费处划价交费，药房系统自动显示药方，病人持收费证明到门诊药房取药”这一段，是典型的跨模块联动。注意：药房取药在整个流程中不需要看到收费金额，它只需要看到“这个处方已收费且有处方明细”。

校验方法：在 API 层面，取药接口不查询费用记录，只依赖就诊状态。收费处收款成功后修改就诊状态为已缴费，药房列表自动刷新。如果药房窗口还去关联收费表，就属于越权显示。同样，化验处结果只回写到检验报告表，同时通知原就诊医生，不直接开放给病人修改。

给一段事务边界的伪代码：

def pay_and_queue(visit_id, amount): with db.transaction(): # 步骤1：写入收费记录 charge = create_charge_record(visit_id, amount) # 步骤2：把visit状态改为已缴费 update_visit_status(visit_id, status='PAID') # 步骤3：给药房生成待发药队列 pharmacy_queue.create(visit_id) # 步骤4：提交后给收费处返回打印小票 return print_receipt(visit_id)

三个写操作放进同一事务的原因是：一个环节要么三个都成功，要么都回滚。如果步骤 2 成功、步骤 3 失败，病人会发现钱交了药房却看不到处方，这是医院系统最典型的翻车现场，事务边界必须清晰。

除了正常流程，还要预留检查报告的“等待期”。原文提到报告单需要等待时，病人持病历卡到自助机打印。这意味着化验报告表和收费单不是强同步，报告存在“已申请、已采样、报告生成中、可打印”几种状态。开发时不要把报告状态和收费状态绑成一个字段，否则一台自助机打印失败会把收费流程锁住。

5. 避坑指南：门诊系统需求文档落地时最容易翻车的五个点

这类需求文档描述偏流程化，到了实现阶段会遇到不少细节坑。下面这些是我实际踩过或见过的。

5.1 挂号卡和 IC 卡纠缠不清

现象：需求文档中既有“每个病人发放挂号卡”，又提到“电子病历存储在 IC 卡中”，产品经理自己也说不清到底用哪种卡。

原因：线下物料和信息化标准没对齐。普通磁条卡成本低，IC 卡适合存数据但要配读卡器，还要考虑补办和丢失场景。

解决：把“卡”降级为“病历号”的索引介质，数据库主键依然是病历号。长期方案以数据库为准，IC 卡只冗余一份用于自助机和线下应急。记住一个原则：卡可以换，病历号不变。

5.2 病人填年龄还是算年龄

现象：表单里同时出现“出生年月”和“年龄”两个字段，测试时发现有人填的年龄和出生日期对不上。

原因：人工录入年龄容易过时，门诊系统里年龄只是辅助展示，医院真正关心的是出生日期和年龄段统计。

解决：页面只录入出生日期，年龄由系统计算。后端校验时，即使前端提交了年龄字段，也要与出生日期比对，超范围就拒绝保存。我在建表时用生成列实现，一劳永逸。

5.3 库存预警阈值写死在代码里

现象：药房某天一批常用药没触发预警，查代码发现是“库存<10”写死的，实际最小发货单位是盒，一批药有 30 盒，10 这个阈值毫无意义。

原因：需求文档只写了“库存少到一定程度应提出警告”，没定义程度，开发顺手把阈值当成常量。

解决：预警阈值做成参数表，按药品分别设置：

CREATE TABLE stock_threshold ( med_id INT PRIMARY KEY COMMENT '药品ID', warehouse_id INT COMMENT '仓库ID', warn_qty DECIMAL(12,2) NOT NULL COMMENT '低于该数量触发预警', enabled TINYINT DEFAULT 1 COMMENT '启用标记', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '库存预警阈值表';

阈值修改要走审批，不能直接在系统配置页面任意乱改，否则药房人员调阈值会让预警完全失效。

5.4 单据类型多，建表时按单据类型拆还是抽象统一

现象：医生开处方同时开检验申请单，缴费后走两条不同流程，开发建了处方表、检查申请表、检验申请表三张单子，结果“退回重开药”时很难在一个界面里统一操作。

原因：文档把各种单据平铺叙述，开发照抄，没有抽象出“医嘱”这一层概念。

解决：建议用医嘱表加医嘱类型字段（PRESCRIPTION/EXAM/LAB），主键统一，用状态字段区分已开立、已缴费、已执行、已终止。界面上的增删改操作作用在医嘱表，而不是分别改三张表。这样挂号单、收费单、医嘱单之间的关联路径都清晰。

5.5 权限只做到菜单级，没有按钮级

现象：给医生开了门诊工作站权限后，发现医生能进入收费日结页面，虽然看不到金额，但能看到药品成本价，被信息科打回。

原因：文档只区分五类用户，没有区分“能进页面”和“能操作按钮”，开发按角色做菜单权限，忽略了按钮和字段权限。

解决：落地时做成 RBAC 加权限码。角色拥有菜单权限，数据范围按科室过滤，对收费、退费、维护药品价格、删除记录这类敏感操作单独加按钮级权限码。不要等验收再补，那需要在每个接口加一遍拦截，工作量会成倍增加。

5.6 报表统计口径不一致

现象：门诊收入月报和收费处日报对不上，财务认定是 bug。

原因：日报按收款时间统计，月报按就诊时间统计，同一笔费用落在跨天时段（比如晚上 23:55 交费后次日 0 点日结）就出现了差异。

解决：在报表模块统一时间维度参数，把费用归属时间做成可选：按收费时间、按就诊时间、按单据生成时间，所有报表默认按收费时间，并在统计口径说明里写清楚。

6. 进阶验证：从需求文档倒推测试用例与数据字典检查法

把这套需求分析书用熟之后，它还能充当验收阶段的测试底稿。把数据流图变成流程用例，等于做了一次需求分析仿真实验。

我经常用“单据清单反查表”来检查数据库有没有漏表。把原文列的十七八种单据逐一对照系统是否存在。比如“手术通知单”，它不是手工录入的表，而是由手术申请单加排班结果自动生成，数据库可以不单独建表，但必须能查询出一条完整链路：手术申请单 → 排班记录 → 手术通知单 → 术后记录。如果既没有表也没有视图能还原这条链，那就是漏项。

最后建议从第一次需求评审时就建一张需求追溯矩阵，把需求来源章节、对应模块、对应 API、测试用例编号、验收结果列成一张 Excel，不要等项目结束再补。上线前拿矩阵逐条勾选，哪些需求没落、哪些实现错了一目了然。

做这个拆解项目时，我最大的教训就是拿到需求分析书先忍住不写代码，把所有流程状态和单据类型列成两张表再动手。从那以后，每次接触门诊信息化这类带线下流程的项目，我都强制自己先走一遍“模块映射 → 状态表 → 权限矩阵 → 用例反查”的流程，再让开发或 AI 进场。希望帮到你。

本文还有配套的精品资源，点击获取