HaHafeng
66255368b7
Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
106 lines
5.8 KiB
Markdown
106 lines
5.8 KiB
Markdown
# **IIT Manager Agent V4 完整产品需求文档 (全量集成版)**
|
||
|
||
## **1\. 引言**
|
||
|
||
### **1.1 项目背景**
|
||
|
||
在研究者发起的临床试验（IIT）中，数据质量的核心痛点在于“过程失控”。传统的 EDC 系统（如 REDCap）是静态的记录工具。IIT Manager Agent V4 旨在通过“自研逻辑编排 \+ Dify 知识库赋能”，构建一个具有主动意识、实时质控、多端协同的数字科研团队。
|
||
|
||
### **1.2 核心目标**
|
||
|
||
* **主动任务化**：将 Protocol（方案）转化为主动驱动的任务流，而非被动的数据填报。
|
||
* **医疗级合规**：通过“影子状态”机制，确保 AI 建议在进入真理源（REDCap）前经过人类确权。
|
||
* **规模化品牌**：通过“企微中枢 \+ 小程序落地”解决 100+ 项目同时运行时的品牌归属感与触达效率。
|
||
|
||
## **2\. 产品总体架构：原生编排 \+ 外部认知**
|
||
|
||
系统放弃了黑盒 Agent 框架，采用\*\*“大脑与图书馆”\*\*分离的架构：
|
||
|
||
* **逻辑大脑 (Node.js \+ pg-boss)**：位于后端，负责状态机流转、影子数据处理、权限校验及异构系统调度。
|
||
* **知识图书馆 (Dify RAG)**：负责非结构化文档（方案、指南、手册）的解析与向量检索，作为 AI 的认知增强。
|
||
|
||
## **3\. 终端与角色矩阵 (Endpoint & Role Matrix)**
|
||
|
||
系统通过“基础角色 \+ 扩展权限”模式，实现跨终端的紧密协作。
|
||
|
||
| 角色 | 核心诉求 | 推荐终端 | 核心交互逻辑 |
|
||
| :---- | :---- | :---- | :---- |
|
||
| **项目负责人 (PI)** | 宏观进度、合规审批、学术报表 | **企业微信 (通知) \+ 微信小程序 (查看)** | 接收企微通知，在小程序查看品牌化报表并审批 |
|
||
| **协调员 (CRC)** | 录入数据、复核建议、管理随访 | **REDCap (录入) \+ PC Workbench (复核)** | 尊重 REDCap 录入习惯，在工作站处理 AI 质疑 |
|
||
| **患者 (受试者)** | 访视提醒、依从性引导、医学咨询 | **个人微信 (H5/小程序)** | 接收由 Agent 以 CRC 名义发送的企微消息 |
|
||
| **系统管理员** | 项目初始化、规则配置、RAG 维护 | **PC 端 (Admin Portal)** | 数字化方案、配置字段映射、管理多租户 |
|
||
|
||
## **4\. 核心功能模块与 Agent 矩阵**
|
||
|
||
### **4.1 数据质控 Agent (严谨的监察员)**
|
||
|
||
* **逻辑**：通过 Webhook 监听 REDCap 录入 \-\> 调用 Dify 检索方案规则 \-\> 发现逻辑冲突 \-\> 生成影子质疑 (Pending Action)。
|
||
* **参数**：Temperature \= 0，追求极致确定性。
|
||
|
||
### **4.2 任务驱动引擎 (数字指挥官)**
|
||
|
||
* **逻辑**：根据项目初始化定义的 Visit Schedule 计算访视窗 \-\> 触发 pg-boss 延时任务 \-\> 自动发送微信提醒。
|
||
|
||
### **4.3 患者随访 Agent (温暖的协调员)**
|
||
|
||
* **逻辑**：基于 RAG 知识库回复患者咨询 \-\> 识别 SAE 风险 \-\> 自动提醒 CRC 介入接管。
|
||
* **参数**：Temperature \= 0.7，保持医学严谨的同时具有亲和力。
|
||
|
||
### **4.4 汇报 Agent (智能汇报者)**
|
||
|
||
* **逻辑**：自动汇总 REDCap 进度数据 \-\> 生成智能报表草稿 \-\> 推送至 PI 微信确认。
|
||
|
||
## **5\. 操作边界：双轨并行原则**
|
||
|
||
为了降低推广阻力，系统明确划分了 REDCap 与 Workbench 的操作边界：
|
||
|
||
* **REDCap 原生录入**：
|
||
* **场景**：手动、少量、常规的临床数据录入。
|
||
* **AI 表现**：后台静默质控，仅通过 EM 插件在页面顶端显示微提醒。
|
||
* **AI Workbench**：
|
||
* **场景**：化验单 OCR 批量采集、AI 建议的深度复核（同屏对比证据链）、多中心映射配置。
|
||
* **AI 表现**：作为主要处理界面，展示推理过程与原文引用。
|
||
|
||
## **6\. 核心机制：影子状态机 (Shadow State)**
|
||
|
||
所有 AI 建议必须经过以下生命周期，严禁 AI 直接修改 REDCap 数据：
|
||
|
||
1. **PROPOSED (影子建议)**：Agent 发现问题，记录于 pending\_actions 表，包含引用页码及推理逻辑。
|
||
2. **APPROVED (人类确权)**：CRC 在 Workbench 点击“确认”或 PI 在小程序点击“审批”。
|
||
3. **EXECUTED (正式执行)**：系统通过 EDC Adapter 调用 API 回写至 REDCap，并生成审计日志。
|
||
|
||
## **7\. 规模化部署与微信集成方案**
|
||
|
||
针对“100 个项目、47 家医院”的规模化场景：
|
||
|
||
### **7.1 通知中枢 (企业微信)**
|
||
|
||
* 使用壹证循统一认证的企微主体作为“推送管道”。
|
||
* 针对每个研究项目创建“自建应用”，应用名可设置为“XX 项目研究组”，降低商业感。
|
||
|
||
### **7.2 品牌落地 (小程序)**
|
||
|
||
* PI/CRC 从企微卡片跳转至微信小程序。
|
||
* **动态渲染**：小程序根据 project\_id 自动加载对应医院的 Logo、主题色和项目名称，给足 PI“学术归属感”。
|
||
|
||
## **8\. 技术底座与安全合规**
|
||
|
||
### **8.1 基础设施**
|
||
|
||
* **数据库**：Postgres-Only 架构，利用 iit\_schema 实现物理隔离。
|
||
* **集成层**：REDCap External Module (EM) 侧挂插件 \+ Node.js REST API 适配器。
|
||
|
||
### **8.2 安全与 GxP**
|
||
|
||
* **Token 安全**：所有 REDCap API Token 使用 AES-256-GCM 高强度加密存储。
|
||
* **脱敏引擎**：上下文进入 LLM 前，本地网关执行 PII（个人身份信息）自动脱敏。
|
||
* **审计链**：记录从 AI 推理原文到人类点击确权的全链路 TraceID。
|
||
|
||
## **9\. 实施阶段计划**
|
||
|
||
* **Phase 1 (连接)**：打通 REDCap Webhook 与 Node.js，上线微信周报确认功能。
|
||
* **Phase 2 (协同)**：上线 PC Workbench 核心组件，实现质控影子建议的闭环。
|
||
* **Phase 3 (增强)**：集成 Python 微服务的 OCR/DC 模块，开启智能化数据采集。
|
||
* **Phase 4 (生态)**：完成 100+ 项目规模化配置方案，预研 AI 原生 SmartEDC。
|
||
|
||
**文档版本**：V4.0 Final | **更新日期**：2025-12-30 | **作者**：产品架构团队 |