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
47 lines
2.9 KiB
Markdown
47 lines
2.9 KiB
Markdown
# **REDCap 原生录入与 AI Workbench 操作边界划分**
|
||
|
||
针对您的关键问题：“CRC 到底在哪里录入数据？”，我们采取\*\*“双轨并行，场景区分”\*\*的原则。
|
||
|
||
## **1\. 核心策略：尊重“数据真理源”**
|
||
|
||
* **原则**：为了确保 GxP 合规性和维护用户的既有习惯，**REDCap 始终是主要的数据录入入口**。
|
||
* **逻辑**：我们不应该重新发明一个录入界面，而是要在录入时通过 AI 进行“实时监护”。
|
||
|
||
## **2\. 详细场景划分**
|
||
|
||
| 场景 | 操作位置 | AI 的角色 | 理由 |
|
||
| :---- | :---- | :---- | :---- |
|
||
| **常规数据录入** | **REDCap 界面** | **实时监护** | 保持 CRC 习惯，降低迁移成本。AI 通过 Webhook 实时质控。 |
|
||
| **大批量数据导入** | **AI Workbench** | **智能搬运** | 外部 Excel 或多张化验单。AI 清洗后，CRC 确认一次，一键注入。 |
|
||
| **图像/PDF 提取录入** | **AI Workbench** | **OCR 提取** | REDCap 原生不支持复杂的 OCR 解析。在 Workbench 完成提取比对最顺手。 |
|
||
| **质疑(Query)处理** | **AI Workbench** | **冲突展示** | 在 Workbench 可以同屏看“证据原文”和“建议值”，体验远好于 REDCap。 |
|
||
| **项目初始化配置** | **AI Workbench** | **架构定义** | 复杂的 RAG 知识库上传、映射表配置，属于 AI 平台的特有逻辑。 |
|
||
|
||
## **3\. 典型流程对比**
|
||
|
||
### **流程 A：常规录入 (CRC 在 REDCap 操作)**
|
||
|
||
1. CRC 登录 REDCap，打开患者表单。
|
||
2. 输入血红蛋白值：8.0（单位录错）。
|
||
3. 点击保存 \-\> REDCap 写入 MySQL \-\> 触发 Webhook。
|
||
4. 我们的后端感知后，QC Agent 发现逻辑错误。
|
||
5. **反馈**：
|
||
* **低延时提醒**：通过 EM 插件在 REDCap 页面上方显示：“AI 提示：该值偏离历史均值，请确认单位”。
|
||
* **异步质疑**：在我们的 Workbench 生成一条 Pending Action。
|
||
|
||
### **流程 B：AI 增强录入 (CRC 在 Workbench 操作)**
|
||
|
||
1. CRC 收到一张化验单照片。
|
||
2. CRC 登录我们的 Workbench，上传照片。
|
||
3. AI 提取出 10 个指标。
|
||
4. **预览比对**：界面左侧是照片，右侧是提取的表格，高亮显示不确定的值。
|
||
5. **一键注入**：CRC 确认无误，点击“同步”。系统自动调用 REDCap API 将这 10 个值一次性填满 REDCap 表单。
|
||
|
||
## **4\. 结论与思路总结**
|
||
|
||
* **REDCap 登录**：用于\*\*“手动、少量、常规”\*\*的临床记录。
|
||
* **AI Workbench 登录**：用于\*\*“大批量、文档提取、质控确认、方案解析”\*\*的高级任务。
|
||
|
||
这种设计的优势在于：**不强制改变用户习惯，但用 AI 让任务变得更轻松。** 我们不需要做一个完整的 EDC，我们要做的是 EDC 的“智能加速器”。
|
||
|
||
**您认可这个“双轨制”吗？** 特别是关于“大批量和文档提取才去 Workbench”的设定。 |