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
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
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. – Portaobjetos y cubreobjetos...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
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.
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.
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
parásitos. El área total del cubreobjetos es de aproximadamente 2700 campos. [4] Fig. 2.1.2. – Portaobjetos y cubreobjetos: 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.
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 … ...
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.
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 …
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 …
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.11 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: ServiceObject Pair (Par ServicioObjeto) . 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.
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
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
ú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.61 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
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.
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: ServiceObject Pair = Par ServicioObjeto) = 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
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.71 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.
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>
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 … ...
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://vhdltrypanosomacruzidetection algorithm.googlecode.com/svn/trunk/prj vhdltrypanosomacruzidetection algorithmreadonly 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
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_CADx2.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ó dcm4cheeweb. Las instrucciones de como hacerlo se encuentran en la web de dicho proyecto [14]. Dentro del directorio ./prj/bin/dcm4cheepacs/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/dcm4cheeweb/dcm4chee2.16.2mysql/bin/run.sh Luego se debe acceder a http://localhost:8080/dcm4cheeweb con usuario: admin y password: admin Fig. 5.1.1. Servidor PACS, DCM4CHEEWEB. 5.2. Envío al servidor PACS Para realizar el envío se puede utilizar la misma herramienta que se necesitó
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.
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/vhdltrypanosomacruzidetectionalgorithm/ • [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 TrypanosomaCruzi 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 (CONICETUNSa.) Universidad Nacional de Salta, Consejo de Investigación. 4400Salta, 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
• [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/dicomspec1.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/dicomstandard/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