基于J2EE的延伸護(hù)理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

黃云霞++王丹志

摘要：現(xiàn)階段，護(hù)理服務(wù)僅局限于患者住院階段，僅有3%的醫(yī)院會(huì)提供院外的延伸護(hù)理服務(wù)，且大多局限于通過(guò)電話(huà)、短信等形式進(jìn)行，這種雙盲的交流形式很容易導(dǎo)致信息不對(duì)稱(chēng)，從而產(chǎn)生諸多問(wèn)題。為了減少傳統(tǒng)的延伸護(hù)理服務(wù)模式所帶來(lái)的問(wèn)題，提升患者出院后的康復(fù)效果，本文提出了將互聯(lián)網(wǎng)技術(shù)應(yīng)用于延伸護(hù)理服務(wù)環(huán)節(jié)，并引申出“健康日記”、“健康秘書(shū)”等全新的理念，通過(guò)建立護(hù)理人員與患者的個(gè)性服務(wù)關(guān)系來(lái)實(shí)現(xiàn)對(duì)患者專(zhuān)業(yè)化、精細(xì)化的全方位護(hù)理服務(wù)。系統(tǒng)采用SpringMVC+Spring+Hibernate相結(jié)合的框架進(jìn)行開(kāi)發(fā)，融合了CDN加速、DES傳輸加密以及實(shí)時(shí)通訊等技術(shù)，并針對(duì)移動(dòng)平臺(tái)進(jìn)行優(yōu)化以適應(yīng)更為廣闊的用戶(hù)群體。目前，本系統(tǒng)已經(jīng)在北京301醫(yī)院代謝綜合征科室進(jìn)行了試驗(yàn)性應(yīng)用，并取得了良好的效果。

關(guān)鍵詞：計(jì)算機(jī)應(yīng)用；延伸護(hù)理；健康秘書(shū)；J2EE架構(gòu)

中圖分類(lèi)號(hào)：TP311

文獻(xiàn)標(biāo)識(shí)碼：A

DOI： 10.3969/j.issn.1003-6970.2016.01.009

0 引言

延伸護(hù)理服務(wù)是通過(guò)一系列的護(hù)理措施用以確保患者在不同的健康照護(hù)場(chǎng)所（如從醫(yī)院到家庭）及同一健康照護(hù)場(chǎng)所（如醫(yī)院的不同科室）受到不同水平的協(xié)作性與連續(xù)性的照護(hù)，通常是患者出院后，專(zhuān)業(yè)的護(hù)理人員為其制定合理的康復(fù)護(hù)理方案，并進(jìn)行后續(xù)的隨訪與指導(dǎo)，幫助患者早日康復(fù)，提高患者的生活質(zhì)量及幸福指數(shù)。

延伸護(hù)理服務(wù)逐步信息化經(jīng)歷了一個(gè)漫長(zhǎng)的歷程，國(guó)內(nèi)外也都做了相應(yīng)的探索。2000年左右美國(guó)開(kāi)始構(gòu)建延續(xù)護(hù)理概念模型，提出了延續(xù)護(hù)理的兩個(gè)核心要素：1、針對(duì)個(gè)體的衛(wèi)生服務(wù)；2、服務(wù)時(shí)間上的延續(xù)性。與此同時(shí)，美國(guó)、西班牙等國(guó)針對(duì)延伸護(hù)理服務(wù)也研發(fā)了相應(yīng)的信息系統(tǒng)，用于保存患者健康檔案，為其提供及時(shí)有效的服務(wù)。

中國(guó)在延伸護(hù)理的信息化研究上起步較晚，2002年香港理工大學(xué)黃金月教授才將延伸護(hù)理模式引入香港，并提出了4C模式，主要應(yīng)用電話(huà)隨訪和家庭訪視，對(duì)出院的糖尿病、冠心病、腎衰晚期、COPD患者進(jìn)行護(hù)理服務(wù)。2011年中國(guó)再次提出，延續(xù)性護(hù)理是“十二五”時(shí)期重點(diǎn)工作任務(wù)。

在“互聯(lián)網(wǎng)加”這個(gè)大背景下，秉承“病前院外、線上線下、隨時(shí)隨地”的理念，解決傳統(tǒng)的電話(huà)、短信、上門(mén)隨訪等護(hù)理服務(wù)模式，本文將互聯(lián)網(wǎng)技術(shù)與護(hù)理服務(wù)結(jié)合起來(lái)，采用B/S結(jié)構(gòu)，設(shè)計(jì)了一套能夠幫助患者在出院后可以隨時(shí)隨地更加方便地享受護(hù)理服務(wù)的系統(tǒng)，以緩解中國(guó)護(hù)理資源的緊張，更好地提升患者的康復(fù)效果。本文將從系統(tǒng)需求分析、系統(tǒng)架構(gòu)設(shè)計(jì)、關(guān)鍵技術(shù)于創(chuàng)新點(diǎn)以及數(shù)據(jù)庫(kù)設(shè)計(jì)做等方面做重點(diǎn)闡述。

l 系統(tǒng)需求分析

傳統(tǒng)觀念上，患者出院后就意味著醫(yī)患關(guān)系的結(jié)束，但是據(jù)調(diào)查研究，很多患者在出院后仍有很高的健康照護(hù)要求，尤其是患者糖尿病、慢性心力衰竭、腦卒中、消化性潰瘍等慢性病患者。由于這些患者在出院康復(fù)期間缺乏合理的康復(fù)方案及優(yōu)質(zhì)的護(hù)理服務(wù)，使得癥狀不能得到有效的控制，進(jìn)而極大降低了患者的生活質(zhì)量及幸福指數(shù)，同時(shí)使得再次入院、急診門(mén)診的使用率大大升高。因此，在慢性病護(hù)理需求日益增加的今天，設(shè)計(jì)開(kāi)發(fā)一套完整的延伸護(hù)理系統(tǒng)是非常有必要的。

本系統(tǒng)的主要用戶(hù)是出院患者及專(zhuān)業(yè)護(hù)理人員，通過(guò)“健康秘書(shū)”的關(guān)系將護(hù)士與患者關(guān)聯(lián)，每個(gè)患者可以添加多個(gè)護(hù)士為健康秘書(shū)，同時(shí)每個(gè)健康秘書(shū)可以為多個(gè)患者服務(wù)。患者與護(hù)士建立了個(gè)性化服務(wù)關(guān)系后，護(hù)士便可查看患者的電子病歷、身體監(jiān)測(cè)數(shù)據(jù)并為其制定合理的干預(yù)方案，患者按照干預(yù)方案進(jìn)行每天的飲食、作息、運(yùn)動(dòng)等生活方式的調(diào)整并向系統(tǒng)反饋每天的方案執(zhí)行情況，通過(guò)雙方即時(shí)的信息交流，護(hù)士便可精確地掌握患者的信息，在必要情況下可進(jìn)行上門(mén)隨訪服務(wù)，極大程度上體現(xiàn)了延伸護(hù)理的綜合性、延續(xù)性、協(xié)調(diào)性和合作性。整個(gè)系統(tǒng)的業(yè)務(wù)模型如圖1所示：

通過(guò)該系統(tǒng)，使得延續(xù)護(hù)理不再受場(chǎng)所、時(shí)間等的限制，括寬了延伸護(hù)理的橫向及縱向?qū)哟危瑵M(mǎn)足了患者出院后的照護(hù)需求，緩解了醫(yī)護(hù)資源的緊張，提高了整個(gè)社會(huì)的醫(yī)療健康滿(mǎn)意度。

2 系統(tǒng)架構(gòu)設(shè)計(jì)

本文采用基于Web的J2EE三層體系結(jié)構(gòu)，基于B/S模式，使用Spring MVC、Spring、Hibernate相結(jié)合的開(kāi)發(fā)框架實(shí)現(xiàn)系統(tǒng)的設(shè)計(jì)與開(kāi)發(fā)。J2EE三層體系包括表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問(wèn)層，表示層主要采用Spring MVC結(jié)合Java Servlet API的方式實(shí)現(xiàn)，主要負(fù)責(zé)頁(yè)面的展示、接收請(qǐng)求、分發(fā)請(qǐng)求。業(yè)務(wù)邏輯層主要是對(duì)數(shù)據(jù)層進(jìn)行操作，對(duì)數(shù)據(jù)邏輯層進(jìn)行處理。數(shù)據(jù)訪問(wèn)層也稱(chēng)為持久層，由Hibemate實(shí)現(xiàn)，主要由數(shù)據(jù)訪問(wèn)工廠層、數(shù)據(jù)訪問(wèn)接口層、自定義查詢(xún)層和臨時(shí)層共同組成，主要負(fù)責(zé)對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)。本系統(tǒng)的整體架構(gòu)圖如圖2所示：

這三種框架相結(jié)合，完整地實(shí)現(xiàn)了J2EE的三層架構(gòu)。采用此體系架構(gòu)，開(kāi)發(fā)人員只需關(guān)注整個(gè)結(jié)構(gòu)中的某一層，能夠有效降低層與層之間的依賴(lài)并有便于各層的獨(dú)立標(biāo)準(zhǔn)化，通過(guò)各層之間的低耦合性、各層邏輯的高復(fù)用性，有利于整個(gè)系統(tǒng)的架構(gòu)設(shè)計(jì)及業(yè)務(wù)變化的分離，從而實(shí)現(xiàn)了便捷、高效、安全、穩(wěn)定的企業(yè)級(jí)系統(tǒng)應(yīng)用。本系統(tǒng)的整體架構(gòu)圖如圖2所示：

其次，本系統(tǒng)中部分頁(yè)面采用Freemarker進(jìn)行視圖的渲染，對(duì)于處理大量判斷、日期金額這些復(fù)雜頁(yè)面而言，性能要優(yōu)于傳統(tǒng)的JSP，同時(shí)它對(duì)JSP標(biāo)簽支持良好，并且采用嚴(yán)格的MVC分離，使得系統(tǒng)結(jié)構(gòu)更加清晰，頁(yè)面渲染更加友好。

3 關(guān)鍵技術(shù)與創(chuàng)新點(diǎn)

本系統(tǒng)在研發(fā)的過(guò)程中應(yīng)用了大量的新型互聯(lián)網(wǎng)技術(shù)，并針對(duì)其應(yīng)用場(chǎng)景進(jìn)行了適應(yīng)化的創(chuàng)新，以使其在系統(tǒng)模塊中產(chǎn)生更大的效能。本文主要對(duì)系統(tǒng)所使用的CDN視頻分布式加速技術(shù)、基于TCP長(zhǎng)連接的實(shí)時(shí)通訊技術(shù)以及DES傳輸加密技術(shù)及其創(chuàng)新點(diǎn)進(jìn)行闡述。

3.1 CDN視頻分布式加速技術(shù)

傳統(tǒng)的視頻服務(wù)器主要是由一臺(tái)集中式視頻服務(wù)器為用戶(hù)提供視頻服務(wù)，這種視頻服務(wù)器部署起來(lái)相對(duì)簡(jiǎn)單并且便于對(duì)視頻資源進(jìn)行集中管理。但是，集中式的管理注定會(huì)帶來(lái)集中式的訪問(wèn)壓力，從而影響用戶(hù)體驗(yàn)。這種劣勢(shì)在本系統(tǒng)這種用戶(hù)分布范圍比較廣泛的應(yīng)用平臺(tái)將會(huì)體現(xiàn)的更為顯著。因此，本文在原始的視頻流服務(wù)器的架構(gòu)的基礎(chǔ)上提出了基于分布式緩存的視頻CDN加速技術(shù)。其應(yīng)用架構(gòu)如圖3所示：

為了讓每一個(gè)用戶(hù)分布區(qū)域享受到最快速的視頻服務(wù)，在每一個(gè)用戶(hù)相對(duì)集中的分布區(qū)域架設(shè)相應(yīng)的Load Balance Server（負(fù)載均衡服務(wù)器），通過(guò)這些服務(wù)器將各地區(qū)的請(qǐng)求進(jìn)行分析，選擇對(duì)于目前地區(qū)訪問(wèn)速度最快的視頻服務(wù)器進(jìn)行接入，極大程度的加快了訪問(wèn)速度，提升了用戶(hù)體驗(yàn)。與此同時(shí)，分庫(kù)策略也使得網(wǎng)站整體性能得以提升。

當(dāng)然，此處所提及的創(chuàng)新點(diǎn)所帶來(lái)的問(wèn)題便是搭建成本以及維護(hù)成本的大幅增加，架構(gòu)進(jìn)一步復(fù)雜化，對(duì)開(kāi)發(fā)人員以及維護(hù)人員提出了更高的要求。在實(shí)際的系統(tǒng)開(kāi)發(fā)過(guò)程中對(duì)于其利弊因素需要進(jìn)行權(quán)衡，選取一種折中的實(shí)現(xiàn)方案。

3.2 基于TCP長(zhǎng)連接的實(shí)時(shí)通訊技術(shù)

以往，對(duì)于網(wǎng)絡(luò)通訊都是采用“郵件”式的異步通訊機(jī)制，即每次都是通過(guò)用戶(hù)主動(dòng)請(qǐng)求的形式拉取相應(yīng)的消息。而對(duì)于本系統(tǒng)這種對(duì)于消息實(shí)時(shí)性要求較高的應(yīng)用場(chǎng)景，這種方式顯然不太合理。例如，保健護(hù)士在通知患者需要在1小時(shí)內(nèi)完成相關(guān)的訓(xùn)練時(shí)，異步通訊所造成的延時(shí)將造成患者不能及時(shí)了解到護(hù)士的安排從而錯(cuò)過(guò)最佳的恢復(fù)時(shí)機(jī)。

本文則將主要應(yīng)用于C/S架構(gòu)上的TCP長(zhǎng)連接技術(shù)應(yīng)用于B/S架構(gòu)中，以實(shí)現(xiàn)Web端的實(shí)時(shí)通訊，其實(shí)現(xiàn)方式如圖4所示：

瀏覽器端的應(yīng)用通過(guò)post請(qǐng)求方式向服務(wù)器請(qǐng)求建立TCP長(zhǎng)連接，如果連接超時(shí)則服務(wù)器向?yàn)g覽器返回一個(gè)空包，瀏覽器接受到空包之后繼續(xù)向服務(wù)器發(fā)送請(qǐng)求。這一舉措有兩個(gè)目的：一是為了讓服務(wù)器能夠判斷當(dāng)前用戶(hù)是否還在線——如果聯(lián)系兩個(gè)間隔沒(méi)有收到該用戶(hù)發(fā)送的心跳包則認(rèn)為用戶(hù)處于離線狀態(tài)；二是為了達(dá)到消息實(shí)時(shí)性的要求，這時(shí)候服務(wù)器只需要在有消息要通知客戶(hù)的時(shí)候準(zhǔn)備好消息，等到下一個(gè)心跳包到來(lái)的時(shí)候直接將其返回給用戶(hù)。這樣也就實(shí)現(xiàn)了消息推送的效果。

由于瀏覽器往往建立在有線網(wǎng)絡(luò)的狀況下，所以這種方式實(shí)現(xiàn)的推送機(jī)制相較于移動(dòng)網(wǎng)絡(luò)將會(huì)更加穩(wěn)定。另外，由于采用了心跳方式的長(zhǎng)連接建立機(jī)制，其對(duì)于網(wǎng)絡(luò)帶寬的需求將會(huì)降低不少。

3.3 DES傳輸加密技術(shù)

在加密技術(shù)的選擇上，本文針對(duì)RSA加密和DES加密進(jìn)行了對(duì)比分析。RSA加密是一種非對(duì)稱(chēng)加密技術(shù)，側(cè)重于數(shù)據(jù)的安全性，但是加密速度相對(duì)較慢，DES加密則是一種對(duì)稱(chēng)加密機(jī)制，由于加密處理速度較快，因此適用于本系統(tǒng)這種對(duì)于速度要求較高并且加密內(nèi)容比較長(zhǎng)的場(chǎng)景。

當(dāng)然，為了彌補(bǔ)采用DES加密傳輸所帶來(lái)的安全性問(wèn)題。本文創(chuàng)新性的提出了融合DES加密-DES+MD5加密算法，所有的通訊協(xié)議內(nèi)容采用DES進(jìn)行加密，而協(xié)議所包裹的數(shù)據(jù)則采用MD5進(jìn)行加密。由于服務(wù)器主要解析相應(yīng)的借口協(xié)議以處理相應(yīng)的邏輯，對(duì)于數(shù)據(jù)主要做存儲(chǔ)操作，所以這一改進(jìn)不僅大大增加了數(shù)據(jù)的安全性，還沒(méi)有增加服務(wù)器的解密壓力。DES加解密相關(guān)的代碼如下所示：

加密代碼：

private static byte[] encrypt （byte[] data. byte[] key）throws Exception{

SecureRandom sr= new SecureRandom（）；

DESKeySpec dks= new DESKeySpec （key）；

SecretKeyFactory keyFactory=SecretKeyFac-tory.getlnstance （DES）；

SecretKey securekey=keyFactory.generateSecret（dks）；

Cipher cipher= Cipher.getlnstance （DES）；

cipher.init （Cipher.ENCRYPT___ MODE. securekey.sr）；

return cipher.doFinal （data）；

）

解密代碼：

private static byte[] decrypt （byte[] data. byte[] key）throws Exception{

SecureRandom sr= new SecureRandom（）；

DESKeySpec dks= new DESKeySpec （key）；

SecretKeyFactory keyFactory=SecretKeyFac-tory.getlnstance （DES）；

SecretKey securekey=keyFactory.generateSecret（dks）；Cipher cipher=Cipher.getlnstance （DES） ；cipher.init （Cipher.DECRYPr MODE， securekey， sr）return cipher.doFinal （data） ；

4 數(shù)據(jù)庫(kù)設(shè)計(jì)

在大型交互型網(wǎng)站的數(shù)據(jù)庫(kù)設(shè)計(jì)上需要考慮的因素包含并發(fā)性以及可擴(kuò)展性等因素。本系統(tǒng)所選取的數(shù)據(jù)庫(kù)為MySql。在考慮可擴(kuò)展性時(shí)對(duì)于兩種方案進(jìn)行了分析：Scale-up（縱向擴(kuò)展）以及Scale-out（橫向擴(kuò)展）。縱向擴(kuò)展是一種通過(guò)提升機(jī)器的性能進(jìn)行擴(kuò)展的方案，而橫向擴(kuò)展則是通過(guò)增加處理節(jié)點(diǎn)從而對(duì)數(shù)據(jù)庫(kù)性能進(jìn)行補(bǔ)充的方案。通過(guò)分析比對(duì)，橫向擴(kuò)展對(duì)于互聯(lián)網(wǎng)應(yīng)用這類(lèi)高并發(fā)性的情況更為適用。

本系統(tǒng)數(shù)據(jù)庫(kù)表包含基本交互式系統(tǒng)所要求的數(shù)據(jù)表，例如權(quán)限表、用戶(hù)表等等。整個(gè)系統(tǒng)數(shù)據(jù)庫(kù)總共包含128張表，下面僅將本系統(tǒng)比較核心的兩個(gè)模塊所涉及的表進(jìn)行介紹。

（1）干預(yù)方案模塊設(shè)計(jì)

干預(yù)方案是本系統(tǒng)的核心內(nèi)容，也是護(hù)士為患者提供服務(wù)最關(guān)鍵的內(nèi)容。其數(shù)據(jù)表設(shè)計(jì)如下所示：

干預(yù)方案是延伸護(hù)理系統(tǒng)的核心內(nèi)容，是護(hù)患溝通的一個(gè)及時(shí)有效的方案。通過(guò)干預(yù)方案護(hù)士可以在線上直接為患者量身定制每天的飲食、運(yùn)動(dòng)方案，讓患者就算在院外也可以享受到院內(nèi)般的科學(xué)指導(dǎo)。

本系統(tǒng)中，每一位患者可以添加多位護(hù)士作為其私人保健專(zhuān)家，所以每位患者將會(huì)有不同護(hù)士為其制定的干預(yù)方案，所以針對(duì)每位患者需要有一張表用于存儲(chǔ)其所擁有的干預(yù)方案列表，方案列表主要用來(lái)存儲(chǔ)患者用戶(hù)每一天需要進(jìn)行的任務(wù)，這些任務(wù)都是由患者的私人護(hù)士進(jìn)行維護(hù)，私人護(hù)士在了解患者相應(yīng)的康復(fù)情況后需要根據(jù)患者的身體狀況為其制定干預(yù)方案，干預(yù)方案表如表1所示：

通過(guò)查詢(xún)語(yǔ)句：

SELECT * FROM T_INTERVENTION—PLANWHERE PATIENT_ ID=“123456789”

可以查詢(xún)出該患者所擁有的所有的干預(yù)方案，然后患者用戶(hù)可以選擇其中任意一個(gè)干預(yù)方案，終端就通過(guò)該方案的方案ID向后臺(tái)請(qǐng)求方案的詳細(xì)信息，后臺(tái)需要到干預(yù)項(xiàng)目表中查詢(xún)相應(yīng)方案的詳細(xì)信息。

（2）監(jiān)測(cè)數(shù)據(jù)模塊設(shè)計(jì)

健康監(jiān)測(cè)作為干預(yù)方案的重要實(shí)施環(huán)節(jié)，在本系統(tǒng)中的作用也是十分重要的。而監(jiān)測(cè)模塊最為重要的兩張數(shù)據(jù)表是監(jiān)測(cè)項(xiàng)目表以及監(jiān)測(cè)數(shù)據(jù)歷史表。

監(jiān)測(cè)項(xiàng)目表是用來(lái)存儲(chǔ)干預(yù)方案中所提及的所有檢測(cè)項(xiàng)目的一張數(shù)據(jù)表，它主要存儲(chǔ)檢測(cè)項(xiàng)目的計(jì)量單位、參考范圍以及適用性別等信息。例如對(duì)于糖尿病患者所關(guān)注的血糖指標(biāo)，需要在這張表中存儲(chǔ)血氧的計(jì)量單位-mmol/L，參考范圍為3.9-6.1mmol/L，對(duì)任意性別和年齡都適用，因此這兩項(xiàng)分別存儲(chǔ)為2男女皆可和0年齡無(wú)影響。檢測(cè)數(shù)據(jù)表的結(jié)構(gòu)如下所示：

監(jiān)測(cè)項(xiàng)目表在提示患者用戶(hù)進(jìn)行數(shù)據(jù)以及對(duì)于監(jiān)測(cè)歷史數(shù)據(jù)進(jìn)行是否異常判斷時(shí)都是非常有用的。后端可以通過(guò)查詢(xún)監(jiān)測(cè)項(xiàng)目表中的項(xiàng)目將結(jié)果反饋給前端讓其做相應(yīng)的用戶(hù)交互界面顯示，以提示患者正確的上傳監(jiān)測(cè)數(shù)據(jù)。

5 系統(tǒng)功能實(shí)現(xiàn)與測(cè)試

根據(jù)文章的系統(tǒng)需求分析，延伸護(hù)理系統(tǒng)的整體功能設(shè)計(jì)如圖5所示：

整個(gè)系統(tǒng)的用戶(hù)分為患者及護(hù)士，主要通過(guò)建立“健康秘書(shū)”關(guān)系將兩者相連接，進(jìn)而建立個(gè)性化延伸護(hù)理服務(wù)關(guān)系。

5.1 患者端功能

對(duì)于患者而言，主要包括4大功能：

（1）基本信息管理：包括患者的個(gè)人賬號(hào)、身份證等自然信息的查詢(xún)、修改，用戶(hù)密碼修改，金幣使用明細(xì)查詢(xún)，電子病歷、體檢報(bào)告等健康檔案的管理。健康檔案的安全性、存儲(chǔ)方便性、時(shí)效性等優(yōu)點(diǎn)極大程度上方便了護(hù)患雙方的信息共享。

（2）測(cè)評(píng)管理：經(jīng)過(guò)咨詢(xún)專(zhuān)業(yè)的護(hù)理團(tuán)隊(duì)，系統(tǒng)提供了一套完整的身體評(píng)估方案，得出了分析身體狀況需要提供的數(shù)據(jù)指標(biāo)以及測(cè)試項(xiàng)目，并針對(duì)每一個(gè)項(xiàng)目設(shè)置了評(píng)分值及權(quán)重，患者僅需按照要求進(jìn)行填寫(xiě)，系統(tǒng)充分運(yùn)用大數(shù)據(jù)分析的思想，即刻就能得出其身體處于何種狀態(tài)并提供一套權(quán)威的監(jiān)測(cè)報(bào)告。測(cè)評(píng)數(shù)據(jù)如圖6所示：

（3）健康秘書(shū)管理：本系統(tǒng)的核心之處就在于建立護(hù)士與患者的服務(wù)關(guān)系?；颊呖梢灾付ㄅc自身疾病相符合的專(zhuān)業(yè)護(hù)理人員為自己的健康秘書(shū)，經(jīng)護(hù)士同意后，便可享受護(hù)士的專(zhuān)業(yè)化、精細(xì)化的護(hù)理服務(wù)。

（4）干預(yù)方案管理：在患者出院后需要延伸護(hù)理服務(wù)的情況下，健康秘書(shū)根據(jù)患者的電子病歷、身體評(píng)估報(bào)告等為其量身制定干預(yù)方案，并以健康日記的形式體現(xiàn)出來(lái)。健康日記展示了患者每天需要完成的任務(wù)及注意事項(xiàng)。健康日記作為延伸護(hù)理服務(wù)的核心實(shí)現(xiàn)，對(duì)其如何實(shí)現(xiàn)做了更深入的研究。

對(duì)于健康日記，設(shè)定了一種可擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，可以支持通用的模板及個(gè)性化方案的制定，并以符合用戶(hù)使用習(xí)慣的時(shí)間軸模式的日記界面顯示，橫軸代表日期，可以顯示30天的時(shí)間記錄，縱軸為時(shí)間軸，由時(shí)間節(jié)點(diǎn)及節(jié)點(diǎn)任務(wù)組成。節(jié)點(diǎn)數(shù)量可以動(dòng)態(tài)調(diào)節(jié)，節(jié)點(diǎn)任務(wù)可以按需增加，文字、視頻、圖片、網(wǎng)頁(yè)等任務(wù)內(nèi)容格式不限。并支持動(dòng)態(tài)的設(shè)定監(jiān)測(cè)數(shù)據(jù)功能。

5.2 護(hù)士端功能

對(duì)于護(hù)士而言，主要包括3大功能：

（1）基本信息管理：包括護(hù)士的個(gè)人賬號(hào)、個(gè)人基本信息的修改，個(gè)人主頁(yè)（疾病擅長(zhǎng)、個(gè)人簡(jiǎn)介、職稱(chēng)等）的管理，個(gè)人績(jī)效查詢(xún)，個(gè)人金幣收入查詢(xún)等。

（2）患者管理護(hù)士同意成為患者的健康秘書(shū)后，便可在該菜單下查詢(xún)自己所服務(wù)的患者，并能夠查詢(xún)患者的基本個(gè)人信息、電子病歷、身體評(píng)估報(bào)告、干預(yù)方案執(zhí)行情況等，能夠及時(shí)精確得了解患者的身體狀況。并能夠通過(guò)即時(shí)通訊模塊與患者進(jìn)行交流，充分體現(xiàn)了延伸護(hù)理的時(shí)效性。

（3）干預(yù)方案管理：系統(tǒng)提供了針對(duì)不同疾病、不同地域、不同年齡階段等的各種健康模板方案，護(hù)士作為健康秘書(shū)，需要根據(jù)患者的病情及康復(fù)情況來(lái)制定方案，可以自己設(shè)定方案，也可根據(jù)模板提供的內(nèi)容進(jìn)行合理的修改，圖7為護(hù)士配置方案的界面。

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

對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō)，測(cè)試是必不可少的環(huán)節(jié)，也是正式應(yīng)用前最重要的環(huán)節(jié)。針對(duì)本系統(tǒng)，主要做了兼容性測(cè)試、功能測(cè)試、性能測(cè)試。

（1）兼容性測(cè)試：針對(duì)目前較為流行的瀏覽器IE6-IE11，F(xiàn)irefox，chrome，safari，360瀏覽器都逐一測(cè)試了各頁(yè)面及數(shù)據(jù)的顯示效果，基本上都與原型設(shè)計(jì)中的效果相一致，實(shí)現(xiàn)了良好的兼容性，滿(mǎn)足了用戶(hù)的交互性能要求。唯一的不足是由于IE6渲染技術(shù)古老，且用戶(hù)使用數(shù)量也較少，系統(tǒng)在該瀏覽器中顯示效果不是很好，需要做進(jìn)一步兼容性改進(jìn)。

（2）功能測(cè)試：針對(duì)兩類(lèi)用戶(hù)，分別測(cè)試了其注冊(cè)、登錄以及登錄后的功能操作。并主要對(duì)系統(tǒng)中涉及到兩個(gè)角色的業(yè)務(wù)流程做了重點(diǎn)測(cè)試，比如：健康秘書(shū)為患者制定干預(yù)方案的流程等。無(wú)論是功能點(diǎn)的測(cè)試還是業(yè)務(wù)流程的測(cè)試，都能很好的實(shí)現(xiàn)。

（3）性能測(cè)試：對(duì)于一個(gè)復(fù)雜的，用戶(hù)數(shù)量龐大的系統(tǒng)，高并發(fā)是極其重要的因素。通過(guò)模擬測(cè)試，本系統(tǒng)實(shí)現(xiàn)了5萬(wàn)用戶(hù)的高并發(fā)量，防止了高峰期段系統(tǒng)的癱瘓，能夠很好的滿(mǎn)足用戶(hù)的日常需求。

總之，該系統(tǒng)的測(cè)試結(jié)果合格，可以投入使用，對(duì)于一些無(wú)關(guān)緊要的細(xì)節(jié)bug，今后會(huì)在做進(jìn)一步的改進(jìn)。

6 結(jié)論

本系統(tǒng)將互聯(lián)網(wǎng)技術(shù)應(yīng)用于延伸護(hù)理系統(tǒng)，成功解決了傳統(tǒng)護(hù)理模式所帶來(lái)的一系列問(wèn)題。本系統(tǒng)目前已經(jīng)在北京301醫(yī)院代謝綜合征科室進(jìn)行了試驗(yàn)性應(yīng)用，很好的滿(mǎn)足了糖尿病人需要長(zhǎng)期監(jiān)測(cè)身體指標(biāo)及長(zhǎng)期飲食指導(dǎo)的需求，取得了良好的護(hù)理效果。將互聯(lián)網(wǎng)技術(shù)應(yīng)用于糖尿病等慢性疾病的延伸護(hù)理過(guò)程中在很大程度上也減少了醫(yī)療資源的浪費(fèi)，緩解了患者就醫(yī)難，路途遠(yuǎn)的煩惱，同時(shí)很大程度上也推進(jìn)了醫(yī)療信息化的進(jìn)步。相信，會(huì)有更多的醫(yī)院采用本系統(tǒng)或者類(lèi)似的延伸護(hù)理系統(tǒng)為患者提供服務(wù)，提升患者的康復(fù)效果，提高患者的幸福指數(shù)。