Sage Journals: Discover world-class research

Abstract

The introduction of electronic health records (EHRs) lies at the heart of many international efforts to improve the safety and quality of healthcare. England has attempted to introduce nationally procured EHR software—the first country in the world to do so. In this qualitative comparative case study tracing local developments over time we sought to generate a detailed picture of the implementation landscape characterising this first attempt at implementing nationally procured software through studying three purposefully selected hospitals. Despite differences in relation to demographic considerations and local implementation strategies, implementing hospitals faced similar technical and political challenges. These were coped with differently by the various organisations and individual stakeholders, their responses being shaped by contextual contingencies. We conclude that national implementation efforts need to allow effective technology adoption to occur locally before considering larger-scale interoperability. This should involve the allocation of sufficient time for individual users and organisations to adjust to the complex changes that often accompany such service re-design initiatives.

Keywords

Electronic health records implementation sociotechnical

Introduction

Internationally, there is increasing interest in the potential of information technology (IT) to enhance the safety, quality and efficiency of healthcare.^{1, 2} The implementation of electronic health records (EHRs) is at the heart of many of these initiatives.³ Among the many anticipated benefits of EHRs are improved communication between different healthcare providers, better availability of information, reduction in medical errors, improved organisational functioning and more streamlined work practices; although there is, at present, relatively little robust evidence indicating that these hoped-for benefits are currently being realised.³

Many countries are now investing substantial sums of money as they seek to achieve large-scale EHR implementation. Strategies to achieve interoperability between different systems and settings vary, but can be divided conceptually into ‘top-down’, ‘bottom-up’ and ‘middle-out’ approaches.^{4, 5} For example, England has embarked on a ‘top-down’ implementation of EHRs, characterised by large-scale government-led procurement of three commercial systems that individual hospitals have been strongly encouraged to implement.^6

–10 In contrast, the USA has adopted a ‘bottom-up’ implementation approach, where ‘meaningful use’ goals relating to EHRs have been centrally decided by a government agency, but where hospitals have considerable choice in how these goals are achieved.^{5, 11, 12} Australia has adopted a more ‘middle-out’ approach, including elements of both national guidance and local choice.^{5, 13}

Many challenges accompanying the introduction of new technology result from the necessary changes to, and transformations of, established organisational processes and individual practices.^{2, 14

–18} There is, therefore, a real danger that systems that are not perceived as being fit-for-purpose are rejected or used in different ways to what was originally intended. In line with this, one of the key findings to emerge from the still relatively limited number of published accounts is that implementations characterised by substantial user involvement in design tend to be more ‘successful’ than those with less user involvement.^19

–23 Such approaches are, however, extremely time-consuming, often involving several rounds of iterative software development. Hence, they are difficult to replicate in the context of the scaled-up national implementation efforts that are now underway in many parts of the world.

A range of additional factors have been identified as playing a potentially important role in facilitating EHR implementation and adoption.^{3, 20, 24

–74} Yet, these are often viewed in isolation, focussing on either technical, social, organisational or environmental issues. In the light of these known and repeatedly encountered problems—even in the context of relatively small-scale implementations—it is imperative that lessons from ongoing international implementation efforts are learned.

As noted above, the English venture involved the national procurement of three EHR systems to be implemented by hospitals. One of these was Software X (the focus of this article), the first ever nationally procured EHR system to be built while it was being implemented. The reasoning behind this approach was that it could be developed in close collaboration with the healthcare professionals who would be using the software. Here, we report on a sub-study of a large-scale evaluation of the national implementation of EHRs in hospitals.^{75, 76} Our results are based on three purposefully selected secondary and community hospitals implementing initial functionality of Software X. Our aim was to explore early views and experiences of users and understand the consequences of the system for work practices, as well as general organisational functioning. Drawing on these experiences and insights, we sought to generate a detailed picture of the implementation landscape characterising this unique attempt to implement and adopt a nationally procured software that was co-developed by users.

Methods

Ethical statement

The observational component of this study received ethical approval from the East London and the City Research Ethics Committee on 2 April 2009. The interview component was submitted for ethical review to the same ethics committee but was classed as a service evaluation on 9 October 2008 (08/H0703/112). To protect the anonymity of participants and hospitals, we have removed potential identifiers wherever possible.

Design

This qualitative study was informed by sociotechnical approaches to studying the implementation of IT systems in healthcare.^{25, 57, 68, 77} These highlight the importance of investigating not only the consequences of the technology for the organisation, but also the consequences of the social setting for technical considerations, and the complex inter-relationship between the two.^78–81 We conceptualised hospitals as case study sites and used a multi-sited ethnography approach, which was designed to provide insights into the wider social system by including a range of relevant stakeholders from outside of the case study sites.^82

–86 In keeping with ‘traditional ethnography’, which is characterised by the in-depth exploration of a particular setting, multi-sited ethnography employs similar data collection methods (i.e. observations, interviews and collection of associated material), but it is, however, characterised by greater breadth of enquiry (at the expense of depth that defines the traditional ethnographic approach).^82

–86 In the context of this study, we envisaged that drawing on data from different settings would help us to understand the nature of a particular phenomenon of interest from a wider range of viewpoints.

Sampling

Sampling of cases/sites and informants was purposeful. Three hospitals were selected as being amongst the first in England to implement the nationally procured Software X, while having different demographics and characteristics (see Table 1). These hospitals may be viewed as critical cases as they were all among the first to face the introduction of Software X.^{87, 88} These organisations implemented early limited functionality of Software X, including patient management and some clinical software modules during the data collection period. This functionality represented one (in Sites B and C) and two (in Site A) of four consecutive software releases on the way to having a fully integrated EHR (see Table 2). Deployments of these modules were small-scale (with Release 1) and large-scale (with Release 2 building on Release 1).

Table 1.

Characteristics of recruited hospitals

Site	Type of hospital	Teaching status	Foundation status (indicating the level of autonomy)	Location	Number of beds	Approximate annual turnover
A	Acute	Non-teaching	Foundation (i.e. more autonomous)	Rural	1021 beds	£231m
B	Community	Non-teaching	Non-Foundation (i.e. less autonomous)	Urban	N/A	£152m
C	Mental Health	Non-teaching	Foundation (i.e. more autonomous)	Rural	Mostly outpatients but 359 inpatient beds	£97m

Table 2.

Software X functionality implemented in case study sites

	Functionality implemented
Site A	Release 1: requests and results functionality including radiology, endoscopy, pathology; and limited clinical documentation; implemented across two wardsRelease 2: Patient Administration System replacement; implemented across the hospital
Site B	Release 1: clinical documentation functionality supporting recording and maintaining medical histories, clinical notes, care events, demographic details, and task management; implemented in one specialist service
Site C	Release 1: clinical documentation functionality, including risk indicator assessment forms, progress notes, request forms, electronic discharge summaries, order communications for pathology; implemented in one specialist service

In line with the multi-sited ethnographic approach and informed by sociotechnical principles, a wide range of stakeholders within hospitals were sampled over the course of the study. This involved approaching the Head/Director of IT as the main local contact initially and then, through snowball sampling, recruiting further participants within the hospitals, including healthcare professionals (nurses, doctors, allied health professions), implementation team members (e.g. managers, clinical leads) and administrative staff. In doing so, the researcher (KC) essentially sampled stakeholders related to Software X within the organisations (the case study sites) and beyond, seeking to understand a varied range of different experiences and attitudes. Outside the case study sites and based on the recommendations of existing interviewees, a range of additional stakeholders outside the immediate hospital environment were sampled. These included developers, governmental stakeholders, representatives from the independent sector and the media. For example, if the researcher started at a ward speaking to users who mentioned a particular implementation team member, that person’s perspective was actively sought. If this implementation team member mentioned another stakeholder, such as developers or politician, they were approached in turn.

Data collection

Data were collected between February 2009 and November 2010 by KC (an academic psychologist). This involved a combination of face-to-face/telephone interviews and observational fieldwork. In addition, a variety of relevant documents were collected. Throughout the study, a conscious effort was made to feed back emerging findings into subsequent data collection activities.

Interviews were semi-structured one-to-one (in some cases one-to-two) discussions, which were digitally audio-recorded. Topics explored comprised individual expectations and experiences of using the software, perceived challenges and recommendations for improvement. Detailed topic guides are available from the corresponding author upon request. Where possible, interviews in case study sites were conducted at two different time points (Table 3).

Table 3.

The two data collection points in case study sites

	Time 1 data collection	Time 2 data collection
Site A	February 2009–October 2009: shortly after the Trust went live with Release 1 on one ward	September 2010–November 2010: when the Trust had implemented Release 2 functionality
Site B	July 2009–February 2010: approximately a year after the Trust went live with Release 1 with half of one service	June 2010–July 2010: shortly after the Trust had rolled out the functionality to the whole service
Site C	December 2009–February 2010: approximately three months after the Trust went live with Release 1	August 2010–November 2010: approximately six months later, the time after which a certain embedding of the software was assumed to have taken place

A mixture of object-/activity-/person-oriented observation with on-site questioning was, where appropriate, employed to complement interviews, for the purposes of triangulation and to contribute to a deeper understanding of the sociotechnical processes involved in adopting the new technology. The concept of ‘following the thing’, i.e. Software X and related social processes, helped to focus observational data collection activities around the software and associated human actions (e.g. direct software use or progress meetings). In doing so, the researcher noted setting, actors, activities and impressions relating to the observation. The length of formal observations depended heavily on the cooperation of gatekeepers, which meant that data collection was somewhat opportunistic depending on opportunities arising locally. Observations, therefore, varied in length between individual settings.

Relevant documentary evidence was also collected—these documents being treated as ‘secondary data sources’ (i.e. as produced for purposes other than the research study). They were used to give an insight into organisational plans and to gain an overview of activities in order to contextualise the interviews and observations.^{89, 90}

The researcher also kept a research journal outlining personal ideas and conceptions in order to make the research process as transparent and reflexive as possible. Data collection continued until theoretical saturation (the point at which no new themes emerged) was reached, although we acknowledge that this saturation related to the early implementation/adoption period only.

Data analysis

Interviews were transcribed verbatim and, together with the transcribed observation notes and documents, uploaded into NVivo8 software. Thematic qualitative analysis was informed by the approach outlined by Miles and Huberman⁹¹ and also drew on the analytic approaches discussed by Mason, including cross-sectional and non cross-sectional indexing (i.e. examining common, as well as specific, themes) and the use of diagrams.⁸⁹

The first step thus involved developing an overall coding framework based on categories and subcategories identified in the literature as being central to IT implementation and adoption in healthcare.^{3, ²⁰, 24

–74} This entailed creating broad definitions of each category, with particular attention being paid to not defining these either too loosely or tightly.⁸⁹ Careful attention was also paid to allowing additional themes and sub-themes to emerge. This constituted the inductive part of analysis and involved examining different data through different lenses (e.g. from different stakeholder viewpoints, looking for potential alternative explanations), focussing on exploring the uniqueness of parts of data, and investigating processes that were too complex to be captured by the developed coding framework.⁸⁹ In exploring different viewpoints, for example, analysis focussed on examining how participants interpreted the situation (as recorded in the transcripts) and how these different viewpoints were integrated to produce effects. The approach to analysis therefore consisted of a mixture of deductive and inductive approaches.⁸⁹ This helped to focus data collection, while being open to emerging issues. The process was further supported by constant revisions to the coding framework in the light of emerging themes from the data.

Coding the data was essentially a process of organising, by indexing relevant transcripts, notes and documents against both pre-established and emerging categories. In doing so, the categories were indexed along the following dimensions identified as important in the literature when considering EHR implementations: history and context, technical dimension, human and social dimension, organisational dimension, and wider environmental dimension.^{3, 20, 24

–74} In line with the sociotechnical approach, coded data that were found to belong to two or more of these dimensions (illustrating the dynamic interplay between social and technical factors) were examined in most detail. Emerging issues were then re-ordered to form the core of the analysis, focussing on exploring similarities and differences between hospitals, data sources, interviewees and time-points. This was achieved by entering these in a tabular format, recording (where relevant) key issues at the two different time points, perceived causes for changes over time, tensions and underlying issues (ways in which effects may have been produced, and exploration of links between emerging themes). Cross–case analysis and integration with the wider contextual interviews involved exploring similarities and differences between case study sites, as well as likely underlying factors contributing to these. The resulting main themes outlined below were chosen on the basis of representing the main factors influencing developments and implementation progress locally and nationally.

Results

Interview data were obtained from a total of 66 different participants within case study sites and 14 additional participants from outside these case study sites. Implementation team members interviewed consisted of a mixture of clinical IT leads, IT managers (both internal and subcontracted) and training professionals. Users included a mixture of ward managers, consultants, nurses, ward clerks, administrative staff, pharmacists, allied health professionals and junior doctors. A total of 41 interviews (with 27 different participants) were conducted in Site A (an acute hospital), 26 interviews (with 19 different participants) in Site B (a community hospital) and 21 interviews (with 20 different participants) in Site C (a mental health hospital). An active effort was made to obtain both positive and negative perspectives. A summary of data collected is given in Table 4.

Table 4.

Overview of data collected in case study sites

	Data collected at Site A	Data collected at Site B	Data collected at Site C
Time period of data collection	February 2009–November 2010	July 2009–July 2010	December 2009–November 2010
Interviews	41 interviews with hospital staff with a total of 27 different interviewees: 6 operational staff and 21 users	26 interviews with hospital staff with a total of 19 different interviewees: 5 operational staff and 14 users	21 interviews with hospital staff with a total of 20 different interviewees: 6 operational staff and 14 users
Observations (noted down in associated field notes)	10 hours (including an inpatient surgery setting and an outpatient setting where the software was used)	24 hours (including use of the software healthcare settings and staff meetings)	4.5 hours of staff using the software
Notes from recruitment meeting	Yes	Yes	Yes
Press statements	eHealth Insider (identified via a search for ‘[name of Site]’), conducted on the 25 June 2009 and repeated 4 November 2010—77 pages altogether.	eHealth Insider and Computer Weekly (identified via a search for ‘[name of Site]’), conducted in January 2010 and repeated in October 2010—60 pages altogether	eHealth Insider and Computer Weekly (identified via a search for ‘[name of Site]’), conducted on 22 February 2010 and repeated 4 November 2010—12 pages altogether
Hospital documents	Deployment History Timeline, Project Initiation Document (PID), Electronic Patient Record Next Stage Business Case	Project Initiation Document (PID), two Project Status Reports, several sets of minutes from Software X Steering Group and associated meetings, Interim Evaluation Report.	Project Initiation Document (PID), two Deployment Verification Reports, Lessons Learnt Report
Researcher field journal	12 pages	5 pages	14 pages

Four main themes emerged from our analysis:

political and economic considerations: different hospitals, but similar problems;

starting points and different developments over time—the role of scale and progress in organisational coping;

the consequences of software characteristics;

individual coping: intended and unintended workarounds (we defined workarounds as behaviour employed by users to overcome a perceived limitation in a technical system) and their consequences.

We discuss our findings in more detail below, illustrated by selected quotes based on frequency (i.e. how often they occurred), similarities/differences (i.e. clustering of themes that had common or uncommon characteristics) and significance (i.e. to what extent they were judged to affect other emerging issues and examining potential underlying factors). Detailed themes and sub-themes are summarised in Box 1.

Box 1.

Themes and sub-themes emerging from the analysis

Political and economic considerations:

- changing political and economic landscape;

- need to balance local needs with national requirements;

- contractual arrangements and perceived powerlessness;

- public and political pressure to show progress.

Starting points and different developments over time in case study sites:

- different implementation strategies and scale;

- different strategies to cope with national pressures;

- progress in relation to scale versus progress in relation to software development.

The consequences of software characteristics:

- immaturity of the technology and consequences for planning, engagement, as well as usability.

Individual coping—intended and unintended workarounds and their consequences:

- workarounds employed by users desired by implementers (i.e. those that were logistically unavoidable due to the initially limited functionality available);

- workarounds employed by users not desired by implementers (i.e. those that were theoretically avoidable but were employed to cope with increases in workloads);

- fundamental changes in perceived professional identities;

- preserving interactions with patients.

A number of other factors were also identified as being important in influencing implementation and adoption activities (e.g. the role of champions, training, leadership), but as these are relatively well known,^{3, 20, 25

–74} we have focussed here on reporting the more novel findings that related to the unique national implementation set-up. In selecting the themes reported, the main aim has been to create a detailed picture of the national implementation landscape, portraying how the range of factors identified inter-related with each other.

Political and economic considerations: Different hospitals, but similar problems

Despite the demographic and strategic differences between hospitals (Tables 1 and 2), the wider political and economic environment in which implementations were taking place resulted in similar challenges experienced locally. There have been continuous changes relating to the overall political and economic landscape, including a general election and the formation of a new coalition government, which had a mandate for substantial wide-ranging budget cuts in the face of the recession/national debt.^{92, 93} These developments resulted in concerns about the lack of resources to resolve problems that arose in the context of implementing Software X, limited resources to share experiences/lessons learned between hospitals, and concerns over resources and support for future releases.^{92, 93} As a consequence, participants repeatedly questioned the adequacy of the national implementation strategy and highlighted the need to balance local needs of users and the organisation with national requirements for standardisation.

Yes ’cause otherwise it might be something which is so specific that it, other people wouldn’t, couldn’t work with it, I can’t think of an example off hand but everybody has their own slight ways of working so you have to make sure that the core, the basic function is acceptable to everybody and then the more peripheral things you can customise here in the organisation.

(Interview, healthcare professional)

In addition, contractual arrangements appeared to have contributed to perceived powerlessness for stakeholders on the ground. Hospitals lacked the ability to customise software according to their individual needs and influence deployment timelines in line with organisational readiness.

…the bottom line is that input has been defined within a national contract, it doesn’t matter how much I complain about it, it doesn’t matter how upset and annoyed [name of the Local Service Provider] may be about it, the fact is it’s subject to a wider contract and I think until that, until some of those issues are addressed…how did we arrive at the situation where the supplier is the one that’s responsible for the plan and the contract…we were told by the SHA [Strategic Health Authority^a] well you’re not going to get anything else because you’re not the customer.

(Interview, IT manager)

Moreover, hospitals were under significant political and, hence, media pressure to show progress with implementation, as there were increasingly negative public perceptions of the national implementation strategy. The media was said to contribute to this by focussing on delays, spiralling costs and various technical and other problems occurring during implementations. Political impatience may thus have inadvertently contributed to problems experienced locally (as was, for example, the case in Site A) by prematurely progressing with implementations.

…when you talk to people from other, particularly the Early Adopters, the pressure they were under to sign off was horrendous, you know, they were saying if you don’t sign this off the Secretary of State for Health is going to have to stand up in Parliament and explain why so just sign it, you know, that kind of pressure is horrendous.”

(Interview, manager)

Many of these national developments were the result of attempts to address problems encountered on the ground. For example, as stakeholders increasingly questioned the ‘top-down’ implementation model and associated contractual arrangements, the national strategy has, over time, slowly changed to a more localised approach.⁷⁵ Shortly after completion of our fieldwork, the UK’s new coalition government announced an increased focus on systems choice for local NHS organisations and an accompanying opening of the software provider market to a larger number of accredited commercial suppliers.^92,93 In line with these developments, central leadership of the implementation of EHRs in hospitals has, over time, somewhat lost momentum as the designated central implementation authority (NHS Connecting for Health) was integrated within the Department of Health’s Informatics Directorate.

Starting points and different developments over time—the role of scale and progress in organisational coping

The way hospitals dealt with the challenges arising from this complex environment (defined as ‘organisational coping’) differed. This was particularly apparent when examining developments over time. Despite fundamental demographic differences, the three hospitals implemented (at least to begin with) the same software, all gradually replacing paper systems, but with somewhat different functionalities tailored to their particular setting. For example, Site A, as an acute hospital, implemented functionality that allowed them to request pathology and radiology results electronically, while Sites B and C (the mental health and community settings) began by implementing clinical documentation functionality allowing structured documentation of care procedures, treatments and future plans. This perhaps reflected the different communication needs across settings, with secondary care prioritising the improvement of communication with geographically disconnected departments, and community/mental health settings prioritising the improvement of communication within their teams. Initially, Sites A and B followed a small-scale implementation approach, going live with one ward and nine users respectively, while Site C implemented on a larger scale, going live with 150 users. As time progressed, it became apparent that Site C, despite the initial ‘head start’, remained relatively static over a sustained period of time, without visible progress either in terms of a larger scale roll-out or significantly improved software functionality. Site A, owing to political and media pressure to progress, implemented increasing software functionality. However, this led to significant problems in the hospital, mainly due to a lack of organisational ability to plan for software that had never been implemented in this setting and the large user base. In contrast, the Site B implementation remained small-scale with no further functionality being deployed over a relatively long period of time. Here, all efforts concentrated on making the software work, this being achieved through intensive development activity in close collaboration with users. However, this took time: so much so that the overall strategic direction was reconsidered in light of resources spent, with hospital management seriously considering switching to an alternative system outside of the government programme.

I was sitting in a room next door to the meeting and chatted to healthcare professionals one by one, this time it was a mixture of those who had been using Software X since the beginning and those who just started using it (the other half of the team), the whole service is now on Software X and it seems to be going very well. The problem is that [name of IT Manager] has left quite quickly as his contract has not been extended, everyone feels that the hospital does not want Software X to succeed as the hospital wants to go with [name of Software Y] instead, it is felt that this is why the most important support person was removed from the team, the new healthcare professionals are getting on quite well which is felt to be due to the fact that the system is now much more developed and due to the hard work of the early user healthcare professionals, everyone is disappointed and does not know what will happen, they feel that pulling the plug on Software X now would be a major waste of money.

(Researcher field notes)

As a result of the perceived lack of progress in system development over time, users in Site A were increasingly frustrated; at Sites B and C, management became increasingly frustrated with the lack of progress in relation to the scale of the implementation (i.e. the limited overall number of active users). There seemed to be two different notions of progress across cases, both of which need to be fulfilled for an implementation to be considered by the majority of stakeholders participating in our research as relatively ‘successful’ (acknowledging that the notion of ‘success’ itself depends on the viewpoint of the observer). User satisfaction appeared to be closely linked to perceived system development progress, while political and managerial stakeholders tended to focus on scale (including both functionality and user base). Site A illustrated that progress in relation to system development had not been achieved, while developments in Site B indicated that progress in relation to scale had not been achieved. Site C could be placed somewhere in the middle with an initially promising implementation in relation to scale, but lacking progress in relation to software development over time.

The consequences of software characteristics

As a result of the national procurement, all hospitals had to deal with similar technology. The biggest challenge in this respect was that this technology was still in development, which affected the planning of work and business processes, training, and user engagement. It also resulted in a range of unanticipated problems for both organisational functioning and individual contexts of use.

I mean a lot of the Release 1 [referring to early and limited functionality including patient demographics] functionality works quite well but on the other hand the clinical content is woefully inadequate, you know, I mean they’re working hard to try and develop clinical content but it, you know, without clinical content clinicians won’t use it… I mean we were really, you know, you can only sort of entice people for so long until they finally sort of get fed up and say well, you know, come back and talk to me when you’ve got something to work with and that’s a lot of what we’re having now.

(Interview, manager)

The immaturity of the system also meant that all hospitals faced similar usability issues. These included, among others, freezing of screens, a long time to load documents, a perceived lack of intuitiveness, long log-in times, perceived inappropriate layouts of forms and print-outs, and the perceived inconsistency of language. Over time, some of these issues were addressed, but users in Sites A and C felt they were not addressed sufficiently for the system to be considered useable. Users in Site B, however, felt that over time the system performance had improved considerably, possibly owing to the intensive support by a dedicated IT Manager and the close involvement of users in development. As a result, users in Sites A and C tended to be relatively negative towards the system, while users in Site B became more positive over time.

Users further complained about the large number of clicks and mandatory screens in the system, which was felt to increase workload; this was a problem encountered in all three case study sites in both inpatient and outpatient care and persisted over time, irrespective of the setting and in stark contrast to the anticipated benefits of EHRs.³ It did not appear that the slowing of workflows was expected or planned for adequately, or that the persistence of these problems was anticipated. At Site B, it was addressed by allowing users an extra five minutes per appointment when they were using Software X. However, the other two sites did not address this issue, which may have exacerbated negative user attitudes.

…with some patients if it was a heavy case it could take them 20 minutes to load a form and, you know, so it’s just not workable.

(Interview, manager)

Developments at Site A were somewhat different. Despite similar usability issues, the deployment did not initially appear to significantly affect organisational functioning. However, when the hospital implemented extended software functionality replacing the local Patient Administration System (PAS), stability issues caused a fundamental disruption. As a result, all efforts there focussed on resolving issues with system stability as opposed to usability issues.

Yes and until we get [Release 2], the PAS base stabilised, we can’t roll out the other stuff and we’re desperate to do that because that’s the point at which Software X starts to add value, at the moment, benefit? None!

(Interview, manager)

Only when organisational functioning was compromised were usability issues revisited and the fitness for purpose of the software increasingly questioned by management (Site A). In Site B, however, usability issues were the focus of efforts. Only when these were addressed and users were relatively happy with the software was further roll-out considered. It therefore seems important to build successful developments on a solid base of usable software before considering further roll-out, but this was challenging in the context of the considerable political pressure to increase the scale of the implementation.

Individual coping: Intended and unintended workarounds and their consequences

While we used the notion of organisational coping to refer to the way hospitals dealt with the challenges arising from the complex ‘top-down’ implementation environment, we use the notion of individual coping to refer to the way users dealt with the introduction of the new technology. Users had to employ temporary workarounds that were accepted by the organisation owing to the initial running of paper-based systems. This was perceived by users as unnecessary duplication of activity, but accepted by most, as it was expected to attenuate in due course. Site B illustrated that this did, indeed, happen when the system was rolled out, which meant a reduction of printing activity.

There are some annoying delays between having completed the form and printing it, there are some unnecessary pages in between”, he had to click several boxes e.g. “print local” and “print preview” before being able to hit the actual print button, ticking these boxes is compulsory.

(Researcher notes, observation)

In addition, all users had to change existing work practices to fit in with the demands of the technology, resulting in workarounds that were unintended by management. Across sites the most common techniques to achieve this included using other systems to compensate for perceived shortcomings (e.g. Microsoft Word or paper), partial use, and ‘tricking the system’ (e.g. if users could not move to the next item without completing a free text box, some would simply copy text from other boxes). Most of these workarounds were what has been classified as ‘essential hindrance workarounds’.⁴² These were used to get around perceived problems in the system that were seen as making use very time-consuming and by some participants perceived to shorten the time they could spend with patients. These were seen as essential as they were designed to save time on administrative tasks, thereby freeing up time for provision of more direct patient care.

However, there were also some more fundamental changes in work practices imposed by the system, which appeared to be of greater concern to users as they were not expected to attenuate over time and could often not be addressed by ‘working around them’. These varied across sites, but often represented changes in perceived professional identities resulting from the way the system re-structured care activities. For example, many clinical users reported an increase in administrative tasks, which they felt was not what they ‘signed up for’ as it meant they spent less time on clinical activities.

We’ll put this data in and put that in, well I’m sorry that’s not my job, you know, and putting demographics in isn’t a nursing task it’s a secretarial one, you know, putting ethnicity in it’s not my job it’s, you know, so that was the ethos of it.

(Interview, healthcare professional)

Therefore, most users carefully ‘guarded’ the interactions with patients by keeping them as personal as possible. This was particularly apparent in settings where computers were originally intended to be used in the clinical encounter (Site A during ward rounds and Site B during one-to-one consultations), which was not perceived as appropriate as users felt it affected the therapeutic relationship (Site B). In other sites, the system was not viewed as fast and flexible enough to be used in the fast-moving clinical setting (Site A). As a result, clinical and administrative tasks tended to be separated at all hospitals and hand-held computers were used to a minimum. As a knock-on effect, data entry into electronic systems was often delayed, which meant that the system was not as up-to-date as it was initially planned to be. This lack of contemporaneous data entry has obvious potentially important implications for the quality and safety of care (e.g. if a certain procedure or medication administration is not documented and therefore repeated), as well as the possibility of associated medico-legal consequences. This issue is likely to pose significant challenges in future deployments as clinical users are likely to resist use of computers if it is perceived to go against the basic philosophical underpinnings of their profession.

The length of time it takes to actually get that note in there is just such hard work and you end up lumping things together because you think I’m not going to open it up again and put a second phone call in, you know, I’ll do it a day later when I’ve done three calls that day and just throw them all in together. I end up keeping a paper note to prompt me because I haven’t got time. I tend to do it all in one big chunk, so I end up doing a paper note saying, you know, don’t forget to write these up. You go in and think right rather than do separate Software X’s for these two phone calls I’ll throw them all in one which works better.

(Interview, healthcare professional)

Similarly, users felt that the balance between security measures and the complex day-to-day service demands characterising the healthcare environment was not fit-for purpose and access cards needed to log into the system were often shared or left in terminals. Again, this is likely to be of continuing importance resulting in compromised security measures.

Discussion

Overall, the national implementation of Software X has been much slower and on a much more limited scale than originally anticipated. Our findings begin to shed light on potential reasons for this lack of progress, as they suggest how the experiences at early implementer sites may have affected the rate of national implementation progress over time, illustrated by, for example, an increasing focus on local involvement in decision making.^92
–95

As can be seen, the national ‘top down’ arrangements have had significant consequences for the way Software X was procured, implemented and used locally. Despite the obvious differences between organisations, they were, therefore, often faced with similar technical and political challenges. These were coped with differently by different organisations owing to contextual contingencies (e.g. implementation scale) and coping of users, reflecting a range of organisational and individual differences. The mutually shaping relationship between these two types of coping has been highlighted, outlining consequences of both organisational coping on individual users and vice versa.

However, many ongoing deliberations and political debates relating to large-scale IT implementations assume that local factors are relatively stable, neglecting this mutually shaping relationship between national and local developments.^{57, 59, 96, 97} It is therefore important that this dynamic environment is reflected in strategic planning of such initiatives, ‘top-down’ or otherwise as national ventures need, by definition, some degree of national guidance.

Any national implementation effort should therefore focus (at least initially) primarily on making systems work locally. Focussing principally on interoperability, as in the English approach by procuring national software with limited customisability, illustrates a lack of appreciation of local factors and in particular the dynamic interplay between the local and the national contexts. As our findings indicate, this local adjustment takes time, particularly when implementing software that is perceived by users as lacking fitness-for-purpose. Associated with this is the need for visible short- and long-term benefits to users, organisations and patients. The latter two may take significantly longer to realise and had, indeed, not materialised in any of the three hospitals studied. Our work has shown that there is clearly a need for sufficient time and resources to allow users and organisations to cope with change and deal with emerging challenges and consequences resulting from the introduction of the new technology. Furthermore, this need for time and space should be accompanied by adequate training and support structures involving ongoing and two-way communication between implementers and users.^{3, 20, 24

–74} These conditions were eventually fulfilled in Site B, which, from our point of view, could be described as a relative local ‘success’ in terms of software usability which led to high adoption rates and some early benefits for users.

In line with this argument, a ‘successful’ national implementation is possibly more likely to be realised if it is built on the basis of several ‘successful’ local implementations (i.e. procuring software that satisfies user, organisational and patient needs). Otherwise, there is a real danger that systems are simply not used or used in ways other than intended, which will, in turn, threaten national implementation ‘success’. In addition, the more practical factors of systems interoperability (most likely to be achieved through some kind of consistent approach to set standards) and scale of adoption seem to be important here.^{4, 11, 12, 98, 99}

The strengths of our work include its real-time, longitudinal nature, as well as the range of data obtained from different sources. However, naturally there are also limitations. Firstly, it is important to recognise that the case study sites may not be representative of the wider range of hospitals in England (or indeed internationally) that are yet to implement EHRs. Nevertheless, the fact that selection of our cases was theoretically informed allowed us to make theoretical generalisations to other settings¹⁰⁰ and the in-depth nature of our work has allowed us to identify a number of common factors that are likely to be transferable. Secondly, our work may not necessarily have provided insights into all aspects of implementation and adoption activities, and was influenced by our assumptions and data sources. We did not enter the field without preconceptions, for example in relation to the ‘top-down’ imposing nature of the programme, which combined with our close involvement with those that had to cope with the consequences of the national implementation locally, possibly influenced our data collection and analysis activities. We have attempted to address this by outlining our methods in as much detail as possible. Similarly, our results only represent a part of our overall findings, identified on the basis of our aims, namely the early experiences of organisations and users attempting to implement a nationally procured system.

Conclusions

This comparative case study has provided insights into the mutually shaping relationship between national and local factors within the context of a national EHR implementation. Hospitals studied were, in many ways, faced with similar issues surrounding national arrangements and resulting technological properties. However, different localities dealt with these in different ways relating to organisational coping (e.g. scale) and similarly in other ways often relating to individual coping (e.g. workarounds). These, in turn, affected wider environmental developments. Drawing on our results, we have developed a more detailed appreciation of sociotechnical factors in national implementation approaches than can be found in the current literature.

Several lessons from these findings can be applied to international efforts of large-scale EHR implementation. We have summarised these in Box 2. By contrasting different experiences over time from a variety of perspectives, we have argued that progress in software development (including resolving issues with system usability) needs to be realised first before tackling progress in terms of deployment scale. Otherwise, there is a danger that local issues compromise national implementation progress. This will only be achieved in close collaboration with users and with a system that is perceived as fit-for purpose, bringing observable benefits to individuals, organisations and patients. National implementation approaches therefore need to be cognisant of local developments before considering issues surrounding systems interoperability, scale and secondary uses of data.

Box 2.

Summary of implications for policy and lessons learnt

- User involvement in all stages of the implementation is key. This should encompass ongoing and two-way communication between implementers and users.

- There is a need to build on a solid base of usable software before considering further roll-out.

- There is a need to recognise that the implementation of EHRs is a long-term process and not a short-term project.

- Sufficient time and resources needed to allow users and organisations to cope with change and deal with emerging challenges and consequences resulting from the technology introduction.

- There is a need to make the software work optimally locally before attempting to roll it out on a larger scale.

- Customisation is important to allow commercial systems to suit local needs.

- There is a need for an increased focus on social and cultural factors which need to be taken into account when designing systems. IT should be viewed as an enabler to improve business processes.

- Managerial large-scale benefits and clinical small-scale benefits need to be carefully balanced as there are likely to be trade-offs with too narrow a focus on either.

Footnotes

Acknowledgements

We are very grateful to the participating sites for supporting this work and to all interviewees who kindly gave their time. We gratefully acknowledge the contribution of our colleagues working on these evaluations and the thoughtful and constructive comments of two expert peer reviewers on an earlier version of the article. KC is supported by a studentship from the Medical Research Council. We acknowledge the support of the National Institute for Health Research, through the Comprehensive Clinical Research Network.

Funding

AS and KC are funded to undertake an evaluation of the NHS Care Record Service (NHS CFHEP 005), data coding and structuring (NHS CFHEP 009) and the impact of IT on the clinician-patient relationship (NHS CFHEP 010). This work is independent research commissioned by the NHS Connecting for Health Evaluation Programme. The views expressed in this publication are those of the authors and not necessarily those of the NHS, the NHS Connecting for Health Evaluation Programme or the Department of Health. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.

Conflict of interest

All authors declare that they have no conflicts of interest.

a

SHAs are governance structures in the English NHS that implement policies at the local level.

b

Organisations that were amongst the first to implement Software X as part of the national strategy.

References

Catwell

Sheikh

. Information technology (IT) system users must be allowed to decide on the future direction of major national IT initiatives. But the task of redistributing power equally amongst stakeholders will not be an easy one. Inform Prim Care 2009; 17: 1–4.

Protti

. Comparison of information technology in general practice in 10 countries. Health Q 2007; 10: 107–115.

Black

Car

Pagliari

. The impact of eHealth on the quality and safety of healthcare: a systematic overview. PLoS Med 2011; 8.

Coiera

. Building a National Health IT System from the middle out. J Am Med Inform Assoc 2009; 16: 271–273.

Morrison

Robertson

Cresswell

. Understanding contrasting approaches to nationwide implementations of electronic health record systems: England, the USA and Australia. J Health Eng 2011; 2: 25–42.

Department of Health. Information for health an information strategy for the modern NHS. Available at: http://www.dh.gov.uk/en/PublicationsAndStatistics/LettersAndCirculars/HealthServiceCirculars/DH_4005016 (1998, accessed 17 December 2007).

Department of Health. The NHS plan: a plan for investment, a plan for reform. London: Department of Health, 2000.

Department of Health. Building the Information Core: Implementing the NHS Plan. London: Department of Health, 2001.

Department of Health. Delivering the NHS Plan: next steps on investment, next steps on reform. London: Department of Health, 2002.

10.

Department of Health. Delivering 21st century IT support for the NHS: national strategic programme. London: Department of Health, 2002.

11.

Blumenthal

Tavenner

. The meaningful use regulation for electronic health records. N Engl J Med 2010; 363: 501–504.

12.

Certification Commission for Health Information Technology. Available at: http://www.cchit.org/ (2011, last accessed 18 January 2011).

13.

Australian Government. A national health and hospitals network for Australia’s future. Delivering better health and better hospitals. Available at: http://www.health.gov.au/internet/yourhealth/publishing.nsf/Content/report-redbook/$File/HRT_report3.pdf. (2010, last accessed 12/04/2012)

14.

Shekelle

Goldzweig

. Costs and benefits of health information technology: an updated systematic review. 2009. London: Health Foundation on behalf of the Southern California Evidence-based Practice Centre, RAND Corporation.

15.

Lorenzi

Novak

Weiss

. Crossing the implementation chasm: a proposal for bold action. J Am Med Inform Assoc 2008; 15; 290–296.

16.

Berg

. Of forms, containers, and the electronic medical record: Some tools for a sociology of the formal. Sci Technol Human Value 1997; 22: 403–433.

17.

Berg

. Medical work and the computer base patient record: a sociological perspective. Method Inform Med 1998; 37: 294–301.

18.

Berg

. Health Information Management – Integrating Information Technology in Health Care Work. London: Routledge, 2004.

19.

Chaudhry

Wang

. Systematic review: impact of health information technology on quality, efficiency, and costs of medical care. Ann Intern Med 2006; 144: 742–752.

20.

Cresswell

Sheikh

. The NHS Care Record Service (NHS CRS): recommendations from the literature on successful implementation and adoption. Inform Prim Care 2009; 17: 153–160.

21.

Friedman

Abbas

. Is medical informatics a mature science? A review of measurement practice in outcome studies of clinical systems. Int J Med Inform 2003; 69: 261–272.

22.

Hendy

Fulop

Reeves

. Implementing the NHS information technology programme: qualitative study of progress in acute trusts. BMJ 2007; 334: 1360.

23.

Greenhalgh

Potts

Wong

. Tensions and paradoxes in electronic patient record research: a systematic literature review using the meta-narrative method. Milbank Q 2009; 87: 729–788.

24.

Car

Anandan

Black

. The impact of eHealth on the quality and safety of healthcare – a systematic overview and synthesis of the literature. Report for the NHS Connecting for Health Evaluation Programme. NHS Connecting for Health Evaluation Programme, Birmingham.

25.

Aarts

Doorewaard

Berg

. Understanding implementation: the case of a computerized physician order entry system in a large Dutch university medical center. J Am Med Inform Assoc 2004; 11: 207–216.

26.

Adler

. How to successfully navigate your EHR implementation. Fam Pract Manage 2007; 14: 33–39.

27.

Ammenwerth

Iller

Mahler

. IT-adoption and the interaction of task, technology and individuals: A fit framework and a case study. BMC Med Inform Decis Mak 2006; 6: 13.

28.

Ash

Berg

. Report of conference Track 4: socio-technical issues of HIS. Int J Med Inform 2003; 69: 305–306.

29.

Austin

Hornberger

Shmerling

. Managing information resources: a study of ten healthcare organizations. J Healthcare Manage 2000; 45: 229–238.

30.

Bali

Wickramasinghe

. Achieving successful EPR implementation with the penta-stage model. Int J Healthcare Technol Manage 2008; 9: 97–105.

31.

Bates

Ebell

Gotlieb

. A proposal for electronic medical records in U.S. primary care. J Am Med Inform Assoc 2003; 10: 1–10.

32.

Bates

Kuperman

Wang

. Ten commandments for effective clinical decision support: making the practice of evidence-based medicine a reality. J Am Med Inform Assoc 2011; 10: 523–530.

33.

Beuscart-Zephir

Anceaux

Crinquette

. Integrating users’ activity modeling in the design and assessment of hospital electronic patient records: The example of anesthesia. Int J Med Inform 2001; 64: 157–171.

34.

Boonstra

Broekhuis

. Barriers to the acceptance of electronic medical records by physicians – from systematic review to taxonomy and interventions. BMC Health Serv Res 2010; 10: 231.

35.

Bossen

. Test the artefact-Develop the organization. The implementation of an electronic medication plan. Int J Med Inform 2007; 76: 13–21.

36.

Callen

Braithwaite

Westbrook

. Contextual implementation model: a framework for assisting clinical information system implementations. J Am Med Inform Assoc 2008; 15: 255–262.

37.

Chaudhry

Wang

. Systematic review: impact of health information technology on quality, efficiency, and costs of medical care. Ann Intern Med 2006; 144: 742–752.

38.

Clemmer

. Computers in the ICU: where we started and where we are now. J Crit Care 2004; 201–207.

39.

Crosson

Stroebel

Scott

. Implementing an electronic medical record in a family medicine practice: communication, decision making, and conflict. Ann Fam Med 2005; 3: 307–311.

40.

Dagroso

Williams

Chesney

. Implementation of an obstetrics EMR module: overcoming user dissatisfaction. J Healthcare Inform Manage 2007; 21: 87–94.

41.

Davidson

Chiasson

. Contextual influences on technology use mediation: a comparative analysis of electronic medical records systems. European J Inform Syst 2005; 14: 6–18.

42.

De Mul

Berg

Hazelzet

. Clinical information systems: CareSuite from Picis. J Crit Care 2004; 19: 208–214.

43.

Duggan

. Implementation evaluation. HIM professionals share their experiences bringing health IT online. J AHIMA 2006; 77: 52–55.

44.

Fenton

Giannangelo

Stanfill

. Essential people skills for EHR implementation success. J AHIMA 2006; 77: 60.

45.

Ferneley

Sobreperez

. Resist, comply or workaround? An examination of different facets of user engagement with information systems. Eur J Inf Syst 2006; 15: 345–356.

46.

Giuse

Kuhn

. Health information systems challenges: The Heidelberg conference and the future. Int J Med Inform 2003; 69: 105–114.

47.

Goroll

Simon

Tripathi

. Community-wide implementation of health information technology: the Massachusetts eHealth Collaborative experience. J Am Med Inform Assoc 2009; 16: 132–139.

48.

Granlien

Hertzum

Gudmundsen

. The gap between actual and mandated use of an electronic medication record three years after deployment. Stud Health Technol Inform 2008; 136: 419–424.

49.

Greenhalgh

Stramer

Bratan

. Introduction of shared electronic records: multi-site case study using diffusion of innovation theory. BMJ 2008; 337: 1786.

50.

Greenhalgh

Stramer

Bratan

. Adoption and non-adoption of a shared electronic summary record in England: a mixed-method case study. BMJ 2010; 340: 3111.

51.

Halamka

Aranow

Ascenzo

. E-Prescribing collaboration in Massachusetts: early experiences from regional prescribing projects. J Am Med Inform Assoc 2006; 13: 239–244.

52.

Hendy

Reeves

Fulop

. Challenges to implementing the national programme for information technology (NPfIT): a qualitative study. BMJ 2005; 331: 331–336.

53.

James

Hess

Kretzing

. Showing “what right looks like”—how to improve performance through a paradigm shift around implementation thinking. J Healthcare Inform Manage 2007; 21: 54–61.

54.

Jones

. Learning the lessons of history? Electronic records in the United Kingdom acute hospitals, 1988–2002. Health Inform J 2004; 10: 253–263.

55.

Karsten

Laine

. User interpretations of future information system use: a snapshot with technological frames. Int J Med Inform 2007; 76: S136–S140.

56.

Keddie

Jones

. Information communications technology in general practice: Cross-sectional survey in London. Inform Prim Care 2005; 13: 113–123.

57.

Keshavjee

Bosomworth

Copen

. Best practices in EMR implementation: a systematic review. AMIA Annual Symposium Proceedings available from: http://www.compete-study.com/documents/Best_Practices_in_EMR_Implementation.pdf

Last accessed: 12/04/2012

58.

Lium

Tjora

Faxvaag

. No paper, but the same routines: A qualitative exploration of experiences in two Norwegian hospitals deprived of the paper based medical record. BMC Med Inform Decis Mak 2008; 8: 2–14.

59.

Lorenzi

Smith

Conner

. The Success Factor Profile for clinical computer innovation. Stud Health Technol Inform 2004; 107: 1077–1080.

60.

Y-C

Xiao

Sears

. A review and a framework of handheld computer adoption in healthcare. Int J Med Inform 2005; 74: 409–422.

61.

Ludwick

Doucette

. Adopting electronic medical records in primary care: Lessons learned from health information systems implementation experience in seven countries. Int J Med Inform 2009; 78: 22–31.

62.

Mehta

Partin

. Electronic health records: a primer for practicing physicians. Cleve Clin J Med 2007; 74: 826–830.

63.

Miranda

Fields

Lund

. Lessons learned during 15 years of clinical information system experience. Computers Nurs 2001; 4: 147–151.

64.

Moen

. A nursing perspective to design and implementation of electronic patient record systems. J Biomed Inform 2003; 36: 375–378.

65.

Nikula

. Why implementing EPR’s does not bring about organizational changes–a qualitative approach. Stud Health Technol Inform 2001; 84: 666–669.

66.

Ovretveit

Scott

Rundall

. Improving quality through effective implementation of information technology in healthcare. Intl J Qual Health Care 2007; 259–266.

67.

Pagliari

. Implementing the National Programme for IT: What can we learn from the Scottish experience? Inform Prim Care 2005; 13: 105–111.

68.

Pare

. Implementing clinical information systems: A multiple-case study within a US hospital. Health Serv Manage Res 2002; 15: 71–92.

69.

Pare

Sicotte

Jaana

. Prioritizing the risk factors influencing the success of clinical information system projects. A Delphi study in Canada. Methods Inform Med 2008; 47: 251–259.

70.

Pendergast

Buchda

. Charting the course. A quality journey. Nursing Administration Q 2003; 27: 330–335.

71.

Puffer

Ferguson

Wright

. Partnering with clinical providers to enhance the efficiency of an EMR. J Healthcare Inform Manage 2007; 21: 24–32.

72.

Quinzio

Junger

Gottwald

. User acceptance of an anaesthesia information management system. Eur J Anaesthesiol 2003; 20: 967–972.

73.

Räisänen

Linde

. Technologizing discourse to standardize projects in multi-project organizations: Hegemony by consensus? Organization 2004; 11: 101–121.

74.

Rose

Jones

Truex

. Socio-theoretic accounts of IS: The problem of agency. Scand J Inform Syst 2005; 17: 133–152.

75.

Robertson

Cresswell

Takian

. Implementation and adoption of nationwide electronic health records in secondary care in England: qualitative analysis of interim results from a prospective national evaluation. BMJ 2010; 341: 4564.

76.

Sheikh

Cornford

Barber

. Implementation and adoption of nationwide electronic health records in secondary care in England: final qualitative results from a prospective national evaluation in “early adopter” hospitals. BMJ 2011; 343: 6054.

77.

Yusof

Kuljis

Papazafeiropoulou

. An evaluation framework for Health Information Systems: human, organization and technology-fit factors (HOT-fit). Int J Med Inform 2008; 77: 386–398.

78.

Coiera

. Four rules for the reinvention of health care. BMJ 2004; 328: 1197–1199.

79.

Chiasson

Reddy

Kaplan

. Expanding multi-disciplinary approaches to healthcare information technologies: What does information systems offer medical informatics? Int J Med Inform 2007; 76: S89–S97.

80.

Doolin

Lowe

. To reveal is to critique: actor-network theory and critical information systems research. J Inform Technol 2002; 17: 69–78.

81.

Prout

. Actor-network theory, technology and medical sociology: an illustrative analysis of the metered dose inhaler. Soc Health Illn 1996; 18: 198–219.

82.

Williams

Pollock

. E-Infrastructures: how do we know and understand them? Strategic ethnography and the biography of artefacts Available at SSRN: http://ssrn.com/abstract=1616593 (2010, accessed last accessed 12/04/2012).

83.

Knoblauch

. Focused ethnography. Available at: http://www.qualitative-research.net/index.php/fqs/article/viewArticle/20/43 (2005, last accessed 7 October 2009).

84.

Williams

Pollock

. Beyond the ERP implementation study: a new approach to the study of packaged information systems: the biography of artifacts framework. ICIS Proceedings 2009 Proceedings. Paper 6. available from: http://hdl.handle.net/1842/3248 last accessed 12/04/2012.

85.

Marcus

. Ethnography in/of the world system: the emergence of multi-sited ethnography. Ann Rev Anthropol 1995; 24: 95–117.

86.

Hannerz

. Being there … and there … and there!: Reflections on multi-site ethnography. Ethnography 2003; 4: 201–216.

87.

Crowe

Cresswell

Robertson

. The case study approach. BMC Med Res Methodol 2011; 11: 100.

88.

Flyvbjerg

. Five misunderstandings about case study research. Qual Inq 2006; 12: 219–245.

89.

Mason

. Qualitative researching. London: Sage, 2002.

90.

Appleton

Cowley

. Analysing clinical practice guidelines. A method of documentary analysis. J Adv Nurs 1997; 25: 1008–1017.

91.

Miles

Huberman

. Qualitative data analysis. Thousand Oaks, CA: Sage, 1994.

92.

Department of Health. Equity and excellence: Liberating the NHS. London: Department of Health, 2010.

93.

Cabinet Office. Government ICT strategy. Available at: http://www.cabinetoffice.gov.uk/content/government-ict-strategy (2011, last accessed 28 April 2011).

94.

The Guardian. NPfIT goes to the country. Available at: http://www.smarthealthcare.com/england-patient-records (2011, last accessed 18 January 2011).

95.

Greenhalgh

Stones

. Theorising big IT programmes in healthcare: Strong structuration theory meets actor-network theory. Soc Sci Med 2010; 70: 1285–1294.

96.

Walker

. Case study: leading change across two sites: introduction of a new documentation system. Nurs Leadership 2006; 34–40.

97.

Sicotte

Pare

Moreault

M-P

. A risk assessment of two interorganizational clinical information systems. J Am Med Inform Assoc 2006; 13: 557–566.

98.

eHealth Insider. Granger secures commitment to fund NPfIT. Available at: http://www.ehi.co.uk/news/ehi/591 (2011, last accessed 18 January 2011).

99.

Craig

. Plundering the Public Sector. How New Labour are letting consultants run off with £70 billion of our money. London: Constable, 2006.

100.

Stake

. The Art of Case Study Research. London: SAGE Publications, 1995.

Comparative case study investigating sociotechnical processes of change in the context of a national electronic health record implementation

Abstract

Keywords

Introduction

Methods

Ethical statement

Design

Sampling

Data collection

Data analysis

Results

Themes and sub-themes emerging from the analysis

Political and economic considerations: Different hospitals, but similar problems

Starting points and different developments over time—the role of scale and progress in organisational coping

The consequences of software characteristics

Individual coping: Intended and unintended workarounds and their consequences

Discussion

Conclusions

Summary of implications for policy and lessons learnt

Footnotes

Acknowledgements

Funding

Conflict of interest

a

b

References