DICOM3

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

TTKK(PKY) Selvitys DICOM3 tiedostoformaatista Versio 1.1 

25.10.03 2/53


VERSIOHISTORIA 

Versio Päiväys 

(valm. pv 

1.0 

lihavoitu) 

26.6 -18.7 

1.1 

31.7 - 21.8 

Tekijät Selite (muutokset, korjaukset...) 

Juha Lähteenmäki 

Juha Lähteenmäki 

Ensimmäinen kommentoitavaksi 

jaeltava versio 

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 

1.1.1 Varoitus! :-) 

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)) . 

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: Selitys 

ACR 

ACSE 

American College of Radiology 

OSI Association Control Service Element 

Atribuutti (attribute) Tarkenne, ominaisuus (tässä eritoten tietyn ominaisuusryhmän 

Big Endian 

yksittäinen jäsen) 

Binääridatan koodaustapa 

CT 

Data-alkio (Data 

Element) 

Datajoukko (Data 

Set) 

DICOM / DICOM3 / 

DICM3 /DICM 

DIMSE 

"draft"-versio 

GIF 

HYTT 

IEC 

Information Object / 

"informaatio objekti" 

IOD 

ISO 

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. 

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ä 

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ä = 

module) 

OB 

OSI-malli 

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ä informaatio- 

objektin samankaltaisia atribuutteja (data-alkioita). Yhdellä 

informaatio-objektilla on usein monta eri ominaisuusryhmää (modules). 

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 OSI Upper Layer Service 

OW 

PIXEL CELL: 

(pikselisolu) 

PIXEL DATA 

(pikselidata) 

PKY 

RGB 

RLE 

SOP 

Service-Object Pair 

(SOP) Instance: 

STN 

"syntaksi" 

Tagi / Tag 

TIFF (TIF) 

TTKK 

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 

Informaatio objektin ja kommunikaatio käsitteen käytännön ilmentymä.. 

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 

Taulukko 1.2 Dokumentissa käytettävät merkintätavat. 

1.3 Viitteet 

lihavointia ja kursivointia on 

käytetty ainoastaan selvennys 

tarkoituksessa 

viittaukset 

tarkennukset 

vaihtoehtoinen tapa 

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


[Dokuty98] 

[EDU] 

[LukuX] 

[NEMA] 

[DICM/status] 

[OSI] 

1.4 Dokumentin rakenne 

1999) osa X 

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 

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 

1988 

Standardin ensimmäinen versio valmistuu. Tämä 

ACR-NEMA standardi ei kuitenkaan saavuta laajaa 

suosiota. 

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


1991 

1993 

1994 

1995 

1998 

Taulukko 2.1 DICOM -standardin kehitysvaiheet. 

2.4 DICOM:n kommunikaation malli 

Medical Imaging Application 

versioista standardi päätetään nimetä DICOM:ksi 

Ensimmäiset DICOM-standardin osat (1 ja 8) 

valmistuvat 

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 

Liite 1 (Supplement 1) eli käytännössä osa 10, (part 

10 Media Storage and File Format) valmistuu 

Liitteet 2, 3 ja 4 (Parts 11, 12 , 13) valmistuvat 

Tällä hetkellä viimeisin Liite 5 (Part 14) valmistuu 

DICOM Application Entity (DICOM sovellusyksikkö) 

Service Class specifications 

Information Object Definitions 

Data Structure and Encoding 

File Format Message Exchange 

DICOM File service 

Media format and physical 

media specifications 

Off Line Communication 

DICOM Session/ 

Transport / 

Profile 

STN 

DICOM 

DataLink 

DICOM 

Physic. (50 pin) 

OSI ULS (OSI Upper layer service) -rajapinta 

DICOM UpperLayer 

Protocol for TCP/IP 

ACSE 

OSI Presentation Kernel 

OSI Session Kernel 

OSI Transport 

OSI Network 

LLC (Link) 

Kuva 2.1 DICOM:n kommunikaation malli ja tuetut kommunikaatio protokollat. 

25.10.03 18/53 

TCP 

IP 

Standard network physical layer 

(Ethernet, ISDN ...etc) 

"Point to Point" -Ympäristö Verkko -Ympäristö 

On Line Communication


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 

Confor- 

mance 

Osa 14 

(liite 5) 

Graysc. 

Stand. 

Disp. 

Funct. 

Osa 8 

(Comm.Network 

Support) (OSI) 

Osa 4 Service Classes Specification 

Osa 3 Information Objects 

Osa 6 

Data Dictionary 

Osa 7 

Message Exchange 

Osa 9 

(Comm.Point 

to Point..) 

Osa 5 

Data Structures 

Osa 13 (liite 4) 

(Print Man. 

Point to Point..) 

Osa 10 (liite 1) 

(Storage Media 

and File Form.) 

Part 12 (liite3) 

(Media formats 

and fys. media) 

Osa 11 

(liite2) 

Media 

storage 

Appli- 

cation 

Profiles 

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: 

(tunniste) 

Esim. arvo Atribuutin kuvaus: 

Instance Number 0020,0013 --- Numero joka yksilöi kuvan 

Patient 

Orientation 

0020,0020 

--- 

Potilaan "asento" suhteessa kuvan 

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 kuva- 

tyypin 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 

Image Type 

0008,0008 

--- 

alkoi. (ks. Image Date) 

data-alkio joka yksilöi tärkeitä 

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. 

0028,2112 

--- 

Mahdolliset arvot: 

00 = kuvaa ei pakattu hävittävällä 

pakkausalgoritmilla. 

01 = kuva on pakkattu 

hävittävällä 

pakkausalgoritmilla. 

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: 

(DICOM 3 standardissa) 

Samples per Pixel 

Photometric 

Interpretation 

Tagi: 

(tunniste) 

0028,0002 

0028,0004 MONOCHR 


1 

OME2. 

Erillisten tasojen lukumäärä 

kuvassa. Standardissa määriteltyjä 

arvoja ovat 1, 3 tai 4 tasoa. 

Mustavalkoisissa (harmaasävy) 

kuvissa tasojen lukumäärä on 

yleensä 1. RGB kuvissa 3. 

Määrittelee pikselin tulkintatavan. 

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 " 



Number of Frames 

Tagi: (tunniste) Esim. arvo Atribuutin kuvaus: 

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. 


25.10.03 34/53


3.3.2.1.4 "Image plane module " 



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. 


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 " 



Patient's Name 

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: 


0010,0010 

---- 

Kuvatun potilaan nimi. 

Patient's ID 0010,0020 --- Ensisijainen potilaan 

25.10.03 35/53


tunnistenumero (esim. Henk. 

tunnus) 

Taulukko 3.5 "Patient identification module " ominaisuusryhmän tärkeimmät dataalkiot. 


3.3.2.2.2 "Patient Demographic Module " 

Tämän ominaisuusryhmän data-alkiot sisältävät tiedot potilaan iästä, 

siviilisäädystä , syntymäajasta, painosta jne. 

Tarkemmat tiedot tämän ryhmän data-alkioista löytyy taulukosta C.2- 

3 DICOM -standardin osasta 3 [DICM/3] (table C.2-3) 

3.3.2.2.3 "Patient Medical Module " 

Tästä ominaisuusryhmästä löytyy tietoa potilaan sairauksista, 

allergioista, lääkityksestä jne. 

Tarkemmat tiedot tämän ryhmän data-alkioista löytyy taulukosta C.2- 

4 DICOM -standardin osasta 3 [DICM/3] (table C.2-4) 

3.3.2.3 Kuvaustavasta 

ilmaiseminen 

riippuvat data-alkiot ja kuvaustavan 

Edellä on käsitelty tärkeimpiä DICOM-muotoiseen tiedostoon 

mahdollisesti upotettuja tietoja ominaisuusryhmittäin. Kyseiset 

ominaisuusryhmät ovat löydettävissä miltei kaikentyyppisissä 

DICOM3 tiedostoista. DICOM muotoisissa kuvissa on kuitenkin vielä 

paljon muutakin tärkeää tietoa, riippuen siitä minkä tyyppinen kuva 

on kyseessä. 

3.3.2.3.1 Imaging modality (0008,0060) 

Imaging modality data-alkio (Tag: 0008,0060) on keskeinen DICOM 

tiedoston rakenteen kannalta, sillä siitä riippuu minkä tyyppisiä tietoja 

standardi kuvalta edellyttää Standardin osassa 3 kappaleessa 

C.7.3.1.1.1 [DICM/3] (C.7.3.1.1.1) on listattu Imaging modality:n 

kaikki mahdolliset arvot. Seuraavassa taulukossa muutamia 

tärkeimpiä. Sivunumerot viittaavat DICOM-standardin sähköiseen 

versioon osaan 3 [DICM/3] joka on pdf-muodossa tämän dokumentin 

liitteenä. 

HUOM. Ensimmäiset sivunumerot viittaavat sivun ylälaidassa ja 

sisällysluettelossa oleviin sivunumeroihin, jälkimmäiset taas pdftiedoston 

sivunumeroihin 

25.10.03 36/53


Arvo ja sen selite sivut ja viitteet: [DICM/3] 

CT = Computed Tomography Table C.8-3 

CT IMAGE MODULE 

MR = Magnetic Resonance 

ATTRIBUTES (s. 181 - 183)(196 

- 198) 

Table C.8-4 

MR IMAGE MODULE 

NM = Nuclear Medicine 

ATTRIBUTES (s. 184 - 188) 

(199 - 203) 

Table C.8-9 

NM IMAGE MODULE 

ATTRIBUTES (s.189-214)(204 - 

229) 

RTIMAGE = Radiotherapy Image Table C.8-34—RT IMAGE 

US=Ultrasound 

MODULE ATTRIBUTES (s.259 - 

266) (274 - 281) 

Table C.8-18 

US IMAGE MODULE 

ATTRIBUTES 

(s.215 -235) (230 - 250) 

Taulukko 3.6 Joitakin Imaging Modality:n sallittuja arvoja sekä viitteet standardin 

kohtiin josta löytyy selvitys minkätyyppiset data-alkiot mahdollisia 

3.4 DICOM File Meta Information ("palapelin" purkamis ohjeet) 

DICOM -standardi määrittelee kaikille standardin mukaisille 

tiedostoille ainakin yhden yhteisen ja pakollisen osan: DICOM File 

Meta Information. Myös File Meta Information koostuu 

samantyyppisistä data-alkioista kuin Data Set- osakin. Erona on 

ainoastaan että File Meta Information -ryhmän data-alkiot eivät 

sisälläkkään tietoa kuvasta, vaan itse tiedostosta ja siitä miten 

tiedoston Data Set osaa pitäisi lukea. Tätä tietoa tarvitaan tiedoston 

Data-Set:n tulkitsemisessa. File Meta Information -ryhmällä on myös 

tärkeä merkitys tiedoston muodon varmentamisessa. Seuraavassa 

25.10.03 37/53


Atribuutin(data- 

alkion) nimi: 


File Preamble 

Dicom Prefix 

Group Length 

File Meta 

Information 

Version 

Transfer Syntax 

taulukossa on listattu tyypillisimpiä (kaikkiaan 12:sta mahdollisesta) 

File Meta Information -ryhmän data-alkiosta ja niiden kuvauksia. 

Lisäksi kutakin data-alkiota vastaten on listattu sen tunniste eli Tagi 

(jos sellainen on ) ja myös joku yleinen esim. arvo. 

Tagi: 

(tunniste) 

--- 

--- 

0002,0000 

0002,0001 

0002,0010 


(00H) 

"DICM" 

132 

256 

1.2.840. 

Kuvaus tiedoston erityisestä 

käyttötavasta. Ei yleensä käytössä 

DICOM -tiedostoissa (silti 

pakollinen). Jos osaa ei käytetä 

kaikki tavut pitäisi asettaa arvoon 

00H. (pituus kiinteä 128 tavua) 

Tunniste DICOM tiedoston 

tunnistamista varten. Jos tiedosto 

on DICOM tiedosto tunniste 

sisältää merkkijonon: "DICM" 

(pakollinen kaikissa DICOM3 - 

Standardin mukaisissa tiedostoissa) 

(pituus kiinteä 4 tavua) 

Ilmaisee ryhmään "File Meta 

information" kuuluvien tavujen 

lukumäärän itsensä jälkeen 

2 tavua pitkä kenttä, joka ilmaisee 

ko. DICOM -tiedoston (File Meta 

Information osan ) version 

Määrittelee DICOM-tiedoston data 

25.10.03 38/53


UID 10008.1.2.1. osion koodaus "syntaksin" 

(mahdolliset arvot listattu 

seuraavassa kuvassa). (Oletus 

syntaksina on implisiittinen VR 

Little Endian) Syntaksilla on suora 

vaikutus siihen, miten kuvan 

Pikselidataa käsitellään.Yleisimmät 

syntaksit on listattu alapuolella. 

Taulukko 3.7 "DICOM File Meta Information " ryhmän tärkeimmät data-alkiot. 

(kaikkiaan 12:sta mahdollisesta) [DICM/10](table 7.1-1) 

3.5 Data-alkioiden koodaus ja pakkaus 

Kun DICOM tiedoston osaset "palapelin" palat on vihdoin saatu 

käsiteltyä, on aika kurkistaa hieman palan (data-alkion) varsinaiseen 

sisältöön eli arvoon. Jotta tämä arvo olisi ilmaistavissa 

yksikäsitteisesti se täytyy koodata jollain tavalla. Binääri datan 

koodaukseen on yleisesti ottaen olemassa kaksi tavallista vaihtoehtoa: 

Big Endian ja Little Endian. 

3.5.1 Big Endian ja Little Endian (Tavujen järjestely Datan 

koodauksessa) 

Little Endian (Tavallisin DICOM3:ssa) koodauksessa useamman 

tavun kokonaisluvut (16bit ,32bit,...) koodataan niin, että vähiten 

merkitsevä (least significant) tavu koodataan ensin ja sitten 

merkisevyysjärjestyksessä seuraava jne. (merkitsevyys lisääntyy 

loppua kohti) 

Merkkijoissa (jotka sisältävät Useita 8 bit. yksittäisiä tavuja) taas 

kirjaimet koodataan esiintymisjärjestyksessä (vasemmalta oikealle) 

Big Endian koodauksessa useamman tavun kokonaisluvuissa 

koodataan eniten merkitsevä tavu ensin ja sitten 

merkitsevyysjärjestyksessä seuraava jne. (merkitsevyys vähenee 

loppua kohti). Merkkijonoissa noudatetaan samaa koodaustapaa kuin 

Little Endian koodauksessa. 

25.10.03 39/53


3.5.2 DICOM-tiedoston syntaksi 

Mm. se kumpaa tavukoodausta (Little Endian vai Big Endian) 

DICOM-tiedostossa käytetään selviää tiedoston "syntaksista". Käytän 

tässä lainausmerkkejä sanan syntaksi ympärillä koska termi on 

virallisesti "transfer syntax" eli sananmukaisesti "lauseoppi siirrosta" 

:-) . Kyseessä on kuitenkin oikeastaan DICOM -tiedoston dataalkioiden 

"koodaustapa" joka ilmaisee miten tiedoston dataa tulisi 

tulkita. Yleisimmät DICOM:n tukemat syntaksit on listattu alla 

olevassa kuvassa. 

Kuva 3.5 DICOM "transfer syntaxes"[Barre] Pakattuun DICOM -formaattiin 

liittyvät syntaksit on ilmaistu kuvakkeella . 

25.10.03 40/53


3.5.3 Pikselidata 

Syntaksi ilmoitetaan tiedoston ryhmän " DICOM File Meta 

Information " "transfer syntax UID" data-alkiolla. Käytännössä siis 

data-alkio (0002,0010) määrää tiedoston tulkinnassa käytettävän 

syntaksin. 

DICOM -tiedostossa varsinaisen koodatun kuvadatan välitykseen 

käytetään Pixel Data Element (7FE0,0010) -data-alkiota (ts. kuvan 

pikselidata on alkiossa (7FE0,0010)). 

Pikselidata (Pixel Data) koostuu pikselialkioista tai pikselisoluista 

(Pixel Cell), joista kukin sisältää yksittäisen pikselin näytearvon. 

Image Pixel module –ominaisuusryhmän data-alkiot Bits Allocated, 

Bits Strored ja High Bit antavat pikselisolujen tulkintaan tarvittavat 

perustiedot. Bits Allocated (0028, 0100) ilmaisee varatut bitit , Bits 

Strored (Tag: 0028, 0101) käytetyt bitit ja High Bit (0028,) eniten 

merkitsevän bitin (Most Significant Bit). 

Pikselidata voi riippuen tiedoston syntaksista (Transfer syntax UID) 

olla joko pakattussa (Encapsulated format) tai pakkaamattomassa 

muodossa (Native Format) 

3.5.3.1 Pakkaamaton pikselidatan koodaus (Native) 

Pakkaamattoman pikselidatan VR:nä (Value Reprentation) käytetään 

yleensä yleensä OW:tä (ks. kuva 3.3). OB:tä voidaan käyttää 

ainoastaan kun data-alkion Bits allocated arvo on pienempi tai 

yhtäsuuri kuin 8, mutta silloinkin vain explisiittisen VR:n yhteydessä. 

Pikselisolut koodataan yksinkertaisesti liittämällä kunkin solun bitit 

yhteen siten, että seuraavan solun merkitsevin bitti seuraa aina 

edellisen solun vähiten merkitsevintä bittiä. (ks [DICM/5](8.2)) 

3.5.3.2 Pakatun pikselidatan koodaus (Encapsulated) 

Pakatun pikselidatan yhteydessä käytetään VR:nä aina OB:tä. 

Pakkauksen yhteydessä käytettävät koodaustavat on määritelty 

DICOM standardin osassa 5 [DICM/5](Annex A). Pakkaus 

algoritmina voidaan käyttää joko JPEG:iä (ks. [DICM/5](8.2.1)) tai 

RLE :tä (Run Length Encoding Compression) (Ks. [DICM/5] (8.2.2)). 

25.10.03 41/53


3.6 Esimerkki 

Päätämme tutkimusmatkamme DICOM -tiedosto palapelin 

ihmeelliseen maailmaan toivottavasti havainnolliseen esimerkkiin. 

Tarkastelun kohteena on tavallinen kaksiosainen MR-kuva. 

Kuva 3.6 DICOM- muotoinen kaksiosainen MR-kuva ja sen data-alkiot 

järjestyksessä, sellaisina kuin monet DICOM –muunnosohjelmat ne 

näyttävät [Chris]. Potilaasta kertovat data-alkiot (0010,xxxx) on 

jätetty yksilösuojan säilyttämiseksi pois. Huomaa että tavumäärät 

(794 bytes ja 19838 bytes) liittyvät vain ja ainoastaan esimerkki 

kuvaan. 

Käydään vielä läpi yo. kuvan sisältö. Aivan ensimmäiseksi on 

kuitenkin syytä todeta, että kuvassa 3.5 esitettäviä data-alkioiden 

nimiä ei todellisessa DICOM- tiedostossa tietenkään ole. Lisäksi 

kaikki data on luonnollisesti binääri-muodossa. 

Seuraavassa taulukossa on käyty läpi esimerkki kuvan kukin dataalkio 

ja se mitä ko. alkio kuvastamme kertoo. 

Data-alkion 

Tagi 

Mitä ko. alkio kertoo kuvasta 

25.10.03 42/53


---- (ens. 128 bytes) ---- 

(Ensimmäiset 128 tavua ovat useimmiten DICOM 

tiedostoissa käyttämättä ja ne voidaan hypätä yli) 

----(4 bytes 

merkkijono ’DICM’) 

Kertoo kuvatiedostomme olevan DICOM muotoa 

0002,0000 Kertoo ”File Meta information ” ryhmän pituuden 

olevan 132 tavua (lukuunottamatta tagitonta 

alkuosaa ja itseään) 

0002,0001 Kertoo tiedoston File Meta Information ryhmän 

versionumeron olevan 256 

0002,0010 Kertoo data-alkioiden koodaustavan olevan 

DICOM:n oletus syntaksi eli Implisiittinen VR, 

Little Endian. 

0008,0000 Kertoo 0008 ryhmän pituuden 152 tavua 

0008,0060 Kertoo kuvan olevan MR-kuva 

0008,0070 Kertoo että kuvan luoneen sovelluksen tai 

kuvauslaitteen valmistajana on toiminut MRIcro 

0018,0000 Kertoo 0018 ryhmän pituuden olevan 28 tavua 

0018,0050 Kertoo yhden ”kuvasiivun” paksuuden olleen 2 mm 

0018,1020 Kertoo kuvan luoneen softan versio tiedot 

0028,0000 Kertoo 0028 ryhmän pituuden olevan 148 tavua 

0028,0002 Kertoo näytteitä otetun 1/pikseli 

0028,0004 Väritys = harmaasävyt 

0028,0008 Kuva on 2 osainen (sis. erillisiä kuvia 2kpl) 

0028,0010 Kuvadatassa on 109 riviä 

0028, 0011 Kuvadatassa 91 saraketta 

0028,0030 Kuvan suurennus = 1:1 (ei tietenkään päde tälle 

pienennetylle versiolle ko. kuvasta) 

0028,0100 Varattujen bittien lukum /pikselisolu = 8 (1 tavu) 

0028,0101 Käytettyjen bittien lukum/pikselisolu = 8 (1 tavu) 

0028,0102 Eniten merkitsevä bitti = 7. 

0028,0103 Pikseleitä kuvaava binääridata unsigned integer 

tyyppiä 

0028,1052 (Rescale Intercept) b=0.00 tallennetun arvon(SV) ja 

Hounsfield(HU) suhteessa. HU =m*SV+b 

0028,1053 (Rescale Slope) m = 0,00392157 tallennetun 

arvon(SV) ja Hounsfield(HU) suhteessa. HU 

=m*SV+b 

7FE0,0000 Pikseli dataryhmän 7FE0 pituus 19850 tavua 

7FE0,0010 Sisältää varsinaisen kuvan eli pikseli datan 

Taulukko 3.8 Esimerkki kuvan analysointi 

25.10.03 43/53


4. SELVITYS DICOM3 -TIEDOSTON MUUNNOKSESTA 

DICOM- tiedoston muuntaminen on sinänsä yksinkertainen asia. 

Saatavana on valmiita ratkaisuja jopa selainpohjaisillekin 

tiedostomuuntimille tai DICOM-tiedostojen katseluohjelmille. 

Joitakin ongelmia muuntamiseen kuitenkin liittyy kuten pakatut 

tiedostoformaatit jne. DICOM-standardin vapaus, joka toisaalta on 

luonut edellytykset tiedostomuodon laajalle leviämiselle, tuo 

mukanaan myös omat haasteensa muunnosprosessille. 

4.1 Olemassa olevat DICOM katselu- ja muunnosohjelmat 

4.1.1 ImageJ 

DICOM -tiedostojen muuntamiseen ja katseluun on olemassa useita 

joko ilmaisia tai shareware -periaatteella jaeltavia apuohjelmia. 

Testasin kaikkiaan noin kymmenkunta tälläistä ohjelmaa. Seuraavassa 

on listattuna joitakin huomioita ja kokemuksia muutamasta mielestäni 

hyvästä ohjelmasta. 

Huom: Useimmat tässä mainitut ohjelmat ovat kaikkine lisätietoineen 

jne. tämän dokumentin sähköisessä liitearkistossa 

ImageJ on Java pohjainen ilmaisohjelma DICOM- ja muidenkin 

kuvaformaattien katseluun. Ohjelma pystyy lukemaan normaaleita 

pakkaamattomia DICOM-tiedostoja. ImageJ:llä pystyy suorittamaan 

myös pieniä kuvankäsittely operaatioita ja tallentamaan kuvia gif, tiff, 

jpeg ym. tiedostomuodoissa. Mainittakoon että Jpeg muunnoksessa 

muunnoksen laatu on asetettavissa. Jpeg muunnos ei kuitenkaan 

onnistu 16 tai 32 bit harmaasävy kuville (tosin muunnos tällöinkin on 

mahdollinen muuttamalla kuvan moodiksi ensin 8bit, jolloin laatu 

tietenkin hiukan kärsii). Myös lähdekoodi ja useita Plugin 

komponentteja on saatavilla. 

Lisätietoja ja ohjelmaa vastaava appletti testattavissa Web-sivulla: 

http://rsb.info.nih.gov/ij/ 

4.1.2 eViewBox ja JDicomViewer 

eViewBox on java-pohjainen ilmaisohjelma jolla voi katsella 

useitakin DICOM-kuvia kerralla jopa URL: osoitteen kautta. Kuvat 

25.10.03 44/53


pystyy myös muuntamaan gif-muotoon. JDicomViewer on saman 

kirjoittajan niin ikään Java-pohjainen ilmaisohjelma. JDicomViewer 

vastaa muuten eViewBox ohjelmaa paitsi että siinä kuvia voi olla 

kerralla auki vain 1 kpl. Myös vastaava appletti on saatavilla. 10$ 

hintaan yksityisille ja 200$ hintaan muille kirjoittaja lupaa myös 

lähdekoodin sekä vapaan oikeuden käyttää DICOM-decoder applettia 

osana Web-sivua. 

Lisätietoja EViewBox:ista: 

http://www.derhy.com/DICOM/EViewBox.html 

Vastaava appletti testattavissa osoitteessa: 

http://www.derhy.com/DICOM/JFR98/DicomApplet/DicomApplet.ht 

ml 

Lisätietoja JDicomViewer:istä osoitteessa: 

http://wwwusers.imaginet.fr/~sderhy/dicJava.html 

appletti testattavissa osoitteessa: 

http://wwwusers.imaginet.fr/~sderhy/DicomApplet.html 

4.1.3 MRIcro ja EzDicom 

MRIcro on helppokäyttöinen ja nopea windows-ilmaisohjelma 

DICOM- ja muidenkin kuva-tiedostojen katseluun, muokkaamiseen ja 

muuntamiseen. Ohjelma lukee melkein kaikkia DICOM-tyyppejä. 

DICOM-tiedostot voi myös muuntaa moniin yleisimpiin 

kuvaformaatteihin kuten: Jpeg, Bmp, Tiff jne. 

EzDicom on saman tekijän (ilmais)ohjelma joka on suunnattu 

enemmän varsinaisten DICOM-tiedostojen katseluun ja tulkintaan. 

Helppokäyttöisenä ja nopeana sopii erittäin hyvin DICOM - 

tiedostojen katseluun Windows:ssa. Myös DICOM -tiedoston 

muunnokset muihin kuvaformaatteihin käyvät helposti. 

Kumpikin EM. ohjelmista on pienikokoinen eikä vaadi asennusta. 

Toimivat kaikissa 32bit windows-ympäristöissä. Myös lähdekoodit 

EZDicom:iin ovat saatavilla. Vaikka helpit puuttuvatkin lähes 

kokonaan, erinomainen info tiedosto sekä ohjelmista että DICOM3 

tiedostoformaatista on saatavissa WWW:n kautta: 

http://www.mrc-cbu.cam.ac.uk/personal/chris.rorden/mricro.htm 

DICOM -infoa 

http://www.mrc-cbu.cam.ac.uk/personal/chris.rorden/dicom.htm 

25.10.03 45/53


4.1.4 Osiris 

Osiris on perustyökalu DICOM-tiedostojen katseluun, analysointiin ja 

muokkaamiseen. Osiris lukee ja kirjoittaa ainakin pakkaamattomia 

DICOM-, papyrys3 -, papyrys2- ja tiff- formaatteja. Ohjelma on 

ilmainen ja saatavana lähes kaikkiin ympäristöihin (Windows, Linux, 

Unix jne.) Kattava (joskin joiltain osin hieman vanhentunut) 

käyttöopas on saatavissa Web-sivulta: 

http://www.expasy.ch/www/UIN/html1/projects/osiris/osiris.html 

4.2 Yleisiä DICOM - muunnoksessa tarvittavia tietoja 

4.2.1 Data-alkioiden tunnistus 

DICOM-tiedosto koostuu ominaisuusryhmien attribuuttien arvoista eli 

data-alkioista. Kullakin data-alkiolla on yksilöllinen tunnisteosa eli 

Tagi (Tag) (ks. 3.3.1.1.1) Tagi on muunnosprosessin ja yleensäkin 

DICOM-tiedostojen käsittelyn kannalta tärkeä, koska se kertoo mistä 

data-alkiosta kulloinkin on kysymys. Kaikkien DICOM -dataalkioiden 

käsittely (lukuun ottamatta File Preamble ja Dicom Prefix 

alkioita) perustuu siihen että alkio ensin tunnistetaan Tagin avulla. 

Data-alkioiden järjestyskin määräytyy Tagin perusteella 

4.2.2 Dataryhmän (Data Group) ja Data-alkion (Data-element) pituus 

Monesti myös tiedoston pituuden ja sen eri osien pituuksien 

tunteminen ovat tärkeitä tiedostoa käsitteleville ohjelmille. Erityisen 

tärkeäksi tämä muodostuu DICOM-tiedostoita käsiteltäessä koska 

data-alkioiden määrä voi vaihdella suurestikin samankin tyyppisessä 

kuvassa. Eräs perustehtävistä DICOM-tiedostoa muunnettaessa onkin 

tiedoston ja sen data-alkioiden sekä dataryhmien pituuksien 

selvittäminen. 

4.2.2.1 Data-ryhmän pituus 

Data-alkiot on järjestelty Tagin ryhmänumeron mukaan dataryhmiksi 

(Data Group) Dataryhmät eivät ole kuitenkaan vakiopituisia mistä 

saattaisi aiheutua ongelmia tiedostoa käsitteleville ohjelmille mikäli 

ryhmän pituutta ei olisi tiedossa. Pituus onkin yleensä aina ilmaistu 

ko. ryhmän ensimmäisenä alkiona eli alkionumerolla 0000h. 

25.10.03 46/53


4.2.2.2 Data-alkion pituus 

Myös Data-alkion pituus on yleensä ilmaistu. Pituuden ilmoittamiseen 

käytetään alkion Value Length -kenttää. Joissain tilanteissa (riippuen 

tiedoston syntaksista) voidaan käyttää myös määrittelemättömän 

pituisia data-alkioita (Undefined Length). Tällöin data-alkion - 

pituuskentän arvoksi on asetettava luku FFFFFFFFh. 

4.3 Muunnosprosessin vaiheet (yleisellä tasolla) 

DICOM-tiedoston muuntamiseen esim. Jpeg:ksi liittyy useita osittain 

mutkikkaitakin toimenpiteitä. Tässä kappaleessa on kuitenkin yritetty 

mahdollisimman yksinkertaisesti ja yleisellä tasolla selvittää 

muunnosprosessin tärkeimpiä vaiheita. On huomattava että esitettyjen 

kuvausten ei ole tarkoituskaan mennä yksityiskohtiin, vaan 

pikemminkin luoda kokonaisvaltainen näkökulma asioista joita 

muunnokseen liittyy. Myöskään siihen mihin muotoon DICOMtiedostoa 

halutaan muuntaa ei oteta kantaa vaan esitettyjen 

toimenpiteiden pitäisi olla yleispäteviä muunnettiinpa DICOMtiedostoa 

mihin formaattiin tahansa. 

4.3.1 Vaihe 1: Tarkista että muunnettava tiedosto kelvollinen 

DICOM3-Tiedosto 

Aivan ensimmäiseksi on syytä tarkistaa, että muunnettava tiedosto on 

kelvollista DICOM3 -muotoa. DICOM3 -standardi tarjoaa tähän 

yksiselitteisen ja helpon tavan määrittelemällä, että kaikissa 

standardin mukaisissa DICOM3 tiedostoissa on oltava "File Meta 

Information" -kentässä toisena alkiona merkkijono "DICM" (DICOM 

prefix) (ks. taulukko 3.1). DICOM3 yhteensopivuuden varmennus 

saadaankin yksinkertaisesti tehtyä esim. lukemalla DICOM- tiedoston 

alusta tavut 129, 130, 131, 132 ja tarkistetamalla, että nämä tavut 

sisältävät merkkijonon 'D' 'I' 'C' 'M'. 

4.3.2 Vaihe2 : Tarkista tiedoston "syntaksi" (Transfer Syntax UID) 

Seuraavaksi kannattanee tarkistaa tiedoston "syntaksi" eli "File Meta 

Information" -osasta data-alkio 0002, 0010 ("Transfer Syntax UID" 

)(ks. taulukko 3.x). Tämä alkio on tärkeä kuvadatan lukemisen 

kannalta, sillä se määrää tavan (kertoo kuvan koodauksessa käytetyn 

kielen) jolla kuvadataa tulisi käsitellä. "Transfer syntaksin" 

tavallisimmat arvot on listattu kuvassa 3.x 

25.10.03 47/53


4.3.3 Vaihe3: Tarkista mitä attribuutteja tiedosto sisältää (tiedoston 

pituus). 

Vaiheena 3 voidaan vaikkapa käydä nopeasti läpi tiedoston kaikki 

ominaisuusryhmät ja tarkistaa mitä data-alkioita tiedosto sisältää. 

Samalla kannattaa selvittää myös kunkin Dataryhmän ja data-alkion 

pituus 

4.3.4 Vaihe4: Tarkista että tiedosto sisältää kaikki muunnosta varten 

tarvittavat data-alkiot 

Vaihe4 on olennainen muunnoksen onnistumisen kannalta, koska 

siinä varmistetaan, että tiedoston otsikko-osa sisältää muunnoksen 

kannalta tärkeät data-alkiot. Mikäli jotakin tarvittavaa data-alkiota ei 

löydy keskeytetään muunnos. Tarpeellisia data-alkioita ovat esim. 

kuvan koon ja bittimäärän yksilöivät alkiot. 

4.3.5 Vaihe5: Lue tarvittavat data-alkiot ja pura niiden sisältämä data 

syntaksin mukaisesti 

Tässä vaiheessa suoritetaan varsinainen tiedoston purku-prosessi eli 

otetaan tiedostosta irti kuvadata ja puretaan sen "koodaus" tiedoston 

syntaksin ("transfer syntax") edellyttämällä tavalla. On huomattava, 

että vaiheet 4 ja 5 kuuluvat läheisesti yhteen, ja monesti ne voidaan 

myös käytännössä yhdistää. Tässä ne on kuitenkin listattu selkeyden 

vuoksi kumpikin omina vaiheinaan. 

4.3.6 Vaihe6: Suorita tarvittavat muunnosprosessit ja kirjoita 

uudelleen koodattu pikseli-data kohdetiedostoon. 

Kun kuva on purettu normaaleiksi pikseli-alkioiksi, sitä voidaan 

edelleen jatkokäsitellä kunkin kohdetiedosto-formaatin vaatimalla 

tavalla, ja sitten kirjoittaa uudelleen koodattu data kohdetiedostoon. 

Kuvadataa voidaan esim. pakata joko häviöttömillä- (esim. gif) tai 

häviöllisillä (esim. häviöllinen Jpeg) pakkausalgoritmeilla.. Varsinkin 

häviöllisillä pakkausalgoritmeilla pakattaessa on kuitenkin 

muistettava että kuvan laatu on säilytettävä riittävän korkeana kutakin 

tarkoitusta varten. 

25.10.03 48/53


(Huom: Se mitä tarkoitetaan tässä riittävän korkealla laadulla, riippuu 

paljolti siitä minkä tyyppiseen diagnosointiin kuvaa on tarkoitus 

käyttää. Peukalosääntönä voidaan kuitekin todeta, että häviöllisen 

pakkauksen kanssa tulisi olla äärimmäisen varovainen.) 

4.4 DICOM -tiedoston muunnoksen Ongelmia 

Kuten kaikkiin käytännön asiohin, myös DICOM-muunnokseen liittyy 

tiettyjä ongelmia. On selvää ettei ympäri maailman käytössä olevaa 

standardia tulkita ja sovelleta kaikkialla aina aivan samalla tavalla. 

Eniten "harmaita bittejä" aiheuttavat todennäköisesti eri syntaksit, 

joita DICOM-standardin puitteissakin on melkoinen määrä. Samoin 

pakatun tiedostoformaatin käsittelyyn liittyy omat koukeronsa. 

Yleisesti ottaen DICOM-muunnoksen vaikein puoli on kuitenkin 

standardin syvällinen ymmärtäminen edes tiedostoformaatin osalta, 

joka vaatii aina oman aikansa. Kun tämä puoli on kunnossa, ei 

muunnos-ohjelman suunnitteleminen ole enää mikään mutkikas 

temppu. Tässä asiassa auttavat varmasti myös valmiit DICOMmuunnos 

ja katseluohjelmien lähdekoodit, joita on ilmaiseksi 

saatavissa useistakin lähteistä. Tämän dokumentinkin sähköisessä 

liite-arkistossa on lähdekoodit muutamasta ratkaisusta sekä Java, C++ 

että Object Pascal (Delphi) kielellä. 

25.10.03 49/53


5. MISTÄ SAAN LISÄTIETOA? (LINKKILISTA JA LIITTEET) 

5.1 Yleistä 

DICOM3 on tietotekniikan standardina jo melkoisen vanha ja lisäksi 

maailman laajuisesti käytössä, joten tiedon löytäminen ei sinänsä ole 

vaikeaa. Kuvaavaa on että yksinkertaisella sanahaulla (DICOM3) 

esim. Alta Vista- hakukoneella löytyi kaikkiaan useita tuhansia sivuja. 

Suurempana ongelmana onkin sen "oikean" tiedon kaivaminen 

valtaisasta tietotulvasta. Tätä silmälläpitäen pyrinkin keräämään 

joitakin olennaista tietoa sisältäviä Web-sivuja, ohjelmia ja muuta 

dokumentaatiota tämän raportin liitteeksi. Liitteet ovat sähköisessä 

muodossa, erityisessä liitearkistossa josta tarkemmin seuraavassa 

kappaleessa. Lisäksi kokosin joukon hyödyllisiä linkkejä, joista myös 

saattaa löytyä apua DICOM:ia koskevissa asioissa. Osa näidenkin 

linkkien kohteista sisältyy liite-arkistoon. Linkit on tarkemmin 

läpikäyty kappaleessa 5.3. 

5.2 Sähköisen liitearkiston sisältö 

Sähköinen liite-arkisto sisältää runsaasti materiaalia (kaikkiaan n. 150 

MT) liittyen DICOM:iin ja lääketieteellisiin kuvaformaatteihin 

yleensä. Arkisto koostuu seuraavista kansioista: 

Kuva 5.1 Sähköisen liite-arkiston kansiot 

5.2.1 Esimerkkejä -kansio 

Tämä kansio sisältää kokoelman DICOM3-muotoisia erilaisia 

tiedostoja lähinnä testiohjelmia ja kuvan muunnoksen testausta varten. 

Kansioon on sisällytetty myös erinäisistä lähteistä saatuja tiedostoja 

joita väitettiin DICOM-tiedostoiksi mutta joita en saanut avatuksi 

millään testaamallini ohjelmalla. Nämä tiedostot ovat Esimerkkejä 

hakemiston alikansiossa: "Tuntematonta muotoa". 

25.10.03 50/53


5.2.2 Omat -kansio 

Omat kansio sisältää tämän dokumentin doc-muodossa ja 

mahdollisesti muuta tekijän itse kirjoittamaa/tuottamaa 

dokumentaatiota. 

5.2.3 Perusinfo -kansio 

Perusinfo sisältää tärkeää informaatiota DICOM:sta. PerusInfon 

sisältämät tiedostot jotka ovat pääsasiassa html-muotoa ja niihin 

kuuluvia kuvia. Perusinfo -kansiossa olevat dokumentit on nimetty 

uudelleen ko. informaatiota kuvaavalla tavalla. Tämä dokumentti 

perustuu DICOM -standardin lisäksi pääosin perusinfo kansiossa 

olevaan dokumentaatioon. 

5.2.4 Projekteja -kansio 

Projekteja kansioon on koottu tietoja DICOM-tiedostomuunnokseen 

liittyvistä projekteista ( Huom: ei sisällä apuohjelmiin liittyvää tietoa 

kuten lähdekoodeja) 

5.2.5 Sekalaista -kansio 

Sekalaista kansioon on koottu kaikki järjestelemätön dokumentti 

materiaali. 

5.2.6 Softa -kansio 

Tämä kansio on sisällöltään kaikkein laajin sisältäen lajitellut 

muunnosohjelmat omina kansioinaan. Sekalaiset alikansio sisältää 

lajittelemattomat ohjelmat. Mahdolliset kuhunkin ohjelmaan liittyvät 

lähdekoodit löytyvät ko. ohjelman kansion alta alikansiosta 

lähdekoodi tai vastaavasta. 

5.2.7 standardi(viimeisin99draft) -kansio 

Sisältää tämän dokumentin kirjoitushetkellä viimeisimmän "draft"version 

DICOM standardista . Tästä kansiosta löytyvät myös 

tiedostot: ChangesRelativeTo98.pdf ja 

98ChangesRelativeToOfficial.pdf jotka sisältävät kuvauksen niistä 

eroista joita standardin "draft" -versio edelliseen standardin versioon 

nähden. 

5.3 Linkkilista selityksineen 

Ikäänkuin lisäporkkanana tiedon hankintaan asiasta kiinnostuneille 

kokosin myös pienen linkkilistan joka kaikkien DICOM-fanien 

kannattaa heti paikalla lisätä selaimensa "bookmarkkeihin" tai 

25.10.03 51/53


suosikkeihin :-). Linkit on myös pyritty esittämään jonkimoisessa 

tärkeysjärjestyksessä ja lisäksi kutakin linkkiä kohden on lyhyt kuvaus 

linkin kohteessa olevasta informaatiosta. 

http://idt.net/~dclunie/medical-image-faq/html/part8.html 

Kaikki linkit ja viitteet maan ja taivaan väliltä liittyen DICOM - 

standardiin ja tiedostomuotoon. Yhteensä 21 sivullista pelkkiä 

linkkejä. (heikkohermoiset ja kärsimättömät älkööt vaivautuko) 

http://medical.nema.org/dicom.html 

Neman DICOM -standardin kotisivu 

http://www.mrc-cbu.cam.ac.uk/personal/chris.rorden/dicom.htm 

Erinomainen ja käytännön läheinen (helppolukuinen!!!) kuvaus 

DICOM-tiedostosta. Älä jätä tätä väliin. 

http://www.bookcase.com/library/faq/archive/medical-imagefaq/part1.html 

Erinomainen, käytännön läheinen, edellistä linkkiä hiemän enemmän 

yksityiskohtiin menevä kuvaus DICOM-tiedoston rakenteesta. Ks. 

myös ... part2 - part8. 

http://crnet4.carelian.fi/euromed/wwwdcm/wwwdcm.html 

Vastaavan tyyppinen projekti johon osana kuului DICOM -kuvien 

esittäminen selaimella 

http://www.eihms.surrey.ac.uk/abbott/IT 

EDUCTRA/html/p423_13.htm 

Yleistä tietoa DICOM -standardista ja sen sisällöstä. Tarjoaa nopean 

katsauksen standardista ja sen sisällöstä hätäisemmille. 

http://www.bookcase.com/library/humor/ 

Kun olet käynyt läpi kaikki edellä olevat linkit voit tarvita hieman 

kevennystä.... :-) 

25.10.03 52/53


6. ONNITTELUT! 

Onnittelut , mikäli pääsit tänne asti torkahtamatta kertaakaan välillä 

tai hyppimättä yli sivuja, olet todella kiinnostunut DICOMtiedostoformaatista. 

Jos vieläkin jäit kaipaamaan lisäinformaatiota tai 

olet halukas antamaan rakentavia parannus/lisäys ehdotuksia, voit 

ottaa vapaasti yhteyttä dokumentin kirjoittajaan. Kaikki mahdolliset 

kommentit liittyen tähän dokumenttiin tai DICOM:iin yleensä ovat 

tervetulleita. Parhaiten minut tavoittaa sähköpostin välityksellä 

osoitteesta: lahteenj@hotmail.com 

25.10.03 53/53

DICOM3

Create successful ePaper yourself

Delete template?

Save as template?