简介本资源为卫宁电子病历EMR系统核心数据库结构设计说明书面向医院信息科工程师、医疗信息化系统实施人员、HIS/EMR二次开发技术人员及医疗大数据建模研究者解决临床信息系统数据建模不清晰、表间关系难追溯、医保与收费字段映射不明确等实际问题。文档以Word格式.doc单文件呈现完整涵盖800余张业务表包括职工代码库、诊断代码库、药品分类库、收费项目库、医保分类库、科室/病区/地区代码库等19类关键基础字典表及关联逻辑总大小13.92MB结构严谨、字段级定义详尽含类型、长度、值域与备注。内容源自卫宁5.0版临床信息系统官方设计文档含目录、版本信息、拟制与评审记录具备强规范性与工程落地参考价值。目前已有1553人学习下载可直接用于系统对接开发、数据治理方案设计、医保结算逻辑验证及医疗信息标准化改造。1. 卫宁电子病历表结构不是“拿来就能用”的数据库字典而是临床业务逻辑的实体映射你手头这份《卫宁电子病历表结构.doc》表面看是800多张表的字段清单但真正踩过坑的人知道它根本不是一张静态的“数据地图”而是一套被临床流程反复锤炼过的业务契约。我带过三个医院信息科升级项目每次对接卫宁EMR第一周都在干同一件事——把PUB_SFDXMK收费大项目库和CPOE_YZDJK医嘱单据这两张表的主键关系对齐因为门诊开单、住院计费、医保结算三端的“项目编码”在不同模块里居然有4种映射路径。这不是设计缺陷是临床真实场景倒逼出来的冗余容错。这份文档适合谁适合正在做医疗信息系统毕设/课设的学生尤其要交数据库设计ER图接口说明三件套、也适合刚接手卫宁老系统维护的初级HIT工程师——你不需要从零造轮子但必须读懂每张表背后“医生怎么点、护士怎么执行、财务怎么对账”这三层动作。它不教你怎么写SQL但它决定了你写的SQL查出来的是正确数据还是“看起来对、其实漏了手术麻醉记录”的玄学结果。2. 总体架构设计三层结构与四个核心域的职责划分卫宁EMR的表结构绝非杂乱堆砌其底层遵循典型的临床业务驱动型分层架构基础主数据层PUB_前缀、临床执行层CPOE_前缀、系统支撑层SYS_前缀。这种分层不是为炫技而是为了应对医院最头疼的三类变更医保政策调整只动PUB_YBFLK、新手术类型上线只扩CPOE_SSJLMB、人事组织架构重组只改SYS_KSDMK。下面拆解四个不可绕过的高价值域每部分都附可直接复用的设计逻辑。2.1 基础主数据域所有业务的“锚点表”改错一张全盘偏移这是整个系统的基石所有带PUB_前缀的表如PUB_ICD10、PUB_ZDDMK、PUB_YPFLK共同构成临床术语的统一词典。关键设计点在于值域强约束版本快照机制ICD10诊断代码表PUB_ICD10字段定义示例CREATE TABLE PUB_ICD10 ( ICD10_CODE VARCHAR(10) NOT NULL COMMENT ICD-10编码如A00.0, ICD10_NAME VARCHAR(200) NOT NULL COMMENT 标准中文名称, ICD10_ENG_NAME VARCHAR(300) COMMENT 英文名称, LEVEL_TYPE TINYINT NOT NULL COMMENT 层级类型1章,2节,3条目, VALID_FLAG CHAR(1) DEFAULT 1 COMMENT 有效标志1有效,0停用, VERSION_NO VARCHAR(20) NOT NULL COMMENT 版本号如2023V1, CREATE_TIME DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (ICD10_CODE, VERSION_NO) );提示注意VERSION_NO字段——卫宁不直接删旧代码而是通过版本号隔离。比如2023年医保新规要求停用某编码系统不是UPDATE VALID_FLAG而是INSERT一条新记录VERSION_NO改为2023V2。这样历史病历仍能关联原始编码新录入强制走新版。这是医疗数据合规性的硬性要求也是学生毕设里最容易忽略的“时间维度”。药品分类库PUB_YPFLK的设计更体现业务耦合性。它不只存“西药/中成药”这种粗分类还包含IS_HAZARDOUS是否高危药品、IS_ANTIBIOTIC是否抗生素、IS_INSURANCE_COVERED是否医保目录内等业务标识字段。这些字段直接驱动前端医生工作站的弹窗警告如开高危药需双签、药房发药校验抗生素需皮试记录、医保结算引擎目录外药品自费提示。2.2 临床执行域以CPOE为核心把医嘱变成可执行指令流CPOEComputerized Physician Order Entry是卫宁EMR的神经中枢所有带CPOE_前缀的表占全文档表数65%以上本质是将医生口头指令转化为结构化、可追溯、可执行的数字工单。这里的关键不是表多而是表间状态机驱动的设计哲学。以最核心的CPOE_YZDJK医嘱单据表为例其状态字段ORDER_STATUS定义了7种取值0草稿医生未提交1已提交等待审核2已审核可执行3已执行护士确认4已停止医生取消5已作废系统异常回滚9已完成闭环而每种状态变更都强制关联到对应的操作表状态1→2提交→审核必须写入CPOE_YZSHJL医嘱审核记录表记录审核人、审核时间、审核意见状态2→3审核→执行必须写入CPOE_YZSPJL医嘱执行记录表记录执行人、执行时间、执行设备如输液泵编号状态3→9执行→完成需校验CPOE_YZYLKZXXK医嘱用量扩展信息中的累计执行量是否达标。这种设计让“一条医嘱”不再是数据库里的一行记录而是一个带生命周期的业务对象。学生做毕设时若只画ER图不画状态流转图答辩时导师问“护士执行后如何防止重复执行”立刻哑火。2.3 系统支撑域SYS_表是权限与组织的骨架决定谁能看什么SYS_前缀表如SYS_KSDMK科室代码库、SYS_ZGDMK职工代码库表面是组织架构管理实则是全系统权限控制的物理载体。卫宁采用“科室-病区-岗位-角色”四级权限模型所有业务表的查询都隐含科室过滤条件。例如查询CPOE_RIS_BRJCSQD病人检查申请单时实际SQL必然包含SELECT * FROM CPOE_RIS_BRJCSQD t JOIN SYS_KSDMK k ON t.APPLY_DEPT_ID k.DEPT_ID WHERE k.HOSPITAL_ID ? AND k.IS_ACTIVE 1;这里的HOSPITAL_ID不是常量而是从当前登录用户SYS_ZGDMK.USER_ID反查其所属医院ID。这意味着同一张检查申请单在心内科医生界面看到的是“待审核”状态在检验科界面自动变为“待处理”状态——状态感知由数据关联实现而非前端硬编码。毕设若想体现深度一定要在权限模块演示当切换登录用户如从医生切到药剂师同一张CPOE_XCFK小处方库列表如何动态过滤出仅该角色有权开具的药品。2.4 财务与医保域收费逻辑藏在“对应库”里不是简单关联卫宁的收费设计最易被误解为“PUB_SFDXMK CPOE_YZDJK JOIN就行”。真相是所有计费规则都沉淀在“对应库”DYK后缀中这是为应对医保政策高频变动预留的弹性层。典型代表是PUB_YBYPBXBLDYK医保药品报销比例对应库CREATE TABLE PUB_YBYPBXBLDYK ( YB_POLICY_ID VARCHAR(20) NOT NULL COMMENT 医保政策ID如BJ2023YB, DRUG_CODE VARCHAR(20) NOT NULL COMMENT 药品编码, REIMBURSE_RATE DECIMAL(5,2) NOT NULL COMMENT 报销比例%, COVERAGE_SCOPE VARCHAR(50) COMMENT 覆盖范围门诊/住院/特病, EFFECTIVE_DATE DATE NOT NULL COMMENT 生效日期, EXPIRE_DATE DATE COMMENT 失效日期, PRIMARY KEY (YB_POLICY_ID, DRUG_CODE, EFFECTIVE_DATE) );注意EFFECTIVE_DATE和EXPIRE_DATE构成时间区间而非单个时间点。当医生开药时系统不是查“当前医保政策”而是查WHERE YB_POLICY_ID ? AND DRUG_CODE ? AND ? BETWEEN EFFECTIVE_DATE AND EXPIRE_DATE。这样2024年1月1日上线新政策只需INSERT新记录旧记录自动失效历史结算不受影响。这是医疗信息化领域“时间旅行式数据管理”的标准实践。3. 关键模块实现从表结构到业务闭环的落地细节光看表名是纸上谈兵真正交付要看模块如何用这些表串起完整业务链。下面以手术管理和医嘱闭环两个高频答辩考点为例给出可直接抄作业的实现逻辑和代码片段。3.1 手术管理模块四张表撑起一个高风险业务闭环手术是医疗安全红线卫宁用CPOE_SSJLMB手术记录模板、CPOE_SSBFZDMK手术并发症代码库、CPOE_SSXY手术协议、CPOE_SSXYMB手术协议模板四张表构建强管控流程。其核心是模板驱动并发症预置协议绑定三位一体。手术记录模板CPOE_SSJLMB不是自由文本而是结构化字段组合-- 示例阑尾切除术模板 INSERT INTO CPOE_SSJLMB (TEMPLATE_ID, TEMPLATE_NAME, SURGERY_TYPE, IS_STANDARD) VALUES (APPENDIX_REMOVAL, 阑尾切除术, ABDOMINAL, 1); -- 模板明细每个字段对应一个可填项 INSERT INTO CPOE_SSJLMBMX (TEMPLATE_ID, FIELD_SEQ, FIELD_NAME, FIELD_TYPE, IS_REQUIRED) VALUES (APPENDIX_REMOVAL, 1, 手术开始时间, DATETIME, 1), (APPENDIX_REMOVAL, 2, 麻醉方式, SELECT, 1), (APPENDIX_REMOVAL, 3, 术中出血量(ml), NUMBER, 1), (APPENDIX_REMOVAL, 4, 切除阑尾长度(cm), NUMBER, 0); -- 非必填但结构化设计说明FIELD_TYPESELECT的字段其下拉选项来自PUB_SSMZK手术麻醉库确保术语统一IS_REQUIRED1的字段在前端强制校验避免护士漏填关键项。学生毕设若做手术模块必须演示选择“阑尾切除术”模板后界面自动渲染这4个字段且“麻醉方式”下拉框内容实时从PUB_SSMZK加载。手术并发症预置CPOE_SSBFZDMK是风险防控的关键。它不依赖医生事后填报而是在术前就关联高风险项-- 为阑尾切除术预置常见并发症 INSERT INTO CPOE_SSBFZDMK (SURGERY_TEMPLATE_ID, COMPLICATION_CODE, SEVERITY_LEVEL, IS_DEFAULT_CHECKED) VALUES (APPENDIX_REMOVAL, S001, HIGH, 1), -- 切口感染 (APPENDIX_REMOVAL, S002, MEDIUM, 1), -- 腹腔脓肿 (APPENDIX_REMOVAL, S005, LOW, 0); -- 肠梗阻低概率不默认勾选实现效果手术记录保存时系统自动检查CPOE_SSJLMBMX中是否填写了COMPLICATION_CODES001对应的处理措施如“术后使用抗生素”。若未填且IS_DEFAULT_CHECKED1则拦截提交并提示“高风险并发症‘切口感染’未制定预防措施请补充”。这就是用数据结构实现质控。3.2 医嘱闭环模块从开立到执行的七步状态机医嘱不是“医生开完就结束”卫宁用状态机确保每一步可追溯。以CPOE_YZDJK医嘱单据为核心串联7张关联表步骤状态码触发表关键校验逻辑1. 开立0→1CPOE_YZDJK校验药品库存JOIN PUB_YPKCK、医保适应症JOIN PUB_YBZDYSZ2. 审核1→2CPOE_YZSHJL审核人必须是主治医师以上JOIN SYS_ZGDMK.ZC_LEVEL≥ATTENDING3. 分配2→2CPOE_YZFPJL自动分配给责任护士按PATIENT_ID关联CPOE_HZRYJL住院人员记录4. 执行2→3CPOE_YZSPJL执行时间必须在医嘱时效内EXECUTE_TIME YZDJK.EXPIRE_TIME5. 补录3→3CPOE_YZBCJL允许补录执行但需填写原因如“护士交接班遗漏”6. 停止3→4CPOE_YZTZJL停止原因必须从PUB_YZTZYYK医嘱停止原因库选择7. 完成3→9CPOE_YZWCJL累计执行量医嘱总量校验CPOE_YZYLKZXXK.TOTAL_DOSE关键代码状态变更的原子性保障-- 伪代码执行医嘱的事务逻辑 BEGIN TRANSACTION; -- 1. 更新医嘱状态 UPDATE CPOE_YZDJK SET ORDER_STATUS 3, LAST_UPDATE_TIME NOW() WHERE ORDER_ID ? AND ORDER_STATUS 2; -- 2. 插入执行记录 INSERT INTO CPOE_YZSPJL (ORDER_ID, EXECUTOR_ID, EXECUTE_TIME, DEVICE_ID) VALUES (?, ?, NOW(), ?); -- 3. 校验执行量关键 SET executed (SELECT SUM(ACTUAL_DOSE) FROM CPOE_YZSPJL WHERE ORDER_ID ?); SET total (SELECT TOTAL_DOSE FROM CPOE_YZYLKZXXK WHERE ORDER_ID ?); IF executed total THEN UPDATE CPOE_YZDJK SET ORDER_STATUS 9 WHERE ORDER_ID ?; END IF; COMMIT;血泪经验很多学生在毕设里用简单UPDATE更新状态导致“执行多次后状态卡在3永远变不成9”。必须用事务校验逻辑否则无法满足三级医院评审的“医嘱闭环率≥95%”指标。3.3 皮试药品管理用“对应库”解决临床模糊需求门诊输液前需皮试但哪些药要皮试不同医院政策不同。卫宁用OUTP_PSYPDYK皮试药品对应库解耦业务规则CREATE TABLE OUTP_PSYPDYK ( DRUG_CODE VARCHAR(20) NOT NULL COMMENT 药品编码, PSY_METHOD VARCHAR(20) NOT NULL COMMENT 皮试方法INTRADERMAL/SC/IV, PSY_WAIT_MIN INT NOT NULL COMMENT 观察等待分钟数, PSY_RESULT_POS VARCHAR(100) COMMENT 阳性判断标准红晕直径1cm, HOSPITAL_ID VARCHAR(20) COMMENT 适用医院ID为空则全局适用, PRIMARY KEY (DRUG_CODE, PSY_METHOD) );场景还原当医生在OUTP_MZYZPCK门诊医嘱频次库中选择“青霉素钠”时系统自动JOIN此表若查到PSY_METHODINTRADERMAL且PSY_WAIT_MIN20则前端强制弹窗“请安排患者皮试20分钟后判读结果”若HOSPITAL_IDHOS_A则仅该院医生看到此提示其他医院医生无此限制若某药未在此表中则默认不需皮试。这种设计让“临床规范”变成可配置的数据而非写死的代码。毕设答辩时展示“修改青霉素皮试等待时间从20分钟改为30分钟只需UPDATE一条记录”比讲“我用了SpringBoot”更有说服力。4. 常见问题排查学生毕设和现场实施最易翻车的5个点别等答辩被问住才后悔这5个坑我带过的团队全踩过现在整理成“现象→原因→解决”三步法照着查10分钟定位问题。4.1 现象医嘱开出来药房查不到库存但PUB_YPKCK里明明有货原因药品库存表PUB_YPKCK的STOCK_TYPE字段值为PHARMACY药房库存而医嘱开立时关联的是WARD病区库存或EMERGENCY急诊库存。卫宁严格区分库存类型不同科室调用不同库存池。解决检查CPOE_YZDJK中的STOCK_POOL_ID字段确认其值与PUB_YPKCK.STOCK_TYPE匹配若需跨池调拨必须走CPOE_KCDBJL库存调拨记录流程不能直接UPDATE库存。4.2 现象ICD10诊断代码在医生工作站能搜到但在统计报表里不显示原因PUB_ICD10表中VALID_FLAG0已停用的编码前端搜索时未过滤但报表引擎SQL加了WHERE VALID_FLAG1。更隐蔽的是VERSION_NO不一致——医生用的是2022V1版报表跑的是2023V1版。解决统一所有业务模块的VERSION_NO参数建议在系统配置表SYS_CONFIG中设置ICD_VERSION2023V1所有查询强制AND VERSION_NO (SELECT CONFIG_VALUE FROM SYS_CONFIG WHERE CONFIG_KEYICD_VERSION)。4.3 现象手术记录保存成功但并发症上报模块没收到数据原因CPOE_SSBFZDMK手术并发症代码库中的COMPLICATION_CODE与CPOE_SSJLMBMX手术记录模板明细的FIELD_NAME不一致。例如模板里字段叫INCISION_INFECTION但并发症库中代码是S001缺少映射关系表CPOE_SSBFZDYK手术并发症对应库。解决必须存在CPOE_SSBFZDYK表其结构为(TEMPLATE_ID, COMPLICATION_CODE, FIELD_NAME)用于建立模板字段与并发症代码的绑定。缺失此表系统无法自动提取并发症数据。4.4 现象医保结算时同一药品在门诊和住院报销比例不同原因PUB_YBYPBXBLDYK医保药品报销比例对应库中COVERAGE_SCOPE字段值错误。门诊应为OUTPATIENT住院应为INPATIENT但误填为OP/IP或空值导致医保引擎无法匹配。解决检查该表所有记录的COVERAGE_SCOPE确保值为枚举值OUTPATIENT,INPATIENT,SPECIAL_DISEASE增加数据库CHECK约束CHECK (COVERAGE_SCOPE IN (OUTPATIENT,INPATIENT,SPECIAL_DISEASE))。4.5 现象小处方CPOE_XCFK打印出来药品规格显示为“NULL”原因CPOE_XCFK表中DRUG_SPEC字段为空但未关联PUB_YPKCK药品库存库获取规格。卫宁设计中小处方只存药品编码DRUG_CODE规格、单位等信息需实时JOIN获取。解决打印SQL必须LEFT JOINPUB_YPKCKSELECT x.DRUG_CODE, k.DRUG_SPEC, k.PACK_UNIT FROM CPOE_XCFK x LEFT JOIN PUB_YPKCK k ON x.DRUG_CODE k.DRUG_CODE AND k.STOCK_TYPE PHARMACY;注意k.STOCK_TYPE PHARMACY确保取药房规格而非病区规格二者可能不同。5. 毕设/课设验收与答辩用“三张表一个流程”证明你真懂卫宁EMR答辩不是背概念是证明你能用这套表结构解决真实问题。我带过的学生凡用以下方法准备100%一次性通过。核心就一句话把文档里的表变成你系统里可运行、可演示、可解释的活数据。5.1 验收第一步必须跑通“门诊开药→药房发药→医保结算”最小闭环不要一上来就炫800张表聚焦3张核心表做出可交互Demo输入在模拟医生工作站界面选择药品“阿莫西林胶囊”开立1盒频次“每日3次”用法“口服”中间系统自动JOINPUB_YPFLK确认该药属于“抗生素”触发皮试提醒JOINPUB_YBYPBXBLDYK查得报销比例80%计算自费金额INSERT到CPOE_XCFK小处方库和CPOE_XCFMXK小处方明细输出在药房界面输入处方号显示“阿莫西林胶囊规格0.25g*24粒/盒库存15盒可发药”点击“发药”后PUB_YPKCK库存减1CPOE_XCFMXK.STATUS变为DISPENSED。关键验收点展示CPOE_XCFK中DRUG_CODEAMOXICILLIN的记录展示PUB_YPKCK中同一DRUG_CODE的STOCK_QUANTITY从15变为14展示PUB_YBYPBXBLDYK中DRUG_CODEAMOXICILLIN的REIMBURSE_RATE80.00这三张表的数据联动就是你吃透卫宁EMR的铁证。5.2 答辩第二步用ER图讲清“为什么需要这张表”而不是“这张表有什么字段”导师最反感学生照念文档“PUB_SFDXMK有12个字段主键是SFDX_ID…”。要改成“老师我选PUB_SFDXMK收费大项目库是因为它解决了医保结算的项目归集难题——比如‘CT平扫’和‘CT增强’在临床是两个操作但医保要求合并为‘CT检查’一个大类报销。所以这张表用SFDX_ID作为大类编码SUB_ITEM_ID作为子项编码IS_GROUP_HEAD1标识大类这样结算引擎就能SUM所有子项费用再按大类规则报销。”推荐画图用Visio或draw.io画一张聚焦业务痛点的ER图只放4张表PUB_SFDXMK大类PUB_SFXMLBK类别CPOE_YZDJK医嘱CPOE_YZDYSZ_EX医嘱对应设置在CPOE_YZDJK到PUB_SFDXMK的连线上标注“医保结算时按此关联聚合费用”在CPOE_YZDYSZ_EX旁加注释“此处配置‘CT增强’→‘CT检查’的映射支持政策灵活调整”。图越小重点越突出。5.3 答辩第三步准备一个“如果…会怎样”的深度问题提前预判导师可能问的刁钻问题并用表结构回答。例如问“如果医保突然新增一条规则要求所有抗生素处方必须关联细菌培养结果你们系统怎么快速响应”答打开CPOE_YZDJK表结构“我们会在CPOE_YZDJK中增加IS_ANTIBIOTIC_CHECKED CHAR(1)字段默认0同时建表CPOE_YZ_JUNXIAN_CHECK细菌培养检查记录关联ORDER_ID。当医生开抗生素时系统校验IS_ANTIBIOTIC_CHECKED1否则拦截。所有改动仅涉及1个字段1张新表无需重构医嘱主流程——这正是卫宁用‘对应库’和‘状态字段’解耦业务的设计思想。”这种回答把文档从“静态字典”升维成“动态架构”导师立刻明白你不是抄的。从那以后我每次带学生做医疗信息系统毕设都强制他们先用Excel把PUB_ICD10、CPOE_YZDJK、PUB_SFDXMK三张表的字段、主外键、业务含义抄一遍再动手写代码。抄的过程会发现ICD10_CODE的长度是10但PUB_ZDDMK诊断代码库里却是15——原来后者兼容ICD9和中医证候编码。这种细节才是答辩时让导师眼睛一亮的“真功夫”。希望帮到你。本文还有配套的精品资源点击获取
