企业官网建设流程全解析

简介：面向医院信息化建设人员、HIS 系统开发与运维工程师的东华 HIS 表结构参考文档，聚焦医疗数据建模与数据库设计场景，适合需要梳理东华系统数据字典、开展接口对接或二次开发的技术人员查阅。压缩包内共 1 个 docx 文件，约 92KB，以目录加表说明的形式组织内容，便于按模块快速定位。文档系统梳理了 CSP 组件表、用户与就诊卡及登记号等基础数据表、病人基本信息主表及婚姻状况、性别、职业、宗教、学历、民族等字典表，并延伸至医嘱项目定义、医嘱子类与大类、医嘱执行分类、账单组与账单小组等模块，对病人医嘱记录明细、就诊明细关联表等关键表也有说明。已有 1691 人学习下载，可作为理解东华 HIS 数据结构、排查数据关联与设计查询语句时的案头参考。

1. 医院信息系统里的“表结构”：一张住院清单背后的数据地图

去医院看病，你可能只感受到挂号、看诊、拿药这几个动作，但背后有一张看不见的“数据地图”在支撑。东华 HIS 表结构新版，说的就是这张地图的绘制规则——HIS 是 Hospital Information System 的缩写，中文叫医院信息系统，而“表结构”指的是这个系统里数据怎么分门别类地存放。打个比方，医院像一座巨大的图书馆，表结构就是书架的分类标签：病人信息放哪一排、医嘱放哪一格、账单放哪一层，全都规定得清清楚楚。搞懂它，你才能明白为什么同一位患者的信息能在挂号、门诊、住院、收费之间顺畅流转，也才能看懂那些看似枯燥的表名背后，其实是一套让医院跑起来的秩序。这份资料的价值，就在于把这张地图完整摊开给你看。

2. 为什么医院数据要拆成这么多张表：从“一个抽屉塞所有东西”说起

2.1 拆表的本质：让每类数据只回答一个问题

很多人第一次看到东华 HIS 表结构，会有一个直观反应：怎么这么多表？光病人相关的基础数据就有性别表、婚姻状况表、职业表、宗教表、学历表、民族表，每一个都单独成表。这看起来像是把简单问题复杂化了，但恰恰相反，拆表的核心逻辑是“一张表只回答一个问题”。

打个比方，如果所有病人信息都塞进一张大表，性别、职业、婚姻状况全部写成文字，那么当医院要统计“30 岁以下已婚女性患者数量”时，就得在几百万条记录里做文本匹配，既慢又容易出错。而拆成独立的基础数据表之后，病人主表里只存一个指向性别表的序号，统计时直接按序号关联，效率完全不同。

这种设计在数据库领域叫“规范化”，通俗地说就是：能用一个编号代替一段文字的地方，就别重复写文字。东华 HIS 表结构里大量出现_DR后缀的字段，比如PAPMI_Sex_Dr、PAPER_Marital_DR，这个 DR 就是“关联”的意思，它存的不是“男”或“已婚”这样的文字，而是一个指向另一张表的行号。这样一来，性别表里“男”这个名称只出现一次，改一次全系统生效，不会出现有的地方写“男”、有的地方写“男性”的混乱。

2.2 基础数据表为什么存在：给“选项”一个统一的家

性别表、婚姻状况表、职业表这些，在东华 HIS 表结构里被归为“基础数据”。它们的结构高度相似：序号、编码、名称、录入时间。看起来简单到没什么好讲的，但它们的意义不在于结构复杂，而在于“统一”。

想象一下没有这些表的情况：每个录入病人信息的界面都自己维护一套性别选项，门诊系统写“男/女”，住院系统写“男性/女性”，体检系统写“M/F”。数据一汇总，统计报表直接翻车。基础数据表的作用就是给所有“选项”一个统一的家，任何模块要用性别，都来这张表里取，保证全系统口径一致。

提示：东华 HIS 表结构里，基础数据表的命名有规律可循，CT_前缀通常表示公共基础表，比如CT_Sex、CT_Marital、CT_Occupation，看到这个前缀基本可以判断它是一张“选项表”。

2.3 关联字段怎么读：_DR后缀是一条线索

理解东华 HIS 表结构，最关键的一把钥匙是看懂关联字段。前面提到_DR后缀表示关联，但具体怎么关联、关联到哪张表，资料里其实给了明确线索。比如病人登记信息表PA_Patmas里的PAPMI_Sex_Dr，资料注明它关联性别表CT_Sex，关联字段是CTSEX_RowId。这意味着你拿到一个病人的记录，看到PAPMI_Sex_Dr的值是 2，就去CT_Sex表里找CTSEX_RowId等于 2 的那一行，读出对应的性别名称。

这种“存编号不存文字”的做法，在查询时表现为一次关联操作。用 SQL 表达大概是这样：

-- 查询病人登记号、姓名和性别名称 SELECT p.PAPMI_No, p.PAPMI_Name, s.CTSEX_Desc FROM PA_Patmas p LEFT JOIN CT_Sex s ON p.PAPMI_Sex_Dr = s.CTSEX_RowId;

这段查询里，PA_Patmas是病人登记信息表，CT_Sex是性别表，LEFT JOIN保证即使性别字段为空，病人记录也不会丢。参数上唯一需要注意的是关联字段的对应关系：PAPMI_Sex_Dr对CTSEX_RowId，写错一个字母结果就全偏了。东华 HIS 表结构资料里每张表都标注了关联去向，读表时顺着_DR字段找过去，基本不会迷路。

3. 病人、就诊、医嘱、收费：四条主线怎么串起来

3.1 病人主线：从登记号到基本信息主表

东华 HIS 表结构里，病人相关数据有两条并行的主线：一条是PA_Patmas（病人登记信息表），存登记号、身份证号、姓名、出生日期这些“身份标识”；另一条是PA_Person（病人基本信息主表），存地址、婚姻状况、职业、国籍、学历这些“属性描述”。两张表通过PAPMI_PAPER_DR和PAPER_PAPMI_DR互相指向，形成一对一的关系。

为什么要拆成两张？通俗地说，登记信息是“你是谁”，基本信息是“你是什么样的人”。挂号时最需要的是快速确认身份，所以登记表字段精简、查询快；而基本信息字段多、更新频率低，单独存放不影响主流程。这种拆分在数据量大的医院里差别很明显：每天几万人次挂号，登记表的查询压力远大于基本信息表，分开之后各扛各的。

3.2 就诊主线：一次看病就是一条PA_Adm记录

病人来了，不管是门诊还是住院，系统都会生成一条就诊记录，存在PA_Adm表里。这张表是东华 HIS 表结构里的枢纽之一，它把病人、科室、医生、床位全部串起来。资料里写得很清楚：PAADM_PAPMI_DR关联病人表，PAADM_DepCode_DR关联科室表，PAADM_AdmDocCodeDR关联医生表，PAADM_CurrentBed_DR关联床位表。

就诊号本身也有讲究，资料提到PAADM_ADMNo以 OP 开头的是住院就诊号、IP 开头的是门诊就诊号。这里容易看反，记住一点就行：字母顺序和直觉相反，OP 对应住院、IP 对应门诊，实际使用时以资料原文为准。就诊类型字段PAADM_Type则用 O、E、I、T 区分门诊、急诊、住院、体检，这些编码在写查询条件时经常用到。

3.3 医嘱主线：OE_OrdItem是处方和住院医嘱的落脚点

医生开的每一条医嘱，最终都落在OE_OrdItem（病人医嘱记录明细）里。资料特别强调，这张表“所有的门诊处方、住院医嘱全部在此表中”，但它只记录医嘱本身，不记录收费明细。这是一个关键边界：医嘱是“医生说要做什么”，收费是“这件事收了多少钱”，两者分开存放，通过关联表连接。

医嘱项的定义在ARC_ItmMast表里，资料给了一个很实用的提醒：HIS 的医嘱项对应 LIS 的医嘱套，而 HIS 的医嘱套是把常用医嘱项组合起来方便医生快速开立。这个对应关系在对接检验系统时经常让人绕晕，记住“HIS 医嘱项 = LIS 医嘱套”这个等式，能少走不少弯路。

3.4 收费主线：账单表和收费项目表各管一段

收费相关的表在东华 HIS 表结构里数量不少，但主线清晰：ARC_ItmMast里的医嘱项必须先关联收费项目，才能在医生开医嘱界面显示，资料原文写的是“医嘱必须跟收费项目关联后才能在医生开医嘱界面看到”。收费项目本身又分大类、子类，还有住院和门诊各自的分类，层层细分。

病人实际发生的费用记录在病人账单表里，资料说明它“记录病人本次就诊期间所发生的费用总额，可根据就诊号查询”。账单和医嘱之间通过关联表连接，形成“账单 → 医嘱 → 收费项明细”的追溯链条。这条链条的意义在于：患者对费用有疑问时，可以从总额一路查到具体是哪条医嘱、哪个收费项目产生的。

4. 常见误区与易混概念：这几组表名别再搞混了

4.1 误区一：病人登记表和病人基本信息主表是一回事

易混点：PA_Patmas和PA_Person都带“病人”字样，字段里都有姓名、出生日期、性别，看起来像重复建设。

为什么混：两张表确实有重叠字段，而且互相关联，初次接触很容易认为其中一张是多余的。

怎么区分：记住分工——PA_Patmas管“身份识别”，核心是登记号PAPMI_No，挂号、就诊卡、就诊记录都指向它；PA_Person管“属性描述”，核心是地址、婚姻、职业、学历这些扩展信息。查身份走前者，查人口学特征走后者。

4.2 误区二：医嘱项和医嘱套是同一个东西

易混点：两个词都带“医嘱”，资料里还专门加了一句“HIS 医嘱项就是 LIS 的医嘱套”，读快了容易以为它们可以互换。

为什么混：跨系统对接时术语错位，HIS 和 LIS 对同一个概念用了不同的名字，加上 HIS 自己又有“医嘱套”的概念，三层含义叠在一起。

怎么区分：在东华 HIS 表结构内部，医嘱项是ARC_ItmMast里的一条具体项目，医嘱套是多个医嘱项的组合，存在ARC_OrdSetDateItem相关表里。跨系统对接时，HIS 的医嘱项对应 LIS 的医嘱套，这是接口层面的映射关系，不是表结构层面的等同。

4.3 误区三：病人医嘱记录明细里能查到收费金额

易混点：OE_OrdItem记录了所有门诊处方和住院医嘱，直觉上收费信息应该也在里面。

为什么混：医嘱和收费在业务流程上紧密相连，医生开医嘱的同时就产生了费用，容易想当然认为数据存在一起。

怎么区分：资料原文明确写了这张表“只用来记录病人医嘱，并没有记录病人收费项目明细”。收费金额要去病人账单表和收费项记录表里查，两者通过关联表连接。写查询时如果发现金额字段为空，先检查是不是找错表了。

4.4 误区四：科室表只存临床科室

易混点：CT_LOC叫科室表，直觉上以为里面只有内科、外科这类看病的地方。

为什么混：表名翻译成“科室”，而日常语境里科室就是诊室。

怎么区分：看CTLOC_Type字段，资料列了 E（执行科室）、OP（手术室）、O（其它科室）、D（配送分发室）、W（病区）、C（财务出纳）、OR（门诊就诊科室）、EM（急诊科室）等多种类型。病区也是科室表里的一类记录，只是类型标记为 W。查科室时如果不加类型条件，会把药房、财务室一起查出来。

4.5 误区五：就诊号前缀 OP 和 IP 按字面理解

易混点：OP 看起来像 outpatient（门诊），IP 看起来像 inpatient（住院），按字面理解似乎顺理成章。

为什么混：英文缩写和实际含义对不上，而且资料原文的表述需要仔细读。

怎么区分：资料原文写的是“OP 起头的是住院就诊号、IP 起头的是门诊就诊号”，和字面直觉相反。实际写查询条件时，以资料标注为准，不要凭英文缩写猜。这类“反直觉编码”在 HIS 里不算少见，遇到不确定的字段值，先翻资料确认再下手。

5. 什么时候该翻这份表结构，什么时候别硬啃

这份东华 HIS 表结构资料，最适合用的场景很明确：你需要写查询、做接口对接、排查数据问题时，它是案头工具。比如要查某位患者本次就诊的所有医嘱，顺着PA_Adm的就诊号找到OE_OrdItem里的OEORD_Adm_DR，再关联ARC_ItmMast取医嘱名称，这条路径资料里都有标注，照着走就行。再比如对接检验系统时搞不清医嘱项和医嘱套的映射关系，翻到对应章节能直接找到答案。

但有些时候别硬啃。如果你只是想了解医院信息系统大概怎么运转，不需要逐张表读字段，抓住四条主线——病人、就诊、医嘱、收费——就够建立整体认知了。另外，资料里个别表标注了“无多大意义”或“没用”，比如医嘱执行分类表和住院登记号字段，这类内容快速跳过即可，不必平均用力。

有个习惯我后来一直保持：每次写涉及多表关联的查询之前，先把要用到的表在纸上画一遍关联箭头，标清楚哪个字段指向哪张表的哪个字段，确认没有断链再动手写 SQL。这个动作花不了几分钟，但能挡掉大部分“查出来数据对不上”的返工。东华 HIS 表结构的关联关系密集，_DR字段一个接一个，光靠脑子记很容易在某个环节接错线。希望这份资料到你手里时，也能成为那张随时可以摊开对照的地图。

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