东华HIS表结构解析：从病人登记到收费的数据库设计-北京尧图网络

简介面向医院信息化建设人员、HIS 系统开发与运维工程师的东华 HIS 表结构参考文档聚焦医疗数据建模与数据库设计场景适合需要梳理东华 HIS 数据字典、理解表间关联关系的中高级技术人员查阅。资源包共 1 个 docx 文件约 92KB内容以目录式结构组织便于按模块快速定位。文档系统梳理了 CSP 组件表、用户与就诊卡及登记号等基础数据表、病人基本信息主表及婚姻状况、性别、职业、宗教、学历、民族等字典表并延伸至医嘱项目定义、医嘱子类与大类、医嘱执行分类、账单组与账单小组等核心业务表对医嘱项与 LIS 医嘱套的对应关系、病人医嘱记录明细、就诊明细关联表等关键表也有说明。已有 1691 人学习下载可作为东华 HIS 二次开发、接口对接与数据查询时的表结构速查依据。1. 医院信息系统里的“表结构”一张能看懂医院运转的底图去医院看病挂号、就诊、开药、缴费、住院每一步背后都有一串数据在流动。很多人以为这些数据是“系统自动搞定”的其实它们最终都落在数据库里一张张具体的表上。所谓“表结构”通俗地说就是数据库的骨架设计图哪张表存病人信息、哪张表存医嘱、哪张表存账单表与表之间靠哪个字段串起来。东华 HIS 表结构新版就是一套面向医院信息系统Hospital Information System简称 HIS的数据库表设计说明把患者从登记到收费的整条链路拆成了可查询、可关联的表格。搞懂它你就能明白医院系统为什么能同时管住病人、医生、药品和钱而不是一团乱麻。2. 为什么医院系统非要拆成这么多表从“一个抽屉”到“一栋楼”如果把医院所有信息都塞进一张大表会发生什么想象一个抽屉里同时放病历、发票、排班表和药品清单找一张纸得翻半天改一个数字还可能牵动整摞纸。医院每天产生海量数据患者、医嘱、收费、发票各自变化频率不同混在一起既难维护又容易出错。拆表的核心逻辑是“一类事情一张表用编号互相指路”这样每张表只负责一件事改病人地址不会影响账单加一个科室也不用动医嘱记录。2.1 拆表的第一层动机让数据各归各位东华 HIS 表结构里用户信息放在 SS_User病人登记放在 PA_Patmas病人基本信息放在 PA_Person就诊记录放在 PA_Adm。每一张表只回答一类问题SS_User 回答“谁在用系统”PA_Patmas 回答“这个病人是谁”PA_Adm 回答“这次就诊是什么情况”。这种划分不是随意起的名字而是按业务对象切分。比如 SS_User 里存工号、姓名、密码、默认科室、安全组PA_Patmas 里存登记号、身份证号、姓名、出生日期、性别关联。一个系统使用者和一个患者是两种完全不同的实体硬塞进一张表就会出现大量空字段查询时还得反复判断“这行到底是员工还是病人”。拆开之后每张表字段少、含义单一新增一类人员或一类患者信息时只需要扩展对应表不会牵一发动全身。这也是为什么表结构文档里反复出现“关联字段”四个字表与表之间不复制数据只存对方的行号需要时再连起来查。2.2 拆表的第二层动机用“行号”当路标而不是重复抄写以病人登记信息表 PA_Patmas 为例它有一个字段 PAPMI_PAPER_DR指向病人基本信息主表 PA_Person 的 PAPER_PAPMI_DR。这样设计的好处是病人的姓名、性别、出生日期在 PA_Patmas 里有一份在 PA_Person 里也有对应记录但两者靠行号绑定而不是各存各的。再比如就诊卡记录表 DHC-CardRef 里的 CF_PAPMI_DR 指向 PA_Patmas 的 PAPMI_RowId卡类型又通过 CF_CardType_DR 指向 PAC_CardType。一张就诊卡背后至少串起病人、办卡员、卡类型、医院四个对象但卡表本身只存这几个行号不重复存病人姓名或医院名称。这种“行号指路”的做法在数据库里叫外键关联。它的直接效果是病人改名只需要改 PA_Patmas 或 PA_Person 里的姓名所有引用这张表的地方自动看到新名字如果每张表都抄一份姓名改一处漏一处数据就对不上了。表结构文档里大量出现“关联字段→某表某字段”的写法就是在告诉你这条路标怎么走。2.3 拆表的第三层动机让查询能按业务路径走通医院系统最常被问的问题不是“这张表有什么”而是“这个病人这次就诊开了哪些医嘱、对应哪些收费”。东华 HIS 表结构把这条路径拆得很清楚PA_Patmas 存病人PA_Adm 存就诊记录OE_Order 存医嘱收费项目表存价格病人账单表存费用汇总。查一个病人的完整链路就是沿着 PAPMI_RowId → PAADM_PAPMI_DR → OEORD_Adm_DR → 收费关联字段一路连过去。如果所有信息挤在一张表里这条路径就变成在一堆混杂字段里挑挑拣拣既慢又容易漏。拆表之后每张表还可以独立建索引、独立归档。比如医嘱记录表数据量最大可以单独做历史归档基础字典表性别、婚姻状况、职业数据量小且稳定可以常驻内存。这种按业务冷热分离的设计是医院系统能扛住门诊高峰的底层原因之一。3. 表结构里的几个关键角色病人、就诊、医嘱、收费怎么串起来理解了“为什么拆”接下来要看“拆完之后谁连着谁”。东华 HIS 表结构新版里最核心的几条线是病人线、就诊线、医嘱线和收费线。这四条线不是并列的而是层层挂接病人是根就诊是枝医嘱是叶收费是果。搞清这四层关系再看任何一张表都不会迷路。3.1 病人线PA_Patmas 和 PA_Person 的分工病人登记信息表 PA_Patmas 和病人基本信息主表 PA_Person 经常被初学者搞混。简单说PA_Patmas 是“登记身份”PA_Person 是“详细档案”。PA_Patmas 里存登记号 PAPMI_No、身份证号 PAPMI_ID、姓名、出生日期、性别关联、死亡标志、VIP 标志、黑名单标志、有效标志PA_Person 里存地址、婚姻状况、职业、宗教、学历、民族、出生地等更细的档案字段。两张表通过 PAPMI_PAPER_DR 和 PAPER_PAPMI_DR 互相指向。为什么要分两张因为登记行为和信息完善是两件事。一个病人可能先登记拿到登记号地址、职业、学历可以后补也可能一个登记号对应多条基本信息记录比如历史档案修正。分开之后登记表保持轻量查询“这个病人有没有登记”很快基本信息表承载扩展字段加一个新档案项不影响登记流程。表结构文档里 PA_Patmas 的字段明显偏“身份识别”PA_Person 的字段偏“社会属性”这个分工就是设计意图的直接体现。3.2 就诊线PA_Adm 是每次来院的“事件记录”病人是长期存在的就诊是一次一次发生的。PA_Adm 表就是用来记录“某病人某一次来院”的事件表。它的关键字段包括 PAADM_PAPMI_DR指向病人、PAADM_ADMNo就诊号、PAADM_AdmDate 和 PAADM_AdmTime就诊日期时间、PAADM_VisitStatus访问状态、PAADM_Type就诊类型、PAADM_DepCode_DR就诊科室、PAADM_AdmDocCodeDR就诊医生、PAADM_CurrentBed_DR当前床位等。这里有个容易看漏的细节就诊号 PAADM_ADMNo 的起头字母有含义文档里写 OP 起头是住院就诊号、IP 起头是门诊就诊号。状态字段 PAADM_VisitStatus 也不是随便填的A 表示当前在院C 表示已撤销D 表示未收费或出院P 表示未允许R 表示已释放N 表示未到诊。这些编码看起来琐碎但查询“这个病人现在在不在院”“这次就诊有没有取消”全靠它们。就诊类型 PAADM_Type 则区分门诊、急诊、住院、体检不同流程走的后续表不一样。3.3 医嘱线ARC_ItmMast 定义“能开什么”OE_Order 记录“开了什么”医嘱这条线有两层定义层和记录层。定义层是 ARC_ItmMast医嘱项目定义它回答“医院允许开哪些医嘱项”字段包括编码、名称、缩写、最小价格、最大价格、停用标志、停用时间、所属医嘱子类、账单组等。记录层是 OE_Order病人医嘱记录明细它回答“某个病人某次就诊实际开了哪些医嘱”。文档里特别提醒这张表只记录病人医嘱不记录收费项目明细收费明细在另外的表里。这个区分非常重要。ARC_ItmMast 是字典表数据相对稳定新增一个医嘱项要走维护流程OE_Order 是流水表每天大量新增字段里带就诊关联、医嘱项关联、医生关联、执行科室关联。查“这个病人用了什么药”查 OE_Order查“这个药属于哪个医嘱子类、对应哪个账单组”查 ARC_ItmMast。两张表通过 OEORI_ItmMast_DR 指向 ARCIM_RowId 连起来。文档里还提到医嘱套的概念HIS 的医嘱套是把常用医嘱项组合起来方便医生快捷开立对应的是医嘱套定义表和医嘱套包含医嘱项定义表。这相当于给医生准备了一个“套餐菜单”点套餐比逐项勾选快得多。3.4 收费线收费项目必须和医嘱项关联后才能被看到收费这条线最容易被低估。文档里有一句很关键的话医嘱必须跟收费项目关联后才能在医生开医嘱界面看到否则不能看到新增的医嘱项。也就是说ARC_ItmMast 里的医嘱项不是孤立存在的它要通过医嘱项关联收费项表挂到收费项目上。收费项目本身又分大类、子类还分住院收费项目大类子类、门诊收费项目大类子类、经济核算费用大类子类、病历首页费用大类子类、会计费用大类子类。这一层层分类不是为了好看而是因为同一笔费用在不同报表里要按不同口径汇总财务看会计科目医保看病历首页分类科室核算看经济核算分类。病人账单表记录本次就诊期间发生的费用总额病人账单关联的医嘱表可以反查这次账单对应哪些医嘱病人账单关联的收费项记录表再往下查到收费明细。这三张表串起来才能回答“这笔钱是哪个医嘱产生的、按什么分类收的”。如果只存一个总金额对账时就只能干瞪眼。4. 常见误区与易混概念别把“关联字段”当成“重复字段”看表结构文档时最容易翻车的地方不是字段多而是几个长得像的概念被混着用。下面几条是初学者血泪经验里出现频率最高的混淆点每条都按“易混在哪、为什么混、怎么区分”说清楚。4.1 误区一把 RowId 当成业务编号易混点看到 PAPMI_RowId、PAADM_RowID、ARCIM_RowId 就以为这是给用户看的登记号或就诊号。为什么混这些字段都叫“RowId”中文常译成“行号”或“序号”看起来像业务编号。怎么区分RowId 是数据库内部的行标识用来做表间关联不对外展示业务编号是 PAPMI_No登记号、PAADM_ADMNo就诊号、ARCIM_Code医嘱项编码。查病人应该用登记号关联表应该用 RowId。文档里写“关联字段→某表某字段”时指的基本都是 RowId 对 RowId。4.2 误区二把 PA_Patmas 和 PA_Person 当成一张表的两半易混点两张表都有姓名、性别、出生日期看起来像重复存储。为什么混字段确实有重叠而且互相指向。怎么区分PA_Patmas 是登记身份表核心是登记号、身份证号、有效标志、黑名单标志PA_Person 是基本信息主表核心是地址、婚姻、职业、宗教、学历、民族、出生地。判断该查哪张问“这个人有没有登记、登记号是多少”查 PA_Patmas问“这个人的社会属性档案”查 PA_Person。两张表通过 PAPMI_PAPER_DR 和 PAPER_PAPMI_DR 互指不是谁替代谁。4.3 误区三把医嘱项和收费项目当成一回事易混点医生开的是医嘱最后收的是费看起来是一条线。为什么混医嘱项和收费项目在界面上经常同时出现而且文档明确说两者要关联。怎么区分医嘱项在 ARC_ItmMast回答“临床上开什么”收费项目在收费项目表回答“财务上收什么”。一个医嘱项可以关联收费项但医嘱记录表 OE_Order 不存收费明细收费明细在病人账单关联的收费项记录表里。查临床执行看医嘱线查金额明细看收费线两条线在关联表处交汇但不能互相替代。4.4 误区四把就诊类型和访问状态混成一个字段易混点PAADM_Type 和 PAADM_VisitStatus 都描述“这次就诊是什么情况”。为什么混两个字段都在 PA_Adm 表里都影响后续流程。怎么区分PAADM_Type 回答“是哪类就诊”取值 O 门诊、E 急诊、I 住院、T 体检PAADM_VisitStatus 回答“这次就诊走到哪一步”取值 A 当前在院、C 已撤销、D 未收费或出院、P 未允许、R 已释放、N 未到诊。一个是分类一个是状态查询“住院病人”用类型查询“还在院的病人”用状态两个条件经常要一起用。4.5 误区五以为基础字典表可以随便改易混点性别表、婚姻状况表、职业表、宗教表、学历表、民族表看起来只是几个编码和名称改一下无所谓。为什么混这些表字段少容易被当成配置项。怎么区分这些字典表的 RowId 被 PA_Person 等主表通过外键引用改编码或删记录会导致历史档案关联断裂。文档里这些表都带“录入时间”字段说明它们是有生效时间的基础数据维护时要考虑历史数据兼容。新增可以随意改旧编码是踩坑高发区。5. 什么时候该翻这份表结构什么时候别硬啃这份东华 HIS 表结构新版最适合的场景是你要在系统之间做数据对接、排查“为什么这个病人查不到医嘱”、或者需要从数据库层面理解一张报表的数字是怎么汇总出来的。比如接口开发时对方给你一个登记号你要反查这个人的就诊记录和医嘱明细沿着 PA_Patmas → PA_Adm → OE_Order 这条线走比在界面里点来点去快得多。再比如对账时发现账单总额和收费明细对不上就需要看病人账单表、账单关联医嘱表、账单关联收费项记录表这三层是不是有一层漏了记录。这些场景下表结构就是一张地图有它和没它排查效率差好几倍。但有些时候别硬啃。如果你只是想知道“这个病人叫什么、住了哪个床”直接查 PA_Patmas 和 PA_Adm 的少量字段就够了不需要把 PA_Person 的所有社会属性字段都拉出来。如果你要做的是界面操作培训表结构帮不上忙该看的是操作手册。还有表结构文档里有些字段标注了“没用”或“无多大意义”比如 PA_Patmas 里的 PAPMI_IPNo 和 PAPMI_OPNo 标注“没用”医嘱执行分类表标注“无多大意义”这些是前人踩坑后留下的标记别因为好奇去依赖它们做核心逻辑。下面这张对照表可以帮你快速判断该走哪条线你想知道的事该查的表/路径别做的事这个病人登记号是多少PA_Patmas 的 PAPMI_No别用 RowId 当登记号对外这个病人这次就诊开了哪些医嘱PA_Adm → OE_Order别在 PA_Patmas 里找医嘱这个医嘱项对应哪个收费项目ARC_ItmMast → 医嘱项关联收费项表别在 OE_Order 里找收费明细这次就诊费用总额是多少病人账单表别把账单总额当收费明细这个科室属于哪个医院CT_LOC 的 CTLOC_Hospital_DR → CT_Hospital别在用户表里找医院这个医生是什么类型CT_CareProv 的 CIPCP_CarPrvTp_DR → CT_CarPrvTp别把医生表和用户表混用还有一个实际教训有一次排查一个“医嘱开了但收费界面看不到”的问题一开始盯着 OE_Order 看了半天记录明明存在。后来顺着文档里那句“医嘱必须跟收费项目关联后才能在医生开医嘱界面看到”去查 ARC_ItmMast 和收费项目的关联表才发现是新加的医嘱项漏配了收费项关联。从那以后我每次碰到“数据在但界面不显示”的问题都强制先走一遍“定义表有没有配全、关联表有没有断”的检查而不是一头扎进流水表里翻。希望这份表结构资料能帮你少走几段弯路需要完整字段清单和表间关系时直接取用这份文档对照着看就行。本文还有配套的精品资源点击获取

东华HIS表结构解析：从病人登记到收费的数据库设计

相关推荐

EN1175-2020工业卡车电气安全标准核心要点解析

X-Plane 11进近实时监控：FlyWithLua状态机与判据表实践

类脑大模型与智能驾驶：面向逻辑思维的程序设计方法

更多资讯

豆包智能体聊天记录批量导出与手动备份实操指南

npm全局安装包管理与查看命令详解

哈希表原理与C++高性能开发实践

豆包智能体聊天数据手动备份与批量导出全攻略

编程入门：三数排序与分支结构实战解析

Green Hills工具链中的GHS-Checkout Browser解析与应用

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？