Udržitelný CHIS DHIS2 Design a architektura¶

Udržitelný CHIS musí být dobře navržen tak, aby vyhovoval informačním potřebám příslušných zúčastněných stran, a musí být dostatečně flexibilní, aby se mohl vyvíjet s měnícími se informačními potřebami systému. Architektonická hlediska jsou důležitá pro to, aby CHIS nebyl samostatný a byl schopen komunikovat s jinými systémy. To vyžaduje dobře navržený datový model, který zaručí výstupy a výsledky předpokládaného CHIS. Tato kapitola se zabývá úvahami o budování zvukové architektury a designu pro CHIS pomocí DHIS2. Byl napsán s ohledem na následující předpoklady:

• Osoba vedoucí návrhu datového modelu má rozsáhlé pracovní znalosti datových modelů DHIS: agregovaných, událostí a sledovacích modelů
• Osoba vedoucí zavádění má rozsáhlé znalosti o národní infrastruktuře a předchozí zkušenosti s podobným zaváděním

1. Mapování současného stavu podnikových procesů¶

Nejhorší konfigurace CHIS v DHIS2 je obvykle tam, kde jsou současné obchodní procesy komunitního zdravotního programu jednoduše digitalizovány do DHIS2 bez jakýchkoli úprav za účelem jejich optimalizace. Abychom se této chybě vyhnuli, je prvním krokem k návrhu dobře fungujícího CHIS v DHIS2 provést důkladné zmapování aktuálního stavu toku dat komunitního zdravotního programu M&E. Hlavním cílem mapování současného stavu je:

1. Harmonize CHW reporting tools into as few as possible
2. Standardizovaly harmonizované nástroje pro podávání zpráv v celé zemi.
3. Identifikujte, co funguje dobře.
4. Identifikujte, co nefunguje dobře a jak by se to dalo zlepšit.

Mapování aktuálního obchodního procesu má v podstatě dva kroky.

1. Zkompilujte všechny aktuální formuláře pro sběr dat. U každého formuláře uveďte:
2. Jaké jsou datové prvky a ukazatele v tomto formuláři sběru dat? Jsou tyto v rámci CHIS M&E? Pokud ne, měli bychom je přesto zachytit?
3. Kdo je zodpovědný za zachycení dat a jak dlouho to trvá?
4. Jaká je frekvence vyplňování formuláře hlášení?
5. Jaké jsou běžné chyby nebo potíže s vyplňováním formuláře pro sběr dat?
6. Jaké pracovní pomůcky nebo nástroje podpory pracovního postupu jsou zabudovány do formuláře pro sběr dat? Pracují? Je potřeba více?
7. Zmapujte tok elektronických nebo papírových dat z místa sběru na centrální úroveň
   • Proti jaké organizační jednotce jsou data zachycena?
   • Jaké jsou body agregace? Kdo provádí agregace?
8. Zkompilujte všechny aktuální nástroje pro analýzu/použití dat. U každého nástroje identifikujte:
9. Jaká je úroveň granularity prezentovaných dat?
   • Organizační úroveň agregace (tj. komunita, zařízení, okres nebo národní)
   • Úroveň periodicity agregace (tj. denně, týdně, měsíčně, např.)
10. Jaká rozhodnutí nebo akce jsou na základě tohoto nástroje činěny?
11. Jaké jsou problémy nebo problémy s nástrojem?
12. Co lze udělat pro řešení těchto problémů nebo problémů?

2. Úvahy o převodu obchodních procesů do DHIS2¶

Překlad datových toků komunity v DHIS2 je nejdůležitějším krokem v procesu návrhu. Existuje devět kritických prvků, které je třeba vzít v úvahu. Tyto jsou:

1. Types of CHW data
2. Období a četnost vykazování
3. Organizational hierarchy: reporting structures & relation to national HMIS
4. Vertical health programs and integrated reporting
5. Implementing partner considerations
6. Core indicators & analysis needs
7. Úvahy o infrastruktuře
8. Technology considerations (devices, connectivity)
9. Bezpečnostní

Types of CHW data¶

Community health service delivery data is often considered an extension of facility-based services to the community with strong linkages to referrals. CHWs also participate in other periodic household level data collection activities, as well as campaigns, education and prevention, and community-based surveillance.

1. CHW Aggregate data reporting: aggregated data from CHWs on routine service delivery and outreach activities are reported into DHIS2 alongside aggregate facility data. The data structure should allow for disaggregation by services delivered in the community or in the facility, as well as meaningful aggregation at the lowest levels of the HMIS hierarchy.
2. Household surveys: annual household surveys are conducted by CHWs and data can be used to populate community-level denominators or provide annual data for triangulation with routine service delivery data.
3. Campaigns: CHWs may be responsible for supporting community-based campaign style interventions that are planned as supplemental activities to routine service delivery
4. Individual-level longitudinal data: digitalization of person-centered data collection, such as clients in the community enrolled into a vertical health program like Family Planning services; or clients tracker for prevention, education and service delivery through integrated digital registers.

The various reporting structures should be mapped against the availability of paper-based and electronic tools to determine the most appropriate point of data integration in DHIS2.

Období vykazování/frekvence¶

While the frequency of source data collection may vary depending on the availability of CHW level data collection tools, it is important to consider the harmonization of reporting period or frequency for integrating aggregate CHW data with aggregate facility data in an HMIS. For example, a given set of related elements for a service such as RDT testing should share the same frequency (e.g. in a DHIS2 dataset_ to enable comparable analysis of community and facility data.

Organization Units & Reporting Structures¶

The logic of reporting structures should be considered with relation to aggregation through the organisation unit hierarchy and linkages with HMIS administrative structures, such as facility catchment areas or supervisory reporting flows from CHWs to facilities. Another important consideration is how to add CHWs in the reporting hierarchy. Given the scale and number of CHWs, this becomes one of the fundamental decisions in CHIS design.

Organizační strom představuje administrativní nebo geografické rozdělení umístěné uvnitř hierarchie. Například:

• Country, HQ [L1]
• Province, district (administrative unit) [L2]
• Facility, clinic, hospital (providing services) [L3]

Designing the organization unit hierarchy to integrate community and facility data should take into account:

1. Where the data is associated with (i.e. individual patient, household, village, health facility, community health posts, facility catchment areas etc.).
2. Co data znamenají. Je možné data smysluplným způsobem agregovat v hierarchii? Jsou data zachycená v této organizační jednotce smysluplná pro tuto úroveň?
3. Kdy jsou data zachycena. Období přiřazené souboru dat nebo programu by mělo být agregovatelné v hierarchii do stále větších období. Například nemůžete mít měsíční vykazovaný datový prvek na úrovni komunity agregovaný do týdenního datového prvku v jeho nadřazeném zařízení.
4. Who captures the data and provides the services. This is especially important for community health programs where we need to know the actions and services delivered by individual CHWs; or need to maintain a mapping from CHW rosters to more stable HMIS hierarchies for data integrationl.

Scale - How big is too big for the hierarchy?¶

Pokud budou CHW nebo jednotlivé komunity zahrnuty do hierarchie a CHIS bude převzat do celostátního měřítka, je velmi pravděpodobné, že CHIS/HMIS bude obsahovat desítky tisíc organizačních jednotek. Pokud jsou organizační jednotky dobře definované a organizované, je velmi možné mít obrovské množství organizačních jednotek. Například CHIS Zambie obsahuje téměř 45 000 organizačních jednotek zastupujících všechny vesnice v zemi.

Při řešení výše uvedeného množství prezentovaných podmínek může být CHW vytvořen jako organizační jednotka v DHIS2 nebo jako uživatel pro organizační jednotku. V každém případě je důležité zvážit a vyhodnotit celou hierarchii organizace pro zemi nebo projekt, aby bylo zajištěno, že hierarchie bude zvládnutelná, obvykle nepřesahující 7-8 úrovní.

Vertical Health Programs vs Integrated reporting¶

In some cases, CHWs networks focus on health program specific interventions and reporting (malaria, HIV, infant feeding habits, contraception counselling, etc.). In other cases, CHWs may be trained on different types of services, such as outreach and education, integrated community case management or integrated RMNCAH services. These reporting structures should be considered in the design and assignment of data sets to user groups and org units.

Implementing Partner Reporting¶

In some countries, CHW networks are supported by specific projects or implementing partners, a dimension which is not typically represented in a national HMIS. These reporting and data flows should be defined to determine the appropriate level of aggregation and integration with HMIS data. Where the CHIS is in a separate instance, it may also be possible to accommodate analysis by implementing partner dimensions using features such as data set attributes.

Core indicators & analysis needs¶

CHIS system design should be driven by the expected outputs and analytics required from the system. Core indicators may be defined through country level steering committees or routine HMIS reviews with government stakeholders. These processes should take into consideration alignment and integration with facility-based and HMIS data; as well as defining reporting requirements based on data use. Though this is a general rule of thumb in the design of any information system at any level, it is a crucial consideration in a CHIS when the scale of data is very large and has immediate implications on the workload of a CHW, as well as the fluctuation of CHWs, availability of devices and connectivity, and other operational challenges.

Infrastructure Considerations¶

• Backend Infrastructure & Hosting – Local versus Cloud DHIS: Dimenzování – hosting serveru se v případě CHIS stává zásadním, pokud má být použito mobilní hlášení pomocí SMS. Hlášení založené na SMS nebude fungovat, pokud je server hostován v cloudu mimo zemi, protože bude zahrnovat mezinárodní zasílání zpráv. Jako takový musí server hostovat v rámci země.
• Nastavení a údržba SMS brány: Primárním požadavkem je integrace s SMS bránou, aby bylo možné hlášení založené na SMS. Je třeba kontaktovat místní/země založené poskytovatele bran a zkontrolovat, zda rozhraní API umožňují integraci.
• Bezplatné vs. placené uživatelem: V případě, že jsou SMS pro odesílatele/CHW zdarma, je pro integraci vyžadován poskytovatel mobilních služeb nebo poskytovatel služeb brány s bezplatným předplatným. V tomto případě musí náklady nést centrálně MZ a poskytovat je zdarma pro CHW
• Správa vysílacího času a náhrada pracovníkům: V případě použití mobilního hlášení pro CHW (SMS nebo internet), využití a řízení vysílacího času musí být přiděleno pro plánované hlášení. Musí být definován účinný systém proplácení CHW, protože pokud CHW nedostanou včas peníze za to, co utratili, mohli by se bránit používání telefonu.
• Posouzení síťové konektivity a napájení: Při zahájení hlášení od CHW pomocí mobilního telefonu je třeba zvážit posouzení pokrytí sítě, zejména ve venkovských a příhraničních oblastech. Načasování poskytování internetu je často proměnlivé a je třeba je vzít v úvahu při definování postupů podávání zpráv. Často se CHW musí potýkat s přerušovaným napájením, které brání hlášení a také nabíjení jejich telefonů a dalších zařízení.
• Vlastnictví a používání zařízení:
  • Hned v okamžiku předání zařízení (telefonů, stolů atd.) CHW je důležité vyjasnit si „vlastnictví“ zařízení spolu s odpovědností za údržbu, péči a ztrátu. Často dochází k nejasnostem ohledně toho, zda je zařízení ve vlastnictví instituce nebo jednotlivce a jaké jsou příslušné odpovědnosti.
  • Pokud se však očekává, že CHW budou pro hlášení používat osobní zařízení, je o to důležitější vyjasnit otázky týkající se vysílacího času/nákladů na data spolu s mechanismem úhrady.

Technology Considerations (Devices, Connectivity)¶

	Papír	SMS/USSD	Jednoduché telefony	Chytré telefony	Integrace 3. strany	Počítače
Kdy jej použít	Vždy je možnost, zvláště když digitalizace dat není prioritou	Prioritou je digitalizace dat u zdroje, zpravodajská zátěž je velmi nízká, mobilní internet není dostupný nebo telefony nelze poskytnout.	Digitizing data at source is priority, higher reporting burden, CHWs have a low ability to use smart phones, and mobile internet is available	Digitizing data at source is priority, reporting, mobile internet is available, and CHWs are able to use smartphones.	Digitizing data at source is priority & a data collection solution is implemented	Digitizing data depending on the level of computer availability
Scalability (geography, service, users, domains)	Scalable across all three elements	Technically east to scale, while training of users will required when adding new elements	Easy to scale geography & users, but not in terms of increasing reporting requirements	Easy to scale in terms of geography, users, and increasing data	Managing integration is an ongoing task; Scaling across users is easiest, while scaling on services & domain will need to be built within the integration approach	Easy to scale across all 3
Data Granularity	Possible to design for deeper dis-aggregation	Not advised for very disaggregate data or long forms	Not advised for very disaggregate data or multistage tracker programs.	Possible to design for deeper dis-aggregation and complex tracker programs.	Integration approach should build in all capturing whatever is reported	Possible to design for deeper disaggregation
Sustainability (Initial cost, ongoing cost)	Initial & ongoing printing; Training cost	Low cost solution; but at extremely high-volume of SMS costs can become significant; Training is a cost; Reporting incentives to CHWs	Initial & ongoing training cost; Procurement; Ongoing internet costs; Reporting incentives to CHWs	Initial & ongoing training cost; Procurement; Ongoing internet costs; Reporting incentives to CHWs	Integration of systems is a big cost	Initial training costs; Ongoing hardware maintenance
Human Capacity	Needs training on forms & logic of forms vs. registers	Needs training on forms & logic of SMS. Significant issues can be expected with short codes for SMS and timeout errors for USSD.	Training on forms, training on reporting using the application. CHWs should be able to troubleshoot basic application and phone problems	Training on forms, training on reporting using application. CHWs need to be able to troubleshoot basic application and phone problems	Training of CHWs is not required, as the integration is happening at server level	Training on forms: Training on the logic of forms vs. registers

Figure 4.3: Conceptualizing Data Acquisition

Security¶

DHIS2 is inherently a very secure software. Furthermore, many countries have strict laws on data security especially in terms of patient level data. Make sure you are aware of all national laws and policies around data security prior to developing a CHIS in DHIS2. As it is applied to CHIS in DHIS2 generally there are several considerations:

• If CHWs are tracking individual patients ensure that CHWs are only able to see the patients that are assigned to them.
• Ensure users are only able to see data as it applies to their role, actions, and decisions. Do not give users access to more data than they need.
• Access to data should always be protected by at least one level of access control. (i.e. password, pin code, etc) Simply swiping a mobile device to "unlock" it is not considered access control.
• Interception of unencrypted data via mobile signals is possible for SMS, USSD and J2ME. There are measures possible to prevent this. Please contact the core DHIS2 team for more information.
• Servers should be in a secure setting.
• Users should not be given more access to DHIS2 applications or features than what is necessary based on their duties.
• Sharing and privacy settings in DHIS2 can significantly increase security but must be carefully managed. For more information please see the DHIS2 User Manual.

3. Develop Mock-Ups and Prototypes of Analytics Outputs (Feedback Mechanisms)¶

All information systems should be designed for data use. An architect does not start constructing a building before he knows exactly what it will look like and the features it will have by making a blueprint and a mockup or prototype. Likewise, for a CHIS prior to system configuration all of the stakeholder analytics, feedback mechanisms, and dashboards must be designed and have mockups and prototypes.

In chapter two, these guidelines introduced the process for identifying stakeholders and in chapter three the process for selecting a feedback mechanisms for stakeholders was covered. Now that you know the data-use framework (who needs data and how it needs to be presented) the final step is to create mockups and prototypes of what those feedback mechanisms actually will look like.

A mockup is a scale model of what the feedback mechanisms looks like. For example, below is a mockup of a district ICCM dashboard. This mockup was developed prior to the configuration of the data base.

Figure 4.4: Prototype of a CHIS District Dashboard

The mockup is then used to:

• Ensure all data elements and indicators necessary for the stakeholders is being included in the system.
• All indicators are able to be presented in the analytics shown considering the degree of granularity of the analytics. For example, the mockup of the bar charts above is weekly counts at community health post (CHP) level. That means we are able to calculate those indicators given the data we have available at the frequency desired (weekly) at CHP level. Alternatively, if we only had the data elements available to create that indicator captured monthly at facility level we would not be able to calculate the indicator to a sufficient degree of granularity as what is required (weekly and at CHP level).
• Guide the actual development of the live analytics and feedback mechanisms.

4. Drawing CHIS Data Flow in DHIS2¶

The goals of this process are:

1. Develop a clear idea of the desired state of the CHIS in DHIS2
2. Formulate how to harmonize parallel or redundant existing data flows
3. Resolve overly burdensome or unclear standard operating procedures
4. Formulate how to reconcile multiple reporting hierarchies into one.
5. Identify job aids or workflow support that could be incorporated into the DHIS2 data capture tools.
6. Develop new data flow diagram/wireframe

5. Developing Reporting Guidelines¶

From the assessment and system design chapters, data flow from beginning to end is clearly defined. To develop data capture guidelines, start with the first event of the data flow and move upwards including all events, whether they utilize paper, mobile applications, or computers. For each point at which data is captured or transmitted the exact process and responsibilities for how that event is achieved needs to be defined.

For each step in the data flow define each event in the format in Figure 4.4.

---

Událost	Event name
Dataset/Reporting tool(s)	The name of the data set or reporting tool(s)
Modality of transmission or entry	Name the application that is used and on what device or outline the paper trail to data entry. (Remove this if the event is only data capture and not transmission or entry into DHIS2)
Responsible person	This is the person/role that is ultimately responsible for the completion of this event.
Periodicita	The frequency with which this event takes place. For example, "monthly," "weekly," or "quarterly
Event deadline	When the event should be completed. For example, "The 10th of the current month," "By 17:00 on Tuesday of the Current Week", or "By the 5th of the first month in the new quarter."
Data transmission or entry incentive	What is the reporting incentive and how is the incentive delivered? (if applicable)
Data quality checks performed	Outline what are the checks that are performed during this event. This does not include the quality checks performed after the data has been submitted.
Access to reporting tools	How are necessary reporting tools (e.g. registries, reporting forms, applications, phones, etc.) stored, accessed, and replenished?
Příběh	The narrative describes the event in long text. It is very specific. This could include best practices, instructions on completing the paper registries, instructions for ordering or making new registries, instructions for using mobile phones, etc. Think practically on what could form bottlenecks for data submission.

Figure 4.5: Data Capture SOPs

Frequent Questions on Data Capture Guidelines¶

What if my CHIS has a paper trail from CHW or community levels to facility or district level?

Some CHIS do not have data submission at CHW or community level. In this event, paper records or registries are produced at community level and then physically transported to facilities or higher levels. It is important for the protocol to include all CHIS activities, even if they are paper trail, as the timeliness and quality of one reporting stage directly impacts the success of the next.

Can the data capture guidelines be made to follow the roles of CHIS users?

Yes. You may be more use to seeing SOPs based on programmatic roles, while these data capture guidelines are based on the data flow. Many countries and programs incorporate the data capture guidelines into a larger programmatic SOP organized by stakeholder roles/titles (e.g. CHW, CHW Supervisor, District Health Officer, etc). The data capture guidelines can be incorporated into this format as long as a sufficient level of detail is provided for each event performed by the stakeholder.

What if my CHIS uses paperless patient registries at CHW level?

In some CHIS, CHWs may be tracking individual patients completely paperless via DHIS2 tracker application or similar application on an android or feature phone. In this event, there will not be a paper registry where information is initially recorded and there will be no production of periodic, aggregate reports. In these cases, typically it is best to consider the patient-CHW interaction and the capturing the patient data as a single event to be included in the data capture guidelines. Keep these factors in mind:

• In some cases, tracker use significantly increases the reporting burden of the CHW, so in high patient volume settings patient tracker may be too burdensome. However, configured as job aid for the CHW employing program rules and skip logic using the tracker application can reduce the reporting burden, increase data quality, and support CHW service delivery.
• Tracker will provide much more granular data and has shown to be appropriate at community level in disease elimination, epidemic control, expanded immunization programs, referral tracking, and neonate tracking.
• At community level, tracker should only be used if there is a targeted action requiring data from a single tracked entity. The specific response to that data should also be defined in the data capture guidelines.

6. Develop CHIS Meta-Data Dictionary¶

A meta-data dictionary is used to describe all of the meta-data attributes. The enables that system users and administrators understand the meaning and purpose of each meta-data item. A reference metadata dictionary is available for download from the DHIS2 CHIS resources based on the WHO and UNICEF recommended guidelines for monitoring CHW data, including core indicators, datasets, data elements and recommended disaggregations.

7. Perform DHIS2 Configuration¶

The final step after compiling a meta-data dictionary to actually perform DHIS2 system configuration.

See the CHIS System Design chapter for more information on DHIS2 configuration for CHW reporting and integration of community and HMIS data.

8. Populate Prototype Database and Test¶

Thoroughly testing a CHIS is critical prior to deployment. There are several goals of testing:

• Test indicator calculation - mock or legacy data should be imported into the prototype database to test if all the indicator calculations are correct.
• Use acceptance (analytics) - to test if all stakeholders are satisfied with the analytics, dashboards, and feedback mechanisms user experience.
• User acceptance (data entry) - to test if all stakeholder performing data entry are satisfied with the data entry user experience. It is also necessary to test if any skip logic, validations, alerts, workflow support, or job aids are working and users are satisfied.
• Bug capture and reporting. With virtually all new database there will be glitches or bugs. It you are thoroughly testing your database then most of these bugs will be noticed. It is best to resolve all bugs before you deploy your CHIS to scale. Bugs can be reported DHIS2 JIRA ([http://jira.dhis2.org]{.ul})

Important

Have a "sandbox" database for testing It is a very good idea to have a cone of your production database to perform testing in. Any change you make to your productions database should be tested first in your "sandbox" prior to being done in your production.

Important

DHIS2 version updates It is best to keep up to date on versions of DHIS2. There is a new version of DHIS2 released every four months. Typically, it is best to keep one or two versions behind the latest releases. If you do not keep up with the releases then you may find it difficult to find people to support your version of DHIS2 when you do have serious problems. Upgrades need to be planned well in advance. The same testing process outlined here for a new database can be employed when you have upgraded. Please remember that something almost always breaks or stops working when you upgrade a large production database so please be plan and test thoroughly before upgrading.

9. Deploy¶

There are many ways to deploy a CHIS. The deployment strategy is dependent on many things like training strategy, scale of the CHIS, etc. In general, there are two deployment strategies, "The big bang and a phased roll-out. Both strategies tend to ultimately cost the same amount of resources.

1. "The Big Bang" - This deployment strategy is often used in situations where development, testing, and initial training of users can or must be achieved quickly. This typically a CHIS small in scope with a lot of implementation support staff working initially on it. This strategy is preferred in situations where rapid crisis response is necessary like in a disease outbreak where community data is needed for epidemic control. Because of the rushed nature of this strategy, there will be technical issues that are identified post deployment that may hinder system use.
2. Phased Roll-out - This is the most typical approach to deployment of the CHIS where deployment is done region by region. Depending on the scale of the CHIS this may take years, but it will result in a much more stable, well tested CHIS.

Tiered Technical Support to CHISs¶

To provide support to the CHIS, the technical central unit must be able to capture, catalogue, and process all support requests, system errors, and flaws (also known as "bugs"). In most large information systems, a multi-tiered support system is required. Multi-tiered means simple issues are able to be addressed by lower level supervisors and more difficult or complex issues are moves up the tiers until they reach someone who is able to address them. Below is model of a CHIS tiered support system with an example issue that that tier may be expected to address.

Figure 4.6: Model of a CHIS Tier Support System

The vast majority of issues requiring support will be simple issues that should be able to be addressed by the first tier of support. Often this first tier is the CHW's direct supervisors. This tier should be able to address simple hardware and software issues. If the CHW supervisors cannot resolve the issue that will then have to escalate it to a higher tier.

Tier Two requests are addressed by are often addressed by district level or sub-national information systems officers, who are trained to manage system configuration issues and all advanced issues around the user interface, data imports and exports.

Tier Three requests are typically addressed by central level IT support persons. They should be able to respond to any back-end maintenance requests.

Many countries with very large-scale CHIS will have more tiers than three. While, smaller programs may have fewer. Regardless of the number of tiers, it is essential that support requests can be submitted by any user directly through either their DHIS2 instance, phone or by email. Using the messaging application, a user may message to the 'Central Technical Support' user group for their sub-national technical support group depending on how the tiers are composed. The "Technical Support" user group is typically made up of central level technicians. Similarly, they could call or email the technical team directly. Once a request for support has been sent to the technical team should acknowledges receipt of the request within a short time period like 12 hours

Best Practice

Have a 24-hour technical support hotline and support desk user group in DHIS2 maned by central level HMIS support staff. When users of the system have difficulties using the system if they feel that they have no avenue to receive technical support they may ultimately quite using the system. A 24-hour, toll free technical support hotline and support desk can give users a sense of support and resolve issues on the fly. Additionally, for CHIS users with a computer they can use the DHIS2 messenger to send support requests to the support desk user group. Below is an example of South Africa's guide to using their support desk build into DHIS2 messenger.

Some Design Guidelines for More Sustainable CHIS¶

In this section, we discuss some design guidelines to develop more sustainable CHIS. A running theme across these guidelines is our effort to shift the focus from a more supply side approach to one that is more grounded in a demand side based thinking that is human-centered and focused to reducing the data burden of CHWs and adding value to their everyday work. These design guidelines include:

1. Build the CHIS based on a participatory design approach
2. Have an architectural thinking to design at the core
3. Design CHIS based on an overarching framework of data governance and standards
4. Design CHIS to support local action rather than enabling more control and surveillance from the top
5. Build CHIS based on existing infrastructure conditions, that necessarily must be hybrid in nature
6. Plan for incremental evolution of the systems, and not seek to design based on a "clean slate" approach

These guidelines are now discussed in some greater detail.

Participatory Design Approach¶

A participatory design approach assumes that the end users are not just passive providers of data and recipients of systems that are "designed from nowhere," but are actively engaged in their co-construction together with the design and development teams. While traditionally, various techniques have been described to enable participatory design (storytelling, focus groups, interviews, mock ups, etc.), these techniques have been developed based on assumption of co-location, single systems, largely situated in single organizational settings. However, the diverse settings of CHIS in terms of scale, prior experience with computerization, levels of literacy and extreme diversity, require these techniques to be sensitively adapted and extended.

The advent of web-based systems implies that the designers and developers become more geographically and culturally remote from the users, and further challenges the use of traditional participatory design techniques. Appropriate approaches to enable participatory design need to be customized to existing contextual conditions, which may also involve the use of online methods coupled with some co-located means. This is of course easier said than done, given some of the challenges discussed, but needs to become an integral part of the project planning process.

Example

Case Study: Participatory Design in India A HISP project in rural India ongoing is aimed at building patient centric systems for primary health care. This project was carried out by a collaboration of the HISP team from the University of Oslo and India, and a public health team from the Post Graduate Institute of Medical Education Research (PGIMER), Chandigarh, India. This collaboration enabled the creation of multi-disciplinary expertise required for system design.

To ensure the active involvement of the CHWs a "living lab" was established in one rural clinic, which was a designated study area for PGIMER. The living lab has become a site for the design study team to work with the CHWs and medical doctors to understand their everyday challenges and needs. By situating the living lab in the clinic, the CHWs also developed a strong ownership of the system, as they saw themselves integral to its process of evolution, and both sides could mutually understand the perspective of the other. The developer team could gain insights into the world of the CHW which they otherwise would never have obtained through the use of traditional design approaches.

For example, during a discussion the CHWs said they wanted the system to generate the primary registers. This was a novel insight, as the assumed approach took the primary registers as a given to the situation, and started the design based on existing data collection formats. This insight structured the design of the system in a novel way, which when completed provided more value and increased job satisfaction to the CHWs.

The important takeaway from this excerpt is the need to develop approaches to design in context which represents the world of work of the CHW. The living lab is one such approach, and there will surely be others. In different contexts, appropriate approaches will need to be constructed to enable these processes of contextualized design.

Architectural Thinking at the Core of Design¶

Architectural thinking in simple terms implies a systems and holistic thinking which seeks to ensure that the different existing systems can "speak with each other" in a relatively seamless manner. This speaking with each other is not just a technical problem requiring technical solutions, but involves complex institutional challenges of getting health programs and people to speak with each other. This undoubtedly is more challenging than building the technical solutions, and needs to come as the primary effort.

Another characteristic of the architectural thinking is that the system development is seen as a long term and evolutionary approach, and thus decisions should not be taken based on a static and one time thinking. An implication here is not to take decisions at one point which will prevent you from taking other choices in the future which may become available and be preferred.

For example, taking the decision to use a proprietary platform may prevent you from building interoperability with other systems in the future. This requires a forward-thinking approach, which seeks to predict future informational requirements, and also be on top with technological trends, and what kind of new opportunities that come up in the future. The system design should ensure we are able to keep on top of these challenges and are able to leverage on the opportunities when they do come up.

Example

Case Study: Collaborative Design in the Living Lab

Taking another example from the living lab project, a starting point of the design was to first understand the different systems the CHWs were currently engaged with.

CHWs were dealing with 9 different systems (computer and paper based) which involved 22 primary registers, and 30 monthly reports, with a lot of overlaps and redundancies between them. A process of mapping the redundancies listed out all the data elements in these registers, identifying the existing duplicates and creating a consolidated list of all the non-repeating data elements. This list was then used to develop the metadata definitions to be customized in the DHIS2 database. Further, this metadata was then adapted to the national MDDS (Metadata and Data Standards) to ensure scalability. In this way, linkages between the different systems were identified, ensuring linkages at the data collection level, which then enabled generation of the primary registers, the main concern of the CHWs.

This process was carried out jointly by CHWs and the system designers, who as a team could identify unwanted or unused elements which would not have been possible by the designers alone. This process also ensured that the designed CHIS would be integrated with the everyday work practices of the CHWs, was primarily aimed at providing added value to CHWs through reducing their work burden. Further, it was designed to be expanded in the future, for example by aligning to the national standards, in terms of generating all required reports for upward reporting and to support local action.

An important takeaway from this excerpt is that system design is not just about creating technical artefacts as solutions, but should be grounded in the everyday work practices and artefacts in use by the CHWs.

Design to Support Local Action¶

Local action refers to all the work being carried out by the CHW, which includes all information related work which relates to the recording, reporting and tracking functions performed by the CHWs. Local action represents the CHW doing recording and reporting, as well as local analysis of data and taking steps to improve health services delivery. While analysis is an important aspect of the CHW work, and one which we actively seek to enhance, we should not lose tracking of the recording and reporting functions which the CHW is obliged to perform. Expecting her to enhance her action taking function, while ignoring her recording and reporting functions, will be unfair to the CHW as she will be reprimanded by her seniors.

An important aspect of the design process is to understand from the perspective of the CHWs what they consider relevant local action (spanning her three key functions), and what outputs she needs from the CHIS to support her different functions.

From the example given above of the living lab, a primary need of the CHW was to support the generation of primary registers, as that would dramatically reduce their work burden, and free up time for provision of more effective care. Such an approach also exemplifies the advantage of taking a holistic systems approach rather than a narrow program specific and standalone. The benefits of adopting a holistic approach influences all the different roles of the CHW and all the health programs. On the contrary, an isolated stand-alone approach enhances fragmentation with limited benefits.

Chapter 3 provides more specific example of local use, so we are not repeating those issues here. The reader is advised to read that chapter for more specific examples of approaches to enhance local use.

Adopt Hybrid Approaches¶

Hybrid approaches are those that cater to a multiplicity of settings, political conditions, and infrastructures. This is key to ensuring scalability and with it sustainability. Community conditions by design are variable, multiple, and relatively dynamic. The CHIS design process must necessarily be hybrid in nature and be capable of catering to this multiplicity. The hybrid approaches encompass technical, institutional and project management approaches.

For example, building a system that relies completely for its operations on internet connectivity only caters to a single environment -- the presence of continuous and reliable internet supply -- and is unable to functions in settings where this condition is not met. Such a system is unlikely to succeed in a scalable manner, as ideal internet condition is unlikely to be available throughout a province, or even all sub-districts within a district. An approach here would be to design a hybrid system which can run in both regions of internet availability or not. Allowing for offline data entry, and subsequent syncing of data with the server when internet is available, is a practical solution to deal with these multiple environments. The DHIS2 has adopted such functionality, which has contributed to its widespread use in a multiplicity of environments and settings.

Example

Case Study: Different approaches in South Africa and Cuba Different political settings also call for hybrid approaches. The HISP project in South Africa, experienced great success with bottom up, participatory approaches in the changing post-apartheid environment of where enhancing health worker environment was at the core of the health reform agenda.

This same approach when transferred to the HISP project in Cuba turned out to be dramatically unsuccessful as the environment was extremely top down, driven by the office of the President. In hindsight, in this environment, HISP should have first obtained buy-in from the top, used this buy-in to create spaces to work with participatory design approaches at the field level, and gradually build ownership using that approach. In the absence of top-down approval, the bottom were fearful of engaging with the alien approach of bottom up design of HISP, and reacted by rejecting the project.

Výstupem z této diskuse je potřeba nejprve analyzovat dané kontextové podmínky a poté identifikovat proveditelné přístupy pro návrh a implementaci. Buďte vždy otevření přizpůsobování a improvizaci na cestě a nebuďte dogmatickí vůči určitému přístupu, který mohl fungovat v jiném prostředí a časovém rámci.

Design CHIS based on existing strengths¶

Přístup HISP k designu CHIS vždy zdůrazňoval důležitost instalované základny, stávajících pracovních postupů a historie CHIS, která existuje, a snažil se ji v průběhu času vyživovat nebo kultivovat. Tento přístup využívá základ, že všechny systémy mají historii a minulost, a že existují hluboce vestavěné systémy a lidské chování a postoje, které nelze nikdy odstranit.

Tento přístup HISP je opakem přístupu „čistého listu“ popularizovaného manažerskými konzultanty v Severní Americe v devadesátých letech a operacionalizovaného pomocí metodologie „reengineeringu obchodních procesů (BPR). Tento čistý přístup byl adaptován designéry CHIS tam, kde nejsou citliví na to, co již existuje, ale neměl velký úspěch, jako když byl přijat v Etiopii na začátku roku 2000 během reformního procesu zdravotnictví.

Dominantní předpoklad vývoje systému BPR je založen na čistém přístupu, který

1. Snaží se „vymazat“ stávající procesy a systémy a začít od nuly, čímž vytvoří čistý štít.

2. Předpokládá, že stávající pracovní postupy a postoje CHWs jsou iracionální, nikoli moderní, je třeba zabít a nahradit je technikami a technologiemi, které jsou modernější a racionálnější.

Exampel

Case Study: CHIS design in Mozambique A HISP project was introducing DHIS in the community health system in Mozambique While conducting training at the community level, various strengths of the CHWs were seen.

1. CHWs had strong abilities to multi-task, developed through decades of working in extremely resource constrained environments. For example, they could engage in providing care in addition to doing administrative tasks at the same time.
2. CHWs were very strongly linked to multiple local and non-work environments, such as the church. So, when the printer of the health facility was not working, they would go to the nearby church to print out the urgently required report.

Instead of seeing the practices of the CHWs as being irrational and impediments to the introduction of new systems, it was recognized that these should be seen as potentials that should be leveraged upon to support the system introduction.

This exposed the limitations of existing approaches to design and implementation using the "clean slate" approach.

Závěrem z této diskuse je potřeba vážně zvážit historii v procesu návrhu systému, jaké jsou pozitivní a negativní potenciály, které s tím přicházejí, a jak lze pozitivní potenciál postupně využít a kultivovat v průběhu času.

Interoperability with DHIS2 in CHIS¶

Why Interoperability?¶

Nastavení komunity mají zvláštnosti, jako je slabé internetové pokrytí, nerovnoměrná infrastruktura a převážně manuální systémy, které velmi ztěžují nasazení kompletního webového systému. Může také existovat několik již existujících systémů vlastněných různými zúčastněnými stranami, které vykonávají odlišné funkce a které mají vysoký stupeň uživatelské akceptace. V důsledku toho existuje značná potřeba najít alternativní způsoby prostřednictvím interoperability, jak přenést data do DHIS2, aby mohla probíhat požadovaná agregace, bylo možné vytvořit analytické řídicí panely a sledovat péči o pacienty. Interoperabilita se zaměřuje na sdílení dat mezi dvěma systémy, aniž by je rušila. Naproti tomu integrace zahrnuje sloučení dvou systémů do jednoho, takže pokračuje pouze jeden systém a druhý již není potřeba. Vzhledem k tomu, že obecně dojde k neochotě vlastníka systému vzdát se svého systému, bude integrace v kontextu CHIS často narážet na odpor.

V souhrnu lze interoperabilitu vnímat jako reakci na následující případy použití:

• Systémy jako ODK a CommCare se používají v různých kontextech ke shromažďování individuálních a agregovaných dat, a to musí být propojeno s DHIS.
• Díky snadné přenositelnosti a lepšímu pokrytí mobilní sítí (než internet) lze ke sběru dat použít mobilní telefon, který lze nejsnáze přenášet prostřednictvím SMS. Tato SMS data je pak potřeba importovat do DHIS2 a dále zpracovávat.
• Tam, kde dominují manuální systémy, lze k zadávání dat použít listy Excel a poté je třeba tyto soubory Excel odeslat do DHIS2 k dalšímu zpracování.
• Community based data could also be collected in hospital systems, where residents go to receive referral care. This hospital data, typically collected in an Electronic Medical Record kind of system, then also needs to be interoperated with DHIS2.

We provide examples of use cases that represent these above conditions, and then provide a technical overview of how interoperability was achieved with DHIS2. For each of these use cases, we also present some technical guidelines on how interoperability can be achieved in other contexts.

Use Cases of Interoperability¶

Open Data Kit (ODK) -- DHIS2¶

The National Institute of Epidemiology, Chennai India is building a system on DHIS2 for fever surveillance. The aim is to record all cases of fever reported in a district to understand epidemiological patterns that underlie these fever cases. For this, they need to capture name based data on fever surveillance which they are doing using ODK. Each case records required demographic information and fever details. This data is then required to be pushed into DHIS2 for further tracking, generation of hotspots and creating required reports and indicators displayed through the dashboard. Thus, building interoperability between the ODK and DHIS2 was a core task in the system development process.

CommCare -- DHIS2¶

In Nepal the Hellen Keller Institute (HKI) is using DHIS2 as a nutrition tracking system. Derived from census population of households in selected districts of Nepal, DHIS2 captures individual level data on demographics and selected nutrition parameters. Based on this data interventions are carried out and impact on nutrition parameters need are monitored at the individual level. To collect this programmatic data HKI is using CommCare. The programmatic CommCare data needs to be interoperated with the census based data in DHIS2. Furthermore, DHIS2 is also being used for various other data reporting formats for other program needs. There is thus the requirement to build a common warehouse of data where these multiple programs data together with the nutrition data could be analyzed for cross-cutting indicators, and displayed through attractive and easy to use dashboards.

Excel Import -- DHIS2¶

While the use of Excel sheets for community level data is a common use case in the context of CHIS, the use case discussed concerns comprehensive case based management of malaria. This project, implemented in Odisha state in India, involes the collection of data on malaria cases in a name based format using Excel due to low internet availability. The Excel files with name-based data is periodically sent to the higher authorities through emails or pen drives etc. At central levels the excel file is converted into a CSV and manually imported into DHIS2 via the data import application. DHIS2 is then able to automatically aggregating to higher levels in the HMIS. The DHIS2 thus contains both name based and aggregate data. Thus, there is a requirement to send the data in these Excel sheets to DHIS2 for monitoring and maintaining the data quality and also enable the connection between the different elements of entire longitudinal record of the patient. The challenge here was to develop a methodology for importing the Excel data into DHIS2.

SMS Data Import -- DHIS2¶

The use of SMS based reporting is another common means of data collection and transmission in community health settings. WHO India initiated the use of SMS based system for supporting their Mass Drug Administration for LF in a campaign spanning 34 rural districts of India over an intensive one week period. SMS rather than web-based transmission was selected because many of the CHWs did not have the resources to access smartphones, so were not oriented to its use. Further, SMS was selected because data needed to be collected only for few elements (such as number of households visited, males, females and children administered the drug, and side effects observed). In this campaign, the CHWs would go house to house administering the drugs, recording the data on their phones, and then sending it by SMS which was received by the DHIS2, where dynamic dashboards were constructed to monitor coverage by day and geography.

Open MRS and DHIS2 Interoperability¶

OpenMRS is the platform on which an EMR was customized for an integrated hospital management system for district hospital in Himachal Pradesh, India. The system collects individual level data as a patient goes through different encounters in a hospital including registration, billing, OPD, IPD, lab tests, pharmacy etc. This individual level data needs to be aggregated (by hospital, department, period, etc.) and then sent into DHIS2 where aggregate reports, for morbidity and mortality can be prepared, hospital management and administrative indicators (for example, average length of stay and bed occupancy rates) can be generated, and comparisons across the different hospitals in the state can be made. This would not have been possible through the OpenMRS system alone, and so the technical task involved building interoperability between the two applications, and ensuring a process to synch the two databases at predefined intervals.

After presenting these different use cases of interoperability with DHIS2, in the next section the technical approach for this is discussed including guidelines for implementing the interoperability solution.

Technical Approach for Interoperability¶

For ODK and CommCare Cases¶

A similar process of building interoperability was followed in both the cases. A tool (Data Motor) was designed that requests for data from the CommCare/ODK application. Data is pulled out from the API through this pool and is pushed through the API again to DHIS2 application. The diagram below depicts this process.

Figure 4.6: DHIS2 Interoperability Model with CommCare and ODK

Guidelines for Implementation¶

1. Identify "data points" which needs to be shared from the data collection system.
2. Find out where they fit in the data model of the system from which they are to be pulled.
3. Find out where they fit in the data model of the system into which they are to be pushed.
   • In case of DHIS2 these are Data Elements, Periods and Organization Units
   • In case of ODK and CommCare these are questions/data entry prompts.
4. Map the two data models based on a unique identifier between the two.
5. Make the data motor
   • Fetch data from one data collection system,
   • Restructure the data to fit the data model of the other data collection system
   • Push the restructured data in the other system
   • Keep unique identifier in both systems for integrity checks
6. Set up the data motor to auto run periodically
7. Keep a log of all activity that the motor does for monitoring and debugging.

Excel Import to DHIS2¶

An Excel micro has been created in DHIS2 with a predefined Excel template. The data from Excel is mapped to UIDs for data elements, organization units and periods for which the data which needed to be imported in DHIS2. The mapping in Excel should only have to be completed one time. Once the mapping is done the data can be maintained in the Excel sheets and imported in DHIS application when internet is available. The data is sent to DHIS2 through the UIDs being mapped in the Excel sheet and sent to respective program and program stages in DHIS2 in the case of name based data.

Guidelines for Implementation

• To maintain the data quality, minimum open text fields should be used in the format. More of drop-down options should be created so that user can select the required options which can be easily linked to DHIS2 data values.
• The sheet should be protected so that the user cannot add any new fields or make any changes in the application.
• Validations same as in DHIS2 need to be built in the Excel sheets.
• Organization unit codes are a preferred option for sending the data to DHIS2 to avoid any mismatch in the organization unit names.
• It is important to have a unique identifier for each record in DHIS2. This unique identifier can then be used to link the longitudinal records (program stages) of the patient so that the patient can be updated as and when visits are made and duplicates are not created.

For OpenMRS-DHIS2 Interoperability¶

The interoperability module from the EMR based on OpenMRS to the DHIS2 was developed by the HISP India team to support an architecture where the name based encounter data was stored in the individual hospital's server, would be aggregated through queries and the data would be moved to the state repository (DHIS2) through a data exchange module. The architecture envisaged was that the name-based data was retained at the facility and aggregated data moved on to the state DHIS2 portal through the data exchange module.

The interoperability standard (SDMX - Statistical Data and Metadata Exchange, initially promoted by WHO and later replaced by the ADX standard), data was exchanged between OpenMRS and DHIS2, and all metadata (data elements and facilities) were synchronized taking DHIS2 as the base and aggregated information into it using DHIS2 API services on periodic basis. The reports exchanged included all national disease program reports, reports on disease profiles for the population, and stocks and inventory reports. Implementing this module was a tremendous challenge. Technically, creating the data transfer required writing hundreds of queries to aggregate and push the data into DHIS2. Initially, it was done manually, where some staff had to just push the export button. When this was not done regularly, this transfer process was automated to enable it at a fixed time everyday where the data would be synched. This too was problematic, because of the intermittent and unreliable internet and power supply.

The architecture for this data exchange is sketched out in Figure 4.7.

Figure 4.7: DHIS2 interoperability with OpenMRS

Guidelines for Implementation¶

• All the data which needs to be transferred to the DHIS2 requires to be defined as data elements in the DHIS2. Data sets need to be created for the aggregate reports required.
• All indicators need to be created in the DHIS2, and also all numerator data (such as number of beds and number of doctors) need to be stored in the DHIS2 which are then used for the generation of indicators.
• Queries need to be written to aggregate the name based data from the OpenMRS database, and then post it into DHIS2 as the defined data elements.
• Reports and dashboards need to be customized in the DHIIS2
• An automatic scheduler should be created to enable periodic data exchange.

SMS Import in DHIS2¶

SMS gateway and APIs are required for receiving the SMS in the DHIS2. If feedback messages also need to be sent (to confirm receipt or not of the SMS in the DHIS2) to the user, an API for sending messages will also be required. The messages need to be sent on a specific number and the same could be read for a predefined set of data items. Separator such as dot (.) or space ( ) could be used for separating the data elements while sending the messages to make them easier for the user to understand. The phone number of the users need to be registered for the respective organization units to which they belong, such that when the SMS is received from the same number, it can be registered at the organization unit.

Guidelines for Implementation¶

• While using the SMS functionality, the data elements to be reported should be minimal for the user to remember the sequence. The sequence and format should be provided written on paper to the CHW for ease of use.
• It is significant to have the phone numbers registered for all the users, and it should be ensured that the user sends the message through the same numbers for the data to be registered at the correct organization units.
• The pictures below describe the different screen shots the user will see in the process of sending the SMS and receiving the confirmation message.

Figure 4.8: Example SMS Import into DHIS2

Use cases¶

India Use Case - Mobile Based Reporting by CHWs¶

Mobile based reporting is a vital part of CHIS in many contexts. In this section, we discuss three different modes of mHealth based reporting from the community level in India.

1. SMS based reporting for HMIS in Punjab, India.
2. SMS based reporting for supporting cancer survey in Punjab, India.
3. GPRS based reporting for HMIS in Himachal Pradesh, India.

In each case we provide details of the technology, the implementation and capacity building processes, the issues and challenges faced and how they were resolved.

SMS-Based Reporting for HMIS in Punjab, India¶

In 2011, the national MoH initiated a pilot project across 5 blocks in 5 different states covering about 200 CHWs, to test the technical efficacy of mobile based reporting from the community level.

A simple JAVA based application was developed in J2ME and installed in the mobile phone of the CHW. A modem with a SIM was installed at the block (sub-district) level to receive the messages. A software "SMS Listener" was installed in the computer of the Block Program Manager along with the offline DHIS2 application. When the CHW sends the report through the mobile application, it comes through a SMS. The SMS listener installed received this SMS in Binary form and imported the data into respective organization unit by recognizing the mobile number from which the message has been received. The mobile number of a particular health worker was entered in DHIS2 offline application for their respective organization units. Some useful lessons were learnt from the pilot. There were technical issues encountered such as the clogging of modems, signal issues in hilly areas, and some data loss. Some CHWs were reluctant to use the mobile as they felt more comfortable with paper based reporting.

Overall, the pilots were seen to be successful, and two states Punjab and Himachal Pradesh came forward for a full statewide scaling for this mobile based reporting

mHealth-Based Reporting for HMIS in Punjab¶

Punjab state has about 5000 CHWs, with each sub-center having 2 ANMs (Auxiliary Nurse Midwife), one regular and the other contractual. The state provided each ANM with a mobile phone (Nokia 2330 Classic) to enable reporting the monthly routine HMIS data.

Unlike the pilot which was based on the offline DHIS2, Punjab went for an online application, developed in J2ME (JAVA) and in Punjabi language. The application was installed via Bluetooth in the mobile phone of the ANM. This was a simple SMS based solution. It included three forms to be filled by the ANM: Daily Reporting, Monthly 1 & Monthly 2. After filling these forms, the ANM sent her data through SMS on a number for which the SIM was installed in the Modem at the state's server. After importing the data in DHIS2 an Acknowledgement SMS was is sent back to the ANM for the confirmation of the report. There were two modems installed at state server one modem each for 10-10 districts.

Figure 4.9: Example J2ME Data Entry Application

Jednalo se o online aplikaci DHIS2 se třemi datovými sadami. Mobilní číslo každého ANM bylo registrováno na podcentru, na kterém bylo ANM zveřejněno. Jakmile je zpráva přijata z čísla, je převedena do souboru XML a importována do DHIS2 pro příslušnou organizační jednotku, na které je příslušné číslo registrováno. Vzhledem k tomu, že každé dílčí středisko mělo dvě ANM, byly pod každým dílčím střediskem vytvořeny další dvě organizační jednotky ANM1 a ANM2 a čísla byla zaregistrována v příslušných uživatelských jménech. Tento mobilní projekt běžel paralelně se státní aplikací HMIS na DHIS2 a očekávalo se, že po několika měsících reportování budou všechna data komunity v DHIS2 přicházet pouze přes mobilní reportování.

Spolu s mobilními telefony bylo poskytnuto připojení CUG, které zahrnovalo kredit 200 Rs pro ANM, aby bylo možné hlásit SMS spolu s možností bezplatného volání.

Figure 4.10: Punjab Use-Case Data Flow Model

Proces implementace zahrnoval následující kroky:

• Pořízení hardwaru: Nokia 2330 Classic se SIMS kartou a modemem modelu EZ-SMS pro příjem SMS.
• Finalizace formátů: Byly dokončeny tři formáty: denní datová sada, měsíční 1 a měsíční 2 s 10, 56 a 83 datovými prvky.
• Klasifikace ANM: ANM byly klasifikovány jako ANM 1 a ANM2.
• Instalace: Soubor JAR tří datových sad byl nainstalován pomocí Bluetooth do 5000 mobilních telefonů a nalepením nálepek na zadní stranu mobilních telefonů se jmény ANM a podcentry. Tento proces probíhal v čele státu po dobu jednoho a půl měsíce.
• Distribuce mobilních telefonů v okresech: Po instalaci byly mobily zaslány do příslušných okresů a před školením distribuovány do ANM.
• Příprava tréninkového manuálu: Poté byl připraven tréninkový manuál v pandžábštině, který demonstroval použití aplikace prostřednictvím snímků obrazovky a diagramů, a ty byly distribuovány během tréninku
• Budování kapacit: Školení o používání aplikace byla prováděna po dobu 2 měsíců a týkala se 4545 zdravotnických pracovníků a byla provedena na úrovni státu/okresu/bloku/subcentra. Byly vytvořeny dvoučlenné týmy pokrývající 5-7 okresů. První den proběhl okresní TOT, po kterém následovaly blokové tréninky.
• Podpora uživatelů: Roční podpora uživatelů byla poskytována prostřednictvím 3-členného týmu umístěného v ústředí státu.

Issues and Challenges Experienced¶

Daily Dataset: Zpočátku ANM vykazovaly nelibost vůči aplikaci, což se postupem času zjednodušilo. Klíčem k této nelibosti bylo denní hlášení, které obsahovalo datové prvky představující aktivity prováděné převážně ve středu v relacích EPI, což znamenalo, že jinde než ve středu byly prvky hlášeny jako nuly. Tento vzorec, jak se ANM domnívali, by správci vnímali tak, že se v jiných dnech flákali. Aby se administrátoři vypořádali s tímto rostoucím odporem, museli nakonec zrušit každodenní zpravodajství.

Věkový faktor: Starší ANM byli rezistentní, protože předtím nepoužívali mobilní telefon. Přimět tyto ANM naučit se aplikaci byl tedy obtížný úkol.

Další problémy: Došlo k problémům se signálem, problémy související s vyvážením a zpožděním v potvrzovacích zprávách ze strany serveru kvůli zatížení aplikace

Zablokování modemu: Modemy přijímaly denně téměř 5000 SMS, což značně zatěžovalo stavový server a modem, což zdržovalo odeslání potvrzovací zprávy, což vyvolalo paniku mezi ANM, zda jejich hlášení byla přijata nebo ne. Zprávy také začaly selhávat, protože mobilní operátor si nepřijaté zprávy nechal na svém serveru pouze 3 dny. Byly nainstalovány další dva modemy pro odesílání potvrzovacích zpráv, aby bylo možné sdílet velké zatížení.

Figure 4.11:A district wise data status percentage showing the reporting percentage in initial days.

Procento stavu dat podle okresu zobrazující procento hlášení v počátečních dnech.

Klíčové věci k ponaučení:

• Zvýšení frekvence hlášení jen proto, že to technologie umožnila, není dobrý nápad, protože to zvýšilo smysl sledování pro ANM.
• Zdálo se, že modemy nejsou dostatečně vybaveny k tomu, aby zvládly rozsáhlý SMS provoz, a řešení SMS brány by bylo vhodnější pro projekt v plném rozsahu.
• Stát zvažuje aplikaci na platformě Android pro hlášení HMIS.

Punjab SMS-Based Cancer Survey Reporting Use Case¶

Po úspěchu rutinního hlášení HMIS v roce 2011 stát zahájil v roce 2012 nový projekt založený na SMS pro průzkum rakoviny pro:

• Vytvářet povědomí o varovných příznacích a symptomech rakoviny.
• Umožnit včasné odhalení onemocnění na základě příznaků
• Identifikovat výskyt onemocnění (skutečný počet případů) pro další plánování

Proces implementace průzkumu je stručně popsán:

• Průzkum ve venkovských oblastech prováděli CHW, zatímco v městských oblastech studenti ošetřovatelství a lékařské fakulty
• Průzkumník šel do každé domácnosti ve své oblasti
• Průzkum byl proveden pomocí dotazníku obsahujícího proformy: První pro zachycení základních informací o každém jednotlivém členu domácnosti v domácnosti, jako je jméno, věková skupina, vzdělání a rodinná anamnéza rakoviny atd.; Dva, pokud byla u nějaké osoby shledána rakovina pozitivní nebo s příznaky rakoviny, byly shromážděny podrobnosti specifické pro toto onemocnění a nahlášeny prostřednictvím mobilního telefonu (JAVA SMS aplikace) do DHIS2.
• Pro průzkum byly použity stejné mobilní telefony (Nokia 2330) a modemy.

Byl použit dříve existující seznam starých mobilních čísel a poté byla přidána nová použitá čísla a zaregistrována v aplikaci DHIS2. Geodet odeslal SMS konkrétního případu, která byla převedena do XML souboru a následně importována do příslušné organizační jednotky, kde bylo vygenerováno Unique ID daného případu a zasláno zpět na potvrzovací SMS. Inspektor poté zaznamenal toto jedinečné číslo na konkrétním formuláři, aby mohl případ sledovat v online aplikaci. Mobilní aplikace se používala na venkově, zatímco v městských oblastech, kde byl internet spolehlivější, se data zadávala přímo do online aplikace.

Data flow¶

Figure 4.12: Data Flow from Sub-Center Level to State Level.

The Capacity Building Process¶

Před celostátním zavedením byl proveden pilotní projekt v jednom okrese na 2 blocích a byl zahájen podobný proces implementace jako HMIS. Byl ustaven 150členný výcvikový tým a celostátní výcvik byl ukončen za 2 týdny.

• Školení probíhala na okresní centrále nebo na úrovni bloků
• Na každém stanovišti prováděl školení dvoučlenný výcvikový tým.
• Účast účastníků školení byla brána v úvahu
• CHW shromáždili mobilní telefony, když přišli na školení
• Jeden člen provedl instalaci aplikace, zatímco druhý se zaměřil na školení pomocí emulátoru, po kterém následovala prezentace v PowerPointu
• V praktickém sezení byl terénní pracovník vyškolen, jak vyplnit všechna pole obsažená v datové sadě a odeslat data přes mobil.
• Pro městské oblasti byl formulář navržen na DHIS2 Tracker. Individuální záznam byl zadán na obrazovce registrace pacienta a výstup ve formě reportů je možné prohlížet prostřednictvím reportů dostupných v aplikaci

Data z venkova prostřednictvím mobilního hlášení byla provedena hladce, ale stále přetrvával problém se zanášením modemu. Pro vyřešení tohoto problému byl na státní serverovnu umístěn jeden správce serveru, který v reálném čase monitoroval provoz SMS. V městských oblastech nebyl uživatel schopen uložit data v online aplikaci kvůli obrovské databázi. Aby se to vyřešilo, byla zavedena funkce importu aplikace Excel pro zadávání dat proforma 2 do listu aplikace Excel, která byla poté stažena do DHIS2.

Himachal Pradesh SMS-Based HMIS Reporting Use Case¶

Po jednoblokovém pilotu stát souhlasil s celostátním pilotem. Poučení z Paňdžábu vedlo ke změně z SMS na aplikaci založenou na GPRS. Některé poznatky z pilotního projektu HP zahrnovaly:

• Dobíjení GPRS bylo dražší než SMS
• Slabá konektivita GPRS v kopcovitých a odlehlých oblastech.
• Stát nedal ANM telefony a byly použity jejich stávající telefony.
• Řešení založené na GPRS nebylo kompatibilní s mnoha uživatelskými telefony a také nekompatibilní s prohlížečem Opera mini. Z 201 mobilních telefonů bylo kompatibilních pouze 74 telefonů, tj. pouze 37 %.
• ANM zjistili, že je obtížné provozovat webové řešení a nastavení GPRS, které se má provést na telefonu, bylo pro ANM těžkopádné.

Po zjištěních z pilotního projektu stát souhlasil s aplikací J2ME. Pro hlášení byl vybrán formulář Měsíční dílčí centrum. Stát se následně rozhodl koupit telefony pro ANM a zvolil Nokii C1-01 a každému ANM bylo poskytnuto 50 Rs za nabíjení. Podobně jako v Pandžábu byla vyvinuta aplikace založená na SMS J2ME pro odesílání zpráv. Vybrané formáty však nebyly pouze pro dílčí centrum jako v Paňdžábu, ale bylo vybráno několik formátů:

• SC Form-- For sub center health worker (monthly)
• IDSP – pro pracovníky v podcentru (týdně)
• Formulář 1 primární zdravotní péče a formulář 2 – pro zdravotníky primární zdravotní péče (měsíčně)
• Formulář 1 CHC a formulář 2 CHC – pro zdravotníky CHC (měsíčně)
• Úmrtnost -- pro zdravotníka SC, PHC, CHC (měsíčně)

JAR files for all these formats were created, and installed on respective facility phones.

SMS Gateway Solution¶

From the learnings of Punjab implementation, it was found that modem was not a good choice for a full state wide roll out hence instead of Modem, SMS gateway solution was used.

• State's Department of Information Technology (DIT) already had a SMS gateway solution bought from a private player.
• The implementers contacted this provider to build the integration with DHIS2. But then the State changed the provider to the government IT department. This required the integration to be redone.
• The server and SMS gateway were both placed in the state IT office which created many logistical challenges.
• The final application integrated with SMS gateway was deployed.

Some of the issues experienced included:

• In testing it was found that the government IT department did not support the compressed SMS which was previously used in Punjab.
• The server only supported the basic SMS length of 160 characters and for some operators it was only 110/120 characters. This was often insufficient, as our SMS was prefixed with a keyword HP NRHM.
• At the 161^st character, the server could not understand the second SMS which was not prefixed with HP NRHM and as a result the second SMS got lost, leading to complete data not being reported.
• So, the SC form was divided into three parts containing 100 characters each, but was not an optimal solution to divide one form into three parts.
• The application was then reworked with the second SMS at the 121^st character also being prefixed with the keyword HP NRHM. The second SMS would cut at 121^st character and the reporting became smoother.
• In some of the blocks, the ANM was responsible for multiple sub centers, but in the application only one mobile number could be assigned to one organization unit. To address this, a 4-digit Facility Code was introduced for every organization unit, which enabled one health worker to report from multiple organization units from the same mobile phone.

Figure 4.13: ANMs going through the application in one of the training sessions in Kangra District.

Capacity Building Process¶

• The training was done mainly at block level, through a 2-3-person training team.
• Attendance of training participants along with their mobile numbers was taken.
• Health workers collected their mobile phones when they came for training.
• One member was responsible for the application installation while the other was for the training on formats and the application.
• Mobile numbers were registered in the respective organization unit in DHIS2.
• One member sensitized the health worker to send the report using mobile phone through the Emulator, followed by hands on training.
• Orientation was provided on the formats, and described in the training manuals which were distributed to all health workers.
• Respective facility codes were also given to the health workers, and they were asked to send a dummy SMS to check the working of the application.
• Then this dummy data was deleted from the server side and the health workers were asked to start their monthly reporting on the reporting date.

Issues and challenges¶

• The vendor of SMS gateway was changed implying a rework of the whole integration process.
• The SMS was relatively expensive on the short code.
• The short code was changed which implied changing the short code in 201 mobile phones again
• Deployment and maintenance of the server was difficult due to the strict government norms such as no remote access to the server was provided, requiring a physical update to the server each time.

The table below summarizes the differences in approaches to the mobile health application in Punjab and Himachal.

Punjab	Himachal Pradesh
J2ME SMS based	J2ME SMS based
Modem	SMS gateway solution
Only SC Form	Multiple forms for SC, CHC, and IDSP form S
State initiated the training dates	State conducting their own HMIS trainings along with Mobile district TOT. In district TOT dates for block trainings were taken. Application is being installed in block trainings itself
Postpaid CUG Tariff plan of Airtel	Pre-paid , no CUG, BSNL
Training only given to ANM and supervisor.	All health workers and supervisors were trained.

Figure 4.14: Difference among India Use Cases.