企业官网建设流程全解析

简介：《天健医院信息系统数据结构手册》是一份面向HIS系统实施、运维及二次开发工程师的数据库设计说明文档。资源围绕天健医疗HIS的底层表结构展开，系统梳理了公共字典、人员属性、科室字典、医疗工作、疾病诊断与手术操作等模块，涵盖性别、血型、费别、科室配置、医嘱类别、床位类型等核心字典及业务表字段定义，能帮助不熟悉数据结构的读者快速定位字段含义与表间关系，提升数据查询和排错效率。这份手册还以颜色标识字段使用状态（红字未使用、蓝字新增在用、黑字在用），便于开发维护时判断字段可用性。资源包为单个doc文件，大小7.19MB，内容为完整版数据结构手册，含版本更新记录与完整目录索引。已有852人学习下载，适合HIS数据库管理员、医疗信息化开发人员以及需要对接天健系统的工程师参考使用。

1. 一本快二十年的 HIS 数据字典，为什么现在还值得翻

接手旧 HIS 系统或者做数据对接时，最麻烦的从来不是 SQL 写不出来，而是不知道业务数据落在哪张表里。这份标题为《天健医院信息系统数据结构手册》的资源，是某厂商 HIS 系统的数据库表结构说明文档，覆盖从人员字典、科室配置、门诊住院业务、医嘱处方、药品库存到收费结算的完整表清单，版本迭代到第 15 稿，时间跨度从 1996 年一直到 2006 年。对要做二次开发报表、老系统迁移、接口联调的人来说，它相当于一份带注释的地图，先读它再动手，能少走很多弯路。适合读它的人包括：刚接手旧 HIS 维护的工程师、做数据对接的开发，以及需要摸清业务表关系的实施人员。注意它是老式 .doc 格式，内容以表格清单为主，没有建表 SQL 脚本。

2. 先读框架再看表：这份数据字典的四层组织逻辑

拿到这份手册，直接翻到某个章节去看字段是低效的。它有一套自己的组织方式，搞清楚这个框架，后面查表才会顺。整本手册按业务域分成若干部分，我在下面拆成三层来解释，这样能更快建立全局观。

2.1 颜色标记与版本约定：先学会读“说明”

手册开头有一页用颜色区分表状态的说明，这是读整份文档的钥匙。红字标识的表及字段，代表未使用状态；蓝字标识的表及字段，代表新增且在用状态；黑字标识的表及字段，代表在用状态。也就是说，你拿到第 15 稿后看到一张表，先看它的文字颜色，就能判断这张表现在到底能不能用。

这个约定在维护阶段非常实用。某个模块升级时，数据结构的负责人会把废弃表标红，把新表标蓝，而不是直接把旧表删掉。因为删除表会影响历史数据和旧程序的运行，保留并醒目标注是更稳妥的做法。所以解读时要养成习惯：把红字表视为“历史遗留，不要写入”；把蓝字表视为“新功能，正在用，写代码时要优先参考”；黑字属于“稳定在用”。我一般会把这三个状态整理成一张状态速查表贴在本机，跟踪哪几张表是新增的、哪些已经废弃。

另外，版本更新记录页也很值得看。它记录了从 1996 年到 2006 年共 15 稿的修改者、修改日期和改动范围。比如第 12 稿修改了药品、门诊病人管理结构，新增了医生站、设备、输血管理结构；第 13 稿修改了医嘱、病案流通、药品结构；第 14 稿和第 15 稿做了全新整理。看这个记录能快速了解系统的演进脉络，知道哪些功能是后期强化的，比如合理用药相关表在第 15 稿里被明确标为不使用，说明这个方向的尝试做过但没落地。

2.2 命名规律：字典表、对照表、主明细表

整本手册的表名有非常强的规律，几乎可以总结出一套命名习惯。第一类是以_DICT结尾的字典表，比如性别字典 SEX_DICT、民族字典 NATION_DICT、科室字典 DEPT_DICT。这类表的特点是数据量小、变化不频繁，一般只有编码和名称两个核心字段，外加排序、输入码之类的辅助字段，作用是把业务表里的代码翻译成可读文字。

第二类是带_VS_的对照表，比如 CHARGE_TYPE_VS_IDENTITY（费别与身份对照）、DEPT_VS_WARD（临床科室与病房区对照）。这类表专门描述两个字典之间的多对多关系。比如一个身份类型可以对应多种费别，一个科室可以对应多个病房区，映射关系全部靠这类表维护。业务查询里频繁出现的关联，追到底层基本都会落到一两张_VS_表上。

第三类是主明细结构，命名上通常是 XXXX_MASTER 配 XXXX_DETAIL（或 ITEMS）。比如药品入库主记录 DRUG_IMPORT_MASTER 配药品入库明细记录 DRUG_IMPORT_DETAIL，检查主记录 EXAM_MASTER 配检查项目记录 EXAM_ITEMS。主表存一次业务行为的总信息，比如入库单号、日期、供货商；明细表存这次行为涉及的具体项目，比如药品编码、数量、批号。写统计 SQL 时最常犯的错误就是把主表和明细表混着查，导致金额或数量成倍放大，正确做法是先明确查询粒度落在主表还是明细表。

2.3 从第 12 稿到第 15 稿：模块演进的痕迹

对比不同版本能看出系统功能的扩张路径。第 11 稿之前的重点是基础框架，包括人员属性、科室、疾病诊断、价表这些支撑模块。第 12 稿引入药品管理的完整链路和门诊病人管理结构调整，同时新增医生站相关结构，说明系统从单纯的收费管理向临床业务延伸。第 13 稿大改医嘱和病案流通结构，这时候医嘱已经不是简单的“开一条记一条”，而是有了成组医嘱模板、医嘱执行频率、医嘱状态字典这些配套概念。到第 14、15 稿出现医疗卡、分诊台、会诊等细节设计，数据结构的复杂度已经接近完整的临床信息系统。

理解这个演进过程，对维护工作的实际帮助是：如果你面对的库里有大量表，但只在用其中一部分，那很正常。因为系统是十几年里一层层叠加出来的，旧表不删除、新表持续增加，最终呈现出来的就是这份手册的模样。所以读的时候不要指望每张表都理解透彻，认准在用状态的核心表就够了。

3. 核心业务表拆读：按门诊、住院、药品、费用四条主线

整本手册的表接近三百张，真正高频使用的是一批围绕病人、医嘱、药品、费用的核心表。下面按业务主线拆几组典型表，讲清楚它们的职责和互相之间的引用关系。

3.1 病人主索引与住院记录：PAT_MASTER_INDEX 的龙头作用

病人主索引 PAT_MASTER_INDEX（病案部分第 9.1 节）是整个系统最核心的一张表，可以理解为所有病人就诊记录的根。一个病人在门诊挂过号、住过院、做过检查，这些行为的共同引用点就是 PAT_MASTER_INDEX 里的病人唯一标识。手册里专门有“病人标识号引用表 PATIENT_ID_REF”，说明系统内部各子系统的记录都以这个标识为关联。合并病人主索引时还有 PMI_MERGED_LOG（主索引合并记录）做日志跟踪，这是我在其他 HIS 系统里不常看到的细节，说明它对数据一致性很重视。

住院相关的主记录是 PAT_VISIT（病人住院主记录），每次住院生成一条，记录入院科室、住院次数、费别这类信息。和它配套的是 TRANSFER（病人在科记录），记录病人在住院期间从哪个科转到哪个科。很多实施人员第一次查“某病人在哪个科室”时直接去 PAT_VISIT 的当前科室字段，这通常是错的，因为住院期间转科会产生多条 TRANSFER 记录。正确的思路是：在这张表之外取最近一次的转科记录，把时间顺序排一下，而不是只看主记录上的单一字段。

住院流程里还有几张辅助表值得关注：床位记录 BED_REC、在院病人记录 PATS_IN_HOSPITAL、准备出院病人记录 PRE_DISCHGED_PATS、等床病人记录 WAIT_BED_PATS，以及记录入出转状态变化的 ADT_LOG。这些表共同描述住院病人的流转路径。观察它们的命名可以培养一个习惯：看到以 PATS_ 开头或含 PAT 的表，通常会关联到某个具体病人的当前状态，查实时数据时优先走这些表，而不是去历史表里筛选。

3.2 医嘱三层结构：ORDERS、ORDERS_COSTS、ORDERS_EXECUTE

医嘱部分共有三张关键表：医嘱 ORDERS、医嘱计价项目 ORDERS_COSTS、医嘱执行表 ORDERS_EXECUTE，外加配套的成组医嘱模板表。这种设计把一条完整医嘱拆成三个视角：医生开的是什么、它产生哪些费用、它有没有被执行。

医嘱主表 ORDERS 存放的内容包含开立医生、医嘱内容、医嘱状态、频率、剂量单位这些描述性信息。医嘱状态字典 ORDER_STATUS_DICT 和医嘱执行频率字典 PERFORM_FREQ_DICT 的存在说明状态与频率是被单独管理的，而不是简单塞在文本字段里。如果你要统计某段时间内长期医嘱的开立数量，用 ORDERS 表按状态和开立时间过滤即可，不要关联费用表，否则一条医嘱带出十几条费用记录，数量就会被放大。

医嘱计价表 ORDERS_COSTS 解决的是“拒账”和“记账”问题。一条医嘱可能对应多个计价项目，比如“静脉输液”这个医嘱，除了液体本身，还涉及输液器、注射费，这些项目在 ORDERS_COSTS 里逐条体现。它有一个关键设计点：医嘱作废后，对应的费用记录也要作废或回滚。实施过程中最常遇到的坏账问题，往往是作废医嘱时没有同步处理费用子表，导致病人账单里多出一笔已经取消的费用。第 13 稿专门修改医嘱和药品结构，说明这套关联在当时也是维护重点。

医嘱执行表 ORDERS_EXECUTE 记录的是护士实际执行的情况，比如哪天哪次执行、执行人是谁。长期医嘱按频次展开后，每天会产生多条执行记录。这个表和费用表之间的关联经常被搞混。记住一句话：费用不一定等于执行，执行也不一定产生费用，中间任何一步都可能被手工干预。

3.3 药品库存与出入库：从 DRUG_STOCK 到 DRUG_IMPORT_DETAIL

药品管理的表结构从第 12 稿开始成型，到第 15 稿加了采购计划、调价记录、总账这些内容，已经形成一套完整的进销存链路。链条的起点是药品字典 DRUG_DICT，包含名称、剂型、毒理分类、处方属性等信息；往上是药品价格 DRUG_PRICE_LIST 和公费用药目录；中间是库存定义 DRUG_STORAGE_PROFILE 和实际库存 DRUG_STOCK；两端是入库和出库。

药品库存表 DRUG_STOCK 记录的是某个库房某药品的当前结存。它和入库明细、出库明细之间是存量与流量的关系，这点不难理解。真正的坑在于住院药房的摆药。手册里有发药申请、发放通知、待发药处方主记录、待发药处方明细记录、摆药请求、摆药记录这一串表，对应的实际流程是：医生下医嘱后形成处方请求，药房根据请求进行摆药或发药，最后才扣减库存。如果你把医嘱开立时间当作药品消耗时间，对账就会对不上，必须等到摆药记录生成后库存才变化。

药品调价记录 DRUG_PRICE_MODIFY 和调价盈亏表 DRUG_PRICE_MODIFY_PROFIT 是第 15 稿新增的内容，处理的是调价前后库存差额的核算。在老的 HIS 维护里，药品调价是最容易出错的环节，因为调价不只改一个价格字段，还要同步处理调价当天的库存差额。有这两张表，说明系统在价格管理上做过专项设计。查询历史用药成本时，不要直接用当前价表里的价格倒推，应该关联当时的调价记录。

3.4 计价与费用：PRICE_LIST、CURRENT_PRICE_LIST 与收据记录

费用相关的核心是价表 PRICE_LIST 和当前价表 CURRENT_PRICE_LIST。这两张表的区别光看名字容易混淆，理解它们的定位要看业务场景。价表维护的是项目在时间段内的定价，一条记录有生效时间和失效时间；当前价表存的是当前正在执行的价格。可以这样理解：一个收费项目在不同时间点有不同的价格，历史价格保留在 PRICE_LIST 里，当前生效的那个版本被冗余到 CURRENT_PRICE_LIST，供日常划价时快速读取。

做统计报表时，查历史费用应该按收费发生时间取价表里对应时段的价格，不能直接拿当前价表去乘数量。另一个容易踩的坑是价表项目分类。手册专门定义了 BILL_ITEM_CLASS_DICT（价表项目分类字典）、MR_FEE_CLASS_DICT（病案首页费用分类）、OUTP_RCPT_FEE_DICT（门诊收据费用分类）、INP_RCPT_FEE_DICT（住院收据费用分类），意思是同一个收费项目，在价表里属于一个分类，在国家要求的病案首页里属于另一个分类，在发票上又按另一种方式归组。写上报接口的时候，如果直接从价表分类推病案首页分类，结果一般都对不上，必须通过 ITEM_CLASS_VS_OTHER_CLASS 这张对照表来映射。

门诊收费的核心记录是 OUTP_RCPT_MASTER（门诊医疗收据主记录），下面挂支付方式记录 OUTP_PAYMENTS_MON。这张表上的支付方式、收据号、作废标记都是审计重点。作废发票会有专门的日志表做追溯，比如发票重打日志 REGIST_REPRINT_LOG。维护这类收费模块时，除非能确认流程，否则不要直接修改收据主表，先看有没有配套的操作日志。

4. 避坑清单：解读与使用这套字典时最常翻车的五个点

看了不少人在老 HIS 数据上栽跟头，总结出五个高频问题，每一条都是实际发生过的。对照这份手册，可以提前绕开。

4.1 看到“不使用”标记就以为表没用了

现象：手册里有一张用户记录 USERS 表，明确标注“不使用”。有开发人员看到这个标记后，就把认证模块的查询全部绕开它，结果登录功能报错。原因：USERS 表废弃后，系统并没有删除权限体系，而是换成了 SECURITY_USERS、SECURITY_GROUPS 这套安全表。解决：处理任何表之前，先看手册里相关章节有没有配套的 SECURITY 开头表。这种标“不使用”的表通常是旧版残留，新版用另一套结构替代，但它们往往还有数据迁移价值，不是完全没用。

第二处类似的是合理用药相关表 MDC_DRUG_MATCH_RESULT 和 MDC_ROUTE_MATCH_RESULT，均标注不使用，说明系统曾经接入了合理用药审查功能但中途放弃了。对接这类表时要先确认是否为废弃功能，别把数据接出来做成报表，等于白做。手册用颜色和文字标出状态，正是要提醒：看到“不使用”别直接忽略，看到“新增”也别立刻信任，结合实施现场是否启用才是准确判断。

4.2 分不清检查号类字典和检查类别字典

现象：做检查模块开发，想在检查记录里生成检查号，结果取号时用了 EXAM_CLASS_DICT（检查类别字典）来拼前缀，导致号段全乱。原因：EXAM_CLASS_DICT 描述的是检查的大类，比如放射、超声、内镜；LOCAL_ID_CLASS_DICT（检查号类别字典）描述的才是号段规则，即每一种检查类别内部如何生成并编号。解决：生成检查号时先用 LOCAL_ID_CLASS_DICT 拿到当前类别对应的号类规则，再看 MODALITY_VS_LOCAL_ID_CLASS（设备与号类对照）确定这台设备用哪个号类，最后才生成号码。把取号和分类理解成两件事，就避免了这个坑。

4.3 把 CURRENT_PRICE_LIST 当作历史价表来用

现象：统计去年某个检查项目收费总额，开发人员直接从 CURRENT_PRICE_LIST 里取单价乘以数量，结果和财务对不上。原因：CURRENT_PRICE_LIST 只存当前生效的价格，历史价格在 PRICE_LIST 里保留。当项目发生过调价，当前价表只有最新值，用最新值核算历史费用自然不准。解决：查历史费用时，用收费时间的日期关联 PRICE_LIST 的生效区间，过滤条件写成“收费日期在生效日期和失效日期之间”，这样取到的是该项目在那一时间点真正的价格。这条规则对所有发生过调价的项目都适用，包括药品、检查费和材料费。

4.4 处方明细只关联药品字典，少了主记录

现象：想统计某药品一个月的处方量，直接 JOIN 药品处方明细表 DRUG_PRESC_DETAIL 到药品字典 DRUG_DICT，结果数量翻倍。原因：一张处方有主记录 DRUG_PRESC_MASTER，一条主记录下有多条明细，如果统计的是处方张数，却按明细行去重，或者反过来统计明细行却漏掉了作废状态的过滤，都会得到错误结果。解决：先明确统计粒度。统计“开药量”用明细表行数、按药品编码汇总，筛选状态为有效；统计“处方数”用车方主记录、按处方号唯一计数。作废的处方要配合 DRUG_PRESC_MASTER 里的状态字段排除，主表与明细表不能混在一起数。

4.5 临时表和队列表被当成正式表查询

现象：开发人员发现有一张门诊医嘱主记录队列 OUTP_ORDERS_T，里面数据不断变化，于是直接在这张表上做统计报表，结果数字不稳定。原因：带_T后缀的表是临时表，用于接收医生站写入的中间数据，提交审核后才转入正式表；带_TEMP后缀的表则是待发药处方主记录、待发药明细这类药房排队用的表。它们的内容是流动的，随时可能被清空或覆盖。解决：正式统计和查询走不带后缀的正式表；_T表只用于追踪中间状态或者做消息队列监控。判断一张表能不能直接查，先看表名后缀，再看手册里标注的使用状态。临时表可以作为联调观察数据流动的工具，但不能作为业务数据的最终来源。

5. 让字典帮你干活：从表结构反推查询与迁移方案

这份手册的价值不只是用来查表名，还可以直接指导实际工作。下面用两个高频场景说明怎么把它用起来。

5.1 报表开发的第一步：先定位字典表再定位业务表

开发一张统计报表，顺序应该是：先明确报表要表达的业务口径，再根据手册目录找到对应业务域，先确定字典表用于翻译，再确定业务表和关联路径。

比如要统计某科室门诊医生的开单量，并区分挂号类型和费别。第一步在手册“门诊医生”部分找到病历记录、医嘱主记录、处方明细这几张表；第二步找到 CLINIC_MASTER（就诊记录）确认就诊主表和科别字段；第三步从人员属性部分找到医生相关的 STAFF_DICT 和 DOCTOR_TITLE_DICT，作为人员维度；第四步用费别字典 CHARGE_TYPE_DICT 翻译医保、自费等标识。关联 SQL 的逻辑大体是：以 CLINIC_MASTER 为起点关联 OUTP_ORDERS，再关联 OUTP_PRESC 拿明细，最后关联 STAFF_DICT 补充医生信息。注意所有费用统计不要直接取价表，结合第 5.3 节讲到的对照关系，从 ORDERS_COSTS 取实际计价项目金额。

5.2 老系统数据迁移时的字段映射思路

从这套 HIS 迁到新系统时，最怕的是照着新系统的字段名去旧库里找对应字段。正确做法是：先按新系统的业务对象分类，再回到手册里找对应表和核心字段。

比如新系统需要一个“病人档案”对象，需要建档时间和来源。回到手册里对应的是“病案”部分，病人主索引 PAT_MASTER_INDEX 提供唯一标识、出生日期、性别代码；就诊记录提供入院方式、入院日期；来源字典提供费别和身份。迁移映射时注意新旧代码差异。以性别为例，旧库里的性别代码值和目标库的代码值可能不一致，这时要借助手册里“性别字典 SEX_DICT”列出代码定义，确认映射关系，而不是直接拷贝。医院机构、科室名称在新旧系统中往往有差异，借手册里的 DEPT_VS_WARD 和 DICT 表对照就能理清。

5.3 接口开发时“不可用表”的处理方式

新人最容易踩的坑是接口文档没写清楚，就按手册里某个表名去联调，结果数据写入后原系统不认。正确方式是：开发接口前先翻对应表，确认它是不是“在手使用状态”。凡是标了“不使用”或红字的表，只要不是历史数据迁移场景，就不要作为新接口的写入目标。

比如开发门诊挂号接口，挂号模式字典 REGIST_MODE_DICT 是新增在用表，挂号支付方式 REGIST_PAY_DICT 也是在用状态，可以直接用。但请求提供病案队列 MR_REQUEST_QUEUE 这类表要谨慎，不同医院的启用情况不一致，先确认目标医院是否启用了病案调用流程，再决定接口是否触发这张表。每个院区的启用情况可能不同，交付前多问一句“这个院区到底用不用”，能省下大量联调时间。

6. 带着版本意识去读表：三个实用小技巧

最后一章分享三个我在实际工作中反复用到的技巧，希望对你有直接帮助。

第一个技巧，拿到手册先看版本和更新记录。这份手册已经到第 15 稿，跨度十年以上。如果手上还有旧稿，可以和 15 稿对比，找到哪些表新增标识、哪些表标了不使用。没有旧稿就直接看颜色约定。不要跳过说明页直接查表，否则很容易把废弃表当成正式表。

第二个技巧，把字典表、对照表、业务表分开维护成一份索引。读手册时见到_DICT、_VS_、_MASTER、_DETAIL、_T这些后缀，分别归入对应列表。哪怕只是把常用表的中文名和主要用途整理在表格里，后续做查询和联调时能节省一半的时间。我习惯按业务域整理一份核心表索引，包括模块、表名、中文名、用途、是否在用、关联主表。

第三个技巧，用关联关系反查索引字段。手册正文没有给出所有索引细节，但通过主外键命名可以推断大部分关联。凡是带_ID或_CODE的字段，通常都会出现在相关从表中。借助这些表名和字段名的命名规律，就可以把主索引从“字典”级别还原成一张拟似的 ER 图。比如有 PAT_MASTER_INDEX 和 PAT_VISIT、TRANSFER，那么它们之间必然通过病人标识号关联，顺着这个思路去看表结构说明里的字段，能迅速建立模型。

第四个技巧，改动表结构之前，先翻看“更新记录”历史。手册多次修改与药品、医嘱相关的结构，说明这些模块经历了多次变更。改这些表时，一定要评估历史数据和现有功能的影响，不能只看当前版本文档。此外，凡是带日志的表，如 ADT_LOG 或 MR_TRACE_LOG，都优先用于跟踪数据变化，修改数据前先做备份。

从那以后，我每次接手任何一套陌生 HIS 系统，都会先找它的数据字典翻一翻，按模块整理出核心表索引，再对着字典核对一遍“在用”状态。这个习惯帮我提前避开了很多设计缺陷和数据口径不清的坑。这份手册也提醒我，老系统的产业化过程中积累的表结构往往更贴近真实业务流程。希望帮到你。

本文还有配套的精品资源，点击获取