dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #19783
[Branch ~dhis2-documenters/dhis2/dhis2-docbook-docs] Rev 605: Implementation guide in Spanish: chapter 4 to 7 completed
------------------------------------------------------------
revno: 605
committer: Inés Bebea <ines.bebea@xxxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Tue 2012-10-30 13:51:32 +0100
message:
Implementation guide in Spanish: chapter 4 to 7 completed
added:
src/docbkx/es/resources/images/implementation_guide/data_warehouse.png
src/docbkx/es/resources/images/implementation_guide/dhis_data_warehouse.png
src/docbkx/es/resources/images/implementation_guide/dimensional_approach.png
src/docbkx/es/resources/images/implementation_guide/interoperable_his.png
modified:
src/docbkx/es/dhis2_implementation_guide_data_warehouse.xml
src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml
src/docbkx/es/dhis2_implementation_guide_enduser_training.xml
src/docbkx/es/dhis2_implementation_guide_integration.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_data_warehouse.xml'
--- src/docbkx/es/dhis2_implementation_guide_data_warehouse.xml 2012-09-27 08:55:25 +0000
+++ src/docbkx/es/dhis2_implementation_guide_data_warehouse.xml 2012-10-30 12:51:32 +0000
@@ -2,59 +2,58 @@
<!-- This document was created with Syntext Serna Free. --><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"; []>
<chapter>
<title>DHIS 2 es un Data Warehouse</title>
- <para>This chapter will discuss the role and place of the DHIS 2 application in a system architecture context. It will show that DHIS 2 can serve the purpose of both a data warehouse and an operational system.</para>
+ <para>En este capítulo se discute el rol y el lugar de la aplicación DHIS 2 en un contesto de arquitectura de sistema. Se muestra que DHIS 2 puede servir la propósito tanto de un data warehouse como de un sistema funcional. </para>
<section>
<title>Data warehouse frente a sistemas funcionales</title>
- <para>A <emphasis role="italic">data warehouse</emphasis> is commonly understood as a database used for analysis. Typically data is uploaded from various operational / transactional systems. Before data is loaded into the data warehouse it usually goes through various stages where it is cleaned for anomalies and redundancy and transformed to conform with the overall structure of the integrated database. Data is then made available for use by analysis, also known under terms such as<emphasis role="italic"> data mining </emphasis>and <emphasis role="italic">online analytical processing</emphasis>. The data warehouse design is optimized for speed of data retrieval and analysis. To improve performance the data storage is often redundant in the sense that the data is stored both in its most granular form and in an aggregated (summarized) form.</para>
- <para>A <emphasis role="italic">transactional system</emphasis> (or <emphasis role="italic">operational system</emphasis> from a data warehouse perspective) is a system that collects, stores and modifies low level data. This system is typically used on a day-to-day basis for data entry and validation. The design is optimized for fast insert and update performance.</para>
+ <para>Un <emphasis role="italic">data warehouse</emphasis>, almacén de datos, suele entenderse como una base de datos utilizada para análisis. Típicamente los datos se cargan desde diversos sistemas funcionales u transaccionales. Antes de que los datos se carguen en el data warehouse pasan normalmente por varios estadíos donde se limpia de anomalías y redundancia y se transforma para encajar en la estructura global de la base de datos integrada. Entonces, los datos se disponibilizan para el análisis, también conocido como <emphasis role="italic"> minería de datos </emphasis>y <emphasis role="italic">procesado analítico online</emphasis>. El diseño del almacén de datos está optimizado para acelerar la entrega y análisis de datos. Para mejorar el funcionamiento, el almacenamiento de los datos suele ser redundante en el sentido de que los datos se guardan tanto en su forma granular como agregada.</para>
+ <para>Un <emphasis role="italic">sistema transaccional</emphasis> (o <emphasis role="italic">sistema funcional</emphasis> desde la perspectiva de almacén de datos) es un sistema que recopila, guarda y modifica datos de bajo nivel. Este sistema se usa generalmente en el día a día para la entrada y validación de datos. Su diseño se optimiza para una inserción rápisa y rendimiento en la actualización.</para>
<graphic fileref="resources/images/implementation_guide/data_warehouse.png" format="PNG" width="80%" align="center"/>
- <para>There are several benefits of maintaining a data warehouse, some of them being:</para>
- <itemizedlist>
- <listitem>
- <para><emphasis role="italic">Consistency:</emphasis> It provides a common data model for all relevant data and acts as an abstraction over a potentially high number of data sources and feeding systems which makes it a lot easier to perform analysis.</para>
- </listitem>
- <listitem>
- <para><emphasis role="italic">Reliability:</emphasis> It is detached from the sources where the data originated from and is hence not affected if data in the operational systems is purged or lost.</para>
- </listitem>
- <listitem>
- <para><emphasis role="italic">Analysis performance:</emphasis> It is designed for maximum performance for data retrieval and analysis in contrast to operational system which are often optimized for data capture.</para>
- </listitem>
- </itemizedlist>
- <para>There are however also significant challenges with a data warehouse approach:</para>
- <itemizedlist>
- <listitem>
- <para><emphasis role="italic">High cost:</emphasis> There is a high cost associated with moving data from various sources into a common data warehouse, especially when the operational systems are not similar in nature. Often long-term existing systems (referred to as legacy systems) put heavy constraints on the data transformation process.</para>
- </listitem>
- <listitem>
- <para><emphasis role="italic">Data validity:</emphasis> The process of moving data into the data warehouse is often complex and hence often not performed at regular and timely intervals. This will then leave the data users with out-dated and irrelevant data not suitable for planning and informed decision making.</para>
- </listitem>
- </itemizedlist>
- <para>Due to the mentioned challenges it has lately become increasingly popular to merge the functions of the data warehouse and operational system, either into a single system which performs both tasks or with tightly integrated systems hosted together. With this approach the system provides functionality for data capture and validation as well as data analysis and manages the process of converting low-level atomic data into aggregate data suitable for analysis. This sets high standards for the system and its design as it must provide appropriate performance for both of those functions; however advances in hardware and parallel processing is increasingly making such an approach feasible.</para>
- <para>In this regard, the DHIS 2 application is designed to serve as a tool for both data capture, validation, analysis and presentation of data. It provides modules for all of the mentioned aspects, including data entry functionality and a wide array of analysis tools such as reports, charts, maps, pivot tables and dashboard.</para>
- <para>In addition, DHIS 2 is a part of a suite of interoperable health information systems which covers a wide range of needs and are all open-source software. DHIS 2 implements the standard for data and meta-data exhange in the health domain called SDMX-HD. There are many examples of operational systems which also implements this standard and potenitally can feed data into DHIS 2:</para>
- <itemizedlist>
- <listitem>
- <para>iHRIS: System for management of human resource data. Examples of data which is relevant for a national data warehouse captured by this system is "number of doctors", "number of nurses" and "total number of staff". This data is interesting to compare for instance to district performance.</para>
- </listitem>
- <listitem>
- <para>OpenMRS: Medical record system being used at hospital. This system can potentially aggregate and export data on inpatient diseases to a national data warehouse.</para>
- </listitem>
- <listitem>
- <para>OpenELIS: Laboratory enterprise information system. This system can generate and export data on number and outcome of laboratory tests.</para>
+ <para>Hay numerosos beneficios de mantener un data warehouse, tales como:</para>
+ <itemizedlist>
+ <listitem>
+ <para><emphasis role="italic">Consistencia:</emphasis> Ofrece un modelo común de datos a todos los datos relevantes y actúa como abstracción sobre un gran número de potenciales fuentes de datos y sistemas de alimentación, lo cual facilita mucho realizar el análisis.</para>
+ </listitem>
+ <listitem>
+ <para><emphasis role="italic">Fiabilidad:</emphasis> Está separado de las fuentes donde se originan los datos y por tanto no le afecta si se dañan o pierden datos en los sistemas funcionales.</para>
+ </listitem>
+ <listitem>
+ <para><emphasis role="italic">Rendimiento de análisis:</emphasis> Está diseñado para el máximo rendimiento de devolución y análisis de datos en comparación con sistemas funcionales, generalmente optimizados para la captura de los datos.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Sin embargo, hay también retos significativos en utilizar un data warehouse:</para>
+ <itemizedlist>
+ <listitem>
+ <para><emphasis role="italic">Coste elevado:</emphasis> Hay un coste elevado asociado a mover los datos de varias fuentes a un almacén común de datos, especialmente cuando los sistemas funcionales de origen no son de naturaleza similar. A menudo sistemas a largo plazo (llamodos sistemas heredados) ponen fuertes restricciones al proceso de transformación de datos.</para>
+ </listitem>
+ <listitem>
+ <para><emphasis role="italic">Validez de los datos:</emphasis> El proceso de mover datos al data warehouse suele ser complejo y por tanto no se realiza regularmente, en intervalos frecuentes. Esto deja a los usuarios de datos con datos obsoletos e irrelevantes inadecuados para la planificación y la toma de decisiones informada.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Debido a las dificultades mencionadas, recientemente se ha hecho popular combinar las funciones de data warehouse y de sistema funcional, bien en un único sistema que realiza ambas tareas o bien en sistemas integrados alojados juntos. Con esta solución, el sistema tiene funcionalidades para captura de datos y validación, así como para análisis de datos y gestiona el proceso de convertir datos atómicos de bajo nivel en fatos agregados adecuados para el análisis. Esto fija grandes estándares para el sistema y su diseño, y debe ofrecer un rendimiento apropiada para ambas funciones; sin embargo, los avances en hardware y en procesado paralelo hacen cada vez más viable este enfoque.</para>
+ <para>En este sentido, la aplicación DHIS 2 está diseñada para servir como herramienta tanto para la captura, validación, análisis y presentación de los datos. Incluye módulos para todos estos aspectos, incluidas funcionalidades de entrada de datos y un amplio abanico de herramientas de análisis como reportes, gráficas, mapas, tablas dinámicas y dashboard.</para>
+ <para>Además, DHIS 2 es parte de un grupo de sistemas de información en salud interoperable que cubre un amplio rango de necesidades y que son todos software libre. DHIS 2 implementa el estándar para intercambio de datos y metadatos en el ámbito de la salud llamado SDMX-HD. Hay muchos ejemplos de sistemas funcionales que también implementan este estándar y potencialmente pueden incorporar datos a DHIS 2:</para>
+ <itemizedlist>
+ <listitem>
+ <para>iHRIS: Sistema de gestión de datos de recursos humanos. Ejemplos de datos que son relevantes a un almacén de datos nacional, capturados por este sistema son "número de doctores", "número de enfermeros" y "número total de personal". Estos datos son interesantes para comparar en base al desempeño por distrito.</para>
+ </listitem>
+ <listitem>
+ <para>OpenMRS: Sistema de registro clínico utilizado en hospitales. Este sistema puede potencialemnte agregar y exportar data sobre enfermedades de pacientes ingresados al data warehouse nacional.</para>
+ </listitem>
+ <listitem>
+ <para>OpenELIS: Sistema de información de laboratorio. Este sistema puede generar y exportar datos de la cantidad y el resultado de tests de laboratorio.</para>
</listitem>
</itemizedlist>
<graphic fileref="resources/images/implementation_guide/dhis_data_warehouse.png" format="PNG" width="80%" align="center"/>
</section>
<section>
<title>Estrategia de agregación en DHIS 2</title>
- <para>The analysis tools in DHIS 2 reads aggregated data from <emphasis role="italic">data mart</emphasis> tables. A data mart is a data store optimized for meeting the most common user requests for data analysis. The DHIS 2 data mart contains data aggregated in the<emphasis role="italic"> space dimension</emphasis> (the organisation unit hierarchy), <emphasis role="italic">time dimension</emphasis> (over multiple periods) and for <emphasis role="italic">indicator formulas</emphasis> (mathematical expressions including data elements). Retrieving data directly from data marts provides good performance even in high-concurrency environments since most requests for analysis can be served with a single, simple database query against the data mart. The aggregation engine in DHIS 2 is capable of processing low-level data in the multi-millions and manage most national-level databases, and it can be said to provide <emphasis role="italic">near real-time access</emphasis> to aggregate data.</para>
- <para>DHIS 2 allows for setting up scheduled aggregation tasks which typically will refresh and populate the data mart with aggregated data every night. You can choose between aggregating data for the last 12 months every night, or aggregate data for the last 6 months everry night and the last 6 to 12 months every Saturday. The scheduled tasks can be configured under "Scheduling" in "Data administration" module. It is also possible to execute arbitrary data mart tasks under "Data mart" in "Reports" module.</para>
+ <para>Las herramientas de análisis en DHIS 2 leen datos agregados de las tablas <emphasis role="italic">datamart</emphasis>. Un datamart es un depósito de datos optimizado para garantizar las peticiones más comunes de los usuarios para el análisis. El datamart en DHIS 2 contiene datos agregados en la <emphasis role="italic"> dimensión espacial</emphasis> (la jerarquía de unidades organizativas), <emphasis role="italic">dimensión temporal</emphasis> (en múltiples periodos) y para <emphasis role="italic">fórmulas de indicadores</emphasis> (las expresiones matemáticas que incorporan los elementos de datos). Rescatar los datos directamente de datamarts da buen rendimiento incluso en entornos altamente concurrentes, ya que la mayoría de las peticiones de análisis pueden servirse en una única petición simple a la base de datos contra el datamart. El motor de agregación en DHIS 2 es capaz de procesar datos de bajo nivel del orden de muchos millones y gestionar la mayor parte de bases de datos de nivel nacional, y puede decirse que ofrece <emphasis role="italic">acceso casi en tiempo real</emphasis> para agregar los datos.</para>
+ <para>DHIS 2 permite configurar tareas programadas de agregación que típicamente se refrescan y propagan los datamart con datos agregados cada noche. Podemos elegir entre agregar los datos de los últimos 12 meses cada noche, o agregar los datos de los últimos 6 meses cada noche y de los últimos 6 a 12 meses cada sábado. Las tareas programadas se pueden configurar en "Agendar" en el módulo de "Administración de datos". También es posible ejecutar tareas arbitrarias de datamart en "Datamart" en el módulo de "Reportes".</para>
</section>
<section>
- <title>Enfoque del almacenamiento de datos</title>
- <para>There are two leading approaches for storing data in a data warehouse, namely the <emphasis role="italic">normalized</emphasis> and <emphasis role="italic">dimensional</emphasis> approach. DHIS 2 lends a bit from the former but mostly from the latter. In the dimensional approach the data is partitioned into <emphasis role="italic">dimensions</emphasis> and <emphasis role="italic">facts</emphasis>. Facts generally refers to transactional numeric data while dimensions are the reference data that gives context and meaning to the data. The strict rules of this approach makes it easy for users to understand the data warehouse structure and provides for good performance since few tables must be combined to produce meaningful analysis, while it on the other hand might make the system less flexible and harder to change.</para>
- <para>
-In DHIS the facts corresponds to the data value object in the data model. The data value captures data as numbers, yes/no or text. The <emphasis role="italic">compulsory dimensions</emphasis> which give meaning to the facts are the <emphasis role="italic">data element</emphasis>, <emphasis role="italic">organisation unit hierarchy</emphasis> and <emphasis role="italic">period</emphasis> dimensions. These dimensions are referred to as compulsory since they must be provided for all stored data records. DHIS 2 also has a custom dimensional model which makes it possible to represent any kind of dimensionality. This model must be defined prior to data capture. DHIS 2 also has a flexible model of groups and group sets which makes it possible to add custom dimensionality to the compulsory dimensions after data capture has taken place. You can read more about dimensionality in DHIS 2 in the chapter by the same name.</para>
+ <title>La propuesta de almacenamiento de datos</title>
+ <para>Hay dos propuestas líderes para almacenar datos en un datawarehouse, que son la <emphasis role="italic">normalizada</emphasis> y la <emphasis role="italic">dimensional</emphasis>. DHIS 2 tiene un poco de la primera pero mucho de la segunda. En la propuesta dimensional los datos se particionan en <emphasis role="italic">dimensiones</emphasis> y <emphasis role="italic">hechos</emphasis>. Generalmente los hechos se refieren a datos numéricos transaccionales, mientras las dimensiones son los datos de referencia que dan contexto y significado a los datos. Las reglas estrictas de esta propuesta facilitan que los usuarios comprendan la estructura de data warehouse y dan buenos resultados, ya que unas pocas tablas pueden combinarse para producir análisis significativos, mientras por otro lado puede que hagan el sistema menos flexible y difícil de cambiar.</para>
+ <para>En DHIS los hechos corresponden al objeto valor de los datos en el modelo de datos. El valor de los datos captura los datos como números, sí/no o texto. Las <emphasis role="italic">dimensiones obligatorias</emphasis> que dan significado a los hechos son los <emphasis role="italic">elementos de datos</emphasis>, <emphasis role="italic">la jerarquía de unidades organizativas</emphasis> y <emphasis role="italic">periodo</emphasis>. Estas dimensiones se dicen obligatorias porque deben proporcionarse para todos los registros de datos almacenados. DHIS 2 también tiene un modelo dimensional personalizable, que posibilita representar cualquier tipo de dimensionalidad. Este modelo debe definirse antes de la captura de datos. DHIS 2 también tiene un modelo flexible de grupos y sets de grupos, que hace posible añadir dimensionalidad personalizada a las dimensiones obligatorias después de que se haya realizado la captura de datos. Podremos leer más sobre dimensionalidad en DHIS 2 en el capítulo del mismo nombre.</para>
<graphic fileref="resources/images/implementation_guide/dimensional_approach.png" format="PNG" width="80%" align="center"/>
</section>
</chapter>
=== modified file 'src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml'
--- src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml 2012-10-22 17:08:59 +0000
+++ src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml 2012-10-30 12:51:32 +0000
@@ -14,83 +14,83 @@
<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: 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>
+ <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: 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>
+ <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 Conectado (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>
+ <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: 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>
+ <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>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>
+ <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>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>
+ <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 de 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>
+ <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>
</chapter>
=== modified file 'src/docbkx/es/dhis2_implementation_guide_enduser_training.xml'
--- src/docbkx/es/dhis2_implementation_guide_enduser_training.xml 2012-09-27 08:55:25 +0000
+++ src/docbkx/es/dhis2_implementation_guide_enduser_training.xml 2012-10-30 12:51:32 +0000
@@ -2,59 +2,58 @@
<!-- This document was created with Syntext Serna Free. --><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"; []>
<chapter>
<title>Capacitación de usuarios</title>
- <para>The following topics will be covered in this chapter:</para>
+ <para>En este capítulo se cubren los temas siguientes:</para>
<itemizedlist>
<listitem>
- <para>What training is needed</para>
- </listitem>
- <listitem>
- <para>Strategies for training</para>
- </listitem>
- <listitem>
- <para>Material and courses</para>
+ <para>Qué capacitación se necesita</para>
+ </listitem>
+ <listitem>
+ <para>Estrategias de formación</para>
+ </listitem>
+ <listitem>
+ <para>Materiales y cursos</para>
</listitem>
</itemizedlist>
<section>
<title>Qué capacitación se necesita</title>
- <para>In a large system like a country health information system, there will be different roles for different people. The different tasks usually depends on two factors; what the person will be doing, i.e. mainly collect data, or analyse it, or maintain the database, and where the person is located, like a facility, a district office, or at national level. A first task will then be to define the different users. The most common tasks will be:</para>
+ <para>En un sistema extenso como es un sistema nacional de información de salud, hay diferentes roles para personas distintas. Las diversas tareas suelen depender de dos factores: qué hará esa persona en el sistema (por ejemplo registrar datos, analizarlos, mantener la base de datos..) y dónde estará esa persona (en un establecimiento de salud, en una oficina distrital, a nivel nacional). Nuestra primera labor es entonces definir a los diferentes usuarios. Las tareas más comunes son:</para>
<itemizedlist>
<listitem>
- <para>Data entry</para>
- </listitem>
- <listitem>
- <para>Data analysis processing, preparing reports and other information products</para>
- </listitem>
- <listitem>
- <para>Database maintenance - managing changes to the database</para>
+ <para>Entrada de datos</para>
+ </listitem>
+ <listitem>
+ <para>Procesado de análisis de datos, preparación de reportes y otros productos de información</para>
+ </listitem>
+ <listitem>
+ <para>Mantenimiento de la base de datos - gestión de cambios en la base de datos</para>
</listitem>
</itemizedlist>
- <para>Data entry is typically decentralized to lower levels, such as a district. Data processing takes place at all levels, while database maintenance usually is centralized. The following table gives an example of user groups and what tasks they typically have:</para>
- <para>Note here that many of the tasks are not directly linked to the use of DHIS2. Data analysis, data quality assessment, preparing feedback and planning regular review meetings are all integral to the functioning of the system, and should also be covered in a training strategy.</para>
+ <para>La entrada de datos normalmente está descentralizada en los niveles más bajos, como en los distritos. El procesado de datos tiene lugar a todos los niveles, mientras el mantenimiento de la base de datos es centralizado. La siguiente tabla da un ejemplo de los grupos de usuarios y qué tareas suelen tener:</para>
+ <para>Notemos que muchas de las tareas no están directamente ligadas al uso de DHIS 2. El análisis de datos, la garantía de calidad de datos, la preparación de retroalimentación y la planificación de revisiones regulares son todas tareas integrales de funcionamiento del sistema, y deben cubrirse en una estrategia educativa.</para>
</section>
<section>
<title>Estrategias de capacitación</title>
- <para>To cover the wide array of tasks/users listed above, a training strategy is helpful. The majority of users will be at lower level; entering and using data. Only a few will have to know the database in-depth, usually at national level. The following are useful tips for end-user training strategies.</para>
+ <para>Para cubrir el amplio abanico de tareas y usuarios listado arriba, es imprescindible plantear una estrategia de capacitación. La mayoría de usuarios estarán en niveles bajos; introduciendo y usando los datos. Solo unos pocos tendrán que conocer la base de datos en profundidad, generalmente a nivel nacional. Los siguientes son trucos útiles para estrategias de capacitación a usuarios finales.</para>
<section>
<title>Formación de formadores</title>
- <para>Since the number of units and staff increase exponentially for each level (a country may have many provinces, each with many districts, each with many facilities), training of trainers is the first step. The number of trainers will vary, depending on the speed of implementation envisioned. As described below, both workshops and on-site training are useful, and especially for the on-site training many people will be needed.</para>
- <para>The trainers should be at least at the level of advanced users, in addition knowing how the database is designed, how to install and troubleshoot DHIS2, and some issues of epidemiology, i.e. concepts that are useful for monitoring and evaluation of health services. As the capabilities of the staff increase, the trainers would also need to increase their skills.</para>
+ <para>Dado que la cantidad de unidades y personal aumenta exponencialmente para cada nivel (un país puede tener provincias, cada una con muchos distritos, cada una con muchos establecimientos), la formación de formadores es el primer paso. El número de formadores puede variar dependiendo de la velocidad de implementación prevista. Como se describe a continuación, ambos workshops y formaciones in-situ son útiles, y para esta última será necesaria mucha gente.</para>
+ <para>Los formadores deberían estar al menos al nivel de usuarios avanzados, para conocer cómo está diseñada la base de datos, cómo isntalar y resolver problemas en DHIS2, y otros asuntos sobre epidemiología, como por ejemplo conceptos útiles para monitoreo y evaluación de servicios de salud. A medida que las capacidades del personal aumentan, los formadores también necesitarán actualizar sus habilidades.</para>
</section>
<section>
<title>Workshops y formación in-situ</title>
- <para>Experience has showed that training both in workshops/training sessions, and on-site in real work situations are complementary. Workshops are better for training many at the same time, and are useful early on in the training sessions. Preferably the same type of users should be trained.</para>
- <para>On-site training takes place at the work-place of the staff. It is useful to have done more organized training session like in a workshop before, so that on-site training can focus on special issues the individual staff would need more training on. Training on-site will involve less people, so it will be possible to include different types of users. An example would be a district training, where the district information officers and the district medical officer can be trained together. The communication between different users is important in the sense that it forms a common understanding of what is needed, and what is possible. Training can typically be centred around local requirements such as producing outputs (reports, charts, maps) that would be useful for local decision-support.</para>
+ <para>La experiencia nos ha mostrado que la formación tanto en sesiones de workshops como en situaciones in-situ de trabajo real son complementarias. Los workshops son mejores para formar a muchos al mismo tiempo, y son útiles para las posteriores sesiones de capacitación. Preferentemente se debería capacitar al mismo tipo de usuarios.</para>
+ <para>La formación in-sity tiene lugar en el lugar de trabajo del personal. Es útil haber realizado una sesión formativa más organizada como un workshop anteriormente, de modo que la formación in-situ puede enfocarse en los asuntos especiales de cada personal en particular. Un ejemplo podría ser una formación de distrito, donde los oficiales de información en el distrito y el personal clínico de distrito sea capacitado conjuntamente. La comunicación entre diferentes usuarios es importante en el sentido de que conforma un entendimiento común de qué se necesita y qué es posible. La formación normalmente puede centrarse en requisitos locales como la generación de salida de datos (reportes, gráficas, mapas) que sean útiles para el soporte a decisiones locales.</para>
</section>
<section>
<title>Formación continua</title>
- <para>Training is not a one off thing. A multi-level training strategy would aim at providing regular training as the skills of the staff increase. For example, a workshop on data entry and validation should be followed by another workshop on report generation and data analysis some time later. Regular training should also be offered to new staff, and when large changes are made to the system, such as redesign of all data collection forms.</para>
+ <para>La formación no es algo separado. Una estrategia de formación en varios niveles pretendería proveer formación regularmente a medida que las habilidades del personal mejoran. Por ejemplo, un workshop en entrada de datos y validación debería seguirse de otro workshop en generación de reportes y análisis de datos. También deberá ofrecerse formación regular a personal de nueva incorporación, y cuando se realicen cambios grandes en el sistema, como el rediseño de todos los formularios de recolección de datos.</para>
</section>
</section>
<section>
<title>Materiales y cursos</title>
- <para>There is comprehensive material available for training and courses. The main source will be the three manuals available from the DHIS2 documentation repository, to be found at <ulink url="http://dhis2.org/documentation";>here</ulink>.</para>
- <para>The user documentation covers the background and purpose of DHIS2 together with instructions and explanations of how to perform data entry, system maintenance, meta-data set-up, import and export of data, aggregation, reporting and other topics related to the usage of the software. The developer documentation covers the technical architecture, the design of each module and use of the development frameworks behind DHIS2. The implementation guide is targeted at implementers and super-users and addresses subjects such as system design, database development, data harmonization, analysis, deployment, human resources needed and integration with other systems. The end user manual is a light-weight version of the user documentation meant for end users such as district records officers and data entry clerks. All can be opened/downloaded as both PDF and HTML, and are updated daily with the latest input from DHIS2 users worldwide.</para>
- <para>
-The development of these guides depend on input from all users. For information how to to add content to them, please see the appendix on documentation in the User Documentation. Here you will also find information about how to make localized documentation, including versioning in different languages.</para>
- <para>From 2011, regional workshops and courses will be held at least once a year by the international DHIS2 community. The goal is to have national technical teams working with DHIS2 customization and implementation. Sessions will also include training and capacity building by these teams in-country. End-user training, i.e. training of district M&E officers, should take place in each county by these teams.</para>
+ <para>Hay material disponible para formación y cursos en inglés y también en español. La fuente principal son los tres manuales disponibles en el repositorio de documentación de DHIS2, que puede encontrarse <ulink url="http://dhis2.org/documentation";>aquí</ulink>.</para>
+ <para>La documentación de usuario cubre el origen y propósito de DHIS2 junto con instrucciones y explicaciones sobre cómo realizar la entrada de datos, el mantenimiento del sistema, la configuración de metadatos, importación y exportación de datos, agregación, reportes y otros temas relacionados con el uso del software. La documentación de desarrolladores cubre la arquitectura técnica, diseño de cada módulo y uso de las plataformas de desarrollo detrás de DHIS2. La guía de implementación está enfocada a implementadores y superusuarios, y trata materias como el diseño del sistema, el desarrollo de la base de datos, la armonización de datos, análisis, despliegue, recursos humanos necesarios y la integración con otros sistemas. El manual de usuario final es una versión ligera de la documentación de usuario pensada para usuarios como los digitadores distritales y el personal de registro de datos. Todos ellos pueden abrirse y descargarse como PDF y HTML, y se actualizan diariamente con la versión más reciente de los usuarios de DHIS2 a nivel mundial.</para>
+ <para>La elaboración de estas guías depende de la contribución de todos los usuarios. Para información sobre cómo añadir contenido, seguiremos el apéndice de documentación en la Documentación de Usuario. Ahí encontramos también información sobre cómo generar documentación localizada, incluido versionado en diferentes idiomas.</para>
+ <para>Desde 2011, los workshops regionales y cursos se realizan al menos una vez al año por la comunidad DHIS2. El objetivo es tener equipos técnicos nacionales trabajando en la personalización e implementación de DHIS2. Las sesiones también incluyen formación y construcción de capacidades de estos equipos en el país. La formación a usuarios finales, por ejemplo la formación de oficiales de distrito clínicos y digitadores, deberían hacerla estos equipos en cada país.</para>
</section>
</chapter>
=== modified file 'src/docbkx/es/dhis2_implementation_guide_integration.xml'
--- src/docbkx/es/dhis2_implementation_guide_integration.xml 2012-09-27 08:55:25 +0000
+++ src/docbkx/es/dhis2_implementation_guide_integration.xml 2012-10-30 12:51:32 +0000
@@ -3,73 +3,73 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"; []>
<chapter>
<title>Integración</title>
- <para>This chapter will discuss the following topics:</para>
+ <para>Este capítulo trata los temas siguientes:</para>
<itemizedlist>
<listitem>
- <para>Integration and interoperability</para>
- </listitem>
- <listitem>
- <para>Benefits of integration</para>
- </listitem>
- <listitem>
- <para>What facilitates integration and interoperability</para>
- </listitem>
- <listitem>
- <para>Architecture of interoperable HIS</para>
+ <para>Integración e interoperabilidad</para>
+ </listitem>
+ <listitem>
+ <para>Beneficios de la integración</para>
+ </listitem>
+ <listitem>
+ <para>¿Qué facilita la integración y la interoperabilidad?</para>
+ </listitem>
+ <listitem>
+ <para>Arquitectura de un SIS interoperable</para>
</listitem>
</itemizedlist>
- <para>In the following each topic will be discussed in greater detail.</para>
+ <para>A continuación cada tema se discute en detalle.</para>
<section>
<title>Integración e interoperabilidad</title>
- <para>In a country there will usually be many different, isolated health information systems. The reasons for this are many, both technical and organizational. Here the focus will be on what benefits integration of these systems will bring, and why it should be a priority. First, a couple of clarifications:</para>
+ <para>En un país normalmente hay muchos sistemas de información de salud diferentes y aislados. Las razones de que esto sea así son diversas, tanto técnicas como organizativas. Aquí pondremos el foco en qué beneficios puede traer la intefración de estos sistemas, y por qué esto debería ser prioritario. Antes de empezar, algunas aclaraciones:</para>
<itemizedlist>
<listitem>
- <para>When talking about integration, we think about the process of making different information systems appear as one, i.e. data from them to be available to all relevant users as well as the harmonization of definitions and dimensions so that it is possible to combine the data in useful ways.</para>
+ <para>Cuando hablamos de integración, pensamos en el proceso de hacer que diferentes sistemas de información parezcan uno solo, es decir, que los datos de cada uno de ellos estén disponibles para todos los usuarios relevantes así como que haya armonía entre las definiciones y dimensiones dadas de modo que sea posible combinar los datos de manera útil.</para>
</listitem>
<listitem>
- <para>A related concept is interoperability, which is one strategy to achieve integration. For purposes related to DHIS2, we say that it is interoperable with other software applications if it is able to share data with this. For example, DHIS2 and OpenMRS are interoperable, because there is support in both to share data definitions and data with each other.</para>
+ <para>Un concepto relacionado es la interoperabilidad, que es una estrategia para alcanzar la integración. A propósito de DHIS 2, decimos que es interoperable con otras aplicaciones software si es capaz de compartir datos ellas. Por ejemplo, DHIS2 y OpenMRS son interoperables porque ambas tienen el soporte para compartir definiciones de datos y datos propiamente dichos entre ellas.</para>
</listitem>
</itemizedlist>
- <para>To say that something is integrated, then, means that they share something, and that they are available from one place, while interoperability usually means that they are able to do this sharing electronically. DHIS2 is often used as an integrated data warehouse, since it contains (aggregate) data from various sources, such as Mother and Child health, Malaria program, census data, and data on stocks and human resources. These data sources share the same platform, DHIS2, and are available all from the same place. These subsystems are thus considered integrated into one system. Interoperability will then be a useful way to integrate also those data sources available on also other software applications. For example, if census data is stored in some other database, interoperability between this database and DHIS2 would mean census data would be accessible in both (but only stored one place).</para>
+ <para>Entonces, para decir que algo es integrado significa que comparten algo y que están disponibles desde un mismo lugar, mientras que interoperabilidad normalmente quiere decir que son capaces de hacer esta compartición electrónicamente. DHIS2 suele usarse como un data warehouse integrado, ya que contiene datos (agregados) procedentes de diversas fuentes, como Salud Materno-infantil, Programa de Malaria, datos censales, y datos de stocks y recursos humanos. Estas fuentes de datos comparten la misma plataforma, DHIS2, y están disponibles desde el mismo lugar. Estos subsistemas se consideran por tanto integrados en un solo sistema. La interoperabilidad podrá ser una manera útil de integrar también fuentes de datos disponibles en otras aplicaciones software. Por ejemplo, si los datos censales se guardan en alguna otra base de datos, la interoperabilidad entre esta base de datos y DHIS2 significaría que los datos censales estarán accesibles en ambas (aunque almacenados en un único lugar).</para>
</section>
<section>
<title>Beneficios de la integración</title>
- <para>There are several potential benefits related to integration of systems. The most important are:i</para>
+ <para>Hay muchos beneficios potenciales relacionados con la integración de sistemas. Los más importantes son:</para>
<itemizedlist>
<listitem>
- <para>Calculation of indicators: many indicators are based on numerators and denominators from different data sources. Examples include mortality rates, including some mortality data as numerator and population data as denominator, staff coverage and staff workload rates (human resource data, and population and headcount data), immunization rates, and the like. For these to be calculated, you need both the numerator and denominator data, and they should thus be integrated into a single data warehouse. The more data sources that are integrated, the more indicators can be generated from the central repository.</para>
- </listitem>
- <listitem>
- <para>Reduce manual processing and entering of data: with different data at the same place, there is no need to manually extract and process indicators, or re-enter data into the data warehouse. Especially interoperability between systems of different data types (such as patient registers and aggregate data warehouse) allows software for subsystems to both calculate and share data electronically. This reduces the amount of manual steps involved in data processing, which increases data quality.</para>
- </listitem>
- <listitem>
- <para>There are organizational reasons for integration. If all data can be handled by one unit in the ministry of health, instead of in various subsystems maintained by the health programs, this one unit can be professionalized. With staff which sole responsibility is data management, processing, and analysis, more specialized skills can be developed and the information handling be rationalized.</para>
+ <para>Cálculo de indicadores: muchos indicadores se basan en numeradores y denominadores de diferentes fuentes de datos. Algunos ejemplos incluyen tasas de mortalidad, con algunos datos de mortalidad como numerador y datos poblacionales como denominador, cobertura de personal y tasas de carga de trabajo del personal (datos de recursos humanos, y datos de población y de plantilla), tasas de inmunización y similares. Para que estos sean calculados, necesitamos ambos datos de numerador y denominador, y por tanto deberían estar integrados en un único data warehouse. Cuanto mayor sea el número de fuentes de datos que estén integradas, mayor cantidad de indicadores podrán generarse desde el repositorio central.</para>
+ </listitem>
+ <listitem>
+ <para>Reducción del procesado y entrada manual de datos: con diferentes datos en el mismo lugar, no hay necesidad de extraer y procesar los indicadores manualmente, o de reinsertar los datos en el data warehouse. Especialmente la interoperabilidad entre sistemas de diferentes tipos de datos (como registros de pacientes y almacenes de datos agregados) permite que los softwares de los subsistemas calculen y compartan datos electrónicamente. Esto reduce la cantidad de pasos manuales implicados en el procesado de datos, lo que contribuye a mejorar la calidad de los datos.</para>
+ </listitem>
+ <listitem>
+ <para>Hay razones organizativas para la integración. Si todos los datos pueden manejarse desde una unidad del Ministerio de Salud, en lugar de tener varios subsistemas mantenidos por los programas de salud, esta unidad puede profesionalizarse. Con personal que tiene como única responsabilidad la gestión, procesado y análisis de datos, pueden desarrollarse habilidades más especializadas y se puede racionalizar el manejo de información.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Qué facilita la integración y la interoperabilidad</title>
- <para>There are three levels that need to be addressed in this regard:</para>
+ <para>Para este fin, hay que avanzar en tres niveles:</para>
<itemizedlist>
<listitem>
- <para>The motivation and will to integrate (organizational level)</para>
- </listitem>
- <listitem>
- <para>Standard definitions (language level)</para>
- </listitem>
- <listitem>
- <para>Standard for electronic storage and exchange (technical level)</para>
+ <para>La motivación y voluntad de integrar (a nivel organizativo)</para>
+ </listitem>
+ <listitem>
+ <para>Las definiciones estándar (a nivel lingüístico)</para>
+ </listitem>
+ <listitem>
+ <para>El estándar de almacenamiento e intercambio electrónico (a nivel técnico)</para>
</listitem>
</itemizedlist>
- <para>The first level is less of a topic in this guide, which takes as a point of departure that a decision has been taken about integration of data. However, it is an important issue and usually the most complex to solve given the range of actors involved in the health sector. Clear national policies on data integration, data ownership, routines for data collection, processing, and sharing, should be in place to address this issue. Often some period of disturbance to the normal data flow will take place during integration, so for many the long-term prospects of a more efficient system will have to be judged against the short-term disturbance. Integration is thus often a step-wise process, where measures need to be taken for this to happen as smoothly as possible.</para>
- <para>At the language level, there is a need to be consistent about definitions. If you have two data sources for the same data, they need to be comparable. For example, if you collect malaria data from both standard clinics and from hospitals, this data need to describe the same thing if they need to be combined for totals and indicators. If a hospital is reporting malaria cases by sex but not age group, and other clinics are reporting by age group but not sex, this data cannot be analyzed according to either of these dimensions, though a total amount of cases will be possible to calculate. There is thus a need to agree on uniform definitions.</para>
- <para>In addition to uniform definitions across the various sub-systems, data exchange standards must be adopted if data is to be shared electronically. The various software applications would need this to be able to understand each other. DHIS2 is supporting several data formats for import and export, but one standard format now supported by WHO is called SDMX-HD (Statistical Data and Metadata Exchange - Health Domain). Other software applications are also supporting this, and it allows the sharing of data definitions and aggregate data between them. For DHIS2, this means it supports import of aggregate data that are supplied by other applications, such as OpenMRS (for patient management), iHRIS (for human resources management)</para>
+ <para>El primer nivel es un tema recurrente en esta guía, y toma como punto de partida que se ha tomado ya una decisión sobre la integración de datos. Sin embargo, es un asunto importante y normalmente el más complejo de resolver dado el rango de actores involucrados en el sector salud. Unas políticas nacionales claras sobre la integración de datos, la propiedad de los datos, las rutinas de recolección, procesado y compartición de datos, deberían fijarse para atender esta cuestión. A menudo puede producirse algún periodo de alteración del flujo normal de datos, así que debería juzgarse la perspectiva a laro plazo de un sistema más eficiente frente a esta alteración a corto plazo. La integración es por tanto un proceso por pasos, donde hay que medir bien para que el proceso sea lo más suave posible.</para>
+ <para>A nivel de lenguaje, hay una necesidad de consistencia en las definiciones. Si tenemos dos fuentes de datos para los mismos datos, deben poder compararse. Por ejemplo, si recogemos datos de malaria de clínicas estándar y de hosppitales, estos datos deberán describir lo mismo si necesitamos combinarlos para cantidades totales e indicadores. Si un hospital está reportando casos de malaria por sexo pero no por edad, y otras clínicas están reportando por grupo de edad pero no por sexo, estos datos no se pueden analizar de acuerdo a ninguna de estas dimensiones, aunque es posible calcular el número total de casos. Entonces, es preciso acordar definiciones uniformes.</para>
+ <para>Además de las definiciones uniformes en varios subsistemas, hay que adoptar estándares de intercambio de datos si los datos se comparten electrónicamente. Las diversas aplicaciones software necesitarán esto para poder entenderse mutuamente. DHIS2 soporta varios formatos de importación y exportación de datos, pero existe un formato estándar soportado por la OMS que se llama SDMX-HD (Statistical Data and Metadata Exchange - Health Domain). También otras aplicaciones software lo sopoertan, y esto permite la compartición de definiciones de datos y agregar datos entre ellas. Para DHIS2, esto quiere decir que puede importar datos agregados proporcionados por otras aplicaciones, como OpenMRS (para la gestión de pacientes) e iHIS (para la gestión de recursos humanos).</para>
</section>
<section>
<title>Arquitectura de SIS interoperables</title>
- <para>Since there are many different use-cases for health information, such as monitoring and evaluation, budgeting, patient management and tracking, logistics management, insurance, human resource management, etc, there will be many different types of software applications functioning within the health sector. Above the issue of interoperability has been addressed, and a plan or overview of the various interoperable software applications and their specific uses, along with what data should be shared between them, is termed an architecture for health information. </para>
- <para>The role of the architecture is to function as a plan to coordinate the development and interoperability of various sub-systems within the larger health information system. It is advisable to develop a plan for the various components even if they are not currently running any software, to be able to adequately see the requirements in terms of data sharing. These requirements should then be part of any specification for the software when such is developed or procured.</para>
- <para>Below is a simple illustration of an architecture, with a focus on the data warehouse for aggregate data. The various boxes represent use cases, such as managing logistics, tracking TB patients, general patient management, etc. All of these will share aggregate data with DHIS2. Note that the arrows are two-way, because there is also a synchronization of meta-data (definitions) involved, to make sure that the right data is shared. Also, an example of the logistics and financial data applications sharing data is also shown, as there are strong links between procuring drugs and handling the budget for this. There will be many such instances of sharing data; the architecture helps us to plan better for this being implemented as the ecosystem of software applications grow.</para>
+ <para>Dado que hay muchos casos de uso distintos de información de salud, tales como monitoreo y evaluación, presupuesto, gestión y seguimiento de pacientes, gestión logística, seguros, gestión de recursos humanos, et, hay muchos tipos de aplicaciones software que funcionan en el Sector Salud. Más allá del tema de abordar la interoperabilidad y planificar o tener una visión de las diversas aplicaciones software interoperables y sus características específicas, y la cuestión de qué datos deberían compartir entre sí, está el tema de construir una arquitectura para la información de salud. </para>
+ <para>El rol de la arquitectura es hacer las veces de plan de coordinación del desarrollo e interoperabilidad de los diversos subsistemas que hay en un sistema amplio de información de salud. Es recomendable elaborar un plan para los varios componentes incluso si todavía no está funcionando ningún software, para ser capaces de ver adecuadamente los requisitos de compartición de datos. Estos requisitos deberían ser parte de cualquier especificación del software que se desarrolle o compre con este propósito.</para>
+ <para>A continuación hay una ilustración sencilla de una arquitectura, con un foco en el data warehouse para datos agregados. Las diversas cajas representan casos de uso, como la gestión logística, el seguimiento de pacientes de TB, la gestión general de pacientes, etc. Todos estos compartirán datos agregados con DHIS2. Notemos que las flechas son bidireccionales, porque hay también una sincronización de metadatos (definiciones), para asegurarnos de que se comparten los datos correctos. También se muestra un ejemplo de aplicaciones de datos logísticos y financieeros compartiendo datos, ya que hay fuertes vínculos entre la adquisición de medicamentos y la gestión del presupuesto para ello. Hay muchas instancias de compartición de datos; la arquitectura nos ayuda a planificar mejor que esto se implemente como un ecosistema creciente de aplicaciones software.</para>
<graphic width="100%" format="PNG" fileref="resources/images/implementation_guide/interoperable_his.png" align="center"/>
</section>
</chapter>
=== added file 'src/docbkx/es/resources/images/implementation_guide/data_warehouse.png'
Binary files src/docbkx/es/resources/images/implementation_guide/data_warehouse.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/implementation_guide/data_warehouse.png 2012-10-30 12:51:32 +0000 differ
=== added file 'src/docbkx/es/resources/images/implementation_guide/dhis_data_warehouse.png'
Binary files src/docbkx/es/resources/images/implementation_guide/dhis_data_warehouse.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/implementation_guide/dhis_data_warehouse.png 2012-10-30 12:51:32 +0000 differ
=== added file 'src/docbkx/es/resources/images/implementation_guide/dimensional_approach.png'
Binary files src/docbkx/es/resources/images/implementation_guide/dimensional_approach.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/implementation_guide/dimensional_approach.png 2012-10-30 12:51:32 +0000 differ
=== added file 'src/docbkx/es/resources/images/implementation_guide/interoperable_his.png'
Binary files src/docbkx/es/resources/images/implementation_guide/interoperable_his.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/implementation_guide/interoperable_his.png 2012-10-30 12:51:32 +0000 differ
