简介：这份文档是方正公司医院信息系统（CHIS5.0）的数据库表结构说明，面向医院信息化开发者、数据库管理员及医疗软件实施人员，用于理解系统底层数据模型、开展二次开发或数据对接。资源包共1个doc文件，约5.01MB，内容按业务模块组织，涵盖PUBLIC公共、GH挂号、MZ门诊、RT报表、WH维护、YP药品、ZY住院、YZ医嘱、XT系统、ZD字典十大模块，逐表列出字段定义与用途，如公共日报表、日报数据表等具体表项。文档结构清晰，便于按模块检索查阅，可作为数据库设计参考、接口开发依据或系统维护手册。目前已有130人学习下载，适合需要掌握CHIS数据架构、进行表结构梳理或系统集成的技术人员参考使用。
1. 一份 CHIS5.0 表结构文档，为什么值得数据库人翻一翻
手上拿到一份《方正公司医院信息系统数据库表结构.doc》，第一反应可能是“这不就是一份数据字典吗”。但真拆开看，它覆盖的是中国医院信息系统 CHIS5.0 的完整库表设计，从 PUBLIC 公共模块一路铺到 GH 挂号、MZ 门诊、YP 药品、ZY 住院、YZ 医嘱、XT 系统、ZD 字典，十个子系统、上百张表的字段级定义都在里面。对做医疗信息化、HIS 二次开发、数据迁移或接口对接的人来说，这不是科普材料，而是一份能直接对着建表、对着写 SQL、对着排查字段来源的底稿。它适合三类人：接手老 HIS 项目要快速摸清库结构的后端，做院内数据集成要理清业务表关系的实施，以及需要按 CHIS 表结构做兼容适配的开发者。下面按“这是什么 → 怎么用 → 坑在哪”的顺序，把这份文档拆成能落地的操作。
2. 先看懂 CHIS5.0 的模块划分与表命名规律
2.1 十个子系统前缀，决定了你该去哪张表找数据
CHIS5.0 的表名不是随便起的，前缀就是子系统缩写，这是整份文档最值钱的隐含信息。PUBLIC 下的表统一以a_开头，比如a_employee_mi（职工主索引）、a_hospital（医院属性表）、a_daily_report（公共日报表）；挂号模块用gh_，门诊用mz_，报表用rt_，维护用wh_，药品用yp_，住院用zy_，医嘱用yz_，系统用xt_，字典用zd_。知道这个规律，你拿到任何一个陌生表名，第一眼就能判断它属于哪个业务域，再去对应章节查字段，比全文搜索快得多。
命名里还有第二层语义。带_zd_的通常是字典表，比如gh_zd_clinic_type（号别字典）、gh_zd_window_no（挂号窗口号字典）、yp_zd_reajlicense（药品调价字典），这类表数据量小、变动少，是下拉框和枚举值的来源。带_mi的是主索引（master index），像a_employee_mi、mz_patient_mi、zy_patient_mi，存的是人或实体的唯一标识，是跨模块关联的锚点。带_detail或_detl的是明细表，gh_detail_charge（费用明细）、yp_in_detl（药品入库明细）、mz_detail_charge（门诊收费明细）都属于这一类，特点是行数多、跟主表一对多。带_config的是配置表，gh_config、mz_config、yp_configures控制各模块的行为开关。
把这三层规律记住，你面对一份几百张表的文档就不会迷路。实际排查问题时，先按业务域定位前缀，再按_zd_/_mi/_detail/_config判断表的角色，最后才去翻具体字段。这个顺序能省掉大量无效检索。
2.2 用文档反推建表语句：以挂号记录表为例
文档给的是字段清单，落地时通常要转成可执行的 DDL。常见做法是先把文档里每张表的字段名、类型、长度、是否可空、注释抄成结构化清单，再批量生成建表语句。以挂号模块的gh_record（挂号记录）为例，它关联病人、号别、医生、发票，是挂号业务的核心表。下面给一个按 CHIS 风格还原的建表示例，字段名和业务含义忠于文档，类型按医疗系统常见选型补全：
-- 挂号记录表：CHIS5.0 GH 模块核心表 CREATE TABLE gh_record ( record_id NUMBER(18) NOT NULL, -- 挂号记录主键 patient_id NUMBER(18) NOT NULL, -- 病人ID，关联 mz_patient_mi clinic_type VARCHAR2(10) NOT NULL, -- 号别代码，关联 gh_zd_clinic_type doctor_code VARCHAR2(20), -- 医生工号，关联 a_employee_mi dept_code VARCHAR2(10), -- 科室代码 request_no VARCHAR2(30), -- 号类编号，关联 gh_zd_request_type receipt_no VARCHAR2(30), -- 发票号，关联 gh_receipt reg_time DATE NOT NULL, -- 挂号时间 reg_status CHAR(1) DEFAULT '0', -- 状态：0正常 1退号 charge_amount NUMBER(12,2), -- 挂号费金额 operator VARCHAR2(20), -- 挂号员 CONSTRAINT pk_gh_record PRIMARY KEY (record_id) ); -- 挂号记录按病人和时间的高频查询索引 CREATE INDEX idx_gh_record_patient ON gh_record (patient_id, reg_time); CREATE INDEX idx_gh_record_receipt ON gh_record (receipt_no);这段 DDL 的逻辑说明：主键record_id用 NUMBER(18) 是 Oracle 系 HIS 的常见做法，兼容序列发生器；patient_id指向门诊病人主索引，是跨模块关联的关键外键；clinic_type、request_no分别指向号别字典和号类字典，保证号别可维护；receipt_no把挂号记录和发票绑定，退号时靠它回冲。参数上，reg_status用单字符枚举而不是布尔，是为了兼容老系统里可能出现的多状态扩展；金额字段统一 NUMBER(12,2)，避免浮点误差。
索引部分别照抄。idx_gh_record_patient服务于“查某病人所有挂号记录”和按时间范围统计；idx_gh_record_receipt服务于退号、对账时按发票号反查。如果你的库写入压力大，索引要按实际查询模式裁剪，不是越多越好。文档本身不提供索引定义，这部分得结合业务查询自己补，这也是很多人拿到表结构文档后最容易忽略的一步。
3. 把表结构文档变成可查询的数据字典
3.1 用维护模块的元数据表自举一份数据字典
CHIS5.0 有个很实用的设计：WH 维护模块里自带元数据表，wh_table_struc（库中表列表）、wh_field_struc（库中表字段结构信息）、wh_index_struc（库中表索引结构信息）三张表，本身就是描述整个库结构的。也就是说，系统运行起来后，你可以直接查这三张表拿到实时的表清单、字段清单和索引清单，比翻 doc 文档更准，因为文档可能和实际库有版本差。
常见做法是写一条查询，把某张业务表的字段结构拉出来核对：
-- 从维护模块元数据表反查指定表的字段结构 SELECT t.table_name, -- 表名 f.field_name, -- 字段名 f.field_type, -- 字段类型 f.field_len, -- 字段长度 f.field_dec, -- 小数位 f.nullable, -- 是否可空 f.comments -- 字段注释 FROM wh_table_struc t JOIN wh_field_struc f ON f.table_name = t.table_name WHERE t.table_name = 'GH_RECORD' ORDER BY f.field_order;逻辑说明：wh_table_struc提供表级清单，wh_field_struc提供字段级明细，两者用table_name关联。field_order保证字段按物理顺序输出，方便和文档逐行比对。参数上，把WHERE里的表名换成你要核对的任意表即可。这条查询的价值在于：文档是静态的，元数据表是动态的，当文档和实际库对不上时，以元数据表为准，再用文档理解业务含义。
3.2 跨模块关联：从挂号到门诊到药品的字段链路
CHIS 各模块不是孤立的，表之间靠主索引和单据号串联。理清几条主链路，做数据集成时就不会断链。挂号到门诊：gh_record.patient_id→mz_patient_mi.patient_id，病人主索引是同一套；门诊到收费：mz_visit_table（就诊记录）→mz_receipt（发票）→mz_receipt_charge（发票明细）→mz_detail_charge（收费明细），一条就诊对应一张或多张发票，发票下挂明细；门诊到药品：处方经mz_dg_orders（诊断处方模板）和mz_dg_record（诊断处方记录）落到药品出库yp_out_patient（药品病人出库明细）。
下面这条查询演示从挂号记录一路关联到病人主索引和号别字典，是排查“某条挂号为什么查不到病人”时的常用手段：
-- 挂号记录关联病人主索引与号别字典 SELECT r.record_id, r.reg_time, p.patient_name, -- 病人姓名，来自主索引 p.id_card, -- 证件号 c.clinic_name, -- 号别名称，来自字典 r.charge_amount FROM gh_record r LEFT JOIN mz_patient_mi p ON p.patient_id = r.patient_id LEFT JOIN gh_zd_clinic_type c ON c.clinic_code = r.clinic_type WHERE r.reg_time >= TRUNC(SYSDATE) -- 只看今天 ORDER BY r.reg_time DESC;逻辑说明：用 LEFT JOIN 而不是 INNER JOIN，是为了在病人主索引缺失时仍能查出挂号记录，方便定位脏数据。TRUNC(SYSDATE)取当天零点，是 Oracle 里按天过滤的常规写法。参数上，clinic_code和clinic_type的对应关系要以gh_zd_clinic_type的实际字段为准，文档里字典表字段可能因版本略有差异，跑之前先DESC一下确认。
提示：跨模块关联前，先确认两边的主索引是不是同一套。CHIS 里门诊病人主索引是
mz_patient_mi，住院是zy_patient_mi，两者可能通过a_patient_mi统一，也可能各自独立，取决于部署版本。文档里zy_patient_mi被标注为“住院病人主索引”，和门诊主索引是否合并，要以实际库为准。
4. 避坑与排查：表结构文档落地时的五个常见问题
4.1 文档字段和实际库对不上
现象：按文档字段名写 SQL，报“无效标识符”。原因：doc 文档是某个时点的快照，实际部署的 CHIS 可能打过补丁，字段增删或改名。解决：以wh_field_struc为准，先跑 3.1 的查询核对字段清单，再改 SQL。养成“文档看业务含义、元数据表看物理结构”的习惯。
4.2 字典表代码含义不明
现象：gh_zd_clinic_type里clinic_code是数字，不知道对应什么号别。原因：文档只给表结构，不给字典数据。解决：直接SELECT * FROM gh_zd_clinic_type看数据，字典表的代码和名称通常在同一张表里成对出现。别去猜代码含义，查数据最快。
4.3 明细表数据量爆炸导致查询慢
现象：查mz_detail_charge或yp_in_detl全表扫描，几分钟不出结果。原因：明细表是全院级流水，行数动辄千万。解决：所有查询必须带时间范围或单据号，禁止无WHERE的全表扫描；确认receipt_no、patient_id、charge_time等字段上有索引，没有就按查询模式补。
4.4 退费退号后数据对不上
现象：发票表有记录，明细表却是空的，或者金额对不平。原因：CHIS 的退费走的是反向单据，mz_detail_charge_back（门诊退费明细表）和正向明细分开存，只查正向表会漏掉退费。解决：对账时正向表和退费表一起查，用单据号关联，净额才是真实收费。
4.5 直接改生产库表结构
现象：为了加个字段直接ALTER TABLE，结果触发系统异常。原因：CHIS 的维护模块wh_table_struc、wh_field_struc缓存了库结构，物理改表但没同步元数据，系统读到的还是旧结构。解决：任何表结构变更走维护模块的字典维护流程，或改完后同步刷新元数据表，别绕过系统直接动 DDL。
5. 进阶：用表结构文档做一次数据血缘梳理
把这份文档用透的最后一招，是拿它做数据血缘。CHIS 里一张报表的数字，往往要穿过四五个模块的表才能追到源头。以“门诊日报”为例，a_daily_report（公共日报表）和a_daily_report_data（日报数据表）是结果，往上追是mz_receipt（发票）和mz_receipt_charge（发票明细），再往上追是mz_detail_charge（收费明细），明细里的收费项目又来自mz_bill_item（帐单码）和zy_audit_item（收费项目分类字典）。把这条链路画清楚，日报数字对不上时就知道该从哪一层查起。
具体做法是建一张血缘对照表，把“目标字段 → 中间表 → 源表 → 源字段”四列填满。下面给一个片段示例：
| 目标字段 | 中间表 | 源表 | 源字段 |
|---|---|---|---|
| 日报收费总额 | a_daily_report_data | mz_receipt | total_amount |
| 发票明细金额 | mz_receipt_charge | mz_detail_charge | charge_amount |
| 收费项目名称 | mz_detail_charge | mz_bill_item | item_name |
| 挂号量 | a_daily_report_data | gh_record | record_id（计数） |
| 药品出库量 | yp_report | yp_out_patient | out_qty |
填这张表的过程，就是逼自己把文档里散落的表按业务流串起来。串完之后，任何一张报表的数字异常，你都能顺着链路逐层核对，而不是对着结果干瞪眼。我一般会先把 PUBLIC、GH、MZ、YP 四个高频模块的血缘填完，这四个覆盖了门诊业务八成以上的数据流，剩下的 RT、WH、ZY、YZ 按需补。
验证血缘对不对，有个笨但有效的办法：拿一个已知正确的小样本，比如某一天某位病人的完整就诊记录，从挂号gh_record开始，一路查到收费mz_detail_charge和药品yp_out_patient，看每一跳的关联字段是否都能对上、金额是否一致。对不上就说明血缘表里某一跳的关联字段写错了。这个验证我每次接手新库都会走一遍，翻车过两次之后就成了固定动作——第一次是漏了退费表导致金额虚高，第二次是把门诊和住院的主索引混用导致病人串号。从那以后我每次梳理血缘，都强制先跑一遍小样本端到端核对，确认链路通了再铺开。希望这份拆解帮到你，把这份 CHIS5.0 表结构文档真正用起来。
本文还有配套的精品资源，点击获取
