It’s week 4 of our HI 201 class. Time has been flying! Or maybe it’s the opposite. It feels like it’s been over a month since I wrote a blog, when in fact that was just last week.
Anyway, for this week we were tasked to answer the question…
How can health information systems be sustainable in developing countries?
We were likewise asked to present a mind map, and below is what I came up with:
Before I answer the question and discuss my mind map, let me first define the following – health information systems and sustainability.
Health information systems, according to Pacific Health Information Network, refer to “any system that captures, stores, manages or transmits information related to the health of individuals or the activities of organizations that work within the health sector.” Meanwhile, sustainability has several definitions, depending on context. Reynolds and Stinson said that the term implies maintaining something that already exists over time. In IT in particular, it implies the ability to identify and manage risks threatening the long-term viability of IT (Korpela, et. al, 1993). But for our purpose, the most fitting definition is the one presented by the Australian Agency for International Development. They defined sustainability as “the continuation of benefits after major assistance from a donor has been completed.” Notice that the emphasis was on the term benefits and it did not specify that the project or program per se should be sustainable. They argued that sustainability should be an ongoing process, and that it needs review and revision as the circumstances change and lessons are learned from experiences.
So why do HIS fail in the first place? A model that could best answer this is the ITPOSMO dimensions of health information system design-reality gap. The acronym refers to information, technology, process, objectives and values, staffing and skills, management systems and structures, and other resources. This model presents the seven dimensions between design and reality, and the basic premise is that the bigger the gap, the more likely it is for a HIS to fail. This model is applicable to HIS in all countries.
However, things are more complex in developing countries. In terms of stakeholders (see orange boxes above), usually two out of the three are international players. The donors who provide funding are commonly international organizations, such as the World Health Organization, or are first-world countries. Developers of the HI system may be brought in as well from other countries. Because of this, they are likely not familiar with the many aspects of the developing country (referred to as user organization; may refer to either private or public organizations, whether at the local or national level) they are trying to help.
Kimaro and Nhampossa (2007), in their paper The Challenges of Health Sustainability of Health Information Systems in Developing Countries: Comparative Studies of Mozambique and Tanzania, mentioned several examples of why HIS failed (refer to green items in mind map above). The use of top-down development approach is one, whereby ownership and control of the project rest on the donors and top-level managers. This excludes the end-users who are ultimately going to regularly use the planned project/proposed system. Another is the lack of ownership and responsibility of the user organization, which may happen when the donor prioritizes the needs and requirements of the donor rather than the user organization. Third is the absence of an explicit sustainable strategy. Since donor funding is usually short-term, not having an explicit sustainable strategy can lead to early failure of the HIS when user organizations are unable to continuously fund the project. In relation to this, lack of training for and long-term support for users who are expected to utilize the system can also lead to failure.
In contrast, examples of factors that can lead to success of a HIS are mainly through addressing the gaps between design and reality. For example, the use of iterative approach in the implementation of the system, either through modules or increments, or even though pilot-and-scale-up, help reduce the amount of change that the users must endure at any one time. This is better combined with effective two-way communication among the key actors/stakeholders, in particular the developers and end-users. It can be a learning process whereby the current design and reality are examined and emergent gaps are readily addressed. It can also help the users better understand the design, and the designers to better understand the reality. Prototyping can also lead to HIS success because it allows for all stakeholders to get an overall sense of the design-reality gap. A final example is having the right people, with a special mention on hybrids. The hybrids are also referred to as bridgers or spanners, and are of central importance because they understand both the world of the developer and the world of the user.
I especially mentioned the hybrids because that, in particular, is what I am hope to be once I have completed my masters in health informatics. I want to be the bridge between the developers and the users, and hopefully positively impact the field of health informatics in the Philippines, particularly in the development of health information systems.
Anyway, so to answer this week’s question, let me briefly run through what I have put in the mind map. I want to focus on the lower half depicting the process which I think is essential to developing a successful HIS.
The first step is initiation. It is at this time that stakeholders are identified. Aside from donors, user organizations and developers, they can also refer to politicians or law-makers, or any key player that could significantly influence the new project or program. The main problem must be identified and afterwards alignment of resources, interest and responsibilities should be aligned. It is important to do this at the onset because conflicting interests will ultimately lead to failure of the HIS.
In the planning phase, I separated bottom-up approach to put more emphasis on it. This is in contrast to the top-down approach that I mentioned earlier, which usually only involved top-level managers. With this bottom-up approach, end-users are involved. I strongly feel that they should be part of the process even in the planning because their current reality and experiences will affect how they understand, accept, and integrate the project. They are key to sustainability long after the donors and developers are gone, and should therefore be involved at the very latest in the planning phase. As for the second part, I incorporated the project management body of knowledge categories mentioned in Satzinger’s System Analysis and Design. They are: 1. scope (functions to be done by system, what will be done by team); 2. time frame (detailed schedule of tasks); 3. cost (initial expenses, cost/benefit analysis); 4. quality (quality plan and control activities for each phase of the project); 5. human resource (recruiting and hiring of project members); 6. communications (establishing team communications); 7. risk (reviewing risks for failure and developing plan for mitigation); 8. procurement (developing request for proposals, writing contracts); and 9. integration. They hybrids (aka. me in the future) are highlighted under human resource because they will be an important asset in the success of the HIS. I also put the design-reality gap model as a means for assessing the risk and feasibility of the proposed project. Finally, I added planning sustainability analysis and strategy because I have the impression that planning for integration is more focused on how the project will be initially rolled out and not how it will be maintained.
In design and development, several things must be considered. For example, is there a current HIS? What is the current HIS offering? Will the proposed HIS be similar, different, or complementary? What do the top-level managers think of the proposed project? What about the end-users? Are they amenable to it? How important will this system be to the users? Can the users sustain the proposed system once it is turned over to them? As development of health information systems usually require a lot of resources in terms of money, time and manpower, we do not want to create a system that will be inefficient, complicated, or deemed as something that yes, has benefits, but are not worth it.
For the execution and control phase, the system may be better implemented in steps. It can be rolled out in one module at the a time or in increments, or pilot-tested in one department or location and then scaled up. As mentioned earlier, this will decrease the amount of change users have to endure at any one point in time. By implementing it this way, every step of the process can be readily evaluated for gaps and the gaps can be addressed early on. In addition, this will better help with institutionalization, since it will be easier for the system to be absorbed and integrated within organizational structures and routine activities. Moreover, those types of delivery, compared to the “big bang” approach (or implementing it all at once), will also facilitate the better belief in, acceptance of, and understanding of the system for the users. While the project is being executed, building local capacity should be done as well. In preparation for the transition or closing, the people who will ultimately manage and use the system, whether they are managers or end-users or IT staff who will do technical support, should be trained to handle the system once they are on their own.
Finally, the closing is when the program is turned over to the user organization. Typically this is when donor funding ceases and the developers end their contract as well. However, it might be better if some form of technical support will still be provided for the users while they continue to navigate the new system, especially if local capacity building was insufficient.
Personally, I truly believe that involvement of the end-users (or at least a core group of them) is one of the keys to having a successful HIS. That and the continued training and knowledge-sharing will help sustain any HIS. I am currently using an EMR software that was developed way before I entered into the company I am working at. I couldn’t have been part of the planning process, but as an end-user now, I can see the many gaps that need to be addressed. Our system is neither a success nor a failure at this point because it hasn’t been fully rolled out to all the international clinics/offices. But interacting with other end-users like myself, I can see why some of them are disappointed and some of them find it difficult to work with the current system. I feel that even though the medical staff see the value of the system, it is very complicated and not user-friendly. It also does not address some important healthcare needs (like generating reports for government-compliance purposes), so users like myself are burdened with using the program along with continuing the old system (aka. paper charts, manually generated reports). It was actually one of the reasons that sparked my interest in Health Informatics, since I wanted to know what else could be done to improve the system.
That concludes my post for this week! It was a lengthy one (I apologize if I’m too rambly), which will most likely be the way the rest of my succeeding posts will be.
I have no question for this week, but I’d love to hear your thoughts on whatever was written above. Leave a comment down below and let’s discuss and learn together.