本發(fā)明涉及醫(yī)療
技術領域:
,特別是指一種用于代謝病電子病歷表單的多頁控件。
背景技術:
:在內分泌科病房或其他與代謝病有密切關系的科室(如腎內科),由于患者病程較長,需要對某些指標進行定期監(jiān)控,如果每日都在病程記錄表單上增加一系列記錄,那么病程記錄將會延續(xù)相當長度,在電子病歷中占非常多的頁數,不利于歸檔與病歷閱讀。因此,需要開發(fā)一種控件,能夠將占用空間極大的代謝病相關病程記錄歸納并整合于一體,能夠將相關病程記錄整合于一體,方便相關記錄的歸檔與閱讀。技術實現要素:針對
背景技術:
中存在的問題,本發(fā)明的目的是提供一種用于代謝病電子病歷表單的多頁控件,集合錄入-存儲-調閱三項功能于一體,節(jié)省存儲空間的同時也方便相關記錄的歸檔與閱讀。本發(fā)明的技術方案是這樣實現的:一種用于代謝病電子病歷表單的多頁控件,包括控件表單設計單元、數據錄入與存儲單元和數據調閱單元,其中,控件表單設計單元:包含基礎屬性設計、interface接口設計、視圖設計以及wrapper適配;控件表單設計單元:用于設計控件表單,這樣生成的多頁控件在每一頁都有相同的模版,可以根據頁碼的不同進行內容的修改;數據存儲單元:包含初次存儲和頁碼擴展,初次存儲指的是當某份電子病歷表單初次寫入該多頁控件并進行存儲時,在對應的電子病歷表單關系型數據庫中,該病人的病歷檔案中單獨建立一個表格,數據經過序列化后存儲于該表格中,主鍵為頁碼;頁碼擴展指隨著病程記錄的增加,頁碼也隨之增加,每次增添新的病程記錄時,在原有表格的基礎上增加;數據調閱單元:在控件表單設計單元中已設定其defaultview為頁碼,從而將指針綁定為頁碼;當用戶需要調閱該控件中的數據時,閱讀器根據輸入的頁碼,使用視圖view對數據源進行篩選調閱。在上述技術方案中,所述基礎屬性設計包含frontcolor、backcolor基礎屬性的規(guī)定設計。在上述技術方案中,所述interface接口設計包括iemrcontrol接口、iparent接口與ichildren三項接口規(guī)范設計。在上述技術方案中,所述表格的構造為橫行對應頁碼,縱列對應該多頁控件所承載的子控件。在上述技術方案中,所述頁碼擴展時,在原有表格的基礎上增加一層數據,增加橫行數,將增加的內容序列化后記錄于具體的橫行中。在上述技術方案中,所述數據調閱時,數據指針指向輸入頁碼對應的橫行,調取出該行的數據,覆蓋在多頁控件之上;當輸入頁碼的橫行改變時,指針發(fā)生移動,指向新輸入的頁碼,從而調出該頁碼對應那一行的數據賦予該多頁控件。本發(fā)明用于代謝病電子病歷表單的多頁控件,包括控件表單設計單元、數據錄入與存儲單元和數據調閱單元,其中,控件表單設計單元包含基礎屬性設計、interface接口設計、視圖設計以及wrapper適配;控件表單設計單元用于設計控件表單,在每一頁都有相同的模版,可以根據頁碼的不同進行內容的修改;數據存儲單元包含初次存儲和頁碼擴展,存儲方式為在關系型數據庫中單獨設立對應表格;數據調閱單元的調閱方式為在數據源中根據選擇的頁碼作為指針使用view篩選數據源,如此,將錄入-存儲-調閱三項功能整合于同一個控件,達到節(jié)省存儲空間的同時也方便相關記錄的歸檔與閱讀。附圖說明圖1為本發(fā)明總體框架示意圖;圖2為本發(fā)明中控件屬性設計單元設計流程圖;圖3為本發(fā)明中數據存儲單元儲流程圖。具體實施方式下面將結合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅是本發(fā)明一部分實施例,而不是全部的實施例?;诒景l(fā)明中的實施例,本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。本發(fā)明所述的一種用于代謝病電子病歷表單的多頁控件,具備iemrcontrol接口、iparent接口與ichildren三項接口規(guī)范,存儲方式為在關系型數據庫中單獨設立對應表格,而調閱方式為在數據源中根據選擇的頁碼作為指針使用view篩選數據源,從而將錄入-存儲-調閱三項功能整合于同一個控件。具體的包括控件屬性設計單元、控件表單設計單元、數據錄入與存儲單元和數據調閱單元,總體框架如圖1所示,以下是對上述各單元的詳細說明:(1)控件屬性設計單元:控件屬性設計單元,針對于控件開發(fā)與適配,對控件的各種屬性做出規(guī)定并適配于電子病歷表單設計器??丶傩栽O計主要包括下述幾項內容:基礎屬性設計、interface接口設計、視圖設計以及wrapper適配。其中,流程如圖2所示。a.基礎屬性設計:多頁控件具備與其他控件相似的frontcolor、backcolor等基礎屬性,需要在控件屬性設計階段對其做出規(guī)定。b.interface接口設計:應用于電子病歷表單設計器中需要對控件做出接口的規(guī)定,對于多頁控件,需要進行三項接口的規(guī)定,包括iemrcontrol接口、iparent接口與ichildren三項接口規(guī)范,iemrcontrol接口使其能夠應用于電子病歷表單設計器,iparent接口使其能夠作為父控件承載其他控件從而作為控件表單設計的基礎,而ichildren使得其能作為子控件被其他父控件所承載。c.視圖設計:該多頁控件的數據存儲于關系型數據庫中,調閱數據時采用視圖調閱,因此設計該多頁控件時需要設定defaultview,在此設定為頁碼。d.wrapper適配:完成幾項控件屬性與接口規(guī)定之后,需要將其經過wrapper控件適配器,在電子病歷表單設計器中的動態(tài)鏈接庫文件中進行注冊,進行各項屬性的適配后能夠用于電子病歷表單設計器。(2)控件表單設計單元:經過控件屬性設計單元設計后,該多頁控件能夠應用于電子病歷表單設計器中。在開發(fā)具體某個科室的代謝病病程記錄表單時,在電子病歷表單設計器的設計模塊中,調用這一控件,并在這一控件的基礎上。根據代謝病具體記錄需要調用其他控件,作為該多頁控件的子控件,這樣生成的多頁控件在每一頁都有相同的模版,可以根據頁碼的不同進行內容的修改。(3)數據存儲單元:該控件的數據存儲分為兩種模式,分別為初次存儲與擴展存儲。a.初次存儲:初次存儲指的是當某份電子病歷表單初次寫入該多頁控件并進行存儲,存儲時該多頁控件在對應的電子病歷表單數據庫中該病人的病歷檔案中單獨建立一個表格,數據存儲于關系型數據庫中,主鍵為頁碼,該表格的構造為橫行對應頁碼,縱列對應該多頁控件所承載的子控件,數據經過序列化后存儲于該表格中。該表格的結構如下表所示b.頁碼擴展:隨著病程記錄的增加,頁碼也隨之增加。每次增添新的病程記錄時,并不創(chuàng)建新的表格,而是在原有表格的基礎上,增加一層數據,也即增加橫行數,將增加的內容序列化后記錄于具體的橫行中。需要注意的是,對應于不同多頁控件的存儲數據表格,其縱列都是不同的,因控件表單設計時所放入的子控件而異。當進行初次存儲時,將該多頁控件中的各個子控件逐個建立縱列,以便與存儲不同頁中該控件所存儲的不同數據。其中,流程如圖3所示。(4)數據調閱單元:該多頁控件數據調閱功能的實現基于一個核心思想:當該控件調閱數據時,并不改變控件本身空間屬性,而是改變其所承載的數據??丶旧碇蛔鳛槿萜?,能夠被賦予來自不同數據源的數據。多頁控件的數據調閱通過視圖view實現,在控件表單設計單元已設定其defaultview為頁碼,從而將指針綁定為頁碼。當用戶需要調閱該控件中的數據時,閱讀器根據輸入的頁碼,使用視圖view對數據源進行篩選,數據指針指向輸入頁碼對應的橫行,調取出該行的數據,覆蓋在多頁控件之上。當輸入頁碼的橫行改變時,指針發(fā)生移動,指向新輸入的頁碼,從而調出該頁碼對應那一行的數據,從而賦予該多頁控件。以下是結合一具體實例進行的進一步說明:經過控件表單設計之后,用于糖尿病病程記錄,該多頁控件中包含血糖值、尿糖檢測、糖尿病病程記錄等。在某病人的病程記錄中,在初次錄入時,首頁記錄的血糖值為11.4mmol/l,尿糖呈陽性,病程記錄略。則存儲時先在數據庫中建立對應的存儲表格,將各個控件作為縱列,頁碼作為橫行,初次記錄存儲的數據結構如下表所示:pagetextbox1_bloodradiobutton1radiobutton2richbox111.4truefalse第二天錄入的數據為8.9mmol/l,尿糖呈陰性,病程記錄略,則進行頁碼擴展,在數據層數加一,將數據存儲于其中,如下表所示:pagetextbox1_bloodradiobutton1radiobutton2richbox111.4truefalse28.9falsetrue調閱數據時,數據指針指向目標頁碼值,讀取該層的數據,覆蓋于多頁控件上。綜上:本發(fā)明用于代謝病電子病歷表單的多頁控件,具有以下有益效果:1.由于代謝病病程記錄較長,所需要監(jiān)控的指標較多,如果將代謝病病程記錄堆積于病程記錄表單中,將會占用相當多的空間,同時也不利于用戶對代謝病以外其他疾病病程記錄的閱讀。而本發(fā)明能夠將代謝病病程記錄與指標監(jiān)控整合于一個控件當中,在數據庫中單獨建立表格針對不同子控件進行結構化的存儲,而不需要每出現一個新的控件就記錄該控件的屬性與數據,一定程度上節(jié)省存儲空間。2.在腎內科等科室,代謝病只是疾病診療的其中一個方面,除代謝病之外還需要治療主要疾病。如果將代謝病病程記錄堆積于病程記錄中,將不利于主要疾病病程記錄的閱讀。采用本發(fā)明后,能夠將代謝病病程記錄集中于一個控件當中,極大地方便了代謝病病程記錄的整理與歸檔,同時也有利于不同時期代謝病病程記錄與指標監(jiān)控的對比。(3)在控件設計環(huán)節(jié)中,該多頁控件既能作為父控件又能作為子控件,能夠承載其他控件,而代謝病的病程記錄常常需要對特定指標進行定期監(jiān)控,如血糖、是否服藥等等,而且不同代謝病所需要記錄的內容也不相同。而本發(fā)明能根據具體代謝病病程記錄的實際需求,在多頁控件中添加符合病程記錄需要的控件,從而開發(fā)出具有針對性的代謝病病程記錄控件,極具靈活性。以上所述僅為本發(fā)明的較佳實施例而已,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內,所作的任何修改、等同替換、改進等,均應包含在本發(fā)明的保護范圍之內。當前第1頁12