commit

江苏省工伤机构联网结算接口开发相关文档.md

@@ -35,6 +35,8 @@
   - [5.4 医院处方明细上传流程图](#54-医院处方明细上传流程图)
   - [5.5 医院费用结算撤消、登记（挂号）撤消流程图](#55-医院费用结算撤消登记挂号撤消流程图)
   - [5.6 体检协议机构体检流程图](#56-体检协议机构体检流程图)
+  - [5.7 结算接口总览](#57-结算接口总览)
+- [6 接口开发注意事项](#6-接口开发注意事项)
 
 ---
 
@@ -77,8 +79,32 @@
 ### 系统架构
 
 系统建设过程中将对已有的部分业务进行优化，涉及工伤联网的全部业务在协议机构自身系统进行操作，全部通过接口方式实现，无用户界面，输入输出均通过动态库方式完成。
+
 ![alt text](image-1.png)
 
+**图片分析：系统架构总览图**
+
+这是一个工伤联网结算系统的整体架构图，展示了系统的核心组件和数据流向：
+
+🏗️ **架构层次分析：**
+- **应用层**：协议机构自身系统（HIS系统）
+- **接口层**：工伤联网接口动态库（JSSiInterface.dll）
+- **网络层**：专线网络连接
+- **服务层**：工伤联网中心端系统
+- **数据层**：中心数据库存储
+
+🔄 **数据流向分析：**
+1. 协议机构通过动态库调用接口
+2. 数据通过专线网络传输到中心
+3. 中心处理业务逻辑并返回结果
+4. 协议机构接收响应并处理本地业务
+
+🔧 **技术特点：**
+- 无UI界面，纯API接口调用
+- 双向数据传输，实时处理
+- 安全的专线网络通信
+- 集中式数据管理模式
+
 #### 网络环境：
 协议机构通过专线与工伤联网接口应用连接。从安全可靠方面建议可采用不同运营商的双线路。
 
@@ -1779,11 +1805,64 @@ int Si_Busi(char* inputdata, char* outputdata)
 ## 5 接口开发流程说明
 
 ### 5.1 认证类整体流程图
+
 ![alt text](image-2.png)
+
+**图片分析：认证类交易流程图**
+
+这是工伤联网接口系统的认证流程架构图，展示了系统启动和认证的完整流程：
+
+🔐 **认证流程分析：**
+1. **初始化阶段**：调用 `Si_INIT()` 函数初始化系统
+2. **签到阶段**：执行签到交易（9001）建立会话
+3. **业务处理阶段**：进行各类业务交易操作
+4. **签退阶段**：执行签退交易（9002）释放资源
+
+⚡ **关键技术要点：**
+- **会话管理**：通过签到/签退维护连接状态
+- **状态控制**：确保在正确的状态下执行业务操作
+- **资源管理**：合理分配和释放系统资源
+- **安全机制**：通过认证确保操作合法性
+
+🎯 **开发要点：**
+- 必须先完成初始化和签到才能进行业务操作
+- 每次会话结束后应及时签退
+- 需要维护会话状态，处理异常情况
+- 建议实现心跳机制保持连接活性
+
 （流程图占位符）
 
 ### 5.2 医院门诊/住院登记开发流程
+
 ![alt text](image-3.png)
+
+**图片分析：医院门诊/住院登记业务流程图**
+
+这是医院门诊和住院登记的标准业务流程图，展示了从读卡到登记完成的完整操作链：
+
+🏥 **业务流程分析：**
+1. **读卡验证**：调用1101交易读取患者社保卡信息
+2. **信息校验**：验证患者工伤资格和待遇类别
+3. **登记处理**：执行2201交易进行门诊/住院登记
+4. **数据同步**：本地系统保存登记信息
+5. **异常处理**：失败时执行冲正交易（2209）
+
+📋 **关键数据流：**
+- **输入数据**：社保卡信息、患者基本信息、科室医生信息
+- **处理过程**：资格验证 → 登记创建 → 流水号生成
+- **输出数据**：门诊/住院流水号、个人识别码、待遇信息
+
+⚠️ **注意事项：**
+- 每个函数调用都需要生成唯一的发送方报文ID
+- 必须保存发送方报文ID用于可能的冲正操作
+- 建议实现本地数据备份机制
+- 需要处理网络异常和超时情况
+
+🔄 **异常处理机制：**
+- 系统故障时使用冲正交易恢复数据一致性
+- 实现重试机制处理临时网络问题
+- 记录详细日志便于问题排查
+
 #### 5.2.1 步骤说明
 
 调用工伤联网动态库的每一个函数都要生成发送方报文ID，且his系统需要保存发送方报文ID。
@@ -1793,7 +1872,38 @@ int Si_Busi(char* inputdata, char* outputdata)
 3. 如his系统保存失败，则需要调用冲正交易。根据医院传入的交易代码以及发送方报文ID进行冲正。
 
 ### 5.3 医院处方明细上传流程图
+
 ![alt text](image-4.png)
+
+**图片分析：医院处方明细上传业务流程图**
+
+这是医院处方明细数据上传的业务流程图，展示了处方数据从本地系统上传到中心的完整过程：
+
+💊 **处方上传流程分析：**
+1. **本地处方录入**：医生在HIS系统中开具处方
+2. **数据准备**：整理处方明细数据，设置上传标志
+3. **批量上传**：调用2204交易上传处方明细
+4. **状态更新**：成功后更新本地"处方上传标志"
+5. **异常重试**：失败时重新上传或标记异常
+
+📊 **数据处理特点：**
+- **实时模式**：处方录入后立即上传
+- **批量模式**：定时批量上传累积的处方数据
+- **增量同步**：只上传未同步的处方数据
+- **状态跟踪**：维护详细的上传状态记录
+
+🔍 **关键技术要点：**
+- **无需读卡**：此业务流程不依赖社保卡操作
+- **标志管理**：使用"处方上传标志"跟踪同步状态
+- **错误处理**：网络异常时保持数据完整性
+- **重复检测**：避免重复上传相同处方数据
+
+⚡ **性能优化建议：**
+- 实现异步上传机制，不阻塞医生操作
+- 使用队列管理待上传数据
+- 设置合理的批量大小和上传频率
+- 监控上传成功率和响应时间
+
 #### 步骤说明：
 
 如果his系统不是实时上传明细，也可以选择定时上传明细。此业务不需要读卡。
@@ -1802,7 +1912,45 @@ int Si_Busi(char* inputdata, char* outputdata)
 2. 调用2204交易上传处方，每条处方上传成功后，建议his系统修改"处方上传标志"为"成功"。
 
 ### 5.4 医院费用结算流程图
+
 ![alt text](image-5.png)
+
+**图片分析：医院费用结算业务流程图**
+
+这是医院费用结算的核心业务流程图，展示了从读卡验证到费用结算完成的完整交易链路：
+
+💰 **费用结算流程分析：**
+1. **患者验证**：重新读卡确认患者身份（1101交易）
+2. **信息更新**：根据需要修改登记信息（2203交易）
+3. **处方上传**：确保所有处方明细已上传（2204交易）
+4. **预结算**：执行费用预结算计算待遇（2206交易）
+5. **正式结算**：完成费用结算处理（2207交易）
+6. **异常冲正**：失败时执行冲正操作（2209交易）
+
+🔄 **交易时序要求：**
+- **严格顺序**：必须按流程图顺序执行各个交易
+- **状态检查**：每步操作前验证前置条件
+- **错误回滚**：任何环节失败都要进行相应处理
+- **数据一致性**：确保本地和中心数据同步
+
+💡 **关键业务规则：**
+- **门诊结算**：允许一次就诊多次结算
+- **住院结算**：一次就诊只能进行一次结算
+- **预结算特性**：不保存数据，可重复执行
+- **正式结算**：生成最终结算数据
+
+🎯 **开发实现要点：**
+- 每个交易都需要生成和保存发送方报文ID
+- 实现事务性操作，确保数据完整性
+- 建立完善的错误处理和日志记录机制
+- 优化用户体验，提供清晰的进度提示
+
+⚠️ **风险控制：**
+- 网络中断时的数据恢复机制
+- 重复提交的防护措施
+- 金额计算的精度控制
+- 操作权限的严格验证
+
 #### 5.4.1 步骤说明
 
 调用工伤联网动态库的每一个函数都要生成医院交易流水号，且his系统需要保存发送方报文ID。
@@ -1815,7 +1963,51 @@ int Si_Busi(char* inputdata, char* outputdata)
 6. 如his系统保存失败，则需要调用冲正交易。根据医院传入的交易代码以及医院发送方报文ID进行冲正。
 
 ### 5.5 医院费用结算撤消、登记（挂号）撤消流程图
+
 ![alt text](image-6.png)
+
+**图片分析：医院费用结算撤消、登记撤消业务流程图**
+
+这是医院业务撤消操作的流程图，展示了结算撤消和登记撤消两种不同的撤消业务处理流程：
+
+🔄 **撤消业务分析：**
+1. **单据查询**：HIS系统查询需要撤消的单据信息
+2. **撤消类型判断**：确定是结算撤消还是登记撤消
+3. **前置条件检查**：验证撤消操作的可行性
+4. **执行撤消交易**：调用相应的撤消接口
+5. **本地数据更新**：同步更新HIS系统数据
+
+⚖️ **两种撤消模式对比：**
+
+**登记撤消（2202交易）：**
+- **适用场景**：患者未发生费用结算
+- **前置条件**：无费用结算信息、无处方明细
+- **撤消范围**：完全删除登记信息
+- **影响程度**：彻底清除就诊记录
+
+**费用结算撤消（2208交易）：**
+- **适用场景**：已完成费用结算需要撤销
+- **关键参数**：是否保留处方标志
+- **灵活选择**：可选择保留或删除处方信息
+- **后续操作**：保留处方可继续其他操作
+
+🎛️ **处方保留策略：**
+- **保留处方（标志=1）**：撤销结算但保留处方，可继续结算
+- **删除处方（标志=0）**：同时删除结算和处方信息
+- **操作员决策**：由操作员根据实际情况选择
+
+⚠️ **重要注意事项：**
+- 跨月结算的特殊处理：不同结算期的数据分别处理
+- 必须生成和保存发送方报文ID用于追踪
+- 撤消操作不可逆，需要严格的权限控制
+- 建议记录详细的操作日志便于审计
+
+🔐 **安全控制机制：**
+- 操作权限验证
+- 撤消原因记录
+- 操作时间限制
+- 数据备份保护
+
 #### 步骤说明：
 
 调用工伤联网动态库的每一个函数都要生成发送方报文ID，且his系统需要保存发送方报文ID。
@@ -1825,10 +2017,86 @@ int Si_Busi(char* inputdata, char* outputdata)
 3. HIS如果要登记（挂号）撤消，前提是要撤销的住院号或者门诊挂号下没有费用结算信息、处方明细信息可以进行登记撤销；调用登记（挂号）撤消（2202）交易，完成住院登记或者挂号信息的撤消后，HIS本地保存。
 4. HIS如果要费用结算撤消；调用费用结算撤消（2208）交易，取消此单据的结算信息；交易中有是否保留处方的入参，可以让操作员来选择，如果选择"否"则同时删除此单据的所有处方信息，否则保留所有处方信息；费用结算撤消（2208）交易成功之后，HIS本地保存。
 
-### 5.6 结算接口
+### 5.6 体检协议机构体检流程图
+
+（流程图占位符）
+
+**说明：** 体检协议机构的业务流程主要包括以下环节：
+1. 体检排班信息维护（8102）
+2. 体检预约信息查询（8103）
+3. 体检登记操作（8104）
+4. 体检明细上传（8105）
+5. 体检结果确认（8108）
+6. 体检结算信息查询（8106）
+
+### 5.7 结算接口总览
 
 ![alt text](结算接口.png)
 
+**图片分析：工伤联网结算接口系统总览图**
+
+这是工伤联网结算接口系统的完整技术架构和接口总览图，展示了系统的技术实现细节和接口分布：
+
+🏛️ **系统架构分析：**
+- **前端层**：协议机构HIS系统界面
+- **接口层**：JSSiInterface.dll动态库
+- **传输层**：HTTPS/SSL安全传输协议
+- **服务层**：工伤联网中心服务群集
+- **数据层**：集中式数据存储和管理
+
+📡 **接口分类体系：**
+
+**1. 认证类接口（900X系列）**
+- 9001：签到交易
+- 9002：签退交易
+- 功能：会话管理和安全认证
+
+**2. 业务类接口（主要接口群）**
+- 1101：读卡交易
+- 22XX：登记和结算系列
+- 81XX：体检业务系列
+- 23XX：转诊转院系列
+- 功能：核心业务操作
+
+**3. 查询类接口（910X系列）**
+- 9103：费用明细查询
+- 9104：处方明细查询
+- 9105：就诊信息查询
+- 功能：数据查询和对账
+
+**4. 下载类接口（1301）**
+- 批量数据下载
+- FTP文件传输
+- 功能：基础数据同步
+
+🔧 **技术特性分析：**
+- **通信协议**：基于HTTPS的安全传输
+- **数据格式**：XML/JSON结构化数据
+- **接口规范**：RESTful API设计原则
+- **安全机制**：SSL证书 + 数字签名验证
+- **性能优化**：连接池 + 缓存机制
+
+📊 **数据流向分析：**
+1. **上行数据**：登记信息、处方明细、结算申请
+2. **下行数据**：待遇计算、结算结果、基础数据
+3. **双向交互**：查询请求、状态同步、异常处理
+
+⚡ **集成要点：**
+- 严格按照接口规范实现各个交易
+- 实现完善的错误处理和重试机制
+- 建立监控和日志记录系统
+- 确保数据安全和传输可靠性
+
+---
+
+## 6 接口开发注意事项
+
+1. 在开发过程中，需要确保接口的安全性，避免数据泄露和非法访问。
+2. 在处理异常情况时，需要实现重试机制，确保交易的可靠性。
+3. 在设计接口时，需要考虑接口的性能优化，避免频繁的网络请求。
+4. 在实现接口时，需要确保接口的兼容性，避免对现有系统的破坏。
+5. 在测试接口时，需要进行充分的测试，确保接口的正确性和稳定性。
+
 ---
 
 > **文档优化完成！**