简介《卫宁电子病历表结构》是一份医疗机构信息化场景下的EMR数据库结构设计说明书面向医院信息科、HIT开发人员及医疗大数据研究者用于梳理电子病历系统中800多张业务表及其字段定义。资源以单一DOC文件打包共1个文件体积13.92MB内容采用分模块呈现从系统框架职工代码库、科室代码库、医疗项目库等到财务收费凭证类型库、收费大项目库、医保分类库等再到诊断代码库、职称编码库等核心医疗信息库并兼顾数据标准化、互操作性与安全保密设计。目前已有1541人浏览学习适合需要深入掌握卫宁EMR底层表结构、进行院内系统接口开发或数据抽取分析的技术人员。阅读后可以快速定位各表的说明、字段类型、长度及值域定义为医院信息化建设、系统优化和二次开发提供直接参考。1. 卫宁电子病历表结构文档一份能少走半年弯路的 800 张表索引拿到卫宁电子病历表结构这份资料的第一感觉是朴素没有花哨的架构图开头就是目录从系统框架的 45 个基础库一路列到医生工作站的 63 张业务表再展开就是 800 多张表的完整表结构说明。它不是操作手册而是一张可以直接照着查的数据字典。对经常跟卫宁 HIS/EMR 打交道的工程师来说这份 doc 能解决的大问题只有一个遇到业务数据对不上或者要写报表时不用再靠猜表名来反查顺着目录就能定位某条数据落在哪张表、字段叫什么、值域是什么。适合三类人做接口对接的集成工程师、负责报表和运维的医院信息科人员、想摸清 EMR 数据模型的医疗数据从业者。下面按我实际拆解这份文档的顺序来讲。2. 拆表结构的第一件事搞懂 SYS_ / PUB_ / CPOE_ 前缀与三层命名逻辑2.1 三套前缀不是摆设主数据、公共字典、医嘱业务的边界第一次打开这份文档的人很容易被满屏的表名劝退。但这里有个非常有价值的细节卫宁并没有随意给表命名而是用固定前缀区分数据的归属层级。顺着这个规律拆800 张表会清晰很多。前缀归属层级典型代表作用SYS_全院主数据SYS_ZGDMK 职工代码库、SYS_KSDMK 科室代码库、SYS_BQDMK 病区代码库组织架构和人员信息全院共享PUB_公共字典PUB_YPFLK 药品分类库、PUB_SFDXMK 收费大项目库、PUB_YBFLK 医保分类库标准化码表被业务表引用CPOE_医生工作站业务表CPOE_YZYPPCK 医嘱药品频次库、CPOE_SSYZK 手术医嘱库医嘱、申请单、文书等业务数据OUTP_门诊专用表OUTP_MZYZPCK 门诊医嘱频次、OUTP_PSYPDYK 皮试药品对应信息门诊流程单独使用为什么要这样分层医院的信息化往往有 HIS、LIS、RIS、EMR 多个模块主数据如果不独立成表后面任何一处科室调整、人员变动都要牵连改业务表。SYS_ 开头的职工、科室、病区是全院主数据底座PUB_ 是各种可被多模块复用的字典CPOE_ 则集中存放医生工作站的业务记录。这个划分决定了数据流向业务表通过编码引用字典表字典表的变动会被业务表感知。后缀规律同样值得记。以这份目录里的表名为例K 一般指代码库或字典表比如 PUB_YPFLK 药品分类库DYK 是对应表本质是关联关系表比如 PUB_LCSFXMDYK 临床收费项目对应库MXK 是明细表比如 CPOE_XKSHMXK 血库审核明细库SZ 是设置类表比如 CPOE_SSYZK_SZ 手术医嘱设置MB 是模板表比如 CPOE_SSXYMB 手术协议模板。看到后缀表的大致功能基本能猜出来。2.2 从 PUB_YPFLK 看一张字典表的字段设计表名看懂了再看字段。这份文档的价值恰恰在于此每个表都带字段定义、字段类型、长度、备注和值域而值域是实施时最容易漏掉的部分。以 PUB_YPFLK 药品分类库为例这类字典表在这个版本里通常包含这些字段字段类型长度说明YPFLDMVARCHAR20药品分类编码主键YPFLMCVARCHAR100药品分类名称如抗菌药、心血管药SJFLDMVARCHAR20上级分类编码支持树形层级YPJXDMVARCHAR10关联药品剂型PUB_YPJXK 药品剂型库PHARMACOLOGYVARCHAR50药理分类用于科室用药管理MEMOVARCHAR200备注这里的 SJFLDM 上级分类编码字段让药品分类可以做成一棵树。树形结构解决的是统计问题医保对码、抗菌药物分级管理、药占比统计都要靠分类树的层级汇总。实施时如果只填了叶子节点而漏维护上级分类后续按大类统计药品时会直接少一块数据。这类字典表的共同用法是在收费侧药品要先在 PUB_SFXXMK 导入收费小项目库里建成收费项目再通过对应表把字典和收费项目绑定才能开得出医嘱、收得了费。所以拆表结构不能只看一张表还要看它在链路里被谁引用。2.3 ICD 双轨PUB_ICD9 与 PUB_ICD10 并存的设计意图诊断是电子病历的核心卫宁在诊断设计上留了一手PUB_ZDDMK 诊断代码库是主诊断字典同时并列存在 PUB_ICD9、PUB_ICD10 两套标准诊断代码再配合 CPOE_ZDFLK 诊断分类库和 CPOE_ZDFLMXK 诊断分类明细库。这种情况在 2014 年的版本里很常见当时正处在 ICD-9 向 ICD-10 切换的过渡期医院既有大量用 ICD-9 编码的历史病历新录入又得符合 ICD-10 要求。双轨并存的目的就是兼容老病历按 ICD-9 回填新病历按 ICD-10 录入PUB_ZDDMK 作为统一索引把两套编码都挂在本院诊断上。加上目录里还有一张 CPOE_ZDXGZ 诊断相关组表可以看作是 DRG 分组的雏形依据主要服务于病案统计和费用分析。实际使用中最常犯的错是把 ICD 标准表直接当本院诊断字典用。后果是医生录入诊断时看到的是公开标准编码回写电子病历首页时又对不上本院诊断分类换一家医院数据就乱了。正确做法是让医生从 PUB_ZDDMK 选诊断ICD 编码只作为扩展属性跟在后面这样统计口径才统一。3. 把表目录还原成业务链路从开单到收费的查表路径3.1 以收费为主线凭证、大项目、小项目的三级结构医院里问得最多的一个问题是一笔费用到底记在哪张表顺着这份文档的目录走答案很清楚。收费侧先有 PUB_PZLXK 凭证类型库定义财务凭证类型然后是 PUB_SFDXMK 收费大项目库、PUB_SFXMLBK 收费项目类别库、PUB_SFXXMK 导入收费小项目库、PUB_LCSFXMK 临床收费项目库最后是 PUB_LCSFXMDYK 临床收费项目对应库把临床项目和收费项目绑起来。这个设计可以用一句话概括大项目管归类小项目管明细对应表管绑定。门诊和住院还各有一张执行科室对应表PUB_MZSFZXKSK 门诊收费执行科室对应和 PUB_ZYSFZXKSK 住院收费执行科室对应目的就是区分一个收费项目在不同场景下由哪个科室执行。做对账或者写收入报表时这条链路是取数的主路径。我一般先按大项目编码过滤再联小项目表和对应表取明细最后限定执行科室编码三张表串起来数据基本不会跑偏。门诊开检查单的场景也是这套思路。CPOE_RIS_BRJCSQD 病人检查申请单、CPOE_RIS_BRJCSQDMX 检查申请单明细再加 CPOE_RIS_BRJCSQDFSXXK 申请单附属信息三张表构成一份完整申请单。申请单主表存单号、病人、申请科室明细表存具体项目附属信息存临床诊断等补充内容。报表里想统计「某个科室开了多少检查项目」直接从明细表按申请科室分组就可以了前提是主表里的申请科室字段维护得干净否则就容易出现单号对得上、科室对不上的情况。3.2 以药品为主线分类、药房、剂型、产地、医保五张字典药品相关的表在目录里占了很大比重但核心链路其实不复杂。PUB_YPFLK 药品分类库管分类PUB_YFDMK 药房代码库管药房PUB_KSYFDYK 科室药房对应库管科室和药房的映射PUB_YPCDMLK 导入产地目录库管药品产地PUB_YPJXK 药品剂型库管剂型PUB_YBFLK 医保分类库管医保归类。五张字典各管一段再通过若干个对应表联动起来。这里值得特别注意的是 CPOE_YPDYLDSZ 剂型对应药品联动设置这张表。它的作用是当你维护某个药品的剂型时系统自动带出一批默认用法和收费项目避免每次开医嘱都要重新选。实施经验是这张表一定要在药品字典导入前就配好否则后面每加一个药品都要手工补联动关系工作量会爆炸。与之配套的还有 CPOE_YPSYPL 药品使用频率、CPOE_YPYFDYK 药品用法对应库、CPOE_YBYPDYK 医保药品对应库这些「对应库」本质上都是中间表把药品主数据、收费、医保、用法串在一起。我们做接口的时候只需要按编码去 join 这些中间表就能拿到某个药完整的信息链路。3.3 以手术为主线从术前申请到术后记录手术这条线是外科电子病历里最长的一条链路。术前有手术协议和模板术中有手术医嘱术后有记录和随访。对应到表结构上PUB_SSDJDMK 手术等级代码库、PUB_QKDJK 切口等级代码库、PUB_SSZDK 手术诊断库、PUB_SSBWK 手术部位库、PUB_SSMZK 手术麻醉库、PUB_SSLB 手术类别库、PUB_SSKSDMK 手术科室代码库这些是术前要引用的字典表。业务表这边CPOE_SSXY 手术协议和 CPOE_SSXYMB 手术协议模板管知情同意CPOE_SSYZK 手术医嘱库管手术安排和术后医嘱CPOE_SSYZK_SZ 手术医嘱设置管手术医嘱的默认行为CPOE_SSJLMB 手术记录模板管术后文书生成CPOE_SSBFZDMK 手术并发症代码库和 CPOE_SSTSGR 手术特殊感染管术后并发症与特殊感染记录还有 CPOE_SHSFJLK 术后随访记录管术后跟踪。这些表之间一般通过手术申请单号或住院号关联。查手术数据时我习惯从 CPOE_SSYZK 入手因为它是这条链路的业务主表其他表大多以它为主表做扩展。4. 医嘱模块深挖CPOE_ 系列表的字段、值域与联动关系4.1 医嘱类型、单据与打印元素的三角关系医生工作站里最核心的数据就是医嘱而医嘱相关表在目录里占了近三十张。从命名上看它们围绕几个中心展开类型、单据、打印、频次、用法、时限和对应关系。先看医嘱类型。CPOE_YZLXK 医嘱类型库定义了医嘱的种类比如长期医嘱、临时医嘱、术后医嘱、备用医嘱。这个字段直接影响后续的执行逻辑长期医嘱每天自动滚动执行临时医嘱只执行一次。CPOE_YZDJK 医嘱单据和 CPOE_YZDJFLK 医嘱单据分类则负责把不同类型的医嘱归类到不同的单据面上。打印侧有 CPOE_YZDYSZ_EX 医嘱对应设置、CPOE_YZDYYZNR_YSK 打印元素基础数据、CPOE_YZDY_SJXZ 医嘱打印提醒时间三者共同决定医嘱单上显示什么、几点提醒打印。这个三角关系非常容易在实施时被忽略。典型场景是医嘱类型配好了但打印元素没绑导致医嘱单上只显示药品名称和频次漏掉了用法和剂量。排查方法很直接先查医嘱类型再查单据分类最后看打印元素表里有没有对应记录。三条链对齐打印出来的医嘱单才完整。4.2 频次、用法与时限三个最容易出问题的值域医嘱的频次和用法是值域问题的重灾区。CPOE_YZYPPCK 医嘱药品频次库管住院频次CPOE_YZYPYFK 医嘱药品用法库管用法OUTP_MZYZPCK 和 OUTP_MZYZYFK 则是门诊对应的两套。门诊和住院各一套的原因很简单门诊用药相对简单频次少住院用药复杂频次多拆开能各自维护而不互相干扰。频次常见的值域包括 QD每日一次、BID每日两次、TID每日三次、QID每日四次、QN每晚一次、Q6H每六小时一次、PRN必要时。如果字段里还有时间点配置那 Q6H 这类间隔频次还会拆成具体的执行时间点。用法这边常见的是口服、静滴、肌注、皮下注射、外用。真正坑人的是时限长期医嘱和临时医嘱的区分通常靠 CPOE_YZSXTJDYK 医嘱时限条件对应库来控制比如临时医嘱 24 小时内有效、术后医嘱默认执行三天。实施时改了频次表却忘了时限表就会出「医嘱还在滚动执行」的诡异现象。提示维护频次时先确认你改的是门诊表还是住院表。OUTP_ 前缀门诊和 CPOE_ 前缀住院是两套数据改错了一张表另一张完全不受影响。4.3 手术医嘱、输血与文字医嘱的特殊表手术医嘱在 CPOE_SSYZK 手术医嘱库里字段通常会包含手术编码、手术名称、手术等级、切口等级、麻醉方式、手术者、拟手术日期等CPOE_SSYZK_SZ 手术医嘱设置则负责配置手术医嘱的默认值。这里容易出问题的点是手术医嘱往往要关联手术协议、手术记录模板如果模板没配好术后文书就生成不出来。输血相关的表也很有意思。CPOE_SXZLTYS 输血治疗同意书、CPOE_SXBLFYK 输血不良反应库、CPOE_XKSHBZK 血库审核步骤库、CPOE_XKSHJSK 血库审核角色库、CPOE_XKSHLCK 血库审核流程库、CPOE_XKSHMXK 血库审核明细库。这是把输血流程拆成了步骤、角色、流程、明细四张表相当于一个可配置的审批流引擎。鼻胃管、导尿这类操作如果不想走收费项目就可以作为文字医嘱直接录入。文字医嘱的边界感很重要它不参与计价不联动库存只是让医生能把一句话写进医嘱单里。给护士执行看可以但要产生费用记录就必须走临床收费项目那条链路。5. 卫宁 EMR 实施避坑五个表结构雷区与排查思路5.1 五个高频雷区的现象、原因与处理雷区一诊断统计口径对不上。现象是同一科室的疾病统计上个月和这个月差了一大截或者换了病案系统后数据全乱了。原因是系统里 ICD-9 和 ICD-10 双轨并存老病历走 ICD-9新病历走 ICD-10统计 SQL 直接按 ICD 编码过滤两套编码混在一起。解决方法是统一从 PUB_ZDDMK 本院诊断字典去取诊断ICD 编码只做辅助列统计时先映射到本院诊断编码再分组。雷区二门诊频次改了没生效。现象是住院医嘱显示正常门诊医生站里频次下拉还是旧的。原因是改的是 CPOE_YZYPPCK 住院医嘱药品频次库门诊用的是 OUTP_MZYZPCK 门诊医嘱频次两张表各走各的。解决方法是先确认页面入口属于门诊还是住院再决定改哪张表。这种问题在新人实施时反复出现记住 OUTP_ 前缀是门诊专用就能避免一半。雷区三开药时提示科室无对应药房。现象是医生开药正常但提交时系统提示「当前科室无对应药房」或者药房收到不该接的处方。原因是 PUB_KSYFDYK 科室药房对应库里的科室和病区映射没配或者药房代码调整后没同步对应表。解决方法是按科室编码查 PUB_KSYFDYK确认科室、病区、药房三点对齐同时检查 SYS_KSDMK 和 SYS_BQDMK 里的编码是否一致。雷区四手术后文书是空白。现象是手术医嘱录了术后记录模板没有自动生成。原因是 CPOE_SSYZK 手术医嘱库里的术式没有和 CPOE_SSJLMB 手术记录模板绑定。解决方法是把常用术式与手术记录模板做一一对应新增术式时同步检查模板配置。这属于配置问题但现场排查起来特别费时间因为手术明明录成功了问题出在模板关联上。雷区五文字医嘱开了但不产生费用。现象是医生在医嘱单里写了一段操作说明护士执行了但患者费用清单上没有这笔费用。原因是 CPOE_TEXTORDER 文字医嘱库本身就不挂收费项目它只是自由文本。解决方法是先判断这条医嘱是否需要计费如果需要就让医生从临床收费项目里开而不是走文字医嘱通道。这类问题涉及科室间扯皮实施人员最好在培训阶段就讲清楚边界否则后面天天有人来问。5.2 排查这类问题的通用思路以上五个雷区有一个共同点问题都不在单张表里而在表与表之间的关联上。所以我排查时有一套固定流程。先看错误提示里的业务词汇属于哪个模块推断前缀比如「频次」大概率是 CPOE_YZYPPCK 或 OUTP_MZYZPCK再去文档目录里搜对应表名确认它到底归属哪一层最后查对应库和明细库的关联记录是否完整。关联完整性可以用 SQL 来查。比如查科室药房对应关系是否断链可以这样写SELECT a.BQDM, a.KSDM, b.YFDM FROM SYS_BQDMK a LEFT JOIN PUB_KSYFDYK b ON a.BQDM b.BQDM WHERE b.YFDM IS NULL;这段 SQL 的逻辑是以病区代码库为主表左连接科室药房对应库找出那些有病区但没有配置药房的行。执行结果是 NULL 的行就是断链点逐条补配置就行。用同样的方式可以排查收费执行科室、医保药品对应等所有「对应库」的完整性问题。工具上我用 Navicat 比较多。把这份文档里的表名整理成清单后在 Navicat 里用「导出表结构」功能可以快速生成每个表的字段列表和文档逐条比对确认版本是否一致。神通数据库的 DbStudio 也能做类似操作适合信创环境下的国产库场景。不管用哪个工具核心动作都是把文档当基线把线上库当实际两边对着看。6. 进阶用法用表结构反向推数据流转做接口对接与报表开发有这份表结构文档在手除了查字段还能干几件更值钱的事。第一件是反向推数据流转。拿到一个需求比如「把手术病人的术后随访数据传给随访系统」我不需要问别人直接看 CPOE_SSYZK 和 CPOE_SHSFJLK 两张表按住院号关联字段名都带中文注释接口参数很快就能定下来。第二件是把表结构转成可检索的字典。把文档里的表和 Navicat 导出的结构合并成一个 Excel 词表保留表名、表注释、字段名、字段注释四列遇到问题用筛选功能直接搜关键词比翻 PDF 快得多。第三件是报表取数的路径选择。很多报表开发一上来就查单据表比如从 CPOE_YZDJK 医嘱单据里取收费金额结果发现金额对不上。正确的路径是先看对应库再看明细库。比如统计科室收入要先从 PUB_SFDXMK 收费大项目库确认归类再从 PUB_SFXXMK 收费小项目明细取数最后按 PUB_MZSFZXKSK 或 PUB_ZYSFZXKSK 限定执行科室。单据表只是流程记录明细和对应关系才决定口径。报表 SQL 的基本框架可以这样搭SELECT a.KSDM, SUM(c.JE) AS TOTAL_AMOUNT FROM PUB_SFXXMK c JOIN PUB_LCSFXMDYK b ON c.SFXMDM b.SFXMDM JOIN SYS_KSDMK a ON b.ZXKSDM a.KSDM WHERE c.SFRQ BETWEEN 2024-01-01 AND 2024-12-31 GROUP BY a.KSDM;这段 SQL 的思路是沿着收费小项目、临床收费项目对应库、科室代码库三级关联取数。先限定收费日期区间再按执行科室分组汇总。实际使用时要把表名和字段名换成线上真实的命名但路径可以照抄。从那以后我每次接到卫宁相关的需求都会强制自己走一遍「按业务链路拆表、按文档目录定位、按对应库验证关联」的流程。这份表结构文档我也始终保留着新同事入职时直接丢给他们当字典用。能够把 800 张表理清楚项目的很多问题都能在动手写代码之前就被规避掉。希望这些经验能帮到你。本文还有配套的精品资源点击获取