DICOM

IMÁGENES DIAGNOSTICAS Y COMUNICACIONES EN MEDICINA

En el área de Instrumentación Medica

UNIVERSIDAD SANTO TOMAS DE AQUINO

FACULTAD DE INGENIERIA ELECTRONICA

BOGOTA D.C.

2004

OBJETIVOS

• Conocer en que consiste este método de diagnostico y comunicación desde sus principios hasta su funcionamiento.

• Conocer que aplicabilidad de este y como mejoraría la medicina en esta era.

• Entender como este sistema sea implementable y si no fuera así, como seria para hacerlo.

• Dar a conocer de donde proviene como también su historia.

• Para que es y de que sirve para la medicina.

INTRODUCCION

¿QUÉ ES DICOM?

Es el estándar en Imagen Digital y Comunicaciones en Medicina, que describe detalladamente los medios para dar formato e intercambiar imágenes e información entre dispositivos diferentes.

En 1992 en la reunión anual de la Sociedad de Radiología de América del Norte (RSNA), en la parte 1(Introducción y Descripción) y en la 8 (Soporte de Comunicaciones de Red e intercambio de Mensaje) del DICOM de ACR-NEMA (Imagen médica y Comunicaciones en la Medicina) el Estándar se había votado y aprobado. Las partes restantes 2 a 7 y 9 se hicieron disponibles para comentarios. En infoRAD, se realizó una demostración de la Versión de DICOM 3.0, la parte 8 usando mensajes de la versión previa 2.0 de ACR-NEMA. Mientras estas no eran implementaciones que incluían todas las estructuras de datos de DICOM, mostraron que el apoyo de red era operacional y podría cumplirse exitosamente.

Durante el encuentro anual de 1992 se formaron Grupos de trabajo de ACR-NEMA (WGs) responsables de las partes restantes y completar el estándar de DICOM en encuentros mensuales. Se terminó en septiembre de 1993, donde las versiones finales de muchas de las partes habían experimentado la prueba de implementación real a lo largo de 1993 para asegurar que la calidad de estándar sería demostrada por productos reales en el encuentro de 1.993.

Ahora esta Versión 3.0 de DICOM esta finalizada, los usuarios y los fabricantes pueden conseguir alguna idea del alcance de trabajo involucrado. Debido a sus partes múltiples y arcanos de comparecientes diagramas y terminología, comprender su uso y el valor de estos documentos es una tarea atemorizante. Este prospecto servirá como una introducción a DICOM, qué son sus elementos, qué conceptos importantes forman su fundación, y como es el límite para extender la revolución electrónica en imagen médica.

PARA QUE SURGIO?

• Promover la comunicación entre imágenes digitales independientemente del fabricante que las produjo.

• Ofrecer mayor flexibilidad a los sistemas de almacenamiento y comunicación de imágenes.

• Facilitar la creación y consulta a sistemas de diagnóstico por diferentes dispositivos y en diversos lugares locales o remotos.

HISTORIA Y FUNDAMENTOS

En 1983, el Colegio Estadounidense de Radiología (ACR) y la asociación Nacional de Fabricantes eléctricos (NEMA) formó un comité cuya misión era hallar o desarrollar una interfase entre el equipamiento y cualquier otro dispositivo que el usuario quiera conectar. Además de las especificaciones para la conexión de hardware, el estándar se desarrollaría para incluir un diccionario de los elementos de datos necesarios para la interpretación y exhibición de imágenes.

En 1985, surgió la primera versión del estándar.

En 1988, se mejoró y surgió la versión 2.0

El problema era que muchos usuarios querían una interfase entre dispositivos y una red y la versión 2.0 carecía de las partes necesarias para la comunicación robusta de red.

Se rediseño el proceso entero y se adoptó como método el objeto orientado a diseño, dando lugar al DICOM 3.0

Pero remontando mas las bases de DICOM explicaremos más.

Con la aparición de los ordenadores y la tecnología de la imagen digital (TAC, Radiología Digital, PET, SPECT etc.) se han desarrollado diversos sistemas que intentan integran el historial clínico del paciente y las diferentes pruebas que se le han realizado par el establecimiento del diagnóstico.

Los PACS (Sistemas de Archivo y Comunicación de Imágenes) son una herramienta informática que aporta nuevos modos de trabajo a la radiología diagnóstica. El objetivo final de un PACS es permitir el funcionamiento de un servicio de radiología sin imágenes en película ni documentos en papel, integrando las imágenes y la información clínica. Alrededor de un sistema central de gestión y archivo se disponen diferentes sistemas de adquisición, visualización y archivo de imágenes, unidos por redes de comunicaciones. Para resolver el problema de la interconexión de este conjunto de equipos tan heterogéneos se definió el estándar DICOM. Para aquellos equipos compatibles con este estándar, el acceso a su información radica en el desarrollo o adquisición de aplicaciones DICOM.

En este trabajo se presenta como ha sido posible la interconexión a través de una WAN de diferentes centros, asistenciales y de investigación, equipados con TACs con protocolos de comunicaciones y almacenamiento digital heterogéneos (DICOM y propietarios). Para buscar una metodología de comunicaciones se ha implementado la arquitectura SCP (Proveedor de clases de servicios)-SCU (Usuario de Clases de Servicios) definida por el estándar. Las comunicaciones son realizadas a través de RDSI entre los diferentes centros hospitalarios y universitarios, distantes entre si desde 5Km hasta 100 Km. Esta topología es escalable y permite la interconexión de equipos, independientemente del protocolo que utilicen, ya que, para cada equipo no compatible DICOM se desarrolla módulo específico de estandarización. Se consigue asi la adquisición en remoto de imágenes médicas para el diagnóstico, centralizándolas en una base de datos común y permitiendo el acceso desde los diferentes centros asistenciales.

En un esfuerzo para desarrollar unos medios estándares para que usuarios de equipamiento de imagen médica (tal como TAC, resonancia magnética, medicina nuclear, y ultrasonidos) puedan intercambiar imágenes u otros dispositivos entre estas máquinas, el Colegio Estadounidense de Radiología (ACR) y la Asociación Nacional de Fabricantes Eléctricos (NEMA) formó un comité conjunto a principios de 1983. La misión de este grupo, el Comité para estandarizar las comunicaciones y la Imagen digital de ACR-NEMA, estuvo en hallar o desarrollar una interfase entre el equipamiento y cualquier otro dispositivo que el usuario quiera conectar.

Además de las especificaciones para la conexión de hardware, el estándar se desarrollaría para incluir un diccionario de los elementos de datos necesitados para interpretación y la exhibición de imágenes.

La comisión inspeccionó muchos patrones de interfase existentes, pero no se encontró ninguno que fuera enteramente satisfactorio. En algunos, sin embargo, se encontraron ideas útiles. La Asociación Estadounidense de Físicos en la Medicina (AAPM) había, un año antes, desarrollado un formato estándar para grabar imágenes sobre la cinta magnética (1). La porción de cabecera contendría una descripción de la imagen junto con los elementos de datos (tal como nombre paciente) para identificarlo. El concepto de usar elementos de longitud variable identificados con una etiqueta o la llave (el nombre del elemento) se creyó que era particularmente importante y fue adoptado por la comisión.

Después de 2 años de trabajo, la versión primera del estándar, ACR-NEMA 300-1985 (también llamado ACR-NEMA Versión 1.0) se distribuyó en 1985 en la reunión anual del RSNA y publicada por NEMA. Como con muchas versiones primeras, se encontraron errores y sugirieron mejoras. La comisión había creado un grupo de trabajo (WG) VI para mejorar el estándar una vez se publicó. Este WG contestó muchas preguntas de desarrolladores potenciales y comenzó trabajando sobre cambios para mejorar el estándar. En 1988, ACRNEMA 300-1988 (o Versión 2.0 de ACR-NEMA) se publicó. Usó sustancialmente la misma especificación de hardware que la Versión 1.0, pero se agregó nuevos elementos de datos y se fijaron un número de errores e inconsistencias.

El problema era que por 1988 muchos usuarios quisieron una interfase entre dispositivos y una red. Mientras esto podría realizarse con la Versión 2.0, el estándar careció de partes necesarias para la comunicación robusta de red. Por ejemplo, uno podría enviar a un dispositivo un mensaje que contenga información de cabecera y una imagen, pero el dispositivo no sabría necesariamente qué hacer con los datos. La Versión 2.0 de ACR-NEMA no era diseñada para conectar equipamiento directamente a una red, resolver estos problemas significaban cambios importantes al estándar. La comisión había adoptado la idea que las futuras versiones del Estándar de ACR-NEMA tendrían compatibilidad con las versiones anteriores, y esto puso algunas restricciones al WG VI.

En una decisión importante para el estándar, se decidió que el desarrollo de una interfase para el apoyo de red requeriría demasiados parches sumados a la Versión 2.0. El proceso entero tuvo que ser rediseñado, y el método adoptado fue el de objeto orientado a diseño. En secciones posteriores describirán este proceso brevemente. Además, un examen completo de los tipos de servicios necesitados para comunicar con redes diferentes mostró que definiendo un servicio básico permitiría que la capa superior procesara las comunicaciones (la capa de aplicación) para hablar con un número de protocolos diferentes de red. Estos protocolos se modelan como una serie de capas, frecuentemente referida a como "stacks.".

En la Versión existente 2.0 el "stack" definido en una conexión punto a punto era uno. Dos de los otros se eligieron con base en la popularidad y futura expansión: El Protocolo de Control de Transmisión / Internet de Protocolo (TCP / IP) y la Organización Internacional de Estándares de Interconexión de Sistemas (ISO-OSI). La figura A se muestra un diagrama del modelo de comunicación desarrollado. La filosofía básica de diseño era que una aplicación de imagen médica determinada (fuera del alcance del estándar) podría comunicar sobre cualquier de los stacks de otro dispositivo que use la misma stack. Con la adherencia al estándar, sería posible cambiar las comunicaciones de stacks sin tener que para revisar los programas de computadora de la aplicación.

Figura A. Modelo de protocolo de comunicaciones DICOM.

Después de tres de años de trabajo, WG VI, con valiosas sugerencias de la industria y la academia, ha completado DICOM de ACR-NEMA (también llamado DICOM 3.0). Es un estándar de tamaño mayor que las versiones 1.0 o 2.0, pero también soporta muchas características de las versiones anteriores.

El proyecto se basó fundamentalmente en la digitalización y almacenamiento de imágenes del Servicio de Radiodiagnóstico. Las imágenes se capturan mediante un sistema de chasis que portando películas de fósforo son estimuladas por los Rayos X y posteriormente leídas mediante una sobre estimulación con luz láser.

A la imagen se le adjuntan los datos personales del paciente, los datos del proceso y exploración así como los datos correspondientes a los profesionales, momento (fecha y hora), etc.

Este conjunto de datos e imagen se unen de una forma específica para formar lo que llamamos una imagen DICOM. (DICOM: Imágenes y Comunicaciones Digitales en Medicina.) Las imágenes DICOM son la base de los sistemas PACs, siendo elementos esenciales para poder archivar y recuperar la información asociada o asociable a los procesos de los pacientes.

El Proyecto que en su fase PACs ha sido valorado y permite su recuperación, por consiguiente el análisis de las imágenes desde sistemas de visualización ubicados en los servicios médicos.

Este proyecto ha tenido varios objetivos:

• Reducir las radiaciones de exposición de los pacientes. Dependiendo de los sistemas utilizados, la mayoría permite hacer exploraciones con menor intensidad de radiación X. Este tipo de exploraciones es tan seguro que rara vez se debe de repetir un estudio, y además la consulta de los archivos permite verificar que hay exploraciones recientes.

• Conseguir aumentar el número de exploraciones por equipos permitiendo así reducir las demoras o esperas de los pacientes pendientes de exploraciones.

• Incrementar notablemente la calidad diagnóstica de las imágenes. El resultado es espectacular, y lo es aun más con el uso de los programas de manipulación de imágenes: lupas digitales, cambios de contrastes, etc.

• Facilitar procesos de realización de informes, archivo y recuperación sin tener que contar con terceros: celadores, profesionales de archivos, etc., u otros como la disminución de película en acetatos (radiografía convencional) y los consiguientes revelados y eliminación de residuos químicos altamente contaminantes (residuos especiales del Grupo IV).

Modelos de Información y DICOM:

Simplemente, DICOM es un estándar para la comunicación de imágenes médicas y la información asociada. Difiere de las Versiones 1.0 y 2.0 de ACR-NEMA en varios aspectos importantes. Muy importante es que el diseño básico del estándar se cambió. Las versiones 1.0 y 2.0 están confinadas en un modelo implícito de información del que se usa en los departamentos de radiología. Los elementos de datos se agruparon con base en la experiencia de los diseñadores, y aunque la planimetría era imperfecta, la estructura de mensaje permitió la información necesaria para ser transmitida. Sin embargo, DICOM confía en modelos explícitos y detallados de cómo las "cosas" (pacientes, imágenes, informes, etc.) implicadas en operaciones de radiología se describen y como se relacionan. Estos modelos se llaman la entidad - relación (o E-R) los modelos y son una manera para estas seguros que fabricantes y los usuarios comprenden la base para desarrollar las estructuras de datos que usa DICOM. La figura B muestra un ejemplo de un diagrama E-R, el modelo total de aplicación que defiende DICOM. Este proceso de modelización se comenzó en uno de los grupos de trabajo que ha creado a DICOM (WG VIII). Este grupo comenzó con la tarea de definir los requisitos de interfase entre un archivo de imagen y una red de comunicaciones (PACS) y un sistema de información de radiología u hospital (HIS o RIS).

Este proceso de definición requirió que las operaciones en radiología debían ser adecuadamente modeladas tal como se necesitarían en un HIS o RIS para poder determinarse conjuntamente qué se haría con esa información en el PACS. El diagrama E-R básico para el funcionamiento del departamento de radiología sirvió como la base para la mayoría de los modelos adicionales hechos por el WG VI en el desarrollo de DICOM.

La ventaja de estos modelos es que muestran claramente los ítems de datos requeridos en un escenario determinado estando modelado como estos ítems obran recíprocamente y se relacionan. Mirando a un diagrama E-R es importante anotar que no es un organigrama que describe los pasos de movimiento de información; más bien, muestra las relaciones y jerarquía de elementos de información. Las flechas se agregan a diagramas para que la dirección de relaciones no sea mal interpretada.

Estos diagramas se usan ampliamente a lo largo de estándar de DICOM puesto que ellos claramente muestran las suposiciones hechas al desarrollar los componentes del estándar.

Figura B.

Figura B: El modelo de aplicación DICOM.

Las cajas rectangulares representan las entidades que singularmente, o en combinación, forman los objetos de información. Los rombos - las formadas cajas son las relaciones.

Las flechas representan las conexiones entre entidades y las relaciones y se muestran con flechas para dar alguna idea de la jerarquía no necesariamente del movimiento de información.

Las "ls" y "Ns" indican si la relación involucra una de entidad a una de entidad, uno a N, N a uno, o N a N de entidades. IOD (Definición de un objeto informativo), VOI (valor de interés), LUT (tabla de consulta), Mod (modalidad).

La importancia de modelar crece con la necesidad de saber el contexto de información cuando consideramos las comunicaciones en red. En un entorno punto a punto, el usuario sabrá exactamente qué dispositivos se conectan y cuales son sus capacidades. Los centenares de dispositivos pueden ser adjuntos a redes y algunos dispositivos pueden ser reconfigurados dinámicamente para manejar diferentes tareas o cargas de datos. Esto significa que no puede siempre ser posible saber qué pueden hacer los dispositivos comunicados.

Los dispositivos pueden tener que negociar para establecer un terreno común sobre el que construir las comunicaciones necesarias para cumplir la tarea que el usuario ha pedido.

Como ejemplo, consideremos una persona que hace una llamada telefónica al extranjero para preguntar sobre la reparación de un motor de automóvil. A un nivel bajo, la comunicación involucra marcar el número de teléfono correcto. Esto establecerá un nexo entre dos personas. Pero, si las dos personas no hablan el mismo idioma, ellos no serán aptos para comunicar. Aún cuando ambos hablen el mismo idioma, si su conocimiento de motores de automóviles es muy diferente, ellos no serán aptos para comunicar sobre la tarea (reparación del motor). El éxito de la comunicación requiere no solamente que los individuos hallen el número telefónico correcto (la dirección de red) y establecer una conexión de teléfono, sino que ellos concierten el idioma hablar y que ellos negocien el nivel al cual ambos se entienden.

Este enfoque de desarrollar estructuras de datos basados en modelos y el análisis de versiones abstractas de entidades reales es usado en los modelos de objeto orientado a diseño. Los objetos son las entidades (o la colección de entidades) definidas por el modelo. La descripción de las características de cada una de las entidades son los atributos. Por ejemplo, el "paciente" la entidad en la Figura B tiene atributos que incluyen "nombre paciente" y "número de identificación de paciente" (para simplificar el diagrama, los atributos para las entidades no son mostrados, pero el estándar incluye tablas que definen estos).

El DICOM llama los objetos de acuerdo con sus modelos " objetos de información " y los modelos y tablas de atributos que los definen "definiciones de objeto de información" (IODS). Las entidades mostradas en el modelo son las abstracciones. Si los valores reales se sustituyen por los atributos, la entidad se llama una instancia.

El objeto orientado a diseño también provee una manera para describir no solamente la información sino qué hacer con la información, o como los programas de computadora accederían a la información en una colección de objetos. En el objeto orientado a diseño, los métodos se asocian con los objetos definidos. El DICOM usa este concepto para definir servicios tales como "almacenar imágenes" o "consigue información paciente".

Estos servicios se cumplen en DICOM usando construcciones conocidas como operaciones o notificaciones. El DICOM define un conjunto de notificaciones y operaciones genéricas y las llama elementos de servicio de mensaje DICOM (DIMSE). La combinación de objetos informativos y los tales servicios se llama un par objetosenice, o clase SOP. Un objeto de información puede usarse con un conjunto de servicios, el resultado es una clase SOP.

La figura C muestra una analogía entre construir una sentencia y los ítems correspondientes en DICOM.

Figura C.

Es una analogía entre construir una sentencia y Conceptos de DICOM se ven en p 8 de la figura. Los ítems a la izquierda de las flechas representan partes de una sentencia. A la derecha de las flechas son analogías a conceptos DICOM. El verbo almacenar define una acción para ser tomada, equivalente al Servicio de DICOM llevó en el Elemento de Servicio de Mensaje DICOM. El sustantivo "Imagen de CT" define un objeto sobre que la acción se tomará; esto corresponde a la Definición de Objeto de Información DICOM. La sentencia construyó: "Almacene una Imagen de CT" corresponde a la Clase Par Objeto Servicio DICOM, y si una imagen CT la específica es referida, la correspondencia está es una Instancia de Par Objeto Servicio.

La clase SOP representa la unidad elemental de funcionalidad definida por DICOM. Para especificar una clase SOP cuya implementación debe conformar y el papel para conformar el dispositivo que la soporta, es posible definir con exactitud un subconjunto preciso de Funcionalidad de DICOM incluyendo los tipos de mensajes de intercambio, los datos transferidos en esos mensajes, y el contexto semántico dentro de cual los datos pueden ser entendidos. Un dispositivo puede, para una clase particular SOP, actuar de dos formas: en el papel de proveedor de clase servicio (SCP), el dispositivo provee los servicios de la clase SOP, o en el papel de usuario de clase servicio (SCU), usa los servicios. Además, para cada combinación de clase SOP y papel, el estándar define un conjunto básico de los comportamientos de incumplimiento que gobiernan la comunicación, tal como que dispositivo puede iniciar una conversación.

Las Partes del DICOM son:

Desde las versiones 1.0 y 2.0, DICOM divide mucha de las especificaciones en partes. Estas se hicieron para que las partes puedan expandirse (por ejemplo, las definiciones de nuevos objetos informativos se agregaron) sin tener que rehacer el estándar entero. Dentro de las partes, las secciones están sujetas a la adición o modificación en anexos adicionales, reduciendo la redacción cuando se actualizan partes. La versión actual de DICOM consiste de nueve partes. Las interrelaciones de las Partes de DICOM no son siempre fácilmente aparentes. En la siguiente figura muestra un diagrama que pauta como las partes se relacionan. Esta figura también muestra las partes 10 y 11, que dirigen la manera de cómo DICOM puede usar archivos sobre medios removibles (por ejemplo, disco y cinta) para el cambio de información. Estas partes se describen luego en este prospecto.

Figura D.

Figura D: Muestra as partes actuales y propuestas de extensión de DICOM. Esta figura no es un diseño del modelo. La izquierda representa las partes que definen la red y las comunicaciones punto a punto de DICOM. La derecha muestra las partes que apoyan la comunicación que usa medios removibles de almacenaje. Note que algunas partes (las partes 1, 2, 3, 5, y 6) se usan en ambos ambientes mientras las otras son particulares al dominio específico de comunicaciones.

La Parte l de DICOM es el documento que provee una descripción del resto del estándar. Provee una descripción de los principios de diseño, define muchos de los plazos, y da una descripción breve de toda la otra parte.

La parte 2 es la definición de conformidad con DICOM, y qué significa conformidad. Más que proveer una lista específica de ítem que cada tipo de implementación tiene que seguir para ser conforme, DICOM ofrece un número de bloques (p. ej. , las clases SOP) y requiere que fabricantes describan de forma concreta como sus productos conforman a DICOM. Este proceso construye una declaración de conformidad, y los usuarios tendrán acceso a estos desde los fabricantes. Las versiones 1.0 y 2.0 carecieron de tal mecanismo, así que es posible que dos dispositivos que reclamen ser conforme puedan tener implementaciones suficientemente diferentes para que ellos no comuniquen.

El número de elecciones posibles para los objetos informativos, servicio de clases, papeles, y datos de códigos en Medios de DICOM que este problema sería peor si no hubiese alguna manera para describir exactamente qué elecciones se hicieron en las implementaciones y qué requisitos básicos deben ser encontrados por todas las implementaciones que reclaman conformidad. Esto orientará a los usuarios en seleccionar productos que deben trabajar juntos y pueden formar también la base para que un usuario pueda desarrollar un requerimiento de conformidad como una parte de un convenio adquisitivo.

La parte 3 describe como se definen los objetos de información. Va a definir las del objeto de información usado en DICOM. Al desarrollar las definiciones de objeto de información (IODS), se encontró que muchos contendrían grupos de atributos similares. Esta se apilaron entonces juntos como una serie de módulos comunes que pueden ser usados por más de un IOD. Los IODs en sí mismos están en anexos a la parte, asegurando que las adiciones pueden hacerse sin tener que para revisar la sección inmutable de la parte.

La tabla 1 enumera el IODS definidos en los anexos a la parte 3.

Tabla 1: Objetos Informativos de DICOM

IODS compuestos IODS Normalizados

Imagen de Radiografía Computarizada Información Paciente

Imagen de Tomografía Computarizada Visita Inspección

Imagen de Resonancia Magnética Información Imagen Estudio

Imagen de Medicina Nuclear Información de Componente de Estudio

Imagen de Ultrasonidos Resulta Información

Imagen de Ultrasonidos Multi - Frame l Información de Interpretación de Imagen l

Las dos columnas de la tabla son importantes. La columna izquierda enumera IODS que son objetos compuestos. Estos objetos contienen atributos que se relacionan, aunque no inherentes, a la entidad del mundo real, más esos son inherentes. Por ejemplo, el Tomógrafo Computerizado IOD contiene el atributo "representa fecha" que es inherente a la imagen de CT. Sin embargo, también contiene el atributo "el nombre paciente" que es relativo a la imagen de CT, sino no inherente (es un atributo inherente al IOD de Información de Paciente). La columna derecha enumera IODS que estandariza los objetos. Del ejemplo posterior, la Información Paciente, se estandariza. Contiene atributos inherentes al paciente. Ha habido algunos que discuten sobre los objetos compuestos y como se definieron para retener alguna compatibilidad con Versiones 1.0 y 2.0, y no se ajusta de forma estricta a la guía de objeto-orientado a diseño. Sin embargo, la reciente literatura de informática destaca ventajas de un objeto compuesto. Usar objetos compuestos significa que atributos relacionados e inherentes pueden recobrarse (leyendo desde el disco) con menos accesos.

La parte 4 de DICOM contiene las especificaciones del servicio clases. El servicio de clases se construye desde un conjunto de operaciones primitivas operando sobre IODS. Los servicios pueden ser sacados de como las operaciones actúan sobre los objetos de información. Los papeles de SCU y SCP se definen también en esta parte, y el comportamiento esperado para cada papel en cada servicio se especifica en la clase. Esto permite a implementadores y usuarios comprender qué esperar de un dispositivo que soporta una clase de servicio particular.

La tabla 2 es un listado de las clases de Servicio de DICOM Versión 3.0.

Tabla 2: Versión de DICOM 3.0 Clases de Servicios.

• Clase de servicio de Certificación

• Clase de servicio de Almacenaje

• Clase de servicio de Preguntas / Recobrar

• Clase de servicio de Estudio del Contenido de Notificación

• Clase de servicio de Información de Paciente

• Clase de servicio del control del Estudio

• Clase de servicio del control de Resultados

• Clase de servicio del control de Impresión

La columna izquierda de la tabla es el anexo de parte 4 que especifica la clase de servicio nombrada en la columna derecha. La verificación es entendida para ser usada para la comprobación y localización de averías en la implementación de los protocolos de servicio. La Clases de servicio de almacenaje provee el apoyo básico para la transferencia de imágenes entre Aplicaciones de DICOM.

Para recobrar imágenes desde aplicaciones de DICOM, la clase de servicio de preguntas/recobra apoya operaciones básicas para acceder y mover imágenes con base en los criterios simples de búsqueda (por ejemplo, consiguen todas las imágenes de un paciente particular).

La notificación del contenido del estudio permite a una aplicación de DICOM notificar a otra sobre la existencia, contenidos, y locación de fuente de las imágenes en un estudio ("el estudio" aquí tiene una definición específica en DICOM, pero en general es la colección de imágenes e información asociada que se vuelca en un informe simple). El paciente, el estudio, y la clase de servicio del control de Resultados se diseñaron para apoyar la comunicación entre DICOM - PACS en uso y un sistema separado de información de hospital o radiología (RIS o HIS). El control de Paciente maneja admisión, cumplimiento, y transferencia de información junto con la otra demográfica e información de inspección. El control de estudio apoya la creación, programación, cumplimiento, y rastreo de estudios. El control de resultados tiene un papel similar para los resultados de estudios. Aunque el almacenamiento y la clase de servicio del control de preguntas/recobra que también usan información paciente, estas clases de servicio no son orientados a imagen. Además, al modelo de información usado en DICOM, esta clase de servicio hacen uso del modelo funcional también.

Este se hizo para que el papel del DICOM servicio particular de dirección clase de pariente a las otras funciones de sistema de información serían bien definan. El DICOM imprime servicio de dirección clase de apoyos DICOM comunicación de dispositivo de impresión de imagen en red (tal como láser o impresoras de color).

Una vez una aplicación de DICOM ensambla un conjunto de datos (una colección de información ensamblada desde Objetos informativos de DICOM y las clases de servicio), debe ser codificada para que poder ponerse en forma de mensaje para la comunicación.

Este proceso de codificación se especifica en parte 5. La función principal de esta parte puede ser entendida como la definición del "idioma" que dos de dispositivos usarán para "hablar" uno con el otro. La mecánica del lenguaje es definida por el protocolo de intercambio de mensaje (parte 7), y la materia a tratar qué está ser hecha son definidas por el servicio y objetos de información las clases (separa 3 y 4). Cosas tales como qué cual es el conjunto de caracteres (para el texto) se usa, como un JPEG (Joint Photografic Experts Group) imagen comprimida es codificada, como los elementos de datos se estructuran, y cual es la sintaxis de transferencia usada son definidas también por la parte S. La sintaxis de transferencia es un conjunto de reglas de codificación que es negociada por dos aplicaciones de comunicación para que ellos puedan con exactitud comprenderse el uno al otro. Para asegurar la más amplia interoperatibilidad entre dispositivos conformes a DICOM, o comunicación con dispositivos de capacidad limitada, DICOM provee una sintaxis de transferencia por defecto. Todas las aplicaciones que reclaman para conformar a DICOM deben apoyar por lo menos esta sintaxis de incumplimiento.

A nivel más básico, todos los objetos de información se componen de conjunto de datos.

Estos elementos codifican los valores de los atributos descritos antes (por ejemplo, nombre paciente, número de bits por pixel). Para recobrar un objeto informativo desde una entidad abstracta a una instancia que representa algo en el mundo real, los valores se abastecen de los conjuntos de datos.

La parte 6 de DICOM es el listado completo de todos los elementos de datos junto con sus nombres numéricos (o etiqueta), sus nombres de texto, cual es su representación (texto, número de coma flotante, etc.), si ellos contienen uno o más ítems (la multiplicidad de valor), y qué los valores permitidos están para esos elementos que pueden contener solo ciertos valores. Para mantener compatibilidad a este nivel la estructura de datos de DICOM con patrones anteriores de ACR-NEMA, ninguno de los elementos eran redefinidos a menos que ellos tuvieran errores. Los elementos no muy usuales se les da la condición de "retirados," indicando a usuarios y fabricantes que ellos pueden incluir el elemento en un conjunto de datos de DICOM, pero puede ignorarse a menos que la aplicación particular que esta siendo comunicada todavía usa el elemento.

El usuario de parte del equipamiento de imagen médica trabaja con software que traduce sus entradas en datos y los comandos usados por el equipamiento. Este software se refiere frecuentemente a como una aplicación. En comunicaciones, este software (siguiendo el esquema común del modelo de comunicaciones) obraría recíprocamente con la capa de aplicación del protocolo de comunicaciones.

DICOM sigue este modelo, y la parte 7 define qué se necesita por la aplicación de software para relacionarse con comunicaciones de DICOM. En

DICOM, un mensaje típico consiste de una secuencia de comandos (que los ítems necesitados para soportar los servicios definidos en la parte 4) y una secuencia de datos (los objetos informativos, codificados según la parte 5). En algunos casos (tal como durante la negociación de capacidades), la secuencia de datos puede ser pequeña o no estar presente.

La parte 7 define la construcción de secuencias de comandos tal como la parte 5 define como construir la secuencia de datos. El mensaje construido en la parte 7 necesita ser pasado a capas inferiores del modelo de comunicaciones para que la comunicación pueda tener lugar.

La parte 8 define el soporte de red para cambiar Mensajes de DICOM. Actualmente, TCP/IP y protocolos ISO-OSI son soportados, pero la naturaleza del servicio superior de capa definido en esta parte es tal que se debe posible expandir a otros protocolos con facilidad relativa. Una vez fuera de la capa superior de DICOM, el remanente del protocolo de comunicaciones (o TCP / IP u OSI) sigue los patrones existentes. DICOM no, y no necesita, modificar o personalizar nada en ninguno de estos patrones.

En las versiones primeras del estándar de ACR-NEMA se definieron una interfase rápida de datos paralelos. Hay algunas aplicaciones, particularmente conectando a un equipo más viejo, que usan esta versión.

Por esto, este protocolo antiguo punto-a-punto ha sido utilizado en DICOM. En una manera transparente a las aplicaciones.

La parte 9 del estándar describe esta actualización de la versión de la interfase de 50 contactos. De hecho, un fabricante podría escoger uno de los protocolos de red de parte 8, o el protocolo punto a punto de la parte 9, y ejecutar el mismo software de aplicación en cualquier situación. La contradicción al convencimiento común, es posible conectar a redes usando Versiones de DICOM 1.0 y 2.0, pero tal conexión requiere que una unidad de interfase de red (NIU) que hable al protocolo punto - de - punto por un lado, y un protocolo de red por el otro.

Características de DICOM:

• Intercambiabilidad de objetos en redes de comunicación y en medios de almacenamiento a través de protocolos y servicios, manteniendo sin embargo, independencia de la red y del almacenamiento físico. Todo esto a través de comandos definidos por una sintaxis y una semántica, a los que se les asocian datos. Las versiones anteriores sólo ofrecían comunicación punto a punto.

• Especificación de diferentes niveles de compatibilidad. Explícitamente se describe como definir un determinado nivel de compatibilidad, para escoger sólo opciones específicas de DICOM. En las versiones anteriores se especifica un nivel mínimo únicamente.

• Información explícita de Objetos a través de estructuras de datos, que facilitan su manipulación como entidades autocontenidas. Los Objetos no son únicamente imágenes digitales y gráficas, sino también estudios, reportes, etc.

• Identidad de objetos en forma única, como instancias con operaciones permitidas definidas a través de clases.

• Flexibilidad al definir nuevos servicios.

• Interoperabilidad entre servicios y aplicaciones a través de una configuración definida por el estándar, manteniendo una comunicación eficiente entre el usuario de servicios y el proveedor de los mismos

• Sigue las directivas de ISO en la estructura de su documentación multi-partes. De esta forma facilita su evolución, simplificando la adición de nuevas partes.

Comunicación en DICOM

• DICOM utiliza el modelo de capas para representar conexiones virtuales entre diferentes plataformas de cómputo, utilizando protocolos de comunicación.

• Para establecer una conexión virtual, los dispositivos que pretenden comunicarse deben utilizar los mismos protocolos en cada capa.

• DICOM agrega la posibilidad de conexión en red utilizando como base los protocolos TCP/IP (Transmission Control Protocol/Internet Protocol) y los propuestos por ISO/OSI (International Standards Organization/Open Systems Interconnection).

• De esta forma se aprovechan los protocolos definidos en las capas inferiores tanto de TCP/IP como de ISO/OSI y define los protocolos necesarios en las capas superiores para soportar la comunicación entre aplicaciones en forma eficiente.

• En el caso de ISO/OSI, aprovecha los servicios de las primeras 6 capas.Para el caso de TCP/IP, especifica un protocolo de capa superior DUL (DUL: DICOM Upper Layer). Para ambos casos se definen un protocolo para aplicaciones DICOM, que permite la portabilidad entre ambos ambientes sin afectar las aplicaciones ya realizadas.

Beneficios de DICOM:

• Contribuye a disminuir la cantidad de material fílmico impreso, disminuyendo costos, tiempo de personal, etc.

• Contribuye a aprovechar mejor el tiempo de trabajo de los expertos en una institución, que muchas veces se encuentran ocupados parcialmente por falta de casos de estudios de la propia clínica, mediante la telé consulta de profesionales de otras instituciones.

• Posibilita brindar servicios a distancia.

• Centraliza las imágenes de toda la institución, ahorrando tiempos de acceso y búsqueda, y aumentando la facilidad y comodidad del manejo y utilización de las mismas.

• Permite implementar una política eficaz de copias de seguridad y registro de todos los estudios de imágenes realizados.

Estatus y Futuro de DICOM:

DICOM esta continuamente en cambio, la versión más reciente no suele tener mas de dos meses de antigüedad. Se añaden nuevos equipos y se definen nuevos servicios para crear un entorno más abierto.

El estándar DICOM esta en continua expansión. Probablemente no pasa sola una semana sin que un grupo de trabajo DICOM se reúna en alguna parte del mundo para debatir sobre la definición de nuevos objetos y servicios. Es fácil ampliar el estándar debido a su naturaleza modular. No importa realmente si esta almacenado una imagen TAC o un objeto recientemente definido tal como una imagen dental, hemodinámica o endoscopia también se puede utilizar el mismo servicio. Se puede comparar esto con un taller que hace muebles, donde los objetos de información serian las piezas del mobiliario; y las herramientas, es decir, el martillo, etc., son los servicios DICOM.

CONCLUSIONES

• Entendí como DICOM es de los más ambiciosos proyectos en imagen médica emprendido por la industria y sociedades profesionales.

• Comprendí en que constaba esta nueva forma de integración de varios partes médicas en imágenes para facilitar el estudio como procesos posteriores.

• Este seria un muy patrón complejo a causa del tamaño de su contenido y estructura, pero es implementable y útil para la sociedad.

• Además es un sistema que constante se esta actualizando como implementado dando cada día mayores posibilidades en los estudios diagnósticos de los pacientes alrededor del mundo.

• DICOM creo yo nació con la mentabilidad de extender a todas las partes o clases en esta era como también a mayor integrabilidad de los servicios.

• Este estándar ofrece un balance correcto entre el objetivo pragmático de apoyo de rápida implementación en productos actuales y una fundación modular sólida que asegura una capacidad para evolucionar y responder a futuras necesidades.

• Además de integrar nuevas versiones que cada día son mejoradas estos sistemas de imágenes diagnosticas, funciona sobre las actuales plataformas de comunicación de la cual facilita el medio de comunicación o el intercambio de estas imágenes y diagnósticos entre clínicas, hospitales entre otros centros.

• Además de cumplir con todas estándares mundiales integra la facilidad del intercambio de ellos como la facilidad de obtener desde otros puntos en lugares remotos e imprimirlas evitando así la búsqueda de ellas.