Digital bildebehandling og kommunikasjon i medisin

Digital bildebehandling og kommunikasjon i medisin ( DICOM ; tysk digital bildebehandling og kommunikasjon i medisin ) er en åpen standard for lagring og utveksling av informasjon i medisinsk bildedatastyring. Denne informasjonen kan for eksempel være digitale bilder, tilleggsinformasjon som segmenteringer , overflatedefinisjoner eller bilderegistreringer . DICOM standardiserer både formatet for lagring av dataene og kommunikasjonsprotokollen for utveksling av dem.

Nesten alle produsenter av bildebehandling eller bildebehandlingssystemer i medisin som B. Digital røntgen , magnetisk resonanstomografi , computertomografi eller sonografi implementerer DICOM-standarden i sine produkter. Dette muliggjør interoperabilitet mellom systemer fra forskjellige produsenter i det kliniske miljøet .

DICOM er også grunnlaget for digital bildearkivering i praksis og sykehus ( Picture Archiving and Communication System , PACS).

Dataformat

DCM-eksempelbilde (se tekst)

I tillegg til datafelt (f.eks. Informasjon om bilder, funn , pasienter, studier, serier) inneholder DICOM også syntaksen og semantikken til kommandoer og meldinger. Videre definerer standarden regler for beskrivelsen av DICOM-kompatible enheter og programvare, siden en nøyaktig beskrivelse av systemfunksjonen må være tilgjengelig og publisert for alle DICOM-kompatible enheter (DICOM Conformance Statement).

En DICOM-datapost fungerer som en beholder som i tillegg til en eller flere objektdefinisjoner også kan inneholde metainformasjon som pasientnavn, innleggelsesdato, enhetsparametere eller legenavn. Objektdefinisjonene kan være bildedata, geometrisk eller matematisk informasjon og også behandlingsspesifikk informasjon, slik som i de såkalte DICOM RT- objektene, som i seg selv bare inneholder behandlingsdata og kun referanse bildedatasett.

DICOM lagrer eller overfører bilder uten tap eller tap, basert på TIFF- format og JPEG- standarden. Den kan oppsummere bildeserier. De forskjellige komprimeringsmetodene er definert i sin egen overføringssyntaks.

DICOM-standarden lar deg også definere dine egne, såkalte private objekter, moduler eller attributter. Imidlertid er denne proprietære informasjonen normalt ikke lenger kompatibel med implementeringer fra andre produsenter.

Bildet til høyre er basert på en DICOM-fil. Den er konvertert til et standard grafisk format for visning.

Virkelig informasjonsmodell

Virkelig informasjonsmodell

DICOM tolker data i en såkalt Real World Information Model , som er delt inn i nivåene av pasient, studie, serie og forekomst . Hver forekomst av et DICOM-objekt inneholder således all informasjon for å kunne tilordne den til en bestemt serie (for eksempel bildeserie), studium (et visst opphold på klinikken eller en individuell undersøkelse) og pasienter.

Det unike med informasjonen er basert på implementerte unike identifikatorer (Unique Identifier ) .

Definisjon av informasjonsobjekt

Eksempel på IOP for et bilde

Alle objekter i DICOM er spesifisert ved hjelp av en såkalt definisjon av informasjonsobjekt . Denne består av flere moduler, som igjen inneholder individuelle attributter eller sekvenser av attributter.

Det er laget mellom normaliserte (normaliserte) og sammensatte (sammensatte) skille objekter. Normaliserte objekter tilsvarer objekter i den virkelige verden, mens sammensatte objekter inneholder attributter som faktisk er relatert til objektet i den virkelige verden, men som ikke kan tildeles dem direkte.

De sammensatte objektene har vanligvis alle følgende moduler til felles: SOP Common, Patient, Study, Series and Equipment. Andre moduler varierer avhengig av egenskapens modalitet . Ved å bruke disse modulene , også kjent som headerinformasjon , kan ethvert objekt tydelig tilordnes til en bestemt prosess.

Moduldefinisjon

Moduldefinisjoner grupperer DICOM-attributter i logiske enheter. Pasientmodulen inneholder for eksempel all informasjon relatert til pasienten, for eksempel navn, ID, kjønn eller alder. Moduler kan brukes på nytt i forskjellige sammensatte gjenstander. I hver definisjon av et sammensatt objekt defineres det også om en bestemt modul er helt nødvendig og må være tilgjengelig ( M - obligatorisk), om dens eksistens er knyttet til visse forhold ( C - betinget) eller om den er etter skjønn bruker ( U - brukeralternativ).

Moduldefinisjoner finnes i DICOM-standarden i kapittel 3.

Attributtdefinisjon

DICOM dataelement

Et attributt defineres ved hjelp av et fast åttesifret heksadesimalt tall , en såkalt datakode . De fire første sifrene definerer tilknytningen til attributtet til en bestemt gruppe (for eksempel File Meta Information ), de andre fire definerer elementet. For bedre lesbarhet vises en DICOM- datakode vanligvis i skjemaet (aaaa, bbbb) med et komma i midten. Dermed tilsvarer merkelappen 0x00100010 - pasientens navn - desimalverdien 1048592 og er representert som (0010,0010).

DICOM-standardattributter har alltid et jevnt antall grupper, med gruppene 0000, 0002, 0004 og 0006 som er reservert for DIMSE- kommandoer og DICOM-filsett . Oddgruppenumre er reservert for private dataelementer som kan tildeles av hvilken som helst implementer.

Et annet kjennetegn ved en attributt er dens representasjon (VR), for eksempel DS (Decimal String), IS (Integer String) eller ST (Short Text). Dette inkluderer maksimal lengde på et felt og tillatt tegnsett eller eksplisitt forbudte tegn.

Videre er definisjonen av Value Multiplicity (VM), i. H. mangfoldet av et attributt er nødvendig. Som et eksempel har spesifikasjonen av en vinkel i en desimalstreng mangfoldet 1. En koordinat , også av typen DS, har mangfoldet 3 for å kunne spesifisere posisjonen i alle romlige retninger.

Den fjerde nødvendige egenskapen er typen av elementet. Det skilles mellom type 1 - absolutt nødvendig og innhold må være til stede -, type 2 - helt nødvendig, men kan være tom - og type 3 - ikke helt nødvendig. Videre kan typene knyttes til forhold ved å legge til bokstaven C (“1C”, “2C”). Dette betyr at for eksempel et element av type 1 faktisk bare må være tilstede hvis betingelsen definert i den tilhørende beskrivelsen faktisk er oppfylt.

Mens verdirepresentasjonen og verdimultiplikiteten forblir konstant, kan typen endres avhengig av modulen der attributtet brukes. Betingelser for typene 1C og 2C kan derfor også endres tilsvarende og er oppført individuelt i den respektive moduldefinisjonen i beskrivelsen av attributtet.

Eksempler

(0010,0010) - Pasientens navn, VR: PN, VM: 1, Type: 2
(0010,0020) - Pasient-ID, VR: LO, VM: 1, Type: 2
(0010,0021) - IssuerOfPatientID, VR: LO, VM: 1, Type: 2

Attributt og tilhørende typedefinisjoner finnes i kapittel 3 i DICOM-standarden. Verdirepresentasjon og verdimultiplikt er definert for alle attributter i kapittel 6. Definisjonene av verdierepresentasjonsverdiene er gitt i kapittel 5 " Datastrukturer og koding".

Serviceklasser

Serviceklassene definert i DICOM-standarden angir forskjellige tjenester. Når disse brukes på et objekt, danner de en tjenestegruppe. Følgende tjenester er tilgjengelige:

  • Bekrefte
  • butikk
  • Spør / hent
  • Fremgangsmåte trinn (varsling)
  • Utskriftshåndtering
  • Administrasjon av medielagring
  • Lagringsforpliktelse
  • Ledelse av arbeidsliste
  • Presentasjonstilstand lagring
  • Strukturert rapporteringslagring
  • Søknadslogglogging
  • Relevant pasientinformasjonsspørsmål
  • Melding om tilgjengelighetsforekomst
  • Ledelse av medieopprettelse
  • Hengende protokolllagring
  • Hanging Protocols Query / Retrieve
  • Spørring om stoffadministrasjon

(Beskrivelser finnes i del 4 av standarden, serviceklasser i kursiv er av mindre betydning eller støttes ennå ikke av produsenter av enheter).

De viktigste tjenestene

Bekrefte
Verify kan brukes til å sjekke om en ekstern nettverksnode støtter DICOM med de konfigurerte parametrene.
Oppbevaring
Lagringstjenesten lagrer en stor del av de vedvarende dataobjektene.
Spør / hent
Med Query and Retrieve kan en PACS eller en annen DICOM-enhet søkes etter objekter (Query), og funnet objekter kan deretter overføres til en annen enhet (Retrieve).
Procedure Step (også forkortet MPPS for Modality utført procedure Step )
Ved hjelp av prosedyretrinn kan DICOM-enheter varsle andre om undersøkelsestrinnene som er utført. Vanligvis kommuniseres disse prosedyrene til enheten for behandling i en arbeidsliste , som deretter utfører, avbryter eller endrer dem. Denne informasjonen kan overføres til planleggingssystemet via utført prosedyretrinnvarsling.
Lagringsforpliktelse
Ved hjelp av lagringsforpliktelse kan lagringsmodaliteten spørre om dataene den har overført er lagret sikkert. Bakgrunn: Hvert lagringssystem har en cache som i utgangspunktet buffrer innkommende data i et ustabilt dataminne. Det kan tenkes en situasjon der et bildedatasett i utgangspunktet ble fullstendig overført til PACS og lagret i hurtigbufferen. Imidlertid, hvis PACS eller lagringssystemet krasjer før innholdet er skrevet til den ikke-flyktige databæreren (for det meste harddisker), vil disse dataene være borte, selv om feilfri overføring ble rapportert tilbake til den sendende modaliteten. Siden det bare er nok lagringsplass på modaliteten i noen dager, kan bildene følgelig slettes der selv om de aldri ble lagret i PACS. Den Storage Engasjement melding utløses bare av PACS når data har ikke bare blitt mottatt i sin helhet, men har også blitt forsvarlig lagret på ikke-flyktige minner. På denne måten kan tap av data forårsaket av scenariet beskrevet ekskluderes.
Worklist Management (også kjent som MWL for Modality Worklist eller DICOM Modality Worklist )
Med arbeidslistehåndtering kan et planleggingssystem (typisk RIS ) sende en (for det meste bildebehandlings) enhet en liste over de neste undersøkelsene, sammen med pasientdataene. Dette eliminerer behovet for å legge inn pasientdata og den forespurte undersøkelsen på undersøkelsesenheten (f.eks. CT, MR, ultralyd).
Presentasjonstilstand lagring
Presentasjonsstatuslagring kan brukes til å overføre informasjon om hvordan et bilde ble eller skal vises. Presentasjonstilstander inkluderer f.eks. B. Informasjon om justering av gråtoner, merknader og markeringer og innzoomede detaljer.
Strukturert rapporteringslagring
Med strukturerte rapporter er det mulig å overføre et medisinsk funn i kodet form.
Hengende protokolllagring
Med Hanging Protocols Storage kan en konsistent representasjon av serien med bilder og studier lagres på forskjellige skjermer for forskjellige brukere.
Hanging Protocols Query / Retrieve
Med Hanging Protocols Query / Retrieve kan skjerminnstillinger søkes etter og overføres (sammenlign Query / Retrieve serviceklasse).

Fordeler med DICOM for brukere

DICOM skal garantere interoperabilitet mellom forskjellige medisinske applikasjoner ("applikasjonsenhet") .

Med DICOM som en åpen standard kommuniserer enheter som hovedsakelig brukes i medisinsk bildebehandling, uavhengig av systemplattformen som brukes eller produsenten. En bruker har dermed friheten til å bruke enhetene som han best kan løse oppgavene sine med.

DICOM kan også støtte arbeidsflyter i klinikker. "Arbeidsliste" -implementeringen i radiologi så vel som i laboratorieområdet har vist seg her i mange år. Dette muliggjør filmfritt arbeid og langsiktig arkivering i digitale systemer.

Erklæringer om samsvar

I samsvarserklæringer beskriver produsentene av systemer hvilke DICOM-funksjoner produktene deres støtter. En samsvarserklæring er et obligatorisk krav for påstanden om at en enhet eller et system er "DICOM-kompatibelt". Dette betyr imidlertid ikke automatisk at interoperabiliteten til en enhet er garantert. Normalt kan dette bare sikres ved å sammenligne flere samsvarserklæringer, eller ved hjelp av tilleggsdokumenter, for eksempel såkalte IHE- integrasjonsuttalelser.

DICOM foreskriver også hvordan samsvarserklæringer skal utarbeides, hvilken struktur de må ha og hvilken informasjon som skal inkluderes. En bruker med DICOM-kunnskap kan analysere samsvarserklæringen til enhetene sine (eller enhetene som skal anskaffes) og bruke dem til å spå om mulige datakommunikasjonsprosesser. Uttalelsene kan bare referere til delvise implementeringer.

Unike identifikatorer (UID)

DICOM identifiserer hvert informasjonsobjekt ved hjelp av unike identifikatorer (UID). UID er unike over hele verden i henhold til ISO-standard 9834-3. Dette oppnås ved at hver implementer må søke om en "UID Root", en rotoppføring som han deretter bygger sine identifikasjoner på. Dette betyr at bildedata kan identifiseres tydelig, og bildeserier og hele studier gis også UID. DICOMs egne objekter som dataobjektbeskrivelser og overføringssyntaks, som dataobjekter overføres eller utveksles med, har også sin egen UID. UID-formatene er definert av ISO 8824, DICOM-spesifikk informasjon finner du i kapittel 5, avsnitt 9 i dokumentasjonen.

DICOM-filsett

DICOM definerer ikke uavhengige "filer". Dataene som skal utveksles kan lagres som en fil, men bare som en del av et DICOM-filsett. Disse DICOM-filsettene kan eksistere på flyttbare medier, det er ingen standardisering for DICOM-filsystemer på harddisker eller nettverksaksjer - likevel har det blitt vanlig praksis blant produsenter å kunne håndtere individuelle filer fra DICOM-filsett; disse blir i sjargongen referert til som "DICOM-filer".

I et DICOM-filsett velges den laveste fellesnevneren for filsystemet. CD-er bør strengt overholde ISO 9660- standarden: Filnavnet skal bestå av maksimalt åtte tegn (store bokstaver, tall) og skal ikke ha noen filtype i det hele tatt . I tillegg må det på det laveste katalognivået ("File System Root") være en fil med navnet DICOMDIR, som igjen inneholder nøyaktig definert informasjon om innholdet og banen til filene på databæreren.

Når du arbeider med DICOM- filsettmedlemmer som uavhengige dataobjekter, har filutvidelser også blitt etablert, for eksempel .ima, .img og .dcm. Disse gjør det mulig for enkle programmer å tilordne filen basert på filtypen. Dette er imidlertid ikke en del av DICOM-standarddefinisjonen.

misligholde

historie

I løpet av utviklingen av digitale bildesystemer på begynnelsen av 1970-tallet, spesielt drevet av utviklingen av datortomografen av Godfrey Hounsfield , oppstod behovet for å kunne utveksle bildedata mellom systemer fra forskjellige produsenter. I 1982 grunnla American College of Radiology (ACR) for å representere brukernes interesser og National Electrical Manufacturers Association (NEMA), som fagforeningen for nordamerikanske produsenter, en arbeidsgruppe for å definere utveksling av digital bildeinformasjon.

I 1985 ble den første versjonen av ACR / NEMA-standarden utgitt, i 1988 en andre og med versjon 3.0 fra 1993 ble navnet endret fra "ACR-NEMA" til DICOM. Siden den gang har nye revisjoner av standarden dukket opp med jevne mellomrom, men begrepet "3.0" brukes ikke her, men heller publiseringsåret for den respektive versjonen. 2020C-standarden er for øyeblikket tilgjengelig.

struktur

DICOM-standarden, som er levert av NEMA (se nettlenker) i den nåværende versjonen, består av flere deler (per august 2011):

  • Del 1: Introduksjon og oversikt (Introduksjon og oversikt)
  • Del 2: Overensstemmelse (samsvar)
  • Del 3: Definisjoner av informasjonsobjekter ( definisjoner av informasjonsobjekt)
  • Del 4: Spesifikasjoner for serviceklasser (klasser for tjenestespesifikasjoner)
  • Del 5: Datastrukturer og koding (datastrukturer og koding)
  • Del 6: Data Dictionary (data ordbok)
  • Del 7: Meldingsutveksling (meldinger)
  • Del 8: Nettverkskommunikasjonsstøtte for meldingsutveksling (nettverkskommunikasjonsstøtte for datautveksling )
  • Del 9: Punkt-til-punkt-kommunikasjon (punkt-til-punkt-kommunikasjon)
  • Del 10: Medielagring og filformat for medieutveksling (lagring på media og filformat for medieutveksling)
  • Del 11: Medielagringsapplikasjonsprofiler (applikasjonsprofiler for lagring på media)
  • Del 12: Medieformater og fysiske medier for medieutveksling (medieformater og fysiske medier for medieutveksling)
  • Del 13: Støtte for kommunikasjon fra punkt til punkt (punkt-til-punkt kommunikasjonsstøtte med hensyn til utskriftsadministrasjon)
  • Del 14: Gråskala standard skjermfunksjon ( gråskala standard skjermfunksjon)
  • Del 15: Sikkerhets- og systemadministrasjonsprofiler (profiler for sikkerhet og systemadministrasjon)
  • Del 16: Innhold Mapping Resource (ressurstildeling for innhold)
  • Del 17: Forklarende informasjon (forklarende informasjon)
  • Del 18: Nettilgang til DICOM Persistent Objects (WADO )
  • Del 19: Programvare (programvare)
  • Del 20: Bilderapporter ved bruk av HL7 CDA (bilderapporter med HL7 CDA)
  • Del 21: Transformasjon av DICOM til og fra HL7-standarder (DICOM-transformasjon til og fra HL7- standarder)

Del 9 (punkt-til-punkt-kommunikasjonsstøtte for meldingsutveksling) og 13 (utskriftsadministrasjon punkt-til-punkt- kommunikasjonsstøtte) er ikke lenger inkludert i standarden.

Standardiseringsprosess

DICOM-standarden utvides fortsatt kontinuerlig av flere arbeidsgrupper for å møte den pågående utviklingen av medisinsk, maskinvare- og programvareteknologi. Det er for tiden 31 arbeidsgrupper (per januar 2018) som utvider DICOM med forskjellige underområder (se nedenfor). Medlemmer av arbeidsgruppene er ansatte fra medisinsk teknologiprodusenter, klinikker, universiteter og andre forskningsinstitusjoner. Som et eksempel handler den nåværende utviklingen av arbeidsgruppene Base Standard og radioterapi om innføring av en ny definisjon av arbeidsprosesser innenfor de forskjellige områdene til en klinikk og den nødvendige innføringen av nye DICOM-objekter.

Videre utvikling legges til standarden gjennom såkalte kosttilskudd . Disse blir først utarbeidet av en eller flere arbeidsgrupper og deretter sendt til Base Standard- arbeidsgruppen for gjennomgang. Hvis utvidelsen gir mening, tilordnes et nummer til tillegget. Så snart arbeidsgruppene har avsluttet endringene sine, blir de sendt til NEMA-medlemmene ( DICOM Voting Members ) som har stemmerett. Etter en positiv avstemning er informasjonen i tillegget gyldig og er innlemmet i den påfølgende versjonen av DICOM-standarden.

Endringer i standarden eller feil i dokumentene kan sendes til de forskjellige arbeidsgruppene ved hjelp av en endringsforespørsel og sendes også til medlemmene som har stemmerett av Base Standard- arbeidsgruppen .

Elementer fjernet fra DICOM-standarden (pensjonert) bør ikke lenger tas i betraktning i nye implementeringer. Generelt sett blir det imidlertid av grunner av nedoverkompatibilitet fjernet bare elementer som er i konflikt med andre konsepter i standarden, eller som aldri eller bare sjelden er implementert.

Arbeidsgruppene er:

  • DICOM standardkomité
  • WG-01: Informasjon om hjerte og kar
  • WG-02: Projeksjonsradiografi og angiografi
  • WG-03: Nuklearmedisin
  • WG-04: Kompresjon
  • WG-05: Exchange Media
  • WG-06: Base Standard
  • WG-07: Strålebehandling
  • WG-08: Strukturert rapportering
  • WG-09: Oftalmologi
  • WG-10: Strategisk rådgivning
  • WG-11: Standard skjermfunksjon
  • WG-12: Ultralyd
  • WG-13: Synlig lys
  • WG-14: Sikkerhet
  • WG-15: Digital mammografi og CAD
  • WG-16: Magnetisk resonans
  • WG-17: 3D
  • WG-18: Kliniske studier og utdanning
  • WG-19: Dermatologiske standarder
  • WG-20: Integrering av bildebehandling og informasjonssystemer
  • WG-21: Beregnet tomografi
  • WG-22: Tannlege
  • WG-23: Programvert
  • WG-24: Kirurgi
  • WG-25: Veterinærmedisin
  • WG-26: Patologi
  • WG-27: Webteknologi for DICOM
  • WG-28: Fysikk
  • WG-29: Utdanning, kommunikasjon og oppsøkende
  • WG-30: Små dyredannelse
  • WG-31: Overensstemmelse

DICONDE

DICONDE (Digital Imaging and Communications for Non-Destructive Evaluation) er en utvidelse av DICOM for ikke-destruktiv materialtesting. Pasientdataene erstattes av komponentdata. DICONDE er utviklet av ASTM International .

Definisjoner av begreper

IOD (definisjon av informasjonsobjekt)
Informasjonsobjekter representerer gjenstander fra den (virkelige) medisinske verdenen (f.eks. Pasient, studie, serie, bilde) og deres forhold til hverandre.
SC (serviceklasse)
Serviceklasser beskriver handlinger som kan utføres med informasjonsobjektene. Eksempler: Store, Print, Query, Retrieval, Modality Worklist, Storage Engagement, Modality Performed Procedure Step (MPPS). Det er ikke nødvendig å støtte alle serviceklasser for å kunne beskrive deg selv som "DICOM-kompatibel". De fleste applikasjoner og enheter støtter bare de serviceklassene som er nødvendige for den tiltenkte bruken.
SOP-klasse (klasse for serviceobjektpar)
Kombinasjonen av informasjonsobjekt og handlingen som skal utføres med det danner et service-objektpar (f.eks. "Lagre MR-bilde", "skriv ut ultralydbilde" osv.). SOP er de grunnleggende funksjonelle enhetene til DICOM.
Overfør syntaksen
Dataene kan utveksles i forskjellige datarepresentasjoner ved hjelp av overføringssyntakser. De beskriver hvordan tall og bildedata er representert, og om nødvendig hvordan bildedata komprimeres. DICOM bruker også innebygde formater som JFIF for dette formålet .
SCU (Service Class User)
En tjenesteklassbruker er en enhet eller et program som bruker en tjeneste.
SCP (Service Class Provider)
En tjenesteklasseleverandør er en enhet eller et program som tilbyr en tjeneste.
DICOM lagringstjenesteklasse
Serviceklasse, som inkluderer sending, mottak og lagring av medisinske bilder. Se også PACS (Picture Archiving and Communication System) .
DICOM Print Management Service Class
Serviceklasse, som inkluderer utskrift av medisinske bilder.
DICOM Worklist Management Service Class
Serviceklasse, som omhandler overføring av pasientdata fra inngangsstasjonen til den respektive modaliteten (f.eks. Ultralydanordning , CT ).
DICOM-verifiseringstjenesteklasse
Serviceklasse, som omhandler verifisering av nettverksforbindelsen mellom to DICOM-systemer. Denne prosessen blir ofte referert til som et ekko .
AE-tittel (tittel på applikasjonsenhet)
"Navn" på en DICOM-node.

Se også

  • HL7 (Health Level 7), internasjonal standard for utveksling av data mellom datasystemer i helsesektoren.
  • IHE (Integrating the Healthcare Enterprise), et initiativ for å bringe helsestandarder under ett tak.
  • IHE PDI (Portable Document Imaging), anbefalinger for utveksling av bærbare optiske medier med pasientbildedata i samsvar med DICOM-standarden.
  • OsiriX , DICOM-seer

weblenker

Commons : Digital Imaging and Communications in Medicine  - samling av bilder, videoer og lydfiler

Individuelle bevis

  1. ↑ varian.com
  2. ↑ gehealthcare.de
  3. ↑ freepatentsonline.com
  4. ↑ visus.com DICOM Samsvarserklæring