简介：天健医院信息系统数据结构手册是天健医疗HIS系统的数据库表结构说明文档，面向需要了解HIS底层数据结构的开发、实施与运维工程师，帮助读者快速掌握各业务模块的表设计逻辑，满足数据查询、二次开发与系统对接等场景需求。资源包为单个doc文档，大小约7.19MB，内容按公共部分、人员属性、国家地区与单位、科室字典、医疗工作等模块展开，覆盖性别、婚姻状况、民族、血型等公共字典表，以及工作人员、科室配置、合同单位、床位字典等核心表结构，并附有版本更新记录和目录索引，便于查阅。目前已有852人学习下载。手册详细罗列了表名、字段用途及字典项，可作为HIS数据库设计参考，对理解天健系统数据流、开展数据分析和项目维护都有实用价值。
1. 医院信息系统数据结构手册：一份被低估的运维地图
接手某医院的集成平台数据运维时，我翻遍了交接文档，最后发现最有价值的不是架构图，而是一份看起来过时的《天健医院信息系统数据结构手册.doc》。它没有花哨的 ER 图，没有冗长的建模理论，却让我在三天内定位了门诊挂号与收费之间的数据断点——这个断点已经让财务对账差异悬置了两周。医院信息系统（HIS）的数据结构手册，本质上是把挂号、医嘱、收费、发药、入出转这些核心业务翻译成表、字段和关联关系的一本字典。
对做集成、做数据迁移、做报表开发的从业者来说，这份资料解决的是最实际的问题：主数据挂在哪张表、费用流水怎么对账、住院床位变更去哪查。而对刚入行的开发，它比任何教科书都更接近真实业务。这篇笔记不评论手册文本本身，而是顺着它的结构，把所有 HIS 实施者都绕不开的表设计、典型坑和排查思路展开说透。
2. HIS 主数据与业务主档：六类基础表先对齐
2.1 组织与人员：科室表、病区表、员工表的角色区分
HIS 里最容易混淆的就是「科室」和「病区」。手册里通常会把它们拆成两张表：科室表（dept_dict）和病区表（ward_dict）。科室是业务归属单位，比如心内科、放射科；病区是物理护理单元，比如三病区、五病区。一张科室表可能对应多个病区，一个病区也可能跨科室收治病人，这在精神科或康复科很常见。
我在某医院做过一个数据抽取任务，需求方要「每个科室的住院患者数」。如果直接按住院登记表的科室字段分组，数字永远对不上，因为住院患者的科室归属会随转科变化，而病区才是床位所在。正确做法是先取病区表确认物理位置，再通过转科记录找到当前医疗归属科室。
员工表（staff_dict）则要区分「操作员账号」和「医务人员档案」。同一个医生可能有两个工号，一个用于排班考勤，一个用于开医嘱。开医嘱的工号绑定的是医师签名和处方权，取错字段会导致后续处方审核和抗菌药物分级管理全部错乱。手册里一般会用 staff_type 或 role_code 区分这两类，实施时建议把关联字段统一规范为 staff_id，避免在业务表中混用工号与员工内部主键。
2.2 患者主索引与就诊记录：patient_id 与 visit_no 的边界
患者主索引表和就诊记录表是整个 HIS 的根。患者主索引（patient_index）一个人一条记录，字段包括姓名、证件号、出生日期、性别、联系人信息。就诊记录（visit_info）则是每次来院一条，包含就诊类型（门诊/急诊/住院）、就诊时间、接诊科室、接诊医生。
让我反复翻手册的坑在「多次就诊合并」：患者可能用身份证建档一次，又用自费卡建档一次，形成两个 patient_id。某集成项目里，外院接口传过来的检验申请单，只带了姓名和身份证号，就要靠 patient_index 的证件类型+证件号码做匹配，匹配不上就自动新建档案，结果产生大量重复档案。后来在手册里看到了唯一索引设计——允许多个档案并存，但通过 merge_flag 和 master_patient_id 标识合并关系。这个设计不仔细看手册很容易忽略。
取业务数据时还要分清该用 patient_id 还是 visit_no：凡是跨多次就诊的统计（比如复诊率、历年就诊次数），用 patient_id 聚合；凡是当次就诊内的行为（处方、缴费、检验申请），一律用 visit_no 关联，否则会把患者上一次住院的医嘱带进本次就诊的数据流。
2.3 收费项目与字典表：划价与执行分离
收费项目表（item_dict）是 HIS 中最琐碎也最关键的字典。每个项目有项目编码、名称、规格、单位、单价、收费类别（药品/诊疗/材料/检验）、医保类别、自理比例等字段。光「一次性注射器」这类材料，在项目字典里可能就得维护几十条记录，区分 1ml、2ml、5ml 和不同厂家。
手册里值得注意的设计是「划价与执行分离」：开单时医生选择的是诊疗项目（order_item），执行科室执行后由护士或系统生成计费项目（charge_item），两者通过 order_id 关联。有时一个医嘱会拆成多条计费记录，比如「静脉输液」这个医嘱，实际计费会包括输液器、注射器、输液费、观察费四个收费项目。
报表开发最常见的错误是直接拿医嘱表（medical_order）里的项目编码和收费表（charge_detail）做 join，发现金额对不上。正确链路是医嘱 → 执行 → 计费，中间还有一层「执行记录表」。数据结构手册的价值恰恰在这里：它把这种对应关系用字段和关联条件固定下来，省去你逐张表翻索引的麻烦。
3. 门诊与住院的业务流水：两张最重的表如何读
3.1 门诊挂号与收费流水：一次就诊两条链
门诊的核心流水是挂号表（register_info）和收费表（outpatient_charge）。挂号表记录挂号的号别、号序、挂号时间、挂号费、就诊科室；收费表记录处方和检查的开单、收费、退费。两条链通过 visit_no 关联。
翻阅手册时会发现费用表会拆成两个层级：主表（charge_master）承载一笔费用的汇总信息（总金额、费别、结算方式、收费员、收费时间），明细表（charge_detail）承载每一条收费项目的数量、单价、金额。开发报表时只 join 明细表会丢失整单退费的信息，因为退费往往在主表上打 red_flag 或 reversal_flag，明细表可能已经按负金额冲销。
参数上建议注意结算方式字段：现金、扫码、银行卡、医保个账、医保统筹分别用不同的结算代码。对账时现金短款最常见的原因之一，是把结算方式为「混合支付」的单子按单一支付方式归类。手册中一般会规定一条明细记录只能挂一种结算方式，但一笔收费主记录可以对应多条结算流水，读数据时要用结算流水表（settle_flow）而不是收费主表的金额字段。
3.2 住院入出转与床位变更：状态机的数据快照
住院模块的主表是住院登记表（admission_info），字段包括入院时间、入院科室、入院诊断、床号、护理等级、主治医生。但真正让数据分析复杂的是「转科」和「转床」，这两类历史动作会记录在 bed_change_log 和 dept_transfer_log 中。
手册的体位设计是：admission_info 只保存当前状态，历史轨迹存在日志表。这带来一个典型问题——如果要统计某科室某月的收治人数，直接按 admission_info 的入院科室分组，会因为转科导致高估或低估。正确做法是按时间段取 dept_transfer_log 的首条记录作为入院初始科室，或者按「在科时间片」切割统计。
床位表（bed_info）本身也是一张会产生困惑的表。床号、房间号、病区、床位类型（普通/抢救/加床）都在里面，但实际业务中加床是动态的——某天走廊加了五张床，信息系统未必马上建档。此时住院患者的床号可能指向一个 bed_id 不存在的记录。手册设计通常允许 bed_code 自由文本，遇到这种数据不要强行关联 bed_info，保留原始床号字段做展示即可。
3.3 医嘱状态与执行闭环：长期医嘱的拆分逻辑
医嘱表（medical_order）是住院系统的数据心脏。药品医嘱、检验医嘱、检查医嘱、治疗医嘱都在这张表里，通过 order_type 区分。字段包括医嘱内容、开立时间、停止时间、开立医生、停止医生、执行状态。
长期医嘱（比如「口服阿司匹林 100mg qd」）有一个和门诊完全不同的逻辑：它需要按执行日期拆分为每日的执行记录。拆分逻辑要么存在医嘱执行表（order_execute）中，每条执行记录带计划执行时间和实际执行时间；要么通过「每日医嘱审核」生成新的执行批次。读数据时如果统计「某药品某月总用量」，必须在医嘱执行表上聚合，而不是在医嘱表上聚合，否则一条长期医嘱会被当作一次用量。
这里踩过的坑是「停止医嘱的作废标记」。医生开完长期医嘱后又停止，数据库里往往不是物理删除，而是给原医嘱记录写入 stop_time，同时生成一条新的作废医嘱记录（order_status = 'D'）。统计时必须过滤 order_status = 'D' 的记录，并保留 stop_time 作为真实有效截止时间，否则药品消耗量被翻倍计算。
4. 费用明细与对账逻辑：从 charge_detail 反查财务差异
4.1 费用项目编码与医保目录的映射陷阱
费用明细表（charge_detail）里每个收费项目都有项目编码、项目名称、数量、单价、金额、开单科室、执行科室、开单医生、收费时间、费别。与医保报销相关的字段包括医保类别、自付比例、超限价金额、自费金额。
HIS 和医保系统之间的数据交换依赖「三大目录」对照：药品目录、诊疗项目目录、医疗服务设施目录。医院内部项目编码与医保目录编码的对照关系挂在对照表（item_mapping）里。这张表在数据手册中通常只有寥寥几行描述，但实际出问题九成在这。
我见过一个案例：某医院一批「超声检查」项目在医保结算时全部报错，原因是内部项目编码对应了两个医保目录编码，一个属于检查费（可以报销），一个属于治疗费（有支付限额），对照关系在主备库之间不同步。排查方式很简单：把 charge_detail 按 item_code 分组，join item_mapping 看是否有重复对照、对照是否在有效期内。
对账时还要注意「按日期对账」的口径。收费时间字段是物理入账时间，而医保接口的回传时间可能与 HIS 入账时间相差数小时。财务对账以哪个时间为准，必须在手册的使用规范里写明，一般建议以 HIS 入账日期为基准，医保回传作为次月核对。
4.2 退费与冲正：负数记录不是错误
费用明细表出现负数记录是常态，不是异常。退费有三种常见情况：当日退费（原记录加红字标记）、跨日退费（原记录保留，生成负数红冲记录）、部分退费（原记录保留，生成负数部分冲销）。
手册中通常会用 charge_flag 或 item_status 标识正常、退费、作废。统计净收入时要用SUM(IF(charge_flag != 'C', amount, 0))这类写法，或者直接求 amount 的合计，因为退费记录本身已经把金额写成了负数。
但「负数记录」不一定都是退费。药品调价、材料盘亏、优惠减免（比如老干部优惠）也可能生成调整记录。而且不同医院实现方式完全不同：有的医院减免额单独字段维护，有的医院直接生成负数明细。不看数据结构手册，仅凭业务直觉做过滤条件，几乎必然出错。
4.3 科室与执行科室分离造成的收入归属问题
开单科室（order_dept）和执行科室（exec_dept）是费用表里两个不同的字段。检验项目通常是住院科室开单、检验科执行，放射项目是临床开单、影像科执行。绩效核算时不同口径导致收入归属不同：按开单科室归临床，按执行科室归医技，两者分开统计。
某次做科室工作量报表，需求是「每个科室的收入」，没有明确口径。我按执行科室做了，结果外科收入骤降、检验科收入暴涨，业务方完全不认可。后来加了开单科室维度才发现，一份尿常规申请单的收入会同时计入外科（开单）和检验科（执行），属于「双计」。手册中对这类字段的定义非常直白，但容易忽略的是它还配套一张「执行关系配置表」，控制哪些项目可以跨科执行，数据读取时同样要带上这张表的生效状态字段。
建议报表输出时把两个口径都列出来，作为同一指标的两个维度，而不是只取一个值。这样运维和财务争执时，可以直接下钻定位差异来源。
5. 排查指南：读 HIS 数据表的六个高频事故现场
5.1 时间精度不一：同一天的数据查不全
现象：按收费日期查询某日门诊收入，金额比收费员日报表少了几千块。
原因：收费时间字段有的是 date 类型，有的是 datetime 类型。收费员日报表按「结账批次」统计，结账批次可能跨自然日——22 点的班次结账到次日凌晨 2 点，费用记录带着次日日期，但结账批次挂在昨天。
解决：查询时不要用WHERE charge_date = '2025-06-01'，改用WHERE charge_time >= '2025-06-01 00:00:00' AND charge_time < '2025-06-02 00:00:00'或者直接关联结账批次表（settle_batch）取批次日期。手册里如果存在 settle_batch 表，优先以它为对账口径。
5.2 空值与默认值混用：未维护的字段悄悄入选
现象：统计各科室门诊量，发现有个「未知科室」类别数据量巨大。
原因：挂号表接诊科室字段允许为空，患者通过自助机挂号时未默认带出科室，入库时写入 NULL 或空字符串。而字典表 dept_dict 主键是科室编码，NULL 值关联不上，聚合时被归为「未匹配」分组。
解决：在抽取脚本里统一清洗空值：COALESCE(NULLIF(dept_code, ''), 'UNKNOWN')，并在映射表中为 UNKNOWN 建立一条虚拟科室记录，便于追溯真实来源。同时检查 HIS 前端配置，确认自助机接口是否传科室默认值。
5.3 转科不写日志：床位在 A 科，记录在 B 科
现象：某日某科室护士站看到的患者列表和管理系统统计的「当前在科人数」对不上。
原因：临床护士直接在床位管理界面把患者拖到了新科室床位，但没有走「转科」流程，业务表中 dept_transfer_log 无记录，只有床位的科室字段变了。admission_info 的当前科室字段也没同步。
解决：这类情况要看手册里床位表（bed_info）是否带科室归属字段。如果床头科室变了，但患者主记录没变，就需要用床位科室反推患者的物理位置。我通常会写一个核对任务：对比 admission_info.dept_code 与 bed_info.ward_code 对应的科室，不一致的就是「物理位置漂移」，需要列表转给护士长确认补流程。
5.4 退费作废后原单仍显示成功
现象：财务导出某收费员收款明细，发现一笔 5000 元检查费出现在流水里，但该患者实际没做检查，已退费。
原因：退费操作只更新了结算流水表的退费标志，收费主表和费用明细表保留了原记录，没有标记。报表只是按「未过滤退费」的 SQL 查询，必然带上这笔。
解决：这是数据使用规范问题。所有对外输出的收费流水，统一增加前端条件charge_flag <> 'C'或refund_status NOT IN ('R')。建议在数据仓库层建一个「费用事实表」视图，提前过滤退费、作废、冲正记录，业务部门只查视图，不碰明细表。
5.5 跨年归档导致本年数据断档
现象：查询今年 1 月数据，发现 1 月 1 日到 10 日的记录缺失，但收费员系统里有。
原因：部分 HIS 采用分库分表或按年度归档，去年年底的未结记录归档到了历史库，业务库只留当年。手册里通常会注明「当前表存放 YYYY 年至今数据，历史数据请查询 hs_ 前缀表」。
解决：数据抽取必须配置多数据源路由，按业务时间判断走当前表还是历史表。跨年边界最容易出问题的时间是 1 月初，建议每年 1 月对账时跑一个「归档边界校验」，对比业务库与历史库的记录数，验证归档任务是否完整执行。
5.6 手工数据与接口数据混用
现象：某个第三方系统同步过来的检查状态，与 HIS 内部状态字段值不一致，导致「已执行」和「未执行」统计错乱。
原因：HIS 内部状态用 status 字段存编码（0 未执行、1 已执行、2 已报告），第三方接口传入的值是字符串「已完成」，映射时没做完备转换，部分记录落库为 NULL。
解决：接口映射表里补全转换规则，NULL 值统一按「未知」处理，不参与统计。同时在接口入站时做数据校验，状态码不合法的直接拒收并进入错误队列表，而不是静默落库。错误队列表要设重推机制，避免夜间接口抖动导致数据永久缺失。
6. 进阶用法：用数据结构手册反向搭建一条就诊链路验证
弄清了表结构后，有一件事值得花一个下午做：用一份数据结构手册反向验证一条完整的就诊链路。方法是从挂号开始，到收费结束，把每一跳的关联字段串起来，验证环节之间的数据是否自洽。
以门诊流程为例：先查挂号表（register_info），用 visit_no 关联到医生工作站。医生开立医嘱（medical_order），再通过 order_id 关联到收费记录（charge_detail）。这时可以核对三个业务事实：该患者挂号科室是否等于开单科室；扣费金额是否等于医嘱项目金额之和；退费记录是否关联了原收费记录。有一条不满足，就说明接口链路或手工流程有断点。
我的职业习惯是拿每个月的第一天数据做全量链路检查。比如某个月 1 号，全院的挂号数为 A，门诊收费记录数为 B，其中「有挂号无收费」的患者列表拉出来，逐条看是否正常——可能是只开了处置没收费，也可能真的是漏收费。这个习惯帮我抓住过一次某门诊护士漏绑定执行科室导致月结差异的问题。
建议你把这份手册里的表关系整理成一张「数据地图」画在自己的笔记里：主数据表为根，业务主档为干，业务流水为叶。不要只收藏手册，而是手动梳理一遍，梳理过程要比阅读过程收获更大。毕竟再详细的手册也只描述字段，而线上数据的真实面貌永远比文档更复杂。希望这篇笔记能帮你在面对 HIS 数据时少几次翻车，多一些笃定。
本文还有配套的精品资源，点击获取
