HIS表结构深度解析：从CSP组件到医嘱收费的关联机制与避坑指南

简介面向医院信息化建设人员、HIS 系统开发与实施工程师的东华 HIS 表结构参考文档聚焦医疗数据建模与数据库设计场景适合需要梳理东华系统数据字典、开展接口对接或二次开发的技术人员查阅。压缩包内共 1 个 docx 文件约 92KB以目录加表说明的形式组织内容便于按模块快速定位。文档系统梳理了 CSP 组件表、用户与就诊卡及登记号等基础数据表、病人基本信息主表及婚姻状况、性别、职业、宗教、学历、民族等字典表并延伸至医嘱项目定义、医嘱子类与大类、医嘱执行分类、账单组与账单小组等核心结构对医嘱记录明细、就诊明细关联等关键表也有说明。已有 1691 人学习下载可作为理解东华 HIS 数据组织方式、编写数据字典或排查字段含义时的案头资料。1. 一张表结构文档为什么能决定 HIS 的生死医院信息系统的崩溃往往不是从代码报错开始的而是从一张表被误解开始的。东华 HIS 表结构新版这份文档表面看是字段清单实质是一份数据契约——它规定了病人、医嘱、账单、发票之间如何咬合。搞懂它你才能明白为什么改一个字段会连锁触发收费异常为什么医嘱开了却看不到为什么登记号在三个表里各有一套编号逻辑。HIS 的底层不是界面是这些表之间的引用关系。这份资源把 CSP 组件、病人主索引、医嘱项、收费项、发票结算五大板块的字段含义和关联路径全部摊开是理解医疗信息化底层机制的一手材料。接下来从组件注册讲到医嘱执行把设计动机和踩坑点拆透。2. CSP 组件表为什么界面是“配”出来的而不是“写”出来的2.1 组件注册机制websys.Component 到底存了什么HIS 的界面元素——病人列表、医嘱录入框、收费明细——不是每个页面单独写死的而是通过websys.Component表注册后动态渲染。这张表的字段设计暴露了整套 UI 框架的元数据驱动思路ClassName指向后台类名QueryName和QuerySQL决定数据从哪来Menus定义右键菜单项FormSizeAndPosition存窗口几何信息。换句话说一个组件的行为在运行时由这行记录拼装出来而不是编译期固定。常见的实现思路是前端框架启动时扫描这张表按Name找到组件反射加载ClassName对应的类把QuerySQL注入数据源再按Display TypeE/F/L决定渲染成编辑框、表单还是列表。这种设计的好处是加一个业务模块不需要改框架代码坏处是表里一行配错整个模块白屏——而且报错信息往往只告诉你“类加载失败”不会告诉你哪行配置有问题。PassThruParameters这个字段容易被忽略它存的是组件初始化时透传的参数比如默认科室编码、默认就诊类型。很多“打开页面数据不对”的问题根子在这个字段被复制粘贴时带错了值。2.2 元数据驱动的代价配置漂移与排查路径元数据驱动最大的坑是配置漂移。开发环境里QuerySQL写的是SELECT * FROM PA_Adm WHERE PAADM_VisitStatusA上线后有人为了性能改成带索引提示的写法结果漏了状态过滤在院病人列表把已出院的也带出来了。这种问题在代码 review 里看不出来因为改的是数据不是代码。排查这类问题的顺序我一般这么走先查websys.Component里该组件的QuerySQL和LastUpdateDate确认最近有没有人动过再看ClassName对应的类是否在%SYS命名空间下能正常实例化最后核对PassThruParameters里的默认参数是否和当前科室/院区匹配。三步走完八成配置类问题能定位。提示LockExtraClass和LockEctrald这两个字段名里的拼写错误Ectral 而非 Extra是历史遗留查询时按原文拼写别自作主张改。2.3 组件表与权限体系的耦合点Menus字段存的是菜单权限串格式类似System.PAPerson.Edit.Print。这套点分命名既是菜单路径也是权限标识用户安全组SS_User.SSUSR_Group决定能看到哪些菜单项。设计上这是把权限粒度做到了按钮级但代价是菜单串一旦改名历史权限配置全部失效。实际运维中改菜单名必须同步刷Menus字段否则医生登录后看不到“打印”按钮报障时只说“按钮没了”排查起来要翻组件表才知道是权限串对不上。3. 病人主索引登记号、就诊号、RowID 为什么是三套编号3.1 PA_Patmas 与 PA_Person 的拆分逻辑病人信息被拆成PA_Patmas登记信息和PA_Person基本信息主表两张表靠PAPMI_PAPER_DR和PAPER_PAPMI_DR双向关联。这个设计初看冗余——姓名、性别、出生日期两边都有。但拆分的动机是PA_Patmas管的是“这个人在本院的存在”PA_Person管的是“这个人的自然属性”。登记号PAPMI_No是院内唯一标识身份证号PAPMI_ID是跨院标识两者不等价。一个人可以有多张就诊卡DHC_CardRef但只有一个登记号一次就诊产生一个就诊号PA_Adm.PAADM_ADMNo但登记号不变。这种三层编号RowID 物理主键、登记号业务主键、就诊号流程主键是 HIS 的通用做法。RowID 用于表间外键稳定但不该暴露给用户登记号用于跨次就诊识别同一个人就诊号用于定位一次具体的诊疗行为。搞混这三者就会出现“按登记号查不到本次费用”或者“按就诊号查历史记录查不全”的问题。3.2 就诊状态机PAADM_VisitStatus 的取值陷阱PA_Adm的PAADM_VisitStatus字段取值 A/C/D/P/R/N分别对应在院、撤销、出院未收费、预入院、已释放、未到诊。这个状态机是收费和医嘱执行的闸门状态为 A 时才能开医嘱状态为 D 时账单已锁定但还没结算状态为 C 时整个就诊作废。血泪经验在于门诊和住院共用这张表但状态流转规则不同。门诊病人看完就走状态直接从 A 跳到 D住院病人要经过预入院 P、在院 A、出院 D 三个阶段。如果查询在院病人时只过滤PAADM_VisitStatusA会把预入院病人漏掉如果不过滤又把已撤销的带出来。正确的写法是按业务场景组合PAADM_VisitStatus和PAADM_TypeO 门诊 / I 住院 / E 急诊 / T 体检。-- 查当前在院住院病人状态 A 且类型 I SELECT PAADM_ADMNo, PAADM_PAPMI_DR, PAADM_AdmDate FROM PA_Adm WHERE PAADM_VisitStatus A AND PAADM_Type I; -- 查某登记号的全部有效就诊排除撤销和未到诊 SELECT PAADM_ADMNo, PAADM_VisitStatus, PAADM_Type FROM PA_Adm WHERE PAADM_PAPMI_DR ? AND PAADM_VisitStatus NOT IN (C, N);第一条语句的PAADM_TypeI是关键过滤条件少了它会把门诊在诊病人也带进来。第二条用NOT IN排除无效状态比正向枚举更稳因为状态码未来可能扩展。3.3 科室表的类型编码CT_LOC 一个表撑起半边天CT_LOC用CTLOC_Type一个字段区分执行科室E、手术室OP、药房D、病区W、财务C、门诊诊室OR、急诊EM。病区也是科室只是类型为 W。这个设计让PA_Adm的PAADM_CurrentWard_DR和PAADM_DepCode_DR都指向同一张表简化了外键管理但查询时必须带类型过滤。翻车场景统计某病区在院人数直接按CTLOC_Desc模糊匹配病区名结果把同名的执行科室也算进去了。正确做法是先按CTLOC_TypeW锁定病区集合再关联PA_Adm。另外CTLOC_Hospital_DR关联医院表多院区部署时漏了这个条件会把其他院区的数据混进来。4. 医嘱与收费为什么开了医嘱却看不到、收不到费4.1 ARC_ItmMast 与收费项的绑定关系医嘱项定义在ARC_ItmMast但医生开医嘱界面能看到哪些项取决于它有没有关联收费项。文档里写得很直白“医嘱必须跟收费项目关联后才能在医生开医嘱界面看到否则不能看到新增的医嘱项。”这个绑定关系存在医嘱项关联收费项表里ARCIM_ItemCat_DR指向医嘱子类ARCIM_BillSub_DR指向账单组收费项再挂到对应的收费大类/子类下。设计动机是医嘱是临床行为收费是经济行为两者解耦但必须挂钩。一个医嘱项可以对应多个收费项比如一次 CT 检查包含扫描费、胶片费、造影剂费收费项也可以被多个医嘱项复用。这种多对多关系用中间表维护代价是新增医嘱项时如果忘了配收费关联界面上就是不出现——而且不报错只是“看不到”。4.2 OE_OrdItem 只记医嘱不记钱账单关联表的作用OE_OrdItem存病人医嘱明细门诊处方和住院医嘱都在这里但它不记录收费明细。收费记录在病人账单表PA_Adm关联的账单表和账单关联收费项记录表里。三张表的关系是医嘱 → 账单关联医嘱表 → 账单关联收费项记录表。查一次就诊的总费用不能直接对OE_OrdItem求和必须走账单链路。这个拆分的好处是医嘱可以改停嘱、退嘱账单按实际执行和收费走两者独立审计。坏处是数据一致性靠程序保证如果停嘱后没触发退费账单里还留着那条收费记录月底对账就对不上。排查这类问题先查OE_OrdItem的医嘱状态OEORI_ItemStat_DR关联医嘱状态表再看账单关联表里有没有对应的退费记录。4.3 长期医嘱的执行记录为什么明细只有一条文档里有一句关键说明长期医嘱在就诊明细中只存一条记录每次执行时间记在医嘱执行情况表里。这是长期医嘱和临时医嘱的核心区别。临时医嘱执行一次就结束明细和执行一一对应长期医嘱每天执行多次如果每次都往明细表插一条数据量会爆炸。所以设计上用“一条明细 多条执行记录”的模式。查询“某病人今天执行了哪些长期医嘱”不能只查明细表要关联执行情况表按执行日期过滤。漏了这层关联要么查不到执行记录要么把没执行的也算进去。执行状态字段医嘱护士执行状态在这里是过滤条件只取正常执行状态的记录。-- 查某就诊某日的长期医嘱执行记录 SELECT o.OEORI_RowId, o.OEORI_ItmMast_DR, e.ExecDate, e.ExecStatus FROM OE_OrdItem o JOIN OE_OrdExec e ON e.Exec_OrdItem_DR o.OEORI_RowId WHERE o.OEORI_Adm_DR ? AND o.OEORI_Priority_DR ? -- 长期医嘱优先级 AND e.ExecDate ?;OEORI_Priority_DR关联医嘱优先级表区分长期/临时ExecStatus过滤掉未执行和已作废的记录。参数顺序按就诊号、优先级、执行日期传入缺一个条件结果集就会偏。4.4 医嘱状态与检验记录查询的联动文档特别标注医嘱状态表“比较有用在查询检验记录时要查询该状态是否是正常状态”。原因是检验申请也是医嘱如果医嘱被作废或退回对应的检验记录不应该出现在报告列表里。查询 LIS 接口数据时必须 join 医嘱状态表过滤掉非正常状态否则会把已撤销的检验申请对应的报告也拉出来医生看到“幽灵报告”。5. 避坑与排查表结构使用中的五类高频问题5.1 密码字段加密方式误判现象直接拿明文密码去比对SS_User.SSUSR_Password永远不匹配。原因该字段存的是单项加密后的值加密入口是DHC-MEDSRC空间下$$ENCR^SSUTIL2(123)。解决校验密码时对输入值走同一加密函数再比对不要试图解密——单项加密不可逆。5.2 医嘱项可见但收费项缺失现象医生界面能看到某医嘱项开立后账单里没有对应收费。原因医嘱项与收费项的关联表漏配或者关联的收费项已停用。解决查医嘱项关联收费项表确认关联记录存在且收费项ActiveFlag有效新增医嘱项时把收费关联作为上线检查项强制走一遍。5.3 就诊号前缀混淆导致查询为空现象按就诊号查住院病人查不到。原因文档写明 OP 开头是住院就诊号、IP 开头是门诊就诊号注意这个命名和直觉相反查询时按前缀过滤反了。解决不要靠前缀猜类型用PAADM_Type字段判断前缀只作展示用。5.4 病区统计混入非病区科室现象病区在院人数统计偏大。原因CT_LOC里病区类型是 W但查询时按名称模糊匹配把执行科室、药房也算进去了。解决先按CTLOC_TypeW锁定病区再关联PA_Adm多院区再加CTLOC_Hospital_DR条件。5.5 长期医嘱执行记录重复统计现象长期医嘱执行次数统计翻倍。原因明细表一条记录关联了多条执行记录直接 count 明细表再 join 执行表产生笛卡尔积。解决统计执行次数时以执行表为主表 count明细表只做过滤条件不要双向 join 后 count。6. 设计取舍为什么 HIS 表结构看起来“反直觉”HIS 表结构里大量反直觉设计——登记号和就诊号分离、医嘱和收费解耦、长期医嘱一条明细多条执行、科室表一个字段分七种类型——背后是同一个取舍临床行为的灵活性和经济行为的可审计性必须分开。临床侧允许改嘱、停嘱、退嘱经济侧要求每笔费用有据可查、可追溯、可对账。两者用关联表桥接代价是一致性靠程序保证好处是任何一侧的变更不会直接污染另一侧的历史数据。验证这套结构是否被正确使用我习惯做三件事拿一个真实就诊号从PA_Adm出发沿外键链路走一遍到账单和发票看有没有断链对同一病人的登记号和就诊号分别查一次费用看结果是否一致随机抽一条长期医嘱核对明细表记录数和执行表记录数的比例是否符合预期。这三步走完表结构用得对不对基本心里有数。从那以后我每次接手新的 HIS 模块都强制先把涉及的表按“主索引 → 流程 → 经济”三层画一遍关联图再动代码不画图直接写 SQL 的教训踩过太多次。希望帮到你。本文还有配套的精品资源点击获取