




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡介
-9-基于醫(yī)用預(yù)約管理子系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)摘要近些年來,我國的醫(yī)療高新和醫(yī)用檢測設(shè)備技術(shù)的快速創(chuàng)新發(fā)展,醫(yī)技設(shè)備檢測技術(shù)在整個(gè)臨床和診療服務(wù)流程管理中都發(fā)揮出了其關(guān)鍵性角色,醫(yī)技設(shè)備檢測技術(shù)的發(fā)展速度水平與檢測質(zhì)量將會(huì)直接影響關(guān)系到臨床醫(yī)院整體診療的醫(yī)療服務(wù)水平。為了能進(jìn)一步的提高臨床醫(yī)技和檢驗(yàn)技術(shù)科室人員的臨床工作效率,以信息技術(shù)平臺(tái)為支撐,建立醫(yī)技預(yù)約平臺(tái),制作一個(gè)預(yù)約掛號系統(tǒng),讓患者在網(wǎng)上掛號,避免醫(yī)院掛號繳費(fèi)處人員大量聚集,在疫情不容忽視的今天,尤為重要。本文較為全面的剖析并設(shè)計(jì)了這個(gè)預(yù)約掛號系統(tǒng)。在系統(tǒng)中,管理員可以管理醫(yī)護(hù)人員、患者、科室等基礎(chǔ)信息,科室醫(yī)護(hù)人員可以發(fā)布各自科室號源供患者掛號,亦可以到指定掛號處掛號?;颊呖梢跃W(wǎng)上查看各科室在職醫(yī)生,并且預(yù)約掛號,無需現(xiàn)場排隊(duì),有效的解決了掛號處人員聚集等問題。本系統(tǒng)在設(shè)計(jì)過程中使用了PowerDesignerUML設(shè)計(jì)工具,在產(chǎn)品研發(fā)的過程中采用到了JAVA編程語言。采用目前主流的SSM架構(gòu)作為WEB架構(gòu),以及MYSQL作為開源的免費(fèi)數(shù)據(jù)庫。在軟件系統(tǒng)開發(fā)的整個(gè)總體的設(shè)計(jì)思路與軟件研發(fā)的流程設(shè)計(jì)中,根據(jù)整個(gè)軟件的開發(fā)工作流程,先后獨(dú)立完成包括了軟件系統(tǒng)需求分析、系統(tǒng)總體的設(shè)計(jì)、編碼測試等階段,結(jié)合SSMweb框架,集成了ApacheShiro開源孵化項(xiàng)目作權(quán)限管理,使用Twitter設(shè)計(jì)師設(shè)計(jì)推出的Bootstrap作為UI基礎(chǔ)框架,完成了該系統(tǒng)。經(jīng)測試本系統(tǒng)達(dá)到了預(yù)期的效果,系統(tǒng)可以使用戶簡單快捷的了解各科室在職醫(yī)生信息并進(jìn)行掛號、取消掛號操作,掛號人員能夠進(jìn)行現(xiàn)場掛號、退號,醫(yī)生可以修改患者就診狀態(tài)、撤銷掛號,后臺(tái)管理員能夠進(jìn)行人員管理、科室管理。關(guān)鍵詞:醫(yī)技預(yù)約平臺(tái);SSM應(yīng)用;JAVAWEB開發(fā);軟件開發(fā)目錄摘要…………=1\*ROMANIAbstract……………………=2\*ROMANII1緒論 11.1選題背景及目的 11.2國內(nèi)外現(xiàn)狀研究 21.2.1國內(nèi)預(yù)約模式研究 21.2.2國外預(yù)約模式研究 31.3主要研究內(nèi)容 42相關(guān)技術(shù)研究 62.1SSM框架 62.2前端所用技術(shù) 62.3后端所用技術(shù) 73系統(tǒng)分析 83.1可行性分析 83.1.1技術(shù)可行性 83.1.2操作可行性 83.1.3經(jīng)濟(jì)可行性 83.2需求分析 83.2.1系統(tǒng)總體業(yè)務(wù)流程 93.2.2功能性需求分析 93.2.3非功能性需求分析 103.2.4數(shù)據(jù)流程分析 114系統(tǒng)設(shè)計(jì) 134.1系統(tǒng)架構(gòu)設(shè)計(jì) 134.1.1技術(shù)架構(gòu)設(shè)計(jì) 134.1.2邏輯架構(gòu)設(shè)計(jì) 144.2系統(tǒng)功能設(shè)計(jì) 154.3數(shù)據(jù)庫設(shè)計(jì) 184.3.1ER實(shí)體關(guān)系分析 184.3.2物理數(shù)據(jù)生成 234.3.3面向?qū)ο髷?shù)據(jù)生成 234.3.4數(shù)據(jù)庫的建立 244.4程序流程設(shè)計(jì) 255系統(tǒng)的實(shí)現(xiàn) 275.1用戶端的實(shí)現(xiàn) 275.2醫(yī)生端的實(shí)現(xiàn) 325.3傳統(tǒng)掛號端的實(shí)現(xiàn) 355.4后臺(tái)管理端的實(shí)現(xiàn) 375.5測試 435.5.1白盒測試 435.5.2黑盒測試 446總結(jié)與展望 466.1總結(jié) 466.2展望 46參考文獻(xiàn)……………………471緒論1.1選題背景及目的隨著高新醫(yī)療設(shè)備技術(shù)的飛速發(fā)展,臨床醫(yī)生對醫(yī)技檢查的依賴程度越來越高,因此醫(yī)院整體的服務(wù)質(zhì)量直接受到醫(yī)技檢查的速度和質(zhì)量的影響,醫(yī)技檢查在臨床醫(yī)療過程中扮演著極其重要的角色。[1]進(jìn)入21世紀(jì),隨著醫(yī)院信息化和大數(shù)據(jù)化進(jìn)程的加快,醫(yī)療保障體系得到了全面覆蓋。目前待解決的問題是在醫(yī)學(xué)技術(shù)檢驗(yàn)中應(yīng)用信息化技術(shù),以提高檢驗(yàn)工作的效率,減少技術(shù)檢驗(yàn)工作的難度,減少病人的預(yù)約等待,使得有限的檢測資源可以最大程度的滿足病人的需要。[2]通過使用統(tǒng)一的平臺(tái),讓數(shù)據(jù)在各個(gè)部門流通起來,這樣可以共享數(shù)據(jù),減少來回奔波的不必要。醫(yī)院掛號科在網(wǎng)上預(yù)約掛號,有效的降低了線下患者的數(shù)量,減少了患者不必要的聚集行為。通過使用掛號平臺(tái),按次序叫號,患者只需在候診區(qū)等候叫號,無需再到醫(yī)生辦公室門口排隊(duì)等候,不給插隊(duì)等不文明現(xiàn)象可乘之機(jī)。一體化醫(yī)技預(yù)約管理系統(tǒng)一個(gè)集成的醫(yī)療技術(shù)診斷管理系統(tǒng),能夠?qū)崿F(xiàn)多個(gè)門診預(yù)約方式的集成平臺(tái)。該平臺(tái)支持各科室醫(yī)生開展業(yè)務(wù)流程的多方協(xié)作,各科室下各項(xiàng)項(xiàng)目一鍵預(yù)約。平臺(tái)包括傳統(tǒng)的科室預(yù)約、診間預(yù)約、自助預(yù)約等功能,還具有號源管理、床位預(yù)約、手術(shù)預(yù)約等功能。[3]從患者到醫(yī)生再到醫(yī)療設(shè)備之間的信息都可以通過一體化醫(yī)技預(yù)約管理系統(tǒng)實(shí)現(xiàn)信息的傳遞?;颊呖梢酝ㄟ^系統(tǒng)在網(wǎng)上預(yù)約掛號。醫(yī)生可以通過系統(tǒng)進(jìn)行就診叫號,也可以進(jìn)行醫(yī)療設(shè)備檢查預(yù)約。管理人員可以對醫(yī)生、病人、科室和醫(yī)療設(shè)備等進(jìn)行管理。該項(xiàng)目的所有工作內(nèi)容都是緊密圍繞于臨床,面向于全院,服務(wù)于全院整個(gè)的臨床醫(yī)學(xué)領(lǐng)域。雖然臨床醫(yī)學(xué)技術(shù)科已自成學(xué)科體系,構(gòu)成了整個(gè)該院重要的學(xué)科組成的部分,但實(shí)際上它主要的臨床服務(wù)和工作重點(diǎn)主要還是在為其他臨床醫(yī)療科人員進(jìn)行診斷治療、或提供配合的診斷,在積極服務(wù)于全院科研、教學(xué)工作的同時(shí),直接地或間接有效地用于對各種門診、急救、住院的病人家屬提供醫(yī)療技術(shù)咨詢服務(wù)。采用一體化的醫(yī)技科室預(yù)約系統(tǒng),節(jié)省了病人在預(yù)約和治療整個(gè)流程中花費(fèi)的一大部分時(shí)間,整合優(yōu)化了醫(yī)院系統(tǒng)內(nèi)的各種醫(yī)療資源并實(shí)現(xiàn)按科室、醫(yī)生進(jìn)行號源統(tǒng)一管理,規(guī)范患者就醫(yī)流程,提高醫(yī)技人員工作效率,減少人員開支,營造舒適溫馨的就醫(yī)環(huán)境,使得醫(yī)院更加便民、利民。[4]1.2國內(nèi)外現(xiàn)狀研究1.2.1國內(nèi)預(yù)約模式研究天門市第一人民醫(yī)院在2016年就成功上線了醫(yī)技檢查智能預(yù)約系統(tǒng),成為湖北首家實(shí)行多科室、多項(xiàng)目、多系統(tǒng)、多種預(yù)約方式于一體的醫(yī)技智能預(yù)約管理的醫(yī)院。根據(jù)醫(yī)院方面介紹,智能預(yù)約系統(tǒng)上線后該院CT拍片和超聲從以前的動(dòng)輒一兩個(gè)小時(shí)的檢查等待時(shí)間縮短到平均十分鐘以內(nèi),普通拍片縮短平均五分鐘內(nèi),患者檢查等待時(shí)間大幅縮短。醫(yī)院實(shí)現(xiàn)預(yù)約時(shí)間管理、醫(yī)療資源和技術(shù)資源的合理分配,使得預(yù)約病人的爽約率不斷下降。醫(yī)護(hù)人員通過預(yù)約系統(tǒng)的便利操作和科學(xué)分配,人員工作效率明顯提升,給病人看病帶來了極大的便利,使病人獲得良好的就醫(yī)體驗(yàn)。據(jù)不完全的數(shù)據(jù),全國現(xiàn)有醫(yī)院約2萬余所,每年接待患者的人數(shù)可達(dá)30億人次,平均下來每位醫(yī)生需要接診的病人一年大約是650位。[5]但其實(shí)許多發(fā)達(dá)國家的平均接診人次都遠(yuǎn)超我們國家,其中主要原因是病人在我國的各類門診業(yè)務(wù)中排隊(duì)等待時(shí)間過長,目前很多醫(yī)院接收到的醫(yī)療投訴都是由于病患在就診過程中等候時(shí)間過長導(dǎo)致的。在醫(yī)院傳統(tǒng)的常規(guī)檢查和預(yù)約的管理服務(wù)模式指導(dǎo)下,各大醫(yī)院的檢驗(yàn)技術(shù)科室目前仍然在實(shí)行著傳統(tǒng)醫(yī)院的常規(guī)人工檢查收費(fèi)、掛號預(yù)約、多項(xiàng)常規(guī)檢測和患者就診需要返診多次的排隊(duì)、多個(gè)檢查環(huán)節(jié)、低效率檢查的常規(guī)管理方法。根據(jù)預(yù)約與分診系統(tǒng)性能,與醫(yī)院HIS系統(tǒng)銜接緊密的PACS/RIS系統(tǒng)雖然能夠有效在醫(yī)院一定的程度上有效緩解檢查病人排隊(duì)查病房時(shí)排隊(duì)與等候造成的擁擠無序的問題,但由于很多時(shí)候檢查的病人都必須要反復(fù)多次來回的排隊(duì)掛號繳費(fèi)、排隊(duì)等候預(yù)約,且對于在門診、住院時(shí)等待的檢查的病人也無法進(jìn)行合理的分流管理與分流疏導(dǎo),業(yè)務(wù)高峰時(shí)期人員的擁堵無序現(xiàn)象也仍是相對明顯。[6]預(yù)約診療中心模式主要是指由各大醫(yī)院統(tǒng)一組織抽調(diào)專人來成立的一個(gè)全國統(tǒng)一規(guī)范的醫(yī)療預(yù)約診療中心,由專業(yè)醫(yī)技人員來承擔(dān)醫(yī)院對患者門診、住院預(yù)約等醫(yī)療各項(xiàng)診療服務(wù)事項(xiàng)的審批。這個(gè)預(yù)約模式雖然減少了患者折返醫(yī)院到其他各種臨床醫(yī)學(xué)技術(shù)科室就診的排隊(duì)道路時(shí)間與排隊(duì)次數(shù),但其實(shí)質(zhì)意義上來說依然還是屬于一個(gè)類似"人工預(yù)約"檢測的檢測模式,但在實(shí)際臨床操作過程當(dāng)中,這個(gè)檢測模式卻依然會(huì)面臨存在著患者預(yù)約檢測信息回執(zhí)管理落后、檢測診療項(xiàng)目時(shí)間無法得到統(tǒng)籌有效安排、患者重復(fù)繳費(fèi)、預(yù)約檢測后仍還需計(jì)算重復(fù)就診排隊(duì)道路時(shí)間次數(shù)等問題,而且檢查對現(xiàn)場預(yù)約檢查人員素質(zhì)的培訓(xùn)要求也很高,增加了檢查人員成本,所以我們在臨床實(shí)際的調(diào)查研究中也發(fā)現(xiàn),患者家屬在現(xiàn)場預(yù)約進(jìn)行檢查治療時(shí)往往還會(huì)存在采用門診診間預(yù)約/住院病房赴約的方式,醫(yī)生需要與其他門診、住院的醫(yī)生同時(shí)站起來排隊(duì)進(jìn)行預(yù)約檢查,采用現(xiàn)場取件系統(tǒng)人工排隊(duì)預(yù)約檢查或直接在診間排隊(duì)打印檢查預(yù)約單,取消簡化了臨床醫(yī)療技術(shù)科室的排隊(duì)和預(yù)約,但也加大了臨床醫(yī)務(wù)人員的檢查工作量;門診病人的繳費(fèi)仍然需要排隊(duì),紙質(zhì)預(yù)約信息靜態(tài),檢查預(yù)約信息無法動(dòng)態(tài)地顯示和預(yù)知情況。[7]從當(dāng)前的實(shí)際情況來看,傳統(tǒng)檢查預(yù)約模式已經(jīng)不能滿足病人的需要,被時(shí)代所拋棄;目前許多醫(yī)院普遍采用PASC/RIS和中心預(yù)約模式,其中,中心門診預(yù)約系統(tǒng)"和"門診/診間預(yù)約"在一定程度上提高了醫(yī)院的服務(wù)效率,但從實(shí)踐來看,流程還需要進(jìn)一步優(yōu)化,還需科學(xué)的統(tǒng)籌調(diào)度、算法和系統(tǒng)平臺(tái),特別是在"互聯(lián)網(wǎng)+醫(yī)療"發(fā)展的這個(gè)大背景下,如何有效利用好"互聯(lián)網(wǎng)+"的科技,使醫(yī)療檢查和預(yù)約服務(wù)的使用效果達(dá)到最大化,完善醫(yī)院診療服務(wù),改善患者看病就醫(yī)體驗(yàn),打造起一個(gè)醫(yī)技檢查和預(yù)約體系,以各種形式的醫(yī)技檢查預(yù)約,實(shí)現(xiàn)“智能預(yù)約、動(dòng)態(tài)分配、科學(xué)檢查”,正是當(dāng)下醫(yī)院信息化建設(shè)的研究方向。[8]1.2.2國外預(yù)約模式研究在發(fā)達(dá)國家,醫(yī)療資源的信息化幾乎可以覆蓋所有的醫(yī)療機(jī)構(gòu),而國外的私立醫(yī)院,一般都是通過PC和手機(jī)進(jìn)行預(yù)約,部分患者通過手機(jī)預(yù)約自己聘請的家庭醫(yī)生。在一些國家,不管是在何種現(xiàn)代服務(wù)業(yè)中都廣泛存在使用著混合式自助的服務(wù)營業(yè)廳系統(tǒng)以及全自動(dòng)化服務(wù)的自助營業(yè)廳,其中自助式服務(wù)營業(yè)廳系統(tǒng)早已逐漸得到了社會(huì)的廣泛的認(rèn)同,成為了現(xiàn)代服務(wù)行業(yè)中部分服務(wù)顧客群體的一種主要業(yè)務(wù)途徑。[9]國外的一些研究醫(yī)院醫(yī)療問題的學(xué)者,在某些預(yù)約調(diào)度問題的研究中發(fā)現(xiàn)存在著患者的爽約或患者到站排隊(duì)的服務(wù)體系的不確定等癥狀,對門診業(yè)務(wù)預(yù)約和衛(wèi)生檢查的調(diào)度問題進(jìn)行了深入的探討。[10]所以,制定預(yù)約報(bào)告的一些科學(xué)、恰當(dāng)?shù)囊?guī)則,就顯得十分必要。由于歐美國家在醫(yī)療資源的豐富程度上與我國存在體制上的差異和差距,這些國家醫(yī)院資源基本都是一些私家的醫(yī)院,因而他們在對醫(yī)院資源的配置選擇方式上也和其他國家相比有著相當(dāng)大的區(qū)別。歐美的病人出去看病通常也都是采用電話預(yù)約的方式,就連去醫(yī)院里看病時(shí)也是一般都是直接采用電話的預(yù)約掛號的方法。[11]在網(wǎng)上預(yù)約的醫(yī)療信息服務(wù)方面,歐美等地區(qū)提供的網(wǎng)上預(yù)約的醫(yī)療信息服務(wù)時(shí)間早于在我國50年左右。醫(yī)療服務(wù)預(yù)約的方式隨著近幾年的網(wǎng)絡(luò)技術(shù)對于醫(yī)療傳統(tǒng)醫(yī)療服務(wù)行業(yè)的全方位的覆蓋,已經(jīng)逐漸和網(wǎng)絡(luò)聯(lián)系結(jié)合到一起。信息化醫(yī)療時(shí)代的快速來臨,使得谷歌和醫(yī)療中心形成合作關(guān)系,為其客戶建立電子醫(yī)療檔案,美國醫(yī)療服務(wù)行業(yè)與互聯(lián)網(wǎng)行業(yè)的合作有了長足的發(fā)展。微軟還推出了能夠了解用戶最新健康狀況的全新信息化醫(yī)療服務(wù)平臺(tái)。Inter和IBM在醫(yī)療信息化方面也有不少嘗試。新加坡基本實(shí)現(xiàn)了基層綜合診所的全面預(yù)約,各大醫(yī)院的預(yù)約系統(tǒng)均由各大醫(yī)院自行實(shí)施建立,并未設(shè)立全國性的預(yù)約服務(wù)平臺(tái),而私營診所、公里醫(yī)院卻未提供預(yù)約服務(wù)制度。日本目前只有少數(shù)幾個(gè)專業(yè)如牙科、兒科已經(jīng)實(shí)施預(yù)約制度。[12]經(jīng)過對相關(guān)文獻(xiàn)資料的梳理,不難發(fā)現(xiàn),外國的醫(yī)療資源要比國內(nèi)多得多,要么就是就醫(yī)病人有自己的家庭醫(yī)生或個(gè)人醫(yī)生,要么就是直接電話預(yù)約去醫(yī)院就診,因此許多國外學(xué)者都選擇了單一服務(wù)臺(tái)的假設(shè)條件,很少考慮同時(shí)存在多個(gè)醫(yī)生或者同時(shí)提供多個(gè)服務(wù)臺(tái)的排隊(duì)模式。國外的醫(yī)療現(xiàn)狀對比國內(nèi)具有較大差別,國外醫(yī)療水平相對較高,人口較少的國家可能不會(huì)遇到我國醫(yī)療現(xiàn)狀中的一些人員過多的問題。想要在大環(huán)境下解決醫(yī)療問題,就必須加速醫(yī)院信息化建設(shè)的速度,不僅要實(shí)現(xiàn)網(wǎng)上掛號、預(yù)約等功能,更要解決長時(shí)間的排隊(duì)、人員不必要的聚集等問題。目前,我國一些大的綜合性醫(yī)院已經(jīng)引入了自助醫(yī)療預(yù)約系統(tǒng),主要是利用微信等方式,讓患者進(jìn)行自助預(yù)約、掛號、繳費(fèi)、結(jié)果查詢等,以提高醫(yī)療質(zhì)量,緩解患者排隊(duì)問題。但是,目前的某些系統(tǒng)由于其內(nèi)在機(jī)制比較復(fù)雜,使用起來也不方便,有些患者可能會(huì)采取傳統(tǒng)的預(yù)約就診流程。故而我們國家的醫(yī)療機(jī)構(gòu)需要結(jié)合自身工作流程特點(diǎn),開服符合自身特色的信息化系統(tǒng)。1.3主要研究內(nèi)容為了實(shí)現(xiàn)醫(yī)療資源的合理分配以及減少患者的就診問題,本課題主要利用IDEA開發(fā)工具、JAVA語言、MYSQL數(shù)據(jù)庫以及基于SSM的邏輯層框架技術(shù)開發(fā)一個(gè)醫(yī)技預(yù)約WEB平臺(tái)。為實(shí)現(xiàn)本系統(tǒng)的設(shè)計(jì),本文的重點(diǎn)是下面幾方面:WEB整體框架設(shè)計(jì)IDEA開發(fā)工具的環(huán)境搭建與部署數(shù)據(jù)庫的管理與應(yīng)用系統(tǒng)前后端數(shù)據(jù)交互
2相關(guān)技術(shù)研究2.1SSM框架相關(guān)研究SSM架構(gòu)是由Spring的MVC,Spring以及Mybatis這三個(gè)架構(gòu)的集成,是一種標(biāo)準(zhǔn)的MVC架構(gòu)模式,該架構(gòu)模式可以把整個(gè)體系分割成View層,Controller層,Service層以及DAO層共四層,利用了Spring的MVC來管理請求對象的轉(zhuǎn)發(fā)管理以及視圖的管理,Spring用來管理服務(wù)請求對象,Mybatis用來作為數(shù)據(jù)對象的持久化引擎。DAO層中的一個(gè)首要的工作任務(wù)是處理數(shù)據(jù)持久層,負(fù)責(zé)和數(shù)據(jù)庫之間進(jìn)行數(shù)據(jù)連接的其他一些重要任務(wù)也均被封裝在此。Service層主要的設(shè)計(jì)功能之一是用于對商業(yè)模型進(jìn)行邏輯和應(yīng)用設(shè)計(jì)。Controller層是對特定的商業(yè)模塊過程進(jìn)行控制的。View層與控制層之間的聯(lián)系更加緊密,兩者需要結(jié)合在一起進(jìn)行開發(fā),View層主要處理前臺(tái)頁面的表示。SSM流程是:在客戶端向分發(fā)機(jī)發(fā)送一個(gè)請求后,分發(fā)機(jī)控制器會(huì)詢問Hander映射,然后找到該請求的Controller,該Controller調(diào)用服務(wù)業(yè)務(wù)邏輯層進(jìn)行處理,然后返回該結(jié)果。流程原理如下圖2-1所示:圖2-1SSM框架流程原理圖2.2前端所用技術(shù)該系統(tǒng)的前端采用了微信發(fā)布的WeUI作為前端架構(gòu),WeUI是一套與微信原有視覺體驗(yàn)相一致的基本風(fēng)格庫,專門為微信WEB開發(fā)量身打造。微信在多個(gè)內(nèi)部小程序使用正常的前提下,將WeUI組件庫開源供外部開發(fā)者使用。WeUI框架界面簡潔大方,功能強(qiáng)悍,適合初學(xué)者學(xué)習(xí)使用。2.3后端所用技術(shù)系統(tǒng)的后端采用Bootstrap作為后臺(tái)UI架構(gòu),Bootstrap提供了一些基本的框架,包含了網(wǎng)格系統(tǒng)、鏈接樣式、背景等。Bootstrap擁有了以下的特性:CSS樣式的全局設(shè)置,HTML元素的定義,CLASS對象的擴(kuò)展以及其他一些更高級的網(wǎng)格系統(tǒng)。Bootstrap中還有其他很多可以被重復(fù)使用的小部件,比如創(chuàng)建圖片、下拉菜單、導(dǎo)航、警告欄、彈出框等等。它還包括一堆定制jQuery插件,用戶可以通過自定義Bootstrap組件、LESS變量以及jQuery插件來設(shè)計(jì)出合適自己的版本。
3系統(tǒng)分析一體化預(yù)約管理系統(tǒng)囊括了預(yù)約掛號、就診會(huì)診、醫(yī)技檢查、住院申請、手術(shù)預(yù)約等多方面功能,本人主要負(fù)責(zé)預(yù)約掛號子系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。對預(yù)約掛號子系統(tǒng)(醫(yī)技預(yù)約平臺(tái))的系統(tǒng)分析將從可行性分析、需求分析兩方面進(jìn)行分析。3.1可行性分析可行性的分析也是系統(tǒng)設(shè)計(jì)開發(fā)中的一個(gè)重要的環(huán)節(jié),利用系統(tǒng)可行性的分析結(jié)果來初步確定系統(tǒng)是否已具備設(shè)計(jì)開發(fā)醫(yī)技預(yù)約平臺(tái)系統(tǒng)所需具備的條件。經(jīng)過前期對醫(yī)技預(yù)約開發(fā)事項(xiàng)進(jìn)行的比較詳細(xì)的研究,確定出了所需要預(yù)約開發(fā)的系統(tǒng)應(yīng)具備什么樣的系統(tǒng)功能、特性、環(huán)境要求等,從技術(shù)可行性、操作可行性和經(jīng)濟(jì)可行性分析三個(gè)研究方向來展開。3.1.1技術(shù)可行性此系統(tǒng)的開發(fā)工具選擇了IntelliJIDEA與MySQL數(shù)據(jù)庫,采用WEB開發(fā)常用的JAVA作為開發(fā)語言,使用主流的SSM框架作為WEB開發(fā)架構(gòu),可以搭建出完善的開發(fā)環(huán)境,符合開發(fā)要求,使得項(xiàng)目具有切實(shí)的技術(shù)可行性。3.1.2操作可行性醫(yī)技預(yù)約平臺(tái)作為WEB平臺(tái),只要是能夠連接到服務(wù)器均可使用,用戶界面簡潔直觀、操作方便,管理端頁面整潔大方、交互性強(qiáng),均具有良好的操作性,符合操作可行性要求。3.1.3經(jīng)濟(jì)可行性系統(tǒng)基于SSM框架構(gòu)建,一臺(tái)電腦足以滿足開發(fā)需求,極大的降低了開發(fā)成本和維護(hù)成本,使用MYSQL開源數(shù)據(jù)庫,WEB平臺(tái)開發(fā)教程詳細(xì)易上手,開發(fā)經(jīng)濟(jì)成本低,投入使用后所帶來的經(jīng)濟(jì)效益大于開發(fā)成本,滿足經(jīng)濟(jì)可行性需求。3.2需求分析本系統(tǒng)通過對現(xiàn)有平臺(tái)業(yè)務(wù)流程分析以及用戶實(shí)際需要,繪制出關(guān)鍵功能的業(yè)務(wù)流程圖,對流程分析后,將其中存在的數(shù)據(jù)直接的關(guān)系流向,通過數(shù)據(jù)流圖展示,以建立功能模型,完善系統(tǒng)的邏輯功能。3.2.1系統(tǒng)總體業(yè)務(wù)流程醫(yī)技預(yù)約平臺(tái)總體的業(yè)務(wù)流程如圖3-1所示:病人可以選擇線上線下兩種方式進(jìn)行預(yù)約掛號。一是可以利用用戶端程序進(jìn)行提前掛號;二是到達(dá)醫(yī)院后,在醫(yī)院的掛號端進(jìn)行傳統(tǒng)的方式進(jìn)行掛號。如果患者需要提前掛號預(yù)約,就需要進(jìn)入用戶端界面,進(jìn)行注冊登錄操作后,選擇科室-醫(yī)生-日期進(jìn)行預(yù)約。如果遇到緊急情況無法正常就診,可以通過系統(tǒng)預(yù)約取消。如果患者沒有提前預(yù)約的想法,那么可以到達(dá)醫(yī)院后,在醫(yī)院的掛號端進(jìn)行掛號。醫(yī)生通過醫(yī)生端進(jìn)行號源發(fā)放,發(fā)布號源后,用戶端和掛號端才可以查詢到該醫(yī)生的號源并選擇是否進(jìn)行掛號就診。圖3-1系統(tǒng)業(yè)務(wù)流程圖3.2.2功能需求分析根據(jù)對業(yè)務(wù)流程的分析,系統(tǒng)需要以下四個(gè)端口,功能需求如下:①管理端管理員要對平臺(tái)整體功能配置,包括隊(duì)科室的管理、對醫(yī)護(hù)人員的管理、重置賬戶密碼,統(tǒng)計(jì)分析等功能。②醫(yī)生端醫(yī)生需要基本的登錄、注銷登錄、修改密碼、修改個(gè)人信息、發(fā)布號源、診治、使用設(shè)備等功能。③用戶端用戶需要注冊、登錄、修改密碼、修改個(gè)人信息、添加患者、掛號、取消掛號等功能。④掛號端掛號端位于掛號收費(fèi)部門,主要為病人提供掛號、銷號等服務(wù)。當(dāng)然還有基本的登錄、注銷、修改信息等基本功能。3.2.3非功能性需求分析①性能需求從系統(tǒng)架構(gòu)角度分析,系統(tǒng)采用的框架應(yīng)該是近年來持續(xù)穩(wěn)定、并且漏洞較少、能夠跨平臺(tái)部署。從實(shí)時(shí)性角度分析,系統(tǒng)內(nèi)功能的在并發(fā)情況下,響應(yīng)時(shí)間應(yīng)符合標(biāo)準(zhǔn)系統(tǒng)響應(yīng)時(shí)間。一般來說響應(yīng)時(shí)間超過4秒,但不超過9秒屬于可接受范圍,超過9秒可能導(dǎo)致用戶流失。[13]②安全需求從網(wǎng)站安全角度分析,系統(tǒng)應(yīng)該具備基本的網(wǎng)站安全策略,權(quán)限檢查策略,對常見漏洞(例如SQL注入等)應(yīng)該具有針對策略。③用戶體驗(yàn)需求從用戶角度來說,整體頁面要美觀大方,人機(jī)交互良好。界面響應(yīng)即使,操作簡單,按鈕要明顯。3.2.4數(shù)據(jù)流程分析分析系統(tǒng)業(yè)務(wù)流程圖,繪制各層數(shù)據(jù)流圖如下圖3-2、圖3-3、圖3-4所示:頂層數(shù)據(jù)流圖:醫(yī)生通過預(yù)約系統(tǒng)發(fā)布號源,患者查看號源進(jìn)行掛號登記。圖3-2頂層數(shù)據(jù)流圖功能數(shù)據(jù)流圖:該系統(tǒng)功能數(shù)據(jù)流圖系統(tǒng)中,細(xì)化描述了整個(gè)系統(tǒng)中的各種邏輯功能,主要是反映出了各種數(shù)據(jù)信息在整個(gè)系統(tǒng)范圍內(nèi)進(jìn)行的各種邏輯的流動(dòng)過程與信息轉(zhuǎn)化流程。醫(yī)生發(fā)出號源信息,由系統(tǒng)處理后,向患者及掛號端公布;患者查詢號源后可以進(jìn)行掛號,系統(tǒng)將掛號信息處理后輸送至后臺(tái)模塊,憑借掛號信息進(jìn)行就診。圖3-3功能數(shù)據(jù)流圖在功能進(jìn)一步分解的數(shù)據(jù)流圖中,細(xì)化了系統(tǒng)的邏輯功能,細(xì)化了數(shù)據(jù)在系統(tǒng)內(nèi)部的邏輯流向和變換過程。進(jìn)一步細(xì)化后,患者的掛號信息輸送至后臺(tái)模塊,患者可以進(jìn)行取消操作,掛號人員也能進(jìn)行銷號操作。如果掛號就診,則數(shù)據(jù)流向醫(yī)生端進(jìn)行診治;如果取消就診,則不會(huì)流入醫(yī)生端,醫(yī)生端患者就診狀態(tài)會(huì)發(fā)生由預(yù)約中到取消預(yù)約的轉(zhuǎn)變。圖3-4進(jìn)一步細(xì)化的功能數(shù)據(jù)流圖
4系統(tǒng)設(shè)計(jì)需求分析明確了“做什么”,總體設(shè)計(jì)則需要明確“怎么做”,通過對組成系統(tǒng)的物理元素的劃分,確定系統(tǒng)框架,選擇最佳的設(shè)計(jì)方案并進(jìn)行數(shù)據(jù)庫設(shè)計(jì)。4.1系統(tǒng)架構(gòu)設(shè)計(jì)系統(tǒng)架構(gòu)設(shè)計(jì)可以在整體上理解問題、規(guī)劃整體設(shè)計(jì),提供長遠(yuǎn)的可擴(kuò)展性。4.1.1技術(shù)架構(gòu)設(shè)計(jì)在需求分析的過程中,對數(shù)據(jù)流圖進(jìn)行研究,對系統(tǒng)進(jìn)行結(jié)構(gòu)劃分,構(gòu)建系統(tǒng)架構(gòu)圖。應(yīng)網(wǎng)站可靠性需求,系統(tǒng)采用Web常用語言Java作為開發(fā)語言,該語言可跨平臺(tái)部署,可靠性滿足需求,日趨完善[14]。同時(shí)使用SSM框架作為系統(tǒng)基礎(chǔ)開發(fā)框架,這也是Java語言開發(fā)Web項(xiàng)目最為主流的框架之一。整體系統(tǒng)采用Maven構(gòu)建工具構(gòu)建,該工具具有簡化構(gòu)建過程,提供統(tǒng)一構(gòu)建系統(tǒng)的功效[15]。為了解決安全需求,采用ApacheShiro開源安全框架,該框架簡便又不失功能強(qiáng)勁穩(wěn)定,尤其作為Apache的孵化項(xiàng)目,教程資料也容易搜集。數(shù)據(jù)庫方面,MYSQL主要負(fù)責(zé)存儲(chǔ)、查詢、修改數(shù)據(jù)信息,方便數(shù)據(jù)庫操作業(yè)務(wù)。數(shù)據(jù)庫交互方面使用MyBatis,將業(yè)務(wù)邏輯與數(shù)據(jù)邏輯相分離[16],使得數(shù)據(jù)庫相關(guān)操作業(yè)務(wù)更加便捷。整體Web框架上基于SSM,整合了SPKngBoot,旨在簡化SPKng的開發(fā)[17]。從用戶體驗(yàn)方面出發(fā),本系統(tǒng)采用Twitter設(shè)計(jì)師合作開發(fā)推出的Bootstrap作為后端UI框架,該框架可以讓初學(xué)者快速掌握前端開發(fā)技術(shù)[18]??蛻舳?,使用微信推出的WeUI為前端UI框架,界面簡潔大方,功能強(qiáng)悍。具體系統(tǒng)構(gòu)架圖如圖4-1所示:圖4-1系統(tǒng)技術(shù)架構(gòu)圖4.1.2邏輯架構(gòu)設(shè)計(jì)系統(tǒng)業(yè)務(wù)分為數(shù)據(jù)庫操作層、模型層、服務(wù)層三層架構(gòu),如下圖4-2所示:圖4-2系統(tǒng)邏輯架構(gòu)圖數(shù)據(jù)庫操作層:執(zhí)行資料庫存取服務(wù),增加、刪除、修改以及查詢資料庫中的資料或存放的數(shù)據(jù)。模型層:針對具體業(yè)務(wù)操作建立邏輯模型,該層處于第二層,作為數(shù)據(jù)交換的媒介,對數(shù)據(jù)庫操作層來說,該層為調(diào)用者;對服務(wù)層來說,該層為被調(diào)用者。服務(wù)層:該層用于接收用戶資料、為用戶提供操作界面、完成數(shù)據(jù)傳輸?shù)裙δ堋?.2系統(tǒng)功能設(shè)計(jì)在系統(tǒng)結(jié)構(gòu)設(shè)計(jì)中,根據(jù)需求分析,從用戶端、醫(yī)生端、傳統(tǒng)掛號端、后臺(tái)管理端四個(gè)方面進(jìn)行了分析。用戶端功能用戶功能主要包括個(gè)人信息管理、信息查詢、掛號、取消預(yù)約、歷史查詢功能。如圖4-3所示:圖4-3用戶端功能模塊圖①個(gè)人信息管理:主要包括患者的注冊與登錄,以及患者可以修改賬號密碼、手機(jī)號等信息。②信息查詢:患者可以在預(yù)約平臺(tái)查詢科室、醫(yī)生的相關(guān)資料,也可以查詢到預(yù)約的情況。③掛號:患者可以按科室、醫(yī)生、日期來進(jìn)行掛號,掛號后,醫(yī)生端能夠查看到患者的掛號信息。④取消預(yù)約:患者可以手動(dòng)取消預(yù)約掛號,取消后,醫(yī)生端顯示的患者預(yù)約狀態(tài)會(huì)從預(yù)約中轉(zhuǎn)變?yōu)槿∠A(yù)約狀態(tài)。⑤歷史記錄查詢:患者可以在“我的”頁面查詢歷史掛號記錄。醫(yī)生端功能醫(yī)生端需要基本的登錄、注銷登錄、修改密碼、修改個(gè)人信息、發(fā)布號源、診治、申請使用設(shè)備等功能。如圖4-4所示:圖4-4醫(yī)生端功能模塊圖①登錄:醫(yī)生的登錄信息由管理員統(tǒng)一發(fā)布管理,無法進(jìn)行注冊。②個(gè)人信息維護(hù):醫(yī)生可以修改個(gè)人資料,如修改密碼、修改個(gè)人手機(jī)號等。③發(fā)布號源:醫(yī)生在系統(tǒng)上按照日期選擇最大號源數(shù)后發(fā)布號源,用戶端和傳統(tǒng)掛號端即可選擇該醫(yī)生進(jìn)行掛號預(yù)約,醫(yī)生還可以修改號源最大數(shù)量,修改后各端口信息同步更新。④診治/取消就診:當(dāng)醫(yī)生診治患者或者由于特殊情況患者不能就診,醫(yī)生可通過該功能改變患者預(yù)約狀態(tài)。⑤醫(yī)技設(shè)備調(diào)用:醫(yī)生可以使用醫(yī)療設(shè)備,當(dāng)使用設(shè)備時(shí),改變該設(shè)備狀態(tài)至使用中,不能同時(shí)使用一臺(tái)設(shè)備,使用結(jié)束通過該功能恢復(fù)設(shè)備空閑狀態(tài)。后臺(tái)管理端功能后臺(tái)管理端是超級管理員使用的端口,管理員可以對平臺(tái)整體功能配置,包括隊(duì)科室的管理、對醫(yī)護(hù)人員的管理、對醫(yī)技設(shè)備的管理、重置賬戶密碼等功能。如圖4-5所示:圖4-5管理端功能圖①個(gè)人信息維護(hù):管理員賬戶由系統(tǒng)編碼實(shí)現(xiàn),具有最高的登錄權(quán)限,管理員可以修改自己個(gè)人資料。②用戶管理:管理員可以更改用戶的個(gè)人資料,因?yàn)獒t(yī)生和掛號人員是醫(yī)院內(nèi)部成員,所以只有管理員能夠?qū)⑺麄兊馁~戶信息添加到系統(tǒng)中,無法進(jìn)行注冊登記。管理員既可直接對醫(yī)師提供的基本信息資料進(jìn)行簡單更改,如醫(yī)師職務(wù)、學(xué)歷、畢業(yè)的學(xué)校、所在的部門、工號姓名等基本信息,也同樣可直接對被掛號人提供的賬戶信息資料進(jìn)行更改。③科室管理:管理員可以對科室信息進(jìn)行增加科室、刪除科室、修改科室信息等操作,還可以對科室進(jìn)行排序分類。④醫(yī)技設(shè)備管理:管理員可以管理設(shè)備信息,可以進(jìn)行新增設(shè)備、刪除設(shè)備、調(diào)整設(shè)備狀態(tài)等操作。⑤數(shù)據(jù)字典管理:管理員對系統(tǒng)的數(shù)據(jù)字典能夠進(jìn)行修改,系統(tǒng)內(nèi)數(shù)據(jù)字典有職位、學(xué)歷、預(yù)約狀態(tài)、預(yù)約類型等。傳統(tǒng)掛號端功能傳統(tǒng)掛號端定位位于醫(yī)院掛號收費(fèi)處,主要負(fù)責(zé)對在醫(yī)院的患者提供掛號、銷號等服務(wù),也擁有基本的登錄、注銷登錄、修改密碼等基本功能。如圖4-6所示:圖4-6傳統(tǒng)掛號端功能圖掛號人員通過手動(dòng)輸入患者信息進(jìn)行登記掛號操作,也可以進(jìn)行預(yù)約取消/銷號。4.3數(shù)據(jù)庫設(shè)計(jì)數(shù)據(jù)庫設(shè)計(jì)就是從特定的應(yīng)用環(huán)境中提取出一個(gè)概念模型來描述用戶的業(yè)務(wù)需求,構(gòu)建最優(yōu)的數(shù)據(jù)庫邏輯架構(gòu)和實(shí)體架構(gòu),并以此來構(gòu)建數(shù)據(jù)庫和應(yīng)用系統(tǒng),從而實(shí)現(xiàn)對數(shù)據(jù)的高效存儲(chǔ)與管理,滿足了用戶對數(shù)據(jù)操作的實(shí)際需要。4.3.1ER實(shí)體關(guān)系分析為了更直觀且準(zhǔn)確的理解以及規(guī)范化用戶的數(shù)據(jù)需求,將使用實(shí)體-關(guān)系圖模型來重新構(gòu)建概念模型。實(shí)體屬性-關(guān)系圖簡稱為E-R圖,主要是由實(shí)體、屬性關(guān)系和關(guān)聯(lián)圖三種圖形基本構(gòu)成要素組成。本系統(tǒng)中實(shí)體有醫(yī)生、科室、患者和醫(yī)療設(shè)備這四個(gè)主要實(shí)體。醫(yī)生可以發(fā)布多個(gè)號源,是1對N關(guān)系,醫(yī)生屬于一個(gè)科室,所以是1-N關(guān)系;醫(yī)生有一個(gè)登錄賬戶,是1對1關(guān)系;患者可以掛號多個(gè)醫(yī)生,醫(yī)生也可以接診多個(gè)患者,所以是N-M關(guān)系;患者也有一個(gè)賬戶,是1對1關(guān)系;賬戶擁有一個(gè)角色,要么是醫(yī)生,要么是患者,所以1對1關(guān)系;醫(yī)生只能使用一臺(tái)醫(yī)療設(shè)備,所以是1對1關(guān)系;醫(yī)療設(shè)備屬于一個(gè)科室,所以是1-N關(guān)系。根據(jù)上述分析,繪制ER實(shí)體關(guān)系圖如圖4-7所示。圖4-7ER實(shí)體關(guān)系圖使用上述實(shí)體關(guān)系,生成數(shù)據(jù)字典,數(shù)據(jù)字典中PK表示主鍵,能夠唯一區(qū)分表中的每一行。表app_doctor,主要用來存儲(chǔ)醫(yī)護(hù)人員信息,包括姓名、簡介、部門、職位、學(xué)歷、畢業(yè)院校、賬戶編號、醫(yī)生工號、掛號最大數(shù)量等。表4-SEQ表\*ARABIC1醫(yī)生信息表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空doctor_id醫(yī)生編號bigintPKNOdoctor_name姓名varchar31YESdoctor_info簡介text65535YESdepartment_dict部門bigintYESposition_dict職位biginteducation_dcit學(xué)歷bigintgraduate_dict畢業(yè)院校varchar 255user_Id賬戶編號bigintdoctor_no醫(yī)生工號varchar255max_quantity掛號最大數(shù)量intapp_doctor_settings:主要是醫(yī)生掛號配置,詳細(xì)說明某一天內(nèi)、某個(gè)醫(yī)生允許掛號的最大數(shù)量,以及當(dāng)天內(nèi)實(shí)際掛號數(shù)量。醫(yī)生在發(fā)布號源的時(shí)候可以指定最大數(shù)量。表4-SEQ表\*ARABIC2號源信息表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空setting_id配置編號bigintPKNOdoctor_id醫(yī)生編號bigintFKNOapp_date日期varchar255NOmax_quantity最大數(shù)量intNOactual_quantity實(shí)際使用數(shù)量int NOapp_patient:主要是存儲(chǔ)患者基本信息,包括姓名、病例號碼、證件號碼、性別等信息。表4-SEQ表\*ARABIC3患者信息表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空patient_id病人編號bigintPKNOpatient_name姓名varchar31YESpatient_no病歷號varchar31YEScard_no證件號碼varchar31YESgender_dict性別bigintYEStel聯(lián)系方式varchar31YESuser_id賬戶編號bigintFKYESAppointment:存儲(chǔ)具體掛號信息,包括醫(yī)生編號、患者編號、時(shí)間、狀態(tài)、日期、類型。表4-SEQ表\*ARABIC4掛號信息表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空appoiment_id掛號編號bigintPKNOdoctor_id醫(yī)生編號bigintFKYESpatient_id病人編號bigintFKYESperiod時(shí)間段varchar255YESstate_dict狀態(tài)bigintYEScreate_date日期dateYEStype_dict類型bigintYESsys_dict:該部分為字典,詳細(xì)存儲(chǔ)類似職位、學(xué)歷、狀態(tài)描述等基本信息。包括字典編號,字典名稱,字典詳細(xì)介紹,上級ID,排序等。表4-SEQ表\*ARABIC5數(shù)據(jù)字典表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空dict_id字典編號bigintPKNOdict_name字典名稱varchar31YESdict_description字典詳細(xì)varchar255YESpid上級IDbigintYESsort排序intYESsys_role:該表為基本角色表,包括ID、角色名稱,主要用來區(qū)分各種用戶類型。表4-SEQ表\*ARABIC6用戶類型表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空role_id角色I(xiàn)DbigintPKNOrole_name角色名稱varchar255YESsys_users:該表為賬戶表、存儲(chǔ)基本的用戶ID、登錄賬戶、密碼、頭像等基本信息。表4-SEQ表\*ARABIC7賬號表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空user_id用戶IDbigintPKNOlogin_name登錄賬戶varchar31YESnick昵稱varchar31YESavatar頭像varchar255YEStel聯(lián)系電話varchar31YESlogin_pwd密碼varchar64YEScreate_date創(chuàng)建日期datetimeYESrole_id角色intYESMedicalequipment:該表為醫(yī)療設(shè)備信息表,存儲(chǔ)基本的設(shè)備編號、設(shè)備名稱、科室信息、使用狀態(tài)等。表4-8設(shè)備信息表字段名稱字段描述數(shù)據(jù)類型長度鍵值允許為空Mach_id設(shè)備編號bigintPKNOMach_name設(shè)備名稱varchar31YESKs_dict所屬科室varchar31YESstate使用狀態(tài)varchar31YESUser_id用戶bigintYES4.3.2物理數(shù)據(jù)生成使用PowerDesigner工具,根據(jù)上面分析的實(shí)體類屬性以及實(shí)體之間的關(guān)系,同時(shí)抽象醫(yī)生的屬性(例如科室、學(xué)歷、畢業(yè)院校等)到一個(gè)類數(shù)據(jù)字典中。形成數(shù)據(jù)模型如圖4-8所示,該模型有助于系統(tǒng)后面的數(shù)據(jù)庫建立。圖4-8物理數(shù)據(jù)生成4.3.3面向?qū)ο髷?shù)據(jù)生成PowerDesigner作為UML設(shè)計(jì)工具,自帶生成面向?qū)ο竽P蜕扇鐖D4-9,能夠生成JAVA語言中的實(shí)體類,方便后續(xù)開發(fā)。圖4-9面向?qū)ο髷?shù)據(jù)生成4.3.4建立數(shù)據(jù)庫使用生成的物理模型,采用PowerDesigner自帶的MySQL生成腳本,生成DBMS模型,并生成數(shù)據(jù)庫對象(包括主鍵、外鍵)等信息[19]如圖4-10所示。圖4-10數(shù)據(jù)庫建立4.4程序流程設(shè)計(jì)這里詳細(xì)設(shè)計(jì)每個(gè)程序詳細(xì)流程,就登錄功能來說,首先填寫基礎(chǔ)登錄信息,包括賬戶、密碼,點(diǎn)擊登錄按鈕。若賬號存在,密碼正確,則登入成功,并跳躍至首頁,反之則會(huì)傳回錯(cuò)誤信息。流程圖如下圖4-11所示:圖4-11登錄流程圖關(guān)于掛號功能,患者登錄后首先選擇科室-醫(yī)生,點(diǎn)擊掛號按鈕,如果有號,則選擇日期進(jìn)行掛號,掛號成功,如果沒有號則不顯示日期,無法掛號。具體流程如圖4-12所示:圖4-12掛號流程圖5系統(tǒng)的實(shí)現(xiàn)系統(tǒng)結(jié)構(gòu)采用通用MVC模式,該模式被PHP,Java等語言廣泛使用[14]。利用MAVEN構(gòu)建工具,利用SPKngBoot快速腳手架,減少配置工作量。按照模塊劃分,可以劃分為通用功能模塊、病人模塊、管理員模塊等。根據(jù)功能劃分,可以將模塊內(nèi)部分為:配置文件、控制器、數(shù)據(jù)庫操作層、模型層、服務(wù)層等。5.1用戶端的實(shí)現(xiàn)用戶通過使用手機(jī)進(jìn)入網(wǎng)址訪問用戶端口,進(jìn)入網(wǎng)址后可以進(jìn)行線上預(yù)約,達(dá)到自助預(yù)約的目的。5.1.1注冊功能實(shí)現(xiàn)由于醫(yī)護(hù)人員屬于內(nèi)部賬戶,所以不添加注冊功能,只能由管理員在后臺(tái)添加賬戶,只有患者才可以通過注冊創(chuàng)建賬戶,如圖5-1所示。圖5-1注冊功能5.1.2預(yù)約功能實(shí)現(xiàn)患者登錄賬戶后,可以在首頁查看目前醫(yī)院設(shè)有的科室,如圖5-2所示:圖5-2科室查詢選擇準(zhǔn)備掛號的科室,查看科室下的醫(yī)生,列表頁主要展示了醫(yī)生的姓名、職稱、畢業(yè)院校等基礎(chǔ)信息,如圖5-3:圖5-3醫(yī)生選擇點(diǎn)擊醫(yī)生,查看醫(yī)生詳細(xì)情況,詳細(xì)介紹了醫(yī)生的職業(yè)經(jīng)歷,綜合決定掛誰的號,如圖5-4。圖5-4醫(yī)生信息查詢5.1.3個(gè)人信息修改功能實(shí)現(xiàn)在這個(gè)頁面內(nèi),患者可以修改自己的賬號、密碼和手機(jī)號,如圖5-5。圖5-5個(gè)人信息修改5.2醫(yī)生端的實(shí)現(xiàn)醫(yī)生通過管理員下發(fā)賬號,在WEB端進(jìn)行登錄,成功登錄后進(jìn)行后續(xù)的發(fā)步號源、診治、設(shè)備使用等操作。5.2.1醫(yī)生端登錄實(shí)現(xiàn)醫(yī)護(hù)人員屬于內(nèi)部賬戶,是由管理員在后臺(tái)管理中添加賬戶的,每位醫(yī)生都擁有自己個(gè)人的賬戶。登錄后頁面顯示如圖,醫(yī)生可以查看預(yù)約信息,發(fā)布號源,如圖5-6。圖5-6醫(yī)生登錄頁面5.2.2發(fā)布號源功能實(shí)現(xiàn)醫(yī)生自己按照日期-時(shí)間發(fā)布號源,可以選擇發(fā)布號源數(shù)量,如圖5-7。圖5-7發(fā)布號源功能5.2.3預(yù)約查詢功能實(shí)現(xiàn)醫(yī)生可以選擇患者信息、狀態(tài)、時(shí)間來查看預(yù)約信息。就診后可以點(diǎn)擊就診按鈕改變病患預(yù)約狀態(tài),如果患者由于某些原因無法就診,醫(yī)生可以點(diǎn)擊取消預(yù)約對預(yù)約進(jìn)行取消操作,如圖5-8。圖5-8預(yù)約查詢功能5.2.4個(gè)人信息修改功能實(shí)現(xiàn)醫(yī)生可以對個(gè)人信息、賬戶信息進(jìn)行修改,如圖5-9。圖5-9個(gè)人信息修改功能5.2.5設(shè)備使用功能實(shí)現(xiàn)醫(yī)生可以使用自己科室的醫(yī)療設(shè)備,當(dāng)使用時(shí),設(shè)備狀態(tài)由空閑中變?yōu)槭褂弥?,結(jié)束使用歸還設(shè)備,設(shè)備狀態(tài)又重新恢復(fù)為空閑狀態(tài)。如圖所示:圖5-10設(shè)備使用功能5.3傳統(tǒng)掛號端的實(shí)現(xiàn)掛號人員通過WEB網(wǎng)站訪問系統(tǒng),進(jìn)入系統(tǒng)后進(jìn)行掛號、銷號等操作。5.3.1傳統(tǒng)掛號端登錄的實(shí)現(xiàn)傳統(tǒng)掛號端是由掛號收費(fèi)處人員登錄進(jìn)行操作,該端口賬戶同醫(yī)生端一樣,是由后臺(tái)管理人員發(fā)布,不對外開放注冊,如圖5-11。圖5-11傳統(tǒng)掛號登錄5.3.2傳統(tǒng)掛號實(shí)現(xiàn)傳統(tǒng)掛號操作是由掛號收費(fèi)處人員通過詢問患者個(gè)人信息得知需要掛號的科室時(shí)間等信息后,人工輸入掛號信息進(jìn)行掛號預(yù)約操作,如圖5-12。掛號成功后醫(yī)生端會(huì)顯示預(yù)約信息。圖5-12根據(jù)患者信息進(jìn)行掛號掛號人員可以通過取消預(yù)約功能取消掛號,取消掛號也會(huì)改變患者預(yù)約信息,如圖5-13。圖5-13取消掛號功能5.4后臺(tái)管理端的實(shí)現(xiàn)后臺(tái)管理員通過WEB網(wǎng)站登入系統(tǒng),進(jìn)行后續(xù)的操作。5.4.1管理員登錄實(shí)現(xiàn)管理員賬戶由后臺(tái)管理員保存使用,賬戶具體信息在編碼中查詢修改,平臺(tái)只提供修改密碼功能,如圖5-14、5-15所示。圖5-14管理員登錄界面圖5-15管理員修改密碼5.4.2管理員操作實(shí)現(xiàn)①科室管理主要對醫(yī)院內(nèi)部各個(gè)科室進(jìn)行管理,主要有增刪改查等功能,由管理員來管理,菜單上對角色進(jìn)行了限制,如圖5-16。圖5-16科室管理②職位管理主要是指對醫(yī)院內(nèi)醫(yī)生的職位進(jìn)行管理,目前主要涵蓋了普通醫(yī)師、主治醫(yī)師、副主任醫(yī)師、主任醫(yī)生等。該功能由管理員進(jìn)行管理,如圖5-17所示。圖5-17職位管理③學(xué)歷管理學(xué)歷是醫(yī)生的一個(gè)屬性,為了減少數(shù)據(jù)庫表的構(gòu)建,系統(tǒng)內(nèi)把類似這樣的功能都擊中到一個(gè)數(shù)據(jù)字典類中進(jìn)行管理,學(xué)歷就是其中一塊,目前主要錄制了專科、本科、研究生、博士生等,如圖5-18所示。圖5-18學(xué)歷管理④預(yù)約狀態(tài)管理系統(tǒng)內(nèi)的預(yù)約狀態(tài)主要是指掛號號碼的狀態(tài),該狀態(tài)主要包括預(yù)約中、取消預(yù)約、已會(huì)診。同樣,該功能在數(shù)據(jù)字典中由管理員維護(hù),如圖5-19所示。圖5-19預(yù)約狀態(tài)管理⑤預(yù)約類型管理預(yù)約類型管理,主要是指掛號的來源,包括現(xiàn)場掛號、網(wǎng)上掛號倆種,由管理員維護(hù),如圖5-20所示。圖5-20預(yù)約類型管理⑥醫(yī)生管理主要是對醫(yī)護(hù)人員管理,為安全考慮,醫(yī)護(hù)人員的賬戶不提供注冊功能,由管理員統(tǒng)一管理,包括新增、賬戶信息修改、基本信息修改、編輯、刪除、賬戶密碼重置,如圖5-21所示。圖5-21醫(yī)生管理功能基礎(chǔ)信息管理包括醫(yī)生的姓名、工號、部門、職位、學(xué)歷、畢業(yè)院校、簡介等,如圖5-22所示。圖5-22醫(yī)生信息編輯功能⑦收費(fèi)人員管理收費(fèi)人員管理是指掛號收費(fèi)處操作人員賬戶管理,同醫(yī)護(hù)人員一樣,該功能只有管理員管理,不對外開放注冊,如圖5-23所示。圖5-23收費(fèi)人員管理功能⑧醫(yī)療設(shè)備管理醫(yī)療設(shè)備管理是指對醫(yī)療設(shè)備的各種管理,如按科室需求增加醫(yī)療設(shè)備,更改醫(yī)療設(shè)備狀態(tài)、刪除醫(yī)療設(shè)備信息等。如圖5-24所示。圖5-24醫(yī)療設(shè)備管理5.5測試在本系統(tǒng)測試中采用了兩種方法:白盒測試和黑盒測試。5.5.1白盒測試白盒測試主要測試軟件內(nèi)單元模塊的功能是否正常運(yùn)行,在該項(xiàng)目中,主要基于IDEA開發(fā)工具內(nèi)部構(gòu)建的JUnit測試工具,對單元模塊測試。白盒測試針對單元模塊測試,主要是因?yàn)閱卧K是組成整體系統(tǒng)的基石,系統(tǒng)某個(gè)功能是由內(nèi)部的很多單元模塊組合而成,為了保證整體功能的穩(wěn)定運(yùn)行,單元模塊必須可靠、有保障。由于Spring環(huán)境需要上下文加載才能正常運(yùn)行,所以這里要在測試類上注解加載基本的上下文,然后再測試功能,測試如圖5-25。圖5-25白盒測試5.5.2黑盒測試在系統(tǒng)開發(fā)完成后,需要先對功能表做黑盒測試,區(qū)別之于白盒的測試,黑盒測試時(shí)僅按要求錄入測試結(jié)果數(shù)據(jù),觀察其測量的結(jié)果數(shù)據(jù)能否準(zhǔn)確達(dá)到期望結(jié)果。例如患者登錄模塊,就是為了判斷賬號是否存在,密碼是否正確,角色是否正確。為了保證每個(gè)語句都有執(zhí)行,也就是語句、條件覆蓋,添加測試用例如下。測試賬戶:admin,密碼123456。表5-1登錄黑盒測試信息表編號輸入內(nèi)容預(yù)期結(jié)果實(shí)際結(jié)果是否符合預(yù)期賬戶密碼1空空登錄失敗登錄失敗是2admin空密碼錯(cuò)誤密碼錯(cuò)誤是3空123456賬戶不存在賬戶不存在是4admin1密碼錯(cuò)誤密碼錯(cuò)誤是5admin123456登錄成功登錄成功是對掛號預(yù)約模塊進(jìn)行測試,這里的判斷是號源是否發(fā)布,掛號是否成功,是否成功診治,是否取消預(yù)約。由于不發(fā)布號源無法進(jìn)行后續(xù)操作,故針對不發(fā)布號源只進(jìn)行一次測試,測試信息如下:表5-2掛號黑盒測試信息表編號是否發(fā)布號源是否掛號是否就診是否取消預(yù)期預(yù)約狀態(tài)實(shí)際預(yù)約狀態(tài)是否符合預(yù)期1否否否否無無是2是否否否無無是3是是否否預(yù)約中預(yù)約中是4是是是否已會(huì)診已會(huì)診是5是是否是取消預(yù)約取消預(yù)約是
6總結(jié)與展望6.1總結(jié)本文完成了“醫(yī)技預(yù)約平臺(tái)”WEB系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn),課題主要完成工作如下:通過文獻(xiàn)和社會(huì)調(diào)查,研究課題所在背景及開發(fā)意義;確保課題是有價(jià)值的。確定用戶所需要的功能。通過對醫(yī)技預(yù)約的
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 豫章師范學(xué)院《油畫靜物技法與表現(xiàn)》2023-2024學(xué)年第二學(xué)期期末試卷
- 珠海格力職業(yè)學(xué)院《藏文文法上》2023-2024學(xué)年第二學(xué)期期末試卷
- 遼寧石化職業(yè)技術(shù)學(xué)院《語文學(xué)科教育論》2023-2024學(xué)年第二學(xué)期期末試卷
- 西安歐亞學(xué)院《數(shù)據(jù)分析與可視化》2023-2024學(xué)年第二學(xué)期期末試卷
- 南京工業(yè)大學(xué)《建筑防火設(shè)計(jì)》2023-2024學(xué)年第二學(xué)期期末試卷
- 西安科技大學(xué)高新學(xué)院《汽車發(fā)展史》2023-2024學(xué)年第二學(xué)期期末試卷
- 遼寧工程技術(shù)大學(xué)《資產(chǎn)評估學(xué)》2023-2024學(xué)年第二學(xué)期期末試卷
- 四川航天職業(yè)技術(shù)學(xué)院《嵌入式系統(tǒng)設(shè)計(jì)與開發(fā)》2023-2024學(xué)年第二學(xué)期期末試卷
- 合肥信息技術(shù)職業(yè)學(xué)院《建筑類專業(yè)導(dǎo)論》2023-2024學(xué)年第二學(xué)期期末試卷
- 南華大學(xué)船山學(xué)院《素描半身帶手及全身像實(shí)踐教學(xué)》2023-2024學(xué)年第二學(xué)期期末試卷
- DL-T5704-2014火力發(fā)電廠熱力設(shè)備及管道保溫防腐施工質(zhì)量驗(yàn)收規(guī)程
- JT-T-610-2004公路隧道火災(zāi)報(bào)警系統(tǒng)技術(shù)條件
- 初中英語比較級和最高級專項(xiàng)練習(xí)題含答案
- 鑒賞詩歌人物形象市公開課一等獎(jiǎng)省賽課微課金獎(jiǎng)?wù)n件
- 大壩安全監(jiān)測系統(tǒng)驗(yàn)收規(guī)范
- 2024年南京鐵道職業(yè)技術(shù)學(xué)院單招職業(yè)技能測試題庫及答案解析
- 校園超市經(jīng)營投標(biāo)方案(技術(shù)方案)
- 康復(fù)醫(yī)院建筑設(shè)計(jì)標(biāo)準(zhǔn)
- 社會(huì)穩(wěn)定風(fēng)險(xiǎn)評估 投標(biāo)方案(技術(shù)方案)
- 高層建筑火災(zāi)撲救面臨問題及對策
- JC-T 738-2004水泥強(qiáng)度快速檢驗(yàn)方法
評論
0/150
提交評論