常用医疗系统数据库在AI时代的快速需求改进（二）

2.10 主数据与术语字典库：最容易被忽视，收益最大

如果要在这份盘点中挑出一个"投入产出比最高"的改造对象，那就是主数据与术语字典。因为它被所有系统依赖，改一次，全院受益。

三大类主数据

第一类：患者主索引（EMPI）

EMPI 的作用是给同一个患者在不同系统中的不同 ID 建立映射，从而把临床数据按人归集。它是 CDR 建设的核心组件。

公开的技术文献指出，构建 EMPI 有两个核心难题：一是识别不同系统中同一患者不同 ID 之间的映射关系十分困难，尤其在区域平台上每个系统都有独立 ID 时更复杂；虽然可通过医保卡号部分解决，但仍有患者无卡或不使用卡的情况，因此要求实名认证（身份证 + 手机号）是必要的。二是一个患者的基础信息（年龄、性别等）可能同时存在于 HIS、LIS、PACS 等系统中，各系统侧重点不同，容易造成填写质量不一致或未及时更新。（据医疗数据治理相关技术文献）

第二类：机构、科室、人员主数据

痛点是"组织架构漂移"：科室会合并、拆分、改名，人员会调动、晋升。如果没有历史归属管理，"去年这个科室有多少人、做了多少台手术"这类问题就无法准确回答。

第三类：术语与编码主数据

包括诊断（ICD-10 / ICD-11 / 医保版 ICD）、手术操作（ICD-9-CM-3 / 医保版）、检验项目（LOINC）、药品（RxNorm / ATC / 医保药品编码）、耗材、收费项目、中医病证等。

关键设计原则

术语映射中心不应设计成"一对一映射表"，而应设计成带置信度与优先级的映射系统：

这套设计对应 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 需求与改造代价

读表建议：把改造代价为"低"的部分（分析库、智能层）视为你的快速战场；把代价为"极高"的部分（HIS 物理结构）视为不可碰的红线。全书的方法论都建立在这个判断上。

2.13 本章小结

• 医院数据可分为五层：生产库、集成库、分析库、知识库、智能层。改动难度递减，改动频率递增。
• HIS 是最难改的，EMR 是最关键的，LIS 是最结构化但语义最乱的，PACS 是最封闭的。
• CDR 与湖仓是"可重建"的，因此是 AI 数据需求的主战场。
• 主数据与术语字典的投入产出比最高，值得优先投入。
• 智能层的五类新库（向量、特征、标签、知识资产、审计）是 AI 时代的新增建物，也是本章最需要标准化设计的一层。
• DRG/DIP 2.0、数据要素政策、电子病历分级评价，共同构成了需求的外部驱动力——下一章展开。

第 3 章 AI 时代需求变化的五大驱动力

第 2 章盘点了"有什么"，这一章回答"为什么现在必须改"。我们把驱动医疗数据库需求变化的力量归纳为五条，它们既相互独立，又彼此叠加。

3.1 模型驱动：RAG 对数据提出的四个硬要求

检索增强生成（RAG）是当前医疗 AI 落地最主流的架构之一。它的原理并不复杂：把机构内的知识（病历、指南、制度）建立索引，在回答问题时先检索、再生成。但它对底层数据提出了四个在传统信息化中从未被明确提出的要求。

要求一：可检索——从"存得下"到"找得到"

传统数据库的目标是"存得下、取得出"，查询条件是精确的（按患者 ID、按时间范围）。RAG 需要的是语义检索：给一段自然语言，找出语义最接近的内容。这要求为非结构化数据建立向量索引。

难点在于：医院的文本不是干净的语料。它包含大量缩写、口语化表达、模板套话、复制粘贴的冗余段落。直接做嵌入，"出院记录"里的通用段落会淹没真正有信息量的内容。

要求二：可切片——切分粒度决定了上限

切片（chunking）是 RAG 中最重要的工程决策之一。切得太粗，检索到的内容噪声大；切得太细，上下文丢失。

医疗文本的切片有额外的复杂度：

• 病历有天然的层级结构（文书 → 章节 → 段落）；
• 同一段落内可能包含多个独立的医学事实；
• 检验报告是表格型，切分需要考虑行列对应。

一个可行的方案是"层级切分 + 语义边界"：先按文书类型和章节切，再在章节内按段落切，对长段落按医学实体边界二次切分。关键是切分结果必须可复现且可反查原文位置。

要求三：可对齐——时间与主体必须明确

同一个患者有多次就诊，同一个诊断在多次就诊中被反复记录，同一份检验有多个时间点。RAG 若不能正确判断"这条信息属于哪次就诊、发生在什么时间"，就会给出错误答案。

举个例子：患者三年前有一次"心肌梗死"诊断，本次主诉是"胸痛"。如果检索系统把历史诊断当作本次诊断，模型可能给出"这是心肌梗死复发"的错误推断。解决这个问题需要数据层面的支撑：诊断要带"本次就诊 / 既往史"的属性，检验要带采集时间，用药要带起止时间。

要求四：可溯源——每个结论都要有出处

医疗场景不允许"无法追溯的回答"。这要求检索结果必须携带精确的定位信息：哪份文书、哪一节、哪一段、第几个字符、哪个版本。

这四点在传统的数据汇聚工作里都不是硬指标，但在 RAG 场景里是上线门槛。

3.2 代理驱动：Agent 要"能写、能回滚、能审计"

如果说 RAG 是"读"，那么 Agent 就是"读写"。当 AI 从助手升级为代理（能够自主执行多步任务），它必然要写回数据。这才是对数据库的真正考验。

场景示例（合成）

一个"医保编码辅助 Agent"被授权在病案编码环节工作。它需要：

这个流程对数据库的要求是：

为什么这是数据库问题而不是应用问题

因为"审批流 + 版本 + 审计"这些能力，本质上需要表结构层面的支持。如果应用层自己维护一份备忘录，一旦更换厂商或升级版本，审计链就断了。正确的做法是把这些能力下沉到数据库的公共模式中，作为基础设施。

一个可复用的通用模式

我们推荐"三段式写入模式"：

建议表（AI 产出） → 审核表（人机交互） → 正式表（业务生效）

三张表通过 trace_id 串联，任何一条正式数据都能回溯到它的建议来源与审核人。这个模式可以复用于几乎所有 Agent 场景：编码、质控、随访、分诊。

3.3 合规驱动：数据分类分级与全生命周期管理

这是最刚性的一条驱动力。它的特点是：不合规的加速等于负加速。

核心法规与标准

《医疗卫生机构网络安全管理办法》的关键条款

该办法（2022 年 8 月由三部门印发）明确：

• 各医疗卫生机构应每年对数据资产进行全面梳理，在落实网络安全等级保护制度的基础上，依据数据的重要程度以及遭到破坏后的危害程度建立本单位数据分类分级标准。分类分级应遵循合法合规、可执行、时效性、自主性、差异性及客观性原则；
• 应加强数据收集、存储、传输、处理、使用、交换、销毁全生命周期安全管理工作，数据全生命周期活动应在境内开展；因业务确需向境外提供的，应当按照相关法律法规及有关要求进行安全评估或审核；针对影响或者可能影响国家安全的数据处理活动需提交国家安全审查；
• 应建立数据安全管理组织架构，明确业务部门与管理部门在数据安全活动中的主体责任；建立健全数据安全管理制度、操作规程及技术规范，涉及的管理制度每年至少修订一次；每年开展数据安全风险评估；
• 在分类分级基础上，明确不同安全级别数据的加密传输要求，加强接口安全控制；选择合适的数据存储架构和介质在境内存储，采取备份、加密等措施，数据存储周期不应超出数据使用规则确定的保存期限。

这些要求如何变成数据库需求

一个常被忽略的点

很多医院在"采集端"做了脱敏，却忘了"训练端"和"推理端"。当病历数据被用于微调大模型，或作为 RAG 的检索语料时，如果索引中残留可识别信息，风险同样存在。行业内已有成熟实践可参考：某大型医疗系统的去标识化工程曾对 20 亿份患者笔记进行处理，实现 99% 的受保护健康信息（PHI）混淆率与目标字段 100% 的掩码或移位，满足 HIPAA 隐私规则的专家判定标准，且经红队三个月对抗测试无法重新识别任何患者（据公开案例研究，2025 年）。

3.4 支付驱动：DRG/DIP 2.0 把数据质量变成钱

第 2 章已经介绍了 2.0 版分组方案的要点。这里从"需求驱动"的角度再深入一层。

DRG/DIP 对数据库的四点硬要求

第一，编码完整性。 核心分组从 1.0 到 2.0 增加了 33 组至 409 组，DIP 核心病种为 9520 组。分组越细，对输入的诊断与手术编码的要求越高。一个未被编码的并发症，可能让病例从高权重组掉到低权重组。

第二，编码准确性。 主要诊断的选择有明确规则（“三最原则”：消耗医疗资源最多、对患者健康危害最大、影响住院时间最长）。数据库层面需要能校验：诊断列表是否存在、主要诊断是否被标记、手术与诊断的逻辑是否自洽。

第三，字段完整性与一致性。 结算清单 190 项中，来自病案首页的部分必须与首页一致；费用部分必须与收费票据口径一致。这意味着数据库需要建立跨源一致性校验。

第四，可解释性。 医保部门与临床都需要知道"这个病例为什么分到了这一组"。这要求分组过程可追溯：用了哪些字段、命中哪条规则、与哪一版分组器。数据库层面需要记录分组快照。

由此产生的三类新表

一个必须注意的合规红线

2.0 版通知明确：医疗机构不得将 DRG/DIP 病组（病种）支付标准作为限额对医务人员进行考核或与绩效分配指标挂钩。 这条要求在系统设计上有直接含义：如果你的数据库中存在"把支付标准写入医师绩效表"的设计，需要重新审视。技术上的合规做法是：分组结果只用于结算与运营分析，不进入个人绩效计算链路。

3.5 要素驱动：数据从"副产品"到"资产"

第四条驱动力来自政策对数据价值的重新定位。

政策背景

2024 年，国家数据局会同中央网信办、科技部、工业和信息化部、国家卫生健康委、国家医保局等 17 部门联合印发《"数据要素×"三年行动计划（2024—2026 年）》，选取工业制造、现代农业、商贸流通、交通运输、金融服务、科技创新、文化旅游、医疗健康、应急管理、气象服务、城市治理、绿色低碳等 12 个行业和领域，推动发挥数据要素乘数效应。

其中"数据要素×医疗健康"明确的方向包括：

• 提升群众就医便捷度，探索推进电子病历数据共享，在医疗机构间推广检查检验结果数据标准统一和共享互认；
• 便捷医疗理赔结算，支持医疗机构基于信用数据开展先诊疗后付费；
• 依法依规探索推进医保与商业健康保险数据融合应用；
• 有序释放健康医疗数据价值，完善个人健康数据档案，融合体检、就诊、疾控等数据，创新基于数据驱动的职业病监测、公共卫生事件预警等公共服务模式；
• 加强医疗数据融合创新，支持公立医疗机构在合法合规前提下向金融、养老等经营主体共享数据，支撑商业保险产品、疗养休养等服务产品精准设计，拓展智慧医疗、智能健康管理等数据应用新模式新业态。

此外，2024 年 5 月国家数据局会同多部门发布首批 20 个"数据要素×"典型案例，其中包括"医疗数据智能化分析辅助提升基层诊疗水平""高质量药物数据集提高新药研发质效"等健康医疗领域案例。

这如何转化为数据库需求

数据要成为"要素"，前提是可度量、可描述、可交付。这带来三个新需求：

《"十四五"全民健康信息化规划》的背景要求

2022 年 11 月，国家卫生健康委、国家中医药局、国家疾控局印发《“十四五"全民健康信息化规划》（国卫规划发〔2022〕30 号），列出 8 方面主要任务：集约建设信息化基础设施支撑体系、健全全民健康信息化标准体系、深化"互联网+医疗健康"服务体系、完善健康医疗大数据资源要素体系、推进数字健康融合创新发展体系、拓展基层信息化保障服务体系、强化卫生健康统计调查分析应用体系、夯实网络与数据安全保障体系。其中明确到 2025 年，二级以上医院基本实现院内医疗服务信息互通共享，三级医院实现核心信息全国互通共享；并要求以普及应用居民电子健康码为抓手，建立居民以身份证号码为主、其他证件号码为补充的唯一主索引，推动"一码通用”。

"唯一主索引"四个字，直接指向 EMPI 的建设——这正是第 2.10 节讨论的内容。

3.6 场景驱动：84 个应用场景带来的需求清单

第五条驱动力来自官方给出的应用场景清单，它把模糊的"我们要做 AI"变成了可枚举的需求。

2024 年 11 月，国家卫生健康委、国家中医药局、国家疾控局联合印发《卫生健康行业人工智能应用场景参考指引》，从四大领域、13 个类目给出 84 项典型应用场景：

• "人工智能+"医疗服务管理（38 项）：包括医学影像智能辅助诊断、医学影像数据智能辅助质控、临床专病智能辅助决策、基层全科医生智能辅助决策、智能预问诊、智能随访、智能病历辅助生成、处方前置审核智能辅助、临床用药智能辅助、医保智能审核、医保智能核算、中医临床智能辅助诊疗、中药智能审方、智能医疗文书质控辅助、智能医疗质量管理、智能手术室管理、智能药房管理、智能耗材管理、智能医院经济管理决策支持等；
• "人工智能+"基层公卫服务（23 项）：智能健康管理、智能慢性病管理、传染病智能监测、智能卫生应急管理、智能老年人健康管理等；
• "人工智能+"健康产业发展（13 项）：手术机器人、康复机器人、智能药物研发、中药材智能仿生鉴定识别等；
• "人工智能+"医学教学科研（10 项）：医学教学智能辅助、医学智能仿真实验、智能患者招募、智能研究型病房、医学科研智能辅助、智能医学科研数据分析等。

这份清单的数据库含义

把 84 项场景按"数据依赖"重新归类，会发现它们高度集中在少数几类数据能力上：

结论很清晰：与其为 84 个场景各自准备数据，不如为这 6 类数据能力建设统一的底座。 这是本书"稳定底座 + 可复用模式"主张的现实依据。

3.7 驱动力—需求矩阵

把五条驱动力与数据层的需求对应起来，得到下面这张矩阵。它可以作为你需求池的分类工具。

读法：一行代表一类数据，一列代表一条驱动力。格子里的内容就是"这类数据在这条驱动力下被要求做什么"。当你收到一个模糊的需求时，先在矩阵上定位它，就能快速判断影响范围。

3.8 本章小结

• 五大驱动力分别是：模型驱动（可检索/切片/对齐/溯源）、代理驱动（可写/可回滚/可审计）、合规驱动（分类分级/全生命周期/境内存储）、支付驱动（DRG/DIP 2.0 的编码质量）、要素驱动（数据资产化与产品化）。此外还有场景驱动（84 项应用场景）。
• 合规是刚性约束，不合规的加速等于负加速。
• DRG/DIP 2.0 把数据质量直接转化为经济后果，也带来了明确的合规红线。
• 84 项应用场景虽然繁多，但底层只依赖 6 类数据能力，应当建设统一底座而非逐场景重复投入。
• 驱动力—需求矩阵是把模糊需求转化为明确改造项的工具。

下一章，我们进入本书的核心：如何把这一堆需求，快速、可验证地落下去。

第 4 章 快速需求改进方法论：五段加速

前四章建立了认知框架，从这一章开始进入操作层面。本章给出一个可执行的方法论：把医疗数据库的 AI 类需求改进，拆成五个阶段，并对每个阶段给出具体的加速手段。

4.1 总模型：需求改进流水线

先看全景。

阶段一 发现 → 阶段二 定义 → 阶段三 验证 → 阶段四 交付 → 阶段五 治理
（需求从哪来） （改什么、怎么改） （改对了吗） （怎么上线） （怎么不反复）
↑ │
└──────────────── 需求资产回流 ────────────────────────────────┘

五个阶段的产出物分别是：

一个重要提醒：五个阶段不是串行的瀑布，而是并发的流。 成熟团队会让不同需求分布在不同阶段同时推进，这样可以避免"所有需求都在等最后一环"的排队效应。

4.2 发现加速：让需求自己浮出来

传统做法是"等业务部门提需求"。这在 AI 时代效率极低，因为业务部门往往不知道 AI 能做什么。更高效的做法是主动挖掘。

手段一：工单与需求历史聚类

把过去 12–24 个月的信息科工单、需求单、故障单导出，用语义聚类分组。你会惊讶地发现：重复出现的痛点往往就是最有价值的改造点。

例如，聚类后可能出现一个高频簇：“报表数字对不上”。它背后往往是"指标口径不统一"这一个根因，而不是二十个不同的报表 bug。解决根因一次，可以消掉二十张工单。

手段二：日志与慢查询挖掘

数据库的慢查询日志、接口调用日志、报表运行日志，是需求的金矿：

• 反复全表扫描的 SQL，往往指向缺失的索引或未优化的模型；
• 频繁 JOIN 五个以上表的查询，往往指向未建宽表或未建语义层；
• 某个接口调用量是其他接口的百倍，往往指向一个未被识别的高频场景。

手段三：AI 辅助访谈

临床与管理部门的需求访谈，传统上是"信息科记录、回去整理"。加速方式是：

这可以把一份访谈从"整理两天"压缩到"校对两小时"。注意：录音必须先取得对方同意，并遵守《个人信息保护法》对个人信息的处理要求。

手段四：政策与考核指标的自动追踪

政策文件、评级标准、绩效考核指标是需求的重要外部来源。可以建立一个小型"规则库"，把关键要求逐条登记，定期核对当前系统的符合度。这比每年临到评审前突击补数据要高效得多。

需求优先级：一个实用的打分法

发现的需求会有很多，必须有排序依据。推荐一个四维打分：

合规刚性排第一位，这是医疗行业的特殊性决定的。

4.3 定义加速：从自然语言到数据契约

这是全书最关键的一节。定义阶段的产出质量，决定了后面所有环节的效率。

什么是"数据契约"

数据契约（Data Contract）是一份明确约定"某类数据长什么样、谁负责、变化如何通知"的文档。它不是数据库设计文档，而是供需双方的接口约定。

一份数据契约至少包含：

AI 如何加速契约编写

定义阶段最耗时的部分是"摸清现状"。这一步可以显著加速：

必须警惕的一点

AI 生成的 DDL 和影响面分析，必须经过人工核查。原因很简单：元数据中的字段注释经常是错的、过时的、复制粘贴来的。一个真实的情况是：某表的 remark 字段注释写的是"备注"，实际存的是"入院方式代码"。如果直接信任注释，整个分析都会跑偏。

推荐的核查方法：三源交叉

对任何关键字段，用三个来源交叉验证：

三者一致，可高度信任；三者不一致，以"代码 + 数据画像"为准，并顺手修正元数据——这一步的副产品就是数据地图的持续完善。

影响面分析的四个必查项

任何字段级变更，必须排查：

4.4 验证加速：在真实数据之前先把错犯完

验证是 AI 数据需求与传统需求差异最大的环节。传统需求可以"上线后看用户反馈"，AI 数据需求不行——错误的输入会静默地产生错误输出，且很难被发现。

手段一：合成数据先行

在真实数据尚未就绪（或因合规原因不可用）时，用合成数据先把链路打通。

合成数据的三种做法：

• 规则生成：按字段定义与值域规则生成，适合结构验证；
• 采样变形：从真实数据中采样后做保结构变形（如姓名替换、日期平移），适合逻辑验证；
• 模型生成：用大模型生成符合医学逻辑的合成病历，适合语义验证与演示。

必须注意：合成数据可以验证"程序对不对"，但不能验证"数据质量好不好"。后者只能用真实数据。

手段二：影子表与双跑对账

新逻辑与旧逻辑并行运行，输出结果比对。这是最稳妥的验证方式，也是医疗场景的必备手段。

一个实用的对账设计：

对账维度：
总量对账 —— 记录数是否一致（允许已知差异并解释）
关键字段对账 —— 核心字段值是否一致
分布对账 —— 空值率、枚举分布是否漂移
边界对账 —— 极端值、缺失值处理是否一致

对账结果必须逐条解释差异，而不是笼统地说"基本一致"。差异解释的过程，就是发现隐性规则的过程。

手段三：评测集建设

对 AI 抽取、分类、推理类需求，必须建立评测集。评测集的设计要点：

手段四：影子模式上线

在正式启用前，让系统以"影子模式"运行一段时间：只产生结果、不产生业务影响，由人工抽样核对。

行业内已有可参考的精度区间（见第 2.3 节）：实体识别 F1 常在 0.85–0.95 之间，否定检测更低，OCR 后进一步下降。因此影子期的规模要根据目标精度反推——如果期望 95% 的准确率，至少要覆盖足够多的高风险样本才能有统计信心。

4.5 交付加速：六个"不动物理库"的技法

这一节的内容与第 5 章高度相关，这里先给出概要。

技法一：视图灰化（View Shimming）

不改物理表，而是建立一层视图，在视图中完成字段重命名、类型转换、口径调整。应用改为访问视图。优点是对源系统零侵入；缺点是视图复杂后性能下降，需要配合物化视图。

技法二：旁路加层（Sidecar Table）

新建独立的补充表，通过主键与源表关联。例如，源表没有"过敏史结构化字段"，则新建 allergy_ext 表，通过 patient_id + visit_id 关联。优点是零侵入、可回滚；缺点是需要处理一致性。

技法三：CDC 实时同步

通过变更数据捕获（Change Data Capture）把源库变更实时同步到分析库或向量库。这是在不动生产库的前提下获得"准实时数据"的标准做法。需要在设计时考虑：断点续传、乱序处理、DDL 变更适配、同步延迟监控。

技法四：语义层（Semantic Layer）

在物理表之上建立"业务语义层"，统一指标定义与维度。所有报表、BI、AI 应用都通过语义层取数，从根上消除"口径不一致"。

领域内一个值得注意的实践是 FHIR 与 OMOP 的并存：FHIR 面向实时交换与操作层，OMOP 面向批量分析与标准化术语层，二者不是替代关系而是分工关系。在成熟架构中，通常以 FHIR 作为交换标准、以 OMOP 作为分析模型，二者之间通过标准映射与 ETL 管道桥接。

技法五：数据虚拟化

对不常访问、体量大的历史数据，采用虚拟化查询（联邦查询）而非物理搬迁。

技法六：读写分离与只读副本

所有 AI 类读取都走只读副本，杜绝影响生产库的风险。这是最低成本的技法是也是最重要的纪律。

4.6 治理加速：把需求变成资产

这一节回答"怎么不反复"。

核心动作一：需求资产化

每个需求单都应结构化存储，包含：编号、提出方、背景、涉及数据对象、变更内容、影响面、验证方式、上线时间、效果度量、责任人。

资产化的价值在于：当类似需求再次出现时，可以直接调用历史方案。 一个成熟的资产库，可以让重复需求的响应时间下降 50% 以上。

核心动作二：需求↔测试↔发布的追溯链

从需求编号出发，能一路查到：涉及的数据契约版本、验证用例、发布记录、上线后指标。这条链是审计的基础，也是知识传承的载体。

核心动作三：变更通知机制

数据契约一旦变更，自动通知所有相关方。这是"数据契约"相较"数据库设计文档"的关键差异——契约是活的，会主动提醒。

核心动作四：定期存量治理

不要指望新需求顺带解决历史问题。需要设立专门的存量治理节奏：例如每季度选一个主题（术语映射、主索引、指标口径）集中攻坚。

4.7 加速的边界：什么不能交给 AI

这一节很重要，因为过度自动化在医疗场景是有害的。

原则：AI 负责"扩大候选集、加速初稿、发现异常"，人负责"决策、担责、定标准"。

4.8 一个完整的例子（合成场景）

为了让方法论落地，看一个端到端例子。

需求：医院要上线"智能病历质控"，需要系统能在医生书写时实时提示病历缺陷。

阶段一 发现

• 从工单聚类发现：“病案室退修率高”"质控科抽查覆盖率低"两个高频簇；
• 从政策追踪发现：电子病历分级评价对病历质控有明确要求，5 级要求"能够根据不同专科病历、诊断等，选择差别化的质量控制项目，进行病历质控，能够记录病历内容缺陷并对时限、规定必须书写的病案内容进行自动判断处理，生成相应的质控记录，质控结果能反馈给相应的病历书写医师和管理者"；
• 优先级：合规刚性高（评级要求）+ 阻塞程度高（影响评级）+ 复用广（可用在多个文书类型）。

阶段二 定义

产出数据契约四份：

阶段三 验证

• 抽取 2000 份历史病历（按科室、文书类型分层）；
• 请 2 名质控人员独立标注"应命中的缺陷"；
• 用新规则跑一遍，计算命中率、误报率、漏报率；
• 逐条分析分歧，修订规则；
• 目标：关键规则命中率 > 90%，误报率 < 10%。

阶段四 交付

• 以影子模式上线 2 周，只记录不提示；
• 收集医师反馈，调整提示语与阈值；
• 灰度开放：先 2 个科室，再全院；
• 保留一键关闭开关与规则版本回滚能力。

阶段五 治理

• 建立"规则变更申请—评审—发布—效果观察"闭环；
• 每月产出质控效果报表（缺陷发现数、医师接受率、退修率变化）；
• 把规则库作为资产登记，纳入数据地图。

成果（示例数据）：退修率下降、质控覆盖率从抽查 5% 提升到全量、医师接受率逐步提升。关键不是数字本身，而是每一步都有可核验的证据。

4.9 本章小结

• 五段流水线：发现 → 定义 → 验证 → 交付 → 治理，并形成需求资产回流闭环。
• 发现阶段要靠主动挖掘（工单聚类、日志挖掘、访谈转写、政策追踪），而不是被动等待。
• 定义阶段的产物是"数据契约"，它比数据库设计文档更强调责任、版本与变更通知。
• 验证阶段的核心是合成数据、双跑对账、评测集与影子模式。
• 交付阶段的六个技法共同指向一个原则：不动物理库。
• 治理阶段把需求变成资产，是"不反复"的关键。
• 加速有边界：AI 扩大候选、加速初稿、发现异常；人做决策、担责、定标准。

下一章，我们把"不动物理库"这一原则展开为完整的架构策略。