T/CBA 101-2019 银医服务接口技术规范

ICS03.060;03.080.30

A11

CBA

团体标准

T/CBA101-2019

银医服务接口技术规范

Technicalspecificationforbankandhospitalserviceinterface

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

中国银行业协会发布

目次

前言II

引言III

1范围1

2术语与定义1

3服务范围1

3.1门诊1

3.2住院2

4信息安全2

4.1总体要求2

4.2完整性要求2

4.3信息加密3

4.4信息检查3

5联机功能要求3

5.1银医合作服务功能3

5.2银医服务签约/解约报文3

5.3诊疗挂号报文3

5.4退号报文4

5.5诊疗费结算报文4

5.6候诊查询4

5.7医学检验状态查询5

6批量功能要求5

6.1批量处理功能和流程5

6.2医院批量文件接口5

6.3银行批量文件接口7

附录A（规范性附录）信息格式规范8

附录B（规范性附录）数据字典15

附录C（规范性附录）银医服务联机接口17

附录D（规范性附录）银医服务批量文件接口34

参考文献41

T/CBA101-2019

前言

本文件的发布机构提请注意，根据国务院及相关部委的方案、意见和规定精神，有关国家标准和《中

国银行业协会团体标准管理办法（试行）》相关规定，本标准的版权归中国银行业协会所有，主要通过

出版发行方式实现相关权益和保护。

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

本标准按照GB/T1.1—2009《标准化工作导则第一部分：标准的结构和编写》给出的规则起草。

本标准由中国工商银行提出。

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

本标准起草单位：中国工商银行、中国邮政银行、交通银行、南京市卫生信息中心、江苏健康无忧

网络科技有限公司、中国农业发展银行、渤海银行、徽商银行、东亚银行（中国）有限公司。

本标准主要起草人：潘光伟、谷澍、胡忠福、张芳、王敬东、吕仲涛、高峰、赵成刚、刘涌、王阳、

陈嘉、刘红星、曾海彬、姜恺、黄海燕、徐忠、古建新、谢晋、李晖、黄钊、郭凌、吕琦英、付浩、刘

国建、夏建英、胡恒社、王海东、熊开、邓晓龙、韩岗、常戈、韩青会、鞠伟宇、武建军、肖钢、杨开

增、李光明、赵峰、唐一鸣、周凯、周骁、叶翔、李东印、杨明、陈静雯、陈宇、余建、肖艳玲、张士

学、吴质、余亚瑞、张艳、王立建、王玉辉、周鑫。

I

T/CBA101-2019

引言

为了持续落实国家普惠金融战略，不断提升银行业在全民医疗中的服务水平，进一步为丰富和拓展

医患金融产品打好基础，解决相关金融增值服务支撑不足，降低银行核心业务系统与医疗诊疗系统互联

互通中拓展成本高等情况，在银行核心业务系统和医疗诊疗系统之间建立简洁、规范、高效的信息化接

口，为就医群众和医疗机构提供高效、方便、安全的服务，特制定本规范。

II

T/CBA101-2019

银医服务接口技术规范

1范围

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

要求。

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

2术语与定义

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

2.1

元素element

代表一个数据域。

2.2

组件components

报文中具有一定业务相关性的数据域集合，主要用于更直观描述报文的业务含义。一个业务组件可

能由多个元素和多个其他业务组件构成。

2.3

业务要素businesselement

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

可能是一个复杂的业务组件。

3服务范围

3.1门诊

3.1.1签约/解约

患者使用银医服务应与银行进行签约，解约后银行不再提供相关服务。协议内容应包含但不限于由

银行提供支付等相关服务。签订协议时患者应保证签约信息真实有效。银行应根据协议为患者提供相关

金融服务。患者可以自愿解除已签订的银医服务协议。

签约/解约应既可以在银行渠道也可以在医院渠道中进行。签约/解约结果应同时保留在银行和医院

的相关系统中，并保持一致。

3.1.2挂号/退号

银医服务当中，医院应向银行提供医疗诊疗号源和挂号/退号规则，支持患者使用银行渠道进行挂

号/退号。银行应使用高效简洁的流程服务患者，合规完成挂号/退号。

医疗诊疗号源应由相关医院进行管理，宜采用银行业集中号池方式，支持和鼓励商业银行竞争优化，

给患者提供更好的服务。

3.1.3候诊查询

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

1

T/CBA101-2019

医院应向银行共享当日准确的候诊排号信息，患者可在银行的渠道服务中了解当日的候诊排号情

况。银行应保证获取排号信息时的效率，不给医疗诊疗系统造成压力。

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做加解密。

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

作方。

2

T/CBA101-2019

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)锁号再挂号：

医院端挂号成功，银行端扣费失败（银行端异常时极低概率出现）视同挂号失败。针对此

种情况，银行端应使用自动进程向医院端进行退号处理。

医院端挂号通讯异常，导致医院端成功，银行端未收到报文结果，银行应不对挂号费或医

事服务费进行扣除，应视为挂号失败。针对此种情况，银行端应使用自动进程向医院

端进行退号处理。

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

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

以提供查询银行端的挂号明细。

3

T/CBA101-2019

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)医院批量文件传输；

4

T/CBA101-2019

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；

5

T/CBA101-2019

模式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)同时在后续的挂号变动明细中告知银行最新的挂号变化结果。

6

T/CBA101-2019

银行端挂号、退号文件文件包括会计日期、银行代码、医院代码、医院日期、业务功能号、银行流

水号、医院流水号、客户姓名、客户HISID、客户银行账号、门诊排班号、门诊号别、门诊日期、门诊

时间、挂号金额、就诊序号、挂号序号、对账时间信息。

6.3.4账务清单

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

账务清单包括会计日期、银行代码、医院代码、医院日期、业务功能号、银行流水号、医院流水号、

客户姓名、客户HISID、客户银行账号、证件类型、证件号码、地址、手机号码、亲属姓名、亲属手机

号、出生日期、性别、对账时间信息。

7

T/CBA101-2019

附录A

（规范性附录）

信息格式规范

A.1语法

A.1.1基本要求

基本要求包括：

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

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

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

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

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

A.1.2报文体结构

一个报文体由一个报文头和一个业务体组成，而业务体由多个业务要素构成，XML不定长，合作双

方可借鉴业务功能报文进行扩展，支持业务发展。完整的报文体结构见表A.1。

表A.1报文体结构

报文头报文头内容

报业业务要素1业务要素1内容

文务业务要素2业务要素2内容

体体业务要素3业务要素3内容

XML格式的报文体以<MsgText>为根节点，报文头以<GrpHdr>为节点名称，业务体由<TrsctlInfo>、

<CustInfo>、<TrsInfo>、<HospitalInfo>等节点组成。

示例：完整的报文如下：

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

<MsgText>

<GrpHdr>

„„

</GrpHdr>

<TrsctlInfo>

„„

</TrsctlInfo>

<CustInfo>

„„

</CustInfo>

</MsgText>

0

T/CBA101-2019

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数据类型说明

索引数据类型定义格式示例备注

最大长度为N，小数位为0以Number3表示最大长

此处长度仅为报文规范

1整数数值一个N位的整数NumberfractionDigital：0，度为3位的整数类型：

规定的最大长度

totalDigital：3123

数值最大长度为N，小数位最

一个N位的小数大长度位N-112345678901.或此处长度仅为报文规范

2小数数值

DecimalNumberfractionDigital：N，0.1234567890规定的最大长度

totalDigital：N-1

代表金额，一个Amount最大长度为17，无小数点，最多17位数字，以分为

3金额12345667890

的整数不固定长度单位，无小数点

4日期日期DateYYYYMMDD20060708

5时间时间TimeHHMMSS230000

6日期时间日期和时间DateTimeYYYYMMDDHHMMSS20060708120000

此处长度为报文标准规

定的最大长度（字节）

最大长度N个字符，最小长度Max5Text：aaaaaa；示例：Max5text，是指

7文本最大N个字符Text

1。如果固定长度，以NText3Text：bbb（定长3位）5个字节（非5汉字字

符）；如无Max，则为定

长文本

A.2.2数据交换模式

1

T/CBA101-2019

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

A.2.3业务要素

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

元素。其要求包括：

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

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

c)在报文中，应根据不同的XMLTag确定不同业务要素；

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

认为是非法取值；

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

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

A.2.4业务组件

应用报文中有很多与业务相关的数据域集合，本规范中定义了一些业务组件，在应用报文定义中可

利用这些组件描述业务流程中的业务要素。实际的报文定义和使用中，则应该将组件扩展开成为相应的

数据域集合。

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

码等。

一个业务组件（简称组件）在XML数据文档中相当于一个复合元素（Complexelement），它可包括

其他业务组件和简单元素。

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

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

a)报文类型；

b)发送起始点；

c)发送目的地；

d)发送时间；

e)报文标识号；

f)其他一些通用信息。

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

表A.3报文头格式

要素

索英文名可选

要素名称XMLTag重复数据格式说明备注

引称性

类型

MaxLeng

Max30th30，报文体版

1版本号Version<Version>[1..1]必选

TextMinLeng本号。

th1

2系统类型SysType<SysType>[1..1]Text8-银医

2

T/CBA101-2019

要素

索英文名可选

要素名称XMLTag重复数据格式说明备注

引称性

类型

报文应编排序号，所有

的报文都应通过一个

唯一的序号标识。通过

监视序号的变化识别

并处理丢失的报文。

银医双方每个会话都

应建立一个独立的接

收和发送序号，参与者

用于标识维护一个序号赋给发

本交易报送的数据包，并且设立

MaxLeng文的唯一一个单独的序号监视

报文传输TransfeMax30th30，性，用于接收到数据包的序号

3<TsfStat>[1..1]必选

标志rStatTextMinLeng通信方面间隔。

th1的检查，数据包丢失处理过程

与具体业中，协议双方应遵守数

务无关。据包顺序处理的原则，

可选择使用以下两种

方法之一可处理数据

包丢失：

a)请求最后收到报文

的所有后续报文；

b)通过维护新报文的

序列列表请求指定的

丢失报文

标识具体

业务功能BusinesNumbe{0，

4<BusCd>[1..1]必选的业务功

号sCoder9}{4，4}

能

交易发起

方：H表示

交易发起TradeSo{A，医院方发

5<TradSrc>[1..1]Text必选

方urceZ}{1，1}起，B表示

银行方发

起

报文发送

者标识，