简介面向医院信息化建设人员、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字段一个接一个光靠脑子记很容易在某个环节接错线。希望这份资料到你手里时也能成为那张随时可以摊开对照的地图。本文还有配套的精品资源点击获取