盧道兵， 卜平，姜雪峰

1. 南京醫(yī)科大學(xué)附屬淮安第一醫(yī)院 a. 信息中心；b. 感管處，江蘇 淮安 223300；2. 衛(wèi)寧健康科技集團(tuán)股份有限公司，上海 200072

引言

傳染病上報(bào)是為國(guó)家提供傳染病發(fā)生、發(fā)展信息的重要渠道，是政府準(zhǔn)確掌握疫情動(dòng)態(tài)、及時(shí)正確地進(jìn)行決策并采取預(yù)防控制措施的重要依據(jù)[1]。然而，傳統(tǒng)的傳染病二次轉(zhuǎn)報(bào)國(guó)家平臺(tái)的手工方式因存在漏報(bào)、誤報(bào)、重報(bào)和延時(shí)長(zhǎng)等問(wèn)題，已經(jīng)遠(yuǎn)遠(yuǎn)不能適應(yīng)信息化快速發(fā)展的今天[2]。盡管葉俊等[3]及顏玉炳等[4]提出將內(nèi)網(wǎng)報(bào)告卡內(nèi)容導(dǎo)出生成可擴(kuò)展標(biāo)記語(yǔ)言（Extensible Markup Language，XML）格式文件后，再通過(guò)外網(wǎng)將XML文件內(nèi)容映射到國(guó)家疾控平臺(tái)（CDC）網(wǎng)頁(yè)的控件上。雖然避免了二次手工上報(bào)所引起的錯(cuò)誤。但是仍然存在上報(bào)延時(shí)和漏報(bào)或重報(bào)的現(xiàn)象。為徹底解決傳染病上報(bào)國(guó)家平臺(tái)的準(zhǔn)確性和實(shí)時(shí)性問(wèn)題，本文提出通過(guò)接口功能，將內(nèi)網(wǎng)審核后的傳染病報(bào)卡內(nèi)容直報(bào)至省傳染病信息平臺(tái)（簡(jiǎn)稱(chēng)“省平臺(tái)”），省平臺(tái)與國(guó)家平臺(tái)已經(jīng)聯(lián)網(wǎng)對(duì)接，進(jìn)而轉(zhuǎn)發(fā)至國(guó)家平臺(tái)。

2017年江蘇省疾病預(yù)防控制中心制定《江蘇省法定傳染病數(shù)據(jù)自動(dòng)報(bào)告工作規(guī)范（2016年版）》（蘇疾控〔2016〕14號(hào)）[5]，要求推進(jìn)全省區(qū)域健康信息平臺(tái)和醫(yī)療機(jī)構(gòu)HIS系統(tǒng)優(yōu)化升級(jí)和改造工作，指導(dǎo)縣（市、區(qū)）級(jí)區(qū)域健康信息平臺(tái)和二、三級(jí)醫(yī)院HIS對(duì)接省級(jí)傳染病信息平臺(tái)數(shù)據(jù)工作，實(shí)現(xiàn)法定傳染病數(shù)據(jù)自動(dòng)報(bào)告。

本文依據(jù)省廳相關(guān)文件規(guī)定及接口規(guī)范，新增臨床信息系統(tǒng)（Clinical Information System，CIS）傳染病內(nèi)外網(wǎng)網(wǎng)絡(luò)直報(bào)接口功能，使醫(yī)院端的傳染病報(bào)告卡內(nèi)容直接上傳省平臺(tái)成為現(xiàn)實(shí)。

1 數(shù)據(jù)上報(bào)

1.1 接口流程

省內(nèi)各級(jí)醫(yī)療機(jī)構(gòu)或公衛(wèi)部門(mén)將待上傳的數(shù)據(jù)封裝成XML格式并加密后上傳至省平臺(tái)，省平臺(tái)對(duì)提交的信息驗(yàn)證其合法性，成功后進(jìn)行解密并校驗(yàn)數(shù)據(jù)的邏輯性。如圖1所示。

圖1 接口流程圖

1.2 數(shù)據(jù)交換

在數(shù)據(jù)交換接口中，系統(tǒng)針對(duì)數(shù)據(jù)交換提供統(tǒng)一操作函數(shù)ReportCard。根據(jù)語(yǔ)言規(guī)范，此操作表達(dá)方式如下：byte[] ReportCard(String userName, String passWord, String certCode, byte[] data)，主要有4個(gè)入?yún)ⅲ?個(gè)出參，各參數(shù)說(shuō)明如表1所示。

表1 RreportCard函數(shù)參數(shù)

2 接口通訊技術(shù)

通過(guò)適配器，客戶端連接到前置機(jī)開(kāi)放的Web Service，在同步傳輸技術(shù)中使用下面的服務(wù)調(diào)用。如圖2所示。

圖2 Web Service服務(wù)調(diào)用流程

SOAP[6‐7]（Simple Object Access Protocol）簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議，是一種輕量的、簡(jiǎn)單的、基于XML（標(biāo)準(zhǔn)通用標(biāo)記語(yǔ)言下的一個(gè)子集）的協(xié)議，它被設(shè)計(jì)成在Web上交換結(jié)構(gòu)化的信息,并提供了標(biāo)準(zhǔn)的RPC方法來(lái)調(diào)用Web Service。WSDL[8]（Web Services Description Language） 是一種使用 XML 編寫(xiě)的文檔，用于描述Web Service及其函數(shù)、參數(shù)和返回值,在客戶端生成調(diào)用服務(wù)器接口的方法。UDDI[9]（Universal Description Discovery and Integration）是一種用于描述、發(fā)現(xiàn)、集成Web Service協(xié)議棧的技術(shù)，包括：UDDI數(shù)據(jù)模型、UDDI API和UDDI注冊(cè)服務(wù)三個(gè)方面。WebService[10‐14]是一個(gè)平臺(tái)獨(dú)立的、低耦合的、自包含的、基于可編程的Web的應(yīng)用程序。

3 接口代碼（住院部分）

4 數(shù)據(jù)安全

4.1 簽名機(jī)制

簽名采用MD5[15‐16]的方式。生成待簽名字符串，請(qǐng)求參數(shù)格式如下：

對(duì)XML串里的每一個(gè)值從a到z的順序排序，若遇到相同首字母，則看第二個(gè)字母，以此類(lèi)推。排序完成之后，再把所有數(shù)組值以“&”字符連接起來(lái)，并將KEY值加在最后面一起加簽。排序完成之后，格式為：

FUN_CODE=1001&REQ_ENCRYPTED=ADqweJsq34A SODU912IJ312LJ123J1291281829FB12890102s90ad0180D1 231S&USER_ID=000000&KEY=XXX

上述的串就是待簽名的字符串，加簽完成后放到SIGN字段中。

4.2 加密機(jī)制

對(duì)稱(chēng)加密，使用的算法為AES。接口請(qǐng)求包采用整體加密方式，即AES加密和解密。此外，采用PKCS5Padding作為補(bǔ)碼，key為16位，并對(duì)加密的內(nèi)容使用BASE64做轉(zhuǎn)碼功能，同時(shí)能起到2次加密的作用。具體格式如下：

將業(yè)務(wù)參數(shù)REQ節(jié)點(diǎn)的內(nèi)容采用AES加密方式進(jìn)行加密，和“帶加密的字符串”REQ_ENCRYPTED相對(duì)應(yīng)。

5 接口應(yīng)用

5.1 傳染病信息填報(bào)

傳染病報(bào)告信息登記分門(mén)診和住院兩部分，以住院為例。若臨床醫(yī)生對(duì)某個(gè)患者輸入傳染病相關(guān)診斷并提交后，根據(jù)CIS住院醫(yī)生站中設(shè)定的傳染病報(bào)卡規(guī)則，系統(tǒng)將自動(dòng)彈出傳染病上報(bào)信息登記界面，如圖3所示。報(bào)卡界面上患者基本信息由系統(tǒng)自動(dòng)填充，無(wú)需醫(yī)生手動(dòng)錄入。其余選項(xiàng)尤其是必填的項(xiàng)目，需要報(bào)告醫(yī)師逐一填寫(xiě)，正確登記完成后方可提交成功；其次，為防止重報(bào)，系統(tǒng)對(duì)患者上報(bào)過(guò)的傳染病信息增加記憶功能，無(wú)論該患者在門(mén)診或住院上報(bào)過(guò)某個(gè)病種的傳染病報(bào)卡，在住院或門(mén)診對(duì)同一患者已上報(bào)過(guò)的相同病種傳染病，系統(tǒng)僅彈框提示“該患者已于*年*月*日*醫(yī)師上報(bào)過(guò)”，不再?gòu)?qiáng)制彈卡要求上報(bào)。

圖3 傳染病報(bào)告卡填報(bào)界面

5.2 傳染病審核及上報(bào)（直報(bào)）

感管處對(duì)臨床醫(yī)師提交后的傳染病報(bào)告卡內(nèi)容進(jìn)行審核，如圖4所示。審核人員分別打開(kāi)每份報(bào)告卡內(nèi)容，逐一進(jìn)行審核。若為艾滋病或梅毒等傳染病不僅要審核主卡，還要審核副卡內(nèi)容。根據(jù)審核結(jié)果，分為審核通過(guò)、審核未通過(guò)和作廢三個(gè)按鈕功能。對(duì)于審核未通過(guò)或作廢的報(bào)告卡，審核人員通常會(huì)給出審核意見(jiàn)并電話告知報(bào)卡醫(yī)生審核不通過(guò)或作廢的原因，以便下次上報(bào)時(shí)增強(qiáng)報(bào)卡正確率。經(jīng)審核通過(guò)的合格報(bào)告卡，審核人員只需點(diǎn)擊審核界面上的“上報(bào)”按鈕，即可將該報(bào)告卡內(nèi)容通過(guò)接口，直接上報(bào)給省平臺(tái)服務(wù)器，無(wú)需再到外網(wǎng)進(jìn)行手工轉(zhuǎn)報(bào)。

圖4 傳染病報(bào)告卡審核及上報(bào)界面

6 應(yīng)用效果

6.1 傳染病上報(bào)差錯(cuò)統(tǒng)計(jì)

傳染病上報(bào)差錯(cuò)是指粗心大意，不按規(guī)章制度操作或技術(shù)水平低而發(fā)生差錯(cuò)，對(duì)國(guó)家疾控平臺(tái)的數(shù)據(jù)真實(shí)性產(chǎn)生直接或間接影響，但未造成嚴(yán)重不良后果者。傳染病上報(bào)差錯(cuò)主要有報(bào)告卡誤報(bào)、漏報(bào)和重報(bào)等。通過(guò)隨機(jī)抽取實(shí)施傳染病接口上報(bào)歸檔報(bào)告卡1000例。結(jié)果顯示，傳染病接口上報(bào)，無(wú)一例上報(bào)差錯(cuò)。

6.2 傳染病上報(bào)時(shí)間統(tǒng)計(jì)

傳染病上報(bào)時(shí)間主要體現(xiàn)在報(bào)告卡審核以及是否要進(jìn)行二次轉(zhuǎn)錄上報(bào)等環(huán)節(jié)。傳染病手工上報(bào)模式不僅要對(duì)內(nèi)網(wǎng)的報(bào)告卡內(nèi)容進(jìn)行審核，還要通過(guò)VPN連接到CDC平臺(tái)上再次對(duì)報(bào)告卡進(jìn)行錄入、審核和上報(bào)等過(guò)程。而傳染病接口上報(bào)僅需在內(nèi)網(wǎng)對(duì)報(bào)告卡進(jìn)行審核和上報(bào)。兩組比較，差異有統(tǒng)計(jì)學(xué)意義（P<0.05），比較結(jié)果如表2所示。

表2 傳染病上報(bào)平均時(shí)間（s）

7 討論

傳染病接口系統(tǒng)顯著提升了傳染病上報(bào)的準(zhǔn)確性。傳統(tǒng)的手工上報(bào)為內(nèi)網(wǎng)審核成功后，再打開(kāi)外網(wǎng)CDC網(wǎng)站，對(duì)審核通過(guò)的報(bào)卡內(nèi)容打印出來(lái)再到CDC網(wǎng)站上依次重新錄入上報(bào)一遍。這過(guò)程增加了誤報(bào)的可能，而且潛藏漏報(bào)和重報(bào)的風(fēng)險(xiǎn)存在。但是，傳染病接口系統(tǒng)上線以來(lái)，感管處審核人員只需在內(nèi)網(wǎng)中對(duì)報(bào)告卡內(nèi)容進(jìn)行仔細(xì)審核，審核通過(guò)后僅需點(diǎn)擊審核界面上的上報(bào)按鈕即可直報(bào)省平臺(tái)，無(wú)需在外網(wǎng)上手工再次轉(zhuǎn)錄上報(bào)一次。這樣杜絕了因二次轉(zhuǎn)報(bào)而引起的誤報(bào)、漏報(bào)和重報(bào)的問(wèn)題。因此，傳染病接口系統(tǒng)顯著提升了傳染病上報(bào)的準(zhǔn)確性。

傳染病接口系統(tǒng)大大提高了傳染病上報(bào)的實(shí)時(shí)性。因傳染病本身的特性要求病例監(jiān)測(cè)的敏感性和疫情報(bào)告的及時(shí)性，做到“早發(fā)現(xiàn)、早報(bào)告、早隔離、早治療”。而傳統(tǒng)的手工上報(bào)方式由于存在二次上報(bào)，這樣將無(wú)形中增加了每份報(bào)告上報(bào)的延時(shí)性，不符合傳染病報(bào)告的要求。相反，傳染病接口上報(bào)模式只需在內(nèi)網(wǎng)程序的報(bào)告卡審核界面上即可完成上報(bào)，無(wú)需再到外網(wǎng)CDC上再次手動(dòng)上報(bào)一次。這樣將大大提高傳染病上報(bào)的實(shí)時(shí)性。

傳染病接口系統(tǒng)減輕了審核人員工作強(qiáng)度，并提升了工作效率。據(jù)統(tǒng)計(jì)，傳統(tǒng)手工上報(bào)一份傳染病報(bào)告需要額外增加打開(kāi)互聯(lián)網(wǎng)、VPN登錄CDC網(wǎng)站、手動(dòng)錄入報(bào)告、審核及上報(bào)等環(huán)節(jié)，這過(guò)程大概需要5～6 min/例，而接口上報(bào)可以省略此步驟操作。按照2019年我院報(bào)告的法定傳染病病例數(shù)量1130例計(jì)算，可節(jié)省約103.6 h（約13 d）的手工錄入時(shí)間。所以，傳染病接口上報(bào)在減輕了審核人員工作強(qiáng)度的同時(shí)，也提升了工作效率。

8 總結(jié)和展望

江蘇省法定傳染病自動(dòng)上報(bào)系統(tǒng)接口模式上線以來(lái)，因報(bào)告卡在內(nèi)網(wǎng)審核后，通過(guò)審核界面的“上報(bào)”按鈕可以將此報(bào)告卡內(nèi)容直報(bào)省平臺(tái)，再由省自動(dòng)轉(zhuǎn)發(fā)至國(guó)家疾控中心。所有這些操作均通過(guò)接口自動(dòng)轉(zhuǎn)發(fā)傳送，中間過(guò)程無(wú)需人為干預(yù)。這樣不僅解決了傳染病上報(bào)的準(zhǔn)確性。同時(shí)，也大大提高了傳染病上報(bào)的實(shí)時(shí)性，并顯著提升審核人員的工作效率。因此，傳染病報(bào)告接口系統(tǒng)的上線，能夠準(zhǔn)確、實(shí)時(shí)地上報(bào)傳染病疫情，為國(guó)家及時(shí)制定防控措施和精準(zhǔn)施策方案提供科學(xué)依據(jù)。

然而，江蘇省法定傳染病上報(bào)系統(tǒng)接口的應(yīng)用因上線時(shí)間短，經(jīng)驗(yàn)不足，在運(yùn)行中也曾暴露出一些問(wèn)題，如連接省平臺(tái)的各地專(zhuān)線帶寬受限，偶爾出現(xiàn)數(shù)據(jù)上傳受阻。需要提高各地連接到省平臺(tái)的專(zhuān)線帶寬，同時(shí)要加大路由轉(zhuǎn)發(fā)功能。