Developing health information systems in developing countries: Lessons learnt from a longitudinal action research study in Vietnam

Designing and implementing health information systems (HISs) in developing‐country settings is challenging. Many HISs do not go beyond the pilot stage and tend to vanish when external funding is over. In other cases, multiple fragmented HISs remain, but these are unable to talk to each other. And more often than not, data collected by HISs are not used in decision making. To better understand and address these problems, this article employs an information infrastructure (II) perspective and views HISs as parts of larger and complex social‐technical networks. This article contributes to the current knowledge with a set of rich empirical descriptions of the design and implementation of HISs in Vietnam. Theoretically, it contributes to II discussions in the information systems domain by presenting four design problems and suggesting five design principles and 15 design rules to meet them. These design principles and rules also offer practical guidance for managers and designers involved in the design and implementation of HISs in developing countries.


| INTRODUCTION
Increasingly huge investments are going into the development of different kinds of health information systems (HISs) in developing countries (Nielsen & Sahay, 2022). More often than not, these systems fade away as pilot systems or end up as failures (Ostern et al., 2021). The problems of integration and interoperability are primary and various efforts at both policy level and implementation level emphasize the need for a more holistic approach which conceptualizes these systems not as standalone ones, but interconnected and reflecting information infrastructures (II) (Michelsen et al., 2015). However, the application of ideas around IIs in research and practice still remains relatively limited, especially so in the context of developing countries, which is a focus of this article.
More and more in developing countries, HISs are taking on II characteristics, such as the increasing interconnectedness and heterogeneity of social-technical elements that form the HISs (Aanestad & Jensen, 2011). This interconnectedness and heterogeneity implies the need for integration and sharing of data, the development of systems that are at scale rather than as pilots, and the combination of different platforms and devices . Despite this rapid growth of systems with II characteristics within the health sector, research and practice have relatively lagged behind. There is a growing number of studies that conceptualize HIS as health information infrastructure (HII) in both developed and developing country context. For example, Sanner et al. (2014) describe the large-scale mobile-based HISs in India and Malawi as HIIs, arguing for the need of "grafting" mobile-based information technology (IT) initiatives into social arrangements to make the IT component grow faster and in a more goal-oriented way. Horvath (2017) employs II concept to discuss the effort to build the national HII in Hungary.
However, there is not a specific body of literature which provides guidance on the design and development of HIIs in developing countries. In the West, based on studies of systems like the Internet, there have been rapid advances in research into HII, such as design principles for II developed by Hanseth and Lyytinen (2010), which were proven useful by Aanestad and Jensen (2011) in their examination of the principles' application to the national HII in Denmark, as well as in their application to the national HIIs in other Western countries. However, it is urgent that researchers in the domain of HIS for developing countries within the broader framework of Information Communication Technology for Development develop design principles which can work with the particularities of developing countries. Developing countries have characteristics regarding infrastructure, politics, resources, capacity, and so forth, which are quite different from those that exist in the West, and which have been the basis for II design principles to date. This article is about trying to identify design problems and propose design principles and design rules relevant to the research and practice of HIS in developing countries. To that end, it is vital to first identify and define any design problems related to HII in developing countries.
Therefore, the aim of this article is twofold. First, it attempts to expand the body of work relating to design theory of II. Second, it provides practical guidance to designers on the building of II for healthcare in developing nations. The specific research question this article explores is: How can we design information infrastructures for the health care sector in developing-country settings?
To answer this research question, I conducted a longitudinal action research in the healthcare sector in Vietnam between 2009 and 2016. The action research basis for this article was conducted within the aegis of the Health Information System Program 1 (HISP), a network spanning multiple countries in Africa and Asia including Vietnam. The primary goal of HISP is to strengthen HISs in developing countries through software development, implementation, and capacity building. As a result, four design problems and six design principles were identified and discussed.
The remainder of this article is organized as follows. I review related studies in Section 2 followed by a case presentation in Section 3.
Section 4 discusses my research approach and methods. The analysis and discussion are presented in the Sections 5 and 6, respectively.

| RELATED RESEARCH
This section presents an overview of theoretical perspectives that informed the data collection and analysis in this research. It starts with the discussion of II and II design principles followed by the argument for the need to extend II design theory to address specific design problems related to HISs in developing countries. Finally, a theoretical framework that guided the analytical process is presented.

| From information system to information infrastructure
Information system (IS) and IS design is a well-established branch of research (see, e.g., Mills et al. (1986), Walls et al. (1992), and Bally et al. (1977)), in which generic methodologies and approaches have been developed to guide the IS design and development process.
Researchers commonly have the ambition of distilling "how-to" guidelines (design principles) that address specific design problems for particular contexts and domains. Markus et al. (2002), for example, developed a design theory for building systems to support emergent knowledge processes relating to basic research, strategic management, and so forth. In this study, they devised a number of design principles such as customer engagement, knowledge translation, knowledge integration, and so forth. Similarly, Lindgren et al. (2004)-also interested in delving deeper into design principles in order to create better guidelines by undertaking an action research which aimed to build a competence management systemdeveloped several design principles including transparency, interest integration, and real-time capture to guide the process of building similar systems. Even in the healthcare domain, design principles were discussed early on with regard to the subject of designing systems when Michel et al. (1999) was researching how to build effective ISs for intensive care units.
When systems become increasingly connected thanks to the advancement of networking technologies such as Internet, their complexities also increase. To deal with their complexities, some researchers argue that these systems should be better conceptualized as IIs (Ciborra & Hanseth, 1998). Markus et al. (2002), however, argue for the need of having new methods and approaches.
Such large-scale and complex systems are coined as II (Ciborra & Hanseth, 1998) involving multiple and heterogeneous stakeholders with asymmetric power relations (Sahay et al., 2009), conflicting goals, and diverse approaches for their design and evolution. This represents a new phenomenon, which differs from the traditionally existing standalone systems, and is currently attracting significant research interest (Hanseth, 2002;Henfridsson & Bygstad, 2013;Tilson et al., 2010). Traditional approaches which pervade in designing and building ISs are often incapable of tackling emerging issues related to constructing such large-scale and complex IIs that are distributed with no clear borders related to what is a part of the II and not, and with no clear start and end dates for their construction. These IIs are subject to the problem of "drift," which 1 https://www.mn.uio.no/hisp/english/ refer to the circumstances when the outcome of an ICT project significantly diverges from what was anticipated or planned (Ciborra, 2000). The problem of drift thus motivates the development of deeper insights into the endogenous mechanisms (Henfridsson & Bygstad, 2013) that contingently drive the evolution and growth of IIs. There are calls for more theorizing of the dynamics around the design, development and evolution of IIs. For example, Tilson et al. (2010) argued for the need to overcome the paucity in IS research and focus on studying IIs, which are becoming as necessary as roads, electricity, water, and similarly vital infrastructure systems.
There are a number of studies dedicated to understanding the different facets and dynamics of IIs. This includes research conducted from within the domains of Science and Technology Studies (STS; Hughes, 1979Hughes, , 1987, Complexity Theory (Lewin, 1999), and Actor Network Theory (Law & Hassard, 1999). In the IS field, Hanseth and Monteiro (1998) conceptualized IIs as networks comprising sociotechnical assemblages characterized by the following six properties: shared, open, evolving, heterogeneous, standards, installed base.
Coming from STS, Star and Ruhleder (1996) proposed a slightly different perspective on IIs, emphasizing social relations as the cornerstone of an II, which is characterized by the following dimensions: embeddedness, transparency, reach or scope, learned as part of membership, links with conventions of practice, embodiment of standards, built on an installed base, becomes visible upon breakdowns.
Both the perspectives by Hanseth and Monteiro (1998) and Star and Ruhleder (1996) recognize the vital role of the installed base in determining the path of development of IIs. Due to the frictions and inertia created by the installed base, designing and building an II is never as straightforward and linear a task as a traditional single-owner IS would be. From this viewpoint, changes to the II thus often undergo processes which are incremental, stepwise, and evolutionary rather than being a big leap, drastic and revolutionary. Because of the installed base, the II slowly evolves, and because of its complexities, the II is hardly designed or built quickly and in a straightforward fashion. Because an II is comprised by a network of heterogeneous actors with conflicting interests and varying levels of autonomy, absolute control of the development of the II is unattainable. Predetermined development plans of an II are seemingly nonexistent as compared with a traditional IS where requirement engineering is the main driving force shaping how and when the system would be built. The trajectory of an II is thus largely provisional and contingent. This evolutionary nature of an II is completely contrary to that of ICT projects which are very goal-specific and confined within predefined timeframes and budgets.
New methods, methodologies, and approaches required to develop IIs are visible in different scholarly works which will be presented in the following section.

| II design problems, design principles, and design rules
Although the complexities and lack of central control are inherent in IIs, various scholars have acknowledged room for design interventions. An exemplary case which happened before the era of the Internet is the development of the electrical system in the US, which was conceptualized as a large-scale and sociotechnical system. Hughes (1979) coined the term "system builders" to denote a class of actors whose role is vital to assembling disconnected and heterogeneous worlds, including various institutions, manufacturers, and investors, into a working and goal-oriented system. In order to do so, system builders must cross disciplinary and functional boundaries and "force unity from diversity, centralization in the face of pluralisms, and coherence from chaos" (Hughes, 1987, p.52). Therefore, although II are hardly built from scratch, they could be cultivated incrementally based on what already exists, the installed base. Cultivation is a process through which an installed base is bootstrapped and incrementally augmented with IT capabilities to cope with emergent requirements (Hanseth & Monteiro, 1998). This meta-level approach can be conceptualized as a form of design intervention for IIs.
To tackle the challenges involved in building II, there have been several attempts by researchers to develop a design theory for them. One prominent example is the work of Hanseth and Lyytinen (2010), which proposed and articulated a united design theory, primarily addressing two design problems: bootstrapping and adaptability.
The bootstrapping problem refers to the situation where an II cannot take a leap by itself but needs some form of kick-starting. An II has a self-reinforcing mechanism through which it can evolve by itself thanks to its evolving momentum. However, at the beginning when none or little of the installed base exists in terms of functionality, data and other users, it is hard to attract early users.
The adaptability problem refers to the situation when an II grows to a certain level with a large installed base; it is trapped by various lock-ins in terms of user base and technology, which constrain its adaptability to new situations. There are two variations of this adaptability problem. The first relates to the existence of a multiplicity of standards adopted by the user community which is hard to unify or make uniform because switching costs are too high. The second relates to the incapability of a certain technology to fit new requirements. A technology could be widely adopted by a large user community despite the fact that over time it will become obsolete and new technologies will arrive to substitute it. This replacement also incurs substantial costs.
While the origins of the two design problems of bootstrapping and adaptability are not clearly stated, there are further considerations to be accounted for. For example, the seminal work of Shapiro and Varian (2013) highlights the significance of understanding the fundamental economics of networked ITs. That is how a network increases its value when its base of users soars. If we conceptualize an II as a network, one of the tasks its designers must address is how to attract as many users as possible. This is the theoretical construct from which the bootstrapping problem emerges. The second problem of adaptability is touched upon in the works of Zittrain (2006) or Hughes (1987), which explore the significance of adaptation of technical systems when they expand their boundaries to encompass other specificities and particularities.
The ultimate goal of any theory is to create appropriate strategies and approaches through building a deep understanding of the phenomena and its dynamics. With this perspective, Hanseth and Lyytinen (2010) proposed five design principles to tackle the two design problems of bootstrapping and adaptability. Although the design theory proposed by (Hanseth & Lyytinen, 2010) is very comprehensive, the socio-technical approach to ISs cautions us that their theory's design principles and design rules cannot be universal and would need to be sensitively extended to different settings and contexts. In fact, Hanseth and Lyytinen (2010) have called for future research to explore additional design problems that have not been covered in their design theory. Recently, IS scholars have responsed to that call. For example, Wulfert et al. (2022) proposes new set of 19 design principles for building e-commerce systems in developed countries. Cronholm and Göbel (2022) provides a design framework to carry out action design research at multi levels. Blaschke et al. (2019) discusses a set of design principles to guide the value cocreation processes. Wulfert et al. (2022) proposes framework for nudging designers toward a more empathic and situated approach. Becker and Schmid (2020) does not directly outline a set of principles for small and medium size businesses but provides a general guidelines for digitization. Despite attracting much attention from the IS research community, design principles in developing country settings, and healthcare in particular, have not been discussed.
My paper is a step in this direction of building upon and extending these design rules of IIs, specifically to be relevant for HIIs in developing countries. This contextualization and extension will need to address the different challenges identified with HISs in developing countries, which we discuss next.

| HISs in developing countries, and their challenges
HISs have gained the increasing interest of practitioners, researchers, and policy makers (Blumenthal, 2009;Zhang, 2013). HISs span a broad range of health management activities from "daily provision of services" and "patient level data in hospitals" to "specific functional areas, such as human resources, drugs and logistics, finance, and inventory management, and others relating to specific diseases such as for HIV/AIDS, Tuberculosis and Malaria" .
Research and practice around HISs in developing countries have grown exponentially in the last two decades or so. Without trying to elaborate on the entire landscape of this research domain, I focus on describing three key challenges which have been discussed extensively in the literature, and addressing them becomes imperative for a proposed design theory. These three challenges identified are: • Systems not achieving integration and interoperability, • Systems not attaining full scale and with it becoming unsustainable, • Systems not leading to effective use of information for supporting health action and local work practices.
Details of each of the above challenges are articulated as follows: • Systems not achieving integration and interoperability The challenge of integration and interoperability refers to the situation in which there exists a multiplicity of isolated and fragmented ISs introduced by various donors and governmental agencies (Heeks, 2006). There are several versions of this challenge. One of them relates to the situation where different health programs exist but do not talk to each other even they are coordinated by the same agency, that is, the health ministry (Chilundo & Aanestad, 2005). Sometimes, it is the coexistence of systems for both vertical health programs and an integrated HMIS with overlapping datasets and data elements (Chilundo & Aanestad, 2005). In other circumstances, multiple systems serving the same functional roles attempt to encroach upon and substitute themselves for each other .
System fragmentation often results in duplication of functions and wastage of time and resources. It requires health workers to work on multiple systems at the same time, creating more workload on health workers who are already over-burdened with clinical care and other administrative tasks (Mosse & Sahay, 2003). In addition, multiple governing structures must be organized to maintain and support these separate systems (Chilundo & Aanestad, 2005). Not only does fragmentation create more work, the redundancy between systems also has adverse effects on data quality (Sahay et al., 2009).
• Systems not attaining full scale and with it becoming unsustainable Very often, HISs in developing countries were funded by donors, and those programs stopped when funding was ceased (Heeks & Baark, 1999). This challenge also relates to the sustainability of HISs, regarding which Braa et al. (2004) argue for the need to align local actions within a network where technological artifacts, lessons, and experiences could be mutually shared among countries. Another facet of this was the challenge to scale a successful pilot project to a larger geographical area, that is, to cover a full district or province. To become useful for decision making, HISs must be able to provide full data coverage. Braa et al. (2004) define this problem as "all or nothing" and argue its significance due to the need of health equity and "health for all" endorsed by top politicians. Scaling of HISs in developing countries is uneasy to attain Nguyen & Braa, 2016;. Sahay and Walsham (2006) argue that scaling is not simply a replication or parachuting of a technology from point A to point B but often requires different strategies to deal with the escalation of technical complexities as well as human resources with adequate skills and experiences.
• Systems not leading to effective use of information for supporting health action local work practices Having good data does not provide a guarantee for data use (Nutley & Reynolds, 2013;Rhoads & Ferrara, 2012), as data is a necessary but not sufficient condition to enable effective decision making. While the final goal of any HIS is to improve decision making through the support of data, little data use is thus a big issue threatening the sustainability of HISs (Braa et al., 2007;. Unfortunately, the problem of little or no data use is widespread in the context of HISs in developing countries Donaldson & Lohr, 1994;Scott, 2016).
Data use problem is part of the "vicious cycle" , a term referring to the factors which affect the success of HISs initiatives.
Efforts have been made into improving the data use issue with a variety of techniques including the introduction of tools that could facilitate the discussion, sharing, and learning toward data use (see, e.g., Manya et al. (2015), Moyo et al. (2016), and ). Despite investments in and improvements of HISs, data use problem remains more or less the same (Wyber et al., 2015).

| My proposed theoretical framework
As discussed earlier, HIIs can be seen as a subset of II. The existing design principles and rules from IIs are applicable in the context of HIIs in developing countries to deal with the two problems bootstrapping and adaptability. However, as HIIs in developing countries pose situated challenges which are different from bootstrapping and adaptability, it is important to frame these challenges as emergent design problems, and work to develop and operationalize new design principles to create rules to address those problems. To guide the analysis process, a number of steps was carried out, which involved identifying HII challenges, framing them as emergent II design problems, building new design principles and rules, and evaluating their robustness to other contexts and domains. Figure 1 illustrates my theoretical framework that guides the analytic process with the following elements. The design principles serve as inputs, denoted by the gray color. The context for this theory is the healthcare sector in Vietnam, where problems have been identified through literature related to HISs, such as data use, all-or-nothing approaches, scaling and sustainability, and others, marked by the blue color. The output of this theory is the extension of the design theory, which includes formalized design problems shown in red, as well as specific design principles and detailed design rules, represented by the orange color.
The theoretical framework thus is an extensions of the II design theory (Hanseth & Lyytinen, 2010). Based on the specificity of HISs in Vietnam, new challenges and problems are identified and a set of design principles and design rules are discovered to help resolve those problems. This is a new set of problems emerged from different empirical settings than the one discussed by (Hanseth & Lyytinen, 2010). Therefore, a new set of design principles and rules are required. Both emerging problems and solutions will be discussed in incoming sections.

| THE CASES
This section describes the design process of four software systems that formed the basis of my empirical work.

| The medical licensing system
On November 23rd, 2009, the Vietnam Assembly enacted a law of medical examination and treatment (herein after the Law). The Law which became effective on January 1st, 2011 set an important legal precedent to regulate medical practicing activities in Vietnam. The three subjects regulated by the law include medical practitioners (doctors, nurses), patients, and medical facilities. The law enforces patient privacy, legalizes the ability for medical practitioners to have a part-time job outside their work in public medical institutions, and prohibits bribery in any form. Most importantly, it officially requires medical professionals to be licensed before they can practice. Each health professional is mandated to have a license, which is granted for lifetime, although holders need to provide proof of continuous medical education. The law was expected to increase the quality of medical services delivery that was considered to be relatively low compared with other countries.
The Law was followed by the Government's issuance of the decree (87/2011/NĐ-CP dated September 27, 2011) which served as a detailed guideline on how to implement the Law. On November 14th, 2011, the Ministry of Health issued a circular (41/2011/TT -BYT) to elaborate formalities and processes to apply and obtain medical licenses for individuals as well as facilities. The enactment of the Law is part of Asia Development Bank's (ADB) support through the Health Human Resources Sector Development Program project, which consists of a number of components. One of these components is to support the development of a registration system for health professionals with aims to (1) regulate professional qualifications and skill standards, (2) monitor individual performance, (3) regulate on disciplinary action when problems arise, and (4) enforce continuous skills development (ADB, 2013). In its project proposal, ADB also emphasizes the fact that Vietnam is among the few countries in Asia which do not have a functioning system to regulate and manage the registration of the health workforce (ADB, 2013). Therefore, a plan to provide support to the Vietnam Ministry of Health to build a computerized licensing system was part of ADB's agenda.
In early 2012, a specialist from MoH (hereinafter DrS), whom I knew through a friend, contacted me and asked me if I could recommend any international firm which could provide software solutions for medical licensing. I accepted his request and tried to contact a number of HISP country nodes. However, I could not find any company because at that time HISP activities mainly involved aggregate-based reporting systems. I suggested to him that I could try to build a prototype based on DHIS2, which is an open source software specialized for healthcare developed by the University of Oslo, in Norway, to see if it was feasible to develop that system locally instead of purchasing it from international vendors. He supported this plan and encouraged me to proceed.
To begin, I extended DHIS2 by developing a web module on top of it. The prototype was ready in a short time and I showed it to DrS. One province in the South of Vietnam (hereafter SouthProvince) was selected to pilot the prototype thanks to the relationship between me and the Head of the Licensing Office in SouthProvince (hereinafter DrP). DrP attended various health informatics courses organized between 2007 and 2008 in Ho Chi Minh City in which I was one of the instructors. DrP had an interest in software systems, so when he heard about the licensing system, he agreed to pilot it in his province. I provided him the link to the licensing system and created an account for him. Soon, he got back to me and gave me a list of suggestions to improve the system. I was working closely with him to address all the comments. When all the major problems were solved, he started to use the system to process licensing applications in his province. During the pilot phase, whenever he found some areas of improvement, DrP discussed these with me and I quickly fixed them for him.
After nearly 1 year piloting it in SouthProvince, the system was evaluated by the MoH and Asian Development Bank (ADB) as ADB was providing aids to strengthen the health human resources in Vietnam through a number of projects. Both of the agencies were happy with the system. They decided to support piloting it in five more provinces.
To implement that plan, ADB provided a small grant to improve and implement the system. With the ADB support, seven people were hired to form a team to work on customizing the system and provide support to end-users (hereafter the Team). The MoH sent a letter to request that the five provinces participate in the pilot. With both financial and political support, the implementation progressed well. Lots of new functionality was added to the system, making it effectively support the transformation of work practices in the pivot provinces.
Subsequently, the scope and size of the implementation of the licensing had a big leap forward. In early 2013, during two notational conferences on licensing management, the MoH allocated time for the Team to present the system to all provinces. Following the conferences, a Vice Minister signed a letter to all the provinces not currently participating in the previous pilot, requesting them to register a minimum of 150 applications into the system. Based on that arrangement, the Team worked intimately with the provinces to support them-not only with the registration of the 150 applications but also to advise them on how to align their workflows to comply with the computerized licensing system. To facilitate the implementation process, the Team built a tool to convert data from Excel files to be compatible with the system. This approach was welcomed by many provinces and not only did they register their requisite 150 applications, they started to use the system to support their work.
The national scaling of the system comprised not only consent but also challenge and protest. Some provinces said that using the system took more of their time than using Excel files and complained that they did not have enough staff to do that. However, there was one event that completely changed the scaling process. SouthProvince made a request to the Team to build functionality that allowed their hospitals to participate in the process by registering applications at hospitals prior to handing hardcopy applications in to the licensing office. SouthProvince argued that this approach might reduce the workload of licensing officers. The Team consented to the request and extended the system with that functionality. User accounts were also created and given to SouthProvince. Enlisting hospitals in the licensing process proved to be an effective approach. Many neighboring provinces expressed interest in visiting SouthProvince to observe and learn. Through efforts of the Team, the approach quickly spread to other provinces. By the end of the year, from the original plan of pilots in five provinces, the licensing system was expanded to all provinces in the country.
Through each milestone, the system was gradually augmented with more functionalities. When being piloted in South Province, only basic functionality to process licensing applications was developed, including: • Applicants' bio information such as name, gender, date of birth, address • History of practice details such as name of hospitals, positions, from when to when • Medical certificate information such as name of medical university, year of graduation When it was about to be deployed to five provinces, however, the system was extended with many advanced functionalities such as batch processing, that is, licensing officers can work on multiple applications at the same time, and searching and filtering. The key feature that was added to the system when it was expanded to all provinces was application registration at the hospital level.
In 2014, ADB opened tendering to allow firms to bid on the chance to extend the licensing system to include other modules, such as continuous education, human resources, payroll, and so forth. After many rounds, a local firm (hereinafter BigFirm) was chosen and awarded a contract.
As the licensing module was fully functioning, ADB provided another grant to the Team to continue supporting it and to help integrate with BigFirm's modules. According to the Terms of References defined by ADB, BigFirm had to work with the Team to integrate their newly developed modules with the licensing system. Modules that would be developed by BigFirm included facility licensing, continuous medical education, human resource management, payroll, business intelligence, and reporting.
Between 2015 and 2016, there were many meetings organized by ADB to facilitate the collaboration between BigFirm and the Team to find solutions for system integration. The Team insisted that BigFirm should use DHIS2 so that integration could take place easily, while BigFirm wanted to use its own platform and technology stack.
In the end, both sides reached an agreement that each team could use its own architecture and platform, independently from each other. To ensure compatibility, The Team would publish data from the licensing system to an online data warehouse. The BigFirm's modules would connect to the data warehouse to copy data into their own database through web services. End users could use both systems with the same user account, thanks to the use of OpenID protocol.
In mid-2016, after more than 1 year of development, BigFirm completed seven modules. It received permission from the MoH to pilot in a couple of provinces. The process of integration between the two systems has been ongoing. 3.2 | The hospital quality and inventory management system After the licensing system was implemented nationwide in 2013, the Team gained trust from many MoH staff. There were a number of discussions between the MoH and the Team on how to replicate the licensing system to support other areas of health management. At the end of 2013, the MoH prepared and released Hospital Quality Evaluation Guidelines for the first time. The guideline consisted more than 3000 criteria, which were used to assess a hospital. To support that process, a computerized IS was needed.
Originally, in May of 2013, the Team had developed a separate module for health facilities licensing, which was cloned from the (professional) licensing system, but the system was not implemented for many reasons. First it conflicted with the plan of ADB to have a tender to select a firm to build all required modules. Second, the Team did not have resources to carry out the implementation without funding. The process of both of the systems is very similar except that one focuses on professionals and the other on facilities. Therefore, much of the code and design could be reused. The Team had planned to build the module so that in case they won the tender, they could have everything ready.
Understanding the emergent need to have a system to support hospital quality assessment and hospital inventory, the Team showed what had been built to the MoH and proposed that it could customize the module to meet the requirements of the Hospital Quality Evaluation and Inventory System. The MoH approved the proposal and asked the German Aid Agency (Deutsche Gesellschaftfür Internationale Zusammenarbeit-GIZ) to provide financial support for the implementation. After receiving the funding, the Team started the software customization process. To expedite the process, a number of "temporal gateways" were used. For example, the Team prepared an Excel file that contained all assessment criteria, transformed and loaded them into a database, which significantly reduced the effort of inputting them manually. There were more than a thousand hospitals in Vietnam, thus creating accounts for all of them could involve a lot of manual work. The Team built a simple program using Java to automatically generate user accounts containing both username and password for all hospitals. The module was extended to become an independent system that supports the following areas: • Hospital quality assessment, including more than 3000 criteria in five categories: patient service orientation, human resources development, performance, continuous hospital quality improvement • Inventory including administrative data, staff, organization chart, drug, equipment, service scope, service delivery.
Because the time was too short, the MoH planned to roll out the system and bypass the pilot stage. Some MOH staff objected to this plan, arguing that it was too risky. The disagreement of several officials from the MoH, in fact, offered more time to the Team to improve and polish the system. After many rounds of discussion and lobbying through the relationship with a high-ranking official who supported the Team, eventually, the go-ahead plan was approved and the system was rolled out.
To start, a member of the Team was assigned to make separate Excel files, each containing accounts of hospitals for each province. Through contacts at health departments in provinces acquired when the Team implemented the licensing system, accounts were distributed to all hospitals. The relationship between the Team and provincial health departments and hospitals, which was strengthened after 1 year of implementing the Licensing System, was very useful for the Team in supporting this system. There were many technical issues in the first week of the implementation, but they were resolved quickly. Based on user feedback, the system was gradually improved to be better and better, thus increasing users' satisfaction. Many hospitals started to use the system to assess their quality and report inventory. The result was later independently verified by provincial health departments. In the end, a report that ranked the quality of all hospitals was generated by the system, giving the MoH necessary data for action.

| The Lunar New Year Reporting System
Following the implementation of the Hospital Quality and Inventory System, the Lunar New Year Reporting System was built and implemented in January 2014. Lunar New Year, which is called Tet in Vietnamese, is the biggest holiday festival in Vietnam, often lasting from 7 to 10 days. Extended leisure activities during Tet often increase risks of traffic accidents, food poisoning, and fireworks burns and injuries. Government agencies, especially the MoH, really need timely and accurate accident and emergency figures in order to respond effectively.
Motivated by the success of the Hospital Quality and Inventory System implemented before, the MoH asked the Team whether it could support to build and implement a Tet Reporting System. As the time was too short, some members in the Team were skeptical, but in the end, they agreed to provide support even though there was no budget for this work.
Also based on DHIS2, the Tet Reporting System was developed to provide functionality for capturing both aggregate and case-based data. Basically, the system consists of an entry form to collect the following data: • Number of hospitalized cases • Number of deaths and injuries by traffic accidents, by illegal use of firecrackers, by food poisoning, and by violence.
For traffic accident, firecracker, and violence, detailed patient data must be reported to avoid duplication and later inspection. There is a separate form to capture patient-level data, that is, patient name, gender, age, address, date of admission, and so forth.
The team managed to complete the system in 2 weeks' time. The MoH sent a letter to hospitals and provincial health departments to inform about the use of the system for Tet reporting. In the letter, there were basic instructions on how to use the system, as well as some hotline telephone numbers that users could call if they needed support. Because there would be no time for formal training, the system was designed in a way that it could ensure that all hospital users could use it easily. For example, the use of a single-page entry form allowed users to input data of all reporting days on one screen, and beside that were help-line numbers. A button to print reports was also integrated into the same screen.
After the Hospital Quality and Inventory System was implemented, hospital users were quite familiar with online reporting, which is a method to report data by using a web browser such as Google Chrome or Firefox. The advantage of online reporting is that only a computer with Internet connection is required, and no software installation is necessary. The implementation of the Tet Reporting System went relatively smoothly with only a few issues related to data validation, which were quickly fixed by the Team.
In 9 days of the Tet holiday, daily data were aggregated and released to the public through mass media before noon the following day. By the end of the Tet holiday, the public realized that the figures of traffic deaths and injuries between the MoH and the Ministry of Public Security (MPS) were not consistent, with much higher numbers in the MoH report. This fueled a big public debate regarding accidents and emergencies during the Tet holiday and people insisted measures be taken at various levels (policy, individual, and so forth) to remedy the issue. Figure 4 summarizes key events of the Tet reporting system.

| The epidemic notification system
Shortly after the Lunar New Year of 2014, the North of Vietnam was struck by a severe measles epidemic. Thousands of patients, mostly children, were hospitalized, and hundreds of them died. The public was very anxious. There was even more panic when they realized that the number of deaths published by the MoH was not consistent with the number revealed by a local hospital. The anger of the public turned directly to the MoH, with several calls to strike at the MoH headquarters. The General Department of Preventive Medicine had built a system to collect epidemic data. However, at the time of the epidemic outbreak, the system was not fully scaled to all provinces, making it impossible to collect the aggregate figures of the whole country. In March 2014, an official from Vietnam Administration of Medical Services approached the Team to discuss extending the Tet Reporting System for measles surveillance. Seeing the opportunity to contribute to solving a public health issue that affected many people, the Team decided to take part in this. In just a few weeks, the Epidemic Notification System was completed and implemented in all hospitals, collecting data on measles-related cases across the country. Summarized reports were compiled every day and sent to all relevant agencies such as the Government Office, General Department of Preventive Medicine, and public media to inform the public about the status of the epidemic. Eventually, the epidemic was pushed back and under control after some months. Later, the system was expanded to cover many other diseases such as dengue fever, foot-hand-mouth, and so forth.
In February 2014, Vietnam joined the Global Health Security Initiative 2 led by the United States of America. The joint initiative of 26 countries aims to enhance mutual support between member countries to help prevent, detect, and respond to outbreaks of communicable diseases. As part of the collaboration, the US Center for Disease Control and Prevention (USCDC) would provide support to Vietnam in building an Emergency Operations Center. To proceed, USCDC staff began to contact Vietnam Administration of Medical Services and General Department of Preventive Medicine to discuss how to integrate systems run by these two entities with the data warehouse to be developed by the USCDC.
To proceed, between December 2014 and January 2015, the USCDC and its partner in Vietnam (PATH) organized a number of meetings and workshops to discuss the situation and seek the best approach to build an infectious disease data warehouse. Among available options, PATH and General Department of Preventive Medicine planned to use data collected from General Department of Preventive Medicine system to feed into the data warehouse. Seeing that bilateral collaboration as a threat, Vietnam Administration of Medical Services and the Team proposed that they could change the system to feed patient data related to infectious diseases from hospitals into the General Department of Preventive Medicine system. The idea was welcomed by other actors. Following that, the Team built a Web Application Programming Interface (API) that transferred data from the Epidemic Notification System to General Department of Preventive Medicine's system. To ensure interoperability, the Team proactively initialized discussion with the technical team behind General Department of Preventive Medicine's system and agreed on data sharing standards and exchange protocols.
As a result of this collaborative effort, a software ecosystem was built from separated systems developed by different software vendors and endorsed by different governmental agencies. One of the important criteria of these processes was that each system must find its own areas of contribution, that is, functional roles, and reconfigure itself to fulfill such roles. It is also critical to develop an ecosystem approach which could strengthen the ecosystem as a whole rather than using only the best components and removing others. It also means that by enrolling into such a network, individual systems can have better protections from mutual exclusion and become more adaptive to other future changes. This section discussed the development and implementation of four different systems that formed the basis of this article. In the following section, research method and approach will be presented.

| Action research
Action research is a research method that aims at not only solving a real-world problem but also generating theoretical knowledge (Winter, 1989).
I chose action research as my mode of inquiry, as it is effective for studying technology in human contexts (Baskerville & Wood-Harper, 2016).
Action research is also distinct from other methods in its ability to develop knowledge for both practice and theory (Suchman, 2002). Furthermore, action research allows researchers to test and examine the differences between hypothesis and actual change, which serves as a motivation to understand how to improve and solve actual practical problems during the course of conducting research.
There are many types of action research; however, canonical action research (CAR) is considered to be a rigorous and prominent type. A typical CAR involves one or many action research cycles (Davison et al., 2021(Davison et al., , 2022.
In this article, an action research comprising four cycles was attempted. In the first cycle, the plan was to build and pilot a system based open source software for managing medical licenses. The action was discussed and decided upon a diagnosis phase through which I and other key stakeholders agreed on the need of having a web-based, centralized, and open-sourced system for medical licensing. During the action taking phase, a prototype was developed and tested in one province. In the review meeting organized at the end of the cycle, the action research team evaluated the outcome and identified several lessons for next cycle. One of the lessons was the importance of participation approach in building a software from scratch.
The second cycle's action planning was based on the lessons learned from the first cycle. However, the diagnosis phase in this cycle also identified another problem which was scaling that needs to be resolved. The action planning was to gradually extend the implementation of the system developed in cycle 1-6 provinces. At the end of the cycle, parts of the lessons learnt were throwable gateway components could catalyze and facilitate the scaling process.
In the third cycle, the diagnosing phase identified more problems. The most salient one was data use. The planning and action was to deploy more and more systems in the existing infrastructure. As a lesson learnt, data use can be improved through several means.
The cycle four identified integration and interoperability issues. The plan and action were to find a way to integrate different competing software systems. The lesson learnt from this cycle was derived as a set of strategies to reconfigure different software systems to form an evolutionary ecosystem. Table 1 summarizes activities happening during each phase of the three research cycles.
As there are many forms of action research, it is essential to have evaluation criteria to ensure that an action research project is rigorous. Avison et al. (1999) proposed a framework containing five principles to assess an action research, which I discuss further below, and explain in Table 2 how my action research attempted to follow these principles.

| Data collection
Given my initial chosen theoretical frame, its evolution, and choices of cases, data was collected both in deliberate planning and in an ad hoc manner (opportunism). Methods of data acquirement were from traditional qualitative approach methods adapted to the needs of particular cases.
For example, while onsite observation (field visits to hospitals, provinces, and MOH offices) was widely used in the case of the Licensing System, thanks to financial support from ADB, it was limitedly used in other cases.

| Participatory observation
Observation techniques are widely accepted as an important method of data collection in qualitative research. They provide a number of advantages over interviews and questionnaires; for example, researchers can directly see things when they occur without relying on interview informants' "retrospective or anticipatory accounts" (Sapsford & Jupp, 2006, p.59).
Being a researcher in a network of action, this participatory observation approach was a rich source of data for me. My longitudinal engagement with many projects in Vietnam gave me chances to follow each case from inception to closure. Broad involvement in the projects in various roles allowed a richness of collected data. Moreover, this approach was really helpful for me to get a deep understanding of people, organizations, and the contexts in which systems were implemented over a long period of time. In addition, the approach enabled direct contact with different data sources (Myers, 1999).
My participation varied from case to case, depending on the roles I played. For example, as an implementer, I had many chances to work with health workers and users who directly used the systems for their daily work. When I played the role of a developer, I was involved in technical T A B L E 1 Summary of three action research cycles. The need for a centralized licensing system to govern the licensing process nationwide Prototyped and piloted the Medical Licensing System in one province • Action planning: Building a prototype based on open source software to support the pilot Using II design principles to guide the design process • Action taking: Building a prototype and piloting in one province through participation approach • Evaluating: A system was built incrementally through step-wise pilot • Specifying learning: The significance of bottom up and participation approach in shaping outcomes of the HII building process 2 January 2013-October 2013 • Diagnosing: Scaling beyond the pilot was a big problem Scaled out the Medical Licensing System to all provinces • Action planning: Gradually expanding the pilot to six provinces Using II design principles to guide the design process • Action taking: Scaling the licensing system to six provinces and rapidly to all provinces and also to hospital level • Evaluating: System was planned for pilot in six provinces but implemented in all provinces and hospitals Shift from confrontation to collaboration • Action taking: Integrating health professional licensing system with modules built by BigFirm issues and responsible for translating requirements to technical languages, and worked with different groups. When acting as a system designer, I participated in high-level meetings with the MOH and donors to plan for implementation.
More often than not, I could take time for reflection shortly after important events such as meetings, workshops, and training sessions. Notes taken during observations were used as materials for this reflection, and it often resulted in more complete and systematic understanding and writing. With substantial time spent in the field and being an action researcher, participation was an important mode of my data collection. Sapsford and Jupp (2006) warn researchers on the validity of data collected by using participation and observation techniques. According to them, data produced from these sorts of activities can be valid only if the conducted observation follows several rules. One of them is that systematic and effective measures of recording of observation must be implemented. This rule was deliberately taken into account in my research approach. Being a longitudinal researcher also gave me advantages when it came to building relationships and fostering trust with hospitals, provincial health departments, the MoH, and donors. Furthermore, research diaries and reflections helped me to alleviate the problem of data distortion and increase the correctness of collected data.

| Documents analysis
The other method of data collection employed in my research was document analysis. Documents used in my research varied in type, including (a) archives of electronic communication tools such as email, mailing lists, chat logs; (b) documents relating to software design, development and implementation processes such as source code, bug-tracking tools, wikis, blueprints, and user manuals; and (c) legal documents such as laws, decrees, and circulars enacted by the Vietnam National Assembly and the MoH.
To manage emails, I created an archive of all emails related to the development and implementation of the systems that formed the empirical basis for this research. This archive allowed me to trace activities, discussions, and interactions with other stakeholders.
Technical documents, meeting minutes, and project reports were other important data sources. A collaborative project was created using Bitbucket 3 to allow team members to discuss technical issues, report bugs, and keep track of other issues posed during the development and Agreements between researcher (myself) and client (MoH) were specified in three formal contracts with clear scope, responsibility of each side, detailed activities, evaluation criteria.

Cyclical process model
As illustrated earlier, four cycles of action research were conducted, each of the cycles followed cyclical process model: diagnosing, planning, action, evaluating, and reflection.

Theory
The overarching theoretical model employed to guide the research approach was II perspective and II design theory.

Change through action
Actions were undertaken to improve situated problems. Changes and improvements were examined and discussed in the evaluating phase of each cycle. For example, the licensing system which was implemented nationwide has changed the way licensing officers worked. Similar changes were also observed as consequences of the implementation of other systems.

Learning through reflection
The client (MoH) was informed and could monitor the outcome of the research through various channels: emails, workshops, meetings, and conferences. Final reports were written and submitted as part of contract duties.
Simultaneously, several research papers were written and published in journals to contribute to the research community. Some of them became part of this article.
3 https://bitbucket.org/ implementation of the systems. A bulk of the technical documents was produced to communicate with the client as well as to train new members of the Team. They also served as part of the deliverables that would be transferred to the client after the acceptance meetings.

| Interviews
In qualitative research, the interview is a common method for data (Kvale, 1994). Seidman (2006) argues that the flexibility of interviews makes them attractive for data collection. Interviews can range from quantitative, structured (questionnaire) to qualitative, unstructured or semistructured ones, depending upon choices and strategies of researchers. Interviews can be particularly useful when observations are not possible due to the restriction on access to research sites or through time limitations (Seidman, 2006). Interviews were also used in my research to complement data collected from other sources. In my research, the interview approach varied across the different action cycles and action phases.
It also followed the pragmatic approach, where most of the planning was done based on the specific situation. Therefore, the details of interviews, selection of interviewees, and questions asked were different from case to case and from phase to phase (in each case). Both face to face and telephone interviews were used. In total, 25 interviews were conducted with a mix of participants ranging from project managers to staff-level employees. All of the interviews were semi-structured, and open-ended questions were used to elicit most of the details.

| Software prototyping
In designing complex software systems, determining user requirements is a challenging task (Kaj, 1989;Mike & Albert, 2001). One of the solutions to this problem is to give users a nearly "working" system (Davis, 1995), that is, a prototype. Through many feedback loops, the prototype evolves and gradually gains critical mass to become a real system. This approach was employed throughout my action research but heavily used during the first cycle relating to the licensing system. In this cycle, the prototyping period lasted nearly 1 year with many interactions with the pilot province before the system became mature and ready for use.

| Capacity-building programs
In supporting the scaling of many systems, two types of capacity-building activities were organized. Formal training in classrooms was set up during the implementation and scaling of the licensing system thanks to the financial support from ADB. However, for other systems, a telephone helpline dubbed "hotline" was established to support users. Personally, I was involved in building training materials and acted as a lecturer in some training sessions. I also directly supported users via telephone or emails to better understand their problems and expectations. Table 4 summarizes all data collection methods used in different cases.

| Theory construction process through three action research cycles
In organizational research, theory building is the central activity (Baskerville, 1999). Theory development has often been done through combining literature, common sense and experience, and is rarely linked to actual data (Baskerville, 1999). Glaser and Strauss (1967) advocate grounded theory approaches which as they argue can allow theoretical development based on the empirical reality. The process of building theory from cases is also described by Yin (2009) and Miles and Huberman (1984). Based on these studies, Eisenhardt (1989) (6) To shape hypotheses and test them in the action-taking phase, I followed the guideline of Eisenhardt (1989), which requires identification of replication logic across cases. For example, the role of political support in scaling could be found in the case of the licensing system, the case of hospital quality and inventory, and the case of the Tet reporting system. Another example of replication logic is the reconfiguration of functional roles in the licensing system and the epidemic notification system, both helped them to survive and avoided substitution by competing systems.
To increase the validity of the theory, I also followed Eisenhardt (1989) advice on enfolding literature. To implement that, I compared the design principles and rules that were formed during the theory construction process with the extant literature on II design (the reference theory) to see how they are different. The process was extended to other related literature on Agile software development methods and platform ecosystems.

| ANALYSIS
This section aims to answer the research question posed earlier by discussing the problems of designing HIIs in Vietnam and proposing design principles to address them. These problems are also prevailing in many other developing countries which share contextual conditions with Vietnam. Therefore, the design principles discussed here should also be relevant in those settings.

| 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.

| 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  , 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, that is, 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 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 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.
F I G U R E 6 Summary of action cycles.

| 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-that is, Epidemic Notification Systemto step in and fill a yet-to-be-taken functional role . 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. After a number of meetings, HISP was assigned to work with two 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 nonuse (Braa et al., 2004). Because the pilot was on a very small scale, that is, in two districts in Ho Chi Minh City and two 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 .

| 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, that is, through encroachment  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 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. In addition, the culture of the Vietnamese people being notoriously very poor on collaboration and teamwork was influential (Nguyen & Johanson, 2007). The concept of collaboration or buying an existing software solution was almost nonexisting. Rather, when a contract winner is identified, a new system is likely built from scratch.

| The information use for action design problem
Information use for action is one of the motivations and main purposes of building HIIs (AbouZahr & 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 . 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 3000 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. In addition, there were also lots of data about things like medical equipment, medical service, and drug use that have not been used for action. After locating the emergent design problems, the following section discusses design principles to address those problems.

| Proposed principles for designing HIIs
With the emergent design problems, there is a need to extend the existing II design principles. In this section, I will propose a number of principles identified through my empirical analysis. Following Hanseth and Lyytinen (2010) approach, I also operationalize these principles by suggesting design rules.

| 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,  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 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 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 T A B L E 5 Summary of HII design problems.

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 two districts of two provinces could not be further expanded. • 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.
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 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 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.

| Design principle 2: Scaffold the enrolment and continuity of use and expansion
After creating an attractor which is usually a "beautiful" showcase, it is important to maintain the rhythm of enrollment and the continuity of use.
To achieve that, different user support structures must be in place. These structures are established to mitigate the difficulties that new adopters often face, as well as to motivate and encourage the continuity of use and expansion. The term scaffold is deliberately used to imply the temporary nature of these structures. It also entails that these structures must be flexible enough to support different demands during different stages of enrollment and use.
Similar to the first design principle, this design principle also aims to address the problem of scalability and sustainability. I now discuss three design rules that are related to this design principle.
Design rule 2.1: Pursue and exploit indirect means to motivate use In Vietnam, as well as other developing countries, where political legitimacy plays a central role in shaping changes, it is necessary to pursue and exploit indirect means to motivate use such as laws, decrees and official dispatches. As illustrated through the empirical cases, every IT capability introduced was triggered by a legitimate document such as law, decree, or official letter from the MoH. Other material incentives were also used in the case of the medical licensing system when every licensing office was supplied with printers, computers, and stationaries. To encourage backward data entry, payment for data entry was also implemented. This tactic appears to be helpful in enrolling reluctant users who are not very sure about the benefits brought by the II. As a result, both groups of highly motivated and least motivated users enroll into the network and support scaling.
Design rule 2.2: Institutionalize a user support team Building an effective user support team is critical for scaling. In cases where official training cannot be organized, a support team can play the role of trainers who teach users on how to use the system. Thus, the support team must be organized in such a way that it effectively supports a wide range of activities: • Answering questions and guiding users to use the system • Fixing data entry errors and doing various data administration tasks • Communicating with the technical team when a bug is found, or a particular functionality is required by users.
In the case of Vietnam, the implementation of the web-based system has enabled users to work at any time and from anywhere, but it also demands the support teamwork outside office hours. This involves organizing shift work for weekends, holidays. In addition to this, there is a need to use software tools to improve efficiency of support. For example, it was very tough for users who mainly had medical backgrounds to explain the IT technical problems they had. In such circumstances, the use of desktop sharing software such as TeamViewer could help to facilitate the communication between users and the support team.
In summary, to facilitate scaling, dedicated and professional user support teams that can work outside of office hours must be organized and equipped with relevant software tools to support their work.

Design rule 2.3: Reusing user skills and experiences
While building upon installed bases through interconnecting existing systems is identified as a mechanism of scaling (Sahay et al., 2009), I argue that leveraging user experiences and skills is also useful to enable scaling. For example, in the case of licensing systems, licensing certificates were printed on pre-printed papers as they were controlled and distributed by the MoH. This requirement posed many difficulties for licensing offices.
However, licensing officers cleverly used the mail merge functionality from Excel to solve the problem. When the web-based system was introduced, there were many configurations required to make the printing work perfectly. And it was even more problematic when users changed their printers or web browsers, because the settings needed to be readjusted. To support them, the Team decided to leverage the existing users' skills and experiences with Excel by exporting data to Excel and letting the users continue to use mail merge to do the printing.

| Design principle 3:
Seek political support to reach full coverage While scaling is important to expand the user base and increase the network effect, addressing the scaling problem does not guarantee full-scale implementation because adoption of HII, in many cases, is just voluntary. To deal with that, there must be a strong political legitimation to mandate the use. Design principles dealing with the all-or-nothing problem thus must compose design rules that help accumulate enough political support to ensure a full-scale implementation. Two design rules are now identified and elaborated upon below.

Design rule 3.1: Target politically visible use cases
To rapidly attain full-coverage adoption, it is important to align IT capabilities with political interests. By doing so, the II can receive the proper support to evolve and expand. For example, the Licensing System was started as just an experiment while waiting for the bid to be approved by the donors and the MoH. However, once it showed potential to be a system that could demonstrate good leadership, that is, anti-fraud and corruption in medical licensing, the system was quickly endorsed by top leaders. To actualize that vision, data from all provinces must be available.
In some cases, when provinces were too reluctant to use the system, creating a gap in collected data, stronger measures from the MoH were sought. For example, one province was very reluctant to use the licensing system, arguing that they were too busy. This situation was only changed when there was a report from another province saying that data from this province were not in the system, so they could not verify whether an issued license certificate was counterfeit or not. It turned out that the license certificate was faked. This provoked Vietnam Administration of Medical Services and a strong warning was dispatched to the province, which quickly complied with using the system.
To make a use case become politically visible requires time and effort. In the case of medical licensing, the message was clearly defined and communicated repeatedly in all the meetings that had the presence of the MoH's top leaders. While a system often offers multiple useful use cases, it is important to pick up the use case that can easily attract political support. With that, full-coverage implementation becomes more attainable.

Design rule 3.2: Leverage the power and position of politically relevant individuals
To solve the problem of all or nothing, the HII must target a full coverage (the entire catchment population). By proposing this design rule, I argue that politically relevant people need to be enrolled early, as they could determine the full coverage. Fully implementing a system requires lots of work to be done by different stakeholders, that is, donors, hospitals, provinces, the MoH, and so forth. However, there are a few critical steps that need to be gotten through. These are often decided by top managers. Therefore, it is important to consider and leverage these human obligatory passing points when dealing with the all-or-nothing problem. In the case of licensing, at the beginning, the idea of building an online system for licensing registration was strongly rejected by some members of Vietnam Administration of Medical Services due to various political reasons. By chance, during a meeting, an adviser from the donor sat next to a Vice Minister and had the opportunity to explain to her in detail. The Vice Minister was convinced, and she started to support the system. Not only did she give her verbal support, she also signed several letters which would enable the full-coverage scaling of the system: from one province to five provinces and from five provinces to all provinces.

| Design principles 4: Shift from confrontation to collaboration
Identified through my analysis, this principle addresses the problem of competing systems which involves substitution, encroachment, and replacement between direct competing software components in the context of HISs in developing countries . The healthcare systems in developing countries are largely dependent on external funding from international donors. To measure the efficiency of their interventions, donors often spent resources to build their own HISs. As a result, there are multiple highly overlapping, fragmented and isolated systems offering the same functionality (Kimaro & Nhampossa, 2007;Smith et al., 2008) and these tend to encroach upon each other .
The issues of fragmentation and overlapping ICT investments are sometimes not a result of poor coordination but a result of competition and battle between different stakeholders. The case of the communicable disease reporting system discussed in my paper "Battleground of IT4D: From mutual exclusion to hybrid vigor" illustrates this situation. This design principle highlights the importance of shifting from confrontation to collaboration, because collaboration within an ecosystem framework will strengthen the ecosystem as a whole. Through the process of refining and defining functional roles, individual systems find their best place to live and let other systems live in a win-win and mutual benefit cooperation.
The design rules for this design principle are discussed as follows: Design rule 4.1: Proactively refine functional roles Involved actors in the competition should always take precautions and seek opportunities to refine their functional roles to respond to threats posed by other systems. Proactively redefining functional roles helps the system to change from confrontation to collaboration. This strategic move will make the system appear less threatening to others and enable collaboration and entry rather than blocking and preventing. Two examples from my cases demonstrate this approach. The first one is how the Licensing System was reconfigured to focus only on medical professionals licensing. The module built for medical facilities licensing was completely reconfigured to function as Hospital Inventory and Hospital Quality Evaluation. This self-reconfiguration helped the Medical Licensing System survive even in case the Team failed the BigFirm tender. Indeed, when the tender was opened, another company was selected as winner. However, due to the reconfiguration done previously, the Licensing System was allowed to stay alongside the BigFirm modules.
The second example was related to the case of the communicable disease reporting system. The Team had built an additional component that could exchange hospitalized case data related to communicable diseases with the system backed by General Department of Preventive Medicine.
By doing so, the Epidemic Notification System offered some advantages to its competing system, the Communicable Disease Reporting System.
First, having data from hospitals saved General Department of Preventive Medicine from expensive and time-consuming implementation of its system to hospitals. Second, although hospitals are required to report communicable disease cases to health centers, they are often reluctant to do so for a variety of reasons. Letting Vietnam Administration of Medical Services work directly with hospitals is a wiser strategy which could help to reduce lots of resistance and avoid delays in reporting.

Design rule 4.2: Proactively define and reserve functional roles for other systems
This design rule suggests involved actors not only refine their own roles to adapt to change but also identify, assign, and reserve functional roles for other competitors. This reflects the fact that powerful actors, that is, those who have the greatest influence, are not necessarily the ones who have insights and experience to propose how refining and defining functional roles should take place or describe why this could ensure mutual benefits for all other actors. In the Medical Licensing case, the Team followed this rule by defining and reserving the facility licensing part for the BigFirm while it only concentrated on the professional licensing part. Similarly, in the case of communicable disease reporting, the Team proposed that it could export data from its system to support the expansion of the system backed by General Department of Preventive Medicine.

Design rule 4.3: Seek political support for refining and defining functional roles
One of the driving forces that triggered the reconfiguration of the Epidemic Notification System was the change in the Circular regulating communicable diseases reporting, that is, Circular 54/2015/TT-BYT. According to the new circular, hospitals must report their data directly to the General Department of Preventive Medicine's system through electronic means rather than by papers. This change presented a threat to the Epidemic Notification System and forced it to change. To apply this design rule there must be some considerations. One of them is to recognize the significance of politics in reshaping functional roles. To better survive, it is crucial to seek political support that can trigger changes in other competing systems. In the case of communicable disease reporting, the change in the circular was deliberately proposed by General Department of Preventive Medicine.
While similar chance for political maneuvering is small, it is important for stakeholders to keep an eye out for any emerging opportunities. 5.3.5 | Design principle 5: Engage the public in public health data This is another design principle identified through my empirical data. It deals with the problem of "Information Use for Action." Many studies have discussed this problem; however, most of the proposed solutions focus on improving data quality  and strengthening the ability to use data (Moyo et al., 2016). I suggest a new design principle that emphasizes the importance of making health data publicly available and engaging the public into the debates of critical health issues. As the public health system is highly political and its efficiency is often used as a demonstration of good leadership and governance, the concerns of the public could attract attention of top leaders to health data and require them to take action. This design principle is further detailed in the following design rules: Design rule 5.1: Collect data relevant to the public and commodify health data This design rule highlights the importance of collecting data that are highly relevant to the public on matters such as life, death, and so forth.
Moreover, the collected data must be presented in a way that is understandable for the public, that is, simple and succinct. For example, unlike traditional HMIS, which contain thousands of data elements to be collected, the Tet Reporting System had only a few data elements, but they were of great relevance to the public. The small number of data elements reduced the reporting burden that hospital users had to do, thus encouraging them to report accurately, fully, and in a timely manner. Furthermore, the reporting structure was also significantly simplified, that is, the reduction of breakout of genders and age groups and the using of indicators was avoided. Because of that, the published data became easier for the public to understand, and helped to raise awareness about the seriousness of the traffic accidents and violence.
Design rule 5.2: Engage mass media and fuel public debates Normally, data from HISs are only circulated within the health system, that is, in hospitals, health centers, and the MoH. They are often out of the public's concern. To draw the public's attention on critical health issues, novel channels of rapid and large-scaled data propagation must be sought.
One such channel is mass media, that is, newspapers and magazines. With a huge number of readers, newspapers (both paper-based and online) can draw attention from the public in a quick and effective way. In addition, thanks to the rhetoric of journalists, titles of articles are often written in an impressive and attractive way, which no doubt makes the boring and mundane data become livelier, attracting the attention of the public. In the case of the Tet Reporting System, once the public was engaged in the debate of health issues through the data propagated by mass media, they raised their voices. The public demanded corresponding governmental agencies to step in and provide firm responses. For example, after expressing concerns over the high number of people killed in traffic accidents, the Prime Minister ordered the heads of provinces and all Ministers to create some effective measures to reduce traffic accidents.

Design rule 5.3: Create feedback mechanisms and triangulate data
Another design rule to address the problem of information use for action involves the creation of multiple feedback mechanisms and the triangulation of data from different sources. Often, reporting flow in HISs is unidirectional, that is, upward from hospitals. In the case of the Tet Reporting System, through the published data, the public got to know more about the work of hospitals during the holiday. And the way the public reacted to the published data, that is, judgment on the reliability of the data, gave hospitals a sense of participation, making them feel the mundane process of collecting and reporting data was relevant. In addition, as the organization in charge of giving data to the public, the MoH had a responsibility to ensure the quality of published data. To do that, it had to assign its staff to watch reported data and contact hospitals if any suspicious data were spotted. All in all, it formed multiple feedback loops, from the public to hospitals and the MoH, and from the MoH to hospitals. Furthermore, the publishing of MoH data on traffic accidents challenged the exclusive role of the MPS. For the first time, data from two sources were juxtaposed and compared. The inconsistency between the two sources perplexed the public, who started to question the veracity of both ministries' numbers. Under that pressure, both the MoH and the MPS joined a debate about data quality. It turned out that their methods of data collection were fundamentally different, thus leading to data variances.

| Summary of extended design principles and design rules
In summary, this article extends the reference theory by identifying additional design problems that have not been covered by the original design theory. Based on the identified design problems, the paper suggests new and revised design principles and rules to deal with the problems. Table 6 summarizes the design principles and design rules that address the emergent design problems related to HII, as well as the empirical evidence that formed the basis of the principles.

| DISCUSSION
The biggest challenge of a case study approach, as well as in action research and qualitative research, is the ability to generalize the findings to other settings and contexts (Malterud, 2001 • Using open-source software, DHIS2 expedited the deployment process • Because DHIS2 is a web-based software, it shortened the time required for implementation • The use of a number of temporal software programs reduced the time it took to switch from paper to the online system, for example the Excel importing tool. • Licensing officers at the first five provinces supported the systems and helped convince the MoH and donors.
Scaffold the enrolment and continuity of use and expansion • Pursue and exploit indirect means to motivate use • Institutionalize user support teams • Reuse user skills and experiences • Providing computers, printers, scanners and software for free reduced resistance from provinces when it came to using the systems. • A dedicated support team helped increase the adoption coverage • Functionality to export data to Word, Excel formats increased the use of the systems economy and a high Internet penetration rate. The healthcare sector in Vietnam has undergone significant reforms involving many diverse stakeholders, including international donors such as ADB, GIZ, WHO, CDC, and local companies such as giant state-owned enterprises and agile startups (Dang & Nguyen, 2022;Khiem & Kuo, 2022;Xuyen et al., 2022). Vietnam has a large population spread across long latitudes, which has resulted in a heavy disease burden and epidemic patterns (Thanh & Duong, 2022). This has provided rich empirical data for grounding theory and generating findings .
As discussed previously, the extended design theory developed in this article is not a prescription on how to act in other cases, but researchers and practitioners in the HISs domain could find some useful suggestions for their specific circumstances.
First, many problems discussed in this article for which the design principles are developed to deal with, exist also in other developing countries. For example, the problem of scalability and sustainability is discussed in many studies on HISs in developing countries. Kimaro (2006) discusses the challenge of sustainability in Tanzania. Similarly, Kimaro and Nhampossa (2007) present a comparative case study between Tanzania and Mozambique to highlight the problem of sustainability in healthcare sectors in these countries. Miscione and Sahay (2007) discuss the problem of scalability in India and propose a practice-institutionalized approach to address it.
On the other hand, the problem of data use and "all or nothing" also has been examined in many studies. For example, Moyo et al. (2016) discuss the problem of data use in Malawi and how the implementation of a software system could remedy the problem. Charles and Geoff (2007) argue that the use of health data in India is merely a ceremony and not for action and change at all. Braa et al. (2004) discuss the problem of all or nothing that applies for healthcare sectors in all developing countries.
Second, the healthcare sectors in developing countries share many similarities. They include "health-related challenges, rampant diseases, and limited resources and capability" (Consulting, 2009, p.5). There is a need for frugal approaches that work in such conditions. The contextualized design principles developed in this article follow a frugal approach (Sahay & Walsham, 2014) that should be affordable for developing countries.
For example, adaptation of open source software (in principle 1) can significantly cut down the cost of software development (Camara & Fonseca, 2007). Using web-based solutions (also in principle 1) can reduce the supporting efforts and costs for implementation (Zoroja et al., 2014). Shifting from confrontation to collaboration (principle 4) can help avoid wasteful overlapping in terms of functional role. Another design rule (in principle 2), which demands a support team that is skillful in troubleshooting and providing support via phone, is also very relevant to developing countries because formal training can be costly and difficult to arrange.
At the same time, applying the two design principles (principle 3 and 5) to other contexts outside Vietnam can be a challenge because it might be difficult to identify local champions as well as politically relevant individuals. This might also be a challenge even in Vietnam in cases where a new system needs to be developed but such champions are no longer available. In addition, the engagement of the public in the health data debate could be challenging since the culture and mass media systems in other countries may work differently. Furthermore, the engagement of the public through mass media (mostly online newspapers) depends very much on the number of Internet users. This number is relatively high in Vietnam compared with other Asian and African countries (Statista, 2017).
Theoretically, this article contributes to II literature by extending the II design theory with design problems not previously defined and discussed. It further suggests additional design principles and rules to deal with these problems. Efforts to use the II perspective to examine HISs in developing countries have been made by a number of researchers (see e.g., Sahay and Walsham (2006), Sanner et al. (2014), Nielsen and Saebø (2016)). This article contributes to such efforts by bringing the II perspective more strongly and practically into the analysis. To operationalize that ambition, the paper has identified four design problems related to HIIs in developing countries and has proposed five design principles with 15 detailed design rules to address these problems. These principles and rules have been discussed together with contextual factors that have shaped their formulation. The design problems, design principles and design rules together form a theoretical framework that is useful to examine not only HISs in developing countries but also systems in other settings and domains.

| CONCLUSION
In conclusion, designing and implementing HISs in developing-country settings is a challenging task. This article provides a valuable contribution to the current knowledge on the subject by employing an II perspective and presenting a set of rich empirical descriptions of the design and implementation of HISs in Vietnam. One identified area for future research could be the application of these design principles and rules into other developing-countries settings. This process will give a chance for these design principles and design rules to be tested in a setting other than Vietnam. Such processes will not only challenge these design principles and rules but also empirically test and extend these principles and rules that ultimately enhance the evolution of the II design theory.

ACKNOWLEDGMENT
Open access publishing facilitated by RMIT University, as part of the Wiley -RMIT University agreement via the Council of Australian University Librarians.