Design Principle 1: Create an attractor through early successful adoption

This principle aims to address the problem of scaling and sustainability. When discussing the problem of scalability of HIIs in developing countries, Braa and Sahay (2012a) proposed the concept of attractor, which is inspired by Complex Adaptive System theory, to emphasize the role of initial success in attracting more and more users. I argue that the scaling process can be kick-started if such an attractor is created early. In the context of HIIs in developing countries, an attractor could be a successful pilot even on a very small scale. This pilot should be able to

78

demonstrate the alignment between the software system and situated context. Specifically, the piloted software system could offer useful functionality to support daily work routines and promise the greater network return if there are more adoptions. Through my empirical analysis, I operationalize this principle into three design rules that are elaborated as follows:

- Design rule 1.1: Reuse and adapt open-source software components

To quickly have an attractor, one approach is to adapt and reuse open-source software solutions that have been used by in other settings. This is a useful tactic given the rapid advancement of generic open-source software applications such as DHIS2 and OpenMRS, which are dedicated to the healthcare domain. In the early phase of the licensing system, the prototype was built based on DHIS2 rather than developed from scratch. This approach partly contributed to the evolution of the II because it helped to shorten the time required to build the system. While the international bid would take a long time to settle, the idea of having an interim system offering core functionality would be easily endorsed by important stakeholders such as the donors and the MoH.

However, to maximize the effect of reusing and adapting open source software, the approach must be very flexible. For example, in some cases we may need to connect and add, while in others, there could be the need to first remove and then add. The particularities of the tactic employed will largely depend on situated conditions like the opportunities available, the political climate and the existing infrastructure and systems. For example, although DHIS2 was adopted, it was not taken in its totality. Only its core modules and architecture were reused. The name-based module of DHIS2 at that time appeared to be unready for production. Indeed, the module subsequently underwent many major revisions. Furthermore, the 3-month release cycle of DHIS2 development did not fit with the requirements from the context where initial results must be demonstrated quickly.

- Design rule 1.2: Use web-based solutions

In dealing with the problem of scaling, web-based solutions should be considered, since they offer several advantages. First, it is much cheaper to scale a web-based application. When the cloud technologies become increasingly ubiquitous, the cost of hosting drops dramatically. On the client side, anyone who has a computer with an Internet connection can become a user. No expensive hardware is required to connect. The cost of maintenance is also reduced because the support can be done online. Second, web-based applications increase accessibility and availability. Users can start to use the system as soon as they receive a link and account. They

79

do not have to wait for support to install the software locally, which often requires some level of expertise. The benefits of using web-based solutions were easily seen from the cases. Many systems were scaled rapidly thanks to the accessibility enabled by web-based technologies. The Licensing System reached national coverage in less than 2 years. The Hospital Quality Evaluation System was roll-outed in few months. The Tet Reporting System was nationally scaled in within less than a month.

- Design rule 1.3: Use gateways that are quick to make and easy to replace

While agreeing upon the importance of gateways in interlinking fragmented IIs, I argue for the need of having gateways that are quick to make and easy to replace. As the attractor must come as early as possible, these gateways contribute to expediting the process. In the Hospital Inventory System, there were many hospitals with data related to drugs and commodities in local databases. Ideally, they should be connected to the MoH’s Hospital Inventory System through standardized WebAPI. However, as the construction of such components could take a great deal of time and resources, a temporary gateway that allowed users to copy and paste data from their local systems to the online system was built.

By showing positive results rapidly, the II could accumulate and gain enough political support needed for its own existence. For example, in the cases of Medical Licensing and Hospital Inventory, there were several temporal gateways built to scaffold the rapid expansion of the user base. First, the gateway that migrated data from legacy systems such as MS Word, Excel, Access played an important role in convincing provincial licensing offices to start to use the II because the gateway ensured their continuity of work without interruption caused by changing systems. Second, although many provinces had started to use the licensing system, they still preferred to use Excel for printing licensing certificates. To support users, a gateway was quickly built to export data from the online system to Excel format. Gradually, when users became confident with the online system, this functionality would be abandoned. By deploying that gateway, the II can be rapidly scaled to a level that easily demonstrates usefulness and survivability.

- Design Rule 1.4: Identify and recruit champions

To quickly illustrate a good result that attracts more adopters, it is important to have local champions. As early versions of software are never perfect, a champion with knowledge and enthusiasm could overcome obstacles more easily and give constructive feedback to improve

80

it. However, identifying and recruiting those champions might be a challenge. In Vietnam, personal relationships and social networks are important factors that determine the outcome of collaboration. This was clearly illustrated in the case of the medical licensing system where the Head of the licensing office in the first pilot province was a friend of the leader of the development team. This personal relationship gave the Head confidence to experiment with a new system and to invest time and resources on it. Through the actual use, he provided feedback to improve the system. Once this feedback was addressed, he developed the feeling of ownership. In conferences or meetings, he shared his own experiences with pride. This

“speaking on behalf” helped to convince other provinces. Indeed, there were many visits from peer provinces to his province to observe and learn experiences on how to do the licensing through an online system. When early users could have come from other provinces, the one identified through personal relationship and social network appeared to be easier to get started.

6.2.2 Design Principle 2: Scaffoldthe enrolment and continuity of use and expansion