基于微信公眾號(hào)的醫(yī)學(xué)檢驗(yàn)儀器故障智能問(wèn)診系統(tǒng)

張喜紅，王玉香

（亳州職業(yè)技術(shù)學(xué)院，安徽 亳州 236800）

0 引言

醫(yī)療設(shè)備在疾病診查、臨床治療、術(shù)后評(píng)估等方面具有重要的意義，現(xiàn)已成為評(píng)價(jià)醫(yī)院醫(yī)療水平高低的關(guān)鍵指標(biāo)之一［1］。隨著醫(yī)療設(shè)備產(chǎn)業(yè)的蓬勃發(fā)展，廠家售后服務(wù)出現(xiàn)了巨大的人才缺口。招納、培養(yǎng)新人是廠家快速補(bǔ)給人才的主要渠道，然而多數(shù)醫(yī)療設(shè)備具有技術(shù)先進(jìn)、多學(xué)科交叉、知識(shí)密集、結(jié)構(gòu)復(fù)雜、集成度高等特點(diǎn)，新入職維修人員很難在短時(shí)間內(nèi)精通各類儀器的維修方法。其次，維修人員的培養(yǎng)需采用“傳、幫、帶”的模式［2］，然而現(xiàn)實(shí)情況是有經(jīng)驗(yàn)的工程師因工作繁忙，無(wú)法顧及人才培養(yǎng)工作。因此，本文開(kāi)發(fā)了一款故障智能問(wèn)診系統(tǒng)，協(xié)助新入職維修人員較早勝任維修工作。

自1968年推斷化學(xué)分子結(jié)構(gòu)的專家系統(tǒng)問(wèn)世以來(lái)，在各領(lǐng)域掀起了以人工智能專家系統(tǒng)替代真人專家工作內(nèi)容的研究熱潮。經(jīng)過(guò)多年的研究積累，故障診斷專家系統(tǒng)在機(jī)械設(shè)備、電力設(shè)備、航天設(shè)備等領(lǐng)域的應(yīng)用已日趨成熟，但大多運(yùn)行于PC機(jī)上，存在便攜性、移動(dòng)性較差的缺點(diǎn)，難以滿足工作人員外出維修作業(yè)的要求［3］。近年來(lái)，隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)的發(fā)展，特別是智能手機(jī)的普及，基于移動(dòng)終端開(kāi)發(fā)的故障診斷系統(tǒng)相繼出現(xiàn)。目前，基于移動(dòng)終端開(kāi)發(fā)的故障診斷系統(tǒng)主要有兩類：一類是基于安卓原生態(tài)APP模式，另一類是基于微信小程序或公眾號(hào)前后臺(tái)交互模式。因前者需安裝本地APP軟件，對(duì)移動(dòng)終端硬件配備有要求，相比之下后者更受青睞。其次，伴隨著圖靈API開(kāi)放應(yīng)用接口應(yīng)用平臺(tái)的出現(xiàn)，因其提供NLP服務(wù)、支持自定義知識(shí)庫(kù)，對(duì)于功能不太復(fù)雜的人工智能問(wèn)診系統(tǒng)，在開(kāi)發(fā)時(shí)為了提高效率、降低開(kāi)發(fā)難度，大多采用圖靈API服務(wù)器充當(dāng)專家系統(tǒng)推理機(jī)與知識(shí)庫(kù)后臺(tái)［4］。

基于上述背景，本文以微信公眾號(hào)為交互前端，微信后臺(tái)與自定義公眾號(hào)服務(wù)器為中間件，圖靈機(jī)器人為故障問(wèn)診后臺(tái)，設(shè)計(jì)了一款醫(yī)學(xué)檢驗(yàn)儀器故障智能問(wèn)診系統(tǒng)。

1 系統(tǒng)總體設(shè)計(jì)

故障智能問(wèn)診系統(tǒng)屬人工智能專家系統(tǒng)范疇。專家系統(tǒng)發(fā)展至今，大致可分為兩大類，一類是基于知識(shí)的專家系統(tǒng)，另一類是基于神經(jīng)網(wǎng)絡(luò)等算法的系統(tǒng)?；谥R(shí)的專家系統(tǒng)是一種將專家經(jīng)驗(yàn)知識(shí)采用某種知識(shí)表示方式（如產(chǎn)生式），建立故障現(xiàn)象與故障原因間的映射關(guān)系，并將其存儲(chǔ)到知識(shí)數(shù)據(jù)庫(kù)中，當(dāng)故障發(fā)生時(shí)，輸入故障現(xiàn)象，通過(guò)特定的推理方法從知識(shí)數(shù)據(jù)庫(kù)中推究故障原因的計(jì)算機(jī)程序［5］。鑒于醫(yī)學(xué)檢驗(yàn)儀器維修工作人員能否做好維修工作與其經(jīng)驗(yàn)積累程度呈正相關(guān)，在系統(tǒng)設(shè)計(jì)時(shí)采用基于知識(shí)的專家系統(tǒng)結(jié)構(gòu)。

基于知識(shí)的專家系統(tǒng)由人機(jī)對(duì)話前端、知識(shí)庫(kù)和推理機(jī)3部分組成。人機(jī)對(duì)話模塊是用戶發(fā)起故障問(wèn)診的交互前端，設(shè)計(jì)時(shí)應(yīng)以易于交互、方便推廣為原則。鑒于微信公眾號(hào)運(yùn)行于移動(dòng)終端、易于推廣的優(yōu)勢(shì)，在系統(tǒng)設(shè)計(jì)時(shí)選用微信公眾號(hào)作為人機(jī)對(duì)話前端［6-7］。

知識(shí)庫(kù)與推理機(jī)好比整個(gè)系統(tǒng)的大腦，自行構(gòu)建知識(shí)庫(kù)與推理機(jī)運(yùn)行平臺(tái)是一項(xiàng)艱巨的工作，且后期需要投入大量的人力物力進(jìn)行維護(hù)。鑒于醫(yī)學(xué)檢驗(yàn)儀器故障問(wèn)診系統(tǒng)的業(yè)務(wù)邏輯相對(duì)單一，在設(shè)計(jì)中選用圖靈機(jī)器人實(shí)現(xiàn)智能問(wèn)答功能，以其等效替代專家系統(tǒng)的推理機(jī)。通過(guò)行業(yè)專家訪談、文獻(xiàn)整理等多種渠道獲取各類儀器的故障排查經(jīng)驗(yàn)，并將其轉(zhuǎn)化為圖靈機(jī)器人平臺(tái)的定制化語(yǔ)料庫(kù)，作為專家系統(tǒng)的知識(shí)庫(kù)。由于圖靈服務(wù)器平臺(tái)對(duì)一個(gè)機(jī)器人所能存儲(chǔ)的自定義知識(shí)庫(kù)有容量限制，在設(shè)計(jì)時(shí)采用多賬號(hào)多機(jī)器人方式，每個(gè)機(jī)器人分別與一類檢驗(yàn)儀器的故障知識(shí)相對(duì)應(yīng)。

微信公眾號(hào)在信息交互時(shí)采用的是XML格式消息，圖靈API服務(wù)器平臺(tái)采用的是JSON格式消息，兩者之間無(wú)法直接交互，需通過(guò)一公眾號(hào)服務(wù)器進(jìn)行格式變換與中轉(zhuǎn)。基于Python開(kāi)發(fā)的Flask Web服務(wù)器框架簡(jiǎn)潔易用，在系統(tǒng)設(shè)計(jì)時(shí)采用Flask Web服務(wù)器框架構(gòu)建公眾號(hào)服務(wù)器［8-10］。最終設(shè)計(jì)的醫(yī)學(xué)檢驗(yàn)儀器故障智能問(wèn)診系統(tǒng)的系統(tǒng)結(jié)構(gòu)如圖1所示。

圖1 系統(tǒng)總體結(jié)構(gòu)框圖Fig.1 Systematic block diagram

2 系統(tǒng)關(guān)鍵環(huán)節(jié)的實(shí)現(xiàn)方法

2.1 故障知識(shí)庫(kù)的整理

多數(shù)醫(yī)學(xué)檢驗(yàn)儀器在設(shè)計(jì)時(shí)為了方便后期的維護(hù)，采用了模塊化設(shè)計(jì)的理念。即以功能為尺度將儀器劃分為相對(duì)獨(dú)立的單元模塊，各個(gè)模塊間通過(guò)總線相連進(jìn)行信號(hào)傳遞。此種設(shè)計(jì)理念促使醫(yī)學(xué)檢驗(yàn)儀器的維修內(nèi)容從元件級(jí)的維修簡(jiǎn)化為板卡級(jí)的維修，在一定程度上降低了故障排查的難度。無(wú)論是元件級(jí)維修還是板卡級(jí)維修，工程師故障診查活動(dòng)的本質(zhì)是一個(gè)由現(xiàn)象到原因的推理過(guò)程，即依據(jù)故障現(xiàn)象推斷故障原因，定位故障位置的過(guò)程。其次，同一故障現(xiàn)象可能由多種故障原因引起，即一個(gè)故障現(xiàn)象發(fā)生時(shí)，可能是由單一因素引起，也有可能是多種因素共同作用的結(jié)果。再者，引發(fā)同一故障現(xiàn)象的各種故障原因發(fā)生的概率有大有小。因此，在某一故障現(xiàn)象發(fā)生時(shí)，對(duì)各種可能原因的排查應(yīng)有先后之分。概率較大的因素稱之為常見(jiàn)故障，是故障現(xiàn)象出現(xiàn)時(shí)應(yīng)該優(yōu)先檢查的內(nèi)容；概率較小的因素稱之為罕見(jiàn)故障，是故障排查時(shí)靠后檢查的內(nèi)容。

基于上述分析，設(shè)計(jì)了如下所示的知識(shí)庫(kù)整理流程，以優(yōu)利特干化學(xué)式尿液分析儀試紙感應(yīng)模塊的故障診斷知識(shí)庫(kù)整理為例進(jìn)行說(shuō)明，具體實(shí)施步驟如下：

1）按儀器功能模塊收集故障征兆集：參照廠家說(shuō)明書(shū)，依據(jù)儀器的原理及組成結(jié)構(gòu)將儀器模塊化分解，收集各功能模塊故障時(shí)的故障征兆集。如試紙感應(yīng)模塊故障時(shí)，對(duì)應(yīng)的征兆現(xiàn)象為“放入試紙條后，撥桿不動(dòng)作！”。

2）故障征兆產(chǎn)生原因的羅列：采用產(chǎn)生式方法的邏輯，由現(xiàn)象為頂層盡可能多地羅列引起現(xiàn)象發(fā)生的原因。如：“放入試紙條后，撥桿不動(dòng)作！”對(duì)應(yīng)的原因有：紅外感應(yīng)模塊被遮擋；紅外感應(yīng)模塊線路損動(dòng)；紅外感應(yīng)模塊的紅外對(duì)管元件損壞；撥桿電機(jī)故障。

3）對(duì)故障原因進(jìn)行優(yōu)先級(jí)排序：采用專家打分或?qū)嵗y(tǒng)計(jì)方法，對(duì)某一故障現(xiàn)象對(duì)應(yīng)的多種原因按發(fā)生的概率大小進(jìn)行排序。例如：“放入試紙條后，撥桿不動(dòng)作！”這一現(xiàn)象產(chǎn)生時(shí)，經(jīng)行業(yè)專家打分，由“紅外感應(yīng)模塊被遮擋”引起的可能達(dá)80%以上；由“紅外感應(yīng)模塊線路損動(dòng)”引起的可能達(dá)60%左右；由“紅外感應(yīng)模塊紅外對(duì)管元件損壞”引起的可能不到20%；由“撥桿電機(jī)故障”引起的可能僅為5%；由此可見(jiàn)，當(dāng)“放入試紙條后，撥桿不動(dòng)作！”這一故障現(xiàn)象出現(xiàn)時(shí)，依據(jù)各原因的概率大小排列，在故障排查時(shí)，首先應(yīng)引導(dǎo)用戶先排查紅外感應(yīng)模塊是否被遮擋；如故障仍未解決，接著引導(dǎo)用戶檢查紅外感應(yīng)模塊與主控板線路間是否有接觸不良，依次類推，若故障還是未能解決才引導(dǎo)用戶做后兩項(xiàng)檢查。

2.2 圖靈機(jī)器人的接入設(shè)計(jì)

圖靈API服務(wù)器注冊(cè)一個(gè)賬號(hào)可同時(shí)創(chuàng)建5個(gè)獨(dú)立的機(jī)器人，圖靈機(jī)器人支持用戶自定義語(yǔ)料庫(kù)，一個(gè)圖靈機(jī)器人可允許用戶添加內(nèi)容容量不超過(guò)5 M，問(wèn)題條數(shù)不超過(guò)1 027條的自定義語(yǔ)料庫(kù)［11］。針對(duì)檢驗(yàn)儀器設(shè)備種類較多、故障問(wèn)診條數(shù)較多、故障知識(shí)庫(kù)所需存儲(chǔ)空間較大，及圖靈機(jī)器人自定義語(yǔ)料庫(kù)受限的情況，在接入圖靈機(jī)器人時(shí)采用多賬號(hào)、多機(jī)器人方式，即每個(gè)機(jī)器人負(fù)責(zé)一種檢驗(yàn)儀器故障問(wèn)題的回答，機(jī)器人數(shù)量的擴(kuò)增方法采用注冊(cè)多個(gè)賬號(hào)，每個(gè)賬號(hào)創(chuàng)建5個(gè)獨(dú)立的機(jī)器人實(shí)現(xiàn)；訪問(wèn)時(shí)通過(guò)“userId”參數(shù)標(biāo)識(shí)用戶賬號(hào)，通過(guò)“apiKey”標(biāo)識(shí)某一賬號(hào)下的機(jī)器人編號(hào)。

圖靈機(jī)器人對(duì)自定義語(yǔ)料的格式也有相應(yīng)的要求，語(yǔ)料庫(kù)的格式如表1所示，其中問(wèn)題長(zhǎng)度不多于64個(gè)字符，答案長(zhǎng)度不超過(guò)600個(gè)字符。所以需將文中2.1節(jié)中的原始知識(shí)庫(kù)進(jìn)行簡(jiǎn)化處理。其中“問(wèn)題”一行與2.1節(jié)中原始知識(shí)庫(kù)的故障現(xiàn)象相對(duì)應(yīng)，當(dāng)儀器故障時(shí)，是用戶向機(jī)器人發(fā)問(wèn)的首選描述方式，在內(nèi)容設(shè)計(jì)時(shí)應(yīng)采用行業(yè)專家的標(biāo)準(zhǔn)述語(yǔ)?！跋嗨茊?wèn)法”是同一問(wèn)題的不同問(wèn)法，也是體現(xiàn)機(jī)器人智力水平的重要因素，在內(nèi)容設(shè)計(jì)時(shí)要與標(biāo)準(zhǔn)述語(yǔ)的語(yǔ)義相同?！按鸢浮笔且鸸收犀F(xiàn)象的可能原因，在內(nèi)容設(shè)計(jì)時(shí)依據(jù)發(fā)生概率的優(yōu)先級(jí)按序編號(hào)羅列，用戶排除故障時(shí)按編號(hào)從小到大依次進(jìn)行。

表1 圖靈機(jī)器人自定義語(yǔ)料庫(kù)格式示例Tab.1 Examples of Turing Robot Custom Corpus format

2.3 Flask微信公眾號(hào)服務(wù)器接入的實(shí)現(xiàn)

微信公眾號(hào)為用戶提供了基礎(chǔ)模式與開(kāi)發(fā)者模式兩種模式［8］，基礎(chǔ)模式只能按公眾號(hào)的約定規(guī)則進(jìn)行簡(jiǎn)單的業(yè)務(wù)處理，本系統(tǒng)需使用開(kāi)發(fā)者模式接入自定義Web服務(wù)器，即采用“開(kāi)發(fā)者模式”+“Flask Web框架服務(wù)器”方式。Flask Web服務(wù)器框架通過(guò)簡(jiǎn)單route（）裝飾器配置便可實(shí)現(xiàn)GET、POST等多種方法的HTTP請(qǐng)求［9］。依據(jù)公眾號(hào)開(kāi)發(fā)者模式的消息交互流程，用戶接入開(kāi)發(fā)者模式可歸納為如下兩步：

1）在微信公眾號(hào)管理后臺(tái)填寫(xiě)、配置自定義服務(wù)器URL地址、Token參數(shù)，其中Token參數(shù)可自定義，但與Flask微信公眾號(hào)服務(wù)器要保持一致。

2）自定義公眾號(hào)服務(wù)器的接入校驗(yàn)，其流程是：當(dāng)用戶向微信后臺(tái)提交了開(kāi)發(fā)者模式配置請(qǐng)求后，微信后臺(tái)會(huì)通過(guò)GET方法攜帶signature、timestamp、nonce、echostr 4項(xiàng)參數(shù)，向自定義服務(wù)器發(fā)出校驗(yàn)請(qǐng)求；自定義服務(wù)器在收到請(qǐng)求后，首先將1）中填寫(xiě)Token與timestamp、nonce參數(shù)按序拼接成一個(gè)字符串后，進(jìn)行SHA1加密，接著將加密得到的字符串與signature參數(shù)對(duì)比，若二者相同則原樣返回echostr參數(shù)的內(nèi)容，代表接入驗(yàn)證成功，反之接入失敗。

2.4 微信后臺(tái)與Flask微信公眾號(hào)服務(wù)器消息交互的實(shí)現(xiàn)

微信后臺(tái)與自定義服務(wù)器之間的消息交互統(tǒng)一采用如圖2所示的XML格式模板進(jìn)行交互［12］，其中ToUserName、FromUserName與標(biāo)簽之間的內(nèi)容為收、發(fā)雙方的帳號(hào)，二者在請(qǐng)求與回應(yīng)消息時(shí)需對(duì)調(diào)，用于標(biāo)識(shí)消息的來(lái)源與去向；CreateTime為消息創(chuàng)建時(shí)間；MsgType標(biāo)簽間的內(nèi)容用于標(biāo)識(shí)消息的類型，本系統(tǒng)中只存在文本消息的交互，因此將其參數(shù)固定為“text”；Content標(biāo)簽間的內(nèi)容是具體的消息內(nèi)容。

圖2 微信后臺(tái)XML格式消息模板Fig.2 WeChat backstage XML format message template

Flask微信公眾號(hào)服務(wù)器向微信后臺(tái)回復(fù)消息的函數(shù)代碼如下所示：

2.5 Flask微信公眾號(hào)服務(wù)器與圖靈機(jī)器人消息交互的實(shí)現(xiàn)

由2.2節(jié)可知，在系統(tǒng)設(shè)計(jì)時(shí)圖靈機(jī)器人的接入采用多賬號(hào)、多機(jī)器人方式接入，一種檢驗(yàn)儀器對(duì)應(yīng)一個(gè)圖靈機(jī)器人。因此用戶在發(fā)送信息時(shí)需攜帶訪問(wèn)哪個(gè)圖靈機(jī)器人的標(biāo)志信息，具體的做法是采用“（儀器名稱）+（故障現(xiàn)象）”的格式作為公眾號(hào)前端用戶請(qǐng)求的模板，“+”前“儀器名稱”用于標(biāo)識(shí)將要訪問(wèn)的圖靈機(jī)器人，“+”后的“故障現(xiàn)象”是向?qū)?yīng)圖靈機(jī)器人提出的問(wèn)診內(nèi)容。在Flask微信公眾號(hào)服務(wù)器中事先將圖靈機(jī)器人賬號(hào)userId與圖靈機(jī)器人密鑰apiKey按儀器名稱為索引進(jìn)行定義，訪問(wèn)時(shí)可通過(guò)tl_userId［′尿液分析儀′］、tl_apiKey［′尿液分析儀′］的格式取到對(duì)應(yīng)的賬號(hào)與機(jī)器人密鑰，示例代碼如下所示。

#圖靈機(jī)器人用戶賬號(hào)：userId與機(jī)器人密鑰：apiKey的設(shè)置

Flask微信公眾號(hào)服務(wù)器故障問(wèn)診業(yè)務(wù)的處理流程如下所示：

1）微信后臺(tái)向Flask微信公眾號(hào)服務(wù)器上傳消息的請(qǐng)求方式采用POST方法，因此首先判斷來(lái)自公眾號(hào)的請(qǐng)求是否是POST請(qǐng)求消息，如果是，則從XML格式消息中分別提取ToUser-Name、FromUserName、CreateTime、MsgType、Content中的內(nèi)容。公眾號(hào)消息的解析通過(guò) xml.etree.ElementTree包實(shí)現(xiàn)，具體實(shí)現(xiàn)代碼如下所示：

2）如果內(nèi)容類型是文本消息，則以“+”為標(biāo)識(shí)拆分解析Content標(biāo)簽中的消息內(nèi)容，得到相應(yīng)機(jī)器人的賬號(hào)標(biāo)識(shí)字符串，以及故障問(wèn)診內(nèi)容字符串。具體實(shí)現(xiàn)代碼如下所示：

3）依據(jù)2）中的機(jī)器人標(biāo)識(shí)查找對(duì)應(yīng)機(jī)器人的用戶賬號(hào)userId與機(jī)器人密鑰apiKey，連同2）得到故障問(wèn)診內(nèi)容，構(gòu)造訪問(wèn)圖靈機(jī)器人的JSON格式數(shù)據(jù)包，并通過(guò)POST方式攜帶JSON格式數(shù)據(jù)包請(qǐng)求圖靈機(jī)器人響應(yīng)；圖靈機(jī)器人成功響應(yīng)后，將返回JSON格式的故障診查流程數(shù)據(jù)包。具體實(shí)現(xiàn)代碼如下所示：

4）解析步驟3）中圖靈機(jī)器人返回的JSON數(shù)據(jù)包內(nèi)容，提取包中的“故障診查建議”，將1）中的ToUserName、FromUserName對(duì)調(diào)后，構(gòu)造微信XML格式數(shù)據(jù)包，將數(shù)據(jù)返回到微信服務(wù)器端。

3 系統(tǒng)測(cè)試

在PyCharm2016.3.3中創(chuàng)建Flask微信服務(wù)器Python腳本文件，并將啟動(dòng)腳本運(yùn)行app.run（）語(yǔ)句中的host參數(shù)設(shè)為host= '0.0.0.0'，端口號(hào)參數(shù)設(shè)為port= 8 000，實(shí)現(xiàn)支持外網(wǎng)訪問(wèn)。接著使用花生殼內(nèi)網(wǎng)穿透軟件，將本機(jī)IP地址、端口號(hào)綁定到花生殼的域名上，為了與微信公眾號(hào)的規(guī)定一致，需將花生殼的外網(wǎng)端口設(shè)為80。接著將花生殼提供的Flask微信服務(wù)器域名填入微信公眾號(hào)管理后臺(tái)的對(duì)應(yīng)頁(yè)面中。關(guān)注微信公眾號(hào)后，進(jìn)行故障問(wèn)診模擬測(cè)試，圖3和圖4為部分測(cè)試結(jié)果，測(cè)試結(jié)果顯示系統(tǒng)運(yùn)行穩(wěn)定。

圖3 測(cè)試實(shí)例一Fig.3 Test example 1

圖4 測(cè)試實(shí)例二Fig.4 Test example 2

4 結(jié)語(yǔ)

本文以醫(yī)學(xué)檢驗(yàn)儀器的故障診查為例，以微信公眾號(hào)為交互前端，F(xiàn)lask Web框架公眾號(hào)服務(wù)器為中間橋梁，圖靈機(jī)器人為后臺(tái)，實(shí)現(xiàn)了一款醫(yī)學(xué)檢驗(yàn)儀器故障智能問(wèn)診系統(tǒng)。經(jīng)實(shí)際應(yīng)用測(cè)試顯示，其運(yùn)行穩(wěn)定，能為維修人員提供可靠的維修建議。本系統(tǒng)的設(shè)計(jì)方案可為快速開(kāi)發(fā)醫(yī)療設(shè)備行業(yè)的故障智能問(wèn)診系統(tǒng)提供參考。