2.10 主数据与术语字典库：最容易被忽视，收益最大
如果要在这份盘点中挑出一个"投入产出比最高"的改造对象，那就是主数据与术语字典。因为它被所有系统依赖，改一次，全院受益。
三大类主数据
第一类：患者主索引（EMPI）
EMPI 的作用是给同一个患者在不同系统中的不同 ID 建立映射，从而把临床数据按人归集。它是 CDR 建设的核心组件。
公开的技术文献指出，构建 EMPI 有两个核心难题：一是识别不同系统中同一患者不同 ID 之间的映射关系十分困难，尤其在区域平台上每个系统都有独立 ID 时更复杂；虽然可通过医保卡号部分解决，但仍有患者无卡或不使用卡的情况，因此要求实名认证（身份证 + 手机号）是必要的。二是一个患者的基础信息（年龄、性别等）可能同时存在于 HIS、LIS、PACS 等系统中，各系统侧重点不同，容易造成填写质量不一致或未及时更新。（据医疗数据治理相关技术文献）
第二类：机构、科室、人员主数据
痛点是"组织架构漂移"：科室会合并、拆分、改名，人员会调动、晋升。如果没有历史归属管理，"去年这个科室有多少人、做了多少台手术"这类问题就无法准确回答。
第三类：术语与编码主数据
包括诊断（ICD-10 / ICD-11 / 医保版 ICD）、手术操作（ICD-9-CM-3 / 医保版）、检验项目（LOINC）、药品（RxNorm / ATC / 医保药品编码）、耗材、收费项目、中医病证等。
关键设计原则
术语映射中心不应设计成"一对一映射表"，而应设计成带置信度与优先级的映射系统：
| 设计要点 | 说明 |
|---|---|
| 多对多关系 | 一个院内项目可映射多个标准概念，一个标准概念可被多个院内项目映射 |
| 置信度 | 映射结果标注 confidence（如 1.0 确定、0.8 待复核、0.5 建议） |
| 优先级规则 | 当存在多个候选时按既定规则选优（如术语体系优先级、临床特异度、显式 primary 标记） |
| 版本与生效期 | 映射关系随时间变化（术语表更新、院内项目调整），需带生效起止时间 |
| 未映射清单 | 显式记录所有未映射项，作为持续改进的待办池 |
| 责任人 | 每条映射有业务责任人，避免"映射了但没人负责" |
这套设计对应 OMOP 官方映射指南中提出的"代码优先级框架"：先按术语体系优先级（SNOMED CT > RxNorm > LOINC > ICD > 本地码），再按临床特异度（优先选择更具体的子概念而非父概念），再考虑 FHIR 中显式的 primary / preferred 标记，最后在条件相同时按出现顺序取第一项。同时在转换过程中应记录足够细节（源系统 URI、源代码、术语服务返回的概念、所做的转换决策），以支持审计与质量保证。
2.11 智能层：AI 时代新增的五类库
这是本书最关注的一层——因为它变化最快、最容易做错，也最容易被当成"厂商的黑盒"。
第一类：向量库 / 向量索引
用途：语义检索。为病历段落、检验报告、影像报告、指南文档建立嵌入向量，支持相似度检索。
设计要点：
- 切分策略必须稳定可复现：同一份病历两次切分必须产生相同结果，否则索引与原文无法对齐；
- 必须保留定位元数据：文档 ID、段落序号、字符偏移、版本号、源系统、生成时间；
- 必须支持增量更新：新病历产生时只追加，不重建全库；
- 必须与原始数据可反查：任何一次检索结果都能回跳到原文；
- 需处理文本修订：病历被修订后，旧向量应失效或被标记。
第二类：特征库 / 指标库
用途：为预测模型、风控、运营分析提供稳定的特征与指标。
设计要点：特征定义必须版本化（“这个模型用的是 v3 版特征定义”），特征计算的时点必须明确（防止数据穿越，即用未来的信息预测过去）。
第三类：标签库
用途：为患者打标签（如"高血压患者"“高风险跌倒”“慢病随访人群”），供人群管理与 Agent 使用。
设计要点：标签必须有明确的定义表达式、更新频率、有效期、责任人。最忌讳的是"标签定义只存在于某个人的脑子里"。
第四类：Prompt 与知识资产库
用途：存储提示词模板、规则、知识片段、术语释义。这是最容易被忽视但极其关键的一层——模型会换，Prompt 与知识资产是会沉淀的。
设计要点：版本化、可 A/B、带效果指标、带责任人。
第五类：模型调用审计库
用途：记录每一次 AI 调用的输入、输出、模型版本、耗时、成本、命中知识、人工干预情况。
设计要点：这是合规审计与质量改进的底座，也是回答"AI 到底做了什么"的唯一依据。没有审计库的 AI 系统，在医疗场景中是不合格的。
2.12 一张总表：各库的痛点、AI 需求与改造代价
| 数据层 | 代表系统/库 | 核心痛点 | AI 时代典型需求 | 改造代价 | 推荐策略 |
|---|---|---|---|---|---|
| 生产库 | HIS 业务库 | 事务压力大、耦合深、文档缺失 | 医嘱时序、药品语义、费用关联 | 极高 | 只读加层，不动物理结构 |
| 生产库 | EMR 电子病历库 | 非结构化为主、版本混乱 | 后结构化、可切片文档树 | 高 | 加旁路抽取表 |
| 生产库 | LIS 检验库 | 项目字典混乱、单位不一 | 趋势化、跨院互认、异常语义化 | 中 | 建字典映射中心 |
| 生产库 | RIS/PACS | 存储封闭、报告版本多 | 报告结构化、影像—文本关联 | 高 | 走标准接口 |
| 生产库 | 手麻/ICU/护理 | 时序噪声大、状态机缺失 | 高质量时序数据集 | 中 | 在分析层重建 |
| 集成库 | EMPI / MDM | 匹配精度不足、无历史归属 | 患者唯一视图 | 中 | 优先改造 |
| 分析库 | CDR / ODS / 数仓 / 湖仓 | 汇聚≠可用、治理无闭环 | 语义层、特征库 | 低（可重建） | 主战场 |
| 支付库 | 病案首页 / 结算清单 | 编码质量不稳、口径不一 | 分组校验、清单完整性 | 中 | 前置校验 + 数据契约 |
| 运营库 | HRP / SPD | 主数据不统一、口径不一 | 成本追溯、指标统一 | 中 | 指标字典先行 |
| 知识库 | 术语字典 / 规则库 | 不完整、无版本 | 术语映射中心 | 中 | 高优先级 |
| 智能层 | 向量库/特征库/标签库/知识资产/审计库 | 无标准、易黑盒 | 可溯源、可回滚、可审计 | 低（新建） | 用标准模式快速搭 |
读表建议：把改造代价为"低"的部分（分析库、智能层）视为你的快速战场；把代价为"极高"的部分（HIS 物理结构）视为不可碰的红线。全书的方法论都建立在这个判断上。
2.13 本章小结
- 医院数据可分为五层：生产库、集成库、分析库、知识库、智能层。改动难度递减，改动频率递增。
- HIS 是最难改的，EMR 是最关键的，LIS 是最结构化但语义最乱的，PACS 是最封闭的。
- CDR 与湖仓是"可重建"的，因此是 AI 数据需求的主战场。
- 主数据与术语字典的投入产出比最高，值得优先投入。
- 智能层的五类新库（向量、特征、标签、知识资产、审计）是 AI 时代的新增建物，也是本章最需要标准化设计的一层。
- DRG/DIP 2.0、数据要素政策、电子病历分级评价，共同构成了需求的外部驱动力——下一章展开。
第 3 章 AI 时代需求变化的五大驱动力
第 2 章盘点了"有什么"，这一章回答"为什么现在必须改"。我们把驱动医疗数据库需求变化的力量归纳为五条，它们既相互独立，又彼此叠加。
3.1 模型驱动：RAG 对数据提出的四个硬要求
检索增强生成（RAG）是当前医疗 AI 落地最主流的架构之一。它的原理并不复杂：把机构内的知识（病历、指南、制度）建立索引，在回答问题时先检索、再生成。但它对底层数据提出了四个在传统信息化中从未被明确提出的要求。
要求一：可检索——从"存得下"到"找得到"
传统数据库的目标是"存得下、取得出"，查询条件是精确的（按患者 ID、按时间范围）。RAG 需要的是语义检索：给一段自然语言，找出语义最接近的内容。这要求为非结构化数据建立向量索引。
难点在于：医院的文本不是干净的语料。它包含大量缩写、口语化表达、模板套话、复制粘贴的冗余段落。直接做嵌入，"出院记录"里的通用段落会
 报错排查与修复指南)
