简介面向医疗信息化工程师、HIS 系统运维与二次开发人员的数据库结构参考文档聚焦天健医院信息系统帮助不熟悉其数据模型的读者快速摸清表结构与字段含义降低数据查询、接口对接与报表开发的门槛。资源包共 1 个文件为 doc 格式的《天健医院信息系统数据结构手册》压缩包约 7.19MB内容按公共部分、人员属性、国家地区单位及其属性、科室字典等模块组织逐表说明字典表与业务表的用途。手册覆盖性别、婚姻、民族、血型、费别、病人来源等基础字典工作人员、技术职务、工作类别等人员表以及科室字典、临床科室配置、科室与病房对照等配置表并附版本更新记录与字段状态标识说明。已有 852 人学习适合作为日常查阅与数据梳理的案头资料。1. 医院信息系统数据结构手册一张医院运转的“总地图”你有没有过这样的经历去医院看病挂号、就诊、开药、缴费、取药每个窗口都像在跟一个独立的系统打交道但你的信息却神奇地一路跟着你走。这背后是一套叫 HIS医院信息系统的软件在支撑。而今天要聊的这份《医院信息系统数据结构手册》说白了就是这套系统的“总地图”——它不教你怎么写代码而是告诉你医院里每一个业务动作最终落在数据库里是哪张表、哪个字段。很多人第一次听到“数据结构手册”会以为是编程教材其实它更像一本字典的目录。字典告诉你每个字怎么读、什么意思这本手册告诉你每张表叫什么、存什么数据、字段之间怎么关联。对于刚接手一套陌生 HIS 的工程师来说没有这张地图面对几百张表就像进了迷宫——知道有路但不知道哪条通向药房、哪条通向收费处。这份手册的价值就是让你不用靠猜直接按图索骥。2. 为什么医院需要一本“表结构说明书”从挂号到取药的数字流水线2.1 医院业务太碎不标准化就会各说各话医院里最不缺的就是“分类”。性别有男女婚姻状况有未婚已婚离异丧偶病人来源有门诊、急诊、转院、社区……如果每个模块各自定义一套编码门诊系统说“1 代表男”住院系统说“1 代表女”数据一交换就全乱套。手册里专门辟出“公共部分”把性别字典、婚姻状况字典、民族字典、血型字典、职业分类字典、身份字典、费别字典、病人来源字典等全部收拢在一起统一编码规则。打个比方这就像快递公司给全国网点发了一本“地址标准手册”省市区县街道的写法必须一致否则包裹分拣就会出错。医院里的字典表就是干这个的——把“男/女”“已婚/未婚”这类高频选项固化成代码所有业务模块引用同一套值数据才能对得上。手册里还特别标注了红字表示“未使用”、蓝字表示“新增且在用”、黑字表示“在用”这种颜色约定本身就是一种低成本的版本管理手段让读表的人一眼看出哪些字段是活的、哪些是历史遗留。2.2 表与表之间靠“引用”串成一条链单独看一张表你只能知道它存了什么字段但医院信息系统的真正逻辑藏在表与表的关系里。手册的目录结构本身就是一条业务链先有人员属性工作人员字典、技术职务字典、医生职务字典再有科室字典和临床科室配置然后是疾病诊断字典、手术操作字典、药品字典、价表最后落到病人主索引、住院主记录、医嘱、检查、检验、收费。通俗地说这就像一家餐厅的运营手册先定义食材药品字典、再定义菜谱诊疗项目字典、再定义价格价表最后才是点菜单医嘱和结账单收费记录。手册里有一张“临床诊疗项目与价表项目对照表”专门解决“同一个诊疗项目在不同科室可能对应不同收费编码”的问题。没有这张对照表医生开的医嘱就没法自动转成收费项病人就得拿着单子来回跑。所以这本手册不只是“表清单”它其实在描述医院业务数据是怎么流动的。2.3 版本更新记录暴露了系统的生长痕迹手册开头的更新记录很有意思从 1996 年到 2006 年前后改了 15 稿早期由一人修改审核定稿后期变成“全新整理”还增加了医生站设备、输血管理结构、医嘱、病案流通、药品结构等内容。这说明医院信息系统不是一次性设计完的而是跟着业务需求长出来的。每新增一个科室、每上线一个新流程就可能多几张表、改几个字段。对接手系统的工程师来说这份更新记录就是“血泪经验”的索引哪些模块是后来补的、哪些字段是临时加的、哪些表标了“不使用”但可能还有历史数据。手册里大量标注“新增”“不使用”“已过时”比如检验模块里好几张表注明“1.0 版使用已过时”药品管理里也有“不使用”的采购记录表。这些标注比表结构本身更有信息量——它告诉你哪些路是死胡同别浪费时间往里钻。3. 手册里到底装了哪些“抽屉”按业务域拆开看3.1 公共字典与人员属性系统的“基础色”手册第 1 章和第 2 章基本是字典表的天下。性别、婚姻、民族、血型、职业、身份、费别、病人来源、入院方式、出院方式、病情状态、住院目的……这些字段看起来琐碎但它们是所有业务表的“基础色”。比如“费别字典”决定了病人是自费、医保还是公费直接影响后续收费逻辑“病人来源字典”区分门诊、急诊、转院影响挂号队列和病案归档规则。人员属性部分则把“人”拆成了多个维度工作人员字典存基本信息技术职务字典存职称工作类别字典存岗位类型医生职务字典存临床职务还有工作组字典和工作人员分组情况表来处理排班和核算组。这种拆法很像人事档案里的“主表子表”结构——一个人一条主记录但他的职称、岗位、所属核算组分别存在不同表里查询时靠人员标识号关联。手册里还专门有一张“费别与身份对照关系”表用来处理“某类身份对应哪种费别”的规则比如某些身份类别默认走公费医疗。3.2 药品、检查、检验三条最复杂的业务线药品管理是手册里表数量最多的模块之一从药品字典、药品名称字典、药品价格、公费用药目录到入库分类、出库分类、处方属性、摆药类别、毒理分类、剂型、类别、编码描述、药品信息、药品相互作用、用量信息再到库存定义、库存、盘点、入库主记录/明细、出库主记录/明细、发放申请、发放通知、结转记录、调价记录、总账……几乎把药房从采购到发药的每个动作都拆成了独立表。检查模块和检验模块也是类似思路。检查有检查病人主索引、检查预约记录、检查主记录、检查项目记录、检查报告、检查图象索引、检查随访记录、工作时间安排、时间间隔、病人时间安排、分组字典、计价项目甚至还有 PACS 相关的病人、检查、更新表。检验则有检验主记录、检验项目、检验结果、仪器配置、联机仪器字典、计算公式字典、标注字典、质控标本记录、质控参数、质控结果等。这三条线的共同点是业务动作多、状态变化频繁、和收费强关联。所以手册里反复出现“主记录明细记录”的配对结构比如药品入库主记录配入库明细处方主记录配处方明细检查主记录配检查项目记录。这种结构就像快递面单和包裹明细的关系——主记录存一次操作的总体信息谁、什么时候、哪个科室明细记录存这次操作里的每一项具体内容什么药、多少量、单价多少。查数据时先定位主记录再展开明细逻辑清晰且不容易漏项。3.3 病案与医嘱临床数据的“主干道”病案模块从病人主索引开始往下是住院主记录、在科记录、诊断记录、门诊诊断记录、主要诊断、诊断分类记录、手术记录、诊断对照记录、住院病人费用记录、输血记录、病案记录、病案追踪日志、病案索引、病历文件索引、联机病历描述、病历模板索引、病历模板选择、当前病历路径描述、病案纸张描述……这一串表基本覆盖了病人从入院到出院、从诊断到手术、从纸质病案到电子病历的完整轨迹。医嘱模块则是临床行为的“指令层”医嘱主表、医嘱计价项目、医嘱执行表、病人体症记录、医嘱记录单影像、成组医嘱模板主记录/明细、医生级医嘱模板对应表、会诊子表/主表。医嘱表的关键在于状态流转——开立、审核、执行、停止、作废每一步都可能触发收费、药品发放、护理执行等下游动作。手册里把“医嘱状态字典”“医嘱执行频率字典”“医嘱执行缺省时间表”单独列出来说明这套系统在设计时就把“什么时候执行、执行几次、每次什么状态”当成一等公民来对待而不是事后补逻辑。4. 容易混淆的几个概念别把“字典”当“记录”4.1 字典表 vs 业务表一个是选项一个是事实初学者最容易把字典表和业务表混为一谈。字典表存的是“可选项”比如性别字典里只有男、女、未知几条记录它不随病人变化业务表存的是“发生的事实”比如病人主索引里每一条记录对应一个真实病人性别字段引用字典里的代码。混淆点在于两者都叫“表”结构看起来也差不多。区分方法很简单看这张表的数据会不会随业务操作不断增加。字典表基本是静态的业务表会持续增长。手册里带“_DICT”后缀的基本都是字典表带“_REC”“_MASTER”“_INDEX”的通常是业务表。4.2 主记录 vs 明细记录一个管“这次操作”一个管“每项内容”药品入库主记录和入库明细记录、处方主记录和处方明细记录、检查主记录和检查项目记录都是“主明”结构。易混点在于什么时候查主表、什么时候查明细表通俗地说主表回答“谁在什么时候做了什么操作”明细表回答“这个操作里具体有哪些条目”。比如查某天药房进了几批药先查入库主记录按日期过滤再关联明细看每批的药名和数量。如果直接查明细表你会得到一堆散点不知道它们属于同一次入库。手册里这种配对结构反复出现说明它是这套系统的核心设计模式读表时先找主表再找明细顺序不能反。4.3 “不使用”的表 vs 真正删除的表历史数据还在里面手册里大量标注“不使用”“已过时”比如用户记录表标了“不使用”诊室字典标了“不使用”检验模块里好几张表注明“1.0 版使用已过时”。易混点在于很多人看到“不使用”就以为可以忽略。实际上这些表可能还有历史数据只是新业务不再写入。区分方法是看手册的颜色标注和版本说明——红字标识的表及字段是“未使用状态”蓝字是“新增且在用”黑字是“在用”。遇到“不使用”的表先确认它是否还被旧报表或历史查询引用别急着从 ER 图里删掉。4.4 价表 vs 收费记录一个是“标价”一个是“实收”价表模块里有价表、当前价表、价表项目分类对照、价表项目名称字典、计价单位字典、收费系数字典、价表项目执行科室、临床诊疗项目与价表项目对照、医嘱附加计价项目字典、病案首页费用分类字典、门诊收据费用分类字典、住院收据费用分类字典、核算项目分类字典、会计科目字典、支付方式字典……这一大串容易让人晕。核心区分是价表存的是“标准价格”收费记录存的是“实际发生的费用”。价表像超市货架上的标价签收费记录像小票。价表会调价所以有“当前价表”和调价记录收费记录一旦生成就不应随意改否则对账对不上。手册里把价表和收据费用分类分开列就是为了让“定价”和“记账”各走各的流程。4.5 病人主索引 vs 住院主记录一个人 vs 一次住院病人主索引存的是病人在医院里的唯一身份标识一个人一辈子可能只有一条主索引记录理想情况下住院主记录存的是每一次住院的流水号、入院时间、出院时间、科室等信息一个人多次住院就有多条记录。易混点在于两者都带“主”字查询时容易拿错。区分方法主索引的键是病人标识号住院主记录的键是住院流水号后者通过病人标识号关联到主索引。手册里还有“主索引合并记录”表专门处理同一个人重复建档后的合并操作说明主索引的“唯一性”在实际系统里是需要维护的不是天然就干净。5. 什么时候该翻这本手册什么时候别指望它这本手册的适用边界其实很清楚。当你接手一套陌生的医院信息系统、需要快速定位某类数据存在哪张表、需要确认某个字段的取值来自哪个字典、需要理清医嘱和收费之间的对照关系时它就是最直接的入口。尤其是做数据迁移、接口对接、报表开发、历史数据清洗这几类工作手册里的表名、字段名、主明细结构、字典引用关系能帮你省掉大量“猜表名”的时间。它不涉及具体 SQL 写法也不教业务规则但能告诉你“数据在哪”。反过来如果你需要的是业务操作流程说明、接口协议文档、或者性能调优方案这本手册帮不上忙。它只描述数据结构不描述“为什么这个流程要这样走”。另外手册标注了大量“不使用”“已过时”的表如果你要做的功能恰好落在这些表上别硬啃先确认当前系统是否已经换了实现方式。还有一点手册里的表名和字段名是给工程师看的不是给临床人员看的拿它去跟医生沟通业务需求大概率会鸡同鸭讲。我自己的习惯是每次接手一套不熟悉的医院系统先把手册的目录过一遍把“公共字典”“病人主索引”“医嘱”“价表”这四个模块的表名抄在一张纸上然后顺着业务链画一条从挂号到收费的线。这条线画完哪些表是主干、哪些是分支、哪些标了“不使用”心里就有数了。从那以后我每次做数据对接前都强制自己先翻一遍对应模块的字典表和主明细结构确认字段来源再动手写查询翻车的次数确实少了很多。希望这份梳理能帮到你。本文还有配套的精品资源点击获取