企业官网建设流程全解析

简介：《卫宁电子病历表结构》是一份医疗机构信息化场景下的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 张表会清晰很多。

为什么要这样分层？医院的信息化往往有 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 药品分类库为例，这类字典表在这个版本里通常包含这些字段：

这里的 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 张表理清楚，项目的很多问题都能在动手写代码之前就被规避掉。希望这些经验能帮到你。

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