Selvitys tiedostoformaatista DICOM3 versio 1.1

Selvitys tiedostoformaatista DICOM3 versio 1.1 TTKK Porin korkeakouluyksikkö Tekijä: Juha Lähteenmäki Tulostettu: 25.10.2003 Jakelu: Prof. Pekka Loula Dokumentin tila: työversio Muokattu: 25.10.2003

25.10.03 2/53

VERSIOHISTORIA Versio 1.0 Päiväys (valm. pv lihavoitu) 26.6-18.7 Tekijät Juha Lähteenmäki Selite (muutokset, korjaukset...) Ensimmäinen jaeltava versio kommentoitavaksi 1.1 31.7-21.8 Juha Lähteenmäki Toinen korjattu versio Muutokset/korjaukset: Luku 1 (lisäyksiä ja päivityksiä) Luku 2 (kirjoitettu pääosin uudelleen) Luku3 (Ulkoasua ja järjestelyä parannettu. Paljon uusia osia) Luku4 (lähes ennallaan ) Luku5 (lähes ennallaan) 25.10.03 3/53

SISÄLLYSLUETTELO 1. JOHDANTO... 7 1.1 TARKOITUS JA KATTAVUUS... 7 1.1.1 Varoitus! :-)... 7 1.2 MÄÄRITELMÄT, TERMIT JA LYHENTEET... 7 1.3 VIITTEET... 11 1.4 DOKUMENTIN RAKENNE... 12 1.5 YLEISKATSAUS DOKUMENTTIIN... 12 2. DICOM???... 14 2.1 MIKÄ DICOM ON?... 14 2.2 DICOM:IIN LIITTYVIÄ VÄÄRINKÄSITYKSIÄ JA SELVITYKSEN ONGELMIA?... 14 2.2.1 Yleiset harhaluulot DICOM:sta... 14 2.2.2 Epäselvyydet versionimissä ja osalukumäärissä... DICOM, DICOM Version 3, ACR- NEMA Version 2, "draft-versio"...????... 15 2.2.3 Mitä DICOM sitten oikein takaa?... 15 2.3 DICOM:N HISTORIA JA SEN KEHITYSVAIHEET... 16 2.4 DICOM:N KOMMUNIKAATION MALLI... 18 2.5 DICOM:N RAKENNE JA OSAT... 20 2.5.1 Osa 1: Introduction and Overview [DICM/1]... 21 2.5.2 Osa 2: Conformance [DICM/2]... 21 2.5.3 Osa 3: Information Object Definitions (IODs) [DICM/3]... 22 2.5.4 Osa4: Service Class Specifications [DICM/4]... 22 2.5.5 Osa5: Data Structure and Semantics [DICM/5]... 22 2.5.6 Osa6: Data Dictionary [DICM/6]... 22 2.5.7 Osa 7: Message Exchange [DICM/7]... 22 2.5.8 Osa 8: Network Communication Support for Message Exchange [DICM/8]... 23 2.5.9 Osa 9: Point to Point Communication Support for Message Exchange [DICM/9]... 23 2.5.10 Osa 10: Media Storage and File Format for Media Interchange [DICM/10]... 23 2.5.11 Osa 11: Media Storage Application Profiles [DICM/11]... 23 2.5.12 Osa 12: Media Formats and Physical Media for Media Interchange [DICM/12]... 24 2.5.13 Osa13: Print Management Point-to-Point Communication Support [DICM/13]... 24 2.6 DICOM:N TULEVAISUUS... 24 3. DICOM3 KUVA-TIEDOSTON RAKENNE JA OSAT... 26 3.1 DICOM-TIEDOSTO - MUTKIKAS PALAPELI... 26 25.10.03 4/53

3.2 DICOM TIEDOSTON PERUSOSAT ("PALAPELIN" KEHYKSET)... 26 3.3 DICOM DATA SET ("PALAPELIN" KUVAPALIKKA JA SEN TIETO PALASET)... 27 3.3.1 Data-alkiot ("palapelin" palaset) Data Set:in ja DICOM tiedoston perustana... 27 3.3.2 Data Setin data-alkiot jaotellaan ominaisuusryhmiin... 30 3.4 DICOM FILE META INFORMATION ("PALAPELIN" PURKAMIS OHJEET)... 37 3.5 DATA-ALKIOIDEN KOODAUS JA PAKKAUS... 39 3.5.1 Big Endian ja Little Endian (Tavujen järjestely Datan koodauksessa)... 39 3.5.2 DICOM-tiedoston syntaksi... 40 3.5.3 Pikselidata... 40 3.6 ESIMERKKI... 40 4. SELVITYS DICOM3 -TIEDOSTON MUUNNOKSESTA... 40 4.1 OLEMASSA OLEVAT DICOM KATSELU- JA MUUNNOSOHJELMAT... 40 4.1.1 ImageJ... 40 4.1.2 eviewbox ja JDicomViewer... 40 4.1.3 MRIcro ja EzDicom... 40 4.1.4 Osiris... 40 4.2 YLEISIÄ DICOM - MUUNNOKSESSA TARVITTAVIA TIETOJA... 40 4.2.1 Data-alkioiden tunnistus... 40 4.2.2 Dataryhmän (Data Group) ja Data-alkion (Data-element) pituus... 40 4.3 MUUNNOSPROSESSIN VAIHEET (YLEISELLÄ TASOLLA)... 40 4.3.1 Vaihe 1: Tarkista että muunnettava tiedosto kelvollinen DICOM3-Tiedosto... 40 4.3.2 Vaihe2 : Tarkista tiedoston "syntaksi" (Transfer Syntax UID)... 40 4.3.3 Vaihe3: Tarkista mitä attribuutteja tiedosto sisältää (tiedoston pituus)... 40 4.3.4 Vaihe4: Tarkista että tiedosto sisältää kaikki muunnosta varten tarvittavat data-alkiot. 40 4.3.5 Vaihe5: Lue tarvittavat data-alkiot ja pura niiden sisältämä data syntaksin mukaisesti. 40 4.3.6 Vaihe6: Suorita tarvittavat muunnosprosessit ja kirjoita uudelleen koodattu pikseli-data kohdetiedostoon.... 40 4.4 DICOM -TIEDOSTON MUUNNOKSEN ONGELMIA... 40 5. MISTÄ SAAN LISÄTIETOA? (LINKKILISTA JA LIITTEET)... 40 5.1 YLEISTÄ... 40 5.2 SÄHKÖISEN LIITEARKISTON SISÄLTÖ... 40 5.2.1 Esimerkkejä -kansio... 40 5.2.2 Omat -kansio... 40 5.2.3 Perusinfo -kansio... 40 5.2.4 Projekteja -kansio... 40 5.2.5 Sekalaista -kansio... 40 5.2.6 Softa -kansio... 40 25.10.03 5/53

5.2.7 standardi(viimeisin99draft) -kansio... 40 5.3 LINKKILISTA SELITYKSINEEN... 40 6. ONNITTELUT!... 40 25.10.03 6/53

1. JOHDANTO 1.1 Tarkoitus ja kattavuus Tämä dokumentti on tehty kesätyönä Porin korkeakouluyksikölle selvitykseksi DICOM3 -Standardin mukaisesta lääketieteellisestä kuvatiedosto-formaatista. Selvitys on osa tulevaisuudessa mahdollisesti toteutuvaa Porin korkeakouluyksikön ja Soneran välistä yhteistyöprojektia. Dokumentissa on käsitelty pääasiassa DICOM3-kuvatiedoston rakennetta lähinnä kuvatiedoston muunnosprosessia silmälläpitäen. Tarkoituksena oli luoda pienimuotoinen selvitys ko. formaatista Webpohjaisen Konsultaatio-järjestelmän suunnittelutyötä ajatellen, sekä tarjota mahdollisuus lisätietojen nopeaan hankkimiseen lähdemateriaalin, viittausten ja sähköisessä muodossa olevan liitearkiston avulla. Tässä liitearkistossa on myös ACR-NEMAN DICOM -standardi ("draft"-versio (1999)). 1.1.1 Varoitus! :-) Huom!!! Vaikka kaikki mahdollinen on tehty tämän dokumentin oikeellisuuden ja kattavuuden varmistamiseksi kirjoitushetkellä, ei Dokumentin kirjoittaja vastaa hengellään, omaisuudellaan tai edes teekkari-lakillaan siitä, mikäli jokin tieto tässä dokumentissa on epätäydellinen tai väärä. Käytä tätä dokumenttia muun informaation (virallisen painetun DICOM-standardin) lisänä ja ymmärtämisen apuna. Tämä varoittelu siitä syystä että DICOM-standardista ja DICOM-tiedostomuodosta on olemassa tuhansia eri tulkintoja jotka standardin yksikäsitteisyydestä huolimatta eivät aina ole yhteensopivia. Myöskään kirjoittajan käytössä ja tämän dokumentin sähköisessä liitearkistossa oleva standardin sähköinen "draft"-versio (1999) ei välttämättä kaikilta kohdiltaan ole virallisen painetun DICOM-standardin (DICOM Version 3) mukainen. Virallinen painettu versio on tilattavissa maksua vastaan NEMA:lta (http://medical.nema.org/dicom.html) 1.2 Määritelmät, termit ja lyhenteet Seuraavassa taulukossa on listattu aakkosjärjestyksessä dokumentissa esiintyvät termit, määritelmät tai lyhenteet, jotka saattaisivat 25.10.03 7/53

mahdollisesti aiheuttaa sekaannusta dokumenttia luettaessa tai tarvitsevat muuten selvitystä tai tarkennusta. Termi tai lyhenne: ACR ACSE Selitys American College of Radiology OSI Association Control Service Element Atribuutti (attribute) Tarkenne, ominaisuus (tässä eritoten tietyn ominaisuusryhmän yksittäinen jäsen) Big Endian Binääridatan koodaustapa CT Data-alkio Element) Datajoukko Set) (Data (Data Computed Tomography Lääketieteellinen kuvausmenetelmä informaatio-objektin atribuutti, jolle on annettu joku yksilöllinen arvo. Joukko data-alkioita. Esim. DICOM tiedostossa data-joukko sisältää tiedoston varsinaisen datan. DICOM / DICOM3 / DICM3 /DICM DIMSE "draft"-versio GIF Dicital Imaging and Communication standard ACR-NEMAN Standardi lääketieteellisistä kuvaformaateista. (Huom. DICOM = DICOM3 koska standardi nimettiin DICOM:ksi vasta 3:ssa versiossa) Tässä dokumentissa tarkoitetaan lisäksi DICOM:sta puhuttaessa DICOM3:n tällä hetkellä viimeisintä sähköistä ns. "draft"- versiota (1999) (ks. "draft"-versio) DICOM Message Service Element DICOM standardin julkisesti saatavilla oleva testikäyttöön tarkoitettu standardin "ehdotelma"-versio. compuserve Graphics Interchange Format Häviöttönästi pakattu kuva formaatti. GIF-formaatissa tallennettu kuva voi sisältää enintään 256 erilaista sävyä HYTT IEC Information Object / "informaatio objekti" IOD ISO Tampereen teknillisen korkeakoulun ohjelmistotekniikan laitoksella käytössä oleva: Hyväksytty Yleinen ToimintaTapa [Dokuty98] International Electrotechnical Commission Informaatio objekti on reaalimaailman käsite joka jollain tapaa voi liittyä lääketieteellisen kuvantamiseen. DICOM-standardin tuntemat informaatio objektit on määritelty standardin osassa 3. [DICM/3]. Kullakin informaatio objektilla on omat atribuuttinsa Information Object Definition International Standards Organization 25.10.03 8/53

JPEG:iä (JPG) Little Endian NEMA ominaisuusryhmä (tässä ominaisuusryhmä = Joint Photographic Expert Group Häviöllinen (myös häviötön JPEG olemassa) pakkausalgoritmi/kuvaformaatti. Jpeg :in yhteydessä käytettävästä koodauksesta tarkemmin [DICM/5](8.2.1) Binääridatan koodaustapa National Electrical Manufacturers Association Ominaisuusryhmä (Information Object Module) on ryhmä informaatioobjektin samankaltaisia atribuutteja (data-alkioita). Yhdellä informaatio-objektilla on usein monta eri ominaisuusryhmää (modules). module) OB OSI-malli Eräs VR:N mahdollinen arvo Open System Interconnection ISO:n Standardiin perustuva 7-kerroksinen laitteiden/sovellusten välisen kommunikaation malli. OSI malli perustuu ns. vertaiskommunikaatioon, jossa kaksi saman kerroksen oliota keskustelee ko. kerroksen yhteyskäytännön mukaisesti. Mallin N:s kerros perustuu aina N-1:n kerroksen tarjoamiin palveluihin. OSI mallin kerrokset ovat alhaalta ylös: 1) Peruskerros (Fyysinen kerros) (Physical) --> siirtää bittejä, 2) Siirtokerros (Link) -->Siirtää datan verkon naapurisolmujen välillä 3) Verkkokerros (Network) --> sanomien reititys verkon läpi 4) Kuljetuskerros(Transport) -->nostaa verkkokerroksen palvelut yhteyskerroksen tasolle 5) Yhteyskerros(Session) --> tarjoaa synkronoidun ja organisoidun tiedonsiirron esitystapa kerrokselle. 6) Esitystapakerros (Presentation) --> Suorittaa esitystapa muunnoksia paikallisen ja siirtoesitysmuodon välillä sekä neuvottelee käytettävän siirtoesitysmuodon 7) Sovelluskerros (Application) -->liitäntä sovellusprosessin ja tietoliikennemaailman välillä 25.10.03 9/53

Kuva 1.1 OSI-malli [OSI] OSI ULS OW PIXEL (pikselisolu) PIXEL (pikselidata) PKY RGB RLE SOP CELL: DATA OSI Upper Layer Service Eräs VR:N mahdollinen arvo Pienin kuvadatan osa, joka sisältää yksittäisen pikselin näytearvon Graafinen data (kuvadata) jossa kukin piste esitetään tietyllä kuvapisteen arvolla pixelillä. PorinKorkeakouluYksikkö Red Green Blue Additiivinen eli lisäävä värien muodostus- (ja koodaus) tapa Run Length Encoding Compression, häviötön pakkausalgoritmi. Service-Object Pair Service-Object Pair Informaatio objektin ja kommunikaatio käsitteen käytännön ilmentymä.. (SOP) Instance: STN "syntaksi" Tagi / Tag TIFF (TIF) TTKK DICOM Session/ Transport / Profile kieli, merkitys; tässä Transfer Syntax joka ilmaisee DICOM-tiedoston kuvadatan koodauksen data-alkion tunnisteosa Tagged Interface File Format, kuvaformaatti runsassävyisille kuville. Tampereen teknillinen korkeakoulu 25.10.03 10/53

UID VR Unique identifier Value Representation, (data-alkion kenttä) spesifioi data-kentän arvon/arvojen tyypin ja muodon Taulukko 1.1 Dokumentissa käytettävät termit ja lyhenteet (joita ei ole selitetty esiintymisensä yhteydessä tai jotka vaativat lisä selvennystä). lihavointi ja kursivointi [hakasuluissa] (suluissa) / kauttaviiva lihavointia ja kursivointia on käytetty ainoastaan selvennys tarkoituksessa viittaukset tarkennukset vaihtoehtoinen tapa Taulukko 1.2 Dokumentissa käytettävät merkintätavat. 1.3 Viitteet Tässä kappaleessa on listattuna ja selitettynä dokumenttissa käytetyt viitteet Varsinainen liite- ja linkkilista on omassa luvussaan (luku 5). [Barre] [Chris] [DICM/X ] http://www.hds.utc.fr/~barre/medical/samples/in dex.html#transfer-syntax Tietoa DICOM - tiedostoformaatista: http://www.mrccbu.cam.ac.uk/personal/chris.rorden/ dicom.htm DICOM3 -standardi (sähköinen "draft" -versio 25.10.03 11/53

1999) osa X [Dokuty98] [EDU] [LukuX] [NEMA] [DICM/status] [OSI] Dokumentoinnin tyyliohje, 30.8.1998, versio 1.0, TTKK, Ohjelmistotekniikka, http://www.cs.tut.fi /cgi-bin/laatu/sivuhaku.pl? nk_no=2&nk_id=189. PRODUCT 4.23 - INFORMATICS STANDARDS IN HEALTH http://www.eihms.surrey.ac.uk /abbott/it-eductra/html/p423_13.htm Viittaa tämän dokumentin lukuun X (1-6) NEMA:n standardi-sivu http://www.nema.org/standards/ http://idt.net/~dclunie/dicom-status/status.html http://www.tml.hut.fi/opinnot/tik- 110.350/1999/Kalvot/TKV170299/index.htm 1.4 Dokumentin rakenne Tämän dokumentin rakenne noudattaa TTKK:n ohjelmistotekniikan laitoksen Hyväksyttyä Yleistä ToimintaTapaa soveltuvin osin (HYTT) [Dokuty98]. 1.5 Yleiskatsaus dokumenttiin Luku 1 on johdanto dokumenttiin. Johdanto selvittää dokumentin tarkoituksen, rakenteen ja laajuuden sekä selittää dokumentissa käytetyt termit ja viittemerkinnät. Ensimmäinen luku tarjoaa myös kiireiselle lukijalle hyödyllisen yleiskatsauksen dokumenttiin (tämä osa),jossa käydään lyhyesti läpi dokumentin sisältö. Luku 2 esittelee lyhyesti DICOM3 -standardin ja sen rakenteen. Tämän luvun tarkoituksena on antaa lukijalle yleiskäsitys DICOM3:sta jotta dokumentin seuraaminen helpottuu. Luku 3 käy läpi DICOM3 kuvatiedoston rakenteen ja tiedostoformaatin. Ennenkaikkea tarkastellaan tiedoston rakennetta DICOM- tiedoston muunnoksen kannalta. Luku 4 käsittelee varsinaisen DICOM3 -tiedoston muuntamisen muihin kuvatiedosto formaatteihin. Muunnos käydään läpi vaiheittain 25.10.03 12/53

yleisellä tasolla, mutta itse muunnosprosessin yksityiskohtiin ei mennä kovin syvällisesti. Tarkoituksena on antaa yleiskuva niistä toimenpiteistä ja asioista, joita DICOM3 -muotoisen tiedoston muuntamiseen liittyy. Luvussa 4 esitellään myös joitakin saatavilla olevia muunnos- ja katseluohjelmia ja niiden ominaisuuksia. Luku 5 sisältää tärkeää informaatiota lisätiedon etsintään aiheesta. Tässä luvussa käydään läpi yksityiskohtaisesti sähköisen liitearkiston sisältö. Lukuun 5 kuuluu myös linkkilista selityksineen aiheeseen liittyen. 25.10.03 13/53

2. DICOM??? 2.1 Mikä DICOM on? DICOM (Digital Imaging and Communications in Medicine) on mailmanlaajuisesti käytetty lääketieteellisen kuvantamisen standardi, joka määrittelee lääketieteellisen kuvaformaatin ja tarjoaa kuvauslaitteille yhteensopivan tavan kommunikoida keskenään sekä ulkomaailman kanssa. Yksinkertaistaen voidaankin todeta, että DICOM määrittelee lääketieteellisen kuvauksen "kielen" ja luo "kehykset" lääketieteellisille kuville. DICOM on pohjimmiltaan amerikkalainen standardi. Sen takana on kahden standardin potetiaalisen käyttäjän ACR (American College of Radiology) ja NEMA (National Electrical Manufacturer's Association) (ACR-NEMA) yhteenliittymä. DICOM on siis lähtenyt käyttäjien tarpeesta. Tämä on mahdollistanut sen, että DICOM:sta on myös voinut kehittyä hyvin käytännön tarpeet täyttävä standardi. Toisaalta käytännön lähtökohtien huomioiminen on varmasti osaltaan syynä siihen, miksi DICOM ei ole ehkä niitä selkeä lukuisimpia standardeja. Tunnettu tosiasiahan on, että käytännöllisyys, yleisyys ja monimutkaisuus kulkevat käsi kädessä. 2.2 DICOM:iin liittyviä väärinkäsityksiä ja selvityksen ongelmia? Osittain ehkä DICOM:n monimutkaisuudesta johtuen siitä on olemassa useitakin vääriä käsityksiä ja huhuja, jotka osaltaan hankaloittavat standardin ymmärtämistä. 2.2.1 Yleiset harhaluulot DICOM:sta DICOM ei sinänsä puutu mitenkään varsinaisen kuvadatan sisältöön eikä näin ollen itsessään paranna kuvan laatua. DICOM ei ota kantaa kuvan lääketieteellisen sisällön oikeellisuuteen tai tarkkuuteen. Se ei siis määrittele kuinka tarkka esim. MR-kuvan pitäisi olla, jotta sitä voitaisiin käyttää diagnosointiin. DICOM ei takaa sitä, että DICOM:a tukevat laitteet ja niiden kuvat olisivat täysin yhteensopivia. DICOM:n hienoin idea on juuri siinä, 25.10.03 14/53

että se ei rajoita käyttäjän luovuutta. Se vain määrittelee tietyt minimi vaatimukset, mutta ei kaikilta osin anna aina ehdotonta mallia miten jokin asia pitäisi tehdä. Varsinainen yhteensopivuus on aina varmistettava laitevalmistajan "yhteensopivuus väittämästä" (conformance statement) esim. valmistajan kotivuilta. Tästä "yhteensopivuus väittämästä" ilmenee millä tavoin valmistajan tuote ja sen kuvat ovat DICOM yhteensopivia. 2.2.2 Epäselvyydet versionimissä ja osalukumäärissä... DICOM, DICOM Version 3, ACR-NEMA Version 2, "draft-versio"...???? DICOM ei eroa mitenkään DICOM Version 3:sta. ACR-NEMA Version1 ja ACR-NEMA Version2 ovat DICOM:n "aiempien versioiden" nimet, eikä DICOM 1:stä, DICOM 2:sta tai DICOM 3:sta ole virallisesti olemassa. Sekavuutta saattaa lisätä vielä verkon kautta jaeltava "draft" - eli kehitysversio, joka kuitenkin vastaa käytännössä melko hyvin standardin uusinta painettua versiota. DICOM:sta ei siis ole olemassa tällä hetkellä useampia kuin yksi virallinen painettu (ja maksullinen) versio nimeltään DICOM Version 3. Tässä versiossa on nykyisin (vuoden 1999 lopussa) alkuperäisen 1993 julkaistun standardin 9 osaa ja näihin myöhemmin lisätyt 5 lisäosaa (liitettä) eli yhteensä 14 osaa. Mainitsen osalukumäärät tässä siksi, että nimenomaan niiden kohdalla esiintyy monesti epäselvyyksiä (tämän dokumentin edellinen versio mukaanlukien) kun joissain yhteyksissä puhutaan muiden kuin alkuperäisten 9:n osan kohdalla liitteistä (supplements). Pahiten asiaa kuitenkin sotkee se, että standardia päivitetään jatkuvasti ja uusia kohtia lisäillään samalla kun vanhentuneita poistetaan. Tämä saattaa aiheuttaa sen, että standardin osienkin lukumäärä voi jo ensi vuonna olla täysin eri kuin tänä vuonna. Oman sotkunsa soppaan lisäävät vielä käytössä olevat standardien vanhemmat painokset ja monet muut lähteet kun puhutaan DICOM:n sisältävän 9, 10 tai 13 osaa. Vaikka osien lukumäärällä ei käytännössä ole juurikaan merkitystä, se antanee kalpean aavistuksen DICOM:n ylläpidon hankaluuksista. Kun liikutaan tietotekniikan kaltaisilla nopeasti muuttuvilla alueilla, vaatii toimivan standardinkin ylläpito jatkuvia muutoksia uusien tekniikoiden kehittyessä ja yleistyessä. 2.2.3 Mitä DICOM sitten oikein takaa? Kaiken yllä olevan negatiivisen pyörityksen jälkeen lukijalle saattaa herätä kysymys, mitä DICOM yhteensopivuus sitten oikein takaa? Periaatteessa vastaus voisi kuulua ei mitään, sillä DICOM: n väljyydestä johtuen sillä voidaan tehdä melkein mitä tahansa. Käytännössä se oikein käytettynä kuitenkin varmistaa, että kuvista on 25.10.03 15/53

saatavissa ja kuviin on liitettävissä kaikki tarpeellinen data järkevällä ja yksikäsitteisellä tavalla, vieläpä siten että kuvan rakennekin säilyy järkevänä, yksikäsitteisenä sekä laitteisto/ympäristö riippumattomana. Kun tähän ylevään lauseeseen vielä lisätään, että kaikki tämä on mahdollista myös käytännön kuvauslaitteille ja suhteellisen vähän luovuutta rajoittavasti, voidaan hyvällä syyllä todeta että DICOM mahdollistaa paljon, vaikkei pelkkä väittämä "DICOM yhteensopiva" itsessään takaakaan paljon mitään. Juuri tämä lienee se DICOM:n menestyksen salaisuus. ;-) 2.3 DICOM:n historia ja sen kehitysvaiheet Ensimmäiset ajatukset lääketieteellisen kuvastandardin kehittämiselle heräsivät jo 1970 -luvulla, kun mikroprosessorien kehityksen myötä tietokoneiden ja tietotekniikan määrä sairaaloissa kasvoi voimakkaasti. Ongelmana oli tuolloin eritoten kuvauslaitteiden ja kuvien keskinäinen yhteensopimattomuus ja hankala siirreltävyys, kun kukin laite käytti ja ymmärsi ainoastaan tietyn tyyppisiä kuvia. Vuonna 1983 ACR (American College of Radiology) ja NEMA (National Electrical Manufacturer's Association) saivat vihdoin pitkällisten alkuvalmistelujen jälkeen muodostetuksi komitean, joka ryhtyi kehittämään lääketieteellisen kuvauksen standardia lähinnä radiologian tarpeisiin. Kehittäjiensä mukaan standardi sai nimekseen ACR-NEMA. Ensimmäistä versiota seurasi pian toinen, mutta kumpikaan ei saavuttanut juurikaan suosiota varsinkaan Amerikan mantereen ja radiologian ulkopuolella. Ongelmana oli lähinnä standardin kapea-alaisuus, verkkotuen puuttuminen ja epäyhteensopivuudet muihin Digitaalisen kommunikaation standardeihin nähden. Jo melko pian ACR-NEMA:n toisen version jälkeen kävi ilmeiseksi, ettei standardi tulisi yleistymään ainakaan radiologian ulkopuolella. Eurooppalaiset kehittelivät jo vauhdilla omaa MEDICOM standardiaan, jonka oli tarkoitus korvata rakenteeltaan osittain vanhentunukin ACR-NEMA euroopassa. ACR ja NEMA olivat vaikean päätöksen edessä. Jatkaako edelleen standardin kehittelyä suppealle kohdejoukolle, vai lähteäkö kehittämään standardia alusta alkaen uudelleen? Lopulta päädyttiin jälkimmäiseen ratkaisuun. Datarakenne päätettiin kuitenkin säilyttää, koska se oli saavuttanut melkoisesti suosiota laitevalmistajien keskuudessa. Sen sijaan vanhentuneet matalan tason kommunikaatio protokollat jätettiin syrjemmälle, ja uusi OSI-mallin pohjalta rakenneltu verkkopohjaisen kommunikaation malli luotiin. Muutenkin yhteensopivuutta muihin standardeihin parannettiin ja standardi pyrittiin suuntaamaan mahdollisimman laajalle sovellusalueelle. 25.10.03 16/53

Työtä tekemään nimettiin useita komiteoita, jotka työskentelivät paljolti yhteistyössä eurooppalaista MEDICOM:ia kehittävän CEN TC 251 -työryhmän ja muidenkin standardoimis organisaatioiden kanssa. Vuoteen 1993 mennessä standardin runko alkoi olla valmis ja standardin jakelu alkoi marraskuussa 1993. Syntynyt uusi lääketieteellisen kuvantamisen standardi, joka sai nimekseen DICOM Version 3, tuntui vihdoin riittävän yleispätevältä. Se vaati kuitenkin vielä monelta osin tarkennuksia ja täsmennyksiä. Merkittävin tehtävä oli määritellä tarkemmin tiedostoformaatti ja spesifioida eri tallennus mediat ja niiden rajapinnat, jotka alkuperäinen standardi periaatteessa jätti avoimeksi. Kehitystyötä päätettiin jatkaa lisäämällä uusia osia (liitteitä) alkuperäiseen standardiin. Liitteitä valmistuikin vähitellen ja vuoden 1998 aikana DICOM oli saanut lähes nykyisen (1999) ulkoasunsa (kaikki 14 osaa). DICOM levisi vauhdilla. Jo vuoteen 1996 mennessä, se oli saavuttanut vankan jalansijan Euroopassakin. Leviämistä Eurooppaan auttoi osaltaan se, että alunperin puhtaasti omaksi standardikseen suunniteltu eurooppalainen kuvantamisen standardi MEDICOM pohjautui yhteistyön ansiosta lähes täysin DICOM:iin. Myös laitteistovalmistajien siirtyminen DICOM:iin kävi helposti, koska standardin datarakenne vastasi ACR-NEMA:n datarakennetta, joka useimmilla valmistajilla oli jo käytössä. Erityisesti yleistyminen kardiologian alueella oli merkitävä läpimurto DICOM:lle. Se osoitti ensimmäistä kertaa myös käytännössä, että alunperin radiologian tarpeisiin suunniteltu standardi pystyi onnistuneesti toimimaan myös muilla lääketieteen alueilla. DICOM:sta tuli kuvauksen ja kuvauslaitteiden "de facto"-standardi, joka on käytössä ympäri maailmaa. Seuraavassa taulukossa on kuvattu lyhyesti DICOM standardin tärkeimmät kehitysetapit. 1983 ACR ja NEMA muodostavat komitean lääketieteellisen kuvastandardin kehittämiseksi 1985 Standardin ensimmäinen versio valmistuu. Tämä ACR-NEMA standardi ei kuitenkaan saavuta laajaa suosiota. 1988 Standardin 2. versio julkaistaan. Versioon 2 on lisätty mm. tuki kuvadatan pakkaukselle. 1989 Aloitetaan standardin 3:n version kehitystyö. Tarkoituksena on luoda kokonaan uudistettu versio, joka pohjautuu paremmin olemassa oleviin kommunikaation standardeihin. Erotukseksi edellisistä 25.10.03 17/53

versioista standardi päätetään nimetä DICOM:ksi 1991 Ensimmäiset DICOM-standardin osat (1 ja 8) valmistuvat 1993 Standardin osat 1-9 otetaan käyttöön. Standardin nimeksi tulee DICOM Version 3. Vaikka standardin 3:s versio katsotaan virallisesti valmistuneeksi sen kehitystyö jatkuu edelleen 1994 Liite 1 (Supplement 1) eli käytännössä osa 10, (part 10 Media Storage and File Format) valmistuu 1995 Liitteet 2, 3 ja 4 (Parts 11, 12, 13) valmistuvat 1998 Tällä hetkellä viimeisin Liite 5 (Part 14) valmistuu Taulukko 2.1 DICOM -standardin kehitysvaiheet. 2.4 DICOM:n kommunikaation malli Medical Imaging Application DICOM Application Entity (DICOM sovellusyksikkö) Service Class specifications Information Object Definitions Data Structure and Encoding File Format DICOM File service Message Exchange OSI ULS (OSI Upper layer service) -rajapinta Media format and physical media specifications Off Line Communication DICOM Session/ Transport / Profile STN DICOM DataLink DICOM UpperLayer Protocol for TCP/IP TCP IP ACSE OSI Presentation Kernel OSI Session Kernel OSI Transport OSI Network LLC (Link) DICOM Physic. (50 pin) "Point to Point" -Ympäristö Standard network physical layer (Ethernet, ISDN...etc) Verkko -Ympäristö On Line Communication Kuva 2.1 DICOM:n kommunikaation malli ja tuetut kommunikaatio protokollat. 25.10.03 18/53

DICOM standardi rakentuu oikeastaan kerroksellisen kommunikaation mallin pohjalta. On hyvä muistaa, että ACR-NEMA standardia lähdettiin aikanaan uudistamaan osaksi juuri puutteellisen verkkotuen takia. Tarvittiin standardia, joka mahdollistaisi joustavasti eri laitteiden ja sovellusten välisen kommunikaation erilaisista ympäristöistä huolimatta. DICOM:a suunniteltaessa otettiinkin tavoitteeksi, että mikä tahansa ulkopuolinen lääketieteellisen kuvauksen sovellus ja kuvauslaite voisivat "keskustella" keskenään standardin tarjoamien "kommunikaatio reittien" (pinot = stacks) avulla. Tältä perustalta syntyi kerroksellinen kommunikaation malli, joka on esitetty kuvassa 2.1. Kommunikaatio mallia katseltaessa voi havaita ISO:n OSI mallin keskeisyyden. Jo kerroksellinen rakenne pohjautuu alunperin OSI:iin, mutta tärkeimpänä liittymäkohtana on kuitenkin OSI:iin pohjautuvan rajapinnan ottaminen mukaan malliin. Seuraavissa kappaleissa on hieman tarkemmin selostettu DICOM:n kommunikaatio mallin sisältöä. Ylimpänä mallissa on DICOM sovellusyksikkö (DICOM application entity) Tämä sovellusyksikkö sisältää palvelu luokkien ja informaatio objektien määritelmät. Lisäksi se spesifioi standardin data rakenteen, datan koodauksen.ja määrittelee viestinnän- sekä tiedoston formaatin. DICOM sovellusyksikkö siis kuvaa standardin kielen ja osaset, joita tarvitaan yhteyksien pitämiseen ulkomaailman kanssa. DICOM sovellusyksikkö voi kommunikoida ulkomaailman kanssa periaatteessa kahden raja-pinnan välityksellä. DICOM File Servicen välityksellä DICOM tiedostot kommunikoivat fyysisen tallennusmedia palasen kanssa, joka pitää sisällään DICOM:n tukemat tallennusvälineet. Koska tämä palikka menee fyysiselle tasolle asti voidaan sen välityksellä DICOM tiedostoja tallentaa hyvinkin monentyyppisissä ympäristöissä tuetuille tallennusvälineille. DICOM sovellusyksikön varsinaiset on-line yhteydet alaspäin hoituvat OSI ULS (OSI Upper Layer Service) -rajapinnan kautta. OSI ULS on pääosin OSI-mallin ACSE(OSI Association Control Service Element ), OSI Presentation Kernel ja OSI Session Kernel palasiin perustuva, DICOM:n Message Exchange -palikan tarjoama palvelu, joka mahdollistaa yhteydet DICOM:n ylempiin kerroksiin. Koska OSI-ULS rajapinta on pääosin yhteinen kaikille DICOM:n tukemille "on line" -kommunikaatio protokollille, se toimii ikäänkuin yhdistävänä siltana DICOM sovellusyksikön ja tuettujen kommunikaatio protokollien välillä. 25.10.03 19/53

DICOM tukee kaikkiaan kolmea erillistä (on-line) kommunikaatio protokollaa. Näistä DICOM:n oma "Point to Point" on mukana lähinnä yhteensopivuus syistä edellisiin "ACR-NEMA" -standardeihin nähden. Verkkopohjaisista protokollista DICOM tukee TCP/IP:tä ja OSI:a. Kuten kuvasta 2.1 voi havaita DICOM ei mitenkään joudu muuttelemaan näitä protokollia, vaan soveltaa niitä sellaisinaan, mikä mahdollistaa laajan yhteensopivuuden eri laitteiden suhteen. OSI protokollasta on erotettavissa kaikki seitsemän kerrosta (ACSE kuuluu 7:een kerrokseen) ks. kuva 2.1. Pohjimmaisena oleva fyysinen kerros ( Standard Network Physical Layer) on yhteinen sekä TCP/IP:lle että OSI:lle. Tämän jälkeen seuraavat OSI:n puolella kaikki muut sen kerrokset järjestyksessä 6:een saakka ja viimeisenä sovelluskerrokseen kuuluva ACSE. Vastaavasti TCP/IP:llä tulevat sen kerrokset IP ja TCP, sekä päälimmäinen DICOM:n oma kerros (DICOM UpperLayer Protocol for TCP/IP) joka vastaa OSI-mallin ylempiä kerroksia ja sovittaa TCP/IP:n OSI:in pohjautuvaan DICOM ULS:ään. Vastaavia tehtäviä hoitaa DICOM:n oman "Point to Point" protokollan puolella STN kerros, joka tukee DICOM ULS:ää tarpeellisilta osin. 2.5 DICOM:n rakenne ja osat Osa 1 OverView Osa 2 Conformance Osa 14 (liite 5) Graysc. Stand. Disp. Funct. Osa 4 Service Classes Specification Osa 3 Information Objects Osa 6 Data Dictionary Osa 7 Message Exchange Osa 5 Data Structures Osa 10 (liite 1) (Storage Media and File Form.) Osa 11 (liite2) Media storage Application Profiles Osa 8 (Comm.Network Support) (OSI) Osa 9 (Comm.Point to Point..) Osa 13 (liite 4) (Print Man. Point to Point..) Part 12 (liite3) (Media formats and fys. media) Kuva 2.2 DICOM -Standardin osat ja rakenne (1999). Alkuperäisten osien ääriviivat on vahvennettu, vanhentuneet osat (tod.näk seuraavasta versiosta poistuvat) kuvattu tummemman harmaalla ja DICOM sovellusyksikkö 25.10.03 20/53

(Application Entity) on ympäröity katkoviivalla. Huomaa että osien sijoittelu kuvaa standardin rakennetta (kerroksellisuus)(vrt kuva 2.1) Edellisessä kappaleessa todettiin jo sivumennen, että DICOM:n rakenne perustuu kommunikaation malliin. Tämä on itse asiassa järkevääkin, sillä sopiihan kommunikaation standardin (jollainen DICOM:kin on) lähtökohdaksi aivan luonnollisesti kommunikaation malli. Suuremmaksi ongelmaksi muodostuikin standardia suunniteltaessa järkevä osajako, eli miten jakaa standardi toisiaan tukeviin, mutta samalla irrallisiin toiminnallisiin palasiin, jotka vielä sopisivat kommunikaation mallin kerroksellisuuteen. Lopulta päädyttiin kuvan 2.2 mukaiseen ratkaisuun. Kun vertaa kuvaa 2.2 kommunikaatio mallin kaavioon, (kuva 2.1) huomaa varmasti melko helposti yhtenäisyydet erityisesti DICOM sovellusykön ja katkoviivoitetun alueen välillä. Tämä palikka pohjautuukin lähes sellaisenaan kommunikaation malliin. Niin ikään alemman tason kommunikointi kerroksien välillä näkyy selvä yhteys, varsinkin jos sisällyttää "point to point" tulostuksen hallinnan (osa 13) "point to point" protokollan yhteyteen. Yleisestikin on huomattava, että vaikka kaikkia osia ei kommunikaatiomallissa näykään, niin silti näilläkin osilla on oma tärkeä tehtävänsä standardissa. Monet näistä kuten osa 2 (conformance) ja osa 11 (Media Storage application profiles) toimivat useamman kerroksen alueella, asettaen rajat standardille ja sen soveltamiselle (Kuvattu muita osia rajoittavina pylväinä). Seuraavissa kappaleissa on vielä käyty lyhyesti läpi kaikki standardin osat ja niiden keskeisimmät tehtävät. 2.5.1 Osa 1: Introduction and Overview [DICM/1] (Esittely ja yleiskatsaus) Tämä osa on eräänlainen johdanto standardiin, joka asettaa päämäärät standardille ja sen toiminnoille. Siinä käydään läpi standardin tavoitteet, historia ja rakenne. Lisäksi osassa 1 on lyhyt yhteenveto standardin kustakin osasta (osat 1-9 ei liite-osia 10-14). 2.5.2 Osa 2: Conformance [DICM/2] (Yhteensopivuus) Määrittelee yleiset yhteensopivuus vaatimukset joiden täytyy täyttyä, jotta tuote voisi olla yhteensopiva DICOM -standardin kanssa. Tämä osa on erittäin tärkeä standardin kannalta koska se tavallaan asettaa rajat standardin tulkinnoille ja soveltamiselle. Conformance osa antaa niin ikään mallin laitevalmistajien käyttämille yhteensopivuus väittämille (conformance statements) joiden rakenteen pitäisi olla sen mukainen. 25.10.03 21/53

2.5.3 Osa 3: Information Object Definitions (IODs) [DICM/3] ("informaatio objectejen" määritelmät) Määrittelee täydellisesti käsitteen "informaatio objekti". Esittää määritelmät käytännön "informaatio objekteista" (käsitteistä, jotka voivat liittyä lääketieteellisen digitaalisen tiedon välittykseen) ja kaikista niihin liittyvistä attribuuteista joita standardi tukee. Määrittelee DICOM:n informaatio mallin ja mallin reaalimaailmasta. 2.5.4 Osa4: Service Class Specifications [DICM/4] (Palveluluokan spesifikaatiot) Määrittelee palveluluokan (Service Class) käsitteen ja SOP:n (Service Object Pair). Kuvaa käsitteiden välisen vuorovaikutuksen mallin, joka on yksi standardin peruspylväistä. Lopuksi käy läpi ja määrittelee eri palveluluokat (Service Class), sekä niihin kuhunkin liittyvät SOP:t. 2.5.5 Osa5: Data Structure and Semantics [DICM/5] (Tiedon rakenne ja semantiikka) Määrittelee tiedon rakenteen ja koodauksen. Käyttää hyväkseen osassa 3 esittettyjä informaatio-objektien määritelmiä ja luo näiden pohjalta "rakennus piirrustukset" standardin välityksellä esitettävälle datalle. ("standardin kielioppi") 2.5.6 Osa6: Data Dictionary [DICM/6] (Tieto sanasto) Sisältää rekisterin kaikista DICOM:n data-alkioista ("rakennus palikat") ja niiden merkinnöistä ("standardin sanakirja") 2.5.7 Osa 7: Message Exchange [DICM/7] (Viestintä) Määrittelee DICOM:n viestipalvelin osan (DIMSE). DIMSE:n käyttämä DIMSE-protokolla puolestaan määrittelee ylemmän tason koodaus säännöt joita tarvitaan viestien välittämiseksi ja sitä kautta myös DICOM ULS:n. Viesti välitetään DIMSE:n mukaan komentojoukkona (Command Set)(sisältää tietoa lähetetyn Data-Setin tulkintaa varten), jota seuraa Datajoukko (DataSet). Viesti formaatti muistuttaa suuresti DICOM tiedostoformaattia (tiedostoformaattia on tarkemmin käsitelty seuraavassa luvussa) 25.10.03 22/53

2.5.8 Osa 8: Network Communication Support for Message Exchange [DICM/8] (Verkkopohjaisen viestinnän tuki) Määrittelee DICOM:n verkkopohjaisen kommunikaation mallin (ks. kuva 2.1), jota voidaan pitää koko DICOM:n rakenteen perustuksena. Tämä osa sisältää myös kuvauksen siitä miten DICOM ULS - muodostetaan ja miten ne liittyvät OSI -mallin kerroksiin. Niin ikään osassa 8 on käsitelty DICOM:n verkkopohjaiset protokollat ja spesifioitu niiden yhteydet toisiinsa 2.5.9 Osa 9: Point to Point Communication Support for Message Exchange [DICM/9] ("Point to Point"- viestinnän tuki) Osa 9 määrittelee DICOM:n oman "Point to Point" protokollan ja sen liittynnän OSI -pohjaiseen rajapintaan DICOM ULS:ään. Tämä osa on mukana lähinnä DICOM:n edeltäjän ACR-NEMA -standardin tukemiseksi. Tulevista DICOM:n versioista se todennäköisesti jää pois. 2.5.10 Osa 10: Media Storage and File Format for Media Interchange [DICM/10] (Tiedon säilöminen ja tiedostoformaatti ) Määrittelee yleisen (kerroksellisen) mallin tiedon tallennukseen, DICOM tiedostomuodon ja DICOM tiedostopalvelun. Malli luo "kehykset" lääketieteellisen kuvainformaation tallennukselle ja eri kuvaformaattien vuorovaikutukselle. Tämän osan sisältöön on perusteellisemmin paneuduttu seuraavassa DICOM:n tiedostoformaattia käsittelevässä luvussa. 2.5.11 Osa 11: Media Storage Application Profiles [DICM/11] (Tiedon tallennuksen sovellutuksia) Tarkentaa ja kuvaa edelleen yleistä tiedon tallennuksen mallia. Mahdollistaa yhteentoimivuuden esittämällä standardin osat, jotka sopivat tiettyyn erityiseen kliiniseen tarpeeseen. 25.10.03 23/53

2.5.12 Osa 12: Media Formats and Physical Media for Media Interchange [DICM/12] ( Tiedon muodot ja fyysinen media tiedon vuorovaikutukseen) Helpottaa tiedon siirtoa eri kuvauslaitteiden ja tietojärjestelmien välillä, määrittelemällä yhteyden yleisen tiedon tallennus mallin (Osa 10) ja tietyn fyysisen median ja tallennusmuodon välille. Määrittelee tuettujen fyysisten medioden ominaispiirteet ja niihin liittyvät tiedon formaatit. 2.5.13 Osa13: Print Management Point-to-Point Communication Support [DICM/13] (Tulostuksen hallinnan tuki) Määrittelee palvelut ja protokollat, jotka ovat tarpeellisia DICOM:n tulostuksen hallinnassa. Tämä osa perustuu läheisesti DICOM:n omaan "Point to Point" -protokollaan (ks. 2.5.9) ja on näin myös siltä osaltaan hieman vanhentunut. 2.5.13.1 Osa14: Grayscale Standard Display Function [DICM/14] (Standardoitu funktio harmaasävyjen esittämiseksi) Osa 14 on DICOM:iin vuoden 2000 alkuun mennessä tehty viimeisin lisäys. Se pyrkii määrittelemään standardoidun tavan harmaasävykuvien esittämiseen. Lisäksi se esittää esimerkkejä kuvausjärjestelmän sovittamiseksi määriteltyyn funktioon. 2.6 DICOM:n tulevaisuus DICOM:n asema lääketieteellisen kuvantamisen ykkös-standardina on tällä hetkellä selvä. Standardi on saavuttanut paitsi laitevalmistajien, myös kuvausalan asiantuntijoiden suosion ympäri maailmaa. Useat muutkin lääketieteellisen kuvauksen standardoimisjärjestöt, kuten japanilainen JIRA (Japanese Industry Association for Radiation Apparatus) ja Eurooppalainen CEN TC 251 ovat ottaneet DICOM:n omien standardiensa ja suositustensa pohjaksi. Tästäkään huolimatta ACR-NEMA:lla ei ole varaa levätä laakereillaan. Lähi tulevaisuuden haasteina DICOM:lla on ennen kaikkea multimedian liittäminen mukaan kuvaan. Ongelmia on tuottanut myös 3D - kuvaus, vaikkakin DICOM:n nykyiset versiot periaatteessa tukevatkin sitä. Työtä tehdäänkin tällä hetkellä eritoten 3D-ultraääni objektien, MPEG:n ja moni osaisten kuvien tuen parantamiseksi. Myös datan turvallisuutta 25.10.03 24/53

yritetään parantaa kehittämällä tukea mm. Digitaalisille allekirjoituksille. Vaikka DICOM voikin turvallisin mielin katsella uudelle vuosituhannelle, riittää sille tulevaisuudessakin haasteita. Levitäkseen edelleen ja säilyttääkseen asemansa, sen tulee pystyä ennakoimaan tulevaisuuden tarpeet riittävän ajoissa ja myös vastaamaan niihin riittävän nopeasti. Tämä on vaikea tehtävä nykyisenä tietotekniikan "salamakehityksen" aikakautena. DICOM:lla on kuitenkin hallussaan samat valttikortit, jotka nostivat sen aikanaan yleiseen suosioon: avoimuus, joustavuus ja tarkkaan mietitty muutokset kestävä rakenne. Mikäli nämä asiat pidetään edelleen mielessä standardia uudistettaessa ja kehitettäessä, ei ole mitään epäselvyyttä siitä etteikö DICOM selviäsi voittajana tälläkin vuosituhannella. 25.10.03 25/53

3. DICOM3 KUVA-TIEDOSTON RAKENNE JA OSAT 3.1 DICOM-tiedosto - mutkikas palapeli DICOM on monessa suhteessa väljä standardi. Tämä pätee myös tiedosto formaattiin. Standardi ei sinänsä määrää tarkkaan tiedoston koostumusta, vaan tarjoaa kuvalle tarvittavat rakennuspalikat ja asettaa rajat sille, mitä palikoita kunkin tyyppisessä kuvassa voi olla. Itse asiassa DICOM kuvatiedosto ei ole sen kummallisempi otus, kuin kasa tälläisiä rakennuspalikoita (data-alkioita) tietyssä järjestyksessä. Data-alkiot puolestaan sisältävät tietoja kuvasta, kuvatusta potilaasta, sekä tietenkin varsinaisen kuvan pikselidatan. DICOM -tiedosto eroaakin normaaleista kuvista juuri siinä, että itse kuvatiedostossa on muutakin kuin pelkkiä pikseleitä. Toivon mukaan seuraava leikkimielinen vertaus selventää hiukan DICOM kuvan rakennetta :-). Ajatellaanpa DICOM tiedostoja vaikkapa palapeleinä, joita kootaan suuresta määrästä erityyppisiin palapeleihin sopivia palasia (dataalkiota). Kokoamisohje (DICOM standardi) määrittelee kaikki käytettävissä olevat palaset ja ryhmittelee sekä yksilöi ne. Kokoamisohje määrää myös tietyt pakolliset palaset, jotka kaikissa ja toisaalta tietyntyyppisissä palapeleissä on oltava. Lisäksi se määrää palasten järjestyksen. Sen sijaan se ei rajoita palapelin palasten kokonaismäärää tai sitä, mitä valinnaisia palasia kokooja haluaa palapelissään käyttää. Jos edellinen ajatusleikki meni "yli hilseen" ei vielä kannata tässä vaiheessa masentua ja heittää tätä selvitystä mappi-ö:n. Vertauksen tarkoituksena oli lähinnä antaa lukijalle jonkinmoinen kokonaiskäsitys asiasta, joka auttaa pysymään selvillä siitä missä mennään, kun seuraavissa kappaleissa pureudutaan tiedoston rakenteen yksityiskohtiin. 3.2 DICOM tiedoston perusosat ("palapelin" kehykset) Kaikista DICOM tiedostoista voidaan erottaa kaksi rakenteellista perusosaa: DICOM File Meta Information ja DICOM Data Set 25.10.03 26/53

Kuva 3.1 Dicom tiedoston perusosat [DICM/10] Tämä rakennemalli vastaa DICOM kommunikaatio mallissa käytettyä viestin rakennetta (ks. 2.5.7). Nyt vain "Command Set":n korvaa DICOM File Meta information. Kuten "Command Set":kin myös File Meta Information ryhmä sisältää Data Set:in lukemisessa tarvittavaa tietoa. Tällä tavalla DICOM ikään kuin kehystää tallennettavan datan liittämällä jokaiseen tiedostoon mukaan datapaketin siitä itsestään. On kuitenkin huomattava että "kehystäminen" ei tässä tapauksessa tarkoita tiedoston pituuden vakioittamista, vaan sekä "File Meta Information" että Data Set:n pituus (ja tietenkin tiedoston kokonaispituuskin) voi vaihdella kuten jatkossa tullaan huomaamaan. Seuraavissa kappaleissa on käyty läpi tarkemmin sekä Data Set että File Meta Information. Vaikka käsittely järjestys saattaa tuntua hieman takaperoiselta (Data Set:hän on DICOM tiedostossa vasta File Meta Information osan jälkeen ), se on perusteltavissa sillä, että File Meta Information osan ymmärtäminen ja käsittely ennen Data-Set:in käsittelyä olisi hankalampaa. 3.3 DICOM Data Set ("palapelin" kuvapalikka ja sen tieto palaset) DICOM tiedoston varsinainen sisältö on tallennettu Data Set:iin Juuri Data Set sisältää tiedot potilaasta, kuvauslaitteistosta, kuvatyypistä jne. Data Set sisältää myös itse kuvan pikselit yhtenä data-alkiona (Pixel Data). 3.3.1 Data-alkiot ("palapelin" palaset) Data Set:in ja DICOM tiedoston perustana Data Set koostuu data-alkioista ("palapelin" palaset) (data elements). Data-alkion koostumusta on selvitetty seuraavassa kuvassa. 25.10.03 27/53

Kuva 3.2 Data Set,Data-alkio (Data Element) ja sen kentät[dicm/5] Data-alkiot rakentuvat osasista joita kutsutaan kentiksi(fields). Seuraavissa kappaleissa on käsitelty kukin kentistä lyhyesti. Tarkempia tietoja data-alkion kenttien sisällöstä ja eri rakenne vaihtoehdoista löytyy DICOM-standardin osasta 5 [DICM/5] (7.1.1). 3.3.1.1 Data-alkion kentät 3.3.1.1.1 Tagi (Tag) kenttä Kaikilla data-alkioilla (ja informaatio-objektin atribuuteilla) on oltava yksilöllinen tunnistekenttä eli Tagi (Tag). Tagi on järjestetty pari 16 bittisiä etumerkittömiä (ei negatiivisia) lukuja. Tagin ensimmäistä numeroa sanotaan ryhmänumeroksi (Group Number) ja toista osaa alkionumeroksi (Element Number). Esim. data-alkion "Patient name" Tagi on (heksalukuna) (0010,0010). DICOM tiedostoissa ei siis ole data-alkion yhteydessä alkion nimeä vaan ainoastaan (binääri muotoinen) tagi, josta tiedostoa käsittelevät ohjelmat tietävät mitä alkiota ne juuri ovat lukemassa. Koska data-alkioita on paljon on luonnollista järjestellä niitä tiedostossa jollain järkevällä tavalla. Helpoimman tavan järjestämiseen tarjoaa juuri Tagi. Tagin ryhmänumero jakaa dataalkiot ensin ryhmiin. Ensimmäisenä tiedostossa tulevat ryhmät joiden Tagin ryhmänumero on pienin. Esim 0008 ryhmänumeron omaavat data-alkiot tulevat ennen 0010 ryhmää jne. Alkionumero taas määrää järjestyksen ryhmän sisällä. Näin esimerkiksin Tagin (0008, 0060) (Modality) omaava data-alkio on tiedostossa ennen data-alkiota (Manufacturer) jonka Tagi on (0008, 0070) 3.3.1.1.2 Value Representation -kenttä Value Representation on 2 tavua pitkän merkkijonon sisältävä kenttä,joka kertoo minkätyyppistä dataa data-alkion arvokenttä (value field) 25.10.03 28/53

sisältää. Tiedoston Transfer Syntax ominaisuus (käsitelty myöhemmin) määrää onko data-alkiossa Value Representation kenttää vai ei. 3.3.1.1.3 Value Length -kenttä Value Length -kenttä (16 tai 32 bit) määrittää arvokentän pituuden tavuina tai jos arvokentän pituus on määrittelemätön, se sisältää luvun FFFFFFFF. 3.3.1.1.4 Arvokenttä eli Value Field Arvokenttä sisältää varsinaisen data-alkion arvon. Pääosin tiedoston "Transfer syntax" -ominaisuudesta riippuu se, miten arvokentän binääridata on koodattu. Arvokenttä sisältää kuitenkin aina parillisen määrän tavuja ja tästä syystä saatetaan arvokentän loppuun toisinaan joutua liittämään ylimääräisiä bittejä. 3.3.1.2 Data-alkion yleinen rakenne ja VR eli Value Representation Edellä oli puhetta data-alkion kenttärakenteesta. Samassa yhteydessä esiteltiin jo Value Representation- eli VR-kenttä, joka tavallaan ilmaisi data-alkion arvokentän rakenteen. VR:llä on kuitenkin DICOM:n data-alkioiden tulkinnan kannalta paljon VR-kenttää laajempikin merkitys. Se määrää tavallaan koko data-alkion rakenteen. Ts. data-alkion rakenne riippuu siitä, minkätyyppinen VR siinä on käytössä. VR-ää on periaatteessa kahta tyyppiä Eksplisiittinen VR (Explicit VR) ja Implisiittinen VR (Implicit VR). Seuraavissa suoraan DICOM:sta lainatuissa taulukoissa on esitetty data-alkion rakenteen erot eri VR:lle [DICM/5](Tables 7.1-1 7.1-3) 25.10.03 29/53

Kuva 3.3 Data-alkion rakenne eksplisiittisen VR:n yhteydessä (DICOM tables 7.1-1 ja 7.1-2 [DICM/5]) Kuva 3.4 Data-alkion rakenne implisiittisen VR:n yhteydessä (DICOM table 7.1-3) 3.3.2 Data Setin data-alkiot jaotellaan ominaisuusryhmiin Kukin data-alkio liittyy aina johonkin DICOM:n määrittelemään "informaatio-objektiin". Esim. edellä esimerkkinä mainittu "Patient name" alkio liittyy "Patient" infromaatio-objektiin. Informaatioobjekti on standardin määrittelemä kuvaustapahtumaan ja informaation kulkuun jollain tavalla vaikuttava osatekijä. 25.10.03 30/53

DICOM standardin 3:s osassa [DICM/3] määritellään useimmat informaatio-objektit ja niihin liittyvät data-alkiot. Yksittäiset informaatio-objektitkin ovat kuitenkin vielä melkoisen laajoja. Esimerkiksi "Patient" informaatio-objektiin liittyy satoja data-alkioita. Tästä johtuen on aivan selvää että data-alkioiden sujuvaa määrittelyä varten informaatio-objektitkin on pilkottava pienemmiksi kokonaisuuksi. Tällä tavoin saatuja ryhmiä kutsutaan DICOM:ssa nimellä "Information Object Module" eli lyhyesti suomennettuna ominaisuusryhmiksi Ominaisuusryhmän jäseniä taas kutsutaan virallisesti ko. informaatio-objektin attribuuteiksi. Nyt lukija saattaa ihmetellä, miten data-alkiosta tulikin yht äkkiä ominaisuusryhmän attribuutti? Itse asiassa nämä DICOM:n ominaisuusryhmiensä yhteydessä määrittelemät attribuutit ovat juuri niitä tutun "tiedosto palapelimme" palikoita data-alkioita, mutta niille vain ei ole vielä annettu arvoja. DICOM standardi ei siis määrittele [DICM/3] tarkasti ottaen dataalkioita, vaan "Informaatio - objekteja" ja niiden attribuutteja, joita tiedostossa ollessaan kutsutaan data-alkioiksi, kun niillä on joku arvo. Tässä selvityksessä puhun kuitenkin tuttavallisesti aina data-alkioista (silloinkin kun kyseessä virallisesti olisi informaatio objektin attribuutti) lukijalle muutoinkin varmasti käsittämätöntä termisekasotkua helpottaakseni. Seuraavissa kappaleissa on käyty läpi muutamia tärkeimpiä "DICOM Data Set:in" ominaisuusryhmiä ja niiden data-alkioiden määritelmiä. Koska data-alkioita ja ominaisuusryhmiä on paljon!!!, ei tässä ole mitään mieltä lähteä käsittelemään niitä kaikkia. Tavoitteena on lähinnä antaa lukijalle kuva siitä, mitä kaikkea DICOM -tiedosto voi sisältää. Jos asia ei Sinua kiinnosta, voit huoletta hypätä kappaleeseen 3.4. Toisaalta lisää luetteloja informaatio-objekteista ja vastaavien data-alkioiden määritelmistä on saatavissa n. 300 sivun verran DICOM standardin osasta 3 [DICM/3] (Suosittelen erityisesti unettomuudesta kärsiville :-) ) 3.3.2.1 Kuvan ominaisuuksiin liittyvät data-alkiot Kuvan ominaisuuksiin liittyvät data-alkiot ovat tiedoston muuntamisen kannalta tärkeitä koska tätä kautta päästään käsiksi kuvan kokoon, kuvatiedostossa olevien "yksittäisten kuvien määrään" sekä kuvan väritykseen. Monet DICOM-tiedostoja muuntavat ja käsittelevät ohjelmat lukevatkin vain tämän osion tietoja kuvan koosta ja bittien määrästä, koska muilla ei juurikaan ole merkitystä muunnosprosessin kannalta [Chris]. Seuraavissa on kappaleissa taulukoituna muutamia tärkeimpiä ominaisuusryhmiä ja niihin liittyviä data-alkoita. 25.10.03 31/53

3.3.2.1.1 "General Image Module Atribuutin (data-alkion) nimi: Tagi: Esim. arvo Atribuutin kuvaus: (tunniste) Instance Number 0020,0013 --- Numero joka yksilöi kuvan Patient Potilaan "asento" suhteessa kuvan Orientation 0020,0020 --- tasoon. Asentoa kuvataan kahdella arvolla jotka kuvaavat anatomista suuntaa. ( Positiivinen Vaaka-akseli (vasemmalta oikealle) ja Positiivinen Pystyakseli (ylhäältä alas)). (Ks.[DICM/3](C.7.6.1.1.1)) (pakollinen jos varsinaisen kuvatyypin data-alkioissa ei vastaavaa) Image Date 0008,0023 --- Päivämäärä jolloin kuvadatan generointi alkoi. (pakollinen ajallisisti sarjassa peräkkäin olevissa kuvissa) Image Time 0008,0033 --- Aika jolloin kuvadatan generointi alkoi. (ks. Image Date) data-alkio joka yksilöi tärkeitä Image Type 0008,0008 --- kuvan tunnistamista auttavia piirteitä. (ks. [DICM/3](C.7.6.1.1.2)) kertoo onko kuva pakattu 25.10.03 32/53

Lossy Image Compression Lossy Image Compression Ratio 0028,2110 --- hävittävällä pakkausalgoritmilla. Mahdolliset arvot: 00 = kuvaa ei pakattu hävittävällä pakkausalgoritmilla. 01 = kuva on pakkattu hävittävällä pakkausalgoritmilla. 0028,2112 --- Kertoo (hävittävällä pakkausalgoritmilla pakatun) kuvan arvioidu pakkaussuhteen. Taulukko 3.1 "General Image Module "ominaisuusryhmän tärkeimmät data-alkiot. [DICM/3](table C.7-7) 3.3.2.1.2 "Image Pixel module " Atribuutin nimi: Tagi: Esim. arvo Atribuutin kuvaus: (DICOM 3 standardissa) (tunniste) Erillisten tasojen lukumäärä Samples per Pixel 0028,0002 1 kuvassa. Standardissa määriteltyjä arvoja ovat 1, 3 tai 4 tasoa. Mustavalkoisissa (harmaasävy) kuvissa tasojen lukumäärä on yleensä 1. RGB kuvissa 3. Photometric 0028,0004 MONOCHR Määrittelee pikselin tulkintatavan. Interpretation OME2. Rows 0028,0010 109 Kuvassa olevien (vaaka)rivien lukumäärä. Columns 0028,0011 91 Kuvassa olevien sarakkeiden (pystyrivien) lukumäärä. 25.10.03 33/53

Bits Allocated 0028,0100 8 Varattujen bittien lukumäärä (tasoa) näytettä (sample) kohti (yleensä Bits Allocated = Bits Strored) Bits Stored 0028,0101 8 Käytettyjen bittien lukumäärä tasoa (näytettä) (sample) kohti High Bit 0028,0101 7 Eniten merkitsevä bitti pikseli Pixel Representation Pixel Data 7FE0,0010 ---- datassa 0028,0103 0 Pikseli näytteiden (tasojen) (19838 bytes) kuvaama data. Jokaista näytettä vastaa sama kuvaus. Mahd. Arvot: 0000H=etumerkitön kokonaisluku 0001H=kakkosen komplementti Varsinainen kuvadata Taulukko 3.2 " Image Pixel module " ominaisuusryhmän tärkeimmät data-alkiot. [DICM/3](table C.7.9) 3.3.2.1.3 "Multi-Frame Module " Atribuutin nimi: (DICOM 3 standardissa) Tagi: (tunniste) Esim. arvo Atribuutin kuvaus: Number of Frames 0028,0008 2 Ilmaisee kuvatiedostoon sisältyvien "erillisten kuvien" lukumäärän. Taulukko 3.3 " Multi-Frame Module" ominaisuusryhmän tärkeimmät data-alkiot. [DICM/3](table C.7-12) 25.10.03 34/53

3.3.2.1.4 "Image plane module " Atribuutin nimi: (DICOM 3 standardissa) Tagi: (tunniste) Esim. arvo Atribuutin kuvaus: Pixel Spacing 0028,0030 2.00\2.00 Fyysinen etäisyys potilaassa /mm vastataten kahden pixelin välistä etäisyyttä /mm Slice Thickness 0018,0050 2.00 Nimellinen "siivun" paksuus /mm Taulukko 3.4 " Image plane module " ominaisuusryhmän tärkeimmät data-alkiot. [DICM/3](table C.7-8) 3.3.2.2 Potilastietoihin liittyvät ominaisuusryhmät Kuten aiemmin jo todettiin DICOM-tiedosto sisältää varsinaisen kuvadatan ja sen ominaisuus tietojen lisäksi informaatiota myös potilaasta. Nämä tiedot eivät ole tärkeitä itse DICOM-muunnos prosessin kannalta, mutta niillä oma keskeinen merkityksensä potilaan tietosuojan ja yksilöimisen kannalta. Siksi tässä käsitellään lyhyesti tärkeimmät potilastietoihin liittyvät ominaisuusryhmät, jotka on sisällytetty DICOM3 tiedosto formaattiin. 3.3.2.2.1 "Patient identification module " Tästä ominaisuusryhmästä (0010, osittain) löytyy potilaan tunnistetiedot. "Patient identification modulin" data-alkioita ovat mm. potilaan nimi, henkilötunnus jne. Ko. kentän data-alkiot on listattu seuraavassa taulukossa: Atribuutin nimi: (DICOM 3 standardissa) Tagi: (tunniste) Esim. arvo Atribuutin kuvaus: Patient's Name 0010,0010 ---- Kuvatun potilaan nimi. Patient's ID 0010,0020 --- Ensisijainen potilaan 25.10.03 35/53