銀醫(yī)服務(wù)接口技術(shù)規(guī)范

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