• No se han encontrado resultados

Generador de Archivos DICOM

N/A
N/A
Protected

Academic year: 2021

Share "Generador de Archivos DICOM"

Copied!
26
0
0

Texto completo

(1)

Para el proyecto de construcción de un prototipo de una máquina portable 

para la detección del Mal de Chagas en muestras de sangre.

INFORMÁTICA MÉDICA

(2)

INFORMACIÓN GENERAL Fecha: Junio del 2011 Tema: Generador de Archivos DICOM Materia: Informática Médica Carrera: Ingeniería de Sistemas Universidad: Universidad Nacional del Centro de la Provincia de Bs. As. Docentes: A cargo de: Dra. Mariana del Fresno, Mag. Ing. José María Massa, Bioing. Pedro Escobar Trabajos Prácticos: Emanuel Arguiñarena, Bárbara Rodeker Autor: APU Luján Emmanuel Email: info@emmanuellujan.com.ar  Web: www.emmanuellujan.com.ar ÍNDICE Índice de contenido INFORMACIÓN GENERAL...2 ÍNDICE...2 Índice de contenido...2 Índice de figuras...3 Índice de tablas...3 1. REQUERIMIENTOS...4 1.1. Descripción general...4 1.1.1.  Mal de Chagas...4 1.1.2. Descripción general del proyecto...4 1.2. Objetivo...5 2. ANÁLISIS Y DISEÑO...6 2.1. Algoritmo de detección...6 2.2. Prototipo FPGA...7 2.2.1. Capacidades de la plataforma...7 2.2.2. Flujo de trabajo y formato de la información...8 2.2.3. dat2xml y formato DICOM...11 2.2.3.1. DICOM ...12 2.2.3.2. Formato DICOM ...12 2.2.3.3. Completar datos...15 2.2.3.4. DICOM XML...18 2.3. Prototipo PC...20 4. INSTALACIÓN Y PRUEBA...21

(3)

4.1. Instalación...21 4.2. Prueba...21 5. ANEXO: Envío a un PACS...22 5.1. Instalación del servidor PACS...22 5.2. Envío al servidor PACS...22 6. CONCLUSIÓN...25 7. BIBLIOGRAFÍA...25 Índice de figuras Fig. 1.2.1. ­ Prototipo en PC con microscopio y cámara de video...5 Fig. 2.1.1. ­ Muestra de sangre de un ratón con muchos parásito...6 Fig. 2.1.2. – Porta­objetos y cubre­objetos...7 Fig. 2.2.2.1. ­ Estructura de directorios. Datos de salida de la máquina...8 Fig. 2.2.2.2. ­ Contenido del archivo con información de las imágenes...9 Fig. 2.2.2.3. ­ Contenido de los archivos de diagnóstico...9 Fig. 2.2.2.4. ­ Imagen resultante del análisis de un campo...9 Fig. 2.2.2.5. ­ Estructura de directorios intermedia...10 Fig. 2.2.2.6. ­ Estructura final de directorios. Datos de salida de la PC...11 Fig. 2.2.2.7. ­ Diagrama de actividades, prototipo FPGA...11 Fig. 2.2.3.2.1. ­ Estructura básica de un archivo DICOM...13 Fig. 2.2.3.2.2. ­ Estudio del mundo real llevado al modelo de información...14 Fig. 2.3.1. ­ Estructura de directorios. Datos de entrada...20 Fig. 2.3.2. ­ Transferencia de datos desde Máquina a PC, de forma simulada...21 Índice de tablas Tabla 2.2.3.3.1. ­ Tabla de Meta Información...17 Tabla 2.2.3.3.2. ­ Tabla del Conjunto de Datos...18 Tabla 2.2.3.3.3. ­ Tabla de un Módulo del Conjunto de Datos...18

(4)

1. REQUERIMIENTOS

En la siguiente sección se detallará una descripción general del proyecto y el  objetivos pretendido.

1.1. Descripción general 1.1.1.  Mal de Chagas

La   enfermedad   de   Chagas   es   una   enfermedad   causada   por   el   parásito  Trypanosoma cruzi  (T. cruzi), que entra en el cuerpo a través de la piel lesionada y las  membranas mucosas, y causa síntomas agudos, que suelen ser leves, como fiebre,  inflamación de los ganglios linfáticos y los tejidos, conjuntivitis y lesiones en la piel.  En las zonas rurales pobres de América del Sur y Central, donde la enfermedad es  endémica y los centros de salud son insuficientes, estos síntomas son en gran medida  desatendidos.   Sin   tratamiento,   la   infección   aguda   remite   espontáneamente   en   la  mayoría   de   los   pacientes,   sin   embargo,   la   infección   crónica   puede   persistir  desapercibida por más de 30 años antes de causar complicaciones tales como ritmo  cardíaco anormal, insuficiencia cardíaca, problemas digestivos y la muerte cardiaca  repentina. Aproximadamente uno de cada tres portadores desarrollan estos síntomas  crónicos.  El médico brasileño Carlos Chagas identificó  T. cruzi como agente causal de la  enfermedad en 1909, y posteriormente se determinó sus manifestaciones clínicas, la  epidemiología   y   ciclo   de   vida   de   los   vectores,   reservorios   silvestres   y   el   huésped  humano. Controversialmente, Chagas nunca recibió un premio Nobel, a pesar de ser  nominado en dos ocasiones. [1] 1.1.2. Descripción general del proyecto El siguiente trabajo se realiza como parte del siguiente proyecto: Construcción del prototipo de una máquina capaz de detectar la enfermedad del  Mal de Chagas en muestras de sangre. La máquina debe ser portable para poder ser  llevada a lugares recónditos, dónde sea difícil que la gente pueda acceder a un centro  de salud.  La máquina se pretende implementar en base a una placa FPGA. Dicha placa  controlará un dispositivo óptico (un microscopio o un interferómetro) que, en conjunto  con un dispositivo mecánico, tomará imágenes de las muestras de sangre en forma de  barrido. Dichas muestras serán analizadas para detectar la presencia del parásito T. 

(5)

cruzi. La detección ser hará en base al movimiento del parásito. Además se debe  contar con un soporte físico para albergar y preservar los componentes, mantener las  condiciones de luz, etc.  Para facilitar las pruebas se implementará también un prototipo en PC. Fig. 1.2.1. ­ Prototipo en PC con microscopio y cámara de video. El procedimiento que se espera realizar con la máquina es el siguiente: un  técnico   visitará   al   paciente,   tomará   una   muestra   de   sangre,   la   colocará   en   un  portaobjetos y luego dentro de la máquina. Ésta hará el análisis pertinente y luego  arrojará por medio de una pantalla simple el identificador del estudio realizado y el  diagnóstico obtenido.  Al paciente se le notificará en ese momento si debe o no dirigirse  a un centro de salud para el tratamiento de la enfermedad o bien, si el diagnóstico es  inconcluso, para hacerse un análisis más riguroso. Por otro lado el identificador será  anotado en una planilla de papel junto con los datos del paciente. Finalizada la ronda de visitas el técnico retornará a su lugar de trabajo en  donde conectará la máquina a una PC, para transferir la información de los estudios.  La   información   será   convertida   mediante   un   software   a   formato   DICOM,   y   será  asociada a los datos del paciente. Los archivos DICOM, luego, serán transmitidos a un  servidor para centralizar la información.

[2]

1.2. Objetivo

El objetivo para este proyecto en particular es: proveer una solución al problema  de  convertir   la  información   de   los   estudios  realizados   por   la  máquina  en   formato  DICOM.

(6)

2. ANÁLISIS Y DISEÑO En la siguiente sección se detallará el análisis y diseño concerniente al objetivo  planteado. Se explicará brevemente el algoritmo de detección usado. Luego los dos  prototipos planteados: FPGA y PC, con el formato de la información y el flujo de  trabajo asociado a cada uno. 2.1. Algoritmo de detección Se usará un algoritmo preparado para bajas concentraciones de parásitos, que  permite detectar la presencia del mismo en etapas tempranas de la enfermedad. En la actualidad se usa un método visual.   Una muestra de sangre fresca es  situada bajo un microscopio de con una magnificación de 400X, la cual es adecuada  para distinguir visualmente el movimiento de los parásitos contra un fondo de glóbulos  rojos casi estáticos. Los glóbulos rojos tienen un diámetro de aproximadamente 4 µm,  mientras que un T. cruzi es un organismo flagelado de aproximadamente 10  µm de  largo. Las muestras están compuestas por campos. Típicamente en un campo hay sólo  un parásito en movimiento, pero debido a que éste afecta el movimiento de los glóbulos  rojos   circundantes   facilita   su   detección.   El   campo   es   un   área   de   1.59   x   105  µm2  (posiblemente haya un error en [4] y este dato y sea 1.59 x 103 µm2). Un técnico cuenta  el   número   de   parásitos   en   100   campos.   Tarda   habitualmente   15   minutos.   Si   la  concentración de parásitos es baja, por ejemplo 0.2 parásitos cada 100 campos, se  necesitan muchos más campos para ser analizados. Fig. 2.1.1. ­ Muestra de sangre de un  ratón con muchos parásito. Caso poco  común. Infección en un ratón  inmunodeprimido. [3] En una propuesta de un método automatizado se escanean los campos de la  muestra moviendo el portaobjetos de manera mecánica. Por cada campo se toman 8  imágenes a 25 frames por segundo. Se substraen las imágenes de a pares y se suman  las resultantes. Luego se aplica un filtro de convolución para mejorar el contraste. A  continuación se binariza la imagen y se hace una dilatación. Y por último se mide el  nivel   de   gris   promedio   de   la   imagen   para   diagnosticar   si   se   sospecha   que   hay 

(7)

parásitos. El área total del cubreobjetos es de aproximadamente 2700 campos.  [4] Fig. 2.1.2. – Porta­objetos y cubre­objetos: Izquierda arriba: portaobjetos en el que se  dispone la muestra. Izquierda abajo: cubreobjetos que se emplea para cubrir la muestra   [5]. Derecha: portaobjetos con muestra de sangre. 2.2. Prototipo FPGA 2.2.1. Capacidades de la plataforma Una placa FPGA (del inglés Field Programmable Gate Array) es un dispositivo  semiconductor   que   contiene   bloques   de   lógica   cuya   interconexión   y   funcionalidad  puede ser configurada 'in situ' mediante un lenguaje de programación especializado.  La   lógica   programable   puede   reproducir   desde   funciones   tan   sencillas   como   las  llevadas a cabo por una puerta lógica o un sistema combinacional hasta complejos  sistemas en un chip.

Las FPGAs se utilizan en aplicaciones similares a los ASICs sin embargo son  más lentas, tienen un mayor consumo de potencia y no pueden abarcar sistemas tan  complejos   como   ellos.   A   pesar   de   esto,   las   FPGAs   tienen   las   ventajas   de   ser  reprogramables (lo que añade una enorme flexibilidad al flujo de diseño), sus costes de  desarrollo y adquisición son mucho menores para pequeñas cantidades de dispositivos  y el tiempo de desarrollo es también menor. Ciertos fabricantes cuentan con FPGAs que sólo se pueden programar una vez,  por lo que sus ventajas e inconvenientes se encuentran a medio camino entre los  ASICs y las FPGAs reprogramables.

Históricamente   las   FPGA   surgen   como   una   evolución   de   los   conceptos  desarrollados en las PAL y los CPLD.

(8)

La   placa   FPGA   que   se   usa   para   el   prototipo   está   programada   con   una  plataforma que permite:

• Entrada de datos: controla una cámara de video conectada a la misma. La 

cámara   a   su   vez   está   conectada   a   un   dispositivo   óptico   (microscopio   o  interferómetro) que toma las imágenes de las muestras de sangre.

• Procesamiento:   se   pueden   ingresar   programas   hechos   en   una   variación   del 

lenguaje C adaptado a dicha plataforma.

• Salida   de   datos:   se   está   desarrollado   la   funcionalidad   de   escritura   a   una 

memoria compact flash. • Entrada/Salida de datos: se está desarrollado la dicha funcionalidad mediante  TPC/IP, utilizando sockets. [6] 2.2.2. Flujo de trabajo y formato de la información La máquina toma como entrada una muestra de sangre. La muestra se divide  en campos. De 100 o más campos se toman 8 imágenes por cada uno. Los píxeles que  conforman las imágenes se almacenan en una memoria. El algoritmo procesa dichas  imágenes y genera una salida. Esta información es almacenada en un estudio. La  máquina almacena varios estudios.  La información de salida de la máquina se define en base a una estructura de  directorios y archivos. Se tendrá un directorio principal  studies, el mismo posee la  siguiente forma: Fig. 2.2.2.1. ­ Estructura de directorios. Datos de salida de la máquina. studies/ images_info.txt study_00001/ general_diagnosis.txt fields/ field_00001/ diagnosis.txt field.pix field_00002/ diagnosis.txt field.pix ...

(9)

Dentro del directorio studies se encuentra:

• El archivo  images_info.txt  que tiene información acerca de las imágenes que 

están contenidas en los estudios. Fig. 2.2.2.2. ­ Contenido del archivo con información de las imágenes. • Todos los estudios almacenados. Cada uno tendrá un identificador único.  A su vez, dentro de cada estudio podemos encontrar los siguientes elementos: • Archivos de diagnóstico: varios diagnósticos parciales, uno por cada campo; y un  diagnóstico general. Fig. 2.2.2.3. ­ Contenido de los archivos de diagnóstico.

• También   se   almacenan   las   imágenes   relativas   a   cada   campo,   incluyendo   la 

imagen resultante: aquella que marca los puntos o zonas en donde se detectó  movimiento en ese campo,  Fig. 2.2.2.4..  La información de las imágenes está 

representada   por   los   archivos   field.pix.   Como  se   verá   más  adelante   esto   es  necesario para los pasos realizados sobre la PC. Fig. 2.2.2.4. ­ Imagen resultante del análisis de un campo. width:250 height:250 bits/pixel:1 Diagnosis: presence  of Trypanosoma  cruzi is suspected in  blood sample. Diagnosis: presence of  Trypanosoma cruzi is  not suspected in blood  sample.

(10)

Se acaba de mostrar como se componen los datos de salida de la máquina, que  son los datos de entrada de la PC. Dichos datos deben ser transformados en formato  DICOM. Se construirá un software que sea capaz de aceptar la entrada de datos  explicada y generar como salida una estructura de directorios cuyo contenido sean  archivos DICOM.  Para hacer esto se usará DCM4CHEE, que es una colección de aplicaciones y  utilidades Open Source provistas para empresas de salud. Estas aplicaciones han sido  desarrolladas  en   el  lenguaje  de   programación   Java   por   motivos   de  performance   y  portabilidad. 

[7] Particularmente se usará la aplicación xml2dcm. Esta aplicación transforma un  archivo XML en un archivo DICOM. Esto implica que se produce la necesidad de  generar   una   estructura   de   datos   intermedios   ya   que   la   salida   de   la   máquina   es  genérica: diagnósticos almacenados como archivos de texto y las imágenes como una  secuencia de píxeles.

Se creará entonces una aplicación dat2xml, también en Java, que toma la salida  de la máquina, Fig. 2.2.2.1., y la transforma en la siguiente estructura de directorios:

Fig. 2.2.2.5. ­ Estructura de directorios intermedia.

Luego   esta   información   es   transformada   otra   vez.   Se   creará   una   aplicación  xml2dcm, nuevamente en Java, que usará la aplicación con el mismo nombre de las  provistas por DCM4CHEE, para generar la estructura de directorios basada en el  formato DICOM: studies/ study_0001/ general_diagnosis.txt fields/ field_00001/ field.xml field.pix field_00002/ field.xml field.pix

(11)

Fig. 2.2.2.6. ­ Estructura final de directorios. Datos de salida de la PC.

El   siguiente   diagrama   de   actividades   muestra   de   forma   resumida   lo   antes   explicado: Fig. 2.2.2.7. ­ Diagrama de actividades, prototipo FPGA. 2.2.3. dat2xml y formato DICOM Como se dijo, esta aplicación tomará como entrada la salida de la máquina y la  transformará a un estado intermedio, compatible con el formato de entrada de la  aplicación xml2dcm de DCM4CHEE.

Para   lograr   construir   dicha   aplicación   se   debe   tener   un   cierto   grado   de  conocimiento en DICOM y su formato.  studies/ study_00001/ general_diagnosis.txt fields/ field_00001/ field.dcm field_00002/ field.dcm

(12)

2.2.3.1. DICOM 

DICOM   (Digital   Imaging   and   Communication   in   Medicine)   es   el   estándar  reconocido mundialmente para el intercambio de imágenes médicas, pensado para el  manejo, almacenamiento, impresión y transmisión de imágenes médicas. Incluye la  definición de un formato de fichero y de un protocolo de comunicación de red. El  protocolo   de   comunicación   es   un   protocolo   de   aplicación   que   usa   TCP/IP   para   la  comunicación entre sistemas. Los ficheros DICOM pueden intercambiarse entre dos  entidades que tengan capacidad de recibir imágenes y datos de pacientes en formato  DICOM.

DICOM permite la integración de escáneres, servidores, estaciones de trabajo,  impresoras   y   hardware   de   red   de   múltiples   proveedores   dentro   de   un   sistema   de  almacenamiento y comunicación de imágenes. Las diferentes máquinas, servidores y  estaciones de trabajo tienen una declaración de conformidad DICOM (conformance  statements) que establece claramente las clases DICOM que soportan. DICOM ha sido  adoptado ampliamente por centros de salud. [5] 2.2.3.2. Formato DICOM 

Los   archivos   DICOM   contienen   una   parte   llamada   Meta   Información   del  Archivo, la cuál contiene un Preámbulo de 128 bytes (el preámbulo debe contener  todos ceros si no es usado, algunas veces las aplicaciones lo usan para sus datos  propietarios.). Un prefijo: “DICM”, en mayúsculas. Y un conjunto de Meta Elementos  (ver tabla Tabla 7.1­1 del estándar DICOM). Seguido a esto tienen una parte llamada  Conjunto de Datos, que representa una sola Instancia SOP, asociada a una sola Clase  SOP  (y su correspondiente IOD) [8],[9]

• IOD:   Information   Object   Definition   (Definición   de   objeto   de   información) 

Permite   representar   entidades   (objetos   del   mundo   real)   que   comparten   las  mismas propiedades. Cada propiedad distinta en una entidad recibe el nombre  de atributo.  • SOP Class: Service­Object Pair (Par Servicio­Objeto) . Es la unión de un IOD  con el grupo de servicios que le corresponde. Existe un grupo de servicios para  cada IOD. (Ver DIMSE, en el estándar DICOM).  • Service Class (Clase de Servicio): Define un grupo de una o más Clases SOP con 

una   función   específica.   Pueden   ser   funciones   relacionadas   con   el  almacenamiento remoto de imágenes (Storage Service Class) o con la búsqueda  de   un   objeto   (Object   Query/Retrieve  Service  Class)   o  cualquier  otro   tipo   de  servicio. 

(13)

Fig. 2.2.3.2.1. ­ Estructura básica de un archivo DICOM. Tanto los Meta Elementos como el Conjunto de Datos siguen un formato de  tags. Cada tag representa un Elemento de Datos. La Meta Información  contiene información acerca del archivo, de las series, del  estudio y del paciente al que pertenece. Esta información es frecuentemente parseada  y usada como índice de datos por un PACS y el sistema de archivos.  PACS son las siglas de Picture Archiving and Communication System (Sistema  de Archivado y Transmisión de Imágenes). Se trata de un sistema computarizado para  el archivado digital de imágenes médicas (medicina nuclear, tomografía computada,  ecografía, mamografía...) y para la transmisión de estas a estaciones de visualización  dedicadas o entre estas a través de una red informática. En el modelo DICOM, un paciente puede tener 1..n estudios (algunas veces  referidos como exámenes o procedimientos). Cada estudio consiste en 1..n series. Una  serie generalmente equivale a un tipo específico de datos, o la posición de un paciente  sobre el dispositivo que se usa para hacer el estudio. Cada serie contiene 1..n instancias de objetos DICOM (comúnmente imágenes,  pero también reportes, objetos de formas de onda, etc.). Toda esta información está  contenida en cada objeto de un estudio DICOM. Además, si un estudio es realizado  sobre   un   paciente,   conteniendo   2   series,   cada   una   con   10   instancias,   todas   las  instancias contendrán la información del paciente y estudio es su encabezado.  Las  instancias también contendrán información sobre la serie en que se encuentran, así 

Meta Información del Archivo

Conjunto de Datos Preámbulo

Prefijo

(14)

Fig. 2.2.3.2.2. ­ Estudio del mundo real llevado al modelo de información.

Asociando la figura de arriba con el contexto del proyecto actual, la modalidad  está asociada al tipo de imágenes que se van a usar, en este caso Microscopía General  (GM).   Se   sabe   que   un   paciente   puede   tener   varios   estudios.   Cada   estudio   está  conformado por un conjunto de campos los cuales se asocian a series. Y cada campo  está conformado por un conjunto de imágenes, las cuales se asocian a las imágenes de  cada serie. Los Elementos de Datos están formados por un identificador llamado Tag, un  tipo de datos llamado VR, una longitud en bytes llamada Longitud del Valor, y el Valor  del elemento propiamente dicho. Fig. 2.2.3.2.3. ­ Conjunto y Elemento de Datos. [12]

Los   Elementos   de   Datos   pueden   también   estar   anidados,   conteniendo   sus  propios Elementos de Datos. Esto es llamado secuencia. Además, es posible crear  tags  privados. Generalmente no son reconocidos por las aplicaciones. Los tags privados son 

(15)

útiles   cuando   se   quiere   incluir   una   información   no   definida   dentro   del   estándar  DICOM. En este proyecto no serán necesarios dichos tags.

[11]

2.2.3.3. Completar datos

El   siguiente   paso   es   conocer   como   completar   los   archivos   DICOM   que   se  pretenden crear. Para ello se hará uso de dos tablas extraídas del estándar DICOM. La  primera   es   la  Tabla  2.2.3.3.1.  que   define   la   información   que   debe   ir   en   la   Meta 

Información del Archivo. La segunda es la Tabla 2.2.3.3.2. que define la información 

que debe ir  en   el  Conjunto  de Datos.  La primer   tabla es  para  todos los  archivos  DICOM la misma, no solo para este proyecto sino en general. En cambio la segunda  está relacionada con el tipo de información que se desea guardar. El estándar propone  muchas tablas con diferentes temáticas. En el caso de este proyecto se desea guardar  información concerniente a microscopía. La  Tabla 2.2.3.3.2.  es la  Tabla A.32.6­1  del 

Estándar DICOM, y especifica los Módulos del IOD de Imágen Microscopica de Video. Antes de presentar las tablas mencionadas se explicará como se deben leer. La  primer tabla muestra un conjunto de Elementos de Datos. De cada uno se muestra su  nombre,   su   tag,   su   tipo   (no   VR)   y   una   descripción.   El   nombre   y   el   tag   son  identificadores y sirven para poder encontrar información del elemento en el estándar,  como VR y Longitud del Valor. El tipo puede ser: 1. Es requerida su presencia y que tenga un valor. 2. Es requerida su presencia pero no que tenga un valor. 3. Es opcional su presencia y su valor. Los tipos 1C, 2C y 3C, son como los anteriores, pero su presencia está sujeta a  una condición. Dicha condición es explicada en la descripción. La segunda Tabla posee un conjunto de Entidades de Información, por cada una  un conjunto de módulos, y por cada módulo una referencia para poder encontrarlo  dentro del estándar, y por último la obligatoriedad de su uso: M: Obligatorio. C: Condicional. U: Opción del Usuario. [13] Respecto  de  los identificadores, cada  estudio  posee  su identificador  unívoco,  Study Instance UID, que es el mismo en todas los archivos DICOM relacionados con 

(16)

archivos de ese estudio. Por otro lado cada campo está representado por un sólo archivo  DICOM, y tiene dos identificadores asociados, que si bien diferentes son unívocos, SOP  Instance   UID,   que   es   el   identificador   del   archivo   propiamente   dicho,   e   Instance  Number, que denota un orden en la serie. Esto quiere decir, ya que cada campo está  asociado a una serie,  Instance Number dirá cual es el orden de esos campos.

Otro   punto   importante   es   el   identificador   del   paciente.   Se   debe   asociar   la  información de los estudios con la información del paciente. La alternativa escogida es  la siguiente: todos los archivos DICOM se generan con el mismo usuario, el usuario  anónimo.   Luego   se   envía   dicha   información   a   un   servidor   PACS.   En   el   servidor,  basándose en el identificador del estudio, se asocia a cada estudio con un paciente. Si,  en el mejor de los casos, el paciente estaba cargado, la asociación es directa, sino  primero se debe cargar el paciente y luego se lo asocia con el estudio.

Nombre del Atributo Tag Tipo Descripción para este proyecto

File Preamble (Preámbulo 

del archivo) Sin campos de Tag y  Longitud

1 Ya se explicó. Para este proyecto se no se usará, así  que los 128 bytes serán seteados a cero. Dicom Prefix (Prefijo 

DICOM) Sin campos de Tag y  Longitud 1 Es “DICM” siempre. File Meta Information Group  Length (Longitud del Grupo  de Meta Información del  Archivo) (0002,0000) 1 Número de bytes después de éste Elemento de  Datos (final del campo Valor) hasta e incluyendo el   último Elemento de Datos del Grupo 2 de la Meta   Información del Archivo. Para este proyecto se es  aproximadamente 160 bytes dependiendo los  próximos elementos. File Meta Information  Version (Versión de la Meta  Información del Archivo) (0002,0001) 1 Campo de dos bytes donde cada bit identifica una  versión de este encabezado de Meta Información de  Archivo. En la versión 1 el primer valor del byte es  00H y el segundo valor de byte es 01H. Para este proyecto se usará la versión 1, así que su  valor será: 0001 Media Storage SOP Class 

UID (IDU de Clase PSO de  Almacenamiento de Medio)

(0002,0002) 1 Identifica de forma unívoca a la Clase PSO de  Almacenamiento de Medio. Están detalladas en  PS 3.4 del estándar DICOM.  Para este proyecto se usará  1.2.840.10008.5.1.4.1.1.77.1.2 cuyo nombre de Clase  PSO es VL Microscopic Image Storage  (Almacenamiento de Imágenes Microscópicas a  Luz Visible) Media Storage SOP Instance  UID (IDU de la Instancia  PSO de Almacenamiento de  Medio) (0002,0003) 1 Identifica la instancia de la Clase PSO. Para este  proyecto se usará un prefijo dado por el usuario,  seguido de un punto y un time stamp.

(17)

Transfer Syntax UID (IDU de 

la Sintaxis de Transferencia) (0002,0010) 1 para codificar el Conjunto de Datos. No se aplica a  Identifica la Sintaxis de Transferencia que se usa   la Meta Información.  Para este proyecto se usará el identificador por  defecto: 1.2.840.10008.1.2. Implicit VR Little Endian. Implementation Class UID  (IDU de Clase de  Implementación) (0002,0012) 1 Identifica unívocamente la implementación que  escribió este archivo y su contenido. Para este  proyecto se usará el identificador usado por  dcm4chee: 1.2.40.0.13.1.1

*UID : Unique Identifier = Identificador Único = IDU *SOP: Service­Object Pair = Par Servicio­Objeto) = PSO * Sólo se añaden los elementos obligatorios (Tipo 1)

Tabla 2.2.3.3.1. ­ Tabla de Meta Información.

Entidad de 

Información Módulo  Referencia Uso

Patient (Paciente) Patient (Paciente) C.7.1.1 M Clinical Trial Subject (Sujeto del Ensayo  Clínico) C.7.1.3 U Study (Estudio) General Study (Estudio General) C.7.2.1 M Patient Study (Estudio del Paciente) C.7.2.2 U Clinical Trial Study (Estudio del Ensayo  Clínico) C.7.2.3 U Series (Serie) General Series (Serie Clínica) C.7.3.1 M Clinical Trial Series (Serie del Ensayo  Clínico) C.7.3.2 U Equipment 

(Equipamento)  General Equipment (Equipamento General) C.7.5.1 M

Image (Imagen) General Image (Imagen General) C.7.6.1 M Cine (Cine) C.7.6.5 M Multi Frame (Múltiples Frames) C.7.6.6 M Image Pixel (Píxel de Imagen) C.7.6.3 M Adquisition Context (Contexto de  Adquisición) C.7.6.14 M Device (Dispositivo) C.7.6.12 U Specimen (Espécimen) C.7.6.22 C *1 VL Image (Imagen Visible a la Luz) C.8.12.1 M

(18)

Frame Extraction (Extracción de Frames) C.12.3 C *2 *1 Requerida de si el sujeto de la imagen es un espécimen *2 Requerido si la instancia PSO fue creada en respuesta a un requerimiento de respuesta a nivel  frame. Tabla 2.2.3.3.2. ­ Tabla del Conjunto de Datos. La siguiente tabla es parte de la la Tabla C.7­1 del estándar DICOM. Mostrar  esta tabla tiene como objetivo exponer   un ejemplo de como son los módulos de la  Tabla 2.2.3.3.2.. La descripción del resto de los módulos y como deben ser llenados se 

encuentra   en   [13].   No  se   hace   una   explicación   extensiva   por   que   son   demasiados  valores.

Nombre del Atributo Tag Tipo Descripción del Atributo

Patient's Name (Nombre del  Paciente) (0010,0010) 2 Nombre completo del paciente. Patient Id (Id del Paciente) (0010,0020) 2 Número de identificación del hospital  primario o código para el paciente ... ... ... ... Patient's Birth Date (Fecha de  Nacimiento del Paciente) (0010,0030) 2 Fecha de Nacimiento del Paciente Patient's Sex (Sexo del 

Paciente) (0010,0040) 2 Sexo del paciente.Valores enumerados:M = Masculino, F = Femenino, O =  Otro. ... ... ... ... Tabla 2.2.3.3.3. ­ Tabla de un Módulo del Conjunto de Datos. 2.2.3.4. DICOM XML Por último, en la siguiente figura se muestra un archivo XML que se genera con  la aplicación dat2xml desarrollada.

(19)

Fig. 2.2.3.4.1. ­ Archivo XML generado con dat2xml.

<?xml version="1.0" encoding="UTF-8"?> <dicom>

<attr tag="00020000" vr="UL" len="4">138</attr> <attr tag="00020001" vr="OB" len="2">00\01</attr>

<attr tag="00020002" vr="UI" len="26" >1.2.840.10008.5.1.4.1.1.77.1.2</attr> <attr tag="00020003" vr="UI" len="26" >123.456.7890.1307518140726</attr> <attr tag="00020010" vr="UI" len="20">1.2.840.10008.1.2.1</attr>

<attr tag="00020012" vr="UI" len="2">1.2.40.0.13.1.1</attr>

<attr tag="00080008" vr="CS" len="16">ORIGINAL\PRIMARY</attr> <attr tag="00080016" vr="UI" len="26">1.2.840.10008.5.1.4.1.1.7</attr> <attr tag="00080018" vr="UI" len="26">123.456.7890.1307518140726</attr> <attr tag="00080020" vr="DA" len="0"/>

<attr tag="00080030" vr="TM" len="0"/> <attr tag="00080050" vr="SH" len="0"/>

<attr tag="00080060" vr="CS" len="2">GM</attr> <attr tag="00080070" vr="LO" len="0"/>

<attr tag="00080090" vr="PN" len="0"/>

<attr tag="00081030" vr="LO" len="30">Blood Chagas Disease Analysis</attr> <attr tag="0008103E" vr="LO" len="34">Fields Images From a Blood Sample</attr> <attr tag="00100020" vr="LO" len="6">000000</attr>

<attr tag="00100010" vr="PN" len="10">Anonymous</attr>

<attr tag="0020000D" vr="UI" len="26">123.456.7890.1307518140726</attr> <attr tag="0020000E" vr="UI" len="26">123.456.7890.1307518140726</attr> <attr tag="00200010" vr="SH" len="26">123.456.7890.1307518140726</attr> <attr tag="00200011" vr="IS" len="0"/>

<attr tag="00200013" vr="IS" len="0">0</attr> <attr tag="00200020" vr="CS" len="0"/>

<attr tag="00280002" vr="US" len="2">1</attr>

<attr tag="00280004" vr="CS" len="12">MONOCHROME2</attr> <attr tag="00280008" vr="IS" len="2">11</attr>

<attr tag="00280009" vr="AT" len="4">00181063</attr> <attr tag="00280010" vr="US" len="2">240</attr> <attr tag="00280011" vr="US" len="2">360</attr> <attr tag="00280100" vr="US" len="2">8</attr> <attr tag="00280101" vr="US" len="2">8</attr> <attr tag="00280102" vr="US" len="2">7</attr> <attr tag="00280103" vr="US" len="2">0</attr> <attr tag="00282110" vr="CS" len="0"/>

<attr tag="00324000" vr="LT" len="172">Diagnosis: ...</attr> <attr tag="00082218" vr="SQ" len="2">0</attr>

<attr tag="00400555" vr="SQ" len="0"/>

<attr tag="7FE00010" vr="OB" len="950400" src="pixels.pix"/> </dicom>

(20)

Puede notarse que el  último tag enlaza al archivo XML con los píxeles que  tienen las imágenes del campo que representa al archivo. La aplicación xml2dcm de  DCM4CHEE usará ambos archivos field.xml y field.pix para generar field.dcm.

2.3. Prototipo PC

Como   se   dijo   antes,   con   el   objetivo   de   facilitar   las   pruebas   se   generará   un  prototipo  en   PC.   Por  tanto  se  deberá  realizar   un   software   que   genere  una   salida  idéntica   a   la   que   generaría   la   máquina,   para   luego   tomar   esa   salida   y   seguirla  procesando. El módulo que se encargue de esto deberá tener una entrada de datos. La  misma se define de la siguiente forma: Fig. 2.3.1. ­ Estructura de directorios. Datos de entrada. El resto del procesamiento es igual al explicado en la sección 2.2.. El módulo es  movement_detector. En el siguiente diagrama de actividades se muestra el flujo de trabajo diseñado: studies/ images_info.txt study_00001/ fields/ field_00001/ image_01.bmp ... image_08.bmp field_00002/ image_01.bmp ... image_08.bmp ... studies/ images_info.txt study_00001/ fields/ field_00001/ image_01.bmp ... image_08.bmp field_00002/ image_01.bmp ... image_08.bmp ...

(21)

Fig. 2.3.2. ­ Transferencia de datos desde Máquina a PC, de forma simulada. 4. INSTALACIÓN Y PRUEBA En esta sección se verá como se puede instalar y probar el proyecto. 4.1. Instalación Se necesitará un sistema GNU/Linux que tenga instalado make, subversion, gcc,  g++, java, javac, jar. Mediante el siguiente comando ingresado en la consola se podrá tener acceso a  todo el proyecto: svn checkout http://vhdl­trypanosoma­cruzi­detection­ algorithm.googlecode.com/svn/trunk/prj vhdl­trypanosoma­cruzi­detection­ algorithm­read­only Luego dentro del directorio prj/ se debe compilar el proyecto ingresando: make Se generarán los binarios correspondientes en el directorio prj/bin/. 4.2. Prueba En el directorio prj/test, se debe ingresar: ./test.sh. Este caso de prueba toma 

(22)

directorio de entrada tiene la información que necesita el Prototipo PC, el de salida  tiene la información terminada, lista para enviar a un PACS. Si se quiere visualizar el contenido de los archivos generados en el directorio  prj/bin/Ginkgo_CADx­2.4.1.0_linux_x86/ se encuentra una herramienta capaz de poder  visualizar el directorio resultante. 5. ANEXO: ENVÍO A UN PACS En la siguiente sección se tratará el tema de enviar los datos generados a un  servidor PACS.  5.1. Instalación del servidor PACS

El   primer   paso   es   instalar   un   servidor   de   estas   características.   Se   eligió  dcm4chee­web. Las instrucciones de como hacerlo se encuentran en la web de dicho  proyecto   [14].   Dentro   del   directorio   ./prj/bin/dcm4chee­pacs/installation_files   se  encuentran los archivos y las instrucciones para poder instalarlo. No se detallarán las  instrucciones aquí porque son algo complejas. Una vez hecho esto se debe ejecutar el  siguiente comando para ejecutarlo: ./prj/bin/dcm4chee­web/dcm4chee­2.16.2­mysql/bin/run.sh Luego se debe acceder a http://localhost:8080/dcm4chee­web con usuario: admin  y password: admin Fig. 5.1.1. ­ Servidor PACS, DCM4CHEE­WEB. 5.2. Envío al servidor PACS Para realizar el envío se puede utilizar la misma herramienta que se necesitó 

(23)

1. Ir a Herramientas   Configuración   Servidores PACS→ AET Local = DCMRCV%localhost

Puerto = 11112

2. En Nuevo completar con los datos de la siguiente figura:

Fig. 5.2.1. ­ Ginkgo CADx, configuración.

3. En   la   pantalla   principal,   click   derecho   en  Anonymous­>Enviar   a   un  Servidor PACS

4. Presionar sobre la flecha >>. Seleccionar Mi Servidor Local. Aceptar.

5. Luego en el servidor, ya que se envían estudios pertenecientes al paciente  anónimo, se pueden crear los pacientes que hagan falta y luego asociar los  estudios con los pacientes, mediante la opción Merge.

(24)
(25)

6. CONCLUSIÓN

En el presente trabajo se planteó resolver un problema particular perteneciente  a un   proyecto que busca la construcción de un prototipo de una máquina portable  capaz   de   detectar   el   Mal   de   Chagas   en   muestras   de   sangre.   Dicho   problema   es  convertir la información de los estudios realizados por la máquina en formato DICOM.  En el trabajo se analizó, diseño e implementó una solución. Se definió el formato  de la información de salida de dicha máquina. El procesamiento de esta información  en una PC, con los respectivos formatos intermedios, hasta convertirla en un formato  final basado en un conjunto de archivos DICOM. Se explicó como se debían construir  dichos archivos haciendo una exploración por el estándar del formato. Finalmente se  explicó   como   esa   información   podía   ser   enviada   a   un   servidor   PACS   para   ser  centralizada. 7. BIBLIOGRAFÍA • [1] Nature. International weekly journal of science. http://www.nature.com/nature/journal/v465/n7301_supp/full/nature09220.html  • [2] Tesis de Grado de Emmanuel Luján: http://code.google.com/p/vhdl­trypanosoma­cruzi­detection­algorithm/ • [3] Imágenes enviadas por Paula G. Ragone.  Unidad de Epidemiología Molecular, Instituto de Patología Experimental.  Universidad Nacional de Salta. Av. Bolivia 5150 CP 4400. • [4] Optical detection of Trypanosoma­Cruzi in blood samples, for diagnosis  purpose . E. Alanis, G. Romero, L. Alvarez, C. Martinez, and M. A. BasombrIo Facultad de Ciencias Exactas ­ Facultad de IngenierIa ­ Facultad de Ciencias  Naturales lnstituto de Patologia Experimental (CONICET­UNSa.)  Universidad Nacional de Salta, Consejo de Investigación. 4400­Salta, Argentina,  email: a1anise@ciunsa.edu.ar  • [5] Wikipedia. http://wikipedia.org/ • [6] Plataforma realizada por Ing. Martín Vazquez  (mvazquez@exa.unicen.edu.ar) y Sr. Luis Pantaleone (panta@luispanta.com.ar). • [7] DCM4CHE: Open Source Clinical Image and Object Management

(26)

• [8] DICOM File Format http://www.dabsoft.ch/dicom/10/7/ • [9] DICOM Specification Overview: Basic DICOM File Structure http://www.leadtools.com/SDK/medical/dicom­spec1.htm • [10] Material provisto en la web de la materia Informática Médica. UNICEN.  http://informaticamedica.alumnos.exa.unicen.edu.ar/ • [11] A Very Basic DICOM Introduction http://www.dcm4che.org/confluence/display/d2/A+Very+Basic+DICOM+Introduc tion • [12] Introduction to the DICOM standard http://www.santec.lu/project/epict/training/dicom/start • [13] Digital Imaging and Communications in Medicine (DICOM). Part 3: Information Object Definitions http://www.dicomtags.com/dicom­standard/09_03pu3.php • [14] DCM4CHEE 2.16.2 Installation Instructions http://www.dcm4che.org/confluence/display/ee2/Installation Otra bibliografía consultada: • The National Electrical Manufacturers Association (NEMA) http://medical.nema.org/ • Siglas DICOM http://www.angelfire.com/co2/whatdicom/yak.html • DICOM Lookup http://www.dicomlookup.com/ • Muestras de archivos DICOM http://www.aycan.de/main/lp/sample_dicom_images.html • Representaciones de Valor (VR) http://idlastro.gsfc.nasa.gov/idl_html_help/Value_Representations.html • Tags Dicom 

Referencias

Documento similar

Con el estudio de las funcionalidades existentes en otros sistemas, lo estipulado en el estándar DICOM 3.0 y las normativas de IHE, para la integración de sistemas

que hasta que llegue el tiempo en que su regia planta ; | pise el hispano suelo... que hasta que el

dente: algunas decían que doña Leonor, &#34;con muy grand rescelo e miedo que avía del rey don Pedro que nueva- mente regnaba, e de la reyna doña María, su madre del dicho rey,

E Clamades andaua sienpre sobre el caua- 11o de madera, y en poco tienpo fue tan lexos, que el no sabia en donde estaña; pero el tomo muy gran esfuergo en si, y pensó yendo assi

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

Fuente de emisión secundaria que afecta a la estación: Combustión en sector residencial y comercial Distancia a la primera vía de tráfico: 3 metros (15 m de ancho)..

Cuando se crea un nuevo proyecto DICOM, se les mostrará a los usuarios las imágenes que ha almacenado en ese proyecto y, a las que puede aplicar los

Las manifestaciones musicales y su organización institucional a lo largo de los siglos XVI al XVIII son aspectos poco conocidos de la cultura alicantina. Analizar el alcance y