Digital Imaging and Communications in Medicine
Wikipedia
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.
- Notera att det finns ett svenskt mindre dataföretag, Dicom Datautveckling AB, som inte har något som helst med standarden DICOM att göra.
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 bli på detta sätt hårt kopplat 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.
DICOM som kommunikationsprotokoll kan klassficeras 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 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öjder.
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 dicipliner 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.
Innehåll |
[redigera] Historia
DICOM bygger på en standardarbete av ACR (American Collage 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övdes 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. T.ex. 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 medcinska gren och Vortech).
Många insåg tidigt att denna version behövdes förbättras. Flera utvidgningar av ACR/NEMA 2.0 skapades, bl.a. 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. Versionnumret "3.0" förkommer 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.
[redigera] Kritik
DICOM som standard har varit väldigt viktigt för att öppna upp medicinsk bildhantering och bryta upp de leveratörsspecifika format som tidigare fanns.
Bland nackdelarna kan nämnas att DICOM är en typisk kommittéprodukt där eftergifter mot vissa leveratö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. Detta leder till att leveratörer tvingas implementera stöd för alla dessa möjligheter och det medför ofta problem vid kommunikation mellan två olika system.
För att komma från flera av dessa problem har intiativet med Integrating the Healthcare Enterprise 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.
[redigera] 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.
[redigera] 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.
[redigera] 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.
[redigera] Query/Retrieve
Ger möjlighet för en arbetsstation att söka och hämta bilder och andra objekt ur ett annat system.
[redigera] 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ökningar (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äggs in objekt som exporteras från modaliteten. Detta effektiviserar arbetet vid modaliteten och minskar risken för fel.
[redigera] Procedure Step SOP Classes
Kompletterar Worklist Management och ger möjlighet att skicka tillbaka information om påbörjade och genomförda arbetssteg (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).
[redigera] 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 standard-kalibrering (definieras i kapitel 14 av standarddokumenten) som möjliggör konsistens mellan olika skärmar, samt mellan skärmar och utskriftsenheter.
[redigera] 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.
[redigera] Viktigare begrepp
- AE-titel (en: AE-title, AE = Application Entity) DICOM-identiteten på ett tillämpningsprogram, 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) defintionen 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 skicka 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.
- Meddelandetyp (en: Service) Exempel: C-STORE är en meddelandetyp som har meddelandena C-STORE-RQ och C-STORE-RP.
- PDU (en: Protocol Data Unit)
- SCU (en: Service Class User) rollbenämning på ett tillämpningsprogram som kan agera klient för en nätverksbaserad serviceklass. Vanligtvis den som initierar en uppkoppling (en: association).
- SCP (en: Service Class Provider) rollbenämning på ett tillämpningsprogram som kan agera server för en nätverksbaserad serviceklass.
- SOP-klass (en: SOP Class, SOP = Service Object Pair) En kombination av en IOD och en meddelandetyp. Exv. IOD=MR-bild, meddelandetyp=C-STORE ger SOP Class = "lagring av MR-bild".
- 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 klient och server förhandlar om SOP-klasser och transfer syntaxer som kan användas under associationen.
[redigera] 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). Patientnamn har datatypen PN (Personal Name).
Ett dataobjekt i DICOM består 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 (så kallat "transfer syntax") 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, Run-Length Encoding (RLE) eller någon annan kompressionsalgoritm som godkänts av DICOM.
[redigera] Exempel
Bilden till höger visar ett exempel på en DICOM-bild. Den visar ett knä som undersökts med Magnet-Resonans-Tomografi.
Nedan finns en listning av några attribut som typiskt ingår i en sådan här bild. Varje rad visar attributets ettiket, värdelängd, 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
[redigera] Se även
[redigera] Externa länkar
- DICOM-kommittens hemsida
- Nyhetsgrupp: comp.protocols.dicom
