cabecera del dicom

Upload: kalaka04

Post on 12-Jul-2015

399 views

Category:

Documents


0 download

TRANSCRIPT

Vol. 4, N 16, 2008 ISSN: 1698-7969

La cabecera del estndar DICOMDavid del Ro Medina1, Carlos Bocanegra Snchez2, David Santo Orcero1Universidad de Mlaga1, Consejera de Innovacin, Junta de Andaluca2

RESUMENEl estndar DICOM es el mecanismo de codificacin, almacenamiento y transmisin de imgenes aceptado universalmente por la comunidad mdica. La cabecera de este formato, extremadamente rica, permite almacenar informacin sobre el paciente, las condiciones en las que se tom la imagen, y el formato interno de esta. En este artculo analizamos en profundidad la cabecera del estndar 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. INTRODUCCINLa introduccin de imgenes mdicas digitales en la dcada de los setenta y el uso de ordenadores para el procesamiento de estas imgenes 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 mtodo estndar para la transmisin de imgenes mdicas y su informacin asociada. Este comit, formado en 1983, public en 1985 el estndar ACR-NEMA. Antes de esto, la mayora de los dispositivos almacenaban las imgenes transferan en un formato de propietario estos y ficheros formatos DICOM (Digital Imaging and Communication in Medicine) no es solo un formato de fichero para imgenes mdicas. De hecho, pretende ser un estndar completo que cubra todas las necesidades de un PACS: almacenamiento, pero tambin transmisin, comunicaciones en general e impresin. De esta forma, se integran todas las mquinas que forman un PACS, desde los dispositivos de almacenamiento porttiles para llevar a cabo la comunicacin de las imgenes. Con el lanzamiento de la versin 3.0 se cambi el nombre a Digital Imaging para and las Communications in Medicine (DICOM), y se aadieron numerosas mejoras comunicaciones estandarizadas.

propietarios a travs de una red o en

2

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

equipos mdicos encargados de la obtencin de imgenes hasta los clientes usados por el personal clnico para visualizar las imgenes.El estndar DICOM facilita la interoperatividad de los equipos de imgenes mdicas especificando: Para las comunicaciones de red, un conjunto de protocolos que deben ser seguidos por los dispositivos conformes al estndar.

El conjunto global de caractersticas y funciones que se esperan de un sistema implementado integrando un grupo de dispositivos DICOM. Un procedimiento de testeo/validacin para calcular la conformidad de una implementacin con el estndar. Los ficheros DICOM consisten en dos partes conformes al estndar

Sintaxis y semntica de los comandos y la informacin asociada que puede ser intercambiada usando estos protocolos. Para la comunicacin de datos, un conjunto de servicios para el almacenamiento de datos que deben ser seguidos por los dispositivos conformes al estndar, as como un formato de fichero y una estructura de directorio mdico para facilitar el acceso a las imgenes y a la informacin relacionada almacenada en medios de intercambio. La informacin que debe suministrarse con una implementacin conforme al estndar. El estndar DICOM no especifica: Detalles de implementacin o cualquier caracterstica del estndar de un dispositivo conforme a l.

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 estndares. El estndar DICOM est ahora mismo en su versin 3.0 y es mantenido por los miembros del Comit de Estndares DICOM (DICOM Standards Committee), que est formado por organizaciones, vendedores de hardware y software para PACS y otros grupos de inters general.

2. ESTRUCTURA DE UN FICHERO DICOMEl formato de fichero DICOM es muy complejo, debido a la gran cantidad de campos que se especifican en la cabecera, as como los varios

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

3

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: Prembulo y prefijo identificativo del fichero.

El estndar DICOM no especifica la manera en que los datos del prembulo tengan que ser estructurados, siendo esto decisin de los encargados de disear la implementacin. En caso de no ser usado, el prembulo debe estar presente, con todos sus bytes puestos al valor 00h.

3.2. Prefijo Meta-cabecera. Cabecera. Imagen; aunque desde el punto de vista del formato, la imagen es un elemento ms de la cabecera. Lo que sigue al prembulo 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 mayscula y usando el repertorio de caracteres ISO 8859 G0.

3. PREMBULO Y PREFIJO3.1. Prembulo El estndar DICOM especifica que un fichero en formato DICOM debe de comenzar con un prembulo. Este prembulo tiene un tamao fijo de 128 bytes, y est pensado para tener un uso definido por la implementacin. Por ejemplo, puede contener informacin sobre el nombre de la aplicacin usada para crear el fichero, o puede tener informacin que permita a aplicaciones acceder directamente a los datos de la imagen almacenada en el fichero.

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

4. ELEMENTOS DE DATOSLa cabecera y la meta-cabecera de un fichero DICOM consisten en una serie de campos con toda la informacin necesaria sobre la imagen en cuestin, incluyendo la propia imagen. Entre estos campos se encuentran, por ejemplo, datos sobre el paciente (nombre, sexo), sobre el tipo de imagen y muchos ms. Entre todos estos campos los que ms nos interesan para el

4

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

proyecto son los que contienen informacin necesaria para procesar y visualizar la imagen correctamente. En la siguiente seccin explicaremos con ms detalle los campos del estndar DICOM. Al conjunto de toda la informacin 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 sucesin de elementos de datos. En esta seccin veremos cmo se codifican estos elementos de datos, ya que es un paso previo necesario para describir ms adelante la metacabecera 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 unvoca. Esta etiqueta est constituida por un Nmero de Grupo (Group Number) y un Nmero de Elemento (Element Number). En el documento nmero 6 del estndar estn las descripciones de todos los elementos de datos, ordenadas segn esta etiqueta. En el documento nmero 3 del estndar se explica el propsito de cada uno de ellos, as como su obligatoriedad. En estos documentos, y

por seguir la nomenclatura tambin en ste, se suele representar como un vector de dos dimensiones, siendo la primera el nmero de grupo, y la segunda el nmero de elemento, en hexadecimal con cuatro dgitos. Por ejemplo, si el nmero de grupo es ocho y el nmero de elemento es doce, la etiqueta ser (0008,000C). Representacin 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. Ms 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 ms 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 segn 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 podra ser Juan

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

5

Expsito, con una longitud del valor igual a diez y con la representacin de valor PN (Person Name).

VR:

representacin

del

valor

del

elemento. En caso de que la cabecera sea de tipo VR implcita, 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) Nmeros de Telfono del Paciente (Patients Telephone Numbers) puede contener ms de un nmero de telfono del paciente, mientras que el elemento de datos (0028,0004) Interpretacin Fotomtrica (Photometric Interpretation) solo puede tener un valor, puesto que una imagen no puede tener ms de una interpretacin fotomtrica. Si el elemento de datos es obsoleto y ha sido retirado en la versin actual del estndar, tendr el identificador RET. Por otra parte, en el documento 3 del estndar vienen todos los campos explicados detalladamente. Para cada uno de ellos, se nos especifica su funcin, la forma en que se debe codificar su valor y su obligatoriedad de uso. DICOM divide la obligatoriedad de uso segn la siguiente nomenclatura:

4.1. Campos DICOM Los campos de una cabecera y meta-cabecera DICOM contienen, por una parte, toda la informacin necesaria para que una implementacin del estndar sea capaz de procesar y visualizar correctamente la imagen o imgenes almacenadas en un fichero DICOM, y, por otra parte, todos los datos asociados a stas que el personal mdico necesita para interpretar correctamente la imagen o imgenes en cuestin. Todos los campos definidos por DICOM se encuentran listados en una base de datos que se encuentra en el documento 6 del estndar, 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 (nmero de grupo y nmero 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 pequea descripcin de su funcin.

6

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

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 vlido segn se especifica en su

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

descripcin. 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 Sin ser incluido se obligatoriamente. embargo,

elemento de datos de este tipo no supone una violacin del protocolo. Adems, puede ser codificado con una longitud del valor igual a cero y sin campo Valor. Entre los distintos campos existentes, nos encontramos: Patients Name Patients Name (0010,0010) especifica el nombre completo del paciente. Patient ID Patients Name (0010,0020) especifica el nmero de identificacin del paciente. Medical Record Locator Medical Record Locator (0010,1090) es un identificador que especifica la localizacin del historial mdico del paciente. Patients Age Patients Age (0010,1010) especifica la edad del paciente.

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

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

7

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

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

Patients Primary Language Code Sequence Special Patientss Primary Language Code Sequence (0010,0101) especifica los lenguajes que pueden ser usados para comunicarse con el paciente, en orden de preferencia. Patient State Patients Size Patient State (0038,0500) especifica el estado Patients Size (0010,1020) especifica el tamao del paciente en metros. Patients Weight Patients 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 mdicas sobre el paciente. Medical Alerts Medical Alerts (0010,2000) especifica aquellos datos que el personal mdico debe tener en cuenta (como, por ejemplo, condiciones de contagio y alergias a medicamentos). Pregnancy Status 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 informacin considerada pertinente para la condicin mdica del paciente. Current Patient Location Current Patient Location (0038,0008) especifica la localizacin actual del paciente. Referring Physicians Name Referring Physicians Name (0008,0090) Needs (0038,0050) especifica los cuidados mdicos y sociales que el paciente necesita (como, por ejemplo, silla de ruedas y oxgeno).

especifica el nombre mdico principal del paciente en la intervencin actual.

8

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

Referring Physician Identification Sequence Referring Physician Identification Sequence (0008,0096) especifica la identificacin del mdico principal del paciente en la intervencin actual. Route of Admissions Route of Admissions (0038,0016) especifica el tipo de intervencin: normal o de emergencia.

Total Number of Exposures Total Number of Exposures (0040,0301)

especifica el nmero total de exposiciones. Laterality Laterality (0020,0060) especifica la lateralidad (izquierda o derecha) de la parte del cuerpo examinada. Patient Position

Study Date Patient Study Date (0008,0020) especifica la fecha de comienzo del estudio. Requesting Physician Requesting Physician (0032,1032) especifica el nombre del mdico que consult al servicio de imgenes. Modality Modality (0008,0060) especifica el tipo de equipo que adquiri los datos usados para crear la imagen. Device Serial Number Anatomic Structure, Space or Region Squence Device Serial Number (0018,1000) especifica el Anatomic Structure, Space or Region Squence (0008,2229) especifica la estructura anatmica, el espacio o la regin que ha sido expuesta a radiacin ionizante. Image Type Image Type (0008,0008) especifica el tipo de imagen. nmero de serie del equipo. Position (0018,5100) especifica la posicin del paciente con respecto al equipo de adquisicin de imgenes. Date of Last Calibration Date of Last Calibration (0018,1200) especifica la ltima vez en la que se calibr el dispositivo de adquisicin de imgenes. Manufacturer Manufacturer (0008,0070) especifica el

fabricante del equipo.

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....CS Code String DA Date Cadena de caracteres, siendo los espacios (20h) no significativos. Cadena de caracteres con el formato yyyymmdd, siendo yyyy el ao, mm el mes y dd el da 16 bytes max. 8 bytes

9

Acquisition Date Acquisition Date (0008,0032) especifica la fecha en la que empez la adquisicin de datos para crear la imagen. Visto esto, pasamos a explicar con ms detalle los distintos campos de un elemento de datos, con el objeto de poder disear e implementar un algoritmo que interprete correctamente la cabecera de cualquier fichero DICOM.

DS Decimal String

Cadena de caracteres 16 bytes representando un nmero en max. coma fija o flotante. 26 bytes max.

DT Date Time Representa una fecha. Veremos su codificacin ms adelante. FL Floating Point Single

Nmero en punto flotante de 4 bytes precisin simple. 8 bytes

FD Floating Nmero en punto Point Double IS Integer String LO Long String LT Long Text

4.2. Representacin del Valor El estndar DICOM define una serie de VRs con diferentes caractersticas, con la intencin de que el campo Valor de cada elemento de datos est codificado correctamente segn lo que representa. El listado, con las descripciones resumidas, es el siguiente:Nombre VR Definicin Longitud

Cadena de caracteres que 12 bytes representa un entero en base max. decimal. Cadena de caracteres. 64 caracteres max. 10240 caracteres max. Segn Sintaxis de Transfere ncia

Cadena de caracteres que puede tener uno o ms prrafos. Cadena de bytes. La codificacin del contenido depende del campo Sintaxis de Transferencia.

OB Other Byte String

OF Other Float String OW Other Word String

Cadena de nmeros en punto max. flotante de simple precisin. Cadena de palabras de 16 bits. La codificacin del contenido depende del campo Sintaxis de Transferencia. Segn Sintaxis de Transfere ncia

AE Application Cadena de caracteres que identifica una Entidad de Entity Aplicacin, siendo los espacios (20h) no significativos.

16 bytes max.

PN Person Name

AS Age String

Cadena de caracteres con uno 4 bytes de estos formatos: nnnD, nnnW, nnnM, nnnY; donde nnn es el nmero de D (das), W (semanas), M (meses), o Y (aos) Par ordenado de enteros sin signo de 16 bits (igual que la codificacin del campo Etiqueta del Elemento de Datos)

64 Cadena de caracteres de cinco componentes: apellidos, caracteres nombre de pila, segundo max. nombre, prefijo, sufijo. Cadena de caracteres. 16 caracteres max. 4 bytes No aplicable. 2 bytes

SH Short String SL Signed Long

Entero con signo de 32 bits en complemento a dos.

AT Attribute Tag

SQ Sequence Secuencia de cero o ms items. of Items SS Signed Short Entero con signo de 16 bits en complemento a dos.

10ST Short Text Cadena de caracteres que puede tener uno o ms prrafos. TM Time

DAVID DEL RO MEDINA ET AL.1024 caracteres max.

RevistaeSalud.com

4.3.1 Codificacin VR ExplcitaEn esta codificacin, 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 codificacin es la siguiente: 1. La etiqueta se codifica usando cuatro bytes: los dos primeros para el nmero de grupo y los dos ltimos para el nmero 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.

Cadena de caracteres con el 16 bytes formato hhmmss.frac, siendo max. hh la hora, mm los minutos, ss los segundos y frac la parte fraccional de un segundo. Formato 24 horas. Cadena de caracteres que contiene un Identificador nico. Entero sin signo de 32 bits. 64 bytes max. 4 bytes

UI Unique Identifier UL Unsigned Long

UN Unknown Cadena de bytes. La Cualquier codificacin del contenido es longitud desconocida. vlida para las dems VRs. US Unsigned Short Entero sin signo de 16 bits. 2 bytes max.

UT Unlimited Cadena de caracteres que puede contener uno o ms Text prrafos.

VR Date Time La VR Date Time se representa como una cadena con la forma YYYYMMDDHHMMSS.FFFFFF$ZZZZ siendo: YYYY = ao, MM = mes, DD = da, HH = hora, MM = minuto, SS = segundo, FFFFFF = fraccin de segundo, $ = + -, ZZZZ = horas y minutos de desplazamiento. $ZZZZ es un prefijo opcional para indicar el desplazamiento

3. Los

dos

bytes

siguientes

estn

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 ms adelante-, son para el valor, que estar codificado

respecto al Tiempo Universal Coordinado.

4.3 Codificacin Existen dos tipos de codificacin para los elementos de datos: VR explcita y VR implcita.

segn indica su VR y la sintaxis de transferencia. Lo podemos ver de forma ms grfica en esta tabla:

Vol. 4, N 16, 2008Etiqueta

LA CABECERA DEL ESTNDAR DICOM....

11

VRVR (cadena de caracteres de dos bytes) de valor: OB, OW, OF, SQ, UT o UN 2 bytes Reservado (dos bytes con el valor 0000h)

Longitud del ValorEntero sin signo de 32 bits

Valor

que estar codificado segn indica su VR y la sintaxis de transferencia.

N de Grupo (entero sin signo de 16 bits)

N de Elemento (entero sin signo de 16 bits)

Valor del elemento de datos codificado segn su VR y la sintaxis de transferenc ia

De forma ms grfica, en esta tabla: EtiquetaN de N de Grupo Elemento (entero sin (entero sin signo de signo de 16 bits) 16 bits) 2 bytes 2 bytes

VR

Longitud del Valor

Valor

2 bytes

2 bytes

2 bytes

4 bytes Los bytes que indiquen Longitud de Valor, salvo en caso especial

del Vr Entero sin Valor (cadena signo de 16 elemento de datos de dos bits codificado bytes) segn su VR y la sintaxis de transferencia

2 bytes

2 bytes

Los bytes que indiquen Longitud de Valor, salvo en caso especial

Si la VR del elemento de datos es cualquiera que no sea una de las anteriormente mencionadas, la codificacin es la siguiente: 1. La etiqueta se codifica usando cuatro bytes: los dos primeros para el nmero de grupo y los dos ltimos para el nmero 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. 1. La etiqueta se codifica usando cuatro 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, bytes: los dos primeros para el nmero de grupo y los dos ltimos para el nmero de elemento. Es decir, una pareja de enteros sin signo de 16 bits, al igual que la VR AT.

4.3.2 Codificacin VR ImplcitaEsta es la codificacin que se usa para la sintaxis de transferencia por defecto, y la diferencia ms importante respecto con la anterior (VR explcita) 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 estndar (o una base de datos externa al fichero) para obtenerla, al igual que ocurre con la descripcin del elemento de datos y con su obligatoriedad. La codificacin es la siguiente:

12

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

2. Los siguientes cuatro bytes son para la longitud del valor, codificada como un entero sin signo de 32 bits.

recursivamente para contener estructuras con mltiples niveles de anidamiento. Hay tres elementos de datos especiales usados

3. Los siguientes bytes, tantos como indica la longitud del valor -salvo en el caso especial-, son para el valor, que estar codificado segn indica su VR y la sintaxis de transferencia. De forma ms grfica, en esta tabla:EtiquetaNmero de grupo (entero sin signo de 16 bits)

en las secuencias que no siguen las normas de la sintaxis de transferencia convenida. Estos deben ser codificados siempre como VR implcita. Estos elementos de datos especiales son: tem (FFFE,E000), tem de Delimitacin de tem (Item Delimitation Item) (FFFE,E00D), e tem de Delimitacin de Secuencia (Sequence Delimitation Item) (FFFE,E0DD).

Longitud del Valor

Valor

del Nmero de Entero sin Valor de elemento signo de 32 elemento datos codificado (entero sin bits segn su VR y la signo de 16 sintaxis de bits) transferencia

4.3.4 Codificacin de los itemsCada tem de un elemento de datos con VR SQ debe ser codificado como un elemento de datos con una etiqueta especfica 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 Explcita: el nmero de bytes del campo Valor del tem (que es el campo siguiente), codificado como un entero sin signo de 32 bits.

2 bytes

2 bytes

4 bytes

Los bytes que indiquen Longitud de Valor, salvo en caso especial

4.3.3 SecuenciasEntre las diferentes VRs, tenemos que hacer mencin especial a la VR Secuencia (SQ), debido a que, por su naturaleza, aquellos elementos de datos cuya VR es SQ tienen una codificacin 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 ms 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

Longitud Indefinida: el campo Longitud del tem debe tener el valor FFFFFFFFh. Debe ser usado en conjunto con un elemento de datos de tipo Delimitacin del tem. El elemento de datos Delimitacin del tem debe tener una etiqueta de valor (FFFE,E00D) y debe

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

13

seguir a los elementos de datos que estn 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 ms elementos de datos dentro de un tem pueden tener una VR SQ, permitiendo de esta manera la recursin.

A continuacin veremos tres ejemplos diferentes de secuencias, para que podamos entender mejor la informacin expuesta arriba.

4.3.5 Codificacin de una secuenciaUn elemento de datos con VR SQ (es decir, una secuencia) puede estar codificado, al igual que el resto, con VR implcita o explcita. En cualquier caso, el campo Longitud del Valor puede ser codificado como: Longitud Explcita: el nmero de bytes del campo Valor, al igual que con cualquier normal. Longitud Indefinida: el campo Longitud del Valor debe tener el valor FFFFFFFFh. Debe ser usado en conjunto con el elemento de datos tem de Delimitacin de Secuencia, que ser el ltimo tem del campo Valor. El tem de delimitacin 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. otro elemento de datos

14

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

Ejemplo de un elemento de datos de VR Secuencia con codificacin VR Implcita, con tres tems de longitud explcita.

Ejemplo de un elemento de datos de VR Secuencia de longitud indefinida, con codificacin VR Explcita con dos tems de longitud explcita.

Ejemplo de un elemento de datos de VR Secuencia de longitud indefinida, con codificacin VR Implcita con dos tems, donde el primero tiene longitud explcita y el segundo longitud indefinida.

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM.... Sintaxis de TransferenciaImplicit VR Little Endian

15 Identificador nico DescripcinSintaxis de transferencia por defecto. Para formato de imagen no encapsulado. Para formato de imagen no encapsulado. Se especifica la Representacin del Valor (Value Representation o VR) de cada elemento de la cabecera. Codificacin little endian. Para formato de imagen no encapsulado. Se especifica la Representacin del Valor (Value Representation o VR) de cada elemento de la cabecera. Codificacin big endian.

La meta-cabecera contiene datos generales sobre el fichero DICOM en cuestin. Estos datos estn 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, slo necesitaremos conocer uno de estos datos: la sintaxis de transferencia (Transfer Syntax).

1.2.840.10008.1.2

Explicit VR Little Endian

1.2.840.10008.1.2.1

Explicit VR Big 1.2.840.10008.1.2.2 Endian

5. SINTAXIS DE TRANSFERENCIALa 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 estn codificados con algn formato encapsulado, como por ejemplo JPEG). A continuacin listaremos algunas de las sintaxis de transferencia existentes, junto con su identificador nico y su descripcin:JPEG-LS JPEG sin prdida JPEG con prdida

1.2.840.10008.1.2.4. Baseline (1) 50 1.2.840.10008.1.2.4. Extended (2,4) 51 1.2.840.10008.1.2.4. Extended (3,5) 52 1.2.840.10008.1.2.4. Lossless, non57 hierar. (14) 1.2.840.10008.1.2.4. Lossless, hierar., 70 first-order pred. 14, Select. Val. 1 1.2.840.10008.1.2.4. Lossless mode 80 1.2.840.10008.1.2.4. Near-lossless 81 mode

JPEG 2000

1.2.840.10008.1.2.4. Lossless mode 90 1.2.840.10008.1.2.4. Lossless mode or 91 lossy mode

RLE Compression

1.2.840.10008.1.2.5

Compresin RunLength Enconding

16

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

6. CABECERA6.1. Introduccin La cabecera de un fichero DICOM es la parte que nos va a proporcionar la gran mayora de la informacin que necesitamos para visualizar la imagen correctamente, incluyendo los propios datos de la imagen, ya que stos son considerados por el estndar como un elemento ms de la cabecera. La cabecera de un fichero DICOM consiste en un conjunto de elementos de datos (Data Set) con toda la informacin necesaria, y est codificada segn la sintaxis de transferencia indicada en la meta-cabecera. Existen cuatro tipos de cabecera segn la sintaxis de transferencia: tres para imgenes en formato no encapsulado (como RGB) y una para imgenes en formato encapsulado (como JPEG o RLE). A lo largo de la seccin daremos una explicacin detallada de estos cuatro tipos.

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)

6.2. Sintaxis de transferencia VR Implcita Little Endian Una cabecera codificada con la sintaxis de transferencia VR Implcita Little Endian (Implicit VR Little Endian Transfer Syntax) debe cumplir los siguientes requerimientos: Los elementos de datos deben de estar codificados con VR implcita, especificada anteriormente.

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.

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

17

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.

VR Little Endian Transfer Syntax) debe cumplir los siguientes requerimientos: Los elementos de datos deben de estar codificados con VR explcita, 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

El

elemento

de

datos

(0028,3006)

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 explcita en su campo VR. En el

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.

6.3. Sintaxis de transferencia VR Explcita Little Endian Una cabecera codificada con la sintaxis de transferencia VR Explcita Little Endian (Explicit

18

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

documento 3 del estndar se encuentra una lista de VRs permitidas. El elemento de datos (5400,1010) Waveform Data tiene la VR especificada de forma explcita 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 Red, (0028,1101), (0028,1102), (0028,1103)

6.4. Sintaxis de transferencia VR Explcita Big Endian Una cabecera codificada con la sintaxis de transferencia VR Explcita Big Endian (Explicit VR Big Endian Transfer Syntax) debe cumplir los siguientes requerimientos: Los elementos de datos deben de estar codificados con VR explcita, 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.

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.

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

19

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 explcita en su campo VR. En el documento 3 del estndar se encuentra una lista de VRs permitidas. El elemento de datos (5400,1010) Waveform Data tiene la VR especificada de forma explcita 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 encapsulados de Transferencia

para

datos

de

pxeles

Una cabecera codificada con una de las Sintaxis para Datos de Pxeles for Encapsulados (Transfer Syntaxes

Encapsulation of Encoded Pixel Data) debe cumplir los siguientes requerimientos: Los elementos de datos deben de estar codificados con VR explcita, 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 explcita, y debe estar codificado como sigue:

20

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

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.

es seguida por el campo Longitud del tem de 4 bytes, que contiene el nmero explcito de bytes del tem. Todos los items que contienen un

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. Si est en formato encapsulado, tiene la VR OB y es la secuencia de bytes resultante de uno de los procesos de codificacin. Contiene el flujo codificado de datos de los pxeles fragmentado en uno o ms items. Este flujo de datos de los pxeles debe representar una imagen simple o multiframe: La longitud del elemento de datos (7FE0,0010) debe debe estar codificada como longitud indefinida (FFFFFFFFh). Cada fragmento de flujo de datos codificado con el procedimiento de codificado debe especfico estar acordado,

fragmento

codificado

deben

tener un nmero 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 pxeles debe ser el tem Tabla Bsica de Desplazamientos (Basic Offset Table). El valor de la tabla bsica 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

encapsulado como un tem con una etiqueta de elementos de datos especfica de valor (FFFE,E000). La etiqueta del tem

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....

21

frame en la secuencia de items. mientos byte de Estos se la desplazamiden primera

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 ordenacin de los bytes (little endian o big endian) no les afecta. A continuacin veremos dos ejemplos sobre la

empezando por el primer etiqueta del tem que sigue a la tabla bsica de desplazamientos. Esta secuencia de items es terminada por un tem de delimitacin 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 explcita en su campo VR. En el documento 3 del estndar se encuentra una lista de VRs permitidas. El elemento de datos (5400,1010) Waveform Data tiene la VR especificada de forma explcita 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

codificacin del elemento de datos Pixel Data (7FE0,0010) en estas sintaxis de transferencia, con el objeto de que podamos entenderlo mejor.

22

DAVID DEL RO MEDINA ET AL.

RevistaeSalud.com

Ejemplo de una imagen de un frame simple definida como sin una la secuencia tabla de tres de

fragmentos

bsica

desplazamientos.

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

Vol. 4, N 16, 2008

LA CABECERA DEL ESTNDAR DICOM....8.

23

BIBLIOGRAFA

[com08h] DICOM committee, editor. PS 3.18: Web Access to DICOM Persistent Objects (WADO). DICOM, 2008.

1.

[com08a] DICOM committee, editor. PS 3.1: Introduction and Overview. DICOM, 2008.

9.

[com08i] DICOM committee, editor. PS 3.2: Conformance. DICOM, 2008.

2.

[com08b] DICOM committee, editor. PS 3.10: Media Storage and File Format for Data Interchange. 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.

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.

RevistaeSalud.com es una publicacin electrnica que intenta promover el uso de TICs (Tecnologas de la Informacin y las Comunicaciones) con el propsito de mejorar o mantener la salud de las personas, sin importar quines sean o dnde estn. Edita: FESALUD Fundacin para la eSalud Correo-e: [email protected] ISSN 1698-7969

Los textos publicados en esta revista, a menos que se indique lo contrario, estn sujetos a una licencia de Reconocimiento-NoComercial-SinObraDerivada 2.5 de Creative Commons. Pueden copiarse, distribuirse y comunicarse pblicamente, siempre que se citen el autor y la revista digital donde se publican, RevistaeSalud.com. No se permite su uso comercial ni la generacin de obras derivadas. Puede consultarse la licencia completa en http://creativecommons.org/licenses/by-nc-nd/2.5/deed.es