企业官网建设流程全解析

简介：《天健医院信息系统数据结构手册》是一份面向HIS系统开发、实施与运维工程师的数据库结构说明文档，系统梳理了天健医疗HIS系统后台表结构设计，让不熟悉底层数据的人员能快速定位字典表、业务表并理解其关联关系。文档从公共字典、人员属性、国家地区单位、科室字典等模块切入，覆盖性别、婚姻、民族、血型、职业、身份、费别、病人来源等常用字典，以及工作人员、用户、技术职务、科室配置、病房对照等核心业务表，便于开展数据查询、接口开发与统计分析。资源以单个doc文档形式打包，大小约7.19MB，已获得852人学习下载。内容还包含版本更新记录与目录结构，红蓝黑字标识表及字段使用状态，适合需要深入掌握天健HIS数据模型的工程师作为随查手册使用。

1. 天健HIS的数据库黑匣子：这份数据结构手册先救急

医院信息系统（HIS）最怕的不是代码跑不通，而是数据库里那几百张表没人讲得清。天健HIS的数据结构手册，正是当初做这套系统的人留下的黑匣子说明书——它把从挂号、医嘱、药房、检查检验到费用结算的全部表结构按业务模块拆开列全，每张表是“在用、未用还是新增”都用颜色标在目录里。我接过一个老系统的报表任务时，就靠它两小时定位到对的表，没让业务部门干等。适合刚接手HIS维护的工程师、做接口对接的二次开发，以及被数据问题找上门的分析岗。这份文档值得下载一份放进团队知识库。

2. 先读目录骨架：十七个模块、三色标识与表命名规律

拿到手册别急着翻字段。目录本身就是一张“数据地图”——它按业务模块把全部表分组，同时还标着每张表的使用状态。先把目录读透，后面查表能省一半时间。

2.1 十七个模块是怎么分的

手册把全部表分成十七个大目录：公共部分、人员属性、国家地区单位、医疗工作、疾病诊断与医疗操作、药品物资、费用、系统维护、输入法、病案、门诊病人、门诊医生、住院病人、医嘱、检查、检验、药品管理、门诊收费。这个顺序不是随手排的，它对应HIS的数据产生顺序：先有基础档案（人员、科室、药品、价表），再有业务单据（挂号、医嘱、处方、检查申请），最后才是结算与统计。

公共目录里放的是一批没有业务归属的纯字典表，比如性别字典（SEX_DICT）、血型字典（BLOOD_TYPE_DICT）、职业分类字典（OCCUPATION_DICT）、身份字典（IDENTITY_DICT）、费别字典（CHARGE_TYPE_DICT）。这些表被门诊、住院、收费、病案多个模块共同引用，单独放在开头就是为了让读者先建立“共同引用”的概念。性别这类字段在业务表里大多只存代码，具体含义要关联字典表才能翻译成人话。

人员属性模块则围绕“工作人员”做文章：工作人员字典（STAFF_DICT）、技术职务字典（TITLE_DICT）、工作类别字典（JOB_CLASS_DICT）、医生职务字典（DOCTOR_TITLE_DICT），还有工作人员分组（STAFF_GROUP_VS_STAFF_VS_GROUP）。这里需要注意的是STAFF_DICT是面向全院人员的，医生、护士、技师、收费员都在里面，查“谁是某科室的医生”要配合科室字典和分组表做过滤。

科室类的表单独成组：科室字典（DEPT_DICT）、临床科室配置（CLINICAL_DEPT_CONFIG）、科室与病房对照（DEPT_VS_WARD）、科室门诊住院属性（DEPT_OI_ATTR_DICT）。DEPT_DICT是全院科室的静态档案，但一个科室是门诊还是住院、是临床还是医技，不直接写在科室字典里，而是拆在属性字典和对照表里。这是老HIS常见的“主档+属性拆表”做法，目录里能看得很清楚。

药品物资模块更典型：药品字典（DRUG_DICT）、药品名称字典（DRUG_NAME_DICT）、药品价格（DRUG_PRICE_LIST）、药品供应商、剂型、类别、计量单位等十几个字典表围着一个“药品”转。读目录时你会发现，药品的“基本档案、名称、价格、类别”被拆成了多张表，这是老系统为了复用和标准化做的拆分——同一种药在不同供应商下可以有不同编码，名称字典解决一药多名，价格表单独维护才能支持调价。理解这个拆法，后面写药品查询才不会被表名绕晕。

2.2 红蓝黑三色：哪些表能用，哪些表别碰

手册的目录和正文里，表名会带颜色，这个细节比字段说明还重要。

我在实际接手时吃过亏：按手册找到一个叫用户记录（USERS）的表，以为能查出系统登录账号，结果整表是空的。回头看目录才注意到这表名字后面标着“不使用”。手册里还有一批类似标注，比如检查号类别、诊室字典、门诊医生检查主记录等，要么标“不使用”，要么标“针对某医院定制”。这种表不是设计缺陷，是历史遗留——版本迭代后功能被替换了，表没人清就一直留着。

遇到红字表，正确动作是跳过；遇到蓝字表，要把它当作新接口的一部分去理解。蓝字表往往对应某次版本升级新增的功能，比如新增的家庭信息表（FAMILY_DICT）、合理用药相关表、医疗卡门诊就医系统配置表（MEDCARD_CONFIG），这类表在老的业务链路里没有位置，但新版本的数据会写进去，联调时少考虑它们就会漏数据。

提示：读任何一张表之前，先确认它在目录里是什么颜色。黑字表查得放心，蓝字表要确认线上版本是否落数，红字表直接不接。

2.3 后缀里的命名密码：DICT、MASTER、DETAIL、T

手册里几百张表，名字不是乱取的。把常见的后缀搞清楚，看到表名大致能猜到它的角色。

以DICT结尾的是字典表，例如SEX_DICT、NATION_DICT、DEPT_DICT。这类表行数少、含义稳定，存的是“代码+名称+排序+有效标志”，用途是给下拉框和翻译字段做参照。

以MASTER结尾的是主记录表，例如CLINIC_MASTER（就诊记录主表）、EXAM_MASTER（检查主记录）、LAB_TEST_MASTER（检验主记录）、DRUG_PRESC_MASTER（处方主记录）。一笔业务过程产生一条主记录，里面存业务编号、发生时间、操作人和归属病人。

以DETAIL结尾的是明细表，例如DRUG_IMPORT_DETAIL（入库明细）、DRUG_PRESC_DETAIL（处方明细）、OUTP_PRESC（处方明细记录，这个没带DETAIL后缀但要按明细对待）。明细表挂在主表下面，一条主记录对应多行明细。

以T结尾的是临时表，例如OUTP_ORDERS_T、OUTP_PRESC_T、DRUG_PRESC_MASTER_T。这类表在手册正文里也叫“队列”表，作用是暂存未落库的待处理单据。门诊医生站录入处方后，数据先写进T表，收费确认后才转到正式表。查“已收费数据”时不要碰T表，否则会把未完成的草稿单统计进去。

还有一类以LOG结尾的日志表，比如ADT_LOG（入出转日志）、PMI_MERGED_LOG（主索引合并日志）、DRUG_STOP_LOG（药品停用日志）。日志表只增不改，适合做审计追溯。手册里日志表常被新手忽略，但排查“数据为什么变了”时它是唯一线索。

命名规律不是绝对严格，比如“检查项目记录EXAM_ITEMS”就没有后缀，但它实际是EXAM_MASTER的子表。所以正确用法是：先用后缀猜方向，再翻开手册确认它的分组和用途，不要只凭名字下结论。目录先读到这里，下面挑几张业务核心表，把字段和关联关系说透。

3. 核心表的读法：主索引、医嘱、药品、价表的字段与关联

手册里最值钱的部分不在目录，而在每张表的字段明细。系统维护模块里专门有“表字段解释说明”（TABLE_COLUMNS_SET）和“表角色解释说明”（TABLE_ROLE_SET）两张元数据表，可见原设计者对字段语义的重视。实际工作中不需要把几百张表全部背下来，抓住几张核心主表，业务链路就通了一半。

3.1 PAT_MASTER_INDEX：全院的病人主索引

手册第9章“病案”第一张表就是病人主索引PAT_MASTER_INDEX。这张表是全院的病人自然信息档案，一个病人一行，以PATIENT_ID为主键，存姓名、性别、出生日期、证件号、地址、联系电话等。注意它不存“第几次住院”，那是PAT_VISIT的事——PAT_VISIT按每次住院或就诊一行，外键挂PATIENT_ID。

为什么要把“某个人”和“某次就诊”分开？因为一个病人可能来院几十次，如果把所有就诊信息堆在同一行，表会变得又宽又难维护。拆开后，主索引只维护自然人属性，PAT_VISIT按visit_id记录每一次入院时间、入院方式、入院科室、出院时间、出院方式。查询时两表join即可。

SELECT p.patient_id, p.name, p.sex, p.birth_date, v.visit_id, v.admission_date, v.discharge_date FROM PAT_MASTER_INDEX p JOIN PAT_VISIT v ON p.patient_id = v.patient_id WHERE p.patient_id = :pat_id ORDER BY v.admission_date DESC;

这段查询先取病人自然信息，再取历次住院就诊记录。:pat_id是病人主索引ID，通常由就诊卡号或住院号反查得到。visit_id是单次就诊的唯一编号，同一PATIENT_ID下会有多个VISIT_ID，所以ORDER BY admission_date按时间倒序，取最新一次就诊就在外面套一层ROWNUM或者LIMIT。

主索引还有一个容易忽略的点：手册里专门列了主索引合并记录（PMI_MERGED_LOG）和修改姓名记录表。说明同一病人在历史数据里可能被建了两个主索引，后来通过合并日志做了关联。查全病史数据时不能只按PATIENT_ID过滤，还要看合并日志，否则分段病历就断开了。这个坑后面排查章节再细说。

3.2 ORDERS 与 ORDERS_COSTS：医嘱和计价拆分

医嘱表ORDERS是整个住院业务的核心。手册第13章把医嘱放在独立章节，原因很简单：医嘱驱动了住院的护士执行、药房发药、检查检验申请、费用记账。ORDERS表一条医嘱一行，关键字段是ORDER_NO（医嘱号）、PATIENT_ID、VISIT_ID、ORDER_CLASS（医嘱类别）、ORDER_TEXT（医嘱描述）、ORDER_STATUS（状态）、开始时间与停止时间。

为什么要单拆一张医嘱计价项目表ORDERS_COSTS？因为一条医嘱对应多个收费项目。最典型的场景是“静脉输液”这条医嘱，可能拆成药品费、输液器费、注射费三个计价项目。如果把这些塞进ORDERS表的字段里，设计上非常笨拙，所以拆一张子表，一条医嘱多行计价明细。

SELECT o.order_no, o.order_text, o.order_status, c.item_name, c.quantity, c.costs FROM ORDERS o LEFT JOIN ORDERS_COSTS c ON o.order_no = c.order_no AND o.patient_id = c.patient_id WHERE o.patient_id = :pat_id AND o.visit_id = :visit_id ORDER BY o.order_no;

ORDER_NO是医嘱号，理想情况下全院唯一，但老系统里存在不同患者号段重复的可能，所以关联时带上PATIENT_ID更稳妥。ORDER_STATUS是排查漏费的关键字段：新开立、作废、停止、执行中、已执行，统计费用时必须过滤掉作废和停止状态的医嘱。用LEFT JOIN而不是INNER JOIN，是为了把所有医嘱都列出来，即使它还没有计价明细，方便核对“有医嘱没收费”的异常数据。

3.3 药品相关：DRUG_DICT 到 DRUG_STOCK 的三层结构

药品相关表在手册里占了整整一章。理解药品数据，关键看三个层次：档案层、库存层、价格层。档案层以药品字典DRUG_DICT为主，存药品编码、通用名、商品名、剂型、规格、毒理分类、处方属性；药品信息DRUG_INFO是扩展属性；库存层是DRUG_STOCK，记录每个库房某药品的当前数量、批号、效期、货位；价格层则是DRUG_PRICE_LIST药品价格表。

手册里药品库存定义表DRUG_STORAGE_PROFILE、库存表DRUG_STOCK、盘点表DRUG_INVENTORY_CHECK放在一起，说明库存管理是围绕“库房+药品+批号”三个维度展开的。写库存查询时，最常见的错误是漏掉STORAGE_DEPT字段，导致同一药品在住院药房、门诊药房、急诊药房的多行记录被重复加总。

SELECT d.drug_name, s.storage_dept, s.quantity, s.batch_no FROM DRUG_STOCK s JOIN DRUG_DICT d ON s.drug_code = d.drug_code WHERE d.drug_name LIKE '%阿莫西林%' ORDER BY s.quantity DESC;

这个查询按药品名称模糊匹配，返回它在所有库房的库存行。注意结果里同一药品可能有多行，因为DRUG_STOCK的粒度是“药品+库房+批号”，同一批药分放在不同货位就是多行。如果需要某个药的全院总库存，要在STORAGE_DEPT上做聚合，不能简单取第一行。批号BATCH_NO字段对效期管理和召回追踪很重要，做药品追溯报表时它是最佳维度。

3.4 价表：PRICE_LIST 与 CURRENT_PRICE_LIST

价表和医嘱计价的关系很密切，但很多人会被两张价表搞晕。手册费用章节里同时列了价表PRICE_LIST和当前价表CURRENT_PRICE_LIST，看上去像重复设计，实际用途完全不同：PRICE_LIST是价表项目的主档案，包含项目编码、名称、单位、价格、收费分类，同时保留历史调价记录；CURRENT_PRICE_LIST只存当前生效的价格，是查询计费时要用的视图。

为什么拆两张？因为医院调价不能覆盖历史。医保结算、退费、日结清单都要按发生当天的价格算，如果直接改PRICE_LIST，历史账单全错。CURRENT_PRICE_LIST可以看成一张“当前有效价”的镜像表，每天有调价任务时刷新它，业务前台一律走它，后台PRICE_LIST留着全量审计数据。

SELECT c.item_code, c.item_name, c.units, c.price, c.charge_class FROM CURRENT_PRICE_LIST c WHERE c.item_code = :item_code AND c.start_date <= :billing_date AND (c.end_date IS NULL OR c.end_date >= :billing_date);

:billing_date是记账日期，用来判断该价格在当天是否有效。CURRENT_PRICE_LIST虽然叫当前价，但设计上仍保留起止日期段，保险起见查询时还是加上时间过滤。CHARGE_CLASS是收费分类，这个字段在病案首页费用分类、门诊收据费用分类里都有对应关系，统计报表时常按它分组。如果发现统计价格和收费对不上，去PRICE_LIST查调价历史，而不是怀疑CURRENT_PRICE_LIST算错。

4. 常见问题排查：五个真实踩坑与定位思路

老系统手册最实用的部分是它帮人避开“看着像、用不对”的陷阱。下面五条都是我在实际翻库时踩过或见别人踩过的坑，每一条都能在手册对应目录里找到线索。

坑一：以为USERS表能查到登录账号，结果整表是空的。

现象：开发一个账号管理页面，按手册找到用户记录USERS，查出来0行，接口联调无从下手。

原因：手册里USERS表名后面明确标了“不使用”。这套系统的用户账号体系用的是系统维护章节里的SECURITY_USERS、SECURITY_GROUPINGS等表，USERS是老版本遗留物，设计者没有删除它，只是不再写入。

解决：翻到第7章“系统维护”，看SECURITY_USERS和APP_GRANTS两张表。SECURITY_USERS存账号和密码摘要，APP_GRANTS存应用权限点。以后再遇到手册里带“不使用”标注的表，直接跳过，别在上面浪费时间。

坑二：药品库存汇总对不上实物账。

现象：统计全院药品库存，把DRUG_STOCK所有行的quantity加起来，和药房手工盘点数差了十几条记录。

原因：DRUG_STOCK的粒度是“药品+库房+货位+批号”，同一药品在门诊药房和住院药房各有一行，甚至在同一个药房不同货位也有多行。直接加总没有按库房过滤，把全院数据混在一起。

解决：先看手册里药品库存定义DRUG_STORAGE_PROFILE，建立“库房维度”概念。查某个药房的库存时，WHERE条件加storage_dept；做全院汇总时，应该GROUP BY drug_code再SUM，而不是把所有行加起来。盘点时还要结合DRUG_STOCK_BALANCE药品结转记录，那个表才是库房结存的权威依据。

坑三：用PRICE_LIST取价统计费用，结果每月报数抖个不停。

现象：做门诊收入月报，直接关联PRICE_LIST取price字段，上个月和这个月金额差异很大，但业务量没明显变化。

原因：PRICE_LIST是历史价表，里面有多次调价记录。同一收费项目在不同时间段有不同价格，直接用最新一条会错，用最早一条更错。手册里单独设计CURRENT_PRICE_LIST就是为了解决这个查询场景。

解决：月报取价一律走CURRENT_PRICE_LIST，并且配合起止日期过滤。需要回溯某个月的收入时，应该用收费流水表OUTP_RCPT_MASTER里记录的收费金额，而不是拿今天的价格去乘数量。记住一个原则：账单金额以发生时的记录为准，价表只是参考。

坑四：把T表当正式表统计，门诊量多了一大截。

现象：统计某天的门诊处方量，关联OUTP_PRESC查出5000张，但收费系统显示只有3500笔。

原因：OUTP_PRESC_T是临时队列表，门诊医生站的处方先写进T表，收费确认后才转正式表。医生开完处方还没缴费，数据就留在T表里。这类临时表在手册里以_T结尾，目录里也能看到成组医嘱模板、待发药处方主记录等类似设计。

解决：统计口径先问清楚是“已收费处方”还是“医生开立处方”。前者只查正式表OUTP_PRESC和OUTP_RCPT_MASTER，后者才把T表加进来。上游系统和HIS对接时，如果下游要的是“已缴费数据”，SQL里必须排除T表，否则处方量永远比实际收费量高。

坑五：病人主索引合并后，按原ID查不到全部历史数据。

现象：某病人在2005年和2008年各住过一次院，按其中一个PATIENT_ID查就诊记录，只查到部分病历。

原因：病人两次住院被系统建了两个主索引，后来人工合并成一条，合并关系记录在PMI_MERGED_LOG里。老HIS这种“先建后并”的情况不少，尤其早期没有身份证校验的时候。

解决：查询历史前先检查PMI_MERGED_LOG，看当前PATIENT_ID是否有合并来源记录。手册里专门列了主索引合并记录表，设计上就是为了支持这种反向追溯。稳妥的做法是在自己的数据集市里建一张病人ID映射表，把合并前后的ID全量对应起来，后续所有关联都走映射表。

提示：碰到“数据对不上”，先回手册目录看表名后面的颜色和标注，再想业务逻辑。大多数翻车都是因为没确认表的使用状态和粒度。

5. 把数据流串起来：从挂号、医嘱到发药的联表查询

单看表结构看不出系统怎么运转。把核心表连起来，一条业务链路才能走通。这里按门诊、住院医嘱、检验、药品四条链路给四组联表SQL，都是可以直接改参数跑通的模板。

5.1 门诊链路：从挂号到处方

门诊的起点是号表和就诊记录。CLINIC_FOR_REGIST是门诊号表，存当天放出的号，CLINIC_MASTER是就诊记录，病人进诊室后生成一条。医生开方后，处方主记录和明细分别写入处方表和处方明细表。门诊收费完成后，费用落到OUTP_RCPT_MASTER。

SELECT c.visit_date, c.clinic_no, p.order_text, p.quantity, p.dosage FROM CLINIC_MASTER c LEFT JOIN OUTP_PRESC p ON c.patient_id = p.patient_id AND c.clinic_no = p.clinic_no WHERE c.patient_id = :pat_id AND c.visit_date BETWEEN :start_date AND :end_date;

:start_date和:end_date限定就诊日期范围，取当天数据就都填同一天。clinic_no是本次就诊号，在门诊流程里是核心关联键，从CLINIC_MASTER到OUTP_PRESC都带它。LEFT JOIN保证即使医生开了病历但没开药，也能把就诊记录查出来。需要看收费情况时，再用CLINIC_MASTER关联OUTP_RCPT_MASTER，注意一个就诊号可能对应多张收据（比如先开药后加检查）。

5.2 医嘱链路：从开立到执行到计价

住院医嘱链路是ORDERS（开立）→ORDERS_EXECUTE（执行）→ORDERS_COSTS（计价）。护士站核对医嘱后生成执行记录，执行记录带执行时间、执行人。同时系统按医嘱内容拆分计价项目写入ORDERS_COSTS。

SELECT o.order_text, e.execute_time, e.exec_doctor, c.item_name, c.quantity, c.costs FROM ORDERS o LEFT JOIN ORDERS_EXECUTE e ON o.order_no = e.order_no LEFT JOIN ORDERS_COSTS c ON o.order_no = c.order_no WHERE o.patient_id = :pat_id AND o.visit_id = :visit_id AND e.execute_date = :exec_date;

注意exec_doctor存的是工作人员代码，要显示姓名还需关联STAFF_DICT。execute_date如果传日期，记得确认ORACLE里该字段是DATE还是VARCHAR2，老库常把日期存成字符串，查询时要用TO_DATE转换或者直接传字符串比较，否则索引失效全表扫。医嘱状态过滤放在外面一层：查费用对账时只保留已执行和已停止的医嘱，新开立的不要算进去。

5.3 检验链路：从申请到结果

检验模块的表结构分层很清楚：LAB_TEST_MASTER是检验主记录（一条申请单），LAB_TEST_ITEMS是检验项目（申请了哪几个化验项），LAB_RESULT是结果明细（每个项目对应的数值、单位、异常标记）。

SELECT m.test_no, m.speciman, i.item_name, i.item_no, r.result_value, r.units, r.abnormal_indicator FROM LAB_TEST_MASTER m JOIN LAB_TEST_ITEMS i ON m.test_no = i.test_no LEFT JOIN LAB_RESULT r ON i.test_no = r.test_no AND i.item_no = r.item_no WHERE m.patient_id = :pat_id AND m.test_date BETWEEN :start_date AND :end_date;

test_no是检验申请号，一个申请对应一个标本，所以标本字段SPECIMAN放在主记录上。item_no是项目序号，同一个申请下多个检验项目靠它区分。abnormal_indicator是异常标志，查“有哪些结果异常”时直接用它过滤，比自己在SQL里写参考区间判断靠谱得多。手册里还有一条检验结果描述与结果值对照表LAB_RESULT_TYPE_VS_VALUES，专门处理“阳性/阴性”这类文字结果，数值型和文本型结果在这里分叉。

5.4 药品链路：从处方到发药到库存扣减

药品发药链路从DRUG_PRESC_MASTER（处方主记录）开始，到DRUG_PRESC_DETAIL（处方明细），再到DRUG_DISPENSE_REC（摆药记录），最后影响DRUG_STOCK（库存）。住院患者用药通常先有医嘱，由药房生成摆药单，护士核对后执行。

SELECT d.drug_code, d.drug_name, d.quantity AS presc_qty, r.dispense_time, s.quantity AS stock_qty FROM DRUG_PRESC_DETAIL d LEFT JOIN DRUG_DISPENSE_REC r ON d.presc_no = r.presc_no LEFT JOIN DRUG_STOCK s ON d.drug_code = s.drug_code AND s.storage_dept = :dept_code WHERE d.presc_no = :presc_no;

:dept_code是发药库房代码，必须和处方的发药药房一致，否则库存行关联错位。presc_qty是处方数量，stock_qty是关联库存表的现存量。如果发现处方数量大于库存数量，先核对是不是关联错了库房，再查DRUG_STOCK_BALANCE药品结转表看这个库房的期初数、入库数、出库数流水。手册里药品管理章节还有药品调价记录DRUG_PRICE_MODIFY和调价盈亏表DRUG_PRICE_MODIFY_PROFIT，药品对账对不上时，这些表能看出是调价差还是损耗差。

四条链路走通后，再回看手册会有一种“地图对上实景”的感觉。先有主索引和字典，再有业务单据，最后落到费用和库存，HIS的数据流本质就是“档案→事件→记账”三层。

6. 把手册变成可检索元数据：一次提取终身复用

手册是Word表格和目录文本，几百张表名靠肉眼翻效率太低。我接手后的第一件事，是把目录里所有表名提取成一张结构化清单，建自己的“表名速查表”。做法很简单：把doc另存为纯文本，目录行的格式基本是“1.1 性别字典 SEX_DICT 17”，用正则按编号、中文名、表名、页码四段提取。

import re import pandas as pd with open("toc.txt", encoding="utf-8") as f: lines = f.read().splitlines() rows = [] for line in lines: line = line.strip() m = re.match( r"^(\d+\.\d+)\s+(.+?)\s+([A-Z][A-Z0-9_]+)\s+(\d+)$", line ) if m: rows.append({ "编号": m.group(1), "中文名": m.group(2), "表名": m.group(3), "页码": int(m.group(4)) }) df = pd.DataFrame(rows) df.to_csv("tianjian_tables.csv", index=False, encoding="utf-8-sig")

正则里的([A-Z][A-Z0-9_]+)只匹配大写字母、数字和下划线组成的表名，正好卡住SEX_DICT、PAT_MASTER_INDEX这类命名。(.+?)用非贪婪匹配截取中文名，避免把页码吞进去。导出用utf-8-sig编码，双击打开CSV不会乱码。

建好这张表后，我把“表名”这一列做成筛选下拉，看到一个业务问题先按中文名关键词过滤，再按表名回手册查字段。比如想找“发药”相关表，筛“发药”出来就是DRUG_DISPENSE_REC、DRUG_PROVIDE_NOTICE、DOCT_DRUG_PRESC_MASTER等一串，比在几百页Word里翻目录效率高太多。从那以后我每次接老系统，都强制自己先把元数据检索表搭起来再碰业务SQL，磨刀不误砍柴工。这套流程也推荐给要长期维护HIS数据的人，希望帮到你。

本文还有配套的精品资源，点击获取