Files

HaHafeng 66255368b7 feat(admin): Add user management and upgrade to module permission system

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

2026-01-16 13:42:10 +08:00

5.8 KiB

Raw Blame History

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 数据：

PROPOSED (影子建议)：Agent 发现问题，记录于 pending_actions 表，包含引用页码及推理逻辑。
APPROVED (人类确权)：CRC 在 Workbench 点击“确认”或 PI 在小程序点击“审批”。
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 | 作者：产品架构团队

5.8 KiB Raw Blame History Unescape Escape