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 Type（E/F/L）决定渲染成编辑框、表单还是列表。这种设计的好处是加一个业务模块不需要改框架代码，坏处是表里一行配错，整个模块白屏——而且报错信息往往只告诉你“类加载失败”，不会告诉你哪行配置有问题。

PassThruParameters这个字段容易被忽略，它存的是组件初始化时透传的参数，比如默认科室编码、默认就诊类型。很多“打开页面数据不对”的问题，根子在这个字段被复制粘贴时带错了值。

2.2 元数据驱动的代价：配置漂移与排查路径

元数据驱动最大的坑是配置漂移。开发环境里QuerySQL写的是SELECT * FROM PA_Adm WHERE PAADM_VisitStatus='A'，上线后有人为了性能改成带索引提示的写法，结果漏了状态过滤，在院病人列表把已出院的也带出来了。这种问题在代码 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_VisitStatus='A'，会把预入院病人漏掉；如果不过滤，又把已撤销的带出来。正确的写法是按业务场景组合PAADM_VisitStatus和PAADM_Type（O 门诊 / 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_Type='I'是关键过滤条件，少了它会把门诊在诊病人也带进来。第二条用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_Type='W'锁定病区集合，再关联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_Type='W'锁定病区，再关联PA_Adm，多院区再加CTLOC_Hospital_DR条件。

5.5 长期医嘱执行记录重复统计

现象：长期医嘱执行次数统计翻倍。原因：明细表一条记录关联了多条执行记录，直接 count 明细表再 join 执行表产生笛卡尔积。解决：统计执行次数时以执行表为主表 count，明细表只做过滤条件，不要双向 join 后 count。

6. 设计取舍：为什么 HIS 表结构看起来“反直觉”

HIS 表结构里大量反直觉设计——登记号和就诊号分离、医嘱和收费解耦、长期医嘱一条明细多条执行、科室表一个字段分七种类型——背后是同一个取舍：临床行为的灵活性和经济行为的可审计性必须分开。临床侧允许改嘱、停嘱、退嘱，经济侧要求每笔费用有据可查、可追溯、可对账。两者用关联表桥接，代价是一致性靠程序保证，好处是任何一侧的变更不会直接污染另一侧的历史数据。

验证这套结构是否被正确使用，我习惯做三件事：拿一个真实就诊号，从PA_Adm出发沿外键链路走一遍到账单和发票，看有没有断链；对同一病人的登记号和就诊号分别查一次费用，看结果是否一致；随机抽一条长期医嘱，核对明细表记录数和执行表记录数的比例是否符合预期。这三步走完，表结构用得对不对基本心里有数。

从那以后我每次接手新的 HIS 模块，都强制先把涉及的表按“主索引 → 流程 → 经济”三层画一遍关联图再动代码，不画图直接写 SQL 的教训踩过太多次。希望帮到你。

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