基于微信小程序的檢驗查詢系統(tǒng)設(shè)計與開發(fā)

邵榮強(qiáng)，王慧敏，陳 燕，胡孔法，龔慶悅*

（1. 南京中醫(yī)藥大學(xué)人工智能與信息技術(shù)學(xué)院，江蘇 南京 210023；2. 宜興市第二人民醫(yī)院信息科，江蘇 宜興 214221）

0 引言

隨著醫(yī)療技術(shù)的快速發(fā)展，醫(yī)用檢查設(shè)備的不斷增多，為疾病的早發(fā)現(xiàn)、早診斷、早治療提供了可能。一些檢查報告（如DR，CT等）可以立等可取，然而一些檢驗報告并不是立即能有結(jié)果的，需要幾小時甚至幾天后才能取到報告。這就意味著患者或體檢客戶（以下簡稱“用戶”）可能需要往返醫(yī)院兩次或以上。我們應(yīng)該通過醫(yī)療軟件來簡化用戶查取報告的流程和環(huán)節(jié)，為用戶提供更優(yōu)質(zhì)的服務(wù)[1]。醫(yī)療軟件是是醫(yī)療活動在人類大腦思維活動的體現(xiàn)[2]，優(yōu)化就醫(yī)流程、改進(jìn)醫(yī)療質(zhì)量、保障醫(yī)療安全、提高醫(yī)院運行效率、降低消耗等諸多方面發(fā)揮了十分重要的作用[3]。隨著移動智能終端和互聯(lián)網(wǎng)技術(shù)的進(jìn)步，醫(yī)療軟件不再局限于 PC端，越來越多的醫(yī)療應(yīng)用出現(xiàn)在移動終端中。然而移動終端的技術(shù)很多，如何選擇合適的技術(shù)來實現(xiàn)用戶隨時隨地查詢自己的檢驗報告，需要我們根據(jù)應(yīng)用的特點來進(jìn)行選擇。

1 目標(biāo)分析

1.1 微信公眾號

隨著微信功能的不斷完善，一些醫(yī)院在公眾號中嵌入相應(yīng)的菜單，開發(fā)了類似于wap網(wǎng)頁來實現(xiàn)報告的查詢。為了保證用戶的合法性，用戶在登陸時需要輸入短信驗證碼和圖形驗證碼或輸入用戶名密碼，復(fù)雜的操作、低頻的使用導(dǎo)致用戶名與密碼經(jīng)常遺忘，也讓這個功能無法廣泛使用。同時網(wǎng)頁版的程序無法調(diào)用手機(jī)攝像頭、藍(lán)牙、GPS、語音等底層功能，也讓功能的擴(kuò)展受到了限制。

1.2 APP

為進(jìn)一步擴(kuò)展功能，一些醫(yī)院在使用微信公眾號的同時也開發(fā)了手機(jī)App客戶端。因為手機(jī)的操作系統(tǒng)不同，需要分別開發(fā)安卓版和IOS版，實現(xiàn)成本相對較高。同時用戶使用前需要下載和安裝相應(yīng)的APP，頻繁的APP升級亦增添了許多麻煩，這些因素均會使得用戶體驗感變差。

1.3 微信小程序

小程序基于微信平臺，有成熟的框架、組件等工具，開發(fā)周期更短且流程更簡單；無需安裝，用戶可以由掃碼等方式通過微信直接打開；無需卸載，用戶用完之后小程序會自動隱藏，無需再進(jìn)行其它操作；對于相同的查詢支持多級緩存，信息獲取的效率更高[4]。

綜上分析，微信小程序更適合移動端檢驗查詢系統(tǒng)的設(shè)計與開發(fā)。

2 功能設(shè)計

好的設(shè)計是開發(fā)程序的必要條件，微信小程序的開發(fā)也是如此。本項目的設(shè)計首先制定設(shè)計原則，然后對整個業(yè)務(wù)流程進(jìn)行梳理，并強(qiáng)調(diào)這個項目的設(shè)計注意點。

2.1 設(shè)計原則

2.1.1 經(jīng)濟(jì)、實用、面向?qū)ο笤瓌t

在保證系統(tǒng)性能和穩(wěn)定性的前提下，對現(xiàn)有醫(yī)院信息系統(tǒng)（下簡稱 HIS）中的流程盡可能地減少改動，從而實現(xiàn)降低成本的原則。本項目采用的是C#、微信開發(fā)者工具和PHP，PHP采用的是TP5框架開發(fā)，這些成熟的技術(shù)有更多的控件和開發(fā)的案例，使項目開發(fā)效率更為高效。

本項目采取三端分離。前端確保系統(tǒng)具有友好的用戶界面，后臺服務(wù)器端具有規(guī)范、通用的理念，管理端具有便捷易用的特點，目的是讓三端均便于掌握、使用和維護(hù)，且能解決具體的實際問題。

為了使開發(fā)的軟件具有能夠快速適應(yīng)變化的敏捷性，我們必須掌握面向?qū)ο蟮木韬烷_放封閉原則。面向?qū)ο蟪绦蛟O(shè)計的精髓包括抽象、封裝、繼承、多態(tài)及模板[5]；開放封閉原則是面向?qū)ο笤O(shè)計的核心，即對擴(kuò)展開放，對修改封閉。

2.1.2 投資保護(hù)原則

為了大限度地保護(hù)信息系統(tǒng)的投資，本項目充分利用現(xiàn)有的信息資源接口（webservice 服務(wù)），并將其作為統(tǒng)一的接口支持方式，這樣既保證了數(shù)據(jù)的一致性，同時也節(jié)約了軟件開發(fā)的工作量和硬件投入。

2.1.3 安全、可靠原則

網(wǎng)絡(luò)空間安全和公眾權(quán)益的重要性與日俱增，軟件安全逐漸演變?yōu)檎麄€軟件生態(tài)系統(tǒng)的體系安全，涵蓋了平臺、軟件和數(shù)據(jù)等諸多維度[6]。安全可靠是本項目所遵循的一條重要原則。利用微信的認(rèn)證體系，建立嚴(yán)格的網(wǎng)絡(luò)用戶的權(quán)限體系，從而保數(shù)據(jù)信息的安全可靠性。

2.2 流程設(shè)計

業(yè)務(wù)的梳理與開發(fā)主要分兩類，一是每一類用戶分別參與哪些業(yè)務(wù)，二是一個業(yè)務(wù)分別有哪些用戶參與[7]，需求理解是軟件工程中最為重要的一步，他決定者軟件開發(fā)是否能達(dá)到預(yù)期目的[8]。基于小程序的檢驗項目查詢涉及登陸驗證、綁定用戶、信息查詢?nèi)齻€步驟，在保障用戶隱私的情況下隨時隨地可查詢相應(yīng)的檢驗報告。

2.2.1 登陸驗證

醫(yī)生開立了檢驗檢查申請單（下簡稱申請單），用戶可掃描微信小程序二維碼進(jìn)入微信小程序，用戶登陸微信時獲取一個 code并發(fā)送給小程序服務(wù)器，后者根據(jù)這個code到微信服務(wù)器換取這個小程序的唯一openid和sessionid，同時小程序服務(wù)器生成一個有時效性的token（或稱令牌）[9]（圖1）。業(yè)務(wù)邏輯層的API中正是通過用戶所攜帶的令牌來鑒別用戶身份。令牌是否合法，是否有效，是否有權(quán)限，將決定用戶是否可以執(zhí)行相應(yīng)的操作。而在此過程中起著重要作用的 token令牌是由 32位隨機(jī)數(shù)、時間戳、salt加密而成，且有時效性，結(jié)合微信的認(rèn)證體系，比起傳統(tǒng)的用戶名與密碼登陸安全性更高。整個登陸驗證過程由小程序服務(wù)器與微信服務(wù)器自動完成，用戶操作非常簡單。

2.2.2 綁定用戶

每個實名認(rèn)證的微信號均有綁定的手機(jī)號，同時在醫(yī)院就診也采取了實名制并留有手機(jī)號碼，通過系統(tǒng)的自動匹配手機(jī)號，用戶即可查詢相關(guān)的檢驗信息。如果微信綁定的手機(jī)號與醫(yī)院就診所留的手機(jī)號不一致，也可通過手機(jī)的短信號碼驗證來獲取授權(quán)。

圖1 Token生成流程圖Fig.1 Token generation flow chart

2.2.3 信息查詢

在用戶登陸查詢檢驗結(jié)果時，如小程序客戶端攜帶的 token已失效，可向微信服務(wù)器申請新的code，并發(fā)給小程序服務(wù)器，后者到微信服務(wù)器上換取appid；如小程序客戶端攜帶token未失效則小程序服務(wù)器可在緩存中根據(jù) token查詢出相應(yīng)的appid。而appid可以驗證用戶的身份真實、有效和權(quán)限，在用戶免密登陸的情況下有效地保障了患者信息的安全性。查詢結(jié)果顯示中僅顯示用戶姓名的首字母，來進(jìn)一步保證檢驗信息的隱私性。

2.3 設(shè)計注意點

2.3.1 安全第一

對于傳統(tǒng)的互聯(lián)網(wǎng)終端產(chǎn)品，大多采取獨立的登陸系統(tǒng)來確保系統(tǒng)的安全，通過手機(jī)短信的驗證，圖形數(shù)字的識別，復(fù)雜的密碼策略。在實施初期可能會取得較好的安全水平，隨著技術(shù)的發(fā)展，黑客技術(shù)也逐漸提高，在多年前看起來固若金湯的系統(tǒng)可能會變得相對不安全，一年多前的勒索病毒面就是一個很好的例子，所以安全防護(hù)的策略也得定期更新。

本項目對于用戶而言是典型的低頻應(yīng)用，投入的技術(shù)、資金和精力遠(yuǎn)不如阿里、美團(tuán)、微信的高頻應(yīng)用。借助成熟穩(wěn)定的微信認(rèn)證系統(tǒng)來加強(qiáng)應(yīng)用安全是一個很好的解決方案。在這個系統(tǒng)中，微信不僅對用戶有實名認(rèn)證，同時對微信小程序開發(fā)過程中應(yīng)用的不安全協(xié)議也會有及時的提醒，例如接入微信服務(wù)器必須用安全性更高的HTTPS協(xié)議，而不是HTTP協(xié)議。

2.3.2 操作簡便

本項目的操作可用12字形容：“登陸便捷，綁定簡單，查詢方便”。

微信使用廣泛，其中一個最大的原因就是登陸便捷，沒有復(fù)雜的驗證碼、密碼等繁瑣的操作。基于微信小程序的檢驗查詢功能也繼承了它登陸簡單的優(yōu)點。代表用戶身份的信息appid和token分別是由微信服務(wù)器與小程序服務(wù)器產(chǎn)生，可自動完成身份校驗并快速登陸。在小程序中獲取微信號實名認(rèn)證的手機(jī)號，與用戶實名就診信息實現(xiàn)自動綁定，并且一次綁定，永久有效。在查詢報告時，用戶僅需登陸微信小程序，小程序服務(wù)器將自動驗證和判斷權(quán)限，一次點擊即可完成報告的查閱。無論在登陸、綁定還是查詢的環(huán)節(jié)，用戶操作步驟均很便捷，真正實現(xiàn)智慧服務(wù)，方便用戶。

2.3.3 注重體驗

部分老用戶所做的檢驗項目較多，一次查詢?nèi)绻糠祷乜赡軙绊懹脩舻捏w驗。為解決這個問題，本項目對查詢進(jìn)行分次加載，首先返回的是最近的10次檢驗信息，通過下拉事件對查詢信息進(jìn)行多次加載，減輕服務(wù)器壓力的同時也改進(jìn)了用戶的體驗。

3 開發(fā)與實施

為了將來功能擴(kuò)展的需要，本項目全棧開發(fā)的過程中采用了“高內(nèi)聚低耦合”的思想，通過三層架構(gòu)（3-tier architecture）將整個業(yè)務(wù)應(yīng)用從下至上劃分為：數(shù)據(jù)訪問層（Data access layer）、業(yè)務(wù)邏輯層（Business Logic Layer）、界面層（User Interface layer）。

3.1 數(shù)據(jù)訪問層

本項目的的數(shù)據(jù)來源分兩部分，一是HIS中的醫(yī)療信息，即本項目中所涉及的患者基本信息及檢驗信息。二是用戶的注冊和授權(quán)信息。

我院原有的APP與網(wǎng)站的醫(yī)療信息數(shù)據(jù)源是通過webservice發(fā)布，為保證數(shù)據(jù)的一致性，本項目中API服務(wù)也是基于現(xiàn)有的webservice服務(wù)來獲取醫(yī)療信息。

用戶的注冊和授權(quán)信息是在本項目運營過程中產(chǎn)生的，為保障數(shù)據(jù)獲取的便捷與穩(wěn)定性，本項目單獨建立了 mysql數(shù)據(jù)庫用于保存運營信息。微信小程序服務(wù)器使用PHP框架TP5開發(fā)，后者集成了常用數(shù)據(jù)庫的驅(qū)動[10]。

3.2 業(yè)務(wù)邏輯層

本項目的業(yè)務(wù)邏輯層是API接口層，它上接表示層，下接數(shù)據(jù)庫訪問層。也是本項目最為復(fù)雜的部分，開發(fā)業(yè)務(wù)邏輯層有以下注意點。

3.2.1 版本號的控制

任何軟件項目，只要它長期使用，必然會遇到升級和版本更新的時刻，像本項目中涉及的API接口正式運營后，需要注意將來升級時對新老版本的同時支持，也就是要注意開閉原則，對擴(kuò)展是開放的，對修改是封閉的，對擴(kuò)展出來的新版本必須讓調(diào)用方有一個平滑的切換過程。本項目對不同控制器設(shè)置了不同的路由，對于調(diào)用方僅通過URL中的版本號標(biāo)識即可完成調(diào)用不同的控制器。

3.2.2 業(yè)務(wù)層的擴(kuò)展性

考慮到本項目邏輯層的API不僅僅是滿足當(dāng)前的小程序的檢驗查詢功能，所以需要提高業(yè)務(wù)邏輯層的復(fù)用性和內(nèi)聚性，故對一些常用的類進(jìn)行了封裝。封裝在簡化代碼的同時，也規(guī)范了代碼的書寫，提高了代碼的易讀性，調(diào)試更為方便，有利于將來業(yè)務(wù)層的維護(hù)與擴(kuò)展。

3.2.3 URL語義化處理

在本項目中開發(fā)API接口均通過URL的方式給微信小程序和將來可能的第三方開發(fā)者使用，語義化處理URL不僅讓API接口更通俗易懂，而且隱藏了服務(wù)的物理路徑，提高了安全性。

3.2.4 API接口使用的效率

在正式生產(chǎn)過程中，必須考慮到返回數(shù)據(jù)量大小的合理性，提高服務(wù)的效率。

從數(shù)據(jù)角度而言，一次業(yè)務(wù)多次連接數(shù)據(jù)庫對數(shù)據(jù)訪問層壓力更大。當(dāng)一個業(yè)務(wù)需要的數(shù)據(jù)量相對較小時，可以遵循“同一業(yè)務(wù)，一次查詢，本地處理”原則，將這個業(yè)務(wù)所可能涉及的數(shù)據(jù)可以一次性查出，保存于表示層本地緩存，然后表示層根據(jù)顯示的要求進(jìn)行二次處理。

對于一個業(yè)務(wù)查詢也不是返回的數(shù)據(jù)越多越好。本項目采取的策略是通過入?yún)硐薅ǚ祷財?shù)據(jù)的記錄數(shù)并讓表示層進(jìn)行分屏顯示處理。

3.3 表示層

3.3.1 表示層的架構(gòu)

本項目表示層是微信小程序，在小程序開發(fā)過程中采用了MVC架構(gòu)，MVC是一個設(shè)計模式，即模型、視圖和控制器[11-13]。view負(fù)責(zé)前端界面，是微信小程序的手機(jī)終端小程序的展示界面，由wxml和wxss文件組成。controller控制view與model之間的數(shù)據(jù)交互，由小程序的js文件組成；Model則通過https協(xié)議來調(diào)用API接口提供的數(shù)據(jù)（圖2）。為保證用戶的體驗感，小程序通過異步和回調(diào)函數(shù)的方式，確保程序的及時響應(yīng)和穩(wěn)定性。

3.3.2 表示層的顯示與交互

圖2 微信小程序表示層架構(gòu)圖Fig.2 Wechat applet presentation layer architecture

表示層的顯示需要數(shù)據(jù)，微信小程序通過js文件以URL向API請求數(shù)據(jù)。Js文件得到數(shù)據(jù)后通過數(shù)據(jù)綁定的方式返回給wxml顯示。

表示層同時需要與用戶交互，用戶通過點擊界面上的控件，從而觸發(fā)相應(yīng)控件上的事件（event），在js的event中可取得頁面控件中的自定義屬性，并引發(fā)相應(yīng)的處理方法，將處理后的回傳屬性重新做數(shù)據(jù)綁定，從而改變用戶界面的顯示來響應(yīng)用戶的操作。

4 結(jié)果

由表1（數(shù)據(jù)詳見附件）可以看出，從2019年11月08日至2019年12月08日，線上查詢檢驗的比例呈增長趨勢，同時線下到醫(yī)院取報告的比例也明顯下降。如表2所示，通過SPSS軟件對兩個比例的增減進(jìn)行雙變量相關(guān)分析，相關(guān)系數(shù)選擇Spearman，分析結(jié)果顯示相關(guān)系數(shù) r=-0.925，P=0.000＜0.001，可以認(rèn)為線上比例的增加與線下比例的下降呈負(fù)向直線相關(guān)，即通過微信小程序線上查詢檢驗可減少用戶現(xiàn)場取報告的人次數(shù)。

表1 線上與線下查詢?nèi)藬?shù)與比例對比表（詳見附件）Tab.1 Comparison of the number and proportion of online and offline queries (see Appendix for details)

表2 SPSS雙變量相關(guān)分析圖Tab.2 SPSS bivariate correlation analysis chart

5 結(jié)論

微信小程序在醫(yī)療領(lǐng)域中的應(yīng)用，為用戶提供高效、穩(wěn)定的智慧醫(yī)院服務(wù)，提升用戶的就醫(yī)體驗。2019年3月，國家衛(wèi)健委明確了智慧醫(yī)院的范圍主要包括三大領(lǐng)域：面向醫(yī)務(wù)人員的“智慧醫(yī)療”、面向患者的“智慧服務(wù)”、面向醫(yī)院管理的“智慧管理”[14]。面向患者的智慧服務(wù)是為了患者就診過程更加方便和快捷。在醫(yī)院的智慧服務(wù)方面，本項目基于微信小程序的檢驗結(jié)果查詢功能的設(shè)計與開發(fā)是一個很好的嘗試，可以利用現(xiàn)有的開發(fā)成果，進(jìn)一步拓展其使用范圍，不僅讓用戶可以在移動終端通過小程序查詢檢驗，還可進(jìn)一步實現(xiàn)小程序端的預(yù)約掛號、排隊叫號、問卷調(diào)查、查詢既往病史，并根據(jù)大數(shù)據(jù)給出合理的建議等功能，讓患者可以真正享受到智慧服務(wù)。