INTERCAMBIO DE MENSAJES DICOM

Memorias II Congreso Latinoamericano de Ingeniería Biomédica, Habana 2001, Mayo 23 al 25, 2001, La Habana, Cuba
INTERCAMBIO DE MENSAJES DICOM
J. R. Jiménez, V. Medina, A. Martínez
Universidad Autónoma Metropolitana – Iztapalapa
Departamento de Ingeniería Eléctrica – Area de Procesamiento Digital de Señales e Imágenes Biomédicas
Av. Michoacán y la Purísima, Col. Vicentina, México, D.F., C.P.09340, [email protected]
RESUMEN
El desarrollo de sistemas de almacenamiento y
transferencia de imágenes médicas (PACS) ha conducido
a la definición del estándar de comunicación DICOM.
Este estándar emplea un protocolo de intercambio de
mensajes (DIMSE) que es usado por dos entidades de
aplicación para intercambiar imágenes e información. En
este trabajo se describe este protocolo y se modela su
comportamiento aplicando un proceso de desarrollo de
proyectos de software. Con los productos obtenidos del
proceso se establece un modelo de solución del protocolo,
proporcionando los servicios que requieren los usuarios de
DIMSE. Las pruebas del proceso indican que el modelo
propuesto es adecuado para la capa DIMSE.
Palabras clave: modelo de objetos, proceso de
desarrollo, casos de uso, diagramas de interacción,
diagramas de clase.
1. INTRODUCCIÓN
El desarrollo de nuevas técnicas en imágenes y el
incremento de las modalidades de imágenes en formato
digital ha ocasionado el desarrollo de sistemas de
administración de imágenes médicas llamados PACS
(Picture Archiving and Communication System).
La evolución en el diseño de PACS avanza hacia una
arquitectura abierta, con equipo de distintos proveedores
basado en el estándar DICOM (Digital Imaging and
Communications in Medicine) cuyos objetivos son:
• Promover la comunicación de imágenes digitales sin
importar el fabricante del dispositivo.
• Facilitar el desarrollo y expansión de PACS que
puedan iterconectarse con otros sistemas de
información del hospital.
• Permitir la creación de bases de datos de información
de diagnóstico que se puedan consultar por una amplia
variedad de dispositivos distribuidos geográficamente.
DICOM es un estándar que contempla el modelo
orientado a objetos, buscando con ello que los desarrollos
en software del mismo, sean más rápidos y que se elimine
la necesidad de reinventar cada vez que se hace una
implementación de DICOM, dado que depende de modelos
explícitos y detallados de cómo están descritos y
relacionados los objetos (pacientes, imágenes, reportes,
etc.) involucrados en operaciones de radiología.
El diseño orientado a objetos proporciona una manera de
describir la información y qué hacer con ella, DICOM hace
uso de este concepto definiendo servicios como “almacenar
una imagen” u “obtener información de paciente” [13].
Estos servicios se implementan en DICOM usando
construcciones conocidas como un conjunto genérico de
operaciones y notificaciones llamados Elementos de
Servicio de Mensaje DICOM o DIMSE (DICOM Message
Service Element).
Ya que DICOM utiliza el modelo de objetos es necesario
aplicar un proceso de desarrollo de software en el diseño
de la implementación de este estándar, de tal manera que
aumente la posibilidad de obtener un producto de software
de alta calidad, robusto y de fácil mantenimiento.
Aplicando el proceso de desarrollo para proyectos de
software propuesto por Larman [8], se presenta un modelo
de solución en el diseño de la parte que corresponde a
DIMSE del estándar DICOM.
2. METODOLOGÍA
DICOM es un estándar que cubre parcialmente el modelo
de procesos distribuidos, el cual tiene al menos dos
procesos compartiendo información [12]. La relación entre
ambos procesos se define por una Clase de Servicio
describiendo los papeles de ambos procesos, el SCU
(Service Class User) es el cliente y el SCP (Service Class
Provider) es el servidor. La Clase de Servicio también
define una clase SOP (Service Object Pair Class) que
combina la información y operaciones que ambos procesos
intercambian.
Para que se lleve a cambio el intercambio entre los dos
procesos se debe acordar cuáles clases SOP se soportan (e
implícitamente la Clase de Servicio) y cómo están
divididos los papeles de SCU y SCP para que de esta
manera se intercambien las instancias de Clase SOP.
Después de que se reune la información se codifica en los
formatos DICOM, incluyendo cada atributo en un elemento
de datos. Este conjunto de datos lo maneja el proveedor de
servicio de intercambio, asegurándose que la contra parte
recibe un conjunto de datos igual.
Antes de intercambiar el conjunto de datos de una
instancia SOP se establece la manera en que el conjunto de
datos se codifica por acuerdo, ya sea cuando se usa un
intercambio de red o un almacenamiento en un medio. La
sintaxis de transferencia define un conjunto de reglas de
codificación usadas para representar sin ambigüedad este
conjunto de datos.
La parte de la información de una clase SOP se define en
los IODs (Information Object Definition), y los elementos
de servicio son las operaciones permitidas sobre los IODs.
El grupo de elementos de servicio pertenecientes a la clase
SOP se selecciona de una lista proporcionada por DIMSE.
DIMSE es un elemento de Servicio de Aplicación usado
950-7132-57-5 (c) 2001, Sociedad Cubana de Bioingeniería, artículo 00293
por un par de Entidades de Aplicación DICOM con el
propósito de intercambiar imágenes médicas e información
relacionada. Este intercambio se lleva a cabo siguiendo un
protocolo que define las reglas de codificación para
construir estos mensajes [10]. DIMSE usa el modelo OSI
para representar la interconexión de equipo y ofrece tres
opciones de protocolos de comunicación: una pila OSI, una
de TCP/IP o bien una pila punto a punto.
DIMSE especifica dos grupos de servicios: DIMSE-C,
soporta operaciones con clases SOP compuestas y DIMSEN que soporta operaciones y notificaciones de clases SOP
normalizadas. Los servicios incluidos en DIMSE-C son: CSTORE, C-FIND, C-GET, C-MOVE y C-ECHO; los de
DIMSE-N son: N-EVENT-REPORT, N-GET, N-SET, NACTION, N-CREATE y N-DELETE. Así, un mensaje
DICOM está compuesto de un Grupo de Comandos y un
Grupo de Datos que es dependiente del primero; en el
Grupo de Comandos se indica el servicio DIMSE que se
ejecuta con los datos.
Los servicios DIMSE se implementan como una
interacción petición/respuesta realizada dentro del contexto
de una Asociación establecida, definiendo los
procedimientos y reglas de codificación para construir
mensajes en el intercambio de petición y respuesta. En
general, DIMSE acepta primitivas de petición y respuesta
de un usuario, construye y acepta mensajes, y los pasa por
medio de primitivas de indicación y confirmación.
Para resolver el problema de analizar, diseñar y desarrollar
un modelo de solución para el protocolo DIMSE se aplica
un proceso de desarrollo de software, entendiendo que este
proceso es un método para organizar las actividades en la
creación, desarrollo y mantenimiento de sistemas de
programas para computadora. Booch [3] recomienda los
siguientes principios como parte del desarrollo:
• Iterativo
e
incremental.
Ampliación
y
refinamiento sucesivo de un sistema a través de ciclos
múltiples de desarrollo de análisis, diseño,
implementación y prueba.
• Manejado por casos de uso. El proceso de
desarrollo deberá estar influenciado y organizado
alrededor de los casos de uso.
• Enfasis temprano en la definición de la
arquitectura. Estructura de alto nivel de subsistemas y
componentes,
sus
interfaces,
conexiones
e
interacciones; consiste de un conjunto de marcos de
trabajo,
subsistemas,
clases,
asignación
de
responsabilidades y colaboración de objetos que
satisfacen las funciones del sistema.
Larman [8] establece que los pasos principales para liberar
una aplicación incluyen los siguientes: Planear y elaborar
(definición de requerimientos y casos de uso), Construir
(ciclos de desarrollo aplicando sus fases principales de
análisis, diseño y construcción) y Entregar (poner el
sistema en producción).
A continuación presentamos los resultados obtenidos de
aplicar los primeros dos pasos principales correspondientes
a Planear y elaborar y Construir.
3. RESULTADOS
La parte primordial de Planear y elaborar es la definición
del diagrama de casos de uso, la cual surge de la
identificación de los actores y procesos que ellos inician en
el sistema. Después de realizar varias iteraciones y
refinamientos en esta identificación llegamos al diagrama
de la figura 1.
El diagrama de la figura 1 ilustra el conjunto de casos
de uso para el sistema. Proveer Servicios DIMSE es el caso
de uso más general y es iniciado por un SCU como
invocador de un servicio, se relaciona también con SCP ya
que como ejecutor debe dar una respuesta del servicio
solicitado, además tiene una relación de uso con
Intercambiar mensaje ya que éste realiza el intercambio del
mensaje.
SCU
Proveer Servicios DIMSE
SCP
<<uso>>
<<uso>>
Respuesta pendiente
<<uso>
<<uso>
Intercambiar mensaje
Cancelar respuesta pendiente
DULP
Fig. 1. Diagrama de casos de uso de DIMSE, mostrando a los actores
externos SCU (cliente), SCP (servidor) y DULP (DICOM Upper Layer
Protocol, montado sobre la pila de comunicación, encargado de enviar el
mensaje) y los procesos en que están involucrados
Fig. 2. Modelo conceptual de DIMSE
Respuesta pendiente incluye aquellos servicios que envían
más de una respuesta, antes de generar una confirmación
final (C-FIND, C-GET y C-MOVE), la cancelación de
estos servicios la cubre el caso de uso Cancelar respuesta
pendiente.
En el paso de Construir y como primer producto de la
fase de análisis se obtuvo el modelo conceptual de DIMSE
mostrado en la figura 2. Este modelo explica el protocolo
que sigue DIMSE en la petición o respuesta de uno de sus
servicios, funciona de la siguiente manera: un Invocador
pide un servicio DIMSE, dicho servicio contiene un
Mensaje que se forma o construye con un Grupo de
Comando y un Grupo de Datos, a su vez, el Grupo de
Comando está formado por Elementos de Comando. Si el
Mensaje es muy grande se fragmenta en datos conocidos
como PDVs (Presentation Data Value) para ser enviados
por DULP. Algo similar ocurre cuando el Ejecutor
responde un servicio.
Con los casos de uso descubiertos se modela el
comportamiento del sistema con los diagramas de
secuencia, mostrando para cada caso de uso los eventos que
generan los actores externos, su orden y eventos internos
del sistema. En la figura 3 se muestra el diagrama
correspondiente al caso de uso Proveer Servicios DIMSE,
el actor del lado izquierdo es el Invocador:SCU, que
solicita un servicio al proveedor Dimse1:DIMSE, éste a su
vez construye el mensaje y lo envía usando un servicio de
Dulp:DULP. Del lado derecho al recibirse el mensaje se
pasa al Ejecutor:SCP como una indicación de servicio, una
vez realizada la operación asociada con el servicio, el
Ejecutor emite una respuesta, Dimse2:DIMSE construye el
mensaje y lo envía a través de Dulp, Dimse1 lo recibe y
finalmente le confirma el servicio al Invocador
completándose el intercambio del mensaje.
interacción, los cuales ilustran cómo se comunican los
objetos para cumplir los requerimientos y posteriormente
se hace el diseño de diagramas de clase para resumir la
definición de las clases que serán implementadas.
Como diagramas de interacción se usaron los diagramas de
colaboración para mostrar el orden de ejecución de los
mensajes para realizar una operación. La asignación de
responsabilidades de los objetos que colaboran en estos
diagramas se hizo por medio de patrones GRASP (General
Responsibility Assignment Software Patterns).
Para obtener el diagrama de clases se examina el modelo
conceptual y los diagramas de interacción. La figura 4
muestra el diagrama de clases obtenido para el sistema
DIMSE.
PDV
<<Actor>>
DULP
VR
DIMSE
1
1
1
FORMATO
1 <<iterator>>
LISTA
1
1
MENSAJE
1 0..1
GRUPODATO
1
1
ELEMENTOCOMANDO
Invocador : SCU
Dimse1 :
DIMSE
Dulp : DULP
Dimse2 :
DIMSE
*
1
GRUPOCOMANDO
Ejecutor : SCP
Petición de servicio
Fig. 4. Diagrama de clases de DIMSE. No se muestran los atributos y
operaciones de las clases para simplificar el diagrama.
Construir mensaje
Enviar mensaje
(Servicio P-DATA)
Recibir mensaje
Indicación de servicio
Respuesta de servicio
Enviar mensaje
(Servicio P-DATA)
Recibir mensaje
Construir mensaje
Confirmación de servicio
Fig. 3. Diagrama de secuencia para el caso de uso Proveer Servicios DIMSE
El comportamiento de los casos de uso restantes se modela
de la misma manera.
Otro producto que se obtuvo dentro de la fase de análisis y
que ayuda también a definir comportamiento son los
contratos. Un contrato describe el efecto de las operaciones
sobre el sistema, y dichas operaciones se identifican de los
diagramas de secuencia. Las operaciones encontradas son:
Petición de servicio, Construir mensaje, Enviar mensaje,
Recibir mensaje, Indicación de servicio, Respuesta de
servicio y Confirmación de servicio. Se elaboró un contrato
para cada operación, conteniendo las siguientes partes:
Responsabilidades, Pre-condiciones y Post-condiciones.
Los contratos son el producto final del análisis y se
procede con la fase de diseño dentro del ciclo de desarrollo.
En la fase de diseño se busca una solución lógica, cuya
parte más importante es la creación de los diagramas de
La clase principal del diagrama se llama DIMSE,
representando al sistema total, las clases restantes son
colaboradoras para cumplir con la responsabilidad
principal de intercambiar mensajes entre Entidades de
Aplicación.
Con el diagrama de clases concluido se esta preparado para
entrar a la fase de construcción, la cual involucra la
implementación del diseño en software. Del diagrama de
clases se hizo la traducción de clases a código C++. La
implementación de los servicios DIMSE en este diseño se
consideran de manera implícita, dado que la clase DIMSE
tiene un único atributo de tipo buffer, el cual contiene
como primer elemento el nombre del servicio solicitado,
así como los parámetros requeridos por el servicio.
4. DISCUSIÓN
La división de DICOM en varias partes dificulta la
comprensión del mismo porque cada tema se aborda en
forma independiente de los demás. Aunado a ésto la
definición del estándar es escueta y dirigida a expertos del
tema. La aplicación de un proceso de desarrollo fue de
gran ayuda para comprender la parte de intercambio de
mensajes de DICOM.
La definición de requerimientos se realizó analizando la
parte 7 de DICOM, el diagrama de casos de uso presentado
fue el resultado de iterar los ciclos de desarrollo del
proceso, nos obligó a buscar y entender cada uno de los
eventos a los que el sistema debe responder, y se dio por
concluido cuando se fue capaz de explicar la funcionalidad
del sistema al usuario o experto de dominio y acordar que
cumple con todos los procesos del sistema.
El modelo conceptual permitió describir los conceptos
(objetos) principales y su relación para establecer, a un
nivel alto de abstracción, la forma en que se lleva a cabo el
intercambio de mensajes.
Para entender el comportamiento del sistema, los
diagramas de secuencia fueron de gran utilidad,
elaboramos muchos diagramas y fue a través de un
refinamiento sucesivo y de repasar el Estándar que se logró
establecer el diagrama que modeló correctamente el
sistema.
La asignación de responsabilidades en los diagramas de
colaboración por medio de GRASP fue una actividad
ineludible, teniendo gran efecto sobre la robustez,
mantenimiento y reusabilidad de los componentes de
software.
Del diagrama de clases se traduce mucha información
directamente a código y proporciona la definición de las
clases, los métodos de las mismas se toman de los mensajes
de los diagramas de colaboración, y el orden en que se dan
estos mensajes se traduce a una declaración de software en
un lenguaje de programación
5. CONCLUSIONES
DICOM es un estándar complejo, escrito en el lenguaje
árido de los estándares y con un mínimo de información
explicativa. No obstante, DIMSE fue comprendido
auxiliándose y apoyándose en la metodología propuesta por
el proceso de desarrollo de proyectos de software.
Un proceso de desarrollo define el punto de partida y la
secuencia de aplicación de las fases para un ciclo de
desarrollo, y permite obtener los productos necesarios para
crear un modelo de solución del dominio del problema.
La implementación del estándar DICOM es un proyecto de
gran alcance en el que se debe involucrar un grupo
interdisciplinario con experiencia en aspectos diversos,
ésto ha motivado que se divida. DIMSE es sólo la parte
encargada de suministrar los servicios para que una
implementación de DICOM intercambie un mensaje, se
comunica con su capa inferior que es DULP, usando los
servicios de éste para enviar los mensajes. DULP es la
parte con la que iniciamos nuestro proyecto de
implementación de DICOM, y actualmente estamos
codificando ambos protocolos con la finalidad de
acoplarlos y probar sus interfaces e interoperabilidad.
AGRADECIMIENTOS
Agradecemos la colaboración y sugerencias de la Dra.
Hanna Oktabba durante la aplicación del proceso de
desarrollo en el presente trabajo. Agradecemos también al
CONACyT el financiamiento de este proyecto, apoyo No.
400200-S-29290ª
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
S. W. Ambler, The Unified Modeling language v1.1 and Beyond:
The
Techniques
of
Object-Oriented
Modeling,
http://www.ambysoft.com/umlAndBeyond.pdf, 1997.
E. V. Berard, Be Careful With “Use Cases”, The Object Agency,
Inc., 1995.
G. Booch, Object Solutions: Managing the Object-Oriented Project,
Addison-Wesley, 1996.
G. Booch, Análisis y diseño orientado a objetos con aplicaciones,
Addison-Wesley/Diaz de Santos, 1996.
I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software
Development Process, Addison-Wesley, 1999.
I. Jacobson, Object-Oriented Software Engineering: A Use Case
Drive Approach, Addison-Wesley, 1992.
C. D. Land, V. Lashin, A. Oriol, J. J. Villanueva, Object-oriented
Design of the DICOM Standard and its Application to
Cardiovascular Imaging, http://www.cvc.uab.es/~craig/dicom/oodicom.htm.
C. Larman, Applying UML and Patterns. An Introduction to ObjectOriented Analysis and Design, Prentice Hall PTR, 1998.
D. F. Leotta, Y. Kim, “Requirements for Picture Archiving and
Communications. Electronic Handling of Image Data Needs Clinical
Acceptance for Success”, IEEE Engng in Med and Biol, pp. 62-69,
March 1993.
NEMA Standards Publication PS 3.7-1993. Digital Imaging and
Communications in Medicine (DICOM) Part 7: Message Exchange,
National Electrical Manufacturers Association, 1994.
NEMA Standards Publication PS 3.8-1993.
B. Revet, “DICOM Cook Book for Implementations in
Modalilities”, Philips Medical Systems Nederland B. V., Version 1.1,
January 1997.
C. H. Steven, F. W. Prior, W. D. Bidgood, C. Parisot, G. Claeys,
DICOM:
An
Introduction
to
the
Standard,
http://www.dicomanalyser.co.uk/html/introduction.htm.
The Fundamentals of DICOM, Healt Imaging Division, Eastman
Kodak Company, Cat. No. 885 5959, 1996.
DICOM MESSAGE EXCHANGE
ABSTRACT
The development of storage systems and transferring of medical images (PACS) has urged a definition of a
communication standard (DICOM). This standard requires a message exchange protocol (DIMSE) used for two
application entities in order to interchange images and information. In this work, a DIMSE protocol is described
and applied to a software development process. The promising results obtained might help to propose a solution
model able to deliver DIMSE services demanded by the users. Process testing indicates that DIMSE model can
meet the DIMSE shell requirements. Therefore, this DIMSE methodology is capable to generate an easy-tomaintain and robust model for information exchange.
Keywords: object model, development process, use case, interaction diagrams, class diagrams.