Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Some of the challenges that healthcare systems are facing are: increasing costs[1, 2], poor quality of service, lack of patient care integration, poor access to patient care information and a high number of medical errors [2].

The use of Health Information Technology (HIT) is expected to have a positive impact on cost reduction by reducing medical errors, increasing quality of care and [2] increasing patient mobility. Several countries such as Australia, Canada, the U.S. and many EU countries are currently investing in HIT initiatives [1, 3, 4].

In Canada for instance, the national infostructure project had received 1.2B Canadian dollars to advance Electronic Health Records (EHR) and tele-health systems [5], and the Obama administration has spent $19B in stimulus support for EHR systems [6], which aim at reducing the estimated number of 98,000 deaths and the number of injuries from medical errors [6].

The Electronic Health Records are at the centre of the HIT initiatives [1, 3, 7], a thing which becomes more apparent by the presence of an EHR project in most of the EU countries’ strategic plan [4], and the fact that national implementations of EHR are internationally pursued [8].

Successful EHR implementations could lead to increased efficiency of the healthcare delivery process, improved patient information collection, speed up administrative processes, improve working conditions and, along with user acceptance, the outcomes will be improved safety, efficiency and quality of healthcare [9].

However, EHR systems are a complex topic. There is no nationally interoperable system yet, or a standard approach to realise their benefits [8]. As [1] plays on words, he points out that EHR can also stand for “Exceptional Hidden Risks” as the cost of implementing those systems, which is quite high to begin with, rose higher than initially expected in some cases. Examples are Australia where it started from AU$500 M and rose to AU$2B, the UK where it started from £2.6B and rose to more than £15B, and the U.S. where the estimate was between $100B and $150B in implementation costs and a $50B/year in operation costs [1]. Those are 2006 figures.

The paper starts with a review of the EHR system literature. In doing so an overview of EHR systems is presented, aiming at examining if an open source software process would be suitable for the implementation of an EHR system at a large scale such as the national or, when applicable, the continental level. For instance, there has been an increased interest in European Union for the construction of a common European system of EHR and harmonisation of different countries EHR systems. Furthermore, we want to find out which problems, found in current EHR implementation efforts, could possibly be alleviated with the use of an open source software development process.

2 The Term EHR: Environment and Stakeholders

Before tackling the issue at hand, it is necessary to examine how our main topic of interest, the EHR, is defined.

According to the International Organization for Standardization (ISO) definition, the EHR is a repository of patient data in digital form which is stored and exchanged securely, and is accessible by multiple authorised users [10]. The term EHR covers a wide range of information systems from department specific to comprehensive medical records [10]. The term EHR has been used interchangeably with the term EMR to describe either local health record systems, or interoperable health record systems both in research and practice [11].

In [12] a compact taxonomy is given. The categories of EHR systems are classified as (i) local EHR systems; (ii) shared EHR systems; (iii) Personal Health Records (PHR), and (iv) Public Health EHR.

A local EHR system refers to a local system which has the detailed information for the local patients collected over the course of encounters with the patient [12].

A shared EHR system refers to a system whose purpose is to facilitate and record integrated and shared lifetime care to the patient in a group of diverse health service providers [12].

A PHR refers to systems allowing the patient to be in control of his/her record, and has some differences over the systems previously described [12].

A Public Health EHR refers to aggregated de-identified data which are used for public health, epidemiological purposes, research, policy development, health statistics and health service management and can be a obtained from an EHR or created from various sources [12].

The shared EHR systems are the ones that are pursued internationally and usually the prerequisite to such an implementation is the wide use of local EHR systems. In this paper we will look at them in this combined fashion as two closely related parts. Different architectures may be used but both types of systems are necessary for exchanging medical records at the national or higher level. For more on those terms the reader can look in [12] and for examples of some architectures can look in [3] and [13].

3 EHR Implementations: The Current Impact

For nearly 20 years, EHR systems were expected to solve all the major problems of healthcare systems [14]. If the problems in healthcare were strictly technical issues, they might have been solved by introducing an EHR system. The expectations were certainly high but which has been the impact of EHR systems so far?

3.1 User Considerations

The physicians consider as important aspects of an EHR the following: improving quality of care, supporting direct contact with a patient, improving collaboration with colleagues, all of which will allow them to “just be good doctors” [14], as well as privacy [15] and security [5]. It is very important to mention that collaboration with colleagues also refers to colleagues working in a different organisation [14]. All these factors relate to allowing the physicians to improve their work process, the healthcare delivery process, and its outcomes.

A study mentioned in [14], which included other end-users besides physicians, found the next as the most important aspects: availability of the system, reduction of administrative work, providing information for research and management and allowing the uniformity of working processes. We would like at this point to note that availability as a term is confusing in the cited paper, as it is a term mentioned by physicians and not by software professionals. We take availability in this context to be the same as system reliability and information availability. Considering that, when asked whether they would prefer “reliability or availability” of the EHR, the physicians answered availability of the EHR. We base this assumption on the authors’ statement “Reliability can sometimes be seen as the opposite of availability” [14], which would be correct if we are talking about information availability and reliability, where under circumstances a reduction of one side results in increase in the other; but as far as system quality is concerned, a reliable system is one which is available and performs as expected under certain conditions. Therefore, we cannot see how it can be that “Reliability can sometimes be seen as the opposite of availability” [14]. Our assumption on this factor is backed up by [16], where reliability was taken for granted as a case when the system was down for seven days is mentioned and the doctors had to input all the data gathered during the down period after the system was operating again.

Nonetheless, the improvement in the work process and its outcomes seems to be the fundamental requirement that the users have from an EHR system, which would explain why when users with different roles in the healthcare delivery process are included, different factors rank higher.

3.2 Usability: Beyond Human Computer Interaction

Existing EHR usability is rather poor [8, 14, 17] and a number of usability flaws have been reported [17] that back this up.

The importance of usability is mentioned in [15], as one of the studies reviewed there, found a strong correlation between user satisfaction from HIT and the ability of the system to do things in a simple way (‘straightforward manner’) and in [13] the user interface is mentioned as a critical factor for EHR success.

More specifically, in [14] it is mentioned that, while time and effort can be saved because the EHR makes searching for data and generating letters easier, it is argued that these effects are helpful for administrative personnel but the opposite holds true for physicians who experience a period of lowered consultation times while learning how to use the EHR. This period lasts from half to one year usually [14].

Usability though, goes beyond human computer interaction as it is carefully elaborated in [17]. The authors there argue that, applications have to be considered as integrated parts of a technological environment and usability should be described in the specific context while taking into account the use of the systems during the user’s work process in order to complete tasks and achieve certain goals. In this approach they measure usability using three dimensions : (1) Compatibility between clinical ICT systems and physicians’ tasks (2) ICT support for information exchange, communication and collaboration in clinical work, and (3) interoperability and reliability. The study was done in Finland and the findings were quite interesting.

The physicians gave relatively low ratings to the EHR systems. Half think that their EHR does not support decision-making and does not provide help with medical error prevention. About half expect better support for routine tasks, and 62 % think that the systems hinder their work by requiring a fixed sequence of steps, even though they had positive opinions on the interfaces of the system [17].

The physicians also consider information accessibility a problem. An 85 % disagrees with the statement that it is easy to access medical information from other healthcare organisations, as it takes too much time to exchange information. Collaboration between physicians in the same organisation is supported, but collaboration between them and the nurses, them and the patients, them and other physicians in distant locations is not supported. The collaboration with the patient not only is not supported, but is also hindered [17].

The findings of [17] that were also supported by other literature sources, as is mentioned there, are problems in data entry, inadequate integration between EHR and other systems. Hospital physicians were more critical towards the EHR systems, indicating the poor suitability of the current systems for hospital settings. On the other hand private providers, which in Finland are mostly clinics dealing with specialised areas, had a better opinion of their systems [17].

3.3 Interoperability

Interoperability between two systems exists when in regard to a certain task one can receive data from the other and perform that task in an appropriate and satisfactory manner without the need for another operators intervention [18].

Considering the central role of the EHR in HIT, as a system which all other HIT systems have to interact with, the importance of EHR system interoperability with other Health Information Systems (HIS) is increased. Interoperability between different EHR systems allows sharing of patient information, it therefore enables patient mobility. Interoperability is also an important property, which is necessary to increase collaboration between physicians from different healthcare organisations and, thus, increases the usability of the HIS as mentioned in the previous section. These two aspects make interoperability a very important quality property of EHR systems.

3.3.1 Interoperability and Standards

At this point health information is stored in different kinds of proprietary formats in different health information systems, which results in severe interoperability problems [18].

For this reason a number of standards have been proposed in order to provide a remedy solution to this problem. Some of the standards are XDS, HL7 version 3, openEHR and EHRcom. Most EHR standards are currently evolving and there is a trend of harmonising and unifying previous EHR developments [18].

Conformance to one of the standards or to a combination of them will not solve the interoperability problem according to [18] as the authors argue that it does not seem realistic that all the healthcare institutes will reach a consensus on using the same standards. If, however, a large number of organisations use the same data format and agree on an exchange protocol, there seems to be no reason why their systems cannot be interoperable. This seems to be the idea behind XDS where the communicating parties agree on document format, structure and content before exchange [18].

The issue of conformance to standards seems to be more related to the HIS development industry rather than healthcare organisations and this is backed by the opinion expressed in [13] where interoperability problems are attributed to a few systems complying with standards. The issue of interoperability came up quite often during this research work. The issue of achieving interoperability at a large scale seems feasible from a technical perspective, but is also affected by political and competitive issues [11].

3.3.2 Financial Impacts of Interoperability

An example of the financial importance of interoperability at a large-scale and for developed economies can be found in [11], where it is stated that the most cited study on EHR benefits was a RAND study in the U.S. which predicted that increased efficiency and safety will result in savings of an average of more than $77 billion per year when 90 % adoption rate was achieved with an average of $42 billion per year during the adoption period, figures which can be doubled if chronic diseases were managed and providers with consumers participated.

However it is also mentioned there that the study predicted those amounts by assuming a level of interoperability which highly exceeded the level of interoperability possible at the time.

3.3.3 Interoperability and Customisation for Local Needs

Standards have to be considered for large-scale interoperability but, there is also an issue of leaving room for customisation in order to fit the specific context [8]. The overall impression from the references used in this paper is that “room for customisation” is a somewhat vague term that has to be more specific in the sense that while intuitively a generic EHR system would not be suitable for the diversity of medical users and clinical practices, there could still be norms that would define the relationship between interoperability considerations and space for customisation in a more specific manner allowing some sort of classification of system characteristics.

4 Social Aspects of EHR Implementation

It should be evident by now that the implementation of an EHR system is by no means a strictly technical issue.

In different countries, healthcare delivery is organised in a different manner, it might be mainly public or mainly private. Typically, health services are divided in primary, secondary and tertiary care [10].

Primary care is provided in the community by general practitioners, secondary care is provided by a specialist facility after referral and tertiary care is provided by a team of specialists in a hospital [10].

In order to understand how beneficial the EHR is, we have to understand how it will affect the interactions that happen at multiple levels. The idea of understanding the information exchange interactions and the value they generate, at multiple levels is found in [11], where at the first level are the interactions within the same organisation, at the second are those between individual practitioners and hospitals, and at the third one are those between regional and competitive health networks. Either one agrees or not with the defined levels, it certainly touches an important aspect, that EHR systems have different effects, at different organisational levels.

Moreover, the work process of healthcare delivery is viewed as a complex system, which is a collection of people and tools interacting in a complicated manner [15] and the issue of implementation is connected to social and economic aspects [1]. The shortcomings of the current national EHR implementations are attributed to the negligence of those aspects, and the underlying organisational and human factors have to be taken into account [9].

As far as support for working processes goes, many EHR systems do not fit naturally in the work process [19]. Effects of EHR on quality of care are dependent on the characteristics of the EHR and its impact on the work process [9]. The opinion expressed in [11] is that realising the full value of HIT will require the creation of new work processes where technology is used naturally (the word embedded is used), it has shared acceptance, resulting in new capabilities, new structures and changes in relationships and culture. This is backed by the fact that benefits have been achieved in small scales where the systems were customised to fit the local context and the main challenges were embedding them in the clinical and organisational process [8].

The introduction of EHR into the workplace has the potential to change roles and processes, it also has the potential to have positive and negative effects on quality of working life [9]. The potential adverse effects may include usability deficiencies which increase frustration [9] or possibly increased intensity of work.

Understanding the dynamics of this change process becomes very important when examining things from this point of view. Without covering this in detail we will mention some factors.

We can say that the compatibility of the technology with the aims of the professionals is such a factor, as for example in [14] the physicians resorted to using paper, which offered a quicker working process thus allowing them to have more time, something they considered they were lacking. Without facing the underlying issue which is lack of time, the introduction of an EHR whose Usability was inferior to that of the paper record keeping, forced them in a certain sense to revert to the use of paper.

Financial and time saving incentives of the use of EHR may affect it positively [20] but this should also take into account different needs for the management and the healthcare personnel.

The management becomes crucial as it has the ability to empower the personnel by encouraging participation and involvement in the change process, which along with willingness to change are important adoption factors [20]. An important thing to note here is that participation is defined as the set of activities and behaviours performed by the users in the implementation process while involvement refers to a subjective norm [20].

However the process of adoption requires time and effort and some adverse effects are unavoidable, since the healthcare personnel will have to learn new skills and adapt to new processes [2] before being able to start optimising them.

In order for the EHR systems to have a transformative effect, those factors and many, which is not possible to cover here, have to be examined. The crucial aspects though are allowing information exchange in large areas in order to enable patient care integration, and supporting the working practices of the medical personnel [9].

5 Open Source Development as a Possible Change Catalyst

In this chapter we present some indications showing that considering and open source development model for large-scale EHR implementation could be beneficial.

5.1 Defining Open Source Software Development

First we have to start by defining open source. A software system can be said to be free and open source when a person has access to its source code, is free to use it, copy it and redistribute it, modify it and distribute the modified versions [21]. There is a variety of licenses (http://opensource.org/licenses/category), ranging from more permissive to more restrictive but they are considered open source as long as they conform to the freedoms mentioned [21].

The development follows a circular process and starts when the source code is made available online. When a contribution is made, a new version is produced, afterwards a testing period follows where bug reports are submitted by the users and fixed by the developers of the community, something which goes on until the version becomes stable. At that point the process starts again with a new contribution [21].

Besides this basic development pattern there is a lot of diversity among open source communities. There are differences to what motivates the community members to contribute, the way that project decisions are made and the main moving force in the project which may be a single person, a community, a company or members of the academia [22].

5.2 Motivational Factors in Open Source Software Development

Except users and sponsors, another stakeholders category that should be taken into consideration while adopting a software development process model is that of the various software developers [23]. Their knowledge, conditions of work and motivation are significant factors in the development of successful and socially acceptable software. EHR implementation, for instance, with or without open source software, leads to social software systems. This indicates the needs for high quality and shared conceptualization. These can lead to social acceptance of electronic health records. Social acceptance is considered an important part of any software system by the authors of this paper. Primarily, a systems development model is as strong as the user involvement it supports [24], in many phases of the development. For instance, this user involvement can clearly be evidenced by the system’s use or avoidance, which, in turn, will also determine the degree of the system’s maintainability. Thus, we must, next, examine motivational and other factors for software developers in open source software development methodology, with references to countries with developing or/and developed economies.

Open source can have an effect on developing economies because open source software can be used as a source of software knowledge that could be used by local companies and technology professionals, serving as a motivational factor for involvement [22].

A number of studies indicates that open source software developers are driven by peer recognition, the desire to be part of a community and internal motivation deriving from the creativity felt during the development.

However, there is an increasing number of developers who are paid to work on open source software. A survey mentioned in [22] states that “the majority” of developers involved in open source software are paid for it. Motivations are usually monetary gains, technical benefits, skill-acquisition and employment prospects especially for individual developers [22]. The increasing number of individual software application developers that are interested in this development shows that funding is necessary in some projects.

This is of great importance as it shows that open source projects can be funded directly by various organizations. The fact that they remain open can allow for the fruitful participation of different stakeholders from private companies to academic researchers and governments, while avoiding e.g. lock-ins and interoperability issues.

5.3 What Could an Open Source Software Process Offer?

The quality of open source was assessed in [21] using the ISO 9126 quality model and the authors concluded that while in some areas open source software, or more specifically free and open source software (FOSS), seems to do better than proprietary software there is room for improvement. For instance, FOSS tends to be more effective for projects where incremental change is rewarded, something that makes it more suitable for back-end development [21].

The open source movement has a commitment to implementing standards that promote functionality and interoperability, and are publicly available and royalty-free [21]. In fact open source seems to do better in projects with well defined requirements [21].

Implementation of functionality and interoperability standards has led to cases where useful feedback indicating errors in the standard was given by a project, something which helped improve the standard [21] and it is also supported that open source might lead to faster adoption of standards [21].

Open source software is reliable due to the quick rate of bug-fixing [21], something that comes as a consequence of having a high number of beta testers, who test the software in operational mode [21].

Availability of the source code allows peer review which, as results show, can lead to better security in the long term [21] although there is some controversy around that. It is stated that while availability of the source code allows it to be reviewed by contributors it also allows malicious users to find flaws which they can later exploit or they can redistribute their version of the software [25].

As far as Usability in open source is concerned the authors find that special attention is necessary at the point when the project idea is conceived [21].

Another aspect which is important is the philosophy of openness and community that is present in open source. By providing tools that facilitate communication in the medical community, this openness could potentially provide research materials about the shortcomings and strengths of the current HIT implementations, and allow professionals to share positive and negative experiences with HIT while at the same time empowering them to participate in the evolution of their HIT work tools.

5.4 Indications of Potential Benefits of Open Source

EHR implementation is considered an evolutionary process where professionals that don’t use an EHR are not going to easily adopt an EHR with advanced functionality [14], something which falls in line with sophistication levels of HIT implementations presented by one of the studies reviewed in [15] where level 0 was no active electronic medical record. Also it is suggested that the process should start small and built from that [8, 13]. The early adopters with the most sophisticated systems or the HIT leaders as [15] calls them, have followed this process of developing their systems in-house over the years by local “champions” in an evolving process of evaluating the system and adapting it.

This would be the most effective way to develop such systems, if of course the benefits of this type of context based development, can be replicated at a larger scale by an open source development model, since open source follows this evolutionary process. This certainly isn’t applicable for each and every one of the involved healthcare organisations but it would be applicable if healthcare organisations taking part in such an initiative would be grouped into organisations offering the same or very similar healthcare services. Open source development would then function as a platform for user involvement, which along with this evolutionary development process would allow the users to exchange experiences, suggest modifications to the EHR system and also be encouraged to suggest new work processes based on the capabilities enabled by the EHR.

In [13] the authors state that populating and using an EHR is very much the same, regardless the country which could enable possible funding of such an initiative by a number of countries that could benefit from this effort, or make the lessons from an effort like this generalisable.

Implementation of EHR standards in such a process could facilitate the harmonisation of the various standards, something that has already begun to some extent as previously described, and the openness could create an interesting interplay between standards development and the evolution of the system itself while enabling the achievement of a much higher degree of interoperability than the one possible now.

The availability of the code has other benefits as well. Some of these are building local capabilities in developing countries [22], building the capabilities of the health informatics workforce, it can allow the academic research from various related fields to influence implementation practice. At the same time, saving funding from licence fees while avoiding vendor lock-ins would be possible, but this has its risks if the project is not build around a community.

Another remarkable finding is in [14], where it is mentioned that 60 % of the market in the Netherlands at the time was in the hands of two suppliers, with systems that did not provide decision support and had a poor user interface. This high amount of concentration shows, at least to a certain extent, a high degree of shared conceptualization, which could be useful as a starting point in a transition to open source implementation, since open source software development has achieved much in applications with well-defined requirements [21] and the most robust community-based projects have a high degree of conceptualisation [22]. The poor results of those systems, are both an incentive to consider open source initiatives and the high degree of conceptualisation can be the starting point for the requirements, if the picture is the same in other countries as well.

Finally, by providing a high quality system for free would allow cost, one of the most frequent adoption barriers [15], to be overcome. A word of caution though is necessary at this point because even though the system could be free and wouldn’t require licensing costs there is still the cost of support and training which should be examined.

5.5 Points to Consider

Although there are some interesting indications about some potential benefits of considering such a development model, its feasibility has to be closely examined. Issues such as licensing and transition strategies from closed source, involving compatibility with a number of legacy systems in use, and the community building process which would make this effort sustainable, would have to be considered.

A number of business models used in open source software would have to be examined in order to encourage companies to offer services and their expertise by becoming members of the community. The information found in [26] can be quite useful to finding some realistic possibilities. User training, installation, maintenance, establishment of backup and disaster recovery processes and procedures, on-site training tailored to users’ needs are good candidates for business models [26]. Permissive license on the core of the system could be tricky as it could lead to replicating the current problem of the variety of proprietary formats being used.

The model has to be tailored to cater for Usability which is a crucial quality aspect as we presented in this paper.

A governance model has to be considered which should attempt to create the “local champion” effect and also take into account that there has to be a balance between user involvement and the core team making the decisions [15, 19] with the process itself having an evaluation framework built in [19] and at a large scale as the one we are considering, this is by no means a trivial task.

Another important consideration of the governance model is the quality assurance of new versions. Simply installing them frequently upon release, not only is not realistic in a healthcare organisation setting, but expecting it to be tested in operation to find the errors would be completely reckless and unacceptable in such safety-critical systems.

The final point to consider is the need for government funding in this effort and a strategic plan over a period of time. Government funding has been found necessary [5, 27]. If the various aspects of a source model suitable for this context are examined in more detail, clarified and shown to be potentially effective, the large amount of financial resources that countries have already spent or have offered as incentives to medical professionals to purchase proprietary software could be a reason to invest in developing high quality open source systems.

6 Closing Remarks and Future Work

In this work we provided some information about the necessity that drives HIT implementation, the central role of EHR systems in these efforts, we gave a definition of the term EHR and provided a picture of the current implementation landscape of EHR systems. The last part of this paper consisted of some indications of potential benefits of considering an open source software process model tailored to this context for large scale implementation, while also considering the challenges that such an endeavour would have.

Concluding, we can argue that healthcare software development is very complex by its nature and it involves technical, economical, social and political aspects. Further research is needed in order to identify and interconnect them and see how an open software development model that is holistic with respect to different stakeholders needs, realistic as to EHR requirements implementation and customisable for different healthcare application domains.

Future work has to develop a more complete understanding of EHR systems and build on the Sects. 5.4 and 5.5 and if possible provide an open source development process model for this case.