★ FEATURED ARTICLE 简介东华HIS表结构新版是一份面向医疗信息化开发、实施与运维人员的数据库表结构参考文档聚焦东华医院信息系统核心业务模块的底层表设计帮助读者快速理解患者主索引、医嘱闭环、费用结算等数据流转逻辑。整份资源为1个docx文件压缩包仅92KB轻量便于离线查阅适合项目实施、报表统计或系统对接时对照使用。该文档已有1670人学习是不少HIS从业者入门的参考材料。内容上文档整理了CSP组件、用户信息、病人登记、就诊卡、科室、医生等基础数据表并展开病人基本信息主表及婚姻、性别、职业、宗教、学历、民族等字典表医嘱部分覆盖医嘱项目定义、医嘱子类/大类、执行分类、医嘱套、医嘱优先级与状态说明病人医嘱记录明细、就诊明细关联表等关键环节账单部分给出账单组挂号费、西药费、中药费与账单小组结构。借助这份文档可较系统地掌握东华HIS的表结构及表间关系为二次开发、数据治理和日常运维提供直接参考。1. 拆这份 HIS 表结构文档先搞清这套系统怎么组织的拿到某 HIS 项目的表结构文档第一反应不是去背表名而是先看出这套系统的骨架。东华 HIS 的库表命名和关联方式其实很有规律核心围绕着病人PA_ 前缀、医护人员CT_ 前缀、医嘱OE_ 前缀、收费DHC_ 前缀四条主线展开。这份文档把表按模块分组每个表带字段级说明和关联字段对做二次开发、写报表、排查数据问题的人来说价值在于省去你连库翻系统字典的半天时间。适合三类人刚接手 HIS 系统的开发、做院内数据接口的工程师、写统计报表的运维。这份文档不是教你建库而是给你一张地图照着地图能找到病人从挂号到结算的全链路数据。2. 病人主数据链路从登记信息到就诊记录的三层结构2.1 主索引与就诊记录的分层设计这套 HIS 的病人数据分三层病人登记信息PA_Patmas、病人基本信息PA_Person、就诊记录PA_Adm。PA_Patmas 是主索引表记录登记号PAPMI_No、姓名PAPMI_Name、身份证号PAPMI_ID、出生日期PAPMI_DOB等核心身份信息。PA_Person 则存扩展信息包括住址PAPER_StNameLine、婚姻PAPER_Marital_DR、职业PAPER_Occupation_DR、学历PAPER_Education_DR、民族PAPER_Nation_DR等维度字段。PA_Adm 是就诊记录表一次挂号或一次住院就是一条记录通过 PAADM_PAPMI_DR 回指主索引。经常有新手混淆这张表的分工直接在 PA_Person 里找姓名翻了半天发现是空的。正确理解是PA_Patmas 管这个病人是谁PA_Person 管这个人的社会属性PA_Adm 管他这次来医院做了什么。三张表通过外键串起来PA_Adm.PAADM_PAPMI_DR → PA_Patmas.PAPMI_RowIdPA_Patmas.PAPMI_PAPER_DR → PA_Person.PAPER_PAPMI_DR。这个设计在查询时有个实际好处统计某科室住院患者年龄分布时只需要 join PA_Adm 和 PA_Patmas不需要碰 PA_Person 的大字段查询效率高不少。2.2 就诊号前缀的反直觉设计PA_Adm 表里有个字段叫 PAADM_ADMNo就诊号文档里标注OP 起头的是住院就诊号、IP 起头的是门诊就诊号。这个命名容易让人踩坑——按惯性思维OP 应该是 Outpatient门诊IP 应该是 Inpatient住院但实际恰好相反。我确认过几套 HIS 库的数据确实是 OP 开头的就诊号对应住院IP 开头对应门诊。PAADM_Type 字段存就诊类型编码O 表示门诊Outpatient、E 表示急诊Emergency、I 表示住院Inpatient这个字段的值才是判断就诊类型的可靠依据。所以写查询时判断门诊还是住院用 PAADM_Type 字段显示给用户看时展示 PAADM_ADMNo。如果直接用就诊号前两位判断类型轻则统计数据出错重则在接口层把住院患者的数据推给门诊系统。配套的表结构里还有一张就诊类别表 PAC_EpisodeSubTypePAADM_Type 存的是它的编码值。这张字典表本身的维护频率不高但做报表时如果需要按普通门诊、专家门诊、急诊、住院分组统计就要 join 这张表不要硬编码判断。2.3 就诊卡与基础字典表就诊卡记录表 DHC_CardRef 通过 CF_PAPMI_DR 关联病人主索引通过 CF_CardType_DR 关联卡类型表 PAC_CardType。卡类型区分门诊卡、住院卡、急诊卡取号逻辑是卡号CF_CardNo全局唯一。办卡时 CF_User_DR 记录了操作员CF_Hospital_DR 关联医院表——在多院区部署时这个字段能帮你区分就诊卡归属哪个院区。基础字典表是这套 HIS 里最能体现设计规范的模块。婚姻状况 CT_Marital、性别 CT_Sex、职业 CT_Occupation、宗教 CT_Religion、学历 CT_Education、民族 CT_Nation六张表结构几乎一致都包含 RowId、Code、Desc 三个字段。查询时用编码做匹配条件展示时用描述避免多语言环境下硬编码中文导致的问题。值得注意的是性别表CT_Sex和民族表CT_Nation分别被 PA_Patmas 和 PA_Person 引用做病人信息展示时需要按登记主索引→性别表、基本信息→民族/学历/婚姻表的两条路径分别取数。-- 查询病人的基本信息含社会属性字典 SELECT p.PAPMI_No AS 登记号, p.PAPMI_Name AS 姓名, s.CTSEX_Desc AS 性别, n.CTNAT_Desc AS 民族, e.EDU_Desc AS 学历, m.CTMAR_Desc AS 婚姻状况, o.CTOCC_Desc AS 职业 FROM PA_Patmas p LEFT JOIN CT_Sex s ON p.PAPMI_Sex_Dr s.CTSEX_RowId LEFT JOIN PA_Person pp ON p.PAPMI_PAPER_DR pp.PAPER_PAPMI_DR LEFT JOIN CT_Nation n ON pp.PAPER_Nation_DR n.CTNAT_RowId LEFT JOIN CT_Education e ON pp.PAPER_Education_DR e.EDU_RowId LEFT JOIN CT_Marital m ON pp.PAPER_Marital_DR m.CTMAR_RowId LEFT JOIN CT_Occupation o ON pp.PAPER_Occupation_DR o.CTOCC_RowId WHERE p.PAPMI_No 0001234567;这里用 LEFT JOIN 而不是 INNER JOIN 是有讲究的。病人的婚姻状况、职业等信息在登记时不是必填项用 INNER JOIN 会把那些没录全的病人直接过滤掉导致查询结果比实际人数少。实际开发中我发现老数据里 PAPER_Marital_DR 为空的记录不在少数用 LEFT JOIN 才能保证主索引表的数据全量返回。3. 医嘱模块拆解医嘱项、医嘱套与执行记录的完整链路3.1 医嘱项与医嘱套层级关系的误解与正解医嘱相关表是这套 HIS 里最容易绕晕的部分先看核心的三张表医嘱项目定义表ARC_ItmMast存的是每一个可开立的医嘱项比如头孢曲松钠 1g就是一条记录。ARCIM_Code 是编码ARCIM_Desc 是名称ARCIM_ItemCat_DR 关联医嘱子类表。ARCIM_BillSub_DR 关联账单组表这个字段决定了医嘱项归到哪个费用类别西药费、检查费、治疗费等。医嘱子类表ARC_ItemCat和医嘱大类表ARC_ItemCat之间是父子关系子类挂到大类下面。比如放射 CT加速器 CT属于子类放射属于大类。实际查询时用子类编码做统计口径大类用于汇总。关键在于文档里的一个注明HIS 的医嘱项就是 LIS 的医嘱套而 HIS 的医嘱套是将常用医嘱项组合而成。这句话的意思是在 HIS 里开检验申请时医生选择的血常规肝功能这个组合在医嘱层面对应的是 LIS 的医嘱套而 HIS 的医嘱套ARC_OrdSet是把多个医嘱项打包方便医生一次开立。理解这个对应关系在写 LIS 接口时才能正确映射两个系统的编码。医嘱套定义表ARC_OrdSet和医嘱套包含医嘱项定义表ARC_OrdSetDetail是主从表关系从表通过 ITM_ARCIM_DR 引用医嘱项。医嘱项别名表ARC_Alias给同一个医嘱项维护多个检索名比如对乙酰氨基酚的别名可能是扑热息痛。医嘱项外部代码表ARC_ItemExternalCodes存的是医嘱项在外部系统LIS、RIS的映射编码做接口时靠这张表做编码转换。-- 查询某个医嘱套包含的医嘱项明细 SELECT os.ARCOS_Desc AS 医嘱套名称, osd.ITM_ARCIM_DR AS 医嘱项RowId, ai.ARCIM_Code AS 医嘱项编码, ai.ARCIM_Desc AS 医嘱项名称, ic.ARCIC_Desc AS 医嘱子类 FROM ARC_OrdSet os LEFT JOIN ARC_OrdSetDetail osd ON os.ARCOS_RowId osd.ITM_ARCOS_ParRef LEFT JOIN ARC_ItmMast ai ON osd.ITM_ARCIM_DR ai.ARCIM_RowId LEFT JOIN ARC_ItemCat ic ON ai.ARCIM_ItemCat_DR ic.ARCIC_RowId WHERE os.ARCOS_Code DX002;实际项目中医嘱套的层级可能超过两层医嘱套 A 包含医嘱项 B而医嘱项 B 在 LIS 里又对应到多个检验项目。做接口联调时不要假设 LIS 返回的项目编码能直接映射到 HIS 医嘱项中间可能需要通过医嘱项外部代码表做一次转换。表格里 EXT_ParRef 字段就是干这个用的但要注意外部代码表的维护职责——通常由检验科或信息科定期同步不归门诊医生管。3.2 医嘱记录明细与执行情况的两表分工病人医嘱记录明细表 OE_OrdItem 是医嘱模块的核心所有门诊处方和住院医嘱都记录在这张表。它通过 OEORI_ItmMast_DR 关联医嘱项目定义通过 OEORI_Adm_DR 关联就诊记录 PA_Adm通过 OEORI_Doctor_DR 关联开立医生。这张表只记录医嘱本身不涉及费用明细。有一个重要细节长期医嘱在 OE_OrdItem 里只存一条记录每次执行时间记录在医嘱执行情况表 OE_OrdExec 里。这意味着查询长期医嘱的执行次数、每次执行时间、执行护士都要 join OE_OrdExec。刚接触这套系统的开发者经常犯的错是在 OE_OrdItem 里找执行次数字段找不到就开始怀疑表结构不对再去翻文档才发现执行明细在另一张表。医嘱状态表是查询检验记录时要重点注意的基础数据。OE_OrdItem 里的状态字段通常是 OEORI_Status_DR需要 join 医嘱状态表才能拿到可读的状态名称。文档特别提醒查询检验记录时要判断状态是否为正常否则可能把已作废的申请单也算进去。实际开发中建议在业务层统一封装状态过滤逻辑而不是每个 SQL 里散落着状态判断条件这样后期维护状态码表时只需要改一处。医嘱执行分类表ARC_ExecDept区分检验医嘱、可执行医嘱等类型文档说这张表无多大意义实际查询统计时确实不常用因为执行科室字段OEORI_RecDep_DR直接关联在医嘱明细表上按科室统计执行量时直接用它就行。3.3 医嘱项与收费项目的强制关联收费项目表DHC_TarItem与医嘱项之间通过医嘱项关联收费项表建立关系。文档里有句关键提示医嘱必须跟收费项目关联后才能在医生开医嘱界面看到否则不能看到新增的医嘱项。这句话意味着新增一条医嘱项后如果不做关联配置它在开单界面是不可见的。运维或实施人员在手工加药品后如果发现医生端找不到大概率是漏配了关联表。这个配置过程包含两部分一是把医嘱项和收费项目关联起来二是配置收费标准。两步都完成新医嘱项才能正常开立和计价。从开发角度看这个强制关联的意义在于医生开医嘱时系统能自动带出收费项目避免医嘱和费用脱节。-- 查询未配置收费项目关联的医嘱项 SELECT ai.ARCIM_RowId, ai.ARCIM_Code, ai.ARCIM_Desc FROM ARC_ItmMast ai LEFT JOIN DHC_TarItemRef tir ON ai.ARCIM_RowId tir.ARCIM_DR WHERE tir.ARCIM_DR IS NULL AND ai.ARCIM_OrderOnItsOwn Y;4. 收费与账单从医嘱明细到病人账单的关联链路4.1 收费项目的多级分类与关联设计收费项目表分为门诊收费项目DHC_TarItem、住院收费项目DHC_IPTarItem两套体系各自带大类和小类的多级分类。医嘱项通过 DHC_TarItemRef 表与收费项目关联关联后医生开医嘱时界面自动带出对应收费。收费项目大类表和小表的设计逻辑是大类用于财务报表汇总如西药费检查费治疗费小类用于科室级明细统计如放射 CT加速器 CT。值得注意的是经济核算费用大类、病历首页费用大类、会计费用大类这三套分类体系与收费项目大类是独立维护的什么意思呢同一个收费项目在经济核算系统里归到一个类别在病历首页里可能归到另一个类别在会计系统里又可能不同。这种多套分类并行的设计在 HIS 里很常见但容易让新人抓狂——在收费项目表里加一个费用类别字段想一劳永逸结果发现根本对不上。正确的做法是先明确当前查询属于哪个口径再选择对应的分类表 join。临床科室统计收入、财务做成本核算、病案室算 DRG 分值三个需求走三套分类表各自独立成链。病人账单表DHC_IPBill记录病人本次就诊期间的费用总额通过 PAADM_DR 关联就诊记录通过 BILL_No 生成账单号。账单关联医嘱表DHC_IPBillOrder和账单关联收费项记录表DHC_IPBillTar是账单的明细层分别记录了账单对应的医嘱和对应的收费项目明细。这里的核心设计是一次就诊对应多条账单记录一条账单关联多条医嘱一条医嘱关联多条收费项目明细。这样设计的好处是如果退费或者部分结算可以在账单层精确到某几条收费记录不影响其他费用记录。-- 按账单查询费用明细住院场景 SELECT b.BILL_No AS 账单号, bt.TAR_Desc AS 收费项目名称, bt.TAR_Price AS 单价, bt.TAR_Qty AS 数量, bt.TAR_Amount AS 金额 FROM DHC_IPBill b LEFT JOIN DHC_IPBillTar bt ON b.BILL_RowId bt.BILL_ParRef WHERE b.PAADM_DR 12345 AND b.BILL_Cancel_Flag N;4.2 发票管理与支付方式扩展发票模块涉及发票入库记录、发票出库记录、发票表、发票与账单关联表。发票入库出库管理的逻辑是财务购买整本发票后入库DHC_InvIn科室领取时出库DHC_InvOut病人缴费后产生实际发票记录DHC_Inv发票数据挂到对应账单。发票表与发票的支付方式关联后同一张发票可以支持现金、银行卡、医保个账等多种支付方式的组合。支付方式表DHC_PayMode和支付方式扩展表是考虑到了移动支付。微信支付、支付宝这些支付通道通常挂在支付方式扩展表里每条扩展记录包含渠道流水号、交易金额、交易状态。开发支付对接时新增一种支付渠道只需要在扩展表加记录不需要改核心的发票表结构。银行交易表记录第三方支付的交易流水门诊银行交易子表、住院押金银行交易子表、住院结算银行交易子表分别记录不同场景下的支付流水。设计上这些交易表都没有直接操作核心账单表是松散耦合的关系所以排查支付成功但账单未结算这类问题时要从支付流水表往账单方向查。4.3 门诊收费与住院收费的流程差异门诊收费流程是挂号 → 医生开医嘱 → 收费员收费 → 生成发票 → 发票关联账单 → 结算日报汇总。住院收费流程是住院登记 → 交押金 → 医生开医嘱 → 费用累计 → 出院结算 → 生成住院收据。住院押金表DHC_IPDeposit和住院结算表DHC_IPSettle是住院收费的两大核心。押金记录每次交款结算记录出院时的费用清算。查询住院患者的费用概况时一般从 DHC_IPBill 查费用总额、从 DHC_IPDeposit 查累计押金、从 DHC_IPSettle 查结算状态三张表要一起看才能判断患者是否欠费。结算日报表DHC_TransationReport和结算日报子表则是门诊收费员的日终报表记录当日每笔收款汇总。银行交易子表与结算日报之间的关联查询是财务对账的常用链路。5. 避坑记录从表结构反推出来的八个隐蔽问题5.1 就诊号前缀与就诊类型不一致现象用 PAADM_ADMNo 前两位筛选门诊和住院数据统计结果与系统界面数据对不上。 原因PA_Adm 的就诊号 OP 开头对应住院IP 开头对应门诊与常规缩写语义相反且存在历史数据中前缀不规范的情况。 解决判断就诊类型一律使用 PAADM_Type 字段O 门诊、E 急诊、I 住院不要解析就诊号字符串。若前期已用就诊号做了筛选逻辑需要排查存量需求的过滤条件逐条改为类型字段判断。5.2 长期医嘱执行次数统计不准确现象统计某患者长期医嘱执行次数时用 OE_OrdItem 里的记录数直接当次数数值偏小。 原因长期医嘱在 OE_OrdItem 只存一条记录每次执行发药、输液等记录在医嘱执行情况表 OE_OrdExec 中。 解决统计执行次数用 OE_OrdExec 做 GROUP BY按医嘱明细 IDOEORI_RowId分组。如果是按天统计护士执行工作量还要加执行时间字段的范围条件注意执行时间是 datetime 两个字段只过滤日期容易漏掉跨天记录。5.3 医嘱状态过滤遗漏导致检验数据多出废单现象查询检验记录数量与检验系统 LIS 的上报数量对不上HIS 侧数量明显偏多。 原因医嘱状态表中有作废状态查询时没有过滤。比如医生开立检验申请后病人退费或者医生撤销医嘱OE_OrdItem 中该状态可能不是正常。 解决在化验申请相关的所有查询语句中JOIN 医嘱状态字典表并增加正常状态的过滤条件。留意有多个正常状态编码的情况勿在 SQL 里硬编码一个绝对值先列出状态字典表人工确认属于正常状态集的记录再过滤。5.4 新增医嘱项在医生工作站不可见现象在 ARC_ItmMast 中新增医嘱项后医生开医嘱界面找不到。 原因医嘱和收费项目没有关联此类项目在开单界面被过滤。 解决确认应在 DHC_TarItemRef 中插入关联记录配置医嘱项与收费项目的绑定关系同时确认收费项目已正确设置了收费标准。用脚本查未关联收费项目的医嘱项批量修复遗漏的关联关系。5.5 病人民族取数路径搞混现象报表展示病人民族信息大量显示为空。 原因民族信息存在 PA_Person病人基本信息主表关联的 CT_Nation 里而不是 PA_Patmas 直接关联。文档里 PA_Adm 关联 PA_Patmas 的表结构中PAPER_Nation_DR 在 PA_Person 表中。 解决取民族字段要走 PA_Patmas → PA_Person → CT_Nation 的三表链路。写 SQL 时注意关联字段PA_Person.PAPER_PAPMI_DR PA_Patmas.PAPMI_RowId再通过 PA_Person.PAPER_Nation_DR 关联 CT_Nation。做完就记住PA_Patmas 管身份主索引社会属性在 PA_Person。5.6 病区与科室的关系不清晰现象查住院病人所在病区直接关联 CT_LOC发现结果在科室、病区之间混淆。 原因病区和科室都存于 CT_LOC通过 CTLOC_Type 字段区别W 表示 Ward 病区OR 表示门诊诊室E 表示执行科室等。部分业务场景需要病区语义却用了科室编码去筛选。 解决查病区必须用 CTLOC_Type W 过滤。住院病人当前病区来自 PA_Adm.PAADM_CurrentWard_DR住院科室来自 PAADM_DepCode_DR二者不可混用。若查询前台页面上的住院科室多数指向病区Ward而非开单科室。6. 从表结构到实用资产写查询脚本的标准姿势把这份表结构文档变成可复用的开发资产建议第一次接触这套 HIS 时不要零散地写查询语句先花两小时跑一遍主链路验证。从病人登记号入手依次查到基本信息、本月就诊记录、具体医嘱明细再到账单费用汇总完整走通一遍后表的关联关系基本就能记住大半。-- 主链路验证查询病人主索引 → 就诊记录 → 医嘱明细 SELECT p.PAPMI_No AS 登记号, p.PAPMI_Name AS 姓名, a.PAADM_ADMNo AS 就诊号, a.PAADM_Type AS 就诊类型, o.OEORI_RowId AS 医嘱ID, ai.ARCIM_Desc AS 医嘱名称, o.OEORI_Status_DR AS 医嘱状态 FROM PA_Patmas p LEFT JOIN PA_Adm a ON p.PAPMI_RowId a.PAADM_PAPMI_DR LEFT JOIN OE_OrdItem o ON a.PAADM_RowID o.OEORI_Adm_DR LEFT JOIN ARC_ItmMast ai ON o.OEORI_ItmMast_DR ai.ARCIM_RowId WHERE p.PAPMI_No 0007654321 ORDER BY a.PAADM_AdmDate DESC;写完后检查三个容易出问题的点一是最大粒度 (PAPMI) 的表是否 main 表是否出现因 join 导致的主表记录重复二是诊疗状态字典、医嘱状态字典这类维度表是否按 needed 的个性度 join避免人士接上太多维表导致结果膨胀三是字段含义随手备注便于将来直接复用。每次新需求来临时先把对应的链路画出来再落 SQL。从那以后每次接到新报表需求只要涉及病人、医嘱、费用三个实体我都强制自己先写下表和关联字段的注释草稿再开写查询。这步操作看着多余却能避免写一半发现关联错字段的返工。这套表结构的文档虽然信息量大但你要懂得把表结构文档转化成查询链路口诀。希望这份拆解和分析对你有帮助把文档读薄把链路记牢遇到问题才能快速定位。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
