dhis2-devs team mailing list archive

[noreply@xxxxxxxxxxxxx]

------------------------------------------------------------
revno: 344
committer: Lars Helge Overland <larshelge@xxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Sat 2011-06-18 22:53:31 +0200
message:
  Added chapter on recommendations for national implementations
added:
  src/docbkx/en/dhis2_implementation_guide_recommendations.xml
modified:
  src/docbkx/en/dhis2_implementation_guide_en.xml


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

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

=== modified file 'src/docbkx/en/dhis2_implementation_guide_en.xml'
--- src/docbkx/en/dhis2_implementation_guide_en.xml	2011-06-18 20:41:38 +0000
+++ src/docbkx/en/dhis2_implementation_guide_en.xml	2011-06-18 20:53:31 +0000
@@ -51,6 +51,7 @@
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_integration.xml" encoding="UTF-8"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_deployment_strategies.xml" encoding="UTF-8"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_data_warehouse.xml" encoding="UTF-8"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_recommendations.xml" encoding="UTF-8"/>
   <!-- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_system_design.xml" encoding="UTF-8"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_database_development.xml" encoding="UTF-8"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; href="dhis2_implementation_guide_harmonisation.xml" encoding="UTF-8"/>

=== added file 'src/docbkx/en/dhis2_implementation_guide_recommendations.xml'
--- src/docbkx/en/dhis2_implementation_guide_recommendations.xml	1970-01-01 00:00:00 +0000
+++ src/docbkx/en/dhis2_implementation_guide_recommendations.xml	2011-06-18 20:53:31 +0000
@@ -0,0 +1,56 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- This document was created with Syntext Serna Free. -->
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"; []>
+<chapter>
+  <title>Recommendations for National HIS Implementations</title>
+  <para>The following text gives a brief overview of some of the key aspects of HIS implementations learned by HISP from numerous missions in developing countries. The various aspects can be used as input for planning of new implementation efforts or evaluation of ongoing processes.</para>
+  <section>
+    <title>Database development</title>
+    <para>When developing a new database a natural start is to define the data elements for which to capture data and to design the data entry forms. The data elements are the core building blocks of the database and must be reasonable stable before moving on. The next step could be to define validation rules based on the mentioned data elements to be able to better ensure the correctness of the data being captured. </para>
+    <para>The other core component of the database is the organisational hierarchy which should be identified and set up in the initial phase. The health facilities are generally the source of the data and the organisational hierarchy is locating the facilities in both the geographical and in the administrative dimension. In most countries there is no strictly defined and continuously updated “master registry” for health facilities, hence this process needs to involve the different stakeholders including the district level as they will be the ones who have best knowledge about the situation.</para>
+  </section>
+  <section>
+    <title>Import and mapping of existing databases</title>
+    <para>Bringing in existing data to the new system adds significant value in the initial phase as it makes it a lot easier to demonstrate analysis capabilities such as charts and reports. This improves the ability to convince stakeholders such as health programs and donors to support the new system. In most cases there exists a large amount of electronically stored data from in-house database systems, excel sheets or other third party systems. This data should whenever possible be imported and mapped to the data elements and the organisational units (locations/facilities) of the new system with whatever feasible technical solution. This should be regarded as a one-time job for boot-strapping the database and does not have to turn into an elegant and reusable routine.</para>
+  </section>
+  <section>
+    <title>Securing necessary resources for the implementation</title>
+    <para>Doing a national roll-out is an expensive effort which requires appropriate funding for aspects mentioned in the following including procurement of hardware, server hosting, internal and external training workshops. The funding could be retrieved from the government budget and/or with help from external donors. It is vital that even relatively small amounts needed for instance for airtime for mobile Internet modem are budgeted for and provided in order to avoid frustrations and unnecessary problems for end users.</para>
+  </section>
+  <section>
+    <title>Integration of parallel systems</title>
+    <para>The typical government health domain has a lot of existing players and systems. Fist it is apparent that an integrated database containing data from various sources becomes a lot more valuable and useful than fragmented and isolated ones. For instance it improves usefulness when analysis of epidemiological data is combined with specialized HIV/AIDS, TB, financial and human resource data, or when immunization is combined with logistics/stock data as it will give a more complete picture of the situation. Second there is typically a lot of overlapping data elements being captured by the various parallel systems. For instance will HIV/AIDS related data elements be captured both by both multiple general counselling and testing programs and the specialized HIV/AIDS program, or data elements related to malaria in pregnancy will be captured by both the reproductive health program and the malaria program. Harmonization the data collection tools of such programs will reduce the total workload of the end users. This implies that such data sources should be integrated into the national information system and harmonized with the existing data elements, which involves both data entry and data analysis requirements and requires a flexible and extensible information system software. It is thus important that individual discussions and work are done with all relevant stakeholders including all health programs.</para>
+  </section>
+  <section>
+    <title>Setup of a reliable online national server</title>
+    <para>As the technological development moves on most countries have a mobile network and coverage for a certain part of the districts. The use of networked based information systems accessed over the Internet (also referred to as “cloud computing”) combined with Internet modems using the mobile network is a great approach for rapid scaling. This assumes a reliable online server at the national level. The recommended approach is to procure such hosting services from external providers (such as Linode and Amazon) which relieves the government of providing necessary features such as back-up electricity solutions, regular data backup, server maintenance and security and reliable Internet/network access. A typical concern is policy and in-country location of the data storage but this can be mitigated with special arrangements with the provider.</para>
+  </section>
+  <section>
+    <title>Pilot phase</title>
+    <para>Before initiating the national system roll out a pilot phase is required, typically for all districts in a province/region. The objective is to field test and get feedback on the system from all stakeholders. Typically end users will provide feedback on the data entry experience, involving the data entry form designs, the usability of the data entry functionality, content of reports and other analysis tools, the feasibility of doing online data entry (modem and airtime accessibility) or offline data entry (reliability of local installation). Typically one will experience some resistance from end-users regarding the change from paper based to electronic systems paradigms, for instance related to the decoupling of data entry forms and data analysis tools. One gets to test the feasibility of the network connectivity and the national server configuration with regard to performance and up-time.</para>
+    <para>In the situation where one has a running legacy system it is vital to shut that system down in the pilot area. If the legacy system is still in production the primary focus of the end users will be on entering data in that system and the piloted system will get peripheral attention with suboptimal testing and learning as a result. If maintaining the legacy system is a priority then the data should be transferred by the technical team without burdening the end users.</para>
+  </section>
+  <section>
+    <title>Roll out</title>
+    <para>The roll out process is traditionally associated with installation and basic training of the system. It is, however, useful to consider it as a more comprehensive process involving multiple phases. </para>
+    <para>The first phase corresponds to the traditional activities where the first objective is about<emphasis role="italic"> data completeness:</emphasis> To ensure that close to 100% of the data is being collected. First this implies that the system should be implemented and used at all districts in the country. Second it implies that data for all data elements included in the forms are actually reported by the districts or facilities. Data being reported within a reasonable time frame - <emphasis role="italic">timeliness</emphasis> - is also relevant in this context. </para>
+    <para>The second objective is related to <emphasis role="italic">data quality</emphasis>: To ensure that data capture errors are reduced to a minimum. Several measures should be effected to achieve this: First data entry and data review should be done by skilled personnel. Second automatic data evaluation methods such as logical validation rules and outlier analysis should be applied to the data.</para>
+    <para>The second phase is about enabling district and hospital officers to use <emphasis role="italic">standard analysis tools</emphasis> such as reports, charts an pivot tables. Users should be able to find and execute those tools with relevant data. This must be followed by a basic understanding of the purpose, meaning and consequences of those tools and of the data being analyzed.</para>
+    <para>The third phase involves <emphasis role="italic">data usage</emphasis>: Regular use of data analysis to improve evaluation, planning and monitoring of health activities at all levels. Data from the information system should be used to evaluate the effects of implemented measures by looking at key indicators. That learning should later be used to make informed decisions on future planning. For instance when low immunization rates are discovered through an immunization report coming from the information system an outreach vaccination campaign could be effectuated. The effects of the campaign could then be monitored and evaluated based on up-to-date reports and informed decisions made on whether to intensify or wind down. The system could later provide information regarding what quantity of vaccine doses which must be ordered from the supplier.</para>
+    <para>To accommodate for large-scale roll out processes a detailed plan must be made for training and follow-up as covering all districts in a country represents a logistical challenge in terms of workshop venues, trainers, participants, equipment and hardware. To speed up the process several teams could give parallel trainings.</para>
+  </section>
+  <section>
+    <title>Training</title>
+    <para>Most of the objectives mentioned in the roll out section depends heavily on appropriate user training. User training can be conducted in several ways. An effective activity, especially for getting started, is training workshops. Users such as district and province record officers, district managers, data entry officers and health program managers are gathered and given training. Training should be done as a combination of theoretical lectures and hands-on practise on relevant subjects mentioned in the roll out section such as data entry, validation and analysis. Participants should be kept at a manageable number depending on the facilities and number of trainers available. Sufficient hardware for all participants to do practical work must be provided.</para>
+    <para>Another useful activity is on-the-job training which has the advantage that users get individual follow-up in their home working environment. This provides the ability to help with individual specific needs or questions and sort any issues related to hardware. Also, giving individual support will often boost the motivation and ownership feeling of end users. </para>
+    <para>The period between a workshop and on the-the-job training can be used for home work assignments, where users typically are assigned to create meaningful analysis for their district or province. This work can then be given feedback on and used as basis for individual training.</para>
+  </section>
+  <section>
+    <title>Decentralization of data capture and management</title>
+    <para>Migrating from paper based systems or primitive databases to full-fledged web based health information systems and from capturing district based aggregated data to facility based data entails new possibilities for decentralized data management which should be exploited. Firstly the facilities with sufficient hardware and network connectivity should be tasked with entering their own data. This will reduce the workload of the district health records officer who might use the freed up time for data analysis, data use, feedback to facilities and data quality efforts. Secondly maintenance of the facility hierarchy in terms of facility classification and health services provided at the facilities is a resource demanding task and should be decentralized and done as a joint effort by all district officers rather than by a single national team. This will make the facility information more correct and up to date since the district officers have better knowledge of their local situation and have incentives for proper management as it will eventually affect their performance indicators and data completeness scores.</para>
+  </section>
+  <section>
+    <title>Review and extension</title>
+    <para>A national HIS is a growing organism which needs to be maintained. As the system usage increases more requirements and needs will emerge from new and existing stakeholders such as district record officers and health program staff. Regular review meetings including such stakeholders should take place where data capture tools, such as data elements and forms, and data analysis tools, such as indicators and reports, should be revised and new tools potentially added. Also, new functionality requirements should be managed and appropriate software development resources should be secured. Such regular activities for supporting the extension and enhancement of the system are vital to maintain the current momentum and learning processes and to improve long-term project sustainability.</para>
+  </section>
+</chapter>