dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #20514
[Branch ~dhis2-documenters/dhis2/dhis2-docbook-docs] Rev 642: Updated chapter 2 of user documentation (Spanish)
------------------------------------------------------------
revno: 642
committer: Inés Bebea <ines.bebea@xxxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Fri 2012-12-21 18:10:34 +0100
message:
Updated chapter 2 of user documentation (Spanish)
added:
src/docbkx/es/resources/images/dhis2UserManual/dhis2_information_cycle.png
modified:
src/docbkx/es/dhis2_implementation_guide_setting_up_new_database.xml
src/docbkx/es/dhis2_user_man_getting_started.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_setting_up_new_database.xml'
--- src/docbkx/es/dhis2_implementation_guide_setting_up_new_database.xml 2012-10-09 18:59:03 +0000
+++ src/docbkx/es/dhis2_implementation_guide_setting_up_new_database.xml 2012-12-21 17:10:34 +0000
@@ -46,7 +46,7 @@
</section>
<section>
<title>Elementos de datos</title>
- <para>El Elemento de Datos es probablemente el bloque más fundamental de una base de datos en DHIS2. Representa la dimensión <emphasis role="italic">qué</emphasis>, ya que explica qué se está recopilando o analizando. En algunos contextos esto está referido a un indicador, para en DHIS2 llamamos elemento de datos a esta unidad de colección y análisis. El elemento de datos a menudo representa un conteo de algo, y su nombre describe qué es aquello que se está contando, por ejemplo "Dosis entregadas de BCG" o "Casos de Malaria". Cuando los datos son recopilados, validados, analizados, reportados o presentados, lo que describe el QUé de los datos son los elementos de datos o expresiones construidas a partir de elementos de datos. Como tales, los elementos de datos se vuelven importantes para todos los aspectos del sistema y deciden no sólo cómo se recopilan los datos, sino algo más importante: cómo los valores de datos se representan en la base de datos, lo cual de nuevo afecta a cómo los datos son analizados y presentados.
+ <para>El Elemento de Datos es probablemente el bloque más fundamental de una base de datos en DHIS2. Representa la dimensión <emphasis role="italic">qué</emphasis>, ya que explica qué se está recopilando o analizando. En algunos contextos esto está referido a un indicador, para en DHIS2 llamamos elemento de datos a esta unidad de colección y análisis. El elemento de datos a menudo representa un conteo de algo, y su nombre describe qué es aquello que se está contando, por ejemplo "Dosis entregadas de BCG" o "Casos de Malaria". Cuando los datos son recopilados, validados, analizados, reportados o presentados, lo que describe el QUÉ de los datos son los elementos de datos o expresiones construidas a partir de elementos de datos. Como tales, los elementos de datos se vuelven importantes para todos los aspectos del sistema y deciden no sólo cómo se recopilan los datos, sino algo más importante: cómo los valores de datos se representan en la base de datos, lo cual de nuevo afecta a cómo los datos son analizados y presentados.
</para>
<para>La mejor práctica en el diseño de elementos de datos es pensar en los elementos de datos como una unidad de análisis de datos y no sólo como un campo en el formulario de entrada de datos. Cada elemento de datos tiene vida propia en la base de datos, completamente separado del formulario, y los reportes y otras salidas se basan en elementos de datos y expresiones o fórmulas compuestas por elementos de datos y no en los formularios de colección de datos. De modo que las necesidades del análisis de datos son las que deberían dirigir este proceso, y no el aspecto y función amigables del formulario de colección de datos.</para>
</section>
@@ -74,7 +74,7 @@
<para>En el módulo integrado de SIG podemos mostrar fácilmente nuestros datos en mapas, tanto en polígonos (áreas) como en puntos (establecimientos de salud), y tanto los elementos de datos como los indicadores. Si añadimos al sistema las coordenadas de nuestras unidades organizativas, podemos rápidamente comenzar a trabajar con este módulo. Recomendamos ver la sección SIG para más detalles sobre cómo configurar este módulo.</para>
</section>
<section>
- <title>Gráficos y dashboard</title>
+ <title>Gráficas y dashboard</title>
<para>Una de las maneras más sencillas de mostrar nuestros datos de indicadores es utilizar gráficas. Una pantalla de diálogo amigable nos guiará a través de la creación de varios tipos de gráficas con data de indicadores, unidades organizativas y periodos a nuestra elección. Estas gráficas pueden añadirse fácilmente a una de las cuatro secciones del dashboard destinadas a gráficas, y así las tendremos disponibles directamente al entrar en nuestra sesión. Para esto deberemos fijar el módulo dashboard como el módulo de inicio en la configuración de usuario.</para>
</section>
</section>
=== modified file 'src/docbkx/es/dhis2_user_man_getting_started.xml'
--- src/docbkx/es/dhis2_user_man_getting_started.xml 2012-11-14 11:31:46 +0000
+++ src/docbkx/es/dhis2_user_man_getting_started.xml 2012-12-21 17:10:34 +0000
@@ -4,45 +4,43 @@
<title>Comenzando con DHIS 2</title>
<section id="mod2_1">
<title>Primeros pasos con DHIS 2</title>
- <para>After reading this chapter you will be able to understand:</para>
- <itemizedlist>
- <listitem>
- <para>Start DHIS 2 from the desktop</para>
- </listitem>
- <listitem>
- <para>How to log-in from the desktop</para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>Create new users and user roles</para>
- </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>What steps are needed to design a DHIS 2 database for your organisation</para>
+ <para>Tras repasar este capítulo habremos podido entender:</para>
+ <itemizedlist>
+ <listitem>
+ <para>Arrancar DHIS2 desde el escritorio</para>
+ </listitem>
+ <listitem>
+ <para>Cómo loquearnos desde el escritorio</para>
+ </listitem>
+ </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>Cómo crear nuevos usuarios y roles de usuario</para>
+ </listitem>
+ </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>Qué pasos son necesarios para diseñar una base de datos DHIS2 para nuestra organización</para>
</listitem>
</itemizedlist>
<section>
<title>Requisitos previos</title>
- <para>You must be sure that you have a current version of the Java Runtime installed on your machine. Depending on your operating system, there are different ways of installing Java. The reader is referred to this <ulink url="http://java.sun.com/javase/downloads/index.jsp";>website</ulink> for detailed information on getting java installed.</para>
+ <para>Primero deberemos asegurarnos de tener la versión más reciente de Java Runtime instalada en la máquina donde correrá la aplicación. Dependiendo del sistema operativo, hay diferentes formas de instalar Java. El lector podrá consultar <ulink url="http://java.sun.com/javase/downloads/index.jsp";> esta web</ulink> para información más detallada sobre cómo instalar Java.</para>
</section>
<section>
<title>Un comienzo con el paquete DHIS 2 Live</title>
- <para>The DHIS 2 Live package is the easiest way to get started with DHIS 2. DHIS 2 Live is appropriate for a stand-alone type of installation. Simply download the application from <ulink url="http://www.dhis2.org/downloads";>here</ulink>.
- Once the file is downloaded, you can simply double-click the downloaded file, and get started using DHIS 2. </para>
+ <para>El paquete DHIS2 Live es la forma más fácil de comenzar con DHIS2. DHIS2 Live es apropiada para una instalación independiente. Simplemente descargamos la aplicación de <ulink url="http://www.dhis2.org/downloads";>aquí</ulink>. Una vez el fichero se ha descargado, hacemos doble click en el fichero descargado y comenzarmos a usar DHIS2. </para>
<section>
- <title>Un comienzo con una base de datos vacía</title>
- <para>The live package comes with a demo database just like what you see on the online demo (which is based on the national Sierra Leone HMIS), and if you want to start with a blank system/database and build up your own system then you need to do the following:</para>
- <para>1) Stop the DHIS 2 live if it is already running. Right click on the tray icon and select Exit.
-The tray icon is the green symbol on the bottom right of your screen (on Windows) which should say' DHIS 2 Server running' if you hold your mouse pointer over it.</para>
- <para>2) Open the folder where the DHIS 2 live package is installed and locate the folder called "conf".</para>
- <para>3) In conf/ open the file called 'hibernate.properties' in a text editor (notepad or similar) and do the following modification:
-locate the string 'jdbc:h2:./database/dhis2' and replace the 'dhis2' part with any name that you want to give to your database (e.g. dhis2_test).</para>
- <para>4) Save and close the hibernate.properties file.</para>
- <para>5) Start DHIS 2 Live by double-clicking on the file dhis2-live.exe in the DHIS 2 Live installation folder or by using a desktop shortcut or menu link that you might have set up.</para>
- <para>6) Wait for the browser window to open and the login screen to show, and then log in with username: admin and password: district</para>
- <para>7) Now you will see a completely empty DHIS 2 system and you should start by adding your users, organisational hierarchy, data elements, and datasets etc. Please refer to the other sections of the user manual for instructions on how to do this.</para>
+ <title>Empezando con una base de datos vacía</title>
+ <para>El paquete Live viene con una base de datos demostrativa como la que vemos en la demo online (basada en el SGIS nacional de Sierra Leona), y si queremos empezar con un sistema/base de datos vacía y construir nuestro propio sistema, entonces tendremos que hacer lo siguiente:</para>
+ <para>1) Parar DHIS2 Live si está todavía corriendo. Hacer click con el botón derecho en el icono de bandeja y seleccionar Salir. El icono de bandeja es el símbolo verde en la esquina inferior derecha de la pantalla (en Windows) que debería decir "Servidor DHIS2 corriendo" cuando colocamos el puntero del mouse sobre él.</para>
+ <para>2) Abrir la carpeta donde se ha instalado el paquete DHIS2 Live y localizar la carpeta llamada "conf".</para>
+ <para>3) En conf/ abrir el fichero llamado 'hibernate.properties' en un editor de texto (bloc de notas o similar) y hacer la siguiente modificación:
+encontrar la expresión 'jdbc:h2:./database/dhis2' y reemplazar la parte 'dhis2' por el nombre que queremos dar a nuestra base de datos (ej. dhis2_test).</para>
+ <para>4) Guardar y cerrar el fichero hibernate.properties file.</para>
+ <para>5) Arrancar DHIS 2 Live haciendo doble click en el fichero dhis2-live.exe en la carpeta de instalación de DHIS 2 Live o utilizando el acceso directo de escritorio o el enlace en el menú.</para>
+ <para>6) Esperar a que se abra la ventana del navegador web y la pantalla de login, y nos logueamos con nombre de usuario admin y contraseña district.</para>
+ <para>7) Ahora veremos un sistema DHIS2 totalmente vacío y deberemos comenzar a añadir usuarios, jerarquía organizativa, elementos de datos, sets de datos, etc. Para instrucciones detalladas sobre cómo hacer esto, podemos revisar otras secciones de este manual.</para>
</section>
</section>
<section>
@@ -202,7 +200,7 @@
<para>Click on <guibutton>Save</guibutton> tab after editing all
details of a particular selected user.</para>
<screenshot>
- <screeninfo>User management screen</screeninfo>
+ <screeninfo>Pantalla de gestión de usuarios</screeninfo>
<mediaobject>
<imageobject>
<imagedata width="100%" fileref="resources/images/dhis2UserManual/user_management.png" format="PNG"/>
@@ -215,72 +213,75 @@
</section>
<section id="mod2_4">
<title>Salir de DHIS 2</title>
- <para>Just click on the Log out link in the top right corner to exit the application.</para>
+ <para>Para salir de la aplicación simplemente haremos click en el enlace "Salir" en la esquina superior derecha de la pantalla.</para>
</section>
<section id="database_design">
<title>Una introducción rápida al diseño de una base de datos en DHIS2</title>
- <para>The DHIS 2 application comes with a set of tools for data collection, validation, reporting and analysis, but the contents of the database, e.g. what to collect, who should collect it and on what format will depend on the context of use. This metadata need to be populated into the application before it can be used, and this can be done through the user interface and requires no programming or in-depth technical skills of the software. We call this initial process database design or customisation.</para>
- <para>This section will provide a very quick and brief introduction to DHIS 2 database design and mainly explain the various steps needed to prepare a new DHIS 2 system for use. How to do each step is explained in other chapters, and best practices on design choices will be explained in an implementers manual (expected during first half of 2011). Here are the steps to follow:</para>
- <para>1. Set up an organisational hierarchy</para>
- <para>2. Define data elements</para>
- <para>3. Define data sets and data entry forms</para>
- <para>4. Define validation rules</para>
- <para>5. Define indicators</para>
- <para>6. Define report tables and design reports</para>
- <para>7. Set up the GIS module</para>
- <para>8. Design charts and customise the dashboard</para>
+ <para>La aplicación DHIS2 viene con un conjunto de herramientas para la recolección, validación, reporte y análisis de datos, pero los contenidos de la base de datos, por ejemplo, qué recolectar, quién debería registrarlo y en qué formato, dependerá del contexto de uso. Estos metadatos deben ser introducidos en la aplicación antes de que pueda utilizarse, y esto puede hacerse directamente mediante el interfaz de usuario sin necesidad de programación de código o grandes habilidades técnicas sobre software. A este proceso inicial lo llamamos diseño de la base de datos o personalización de la aplicación.</para>
+ <para>Esta sección ofrece una rápida y breve introducción al diseño de la base de datos en DHIS2 y fundamentalmente explica los pasos necesarios para preparar un nuevo sistema DHIS2 para su uso. Cómo realizar cada paso se explica en otros capítulos, y las buenas prácicas en las decisiones de diseño se explican en la Guía de Implementación. A continuación se listan los pasos a seguir:</para>
+ <para>1. Montar una jerarquía organizativa</para>
+ <para>2. Definir los elementos de datos</para>
+ <para>3. Definir los sets de datos y los formularios de entrada de datos</para>
+ <para>4. Definir las reglas de validación</para>
+ <para>5. Definir indicadores</para>
+ <para>6. Definir tablas de reportes y diseñar reportes</para>
+ <para>7. Montar el módulo SIG</para>
+ <para>8. Diseñar gráficas y personalizar el panel de control (dashboard)</para>
<section>
<title>La jerarquía organizativa</title>
- <para>The organisational hierarchy defines the organisation using the DHIS 2, the health facilities, administrative areas and other geographical areas used in data collection and data analysis. This dimension to the data is defined as a hierarchy with one root unit (e.g. Ministry of Health) and any number of levels and nodes below. Each node in this hierarchy is called an organisational unit in DHIS 2. The design of this hierarchy will determine the geographical units of analysis available to the users as data is collected and aggregated in this structure. There can only be one organisational hierarchy at the same time so its structure needs careful consideration. Additional hierarchies (e.g. parallel administrative boundaries to the health care sector) can be modelled using organisational groups and group sets, but the organisational hierarchy is the main vehicle for data aggregation on the geographical dimension. Typically national organisational hierarchies in public health have 4-6 levels, but any number of levels is supported. The hierarchy is built up of parent-child relations, e.g. a Country or MoH unit (the root) might have e.g. 8 parent units (provinces), and each province again ( at level 2) might have 10-15 districts as their children. Normally the health facilities will be located at the lowest level, but they can also be located at higher levels, e.g. national or provincial hospitals, so skewed organisational trees are supported (e.g. a leaf node can be positioned at level 2 while most other leaf nodes are at level 5). Typically there is a geographical hierarchy defined by the health system. e.g. where the administrative offices are located (e.g. MoH, province, district), but often there are other administrative boundaries in the country that might or might not be added, depending on how its boundaries will improve data analysis. When designing the hierarchy the number of children for any organisational unit may indicate the usefulness of the structure, e.g. having one or more 1-1 relationships between two levels is not very useful as the values will be the same for the child and the parent level. On the other extreme a very high number of children in the middle of the hierarchy (e.g. 50 districts in a province) might call for an extra level to be added in between to increase the usefulness of data analysis. The lowest level, the health facilities will often have a large number of children (10-60), but for other levels higher up in the hierarchy approx. 5-20 children is recommended. To few or too many children might indicate that a level should be removed or added. Note that it is quite easy to make changes to the upper levels of the hierarchy at a later stage, the only problem is changing organisational units that collect data (the leaf nodes), e.g. splitting or merging health facilities. Aggregation up the hierarchy is done based on the current hierarchy at any time and will always reflect the most recent changes to the organisational structure. Refer to the chapter on Organisation Units to learn how to create organisational units and to build up the hierarchy.</para>
+ <para>La jerarquía organizativa define la organización en DHIS 2: los establecimientos de salud, las áreas administrativas y otras áreas geográficas utilizadas en la recolección y el análisis de datos. Esta dimensión de los datos se define como una jerarquía con una unidad raíz (ej. Ministerio de Salud) y diversos niveles y nodos debajo. Cada nodo en esta jerarquía es lo que en DHIS 2 llamamos unidad organizativa. El diseño de esta jerarquía determinará las unidades geográficas de análisis disponibles a los usuarios al momento en que los datos son registrados y agregados en esta estructura. Solo puede haber una jerarquía organizativa en el sistema, de modo que deberemos considerar cuidadosamente cómo estructurarla.</para>
+ <para>Es posible modelar jerarquías adicionales (tales como límites administrativos paralelos al Sector Salud) utilizando grupos organizativos y sets de grupo, pero la jerarquía organizativa es el vehículo principal para la agregación de datos en una dimensión geográfica. Normalmente las jerarquías organizativas nacionales en Salud Pública tienen entre 4 y 6 niveles, pero DHIS soporta cualquier cantidad de niveles. La jerarquía se construye con relaciones padre-hijo, por ejemplo: una unidad País o Ministerio de Salud (la raíz) puede tener 8 unidades hijo (provincias), y cada provincia (en nivel 2) puede tener a su vez 10 ó 15 distritos como nodos hijo. Generalmente los establecimientos de salud estarán colocados en el nivel más bajo, pero también podemos colocarlos en niveles más altos como sucederá con los hospitales provinciales o nacionales, de modo que es posible tener árboles organizativos asimétricos (ej. un nodo hoja puede estar colocado en el nivel 2 mientras la mayoría de nodos hoja se encuentran en el nivel 5). </para>
+ <para>Normalmente hay una jerarquía geográfica definida por el sistema de salud, por ejemplo, dónde se ubican las oficinas administrativas (el Ministerio de Salud, las direcciones provinciales, distritales..), pero frecuentemente hay también otros límites administrativos en el país que puden o no añadirse, dependiendo de si estas subdivisiones mejoran el análisis de los datos. Cuando diseñamos la jerarquía el número de hijos para cada unidad organizativa debe indicar la utilidad de dicha estructura, es decir, tener una o más relaciones 1 a 1 entre dos niveles no es muy útil ya que los valores serán los mismos para el nivel padre y el nivel hijo. En el lado opuesto tendríamos un número demasiado grande de hijos en medio de la jerarquía (por ejemplo, 50 distritos en una provincia) que podemos resolver con un nivel intermedio extra que aumente la utilidad del análisis de los datos. El nivel más bajo, los establecimientos de salud, a menudo tienen un número grande de hijos (entre 10 y 60), pero ara otros niveles superiores en la jerarquía es recomendable limitarlo a 5-20 hijos. Demasiados o demasiado pocos hijos puede indicarnos que deberíamos eliminar o añadir un nivel. Es importante resaltar que es fácil hacer cambios en los niveles altos de la jerarquía a posteriori, el único problema es cambiar las unidades organizativas que recogen los datos (los nodos hoja), al subdividir o fusionar establecimientos de salud. El agregado de datos hacia arriba en la jerarquía se realiza según la jerarquía establecida en un momento dado, y siempre reflejará los cambios más recientes en la estructura organizativa. Hay más detalle en el capítulo sobre Unidades Organizativas para aprender cómo crear unidades organizativas y cómo construir la jerarquía.</para>
</section>
<section>
<title>Elementos de datos</title>
- <para>The Data Element is perhaps the most important building block of a DHIS 2 database. It represents the "WHAT" dimension, it explains what is being collected or analysed. In some contexts this is referred to an indicator, but in DHIS 2 we call this unit of collection and analysis a <emphasis role="italic">data element</emphasis>. The data element often represents a count of something, and its name describes what is being counted, e.g. "BCG doses given" or "Malaria cases". When data is collected, validated, analysed, reported or presented it is the data elements or expressions built upon data elements that describes the WHAT of the data. As such the data elements become important for all aspects of the system and they decide not only how data is collected, but more importantly how the data values are represented in the database, which again decides how data can be analysed and presented. </para>
- <para>It is possible to add more details to this "WHAT" dimension through the disaggregation dimension called data element categories. Some common categories are Age and Gender, but any category can be added by the user and linked to specific data elements. The combination of a data element's name and its assigned category defines the smallest unit of collection and analysis available in the system, and hence describes the raw data in the database. Aggregations can be done when zooming out of this dimension, but no further drill-down is possible, so designing data elements and categories define the detail of the analysis available to the system (on the WHAT dimension). Changes to data elements and categories at a later stage in the process might be complicated as these will change the meaning of the data values already captured in the database (if any). So this step is one of the more decisive and careful steps in the database design process.</para>
- <para>One best practice when designing data elements is to think of data elements as a unit of data analysis and not just as a field in the data collection form. Each data element lives on its own in the database, completely detached from the collection form, and reports and other outputs are based on data elements and expressions/formulas composed of data elements and not the data collection forms. So the data analysis needs should drive the process, and not the look an feel of the data collection forms. A simple rule of thumb is that the name of the data element must be able to stand on its own and describe the data value also outside the context of its collection form. E.g. a data element name like "Total referrals" makes sense when looking at it in either the "RCH" form or the "OPD" form, but on its own it does not uniquely describe the phenomena (who are being referred?), and should in stead be called "Total referrals from Maternity" or "Total referrals from OPD". Two different data elements with different meanings, although the field on the paper form might only say "Total referrals" since the user of the form will always know where these referrals come from. In a database or a repository of data elements this context is no longer valid and therefore the names of the data elements become so important in describing the data. </para>
- <para>Common properties of data elements can be modelled through what is called data element groups. The groups are completely flexible in the sense that they are defined by the user, both their names and their memberships. Groups are useful both for browsing and presenting related data, but can also be used to aggregate data elements together. Groups are loosely coupled to data elements and not tied directly to the data values which means they can be modified and added at any point in time without interfering with the raw data. </para>
+ <para>El Elemento de Datos es probablemente el bloque más fundamental de una base de datos en DHIS2. Representa la dimensión <emphasis role="italic">qué</emphasis>, ya que explica qué se está recopilando o analizando. En algunos contextos esto está referido a un indicador, para en DHIS2 llamamos elemento de datos a esta unidad de colección y análisis. El elemento de datos a menudo representa un conteo de algo, y su nombre describe qué es aquello que se está contando, por ejemplo "Dosis entregadas de BCG" o "Casos de Malaria". Cuando los datos son recopilados, validados, analizados, reportados o presentados, lo que describe el QUÉ de los datos son los elementos de datos o expresiones construidas a partir de elementos de datos. Como tales, los elementos de datos se vuelven importantes para todos los aspectos del sistema y deciden no sólo cómo se recopilan los datos, sino algo más importante: cómo los valores de datos se representan en la base de datos, lo cual de nuevo afecta a cómo los datos son analizados y presentados.</para>
+
+ <para>Es posible añadir más detalles a la dimensión "QUÉ" mediante las categorías de elementos de datos. Algunas categorías comunes son Edad y Género, pero es posible añadir cualquier categoría identificada por el usuario y enlazarla con elementos de datos específicos. La combinación del nombre de un elemento de datos y su categoría asignada define la unidad más pequeña de recolección y análisis disponible en el sistema, y por tanto describe los datos en bruto en la base de datos. Podemos hacer agregados al alejarnos en esta dimensión, pero no es posible acercarnos, descomponerlo más, ya que diseñar elementos de datos y categorías define el detalle de análisis posible en el sistema (en la dimensión QUÉ). Si hacemos cambios posteriores en los elementos de datos y categorías puede complicarse, ya que esto cambiará el significado de los valores de datos ya registrados en la base de datos. De modo que este paso es uno de los más decisivos y cuidadosos en el proceso de diseño de la base de datos.</para>
+
+ <para>La mejor práctica en el diseño de elementos de datos es pensar en los elementos de datos como una unidad de análisis de datos y no sólo como un campo en el formulario de entrada de datos. Cada elemento de datos tiene vida propia en la base de datos, completamente separado del formulario, y los reportes y otras salidas se basan en elementos de datos y expresiones o fórmulas compuestas por elementos de datos y no en los formularios de colección de datos. De modo que las necesidades del análisis de datos son las que deberían dirigir este proceso, y no el aspecto y función amigables del formulario de colección de datos. Una regla de oro es que el nombre del elemento de datos debe entenderse por sí mismo y describir el valor del dato también fuera del contexto de su formulario de registro. Por ejemplo, un nombre de elemento de dato como "Total referidos" tiene sentido cuando miramos bien en el formulario de "RCH" o de "OPD", pero por sí mismo no describe de forma unívoca el fenómeno (¿quiénes son referidos?), y debería más bien llamarse "Total referidos en maternidad" o "Total referidos en OPD". Dos elementos de datos diferentes con significados distintos, aunque el campo en el formulario de papel puede simplemente decir "Total referidos" ya que el usuario del formulario siempre sabe de dónde vienen los referidos (está contextualizado). En una base de datos o un repositorio de elementos de datos este contexto no es válido, y por eso los nombres de los elementos de datos se vuelven muy importantes al describir los datos.</para>
+ <para>Las propiedades comunes de elementos de datos pueden modelarse con lo que llamamos grupos de elementos de datos. Los grupos son completamente flexibles en el sentido de que son definidos por el usuario, tanto sus nombres como sus miembros. Los grupos son útiles tanto para explorar como para presentar los datos relacionados, pero también pueden utilizarse para agregar elementos de datos. Los grupos están vinculados a elementos de datos pero no ligados directamente a los valores de los datos, lo que implica que podemos modificarlos y añadir nuevos grupos en cualquier momento sin interferir en los datos en bruto. </para>
</section>
<section>
<title>Sets de datos y formularios de entrada de datos</title>
- <para>All data entry in DHIS 2 is organised through the use of Datasets. A Dataset is a collection of data elements grouped together for data collection, and in the case of distributed installs they also define chunks of data for export and import between instances of DHIS 2 (e.g. from a district office local installation to a national server). Datasets are not linked directly to the data values, only through their data elements and frequencies, and as such a dataset can be modified, deleted or added at any point in time without affecting the raw data already captured in the system, but such changes will of course affect how new data will be collected. </para>
- <para>A dataset has a period type which controls the data collection frequency, which can be daily, weekly, monthly, quarterly, six-monthly, or yearly. Both which data elements to include in the dataset and the period type is defined by the user, together with a name, short name, and code.</para>
- <para>In order to use a dataset to collect data for a specific orgunit you must assign the orgunit to the dataset, and this mechanism controls which orgunits that can use which datasets, and at the same time defines the target values for data completeness (e.g. how many health facilities in a district expected to submit RCH data every month). </para>
- <para>A data element can belong to multiple datasets, but this requires careful thinking as it may lead to overlapping and inconstant data being collected if e.g. the datasets are given different frequencies and are used by the same orgunits.
-</para>
+ <para>Toda la entrada de datos en DHIS 2 se organiza mediante la utilización de sets de datos. Un set de datos es una colección de elementos de datos agrupados juntos para la recopilación de datos, y en el caso de instalaciones distribuidas también define pedazos de datos para exportarlos o importarlos entre instancias de DHIS 2 (por ejemplo de una instalatión local en una oficina distrital a un servidor nacional). Los sets de datos no están vinculados directamente a los valores de datos, solo mediante sus elementos de datos y frecuencias, y como tales los sets de datos pueden ser modificados, eliminados o añadidos en cualquier momento sin que esto afecte a los datos en bruto previamente capturados en el sistema, pero tales cambios afectarán por su puesto a cómo se registrarán nuevos datos.</para>
+ <para>Un set de datos tiene un tipo de periodo que indica la frecuencia de registro de datos, que puede ser diaria, semanal, mensual, trimestral, semestral o anual. Tanto qué elementos incluir en el set de datos como el tipo de periodo son definidos por el usuario, junto con un nombre, un nombre corto y un código.</para>
+ <para>Para utilizar un set de datos para recopilar los datos de una unidad organizativa específica debemos asignar la unidad organizativa al set de datos, y este mecanismo controla qué unidades organizativas pueden utilizar qué sets de datos, y al mismo tiempo define los valores objetivo para la completitud de los datos (por ejemplo, cuántos establecimientos de salud en un distrito esperamos que envién datos de RCH cada mes). </para>
+ <para>Un elemento de datos puede pertenecer a múltiples sets de datos, pero requiere una reflexión cuidadosa ya que puede luego provocar solapes y el registro de datos inconsistentes si por ejemplo, los sets de datos reciben diferentes frecuencias y son utilizados por las mismas unidades organizativas. </para>
<section>
<title>Formularios de entrada de datos</title>
- <para>Once you have assigned a dataset to an orgunit that dataset will be made available in Data Entry (under Services) for the orgunits you have assigned it to and for the valid periods according to the dataset's period type. A default data entry form will then be shown, which is simply a list of the data elements belonging to the dataset together with a column for inputting the values. If your dataset contains data elements with categories such as age groups or gender, then additional columns will be automatically generated in the default form based on the categories. In addition to the default list-based data entry form there are two more alternatives, the section-based form and the custom form.</para>
+ <para>Una vez hemos asignado un set de datos a una unidad organzativa, ese set de datos quedará disponible en Entrada de Datos (en el menú de Servicios) para las unidades organizativas que le hayamos asignado y para los periodos válidos de cuerdo con el tipo de periodo del set de datos. Un formulario de entrada de datos por defecto aparecerá encontes, y es simplemente una lsta de los elementos de datos que pertenecen al set de datos junto a una columna para introducir los valores. Si nuestro set de datos contiene elementos de datos con categorías como grupos de edad o género, entonces aparecerán columnas adicionales en el formulario por defecto en base a estas categorías. Además del listado por defecto hay otras dos alternativas de formularios: de sección y personalizado.</para>
<section>
<title>Formularios de Sección</title>
- <para>Section forms allow for a bit more flexibility when it comes to using tabular forms and are quick and simple to design. Often your data entry form will need multiple tables with subheadings, and sometimes you need to disable (grey out) a few fields in the table (e.g. some categpories do not apply to all data elements), both of these functions are supported in section forms. After defining a dataset you can define it's sections with subsets of dataelements, a heading and possible grey fields i the section's table. The order of sections in a datsaset can also be defined. In Data Entry you can now start using the Section form (should appear automatically when sections are available for the selected dataset). You can switch between default and section forms in the top right corner of the data entry screen. Most tabular data entry forms should be possible to do with sections forms, and the more you can utilise the section forms (or default forms) the easier it is for you. If these two types of forms are not meeting your requirements then the third option is the completely flexible, although more time-consuming, custom data entry forms.</para>
+ <para>Los formularios de sección nos permiten una mayor flexibilidad que los formularios en tabla (por defecto) y son rápidos y sencillos de diseñar. Frecuentemente nuestros formularios de entrada de datos requieren múltiples tablas con subtítulos, y a veces necesitamos deshabilitar (poner en gris) unos pocos campos de la table (por ejemplo, para algunas categorías que no aplican a todos los elementos de datos), y estas funciones son soportadas en los formularios de sección. Después de definir un set de datos podemos definir sus secciones con subsets de elementos de datos, un encabezado y posibles campos en gris. También podemos fijar el orden de las secciones en un set de datos. En Entrada de Datos podemos comenzar a utilziar el formulario de sección (deberá aparecer automáticamente cuando las secciones quedan disponibles para el set de datos seleccionado). Podemos cambiar pasar de formularios por defecto a sección en la esquina superior derecha de la pantalla de entrada de datos. Muchos formularios de entrada de datos tabulares deberían poder convertirse en formularios de sección, y cuantos más de estos utilicemos más facil nos resultará. Si estos dos tipos de formularios no cumplen nuestros requisitos, entonces tenemos también una opción totalmente flexible, aunque nos llevará más tiempo su diseño: los formularios personalizados de entrada de datos.</para>
</section>
<section>
<title>Formularios personalizados</title>
- <para>When the form you want to design is too complicated for the default or section forms then your last option is to use a custom form. This takes more time, but gives you full flexibility in term of the design. In DHIS 2 there is a built in HTML editor (FcK Editor) for the form designer and you can either design the form in the UI or paste in your html directly (using the Source window in the editor. In the custom form you can insert static text or data fields (linked to data elements + category) in any position on the form and you have complete freedom to design the layout of the form. Once a custom form has been added to a dataset it will be available in data entry and used automatically. You can switch back to default and section (if exists) forms in the top right corner of the data entry screen. </para>
+ <para>Cuando el formulario que queremos diseñar es demasiado complicado para los formatos por defecto o de sección, esta es nuestar última opción. Nos llevará más tiempo, pero ofrece total flexibilidad en términos de diseño. En DHIS2 hay un editor HTML (Editor FcK) para el diseñador de formularios y podemos diseñar el formulario en el interfaz de usuario o bien pegar nuestro código HTML directamente (utilizando la ventana Fuente del editor). En el formulario personalizado podemos insertar texto estático o campos de datos (vinculados a elementos de datos y categorías) en cualquier posición del formulario y tendremos total libertad para diseñar la apariencia del formulario. Una vez hayamos añadido el formulario personalizado a un set de datos, deberá estar disponible en Entrada de Datos y podremos comenzar a usarlo inmediatamente. Podemos cambiar o regresar a los formularios por defecto o de sección, en la esquina superior derecha de la pantalla de entrada de datos.</para>
</section>
</section>
</section>
<section>
<title>Reglas de validación</title>
- <para>Once you have set up the data entry part of the system and started to collect data then there is time to define data quality checks that help to improve the quality of the data being collected. You can add as many validation rules as you like and these are composed of left and right side expressions that again are composed of data elements, with an operator between the two sides. Typical rules are comparing subtotals to totals of something. E.g. if you have two data elements "HIV tests taken" and "HIV test result positive" then you know that in the same form (for the same period and organisational unit) the total number of tests must always be equal or higher than the number of positive tests. These rules should be absolute rules meaning that they are mathematically correct and not just assumptions or "most of the time correct". The rules can be run in data entry, after filling each form, or as a more batch like process on multiple forms at the same time, e.g. for all facilities for the previous reporting month. The results of the tests will list all violations and the detailed values for each side of the expression where the violation ocurred to make it easy to go back to data entry and correct the values.</para>
+ <para>Una vez que hayamos configurado la parte de entrada de datos del sistema y comenzado a recoger datos, entonces es momento de definir chequeos de calidad de los datos que ayuden a mejorar la calidad de los datos que se están recopilando. Podemos añadir tantas reglas de validación como queramos, que estarán compuestas por expresiones a izquierda y derecha de un operador matemático, que a su vez están formadas por elementos de datos. Las reglas típicas consisten en comparar los subtotales con los totales de algo. Por ejemplo, si tenemos dos elementos de datos "Test VIH realizados" y "Test VIH resultado positivo", entonces sabemos que en el mismo formulario (es decir, para el mismo periodo y unidad organizativa) el número total de tests deberá ser siempre igual o mayor que el número de tests positivos. Estas reglas deberían ser reglas absolutas, que significa que son matemáticamente correctas y no simplemente asunciones o "casi siempre correctas". Las reglas se pueden ejecutar en la entrada de datos, después de rellenar cada formulario, o como un proceso por tandas testeando múltiples formularios de una vez, por ejemplo para todos los establecimientos durante el mes de reporte previo. Los resultados de los tests de validación mostrarán un listado con todas las infracciones y con los valores detallados de cada lado de la expresión donde se produjo la infracción para facilitar que regresemos a la entrada de datos y corrijamos los valores.</para>
</section>
<section>
<title>Indicadores</title>
- <para>Indicators represent perhaps the most powerful data analysis feature of the DHIS 2. While data elements represent the raw data (counts) being collected the indicators represent formulas providing coverage rates, incidence rates, ratios and other formula-based units of analysis. An indicator is made up of a factor (e.g. 1, 100, 100, 100 000), a numerator and a denominator, the two latter are both expressions based on one or more data elements. E.g. the indicator "BCG coverage <1 year" is defined a formula with a factor 100, a numerator ("BCG doses given to children under 1 year") and a denominator ("Target population under 1 year"). The indicator "DPT1 to DPT3 drop out rate" is a formula of 100 % x ("DPT1 doses given"- "DPT3 doses given") / ("DPT1 doses given"). </para>
- <para>Most report modules in DHIS 2 support both data elements and indicators and you can also combine these in custom reports, but the important difference and strength of indicators versus raw data (data element's data values) is the ability to compare data across different geographical areas (e.g. highly populated vs rural areas) as the target population can be used in the denominator.</para>
- <para>Indicators can be added, modified and deleted at any point in time without interfering with the data values in the database. </para>
+ <para>Los indicadores representan seguramente la herramienta más poderosa de análisis incluida en DHIS 2. Mientras los elementos de datos representan los datos en bruto (conteos) que son recopilados, los indicadores representan fórmulas que proporcionan tasas cobertura, tasas de incidencia, ratios y otras unidades de análisis calculadas. Un indicador se compone de un factor (por ejemplo 1, 10, 100, 10 000), un numerador y un denominador, los dos últimos siendo expresiones obtenidas a partir de uno o varios elementos de datos. A modo de ejemplo, el indicador "Cobertura BCG <1 año" queda definido por una fórmula con factor 100, numerador el número de "dosis BCG entregadas a niños menores de 1 año", y denominador la "población diana menor de 1 año". El indicador "Tasa de exclusión de DPT1 a DPT3" es una fórmula de 100 % x ("Dosis entregadas DPT1"-"Dosis entregadas DPT3") / ("Dosis entregadas DPT1")</para>
+ <para>La mayoría de los módulos de reporte en DHIS 2 soportan tanto elementos de datos como indicadores y podemos incluso combinarlos en reportes personalizados. Pero la diferencia más importante y la ventaja de los indicadores frente a los datos en bruto (los valores de los datos en los elementos de datos) es la capacidad para comparar datos a través de áreas geográficas distintas (por ejemplo, áreas muy pobladas frente a áreas rurales) ya que la población diana puede utilizarse como denominador.</para>
+ <para>Es posible añadir, modificar y eliminar indicadores en cualquier momento sin interferir en los valores de los datos que ya se encuentran en la base de datos.</para>
</section>
<section>
<title>Reportes y tablas de reportes</title>
- <para>Standard reports in DHIS 2 is a very flexible way of presenting the data that has been collected. Data can be aggregated by any organisational unit or orgunit level, by data element, by indicators, as well as over time (e.g. monthly, quarterly, yearly). The report tables are custom data sources for the standard reports and can be flexibly defined in the user interface and later accessed in external report designers such as iReport or BIRT. These report designs can then be set up as easily accessible one-click reports with parameters so that the users can run the same reports e.g. every month when new data is entered, and also be relevant to users at all levels as the organisational unit can be selected at the time of running the report.</para>
+ <para>Una manera muy flexible de presentar los datos que se han recopilado son los reportes estándar en DHIS 2. Los datos pueden ser agregados por unidad organizativa o cualquier nivel de orgunit, por elemento de datos, por indicadores, así como a lo largo del tiempo (por ejemplo, mensual, trimestral, anualmente). Las tablas de reportes son fuentes de datos personalizadas para los reportes estándar y se pueden definir de manera flexible en el interfaz de usuario y posteriormente acceder a ellas con diseñadores externos de reportes como iReport o BIRT. Estos diseños de reporte se pueden configurar para ser accesibles fácilmente "one-click" con unos parámetros predefinidos de modo que los usuarios puedan lanzar los mismos reportes, por ejemplo, cada mes cuando se introducen nuevos datos, y también pueden ser relevantes a usuarios a todos los niveles ya que la unidad organizativa puede seleccionarse al momento de lanzar el reporte.</para>
</section>
<section>
<title>SIG</title>
- <para>In the integrated GIS module you can easily display your data on maps, both on polygons (areas) and as points (health facilities), and either as data elements or indicators. By providing the coordinates of your organisational units to the system you can qucikly get up to speed with this module. See the GIS section for details on how to get started. </para>
+ <para>En el módulo integrado de SIG podemos mostrar fácilmente nuestros datos en mapas, tanto en polígonos (áreas) como en puntos (establecimientos de salud), y tanto los elementos de datos como los indicadores. Si añadimos al sistema las coordenadas de nuestras unidades organizativas, podemos rápidamente comenzar a trabajar con este módulo. Recomendamos ver la sección SIG para más detalles sobre cómo configurar este módulo. </para>
</section>
<section>
<title>Gráficas y panel de control (dashboard)</title>
- <para>On of the easiest way to display your indicator data is through charts. An easy to use chart dialogue will guide you through the creation of various types of charts with data on indicators, organisational units and periods of your choice. These charts can easily be added to one of the four chart sections on your dashboard and there be made easily available right after log in. Make sure to set the dashboard module as the start module in user settings. </para>
+ <para>Una de las maneras más sencillas de mostrar nuestros datos de indicadores es utilizar gráficas. Una pantalla de diálogo amigable nos guiará a través de la creación de varios tipos de gráficas con data de indicadores, unidades organizativas y periodos a nuestra elección. Estas gráficas pueden añadirse fácilmente a una de las cuatro secciones del dashboard destinadas a gráficas, y así las tendremos disponibles directamente al entrar en nuestra sesión. Para esto deberemos fijar el módulo dashboard como el módulo de inicio en la configuración de usuario.</para>
</section>
</section>
</chapter>
=== added file 'src/docbkx/es/resources/images/dhis2UserManual/dhis2_information_cycle.png'
Binary files src/docbkx/es/resources/images/dhis2UserManual/dhis2_information_cycle.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/dhis2UserManual/dhis2_information_cycle.png 2012-12-21 17:10:34 +0000 differ
