Files
AIclinicalresearch/docs/03-业务模块/IIT Manager Agent/02-技术设计/docs_03-业务模块_IIT Manager Agent_02-技术设计_11-基于Skills的CRA规则配置实施指南.md

7.6 KiB
Raw Blame History

基于 Skills 的 CRA 规则配置实施指南

文档目的: 定义如何通过 iit_skills 表配置化实现 CRA 的 5 大核心工作变量质控、入排、PD、AE、伦理

适用版本: IIT Manager Agent V2.9.1

创建日期: 2026-02-07

🏗️ 核心概念Skill = 规则容器

在我们的架构中,Skill (技能) 是一个可执行的最小业务单元。它定义了:

  1. 触发条件:什么时候跑?(Webhook/Cron)
  2. 执行引擎:用哪个引擎跑?(Hard/Soft)
  3. 配置数据:具体规则是什么?(JSON/Prompt)
  4. 数据依赖:需要哪些数据?(Tags)

数据库模型映射 (iit_skills)

我们复用并扩展 V2.6 计划中的 iit_skills 表设计:

model IitSkill {
id String @id @default(uuid())
projectId String @map("project_id")
name String // e.g., "入排标准核查"
type String // 'HARD_RULE' | 'LLM_CHECK' | 'HYBRID'

// 触发配置
triggerType String @map("trigger_type") // 'WEBHOOK' | 'CRON' | 'MANUAL'
cronExpr String? @map("cron_expr") // 如果是定时任务

// 核心配置 (JSONB)
// 包含Prompts, JSONLogic, Thresholds
config Json

// 数据依赖 (智能路由用)
// 告诉 ContextBuilder 需要加载哪些 Tag
requiredTags String[] @map("required_tags") // e.g., ['#lab', '#demographics']

isEnabled Boolean @default(true)
createdAt DateTime @default(now())

@@map("iit_skills")
@@schema("iit_schema")
}

🛠️ 五大规则的 Skill 实现方案

我们通过配置不同类型的 Skill 来覆盖 CRA 的所有工作。

1. 变量质控 Skill (Type: HARD_RULE)

对应需求: 针对每个变量,构建数据质控规则。

  • 场景:空值检查、数值范围、逻辑跳转。

  • 配置来源Rule Studio (Layer 1) 自动生成。

  • Config 结构
    {
    "engine": "HardRuleEngine",
    "rules": [
    { "field": "age", "op": "between", "args": [18, 80] },
    { "field": "bmi", "op": "lt", "args": [50] }
    ]
    }

  • 执行Node.js 直接计算,毫秒级响应。

2. 入排标准 Skill (Type: LLM_CHECK)

对应需求: 针对是否符合入排标准,建立医学逻辑规则。

  • 场景:复杂的医学判断(如:病理确诊时间 < 3个月
  • 配置来源Rule Studio (Layer 3) AI 提取 + 人工确认。
  • 数据依赖['#demographics', '#lab', '#history']
  • Config 结构
    {
    "engine": "SoftRuleEngine",
    "model": "deepseek-v3",
    "system_prompt": "你是一个医学监查员...",
    "checks": [
    {
    "id": "I-03",
    "desc": "肝肾功能正常 (ALT/AST < 2.5 ULN)",
    "prompt_template": "基于以下实验室数据 {{#lab}},判断..."
    }
    ]
    }

3. 方案偏离 Skill (Type: HYBRID)

对应需求: 针对是否出现方案偏离,建立核查规则。

  • 场景:访视超窗、漏做检查。
  • 配置来源Rule Studio (Layer 2) 逻辑构建器。
  • Config 结构
    {
    "engine": "HybridEngine",
    "logic": {
    "if": [
    { "date_diff": ["$V2.date", "$V1.date"] },
    { ">": 31 }, // 28 + 3
    "FAIL",
    "PASS"
    ]
    }
    }

4. AE 监测 Skill (Type: LLM_CHECK)

对应需求: 针对是否出现 AE 事件,建立核查规则。

  • 场景SAE ReconciliationLab 异常 vs AE 记录)。
  • 数据依赖['#lab', '#ae']
  • Config 结构
    {
    "engine": "SoftRuleEngine",
    "task": "AE_RECONCILIATION",
    "prompt": "对比 <lab_data> 中的 Grade 3+ 异常值与 <ae_data> 记录,找出未报告的 AE。"
    }

5. 伦理合规 Skill (Type: HARD_RULE)

对应需求: 针对是否出现伦理问题,建立规则。

  • 场景ICF 日期逻辑。
  • Config 结构
    {
    "engine": "HardRuleEngine",
    "rule": {
    "op": "date_before",
    "a": "$icf_date",
    "b": "$first_visit_date"
    },
    "severity": "CRITICAL"
    }

三大触发时机详解 (Trigger Strategy)

我们将质控规则的执行时机划分为“实时、定时、人工”黄金三角,以平衡时效性与成本。

1. 🟢 实时触发 (Real-time / Webhook)

  • 触发源REDCap DET (Data Entry Trigger)。CRC 保存任意表单时触发。
  • 执行范围单点切片 (Micro-Batch)
    • 仅针对 当前受试者 (Current Record)
    • 仅加载 与当前表单相关 的 Skill (通过 formName 过滤)。
    • 例如:录入“血常规”单,系统只检查 #lab 相关规则,不会检查人口学。
  • 核心价值阻断错误。在 CRC 记忆犹新时(秒级)推送企微提醒,纠正成本最低。
  • 成本策略:默认优先跑 Hard Rules。涉及核心安全指标(如 AE时才触发 Soft Rules (LLM)。

2. 🔵 定时触发 (Scheduled / Cron)

  • 触发源pg-boss Cron Job。每日凌晨 (e.g., 02:00) 执行。
  • 执行范围全量扫描 (Full Scan)
    • 针对 所有活跃受试者
    • 重点运行 跨表逻辑 (如一致性检查) 和 时间敏感型规则 (如访视超窗 PD)。
  • 核心价值发现隐患。捕捉“因时间流逝而产生的问题”(如昨天未超窗,今天超窗)和“漏录问题”。
  • 成本策略:使用 增量标记。若数据 Hash 未变且无时间规则,跳过 LLM 检查。

3. 🟠 人工触发 (Manual / On-Demand)

  • 触发源:管理端 "一键全量质控" 或 "单受试者重跑" 按钮。
  • 执行范围按需全量
    • 针对选定的受试者范围。
    • 运行 所有启用 的 Skill。
  • 核心价值合规审计与验证。用于项目初始化清洗、规则调整后的验证、或上级核查前的自查。

🔄 调度与执行Skill Runner

我们不需要为每个规则写死代码,而是实现一个通用的 SkillRunner

执行流程

  1. 触发 (Trigger)
    • Webhook 收到数据 -> 触发 SkillRunner.runByTrigger('WEBHOOK', projectId, recordId, formName)
    • Cron Job 到点 -> 触发 SkillRunner.runByTrigger('CRON', projectId)
    • 人工点击 -> 触发 SkillRunner.runByTrigger('MANUAL', projectId)
  2. 加载 (Load)
    • Runner 从 iit_skills 表加载所有启用的 Skill。
    • 过滤:如果是 WEBHOOK 触发,仅加载与当前 formName 关联的 Skill。
  3. 路由 (Route)
    • 根据 Skill 的 type 分发给对应的 Engine (HardRuleEngine 或 SoftRuleEngine)。
  4. 上下文构建 (Context)
    • 如果需要 LLM调用 ContextBuilder传入 Skill 定义的 requiredTags只拉取相关数据。
  5. 结果聚合 (Aggregate)
    • 收集所有 Skill 的执行结果,存入 iit_qc_logs。

结论:对当前计划的影响

你的 V2.6 开发计划 非常稳健,只需要在细节上明确 Skill 的定义即可。

建议调整:

  1. Phase 1:重点设计 iit_skills 的 JSON Schema确保它能容纳上述 5 种类型的配置。
  2. Phase 2:实现 SkillRunner作为连接 SOP 和 Engine 的中间件。

总结:通过 SKILLS 配置化,你的系统就像一个**“可插拔的乐高玩具”**。

  • 如果明天要加一个“肿瘤评估 (RECIST)”规则,你只需要新增一个 Skill完全不用改后端代码。
  • 这正是 SaaS 化产品的核心竞争力。