简介天健医院信息系统数据结构手册是一份面向HIS系统工程师、数据库维护人员的完整数据库表结构说明文档帮助不熟悉底层数据结构的读者快速定位字段含义、表间关联及业务字典。内容覆盖公共字典性别、血型、费别、病人来源等、人员属性工作人员、技术职务、工作类别等、国家地区单位、科室字典、临床科室配置等核心模块同时标注了表字段的启用状态、版本更新记录和红蓝字标识规则便于实际开发与数据查询时对照使用。文档按目录化方式组织从公共部分、人员属性到医疗工作分类系统梳理了数十张数据字典与业务表可辅助工程师理解天健HIS的库表设计思路也可作为二次开发、运维排查和测试数据构造的参考手册。资源为单个doc格式文档大小约7.19MB结构清晰便于检索。目前已有850人学习下载适合需要深入理解天健HIS数据库模型的工程师查阅。1. 接手老 HIS 的第一天先别急着连数据库不管你是做运维、做报表还是做接口只要跟医院信息系统打过交道大概率都经历过这种窘境库里几百张表摆在那里字段命名全靠猜同一个“费别”在门诊收费和住院结算里含义不一样医嘱状态码散落得到处都是。这份《天健医院信息系统数据结构手册》版本 1.0.15第 15 稿解决的就是这件事——它把天健 HIS 的 17 大业务模块、数百张表的结构、字典取值、状态含义一次性交代清楚了。更难得的是文档里用红、蓝、黑三种颜色明确标注了每张表和字段的启用状态这在旧系统维护里几乎等于一份带批注的藏宝图。适合谁读被老系统折磨的运维工程师、做数据迁移和报表开发的人以及刚接手天健 HIS 需要快速定位业务的开发者。2. 库表分层逻辑先搞懂字典区、业务主表和流水表的关系2.1 公共字典区26 张基础码表是所有业务的起点手册的第一大部分是公共字典从性别SEX_DICT、婚姻状况MARITAL_STATUS_DICT、民族NATION_DICT、血型BLOOD_TYPE_DICT这类人口学属性到身份IDENTITY_DICT、费别CHARGE_TYPE_DICT、病人来源PATIENT_SOURCE_DICT这类业务属性全部拆成了独立的字典表。这套设计的核心逻辑是业务表里不存中文描述只存代码所有中文名称统一关联字典表翻译。好处很明显改一个科室名称不用动业务表只改字典表。这里有个容易被忽略的点费别和身份之间还有一张对照关系表 CHARGE_TYPE_VS_IDENTITY。某开发者第一次对接医保接口时直接在费别字典里查“医保”两个字结果发现费别和身份是两个维度必须通过这张对照表才能正确映射。实际踩过的坑是有些患者身份是“军队人员”费别却是“地方医保”两套字典交叉组合出十几种情况报表要按组合口径统计少了对照表根本查不准。2.2 医疗业务核心链路病案、医嘱、检查、检验四张主表串起全流程翻到第 9 章病案部分能看到整个系统的主干PAT_MASTER_INDEX病人主索引、PAT_VISIT住院主记录、TRANSFER在科记录构成病人的就诊主线。这个设计有一个很关键的主键约定——PATIENT_ID VISIT_ID 联合定位一次就诊。同一患者多次住院PATIENT_ID 不变VISIT_ID 递增所有业务流水表都挂在这两个字段上。做数据抽取时如果只按 PATIENT_ID 关联会把多次住院的记录全部混在一起报表数据直接翻倍。医嘱链路在第 13 章ORDERS医嘱主记录、ORDERS_COSTS医嘱计价项目、ORDERS_EXECUTE医嘱执行表三层结构。ORDERS 存医生开立的医嘱内容ORDERS_COSTS 把一条医嘱展开成多条计价项目——比如“葡萄糖氯化钠注射液 500ml”这条医嘱会拆出药品费、输液费、一次性耗材费三条费用记录。这是报表对不上账的高发区统计医嘱数量时按 ORDERS 算统计费用时按 ORDERS_COSTS 算两个数天然不一样不是 bug 是设计。检查链路在第 14 章EXAM_MASTER检查主记录和 EXAM_ITEMS检查项目分离一张检查申请单可以包含多个检查部位。检验链路在第 15 章LAB_TEST_MASTER、LAB_TEST_ITEMS、LAB_RESULT 三层检验主记录对标本检验项目对分析指标检验结果存具体数值。值得注意的是第 14 章后半段出现了大量 PACS 相关表PBCATCOL、PBCATEDT、STOREUID 等这是影像归档系统的表虽然不像核心业务表那么常用但做影像调阅接口时必须知道 EXAM_MASTER 怎么跟 PACSSTUDY 关联。2.3 药品与费用从药品字典、库存到价表的闭环药品模块是全手册最重的部分从第 5 章一直铺到第 16 章。基础字典包括 DRUG_DICT药品字典、DRUG_NAME_DICT药品名称字典、DRUG_FORM_DICT剂型字典、DRUG_CLASS_DICT药品类别字典这些是静态数据。动态数据是库存链路DRUG_STORAGE_PROFILE库存定义、DRUG_STOCK库存、DRUG_IMPORT_MASTER/DETAIL入库、DRUG_EXPORT_MASTER/DETAIL出库加上 DRUG_STOCK_BALANCE结转记录形成进销存闭环。药品和费用之间的桥梁是价表。第 6 章单独定义了一套价表体系PRICE_LIST价表、CURRENT_PRICE_LIST当前价表、PRICE_ITEM_NAME_DICT价表项目名称字典。之所以要区分“价表”和“当前价表”是因为药品调价后历史费用不能跟着变每次调价生成新版本价表当前价表只保存最新生效的版本。做费用查询时如果用错表拿历史医嘱去匹配当前价表算出来的金额和收费记录永远对不上。3. 把手册用起来逆向还原 ER 图与三个高频查询场景3.1 模块清单与表命名规律手册就是你的数据字典底图先看整份手册的模块分布大致可以分成这样几个区域区域模块章节典型表基础数据公共部分、人员属性、科室字典、疾病诊断SEX_DICT、STAFF_DICT、DEPT_DICT、DIAGNOSIS_DICT病人主线病案、门诊病人管理、住院病人管理PAT_MASTER_INDEX、CLINIC_MASTER、PATS_IN_HOSPITAL业务执行门诊医生、医嘱、检查、检验、药品管理OUTP_ORDERS、ORDERS、EXAM_MASTER、LAB_RESULT、DRUG_STOCK费用结算费用、门诊收费PRICE_LIST、OUTP_RCPT_MASTER住院相关费用表系统支撑系统维护、输入法SECURITY_USERS、OUTER_CODE_DICT识别表名后缀是最快的上手方式_DICT 结尾的是字典表只存代码和名称_MASTER 结尾的是业务主记录一条记录对应一次业务事件_DETAIL 结尾的是明细子表挂在主记录下面_LOG 结尾的是日志表记录状态变更历史。掌握了这个规律遇到没见过的表也能猜出七八分用途。比如看到 DRUG_PRESC_MASTER 就知道是处方主记录下面一定还有一张 DRUG_PRESC_DETAIL 存具体药品明细。3.2 三个高频 SQL 场景拿到手册就能写对查询场景一查某患者在某次住院期间的全部医嘱及计价明细。核心是 ORDERS 和 ORDERS_COSTS 两张表通过 ORDER_ID 关联。SELECT o.ORDER_ID, o.ORDER_CLASS, o.ORDER_CONTENT, c.ITEM_NAME, c.COSTS, c.AMOUNT FROM ORDERS o LEFT JOIN ORDERS_COSTS c ON o.ORDER_ID c.ORDER_ID WHERE o.PATIENT_ID :patient_id AND o.VISIT_ID :visit_id ORDER BY o.ORDER_ID, c.ITEM_NO;这里的关键点是 ORDER_ID 在 ORDERS 表里是主键在 ORDERS_COSTS 里是外键。一条医嘱可能拆出 0 到多条计价明细比如长期医嘱“二级护理”在 ORDERS_COSTS 里可能只有一条费用记录但“静脉输液”这种医嘱会拆出药品、耗材、操作费好几条。用 LEFT JOIN 能保住没有计价项目的医嘱避免漏数。实际做临床科室核算时发现有些科室的医嘱漏传费用LEFT JOIN 一眼就能揪出来——COUNT 一下 ORDER_ID 为空的数量就是漏计费医嘱条数。场景二查药品库存流水需要把 DRUG_STOCK、DRUG_IMPORT_DETAIL、DRUG_EXPORT_DETAIL 三张表按药品编码关联。SELECT d.DRUG_CODE, d.DRUG_NAME, COALESCE(i.IMPORT_QTY, 0) - COALESCE(e.EXPORT_QTY, 0) AS STOCK_QTY FROM DRUG_DICT d LEFT JOIN ( SELECT DRUG_CODE, SUM(QTY) AS IMPORT_QTY FROM DRUG_IMPORT_DETAIL WHERE IMPORT_DATE BETWEEN :date_from AND :date_to GROUP BY DRUG_CODE ) i ON d.DRUG_CODE i.DRUG_CODE LEFT JOIN ( SELECT DRUG_CODE, SUM(QTY) AS EXPORT_QTY FROM DRUG_EXPORT_DETAIL WHERE EXPORT_DATE BETWEEN :date_from AND :date_to GROUP BY DRUG_CODE ) e ON d.DRUG_CODE e.DRUG_CODE WHERE d.DRUG_CODE :drug_code;这段脚本注意两个坑一是 DRUG_IMPORT_DETAIL 和 DRUG_EXPORT_DETAIL 里存的 QTY 可能是入库单位数量不是处方单位数量必须先查 DRUG_DICT 里的单位和换算系数二是药品存在退库和退药的情况明细表里会出现负数金额直接 SUM 会把负数抵消掉对账时要单独把退货记录筛出来核对否则月底盘点和财务对不上。场景三查门诊医生开具的处方主表是 OUTP_PRESC关联 DRUG_PRESC_MASTER 和 DRUG_PRESC_DETAIL。SELECT p.RCPT_NO, m.DRUG_CODE, m.DRUG_NAME, d.DOSAGE, d.MOUNT, d.UNIT_PRICE FROM OUTP_PRESC p JOIN DRUG_PRESC_MASTER m ON p.PRESC_NO m.PRESC_NO JOIN DRUG_PRESC_DETAIL d ON m.PRESC_NO d.PRESC_NO WHERE p.VISIT_DATE :visit_date;实际复用这套查询时发现同一张处方在 DRUG_PRESC_MASTER 里只有一条主记录但在 DRUG_PRESC_DETAIL 里可能有几十条明细而且明细记录的排序是按药品添加顺序不是按药理分类。手册里对这个表的说明很明确DETAIL 表不保证顺序要按 DRUG_CODE 分组统计时最好先做 GROUP BY 再联主表。3.3 容易被忽略的特色模块输入法词库和制剂管理第 8 章单独讲输入法配置这是老 HIS 系统比较有年代感的设计。OUTER_CODE_DICT输入码表里存了所有药品、诊断、科室的拼音码、五笔码、自定义助记码收费员录入时敲几个字母就能带出全名。这套设计的核心是“编码即检索”但不同医院维护的词库不一致某医院的药品拼音码是 YPGJJ另一家可能完全不一样。做数据迁移时输出码表必须随业务数据一并迁移否则换系统后收费员的工作习惯全打乱。制剂管理是第 16 章后半段的内容PREPARATION_DICT、PREPARATION_PRESC、PREPARATION_COST 覆盖了医院自制药剂的配制、成本核算、检验全流程。这套模块不是每家医院都启用手册里同样标注了“不使用”的表。遇到这种表不用花精力去拆逻辑但要保留在数据库里因为有些报表程序还在读它们删了会直接报错。4. 落地改造必看字段状态标记、易混表与历史遗留表4.1 红蓝黑字标记先分清哪些是活表、哪些是标本这份手册最实用的细节是它的颜色标记规则红字标识的表和字段是未使用状态蓝字标识的是新增且在用状态黑字标识的是在用状态。也就是说整份手册翻下来黑字表是当前运行的正式表蓝字表是后来迭代新加的红字表是已经被淘汰但还留在库里的。这个信息极其关键。某开发者在做一个医保接口时按手册索引找到了两张名字几乎一样的表——MEDICARD_CONFIG 和 MEDICAL_CARD_CONFIG一张蓝字、一张红字。蓝字的表里有最新的卡类型配置红字的那张是同一个项目早期试运行的备份结构只有一半字段是相同的。如果不看颜色标记新手极大概率会把红字表当成正式表接口对接还没开始就已经错了。每次做字段梳理前先按颜色把表分成三类只对黑字表建正式的数据字典蓝字表单独建一个“扩展字段清单”红字表直接拉黑不参与任何新开发。4.2 长得像但别混用的几组表手册里有几组表名极易搞混整理一个表格对比组别表名差异点价表组PRICE_LIST / CURRENT_PRICE_LISTPRICE_LIST 是所有历史价CURRENT_PRICE_LIST 只保留当前版本病人主索引PAT_MASTER_INDEX / PAT_VISIT前者是一个人一条记录后者是一次住院一条记录门诊医嘱OUTP_ORDERS / OUTP_ORDERS_T带 _T 后缀的是临时队列表处理完就清空药品处方DRUG_PRESC_MASTER / DRUG_PRESC_DETAILMASTER 存处方头DETAIL 存具体药品明细检查记录EXAM_MASTER / EXAM_ITEMS一张检查单对应多个检查项目一对多关系容易翻车的是 OUTP_ORDERS 和 OUTP_ORDERS_T 这组。过去在门诊医生站里医生提交医嘱后先写入 _T 临时表收费完成后才转入正式表 OUTP_ORDERS。如果程序异常中断_T 表里会残留已开立但未收费的单据。做行为分析时如果直接统计 _T 表会把未完成单据也算进去数据严重虚高。4.3 “不使用”的表为什么还需要留着手册里有一批标注“不使用”的表比如自动生成 ID 表 AUTO_SETTING标为不使用但手册又列出了 AUTO_SETTING_ID 表。这两张表的关系是AUTO_SETTING 是旧版配置界面用的表已废弃AUTO_SETTING_ID 是当前系统里真正用于生成主键 ID 的表关联的是各业务表的最大号值。这类表不能物理删除——它们可能还被老程序引用或者还有历史数据需要做审计。正确做法是在新系统里保留原表结构但不再写入新数据用视图或新表替代最后再通过手册里的颜色标记逐一核对哪些表已经失去引用与业务方确认后再决定归档方式。5. 避坑指南接手天健 HIS 数据时最常见的 5 个翻车现场5.1 翻车一病人主索引重复合并后日志没跟上现象同一患者在系统里存在两条 PAT_MASTER_INDEX 记录一条是 2005 年建档的一条是 2015 年重新挂号时新建的住院史被拆成两段费用统计和病历调阅都不完整。原因老系统没有做强制的主索引查重收费员按姓名和身份证号找不到已有档案时习惯直接新建。手册里虽然有 PMI_MERGED_LOG主索引合并记录但很多医院合并后没有在应用层把历史就诊记录同步迁移。解决处理流程是先查 PAT_MASTER_INDEX 里同名同证件的记录确认后做主索引合并保留其中一个 PATIENT_ID把所有业务表的 PATIENT_ID 统一改写同时在 PMI_MERGED_LOG 里补一条合并记录。从那以后每建一个新接口我都会让开发先跑一遍主索引重复率检查。5.2 翻车二价表取错版本报表收入对不上现象某月财务報表里药品收入比药房实收少了三万元逐笔核对发现收费记录里取的单价和当前价表不一致。原因收费发生时系统按当时的价表计价并写入业务表但报表程序为了算“收入”直接 JOIN 了 CURRENT_PRICE_LIST当前价表反推金额。药品调价后当前价和新价不是同一个数历史收入自然对不上。解决报表统计永远以业务流水里的实收金额字段为准价表只用来核查单价异常。具体做法是拿 OUTP_RCPT_MASTER 的实收金额做汇总不去 JOIN 价表。如果一定要核对某项收费单价是否合理再按收费日期回溯当时生效的 PRICE_LIST 版本而不是用 CURRENT_PRICE_LIST。5.3 翻车三医嘱和计价项目一对多统计口径打架现象临床科室说做了 1000 条输液医嘱财务说只收到 950 笔输液费两边吵到信息科。原因医嘱表 ORDERS 里一条输液医嘱可能对应多条 ORDERS_COSTS 明细——药费、注射费、耗材费分开计。有些医嘱开了但没执行医嘱状态是“停止”或“作废”费用明细自然不存在。解决必须明确医嘱状态字段的流转规则。统计执行工作量时过滤掉非执行状态统计收费时以 ORDERS_COSTS 表为准。遇到过两次这类纠纷后我养成了习惯写任何医嘱相关报表先加一列医嘱状态出来核对数据前先看状态分布。5.4 翻车四检查主表与影像系统关联错位现象影像科报告写完了临床医生在系统里点开报告看到的却是另一个患者的片子。原因EXAM_MASTER 与 PACSSTUDY 的关联不是靠唯一的检查号而是靠 patient_id 和 exam_id 两个字段联合匹配。老系统里同一个 patient_id 多次住院做同一项检查如果影像系统只回传了 patient_id没有回传 exam_id就会把最近一次检查的影像挂到所有同名检查单上。解决核对接口时重点确认影像回传消息里是否包含完整的 exam_id检查申请号不仅仅是患者 ID。一旦出现检查号缺失立即定位到 PACS 接口的 mapping 配置把 EXAM_MASTER.EXAM_ID 与 PACSSTUDY.STUDY_ID 的映射补全。5.5 翻车五药品库存单位与处方单位不一致现象药房盘点时库存数量和处方发药数量差异巨大某药品账上剩余 3000 支实际药架只有 300 瓶。原因DRUG_STOCK 里存的默认单位是“最小包装单位”比如片、支而 DRUG_PRESC_DETAIL 里存的是“处方单位”可能是盒、瓶中间有换算系数。部分药品的换算系数在 DRUG_DICT 里维护了部分药品的换算系数被漏掉系统按默认系数 1 换算导致库存消耗失真。解决做药品进销存对账前先核对 DRUG_DICT 里的单位字段和换算系数重点排查新进药品目录里未维护换算系数的品种。正确的对比口径是把处方发药量统一换算成最小包装单位后再与库存流水比对。6. 反向核对技巧用手册生成一份库表覆盖检查清单与其把手册当字典逐字读不如把它变成一把尺子量一量实际数据库离“标准结构”差多少。做法是先把手册的目录拆成一张期望表清单再反向查数据库的 information_schema两边一比对缺失的表、废弃的表、结构对不上的表全部现形。具体用 Python 脚本最顺手import pymysql conn pymysql.connect( host127.0.0.1, userhis_readonly, passwordyour_password, databasehis_db ) cursor conn.cursor() # 手册里摘出来的表清单按模块整理 expected_tables { 病案: [PAT_MASTER_INDEX, PAT_VISIT, TRANSFER, DIAGNOSIS], 医嘱: [ORDERS, ORDERS_COSTS, ORDERS_EXECUTE], 检查: [EXAM_MASTER, EXAM_ITEMS, EXAM_REPORT], # 其余模块按手册目录逐个补充 } cursor.execute( SELECT TABLE_NAME, TABLE_COMMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA his_db ) actual_tables {row[0]: row[1] for row in cursor.fetchall()} for module, tables in expected_tables.items(): missing [t for t in tables if t not in actual_tables] if missing: print(f[缺失] {module}: {missing}) else: print(f[完整] {module}: {len(tables)} 张表都在) cursor.close() conn.close()这段脚本的思路是先维护一个“期望表清单”再与 information_schema 里的实际表名做差集。有人会问为什么不去解析手册 PDF 自动抽表名因为手册里有些表标注了“不使用”自动抽取会把废弃表也纳入检查反而干扰正常判断。我一般分两步走第一步用脚本核对黑字表是否齐全第二步手动翻蓝字表确认新增表在目标库里确实存在。跑完脚本后数据库里那些手册根本没提过的表也要单独列清单这些通常是第三方系统或本地化扩展建的不在标准范围内。真正做到这一步你对这套 HIS 的结构就算摸透了。自己当初接手第一个 HIS 数据迁移项目时就是靠这份手册建立了一个自动化核查脚本库后来每到一个新环境第一件事就是把核对脚本跑一遍而不是急着写业务查询。从那以后我每次判断一个数据库是否“健康”都强制走一遍期望清单比对流程希望帮到你。本文还有配套的精品资源点击获取