Article Text
PDF
Abstract
Background Point-of-care electronic medical records (EMRs) are a key tool to manage chronic illness. Several EMRs have been developed for use in treating HIV and tuberculosis, but their applicability to primary care, technical requirements and clinical functionalities are largely unknown.
Objectives This study aimed to address the needs of clinicians from resource-limited settings without reliable internet access who are considering adopting an open-source EMR.
Study eligibility criteria Open-source point-of-care EMRs suitable for use in areas without reliable internet access.
Study appraisal and synthesis methods The authors conducted a comprehensive search of all open-source EMRs suitable for sites without reliable internet access. The authors surveyed clinician users and technical implementers from a single site and technical developers of each software product. The authors evaluated availability, cost and technical requirements.
Results The hardware and software for all six systems is easily available, but they vary considerably in proprietary components, installation requirements and customisability.
Limitations This study relied solely on self-report from informants who developed and who actively use the included products.
Conclusions and implications of key findings Clinical functionalities vary greatly among the systems, and none of the systems yet meet minimum requirements for effective implementation in a primary care resource-limited setting. The safe prescribing of medications is a particular concern with current tools. The dearth of fully functional EMR systems indicates a need for a greater emphasis by global funding agencies to move beyond disease-specific EMR systems and develop a universal open-source health informatics platform.
This is an open-access article distributed under the terms of the Creative Commons Attribution Non-commercial License, which permits use, distribution, and reproduction in any medium, provided the original work is properly cited, the use is non commercial and is otherwise in compliance with the license. See: http://creativecommons.org/licenses/by-nc/2.0/ and http://creativecommons.org/licenses/by-nc/2.0/legalcode.
Statistics from Altmetric.com
Article summary
Article focus
Evaluation of all open-source point-of-care EMRs for use in resource-limited settings without reliable internet access.
Key messages
We found six open-source EMRs, but none meets the minimum requirements for a fully functioning EMR suitable for use in resource-limited settings.
Safe medication prescribing presents the biggest challenge for the development of an EMR suitable for use in resource-limited settings.
It is imperative that an international body directly test these products to determine their clinical functionalities and limitations.
Strengths and limitations of this study
We identified all open-source EMRs suitable for use in resource-limited settings.
Our study relied on self-report of a survey among developers, technical implementers and clinical implementers.
Introduction
Electronic medical records (EMRs) are important tools for safely managing chronic diseases. They allow clinicians to evaluate and follow-up patients, prescribe medications safely, monitor laboratory and imaging results, allow for programme evaluation and provide ongoing data for quality improvement. The HIV pandemic and increases in multidrug-resistant tuberculosis have provided much of the impetus for funders to support the development of point-of-care EMRs in resource-limited settings. Non-communicable chronic diseases are also major causes of worldwide morbidity and mortality, but they have not received the emphasis afforded HIV/AIDS and TB, either in the Millenium Development Goals1 nor in the development of EMRs for delivering primary care for patients.
Case studies and periodic reviews have provided potential users with information about various EMR implementations in resource-limited settings, but Mitchell's characterisation of the landscape as ‘a descriptive feast but an evaluative famine’ in 2001 continues unchanged.2 Authors of reports concerning individual EMRs often emphasise the strengths and potentialities of the system they have been developing, but fail to delineate actual functionalities and limitations.3–11 Reviews often mention a selection of EMRs under development but have not indicated why they chose to evaluate particular systems and to exclude others.12–14
Potential adopters of a point-of-care EMR have a critical need to know the functionalities and limitations of existing systems in order to evaluate whether or not a given EMR is suitable for their clinical setting. Recently, Kenya published standards and guidelines for EMR systems,15 but it is impossible to determine, based on published reports, which products have the functionalities necessary to provide full clinical care.
The motivation for this study came from the need to equip a new medical school teaching clinic with an EMR, both to improve medical care and to teach medical students about medical informatics. The setting has slow unreliable internet access and inconsistent electrical supply, but computers are widely used in the area and among the medical students. Computers on and off campus are plagued by viruses, which further degrade the performance and reliability of computers based on the Windows operating system.
This study aims to address the needs of clinicians like us from resource-limited settings who are exploring options for adopting an outpatient point-of-care EMR but have unreliable internet access and limited financial and human resources. Our emphasis is on EMR availability, cost, simplicity of installation and maintenance, clinical functionality, and reporting for monitoring and quality improvement. We attempted to take into account clinical setting and patient problems, cost of needed hardware and proprietary software components, technical skill needed for installation and maintenance, scalability, clinical functionalities and ease of reporting. While other reviews have emphasised EMRs in the care of HIV and TB, this review also explores the availability of EMRs to support primary care.
Methods
Data sources
We searched Medline (1995–2010), CINAHL (1995–2010), Google Scholar (1995–2010) using combinations of the following search terms: Medical Records Systems, Computerised OR Electronic Health Records. We conducted searches both with and without the AND Developing Countries MESH heading. We systematically searched the reference lists of articles retrieved, contacted key authors directly, and posted enquiries to the Health IT section of Global Health Delivery Online (http://www.ghdonline.org/) to identify key informants for EMR systems that have not been subject to publications. We screened the identified studies and software products with the objective of finding reports on specific outpatient point-of-care EMRs. We contacted key informants whom we identified through publications (OpenMRS,16 DREAM,11 iSante5), user groups (OSCAR,17 WorldVista18) or personal contact (GHIS). We contacted the key informants about each product via email.
Inclusion criteria
Open source
Recognising that most EMRs use a combination of propriety and non-proprietary components, we aimed to include only products that can credibly be considered open source. Open-source software eliminates licensing and software upgrade costs, and development costs are shared among a community of developers and users and reduces the threat that the disappearance of a proprietary software vendor will jeopardise the product. Lack of ‘vendor lock-in’ allows the customer to use alternatives to support and maintain the EMR application. Finally, the barrier of standards compatibility and system interoperability is lessened by open-source software.19
Outpatient care
Hospitals and outpatient clinics have very different requirements for EMRs. Hospital care emphasises short-term care, point-of-care order entry and laboratory monitoring. Outpatient EMRs emphasise ongoing care, chronic problems, safe prescribing and quality reporting.
Point-of-care data entry
The functionality and decision-support facilitated by an EMR is lost if data are collected on paper and subsequently entered in a database for later analysis. For this reason, we limited our analysis to systems that currently function in the field as point-of-care EMRs.
Non-internet access required systems
Given the unreliability of internet access in resource-limited settings, we limited our study to software applications with a local database and other components which do not require ongoing internet access.
Data collection
We developed three written questionnaires directed to key informants concerning each software product. The first questionnaire was directed to a clinician who implemented the EMR at a specific site and included information that will be of importance to other clinicians who are considering implementing the system. The second questionnaire was directed to an informatics technician at the site where the EMR was implemented. It contained technical information about a single functioning EMR implementation. The third questionnaire was directed to system developers and contained more global technical information important for potential implementers.
Evaluation characteristics
Our research team consisted of two clinicians experienced in EMR systems and a computer scientist. The two clinicians, PSM and CAB, worked together to summarise the clinical functionalities of the products and JB, the computer scientist, evaluated the technical characteristics. PSM had previous limited experience with WorldVista and DREAM software. We evaluated the following aspects of the systems:
Hardware
Availability and special requirements for computer hardware (server capacities, workstations and networking equipment, both back and front ends). Configuration, start-up and maintenance of the hardware.
Operating systems, database systems and middleware
The cost of licenses for proprietary operating systems often increases with the number of users, so an EMR, which can run on an open-source operating system, databases, middleware and an open-source development toolkit, is an important consideration in resource-limited settings.
Development tools
A development toolkit is needed to adapt the original EMR platform to the client's needs.
Community
The development community can be considered the counterpart of a vendor, which maintains the system, fixes bugs and develops new functionalities. A community of users and developers that uses and supports the system is an important consideration.
Clinical functionalities
One of the keys to choosing an EMR system is to assure that basic functionalities meet the demands of the end users. Functionalities which we evaluated include entering patients in the system, retrieving their records when patients return for follow-up, safe medication prescribing (coded drug lists with dosage forms and drug–drug interaction checking), coding of problems using the International Classification of Disease (ICD), recording and updating past medical history and risk factors, and the ability to easily record and retrieve progress notes and medical procedures.
Results
Of the 20 potential EMRs, which we identified, 19 were encountered from published papers and one was encountered via personal contact. The included EMRs are shown in table 1. The excluded products and the reasons for exclusion are shown in table 2.
Included electronic medical records
Excluded products
After contacting key informants for each of the EMRs we identified, we were directed to the person who would be qualified to complete one of the three surveys for that product. Once we contacted the appropriate person, there were no refusals to complete the surveys. There were several instances in which one individual was qualified to complete more than one survey. In the case of OSCAR, the president of the OSCAR Canada User Group helped to develop the software, installed it in his own practice and uses it as a clinician. We therefore judged him appropriate to complete all three surveys.
A concise summary of the clinical functionalities is found in table 3. The full results of the clinician surveys are shown in table 4, the technical implementer surveys in table 5 and the technical developer surveys in table 6.
Concise summary of clinical functionalities
Full clinical implementer responses
Technical implementer responses
Technical developer responses
Characteristics of the systems
OpenMRS
OpenMRS uses web-based architecture but does not require internet access. Hardware requirements are minimal. Software platforms and software tools are all open source, and it has an active support community. OpenMRS is used widely as a database system but is used only in Chile as a point-of-care primary care EMR. It has patient registration and arrival/flow capabilities. It utilises form-based templates but does not permit past medical history, family history or risk factors to be coded as variables. Problems are listed by ICD code in both short and comprehensive pick lists. The implementation in Chile has no prescription, flow sheet or health maintenance reminder functionality, but it does permit both electronic and printed lab requests, printed imaging requests and manual entry of both lab and imaging results. It is capable of creating reports based on patient demographics and ICD codes.
Dream–Sant Egidio
Dream–Sant Egidio (SE) relies on Microsoft Windows, MS SQL Server and MS Access. These are standard products, appropriate for most environments, and staff with basic skills to install them are ubiquitous. They must be carefully protected with updated anti-virus software. These products also have recurring licensing costs. Hardware equipment requirements are minimal. Dream–SE is free software, but the software code is closed, which limits customisability. It is a client–server application, which is not an issue if users are connected through an LAN network to the server but can be problematic for remote users. Dream–SE software is designed for HIV care and is being used in Portuguese, Italian, English and French. It has a comprehensive patient registration and arrival/flow system in place and uses form-based templates. Problem lists are based on a partial list of ICD-10 codes. Prescriptions are linked to on-site pharmacy inventories but do not provide allergy or drug interaction checks. The system provides HIV-related health maintenance remainders. Lab requests can be printed or transmitted electronically. Dream–SE generates reports based on patient demographics, ICD codes and provided prescriptions.
GHIS
GHIS is an open-source client–server application which runs on MS Windows and MS SQL Server. Hardware requirements are minimal. Simplicity of the client–server application and minimum requirements of hardware and networking equipment make this a very fast system, but it is problematic for remote users. As with Dream–SE, the use of proprietary platforms can be a financial handicap as the number of users grows. GHIS is an English language system for both HIV and primary care. It has a comprehensive patient registration, arrival/flow and vitals signs retrieval process. It utilises form-based templates including past medical history and family history as coded variables. Problems are listed by ICD code in both short and comprehensive pick lists. Prescriptions can be printed or transmitted electronically, which permits inventory tracking; neither drug allergy nor interaction checking is supported. The system provides flow sheets, health maintenance remainders and has electronic and printed lab and imaging ordering. GHIS generates reports based on demographics, ICD codes, prescription and quality report cards.
iSante
iSanté uses web-based architecture but does not require internet access. Hardware requirements are minimal. iSante runs on both open-source platforms as Linux–Apache–MySQL and proprietary Microsoft platforms. iSante is free open-source software. iSanté is an HIV care system available in French and English. It has patient registration and arrival/flow capabilities. It uses form-based templates; past medical history and family history can be created during the initial visit but cannot easily be edited. Problems are listed by ICD code in a short pick list only. iSante is designed to function with an on-site pharmacy, but it does not track allergies/interactions or medication inventory. It provides flow sheets, health maintenance remainders and generates reports organised by demographics, ICD code, prescriptions and quality report cards.
WorldVista
WorldVista is an open-source system, able to run on proprietary Intersystem Cache database but also runs on other systems. Worldvista offers both web-based and client/server configuration, so that different configurations can be established depending on the environment. It has a strong community supporting the platform, but the programming code is not easily editable. Worldvista is deployed in the USA, primarily in a hospital environment, but a few practices have adopted it as an outpatient EMR. WorldVista is a primary care system, but templates for specialist care can be created by the end user. It is currently functional in English. Past medical history, family history and risk factors can be entered as coded variables but are not easily editable at follow-up visits. Problems are listed by ICD code in both short and comprehensive lists. WorldVista has an embedded coded (USA) medication list, which allows for drug allergy and interaction checking. It has capabilities to display flow sheets, health maintenance remainders, lab and imaging results, and generates reports of demographics, medications and problems.
OSCAR
OSCAR was developed in Canada for primary care. It requires simple hardware and uses web-based architecture. Software platforms needed to run it and software tools are all open source. OSCAR has an active support community. It has patient registration and arrival/flow capabilities and uses form-based templates. It allows updating of past medical history, family history and risk factors. Problems are listed by ICD code in both short and comprehensive pick lists. It has a coded (Canadian) drug list with interaction and allergy checking, flow sheet and health maintenance reminder functionality. It permits both electronic and printed lab requests, printed imaging requests and manual entry of both lab and imaging results. It is capable of generating reports based on patient demographics and ICD codes.
Discussion
The challenge for clinicians working in resource-limited settings is to find an EMR that will provide basic functionality for primary care practice and provide an interoperable base on which to build for the future.
In contrast to the optimism evident in many published articles, we found only six open-source EMRs suitable for use in resource-limited settings with unreliable internet access. Many of the products highlighted in published articles are not used in outpatient point-of-care settings, others are proprietary and others have ceased development.
The development of open-source EMRs for use in resource-limited settings reflects the long-standing tension in public health between vertical and horizontal programmes.27 Funding agencies have supported the development of open-source EMRs for HIV care, which contain most of the functionalities needed by clinicians to ensure efficient workflow but have not supported systems applicable to primary care. Even in the areas with the highest HIV prevalence, primary care remains the highest priority for both HIV-infected and non-infected individuals. In the words of the World Health Report, 2008: ‘The growing reality that many individuals present with complex symptoms and multiple illnesses challenges service delivery to develop more integrated and comprehensive case management’.28
The developers of HIV-focused EMRs report that they are developing modules for non-communicable chronic diseases. This is good news, but it remains to be seen if the funding agencies will be willing to support non-HIV-related projects.
Given that our readers may be clinicians with limited computer expertise, we thought it important to summarise the characteristics of each product in a concise format. Unfortunately, there is no validated scoring system for software ease of installation, use and maintenance. JB, a computer scientist experienced with the operating systems and databases used in each of the products, summarised his opinions concerning ease of installation, use and maintenance (table 7).
Our judgement of technical characteristics
PSM has had limited personal experience with two of the systems, Dream–SE and WorldVista. We use neither of the systems currently but investigated each of them as potential EMRs for our teaching clinic prior to undertaking this study. WorldVista was developed by the US Veterans Administration as an inpatient EMR, and while it is not reflected in the survey responses, it lacks some of the basic functionality needed to operate as a fully functioning outpatient EMR. The application is written in an obsolete programming language (MUMPS), and the basic application is thus not easily editable, which does not allow implementers to remove references to ‘the veteran’ or change other functionalities appropriate to in-hospital care of veterans. For the same reason, it is functionally an English-language-only system. DREAM–SE is a fully functioning outpatient HIV care EMR, but using it for primary care is problematic because of lack of full ICD codes or a complete coded drug list.
OpenMRS has been described by one of its developers as a platform, rather than an EMR. It allows for extensive customisation but would be most appropriate for clinicians who have considerable time, programming skills and motivation. An interesting implementation of OpenMRS, the Baobab system,4 was not eligible for this study because it is a proprietary system.
OSCAR is a fully developed system and appears to be the best choice for primary care, but safe medication prescribing will be a challenge because of international differences in drug names and dosage forms.
Safe medication prescribing is a key function of EMRs and the lack of an established international standard for drug coding is a challenge. The USA has a National Drug Code Directory29 which is used by commercial EMRs in the USA. WHO has developed an international drug dictionary.30 Using the US system as a model, the WHO drug dictionary could potentially be used as the basis for an international medication coding system for EMRs.
Potential adopters of any of these EMRs should proceed cautiously and, if possible, communicate directly with others who have installed and used the application in the desired language and clinical setting. We strongly recommend that any potential user test a working system before making a decision to adopt it.
Limitations
This study relied solely on self-report from informants who actively use and continue to develop the included systems. We administered three surveys to different observers in order to get a fairer picture of the systems. We used the personal judgement of JB, a computer scientist, concerning ease of installation and maintenance of the software. Given the complexity of the applications and the need for extensive testing in order to ascertain functionality, we were not able to confirm the accuracy of the reported data.
In spite of repeated enquiries, we were unable to obtain responses from two developers. Primary Health Care Records has had no publications or web presence since the one pilot study was published in 2007.21 SmartCare has a website (http://www.smartcare.org.zm) but is only implemented through partner organisations such as the Zambian Ministry of Health, the US Centers for Disease Control and the Elizabeth Glaser Paediatric AIDS Foundation. Like the Baobab EMR,4 it is a proprietary system developed with public funding and is not available to non-affiliated users.
Conclusions
Given the importance of the EMRs for the future of medical care, we feel it is imperative that an international body directly test these products to determine their clinical functionalities and limitations. Unfortunately, the long-term goal of having primary care data available for local, national and global use in making public health and quality care comparisons is nowhere in sight. Ultimately, a new Millennium Development Goal should include the creation of a universal open-source health informatics platform that will allow the collection, management and delivery of clinical and population data that will guide decision processes at the local, regional and global levels. Until this goal is achieved, care will continue to consume unnecessary resources because of fragmentation, medical errors and poor data utilisation.
References
Footnotes
Contact information: The following developers were willing to share their contact information with readers: DREAM: ict{at}dreamsantegidio.net; PHIS: paul.fisher{at}ufrgs.br and OSCAR: phuttenczapski{at}gmail.com
To cite: Millard PS, Bru J, Berger CA. Open-source point-of-care electronic medical records for use in resource-limited settings: systematic review and questionnaire surveys. BMJ Open 2012;2:e000690. doi:10.1136/bmjopen-2011-000690
Contributors PSM is the lead author. PSM, JB and CAB made substantial contributions to conception and design, acquisition of data, analysis and interpretation of data; drafting the article and revising it critically for important intellectual content; and final approval of the version to be published.
Funding This study was supported by the Fogarty International Center, National Institutes of Health (grant number: 3 D43 TW01038) and by the Catholic University of Mozambique. No funding bodies played any role in the design, writing or decision to publish this manuscript.
Competing interests None.
Provenance and peer review Not commissioned; externally peer reviewed.
Data sharing statement All data have been published. The survey instruments are available from the authors.