简介东华HIS表结构新版.docx 是一份针对东华医院信息系统的数据库表结构说明文档适合医院信息化工程师、HIS二次开发与运维人员作为工具书使用。文档围绕医疗数据存储与业务流转展开系统梳理了CSP组件、用户信息、病人登记与就诊卡、病人基础信息、医嘱项目、账单信息等核心模块在表层面收录了用户信息表、病人登记信息表、就诊卡记录表、病人基本信息主表、诊断类型表、科室表、医院表、医生表、医嘱项目定义、医嘱子类/大类、账单组表等常用表并说明了各类表的字段用途与设计意图。针对医嘱部分还点出了医嘱项目、医嘱套与LIS外部代码的关系对理解HIS与LIS之间的数据交互很有帮助。资源包内共1个文件为docx格式压缩包整体约92KB体积虽小但内容丰富目录层级清晰。目前已有1670人浏览学习适合刚接触东华HIS的读者快速建立表结构整体认知也便于日常开发维护时速查参考。1. 东华HIS表结构新版文档是医院集成项目的第一张底牌去医院做数据对接最难的不是写代码而是搞清楚业务数据到底散落在哪几张表里。需求会上轻飘飘一句“门诊收入”“预交金余额”“在院病人数”落到数据库里往往要跨五六张表、关联十来个字段才能算准。这也是为什么开工前我会先找对方要一份「东华HIS表结构新版.docx」——它直接决定整个项目的排期、工作量和后续要踩多少坑。这份文档的价值不在“新”字上而在于它替你回答了集成项目里最要命的三个问题数据在哪张表、字段代表什么含义、表与表之间靠什么关联。适合三类人看给医院做接口对接的开发、帮科室写报表的工程师、以及做数据迁移和上报的实施人员。新手可以把它当字典按图索骥熟手则能从表结构反推出业务边界提前判断哪些数据拿不到、哪些统计对不齐。本文不打算复述文档内容而是讲清楚怎么把它变成能落地的查询方案以及那些只有动过真数据才会发现的坑。2. 先看模块再看字段东华HIS表结构文档的正确打开方式拿到一份几百页的表结构 docx最忌讳的做法是从第一页往后翻翻到一半就忘了前面。这份文档本质上是一张“数据库地图”读它的顺序应当是先看有哪些业务模块再看表名前缀和公共字段最后才去逐表研究字段清单。2.1 模块划分门诊、住院、药房、字典四张地图东华HIS这类医院信息系统的表结构几乎都是按业务域来组织的。我接触过的项目里文档无论排版怎么变核心模块都逃不开下面这四块我把它们整理成了一张对照表方便你在文档里按图索骥。业务模块常见表名前缀文档里常出现的表典型使用场景门诊OUTP / MZ挂号表、门诊收费表、处方表门诊收入统计、挂号量分析住院INP / ZY入院登记表、医嘱表、费用明细表预交金管理、住院费用汇总药房药库PHAR / YF库存表、发药表、盘点表药品消耗统计、库存对账基础字典DICT / BASE科室表、员工表、收费项目表、医保对照表数据翻译、科室归属、项目编码拿到文档先别急着看字段第一步是在目录或工作表标签里确认这个医院实际启用了哪些模块。不同医院上线范围不一样有的把药库单独拆了一套系统有的把检验检查结果放在独立的 LIS 表里这份 docx 里未必全有。你只需要关心你项目涉及的那几个模块其余先放一边。我一般会先在文档里搜索“收费”“医嘱”“预交金”“库存”这四个关键词把相关表页做个书签后面写 SQL 时能省大量翻找时间。2.2 公共字段与命名规律拿到任何一张新表先看这五类字段表结构文档里每张表动辄二三十个字段逐字段理解不现实。我的习惯是看任何一张业务表先找下面这五类字段它们基本决定了这张表能不能被安全地用到查询里。第一是患者标识类字段。常见的有患者主索引号、住院号、门诊就诊号注意这三者不是一回事住院号只在一次住院周期内唯一患者ID才能跨次关联同一个人的历史记录。第二是时间字段。注意区分业务时间挂号时间、收费时间和系统时间插入时间、最后修改时间增量抽取时只能用后者前者会被退费和补录弄乱。第三是状态字段。HIS 表里几乎都有个状态或标志位表示这笔记录是否有效、是否已结算、是否被冲正查询时漏掉它统计数据就会翻车。第四是金额字段。重点关注单位到底是元还是分同一个库里很可能两种单位并存。第五是关联字段。比如挂号流水号、发票号、处方号这些是表间 join 的钥匙文档里通常会标注是否索引。字段命名规律方面东华HIS的老版本喜欢用拼音缩写新版文档里不少字段改成了英文名但库里实际列名可能还是拼音。所以你在这份 docx 里看到的“Name/Code/Status”到线上库执行 SELECT 时可能要写成“XM/DM/ZT”。我建议在项目初期就做一张“文档字段名-库字段名”对照表后面写 SQL 时照着抄能少踩一半坑。3. 按业务场景找表门诊收费与住院费用的三组可复用SQL表结构文档不是用来读的是用来“反查”的。最有效的打开方式是从一个具体的业务问题出发倒着找表、找字段。这一章我用三个高频场景演示这个过程门诊收费流水怎么查、住院费用汇总怎么算、以及怎么把 docx 变成程序可读的字典文件。3.1 门诊收费流水从一次就诊到一张发票的查询链路业务场景是“统计某天上午的门诊收费金额”。按照表结构文档你至少要关联三张表挂号表获得就诊信息收费表获得金额和发票号患者表获得姓名。SQL 骨架是这样-- 查询 2024-01-15 上午的门诊收费流水 -- 注意表名/字段名以你手上的文档为准这里是通用结构 SELECT r.就诊流水号, p.患者姓名, r.科室名称, c.发票号, c.收费金额, c.收费时间 FROM 门诊挂号表 r JOIN 门诊收费表 c ON r.就诊流水号 c.就诊流水号 JOIN 患者主索引表 p ON r.患者ID p.患者ID WHERE c.收费时间 TO_DATE(2024-01-15 00:00:00, YYYY-MM-DD HH24:MI:SS) AND c.收费时间 TO_DATE(2024-01-15 12:00:00, YYYY-MM-DD HH24:MI:SS) AND c.记录状态 1; -- 1 表示有效0 表示已作废这段 SQL 的逻辑核心是用就诊流水号把挂号表和收费表串起来再用患者ID 补全患者信息。三个参数最值得关注第一个是时间范围用的是收费时间而不是挂号时间因为退费重收会导致挂号时间和收费时间不一致第二个是记录状态过滤很多 HIS 的作废发票并不会删除而是把状态位置为 0不过滤会把退掉的金额也算进收入第三个是 join 字段的选择千万不要拿发票号去 join 挂号表因为一次就诊可能开多张发票会出重复行。3.2 住院费用汇总预交金与欠费的减法逻辑住院场景比门诊复杂核心区别在于“预交金是反复发生的费用是每天累计的”。你要算一个患者当前欠费多少等于“累计费用 - 累计预交金 - 医保已结算金额”。这里最容易算错的是冲正记录。预交金的退回、费用的红冲在表里通常不是删除而是插入一条负数金额的新记录。所以汇总 SQL 里必须显式把正负都算进去-- 计算住院患者费用汇总包含冲正记录 -- 负金额记录表示退费/红冲不能直接排除 SELECT 住院号, SUM(费用金额) AS 总费用, -- 正负相抵后的净费用 SUM(CASE WHEN 费用金额 0 THEN 费用金额 ELSE 0 END) AS 正向费用, SUM(CASE WHEN 费用金额 0 THEN 费用金额 ELSE 0 END) AS 冲正金额 FROM 住院费用明细表 WHERE 费用日期 TO_DATE(2024-01-01, YYYY-MM-DD) GROUP BY 住院号;逻辑说明总费用是正负相加的净额这也是财务口径把正负拆成两列是为了对账时能看出这周退费了多少方便和人工台账核对。参数上要注意 GROUP BY 的粒度如果医院要求按科室统计就把科室编码加进分组如果只看在院患者还得 join 住院登记表过滤掉已出院记录。另外费用日期和记账日期也存在差异费用日期是业务发生日记账日期是系统入账日月底对账时一定要确认口径否则两边数字永远差两三天。3.3 把 docx 表结构变成可检索的数据字典python-docx 脚本表结构文档是 Word 表格手工找字段效率太低。我习惯拿到文档后先跑一个脚本把 docx 里所有表格抽取成 CSV再导入 Excel 或数据库做筛选。这里用 python-docx 库处理“东华HIS表结构新版.docx”# 读取 docx 中所有表格并导出为 CSV便于检索 import csv from docx import Document doc Document(东华HIS表结构新版.docx) out_path his_dict.csv with open(out_path, w, newline, encodingutf-8) as f: writer csv.writer(f) for table in doc.tables: # 遍历文档中的每个表格 for row in table.rows: # 遍历表格中的每一行 cells [cell.text.strip().replace(\n, ) for cell in row.cells] writer.writerow(cells) print(f已导出 {out_path}可打开检查表数量与字段行数)这段脚本的逻辑是把每个 Word 表格的每一行视为一条记录单元格里的换行符替换成空格避免 CSV 错列。两个参数值得调整一是 encoding 如果在 Windows 上用 Excel 打开乱码改成encodingutf-8-sig二是如果文档里除了表结构还有说明段落导出后按列内容筛选即可表结构行通常包含“字段名”“类型”“是否为空”等关键字。做完这一步后续查字段就变成在 CSV 里按关键词筛选而不是反复翻 Word效率能提升一大截。4. 从表结构到集成接口增量抽取与字段映射的落地写法看懂表结构只是第一步真正让这份文档产生价值的是把它变成对外提供数据的接口。集成项目的常见路径是把 HIS 数据抽取到中间库或数仓再对外提供查询。这里有两个绕不开的问题增量数据怎么抽才不重不漏字段怎么映射才不被业务方打回。4.1 增量抽取的第一选择统一时间戳字段加 ROWNUM 分页HIS 通常跑在 Oracle 上增量抽取最常见的方式是按“最后修改时间”拉取。这里有个关键点不要用业务发生时间做增量因为补录、退费、修改都会让历史记录的业务时间不变但内容变化。正确做法是用每条记录的“最后更新时间”字段加上分页防止一次拉太多把源库压垮。Oracle 分页的标准写法如下-- 增量抽取第 N 页数据每页 1000 条 -- :last_time 是上次抽取记录的最大修改时间 SELECT * FROM ( SELECT a.*, ROWNUM AS rn FROM ( SELECT * FROM 业务流水表 WHERE 最后修改时间 TO_DATE(:last_time, YYYY-MM-DD HH24:MI:SS) AND 最后修改时间 SYSDATE ORDER BY 最后修改时间, 主键 ) a WHERE ROWNUM :page * 1000 ) WHERE rn (:page - 1) * 1000;这段 SQL 的逻辑是三层的洋葱结构最内层按修改时间排序并过滤增量范围第二层用 ROWNUM 截断到当前页的末尾最外层筛掉前面页的数据。参数上三个点必须处理好一是:last_time要精确到秒而且要记录每次抽取的最大修改时间作为下次起点不能每次取当前时间否则秒级并发写入容易漏数据二是 ORDER BY 里除了时间还要加主键保证等值时间戳的数据排序稳定避免分页时重复或遗漏三是加 SYSDATE防止把正在写入的半截数据抽走。4.2 金额、日期、状态三类字段的映射规则字段映射是接口开发里最琐碎但最容易出事故的环节。我整理了三类高风险字段的处理经验供你建映射脚本时直接套用。字段类型HIS 原始形态目标库建议注意点金额NUMBER部分表单位为分部分为元统一转成元保留两位小数抽取时除以 100 还是乘以 100必须逐表核对文档注释日期DATE 类型含时分秒统一转成字符串或时间戳注意 Oracle 的 DATE 精确到秒没有毫秒别用毫秒级过滤状态CHAR 或 NUMBER1 有效 / 0 无效统一成布尔或状态码表同一含义在不同表里可能是 Y/N、1/0、A/I需建立对照金额单位这个坑我单独强调一下。东华HIS不同子系统的金额字段单位不统一是常态药品表可能存“分”收费汇总表可能存“元”而且文档里不一定写清楚。我踩过一次之后养成一个习惯每张表的金额字段都先在库里跑一条SELECT MAX(金额), MIN(金额), AVG(金额) FROM 表 WHERE 金额 0用数值量级反推单位。例如某张表平均金额数值小于 10基本可以判断是“元”的小额项目也可能是“分”的大额数值此时找两三笔真实业务的票据核对比看文档注释更快更准。5. 东华HIS表结构落地踩坑五个高频翻车点我把之前项目里因为表结构理解不到位导致的问题做了个汇总每一条都是先用错误口径算出结果、被业务方当场质疑后才定位到的。这五个点几乎每个 HIS 集成项目都会遇到提前知道能省掉大把返工时间。5.1 现象同一患者统计出多条住院记录病案数虚高原因住院号在 HIS 里是每次入院的唯一编号但同一个患者可能因为重复入院、转科换号等原因有多条住院记录。直接用住院号关联患者会把一次治疗拆成多人。解决统计人次用住院号分组统计人数必须用患者ID去重。在写需求文档阶段就把“人次”和“人数”这两个口径和业务方确认清楚SQL 里分别实现不要在同一个指标里混用。5.2 现象收费汇总金额比财务系统少差出来的都是退费原因HIS 的退费处理不是把原记录删除而是插入一条等额负数的红冲记录。如果抽取时只关注正数金额或者用DELETE思维理解退费就会把退掉的金额漏掉。解决汇总时保留正负金额绝对值之和与净额两个指标。涉及退费统计时用SUM(金额)得到净额用SUM(CASE WHEN 金额0 THEN 金额 END)得到毛额两者相减就是退费总额这个口径财务认可。5.3 现象金额字段算出来大得离谱小数点移错三位原因同一种业务字段在不同表里的单位不一致。费用明细表按“分”存储日报汇总表按“元”存储文档里没有显式标注单位。解决建映射脚本前先按表做金额量级探测。我通常跑一句SELECT MAX(金额) FROM 表结合业务常识判断住院总费用单笔几十万对应“元”如果是几千万则对应“分”。同时保留原始值字段对账发现问题时能回溯避免改了单位后无法定位原值。5.4 现象字段名在文档里是英文代码里是拼音接口总是查不到列原因新版文档更新了字段注释但线上库是老版本结构列名仍是拼音缩写或旧命名。文档和库结构不一致尤其在经历过升级但文档未同步的医院里最常见。解决进场第一天就用文档里的表名和线上数据字典做对比。Oracle 里查ALL_TAB_COLUMNS视图把文档表和线上表做外连接比较生成差异清单发给信息科确认。不要默认文档是对的也不要默认库是对的以实际业务查询结果为准。5.5 现象查询走了索引还是慢半小时跑不出结果原因HIS 核心表的关联字段虽然建了索引但抽取端经常把日期字段套上函数如TO_CHAR(时间,YYYY-MM-DD) 2024-01-15导致索引失效全表扫描。解决条件里保持字段原始类型用范围比较代替函数比较。例如时间 TO_DATE(2024-01-15,YYYY-MM-DD) AND 时间 TO_DATE(2024-01-16,YYYY-MM-DD)这样能命中索引。另外大批量抽取时错开 HIS 白天高并发期把增量任务安排在晚上十点后执行这条直接关系到源库的稳定性。6. 拿到文档后的第一周四件事把踩坑概率压到最低新项目拿到这份表结构文档不要急着写接口。我给自己定过一个规矩前三天只做验证和摸底不做任何开发。具体是四件事。第一件事是版本核对。把 docx 里的表名清单抽出来和线上数据库实际存在的表做一次全量比对。Oracle 里可以查DBA_TABLES或ALL_TABLES把不存在的表和多余的表列出来。这一步能发现文档与库不一致的全部风险点比后面逐字段踩坑效率高得多。第二件事是行数摸底。对每个要用的核心表跑SELECT COUNT(*)不需要精确估算即可。这一步是为了判断数据量级决定增量抽取的分页大小和同步频率。如果挂号表一天才几千条没必要用复杂的增量方案全量重抽反而更稳。第三件事是字典验证。HIS 的科室、收费项目、诊断编码这类字典表是翻译业务数据的根基。随机抽几个编码人工确认它对应的中文名称是否符合业务常识同时确认文档里标注的启停用字段是否真实生效。字典错了后面所有报表和接口都会错而且错得隐蔽。第四件事是烟囱验证。拿一个真实业务场景把文档里的主链路表全部走一遍。比如查“某个住院患者从入院到今天的所有费用明细”这条链路会经过患者表、住院表、费用表、字典表能跑通且结果合理才说明文档的基本可用性。如果连烟囱验证都卡住趁早找医院信息科确认表结构版本而不是继续往下开发。这四件事做完我对这份表结构文档的信任度心里才有底。这些年做医院数据项目我最大的教训是表结构文档一定存在滞后性但它仍然是整个项目最重要的起点。把它当成一张需要验证的地图而不是一锤定音的说明书所有集成工作就有了可靠的根基。希望这套从读文档到验证落地的方法能让你少走几趟我当年走过的弯路也祝你的 HIS 对接项目顺利上线。本文还有配套的精品资源点击获取