dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #20262
[Branch ~dhis2-documenters/dhis2/dhis2-docbook-docs] Rev 632: Updated chapter 1 of user documentation (Spanish)
------------------------------------------------------------
revno: 632
committer: Inés Bebea <ines.bebea@xxxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Wed 2012-12-05 00:52:44 +0100
message:
Updated chapter 1 of user documentation (Spanish)
modified:
src/docbkx/es/dhis2_implementation_guide_installation.xml
src/docbkx/es/dhis2_user_man_introduction.xml
--
lp:~dhis2-documenters/dhis2/dhis2-docbook-docs
https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs
Your team DHIS 2 developers is subscribed to branch lp:~dhis2-documenters/dhis2/dhis2-docbook-docs.
To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs/+edit-subscription
=== modified file 'src/docbkx/es/dhis2_implementation_guide_installation.xml'
--- src/docbkx/es/dhis2_implementation_guide_installation.xml 2012-10-22 17:08:59 +0000
+++ src/docbkx/es/dhis2_implementation_guide_installation.xml 2012-12-04 23:52:44 +0000
@@ -362,6 +362,15 @@
<para>El cron se configura con dos ficheros. El primero es un <emphasis role="italic">script</emphasis> de backup que realiza la tarea misma de hacer la copia de seguridad de la base de datos. Utiliza un programa PostgreSQL llamado <emphasis role="italic">pg_dump</emphasis> para crear la copia de la base de datos. El segundo es un fichero crontab que lanza el script de backup cada día a las 23:00. Notemos que este script hace la copia de seguridad de la base de datos y la guarda en un fichero en el disco local. Es muy recomendable guardar una copia de esto también fuera del servidor donde se aloja la aplicación. Esto podemos conseguirlo con la herramienta <emphasis role="italic">scp</emphasis>. Deberemos asegurarnos de que hemos fijado la fecha y hora del sistema correctamente en nuestro servidor.</para>
</section>
<section>
+ <title>Trabajando con la base de datos PostgreSQL</title>
+ <para>Algunas operaciones frecuentes al gestionar una instancia DHIS son las copias y restauraciones de bases de datos. Para realizar una copia (dump) de nuestra base de datos, asumiendo la configuración mencionada en la sección de instalación, podemos invocar lo siguiente: </para>
+ <screen>pg_dump dhis2 -U dhis -f dhis2.sql</screen>
+ <para>El primer argumento (dhis2) se refiere al nombre de la base de datos. El segundo argumento (dhis) se refiere al usuario de la base de datos. El último argumento (dhis2.sql) es el nombre de fichero de la copia. Si queremos comprimir el fichero copiado inmediatemente podemos hacer lo siguiente:</para>
+ <screen>pg_dump dhis2 -U dhis | gzip > dhis2.sql.gz</screen>
+ <para>Para restaurar esta copia en otro sistema, primero necesitamos crear una base de datos vacía como se describe en la sección de instalación. También necesitamos descomprimir la copia si habíamos creado una versión comprimida. Podemos invocar entonces:</para>
+ <screen>psql -d dhis2 -U dhis -f dhis2.sql</screen>
+ </section>
+ <section>
<title>Usando los Servicios Web Amazon</title>
<para>Los Servicios Web Amazon (AWS) ofrecen recursos virtuales de cloud-computing que permiten a desarrolladores e implementadores escalar rápidamente una aplicación, tanto horizontal como verticalmente, de forma eficaz en cuanto a costes. AWS ofrece múltiples sistemas operativos y tamaños de instancias dependiendo de la naturaleza concreta del despliegue. Esta sección descrie un montaje sencillo con el sistema AWS Elastic Cloud Compute (EC2) utilizando Amazon AMI Basic 32 bit, que se basa en la distribución Red Hat Linux. </para>
<para>Podemos estimar el coste de una instancia AWS usando el <ulink url="http://calculator.s3.amazonaws.com/calc5.html";> "Simple Monthly Calculator"</ulink>. Los costes de AWS se basan directamente en su uso. A medida que crece el uso de nuestra aplicación, podemos proveer con nuevos servidores. </para>
=== modified file 'src/docbkx/es/dhis2_user_man_introduction.xml'
--- src/docbkx/es/dhis2_user_man_introduction.xml 2012-11-14 11:31:46 +0000
+++ src/docbkx/es/dhis2_user_man_introduction.xml 2012-12-04 23:52:44 +0000
@@ -3,351 +3,275 @@
<chapter>
<title>¿Qué es DHIS2?</title>
<highlights>
- <para>After reading this chapter you will be able to understand:</para>
+ <para>Después de leer este capítulo habremos comprendido:</para>
<itemizedlist>
<listitem>
- <para>What is DHIS 2 and what purpose it serves with respect to
- health information systems (HIS)?</para>
- </listitem>
- <listitem>
- <para>What are the major technological considerations when it comes to deploying DHIS 2, and what are the options are for extending DHIS 2 with new modules?</para>
- </listitem>
- <listitem>
- <para>What is the difference between patient based and aggregate data?</para>
- </listitem>
- <listitem>
- <para>What are some of the benefits and challenges with using Free and Open Source Software (FOSS) for HIS?</para>
+ <para>Qué es DHIS2 y qué finalidad tiene en el marco de los Sistemas de Información de Salud (SIS)</para>
+ </listitem>
+ <listitem>
+ <para>Cuáles son las principales consideraciones tecnológicas que deberemos tener en cuenta para desplegar un sistema basado en DHIS2, y qué opciones existen para ampliar el aplicativo DHIS2 con nuevos módulos</para>
+ </listitem>
+ <listitem>
+ <para>Qué diferencias hay entre datos agregados y datos de paciente</para>
+ </listitem>
+ <listitem>
+ <para>Qué beneficios y dificultades conlleva la utilización de software libre y de código abierto (FOSS) en un SIS</para>
</listitem>
</itemizedlist>
</highlights>
<section id="mod1_1">
<title>Antecedentes de DHIS2</title>
- <para>The DHIS 2 is a tool for collection, validation, analysis, and presentation of aggregate statistical data, tailored (but not limited) to integrated health information management activities. It is a generic tool rather than a pre-configured database application, with an open meta-data model and a flexible user interface that allows the user to design the contents of a specific information system without the need for programming. DHIS 2 and upwards is a modular web-based software package built with free and open source Java frameworks.</para>
- <para>DHIS 2 is open source software released under the BSD license and can be used at no cost. It runs on any platform with a JRE 6 (or higher) installed. Simply download (from dhis2.org), unpack and run the executable file and you are good to go.</para>
- <para>The DHIS 2 is developed by the Health Information Systems Programme (HISP) as an open and globally distributed process with developers currently in India, Vietnam, Tanzania, Ireland, and Norway. The development is coordinated by the University of Oslo with core support from Norad. </para>
- <para>As of October 2012, the DHIS 2 software is used in more than 30 countries in Africa, Asia, and Latin America, and countries that have adopted DHIS 2 as their nation-wide HIS software include Kenya, Tanzania, Uganda, Rwanda, Ghana, Liberia, and Bangladesh. A rapidly increasing number of countries and organisations are starting up new deployments.</para>
- <para>The documentation provided in herewith, will attempt to provide a comprehensive overview of the application. Given the abstract nature of the application, this manual will not serve as a complete step-by-step guide of how to use the application in each and every circumstance, but rather will seek to provide illustrations and examples of how DHIS2 can be implemented in a variety of situations through generalized examples.</para>
- <para>Before implementing DHIS 2 in a new setting we highly recommend reading the DHIS 2 Implementation Guide (a separate manual from this one), also available at dhis2.org.</para>
+ <para>DHIS2 es una herramienta para la recolección, validación, análisis y presentación de datos estadísticos agregados, hecho a medida de (pero no limitado a) actividades de gestión integral de información de salud. Es más una herramienta genérica que una aplicación de base de datos preconfigurada, con un modelo de metadatos abierto y una interfaz de usuario flexible que permite al usuario diseñar los contenidos de un sistema específico de información sin necesidad de códigos de programación. DHIS2 y sus extensiones son un paquete software web y modular elaborado con entornos de código libre y abierto Java.</para>
+ <para>DHIS2 es software de código abierto publicado bajo la licencia BSD y puede utilizarse sin coste alguno. Funciona en cualquier plataforma que tenga instalado JRE 6 (o una versión superior). Simplemente se descarga (de dhis2.org), se desempaqueta, se lanza el fichero ejecutable y estamos listos para comenzar.</para>
+ <para>DHIS2 ha sido desarrollado por el Health Information Systems Programme (HISP) en un proceso abierto y distribuido globalmente con desarrolladores que actualmente están en India, Vietnam, Tanzania, Irlanda y Noruega. El desarrollo está coordinado desde la Universidad de Oslo con un soporte principal de Norad.</para>
+ <para>En Octubre de 2012, el software DHIS2 se utiliza en los sistemas de salud de más de 30 países en África, Asia y Latinoamérica, y entre los países que han adoptado DHIS2 como software de SIS nacional están KEnia, Tanzania, Uganda, Ruanda, Ghana, Liberia y Bangladesh. Un número creciente de países y organizaciones esán comenzando nuevos despliegues con DHIS2.</para>
+ <para>La documentación ofrecida aquí trata de ofrecer una panorámica global de la aplicación. Dada la naturaleza abstracta de la aplicación, este manual no sirve como una guía paso a paso detallada de cómo utilizar la aplicación en cada circunstancia, sino más bien ofrece ilustraciones y ejemplos de cómo DHIS2 puede implementarse en varias situaciones mediante ejemplos generalizados.</para>
+ <para>Antes de implementar DHIS2 en un nuevo despliegue, recomendamos fuertemente la lectura de la Guía de Implementación de DHIS2 (un manual distinto de este), también disponible en dhis2.org.</para>
</section>
<section>
<title>Las características clave y el propósito de DHIS 2</title>
- <para>The key features and purpose of DHIS 2 can be summarised as follows:</para>
+ <para>Las características clave y el propósito de DHIS2 pueden resumirse como sigue:</para>
<itemizedlist>
<listitem>
- <para>Provide a comprehensive HIS solution based on data
- warehousing principles and a modular structure which can easily be
- customised to the different needs of the health systems - and supports the idea of an integrated HIS at all levels of the health hierarchy.</para>
- </listitem>
- <listitem>
- <para>Customisation and local adaptation through the user interface. No programming required to start using DHIS 2 in a new setting (country, region, district etc.).</para>
- </listitem>
- <listitem>
- <para>Provide data entry tools which can either be in the form
- of standard lists or tables, or can be
- customised to replicate paper forms.</para>
- </listitem>
- <listitem>
- <para>Provide different kinds of tools for data validation and
- improvement of data quality.</para>
- </listitem>
- <listitem>
- <para>Provide easy to use - one-click reports with charts and tables for selected indicators or summary reports using the design of the data collection tools. Integration with popular external report design tools like iReport and BIRT allows super-users to flexibly add more custom reports accessible to all users.</para>
- </listitem>
- <listitem>
- <para>Flexible and dynamic (on-the-fly) data analysis in the Data Visualizer and the GIS modules.</para>
- </listitem>
- <listitem>
- <para>A user-specific dashboard for quick access to the relevant monitoring and evaluation tools including indicator charts and links to favourite reports, maps and other key resources in the system.</para>
- </listitem>
- <listitem>
- <para>Easy to use user-interfaces for metadata management e.g. for adding/editing datasets or health facilities. No programming needed to set up the system in a new setting.</para>
- </listitem>
- <listitem>
- <para>Functionality to design and modify calculated indicator formulas.</para>
- </listitem>
- <listitem>
- <para>User management
- module for passwords, security, and fine-grained access control (user roles).</para>
- </listitem>
- <listitem>
- <para>Messages can be sent to system users for feedback and notifications. Messages can also be delivered to email and SMS.</para>
- </listitem>
- <listitem>
- <para>Users can share and discuss their data in charts and reports using Interpretations, enabling an active information-driven user community.</para>
- </listitem>
- <listitem>
- <para>Functionalities of export-import of data and metadata, supporting synchronisation of offline installations as well as interoperability with other applications.</para>
- </listitem>
- <listitem>
- <para>Integration with other software systems – using the DHIS 2 Web-API and the Integration Engine.</para>
- </listitem>
- <listitem>
- <para>Further modules can be
- developed and integrated as per user needs, either as part of the DHIS 2 portal user interface or a more loosely-coupled external application interacting through the DHIS 2 Web-API.</para>
+ <para>Ofrecer una solución SIS exhaustiva focalizada en principios de almacenamiento de datos y en una estructura modular que puede personalizarse fácilmente para las distintas necesidades de los sistemas de salud - y sostiene la idea de un SIS integrado a todos los niveles de la jerarquía de salud.</para>
+ </listitem>
+ <listitem>
+ <para>Capacidad para personalizar y adaptar localmente mediante el interfaz de usuario. No es preciso programar código para empezar a utilizar DHIS2 en un nuevo despliegue (país, región, distrito, etc.).</para>
+ </listitem>
+ <listitem>
+ <para>Ofrecer herramientas de entrada de datos que pueden ser del tipo de listas o tablas estándar, o que pueden ser personaliadas para replicar los formularios en papel.</para>
+ </listitem>
+ <listitem>
+ <para>Ofrecer diferentes tipos de herramientas para la validación de los datos y para la mejora de la calidad de los datos.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Ofrecer reportes fáciles de usar en un sólo click, con gráficas y tablas para los indicadores seleccionados o reportes resumen utilizando el diseño de las herramientas de recolección de datos. También es posible la integración con herramientas de diseño de reportes externas y populares como iReport o BIRT, permitiendo a los usuarios añadir más reportes personalizados de forma flexible y accesibles a todos los usuarios.</para>
+ </listitem>
+ <listitem>
+ <para>Análisis de datos flexible y dinámico (en tiempo real) en la herramienta de Visualizador de Datos y en el módulo SIG.</para>
+ </listitem>
+ <listitem>
+ <para>Un panel de control (dashboard) para cada usuario con acceso rápido a las herramientas relevantes de monitoreo y evaluación incluidas las gráficas de indicadores y enlaces a los reportes favoritos, mapas y otros recursos clave en el sistema.</para>
+ </listitem>
+ <listitem>
+ <para>Interfaces de usuario sencillas de utilizar para la gestión de metadatos, por ejemplo para añadir o editar sets de datos o establecimientos de salud. No es necesaria la programación de código para poner en marcha el sistema en un nuevo despliegue.</para>
+ </listitem>
+ <listitem>
+ <para>Funcionalidad para diseñar y modificar las fórmulas calculadas de los indicadores.</para>
+ </listitem>
+ <listitem>
+ <para>Módulo de gestión de usuarios para las contraseñas, seguridad y control fino de acceso (roles de usuario).</para>
+ </listitem>
+ <listitem>
+ <para>Es posible enviar mensajes a los usuarios del sistema de cara a obtener retroalimentación y avisos. Los mensajes también pueden entregarse en formato de email y como SMS.</para>
+ </listitem>
+ <listitem>
+ <para>Los usuarios pueden compartir y discutir sus datos en gráficas y reportes utilizando "Interpretaciones", favoreciendo una comunidad de usuarios con base activa en la información.</para>
+ </listitem>
+ <listitem>
+ <para>Funcionalidades de exportación-importación de datos y metadatos, apoyando la sincronización de las instalaciones offline así como la interoperabilidad con otras aplicaciones.</para>
+ </listitem>
+ <listitem>
+ <para>Integración con otros sistemas software - utilizando el API-Web de DHIS2 y el Motor de Integración.</para>
+ </listitem>
+ <listitem>
+ <para>Existe la posibilidad de desarrollar e integrar nuevos módulos para dar respuesta a necesidades específicas de los usuarios, ya sea como parte del interfaz de usuario del portal de DHIS2 o como una aplicación externa acoplada que interactúe a través del API-Web de DHIS2.</para>
</listitem>
</itemizedlist>
- <para>In summary, DHIS2 provides a comprehensive HIS solution for the
- reporting and analysis needs of health information users at any level.</para>
+ <para>En resumen, DHIS2 facilita una solución integral de SIS para las necesidades de reporte y análisis de los usuarios de información de salud a cualquier nivel.</para>
</section>
<section>
<title>Utilización de DHIS2 en el SIS: registro, procesado, interpretación y análisis de los datos</title>
- <para>The wider context of HIS can be comprehensively described through
- the information cycle presented in Figure 1.1 below. The information
- cycle pictorially depicts the different components, stages and processes
- through which the data is collected, checked for quality, processed,
- analysed and used.</para>
+ <para>El contexto amplio de un SIS puede entenderse integralmente mediante el ciclo de la información presentado en la Figura 1.1. El ciclo vida de la información plasma gráficamente los distintos componentes, etapas y procesos por los cuales los datos se recogen, comprueban según calidad, procesan, analizan y utilizan.</para>
<figure>
- <title>The health information cycle</title>
+ <title>El ciclo de vida de la información en salud</title>
<mediaobject>
<imageobject>
<imagedata width="60%" align="center" fileref="resources/images/dhis2UserManual/dhis2_information_cycle.png"/>
</imageobject>
</mediaobject>
</figure>
- <para>DHIS 2 supports the different facets of the information cycle
- including:<itemizedlist>
- <listitem>
- <para>Collecting data.</para>
- </listitem>
- <listitem>
- <para>Running quality checks.</para>
- </listitem>
- <listitem>
- <para>Data access at multiple levels.</para>
- </listitem>
- <listitem>
- <para>Reporting.</para>
- </listitem>
- <listitem>
- <para>Making graphs and maps and other forms of analysis.</para>
- </listitem>
- <listitem>
- <para>Enabling comparison across time (for example, previous
- months) and space (for example, across facilities and
- districts).</para>
- </listitem>
- <listitem>
- <para>See trends (displaying data in time series to see their min
- and max levels).</para>
+ <para>DHIS2 participa en las diferentes facetas del ciclo de vida de la información, donde se incluyen:
+ <itemizedlist>
+ <listitem>
+ <para>Recogida de datos.</para>
+ </listitem>
+ <listitem>
+ <para>Realización de chequeos de calidad.</para>
+ </listitem>
+ <listitem>
+ <para>Acceso a los datos a múltiples niveles.</para>
+ </listitem>
+ <listitem>
+ <para>Reporte.</para>
+ </listitem>
+ <listitem>
+ <para>Elaboración de gráficas, mapas y otras formas de análisis.</para>
+ </listitem>
+ <listitem>
+ <para>Posibilidad de comparaciones a lo largo del tiempo (por ejemplo, frente a meses anteriores) y del espacio (por ejemplo, entre distintos establecimientos y distritos).</para>
+ </listitem>
+ <listitem>
+ <para>Detección de tendencias (mostrando datos en series temporales para verificar niveles máximos y mínimos tolerados).
+ </para>
</listitem>
</itemizedlist>
</para>
- <para>As a first step, DHIS 2 serves as a data collection, recording and
- compilation tool, and all data (be it in numbers or text form) can be
- entered into it. Data entry can be done in lists of data elements or in
- customised user defined forms which can be developed to mimic paper based forms in order to ease the process of data entry.</para>
- <para>As a next step, DHIS 2 can be used to increase data quality.
- Firstly, at the point of data entry, a check can be made to see if data
- falls within acceptable range levels of minimum and maximum values for
- any particular data element. Such checking, for example, can help to
- identify typing errors at the time of data entry. Further, user can
- define various validation rules, and DHIS 2 can run the data through the
- validation rules to identify violations.</para>
- <para>When data has been entered and verified, DHIS 2 can help to make
- different kinds of reports. The first kind are the routine reports that
- can be predefined, so that all those reports that need to be routine
- generated can be done on a click of a button. Further, DHIS 2 can help
- in the generation of analytical reports through comparisons of for
- example indicators across facilities or over time. Graphs, maps, reports
- and health profiles are among the outputs that DHIS 2 can produce, and
- these should routinely be produced, analysed, and acted upon by health
- managers.</para>
+ <para>En un primer paso, DHIS2 sirve como herramienta para la recogida, registro y compilación de datos, y todos los datos (ya sea en forma de números o texto) pueden introducirse en la aplicación. La entrada de datos puede hacerse en listas de elementos de datos o mediante formularios definidos por los usuarios, que pueden elaborarse a imagen y semejanza de los formularios en papel para facilitar a los usuarios el proceso de registro de datos.</para>
+ <para>En un segungo paso, DHIS2 puede utilizarse para aumentar la calidad de los datos. Por un lado, en los puntos de entrada de datos puede realizarse un chequeo para verificar si los datos cuadran en rangos aceptables entre valores máximos y mínimos para cada elemento de datos particular. Este chequeo puede ayudar, por ejemplo, a identificar errores producidos al momento de meter los datos. Por otro lado, los usuarios pueden definir reglas de validación, y DHIs2 puede lanzar comprobaciones de estas reglas de validación sobre los datos para detectar infracciones.</para>
+ <para>Luego, cuando ya se han introducido y verificado los datos, DHIS2 puede ayudar a realizar diferentes tipos de reportes. El primer tipo de reporte es el rutinario que necesita ser predefinido, de modo que todos los reportes que sean generados en rutina puedan obtenerse con un click. Adrmás, DHIS2 puede ayudar en la generación de reportes analíticos mediante por ejemplo comparaciones de indicadores en distintos establecimientos de salud o a lo largo del tiempo. Algunas de las salidas de análisis que puede producir DHIS2 son gráficas, mapas, reportes y perfiles de salud. Todos ellos deberían ser producidos, analizados y servir de base para intervenciones de salud por parte de los gestores de salud.</para>
</section>
<section>
<title>Antecedentes tecnológicos</title>
<section>
- <title>DHIS as a platform</title>
- <para>DHIS can be perceived as a platform on several levels. First, the application database is designed ground-up with flexibility in mind. Data structures such as data elements, organisation units, forms and user roles can be defined completely freely through the application user interface. This makes it possible for the system to be adapted to a multitude of locale contexts and use-cases. We have seen that DHIS supports most major requirements for routine data capture and analysis emerging in country implementations. It also makes it possible for DHIS to serve as management system for domains such as logistics, labs and finance.</para>
- <para>Second, due to the modular design of DHIS it can be extended with additional software modules. These software modules can live side by side with the core modules of DHIS and can be integrated into the DHIS portal and menu system. This is a powerful feature as it makes it possible to extend the system with extra functionality when needed, typically for country specific requirements as earlier pointed out.</para>
- <para>The downside of the software module extensibility is that it puts several constraints on the development process. The developers creating the extra functionality are limited to the DHIS technology in terms of programming language and software frameworks, in addition to the constraints put on the design of modules by the DHIS portal solution. Also, these modules must be included in the DHIS software when the software is built and deployed on the web server, not dynamically during run-time. </para>
- <para>In order to overcome these limitations and achieve a looser coupling between the DHIS service layer and additional software artifacts, the DHIS development team decided to create a Web API. This Web API complies with the rules of the REST architectural style. This implies that:</para>
+ <title>DHIS2 como plataforma</title>
+ <para>DHIS2 puede entenderse como una plataforma con muchos niveles. Primero, la base de datos de la aplicación está diseñada de abajo a arriba con un enfoque de flexibilidad. Las estructuras de datos como son los elementos de datos, las unidades organizativas, los formularios y los roles de los usuarios pueden definirse de forma totalmente libre desde el interfaz de usuario de la aplicación. Esto posibilita que el sistema pueda adaptarse a múltiples contextos locales y casos de uso. Hemos visto que DHIS2 soporta los requisitos más importantes para la captura y el análisis rutinarios de datos necesarios en implementaciones nacionales. Esto hace que DHIS2 pueda servir también como sistema de gestión para dominios específicos como logística, laboratorios y contabilidad.</para>
+ <para>En segundo lugar, gracias a su diseño modular DHIS2 puede extenderse con módulos software adicionales. Estos módulos software pueden convivir con los módulos centrales de DHIS2, e integrarse en el portal DHIS y en el sistema de menús. Es una caractarística potente que permite extender el sistema con funcionalidad extra cuando se requiera, típicamente para requisitos específicos del país, como se apuntó anteriormente.</para>
+ <para>La otra cara del módulo de extensión software es que impone varias limitaciones al proceso de desarrollo. Los desarrolladores que crean funcionalidad extra están limitados a la tecnología DHIS en términos de lenguaje de programación y de entornos software, además de las limitaciones ya mencionadas para el diseño de los módulos para la solución de portal web DHIS. Estos módulos deben incluirse en el software DHIS cuando se compila el software y se despliega en un servidor, no se pueden añadir dinámicamente en tiempo de ejecución.</para>
+ <para>Para superar estas limitaciones y lograr un acercamiento entre el nivel de servicio DHIS y otras piezas adicionales de software, el equipo de desarrollo de DHIS decidió crear el API Web. Este API-Web cumple con las normas de estilo arquitectónico REST. Esto implica que:</para>
<itemizedlist>
<listitem>
- <para>The Web API provides a navigable and machine-readable interface to the complete DHIS data model. For instance, one can access the full list of data elements, then navigate using the provided hyperlink to a particular data element of interest, then navigate using the provided hyperlink to the list of forms which this data element is part of. E.g. clients will only do state transitions using the hyperlinks which are dynamically embedded in the responses.</para>
- </listitem>
- <listitem>
- <para>Data is accessed through a uniform interface (URLs) using a well-known protocol. There are no fancy transport formats or protocols involved - just the well-tested, well-understood HTTP protocol which is the main building block of the Web today. This implies that third-party developers can develop software using the DHIS data model and data without knowing the DHIS specific technology or complying with the DHIS design constraints. </para>
- </listitem>
- <listitem>
- <para>All data including meta-data, reports, maps and charts, known as resources in REST terminology, can be retrieved in most of the popular representation formats of the Web of today, such as HTML, XML, JSON, PDF and PNG. These formats are widely supported in applications and programming languages and gives third-party developers a wide range of implementation options.</para>
+ <para>El API Web proporciona un interfaz navegable y también de lenguaje-máquina para completar el modelo de datos DHIS. Por ejemplo, podemos acceder a la lista completa de elementos de datos, luego navegar utilizando el hipervínculo a un elemento de datos que nos interese en particular, luego navegar utilizando el hipervínculo a la lista de formularios de los cuales este elemento de datos forma parte. Por ejemplo, los clientes solo harán transiciones de estado utilizando hipervínculos que se incrustan dinámicamente en las respuestas de la base de datos.</para>
+ </listitem>
+ <listitem>
+ <para>Los datos son accedidos mediante un interfaz uniforme (URLs) utilizando un protocolo reconocido. No hay formatos o protocolos de transporte extravagantes - solo el protocolo HTTP ampliamente probado y entendido, que es el bloque fundamental de la Web actual. Esto implica que los desarrolladores de terceros pueden desarrollar software utilizando el modelo de datos y los datos de DHIS sin conocer la tecnología específica o sin cumplir a las restricciones de diseño de DHIS.</para>
+ </listitem>
+ <listitem>
+ <para>Todos los datos incluidos metadatos, reportes, mapas y gráficas, que consideramos "recursos" en terminología REST, pueden obtenerse en los formatos de representación de datos más populares de la Web como HTML, XML, JSON, PDF y PNG. Estos formatos son ampliamente soportados en aplicaciones y lenguajes de programación y permiten a los desarrolladores de terceros un amplio abanico de opciones de implementación.</para>
</listitem>
</itemizedlist>
<graphic fileref="resources/images/implementation_guide/dhis_platform.png" format="PNG" width="80%" align="center"/>
</section>
<section>
- <title>Understanding platform independence</title>
- <para>All computers have an Operating System (OS) to manage it and the
- programs running it. The operating system serves as the middle layer between the
- software application, such as DHIS 2, and the hardware, such as the
- CPU and RAM. DHIS 2 runs on the Java Virtual Machine, and can therefore run on any operating system which supports Java. Platform
- independence implies that the software application can run on ANY OS -
- Windows, Linux, Macintosh etc. DHIS 2 is platform independent, and is
- extremely useful in the context of public health, where multiple operating systems may be in use.</para>
- <para>Furthermore, DHIS 2 is also platform independent when it comes to the Database Management System (DBMS). DHIS 2 uses the Hibernate database abstraction framework and is compatible with any DBMS supported by Hibernate, such as PostgreSQL, MySQL, H2, MS SQL Server, Oracle and many more. PostgreSQL is the recommended DBMS for DHIS 2.</para>
+ <title>Comprendiendo la independencia de plataforma</title>
+ <para>Todas las computadoras tienen un Sistema Operativo (SO) para manejarlas y manejar los programas instalados. El sistema operativo sirve como nivel intermedio entre la aplicación software, como DHIs2, y el hardware, como la CPU o la memoria RAM. DHIS2 funciona en la Máquina Virtual de Java, y por eso puede funcionar en cualquier sistema operativo que soporte Java. La independencia de plataforma significa que la aplicación software puede ejecutarse en cualquier SO: Windows, Linux, Macintosh, etc. DHIS2 es independiente de plataforma, y es extremadamente útil en el contexto de salud pública, donde pueden estar en uso múltiples sistemas operativos distintos.</para>
+ <para>Más allá, DHIS2 es también independiente de plataforma en relación al Sistema de Gestión de Base de Datos. DHIS2 utiliza el entorno de abstracción de bases de datos Hibernate y es compativle con cualquier sistema soportado por Hibernate, como PostgreSQL, MySQL, H2, MS SQL Server, Oracle y muchos otros. PostgreSQL es el sistema de base de datos recomendado para DHIS2.</para>
</section>
+
<section>
<title>Estrategias de despliegue - conectado (online) o desconectado (offline) </title>
- <para>DHIS 2 is a network enabled application and can be accessed over the Internet, a local intranet and as a locally installed system. The deployment alternatives for DHIS 2 are in this chapter defined as i) offline deployment ii) online deployment and iii) hybrid deployment. The meaning and differences will be discussed in the following sections.</para>
- <section>
- <title>Despliegue Offline</title>
- <para>An offline deployment implies that multiple standalone offline instances are installed for end users, typically at the district level. The system is maintained primarily by the end users/district health officers who enters data and generate reports from the system running on their local server. The system will also typically be maintained by a national super-user team who pay regular visits to the district deployments. Data is moved upwards in the hierarchy by the end users producing data exchange files which are sent electronically by email or physically by mail or personal travel. (Note that the brief Internet connectivity required for sending emails does not qualify for being defined as online). This style of deployment has the obvious benefit that it works when appropriate Internet connectivity is not available. On the other side there are significant challenges with this style which are described in the following section.</para>
- <itemizedlist>
- <listitem>
- <para>Hardware: Running stand-alone systems requires advanced hardware in terms of servers and reliable power supply to be installed, usually at district level, all over the country. This requires appropriate funding for procurement and plan for long-term maintenance.</para>
- </listitem>
- <listitem>
- <para>Software platform: Local installs implies a significant need for maintenance. From experience, the biggest challenge is viruses and other malware which tend to infect local installations in the long-run. The main reason is that end users utilize memory sticks for transporting data exchange files and documents between private computers, other workstations and the system running the application. Keeping anti-virus software and operating system patches up to date in an offline environment are challenging and bad practises in terms of security are often adopted by end users. The preferred way to overcome this issue is to run a dedicated server for the application where no memory sticks are allowed and use an Linux based operating system which is not as prone for virus infections as MS Windows.</para>
- </listitem>
- <listitem>
- <para>Software application: Being able to distribute new functionality and bug-fixes to the health information software to users are essential for maintenance and improvement of the system. Relying on the end users to perform software upgrades requires extensive training and a high level of competence on their side as upgrading software applications might a technically challenging task. Relying on a national super-user team to maintain the software implies a lot of travelling.</para>
- </listitem>
- <listitem>
- <para>Database maintenance: A prerequisite for an efficient system is that all users enter data with a standardized meta-data set (data elements, forms etc). As with the previous point about software upgrades, distribution of changes to the meta-data set to numerous offline installations requires end user competence if the updates are sent electronically or a well-organized super-user team. Failure to keep the meta-data set synchronized will lead to loss of ability to move data from the districts and/or an inconsistent national database since the data entered for instance at the district level will not be compatible with the data at the national level.</para>
- </listitem>
- </itemizedlist>
- </section>
- <section>
- <title>Despliegue Online</title>
- <para>An online deployment implies that a single instance of the application is set up on a server connected to the Internet. All users (clients) connect to the online central server over the Internet using a web browser. This style of deployment currently benefits from the huge investments in and expansions of mobile networks in developing countries. This makes it possible to access online servers in even the most rural areas using mobile Internet modems (also referred to as <emphasis role="italic">dongles</emphasis>). </para>
- <para>This online deployment style has huge positive implications for the implementation process and application maintenance compared to the traditional offline standalone style:</para>
- <itemizedlist>
- <listitem>
- <para>Hardware: Hardware requirements on the end-user side are limited to a reasonably modern computer/laptop and Internet connectivity through a fixed line or a mobile modem. There is no need for a specialized server, any Internet enabled computer will be sufficient.</para>
- </listitem>
- <listitem>
- <para>Software platform: The end users only need a web browser to connect to the online server. All popular operating systems today are shipped with a web browser and there is no special requirement on what type or version. This means that if severe problems such as virus infections or software corruption occur one can always resort to re-formatting and installing the computer operating system or obtain a new computer/laptop. The user can continue with data entry where it was left and no data will be lost.</para>
- </listitem>
- <listitem>
- <para>Software application: The central server deployment style means that the application can be upgraded and maintained in a centralized fashion. When new versions of the applications are released with new features and bug-fixes it can be deployed to the single online server. All changes will then be reflected on the client side the next time end users connect over the Internet. This obviously has a huge positive impact for the process of improving the system as new features can be distributed to users immediately, all users will be accessing the same application version, and bugs and issues can be sorted out and deployed on-the-fly.</para>
- </listitem>
- <listitem>
- <para>Database maintenance: Similar to the previous point, changes to the meta-data can be done on the online server in a centralized fashion and will automatically propagate to all clients next time they connect to the server. This effectively removes the vast issues related to maintaining an upgraded and standardized meta-data set related to the traditional offline deployment style. It is extremely convenient for instance during the initial database development phase and during the annual database revision processes as end users will be accessing a consistent and standardized database even when changes occur frequently.</para>
- </listitem>
- </itemizedlist>
- <para>This approach might be problematic in cases where Internet connectivity is volatile or missing in long periods of time. DHIS 2 however has certain features which requires Internet connectivity to be available only only part of the time for the system to work properly, such as the MyDatamart tool presented in a separate chapter in this guide.</para>
- </section>
- <section>
- <title>Despliegue Híbrido</title>
- <para>From the discussion so far one realizes that the online deployment style is favourable over the offline style but requires decent Internet connectivity where it will be used. It is important to notice that the mentioned styles can co-exist in a common deployment. It is perfectly feasible to have online as well as offline deployments within a single country. The general rule would be that districts and facilities should access the system online over the Internet where sufficient Internet connectivity exist, and offline systems should be deployed to districts where this is not the case. </para>
- <para>Defining decent Internet connectivity precisely is hard but as a rule of thumb the download speed should be minimum 10 Kbyte/second and accessibility should be minimum 70% of the time. </para>
- <para>In this regard mobile Internet modems which can be connected to a computer or laptop and access the mobile network is an extremely capable and feasible solution. Mobile Internet coverage is increasing rapidly all over the world, often provide excellent connectivity at low prices and is a great alternative to to local networks and poorly maintained fixed Internet lines. Getting in contact with national mobile network companies regarding post-paid subscriptions and potential large-order benefits can be a wort-while effort. The network coverage for each network operator in the relevant country should be investigated when deciding which deployment approach to opt for as it might differ and cover different parts of the country.</para>
- </section>
- <section>
- <title>Alojamiento del servidor</title>
- <para>The online deployment approach raises the question of where and how to host the server which will run the DHIS 2 application. Typically there are several options:</para>
- <orderedlist>
- <listitem>
- <para>Internal hosting within the Ministry of Health</para>
- </listitem>
- <listitem>
- <para>Hosting within a government data centre</para>
- </listitem>
- <listitem>
- <para>Hosting through an external hosting company</para>
- </listitem>
- </orderedlist>
- <para>The main reason for choosing the first option is often political motivation for having “physical ownership” of the database. This is perceived as important by many in order to “own” and control the data. There is also a wish to build local capacity for server administration related to sustainability of the project. This is often a donor-driven initiatives as it is perceived as a concrete and helpful mission.</para>
- <para>Regarding the second option, some places a government data centre is constructed with a view to promoting and improving the use and accessibility of public data. Another reason is that a proliferation of internal server environments is very resource demanding and it is more effective to establish centralized infrastructure and capacity.</para>
- <para>Regarding external hosting there is lately a move towards outsourcing the operation and administration of computer resources to an external provider, where those resources are accessed over the network, popularly referred to as “cloud computing” or “software as a service”. Those resources are typically accessed over the Internet using a web browser. </para>
- <para>The primary goal for an online server deployment is provide long-term stable and high-performance accessibility to the intended services. When deciding which option to choose for server environment there are many aspects to consider:</para>
- <orderedlist>
- <listitem>
- <para>Human capacity for server administration and operation. There must be human resources with general skills in server administration and in the specific technologies used for the application providing the services. Examples of such technologies are web servers and database management platforms.</para>
- </listitem>
- <listitem>
- <para>Reliable solutions for automated backups, including local off-server and remote backup.</para>
- </listitem>
- <listitem>
- <para>Stable connectivity and high network bandwidth for traffic to and from the server.</para>
- </listitem>
- <listitem>
- <para>Stable power supply including a backup solution.</para>
- </listitem>
- <listitem>
- <para>Secure environment for the physical server regarding issues such as access, theft and fire.</para>
- </listitem>
- <listitem>
- <para>Presence of a disaster recovery plan. This plan must contain a realistic strategy for making sure that the service will be only suffering short down-times in the events of hardware failures, network downtime and more.</para>
- </listitem>
- <listitem>
- <para>Feasible, powerful and robust hardware.</para>
- </listitem>
- </orderedlist>
- <para>All of these aspects must be covered in order to create an appropriate hosting environment. The hardware requirement is deliberately put last since there is a clear tendency to give it too much attention.</para>
- <para>Looking back at the three main hosting options, experience from implementation missions in developing countries suggests that all of the hosting aspects are rarely present in option one and two at a feasible level. Reaching an acceptable level in all these aspects is challenging in terms of both human resources and money, especially when compared to the cost of option three. It has the benefit that is accommodates the mentioned political aspects and building local capacity for server administration, on the other hand can this be provided for in alternative ways.</para>
- <para>Option three - external hosting - has the benefit that it supports all of the mentioned hosting aspects at a very affordable price. Several hosting providers - of virtual servers or software as a service - offer reliable services for running most kinds of applications. Example of such providers are Linode and Amazon Web Services. Administration of such servers happens over a network connection, which most often anyway is the case with local server administration. The physical location of the server in this case becomes irrelevant as that such providers offer services in most parts of the world. This solution is increasingly becoming the standard solution for hosting of application services. The aspect of building local capacity for server administration is compatible with this option since a local ICT team can be tasked with maintaining the externally hosted server.</para>
- <para>An approach for combining the benefits of external hosting with the need for local hosting and physical ownership is to use an external hosting provider for the primary transactional system, while mirroring this server to a locally hosted non-critical server which is used for read-only purposes such as data analysis and accessed over the intranet.</para>
- </section>
- </section>
- </section>
+ <para>DHIS2 es una aplicación en red y puede ser accedida a través de Internet, en una intranet local y como un sistema instalado localmente. Las alternativas de despliegue de DHIS se definen en este capítulo como (1) despliegue offline (desconectado) (2) despliegue online (conectado) y (3) despliegue híbrido. El significado de cada una y las diferencias entre ellas se detallan en las secciones siguientes.</para>
+ <section>
+ <title>Despliegue Offline (Desconectado)</title>
+ <para>Un despligue offline implica que instalamos muchas instancias autónomas offline 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. Típicamente hay también un equipo de superusuarios a nivel nacional que mantiene el sistema y realizar visitas regularmente a los despliegues en distritos. Los usuarios envían los datos hacia arriba en la jerarquía produciendo ficheros de intercambio de datos que se envían electrónicamente por email o físicamente por correo convencional o viajes del personal. Notemos que aunque haya una conexión reducida a Intenret 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 desplique, que se describen a continuación.</para>
+ <itemizedlist>
+ <listitem>
+ <para>Hardware: Tener en funcionamiento sistemas autónomos requiere un hardware más avanzado en términos de instalar servidores y suministro eléctrico fiable, generalmente a nivel de distrito, en todo el país. Esto requiere una financiación apropiada para la adquisición de equipos y la planificación de mantenimiento a largo plazo.</para>
+ </listitem>
+ <listitem>
+ <para>Plataforma software: Las instalaciones locales implican una necesidad importante de mantenimiento. De la experiencia de HISP, el mayor reto son los viruses y otros malwares que tienden a infectar las instalaciones locales a largo plazo. La razón 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 aplicación DHIS. Mantener sofware antivirus y parches de sistema operativo actualizados en un entorno offline es dificultoso y una mala práctica en términos de seguridad muy común entre los usuarios. Tal vez la mejor manera de evitar esto es lanzar un servidor dedicado para la aplicación 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.</para>
+ </listitem>
+ <listitem>
+ <para>Aplicación software: Ser capaces de distribuir nuevas funcionalidades y resolución de <emphasis role="italic">bugs</emphasis> a los usuarios del software de información 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 formación extensiva y un altísimo nivel de competencias de aquel lado, ya que las actualizaciones software pueden incluir alguna tarea técnicamente ariesgada. Delegar en el equipo nacional de superusuarios la tarea de mantener el software directamente, implicará muchos viajes.</para>
+ </listitem>
+ <listitem>
+ <para>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.). Aquí sucede algo parecido al punto anteriormente comentado sobre actualizaciones de software: la distribución de cambios en el set de metadatos en gran número de instalaciones offline requiere usuarios finales muy competentes si las actualizaciones se envían digitalmente o bien un equipo de superusuarios muy bien organizado. Si hay un fallo al mantener la sincronización del set de metadatos, conllevará la pérdida 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 serán compatibles con los datos a nivel nacional.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section>
+ <title>Despliegue Online (Conectado)</title>
+ <para>Un despliegue online implica que una sola instancia de la aplicación DHIS se instala en un servidor conectado a Internet. Todos los usuarios (clientes) se conectan con el servidor central online a través de Internet utilizando un navegador web. Este estilo de implementación suele beneficiarse de las grandes inversiones y extensiones de las redes de comunicaciones de acceso: móviles (celular) y de banda ancha en países en desarrollo. Esto posibilita el acceso a servidores online incluso en las áreas más rurales utilizando modems de Internet móvil (también llamadas <emphasis role="italic">dongles</emphasis>).</para>
+ <para>Esta forma de despliegue online tiene implicaciones muy positivas en el proceso de implementación y en el mantenimiento de la aplicación en comparación con el estilo tradicional desconectado:</para>
+ <itemizedlist>
+ <listitem>
+ <para>Hardware: Los requisitos hardware del lado del usuario se limitan a una computadora o portátil (laptop) razonablemente modernos, y conexión a Internet a través de línea fija o módem celular. No hay necesidad de tener servidores especializados del lado del usuario, sino que cualquier computadora que pueda navegar es suficiente.</para>
+ </listitem>
+ <listitem>
+ <para>Plataforma software: Los usuarios solo necesitan un navegador web para conectarse al servidor online. Hoy en día todos los sistemas operativos populares vienen con un navegador web ya instalado y no hay ningún requisito especial sobre qué tipo o versión de navegador. Lo que esto significa es que si hay problemas graves como infecciones de virus o corrupción 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 podrá seguir introduciendo datos donde lo dejó y no se habrá perdido ningún dato.</para>
+ </listitem>
+ <listitem>
+ <para>Aplicación software: El estilo de despliegue online, es decir, basado en un servidor central, significa que podemos actualizar y mantener la aplicación de manera centralizada. Cuando salen nuevas versiones de DHIS con nuevas funcionalidades y resoluciones de bugs, esto puede aplicarse únicamente al servidor online. Y todos los cambios se reflejarán en el lado del cliente la próxima vez que los usuarios se conecten al servidor a través 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 estarán siemrpe accediendo a la misma versión de la aplicación, y los bugs y complicaciones pueden resolverse e implantarse al momento.</para>
+ </listitem>
+ <listitem>
+ <para>Mantenimiento de la base de datos: De forma similar al punto anteior, los cambios en los metadatos se hacen en el servidor online de forma centralizada y se propagan automáticamente a todos los clientes la próxima 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 offline. Por ejemplo es muy conveniente este estilo durante la fase inicial de desarrollo de la base de datos y durante los procesos anuales de revisión de la base de datos, ya uqe los usuarios estarán accediendo a una base de datos consistente y estandarizada incluso cuando en ella se están produciendo cambios frecuentes.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Este enfoque puede ser problemático en los casos en los que la conexión a Internet es volatil o insuficiente durante largos periodos de tiempo. Sin embargo, DHIS 2 dispone de algunas características que permiten que el requisito de conexión a Internet solo sea necesario en momentos concretos para que el sistema funcione bien, como la herramienta MyDatamart que se explica en un capítulo específico de este Manual.</para>
+ </section>
+ <section>
+ <title>Despliegue Híbrido</title>
+ <para>De la discusión de los puntos anteriores, uno puede darse cuenta de que el estilo de despliegue online es más favorable que el despliegue desconectado, pero requiere conexión a Internet allá donde se use. Es importante tomar en cuenta que los estilos mencionados también pueden coexistir en un un despliegue común. Es perfectamente factible tener despliegues online y offline en un mismo país. La norma general sería que los distritos y establecimientos deberían acceder al sistema online a través de Internet siempre que exista conexión suficiente, y habrá sistemas offline en aquellos distritos donde no se dé el caso.</para>
+ <para>Es difícil definir con precisión cómo es una conexión a Internet suficiente pero podemos poner como regla práctica que la velocidad de descarga debería ser mínimo 10 Kbyte/seg y la disponibilidad devería ser como mínimo el 70% del tiempo. </para>
+ <para>En este sentido los modems de Internet por celular que se puedan conectar a una computadora o portátil para acceder a la red celular son una solución factible y suficiente. La cobertura de Internet móvil está aumentando rápidamente 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 líneas fijas de Internet. Puede resultar un esfuerzo que vale la pena el contactar con las compañías de red móvil nacional y negocias suscripciones de postpago y beneficios potenciales de economía de escala. Es conveniente estudiar la cobertura de red para cada operador de red de telecomunicaciones en el país concreto, a la hora de decidir qué tipo de despliegue arrancar, ya que podrá ser diferente en distintas regiones del país.</para>
+ </section>
+ <section>
+ <title>Alojamiento del servidor</title>
+ <para>El enfoque de despliegue online plantea la cuestión de dónde y cómo alojar el servidor que ejecutará la aplicación DHIS2. Típicamente hay varias opciones posibles:</para>
+ <orderedlist>
+ <listitem>
+ <para>Alojamiento interno en el Ministerio de Salud</para>
+ </listitem>
+ <listitem>
+ <para>Alojamiento en un centro gubernamental de datos</para>
+ </listitem>
+ <listitem>
+ <para>alojamiento a través de una compañía externa de hosting</para>
+ </listitem>
+ </orderedlist>
+ <para>La razón principal para elegir la primera de las opciones es a menudo la motivación política de tener "propiedad física" de la base de datos. Muchos perciben esto como algo importante de cara a "poseer" y controlar los datos. Existe también el deseo de desarrollar capacidad local para la administración del servidor relacionada con la sostenibilidad del proyecto. Esto suele darse en iniciativas lideradas por donantes que perciben así la misión más concreta y servicial.</para>
+ <para>En cuanto a la segunda opción, en algunos lugares se construye un centro gubernamental de datos con la visión de promover y mejorar el uso y acceso a los datos públicos. Otra razón puede ser que la proliferación de entornos internos de servidos demanda muchos recursos y es más eficiente establecer una infraestructura y capacidad centralizadas.</para>
+ <para>Sobre el alojamiento externo, hay recientemente un movimiento hacia la externalización de la operación y administración de recursos informáticos a proveedores externos, donde se accede a esos recursos a través de la red, en lo que se llama popularmente "cloud computing" o "computación en la nube". Esos recursos generalmente se acceden a través de Internet utilizando un navegador web.</para>
+ <para>El objetivo primordial de un despligue de servidor online es proporcionar un acceso estable a largo plazo y de alto rendimiento a los servicios ofrecidos. Cuando decidamos qué opción elegir para un entorno de servidor, deberemos considerar varios aspectos:</para>
+ <orderedlist>
+ <listitem>
+ <para>La capacidad humana de administración y operación del servidor. Debe haber personal con habilidades genéricas para la administración de servidor y en las tecnologías específicas de la aplicación que provee servicios. Ejemplos de estas tecnologías son los servidores web y las plataformas de gestión de bases de datos.</para>
+ </listitem>
+ <listitem>
+ <para>Soluciones fiables para copias de seguridad automatizadas, incluido un servidor local off y backup remoto.</para>
+ </listitem>
+ <listitem>
+ <para>Conectividad estable y buen ancho de banda para el tráfico hacia y desde el servidor.</para>
+ </listitem>
+ <listitem>
+ <para>Fuente de alimentación eléctrica estable, incluida una solución de backup.</para>
+ </listitem>
+ <listitem>
+ <para>Entorno seguro para el servirod físico en términos de acceso, robo y fuego.</para>
+ </listitem>
+ <listitem>
+ <para>Presencia de un plan de recuperación ante desastres. Este plan debe contener una estrategia realista para asegurar que el servicio solo sufrirá caídas breves en los casos de fallo hardware, caída de la red y otros.</para>
+ </listitem>
+ <listitem>
+ <para>Hardware viable, potente y robusto.</para>
+ </listitem>
+ </orderedlist>
+ <para>Todos estos aspectos deben cubrirse para crear un entorno de alojamiento apropiado. El requisito hardware se ha puesto en último lugar deliberadamente debido a que hay una tendencia clara a prestarle demasiada atención, habiendo otros factores más cruciales.</para>
+ <para>Volviendo a las tres principales opciones de alojamiento, la experiencia de misiones de implementación en países en desarrollo sugiere que los aspectos citados rara vez están presentes en las opciones uno y dos a nivel viable. Alcanzar un nivel aceptable en todos esos aspectos es desafiante en términos de recursos humanos y dinero, especialmente al comparar con la tercera opción. Tiene el beneficio de que acomoda los aspectos políticos mencionados y crea capacidades locales para la administración de servidor, aunque por otro lado esto se puede lograr por otras vías.</para>
+ <para>La opción 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 mayoría de aplicaciones posibles. Un ejemplo de estos proveedores son los servidores web de Linode y Amazon. La administración de esos servidores se realiza a través de una conexión de red, lo que sucede también muchas veces en el caso de la administración de un servidor local. La ubicación física del sercidor en este caso es irrelevante ya que esos proveedores ofrecen servicios en muchas partes del mundo. Esta solución se está convirtiendo en un estándar para el alojamiento de los servicios de aplicaciones. El aspecto de crear capacidad local para la administración de servidor es compatible con esta opción ya que un equipo local TIC puede asumir la tarea de mantenimiento del servidor alojado externamente.</para>
+ <para>Una alternativa para combinar las ventajas del alojamiento externo con la necesidad de hosting local y propiedad física es usar un proveedor de hosting externo para el sistema de transacción primario, y copiar (mirror) este servidor a un servidor local no-crítico que se use para solo-lectura como el análisis de datos y que se acceda por una intranet.</para>
+ </section>
+ </section>
+</section>
+
<section>
<title>Diferencias entre datos agregados y datos de paciente en un SIS</title>
- <para>
- <emphasis>Patient data</emphasis> is data relating to a single patient,
- such as his/her diagnosis, name, age, earlier medical history etc. This data is typically based on a single patient-health care worker interaction. For instance, when a patient visits a health care clinic, a variety of details may be recored, such as the patient's temperature, their weight, and various blood tests. Should this patient be diagnosed as having "Vitamin B 12 deficiency anaemia, unspecified" corresponding to ICD-10 code D51.9, this particular interaction might eventually get recorded as an instance of "Anaemia" in an aggregate based system. Patient based data is important when you want to track longitudinally
- the progress of a patient over time. For example, if we want to track
- how a patient is adhering to and responding to the process of TB
- treatment (typically taking place over 6-9 months), we would need
- patient based data.</para>
- <para>
- <emphasis>Aggregated data</emphasis> is the consolidation of data
- relating to multiple patients, and therefore cannot be traced back to a
- specific patient. They are merely counts, such as incidences of Malaria,
- TB, or other diseases. Typically, the routine data that a health
- facility deals with is this kind of aggregated statistics, and is used
- for the generation of routine reports and indicators, and most importantly, strategic planning within the health system. Aggregate data cannot provide the type of detailed information which patient level data can, but is crucial for planning and guidance of the performance of health systems. </para>
- <para>In between the two you have case-based data, or anonymous "patient" data. A lot of details can be collected about a specific health event without necessarily having to identify the patient it involved. Inpatient or outpatient visits, a new case of cholera, a maternal death etc. are common use-cases where one would like to collect a lot more detail that just adding to the total count of cases, or visits. This data is often collected in line-listing type of forms, or in more detailed audit forms. In is different from aggregate data in the sense that it contains many details about a specific event, whereas the aggregate data would count how many events of a certain type, e.g. how many outpatient visits with principal diagnosis "Malaria", or how many maternal deaths where the deceased did not attend ANC, or how many cholera outbreaks for children under 5 years. In DHIS 2 this data is collected through programs of the type single event without registration.</para>
- <para>Patient data is highly confidential and therefore must be
- protected so that no one other than doctors can get it. When in paper,
- it must be properly stored in a secure place. For computers, patient
- data needs secure systems with passwords, restrained access and audit logs.</para>
- <para>Security concerns for aggregated data are not as crucial as for
- patient data, as it is usually impossible to identify a particular person to a aggregate statistic . However,
- data can still be misused and misinterpreted by others, and should not
- be distributed without adequate data dissemination policies in place. </para>
+ <para>Los <emphasis>datos de paciente</emphasis> son datos relativos a un paciente individual, como son su diagnóstico, nombre, edad, historial médico previo, etc. Estos datos generalmente se basan en la interacción 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 sanguíneaos. Si este paciente obtiene un diagnóstico de "Anemia deficiente Vitamina B12, no especificado" correspondiente al código CIE-10 D51.9, esta interacción concreta puede registrarse como una instancia de "Anemia" en un sistema de información 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 cómo un paciente se adhiere y responde a un proceso de tratamiento de TB (que generalmente tiene una duración de 6-9 meses), necesitaremos información de datos de paciente.</para>
+ <para> Los
+ <emphasis>datos agregados</emphasis> son la consolidación de datos relativos a múltiples 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. Típicamente, los datos rutinarios con los que trabaja un establecimiento de salud so este tipo de estadísticas agregadas, y se utilizan para la generación de reportes e indicadores rutinarios, y lo que es más importante, para la planificación estratégica en el sistema de salud. Los datos agregados no pueden proporcionar el tipo de información detallada que dan los datos de nivel de paciente, pero es crucial para la planificación y orientación del funcionamiento de los sistemas de salud.</para>
+ <para>Digamos que entre unos y otros se encuentran los datos relativos a casos, o datos anónimos "de paciente". Es posible recoger numerosos detalles sobre el evento específico de salud sin necesidad de identificar al paciente involucrado. Las visitas de pacientes externos o internos, un nuevo caso de cólera, mortalidad materna, etc. son casos de uso comunes cuando queremos recopilar muchos más detalles que el mero conteo del número total de casos o visitas. Estos datos normalmente se registran en formularios en forma de listado, o en formularios de auditoría más 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 contarían cuántos eventos se producen de un cierto tipo, por ejemplo, cuántas visitas externas con diagnóstico principal "Malaria", o cuántas muertes maternas donde la fallecida no siguió el protocolo ANC, o cuántos brotes de cólera en niños menores de 5 años. En DHIS2 estos datos son recogidos mediante programas de tipo "evento único sin registro".</para>
+ <para>Los datos de paciente son muy confidenciales y por tanto deben ser protegidos para que ninguna persona no autorizada pueda obtenerlos. Cuando están 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.</para>
+ <para>La preocupación 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 estadística agregada. Sin embargo, los datos también pueden ser mal usados o malinterpretados por otros, y no deberían distribuirse sin unas políticas de difusión de datos adecuadas.
+ </para>
</section>
<section>
<title>Software libre y de código abierto (FOSS): beneficios y retos</title>
- <para>Software carries the instructions that tell a computer how to
- operate. The human authored and human readable form of those
- instructions is called source code. Before the computer can actually
- execute the instructions, the source code must be translated into a
- machine readable (binary) format, called the object code. All
- distributed software includes the object code, but <abbrev>FOSS</abbrev> makes the
- source code available as well.</para>
- <para>Proprietary software owners license their copyrighted object
- code to a user, which allows the user to run the program. <abbrev>FOSS</abbrev>
- programs, on the other hand, license both the object and the source
- code, permitting the user to run, modify and possibly redistribute the
- programs. With access to the source code, the users have the freedom
- to run the program for any purpose, redistribute, probe, adapt, learn
- from, customise the software to suit their needs, and release
- improvements to the public for the good of the community. Hence, some
- <abbrev>FOSS</abbrev> is also known as free software, where “free” refers, first and
- foremost, to the above freedoms rather than in the monetary sense of
- the word.</para>
- <para>Within the public health sector, <abbrev>FOSS</abbrev> can potentially have a
- range of benefits, including:</para>
+ <para>El software lleva las instrucciones que indican a una computadora cómo funcionar. La forma legible y con autoría humana de esas instrucciones es denominada código fuente. Antes de que la computadora pueda realmente ejecutar las instrucciones, el código fuente debe traducirse en un formato legible por máquinas (binario), llamado código objeto. Todo el software disponible incluye el código objeto, pero <abbrev>FOSS</abbrev>publica también el código fuente.</para>
+ <para>Los dueños de software propietario licencian su código objeto con copyright a un usuario, lo cual permite a éste ejecutar el programa. Los programas <abbrev>FOSS</abbrev>, sin embargo, licencian tanto el código objeto como el código fuente, permitiendo al usuario no sólo utilizarlo sino también modificar y tal vez distribuir los programas. Teniendo acceso al código 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 públicamente para el bien de la comunidad. Por lo tanto, algun FOSS es conocido también 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 relación a la gratuidad).</para>
+ <para>En el sector de la salud pública, FOSS puede tener muchos beneficios, como por ejemplo:</para>
<itemizedlist>
<listitem>
- <para>Lower costs as it does not involve paying for prohibitive
- license costs.</para>
- </listitem>
- <listitem>
- <para>Given the information needs for the health sector are
- constantly changing and evolving, there is a need for the user to
- have the freedom to make the changes as per the user requirements.
- This is often limited in proprietary systems.</para>
- </listitem>
- <listitem>
- <para>Access to source code to enable integration and interoperability. In the health sector interoperability between different software applications is becoming increasingly important, meaning enabling two or more systems to communicate metadata and data. This work is a lot easier, and sometimes dependent on the source code being available to the developers that create the integration. This availability is often not possible
- in the case of proprietary software. And when it is, it comes at a
- high cost and contractual obligations.</para>
- </listitem>
- <listitem>
- <para>FOSS applications like DHIS 2 typically are supported by a
- global network of developers, and thus have access to cutting edge
- research and development knowledge.</para>
+ <para>Menores costes ya que no implica el pago de costes de licencia prohibitivos.</para>
+ </listitem>
+ <listitem>
+ <para>Dado que las necesidades de información para el sector salud están en constante cambio y evolución, hay una necesidad de que el usuario tenga libertad para hacer los cambios según sus propios requisitos. Esto frecuentemente es muy limitado en sistemas propietarios.</para>
+ </listitem>
+ <listitem>
+ <para>Acceso a código fuente para favorecer la integración e interoperabilidad. La interoperabilidad entre diferentes aplicaciones software en el sector salud está tomando importancia creciente, lo que significa permitir que dos o más sistemas compartan datos y metadatos. Este trabajo es mucho más fácil, y a veces dependiente del código fuente que se disponibiliza a los desarrolladores que hacen la integración. Esta disponibilidad frecuentemente no es posible en el caso del software propietario. Y cuando lo es, supone costes enormes y obligaciones contractuales.</para>
+ </listitem>
+ <listitem>
+ <para>Las aplicaciones FOSS como DHIS2 típicamente están mantenidas por una red global de desarrolladores, y por tanto tiene acceso a conocimiento puntero en investigación y desarrollo (I+D).</para>
</listitem>
</itemizedlist>
</section>
