简介这是一份关于东华His数据库表结构的系统性整理面向医院信息化建设者、HIS二次开发与运维人员可帮助读者快速建立表结构认知减少系统对接与数据排查中的查阅成本。文档对东华HIS的核心数据模型进行了系统梳理涵盖CSP组件、用户与就诊卡、病人基础信息、医嘱项目、账单信息等模块并细分到病人基本信息主表、婚姻状况、性别、职业、宗教、学历、民族等基础字典表以及科室、医院、医生、病房、床位等资源表。在医嘱部分不仅列出了医嘱项目定义、医嘱子类、大类、执行分类等基础配置还重点说明了医嘱套与医嘱项的关系、病人医嘱记录明细与就诊明细关联表的关键作用便于理解门诊处方和住院医嘱的存储逻辑。资源为单个docx文档压缩包大小仅92KB内容为可直接查阅的表结构说明适合医院信息科人员、HIS系统实施与开发工程师、以及需要做数据对接或字典维护的读者使用。目前已有1656人学习是一份轻量但信息密度较高的东华HIS结构参考资料。1. 东华HIS表结构新版.docx为什么说它是二次开发和接口对接绕不开的“第一份资料”医院系统集成项目的第一个工作周最常出现的场景是新来的工程师被叫到会议室然后递过来一份Word文件文件名就叫“东华his表结构新版.docx”。这份文件是东华软件HIS系统交付物里最枯燥也最值钱的一本蓝图它把门急诊、住院、收费、药房药库等核心模块的数据存储关系全部以表和字段的形式摊开。凡是接医保接口、做数据中台、上互联网医院前期设计都离不开它。对实施工程师来说它比业务流程图更接近真相对数据开发来说它是写ETL的字段依据。这篇文章我会从表格怎么读、字段怎么看讲到怎样把它变成可检索的字典再点几个常见的翻车点。2. 读懂东华HIS表结构新版.docx的内容组织从模块划分到字段定义的三个层次很多拿到这份文档的人第一反应是打开Word直接CtrlF搜字段名。结果搜出来的往往是一大堆同名词比如“状态”“编码”“时间”各出现几十次越查越乱。这是因为没先看文档的整体框架。东华HIS表结构文档不是一张大宽表堆出来的而是按业务模块分层摆放的。真正去吃透它我通常分三个层次看表目录、字段定义、关系约束。这三层分别解决“有哪些表”“每个字段是什么”“表怎么串起来”的问题每一层漏掉都会在后续写SQL时付出代价。2.1 表目录先按模块划分做一张“索引地图”东华HIS表结构文档开篇一般会放一个总目录目录把表按照基础资料、门诊诊疗、住院护理、药房药库、收费结算、系统管理这些模块分组。不同版本的HIS交付模块划分会有细节差异但分组逻辑通常不会变。我拿到文档后第一件事不是看表而是把目录复制到Excel整理成四列模块、表名、中文名、主要业务动作。比如收费结算模块下的表主要业务动作是记账、冲正、结算将来统计科室收入时就知道先在这个模块里找表而不是全库乱翻。填备注时要注意一点同一张表可能同时被两个模块引用例如药品基础表既在基础资料里维护又被药房药库模块引用。遇到这种情况在“主要业务动作”里写两个动作不要写“关联模块”否则排查问题时要反复回翻原文。这一步大约耗时二十分钟但换来的是整张地图在手。2.2 字段定义页类型、长度、可否为空是三个必须看懂的信号每张表的字段定义是文档里信息最密集的部分格式通常是一个字段一行列出字段名、数据类型、长度、可空性、默认值、说明。字段类型要重点区分字符和日期。在Oracle和神通这类数据库里日期字段带不带时分秒直接决定接口参数怎么传按天统计只需要日期按小时统计就必须有完整时间戳。长度这个信号也很关键字符字段长度接近满时接口拼接会报错接手旧系统时按文档中的长度定义预留百分之二十余量比较稳妥。可空性和默认值经常被忽略但它们是插入数据翻车的重灾区。文档里标着“可为空”的字段实际库中可能已经被升级脚本改成NOT NULL文档标了默认值实际表可能没有加default属性。所以处理字段时不要只抄字段名和类型要把可空性、默认值一并抄进基线表。文档备注里如果出现“0-未结算1-已结算”这类枚举说明更要单独摘出来做成枚举清单它比任何代码里猜出来的条件都可靠。提示同一含义在不同模块可能叫“费用状态”“记账状态”“结算状态”联表条件不要只看字段名像不像要看注释是否指向同一个枚举。2.3 主外键与索引看清表与表怎么才能串起来字段读完下一步是梳理主外键关系。主键决定单表唯一性外键决定关联方向。HIS里最常见的关联是患者主表到就诊表再到医嘱和费用最终由就诊号或患者内部号串起整条业务链。文档里若写了索引通常暗示了高频查询条件比如按病历号查患者、按科室和日期查当日业务。把这些索引列摘到Excel的“高频查询列”栏后续写SQL时优先用这些列做WHERE能省掉不少慢查询的麻烦。如果文档里没有ER图我会自己画一张手画都行只要把“患者表主键被就诊表外键引用”“医嘱表挂到哪张费用表”这类指针标清楚。这张手绘图在设计接口查询时比任何代码都直观。实际中有个常见错误把就诊业务号当成患者主键去关联业务流水。正确路线是先通过就诊表找到患者号再挂过去的其他业务表顺序反了就容易出现一个患者查出多条无关记录。2.4 三遍读表法从文档到SQL规划的实际习惯面对几百张表的结构文档不可能一个晚上全部吃透。我常用的方法是“三遍读表法”第一遍只读目录和高频模块的表名花半小时建立整体感第二遍挑与手头任务相关的模块把字段和注释过一遍第三遍才是精读针对要写的查询把涉及表的字段、主外键、枚举值全部抄进设计稿。大多数人的问题在于跳过前两遍直接精读结果被大量同名词淹没最后写出来的查询条件连自己都解释不清。3. 把docx变成能查的数据库字典python提取与dbstudio建表实操一份真实交付的东华HIS表结构文档动辄几百张表如果靠人工在Word里翻页找字段效率太低。更实际的做法是先把Word表格提取成结构化数据再和目标库的真实表结构做比对。这样既得到一份基线字典也能发现文档版本和线上库表之间的差异。这一章我按实际项目里的三个步骤写提取、导库、比对。3.1 用python-docx批量提取Word里的字段表通用的做法是使用python-docx读取.docx里的所有表格再交给pandas统一处理。东华HIS表结构文档里的表格格式相对规整每行一个字段列顺序多为字段名、类型、长度、可空、默认值、说明。下面这段代码可以直接跑# 用 python-docx 提取东华HIS表结构文档中所有表格 from docx import Document import pandas as pd doc Document(东华his表结构新版.docx) frames [] for i, table in enumerate(doc.tables): rows [] for row in table.rows: # 去掉单元格首尾空格避免字段名和注释对不上 rows.append([cell.text.strip() for cell in row.cells]) df pd.DataFrame(rows) if len(df) 0: continue # 第一行通常是表头但也有部分表格没有表头需要手动指定列名 df.columns df.iloc[0] df df[1:] frames.append(df) # 合并所有表格得到一份“文档字段字典” doc_df pd.concat(frames, ignore_indexTrue) print(f共提取表格 {len(frames)} 个字段行 {doc_df.shape[0]} 行)代码逻辑说明先遍历文档里所有的table对象把每一行单元格转成字符串列表再用第一行做列名其余行做数据。参数上需要注意两个细节一是strip()必须加Word单元格经常带隐形空格不清理会把字段名变成带前导空格的形式后续与数据库比对时必翻车二是表头不一定是标准字段名如果发现提取后列名变成第一条数据说明这张表没有表头行需要手动指定列名而不是用第一行。3.2 用dbstudio导出当前库的真实表结构只出结构不出数据文档是某个时间点的快照线上的库可能已经过升级或定制开发。所以我一般再从dbstudio也就是神通数据库自带的管理工具里导出现库结构和文档对齐。dbstudio的导出菜单一般会有“仅导出对象定义”或“只导出表结构”选项操作时选择目标库和模式只勾选表和索引不勾选数据行。如果界面上找不到这个菜单更可靠的方式是用SQL查系统字典-- 神通数据库/Oracle 风格查当前模式下的全部表和注释 SELECT table_name, comments FROM user_tab_comments ORDER BY table_name;-- 查表字段信息表名、字段名、类型、长度、是否可空 SELECT table_name, column_name, data_type, data_length, nullable FROM user_tab_columns WHERE table_name IN (PATIENT, VISIT, ORDER_BASE) ORDER BY table_name, column_id;说明user_tab_comments和user_tab_columns是系统字典视图第一个给出表名和表注释第二个给出字段级信息。用这两个查询导出的结果保存为CSV或Excel就是“实际库表结构”。如果用的是其他数据库就去查对应的information_schema视图思路完全一样。这个方案比图形界面导出更通用不受dbstudio版本差异影响也方便后续脚本化处理。3.3 合并得到“字段基线表”让文档真正可查现在手上有两份数据一份来自Word文档一份来自实际数据库。下一步按表名和字段名关联合并。常见做法是以文档为主表做左连接实际库结构作为校验列。这样一张“字段基线表”就成型了某张表按文档有哪些字段、实际库有哪些字段、哪一列缺失、哪一列是新增一眼就能看到。# 假设 db_df 是从 user_tab_columns 查询结果导出的 CSV 读入 db_df pd.read_csv(columns_info_export.csv) # 合并文档结构与实际库结构标记差异 merged pd.merge( doc_df, db_df, on[table_name, column_name], howleft, suffixes(_doc, _db), indicatorTrue ) # 找出实际库有、但文档里没有记录的字段 missing_in_doc merged[merged[_merge] right_only] print(f文档缺失字段 {missing_in_doc.shape[0]} 个)参数说明on指定关联键这里是表名加字段名howleft表示以文档为主suffixes用来区分两边类型indicatorTrue会自动生成_merge列right_only代表实际库有而文档里没记录。跑完之后把缺失字段单独存成Excel发给业务方确认新增字段口径。这比在Word里挨个CtrlF找差异快一个量级。4. 东华HIS表结构的核心模块拆解患者、医嘱、费用与库存把文档变成字典只是第一步真正要看懂东华HIS的表结构设计还是要回到业务链路。这一章我按交付文档里常见模块划分把高频使用的几组表拆开讲。重点不是让大家去抄表名而是理解为什么这样设计。不同版本的东华HIS表名会有差异但业务关系大致相同。4.1 患者主索引与就诊表一串业务号关联的根节点HIS里患者信息通常拆成患者主索引表和就诊表。患者主索引表存姓名、性别、出生日期、证件号、手机号等低频变化信息主键是患者内部号。就诊表存每次到院形成的一次就诊身份比如门诊就诊号、住院号外键指向患者主索引并带有就诊类型、就诊科室、入出区时间等字段。表结构文档里这类表一般放在模块前部字段命名规范主键容易识别。写查询时不要把就诊号直接当成患者主键去关联业务流水。一个患者可以反复来院就诊就诊号只代表某一次就诊。正确路线是先通过就诊表找到患者内部号再关联医嘱或费用表避免一个患者查出多条不相关记录。下面是常规写法的示意-- 先定位患者再通过患者主索引关联就诊 SELECT p.patient_name, v.visit_sn, v.visit_type, v.visit_dept FROM patient_index p JOIN visit_table v ON p.patient_id v.patient_id WHERE p.id_card_no 患者证件号;逻辑说明id_card_no是业务查询常用条件通过它先在患者主索引表定位到唯一的patient_id再关联就诊表得到该患者历次就诊记录。这里刻意没有直接把证件号放到就诊表的查询条件里因为证件号不一定冗余存储在每个就诊记录上直接关联反而可能漏掉历史数据。4.2 医嘱与费用明细枚举值要按文档对齐医嘱和费用明细是HIS里数据量最大、接口最敏感的部分。结构上医嘱表通常有医嘱编码、医嘱名称、开立医生、开立时间、停止时间、科室、状态费用明细或收费项目表按记账项逐条落库包含项目编码、数量、单价、金额、记账科室、发票号等列。这里最容易踩的坑是状态字段的枚举值不一致。同一条医嘱在业务界面显示“已停止”到库里可能存的是一个数字或字母代码。做统计前必须把文档备注里的枚举值整理成对照表再逐个核对SQL条件里的取值。如果文档没写枚举就去看后台字典表不要自己猜一个值。有些接口文档和表结构文档对同一枚举的写法还会冲突表结构里写“1-正常”接口文档里写“NORMAL”。遇到这种情况统一以后台字典表为准。这里可以运行一段SQL看枚举值的实际分布与文档确认-- 抽查状态字段真实取值验证枚举是否与文档一致 SELECT order_status, COUNT(*) AS cnt FROM order_base GROUP BY order_status ORDER BY cnt DESC;说明这段SQL不做什么复杂处理就是列出状态字段的所有不同值及其数量。如果结果里出现文档没有描述的取值说明线上数据有特殊情况需要去查字典表确认而不是闷着头写条件。4.3 药库批次、效期与供应商结算金额和数量的几个坑药库相关的表结构需要特别盯住三组字段批次号与批号、生产期与效期、供应商编码与供应商名称。批次代表一次入库的物理批效期是药品有效期表里往往日期类型和字符类型两种写法都有。按月统计效期时如果用字符串直接比较结果很可能会错。更隐蔽的问题是金额字段。药库入库单的金额字段可能拆成含税额、不含税额、税率三列中间有计算关系。统计供应商应付款时如果不把税率考虑进去月初对账就能差出一大截。处理这类表的常规做法是先从文档里摘出金额、数量相关字段写一条完整性校验SQL校验数量乘单价是否等于金额-- 校验入库单数量、单价、金额三者是否对得上 SELECT item_code, quantity, unit_price, amount, ROUND(quantity * unit_price, 2) AS calc_amount FROM drug_in_stock WHERE ABS(amount - ROUND(quantity * unit_price, 2)) 0.01;参数说明ROUND(quantity * unit_price, 2)把理论金额统一保留两位小数再用ABS判断与实存金额的差值是否超过一分钱。超过的金额记录单独拉出来给人核对。这条SQL建议在所有涉及金额的表上都跑一遍它比人工对账快得多尤其是在药库这类数据量大、批次多的场景。5. 东华HIS表结构使用避坑五条大量实践的踩坑记录这一章我把项目里反复遇到的五类问题写出来。每一条都按“现象、原因、解决”三步展开这些问题都不是原理多深而是文档使用姿势不对造成的踩过一次就不会忘。5.1 按文档字段名写SQL查不出结果大小写与空格在作怪现象按文档里的字段名写查询要么报“无效标识符”要么结果集为空但在数据库工具里手动看表结构明明能看到这一列。 原因Oracle和神通这类数据库里表名和字段名如果没有用双引号会自动转成大写。Word文档里的字段名可能带着首尾空格、全角空格或者被排版成大小写混合。复制字段名时很容易把不可见字符一起带进SQL编辑器。 解决先把文档里所有字段名做trim()并统一转大写再和user_tab_columns里的column_name比对。查询时不要手抄文档直接用系统字典导出的字段清单。不要在SQL里动用双引号强制大小写匹配生产环境通常约定统一大写双引号反而制造麻烦。5.2 字符字段里存了数字统计前没检查字段类型现象用sum(quantity)统计数量时直接报类型转换错误或者结果被截断。 原因表结构文档里该字段是VARCHAR2类型业务数据的内容全是数字。开发图省事直接sum数据库不认这种隐式转换。 解决对类型不信任的字段先查data_type和数据样例再写统计。如果必须对字符列聚合先用to_number做安全转换但要注意空值处理。更稳妥的办法是确认是否存在数值副本列或专门的数字字典表优先用数值列参与计算。5.3 默认值忽略导致插入失败NOT NULL字段没有值现象向业务表插入一条记录总是报“无法为NULL插入”但文档里这个字段明明没标NOT NULL。 原因文档与实际库不一致。线上版本的字段约束可能已被升级脚本改过或者该字段在文档里标了默认值但实际库没有加载默认值属性。 解决写数据前不要只信文档的可空性标记要查系统字典里的nullable和data_default。插入时尽量主动赋值而不是依赖缺省。建表脚本和同步脚本提交前先跑一段表约束巡检把nullable和data_default一并导出核对。5.4 金额字段类型不一致财务统计莫名多出几分钱现象对账时发现某个月份的金额总和比报表多出0.01元怎么排查都找不回。 原因同一业务里的金额字段部分用NUMBER(18,2)部分用NUMBER(14,2)字符类型存金额的情况也存在。跨表关联时浮点误差被放大或字符转数字产生四舍五入。 解决在字段基线表里把所有金额字段标出来统一按NUMBER(18,2)口径处理字符金额在关联前先做to_number(trim(...))。汇总查询统一用ROUND(SUM(...),2)避免数据库在中间结果里的精度扩展产生尾差。库存相关的单价建议用更高精度存储结算时再规整能把误差降到最低。5.5 多机构字段过滤缺失分院数据混在一起导致统计翻倍现象查询住院收入结果突然比上个月多出一倍核对后发现同一个患者出现在两个分院。 原因医院存在多院区或多科室体系表结构里有一个院区编码或机构号字段联表查询时漏加过滤条件或者选了全局汇总表而不是分院视图。 解决先看表结构文档里是否有院区、机构、组织这类标识字段有就把它写进所有涉及业务流水表的WHERE条件。开发环境也要保持该过滤条件不缺失不要依赖事后清洗。线上已经出现脏数据时先按患者主索引和就诊表去重再重新统计。安全的联表写法是第一版查询就把机构号带入不留到后端统一过滤。6. 把表结构文档用成日常工具Navicat导出结构与字段变更影响面检查文档读懂了坑也避开了最后要建立的是一个长效习惯把Word表结构文档当作变更管理的源头而不是一次性救命草。Navicat一类图形工具里多选表后右键选择“导出表结构”可以生成Excel或SQL格式的字段清单列里包含字段名、类型、长度、注释。如果数据库工具没有现成导出选项就走用户视图或information_schema查询把结果导出为表格效果一样。这个动作每次接手新系统都做一遍生成的就是一份“与交付文档可比的现场结构快照”。6.1 定期做“文档与库”结构比对形成版本痕迹我给自己定的习惯是每次版本升级后三天内用前面python脚本重新提取一次文档结构与dbstudio导出的现库结构做比对把新增字段、变更类型、失效表记为一次版本痕迹。医院系统的表结构变更往往不会提前通知下游这个习惯多次避免了报表口径崩塌。比对结果只保留差异行发给数据使用方同步联调口径。6.2 以“字段变更影响面”为锚做回归测试当发现线上表新增字段或修改类型时用字段名在整个项目代码里搜索凡出现该字段的地方都要纳入回归。搜索范围不止代码仓库还包括存储过程、接口定义、报表模板和ETL配置。这是表结构文档最有价值的一种用法它不只是开发时的字典更是变更影响分析的依据。每次结构变更都按这个清单回归一遍比等业务方报错再救火节省大量时间。6.3 把“字段基线表”变成团队共识最后说一个坚持了很多年的习惯无论项目大小接手第一天就建立字段基线表。基线表里保留字段状态、链接来源和变更记录三列。每次任何一方提出改表或改字段先在基线表里标记影响面再开始动代码。我的经验是HIS这类长生命周期系统的难点从来不是写SQL而是维护字段口径。文档会过期但基线表如果一直维护它就是你在这个项目里最可靠的后悔药。希望这篇东华HIS表结构新版.docx的使用笔记能帮你少熬夜、少翻车多留一点时间做有价值的设计。希望帮到你。本文还有配套的精品资源点击获取