Open-source point-of-care electronic medical records for use in resource-limited settings: systematic review and questionnaire surveys.

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.

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.

Table 1

Included electronic medical records

Product	Ambulatory point-of-care sites
iSante5	Haiti
PHIS	Guyana
Dream–Sant Egidio11	Italy, English-, Portuguese- and French-speaking African countries
OpenMRS (http://www.openmrs.org)	Primary care: Chile
	MDR-TB: Pakistan, Haiti, Los Angeles20
WorldVista18	USA
OSCAR (http://www.oscarcanada.org)	Canada, Kenya, Argentina, Ecuador

Table 2

Excluded products

Product	Reason for exclusion
Mosoriot Medical Record System	Subsequently renamed AMRS
AMRS7	Paper-based entry with retrospective electronic entry
MEDCAB10	Proprietary
PCHR (Primary Care Health Records)21	Developer did not respond
Careware®22	Not currently being developed
PIH-EMR: Partners in Health23	Internet based
HIV-EMR: Partners in Health24	Internet based
SmartCare (http://www.smartcare.org.zm)	Proprietary for use by partner organisations
ESOPE (from Ensemble pour une solidarité thérapeutique hospitalière en réseau, ESTHER)	Relational database, not an EMR
SICLOM14	Drug management system
PatientOS25	Open source, for profit, proprietary
Tolven26	Internet based
Fuchia (Follow-Up of Clinical HIV Infection and AIDS)14	Not currently being developed
Baobab Health/Malawi EMR4	Proprietary for use in Malawi only

EMR, electronic medical record.

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.

Table 3

Concise summary of clinical functionalities

	OpenMRS	Dream–Sant Egidio	GHIS	iSante	WorldVista	OSCAR
Target conditions	Primary care, HIV	HIV	Primary care, HIV	HIV	Primary care	Primary care
Languages	Eng, Sp	Eng, Fr, Port, Ital	Eng	Fr, Eng	Eng	Eng, Fr, Sp
Auto generate patient ID	Yes	Yes	Yes	Yes	Yes	Yes
Form-based demographic data entry	Yes	Yes	Yes	Yes	No	Yes
Enter and retrieve metric vital signs including calculated BMI	Yes	Yes	Yes	Yes	Yes	Yes
Coded and editable past medical history, family history, risk factors	No	No	Yes	Yes, but not editable	Yes, but difficult to edit	Yes
ICD coded problem list	Yes	Yes	Yes	Partial list	Yes	Yes
Coded med list, med interaction and allergy checking	No	No	No	No	Yes	Yes
Pharmacy inventory	No	Yes	Yes	No	Yes	No
Prescription printing	No	No	Yes	No	Yes	Yes
Flow sheets for common illnesses	No	No	Yes	Yes	Yes	Yes
Health maintenance reminders	No	Yes	Yes	Yes	Yes	Yes
Print lab order	Yes	Yes	Yes	No	Yes	Yes
Print imaging request	Yes	No	Yes	No	Yes	Yes
Demographics and diagnosis reporting	Yes	Yes	Yes	Yes	Yes	Yes
Quality report cards	No	No	Yes	Yes	Yes	Yes

BMI, body mass index; Eng, English; Fr, French; ICD, International Classification of Disease; Ital, Italian; Port, Portuguese; Sp, Spanish.

Table 4

Full clinical implementer responses

EMR system	OpenMRS	DREAM–Sant Egidio	GHIS	iSanté	WorldVista	OSCAR
EMR design
Designed for what level of care/specialty care	Primary care	HIV/AIDS	HIV/AIDS and primary care	HIV/AIDS	Primary care	Primary care
Languages	Eng, Sp	Port, Ital, Eng, Fr	Eng	Fr, Eng	Eng	Eng, Fr, Sp
Patient registration
Form-based data entry for patient registration	X	X	X	X	–	X
Auto generate unique patient ID	X	X	X	X	X	X
Patient arrival/flow
Able to search/retrieve info on various criteria?	X	–	X	X	X	X
Office visit scheduling system?	X	X	X	X	X	X
Retrieve records and mark ‘arrived’ on f/u?	X	X	–	X	X	X
Vital signs
Enter and retrieve ALL vitals?	X	X	X	X	X	X
Templates
Form-based templates?	X	X	X	X	X	X
Coded data entered in templates?	–	X	X	X	X	X
PMH, FH, Smoking, and ETOH coded as variables?	–	–	X	X, but not editable on follow-up visits	X, but difficult to edit on follow-up visits	X
Procedure notes
Template-based provider procedure notes?	X	–	–	–	X	Boilerplate text notes
Problem list
List based on ICD-9 or ICD-10?	X	X	X	X	X	X
List in local language?	X	–	X	X	X	English but ability to load ICDs in other language
Short pick list AND comprehensive list?	X	X	X	Only short pick list, not comprehensive	X	X
MED list and RX
Allows for allergy AND drug interaction check?	–	–	–	–	X	X
List updated to Rx availability?	–	X	–	X	X	X
Rx sent to on-site pharmacy?	–	X	X	X	–	X
Track inventory in pharmacy?	–	X	X	–	X	–
Option to print Rx?	–	–	X	–	X	X, also with bar code
Flow sheets and remainders
Customised info retrieval flow sheets for common dx?	–	–	X	X	X	X
Health maintenance remainder?	–	X	X	X	X	X
Labs and results
Print labs request?	X	X	X	–	X	X
Electronic labs request?	X	X	X	–	X	X
Manual entry of results?	X	X	X	X	X	X
Imaging and results
Print imaging requests?	X	–	X	–	X	X
Manual entry of results?	X	X	X	X	X	X
Reporting
Reports of pt. demographics?	X	X	X	X	X	X
Reports of dx or ICD code?	X	X	X	X	X	X
Meds Rx report?	–	X	X	X	X	X
Quality report cards?	–	–	X	X	X	X

–, No, not present; EMR, electronic medical record; Eng, English; Fr, French; ICD, International Classification of Disease; Ital, Italian; Port, Portuguese; Sp, Spanish; X, Yes, present.

Table 5

Technical implementer responses

EMR system	OpenMRS	DREAM–Sant Egidio	GHIS	iSanté	WorldVista	OSCAR
Type of server at back end
Brand	Dell Power Edge 1950	HP, Dell	Dell	HP, Dell	Any	Dell
Type of processors	Intel Xeon 5400 series 3.33 GHz	Intel Xeon Intel Dual Core	Intel Dual Core	Intel Dual Core Others	X86, VAX/Alpha	I7
Number of processors	4	1	1	1	1	1
Total hard drive capacity	4 GB	250 MB	100 GB	1 GB	200 MB	500 MB
Hard drive capacity in use	500 MB	80 MB	15 GB	500 MB		200 MB
Hard drive configuration	RAID 1	–	RAID 1	No raid	–	No raid
Server operating system	Linux, Windows	Windows	Windows	Windows/Linux	Linux, Windows, Unix, VMS	Linux, Mac OSX and Windows
Web server	Apache	Not applicable	Apache	Apache/IIS	Apache, IIS	Apache Tomcat
Database running EMR system	MySQL	MS SQL Server	MS SQL Server	MySQL MS SQL Server	Any that have compatible APIs	MySQL
Other software required	Java JDK 1.6 +, PHP 5.3+	MS Access	MS VB.Net	LDAP, Perl, Cygwin (Windows only), Java, JasperReports		Sun Java
Cost of servers	US$4000–$5000	US$2000	US$1500	US$10 000	US$2000	US$1000
Type of workstations running the EMR back end
Brand	PC, NetBook, Tablet	HP, Dell	Dell	HP, Dell	Any	Dell, Any
Type of processor	1.5 GHz any processors	Intel Pentium 4, Intel Core 2 Duo, Intel Celeron, AMD	Intel Celeron	Intel Dual Core, Others	X86	Pentiums mostly about 5 years old
Hard drive capacity	2 GB	80 GB	80 GB	500 MB	200 MB	100 MB
Operating system running workstations for the EMR front end	Linux, Windows, OSX	Windows	Windows	Windows	Linux, Windows, OSX	Linux, Windows, OSX
Cost of a typical workstation	US$1000	US$1000	US$700	US$1000	US$400	US$600
Networking
Type of network	Ethernet, GPRS, 3G	Ethernet	Ethernet	Ethernet	Ethernet	Ethernet
Type and number of switches	–	Layer 2 and Layer 3 Fast Ethernet Switchs	Routers, number varies according to site requirements.	1 linksys router	Ethernet	Dlink
Network bandwidth	Ethernet, Fast Ethernet	Fast Ethernet	Ethernet, Fast Ethernet	Ethernet, Fast Ethernet	–	Fast Ethernet
Backup system
Backup up functionality	Yes Management User, role and group Administration module Edition advanced data record. Administration service web.	Yes Standard MS SQL backup system, plus a daily copy of the database to another computer, and to the head office.	Yes scheduled backup to portable devices used to update master database	Yes, Standard OS File system backup + standard database backup + custom application data replication to remote server	–	Yes, Cron job that runs an encrypted compressed backup of the database and documents daily
IT providers related to the IT infrastructure	Lazos: Responsible of the operation and platform Frontera University: Center excellence Software Engineering, responsible of the proyect and development.	DREAM local IT Staff	In-house IT department of ministry of health responsible for installation maintenance and repair of all hardware and software	CIRG (Clinical Informatics Research Group) developed and supports the application. I-TECH Haiti IT staff and CDC staff supports the application in Haiti	–	Oscar Service
System deployment
Number and roles of people involved in deployment tasks	1 Manager Development and coordinator team 1 Analyst Quality and Testing 2 Software Engineers 1 Systems Administrator	2 technicians in country for deployment tasks with Servers administration and Network proficiency.	IT department technicians Site coordinator (system manager/administrator) Trainer	8–10 IT personnel do physical installation of hardware and installation and configuration of software across all sites in country	–	1 programmer from Oscar Service for install and one trainer from Oscar Install. Both done remotely via the internet
Overall estimated time for EMR software deployment (not including hardware/network)	8 months	1 h for 10 computers	1 month	3 days for software installation and training	–	Half day training session over the internet
Estimated cost for configuration and installation of software (not including hardware/network)	US$120 000	US$10 per site of 10 computers	US$5000	–	–	US$1500.00
EMR interface usability
EMR interface design follows standards/best practices	ISO 9241	ISO 9241	No	ISO 9241	–	ISO 9241
EMR interface intuitive and easy to learn for new users?	Yes	Yes	Yes	Yes	–	Yes, You can teach it over the internet. Locums are able to manage the system with minimal instruction by my nurse (15 min)
EMR interface easy to remember for users?	Yes	Yes It has good layout, functions buttons always in the same area and basic functions just a few clicks away.	No Requires time to get accustomed to NEW forms and reports	Yes	–	Yes, Same routine daily
EMR performance
Number of users of the EMR system	–	20 per site	3–10 per site	5 per site	–	20
Average number of concurrent users utilising the EMR system	10	8	3–10	3	–	10
Maximum number of concurrent users utilising the EMR system	40	No defined limit.	3–10	10	–	No real limit
Current size of database files	26 GB, 4.000.000 records	500 MB.	70 MB	1.27 GB	–	Backups fit on a DVD. 1.2 GB for documents and 240 MB database (Gziped)
Average availability of EMR system	Always available	Always available	Unavailable once a week	Always available	–	Always available
Average down time of EMR system when it fails	<1 h	<30 min	<1 day	<1 h	–	<1 min
Subjective speed of EMR
When entering patient data	2 s	0.5 s	Instant	Adequate	–	No delay
When accessing patient data	3–5 s	1 s	Seconds	Adequate for single patient access; large reports are cached and/or run overnight	–	Depends on the file. Opening a large patient file can take 3 up to 30 s with an internet connection
When sending queries for reporting	120 s	3 s	Depends on complexity of query	Aggregate real-time reports may take up to 30 min in some cases, but most standard reports take 30 s or less	–	Depends on the query. Some whole database conversions to CIHI XML format can take up to 20 min
EMR system integrated with other software?	CMS Typo3 Medica Agenda	No	No	Yes OpenELIS (lab info system)	–	Yes Local hospital reporting system. External laboratory reporting system
Standards used for transferring information	OpenEHR, LOINC	–	–	No Connected by Custom interface	–	HL7
EMR maintenance
Who provides operational maintenance	On-site resources	On-site resources	IT department technicians	CDC Haiti staff/ I-TECH Haiti IT	–	On-site resources
Who is in charge of fixing EMR software bugs and developing new functionalities?	External company	On-site resources	IT department technicians Site coordinator (system manager/administrator)	CIRG (Clinical Informatics Research Group—University of Washington)	–	Community
Overall cost of EMR maintenance	US$5000 per month	None	US$15 000 per year	–	–	No contract with our installer and upgrade locally. This does take time which I don't bill for … about 8 h to convert, test, and then convert live data.
EMR system deployment
Who was in charge of system deployment?	External company	On-site resources	IT department technicians Site coordinator (system manager/administrator)	CDC Haiti staff I-TECH Haiti IT	–	External company
Time for system deployment	2–3 s	Around 1 h for 10 computers.	1 week	3 days	–	Quite some time as they had to convert our existing proprietary EMR data to the Oscar standard. Apprx 50 h. A de novo install of Oscar is the time to install Ubuntu plus 15 min.
How many people were involved in the deployment tasks?	3–5 Technician	1 Technician	4 Technician	1 Technician	–	2 Technician
Training
Time required for user training	1 week	15 min for each section of the programme	1 week	1 day	–	One half day
Who conducted training tasks?	Software community	In-site resources	IT department trainer Site coordinator (system manager/administrator)	CDC Haiti staff I-TECH Haiti IT	–	External company
Number and roles of staff involved in training tasks	2 roles 1 Coordinator 1 assistant	One DREAM local IT Senior Staff.	IT department trainer Site coordinator (system manager/administrator)	One I-TECH Haiti trainer	–	One external employee and all the clinical and secretarial staff
Software currently has training manuals for the following:	IT Technical staff	Receptionists, clinicians, pharmacy staff	Receptionists, physicians, nurses, counsellors, DOTS staff, pharmacy staff, site coordinator, IT technical staff	Clinicians, users, IT technical staff	–	Receptionists, clinicians, pharmacy staff, IT technical staff

EMR, electronic medical record.

Table 6

Technical developer responses

EMR system	OpenMRS	DREAM–Sant Egidio	GHIS	iSanté	WorldVista	OSCAR
Servers
Type of servers which can run the EMR back end?
Brands compatible	Dell Power Edge 1950	Any	Not available	HP/Dell/others	Not available	Any
Type of processors compatible	Intel Xeon Processors 5400 series at up to 3.33 GHz	PC	Not available	Intel/others	Not available	Any
Minimum number of processors required	4	1	Not available	1	Not available	1
Minimum hard drive capacity required	4 GB	1 GB	Not available	1 GB	Not available	200 MB
Operating systems compatible with the EMR server	Linux	Windows	Not available	Linux, Windows, Unix	Not available	Linux, Windows, Unix, OSX and Solaris
Web servers compatible with the EMR server	Apache, GLASSFISH V2	Not applicable	Not available	Apache, IIS	Not available	Apache
Database systems compatible with the EMR system	MySQL	MS SQL Server	Not available	MySql, MS SQL Server	Not available	MySQL, ORACLE in older releases
Other software required for the EMR system functioning	Java JDK 1.6 +, PHP 5.3+	No required	Not available	LDAP, Java, Perl, Cygwin (Windows only), JasperReports	Not available	Java
Approach price of a minimum capacity server to run the EMR system	$4000–$ 5000	On small centre we use a $500 laptop.	Not available	$2000	Not available	$329
Workstations
Type of workstations that can run the EMR front end
Brands compatible	PC, NetBook, Tablet 1.5 Ghz any processors	ALL	Not available	Any windows server/notebook	Not available	Any machine that can load a web browser
Type of processors compatible	1.5 Ghz any processors	PC	Not available	Intel/others	Not available	Any
Minimum hard drive capacity	1 GB	1 GB	Not available	200 MB	Not available	100 MB
Operating systems compatible with the EMR front end	Linux, Windows	Windows	Not available	Linux, Windows, Unix	Not available	Linux, Windows, Unix, Other, OSX, Android, IOS, blackberry
Minimum price of a workstation to run the EMR front end	$500–$1000	$400	Not available	$600	Not available	$250
Networking
Type of networks are compatibles with the EMR system	Ethernet, GPRS, 3G	Ethernet	Not available	Ethernet, Fast Ethernet	Not available	Ethernet, 3G
Network bandwidth required to run the system	10 MB/s, Fast Ethernet	10 MB/s	Not available	Ethernet	Not available	Ethernet
EMR system scalability capabilities	The interfaces can to be developed in any language as flex, gwt or rap. The interface can to be installed in any CMS and can manipulate information using service web with openMRS. We can develop any systems and store the information in openMRS	Actually, the system scalability capabilities are guarantee by the using of a client server architecture with Microsoft SQL Server that provides growing databases with the tools and features necessary to optimise performance, scale-up individual servers and scale-out for very large databases	System is completely scalable, designed for use in small clinics and hospitals	EMR typically needs to support only a few users at a time. No scaling tests have been done	Scales from one user to thousands	The base systems (Java, MySQL etc) are very scalable. Oscar itself has some bottlenecks that will become a problem when getting to hundreds of concurrent users. There are fixes for those but have not been committed back to the trunk. The other approach is to run a distributed strategy with servers linked through the ‘Oscar Integrator’
Interoperability: capabilities to provide standard clinical information to external systems	Yes	NO Actually only export statistical data, we are working to give the possibility to export clinical data in International standard	NO, Currently, no but could be programmed to do so	NO	Yes	Yes
Interoperability standards supported	HL7, DICOM, LOINC	Not available	Not available	Not available	HL7, DICOM	HL7
Questions regarding the EMR system software development and environment
Licensing requirements of the EMR software	Open source	Free software (Closed Code)	Open source	Free software	Open source	Open source, free software, GPS
System architecture	Web based, service oriented, architecture	Client/server	Client/server	Web based	Web based and client/server	Web based and client/server
EMR technical documentation availability	Yes	No	Yes, included in source and documentation	Yes	Yes	Yes
Software platform used to develop the software	Java Clients, Web Services, PHP Extension CMS Typo3	NET, Access VBA	MS VB.Net	LAMP	Java Clients, Web Services	Java/Tomcat jsp/MySQL
Development environment used to develop the EMR system	Eclipse	VBA, Visual Studio	Visual Studio 2005	Developers chose favourite IDE	M	Eclipse
Language	Java, PHP5	C#, VB	MS VB.Net	PHP/Ext JavaScript Library	M	Java
Type of license of the development environment used to develop the EMR system	Open source	Proprietary	Proprietary	Open source	Open source	Open source
Security and privacy
Security characteristics:	User and login.Card, as cards bank Santander. Codification message between provider and client service web	Access only with login and password, user access levels, data exchange between centres or labs encrypted	System access via user name and password, record access based on user ID and type	Uses LDAP for authentication and application proprietary scheme for authorisation and roles	Meets all security requirements for operation in VA Hospitals and CCHIT	A granular security policy exists so access can be restricted
HIPAA compliance	Yes	No	No	Yes	Yes	No
Community
Is the EMR system supported by a community?	Yes	No	No	No	Yes	Yes
Services provided by the community	Documentation, bug reporting, update, module plugin, forum	–	–	–	–	Answering surveys, documentation, translations, some code

EMR, electronic medical record.

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).

Table 7

Our judgement of technical characteristics

	OpenMRS	Dream–Sant Egidio	GHIS	iSante	WorldVista	OSCAR
Hardware requirements	1	1	1	1	1	1
Operating system	1	1	1	1	1	1
Non open-source components	1	2	2	2	2	1
Technical skill for installing and maintaining	1	1	1	1	2	1
Openness of software code	1	2	2	2	1	1
Training manuals	IT technical staff	Receptionists, clinicians, pharmacy staff	Receptionists, physicians, nurses, counsellors, DOTS staff, pharmacy staff, site coordinator, IT technical staff	Clinicians, users, IT technical staff	–	Receptionists, clinicians, pharmacy staff, IT technical staff

Ratings: 1, easy, simple, open; 2, moderately complex; 3, difficult, complex, closed.

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.