★ FEATURED ARTICLE 简介《天健医院信息系统数据结构手册》是一份面向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 系统都会先找它的数据字典翻一翻按模块整理出核心表索引再对着字典核对一遍“在用”状态。这个习惯帮我提前避开了很多设计缺陷和数据口径不清的坑。这份手册也提醒我老系统的产业化过程中积累的表结构往往更贴近真实业务流程。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
