# 项目愿景

## 一、核心目标

`chisup` 要解决第三方体检系统向基卫 CHIS 上报数据时，登录、会话、格式转换、错误处理和重复提交都难以稳定维护的问题。

> 让第三方系统只按约定提交业务数据，由 `chisup` 负责 CHIS 会话和 CHIS 接口格式细节。

它不是 CHIS 替代系统，也不是前端自动化脚本，而是一个面向第三方系统的后端中间服务。

## 二、目标用户

- 第三方业务系统：通过 API 提交体检数据，不直接理解 CHIS 前端接口细节。
- 项目维护人员：维护 CHIS 登录、会话、字段映射和问题排查。
- 医卫业务实施人员：通过稳定接口减少重复录入和手工导入成本。

## 三、产品原则

- 核心闭环优先：先跑通单条体检上报，再扩展更多业务类型。
- 真实接口优先：字段、接口、错误码以实际 CHIS 请求和响应为准。
- 安全优先：账号、密码、Cookie、身份证号、体检数据必须脱敏处理。
- 会话复用优先：不要每次请求都登录 CHIS；优先复用有效 Redis 会话。
- 可追踪：每次上报要能通过 trace_id 查到入参摘要、转换结果、CHIS 请求结果和错误原因。
- 可维护：view、service、mapper、CHIS client、auth、repository 边界清晰。

## 四、核心价值主张

| 价值点 | 说明 |
| --- | --- |
| 降低接入成本 | 第三方不需要直接适配 CHIS 复杂请求格式 |
| 提高稳定性 | 统一处理 CHIS 登录、会话失效、重登、错误翻译 |
| 避免重复提交 | 通过幂等键控制第三方重试导致的重复体检记录 |
| 便于排查 | 统一日志、错误码和请求流水，减少线上问题定位成本 |

## 五、不做什么（非目标）

- 不绕过 CHIS 的账号权限、角色、机构和审计规则。
- 不保存真实明文 CHIS 密码到代码、文档或日志。
- 不直接写 CHIS 数据库。
- 不在 MVP 做可视化管理后台。
- 不一次性覆盖 CHIS 全部业务模块；先完成体检上报闭环。