Keywords

1 Introduction

In this article, we use the concept of Complex Adaptive Systems (CAS) to understand the problems of fragmentation and poor coordination in the national Health Information Systems (HIS) in Indonesia. We specifically draw upon the CAS concept of ‘attractor for change’ illustrated through the use of dashboard both as a convincing metaphor and as a practical strategy for integration, which does not disturb underlying systems and political structures, and creating a ‘win without losing’ situation.

Complexity is an important concept in information systems research, to highlight the indeterminate nature of how they evolve and have impact, and the non-linear nature of change. Often the use of the term complexity hides more than what it reveals, and provides limited analytical leverage to describe or make sense of a phenomenon. For example, saying the “context is complex” does not help explain its particular characteristics and influences, and on the contrary, goes to obscuring its relevance. Analysis of complexity thus needs to be operationalized with specific concepts, such as of attractor for change which we employ.

We build upon Kling and Scacchi’s theoretical framework [1] to understand why and how large information systems tend to be tied to the social context, and are best viewed as social systems. Applying a social system perspective helps to understand the mutual interconnections between technical and social systems and their underlying characteristics of complexity. For example, a specification of interoperability between systems in different organisations will be worthless if one of the organisations decides not to take part in the interoperability. By including organisational politics, culture and social behavior in the framework of analysis, the understanding of complexity becomes richer.

A networked perspective provides richer insights into complexity [2] as interconnections such as through the Internet can both shape and be shaped by each other. This contrasts with the ‘classic’ information system view based on a structural definition of systems in terms of boundaries, interconnected but discrete components. Networked structures are difficult to represent in a modular and structured way, as the boundaries between the system and environment are difficult to delineate, and are always changing. Concepts from CAS are better equipped to understand these dynamics. CAS pays particular attention on the study of how order emerges rather than it being created through design. In our case, we discuss the creation of “attractors for change” [3] as a strategy to bring about changes in areas with limited agreement, standards and stability [4].

As is typical in most countries [4, 5], health data in Indonesia is managed in vertical health program specific systems with minimal horizontal sharing, making overall monitoring of health system problematic. HIS for Tuberculosis and HIV/AIDS, for example, are managed as separate ‘silos’ with no data sharing, despite the fact that co-infection of TB and HIV/AIDS is a widespread critical health problem, requiring shared information. The project reported was to develop an integrated data warehouse and dashboard for health data in Indonesia. With this background, the paper seeks to address the research questions of “How can the understanding of complexity be sensitively applied to design and implement integrated HIS?”

This analysis is grounded within the empirical work of the Health Information Systems Programme (HISP), from the University of Oslo (UiO), which has over the last two decades been engaged with strengthening HIS in multiple countries. We draw upon examples from Indonesia to analyse the nature of complexity in multi-organisational contexts, and how concepts from CAS helps to understand both the complexity involved and how to address it.

2 Relevant Theoretical Concepts

2.1 Fragmentation of HIS in LMICs

Fragmentation and complexity of systems are terms that may be used interchangeably to describe particular contexts of HIS, but we emphasise an important difference. While fragmentation may be understood to be destructive representing systems being broken into small or separate and uncoordinated parts, complexity denotes that systems consisting of many different interconnected parts in multiple ways such that the whole system seems to be evolving on its own. While fragmentation refers to a lack of interaction and coordination, complexity may focus on the potential and actual interaction, both intended and unintended, between the different parts of an overall system. Both these concepts emphasize interactions and inter-dependencies between different elements of the whole, thus complexity becomes a useful lens for analysis of such HIS.

Looking at the history of HIS in Lower Middle Income Countries (LMICs), increasing fragmentation, lack of shared standards, and poor coordination are key challenges. In particular, since the advent of the large HIV/AIDS programmes around 2000, there have been increased numbers of NGOs and donors initiating projects with their own parallel reporting structures greatly magnifying fragmentation. A focus on HIV/AIDS patients and expensive ARV drugs made the ability to track patients and manage clinical pathways increasingly important, which led to a proliferation of patient record systems alongside an increasing number of typically overlapping aggregate reporting systems at the facility level. Good quality data is essential for effective monitoring, which is not easily forthcoming.

A key quest of HIS research and practice on integration, not only of the health services and population-based ‘HMIS’ and ‘M&E’-like systems, but also of patient-based and population-based health data and systems. Such systems have historically evolved independently of each other, based on different logics, and promoted by different communities with different cultures of action [5]. In order to provide integrated information support to health systems across multiple levels of management, these systems and communities need to interoperate and speak with each other.

While integration of HIS has been on the global agenda for a long time, in recent years this interest has significantly heightened as WHO and other big donor organisations are increasingly demanding the integration of data and systems. These changes in attitudes of these organizations are welcome and are being expressed at a time when the rapid spread of the Internet has in fact made integration relatively easier than before. We can say we are moving from the challenge of handling fragmentation to handling complexity of systems.

2.2 CAS, Complexity and Social Systems

Complexity refers to a situation, or an overall system, where many different parts are interacting in multiple ways, so that the whole system appears to be evolving on its own. It can be a big city, a beehive, or the Internet. CAS is a field within complexity science which studies the adaptation dynamics of complex systems: how different parts of the system and their interaction adapt and evolve to changing conditions, and how order emerges rather than it being designed. Central to the emergence of orders is the notion of attractors which represents a shared standard that is followed by many. For example, MS Windows, for good or for bad, created order in the personal computing area representing an “attractor for change” [3]. This becomes a strategy to bring change in areas with limited agreement, standards and stability, such as fragmented HIS. Scaling is another central and related concept to understand how this emerging order can expand.

“Complex, adaptive systems exhibit coherence through scaling and self-similarity. Scaling is the property of complex systems in which one part of the system reproduces the same structure and patterns that appear in other parts of the system” [7].

The example of broccoli is a metaphor to understand scaling in a natural system, where branches and sub-branches replicate the structure of the whole plant. However, information systems are inherently social systems, and cannot be represented through the broccoli metaphor as people and organizations are always context specific. Kling and Scacchi’s [1] web model provides insights to understand the challenges to scaling since information systems tend to be tied to the social context through a complex web of associations, as contrasted with the discrete-entity model that are viewed as relatively context neutral [1].

Another relevant concept we’ll use is cultivation which denotes a way of shaping technology based on resources and potential already present, which is fundamentally different from construction as an engineering method based on structured planning which assumes a starting point of a clean slate [8]. As the metaphor indicates, cultivation is about interfering with, supporting and controlling natural processes already existing, like nurturing and watering a plant to nurture an “organism” with a life of their own [9]. Cultivation is seen in opposition to structured methods and consisting of incremental and evolutionary approaches, and “piecemeal engineering” [10]. While cultivation represents an approach within the social system model, structured engineering methods are linked to the discrete-entity model.

3 Research Methods

The project is to develop an integrated dashboard system for health data for the national ministry of health in Indonesia. This project was initiated and developed within the global HISP network by the University in Oslo (UiO), HISP India and the GadjaMadha University (UGM) in Yogyakarta. Action research was the key methodology used based on a prototyping approach which was both used as a tool for enhancing communication and cooperation on design approaches between the HISP team and ministry staff, as well as a practical way to actually implement solutions that are ‘low hanging fruits’ in terms of being both useful and easy to achieve. Action research, generally, aims at generating new knowledge through taking part in the full cycle of planning, design, implementation and evaluating the results from concrete interventions [11]. Action research in HISP is linked to the practices of system development. Engaging users in participatory prototyping through cycles of learning, refinement and further development of information systems are typical ‘actions’ in the HISP action research. The DHIS2 open source software platform (DHIS2.org) is developed within the HISP network and is used as a platform for the IS related parts of the action research.

In our action research, it has not been possible to follow the rigid cycles envisaged in the more formal versions of action research [12]. Our approach was for the research team, HISP, to become ‘trusted’ participants in the various processes of organisational change and negotiations in which the HIS project is embedded. The nature of engagement ranges from developing ‘small’ concrete solutions with local users, to the linking of these solutions together in a larger national level data warehouse and dashboard solutions for the Ministry of Health. This process has involved conducting negotiations at inter-organisational levels regarding design strategies, plans and funding. Such organisational processes are larger than what is possible to control, or fit into formal action research cycles. Rather, therefore, the action research applied consists of working to influence the development of the HIS in the planned direction through improvisations and opportunity based approaches, as in ‘navigating the river’ of continuous changes. Or as Heraclitus famously said, “You cannot step into the same river twice, for other waters are continually flowing on.”Footnote 1 Meaning that change is constant; even things that appear constant, as the river, is undergoing change. The organisational context of the health systems may seem constant, but organisational politics, inter-personal matters, reshuffling of staff, changing health needs and global influences, leads to a constant changing context for the research.

The project was initiated in 2012–13 when HISP India was invited by the Ministry of Health (MoH) to start a pilot on system integration at district level in Yogyakarta province using the open source software platform DHIS2 which is a product of the HISP network. The following is the chronological sequence of events, which occurred during the project implementation.

3.1 Chronology of the Action Research Events

2012–2013: HISP India starts working with the MoH in Indonesia and key technical people take part in DHIS2 training in India. A pilot project aiming to integrate data from the Health Centres (called Puskesmas) at the district level was started in Yogyakarta province in collaboration with the UGM. Two people from HISP India worked with the UGM and the Yogyakarta health departments over two months and trained staff in the DHIS2 and created awareness which the follow up project benefited from. The pilot project ‘dried up’ because there were no funds and the central support ceased because the supportive director of the MoH department responsible for HIS was replaced (end of 2013).

2013: UiO established an agreement with the Global Fund (GF) for the support of DHIS2 implementation in countries, including Indonesia. The UiO team requested Global Funds for funds to conduct a scoping mission in the country. Following a successful regional meeting in Manila, where the DHIS2 dashboards were demonstrated, the new Indonesia MoH leadership agreed to this scoping mission to help develop a plan for the dashboard system.

Three of the authors went for a 3 weeks mission to Indonesia and worked with the MoH counterparts and the partners from UGM to develop this plan which was submitted to Global Fund, which was subsequently approved as a two years project to start in September 2015. The project consisted of two parts; (1) work with the national information and IT department team (called Pusdatin), to develop a national integrated dashboard; and, (2) work with the provincial health department in Yogyakarta province to develop an integrated dashboard in the province. Together with UGM, the UiO, HISP India and HISP Vietnam conducted a first round of training in Jakarta for the central level and Yogyakarta for the province level in September, 2015. Prior to the training sessions, the team, together with the MoH partners, visited and worked with different health programs at the national level (TB, HIV/AIDS) to learn about their systems and to export data for a first prototype dashboard. This prototype was then used and developed further in a participatory way during the training workshops.

Later in the year, during a new mission of the HISP India and UiO teams, more focused training of the technical staff from different health programs in Yogyakarta was conducted and the prototype was developed further. This was demonstrated during another regional meeting in Bali November 2015. The Pusdatin director and other MoH staff found it interesting, and during a side meeting it was decided that the dashboards should be implemented in selected provinces early 2016, and a plan was made to invite key people from these provinces for introduction and training in January 2016. However, in December 2015, a new reshuffle of staff happened and all plans had to be redeveloped and the future of the project was in flux. However, the objective of developing a shared integrated dashboard turned out to be relatively well entrenched, and the project was kept alive during the turbulent period. Training of province people was planned and cancelled twice before it eventually took place in March, 2016. But the implementation activities planned in the provinces were cancelled due to budget cuts.

The work continued in a different mode with the HISP team working with each of the health programs at central level, as well as with one selected district and the province department in Yogyakarta. This made up a sub-project within the overall project. The Malaria program is one example; they had developed a system for reporting data from the health facilities and all the way to the national level based on Excel. In a database perspective, Excel is suboptimal, and data from health facilities are sent to the district in Excel sheets. In the district the data is aggregated by district and sent to the province, which again send the data to the national level. Only in the districts, therefore, are the data from the health facilities are available, while at the central level, only the district aggregates are available. In order for this system to be able to share and include data from the reporting units (health facilities) and to export data by the level of the health centers, these data first needed to be imported to a database system. Consequently, a system for uploading the excel sheets in DHIS2 was developed for the malaria program, which at the same time provided a comprehensive system application for the malaria program using the DHIS2 platform.

In October 2016, the new ‘Health Systems Strengthening’ Global Fund project was initiated to strengthen HIS and establish ‘dashboards’ in 10 selected districts and the 5 provinces where these districts are located. A taskforce was established with members from Pusdatin, three universities selected as ‘centres of excellence’ in health informatics, UiO, UGM and eleven HSS hired consultants; one for each districts and one national. An online DHIS2 system was established with data from HIV, TB and Malaria and used to train the national pusdatin core technical team (super users), consultants hired by HSS, and selected provincial level members. The rollout of the DHIS2 and dashboard project started in February 2017 following a sequential approach selected as an adaptation of the cycles in action research, where the learning from each cycle is used to inform and improve the next cycle, with each province represent one cycle. At the time of finalising this paper, the rollout was in its first cycle and the authors were engaged in assessing systems at province, district and facility levels, in Lombok.

While the case study is focusing on the main project and the period November 2014–February 2017, without the preparatory project phase the main project would not have been initiated. This longitudinal aspect of action research in large ‘as the river flows’ contexts is a key component of the research methodology, and a key message of this article.

4 Case Study: DHIS2 Dashboard as an “Attractor for Change”

Indonesia is a large country with the fourth largest population globally, with well-developed infrastructure with regional variations. The HIS is fairly typical with multiple vertical health program-specific systems with own platforms working in ‘silos’ with little data sharing. The case study involved building a national level dashboard cross-cutting these programs, which was a non-trivial challenge given the multiplicity of systems, platforms and the absence of shared standards. For example, all systems used different codes for health facilities.

Indonesia has a federal structure where provinces and districts are relatively independent from the national MoH. There are stark contrasts between the developed western part of the country (Java, Bali, Sumatra) and the much less developed eastern parts (Papua). In Java island, all puskesmas have electronic patient record systems, very often locally developed, and often of different types even within the same district. At the national level, health programmes have their own systems, many of them web-based (e.g. TB, HIV/AIDS), but also Excel-based (e.g. malaria). Data from the puskesmas are reported to the districts, from where data is compiled and captured in national systems. All programs have officers at the district level who send data to province and national, with minimum horizontal sharing.

The national level is running a system called KOMDAT which collects data for about 130 national health indicators, based on data aggregated by district. The design limited the district data managers to enter data until they have received a complete set of data from all reporting puskesmas in their districts. The national health insurance agency (BPJS) has established a patient-based system for insurance claims in all hospitals and puskesmas. The BPJS system is not integrated with the other systems. For example, in Lombok Timur district all data had to be re-entered in another system that produced the actual claim as a printout. Also in our visit to Malang district, we saw that the only way to get an overview of data was to meet the officer in charge of each program. While KOMDAT was trying to address this need, it was limited to data aggregated by district, making it impossible to check quality of facility data or to see completeness of reporting from the facilities. Figure 1 illustrates the HIS complexity.

Fig. 1.
figure 1

Complexity as seen in the HIS in Indonesia before the HIS reform intervention

Full size image

The situation differs between districts. For example in Surabaya City they have developed a comprehensive patient-based system covering all programs and health facilities. In all districts in Yogyakarta province, every health centre has its own electronic patient record system to report patient data to the district, where aggregated district reports are generated. In contrast, in Malang district, there is a plethora of systems in use at the facility level and limited integration at the district level.

The MoH and other actors have for a long time acknowledged the need for integration and data sharing, but have believed – due to the complexity arising from the independence given to districts and provinces under the federal structure – it would not be possible. With the dashboard approach, it was believed relevant data could be moved from different systems to a central repository, without disturbing the underlying structures too much. Seeing this potential, the MoH, HSS, UiO and UGM formed a joint project, funded by Global Fund, to develop an integrated dashboard using the DHIS2 platform (see Fig. 2 for the proposed model). A major problem in sharing data across the vertical systems is that they are all using different codes or names for the health facilities. A first step for this integration was therefore to develop a facility register where facility IDs used by the different systems could be mapped to a common reference.

Fig. 2.
figure 2

Proposed dashboard and data warehouse integration model

Full size image

For each of systems that will share data with the DHIS2, database and data models were studied and procedures for data extraction, transformation and loading into the DHIS2 were developed and one off transfer of data was conducted. Data from the HIV and the TB systems were the first systems to be incorporated. Apart from these two systems, most of the health program specific systems are only reporting data aggregated by district to the national level, and are therefore not really useful. Facility based data are typically reported by the systems from health facility and districts to the province level, where the data is aggregated by district and reported onwards to the national level. The rollout of DHIS2 to the 5 provinces therefore has as key tasks in the districts and provinces to identify data sources and establish procedures for data extraction and loading into the DHIS2. The study of data flows in West Nusa Tenggara, the first province in the rollout, showed that several systems, such as for nutrition, mother and child health, immunization and malaria, are reporting facility based data to the province. Meaning that data extraction to DHIS2 at the province level will provide data for all health facilities in all districts in the province. If this pattern is repeated in other provinces it will make scaling easier than if each district would have had to be handled one by one. The challenge, however, will be to establish and maintain routines for extracting data from the identified systems in each province and in some cases also districts and load them in the national DHIS2. Many of the local systems are based on Excel. As long as these systems are based on fixed templates it is technically easy develop systems for uploading the data. Local capacity and ownership will be the key to success. Technical people from the districts and provinces have been trained and take part in all aspects of the work during the rollout. Experience from West Nusa Tenggara shows that technical capacity is available and that managers at district and province level are supporting the initiative because good integrated information is currently not easily available and the ‘dashboard’ appears to be able to fill this gap.

5 Discussion

As a general rule we say that the higher the complexity, and the more embedded in the social context the systems are, the less easy it is to handle complexity. In the following model, we analyse complexity along two dimensions: more or less context-sensitive, and more or less networked or interdependent of other systems.

5.1 The Context-Sensitive vs. Context-Free Dichotomy

Complexity is a function of the nature of interaction of the system with local business processes, their levels of formalization, or standardisation, and the rate of change of the different components. The stronger the interaction and lower the levels of formalisation, the more unique features the system will need to include, making it more context-sensitive. This links with the web model [1] presented earlier, where the social systems model represents the context-sensitive end of the continuum and the discrete entity model the context-free end.

In the HIS domain, level of formalisation is referring to the level of standardization of data and routines and work processes for handling data. In our case, for example, most systems are using their own different codes and names for facilities, making data sharing difficult and illustrating a low level of standardization of meta-data in this area. Overlap of data being reported in different systems and reporting tools resulting in same data being captured and reported multiple times, is a common feature and is illustrating low level of standardisation of data handling routines.

The more networked a system and the more dependent it is on other systems and organisational structures, the higher is the level of complexity, and the less possible it is to apply a linear model of systems development. It is easier to develop a standalone system with no or few dependencies than an integrated system, or a system with multiple dependencies. This is the reason why HIS in countries tend to be fragmented into multiple ‘silos’ as each disease-specific programme makes its own system with little sharing of data. Such complexity can be described into two dimensions. That is, complexity is low when the systems in question are relatively context-free and have low dependencies with other systems. In contrast, complexity is ‘very’ high when systems are both context-sensitive and have multiple connections and dependencies, and in between there is a continuum of more or less complexity. The case study illustrates a system of high complexity, both in terms of the numerous connections and interdependencies with specific health programmes institutional structures, identifiers and others.

Systems development, whether it is about strengthening existing systems or developing a new one, such as the integrated solution in Indonesia, is, at a basic level, about identifying what needs to be done and then doing it, or to define tasks and then carrying them out. The less complex the situation, the more the system can be predefined and development done in a pre-planned manner. The opposite is also true – the more complexity and higher the level of uncertainty, the less of the development can be planned in advance. Of course, roadmaps and general directions of work can always be prepared, but the concrete medium to longer term plans will need to be developed and revised as part of the building process. The aim of the action research in our case is to generate knowledge on a wide range of issues in a participative process together with stakeholders and users, linked to, but not limited to the system development process. One aim of the action research is to explore and generate learning about how data can be used to improve health services. Systems development is used as a vehicle for generating knowledge, but the aims of the action research is wider than the development of systems and system components. In terms of methodology, however, action research in the IS domain have the same challenges as system development in managing uncertainty in complex contexts. The action research field may learn about handling complexity and uncertainty from the rich IS literature.

When uncertainty related to the context and goals of system development is high, experimental approaches, user participation and learning by doing are generally recommended [13, 14]. These are approaches within the concept of cultivation where development may not be controlled totally, but proceeds through user participation, tinkering, improvisation, and gradual development over time is an important approach to managing uncertainty. Attractors may be used as a strategy to enable cultivation over the two following components;

  1. i.

    User participation, experiments around practical prototypes and shared learning-by-doing among users and developers as part of the day-to-day development. Seeking to develop and strengthen attractors for change through prototyping activities.

  2. ii.

    An evolutionary and process oriented approach. Accepting that development will take time and that piecemeal development and learning are needed to help guide further work.

Robust, flexible and scalable system architectures are essential for systems development in contexts of high complexity and uncertainty as it must always be possible to add components. It is therefore important to delay decisions that can close future choices as much as possible. User participation and continuous interactions between the technical team and the users have been an important part of the strategy in the development of the dashboards in our case [15]. This contributed to mutual learning where users learn to what extent and how their information needs could be implemented using the technology, and the technical team learns about the context of use and users’ needs. This created an evolutionary step-by-step approach as new modules and sub-systems were included.

Also in the early phases of the process of the Indonesia project, practical prototypes for demonstrating what can be done with integrated data was an important part of the interaction with the multitude of user groups and health programmes. Working towards integrated solutions in the highly complex context needs to be gradual and with a long-time horizon. The data warehouse and dashboard served as other effective attractors for change, and helped to navigate through high degrees of complexity. This approach was relatively successful because the dashboard was not closely embedded in complicated business processes, and could stand “above” it. Further, its flexible and scalable architecture allowed for adding new data sets and components as new actors joined. Such scalability would not have been possible in more complicated business models. Data input and outputs are relatively simple processes and not restricted to any place in a particular business process. The dashboard was loaded with data behind the scene; the user can access the data through the Internet, from any physical position, and, important in this context, from any place or stage in any business or work process.

6 Conclusion

Quality health data and good HIS are needed for countries to provide quality health services to the population [16, 17]. Poor coordination and fragmented HIS, which we have analysed within the framework of complexity, represent important challenges for developing countries in their endeavors to develop appropriate HIS that can provide quality health data. Better understanding and approaches to handle complexity, the topic and aim of the article, are therefore important research questions. We have presented and discussed the case of Indonesia using the concept of attractor for change to analyse the process to integrate several fragmented HIS using a dashboard approach. The process gained momentum because health programs came to understand that integration was feasible and that they could gain from it without having to give up their systems or independence. The process of integrating provincial HIS within a national framework in South Africa followed a similar pattern; the attractor for change in that case was a combination of the DHIS v1 software and a principle of hierarchies of standards making it possible for provincial systems to integrate with the national system while at the same time being able to independently add their own requirements to the system [4]. Another important learning from the case of Indonesia is that processes driven by the attractor for change and providing a way to handle complexity are basically social processes. Thus emphasising that complexity cannot be handled in a one-to-one specification of e.g. new integrated systems.