La cabecera del estándar DICOM

David del Río Medina

Universidad de Málaga

Carlos Bocanegra Sánchez

Consejería de Innovación, Junta de Andalucía

David Santo Orcero

Universidad de Málaga

Resumen/Abstract

El estándar DICOM es el mecanismo de codificación, almacenamiento y transmisión de imágenes aceptado universalmente por la comunidad médica. La cabecera de este formato, extremadamente rica, permite almacenar información sobre el paciente, las condiciones en las que se tomó la imagen, y el formato interno de esta. En este artículo analizamos en profundidad la cabecera del estándar DICOM.
The DICOM standar is a mechanism for codification, storage and transmission of images, worlwide accepted by the medical community. It allows to record information about patients, the conditions while the image was taken ant its internal format.

1. Introducción

La introducción de imágenes médicas digitales en la década de los setenta y el uso de ordenadores para el procesamiento de estas imágenes una vez adquiridas llevó al American College of Radiology (ACR) y a la National Electrical Manufacturers Association (NEMA) a formar un comité conjunto para crear un método estándar para la transmisión de imágenes médicas y su información asociada. Este comité, formado en 1983, publicó en 1985 el estándar ACR-NEMA. Antes de esto, la mayoría de los dispositivos almacenaban las imágenes en un formato propietario y transferían ficheros de estos formatos propietarios a través de una red o en dispositivos de almacenamiento portátiles para llevar a cabo la comunicación de las imágenes. Con el lanzamiento de la versión 3.0 se cambió el nombre a Digital Imaging and Communications in Medicine (DICOM), y se añadieron numerosas mejoras para las comunicaciones estandarizadas.

DICOM (Digital Imaging and Communication in Medicine) no es solo un formato de fichero para imágenes médicas. De hecho, pretende ser un estándar completo que cubra todas las necesidades de un PACS: almacenamiento, pero también transmisión, comunicaciones en general e impresión. De esta forma, se integran todas las máquinas que forman un PACS, desde los equipos médicos encargados de la obtención de imágenes hasta los clientes usados por el personal clínico para visualizar las imágenes.El estándar DICOM facilita la interoperatividad de los equipos de imágenes médicas especificando:

  • Para las comunicaciones de red, un conjunto de protocolos que deben ser seguidos por los dispositivos conformes al estándar.
  • Sintaxis y semántica de los comandos y la información asociada que puede ser intercambiada usando estos protocolos.
  • Para la comunicación de datos, un conjunto de servicios para el almacenamiento de datos que deben ser seguidos por los dispositivos conformes al estándar, así como un formato de fichero y una estructura de directorio médico para facilitar el acceso a las imágenes y a la información relacionada almacenada en medios de intercambio.
  • La información que debe suministrarse con una implementación conforme al estándar.

El estándar DICOM no especifica:

  • Detalles de implementación o cualquier característica del estándar de un dispositivo conforme a él.
  • El conjunto global de características y funciones que se esperan de un sistema implementado integrando un grupo de dispositivos conformes al estándar DICOM.
  • Un procedimiento de testeo/validación para calcular la conformidad de una implementación con el estándar.

Los ficheros DICOM consisten en dos partes diferenciadas:

  • Una cabecera con multitud de campos estandarizados que especifican tanto datos administrativos (datos del paciente, hospital donde se realizó, entre otros) como datos sobre la imagen.
  • Cuerpo con la imagen, que puede estar comprimida con distintos estándares.

El estándar DICOM está ahora mismo en su versión 3.0 y es mantenido por los miembros del Comité de Estándares DICOM (DICOM Standards Committee), que está formado por organizaciones, vendedores de hardware y software para PACS y otros grupos de interés general.

2. Estructura de un Fichero DICOM

El formato de fichero DICOM es muy complejo, debido a la gran cantidad de campos que se especifican en la cabecera, así como los varios tipos de cabecera que permite y la multitud de formatos en los que puede estar grabada la imagen.

Desde el punto de vista del implementador, un fichero DICOM se puede dividir en cuatro partes diferenciadas:

  • Preámbulo y prefijo identificativo del fichero.
  • Meta-cabecera.
  • Cabecera.
  • Imagen (aunque desde el punto de vista del formato, la imagen es un elemento más de la cabecera).

3. Preámbulo y Prefijo

3.1. Preámbulo

El estándar DICOM especifica que un fichero en formato DICOM debe de comenzar con un preámbulo.

Este preámbulo tiene un tamaño fijo de 128 bytes, y está pensado para tener un uso definido por la implementación. Por ejemplo, puede contener información sobre el nombre de la aplicación usada para crear el fichero, o puede tener información que permita a aplicaciones acceder directamente a los datos de la imagen almacenada en el fichero.

El estándar DICOM no especifica la manera en que los datos del preámbulo tengan que ser estructurados, siendo esto decisión de los encargados de diseñar la implementación.

En caso de no ser usado, el preámbulo debe estar presente, con todos sus bytes puestos al valor 00h.

3.2 Prefijo

Lo que sigue al preámbulo es el prefijo identificativo de los ficheros DICOM.

Este prefijo consiste en cuatro bytes que contienen la cadena de caracteres DICM. Esta cadena debe estar codificada siempre con las letras en mayúscula y usando el repertorio de caracteres ISO 8859 G0.

El propósito de este prefijo es permitir a las implementaciones diferenciar si un fichero es DICOM o no.

4. Elementos de Datos

La cabecera y la meta-cabecera de un fichero DICOM consisten en una serie de campos con toda la información necesaria sobre la imagen en cuestión, incluyendo la propia imagen.

Entre estos campos se encuentran, por ejemplo, datos sobre el paciente (nombre, sexo), sobre el tipo de imagen y muchos más. Entre todos estos campos los que más nos interesan para el proyecto son los que contienen información necesaria para procesar y visualizar la imagen correctamente.

En la siguiente sección explicaremos con más detalle los campos del estándar DICOM.

Al conjunto de toda la información codificada sobre un campo se le conoce con el nombre de Elemento de Datos (Data Element). Así, tanto la cabecera como la meta-cabecera de un fichero DICOM consisten en una sucesión de elementos de datos.

En esta sección veremos cómo se codifican estos elementos de datos, ya que es un paso previo necesario para describir más adelante la meta-cabecera y la cabecera. Un elemento de datos está constituido por los campos:

  • Etiqueta del Elemento de Datos (Data Element Tag): sirve para identificar cada elemento de datos de forma unívoca. Esta etiqueta está constituida por un Número de Grupo (Group Number) y un Número de Elemento (Element Number). En el documento número 6 del estándar están las descripciones de todos los elementos de datos, ordenadas según esta etiqueta. En el documento número 3 del estándar se explica el propósito de cada uno de ellos, así como su obligatoriedad. En estos documentos, y por seguir la nomenclatura también en éste, se suele representar como un vector de dos dimensiones, siendo la primera el número de grupo, y la segunda el número de elemento, en hexadecimal con cuatro dígitos. Por ejemplo, si el número de grupo es ocho y el número de elemento es doce, la etiqueta será (0008,000C).
  • Representación del Valor (Value Representation, abreviado VR): indica la forma en que se codifica el valor del elemento. Por ejemplo el valor puede estar codificado como una cadena de caracteres o un entero sin signo. Más adelante daremos el listado con todos los posibles VRs. El campo VR no siempre está codificado en el elemento de datos, sino que depende de la sintaxis de transferencia. Explicaremos el concepto de sintaxis de transferencia más adelante.
  • Longitud del Valor (Value Length): como su nombre indica, es la longitud del campo Valor.
  • Valor (Value): es el valor del elemento de datos, codificado según el campo VR y con la longitud que indica el campo Longitud del Valor. Por ejemplo, para el elemento de datos Nombre del paciente (0010,0010) el valor podría ser “Juan Expósito”, con una longitud del valor igual a diez y con la representación de valor “PN” (Person Name).

4.1 Campos DICOM

Los campos de una cabecera y meta-cabecera DICOM contienen, por una parte, toda la información necesaria para que una implementación del estándar sea capaz de procesar y visualizar correctamente la imagen o imágenes almacenadas en un fichero DICOM, y, por otra parte, todos los datos asociados a éstas que el personal médico necesita para interpretar correctamente la imagen o imágenes en cuestión.

Todos los campos definidos por DICOM se encuentran listados en una base de datos que se encuentra en el documento 6 del estándar, y se la conoce como Registro de los elementos de datos DICOM (Registry of DICOM data elements).

Cada elemento de datos está indexado por su etiqueta (número de grupo y número de elemento), que es la clave usada para buscarlo en la base de datos, y para cada elemento de datos se nos especifica:

  • Nombre: nombre del elemento de datos, que es una pequeña descripción de su función.
  • VR: representación del valor del elemento. En caso de que la cabecera sea de tipo VR implícita, será necesario consultar ésta base de datos para conocer su VR.
  • VM: indica la cantidad de valores del mismo tipo que pueden contener el campo Valor del elemento de datos. Por ejemplo el elemento de datos (0010,2154) Números de Teléfono del Paciente (Patients Telephone Numbers) puede contener más de un número de teléfono del paciente, mientras que el elemento de datos (0028,0004) Interpretación Fotométrica (Photometric Interpretation) solo puede tener un valor, puesto que una imagen no puede tener más de una interpretación fotométrica.
  • Si el elemento de datos es obsoleto y ha sido retirado en la versión actual del estándar, tendrá el identificador RET.

Por otra parte, en el documento 3 del estándar vienen todos los campos explicados detalladamente. Para cada uno de ellos, se nos especifica su función, la forma en que se debe codificar su valor y su obligatoriedad de uso.

DICOM divide la obligatoriedad de uso según la siguiente nomenclatura:

  • Tipo 1: si un elemento de datos es de tipo 1, éste debe ser incluido obligatoriamente. La longitud del valor no puede ser cero, y debe tener un valor válido según se especifica en su descripción.
  • Tipo 1C: si un elemento de datos es de tipo 1C, éste debe ser incluido obligatoriamente si se cumplen ciertas condiciones especificadas. En el caso de que estas condiciones se den, el elemento de datos de tipo 1C debe cumplir los mismos requerimientos que un elemento de datos de tipo 1. En caso contrario, el elemento de datos no debe ser incluido.
  • Tipo 2: si un elemento de datos es de tipo 2, éste debe ser incluido obligatoriamente. Sin embargo, se permite codificar el elemento con una longitud del valor igual a cero y sin campo Valor, solo en el caso de que el valor del elemento de datos de tipo 2 no sea conocido. Tipo 2C: si un elemento de datos es de tipo 2C, éste debe ser incluido obligatoriamente si se cumplen ciertas condiciones especificadas. En el caso de que estas condiciones se den, el elemento de datos de tipo 2C debe cumplir los mismos requerimientos que un elemento de datos de tipo 2. En caso contrario, el elemento de datos no debe ser incluido.
  • Tipo 3: si un elemento de datos es de tipo 3, éste puede ser incluido opcionalmente, y la ausencia de un elemento de datos de este tipo no supone una violación del protocolo. Además, puede ser codificado con una longitud del valor igual a cero y sin campo Valor.

Entre los distintos campos existentes, nos encontramos:

Patient’s Name

Patient’s Name (0010,0010) especifica el nombre completo del paciente.

Patient ID

Patient’s Name (0010,0020) especifica el número de identificación del paciente.

Medical Record Locator

Medical Record Locator (0010,1090) es un identificador que especifica la localización del historial médico del paciente.

Patient’s Age

Patient’s Age (0010,1010) especifica la edad del paciente.

Patient’s Sex

Patient’s Sex (0010,0040) especifica el sexo del paciente, que puede ser M (masculino), F (femenino, O (otro).

Patient’s Primary Language Code Sequence

Patient’s’s Primary Language Code Sequence (0010,0101) especifica los lenguajes que pueden ser usados para comunicarse con el paciente, en orden de preferencia.

Patient’s Size

Patient’s Size (0010,1020) especifica el tamaño del paciente en metros.

Patient’s Weight

Patient’s Weight (0010,1030) especifica el peso del paciente en kilogramos.

Responsible Person

Responsible Person (0010,4000) especifica el nombre de la persona con autoridad para tomar decisiones médicas sobre el paciente.

Medical Alerts

Medical Alerts (0010,2000) especifica aquellos datos que el personal médico debe tener en cuenta (como, por ejemplo, condiciones de contagio y alergias a medicamentos).

Pregnancy Status

Pregnancy Status (0010,21C0) especifica el estado de embarazo de la paciente: no embarazada, posiblemente embarazada, embarazada, desconocido.

Special Needs

Special Needs (0038,0050) especifica los cuidados médicos y sociales que el paciente necesita (como, por ejemplo, silla de ruedas y oxígeno).

Patient State

Patient State (0038,0500) especifica el estado del paciente (como, por ejemplo, comatoso, desorientado, o ciego).

Pertinent Documents Sequence

Pertinent Documents Sequence (0038,0100) especifica la lista de los documentos (por ejemplo, SR o CDA) que contienen información considerada pertinente para la condición médica del paciente.

Current Patient Location

Current Patient Location (0038,0008) especifica la localización actual del paciente.

Referring Physician’s Name

Referring Physician’s Name (0008,0090) especifica el nombre médico principal del paciente en la intervención actual.

Referring Physician Identification Sequence

Referring Physician Identification Sequence (0008,0096) especifica la identificación del médico principal del paciente en la intervención actual.

Route of Admissions

Route of Admissions (0038,0016) especifica el tipo de intervención: normal o de emergencia.

Study Date

Study Date (0008,0020) especifica la fecha de comienzo del estudio.

Requesting Physician

Requesting Physician (0032,1032) especifica el nombre del médico que consultó al servicio de imágenes.

Modality

Modality (0008,0060) especifica el tipo de equipo que adquirió los datos usados para crear la imagen.

Anatomic Structure, Space or Region Squence

Anatomic Structure, Space or Region Squence (0008,2229) especifica la estructura anatómica, el espacio o la región que ha sido expuesta a radiación ionizante.

Total Number of Exposures

Total Number of Exposures (0040,0301) especifica el número total de exposiciones.

Laterality

Laterality (0020,0060) especifica la lateralidad (izquierda o derecha) de la parte del cuerpo examinada.

Patient Position

Patient Position (0018,5100) especifica la posición del paciente con respecto al equipo de adquisición de imágenes.

Date of Last Calibration

Date of Last Calibration (0018,1200) especifica la última vez en la que se calibró el dispositivo de adquisición de imágenes.

Manufacturer

Manufacturer (0008,0070) especifica el fabricante del equipo.

Device Serial Number

Device Serial Number (0018,1000) especifica el número de serie del equipo.

Image Type

Image Type (0008,0008) especifica el tipo de imagen.

Acquisition Date

Acquisition Date (0008,0032) especifica la fecha en la que empezó la adquisición de datos para crear la imagen.

Visto esto, pasamos a explicar con más detalle los distintos campos de un elemento de datos, con el objeto de poder diseñar e implementar un algoritmo que interprete correctamente la cabecera de cualquier fichero DICOM.

4.2 Representación del Valor

El estándar DICOM define una serie de VRs con diferentes características, con la intención de que el campo Valor de cada elemento de datos esté codificado correctamente según lo que representa.

El listado, con las descripciones resumidas, es el siguiente:

VR Date Time

La VR Date Time se representa como una cadena con la forma YYYY­MM­DD­HH­MM­SS­.­FFFFFF­$ZZZZ siendo: YYYY = año, MM = mes, DD = día, HH = hora, MM = minuto, SS = segundo, FFFFFF = fracción de segundo, $ = ’+’ ó ’-’, ZZZZ = horas y minutos de desplazamiento. $ZZZZ es un prefijo opcional para indicar el desplazamiento respecto al Tiempo Universal Coordinado.

4.3 Codificación

Existen dos tipos de codificación para los elementos de datos: VR explícita y VR implícita.

4.3.1 Codificación VR Explícita

En esta codificación, los elementos de datos se codifican de dos formas distintas, dependiendo de su VR.

Si la VR del elemento de datos es OB, OW, OF, SQ, UT o UN, la codificación es la siguiente:

  1. La etiqueta se codifica usando cuatro bytes: los dos primeros para el número de grupo y los dos últimos para el número de elemento. Es decir, una pareja de enteros sin signo de 16 bits, al igual que la VR AT.
  2. La VR se codifica como una cadena de caracteres de dos bytes, que puede tener el valor OB, OW, OF, SQ, UT o UN.
  3. Los dos bytes siguientes están reservados, y deben ser puestos al valor 0000h.
  4. Los siguientes cuatro bytes son para la longitud del valor, codificada como un entero sin signo de 32 bits.
  5. Los siguientes bytes, tantos como indica la longitud del valor, -salvo el caso especial que veremos más adelante-, son para el valor, que estará codificado según indica su VR y la sintaxis de transferencia.

Lo podemos ver de forma más gráfica en esta tabla:

Si la VR del elemento de datos es cualquiera que no sea una de las anteriormente mencionadas, la codificación es la siguiente:

  1. La etiqueta se codifica usando cuatro bytes: los dos primeros para el número de grupo y los dos últimos para el número de elemento. Es decir, una pareja de enteros sin signo de 16 bits, al igual que la VR AT.
  2. La VR se codifica como una cadena de caracteres de dos bytes, que puede ser cualquier VR menos las mencionadas anteriormente.
  3. Los siguientes dos bytes son para la longitud del valor, codificada como un entero sin signo de 16 bits.
  4. Los siguientes bytes, tantos como indica la longitud del valor, son para el valor, que estará codificado según indica su VR y la sintaxis de transferencia.

De forma más gráfica, en esta tabla:

4.3.2 Codificación VR Implícita

Esta es la codificación que se usa para la sintaxis de transferencia por defecto, y la diferencia más importante respecto con la anterior (VR explícita) es que, como su nombre indica, la VR de cada elemento de datos no se codifica en el fichero, obligando a consultar los documentos del estándar (o una base de datos externa al fichero) para obtenerla, al igual que ocurre con la descripción del elemento de datos y con su obligatoriedad.

La codificación es la siguiente:

  1. La etiqueta se codifica usando cuatro bytes: los dos primeros para el número de grupo y los dos últimos para el número de elemento. Es decir, una pareja de enteros sin signo de 16 bits, al igual que la VR AT.
  2. Los siguientes cuatro bytes son para la longitud del valor, codificada como un entero sin signo de 32 bits.
  3. Los siguientes bytes, tantos como indica la longitud del valor -salvo en el caso especial-, son para el valor, que estará codificado según indica su VR y la sintaxis de transferencia.

De forma más gráfica, en esta tabla:

4.3.3 Secuencias

Entre las diferentes VRs, tenemos que hacer mención especial a la VR Secuencia (SQ), debido a que, por su naturaleza, aquellos elementos de datos cuya VR es SQ tienen una codificación distinta a la del resto.

La VR identificada como “SQ” debe ser usada para aquellos elementos de datos cuyo valor consiste en una secuencia de cero o más items, donde cada ítem debe contener un conjunto de elementos de datos. Esto provee de un esquema de codificado flexible que puede ser usado para estructuras simples de conjuntos de elementos de datos, o por ejemplo puede ser usado recursivamente para contener estructuras con múltiples niveles de anidamiento.

Hay tres elementos de datos especiales usados en las secuencias que no siguen las normas de la sintaxis de transferencia convenida. Estos deben ser codificados siempre como VR implícita. Estos elementos de datos especiales son: Ítem (FFFE,E000), Ítem de Delimitación de Ítem (Item Delimitation Item) (FFFE,E00D), e Ítem de Delimitación de Secuencia (Sequence Delimitation Item) (FFFE,E0DD).

4.3.4 Codificación de los items

Cada ítem de un elemento de datos con VR SQ debe ser codificado como un elemento de datos con una etiqueta específica de valor (FFFE,E000). La etiqueta de ítem es seguida por el campo de 4 bytes llamado Longitud del Ítem (Item Length), que debe estar codificado de una de las siguientes formas:

  • Longitud Explícita: el número de bytes del campo Valor del ítem (que es el campo siguiente), codificado como un entero sin signo de 32 bits.
  • Longitud Indefinida: el campo Longitud del Ítem debe tener el valor FF­FF­FF­FFh. Debe ser usado en conjunto con un elemento de datos de tipo Delimitación del Ítem. El elemento de datos Delimitación del Ítem debe tener una etiqueta de valor (FFFE,E00D) y debe seguir a los elementos de datos que estén encapsulados dentro del ítem. No debe tener valor y su longitud debe ser 00000000h.

El campo Valor del ítem debe contener un Conjunto de Datos (Data Set) DICOM compuesto de elementos de datos. Uno o más elementos de datos dentro de un ítem pueden tener una VR SQ, permitiendo de esta manera la recursión.

4.3.5 Codificación de una secuencia

Un elemento de datos con VR SQ (es decir, una secuencia) puede estar codificado, al igual que el resto, con VR implícita o explícita.

En cualquier caso, el campo Longitud del Valor puede ser codificado como:

  • Longitud Explícita: el número de bytes del campo Valor, al igual que con cualquier otro elemento de datos normal.
  • Longitud Indefinida: el campo Longitud del Valor debe tener el valor FF­FF­FF­FFh. Debe ser usado en conjunto con el elemento de datos Ítem de Delimitación de Secuencia, que será el último ítem del campo Valor. El ítem de delimitación de secuencia, cuya etiqueta es (FFFE,E0DD), no debe de tener campo Valor, por lo que su campo Longitud del Ítem tendrá el valor 00000000h.

A continuación veremos tres ejemplos diferentes de secuencias, para que podamos entender mejor la información expuesta arriba.

Ejemplo de un elemento de datos de VR Secuencia con codificación VR Implícita, con tres ítems de longitud explícita:

Ejemplo de un elemento de datos de VR Secuencia de longitud indefinida, con codificación VR Explícita con dos ítems de longitud explícita:

Ejemplo de un elemento de datos de VR Secuencia de longitud indefinida, con codificación VR Implícita con dos ítems, donde el primero tiene longitud explícita y el segundo longitud indefinida:

La meta-cabecera contiene datos generales sobre el fichero DICOM en cuestión.

Estos datos están estructurados como elementos de datos (Data Elements) y deben ser codificados siempre usando la Sintaxis de Transferencia (Transfer Syntax) Explicit VR Little Endian.

Todos estos elementos de datos pertenecen al grupo (Group) 0002h.

En nuestro caso, sólo necesitaremos conocer uno de estos datos: la sintaxis de transferencia (Transfer Syntax).

5. Sintaxis de Transferencia

La sintaxis de transferencia es un identificador único (UID) que describe la forma en que se va a codificar la cabecera (caso normal) o la cabecera y los datos de la imagen (en el caso de que los datos de la imagen estén codificados con algún formato encapsulado, como por ejemplo JPEG).

A continuación listaremos algunas de las sintaxis de transferencia existentes, junto con su identificador único y su descripción:

6. Cabecera

6.1. Introducción

La cabecera de un fichero DICOM es la parte que nos va a proporcionar la gran mayoría de la información que necesitamos para visualizar la imagen correctamente, incluyendo los propios datos de la imagen, ya que éstos son considerados por el estándar como un elemento más de la cabecera.

La cabecera de un fichero DICOM consiste en un conjunto de elementos de datos (Data Set) con toda la información necesaria, y está codificada según la sintaxis de transferencia indicada en la meta-cabecera. Existen cuatro tipos de cabecera según la sintaxis de transferencia: tres para imágenes en formato no encapsulado (como RGB) y una para imágenes en formato encapsulado (como JPEG o RLE).

A lo largo de la sección daremos una explicación detallada de estos cuatro tipos.

6.2. Sintaxis de transferencia VR Implícita Little Endian

Una cabecera codificada con la sintaxis de transferencia VR Implícita Little Endian (Implicit VR Little Endian Transfer Syntax) debe cumplir los siguientes requerimientos:

  • Los elementos de datos deben de estar codificados con VR implícita, especificada anteriormente.
  • El codificado de los campos de los elementos de datos (Etiqueta del Elemento de Datos, Longitud del Valor, y Valor) debe de estar en little endian.
  • Para todas las VRs, excepto OB y OW, el codificado debe de estar en little endian.
  • El elemento de datos (7fE0,0010) Pixel Data tiene la VR OW y debe estar codificado en little endian.
  • El elemento de datos (60xx,3000) Overlay Data tiene la VR OW y debe estar codificado en little endian.
  • El elemento de datos (50xx,3000) Curve Data tiene la VR OB.
  • El elemento de datos (5400,1010) Waveform Data tiene la VR OW y debe estar codificado en little endian.
  • El elemento de datos (50xx,200C) Audio Sample Data tiene la VR OB cuando Audio Sample Format(50xx,2002) especifica valores de 8 bits, y OW codificado en little endian cuando especifica valores de 16 bits.
  • Los elementos de datos (0028,1201), (0028,1202), (0028,1203) Red, Green, Blue Palette Lookup Table Data tiene la VR OW y deben estar codificados en little endian.
  • Los elementos de datos (0028,1101), (0028,1102), (0028,1103) Red, Green, Blue Palette Lookup Table Descriptor tiene la VR SS o US, y deben estar codificados en little endian. El primer y el tercer valor deben ser interpretados siempre como sin signo, sea cual sea la VR.
  • Los elementos de datos (0028,1221), (0028,1222), (0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data tienen la VR OW y deben estar codificados en little endian.
  • El elemento de datos (0028,3006) Lookup Table Data tiene la VR US, SS o OW y debe estar codificado en little endian.
  • El elemento de datos (0028,3002) Lookup Table Descriptor tiene la VR SS o US y debe estar codificado en little endian. El primer y el tercer valor deben ser interpretados como sin signo, sea cual sea la VR.
  • El elemento de datos (0028,3002) Lookup Table Descriptor tiene la VR SS o US y debe estar codificado en little endian. El primer y el tercer valor deben ser interpretados como sin signo, sea cual sea la VR.

El identificador único para esta sintaxis de transferencia será “1.­2.­840.­10008.­1.­2”.

6.3. Sintaxis de transferencia VR Explícita Little Endian

Una cabecera codificada con la sintaxis de transferencia VR Explícita Little Endian (Explicit VR Little Endian Transfer Syntax) debe cumplir los siguientes requerimientos:

  • Los elementos de datos deben de estar codificados con VR explícita, especificada anteriormente.
  • El codificado de los campos de los elementos de datos (Etiqueta del Elemento de Datos, Longitud del Valor, y Valor) debe de estar en little endian.
  • Para todas las VRs, excepto OB y OW, el codificado debe de estar en little endian
  • El elemento de datos (7fE0,0010) Pixel Data:
    • si el elemento de datos Bits Allocated (0028,0100) tiene un valor mayor que 8, Pixel Data debe de tener la VR OW y estar codificado en little endian.
    • si el elemento de datos Bits Allocated (0028,0100) tiene un valor menor o igual que 8, Pixel Data debe de tener una VR OB o OW y debe estar codificado en little endian.

El elemento de datos (60xx,3000) Overlay Data tiene la VR OB o OW y debe estar codificado en little endian. El elemento de datos (50xx,3000) Curve Data debe tener la VR especificada de forma explícita en su campo VR. En el documento 3 del estándar se encuentra una lista de VRs permitidas. El elemento de datos (5400,1010) Waveform Data tiene la VR especificada de forma explícita en su campo VR. El elemento de datos (50xx,200C) Audio Sample Data tiene la VR OB cuando Audio Sample Format(50xx,2002) especifica valores de 8 bits, y OW codificado en little endian cuando especifica valores de 16 bits. Los elementos de datos (0028,1201), (0028,1202), (0028,1203) Red, Green, Blue Palette Lookup Table Data tienen la VR OW y deben estar codificados en little endian. Los elementos de datos (0028,1101), (0028,1102), (0028,1103) Red, Green, Blue Palette Lookup Table Descriptor tienen la VR SS o US, y deben estar codificados en little endian. El primer y el tercer valor deben ser interpretados siempre como sin signo, sea cual sea la VR. Los elementos de datos (0028,1221), (0028,1222), (0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data tienen la VR OW y deben estar codificados en little endian. El elemento de datos (0028,3006) Lookup Table Data tiene la VR US, SS o OW y debe estar codificado en little endian. El elemento de datos (0028,3002) Lookup Table Descriptor tiene la VR SS o US y debe estar codificado en little endian. El primer y el tercer valor deben ser interpretados como sin signo, sea cual sea la VR.

El identificador único para esta sintaxis de transferencia será “1.­2.­840.­10008.­1.­2.­1”.

6.4. Sintaxis de transferencia VR Explícita Big Endian

Una cabecera codificada con la sintaxis de transferencia VR Explícita Big Endian (Explicit VR Big Endian Transfer Syntax) debe cumplir los siguientes requerimientos:

  • Los elementos de datos deben de estar codificados con VR explícita, especificada anteriormente.
  • El codificado de los campos de los elementos de datos (Etiqueta del elemento de datos, Longitud del Valor, y Valor) debe de estar en big endian.
  • Para todas las VRs, excepto OB y OW, el codificado debe de estar en big endian.
  • El elemento de datos (7fE0,0010) Pixel Data:
    • si el elemento de datos Bits Allocated (0028,0100) tiene un valor mayor que 8, Pixel Data debe de tener la VR OW y estar codificado en big endian.
    • si el elemento de datos Bits Allocated (0028,0100) tiene un valor menor o igual que 8, Pixel Data debe de tener una VR OB o OW y debe estar codificado en big endian.

El elemento de datos (60xx,3000) Overlay Data tiene la VR OB o OW y debe estar codificado en big endian. El elemento de datos (50xx,3000) Curve Data debe tener la VR especificada de forma explícita en su campo VR. En el documento 3 del estándar se encuentra una lista de VRs permitidas. El elemento de datos (5400,1010) Waveform Data tiene la VR especificada de forma explícita en su campo VR. El elemento de datos (50xx,200C) Audio Sample Data tiene la VR OB cuando Audio Sample Format(50xx,2002) especifica valores de 8 bits, y OW codificado en big endian cuando especifica valores de 16 bits. Los elementos de datos (0028,1201), (0028,1202), (0028,1203) Red, Green, Blue Palette Lookup Table Data tienen la VR OW y deben estar codificados en big endian. Los elementos de datos (0028,1101), (0028,1102), (0028,1103) Red, Green, Blue Palette Lookup Table Descriptor tienen la VR SS o US, y deben estar codificados en big endian. El primer y el tercer valor deben ser interpretados siempre como sin signo, sea cual sea la VR. Los elementos de datos (0028,1221), (0028,1222), (0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data tienen la VR OW y deben estar codificados en big endian. El elemento de datos (0028,3006) Lookup Table Data tiene la VR US, SS o OW y debe estar codificado en big endian. El elemento de datos (0028,3002) Lookup Table Descriptor tiene la VR SS o US y debe estar codificado en big endian.

El primer y el tercer valor deben ser interpretados como sin signo, sea cual sea la VR.

El identificador único para esta sintaxis de transferencia será “1.­2.­840.­10008.­1.­2.­2”.

6.5. Sintaxis para datos de píxeles encapsulados

Una cabecera codificada con una de las Sintaxis de Transferencia para Datos de Píxeles Encapsulados (Transfer Syntaxes for Encapsulation of Encoded Pixel Data) debe cumplir los siguientes requerimientos:

  • Los elementos de datos deben de estar codificados con VR explícita, especificada anteriormente.
  • El codificado de los campos de los elementos de datos (Etiqueta del Elemento de Datos, Longitud del Valor, y Valor) debe de estar en little endian.
  • Para todas las VRs, excepto OB y OW, el codificado debe de estar en little endian.
  • El elemento de datos (7fE0,0010) Pixel Data puede estar en formato encapsulado o nativo.
  • Si está en formato nativo, debe tener longitud explícita, y debe estar codificado como sigue:
    • si el elemento de datos Bits Allocated (0028,0100) tiene un valor mayor que 8, Pixel Data debe de tener la VR OW y estar codificado en little endian.
    • si el elemento de datos Bits Allocated (0028,0100) tiene un valor mayor que 8, Pixel Data debe de tener la VR OW y estar codificado en little endian.
  • Si está en formato encapsulado, tiene la VR OB y es la secuencia de bytes resultante de uno de los procesos de codificación. Contiene el flujo codificado de datos de los píxeles fragmentado en uno o más items. Este flujo de datos de los píxeles debe representar una imagen simple o multiframe:
    • La longitud del elemento de datos (7FE0,0010) debe debe estar codificada como longitud indefinida (FF­FF­FF­FFh).
    • Cada fragmento de flujo de datos codificado con el procedimiento de codificado específico acordado, debe estar encapsulado como un ítem con una etiqueta de elementos de datos específica de valor (FFFE,E000). La etiqueta del ítem es seguida por el campo Longitud del Ítem de 4 bytes, que contiene el número explícito de bytes del ítem.
    • Todos los items que contienen un fragmento codificado deben tener un número par de bytes mayor o igual a dos. El último fragmento de un frame deberá ser ajustado, si es necesario, para cumplir estos requisitos.
    • El primer ítem de la secuencia de ítems anterior al flujo de datos de los píxeles debe ser el ítem Tabla Básica de Desplazamientos (Basic Offset Table). El valor de la tabla básica de desplazamientos, sin embargo, no tiene que estar presente:
      • Si el valor del ítem no está presente, la longitud del ítem debe ser cero (00000000h).
      • Si el valor del ítem está presente, debe contener enteros sin signo de 32 bits concatenados que son los desplazamientos al primer byte de la etiqueta del ítem del primer fragmento de cada frame en la secuencia de items. Estos desplaza-mientos se miden empezando por el primer byte de la primera etiqueta del ítem que sigue a la tabla básica de desplazamientos.

Esta secuencia de items es terminada por un ítem de delimitación de secuencia con la etiqueta (FFFE,E0DD) y con la longitud del valor (00000000h) (por lo tanto, el campo valor no debe estar presente).

El elemento de datos (60xx,3000) Overlay Data tiene la VR OB o OW y debe estar codificado en little endian. El elemento de datos (50xx,3000) Curve Data debe tener la VR especificada de forma explícita en su campo VR. En el documento 3 del estándar se encuentra una lista de VRs permitidas.

El elemento de datos (5400,1010) Waveform Data tiene la VR especificada de forma explícita en su campo VR. El elemento de datos (50xx,200C) Audio Sample Data tiene la VR OB cuando Audio Sample Format(50xx,2002) especifica valores de 8 bits, y OW codificado en little endian cuando especifica valores de 16 bits. Los elementos de datos (0028,1201), (0028,1202), (0028,1203) Red, Green, Blue Palette Lookup Table Data tienen la VR OW y deben estar codificados en little endian. Los elementos de datos (0028,1101), (0028,1102), (0028,1103) Red, Green, Blue Palette Lookup Table Descriptor tienen la VR SS o US, y deben estar codificados en little endian. El primer y el tercer valor deben ser interpretados siempre como sin signo, sea cual sea la VR. Los elementos de datos (0028,1221), (0028,1222), (0028,1223) Segmented Red, Green, Blue Palette Color Lookup Table Data tienen la VR OW y deben estar codificados en little endian. El elemento de datos (0028,3006) Lookup Table Data tiene la VR US, SS o OW y debe estar codificado en little endian. El elemento de datos (0028,3002) Lookup Table Descriptor tiene la VR SS o US y debe estar codificado en little endian. El primer y el tercer valor deben ser interpretados como sin signo, sea cual sea la VR.

Para aquellos datos codificados con la VR OB, el tipo de ordenación de los bytes (little endian o big endian) no les afecta.

A continuación veremos dos ejemplos sobre la codificación del elemento de datos Pixel Data (7FE0,0010) en estas sintaxis de transferencia, con el objeto de que podamos entenderlo mejor.

Ejemplo de una imagen de un frame simple definida como una secuencia de tres fragmentos sin la tabla básica de desplazamientos.

Ejemplo de una imagen de dos frames definida como una secuencia de tres fragmentos con la tabla básica de desplazamientos:

Bibliografía

  1. [com08a] DICOM committee, editor. PS 3.1: Introduction and Overview. DICOM, 2008.
  2. [com08b] DICOM committee, editor. PS 3.10: Media Storage and File Format for Data Interchange. DICOM, 2008.
  3. [com08c] DICOM committee, editor. PS 3.11: Media Storage Application Profiles. DICOM, 2008.
  4. [com08d] DICOM committee, editor. PS 3.12: Storage Functions and Media Formats for Data Interchange. DICOM, 2008.
  5. [com08e] DICOM committee, editor. PS 3.14: Grayscale Standard Display Function. DICOM, 2008.
  6. [com08f] DICOM committee, editor. PS 3.16: Content Mapping Resource. DICOM, 2008.
  7. [com08g] DICOM committee, editor. PS 3.17: Explanatory Information. DICOM, 2008.
  8. [com08h] DICOM committee, editor. PS 3.18: Web Access to DICOM Persistent Objects (WADO). DICOM, 2008.
  9. [com08i] DICOM committee, editor. PS 3.2: Conformance. DICOM, 2008.
  10. [com08j] DICOM committee, editor. PS 3.3: Information Object Definitions. DICOM, 2008.
  11. [com08k] DICOM committee, editor. PS 3.4: Service Class Specifications. DICOM, 2008.
  12. [com08l] DICOM committee, editor. PS 3.5: Data Structure and Encoding. DICOM, 2008.
  13. [com08m] DICOM committee, editor. PS 3.6: Data Dictionary. DICOM, 2008.
  14. [com08n] DICOM committee, editor. PS 3.7: Message Exchange. DICOM, 2008.
  15. [com08o] DICOM committee, editor. PS 3.8: Network Communication Support for Message Exchange. DICOM, 2008.

RevistaeSalud.com es una publicación electrónica que intenta promover el uso de TICs (Tecnologías de la Información y las Comunicaciones) con el propósito de mejorar o mantener la salud de las personas, sin importar quiénes sean o dónde estén.
Edita: FESALUD – Fundación para la eSalud
Correo-e: edicion@revistaesalud.com
ISSN 1698-7969		 Los textos publicados en esta revista, a menos que se indique lo contrario, están sujetos a una licencia de Reconocimiento-NoComercial-inObraDerivada 2.5 de Creative Commons. Pueden copiarse, distribuirse y comunicarse públicamente, siempre que se citen el autor y la revista digital donde se publican, RevistaeSalud.com. No se permite su uso comercial ni la generación de obras derivadas. Puede consultarse la licencia completa en http://creativecommons.org/licenses/by-nc-nd/2.5/deed.es

¿Cómo citar este artículo?