简介：天健医院信息系统数据结构手册面向HIS系统开发、实施与运维工程师，尤其是初次接触天健医疗数据库的技术人员，用于快速掌握表结构与字段含义，降低数据查询与分析的门槛。资源包共1个文件，为doc格式文档，压缩包约7.19MB，内容按公共部分、人员属性、国家地区单位及其属性、科室字典等模块组织，逐表说明字段定义与用途。文档中收录了性别、婚姻状况、民族、血型、职业分类、身份、费别、病人来源等字典表，以及工作人员字典、用户记录、技术职务、工作类别、社会关系、医生职务等人员属性表，并涵盖国家及地区字典、行政区字典、医院基本情况、合同单位记录、科室字典、临床科室配置、科室与病房对照等结构说明。借助这份手册，读者可对照表名与字段快速定位数据来源，理解字典表标准化设计思路，为接口开发、报表取数与数据核对提供参考。目前已有849人学习下载，适合需要系统梳理天健HIS数据结构的中高级工程师查阅。
1. 天健医院信息系统数据结构手册：一份被低估的对接地图
接手医院第三方系统对接的工程师，大概率都经历过这种场面：接口文档写得含糊，字段名靠猜，跑出来的数据对不上护士站的记录，最后被一句“以天健系统为准”堵回来。天健医院信息系统数据结构手册.doc 这类文档，本质上是 HIS 厂商留给实施和二次开发人员的一张底层地图，它描述的是数据库表结构、字段含义、字典编码和表间关系。很多人拿到手第一反应是“这不就是个数据字典吗”，然后束之高阁，等到真正要写视图、做报表、对接 LIS/PACS 时才后悔没早点翻。它解决的核心问题只有一个：让你知道数据存在哪张表、哪个字段、用什么编码，而不是靠试错去猜。适合谁看？做医院数据集成、报表开发、接口对接、数据迁移的工程师，以及需要从 HIS 里取数做运营分析的技术人员。数据结构这四个字听起来像教科书内容，但在医院场景里，它直接决定你的 SQL 能不能跑对。
2. 先搞清楚手册里到底有什么：表、字段、字典三层结构
2.1 天健 HIS 的数据分层逻辑
天健医院信息系统的数据库设计，遵循典型的医疗信息化分层思路：基础字典层、业务主表层、明细流水层。基础字典层放的是科室、人员、收费项目、药品、诊断编码这些相对稳定的数据，比如科室字典表通常以DEPT或GY_DEPT开头，人员字典常见STAFF或GY_USER。业务主表层是挂号、就诊、医嘱、处方、收费这些核心业务记录，一张主表对应一次业务事件。明细流水层则是主表下面的子表，比如一条处方对应多条处方明细，一条收费单对应多条收费明细。
手册里最容易被忽略的是字典编码表。医院里几乎所有业务字段都不是直接存中文，而是存编码，比如性别存1和2，费别存01、02，科室存内部科室码而不是科室名称。如果你不知道编码含义，查出来的数据就是一堆数字。手册的字典章节会列出每个编码集的范围和含义，这是取数前必须过一遍的内容。
常见做法是先把手册里的表按业务域分类：患者域、就诊域、医嘱域、收费域、药品域、检验检查域。每个域找出主表和关键关联字段，画一张自己的 ER 草图。不要指望手册里有一张完整的 ER 图，大多数厂商手册只给单表说明，关系要自己推。
2.2 怎么从手册里定位一张业务表
拿到手册后，不要从头读到尾。正确姿势是按业务问题反查。比如你要查“某患者某次住院的所有收费明细”，拆解路径是：患者 → 住院就诊记录 → 收费主表 → 收费明细表。手册里通常会有表名注释，天健的表名习惯用拼音首字母缩写，比如ZY_BRXX可能是住院病人信息，MZ_GH可能是门诊挂号。但不同版本命名不完全一致，所以要以手册实际列出的表名为准。
定位步骤可以固定下来：
- 在手册目录里找业务域章节，比如“住院管理”“门诊收费”。
- 找到该域的主表，看字段里有没有患者标识、就诊标识、时间字段。
- 顺着主表的主键字段名，去其他表里找同名字段，通常就是外键关联。
- 确认字典字段，去字典章节查编码含义。
提示：手册里的字段类型和长度也要看，尤其是金额字段，有的用
NUMBER(12,2)，有的用NUMBER(10,4)，精度不同会导致对账差几分钱。
2.3 字段命名规律与常见前缀
天健系统的字段命名有一定规律，掌握之后查表速度会快很多。常见前缀：
| 前缀 | 含义 | 示例 |
|---|---|---|
BR | 病人 | BRID病人标识 |
GH | 挂号 | GHID挂号流水号 |
ZY | 住院 | ZYH住院号 |
MZ | 门诊 | MZH门诊号 |
YS | 医生 | YSDM医生代码 |
KS | 科室 | KSDM科室代码 |
SF | 收费 | SFID收费流水号 |
YP | 药品 | YPDM药品代码 |
这些前缀不是绝对的，但覆盖大部分场景。手册里每个字段都有中文注释，遇到不认识的字段名，先看注释，再看它出现在哪些表里，基本能判断用途。如果手册注释写得模糊，比如只写“标志”，那就需要结合业务数据去验证，取几条实际数据看值分布。
2.4 用 SQL 验证手册描述是否准确
手册是文档，数据库是活的，两者可能不一致。上手第一件事是拿几条验证 SQL 去核对。以患者主表为例：
-- 查询患者主表结构，确认字段是否存在 SELECT column_name, data_type, data_length, nullable FROM all_tab_columns WHERE table_name = 'ZY_BRXX' ORDER BY column_id; -- 取前 10 条数据，观察关键字段实际值 SELECT BRID, BRXM, XB, CSRQ, KSDM FROM ZY_BRXX WHERE ROWNUM <= 10;第一段 SQL 查的是表结构，确认手册里写的字段在数据库里真实存在，类型是否一致。第二段 SQL 取样本数据，重点看字典字段的实际值，比如XB性别字段，如果手册写1=男 2=女，但实际数据里出现了0或9，说明手册没写全或者有历史脏数据。这一步能帮你提前发现手册和实际库的偏差，避免写出来的 SQL 跑出错误结果。
参数说明：all_tab_columns是 Oracle 的系统视图，天健 HIS 大多跑在 Oracle 上，如果是 SQL Server 则换INFORMATION_SCHEMA.COLUMNS。ROWNUM是 Oracle 限制返回行数的写法，SQL Server 用TOP 10。取样本时不要用SELECT *，只取你关心的字段，减少干扰。
3. 从手册到可跑 SQL：核心业务表的关联查询
3.1 患者-就诊-收费三表关联的最小闭环
医院数据取数最常用的链路是：患者信息 → 就诊记录 → 费用明细。以住院场景为例，假设手册里查到三张表：ZY_BRXX（住院病人信息）、ZY_JZJL（住院就诊记录）、ZY_SFMX（住院收费明细）。关联字段通常是BRID（病人标识）和ZYH（住院号）。
-- 住院患者费用明细查询：患者+就诊+费用三表关联 SELECT b.BRID AS 病人标识, b.BRXM AS 病人姓名, b.XB AS 性别, j.ZYH AS 住院号, j.RYRQ AS 入院日期, j.CYRQ AS 出院日期, s.SFXM AS 收费项目, s.SL AS 数量, s.DJ AS 单价, s.JE AS 金额, s.SFRQ AS 收费日期 FROM ZY_BRXX b JOIN ZY_JZJL j ON b.BRID = j.BRID JOIN ZY_SFMX s ON j.ZYH = s.ZYH WHERE j.RYRQ >= TO_DATE('2024-01-01', 'YYYY-MM-DD') AND j.RYRQ < TO_DATE('2024-02-01', 'YYYY-MM-DD') ORDER BY j.ZYH, s.SFRQ;这段 SQL 的逻辑是：以病人主表为起点，通过BRID关联到就诊记录，再通过ZYH关联到费用明细。WHERE条件限制入院日期在一个月内，避免全表扫描。ORDER BY按住院号和收费日期排序，方便核对。
参数说明：TO_DATE是 Oracle 的日期转换函数，格式字符串'YYYY-MM-DD'必须和输入匹配。如果手册里入院日期字段是VARCHAR2类型存字符串，那就不能用TO_DATE比较，需要先确认存储格式。关联字段的类型也必须一致，如果BRID在病人表里是NUMBER，在就诊表里是VARCHAR2，直接 JOIN 会隐式转换，可能导致索引失效，查询变慢。
3.2 医嘱表与药品字典的关联
医嘱数据是医院数据里结构最复杂的部分之一。一条长期医嘱可能对应多条执行记录，药品医嘱还要关联药品字典才能拿到药品名称和规格。手册里通常会有YZ_KZ（医嘱主表）、YZ_MX（医嘱明细）、YP_ZD（药品字典）这几张表。
-- 查询某住院号下的药品医嘱明细 SELECT y.YZID AS 医嘱ID, y.ZYH AS 住院号, y.KSDM AS 开单科室, y.YSDM AS 开单医生, m.YZMC AS 医嘱名称, m.YPLX AS 药品类型, p.YPMC AS 药品名称, p.YPGG AS 药品规格, p.YPDW AS 药品单位, m.YL AS 用量, m.YLDW AS 用量单位, m.YZTS AS 医嘱天数 FROM YZ_KZ y JOIN YZ_MX m ON y.YZID = m.YZID LEFT JOIN YP_ZD p ON m.YPDM = p.YPDM WHERE y.ZYH = '2024001234' AND m.YZLX = '1' -- 1 代表药品医嘱 ORDER BY y.KDRQ, y.YZID;这里用LEFT JOIN关联药品字典，是因为有些医嘱可能关联不到药品字典（比如手工录入的临时医嘱），用LEFT JOIN可以保留这些记录，避免漏数据。YZLX = '1'是过滤条件，只取药品类医嘱，具体编码值要以手册字典章节为准。
参数说明：YZID是医嘱的唯一标识，通常由系统生成。YPDM是药品代码，关联药品字典的主键。YZTS是医嘱天数，长期医嘱和临时医嘱的取值逻辑不同，长期医嘱可能存的是计划天数，临时医嘱存的是1或0。这些细节手册里不一定写全，需要结合业务数据验证。
3.3 字典编码的转换与映射
前面提到，医院数据大量使用编码存储。写 SQL 时如果直接输出编码，业务人员看不懂。常见做法是关联字典表做转换，或者在应用层做映射。手册里的字典章节会列出编码集，但字典表本身可能不在手册里，需要从数据库里找。
-- 关联科室字典，把科室代码转成科室名称 SELECT s.ZYH, s.SFXM, s.JE, d.KSMC AS 科室名称 FROM ZY_SFMX s LEFT JOIN GY_KSZD d ON s.KSDM = d.KSDM WHERE s.SFRQ >= TO_DATE('2024-01-01', 'YYYY-MM-DD');GY_KSZD是科室字典表，KSDM是科室代码，KSMC是科室名称。用LEFT JOIN是因为可能存在已停用科室，字典表里没有对应记录，但历史数据里还有。如果直接INNER JOIN，这些记录会被过滤掉，导致金额对不上。
注意：字典表在不同天健版本里命名可能不同，有的叫
GY_KSZD，有的叫DICT_DEPT，以手册实际列出的表名为准。如果手册里没有字典表，去数据库里搜表名包含DICT或ZD的表。
3.4 时间字段的处理与性能注意
医院数据量大，时间字段处理不当会直接拖垮查询。手册里时间字段通常有RYRQ（入院日期）、CYRQ（出院日期）、SFRQ（收费日期）、KDRQ（开单日期）等。写查询时尽量用时间字段做过滤条件，并且保证字段上有索引。
-- 按收费日期范围查询，避免全表扫描 SELECT COUNT(*) AS 收费笔数, SUM(JE) AS 总金额 FROM ZY_SFMX WHERE SFRQ >= TO_DATE('2024-01-01', 'YYYY-MM-DD') AND SFRQ < TO_DATE('2024-02-01', 'YYYY-MM-DD');如果SFRQ字段是DATE类型且有索引，这个查询会走索引范围扫描。如果字段是VARCHAR2存字符串，比如'20240101120000'，那就需要按字符串比较，但要注意格式统一。更麻烦的是，有些老系统时间字段存的是NUMBER类型，比如20240101，这种就需要转换。
性能上还有一个坑：不要在WHERE条件里对时间字段做函数运算，比如TO_CHAR(SFRQ, 'YYYY-MM') = '2024-01'，这会导致索引失效。正确写法是用范围比较，让字段裸奔。
4. 对接与取数时最容易翻车的几个地方
4.1 手册版本和实际数据库不一致
现象：按手册写的字段名去查，报ORA-00904: invalid identifier，字段不存在。原因：手册是旧版本，数据库已经升级过，字段被重命名或删除了。解决：先用all_tab_columns查实际表结构，以数据库为准，手册只做业务含义参考。如果字段确实没了，去问实施人员要最新版手册，或者从数据库注释里找线索。
4.2 字典编码有历史遗留值
现象：性别字段手册写1=男 2=女，但数据里出现了0、3、9。原因：老数据迁移时没有清洗，或者不同子系统写入的编码规则不一致。解决：先GROUP BY看值分布，把实际出现的值都列出来，再找业务人员确认含义。不要直接按手册写CASE WHEN XB='1' THEN '男' ELSE '女' END，会把异常值都归成女。
4.3 关联字段类型不一致导致查询慢
现象：三表关联查询跑了几分钟不出结果。原因：关联字段类型不一致，比如BRID在 A 表是NUMBER，在 B 表是VARCHAR2，Oracle 做隐式转换，索引失效。解决：用all_tab_columns确认两边字段类型，如果不一致，在 SQL 里显式转换，比如TO_CHAR(a.BRID) = b.BRID，但这样仍然可能不走索引。更好的做法是找 DBA 确认是否有函数索引，或者在 ETL 层做类型统一。
4.4 金额字段精度不一致
现象：收费明细汇总金额和收费主表金额差几分钱。原因：明细表金额字段是NUMBER(12,4)，主表是NUMBER(12,2)，汇总时四舍五入方式不同。解决：统一用明细表汇总，或者在汇总时用ROUND(SUM(JE), 2)明确精度。对账时以明细为准，主表金额只做参考。
4.5 医嘱表和收费表关联不上
现象：按ZYH关联医嘱和收费，发现有些收费记录找不到对应医嘱。原因：收费记录可能来自手工补录、退费重收、或者医嘱被作废但收费未撤销。解决：不要用INNER JOIN，改用LEFT JOIN保留收费记录，再通过YZID或时间范围去匹配。如果业务上要求必须一一对应，那就需要和业务方确认哪些场景允许不一致。
5. 把手册用活：从取数到数据校验的进阶习惯
手册的价值不只是查字段，而是帮你建立一套可复用的取数模板。我一般会做三件事：第一，把常用业务域的关联 SQL 存成视图或 CTE，下次直接引用，不用每次重写 JOIN。第二，建一张自己的字典映射表，把手册里的编码和实际数据里出现的值都维护进去，遇到新值就补充，避免每次都要问人。第三，写一个简单的数据校验脚本，定期跑一遍关键指标，比如每日收费总额和财务系统对账，发现偏差就回头查手册确认字段逻辑。
-- 每日收费汇总校验：按收费日期统计笔数和金额 SELECT TRUNC(SFRQ) AS 收费日期, COUNT(*) AS 收费笔数, SUM(JE) AS 收费金额 FROM ZY_SFMX WHERE SFRQ >= TRUNC(SYSDATE) - 7 GROUP BY TRUNC(SFRQ) ORDER BY 收费日期;这个查询用TRUNC(SFRQ)把时间截断到天，按天汇总。SYSDATE - 7取最近七天。跑出来的结果和财务日报对比，如果金额一致，说明取数逻辑没问题；如果不一致，优先检查字典关联是否漏了科室、费别过滤条件是否和财务口径一致。
还有一个习惯：每次从手册里查到一个新表，就在自己的笔记里记下表名、业务含义、关键字段、关联关系。时间长了，你就有一份比原版手册更好用的个人版数据地图。手册是死的，业务是活的，真正值钱的是你对手册和实际数据之间差异的理解。希望帮到你。
本文还有配套的精品资源，点击获取
