Keywords

FormalPara Learning Objectives
  1. 1.

    Define global health informatics.

  2. 2.

    List and describe some global policies that support public health in low-income, resource-constrained countries.

  3. 3.

    Describe public health informatics interventions that have been successfully developed and deployed in low-income, resource-constrained countries.

  4. 4.

    Cite examples of public health informatics interventions that have been developed and deployed in a low-income, resource-constrained country, add value, and have been sustained.

  5. 5.

    Articulate challenges surrounding the use of information technology in healthcare in a low-income, resource-constrained country.

  6. 6.

    Describe solutions to common problems confronted in the deployment of systems in low-income, resource-constrained countries.

Overview

Public health professionals’ functions are rapidly expanding beyond their countries’ borders. Many academic centers are recognizing the importance of global health and are creating programs to train students to meet this growing demand. Global health centers and institutes also are being created to focus on the research and programmatic efforts needed to understand the burden of disease worldwide, as well as the financial, political, medical, policy, workforce, and infrastructure issues surrounding any solutions. Due to this emerging interest by the public health community, we need to understand where the intersection between global health and informatics occurs. For many years, the promise of what technology can do to alleviate suffering and support disease surveillance and other public health activities took precedence over understanding the environment in which the technology has to function. People and their participation in the implementation of the technological solution are critical for success. In resource-poor environments, the deployment of technological solutions faces other challenges for success. Lack of stable electrical power, availability of Internet connections, and a workforce that can support the information technology remain barriers to successful implementation. Yet, through experiences in the implementation of information technology as supported by international donors and the US President’s Emergency Plan for AIDS Relief, lessons are being learned to move forward towards the benefits that global health informatics can bring.

Introduction

As the world becomes more interconnected through travel, migration, and economic forces, many health issues are being increasingly recognized as a concern not for only one country, but for all nations. Infectious diseases such as lung infections, tuberculosis, and human immunodeficiency virus (HIV), and chronic diseases such as diabetes, cancer, and ischemic heart disease, are leading factors of death worldwide [1]. Sudden outbreaks, such as severe acute respiratory syndrome (SARS), H5N1 influenza, and novel Ebola virus have captured the world’s attention [2]. The neglected tropical diseases, so named for lack of adequate response, also are gaining attention and, in some cases, severity [3, 4]. For example, global incidence of severe dengue, a mosquito-borne viral infection with no specific treatment, has grown rapidly in the past four decades, from only nine countries before 1970 to more than 100 countries in 2010 [1]. None of these health issues are limited to particular continents or countries, socio-economic class, race, or gender. They are health issues that are important to all people.

Informatics has been involved in infectious disease [5], chronic disease [6], and neglected tropical diseases [7, 8]. Surveillance systems, laboratory information systems (LIS), data warehouses, electronic health records (EHR), and other electronic health information systems (HIS) are used by public health professionals in detecting and responding to infectious disease outbreaks and supporting the continuity of care for chronic disease. Since global action is necessary to effectively reach the highest attainable standard of health and well-being for the world’s people, global health informatics is necessary to tackle these worldwide health issues.

Global Health

Global health is a term that has gained widespread use. For many years, international health was a fixture in the public health vocabulary to describe public health activities outside of one’s country or between countries. As times and situations in the world have evolved, the terms to reflect these global changes have become more refined. However, to date, no single definition of global health has been widely adopted. As often occurs in a relatively new field, there appears to be ambiguity and elusiveness about what the field is. Most of the literature about global health suggests that global health includes health-related issues that cross national boundaries, are common to all people, and for which solutions can be translated to many different communities.

A good place to start in looking at the field is to examine its genesis. Often, the terms international health and global health have been considered to be synonyms, and many considered it unnecessary to differentiate between them [9]. Conversely, others believe that differentiating the two terms helps global health practitioners develop clearer policy and direction. Brown et al.’s view is that the term international was meaningful in the late nineteenth and early twentieth century when the focus was “control of epidemics across boundaries between nations,” and the relationships regarding policies and practices of public health between the sovereign nations were central to solving health problems [10]. As the focus developed into a consideration of health needs of people worldwide “above that of particular nations”, with increasing involvement of non-governmental organizations (NGOs), the term global health better described the worldview. As part of an initiative from the Consortium of Universities for Global Health (CUGH) Executive Board, an examination was made to highlight the fundamental similarities and differences between global, international, and public health [11]. They determined that attributes of geography, cooperation, populations, access, and disciplines offer the best insights. In global health, the health issues transcend national boundaries, solutions require worldwide cooperation and involve both prevention and clinical care, health equity is a necessary pursuit among all nations, and collaborations are developed within and among multiple disciplines (Table 31.1).

Table 31.1 Comparison of global, international and public health
Full size table

The Koplan et al.’s [11] definition is frequently cited and has been adopted by the 2011 Expert Panel on Canada’s Strategic Role in Global Health [12]:

Global health is an area for study, research, and practice that places a priority on improving health and achieving equity in health for all people worldwide. Global health emphasizes transnational health issues, determinants, and solutions; involves many disciplines within and beyond the health sciences and promotes interdisciplinary collaboration; and is a synthesis of population-based prevention with individual-level clinical care.

Global Health Informatics

Global health informatics uses many different terms, concepts, and technologies. A thorough scan of the multiple scientific and grey literature databases and multiple Internet search engines indicate that there are few instances that use the full term – global health informatics. This begs the question: what is global health informatics? We propose that global health informatics is the informatics discipline focused on empowering people to use appropriate technology to provide information-based solutions with a global perspective that support health care for all. The mission of global health informatics is to share informatics knowledge, skills, and research, and foster local innovations to promote highest standards of health for all with an emphasis on low income, low resource countries and the medically underserved.

The Influence of Global Health Policy

Over the past 30 years the state of the world’s health has improved significantly. Life expectancy rates have increased and quality of life has improved in almost all countries. Public health measures, new medical technologies that have been readily adopted, and improved health literacy have all played a role in this increase. Collective global health actions also have been central to increasing the standard of health for all people. The foundation for these changes can be traced back to two critical policy statements: the 1978 WHO Declaration of Alma-Ata, which called for urgent action by governments and the world community to promote health of all the people of the world, and the 2000 United Nations (UN) Millennium Declaration, which built upon the ideas of the Alma-Ata Declaration more specifically by outlining eight goals, each with measureable objectives to be achieved by 2015 [13]. Of these eight goals, now known as the Millennium Development Goals (MDGs), three are directly related to health – Goal 4: Reduce child mortality rate; Goal 5: Improve maternal health; and Goal 6: Combat HIV/AIDS, malaria, and other diseases.

The establishment of these concrete goals provided the catalyst and focus for many other UN agencies and related programs. Countries also have used the framework of the MDGs to target their developmental aid funds, such as Sweden (SIDA), Norway (Norad), Germany (GIZ), United Kingdom (DIFD), Canada (CIDA/IDRC), Australia (AusAID), and the United States (USAID/HHS-CDC). International organizations, such as the World Bank, Global Fund, and Asia Development Bank, have used the MDGs as a focus for funding in-country projects. During the last decade, many US-based NGOs began to play a major role in supporting initiatives to reach the MDG health-related goals, including the Bill and Melinda Gates Foundation, Rockefeller Foundation, Ford Foundation, and the William J. Clinton Foundation [14].

For many decades, the United States (US) has been actively involved in working with other nations to improve global health. In 2003, President George W. Bush called for the creation of the President’s Emergency Plan for AIDS Relief (PEPFAR), formally authorized by US Public Law 108–25, United States Leadership Against HIV/AIDS, Tuberculosis, and Malaria Act of 2003 [15]. The authorization was for 5 years and up to US$15 billion for HIV care, treatment, and prevention, and included support for capacity building and strategic information (i.e., surveillance, monitoring, and evaluation) in 15 focus countries, and for initiatives by the Global Fund to Fight AIDS and UNAIDS. This initiative is considered to be the largest commitment by any nation to combat a single disease in history [16]. The 15 focus countries were among the countries hardest hit by HIV disease: Botswana, Cote d’Ivoire, Ethiopia, Guyana, Haiti, Kenya, Mozambique, Namibia, Nigeria, Rwanda, South Africa, Tanzania, Uganda, Viet Nam, and Zambia. In 2008, US Public Law 110–293, Tom Lantos and Henry J. Hyde United States Global Leadership Against HIV/AIDS, Tuberculosis, and Malaria Reauthorization Act of 2008, re-authorized PEPFAR for an additional 5 years and up to US$48 billion to expand to 49 countries and regional programs. Building on the established prevention, care and treatment, capacity building, and strategic information programs, PEPFAR II emphasizes country partnership and ownership, and strengthening of health systems. PEPFAR remains the largest funder of global health initiatives and has many successes in reducing the burden of HIV/AIDS in the focus countries. In fiscal year 2011, PEPFAR directly supported HIV testing and counseling for more than 9.8 million pregnant women, and care and treatment for nearly 13 million people including more than 4.1 million orphans and vulnerable children [17].

Health Information Systems in PEPFAR

From the beginning, the use of electronic health information systems was a critical component of the PEPFAR implementation. High-quality data are essential to HIV prevention, care and treatment, policy development, resource planning, and accountability. Understanding the burden of disease requires functioning surveillance and aggregate indicator monitoring systems. Providing effective patient treatment requires consistent and available patient, laboratory and pharmacy data. All of the PEPFAR focus countries had major deficiencies in their national health information systems. During the first years of PEPFAR, the aim was to assist countries in developing health information system infrastructure that would support the national and PEPFAR HIV/AIDS programs. Health management information systems (HMIS) were developed to help report the 41 core indicators that were required as a condition of funding. These indicators and other nationally-oriented indicators were also used for policy development, program planning, implementation, and identification of best practices. These systems frequently were paper-based at the facility and district-levels of a country, and then captured into an electronic system at or before arriving at the Ministry of Health. In the countries with electronic data systems in facilities or districts, the effort was placed on harmonizing data elements and core data sets. As health information infrastructure matured in countries, patient-level data collection systems were implemented to be used for both patient care and for routine health information for surveillance, monitoring and evaluation, and resource planning.

Over the past 8 years, counseling and testing have identified millions of people with HIV/AIDS and anti-retroviral treatment has extended the life span of people living with HIV. Due to this impact, electronic systems have become more necessary to manage the volume of patient data created by longitudinal health records. Electronic medical records (EMR), laboratory information systems (LIS), and other patient-level systems are being implemented.

This growth in patient-level systems has created a greater need to standardize functional and technical requirements for health information systems, design systems that facilitate and enable interoperability between different systems (e.g., EMRs, LIS, pharmacy, and others), facilitate linkage and de-duplication of records, and strengthen data security, privacy, and confidentiality measures. This work will be done partly through innovative technical solutions. Most of the work will be accomplished through strengthening strategic planning and governance, developing in-country human capacity, and on-going evaluation of health information system implementations to identify effective informatics practices, efficiencies gained, and health impacts.

Building partnerships with countries to create sustainable health information systems is a foundational goal of PEPFAR II. Working with Ministries of Health to build infrastructure and human capacity, PEPFAR has encouraged countries to assume more leadership responsibility. The focus has shifted from health information systems developed and supported by PEPFAR to a situation where Ministries of Health recognize the necessity of leveraging and coordinating the investments in health information infrastructure and systems among donors and develop country-level strategic health information system plans with measureable goals and objectives. Across Africa, Asia, and Latin America, huge advances have occurred in information and communication technologies, and Ministries of Health are seeking to take fuller advantage of these tools to improve service delivery.

How these policies have played out in countries has depended on many factors. Some countries have a more stable governmental infrastructure and are able to establish long-standing health information system policies; others have a more fluid governmental situation where leadership changes frequently and health information system policies may be retracted or radically changed. Environmental factors including lack of navigable roads, potable water, sanitary conditions, electrical power, and sheer distance between communities can impact countries’ motivation and ability to prioritize or implement an electronic health information system. The small gains in developing and retaining informatics skills and knowledge in-country may not be enough to sustain the systems. Sustainable and country-owned health information systems are the goal; the global informatics community is the supporting actor.

Below are two case studies that describe the evolution of health information systems to support care and treatment of people with HIV/AIDS in two low-income, resource-constrained countries. These cases provide insights into lessons learned, technologies used, and policies needed. They are illustrative of many health information system implementation endeavors within low-income, resource-constrained, and HIV/AIDS-burdened countries.

Case Studies of Health Information System Implementation

A Decade of Public Health Informatics in Malawi

Background

Malawi is a landlocked country in sub-Saharan Africa with a population of approximately 15 million people. The Malawi Ministry of Health provides healthcare at no cost through a network of government health facilities comprising roughly 400 health centers, supported by 24 district hospitals and 4 central referral hospitals. In 2007, health adjusted life expectancy at birth was 44 years. The World Health Organization (WHO) ranks Malawi 185 out of 191 in overall health system performance [18]. Roughly one in 17 children die before reaching 12 months of age and one in 11 die before reaching 5 years of age (2010). Roughly 11 % of the age 15–49 population is HIV positive (2009). Malawi, like many low- and middle-income countries, is hampered in its ability to provide healthcare by a severe shortage of medical staff, medications, and diagnostic resources. Malawi has the lowest ratio of doctors per capita of any country (~1 physician per 50,000 capita in 2012). In 2012, spending on healthcare was US$65 per capita [19].

The Central Monitoring and Evaluation Division (CMED) housed within the Ministry of Health is responsible for the collection, analysis, and reporting of key health indicators from all health facilities in Malawi. Prior to 2000, the collection of morbidity and mortality data relied on the completion of pre-printed forms by clinicians, nurses, and clerks. Outpatient diagnoses were recorded on a monthly tally sheet, and inpatient data was abstracted from a three-part discharge form. A team of data entry clerks entered data from the paper forms into computers using custom-developed data entry software written in dBase IV. Following a national review in 2001, a series of paper-registers were introduced, replacing tally sheets and discharge forms as the primary form of data collection. This shift to using registers for data collection required that health facilities manually aggregate their own data before reporting it. Particularly at district and central hospitals, the registers were increasingly being completed by lay clerks with little or no training in health or medical terminology, rather than by clinicians and nurses. To produce district-level and national-level reports from the manually-aggregated totals derived from paper registers, the District Health Information System (DHIS) software was adopted [20].

Issues and Solutions

Our initial work piloting informatics solutions with the Malawi Ministry of Health started in 2001. We started our investigations at Kamuzu Central Hospital (KCH), a 700+ bed referral hospital located in Malawi’s capital city of Lilongwe. We observed that ward clerks had no training in medical terminology, but were required to both transcribe medical data as well as map diagnoses into indicators (e.g., Diabetes was mapped into an indicator called Other Non-communicable Diseases of Public Health Importance), raising questions about the completeness and accuracy of the reported data. Clinicians were over-burdened with patient care, and perceived documentation for “statistical” purposes as outside the scope of clinical work and therefore not part of their responsibilities. We hypothesized that an electronic information system designed to support the delivery of healthcare in a resource-poor setting may provide clinicians and nurses with tools that would augment their ability to efficiently and effectively deliver healthcare, while collecting data as a transparent byproduct of system use. We proposed the idea of a rudimentary electronic medical record (EMR) that would be used by clinicians in real-time at the point-of-care, and moved ahead with the development of a system to be piloted in the pediatric department at KCH.

As we developed hardware and software solutions for our pilot work, we identified several potential and two critical barriers. First, health workers had little or no training in using computers. We believed that this could be mitigated by emphasizing simplicity and usability as part of the system design [21, 22]. Recognizing that to develop computer literacy among the users would take time, we opted for an entirely touchscreen-driven user interface. Secondly, power outages at the hospital were frequent, and would be a significant threat to building a reliable system. To address this, we developed a power back-up solution around locally-available deep-cycle batteries used for solar power installations. However, rather than charging them from solar panels, we simply connected them to a charger powered by the national grid. This solution, combined with the efficient low-power touchscreen computers, allowed the system to run for 36–48 hrs. in the absence of power from the grid [23].

System Description

Our pilot system was aimed at supporting the care of children attending the outpatient clinic as well as those admitted on the wards at KCH (216 beds). At that time, no records were kept for patients seen in the outpatient setting. Paper charts were created for patients admitted to the ward, and for the most part could be retrieved during the normal workday on subsequent admission, provided the patient’s name and date of last admission were known. For our pilot, we aimed to create a permanent electronic record of outpatient visits, capturing a limited set of diagnostically-relevant signs and symptoms and a diagnosis. For inpatients, we chose only to capture the date of admission, discharge diagnosis, and the date of discharge, from which length of stay could be derived. While this seems trivial in the context of a western incarnation of an EMR, it allowed us to do a basic proof of concept. Furthermore, it represented an improvement over the current paper system, allowing clinicians in both the outpatient clinic as well as on the wards to see a patient’s past medical history, albeit limited.

The greatest impediment to creating this time-series of patient visits was re-identifying the patient on subsequent visits to the hospital. Malawi has no form of national registration system, eliminating a national ID number as a possible unique patient identifier. Many patients were illiterate, making it impossible for them to verify the spelling of their name. Many older patients knew their year of birth, but not the month and day. We chose to implement a simple patient registration system that allowed a clerk to capture a limited set of demographic information from a patient and generate a unique patient identifier. This information was stored in an electronic Master Patient Index as well as printed on an inexpensive adhesive label to be affixed to a patient’s health passport, a small patient-kept booklet issued to patients by the Ministry of Health. To facilitate ease-of-use and reduce the chance of transcription or data-entry error, the patient’s unique identifier was represented in barcode form as well as in human-readable text on the label. The inpatient module primarily tracked admissions and discharges and was operated by clerks. The outpatient module was developed with the intention of clinicians’ use, but was not well-adopted and subsequently discontinued as the system was both too onerous and not sufficiently detailed [24].

Following discussions with pediatricians at KCH as well as the College of Medicine in Blantyre, we decided to focus on strengthening the admission process. We created an admission module modeled off a paper-based admission guideline developed at the College of Medicine [25]. The module systematically stepped the clinician through the assessment of the patient and creation of a treatment plan, including medications to be prescribed and diagnostic tests to be ordered. Time-saving features of the module included automatic medication dosage calculation based on the child’s weight and age, and generation of specimen labels for all samples to be drawn for laboratory testing. On completion of the process, the system printed an admission note, a pre-populated medication administration record, and a nursing plan template. We felt that this was the first example of a true point-of-care application working in a low-resource setting, and concluded that there was sufficient evidence that this approach could be extended to other clinical domains.

In 2003 and 2004, we undertook two small demonstration projects to determine the potential use of information systems for supporting ancillary services in the hospital. Working with pharmacy technicians in the KCH pharmacy dispensary, we developed a simple medication dispensation tracking system. At that time, tracking of medication usage was done at the level of bulk containers. For example, the pharmacy would document that the dispensary had received 5,000 tabs of Ibuprofen, but not how many or to whom those tabs had been dispensed. While only a small portion of the medications had barcodes printed on the packaging, we were able to create a simple barcoding system by labeling the shelf on which the medications were stored at the dispensation window. We arbitrarily assigned medication ID numbers to all drugs in the pharmacy and printed barcoded labels for each section of the shelf. Using these barcodes to identify medications being dispensed, and patient identifiers in barcode form on the patients’ health passports, pharmacy technicians were able to record patient-level dispensation of medication in real-time using a touchscreen computer located at each of the four dispensation windows in the pharmacy.

Working with the radiology department at KCH and with the assistance of a consultant radiologist, we developed and deployed a simple touchscreen-based system to improve the labeling of radiology films. Prior to this intervention, x-ray films were labeled in the top left-hand corner by transferring the patient’s name from a hand-written note onto the x-ray film using a photo-imprinting process at the time of developing the film. Legibility of the label was poor, making it hard to identify to which patient the film belonged, and making filing of films almost impossible. Our solution used a touchscreen computer, barcode scanner, and thermal label printer located in the radiology department to retrieve the patient’s demographic record from the master patient index, select the type of study ordered and referring department using on-screen prompts, and print a legible adhesive label to first be used for photo-imprinting onto the film, and then be affixed to the film envelope for clear identification.

In 2005, with support from the United States Agency for International Development (USAID), we developed and piloted a touchscreen-based electronic pharmacy inventory control system (ePICS) to manage medication inventory at the stockroom level. The system combined features found in advanced inventory management software, with the high usability offered by the touchscreen user interface.

Supporting HIV Care and Treatment

In 2003, working with a Malawian NGO providing voluntary counseling and testing (VCT) services, and with support from the US Centers for Disease Control and Prevention (CDC), we developed a touchscreen system designed to guide counselors through the counseling process, while collecting data to be used for monitoring and evaluation (M&E) [26]. This system was deployed at three VCT sites in Malawi, where it was used by dozens of counselors with no prior computer training. This apparent success increased our confidence that electronic systems, if appropriately designed, could be used in real-time in low-resource settings. In 2004, working with the Lighthouse Clinic, an HIV Center of Excellence in Malawi, our focus on HIV moved into the development of a prototype EMR for managing patients receiving antiretroviral therapy (ART). This was our first encounter with designing a system to accommodate multiple points of care (patient check-in, vital signs station, nurses exam room, clinicians exam room, and pharmacy), and multiple workflows. This was a large undertaking, and pushed the limits of both our capacity and our capabilities. While still under development there were many revisions to the system specification, partially due to changes in treatment regimens and guidelines, and progress was painfully slow.

In mid-2005, we made the decision to change our development platform to take advantage of free and open source software as much as possible. This was motivated by the vision that these systems, if successful, would be adopted by the Malawi Ministry of Health, and the cost of scaling-up could be reduced if licenses costs for operating system and database management systems could be eliminated. An additional appeal of open source was the emphasis on community-based support rather than vendor-based support, which we perceived to be a better model for supporting systems in low-resource settings.

By 2006, Malawi’s national response to providing antiretroviral therapy was in full swing, with some of the more well-established clinics managing several thousand patients. Overwhelmed with the challenges of generating quarterly and cumulative cohort reports for programmatic M&E, the Department of HIV and AIDS within the Ministry of Health issued a request for proposals for the development of an electronic system to automate the generation of reports at high-burden sites. Working in collaboration with the Ministry of Health and through a cooperative agreement with the CDC, we created a prototype point-of-care EMR system informed by our previous experiences to manage patients receiving ART that was developed around newly-introduced clinical practice guidelines, and the newly introduced cohort reporting M&E framework, and using the Ruby on Rails open-source software stack with parts of the OpenMRS system, particularly the data model [27, 28]. The EMR was piloted at two district hospitals in 2007. Refining the system, and particularly creation of the detailed cohort reports, took much longer than anticipated and was complicated by changes in national guidelines and the introduction of new drug regimens. However, following a lengthy pilot period, the system was adopted by the Ministry of Health in 2010 for national scale-up to high burden sites pending the availability of funds. By the end of 2012, the national ART EMR was deployed at 21 high-burden ART clinics (including the Lighthouse Clinic) collectively managing care and treatment for roughly 98,000 patients [23].

Beyond HIV

Having established a model to support HIV care and treatment in low-resource settings using an EMR, we explored the feasibility of supporting the management of chronic non-communicable disease in the same way. In 2009, in collaboration with the International Union Against Tuberculosis and Lung Disease and the Malawi College of Medicine, we developed and piloted an EMR to support care and treatment for patients with diabetes mellitus. The system was piloted at Queen Elizabeth Central Hospital in Blantyre, and later expanded to the remaining three central hospitals in Malawi [29]. In 2011, clinical modules were expanded to support antenatal care, maternity, and under-5 services. As of 2013, work is in progress to address a broader package of non-communicable diseases.

A Model for Sustainability

These efforts had prioritized clinical benefit and enhanced monitoring and evaluation over cost. In 2010, we modeled the potential return on investment that might result from deploying these systems. Focusing on the specifics of KCH, we projected potential annual savings in three distinct areas that could be generated by the use of EMR modules. Using estimated costs for installing and maintaining a hospital-wide EMR system at KCH, and projected savings over a 5-year period, we constructed a financial model to determine the potential return on investment. Based on this model, we were able to demonstrate a complete recapture of the initial investment costs of a hospital-wide system in less than 3 years [30]. This finding generated some optimism that the use of information technology in low-resource settings might actually be a cost-saving intervention, and we believe that this important finding may be the basis for the long-term sustainability of these systems.

Lessons Learned

Findings were mixed. While many of the systems we developed and piloted could not be sustained, others have been integrated into the clinic workflow.

False Starts and Experience Gained

The outpatient module developed in 2001 was so constrained in its functionality that it resembled an electronic register more than an electronic medical record system. Once we recognized the poorness of fit, we discontinued the use of this module. The pediatric admission module was significantly more successful, running for more than 18 months before being discontinued. Despite the apparent goodness of fit, and the positive feedback from users, it was difficult to keep the system running. Unlike other systems we had developed, the pediatric admission module relied on the use of laser printers. At the time we had no technical solution to powering laser printers from a backup source of power (now solved). Consequently, during periods of power failure clinicians would have to complete the admission note by hand. Other problems arose when printers ran out of paper, and there was no paper available to refill the tray. These problems frustrated clinicians. The system was finally discontinued when both laser printers were damaged by a power surge and there was no funding to replace them. KCH pharmacy staff reported the ePICS system deployed in 2005 was greatly beneficial to the smooth running of the pharmacy. However, without a directive from hospital management, the pharmacy staff was unable to discontinue using the paper-based stock system, and doing both was far too time-consuming. Struggling with the burden of maintaining parallel systems in the absence of a strong champion, staff use of ePICS became inconsistent several months after the ePICS system went live. This resulted in inaccurate stock levels in the system, and a general agreement to terminate the pilot. Both the pediatric admission module and the ePICS module were essentially demonstration projects that had no clear strategy to sustain them.

Exemplars for Sustainability

Despite these challenges, several systems have been sustained. The patient registration system is now in its 12th year of use, having issued more than 1.6 million unique IDs to patients. The specimen-labeling component of the pediatric admission module was implemented as a stand-alone module and deployed at the Lighthouse Clinic in 2003, where it continues to generate labels for CD4, full blood count, and TB sputum testing at both the main site as well as its sister clinic, the Martin Preuss Center. The radiology module has been in continuous use at KCH since 2005. Both systems are stand-alone, simple in their functionality, and have a strong value proposition for the user. Yet despite their simplicity, these systems generate a large volume of data that can be reported in multiple ways. Not unlike the discontinued systems described above, both the radiology system and specimen labeling system were demonstration projects with no clear model for sustainability. We believe that the continued use of these systems is a result of the low overhead required for maintenance and support, combined with the strong value proposition for the user.

Keys to Success

Establishing a patient identifier scheme and master patient index at the beginning simplified the development of other modules, as it provided a level of interoperability through which different modules could share patient information. Designing systems for simplicity and usability was a core design principle and appears to have been a prudent decision. Health workers with little or no previous exposure to training in the use of computers quickly became proficient in the use of the touchscreen systems. To increase the sustainability of the systems being built, a strategic decision was made early on to develop a local team to build the systems, rather than rely on international contractors and consultants. The availability of experienced local software developers was limited, requiring that many of the developers be trained on-the-job. This slowed down productivity, often resulting in milestones being missed. Emphasis on adapting hardware to work with a centralized 48 Volts Direct Current (DC) power backup system required extra work, but ultimately paid off in increased system up-time in the presence of grid power failures. Despite these challenges, we believe this 10+ year legacy of systems in Malawi validates our vision for local development and ownership.

The Past is Prologue

Looking back over a decade of work in Malawi, had we expanded our demonstration projects beyond medications and laboratory testing, we may have had a broader impact on health systems strengthening and healthcare delivery, rather than the somewhat narrower scope of managing HIV and non-communicable diseases that has been achieved to date. Our experience reinforced the importance of addressing the needs of the system users as the highest priority. In low-resource settings, where supervision is minimal or nonexistent, the mandated use of systems does not work and shifts the strategy for sustained system use to having a strong value proposition for system users.

We started this work in Malawi with the hypothesis that small, highly-usable systems designed to address challenges in process or work-flow identified by health workers can add value, fully recognizing that the use of these systems would create large amounts of valuable data, but setting the primary purpose as process improvement. From time to time, we deviated from this strategy, creating large monolithic solutions, often seduced by the appeal of collecting data for later benefits rather than addressing a more immediate problem, and without a clear understanding of the mechanisms (such as decision support) that these systems were trying to leverage at the point-of-care. As we move ahead, we must go back to basics, leveraging the lessons we have learned and refocusing on the mechanisms through which EMR use at the point-of-care can both improve patient outcomes and reduce healthcare delivery costs. This will require a strategic approach at the country level, with involvement and cooperation of the Ministry of Health, technical partners, and funding agencies. The development of a strategic plan for the evolution of eHealth solutions in Malawi will serve both as a road-map for the future and a model through which we can share ideas, facilitate discussions, and validate design decisions and priorities.

Public Health Informatics in Rwanda: The OpenMRS EMR Project

Background

Rwanda is a small, landlocked country in central Africa with 11 million people. In 2005 Rwanda had a gross domestic product (GPD) per person of less than US$230 per year, one of the lowest in the world. Infectious diseases remain among the largest health challenges, along with maternal and child health, trauma, and mental health. Non-communicable diseases, including oncology and heart disease, are of increasing importance. HIV prevalence was 3.3 % in 2005, causing a major burden of disease. Substantial progress has been made by Rwanda over the last 7 years with GDP per person rising to US$582 in 2011, and while HIV prevalence remains about 3 %, 108,113 HIV patients were receiving ARV treatment in June 2012, the second highest rate in Africa [31]. Challenges for the Rwandan health system were very similar to those in Malawi, including lack of roads and communications to remote clinics, a severe shortage of trained healthcare workers, and limited investment in clinic infrastructure. There was limited knowledge of the disease burden in communities, including prevalence of HIV, and a need to track lifelong care for those patients. The existing processes for managing clinical data were also similar to Malawi, with a focus on multiple paper registers and paper charts that were often difficult to locate.

History of Partners in Health Informatics Projects in Rwanda, 2005 Onward

Partners In Health (PIH) was first invited to work in Rwanda by the Ministry of Health (MOH) in 2004, to help develop a strategy to support the expansion of HIV care to remote rural areas. The MOH were aware of PIH’s successful provision of HIV care in the remote and extremely impoverished Central Plateau area of Haiti and they wanted to achieve the same success in the large, underserved rural areas of Rwanda [32]. In 2005,the first PIH supported Rwandan clinic was established in Rwinkwavu hospital in the east of the country – an area with exceptionally poor infrastructure. In Haiti, 2 years previously, PIH had developed and deployed a web-based electronic medical record (EMR) system to support HIV care [34]. This EMR was adapted to the needs of the Rwandan health system. We found however that the level of customization was extensive and time-consuming; changes included the language, demographic data and address structure, form and report design, and workflow, and further extensive modification would be required to support other disease types. At this time the PIH informatics team had started to collaborate with the Regenstrief Institute in Indiana and their AMPATH project in Kenya, as well as the South African Medical Research Council (MRC), to develop a new, flexible, open source EMR platform – OpenMRS. This offered a more sustainable way of building EMR systems in resource poor environments. The decision was made to pioneer the system in Rwanda and Kenya. The first version of OpenMRS went live in Eldoret, Kenya in February 2006, followed by Rwinkwavu hospital in August that year, and shortly after, in Richmond hospital in KwaZulu, South Africa.

Technical, Organizational and Functional Description of the OpenMRS

OpenMRS is an open source software project written in Java. It uses the MySQL database, and can run on Linux or Windows [27]. It is designed around a “concept dictionary” of structured data items that defines virtually all the data that can be stored in OpenMRS (other than patient demographics). An unlimited number of concepts can be added to the system without modifying the underlying software, and concept dictionaries can be standardized or shared. Unusual for an EMR system, it has a modular architecture that allows new functionality to be programmed without modifying the core system. More than 130 modules are available in the OpenMRS module repository, ranging from core functions such as form creation and reporting tools, to more customized code for specific implementations. However, it is not necessary to write new modules to implement the system. Core groups of paid programmers have supported OpenMRS from the beginning, with Rwanda playing an important role in the development of the core code as well as customization and field testing [33]. The international OpenMRS community is playing an increasing role in development, testing, and support [28]. Until recently, with the exception of AMPATH, most implementations of OpenMRS have been small, usually one or more clinics running the system on a single desktop PC. Sites with good Internet access can use an offsite web server, simplifying support of individual clinics and sharing of data, such as laboratory results and patient transfers. Most sites in low-income countries require a local copy of OpenMRS to provide “good enough” performance, which implies stable power, information technology (IT) support, and a strategy for offsite data backup.

Current Status and Uses of OpenMRS at IMB

As of March 2013, OpenMRS was used in more than 30 MOH clinics supported by Inshuti Mu Buzima (IMB, meaning Partners In Health in the Rwandan national language) in Eastern and Northern districts of Rwanda, covering a population of almost one million people. All sites collect HIV patient data for clinical use, analysis, and reporting. This includes capturing data on intake and follow-up forms and clinical flowsheets, with the help of data entry staff. Over the last 2 years, this has been extended to cover voluntary counseling and testing (VCT) and prevention of mother-to-child transmission (PMTCT) programs and pediatric HIV care. Data are used for a range of purposes including:

  • Supporting clinical care through printed patient consult sheets (Fig. 31.1) and direct lookup of patient records by clinicians

    Fig. 31.1
    figure 1

    An HIV consult sheet from Rwinkwavu hospital

    Full size image

  • Creating reports to the MOH and funders

  • Clinical research on HIV care

  • Assistance with forecasting medication requirements

A patient registration module is used in Rwinkwavu for all primary care patients presenting to the health center. This module is based on the designs and experience of the project in Malawi and includes the ability to print a barcoded ID card for each patient. In addition to HIV care, OpenMRS is used to support the care of heart failure and diabetes patients in some sites.

Current Status and Uses of the System at MOH

After observing the OpenMRS implementation in IMB sites, in 2009 the MOH decided to initiate a rollout of the system to several hundred clinics in mostly rural areas of the country. With support from the Global Fund to Fight AIDS, Tuberculosis, and Malaria (GFATM) and the International Development Research Centre of Canada (IDRC), the MOH hired seven Rwandan programmers who had graduated from a PIH/IMB run training program. The initial clinical focus was for HIV and primary care. Then they started to customize the systems to support new functions for pharmacy and supply chain management, laboratory data management, billing, and reporting. OpenMRS was set up in four initial sites in 2010 and then the rollout was scaled up in 2011. As of March 2013, more than 200 clinics have the system installed and training of staff is ongoing.

Informatics-Related Issues Faced and Challenges Overcome During the Implementation

OpenMRS hardware requirements are simple; the basic version can be downloaded from the OpenMRS web site and run on a basic PC. There are several key challenges in getting the system running smoothly, which are very similar to those described for Malawi. Unstable power can be very disruptive, especially if clinicians rely on the system during clinics. Recently, smaller clinics in Rwanda have started to use laptop computers as servers, providing several hours of running time and ensuring that the system shuts down safely. Lack of Internet connectivity makes supporting OpenMRS more difficult and prevents use of one central server to share data. Initially, IMB provided satellite Internet access to clinics and hospitals, greatly simplifying the rollout and support of information systems, but this connection was expensive and variable in quality. More recently, the cellular phone GPRS network has been used to link clinics to a central server in Rwinkwavu hospital over a virtual private network. However, this connection is still too slow to allow direct web-based access to the OpenMRS server so a module was created that allows data to be synchronized between instances of OpenMRS and a central server over an intermittent connection. This has greatly improved the performance of OpenMRS in remote clinics, as it now allows clinical reporting across all sites in a district, facilitates pushing laboratory results out to clinics, allows lookup of records for patients transferring between clinics in the district, and provides an automatic offsite data backup. The main disadvantage is that synchronization requires more technical support than a standard installation, an issue we are still working to improve. As OpenMRS is rolled out to additional sites, it will be particularly important to track system performance, including down time, data entry and completeness, and daily use, and to evaluate the cost of system implementation and support. Tools are being developed to track these parameters and transmit data to a central site for monitoring.

Improving Reporting Tools

Reporting and data use is a core function of OpenMRS, whether for clinical care, program management, or research. The flexibility and power of the OpenMRS concept dictionary comes at the price of making certain types of data export and analysis more difficult than simple database designs. A number of different reporting tools have been developed over the past 5 years to address these challenges. The OpenMRS reporting framework is the most flexible example, and was partly developed in Rwanda with support from the Rockefeller Foundation. It is used extensively at IMB and increasingly at the MOH. The challenge now is to improve the flexibility of this framework and to simplify its use by non-programmers. OpenMRS data is increasingly used for research studies such as a recent analysis of HIV care outcomes at IMB [34] and a large clinical epidemiology study in Peru [35].

Clinical Evaluation

As the use of OpenMRS has grown in Rwanda, there has been increasing interest in evaluating the system and assessing what benefits this investment has brought to the health system. A key requirement in the management of HIV is access to CD4 counts that indicate the status of the patient’s immune system. At IMB, it was found that many CD4 counts in patients’ charts were out of date. Amoroso and colleagues studied the impact of adding a module to OpenMRS to allow direct entry of CD4 counts in the laboratory [36]. The findings showed that the number of CD4 counts that were out of date fell from 25.7 to 16.7 % (p < 0.002). Were et al. [37] in Kenya studied the impact of giving clinicians access to printed clinical summaries from OpenMRS that contained warnings of low CD4 counts. Their results showed that ordering of repeat CD4 counts increased from 38 to 63 % (p < 0.0001). More extensive evaluation is planned of the clinical impact of the system.

Capacity Building and the EHSDI Training Program

Finding Rwandan programmers with good Java programming skills proved to be very difficult. In 2008, with support from the IDRC, PIH set up a training program for programmers to obtain hands-on skills in enterprise Java programming and OpenMRS development [38]. A total of 34 programmers graduated over the 3 years to 2011. Many graduates are now working with the MOH, IMB, and other organizations, developing and implementing OpenMRS.

Vocabulary Management

Over the last 2 years, a standard OpenMRS concept dictionary has been created by a team at Columbia University combining the concepts from several projects including IMB, the MOH, AMPATH, and the Millennium Villages project. The Rwanda Health Enterprise Architecture (RHEA) project is using that dictionary and a set of custom vocabulary management tools to create a core data set for maternal health projects using OpenMRS and other systems, including RapidSMS.

The Future for the System

The initial use of OpenMRS in resource-poor environments nearly always involved clinicians collecting data on paper forms that were later transcribed by data entry staff. Outputs were usually in the form of printed patient summaries, consultation sheets, and reports. As in Malawi, clinicians at IMB-supported sites were keen to access clinical data directly to ensure that they had the most up-to-date clinical findings, laboratory results, and drug regimens. This required the addition of a clinical summary for HIV care, and training for the clinicians on searching for patient records. It also required upgrading the infrastructure and IT hardware to ensure that systems were available consistently on clinic days. These improvements were made possible by a grant from the US Centers for Disease Control and Prevention (CDC).

Supporting a Broader Range of Diseases

Most of the initial implementations of OpenMRS were designed to support HIV care, with many also covering TB co-infection. Adding the capability to manage new clinical areas can be as simple as adding one or more forms and reports and a patient summary. However, more extensive customization and programming may be required for more complex care processes, particularly if healthcare staff use the system directly. The first example of this was OpenMRS-TB, designed to support the care of Multi-Drug Resistant TB (MDR-TB). It includes custom tools for managing and viewing laboratory and medication data, a variety of WHO specified reports, and a custom timeline for visualizing the whole treatment process (Fig. 31.2) [39].

Fig. 31.2
figure 2

Timeline for the MDR-TB management including laboratory data and drug regimens

Full size image

Similar customization was carried out by IMB in 2012 to support the care of oncology patients in Rwanda. Programming was also required to support patient registration and management of barcoded ID cards, as well as capturing clinical diagnoses and problems. An additional challenge is to program these clinical components as generalizable modules that can be reused worldwide, which requires substantially more investment in design, programming, and testing than simply customizing the system for one site.

Rwanda eHealth Enterprise Architecture

In 2010, the Rwanda eHealth Enterprise Architecture Project was started as a collaboration between the MOH, Jembi Health Systems in South Africa, the Regenstrief Institute in Indiana, IDRC, the Rockefeller Foundation, and the PEPFAR program. The goals of this project are to create an overarching plan for all eHealth systems in the country, with clear specifications of their functions, and using medical data standards and tools to ensure interoperability. The first stage of implementation of this project is underway in the Rwamagana district in the south east of the country, to support maternal health care. Data are being collected by clinic and hospital-based staff using OpenMRS, as well as community healthcare workers using mobile phones and text messaging with RapidSMS software. An instance of OpenMRS is installed on a server in the national data center and functions as a shared health record, combining data from local OpenMRS installations as well as from RapidSMS. Three national registries provide shared resources for patients, providers, and facilities, and there is a terminology server. The goal is to roll this system out nationally and extend it to cover other disease areas including HIV, TB, and primary care. OpenMRS installations managed by MOH and IMB will be included over time. An additional project is using a data standard called SDMX-HD to send reports from OpenMRS to a web-based national reporting system called TRACnet.

Hospital Information Systems Based on OpenMRS

In addition to supporting clinics with OpenMRS the MOH is starting to focus on the needs of district hospitals. Starting with a government-run hospital in Kigali, they have implemented tools for management of patients in a range of clinical services. These include modules for:

  • patient registration system (described above)

  • medication prescribing, dispensing, and inventory

  • laboratory orders and results

  • capturing diagnoses and problem lists

  • forms for a range of clinical services

The OpenMRS community is also starting to focus on direct use of the system by clinical staff in hospitals, with a particular focus on a new teaching hospital built by PIH at Mirebalais in Haiti. This should provide additional tools for the pioneering projects in Rwanda.

Broader International Rollouts Based on Rwanda Experience

Rwanda and Kenya have been the main sites for much of the early development and implementation of OpenMRS. Rwanda’s contributions include the first use of OpenMRS on Linux, and the first deployments of many core modules including HTML form entry, the reporting framework, and data synchronization. Other key initiatives have been direct clinician viewing of patient summaries and implementation of patient registration with barcoded IDs (building on the experience from Malawi). The MOH team has pioneered work on a broader national rollout of OpenMRS and initial use in hospitals. There is now a large and growing international community developing and implementing OpenMRS. More than 50 developing countries are currently using OpenMRS clinically; many are carrying out development of new modules or contributing to improving the core system. Key initiatives include the development of standard concept dictionaries shared between implementations and countries, and tools to standardize core dictionaries for maternal health care. Many projects are linking OpenMRS to a range of mobile phone-based software tools including ODK, CommCare, Sana, and OpenXdata. The Kenyan MOH is currently rolling out OpenMRS to 300 rural clinics, building on the experience in Rwanda with help from programmers at PIH. Going forward, top priorities for the OpenMRS project are to simplify the setup of OpenMRS in new projects and provide reusable tools for managing diseases like HIV, primary care, and maternal health, as has been done for MDR-TB. The core goal will continue to be the use of data from OpenMRS for clinical care, program management, forecasting of supplies, and clinical research.

Rwanda has played a critical role in the development and evaluation of OpenMRS. The software developed for the projects here and the lessons learned are helping many projects around the world decide whether or not to use the OpenMRS software. With the current work on rolling out OpenMRS nationwide, the direct use of OpenMRS by clinicians, the development of tools for oncology, and the RHEA project, this pioneering role is likely to continue.

The Way Forward

The growth of global health informatics is continuing. Policies and funding are shaping the course of global health informatics as the field seeks to better understand the impact that solutions have on health outcomes of the medically underserved. We promote an approach that is both top-down and bottom-up. Working in global health informatics requires an implicit recognition that the differences in countries’ characteristics, health challenges, and priorities have a direct bearing on how information systems should be developed and used. When developing health information systems in low-income, resource-restrained environments, simple, focused solutions can work well in specific sites but are usually of limited general value. More comprehensive and adaptable informatics solutions are necessary to scale to multiples sites, multiple diseases, and large numbers of patients. Keeping a focus on the clinical and programmatic needs, not the technology, is essential to achieve better acceptance, adoption, and sustainability. Remembering that the little things do count, such as stable power, printer repair, and even paper, leads to success when a system is deployed in the field. Building local expertise in system development and maintenance is necessary for on-going success and system sustainability. Determining the value add that the users will gain from the system and then creating a system that provides the added value is critical. Interoperability between systems is necessary to be able to provide comprehensive patient care and conduct accurate disease surveillance. Monitoring and evaluation of the performance, cost and impact of systems is essential to allow resource and policy decisions based on data. The world of health, information, and technology is a rapidly changing place. Exciting opportunities exist in keeping pace with that change and discovering new informatics solutions to provide health for all.

Review Questions

  1. 1.

    There are many different ways to view the discipline of global health informatics. What are some of the defining attributes that set it apart from other informatics disciplines?

  2. 2.

    Policy is foundational to global health informatics. Why is policy so important?

  3. 3.

    When might eHealth and mHealth tools be appropriate to apply?

  4. 4.

    The Malawi case describes how clerks are used to capture admission and discharge information at Kamuzu Central Hospital. What factors may compromise both the completeness as well as the accuracy of this data?

  5. 5.

    Describe three challenges to operationalizing electronic information systems designed to support patient care in low-resource settings.

  6. 6.

    The Malawi case study describes a system developed to create computer-generated order labels to attach to test-tubes being sent to the laboratory for testing. Describe the mechanisms through which this might reduce the length of stay for a patient admitted to the hospital.

  7. 7.

    The pediatric admission module described in the Malawi case incorporated automatic medication dosage calculation based on the child’s weight and age. Speculate how this system may benefit (a) the clinician, (b) the patient, and (c) the hospital administration.

  8. 8.

    In developing the electronic medical record system to support HIV care and treatment, a point-of-care solution was selected over a paper-based data collection system with retrospective data entry. What was the rationale for this decision?

  9. 9.

    How can the benefits of creating a common database of patients be achieved when clinic sites have unreliable network connections?