我看了軍惠的電子病歷，就是用ole控件，總覺得有點落后。尤其不能實現結構化的查詢，規則等管理，其實還是采用拷貝方式，很容易出問題，如女性的疾病也同樣可以出現在男性的病歷中。
編輯器技術是電子病歷系統中的重點和難點，它是電子病歷系統的核心技術，它的功能是否強大直接關系到電子病歷系統的成敗。因為在病歷書寫過程中，既要支持醫學術語的結構化存儲，又要支持自由描述語言的書寫，同時還要支持圖文混排，表格操作等，現有的書寫工具很難完成上述要求。但是開發專用電子病歷編輯器難道非常大，目前國內有成熟并且已經大量商業應用電子病歷編輯器的公司據我所知只有2家，一家是北京華信慧典的病歷寶典2009（穆鵬義開發的），一家是北京嘉禾美康的EMRpad3.0（陳聯忠開發的），而且都是有6、7年的開發經歷了。這個兩家公司的技術水平都很高，產品也都很穩定，但個人認為華信慧典的病歷寶典在技術上更勝一籌，主要表現在他們的編輯器表格處理能力很強大（編輯器中最難的就是表格技術），而且結構化做的也很好。從電子病歷編輯器的復雜性來說，沒有3、4年的時間，不可能研發出可以商業應用的成熟產品。所以樓主可以跟這2家公司接觸一下，看能否得到他們的幫助。
B>重慶中聯電子病歷系統(ZLRichEPR :
基本介紹
【功能概述】
配合醫生工作站，ZLRichCPR主要完成如下功能：
實現各類門診/住院病歷文件書寫規范、格式和書寫審核要求的設置調整
各種病歷文件的全文示范、段落示范和詞句示范的編輯管理
病人就診過程各種病歷的書寫、審簽、歸檔管理與質量控制
對病人病歷的查閱、分析和利用
【注】豐富文本格式(Rich Text Format，簡稱RTF)：
是一種多格式文本信息的描述格式，將文本信息及其格式說明以文本的方式共同存放，以便于數據的傳輸，是一種通用的計算機文件格式，目前已被作為我國電子公文傳遞的標準格式之一采用。ZLRichCPR充分利用該格式，保證了電子病歷的格式和編輯的靈活性。
【功能特色】
可控制的豐富格式病歷文檔編輯：在電子病歷范疇中，現階段多數還是以文檔形式存在；伴隨不同醫療過程的病歷具有不同的內容要求和格式規定，不同地區和學科也存在差別。ZLRichCPR在提供豐富格式病歷的基礎上，實現病歷定義過程內容規范和格式上的靈活性，在編輯過程中的可控制性
真正結構化病歷，支持數據結構化輸入與控制：結構化始終是電子病歷發展不變的追求,實現電子病歷可利用性的前提,在豐富格式文檔中,包含了填空、選擇等內容結構化輸入控制,以及對表格化病歷的支持
增強的病歷質量管理功能：電子病歷伴隨病人診療過程由醫護人員按規定完成；在此過程中，對病歷的及時性、完成性和基本的正確性提醒控制，有利于病歷質量的提高，進而有利于醫療質量的提高
可分科定制病歷書寫規范
病歷全文模板元素模板功能a
導入歷史病歷功能
疾病診斷診療用藥參考管理
【功能概述】
配合醫生和護士工作站，利用計算機強大的存儲、檢索功能，將大量的診療措施及藥品的功能、特性、用法用量、注意事項等信息組織起來，提供診斷參考規范和診療措施應用參考規范的管理，包括常規知識參考和局部合理性檢測，供醫護人員查閱了解，并在實際診斷治療護理過程中隨時調閱或應用參考規范
【功能特色】
基于標準疾病編碼體系的疾病輔助診斷和治療措施參考功能
藥品用法參考功能
中藥方劑參考功能
診療措施用法參考功能
基于.NET平臺和Cache數據庫的結構化電子病歷系統設計
來源：中國論文下載中心 [ 08-11-17 15:32:00 ] 作者：江鳳蓮 鄧書顯 編輯：studa20
多智網校誠招全國各地市獨家線下代理商，共同開發網上教育市場。多智教育(DOZEDU.COM)！
【摘要】 電子病歷(CPR)系統是醫療信息化的重要部分,在國外有不少廣泛使用的系統，但不能通過漢化提高國內CPR水平，現基于.NET平臺和Cache數據庫提出一種結構化電子病歷系統方案，主要創新點包括平臺選擇、病歷模型結構、接口模型設計以及規則引擎的引入等。
【關鍵詞】 結構化電子病歷系統 病歷模型結構 接口模型 規則引擎
電子病歷(Computer-based Patient Record, CPR)是以病人為中心的信息集成，是醫院所有業務系統的有機融合，能完整、動態地反映患者的醫療過程，是對個人醫療信息及其相關處理過程綜合化的體現［1］。電子病歷又稱電子病人記錄（EMR），現正向電子健康記錄（EHR）發展。
《2007年中國醫衛行業信息化建設與IT應用趨勢研究報告》顯示，電子病歷、PACS、HIS系統的升級、完善和集成、信息安全等是2007年醫衛行業信息化建設的投資重點［2］。目前不能通過漢化國外CPR軟件提高國內CPR使用水平。首先，病歷的組織結構、描述方式中外有別，國外的CPR系統不能完全適應國內的病歷管理規范。其次，由于電子病歷相關立法以及監督機制等方面的差異，國外CPR系統的設計理念和國內不一樣。現國內的CPR要求將病歷打印出來進行手工簽名以起到法律效應。國外的CPR系統以表格或樹形結構的方式錄入數據，很難將計算機中的數據還原成“手工病歷”。
因此，我們在認真分析了國內外CPR系統的基礎上開發了基于.NET平合和Cache數據庫的結構化電子病歷系統。
1 系統體系結構
系統結構見圖1。
數據訪問層中對數據庫的操作分兩部分。訪問組件在微軟Enterprise Library中Data Access Application Block基礎上修改，增加了對ODBC數據源的支持(因為目前.NET平臺上還沒有支持Cache的驅程)，對Database抽象類功能進行擴充。圖2所示的數據訪問組件是以工廠模式［3］設計的，Database和DbCommandWrapper都是抽象類。客戶端代碼通過DatabaseFactory類創建Database實例。通過Cache提供的CacheObject訪問Cache多維數組。
因病歷輸入過程中使用大量代碼字典表數據，如診斷、癥狀、藥品目錄等。客戶端在輸入時都從數據庫中讀取，服務器負擔很重，可用數據緩存方式加以解決。
2 開發平臺選擇
因國內醫院普遍使用Windows操作系統，本系統基于Windows平臺以WinForm程序為主，采用.NET平臺進行開發。
數據庫選擇相對復雜。CPR系統中包括病歷數據和其它基礎數據。對于一般性數據可用關系型數據庫進行建模、存儲，而結構化處理后的病歷數據就不能滿足數據分析的需要。
病歷本身數據量很大，再加上結構化處理時增加的描述符，最終數據會增加很多。基于共享需要，病歷數據以XML格式保存［4］，對它處理要用XQuery、XPath等技術。雖然主流關系型數據，如SQL Server、Oracle、DB2等都支持XML數據，但要提高數據查詢效率，必須對數據添加索引。然而，病歷數據的結構是動態的，不能有效建立索引。因而，將動態結構的數據分解為固定格式的明細數據。
在關系型數據庫中，路徑表示數據在病歷結構中的位置。同步數據時借助路徑來定位，分析數據時通過路徑過濾。因為病歷數據分解為明細數據后數據量非常大，相應的路徑數量非常多，且查詢數據時因缺乏必要的索引信息需遍歷整個表。同時，值字段需要保存各種類型的數據，而字段類型只能是字符類型，在進行數據比較時要進行類型轉換，查詢的代價急劇上升。若能夠提高數據遍歷速度，并避免類型轉換，將大大提高效率［5］。而這恰恰是Cache數據庫的特點之一。
Cache數據庫的核心是高效的多維數據引擎。通過內置的CacheObjectScript腳本語言，可以直接訪問多維數據結構，這樣可以獲得最高的性能和最好的存儲利用率。當有特別的或者專業的結構并且不需要提供對象或者SQL的方法來訪問數據時，或者當要求盡可能高的性能時，直接的“global訪問”是特別普遍的。
3 插件式應用程序框架
本系統客戶端使用基于SmartClient技術的插件式應用程序框架，主要包括：①加載基本模塊:基礎框架類庫定義接口IPlugin、IStartup模塊程序實現接口，主程序通過PlugInHelper輔助類加載:②數據訪問:基礎框架類庫定義接口IDataAccess，并實現SqlDataAccess，主程序通過DataAccessFactory訪問數據庫;③浮動窗口:主程序支持浮動窗口顯示，基礎類庫定義DockingWindow,
DockingForm,DockingContent提供各模塊類創建浮動窗口，例如工具窗口、病人列表等，在加載模塊同時通過DockingHelper輔助類實現浮動窗口顯示，并動態保存浮動窗口位置、顯示方式，支持不同操作人員設置;④登錄部分:采用基于角色方式的帳戶管理，并加密處理，所有主程序加載的功能模塊，都基于這個帳戶的權限信息進行控制;⑤報表部分:提供統一的報表服務。
4 病歷模型結構圖
系統對病歷數據處理分為3個部分：
數據訪問部分負責處理和病歷有關的數據存儲操作。
ModelStorage組件負責處理數據庫中數據與病歷對象之間的轉換、實際數據與查詢數據之間的同步。
病歷業務負責病歷的內部邏輯。在EMRModel組件中完成病歷對象維護、檢查等工作。EMRWidget組件用來統一處理病歷的展現及錄入、病歷對象數據與RTF文本之間的轉換。
病歷界面包括病歷模板設置程序和病歷錄入組件。在病歷錄入組件中只負責和文字編輯有關的操作，數據的內部邏輯處理由EMRWidget組件完成。
病歷模型的實現比較復雜，主要內容如下。
EMRNode為基本元素，表示病歷內容，有三個繼承類:EMREntity,EMRNativeText, EMRPackage。EMREntity表示數據實體，病歷結構中最小輸入單位，也是數據分析基本單位，可以是多個數據項的組合。如 “身高”數據，應同時包含“身高的值”和“身高的單位”兩部分。EMRNativeText為原生文本，即以自然語言輸入的文本。
EMRPackage為病歷內容包，相當于文檔結構中的目錄，是個容器，可包含實體、原生文本或另一個包。
EMRDynamicMoleNode為嵌入式模板，即“主訴”、“現病史”這一層次內容，由EMREmbededMoleNode構成。
EMREmbededMoleNode為嵌入式對象，即“胸痛描述”、“頭部檢查”這一層次內容，由EMRObject構成。
EMRObject為元數據對象，即“發病時間”、“伴隨癥狀”這一層次的內容，它由EMREntity構成，是病歷結構中的最小顯示單位。
另為在模型中表示表格對象引入EMRTable、EMRRow、EMRCelI三個類，分別對應表、表中的行和行的單元格記錄。
5 數據接口模型
CPR系統是醫院信息系統的核心，HIS、LIS、RIS、PACS等系統都需要與其進行數據交換。在CPR的應用范圍提升以后，還會和其它系統進行數據交換。所以，CPR的數據接口定義非常重要。在醫療信息領域各種數據標準也非常多，其中影響最大、應用最廣的是HL7協議。
目前國內系統真正支持HL7協議的很少，系統投入使用前要么花大力氣改造與CPR聯網的系統，要么根據對方要求定制CPR系統數據接口，因此，我們設計了自己的接口模型。
在接口中傳輸數據請求可分為兩類:同步數據請求和讀取數據請求［6］。由于同步數據請求發出后不需立即得到結果，可將這類信息放入一個異步消息隊列，由專門的異步消息處理進程處理。而讀取數據的請求需要實時處理。
定義接口首先定義數據的傳輸格式、調用方式等。數據格式是中立格式，調用接口的系統與被接口調用的系統都要處理系統內部數據與接口數據之間的格式轉換。由于各系統使用技術不同，對于接口我們都通過WebService來發布。
接口分獨立消息處理服務程序、客戶端接口處理組件兩部分。
因接口數據傳輸涉及兩個系統，一要按通用技術標準設計接口屏蔽技術差異，二要提供接口處理程序處理意外情況，所以建立專門的消息處理服務程序。
接口組件處理接口數據與內部數據轉換及與消息服務程序間通訊。將接口組件放在客戶端一是減輕消息服務器的負擔提高并發性，二是降低程序實現的復雜度。
接口消息體格式參考HL7的消息格式如下:
編號發出系統接收系統〖〗消息類型應答標記請求編號數據體
編號是唯一序號，發出系統是發出消息的系統代號，接受系統是消息要送達的系統代號，消息類型是消息需要完成操作的代號，答標記標識此消息是否已被對方系統接收(保留字段)，請求編號是本消息要回復的消息的編號，數據體包含了消息處理時所需的接口數據。
6 規則引擎
在CPR數據邏輯處理中，需經常進行數據校驗、聯動處理，如以代碼形式固化在程序里，工作量大，且業務規則變復雜后很難維護。同時不同用戶業務有不同的規則需求，需不斷修改處理邏輯，增加系統維護工作量。因此，本系統通過規則引擎維護一個規則庫(通常以配置方式放入引擎)，運行時將一組對象作為事實庫交給規則引擎處理；規則引擎將對事實庫中的諸條事實與規則庫中諸規則的“事實”部分進行模式匹配，一旦某條規則指定事實存在，則執行該規則指定行為。
在需要處理業務規則時，規則引擎會執行所有能夠與事實庫中事實相匹配的規則。
如病案首頁中的住院次數、住院天數通常其標準的校驗規則如下:
IF住院次數<>數據庫中該病人病案首頁記錄數 THEN提示住院次數輸入錯誤IF住院天數<>(出院日期－入院日期)THEN提示住院天數輸入錯誤
但在部分醫院，這樣的規則就不適用了。如病人在使用計算機系統前住過院，但以前的數據并不在當前系統中。又如精神病醫院中與普通醫院不同，患者在得到允許的情況下可回家休息，所以在醫院的實際住院天數可能比出院日期和入院日期之間的差值小。在使用規則引擎方式處理后，只需在規則庫中添加或刪除規則即可。
7 結語
CPR系統的設計必須針對國情，便于管理及符合醫患的利益，我們提出的這個結構化電子病歷系統設計方案主要創新點在數據庫
|
|
資源大小：46.60 KB 
