EDV06 DICOM Standard und DICOM Services WS 2024 PDF

EDV in der Radiologietechnologie: WS 2024 EDV06: DICOM Standard und DICOM Services Christopher Piribauer MSc. – [email protected] Weiterführende Literatur DICOM Digital Imaging and Communications in Medicine (DICOM) - Oleg S. Pianykh, Ph.D. ISBN 978-3-642-10849-5 Offizielle DICOM St...

EDV in der Radiologietechnologie: WS 2024 EDV06: DICOM Standard und DICOM Services Christopher Piribauer MSc. – [email protected] Weiterführende Literatur DICOM Digital Imaging and Communications in Medicine (DICOM) - Oleg S. Pianykh, Ph.D. ISBN 978-3-642-10849-5 Offizielle DICOM Standard - https://www.dicomstandard.org/current (Stand 13.11.2022: DICOM 2022d) 2 Inhalt DICOM Einleitung Geschichte Aufbau Kommunikation − Real World Information Model − AET und TCP/IP − Information Object Definition − DICOM Services − DICOM Element − Transfer Syntax − DICOM Data Directory − SOP Classes − DICOM Module − Conformance Statement 3 Einführung Wozu DICOM? 4 Einführung Wozu DICOM? 5 Einführung Wozu DICOM? 6 Einführung DICOM = Digital Imaging and COmmunication in Medicine DICOM ist ein Standard zur Verwaltung, Speicherung und Übertragung von medizinischen Bilddaten. Er definiert dabei nicht nur das verwendete Dateiformat und die Struktur der DICOM Daten sondern auch das einzusetzende Protokoll und die zugehörige Syntax für die Netzwerkkommunikation. Ziel des Standards ist es ein universell einsetzbares und herstellerunabhängiges Format zur Speicherung und Übertragung von medizinischen Bilddaten auch zwischen verschiedenen Kliniken und Instituten zu gewährleisten. 7 Geschichte ACR-NEMA 1983 gegründetes Konsortium zwischen dem American College of Radiology (ACR) und der National Electrical Manufacturers Association (NEMA) Ziel eines einheitlichen Standards für den Austausch von medizinischen Bilddaten unabhänging vom Gerätehersteller 1985 Veröffentlichung von ACR-NEMA v1.0 mit minimaler Definition 1988 ACR-NEMA v2.0 wird veröffentlicht 8 Geschichte DICOM = Digital Imaging and COmmunication in Medicine 1993 Veröffentlichung von ACR-NEMA v3.0, erstmal unter dem Namen DICOM und seitdem als DICOM Standard bekannt. Erstmals wurde der Betrieb in verteilten Netzwerken unterstützt (Support von TCP/IP) Seit 1995 wird der modular aufgebaute Standard fortlaufende durch das DICOM Standard Komitee weiterentwickelt. Mittlerweile umfasst dieser 22 Module, welche teilweise bereits obsolet sind aus Kompatibilitätsgründen aber weiterhin unterstützt werden. 9 Einführung DICOM = Digital Imaging and COmmunication in Medicine DICOM Part 1: Introduction and Overview DICOM Part 14: Grayscale Standard Display Function DICOM Part 2: Conformance DICOM Part 15: Security and System Management Profiles DICOM Part 3: Information Object Definitions DICOM Part 16: Content Mapping Resource DICOM Part 4: Service Class Specifications DICOM Part 17: Explanatory Information DICOM Part 5: Data Structures and Encoding DICOM Part 18: Web Services DICOM Part 6: Data Dictionary DICOM Part 19: Application Hosting DICOM Part 7: Message Exchange DICOM Part 20: Imaging Report using HL7 Clinical Document DICOM Part 8: Network Communication Support for Message Architecture Exchange DICOM Part 21: Transformations between DICOM and other DICOM Part 10: Media Storage and File Format for Media Representations Intergange DICOM Part 22: Real-Time Communication DICOM Part 11: Media Storage Application Profiles DICOM Part 12: Media Formats and Physical Media for Media Interchange 10 Aufbau Real World Information Model Patient Patient unterzieht sich einer Untersuchung (=Study) Study Studie besteht aus mehreren Sequenzen (=Serie) Serie wiederum besteht aus einem oder Serie Serie Serie mehreren Bildern (=Instance) Instances Instances Instances Aufbau Information Object Definition DICOM Daten bestehen neben Bilddaten aus Vielzahl anderer Attribute, welche Informationen über Patienten, Study, Serie, usw. zur Verfügung stellt Definiert je nach Art der Bilder über die IOD (Information Object Definition) IODs sind zusammengesetzt aus Modulen, z.B. Patient Module, Series Module, … Module definieren die DICOM Elemente und Attribute, welche darin enthalten sind Aufbau Information Object Definition MR Image IOD Patient Module - Patient (M) Module können Mandatory (M) oder User Optional (U) definiert sein Clinical Trial Subject Module - Patient (U) Abhängig von Patient oder der durchgeführten General Study Module - Study (M) Image Study Z.B. ist Clinical Trial Subject nur von Relevanz, wenn Patient Study Module - Study (U) Patient an einer klinischen Studie … … 13 Aufbau DICOM Element (Quelle: DICOM NEMA 2020) DICOM Files sind seriell aufgebaut, d.h. es wird ein Data Element nach dem anderen, geordnet nach dem Data Tag, im File angeordnet. Jedes Data Element wird durch seinen Tag unterschieden und muss entsprechend eindeutig sein. 14 Aufbau DICOM Element – Tag (Quelle: DICOM NEMA 2020) Der Tag besteht aus zwei 16-Bit Zahlen, welche die Gruppe und das Element in der Gruppe in 2 x 4 Hexadezimalzeichen darstellen. Erste 4 Zeichen identifizieren die Gruppe, z.B. 0010 für Data Elements aus der Patient Group Zweite 4 Zeichen identifizieren das Element innerhalb der Gruppe, z.B. 0030 für das Geburtsdatum des Patienten (0010, 0030) → Patient‘s Birth date 15 Aufbau DICOM Element – Tag (Quelle: DICOM NEMA 2020) Sinn der Gruppe ist das Zusammenfassen von Datenelementen entsprechend ihres Verwendungsbereichs Public Tags sind eindeutig im Standard definiert und besitzen durchgehend gerade Gruppennummern und sind daher eindeutig als diese identifizierbar Firmen können auch eigene Tags in ihren DICOM Daten verwenden (Private Tags), diese müssen aber mit ungeraden Gruppennummern beginnen, damit diese entsprechend als diese erkannt werden 16 Aufbau DICOM Element – Value Representation (Quelle: DICOM NEMA 2020) Die Value Representation (VR) definiert den Datentyp des Wertes eines Data Elements. Im DICOM Standard sind 34 verschiedene VR Typen definiert, diese sind in Part 5 des Standards definiert. Alle Datenelemente eines DICOM Files müssen einer dieser VR Typen zugeordnet sein und definieren, wie und in welchem Format diese dort abgelegt werden müssen. 17 Aufbau DICOM Element – Value Representation VR Name Definition Character Repertoire String im Format YYYYMMDD; wobei YYYY = Jahr, MM = Monat und DD = Tag, nach dem gregorianischen Kalender. "0"-"9" aus dem Standard DA Date Beispiel: Characterset. "19930822" repräsentiert August 22, 1993. Bei menschlichen Patienten: Familienname, Vorname, Mittelame, PN Standard Characterset wie in Namensprefix, Namenssuffix. Person Name Dataelement (0008,0005) Teile davon können auch leer sein. Als Trennzeichen wird das "^" (character definiert. (5EH)) verwendet. … … … 18 Aufbau DICOM Element – Value Length (Quelle: DICOM NEMA 2020) Das Feld Value Length gibt die explizite Länge des Value Fields dieses Data Elements an. 19 Aufbau DICOM Element – Value Field (Quelle: DICOM NEMA 2020) Im Value Field wird der tatsächliche Wert des Data Elements eingetragen Besteht immer aus einer geraden Anzahl an Bytes Inhalt ist durch die Value Representation spezifiziert 20 Aufbau DICOM Data Directory Sämtliche verfügbare Data Elements werden im DICOM Data Directory aufgelistet, welches Teil von Part 6 im DICOM Standard ist. Zusätzlich zum Namen bzw. dem Keyword des Elements kann dort auch die Value Representation (VR) und auch die Value Multiplicity (VM) gefunden werden. Auszug: Tag Name Keyword VR VM (0010,0010) Patient’s Name PatientName PN 1 (0010,0020) Patient ID PatientID LO 1 (0010,0021) Issuer of Patient ID IssuerOfPatientID LO 1 (0010,0022) Type of Patient ID TypeOfPatientID CS 1 (0010,1000) Other Patient IDs OtherPatientIDs LO 1-n Die Value Multiplicity definiert dabei, wie oft ein Element dabei innerhalb eines Files vorkommen darf. 21 Aufbau DICOM Module DICOM Module werden definiert, um ähnliche Information in logischen Containern zusammenzufassen Z.B. gruppiert das Patient Module alle Data Elements, welche notwendig sind um den Patienten zu beschreiben Auszug: Attribute Tag Type Attribute Description Patient‘s Name (0010,0010) 2 Patient's full name. Patient ID (0010,0020) 2 Primary identifier for the Patient. Patient‘s Birth Date (0010,0030) 2 Birth date of the Patient. Patient‘s Sex (0010,0040) 2 Sex of the named Patient. Enumerated Values: M = male, F = female, O = Other Patient's Birth Time (0010,1001) 3 Other names used to identify the Patient. 22 Aufbau DICOM Module – Data Element Type Der Type des Data Elements innerhalb der Module Definition, definiert welche Vorgaben an das Element gestellt wird. Dabei kann dieser folgende Werte einnehmen. Type Bedingung Beschreibung Notwendiges Feld, welches einen gültigen Wert laut der in PS3.6 definierten VR und VM des Elements haben muss. Ein 1 Required fehlen des Elements stellt eine Verletzung des Standards da. Unter einer definierten Bedingung notwendiges Feld, welches einen gültigen Wert laut der in PS3.6 definierten VR und VM 1C Conditional des Elements haben muss. Ein fehlen des Elements stellt eine Verletzung des Standards da, sofern die Bedingung erfüllt ist. Notwendiges Feld, welches einen gültigen Wert laut der in PS3.6 definierten VR und VM des Elements haben muss. Im Falle, 2 Required dass der Wert nicht bekannt ist, kann diese Feld auch leer gelassen werden oder mit einem Leerstring befüllt werden. Ein fehlen des Elements stellt eine Verletzung des Standards da. Unter einer definierten Bedingung notwendiges Feld, welches einen gültigen Wert laut der in PS3.6 definierten VR und VM des Elements haben muss. Im Falle, dass der Wert nicht bekannt ist, kann diese Feld auch leer gelassen werden oder mit 2C Conditional einem Leerstring befüllt werden. Ein fehlen des Elements stellt eine Verletzung des Standards da, sofern die Bedingung erfüllt ist. 3 Optional Optionales Feld, welches nicht zwingend erforderlich ist und bei Bedarf auch nicht in dem Data Set vorhanden sein muss. 23 Kommunikation AET und TCP/IP Zur Kommunikation innerhalb eines verteilten Netzwerkes müssen die einzelnen Teilnehmer eindeutig identifizierbar sein. Verwendetes Protokoll ist TCP/IP Application Entity Title (AET) zur eindeutigen Identifikation des DICOM Knoten und der verschiedenen Modalitäten Aus Sicherheitsgründen müssen im Regelfall beide Knoten gegenseitig registriert sein, anonyme Übertragungen werden abgewiesen. 24 Kommunikation AET und TCP/IP Notwendige Informationen zur Kommunikation: Hostname IP-Adresse Port (Standard-Port für DICOM: 104) Applicatoin Entity Title (AET) 25 Kommunikation SOP Classes Zur Verarbeitung der IODs werden entsprechenden Services, welche auf diese Informationen angewendet werden können, im Standard definiert. Eine Kombination von IOD und Service wird als Service Object Pair Class bezeichnet, kurz SOP Class oder Service Class. Im DICOM Standard definiert Services können von den verschiedenen Herstellern implementiert werden, wobei nicht alle verfügbaren Services implementiert werden müssen. Die unterstützten Services einer Modalität oder Application sind im zugehörigen DICOM Conformance Statement vermerkt. 26 Kommunikation Kommunikationsablauf Initialisierung TCP/IP Verbindung Aufbau der DICOM Connection (Association Negotiation) Abwechselnd DIMSE Request und DIMSE Response Freigabe der DICOM Connection (Association Release) Terminierung der TCP/IP Verbindung (Quelle: https://saravanansubramanian.com/) 27 Kommunikation Kommunikationsablauf – DICOM Association Aushandeln der DICOM Connection Welcher Service soll genutzt werden (Abstract Syntax) – wir dieser unterstützt? Transfer Syntax wird ausgehandelt – beide Knoten müssen sich auf einen unterstützen Syntax einigen Generelle Kommunikationsinformation werden übermittelt (Quelle: Pianykh 2012) 28 Kommunikation Kommunikationsablauf - Transfer Syntax Transfer syntax name Transfer syntax UID Meaning Vergleichbar mit dem Bildformat von 1. Byte ordering for different computer architectures. Images are not compressed: Digitalfotos (JPG, PNG, BMP, …) Implicit VR Little Endian 1.2.840.10008.1.2 Default DICOM Transfer Syntax – must be supported by all DICOM devices Unkomprimierte und Komprimierte Same as implicit, but with VR types Explicit VR Little Endian 1.2.840.10008.1.2.1 Übertragung included into DICOM objects Komprimierte Übertragung kann Explicit VR Big Endian 1.2.840.10008.1.2.2 Reverted byte ordering Verlustbehaftet (lossy) und Verlustfrei 2. Image compression formats: DICOM Explicit JPEG base- Implementing various digital image (Lossless) sein line 8-bit Lossy compression 1.2.840.10008.1.2.4.50 compression algo-rithms. They all use 35 Transfer Syntaxes definiert DICOM Explicit JPEG base- explicit Little Endian VR encoding. line 12-bit Lossy 1.2.840.10008.1.2.4.51 14 davon bereits retired (obsolet) compression DICOM Explicit JPEG base- 1.2.840.10008.1.2.4.57 line Lossless compression … 29 Kommunikation DICOM Services – SCU und SCP Kommunikation findet immer zwischen zwei Entitäten statt Eine Seite übernimmt die Rolle des Service Class Providers (SCP), welcher einen Service anbietet, die Andere die Rolle des Service Class Users (SCU), welcher einen angebotenen Service nutzt Während einer Transaktion können die Rollen dabei mehrmals getauscht werden (Quelle: Pianykh 2012) 30 Kommunikation DICOM Services – C-ECHO Einfachster DICOM Service Vergleichbar mit dem Ping Befehl in Windows SCU sendet Echo Request an SCP SCP verarbeitet Request und sendet Echo Response an SCU zurück Basistest zur Überprüfung der Kommunikation zweier Instanzen (Quelle: Pianykh 2012) 31 Kommunikation DICOM Services – C-FIND Service zum Suchen von gespeicherten Studien eines Patienten auf dem SCP, z.B. ein PACS C-FIND Request beinhaltet Suchparameter, z. B. Patient ID, Name, … welche von SCP verarbeitet werden Informationen zutreffender Studien werden als C- FIND Response an SCU zurück geschickt Studien werden dem User präsentiert und in der Applikation dargestellt (Quelle: Pianykh 2012) 32 Kommunikation DICOM Services – C-STORE Service zum senden einer Studie von CT/MR ans PACS SCU sendet einen C-STORE Request mit den Bilddaten an das PACS. Daten werden gespeichert und anschließend eine C-STORE Response (erfolgreich gespeichert oder Fehler) an SCU Übertragung im Regelfall pro Image Instance. (Quelle: Pianykh 2012) Jedes Slice eine Übertragung. 33 Kommunikation DICOM Services – C-GET Kombinierter Service aus C-FIND and C-STORE zum suchen und anfordern von Studies eines Patienten SCU sendet Suchparameter an SCP (C-FIND) SCP verarbeitet Suchparameter und initiiert die Datenübertragung an den SCU (C-STORE) SCU und SCP tauschen die Rollen (Quelle: Pianykh 2012) 34 Kommunikation DICOM Services – C-MOVE Ähnliche Funktion wie C-GET Versand erfolgt allerdings an eine dritte Instanz Workstation 1 (SCU) sendet C-FIND an PACS (SCP) PACS sendet C-FIND Response an Workstation 1 Workstation 1 sendet C-MOVE an PACS mit Workstation 2 als Ziel PACS (SCU) sendet C-STORE Request and Workstation 2 (SCP) (Quelle: Pianykh 2012) 35 Kommunikation Conformance Statement Dokument des Geräteherstellers, welches die DICOM Eigenschaften des Gerätes beschreibt Verbindliches Dokument, welches bei der Auslieferung des Gerätes inkludiert sein muss Vorgegeben Form bzw. Inhalt (definiert im Standard) Definiert unter anderem welche SOP Classes für welchen Service in welcher Rolle angeboten werden. Deklariert unterstützte Transfer Syntaxes für die jeweilige SOP Class Wichtig bei der Anschaffung einer neuen Modalität und Integration in das eigene Netzwerk Vorgelagerte Compatibility-Testphase empfohlen (Abnahmetests) 36 Kommunikation Conformance Statement Auszug Conformance Statement Philips IntelliSpace Portal 10 Image Viewer eingesetzt bei MedAustron 37 (Quelle: Philips 2018)