AI优化病例报告表：从字段设计到逻辑校验，如何减少人工返工

在去年的三个肿瘤类临床试验 EDC（电子数据采集）建库项目中，CRF（病例报告表）的定稿周期均超出了预期的 4 周。排查项目日志后，我们发现时间主要消耗在版本返工上：试验方案中的非结构化描述导致字段频繁漏项，人工编写的 Edit Checks（逻辑核查）在 UAT（用户验收测试）阶段冲突率居高不下。为解决这一问题，我们将 CRF 抽象为 JSON Schema 结构，引入大语言模型（LLM）解析方案文本，并配合 Python 规则引擎进行静态校验。本文将复盘这一自动化改造过程中的技术选型与字段变更处理细节。

真实痛点：建库日志里的返工重灾区

在翻阅过去的建库问题跟踪单时，CRF 设计阶段的返工主要集中在三个具体的业务场景中。在我们引入新架构进行内部灰度测试后，某常规 II 期项目的建库周期从原来的 28 天缩减至约 12 天，UAT 阶段的逻辑冲突报错率下降了约 75%。这些提升主要源于对以下痛点的针对性处理。

最头疼的是非结构化方案带来的字段漏项问题。试验方案（Protocol）里的入排标准和访视时间表通常是大段的自然语言描述。数据管理员人工拆解时，极容易漏掉特定条件下的伴随用药记录或实验室检查。而且，早期草稿中各家医院的字段命名往往带有强烈的个人习惯，后期在统一对齐 CDASH（临床数据获取标准协调）标准时，免不了要进行大面积的字段名重构和数据迁移。

同时，逻辑核查规则的内部冲突也是 UAT 阶段频繁报错的根源。一份中等规模的 CRF 通常包含数百条交叉校验规则。当多位数据管理员在 Excel 中分头编写规则时，不可避免地会产生逻辑死循环或条件互斥。比如，前置规则要求“男性受试者的妊娠检查项置灰”，而后置的表单级规则又把“妊娠检查结果”设为全局必填，这种隐藏的冲突往往在系统上线测试时才会暴露，导致前端页面卡死或录入受阻。

此外，版本变更（Protocol Amendment）带来的追踪成本往往超出预期。从 V1.0 升级到 V1.1，有时可能只是增加了一个访视点，或调整了某项化验结果的正常值上下限。但如果底层使用的是传统关系型数据库，表结构的频繁增删改会非常笨重。在排查不同版本之间的细微差异时，人工比对 Excel 矩阵极易出现视觉疲劳和遗漏。

核心解法：结构化、AI提取与规则引擎

针对上述工程痛点，破局思路是将 CRF 抽象为强类型的数据结构，并引入自动化流水线进行校验。我们最终的技术选型以 Python 为核心，底层使用 PostgreSQL 的 JSONB 字段存储动态表单，通过 JSON Schema 约束字段定义，并引入 LLM 辅助处理非结构化文本。

整体的数据流转架构如下：

步骤一：用 AI 辅助提炼字段并映射 JSON Schema

LLM 擅长处理非结构化文本，但不适合直接生成供生产环境使用的复杂关系型数据结构。因此，我们将目标收敛为：让 AI 根据给定的 CDASH 标准字典，从文本中提取变量，并严格输出合规的 JSON Schema 格式，作为前端表单渲染的骨架草案。

在实现上，使用 pydantic 结合 OpenAI 的 Structured Outputs 功能，可以有效约束返回格式。核心代码示例如下：

import os
import json
from typing import List, Optional
from pydantic import BaseModel, Field
from openai import OpenAI

# 通过环境变量隐式读取，避免硬编码风险
client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

# 1. 定义期望的 CRF 字段数据模型 (对齐 JSON Schema 核心要素)
class CRFField(BaseModel):
    field_name: str = Field(description="标准的英文字段名，如 BRTHDTC")
    label: str = Field(description="中文显示标签，如 出生日期")
    data_type: str = Field(description="数据类型：string, integer, boolean, date")
    required: bool = Field(description="是否必填")
    options: Optional[List[str]] = Field(default=None, description="下拉框选项列表")
    cdash_domain: str = Field(description="所属 CDASH 域，如 DM, VS, LB")

class CRFForm(BaseModel):
    form_name: str = Field(description="表单名称，如 人口学资料")
    fields: List[CRFField]

# 2. 提取函数
def extract_crf_schema(protocol_text: str) -> str:
    prompt = f"""
    你是一个协助临床数据管理的解析助手。请阅读以下临床试验方案片段，
    提取需要收集的受试者数据字段，并将其映射为符合 CDASH 标准的表单定义。
    
    方案片段：
    {protocol_text}
    """
    
    response = client.beta.chat.completions.parse(
        model="gpt-4o-2024-08-06",
        messages=[
            {"role": "system", "content": "你必须严格输出 JSON 格式的表单定义。"},
            {"role": "user", "content": prompt}
        ],
        response_format=CRFForm,
    )
    
    return response.choices[0].message.content

# 测试执行
protocol_snippet = "受试者入组时需记录其出生年月、性别（男/女）、种族，并确认是否签署知情同意书。"
schema_result = extract_crf_schema(protocol_snippet)
print(json.dumps(json.loads(schema_result), indent=2, ensure_ascii=False))

这套脚本输出的 JSON 数据将直接进入草稿库，省去了数据管理员从 Word 文档复制粘贴并手动敲击拼音首字母缩写的繁琐过程。

步骤二：逻辑校验（Edit Checks）的自动化前置

提取字段只是第一步，系统的稳定性更依赖于严谨的逻辑校验。在我们的架构中，AI 仅用于发现和建议潜在的逻辑规则，而执行校验必须交由确定性的 Python 规则引擎。

通过在设计阶段引入逻辑解析器，我们可以在表单发布前对规则本身进行静态死结检测。为了避免 Python 内置 eval() 带来的执行域安全风险，我们使用 simpleeval 库进行安全的表达式解析：

import simpleeval
from typing import Dict, Any

class LogicCheckEngine:
    def __init__(self, rules: list):
        """
        rules 示例:
        [
            {"id": "CHK01", "expr": "gender == 'Male' and preg_test == 'Done'", "error": "男性不可进行妊娠检查"},
            {"id": "CHK02", "expr": "age < 18", "error": "受试者年龄必须大于等于18岁"}
        ]
        """
        self.rules = rules

    def validate_data(self, data: Dict[str, Any]) -> list:
        errors = []
        for rule in self.rules:
            try:
                # 使用 simpleeval 替代危险的 eval()，仅允许基础数学运算和逻辑判断
                is_triggered = simpleeval.simple_eval(rule['expr'], names=data)
                if is_triggered:
                    errors.append(f"规则 {rule['id']} 触发: {rule['error']}")
            except KeyError:
                # 忽略缺失字段导致的错误，或根据业务需求做标记
                pass
            except Exception as e:
                errors.append(f"解析规则 {rule['id']} 发生异常: {str(e)}")
        return errors

# 模拟数据管理员在系统上设计的校验规则
edit_checks = [
    {"id": "CHK01", "expr": "gender == 'Male' and preg_test == 'Done'", "error": "逻辑冲突：男性受试者无需妊娠检查"},
    {"id": "CHK02", "expr": "age < 18", "error": "越界：受试者年龄必须大于等于18岁"}
]

engine = LogicCheckEngine(edit_checks)

# 模拟注入一个边界测试用例（既是男性又做了妊娠检查）以验证规则有效性
mock_patient_data = {
    "subject_id": "S001",
    "gender": "Male",
    "age": 25,
    "preg_test": "Done"
}

validation_results = engine.validate_data(mock_patient_data)
for issue in validation_results:
    print(issue)

在实际工程中，我们会在 CRF 模版保存阶段向该引擎自动注入预设的各类边界测试用例，验证规则本身是否能够正确触发且互不干扰，从而大幅减少人工 UAT 阶段的排错时间。

步骤三：基于 JSON Diff 的版本比对与变更追踪

为了应对方案的频繁变更，我们将单个表单的完整定义作为一个 JSONB 对象存储在 PostgreSQL 中。这种无模式（Schema-free）的存储方式天然适合应对字段的动态增减。

借助 Python 的 deepdiff 库，我们可以直接在代码层面对表单版本进行细粒度比对，自动生成变更日志（Audit Trail）。

from deepdiff import DeepDiff
import pprint

# V1.0 的 CRF 定义
crf_v1 = {
    "form_name": "Demographics",
    "fields": {
        "BRTHDTC": {"label": "出生日期", "required": True},
        "SEX": {"label": "性别", "options": ["男", "女"]}
    }
}

# V1.1 的 CRF 定义 (方案变更：增加了种族字段，去掉了出生日期必填限制，修改了性别选项)
crf_v2 = {
    "form_name": "Demographics",
    "fields": {
        "BRTHDTC": {"label": "出生年月", "required": False}, 
        "SEX": {"label": "性别", "options": ["男", "女", "未知"]}, 
        "RACE": {"label": "种族", "required": True} 
    }
}

# 执行结构化比对
diff_result = DeepDiff(crf_v1, crf_v2, ignore_order=True)

print("CRF 版本变更报告：")
pprint.pprint(diff_result, indent=2)

前端界面解析 DeepDiff 的输出结果后，可以渲染出类似代码 Diff 的对比视图：新增字段标绿，删除字段标红，修改属性标黄。数据管理员在确认方案变更时，对数据采集范围的变动一目了然。

总结与后续迭代计划

将 AI 解析与规则引擎整合进 CRF 的设计与校验环节，本质上是将人工从跨文档肉眼核对的体力活中解放出来，转变为对代码与规则结构的审核确认。通过结构化的 JSON Schema 构建数据骨架，利用独立规则引擎前置拦截逻辑死循环，再借助 JSON Diff 解决跨版本比对难题，这套机制在近期的项目中已经展现出了明显的效率提升。

在医疗健康这种强监管环境下，系统架构的设计边界必须极其清晰：AI 目前的定位只能是辅助校验和对比，绝对不能直接决定生产环境的数据结构与判定逻辑。任何一个字段的增删、任何一条 Edit Check 的上线，最终的发布口径都必须由具备资质的数据管理员人工确认并保留电子签名。

在下一步的迭代计划中，我们将优先扩充 CDASH 本地标准字典的覆盖度，减少模型推断的偏差。同时，计划在规则引擎中加入基于抽象语法树（AST）的依赖图分析模块，以便在设计器前端实时高亮可能引发链式反应的交叉冲突规则，进一步降低多表单联动校验的维护成本。

本文作者：超能文献团队(https://suppr.wilddata.cn/)