Keywords

1 Introduction

To provide effective public health services, the right health commodities, such as medicines and equipment, must get to the right people at the right time [24]. To manage the distribution of commodities, relevant information is needed at all steps of the supply chain – from the point-of-origin to the point-of-consumption. Who needs how much of a certain commodity? Where can it be found, and at what price? How can we get it to where it is needed? In addition to the direct need of logistics information for supply chain management, commodity data and indicators are also important for the routine monitoring and evaluation of health services in general. Are our immunization rates influenced by stock-outs? Do the facilities have the right staff to administer these commodities? Information systems are clearly essential for the proper management of the supply chain and the evaluation of it in the health sector.

Despite the apparent need for well-functioning information systems to support the supply chain across the different levels of the health system, such systems continue to be challenged [13, 17], including weak sharing of data amongst stakeholders, fragmentation of logistics data, a plethora of paper and electronic forms used in different locations, incomplete data on dispensing to patients and competing software for supply chain at the various levels [9, 10]. There have been many initiatives to improve supply chains and corresponding information systems in developing countries, but they have been limited in scope and do only in a limited way address the linkages to other relevant information systems [17]. A broader approach seems necessary. At the same time, a good understanding of the various parts of the supply chain information systems in developing countries is absent from the existing literature. The international organizations supporting many developing countries in this regard tend to focus only on limited parts of the system, and their definitions of such systems vary.

The health commodity supply chain is a multi-level system, that include producers of commodities at the global level; procurement, finance, and quality assurance mechanisms between national ministries and the producers; warehouses and distribution mechanisms in-country; and finally mechanisms around dispensing commodities to relevant beneficiaries, such as patients requiring medicines. The information needed for each of these tasks vary in their level of detail, and should also support the correct forecasting and replenishment of commodities. Given the above, it is not surprising that a range of different information systems are in use within a single country [10]. But questions remain related to the architecture these systems form and how they are integrated (or not) and interoperate (or not).

To get a better understanding of information systems for health commodity supply management, we take as a point of departure several international efforts to strengthen supply chains in developing countries. Examining their use of LMIS, we see that this can be understood as one out of many information systems involved in the supply chain. One of the aims of this paper is thus to explore what an LMIS is, and how it interacts or not with other systems. We do this by presenting two cases of LMIS, from Uganda and Tanzania. We further discuss and draw lessons learnt related to the information systems from these cases that can be generally applicable to strengthen health commodity supply chains. To guide our research on LMIS, we have sought to answer the following research question: What are appropriate information systems architectures for public health supply chain management in developing countries?

While integration is a common prescription for health information systems architectures [2], we argue for a critical perspective on the needs for integrating logistics management information systems across the different levels of the health system and with information systems from other domains. By architecture, we mean how various information systems work together, offer complementary and/or overlapping functionality and the related structures supporting their integration, interoperability and evolution over time. For us, architecture is not “theoretical” drawings or blueprints, but the actual and operative information systems on the ground, how they are interrelated and how they share functional responsibilities.

The rest of the paper is organized as follows. First, we look at common understandings of LMIS as a concept to establish an understanding of its scope. Then we present the methods applied in our study of LIMS in Tanzania and Uganda, followed by the empirical findings. This is followed by a discussion related to the current understanding of LMIS, before we conclude with a more detailed view on LMIS architectures and draw lessons learned for their design.

2 Relevant Literature on LMIS

As countries are making efforts at strengthening their LMIS, they move toward digitizing previously paper-based systems. Currently there is not a lot of academic literature on the subject of LMIS, what little there is does not have an IS focus, but is mostly concerned with assessing the supply chain as a whole, challenges in general related to supply chains in developing countries [1, 6, 16]. There has also been work done to improve the understanding of the different roles within health logistics [15]. Over the last decade, some large international organizations have led this work on a normative level, spearheaded by inter-agency initiatives such as the USAID sponsored Deliver projectFootnote 1 and SIAPS programFootnote 2, and the United National Commission on Life Saving CommoditiesFootnote 3. We start by examining these and related organizations’ understanding of LMIS, before presenting our own definition of it.

Despite the frequent references to LMIS among the international organizations, which fund and lead supply chain projects in developing countries, a clear definition of LMIS is lacking. It is often treated as everything related to information that supports the supply chain, and also as an off-the-shelf product with seemingly little, if any, complexity. Such a broad understanding hides the various aspects of the health commodity supply chain and the variety of informational needs and can translate into poorly designed information systems.

The broadness of the existing definition is well illustrated by USAID: “A logistics management information system (LMIS) collects, processes, and reports logistics data. A well-functioning LMIS provides decision makers throughout a supply chain with accurate, timely, and appropriate data” [18]. Given a view of the supply chain as everything from raw material supply for medicines, to the individual patients [13], this definition includes users at local, national, and international levels. Little difference is made between the supply chain at large and LMIS, but a narrowing of scope is provided by more recent documents from USAID. Defining both supply chain and logistics management, they state that “the supply chain includes global manufacturers and supply and demand dynamics, but logistics tends to focus more on specific tasks within a particular program health system” [19]. An LMIS then, supports planning and execution of flows and storage of commodities, primarily within the individual national health systems, i.e. all that is required to meet patient demand [13]. However, it is still broad in that it includes functions like procurement, finances, transportation and fleet management. A more narrow understanding is provided by the World Bank, who defines LMIS by emphasizing information on stock status and day-to-day management of commodities and forecasting [23]. In the latter, LMIS is seen as a more restricted system. Stock-out data and forecasts, outputs of the LMIS, are seen as informing procurement which will take place through other mechanisms and systems.

The different definitions open up for seeing the supply chain as being supported by a diverse set of information systems, of which the LMIS is only one. One distinction can be made between the LMIS and Warehouse Management Systems (WMS). A WMS is used to manage the flow of materials into, through, and out of storage facilities by processing the transactions associated with each movement, from receiving and put-away to picking, packing, and shipping [14]. Yet another, newer, USAID document engage in breaking up the domain further, where the supply chain is supported by warehouse systems and billing and accounting systems, in addition to the LMIS [20].

Based on our empirical work and these definitions, we argue for the following clarifications of the LMIS concept. First, we suggest defining LMIS as a system of records and reports on routine administration, dispensing, consumption, and loss and adjustments data, to support forecasting and distribution of health commodities from central national storage to point of health service delivery. Second, we argue for understanding LMIS as one of several information systems that supports the supply chain at large, where the different systems provide specialized functionality yet are linked together by sharing key data related to the overall supply chain. The second point is thus related directly to our research question. Given that LMIS potentially interacts with a range of other supply chain information systems, what is its functional role in relation to them? We now turn to relevant literature on health information systems architectures.

We define information systems architectures as the roles of system components and the relationships between them. Our focus is not on the individual software applications’ inner workings, but how different constellations of information systems offer different functionality and interact with each other. Related to health supply chains, the architecture is composed of multiple information systems, such as LMIS, WMS, billing and accounting systems, etc.

Based on an understanding of information systems as open-ended and shared among a multitude of different actors, as articulated by research on information infrastructures [5], it follows that information system architectures are not centrally designed and controlled. Instead they tend to evolve, blurring the justification of how certain architecture emerged [3]. This evolutionary view downplays the role any actor has to impose architectural principles like service-orientation and modularity [4] that aim to add coherence throughout all parts of the information systems. As a result, national health information systems in developing countries seldom experience high degrees of reusability and interoperability [8].

Nielsen and Sæbø [11] examine architectures from a functional perspective, and note that in situations where functional needs are unmet, it is not uncommon for existing software to expand to meet these needs. In more limited markets, such as developing countries’ public sector, the different components of the overall architecture can thus cover more ground than if there were many alternatives to choose from. Touching specifically on LMIS, they show how related health information systems expand to cover some aspects of the LMIS when there is no other viable solution in place.

3 Methods

The data presented in this paper is based on an interpretive case study [22] of the health sector supply chain information systems in Uganda and Tanzania. The primary data collection was conducted during a joint visit to both countries over the period of a month in January 2016. Secondary data collection was based on discussions with other participants in a larger research project on LMIS, as well as a document review of relevant international organizations who support developing countries with health system strengthening. An initial document search was carried out to identify those who either define or discuss logistics management information systems (LMIS) or supply chain information systems. We looked at documents from large international agencies such as World Health Organization (WHO) and UNICEF, relevant international projects they are part of, and technical partners of said organizations.

This fieldwork consisted of visits by the authors to different levels of the medical supply chain in the two countries. Data was collected through interviews and observations, with the aim of understanding the flow of information and commodities, and supporting technologies and information systems, summarized in Table 1.

Table 1. Data collection
Full size table

Data analysis was carried out jointly by the authors. For Uganda and Tanzania, the focus was on identifying software or paper systems used in the supply chain, what functionality the software had, how it was used, and what data the different systems contained. This was done by drawing illustrations, or “maps” of the health sector, where the scope and scale of the systems were outlined, as well as their integration or not. The document analysis focused on identifying definitions of LMIS, and secondary on related concepts such as supply chain, supply chain information system, warehouse information system, etc. These definitions were then compared, and similarities and differences outlined. Lastly, these definitions were compared with the functional “maps” from Tanzania and Uganda.

4 Cases - Tanzania and Uganda

In Tanzania, most health facilities report on consumption and order new commodities through paper forms (Report and Requisition, R&R), brought to district offices where this information is entered in an online system, eLMIS. In the capital some health facilities can enter their R&R reports directly into eLMIS, due to the more widespread availability of computers and Internet connection. The system handles the flow of this information between districts, regional and national warehouses. At the warehouses, a proprietary Electronic Resource Planning (ERP) system, Epicor9, is supporting their needs of warehouse management, distribution planning, and finances. There was at the time of research a partial integration between eLMIS and Epicor9, where eLMIS send data to Epicor9, but not the other way around.

eLMIS is used by the district pharmacist, who enters orders from the paper forms into eLMIS. This R&R contains each commodity’s starting balance, commodities received, loss/adjustments and a closing balance, as well as orders for replenishment of stocks. The district pharmacist can call the reporting facility to confirm the data, and can make adjustments in cases where errors are detected. The district pharmacist also adjusts orders based on the facilities budget. The costs of the commodities appear in eLMIS, but the facility budget does not. The district pharmacist therefore receives the budgets for each facility, printed from Epicor9, from the higher levels. When an adjustment is made, the facilities are not notified.

There are in addition a multitude of other systems at the lower levels which also engage with logistics data. One such system is the ILS Gateway, a mobile reporting system used to report stock on hand and adjustments by facilities on a limited set of tracer commodities. It also sends SMS reminders to the facilities to submit reports and notifies them of upcoming supervision visits. The data collected via the ILS Gateway can be accessed in a website by the district pharmacist. Some reporting is done by sending SMS with mobile phones. Other logistics data is generated by electronic patient systems, which is then printed out and entered into eLMIS manually. An example is the CTC2, a patient record system used for HIV/AIDS patients used at large facilities, which keeps track of the patients’ adherence to antiretroviral therapy (ART). A patient’s current and previous ART regimens are registered in the system, and the system also tracks the stock balance of the ART medicines. When orders are to be placed, the order forms are printed and manually entered into eLMIS. Lastly, some data on commodities is entered into the national health management information system (HMIS), which runs on the DHIS2 software. This data is entered into DHIS2 by HMIS workers at district level, and the data is used by health managers. The primary use of logistics data for general management is to analyze stock-out data with service delivery data, and the HMIS is not used for ordering purposes. Interoperability between DHIS2 and eLMIS or ILS Gateway is not established and there is some duplication of data among the systems. A project to send statistics from eLMIS to DHIS2 in order to utilize the analysis tool in the latter was ongoing at the time of writing [21].

In addition to the official system, facility staff also uses other means to replenish their stocks. For example, we found that facility staff had WhatsApp groups where facilities helped each other out when they were low on stocks. They would then redistribute among themselves, and report these transactions in the R&R forms.

The situation in Tanzania is illustrated below, where at the national level there exists one ERP as WMS. At the district and national level there exist two LMIS systems, where only one is actually used as the system handling orders. At the facility and district level an LMIS system exists that is only used for reporting. While at the facility level there are smaller systems used for patient records and inventory management. Most information subsystems at lower level are completely paper-based due to lack of reliable electricity and internet support (Fig. 1).

Fig. 1.
figure 1

Different systems used in the Tanzanian LMIS

Full size image

The situation in Uganda is quite similar to that in Tanzania, with proprietary ERPs used at the national and regional warehouses. Two different systems are in fact used, SageLine 500 and the MACS Warehouse Management System. SageLine 500 is used for finances, account supervision, as well as a general ledger. The MACS WMS is used for order processing, facility budgets, picking and packing, and journey planning. In addition, public health facilities get some commodities from a large private supplier, The Joint Medical Stores (JMS), which also use an ERP (IFS) for their national and regional warehouses.

Most reporting and ordering in Uganda is done through paper forms from facilities to the warehouses. Of the computer-supported systems identified, they either had limited scope, such as related to one health program only, or used in only hospitals and not smaller facilities. A stand-alone system, Rx Solution, is used for inventory management at most hospitals, but reporting and ordering is done through reports printed from this system, which can also be sent as an email attachment. Other specific logistics streams, like that for ART, are supported by different software. Where such software exists, data is often stored on paper in addition. The DHIS2 software (which is also used for the national HMIS) is used for ordering ART commodities, where the paper orders are entered manually at the facility or the district office. Before an order is shipped, the facility is contacted in order to confirm the order. The order data is entered manually into MACS, as there is no integration between DHIS2 and MACS (Fig. 2).

Fig. 2.
figure 2

Different systems used in Ugandan LMIS

Full size image

In both Uganda and Tanzania there is a gap between the public and the private health sector and additional streams of information and commodities related to international agencies. Where electronic systems exist, they are not interoperable and unable to share data with the public health sector.

A pattern of how the field of LMIS is organized can be seen across the two cases. Large, complex proprietary ERP packages are used to support the national warehouses, with modules for inventory, finances, procurement and the like. The flow of commodities from the warehouses out to districts and health facilities is supported by smaller, less complex systems which focus on ordering and reporting. At the facilities, there is a group of specialized software, typically originating from needs around patient management, that also have small modules for local inventory and order management. Taken together, the field of logistics management is supported by a patchwork of systems, varying greatly in their complexity, origin, cost, and reach.

5 Discussion

The cases from Tanzania and Uganda show architectures consisting of fragmented and heterogeneous systems. While there are certainly systems that are used for supporting logistics, such as eLMIS in Tanzania and DHIS2 for ART medicines in Uganda, there are also other systems that contain data on health commodities.

Given our definition of LMIS, understood as a system of records and reports on routine administration, dispensing, consumption, and loss and adjustments data, to support forecasting and distribution of health commodities from central national storage to point of health service delivery, one finding is that there are several information systems which may qualify as playing the role of an LMIS. In both countries, LMIS functionality is spread out among different paper-based and electronic information systems. While in both countries there are systems that deal with both reporting and ordering between facilities and national warehouses, there are also several systems that focus on more local logistics, such as patient management systems or local inventory systems. In addition there are systems which contain some of the same data, but not for ordering purposes but rather as one of many data sources for general health management.

Looking at the different levels of the health system, there are strong similarities between Uganda and Tanzania. In general there are differences in infrastructure as well as the understanding of logistics at the different levels [15]. At the national level there is a logical, rational and mathematical approach to logistics. Their focus is getting commodities to the clinics and their area of operation is the broadest. Here both countries have large, proprietary ERP solutions that handle both warehouse management and finances and other related functional areas. At the facility level there is more of a pragmatic approach to logistics. The main facility level focus is on delivering health services to those who need it. They still have information systems that cover some logistics support, such as systems primarily for patient management (CTC2 in Tanzania), local facility inventory systems (Rx Solution in Uganda), and “shadow IT” that go beyond the official systems (use of WhatsApp for inter-facility redistribution in Tanzania). National and facility levels have very different infrastructure, needs and scope of operation which is reflected in the systems they use.

The district level resembles characteristics from both levels, where the management of health services is a primary focus. Technologically they are more advanced than the facility level, yet their needs differ from the national level as they are more of a middle-man between the facility and national level, adjusting the facility orders, and to a limited degree, partaking in the distribution of commodities.

The difference in technology used on the different levels is not only connected to the primary goals, but also its infrastructure and maturity. On a general level the district and national level has a more robust infrastructure than the facility level. This doesn’t just concern Internet connectivity and electricity, but also the ability for on-site support. Together these factors results in the fragmentation of information systems, which both cases show. It is important to point out that even if different, the information systems in place are suited to their local needs.

When the need for a system has emerged in both Tanzania and Uganda, it has been developed and implemented in isolation, with little regard to other systems. This is at least partially due to different actors developing the systems, but more importantly a lack of an architectural vision from the national level guiding how systems should be developed and implemented. This has created systems working independently of each other, sometimes within the same functional area. The functional overlap is quite as expected given the tight integration of the various aspects of health service provision. For example, the CTC2 system in Tanzania is a patient-management system that also contains relevant data on health commodities, in this case on ART medicines for HIV patients. When treating HIV patients, a large part of that is to administer medicines and make sure you have enough of those medicines and forecast what you will need over the next few months. Developing a system to support patient management, it is thus natural to extend the functionality to also cover inventory management in the absence of any unified LMIS and inventory system that you can connect to. The same logic is behind the inclusion of stock-out data in the national HMIS.

Both countries show the same architecture of systems existing as separate entities in the supply chain, even though some of them share the same data. One way to interpret this is that this works and is suited to the context, but it may need optimization related to functional duplication. Another interpretation is that this doesn’t work and that this patchwork of information systems should be replaced by one big system that can handle everything. However, such a strategy would easily face challenges related to the very different needs at the different levels. The third way could be to argue that this doesn’t work as effectively as it could, but there is no need to start again from scratch. Integrating existing systems is a more feasible solution to the fragmented information systems. Integration will help circumvent some of the issues persisting today in the LMIS. The question then becomes, where do we integrate? There aren’t necessarily any correct answers to this question. It depends on the systems already in place, the availability of supported, appropriate, technology, and the priorities of the health system as a whole. Integration should also be driven by informational needs. Today such integration is already working, though in a manual way. The important thing when opting for integration is having a full architectural vision [8]. This architectural vision should be based on the principles of service orientation [4].

Approaching the LMIS architecture with basic software design principles such as encapsulation, loose coupling, composability and normalization in mind will help make the LMIS more flexible. Encapsulation will ensure that the existing LMIS systems can be utilized when the new architectural vision is implemented. Systems developed under the new vision should emphasize loose coupling where dependency on other services should be minimized. Composability as well as normalization will help ensure less of a functional overlap between the systems in place, such as the case is today. Another important factor is data standards. When the same data exists on paper, as well as in different systems, data standards can help in creating a bridge between the software applications. Examples of challenges when integrating these systems can be found from the experiences when Tanzania wanted to create an integrated HMIS/LMIS dashboard [21]. Issues such as different facility names in the different system, different reporting periods and different naming conventions for drugs created issues that could have partly been solved with a more service oriented approach to the LMIS architecture. It is also important to mention that service oriented architectures empowers reuse which can help in reducing the number of systems in the LMIS, but it also increases the complexity.

In summary, both countries show that the functionality of an LMIS is spread out across many different systems, which may or may not have been developed with the aim of actually being an LMIS. When for instance a health management information system or an patient management system comes to include data and functionality around logistics, it is consistent with a situation where an LMIS has already been established but does not yet cover the needs of general management or patient management, respectively [11]. Given the different information needs and infrastructural situation at the various levels, this “patchwork” of logistics-related systems is not only expected, but also to a certain degree beneficial. Both countries have some systems that support horizontal reporting and ordering, but there are still needs for logistics data beyond these that has come to be supported by other systems. The crucial question then becomes if, and how, and where, they should be integrated.

Some answers to these questions are coming from the countries already. In Tanzania, there is a need for the eLMIS to be integrated with the ERP warehouse system, so that orders can be shared automatically to the higher level system and financial data can be shared down to district pharmacists. Such integration has already been established, but only allowing one-way data sharing. Likewise, there is a need to share financial data downwards, so that district pharmacists or others who enter ordering data can do this within the frame of the facilities’ budgets. Since some logistics data is also relevant for health service management, there is also an initiative to integrate eLMIS and DHIS2. This is certainly an area where we would call for more research, and to document the learnings from the above mentioned initiatives.

6 Conclusion

Our research question in this paper is: What are appropriate information systems architectures for public health supply chain management in developing countries?

Our short answer is that this depends on the existing systems in place, and the needs they cover at the various levels. We caution against thinking that one system may cover all supply chain related needs, given the big differences in scope and technical infrastructure. Though we have only looked at two countries, a pattern emerges where a larger ERP-like system is needed at national warehouses, a “slimmer” transactional system that focus on reporting and ordering connects the warehouses with the facilities, and a range of other systems that primarily support other functions also cover some supply chain data. The transactional system between the levels is what most resembles the definitions of LMIS we have identified among the international organizations who support supply chain systems in developing countries, though there are many other systems who could be said to have limited LMIS functionality also.