Organisation Units

- Organisation unit hierarchy design - The process of designing a sensible organisation unit hierarchy has many aspects: - - - Include all reporting health facilities: All health facilities which contribute to the national data collection should be included in the system. Facilities of all kinds of ownership should be incorporated, including private, public, NGO and faith-oriented facilities. Often private facilities constitute half of the total number of facilities in a country and have policies for data reporting imposed on them, which means that incorporating data from such facilities are necessary to get realistic, national aggregate figures. - - - Emphasize the health administrative hierarchy: A country typically has multiple administrative hierarchies which are often not well coordinated nor harmonized. When considering what to emphasize when designing the DHIS 2 database one should keep in mind what areas are most interesting and will be most frequently requested for data analysis. DHIS 2 is primarily managing health data and performing analysis based on the health administrative structure. This implies that even if adjustments might be made to cater for areas such as finance and local government, the point of departure for the DHIS 2 organisation unit hierarchy should be the health administrative areas. - - - - - Limit the number of organisation unit hierarchy levels: To cater for analysis requirements coming from various organisational bodies such as local government and the treasury, it is tempting to include all of these areas as organisation units in the DHIS 2 database. However, due to performance considerations one should try to limit the organisation unit hierarchy levels to the smallest possible number. The hierarchy is used as the basis for aggregation of data to be presented in any of the reporting tools, so when producing aggregate data for the higher levels, the DHIS 2 application must search for and add together data registered for all organisation units located further down the hierarchy. Increasing the number of organisation units will hence negatively impact the performance of the application and an excessively large number might become a significant problem in that regard. - In addition, a central part in most of the analysis tools in DHIS 2 is based around dynamically selecting the “parent” organisation unit of those which are intended to be included. For instance, one would want to select a province and have the districts belonging to that province included in the report. If the district level is the most interesting level from an analysis point of view and several hierarchy levels exist between this and the province level, this kind of report will be rendered unusable. When building up the hierarchy, one should focus on the levels that will be used frequently in reports and data analysis and leave out levels that are rarely or never used as this will have an impact on both the performance and usability of the application. - - - Avoid one-to-one relationships: Another guiding principle for designing the hierarchy is to avoid connecting levels that have near one-to-one parent-child ratios, meaning that for instance a district (parent) should have on average more than one local council (child) at the level below before it make sense to add a local council level to the hierarchy. Parent-child ratios from 1:4 or more are much more useful for data analysis purposes as one can start to look at e.g. how a district’s data is distributed in the different sub-areas and how these vary. Such drill-down exercises are not very useful when the level below has the same target population and the same serving health facilities as the parent. - Skipping geographical levels when mapping the reality to the DHIS 2 organisation unit hierarchy can be difficult and can easily lead to resistance among certain stakeholders, but one should have in mind that there are actually ways of producing reports based on geographical levels that are not part of the organisational hierarchy in DHIS 2, as will be explained in the next section. + Diseño de la jerarquía de unidades organizativas + El proceso de diseñar una jerarquía de unidades organizativas con sensatez debería tomar en cuenta varios aspectos: + + + Incluir todos los establecimientos que reportan datos de salud: Todos los establecimientos de salud que contribuyen a la recolección de datos nacionales deberían incluirse en el sistema. Los establecimientos de todo tipo deberían incorporarse, incluyendo los privados, públicos, ONG y religiosos. A menudo los establecimientos privados constituyen un porcentaje no despreciable del total de establecimientos en un país y siguen políticas de reporte de datos impuestas, lo que significa que incorporar datos de esos establecimientos es necesario para hacernos una imagen agregada realista a nivel nacional. + + + Enfatizar la jerarquía administrativa en salud Generalmente un país tiene múltiples jerarquías administrativas que muchas veces no están bien coordinadas o armonizadas. Cuando consideramos qué enfatizar al diseñar la base de datos de DHIS 2 debemos tener en mente qué áreas son las más interesantes y serán más solicitadas para el análisis de datos. DHIS gestiona primordialmente datos de salud y realiza análisis basándose en la estructura administrativa de salud. Esto impica que incluso si hubiera que hacer ajustes para satisfacer áreas financieras o del gobierno local, el punto de partida de la jerarquía de unidades organizativas de DHIS serían las áreas administrativas en salud. + + + Limitar el número de niveles en la jerarquía de unidades organizativas: Para satisfacer los requisitos de análisis provinientes de diversos cuerpos organizativos como el gobierno local y el tesoro, es tentador inluir todas estas áreas como unidades organizativas en la base de datos de DHIS 2. Sin embargo, por consideraciones de rendimiento uno debería intentar limitar los niveles de la jerarquía de unidades organizativas al menor número posible. La jerarquía se utiliza como base para la agregación de datos que se presentan en cualquiera de las herramientas de reporte, así que cuando se producen datos agregados para niveles más altos, la aplicación DHIS 2 debe buscar y juntar datos registrados para todas las unidades organizativas ubicadas más abajo en la jerarquía. Entonces, aumentar el número de unidades organizativas repercutirá negativamente en el rendimento de la aplicación y un número excesivamente grande puede convertirse en un problema importante. + Además, una parte central en la mayoría de herramientas de análisis en DHIS 2 se basa en seleccionar dinámicamente la unidad "padre" de aquellas que se quieren incluir en el análisis. Por ejemplo, si queremos seleccionar una provincia e incluir los distritos de esa provincia en el reporte. Si el nivel de distrito es el nivel más interesante desde el punto de vista del análisis y existen muchos niveles jerárquicos entre este y el nivel provincial, este tipo de reporte se renderizará inútilmente. Cuando construimos la jerarquía, deberíamos fijarnos en los niveles que se utilizarán frecuentemente en reportes y en análisis de datos y dejar fuera los niveles que raramente o nunca se usan ya que esto tiene un impacto tanto en el rendimiento como en la usabilidad de la aplicación. + + + Evitar relaciones uno-a-uno: Otro principio referente para diseñar la jerarquía es evitar conectar niveles que tienen ratios padre-hijo cercanos al uno-a-uno, lo que quiere decir que por ejemplo un distrito (padre) debería tener de media más de una municipalidad (hijo) en el nivel inferior para que tenga sentido añadir esta municipalidad a la jerarquía. Los ratios padre-hijo de 1:4 o más son mucho más útiles para el propósito de análisis de datos ya que nos permite mirar por ejemplo, cómo los datos de un distrito se distribuyen en las diferentes subáreas y cómo varían. Estos ejercicios de recorrido vertical son poco útiles cuando el nivel inferior tiene la misma población objetivo y los mismos establecimientos prestadores de servicios que la unidad padre. + A la hora de mapear la realidad en la jerarquía de unidades organizativas de DHIS 2 puede ser difícil saltar niveles geográficos y puede conllevar resistencias entre ciertos actores, pero deberemos tener en mente que en realidad hay formas de producir reportes basados en niveles geográficos que no son parte de la jerarquía organizativa en DHIS 2, como se explica en la sección siguiente.

- Organisation unit groups and group sets - In DHIS 2, organisation units can be grouped in organisation unit groups, and these groups can be further organised into group sets. Together they can mimic an alternative organisational hierarchy which can be used when creating reports and other data output. In addition to representing alternative geographical locations not part of the main hierarchy, these groups are useful for assigning classification schemes to health facilities, e.g. based on the type or ownership of the facilities. Any number of group sets and groups can be defined in the application through the user interface, and all these are defined locally for each DHIS 2 database. - An example illustrates this best: Typically one would want to provide analysis based on the ownership of the facilities. In that case one would create a group for each ownership type, for instance “MoH”, “Private” and “NGO”. All facilities in the database must then be classified and assigned to one and only one of these three groups. Next one would create a group set called “Ownership” to which the three groups above are assigned, as illustrated in the figure below. + Grupos de unidades organizativas y sets de grupos + En DHIS 2, las unidades organizativas pueden agruparse en grupos de unidades organizativas, y estos grupos pueden a su vez asociarse en sets de grupos. Juntos pueden emular una jerarquía organizativa alternativa que puede usarse a la hora de crear reportes y otras salidas de datos. Además de representar ubicaciones geográficas alternativas que no están en la jerarquía principal, estos grupos son útiles para asignar esquemas de clasificación a los establecimientos de salud, por ejemplo basados en el tipo o propietario de los establecimientos. Se pueden definir tantos grupos y sets de grupos como deseemos en la aplicación a través del interfaz de usuario, y todos ellos se definen localmente para cada base de datos DHIS 2. + Este ejemplo lo ilustra mejor: generalmente queremos proveer análisis en base a la propiedad de los establecimientos (público, privado, etc). En ese caso podemos crear un grupo para cada tipo de propiedad, por ejemplo "Ministerio de Salud", "Privado" y "ONG". Todos los establecimientos en la base de datos deben clasificarse y ser asignados a uno y solo uno de estos grupos. A continuación crearíamos un set de grupos llamado "Propiedad" al que se asignan los tres grupos anteriores, como se ilustra en esta figura. - In a similar way one can create a group set for an additional administrative level, e.g. local councils. All local councils must be defined as organisation unit groups and then assigned to a group set called “Local Council”. The final step is then to assign all health facilities to one and only one of the local council groups. This enables the DHIS 2 to produce aggregate reports by each local council (adding together data for all assigned health facilities) without having to include the local council level in the main organisational hierarchy. The same approach can be followed for any additional administrative or geographical level that is needed, with one group set per additional level. Before going ahead and designing this in DHIS 2, a mapping between the areas of the additional geographical level and the health facilities in each area is needed. - A key property of the group set concept in DHIS 2 to understand is exclusivity, which implies that an organisation unit can be member of exactly one of the groups in a group set. A violation of this rule would lead to duplication of data when aggregating health facility data by the different groups, as a facility assigned to two groups in the same group set would be counted twice. - With this structure in place, DHIS 2 can provide aggregated data for each of the organisation unit ownership types through the “Organisation unit group set report” in “Reporting” module or through the Excel pivot table third-party tool. For instance one can view and compare utilisation rates aggregated by the different types of ownership (e.g. MoH, Private, NGO). In addition, DHIS 2 can provide statistics of the distribution of facilities in “Organisation unit distribution report” in “Reporting” module. For instance one can view how many facilities exist under any given organisation unit in the hierarchy for each of the various ownership types. In the GIS module, given that health facility coordinates have been registered in the system, one can view the locations of the different types of health facilities (with different symbols for each type), and also combine this information with a other map layer showing indicators e.g. by district. + De forma similar podemos crear un set de grupos para un nivel administrativo adicional, por ejemplo municipios. Todos los municipios han de definirse como grupos de unidades organizativas y asignarlos a un set de grupos llamdo "Municipios". El paso final sería asignar todos los establecimientos a uno y solo uno de los grupos de municipio. Esto permite a DHIS 2 producir reportes agregados por cada municipio (añadiendo conjuntamente datos de todos los establecimientos incluidos) sin tener que incluir el nivel de municipio en la jerarquía organizativa principal. El mismo camino puede seguirse para cualquier nivel administrativo o geográfico adicional que sea necesario, con un set de grupo por nivel adicional. Antes de continuar y diseñar esto en DHIS 2, es importante mapear las áreas de niveles geográficos adicionales y los establecimientos por cada área. + Una cualidad esencial del concepto de set de grupos en DHIS 2 que debemos comprender es la exclusividad, que implica que una unidad organizativa puede ser miembro de solo uno de los grupos en un set de grupos. Infringir esta norma podría conllevar la duplicación de datos al agregar datos de establecimientos de salud por parte de distintos grupos, ya que un establecimiento que es asignado a dos grupos en el mismo set de grupos sería contabilizado dos veces. + Con esta estructura presente, DHIS 2 puede proporcionar datos agregados para cada tipo de propiedad de unidad organizativa mediante el "Reporte de set de grupos de unidades organizativas" en el módulo de "Reporte" o mediante la herramienta de terceros de las tablas dinámicas Excel. Por ejemplo podremos ver y comparar tasas de uso agregadas por los diferentes tipos de propiedad (ej. Ministerio, Privado, ONG). además, DHIS 2 puede sacar estadísticas de distribución de los establecimientos en el "Reporte de set de grupos de unidades organizativas" del módulo de "Reporte". Por ejempo, podemos ver cuántos establecimientos hay bajo una determinada unidad organizativa de la jerarquía para cada tipo de propiedad. En el módulo SIG, dado que las coordenadas de los establecimientos de salud se han registrado en el sistema, podremos ver las ubicaciones de los diferentes tipos de establecimientos de salud (con símbolos distintos según su tipo), y también combinar esta información con otra capa de mapa que muestre indicadores, por ejemplo, por distrito.

- Home page: dhis2.org - The DHIS 2 home page is found at http://dhis2.orgThe download page provides downloads for the DHIS 2 Live package, WAR files, the mobile client, a Debian package, the source code, sample databases and a tool for editing the application user interface translations. Please note that the current latest release will be maintained until the next is released and both the actual release and the latest build from the release branch are provided. We recommend that you check back regularly on the download page and update your online server with the latest build from the release branch. The build revision can be found under Help - About inside DHIS 2. - The documentation page provides installation instructions, user documentation, this implementation guide, presentations, Javadocs, changelog, roadmap and a guide for contributing to the documentation. The user documentation is focused on the practical aspects of using DHIS 2, such as how to create data elements and reports. This implementation guide is addressing the more high-level aspects of DHIS 2 implementation, database development and maintenance. The change log and roadmap sections provide links to the relevant pages in the Launchpad site described later. - The functionality and features pages give a brief overview with screenshots of the main functionalities and features of DHIS 2. A demo DHIS 2 application can be reached from the demo top menu link. These pages can be used when a quick introduction to the system must be given to various stakeholders. - The about page has information about the license under which DHIS 2 is released, how to sign up for the mailing lists, get access to the source code and more. + Página principal: dhis2.org + La página principal de DHIS 2 se encuentra en http://dhis2.org La página de descargas contiene descargas del paquete DHIS 2 Live, ficheros WAR, el cliente móvil, un paquete Debian, el código fuente, bases de datos de ejemplo y una herramienta de edición de las traducciones del interfaz de usuario de la aplicación. Notemos que la última versión se mantiene hasta que la aparece la siguiente y están disponibles tanto la versión actual más reciente como la última generación del branch. Recomendamos comprobar regularmente la página de descargas y actualizar el servidor online con la última versión del branch. La revisión de versiones se puede encontrar también en Ayuda - Acerca de en DHIS 2. + La página de documentación contiene instrucciones para la instalación, documentación de usuario, esta guía de implementación, presentaciones, Javadocs, registro de cambios, roadmap y una guía sobre cómo contribuir en la documentación. La documentación de usuario está enfocada a aspectos prácticos del uso de DHIS 2, como cómo crear elementos de datos y reportes. Esta guía de implementación cubre los aspectos de más alto nivel de la implementación, desarrollo de la base de datos y mantenimiento de DHIS 2. El registro de cambios y la sección de roadmap contienen enlaces a las páginas respectivas en el sitio de Launchpad que se describe más adelante. + Las páginas de funcionalidad y características dan una visión escueta con capturas de pantalla de las principales funciones y características de DHIS 2. Se puede también acceder a una demo de DHIS 2 en el menú demo. Estas páginas pueden utilizarse cuando queremos dar una rápida introducción al sistema a los diversos actores del proyecto. + La página Acerca de contiene información sobre la licencia de publicación de DHIS 2, sobre cómo inscribirse a las listas de correo y tener acceso al código fuente y más.

- Collaboration platform: launchpad.net/dhis2 - DHIS 2 uses Launchpad as the main collaboration platform. The site can be accessed at http://lanchpad.net/dhis2 Launchpad is used for source code hosting, functionality specifications, bug tracking and notifications. The Bazaar version control system is tightly integrated with Launchpad and is required for checking out the source code. - The various source code branches including trunk and release branches can be browsed at http://code.launchpad.net/dhis2 - If you want to suggest new functionality to be implemented in DHIS 2 you can air your views on the developer mailing list and eventually write a specification, which is referred to as blueprints in Launchpad. The bueprint will be considered by the core development team and if accepted be assigned a developer, approver and release version. Blueprints can be browsed and added at http://blueprints.launchpad.net/dhis2 - If you find a bug in DHIS 2 you can report it at Launchpad by navigating to http://bugs.launchpad.net/dhis2 Your bug report will be investigated by the developer team and be given a status. If valid it will also be assigned to a developer and approver and eventually be fixed. Note that bugfixes are incorporated into the trunk and latest release branch - so more testing and feedback to the developer teams leads to higher quality of your software. + Plataforma colaborativa: launchpad.net/dhis2 + DHIS 2 utiliza Launchpad como la principal plataforma colaborativa. Se accede al sitio en http://lanchpad.net/dhis2 Launchpad se utiliza para alojar el código fuente, las especificaciones técnicas, el seguimiento de bugs y notificaciones. El sistema de control de versiones Bazaar está estrechamente integrado con Launchpad y se requiere para verificar y actualizar el código fuente. + Los diversos branch de código fuente incluido trunk y release se pueden encontrar via web en http://code.launchpad.net/dhis2 + si queremos sugerir que sean implementadas nuevas funcionalidades en DHIs 2 podemos compartir nuestras propuestas en la lista de correo de desarrolladores e incluso escribir una especificación, que se denomina blueprints en Launchpad. El blueprint será considerado por el equipo troncal de desarrollo y si se acepta, se le asignará un desarrollador, revisor y una versión de publicación. Se puede acceder y añadir blueprints via web en http://blueprints.launchpad.net/dhis2 + Si encontramos un bug en DHIS 2 podemos también reportarlo en Launchpad navegando a http://bugs.launchpad.net/dhis2 Nuestro reporte de bug será investigado por el equipo de desarrollo y se le asignará un estatus. Si se valida, será asignado a un desarrollador y revisor y eventualmente será solucionado. Notemos que la resolución de bugs se incorpora en el trunk y en el branch más reciente publicado - de modo que realizar un buen testeo y retroalimentación a los equipos de desarrollo revierte en mejor calidad de nuestro software.