Multiple translations of the vision

Within our case study sites, we found that there were many different translations of the overall vision of NHS Care Records Service systems among various stakeholders. These ranged from those that focused on managing patients’ data (such as data capture, storage, and sharing) to changing organisational arrangements and workflows (such as business process change) to more policy related aims (such as modernisation, shift to patient focus). For example, some held a business driven view that emphasised standardised practice at the expense of innovation in workflow, clinical practice, interorganisational arrangements, or management and policy ambitions:

“Ideal is that the NHS will become standardised, so the way in which we interact with computers and the way in which we interact with patients will become standardised” (interview, IT professional, site C).

Such views clashed with those who saw electronic health records as being a way to achieve more patient centred healthcare:

“it’s the patients that hold the record and the patient should control who has access to it . . . Give the patient the record and give the patient the key to unlock it. They are partly responsible for the record themselves” (interview, healthcare professional, site R).

We found little evidence of efforts to align these perspectives to aid the process of working towards agreed goals. The persistence of multiple visions thus possibly reflected limited or ineffective communication channels to maintain or indeed refine or update the original vision.

The arrival of the NHS Care Records Service in institutional settings

Various approaches were taken by local organisations to prepare for implementation, and several internal and external factors shaped the different implementation strategies pursued. These included different levels of maturity of NHS Care Records Service systems, concurrent changes occurring in sites (for example, working to achieve greater autonomy from the Department of Health), changes in the National Programme as a whole (for example, contract renegotiations), and in NHS policies and targets (for example, financial savings and restructuring of commissioning models), all adding uncertainties and delays to the process.

“I think people get a bit, is it worth it? Is it worth me continuing? Should I put the effort in?” (interview, IT professional, site C).

Most of the hospitals we studied were “early adopters.” This meant that all concerned (that is, NHS Connecting for Health, suppliers, local service providers, and hospitals) were encountering problems for the first time. These often involved the challenges inherent in putting software into practice and related problems with connectivity, usability, training, data quality and migration, and system downtime.

The complex supply chains and convoluted communication processes between hospitals, local service providers, software suppliers, and NHS Connecting for Health that we previously described, persisted over time.38 The tensions relating to contracts often led to a rigid focus on a limited set of “deliverables,” thereby hindering any attempts at fostering local ownership or meaningful engagement with NHS staff. There was consequently a lack of attention to more productive deliberations that might have helped to overcome the many challenges that were (inevitably) encountered. Hospitals, as the “client” or “problem owner,” were hampered by a lack of budgetary control, lack of information about contractual arrangements, and lack of ability to configure the software (constrained by contractual clauses). Nor could they effectively engage in direct communication with the software supplier. The primacy of these commercial relationships often meant that participants suggested that contracts were focused on the delivery of the product rather than on its quality, the process of delivery, achieving meaningful use, and wider consequences of its implementation:

“I think it’s always very difficult when you involve a commercial company with a public service, because a commercial company will always be driven by profit and the money that they are making. Maybe as things get critical the quality of what’s delivered becomes a secondary issue” (interview, healthcare professional, site C).

This led at times to a gradual disengagement by hospital staff. Also contributing to disengagement was the communications cycle between user and developer that was often extended and fragmented. The potential for imaginative or pragmatic problem solving furthermore clashed with the “top down” approach governed by software contracts and formal processes of requirement specification.

“The milestones in the plan were set as a contractual milestone so we weren’t allowed to alter those. What was quite difficult was we had to work backwards from those milestones . . . milestones that were set were probably going to be unachievable, but we had to work within the constraints of that contract” (interview, IT professional, site R).

“it takes much longer to do anything than you think it’s going to take and there’s so many people involved, so many committees involved to get anything done at the supply side that it takes a long time to get things sorted and that’s unfortunate” (interview, IT professional, site H).

Standardisation versus localisation

All sites adopting the software systems faced trade-offs between standardisation and localisation. Administrative, technical, and clinical users interviewed were often aware of this tension and of the need to balance the requirements of individual organisations and the NHS more generally. Thus, some were concerned that the more customised the software became the more distant it would get from its centrally defined purposes:

“If you keep giving people the ability to localise things you kind of drive away from a centralised understanding” (interview, healthcare professional, site C).

Assumptions inscribed into NHS Care Records Service systems as to how the English NHS operated (or should operate) were often challenged. The system was often perceived by hospital staff to reflect developers’ lack of understanding of their clinical processes, resulting in systems that were often seen as linear and homogeneous, and unable to fit to the actual complexities of clinical practice:

“What was delivered was a clumsy system that seems to have been designed for one clinician who has clinics booked up in advance that uniquely come in and everybody who comes shows up or maybe they don’t show up. There is nothing more complicated than that” (interview, healthcare professional, site M).

The complex supply chains added tortuous bottlenecks in resolving such issues. In line with this, some participants reported that the software they were implementing was “inflexible,” that they “had to push hard for every single change in the system,” and that “finding solutions seemed to be long winded and difficult” (interview, healthcare professional, site R).

Some early benefits for staff

The challenging experiences described above did not necessarily invalidate the case for electronic health records. Enhanced availability of data and data management tools were perceived as benefits by managers and some clinical users when information was legible, available in “real time,” more easily searchable and retrievable (such as for management purposes), and accessible “any time” and “anywhere” by multiple concurrent users. The team working that exemplifies community mental health provided an example of where sharing of data brought clear benefits.

“The main thing really is that we can read people’s writing. That was a big thing before that you couldn’t actually read what people were writing in the NHS across the board. Now we can read everybody’s writing. That is a major thing. And people I think forget that over time. You quickly forget the bad old days of not being able to read what somebody has written” (interview, healthcare professional, site M).

“It’s good for performance management as well, so you can go back to clinicians and go OK never mind how many patients you saw, this is your risk level of your case load, this is the risk level of somebody else’s caseload, look at the difference? Why do you think that might be, and you can also look at numbers, you know, this is the number of letters that you’ve sent to GPs [general practitioners] how come so and so sends this many letters and you only do this many letters, you know, because you’ve got absolutely everything there” (interview, IT professional, site H).

These positive developments really materialised only after a system had achieved a critical mass of users and data. Initially, there was often seen to be a need to “feed the beast” (interview, healthcare professional, site H), getting little, if anything, in return.

Electronic transmission of information was also reported as making some user workflows faster overall, although individual stages of these workflows could become more time consuming than the previous system—this was, for example, the case if the data input screen required additional or different data from those that were customarily recorded. In such cases, staff often understood that the extra investment of time on their part served an important wider organisational function, but in the context of already heavy clinical or administrative workloads investing this additional time still often rankled.

More generally, our data, drawn from multiple user and managerial communities across sites, suggested that the upheaval associated with implementing these systems had given the opportunity for organisational learning and reflection. Staff were often engaged with the problem of getting the best out of the new system and in exploring its possibilities. As one IT professional stated:

“There are a lot of experienced people now that understand what this type of change means to the NHS and how to help them to make that happen that I think you wouldn’t want to lose that” (interview, IT professional, site D).

Work processes and changes in work practices

We found that the NHS Care Records Service was usually portrayed by planners and implementers as a set of systems designed primarily for clinical users, but that the main users of the software systems, at least in the early phases, were often allied health professionals and administrative staff. Their interests and concerns, however, seemed less likely to be elicited, understood, or acted on as implementations went forward.

“Well you feel like saying if it’s not working well let’s go home shall we, cause you just feel why have I bothered to come into work, you would come in before and you would think well I’ve got three clinics there that day and you’re just thinking well I knew I could get three of them typed you’re lucky now if you can get one typed in a day. I said at one of the meetings well when are you going to start employing some extra staff if you want the work done instead of cutting back on us, which is what they’re doing because now with the system work’s just all piled up and they’re just giving us a system, we don’t have any cover, work piled up for two weeks, and the system is taking two or three times as long” (interview, administrative staff, site B).

Senior clinicians were often (particularly in the early stages of the implementation) less likely to be affected directly by the system on a daily basis than their more junior colleagues (though this to an extent depended on the system in question and the specialty). For instance, a consultant psychiatrist explained that junior doctors would type clinical information into the electronic health record on their behalf:

“I have a team. I probably use [RiO] less than 10% of the time, because if I’m seeing patients in a ward setting, it would be my junior doctor that’s inputting the information” (interview, healthcare professional, site M).

Over time, the software systems were, in most cases, made to work better and more in synchrony with the local practices of delivery of care. Users, despite the problems they faced, were with effort able to “reconfigure” the software or reconfigure their way of working. In this way, their early frustrations were in some cases reduced. Thus a process of adaptation and adoption into the complex settings in which the software systems were implemented occurred. If this adjustment process was not possible, however, staff were obliged to accommodate the idiosyncrasies of the technology (for example, by using other systems, adopting compensating behaviours, or by partial use). Getting to know the limits of the system, users learnt to prepare and compensate. In doing so, they “creatively” devised strategies to overcome usability issues, such as taking screenshots of the just typed notes when the system “froze” and then printing it to add it to the paper file to avoid having to re-do time consuming work. This also, for example, involved leaving identity authentication cards in computer terminals to avoid lengthy log-in processes, as illustrated by the following researcher observation note:

10.45am: Student is now seeing a patient (old lady) in cubicle 1, chatting “How are you today? How are you getting on with your cream? Are you diabetic? Do you have thyroid problems?”; the system is still running on the laptop and the SmartCard [an identity authentication card] is in it while [the healthcare professional] is still out of the room.

The need to “trick the system” to overcome constraints (such as mandated fields or screens unfit for a specific clinical activity) and to “get the job done” or absence of the right clinical code in a drop down menu could result in issues further down the line—for instance, impacting on data quality or management’s ability to monitor activity levels.

Systems also led to a redistribution of work, with in some cases, clinicians doing more of the data entry that would otherwise be done by “typists” or “data entry” clerks. As a result, some participants reported that constant use of computers was “not really what [they] signed up for,” and other interviewees argued that NHS Care Records Service software was undermining their professional standing by forcing them to undertake administrative tasks:

“Especially when it started for the first few months it was very much, we felt like IT people, we felt like admin people instead of actual clinicians because we were spending more time with this system than we were actually with the patient” (interview, healthcare professional, site H).

This was exacerbated when data entry on the computer took (or seemed to take) longer than on paper, which put additional pressure on users:

“All our doctors and nurses are having to work harder now, because we are having to see the same number of patients with less time, because you are spending more time on a computer now and we have got no more doctor or nursing resources to do that” (interview, healthcare professional, site D).

Overall, work practices did not become “paperless” or even “paper light”: note taking while with the patient was still most often done on paper—sometimes on the back of scraps of used paper—with data entry to the computer systems done retrospectively (though this depended again on the maturity of the system in question). A major change in work practices expected by many at the outset, indeed a part of the vision, was concurrent entry of clinical information on the system at the time the activity took place (such as when consulting with a patient). For instance, in one hospital, the intention of management was for:

“Staff to update the record in real-time, so that the NHS Care Records Service became accepted as a normal part of their work” (interview, IT professional, site D).

In most hospitals, however, clinicians did not enter data in the system while they were with the patients (either at bedside, during ward rounds, or during outpatient clinics). This changed to some extent over time and varied between settings, but the example of mental health patients presenting in emergency departments (which had target times within which all patients needed to be seen) was particularly telling:

“I think there is a big issue for junior doctors out of hours and the nightshift in accident and emergency because the psychiatric assessments are quite lengthy and there is quite a lot of notes that go with it. What they usually do while they are in with the patient is, they make the notes as they go along and they are the record. They’ve raised concerns that they will be in with the patient and they are then going to have to come and type those notes up. They are not going to be able to do it while they are with the patient, because of issues like risk. These are patients that are really quite disturbed. You can’t kind of be faffing around getting them by computers. So it’s going to increase the time spent and you are then delayed seeing the next patient, that’s going to impact on the breaches of accident and emergency which is I think the big anxiety” (interview, healthcare professional, site M).