Part 2 of Insights from the 5th Annual OpenMRS Meeting

A couple of days back I wrote my first article on the  the fifth annual OpenMRS implementers meeting. Immediately after posting the article I checked my meeting notes and thought I would need to write on a few more insights that appeared equally profound. Consider this a continuation of the lessons I described in the earlier post.

Lesson 4. Open source is great; best with a global community
One of the big debates in many developing countries is whether to adopt an Open Source policy for their e-government initiatives. It appears key decision makers have began to appreciate the benefits of such a policy. However there needs to be further understanding that a mere application of open source technologies for development of government software systems is not enough. There is need to embrace the concept of open source from a global community perspective.  A software expert or two can sit with an health care expert and develop an awesome, robust, feature-rich EMR or Pharmacy system using open source technologies. The system can easily go ahead and be deployed successfully in a health facility or two. The challenge with such an awesome system would revolve around the nature and size of its community of implementers and developers. Such challenges would begin to show when it begins to expand its scope, both in terms of number of installations and scalability of functionality.

During the meeting I confirmed the unparalleled size and diversity of  the OpenMRS community - for an EMR sytem. However, the bigger learning point for me was that indeed a large and diverse community enhances chances of software supporting global best practices.  I may not be placed best to comment on this a the medical or health care point of view. However description of the whole idea of OpenMRS concept collaborative (OCC) and meta-data sharing had strong indications of how powerfully the open source, multi-institution approach can influence harmonization of terminology and adoption of best practices in the health care domain. Dr. Andy Kanter’s presentation did very well to highlight the possibilities and potential around concept sharing.

From the information systems point of view, global best practices on software design and development were an underlying feature of the technical discussions - as a necessity. In this era of globalisation, I was particularly impressed by the approaches to providing services in resource-constrained environments. These I thought in due course can be perfected by developing countries and competitively propagated to developed country settings on relatively  less resource-rich but essential devices like mobile phones.

In general my lesson here was that an open source system built and maintained by a small or closed community can be as inflexible and as expensive as a proprietary system. Any open source software initiative with a national or global ambition should strive to build a large community enough to sustain its growth objectives.

Lesson 5: Enterprise Architecture optimizes on resource use and unifies efforts
During one of those parallel tracks at the meeting there was this intense debate about Enterprise Architecture (EA) and OpenMRS. On my part I had long held this belief that EA was too abstract a concept to be directly relevant to a national health information systems arena. More so for a low-resource, developing country setting, the concept had unfortunately appeared to be ‘too high up there’. The turning point for me was when a participant dared the rest of us to think that “Perhaps EA is NOT too esoteric to be talking about in a low resource setting”. Of course I had to first struggle through the definition of the enterprise itself - noting that the enterprise could be ‘Myself’, a clinic, a Ministry of Health Division, A country’s health sector, or even a countrywide ‘all sectors’ as an entity.

Incidentally I got convinced during this session that a country having EA is one of the biggest success factors for achieving an effective implementation of a nationwide eHealth systems. The simplest benefit of an EA seemed to be its ability to harmonise terminology across the eHealth landscape. For instance it would reduce misunderstandings arising from the lack of a distinction between roles of constituent components such as the EMR, the HMIS system, the Supply chain management system, the Communuty Health Worker system and so on. Where there are many stakeholders, EAs assists every contributor to the national enterprise architecture to focus efforts on the functional and interoperability profiles of envisaged components. Such critical understanding has immense potential to reduce duplication of efforts and wastage of expensive donor money in the developing world.

Furthermore, with EA’s ability to unify national stakeholders around technically sound functional and interoperability profiles, it was regarded in the discussions as an important cushion if not a weapon against the ever looming adverse political changes in our health ministries.

There were endless lessons and insights in the meeting and you might guess I still have a couple of more thoughts worth writing about. I shall leave that for yet another blog post.