Approaches to Handling Complexity in Public Health Information Systems in Low and Middle-Income Countries
In this last section, we summarized the key issues related to complexity and how the Expanded PHI approach can help to design strategies to manage HIS complexity in LMIC contexts.
We have argued that the context of public health in LMICs is characterized by being less formalized and structured than, say, in hospitals in industrialized countries. The concept of outreach services in public health is in contrast to the more formalized ‘inward’ reaching services carried out within the walls of a hospital. Outreach activities aiming at, for example, providing services to children and mothers that are not reached by the facility-based health services illustrates the openness in terms of the scope of data collection and systems, the linkages to society, and context of use in population-based systems.
In the model presented, complexity is seen to increase with context sensitivity and number of connections or interdependencies with other systems. We have discussed several concepts used to understand how higher levels of complexity influence HIS development and data quality: poorly formalized business procedures; fuzziness of data; a web of connections to the social system; open-endedness in terms of the scope of the system; and higher levels of context sensitivity. In system development, these aspects of complexity may be translated into levels of uncertainty related to the context and goals of the system to be developed, as well as to the system development process as such.
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 more of the development can be properly planned and defined before it is actually carried out. The opposite is also true—the more complexity and higher the level of uncertainty, the less 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.
When uncertainty related to the context and goals of system development is high, experimental approaches, user participation and learning by doing are generally recommended (Andersen et al. 1986; Davis 1982). These are approaches within the concept of cultivation. When the uncertainty is high, development may not be controlled totally, but a cultivation strategy which incorporates user participation, tinkering, improvisation, and gradual development over time is an important approach to managing uncertainty. Attractors may be sought, created as a strategy to guide the direction of design and development. This cultivation approach may be seen as having two main components:
i) User participation, experiments around practical prototypes, and shared learning by doing among users and developers as part of the day-to-day development. Seek to develop and strengthen attractors for change through prototyping activities.
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. During the first phase of developing the national system in South Africa during 19972000, user participation in the hands-on development of prototypes was an important part of the strategy (Braa and Hedberg 2002), involving iterative and continuous interactions between developers and users. This contributed to mutual learning where users learn to what extent and how their information needs could be implemented using the technology, and the developers learn about the context of use and users’ needs. By default, the development of the national HIS in South Africa witnessed an evolutionary step-by-step approach as new modules and subsystems 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 have been an important part of the interaction with the multitude of user groups and health programmes. Working towards integrated solutions in the highly complex context of Indonesia will need to be gradual and with a long-time horizon. In Ghana, we have seen that the process of strengthening the system and improving data quality has been carried out as an inclusive data review process, starting at the facility and district levels before moving to the regional and national levels. This process has resulted in improved data quality, which again has convinced other programmes and stakeholders, such as TB and HIV/AIDS, to join the process. All these examples are about cultivating an evolutionary process of system development, and also showing that attractors for change can help create a momentum for change. In Ghana, the attractor was the DHIMS 2 system, which has already achieved results in strengthening data quality.
Similarly, the data warehouse and dashboard have served as other effective attractors for change, and have helped to navigate through high degrees of complexity. Integrated statistical data warehouse and dashboard systems have been relatively successful because they are not closely embedded in complicated business processes, and can stand ‘above’ it. Furthermore, they have a flexible and scalable architecture, allowing for adding new data sets and components as needs arise and new actors join. Such scalability would not have been possible at a general level in the context of more complicated business models. Data input and outputs are relatively simple processes and are not restricted to any place in a particular business process. The dashboard is loaded with data behind the scene; the user can access the data through the internet, from any physical position, and, particularly in this context, from any place or stage in any business or work process. Of course, the data being presented may be more or less useful, but to design useful dashboards for different user groups is relatively easy. Data collection is more complex, but provided resources, it is achievable. In cases similar to Indonesia, where a lot of existing data sources are electronic, collaboration and agreements between system owners and other stakeholders are the keys to success. Technically, it is relatively easy to import data into a data warehouse installed on a central server. Paper-based data collection and data sources, however, have their own complexities and problems related to data quality, which are not solved by a system on a central server. But the procedures for collecting routine data from health facilities have been established over many years in most countries and are fairly formalized, and easy to computerize.
Our Expanded PHI approach emphasizes the need for modern technologies, such as the use of central servers for cloud computing, sensitively coupled with thoughtful design and development approaches that understand and factor in the complexity that characterizes this domain.