📚 课程目录第4章医疗支付风控规则引擎构建

4. 医疗支付风控规则引擎构建

规则引擎是医疗支付风控系统的“决策中枢”。它把医保政策、临床合理用药规范、支付方式约束和欺诈识别经验，转化为可执行、可审计、可迭代的判定逻辑。与通用风控不同，医疗支付规则同时受政策强约束和临床个体差异影响，因此引擎必须解决四件事：规则如何表达、规则如何全生命周期管理、规则之间如何避免冲突、规则如何安全上线与回滚。

一、规则表达：从自然语言到可执行判定

规则表达的核心是把“什么条件下，对什么对象，做什么判定”结构化。医疗支付场景中，一条规则通常包含：适用场景（门诊/住院/DRG/DIP）、对象（处方、医嘱、结算单、参保人）、条件（诊断、药品、项目、金额、频次、时间窗）、动作（拦截、预警、降级、转人工）和优先级。推荐采用“条件—动作”结构，条件部分用逻辑表达式描述，动作部分给出处置结果。

例如一条“门诊超量开药预警”规则可表达为：当同一参保人同一药品在30天内累计开药天数超过60天，且该药品属于《长期处方管理规范》目录时，触发预警并转人工审核。这里“30天”“60天”是参数，应外置为可配置项，而不是硬编码在规则文本中。参数外置后，政策调整时只需改参数，不必改规则逻辑。

规则表达还要区分“硬规则”和“软规则”。硬规则对应医保政策红线，如超医保限定支付范围、重复收费，命中后直接拦截；软规则对应风险提示，如高频就诊、金额异常，命中后预警或转人工。硬规则要求确定性高、误伤低；软规则允许一定误报，用于发现新型欺诈模式。

二、规则生命周期管理：从草稿到退役

规则不是一次性写死的代码，而是有生命周期的资产。完整生命周期包括：草稿、评审、测试、发布、运行、监控、修订、退役。每个状态都要有明确的责任人和准入条件。

草稿阶段由业务专家提出规则意图，并填写规则元数据：规则名称、适用场景、触发条件、动作、优先级、生效时间、失效时间、负责人。评审阶段由医保办、临床科室、风控和法务共同确认规则依据，避免“拍脑袋”规则。测试阶段必须在历史结算数据上回放，统计命中率、误报率和拦截金额。发布阶段进入灰度，运行阶段持续监控命中分布和申诉率。当政策变化或误报率超标时，规则进入修订或退役。

生命周期管理的关键是“可追溯”：每条规则从提出到退役的每次变更都要留痕，包括变更人、变更时间、变更原因和影响范围。这样在审计时才能回答“这条规则为什么存在、依据是什么、谁批准的”。

三、规则冲突检测：避免自相矛盾

规则数量增长后，冲突不可避免。常见冲突有四类：条件重叠但动作相反，例如规则A对某药品拦截、规则B对同一药品放行；优先级相同但结论不同；规则链循环触发；参数边界重叠导致同一笔结算被多次处置。

冲突检测可在规则发布前自动执行。基本思路是：把每条规则的条件解析为逻辑表达式，两两比较是否存在可同时满足的取值区间。若存在，再比较动作是否一致。若动作相反且优先级相同，则判定为冲突，必须由规则负责人裁决。对于无法静态判断的冲突，可在测试环境用历史数据回放，观察同一笔结算是否被多条规则同时命中。

处理冲突的原则是：政策硬规则优先于业务软规则；高优先级优先于低优先级；同优先级冲突必须合并或拆分，不能简单“后发布覆盖先发布”。

四、版本控制与灰度发布：安全上线

规则版本控制要求每次修改生成新版本，旧版本保留可回滚。版本号建议采用“主版本.次版本.修订号”，主版本对应政策大调整，次版本对应规则逻辑变化，修订号对应参数微调。每个版本记录变更说明、影响规则清单和回滚方案。

灰度发布是降低风险的关键。可按参保人、医疗机构、险种或结算金额分层放量。例如先对1%的定点药店开放新规则，观察24小时命中率和申诉率；若误报率低于阈值，再扩大到10%、50%，最终全量。灰度期间新旧版本并行，系统需记录每笔结算命中的规则版本，便于对比分析。

回滚机制必须自动化：当灰度版本误报率超过预设阈值，或出现批量申诉时，系统自动切回上一稳定版本，并通知规则负责人。回滚不是失败，而是规则迭代的正常保护措施。

五、一个可执行的规则配置示例

下面给出一条“门诊重复开药预警”规则的配置样例，展示规则表达、参数和版本字段如何落地。该样例为教学示例，参数为合理假设值，实际部署需结合本地医保政策调整。

{
  "rule_id": "OP_DRUG_REPEAT_001",
  "rule_name": "门诊重复开药预警",
  "scene": "outpatient",
  "version": "1.3.0",
  "status": "gray",
  "priority": 80,
  "condition": {
    "same_patient": true,
    "same_drug": true,
    "time_window_days": 30,
    "cumulative_days": { "gt": 60 },
    "drug_catalog": "long_term_prescription"
  },
  "action": "warn_and_manual_review",
  "params": {
    "time_window_days": 30,
    "cumulative_days_threshold": 60
  },
  "effective_from": "2025-04-01",
  "effective_to": "2025-12-31",
  "owner": "医保风控组",
  "basis": "长期处方管理规范（示例）"
}

该配置中，condition描述触发条件，action描述处置动作，params把阈值外置，version和status支持版本与灰度管理，basis记录政策依据。规则引擎加载后，对每笔门诊结算先匹配场景，再求值条件，命中后执行动作并记录规则版本。

规则上线前，建议用近3个月历史结算数据回放，重点观察误报率。若误报率超过5%，应先调整参数或缩小适用范围，而不是直接全量发布。

规则冲突不能靠“后发布覆盖先发布”解决。同一场景下动作相反的规则必须显式裁决，否则同一笔结算可能被拦截又被放行，导致审计无法解释。

综上，医疗支付风控规则引擎的建设重点不在“写多少条规则”，而在规则表达是否结构化、生命周期是否可追溯、冲突是否可检测、版本与灰度是否可控。把这四件事做好，规则引擎才能既守住医保基金安全，又不误伤合理诊疗。