=== modified file 'src/docbkx/en/dhis2_implementation_guide_conceptual_design_principles.xml' --- src/docbkx/en/dhis2_implementation_guide_conceptual_design_principles.xml 2012-02-08 22:35:01 +0000 +++ src/docbkx/en/dhis2_implementation_guide_conceptual_design_principles.xml 2012-09-20 11:21:47 +0000 @@ -38,13 +38,13 @@
Data input != Data output - In DHIS 2 there are three dimensions that describe the aggregated data being collected and stored in the database; the where - organisation unit, the what - data element, and the when - period. The organisation unit, data element and period make up the three core dimensions that are needed to describe any data value in the DHIS 2, whether it is a in a data collection form, a chart, on a map, or in an aggregated summary report. When data is collected in an electronic data entry form, sometimes through a mirror image of the paper forms used at facility level, each entry field in the form can be described using these three dimensions. The form itself is just a tool to organise the data collection and is not describing the individual data values being collected and stored in the database. Being able to describe each data value independently through a Data Element definition (e.g. ‘Measles doses given <1 year’) provides important flexibility when processing, validating, and analysing the data, and allows for comparison of data across collection forms and health programs. - This design or data model approach separates DHIS from many of the traditional HIS software applications which threat the data collection forms as the key unit of analysis. This is typical for systems tailored to vertical programs’ needs and the traditional conceptualisation of the collection form as also being the report or the analysis output. The figure below illustrates how the more fine-grained DHIS design built around the concept of Data Elements is different and how the input (data collection) is separated from the output (data analysis), supporting more flexible and varied data analysis and dissemination. The data element ‘Measles doses given <1 y’ is collected as part of a Child Immunisation collection form, but can be used individually to build up an Indicator (a formula) called ‘Measles coverage <1y’ where it is combined with the data element called ‘Population <1y’, being collected through another collection form. This calculated Indicator value can then be used in data analysis in various reporting tools in DHIS 2, e.g. custom designed reports with charts, pivot tables, or on a map in the GIS module. + In DHIS 2 there are three dimensions that describe the aggregated data being collected and stored in the database; the where - organisation unit, the what - data element, and the when - period. The organisation unit, data element and period make up the three core dimensions that are needed to describe any data value in the DHIS 2, whether it is in a data collection form, a chart, on a map, or in an aggregated summary report. When data is collected in an electronic data entry form, sometimes through a mirror image of the paper forms used at facility level, each entry field in the form can be described using these three dimensions. The form itself is just a tool to organise the data collection and is not describing the individual data values being collected and stored in the database. Being able to describe each data value independently through a Data Element definition (e.g. ‘Measles doses given <1 year’) provides important flexibility when processing, validating, and analysing the data, and allows for comparison of data across collection forms and health programs. + This design or data model approach separates DHIS from many of the traditional HIS software applications which treat the data collection forms as the key unit of analysis. This is typical for systems tailored to vertical programs’ needs and the traditional conceptualisation of the collection form as also being the report or the analysis output. The figure below illustrates how the more fine-grained DHIS design built around the concept of Data Elements is different and how the input (data collection) is separated from the output (data analysis), supporting more flexible and varied data analysis and dissemination. The data element ‘Measles doses given <1 y’ is collected as part of a Child Immunisation collection form, but can be used individually to build up an Indicator (a formula) called ‘Measles coverage <1y’ where it is combined with the data element called ‘Population <1y’, being collected through another collection form. This calculated Indicator value can then be used in data analysis in various reporting tools in DHIS 2, e.g. custom designed reports with charts, pivot tables, or on a map in the GIS module.
Indicator-driven data analysis and reporting - What is referred to as a Data Element above, the key dimension that describes what is being collected, is sometimes referred to as an indicator in other settings. In DHIS 2 we distinguish between Data Elements who describe the the raw data, e.g. the counts being collected, and Indicators, which are formula-based and describe calculated values, e.g. coverage or incidence rates that are used for data analysis. Indicator values are not collected like the data (element) values, but instead calculated by the application based on formulas defined by the users. These formulas are 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 "Measles coverage <1 year" is defined a formula with a factor 100, a numerator ("Measles 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"- "DPT3doses given") / ("DPT1 doses given"). These formulas can be added and edited through the user interface by a user with limited training, as they are quite easy to set up and do not interfere with the data values stored in the database (so adding or modifying an indicator is not a critical operation). + What is referred to as a Data Element above, the key dimension that describes what is being collected, is sometimes referred to as an indicator in other settings. In DHIS 2 we distinguish between Data Elements which describe the the raw data, e.g. the counts being collected, and Indicators, which are formula-based and describe calculated values, e.g. coverage or incidence rates that are used for data analysis. Indicator values are not collected like the data (element) values, but instead calculated by the application based on formulas defined by the users. These formulas are 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 "Measles coverage <1 year" is defined a formula with a factor 100, a numerator ("Measles 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"- "DPT3doses given") / ("DPT1 doses given"). These formulas can be added and edited through the user interface by a user with limited training, as they are quite easy to set up and do not interfere with the data values stored in the database (so adding or modifying an indicator is not a critical operation). Indicators represent perhaps the most powerful data analysis feature of the DHIS 2, and all reporting tools support the use of indicators, e.g. as displayed in the custom report in the figure above. Being able to use population data in the denominator enables comparisons of health performance across geographical areas with different target populations, which is more useful than only looking at the raw numbers. The table below uses both the raw data values (Doses) and indicator values (Cov) for the different vaccines. Comparing e.g. the two first orgunits in the list, Taita Taveta County and Kilifi County, on DPT-1 immunisation, we can see that while the raw numbers (659 vs 2088) indicate many more doses are given in Kilifi, the coverage rates (92.2 % vs 47.5 %) show that Taita Taveta are doing a better job immunising their target population under 1 year. Looking at the final column (Immuniz. Compl. %) which indicates the completeness of reporting of the immunisation form for the same period, we can see that the numbers are more or less the same in the two counties we compared, which tells us that the coverage rates are comparable across the two counties.
=== modified file 'src/docbkx/es/dhis2_implementation_guide_conceptual_design_principles.xml' --- src/docbkx/es/dhis2_implementation_guide_conceptual_design_principles.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_conceptual_design_principles.xml 2012-09-20 11:21:47 +0000 @@ -2,60 +2,65 @@ - Conceptual Design Principles - This chapter provides a introduction to some of the key conceptual design principles behind the DHIS 2 software. Understanding and being aware of these principles will help the implementer to make better use of the software when customising a local database. While this chapter introduces the principles, the following chapters will detail out how these are reflected in the database design process. - The following conceptual design principles will be presented in this chapter: + Principios conceptuales de diseño + Este capítulo pretende servir de introducción a algunos de los principios conceptuales clave de diseño que alberga el software DHIS 2. La comprensión y toma de conciencia sobre estos principios ayudará a los implementadores a hacer un uso óptimo del software al personalizar una base de datos local. Si bien este capítulo solo se centra en los principios, los capítulos siguientes detallan cómo éstos repercuten en el proceso de diseño de la base de datos + En este capítulo se presentan los siguientes principios de diseño: - All meta data can be added and modified through the user interface - - - A flexible data model supports different data sources to be integrated in one single data repository - - - Data Input != Data Output - - - Indicator-driven data analysis and reporting - - - Maintain disaggregated facility-data in the database - - - Support data analysis at any level in the health system + Que todos los metadatos puedan añadirse y modificarse a través del interfaz de usuario + + + Que un modelo de datos flexible soporte que diferentes fuentes de datos puedan ser integradas en un único repositorio de datos + + + Que la entrada de datos != Salida de datos + + + Que el análisis de datos y reportes estén basados en indicadores + + + Que los datos de establecimientos de salud se mantengan desagregados en la base de datos + + + Que el análisis de datos esté soportado para cualquier nivel del sistema de salud - In the following section each principle is described in more detail. -
- All meta data can be added and modified through the user interface - The DHIS 2 application comes with a set of generic tools for data collection, validation, reporting and analysis, but the contents of the database, e.g. what data to collect, where the data comes from, and on what format, will depend on the context of use. This meta data 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. This allows for more direct involvement of the domain experts that understand the details of the HIS that the software will support. - The software separates the key meta data that describes the raw data being stored in the database, which is the critical meta data that should not change much over time (to avoid corrupting the data), and the higher level meta like indicator formulas, validation rules, and groups for aggregation as well as the various layouts for collection forms and reports, which are not that critical and can be changed over time without interfering with the raw data. As this higher level meta data can be added and modified over time without interfering with the raw data, a continuous customisation process is supported. Typically new features are added over time as the local implementation team learn to master more functionality, and the users are gradually pushing for more advanced data analysis and reporting outputs. -
-
- A flexible data model supports different data sources to be integrated in one single data repository - The DHIS 2 design follows an integrated approach to HIS, and supports integration of many different data sources into one single database, sometime referred to as an integrated data repository or a data warehouse. - The fact that DHIS 2 is a skeleton like tool without predefined forms or reports means that it can support a lot of different aggregate data sources. There is nothing really that limits the use to the health domain either, although use in other sectors are still very limited. As long as the data is collected by and orgunit, described as a data element (possibly with some disaggregation categories), and can be represented by a predefined period frequency, it can be collected and processed in DHIS 2. This flexibility makes DHIS 2 a powerful tool to set up integrated systems that bring together collection tools, indicators, and reports from multiple health programs, departments or initiatives. Once the data is defined and then collected or imported into a DHIS 2 database, it can be analysed in correlation to any other data in the same database, no matter how and by whom it was collected. In addition to supporting integrated data analysis and reporting, this integrated approach also helps to rationalise data collection and reduce duplication. -
-
- Data input != Data output - In DHIS 2 there are three dimensions that describe the aggregated data being collected and stored in the database; the where - organisation unit, the what - data element, and the when - period. The organisation unit, data element and period make up the three core dimensions that are needed to describe any data value in the DHIS 2, whether it is a in a data collection form, a chart, on a map, or in an aggregated summary report. When data is collected in an electronic data entry form, sometimes through a mirror image of the paper forms used at facility level, each entry field in the form can be described using these three dimensions. The form itself is just a tool to organise the data collection and is not describing the individual data values being collected and stored in the database. Being able to describe each data value independently through a Data Element definition (e.g. ‘Measles doses given <1 year’) provides important flexibility when processing, validating, and analysing the data, and allows for comparison of data across collection forms and health programs. - This design or data model approach separates DHIS from many of the traditional HIS software applications which threat the data collection forms as the key unit of analysis. This is typical for systems tailored to vertical programs’ needs and the traditional conceptualisation of the collection form as also being the report or the analysis output. The figure below illustrates how the more fine-grained DHIS design built around the concept of Data Elements is different and how the input (data collection) is separated from the output (data analysis), supporting more flexible and varied data analysis and dissemination. The data element ‘Measles doses given <1 y’ is collected as part of a Child Immunisation collection form, but can be used individually to build up an Indicator (a formula) called ‘Measles coverage <1y’ where it is combined with the data element called ‘Population <1y’, being collected through another collection form. This calculated Indicator value can then be used in data analysis in various reporting tools in DHIS 2, e.g. custom designed reports with charts, pivot tables, or on a map in the GIS module. + A continuación cada principio se describe en mayor detalle en las respectivas secciones. +
+ Todos los metadatos pueden añadirse y modificarse a través del interfaz de usuario + La aplicación DHIS 2 trae un set de herramientas genéricas para la recolección de datos, validación, elaboración de reportes y análisis de datos. Sin embargo, los contenidos de la base de datos, tales como qué datos recolectar, de dónde vienen los datos, o en qué formato, depende del contexto de uso de esa información. Antes de poder utilizar estos metadatos es preciso ingresarlos en la aplicación, lo cual puede hacerse a través del interfaz de usuario y no requiere programación. Esto permite involucrar más directamente a los expertos de ese ámbito, que son quienes entienden los detalles del SIS que el software debe soportar. + El software separa los metadatos importantes que describen los datos en bruto que son almacenados en la base de datos, que son los metadatos críticos que no debieran cambiar mucho a lo largo del tiempo (para evitar la corrupción de datos), y los metadatos de alto nivel como las fórmulas de indicadores, las reglas de validación y los grupos de agregación, así como las diferentes capas (layouts) para recogida de formularios y reportes, que no son tan críticos. En este alto nivel los metadatos pueden añadirse y modificarse en el tiempo sin interferir con los datos en bruto, soportando un proceso permanente de personalización. Es típico añadir nuevos atributos a medida que el equipo local de implementación va aprendiendo a dominar más funcionalidades de la aplicación, y que los usuarios van introduciendo gradualmente análisis de datos y reportes más avanzados. +
+
+ Un modelo de datos flexible soporta que diferentes fuentes de datos puedan ser integradas en un único repositorio de datos + El diseño de DHIS 2 sigue una aproximación integral del SIS, y soporta la integración de muchas fuentes de datos diversas en una misma base de datos, en ocasiones denominada repositorio integrado de datos o data warehouse + El hecho de que DHIS 2 sea una especie de herramienta esqueleto sin formularios o reports predefinidos significa que puede soportar una buena cantidad de diferentes fuentes de datos agregados. Tampoco hay nada que limite realmente su uso al ámbito de la salud, aunque su uso en otros sectores es aún muy restringido. Mientras los datos sean recogidos por una orgunit, descritos como elementos de datos (probablemente con una desagregación en categorías), y puedan representarse con una frecuencia y periodos predefinidos, esos datos pueden recolectarse y procesarse en DHIS 2. Esta flexibilidad hace que DHIS 2 sea una herramienta potente para montar sistemas integrados que aúnen herramientas de recolección, de indicadores y de reportes de múltiples programas de salud, departamentos e iniciativas. Una vez que los datos se definen y luego se recogen o importan en una base de datos de DHIS 2, pueden analizarse en correlación con otros datos cualesquiera de la misma base de datos, sin importar cómo o quién introdujo los datos. Además de soportar el análisis y reporte integrado de datos, este enfoque integrado también ayuda a racionalizar la recolección de datos y a reducir los duplicados. +
+
+ Entrada de datos != Salida de datos + En DHIS 2 hay tres dimensiones que describen los datos agregados que se están recogiendo y almacenando enla base de datos: DÓNDE - la unidad organizativa, QUÉ - el elemento de datos, y CUÁNDO - el periodo. La unidad organizativa, el elemento de datos y el periodo constitutyen las tres dimensiones nucleares necesarias para describir cualquier valor de un dato en DHIS 2, ya se encuentr en un formulario de recogida de datos, en un gráfico, en un mapa, o en un reporte sumarístico agregado. Cuando los datos se recogen en formularios electrónicos, que a veces son imágenes especulares de los formularios en papel utilizados en los establecimientos, cada campo de entrada del formulario queda descrito utilizando estas tres dimensiones. El formulario en sí mismo es tan solo una herramienta para organizar la recolección de datos y no describe los valores de datos individuales que se están recogiendo o guardando en la base de datos. Ser capaces de describir cada valor de datos independientemente mediante una definición de Elemento de Datos (por ejemplo, 'Dosis de sarampión suministradas < 1 año') permite una importante flexibilidad a la hora de procesar, validar y analizar los datos, permitiendo comparar datos en diversos formularios y programas de salud. + + Este enfoque de diseño o de modelo de datos marca la diferencia entre DHIS y muchas otras aplicaciones software de SIS que tratan los formularios de recogida de datos como la unidad clave del análisis. Esto es muy típico en sistemas hechos a la medida de las necesidades de programas verticales de salud y en la mentalidad tradicional de que el formulario de entrada de datos agregados es ya también la salida de reporte o de análisis. + + La figura siguiente muestra cómo el diseño granular fino de DHIS, construido sobre el concepto de Elementos de Datos, es diferente y cómo la entrada (recogida de datos) está separada de la salida (análisis de datos), permitiendo un análisis y diseminación de datos más flexible y variada. En el ejemplo, el elemento de dato 'Dosis de sarampión suministradas < 1 año' es registrado como parte de un formulario de registro de Inmunización Infantil, pero puede utilizarse individualmente para construir un Indicador (una fórmula) llamada 'Cobertura de sarampión < 1 año', donde se combina con el elemento de datos llamado 'Población < 1 año', que se registra en un formulario distinto. El valor de este indicador calculado puede utilizarse luego en el análisis de datos de varias herramientas de reporte en DHIS 2, como por ejemplo en reportes personalizados con gráficos, tablas dinámicas, o en un mapa en el módulo SIG. +
- Indicator-driven data analysis and reporting - What is referred to as a Data Element above, the key dimension that describes what is being collected, is sometimes referred to as an indicator in other settings. In DHIS 2 we distinguish between Data Elements who describe the the raw data, e.g. the counts being collected, and Indicators, which are formula-based and describe calculated values, e.g. coverage or incidence rates that are used for data analysis. Indicator values are not collected like the data (element) values, but instead calculated by the application based on formulas defined by the users. These formulas are 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 "Measles coverage <1 year" is defined a formula with a factor 100, a numerator ("Measles 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"- "DPT3doses given") / ("DPT1 doses given"). These formulas can be added and edited through the user interface by a user with limited training, as they are quite easy to set up and do not interfere with the data values stored in the database (so adding or modifying an indicator is not a critical operation). - Indicators represent perhaps the most powerful data analysis feature of the DHIS 2, and all reporting tools support the use of indicators, e.g. as displayed in the custom report in the figure above. Being able to use population data in the denominator enables comparisons of health performance across geographical areas with different target populations, which is more useful than only looking at the raw numbers. The table below uses both the raw data values (Doses) and indicator values (Cov) for the different vaccines. Comparing e.g. the two first orgunits in the list, Taita Taveta County and Kilifi County, on DPT-1 immunisation, we can see that while the raw numbers (659 vs 2088) indicate many more doses are given in Kilifi, the coverage rates (92.2 % vs 47.5 %) show that Taita Taveta are doing a better job immunising their target population under 1 year. Looking at the final column (Immuniz. Compl. %) which indicates the completeness of reporting of the immunisation form for the same period, we can see that the numbers are more or less the same in the two counties we compared, which tells us that the coverage rates are comparable across the two counties. + Análisis de datos y reportes basados en indicadores + Aquello que hemos llamado previamente Elemento de Datos es la dimensión clave que describe qué se está registrando (en otros contextos puede nombrarse somo indicador). En DHIS 2 distinguimos entre Elementos de Datos, que describen los datos en bruto, como los recuentos, y los Indicadores, que parten de fórmulas y describen valores calculados, como por ejemplo cobertura o tasa de incidencia que se utilizan para en el análisis. Los valores de los indicadores no se registran como los valores de datos, sino que se calculan enla aplicación a partir de fórmulas definidas por los usuarios. Estas fórmulas constan de un factor (ej. 1, 100, 1000, 200 000), y de un numerador y un denominador, que son expresiones construidas con uno o más elementos de datos. Por ejemplo, el indicador 'Cobertura de sarampión < 1 año' se define con una fórmula de factor 100, un numerador ('Dosis de sarampión suministradas a niños menores de 1 año') y n denominador ('Población diana menores de 1 año'). El indicador 'Tasa de exclusión DPT1 a DPT3' es una fórmula de 100 % x ('Dosis suministradas DPT1' - 'Dosis suministradas DPT3') / ('Dosis suministradas DPT1'). Estas fórmulas pueden añadirse y editarse a través del interfaz de usuario por usuarios con una capacitación básica, ya que son bastante sencillos de configurar y no interfieren con los valores de datos almacenados en la base de datos (de modo que añadir o modificar un indicador no es una operación crítica). + Los indicadores son tal vez la característica más potente de DHIS 2 y todas las herramientas de reporte soportan el manejo de indicadores, como se muestra por ejemplo en el reporte personalizado de la figura anterior. Tener la capacidad de utilizar datos de población en el denominador permite comparaciones de desempeño en salud entre diversas áreas geográficas con distintas poblaciones diana, lo cual resulta más útil que mirar únicamente los números en bruto. La tabla siguiente utiliza tanto valores de datos en bruto (las dosis) como los valores de indicadores (la cobertura) para diferentes vacunas. Comparando por ejemplo las dos primeras unidades organizativas de la lista, distrito de Taita Taveta y distrito de Kilifi, en inmunización DPR-1, podemos observar que mientras los números en bruto (659 vs 2088) indican que se suministraron muchas más dosis en Kilifi, las tasas de cobertura (92.2 % vs 47.5 %) muestran que Taita Taveta está realizando un mejor trabajo en la inmunización de su población diana menores de 1 año. Si observamos ahora la última columna (Inmunización completada %), que indica la integridad de registros del formulario de inmunización para el mismo periodo, vemos que los números son más o menos los mismos para los dos distritos comparados, lo cual apunta a que las tasas de cobertura son comparables en los dos distritos. Si estos números fueran diferentes podríamos apuntar a menor tasa de reporte aunque no podríamos concluir sobre las tasas de cobertura.
- Maintain disaggregated facility-data in the database - When data is collected and stored in DHIS 2 it will remain disaggregated in the database with the same level of detail as it was collected. This is a major advantage of having a database system for HIS as supposed to a paper-based or even spreadsheet based system. The system is designed to store large amounts of data and always allow drill-downs to the finest level of detail possible, which is only limited by how the data was collected or imported into the DHIS 2 database. In a perspective of a national HIS it is desired to keep the data disaggregated by health facility level, which is often the lowest level in the orgunit hierarchy. This can be done even without computerising this level, through a hybrid system of paper and computer. The data can be submitted from health facilities to e.g. district offices by paper (e.g. on monthly summary forms for one specific facility), and then at the district office they enter all the facility data into the DHIS 2 through the electronic data collection forms, one facility at a time. This will enable the districts health management teams to perform facility-wise data analysis and to e.g. provide print-outs of feedback reports generated by the DHIS 2, incl. facility comparisons, to the facility in-charges in their district. + Mantener los datos de establecimientos desagregados en la base de datos + Cuando se recogen datos y se almacenan en DHIS 2, éstos quedarán desagregados en la base de datos con el mismo nivel de detalle con el cual fueron registrados. Ésta es la mayor ventaja de tener un sistema de base de datos para SIS similar a lo esperado de un sistema en papel o incluso en hojas de cálculo. El sistema se diseña para almacenar gran cantidad de datos y siempre permite exámenes a fondo hasta el nivel más fino posible de detalle, que solo está limitado por la manera en que los datos fueron registrados o importados en la base de datos DHIS 2. + Desde la perspectiva de un SIS nacional, es deseable guardar los datos desagregados por nivel de establecimiento de salud, que generalmente es el nivel más bajo en la jerarquía organizativa. Esto puede hacerse incluso sin informatizar este nivel, mediante un sistema híbrido informático y en papel. Por ejemplo, los datos pueden ser enviados en papel desde los establecimientos de salud a las oficinas distritales (en formularios mensuales resumidos para un establecimiento específico), y luego en la oficina distrital ya introducen todos los datos de establecimiento en DHIS 2 mediante formularios electrónicos de recogida de datos, establecimiento por establecimiento. Esto permitirá a los equipos distritales de gestión de salud realizar análisis de datos por establecimiento y por ejemplo compartir los reportes impresos de realimentación generados en DHIS 2, incluidas comparativas entre establecimientos, con los responsables de los establecimientos en cada distrito.
- Support data analysis at any level in the health system - While the name DHIS indicates a focus on the District, the application provides the same tools and functionality to all levels in the health system. In all the reporting tools the users can select which orgunit or orgunit level to analyse and the data displayed will be automatically aggregated up to the selected level. The DHIS 2 uses the orgunit hierarchy in aggregating data upwards and provides data by any orgunit in this hierarchy. Most of the reports are run in such a way that the users will be prompted to select an orgunit and thereby enable reuse the same report layouts for all levels. Or of desired, the report layouts can be tailored to any specific level in the health system if the needs differ between the levels. - In the GIS module the users can analyse data on e.g. the sub-national level and then by clicking on the map (on e.g. a region or province) drill down to the next level, and continue like this all the way down to the source of the data at facility level. Similar drill-down functionality is provided in the Excel Pivot Tables that are linked to the DHIS 2 database. - To speed up performance and reduce the response-time when providing aggregated data outputs, which may include many calculations (e.g. adding together 8000 facilities), DHIS 2 pre-calculates all the possible aggregate values and stores these in what is called a data mart. This data mart can be scheduled to run (re-built) at a given time interval, e.g. every night. + Soporte de análisis de datos a cualquier nivel del sistema de salud + Aunque el propio nombre de DHIS apunta a un enfoque de 'distrito', la aplicación ofrece las mismas herramientas y funcionalidades a todos los niveles del sistema de salud. En todas las herramientas de reporte los usuarios pueden seleccionar qué unidad organizativa o qué nivel de orgunit desean analizar y los datos mostrados se agregarán automáticamente en el nivel seleccionado. DHIS 2 utiliza la jerarquía de unidades organizativas para agregar datos hacia arriba y nos da los datos para cualquier orgunit en esta jerarquía. La mayoría de reportes se lanzan de manera que se pedirá a los usuarios que seleccionen una unidad organizativa y así permitir la reutilización de las mismas capas de reporte para todos los niveles. O si se desea, las capas de reporte pueden diseñarse a la medida de un nivel específico cualquiera en el sistema de salud en caso de que las necesidades difieran entre diferentes niveles. + En el módulo SIG los usuarios pueden analizar los datos por ejemplo a nivel subnacional y entonces pinchando en el mapa (por ejemplo en un departamento o provincia) examinar a fondo el siguiente nivel, y continuar de este modo descendiendo hacia la fuente de datos a nivel de establecimiento. Una funcionalidad similar de profundización está disponible en las tablas dinámicas que están enlazadas con la base de datos DHIS 2. + Para acelerar el rendimiento y reducir el tiempo de respuesta al generar salidas de datos agregadas, que pueden incluir numerosos cálculos (por ejemplo juntar 8000 establecimientos), DHIS 2 realiza un precálculo de todos los valores agregados posibles y los guarda en lo que se denomina datamart. El datamart puede programarse para ser ejecutado (reconstruirse) en intervalos de tiempo determinados, por ejemplo cada noche.
=== added directory 'src/docbkx/es/resources/images/implementation_guide' === added file 'src/docbkx/es/resources/images/implementation_guide/data_input_output.png' Binary files src/docbkx/es/resources/images/implementation_guide/data_input_output.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/implementation_guide/data_input_output.png 2012-09-20 11:21:47 +0000 differ === added file 'src/docbkx/es/resources/images/implementation_guide/indicator_report.png' Binary files src/docbkx/es/resources/images/implementation_guide/indicator_report.png 1970-01-01 00:00:00 +0000 and src/docbkx/es/resources/images/implementation_guide/indicator_report.png 2012-09-20 11:21:47 +0000 differ