Brainstorming OpenLMIS in disaster/crisis/conflict contexts?

Recently I stumbled upon an ICTWorks article on a Humanitarian Grand Challenge which included an excellent Analysis of Barriers Affecting Innovations in Humanitarian Contexts (PDF), and it reminded me of a concept that has surfaced from time-to-time in OpenLMIS that goes something like this:

OpenLMIS is hard to configure (because routine supply chains are complex), however when disaster strikes the value of an integrated health supply chain stays the same, if not increases; so if we could just make it easier/faster/painless to deploy OpenLMIS then we could help supply meet demand and lessen the impact of that crisis.

I think we’ve all heard of or seen some response to a humanitarian crisis that attempts to use ad-hoc communication or data collection tools (e.g. SMS, WhatsApp, ODK, google forms, CommCare, etc) instead of a supply chain tool, and if you’re like me you groan a little inside. On the other hand supply chain tools tend to be medium to heavy-weight, OpenLMIS certainly qualifying, and in a crisis we’ve all heard how all the normal infrastructure fails and responders have to use the tools at hand.

What I’d love to do is brainstorm on two topics:

  1. Would OpenLMIS really help in a crisis, and if so what does that crisis look like? or NOT look like?
  2. If we thought of an OpenLMIS “crisis mode” for #1, what would those features look like?

I’ll start to get the ball rolling,

  1. The crisis needs to not be very temporary. Nor is it narrow in geographical scope. It likely effects many for a period of months, or longer, over a wide-area. Disease outbreaks, aftermath of a natural disaster that destroys public health infrastructure, conflict that displaces populations and services are examples. Enough time needs to pass that adequate resupply will be a factor. Enough of an area needs to be effected that multiple competing needs have to be balanced. In this regard OpenLMIS as a supply chain tool that understands health products, which has multiple resupply workflows to fit different needs, and which is engineered to work in low-resource environments is well suited (with improvements) to bringing better supply chain practices to crisis contexts, and those practices will help supply better meet demand.
  2. We’d loosen rules and up-front configuration and instead rely on ad-hoc data entry and conventions: Facilities, equipment and products could be added ad-hoc, supply chain hierarchies would be flattened, approvals for resupply requests would be very short or squashed. Strict rules would be turned off and instead simple recommender systems would be built: if you do this your stock technically will be negative, if you add that facility there is actually one already added with a similar name, etc. These “crisis mode” features could be selectively turned off by some vertical (program, location, product) over time, allowing the implementation to grow into a more routine one with many data quality checks, rules and approvals - what OpenLMIS currently does well today.

These are just some of my thoughts though, what do you think?

Some more (possibly) relevant material:

1 Like

Feedback from the Product Committee Implementers meeting on August 13:

  • Context: OpenLMIS could be well-suited for emergency situations - would need to work on making it easier to configure (a few days max, rather than several weeks)
  • @Matthew_Kumbuyo : some organizations are interested in tools for such contexts
  • @Gaurav_Bhattacharya : Reach out to MSF, Save the Children, UNHCR
  • @Dercio_Duvane : in Moz this was needed to track stock levels at facilities and to track expiration dates, especially with a lot of foreign aid coming to the country; must be easy to deploy