Last June, we arrived in Tanzania with laptops, business plans, and sales presentations in hand – ready to observe, adapt, and pitch our way to serving hospital needs and establishing a sustainable customer base. Our mission: to improve healthcare by alleviating medical equipment breakdowns with software that better manages hospital equipment inventory.
Over the course of 8 weeks, MED International visited more than 40 hospitals across Tanzania and Ghana to work towards that mission. We toured hospitals and encountered both modern operating theaters and medical equipment graveyards (rooms full of broken medical equipment), often in the same facility. We met with hospital executives, biomedical equipment technicians, and IT managers who verified that their hospitals had poor or absent systems for tracking important (and expensive) pieces of medical equipment. We presented our inventory management software – named “Zanhealth” for MED’s 2012 start in Zanzibar – to hospital staff and leaders, nearly all of whom were impressed by and excited to use our product.
We learned valuable lessons about what did and didn’t belong in a hospital’s inventory management system and applied those lessons to construct a robust software solution in Zanhealth.
Now, 7 months later, we are making Zanhealth open-source to share our work and accelerate its progress. Between then and now, we encountered our fair share of obstacles. We’d like to share the lessons we learned with you and encourage those interested in our mission to continue the work.
So what did we learn?
1. Product development must happen closer to the ground
We built Zanhealth after an initial successful 5-month pilot in Zanzibar, but the bulk of development took place within the confines of Brown University. This meant that several key product features were not in sync with the daily reality of the Tanzanian and Ghanaian hospitals that we eventually targeted. Though we spent two summers training technicians in Zanzibar’s hospitals, mainland Tanzania and Ghana, where we arrived this summer, had unique challenges for running and maintaining software.
The slew of challenges included: unreliable internet infrastructure, low software utilization and overstretched hospital budgets. Zanhealth, as it was then designed, was a web application for hospital staff to monitor equipment statuses, report breakdowns, and perform repairs more efficiently. The web-based model had initially made sense to us. We envisioned it being valuable in the long run, with a Software-as-a-Service (SaaS) subscription model enabling easier updates, greater integration with international partners and the opportunity to create a global data set of equipment use. However, without reliable internet, Zanhealth was not a reliable management system for life-saving medical equipment; without extensive experience using the software, users had trouble updating equipment status; and without room in hospital budgets, we could not guarantee long-term user support.
Even with our best efforts at long-distance data-gathering with few accessible hospital resources, we realized there was no substitute for being on the ground and iterating our product first-hand. We couldn’t build a successful product without continuous hospital input and a leaner production model.
2. Local connections and end-user engagement are necessities throughout the process
Our biggest challenge lay in correctly identifying the greatest pain points of hospital staff. Not that doing so would have been an easy task; dozens of emails and international phone calls to Tanzania and Ghana elicited responses that were hard to accurately discern. Our months in Zanzibar’s public hospitals where we piloted also turned out to be very different from the facilities we approached in Ghana, and on the Tanzanian mainland. Without rich participation from our new constituents, we had only limited data and our own ideas of what could and couldn’t work.
Once in Ghana, we encountered a handful of successful software developers who built loyal customer bases for their hospital software packages. While they were mostly on-premise solutions that did not operate at scale, they worked with hospital executives and staff from the beginning of their projects to study user behavior and design appropriate solutions. While limited in scope, they targeted low hanging fruit that brought quick value for the user at a price point we were unable to match.
Being able to collaborate with local hospitals to learn about their infrastructural challenges, software adoption, and financial conditions would have helped us design a more appropriate solution much earlier. However, after observing maintenance and repair workflows, we gained a more sophisticated understanding of how hospitals respond to medical equipment breakdown, how their processes may be improved, and what solutions can help. In the big picture of improving health systems, the perspectives and experiences of individual technicians and staff members are invaluable.
3. Structural issues are challenging but not insurmountable.
The obstacles we faced in Tanzania and Ghana could easily be deemed structural barriers that social enterprises have no business overcoming. Social entrepreneurs will never create a silver bullet for structural issues like poverty, corruption or poor technology infrastructure, but we can still innovate to improve existing systems step by step.
Software utilization and computer literacy is still low in many developing nations. The culture of automation and computerization that has taken hold in developed states has yet to achieve critical mass in places like Tanzania and Ghana. Yet, we identified many hospital executives and staff actively seeking to innovate and improve hospital efficiency through technology. More developing country hospitals are looking to software to increase efficiency, reduce costs, and deliver better health care.
A key utilization barrier Zanhealth encountered was hospitals’ perception of its high cost. We offered trial versions to demonstrate cost savings with 3 hospitals (including one of Ghana’s largest) signing on. However, they weren’t able to continue using Zanhealth because of the internet requirement, another barrier that could be overcome. We tinkered with mobile platform integration, but could not get quite the right balance between functionality, platform integration and usability.
Internet access remains unreliable in many developing countries. Most hospitals rely on local area networks (LAN) to run locally-hosted software without the need for an internet connection. Hospitals were much more likely to purchase and use Zanhealth on a LAN – without an Internet requirement. Internet infrastructure, while important, is not necessary for hospitals to use Zanhealth software and reduce medical equipment breakdown.
Now, what can you do?
We’ve done the legwork to compile market research and build the bulk of a software to improve medical equipment management in developing country hospitals. Our learnings from Tanzania and Ghana are included in the latest version of Zanhealth, now optimally suited for hospital staff to integrate into their workflow.
After 4 years working from abroad to effect hospital systems change in developing countries, MED International recognizes that we are not in the best position to take on this challenge. We believe the best team suited for the deployment is one based on the ground, working in local settings, and with direct access to hospital users.
For these reasons, we are making Zanhealth open-source software to accelerate innovation and support these developers in solving a pressing social problem. Our source code is now freely and publicly available for you to modify and to hospitals to use.
We are providing a platform for social entrepreneurs and programmers to build off MED International’s work and see hospitals use Zanhealth to operate more efficiently and deliver better patient care. If using technical expertise to build on Zanhealth and generate social impact interests you, we encourage you to get in touch.