John Kieti is a Database Specialist at Kenya’s National AIDS Control Council as well as a technology blogger at www.gmeltdown.com.
Last week, I had this great opportunity to be a participant at the fifth annual OpenMRS implementers meeting in Cape Town. The meeting brought together implementers, developers, and the leadership of OpenMRS. The meeting was of the “unconference” style and being relatively less experienced with OpenMRS, I found myself simply following through the intense sessions, soaking up a lot of knowledge and insights. There were many lessons and great experiences including ideas on how to actualize the dream in my earlier blog post on adopting OpenMRS in Kenya. I shall try and describe three of them in this post – based on my personal synthesis.
Lesson 1: Clinical Systems Not Reporting Systems
During one of the evening discussions with Dr. Alvin Marcelo and a few others round a dinner table, I had this bulb light somewhere in my mind that “Really, medical record systems need not be seen as reporting tools”. In fact, to some health care practitioners, all that should be expected of the medical records system is that it assists in retrieving a patient’s medical history, and perhaps assists in diagnosis. To those who think that way, other information management issues including aggregation of patient and treatment statistics for what we know as monitoring and evaluation (reporting) is almost out of scope for a electronic medical records system (EMR). The idea that an EMR system needs to primarily address the health care givers’ information requirements at their points of care implies that national Monitoring and Evaluation (M&E) and reporting needs become secondary.
These observations got me thinking. Perhaps the efforts to have EMR’s in Kenya will not necessarily yield the desired expectations. Over the last couple of years in Kenya, the National STI and AIDS control program (NASCOP) and the division of Health Information Systems (HIS) in the Ministry of Public Health and Sanitation have been working hard towards having elaborate EMR systems used at the country’s public health facilities. With the country’s drive for implementation of these systems being “national reporting”, it appears NASCOP and the division of HIS might be better off concentrating efforts on district health information systems such as DHIS2. It should be possible to allow for diverse EMR systems that support the SDMX-HD protocol for data exchange with the DHIS system to facilitate upward aggregation of data – hence national reporting. (Of course, this is not to disregard the need to foster data use and M&E at the administrative level of health facilities.)
Lesson 2: Symbiotic Relationships Paramount
It is fairly easy for health experts to say that the field of health information systems (e.g., medical record systems) is their exclusive domain. Such a perspective can be legitimized by many valid arguments to the extent that the relevance of input from other professions can be seriously downplayed. Conversely, from a different perspective, information systems experts can easily justify why health information systems is their domain. When these perspectives are not adequately reconciled, there is a high probability that in an health information systems implementation, either health aspects or technology aspects will not be optimized. During the meeting, several participants emphasized that the development and implementation of successful medical records system calls for a symbiotic relationship between health care professionals and IT professionals. Moreover, health information systems implementation require meaningful engagement of all would-be beneficiaries. This was well summarized in by the observation of Chris Bailey from WHO: “If you want the truth about an EHR system implementation, talk to the nurse.”
Lesson 3: Who and What really is OpenMRS?
I am sure this is a lingering question in some readers’ minds. To me the question was answered better during the meeting. A plenary session with Dr. Paul Biondich helped me to understand the idea that OpenMRS is both a global community and a software platform. It is a non-profit, multi-institution collaborative. Its mission is to improve health care delivery in resource-constrained environments by coordinating a global community that creates a robust, scalable, user driven, open source medical records system platform. From a technology perspective, OpenMRS is also a software platform and a reference application which enables design of a customized medical records system. One more related learning point was that there is an on-going work to incorporate a non-profit organization that would facilitate a more proactive pursuit of the community’s mission.
In general, there was a sense that for a health information systems initiative like OpenMRS, maintaining a balance between meeting health care delivery and software evolution objectives is paramount.
Some nice photos of the 2010 OpenMRS Implementers Meeting are available courtesy of John Wesonga.
Read part two of John Kieti’s thoughts on the meeting at his blog.
7 thoughts on “Insights From 5th Annual OpenMRS Meeting”
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
i am eager to be your Member if it is possible.please you may include me as one of your member.
thanks,God bless you.
Hi Abdisa. There are many ways you can get involved and join the OpenMRS community. Check out our Get Involved page for some ideas. Thanks for your interest!
My interests were fully satisfied from attending the meeting. Knowledge spread through discussions on the OCC and other form development issues quickly broadened my thoughts with regards to our current implementation at AMPATH. I would like to thank Dr. Paul Biondich and the team for giving me this splendid opportunity to attend the meeting and share ideas and learn new things which already provides a broader scope in managing concepts within AMPATH.
@Boniface It was great to meet more implementers in Kenya like you. I liked the thought that AMPATH nolonger has an excuse for sticking to Microsoft Windows Client machines related the use of Infopath. The the lock-in situation of using Microsoft Office might nolonger be the case if Xforms/HTMLforms are adopted instead
Thanks for that it is a worth info
Must have been interesting,if only i were there!
Kieti —
I just ran across these comments in Greg McCallum’s blog. I wanted to address your point on clinical systems not reporting systems. But first, let me identify myself. I’m a member of the HIS Team at CDC HQ, I’ve been part of the OpenMRS community for 4 years, participated in a small way in the SDMX-HD design process, and am working with Ghana to implement DHIS2. You can reach me via the OpenMRS dev or implementers list.
I think you are right to distinguish between clinical (patient medical record) systems and indicator (aggregate data) systems. However, I think you are wrong to oppose them them to each other. Most indicators should be measures of patient care which are derivable from patient data and should be produced as outputs from a clinical system that are then imported into the aggregate data system. Other clinic-based non-patient systems (such as human resources, supplies, lab and pharmacy) can also contribute data to the aggregate data system. The aggregate data system is good for carrying information other than indicators, such as surveillance data, budget and planning data, etc. Then there is clinic-level data, such as water source, means of incineration, presence of internet which is useful only as aggregates. It is also a good platform for visualization of data.
The preceding paragraph discussed a theoretical clinic which has a full range of clinical systems, but we all know that this is not common in Africa. What we typically find is a number of paper-based patient registers which are tallied by hand onto reporting forms and forwarded to the next higher level for further accumulation. The data on the reporting forms is that which is entered into the aggregate system at some level of the hierarchy. If there is automation, it is only for a few of the services, typically those that are funded by outside donors.
The data in the registers is individually identified data, so needs to be handled in a manner that protects privacy. The data in the aggregate system is clinic-level data, so it need not be handled so securely. This is an important distinction.
It is useful to enter the individual level data from the registers into a system, because it prevents errors at the tallying step. This system should also have the capability of reporting because only if data is used and useful to the clinic staff will data quality be maintained. This system can be implemented in OpenMRS or a less complex system. The thing is, the information in the register is insufficient for the physician to manage the patient’s care, it is mainly useful for counting the number of instances a service is rendered. But if we take the columns from a patient register and put them on an encounter form, and add fields appropriate to the type of service being rendered, we now have the basis for an EMR. If we move incrementally in this fashion, we can avoid the huge change management issues of implementing an “elaborate EMR system.”
So the idea is to have a good aggregate system for the transmission, storage and sharing of indicators and other management data; to enter detail data into some system and let the system tally and export to the aggregate system; and to grow the registers into full-scale patient records which become part of an EMR system. Note that this is not an ordered list, there can be a mix of paper systems and EMRs in the same health system, clinics can only advance at a rate determined by their staff, capabilities and conditions. But in this day and age, the aggregate system and simple register data entry and tallying programs should extend quite far down the hierarchy, while EMRs should be taken up by the larger clinics and hospitals.
I’d love to hear your comments on these ideas.