熊 煒,閔娟娟
(九江學院計算機與大數據科學學院,九江 332005)
隨著人們生活質量的提高,越來越多的寵物走進了普羅大眾的家中。在西方國家,寵物通常被視為家庭成員與重要朋友,作為家庭的一員,寵物的健康也被人們高度關注。學者Baker 提出區域之間寵物的醫療資源是大相徑庭的,為解決寵物遠程就診問題,近年來已萌生了寵物在線平臺的概念,力圖突破時空的限制,提供專屬的醫療服務[1?4]。美國ATA 協會通過多項研究表明,伴隨著COVID?19 的出現,遠程問診得到了更多人的重視,在遠程問診技術的發展之路上,有必要將寵物先引入遠程問診作為研究[5]。
在我國,調查顯示寵物醫療已經占整體寵物服務業的29.2%[6],然而在如此巨大的市場需求下,卻隱藏著諸多問題:寵物醫療行業人才缺失、寵物醫療診所稀缺、寵物治療費用昂貴,等等[7]。在如此困境之下,改革是必然的。2018 年4 月份,國務院正式發布了《關于促進“互聯網+醫療健康”的發展意見》,互聯網+醫療成為我國醫療行業里的主流發展方向[8],其本質是線上問診的合理應用與推進線上、線下相結合的問診流程。對于寵物醫療行業而言,這種改變無疑能促進醫療資源分配的合理性,是一場傳統服務業與當下互聯網相結合的一次技術革命。
綜上所述,使傳統寵物醫療行業搭上互聯網的便車,開發寵物問診平臺有利于對當下寵物醫療資源進行統籌規劃,吸引更多合格的、優質的寵物醫院與醫師加入,通過靈活的線上問診方式充分利用醫療資源,改善分配不均的現狀。同時,可以利用智能推薦算法,結合用戶的操作進行平均加權,給予用戶智能化的推薦與人性化的流程,從而根據用戶的抉擇不斷對平臺進行正向調節[9]。
在查閱現有互聯網醫療發展文獻、對相關群眾做出擇醫傾向調查、與現有寵物線上問診類平臺進行功能分析與實際使用后,發現從聯系醫生到醫生審查病情,往往實時問診耗時更長,因此明確了“有問題及時診、線上線下強結合” 的基本方針[10]。經過分析得出,平臺的主要功能有:智能推送醫生、線上問診、查看附近的醫院、查看平臺優質醫生、平臺藥物購買、訂單管理、疾病百科等。
寵物線上平臺功能如圖1所示。

圖1 寵物線上問診平臺功能
下面對用戶登錄后的核心功能做詳細介紹:
(1)智能推送醫生。用戶登錄后,平臺會根據用戶的偏好以及用戶的歷史操作智能推送符合用戶預期需求的優質醫生。
(2)線上問診。當用戶在平臺添加好自己的寵物后,可以根據寵物現有情況對醫生專家發起圖文問診或預約線上即時問診。圖文問診中,用戶可以發送圖片以及文字對寵物病癥做出描述,適用于非急性病癥;線上即時問診針對急性病,可以與醫生進行即時的溝通,通過圖片、文字和語音的方式對病癥做出更詳細的描述。這兩種方式的混合使用,實現了“有問題及時診”這一思想,使得醫生的問診效率能在必要時達到高點。
(3)查看附近醫院。用戶可以根據寵物的醫療服務需求,通過地圖范圍定位對線下的寵物醫院進行篩選,在醫院板塊中可以看到醫院的基本介紹以及醫院內的醫生,用戶可以在線上了解醫生后,就近選擇醫院前往問診,從而推動了線上與線下的“強結合”。
(4)平臺藥物購買。用戶登錄后,可以根據醫生的建議在平臺的商店選擇藥品加入購物車或者直接購買。
在需求分析的階段,通過對目前市場的調研以及相關專業資料的查詢,得出一個合理的模型,用例圖是一個合理而直觀的方式。接下來將從管理員、用戶、醫生三個角度來探究平臺不同使用者的相應功能:
(1)管理員角色是平臺的主要管理者,負責統籌管理醫院醫生、用戶訂單與上傳疾病資訊等。其存在能夠使得平臺數據更加可靠,確保平臺的正常運作。
(2)用戶角色是平臺核心的主要需求者,用戶登錄平臺后,可以添加寵物、按條件查看寵物醫院、根據寵物情況對合適的醫生發起問診請求、評價醫生、根據醫生的建議或是自身的需求在平臺內購買相應藥品或將藥品加入購物車、對訂單進行查看與修改、對個人信息做出修改。
(3)醫生角色是平臺問診功能的主要提供者,醫生登錄后,可以對醫生信息進行修改,對接診時間做出修改,并對用戶發起的提問做出專業回復。
寵物線上問診平臺用例圖如圖2所示。

圖2 寵物線上問診平臺用例
數據庫的設計需要開發人員對系統的開發背景有整體性的了解,在設計數據庫時,要從全面去考慮問題,不應該只考慮數據庫在單個頁面上的作用,更需要從業務流程以及優化的方面對表之間的合理性做整體的考量[11]。通過探究平臺系統內實體與實體的聯系,畫出實體?聯系圖,如圖3所示。

圖3 系統實體-聯系
流程圖作為一個有效的說明工具,能夠輔助管理者做出決定,幫助確定可供選擇的行動方案,并直觀地敘述一個業務的整體運作步驟。
用戶的基本業務流程圖如圖4所示。

圖4 用戶的基本業務流程
本平臺分為微信小程序端與后臺管理端,在小程序端開發中,采用Hubuilder 與微信開發者工具作為開發工具,在開發語言上選擇以Vue為內核的uni?app框架,結合SCSS、JavaScript與uView 2.0 作為頁面樣式支撐。uni?app 作為新生的編程框架,其優勢在于一次編寫,能在多端使用,并且得益于插件庫中豐富的開源組件,使得在開發效率上也有了極大的提升。
在后臺方面選擇了當下最常用的Spring?Boot+Mybatis?plus 作為基礎框架,極大提升了開發效率,并采取抽象工廠的設計模式,使得系統將具體的類進行抽離,在編寫時只需要通過相應的抽象接口進行使用。數據庫方面,使用MySQL 與Redis,將暫時性的緩存信息存入Re?dis,減輕反復查詢的負擔,重要核心的數據存入MySQL,以確保數據的持續儲存。在安全性方面,使用JWT 生成用戶的唯一token,存入Redis中,并使用Spring Security對安全訪問進行控制,這兩項技術成熟實用,能夠減輕開發者在安全代碼上的重復工作。前后端分離的交互如圖5所示。

圖5 前后端分離交互
在用戶使用平臺的過程中,其中最重要的核心模塊有三:一是智能推薦,二是與平臺醫生的即時問診技術,三是使用Spring Security、JWT與Redis三位一體的權限認證。
3.2.1 智能推薦
本平臺采取的是推薦算法中的基于領域的算法。根據平臺的性質與實際調查,選擇了基于物品的協調過濾算法(Item CF)。相較于基于用戶的協調過濾算法(User CF),Item CF 更加關注用戶的歷史性操作數據,更能從歷史操作中挖掘出用戶的潛在興趣,給予用戶更豐富的醫生供其選擇[12]。在試驗下,Item CF 也具備良好的召回率、精確度,并同時保證了對數據的高覆蓋度[13]。其算法的本質是為用戶建設偏好文檔,假設選擇醫生A 的用戶大多數也會選擇醫生B,那么我們認為醫生A 與醫生B 相似,相似度高的醫生更符合用戶偏好,將會優先推送給用戶。這個推薦往往是穩定的,因為在醫生數量小于用戶數量的平臺上,避免了頻繁更新醫生的相似度。其中用戶關于醫生的操作記錄將被轉化為用戶對醫生偏好程度的影響因子,系統中的用戶操作對應的影響因子如表1所示。

表1 用戶操作影響因子表
假設有四名用戶A、B、C、D 對四名寵物醫生a,b,c,d進行了操作,如表2所示。

表2 用戶操作表
那么根據表1中的對應操作與影響因子相互轉化轉換,如表3所示。

表3 用戶操作對應影響因子表
此時可以通過余弦公式:
便可以計算出相應的醫生之間的相似度,但是在表2中可以發現,用戶A習慣于對每個醫生進行反復的查看與問診。這是因為某類用戶對醫生頻繁訪問與形成習慣性的問診后,便會造成影響因子數據的不規范性,此時使用余弦公式計算出的結果便不那么準確了,此時就需要算法考慮自動修正這部分數據。這里改用皮爾遜相關系數公式,原理是將用戶的操作因子抽象成為醫生的向量,再將兩個用戶操作對應的醫生向量減去它們對應的平均值,再通過余弦公式來進行計算[14]。
養生旅游業發展起步晚,沒有形成統一規劃的格局,吸引力較低。養生旅游作為一種體驗式旅游項目,游客停留時間較長,對旅游設施要求高,而旅游道的線路長,彎道大,車道窄,容易使游客感到疲倦與不適。目前,在普洱旅游道內主要以養生為主題的酒店稀少,可接待人數少,難以滿足游客需求。此外,農家樂成了主要的接待機構,缺乏規范,設施簡陋,衛生條件等不符合養生食療理念。
皮爾遜相關系數公式為:
其中:系數P即反應操作向量Ri,p與Ri,p之間的關系,當其間取值在[?1,1]之間,這個相關性可以是弱的也可以是強的[15]。皮爾遜相關系數越大,我們認為醫生向量相似度越強。當兩個向量為正相關時,在通常情況下取約定系數范圍對應強度,如表4所示。

表4 系數強度表
本例中借助Python 進行系數計算,其核心代碼如下:
通過對用戶操作矩陣的計算,我們可以得到醫生相關系數,如圖6所示。

圖6 醫生相關系數
所以在本例中,當出現新注冊的用戶E 僅查看過醫生b后,我們可以根據相似度,以醫生c、醫生a、醫生d的順序對其進行智能推薦。隨著用戶日常操作所產生的數據日益豐富,傳統協同過濾算法的表現也日趨良好[16]。至此,通過統計用戶歷史操作并進行計算便可以預測用戶對醫生的偏好,從而達到智能推薦的效果。
3.2.2 即時問診
平臺采用的即時通訊技術源于集成環信SDK,一套通訊組件內部含有多個子系統,開發難度大,開發周期長,整體的成本高昂[17]。所以對于個人開發者,有著良好可擴展性、可靠性與穩定性的第三方SDK 顯然是首選。此時,便可以獲得一套涵蓋文字、emoji 表情、語音、圖片的完善聊天頁面。然而,僅僅是一個聊天界面顯然是不夠的,我們必須要考慮兩個問題,首先是用戶與醫生在未讀的情況下,是否有未讀消息的提示,其次是如何使得這單問診在規定時間內自動結束。
為解決未讀消息的提示,系統將對兩種情況分別進行討論,第一種是當前角色在發送消息時,需要更新的是Redis 中對應角色的未讀消息。第二種是關于已讀消息,此處并不能使用慣性思維,即進入聊天界面便所有消息已讀,因為當前角色在發送消息,對方角色也同樣可能在發送消息,會造成Redis 中的未讀消息數量超出實際的情況。故只能在退出時,清空對方在Redis中發送的未讀消息數量。
為了使問診訂單在超出規定時間后自動結束,平臺在用戶開始即時問診訂單后,使用expire方法設置倒計時,將用戶與醫生的消息回復數量全部初始化為0,將其存入Redis中。注意此處訂單與消息數量不可以設置為同一個Key,否則訂單自動結束后未讀消息將會一并自毀。
即時通訊效果圖如圖7所示。

圖7 即時通訊效果
3.2.3 權限認證
身份認證是系統中的核心功能,確認合法性,確保核心資源的安全與穩定是本平臺的重要考核指標[18]。平臺實際采用的身份認證系統使用了SpringBoot+Spring Security,相較于使用Spring+Spring Security 通過控制反轉,注入依賴與面向切面編程的方式,引入SpringBoot 簡化了對于文檔的編寫,將代碼量進行了大幅度的縮減[19?20]。本平臺驗證當前角色的操作是否符合權限需求,都以在接收請求時,請求頭中攜帶的token 是否能夠在系統中解析出相應的權限字段作為判定標準。
Spring Security 的本質是由一串過濾器組成的過濾鏈,如圖8所示。

圖8 過濾鏈
在過濾鏈中,過濾器UsernamePasswordAu?thenticationFilter 承擔處理用戶在登錄頁面填寫的用戶名密碼后的請求登錄操作的功能職責。然而在平臺的登錄流程中,自帶的過濾器無法按照預期,即登錄成功后在內部響應JWT生成的token,所以需要自定義的Controller 接口接收由前端傳入的賬號與密碼,再通過UserDetail?Service 對信息進行校驗。若用戶輸入的賬號與密碼成功匹配,將通過ProviderManager 的方法生成JWT 存入Redis中完成登錄流程;若匹配失敗,則將被過濾器ExceptionTranslationFilter 捕獲,拋出異常并返回給前端。
登錄時序圖如圖9所示。

圖9 登錄時序
認證過程中出現異常的核心代碼如下:
寵物線上問診平臺實現了智能化的醫生推薦、查看篩選附近診所、線上問診、平臺購買與訂單管理等功能。系統界面簡潔大方,運行流暢,可擴展性高,Spring Security 與JWT 的結合使得平臺還有更多權限變更的操作空間。使用該平臺,不僅用戶能夠突破周邊醫療資源的匱乏困境,而且寵物也能在萬里之外獲得優質醫生的診斷,同時醫院與醫生也能通過該平臺獲取額外的知名度。目前寵物醫療與互聯網相結合在國內仍是一片巨大的藍海,相信在未來,線上寵物問診能夠讓更多養寵人士受益,助力于寵物經濟的良性發展。