Enlace Hispanoamericano de Salud: Aplicaci�n del software libre en Cooperaci�n al Desarrollo

Se han dado numerosas razones para utilizar y desarrollar software libre en pa�ses en desarrollo y, en particular, en proyectos de desarrollo, pero, la realidad indica que su aplicaci�n es a�n limitada, por diversas razones, entre las que cabe destacar el bajo nivel educativo en inform�tica, el monopolio de formatos en ofim�tica, y el recurso masivo a la copia ilegal. Como en todas partes, su introducci�n empieza all� donde su uso es, sin posibilidad de discusi�n, la mejor soluci�n t�cnica y econ�mica.

Este es el caso de las soluciones que desarrolla el programa Enlace Hispano Americano de Salud (EHAS[15]), liderado por el Grupo de Bioingenier�a y Telemedicina de la Universidad Polit�cnica de Madrid, en su vertiente de investigaci�n y desarrollo, y por la ONG Ingenier�a Sin Fronteras, en su vertiente de realizaci�n de proyectos. Cuenta con la participaci�n de universidades e instituciones p�blicas en Per�, Colombia y Cuba y es apoyado financieramente por el Plan Nacional de I+D+I, Colciencias, Concytec, AECI, CYTED, el programa InfoDev del Banco Mundial, y Comit� de Cooperaci�n y Solidaridad de la Universidad Polit�cnica de Madrid, entre otros.

El programa EHAS parte del estudio de necesidades de personal sanitario en regiones aisladas de Per� y Nicaragua, as� como de sus condicionantes en comunicaciones y energ�a. Si bien cada zona estudiada es diferente, el mayor problema es la incomunicaci�n f�sica, ya que en algunos casos el t�cnico sanitario puede llegar a necesitar varios d�as de viaje para acceder a su centro sanitario de referencia, del que depende. Sin llegar a intentar resolver el problema f�sico, la telecomunicaci�n es el veh�culo obvio para paliar el aislamiento personal y profesional, pudiendo facilitar las consultas profesionales, la formaci�n, el intercambio de informes, la coordinaci�n de emergencias, el pedido de medicamentos, etc. Las razones para no disponer de un servicio de telecomunicaciones apropiado son el desinter�s de las operadoras en las zonas aisladas, el escaso presupuesto de los puestos de salud, la baja formaci�n de los t�cnicos sanitarios, especialmente en relaci�n con el uso de la inform�tica, la ausencia de una fuente de energ�a el�ctrica apropiada, y condiciones ambientales extremas.

Tras establecer las condiciones necesarias para llevarlo a cabo, entre los a�os 2000 a 2002 se ha puesto en marcha un proyecto piloto en la provincia de Alto Amazonas del departamento de Loreto en Per�, con objeto de demostrar una soluci�n de bajo coste y evaluar su impacto. Dicho proyecto involucra al Hospital Provincial de la capital, Yurimaguas, y a 40 establecimientos de salud de dos categor�as: centros de salud y puestos de salud. Los centros de salud est�n dotados de varias personas, al menos una de ellas m�dico, y suelen tener tel�fono y grupo electr�geno, funcionando algunas horas al d�a. Los puestos de salud dependen de los anteriores y s�lo cuentan con una persona de formaci�n limitada y carecen de tel�fono y cualquier fuente de energ�a. El mapa que sigue muestra el �rea de intervenci�n, con los centros marcados con cuadrados rojos y los puestos como puntos de color.

La experiencia obtenida con este proyecto ha dado pie para definir otros nuevos en distintos escenarios, con la misma tecnolog�a mejorada o con otras distintas. A continuaci�n se describen las tecnolog�as utilizadas, haciendo hincapi� en el software libre empleado, modificado o construido.

En zonas como Alto Amazonas, con establecimientos separados decenas de kil�metros, sin tel�fono, la infraestructura m�s sencilla y usada para comunicar los puestos de salud con su centro de salud es la radio VHF, ya que su alcance puede ser del orden de 50 Km, limitado por la potencia de transmisi�n y la altura de las antenas, que deber�n compensar la curvatura de la tierra y salvar los obst�culos, aunque tiene bastante tolerancia a los mismos. Se eligen pues en estos casos radios VHF convencionales que se utilizan normalmente para voz, pero que, intermitentemente, pasan a intercambiar datos entre un ordenador cliente en el puesto de salud y un servidor situado en su centro de salud de referencia. Una instalaci�n solar en el puesto de salud alimenta la radio y el ordenador cliente, as� como otros aparatos auxiliares (modem radio, luminarias, etc). Los centros de salud disponen de un cargador de bater�as para alimentar el servidor las horas necesarias, aunque el grupo electr�geno est� apagado, ya que s�lo se enciende a la puesta del sol, durante unas cuatro horas. El servidor a su vez se comunica intermitentemente con internet a trav�s del tel�fono o, en algunos casos, a trav�s de un terminal VSAT. En las fotos siguientes se ven las antenas de VHF de un centro de salud y un puesto de salud, �ste con su placa solar.

En zonas muy aisladas, VHF no se puede utilizar. En estos casos puede utilizarse HF (onda corta) por reflexi�n ionosf�rica, salv�ndose distancias de centenares o miles de kil�metros. Lamentablemente en HF tenemos enlaces de peor calidad y con mucha variabilidad en cortos intervalos de tiempo, adem�s de que s�lo puede usarse a ciertas horas, dependiendo del canal, y con protocolos y modulaciones especiales. Luego examinaremos brevemente las soluciones propuestas para HF.

Otra soluci�n explorada para zonas muy aisladas ha sido la utilizaci�n de sat�lites de baja �rbita (LEO). Estos sat�lites no son geoestacionarios, pero pueden utilizarse cuando pasan por encima de un punto para intercambiar ficheros con muy baja energ�a. Los principales inconvenientes son que no pueden utilizarse para voz y dependen de microsat�lites compartidos de vida incierta. Ciertamente podr�a usarse la moderna telefon�a satelital en la mayor�a de los lugares, pero los costes actuales resultan excesivos.

Finalmente tambi�n se est� explorando la aplicabilidad de la tecnolog�a de redes locales inal�mbricas en microondas (IEEE 802.11b) en diversos escenarios. Con las regulaciones vigentes en Hispanoam�rica se pueden conseguir enlaces de decenas de kil�metros a potencias muy bajas, con un ancho de banda mucho mayor que las soluciones anteriores, lo que abre el camino a aplicaciones muy diferentes. Su mayor inconveniente es la necesidad de que no haya obst�culo alguno entre los puntos a comunicar, algo muy caro de conseguir en selva, por ejemplo. No obstante se est� explorando la posibilidad de construir repetidores activos aut�nomos de bajo costo, lo que facilitar�a su aplicaci�n en ese �mbito.

Excepto en el caso de las redes inal�mbricas en microondas, vemos que las soluciones propuestas se basan en conexiones intermitentes de bajo ancho de banda y utilizando medios diversos. Por ello todas las aplicaciones contempladas se construyen a trav�s de correo electr�nico, ya sea interpersonal, ya entre programas. As� los mensajes pueden atravesar distintos medios (radio VHF o HF, conexiones telef�nicas a veces de mala calidad, o almac�n intermedio en sat�lites LEO) sin problemas.

Llamamos microrred VHF a una red formada por varios puestos de salud que dependen de un centro de salud, en el cual se dispone de acceso a Internet, ya sea intermitente (RTC) o permanente (VSAT). La comunicaci�n entre puestos y centro es por medio de las radios VHF que tambi�n se utilizan para voz. En principio s�lo es necesaria una interacci�n cliente servidor entre los puestos y el centro, y este hecho permite reducir el coste de las infraestructuras necesarias, especialmente las instalaciones a�reas (conjunto torre-antena) y energ�ticas (alimentaci�n solar), como luego veremos.

En Alto Amazonas las condiciones locales impusieron que los clientes fueran m�quinas port�tiles MS-Windows, lo que condicion� la soluci�n adoptada y ocasion� no pocas dificultades, debido al car�cter cerrado de la plataforma y del software auxiliar, as� como por lo limitado de la arquitectura y su vulnerabilidad. La foto muestra el uso de uno de esos clientes.

Los servidores en cambio fueron m�quinas Debian GNU/Linux realizadas con componentes PC/104[12], de bajo consumo y gran robustez y fiabilidad. La foto muestra el interior de uno de estos servidores, con su radio y modem.

Para comunicar v�a radio clientes y servidores se utiliza el protocolo AX.25[1], una adaptaci�n de X.25 realizada por radioaficionados y de la que existe un par de implementaciones libres para Linux y varias implementaciones cerradas, aunque gratuitas en nuestra aplicaci�n, para Windows.

Como las aplicaciones de correo para Windows utilizan protocolos POP y SMTP directamente, fue preciso implementar estos servicios de alguna manera sobre AX.25. En general, sea cual sea la plataforma, parece buena idea implementar protocolos de aplicaci�n est�ndar de Internet, ya que de ese modo todos los programas dise�ados para internet funcionar�n directamente. Sin embargo, esto ocasiona dificultades e ineficiencias, por lo que para estaciones de trabajo Linux preferimos utilizar el venerable uucp de Ian L. Taylor[5], paquete libre que ya usamos sobre TCP para intercambiar correo entre los centros de salud y el conmutador central, situado en la Universidad Cat�lica de Lima para el piloto de Alto Amazonas. Dicho paquete soporta diversos protocolos para distintos tipos de conexiones, permite reanudar transferencias abortadas, y es eficiente, pudi�ndose montar sobre �l paquetes comprimidos con bsmtp[10].

Con HF ya no son necesarias microrredes, ya que generalmente las estaciones clientes pueden alcanzar directamente un servidor en una capital bien conectada. Sin embargo el canal HF tiene caracter�sticas que hacen dif�cil trabajar con �l, por lo que los modems de HF son extraordinariamente caros, o muy lentos (t�picamente de 100 a 300 bps para los de radioaficionados). Para aprovechar el escaso espectro disponible, los canales suelen ser de 3 KHz y la modulaci�n en banda lateral �nica, mucho menos robusta que la FM y sometida adem�s a desvanecimientos ocasionados por las incertidumbres de la propagaci�n ionosf�rica.

Gran parte del trabajo desarrollado para VHF sirve para HF (por ejemplo el mecanismo DAMA de control de acceso al medio en AX.25). Sin embargo la mala calidad del canal hizo necesario trabajar m�s en profundidad la modulaci�n, as� como mejorar el protocolo AX.25 para soportar mejor muchas p�rdidas de paquetes. La ausencia de fuentes para Windows determin� que la estaci�n de trabajo fuera Linux, pudi�ndose intervenir en modificaciones incompatibles con el est�ndar AX.25 y en los modems de tarjeta de sonido.

La modificaci�n m�s importante se hizo sobre un modem (newqpsk) a�adido por Tomi Manninen al paquete de modems para tarjeta de sonido en espacio de usuario de Thomas Sailer (soundmodem). Dicho modem, basado a su vez en otro de Pawel Jalocha, usa 15 portadoras moduladas en DQPSK, entrelazado de bits para luchar contra los errores de r�fagas, y c�digos autocorrectores. En �l se sustituy� el c�digo autocorrector por turboc�digos convolucionales[3], adaptando y optimizando un dise�o de Mathys Walma, adem�s de otras modificaciones, consigui�ndose alcanzar velocidades alrededor de los 2000 bps, seg�n la calidad del canal. Como se ve, este m�dulo es un ejemplo de la conveniencia del modelo de desarrollo de software libre.

Otra modificaci�n importante fue la retransmisi�n selectiva de paquetes en AX.25, algo muy necesario en un entorno tan sensible a errores. La modificaci�n introducida no es compatible con el est�ndar, ya que permite enumerar exactamente qu� paquetes se han recibido mal, adem�s de indicar el �ltimo correctamente recibido. De esta forma, s�lo se retransmiten los necesarios con ventanas de transmisi�n que siempre contienen el m�ximo n�mero de paquetes posible.

Finalmente se configur� uucp para funcionar directamente sobre AX.25, a trav�s del protocolo y, apto para canales semiduplex libres de errores. Por encima, el agente de transferencia de correo (postfix, de Wietse Venema[9]) se configur� para usar un transporte BSMTP sobre uucp. BSMTP crea paquetes comprimidos a partir de varios mensajes, que son enviados como ficheros de tama�os parecidos.

Tambi�n se ha contemplado el posible uso de microsat�lites de baja �rbita, que son visibles varias veces al d�a durante unos minutos, momento que se puede aprovechar para intercambiar mensajes con ellos. Estos sat�lites tambi�n fueron dise�ados por radioaficionados, aunque existen sat�lites que usan la misma tecnolog�a con fines comerciales y de cooperaci�n al desarrollo (Vitasat, Healthsat). Suelen tener transmisores en la banda de UHF y receptores en VHF operando protocolos de difusi�n y trasferencia de ficheros montados sobre AX.25 y conocidos como protocolos PACSAT[6].

En este caso lo que se hizo fue crear un agente de transporte para correo electr�nico utilizando los protocolos PACSAT, y conect�ndolo adecuadamente a un agente de transferencia (en nuestro caso a sendmail de Allman[11], pero vale para cualquier otro). Para ello se extrajeron porciones de un programa libre interactivo llamado pb-pg[14] para extraer las porciones relativas al protocolo.

Uno de los problemas de este sistema es la necesidad de apuntar antenas m�viles y la de corregir la frecuencia de la radio para compensar el desv�o ocasionado por el efecto Doppler. Adem�s del coste de los equipos controlados, es necesario un sistema de previsi�n de �rbitas. Los mismos sat�lites env�an peri�dicamente esas previsiones, pero es mucho m�s conveniente no tener que usarlas, para lo que se han desarrollado antenas fijas y modificaciones de radios.

La infraestructura montada con los componentes antes descritos, acompa�ada de algo de organizaci�n y mucho de formaci�n, sirve ya para mejorar la calidad asistencial de los establecimientos de salud aislados. Sin embargo es conveniente desarrollar aplicaciones que den valor a�adido a las redes construidas. Por ejemplo, puede ser muy �til facilitar la cumplimentaci�n de informes epidemiol�gicos que puedan servir al sistema de salud para reaccionar adecuadamente a los brotes epid�micos.

Actualmente se est� desarrollando en el piloto de Alto Amazonas un programa de formaci�n en el que la Universidad Peruana Cayetano Heredia, contraparte m�dica del proyecto en el Per�, prepara cursos que se dividen en lecciones que se env�an por correo electr�nico como mensajes en HTML con im�genes. Este m�todo, si bien no requiere ninguna herramienta adicional, es poco conveniente para editores y alumnos, por lo que para futuros proyectos del programa EHAS se est�n desarrollando una serie de herramientas que nos permiten definir cursos en XML de forma abstracta, transform�ndolos con posterioridad por medio de hojas de estilo XSLT, con ayuda de motores XSLT libres como Saxon[13].

El software libre nos ha permitido desarrollar r�pidamente con pocos recursos un conjunto de soluciones de bajo coste para mejorar las condiciones de vida en zonas aisladas y desfavorecidas. Tambi�n ha ayudado el car�cter abierto de la comunidad de radioaficionados. En los casos en que se ha tenido que usar software comercial, las dificultades han sido mayores, ya que se han tenido que soslayar los problemas que su car�cter cerrado imped�a resolver m�s directamente. Esperamos que el trabajo realizado y por venir ayude a los sistemas p�blicos de salud de pa�ses en desarrollo, algunos de los cuales son plenamente conscientes de la importancia estrat�gica del software libre, a desplegar soluciones econ�micas, eficaces y controladas por ellos.