HaHafeng
0b29fe88b5
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
106 lines
4.8 KiB
Markdown
106 lines
4.8 KiB
Markdown
# **CRA 质控报告自动化生成与 LLM 友好型设计规范**
|
||
|
||
**文档版本**：V2.1 (5 层架构剪枝与 LLM 实战版)
|
||
|
||
**设计目标**：利用“五层数据坐标剪枝”与“语义组装”，形成对大模型（LLM）极度友好、绝不产生幻觉的 Payload。
|
||
|
||
## **核心设计原则：LLM 友好性 (LLM Readiness)**
|
||
|
||
要让 LLM 稳定输出，必须遵循“三不”原则：
|
||
|
||
1. **不喂全量数据**：依托 5 层架构执行 JSON 树剪枝，只提取 status \= FAIL 的切片。
|
||
2. **不喂物理字段**：所有的 lb\_alt\_v 必须经过 AutoMapper 映射为 谷丙转氨酶(ALT)。
|
||
3. **不让 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 幻觉！ |