**章 總章
一.1. 項目背景
隨著經濟與科學技術的高速發展,信息化的進程不斷加快。我國還有部分醫院的信息處理停留在手工方式,勞動強度大且工作效率低,醫師護士和管理人員的大量時間都消耗在事務性工作上,病人排隊等候時間長,輾轉過程多,影響了醫療的秩序。計算機化的醫院信息系統已成為現代化醫院運營必不可少的基礎設施與技術支撐環境。門診掛號系統是整個醫院管理信息系統的**個窗口,是病人到醫院就診要做的**項工作。它用于收集病人的信息,協調科室醫生管理,控制各科室的流量等等。網上預約以及電話預約掛號系統是一種基于移動互聯網及MIS電話的新型掛號系統,是衛生信息化建設的最基礎項目之一。
一.2. 預約掛號解決的問題
1. 通過預約掛號系統,用戶就可以在網上預約醫院的專家而無須再受排隊之苦。
2. 通過網上及電話預約掛號系統更好的改善就醫環境,簡化就醫環節,節約就醫時間,真正體現了以病人為中心,一切從方便患者出發,符合當今醫院人性化溫馨服務的理念。
3. 通過網上及電話預約掛號系統解決門診一直是困擾醫院提高服務質量的。
4. 一個復雜環節,特別是醫療水平高、門診量大的醫院,而造成門診質量難以提高的因素主要有兩方面:一是集中式掛號(現在流行的分層掛號只是相對而言一個范圍較小的集中式掛號),就診人員流量不均、具有不確定性,有明顯的就診高峰和低谷(表現在整個醫院不同門診時間段及同科室的不同時間段)。
5. 通過網上及電話預約掛號的方式解決高峰期病人掛號排隊長,就診時間長,醫生熟人插號現象,環境擁擠混亂,醫生問診時間短、不仔細、態度差。而低谷期,醫生無病人看、溜號,醫院資源浪費。
6. 通過網上及電話預約掛號解決專家號(特別是外院專家號)難掛,出現倒號、炒號現象,嚴重損害病人利益,影響到醫院的聲譽。
7. 最終通過網上及電話預約掛號,可有效的解決這一現象,還通過有效的身份驗證,杜絕倒、炒專家號的現象,提高醫院門診服務質量,取得良好的社會效益和經濟效益。此外,病人到醫院就診前對醫院的相關信息了解不多,對所要掛的??漆t生的情況又不太了解,只能憑經驗和印象進行選擇,具有較大的盲目性。而當醫院開通網上掛號預約服務以后,求醫者只需坐在家中,輕點兒下鼠標,就可以掛上醫院專家門診號,可以做到“足不出戶選醫生”。網上預約正悄然改變著都市求醫者的看病觀念。擁有相對固定的個人醫生和習慣。預約看病,將不再遙遠,所以應用必將越來越廣泛。
第二章 總體結構設計
二.1. 設計原則
1) 先進性、成熟性
采用CTI領域的****,保證系統在建成后一段時間內不會因技術落后而大規模調整,并能夠通過升級保持系統的先進性,延長其生命周期,同時又要保證先進的技術是穩定的、成熟的,支持現有的多種呼叫功能和網絡協議,滿足系統建成后3年服務業務的發展需要。 l
2) 強大的可開發性
系統配置通用的開發接口和豐富的開發工具,采用可視化流程定制等工具滿足用戶的業務發展需求。
3) 可靠性:
整個系統具備較強的可靠性,系統設計要求能夠穩定、可靠、連貫地運行,確保系統建設獲得**的應用效果。
4) 可維護性:
易于管理和維護:系統維護應盡量集中、簡單,盡量避免復雜系統和多系統組合的維護開銷,減輕維護人員的負擔,提高網管和決策的效率。
二.2. 預約方式
二.2.1. 電話預約
可直接預約掛號。例如患者張XX需要在4月30日上午8:30預約XXX醫院心血管科的xx醫生,張XX在自助服務電子顯示屏上上查詢到該醫生的工號為00868,則正確格式為:“GHDH00868,07150830,張XX”。實現移動手機電話預約掛號流程。
二.2.2. 網上預約
(1) 點開醫院網站首頁,注冊會員,登陸。
(2) 選擇科室:在選中的醫院后,您可根據需要就診的疾病選擇點擊相應的科室,即打開該科室醫生出診時間安排表。
(3) 選擇醫生:您可根據醫生信息、出診時間、自己的時間安排,選定最適合自己的醫生,點擊醫生出診時間,進行掛號;
(4) 填寫預約信息:您按照要求填寫好各項信息并確認無誤后點提交,完成本次網上掛號的操作;
(5) 掛號預約成功確認:當您預約成功后,可點擊掛號管理,確認您的網上掛號預約是否成功;
(6) 去醫院就診:就診人攜帶相關證件,到醫院導診臺或就診科室說明您是預約掛號即可。
二.2.3. 短信預約
隨著科技的不斷發展進步,短信的使用以及深入到人們生活的各個層面,使用短信進行掛號是人們對醫院服務的一個基本需求。
同時對于提升醫院的服務質量,提供醫院的形象有著很重要的作用。
(1) 手機注冊
系統提供手機用戶的注冊功能,系統根據提示輸入身份證號碼后,系統會會送客戶的用戶帳號。以后用戶就可以使用這一憑據進行短信預約掛號。
(2) 短信預約掛號
患者可以使用手機短信發送申請的帳號到短信預約特服號碼,根據短信的提示,按照步驟,就可以選擇預約日期、時間、科室以及當班醫生進行掛號,成功后系統會直接將成功短信息發送到患者的手機上。
(3) 短信查詢
患者可以通過手機短信進行值班醫生,科室等情況進行查詢。
(4) 短信變更通知
當預約信息發生變更時,可以短信通知患者,做相應的準備。
第三章 平臺功能設計
三.1. 預約信息查詢:
預約掛號可以應用戶要求,對醫生預約信息進行查詢。查詢分為以下四種模式:按照專家姓名代碼查詢、按照科室進行查詢、按照醫生專長進行模糊查詢、按照出診時間進行查詢;
三.2. 預約信息提交:
用戶查詢到要預約的專家號后,12580應用戶要求進行預約;預約成功后,系統會發送預約成功的通知短信到用戶手機上,完成整個預約提交過程;
三.3. 預約信息取消:
用戶預約成功后,12580平臺不提供用戶發起的預約取消功能,即預約成功后不能因用戶方原因進行預約取消。如果因醫院緊急取消大夫出診等非客戶發起預約取消的原因,執行預約主動取消流程;
三.4. 預約記錄查詢:
客服人員可以根據以下兩種方式查詢預約記錄:按呼入12580系統的手機號和按用戶證件號碼查詢,幫助用戶查詢本人預約的情況;
三.5. 日志和信息查詢:
系統提供保留1年的預約日志和操作錯誤日志,并提供基于web的日志統計功能,包括業務量報表、業務類別統計報表、員工工作量報表;
三.6. 黑名單信息同步:
被列入黑名單的表項不允許進行預約。移動公司采用醫院方提供的黑名單對用戶身份信息進行限定。人工代客掛號系統本身不保存黑名單信息,而是同步醫院方提供的黑名單數據到本地。
三.7. 系統后臺主要功能
? 具有后臺掛號值班人員可操作的所有權限
? 專家管理功能:對專家進行添加與刪除,修改專家檔案;安排和查看專家的值班情況(即生成醫生排班表),查看和修改每個專家的預約情況。
? 用戶管理功能:修改和刪除用戶資料,顯示用戶的預約信息
? 預約掛號管理功能:可以分別按用戶名、專家名、預約號、科室、預約日期、就診日期等字段進行查詢管理,取消已過期的預約掛號信息。
? 系統管理功能:對管理員及掛號值班操作人員進行添加與刪除,修改其信息。
? 統計功能:能完成任意時間段的診別、類別、科別(并可統計到醫生)工作量統計、掛號收費(診療費、掛號費)統計;能完成掛號員、掛號室工作量及診療費、掛號費、病歷本費統計日報、月報(及任意時間段)。能即時完成會計科目、收費項目和科室匯總等日報、月報表。能統計退號退費一覽表等。
三.8. 與HIS掛號數據對接
完成平臺與醫院HIS系統得掛號、收費、排班、門診醫生等系統的實時數據交換接口,平臺要實時取得醫院的掛號信息、門診醫生排班信息;醫院HIS系統的掛號、收費、門診醫生要實時取得平臺的預約掛號、收費信息。
平臺需要反饋給HIS的預約掛號數據,包括:
(1) 成功預約的號子和時間段;內容包含科室、醫生和掛號費。
(2) 未被預約的號子和時間段;內容包含科室、醫生和掛號費。
三.9. 特殊情況處理
l 如醫生停診,平臺將以短信方式通知,可憑預約服務號和個人身份以及停診通知短信到醫院退回掛號費。(在就診前一天可在預約平臺上提供轉號功能,也可申請退號,就診當天只能申請退號)
l 如需退號,需要在預約平臺上進行退號操作,可憑預約服務號和個人身份證以及退號短信到醫院退回掛號費,退號截止時間在就診當天上午或下午。
l 預約掛號的前提條件:需要選擇預約的醫生、預約的時間段。
l 可以通過過濾條件:醫院、科室、醫生,來選擇醫生和時間段。
l 可以通過過濾條件:科室、日期范圍,來選擇醫生和時間段。
l 提供成功掛號清單,以及支付的費用。
l 要求醫院在預約掛號病人到院內去確認時將病人掛號信息,與醫院his系統內病人基本信息作對比。
三.10. 投訴舉報管理
患者可采用電話錄音留言、人工或Email方式對醫院、醫護人員的服務態度、服務質量等進行投訴舉報和批評建議。對已受理的投訴舉報或批評建議,系統自動生成**標識的受理流水號?;颊邞{此流水號,可隨時打電話進入系統了解處理情況。對已受理的投訴舉報或批評建議,由職能部門整理后,根據職責分工轉對口部門處理。對本級部門無法處理的舉報,可采用自動或手工方式移交上級部門處理。系統可通過電話語音、手機短信、Email等方式將處理結果及時反饋給患者。
第四章 公司技術優勢
四.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、內存、負載均衡各項指標,支持設置閾值,當關鍵指標任務發生錯誤或服務器性能異常發送郵件及短信提醒。