informacion RAD 1709

Informática en Radiología ( informacion RAD)

RadioGraphics

Un marco de código abierto para la modificación y

comunicación de objetos DICOM 1

Thomas Hackla¨nder, MD, MSc ● ● Jens Martin, MSc ● ● Klaus Kleber, MSc

Se ha desarrollado un marco configurable que puede recibir, modificar y exportar imágenes en diferentes
escenarios de archivo de imágenes y sistemas de comunicación. El marco tiene tres componentes principales: un
receptor para objetos de Imagen Digital y Comunicaciones en Medicina (DICOM), una tubería de procesamiento
para aplicar una o más modificaciones a estos objetos y uno o más remitentes para enviar los objetos procesados
​a destinatarios predefinidos. La programación de la caja de herramientas se implementó como un proyecto de
código abierto en Java. La canalización de procesamiento utiliza el concepto de complementos configurables. Un
complemento es programable por el usuario mediante archivos de lenguaje de hoja de estilo extensible y permite la
conversión de objetos DICOM a documentos de lenguaje de marcado extensible u otros tipos de archivos. Los
canales de entrada y salida son el servicio de almacenamiento DICOM, discos compactos DICOM, memoria de
solo lectura (CDROM), y el sistema de archivos local. La caja de herramientas se ha aplicado con éxito a diferentes
escenarios clínicos, incluida la corrección de objetos DICOM a partir de las modalidades de no integración de la
empresa de atención médica (IHE), el seudónimo de imágenes DICOM y el uso del perfil de datos portátiles IHE
para imágenes con importación y exportación de CD -ROMs. La caja de herramientas ha demostrado ser confiable
en la rutina clínica. Debido a las interfaces de programación abiertas, la funcionalidad se puede adaptar fácilmente
a futuras aplicaciones. La caja de herramientas ha demostrado ser confiable en la rutina clínica. Debido a las
interfaces de programación abiertas, la funcionalidad se puede adaptar fácilmente a futuras aplicaciones. La caja
de herramientas ha demostrado ser confiable en la rutina clínica. Debido a las interfaces de programación abiertas,
la funcionalidad se puede adaptar fácilmente a futuras aplicaciones.

©© RSNA, 2005

Abreviaturas discos compactos disco compacto, DICOM Imagen digital y comunicaciones en medicina, DSA angiografía de sustracción digital, HTML lenguaje de marcado de hipertexto, IHE Integrando
la Empresa de Salud, PACS sistema de archivo y comunicación de imágenes, PDI Datos portátiles para imágenes, UID identificador único, XML lenguaje de marcado extensible, XSL lenguaje de
hoja de estilo extensible

RadioGraphics 2005; 25: 1709-1721 ● ● Publicado en línea 10.1148 / rg.256055072 ● ● Código de contenido:

1 Del Departamento de Radiología, HELIOS KlinikumWuppertal, Hospital de la Universidad de Witten-Herdecke, Heusnerstrasse 40, 42283 Wuppertal, Alemania (TH); y VISUS Technology Transfer,
Bochum, Alemania (JM, KK). Presentado como un informacion Exposición RAD en la Reunión Anual RSNA 2004. Recibido el 28 de marzo de 2005; revisión solicitada el 23 de junio y recibida el 13 de
julio; aceptado el 18 de julio. Todos los autores no tienen relaciones financieras que revelar. Dirección de correspondencia a El correo: thomas@hacklaender-online.de ).

©© RSNA, 2005
 1710 noviembre-diciembre 2005
Introducción
El intercambio de información radiológica está definido por el
estándar Digital Imaging and Communications in Medicine
(DICOM) y el estándar Health Level Seven (HL7) (1–5). Sobre la
base de estos estándares, el marco de Integrating the Healthcare
RadioGraphics
Enterprise (IHE) (6,7) define los flujos de trabajo típicos para los
procesos en imágenes médicas.
Cuando se analiza el flujo de trabajo de un sistema de archivo y
comunicación de imágenes (PACS) (Fig.
1), la comunicación de imágenes se puede dividir en tres dominios
funcionales abstractos: en un entorno PACS, las imágenes adquiridas con
las modalidades se transfieren entre el archivo y las estaciones de trabajo
en un mundo restringido y bien definido. Para la comunicación externa, las
imágenes se pueden transferir a través de la red a otro sistema compatible
con DICOM como otro PACS (por ejemplo, el servidor del departamento o
servidores de otras empresas) u otra estación de trabajo (por ejemplo, una
estación de teleradiología). Las imágenes salen del PACS como
impresiones de películas o como medios de imagen en forma de CD
grabables DICOM; otros PACS tienen que importar imágenes de estos
medios. En todos estos escenarios, se producen errores debido a
estructuras de datos codificadas incorrectamente o simplemente por la
falta de interfaces.
PUNTOS PARA LLEVAR A CASA
Los objetos DICOM se pueden leer y escribir mediante diferentes
técnicas y protocolos.
Los objetos DICOM se pueden modificar de forma automatizada sin que el
usuario esté presente mediante reglas definidas por el usuario.
Una interfaz de programación abierta permite la extensión de la funcionalidad.
La caja de herramientas se implementa como un proyecto de código abierto en
Java.
RG F Volumen 25 ● ● Número 6
Para permitir la comunicación y la corrección de los objetos
DICOM en el flujo de trabajo, se debe conectar una aplicación
configurable a un canal existente entre dos dispositivos. Esta
aplicación debería poder recibir imágenes de un usuario de clase
de almacenamiento de imágenes DICOM o un CD grabable
DICOM; debería poder manipular la información de la imagen y
exportar finalmente las imágenes a un proveedor de clase de
servicio de almacenamiento DICOM o en forma de CD grabables
DICOM.
Las siguientes dificultades pueden surgir de implementaciones
incorrectas de los estándares: Una aplicación (modalidad, estación de
trabajo, estación de teleradiología) puede ( una) enviar información a los
campos de datos incorrectos, ( si) enviar objetos de imagen con campos
de datos codificados incorrectamente, o ( C) No envíe ninguna información
obligatoria.
Estas dificultades a menudo se pueden resolver modificando los
elementos de datos o deduciendo su contenido de otros elementos. La
manipulación de elementos de datos también puede mejorar los casos
de uso que no están definidos en IHE. Sin embargo, esto puede llevar
mucho tiempo y estar lleno de errores cuando se realiza en un caso
individual.
Para lograr el mayor grado posible de flexibilidad, hemos
desarrollado un dispositivo de procesamiento en forma de una caja de
herramientas de funciones que puede realizar modificaciones de datos
de manera automatizada sin supervisión.
Concepto de materiales y
métodos
El concepto de nuestro software de procesamiento, que hemos
denominado DICOMRouter, es el de una estructura modular que permite
un uso flexible. Hay dos receptores para los objetos DICOM entrantes:
el primer receptor se puede alimentar con imágenes del PACS
directamente a través de la red. El enrutador proporciona el servicio
DICOM Almacenamiento como proveedor de clase de servicio. Esto lo
convierte en un nodo receptor desde el punto de vista PACS. El usuario
puede seleccionar entre dos modos de transmisión: transmisión
encriptada de Seguridad de la capa de transporte (TLS) o transmisión
abierta, ambas definidas en
 RG F Volumen 25 ● ● Número 6
RadioGraphics
DICOM estándar. El segundo receptor puede acceder a los archivos
almacenados en el sistema de archivos, ya sea localmente en la
computadora donde se está ejecutando la caja de herramientas o en un
externo, como un CD grabable. Estos archivos deben contener objetos
DICOM y deben almacenarse de acuerdo con DICOM parte 10.
Independientemente de qué receptor lea un objeto DICOM, se
decodifica en una estructura de datos abstractos y se coloca en la
tubería de procesamiento de la caja de herramientas. La canalización de
procesamiento se implementa como una secuencia de complementos.
Cada complemento representa un segmento de programa autónomo
que calcula una tarea claramente definida. Recibe un paquete de datos
de un receptor o del complemento anterior, procesa el paquete y lo pasa
al siguiente complemento de la canalización.
Cuando se han calculado todos los pasos de la canalización de
procesamiento, el paquete de datos se envía a sus destinatarios. Hay varios
remitentes disponibles, cada uno realizado como un complemento. De esta
forma, la caja de herramientas puede enviar paquetes de datos
consecutivamente a través de varios canales de salida a múltiples
receptores. La versión operativa actual del DICOMRouter pro-
Hackla¨nder et al 1711
Figura 1. Flujo de trabajo de un PACS. En un entorno PACS, las
imágenes adquiridas con las modalidades se transfieren entre el
archivo y las estaciones de trabajo en un mundo cerrado. Las
imágenes generalmente salen del PACS como impresiones de
películas o como medios de imagen en forma de discos
compactos (CD) grabables, que también permiten la importación
de imágenes estandarizadas. Como funciones adicionales, el
DICOMRouter permite importar, exportar y corregir objetos
DICOM. DVD disco de video digital, ordenador personal computadora
personal.
Vide canales de salida complementarios a los dos receptores.
Además, permite la escritura de datos en medios de
almacenamiento organizados de acuerdo con la parte 12 del
estándar DICOM. En particular, estos son CD grabables DICOM.
El diseño del software permite que varias instancias del
DICOMRouter se ejecuten simultáneamente en una computadora. Para
cada caso, un archivo de configuración define una canalización de
procesamiento inherente que incluye el receptor.
Capa Funcional
La capa funcional del DICOMRouter se realiza como una biblioteca de
programas. El uso de esta biblioteca permite la implementación de
pequeños programas, llamados front-end, para los diferentes casos de
uso. Como una posibilidad, la Figura 2 muestra el front-end utilizado en
el proyecto de desarrollo con su interfaz gráfica de usuario.
 1712 noviembre-diciembre 2005 RG F Volumen 25 ● ● Número 6

RadioGraphics

Figura 2. Ejemplo de un front end. Las pantallas del DICOMRouter muestran una interfaz que está organizada en tres fichas. ( una) En
la primera tarjeta, el usuario selecciona y configura el receptor. ( si) En la segunda tarjeta, se selecciona el archivo de configuración.
( C) La tercera tarjeta le permite a uno seleccionar el archivo de configuración para el registrador e iniciar el receptor seleccionado.
Además, se muestran una barra de progreso y un campo de texto para la salida de la información de registro.

La arquitectura interna del programa del DICOMRouter

tiene una jerarquía multicapa (Fig.
3) La ventaja para el usuario es que no se necesita un conocimiento
detallado de los procesos de comunicación DICOM o de los detalles
internos del complemento para adaptar la funcionalidad. El usuario solo
ve la capa superior del programa del enrutador DICOM, compuesta por
la interfaz gráfica de usuario del front-end seleccionado y un archivo de
configuración. La Figura 4 muestra un extracto de un archivo de
configuración para un caso de uso específico, almacenado en formato
de texto.
Figura 3. Estructura del DICOMRouter que se muestra como un diagrama de
capas. Tanto los receptores como los complementos utilizan la biblioteca
dcm4che para todas las comunicaciones DICOM. El usuario define la
funcionalidad deseada modificando un archivo de configuración y controla el
DICOMRouter con un extremo frontal.
 RG F Volumen 25 ● ● Número 6 Hackla¨nder et al 1713

Figura 4. Con fi guración de TagModifyPlugin para

corregir los atributos DICOM de la imagen
angiográfica de sustracción digital (DSA) que se
muestra en la Figura 5.
RadioGraphics

tabla 1
Complementos implementados, sus funciones y el número de atributos modificables

Nombre del complemento Función* No. de opciones

DicomStorageSCUPlugin Utiliza el servicio de almacenamiento DICOM para almacenar el objeto DICOM en un SCP de 25
almacenamiento DICOM

ExportImagePlugin Exporta el objeto DICOM dado como una imagen gráfica estándar 11
InfoPlugin Registra información del objeto DICOM procesado (por ejemplo, nombre del paciente, fecha 00

de examen e identificadores)
NullPlugin No hace nada; se puede usar como marcador de posición en la cola de complementos 00

PortableMediaCreatorPlugin crea una estructura de CD compatible con PDI IHE 99

PrivateRemovePlugin Elimina todos los elementos privados del objeto DICOM. 00

SeudónimoPlugin Reemplaza el nombre del paciente con un seudónimo 1

SaveDicomdirPlugin Guarda el objeto DICOM en el sistema de archivos local en una estructura de directorio 2
DICOM
SaveFilesystemPlugin Guarda el objeto DICOM como un archivo en el sistema de archivos local 66

TagModifyPlugin Modifica elementos nombrados del objeto DICOM 1) . . norte

UIDModifyPlugin Modifica el UID de instancia de SOP, el UID de instancia de estudio y el UID de instancia de 44

serie
XSLTransformPlugin Transforma el objeto DICOM dado en una representación XML y opcionalmente 13
procesa eso utilizando un archivo XSL

* *PDI Datos portátiles para imágenes, SCP Proveedor de clase de servicio, SOP par de objeto de servicio, identificador único UID, XML lenguaje de marcado
extensible, XSL Lenguaje de hoja de estilo extensible.

El usuario puede cambiar los valores de los atributos de los
complementos mediante un simple editor de texto.
Implementación
El software fue programado completamente en Java (versión 1.4) (Sun
Microsystems, Santa Clara, California). Como se muestra en la Figura 3,
la funcionalidad DICOM está completamente encapsulada en la biblioteca
dcm4che (8). También es compatible con los perfiles de conexión de
transporte seguro DICOM para canales de comunicación cifrados. La
elección de esta biblioteca como una capa inferior tiene la ventaja de que
todas las capas superiores deben manejar solo estructuras abstractas
DICOM. Esto se aplica a los receptores, a todos los componentes
enchufables y a las interfaces del programa.
Cada complemento se implementa mediante su propia clase Java.
Para permitir una extensión fácil con nuevas funcionalidades, se define
una interfaz de programación simple para los complementos. Al copiar
complementos compilados en una carpeta de clase predefinida del
DICOMRouter, los complementos estarán disponibles inmediatamente
para la canalización de procesamiento sin volver a vincular todo el
programa. La versión actual del DICOM
El enrutador incluye los complementos enumerados en la Tabla 1. Los
ejemplos descritos en la introducción se pueden procesar completamente
con este conjunto.
Se pueden realizar funciones más complejas a través de
XSLTransformPlugin. A diferencia de los otros complementos, este
no tiene su propia rutina de procesamiento. Su función de
procesamiento se describe y configura mediante un archivo de texto
externo como una plantilla XSL (9). Este concepto brinda la
posibilidad al usuario de programar nuevas funcionalidades que
pueden requerir combinaciones complejas de elementos del objeto
DICOM. Antes de aplicar la plantilla XSL, el objeto DICOM se
convierte en un documento XML (10). La conversión permite una
fácil transferencia del objeto DICOM a otros formatos de archivo
(11), que se pueden guardar en el sistema de archivos local. Por
ejemplo, una de las plantillas XSL definidas en el proyecto exporta
objetos DICOM como archivos de lenguaje de marcado de hipertexto
(HTML).
 1714 noviembre-diciembre 2005 RG F Volumen 25 ● ● Número 6

RadioGraphics

Figura 5. (a) Imagen enviada por un dispositivo DSA con valores de atributo DICOM parcialmente incorrectos. ( si) La imagen después de la corrección de los valores
de atributo por el DICOMRouter.

Para rastrear la salida del programa, se utiliza la biblioteca de registro log4j

Tabla 2
(12). En lugar de escribir la salida del registro en la pantalla local, esta
Atributos DICOM en el módulo de píxeles de imagen de un
biblioteca también puede almacenar la información del registro como archivos dispositivo DSA anterior (Fig. 5)
locales o enviarla a cualquier computadora conectada a la red.
Valores enviados por Valores después

Los requisitos para el hardware de la computadora son iguales a los

DICOMAttribute el dispositivo de la corrección

del entorno de ejecución Java: un procesador Pentium II (Intel, Santa Filas 512 1024
Clara, California) con una unidad central de procesamiento (CPU) de 400 Columnas 512 1024
MHz y una memoria de 256 MB es suficiente para ejecutar el programa. . Bits asignados 8 dieciséis

La capacidad del disco duro se relaciona con las operaciones realizadas Bits almacenados 8 15
de los complementos utilizados. Los componentes principales del Poco alto 77 15
programa del enrutador DICOM requieren solo 1,5 MB de espacio en
disco.
Los datos de imagen mostraron que algunos de los atributos requeridos para la

El proyecto ha sido publicado como un proyecto de código visualización de imágenes eran incorrectos y debían corregirse, como se

abierto bajo la Licencia Pública General de GNU (GPL) y se puede describe en la Tabla 2.

descargar de forma gratuita (13).

Resultados
Modificación de objetos DICOM
La transformación correcta de las estructuras de datos, como se define a
través de los estándares, es una condición previa necesaria para los
procesos de operación funcional. Sin embargo, no es el caso en todos los
sistemas clínicamente utilizados. El siguiente ejemplo ilustra cómo se
puede utilizar el marco en la práctica simplemente configurando un
complemento.
Solución. —El DICOMRouter se aplicó entre la modalidad y el
archivo de imágenes. El dispositivo DSA envía las imágenes al
enrutador DICOM con la clase de servicio de almacenamiento
DICOM, con lo cual el DICOMRouter corrige los atributos incorrectos
automáticamente y reenvía los datos de la imagen al archivo de
imágenes. Para la corrección de los datos de la imagen, se utiliza
TagModifyPlugin. Es capaz de reemplazar los atributos incorrectos
con los valores correctos. La configuración de TagModifyPlugin se
puede obtener de la Figura 4. Cuando una estación de trabajo llama
a estos datos de imagen desde el archivo de imágenes, la imagen
se ve como se ve en la Figura 5b.

Ejemplo 1. —Las imágenes que se transmitieron desde un

dispositivo DSA al PACS se mostraron completamente
codificadas (Fig. 5a). Análisis de la Ejemplo 2 —La anonimización de los datos de la imagen es necesaria en
aquellos casos en los que se accederá a los datos de la imagen fuera del área
de diagnóstico o tratamiento.
 RG F Volumen 25 ● ● Número 6
RadioGraphics
Figura 6 Con fi guración del DICOMRouter para la eliminación de los atributos de identificación del paciente. Las imágenes se envían desde una
estación de trabajo o modalidad al DICOMRouter, que borra los datos personales de las imágenes. PseudonymPlugin, TagModifyPlugin,
PrivateRemovePlugin y UIDModifyPlugin se ejecutan secuencialmente. Luego, las imágenes modificadas se almacenan en el archivo PACS como una
copia. SCP Proveedor de clase de servicio.
Las sesiones de enseñanza y los proyectos de investigación son ejemplos
comunes. En muchos PACS, esto solo es posible de forma limitada,
especialmente cuando los datos se deben reenviar a través de un CD.
Solución. —Para este proceso, la clase de servicio de
almacenamiento DICOM envía los datos de imagen del archivo de
imágenes al DICOMRouter. El enrutador DICOM manipula estos
datos de imagen y luego los devuelve al archivo de imágenes. Aquí,
PseudonymPlugin, TagModifyPlugin, PrivateRemovePlugin y
UIDModifyPlugin se ejecutan secuencialmente (Fig. 6).
PseudonymPlugin reemplaza automáticamente el nombre del
paciente con un seudónimo, ya que el campo que contiene el
nombre del paciente no se puede eliminar, ya que es una parte
elemental de cada imagen DICOM. TagModifyPlugin está
configurado de tal manera que una fila de campos, que según los
estándares DICOM no se pueden eliminar, se establece con un
valor no válido. Esto afecta principalmente a campos como ID de
paciente y Número de acceso. La ID de paciente de campo se
mantiene como un identificador inequívoco y en parte reemplaza los
nombres de otros sistemas como Order Filler en el contexto IHE
Reconciliación de información del paciente. El número de acceso de
campo se utiliza parcialmente para la asignación de resultados.
Además de los atributos definidos por el estándar DICOM, también
puede haber elementos denominados privados en las imágenes DICOM,
cuyo contenido es establecido por los respectivos sistemas de creación.
Dado que estos atributos también pueden contener el nombre de usuario
(que también ocurre en algunos casos), PrivateRemovePlugin los
elimina.
El último complemento es UIDModifyPlugin, que establece el
UID de instancia SOP [par de objeto de servicio], UID de instancia
de estudio y UID de instancia de serie en otro valor único. Estos
deben ser ed-
Hackla¨nder et al 1715
para que el archivo de imagen que recibe los datos de la imagen
interprete esas imágenes como un nuevo examen y las deposite en el
archivo de imágenes. Después de la ejecución de los complementos,
hay un nuevo conjunto de datos disponible en el PACS, que ya no
contiene referencias al paciente.
Ejemplo 3 —Debido al flujo de trabajo y la infraestructura en nuestro
hospital, era necesario proporcionar a los médicos en un hospital
remoto acceso a estudios de tomografía computarizada (TC) realizados
en nuestras instalaciones. Dado que nuestro PACS está equipado con
un software de distribución de imágenes basado en HTML, el método
obvio era permitir el acceso del hospital externo a nuestro sistema de
distribución de imágenes a través de teleradiología (14). El médico
externo está conectado a una puerta de enlace fuera del cortafuegos
de nuestro hospital a través de Internet. La conexión requiere
certificados de acceso y está encriptada con Secure Socket Layer
(SSL). Para mejorar la protección de la privacidad, el médico externo
debe poder acceder solo a las imágenes que ya han sido
seudonimizadas.
Solución. —Las imágenes se envían desde una estación de trabajo a
un DICOMRouter, que borra todos los datos personales de las
imágenes (Fig. 6) y llena el elemento de datos Médico de referencia
con un valor predefinido. Luego, las imágenes modificadas se
almacenan en el archivo PACS como una copia. Al determinar los
derechos de acceso especiales, los médicos externos pueden revisar
solo las imágenes con seudónimo con el valor especial del elemento
de datos Médico de referencia. Por esa razón, el DICOMRouter está
físicamente ubicado en la sala de servidores del hospital. El registro
se configura de tal manera que
 1716 noviembre-diciembre 2005 RG F Volumen 25 ● ● Número 6

RadioGraphics

Figura 7. (a) La imagen fluoroscópica original de un examen de enema de doble contraste muestra el colon transverso. Las regiones no expuestas por rayos X
están representadas por áreas oscuras. No se muestra el patrón de rayos X habitual hasta que la imagen se invierte ( si).

Figura 8. La configuración de
XSLTransformPlugin se utiliza para
cambiar la interpretación fotométrica
de la imagen en la Figura 7 de
MONOCROMO2 a
MONOCROMO1.

Figura 9 Extracto de la representación XML

de la imagen en la Figura 7. Cada elemento
DICOM está representado por un elemento
XML del tipo "elm". Los campos del elemento
DICOM, como la etiqueta, están
representados por atributos del elemento
XML. El elemento XML hijo "val" cubre el
valor del elemento DICOM; este valor se da
realmente en el atributo "datos".

los mensajes se enrutan a la computadora del administrador de PACS
para mantenerlo informado sobre la funcionalidad. Procesamiento
simultáneo de estudios de TC multisección con más de 500 imágenes
cada uno sin ningún problema. El tiempo de procesamiento está
directamente relacionado con la tubería de procesamiento configurada, el
tamaño de la imagen y el hardware del sistema. En nuestra instalación se
utiliza un sistema Pentium II con una velocidad de reloj del procesador de
450 MHz y una tubería de procesamiento de seis complementos. Con un
tamaño de matriz de 512 512 píxeles, el tiempo de procesamiento del
DICOMRouter es de 2 segundos por imagen.
Ejemplo 4 —Todas las imágenes de los exámenes fluoroscópicos
deben invertirse, como se muestra en la Figura 7.
Solución. —Si un valor de píxel de 0 debe mostrarse como
blanco o negro, está definido por el elemento DICOM
Interpretación fotométrica. Por lo tanto, el proceso de invertir
una imagen se puede lograr cambiando el valor de este
elemento de MONOCROMO1 a MONOCROMO2 o
viceversa. Debido a que la modificación requiere la decisión
lógica de si el valor original es MONOCROMO1 o
MONOCROMO2, TagModify no pudo resolver el problema.
 RG F Volumen 25 ● ● Número 6 Hackla¨nder et al 1717

RadioGraphics

Figura 10 Transformación XSL aplicada por XSLTransformPlugin para cambiar la interpretación fotométrica de la imagen en la Figura 7 de
MONOCROMO2 a MONOCROMO1.

Enchufar. En lugar de programar un complemento especializado,
se puede adoptar XSLTransformPlugin. Al usar el archivo de
configuración en la Figura 8, la imagen se convierte en la
representación XML en la Figura 9. Después de la aplicación de la
transformación XSL en la Figura 10, la representación XML se
convierte en DICOM. Para acelerar el proceso, los datos de
píxeles no se convierten a XML.
Como una aplicación basada en reglas, la transformación XSL se
realiza mediante la aplicación de elementos de "plantilla" a la
representación XML en su conjunto. Si más de una plantilla coincide
con la fuente, se elige la que tenga la prioridad más alta. Si no se
especifica
 1718 noviembre-diciembre 2005 RG F Volumen 25 ● ● Número 6

RadioGraphics

Figura 11 Árbol de directorios creado por PortableMediaCreatorPlugin. El ejemplo muestra el árbol después de la exportación de una
imagen de un estudio con las siguientes especificaciones: El paciente se llama Hans Mustermann (seudónimo) y nació el 22 de mayo
de 1957. El estudio se realizó el 30 de diciembre de 2004 a las 15 : 31 en una cámara de resonancia magnética (MR). El estudio y los
identificadores de serie (ID) son 4711 y 3, respectivamente. El número de instancia de la imagen es 54.

de lo contrario, la prioridad de una plantilla es entre

0.5 y 0.5, dependiendo del patrón de coincidencia. En este
ejemplo, todos los elementos DICOM, excepto la interpretación
fotométrica, deben dejarse intactos. Para eso, la segunda
plantilla en la Figura 10 copia todos los nodos desde el origen
hasta el destino. Como esta plantilla tiene una prioridad de 2.0, se
sobrescribe con la primera plantilla, que solo coincide con la
Interpretación fotométrica con una prioridad estándar de 0.5. El
nuevo valor del elemento DICOM se calcula en la variable XSL
"nueva interpretación fotométrica", dependiendo de su valor
inicial.

Comunicación de objetos DICOM

Además del intercambio de objetos DICOM a través de una red,
cada vez es más común usar CD o discos de video digital (DVD)
como medio de distribución fuera de línea. Para garantizar un
intercambio confiable de dichos medios, IHE ha definido el perfil
de integración de datos portátiles para imágenes (PDI) (6). Dos
ejemplos de dicha aplicación de nuestro software se describen en
esta sección.

Figura 12 La pantalla de un navegador web muestra el contenido web

Ejemplo de exportación de medios. —DICOM parte 12 (1) define
los formatos de medios de intercambio, especialmente el formato
de un DICOMCD. El perfil de integración PDI expande esta
definición a un formato que incluye tanto el contenido DICOM como
el contenido web. El contenido web está escrito en un directorio
separado en el nivel raíz y contiene archivos extensibles HTML
(XHTML) (15) que hacen referencia a representaciones JPEG
(Joint Photographic Experts Group) de las imágenes DICOM.
de un CD. El contenido web fue creado en el formato IHE PDI por
PortableMediaCreatorPlugin.
A través de este medio, los usuarios y pacientes pueden acceder a las
imágenes con un navegador web.
Solución. —La creación de una estructura de archivos PDI
conforme se realiza mediante PortableMediaCreatorPlugin. El
complemento en sí solo escribe los archivos XHTML. Para escribir
el contenido DICOM y los archivos JPEG, el complemento llama a
SaveDicomdirPlugin y ExportImagePlugin. En figura
 RG F Volumen 25 ● ● Número 6
RadioGraphics
11, la estructura de archivo resultante se da para una imagen. Los
diferentes archivos INDEX.HTM permiten al usuario navegar por enlaces
HTML a través de listas de estudio y series hasta la lista de imágenes de
una serie (Fig. 12).
Ejemplo de importación de medios. —Un número creciente de
pacientes tienen sus exámenes previos guardados en CD. Para
permitir la comparación de los exámenes actuales y anteriores, es
deseable copiar imágenes del examen anterior en el PACS.
Solución. —En un nivel abstracto, IHE describe la importación de
dichos CD utilizando un actor Importador de medios portátiles. Lee los
datos DICOM del CDmedia, que deben organizarse de acuerdo con
DICOM parte 12 (1). Además de eso, debe realizar la conciliación de
los atributos clave. Para eso, los atributos Nombre del paciente, ID del
paciente, Fecha de nacimiento del paciente y Sexo del paciente
deben reemplazarse por sus valores en el PACS receptor. Los
atributos de identificación relacionados con el flujo de trabajo, como
los UID, no cambian, se eliminan o se reemplazan por los valores de
PACS, dependiendo del flujo de trabajo de la institución importadora.
Como las imágenes DICOM se almacenan con PDI conforme en el
CD, contiene imágenes de un solo paciente. Como se muestra en la
Figura 13, el File Receiver lee consecutivamente todos los archivos
DICOM del sistema de archivos del CD y los envía a la tubería de
procesamiento. Antes de que las imágenes se envíen al archivo,
TagModifyPlugin modifica cuatro elementos DICOM. Los nuevos
valores de los elementos se dan como propiedades del complemento
mediante el archivo de configuración.
Hackla¨nder et al 1719
Figura 13 Uso del DICOMRouter como
actor IHE compatible con el Importador
de medios portátiles. Las imágenes
DICOM se almacenan en un PDI
DISCOS COMPACTOS. Debido a que un
CD contiene imágenes de un solo
paciente, File Receiver lee
consecutivamente todos los archivos
DICOM del sistema de archivos del CD y
los envía a la tubería de procesamiento.
Antes de enviar las imágenes al archivo,
TagModifyPlugin modifica cuatro
elementos DICOM. Los nuevos valores
de los elementos se dan como
propiedades del complemento. DVD disco
de video digital.
Discusión
Implementación de software
Una parte crítica de cada aplicación DICOM es su conformidad con el
estándar DICOM, que debe verificarse nuevamente para cada ejemplo.
Para evitar este problema, la aplicación puede usar una biblioteca bien
probada para todos los accesos DICOM. Además de los productos
comerciales, algunas bibliotecas de código abierto gratuitas están
disponibles para este propósito (16). El enrutador DICOM utiliza la
biblioteca dcm4che, que es gratuita. En comparación con otras
implementaciones, es la única que se implementa en Java puro y tiene
un equipo de desarrollo abierto. Se ha probado muchas veces en el
contexto IHE y cumple 10 de 15 perfiles de integración IHE (17).
Más allá de las cajas de herramientas DICOM de bajo nivel,
algunos proveedores ofrecen componentes de software que realizan
funciones especializadas, como pseudonaming (18) o conversión a
varios formatos gráficos (19). Solo unos pocos paquetes
comerciales permiten al usuario adaptar la funcionalidad a las
necesidades específicas (20). Un enfoque de código abierto para
eso es el proyecto DIFAF (21). Permite la modificación de objetos
DICOM por medio de un conjunto predefinido de subprogramas
escritos en Java. Por lo tanto, el enfoque de DIFAF es comparable al
del DICOMRouter. El problema más importante con DIFAF es el uso
de la biblioteca OFFIS (Oldenburger Forschungs- und
Entwicklungsinstitut fu¨r Informatik-Werkzeuge und -Systeme) para
accesos DICOM de bajo nivel (22). Como este paquete se
implementa en C
, DIFAF tiene que dar cuenta
 1720 noviembre-diciembre 2005
varias interfaces entre Java y C . Ser-
debido a su uso de la biblioteca OFFIS, la aplicación completa no
es compatible con binarios con varios sistemas operativos,
mientras que el enrutador DICOM sí lo es. Además, las interfaces
de programación de los subprogramas y el mecanismo de
RadioGraphics
registro se realizan rudimentariamente en DIFAF.
La implementación como un proyecto de código abierto y las
interfaces de programación abiertas ofrecen la posibilidad de resolver
incluso otros casos de uso además de los ya mencionados.
Modificación de objetos DICOM
El diseño del marco permite la aplicación lineal de pasos de
procesamiento para cada imagen. Sin embargo, hay algunos
escenarios en los que es necesario el procesamiento de más de una
imagen. Por ejemplo, algunas estaciones de visualización clasifican las
imágenes en el orden en que fueron recibidas. Esto da como resultado
un orden de visualización no válido. En este escenario, el marco podría
recopilar todas las imágenes y ordenarlas de acuerdo con los campos
DICOM Posición de imagen y Orientación de imagen. Otro escenario es
la aplicación automatizada de reforma multiplanar (MPR) y proyección
de máxima intensidad (MIP). Para algunos exámenes de CT, tiene
sentido crear automáticamente una nueva secuencia con una nueva
orientación antes de que las imágenes se envíen a una estación de
visualización. En escenarios de teleradiología, tiene sentido reducir el
número de imágenes mediante la aplicación de MIP.
Los complementos ya implementados cubren una gran parte de
los posibles casos de uso. Esto se debe a la posibilidad de unirlos en
el orden deseado y de adaptar la función individual editando un
archivo de configuración. Un inconveniente es que no es posible
cambiar el comportamiento de la cola de procesamiento mediante
decisiones lógicas. Además, no es posible modificar el contenido de
un elemento DICOM con una combinación de dos o más elementos.
Para obtener tal resultado, uno tiene que desarrollar un nuevo
complemento. Para evitar esto, se podría usar XSLTransformPlugin.
Aunque no agrega ninguna funcionalidad nueva al enrutador DICOM
por sí mismo, permite al usuario implementar nuevas funciones
editando un archivo de texto conforme a XSL. Como el procesador
XSL utilizado por el proyecto permite el uso del modelo de datos
XPath, El usuario puede seleccionar y combinar nodos XML
utilizando expresiones similares a las de los lenguajes de
programación tradicionales. De esta manera, incluso los cálculos
complejos son posibles.
RG F Volumen 25 ● ● Número 6
Confidencialidad de la identificación del
paciente en teleradiología
Los sistemas de teleradiología deben proporcionar protocolos de
seguridad de red y software para proteger la confidencialidad de la
identificación del paciente y los datos de imágenes, de acuerdo con los
requisitos legales federales y estatales. Debería haber medidas para
salvaguardar los datos y garantizar la integridad de los datos mediante la
protección contra la corrupción intencional o no intencional de datos (23).
En particular, los datos deben transmitirse solo a través de
canales seguros al destinatario destinado (24). En nuestra aplicación,
esto se realiza mediante el uso de la transmisión Secure Socket Layer
(SSL) hasta el primer cliente del hospital remoto. Sin embargo, no fue
posible garantizar que solo los usuarios autorizados pudieran acceder
a esta computadora cliente. Este hecho llevó a la decisión de utilizar
un proceso de seudonimización para todas las imágenes enviadas al
hospital remoto. Con el DICOMRouter, esta precaución requiere solo
un proceso de copia adicional para cada examen. El retraso de
menos de 1 minuto para un examen de CT típico de la cabeza es
insignificante en comparación con todo el proceso de diagnóstico.
Para aplicaciones que simplemente requieren conexiones de igual a
igual entre dos nodos PACS, es posible una interconexión a través de dos
enrutadores DICOM. Para esto, la conexión entre los enrutadores ya se
realiza mediante el perfil de conexión de transporte seguro implementado
por la biblioteca dcm4che. Si los cortafuegos protegen los dos PACS,
ambos deben configurarse de tal manera que se permita una conexión
entre los enrutadores. Este problema se puede resolver si se utiliza una
comunicación de correo electrónico DICOM (24) (suplemento 54) en lugar
de una conexión directa (25). Sin embargo, esto no es posible con el
conjunto existente de complementos. Se requiere un complemento de
receptor de correo electrónico adicional y un complemento de remitente de
correo electrónico.
Comunicación de objetos DICOM
La exportación de exámenes de pacientes en el formato IHE PDI
permite a los pacientes y a otros médicos ver los exámenes sin la
necesidad de hardware y software especializado. Debido a que el
CD usa el formato HTML, pueden ver las imágenes en cada
plataforma de computadora que deseen usar. En el pasado, esto a
menudo era un problema grave, incluso si el software de
visualización DICOM se incluía en los CD de los pacientes. Otra
posible aplicación para el CD PDI es construir un archivo especial
con fines educativos. Para proteger la privacidad de los pacientes
en este caso, los complementos que se muestran en la Figura 6
deben aplicarse antes de llamar a PortableMediaCreatorPlugin.
 RG F Volumen 25 ● ● Número 6
Al usar SaveFilesystemPlugin, el DICOMRouter puede
exportar objetos DICOM al sistema de archivos local de la
computadora donde se está ejecutando el enrutador. Esto
permite que otro software procese dichos objetos, incluso si el
software no puede procesar la comunicación DICOM.
RadioGraphics
Cuando las imágenes se importan a un PACS, se deben
considerar dos aspectos. Para garantizar la integridad de los PACS,
el proceso de importación de imágenes externas requiere la
verificación de su conformidad con el estándar DICOM. Dentro del
enrutador DICOM, el proceso de decodificación dentro del receptor
garantiza la conformidad y comprueba la sintaxis de la imagen
mientras la convierte en una estructura de datos abstractos para su
posterior procesamiento. En caso de errores de decodificación, las
imágenes no se colocan en la cola de procesamiento. Por lo tanto, el
PACS está protegido contra la importación de estas imágenes
incorrectas. El segundo punto es garantizar la integridad lógica de los
PACS. Para eso, las imágenes importadas deben asignarse al
paciente correcto en el PACS. Esto se realiza mediante la
implementación de un actor Importador de medios portátiles. Sin
embargo, la implementación actual tiene un inconveniente: Para cada
CD que deba importarse, el archivo de configuración del
DICOMRouter debe modificarse para reflejar la información correcta
del paciente. Para el futuro, se planea actualizar el front-end de tal
manera que la información necesaria se pueda editar en campos de
texto de la interfaz gráfica de usuario.
Expresiones de gratitud: Agradecemos a Heinrich Mertens, PhD, por
su apoyo y a James H. Caldwell, MD, por su crítica crítica.
Referencias
1. Asociación Nacional de Fabricantes Eléctricos (NEMA).
Publicación de normas PS 3, Imágenes digitales y
comunicaciones en medicina (DICOM).
http://medical.nema.org/dicom/
2004.html. Consultado el 5 de julio de 2005.
2. Horii SC. Manual sobre informática y tecnología de la
información. IV. Una introducción no técnica a DICOM.
RadioGraphics 1997; 17: 1297–1309.
3. Bidgood WD Jr, Horii SC, Prior FW, Van Syckle DE. Comprender
y utilizar DICOM, el estándar de intercambio de datos para
imágenes biomédicas. J AmMed Inform Assoc 1997; 4 (3):
199–212.
4. Health Level Seven, Inc. Health Level Seven (HL7).
http://www.hl7.org/Library/standards_non1.htm. Consultado el 5 de
julio de 2005.
5. Dolin RH, Alschuler L, Beebe C, y col. La arquitectura del
documento clínico HL7. J AmMed Inform Assoc 2001; 8 (6):
552–569.
6. Integración de la empresa sanitaria (IHE). http://www.ihe.net.
Consultado el 5 de julio de 2005.
7. Siegel EL, Channin DS. La integración de la empresa de salud:
una introducción. I. Introducción. Radiografía 2001; 21:
1339-1341.
Hackla¨nder et al 1721
8. Zeilinger G. dcm4che: una implementación de DI-COM en Java.
Versión 1.1.4. http: // sourceforge
. net / projects / dcm4che /. Consultado el 5 de julio de 2005.
9. Consorcio WorldWideWeb. Familia de lenguaje de hoja de estilo extensible
(XSL). http://www.w3.org/Style/ XSL /. Consultado el 5 de julio de 2005.
10. Consorcio de la World Wide Web. Lenguaje de marcado extensible
(XML). http://www.w3.org/XML/. Accedido el 5 de julio de 2005.
11. Wang C, Kahn CE Jr. Uso potencial del lenguaje de marcado
extensible para informes de radiología: un tutorial. RadioGraphics
2000; 20: 287–293.
12. El proyecto Apache Jakarta. Proyecto Log4j. http: //
jakarta.apache.org/log4j/docs/index.html. Accedido el 5 de julio de
2005.
13. Hackla¨nder T, Heupel R, Kleber K. Dicom-Router. Versión
2.2.10. http://sourceforge.net/ projects / dcmrouter /.
Consultado el 5 de julio de 2005.
14. Hackla¨nder T, Kleber K, Schneider H, Demabre
N, Cramer BM. Entwicklung einer sicheren und
kostengu¨nstigen intrastruktur zum zugriff auf be-liebige
Web-basierte bildverteilungssysteme. Rofo 2004; 176:
1167–1174.
15. Consorcio de la World Wide Web. El lenguaje de marcado de hipertexto
extensible (2Ed): una reformulación de HTML 4 en XML 1.0.
http://www.w3.org/TR/ xhtml1. Consultado el 5 de julio de 2005.
16. Sociedad Radiológica de América del Norte. Recursos DICOM en
Internet. http://www.rsna.org/ practice / dicom / dicom.html.
Consultado el 5 de julio de
2005
17. Resultados de IHE Europe Connectathon 2005. http: //
www.ihe-europe.org/con_result. Consultado el 5 de julio de
2005
18. NeoLogica. DICOMAnonymizer. http: // eng.
neologica.it/download/downloadDICOMAnony- mizer.html.
Consultado el 5 de julio de 2005.
19. Crabb A. Software gratuito de imágenes médicas. http: //
www.idoimaging.com/index.shtml. Acceso en julio
5 de 2005.
20. Fusionar eFilm. MergeCOM-3 Advanced Integrators Toolkit.
http://www.merge.com/products/ developmenttools / toolkits.asp.
Consultado el 5 de julio de
2005
21. Hackla¨nder T, Schmidt A, Sto¨ckel A. Teleradiología basada en la
web u¨ber das Internet: entwicklung eines sistemas bajo
besonderer beru¨cksichtigung des datenschutzes [resumen].
Rofo 2000; 172: S130.
22. KuratoriumOFFIS. DCMTK: DICOM-Toolkit. http: //dicom.of fi
s.de/dcmtk.php.en. Consultado el 22 de febrero de 2005.
23. Colegio Americano de Radiología. Norma técnica ACR para
teleradiología. http: //www.acr
. org / s_acr / bin.asp? TrackID y SID 1 y DID 12292 y CID 541 y VID 2
y DOC File.PDF. Consultado el 5 de julio de 2005.
24. Clunie DA. Suplementos DICOM por número.
http://www.dclunie.com/dicom-status/status. html #
SupplementsByNumber. Consultado en febrero
22 de 2005.
25. Weisser G, Walz M, Koester C, Dinter D, Duber
C. Nuevos conceptos en teleradiología con el correo electrónico de
Dicom [en alemán]. Biomed Tech (Berl) 2002; 47 (supl 1 pt 1):
356–359.