简介：这是一份天健医院信息系统（HIS）的数据库结构手册，专门面向需要对接或维护天健HIS的数据库工程师、开发人员与实施顾问，帮助其快速掌握后台表结构、字段含义与字典分类逻辑。资源以单文件Word文档形式提供，压缩包内仅有1个doc文件，大小7.19MB，全文按公共部分、人员属性、国家地区单位、科室字典、医疗工作、疾病诊断与医疗操作等模块组织，目录层级清晰。文档不仅收录性别、婚姻状况、民族、血型、职业、军种、费别、病人来源等基础字典，还覆盖工作人员、用户、科室字典、临床科室配置、科室与病房对照、工作人员分组、病案、床位、疾病诊断与手术操作等核心表和对照关系；同时用红字/蓝字/黑字分别标注未使用、新增与在用状态，并对第15稿的版本更新记录、编写日期与修改说明做了完整保留，便于追溯不同表字段的演进过程。目前已有850人学习下载，适用于HIS二次开发、数据字典梳理、医院信息化运维和系统间数据对接等场景。
1. 天健医院信息系统数据结构手册：为什么说它是接口工期和报表正确性的分水岭
医院信息化项目里有一类文档，平时躺在服务器共享目录里没人翻，一上线就变成所有集成工程师的救命稻草，它就是天健医院信息系统数据结构手册。这本 doc 本质上是一套数据字典：把天健 HIS 后台数据库里的表名、字段名、类型、长度、主键、中文备注按模块整理出来，告诉你病人主索引放在哪张表、门诊处方和费用明细怎么关联、医嘱状态码里的“3”到底代表什么。做接口对接、统计报表、数据迁移的人，拿到它等于从对着黑匣子猜变成手里有一张地图；没拿到它，就只能靠抓包、逆向前台 SQL 和反复试错，工期翻一倍很正常。这篇笔记不聊 HIS 业务流程，直接把手册和真实库对照着讲：怎么读表、怎么把 doc 转成能落地的查询脚本，以及哪些地方最容易踩坑。
2. 读懂天健HIS数据字典：五类核心表与字段命名的底层逻辑
2.1 先从主索引读起：PAT_MASTER_INDEX 承载的“人”维度
天健 HIS 的表命名有比较清晰的前缀习惯，业务模块用英文缩写区分，例如 PAT、OUTP、INP 分别对应病人、门诊、住院。几乎所有业务表都要关联到病人主索引表，天健这套系统里主索引表的常见名字是 PAT_MASTER_INDEX，它存的是每个患者的基本档案，包括就诊号、姓名、性别、出生日期、证件号码、联系电话等。读这份手册的第一步，不是从头翻，而是先定位这张表，把它作为所有查询的起点。
-- 查病人主索引的基本字段，TOP 10 只取前 10 条确认数据样例 SELECT TOP 10 PATIENT_ID, NAME, SEX, BIRTH_DATE, ID_NO FROM PAT_MASTER_INDEX;这段 SQL 的逻辑很直接：先看患者的唯一标识 PATIENT_ID，再看性别和出生日期的存储格式。我一般会用这一步来快速判断库的整体风格。比如 SEX 字段如果返回的是 1 和 2，说明是代码值，关联的代码表通常叫 DATA_DICTIONARY 或 SEX_CODE；如果直接返回“男”“女”，那说明这台库做了冗余存储。你后续写报表的时候，性别处理方式会完全不同。参数上要注意 PATIENT_ID 在很多部署里不是自增数字，而是 varchar 类型，有的还会带上前缀，例如外院转诊患者会拼上原医院代码，这个细节在手册常见字段说明里不一定写清楚，但写关联条件时直接影响索引利用率。
出生日期也一样：库里的 BIRTH_DATE 可能是 datetime，也可能是 varchar 存的“YYYYMMDD”，我拿到的这本手册里写着“日期型”，但实际上有历史分区表里存的是字符型。所以每次接新环境，我会先跑一条查询确认类型，再写业务 SQL。这个习惯帮我在后面减少了很多返工。
2.2 业务单据表：门诊处方、住院医嘱与状态字段
确认完主索引，就要进入每天都会打交道的业务单据表。门诊这块核心是处方主表和处方明细表，天健常见的命名是 OUTP_PRESC_MASTER 和 OUTP_PRESC_DETAIL，主表存处方号、患者 ID、开单科室、开单医生、处方日期，明细表存药品编码、药品名称、数量、单价、金额。两张表通过 PRESC_ID 关联。住院这边，医嘱表命名常见 ORDERS 或 INP_ORDERS，它比处方更复杂，因为一条医嘱可能有停止时间、执行状态、长期临时标志。
实际写统计和接口脚本的时候，最应该盯的是状态字段。处方有作废标志，医嘱有状态码，而这些状态的取值映射往往不在主文档里，而在手册附录的代码表章节。比如医嘱状态，常见取值有“0 未审核、1 已审核、2 执行中、3 已停止、4 已作废”，但这套取值不是行业标准，每个实施现场可能都不一样。所以先不要急着写死业务逻辑，应该用一条 SQL 把状态字段的所有取值拉出来，再和手册对照：
-- 统计医嘱表里所有状态字段的取值和数量，确认代码含义 SELECT ORDER_STATUS, COUNT(*) AS CNT FROM INP_ORDERS GROUP BY ORDER_STATUS ORDER BY CNT DESC;这条查询的目的不是取数，而是摸底。跑出来的结果如果出现手册里没写的状态码，比如 5、9，就要赶紧找现场实施确认。我最开始接天健库的时候，想当然地认为 ORDER_STATUS=2 是执行中，后来发现这个现场 2 代表“已停止”，导致抽取的正在执行医嘱全部错误。这种亏吃过一次就长记性了：手册是某个版本某个现场的记录，不能代替你面前这台实际库的真实数据。先 GROUP BY，再写条件，这是所有单据表操作的共同顺序。
2.3 金额与结算：费用明细表里最容易被算错的三处字段
门诊收费和住院费用是财务对账的重灾区，对应表名一般是 OUTP_BILL_DETAIL 和 INP_BILL_DETAIL。费用明细表结构上并不复杂，核心字段就几个：收费项目编码、项目名称、单价、数量、金额、结算号、退费标志。真正容易翻车的是三个地方。第一个是金额字段的单位，手册里可能写 numeric(12,2)，你以为是元，实际上这个表按分存储，差 100 倍；第二个是退费记录，有的库用负数金额表示退费，有的库用独立状态字段配合正数金额；第三个是收费项目编码和药品编码共用同一个字段，但关联的目录表不同。
-- 按收费项目汇总住院费用，先看单位是元还是分，再决定是否除以 100 SELECT ITEM_CODE, ITEM_NAME, SUM(COSTS) AS TOTAL_COSTS, COUNT(*) AS BILL_COUNT FROM INP_BILL_DETAIL WHERE BILL_DATE >= '2024-01-01' GROUP BY ITEM_CODE, ITEM_NAME ORDER BY TOTAL_COSTS DESC;这条 SQL 里我故意没有除以 100，因为单位没确认之前，除错比不除更危险。正确做法是先取一条记录，把手工数据——比如住院收费细目屏显的金额——和这个查询结果对比，确认 COSTS 字段的语义，再加上换算。另外，汇总时如果直接 SUM 会把退费记录也包含进去，具体要看 BILL_DATE 这个字段是否在退费时生成一条新的负金额记录。我一般在汇总条件里会加上“记录状态不是退费”的过滤，但退费标志字段名各个现场不一样，有叫 VOID_FLAG、REFUND_FLAG、CANCEL_FLAG 的，写脚本前通过手册的字段说明定位，或者直接查看表字段清单。这个排查过程用到的 SQL 会在下一章展开，它比对着 doc 翻快得多。
3. 把doc手册转成可用的建模脚本：从Word文档到SQL字段清单
3.1 先建表-字段-中文名对照清单：用一条SQL读出全部字段
doc 手册本身是给人看的，不是给代码用的。联调接口或写报表时，你不可能一边翻 Word 一边敲字段名，先把整个库的表和字段导成一张二维清单，才是效率最高的做法。以 SQL Server 为例，靠系统视图就能拿到几乎全部元数据，不需要额外权限：
-- 从系统目录读取所有用户表的字段清单，输出表名、字段名、类型、长度 SELECT t.name AS table_name, c.name AS column_name, TYPE_NAME(c.system_type_id) AS data_type, c.max_length AS col_length, c.is_nullable AS nullable FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id WHERE t.type = 'U' ORDER BY t.name, c.column_id;把这条查询的结果存成 Excel，和手册里的表结构章节逐表对比，你会立刻发现两个问题：库里的表数量远多于手册描述，手册里有一部分表在库中已经改名或废弃。原因是天健 HIS 上线时做过二次开发和升级，数据字典的更新往往跟不上版本。这段 SQL 的关键参数是 max_length，注意它在 SQL Server 里对 nvarchar 返回的是字节数而不是字符数，比如 nvarchar(10) 显示为 20，容易误判长度。我习惯把这一列除以 2 再看，或者直接依赖 INFORMATION_SCHEMA.COLUMNS 里的 CHARACTER_MAXIMUM_LENGTH，它返回的就是字符数。两张视图可互相验证，实际写脚本时我更推荐 INFORMATION_SCHEMA，字段名更直观。
导出清单之后，我建议不要直接删除 doc 手册，而是把它解构成三层对照表：表级说明、字段级说明、代码值映射。表级说明记录“这个表是干什么的、对应业务模块”；字段级说明记录“字段名、中文名、类型、长度、是否必填、备注”；代码值映射专门放状态字段和类型字段的取值含义。这三张表是你后续所有取数脚本的元数据基础。
提示：如果库里存在大量自建扩展表，比如以 EXT_、T_、ZZ_ 开头，通常不属于手册范围。对比时先排除，或者单独分组，避免和 HIS 核心表混在一起影响建模。
3.2 拿系统目录视图校验文档：手册和库不一致时以谁为准
手册和实际库不一致，几乎是必然事件。不同版本、不同实施现场的差异很大，我见过同一个表名 OUTP_PRESC_MASTER，在 A 医院有 30 个字段，在 B 医院有 42 个字段，多出来的 12 个都是个性化需求加的扩展列。这时候的判断原则就一条：以实际库为准，手册只用来理解业务含义，绝对不能拿手册字段清单去生成建表语句。
具体操作上，我会用 EXCEPT 语法快速找出两边差异。先把手册字段做成一张临时表，再和系统目录做差集。实际现场没有解析 doc 的条件时，更快的办法是直接查新增扩展字段的特征：天健二次开发加的扩展列，命名上非常喜欢带前缀，比如 EXT_、CUST_、SPARE1，而且字段备注里往往写着“自定义”“备用”。一条 SQL 就能把这些字段筛出来：
-- 找出手册可能遗漏的扩展字段：名称带 EXT 前缀或者备注为空的新增列 SELECT t.name AS table_name, c.name AS column_name, EP.value AS comment FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN sys.extended_properties EP ON EP.major_id = t.object_id AND EP.minor_id = c.column_id AND EP.name = 'MS_Description' WHERE t.type = 'U' AND (c.name LIKE 'EXT\_%' ESCAPE '\' OR c.name LIKE 'CUST\_%' ESCAPE '\') ORDER BY t.name, c.column_id;这段 SQL 用到了扩展属性视图 sys.extended_properties，它是 SQL Server 里字段中文备注的存放位置。天健的建表脚本如果规范，每个字段都会写 MS_Description，那么通过这段脚本，你能很快定位到哪些表、哪些字段是实施团队后来补上去的。参数上注意 LIKE 转义，下划线在 SQL 里是单字符通配符，所以必须用 ESCAPE '' 配合 '_%' 才能把下划线当普通字符匹配。我第一次写的时候忘了转义，结果把所有字段都筛出来了，以为是系统问题，排查半天才发现是通配符搞的鬼。
3.3 文档里查不到的表：从命名规则反向补全字段注释
有些表手册里完全没有，但业务又在用，典型的就是各类中间表、临时表、排队表、日志表。遇到结构不认识的表，我的排查路径分三步：先看表名前缀判断模块，再看主键和关联字段判断业务定位，最后看是否有扩展属性注释。天健的实际库表名命名比较克制，门诊相关基本是 OUTP_ 开头，住院是 INP_，病人是 PAT_，财务结算包含 BILL 或 ACCT，药品目录是 DRUG_。如果出现一个叫 TMP_CLINIC_QUEUE 的表，不用猜也知道是门诊排队临时表，这种表通常不需要做数据归档，接口也不该去读，因为它会被定时清理，数据随时可能消失。
识别一个陌生表是否值得编写接口，核心是不是它有没有稳定的主键和审计字段。有主键、有 CREATE_DATE、有 UPDATE_DATE，说明是正式业务表；没有主键、纯内存临时表特征，直接忽略。手册查不到时，我会用系统存储过程快速看结构：
-- 查看指定表的结构信息，包含主键、索引、字段类型 EXEC sp_help 'TMP_CLINIC_QUEUE';sp_help 一次返回多组结果集，有字段、索引、约束、外键引用，足够判断表的性质。输出里如果 index_name 为 NULL、主键列为空，就不要花时间深挖了，这种表在接口对接里没有价值。反过来，如果发现它有主键、有费用相关字段，但手册没收录，那就要重视起来，尽快和现场实施确认这张表是否承担了手册里某张旧表的职责。我经历过一次门诊收费对账不平，排查到最后一整天才发现，新版本里结算记录已经写到一张手册没有的 NEW_SETTLEMENT_LOG 表里了，老表只剩历史数据。这个教训说明：手册要信，但不能全信，库里的真实结构才是最终标准。
4. 对接天健HIS的避坑指南：时间分区、金额精度与未知状态码
4.1 坑一：日期字段是 DATETIME 还是 VARCHAR，先查类型再写过滤条件
现象：接口按日期范围抽取门诊记录，漏掉当天部分数据，前端却显示这些记录是存在的。原因：手册对日期字段只写了“日期型”，但这台库的某些分区表把日期存成 varchar(8)，格式是“YYYYMMDD”，而你传入的参数用的是 datetime 类型，隐式转换让索引失效，甚至直接查不到匹配行。解决：写过滤条件之前，先查目标字段的真实类型。
-- 查指定日期字段的真实数据类型，确认是 datetime 还是 varchar SELECT DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'OUTP_PRESC_MASTER' AND COLUMN_NAME = 'PRESC_DATE';如果查出来是 varchar(8)，统一用字符串格式传参：WHERE PRESC_DATE >= '20240101' AND PRESC_DATE < '20240201'。如果查出来是 datetime，再用带时间的参数。这个“先查类型再写条件”的习惯，能避开至少一半的取数翻车现场。
4.2 坑二：金额单位“分”与“元”混用，数据差 100 倍
现象：统计住院收入，查询结果比财务报表少 100 倍，或者恰好相反。原因：费用明细表里一部分字段以元存储，比如单价 PRICE；另一部分以分存储，比如金额 COSTS，而手册在描述两者时都写 numeric(12,2)，没有单独标注单位。这个不是 bug，是历史包袱——收费程序界面显示元，内部计算用分。解决：先做单条抽样对账，确认每个金额字段的单位。
-- 抽样一条费用记录，观察单价格式判断金额单位 SELECT TOP 5 PRICE, COSTS, QUANTITY, ITEM_NAME FROM INP_BILL_DETAIL WHERE BILL_DATE = '2024-03-01' AND COSTS != 0;看结果里 COSTS 是小数值还是整百数值，结合 QUANTITY 和 PRICE 相乘的结果，能快速推算单位。确认后，在所有汇总脚本里统一加注释并处理换算，不要在业务 SQL 里临时除，而是建一张字段单位配置表，让脚本从这个配置表读取换算方式。我建过一张 VIEW，把所有需要换算的金额字段统一转换输出，这样报表层永远只面对“元”。
4.3 坑三：退费不是负数，而是状态标记加负数记录
现象：统计门诊收费月报，按金额求和后比实际收入高出一截。原因：对退费记录的处理方式理解错了。这套库的退费实现是插入一条原记录的负数金额副本，同时把原记录的退费标记置为“已退”，两条记录的 BILL_DATE 都在同一个统计区间内。SUM 直接算，原记录和退费记录同时被计入，收入自然虚高。解决：统计时先过滤状态标记，如果没有标记字段，就要通过负数金额反向圈定退费记录。
-- 汇总时排除退费记录：状态为正常收费，且金额大于 0 SELECT SUM(CASE WHEN VOID_FLAG = '0' AND COSTS > 0 THEN COSTS ELSE 0 END) AS valid_income FROM INP_BILL_DETAIL WHERE BILL_DATE >= '2024-01-01';这里有个更隐蔽的情况：部分现场不用负数，而是退费时生成一条金额为正但 VOID_FLAG 标记为 1 的记录，同时对原记录打退费标。所以只过滤负数会漏。最稳妥的办法是把状态字段的所有取值先拉出来，确认这个现场用哪种模式，再写汇总。手上如果同时维护多个医院的数据仓库，这个坑几乎每个院的处理都不一样，不要在代码层面写死。
4.4 坑四：医嘱状态机的未知状态码，黑匣子里的“1”和“2”
现象：接口只抽取“已审核”医嘱，但同步到下游系统的医嘱数量对比 HIS 前台界面少了一部分。原因：状态码映射表中没有涵盖某个新状态值，实际库里出现手册未登记的代码。比如手册写了 1 是已审核、2 是已执行，但个别特殊项目类型的新医嘱，状态取值为 5，含义是“已审核待执行”，你没过滤到它，配置类的长期医嘱就被整体漏掉了。解决：写状态过滤条件前，先全量跑一次状态分布。
-- 全量统计医嘱状态分布，找出手册中未记录的代码值 SELECT ORDER_STATUS, COUNT(*) AS CNT FROM ( SELECT ORDER_STATUS FROM INP_ORDERS UNION ALL SELECT ORDER_STATUS FROM OUTP_ORDERS ) t GROUP BY ORDER_STATUS;拿到分布后，把每个未知代码值找实施确认含义，更新到你自己的代码值映射表里。这个过程很像是给系统建黑匣子解释器。我现在的做法是：接口层不允许以“未知状态直接丢弃”，而是把未知值原样透传并打上“未映射”标记，宁可让下游发现脏数据，也不要在入口把数据静默丢掉。后者的代价是数据莫名消失，排查成本远高于曝光。
4.5 坑五：分区表跨区查询翻车，索引失效的经典现场
现象：分页抽取医保上传数据，页码越大越容易重复或漏数，单页数量和数据库游标位置对不上。原因：手册把逻辑表描述成一张普通表，实际物理存储是按月份做的分区视图或分区表，有独立分区编号。按主键排序分页时，如果没有把时间分区字段作为排序键的一部分，数据库执行计划在跨分区情况下可能产生不稳定的排序结果，尤其当主键不是严格递增的时候。解决：把分页游标改成基于业务日期和唯一业务键的双字段游标。
-- 用业务日期和唯一键组合游标，避免跨分区翻车 SELECT TOP 100 SETTLEMENT_ID, BILL_DATE FROM INP_BILL_DETAIL WHERE BILL_DATE > '2024-01-01' OR (BILL_DATE = '2024-01-01' AND SETTLEMENT_ID > '20231200001') ORDER BY BILL_DATE, SETTLEMENT_ID;这段 SQL 的技巧是用“大于上一页最大值”代替 OFFSET，让数据库永远只沿一个方向扫描。参数上注意 SETTLEMENT_ID 是 varchar 类型，比较时需要保证两边格式一致，最好在代码里统一左填充补齐位数。实际操作中，这个方案也在数据量达到几千万行时仍然保持稳定。吃过大亏之后，我养成了习惯：凡是要全量抽取的大表，第一件事先确认是否分区，第二件事观察主键生成方式，然后才设计抽取策略。
5. 把手册当代码库维护：用一张自建字典表跟踪天健HIS的数据结构变更
5.1 自建 EXT_SCHEMA_DICT 表，把文档里能用的部分固化成 SQL
手册是静态的，库是动态的，靠人肉记忆两者差异早晚会漏。我接手第二个天健库之后，就建了一张自有的字典表，把手册里确认过、验证过的字段含义固化成结构化数据，后续所有取数脚本都基于这张表生成，而不直接依赖 Word 文档。
-- 自建数据结构字典表，固化手册中的有效字段说明 CREATE TABLE EXT_SCHEMA_DICT ( ID INT IDENTITY PRIMARY KEY, TABLE_NAME VARCHAR(80) NOT NULL, COLUMN_NAME VARCHAR(80) NOT NULL, COLUMN_CN_NAME NVARCHAR(200) NULL, DATA_TYPE VARCHAR(40) NULL, UNIT_FLAG VARCHAR(10) NULL, -- 单位标记：YUAN / FEN STATUS_MEANING NVARCHAR(400) NULL, -- 状态码含义描述 SOURCE_DOC_VER VARCHAR(20) NULL, -- 来源手册版本 ACTIVE_FLG CHAR(1) DEFAULT '1', -- 是否仍启用 CREATE_DATE DATETIME DEFAULT GETDATE() );这张表的作用不只是存手册内容，更重要的是记录“历史变更”。每次发现一个手册没写的扩展字段，我就往里面插一条；每次确认一个状态码，就更新 STATUS_MEANING。时间一长，这张表变成了一本“活字典”，新人接手项目时，看它比翻原始 doc 快得多，因为它只记录验证过的东西，不含废话。关键参数 ACTIVE_FLG 用来标记已废弃字段，比如某张表升级后字段改名，旧字段就置 0，不物理删除，保留历史查询的原始语义。
5.2 每周跑一次结构对比，让变更不再靠群里通知
数据结构变更最大的风险是“悄悄发生”。曾有一次门诊系统升级，把费用表的一个状态字段取值范围改了，直到医保接口对账失败才发现，中间整整三天导出的数据全是错的。后来我用系统视图和自建字典表做了一个简单的差异检测脚本，每周一自动跑一遍，有变化就给组里发提醒。核心逻辑是把当前库的实际结构和字典表做 LEFT JOIN，找出字典表里不存在的字段，以及实际库已经删掉但字典表还在的记录：
-- 对比实际库与自建字典表，找出当前存在但字典未记录的字段 SELECT t.name AS table_name, c.name AS column_name, TYPE_NAME(c.system_type_id) AS actual_type FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN EXT_SCHEMA_DICT d ON d.TABLE_NAME = t.name AND d.COLUMN_NAME = c.name WHERE d.ID IS NULL AND t.type = 'U' ORDER BY t.name, c.name;这段 SQL 输出的是“字典里没有的新字段”。我每周一次把结果清一遍，有业务含义的补进字典表，没业务含义的临时字段直接忽略。这个习惯帮我提前发现过好几次表结构调整，包括新加的预约来源字段、新拆出的退费明细表。做久了你会发现，数据字典这东西本质上不是一份静态文档，而是一套需要持续维护的元数据系统。手册是起点，不是终点。它给了你第一版地图，但地图要跟着地形走，地形变了，地图就得改。我现在每接一个新项目，第一件事就是跑这套对比脚本，把手册和实际库的差异摊在明面上，再逐项确认。这样至少不会再犯“拿三年前的文档指导今天的取数工作”这种低级的错。希望这套方法也能让你少走几趟弯路，特别是当你面对的也是一台上线多年、经历过无数二次开发的 HIS 系统时，一份属于自己的活字典，比任何官方文档都管用。
本文还有配套的精品资源，点击获取
