卫宁电子病历表结构解析：从数据库设计到医疗信息化落地-北京尧图网络

简介《卫宁电子病历表结构》是上海金仕达卫宁软件临床信息系统数据库结构设计说明书面向医院信息化实施、EMR 二次开发及数据对接人员用于厘清电子病历系统各表的关系与字段含义。文档覆盖系统框架、基础代码库、财务收费、医疗信息、数据标准化和权限安全设计正文按职工代码库、医疗项目库、药品分类库、科室/病区代码库、凭证类型库、收费项目类别库、医保分类库、诊断代码库等模块展开对 800 多张表逐表列出表说明、字段定义、类型、长度、备注和值域可作为数据字典直接查阅。包体为单个 Word 文档压缩包约 13.92MB目录层级清晰便于按模块检索和复制。目前已有 1547 人学习适合在系统集成、报表开发、数据迁移或接口联调时作为权威字段参考。1. 卫宁电子病历表结构一份藏在DOC里的医院数据地图我拿到这份《卫宁电子病历表结构.doc》时第一反应是“又是那种几百页没人看的说明书”。但翻到目录页就改了判断——这不是概述文档而是一份包含800多张表、几十个基础代码库和完整CPOE医生医嘱录入模块字段定义的数据库结构说明书覆盖从职工代码库、医疗项目库到检查申请单、手术医嘱、血库审核流程的全部表结构。对医疗信息化从业者来说它相当于一张可以直接对着建库、做接口、跑数据迁移的底图。无论你是EMR实施工程师、集成平台开发还是做医院数据仓库的BI工程师这份表结构文档都能帮你少走至少两个月的弯路——前提是你得知道怎么读它。2. 基础框架库与主数据表先理清医院信息系统的“底盘”再谈业务2.1 系统框架库的整体分类与命名规律整份文档的第一部分标着“系统框架”列出的是整张底图的基础层。我把它挑出来单独说是因为在HIS/EMR这类系统里主数据表的字段设计直接决定后续业务表能怎么关联。先把框架库按用途分成四类类别代表库用途人员与组织SYS_ZGDMK 职工代码库、SYS_KSDMK 科室代码库、SYS_BQDMK 病区代码库员工、科室、病区的编码与层级医疗主数据PUB_YLXMK 医疗项目库、PUB_YPFLK 药品分类库、PUB_ZDDMK 诊断代码库、PUB_ICD9 / PUB_ICD10项目、药品、诊断的字典与编码财务与收费PUB_PZLXK 凭证类型库、PUB_SFDXMK 收费大项目库、PUB_SFXMLBK 收费项目类别库、PUB_YBFLK 医保分类库计费分类、医保对码对照关系PUB_KSYFDYK 科室药房对应、PUB_KSBQDYK 科室病区对应、PUB_MZSFZXKSK 门诊收费执行科室对应多对多关系映射命名上有一套规律前缀“SYS_”表示系统级数据“PUB_”表示公共数据“CPOE_”属于医生工作站业务模块“OUTP_”走门诊这在第3章会展开。看到表名基本就能定位它的角色这是拆这套库最省力的方式。2.2 职工代码库与科室病区代码库组织架构怎么落到字段上以SYS_ZGDMK职工代码库为例这类表的字段设计思路通常包含职工编码主键、姓名、所属科室编码、职称编码、执业类型、在职状态、登录账号等。“职称编码库”PUB_ZCBMK和“科室代码库”SYS_KSDMK在中间起着关联作用——职工表通过科室编码指向科室代码库通过职称编码指向职称编码库从而实现“某个医生属于某个科室、具备某种职称”的查询路径。做集成时常见做法是把SYS_ZGDMK作为人员主索引通过唯一职工编码对外提供人员信息科室代码库则维护科室的层级关系比如一级科室、二级科室分别对应PUB_YJKSK和PUB_EJKSK。科室与病区的对应关系比较隐蔽。SYS_KSDMK管科室、SYS_BQDMK管病区但它们不是一对一。实际住院业务中一个科室可能分布在多个病区一个病区也可能收治不同科室的病人所以单独的“科室病区对应库”PUB_KSBQDYK就是用来维护这种多对多关系的。在写住院医嘱或病人入区接口时不能直接拿科室编码去反查病区编码要先查对应库否则就会出现“医生下了医嘱但护士站看不到”这类经典问题。2.3 药品与收费项目的关联为什么收费老对不上账药品主数据这一块PUB_YPFLK药品分类库管分类层级PUB_YFDMK药房代码库管各药房门诊药房、住院药房、急诊药房的编码剂型用PUB_YPJXK药品剂型库。但真正容易踩坑的是药品和收费项目之间的关系。文档里专门列了PUB_LCSFXMDYK“临床收费项目对应库”说明一个药品或诊疗项目在开单时需要通过对应库找到匹配的临床收费项目再关联到PUB_SFDXMK收费大项目库去做财务分类。我见过不少对账差异来自这个环节医嘱用的是医疗项目编码计费走的是收费小项目编码中间少了对应关系或对应关系配错导致临床开的药和财务记的账各说各话。所以对接计费接口时最关键的不是把项目编码传过去而是要确认“医嘱项目→临床收费项目→收费大项目”这条链路在对应库里是否配齐。检查方法很直接拿PUB_YLXMK里的项目编码去关联PUB_LCSFXMDYK看能否匹配到唯一的收费项目再把收费项目挂到正确的收费类别下。2.4 诊断代码库与医保分类库编码标准怎么影响今天的对接诊断代码库分了PUB_ZDDMK、PUB_ICD9、PUB_ICD10三套。起初我有点疑惑既然有了PUB_ZDDMK为什么还要单列ICD9和ICD10拆到字段层面就明白了——PUB_ZDDMK更像是医院内部维护的诊断字典包含医院自定义的诊断名称和内部编码PUB_ICD9和PUB_ICD10则按国家标准编码组织一个对应ICD-9一个对应ICD-10用于病历首页上报和医保结算。实际操作中内部诊断编码要和ICD编码建立映射关系映射不全会直接影响病案首页的质控和DRG入组。医保分类库PUB_YBFLK则是收费侧的关键。它维护医保类别甲类、乙类、自费等、报销比例等信息和收费项目本身是分开维护的。在住院结算、门诊收费等场景中计费程序先按收费项目查到医保分类再按分类去套报销比例。若同一收费项目在不同医保目录下报销比例不同往往需要再加一层“医保项目对应库”CPOE_YBXMDYK来维护项目与医保目录的映射而不是直接改收费标准。这就是表结构文档的价值——它告诉你在哪个环节做什么事而不是让你绕路改错表。3. 医生工作站CPOE核心表医嘱、检查申请、手术、输血数据怎么串起来3.1 CPOE表族的功能划分从医嘱录入到执行回传系统框架只是地基医生工作站才是每天被点得最多的模块。文档第二部分以“CPOE_”开头列出了60多张表覆盖了从医生开立医嘱到处方打印的全流程。我按业务流把它们分成五组分组代表表承担的业务医嘱主数据CPOE_TEXTORDER文字医嘱库、CPOE_WZYZK文字医嘱库、CPOE_YZLXK医嘱类型库医嘱内容与分类频次用法CPOE_YZYPPCK医嘱药品频次库、CPOE_YZYPYFK医嘱药品用法库、OUTP_MZYZPCK门诊医嘱频次、OUTP_MZYZYFK门诊医嘱用法给药频次、用药方式申请单CPOE_RIS_BRJCSQD病人检查申请单、CPOE_RIS_BRJCSQDMX检查申请单明细、CPOE_RIS_SQDMBK检验申请单模板库检查检验申请手术输血CPOE_SSYZK手术医嘱库、CPOE_SSJLMB手术记录模板、CPOE_SSXYMB手术协议模板、CPOE_XKSHLCK血库审核流程库围手术期与输血管理医生排班CPOE_YSPBK医生排版、CPOE_YSPBMXK医生排班记录明细表排班与工作量统计其中CPOE_TEXTORDER文字医嘱库是整个流程的起点。它存的是医生录入的医嘱原文常见字段包括医嘱编号、病人ID、医嘱内容、开立医生、开立时间、医嘱状态新开/停止/作废、长期或临时标识等。它和CPOE_WZYZK的功能有重叠——后者更像是历史归档或未结构化医嘱的存放位置。对接外部系统时优先以CPOE_TEXTORDER为主。3.2 频次与用法给药时间是怎么算出来的医嘱要能正确执行依赖“频次”和“用法”两个字典。CPOE_YZYPPCK医嘱药品频次库维护的是类似“每日一次”“每8小时一次”“必要时”等频次定义字段中通常包含频次编码、频次名称、每日执行次数、间隔小时数、是否长期医嘱默认值等。CPOE_YZYPYFK医嘱药品用法库则管“口服”“静脉滴注”“肌肉注射”“外用”这类给药途径以及稀释液、滴速、使用注意事项。在护理执行和药房发药的场景中频次和用法直接决定摆药单、执行单怎么生成。之前我在实施项目中发现过一类问题频次库里的“每日三次”没有维护间隔小时数或者“用药时间点”只能在固定时刻执行如8:00、12:00、16:00而药房摆药按的是间隔小时数两边算法不一致导致本该同时执行的医嘱分成了不同的执行批次。这类问题查到最后往往不是程序Bug而是频次库的字段没配全或两边用的字段不是同一套。3.3 检查申请单从申请到报告的状态流转CPOE_RIS_BRJCSQD病人检查申请单和CPOE_RIS_BRJCSQDMX检查申请单明细是一对主从表。头表存申请单号、病人ID、申请科室、申请医生、申请时间、检查类别放射、超声、内镜等、当前状态明细表存具体项目比如检查部位、检查方法、临床诊断、特殊要求。之所以拆两张表是因为一次申请可能包含多个检查部位拆开便于按明细计费和分派给不同检查科室。申请单状态字段是整个流转的核心。常见的状态包括已申请、已预约、已执行、已报告、已取消。我把这个状态理解为一条链申请提交后转预约检查科室登记执行医生写完报告后状态置为“已报告”临床医生在医生工作站里就能看到报告结论。集成平台在做申请单推送时最容易漏掉的是“取消申请”这个动作——病人没来做检查护士在登记处取消了申请但检查科室的系统没收到取消消息导致报告一直挂着“未完成”月末统计时就会平白多出一堆未关闭申请单。3.4 手术医嘱与血库审核围手术期管理里最绕的几张表手术相关表在文档里占了很大篇幅CPOE_SSYZK手术医嘱库、CPOE_SSJLMB手术记录模板、CPOE_SSXYMB手术协议模板、CPOE_SSBWK手术部位库、CPOE_SSMZK手术麻醉库、CPOE_SSLB手术类别库。以CPOE_SSYZK为例它需要记录病人基本信息、预手术时间、实际手术时间、手术等级参考PUB_SSDJDMK、切口等级参考PUB_QKDJK、手术诊断参考PUB_SSZDK、手术部位、麻醉方式、术者、助手等。手术协议表的用途是存病人或家属的知情同意书内容及其签署状态这个字段在电子签名对接时是必查项。输血管理看CPOE_XKSHLCK血库审核流程库。它的核心是审核步骤与角色申请输血后医生开申请、科室主任审核、血库交叉配血、发血、护士执行、事后评价每一步都有对应的状态记录。文档里还列出了CPOE_XKSHJSK血库审核角色库和CPOE_XKSHMXK血库审核明细库前者定义谁能审、后者记录每一步的审核时间和意见。做输血闭环的项目需要把输血申请单与发血记录、执行记录串起来并且每一步的状态变化都要留痕——而这张流程库就是状态机的定义来源。3.5 小处方与医生排版两个容易被忽略但实用的表小处方库CPOE_XCFK和它的明细表CPOE_XCFMXK名气不大但在门诊场景中很实用。小处方一般指手写或简化录入的处方不走完整医嘱流程适合急诊、简易门诊这类快速开方场景。它的表结构与正式处方类似包含处方号、处方类型、开方医生、开方时间、药品编码、药品名称、规格、数量、用法、频次、用量等字段但状态流转比正式医嘱简单。做电子处方流转或处方点评时不能只盯CPOE_TEXTORDER小处方数据也是处方点评的重要来源漏了它统计就会不准。CPOE_YSPBK医生排版和CPOE_YSPBMXK医生排班记录明细表是管医生排班的。前者保存排班主记录后者保存每天的具体坐诊或值班安排。对门诊预约系统和号源管理来说这两张表是号源分配的数据来源。当时做预约挂号对接时发现排班明细与医生出诊状态不同步早上的号放出去了下午医生临时停诊预约平台没有及时关停号源导致患者到了现场才发现停诊——这些问题都要回到排班表的状态字段上去排查。4. 字段设计与关联关系把800张表变成可查询的ER视图4.1 字段命名的通用约定与值域风格读这份表结构文档读久了会发现字段命名有一定规律。以“编码”类字段为例常见字段名包括DM代码、MC名称、PYM拼音码、WBZM五笔字码等缩写以“时间”类字段为例常见的有JLSJ记录时间、KSSJ开始时间、JSSJ结束时间、SJC (时间戳)等金额类字段多与JE金额、FYJE费用金额、ZFJE自付金额相关。这些缩写不是这份文档独有的而是国内HIS厂商继承了同一套命名风格。做数据抽取时如果源库没有提供中文字段对照先按这些缩写猜再去查具体说明效率会高很多。值域字段——就是文档摘要里说的“字段的备注和值域”——是这份文档的另一核心价值。许多表的“状态”字段并不会直接用中文存“已提交”“已审核”这样的值而是用一个数字或字符表示比如0代表未提交、1代表已提交、2代表已审核、9代表已作废。如果文档里没有列值域看到状态字段等于盲猜。以前对接某跨平台系统时就遇到过对方把“1”当成有效状态、而我们系统里“1”代表已作废的情况查了半天才发现是值域没对齐。4.2 主外键关系医嘱表到执行记录是怎么连起来的看完整份目录最值得做的事就是把业务主链路的主外键关系先画出来。以住院医嘱为例一条典型的链路是病人入区SYS_BQDMK维护病区 → 医生开医嘱CPOE_TEXTORDER记录病人ID、医嘱内容、频次、用法 → 药房摆药通过药品编码关联PUB_YLXMK和PUB_YFDMK → 护士执行执行记录通过医嘱号回指CPOE_TEXTORDER → 费用生成通过临床收费项目对应库PUB_LCSFXMDYK关联收费项目也就是说医嘱表是这一整条链的源头其他表靠“医嘱号”或“病人ID”与它关联。但采购或实施时的常见问题是医嘱表里同一个医嘱号对应多行明细一组医嘱包含多条药品或项目如果下游系统没有处理好这个一对多关系直接按医嘱号汇总费用就会翻倍。所以我在做接口测试时都会加一个校验统计每条医嘱对应的费用明细数是否与医嘱明细行数一致。4.3 门诊与住院的差异为什么有些表要单独建文档里出现了OUTP_门诊和CPOE_住院医生站两套频次、用法表比如OUTP_MZYZPCK门诊医嘱频次和CPOE_YZYPPCK医嘱药品频次库并存。这说明门诊和住院的医嘱节奏本质上不一样门诊以“几天量”为单位频次更多是“每日一次、每次一片”住院以“长期医嘱临时医嘱”为单位频次要精确到给药间隔和执行批次。做门诊处方接口时直接去读住院的频次表会出现很多不适用的情况。我一般会在做接口映射前先按门诊、住院分开梳理字典表而不是统一走一套配置。4.4 多对多关系科室、病区、药房之间的各种对应表文档中有大量“对应库”其实就是在维护多对多关系PUB_KSYFDYK科室药房对应、PUB_KSBQDYK科室病区对应、PUB_MZSFZXKSK收费执行科室对应、PUB_ZYSFZXKSK住院收费执行科室对应、PUB_LCSFXMDYK临床收费项目对应库、CPOE_YPYFDYK药品用法对应库等。多对多表在数据库设计中一般包含两个外键加生效时间、失效时间、备注等附加字段。比如科室药房对应表一个科室对应多个药房门诊药房、急诊药房、住院药房一个药房服务多个科室中间表就是做这个约束的。做主数据治理时这类对应表的变更管理很关键——改药房和科室的对应关系前要评估是否有未执行的医嘱或未结算的费用挂在这些映射上否则改了对应关系存量数据就找不到归属了。5. 排查与避坑拆这份表结构文档时最容易翻车的五个地方5.1 把DOC格式当成普通Word直接处理现象是python-docx打开文件报错显示“文件已损坏”或格式不兼容——原因是这份文档是.doc后缀的旧版二进制格式python-docx只支持.docx解决方法是先做一次格式转换用LibreOffice命令行将.doc转成.docx或转成HTML后解析soffice --headless --convert-to docx 卫宁电子病历表结构.doc --outdir ./converted然后写脚本批量提取目录和字段定义行。我一般还会转一份HTML方便用BeautifulSoup直接抓表格行再把字段名和说明落成CSV。5.2 字段说明不全就盲目建表现象是建好的表结构和实际数据对不上比如某个字段在文档里写了长度但库里存了更长的值——原因是文档只标注了常见长度没有针对每个值域给出完整校验规则解决方法是把文档当“设计基线”而不是“物理建库脚本”建表前先找一份对应版本的真实库做字段级Diff把多出来的字段、改过的类型、新增的状态值都记录在案。5.3 状态值域没有列全导致接口数据解析错乱现象是对方传过来的状态值和文档里对不上比如“已取消”在文档里是4实际数据是5——原因是版本迭代过程中新增了状态值但文档没有更新解决方法是先统计实际数据里所有出现的状态值再回填到字典表里同时把“未知状态”也纳入处理逻辑不要写死只能处理已知值域。5.4 把CPOE_TEXTORDER当成唯一医嘱来源导致漏数现象是统计出来的医嘱量和医生工作站界面显示的不一致——原因是小处方CPOE_XCFK、文字医嘱CPOE_WZYZK这些旁路表没纳入统计范围医嘱本身存在多张表里解决方法是先明确业务范围住院以CPOE_TEXTORDER为准门诊要合并OUTP表和CPOE_XCFK再决定取数口径同时在接口层面约定好哪些医嘱类型允许进集成平台。5.5 直接拿“拼音码”当业务主键关联现象是关联后数据大量匹配不上看起来像是脏数据——原因是拼音码不是唯一键不同读音相似或生僻字编码容易重复文档里也没有把拼音码标成主键解决方法是只用内部编码做关联条件拼音码仅作为检索提示字段不要参与表连接。遇到重码问题时先查编码规则再确认是否有独立的唯一索引。6. 进阶用法与落地验证把表结构文档变成一套可以复用的数据字典拿到这份文档最直接的进阶用法是先把800多张表的目录和字段定义整理成结构化的数据字典做法是写一个解析脚本把目录和每个表的字段说明提取成统一格式的元数据表表名、字段名、字段类型、长度、必填、主键、值域、备注。之后不管是写SQL还是做接口都能直接查这份字典而不是反复翻原始DOC。我通常还会把这份元数据导入数据库建一张数据字典总表用于做字段级联查。比如要查“所有和频次相关的表”直接按字段名模糊匹配就能列出来。在项目交付时这份字典也是给信息科做运维培训的底稿减少“这个字段是什么意思”的沟通成本。验证这份文档是否适用于当前环境的方法是选三组关键业务做闭环测试。第一组是门诊处方从开方、收费、发药到退费全程跟踪处方号在CPOE_XCFK和收费表中的流转状态第二组是住院医嘱从开立、审核、摆药、执行到计费确认每条医嘱的费用明细都能追溯到开立记录第三组是检查申请从申请、预约、登记、执行到报告确认状态字段的每一次变化都有时间戳记录。三组跑通后再抽查一周的真实业务数据按“数据完整性、状态合法性、金额一致性”三个维度做计数核对。我自己的习惯是每到一个新项目第一周不写业务代码先把数据字典建好、把主链条的表关系画清楚再动手做接口。磨刀不误砍柴工这套流程省下来的排查时间远比投入多。当初拆完这份卫宁电子病历表结构最大的收获不是记住了多少张表名而是掌握了一套“先找主链路、再查对应关系、最后对值域”的拆库方法。希望帮到你。本文还有配套的精品资源点击获取

卫宁电子病历表结构解析：从数据库设计到医疗信息化落地

相关推荐

smol developer 全程序生成实战：从 shared_deps.md 共享依赖契约解读 AI 生成的 Pong 游戏架构

Apache OpenDAL 接入 MongoDB GridFS：从配置到源码级的完整实战指南

AI生成HTML课件如何转成可编辑PPTX？语义解析与版式重建实战

更多资讯

airllm逐层加载实战：4GB显存如何跑70B大模型

YOLO26算法城市街道背包手提包纸袋行人目标检测+训练好的模型+9130张数据集+pyqt可视化界面

动态多Agent工作流公测体验：架构拆解与压测实战

线束工厂100问｜端子采购需要核对哪些关键参数，避免来料不匹配？

小说一键成片：开源AI工具如何用大模型重构短剧生产链

NSGAII多目标优化在综合能源系统调度中的Matlab实现与调参实践

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？