Analytical concepts

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. CAS pays particular attention to the study of how order emerges, rather than being created through design. Central to the emergence of orders is the notion of attractors. A typical example of an attractor is a shared standard that is followed by many. For example, MS Windows, for good or for bad, created order in the personal computing area. The creation of ‘attractors for change’ (Plsek and Wilson 2001) may be used as a strategy to bring about changes in areas with limited agreement, standards, and stability, such as fragmented HIS. Scaling is another central concept in complexity science, which is a useful lens 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’

(Eoyang 1996, p. 36).

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 (Braa et al. 2007). In their web models, Kling and Scacchi (1982), give a theoretical framework to understand why and how large information systems tend to be tied to the social context through a complex web of associations, as contrasted with the discrete-entity model view of information systems being socially neutral technical systems.

‘When an analyst uses a discrete-entity model to understand the computing capabilities of an organisation he usually begins by asking, “What kind of equipment and facility do they have?” In contrast, analysts using a web model begin by asking: “What kinds of things do people do here?” ’

(Kling and Scacchi 1982, p. 9).

The web model emphasizes historical legacy and context in system development:

‘Since information systems are bound up with the infrastructures available, and since these evolve over time, computing developments are shaped by a set of historical commitments. In short, web models view computing developments as complex social objects constrained by their context, infrastructure and history’

(Kling and Scacchi 1982, p. 69).

The other relevant concept for understanding HIS is of 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 clean slate (Dahlbom and Janlert 1996). As the metaphor indicates, cultivation is about interfering with, supporting, and controlling natural processes that are already there, as in nurturing and watering a plant to nurture an ‘organism’ with a life of their own (Ciborra 1997). As a strategy in systems development and design, cultivation is thus seen as in opposition to structured methods and consisting of incremental and evolutionary approaches, and ‘piecemeal engineering’ (Popper 1986). While cultivation represents an approach within the social system model, structured engineering methods are linked to the discrete-entity model.

We illustrate this approach where attractors cultivate change as a way of addressing complexity with an example from Indonesia, as featured in Case Study 7.1.

Case Study 7.1 Indonesia: DHIS 2 Dashboard as an 'Attractor for Change'

Indonesia is a large country with the fourth largest population in the world, with a well- developed infrastructure showing some regional variations. In terms of HIS, the country is fairly typical; while a number of vertical health programme-specific systems have moved to the cloud and the amount of data have increased, the systems remain as separate silos with little to no sharing of data. In this case, we describe a newly initiated process under the leadership of the MoH to develop an integrated dashboard for the sharing of data across health programmes and systems, starting from a point where no shared standards existed. All systems are, for example, using different codes for health facilities, making it impossible to share or compare data at that level. This agreement to work together on the process of integrating their systems is, on the one hand, based on a genuine need for shared information and a shared ‘trust’ in the dashboard concept. The dashboard is understood as an achievable approach for integration without disturbing the underlying systems too much, or without too high a cost. We’ll use the dashboard as an ‘attractor for change’ concept to analyse the case.

Indonesia has a strong federal structure where provinces and districts manage their own health services and budgets 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 health centres (called ‘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 health centres are reported to the districts, where it is then compiled and captured in national systems. The HIV/AIDS system for example, runs patient-based systems at the health centre level and reports aggregate data to the district where it is captured in the national system. All programmes have their officers at the district level who process data for sending onto the province and national levels. However, despite all data passing through the districts, there is no shared data repository.

The national level is running a system called KOMDAT, which collects data for about 130 national health indicators, based on data aggregated by district. In addition, the recently established universal health insurance agency (BPJS) has established a patient-based insurance system in all hospitals and gradually all health centres. A key problem identified is that at no level is any systematic overview provided of the integrated data across health programmes, administrative levels, and health services. For example, when visiting Malang district, we saw the only way to get an overview of data was to meet the officer in charge of each programme; a situation repeated at the province and national levels. The one system trying to address this need is the KOMDAT, but since it is based on data aggregated by district, there is no way to check data quality at the facility level, and the system is therefore not trusted by the administrators.

We provide below our conceptualization of the HIS and its underlying complexity in Figure 7.1.

The situation differs between districts. For example, in Surabaya City they have developed a comprehensive patient-based system covering all programmes 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. Data are, however, reported from facilities on paper and in some cases MS Excel (e.g. for immunization), and compiled as district Excel sheets with data

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

Fig. 7.1 Complexity as seen in Indonesia's HIS before the reform intervention

Proposed integration model using DHIS 2

Fig. 7.2 Proposed integration model using DHIS 2.

by facility. When reporting to province, however, data are aggregated by districts. The district is the only place where data by facility may be found, while the province only has data by districts, available in Excel sheets in email attachments.

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—that it would not be possible. At the third general meeting of the Asian eHealth Information Network (AeHIN) in Manila in December 2014, dashboards based on DHIS 2 including maps and graphs from several countries such as Bangladesh and Laos were demonstrated, reflecting a proof of concept of what could be realistically achieved without disturbing the underlying structures too much. Seeing this, the Indonesian team saw its feasibility for their country, and the MoH and national insurance organization (BPJS) agreed to form a joint project to develop an integrated dashboard using the DHIS 2 platform (see Fig. 7.2 for the proposed model).

A proposal for funding was submitted to the Global Fund and accepted, and the project started in 2015. During the initial work, agreements have been made with HIV/AIDS, TB, and malaria programmes to start with importing their data into the DHIS 2 data warehouse, to be used for visualizations through the dashboard. In parallel, work has started with BPJS, where the data structures are more complex, and cannot be imported directly into the data warehouse. A first step for this integration is to develop a facility register where facility IDs used by the different systems can be mapped to a common reference.

The project seeks to manage complexity by creating integrated dashboards in Indonesia, but it is still early days to produce tangible results. Some systems have completely moved to the warehouse, others have held out and continue stand-alone, while others are making the change partially and gradually. However, the interesting aspect here is that the ‘dashboard’ has started to emerge as an ‘attractor for change, with the different stakeholders converging around it to discuss, practice, and visualize change.

In the next case study (7.2), we discuss another example of attractors of change and the cultivation of change in another context—the implementation of the District Health Information Management System (DHIMS) in Ghana.

 
Source
< Prev   CONTENTS   Source   Next >