简介天健医院信息系统数据结构手册是天健医疗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 数据时少几次翻车多一些笃定。本文还有配套的精品资源点击获取