4. 规则体系架构设计
医疗数据质量规则体系如果只是把几百条校验规则堆在一个文档里，很快就会失控：同一条“住院号非空”在三个系统里写法不同，某个字段口径变更后没人知道哪些规则受影响，规则上线后也无法解释为什么这条数据被拦截。要解决这些问题，必须先把规则体系当成一个“有层次、有元数据、有存储、有执行”的工程结构来设计。本节围绕四个核心构件展开：分层架构负责“规则怎么分类”，元数据管理负责“规则描述什么”，规则仓库负责“规则存在哪里”，规则引擎负责“规则怎么跑起来”。
一、分层架构：基础规则、业务规则、场景规则
分层的目的不是把规则分等级，而是按“稳定性”和“复用范围”分层。越靠下的层越稳定、越通用，越靠上的层越贴近具体业务和场景，变化也越快。
基础规则层面向数据本身的结构与格式，与具体业务无关，例如：字段非空、数据类型合法、值域范围、编码格式、主键唯一、日期格式符合 YYYY-MM-DD。这类规则通常由数据标准直接推导，全院甚至跨机构通用。示例：患者性别代码必须属于 GB/T 2261.1 的取值集合 {0,1,2,9}；出生日期不得晚于当前日期。
业务规则层面向医疗业务逻辑，依赖具体业务语义，例如：入院日期不得晚于出院日期；手术编码必须与手术日期同时存在；同一患者同一时间段不得存在两条在院记录。业务规则通常由临床、病案、医保等业务方确认，跨系统复用但需要业务口径支撑。
场景规则层面向具体应用场景，例如上报、结算、科研入组、质控抽查。同一份数据在不同场景下要求不同：病案首页上报要求主要诊断编码必须为 ICD-10 医保版 2.0；而科研入组可能要求某病种必须有病理诊断。场景规则变化最频繁，应尽量通过“引用下层规则 + 场景附加约束”的方式组合，而不是重复定义。
二、元数据管理：让每条规则可解释、可追溯
规则元数据是规则的“身份证”。没有元数据，规则仓库就只是一个文本堆。建议每条规则至少登记以下字段：规则编号、规则名称、所属分层、适用数据对象（表/字段）、规则表达式、阈值或参数、严重级别、责任部门、生效时间、版本号、关联数据标准、变更记录。其中“关联数据标准”和“版本号”最关键：前者让规则能追溯到口径来源，后者让规则变更可回滚、可对比。
元数据管理还要解决“字段—规则—场景”的三向关联。例如字段“主要诊断编码”关联基础规则（编码格式）、业务规则（必须有诊断名称）、场景规则（医保上报版本要求）。当该字段口径变更时，通过元数据即可反查出所有受影响规则，而不是靠人工翻文档。
三、规则仓库与规则引擎的定位
规则仓库是规则的“唯一可信来源”，负责存储、版本、检索、发布和权限。它不负责执行，只负责“规则是什么、当前生效哪一版”。规则仓库应支持按分层、数据对象、责任部门、场景等维度检索，并保留历史版本，做到任何一次拦截都能回溯到当时生效的规则版本。
规则引擎是规则的“执行器”，负责把仓库中发布的规则加载、解析、匹配到数据上并输出结果。它关注的是执行效率、执行顺序、错误定位和结果输出。规则引擎不生产规则，也不应硬编码业务逻辑；它从仓库拉取规则，按优先级执行，返回“通过/不通过/告警”及命中的规则编号。
两者的边界可以概括为：仓库管“规则的生命周期”，引擎管“规则的一次执行”。规则变更走仓库发布流程，引擎只消费已发布版本，避免“改了规则但引擎还在跑旧逻辑”的常见问题。
四、四者如何协同：一次规则执行的完整链路
把四个构件串起来看，一次典型的规则执行链路是：数据标准与业务口径先沉淀为元数据，元数据描述规则并归入相应分层；规则经审核后进入规则仓库并发布版本；规则引擎从仓库拉取当前生效版本，加载到内存或规则集，按优先级对数据逐条匹配；命中后输出结果并携带规则编号，供质控人员回溯到仓库中的规则定义和元数据。
以一个具体示例说明。假设字段“出院日期”需要校验：基础层规则 R-B-012 要求“出院日期格式为 YYYY-MM-DD 且非空”；业务层规则 R-BIZ-045 要求“出院日期 ≥ 入院日期”；场景层规则 R-SCN-008 要求“医保结算场景下出院日期不得晚于结算日期”。三条规则分别登记元数据，关联到“出院日期”字段和“医保结算”场景。引擎执行时按基础→业务→场景顺序匹配，若 R-BIZ-045 不通过，输出规则编号和实际值，质控人员即可定位是入院/出院日期逻辑问题，而不是格式问题。
五、落地时的常见误区
- 分层混用：把“医保上报要求主要诊断编码为 2.0 版”写进基础层，导致基础规则频繁变更。应归入场景层。
- 元数据缺失：只存规则表达式，不记录责任部门和关联标准，规则失效后无人认领。
- 仓库与引擎耦合：引擎直接读规则文档或硬编码阈值，规则变更无法统一发布和回滚。
- 场景规则重复定义：每个场景把基础规则重写一遍，导致同一字段多套口径。应引用下层规则再附加场景约束。
总结来说，分层架构解决规则的“组织方式”，元数据管理解决规则的“可解释与可追溯”，规则仓库解决规则的“存储与版本”，规则引擎解决规则的“执行与反馈”。四者各司其职、边界清晰，规则体系才能从一份文档演变为可持续运行的工程能力。