企业官网建设流程全解析

简介：天健医院信息系统数据结构手册是一份面向HIS系统开发、实施与运维工程师的数据库表结构说明文档，帮助不熟悉底层结构的读者快速掌握天健医疗HIS的数据字典与表间关系。手册内容覆盖公共部分、人员属性、国家地区及科室字典等核心模块，具体包含性别、婚姻、民族、血型、职业、身份、费别、病人来源等公共字典，以及工作人员、技术职务、科室字典、临床科室配置、科室与病房对照等常用表，并对每张表和字段的在用/未使用状态做了红蓝黑标识，方便直接参照业务含义进行查询与分析。资源以单个doc文档形式提供，压缩包约7.19MB，内含完整目录层级及字段级说明，适合用于系统对接、数据分析、二次开发和日常维护。当前已有852人学习下载，是一个了解天健HIS数据库结构较为直接的技术参考资料。

1. 天健医院信息系统数据结构手册：一张能省三个月工期的图纸

拿到一份几十页的《数据结构手册》，很多人第一反应是翻两页就丢回去——全是表名、字段名、类型和长度，读起来像天书。但真正做过医院信息系统对接的人都知道，这份文档比源代码还值钱。它记录了诊断、药品、医嘱、费用、检验、检查这些核心业务落在数据库里长什么样：哪个表存了什么、哪个字段是主键、哪个字段改了会影响收费。所谓集成、报表、迁移、对账，本质都是在跟这份结构定义打交道。适合谁？接 HIS 接口的集成工程师、要做数据抽取的临床科研人员、接手老旧系统维护的运维。有了这份手册，你不需要去问已经离职的开发者，不需要反编译黑匣子，照着字段定义就能把业务还原出来。

2. 医院信息系统数据结构：先看清它到底在管什么

2.1 HIS 数据模型的三个核心域：医嘱、费用与药品

医院信息系统（简称 HIS）的数据结构，无论厂商怎么设计，最终都绕不开三个核心域：医嘱域、费用域、药品域。医嘱域记录医生开什么、开给谁、什么时候执行，主表通常是医嘱记录表，每一条医嘱带着患者标识、就诊流水号、医嘱项目编码、开嘱时间、执行状态。费用域则围绕收费记录展开，包括挂号、诊疗、检查、检验、药品处方等各个收入来源，费用明细表是这里的核心，它把一条医嘱或一个项目的金额逐条拆开。药品域管理药品从入库、发药到退药的完整生命周期，药库库存表、药房库存表、处方发药记录都属于这个域。

这三个域不是独立存在的，它们通过患者标识和就诊标识互相咬合。一次门诊就诊，患者先有挂号记录，医生基于就诊号下医嘱，药房根据医嘱发药，收费处根据发药记录和项目执行记录生成费用明细。数据结构手册里最值钱的就是这些关联关系——哪个字段是逻辑主键，哪个字段是外键。拿到手册第一件事不是看字段字典，而是把这几个域的主表找出来，描出它们之间的连线。

2.2 从手册目录反推厂商设计思路

厂商的《数据结构手册》目录结构有一定规律，常见做法是分为基础字典、业务主表、业务明细表、日志表四层。基础字典包括科室表、员工表、收费项目字典、药品字典、诊断字典，这些表通常体积不大，但被所有业务表引用。业务主表记录一次就诊、一条医嘱、一张处方的主体信息，主表一般只存公共属性和状态，金额和数量拆到明细表，这就是为什么费用明细表动辄上百万行。

读目录时有个技巧：先看有没有「数据字典」章节。同一个厂商的产品，不同医院实施时，字典表结构往往是定制的，而业务主表和明细表结构相对稳定。手册如果同时包含标准表和自定义表，会在表名上做区分，比如前缀不同。我一般会先数一遍表数量，再看每张表的字段数量。一张主表 20～30 个字段是正常区间，如果某张主表超过 60 个字段，多半是厂商把多类业务揉在一张表里了，后续查询要特别小心。字段注释写得越细的手册越值得信任，注释能写到「0 未收费 1 已收费 2 已退费」这种级别的，说明文档经过实际维护。

2.3 常见 HIS 数据表清单：一张表对应一段业务流程

这张表不是标准答案，但涵盖了大多数医院信息系统结构的共性。实际手册里表名会有厂商前缀，遇到名称不一致不要慌，按「这个表在业务里解决什么问题」去对应。比如有的系统把药品库存和发药放在一张表，有的拆成两张，只要业务含义清楚，结构差异不影响整体理解。记住一条经验：先找收费项目字典和药品字典，这两个字典是所有业务表引用的根基，字段设计得烂的系统，这两个字典一定也烂。

3. 从字段反推业务：HIS 数据字典的精读方法

3.1 识别主键、外键与业务主键的三层关系

数据结构手册里每个字段都有类型、长度、是否为空、默认值这些属性，但真正决定数据质量的，是主键和外键怎么设计。HIS 系统里最常见的是用自增整型作为物理主键，比如流水号、序号字段，这类主键对查询分页友好，但对业务没意义。业务真正依赖的是业务主键，比如就诊号、医嘱号、处方号，这些字段在界面上可见，在接口报文里传递。

读字段定义时，先区分三层。第一层是物理主键，通常字段名叫 ID 或带有 SEQ 后缀，唯一但无业务含义。第二层是业务主键，比如 HIS 系统里到处出现的就诊流水号，它关联挂号、医嘱、费用、检查报告所有环节。第三层是外键，比如医嘱表里的患者 ID 指向患者基本信息表。最容易翻车的地方在于，不少厂商的业务主键本身由多个字段组合而成，比如「机构号 + 就诊日期 + 当日序号」共同组成一次就诊的唯一标识。只看单个字段会误以为它是主键，组合起来才是。遇到复合业务主键，一定要在笔记里记下来，所有关联查询都要带全字段。

3.2 状态字段与时间字段：最容易看走眼的两个细节

状态字段是数据结构手册里水分最大的地方。同一个业务，不同医院实施时状态枚举可以完全不同。门诊医嘱状态常见的有「开立、提交、作废、执行、终止」，住院医嘱多一套「停止、申领、发药」；来源字段也乱，一个收费项目可能是手工录入、接口写入、医嘱触发。手册如果只写「状态」两个字不写枚举含义，基本等于没写。我的习惯是拿到手册后，先把所有带「状态、标志、类型」的字段圈出来，逐一确认取值范围。确认方式包括翻手册附录、查界面代码、或者找医院信息科要一份维护文档。

时间字段的坑在时区和精度。有的系统用 datetime，有的用 timestamp，还有的用字符串存「20240101120000」。统一时间格式是做数据分析和接口开发的第一步。更隐蔽的是业务时间字段的含义，同一张表里可能有开单时间、审核时间、执行时间、记账时间四个时间字段，各代表不同环节。做费用对账时，取错时间会导致一个月的数据对不平。我的经验是：时间字段永远先确认「这个时间是谁在什么环节写入的」，而不是假设「它就是操作时间」。

3.3 金额与数量的精度：分还是元，这问题能吵一晚上

几乎所有 HIS 系统的金额字段都值得单独写一篇笔记。以分为单位还是以元为单位，乘以 100 还是除以 100，对接时搞错一次，对账就能出现百万分之一的误差。更麻烦的是折扣、医保报销、自付部分往往会拆分到多个字段：应收金额、实收金额、医保支付、个人账户支付、现金支付。字段之间不是简单的相等关系，而是经过结算规则运算后的结果。

数量字段同样有精度问题。药品有最小包装单位，比如一片、一支、一瓶，但处方可能开两盒，库存按盒扣减。医嘱频次字段用文字描述还是编码，也影响后续统计。读字段时，凡是数值型且带「金额、数量、单价、比例」字段的，必查三件事：单位是分还是元、小数位保留几位、有没有默认值或计算逻辑。手册上写「NUMBER(12,2)」只是数据库精度，业务单位必须看注释。注释写「单位：元，保留两位」的才是靠谱。没写单位的字段，宁可先去查一条样本数据，也别拍脑袋假设。

4. 从表结构推导接口与报表：把手册变成生产力

4.1 接口联调：如何用字段定义生成接口映射

数据手册最常见的实战用途是写接口。医院信息系统对外提供接口时，不管是视图、存储过程还是中间表，核心都是字段映射。我一般这样操作：先列出我方系统需要的每个业务字段，再在手册里找到对应来源表，把手册字段翻译成接口字段。比如需要患者姓名、性别、出生日期、联系电话，就去患者基本信息表里找对应字段。可能遇到命名不一致，例如手册里叫「姓名」，接口报文里叫「PATIENT_NAME」，映射文件里写清楚即可。

接口联调中有个容易被忽略的点：值域转换。字典表里的性别字段存的是 1、2、9，接口输出了「男、女、未知」。合法值映射必须做成独立的对照表，不要写死在代码里。另一个点是必填校验，手册字段标注「非空」，接口就要强制校验。如果厂商自己都允许空值，联调时要特别留意，空值传到下游会造成主数据缺失。开发阶段把这些约束理清楚，上线后少一半麻烦。

4.2 报表统计：直接从明细表聚合的代价

做 HIS 报表时，很多人上来就查费用明细表，用就诊号分组求和。这在数据量小的医院没问题，一旦门诊量上来，明细表几百万行起步，分组统计会拖垮数据库。更稳的路径是先看手册里有没有现成的汇总表。有的系统设计了日结表、月结表，专门存每天每个科室的收入汇总。找到这张表，报表就简单了。

如果没有汇总表，只能在明细表上聚合，那就得注意维度拆分。收入报表要按科室、收费项目类别、医保类型三个维度分别聚合，一次查询做三个 group by 效率极低。常见的做法是离线跑批，在凌晨低峰期把明细表刷进报表专用表。字段级注意事项：费用明细表里作废记录不会物理删除，用状态字段标记。聚合时要过滤掉已作废记录，否则报表数字虚高。这种「软删除」设计在 HIS 里非常普遍，手册上一般不写，得靠对业务流程的理解去发现。

4.3 数据迁移：手册是迁移脚本的唯一依据

医院信息系统换厂商、换版本时，数据迁移是硬骨头。老系统导出的数据要装进新系统的表结构，没有手册根本无从下手。手册的价值在于让迁移人员看清两边字段的对应关系。迁移脚本的核心不是 INSERT 语句，而是字段映射和值域转换。老系统性别存 0/1，新系统存 1/2，迁移脚本里得写 CASE WHEN。药品字典的编码规则更麻烦，老系统用拼音助记码，新系统用国家药品编码，这已经不是映射，而是需要维护一张编码对照表。

我处理迁移的思路分成三步。第一步，按手册把新系统的必填字段列出来，逐一去老系统找数据来源，找不到的字段要标记为「待确认」。第二步，写字段映射清单，包含老字段、新字段、转换规则。第三步，先迁移基础字典，再迁移业务主表，最后迁移业务明细，顺序反了会导致外键找不到父表。迁移完成后必须做数据校验，常见方式是数总量、比金额合计、抽查明细。这是整个项目里最不能省的一步。

5. 数据结构手册的常见坑：读不懂、对不上、查不全

5.1 手册与线上库不一致：文档更新的滞后性

现象：手册上标记的字段在测试环境查询直接报字段不存在，或者长度限制对不上。原因：系统迭代时，DBA 直接在线上库加了字段，但手册没同步更新。这是存量系统最普遍的问题。解决：核对手册前先查数据库系统表，以线上真实结构为准。做法是写一段查询，把系统表里所有字段名、类型、注释拉出来，和手册做一遍 diff，输出差异清单再判断。手册只能当参考，数据库本身才是真相。

5.2 一个字段多个含义：业务逻辑藏在不透明命名里

现象：某字段叫 remark，有的科室往里存备注，有的科室存过敏史，有的科室存出院随访内容。原因：厂商设计时偷懒，留了个通用备注字段，不同模块复用。解决：遇到这种「万能字段」，不能直接用于统计或关联。正确姿势是找该字段在不同业务模块的写入入口，逐条确认实际存储内容。如果是接手别人做过的集成，先翻对方的历史脚本，看这字段被当成了什么。字段名只反映设计意图，不反映实际数据。

5.3 查询结果慢到不可用：缺索引并不是唯一原因

现象：按手册的字段条件查询，大表查询耗时几十秒，接口直接超时。原因：条件字段没建索引是表层原因，更深层的是查询条件里用了函数，比如对时间字段做转换后再比较，导致索引失效。还有一种是关联查询时，驱动表选错，HIS 表动辄几千万行，关联顺序错了性能天差地别。解决：先看执行计划，确认是否走索引；然后把函数条件改成等值范围；最后调整关联顺序和过滤下推。血泪经验：任何从手册字段推出来的查询，第一步都要跑一遍执行计划再上线。

5.4 值域含义全凭猜：枚举值没有注释

现象：某个「来源」字段取值为 1、2、3，手册没写含义，网上搜索也搜不到。原因：实施阶段该字段由医院信息科自定义，厂商手册只覆盖标准版本。解决：最直接的办法是找医院方要字典维护界面或者后台配置表。很多自定义字典其实就存在数据库的某张配置表里，SELECT 一下就能看到完整值域。还有一招是取几条典型业务记录做特征分析，比如住院记录和门诊记录在这个字段上取值是否不同，能反推大致含义。不要靠猜，猜错一次，数据就脏一片。

6. 用手册做数据质控：不写一行业务代码也能发现脏数据

手册不仅能用来做接口和迁移，还能做数据质量检查，这是最后想分享的一个实用技巧。把手册里的字段约束当成「质检规则」，可以快速找出脏数据。比如手册规定就诊主表的就诊类型只能是「门诊」「住院」「急诊」，直接查询 DISTINCT 一下就能发现异常值；再比如手册标了必填的字段，统计 NULL 比例就知道主数据维护是否到位。我曾经接过一个项目，通过手册发现同一患者的姓名在两个子系统里长度不一致，最终定位到老系统没做校验、新系统做了，数据迁移时截断导致的。这类问题不做质控就很难暴露，等患者来窗口投诉就晚了。

做质控时我习惯先建一张结果表，把每一条规则验证的通过数、失败数、典型样本记录下来，形成一份数据质量报告，再和医院信息科逐条确认。这套方法不依赖复杂工具，有数据库查询权限就够了。另一个常用质控维度是关联完整性：费用明细表的就诊号是否都能在就诊主表里找到，找不到的就是孤儿数据，多半是退费单、异常单，要特别警惕。每次跑完质控，把新发现的规则补充进笔记里，手册本身的坑也就越填越少。

这些年 HIT 项目做多了，最大的教训是：拿到任何手册，先别急着写 SQL、画架构图，花一晚上通读字段定义，比任何后期返工都值。很多翻车现场，根源都是最初跳过了字段级的理解。数据结构的每个设计细节，背后都对应着某个真实业务流程，读懂了它，你就读懂了这套系统一半。希望帮到你。

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