1.4.2. Comprendiendo la independencia de plataforma

Todas las computadoras tienen un Sistema Operativo (SO) para manejarlas y manejar los programas instalados. El sistema operativo sirve como nivel intermedio entre la aplicacion software, como DHIS2, y el hardware, como la CPU o la memoria RAM. DHIS2 funciona en la Maquina Virtual de Java, y por eso puede funcionar en cualquier sistema operativo que soporte Java. La independencia de plataforma significa que la aplicacion software puede ejecutarse en cualquier SO: Windows, Linux, Macintosh, etc. DHIS2 es independiente de plataforma, y es extremadamente util en el contexto de salud publica, donde pueden estar en uso multiples sistemas operativos distintos.

Mas alla, DHIS2 es tambien independiente de plataforma en relacion al Sistema de Gestion de Base de Datos. DHIS2 utiliza el entorno de abstraccion de bases de datos Hibernate y es compatible con cualquier sistema soportado por Hibernate, como PostgreSQL, MySQL, H2, MS SQL Server, Oracle y muchos otros. Postgre SQL es el sistema de base de datos recomendado para DHIS2.

1.4.3. Estrategias de despliegue - conectado (online) o desconectado (offline)

DHIS2 es una aplicacion en red y puede ser accedida a traves de Internet, en una Intranet local y como un sistema instalado localmente. Las alternativas de despliegue de DHIS se definen en este capitulo como (1) despliegue off line (desconectado) (2) despliegue online (conectado) y (3) despliegue hibrido. El significado de cada una y las diferencias entre ellas se detallan en las secciones siguientes.

1.4.3.1. Despliegue Offline (Desconectado)

Un despligue offline implica que instalamos muchas instancias autonomas off line para los usuarios finales, generalmente a nivel de distrito. El sistema lo mantienen principalmente los usuarios, trabajadores de salud en distrito, que introducen los datos y generan reportes utilizando su servidor local. Tipicamente hay tambien un equipo de super usuarios a nivel nacional que mantiene el sistema y realizar visitas regularmente a los despliegues en distritos. Los usuarios envian los datos hacia arriba en la jerarquia produciendo ficheros de intercambio de datos que se envian electronicamente por email o fisicamente por correo convencional o viajes del personal. Notemos que aunque haya una conexion reducida a Internet para enviar emails, puede no ser suficiente para que el sistema sea online. Esta forma de despliegue tiene el beneficio claro de que funciona cuando no disponemos de una conectividad de Internet apropiada. Por otro lado hay algunos retos significativos en esta forma de despliegue, que se describen a continuacion.

·          Hardware: Tener en funcionamiento sistemas autonomos requiere un hardware mas avanzado en terminos de instalar servidores y suministro electrico fiable, generalmente a nivel de distrito, en todo el pais. Esto requiere una financiacion apropiada para la adquisicion de equipos y la planificacion de mantenimiento a largo plazo.

·          Plataforma software: Las instalaciones locales implican una necesidad importante de mantenimiento. De la experiencia de HISP, el mayor reto son los virus y otros malware que tienden a infectar las instalaciones locales a largo plazo. La razon principal para esto es que los usuarios utilizan dispositivos de memoria externa USB para transportar los ficheros de intercambio de datos y documentos entre computadoras privadas, otras computadoras de red y el sistema en el que funciona la aplicacion DHIS. Mantener software antivirus y parches de sistema operativo actualizados en un entorno off line es dificultoso y una mala practica en terminos de seguridad muy comun entre los usuarios. Tal vez la mejor manera de evitar esto es lanzar un servidor dedicado para la aplicacion donde no se utilicen memorias externas y se utilice un sistema operativo basado en Linux, que no sea susceptible de infecciones de virus como lo es MS Windows.

·          Aplicacion software: Ser capaces de distribuir nuevas funcionalidades y resolucion de bugs a los usuarios del software de informacion de salud es esencial para el mantenimiento y la mejora progresiva del sistema. Delegar en los usuarios finales la tarea de actualizar el software implica que ellos reciban una formacion extensiva y un altisimo nivel de competencias de aquel lado, ya que las actualizaciones software pueden incluir alguna tarea tecnicamente arriesgada. Delegar en el equipo nacional de superusuarios la tarea de mantener el software directamente, implicara muchos viajes.

·          Mantenimiento de la base de datos: Un requisito previo para lograr un sistema eficiente es que todos los usuarios introduzcan datos con un set estandarizado de metadatos (elementos de datos, formularios, etc.). Aqui sucede algo parecido al punto anteriormente comentado sobre actualizaciones de software: la distribucion de cambios en el set de metadatos en gran numero de instalaciones off line requiere usuarios finales muy competentes si las actualizaciones se envian digitalmente o bien un equipo de superusuarios muy bien organizado. Si hay un fallo al mantener la sincronizacion del set de metadatos, conllevara la perdida de capacidad para enviar datos desde los distritos y/o una base de datos nacional inconsistente, ya que los datos introducidos por ejemplo a nivel de distrito, no seran compatibles con los datos a nivel nacional.

1.4.3.2. Despliegue Online (Conectado)

Un despliegue online implica que una sola instancia de la aplicacion DHIS se instala en un servidor conectado a Internet. Todos los usuarios (clientes) se conectan con el servidor central online a traves de Internet utilizando un navegador web. Este estilo de implementacion suele beneficiarse de las grandes inversiones y extensiones de las redes de comunicaciones de acceso: moviles (celular) y de banda ancha en paises en desarrollo. Esto posibilita el acceso a servidores online incluso en las areas mas rurales utilizando modems de Internet movil (tambien llamadas dongles).

Esta forma de despliegue online tiene implicaciones muy positivas en el proceso de implementacion y en el mantenimiento de la aplicacion en comparacion con el estilo tradicional desconectado:

·          Hardware: Los requisitos hardware del lado del usuario se limitan a una computadora o portatil (laptop) razonablemente modernos, y conexion a Internet a traves de linea fija o modem celular. No hay necesidad de tener servidores especializados del lado del usuario, sino que cualquier computadora que pueda navegar es suficiente.

·          Plataforma software: Los usuarios solo necesitan un navegador web para conectarse al servidor online. Hoy en dia todos los sistemas operativos populares vienen con un navegador web ya instalado y no hay ningun requisito especial sobre que tipo o version de navegador. Lo que esto significa es que si hay problemas graves como infecciones de virus o corrupcion del software en esa computadora, siempre podremos recurrir a reformatear e instalar de nuevo el sistema operativo o comprar una computadora nueva. En tal caso, el usuario podra seguir introduciendo datos donde lo dejo y no se habra perdido ningun dato.

·          Aplicacion software: El estilo de despliegue online, es decir, basado en un servidor central, significa que podemos actualizar y mantener la aplicacion de manera centralizada. Cuando salen nuevas versiones de DHIS con nuevas funcionalidades y resoluciones de bugs, esto puede aplicarse unicamente al servidor online. Y todos los cambios se reflejaran en el lado del cliente la proxima vez que los usuarios se conecten al servidor a traves de Internet. Obviamente, esto tiene un impacto enormemente positivo en el proceso de mejorar el sistema ya que las nuevas funcionalidades se distribuyen inmediatamente a los usuarios, todos los usuarios estaran siempre accediendo a la misma version de la aplicacion, y los bugs y complicaciones pueden resolverse e implantarse al momento.

·          Mantenimiento de la base de datos: De forma similar al punto anterior, los cambios en los metadatos se hacen en el servidor online de forma centralizada y se propagan automaticamente a todos los clientes la proxima vez que se conecten al servidor. Esto efectivamente elimina los vastos problemas relacionados con mantener un set de metadatos actualizado y estandarizado, como sucede en el despliegue off line. Por ejemplo es muy conveniente este estilo durante la fase inicial de desarrollo de la base de datos y durante los procesos anuales de revision de la base de datos, ya que los usuarios estaran accediendo a una base de datos consistente y estandarizada incluso cuando en ella se estan produciendo cambios frecuentes.

Este enfoque puede ser problematico en los casos en los que la conexion a Internet es volatil o insuficiente durante largos periodos de tiempo. Sin embargo, DHIS 2 dispone de algunas caracteristicas que permiten que el requisito de conexion a Internet solo sea necesario en momentos concretos para que el sistema funcione bien, como la herramienta MyDatamart que se explica en un capitulo especifico de este Manual.

1.4.3.3. Despliegue Hibrido

De la discusion de los puntos anteriores, uno puede darse cuenta de que el estilo de despliegue online es mas favorable que el despliegue desconectado, pero requiere conexion a Internet alla donde se use. Es importante tomar en cuenta que los estilos mencionados tambien pueden coexistir en un un despliegue comun. Es perfectamente factible tener despliegues online y offline en un mismo pais. La norma general seria que los distritos y establecimientos deberian acceder al sistema online a traves de Internet siempre que exista conexion suficiente, y habra sistemas off line en aquellos distritos donde no se de el caso.

Es dificil definir con precision como es una conexion a Internet suficiente pero podemos poner como regla practica que la velocidad de descarga deberia ser minimo 10 Kbyte/seg y la disponibilidad deberia ser como minimo el 70% del tiempo.

En este sentido los modems de Internet por celular que se puedan conectar a una computadora o portatil para acceder a la red celular son una solucion factible y suficiente. La cobertura de Internet movil esta aumentando rapidamente en todo el mundo, con frecuencia ofreciendo una conectividad buena a precios asequibles y es una alternativa a las redes locales y poco mantenidas de lineas fijas de Internet. Puede resultar un esfuerzo que vale la pena el contactar con las compañias de red movil nacional y negocias suscripciones de postpago y beneficios potenciales de economia de escala. Es conveniente estudiar la cobertura de red para cada operador de red de telecomunicaciones en el pais concreto, a la hora de decidir que tipo de despliegue arrancar, ya que podra ser diferente en distintas regiones del pais.

1.4.3.4. Alojamiento del servidor

El enfoque de despliegue online plantea la cuestion de donde y como alojar el servidor que ejecutara la aplicacion DHIS2. Tipicamente hay varias opciones posibles:

·          Alojamiento interno en el Ministerio de Salud

·          Alojamiento en un centro gubernamental de datos

·          Alojamiento a traves de una compañia externa de hosting

La razon principal para elegir la primera de las opciones es a menudo la motivacion politica de tener "propiedad fisica" de la base de datos. Muchos perciben esto como algo importante de cara a "poseer" y controlar los datos. Existe tambien el deseo de desarrollar capacidad local para la administracion del servidor relacionada con la sostenibilidad del proyecto. Esto suele darse en iniciativas lideradas por donantes que perciben asi la mision mas concreta y servicial.

En cuanto a la segunda opcion, en algunos lugares se construye un centro gubernamental de datos con la vision de promover y mejorar el uso y acceso a los datos publicos. Otra razon puede ser que la proliferacion de entornos internos de servidos demanda muchos recursos y es mas eficiente establecer una infraestructura y capacidad centralizadas.

Sobre el alojamiento externo, hay recientemente un movimiento hacia la externalizacion de la operacion y administracion de recursos informaticos a proveedores externos, donde se accede a esos recursos a traves de la red, en lo que se llama popularmente "cloud computing" o "computacion en la nube". Esos recursos generalmente se acceden a traves de Internet utilizando un navegador Web.

El objetivo primordial de un despliegue de servidor online es proporcionar un acceso estable a largo plazo y de alto rendimiento a los servicios ofrecidos. Cuando decidamos que opcion elegir para un entorno de servidor, deberemos considerar varios aspectos:

1.       La capacidad humana de administracion y operacion del servidor. Debe haber personal con habilidades genericas para la administracion de servidor y en las tecnologias especificas de la aplicacion que provee servicios. Ejemplos de estas tecnologias son los servidores Web y las plataformas de gestion de bases de datos.

2.       Soluciones fiables para copias de seguridad automatizadas, incluido un servidor local off y backup remoto.

3.       Conectividad estable y buen ancho de banda para el trafico hacia y desde el servidor.

4.       Fuente de alimentacion electrica estable, incluida una solucion de backup.

5.       Entorno seguro para el servidor fisico en terminos de acceso, robo y fuego.

6.       Presencia de un plan de recuperacion ante desastres. Este plan debe contener una estrategia realista para asegurar que el servicio solo sufrira caidas breves en los casos de fallo hardware, caida de la red y otros.

7.       Hardware viable, potente y robusto.

Todos estos aspectos deben cubrirse para crear un entorno de alojamiento apropiado. El requisito hardware se ha puesto en ultimo lugar deliberadamente debido a que hay una tendencia clara a prestarle demasiada atencion, habiendo otros factores mas cruciales.

Volviendo a las tres principales opciones de alojamiento, la experiencia de misiones de implementacion en paises en desarrollo sugiere que los aspectos citados rara vez estan presentes en las opciones uno y dos a nivel viable. Alcanzar un nivel aceptable en todos esos aspectos es desafiante en terminos de recursos humanos y dinero, especialmente al comparar con la tercera opcion. Tiene el beneficio de que acomoda los aspectos politicos mencionados y crea capacidades locales para la administracion de servidor, aunque por otro lado esto se puede lograr por otras vias.

La opcion tres - alojamiento externo - tiene la ventaja de que soporta todos los aspectos mencionados a un coste asequible. Muchos proveedores de hosting - de servidores virtuales o de servicios en la nube - ofrecen servicios fiables para lanzar la mayoria de aplicaciones posibles. Un ejemplo de estos proveedores son los servidores web de Linode y Amazon. La administracion de esos servidores se realiza a traves de una conexion de red, lo que sucede tambien muchas veces en el caso de la administracion de un servidor local. La ubicacion fisica del servidor en este caso es irrelevante ya que esos proveedores ofrecen servicios en muchas partes del mundo. Esta solucion se esta convirtiendo en un estandar para el alojamiento de los servicios de aplicaciones. El aspecto de crear capacidad local para la administracion de servidor es compatible con esta opcion ya que un equipo local TIC puede asumir la tarea de mantenimiento del servidor alojado externamente.

Una alternativa para combinar las ventajas del alojamiento externo con la necesidad de hosting local y propiedad fisica es usar un proveedor de hosting externo para el sistema de transaccion primario, y copiar (mirror) este servidor a un servidor local no-critico que se use para solo-lectura como el analisis de datos y que se acceda por una Intranet.

1.5. Diferencias entre datos agregados y datos de paciente en un SIS

Los datos de paciente son datos relativos a un paciente individual, como son su diagnostico, nombre, edad, historial medico previo, etc. Estos datos generalmente se basan en la interaccion individual entre el paciente y el trabajador de salud. Por ejemplo, cuando un paciente visita un centro de salud pueden registrarse gran variedad de detalles, como la temperatura del paciente, su peso, y diversos tests sanguineos. Si este paciente obtiene un diagnostico de "Anemia deficiente Vitamina B12, no especificado" correspondiente al codigo CIE-10 D51.9, esta interaccion concreta puede registrarse como una instancia de "Anemia" en un sistema de informacion agregada. Los datos de paciente son importantes cuando queremos hacer un seguimiento longitudinal del progreso de un paciente en el tiempo. Por ejemplo, si queremos seguir como un paciente se adhiere y responde a un proceso de tratamiento de TB (que generalmente tiene una duracion de 6-9 meses), necesitaremos informacion de datos de paciente.

Los datos agregados son la consolidacion de datos relativos a multiples pacientes, y por tanto no se puede rastrear el origen de los datos de un paciente concreto. Se trata generalmente de conteos, como la incidencia de Malaria, TB y otras enfermedades. Tipicamente, los datos rutinarios con los que trabaja un establecimiento de salud so este tipo de estadisticas agregadas, y se utilizan para la generacion de reportes e indicadores rutinarios, y lo que es mas importante, para la planificacion estrategica en el sistema de salud. Los datos agregados no pueden proporcionar el tipo de informacion detallada que dan los datos de nivel de paciente, pero es crucial para la planificacion y orientacion del funcionamiento de los sistemas de salud.

Digamos que entre unos y otros se encuentran los datos relativos a casos, o datos anonimos "de paciente". Es posible recoger numerosos detalles sobre el evento especifico de salud sin necesidad de identificar al paciente involucrado. Las visitas de pacientes externos o internos, un nuevo caso de colera, mortalidad materna, etc. son casos de uso comunes cuando queremos recopilar muchos mas detalles que el mero conteo del numero total de casos o visitas. Estos datos normalmente se registran en formularios en forma de listado, o en formularios de auditoria mas detallados. Y estos datos de casos son diferentes de los datos agregados en el sentido de que contienen muchos detalles sobre un evento concreto, mientras que los datos agregados simplemente contarian cuantos eventos se producen de un cierto tipo, por ejemplo, cuantas visitas externas con diagnostico principal "Malaria", o cuantas muertes maternas donde la fallecida no siguio el protocolo ANC, o cuantos brotes de colera en niños menores de 5 años. En DHIS2 estos datos son recogidos mediante programas de tipo "evento unico sin registro".

Los datos de paciente son muy confidenciales y por tanto deben ser protegidos para que ninguna persona no autorizada pueda obtenerlos. Cuando estan en papel, deben ser archivados en un lugar seguro. En computadoras, los datos de paciente necesitan sistemas seguros con contraseñas, acceso restringido y logs de seguimiento.

La preocupacion por la seguridad de datos agregados no es tan crucial como lo es para los datos de paciente, ya que generalmente es imposible identificar una persona en particular con una estadistica agregada. Sin embargo, los datos tambien pueden ser mal usados o malinterpretados por otros, y no deberian distribuirse sin unas politicas de difusion de datos adecuadas.

1.6. Software libre y de codigo abierto (FOSS): beneficios y retos

El software lleva las instrucciones que indican a una computadora como funcionar. La forma legible y con autoria humana de esas instrucciones es denominada codigo fuente. Antes de que la computadora pueda realmente ejecutar las instrucciones, el codigo fuente debe traducirse en un formato legible por maquinas (binario), llamado codigo objeto. Todo el software disponible incluye el codigo objeto, pero FOSS publica tambien el codigo fuente.

Los dueños de software propietario licencian su codigo objeto con copyright a un usuario, lo cual permite a este ejecutar el programa. Los programas FOSS, sin embargo, licencian tanto el codigo objeto como el codigo fuente, permitiendo al usuario no solo utilizarlo sino tambien modificar y tal vez distribuir los programas. Teniendo acceso al codigo fuente, los usuarios tienen la libertad de ejecutar el programa para cualquier fin, redistribuirlo, probar, adaptar, aprender de ello, personalizar el software para responder a sus necesidades, y volcar mejoras publicamente para el bien de la comunidad. Por lo tanto, algun FOSS es conocido tambien como software libre, donde "libre" se refiere primero y ante todo, a las libertades antes descritas que a un sentido monetario de la palabra (en relacion a la gratuidad).

En el sector de la salud publica, FOSS puede tener muchos beneficios, como por ejemplo:

·          Menores costes ya que no implica el pago de costes de licencia prohibitivos.

·          Dado que las necesidades de informacion para el sector salud estan en constante cambio y evolucion, hay una necesidad de que el usuario tenga libertad para hacer los cambios segun sus propios requisitos. Esto frecuentemente es muy limitado en sistemas propietarios.

·          Acceso a codigo fuente para favorecer la integracion e interoperabilidad. La interoperabilidad entre diferentes aplicaciones software en el sector salud esta tomando importancia creciente, lo que significa permitir que dos o mas sistemas compartan datos y metadatos. Este trabajo es mucho mas facil, y a veces dependiente del codigo fuente que se disponibiliza a los desarrolladores que hacen la integracion. Esta disponibilidad frecuentemente no es posible en el caso del software propietario. Y cuando lo es, supone costes enormes y obligaciones contractuales.

·          Las aplicaciones FOSS como DHIS2 tipicamente estan mantenidas por una red global de desarrolladores, y por tanto tiene acceso a conocimiento puntero en investigacion y desarrollo (I D).

Seguir leyendo: Capitulo 2. Comenzando con DHIS 2 http://dhis2.org/doc/snapshot/es/user/html/ch02.html

Enlace: http://dhis2.org/download/dhis2-live.zip

Academia DHIS 2: http://esalud.unicauca.edu.co/academiadhis2/index.php/acerca-de-dhis2