銀醫(yī)服務接口技術規(guī)范VIP

1銀醫(yī)服務接口技術規(guī)范本規(guī)范規(guī)定了銀行核心系統與醫(yī)療診療系統之間的服務范圍、信息安全、聯機功能要求、批量功能要求。本規(guī)范適用于銀行核心系統與醫(yī)療診療系統之間的互聯互通。2術語與定義下列術語和定義適用于本文件。2.1元素element代表一個數據域。2.2組件components報文中具有一定業(yè)務相關性的數據域集合，主要用于更直觀描述報文的業(yè)務含義。一個業(yè)務組件可能由多個元素和多個其他業(yè)務組件構成。2.3業(yè)務要素businesselement報文體的基本組成元素。作為對應于業(yè)務流程操作中的一個商業(yè)元素，可能是一個簡單的元素，也可能是一個復雜的業(yè)務組件。3服務范圍3.1門診3.1.1簽約/解約患者使用銀醫(yī)服務應與銀行進行簽約，解約后銀行不再提供相關服務。協議內容應包含但不限于由銀行提供支付等相關服務。簽訂協議時患者應保證簽約信息真實有效。銀行應根據協議為患者提供相關金融服務?；颊呖梢宰栽附獬押炗喌你y醫(yī)服務協議。簽約/解約應既可以在銀行渠道也可以在醫(yī)院渠道中進行。簽約/解約結果應同時保留在銀行和醫(yī)院的相關系統中，并保持一致。3.1.2掛號/退號銀醫(yī)服務當中，醫(yī)院應向銀行提供醫(yī)療診療號源和掛號/退號規(guī)則，支持患者使用銀行渠道進行掛號/退號。銀行應使用高效簡潔的流程服務患者，合規(guī)完成掛號/退號。醫(yī)療診療號源應由相關醫(yī)院進行管理，宜采用銀行業(yè)集中號池方式，支持和鼓勵商業(yè)銀行競爭優(yōu)化，給患者提供更好的服務。3.1.3候診查詢銀醫(yī)服務當中，應及時向患者提示當日候診排號情況，方便患者減少等待時間。2醫(yī)院應向銀行共享當日準確的候診排號信息，患者可在銀行的渠道服務中了解當日的候診排號情況。銀行應保證獲取排號信息時的效率，不給醫(yī)療診療系統造成壓力。3.1.4醫(yī)學檢驗狀態(tài)查詢銀醫(yī)服務當中，應及時向患者提供醫(yī)學檢驗狀態(tài)查詢，方便患者合理安排復診時間。醫(yī)院應向銀行共享醫(yī)學檢驗基本信息和狀態(tài)（含狀態(tài)變化患者可在銀行的服務渠道中獲取醫(yī)學檢驗狀態(tài)和檢驗報告信息。銀行應保證獲取醫(yī)學檢驗狀態(tài)信息時的效率，不給醫(yī)療診療系統造成壓力。3.1.5繳費銀醫(yī)服務當中，銀行應為患者提供豐富、便捷、安全的繳費服務，應向醫(yī)院高效、準確、安全地提供繳費情況，為醫(yī)院提供準確、便捷的清算服務。醫(yī)院應向銀行提供準確的繳費信息，以便銀行完成支付服務。銀行應向醫(yī)院提供完整準確的對賬數據。銀行、醫(yī)院在目前的標準接口上，可使用補充標簽等方式支持他行卡的處理。3.2住院3.2.1住院預授權銀醫(yī)服務當中，為了減少患者存取和攜帶大量現金的風險，宜使用銀行預授權功能，預付押金。醫(yī)院應向銀行提供患者的住院預授權信息，銀行按信息進行指定賬戶的預授權處理，保證相應金額在住院結算前不會被挪用，向醫(yī)院提供預授權明細。具體實現方式見5.5。3.2.2住院結算見3.1.5。實現住院結算方式見5.5。4信息安全4.1總體要求銀行與醫(yī)院之間通信報文包頭，應通過使用數字簽名對XML消息報文進行簽名的安全機制，實現報文完整性和敏感數據保護。報文詳細格式參見附錄A。4.2完整性要求數據完整性要求包括：a)接收方應對通信數據中各字段是否符合協議的格式要求進行驗證，檢查其完整性是否遭到破壞；b)通過業(yè)務邏輯檢查完整性是否遭到破壞，包括統計交易記錄總數，并將記錄總數附在傳輸數據后，由接收方做驗證；c)統計文件總數，并將文件總數附在傳輸數據后，由接收方驗證；d)發(fā)送方應對傳輸的敏感數據計算校驗碼，由接收方驗證校驗值；e)應采用數字簽名進行數據完整性檢查：.數字簽名應采用公私鑰算法，對整個報文進行數字簽名計算，并由報文接收方對數字簽名進行校驗，應使用國密算法SM2和SM3，SM3做散列，SM2做加解密。.聯機交易數字簽名密鑰由銀行通過密鑰生成工具生成一對密鑰，然后分別提供給銀行和合作方。34.3信息加密通信信息應進行機密性保護。銀行與醫(yī)院間傳輸的業(yè)務敏感數據，應采用以下方式進行機密性保護：a)使用對稱加密算法或散列算法加密敏感數據；b)使用對稱加密算法加密傳輸報文；c)用HTTPS/SSL協議對所有通信數據加密，動態(tài)更換密鑰。交換密鑰使用非對稱加密算法加密保護，一次一密。4.4信息檢查信息檢查應滿足：a)服務請求方將待發(fā)送的交易信息進行檢查；b)服務提供方接收交易信息后進行檢查。c)為防止利用XML的XXE漏洞，宜使用靜態(tài)DTD進行校驗。5聯機功能要求5.1銀醫(yī)合作服務聯機功能概述聯機功能包括簽約/解約、掛號、退號、診療結算、候診查詢、醫(yī)學檢驗狀態(tài)查詢。聯機功能的報文格式規(guī)范參見附錄C，對應字典參見附錄B。5.2銀醫(yī)服務簽約/解約報文要求當報文發(fā)起方為銀行系統，接收方為醫(yī)院系統時，銀醫(yī)服務簽約/解約報文要求包括：a)用于客戶簽訂銀醫(yī)服務協議。銀行系統發(fā)起，與醫(yī)院進行一次交互，醫(yī)院端處理成功后返回診療ID給銀行。b)同一個客戶僅能生成一個診療ID。協議建立與申請診療ID屬于同個動作，若客戶無診療ID，則自動建立一個診療ID。若銀行申請協議簽訂時，在醫(yī)院端已經建立了協議（客戶信息、銀行卡號均相同），則返回成功給銀行。當報文發(fā)起方為醫(yī)院系統，接收方為銀行系統，銀醫(yī)服務簽約/解約報文要求包括：a)用于客戶簽訂銀醫(yī)服務協議；b)醫(yī)院系統發(fā)起，與銀行進行一次接口交互，醫(yī)院端發(fā)送診療ID給銀行。5.3診療掛號報文要求報文發(fā)起方：銀行系統。報文接收方：醫(yī)院系統。診療掛號報文要求包括：a)鎖號再掛號：.醫(yī)院端掛號成功，銀行端扣費失?。ㄣy行端異常時極低概率出現）視同掛號失敗。針對此種情況，銀行端應使用自動進程向醫(yī)院端進行退號處理。.醫(yī)院端掛號通訊異常，導致醫(yī)院端成功，銀行端未收到報文結果，銀行應不對掛號費或醫(yī)事服務費進行扣除，應視為掛號失敗。針對此種情況，銀行端應使用自動進程向醫(yī)院端進行退號處理。.對于不支持自動解鎖的醫(yī)院，銀行端應支持通過自動進程向醫(yī)院發(fā)起解鎖。.掛號成功則銀行應發(fā)送短信通知給客戶。掛號明細在應銀行保留，后續(xù)銀行的各終端應可以提供查詢銀行端的掛號明細。4b)除排班編號外，門診號別、門診時間等字段應同時發(fā)送給醫(yī)院，由醫(yī)院按需使用；c)醫(yī)院端宜支持自動解鎖，在一定時間（例如5min）內沒有掛號確認報文，則自動將報文解鎖；d)若醫(yī)院端不支持自動解鎖，銀行端應主動發(fā)解鎖申請，解鎖申請中不一定包含掛號序號；e)對于銀行端扣費失敗的，應視為掛號失敗。醫(yī)院端不應發(fā)送掛號成功短信給客戶，銀行端會主動發(fā)送，如要發(fā)送，宜至少在5min后發(fā)送客戶。銀行端會自動發(fā)起主動退號。5.4退號報文要求報文發(fā)起方：銀行系統。報文接收方：醫(yī)院系統。退號報文要求包括：a)應由醫(yī)院決定是否能夠退號，醫(yī)院通過后，銀行給客戶退費（實時退費）；b)如果收到銀行發(fā)起的多次退號請求，且號已正常退掉，醫(yī)院應返回成功給銀行；c)若銀行端退費失敗，醫(yī)院應在對賬后在后續(xù)的批量代收付文件中添加退費內容；d)若銀行端退號未知（發(fā)送醫(yī)院結果未知且客戶未進行后續(xù)操作，醫(yī)院應在完成對賬后，通過掛號狀態(tài)變更文件通知銀行改狀態(tài)，同時在批量代收付文件中添加退費內容。5.5診療費結算報文要求報文發(fā)起方：醫(yī)院系統。報文接收方：銀行系統。診療費結算報文要求包括：a)直接扣費、預授權付費模式，醫(yī)院需要在銀行端注冊商戶編號（預授權模式支持部分預授權，剩余資金保持凍結）；b)結算交易均支持重發(fā)，醫(yī)院端應發(fā)送重發(fā)標志，同時按原醫(yī)院流水號發(fā)送給銀行，銀行應判斷賬務是否已經處理，若未處理，則處理賬務；若已處理，則直接返回醫(yī)院處理結果；c)賬務處理以銀行結果為準。5.6候診查詢報文要求報文發(fā)起方：銀行系統。報文接收方：醫(yī)院系統。候診查詢報文要求包括：a)銀行應控制查詢頻率，避免對醫(yī)療診療系統產生壓力；5.7醫(yī)學檢驗狀態(tài)查詢報文要求報文發(fā)起方：銀行系統。報文接收方：醫(yī)院系統。醫(yī)學檢驗狀態(tài)報文要求包括：a)銀行應控制查詢頻率，避免對醫(yī)療診療系統產生壓力。6批量功能要求6.1批量處理功能和流程6.1.1批量處理功能批量處理功能包括：a)醫(yī)院批量文件傳輸；5b)銀行批量文件傳輸。醫(yī)院批量文件包括科室信息文件、醫(yī)生信息文件、排班信息文件、掛號變動明細文件、批量代收付文件、批量預授權確認文件；銀行批量文件包括協議對賬文件、賬務類對賬文件、銀行掛號退號文件、賬務清單。批量功能的報文格式規(guī)范參見附錄D，對應字典參見附錄B。6.1.2批量處理流程批量功能流程如下：a)醫(yī)院應在相關功能對患者開放前提供對應文件發(fā)送到銀行系統；b)銀行獲取醫(yī)院文件進行處理，在銀行核心系統完成對賬后生成對賬文件給醫(yī)院；c)醫(yī)院獲取對賬文件并根據銀行的對賬文件進行處理。d)雙方文件傳輸宜采用SFTP方式。6.2醫(yī)院批量文件接口6.2.1接口要求醫(yī)院批量文件接口應滿足：a)批量文件格式：定長，字段按照最大長度，如果長度不夠則右補空格；b)參數標志說明：.每家醫(yī)院可以選擇其中一種模式（增量或全量），其中增量方式參數標志只能選擇1-新增、2-修改、3-刪除，全量方式參數只能選擇4-覆蓋，醫(yī)院可和銀行約定使用對應模式；.每天的科室、醫(yī)生、排班文件的編號科室編號、（醫(yī)生編號+科室編號）、排班編號應唯一。6.2.2科室信息文件科室信息文件包括科室編號、科室名稱、科室介紹、參數標志信息。若無變化，可發(fā)送空文件。6.2.3醫(yī)生信息文件醫(yī)生信息文件包括醫(yī)生編號、科室編號、醫(yī)生姓名、醫(yī)生性別、醫(yī)生職稱、醫(yī)生學歷、醫(yī)生特長、醫(yī)生簡介、醫(yī)生照片，參數標志信息。醫(yī)生信息文件宜增量傳輸；如果全量傳輸，則所有記錄的傳輸標志為4-覆蓋模式，銀醫(yī)系統將先刪除歷史記錄，再插入新值。6.2.4排班信息文件排班信息文件包括門診排班號、科室編號、醫(yī)生編號、號類別、就診日期、就診時間、就診位置、掛號費或醫(yī)事服務費、限號數、參數標志信息。排班信息文件宜增量傳輸；如果全量傳輸，則所有記錄的傳輸標志為4，銀行系統將先刪除歷史記錄，再插入新值。醫(yī)院排班文件同步批量約束包括：a)批量文件通過gzip壓縮，分文件壓縮；b)醫(yī)院排班文件一日可以處理多場，醫(yī)院可以分次發(fā)送，發(fā)送時應在文件名上標明小編號；c)批量文件傳輸方案包括以下方式，具體采用哪種方式根據與醫(yī)院對接模式確定：.模式1：醫(yī)院端將參數文件上傳至銀行前置服務器，上傳截止時間到當天20：00，若20：00前未提交，則將在次日導入。日間醫(yī)院可以隨時將文件上傳銀行，銀行在指定時間批次統一處理，處理間隔時間6h；6.模式2：醫(yī)院端通過聯機交易發(fā)送文件就緒通知，銀行端主動從醫(yī)院前置機獲取文件并處理，無處理時間限制。6.2.5掛號變動明細文件因醫(yī)生排班變化導致已掛號變化的記錄，或客戶已掛號信息的狀態(tài)變更應通過該文件批量推送給銀掛號變動明細文件包括銀行代碼、醫(yī)院代碼、醫(yī)院日期、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、掛號金額、門診排班號（舊）、門診號別（舊）、門診日期（舊）、門診時間（舊）、就就診序號（新）、掛號序號（新）信息。6.2.6批量代收付文件實現醫(yī)院批量退費。批量代收付文件包括銀行代碼、醫(yī)院代碼、業(yè)務功能號、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、轉賬金額、轉賬幣種、轉賬鈔匯標志、用途、摘要信息。6.2.7批量預授權確認文件對于預授權確認模式，可聯機作預授權，通過批量文件確認。批量預授權確認文件包括銀行代碼、醫(yī)院代碼、醫(yī)院分支機構代碼、業(yè)務功能號、原銀行流水號、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、轉賬金額、轉賬幣種、轉賬鈔匯標志、用途、摘要信息。6.3銀行批量文件接口6.3.1新增/修改/刪除協議對賬文件醫(yī)院端以銀行為準進行處理。新增/修改/刪除協議對賬文件文件包括會計日期、銀行代碼、醫(yī)院代碼、醫(yī)院日期、業(yè)務功能號、銀行流水號、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、證件類型、證件號碼、地址、手機號碼、親屬姓名、親屬手機號、出生日期、性別、對賬時間信息。6.3.2賬務類對賬文件提供與醫(yī)院發(fā)生的實際賬務數據，不包含批量代收付結果，按照銀行主機日期出具對賬文件，包含所有醫(yī)院發(fā)起的交易，成功或失敗均應返回。賬務類對賬文件包括會計日期、銀行代碼、醫(yī)院代碼、醫(yī)院日期、業(yè)務功能號、銀行流水號、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、證件類型、證件號碼、地址、手機號碼、親屬姓名、親屬手機號、出生日期、性別、對賬時間信息。6.3.3銀行端掛號、退號文件該文件主要要求包括：a)記錄當日銀行端處理成功的掛號及退號記錄；b)銀行端未掛號成功的，醫(yī)院日終進行退號（客戶未能扣費成功）；c)銀行端未能退號成功的，醫(yī)院若已經退號成功，醫(yī)院后續(xù)通過批量代收付文件進行退費；d)同時在后續(xù)的掛號變動明細中告知銀行最新的掛號變化結果。7銀行端掛號、退號文件文件包括會計日期、銀行代碼、醫(yī)院代碼、醫(yī)院日期、業(yè)務功能號、銀行流水號、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、門診排班號、門診號別、門診日期、門診時間、掛號金額、就診序號、掛號序號、對賬時間信息。6.3.4賬務清單所有通過銀醫(yī)系統和醫(yī)院對公戶發(fā)生的賬務交易明細，僅包含成功明細，不包含批量代收付結果。賬務清單包括會計日期、銀行代碼、醫(yī)院代碼、醫(yī)院日期、業(yè)務功能號、銀行流水號、醫(yī)院流水號、客戶姓名、客戶HISID、客戶銀行賬號、證件類型、證件號碼、地址、手機號碼、親屬姓名、親屬手機號、出生日期、性別、對賬時間信息。0（規(guī)范性附錄）信息格式規(guī)范A.1語法A.1.1基本要求基本要求包括：a)報文體采用XML格式描述；b)報文體的語法規(guī)則應遵循XML語法規(guī)則；c)報文采用Unicode字符集，UTF-8編碼方式；d)優(yōu)先使用英文和數字信息；e)一般不做碼制轉換，如確需做碼制轉換，則需根據具體情況具體分析碼制轉換方案。A.1.2報文體結構一個報文體由一個報文頭和一個業(yè)務體組成，而業(yè)務體由多個業(yè)務要素構成，XML不定長，合作雙方可借鑒業(yè)務功能報文進行擴展，支持業(yè)務發(fā)展。完整的報文體結構見表A.1。表A.1報文體結構............XML格式的報文體以<MsgText>為根節(jié)點，報文頭以<GrpHdr>為節(jié)點名稱，業(yè)務體由<TrsctlInfo>、<CustInfo>、<TrsInfo>、<HospitalInfo>等節(jié)點組成。<?xmlversion=Text>為根節(jié)點，報文頭以1A.1.3可選性業(yè)務要素在報文體中的可選性分為：a)M，必填（Mandatory）；b)O，可選（Optional）。A.1.4重復性報文塊的重復性分為：a)Y，可重復；b)N，不可重復。本規(guī)范中利用[m..n]來描述業(yè)務要素的可選性和重復性，[m..n]表示該要素至少應出現m次，最多出現n次。A.2數據類型A.2.1數據類型說明數據類型用于定義數據域的取值類型，本規(guī)范定義了一些基本的數據類型，見表A.2。表A.2數據類型說明1一個N位的整數NumbertotalDigital：3此處長度僅為報文規(guī)范2大長度位N-1totalDigital：N-1此處長度僅為報文規(guī)范34567此處長度為報文標準規(guī)5個字節(jié)（非5漢字字A.2.2數據交換模式2本規(guī)范針對聯機、單筆交易數據交換模式，包括多筆、批量文件交換模式。A.2.3業(yè)務要素業(yè)務要素是業(yè)務數據項的抽象名稱，是報文體的基本組成元素，對應于業(yè)務流程操作中的一個商業(yè)元素。其要求包括：a)業(yè)務要素可是一個簡單的業(yè)務元素，也可是由業(yè)務元素組成的復雜業(yè)務組件；b)每一個業(yè)務要素都應有XMLTag、業(yè)務含義、數據類型和取值范圍；c)在報文中，應根據不同的XMLTag確定不同業(yè)務要素；d)業(yè)務要素的數據類型決定了其取值類型，取值范圍可以是一個集合，任何在此集合外的取值被認為是非法取值；e)應用數據字典詳細定義了業(yè)務元素取值范圍；f)XMLTag業(yè)務要素可根據雙方的約定統一為小寫或者大寫。A.2.4業(yè)務組件應用報文中有很多與業(yè)務相關的數據域集合，本規(guī)范中定義了一些業(yè)務組件，在應用報文定義中可利用這些組件描述業(yè)務流程中的業(yè)務要素。實際的報文定義和使用中，則應該將組件擴展開成為相應的數據域集合。示例：大多數應用報文都會用到一系列定義客戶信息的數一個業(yè)務組件（簡稱組件）在XML數據文檔中相當于一個復合元素（Complexelement），它可包括其他業(yè)務組件和簡單元素。A.2.5報文包頭組件格式和數據類型每一個會話或應用報文應有一個報文頭，報文頭應包括：a)報文類型；b)發(fā)送起始點；c)發(fā)送目的地；d)發(fā)送時間；e)報文標識號；f)其他一些通用信息。報文頭格式、數據類型見表A.3。表A.3報文頭格式稱性1報文體版23稱性3報文傳輸用于標識本交易報文的唯一性，用于通信方面的檢查，與具體業(yè)的報文都應通過一個監(jiān)視序號的變化識別銀醫(yī)雙方每個會話都應建立一個獨立的接維護一個序號賦給發(fā)一個單獨的序號監(jiān)視接收到數據包的序號數據包丟失處理過程可選擇使用以下兩種方法之一可處理數據a)請求最后收到報文b)通過維護新報文的序列列表請求指定的4業(yè)務功能號r標識具體的業(yè)務功能5交易發(fā)起方交易發(fā)起醫(yī)院方發(fā)銀行方發(fā)起6n報文發(fā)送者標識，包括發(fā)送方的機構代碼，分支機構代4稱性7n報文接收者標識，包括接收方的機構代碼，分支機構代8e報文發(fā)送日期。交易日期由請求方上送，服務應答方對日期一致性進行檢9e報文發(fā)送雙方通信上的處理結果（與具體業(yè)務A.2.6返回結果組件結構和數據類型銀醫(yī)雙方，服務提供方處理失敗時應向服務請求方反饋錯誤碼信息。雙方之間的聯機數據處理結果應答，可采用一層信息描述處理狀態(tài)。對于返回碼字段，宜用二層信息即二個字段進行描述。雙方之間數據交換文檔中應按照“成功”、“失敗”、“處理中”對各類情況進行明確歸納，約定各狀態(tài)的后續(xù)處理流程。返回結果結構和數據類型見表A.4。表A.4返回結果結構和數據類型1指示本次交a)按區(qū)間劃分，識別指令執(zhí)行的狀態(tài)：成b)指令執(zhí)行成功，狀態(tài)只有一種，分配單c)指令執(zhí)行失敗，其原因有多種，需要以5錯誤碼作為返回碼。錯誤碼是一組數字(或字母與數字的結合)代碼，是指令執(zhí)行狀態(tài)為失敗的代碼。錯誤碼與返回的錯誤信息建立關聯，可用來識別服務提供方及其程序中的特定問題，是服務提供方所接收每個請求分配的執(zhí)行失敗代d)指令處理過程，因處理時間因素，或處服務請求方、服務提供方應協商，減少“處理中”的聯機數據或縮短處理時間理中”的聯機數據，銀醫(yī)雙方應約定后續(xù)處理機制，包括數據同步、內部管理柜員的批復等功能；e)返回碼（含錯誤碼）具體編碼由合作雙2附帶的返回1A.2.7失敗交易后續(xù)處理對于服務提供方應用處理“失敗”的聯機數據，服務提供方有特殊后續(xù)處理需求時，雙方應約定后續(xù)處理機制，主要包括：a)向服務請求方應答失敗、結束處理流程；b)向服務請求方應答“處理中”。服務提供方應用處理失敗，服務請求方應用有需求時，對此類可后續(xù)人工處理、狀態(tài)登記為“待處理”的聯機數據，由銀行或醫(yī)院相關人員根據業(yè)務需求進行輔助操作之后完成后續(xù)處理。A.3機構信息組件結構和數據類型銀醫(yī)之間進行接口報文交換時，為便于雙方準確識別業(yè)務發(fā)送方機構、接收方機構，應采用機構信息組件標識機構信息，機構信息結構見表A.5。表A.5機構信息結構索備6引稱型性注1碼r該機構的唯一標2稱13分支機構的唯一415碼網點的唯一標識營業(yè)網點進行統6稱17發(fā)送機構的為本次接口交互分配（規(guī)范性附錄）數據字典B.1報文傳輸標志報文傳輸標志如下：a)9：交易未處理；b)0：交易已處理。B.2業(yè)務功能碼業(yè)務功能碼代碼如下：a)21001：協議簽訂；b)21002：協議修改；c)21003：協議注銷；d)22001：客戶轉醫(yī)院(轉賬)；e)22002：醫(yī)院轉客戶(轉賬)；f)22003：客戶轉醫(yī)院沖正(轉賬)；g)22004：醫(yī)院轉客戶沖正(轉賬)；h)22005：客戶扣費預授權；i)22006：客戶扣費預授權追加；j)22007：客戶扣費預授權撤銷；k)22008：客戶扣費預授權確認（剩余資金解凍）；l)22011：客戶扣費預授權確認（支持部分資金確認，剩余資金保留）；m)22009：客戶轉醫(yī)院(消費)；n)22010：客戶轉醫(yī)院沖正(消費)；o)23001：掛號鎖號申請；p)23002：掛號鎖號取消；q)23003：掛號確認；r)23005：醫(yī)保掛號確認；s)23004：退號；t)23006：醫(yī)保掛號退號；u)23007：掛號預授權扣費；v)23008：掛號預授權退費；w)24001：診療進度查詢；x)24002：診療結果查詢；y)24003：智能候診。B.3交易發(fā)起方交易發(fā)起方代碼如下：a)H：醫(yī)院端發(fā)起；8b)B：銀行端發(fā)起。B.4是否重發(fā)標志是否重發(fā)標志如下：a)0：非重發(fā)；b)1：重發(fā)。B.5是否接收短信提醒標志是否接收短信提醒標志如下：a)0：接收；b)1：不接收。B.6是否支持醫(yī)院方扣費標志是否支持醫(yī)院方扣費標志如下：a)0：支持；b)1：不支持(解約時不輸入)。9（規(guī)范性附錄）銀醫(yī)服務聯機接口C.1聯機數據交換主要內容銀醫(yī)業(yè)務合作數據交換報文，應以交易請求、交易處理成對的形式出現。本規(guī)范在數據元、值域及報文設計方面，與金融業(yè)已發(fā)布的報文相關規(guī)范保持協調性和一致性。銀醫(yī)業(yè)務合作數據交換主要內容見表C.1。表C.1銀醫(yī)業(yè)務合作數據交換主要內容銀行與醫(yī)院之間合作，開辦為患者服務的銀醫(yī)服務功能集，被封裝用于解決一個或報文格式定義及報文內容），輯規(guī)則和簡便的方法指銀醫(yī)間對接口功能處理等描述的文檔C.2聯機交易約定聯機交易約定包括：a)報文傳輸標志發(fā)起時由發(fā)起方置為9，接收方將其改為0。b)交易運行狀態(tài)為：.0：成功；.1：失??；.2：未知（不能確定是否成功，建議發(fā)起方重發(fā)）。c)報文消息體采用XML格式描述。<?xmlversion="1.0"encodiC.3銀醫(yī)簽約解約報文C.3.1請求報文內容請求報文的主要內容見表C.2。表C.2請求報文主要內容性應用系統類型報文傳輸標志</MsgText/GrpHdr/Sea)醫(yī)院發(fā)起時為醫(yī)院在銀行注冊b)預約平臺發(fā)起為預約平臺代發(fā)起方分支</MsgText/GrpHdr/Se醫(yī)院發(fā)起時且為預約平臺時輸入其</MsgText/GrpHdr/Reb)銀行發(fā)起時為醫(yī)院在銀行注冊接收方分支</MsgText/GrpHdr/Reb)銀行發(fā)起時且對方為預約平臺發(fā)起方流水號醫(yī)院發(fā)起為醫(yī)院流水號、銀行發(fā)起是否重發(fā)標志客戶銀行賬號</MsgText/CustInfo/Acctno>醫(yī)院開通支持委托代扣或者預授權性</MsgText/CustInfo/協議新增、修改時候輸入，解約不</MsgText/CustInfo/R親屬手機號碼</MsgText/CustInfo/R是否接收短是否支持醫(yī)C.3.2應答報文內容應答報文主要內容見表C.3。表C.3應答報文主要內容性性>b)醫(yī)院發(fā)起時同請求報文對應字段無C.4診療掛號報文C.4.1請求報文內容請求報文內容見表C.4。表C.4請求報文內容性發(fā)起方代碼（銀發(fā)起方分支機構性接收方代碼（醫(yī)醫(yī)院(或預約平臺)在銀行系統中注接收方分支結構發(fā)起端流水號>>a)23001時：掛號鎖號申請時此字b)23003/23005時：輸入鎖號成功</MsgText/CustInfo/Acctno>b)客戶為注冊客戶時輸入銀行客醫(yī)院提供的排班參數文件中的排班號若鎖號申請成功時醫(yī)院返回的號別若鎖號申請成功時醫(yī)院返回的日期若鎖號申請成功時醫(yī)院返回的時間若鎖號申請成功時醫(yī)院返回的金額無C.4.2應答報文內容應答報文主要內容見表C.5。表C.5應答報文主要內容性應要與對應請求報文中的銀行流水號一致應要與對應請求報文中的接收方代碼應要與對應請求報文中的交易日期一致b)其他5位數字表示失敗，醫(yī)院需提供常見的失敗返回碼，同時補充返a)需保證一家醫(yī)院內一直唯一（前8）；）；性應收客戶掛號1）若不返回則銀行掛號處理時以排2)若更新返回則以返回金額進行后續(xù)扣費處理(針對醫(yī)院掛號收費臨時醫(yī)院自定義短醫(yī)院自定義短信內容（如HIS就診密碼），無C.5退號報文C.5.1請求報文內容請求報文內容見表C.6。表C.6請求報文內容性發(fā)起方分支機醫(yī)院(或預約平臺)在銀行系統中注冊的性接收方分支結YYYYMMDD工作日期，由接收方校驗一致性發(fā)起端流水號>>游客掛號時輸入空；非游客情況下輸入就診序號（客戶主動退號時有值，自動掛號序號（掛號鎖號取消、掛號確認、若鎖號申請成功時醫(yī)院返回的號別有更新，則其他后續(xù)場景以更新后的內容輸入若鎖號申請成功時醫(yī)院返回的日期有更新，則其他后續(xù)場景以更新后的內容輸入若鎖號申請成功時醫(yī)院返回的時間有更新，則其他后續(xù)場景以更新后的內容輸入若鎖號申請成功時醫(yī)院返回的金額有更新，則其他后續(xù)場景以更新后的內容輸入無C.5.2應答報文應答報文內容見表C.7。性應要與對應請求報文中的銀行流水號一致應要與對應請求報文中的接收方代碼2）23004/23006時)表示已退號(針a)需保證一家醫(yī)院內一直唯一（最好）；d)23004/23006時：表示退號流水號表C.7應答報文內容C.6診療費結算報文C.6.1請求報文請求報文內容見表C.8。表C.8診療費結算報文內容性前版本為“1.0.0”22008：客戶扣費預授權確認（剩余）；22011：客戶扣費預授權確認（支持）；校驗該醫(yī)院代碼已在銀行系統中注冊醫(yī)院發(fā)起時為醫(yī)院代碼(預約平臺發(fā)發(fā)起方分支機輸），預約平臺發(fā)起為醫(yī)院代碼(必>性原醫(yī)院端流水號</MsgText/CustInfo/Acctno>無</MsgText/TrsInfo/TrfAmt</MsgText/TrsInfo/Ccy>C.6.2應答報文應答報文內容見表C.9。表C.9診療費結算應答報文內容性性發(fā)起方代碼（醫(yī)發(fā)起方分支機構應收合作機構手C.7智能候診C.7.1請求報文請求報文的主要內容見表C.10。表C.10智能候診請求報文性a)描述當前通訊接口使用的版本b)當前版本為“1.0.0”性發(fā)起方代碼（銀發(fā)起方分支機構接收方代碼（醫(yī)a)校驗該醫(yī)院代碼已在銀行系統接收方分支結構發(fā)起端流水號>>無>C.7.2應答報文應答報文的主要內容見表C.11。表C.11智能候診應答報文性</MsgText/GrpHdr/Se</MsgText/GrpHdr/Re</MsgText/QueryRetu</MsgText/QueryRetun</MsgText/QueryRetun/Item/</MsgText/QueryRetun/Ite</MsgText/QueryRetun/Ite</MsgText/QueryRetun/It</MsgText/QueryRetun/It</MsgText/QueryRetun/I</MsgText/QueryRetuC.8診療進度查詢C.8.1請求報文請求報文的主要內容見表C.12。表C.12診療進度查詢請求報文性a)描述當前通訊接口使用的版本b)當前版本為“1.0.0”發(fā)起方代碼（銀發(fā)起方分支機構接收方代碼（醫(yī)a)校驗該醫(yī)院代碼已在銀行系統接收方分支結構a)校驗該醫(yī)院代碼已在銀行系統發(fā)起端流水號>原醫(yī)院流水號（掛號時醫(yī)院返回的</MsgText/CustInfo/Acctno>性無C.8.2應答報文應答報文的主要內容見表C.13。表C.13診療進度查詢