電子病歷(Electronic Medical Record，EMR)系統(tǒng)是一個數(shù)字技術(shù)、計算機技術(shù)、通訊技術(shù)、軟件工程、圖形圖像綜合技術(shù)等多學(xué)科的高新科技項目。其完整資料、數(shù)據(jù)處理、網(wǎng)絡(luò)傳輸、診療支援、統(tǒng)計分析等均是紙質(zhì)病歷無法比擬的。
體溫是電子病歷系統(tǒng)中一個重要的數(shù)據(jù)，比如某病人體溫升高可以讓臨床醫(yī)生知道該病人有發(fā)熱的癥狀。在電子病歷系統(tǒng)中，體溫單所針對的用戶是醫(yī)院的護士。護士每天記錄病人的體溫等各項信息，錄入到數(shù)據(jù)庫中，系統(tǒng)自動生成電子體溫單，并繪制成曲線圖。體溫曲線圖直觀地顯示了病人的體溫等相關(guān)數(shù)據(jù)，這些數(shù)據(jù)與有關(guān)疾病和治療的知識相結(jié)合，可作為進一步診斷及確定治療方案的基礎(chǔ)。
筆者參與開發(fā)的電子病歷系統(tǒng)根據(jù)某大型醫(yī)院的實際需求，在.NET平臺下全程采用C#語言開發(fā)實現(xiàn)。本文著重介紹電子病歷系統(tǒng)中體溫曲線圖的設(shè)計和實現(xiàn)。
1 電子病歷系統(tǒng)主要功能
本系統(tǒng)根據(jù)醫(yī)院的實際需求，最主要的目的是采集病人的數(shù)據(jù)，使之能為臨床醫(yī)生提供所需要的診斷和決策信息，更進一步的目的是這些信息能夠用于臨床科研。系統(tǒng)主要功能如圖1所示。
2 體溫曲線圖的設(shè)計與實現(xiàn)
2.1 體溫表的生成
在電子病歷系統(tǒng)中，每個來院就診的病患在醫(yī)院就診期間會產(chǎn)生一個病歷號，這是標志病人的確定碼，通常在數(shù)據(jù)庫系統(tǒng)中也作為惟一的對應(yīng)碼和關(guān)鍵字。病人人院后，護士對病人進行體溫、脈搏、呼吸等各個方面的檢測，將這些數(shù)據(jù)錄入到電子病歷系統(tǒng)中，系統(tǒng)則自動生成體溫單。
在病人的體溫單中，需要記錄并分析病人的體溫變換情況。體溫單信息的“體溫”、“脈搏”、“呼吸”這三項信息是要每隔4個小時記錄1次，分別在4時、8時、12時、16時、20時、24時這幾個時間段。而“大便次數(shù)”、“小便次數(shù)或量”、“攝人量”、“排出量”、“血壓”、“體重”等信息是1天記錄1次。根據(jù)體溫單信息，以1天為1個單位，畫出1天內(nèi)病人在各個時間段的“體溫”、“脈搏”、“呼吸”的曲線變化情況，以及記錄的“大便次數(shù)”、“小便次數(shù)或量”、“攝入量”、“排出量”、“血壓”、“體重”等信息。整個體溫圖1次只顯示7天的情況。在體溫圖中用坐標以及曲線描述病人體溫的連續(xù)變化情況，直觀地滿足了護士對患者的體溫、呼吸、脈搏等信息的錄入和查詢的需要。圖2是體溫單顯示界面。
2.2 體溫圖的繪制
體溫圖是根據(jù)體溫單的數(shù)據(jù)自動生成的。由于體溫圖每次只顯示病人7天的體溫變化情況，所以設(shè)計了翻頁的功能，對住院時間久的病人通過翻頁每次跳過7天，保證病人的體溫信息完整的顯示。
2.2.1 C#的GDI+繪圖
體溫圖的繪制由.NET基類集組成的GDI+實現(xiàn)，這些基類可用于在屏幕上完成定制繪圖，能把合適的指令發(fā)送到圖形設(shè)備的驅(qū)動程序上，確保在顯示器屏幕上顯示正確的輸出。
在GDI中，識別輸出設(shè)備的方式是使用對象設(shè)備環(huán)境(DC)。該對象存儲特定設(shè)備的信息，并能把GDI API函數(shù)調(diào)用轉(zhuǎn)換為要發(fā)送給該設(shè)備的指令。實現(xiàn)畫圖的功能要使用到GDI+畫圖技術(shù)。通過重寫Form類中的OnPaint(PaintEventArgs e)執(zhí)行畫圖操作。
在OnPaint()中，首先從PaintEventArgs中引用Graphics對象，繪制圖形。最后調(diào)用基類的OnPaint()方法。
在應(yīng)用程序第一次啟動，窗口第一次顯示出來時，也調(diào)用了OnPaint()，所以不需要在構(gòu)造函數(shù)中復(fù)制繪圖代碼。
由于整個體溫圖比較大，而顯示窗口定為800×600，為了能完整顯示體溫圖文檔，需要在文檔超出窗口時，通知窗口在右側(cè)出現(xiàn)滾動條。為此，把整個文檔區(qū)域定為(800，1 886)像素，并在窗體設(shè)計器的屬性中把AutoScroll屬性設(shè)置為True。這樣，在體溫圖超過窗口時自動出現(xiàn)滾動條。
2.2.2 絕對坐標到相對坐標的變換
在一般的繪圖代碼中，由于所繪制的圖形區(qū)域一般不超過窗口的大小，所以不需要特別的注意。Graphics實例在默認情況下把坐標解釋為是相對于窗口的，它并不知道滾動條的情況。當(dāng)用戶滑動滾動條時，Windows沒有要求應(yīng)用程序重新繪制已經(jīng)顯示在屏幕中的內(nèi)容。Windows只指出屏幕上目前顯示的內(nèi)容可以平滑的移動，以匹配滾動條的位置。對于多出來的文檔部分，在應(yīng)用程序第一次顯示時，沒有繪制這部分窗口，因為在滾動窗口前，這部分在窗口區(qū)域的外部。這表示W(wǎng)indows要求ScrollShapes應(yīng)用程序繪制這個區(qū)域。它將引發(fā)Paint事件，把這個區(qū)域作為剪切的矩形，在窗口中和原來的圖形一起顯示出來，這樣會出現(xiàn)一個窗口中有多個圖形重疊，造成圖形的混亂。
解決的方法是把Graphics實例默認的坐標表示為相對坐標，即坐標是相對于窗口的左上角，而不是文檔開頭的左上角，把絕對坐標轉(zhuǎn)換為相對坐標。這里用圖3說明這一轉(zhuǎn)換。
實線矩形標記了屏幕區(qū)域的邊框和整個文檔的邊框。虛線矩形標記了試圖要繪制的矩形和橢圓。P標記要繪制的某個隨意點。在調(diào)用繪圖方法時，提供Graphics實例和從A點到P點的矢量，整個矢量表示為一個Ponit實例。而實際上需要的是從點B到點P的矢量。問題是，這里只知道從A點到P點的矢量，這是P相對于文檔左上角的坐標，而要在文檔的P點繪圖。另外還知道從A點到B點的矢量，這是滾動的距離，它儲存在Form類的一個屬性AutoScrollPosition中。要知道從B點到P點的矢量只需要進行矢量相減即可。Graphics類的TranslateTransform方法可以進行這些矢量的計算。這里給它傳送水平和垂直坐標，表示窗口驅(qū)譴、與的左上角相對于文檔的左上角的矢量(AutoScrollPosition屬性，它是圖中從A到B的矢量)，然后Graphics設(shè)備考慮窗口區(qū)域相對于文檔區(qū)域的位置，處理這些坐標。只要在繪圖代碼中加入以下語句：g.TranslateTransform(this.AutoScrollPositiort.X，this.AutoScrollPosition.Y)；即可解決坐標轉(zhuǎn)換的問題。
2.2.3 體溫圖的繪制技術(shù)
體溫圖的繪制根據(jù)體溫單中病人的相關(guān)信息，利用才C#的GDI+可以繪制出相應(yīng)的體溫曲線圖。在程序中首先進行絕對坐標和相對坐標的變換，然后用Pen類定義畫筆，用Brush類定義畫刷顏色，對于需要填充的地方用畫刷進行填充，再調(diào)用Graphics類的DrawLine方法畫出所需的線條。在DrawLine方法中，需要提供畫筆類型，線段起點和終點坐標等參數(shù)。
體溫圖初始化之后，根據(jù)從體溫表傳遞的病人編號作為體溫圖中的全局變量，對數(shù)據(jù)庫進行查詢，并把查詢結(jié)果轉(zhuǎn)換為坐標，傳遞給畫圖方法DrawLine和FillEllipse，畫出圖形。圖4是一張體溫圖顯示界面。
2.2.4 體溫圖中翻頁的實現(xiàn)
由于體溫圖每次只顯示病人1周的體溫變換信息，要顯示1周之前的體溫信息，可以使用翻頁功能。實現(xiàn)翻頁功能主要利用在讀取數(shù)據(jù)時使用到的Read()方法的特性。通過Read()方法在讀取數(shù)據(jù)的同時把當(dāng)前的指針向下移動1位。最初它位于數(shù)據(jù)集的第一行之前，因此第一次調(diào)用Read()將把指針置于第一行上，使它成為當(dāng)前行。隨著每次調(diào)用Read()導(dǎo)致指針向下移動，按照從上至下的次序獲取數(shù)據(jù)集行。代碼如下：
其中變量n為全局變量，由翻頁按鈕對其進行賦值。以當(dāng)前的變量n減1乘7為所需跳過的間隔數(shù)，以日期為單位，對數(shù)據(jù)集中的日期進行篩選，選出這一周的日期儲存到數(shù)組array中。
3 結(jié) 語
電子病歷是醫(yī)院信息化發(fā)展的必然趨勢。根據(jù)HL7的標準化要求，當(dāng)前國內(nèi)電子病歷的研究還很不完善，要制定出比較完善的適應(yīng)國內(nèi)醫(yī)院使用的電子病歷原型系統(tǒng)還需要更深入的研究。本文探討利用C#繪制電子病歷系統(tǒng)體溫圖的技術(shù)，試圖對完善電子病歷系統(tǒng)做有益的嘗試。電子病歷系統(tǒng)相關(guān)的研究內(nèi)容將會不斷發(fā)展和深入，而電子病歷的技術(shù)構(gòu)架和軟件流程也將會越來越成熟。