Digital Imaging and Communications in Medicine

Notera att det finns ett svenskt mindre IT-företag, Dicom Datautveckling AB, som inte har något som helst med standarden DICOM att göra.

Digital Imaging and Communications in Medicine, DICOM, är en standard för hantering, lagring, utskrift och överföring av medicinska digitala bilder och information relaterad till dessa bilder. DICOM specificerar huvudsakligen ett filformat och ett kommunikationsprotokoll.

En DICOM-fil innehåller inte bara information om själva pixeldatat utan även information om vilken patient bilden hör till, vilken utrustning som genererat bilden m.m. Patientinformationen blir på detta sätt hårt kopplad till pixeldatat. Filformatet utgår från ett dataformat som även används vid DICOM-kommunikation, se nedan. I den mån en filändelse används för DICOM-filer är .dcm vanligast.

Kommunikationsprotokoll

DICOM som kommunikationsprotokoll kan klassificeras i de tre översta lagren i OSI-modellen, alternativt i applikationsskiktet i TCP/IP-modellen. Protokollet stödjer överföring av bilder och andra medicinska dokument, arbetslistor, statusinformation, sökning i databaser, utskrift mot filmskrivare m.m. DICOM möjliggör på detta sätt sammankoppling av exempelvis modaliteter, informationssystem, bildläsare, värddatorer, arbetsstationer, skrivare och annan hårdvara från olika leverantörer till ett integrerat system. Produkter som stödjer DICOM skall enligt standarden levereras med ett dokument, ett så kallat DICOM Conformance Statement, som specificerar vilka delar av DICOM som produkten stöder.

DICOM är idag den dominerande standarden inom framförallt medicinsk radiologi men används inom andra medicinska områden, exempelvis för ögonbottenbilder, för nuklearmedicin-bilder, inom strålbehandling, för EKG-kurvor m.m.

DICOM förvaltas av en kommitté med säte i USA. I kommittén finns läkare inom olika discipliner samt representanter för olika tillverkningsföretag. DICOM är i högsta grad en levande standard där nya tillägg (en: Supplement) görs i stor omfattning varje år.

Historia

Framsidan till ACR/NEMA 300, version 1.0, som släpptes 1985

DICOM bygger på en standardarbete av ACR (American College of Radiology) och NEMA (National Electrical Manufacturers Association). I början av 1980-talet var det nästan omöjligt för andra än tillverkarna av datortomografer att dechiffrera de digitala bilderna som apparaterna genererade. Radiologerna ville använda bildinformationen till dosplanering för strålbehandling. ACR tog kontakt med NEMA och en standardiseringskommitté skapades 1983.

Deras första version av standarden, ACR/NEMA 300, släpptes 1985. Snart insåg man att den behövde förbättras för att bli användbar. Denna första version var vag och innehöll motsägande uppgifter.

1988 kom version 2.0 av ACR/NEMA-standarden. Denna fick en bredare acceptans bland tillverkarna. Dock var inte heller denna version bra. Till exempel gick bildöverföringen över en dedikerad kabel (50-stiftskontakt). På konferensen RSNA (Radiological Society of North Armerica) 1990 presenterades de första kommersiella apparaterna som stödde ACR/NEMA 2.0, levererade av General Electrics medicinska gren och Vortech (ett företag som sedermera blev uppköpt av Eastman Kodak).

Många insåg att denna version behövdes förbättras. Flera utvidgningar av ACR/NEMA 2.0 skapades, bland annat Papyrus (drevs av Universitetssjukhuset i Genève) och SPI, Standard Product Interconnect (framtaget av Siemens AG och Philips).

ACR/NEMA gav ut version 3.0 av sin standard 1992. Samtidigt bytte standarden namn till DICOM. Nu behövde man inte ha en speciell kabel utan kunde kommunicera med TCP/IP över Ethernet, nya serviceklasser definierades och DICOM Conformance Statements specificerades. Versionsnumret "3.0" förekommer ofta tillsammans med namnet DICOM. Vi har idag fortfarande version 3.0 av DICOM, men en kraftig utveckling av standarden pågår ständigt. För olika versioner av DICOM refererar man istället till vilket års version man menar, till exempel "DICOM 2007".

Kritik

DICOM som standard har varit väldigt viktig för att öppna upp medicinsk bildhantering och bryta upp de leverantörsspecifika format som tidigare fanns.

Bland nackdelarna kan nämnas att DICOM är en typisk kommittéprodukt där eftergifter mot vissa leverantörer gjorts, vilket har lett till många olika möjligheter. Exempelvis finns tre olika okomprimerade format och vidare finns många olika varianter för lagring av pixeldata. Ett annat exempel är att det finns olika sätt att spara grafik som är associerade med bilderna (som så kallade Presentation States, som DICOM Overlay:er i pixeldata, som DICOM Overlay i separata attribut, som strukturerade rapporter, som DICOM Curvs, inbrända i bilden med mera) Detta leder till att leverantörer tvingas implementera stöd för alla dessa möjligheter och det leder till komplicerade lösningar som ofta medför problem vid kommunikation mellan två olika system.

För att komma från flera av dessa problem har initiativet med Integrating the Healthcare Enterprise (IHE) varit viktigt och relativt framgångsrikt, även om många problem med DICOM:s rika möjligheter att göra samma sak på flera sätt fortfarande kvarstår.

En annan kritik som ofta framförs är att det saknas verifiering och certifiering inom DICOM. Man säger ofta att det saknas en "DICOM-polis", det vill säga en myndighet som kan avgöra vilken part som gör fel när integrationsproblem uppstår mellan två leverantörer. Det är inte heller alltid som en "DICOM-polis" som skulle göra slutanvändaren nöjd, utan möjligen skulle detta kunna lösas av ytterligare standarder inom IHE samtidigt som en ordentlig certifiering av riktiga produkter infördes inom IHE.^[1]

Serviceklasser

I DICOM finns ett antal serviceklasser (en: Service Classes, på svenska ofta även kallade "tjänster") specificerade. Varje serviceklass specificerar en eller flera funktioner som kan utföras med en viss typ av information. De viktigaste serviceklasserna beskrivs kortfattat nedan.

Storage

Är den serviceklass som används för överföring av bilder och annan beständig information, exempelvis bildpresentationsinformation (en: Presentation States), rapporter (en: Structured Reports), eller EKG-kurvor.

Storage Commitment

Används av sändande tillämpningsprogram efter en överföring för att lämna över ansvaret för lagringen av de överförda objekten. Med en sådan kvittens kan objekten raderas på sändande sida utan risk för att de försvinner ur systemet.

Query/Retrieve

Ger möjlighet för en arbetsstation att söka och hämta bilder och andra objekt ur ett annat system.

Worklist Management

Innehåller två delar, dels arbetslistor för modaliteter (en: Modality Worklist, MWL) och dels mer generella arbetslistor (en: General Purpose Worklist, GPWL). Den senare varianten är inte speciellt mycket använd.

MWL används i mycket stor utsträckning. Den gör det möjligt för modaliteter att hämta en lista av bokade undersökningsmoment (en: Scheduled Procedure Steps). Listan erbjuds av ett informationssystem, vanligtvis ett RIS. Genom att modalitetsoperatören kan markera den aktuella patientens namn i en lista kan informationen från arbetslistan läggas in i objekt som exporteras från modaliteten. Detta effektiviserar arbetet vid modaliteten och minskar risken för fel.

Procedure Step SOP Classes

Kompletterar Worklist Management och ger möjlighet att skicka tillbaka information om påbörjade och genomförda undersökningsmoment (en: Performed Procedure Steps). Denna serviceklass hette tidigare "Study Management".

Det finns, precis som i Worklist Management, två delar; en som är knuten till modaliteten och en mer generell. Den modalitetsknutna funktionen förkortas ofta MPPS (Modality Performed Procedure Step).

Print Management

Används för att skicka bilder för utskrift till filmskrivare (så kallade laserkameror). Dessa skriver ut bilderna på stora film-ark. DICOM specificerar även en standard-kalibrering (definieras i kapitel 14 av standarddokumenten) som möjliggör konsistens mellan olika skärmar, samt mellan skärmar och utskriftsenheter.

Media Storage

Används för att lagra bilder och andra DICOM-objekt som filer på ett lagringsmedium, exempelvis CD och DVD. Om DICOM-objekt läggs på ett lagringsmedium av en applikation enligt DICOM Media Storage kan man läsa upp objekten på en annan applikation som stödjer denna serviceklass. Förutom DICOM-objekten skall det även finnas en index-fil, kallad DICOMDIR. DICOMDIR-filen beskriver namnen på de patienter, undersökningar (en: studies), bildserier och DICOM-objeket som finns på mediat samt anger sökvägen till objekten.

Det filformat som används i samband med Media Storage kallas ibland för kapitel 10-format (en: Chapter 10 format), då detta format beskrivs i kapitel 10 av standarden. Exempelvis finner man exempelfiler på Internet i detta format. Många PACS använder också det internt.

Viktigare begrepp

Följande lista ger enklare förklaringar på de viktigaste begreppen inom DICOM:

AE-titel (en: AE-title, AE = Application Entity) DICOM-identiteten, namnet, på ett tillämpningsprogram. Består av en teckensträng med högst 16 tecken, exempel: DICOM_STORAGE.
Association En uppkoppling.
FSC (en: File Set Creator) rollbenämning på ett tillämpningsprogram som kan skriva på media enligt serviceklassen Media Storage.
FSR (en: File Set Reader) rollbenämning på ett tillämpningsprogram som kan läsa från ett media enligt serviceklassen Media Storage
FSU (en: File Set Updater) rollbenämning på ett tillämpningsprogram som kan uppdatera ett media enligt serviceklassen Media Storage
IOD (en: Information Object Definition) definitionen av en typ av DICOM-bild eller annat DICOM-objekt. Det finns olika definitioner för olika bildgenereringstekniker, exempelvis CT, MR, CR (bildplattebilder), MG (mammografibilder) etc.
Meddelande (en: Message) ett meddelande som skickas mellan två tillämpningsprogram som har upprättat en association. Exempel: objekt skickas i serviceklassen Storage med meddelandet C-STORE-RQ. Mottagaren kvitterar det mottagna objektet genom att skick tillbaka ett C-STORE-RP-meddelande.
PDU (en: Protocol Data Unit) benämningen på de paket som skickas mellan två applikationerna. Det finns PDU:er som används för att sätta upp, avsluta och avbryta associationer. PDU:n P-DATA-TF används för att skicka meddelanden. PDU:erna skickas med TCP-datagram.
SCU (en: Service Class User) rollbenämning på ett tillämpningsprogram som använder en nätverksbaserad serviceklass. Det är vanligtvis SCU:n som initierar en association och agerar klient.
SCP (en: Service Class Provider) rollbenämning på ett tillämpningsprogram som erbjuder en nätverksbaserad serviceklass. Vanligen är SCP:n en server.
Service (en: Service) är en meddelandetyp. Exempel: C-STORE är en service som har meddelandena C-STORE-RQ och C-STORE-RP.
SOP-klass (en: SOP Class, SOP = Service Object Pair) En kombination av en IOD och en service. Exempelvis IOD=MR-bild, meddelandetyp=C-STORE ger SOP Class = "lagring av MR-bild". En serviceklass består av ett antal SOP-klasser.
Transfer Syntax format på vilket bilder och andra objekt kan skickas och lagras. Det finns tre okomprimerade format och ett antal komprimerande format.
Uppkopplingsförhandling (en: Association Negotiation) Den inledande handskakningen där den som initierar en association förhandlar med den som accepterar en association om SOP-klasser och transfer syntaxer som kan användas under associationen.

Dataformat

DICOM har ett dataformat som används både vid kommunikation och vid fillagring. I DICOM:s dataformat taggas all information med en etikett (en: tag), därefter specificeras värdets längd och sist värdet självt. Dessa tre tillsammans kallas för ett attribut (en: attribute). Varje attribut har även en datatyp (en: value representation) som kan vara explicit specificerad (d.v.s. lagrad i filen eller skickas i meddelandet) eller så framgår den implicit av standarden. Exempelvis kan attributet patientnamn vara specificerad genom: etikett: (0010,0010), värdelängd: 18 tecken, värde: "Efternamn^Förnamn ". Patientnamn har alltid etiketten (0010,0010) och alltid datatypen PN (Personal Name).

Ett dataobjekt i DICOM består av många attribut. Exempelvis kan en datortomografibild innehålla mellan 100 och 200 attribut som specificerar personuppgifter, uppgifter om apparaten som genererade bilden, datum o.s.v. (se exempel nedan). Ett av attributen, med etiketten (7FE0,0010), innehåller bilden i sig, d.v.s. själva pixeldatat. Här ser man en skillnad mot många andra bildformat; en DICOM-bild innehåller mycket mer information än själva pixeldatat. Personuppgifterna för patienten ligger alltså alltid lagrat tillsammans med bilden.

En DICOM-fil inleds med 128 NUL-tecken (ASCII-värdet 0), därefter strängen "DICM". Därefter följer några meta-attribut som bl.a. anger det exakta formatet (transfer syntaxen) för filen. Sist följer dataobjektets alla attribut.

En DICOM-bild kan vara en enkel-bild, men kan även innehålla flera bildrutor (en: frames), vilket bl.a. används vid lagring av ultraljudssekvenser (ultraljuds-clip). Pixeldatat kan lagras okomprimerat eller vara komprimerat med JPEG, Lossless JPEG, JPEG 2000, Skurlängdskodning (eng. Run-Length Encoding, RLE) eller någon annan kompressionsalgoritm som godkänts av DICOM.

Exempel

Bilden till höger visar ett exempel på en DICOM-bild. Den visar ett knä som undersökts med magnetisk resonanstomografi.

Nedan finns en lista över några attribut som kan ingå i en sådan bild. Varje rad visar attributets etikett, värdelängd och värde. Efter # visas attributets namn.

(0002,0010) 18 1.2.840.10008.1.2 # Transfer Syntax UID (0008,0016) 26 1.2.840.10008.5.1.4.1.1.4 # SOP Class UID (0008,0018) 28 1.2.752.24.3.3.288.14.10.22 # SOP Instance UID (0008,0020) 8 20011016 # Study Date (0008,0030) 12 074751.0000 # Study Time (0008,0050) 8 EXAM0088 # Accession Number (0008,0060) 2 MR # Modality (0008,0070) 24 Philips Medical Systems # Manufacturer (0008,0080) 16 Centralsjukhuset # Institution Name (0008,1030) 12 MRI RT KNEE # Study Description (0008,1090) 12 Gyroscan NT # Manufacturer Model Name (0010,0010) 18 Efternamn^Förnamn # Patient Name (0010,0020) 14 12345678-9012 # Patient ID (0010,0030) 8 19700123 # Patient Birthdate (0010,0040) 2 M # Patient Sex (0028,0010) 2 256 # Rows (0028,0011) 2 256 # Columns (0028,0030) 16 1.17188\1.17188 # Pixel Spacing (0028,0100) 2 16 # Bits Allocated (0028,0101) 2 12 # Bits Stored (0028,0102) 2 11 # High Bit (7fe0,0010) 131072 0000\0000\0000\0000... # Pixel Data

Se även

Referenser

^ David Clunie (3 juni 2007). ”On the lack of DICOM Police, the example of IHE content profiles, and the need for usability standards and cross-certification ...”. http://www.dclunie.com/blog/blog/2007/06/on-lack-of-dicom-police-example-of-ihe.html. Läst 18 juli 2007.

Externa länkar

Aktuell status för standarden på David Clunies hemsida
DICOM-kommitténs hemsida
Nyhetsgrupp: comp.protocols.dicom

[1] David Clunie (3 juni 2007). ”On the lack of DICOM Police, the example of IHE content profiles, and the need for usability standards and cross-certification ...”. http://www.dclunie.com/blog/blog/2007/06/on-lack-of-dicom-police-example-of-ihe.html. Läst 18 juli 2007.

[1]