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