简介面向医疗信息化工程师、HIS 实施与运维人员的《天健医院信息系统数据结构手册》聚焦天健 HIS 数据库表结构说明帮助不了解该系统的技术人员快速掌握数据组织方式胜任接口开发、报表取数与数据核对等实际工作。压缩包内为 1 个 doc 文档约 7.19MB以表格与字段说明的形式系统梳理公共字典、人员属性、国家地区与单位属性、科室字典等模块逐一列出 SEX_DICT、STAFF_DICT、DEPT_DICT、CLINICAL_DEPT_CONFIG 等表的用途与字段含义并标注在用、新增与未使用字段的区分规则方便读者按模块检索定位。已有 852 人学习下载可作为熟悉天健 HIS 数据模型的案头查询资料也能为数据字典整理和跨系统对接提供参照。1. 一份 Word 手册撑起一套二十年 HIS 的数据库全景接手一套跑了二十年的 HIS最难的不是代码土而是打开数据库看到上千张表没人告诉你哪张是主表、哪张早就废弃。我第一次接触这套系统时手里唯一的资料就是一份 Word 写的《数据结构手册》目录从公共部分一路排到门诊收费十七个业务域、几百张表名没有 ER 图没有建表语句只有表名、中文名和一句用途说明。它本身就是那个年代做数据库文档的标准产物先有表再有说明最后补一句“新增”“不使用”。这份手册面向的人很具体——要给这套 HIS 做报表、写接口、做数据迁移的工程师。系统 1996 年立项2006 年整理到第 15 稿字典表、病人主索引、医嘱、费用、药品库存全挤在一个主库里谁想绕开手册直接靠字段名猜业务基本都会翻车。下面按我拆它的顺序走一遍全局结构、门诊主线、药品库存、几个必须知道的坑最后落到怎么拿它当数据字典写二次开发 SQL。2. 表结构全景十七个业务域怎么分成字典层、主数据层和流水层2.1 目录本身就是一张模块地图把手册目录抄到一张纸上这套库的骨架就出来了。公共部分管人员属性从性别字典SEX_DICT、婚姻状况MARITAL_STATUS_DICT、民族NATION_DICT、血型BLOOD_TYPE_DICT一直到职业分类、身份、军种、勤务、费别、病人来源、入院方式、出院方式、病情状态全是最底层的枚举接下来是国家地区与单位属性COUNTRY_DICT、AREA_DICT、HOSPITAL_CONFIG、UNIT_IN_CONTRACT、DEPT_DICT再往下是医疗工作域号类别、检查类别、医嘱类别、病案状态、床位类型全在这一段疾病诊断与医疗操作放的是DIAGNOSIS_DICT、OPERATION_DICT、CLINIC_ITEM_DICT、LAB_ITEM_DICT这类“全院共用一套编码”的项目字典药品物资、费用、系统维护、输入法各占一章。后半段才是业务流水病案、门诊病人管理、门诊医生、住院病人管理、医嘱、检查、检验、药品管理、门诊收费。目录排到第 17 章门诊收费就断了按老 HIS 的惯例后面还有住院收费、物资、统计报表几块我一般会先到库里把实际存在的模块补全再动工。这个顺序不是随便排的它反映的是依赖关系前面的字典表被后面的流水表引用所以拆库、做数据字典、写接口文档都得顺着这个方向读。反过来从门诊收费往前倒推你会发现一条收据能牵出十几张表很容易迷路。提示手册的章号是有业务含义的写接口文档时直接沿用手册的章号做分组前端和业务方对表的时候能省掉一半沟通成本。2.2 三层结构怎么一眼分出来命名后缀的规律表名全是英文缩写加大写下划线看着乱其实后缀非常规整摸清后缀比背表名有用得多。后缀含义典型表_DICT字典表代码到名称的映射SEX_DICT、DEPT_DICT、DRUG_DICT_CONFIG/_SETTING配置表控制开关和参数HOSPITAL_CONFIG、APP_CONFIGER_PARAMETER_MASTER/_DETAIL主从结构一对多DRUG_IMPORT_MASTER/DRUG_IMPORT_DETAIL_REC记录表业务发生留下的行BED_REC、MR_REC_LOG日志表只追加不修改ADT_LOG、DRUG_STOP_LOG、MR_TRACE_LOG_TEMP/_T临时表、队列表LAB_RESULT_TEMP、OUTP_ORDERS_T_VS_对照表两张主表的多对多DEPT_VS_WARD、CLINIC_VS_CHARGE_INDEX索引/主索引表PAT_MASTER_INDEX、MR_INDEX_VS_这一类值得单独说。手册里出现了一大批对照表CHARGE_TYPE_VS_IDENTITY费别与身份、DEPT_VS_WARD科室与病房、STAFF_VS_GROUP人员与工作组、CLINIC_VS_CHARGE诊疗项目与价表、LAB_ORDER_VS_REPORT检验申请与报告项目、BED_VS_AIRCONDITION、EQUIP_VS_FEE_DICT、MODALITY_VS_LOCAL_ID_CLASS。这是老系统在不用外键约束的前提下做解耦的惯用手法——两张主表各自独立维护中间用对照表挂起来改一边不影响另一边。我一般在动手写业务 SQL 之前会先把库里的字典表和对照表清点一遍规模心里有数了再看流水表就不会慌-- Oracle把所有以 _DICT 结尾的表捞出来先看清字典层有多大规模 SELECT table_name FROM all_tables WHERE owner HIS AND table_name LIKE %\_DICT ESCAPE \ ORDER BY table_name; -- 再把对照表单独列一份这些表通常是多对多关系的唯一入口 SELECT table_name FROM all_tables WHERE owner HIS AND table_name LIKE %\_VS\_% ESCAPE \ ORDER BY table_name;第一条 SQL 用的是 Oracle 数据字典视图ALL_TABLESOWNER换成实际 schema 名LIKE里的反斜杠是转义符因为下划线在LIKE里是通配符不转义会把_DICT匹配成“任意字符 DICT”。如果库是 SQL Server把ALL_TABLES换成INFORMATION_SCHEMA.TABLES条件改成TABLE_NAME LIKE %[_]DICT。这两条语句跑完你会得到一份几十张字典表加十几张对照表的清单这就是整个库的“常量池”后面所有流水表里的XXX_CODE字段基本都能在这份清单里找到出处。2.3 公共字典表为什么值得先啃公共部分那三十来张表结构高度雷同一个代码、一个名称、一个输入码拼音码、一个标准码、一个有效标志。差别只在业务含义。这类表的价值在于它们是所有业务表的外键目标读懂一张就等于读懂三十张。真正需要花时间的是几类“不那么标准”的字典。STAFF_DICT存工作人员但人员还会出现在STAFF_VS_GROUP分组情况、DOCTOR_GROUP医生核算组、USERS用户记录手册明确标了“不使用”里同一个医生在不同表里扮演不同角色接口取“开单医生”时到底该连哪张得看业务语义。DEPT_DICT更是重灾区围绕它至少有CLINICAL_DEPT_CONFIG临床科室配置、DEPT_CLINIC_ATTR_DICT临床属性、DEPT_OI_ATTR_DICT门诊住院属性、DEPT_IS_ATTR_DICT内外科属性、DEPT_VS_WARD科室与病房对照五张附属表一个科室的完整画像要靠六张表拼出来。我这里有个血泪经验别指望一次把字典表全搞懂按当前任务需要的那条链路去读。做门诊报表就只啃号类别、费别、科室、人员这四五张剩下的等用到再说。3. 门诊主线拆解从挂号、就诊到收据一次门诊在库里留下哪些行3.1 挂号链路从排班到号表再到结账门诊这条线在手册里分散在第 10 章门诊病人管理、第 11 章门诊医生、第 17 章门诊收费三处读的时候得自己在脑子里拼起来。起点是CLINIC_TYPE_DICT号类字典和CLINIC_TYPE_SETTING号类设置表号类别决定了挂号的类型、价格、是否限号CLINIC_INDEX门诊号别定义和CLINIC_SCHEDULE门诊安排记录排的是“哪天哪个科室哪个医生出什么号”CLINIC_FOR_REGIST门诊号表才是真正可被挂走的号源记录CLINIC_APPOINTS门诊预约记录挂的是预约。这三张表的关系是老 HIS 的经典设计排班是模板号表是实例预约是占位。挂号成功后钱的部分进REGIST_ACCT_MASTER挂号结账主记录、REGIST_ACCT_DETAIL明细、REGIST_ACCT_MONEY金额分类退号进CLINIC_RETURNED_ACCT发票重打留REGIST_REPRINT_LOG。这一整套是围绕“挂号员日结”设计的主记录按结账批次走明细按号别走金额分类按支付方式走三层结构跟财务对账的口径完全一致。提示REGIST_REPRINT_LOG这种表在数据迁移时经常被忽略但它记录了发票号的重复使用情况迁漏了会导致新系统发票号冲突。3.2 就诊与医嘱CLINIC_MASTER 是主心骨病人真正进诊室之后主表是CLINIC_MASTER就诊记录。这张表是门诊所有业务行的父记录医嘱、处方、检查治疗申请、诊断、体征全挂在它下面。手册第 11 章里OUTP_ORDERS门诊医嘱主记录、OUTP_PRESC处方医嘱明细、OUTP_TREAT_REC检查治疗医嘱明细三张表构成了门诊医嘱的主体主记录一行代表一次开单行为明细按项目拆处方和检查治疗分表存是因为它们的后续流程完全不同——处方要走药房检查治疗要走医技科室。这里有个容易踩错的地方OUTP_ORDERS_T、OUTP_PRESC_T、OUTP_TREAT_REC_T这三张带_T后缀的表和主表字段几乎一样。它们不是备份是队列中间表医生站提交后先进_T后台进程消费完再落正式表。查实时数据查正式表查“刚开还没落库”的查_T两张一起查才是完整视图但千万别把_T当权威数据源做统计。下面这条 SQL 是我常用的门诊主线串联骨架从就诊记录一路连到费用明细-- 按 病人ID 就诊号 串起一次门诊就诊 → 医嘱 → 计价 → 收据 SELECT cm.PATIENT_ID, cm.VISIT_ID, pmi.NAME, oo.ORDER_NO, oo.ORDER_CLASS, -- 医嘱类别对应 ORDER_CLASS_DICT oc.ITEM_CODE, oc.ITEM_NAME, oc.AMOUNT AS 计价金额, rm.RCPT_NO AS 收据号 FROM CLINIC_MASTER cm JOIN PAT_MASTER_INDEX pmi ON pmi.PATIENT_ID cm.PATIENT_ID LEFT JOIN OUTP_ORDERS oo ON oo.PATIENT_ID cm.PATIENT_ID AND oo.VISIT_ID cm.VISIT_ID LEFT JOIN OUTP_ORDERS_COSTS oc ON oc.PATIENT_ID oo.PATIENT_ID AND oc.VISIT_ID oo.VISIT_ID AND oc.ORDER_NO oo.ORDER_NO LEFT JOIN OUTP_RCPT_MASTER rm ON rm.PATIENT_ID cm.PATIENT_ID AND rm.VISIT_ID cm.VISIT_ID WHERE cm.PATIENT_ID :pid AND cm.VISIT_ID :vid;PATIENT_ID是病人主索引里的全局唯一号VISIT_ID是一次就诊的序号这两个字段加上ORDER_NO基本就是这套库的通用主键组合几乎所有门诊业务表都带。注意我对收据表用的是LEFT JOIN且只按病人和就诊号关联——手册里OUTP_RCPT_MASTER并没有医嘱号字段收据和医嘱之间是靠计价明细汇总对齐的不是一对一。这条 SQL 严格说是“一份就诊的所有医嘱 该次就诊的所有收据”的笛卡尔展开实际做对账要按金额汇总后再比直接拿来出报表会重复计数。3.3 收费闭环价表为什么是两张费用这一章第 6 章里最值得琢磨的是PRICE_LIST价表和CURRENT_PRICE_LIST当前价表并存。老 HIS 里几乎所有价格类数据都是这个套路一张历史表存全量变更记录一张当前表只存生效中的那条查当前价走小表快查历史价走大表全。DRUG_PRICE_LIST对应药品价EXP_PRICE_LIST对应消耗品价PREPARATION_PRICE_LIST对应制剂价结构思路一致。价表往业务表走要经过CLINIC_VS_CHARGE临床诊疗项目与价表项目对照这就是前面说的_VS_解耦。医生开的是诊疗项目收费收的是价表项目中间靠对照表翻译一个诊疗项目可以对应多个收费项比如一次手术拆成手术费、麻醉费、材料费这个设计在 2006 年是很超前的代价是对照表维护不好就会漏费。调价之后核对历史价和当前价是否一致是我每次版本升级后必跑的检查-- 调价后自检同一价表项目在历史表和当前表里价格对不上的行 SELECT c.ITEM_CODE, c.ITEM_NAME, p.PRICE AS 历史价, c.PRICE AS 当前价, c.START_DATE AS 当前价生效日 FROM CURRENT_PRICE_LIST c JOIN PRICE_LIST p ON p.ITEM_CODE c.ITEM_CODE AND p.STOP_DATE IS NULL WHERE p.PRICE c.PRICE;STOP_DATE IS NULL表示这条历史价还没失效正常情况下一个项目最多只有一条未失效记录。查出来有行要么是调价时只更新了当前表没写历史表要么是历史表里残留了未关闭的旧记录。ITEM_CODE是价表项目编码START_DATE/STOP_DATE是价格的生效区间这两个字段是做“某天的价格是多少”这类查询的唯一依据别用当前表去反推历史。4. 药品与库存批次、库存、价表三本账怎么对上4.1 药品字典和价表为什么分开药品这一块在手册里占了第 5 章药品物资和第 16 章药品管理两大块前者是基础字典后者是库存业务。DRUG_DICT药品字典存药品的基本属性——规格、剂型、毒理分类、处方属性、摆药类别DRUG_PRICE_LIST单独存价格DRUG_NAME_DICT存别名DRUG_CODING_RULE存编码规则DRUG_INFO存扩展信息DRUG_INCOMPATIBILITY存配伍禁忌。把价格从字典里拆出来是因为药品调价比改字典频繁得多而且调价要留痕。DRUG_PRICE_MODIFY调价记录和DRUG_PRICE_MODIFY_PROFIT调价盈亏表就是配套的前者记“什么时候从多少调到多少”后者记“调价那一刻库存值多少钱、差异多少”。这两张表在做药品成本核算时是必需的只查当前价会算不出历史成本。DRUG_CLASS_DICT药品类别、DRUG_FORM_DICT剂型、DRUG_TOXI_PROPERTY_DICT毒理分类、DRUG_PRESC_ATTR_DICT处方属性、DRUG_DISP_PROPERTY_DICT摆药类别这几张是典型的多维度分类同一盒药会同时落在五个分类体系里做药品统计时选哪个维度决定结果口径这一点在写报表需求时必须跟业务确认清楚。4.2 入库出库主从表与库存表的扣减关系库存这一块的模型是标准的主从加余额DRUG_IMPORT_MASTER/DRUG_IMPORT_DETAIL记入库DRUG_EXPORT_MASTER/DRUG_EXPORT_DETAIL记出库DRUG_STOCK记当前结存DRUG_STORAGE_PROFILE定义库存单位DRUG_STORAGE_DEPT是库存科室DRUG_SUB_STORAGE_DICT是库房DRUG_STOCK_LOCATION管货位LOCATION是货位名字典。关键在于DRUG_STOCK是一张被反复更新的余额表不是视图。也就是说账面库存的正确性完全依赖出库入库程序有没有在同一事务里改明细和改余额。老系统里这块最容易出问题的场景是并发发药——两个药房窗口同时发同一批药余额被覆盖。手册不会写这个但你从表结构就能推出来DRUG_STOCK上没有版本号字段说明并发控制是靠数据库行锁或者应用层串行做到的。做库存对账我是这么查的-- 药品库存对账账面结存 vs 期间入库 - 期间出库 SELECT s.STORAGE_CODE, -- 库房 s.DRUG_CODE, -- 药品 s.QUANTITY AS 账面结存, NVL(i.QTY, 0) AS 期间入库, NVL(e.QTY, 0) AS 期间出库, NVL(i.QTY, 0) - NVL(e.QTY, 0) AS 期间净变动 FROM DRUG_STOCK s LEFT JOIN (SELECT DRUG_CODE, STORAGE_CODE, SUM(QUANTITY) QTY FROM DRUG_IMPORT_DETAIL WHERE IMPORT_DATE BETWEEN :d1 AND :d2 GROUP BY DRUG_CODE, STORAGE_CODE) i ON i.DRUG_CODE s.DRUG_CODE AND i.STORAGE_CODE s.STORAGE_CODE LEFT JOIN (SELECT DRUG_CODE, STORAGE_CODE, SUM(QUANTITY) QTY FROM DRUG_EXPORT_DETAIL WHERE EXPORT_DATE BETWEEN :d1 AND :d2 GROUP BY DRUG_CODE, STORAGE_CODE) e ON e.DRUG_CODE s.DRUG_CODE AND e.STORAGE_CODE s.STORAGE_CODE WHERE s.QUANTITY 0;这里用子查询而不是 CTE是因为 2006 年前后的库很多还在 Oracle 8i / 9iWITH语法不一定支持写成相关子查询兼容性最稳。STORAGE_CODE是库房标识DRUG_CODE是药品编码两个一起才是库存的唯一键——同一个药品在门诊药房和住院药房是两条独立余额。NVL是 Oracle 的空值转零函数SQL Server 里对应ISNULL。这条 SQL 只能查出“账面和流水对不上”的嫌疑行真正定位还得结合DRUG_STOCK_BALANCE结转记录看期初是不是就错了。4.3 住院摆药链路里那几张临时表住院用药走的是另一条线医生开医嘱进ORDERS护士站确认后生成DRUG_DISPENSE_REQ摆药请求药房摆药生成DRUG_DISPENSE_REC摆药记录住院处方本身存在DOCT_DRUG_PRESC_MASTER/DOCT_DRUG_PRESC_DETAIL而DRUG_PRESC_MASTER_TEMP/DRUG_PRESC_DETAIL_TEMP是待发药状态的临时表。这套设计的意图是正式处方表只存已发药的临时表存流程中的。查“病人现在有什么药还没发”查临时表查“病人历史上用过什么药”查正式表加医嘱表。我见过有人只查正式表做用药史统计结果把当天的药全漏了这种问题不看表名后缀很难发现。摆药请求到实发的核对-- 摆药链路核对申请了但没实发的行 SELECT r.PATIENT_ID, r.ORDER_NO, r.DRUG_CODE, r.QUANTITY AS 申请量, d.QUANTITY AS 实发量 FROM DRUG_DISPENSE_REQ r LEFT JOIN DRUG_DISPENSE_REC d ON d.REQ_NO r.REQ_NO WHERE r.REQ_DATE :biz_date AND (d.REQ_NO IS NULL OR d.QUANTITY r.QUANTITY);REQ_NO是摆药请求号作为两张表的连接键QUANTITY在请求表和记录表里语义相同都是数量但单位可能因为拆零包装而不一致核对前要先确认两边是不是同一个计价单位这一点手册里通常在药品字典那一章用一句话带过很容易漏读。5. 排查与避坑手册里那些「不使用」标记最容易让人翻车5.1 颜色标记这套东西在电子版里等于没有手册开头有一句说明红字标识的表及字段是“未使用状态”蓝字标识的是“新增且在用”黑字是“在用”。问题在于——这份东西是 Word 文档一旦转成 PDF、打印出来、截图发出去红色和黑色几乎分不出来。我拿到的第一份拷贝就是灰度打印稿满篇黑字完全不知道哪些表是废弃的。现象是查出来的数据全是空的或者明显是十几年前的残留原因就是照着灰度稿把废弃表当在用表用了。解决办法很土但有效不要相信颜色直接去库里数行数、看最大更新时间和依赖它的存储过程。手册只是索引库才是事实。5.2 排查清单五个真实踩过的坑坑一标了“不使用”的表里还有数据。手册里USERS、DOCTOR_ORDERS、CLINIC_MASTER_DAYNUMBER_TEMP、ALERGY_DRUGS、EXAM_MASTER_OUTP都标了“不使用”但库里这些表可能还留着历史数据甚至有老模块在写。直接删表会炸正确做法是先确认没有程序引用再考虑归档。查一下这些表到底有没有数据-- 手册标“不使用”的表先确认库里是真空表还是仍有数据 SELECT USERS AS TBL, COUNT(*) AS CNT FROM USERS UNION ALL SELECT DOCTOR_ORDERS, COUNT(*) FROM DOCTOR_ORDERS UNION ALL SELECT ALERGY_DRUGS, COUNT(*) FROM ALERGY_DRUGS UNION ALL SELECT EXAM_MASTER_OUTP, COUNT(*) FROM EXAM_MASTER_OUTP;UNION ALL把多张表的行数拼成一张结果集比一张张查快得多。COUNT(*)在千万级表上会慢生产环境建议换成查ALL_TABLES.NUM_ROWS估算值只在可疑表上做精确计数。坑二目录里有重复条目。手册 11.1 和 11.2 都叫OUTP_MR门诊病历记录10.25 和 11.21 都叫OUTP_QUEUE_SEQUENCE。这不是排版错误是同一张表被门诊挂号和门诊医生两个模块共用。现象是你在 A 模块文档里看到的字段说明和 B 模块里的对不上。原因是这张表被多方写入各自只加了自己关心的字段。解决办法是改字段前用ALL_TAB_COLUMNS拉一遍真实字段清单再反查依赖它的视图和存储过程。-- 拉单表真实字段和手册条目逐条对别信目录里的重复描述 SELECT column_id, column_name, data_type, data_length, nullable FROM all_tab_columns WHERE owner HIS AND table_name OUTP_MR ORDER BY column_id;COLUMN_ID是字段在表里的物理顺序老表经常靠顺序表示业务含义比如前几个字段固定是主键这个信息比字段名本身还有用。坑三把_T队列表当正式表统计。现象是门诊量统计每天多出几十条重复记录。原因是统计 SQL 同时查了OUTP_ORDERS和OUTP_ORDERS_T一条医嘱在提交瞬间两张表都有。解决办法是只认正式表_T表仅用于排查“卡住的医嘱”。坑四病人主索引合并后按PATIENT_ID关联查不全。老 HIS 允许合并重复的病人档案合并动作记在PMI_MERGED_LOG里PAT_MASTER_INDEX只留合并后的主记录。现象是某个病人明明有十次就诊查出来只剩八次。原因是另外两次挂在被合并掉的旧 ID 上。解决办法是查历史数据时先读合并日志把旧 ID 映射成新 ID 再聚合。坑五医院定制表混在通用表里。分诊那批OUTP_COUNSEL_*表、某些盘点表都是给特定医院加的定制功能通用版本里根本没有。现象是照着手册写代码部署到另一家医院报表不存在。解决办法是上线前跑一遍建表脚本比对把定制表和通用表分开维护别混在一份迁移脚本里。6. 二次开发拿这份手册当字典先搭一条最小验证链路我拿这份手册做二次开发流程基本固定先在目录里定位表归属哪个业务域再用ALL_TAB_COLUMNS拉真实字段然后搭一条最小链路验证关联关系对不对最后才写业务逻辑。最小链路我一般选“病人 → 就诊 → 科室”这条因为它跨了主索引、业务主表、字典表三层能一次校验三类问题-- 最小验证视图就诊记录关联科室字典顺手暴露脏数据 CREATE OR REPLACE VIEW V_PAT_VISIT_CHK AS SELECT v.PATIENT_ID, v.VISIT_ID, v.DEPT_CODE, d.DEPT_NAME FROM PAT_VISIT v LEFT JOIN DEPT_DICT d ON d.DEPT_CODE v.DEPT_CODE; -- 科室名对不上的行就是字典改过但业务表没同步或者科室被停用了 SELECT COUNT(*) AS 异常行数 FROM V_PAT_VISIT_CHK WHERE DEPT_NAME IS NULL;PAT_VISIT是住院主记录DEPT_CODE是入院科室代码DEPT_DICT是科室字典。用LEFT JOIN而不是INNER JOIN就是为了把匹配不上的行留下来——INNER JOIN会把这些脏数据悄悄过滤掉看着一切正常等业务方拿着病人骂上门才发现。这个视图一旦建好后面所有涉及科室的查询都能直接复用比每次现写 join 稳。改造时要避开的两个方向一是别在字典表上加业务字段字典表被全院几十个模块读加字段容易撞名二是别直接改_TEMP表的结构那几张表的字段顺序被后台进程按位置读取加一列就可能整条链路停摆。从那以后我每次接老库都强制先跑一遍字典表清点、再搭一条最小链路做连接测试两步都过了才动手写第一条业务 SQL。这份手册的价值不在于它写得多全而在于它给了你一个可以逐个验证的入口剩下的靠库自己去对。希望帮到你。本文还有配套的精品资源点击获取