Fitness for purpose when there are many different purposes: Who are electronic patient records for?

Abstract

Electronic patient record systems serve many purposes for many different kinds of users. Four case studies are reported of the use made by health-care staff of electronic patient record systems that supported health-care pathways. The results demonstrate that the systems fit the purposes of strategic and managerial users of the record, but they are problematic as tools for use by the frontline staff delivering care. As a result, these staff frequently resort to workarounds to accomplish their work goals. An analysis of the design processes that created these systems shows that the specification of the systems was based on strategic and managerial requirements and there was no formal assessment of the needs of frontline users. Efforts to address the needs of frontline staff in the provisions of electronic systems were most often made after the main system was implemented.

Introduction: the multiple functions of patient records

In the electronic patient information systems that cross organizational boundaries (EPICOg) project, ¹ we found that electronic systems that held patient records had many different functions. They were, for example, (1) the working tools of health-care teams as they sought to diagnose and treat the conditions of their patients; (2) a means of undertaking administrative procedures; (3) archives of past clinical and administrative information; (4) support for transactional activities, for example, a means of ordering tests; (5) communication channels in ‘handovers’ between agencies; (6) control mechanisms to enforce prescribed procedures for undertaking care; (7) sources of management information; (8) providers of audit information in the event of complaints and disputes; (9) a source of information for patients (in some cases); and (10) components in a database used for research, planning and policy development. More functions could no doubt be added. Some users have more of a ‘stake’ in some of these functions than others. The UK Government has recently issued a set of Information Principles ² to be applied to electronic information systems in all government departments and these principles are being adopted in the Department of Health’s strategy for e-health systems in the next 10 years. ³ Principle 3 is that ‘Information should be fit for purpose’. This raises a number of questions about the ‘purpose’ of the information in the context of electronic patient record systems. How is fitness for purpose to be achieved when there are many different stakeholders with many different purposes? Is it possible for one record system to be ‘fit for purpose’ for all the different demands made on it? If not, which purposes are privileged over others and what are the consequences for those whose purposes are not supported?

The EPICOg project ⁴ examined how electronic records supported the coordination of care across six health-care pathways in two local health-care communities in England, UK. Most studies of the impact of electronic record systems focus on a particular system, but in EPICOg we reversed the lens: we focused on the health-care task of frontline staff and asked how well the available electronic records assisted the undertaking of this task. The health-care pathways we examined typically involved patient journeys from general practitioners (GPs) to Acute Care and into Community Care, and our focus was on how the electronic systems supported the sharing of information between the different agencies and disciplines involved in patient treatment in each pathway. In each of the case studies, we developed a sociotechnical mapping of the pathway that represented the different work roles contributing to the pathway and the electronic record systems that supported these roles. In every case, more than one electronic record system served the pathway because different agencies made use of different systems. We took a purposive sample to cover the major clinical and administrative roles in the pathway across the different agencies involved, for example, GPs, hospital staff and community staff and conducted semi-structured interviews to examine (1) what electronic and non-electronic patient records were used and (2) how well they served the needs of patient care. In four of the pathways we also developed, in retrospect or by longitudinal study, an account of the design processes that created the electronic record systems. For this study, we undertook documentary analysis, interviewed the informatics staff and clinical staff involved in systems design and observed design team meetings.

As a result of these two data sets we had, for four case studies, data on the degree to which systems were ‘fit for purpose’ and data on how those systems were designed. The ‘fit for purpose’ data demonstrated that some stakeholders were better served than others by the systems in place. The rich account of the design history enabled us to examine what it was about the design process that led to the differences in services experienced by users. In this article, we will present one of the case studies in detail before discussing the generality of the results by reference to the other case studies and the broader literature. Further details of the methods used in the study will be given in the context of one particular case to be described below.

Electronic health record systems in the stroke pathway

One of the case studies was a study of the stroke pathway in Walsall, in the West Midlands. This pathway and the electronic record systems that served it had been in place for some years and there was a large amount of documentary evidence of the design history of the pathway and the electronic systems. It is selected here as the main case to report because we have a very detailed account of the initial design processes of the pathway and the electronic record systems that serve it and of all the modifications that have occurred since its implementation. A full account of this case study is provided in the final report of the EPICOg project. ⁴

Mapping the pathway

As a result of documentary analysis and a workshop with informatics and clinical staff, a sociotechnical system representation of the stroke pathway was prepared. This form of representation is based on the sociotechnical principle that undertaking a cooperative work task involves division of labour between a number of human agencies who each take responsibility for component tasks in the work process. Each of the human agencies uses technical artefacts to support their work. The need to coordinate work on the tasks means there are interdependencies between the human agencies and also with the technologies they use.^5,6 In this study, we developed a coarse-grained representation of each pathway that enabled us to identify the major sub-processes in the overall task, the way work was divided between different agencies and disciplines and the electronic record systems that supported them. To achieve these purposes, it was unnecessary to go into further detail, for example, to document the variety of routes through each pathway or to study the differences between prescribed pathways and the way the work was actually undertaken. Figure 1 provides a simplified representation of the main processes in the stroke pathway, the main agencies involved and the electronic record systems that served these agencies.

Figure 1.

The stroke pathway and supporting electronic record systems.

Although the nature and severity of a stroke could lead to many variants in the treatment of a stroke victim, there was a basic common shape to the stroke pathway. In most cases, patients suspected of suffering a stroke were admitted to the accident and emergency (A&E) department of the local general hospital. From here, they were scanned and transferred to a dedicated stroke ward as quickly as possible. If initial treatment was successful, the ward team turned their attention to rehabilitation to recover any capacities lost because of the stroke. In addition to medical and nursing staff, the team treating the patient could include physiotherapists, speech therapists and others. In this hospital, it also included a social worker to plan home care for the patient. When the patient was discharged, they were likely to be under the care of their local GP, social services and a dedicated community-based integrated stroke service unit that continued rehabilitation work with the patient. The pathway also stipulated regular monitoring of the patient’s condition in outpatient clinics.

In this example, every one of the agencies involved in the stroke pathway had their own electronic patient records serving their own needs. These systems included GP electronic record systems, a community-services patient administration system, a social services systems and a hospital system. In addition to the main hospital system, there were a number of sub-systems: a ‘whiteboard’ used by A&E, Picture Archive and Communication System (PACS) for X-rays and scanned images and a system used by physiotherapists. In the Walsall health community, the informatics department had deployed the Fusion system, which is a portal that enables many of these agencies to view the electronic records held by their colleagues in different systems, for example, community staff could view the hospital records of patients. The most significant development for the stroke pathway, however, was the development, within Fusion, of a stroke register. This was a separate database into which the records of all patients treated for a stroke were placed. As the patient proceeded through the stroke pathway, each agency treating them was responsible for updating the stroke register so that it contained a cumulative record of the treatment received by the patient. This record was accessible by the agencies engaged in the pathway through the Fusion portal and was the one system dedicated to supporting the entire process.

User responses to the electronic patient record systems

In order to assess the degree to which these systems supported the work of health-care staff in the stroke pathway, we conducted semi-structured interviews with clinical, managerial and administrative staff in the main agencies that contributed to patient care. A total of 10 members of staff were interviewed, including four GPs, the manager, a senior nurse and a physiotherapist from the stroke ward and the manager and two members of staff from the community-based integrated stroke unit. In addition, a ‘walk-through’ was conducted in which the research team visited A&E, the stroke ward and the community-services stroke unit to have discussions with staff about the electronic systems that supported the pathway.

The primary source of information available to the A&E staff when dealing with patients as an emergency was the whiteboard system where the emphasis was upon meeting the 4-h deadline for treating patients. The treatment of patients admitted to the stroke ward was logged on the main hospital system and on paper records kept by the patient’s bedside. Nursing staff reported that typically a patient was not entered into the stroke register until his or her discharge from the hospital. This was because the register required a structured and coded statement of the type of stroke and the treatment supplied and this could not be confirmed early in the process. The register also required exact statements of when specific activities took place, for example, the initial scan, to confirm that treatment met the key performance targets (kpis), laid down in the National Stroke Strategy. ⁷ The nurses reported that sometimes, the order of events was different from the National Strategy but the total process was within the time stipulated and, if the report was compiled later, the results could be presented in a way that meant the ward was meeting its targets. The physiologists also reported that they used their own system during the treatment of the patient and entered a structured summary into the stroke register when the patient was to be discharged. The view of all the frontline staff on the ward was that the stroke register was for management purposes. It was of no service to them as a tool in their patient care but constituted an extra data entry duty. It was a duty that needed care and attention because the categories in the system often did not fit the patient and their treatment and the data entered could have consequences for judgements about the performance of the ward.

When the patient was ‘handed over’ to the care of the GPs and the Integrated Stroke Services Unit in the community, the stroke register record was available to them. The GPs found it of little help and preferred the narrative account given in the electronic discharge summaries the hospital medical staff provided via Fusion when the patient was discharged. The frontline staff caring for the patient in the Integrated Stroke Services Unit also found it difficult to use the stroke register: the information was too summarized and fragmented into different categories to be helpful in devising a specific care plan for the patient. The rehabilitation staff preferred to meet their colleagues on the stroke ward to discuss how to continue the specific rehabilitation work that had been undertaken with the patient while in hospital. The community service team used their own electronic system and paper records left in the patient’s home as the means of coordinating their care of patients. They too confirmed their work by entering structured summaries into the stroke register at a later date. When they needed to obtain information from GPs or social services they often resorted to making fax requests.

The managers that were interviewed in the hospital and the community took a different view of the stroke register. The reports they could obtain of the aggregated records of patients being treated for strokes helped them monitor the performance of the service against the many targets they had to meet and enabled them to focus their efforts on areas where the service was at risk. However, they agreed that the record was of little service to those providing treatment for a patient. As a community service manager put it,

The way the Stroke Register is set up it is primarily for data management. We hope maybe at some stage later we can get something that may help the staff.

The design process

In exploring the history of the design of the systems supporting the stroke service, it became apparent that two different design processes came together to create the health-care service in place: the design of the stroke pathway and the design of the electronic patient record systems to support it. In 2001, the National Service Framework (NSF) for Older People ⁸ set out health service targets for stroke patients, and these were made more comprehensive in 2007 in the ‘National Stroke Strategy’, ⁷ which listed 20 ‘quality markers’ defining good quality care at every stage of the patient’s journey; from arrival at A&E to initial scanning and the administration of appropriate drugs, to the management of transfer of care to the community and monitoring after 6 weeks, 6 months and so on. In response to the National Stroke Strategy, Walsall created a dedicated stroke unit in the hospital and a dedicated stroke rehabilitation unit, the Integrated Stroke Services Unit, in the community.

The development of the electronic record systems to support stroke care was part of a continuous process in Walsall over the past decade. The Fusion portal was implemented in 2002 and access to databases steadily increased in the subsequent decade. The database in the stroke register, mounted in Fusion in 2009, was designed specifically to enable the management of the health community to collect data in relation to their responsibilities as defined in the National Stroke Strategy. As a result, the database is structured, coded and organized in a standard way that enables aggregation of records. This in turn means that management reports can be created that show performance in relation to the key performance indicators (kpis) for the service.

Given these design priorities, it is not surprising that the stroke register works as a tool for management and is not useful to those providing coordinated care for the patient. It has four consequences for frontline staff. First, they sustain their own systems, whether paper-based or electronic. Second, they have double entry duties to perform, into their own system and into the management system. Third, they regard the management system as monitoring their performance and they have to prepare the best account of their work with patients that they can even if it involves ‘workarounds’. ⁹ Fourth, they sustain or seek to develop other means by which they can share data with colleagues to support the coordination of care, whether that is in multidisciplinary team meetings, trading faxes or using other services available in Fusion, such as the electronic discharge summaries. Although, in theory, the stroke register could have been the master electronic record serving all the purposes of the many stakeholders in the stroke pathway, this has not been the outcome. In practice, a variety of systems are in use and, given the fragmentary way in which support is obtained, it seems unlikely that good quality, coordinated care is always the result.

One important feature of the history of the Fusion system is that since its inception, it has undergone continuous evolution and growth with access to an ever widening array of patient data and an increasing number of users. Many of the developments have come as a result of requests from frontline staff. As a result, for example, staff contributing to the stroke pathway can access information about their patients in a variety of places (scanned images in PACS, a summary care record from the GPs, medical discharge summaries from the hospital etc.). While the stroke register, the one system dedicated to serving the pathway, has not changed, a wider array of electronic services are supporting the pathway as a result of these ‘bottom-up’ design processes.

Meeting user needs in other pathways

The three other pathways studied in the EPICOg project where there is evidence of user experiences and an account of the design process, displayed similar tensions at work in meeting the needs of different kinds of users although the dynamics were different in every case. ⁴ The development of a Frail Elderly Pathway at Walsall ¹⁰ has also led to the creation of a ‘virtual ward’ database in Fusion of patients on the pathway. We were able to follow design developments in this case as they occurred and there were tensions throughout between the need to create records that could be aggregated to generate management reports to monitor progress against kpis and the need for records that would help staff coordinate care. In this case, the virtual nature of teams caring for patients in their own homes made the provision of useful records that could be shared by team members a very important objective to achieve and the design team are currently grappling with the task of meeting both frontline coordination needs and management needs. The use of electronic systems at present involves staff in a considerable amount of re-entry of data into several systems and one of the design aims is to reduce these duplications. In the diabetic retinopathy scanning pathway in Northamptonshire, a generic electronic patient record system was purchased which was specifically designed to support this pathway. It is also structured and organized to facilitate the aggregation of records to provide management reports in relation to key performance targets, for example, the percentage of diabetic patients scanned each year. The system is well geared to the transactions necessary to book appointments, undertake scans and analyse retinal images, but the multidisciplinary team contributing to the scanning pathway find it frustrating that it is difficult to customize the system to match their local and evolving circumstances. Also in Northamptonshire, we studied a local ‘refresh’ design process in community services that was utilizing the configuration capabilities of the general purpose electronic patient record system, SystmOne, to harmonize the record keeping procedures of many services in order to facilitate the sharing of information between them. In the middle of this process, the project was suspended because the Intermediate Care Service was reorganized to meet new pathway requirements to care for more patients in the community. The work of the informatics staff was redirected to produce records that would serve the management needs of the new pathway. In each of these three cases, there was a tension, albeit exhibited in different ways, between the needs of the frontline staff and the needs of management and it was the management need to have structured and coded records that could be aggregated that dominated the design process.

Discussion

Consequences of the design process for electronic patient record systems

A common feature of the electronic record systems examined in this study is that they prioritized the meeting of management needs rather than the needs of the local frontline staff that deliver patient care. This finding accords with the conclusions of Berg et al. in a series of papers^11–13 about the implementation of information systems within hospital settings in Holland. These researchers found that the rigid, pre-fixed organization and content of medical records did not recognize the ‘messy’, flexible and ‘fluid’ nature of work practice as clinical teams worked to test provisional diagnoses and solve the daily problems that come with treating patients.

Other researchers have noted the consequences of mismatches between the work practices of frontline staff and the electronic record systems they are expected to use. Harrison et al. ⁹ in their analysis of the unintended consequences of implementing electronic health records for computerized physician order entry (CPOE) provide a number of examples of ‘workarounds’ where health-care staff found it necessary to invent ways of circumventing features of the technology (e.g. system data entry requirements or authorization requests) that did not fit the health care they were delivering. Eason et al. ¹⁴ in a study of an electronic record system used in mental health found that clinicians did not feel able to report their patients’ conditions by ticking predetermined categories and instead used an open-ended ‘additional information’ box to provide a narrative account in which they could represent their conclusions about their patients in their own words. In a social services setting, Broadhurst et al. ¹⁵ also found staff engaging in workarounds to deal with problems with electronic record systems. In this case, the Integrated Children’s System (ICS) required social workers to complete an elaborate questionnaire following their assessment of the child’s treatment at home. Most of the questionnaire was irrelevant to each specific case and, to save time, social workers either left sections blank or ‘cut-and-pasted’ answers from other cases.

The common features across these cases are that the electronic record systems require inputs to predetermined fields of information that can then be aggregated to provide management reports. The fields of information required often cover all possible cases making them laborious to complete. The systems may also act as control systems, requiring users to confirm they have undertaken prescribed actions and met specified targets. The evidence from many studies shows that frontline users often find it difficult and time-consuming to report their work in this way and their ways of coping with the situation include limiting what they do with the systems and using other systems to record and communicate what they need to say about their patients. This includes sustaining other computer- and paper-based record systems and using other means of communication that support open-ended information flows, for example, faxes, telephone calls and face-to-face meetings. At best, these outcomes mean there is a lot of duplicated data entry and at worst it may mean the records used by management are incomplete and do not represent the treatment being provided for patients. It may also mean that important information about patients that is needed for handovers in pathways or for shared care may be absent from the records.

Alternative design strategies

There is now a wealth of information about the design routes that are necessary if the requirements of all stakeholders are to be met by the electronic patient record systems that are implemented. Many authors point to the need for a user-centred process that extends from early specification work to post-implementation adoption,^5,16,17 that recognizes that this process involves organizational learning, ¹⁸ and that it involves an evolution in the local sociotechnical systems requiring both the customization of the technical system to local needs and the accommodation of the technical system into revised working practices in the organization.^12,14,19 There is also a recognition that this ‘normalisation’ process ²⁰ in which the new technical capabilities are absorbed into normal working practices can take months or years.

The accounts of the design processes obtained in the EPICOg project show that these processes were largely absent when major shared electronic patient record systems were implemented. Coiera, ²¹ notes the ‘top-down’ nature of the design of these record systems. They tend to be created by software companies to a generic specification and implemented in health agencies by senior staff for whom standardization, control and management reporting are important considerations. In this study, it has been particularly striking that the national establishment of strategies for major pathways has fed directly into the design of the electronic record systems to support these pathways. As a result, there are two ‘top-down’ drivers that structure and organize the contents of record systems: the need for information to show adherence to each national strategy and the desire to pre-structure the record system. In design processes used outside of the health service, it is common for there to be a requirements capture phase at the beginning of the process during which studies are undertaken to determine the needs of all the different users and stakeholders. ²² There is no sign of such a phase in the design processes examined in EPICOg, and as a consequence, the needs of frontline staff are not directly addressed when the electronic record systems are specified.

What is also apparent in these case studies is that there are often ‘bottom-up’ local attempts to develop electronic services that are a better fit with the needs of frontline staff. These attempts are often made after the ‘top-down’ implementation and may involve the development of systems in addition to the main record system or additions to or reconfigurations of the main system. However, because of the constraints of the existing system, these ‘bottom-up’ developments may be difficult to undertake and limited in what they can achieve.

What then can be concluded about the development of electronic patient records that are ‘fit for purpose’ for all their users? The ‘top-down’ nature of the major systems development processes means that the specification of the system is to meet the needs of senior users and the purposes they give priority to. Does the evidence here mean that it is not possible for these systems also to meet the needs of the frontline staff delivering care? If user-centred sociotechnical design processes had been followed, it is possible that the resultant technical system would have been able to meet all user needs. Coiera ²³ has proposed, for example, that we need to adopt a middle-out approach that is neither top-down (that privileges management needs) or ‘bottom-up’ (that meets local needs but at the expense of being able to share information with others). In the context of the health-care pathways, a ‘middle-out’ approach might embrace all the needs of the health-care community that contribute to a specific pathway and who therefore need to coordinate their work with a patient. The tightly defined scope of such a system may mean it could meet all the needs of the user community.

However, it may be the case that the information needs of all the users involved in a care pathway are so diverse that one technical system cannot meet them all and that, for example, it is necessary to create one system that supports the detailed, real-time needs of frontline staff and another that collects abstracted and standardized information for management purposes. One danger of this approach is that it will perpetuate the need for health-care staff to enter the same data into several different systems, a process that is both prone to error and wasteful of their time. Avoiding this difficulty would put a premium on the widespread use of inter-operable systems that can automatically extract information from one system and input it into another.

Conclusion

This study shows that rather than meeting the needs of all stakeholders and users, current attempts to create electronic patient record systems to serve all needs actually serve the needs of management users and do not directly address the needs of frontline staff in health-care pathways who need to coordinate their treatment of patients. The consequences for frontline staff are that they have to find other ways of serving their information needs and they may be involved in entering the same patient data into several systems. An examination of the design processes shows that these systems are designed in a ‘top-down’ way in which the specification comes from strategic and management concerns. It is left to ‘bottom-up’ actions, usually at a later date, to try to create or modify systems to meet the operational needs of frontline staff. We cannot conclude that it is impossible to devise electronic patient record systems that will be fit for purpose for all users and stakeholders. However, we can conclude that a ‘top-down’ design process that privileges one powerful group of users over others is not likely to meet all needs, and this failure will have consequences for the users whose needs are not met and for the systems that do not serve them well.