Scholarly article on topic 'Towards the Adoption of Open Source and Open Access Electronic Health Record Systems'

Towards the Adoption of Open Source and Open Access Electronic Health Record Systems Academic research paper on "Medical engineering"

0
0
Share paper
Academic journal
Journal of Healthcare Engineering
OECD Field of science
Keywords
{""}

Academic research paper on topic "Towards the Adoption of Open Source and Open Access Electronic Health Record Systems"

Towards the Adoption of Open Source and Open Access Electronic Health Record Systems

Ilias Maglogiannis*

University of Central Greece, Department of Computer Science and Biomedical Informatics

Submitted July 2011. Accepted for publication December 2011. ABSTRACT

As the Electronic Health Record (EHR) systems constantly expand to support more clinical activities and their implementations in healthcare organizations become more widespread, several communities have been working intensively for several years to develop open access and open source EHR software, aiming at reducing the costs of EHR deployment and maintenance. In this paper, we describe and evaluate the most popular open source electronic medical records such as openEMR, openMRS and patientOS, providing their technical features and potentials. These systems are considered quite important due to their prevalence. The article presents the key features of each system and outlines the advantages and problems of Open Source Software (OSS) Systems through a review of the literature, in order to demonstrate the possibility of their adoption in modern electronic healthcare systems. Also discussed are the future trends of OS EHRs in the context of the Personal Health Records and mobile computing paradigm.

Keywords: Open source software systems, electronic health records, OpenEMR, OpenEHR, OpenMRS, patientOS, personal health records

1. INTRODUCTION

In a world that constantly adopts electronic health solutions, the healthcare industry continues its quest for the ideal computing platform to serve caregivers and patients. As the Computer-based Patient or Electronic Health Record (CPR, EHR) system expands to support more clinical activities, healthcare organizations are asking physicians and nurses to interact increasingly with new computer systems to perform their jobs. The present lively interest in electronic health recognizes its potential to offer tremendously useful health care service delivery advantages. Clinical data, patient history and medical image handling efficiency are translated directly into labor and time savings, significantly reducing healthcare costs. Medical platforms allowing doctors to access EHR are already set up in several countries [1, 2, 3]. An EHR is an electronic version of a patient's medical history, that is maintained by the healthcare provider over time, and includes all of the key administrative clinical data relevant to that person's care

*E-mail: imaglo@ucg.gr. Phone: +30-2231066931, Fax: +30-22310-66907 Papasiopoulou 2-4 35100 Lamia Greece.

under such provider, including demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, medical images and radiology reports [4]. The EHR automates access to information and has the potential to streamline clinicians' workflow. The EHR also has the ability to support other care-related activities directly or indirectly through various interfaces, including evidence-based decision support, quality management, and outcomes reporting. Significant background information related to EHRs' specifications, technical issues and medical data coding systems may be found in [5 - 10]. The types of indicative data included in EHR systems are presented in Table 1. EHR systems provide the healthcare organizations with the infrastructure to collaborate efficiently at technical level. Hospitals are sufficiently rich in their infrastructure to handle the internal administrative and clinical processes, and the need to integrate the processes of geographically distributed and organizationally independent organizations is evident.

Table 1. Electronic Health Records data modalities

Digital Data Contrast / Resolution (No. of samples per second x bits per sample) Data Size

Demographic Data ~ 100 KB

Basic Medical History (Problems, Medications, Known Allergies) ~ 10MB

Clinical Data (Biosignals) ~ 100 KB / incident

Digital audio stethoscope (Heart Sound) 10000 X 12 ~120 Kbps

Electrocardiogram ECG 1250 x 12 ~ 15 Kbps

Electroencephalogram EEG 350 x 12 ~10 Kbps

Electromyogram EMG 50000 x 12 ~ 600 Kbps

Laboratory Results ~ 1 MB (/exam)

Ultrasound, Cardiology, Radiology 512 x 512 x 8 256 KB (image size)

Magnetic resonance image 512 x 512 x 8 384 KB (image size)

Scanned x-ray 1024 x 1250 x 12 1.8 MB (image size)

Digital radiography 2048 x 2048 x 12 6 MB (image size)

Mammogram 4096 x 4096 x 12 24 MB (image size)

Compressed and full motion video (endoscopy or telemedicine) 384 kbps to 1.544 Mb/s (speed)

Furthermore, during the past few years, several research communities worked intensively to develop reliable open access and open source (OS) EHR implementations, in order to reduce the financial requirements of electronic health. An open access/source EHR system ensures further cost savings by reducing the expenses for installation, maintenance, upgrading, etc. of such systems. OS enables to easily interface "foreign" modalities, e.g., any known brand of new equipment or new software. This is a consideration of special importance to less affluent markets as in the so-called third world, where diagnostic centers are few and scattered, and the financial resources are limited.

Open Source Software (OSS) in electronic healthcare can provide advantages in terms of the software cost, but the most important benefit is their openness and flexibility [10]. The open source EHRs enable individual regions to adapt Information Technology (IT) to their own special needs and not be beholden to multiple commercial software vendors, thus allowing the establishment of regional healthcare networks [11, 12]. Since small clinics and organizations with limited human resources cannot afford huge annual expenses on software, they are more willing to adopt the alternative choice of open source EHRs. Furthermore, a crucial factor in using open source EHRs is their free usage by the public and that they are not limited by licensing and ownership by any individual or entity. Therefore these products can be accessed and interactively altered by every authorized practitioner. The open source code is accessible to all programmers to serve the individual needs of the users, providing opportunities to enhance the system architecture and technical features in order to comply with multiple operating systems and facilitate health information exchange. In terms of services and tool adaptation, modern open source EHRs are capable of incorporating communication standards, such as the HL7 messaging, between and among systems in a way that they facilitate the development of more generic interfaces [13].

The potential benefits of open source EHRs' wide adoption are extensively reported in literature; however penetration is limited due to some issues yet to be considered [14, 15]. The most important issue is the lack of support and technical assistance, since there is no service indicated by the licensing forms of the software. As a result, software upgrading and enhancement depend on the user's skills and familiarity to the software. In addition, a major disadvantage is the lack of credibility and validity of the software, especially after dramatic alterations of the initial version. Sensitive medical and personal data (demographic data, patient's history, etc.) are disposed in an unsafe environment or network taking little responsibility for its users and providing no opportunity to engage technicians or scientific collaborators. Another issue is that OSSs require, in most cases, in-house customization and training before the medical staff can use it efficiently and develop materials and forms to meet specific needs. These issues are discussed in the following Section 2, which describes, from our perspective, some popular open source electronic medical record systems, namely, openEMR, openMRS and patientOS, and provide a comparison of their technical characteristics along with a short evaluation. Section 2 also reports a widely documented and extensively employed OS EHR specification (viz. OpenEHR), as well as some other open access EHRs available today. Section 3 describes some additional task-specific OSSs in the electronic healthcare domain along with their emerging applications and future trends,

while Section 4 reports the shortcomings and unsettled issues that deter the full adoption and deployment of OSS EHRs. Finally, Section 5 provides a discussion on the major benefits and drawbacks of the open source EHRs adoption through Strengths, Weaknesses, Opportunities, Threats (SWOT) analysis, and concludes the paper.

2. REVIEW OF EXISTING OPEN SOURCE ELECTRONIC HEALTH RECORD SYSTEMS 2.1. The OpenEMR System

OpenEMR (www.oemr.org) is a widely adopted free and OS EMR system supported by a variety of operating systems and platforms. Historically, OpenEMR was initiated by Synitech Corporation and its version 1.0 was released in 2001 as MP Pro (Medical Practice Professional). The openEMR's code has been implemented with improved security features according to its guidelines [16]. The product was reintroduced as OpenEMR version 1.3 in 2002, and later on evolved into an open source project through version 2.0, that Pennington Firm became its primary maintainer in 2004. Pennfirm promoted OpenEMR in the medical community; as more developers and users became active in making improvements through acquiring the technical knowledge and programming skills for the program, the OpenEMR's code base was acquired by SourceForge in 2005. The OpenEMR is a fully functional EHR that can be downloaded, stored and deployed by any individual. The OpenEMR programming community certifies its improvement and online assistance, and has been gaining recognition as an option in the healthcare industry.

The aim of OpenEMR is to support small healthcare units or larger clinics and hospitals. It contains a multimodal environment that provides patient's demographic information, medical data, laboratorial testing results, encounter templates (an encounter is an interaction/contact with a physician), an appointment calendar (with availability crosschecking), electronic billing system, reporting, etc. The OpenEMR is accompanied with licensing guidelines that clearly state prohibition of reselling or any exploitation of the product. OpenEMR follows some of the HIPAA standards (http://www.hipaa.org/) regarding security. The Health Insurance Portability and Accountability Act (HIPAA), enacted by the U.S. Congress in 1996, is the most prominent standard in the field of electronic health security today.

2.1.1. OpenEMR features

OpenEMR basic features are listed below:

• Practice Management features for patient scheduling, patient demographics.

• EMRs, creating an on-line record of encounters/incidents according to the incident-based EHR design paradigm.

• Compliance with medical terminology standards. Ability to enter CPT (Current Procedural Terminology) and ICD-9 (International Classifications of Diseases) codes at the end of a patient encounter. CPT codes are numbers assigned to every task and service a medical practitioner may provide to a patient, including medical, surgical and diagnostic services. These codes are then used by insurers to determine the amount of reimbursement that a practitioner will receive for providing the service. The clearly defined, standardized codes ensure uniformity. ICD codes are alphanumeric

designations given to every diagnosis, description of symptom and cause of death attributed to human beings. These classifications are developed, monitored and copyrighted by the World Health Organization (WHO). Efforts have been also undertaken to incorporate the newest version of ICD-10. Advanced reporting capabilities with PHPMyAdmin administration tool. Prescription writing feature allowing email or print prescriptions. Compliance with medical data communication standards such as HL7 (http://www.hl7.org/) which supports to parse HL7 messages and allow information to be shared and processed in a uniform and consistent manner.

2.1.2. Architecture and Technical Components of OpenEMR

Figure 1.

OpenEMR screenshots: (a) summary screen, (b) calendar screen, (c) add new patient form, and (d) printed reports.

OpenEMR's interface is accessible by authorized users (through basic authorizing mechanisms), and medical records for each patient are easily viewed via a summary screen displaying a brief description of medical issues, medical prescriptions, allergies and history (see Figure 1). Moreover, OpenEMR is constructed on a LAMP (Linux,

Apache, MySQL and PHP/Perl/Python) architectural platform that is very popular for the development of OSS applications. In addition, OpenEMR poses complex programming issues to its open source community for further manipulation and problem solving, supporting its users with a more mature and stable software stack.

The OpenEMR solution consists of three components: the Practice Management System (PMS), FreeB, and SQL-Ledger. The PMS is the main component of the platform that provides the application functionality, the cross validation of the calendaring system, the electronic medical records, the encounter/incident forms and the medication electronic prescriptions. FreeB is an open source medical bill formatting engine for medical billing documents, while SQL-Ledger is a double-entry accounting system, not specific to electronic healthcare. In the primary versions of OpenEMR, security issues were to be addressed as a crucial troubleshooting for its adoption. However, through systematic work and alterations on the base code, concerning the role-based access control and administration rights, the security level has risen significantly. Role-based access control allows access to certain data objects based on three aspects of security: the user requesting access, the object being requested, and the role of the user.

2.2. The OpenMRS System

The OpenMRS system (www.openmrs.org) is an open source, collaborative software that can serve as a foundation for EHR development in developing countries [18]. It has mostly served physicians who are dealing with populations infected by the HIV virus in developing countries. More specifically, OpenMRS community focuses on management of medical data under the predicament of limited equipment and staff expertise in treating and managing care for patients with the aforementioned diseases in Eastern and Southern Africa. Initial implementations have been deployed in Kenya, Rwanda, and South Africa, and pilot implementations are being evaluated in Lesotho, Malawi, Tanzania, Uganda, and Zambia [19 - 23].

2.2.1. OpenMRS Features

The OpenMRS core is a Java application that runs within the Java runtime environment (http://java.sun.com). Web pages were developed in JavaScript and run within Apache Tomcat (http://tomcat.apache.org/), a servlet container used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The OpenMRS uses the MySQL (www.mysql.com) relational database management system (RDBMS) for data storage. Although the OpenMRS software is free and open, in some implementations, the front end forms require InfoPath (developed by Microsoft Corporation), a commercial application included in the Office 2003 Professional suite of products. The OpenMRS interface supports forms that are produced by Infopath as an efficient means to facilitate data entry. The OpenMRS user interface is shown in Figure 2.

(a) (b)

Figure 2. OpenMRS Screenshots: (a) main screen, and (b) medical images viewer.

2.2.2. Architecture and Technical Components of OpenMRS

All components required for OpenMRS implementation (with the exception of Microsoft InfoPath) are freely available. The software and scripts required to install and run OpenMRS are distributed through two web sites: (1) www.openmrs.org, which is the main web site for OpenMRS (hosted by the Regenstrief Institute, Indiana University, Indianapolis, USA), and (2) http://trac.openmrs.org, which is the main page of the open source development project (hosted by the Regenstrief Institute, Indiana University, Indianapolis, USA). A complete standalone version of OpenMRS requires at least 300MB of disk space, including the following:

1. MySQL- 143MB

2. Java Runtime Environment - 68.7MB

3. Apache Tomcat - 14.3MB (excluding the OpenMRS application)

4. Mozilla Firefox - 15.7MB

5. OpenMRS application - 23.9MB

Additional disk space is required to store the forms and the patient data, which can grow to a very large size.

The OpenMRS system [18] may be deployed either as a standalone application on a single computer or, more effectively, as a multi-user application in a client-server configuration where the RDBMS is maintained on a separate database server. In the client-server configuration, the OpenMRS application may be located on the same database server or on a separate application server. This facilitates modularity in the architecture employed, which is the key of any large and distributed system. OpenMRS Tier Architecture, as shown in Figure 3, consists of the database tier, the web/application tier and the presentation tier. OpenMRS forms are developed as XML style sheets and follow the XForms specification. The application also communicates internally using the HL7 messaging standard.

Curant

-Presentation Tier

Figure 3. OpenMRS tier diagram (source: openmrs.org)

2.3. The PatientOS System

PatientOS (www.patientos.org; OS stands for Open Source) was initially introduced under an integrated Healthcare Information System (HIS). The patientOS architecture includes multiple design patterns, modern interfaces and framework that aim to run applications for a wide variety of users. The PatientOS community envisioned an open source product that will satisfy the needs of medical staff for efficient, functional and easy to use software. The right default values, the consistent layout, the fewest clicks, and the scripting behind the scenes are intended to save work and automate actions. The entire system user interface is configurable, allowing redesigning and rebuilding of the user interface as requirements evolve. Every piece of information visible on the forms can be customized - even the layout of the panels, the depth of the cascading lists, and more. The interface is consistent throughout the application enabling quick adoption by the medical staff.

2.3.1. PatientOS Features

The primary goal of PatientOs is to scale and evolve into a fully-fledged healthcare information system for hospitals. In version 0.40, an important alteration is the integration of HL7 standard inbound interface (ORUAR01), where the HL7 messages match the patient by identifiers and post clinical data and laboratory results captured by other systems into the patients chart. Moreover, several other add-ons, such as the advanced laboratory result viewer, have been incorporated in order to improve the systems efficiency. The PatientOS basic features are listed below:

• Registration, scheduling, reminders, patient lists.

• Lab result viewing, flow sheet (observation) viewing.

• Clinical and administrative forms, templates.

• Physician order entry, prescription writing.

• Clinical documentation - inking, multimedia.

• HL7 Interfaces - Admission, Discharge, Transfer (ADT), Orders, Results, Observations, Charges.

• Patient portal and email integration.

• Custom reports, batch jobs, data mining

2.3.2. Architecture and Technical Components of PatientOS

PatientOS features an architecture model that divides the reference data into individual structures in order to increase functionality. More specifically, the PatientOS system divides its architecture into 3 layers: the Client/Presentation Layer, the Middleware/Business Logic Layer, and the DataBase Access Layer. This architecture is similar to OpenMRS and is depicted in Figure 4. The business layer resides in the application server with the middleware provided by the Open Source JBoss Enterprise Application Server, while the RDBMS is again the popular MySQL. Figure 5 displays two of the basic PatientOS screenshots.

Figure 4. PatientOS system architecture (source: patientos.org)

(a) (b)

Figure 5. PatientOS screenshots: (a) scheduling screen, and (b) patient form.

2.4. OpenEHR Specification-Based Systems

An extensively documented specification for developing OS EHRs is OpenEHR, which is available online at www.openehr.org. OpenEHR has a holistic approach to standardizing EHRs by supplying system specifications for both data and clinical phenomena/observations. The OpenEHR foundation, which provides the OpenEHR software, is an international non-profit consortium founded in 2000, aiming at improving the health sector and creating new perspectives for managing EHRs. The main feature of OpenEHR is its architecture reference models and especially archetype models, which are used for standardization of data and clinical observations.

Figure 6. The OpenEHR artefact ecosystem (source: openehr.org)

The key innovation in the OpenEHR framework (Figure 6) is the archetypes. This model leaves all specification of clinical information out of the information model and provides a powerful means of expressing the clinicians' and patients' reports that they need to record so that the information can be understood and processed wherever there is a need. Clinical information models are specified in a formal way ensuring the specifications, known as 'archetypes', are computable. The archetypes express clinical information requirements in 'chunks' that have the maximum utility; they can be reused very often in health care settings. They are designed to be as inclusive as possible, and thus represent the maximal datasets for the information constructs, in order to reduce the number of archetypes required and to increase their expressivity. Archetypes are always statements made within the context of the OpenEHR reference model. Therefore, designers do not have to be concerned with representing who provided the information, what it is about, when it was stored or added to the EHR. There are many other features of the reference model designed to reduce the need of archetype, such as the timing of observations, including interval measurements such as maximum and

minimums, and the ability to provide a reason if mandatory information is not available at the time a record was created.

The OpenEHR archetypes need to be quality managed to conform to a number of axioms such as mutual exclusiveness. The software community has collaborated closely with a group of physicians in order to secure the high standards in which archetypes are formed and processed in the software. Archetypes are designed to support clinical decision and allow the specification of clinical knowledge to evolve and develop over time. Since the architecture is archetype-driven, it satisfies many requirements outside the original concept of the "clinical EHR". For instance, the same reference architecture can be used for veterinary health or even "care" of public infrastructure or buildings.

2.5. Evaluation and Discussion of the Surveyed Open Source Electronic Health Record Systems

As mentioned in the introduction, in evaluating the specific OSS EHRs, some difficulties in terms of ease of installation and user friendliness occurred. The setup of the systems was not obvious in some of the cases and requires IT administration skills. PatientOS seems to be less popular than the other open source software due to its complexity in setting up, particularly in customizing its forms, settings and scripts. However, it supports more functions, is web-based, and is fully customizable. PatientOS community has started integrating the AJAX web technology to enhance its user experience. Clinical information and questions may also be submitted by multiple users and accessed by a pending queue within the main application.

The OpenEMR has a small but vibrant community. Built on a standard software stack, OpenEMR seems to offer security features far more advanced in comparison to the other OSS EHRs. Additional benefits are its portability and expandability.

The strength of OpenEHR-based systems is in the archetypes that distinguish such systems from the other presented medical record software in the capability of supporting physicians in decision making and diagnosing. Archetypes are recordings of things of interest (e.g., observation, evaluation) during the clinical process according to the healthcare professionals and following typical clinical approaches. In practical terms, archetypes are practical in their intent, and only capture what healthcare professionals think they need to record. OpenEHR's proposed interface is comprehensive and easy to use, while its database schema is considered appropriate and complete in providing crucial information to its users.

The OpenMRS is based on a "concept dictionary" that describes all the data items that can be stored in the system, such as clinical findings, laboratory test results and socio-economic data. This approach avoids the need to modify the database structure in order to add new diseases, for example, and facilitates sharing data dictionaries between projects and sites. An important feature of OpenMRS is its modular construction, which allows the programming of new functions without modifying the core code. The main characteristics of the surveyed OS EHRs are summarized in Table 2.

Table 2. Comparison of the surveyed open source software for electronic health

records

Architecture Standards Features Security

OpenEMR Linux, Apache, MySQL/PHP/Perl/ Python CPT (Current Procedural Terminology)/ ICD (International Classifications of Diseases)/ HL7 Incident-based EHR design paradigm HIPAA compliant

OpenMRS MySQL/ Java Runtime Environment/ Apache Tomcat OpenMRS Tier Architecture HL7 May be deployed as a standalone application or, as a multi-user application in a client-server configuration Role Based Access Control

PatientOS Multi-Tier Architecture Jboss Enterprise Application Server, /MySQL HL7 - ADT, Orders, Results, Observations, Charges Patient Portal and Email integration / Custom reports, batch jobs, data mining User Based Access Control

OpenEHR based systems Java / Python ASTM Continuity of Care Record / SNOMED CT/ HL7 Archetype modeling User Based Access Control

3. OTHER SYSTEMS: EMERGING APPLICATIONS AND FUTURE TRENDS

The aforementioned open source EHRs are considered quite mature and complete implementations of the OSS concept in the electronic healthcare domain according to the utilization statistics presented on their web sites. A significant effort had also been undertaken by Google for the implementation of Google Health service (www.google.com/health/). The main difference from the systems described above is that this EHR is actually a Personal Health Record (PHR) where data are input and administered by the patients. However, Google has recently decided to discontinue the Google Health service after January 1, 2012. According to Google's announcement, the main reason is that the service did not create the desired broad impact they expected. Although it has been adopted by certain groups of users, such as computer literate patients, physicians, and more recently fitness and wellness enthusiasts, the service did not manage to reach a high level of penetration and failed to enter the modern social networks (e.g., facebook, twitter, etc). The main reason for the low adoption may be the lack of trust concerning the privacy of the stored medical data by a private organization. An extensive discussion on the limitations of OS EHR systems, and the reasons for their

limited popularity is provided in the last section of this paper.

Nevertheless, Google Health service (see Figure 7) provided some great ideas and concepts on enabling users to enter their health records - either manually or by logging into their accounts at partnered health services providers. The key idea is thereby to merge potentially separate health records into one centralized Health Record system. The medical information included in PHRs consists of health conditions, medications, allergies, and lab results. Various implementations of PHRs are emerging in replacement of the Google Health, such as the MyPHR service (http://www.myphr.com/). Other open source implementations of PHR similar to the Google Health include Indivo software (http://www.indivohealth.org/) and UHR (Universal Health Record) which is a PHR system managing medical information intended to be exchanged in a scalable way with particular health care providers at the patient's discretion.

Figure 7. Google Health service: (a) main screen, and (b) partnered health services providers

Another type of EHR systems is those intended for storing systematic data produced during clinical trials. Three different implantations of this type are in the OSS community: Caisis (http://www.caisis.org), TrialDB (http://ycmi.med.yale.edu/trialdb/index.shtm) and OpenClinica (http://www.openclinica.org). All of these systems are effective in serving the particular need of clinical trial data collection.

Some additional OSS utilized in the e-health domain, not necessarily as complete EHR systems but as modules that may interact with EHRs, are summarized below:

• Apelon (http://apelon-dts.sourceforge.net/) is a Distributed Terminology System (DTS) offering terminology, data standardization and classification services for clinical data. It supports well-established standards in the medical community, such as ICD-9, CPT and SNOMED CT coding standards.

• caAERS (https://cabig.nci.nih.gov/tools/caAERS) is a tool developed specifically to record cancer related cases and incidents incorporating the corresponding cancer treatment protocols.

• Care2X (http://www.care2X.org/) is an integrated Hospital Information System (HIS) including an EHR. This system may be considered a significant implementation of an OSS HIS; however, the development has stopped during the last 2 years and the community seems to be inactive.

• ClearCanvas (http://www.clearcanvas.ca/dnn/) is an OSS intended particularly for viewing DICOM medical images implementing a small Picture Archiving and Communication System (PACS). It targets specifically radiology clinics and not physicians in general.

• ePostRX (http://www.anshealth.com/solutions.htm). This is an OSS e-prescription system for on-line ordering and handling of medication.

• MIRTH (http://www.mirthproject.org) is a Web based engine that allows creation of HL7 messages and can be incorporated with other EHRs.

• O3 (http://www.O3consortium.eu) is a platform for storing and retrieval of recorded biosignals and medical images.

• VistA (http://vistasoftware.org) was developed by the Department of Veterans Affairs, and supports the hospitals and clinics serving veterans throughout the US.

The above list is not exhaustive but indicative of the OSSs that currently exist in the area of electronic healthcare.

PHRs are also gaining attention recently, due to the potential benefits for patients such as better patient-provider communication, improved quality of care, reduction in unnecessary tests and medication errors, and improvements in overall health. However, adoption and utilization of PHRs are unsatisfactorily low, and that is why Google has decided to discontinue Google Health service in 2012. It seems some additional insight is needed to adjust the PHR features and functions in order to encourage PHR adoption by patients/consumers.

Another trend in the surveyed field is Mobile Electronic Health Record Systems (mEHRs) integrated into mobile devices (e.g., pocket PCs, personal data assistants [PDAs] and smart phones) [19, 20, 21, 30, 50, 51]. Such mobile applications aim at the retrieval of medical images, such as CT scans, MRIs, and ultrasound images [27]. The benefits of mEHRs for mobile care of elderly citizens are to provide seamless and consistent communication flow between home health care and primary care providers using devices like PDAs and Tablet PCs [25]. A lightweight mobile record system was utilized for managing health records integrated into an HIV treatment application developed for African health workers. Smart cards and web interfaces have been employed to store patient records electronically [27]. The MADIP system is a distributed information platform allowing wide-area health information exchange based on mobile agents [33]. Although mEHRs seem to be popular among medical personnel, their open source and open access implementations are still limited. The Google Health service has a free mobile client for the iPhone, viz. Cloud PHR. A typical implementation of OSS mEHR is the Borboleta Project (http://ccsl.ime.usp.br/borboleta/en/the-borboleta-project). The goal of the Borboleta Project is to provide home care services, through mobile computing, in order to improve health services to people with low income. Screenshots of the developed mobile application are exhibited in Figure 8. It should be noted that in general, OS mEHRs have not yet reached the maturity of their desktop counterparts.

Figure 8. Screenshots of the Borboleta OSS mobile application

The OS EHRs surveyed in this study seem to constitute reliable and efficient solutions for low cost implementation of electronic health services. Much effort has been made since their appearance to improve their usability, user friendliness, and therefore, user acceptance. However, OS EHRs need to be further improved in the following areas in order to reach the maturity and reliability levels comparable to commercial products: (i) interoperability and collaboration, (ii) security and privacy, and (iii) intelligent data analysis. These areas are discussed separately in the following section.

4. NEEDS OF IMPROVEMENT

In this section, we discuss main issues which, in our view, incommode the adoption of OS EHRs. The areas discussed below are important and require significant efforts by the communities that support OS EHR systems. Other problems such as difficulty in installation and intuitive user interfacing are considered easy to handle.

4.1. Interoperability and Collaboration with External Systems

The integration of established standards of medical data coding and exchange is not always supported in the OS EHRs covered in this study. The provision of complete electronic health care services depends significantly on the ability to build, maintain and augment interoperable systems, including different software and hardware components and systems that are required to interact to achieve the user's overall goals. Most important interoperability issues concern service and device integration. Electronic Health often involves devices, which operate in very different environments and connect together in different ways, e.g., acquisition of medical images or lab results by the corresponding infrastructure. The predominant communication protocols are DICOM and HL7, which are not fully supported by OS EHRs. Although the support of HL7 has appeared in the latest versions of OSS EHRs, the messaging and the communication with external systems are not obvious and require additional programming efforts. Furthermore, the OSS EHRs' database schemas are not always

compatible with external systems' databases (i.e., the database of a PACS in a radiology clinic, or a Laboratory Information System), and they do not always follow the incident-or episode-based architecture, which is accepted by most medical software developers.

4.2. Security and Privacy

With the exception of OpenEMR, which follows the HIPAA standards, the other OS EHRs do not incorporate appropriate security and privacy features, since they are just struggling to reduce deployment costs. However, implementing an EHR system without proper security measures can be more costly. In addition, the loss of reputation and user confidence is a great expense for an OSS [45]. According to a recent study, communication, privacy, and security requirements are accomplished by OS EHRs in less than 23 percent of the cases, mainly at minimal functional level [46]. A secure computer-based system begins by addressing the fundamentals of information security - maintaining the confidentiality, integrity and availability of all systems. A best practice security environment will be compliant with HIPAA standards. Still, the security of a computer system depends highly on the hosting organization. High security rules require administrative, technical, and physical safeguards in place. Administrative safeguards address the security management process, the assigned security responsibility, the security awareness and training, as well as contingency planning. Technical safeguards address access controls, audit controls, integrity, and person or entity authentication and transmission security. Physical safeguards address facility access control, secure installation environment, protection of devices, and media controls. A common practice for information security is a risk analysis of the environment to identify where vulnerabilities exist and the potential risks associated with them [47]. Especially, for a healthcare organization using open source software, it is essential to reduce the effects of threats and vulnerabilities to a reasonable level and to determine the cost of each administrative, technical and physical security control. Furthermore, maintenance of security is an ongoing iterative process that requires consideration of technology changes and new threats. Highly effective measures are comprehensive security awareness and training program creating a culture of security. The open source communities should pay more attention to the creation of security awareness and produce more training materials. As healthcare organizations are trying to save resources using OSS EHRs, well-designed security software and systems can give them the confidence that in the event of an incident, they will be well prepared to minimize the damages.

4.3. Intelligent Data Analysis

Another sector that OS EHRs seem to be behind commercial products is data mining and intelligent analysis. The enormous amount of data produced by computerized medical systems and stored to EHRs drive efforts to inductively manipulate, interpret and discover 'useful' knowledge from the collected data. Although decision support and assistive diagnosis are not acknowledged as primary objective of EHRs, younger and IT- (Information Technology) trained physicians like to use computer-based tools that can help with research or even medical practice. Due to the existence of multiple heterogeneous data sources, advanced data mining and fusion techniques are necessary

[48]. Hence, the current trend in modern EHRs is to incorporate data mining and intelligent analysis modules, which could assist physicians to manage large raw medical datasets in reaching a medical decision. Such tools have been already integrated into commercial electronic healthcare products; for instance, the prefetching mechanism is supported by several commercial PACS handling medical images [34]. Prefetching modules enable the access to relevant prior studies across multiple disparate PACS systems and move them to the appropriate PACS or workstation. The corresponding algorithms are based on relevant prior exams utilizing standard DICOM attributes and trigger relevant priors to be moved based on HL7 orders [35]. Similar intelligent modules have been introduced to improve medication administration [36], to monitor patients in intensive care units [37], to assist physicians in taking notes from a doctor-patient dialog [38], and to visualize and explore time-oriented data of multiple patients [39]. Also an important new feature is the integration of -omic data in EHR for enforcing translational research towards personalized medicine [40, 41].

OS EHRs seems to be behind in the above latest developments, and they are poor in this field depicting small or inexistent intelligence. The concept of archetypes, which is incorporated in the OpenEHR framework, aims at addressing such issue. Since the archetypes express clinical information requirements in 'chunks' that have the maximum value in helping the physician to reach a decision, they constitute a simple form of intelligent data mining [42]. Certainly, data mining and intelligent analysis can reach higher levels through appropriate methodologies and algorithms extracted by the corresponding scientific fields. This functionality is included in commercial EHR software in the context of "business intelligence"; however, it is neglected by open source medical software community except perhaps the OpenEHR developers.

5. DISCUSION

Overall, OS EHRs have ameliorated the enrollment of electronic healthcare in medical practice and provided optimistic perspectives to potential users with limited financial resources. The different features supported by different products suggest the basic need of interoperability among open source software, an issue of paramount importance. Through the evaluation of existing open source medical systems, it is concluded that the progress during the past several years is enormous. Although open source is a relatively new trend, most of the existing open source EHR systems are impressive. Software can conform to local custom needs and to be able to provide technical and programmer support in the local installations.

The main benefits and drawbacks of open source EHRs are summarized in Table 3, which comprises a standard Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis. A very powerful technique for analysing the strategic position of a product or a system can be developed by considering these four aspects [49]. In general, an effective strategy is to take advantage of the opportunities introduced by the product or system through its strengths, ward off or avoid threats by correcting or compensating for weaknesses.

Table 3. SWOT Analysis of open source EHRs

Strengths Weaknesses

• Reduced maintenance costs • Communities support • Shared development costs • Less vulnerability to vendor failure or product termination • Functional limitations • Lack of standards in coding medical data • Low security and privacy protection • Limited professional support • Lack of data mining and intelligent analysis tools, lack of compatible knowledge bases

Opportunities Threats

• Low acquisition and installation costs • Greater opportunity for customization and enhancements • Easily adapted products to specific requirements • Increased Costs for Early Adopters • Inferior interoperability • Low reliability • Lack of public trust especially concerning Security and privacy • Lack of support for e-prescribing and lab order processes

Besides the technical and functional limitations, there are significant policy and marketing challenges that need to be addressed before OS EHRs could be widely adopted, as summarized below:

Healthcare professionals' trust: OS EHRs have not yet gained the trust of physicians. The OS EHR market needs a vendor like the Linux providers (i.e., Ubuntu, Redhat, etc.) to undertake this task.

Awareness: Additional effort should be undertaken to raise awareness of OS EHR systems. A coordination of the efforts among various OS EHR projects for dissemination purposes seems also a prominent solution.

Duplication of software development efforts: The surveyed systems exhibit many common elements (i.e., LAMP Linux, Apache, MySQL and PHP/Perl/Python architecture); however there is no actual coordination of the development efforts among the various communities.

6. CONCLUDING REMARKS

Based on the analysis presented in this work, it appears that OS EHRs may be a viable solution for the computerization of health care, especially in developing countries where financial resources are limited. The public availability of OS EHR software may enable healthcare organizations with limited funding resources to promote customizations and enhancements that may be needed. Furthermore, the OSS model allows the sharing of development costs among health institutions with common needs and scopes in support of the corresponding developer communities. Besides cost, the introduction of OS EHRs eliminates the danger of vendor failure or product termination. Although there are clear benefits associated with adoption of OS EHRs, their penetration is still limited among electronic healthcare systems. Further developments are needed in order to reach a desired level of maturity, while raising

awareness is also important. Nevertheless, the future of OS EHRs seems to be bright and improvements will substantiate as the development and user involvement grow.

REFERENCES

[1] Menachemi N, P. R., van Durme DJ, Brooks RG. Examining the Adoption of Electronic Health Records and Personal Digital Assistants by Family Physicias in Florida. Informatics In Primary Care. 2006; 14(1): 8.

[2] Lxrum H, Karlsen T, Faxvaag A. Effects of Scanning and Eliminating Paper-based Medical Records on Hospital Physicians Clinical Work Practice. Journal of the American Medical Informatics Association. 2003; 10: 588-595.

[3] Wang S, Middleton B, Prosser LA, Bardon CG, Spurr CD, Carchidi PJ, Kittler AF, Goldszer RC, Fairchild DG, Sussman AJ, Kuperman GJ, Bates DW. A cost-benefit analysis of electronic medical records in primary care. Am J Med. 2003; 114(5):397-403

[4] Maglogiannis I, Delakouridis K, Kazatzopoulos L. Enabling collaborative medical diagnosis over the Internet via peer to peer distribution of electronic health records, Journal of Medical Systems Springer. 2006; 30(2): 107-116.

[5] Institute of Medicine. The computer-based patient record: an essential technology for health care. 1997.

[6] Shortliffe EH, Cimino JJ. Biomedical Informatics: Computer Application in Health Care and Biomedicine. 2006.

[7] National Institutes of Health/National Center for Research Resources. Electronic Health Records Overview. 2006. http://www.ncrr.nih.gov/publications/informatics/EHR.pdf

[8] Cimino JJ. Review paper: coding systems in health care. Methods Inf Med. 1996 Dec;35(4-5):273-84.

[9] Office of the National Coordinator for Health Information Technology, Department of Health and Human Services. Health information technology: initial set of standards, implementation specifications, and certification criteria for electronic health record technology. Interim final rule. Fed Regist. 2010 Jan 13;75(8):2013-47.

[10] McDonald CJ, Schadow G, Barnes M, Dexter P, Overhage JM, Mamlin B, McCoy JM. Open Source software in medical informatics—why, how and what. Int J Med Inform. 2003 Mar;69(2-3):175-84.

[11] Hogarth MA, Turner S. A study of clinically related open source software projects. AMIA Annu Symp Proc. 2005:330-4.

[12] Janamanchi B, Katsamakas E, Raghupathi W, Gao W. The state and profile of open source software projects in health and medical informatics. Int J Med Inform. 2009 Jul;78(7):457-72.

[13] Yellowlees PM, Marks SL, Hogarth M, Turner S. Standards-based, open-source electronic health record systems: a desirable future for the U.S. health industry. Telemed J E Health. 2008 Apr;14(3):284-8.

[14] Valdes I. Free and open source software in healthcare 1.0. AMIA Open Source Working Group White Paper. 2008 https://www.amia.org/files/Final-OS-WG%20White%20Paper_11_19_08_0.pdf.

[15] Doyle MJ. Open source will help drive EHR costs down. The use of open source in healthcare will break down many barriers, from high cost and lack of interoperability, to inaccessibility and complexity. Health Manag Technol. 2009 Sep; 30(9):10-1.

[16] IOM. To Err is Human: Building a Safer Health System: Institute of Medicine (IOM); 1999.

[17] Rajani N. Free as in Education. Significance of the Free/Libre and Open Source Software for Developing Countries. In FLOSS Report; 2003.

[18] Mamlin BW, Biondich PG, Wolfe BA, Fraser H, Jazayeri D, Allen C, Miranda J, Tierney WM. Cooking up an open source EMR for developing countries: OpenMRS - a recipe for successful collaboration. AMIA Annu Symp Proc. 2006:529-33.

[19] Mohammed-Rajput NA, Smith DC, Mamlin B, Biondich P, Doebbeling BN. Open MRS Collaborative Investigators. Proc of AMIA Annual Symposium 2011; 2011:960-8

[20] Allen C, Jazayeri D, Miranda J, Biondich PG, Mamlin BW, Wolfe BA, Seebregts C, Lesh N, Tierney WM, Fraser HS. Experience in implementing the OpenMRS medical record system to support HIV treatment in Rwanda. Stud Health Technol Inform. 2007; 129(Pt 1):382-6.

[21] Seebregts CJ, Mamlin BW, Biondich PG, Fraser HS, Wolfe BA, Jazayeri D, Allen C, Miranda J, Baker E, Musinguzi N, Kayiwa D, Fourie C, Lesh N, Kanter A, Yiannoutsos CT, Bailey C; OpenMRS Implementers Network. The OpenMRS Implementers Network. Int J Med Inform. 2009 Nov;78(11):711-20.

[22] Tierney WM, Achieng M, Baker E, Bell A, Biondich P, Braitstein P, Kayiwa D, Kimaiyo S, Mamlin

B, McKown B, Musinguzi N, Nyandiko W, Rotich J, Sidle J, Siika A, Were M, Wolfe B, Wools-Kaloustian K, Yeung A, Yiannoutsos C; Tanzania-Uganda Openmrs Consortium. Experience implementing electronic health records in three East African countries. Stud Health Technol Inform. 2010; 160(Pt 1):371-5.

[23] Seebregts CJ, Mamlin BW, Biondich PG, Fraser HS, Wolfe BA, Jazayeri D, Miranda J, Blaya J, Sinha

C, Bailey CT, Kanter AS. Human Factors for Capacity Building. Lessons learned from the OpenMRS Implementers Network. Yearb Med Inform. 2010; 13-20.

[24] Y. Lin, I. Jan, P. Ko, Y. Chen, J. Wong, and G. Jan, 'A Wireless PDA-Based Physiological Monitoring System for Patient Transport', IEEE Trans. Inform. Technol. Biomed., Vol. 8, no. 4, Dec. 2004; 439-447.

[25] Fischer S, Stewart TE, Mehta S,Wax R, and Lapinsky SE, "Handheld computing in medicine" J.

Amer. Med. Inform. Assoc. 2003; 10(2):139-149.

[26] Maglogiannis I, Apostolopoulos N, Tsoukias. Designing and Implementing an Electronic Health Record for Personal Digital Assistants (PDA's)" International Journal for Quality of Life Research. 2004; 2(1):63-67.

[27] Andrade R, Wangenheim A and Kessler Bortoluzzi M. Wireless and PDA: a novel strategy to access DICOM compliant medical data on mobile devices. International Journal of Medical Informatics. 2003; 71:157-163.

[28] Jimena Rodriguez, Alfredo Goni, and Arantza Illarramendi. Real-Time Classification of ECGs on a PDA. IEEE Transactions On Information Technology In Biomedicine. 2005; 9(1) 23-34.

[29] Bojovic M and Bojic M. MobilePDR: A Mobile Medical Information System Featuring Update via Internet', IEEE Transactions On Information Technology In Biomedicine. 2005; 9(1):1-3.

[30] Koch S, Hägglund S, Scandurra I, Moström D. Towards a virtual health record for mobile home care of elderly citizens. MEDINFO 2004, Amsterdam. 2004; 960 - 963.

[31] Kumar A., Purandare A., Chen J., Meacham A., and Subramanian, L. 2009. ELMR: lightweight mobile health records. In Proceedings of the 35th SIGMOD International Conference on Management of Data. 2009; 1035 - 1037.

[32] Alvin T.S. Chan. WWW_smart card: towards a mobile health care management system. International Journal of Medical Informatics. 2000; 57:127-137.

[33] Chuan Jun Su. Mobile multi-agent based, distributed information platform (MADIP) for wide-area e-health monitoring. Computers in Industry. 2008; 59:55-68.

[34] H. K. Huang. PACS and Imaging Informatics: Basic Principles and Applications. John Wiley and Sons, 2010

[35] Weathermon A, Tsui J, Rohling R. iScout: an intelligent scout for accessing and navigating large image sets in a PACS. J Digit Imaging. 2004 Jun;17(2):109-19.

[36] Prusch AE, Suess TM, Paoletti RD, Olin ST, Watts SD. Integrating technology to improve medication administration. Am J Health Syst Pharm. 2011 May 1; 68(9):835-42.

[37] Saeed M, Villarroel M, Reisner AT, Clifford G, Lehman LW, Moody G, Heldt T, Kyaw TH, Moody B, Mark RG. Multiparameter Intelligent Monitoring in Intensive Care II: a public-access intensive care unit database. Crit Care Med. 2011 May; 39(5):952-60.

[38] Klann JG, Szolovits P. An intelligent listening framework for capturing encounter notes from a doctor-patient dialog. BMC Med Inform Decis Mak. 2009 Nov 3; 9 Suppl 1:S3.

[39] Klimov D, Shahar Y, Taieb-Maimon M. Intelligent visualization and exploration of time-oriented data of multiple patients. Artif Intell Med. 2010 May; 49(1):11-31.

[40] Lowe HJ, Ferris TA, Hernandez PM, Weber SC. STRIDE—An integrated standards-based transla-tional research informatics platform. AMIA Annu Symp Proc. 2009 Nov 14; 2009:391-5.

[41] Murphy SN, Weber G, Mendis M, Gainer V, Chueh HC, Churchill S, Kohane I. Serving the enterprise and beyond with informatics for integrating biology and the bedside (i2b2). J Am Med Inform Assoc. 2010 Mar-Apr; 17(2):124-30.

[42] Duftschmid G, Wrba T, Rinner C. Extraction of standardized archetyped data from Electronic Health Record systems based on the Entity-Attribute-Value Model. Int J Med Inform. 2010 Aug; 79(8):585-97.

[43] Hameed K. The application of mobile computing and technology to health care services. Telematics and Informatics 20. 2003; 99-106.

[44] Mendonça E, Chen E, Stetson P, McKnight L, Cimino J. Approach to mobile information and communication for health care. International Journal of Medical Informatics. 2004; 73:631—638.

[45] Maglogiannis I, Kazatzopoulos L, Delakouridis K., and Hadjiefthymiades S. Enabling Location Privacy and Medical Data Encryption in Patient Telemonitoring Systems. IEEE Transactions on Information Technology in Biomedicine. 2009; 13(6):946-954.

[46] Flores Zuniga AE, Win KT, Susilo W. Functionalities of free and open electronic health record systems. Int J Technol Assess Health Care. 2010 Oct; 26(4):382-9.

[47] Maglogiannis I, Zafiropoulos E, Platis A, Lambrinoudakis C. Risk Analysis of a Patient Monitoring System Using Bayesian Network Modelling. Journal of Biomedical Informatics. 2006; 39(6):637-647.

[48] Maglogiannis I. Introducing Intelligence in Electronic Healthcare Systems: State of the Art and Future Trends", AI an International Perspective Lecture Notes in Artificial Intelligence. 2009: 5640.

[49] Rowe M, Dickel M, Mockler M. Strategic Management: a methodological approach. 4th Edition, 1994. Addison-Wesley. Reading Mass.

[50] Gurkan D and Merchant F. Interoperable Medical Instrument Networking and Access System with Security Considerations for Critical Care Journal of Healthcare Engineering. 2010; 1(4):637-654.

[51] Ara A. Salibian and Thomas Scholz. Smartphones in Surgery/ Journal of Healthcare Engineering. 2011; 2(4):473-486.