DICOM Digital Imaging and Communications in Medicine!

!

Primera clase - estructuras

______________________________________!UY - FING - NIB - Jacques FAUQUEX / 2015-04-09

Objetivos• introducción al estándar DICOM!

• características de la imagenología médica!

• imagenología y metadatos!

• modelado de objetos DICOM!

• representación del modelado !

• xml!

• json!

• binario!

• archivo DICOM binario

introducción al estándar DICOM

DICOM

• Digital Imaging and Communications in Medicine!

• estándar international (ISO 12052).!

• define el formato de las imágenes médicas que se intercambian con los datos y la calidad necesarios para uso clínico.

• 22 años de existencia de la versión 3.0!

• acceso libre al estándar y a muchas implementaciones!

• http://medical.nema.org!

• http://www.dclunie.com/dicom-status/status.html

• conferencia, cada año a fines de noviembre en Chicago: RSNA (Radiological Society of North América)

60’000

DICOM - HL7 - IHE• DICOM: para recursos imagenológicos y binarios!

• HL7: esencialmente textual !

• IHE: metodología UML aplicada a DICOM y HL7 (perfiles de integración, casos de uso, actores, transacciones, connectathons…)!

• Informe radiológico: del DICOM SR (Structured Report) a la adopción del CDA HL7 XML por DICOM!

• Evolución de HL7 (FHIR), DICOM (-RS) y IHE (m…) a REST y JSON para permitir acceso web móvil

características de la imagenología médica

• estudios volumétricos y dinámicos de 1’000 - 20’000 imágenes son frecuentes, por ejemplo en PET/CT!

• tomógrafos capaces de capturar 254 cortes volumétricos a la vez en modo de secuencia dinámica!

• matriz de adquisición de cámaras y ‘flat panels’ pasó de 512 (o 1024) a 2048 en ciertos equipos, por ejemplo angiografos de última generación

crecimiento exponencial del volumen de datos

• pantallas grandes con pixeles chicos!

• calibración precisa de la curva de grises para preservar el concepto de JND (Just Noticeable Difference)!

• muchos LCD económicos no cumplen!

• en suma, requerimientos similares a estaciones gráficas profesionales de edición de libros de artes visuales.!

• pero MSP pide además “certificación calidad diagnóstica en el país de origen del monitor”

necesidad de condiciones de visualización excelentes

• disposición estructurada de ventanas dentro de los monitores para permitir comparación izquierda - derecha!

• colecciones digitales inmediatamente accesibles!

• herramientas informáticas de post-procesamiento

heurística comparativa idealmente potenciada por

• para especializarse se necesita ver muchos pacientes!

• requiere procesos ágiles, sin tareas secundarias!

• flujo de trabajo de alta disponibilidad!

• es de interés del especialista, de la institución y del paciente, que se trabaje rápido.

optimización de tiempos de especialistas

• ramo dedicado a la salud y vida de los pacientes !

• demoras y errores pueden tener consecuencias de vida y legales graves!

• las herramientas tienen que ser confiables!

• los procedimientos auditables, con grado de certeza admitido en juicios civiles o penales.

auditabilidad de los procesos

• el despliegue tecnológico espectacular del multimedia de consumo hogareño rebaja la mística de los productos de imagenología médica!

• existen oportunidades para empresas chicas de crear productos nuevos o derivados, porque el mercado está todavía acostumbrado a precios exhorbitantes y alternativas pueden retener la atención!

• ejemplo: grabador de CD DICOM con software opensource

desaparición de la mística tecnológica

imagenología y metadatos

• metadato = dato relativo a dato!

• todos los formatos de imágenes contienen metadatos.Ejemplo básico: el tamaño de una linea de pixeles!

• la sintaxis para escribir los metadatos es lo que caracteriza un formato de imagen. Por ejemplo:!

• TIFF, JPG, PNG, BMP...!

• EXIF!

• XMP!

• y para imagen médica, … DICOM

MIME Type : image/jpeg JFIF Version : 1.01 Color Space Data : RGB Device Model Desc : IEC 61966-2.1 Default RGB colour space - sRGB Red Tone Reproduction Curve : (Binary data 2060 bytes, use -b option to extract) Green Tone Reproduction Curve : (Binary data 2060 bytes, use -b option to extract) Blue Tone Reproduction Curve : (Binary data 2060 bytes, use -b option to extract) Camera Model Name : Canon EOS 40D Orientation : Horizontal (normal) X Resolution : 72 Y Resolution : 72 Date/Time Original : 2012:12:04 21:11:09 Exif Image Width : 1000 Exif Image Height : 733 XMP Toolkit : XMP Core 4.4.0 Serial Number : 920515432 Lens : Canon EF 24-105mm f/4L IS Lens ID : 237 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3

./exiftool foto.jpg

• categorías de metadatos comunes:

• técnica usada para la captura!

• identificación equipamiento!

• geográficos y cronológico

• + categorías de metadatos DICOM

• paciente!

• profesionales de salud!

• estudio realizado!

• equipo que captura una serie de imágenes!

• enlaces a la historia clínica!

• ...

• define :!

• metadatos!

• como juntar datos y metadatos!

• como comunicar el conjunto

estándar DICOM: formalización de objetos de información para

la imagenología médica

Modelado de objetos DICOM

SOP Class

DICOM “SOP class”• “SOP Class” es un concepto que verán por todos lados

en el estándar DICOM (Digital Imaging and Communications in Medicine)

• SOP = Service Object Pair!

• ejemplos: almacenar tomografía, imprimir tomografía!

• junta el concepto de servicio de mensajería entre un proveedor y un usuario al concepto de “Information Object Definition” (IOD)

InformationObject

Definition

DIMSE Servicesor Media Storage

Services

Service ClassSpecification

11

SOP Class(es)

Attributes

Service Group

specifies related1

n

1

is a group of1

n contains1

n

defined as

1 1applied to an

SOP Class = servicio & IOD

Servicio:!Parte 4 del !estándar!(clase 2)

IOD:!Parte 3 !

del estándar! (clase 1)

IOD

• IOD equivalente al concepto informático “clase”!

• una imagen DICOM es instancia de un IOD si contiene:!

• todos los atributos obligatorios de este IOD,!

• eventualmente los opcionales!

• eventualmente atributos privados definidos en el “conformance statement” del equipo creador!

• y no contiene otros atributos

IOD : Definición de Información de Objeto

IODOID: ID objetoUID: ID instancia

atributos : - obligatorios, - opcionales, - privados

estructura de una instancia de IOD DICOM

• un UID = Identificador universalmente Único. Identifica individualmente cualquier cosa!

• La forma de un UID es una secuencia de números separados por puntos (ej: 1.2.3)!

• un OID = IDentificador de Objeto es un tipo particular de UID. El OID identifica:!

• individualmente un IOD!

• colectivamente todas las instanciaciones del IOD

unaoid.gub.uy

IODs y panorama de representación de la realidad

• DICOM representa los objetos principales necesarios para la realización de estudios médicos imagenológicos por medio de diagramas que contienen entidades de información (IE) y relaciones entre ellas!

• Se llama “composite” (compuesto) a un IOD que contiene atributos de varios IE!

• Se llama “normalized” (normalizado) a un IOD que contiene atributos de un solo IE

Series

comprised of

containsincludes

Modality performedProcedure Steps

creates spatially defines

Equipment

Fiducials

Image

Raw Data

MR Spectroscopy

Radiotherapy Objects

Encapsulated Document

Real-World Value Mapping

Presentation State

Frame of Reference

Patient

visit

makes has

includes

Study

1

1-n

1

1-n

1

1-n

1

1-n

1

1-n

contains1

1

1-n

0-1

1-n

1-n

0-n

0-n

0-n

0-n

1

1-n

1-n

Waveform0-n

0-n

0-n

0-n

0-n

0-n

Stereometric Relationship0-n

SR Document0-n

Measurements0-n 0-n

Registration spatially defines

Surface

Estudios

• los IODs de estudios almacenados son de tipo “composite” porque usan atributos de varios IEs!

• Se encuentran descritos en parte 3 anexo A

Film Session

contains

Printer

Presentation LUTLookup Table

contains11-n

1-n0-nrelates to

1-n

0-1

1

0-1

contains issues1

0-1

1-n

0-n

Print JobAnnotation

1

1-n

prints1

1-nImage

Image Box

relates touses1-n

0-1

1

0-n

issues

Film Box

is presented by

Impresión• Esencialmente IODs

de tipo “Normalized”!

• parte 3 anexo B

IODs “composite”• IOD (Information Object Definition) parte 3 anexo A!

• varios IE (Information Entity)!

• uno o más modulos!

• listando atributos!

• que pueden contener items listando atributos!

• y usando cero o más macros (listas de atributos)!

• que pueden contener items listando atributos

IE Module Reference UsagePatient Patient C.7.1.1 M

Clinical Trial Subject C.7.1.3 UStudy General Study C.7.2.1 M

Patient Study C.7.2.2 UClinical Trial Study C.7.2.3 U

Series General Series C.7.3.1 MClinical Trial Series C.7.3.2 U

Frame of Reference Frame of Reference C.7.4.1 MEquipment General Equipment C.7.5.1 MImage General Image C.7.6.1 M

Image Plane C.7.6.2 MImage Pixel C.7.6.3 MContrast/bolus C.7.6.4 C - Required if contrast

media was used in this imageDevice C.7.6.12 USpecimen C.7.6.22 UCT Image C.8.2.1 MOverlay Plane C.9.2 UVOI LUT C.11.2 USOP Common C.12.1 M

PARTE 3: A.3.3 CT IMAGE IOD MODULES

Lista de modulos que componen un IOD

• algunos módulos son obligatorios (M=mandatory)!

• otros son opcionales (U=User option)!

• otros condicionales (C=conditional)!

• el orden de los módulos en esta lista es insignificante!

• en el dataset final, los atributos de un modulo se mezclan con los atributos de los otros

Attribute Name Tag Type Attribute DescriptionPatient's Name (0010,0010) 2 Patient's full name.Patient ID (0010,0020) 2 Primary hospital identification number or

code for the patient.

Include Issuer of Patient ID Macro Table 10-18

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

Referenced Patient Sequence (0008,1120) 3 A sequence that provides reference to a Patient SOP Class/Instance pair. Only a single Item shall be permitted in this Sequence.

>Include SOP Instance Reference Macro Table 10-11Patient's Birth Time (0010,0032) 3 Birth time of the Patient.

PARTE 3: C.7.1.1 PATIENT MODULE ATTRIBUTES

Attribute Name Tag Type DescriptionReferenced SOP Class UID (0008,1150) 1 Uniquely identifies the referenced SOP Class.

Referenced SOP Instance UID (0008,1155) 1 Uniquely identifies the referenced SOP Instance.

PARTE 3: 10.8 SOP INSTANCE REFERENCE MACRO

Attribute Name Tag Type DescriptionReferenced SOP Class UID (0008,1150) 1 Uniquely identifies the referenced SOP Class.

Referenced SOP Instance UID (0008,1155) 1 Uniquely identifies the referenced SOP Instance.

PARTE 3: 10.8 SOP INSTANCE REFERENCE MACRO

item 1

item 2

item …

ATRIBUTO DE TIPO “SEQUENCE” (SQ)

representación de IOD

• al contrario de EXIF (compuesto por un solo “dataset” - listado de atributos), el IOD está estructurado en forma arborescente.!

• un IOD puede tener dentro de su “dataset” principal unos atributos de tipo “sequence”, que contienen items que incluyen cada uno otro dataset.!

• el mecanismo de inclusión es recursivo

IOD estructurado en forma arborescente

• Attribute: contenido identificado por un tag (etiqueta)!

• vr: “value representation” indica el tipo de datos contenidos!

• Value: un elemento del contenido del atributo!

• Dataset: lista de atributos clasificados por tag en orden creciente !

• Item: contenedor de un dataset !

• Sequence: tipo de atributo contenedor de cero o más items delimitando cada uno un dataset embebido

estructuración DICOM

xml

representación xml - attribute!!! ! <DicomA)ribute!vr="vr1"!tag="e"queta1">!! ! ! <Value!number="1">contenido1</Value>!! ! </DicomA)ribute>

representación xml - dataset!!! ! <DicomA)ribute!vr="vr1"!tag=“e"queta1">!! ! ! <Value!number="1">contenido1</Value>!! ! </DicomA)ribute>!! ! <DicomA)ribute!vr="vr2"!tag="e"queta2">!! ! ! <Value!number=“1">contenido2</Value>!! ! </DicomA)ribute>

representación xml - item!! <Item!number="1">!! ! <DicomA)ribute!vr="vr1"!tag=“e"queta1">!! ! ! <Value!number="1">contenido1</Value>!! ! </DicomA)ribute>!! ! <DicomA)ribute!vr="vr2"!tag="e"queta2">!! ! ! <Value!number=“1">contenido2</Value>!! ! </DicomA)ribute>!! </Item>

<DicomA)ribute!vr=“SQ”!tag=“e"queta0”>!! <Item!number="1">!! ! <DicomA)ribute!vr="vr1"!tag=“e"queta1">!! ! ! <Value!number="1">contenido1</Value>!! ! </DicomA)ribute>!! ! <DicomA)ribute!vr="vr2"!tag="e"queta2">!! ! ! <Value!number=“1">contenido2</Value>!! ! </DicomA)ribute>!! </Item>!! <Item!number="2">!! ! <DicomA)ribute!vr="vr3"!tag=“e"queta3">!! ! ! <Value!number="1">contenido3</Value>!! ! </DicomA)ribute>!! ! <DicomA)ribute!vr="vr4"!tag="e"queta4">!! ! ! <Value!number=“1">contenido4</Value>!! ! </DicomA)ribute> ! </Item>!</DicomA)ribute>

representación xml - sequence

• en XML, se trata de una propiedad de un elemento!

• <elemento atributo= “valor”></emento>

• en DICOM, se trata de un elemento de información!

• atributo DICOM = elemento XML

¡¡¡ atributo !!!

limitación de la representación xml

• fiel a la sintaxis DICOM, exclusivamente!

• no es una representación ontológica (RDF, OWL)

ventajas de la representación xml

• fácilmente explorable por expresión xpath. ejemplo:!

• “DicomAttribute[@tag=“etiqueta0”]/Item[@number=“1”]/DicomAttribute[@tag=“etiqueta1”]/Value[@number=“1”]”selecciona contenido1!

• xpath es parte de los lenguajes XSLT, XQuery y existen librarías disponibles para todos los lenguajes de programación!

• xslt1 y xPath incluidos en casi todos los navegadores web !

• posibilidad de armar páginas web dinámicas con información seleccionada del lado cliente

json

representación json - attribute!!! ! ! ! ! ! ! ! "e"queta1":!{"vr":!“vr1",!"Value":![!"contenido1"!]!}

representación json - dataset!!! ! ! ! ! ! ! ! "e"queta1":!{"vr":!“vr1",!"Value":![!"contenido1"!]!},!! ! ! ! ! ! ! ! "e"queta2":!{!"vr":!“vr2",!"Value":![!"contenido2"!]!}

representación json - item!!! ! ! ! ! ! ! ! { ! ! ! ! ! ! ! ! "e"queta1":!{"vr":!“vr1",!"Value":![!"contenido1"!]!},!! ! ! ! ! ! ! ! "e"queta2":!{!"vr":!“vr2",!"Value":![!"contenido2"!]!}!! ! ! ! ! ! ! ! }!!

representación json - sequence"e"queta0":!{!! ! ! "vr":!“SQ",!"Value":![!! ! ! ! ! ! ! ! { ! ! ! ! ! ! ! ! "e"queta1":!{"vr":!“vr1",!"Value":![!"contenido1"!]!},!! ! ! ! ! ! ! ! "e"queta2":!{!"vr":!“vr2",!"Value":![!"contenido2"!]!}!! ! ! ! ! ! ! ! },!!! ! ! ! ! ! ! ! {!! ! ! ! ! ! ! ! "e"queta3":!{"vr":!“vr3",!"Value":![!"contenido3"!]!},!! ! ! ! ! ! ! ! "e"queta4":!{!"vr":!"vr4","Value":![!“contenido4”]!}!! ! ! ! ! ! ! ! }!! ! ! ! ! ! ! !!!!!]!! ! ! }!

ventajas de la representación json

• más compacta que la representación xml!

• importable y explorable sin parseo complejo desde javascript y otros lenguajes, pues ideal para aplicaciones web

binario

representación binaria

• fue la primera forma de representar DICOM, antes de la creación de xml o json!

• acepta muchas variantes!

• little o big endian!

• value representation implicit o explicit!

• items y secuencias de tamaño especificado o delimitados por un atributo de fin de item o fin de secuencia!

• descrita en la parte 5 del estándar DICOM

variantes fundamentales• implicit little endian (ILE)!

• obligatorio de aceptarla en lectura!

• es la sintaxis más usada en los queries!

• explicit little endian (ELE)!

• no requiere diccionario de tags para conocer el tipo de datos incluido!

• obligatoria para sintaxis de transferencia encapsuladas (DICOM comprimido)!

• items y secuencias delimitados por atributo porque es más fácil de editar y facilita la conversión a xml o json

ejemplo

Tag Name Keyword VR VM

(0002,0000) File Meta Information Group Length FileMetaInformationGroupLength UL 1

(0002,0001) File Meta Information Version FileMetaInformationVersion OB 1

(0002,0002) Media Storage SOP Class UID MediaStorageSOPClassUID UI 1

(0002,0003) Media Storage SOP Instance UID MediaStorageSOPInstanceUID UI 1

(0002,0010) Transfer Syntax UID TransferSyntaxUID UI 1

(0002,0012) Implementation Class UID ImplementationClassUID UI 1

(0002,0013) Implementation Version Name ImplementationVersionName SH 1

(0002,0016) Source Application Entity Title SourceApplicationEntityTitle AE 1

(0002,0100) Private Information Creator UID PrivateInformationCreatorUID UI 1

(0002,0102) Private Information PrivateInformation OB 1

parte 6: diccionario

UI Unique Identifier (UID)

A character string containing a UID that is used to uniquely identify a wide variety of items. The UID is a series of numeric components separated by the period "." character. If a Value Field containing one or more UIDs is an odd number of bytes in length, the Value Field shall be padded with a single trailing NULL (00H) character to ensure that the Value Field is an even number of bytes in length. See Section 9 and Annex B for a complete specification and examples.

"0”-”9”, “." of Default Character Repertoire

64 bytesmaximum

UL Unsigned Long

Unsigned binary integer 32 bits long. Represents an integer n in the range:!

0 <= n < 2

not applicable 4 bytesfixed

UN Unknown

A string of bytes where the encoding of the contents is unknown (see Section 6.2.2).

not applicable Any length valid for any of the other DICOM Value Representations

US Unsigned Short

Unsigned binary integer 16 bits long. Represents integer n in the range:!

0 <= n < 2

not applicable 2 bytesfixed

PARTE 5: DICOM VALUE REPRESENTATIONS

inclusión del dataset dentro de un archivo

• a priori los dataset binario no requieren almacenamiento dentro de los límites de un archivo. Podrían almacenarse por ejemplo directamente dentro de una base de datos!

• no obstante, el uso de un archivo como contenedor de dataset resultó ser muy práctico en los 20 últimos años, por lo cual se agregó la parte 10 del estándar que indica como almacenar un dataset dentro de un archivo

archivo binario DICOM• preámbulo de 128 bytes sin uso!

• letras ascii ‘DICM’!

• atributos del grupo 0002!

• tamaño del grupo 0002 !

• SOP Class, transfer síntax, aplicaciones involucradas!

• dataset principal!

• atributo 0008,0005 para indicar el charset usado!

• otros atributos clasificados por orden de tag!

• atributo 7FE0,0010 contiene los pixeles de la imagen!

• eventualmente atributo de padding trailing

ventajas de la representación binaria

• usada por todos los equipos de adquisición DICOM !

• la más compacta!

• adaptada a contenidos binarios (imágenes, etc…)!

• xml y json requieren que los contenidos binarios estén convertidos a codificación base64, lo que implica conversiones y aumento de peso de un tercio.

limitaciones de la representación binaria

• requiere parseo o serialización complejos para usar la información!

• no adaptada al uso dentro de aplicaciones web

¿cual representación usar?• para la red local de producción de imágenes dentro del

hospital, la única solución realista por ahora, hasta que les equipos de creación de imagen evolucionen, es de seguir con la representación binaria!

• pero está en curso una nueva etapa en la cual la dispersion de los estudios ya no es admisible y se quiere reunir toda la historia clínica imagenológica del paciente en la nube, con tecnología web. Este nuevo caso de uso se beneficia extraordinariamente de las representación xml y json.!

• todas las representaciones son alternativas y se puede pasar de una a otra sin pérdida de información porque comparten el mismo modelo de objeto.