OsiriX y su XML-RPC - Parte I

Desde el año pasado que estoy trabajando en modificar un plugin para un sistema que ocupa Link La verdad me he demorado por diferentes razones. En si el codigo es limpio y claro, a si que eso no es el problema.

La idea es que este sistema que ocupa Link soporte no solamente Windows, sino tambien OS X (y por que no en un futuro linux). El hecho es que el visualizador mas conocido (al parecer) es Link. Es de codigo abierto y soporta plugins.

En si es un visualizador muy completo, sobre todo por el sistema de plugins que tiene. Hay una sección en la propia pagina de OsiriX en donde te "Enseñan" a programar tus propios plugins para hacerlos funcionar con el visualizador. El punto es que como en la mayoria de las documentaciones existentes sobre sistemas de plugins o API's, es BASTANTE incompleta.

Basicamente a mi me interesaba comunicarme desde otro plugin (Java) a OsiriX y para hacer esto, una de las opciones (y las mas viables en ese momento) era ocupar Link y justo, este visualizador permitia hacer una llamada (que era la interesada) via Link.

A grandes rasgos necesitaba que cuando un usuario llamara a OsiriX con un ID - este ID representa un estudio dentro del PACS - OsiriX mostrara el estudio en cuestion.

Aqui hay 2 grandes temas:

1. El estudio puede encontrarse localmente. Mostrarlo es facil.
2. El estudio no esta localmente, por ende hay que ir a buscarlo al PACS.

Obviamente, la opcion 1 es la mas facil.

Para la 1 simplemente hacemos una llamada via XML-RPC con el metodo DBWindowFind que nos devulve el estudio que esta localmente.

El problema comienza cuando no esta localmente, osea 2. Hay que hacer una llamada completamente diferente, CMove es la llamada y de parametros, hay que pasarle el ID y el servidor PACS (que TIENE que estar configurado en OsiriX). en donde esta el estudio.

Para el que no sepa que es CMove, es simplemente una de las diferentes operaciones que se usan cuando se esta trabajando con PACS y imagenes DICOM. Basicamente trae el estudio (conjunto de Imagenes DICOM) al equipo que lo esta pidiendo.

Ahora, el problema es que al hacer la implementacion en Java (que realizaba estas 2 peticiones) OsiriX se colgaba hasta obtener el estudio (si es que lo llegaba a obtener) entonces no sabiamos de el progreso de la transferencia, y la verdad es un poco "antinatural" hacer 2 peticiones XML-RPC a OsiriX para obtener 1 mismo estudio.

A si que la opcion no estaba en seguir pidiendo los estudios via los 2 metodos XML-RPC. Sino en hacer un plugin XML-RPC propio que fuera capas de identificar si el estudio solicitado exisitia,  si  exisite lo abre, si no existe lo baja y luego lo muestra.

En la proxima entrada explicare los pasos basicos para programar un plugin para OsiriX.