The organisational hierarchy

Data Elements === modified file 'src/docbkx/es/dhis2_implementation_guide_as_a_platform.xml' --- src/docbkx/es/dhis2_implementation_guide_as_a_platform.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_as_a_platform.xml 2012-09-27 08:55:25 +0000 @@ -1,7 +1,7 @@ - DHIS as a platform + DHIS como plataforma DHIS can be perceived as a platform on several levels. First, the application database is designed ground-up with flexibility in mind. Data structures such as data elements, organisation units, forms and user roles can be defined completely freely through the application user interface. This makes it possible for the system to be adapted to a multitude of locale contexts and use-cases. We have seen that DHIS supports most major requirements for routine data capture and analysis emerging in country implementations. It also makes it possible for DHIS to serve as management system for domains such as logistics, labs and finance. Second, due to the modular design of DHIS it can be extended with additional software modules. These software modules can live side by side with the core modules of DHIS and can be integrated into the DHIS portal and menu system. This is a powerful feature as it makes it possible to extend the system with extra functionality when needed, typically for country specific requirements as earlier pointed out. The downside of the software module extensibility is that it puts several constraints on the development process. The developers creating the extra functionality are limited to the DHIS technology in terms of programming language and software frameworks, in addition to the constraints put on the design of modules by the DHIS portal solution. Also, these modules must be included in the DHIS software when the software is built and deployed on the web server, not dynamically during run-time. @@ -20,7 +20,7 @@ There are several scenarios where additional software artifacts may connect to the DHIS Web API.

- Web portals + Portales Web First, Web portals may be built on top of the Web API. A Web portal in this regard is a web site which functions as a point of access to information from a potential large number of data sources which typically share a common theme. The role of the Web portal is to make such data sources easily accessible in a structured fashion under a common look-and-feel and provide a comprehensive data view for end users. Aggregate data repository: A Web portal targeted at the health domain may use the DHIS as the main source for aggregate data. The portal can connect to the Web API and communicate with relevant resources such as maps, charts, reports, tables and static documents. These data views can dynamically visualize aggregate data based on queries on the organisation unit, indicator or period dimension. The portal can add value to the information accessibility in several ways. It can be structured in a user-friendly way and make data accessible to inexperienced users. It can provide various approaches to the data, including: @@ -52,11 +52,11 @@ Forum: The portal can provide a forum for hosting discussions between professional users. The subject can range from help for performing basic operations in the health information system to discussions over data analysis and interpretation topics. Such a forum can act as interactive source for information and evolve naturally into a valuable archive.

- Apps + Aplicaciones (Apps) Second, third-party software clients running on devices such as mobile phones, smart phones and tablets may connect to the DHIS Web API and read and write to relevant resources. For instance, third-party developers may create a client running on the Android operating system on mobile devices targeted at community health workers who needs to keep track of the people to visit, register vital data for each encounter and receive reminders of due dates for patient care while travelling freely in the community. Such a client application might interact with the patient and activity plan resources exposed by the DHIS Web API. The developer will not be dependent on deep insight in the DHIS internal implementation, rather just basic skills within HTTP/Web programming and a bit of knowledge of the DHIS data model. Understanding the DHIS data model is made easier by the navigable nature of the Web API.

- Information Systems + Sistemas de Información Third, information system developers aiming at creating new ways of visualizing and presenting aggregate data can utilize the DHIS Web API as the service layer of their system. The effort needed for developing new information systems and maintaining them over time is often largely under-estimated. Instead of starting from scratch, a new application can be built on top of the Web API. Developer attention can be directed towards making new, innovative and creative data representations and visualizations, in the form of e.g. dashboards, GIS and charting components.

=== modified file 'src/docbkx/es/dhis2_implementation_guide_data_analysis_tools_overview.xml' --- src/docbkx/es/dhis2_implementation_guide_data_analysis_tools_overview.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_data_analysis_tools_overview.xml 2012-09-27 08:55:25 +0000 @@ -2,7 +2,7 @@ - Data Analysis Tools Overview + Una perspectiva general de las herramientas de análisis de datos This chapter offers an overview of the available tools for data analysis provided by DHIS 2 along with a description of the purpose and benefits of each. If you are looking for a detailed guide on how to use each tool we recommend to continue to read the user guide after finishing this chapter. The following list shows the various tools: @@ -37,46 +37,46 @@

- Data analysis tools + Herramientas de análisis de datos The following section gives a description of each tool.

- Standard reports + Reportes estándar Standard reports are reports with predefined designs. This means that the reports are easily accessible with a few clicks and can be consumed by users at all levels of experience. The report can contain statistics in the form of tables and charts and can be tailored to suit most requirements. The report solution in DHIS 2 is based on JasperReports and reports are most often designed with the iReport report designer. Even though the report design is fixed, data can be dynamically loaded into the report based on any organisation unit from in the hierarchy and with a variety of time periods.

- Data set reports + Reportes de sets de datos Data set reports displays the design of data entry forms as a report populated with aggregated data (as opposed to captured low-level data). This report is easily accessible for all types of users and gives quick access to aggregate data. There is often a legacy requirement for viewing data entry forms as reports which this tool efficiently provides for. The data set report supports all types of data entry forms including section and custom forms.

- Data completeness report + Reportes de integridad de datos The data completeness report produces statistics for the degree of completeness of data entry forms. The statistical data can be analysed per individual data sets or per a list of organisation units with a common parent in the hierarchy. It provides a percentage value for the total completeness and for the completeness of timely submissions. One can use various definitions of completeness as basis for the statistics: First based on number of data sets marked manually as complete by the user entering data. Second based on whether all data element defined as compulsory are being filled in for a data set. Third based on the percentage of number of values filled over the total number of values in a data set.

- Static reports + Reportes estáticos Static reports provides two methods for linking to existing resources in the user interface. First it provides the possibility to link to a resource on the Internet trough a URL. Second it provides the possibility to upload files to the system and link to those files. The type of files to upload can be any kind of document, image or video. Useful examples of documents to link to are health surveys, policy documents and annual plans. URLs can point to relevant web sites such as the Ministry of Health home page, sources of health related information. In addition it can be used as an interface to third-party web based analysis tools by pointing at specific resources. One example is pointing a URL to a report served by the BIRT reporting framework.

- Organisation unit distribution reports + Reportes de distribución de unidades organizativas The organisation unit distribution report provides statistics on the facilities (organisation units) in the hierarchy based on their classification. The classification is based on organisation unit groups and group sets. For instance can facilities be classified by type through assignment to the relevant group from the group set for organisation unit type. The distribution report produces the number of facilities for each class and can be generated for all organisation units and for all group sets in the system.

- Report tables + Tablas de reporte Report tables are reports based on aggregated data in a tabular format. A report table can be used as a stand-alone report or can be used as data source for a more sophisticated standard report design. The tabular format can be cross-tabulated with any number of dimensions appearing as columns. It can contain indicator and data element aggregate data as well as completeness data for data sets. It can contain relative periods which enables the report to be reused over time. It can contain user selectable parameters for organisation units and periods to enable the report to be reused for all organisation units in the hierarchy. The report table can be limited to the top results and sorted ascending or descending. When generated the report table data can be downloaded as PDF, Excel workbook, CSV file and Jasper report.

- Charts + Gráficas The chart component offers a wide variety of charts including the standard bar, line and pie charts. The charts can contain indicators, data elements, periods and organisation units on both the x and y axis as well as a fixed horizontal target line. Charts can be view directly or as part of the dashboard as will be explained later.

- Web Pivot tables + Tablas Web dinámicas The web pivot table offers quick access to statistical data in a tabular format and provides the ability to “pivot” any number of the dimensions such as indicators, data elements, organisation units and periods to appear on columns and rows in order to create tailored views. Each cell in the table can be visualized as a bar chart.

- GIS + SIG The GIS module gives the ability to visualize aggregate data on maps. The GIS module can provide thematic mapping of polygons such as provinces and districts and of points such as facilities in separate layers. The mentioned layers can be displayed together and be combined with custom overlays. Such map views can be easily navigated back in history, saved for easy access at a later stage and saved to disk as an image file. The GIS module provides automatic and fixed class breaks for thematic mapping, predefined and automatic legend sets, ability to display labels (names) for the geographical elements and the ability to measure the distance between points in the map. Mapping can be viewed for any indicator or data element and for any level in the organisation unit hierarchy. There is also a special layer for displaying facilities on the map where each one is represented with a symbol based on the its type.

- My Datamart and Excel Pivot tables + Tablas My Datamart y tablas dinámicas Excel The purpose of the My Datamart tool is provide users with full access to aggregate data even on unreliable Internet connections. This tool consists of a light-weight client application which is installed at the computer of the users. It connects to an online central server running a DHIS 2 instance, downloads aggregate data and stores it in a database at he local computer. This database can be used to connect third-party tools such as MS Excel Pivot tables, which is a powerful tool for data analysis and visualization. This solution implies that just short periods of Internet connectivity are required to synchronize the client database with the central online one, and that after this process is done the data will be available independent of connectivity. Please read the chapter dedicated to this tool for in-depth information.

=== modified file 'src/docbkx/es/dhis2_implementation_guide_data_elements_and_custom_dimensions.xml' --- src/docbkx/es/dhis2_implementation_guide_data_elements_and_custom_dimensions.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_data_elements_and_custom_dimensions.xml 2012-09-27 08:55:25 +0000 @@ -2,16 +2,16 @@ - Data Elements and Custom Dimensions + Elementos de datos y dimensiones personalizadas This chapter first discusses an important building block of the system: the data element. Second it discusses the category model and how it can be used to achieve highly customized meta-data structure for storage of data.

- Data elements + Elementos de datos The data element is together with the organisation unit the most important building block of a DHIS 2 database. It represents the what dimension and explains what is being collected or analysed. In some contexts this is referred to an indicator, however in DHIS 2 this meta-data element of data collection and analysis is referred to as a data element. The data element often represents a count of some event and its name describes what is being counted, e.g. "BCG doses given" or "Malaria cases". When data is collected, validated, analysed or presented it is the data elements or expressions built with data elements that describe what phenomenon, event or case the data is registered for. Hence the data element become important for all aspects of the system and decide not only how data is collected, but more importantly how the data is represented in the database and how data can be analysed and presented. An important principle behind designing data elements is to think of data elements as a self-contained description of an phenomenon or event and not as a field in a data entry form. Each data element lives on its own in the database, completely detached and independent from the collection form. It is important to consider that data elements are used directly in reports, charts and other tools for data analysis, in which the context in any given data entry form is not accessible nor relevant. In other words, it must be possible to clearly identify what event a data element represents by only looking at its name. Based on this one can derive a rule of thumb saying 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. For instance, a data element called “Malaria” might be concise when seen in a data entry form capturing immunization data, in a form capturing vaccination stocks as well as in a form for out-patient data. When viewed in a report, however, outside the context of the data entry form, it is impossible to decide what event this data element represents. If the data element had been called “Malaria cases”, “Malaria stock doses received” or “Malaria doses given” it would have been clear from a user perspective what the report is trying to express. In this case we are dealing with tree different data elements with completely different semantics.

- Categories and custom dimensions + Categorías y dimensiones personalizadas Certain requirements for data capture necessitates a fine-grained breakdown of the dimension describing the event being counted. For instance one would want to collect the number of “Malaria cases” broken down on gender and age groups, such as “female”, “male” and “< 5 years” and “> 5 years”. What characterizes this is that the breakdown is typically repeated for a number of “base” data elements: For instance one would like to reuse this break-down for other data elements such as “TB” and “HIV”. In order to make the meta-data more dynamic, reusable and suitable for analysis it makes sense to define the mentioned diseases as data elements and create a separate model for the breakdown attributes. This can be achieved by using the category model, which is described in the following. The category model has three main elements which is best described using the above example: @@ -32,7 +32,7 @@ An important point about the category model is that data values are persisted and associated with a category option combination. This implies that adding or removing categories from a category combination renders these combinations invalid and a low-level database operation much be done to correct it. It is hence recommended to thoughtfully consider which breakdowns are required and to not change them too often.

- Data element groups + Grupos de elementos de datos 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, and can also be used to aggregate values captured for data elements in the group. 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 low-level data.

=== modified file 'src/docbkx/es/dhis2_implementation_guide_data_quality.xml' --- src/docbkx/es/dhis2_implementation_guide_data_quality.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_data_quality.xml 2012-09-27 08:55:25 +0000 @@ -1,10 +1,10 @@ - Data Quality + Calidad de los datos This chapter discusses various aspects related to data quality.

- Measuring data quality + Cómo medir la calidad de los datos Is the data complete? Is it collected on time? Is it correct? These are questions that needs to be asked when analysing data. Poor data quality can take many shapes; not just incorrect figures, but a lack of completeness, or the data being too old (for meaningful use).

@@ -28,7 +28,7 @@

- Improving data quality + Cómo mejorar la calidad de los datos Improving data quality is a long-term task, and many of the measures are organizational in nature. However, data quality should be an issue from the start of any implementation process, and there are some things that can be addressed at once, such as checks in DHIS2. Some important data quality improvement measures are: @@ -49,28 +49,28 @@

- Using DHIS 2 to improve data quality + Cómo utilizar DHIS 2 para mejorar la calidad de los datos DHIS to has several features that can help the work of improving data quality; validation during data entry to make sure data is captured on the right format and within a reasonable range, user-defined validation rules based on mathematical relationships between the data being captured (e.g. subtotals vs totals), outlier analysis functions, as well as reports on data coverage and completeness. More indirectly, several of the DHIS design principles contribute to improving data quality, such as the idea of harmonising data into one integrated data warehouse, supporting local level access to data and analysis tools, and by offering a wide range of tools for data analysis and dissemination. With more structured and harmonised data collection processes and with strengthened information use at all levels, the quality of data will improve. Here is an overview of the functionality more directly targeting data quality:

- Data input validation + Validación en la introducción de datos The most basic way of data quality check in DHIS 2 is to make sure that the data being captured is on the correct format. The DHIS 2 will give the users a message that the value entered is not on the correct format and will not save the value until it has been changed to an accepted value. E.g. text cannot be inputted in a numeric field. The different types of data values supported in DHIS 2 are explained in the user manual in the chapter on data elements.

- Min and max ranges + Rangos Máximo y Mínimo To stop typing mistakes during data entry (e.g typing ‘1000’ instead of ‘100’) the DHIS 2 checks that the value being entered is within a reasonable range. This range is based on the previously collected data by the same health facility for the same data element, and consists of a minimum and a maximum value. As soon as a the users enters a value outside the user will be alerted that the value is not accepted. In order to calculate the reasonable ranges the system needs at least six months (periods) of data.

- Validation rules + Reglas de validación A validation rule is based on an expression which defines a relationship between a number of data elements. The expression has a left side and a right side and an operator which defines whether the former must be less than, equal to or greater than the latter. The expression forms a condition which should assert that certain logical criteria are met. For instance, a validation rule could assert that the total number of vaccines given to infants is less than or equal to the total number of infants. The validation rules can be defined through the user interface and later be run to check the existing data. When running validation rules the user can specify the organisation units and periods to check data for, as running a check on all existing data will take a long time and might not be relevant either. When the checks are completed a report will be presented to the user with validation violations explaining which data values that need to be corrected. The validation rules checks are also built into the data entry process so that when the user has completed a form the rules can be run to check the data in that form only, before closing the form.

- Outlier analysis + Análisis de outliers The standard deviation based outlier analysis provides a mechanism for revealing values that are numerically distant from the rest of the data. Outliers can occur by chance, but they often indicate a measurement error or a heavy-tailed distribution (leading to very high numbers). In the former case one wishes to discard them while in the latter case one should be cautious in using tools or interpretations that assume a normal distribution. The analysis is based on the standard normal distribution.

- Completeness and timeliness reports + Reportes de integridad y de puntualidad Completeness reports will show how many data sets (forms) that have been submitted by organisation unit and period. You can use one of three different methods to calculate completeness; 1) based on completeness button in data entry, 2) based on a set of defined compulsory data elements, or 3) based on the total registered data values for a data set. The completeness reports will also show which organisation units in an area that are reporting on time, and the percentage of timely reporting facilities in a given area. The timeliness calculation is based on a system setting called Days after period end to qualify for timely data submission.

=== modified file 'src/docbkx/es/dhis2_implementation_guide_data_sets_and_forms.xml' --- src/docbkx/es/dhis2_implementation_guide_data_sets_and_forms.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_data_sets_and_forms.xml 2012-09-27 08:55:25 +0000 @@ -1,46 +1,46 @@ - Data Sets and Forms + Sets de datos y formularios This chapter discusses data sets and forms, what types of forms are available and describes best practises for the process of moving from paper based to electronic forms.

- What is a data set? + ¿Qué es un set de datos? All data entry in DHIS 2 is organised through the use of data sets. A data set 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). Data sets are not linked directly to the data values, only through their data elements and frequencies, and as such a data set 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. A data set has a period type which controls the data collection frequency, which can be daily, weekly, monthly, quarterly, six-monthly, or yearly. Both the data elements to include in the data set and the period type is defined by the user, together with a name, short name, and code. If calculated fields are needed in the collection form (and not only in the reports), then indicators can be assigned to the data set as well, but these can only be used in custom forms (see further down). In order to use a data set to collect data for a specific organisation unit the user must assign the organisation unit to the data set. This mechanism controls which organisation units that can use which data sets, and at the same time defines the target values for data completeness (e.g. how many health facilities in a district are expected to submit the RCH data set every month). A data element can belong to multiple data sets, but this requires careful thinking as it may lead to overlapping and inconstant data being collected if e.g. the data sets are given different frequencies and are used by the same organisation units.

- What is a data entry form? + ¿Qué es un formulario de entrada de datos? Once you have assigned a data set to an organisation unit that data set will be made available in Data Entry (under Services) for the organisation units you have assigned it to and for the valid periods according to the data set's period type. A default data entry form will then be shown, which is simply a list of the data elements belonging to the data set together with a column for inputting the values. If your data set 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.

- Types of data entry forms + Tipos de formularios de entrada de datos DHIS 2 currently features three differnet types of forms which are described in the following.

- Default forms + Formularios por defecto A default data entry form is simply a list of the data elements belonging to the data set together with a column for inputting the values. If your data set contains data elements with a non-default category combination, such as age groups or gender then additional columns will be automatically generated in the default form based on the different options/dimensions. If you use more than one category combination in a data set you will get one table per category combination in the default form, with different column headings for the options.

- Section forms + Formularios de Sección 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 categories do not apply to all data elements), both of these functions are supported in section forms. After defining a data set you can define it's sections with subsets of data elements, a heading and possible grey fields i the section's table. The order of sections in a data set 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 data set). Most tabular data entry forms should be possible to do with sections forms. Utilizing the section or default forms makes life easy as there is no need to maintain a fixed form design which includes references to data elements. 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.

- Custom Forms + Formularios personalizados 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 terms of the design. In DHIS 2 there is a built in HTML editor (CK Editor) in the form designer which allows you to either design the form in the GUI 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 option combination) 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 data set it will be available in data entry and used automatically. When using a custom form it is possible to use calculated fields to display e.g. running totals or other calculations based on the data captured in the form. This can e.g. be useful when dealing with stock or logistics forms that need item balance, items needed for next period etc. In order to do so, the user must first define the calculated expressions as indicators and then assign these indicators to the data set in question. In the custom form designer the user can then assign indicators to the form the same way data elements are assigned. The limitation to the calculated expression is that all the data elements use in the expression must be available in the same data set since the calculations are done on the fly inside the form, and are not based on data values already stored in the database.

- From paper to electronic form - Lessons learned + Lecciones aprendidas: de los formularios en papel a los formularios electrónicos When introducing an electronic health information system the system being replaced is often paper based reporting. The process of migrating to electronic data capture and analysis has some challenges. The following sections suggest best practises on how to overcome these.

- Identify self-contained data elements + Identificar elementos de datos autónomos Typically the design of a DHIS 2 data set is based on some requirements from a paper form that is already in use. The logic of paper forms are not the same as the data element and data set model of DHIS, e.g. often a field in a tabular paper form is described both by column headings and text on each row, and sometimes also with some introductory table heading that provides more context. In the database this is captured for one atomic data element with no reference to a position in a visual table format so it is important to make sure the data element with the optional data element categories capture the full meaning of each individual field in the paper form.

- Leave calculations and repetitions to the computer - capture raw data only + Dejar los cálculos y las repeticiones a la computadora: capturar solo datos en bruto Another important thing to have in mind while designing data sets is that the data set and the corresponding data entry form (which is a data set with layout) is a data collection tool and not a report or analysis tool. There are other far more sophisticated tools for data output and reporting in DHIS 2 than the data entry forms. Paper forms are often designed with both data collection and reporting in mind and therefore you might see things such as cumulative values (in addition to the monthly values), repetition of annual data (the same population data reported every month) or even indicator values such as coverage rates in the same form as the monthly raw data. When you store the raw data in the DHIS 2 database every month and have all the processing power you need within the computerised tool, there is no need (in fact it would be wrong and most likely cause inconsistency) to register manually calculated values such as the ones mentioned above. You only want to capture the raw data in your data sets/forms and leave the calculations to the computer, and presentation of such values to the reporting tools in DHIS. Through the functionality of data set reports all tabular section forms will automatically get extra columns at the far right providing subtotal and total values for each row (data element).

=== modified file 'src/docbkx/es/dhis2_implementation_guide_data_warehouse.xml' --- src/docbkx/es/dhis2_implementation_guide_data_warehouse.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_data_warehouse.xml 2012-09-27 08:55:25 +0000 @@ -1,10 +1,10 @@ - DHIS 2 as Data Warehouse + DHIS 2 es un Data Warehouse 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.

- Data warehouses and operational systems + Data warehouse frente a sistemas funcionales A data warehouse 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 data mining and online analytical processing. 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. A transactional system (or operational system 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. @@ -46,12 +46,12 @@

- Aggregation strategy in DHIS 2 + Estrategia de agregación en DHIS 2 The analysis tools in DHIS 2 reads aggregated data from data mart 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 space dimension (the organisation unit hierarchy), time dimension (over multiple periods) and for indicator formulas (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 near real-time access to aggregate data. 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.

- Data storage approach + Enfoque del almacenamiento de datos There are two leading approaches for storing data in a data warehouse, namely the normalized and dimensional approach. DHIS 2 lends a bit from the former but mostly from the latter. In the dimensional approach the data is partitioned into dimensions and facts. 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. 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 compulsory dimensions which give meaning to the facts are the data element, organisation unit hierarchy and period 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. === modified file 'src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml' --- src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml 2012-09-27 08:55:25 +0000 @@ -1,10 +1,10 @@ - Deployment Strategies + Estrategias de despliegue DHIS 2 is a network enabled application and can be accessed over the Internet, a local intranet and as a locally installed system. The deployment alternatives for DHIS 2 are in this chapter defined as i) offline deployment ii) online deployment and iii) hybrid deployment. The meaning and differences will be discussed in the following sections.

- Offline Deployment + Despliegue Desconectado (Offline) An offline deployment implies that multiple standalone offline instances are installed for end users, typically at the district level. The system is maintained primarily by the end users/district health officers who enters data and generate reports from the system running on their local server. The system will also typically be maintained by a national super-user team who pay regular visits to the district deployments. Data is moved upwards in the hierarchy by the end users producing data exchange files which are sent electronically by email or physically by mail or personal travel. (Note that the brief Internet connectivity required for sending emails does not qualify for being defined as online). This style of deployment has the obvious benefit that it works when appropriate Internet connectivity is not available. On the other side there are significant challenges with this style which are described in the following section. @@ -22,7 +22,7 @@

- Online deployment + Despliegue Conectado (Online) 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 dongles). This online deployment style has huge positive implications for the implementation process and application maintenance compared to the traditional offline standalone style: @@ -42,13 +42,13 @@ 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.

- Hybrid deployment + Despliegue Híbrido 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. 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. 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.

- Server hosting + Alojamiento de servidor 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: === modified file 'src/docbkx/es/dhis2_implementation_guide_enduser_training.xml' --- src/docbkx/es/dhis2_implementation_guide_enduser_training.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_enduser_training.xml 2012-09-27 08:55:25 +0000 @@ -1,7 +1,7 @@ - End-user Training + Capacitación de usuarios The following topics will be covered in this chapter: @@ -15,7 +15,7 @@

- What training is needed + Qué capacitación se necesita 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: @@ -32,25 +32,25 @@ 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.

- Strategies for training + Estrategias de capacitación 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.

- Training of trainers + Formación de formadores 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. 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.

- Workshops and on-site training + Workshops y formación in-situ 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. 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.

- Continuation of training + Formación continua 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.

- Material and courses + Materiales y cursos 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 here. 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. === modified file 'src/docbkx/es/dhis2_implementation_guide_indicators.xml' --- src/docbkx/es/dhis2_implementation_guide_indicators.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_indicators.xml 2012-09-27 08:55:25 +0000 @@ -1,7 +1,7 @@ - Indicators + Indicadores This chapter covers the following topics: @@ -19,7 +19,7 @@ The following describes these topics in greater detail.

- What is an indicator + Qué es un indicador In DHIS 2 the indicator is a core element of data analysis. An indicator represent calculated formula based on data elements, i.e it is not just a figure, but a proportion relating to something. It has a numerator which represents the data elements being measured, and a denominator which the data element(s) is is measured as a proportion of). Indicators are thus made up of formulas of these data elements, in addition to a factor (e.g. 1, 100, 100, 100 000) to set the right measurement. E.g. the indicator "BCG coverage <1 year" is defined a formula with a factor 100 (to get it as a per cent), 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"). Indicator = numerator / denominator x factor @@ -85,17 +85,17 @@

- Purposes of indicators + El propósito de los indicadores Indicators are a lot more useful for analysis than raw data. Since they are proportions, they are comparable across time and space, which is very important since units of analysis and comparison, such as districts, vary in size and change over time. A district with 100 cases of a disease may have a higher incidence rate than a district of 1000 cases, if the latter district is more than 10 times as populous. An indicator measuring the incidence rate related to a population will be possible for comparison no matter what the population might actually be. Indicators thus allow comparison, and are the prime tool for data analysis. DHIS2 should provide relevant indicators for analysis for all health programs, not just the raw data. Most report modules in DHIS 2 support both data elements and indicators and you can also combine these in custom reports.

- Indicator-driven data collection + Recolección de datos por indicadores Since indicators are more suited for analysis compared to data elements, the calculation of indicators should be the main driving force for collection of data. A usual situation is that much data is collected but never used in any indicator, which significantly reduces the usability of the data. Either the captured data elements should be included in indicators used for management or they should probably not be collected at all. For implementation purposes, a list of indicators used for management should be defined and implemented in DHIS 2. For analysis, training should focus on the use of indicators and why these are better suited than data elements for this purpose.

- Managing indicators + Gestión de indicadores Indicators can be added, deleted, or modified at any time in DHIS2 without affecting the data. Indicators are not stored as values in DHIS2, but as formlas, which are calculated whenever the user needs them. Thus a change in the formulas will only lead to different data elements being called for when using the indicator for analysis, without any changes to the underlying data values taking place. For information how to manage indicators, please refer to the chapter on indicators in the DHIS2 user documentation.

=== modified file 'src/docbkx/es/dhis2_implementation_guide_installation.xml' --- src/docbkx/es/dhis2_implementation_guide_installation.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_installation.xml 2012-09-27 08:55:25 +0000 @@ -1,7 +1,7 @@ - Installation + Instalación The installation chapter provides information on how to install DHIS 2 in various contexts, including online central server, offline local network, standalone application and self-contained package called DHIS 2 Live. DHIS 2 runs on all platforms for which there exists a Java Runtime Environment version 6 or higher, which includes most popular operating systems such as Windows, Linux and Mac. DHIS 2 also runs on many relational database systems such as PostgreSQL, MySQL, H2 and Derby. DHIS 2 is packaged as a standard Java Web Archive (WAR-file) and thus runs on any Servlet containers such as Tomcat and Jetty. The DHIS 2 team recommends Ubuntu 12.04 LTS operating system, PostgreSQL database system and @@ -10,7 +10,7 @@ over many years. This chapter provides a guide for setting up the above technology stack. It should however be read as a guide for getting up and running and not as an exhaustive documentation for the mentioned environment. We refer to the official Ubuntu, PostgreSQL and Tomcat documentation for in-depth reading.

- Server setup + Montaje del sevidor This section describes how to set up a server instance of DHIS 2 on Ubuntu 12.04 64 bit with PostgreSQL as database system and Tomcat as Servlet container. The term invoke refers to executing a given command in a terminal. For a national server the recommended configuration is a quad-core 2 Ghz processor or @@ -98,7 +98,7 @@

- Basic setup for nginx + Instalación básica de nginx We recommend using nginx (http://wiki.nginx.org) as reverse proxy due to its low memory footprint and ease of use. To get the latest version we recommend installing from source: sudo apt-get install make gcc libpcre3 libpcre3-dev zlibc zlib1g zlib1g-dev libssl-dev openssl wget http://nginx.org/download/nginx-1.0.14.tar.gz @@ -143,7 +143,7 @@

- Enabling SSL on nginx + Habilitando SSL en nginx In order to improve security it is recommended to configure the server running DHIS to communicate with clients over an encrypted connection and to identify itself to clients using a trusted certificate. This can be achieved through SSL which is an cryptographic communication protocol running on top of TCP/IP. To configure nginx to use SSL you will need a proper SSL certificate from an SSL provider. The cost of a certificate varies a lot depending on encryption strength. An affordable certificate from Rapid SSL Online should serve most purposes. To generate the CSR (certificate signing request) you can invoke the command below. When you are prompted for the Common Name, enter the fully qualified domain name for the site you are securing. openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr @@ -189,7 +189,7 @@ }]]>

- Control scripts for nginx + Scripts de control para nginx In certain situations a server might reboot unexpectedly. It is hence preferable to have Tomcat and nginx start automatically when the server starts. To achieve that the first step is to create init scripts. Create a new file called tomcat and paste the below content into it (adjust the HOME variable to your environment): #!/bin/sh #Tomcat init script @@ -239,7 +239,7 @@ Tomcat and nginx will now be started at system startup and stopped at system shutdown. If you later need to revert this you can replace defaults with remove and invoke the above commands again.

- Making resources available with nginx + Poner recursos disponibles con nginx Making resources publicly available In some scenarios it is desirable to make certain resources publicly available on the Web without requiring authentication. One example is when you want to make data analysis related resources in the Web API available in a Web portal. The following example will allow access to charts, maps, reports, report table and document resources through basic authentication by injecting an Authorization HTTP header into the request. It will remove the Cookie header from the request and the Set-Cookie header from the response in order to avoid changing the currently logged in user. It is recommended to create a user for this purpose given only the minimum authorities required. The Authorization value can be constructed by Base64-encoding the username appended with a colon and the password and prefix it "Basic ", more precisely "Basic base64_encode(username:password)". It will check the HTTP method used for requests and return 405 Method Not Allowed if anything but GET is detected. location ~ ^/api/(charts|maps|reports|reportTables|documents)/ { === modified file 'src/docbkx/es/dhis2_implementation_guide_integration.xml' --- src/docbkx/es/dhis2_implementation_guide_integration.xml 2012-09-18 17:33:07 +0000 +++ src/docbkx/es/dhis2_implementation_guide_integration.xml 2012-09-27 08:55:25 +0000 @@ -2,7 +2,7 @@ - Integration + Integración This chapter will discuss the following topics: @@ -20,7 +20,7 @@ In the following each topic will be discussed in greater detail.

- Integration and interoperability + Integración e interoperabilidad 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: @@ -33,7 +33,7 @@ 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).

- Benefits of integration + Beneficios de la integración There are several potential benefits related to integration of systems. The most important are:i @@ -48,7 +48,7 @@

- What facilitates integration and interoperability + Qué facilita la integración y la interoperabilidad There are three levels that need to be addressed in this regard: @@ -66,7 +66,7 @@ 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)

- Architecture of interoperable HIS + Arquitectura de SIS interoperables 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. 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. 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. === 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-09-26 10:12:58 +0000 +++ src/docbkx/es/dhis2_implementation_guide_setting_up_new_database.xml 2012-09-27 08:55:25 +0000 @@ -5,75 +5,75 @@ Instalación de una nueva base de datos La aplicación DHIS 2 viene con un set de herramientas para la recogida de datos, validación, reporte y análisis, pero los contenidos de la base de datos, como son qué datos registrar, de dónde vienen los datos, y en qué formato, dependen del contexto en que usemos la aplicación. Tendremos que insertar estos metadatos en la aplicación antes de poder usarlos, y esto es posible hacerlo mediante el interfaz de usuario sin necesidad de programación. Lo que sí se necesita es conocer en profundidad el contexto local del SIS así como comprender los principios de diseño de DHIS 2 (véase el capítulo "Principios conceptuales de diseño en DHIS 2"). Esto es lo que llamamos proceso inicial para el diseño y personalización de la base de datos. Este capítulo da una perspectiva general del proceso de personalización y explica brevemente los pasos requeridos, con el objetivo de ofrecer a los implementadores una visión de lo que requiere este proceso. Otros capítulos de este manual entran con mayor detalle en algunos de estos pasos concretos.

- Estrategias para comenzar + Estrategias para empezar La sección siguiente describe una lista de consejos para arrancar con buen pie en el desarrollo de una nueva base de datos. - Insertar rápidamente una base de datos demostrativa, que incluya ejemplos de reportes, gráficas, dashboard, SIG, formularios de entrada de datos. Utilizar datos reales, idealmente a nivel nacional, pero no necesariamente datos a nivel de establecimientos de salud. - - - Put the demo database online. Server hosting with an external provider server can be a solution too speed up the process, even if temporary. This makes a great collaborative platform and dissemination tool to get buy-in from stakeholders. - - - The next phase is a more elaborate database design process. Parts of the demo can be reused of viable. - - - Make sure to have a local team with different skills and background: public health, data administrator, IT and project management. - - - Use the customisation and database design phase as a learning and training process to build local capacity through learning-by-doing. - - - The country national team should drive the database design process but be supported and guided by experienced implementers. + Montar cuanto antes una base de datos demostrativa, que incluya ejemplos de reportes, gráficas, dashboard, SIG, formularios de entrada de datos. Utilizar datos reales, idealmente a nivel nacional, pero no necesariamente datos a nivel de establecimientos de salud. + + + Poner la base de datos demostrativa accesible desde Internet. Una manera de acelerar este proceso puede ser alojarla en un servidor web con un proveedor de servicios externo, incluso si es solo temporal. Esto crea una buena plataforma colaborativa y una herramienta estupenda de difusión para lograr la aprobación y participación de los diferentes actores relevantes para el SIS. + + + Realizar a continuación un proceso de diseño de la base de datos más elaborado. Si es posible, algunas partes de la demo pueden reutilizarse. + + + Asegurarse de que contamos con un equipo local multidisciplinar, con capacidades y formación diversas: salud pública, administración de sistemas, gestión de TIC y gestión de proyectos. + + + Utilizar la fase de personalización y diseño de la base de datos como un proceso de aprendizaje y de formación para cultivar capacidades locales mediante "aprender haciendo". + + + El equipo nacional de implementación deberá liderar el proceso de diseño de la base de datos pero siempre apoyado y guiado por implementadores más experimentados.

- Controlled or open process? - As the DHIS 2 customisation process often is and should be a collaborative process, it is also important to have in mind which parts of the database that are more critical than others, e.g. to avoid an untrained user to corrupt the data. Typically it is a lot more critical to customise a database which already has data values, than working with meta data on an “empty” database. Although it might seem strange, much customisation takes place after the first data collection or import has started, e.g. when adding new validation rules, indicators or report layouts. - -The most critical mistake that can be made is to modify the meta data that directly describes the data values, and these as we have seen above, are the data elements and the organisation units. When modifying these definitions it is important to think about how the change will affect the meaning of the data values already in the system (collected using the old definitions). It is recommended to limit who can edit these core meta data through the user role management, to restrict the access to a core customisation team. - Other parts of the system that are not directly coupled to the data values are a lot less critical to play around with, and here, at least in the early phases, one should encourage the users to try out new things in order to create learning. This goes for groups, validation rules, indicator formulas, charts, and reports. All these can easily be deleted or modified later without affecting the underlying data values, and therefore are not critical elements in the customisation process. - Of course, later in the customisation process when going into a production phase, one should be even more careful in allowing access to edit the various meta data, as any change, also to the less critical meta data, might affect how data is aggregated together or presented in a report (although the underlying raw data is still safe and correct). + ¿Un proceso controlado o un proceso abierto? + Dado que el proceso de personalización de DHIS 2 suele ser y debe ser un proceso colaborativo, es importante tener en mente qué partes de la base de datos son más críticas que otras, por ejemplo para evitar que usuarios no capacitados corrompan los datos. Normalmente es mucho más crítico personalizar una base de datos que ya tiene valores de datos, que trabajar con metadatos en una base de datos "vacía". Aunque parezca extraño, mucha de la personalización tiene lugar después del primer registro de datos o de la primera importación. Es entonces cuando por ejemplo se añaden nuevas reglas de validación, indicadores y capas de reporte. + El error más crítico que se puede cometer aquí es modificar los metadatos que describen directamente los valores de datos, que como hemos visto anteriormente, son los elementos de datos y las unidades organizativas. Cuando modificamos estas definiciones es importante pensar en cómo afectarán los cambios al significado de los valores de datos que ya estaban en el sistema (recogidos utilizando las definiciones anteriores). Es recomendable limitar quién puede editar estos metadatos fundamentales, mediante la gestión de roles de usuario, para restringir el acceso al equipo experto de personalización. + Otras partes del sistema que no están directamente acopladas a los valores de datos son mucho menos críticas y podemos experimentar con ellas. Es más, en las fases incipientes de implementación, deberíamos animar a los usuarios a probar cosas nuevas y así provocar el aprendizaje. Esta premisa es válida para los grupos, las reglas de validación, las fórmulas de indicadores, las gráficas y los reportes. Todos ellos pueden borrarse o modificarse posteriormente con facilidad sin afectar a los valores de datos, de modo que no son partes críticas del proceso de personalización. + Por supuesto, cuando posteriormente llevamos el proceso de personalización a fase de producción, deberemos ser todavía más cautos al permitir acceso a la edición de metadatos, ya que cualquier cambio, incluso en los menos críticos, puede afectar a cómo se agregan o se presentan los datos en reportes (aunque los datos en bruto por debajo estén correctos y a salvo). + .

- Steps for developing a database - The following section describes concrete steps for developing a database from scratch. + Pasos para desarrollar una base de datos + Esta sección describe los pasos concretos para desarrollar una base de datos partiendo de cero.

- The organisational hierarchy - 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). + Jerarquía organizativa + La jerarquía organizativa define la organización en DHIS 2: los establecimientos de salud, las áreas administrativas y otras áreas geográficas utilizadas en la recolección y el análisis de datos. Esta dimensión de los datos se define como una jerarquía con una unidad raíz (ej. Ministerio de Salud) y diversos niveles y nodos debajo. Cada nodo en esta jerarquía es lo que en DHIS 2 llamamos unidad organizativa. El diseño de esta jerarquía determinará las unidades geográficas de análisis disponibles a los usuarios al momento en que los datos son registrados y agregados en esta estructura. Solo puede haber una jerarquía organizativa en el sistema, de modo que deberemos considerar cuidadosamente cómo estructurarla. + Es posible modelar jerarquías adicionales (tales como límites administrativos paralelos al Sector Salud) utilizando grupos organizativos y sets de grupo, pero la jerarquía organizativa es el vehículo principal para la agregación de datos en una dimensión geográfica. Normalmente las jerarquías organizativas nacionales en Salud Pública tienen entre 4 y 6 niveles, pero DHIS soporta cualquier cantidad de niveles. La jerarquía se construye con relaciones padre-hijo, por ejemplo: una unidad País o Ministerio de Salud (la raíz) puede tener 8 unidades hijo (provincias), y cada provincia (en nivel 2) puede tener a su vez 10 ó 15 distritos como nodos hijo. Generalmente los establecimientos de salud estarán colocados en el nivel más bajo, pero también podemos colocarlos en niveles más altos como sucederá con los hospitales provinciales o nacionales, de modo que es posible tener árboles organizativos asimétricos (ej. un nodo hoja puede estar colocado en el nivel 2 mientras la mayoría de nodos hoja se encuentran en el nivel 5).

- Data Elements + Elementos de datos 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 data element. 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. A 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.

- Data sets and data entry forms + Sets de datos y formularios de entrada de datos All data entry in DHIS 2 is organised through the use of data sets. A data set 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). Data sets are not linked directly to the data values, only through their data elements and frequencies, and as such a data set 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. Once you have assigned a data set to an organisation unit that data set will be made available in Data Entry (under Services) for the organisation units you have assigned it to and for the valid periods according to the data set's period type. A default data entry form will then be shown, which is simply a list of the data elements belonging to the data set together with a column for inputting the values. If your data set 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. 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. 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.

- Validation rules + Reglas de validación 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 occurred to make it easy to go back to data entry and correct the values.

- Indicators + Indicadores 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"). 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. Indicators can be added, modified and deleted at any point in time without interfering with the data values in the database.

- Report tables and reports + Tablas de reporte e informes 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.

- GIS (Maps) + SIG (Mapas) 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.

- Charts and dashboard + Gráficos y dashboard 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.