# 复诊管理接口适配方案

本文档旨在分析后端提供的复诊管理接口，并提出前端适配方案，以确保前后端协同工作。

## 后端接口分析

根据后端提供的接口设计，复诊管理功能包含以下接口：

1. **创建复诊请求接口**
   - URL: POST /follow-up/create
   - 应用场景: 患者创建复诊预约请求
   - 详细描述: 患者选择医生并指定预约时间，提交复诊申请，系统默认状态为"PENDING"(待确认)

2. **更新复诊记录接口**
   - URL: PUT /follow-up/{id}
   - 应用场景: 更新复诊记录（医生确认、取消或患者修改）
   - 详细描述: 
     - 医生可以确认、取消或完成复诊
     - 患者可以修改自己待确认的复诊请求
     - 当状态更新为"COMPLETED"时，系统会自动记录实际就诊时间

3. **分页查询复诊记录接口**
   - URL: POST /follow-up/list
   - 应用场景: 根据时间范围和分页参数查询复诊记录
   - 详细描述:
     - 患者查看自己的复诊记录
     - 医生查看分配给自己的复诊记录
     - 系统管理员查看所有复诊记录

4. **医生分页查询患者复诊记录接口**
   - URL: POST /follow-up/list-by-patient
   - 应用场景: 医生查询特定患者的复诊记录（需有绑定关系或权限）
   - 详细描述:
     - 医生查看患者的复诊历史
     - 系统管理员查看任何患者的复诊记录

5. **删除复诊记录接口**
   - URL: DELETE /follow-up/{id}
   - 应用场景: 根据ID删除复诊记录
   - 详细描述:
     - 患者删除自己待确认的复诊请求
     - 仅允许患者本人删除自己的复诊记录

## 前端适配方案

### 1. API模块设计

需要创建一个新的API模块 `src/api/followUp.ts` 来封装所有复诊相关接口调用。

#### 接口映射关系：

| 原设计接口 | 新接口 | 方法名 |
|-----------|--------|--------|
| POST /followup/invite | POST /follow-up/create | createFollowUp |
| POST /followup/accept | PUT /follow-up/{id} | updateFollowUp |
| POST /followup/decline | PUT /follow-up/{id} | updateFollowUp |
| GET /followup/list | POST /follow-up/list | getFollowUpList |
| GET /appointment/list | POST /follow-up/list | getFollowUpList |
| POST /appointment/create | POST /follow-up/create | createFollowUp |

### 2. 数据模型定义

需要定义相应的数据模型来匹配接口数据格式：

```typescript
// 复诊记录实体
interface FollowUp {
  id: number;
  patientUserId: number;
  doctorUserId: number;
  scheduledTime: string; // 预约时间
  actualTime?: string;   // 实际就诊时间
  status: 'PENDING' | 'CONFIRMED' | 'CANCELLED' | 'COMPLETED'; // 状态
  remark?: string;       // 备注
  createdAt: string;     // 创建时间
  updatedAt: string;     // 更新时间
}

// 分页查询参数
interface FollowUpQueryParams {
  patientUserId?: number;
  doctorUserId?: number;
  status?: 'PENDING' | 'CONFIRMED' | 'CANCELLED' | 'COMPLETED';
  startTime?: string;
  endTime?: string;
  current?: number;
  size?: number;
}

// 创建复诊请求参数
interface CreateFollowUpRequest {
  doctorUserId: number;
  scheduledTime: string;
  remark?: string;
}

// 更新复诊请求参数
interface UpdateFollowUpRequest {
  status: 'PENDING' | 'CONFIRMED' | 'CANCELLED' | 'COMPLETED';
  scheduledTime?: string;
  actualTime?: string;
  remark?: string;
}
```

### 3. 页面功能调整

#### 医生端功能调整

1. **医生首页(todayReminders.followUpCount)**
   - 继续使用现有接口获取待处理复诊数量
   - 需要确认是否仍使用 `GET https://wx.baiyun.work/doctor/today_reminders`

2. **我的病人(inviteRevisit)**
   - 将原来的占位功能改为实际调用新接口
   - 使用 `createFollowUp` 方法创建复诊请求
   - 弹窗需要包含时间选择器和备注输入框

3. **复诊管理列表(/pages/doctor/manage/followup)**
   - 使用 `getFollowUpList` 获取复诊记录列表
   - 支持按状态筛选(PENDING, CONFIRMED, COMPLETED, CANCELLED)
   - 支持查看详情和操作(确认、取消、完成)

#### 患者端功能调整

1. **我的医生(makeAppointment)**
   - 将原来的占位功能改为实际调用新接口
   - 使用 `createFollowUp` 方法创建复诊请求
   - 弹窗需要包含医生选择、时间选择器和备注输入框

2. **患者复诊记录列表**
   - 使用 `getFollowUpList` 获取自己的复诊记录
   - 支持查看详情和修改待确认的复诊请求
   - 支持删除自己待确认的复诊请求

#### 家属端功能调整

1. **我的家人(inviteRevisit)**
   - 与医生端类似，改为实际调用新接口
   - 使用 `createFollowUp` 方法创建复诊请求

### 4. 状态管理和权限控制

1. **状态转换规则**
   - PENDING -> CONFIRMED (医生确认)
   - PENDING -> CANCELLED (医生或患者取消)
   - CONFIRMED -> COMPLETED (医生标记完成，并记录实际就诊时间)
   - CONFIRMED -> CANCELLED (医生或患者取消)

2. **权限控制**
   - 患者只能操作自己的复诊记录
   - 医生只能操作分配给自己的复诊记录
   - 只有患者能删除自己待确认的复诊请求
   - 状态更新需要符合状态转换规则

### 5. 异常处理和用户体验优化

1. **异常值提醒增强**
   - 在健康数据异常提醒中增加"立即预约"按钮
   - 点击后跳转到预约页面或弹出预约表单

2. **实时更新机制**
   - 复诊状态变更后，及时更新相关页面和提醒数量
   - 考虑使用WebSocket或轮询机制实现实时更新

## 待办事项清单

- [ ] 创建 `src/api/followUp.ts` API模块
- [ ] 定义相关数据模型和接口类型
- [ ] 修改医生端"邀请复诊"功能，替换为实际接口调用
- [ ] 修改患者端"预约复诊"功能，替换为实际接口调用
- [ ] 修改家属端"邀请复诊"功能，替换为实际接口调用
- [ ] 创建医生复诊管理列表页面 (`/pages/doctor/manage/followup`)
- [ ] 创建患者复诊记录列表页面
- [ ] 实现复诊详情查看和状态更新功能
- [ ] 增强异常值提醒中的预约功能
- [ ] 添加适当的加载状态和错误处理

## 总结

新的后端接口设计更加规范化和完整化，提供了完整的复诊生命周期管理。前端需要相应地调整接口调用方式和业务逻辑实现，同时保持良好的用户体验。重点关注状态管理和权限控制，确保数据安全和操作合规性。