Keywords

1 Introduction

This paper addresses the wicked problem of sustainability of ICT for Development (ICT4D) projects. The notion of sustainability gained prominence in the Rio Summit of 1992, and Agenda 21 which was adopted at the summit [1] described sustainability as “Meeting the needs of the present generation without compromising the ability of future generations to meet their needs.”

In the field of ICT4D the issue of sustainability has remained a matter of great concern and has been discussed and analysed by various researchers. The common question of concern is “how systems can continue to exist after external assistance is withdrawn?” Many ICT4D projects fade away as pilots, getting discontinued after the external technical and financial assistance is withdrawn [2], leading to significant wastage of time and resources.

Despite this huge work on sustainability [3], there are limited explanations of how sustainability can be best achieved. The sustainability problem has proved to be wicked, as trying to find solutions in one domain, lead to the emergence of other problems. For example, in trying to address the problem of resource constraints, donor funds could be solicited, which creates further dependencies which challenge sustainability. In the public health sector of LMICs, this problem is especially acute [4]. Blaschke [2] coined the term “pilotitis” to describe the multiplicity of mHealth projects in Uganda which died as pilots. Braa et al. [5] argue that unsustainable projects to not scale, and if they don’t scale they remain unsustainable.

The why of unsustainability remains inadequately understood. Braa et al. [5] have described the “networks of action” approach as a means to strengthen sustainability by promoting collective learning and sharing in the network. However, this approach is limited in explaining the micro level adoption and use processes within an organization. Solutions towards achieving sustainability are often superficially restricted towards providing advice on enhancing capacity through training, or the provision of organizational budgets. This supply side focus is limited, which this paper seeks to address by emphasizing two demand side inter-related processes of “building local ownership” and “leveraging use value from the system.” This paper explores these dynamics within the context of a project around designing and implementing a hospital information system (HIS) for the public health sector in an Indian state.

In the next section, we discuss relevant literature on sustainability, following which the research methodology is described, and then the case study. The case analysis and discussions follow and then some brief conclusions.

2 Sustainability of HIS: Arguing for a More User Driven Perspective

In this section, we discuss some perspectives around sustainability of HIS initiatives, while emphasizing the need for strengthening use or supply side processes. Sustainability, in general terms implies that the system is unable to continue in the long run after external technical and financial assistance, typically from the World Bank and other donors, is withdrawn. This leads to project dying as pilots, a phenomenon termed as “pilotitis” [2]. Braa et al. [5] described lack of sustainability to be the largest problem facing HIS in LMICs, which limits also their scalability.

Identified reasons for unsustainability include lack of commitment from political leadership, poor coordination between donors, fragmented structures, and unrealistic ambitions around what ICTs can do [6]. Heeks [4] describes “design-reality” gaps to indicate the wide chasm that exists between systems designed in the West for organizational contexts in LMICs, leading to a total or partial failure of the system. Wahid [6] describes how different local governments in Indonesia worked with their own systems with poor coordination contributing to sustainability failures.

Naby researchers have described sustainability as an attribute of the IS [3, 6] such as of it being long term, scalable, adaptable, responsive to changing needs, and stable and robust. Such a view of IS inscribed agency disregards agency of people, organizations, and history which also shape sustainability. Wahid argues for sustainability to be better conceptualized as information infrastructures rather than isolated systems, and proposes a triple helix model. Kumar and Best’s [7] conceptualization of sustainability covers five aspects of social, financial, technological, political/institutional and environmental. Furholt [8] analyzes sustainability with respect to supply and demand related dynamics.

Various conditions have been identified for both sustainable and unsustainable systems. Maruster et al. [9] describes sustainability to relate to the adaptability of the system to changes in the environment, the involvement of relevant stakeholders, and supporting the complete knowledge life cycle of the project. Jaccuci et al. [10] identified conditions under which systems are unsustainable, including the neglect of local use of information, narrowly driven interventions and a dominant technical bias in projects. In the context of HIS in Tanzania, Smith et al. [11], see the unsustainability of systems due to the very managerialist manner in which the problem of integration is tried to be addressed, which leads to technically biased short-term solutions which do not endure. Instead, they argue that guidance on the conceptualization of integration should be drawn from also the disciplines of Sociology and Development Studies.

Kimaro and Nhampossa [3] in their analysis of sustainability of HIS drawing upon case studies from Mozambique and Tanzania, point to the problem of financial dependencies of countries on donor funds. This dependency they argue is shaped by three key sets of relationships. The first concerns the relationship between the Ministry of Health (MoH) and the software development agency, the second between the MoH and the donors, and the third between the donors and the software development agency. All these relationships which are crucial for the establishment of the HIS, in practice tend to create dependencies of the host country on external assistance which cannot be sustained after the withdrawal of donor support.

2.1 Sustainability from a User-Perspective

The above brief review of IS/HIS in LMIC contexts points to two sets of issues. One, analysis of sustainability takes on a very supply driven perspective, putting the onus of unsustainability to external support withdrawal or the paucity of funds. Within such a perspective, proposed solutions tend to focus on how to augment the supply side resources, which more often than not may lead to continued and more complex dependencies – the nature of a wicked problem. Two, the onus of unsustainability is placed on the IS perse, as an attribute of the system. This perspective ignores the agency of users, the role of institutions, and many other conditions relevant to building a social systems understanding. For example, new technologies such as mobile phones may be positioned as being more sustainable, reinforcing the attribute view discussed above.

This paper argues to switch the analysis perspective of sustainability by building a demand side focus which places the user at the center of the analysis, and emphasizing two sets of processes. One, relates to the question of how the local ownership of a system can be cultivated over time. Two, concerns how the use of the system relevant to local needs can be made to evolve over time. These two sets of processes are argued to be inter-related, and mutually supporting processes can help develop more rounded insights on the sustainability problem. We analyze these processes in our case study. But first, the research methods adopted are briefly described.

3 Research Method

The research is based on an ongoing project since 2010 into the design, development, implementation and support of an integrated HIS for district hospitals in an Indian state (called NSTATE). Both the authors of this paper have been directly involved in the execution of the project from its initiation to now.

Broadly, an interpretive approach was adopted, where the focus was on understanding the multiple interpretations around sustainability, through discussions with various actors including the health care providers at the hospitals comprised of field nurses, medical doctors and technicians, and also the district and state administrators. Our research also involved a multi-level engagement, talking to the global developers responsible for the open source platform on which the HIS was developed, to the state authorities, and hospital staff. These different groups would view sustainability from varying frames of reference, for example, for INGO sustainability was understood in relation to the period of the contract agreement, while for the state it would involve building ownership beyond the contract period. For users, the meaning of sustainability is embedded in their everyday work context, and their understanding of how the system could ease and improve their work processes over time.

The research was longitudinal in nature with both authors engaged in it from its inception in 2010 to date. During this period they both engaged in the research in terms of its conceptualisation, building the proposal, understanding system requirements, system design, capacity strengthening, institutionalisation, feedback, trouble shooting, implementation support, and much more. Both authors have been both continuously visiting the implementation sites over the years, once in few months, meeting various actors to help understand their expectations, experiences and fears, and how these have changed or not over time. These interactions gave rich insights to different dynamics that shape sustainability. Being following this project for long, we also have had the privilege to see whether the project has actually sustained over time.

Interpretivism [12] was coupled with action research [5], where the aim was to make the system work, in the context of the hospitals, which spanned processes of design, development, implementation and support. The project activities were intensive involving everyday work of meetings, coordinating development tasks, making presentations, documentation, conducting trainings and various others. All these tasks created vast amounts of data which were compiled as meeting minutes, project documents, observations during meetings, and various others. Data collection thus involved diverse and multiple means. Lots of data was also collected through informal means, through casual interactions, phone calls, email exchanges and the like. The project management tool used in INGO served as the repository of all project related information which was available for this research.

Data analysis was complex, as it involved making sense of diverse data collected for varying purposes, and focusing on specific data related to the phenomenon under study. The analysis was largely inductive in nature and spirit, where we allowed ourselves to be guided by the field experiences. However, we took a “top-down” process of analysis, trying to develop holistic interpretations of our combined field experiences over time, rather than using reductionist methods of developing codes in the data and seeking inter-rater reliabilities. We believe our interpretive process provides for a rich and holistic understanding of the phenomenon. Given the analytical focus on sustainability, we focused on those actions and processes which we believed would contribute to the system continuing in the state after INGO, the technical support partner, had withdrawn. This made us focus understanding processes by which users tried to take control of the system or in defining the desired future trajectory of HIS.

4 Case Study Description

This section is divided over two main parts. In the first, we provide an extended discussion of the case study context, which is pertinent to understand conditions for sustainability. In the next part, we provide a narrative of the case.

4.1 Case Study Context

The case/project is based in a hilly north Indian state (anonymized as NSTATE) located in the foothills of the Himalayas. NSTATE has a population density of 123 persons per square km, with about 90% rural population, and much lower than the national average of 382 (2011 Census). This contributed to a high dependence of the population on the public health system, and provides the political impetus to the government to continually strengthen it, including through computerization. NSTATE has the reputation of being stable, inclusive, cohesive, and a well-governed, and was ranked third in the country on the Human Development Index [13].

NSTATE’s commitment to strengthen public services delivery is seen in its efforts to decentralize its information systems, along with the financial and functional powers to the facility level. The state has made investments to use ICTs in overcoming the geographic challenges, such as through high profile tele-medicine initiatives. The state has deployed a fleet of over 200 hundred well equipped ambulances across the districts to ensure efficient referrals. The state has been pioneering in connecting all district and sub-district hospitals with a HIS, which is the focus of this paper.

4.2 Case Study Narrative

In 2008, NSTATE decided to introduce a HIS in 20 district and sub-district hospitals, and floated a request for proposal (RFP) to which 53 companies responded. The RFP specified a ‘perfect and utopian’ system with features including telemedicine, SMS based electronic appointment scheduling, and digitizing of medical images and videos. With no success on the selection of a vendor, the state approached INGO, an Indian NGO working in NSTATE since 2008 on other systems. In 2009, NSTATE signed an agreement for INGO to design, develop and implement the HIS project.

A District Hospital (DH) is typically a 100 to 300 bedded hospital with multiple specialties catering to a daily load of about 800–1000 outpatients and 40–50 inpatients. The systems in a DH are largely manual, thus making computerization a formidable challenge. INGO adopted an incremental approach where patient registration and billing were selected as the first modules to be implemented, followed by the more complex OPD and IPD modules. The plan was after the system was successfully piloted in the reference hospital, the same system would be taken to the other 19 hospitals.

Right from initiation, a participatory and incremental approach was adopted, including for modules prioritization, conducting requirements, design and implementation. An important design guideline was not to ‘just’ automate processes, but also to add value by ‘re-engineering’ existing processes. This required the design process to be based on strong mutual collaboration and dialogue, where the users were not assumed to be passive providers of requirements, but as actively engaged in co-constructing them. The process followed included INGO understanding the work and information flows in a department, followed by discussions, returning with mock-up screens representing their understanding of the requirements, making revisions based on user feedback, presenting final design for signoff and then initiating module development. The proposed design was very context sensitive with strong user involvement.

Given that this was first experience of the hospital of using real-time electronic HIS for recording all patient transactions, the INGO team was intensively present in the hospital. In the first week after “go-live”, the INGO team made a roster of its five member team to be in the hospital before start of work to ensure LAN, printers, systems were up and working. This process continued for a month before INGO started discussing with the hospital to try and create a local team, and two members were identified. The team started to be trained following an approach of “learning by doing”, and slowly their skills expanded from doing routine support tasks for hardware, to operating the server and conducting internal capacity building tasks. Over the period, the hospital team with their responsibilities was formalized. More into the future, the team started to generate data on system use and circulate to hospital staff.

It took about one-and-a-half years for INGO to implement the integrated suite of 10 modules in the HIS and stabilize use processes. They could then initiate scaling processes to the other hospitals which were located in other cities of the state, typically involving a day’s travel from where the reference hospital was located. As a result of these time and resource constraints, it was not possible to replicate the intensive process of support and capacity building carried out in the reference hospital in the other hospitals. An approach was improvised which involved INGO enrolling staff from the reference hospital like data entry operators and pharmacists to support training of counterpart staff from the other hospitals. In this way, some networks of learning and sharing were enabled, allowing for enhanced user ownership.

Processes of creating local teams in each hospital then ensued. Interestingly this was not something which was mandated by the state, rather a self-initiative which slowly spread as learning within the ‘networked-hospitals’. These processes of transition spanned over five-years, still ongoing, starting from local teams doing basic hardware fixes to taking on complete system use and related processes.

As technical and capacity building processes stabilized, the focus shifted to the use of data and analysis of questions relating to what does the data mean, how can I start looking into my data, and what can we say about improvements in hospital performance. We take an example to explain this maturing process. In its second year of implementation the reference hospital initiated a system of routing every new patient to general OPD after registration, rather than directly sending them to specialised OPDs (as was the practice earlier). Only after the examination if the doctor in general OPD felt the need for specialist, could the patient be sent to specialist OPD. This change was triggered after the hospital management started looking into data of OPD queues, waiting time for patients at specialist OPDs, and identifying patients who came only for medical examinations for purposes of getting a drivers’ license or to support a job application. By focussing on the critical patients requiring longitudinal care (such as Diabetes and Hypertensive), the load of creating electronic medical record for each patient was reduced.

Soon we saw requests from doctors for customising auto-generated reports showing patients seen in the OPD with diagnosis and patient profiles to help discern disease and demographic trends. Reports were demanded by doctors to see turn-around time for patients, which helped the hospital to re-visit work processes to make it efficient for the patient to complete all transactions in a day, thus reducing travel demands on patients. A repercussions of this process was extending the lab and pharmacy timings.

Later in the process, the first ‘data use’ workshop was organised by the state team which was attended by all hospital heads and the Secretary, Health. The initial discussions were around trying to understand why are there more new patients registered as compared to re-visit patients which was atypical. One of the reasons identified was the laziness of the registration clerks who did not make enough effort to search a patient, and rather registered the same patient each time as a new one. This led to further training for the data entry clerks. The questions of ‘improvement in quality care’, and how has the ‘patient’ gained from ‘computerisation’ became important topic of discussion in the data use workshops and review meetings. Each hospital shared experiences and suggestions to address patient quality care questions. This led to requests from staff for creating system enhancements such as adding a screen to prompt the registration clerk to ask patients if this was first or revisit; printing clinical summary for every patient, and giving laboratory results with reference ranges for the tests. Currently, the state has initiated discussions on integrating the HIS with a national identification system (Aadhar) at registration and also linking public utility portal for patients to pre-book appointments at respective hospitals. These enhancements, when materialized, would significantly help to improve the user friendliness of the HIS.

5 Case Analysis and Discussion

The case study has focused on describing two sets of processes, one relating to evolving local ownership, and the second on enhancing data use value.

5.1 Evolving Local Ownership

Important to enhancing local ownership was the manner of project initiation which helped frame future trajectory of ownership. After experiencing the failure of the initial tendering process, the state adopted a more “open” process where the definition of the requirements was a component of the agreement and was not pre-determined. It provided the space for user agency to be exercised, which set the stage for a user driven participatory process, which took place in an iterative and evolving manner. Such an approach, made allowances to the fact no one had absolute knowledge – INGO about the system, and the users about their requirements – and practical, useful knowledge about both needed to evolve through a mutual process of dialogue and co-learning. And most importantly, the state provided the time and the enabling environment for this process to evolve. An acknowledged constraint to this process was that during the initial stages, it was INGO who knew the system, which rang the danger of them framing requirements at the expense of the users. But this framing to a certain extent was inevitable, and was addressed by both sides being conscious of this issue, and secondly, by the users engaging in a process of “proactive participation.”

Some examples of enhancing ownership are provided. Initially, printing paper was provisioned by the state, but slowly with time, the hospital started provisioning their own paper. Networking of the hospitals was initially planned for by the state office, but with time, the hospitals started to create their own contracts with third party vendors for the same. Similar processes were also seen in the development of Annual Maintenance Contracts for hardware repair, and the provision of capacity building, where internally people started to support each other. The local team of data entry operators employed for registration and billing, soon started to undertake other tasks such as hardware support and also training internally for other hospital users. The state took some policy measures by making training on the HIS a mandatory task for entering medical doctors. At the level of a department in the hospital, for example, in the Laboratory, some technicians took immense pride in ensuring that the supporting systems like printers and papers are operational, so that they are able to give the printed lab results to the patients, who really liked that output and demanded it.

The open source platform (OpenMRS) on which the HIS was developed also enabled the possibilities for the users to enhance ownership. Given that there were no license restrictions to modify the system, INGO could speedily respond to user requests. As users saw their requests being responded to, they felt confident to ask for more and build their ownership of the system. Such developments were not uniform across and within hospitals, But a general trajectory could be discerned relating to evolving ownership at the three levels of the state, hospital facility and the individual.

5.2 Evolving Use of Data

The initial use of the system was largely a process of automation – where existing manual systems were computerized. However, this automation was not done as a “copy and paste” process from the paper to the computer, but was accompanied with a “judicious design” which involved making process changes, and a selective combining of paper and computer. For example, billing which was previously done at different points in the hospital was modified to a centralized one to enable automation of the billing process. Similarly, the OPD slip was printed with a pre-defined format where the tests and procedures showed up on the slip, and the doctor would tick mark those required for a particular patient by hand. This hybrid automation was to help deal with the problem of high patient loads, and limited availability of computers.

Over time, there was an increasing level of HIS use at the departmental and hospital levels, enabled by the state convening workshops where managers emphasized the importance of using the HIS for improving patient care and overall hospital administration. The workshop attendees were told in no uncertain terms, that the use of the HIS was not voluntary, and needed to become an integral part of work. Users were shown statistics of HIS usage in the hospital, gaps and achievements were identified, and suggestions taken for improvements. INGO facilitated the process by generating the required statistics from the HIS. With hospital wide use becoming more widespread, the state authorities gained confidence in trying to also enable wider use outside the scope of only the hospitals. Examples included the decision to take a slimmed down version of the HIS to the primary health care (PHC) facilities, which currently work with aggregate and not patient based data. Other examples includes efforts to integrate with the Aadhar and the “Outpatient Registration System” discussed earlier.

5.3 Building Synergies: Process of Evolving Ownership and Enhancing Use

We conceptualize these two sets of processes described above to be mutually self-reinforcing, with one supporting the other, and each itself being also enhanced through this support. We depict this figure schematically and then discuss it (Fig. 1).

Fig. 1.
figure 1

Self-reinforcing mechanisms of sustainability

Full size image

The two sets of processes can be seen to be mutually reinforcing. The more the hospital takes ownership of the various processes, the more they develop the capability to understand the possibilities offered by the system, and how it can help to support their everyday work. With this growing maturity, they are able to shape use processes including defining what is needed. The more they see their specific needs are catered to by the system, the more is their motivation to take increasing ownership. In this way, these two sets of processes can be seen as mutually self-reinforcing. The converse is also true, with limited ownership, the HIS is seen as an external implant without direct relevance and value, it will be seen as a burden and users will withdraw from it.

The important question is of how can these self-reinforcing mechanisms be designed? The case points to the need to not have detailed design specifications but to allow it to evolve through a collaborative process. Instead, the design or plan could be seen to be operating at a more meta-level, being rather open in nature, with the positive possibilities of the users being able to drive it forward in the way they considered relevant. A pertinent example in this regard was how specifications were not defined in the tender document, but were allowed to evolve with time and use.

Important, is also the role of the enabling context, which arguably was supportive towards encouraging these two sets of process. Two aspects of this enabling context were important. The first was a progressive state, committed to strengthening public health systems, and promoting decentralized and open forms of governance. The second was the role of INGO, the technical partner of the state, who were deeply rooted in an ideology of participatory design and the use of open source platforms. Taken together, these two sets of processes within the setting of an enabling context had positive implications on participation, providing the technical potential for evolution, with positive impacts on sustainability.

6 Conclusion

This paper has argued for more user-focused analysis of HIS sustainability in LMICs. This is argued to be a more realistic approach to try and achieve sustainability, as supply side approaches by themselves are inadequate. Seeking more funding from donors may only create new dependencies. While the dominant focus of existing literature is on the supply side, this paper has reversed this perspective with a largely user focused view. This adds to the discussions of Unwin [14] who discusses market and society led approaches in ICTD projects. We hope this paper provides an interesting path for future analysis of sustainability of HIS in LMICs.