一.1. 項目背景
? 隨著科學技術的發展和進步，信息化、數字化和網絡化的不斷推廣和應用，醫院的工作方式也逐漸變化，醫院大樓的管理和運行方式不斷進步，分診排隊叫號系統已成為現代化醫院不可或缺的一個重要組成部分。
? 分診排隊叫號系統發展到今天，已經不再是簡單的醫患之間溝通的工具，在實際應用中應兼顧到醫院的整體設計，極有特色又具有良好實用性、裝飾性的設備將得到越來越廣泛的應用。
? 與此同時，我國醫療條件的匱乏與患者日益增多的矛盾越來越突出，醫院“看病難”、醫院擁擠、無排隊等現狀也日益明顯，如何把患者做好分流導診、有序排隊就診，縮短排隊時間，服務好患者，我們任重道遠。
? 作為一家致力于醫院就診流程優化、排隊叫號、解決患者“看病難”問題的醫療服務平臺公司，我們倍康公司深耕細作，日積月累，已經擁有了一套豐富、完整的整體解決方案。
一.2. 建設目標
信息化建設已日益成為提高醫院管理水平、醫療服務質量和醫療工作工作效率的有力手段，加快信息化建設是深化醫療改革、促進醫院發展的必然要求。
排隊叫號系統作為醫院信息化建設的重要組成部分，應體現以下目標：
l 系統實用性：
采用排隊叫號管理系統，可以真正解決患者就醫過程中的無序狀態，提高就醫環境質量，降低護士工作量，提高醫生工作環境質量，同時全面統計數據并加以多種分析，以供領導的決策。
l 系統穩定性：
排隊叫號管理系統在使用過程中是直接聯系患者、護士、醫生的主要紐帶之一，保持系統穩定可靠,連續不間斷的運行和服務,關系到廣大醫患之間的切身利益。系統在運行比較頻繁，不能出現故障，否則造成不但不能改善環境，反而使環境更為混亂的局面，穩定性是系統能否真正實用的一個不可缺少的重要指標。
l 系統成熟性：
醫院在運行過程中，不同醫院之間有很多的相同之處，同時各家醫院也有個性化的特點；系統要能夠適應醫院的特點，則必須對不同醫院的需求進行充分調研，以具備相當的成熟性。
l 系統拓展性：
信息化在不斷發展，要求排隊叫號系統健壯，可擴張性好，既能滿足目前的需要，又能保證系統能夠適應醫院今后快速發展的需求，保持和醫院的管理相適應。
l 系統兼容性：
信息化在醫院的眾多方面得以應用；醫院的信息網絡要得以**程度的應用，充分實現各個系統內部與外部的信息共享就顯得尤為重要；排隊叫號管理系統也需要與其他系統做好充分的共享，以發揮其更大的功能。
l 系統安全性：
系統安全性問題是實施信息化建設過程中必須重點考慮的。充分保障系統在各種特殊干擾環境下不丟失數據，以及對數據準確的檢驗機制，防止多種攻擊等。
一.3. 方案建設思路
我們根據醫院的需求，利用信息化的手段來改善患者的就診感受，在患者的就診排隊過程中，進行有序規劃，為實現現代化、科學化、合理化的排隊叫號，根據醫院的現有情況，制定了一整套的完善的專業解決方案。
方案從門診、醫技、藥房三大主要區域進行了分析，依托先進的網絡技術，結合人性化的服務，為醫院提供一套整體的排隊叫號系統，努力構建一個候診有序、安靜文明的就診環境，排隊叫號系統的建設，我們遵從整體規劃，分步細化，落實細節的指導思想。
l 門診區
一般的診區布局主要有兩大區域：候診區和診室
系統將根據場地特點進行合理的設計和布局：
1．在護士臺位置各配置一套診區管理系統（診區護士工作站），患者掛完號后就到診區等候坐椅上候診；
2．在護士臺位置的正上方設置一塊電子顯示屏，顯示目前的叫號和就診信息，同時可以通過流動的方式在顯示屏上面顯示一些提示信息（如通知、就診提示等）；
3．在患者等候區的上方，安裝兩個音箱，能過聲音提示患者就診；
4．在醫生的工作臺上，給每位醫生配置一臺呼叫終端（呼叫器）。
l 醫技區
一般的醫技區有兩大區域：候診區和醫技室
1．在醫技護士站配置護士長排隊叫號模塊，患者在醫技處簽到后，在候診區進行等待。
2．在醫技門口正上方安裝一塊電子顯示屏，顯示目前的叫號信息和就診信息，同時可以通過流動的方式在顯示屏上面顯示一些提示信息（如通知、就診提示等），并在上方安裝一個音響。
3．在醫生工作臺上，配備一臺呼叫器，呼叫下一個患者。
l 藥房區
藥房區一般也有兩大區域，取藥排隊區和藥房
1．在藥房工作站安裝藥房排隊模塊子系統，醫院根據實際情況，定義是否是繳費后就可撿藥，還是簽到后才撿藥。
2．在藥房窗口正上方安裝一塊電子顯示屏，顯示目前的叫號信息，同時可以通過流動的方式在顯示屏上面顯示一些提示信息（如通知提示等），并在上方安裝一個音響。
3．在藥房工作臺上，每個窗口配備一臺呼叫器，呼叫下一個患者。
一.4. 方案建設價值
本方案部署后，醫院不僅可以更大程度地提高服務質量及工作效率，更可以體現出醫院以人為本的特色，全面提高就醫者對醫院的滿意度，全面提高對患者的服務水平，吸引更多的患者前來醫院就診，打造醫院醫療服務品牌。具體可從以下幾個方面來體現：
l 管理層面
? 響應衛生部、衛生廳及政府的政策號召，把提高醫療服務效率落到實處。
? 為醫院面臨的三級醫院評審中的“醫院服務”部分加分，幫助醫院改善、分流候診排隊現象，方便患者就診。
? 可根據系統生成的多種就診統計報表，對醫護人員進行相應方面的量化考核。
? 將實時的排隊候診情況畫面，通過系統或者監控等，傳送到院長辦公室或者相關部門，實時監控，強化醫院管理。
l 患者層面
? 系統按序自動安排患者到最適合的或者患者自己所選擇的醫生處就診，真正實現了“個人”化服務和“交互式”服務；
? 減少患者的等待時間，少了大部分的人工環節，中間環節大部分采用系統控制，縮短患者的排隊時間；
? 避免發生排錯號、插隊等現象，減少許多不必要的糾紛隱患；
? 營造一個輕松平和、公平有序、合理的就診環境，給患者帶來輕松愉快的心情；
l 醫護層面
? 方便醫生應診、杜絕圍醫搶醫的現象發生、杜絕診室的紛亂現象；
? 不再因為患者不斷推門咨詢和闖入而擾亂工作；
? 優化的工作環境可以減少工作失誤，提高工作效率，提高診治的質量；
? 減輕分診護士工作量、提高導診工作效率。
一.5. 方案建設前后效果圖對比
l 未建設排隊叫號系統前（如下圖）
#嘈雜的環境，心急的等候
l 建設排隊叫號系統后（如下圖）
#有序的就診，文明的趨勢
第二章 排隊叫號系統建設內容
二.1. 系統概述
我們在醫院現有成熟的HIS系統基礎上，利用等離子或者液晶顯示屏等設備作為顯示終端，結合揚聲器與簽到等設備，與醫院現有的HIS 系統進行數據對接，通過軟件集成，建設一套集中、統一的電子排隊叫號管理系統，通過此套系統的應用，實現各門診科室信息的電子化，有序化，從而達到改善醫院候診排隊的管理服務水平，提高醫院就診處理的工作效率，讓患者在安靜、文明、和諧的環境中感受到醫院提供的優質服務。
方案共包含以下四大部分：
二.2. 排隊叫號系統介紹
醫院分診排隊叫號系統是通過患者自助刷卡簽到或者掛號等多種方式進入隊列，護士對隊列實行分診叫號，方便患者有序、舒適就診。整個系統軟件包括門診子系統，醫技子系統，藥房子系統，后臺管理子系統四大子系統。
二.2.1. 門診子系統
門診子系統包含診區護士和診區醫生站兩大模塊:
l 診區護士站
此系統模塊安裝在候診區護士站，護士通過操作系統來完成候診區的排隊叫號，使候診區形成一個有序，舒適的候診環境。
簽到：患者可通過刷卡或直接提供憑條給護士，進入候著隊列（一級分診）；
呼叫：護士可手動補齊候診患者進入診室待診隊列（二級分診），同時喇叭呼叫，聽到呼叫的患者進入診間就診；
維護隊列：當有特殊情況的時候，護士可拖動隊列信息調整候診隊列中患者排隊情況；
批量叫號：當候診區和診間有一定的距離的時候，護士可以一次性從候診隊列中叫入多名患者進入醫生待診序列中，方便醫生叫入下一位患者，節省到診間距離的時間；
優先級調整：如患者是軍人，老人，預約患者，過號患者等在醫院的規定范圍內，均可通過護士站調整排隊優先級。
指定醫生：如果患者想在上一次就診的醫生處就診，可以通過護士的調配來完成。
回診處理：當患者是由于需要先去做檢查，然后在回診給醫生確定檢查結果的患者，可以進行重呼并優先進入隊列。
l 診區醫生站
此模塊系統安裝在醫生診間，原則是排隊叫號系統不影響醫生操作HIS等業務系統，界面精小方便，以一橫條或者最小化到任務欄的形式展現。
主要功能有：
呼叫：醫生可以手動點擊“下一批”來批量呼叫待診患者，也可以啟動自動模式，當確定就診完一個患者后，系統自動補齊一個，也可取消自動補齊功能。
暫停：醫生有其他情況的時候可以暫停診療，護士查看到醫生暫停則不再進行下一批患者補錄，當醫生恢復診療狀態，護士再批量叫入待診。
刷新：為減少服務器的壓力，醫生站刷新時間間隔10秒，如果數據上有點滯待，可以點擊立即刷新信息。
過號：如果患者多次呼叫仍然未到，可以點確認已經就診，作過號處理，如果患者到來，可以點擊重置，進行看病。
二.2.2. 醫技子系統
此模塊安裝在醫技護士站，護士通過操作系統來完成候診區的排隊叫號，使候診區形成一個有序，舒適的就診環境。
主要功能有：
l 登記簽到：患者可通過刷卡或直接提供憑條給護士使用，進入候著隊列
l 呼叫：護士可手動補齊候診患者進入診室待診隊列，并進行喇叭呼叫
l 維護隊列：護士可拖動隊列信息調整候診隊列中患者排隊情況
l 批量叫號：護士可以一次性從候診隊列中叫入多名患者進入醫生待診序列中，方便醫生叫入下一位操作
l 優先級調整：如患者是軍人，老人，預約患者，過號患者等均可通過護士站調整優先級。
二.2.3. 藥房子系統
此模塊安裝在藥房，發藥醫生通過操作系統來完成候診區的排隊叫號，完成藥房的領藥工作，使藥房區保持安靜、有序、快捷的取藥環境。
功能描述：
患者繳費后需刷卡確定取藥，否則藥房不進行擺藥，當患者刷卡確定后，藥房擺藥同時進入隊列進行等候，當藥品擺好，通知發藥師叫號。
二.2.4. 后臺管理子系統
此模塊安裝在系統管理員處，主要是為各站子系統提供后臺的配置、同步、運行管理等服務。
主要功能有：
l 病區、科室、診間等設置
l 用戶管理及權限
l 隊列管理
l 醫技室和藥房管理
l 自動同步HIS掛號信息
l 自動同步HIS退號信息
l 自動同步HIS 就診狀態
l 自動同步HIS 檢查單信息
l 自動同步HIS檢驗單信息
l 自動同步HIS 號別信息
二.2.5. 整體功能清單
飛博排隊叫號系統功能清單 |
門診子系統 |
功能 | 功能說明 |
簽到 | 患者簽到，支持刷卡器讀取醫院就診卡進行排隊簽到，無需手動輸入 |
指定醫生 | 根據患者需要指定就診醫生 |
優先級調整 | 手動調整患者優先級（老人、軍人、急診…），預約患者優先級自動調整，過號后，患者需重新刷卡進入隊列，手動調整優先級 |
診間就診 | 需安排患者進入診間時，有文字及閃爍提醒，通知護士及時安排患者進入診間 |
護士呼叫 | 呼叫人數可以根據具體情況成批固定數量呼叫，也能調整人數補齊方式呼叫。 |
刷新 | 手動刷新和自動刷新就診狀態，人性化提醒護士及時安排患者進入診間 |
查看 | 查看各個科室的待診隊列和已診隊列，停電后能自動保存排隊情況（已呼叫和未呼叫），來電后不影響系統工作。 |
設置 | 設置每日開診的診室及醫生情況 |
醫生呼叫 | 醫生端也具有自主呼叫待診患者的功能，加強了醫生和護士的協調性，無需登錄，雙擊直接打開醫生端即可（需要設置診間等位置信息） |
下一個 | 醫生呼叫下一個待診患者，也可以通過快捷鍵呼叫，同時支持硬件叫號器呼叫。 |
暫停 | 支持醫生暫?；蛲Ｔ\處理，暫?？苫謴屠^續接診，護士可將停診隊列中已簽入的患者改到其他隊列中。 |
醫技子系統 |
輸入 | 根據實際情況，護士可輸入患者信息。 |
簽到 | 在有自助簽到設備的情況下，支持患者在護士站自助簽到 |
調配 | 能安排調配患者就診時間，遇到急診情況，可優先安排 |
叫號 | 可配備叫號器與護士站軟件配合，實現叫號 |
優先級調整 | 如患者是軍人，老人，預約患者，過號患者等均可通過護士站調整優先級 |
藥房子系統 |
簽到 | 患者繳費后，需要通過刷卡簽到確定取藥，藥房根據所需藥品進行收集 |
叫號 | 通過系統實現廣播進行叫號，患者一次領藥 |
后臺管理子系統 |
用戶組管理 | 定義系統使用用戶組，可按不同的分組來管理 |
用戶管理 | 新增使用系統的用戶，如用戶信息有變化可進行修改或者刪除 |
用戶組權限管理 | 通過分組來定義系統用戶的操作權限 |
病區管理 | 定義醫院的病區分步 |
科室管理 | 可從HIS里導入醫院科室信息，保持與HIS同步 |
診間管理 | 定義醫院診間信息 |
檢查室管理 | 定義醫院的檢查室信息 |
藥房管理 | 定義藥房信息 |
護士工作站管理 | 定義醫院護士工作站信息 |
職稱管理 | 定義醫生或者護士不同的職稱名稱 |
醫生管理 | 可從HIS導入醫生信息及醫生排班信息 |
就診類型管理 | 可從HIS導入數據，支持修改 |
優先級管理 | 定義候診隊列優先級別標記 |
當日出診管理 | 定義，修改當日出診的醫生情況安排 |
檢查項目管理 | 可從HIS導入數據 |
檢查分組 | 對不同的檢查類型進行分組管理 |
檢查類型 | 可從HIS導入數據 |
屏幕管理 | 定義，控制排隊系統中的屏幕數量及屏幕顯示內容等 |
揚聲器管理 | 定義，控制揚聲器的數量及發聲規則等 |
廣播（可運行在護士站） |
播放 | 自動播放呼喚患者進入診間語音 |
次數 | 可設置播放次數 |
再次播放 | 可人工控制再次補叫播放 |
清空 | 自動清空播放隊列 |
格式設置 | 播放語音內容格式可自主設置調整 |
聲音切換 | 支持男女發聲語音切換 |
移動終端 |
實時查看 | 支持 患者可以通過智能手機實時查看隊列信息，無縫對接倍康手機移動醫療服務平臺 |
實時推送 | 支持隊列信息推送提示，主動提醒患者，實現“向導式就診” |
實時掛號 | 支持網絡平臺掛號進入院內排隊隊列 |
二.3. 排隊叫號硬件模塊介紹
說明：硬件設備根據每個醫院的需求不一樣而定制，下面介紹幾種常用的硬件設備
二.3.1. 顯示屏
診區Tv顯示屏
描述：主要在診區顯示患者編號、姓名、對應科室、檢查類型，診室號及隊列情況
藥房顯示屏：
描述：主要在藥房顯示取藥患者姓名及列表
診間LED顯示屏
描述：主要在醫生診間顯示當前患者編號
二.3.2. 揚聲器
吸頂式揚聲器
描述：傳遞語音叫號聲音
二.3.3. 功放設備
多功能會場功放
描述：功率放大，擴大音量
二.3.4. 呼叫器
物理呼叫器
描述：用于醫生呼叫下一批患者進入診間，并能有效統計患者數及提醒醫生會診等功能
二.3.5. 簽到設備
自助簽到刷卡機
描述：用于大廳為患者提供排隊自助簽到功能
刷卡機
描述：用于護士站為患者提供排隊簽到功能
二.3.6. 電子錄入設備
高拍儀
描述：用于采集臨床紙質申請單等
二.4. 系統工作流程
第三章
公司技術優勢
三.1. 醫院系統運行卡頓問題的解決
行業內很多家廠商的軟件系統在早年間因架構設計的原因，隨著醫院醫院信息系統運行的年限越長積累的數據量越大，系統運行的速度就越來越慢，目前已極大的影響了醫院為病人服務的效果。醫院信息系統運行速度慢的原因，主要是應用軟件的數據結構設計方法問題。
目前，采用多維數據庫、數據庫分區、不拘泥于數據設計的范式的要求、使用臨時數據表等方法都可以提高數據庫運行的速度和效率，從而達到提高醫院信息系統的運行速度的目的。這些方法在醫院信息軟件中的綜合運用取得了運行速度快、節約醫院信息系統運行成本的良好的效果，也是目前軟件數據庫的主流設計思路。
三.1.1. 問題的提出
醫院信息系統的運行速度問題是影響醫院為病人服務的問題也是關系到醫院信息系統發展，降低醫院信息系統成本的問題。
隨著醫院信息管理系統運行的軟件模塊的數量越來越多，特別是以電子病歷為中心的臨床信息系統的使用，導致醫院信息系統的數據庫的數據量不斷增加，數據之間的關聯更為復雜，運行時間1-2年以后信息系統的運行速度成為信息系統使用的瓶頸。很多醫院，特別是大、中型醫院信息系統的運行速度變慢甚至發生系統阻塞、死鎖、數據錯誤等問題。更為嚴重的是醫院信息系統速度慢多發生在醫院業務的高峰期上午9時至11時,對病人服務的影響尤為嚴重。這是我國醫院信息系統運行中比較普遍存在亟待解決的問題。
醫院信息管理系統運行的數據庫系統絕大多數都使用大型關系型數據庫（RDBEMS）。包括ORACL、MSSQLSERVER、SYBASE等。由于關系型數據庫的本質是數據記錄（關系元組）的線性集合。隨著數據庫系統運行時間的增長數據庫的數據量不斷增加會使數據的處理速度變慢，導致醫院信息庫系統的運行速度變慢。數據庫的數據之間的關聯程度越大、數據共享程度越高也會導致系統運行的速度降低。
目前大多數醫院信息系統主要使用兩種方法來提高系統的運行速度。一是把數據庫中的數據轉出減少數據庫中的數據量以提高數據庫系統的運行速度。但是這對于需要長期、大量數據實時在線的數據庫系統特別是需要長期保持數據在線的電子病歷系統是相當麻煩或不可行的。二是購買更好的硬件（服務器、交換機、網絡、工作站等），以提高醫院信息系統的運行速度。甚至發生醫院信息系統建設廠商要求一家400張床位的醫院購買小型機來提高系統運行速度的情況。這種方法大大增加了醫院信息系統系統的運行成本，這些方法都是治標不治本的解決方法。
三.1.2. 影響醫院信息系統運行速度的因素
醫院信息系統的運行速度受多種因素的影響包括應用軟件的數據結構設計、數據庫的種類、網絡和硬件配置、使用系統的站點數量等。
我們認為應用軟件的數據結構設計是最重要的因素是最值得關注的解決醫院信息系統運行速度問題的方法。
在數據庫種類方面，醫院信息系統系統大多都是使用大型關系型數據庫ORACL、MS SQL SERVER、SYBASE、DB2等只要運用得當對運行速度的影響并不大。網絡和硬件配置、使用系統的站點數量也是影響影響運行速度的重要因素。在資金投入允許的條件下網絡和硬件配置越好運行速度越快使用系統的站點數量越多運行速度越慢。
三.1.3. 應用軟件的數據結構設計的方法
既然應用軟件的數據結構設計是影響醫院信息系統的運行速度的最重要的因素。我們在應用軟件的數據結構設計方法方面可以采取以下方法來提高應用軟件的運行速度。
1) 多維數據庫設計方法
多維數據庫設計是指在關系型數據庫的基礎上在醫院應用軟件的設計中采用多維的方法對數據進行組織、存儲。通過多維化的數據組織存儲設計從根本上解決數據庫系統長期快速運行數據長期在線的問題。解決醫院信息系統隨著運行的時間增長數據庫系統的數據量不斷增加大用戶量的數據并發處理需要提高速度歷史數據需要長期在線存儲等問題。
多維數據庫設計方法是一種針對關系型數據庫的高效率、特殊的數據結構組織、存儲設計的技術方法。多維化數據設計的關鍵技術是從數據的時間、歸屬、數據狀態、序列等維度進行數據分析、組織建立數據存儲的多維化模型進行系統數據和程序設計解決信息共享和信息存儲、系統運行速度等問題滿足醫院信息系統數據海量存儲和實時存取的需要。
特別是電子病歷系統可能有幾十、幾百甚至上千個醫務人員同時并發使用電子病歷數據，海量的電子病歷數據需要快速存儲，有的病人的電子病歷需要1-5年或更長時間的在線存儲（老年慢性病人、精神病病人等）。多維化數據設計方法，能夠從根本上解決醫院信息系統，特別是電子病歷系統多用戶并發處理，大數據量快速存儲，數據長期在線，系統長期快速穩定運行的問題?？梢詫崿F醫院信息系統在大數據量（1TGB）以上5~10年數據實時在線300~2000個用戶并發使用的條件下電子病歷系統的快速運行問題。實現海量存儲和實時快速存取的統一降低電子病歷的運行成本。
多維數據庫設計的具體方法是首先進行數據維度分析。對應用系統的數據從數據的時間、歸屬、業務、狀態和序列等維度進行分析設計再建立時間維度模式年、月、日等、歸屬維度模式病人、科室、病區、藥庫、藥房等、業務維度模式掛號、收費、處方、醫囑、病歷、病程記錄等、狀態維度模式已收費、未收費、已執行、未執行等序列維度模式掛號序列的序號、收費單據的單據號、科室的編號等等模式的數據庫和或數據表構建多維化數據庫。設計應用程序時根據數據的多維化組織模式進行軟件程序設計和開發。
十多年來我們對醫院信息系統的多維數據庫設計技術進行了不斷的研究和應用，目前已經在部分中大型醫院的實際運行中取得了良好效果。
2) 數據庫分區設計方法
數據庫分區設計方法是通過數據分區的設計來提高數據庫的讀寫性能和效率從而提高系統運行速度。
數據庫分區是一種對數據表的橫向分割將表、索引或索引組織表進一步細分為段的設計技術這些數據庫的段叫做分區。數據庫分區的原理是當數據表中的數據量不斷增大使用數據的速度就會變慢導致應用程序的運行速度下降。通過對數據庫的數據表的分區將表中的數據在物理上存放到多個表空間(物理文件上)這樣應用程序使用分區數據表會改善性能和可用性從而提高應用程序運行速度。
當數據表的大小超過2GB或表中包含歷史數據需要把新的數據增加到新的分區中時應使用數據庫分區技術進行應用軟件的數據設計來提高系統的運行速度。
3) 突破數據設計的范式要求
醫院信息系統數據之間的關聯非常復雜往往在處理一個業務時需要打開或管理多個數據表庫。加之同一業務可能有幾十或幾百個站點并發處理。導致數據表的之間的關系非常復雜影響應用系統的運行速度甚至導致堵塞、死鎖等問題。因此在應用軟件的數據庫設計中不可拘泥于數據庫設計的第三范式的要求在數據設計中適當的增加數據冗余以減少數據表之間的關聯提高數據提取的速度，從而提高醫院信息系統的運行的速度。
4) 充分運用臨時數據表技術
醫院信息系統應用軟件運行中，需要對數據庫進行寫表的操作很多，而且可能是一次操作需要寫入多條記錄（如處方、醫囑、收費等）,同時還會有多個操作員并發操作。由于寫表時對數據庫的運行速度影響很大，因此應充分應用臨時表技術，先建立臨時表，把需要寫入的數據先寫入臨時表，再把臨時表的數據一次性添加到數據表中。提高數據處理的速度，進而提高醫院信息系統的運行速度。如果運用臨時表技術把臨時表建立在緩存中效果更好。
三.1.4. 解決醫院信息系統運行速度問題的效果
我們在醫院信息系統應用軟件設計中，綜合采用以上方法，特別是采用了多維數據庫設計方法，實現了醫院信息系統長期快速運行，數據長期實時在線，系統運行5~10年，數據全部聯機保存，運行速度與**年基本一致的要求的效果?？梢越鉀Q當前醫院信息系統比較普遍存在的隨著系統運行時間的增長，系統的運行速度越來越慢的問題。而且可以降低服務器等硬件系統的配置，降低醫院信息系統運行的成本。
三.2. B/S化設計特征
目前本司已實現全應用的B/S化開發設計，以下是C/S架構應用與B/S架構應用對比介紹：
序號 | 指標 | C/S | B/S | 備注 |
1. | 定義 | CS（Client/Server）指客戶端/服務器架構模式。 客戶端需要安裝專用的客戶端軟件。 | BS（Browser/Server）：瀏覽器/服務器結構，是目前應用系統的發展方向。 客戶端采用瀏覽器運行軟件。 |
|
2. | 優點 | 交互性強 存取模式安全 網絡通信量低 響應速度快 利于處理大量數據 無拓展性，目前新的技術都不在用C/S架構研發了，軟件上限已固定。 | 分布性強，客戶端零維護。只要有網絡、瀏覽器，可以隨時隨地進行查詢、瀏覽等業務處理。 業務擴展簡單方便，通過增加網頁即可增加服務器功能。 維護簡單方便，只需要改變網頁，即可實現所有用戶的同步更新。 開發簡單，共享性強。 拓展性強，新技術基本都是基于B/S架構研發，軟件能不斷增加新技術新功能，順應時代持續成長。 |
|
3. | 缺點 | ●需要專門的客戶端安裝程序，分布功能弱，針對點多面廣且不具備網絡條件的用戶群體，不能夠實現快速部署安裝和配置。 ●兼容性差，對于不同的開發工具，具有較大的局限性。若采用不同工具，需要重新改寫程序。 ●開發、維護成本較高，需要具有一定專業水準的技術人員才能完成，發生一次升級，則所有客戶端的程序都需要改變。 | ●一般用源碼開發的B/S系統個性化特點明顯降低，無法實現具有個性化的功能要求。(這一點快速開發平臺開發可以進行解決) ●在速度和安全性上需要花費巨大的設計成本，所以目前市面上普遍的廠商報價都非常貴。 |
|
4. | 開發和維護成本 | CS開發和維護的成本高于BS。 CS結構軟件安裝調試升級都需要在所有客戶機上進行。 | BS結構只需要將服務器上的軟件版本升級即可，不必安裝與維護。 |
|
5. | 硬件環境 | CS結構要求必須有相同的操作系統。 CS客戶端的計算機電腦配置要求較高。 CS的每一個客戶端都必須安裝和配置軟件。 | BS結構因為在瀏覽器上運行只要有操作系統和瀏覽器就行。 BS客戶端的計算機電腦配置要求較低。 BS客戶端在瀏覽器上運行不必安裝。 |
|
6. | 負載 | CS客戶端負載大。 CS客戶端與用戶交互、收集信息，向后臺請求。 | BS客戶端由后臺處理數據，前端只顯示內容。 |
|
7. | 安全性 | CS安全性較高，可以通過嚴格的管理來應用于指定人群。 | BS使用人數多，無法精確控制。（可通過嚴格的組織機構權限設置進行控制，本司基于平臺開發已實現） |
|
總體來說相比于CS管理系統，BS 在安裝部署、升級維護、設備帶寬、軟件學習推廣成本等方面都有無可比擬的優勢。
因為傳統的C/S架構系統前臺與后臺數據直接交流，在醫院數據量較小時速度優勢明顯。但隨著醫院規模越來越大，終端用戶越來越多，C/S架構的系統受數據庫連接限制，速度越來越慢，反而變成了劣勢。
B/S架構下的應用是通過瀏覽器作為用戶端，無需進行部署安裝，無本地化客戶端，擺脫了對Windows操作系統的依賴，可無縫切換至國產操作系統，能積極響目前國家對于網絡數據安全的要求。
瀏覽器的方式也使得用戶的使用十分方便，用戶可以何時何地通過Internet訪問URL而進行相應的工作，升級維護也能比較集中。非常適合未來醫院在很多應用范圍涉及區域逐漸變廣，用戶會需要通過不同的地點快捷進行訪問的工作模式。
B/S架構**的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件，只要有一臺能上網的電腦就能使用，客戶端零安裝、零維護，系統的擴展非常容易。
三.3. 原生代碼開發與平臺開發區別
本司是行業內**的低代碼快速開發平臺式軟件開發模式，早期就一直使用平臺化開發架構應用，用戶在軟件的使用過程中能利用開發平臺不斷的對醫院系統進行優化細化，達到醫院在運行過程中產生的各種細節需求都能通過平臺進行滿足，真正實現客戶自己想要的軟件。這一點是所有源代碼開發系統寫死的公司做不到的。
19年公司也已從原來的C/S開發平臺迭代至全新的B/S開發平臺，基于B/S技術封裝了行業最前沿的技術模塊，更能支持醫院下個十年的高速發展。以下介紹原生代碼與低代碼平臺化開發的區別：
傳統原生代碼開發/低代碼開發的比較 |
序號 | 指標 | 傳統原生代碼開發 | 低代碼開發平臺 |
1 | 開發難度 | 高 | 低 |
2 | 開發周期 | 長
代碼級開發，開發和測試周期都很長，而且開發好的系統也要磨合一定時間才能穩定。 | 短
一天可以開發十幾個模塊，且測試簡單，性能穩定，不需要磨合時間。 |
3 | 開發人員要求 | 高
精通編程語言、數據庫和各種開發技術的人才。 | 低
無需懂開發語言，只需要稍懂數據庫。 |
4 | 開發成本 | 高
對開發人員要求高及開發時間長，開發成本高。 | 低
對開發人員要求相對較低，成熟的模塊化開發，開發時間較短，開發成本相對較低。 |
5 | 維護成本 | 高
維護時由于代碼級修改，可能會導致產品其他地方錯誤，引起新的問題，調試十分麻煩。 | 低
維護只是重新配置一下規則，不用修改代碼，不會引起關聯問題，調試簡單方便。 |
6 | 安全性 | 高
需要專業人員做安全處理。 | 高
平臺已在所有有可能出現漏洞的地方做了安全處理。應用系統開發人員無需關心這些復雜繁瑣的工作。 |
7 | 數據庫支持 | 難
需要支持多種類型的數據庫或每個模塊對應不同的數據庫。由于各種數據庫語法不同，傳統開發處理起來非常麻煩。 | 支持
支持多種類型的數據庫或每個模塊對應不同的數據庫。對于各種數據庫的語法轉換，平臺會自動處理。 |
8 | 界面統一美觀性 | 難實現
如果項目由多人同時開發，每人開發風格不同，很難保證界面統一，不統一的界面給用戶帶來不好的用戶體驗。增加學習成本，使用不方便。 | 容易
平臺界面自動生成，并且提供大量界面控件來生成統一而精美的界面。 |
9 | 擴展性 | 較好 但需要專業技術到達一定水平工程師進行處理，不然BUG率高。 | 好
代碼級開發，豐富多樣的模板庫，高自由度的組合方式，擴展靈活性高。 |
三.4. 平臺化開發設計的便捷及通用功能介紹
1) 集團化的組織機構管理，可設置多個機構進行統一管理，每個機構的可設置專項角色屬性與賬戶關聯進行相關的權限管理；用戶管理員可通過權限控制是否對組織機構中某“角色”顯示某應用界面；用戶管理員可通過權限控制是否對組織機構中某“角色”顯示某應用界面中的某些按鈕功能。
（實施人員會根據醫院實際情況進行相關權限的設置，系統驗收后醫院發展新增角色及用戶，可通過管理員賬號自主設置）
2) 用戶可自由設置所有應用界面上的字段排列順序以及按顯示需求進行是否顯示的設置，該功能不影響業務流程；
3) 查詢功能的搜索條件可進行設置，可通過任何一條字段的設置及相應條件的設置進行多層數據查詢；
4) 軟件的界面主題客戶可自行進行更換，界面展示風格、窗體風格、按鈕風格等可個性化設置；
5) 集成門戶功能：可實現多應用集成至系統登錄門戶里,通過系統入口即可實現登錄所有其他異構系統并進行操作；
6) 一鍵更新功能：服務器一鍵跟更新，無需每臺客戶端進行更新處理；
7) 消息機制：可在程序設置定時或者觸發式消息機制，用戶可通過短信或者微信等方式接收到新的消息；
8) 分流式表結構設計讓數據登記與查詢分開，系統數據積累再多也不會導致卡頓；
9) 數據抽取機制：通過大數據抽取及管道傳輸技術，可將所有系統數據庫中任意表的任意字段進行抽取復制，不影響主系統業務的執行，同時能進行數據實時的查詢及展示；
10) 駕駛艙：數據展示不再是單純的網格顯示，可通過駕駛艙顯示多樣化的數據展示效果，所有數據效果更直觀；
11) 用戶可通過開發平臺“向導”功能快速創建擁有完整的增刪改查功能的模塊，并且可自主構建數據建模數據集及數據字典，實現無代碼開發小功能小模塊；
12) 數據字典:大部分引用的國標化的數據字典，讓所有數據統一規范化，同時開發用戶可通過平臺進行數據字典的自主新增及名稱修改的無代碼開發；
13) 低代碼開發平臺會不斷開發并引用更多行業前沿技術，將支持醫院未來智慧智能化的建設需求。
三.5. 數據管道工具
三.5.1. 應用功能
1) 項目管理
項目管理用于對構建的任務進行分類，維護各類型數據抽取任務。
2) 執行器管理
執行器管理是彈性增減執行器界面。執行器是整個抽取任務的“大腦”，支持集群執行器部署，當遇到性能瓶頸，可以平滑添加執行器。
3) 數據源管理
數據源管理界面專門維護數據庫鏈接，支持mysql、oracle、postgresql、sqlserver、mongodb、hive、hbase等數據庫。所有配置的連接信息都是經過加密處理保存。
4) 日志管理
日志管理專門提供執行任務的日志信息檢索及查看。對每個任務執行進度進行明細記錄，可以根據日志快速回溯及糾錯。
5) 用戶管理
用戶管理專門用來維護用戶?？梢愿鶕煌瑘鼍霸O置不同的用戶權限。
6) 資源監控
資源監控實時展示CPU使用率、內存使用率、平均負載，可以設置資源閾值報警機制，當達到閾值時，可短信及郵件通知運維人員。
7) 任務模板
任務模板是一個調度性能的模板?？梢栽O置執行器、路由策略、阻塞方式、執行時間、報警郵件、任務資源參數。
8) 任務構建
任務構建是一個數據抽取的配置界面。通過綁定之前設置好的數據源，簡單的寫入sql語句，綁定一個任務模板，即可完成一個數據抽取任務。
9) 批量任務構建
批量任務構建是批量數據抽取的配置界面。效果和單個任務構建一致。
10) 任務管理
任務管理是一個任務調度界面。界面上面展示了詳細的路由策略與執行規律?？梢栽诮缑婵旖菪薷恼{度配置信息、任務的開啟與關閉。
三.5.2. 技術特征
1) 多數據庫支持
支持mysql、oracle、postgresql、sqlserver、mongodb、hive、hbase等數據庫。
2) 可視化抽取配置
通過界面，選著好執行器、路由策略、阻塞方式、執行時間、報警郵件、任務資源參數即可快速生成抽取任務。
3) 可視化調度監控
完整可視化任務監控，支持隨時修改任務配置，啟動及關閉任務。
4) 原子級日志監控
每個任務執行過程都詳細記錄操作日志信息，方便數據回溯、問題排查。
5) 集群化部署
執行器支持集群化部署，彈性提升整體執行效率。
6) 性能監控
可以隨時查看服務器CPU、內存、負載均衡各項指標，支持設置閾值，當關鍵指標任務發生錯誤或服務器性能異常發送郵件及短信提醒。
第四章 項目實施管理
四.1. 項目的組織形式
任何一個工程項目的成功建設，清晰的項目領導管理組織機構至關重要。本次項目的實施涉及用戶多個業務和技術部門，組織協調具有一定難度。其有效啟動和實施，**步就是成立相應的項目管理領導機構及項目實施機構，該機構應該規格層次恰當，能充分理解和執行用戶的需求和決策，能有效協調各個業務和技術部門，具備完善的應急處理流程和措施等，以保證足夠的運作、管理、協調能力。
圖 3-1 項目組織形式
上述的組織形式主要有以下優勢：
? 項目成立項目管理組，項目經理直接聯系公司總部，結構簡單，責權分明、命令統一，反應迅速，聯系、溝通簡捷，工作效率高；
? 項目組由項目經理指揮，獨立性大，避免行政干預，有利于提高工作效率；
? 按職能分工，人員均為各職能專家，可充分發揮專家作用，大大提高了管理的專業化程度；
? 項目工作人員大部分為公司員工，因此不存在磨合，配合默契，提高了工作效率。
四.2. 項目計劃
準備階段 |
商務準備 | 1) 實施計劃編制 武漢飛博科技有限公司實施項目組根據項目的實際情況，在與院方相關人員初步接觸溝通后，編制實施計劃文檔。 2) 實施計劃確認 雙方的相關人員共同對本實施計劃進行修訂和確認。 3) 召開項目啟動大會 項目的實施是一項繁瑣、細致、認真、嚴肅的事情，可能會在一定程度上影響現有的業務操作習慣，也可能會造成不同崗位之間工作量的重新分配等情況，各種因素都有可能造成某些人員對項目推行的抵觸。 因此，建議院方在項目正式實施之前，事先在內部召開動員大會或者下達正式的書面通知，讓大家對實施的項目有所認識和準備，并引起足夠的重視，充分調動各方面人員的積極性。 經驗證明，院方領導對項目的重視程度，將會成為左右項目實施成效的關鍵。 |
人員準備 | 1) 成立項目組 成立項目組，由雙方的人員共同參與，項目組直接向院方本項目主管人員信息科主任匯報工作。在本項目院方主管人員賦予相關的執行權限后，可以在實施期間調度所需要的相關資源，確保項目的順利實施。 2) 起草管理制度和崗位職責 院方內部制定合理有效的管理制度，落實各項具體工作的負責人和責任人，明確問題反饋和解決問題的詳細流程，充分做好上線前期的準備工作，確保項目的順利實施。 |
環境準備 | ? 軟件環境準備 如果系統運行有需要于其他第三方系統進行對接工作，為了不影響本系統上線使用，實施前請確保第三方系統已正常上線運行并且有相關人員能進行工作上的配合。 ? 網絡環境準備 服務器需要在醫院內網上有固定的 IP 地址。 ? 培訓環境準備 投影儀：以便在培訓過程中取得更好的視覺效果。 會議室：會議室或者能容納培訓人員的較寬敞場地。 時間：事先安排好各個崗位的工作時間，以便按時參加培訓。 建議采用進行統一培訓的方式，如果人員數量比較多或者由于工作時間等因素，可以分批培訓。 根據與院方確定培訓場地、時間、方式等，本司可使用遠程示教培訓系統進行相關系統的直播培訓并進行過程錄制并系統留檔，可方便各科室使用系統人員隨時調閱學習，達到學習效率的**化。 |
項目啟動階段 |
系統初始化 | 把各種初始化數據導入到數據庫中，主要包括系統用到的配置信息，以及用于記錄數據的表，需要院方配合導入工作，給予一定的權限，或者我們提供數據庫腳本，由院方數據庫管理員進行導入。 |
需求獲取 | 如果院方在已實施的系統之外有自己的需求，可以提出，項目組負責收集需求，并進行整理。 |
需求確認 | 將整理好的需求發送給院方領導和公司領導，共同確認，并在《需求確認書》上簽字。 |
項目實施階段 |
系統試運行 | 軟件系統投入運行，進行全面綜合的測試。包括：測試硬件環境的穩定性，測試軟件系統的穩定性，測試網絡環境的穩定性，測試業務數據的準確性等。 |
需求提交 | 項目組將已確認的《需求確認書》提交給公司和院方領導留存。 |
需求實現 | 待需求確認后，項目組將對需求進行實現。 |
正式上線 | 系統進入正式使用期，院方需要安排人員及時收集問題并依照問題反饋流程提交上報。 |
工作跟蹤與處理 | 武漢飛博科技有限公司項目組全程跟蹤系統的運行情況，現場指導并解決問題。 |
驗收階段 |
結項 | 院方對本次實施培訓進行確認。 |
文檔歸檔 | 對實施期間的所有文檔整理和歸類。 |
后續工作安排 | 根據項目實施的實際情況，安排后續的工作事項。 |
第五章 售后服務體系
l 提供系統上線后12個月免費維護（質保服務）。
l 為醫院提供免費的云維保管理系統使用，可通過遠程視訊、遠程桌面等技術快速定位系統在售后過程中的問題快速解決，并且幫助醫院建立日常維護記錄制度和系統管理規范。
l 對于醫院的服務請求，公司在一個小時內給予明確的響應和安排，處理后給予明確說明。
l 對于軟件質量或性能與合同要求不符的部分，供方收到通知后在院方規定的時間內修改軟件，滿足醫院的要求。
l 如果將來醫院引進其他系統需與本方案系統進行對接的，本司可提供技術配合工作。
l 定期與醫院保持聯系，利用電話或專用表格指導醫院系統維護人員對服務器的運行狀態進行檢查，監控數據庫系統參數及性能，防止異常情況的出現。
五.1. 用戶回訪
本司會定期對醫院進行上門回訪，同時公司每個月對醫院進行至少2次的遠程回訪，幫助醫院技術人員解決問題，提出對系統進行日常的維護保養建議，**限度地降低故障發生的機率。
五.2. 電話支持
客戶服務中心人員7*24小時開通電話服務，全天候為醫院提供咨詢和即時服務。
五.3. 遠程支持
對于電話支持不能解決的問題，在醫院授權容許的情況下，通過云維保管理系統的遠程桌面技術，登錄到醫院的網絡中，協助醫院相關人員查看故障，實時解決問題。
五.4. 本地化服務
如果上述快速響應技術服務無法解決系統故障，則由本司立即安排專業技術人員攜帶必要的備件和工具根據實際行程以最快時間趕往現場，立即著手檢查系統和排除故障，恢復系統的正常運行。
五.5. 平臺化服務
可為醫院培養專業的運維平臺工具使用人員，解決系統日常運行中90%的糾錯性問題。
五.6. 售后運維人員培訓服務
線上培訓：當服務轉向至質保售后階段時，公司會不定期（根據售后安排通知）舉辦線上直播培訓課程對院方信息化專員進行遠程培訓，培訓內容錄制后上傳至系統網盤公開瀏覽。
長期培訓：當服務轉向至質保售后階段時，當院方需要進行新的信息化人才的培養時，可安排信息化專員上門來司進行數月的專項學習，以實現該人員能利用開發平臺對醫院系統細節進行不斷的優化，達到醫院系統完全適配自身管理模式、運轉效率最高的目的。
