T/CBA 101-2019(R[0]2022) 银医服务接口技术规范

　　ICS 03.060 ; 03.080.30 A11

　　CBA

　　团 体 标 准

　　T/CBA 101—2019 (R[0]2022)

　　银医服务接口技术规范

　　Technical specification for bank and hospital service interface

　　2019 - 8 - 27 发布 2019 - 8 - 27 实施

　　中 国银行业协会 发 布

　　目 次

　　T/CBA 101—2019 (R [0]2022)

　　前 言

　　本文件的发布机构提请注意，根据国务院及相关部委的方案、意见和规定精神，有关国家标准和《中国银行业协会团体标准管理办法(试行)》相关规定，本标准的版权归中国银行业协会所有，主要通过出版发行方式实现相关权益和保护。

　　请注意本文件的某些内容可能涉及专利。本文件的发布机构不承当识别这些专利的责任。

　　本标准按照GB/T 1.1—2009《标准化工作导则第一部分：标准的结构和编写》给出的规则起草。本标准由中国工商银行提出。

　　本标准由中国银行业协会银行业产品和服务标准化委员会归口。

　　本标准起草单位：中国工商银行、中国邮政银行、交通银行、南京市卫生信息中心、江苏健康无忧网络科技有限公司、中国农业发展银行、渤海银行、徽商银行、东亚银行(中国)有限公司。

　　本标准主要起草人：潘光伟、谷澍、胡忠福、张芳、王敬东、吕仲涛、高峰、赵成刚、刘涌、王阳、陈嘉、刘红星、曾海彬、姜恺、黄海燕、徐忠、古建新、谢晋、李晖、黄钊、郭凌、吕琦英、付浩、刘国建、夏建英、胡恒社、王海东、熊开、邓晓龙、韩岗、常戈、韩青会、鞠伟宇、武建军、肖钢、杨开增、李光明、赵峰、唐一鸣、周凯、周骁、叶翔、李东印、杨明、陈静雯、陈宇、余建、肖艳玲、张士学、吴质、余亚瑞、张艳、王立建、王玉辉、周鑫。

　　引 言

　　为了持续落实国家普惠金融战略，不断提升银行业在全民医疗中的服务水平，进一步为丰富和拓展医患金融产品打好基础，解决相关金融增值服务支撑不足，降低银行核心业务系统与医疗诊疗系统互联互通中拓展成本高等情况，在银行核心业务系统和医疗诊疗系统之间建立简洁、规范、高效的信息化接口，为就医群众和医疗机构提供高效、方便、安全的服务，特制定本规范。

　　银医服务接口技术规范

　　1 范围

　　本规范规定了银行核心系统与医疗诊疗系统之间的服务范围、信息安全、联机功能要求、批量功能要求。

　　本规范适用于银行核心系统与医疗诊疗系统之间的互联互通。

　　2 术语与定义

　　下列术语和定义适用于本文件。

　　2.1

　　元素 element

　　代表一个数据域。

　　2.2

　　组件 components

　　报文中具有一定业务相关性的数据域集合，主要用于更直观描述报文的业务含义。一个业务组件可能由多个元素和多个其他业务组件构成。

　　2.3

　　业务要素 business element

　　报文体的基本组成元素。作为对应于业务流程操作中的一个商业元素，可能是一个简单的元素，也可能是一个复杂的业务组件。

　　3 服务范围

　　3.1 门诊

　　3.1.1 签约/解约

　　患者使用银医服务应与银行进行签约，解约后银行不再提供相关服务。协议内容应包含但不限于由银行提供支付等相关服务。签订协议时患者应保证签约信息真实有效。银行应根据协议为患者提供相关金融服务。患者可以自愿解除已签订的银医服务协议。

　　签约/解约应既可以在银行渠道也可以在医院渠道中进行。签约/解约结果应同时保留在银行和医院的相关系统中，并保持一致。

　　3.1.2 挂号/退号

　　银医服务当中，医院应向银行提供医疗诊疗号源和挂号/退号规则，支持患者使用银行渠道进行挂号/退号。银行应使用高效简洁的流程服务患者，合规完成挂号/退号。

　　医疗诊疗号源应由相关医院进行管理，宜采用银行业集中号池方式，支持和鼓励商业银行竞争优化，给患者提供更好的服务。

　　3.1.3 候诊查询

　　银医服务当中，应及时向患者提示当日候诊排号情况，方便患者减少等待时间。

　　医院应向银行共享当日准确的候诊排号信息，患者可在银行的渠道服务中了解当日的候诊排号情况。银行应保证获取排号信息时的效率，不给医疗诊疗系统造成压力。

　　3.1.4 医学检验状态查询

　　银医服务当中，应及时向患者提供医学检验状态查询，方便患者合理安排复诊时间。

　　医院应向银行共享医学检验基本信息和状态(含状态变化)，患者可在银行的服务渠道中获取医学检验状态和检验报告信息。银行应保证获取医学检验状态信息时的效率，不给医疗诊疗系统造成压力。

　　3.1.5 缴费

　　银医服务当中，银行应为患者提供丰富、便捷、安全的缴费服务，应向医院高效、准确、安全地提供缴费情况，为医院提供准确、便捷的清算服务。

　　医院应向银行提供准确的缴费信息，以便银行完成支付服务。银行应向医院提供完整准确的对账数据。银行、医院在目前的标准接口上，可使用补充标签等方式支持他行卡的处理。

　　3.2 住院

　　3.2.1 住院预授权

　　银医服务当中，为了减少患者存取和携带大量现金的风险，宜使用银行预授权功能，预付押金。

　　医院应向银行提供患者的住院预授权信息，银行按信息进行指定账户的预授权处理，保证相应金额在住院结算前不会被挪用，向医院提供预授权明细。

　　具体实现方式见5.5。

　　3.2.2 住院结算

　　见3.1.5。

　　实现住院结算方式见5.5。

　　4 信息安全

　　4.1 总体要求

　　银行与医院之间通信报文包头，应通过使用数字签名对XML消息报文进行签名的安全机制，实现报文完整性和敏感数据保护。报文详细格式参见附录A。

　　4.2 完整性要求

　　数据完整性要求包括：

　　a) 接收方应对通信数据中各字段是否符合协议的格式要求进行验证，检查其完整性是否遭到破坏;

　　b) 通过业务逻辑检查完整性是否遭到破坏，包括统计交易记录总数，并将记录总数附在传输数据后， 由接收方做验证;

　　c) 统计文件总数，并将文件总数附在传输数据后，由接收方验证;

　　d) 发送方应对传输的敏感数据计算校验码， 由接收方验证校验值;

　　e) 应采用数字签名进行数据完整性检查：

　　. 数字签名应采用公私钥算法，对整个报文进行数字签名计算，并由报文接收方对数字签名进行校验，应使用国密算法 SM2 和 SM3，SM3 做散列，SM2 做加解密。

　　. 联机交易数字签名密钥由银行通过密钥生成工具生成一对密钥，然后分别提供给银行和合作方。

　　4.3 信息加密

　　通信信息应进行机密性保护。

　　银行与医院间传输的业务敏感数据，应采用以下方式进行机密性保护：

　　a) 使用对称加密算法或散列算法加密敏感数据;

　　b) 使用对称加密算法加密传输报文;

　　c) 用HTTPS/SSL协议对所有通信数据加密，动态更换密钥。交换密钥使用非对称加密算法加密保护，一次一密。

　　4.4 信息检查

　　信息检查应满足：

　　a) 服务请求方将待发送的交易信息进行检查;

　　b) 服务提供方接收交易信息后进行检查。

　　c) 为防止利用 XML 的 XXE 漏洞，宜使用静态 DTD 进行校验。

　　5 联机功能要求

　　5.1 银医合作服务联机功能概述

　　联机功能包括签约/解约、挂号、退号、诊疗结算、候诊查询、医学检验状态查询。联机功能的报文格式规范参见附录C，对应字典参见附录B。

　　5.2 银医服务签约/解约报文要求

　　当报文发起方为银行系统，接收方为医院系统时，银医服务签约/解约报文要求包括：

　　a) 用于客户签订银医服务协议。银行系统发起，与医院进行一次交互，医院端处理成功后返回诊疗 ID 给银行。

　　b) 同一个客户仅能生成一个诊疗 ID。协议建立与申请诊疗 ID 属于同个动作，若客户无诊疗 ID，则自动建立一个诊疗 ID。若银行申请协议签订时，在医院端已经建立了协议(客户信息、银行卡号均相同)，则返回成功给银行。

　　当报文发起方为医院系统，接收方为银行系统，银医服务签约/解约报文要求包括：

　　a) 用于客户签订银医服务协议;

　　b) 医院系统发起，与银行进行一次接口交互，医院端发送诊疗 ID 给银行。

　　5.3 诊疗挂号报文要求

　　报文发起方：银行系统。

　　报文接收方：医院系统。

　　诊疗挂号报文要求包括：

　　a) 锁号再挂号：

　　. 医院端挂号成功，银行端扣费失败(银行端异常时极低概率出现)视同挂号失败。针对此种情况，银行端应使用自动进程向医院端进行退号处理。

　　. 医院端挂号通讯异常，导致医院端成功，银行端未收到报文结果，银行应不对挂号费或医事服务费进行扣除，应视为挂号失败。针对此种情况，银行端应使用自动进程向医院端进行退号处理。

　　. 对于不支持自动解锁的医院，银行端应支持通过自动进程向医院发起解锁。

　　. 挂号成功则银行应发送短信通知给客户。挂号明细在应银行保留，后续银行的各终端应可以提供查询银行端的挂号明细。

　　b) 除排班编号外，门诊号别、门诊时间等字段应同时发送给医院， 由医院按需使用;

　　c) 医院端宜支持自动解锁，在一定时间(例如 5min)内没有挂号确认报文，则自动将报文解锁;

　　d) 若医院端不支持自动解锁，银行端应主动发解锁申请，解锁申请中不一定包含挂号序号;

　　e) 对于银行端扣费失败的，应视为挂号失败。医院端不应发送挂号成功短信给客户，银行端会主动发送，如要发送，宜至少在 5min 后发送客户。银行端会自动发起主动退号。

　　5.4 退号报文要求

　　报文发起方：银行系统。

　　报文接收方：医院系统。

　　退号报文要求包括：

　　a) 应由医院决定是否能够退号，医院通过后，银行给客户退费(实时退费);

　　b) 如果收到银行发起的多次退号请求，且号已正常退掉，医院应返回成功给银行;

　　c) 若银行端退费失败，医院应在对账后在后续的批量代收付文件中添加退费内容;

　　d) 若银行端退号未知(发送医院结果未知)，且客户未进行后续操作，医院应在完成对账后，通过挂号状态变更文件通知银行改状态，同时在批量代收付文件中添加退费内容。

　　5.5 诊疗费结算报文要求

　　报文发起方：医院系统。

　　报文接收方：银行系统。

　　诊疗费结算报文要求包括：

　　a) 直接扣费、预授权付费模式，医院需要在银行端注册商户编号(预授权模式支持部分预授权，剩余资金保持冻结);

　　b) 结算交易均支持重发，医院端应发送重发标志，同时按原医院流水号发送给银行，银行应判断账务是否已经处理，若未处理，则处理账务;若已处理，则直接返回医院处理结果;

　　c) 账务处理以银行结果为准。

　　5.6 候诊查询报文要求

　　报文发起方：银行系统。

　　报文接收方：医院系统。

　　候诊查询报文要求包括：

　　a) 银行应控制查询频率，避免对医疗诊疗系统产生压力;

　　5.7 医学检验状态查询报文要求

　　报文发起方：银行系统。

　　报文接收方：医院系统。

　　医学检验状态报文要求包括：

　　a) 银行应控制查询频率，避免对医疗诊疗系统产生压力。

　　6 批量功能要求

　　6.1 批量处理功能和流程

　　6.1.1 批量处理功能

　　批量处理功能包括：

　　a) 医院批量文件传输;

　　b) 银行批量文件传输。

　　医院批量文件包括科室信息文件、医生信息文件、排班信息文件、挂号变动明细文件、批量代收付文件、批量预授权确认文件;银行批量文件包括协议对账文件、账务类对账文件、银行挂号退号文件、账务清单。批量功能的报文格式规范参见附录D，对应字典参见附录B。

　　6.1.2 批量处理流程

　　批量功能流程如下：

　　a) 医院应在相关功能对患者开放前提供对应文件发送到银行系统;

　　b) 银行获取医院文件进行处理，在银行核心系统完成对账后生成对账文件给医院;

　　c) 医院获取对账文件并根据银行的对账文件进行处理。

　　d) 双方文件传输宜采用 SFTP 方式。

　　6.2 医院批量文件接口

　　6.2.1 接口要求

　　医院批量文件接口应满足：

　　a) 批量文件格式：定长，字段按照最大长度，如果长度不够则右补空格;

　　b) 参数标志说明：

　　. 每家医院可以选择其中一种模式(增量或全量)，其中增量方式参数标志只能选择 1-新增、2-修改、3-删除，全量方式参数只能选择 4-覆盖，医院可和银行约定使用对应模式;

　　. 每天的科室、医生、排班文件的编号科室编号、(医生编号+科室编号)、排班编号应唯一。

　　6.2.2 科室信息文件

　　科室信息文件包括科室编号、科室名称、科室介绍、参数标志信息。

　　若无变化，可发送空文件。

　　6.2.3 医生信息文件

　　医生信息文件包括医生编号、科室编号、医生姓名、医生性别、医生职称、医生学历、医生特长、医生简介、医生照片，参数标志信息。

　　医生信息文件宜增量传输;如果全量传输，则所有记录的传输标志为4-覆盖模式，银医系统将先删除历史记录，再插入新值。

　　6.2.4 排班信息文件

　　排班信息文件包括门诊排班号、科室编号、医生编号、号类别、就诊日期、就诊时间、就诊位置、挂号费或医事服务费、限号数、参数标志信息。

　　排班信息文件宜增量传输;如果全量传输，则所有记录的传输标志为4，银行系统将先删除历史记录，再插入新值。

　　医院排班文件同步批量约束包括：

　　a) 批量文件通过 gzip 压缩，分文件压缩;

　　b) 医院排班文件一日可以处理多场，医院可以分次发送，发送时应在文件名上标明小编号;

　　示例：H03_医院代码_YYYYMMDD_01.gz

　　c) 批量文件传输方案包括以下方式，具体采用哪种方式根据与医院对接模式确定：

　　. 模式 1：医院端将参数文件上传至银行前置服务器，上传截止时间到当天 20：00，若 20： 00 前未提交，则将在次日导入。 日间医院可以随时将文件上传银行，银行在指定时间批次统一处理，处理间隔时间6h;

　　. 模式 2：医院端通过联机交易发送文件就绪通知，银行端主动从医院前置机获取文件并处理，无处理时间限制。

　　6.2.5 挂号变动明细文件

　　因医生排班变化导致已挂号变化的记录，或客户已挂号信息的状态变更应通过该文件批量推送给银行。

　　示例：客户已挂号信息的状态变更：号作废、号时间变化。

　　挂号变动明细文件包括银行代码、医院代码、医院日期、医院流水号、客户姓名、客户HISID、客户银行账号、挂号金额、门诊排班号(旧)、门诊号别(旧)、门诊日期(旧)、门诊时间(旧)、就诊序号(旧)、挂号序号(旧)、门诊排班号(新)、门诊号别(新)、门诊日期(新)、门诊时间(新)、就诊序号(新)、挂号序号(新)信息。

　　6.2.6 批量代收付文件

　　实现医院批量退费。

　　批量代收付文件包括银行代码、医院代码、业务功能号、医院流水号、客户姓名、客户HISID、客户银行账号、转账金额、转账币种、转账钞汇标志、用途、摘要信息。

　　6.2.7 批量预授权确认文件

　　对于预授权确认模式，可联机作预授权，通过批量文件确认。

　　批量预授权确认文件包括银行代码、医院代码、医院分支机构代码、业务功能号、原银行流水号、医院流水号、客户姓名、客户HISID、客户银行账号、转账金额、转账币种、转账钞汇标志、用途、摘要信息。

　　6.3 银行批量文件接口

　　6.3.1 新增/修改/删除协议对账文件

　　医院端以银行为准进行处理。

　　新增/修改/删除协议对账文件文件包括会计日期、银行代码、医院代码、医院日期、业务功能号、银行流水号、医院流水号、客户姓名、客户HISID、客户银行账号、证件类型、证件号码、地址、手机号码、亲属姓名、亲属手机号、出生日期、性别、对账时间信息。

　　6.3.2 账务类对账文件

　　提供与医院发生的实际账务数据，不包含批量代收付结果，按照银行主机日期出具对账文件，包含所有医院发起的交易，成功或失败均应返回。

　　账务类对账文件包括会计日期、银行代码、医院代码、医院日期、业务功能号、银行流水号、医院流水号、客户姓名、客户HISID、客户银行账号、证件类型、证件号码、地址、手机号码、亲属姓名、亲属手机号、出生日期、性别、对账时间信息。

　　6.3.3 银行端挂号、退号文件

　　该文件主要要求包括：

　　a) 记录当日银行端处理成功的挂号及退号记录;

　　b) 银行端未挂号成功的，医院日终进行退号(客户未能扣费成功);

　　c) 银行端未能退号成功的，医院若已经退号成功，医院后续通过批量代收付文件进行退费;

　　d) 同时在后续的挂号变动明细中告知银行最新的挂号变化结果。

　　银行端挂号、退号文件文件包括会计日期、银行代码、医院代码、医院日期、业务功能号、银行流水号、医院流水号、客户姓名、客户HISID、客户银行账号、门诊排班号、门诊号别、门诊日期、门诊时间、挂号金额、就诊序号、挂号序号、对账时间信息。

　　6.3.4 账务清单

　　所有通过银医系统和医院对公户发生的账务交易明细，仅包含成功明细，不包含批量代收付结果。

　　账务清单包括会计日期、银行代码、医院代码、医院日期、业务功能号、银行流水号、医院流水号、客户姓名、客户HISID、客户银行账号、证件类型、证件号码、地址、手机号码、亲属姓名、亲属手机号、出生日期、性别、对账时间信息。

　　附 录 A

　　(规范性附录)

　　信息格式规范

　　A.1 语法

　　A.1.1 基本要求

　　基本要求包括：

　　a) 报文体采用XML 格式描述;

　　b) 报文体的语法规则应遵循 XML 语法规则;

　　c) 报文采用 Unicode 字符集，UTF-8 编码方式;

　　d) 优先使用英文和数字信息;

　　e) 一般不做码制转换，如确需做码制转换，则需根据具体情况具体分析码制转换方案。

　　A.1.2 报文体结构

　　一个报文体由一个报文头和一个业务体组成，而业务体由多个业务要素构成， XML不定长，合作双方可借鉴业务功能报文进行扩展，支持业务发展。完整的报文体结构见表A.1。

　　表 A.1 报文体结构

　　XML 格式的报文体以为根节点 ，报文头以为节点名称 ，业务体由 、 、 、等节点组成。

　　示例：完整的报文如下：

　　为根节点，报文头以<"UTF-8"?>

　　……

　　……

　　……

　　A.1.3 可选性

　　业务要素在报文体中的可选性分为：

　　a) M，必填(Mandatory);

　　b) O，可选(Optional)。

　　A.1.4 重复性

　　报文块的重复性分为：

　　a) Y，可重复;

　　b) N，不可重复。

　　本规范中利用[m n]来描述业务要素的可选性和重复性， [m n]表示该要素至少应出现m次，最多出现n次。

　　示例： [0 1]表示该元素可以不出现，也可以出现一次。

　　A.2 数据类型

　　A.2.1 数据类型说明

　　数据类型用于定义数据域的取值类型，本规范定义了一些基本的数据类型，见表A.2。

　　表 A.2 数据类型说明

　　A.2.2 数据交换模式

　　本规范针对联机、单笔交易数据交换模式，包括多笔、批量文件交换模式。

　　A.2.3 业务要素

　　业务要素是业务数据项的抽象名称，是报文体的基本组成元素，对应于业务流程操作中的一个商业元素。其要求包括：

　　a) 业务要素可是一个简单的业务元素，也可是由业务元素组成的复杂业务组件;

　　b) 每一个业务要素都应有 XML Tag、业务含义、数据类型和取值范围;

　　c) 在报文中，应根据不同的 XML Tag 确定不同业务要素;

　　d) 业务要素的数据类型决定了其取值类型，取值范围可以是一个集合，任何在此集合外的取值被认为是非法取值;

　　e) 应用数据字典详细定义了业务元素取值范围;

　　f) XML Tag 业务要素可根据双方的约定统一为小写或者大写。

　　A.2.4 业务组件

　　应用报文中有很多与业务相关的数据域集合，本规范中定义了一些业务组件，在应用报文定义中可利用这些组件描述业务流程中的业务要素。实际的报文定义和使用中，则应该将组件扩展开成为相应的数据域集合。

　　示例：大多数应用报文都会用到一系列定义客户信息的数据域：客户姓名、客户类型、客户证件类型、客户证件号码等。

　　一个业务组件(简称组件)在XML数据文档中相当于一个复合元素(Complex element)，它可包括其他业务组件和简单元素。

　　A.2.5 报文包头组件格式和数据类型

　　每一个会话或应用报文应有一个报文头，报文头应包括：

　　a) 报文类型;

　　b) 发送起始点;

　　c) 发送目的地;

　　d) 发送时间;

　　e) 报文标识号;

　　f) 其他一些通用信息。

　　报文头格式、数据类型见表A.3。

　　表 A.3 报文头格式

　　A.2.6 返回结果组件结构和数据类型

　　银医双方，服务提供方处理失败时应向服务请求方反馈错误码信息。双方之间的联机数据处理结果应答，可采用一层信息描述处理状态。

　　对于返回码字段，宜用二层信息即二个字段进行描述。

　　双方之间数据交换文档中应按照“成功 ”、“失败 ”、“处理中 ”对各类情况进行明确归纳，约定各状态的后续处理流程。

　　返回结果结构和数据类型见表A.4。

　　表 A.4 返回结果结构和数据类型

　　A.2.7 失败交易后续处理

　　对于服务提供方应用处理“失败 ”的联机数据，服务提供方有特殊后续处理需求时，双方应约定后续处理机制，主要包括：

　　a) 向服务请求方应答失败、结束处理流程;

　　b) 向服务请求方应答“处理中 ”。

　　服务提供方应用处理失败，服务请求方应用有需求时，对此类可后续人工处理、状态登记为“待处理 ”的联机数据， 由银行或医院相关人员根据业务需求进行辅助操作之后完成后续处理。

　　A.3 机构信息组件结构和数据类型

　　银医之间进行接口报文交换时，为便于双方准确识别业务发送方机构、接收方机构，应采用机构信息组件标识机构信息，机构信息结构见表A.5。

　　表 A.5 机构信息结构

　　附 录 B

　　(规范性附录)

　　数据字典

　　B.1 报文传输标志

　　报文传输标志如下：

　　a) 9：交易未处理;

　　b) 0：交易已处理。

　　B.2 业务功能码

　　业务功能码代码如下：

　　a) 21001：协议签订;

　　b) 21002：协议修改;

　　c) 21003：协议注销;

　　d) 22001：客户转医院(转账) ;

　　e) 22002：医院转客户(转账) ;

　　f) 22003：客户转医院冲正(转账) ;

　　g) 22004：医院转客户冲正(转账) ;

　　h) 22005：客户扣费预授权;

　　i) 22006：客户扣费预授权追加;

　　j) 22007：客户扣费预授权撤销;

　　k) 22008：客户扣费预授权确认(剩余资金解冻);

　　l) 22011：客户扣费预授权确认(支持部分资金确认，剩余资金保留);

　　m) 22009：客户转医院(消费) ;

　　n) 22010：客户转医院冲正(消费) ;

　　o) 23001：挂号锁号申请;

　　p) 23002：挂号锁号取消;

　　q) 23003：挂号确认;

　　r) 23005：医保挂号确认;

　　s) 23004：退号;

　　t) 23006：医保挂号退号;

　　u) 23007：挂号预授权扣费;

　　v) 23008：挂号预授权退费;

　　w) 24001：诊疗进度查询;

　　x) 24002：诊疗结果查询;

　　y) 24003：智能候诊。

　　B.3 交易发起方

　　交易发起方代码如下：

　　a) H：医院端发起;

　　b) B：银行端发起。

　　B.4 是否重发标志

　　是否重发标志如下：

　　a) 0：非重发;

　　b) 1：重发。

　　B.5 是否接收短信提醒标志

　　是否接收短信提醒标志如下：

　　a) 0：接收 ;

　　b) 1：不接收。

　　B.6 是否支持医院方扣费标志

　　是否支持医院方扣费标志如下：

　　a) 0：支持;

　　b) 1：不支持(解约时不输入)。

　　附 录 C

　　(规范性附录)

　　银医服务联机接口

　　C.1 联机数据交换主要内容

　　银医业务合作数据交换报文，应以交易请求、交易处理成对的形式出现。本规范在数据元、值域及报文设计方面，与金融业已发布的报文相关规范保持协调性和一致性。

　　银医业务合作数据交换主要内容见表C.1。

　　表 C.1 银医业务合作数据交换主要内容

　　C.2 联机交易约定

　　联机交易约定包括：

　　a) 报文传输标志发起时由发起方置为9，接收方将其改为 0。

　　b) 交易运行状态为：

　　. 0：成功;

　　. 1：失败;

　　. 2：未知(不能确定是否成功，建议发起方重发)。

　　c) 报文消息体采用XML 格式描述。

　　示例：消息体样例如下：

　　……

　　……

　　……

　　Inf

　　C.3 银医签约解约报文

　　C.3.1 请求报文内容

　　请求报文的主要内容见表C.2。

　　表 C.2 请求报文主要内容

　　C.3.2 应答报文内容

　　应答报文主要内容见表C.3。

　　表 C.3 应答报文主要内容

　　C.4 诊疗挂号报文

　　C.4.1 请求报文内容

　　请求报文内容见表C.4。

　　表 C.4 请求报文内容

　　C.4.2 应答报文内容

　　应答报文主要内容见表C.5。

　　表 C.5 应答报文主要内容

　　C.5 退号报文

　　C.5.1 请求报文内容

　　请求报文内容见表C.6。

　　表 C.6 请求报文内容

　　C.5.2 应答报文

　　应答报文内容见表C.7。

　　表 C.7 应答报文内容

　　C.6 诊疗费结算报文

　　C.6.1 请求报文

　　请求报文内容见表C.8。

　　表 C.8 诊疗费结算报文内容

　　C.6.2 应答报文

　　应答报文内容见表C.9。

　　表 C.9 诊疗费结算应答报文内容

　　C.7 智能候诊

　　C.7.1 请求报文

　　请求报文的主要内容见表C.10。

　　表 C.10 智能候诊请求报文

　　C.7.2 应答报文

　　应答报文的主要内容见表C.11。

　　表 C.11 智能候诊应答报文

　　C.8 诊疗进度查询

　　C.8.1 请求报文

　　请求报文的主要内容见表C.12。

　　表 C.12 诊疗进度查询请求报文

　　C.8.2 应答报文

　　应答报文的主要内容见表C.13。

　　表 C.13 诊疗进度查询应答报文

　　附 录 D

　　(规范性附录)

　　银医服务批量文件接口

　　D.1 医院批量文件接口

　　D.1.1 科室信息文件

　　科室信息文件名：H01_医院代码_YYYYMMDD.gz，其主要内容见表D.1。

　　表 D.1 科室信息文件内容

　　D.1.2 医生信息文件

　　医生信息文件名：H02_医院代码_YYYYMMDD.gz，其主要内容见表D.2。

　　表 D.2 医生信息文件内容

　　D.1.3 排班信息文件

　　排班信息文件名：H03_医院代码_YYYYMMDD.gz，其主要内容见表D.3。

　　表 D.3 排班信息文件内容

　　D.1.4 挂号变动明细文件

　　挂号变动明细文件名：H04_医院代码_YYYYMMDD.gz，其主要内容见表D.4。

　　表 D.4 挂号变动明细文件内容

　　D.1.5 医生照片文件

　　医生照片文件名：Hphoto_医院代码_YYYYMMDD.gz，

　　说明：gz包解开后是一个Hphoto_医院代码_YYYYMMDD.zip包，其中：

　　a) 医生照片文件格式为：医生编号.jpg;

　　b) 医院照片文件格式为：医院代码.jpg。

　　D.1.6 批量代收付文件

　　批量代收付文件名：H05_医院代码_YYYYMMDD.gz，其主要内容见表D.5。

　　表 D.5 批量代收付文件内容

　　D.1.7 批量预授权确认文件

　　批量预授权确认文件名：H06_医院代码_YYYYMMDD.gz，其主要内容见表D.6。

　　表 D.6 批量预授权确认文件内容

　　D.1.8 停诊明细文件

　　停诊明细文件文件名：H07_医院代码_YYYYMMDD.gz，其主要内容见表D.7

　　表 D.7 停诊明细文件

　　D.2 银行批量文件接口

　　D.2.1 新增/修改/删除协议对账文件

　　新增/修改/删除协议对账文件名：B01_医院代码_YYYYMMDD.gz，其相关内容见表D.8。

　　表 D.8 新增/修改/删除协议对账文件内容

　　3l

　　D.2.2 账务类对账文件

　　账务类对账文件名：B02_医院代码_YYYYMMDD.gz，其主要内容见表D.9。

　　表 D.9 账务类对账文件内容

　　D.2.3 银行端挂号、退号文件

　　银行端挂号、退号文件名：B03_医院代码_YYYYMMDD.gz，其主要内容见表D.10。

　　表 D.10 银行端挂号、退号文件内容

　　D.2.4 账务清单

　　账务清单(所有入医院账户的交易明细，仅成功明细)文件名：B04_医院代码_YYYYMMDD.gz，其主要内容见表D.11。

　　表 D.11 账务清单内容

　　参 考 文 献

　　[1] GB/T 2261.1-2003 个人基本信息分类与代码 第1部分：人的性别代码

　　[2] JR/T 0126-2015 银行与合作方业务数据一致性处理规范

　　[3] ISO 20022 金融服务金融业通用报文方案