DHIS2 Guía de Implementación 2.15

Transcripción

1 DHIS2 Guía de Implementación 2.15

2 Equipo de Documentación DHIS Version :01:32 Garantía: ESTE DOCUMENTO HA SIDO FACILITADO POR LOS AUTORES EN EL ESTADO EN QUE SE ENCUENTRA Y SE RENUNCIARÁ RECURRIR A CUALQUIER TIPO DE GARANTÍA IMPLÍCITA O EXPLÍCITA, INCLUYENDO DE FORMA NO LIMITANTE LAS GARANTÍAS IMPLÍCITAS DE COMERCIALIZACIÓN E IDONEIDAD PARA PROPÓSITOS PARTICULARES. EN NINGÚN CASO LOS AUTORES O COLABORADORES ASUMIRÁN RESPONSABILIDADES POR DAÑO ALGUNO DIRECTO, INDIRECTO, FORTUITO, ESPECIAL, EJEMPLAR O CONSIGUIENTE (INCLUIDOS, PERO NO RESTRINGIDOS A, LA ADQUISICIÓN DE BIENES O SERVICIOS SUSTITUTIVOS; PÉRDIDA DE USO, DATOS O BENEFICIOS; O INTERRUPCIÓN DE LA ACTIVIDAD) PRODUCIDO EN MODO ALGUNO NI POR NINGUNA VINCULACIÓN EXIGIBLE, YA SEA POR CONTRATO, RESPONSABILIDAD ESTRICTA, O AGRAVIO (INCLUIDA NEGLIGENCIA O DE OTRO TIPO) QUE PUEDAN SURGIR EN MODO ALGUNO DE LA UTILIZACIÓN DE ESTE MANUAL Y DE LOS PRODUCTOS EN ÉL MENCIONADOS, INCLUSO SI EXISTE ADVERTENCIA PREVIA SOBRE LA POSIBILIDAD DE TALES DAÑOS. Licencia: Se garantiza el permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, Versión 1.3 o cualquier versión posterior publicada por la Free Software Foundation; sin Secciones Invariables ("Invariant Sections"), sin Textos de Portada ("Front-Cover Texts") y sin Textos de Contraportada ("Back-Cover Texts"). Las fuentes de esta documentación incluyen una copia de la licencia, que también está disponible online: ii

3 DHIS2 Guía de Implementación Contents 1. Recomendaciones para implementaciones nacionales de SIS Desarrollo de bases de datos Importar y mapear bases de datos existentes Asegurar los recursos necesarios para la implementación Integración de sistemas paralelos Establecer un servidor nacional online y fiable Fase piloto Lanzamiento Formación Descentralización de la gestión y la captura de datos Revisión y extensión Principios conceptuales de diseño Todos los metadatos pueden añadirse y modificarse a través del interfaz de usuario Un modelo de datos flexible soporta que diferentes fuentes de datos puedan ser integradas en un único repositorio de datos Entrada de datos!= Salida de datos Análisis de datos y reportes basados en indicadores Mantener los datos de establecimientos desagregados en la base de datos Soporte de análisis de datos a cualquier nivel del sistema de salud Instalación de una nueva base de datos Estrategias para empezar Un proceso controlado o un proceso abierto? Pasos para elaborar una base de datos Jerarquía organizativa Elementos de datos Sets de datos y formularios de entrada de datos Reglas de validación Indicadores Tablas de reporte e informes SIG (Mapas) Gráficas y dashboard Estrategias de despliegue Despliegue Desconectado (Offline) Despliegue Conectado (Online) Despliegue Híbrido Alojamiento de servidor DHIS 2 es un Data Warehouse Data warehouse frente a sistemas funcionales Estrategia de agregación en DHIS La propuesta de almacenamiento de datos Capacitación de usuarios Qué capacitación se necesita Estrategias de capacitación Formación de formadores Workshops y formación in-situ Formación continua Materiales y cursos Integración Integración e interoperabilidad Beneficios de la integración Qué facilita la integración y la interoperabilidad Arquitectura de SIS interoperables Instalación Montaje del servidor Configuración de proxy inverso Instalación básica de nginx Habilitando SSL en nginx iii

4 DHIS2 Guía de Implementación Contents Scripts de control para nginx Colocar recursos disponibles con nginx Configuración básica de proxy inverso con Apache Balanceo de carga básico con Apache y Tomcat Encriptado básico SSL con Apache Instalación de DHIS 2 Live Copias de seguridad (Backup) Trabajando con la base de datos PostgreSQL Usando los Servicios Web Amazon Soporte Página principal: dhis2.org Plataforma colaborativa: launchpad.net/dhis Unidades Organizativas Diseño de la jerarquía de unidades organizativas Grupos de unidades organizativas y sets de grupos Elementos de datos y dimensiones personalizados Elementos de datos Categorías y dimensiones personalizadas Grupos de elementos de datos Sets de datos y formularios Qué es un set de datos? Qué es un formulario de entrada de datos? Tipos de formularios de entrada de datos Formularios por defecto Formularios de Sección Formularios personalizados Lecciones aprendidas: de los formularios en papel a los formularios electrónicos Identificar elementos de datos autónomos Dejar los cálculos y las repeticiones a la computadora: capturar solo datos en bruto Calidad de los datos Cómo medir la calidad de los datos Causas de una baja calidad de datos Cómo mejorar la calidad de los datos Cómo utilizar DHIS 2 para mejorar la calidad de los datos Validación en la introducción de datos Rangos Máximo y Mínimo Reglas de validación Análisis de outliers (valores atípicos) Reportes de integridad y de puntualidad Indicadores Qué es un indicador El propósito de los indicadores Recolección de datos por indicadores Gestión de indicadores Los usuarios y sus roles Usuarios Roles de usuario Una perspectiva general de las herramientas de análisis de datos Herramientas de análisis de datos Reportes estándar Reportes de sets de datos Reportes de completitud de datos Reportes estáticos Reportes de distribución de unidades organizativas Tablas de reporte Gráficas Tablas Web dinámicas iv

5 DHIS2 Guía de Implementación Contents SIG Tablas My Datamart y tablas dinámicas Excel Tablas dinámicas y la herramienta MyDatamart Diseño de tablas dinámicas Conectando con la base de datos de DHIS Manejando grandes cantidades de datos La herramienta MyDatamart Utilizando tablas dinámicas Excel y MyDatamart - un ejemplo práctico Descargar y lanzar la herramienta MyDatamart por primera vez Crear y distribuir las tablas dinámicas Actualizar MyDatamart Actualizar las tablas dinámicas Repetimos los pasos 3 y 4 cuando haya nuevos datos disponibles en el servidor central DHIS como plataforma Portales Web Aplicaciones (Apps) Sistemas de Información Conceptos para la adaptación local Utilizando el servidor de traducción DHIS Herramienta DHIS2 i18n Detalles a tener en mente (2.15) v

6

7 Recomendaciones para implementaciones nacionales de SIS Desarrollo de bases de datos Capítulo 1. Recomendaciones para implementaciones nacionales de SIS Este texto pretende ofrecer una breve introducción a algunos de los aspectos clave en la implementación de Sistemas de Información de Salud (SIS) recogidas por HISP a lo largo de numerosos proyectos en países en desarrollo. Los diversos aspectos aquí mencionados pueden utilizarse como aportaciones para planificar nuevos esfuerzos de implementación así como para la evaluación de procesos en curso Desarrollo de bases de datos Cuando desarrollamos una nueva base de datos, la manera natural de empezar es definir los elementos de datos para los cuales registrar datos y diseñar los formularios de entrada de datos. Los elementos de datos son los bloques centrales de la base de datos y deben ser razonablemente estables antes de avanzar más en la implementación. El siguiente paso sería definir las reglas de validación basadas en los elementos de datos mencionados para ser capaces de garantizar de mejor manera la corrección de los datos que se están registrando. Otro componente fundamental de la base de datos es la jerarquía organizativa que debe ser identificada y configurada en una fase inicial. Los establecimientos de salud son generalmente la fuente de la información y la jerarquía organizativa ordena los establecimientos tanto en la dimensión geográfica como administrativa. En la mayoría de países no hay un registro máster definido estrictamente y actualizado permanentemente para los establecimientos de salud, de modo que este proceso necesita involucrar a los diversos actores, inluido el nivel distrital, dado que son ellos los que mejor conocen la situación Importar y mapear bases de datos existentes Traer datos existentes al nuevo sistema añade un importante valor en las fases iniciales, ya que facilita enormemente la exhibición de las capacidades de análisis de DHIS2 como son las gráficas y los reportes. Esto mejora nuestra capacidad para convencer a actores clave como los programas de salud y los donantes para que apoyen el nuevo sistema. En la mayoría de los casos existe una gran cantidad de datos almacenados electrónicamente de sistemas de bases de datos internos, hojas de cálculo u otros sistemas de terceros. Siempre que sea posible, estos datos deberían importarse y mapearse en elementos de datos y en unidades organizativas (ubicaciones, establecimiensos de salud) en el nuevo sistema siguiendo cualquier solución técnica viable. Este proceso ha de realizarse una única vez para poner la base de datos a punto y no debería convertirse en une rutina repetitiva Asegurar los recursos necesarios para la implementación Realizar un lanzamiento nacional es un esfuerzo costoso que requiere financiación apropiada para los aspectos aquí mencionados, incluyendo la compra de hardware, alojamiento en servidores, workshops y formación interna y externa. La financiación puede venir del presupuesto gubernamental y/o de donantes externos. En todo caso es vital que incluso cantidades pequeñas necesarias por ejemplo para la tarifa de conexión a Internet sean presupuestadas y gestionadas para evitar así frustraciones y problemas innecesarios a los usuarios finales Integración de sistemas paralelos La esfera gubernamental típica en salud tiene muchos actores y sistemas pre-existentes. En primer lugar, está claro que una base de datos integrada que contenga datos de varias fuentes se vuelve mucho más valiosa y útil que una con datos aislados y fragmentados. Por ejemplo, mejora su utilidad cuando el análisis de datos epidemiológicos se combina con datos especializados de VIH/SIDA, TB, recursos humanos y financieros, o cuando la inmunización se combina con datos de logística y stock, ya que nos ofrece un cuadro más completo de la situación. En segundo lugar, hay típicamente muchos elementos de datos solapados que están siendo capturados en los diferentes sistemas paralelos. Por ejemplo, los 1

8 Recomendaciones para implementaciones nacionales de SIS Establecer un servidor nacional online y fiable elementos de datos relativos a VIH/SIDA son capturados por múltiples programas generales de conciliamiento y test y también por el programa específico de VIH/SIDA, o los elementos de datos relativos a malaria durante el embarazo son registrados tanto por el programa de salud reproductiva como por el programa de malaria. Si armonizamos las herramientas de recogida y registro de datos de estos programas reduciremos la carga de trabajo total de los usuarios finales. Esto implica que estas fuentes de datos estén integradas en el sistema nacional de información y armonizadas con los elementos de datos existentes, que incluye requisitos tanto de entrada de datos como de análisis de datos y exige un sistema software de información que sea flexible y escalable. Por tanto, es importante que las discusiones y el trabajo individual se realicen junto a todos los actores relevantes incluidos todos los programas de salud Establecer un servidor nacional online y fiable Dado que el desarrollo tecnológico avanza, muchos países disponen ya de red celular y cobertura para buena parte de los distritos. La utilización de sistemas de información en red que pueden ser accedidos a través de Internet (también conocidos como "cloud computing") unido a modems de Internet que usan la red celular es un gran acercamiento a la rápida escalabilidad. Esto requiere tener un servidor online fiable a nivel nacional. El enfoque recomendado consiste en conseguir servicios de alojamiento en proveedores externos (como Linode o Amazon) que libera al gobierno de proporcionar acciones necesarias como soluciones de back-up eléctrico, copias de seguridad y respaldo de datos frecuentes, mantenimiento de servidor, seguridad y acceso fiable en red/internet. Una preocupación típica aquí es la política y la localización dentro del país del almacenamiento de datos, pero esto puede solucionarse negociando condiciones especiales con el proveedor Fase piloto Antes de comenzar el lanzamiento del sistema nacional es preciso realizar una fase piloto, típicamente para todos los distrituos de una provincia o región concreta. El objetivo es realizar una prueba de campo y obtener retroalimentación del sistema por parte de todos los actores involucrados. Normalmente los usuarios aportarán retroalimentación sobre la experiencia de entrada de datos, los diseños de formularios para entrada de datos, la usabilidad de la funcionalidad de entrada de datos, el contenido de los reportes y otras herramientas de análisis, la viabilidad de realizar entrada de datos online (calidad de las conexiones) u offline (fiabilidad de la instalación local). Generalmente sucede que hay cierta resistencia por parte de los usuarios finales en cuanto al cambio de paradigma del sistema basado en papel al sistema electrónico, por ejemplo en relación a desacoplar los formularios de entrada de datos y las herramientas de análisis de datos. Es preciso testear la viabilidad de la conexión de red y la configuración del servidor nacional considerando el rendimiento y el tiempo de funcionamiento del sistema. Dada la situación de que haya un sistema heredado en funcionamiento, es vital apagar ese sistema en el zona del piloto. Si tal sistema todavía está en producción, los usuarios seguirán enfocándose en introducir los datos en ese sistema y al sistema piloto solo se le prestará atención de forma periférica obteniendo como resultado un testeo y un aprendizaje subóptimos. Si mantener el sistema anterios es una prioridad, entonces los datos deberán ser transferidos al nuevo sistema por el equipo técnico sin molestar a los usuarios finales Lanzamiento El proceso de lanzamiento está asociado tradicionalmente a la instalación del sistema y la formación inicial básica de los usuarios. Sin embargo, es siempre útil considerarlo como un proceso más integral constituido por múltiples fases. La primera fase corresponde a las actividades tradicionales en las que el primer objetivo es la integridad de los datos: para garantizar que cerca del 100% de los datos están siendo recogidos. En primer lugar esto implica que el sistema deberá ser implementado y utilizado en todos los distritos del país. En segundo lugar, implica que los datos para todos los elementos de datos incluidos en los formularios se reportan realmente desde los distritos o los establecimientos de salud. El hecho de que los datos que sean informados en una franja de tiempo razonable - puntualidad -es también relevante en este contexto. El segundo objetivo está ligado a la calidad de los datos: para garantizar que los errores en la captura de datos se reducen al mínimo. Es posible aplicar muchas mediciones diferentes para lograr este objetivo: primero, la entrada de 2

9 Recomendaciones para implementaciones nacionales de SIS Formación datos y la revisión de datos debe realizarse por personal cualificado, segundo, se deberán aplicar métodos de evaluación automática de datos tales como reglas de validación y análisis de outliers (valores atípicos). La segunda fase tiene que ver con capacitar al personal de los hospitales y unidades distritales a utilizar herramientas estándar de análisis como reportes, gráficas y tablas dinámicas. Los usuarios deberían ser capaces de encontrar y ejecutar esas herramientas sobre los datos relevantes. Esto debe seguirse de una comprensión básica del propósito, sentido y consecuencias del uso de esas herramientas y de los datos que sometidos a análisis. La tercera fase involucra la utilización de los datos: un uso regular del análisis de datos para mejorar la evaluación, planificación y monitoreo de las actividades de salud a todos los niveles. Los datos del sistema de información deberían ser utilizados para evaluar los efectos de las decisiones realizadas y las medidas tomadas a través de la observación de indicadores clave. Este aprendizaje deberá ser utilizado más adelante para la toma informada de decisiones en planificaciones futuras. Por ejemplo cuando se descubren bajas tasas de inmunidad mediante un reporte de inmunización proviniente del sistema de información, deberá efectuarse una campaña de vacunación extraordinaria. Los efectos de la campaña podrán ser monitoreados y evaluados en base a reportes permanentemente actualizados, y se tomarán decisiones informadas sobre dónde intensificar o suavizar la campaña. Posteriormente, el sistema podrá proporcionar información sobre qué cantidad de dosis de vacunas es preciso solicitar a los proveedores. Es preciso trabajar en un plan detallado de formación y acompañamiento para dar cabida a procesos de lanzamiento a gran escala, ya que cubrir todos los distritos de un país representa un reto logístico en términos de organización de workshops, formadores, participantes, equipamiento y hardware. Para acelerar el proceso, diversos equipos pueden realizar formaciones en parelelo Formación La mayor parte de los objetivos mencionados en la sección de lanzamiento depende en gran medida de una adecuada capacitación de los usuarios. La formación de usuarios puede realizarse de muy diversas formas. Una actividad muy eficaz, especialmente para comenzar, son los workshops de formación. Los usuarios tipo digitadores/tipeadores distritales o provinciales, gestores distritales, personal de registro de datos y gestores de programas de salud se agrupan y reciben formación conjunta. La formación debería ser una combinación de lecturas teóricas y de ejemplos prácticos en los temas relevantes mencionados enla sección anterior como son la entrada de datos, validación y análisis. El número de participantes debería ser manejable en función del número de establecimientos de salud y de formadores disponibles. Se deberá proporcionar el hardware suficiente para que todos los participantes puedan realizar trabajos prácticos. Otra actividad útil es la formación durante el trabajo, que tiene la ventaja de que los usuarios reciben acompañamiento individual en su entorno normal de trabajo. Esto aporta la capacidad de apoyarlos en necesidades o cuestiones individuales específicas y de resolver problemas relacionados con el hardware instalado. Además, recibir soporte individual generalmente refuerza la motivación y el sentimiento de pertenencia en los usuarios. El periodo entre un workshipo y la formación en el trabajo puede emplearse para asignar tareas de entrega posterior, donde normalmente se pide a los usuarios que creen análisis coherentes para su distrito o provincia. Este trabajo puede más tarde ser retroalimentado y utilizarse como base para la capacitación individual Descentralización de la gestión y la captura de datos La migración de sistemas basados en papel o bases de datos primarias a sistemas de información de salud web en toda regla, y de registrar datos agregados de distrito a datos de establecimientos de salud, supone nuevas posibilidades para la gestión descentralizada de datos que deberían aprovecharse. En primer lugar, los establecimientos de salud con hardware y conectividad suficientes deberían ser responsables de introducir sus propios datos. Esto reducirá la carga de trabajo del personal de registro a nivel distrital, quien podrá utilizar el tiempo ganado para análisis de datos, utilización de los datos, retroalimentación a los establecimientos y mejora de la calidad de los datos. En segundo lugar, el mantenimiento de la jerarquía de establecimientos en términos de clasificación y de los servicios de salud proporcionados en los establecimientos es una tarea que demanda recursos y que debería ser descentralizada y realizada como un esfuerzo conjunto por todo el personal distrital más que por un único equipo nacional. Esto hará que la información de los establecimientos sea más correcta y actualizada ya que el personal distrital tendrá mejor 3

10 Recomendaciones para implementaciones nacionales de SIS Revisión y extensión conocimiento de su situación local, y tendrá también motivación para una gestión adecuada ya que ello afectará sus indicadores de rendimiento y sus marcas de integridad de datos Revisión y extensión Un SIS nacional es un organismo en crecimiento que necesita mantenimiento. A medida que aumenta el uso del sistema, surgirán más requisitos y necesidades de los actores existentes y otros nuevos como son el personal distrital de registro y el personal de programas de salud. Es recomendable mantener reuniones regulares de revisión que incorporen a dichos actores, y donde las herramientas de captura de datos, como son los elementos de datos y formularios, y las herramientas de análisis, como son los indicadores y reportes, se revisen y se añadan potenciales herramientas nuevas. Además, los nuevos requisitos de funcionamiento deben gestionarse y se deben asegurar recursos apropiados para el desarrollo software. Estas actividades regulares para apoyar la extensión y mejora del sistema son vitales para mantener el momentum actual y los procesos de aprendizaje, así como para mejorar la sostenibilidad del proyecto a largo plazo. 4

11 Principios conceptuales de diseño Todos los metadatos pueden añadirse y modificarse a través del interfaz de usuario Capítulo 2. Principios conceptuales de diseño Este capítulo pretende servir de introducción a algunos de los principios conceptuales clave de diseño que alberga el software DHIS 2. La comprensión y toma de conciencia sobre estos principios ayudará a los implementadores a hacer un uso óptimo del software al personalizar una base de datos local. Si bien este capítulo solo se centra en los principios, los capítulos siguientes detallan cómo éstos repercuten en el proceso de diseño de la base de datos En este capítulo se presentan los siguientes principios de diseño: Que todos los metadatos puedan añadirse y modificarse a través del interfaz de usuario Que un modelo de datos flexible soporte que diferentes fuentes de datos puedan ser integradas en un único repositorio de datos Que la entrada de datos!= Salida de datos Que el análisis de datos y reportes estén basados en indicadores Que los datos de establecimientos de salud se mantengan desagregados en la base de datos Que el análisis de datos esté soportado para cualquier nivel del sistema de salud A continuación cada principio se describe en mayor detalle en las respectivas secciones Todos los metadatos pueden añadirse y modificarse a través del interfaz de usuario La aplicación DHIS 2 trae un set de herramientas genéricas para la recolección de datos, validación, elaboración de reportes y análisis de datos. Sin embargo, los contenidos de la base de datos, tales como qué datos recolectar, de dónde vienen los datos, o en qué formato, depende del contexto de uso de esa información. Antes de poder utilizar estos metadatos es preciso ingresarlos en la aplicación, lo cual puede hacerse a través del interfaz de usuario y no requiere programación. Esto permite involucrar más directamente a los expertos de ese ámbito, que son quienes entienden los detalles del SIS que el software debe soportar. El software separa los metadatos importantes que describen los datos en bruto que son almacenados en la base de datos, que son los metadatos críticos que no debieran cambiar mucho a lo largo del tiempo (para evitar la corrupción de datos), y los metadatos de alto nivel como las fórmulas de indicadores, las reglas de validación y los grupos de agregación, así como las diferentes capas (layouts) para recogida de formularios y reportes, que no son tan críticos. En este alto nivel los metadatos pueden añadirse y modificarse en el tiempo sin interferir con los datos en bruto, soportando un proceso permanente de personalización. Es típico añadir nuevos atributos a medida que el equipo local de implementación va aprendiendo a dominar más funcionalidades de la aplicación, y que los usuarios van introduciendo gradualmente análisis de datos y reportes más avanzados Un modelo de datos flexible soporta que diferentes fuentes de datos puedan ser integradas en un único repositorio de datos El diseño de DHIS 2 sigue una aproximación integral del SIS, y soporta la integración de muchas fuentes de datos diversas en una misma base de datos, en ocasiones denominada repositorio integrado de datos o data warehouse El hecho de que DHIS 2 sea una especie de herramienta esqueleto sin formularios o reports predefinidos significa que puede soportar una buena cantidad de diferentes fuentes de datos agregados. Tampoco hay nada que limite realmente su uso al ámbito de la salud, aunque su uso en otros sectores es aún muy restringido. Mientras los datos sean recogidos por una orgunit, descritos como elementos de datos (probablemente con una desagregación en categorías), y puedan 5

12 Principios conceptuales de diseño Entrada de datos!= Salida de datos representarse con una frecuencia y periodos predefinidos, esos datos pueden recolectarse y procesarse en DHIS 2. Esta flexibilidad hace que DHIS 2 sea una herramienta potente para montar sistemas integrados que aúnen herramientas de recolección, de indicadores y de reportes de múltiples programas de salud, departamentos e iniciativas. Una vez que los datos se definen y luego se recogen o importan en una base de datos de DHIS 2, pueden analizarse en correlación con otros datos cualesquiera de la misma base de datos, sin importar cómo o quién introdujo los datos. Además de soportar el análisis y reporte integrado de datos, este enfoque integrado también ayuda a racionalizar la recolección de datos y a reducir los duplicados Entrada de datos!= Salida de datos En DHIS 2 hay tres dimensiones que describen los datos agregados que se están recogiendo y almacenando enla base de datos: DÓNDE - la unidad organizativa, QUÉ - el elemento de datos, y CUÁNDO - el periodo. La unidad organizativa, el elemento de datos y el periodo constitutyen las tres dimensiones nucleares necesarias para describir cualquier valor de un dato en DHIS 2, ya se encuentr en un formulario de recogida de datos, en un gráfico, en un mapa, o en un reporte sumarístico agregado. Cuando los datos se recogen en formularios electrónicos, que a veces son imágenes especulares de los formularios en papel utilizados en los establecimientos, cada campo de entrada del formulario queda descrito utilizando estas tres dimensiones. El formulario en sí mismo es tan solo una herramienta para organizar la recolección de datos y no describe los valores de datos individuales que se están recogiendo o guardando en la base de datos. Ser capaces de describir cada valor de datos independientemente mediante una definición de Elemento de Datos (por ejemplo, 'Dosis de sarampión suministradas < 1 año') permite una importante flexibilidad a la hora de procesar, validar y analizar los datos, permitiendo comparar datos en diversos formularios y programas de salud. Este enfoque de diseño o de modelo de datos marca la diferencia entre DHIS y muchas otras aplicaciones software de SIS que tratan los formularios de recogida de datos como la unidad clave del análisis. Esto es muy típico en sistemas hechos a la medida de las necesidades de programas verticales de salud y en la mentalidad tradicional de que el formulario de entrada de datos agregados es ya también la salida de reporte o de análisis. La figura siguiente muestra cómo el diseño granular fino de DHIS, construido sobre el concepto de Elementos de Datos, es diferente y cómo la entrada (recogida de datos) está separada de la salida (análisis de datos), permitiendo un análisis y diseminación de datos más flexible y variada. En el ejemplo, el elemento de dato 'Dosis de sarampión suministradas < 1 año' es registrado como parte de un formulario de registro de Inmunización Infantil, pero puede utilizarse individualmente para construir un Indicador (una fórmula) llamada 'Cobertura de sarampión < 1 año', donde se combina con el elemento de datos llamado 'Población < 1 año', que se registra en un formulario distinto. El valor de este indicador calculado puede utilizarse luego en el análisis de datos de varias herramientas de reporte en DHIS 2, como por ejemplo en reportes personalizados con gráficos, tablas dinámicas, o en un mapa en el módulo SIG. 6

13 Principios conceptuales de diseño Análisis de datos y reportes basados en indicadores 2.4. Análisis de datos y reportes basados en indicadores Aquello que hemos llamado previamente Elemento de Datos es la dimensión clave que describe qué se está registrando (en otros contextos puede nombrarse somo indicador). En DHIS 2 distinguimos entre Elementos de Datos, que describen los datos en bruto, como los recuentos, y los Indicadores, que parten de fórmulas y describen valores calculados, como por ejemplo cobertura o tasa de incidencia que se utilizan para en el análisis. Los valores de los indicadores no se registran como los valores de datos, sino que se calculan enla aplicación a partir de fórmulas definidas por los usuarios. Estas fórmulas constan de un factor (ej. 1, 100, 1000, ), y de un numerador y un denominador, que son expresiones construidas con uno o más elementos de datos. Por ejemplo, el indicador 'Cobertura de sarampión < 1 año' se define con una fórmula de factor 100, un numerador ('Dosis de sarampión suministradas a niños menores de 1 año') y n denominador ('Población diana menores de 1 año'). El indicador 'Tasa de exclusión DPT1 a DPT3' es una fórmula de 100 % x ('Dosis suministradas DPT1' - 'Dosis suministradas DPT3') / ('Dosis suministradas DPT1'). Estas fórmulas pueden añadirse y editarse a través del interfaz de usuario por usuarios con una capacitación básica, ya que son bastante sencillos de configurar y no interfieren con los valores de datos almacenados en la base de datos (de modo que añadir o modificar un indicador no es una operación crítica). Los indicadores son tal vez la característica más potente de DHIS 2 y todas las herramientas de reporte soportan el manejo de indicadores, como se muestra por ejemplo en el reporte personalizado de la figura anterior. Tener la capacidad de utilizar datos de población en el denominador permite comparaciones de desempeño en salud entre diversas áreas geográficas con distintas poblaciones diana, lo cual resulta más útil que mirar únicamente los números en bruto. La tabla siguiente utiliza tanto valores de datos en bruto (las dosis) como los valores de indicadores (la cobertura) para diferentes vacunas. Comparando por ejemplo las dos primeras unidades organizativas de la lista, distrito de Taita Taveta y distrito de Kilifi, en inmunización DPR-1, podemos observar que mientras los números en bruto (659 vs 2088) indican que se suministraron muchas más dosis en Kilifi, las tasas de cobertura (92.2 % vs 47.5 %) muestran que Taita Taveta está realizando un mejor trabajo en la inmunización de su población diana menores de 1 año. Si observamos ahora la última columna (Inmunización completada %), que indica la integridad de registros del formulario 7

14 Principios conceptuales de diseño Mantener los datos de establecimientos desagregados en la base de datos de inmunización para el mismo periodo, vemos que los números son más o menos los mismos para los dos distritos comparados, lo cual apunta a que es razonable comparar las tasas de cobertura entre estos dos distritos Mantener los datos de establecimientos desagregados en la base de datos Cuando se recogen datos y se almacenan en DHIS 2, éstos quedarán desagregados en la base de datos con el mismo nivel de detalle con el cual fueron registrados. Ésta es la mayor ventaja de tener un sistema de base de datos para SIS similar a lo esperado de un sistema en papel o incluso en hojas de cálculo. El sistema se diseña para almacenar gran cantidad de datos y siempre permite exámenes a fondo hasta el nivel más fino posible de detalle, que solo está limitado por la manera en que los datos fueron registrados o importados en la base de datos DHIS 2. Desde la perspectiva de un SIS nacional, es deseable guardar los datos desagregados por nivel de establecimiento de salud, que generalmente es el nivel más bajo en la jerarquía organizativa. Esto puede hacerse incluso sin informatizar este nivel, mediante un sistema híbrido informático y en papel. Por ejemplo, los datos pueden ser enviados en papel desde los establecimientos de salud a las oficinas distritales (en formularios mensuales resumidos para un establecimiento específico), y luego en la oficina distrital ya introducen todos los datos de establecimiento en DHIS 2 mediante formularios electrónicos de recogida de datos, establecimiento por establecimiento. Esto permitirá a los equipos distritales de gestión de salud realizar análisis de datos por establecimiento y por ejemplo compartir los reportes impresos de realimentación generados en DHIS 2, incluidas comparativas entre establecimientos, con los responsables de los establecimientos en cada distrito Soporte de análisis de datos a cualquier nivel del sistema de salud Aunque el propio nombre de DHIS apunta a un enfoque de 'distrito', la aplicación ofrece las mismas herramientas y funcionalidades a todos los niveles del sistema de salud. En todas las herramientas de reporte los usuarios pueden seleccionar qué unidad organizativa o qué nivel de orgunit desean analizar y los datos mostrados se agregarán automáticamente en el nivel seleccionado. DHIS 2 utiliza la jerarquía de unidades organizativas para agregar datos hacia arriba y nos da los datos para cualquier orgunit en esta jerarquía. La mayoría de reportes se lanzan de manera que se pedirá a los usuarios que seleccionen una unidad organizativa y así permitir la reutilización de las mismas capas de reporte para todos los niveles. O si se desea, las capas de reporte pueden diseñarse a la medida de un nivel específico cualquiera en el sistema de salud en caso de que las necesidades difieran entre diferentes niveles. En el módulo SIG los usuarios pueden analizar los datos por ejemplo a nivel subnacional y entonces pinchando en el mapa (por ejemplo en un departamento o provincia) examinar a fondo el siguiente nivel, y continuar de este modo descendiendo hacia la fuente de datos a nivel de establecimiento. Una funcionalidad similar de profundización está disponible en las tablas dinámicas que están enlazadas con la base de datos DHIS 2. Para acelerar el rendimiento y reducir el tiempo de respuesta al generar salidas de datos agregadas, que pueden incluir numerosos cálculos (por ejemplo juntar 8000 establecimientos), DHIS 2 realiza un precálculo de todos los valores agregados posibles y los guarda en lo que se denomina datamart. El datamart puede programarse para ser ejecutado (reconstruirse) en intervalos de tiempo determinados, por ejemplo cada noche. 8

15 Instalación de una nueva base de datos Estrategias para empezar Capítulo 3. Instalación de una nueva base de datos La aplicación DHIS 2 viene con un set de herramientas para la recogida de datos, validación, reporte y análisis, pero los contenidos de la base de datos, como son qué datos registrar, de dónde vienen los datos, y en qué formato, dependen del contexto en que usemos la aplicación. Tendremos que insertar estos metadatos en la aplicación antes de poder usarlos, y esto es posible hacerlo mediante el interfaz de usuario sin necesidad de programación. Lo que sí se necesita es conocer en profundidad el contexto local del SIS así como comprender los principios de diseño de DHIS 2 (véase el capítulo "Principios conceptuales de diseño en DHIS 2"). Esto es lo que llamamos proceso inicial para el diseño y personalización de la base de datos. Este capítulo da una perspectiva general del proceso de personalización y explica brevemente los pasos requeridos, con el objetivo de ofrecer a los implementadores una visión de lo que requiere este proceso. Otros capítulos de este manual entran con mayor detalle en algunos de estos pasos concretos Estrategias para empezar La sección siguiente describe una lista de consejos para arrancar con buen pie en el desarrollo de una nueva base de datos. 1. Montar cuanto antes una base de datos demostrativa, que incluya ejemplos de reportes, gráficas, dashboard, SIG, formularios de entrada de datos. Utilizar datos reales, idealmente a nivel nacional, pero no necesariamente datos a nivel de establecimientos de salud. 2. Poner la base de datos demostrativa accesible desde Internet. Una manera de acelerar este proceso puede ser alojarla en un servidor web con un proveedor de servicios externo, incluso si es solo temporal. Esto crea una buena plataforma colaborativa y una herramienta estupenda de difusión para lograr la aprobación y participación de los diferentes actores relevantes para el SIS. 3. Realizar a continuación un proceso de diseño de la base de datos más elaborado. Si es posible, algunas partes de la demo pueden reutilizarse. 4. Asegurarse de que contamos con un equipo local multidisciplinar, con capacidades y formación diversas: salud pública, administración de sistemas, gestión de TIC y gestión de proyectos. 5. Utilizar la fase de personalización y diseño de la base de datos como un proceso de aprendizaje y de formación para cultivar capacidades locales mediante "aprender haciendo". 6. El equipo nacional de implementación deberá liderar el proceso de diseño de la base de datos pero siempre apoyado y guiado por implementadores más experimentados Un proceso controlado o un proceso abierto? Dado que el proceso de personalización de DHIS 2 suele ser y debe ser un proceso colaborativo, es importante tener en mente qué partes de la base de datos son más críticas que otras, por ejemplo para evitar que usuarios no capacitados corrompan los datos. Normalmente es mucho más crítico personalizar una base de datos que ya tiene valores de datos, que trabajar con metadatos en una base de datos "vacía". Aunque parezca extraño, mucha de la personalización tiene lugar después del primer registro de datos o de la primera importación. Es entonces cuando por ejemplo se añaden nuevas reglas de validación, indicadores y capas de reporte. El error más crítico que se puede cometer aquí es modificar los metadatos que describen directamente los valores de datos, que como hemos visto anteriormente, son los elementos de datos y las unidades organizativas. Cuando modificamos estas definiciones es importante pensar en cómo afectarán los cambios al significado de los valores de datos que ya estaban en el sistema (recogidos utilizando las definiciones anteriores). Es recomendable limitar quién puede editar estos metadatos fundamentales, mediante la gestión de roles de usuario, para restringir el acceso al equipo experto de personalización. Otras partes del sistema que no están directamente acopladas a los valores de datos son mucho menos críticas y podemos experimentar con ellas. Es más, en las fases incipientes de implementación, deberíamos animar a los usuarios a probar cosas nuevas y así provocar el aprendizaje. Esta premisa es válida para los grupos, las reglas de validación, las fórmulas 9

16 Instalación de una nueva base de datos Pasos para elaborar una base de datos de indicadores, las gráficas y los reportes. Todos ellos pueden borrarse o modificarse posteriormente con facilidad sin afectar a los valores de datos, de modo que no son partes críticas del proceso de personalización. Por supuesto, cuando posteriormente llevamos el proceso de personalización a fase de producción, deberemos ser todavía más cautos al permitir acceso a la edición de metadatos, ya que cualquier cambio, incluso en los menos críticos, puede afectar a cómo se agregan o se presentan los datos en reportes (aunque los datos en bruto por debajo estén correctos y a salvo) Pasos para elaborar una base de datos Esta sección describe los pasos concretos para elaborar una base de datos desde el principio Jerarquía organizativa La jerarquía organizativa define la organización en DHIS 2: los establecimientos de salud, las áreas administrativas y otras áreas geográficas utilizadas en la recolección y el análisis de datos. Esta dimensión de los datos se define como una jerarquía con una unidad raíz (ej. Ministerio de Salud) y diversos niveles y nodos debajo. Cada nodo en esta jerarquía es lo que en DHIS 2 llamamos unidad organizativa. El diseño de esta jerarquía determinará las unidades geográficas de análisis disponibles a los usuarios al momento en que los datos son registrados y agregados en esta estructura. Solo puede haber una jerarquía organizativa en el sistema, de modo que deberemos considerar cuidadosamente cómo estructurarla. Es posible modelar jerarquías adicionales (tales como límites administrativos paralelos al Sector Salud) utilizando grupos organizativos y sets de grupo, pero la jerarquía organizativa es el vehículo principal para la agregación de datos en una dimensión geográfica. Normalmente las jerarquías organizativas nacionales en Salud Pública tienen entre 4 y 6 niveles, pero DHIS soporta cualquier cantidad de niveles. La jerarquía se construye con relaciones padre-hijo, por ejemplo: una unidad País o Ministerio de Salud (la raíz) puede tener 8 unidades hijo (provincias), y cada provincia (en nivel 2) puede tener a su vez 10 ó 15 distritos como nodos hijo. Generalmente los establecimientos de salud estarán colocados en el nivel más bajo, pero también podemos colocarlos en niveles más altos como sucederá con los hospitales provinciales o nacionales, de modo que es posible tener árboles organizativos asimétricos (ej. un nodo hoja puede estar colocado en el nivel 2 mientras la mayoría de nodos hoja se encuentran en el nivel 5) Elementos de datos El Elemento de Datos es probablemente el bloque más fundamental de una base de datos en DHIS2. Representa la dimensión qué, ya que explica qué se está recopilando o analizando. En algunos contextos esto está referido a un indicador, para en DHIS2 llamamos elemento de datos a esta unidad de colección y análisis. El elemento de datos a menudo representa un conteo de algo, y su nombre describe qué es aquello que se está contando, por ejemplo "Dosis entregadas de BCG" o "Casos de Malaria". Cuando los datos son recopilados, validados, analizados, reportados o presentados, lo que describe el QUÉ de los datos son los elementos de datos o expresiones construidas a partir de elementos de datos. Como tales, los elementos de datos se vuelven importantes para todos los aspectos del sistema y deciden no sólo cómo se recopilan los datos, sino algo más importante: cómo los valores de datos se representan en la base de datos, lo cual de nuevo afecta a cómo los datos son analizados y presentados. La mejor práctica en el diseño de elementos de datos es pensar en los elementos de datos como una unidad de análisis de datos y no sólo como un campo en el formulario de entrada de datos. Cada elemento de datos tiene vida propia en la base de datos, completamente separado del formulario, y los reportes y otras salidas se basan en elementos de datos y expresiones o fórmulas compuestas por elementos de datos y no en los formularios de colección de datos. De modo que las necesidades del análisis de datos son las que deberían dirigir este proceso, y no el aspecto y función amigables del formulario de colección de datos Sets de datos y formularios de entrada de datos Toda la entrada de datos en DHIS 2 se organiza mediante la utilización de sets de datos. Un set de datos es una colección de elementos de datos agrupados juntos para la recopilación de datos, y en el caso de instalaciones distribuidas también 10

17 Instalación de una nueva base de datos Reglas de validación define pedazos de datos para exportarlos o importarlos entre instancias de DHIS 2 (por ejemplo de una instalatión local en una oficina distrital a un servidor nacional). Los sets de datos no están vinculados directamente a los valores de datos, solo mediante sus elementos de datos y frecuencias, y como tales los sets de datos pueden ser modificados, eliminados o añadidos en cualquier momento sin que esto afecte a los datos en bruto previamente capturados en el sistema, pero tales cambios afectarán por su puesto a cómo se registrarán nuevos datos. Una vez hemos asignado un set de datos a una unidad organizativa, ese set de datos estará disponible en Entrada de Datos (del menú Servicios) para la unidad asignada y para los periodos válidos de acuerdo al tipo de periodo del set de datos. Entonces, se mostrará un formulario de entrada de datos por defecto, que es simplemente una lista de los elementos de datos pertenecientes al set de datos junto a una columna para introducir los valores. Si nuestro set de datos contiene elementos de datos con categorías como grupos de edad o género, entonces se generarán automáticamente columnas adicionales en el formulario por defecto en base a estas categorías. Además del formulario de entrada de datos por defecto basado en listado, existen dos alternativas: el formulario basado en secciones y el formulario personalizado. Los formularios por secciones permiten un poco más de flexibilidad cuando queremos utilizar formularios tabulares, y además son rápidos y sencillos de diseñar. A menudo sucederá que nuestro formulario de entrada de datos precisa múltiples tablas con subtítulos, y a veces necesitamos deshabilitar (poner en gris) algunos campos de la tabla (por ejemplo cuando algunas categorías no aplican para todos los elementos de datos); estas funciones están soportadas en los formularios por secciones. Cuando el formulario que queremos diseñar es demasiado complicado para los modelos por defecto o por secciones, entonces nuestra última opción es usar el formulario personalizado. Este nos llevará más tiempo, pero da una flexibilidad total en términos de diseño. DHIS 2 viene ya con un editor HTML (Editor FcK) para el diseñador de formularios y podemos diseñar el formulario usando este interfaz de usuario o bien pegar directamente nuestro código HTML (usando la ventana Fuente en el editor) Reglas de validación Una vez que hayamos configurado la parte de entrada de datos del sistema y comenzado a recoger datos, entonces es momento de definir chequeos de calidad de los datos que ayuden a mejorar la calidad de los datos que se están recopilando. Podemos añadir tantas reglas de validación como queramos, que estarán compuestas por expresiones a izquierda y derecha de un operador matemático, que a su vez están formadas por elementos de datos. Las reglas típicas consisten en comparar los subtotales con los totales de algo. Por ejemplo, si tenemos dos elementos de datos "Test VIH realizados" y "Test VIH resultado positivo", entonces sabemos que en el mismo formulario (es decir, para el mismo periodo y unidad organizativa) el número total de tests deberá ser siempre igual o mayor que el número de tests positivos. Estas reglas deberían ser reglas absolutas, que significa que son matemáticamente correctas y no simplemente asunciones o "casi siempre correctas". Las reglas se pueden ejecutar en la entrada de datos, después de rellenar cada formulario, o como un proceso por tandas testeando múltiples formularios de una vez, por ejemplo para todos los establecimientos durante el mes de reporte previo. Los resultados de los tests de validación mostrarán un listado con todas las infracciones y con los valores detallados de cada lado de la expresión donde se produjo la infracción para facilitar que regresemos a la entrada de datos y corrijamos los valores Indicadores Los indicadores representan seguramente la herramienta más poderosa de análisis incluida en DHIS 2. Mientras los elementos de datos representan los datos en bruto (conteos) que son recopilados, los indicadores representan fórmulas que proporcionan tasas cobertura, tasas de incidencia, ratios y otras unidades de análisis calculadas. Un indicador se compone de un factor (por ejemplo 1, 10, 100, ), un numerador y un denominador, los dos últimos siendo expresiones obtenidas a partir de uno o varios elementos de datos. A modo de ejemplo, el indicador "Cobertura BCG <1 año" queda definido por una fórmula con factor 100, numerador el número de "dosis BCG entregadas a niños menores de 1 año", y denominador la "población diana menor de 1 año". El indicador "Tasa de exclusión de DPT1 a DPT3" es una fórmula de 100 % x ("Dosis entregadas DPT1"-"Dosis entregadas DPT3") / ("Dosis entregadas DPT1") La mayoría de los módulos de reporte en DHIS 2 soportan tanto elementos de datos como indicadores y podemos incluso combinarlos en reportes personalizados. Pero la diferencia más importante y la ventaja de los indicadores frente a los datos en bruto (los valores de los datos en los elementos de datos) es la capacidad para comparar datos a través de áreas geográficas distintas (por ejemplo, áreas muy pobladas frente a áreas rurales) ya que la población diana puede utilizarse como denominador. 11