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