HII Design Problems in Vietnam

As discussed earlier, HII is a subset of II, and thus will also share the bootstrapping and adaptability design problems. While these design problems could be effectively met based on the use of the existing II design principles and design rule, my research identifies four additional design problems.

6.1.1 The scaling and sustainability design problem

This problem refers to a common phenomenon of HII in developing countries where many systems, despite huge investments, end as pilots; in other words, they could not scale. The scaling problem can be seen as the failure in transferring local successes to other settings (Braa et al., 2004). Because it is often too expensive to maintain an HII that is only implemented on a small scale, the HII faces threats of death after external funding is over. One example from my empirical work illustrating this phenomenon was about a department within the MoH, which received significant funding from external donors through several projects to build a health management information system (HMIS). Thanks to the funding, many systems were built, yet they were piloted on a very small scale, i.e., one or two districts. However, all of the systems soon became inactive and were forgotten. In 2012, I was personally contracted by a European donor to build a system to track gender equity indicators for Vietnam. After completion, this system was transferred to the MoH, but since that time, I have not heard anything about how the system was used (does not imply much). Recently, a department within the MoH had a project to build a national Electronic Medical Record (EMR) exchange framework with a budget of nearly 5 million USD. A large and complex system was built with many components to load, transform, and store patient data. It was piloted in two big hospitals, but it has been silent since.

Apart from the scaling issue, from my empirical investigation, I also found that there were many HII efforts which were stopped even after being largely scaled and providing useful

74

functionality for both hospitals and health managers. Medisoft was such an example. This software was developed in 2000 and quickly attained national scale thanks to great support from a Deputy Minister of the MoH. It was implemented in all hospitals throughout the country to collect basic patient admissions data, and the software was legitimized by an official Circular.

However, the system soon lost its momentum when there was conflict between the company and the MoH regarding copyright of the source code. The stopping of support from the MoH soon made the system obsolete. In the cases that I was directly involved in, such as Patient Survey and Patient Complaint, the challenge of sustainability was significant. For example, the Patient Complaint System, which was built and implemented in all hospitals, had become a useful tool to improve hospital quality and patient satisfaction. However, its implementation was stopped because there was a lack of financial resources to hire data entry clerks who transferred complaints from patients to the system so that these complaints could be disseminated to respective hospitals.

6.1.2 The all-or-nothing design problem

This design problem refers to the particular requirement that HIIs are only useful when they are implemented in “all corners of a district, to all districts in a province, and to all provinces in a country” (Braa et al., 2004 , p.340), offering full-coverage data. This is becoming increasingly important with the efforts by governments in many countries to address the issue of health equity and insurance for all, such as in South Africa and Thailand (Braa et al., 2004), and with the current focus on universal health coverage. One example from my empirical work illustrating this need for scale is the case of the Communicable Disease Reporting. During 2010, the General Department of Preventive Medicine developed a comprehensive communicable disease reporting system with substantial support from international donors through a bottom-up and participatory approach (Ehn, 1993). The implementation of the system was steadily expanded from the first pilot province to 10 provinces and then to 23 provinces (over 63 provinces of the country). This scaling process was carried out incrementally and step by step because it depended heavily on financial support from the donors. As a result, when the measles outbreak occurred in early 2014, the system could not provide MoH leaders with sufficient data to make decisions. This, however, created opportunities for other systems with a better scaling strategy—i.e., Epidemic Notification System—to step in and fill a yet-to-be-taken functional role (Nielsen and Sæbø, 2016). Another example relates to the early approach of HISP when it first came to Vietnam in 2004 through the introduction of the Ministry of Science and Technology (MOST). After a number of meetings, HISP was assigned to work with two

75

provinces to pilot its DHIS software, which at that time was in version 1.3. The pilot lasted for nearly 10 years but yielded very little visible outcome and quickly fell into a vicious circle of non-use (Braa et al., 2004). Because the pilot was on a very small scale, i.e., in 2 districts in Ho Chi Minh City and 2 districts in Thua Thien Hue province, it could not give provincial health managers data that they need, resulting in the health mangers not taking ownership of the system and not wanting to invest in making it fully implemented (Braa and Sahay, 2012b).

6.1.3 The competing systems design problem

The competing systems problem partially refers to the fragmentation of HII in developing countries where multiple donors invest in systems for their own reporting and management purposes and ignore the existence of other similar systems. This problem is escalated when multiple systems offering similar and overlapping functionality attempt to exclude each other, i.e., through encroachment (Nielsen and Sæbø, 2016). Actors involved in such a competition are often backed by various donors, companies, governmental agencies with competing interests.

In Vietnam, Medisoft software was under constant attack by other software vendors who blamed them for monopolizing the hospital management software market. In the case of the communicable disease reporting system, the software system owned by General Department of Preventive Medicine, and developed and implemented based on support from external donors, was replaced by a system developed by a giant state-owned telecom conglomerate to become the Communicable Disease Reporting System. The reasons for substitution, however, were often not clearly stated. In another development, through a modified circular, General Department of Preventive Medicine managed to mandate hospitals to report communicable diseases-related data in its system rather than depending on the Epidemic Notification System.

The General Department of Preventive Medicine’s Communicable Disease Reporting System could have served the functional role that the other systems did, including the Epidemic Notification System managed by Vietnam Administration of Medical Services, and thus excluded other competing vendors.

While it is argued that competition is healthy for innovation and evolution, the competition between software systems in public health is more acute than in other sectors due to a number of factors. First, the number of potential customers, e.g., clinics, health centers, is fixed and

76

hard to expand. The market for HII is thus very limited. Second, the MoH is usually the agency that chooses a particular software system for the national healthcare sector. There are rare occasions on which more than one solution is allowed to stay for the same purpose, e.g., different provinces may use different systems. Additionally, the culture of the Vietnamese people being notoriously very poor on collaboration and teamwork was influential (Nguyen and Johanson, 2007). The concept of collaboration or buying an existing software solution was almost non-existing. Rather, when a contract winner is identified, a new system is likely built from scratch.

6.1.4 The information use for action design problem

Information use for action is one of the motivations and main purposes of building HIIs (AbouZahr and Boerma, 2005). However, when the task of collecting data and generating information is addressed, developing countries continue to face the challenge of using information in decision making (Braa et al., 2012). With the Medical Licensing System in Vietnam, there was no clear plan on how to use data of health professionals for human resource development and planning. There were, however, casual inquiries by various institutions regarding several indicators such as the number of doctors in different specializations and the gender distribution of health professionals. In the case of the Hospital Quality Evaluation System, the data from more than 3,000 quality criteria, which were evaluated by all hospitals and their provincial health departments, was used modestly. Only a few basic indicators were generated, such as the ranking of hospitals based on their quality. Additionally, there were also lots of data about things like medical equipment, medical service and drug use that have not been used for action.

Table 9 summarizes the emergent design problems and empirical examples illustrating them:

Table 10: Summary of HII design problems

Design problem Description Empirical examples

Scaling and Sustainability Problem

Local successes of HII find it hard to be replicated to other settings and cannot continue after the external funding is over.

- The EMR exchange system built by the Department of IT, MoH could not go beyond two pilot hospitals.

- The pilot of DHIS2 in 2 districts of 2 provinces could not be further expanded.

77

- The Patient Complaint System could not continue due to lack of funding.

All-or-Nothing Problem

Often linked with the political visions of promoting equity in access to health services, HIIs are only useful to health managers if they can provide data for the entire catchment area.

- The communicable disease system in only 23/63 provinces could not provide useful data for MoH leaders.

- The licensing system could not help to verify and remove duplicate applications before scaling to national level.

Competing Systems Problem

Multiple actors promote competing systems that offer overlapping IT functionality.

- The system developed by BigFirm attempted to exclude the Medical Licensing System

- The Communicable Disease Reporting System funded by international donors was replaced by a new system developed by a local state-owned company

Information Use Problem

Successfully implemented II generates information that is not used in decision making.

- Data from many systems such as Hospital Inventory System, Hospital Quality Evaluation System has not been used for strategic planning.

After locating the emergent design problems, the next section discusses design principles to address those problems.