东华HIS表结构新版.docx解读：从字段清单到实战应用

简介东华HIS表结构新版参考文档是面向医院信息化建设者、HIS系统开发与运维人员的专业资料旨在梳理东华医院信息系统核心数据表的设计逻辑与关联关系。资源为docx格式共1个文件压缩包约92KBWord文档形式便于查阅、检索与备注。文档从CSP组件表入手系统覆盖用户、就诊卡、登记号、病人基础信息、医嘱项目、账单信息等模块逐一说明表名、字段含义及设计意图。具体包括用户信息表、病人登记信息表、就诊卡记录表、病人基本信息主表、婚姻状况、性别、职业、宗教、学历、民族等基础数据表医嘱部分则涉及医嘱项目定义、医嘱子类、医嘱大类、医嘱执行分类以及账单组表、账单小组表等并交代了HIS医嘱项与LIS医嘱套之间的关系。目前已有1656人浏览学习此资源可供需要了解东华HIS数据模型、进行系统二次开发、报表统计、数据迁移或日常运维的人员直接参考能显著提高对核心业务表的认识与查询效率。1. 东华HIS表结构新版.docx是什么底牌交付现场的第一份技术地图医院信息科或集成商做接口对接时经常会在邮箱里收到一份《东华HIS表结构新版.docx》。这不是普通的说明文档而是几百张业务表的字段清单、主键、类型和注释直接决定你评估工作量、排开发计划、写SQL和定位问题的效率。很多工程师拿到后直接打开全文搜索搜不到就开始猜表名几天后才发现方向偏了。这份文档能帮你解决三类具体问题第三方系统要和HIS做数据交互时快速确认字段是否存在、类型是否匹配数据迁移或上报时按表关系确定抽取顺序排查线上问题时从字段定义反推业务逻辑。适合的是做集成开发、数据工程师、实施顾问和医院信息科运维的人不是给业务人员看的操作手册。它不回答“按钮怎么点”只回答“数据到底存在哪张表里”。2. 先读懂新版docx的数据字典模块划分、字段命名与公共表打开《东华HIS表结构新版.docx》第一眼通常是几十页的目录和表清单。我一般不建议直接搜业务关键词而是先花半小时把文档的框架摸清楚。东华HIS的表结构文档虽然不同版本排版有差异但大体遵循“公共基础数据、临床业务数据、药品物资费用数据”三层结构。把这三层看懂后面所有工作都顺手。先从文档目录判断版本风格老版本偏Oracle风格字段多用VARCHAR2、NUMBER、DATE表名常带拼音缩写新版往国产数据库靠VARCHAR、NUMERIC、DATETIME这类写法越来越多。这个细节很重要因为它直接影响你后面写SQL时的类型转换和兼容性判断。2.1 公共基础表部门、人员、科室和它们的主键写法公共基础表是HIS所有业务的根通常包括科室表、部门表、职工表、用户表、患者主索引、收费项目字典、诊断字典等。这类表的特点是有稳定主键、编码字段和状态标志。我在实践里总结过一套公共表的典型结构虽然具体表名在不同医院版本里会有差异但字段设计逻辑高度一致。公共基础表常见形态如下主键一般是单列主键常见命名为ID、DEPT_ID、EMP_ID老版本里也有直接用业务编码做主键的写法。编码字段如DEPT_CODE、EMP_CODE医院内部编码通常是数字或拼音首字母例如内科写成NK。名称字段如DEPT_NAME、EMP_NAME。辅助检索字段如INPUT_CODE拼音码、WB_CODE五笔码、MB_CODE助记码这类字段在老HIS里很常见新版还在保留。状态字段如DELETE_FLAG、STATUS用于逻辑删除和启停用。时间字段CREATE_TIME、UPDATE_TIME。读公共表时要特别留意主键的生成方式。如果ID是递增数字插入时依赖序列或自增如果主键是VARCHAR类型且长度较长往往是编码规则生成拼接科室编码和日期的情况很常见。比如就诊号主键在部分版本里用YYYYMMDD 流水号拼接遇到跨年数据就要考虑分区或归档。还有一个容易被忽略的点职工表和部门表往往不是简单的归属关系而是多对多。一个医生可以属于多个科室文档里通常会有一张中间关联表比如EMP_DEPT_REL。如果你只盯着主表看后续做组织架构数据迁移时会漏数据。2.2 临床业务表医嘱、处方、病历单据的关联线索临床业务表是整个HIS表结构中最复杂的部分也是集成商开发接口时最常打交道的区域。医嘱、处方、申请单、病历文书、检查检验报告它们之间有明显的“主表 从表”结构。我在一个接口项目里遇到过很典型的情况第三方系统需要同步“某患者当天开的全部药品医嘱”如果只找到医嘱主表里面只有就诊号、医嘱状态和开立时间具体药品要从医嘱明细表去关联。主表的患者标识字段、就诊标识字段、开立医生字段明细表的药品编码、数量、频次、用法这些字段在文档里都会出现但需要你按“主表流水号 从表外键”的思路才能准确串起来。临床业务表常见的关联字段组合包括患者标识PATIENT_ID或PAT_ID可能关联到患者主索引表。就诊标识VISIT_ID、ENCOUNTER_ID一次住院或一次门诊是一个就诊。单据内部流水医嘱主表有ORDER_NO明细表有ORDER_ITEM_NO。上级单据号处方表里有RX_NO申请单表里有REQ_NO通过它关联医嘱。文档里通常会用字段注释说明“关联XX表”但新版docx字段注释不全的情况很多。这时候不要硬猜可以在文档里先搜索“医嘱”或“处方”定位到目标表附近再反过来看字段列表。另一个线索是字段名本身比如以ORDER_开头的字段大概率属于医嘱域以RX_开头的属于药品处方域以REQ_开头的属于检查检验申请域。如果只看字段不满足需求我会把临床业务表的“状态值”整理出来。医嘱状态在文档里经常是ORDER_STATUS类型是CHAR(1)或VARCHAR(2)注释可能只写“医嘱状态”而不写取值含义。这时要借助后续的字典表去匹配比如医嘱状态字典表里会定义 0-未审核、1-已审核、2-执行中、3-已停止等。这个组合阅读法能把一份看起来单薄的表结构文档用出两倍价值。2.3 药品物资费用表库存单据和结算表的状态机药品、物资、费用这三类表在HIS里承担的是“钱和物”的流转比临床表更讲究状态一致性和单据闭环。表结构文档读到这里重点不再是字段名而是状态字段和单据号的关系。药品相关表一般包括药品字典、药品库存表、入出库单据表、入出库明细表。物资与设备类似只是字典字段不同。费用相关表通常有费用明细表、结算表、退费记录表。我看到很多工程师在这里踩坑把药品库存表当成实时库存来源。其实HIS的库存表是“账面库存”它依赖入出库单据流水的累积计算。表结构文档里如果没有STOCK_QTY字段让你误以为可以直接查要注意旁边是否还有LOCK_QTY锁定数量、AVAILABLE_QTY可用数量之类的字段。有锁定数量的版本说明系统支持占用和释放逻辑直接读库存表会多算或少算。费用表的设计更能体现版本演变老结构里费用明细表字段较少费用类别靠FEE_TYPE一个字段区分。新结构里费用表拆得更细增加了结算批次号、医保结算状态、自费标志、记账时间等字段。退费不是删除记录而是通过反向记账或冲正记录体现这也是为什么文档里有红冲标志、冲正单号这类字段。读费用表时我习惯关注几个关键字段CHARGE_STATUS记账状态、SETTLE_NO结算号、REFUND_FLAG退费标志。这三个字段决定了一张费用单是有效、挂账、已结算还是已退费。如果只按时间范围查费用明细不判断状态统计报表数字会失真。3. 用表结构快速锁定业务表按模块前缀过滤、按字段反查的两条路表结构文档动辄几百张表全量通读不现实。我拿到新版docx后会先建一个Excel索引把表名、表注释、所在页码三列拉出来然后按业务需求过滤。两条路最常用按表名前缀过滤模块按字段反查定位表。前者适合你知道业务模块但不清楚具体表名后者适合你只有一个字段名或中文含义。3.1 按功能模块前缀过滤挂号、医嘱、药品表的写法差异东华HIS的表名存在明显的模块前缀习惯虽然不同项目可能有定制化修改但前缀规律值得先试探。常见做法是先用Word打开docx在导航窗格里搜索几个典型关键词挂号、收费、医嘱、处方、病历、药品、库存、结算。搜索结果会带你进入对应章节然后观察附近表名的共同前缀。我见过比较多的情况是挂号相关表以REG_或OUTP_开头对应门诊挂号、门诊就诊域。收费相关表以FEE_、CHARGE_、PAY_开头费用结算域集中在这个前缀下。医嘱相关表以ORDER_或ORD_开头有时会区分ORDERS和ORDER_ITEMS。药品库存相关表以DRUG_、MM_西药/材料、STORAGE_开头。住院相关表可能用IPD_、INP_门诊用OPD_。这些前缀不是标准规范我从来不会直接拿前缀去写SQL而是把前缀当成检索线索。过滤出来的候选表再去核对字段确认是否真的是目标表。特别是同义词问题比如药品表可能叫DRUG_DICT也可能叫MEDICINE_DICT光靠前缀定位会漏。一个实用技巧是在Excel索引里加一列“业务关键词”把表注释里出现的词整理出来例如“患者”“就诊”“处方”“库存”“结算”然后用筛选功能批量过滤。这样比反复在Word里搜索快得多。把索引表维护好了后面无论是写接口还是排查问题都能在几分钟内定位到表。3.2 按字段反查表用Word和Excel里的搜索替代猜表名有时候需求不是“查哪张表”而是“这个字段到底属于谁”。比如你要同步患者的医保类型但只知道字段名叫INSUR_TYPE或中文叫“医保类别”。从业务表名猜很可能猜错更可靠的是在整套文档里反查。如果docx里的表格已经分了页并且目录完整可以用Word的“在结果中查找”功能先搜中文注释“医保”再搜英文候选字段名。搜索范围别局限在一个文件里把整个目录章节都覆盖。找到的每一个目标表都打开看一下上下文确认它处于业务步骤的哪个位置。更高效的做法是把docx里的表格批量提取到Excel。常见的转法是用Word的另存为或复制粘贴再用Excel清洗全选表格内容复制到一个空白Excel工作簿。分列清洗去掉合并单元格带来的空行。把字段名列、类型列、注释列分别整理成列。用Excel筛选或查找功能输入关键词定位。有些版本docx里的表格是图片或嵌入式对象不能直接复制文字就需要用Python的python-docx库把表格解析出来。解析脚本大致长这样from docx import Document doc Document(东华HIS表结构新版.docx) for i, table in enumerate(doc.tables): print(f--- 表格 {i} ---) for row in table.rows: cells [cell.text.replace(\n, ).strip() for cell in row.cells] print(\t.join(cells))这个脚本不会处理太复杂的合并单元格但足够把字段清单导出来。doc.tables是Word文档里的所有表格对象每个row是一行cell.text取出单元格文字。导出后你会发现很多表头不一致清洗时保留四列表名、字段名、类型、注释。有了这张总表反查字段就变成Excel筛选动作十几秒出结果。3.3 文档与生产库对不上时优先信谁新版docx看起来比旧版完整但它始终是“文档”不是生产库本身。经历过几个项目后我的原则很明确文档是线索生产库是事实。最典型的情况是文档里写的是VARCHAR2(20)生产库里已经是VARCHAR(20)文档里有一张表叫ORDER_MAIN生产库里建了视图却删了物理表文档里某个字段注释是“作废”但生产库还在用。这些不一致在接口联调阶段会直接变成运行错误所以不要拿文档里的定义直接写死SQL。验证方式很简单连上生产库查元数据。Oracle用ALL_TAB_COLUMNS神通数据库或兼容模式可以用USER_TAB_COLUMNS或系统表_FIELDSMySQL用information_schema.COLUMNS。先确认表存在再确认字段存在最后核对类型三步做完再写业务逻辑。如果文档和库有冲突我会以生产库为准并把差异记录在索引表的“备注”列里。这看起来多了一步但能避免你基于错误定义写代码后返工。复杂场景下文档里的字段名在生产库已经改名靠搜名字找不到需要查字段注释再去反查。这时候优先查数据库里的注释表比盲搜文档高效。4. 表结构文档的3种实战用法对接接口、迁移数据、做报表统计把表结构文档读懂只是起点真正有区分度的是怎么用。同一个文档我的用法分三种场景接口开发、数据迁移、报表统计。三种场景对表结构的关注点完全不同照着同一套思路会出问题。4.1 接口对接字段类型、必填项和状态值决定写入时机第三方系统和HIS做接口最常见的是推送挂号信息、查询费用明细、回写检查结果。无论哪种接口开发的第一步不是我写代码而是把表结构的必填字段盘清楚。很多接口报错不是接口协议问题而是写入的字段不符合表结构约束。我喜欢从表结构文档里提取“写入检查单”主要看三件事字段类型是否匹配文档里是NUMERIC(10,2)你传了字符串数据库会报类型错误。是否存在非空约束注释里标了“必填”或“非空”写入时缺字段直接失败。状态字段取值是否合法比如STATUS只接受0和1你传了2业务逻辑会异常。写接口前先用一段SQL核对目标表的实时结构比反复翻Word快得多。下面是我常用的Oracle查询脚本换成神通数据库或MySQL时改一下系统表名即可SELECT a.column_name, a.data_type, a.data_length, a.nullable, a.data_default, b.comments FROM all_tab_columns a LEFT JOIN all_col_comments b ON a.owner b.owner AND a.table_name b.table_name AND a.column_name b.column_name WHERE a.table_name ORDER_ITEMS ORDER BY a.column_id;这段SQL的作用是输出一张表的字段名、类型、长度、是否可空、默认值和注释。all_tab_columns是Oracle的系统视图保存所有表字段定义all_col_comments保存字段注释。两者通过表名和字段名关联能一次性看清字段约束。神通数据库全面兼容Oracle模式时同样可用。注意NULLABLE列的值是Y或NN就是非空。接口写入时优先处理非空字段再处理有默认值的字段。如果文档和生产库不一致以这里查出来的结果为准。4.2 数据迁移按主子表关系决定抽取顺序与去重键数据迁移和接口开发相反接口开发关心单表字段约束数据迁移关心表与表之间的依赖顺序。HIS的数据往往有主外键关系直接全量抽取会碰到子表先插、主表还没插入的尴尬。我一般会把表分成三个批次抽第一批次公共基础表科室、人员、字典表它们不依赖其他业务表。第二批次业务头表挂号记录、医嘱主表、入库单主表。第三批次明细表医嘱明细、费用明细、入库明细。分批次之外还要解决重复数据问题。老HIS在多年运行后基础表里的代码可能出现过重复比如一个科室编码被占用后来又重建了一条新记录。迁移时用去重键很重要。下面这个SQL用开窗函数按业务编码去重SELECT * FROM ( SELECT dept_id, dept_code, dept_name, ROW_NUMBER() OVER ( PARTITION BY dept_code ORDER BY update_time DESC, dept_id DESC ) AS rn FROM dept_dict ) t WHERE rn 1;这段SQL以dept_code为分组键用ROW_NUMBER()给同编码的多条记录编号保留UPDATE_TIME最新的一条。PARTITION BY指定分组字段ORDER BY决定哪条算最新。实际迁移时公共表用这个逻辑清洗后再抽业务表能避免外键挂到被废弃的记录上。时间范围增量抽取不要只看CREATE_TIME还要看UPDATE_TIME。HIS里的数据经常在创建后被修改只按创建时间抽会漏掉状态变更。文档里的表如果有这两个字段优先用UPDATE_TIME做增量边界。4.3 报表统计先看索引、冗余字段避开大表join报表统计最容易翻车的地方是性能。HIS的表数据量是千万级起步医嘱明细和费用明细每年积累下来一张表可能上亿行。表结构文档里虽然不直接写索引部署情况但会告诉你哪些字段适合做索引。比如某个字段注释里写了“索引字段”或“高频查询”那就可以放心用于过滤条件。设计报表查询时我的习惯是在大表上只查必要字段不要SELECT *同时优先利用文档里的冗余字段。新版HIS表结构里经常能看到冗余计数字段比如ORDER_COUNT、TOTAL_FEE这些字段在业务写入时已经计算好报表直接读取比实时聚合快得多。如果要按月统计某科室的费用汇总又不想在大明细表上全表扫我建议先做日汇总或小时汇总。下面是一个按日汇总费用的查询骨架SELECT dept_code, TRUNC(fee_time) AS fee_date, SUM(amount) AS total_amount FROM fee_detail WHERE fee_time TO_DATE(:start_date, YYYY-MM-DD) AND fee_time TO_DATE(:end_date, YYYY-MM-DD) 1 GROUP BY dept_code, TRUNC(fee_time) ORDER BY dept_code, fee_date;TRUNC(fee_time)把时间截断到当天GROUP BY按科室和日期分组适合先把数据缩小再和各科室名称表关联。报表慢时检查执行计划看看是否走到全表扫描而不是去改表结构文档里的字段定义。5. 踩坑记录读东华HIS表结构时常见的5类翻车表结构文档带给你的不只是便利还有隐蔽的坑。以下五类问题是我在项目中反复遇到的每条都按现象、原因、解决写清楚希望能帮你省下排查时间。5.1 字段注释是空的现象文档里表名和字段名都有但注释列大面积空白只能看到COLUMN_NAME完全不知道这个字段是干什么用的。尤其出现在临床业务表里几十个字段全是英文缩写根本不敢下手。原因《东华HIS表结构新版.docx》很多是从数据库建模工具反向生成的字段注释没有同步到工具的字典里导致导出时注释丢失。越老的模块越容易出现这种问题因为当时的开发规范不强制写注释。解决先用数据库实时注释补一遍Oracle查ALL_COL_COMMENTS神通数据库查同名字典表。如果库里的注释也是空的就去找HIS前端页面对应功能把页面输入项名称和字段名对应起来。再不行就查后台日志或接口入参从代码里反推字段含义。不要猜猜错的代价是上线后数据错误。5.2 同一个业务对象出现两套字段名现象文档里同样的“患者姓名”有的表叫PATIENT_NAME有的表叫PAT_NAME同一个“医保类型”出现在不同章节里字段名完全不同。你在多个表间做关联时因为字段名不统一join条件容易写错。原因HIS系统经过多次迭代不同时期开发的模块由不同团队负责命名规范没统一。老模块用业务拼音缩写新模块用英文单词两套风格并存。新版docx只是把旧表和新表的定义合在一起没有做字段标准化。解决以生产库实际字段为准建立“同义字段映射表”把患者ID、就诊ID、医嘱号等高频字段的不同写法统一到同一套标准命名。需要join时先查映射表确认两边的字段是否真的代表同一个含义而不是只根据字段名里的相似词做判断。5.3 数据类型和实际库不一致现象文档上写DATE生产库里是DATETIME接口代码按照文档格式化时间结果读出时分秒全丢失或者文档写VARCHAR2(10)生产库已经改成VARCHAR(20)报“ORA-12899 值太大”的错误。原因数据库从Oracle迁移到国产数据库时建表语句里的类型被自动转换文档没有同步更新。也可能是历史表做过字段扩容但文档再导入时仍然使用旧定义。解决不要用文档里的字段定义做接口代码的硬编码校验。联调前用ALL_TAB_COLUMNS或国产库的系统表拉取真实字段类型再和文档做一次差异对比至少把变更过的字段记到备注里。5.4 已删除表还留在文档里现象在docx里找到了一张很匹配需求的表字段注释都齐全但连到生产库一查提示表或视图不存在代码直接报错。原因文档是基于某个历史版本的数据库生成的后来表做过下线、重命名或拆分成多张表文档没有同步清理。解决凡是发现疑似不存在的表先查数据库系统视图确认物理表是否还在。不在的话可以在同章节找相近表名的替代表或者查表的创建时间判断是否属于历史归档表。文档里标注清楚“已下线”避免自己第二次踩同一个坑。5.5 唯一键和索引没标全现象表结构文档只标注了主键字段但业务上需要唯一约束的字段没有列出来导致你用该字段做去重或幂等校验时实际不生效数据重复写入。原因文档导出工具默认只提取主键约束不导出唯一索引、普通索引。新版docx也可能是由人工维护只画了主键遗漏其他索引。解决上生产库查实际索引Oracle用ALL_INDEXESMySQL用SHOW INDEX FROM神通数据库有对应的系统表。把实际唯一键和维护到Excel索引表里。写入逻辑不要假设文档里没有唯一键就认为可以重复插入以数据库实际约束为准。6. 把表结构变成长期资产docx转Excel并用DBStudio与库内结构比对文档最终不应该停留在docx这种不便检索的形式里。我的收尾习惯是把它转成Excel索引再用数据库管理工具把生产库的真实表结构导出来做比对形成一版“带差异批注”的可用资产。这套动作做一次后面每次接口开发都能省时间。6.1 用Navicat导出数据库表结构为表格Navicat是日常管理数据库比较顺手的工具但很多版本没有一键导出表结构为Excel的功能。常见做法是用SQL查询系统表把结果集复制粘贴到Excel里。以MySQL为例SELECT table_name, column_name, column_type, is_nullable, column_default, column_comment FROM information_schema.columns WHERE table_schema his_db ORDER BY table_name, ordinal_position;information_schema.columns保存了字段级全部元数据。执行后把结果复制到Excel就能得到一张和生产库完全一致的表结构清单。如果是Oracle或神通数据库把table_schema换成对应owner名系统表改成ALL_TAB_COLUMNS。6.2 用神通数据库DBStudio只备份表结构如果目标库是神通数据库管理工具DBStudio支持只导出表结构的功能。它的价值在于生成一套干净的建表DDL脚本不包含数据便于做离线对比。操作上只需选择目标库或Schema在导出选项中勾选“仅导出表结构”或“不导出数据”生成SQL脚本后保存为文本。这套脚本是所有版本兼容性判断的基准。拿到后把前面从docx里提取的字段清单和脚本里的字段定义放在一起按表名匹配逐字段核对类型、长度、是否为空、默认值。差异部分用一个“结构差异表”记录字段级差异标出Docx值、数据库值、处理结论。6.3 差异比对口径与收尾习惯比对结果并不是所有差异都要处理。我的收尾习惯是先按影响程度分级高优先级字段名不一致、必填字段存在性差异、类型不兼容这类会直接导致接口报错必须改。中优先级长度不一致、默认值有区别这类影响数据写入边界建议改。低优先级注释缺失、字段顺序不同、已下线表这类只影响阅读和开发效率记录即可。把差异表归档到项目文档里并标注比对日期、数据库版本、库实例地址。下次再有人问你“XX字段在哪张表”你可以直接给他Excel索引而不是甩一份几百页的docx让他自己翻。这几年我养成的习惯是新建项目的第一周不写业务代码先花一天把表结构文档转成可检索的Excel索引并完成和生产库的基础比对。前期这步看起来很慢但后面每次排查一条慢SQL或对齐一个接口字段都能省下半天。表结构文档是一份会过期的资产只有把它变成你手里维护的索引表它才算真正属于你的工具。希望这份整理思路对你有点用。本文还有配套的精品资源点击获取