前言：本站為你精心整理了DICOM標準圖像數(shù)據(jù)庫范文，希望能為你的創(chuàng)作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

1dicom數(shù)據(jù)模型

在DICOM標準中,定義了一個以患者,研究(Study),序列(Series)、圖像四個層次的信息模型。這四個層次分別對應了有關類型信息的生成階段和不同來源。

(1)患者層次

患者層次包含了屬于某個研究的患者標識和人口統(tǒng)計信息。由于一個患者可能存在多個研究,患者層次是信息系統(tǒng)模型中的最高層次,一個患者可能由于其它或以前的檢查而有多個研究。然而在DICOM標準中,患者信息卻被包含在研究模塊中。

(2)研究層次

研究層次是在信息模型中最重要的層次。一個研究是某個特定類型檢查請求的結(jié)果。放射科的所有活動都是圍繞著正確處理患者的研究請求而進行的。在研究層次上,保存著患者的標識信息,并包含有與同一個研究有關的醫(yī)院管理信息系統(tǒng)中的其它參考信息。一般地,一個研究的請求可能會涉及不同模式(Modality)的檢查過程,因而涉及一個或多個圖像的序列,這取決于檢查所定義的協(xié)議。研究作為DICOM的信息根將所有圖像數(shù)據(jù)收集到一起。在研究層次下收集了所有的圖像序列。

(3)序列層次

序列層次標識了生成圖像的模式類型、序列生成的日期、檢查類型的細節(jié)和使用的設備等信息,是來自單一模式有關圖像的集合。圖像組合到序列中的方式取決于它們的臨床用途。而圖像在模式上是如何獲取的對序列的分組并不重要。但是不同的屬性將獲取標識并在顯示圖像時表現(xiàn)出來。在許多情況下,圖像關系是通過獲取發(fā)生的方式定義的。當按順序的獲取具有空間或普通的關系時,這種獲取結(jié)果的圖像可以成組到一個序列中。當存在于圖像之間的關系不再有效時,必須開始新序列。

(4)圖像層次

信息模型的最低層次是圖像層次,每個圖像包含獲取位置以及圖像數(shù)據(jù)本身,取決于模式的類型。圖像層次包含有一幅(單幅)、兩幅(雙屏)和在相對短的時間內(nèi)收集的多幅圖像(多幀圖像)。多幀圖像的使用節(jié)約了高層次上信息的重復,但這僅僅是在幀之間關系可以用簡單方法描述時才有可能,例如時間間隔或系統(tǒng)移動的增量在所有幀之間都是相等的。DICOM模型考慮了在醫(yī)院環(huán)境下所涉及到圖像的絕大部分信息,對于系統(tǒng)設計有很好的參考作用。必須說明的是在信息模型中,不是所有內(nèi)容都是必須的。DICOM標準在第三部分詳細定義了各種信息對象的模塊組成和模塊中的屬性,允許根據(jù)設備的類型、應用系統(tǒng)的需求等具體情況有條件地取舍,但必須在兼容性聲明中加以說明。正是由于DICOM標準中允許屬性是可選的,這種不確定性給數(shù)據(jù)庫的結(jié)構(gòu)定義帶來困難。

2數(shù)據(jù)的表示和關系表的設計

在DICOM標準中,所有的數(shù)據(jù)(即模塊中的屬性)都是以數(shù)據(jù)元素的形式出現(xiàn)的。一個數(shù)據(jù)元素是由標記(Tag),值表示法(ValueRepresentation,VR),值長度(ValueLength,VLen)和值(Value)四個部分組成。標記用一對16位無符號整數(shù)組成,分別稱為組號和元素號。標記的值的指定和語義說明在數(shù)據(jù)字典中定義。值表示法是用兩個字符組成,規(guī)定了該數(shù)據(jù)元素值的表示格式,如AS表示年齡字符串,DT是日期和時間,FD表示雙精度浮點數(shù)等。值長度用16位或32位整數(shù)表示,值域則實際存放具體內(nèi)容。上述的信息模型并不能直接轉(zhuǎn)換到關系數(shù)據(jù)庫中,這是因為①DICOM標準中數(shù)據(jù)是以數(shù)據(jù)元素的格式進行交換和存放在可移動介質(zhì)上的,即有(TAG,VR,VLen,V)的結(jié)構(gòu)的要求,這與關系數(shù)據(jù)庫中的原子屬性不一致;②對于同一個屬性存在著對應多個值表示法,

這使得在數(shù)據(jù)庫定義的數(shù)據(jù)類型上無法直接定義;③對于同一個屬性存在多個TAG,也要求存在有一種對應的映射。由于上述原因,在關系數(shù)據(jù)庫的實現(xiàn)中,必須保存完整的數(shù)據(jù)元素結(jié)構(gòu)以及內(nèi)容,這樣既解決了數(shù)據(jù)元素結(jié)構(gòu)上的要求,也解決了由于屬性可選而帶來的數(shù)據(jù)稀疏問題。在我們的設計中,無論是研究,序列圖像還是患者模塊,其實現(xiàn)的關系表結(jié)構(gòu)都是一樣,即以(UID,TAG,VR,VLen,V)多元組表示。各模塊之間以唯一標識符(UniqueIDentifier,UID)作為關鍵字聯(lián)接。根據(jù)標準要求,主要設立下面幾個表:(1)患者表PatientTable=(PatientID,TagGroup,TagElement,VR,VLen,ValueContent):存放描述患者的靜態(tài)信息的數(shù)據(jù)元素,對于每個患者指定一個ID作為索引的鍵值。(2)研究表StudyTable=(StudyUID,TagGroup,TagElement,VR,VLen,ValueContent):存放所有研究模塊的數(shù)據(jù)元素,以及患者的動態(tài)信息。(3)序列表SeriesTable=(SeriesUID,TagGroup,TagElement,VR,VLen,ValueContent):存放所有序列模塊的數(shù)據(jù)元素,以及設備信息和參考幀信息。(4)圖像表ImageTable=(ImageUID,TagGroup,TagElement,VR,VLen,ValueContent):存放所有描述圖像屬性的數(shù)據(jù)元素。(5)數(shù)據(jù)表DataTable=(DataUID,TagGroup,TagElement,VR,VLen,ValueContent):存放所有圖像的象素等類型的數(shù)據(jù)。(6)訪問表VisitTable=(VisitUID,TagGroup,TagElement,VR,VLen,ValueContent):存放所有訪問模塊的數(shù)據(jù)元素。(7)患者聯(lián)接表PatientLinkTable=(PatientID,VisitUID,StudyUID,SeriesUID,ImageUID):存放所有患者與其研究、序列、圖像以及訪問之間聯(lián)接的信息,這是一個有信息冗余的表,但可以提高數(shù)據(jù)操作的效率。除此以外,還有一些與管理類、服務類有關的表,這里就不再贅述。

3患者信息的處理

在DICOM標準中,患者信息雖然信息層次最高,但是從屬于研究模塊,這樣帶來兩個問題:一是由于患者存在有多個研究,同樣的患者信息就存在于多處,容易造成患者數(shù)據(jù)不一致。二是對常用的操作(如查詢、存儲等),都是首先從患者信息開始進行的。如果患者信息存放在研究模塊中,必然先從研究模塊中查找患者信息,再由此查找到其它模塊中的索引信息,這樣的過程會引起系統(tǒng)效率的降低?；颊咝畔⒖梢苑譃椴蛔兊撵o態(tài)信息和可變的動態(tài)信息兩部分。靜態(tài)信息指患者出生年月,父母姓名等等。這些信息只要在患者模塊中保存一次,需要時直接引用即可。而其它的是屬于動態(tài)變化的信息,如體重等,對于每次研究,這些信息可能都有變化,這些變化往往有醫(yī)療診斷價值,研究模塊必須反映出這種變化,因此這些動態(tài)信息必須單獨保存在研究模塊中。這樣分離的結(jié)果使得患者模塊既提升到研究模塊之外,避免了在研究模塊中患者信息的重復存儲,而又不造成信息丟失。當需要使用患者的靜態(tài)信息時,將患者模塊中的數(shù)據(jù)鏈接到研究模塊中即可。在DICOM標準中,規(guī)定了患者姓名、患者ID作為查詢的關鍵字,其它信息則是可選擇的。但無論對中國人還是外國人來說都存在重名的問題。因而在數(shù)據(jù)庫中姓名是不能作為主關鍵字,在查詢過程中也要對同名問題加以處理。患者ID通過在系統(tǒng)中指定一個唯一的ID派發(fā)中心,可以保證在醫(yī)院范圍內(nèi)的唯一性,因而可以作為數(shù)據(jù)庫的主關鍵字。但是在網(wǎng)絡環(huán)境下存在著同一個人在不同地點、不同的醫(yī)院中有不同的編號,這使得在醫(yī)院之間的信息交換過程更加復雜,一般是通過組合屬性查詢的方法解決這個問題。

4SQL查詢過程

對于用上面各個關系表建立起來的數(shù)據(jù)庫,基本的查詢、存儲、修改等功能都是用數(shù)據(jù)庫系統(tǒng)中SQL語言的存儲過程,配合通信網(wǎng)關模塊中的程序?qū)崿F(xiàn)。DICOM通信網(wǎng)關程序負責與網(wǎng)絡環(huán)境中的其它DICOM設備進行通信,將DICOM消息交換協(xié)議(DIMSE)命令映射為對數(shù)據(jù)庫操作的SQL語句和其它處理過程,網(wǎng)關程序通過ODBC方式與數(shù)據(jù)庫互連。例如對于常用的從患者姓名得到某個圖像數(shù)據(jù)查詢過程如下:(1)從患者模塊中查出所有姓名為NameStr的患者IDSELECTPatientIDFROMPatientTableWHERETagGroup=16ANDTagElement=16ANDValuecon-tent=@NameStr(2)從同名的各個患者詳細信息中選出所要的患者的ID這是一個交互的過程,用戶通過應用程序與數(shù)據(jù)庫得到具體的患者ID。(3)以患者ID為鍵值查患者聯(lián)接表,得到所有的研究、序列、圖像UID用SELECTStudyUIDFROMPatientLinkTableWHEREPatientID=@ID得到所有研究UID。用SELECTImageUIDFROMPatientLinkTableWHEREPatientID=@ID得到所有圖像UID。(4)以圖像UID可以從圖像數(shù)據(jù)表中得到圖像數(shù)據(jù):SELECTValueFROMDataTableWHERETagGroup=32736ANDTagElement=16ANDPatientID=@ID。(5)應用程序以ODBC的調(diào)用取出圖像數(shù)據(jù)做進一步的處理。必須說明的是,上述操作僅僅是DICOM網(wǎng)關程序?qū)?shù)據(jù)庫的直接操作,而數(shù)據(jù)庫管理系統(tǒng)并不直接與系統(tǒng)中其它的DICOM設備交換信息。

5結(jié)論

盡管DICOM標準應用了面向?qū)ο蟮姆治龇椒?但根據(jù)其信息模型,還是可以用簡潔方式在關系數(shù)據(jù)庫上實現(xiàn)其信息存儲功能。本文提出的方案,在SQLServer7.0和Oracle8系統(tǒng)上都實現(xiàn)了設計目標。本系統(tǒng)經(jīng)過實驗檢驗,具有如下的優(yōu)點:(1)庫結(jié)構(gòu)簡單,構(gòu)造方便,這使得系統(tǒng)維護工作量大為減少。(2)數(shù)據(jù)存儲效率高,克服了記錄全部屬性所產(chǎn)生的數(shù)據(jù)稀疏問題。(3)系統(tǒng)擴充余地大,由于DICOM標準的是在不斷的修改和補充變化的過程中,用本方案不會為因為變化而引起數(shù)據(jù)庫結(jié)構(gòu)的變化。(4)數(shù)據(jù)庫輸出數(shù)據(jù)時,易于組成標準所要求的數(shù)據(jù)集,數(shù)據(jù)轉(zhuǎn)換的開銷小。(5)數(shù)據(jù)庫系統(tǒng)功能獨立,不參與DICOM的消息交換協(xié)議。(6)保留了數(shù)據(jù)標記(Tag),使得數(shù)據(jù)有精確語義,不會引起語義的混淆。至于由于記錄了每個數(shù)據(jù)元素的標記、值表示法和值長所帶來的對存儲效率的影響,我們認為在存儲設備容量不斷增大,性能飛速提高的現(xiàn)代技術(shù)條件下,以存儲空間換取系統(tǒng)結(jié)構(gòu)上的簡單和程序的清晰等優(yōu)勢還是值得的。醫(yī)學圖像數(shù)據(jù)庫作為醫(yī)療信息系統(tǒng)的核心技術(shù),可廣泛應用在PACS系統(tǒng)、遠程醫(yī)療系統(tǒng)、醫(yī)療檔案系統(tǒng)以及醫(yī)療影象設備中。