dhis2-devs team mailing list archive

[noreply@xxxxxxxxxxxxx]

------------------------------------------------------------
revno: 183
committer: Jason P. Pickering <jason.p.pickering@xxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Mon 2010-04-12 19:27:26 +0200
message:
  Adding first (totally incomplete) implementation guide. Work in progress
added:
  src/docbkx/en/dhis2_implementation_guide.xml


--
lp:~dhis2-documenters/dhis2/dhis2-docbook-docs
https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs

Your team DHIS 2 developers is subscribed to branch lp:~dhis2-documenters/dhis2/dhis2-docbook-docs.
To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs/+edit-subscription

=== added file 'src/docbkx/en/dhis2_implementation_guide.xml'
--- src/docbkx/en/dhis2_implementation_guide.xml	1970-01-01 00:00:00 +0000
+++ src/docbkx/en/dhis2_implementation_guide.xml	2010-04-12 17:27:26 +0000
@@ -0,0 +1,175 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- This document was created with Syntext Serna Free. --><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "docbookV4.5/docbookx.dtd" []>
+<chapter>
+  <title>DHIS2 Implementation Guide</title>
+  <abstract>
+    <para>DHIS2 is a modern, robust and comprehensive information management platform developed globally  tailored to the collection of aggregate statistical data. . This document will provide a high-level overview of the various steps that will be required to implement DHIS2 at the country level. 
+The document is intended primarily for  consultants who will be responsible for the initial configuration of DHIS2 for a given country or organization.  While this document attempts to identify the most important points to consider when planning an implementation, there are many circumstances in a particular country that are impossible to anticipate. With that in mind, this document should be used as the basis to plan and execute a DHIS2 deployment, but should by no means be regarded as comprehensive. Other factors (political, human, or technical) that may not be included in this document, but that may be deemed to be important by the person(s) planning the implementation, should always be considered, and are usually highly specific to each country’s situation. . Significant planning, stakeholder consultation, and resources will be required in order to implement and maintain such an information system.  Careful planning and resource allocation will help to mitigate the risk of deployment. 
+The initial stages of planning and deployment are crucial in order to acheive a functional system. </para>
+  </abstract>
+  <section>
+    <title>Readiness asessment</title>
+    <section>
+      <title>Stakeholders forum</title>
+      <para>There are many factors that influence the successful establishment of an health management information system: technical, political and human. Understanding the requirements of key stakeholders prior to an technical work being performed is crucial in order to ensure the sustainability of the HMIS. DHIS2 has often been implemented with the assistance of external consultants, who may be present in a given country for a short period of time. In many cases, they may not understand all of the requirements of different parties that are part of the HMIS. It is therefore crucial that a HMIS working group be established, and clearly define the overall requirements of the HMIS, prior to any technical consultations being carried out. </para>
+      <para>Typically, the HMIS working group would be composed of different stakeholders who have different interests in the system. <itemizedlist>
+          <listitem>
+            <para>Ministry of Health: Typically the key client and driver of the HMIS. In some countries, the Minsitry may be responsible for oversight, in other countries they may be direct service providers. </para>
+          </listitem>
+          <listitem>
+            <para>Central Statistics Office or its equivalent:  Indicators are often based on population figures, which are typically supplied by the CSO or its equivalent. In many countries, the MoH is responsible for the submission of a yearly report to the CSO on the health sector. Good coordination between these two bodies is crucial to ensure that population figures are up to date and accurate, and that the data supplied to the CSO by the MoH satisfies the needs of the national statistical system. </para>
+          </listitem>
+          <listitem>
+            <para>Key non-governmental agencies, that typically supply data on programmatic interventions. Examples would be faith-based organisations (FBOs) who in many countries offer health related services and who often report to the MoH on their activities. </para>
+          </listitem>
+          <listitem>
+            <para>UN Agencies (WHO, UNICEF, UNAIDS). The MoH is usually responsible to report to the UN agencies on various statistics. The UN agencies can often offer technical support and provide advice on international norms and standards for the establishment or reform of an HMIS. </para>
+          </listitem>
+          <listitem>
+            <para>Other governmental bodies that may offer health related services. The National HIV/AIDS Commission ( or its equivalent) often monitors or implements services such as home-based care and anti-retroviral treatment programmes. There is often overlap between the MoH and the NAC, and therefore close cooperation should be estabslished to ensure a proper data flow. </para>
+          </listitem>
+          <listitem>
+            <para>Donor agencies and other cooperating partners. In many countries, donors regularly request information related to the health sector from the MoH. Additionally, some bilateral organisations, e.g. USAID/CDC, may be implementing programmes in countries which support health related services. </para>
+          </listitem>
+        </itemizedlist></para>
+      <para>Other organisations such as private sector enterprises with HIV/AIDS workplace programs, private sector health care providers, non-governmental organizations involved in health care, etc.  should be considered. The HMIS working group can help to establish the overall scope of the information management system, key indicators, frequency (monthly, quarterly, annually) of data collection, as well as the geographical (e.g. national, provincial, district, facility) and organizational (single versus multiple) hierarchy that should be part of the HMIS. 
+</para>
+    </section>
+  </section>
+  <section>
+    <title>Deployment architecture</title>
+    <section>
+      <title>Determining an architecture</title>
+      <para>DHIS2 is a server-client application that is capable of scaling from a single-desktop installation, to a multi-tiered clustered application capable of serving many clients at the same time.  The deployment architecture of DHIS2 will determine how the application is deployed in a given situation, and how different instances of DHIS2 will interact with each other. Several typical deployment architectures will be described in this section.  The determination of an approrpriate architecture is critical in order to meet the needs of the end-users, and it typically constrained by the level of available technical and finanacial resources for a given deployment. It should be noted that the deployment architecture may need to evolve over the course of an implementation. It is important to consider other systems that need to interact with the HMIS, such as patient record systems, logistical information systems, human resource information systems, financial management systems, etc. </para>
+    </section>
+    <section>
+      <title>Single-server, multiple clients</title>
+      <para>In this scenario, a single server will be used by multiple clients that connect to the server via the Internet. This deployment scenario is probably the simplest of all, besides the single-user desktop installation. In a typical scenario, a sinlge standard server-class machine would be used. DHIS2 would run with Apache Tomcat with either MySQL or Postgresql database backend. The administrator would be responsible for specification of the different user roles, and the provision of logins for each user, depending on their role. </para>
+      <para>Of course, depending on the actual number of clients that will be simultaneously accessing the application, multiple load-balanced servers accessing a clustered database may be more appropriate. DHIS2, like many database driven applications, tend to be constrained in terms of disk input/output. A common strategy for alleviating this constraint is the use of a clustered database. Both Postgresql and MySQL support database clustering. Essentially, a database cluster acts for all intents and purposes as a single database, but appears to the application accessing the database as as a single instance. There are many different scenarios that are capable of acheiving a clustered database with either MySQL or Postgres , but are beyond the scope of this article to consider. It should be mentioned that database replication, while seemingly easy to implement, requires considerable database administration experience, and should only be considered when high availability and large numbers of users will be encountered.  </para>
+    </section>
+    <section>
+      <title>Decentralised architecture</title>
+    </section>
+  </section>
+  <section>
+    <title>Configuration</title>
+    <section>
+      <title>Organizational unit hierarchy</title>
+    </section>
+    <section>
+      <title>Data elements</title>
+    </section>
+    <section>
+      <title>Indicators</title>
+    </section>
+    <section>
+      <title>GIS data</title>
+    </section>
+  </section>
+  <section>
+    <title>Migration from existing systems</title>
+    <para/>
+    <section>
+      <title>Importing organizational units</title>
+      <para>   1. Find IDs for all the orgunits at the lowest level (usually facilities). They often have codes, but that is not the ID (rather it is CODE). Generate suitable IDs for the ones at the higher levels. Add all the IDs to SOURCE. NOTE: In postgres the simplest thing would be to use the built-in ID sequence called hibernate_sequence. This provides a unique ID and is consistent with the other tables and rows in the database (which all get the IDs from this sequence). This hibernate_sequence might be available in other DBMSs as well, not sure. The sql command is on the type
+
+      insert into XX values
+      (nextval(&apos;hibernate_sequence&apos;,etc. etc.)
+   2. Add the top node (e.g. National MoH) to ORGANISATIONUNIT. Make sure PARENTID is NULL and ACTIVE=TRUE
+   3. Then add level 2 (e.g. provinces). All must have PARENTID=&lt;TOP_NODE_ID&gt;, a NAME(230), a SHORTNAME(25)  (both unique) and ACTIVE=TRUE. This can be a big job for shortname. One way to achieve this quickly is to initially just use the ID as shortname, but put the first 20 characters of the name in front. Not a good long term solution - the best is usually to take the core of the name and add a qualifier that distinguishes it from other facilities with the same core name. In the shortname, leave out the orgunit type (i.e. don&apos;t include &quot;Dispensiary&quot;, &quot;Medical Clinic&quot; etc in the shortname).
+   4. Proceed similarly for levels 3 and on, but always pay attention to the PARENTID
+   5. Create names for each Organisation Unit Level in DHIS2
+   6. IMPORTANT: SOURCE and ORGANISATIONUNIT must always be synchronized, otherwise you will have problems with datamarts (e.g. if there is an extra ID in SOURCE)</para>
+    </section>
+    <section>
+      <title>Importing data elemens</title>
+      <para>1.      Add a default element with CATEGORYCOMBOID in CATEGORYCOMBO
+
+2.      Each data element must have a NAME(230), a SHORTNAME(25) and ACTIVE=TRUE. Both must be unique. Also, it musth have a VALUETYPE=&quot;int&quot; DOMAINTYPE=&quot;aggregate&quot;, AGGREGATIONTYPE=&quot;sum&quot; and CATEGORYCOMBOID as in step 1.
+
+3.      We now need at least a default CATEGORYOPTIONCOMBOID. If you have multidimensional data (e.g. broken down by age group or sex), you need to create the corresponding categories. This is best done in the DHIS2 GUI
+
+4.      Add in DATAELEMENTGROUP - NAME, ID and optional CODE
+
+5.      Add DATAELEMENTGROUPMEMBERS - two IDs
+
+6.      Add DATASET - ID, NAME and SHORTNAME(60). Requires a PERIODTYPEID from PERIODTYPE (e.g. 6 for monthly, 9 for yearly). (and LOCKED =&quot;0&quot; ??)
+
+7.      DATASETMEMBERS - two IDs
+
+8.      DATASETSOURCE - two IDs. However note that it easy to assign datasets to all orgunits at a level inside DHIS2. Often, one wants a kind of cartesian product, e.g. SELECT datasetid, organisationunitid FROM dataset, organisationunit WHERE organisationunitid&lt;1000</para>
+    </section>
+    <section>
+      <title>Importing indicators</title>
+      <para>   1. INDICATORTYPE - just make a DEFAULT with FACTOR=1
+   2. INDICATOR - ID, NAME(230), SHORTNAME(25), INDICATORTYPE (default), NUMERATOR must be on the form [DATAELEMENTID.CATEGORYOPTIONCOMBOID],dataelement shortname as NUMERATORDESCRIPTION (Why do we require this in the GUI?), DENOMINATOR=1, &quot;One&quot; as DENOMINATORDESCRIPTION (Why required in GUI?). It can be smart to set the numeratoraggregationtype and denominatoraggregationtype to &quot;sum&quot;
+   3. INDICATORGROUP - perhaps same as DATAELEMENTGROUP ?
+   4. INDICATORGROUPMEMBERS - can be similar to DATAELEMENTGROUPMEMBERS</para>
+    </section>
+    <section>
+      <title>Importing data values</title>
+      <para>1.      PERIOD - all fields
+
+2.      For DATAVALUE you need these fields: DATAELEMENTID, PERIODID, SOURCEID,CATEGORYOPTIONCOMBOID and VALUE (Determine the needed CATEGORYOPTIONCOMBOIDs or just use the default one)</para>
+    </section>
+  </section>
+  <section>
+    <title>Case studies</title>
+    <section>
+      <title>India metadata handling experience</title>
+      <para>35 server instances (one per state) on 7 physical servers Kerala works both online and offline 2000 PHCs. Problem with version control for the database content - how to synchronize thousands of offline installations. HMIS committee at state level - control changes to happen only once a year, releasing versioned  metadata lists.
+
+Different states have different data elements (in addition to the nationally defined ones).
+
+Versioned document for each state published on NHSRC portal: “Data Element definition and guide for use” containing level, frequency, guide for use and definition, as well as group. Dimensions are not created unless they are shared between several data elements. Currently, breakdowns by dimensions are not included in the document.
+
+Problem with DHIS2 that everyone sees all data elements defined by anyone - and no concept of ownership of data elements (or indicators).
+
+What if one district has a different dimensional breakdown?
+
+Strict control over the data elements: A change process where everyone updates centrally distributed database content versions and DHIS versions, including existing data. Everyone gets all data for the whole district. District has down to subcenter data. The online is just down to block level (State - District - Block).
+
+District people are not allowed to change metadata and just exports aggregate data.
+
+In Kerala, all PHCs have computers. From next month just online data entry.
+
+8000 PHCs in Gujarat - the server cannot handle everyone entering data at once, so rotating weeks between districts. Batch process to generate all reports. Currently not using the datamart - as it used to take too long time. DB size is 3 GB and MySql cannot handle it. Server with 32 GB RAM. Lars: Data entry must be made more efficient. Needs expertise in clustering, load balancing and database optimization.
+
+India has requested a system setting “Disallow updates on import”.
+</para>
+    </section>
+    <section>
+      <title>Zanzibar and Tanzania</title>
+      <para>35 server instances (one per state) on 7 physical servers Kerala works both online and offline 2000 PHCs. Problem with version control for the database content - how to synchronize thousands of offline installations. HMIS committee at state level - control changes to happen only once a year, releasing versioned  metadata lists.
+
+Different states have different data elements (in addition to the nationally defined ones).
+
+Versioned document for each state published on NHSRC portal: “Data Element definition and guide for use” containing level, frequency, guide for use and definition, as well as group. Dimensions are not created unless they are shared between several data elements. Currently, breakdowns by dimensions are not included in the document.
+
+Problem with DHIS2 that everyone sees all data elements defined by anyone - and no concept of ownership of data elements (or indicators).
+
+What if one district has a different dimensional breakdown?
+
+Strict control over the data elements: A change process where everyone updates centrally distributed database content versions and DHIS versions, including existing data. Everyone gets all data for the whole district. District has down to subcenter data. The online is just down to block level (State - District - Block).
+
+District people are not allowed to change metadata and just exports aggregate data.
+
+In Kerala, all PHCs have computers. From next month just online data entry.
+
+8000 PHCs in Gujarat - the server cannot handle everyone entering data at once, so rotating weeks between districts. Batch process to generate all reports. Currently not using the datamart - as it used to take too long time. DB size is 3 GB and MySql cannot handle it. Server with 32 GB RAM. Lars: Data entry must be made more efficient. Needs expertise in clustering, load balancing and database optimization.
+
+India has requested a system setting “Disallow updates on import”.
+</para>
+    </section>
+    <section>
+      <title>Sierra Leone</title>
+      <para>From 2009 to 2010 they changed the dimensional breakdown of some data elements from by gender to by age group. This necessitated a huge database merging effort and parallel “2009” and “2010” database structures (because it takes time to get all reported data in from the previous year).
+
+Another huge problem is keeping the orgunit hierarchy up to date and synchronizing it between installations. Orgunit names change, new units get created, and when old files get imported, old misspellings crop up again.
+</para>
+    </section>
+    <section>
+      <title>Zambia</title>
+    </section>
+  </section>
+</chapter>