Digital Imaging and Communications in Medicine (DICOM; deutsch digitale Bildgebung und -kommunikation in der Medizin) ist ein offener Standard zur Speicherung und zum Austausch von Informationen im medizinischen Bilddatenmanagement. Diese Informationen können beispielsweise digitale Bilder, Zusatzinformationen wie Segmentierungen, Oberflächendefinitionen oder Bildregistrierungen sein. DICOM standardisiert sowohl das Format zur Speicherung der Daten als auch das Kommunikationsprotokoll zu deren Austausch.
Fast alle Hersteller bildgebender oder bildverarbeitender Systeme in der Medizin wie z. B. digitales Röntgen, Magnetresonanztomographie, Computertomographie oder Sonographie implementieren den DICOM-Standard in ihren Produkten. Dadurch wird im klinischen Umfeld Interoperabilität zwischen Systemen verschiedener Hersteller ermöglicht.
DICOM ist auch die Grundlage für die digitale Bildarchivierung in Praxen und Krankenhäusern (Picture Archiving and Communication System, PACS).
Datenformat
DICOM enthält neben Datenfeldern (z. B. Informationen über Bilder, Befunde, Patienten, Studien, Serien) auch die Syntax und Semantik von Kommandos und Nachrichten. Weiterhin legt der Standard Vorschriften für die Beschreibung von DICOM-kompatiblen Geräten und Software fest, da für jedes DICOM-kompatible Gerät eine exakte Beschreibung der Systemfähigkeit vorhanden und veröffentlicht sein muss (DICOM Conformance Statement).
Ein DICOM-Datensatz dient als Container, der außer einer oder mehrerer Objektdefinitionen auch Metainformationen wie Patientenname, Aufnahmedatum, Geräteparameter oder Arztname enthalten kann. Die Objektdefinitionen können Bilddaten, geometrische bzw. mathematische Informationen und auch behandlungsspezifische Informationen sein, wie beispielsweise in den sogenannten DICOM RT-Objekten, die selbst nur Behandlungsdaten enthalten und Bilddatensätze nur referenzieren.
DICOM speichert bzw. überträgt Bilder verlustlos oder verlustbehaftet, angelehnt an das TIFF-Format und die JPEG-Norm. Es kann Bildserien zusammenfassen. Die verschiedenen Kompressionsverfahren werden in eigenen Transfersyntaxen definiert.
Der DICOM-Standard erlaubt es auch, eigene, sogenannte private Objekte, Module oder Attribute zu definieren. Diese proprietären Informationen sind jedoch im Normalfall nicht mehr kompatibel mit Implementierungen anderer Hersteller.
Das Bild rechts basiert auf einer DICOM-Datei. Zur Anzeige wurde es in ein Standard-Grafikformat konvertiert.
Real World Information Model
DICOM fasst Daten in einem sogenannten Real World Information Model auf, das in die Stufen Patient, Studie, Serie und Instanz unterteilt ist. Jede Instanz eines DICOM-Objektes hält somit alle Informationen, um sie einer bestimmten Serie (beispielsweise Bild-Serie), Studie (einem bestimmten Aufenthalt im Klinikum bzw. einer einzelnen Untersuchung) und Patienten zuordnen zu können.
Die Eindeutigkeit der Information wird anhand von eindeutigen Kennzeichnern (Unique Identifier) umgesetzt.
Information Object Definition
Alle Objekte in DICOM werden über eine sogenannte Information Object Definition festgelegt. Diese besteht aus mehreren Modulen, die wiederum einzelne Attribute bzw. Sequenzen von Attributen enthalten.
Es wird hierbei zwischen normalisierten (Normalized) und zusammengesetzten (Composite) Objekten unterschieden. Normalisierte Objekte stimmen mit Objekten der realen Welt überein, während zusammengesetzte Objekte Attribute enthalten, die zwar durchaus mit dem Objekt der realen Welt in Verbindung stehen, ihnen aber nicht unmittelbar zuzuordnen sind.
Die Composite-Objekte haben normalerweise alle die folgenden Module gemein: SOP Common, Patient, Study, Series und Equipment. Weitere Module variieren je nach Modalität des Objektes. Über diese, auch Header-Information genannten Module, lässt sich jedes beliebige Objekt eindeutig einem bestimmten Vorgang zuordnen.
Module Definition
Modul-Definitionen gruppieren DICOM-Attribute in logischen Einheiten. So enthält beispielsweise das Patienten-Modul alle den Patienten betreffende Informationen, wie beispielsweise Name, ID, Geschlecht oder Alter. Module können in verschiedenen Composite-Objekten wiederverwendet werden. In jeder Definition eines Composite-Objektes ist auch definiert, ob ein bestimmtes Modul zwingend notwendig ist und vorhanden sein muss (M – Mandatory), ob das Vorhandensein an bestimmte Bedingungen geknüpft ist (C – Conditional) oder ob es im Ermessen des Anwenders liegt (U – User Option).
Modul-Definitionen sind im DICOM-Standard in Kapitel 3 zu finden.
Attribute Definition
Ein Attribut wird über eine festgelegte achtstellige Hexadezimalzahl, ein sogenanntes Data Tag definiert. Die ersten vier Stellen definieren die Zugehörigkeit des Attributes zu einer bestimmten Gruppe (wie beispielsweise File Meta Information), die weiteren vier bestimmen das Element. Zur besseren Lesbarkeit wird ein DICOM Data Tag normalerweise in der Form (aaaa,bbbb) mit einem Komma in der Mitte dargestellt. Somit entspricht das Tag 0x00100010 – Patient’s Name – dem Dezimalwert 1048592 und wird als (0010,0010) dargestellt.
DICOM-Standard-Attribute haben immer eine geradzahlige Gruppenzahl, wobei die Gruppen 0000, 0002, 0004 und 0006 für DIMSE-Kommandos und DICOM File Sets reserviert sind. Ungerade Gruppenzahlen sind privaten Datenelementen vorbehalten, die durch jeden Implementierer vergeben werden können.
Ein weiteres Charakteristikum eines Attributes ist dessen Value Representation (VR), beispielsweise DS (Decimal String), IS (Integer String) oder ST (Short Text). Hierzu gehört die maximal mögliche Länge eines Feldes und der erlaubte Zeichensatz, bzw. explizit nicht erlaubte Zeichen.
Des Weiteren ist die Definition der Value Multiplicity (VM), d. h. der Multiplizität eines Attributes notwendig. Als Beispiel hat die Angabe eines Winkels innerhalb eines Decimal String die Multiplizität 1. Eine Koordinate, ebenfalls vom Typ DS, hat die Multiplizität 3, um die Position in allen Raumrichtungen angeben zu können.
Die vierte notwendige Eigenschaft ist der Typ des Elements. Es gibt die Unterscheidungen zwischen Typ 1 – zwingend notwendig und Inhalt muss vorhanden sein –, Typ 2 – zwingend notwendig, kann aber leer sein – und Typ 3 – nicht zwingend notwendig. Des Weiteren können die Typen durch den Zusatz des Buchstabens C („1C“, „2C“) an Bedingungen geknüpft werden. Daraus ergibt sich dann, dass beispielsweise ein Element des Typs 1 auch tatsächlich nur zwingend vorhanden sein muss, wenn die in der dazugehörigen Beschreibung definierte Bedingung auch tatsächlich erfüllt ist.
Während die Value Representation und die Value Multiplicity konstant bleiben, kann sich der Typ ändern, je nachdem in welchem Modul das Attribut verwendet wird. Bedingungen für die Typen 1C und 2C können sich somit auch entsprechend ändern und sind in der jeweiligen Modul-Definition in der Beschreibung des Attributes einzeln aufgeführt.
Beispiele
- (0010,0010) – Patient’s Name, VR: PN, VM: 1, Type: 2
- (0010,0020) – PatientID, VR: LO, VM: 1, Type: 2
- (0010,0021) – IssuerOfPatientID, VR: LO, VM: 1, Type: 2
Attribut- und dazugehörige Typ-Definitionen sind im DICOM-Standard in Kapitel 3 zu finden. Value Representation und Value Multiplicity sind für alle Attribute in Kapitel 6 definiert. Die Definitionen der Value Representation-Werte sind in Kapitel 5 „Data Structures and Encoding“ aufgeführt.
Dienstklassen
Die im DICOM-Standard definierten Service Classes bezeichnen verschiedene Dienste. Werden diese auf ein Objekt angewandt, bilden sie eine Dienstgruppe. Es gibt folgende Dienste:
- Verify
- Store
- Query/Retrieve
- Procedure Step (Notification)
- Print Management
- Media Storage Management
- Storage Commitment
- Worklist Management
- Presentation State Storage
- Structured Reporting Storage
- Application Event Logging
- Relevant Patient Information Query
- Instance Availability Notification
- Media Creation Management
- Hanging Protocols Storage
- Hanging Protocols Query/Retrieve
- Substance Administration Query
(Beschreibungen finden sich in Part 4 des Standards, kursiv gesetzte Serviceklassen sind von geringerer Bedeutung oder werden von Geräteherstellern noch nicht weitgehend unterstützt).
Die wichtigsten Dienste
- Verify
- Mit Verify kann überprüft werden, ob ein externer Netzwerkknoten DICOM mit den konfigurierten Parametern unterstützt.
- Storage
- Der Storage Service speichert einen Großteil der persistenten Datenobjekte.
- Query/Retrieve
- Mit Query und Retrieve kann ein PACS oder ein anderes DICOM Gerät nach Objekten durchsucht werden (Query) und gefundene Objekte dann auf ein anderes Gerät übertragen werden (Retrieve).
- Procedure Step (abgekürzt auch MPPS für Modality performed procedure Step)
- Mittels Procedure Steps können DICOM-Geräte andere über durchgeführte Untersuchungsschritte benachrichtigen. Typischerweise werden diese Prozeduren auf einer Worklist dem Gerät zur Bearbeitung mitgeteilt, das diese dann ausführt, abbricht oder ändert. Diese Information kann per Performed Procedure Step Notification an das planende System übermittelt werden.
- Storage Commitment
- Mittels Storage Commitment kann die speichernde Modalität abfragen, ob die von ihr übermittelten Daten sicher gespeichert wurden. Hintergrund: Jedes Speichersystem verfügt über einen Cache, der eingehende Daten zunächst in einem flüchtigen Datenspeicher zwischenpuffert. Es ist eine Situation denkbar, bei der ein Bilddatensatz zunächst vollständig an das PACS übergeben und im Cache gespeichert wurde. Stürzt das PACS bzw. das Speichersystem aber ab, bevor der Inhalt auf die nichtflüchtigen Datenträger (meist Festplatten) geschrieben wurde, wären diese Daten weg, obwohl an die übermittelnde Modalität eine fehlerfreie Übertragung rückgemeldet wurde. Da der Speicherplatz an der Modalität nur für wenige Tage ausreichend ist, könnten die Bilder folglich dort gelöscht werden, obwohl sie nie im PACS gespeichert wurden. Die Meldung Storage Commitment wird vom PACS erst ausgelöst, wenn die Daten nicht nur vollständig empfangen, sondern auch sicher auf nichtflüchtigen Speichern abgelegt wurden. Damit kann ein durch das beschriebene Szenario verursachter Datenverlust ausgeschlossen werden.
- Worklist Management (auch MWL für Modality Worklist oder auch DICOM Modality Worklist genannt)
- Mit Worklist Management kann ein planendes System (typischerweise das RIS) einem (meist bildgebenden) Gerät eine Liste der nächsten Untersuchungen, zusammen mit den Patientendaten übermitteln. Damit entfällt die Eingabe der Patientendaten und der angeforderten Untersuchung am Untersuchungsgerät (z. B. CT, MR, Ultraschall).
- Presentation State Storage
- Mit Presentation State Storage kann Information übermittelt werden, wie ein Bild dargestellt wurde oder dargestellt werden soll. Presentation States beinhalten z. B. Informationen zum Graustufenabgleich, zu Anmerkungen und Markierungen und zu Ausschnittvergrößerungen.
- Structured Reporting Storage
- Mit Structured Reports ist es möglich, einen medizinischen Befund kodiert zu übermitteln.
- Hanging Protocols Storage
- Mit Hanging Protocols Storage kann eine konsistente Darstellung der Bilderserien und Studien auf verschiedenen Anzeigen für verschiedene Benutzer gespeichert werden.
- Hanging Protocols Query/Retrieve
- Mit Hanging Protocols Query/Retrieve können Anzeigeeinstellungen gesucht und übertragen werden (vergleiche Query/Retrieve Serviceklasse).
Nutzen von DICOM für Anwender
DICOM soll die Interoperabilität zwischen verschiedenen medizinischen Anwendungen („application entity“) gewährleisten.
Mit DICOM als offenem Standard kommunizieren Geräte primär der bildgebenden Medizin unabhängig von der verwendeten Systemplattform oder dem Hersteller. Ein Anwender hat somit die Freiheit, die Geräte zu verwenden, mit denen er seine Aufgaben am besten lösen kann.
DICOM kann auch Arbeitsabläufe in Kliniken unterstützen. Bewährt hat sich hier seit vielen Jahren die „Worklist“-Implementierung in der Radiologie, wie auch im Laborbereich. Dies ermöglicht ein filmfreies Arbeiten und die Langzeitarchivierung in digitalen Systemen.
Konformitätserklärungen
In Konformitätserklärungen beschreiben die Hersteller von Systemen, welche DICOM-Funktionen ihre Produkte unterstützen. Eine Konformitätserklärung ist zwingende Voraussetzung für die Behauptung, dass ein Gerät oder System „DICOM-fähig“ ist. Dies bedeutet jedoch nicht automatisch, dass die Interoperabilität eines Gerätes gewährleistet ist. Dies lässt sich im Normalfall nur durch den Abgleich mehrerer Konformitätserklärungen sicherstellen, oder durch weiterführende Dokumente, wie beispielsweise sogenannte IHE Integration Statements.
DICOM schreibt ebenfalls vor, wie Konformitätserklärungen zu verfassen sind, welche Struktur sie haben müssen und welche Information enthalten sein muss. Ein Anwender mit DICOM-Kenntnissen kann die Konformitätserklärungen seiner Geräte (oder der zu beschaffenden Geräte) analysieren und daraus Vorhersagen über die möglichen Datenkommunikationsvorgänge treffen. Die Statements können sich auch nur auf Teilimplementierungen beziehen.
Unique Identifiers (UIDs)
DICOM identifiziert jedes Informationsobjekt durch Unique Identifiers (UIDs). UIDs sind weltweit eindeutig entsprechend ISO-Standard 9834-3. Das wird erreicht, indem jeder Implementierer eine „UID Root“, einen Stammeintrag beantragen muss, auf dem er dann seine Identifikationen aufbaut. Damit sind Bilddaten eindeutig identifizierbar, auch Bildserien und ganze Untersuchungen (Studies) bekommen UIDs. Die DICOM-eigenen Objekte wie Datenobjekt-Beschreibungen und Transfersyntaxen, mit denen Datenobjekte übertragen oder ausgetauscht werden, haben ebenfalls eine eigene UID. Das Format der UIDs wird durch ISO 8824 definiert, DICOM-spezifische Informationen dazu befinden sich in Kapitel 5, Sektion 9 der Dokumentation.
DICOM File Sets
DICOM definiert keine unabhängigen „Dateien“. Die auszutauschenden Daten können als Datei gespeichert werden, aber nur als Teil eines DICOM File Sets. Diese DICOM File Sets können auf Wechseldatenträgern existieren, eine Standardisierung für DICOM-Dateisysteme auf Festplatten oder Netzwerkfreigaben gibt es nicht – trotzdem hat sich unter den Herstellern eingebürgert, auch mit einzelnen Dateien aus DICOM File Sets umgehen zu können; diese werden im Jargon dann als „DICOM-Dateien“ bezeichnet.
In einem DICOM File Set wird der kleinste gemeinsame Nenner für das Dateisystem gewählt. CDs sollten streng der ISO 9660 Norm entsprechen: Der Dateiname sollte aus max. acht Zeichen (Großbuchstaben, Ziffern) bestehen und überhaupt keine Dateiendung tragen. Zusätzlich muss im niedrigsten Verzeichnis-Niveau („File System Root“) eine Datei mit dem Namen DICOMDIR liegen, die ihrerseits genau festgelegte Informationen über Inhalt und Pfad der Dateien auf dem Datenträger enthält.
Im Umgang mit DICOM File Set Members als selbständige Datenobjekte haben sich aber auch Dateiendungen etabliert, beispielsweise .ima, .img und .dcm. Diese ermöglichen einfachen Programmen die Datei anhand der Dateiendung zuzuordnen. Dies ist jedoch kein Teil der DICOM-Standard-Definition.
Standard
Geschichte
Im Zuge der Entwicklung digitaler Bildgebungssysteme zu Beginn der 1970er Jahre, allen voran getrieben durch die Entwicklung des Computertomographen durch Godfrey Hounsfield, erwuchs der Bedarf Bilddaten zwischen Systemen verschiedener Hersteller austauschen zu können. Daraufhin gründeten 1982 das American College of Radiology (ACR) als Interessenvertretung der Anwender und die National Electrical Manufacturers Association (NEMA) als Berufsverband der nordamerikanischen Hersteller eine Arbeitsgruppe, die den Austausch digitaler Bildinformationen definieren sollte.
1985 wurde die erste Version des ACR/NEMA-Standards veröffentlicht, 1988 eine zweite und mit der Version 3.0 von 1993 erfolgte die Umbenennung von „ACR-NEMA“ in DICOM. Seither erscheinen in regelmäßigen Abständen neue Revisionen des Standards, doch verwendet man hierbei nicht die Bezeichnung „3.0“, sondern man bezieht sich auf das Erscheinungsjahr der jeweiligen Version. Hintergrund ist, dass der Standard grundsätzlich nur abwärtskompatible Änderungen aufnimmt, und so keine neue „Major Version“ notwendig sein sollte. Neuere Ausgaben werden als „Editions“ herausgegeben, die aus einer Jahreszahl und einem angehängten Buchstaben bestehen. Aktuell (Stand Januar 2022) ist „Edition 2021e“ erhältlich.
Struktur
Der DICOM-Standard, der bei der NEMA (siehe Weblinks) in der aktuellen Fassung bereitgestellt wird, besteht aus mehreren Teilen (Stand August 2011):
- Part 1: Introduction and Overview (Einführung und Überblick)
- Part 2: Conformance (Konformität)
- Part 3: Information Object Definitions (Informationsobjekt Definitionen)
- Part 4: Service Class Specifications (Serviceklassen Spezifikationen)
- Part 5: Data Structures and Encoding (Datenstrukturen und Kodierung)
- Part 6: Data Dictionary (Datenlexikon)
- Part 7: Message Exchange (Nachrichtenaustausch)
- Part 8: Network Communication Support for Message Exchange (Netzwerkkommunikationsunterstützung für Datenaustausch)
- Part 9: Point to Point Communication (Punkt-zu-Punkt Kommunikation)
- Part 10: Media Storage and File Format for Media Interchange (Speicherung auf Medien und Dateiformat für den Medienaustausch)
- Part 11: Media Storage Application Profiles (Anwendungsprofile für die Speicherung auf Medien)
- Part 12: Media Formats and Physical Media for Media Interchange (Medienformate und physische Medien für den Medienaustausch)
- Part 13: Print Management Point to Point Communication Support (Punkt-zu-Punkt Kommunikationsuntersützung bezüglich des Druckmanagements)
- Part 14: Grayscale Standard Display Function (Grauskala-Standard-Anzeigefunktion)
- Part 15: Security and System Management Profiles (Profile für Sicherheit und Systemmanagement)
- Part 16: Content Mapping Resource (Hilfsquelle zur Inhaltszuordnung)
- Part 17: Explanatory Information (Erklärende Informationen)
- Part 18: Web Access to DICOM Persistent Objects (WADO) (Web-Zugriff auf persistente DICOM-Objekte (WADO))
- Part 19: Application Hosting (Hosting von Anwendungen)
- Part 20: Imaging Reports using HL7 CDA (Bild-Berichte mit HL7 CDA)
- Part 21: Transformation of DICOM to and from HL7 Standards (Transformation von DICOM zu und von HL7-Standards)
Die Teile 9 (Point to Point Communication Support for Message Exchange) und 13 (Print Management Point-to-Point Communication Support) sind nicht mehr im Standard enthalten.
Standardisierungsvorgang
Der DICOM-Standard wird noch heute von mehreren Arbeitsgruppen kontinuierlich erweitert, um der fortwährenden Entwicklung von Medizin-, Hard- und Softwaretechnologie zu begegnen. Derzeit existieren 31 Arbeitsgruppen (Stand: Jan. 2018), die DICOM um verschiedene Teilbereiche (siehe unten) erweitern. Mitglieder der Arbeitsgruppen sind Mitarbeiter von Medizintechnik-Herstellern, Kliniken, Universitäten und anderen Forschungseinrichtungen. Als Beispiel befassen sich die aktuellen Entwicklungen der Arbeitsgruppen Base Standard und Radiotherapy mit der Einführung einer neuen Definition von Arbeitsabläufen innerhalb der verschiedenen Domänen einer Klinik und der damit notwendigen Einführung neuer DICOM-Objekte.
Weiterentwicklungen werden durch sogenannte Supplements dem Standard hinzugefügt. Diese werden zunächst von einer oder mehrerer Arbeitsgruppen verfasst und dann der Arbeitsgruppe Base Standard zur Sichtung vorgelegt. Erscheint die Erweiterung sinnvoll, wird dem Supplement eine Nummer zugeteilt. Sobald die Arbeitsgruppen ihre Zusätze finalisiert haben, werden diese den stimmberechtigten NEMA-Mitgliedern (DICOM Voting Members) zur Abstimmung vorgelegt. Nach einer positiven Abstimmung erhält die Information innerhalb des Zusatzes Gültigkeit und wird in die darauffolgende Version des DICOM-Standards eingearbeitet.
Änderungen am Standard oder Fehler in den Dokumenten können bei den verschiedenen Arbeitsgruppen durch ein Änderungsgesuch eingereicht werden und werden ebenfalls durch die Arbeitsgruppe Base Standard den stimmberechtigten Mitgliedern vorgelegt.
Aus dem DICOM-Standard entfernte Elemente (retired) sollen bei Neuimplementierungen nicht mehr berücksichtigt werden. Generell werden jedoch aus Gründen der Abwärtskompatibilität nur Elemente entfernt, die im Konflikt mit anderen Konzepten des Standards stehen oder nie bzw. nur selten implementiert wurden.
Die Arbeitsgruppen sind:
- DICOM Standards Committee
- WG-01: Cardiac and Vascular Information
- WG-02: Projection Radiography and Angiography
- WG-03: Nuclear Medicine
- WG-04: Compression
- WG-05: Exchange Media
- WG-06: Base Standard
- WG-07: Radiotherapy
- WG-08: Structured Reporting
- WG-09: Ophthalmology
- WG-10: Strategic Advisory
- WG-11: Display Function Standard
- WG-12: Ultrasound
- WG-13: Visible Light
- WG-14: Security
- WG-15: Digital Mammography and CAD
- WG-16: Magnetic Resonance
- WG-17: 3D
- WG-18: Clinical Trials and Education
- WG-19: Dermatologic Standards
- WG-20: Integration of Imaging and Information Systems
- WG-21: Computed Tomography
- WG-22: Dentistry
- WG-23: Application Hosting
- WG-24: Surgery
- WG-25: Veterinary Medicine
- WG-26: Pathology
- WG-27: Web Technology for DICOM
- WG-28: Physics
- WG-29: Education, Communication and Outreach
- WG-30: Small Animal Imaging
- WG-31: Conformance
DICONDE
DICONDE (Digital Imaging and Communications for Non-Destructive Evaluation) ist eine Erweiterung von DICOM für zerstörungsfreie Materialprüfung. Dabei werden die Patientendaten durch Komponentendaten ersetzt. DICONDE wird von der ASTM International entwickelt.
Begriffsdefinitionen
- IOD (Information Object Definition)
- Informationsobjekte repräsentieren Objekte der (realen) medizinischen Welt (z. B. Patient, Study, Series, Image) und deren Beziehungen zueinander.
- SC (Service Class)
- Dienstklassen beschreiben Aktionen, welche mit den Informationsobjekten ausgeführt werden können. Beispiele: Store, Print, Query, Retrieval, Modality Worklist, Storage Commitment, Modality Performed Procedure Step (MPPS). Es ist nicht notwendig alle Dienstklassen zu unterstützen um sich als „DICOM-kompatibel“ bezeichnen zu dürfen. Die meisten Applikationen bzw. Geräte unterstützen nur jene Dienstklassen, die für ihren Verwendungszweck notwendig sind.
- SOP Class (Service Object Pair Class)
- Die Kombination aus Informationsobjekt und die damit auszuführende Aktion bildet ein Service-Object-Paar (z. B. „MR-Bild speichern“, „Ultraschallbild drucken“ etc.). SOPs bilden die funktionellen Grundeinheiten von DICOM.
- Transfer Syntax
- Die Daten können in unterschiedlichen Datenrepräsentationen ausgetauscht werden, dazu dienen Transfer Syntaxes. In ihnen wird beschrieben, wie Zahlen und Bilddaten repräsentiert werden und wie gegebenenfalls Bilddaten komprimiert werden. Dazu nützt DICOM auch eingebettete Formate wie JFIF.
- SCU (Service Class User)
- Ein Service Class User ist ein Gerät bzw. eine Applikation, die einen Dienst in Anspruch nimmt.
- SCP (Service Class Provider)
- Ein Service Class Provider ist ein Gerät bzw. eine Applikation, die einen Dienst anbietet.
- DICOM Storage Service Class
- Service Class, die das Versenden, Empfangen und Abspeichern von medizinischen Bildern umfasst. Siehe auch PACS (Picture Archiving and Communication System).
- DICOM Print Management Service Class
- Service Class, die das Drucken von medizinischen Bildern umfasst.
- DICOM Worklist Management Service Class
- Service Class, die sich mit der Übertragung von Patientendaten von der Eingabestation zu der jeweiligen Modalität (Bsp.: Ultraschallgerät, CT) befasst.
- DICOM Verification Service Class
- Service Class, die sich mit der Verifikation der Netzwerkverbindung zweier DICOM Systeme befasst. Dieser Vorgang wird oft auch als Echo bezeichnet.
- AE Title (Application Entity Title)
- „Name“ eines DICOM Knotens.
Siehe auch
- HL7 (Health Level 7), internationaler Standard für den Austausch von Daten zwischen Computersystemen im Gesundheitswesen.
- IHE (Integrating the Healthcare Enterprise), eine Initiative, um die Standards im Gesundheitswesen unter einen Hut zu bringen.
- IHE PDI (Portable Document Imaging), Empfehlungen zum Austausch von portablen optischen Medien mit Patientenbilddaten konform zum DICOM-Standard.
- OsiriX, DICOM-Viewer
Weblinks
- DICOM-Seite der NEMA
- Aktueller Zustand der Supplements und Change Proposals
- Aufbau des Kopfdatenbereiches
- Verzeichnis freier medizinischer Bildverarbeitungssoftware
- DICOM cookbook by Phillips
- DICOM Standard Browser Zur Suche und für die Erklärung von DICOM-Tags sowie Analyse von Dicom-Dateien