design.md 4.2 KB
Context
DRG算法配置是医保控费系统的核心基础数据管理模块，目前仅支持单条数据的增删改查操作。随着DRG分组规则的调整和医疗机构基础数据的更新，需要频繁维护大量DRG算法数据（DRG代码、描述、基准点数、预估点值、病组差异系数、支付标准等）。
当前系统已实现ICD编码查询菜单的导入功能，采用前后端分离架构：前端提供导入模板下载和Excel上传功能，后端提供查询列表、验证数据、保存数据三个接口服务。本次需求参考该实现模式，为DRG算法配置菜单增加导入功能。
Goals / Non-Goals
Goals:
- 提供DRG算法数据的标准Excel导入模板下载功能
- 实现Excel文件的解析、数据校验和批量导入
- 导入时关联省、市行政区划和医疗机构信息
- 后端采用operatetable方式操作HB_DRGCoreAlgorithmData表
- 与现有ICD编码导入保持一致的交互体验和架构风格
Non-Goals:
- 不支持增量更新（重复数据按新增处理，由业务层决定覆盖策略）
- 不实现复杂的Excel格式校验（仅校验必填字段和数据类型）
- 不涉及DRG分组逻辑算法的修改
Decisions
1. 后端接口设计采用三层架构模式
参考ICD编码导入实现，后端提供三个独立的接口服务：
- Query接口：查询已存在的DRG算法数据列表，用于前端展示导入结果
- Validate接口：校验导入数据的合法性（必填字段、数据格式、重复性）
- Save接口：保存校验通过的数据到HB_DRGCoreAlgorithmData表
Rationale：三层分离便于前端实现分步导入流程（上传→校验→确认保存），提高用户体验。
2. 数据更新采用operatetable方式
使用InterSystems IRIS的operatetable方法直接操作数据库表，而非通过对象映射。
Rationale：批量数据导入场景下，operatetable性能优于对象映射方式，且便于处理大批量数据的事务控制。
3. 行政区划和医疗机构关联策略
导入弹框要求用户必选省、市、医疗机构，前端获取对应代码后随导入数据一并提交：
- 市接口返回值中的Code作为MdtrtArea（行政区划代码）
- 医疗机构接口返回的OrganizationCode作为FixmedinsCode（机构代码）
- 医疗机构接口返回的Descripts作为FixmedinsName（机构名称）
- 医疗机构接口返回的HospGrade_Dr作为MedinsLv（机构等级）
Rationale：DRG算法数据与行政区划和医疗机构强相关，通过前置选择确保数据归属准确，避免导入后数据混乱。
4. Excel模板字段设计
模板包含6个核心字段： | 字段名 | 含义 | 说明 | |--------|------|------| | DRGCode | DRG代码 | 必填，唯一标识 | | DRGDesc | DRG描述 | 必填 | | Points | 基准点数 | 必填，数值型 | | PipValue | 预估点值 | 必填，数值型 | | DGDOV | 病组差异系数 | 必填，数值型 | | PayStandard | 支付标准 | 必填，数值型 |
Rationale：覆盖DRG算法核心要素，满足基础数据配置需求。
Risks / Trade-offs
| 风险 | 缓解措施 |
|---|---|
| 大批量导入可能导致性能问题 | 限制单次导入最大行数（如1000行），超出分批处理 |
| Excel格式不标准导致解析失败 | 提供标准模板下载，模板中包含数据示例和格式说明 |
| 重复数据导入导致数据冗余 | Validate接口校验重复性，前端展示重复数据提示，由用户确认是否覆盖 |
| 行政区划或医疗机构选择错误 | 弹框中省、市、医疗机构为必选，未选择时禁用导入按钮 |
Migration Plan
- 后端开发：创建三个接口服务类（Query、Validate、Save）
- 前端开发：在DRG算法配置页面增加导入按钮和导入弹框组件
- 接口联调：前后端联调，验证数据流转正确性
- 测试验证：功能测试、性能测试、边界场景测试
- 上线部署：无数据迁移需求，直接部署新版本
Open Questions
- 是否需要支持导入数据的修改（覆盖）功能？
- 单次导入的最大行数限制为多少合适？
- 导入失败的数据是否需要提供导出功能便于用户修正后重新导入？