Files

HaHafeng 0b29fe88b5 feat(iit): QC deep fix + V3.1 architecture plan + project member management

QC System Deep Fix:
- HardRuleEngine: add null tolerance + field availability pre-check (skipped status)
- SkillRunner: baseline data merge for follow-up events + field availability check
- QcReportService: record-level pass rate calculation + accurate LLM XML report
- iitBatchController: legacy log cleanup (eventId=null) + upsert RecordSummary
- seed-iit-qc-rules: null/empty string tolerance + applicableEvents config

V3.1 Architecture Design (docs only, no code changes):
- QC engine V3.1 plan: 5-level data structure (CDISC ODM) + D1-D7 dimensions
- Three-batch implementation strategy (A: foundation, B: bubbling, C: new engines)
- Architecture team review: 4 whitepapers reviewed + feedback doc + 4 critical suggestions
- CRA Agent strategy roadmap + CRA 4-tool explanation doc for clinical experts

Project Member Management:
- Cross-tenant member search and assignment (remove tenant restriction)
- IIT project detail page enhancement with tabbed layout (KB + members)
- IitProjectContext for business-side project selection
- System-KB route access control adjustment for project operators

Frontend:
- AdminLayout sidebar menu restructure
- IitLayout with project context provider
- IitMemberManagePage new component
- Business-side pages adapt to project context

Prisma:
- 2 new migrations (user-project RBAC + is_demo flag)
- Schema updates for project member management

Made-with: Cursor

2026-03-01 15:27:05 +08:00

4.8 KiB

Raw Blame History

CRA 质控报告自动化生成与 LLM 友好型设计规范

文档版本：V2.1 (5 层架构剪枝与 LLM 实战版)

设计目标：利用“五层数据坐标剪枝”与“语义组装”，形成对大模型（LLM）极度友好、绝不产生幻觉的 Payload。

核心设计原则：LLM 友好性 (LLM Readiness)

要让 LLM 稳定输出，必须遵循“三不”原则：

不喂全量数据：依托 5 层架构执行 JSON 树剪枝，只提取 status = FAIL 的切片。
不喂物理字段：所有的 lb_alt_v 必须经过 AutoMapper 映射为谷丙转氨酶(ALT)。
不让 LLM 算数：日期差、缺失率由 Node.js 算好，直接把“结论标签”喂给 LLM。

报告生成链路与 LLM 模拟实战 (基于 5 层坐标)

场景一：数据质疑管理 (eQuery Log) - D3 规则

【业务场景】 D3 逻辑发现异常，生成一条像资深 CRA 写的质疑描述。

【剪枝后的 5层 LLM 友好输入片段 ✅】

{
"system_instruction": "你是一个严谨的临床数据经理。请根据下方异常数据，生成一条专业的电子质疑（eQuery）。指出矛盾点并给建议，100字以内。",
"clinical_context": {
"受试者ID": "P005",
"访视阶段": "随访2 (Week 4)",
"触发表单": "实验室检查",
"数据实例": "Instance 1"
},
"anomaly_data": {
"异常指标": "谷丙转氨酶 (ALT)",
"当前录入值": "150 U/L",
"HardRuleEngine_计算结论": "超出正常上限 (50 U/L) 的 3 倍",
"跨表核查结果": "查询《不良事件(AE)表》所有 Instance，当前记录数为 0"
}
}

【LLM 输出示例】

“检测到该受试者在「随访2」的「实验室检查」中，谷丙转氨酶(ALT)为 150 U/L，已超出正常上限 3 倍。经跨表核查，未发现对应的《不良事件(AE)》记录。请核实检验结果是否录入无误；若无误，请评估是否需要补充填报 AE。”

场景二：不良事件风险评估 (AE Log) - D5 规则

【业务场景】 提取录入的 AE，结合患者的其他重复表单（如多次服药），提示风险。

【应对重复表单 (Repeating Forms) 的完美 JSON 结构 ✅】

系统精确拉取 AE_Log 和 ConMed_Log 下的不同 InstanceID：

{
"system_instruction": "作为临床安全评估助手，请分析患者新发的 AE，结合既往病史和用药，提示潜在风险关联。你无权下定论，仅供 PI 参考。",
"patient_context": {
"受试者": "P012",
"合并用药表 (ConMed_Log)": [
{"instance_id": 1, "药物名称": "阿司匹林"},
{"instance_id": 2, "药物名称": "布洛芬"}
]
},
"不良事件表 (AE_Log)": [
{"instance_id": 3, "事件名称": "消化道出血", "严重程度": "CTCAE 3级"}
],
"rag_knowledge_retrieval": "方案规定：非甾体抗炎药（NSAIDs）如布洛芬、阿司匹林联用会显著增加消化道出血风险。"
}

【LLM 输出示例】

“该受试者新发 3 级「消化道出血」(Instance 3)。系统监测到患者正在同时服用「阿司匹林」(Instance 1)与「布洛芬」(Instance 2)。结合方案提示，非甾体抗炎药联用是高危出血因素。建议 PI 重点关注该 AE 是否与合并用药具有因果关系。”

场景三：方案偏离记录 (PD Log) - D6 规则

【喂给 LLM 的切片 ✅】

{
"system_instruction": "请根据硬逻辑引擎计算出的偏差事实，撰写连贯的方案偏离描述，并提出纠正预防措施(CAPA)。",
"deviation_facts": {
"坐标": "Record:P002 -> Event:随访3 -> Form:访视表 -> Instance:1",
"偏离类型": "访视超窗",
"HardRuleEngine_计算依据": {
"方案允许窗口": "2026-02-15 ±3天",
"实际发生日期": "2026-02-25",
"计算结果": "延误 10 天"
}
}
}

场景四：数据缺失率总结 (Missing Rate Log) - D2 规则

【特殊说明：此报告尽量不用 LLM】

数据缺失率表严禁使用 LLM 计算百分比！完全由 Node.js CompletenessEngine 根据 Instance 和分支逻辑动态计算完成。LLM 仅根据最终聚合数值生成执行摘要。

【喂给 LLM 的切片 ✅】

{
"report_type": "数据完整性摘要",
"total_missing_rate": "5.0%",
"top_missing_forms": [
{"form": "SF-36 生活质量问卷", "missing_rate": "40%"}
],
"task": "基于以上统计数据，写两句话的执行摘要。"
}

技术收益总结：

五层架构（特别是 InstanceID 实例层）的引入，让发给 LLM 的 JSON 数据结构具备了完美的数组映射能力，彻底消灭了多行数据相互覆盖的 Bug，并最大程度防范了 AI 幻觉！

4.8 KiB Raw Blame History Unescape Escape