企业官网建设流程全解析

简介：《卫宁电子病历表结构》是上海金仕达卫宁软件临床信息系统数据库结构设计说明书，面向医院信息化实施、EMR 二次开发及数据对接人员，用于厘清电子病历系统各表的关系与字段含义。文档覆盖系统框架、基础代码库、财务收费、医疗信息、数据标准化和权限安全设计，正文按职工代码库、医疗项目库、药品分类库、科室/病区代码库、凭证类型库、收费项目类别库、医保分类库、诊断代码库等模块展开，对 800 多张表逐表列出表说明、字段定义、类型、长度、备注和值域，可作为数据字典直接查阅。包体为单个 Word 文档，压缩包约 13.92MB，目录层级清晰，便于按模块检索和复制。目前已有 1547 人学习，适合在系统集成、报表开发、数据迁移或接口联调时作为权威字段参考。

1. 卫宁电子病历表结构：一份藏在DOC里的医院数据地图

我拿到这份《卫宁电子病历表结构.doc》时，第一反应是“又是那种几百页没人看的说明书”。但翻到目录页就改了判断——这不是概述文档，而是一份包含800多张表、几十个基础代码库和完整CPOE（医生医嘱录入）模块字段定义的数据库结构说明书，覆盖从职工代码库、医疗项目库到检查申请单、手术医嘱、血库审核流程的全部表结构。对医疗信息化从业者来说，它相当于一张可以直接对着建库、做接口、跑数据迁移的底图。无论你是EMR实施工程师、集成平台开发，还是做医院数据仓库的BI工程师，这份表结构文档都能帮你少走至少两个月的弯路——前提是，你得知道怎么读它。

2. 基础框架库与主数据表：先理清医院信息系统的“底盘”再谈业务

2.1 系统框架库的整体分类与命名规律

整份文档的第一部分标着“系统框架”，列出的是整张底图的基础层。我把它挑出来单独说，是因为在HIS/EMR这类系统里，主数据表的字段设计直接决定后续业务表能怎么关联。先把框架库按用途分成四类：

命名上有一套规律：前缀“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文字医嘱库是整个流程的起点。它存的是医生录入的医嘱原文，常见字段包括医嘱编号、病人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和收费表中的流转状态；第二组是住院医嘱：从开立、审核、摆药、执行到计费，确认每条医嘱的费用明细都能追溯到开立记录；第三组是检查申请：从申请、预约、登记、执行到报告，确认状态字段的每一次变化都有时间戳记录。三组跑通后，再抽查一周的真实业务数据，按“数据完整性、状态合法性、金额一致性”三个维度做计数核对。

我自己的习惯是：每到一个新项目，第一周不写业务代码，先把数据字典建好、把主链条的表关系画清楚，再动手做接口。磨刀不误砍柴工，这套流程省下来的排查时间远比投入多。当初拆完这份卫宁电子病历表结构，最大的收获不是记住了多少张表名，而是掌握了一套“先找主链路、再查对应关系、最后对值域”的拆库方法。希望帮到你。

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