Keywords

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

1 Introduction

This chapter explores the difficulties experienced in recent attempts to implement ‘packaged’ Hospital Electronic Prescribing and Medicine Administration (HEPMA) systems in NHS England. Though electronic prescribing was originally conceived as a pharmacy technology, it has become the occasion for integrating various other kinds of digital information (e.g. laboratory test results) at the point of care and for sharing this information across the care pathway. HEPMA in the United Kingdom (UK) has thus served as a stepping stone in developing hospital-wide infrastructures that directly support both diagnosis and care delivery. Considerable effort was needed to integrate HEPMA modules within the hospital information infrastructures and to interface them with external systems – and other parts of the health system, notably primary care. The difficulties besetting attempts to implement HEPMA as Commercial Off The Shelf (COTS) packaged software have highlighted the gap between the generic workflow models embedded in standardised COTS solutions (many of which were developed overseas) and the diverse practices of particular UK hospitals. Similar problems arose with previous attempts to implement packaged enterprise systems (ES), but were ameliorated through a protracted social learning (Sørensen 1996) process involving vendors, suppliers and various intermediaries. Comparing HEPMA and ES highlights the current immaturity of the HEPMA market. This is characterised by: the relatively embryonic linkages between HEPMA vendors and their potential market of users; users’ lack of understanding of the exigencies of exploiting packaged solutions; vendors’ limited understanding of user requirements and poorly elaborated strategies to address diverse user needs in generic solutions.

Stakeholders managing health systems in many countries have invested substantial efforts to implement and deploy electronic or ePrescribing systems (Mozaffar et al. 2014; Cresswell et al. 2013) to support prescribing decisions in health organisations (Aarts and Koppel 2009; Bates et al. 1998). The National Health Service (NHS) in England has similarly invested considerable resources in these systems. It describe these systems as:

The utilisation of electronic systems to facilitate and enhance the communication of a prescription or medicine order, aiding the choice, administration and supply of a medicine through knowledge and decision support and providing a robust audit trail for the entire medicines use process. (NHS Connecting for Health, England)

1.1 The UK Context for Hospital Electronic Infrastructures

Health care in the UK is primarily provided through the publicly-funded National Health Service (NHS). With over a million employees, the NHS is an exceptionally large and complex organisation (Hibberd et al. 2016). There are differences between the NHS in each of the devolved administrations (England, Scotland, Wales, Northern Ireland). This chapter focuses on developments within NHS England, which is by far the largest. Hospitals are run by regional health authorities, originally known as Primary Care Trusts, with primary care delivered by multiple independent General Practitioners. Despite a very long history of hospital computerisation stretching over 60 years, the development of hospital electronic infrastructures was seen to be held up, inter-alia, by the fragmentation of procurement between hospitals and trusts. Repeated attempts to improve integration culminated in a major national initiative: the National Programme for Information Technology (NPfIT) in which, as well as creating a central transaction processing ‘Spine’ (Hibberd et al. 2016), selected software applications were to be centrally procured and implemented in NHS hospitals (Sheikh et al. 2011; Robertson et al. 2011). This initiative however encountered numerous problems and, as a result, the Department of Health instituted a change of direction from a ‘centrally driven strategy of replace all’ to ‘locally chosen and implemented systems’ (Robertson et al. 2011; Sheikh et al. 2011).

NHS calls to improve the quality, safety and efficiency of healthcare, coupled with substantial financial support, have provoked widespread interest in the timely implementation of HEPMA systems in UK hospitals (Buntin et al. 2011; Black et al. 2011; McKibbon et al. 2011) and attracted a number of UK and overseas suppliers. Electronic prescribing is already well established in England’s primary care (Avery et al. 2007; Fernando et al. 2004; Hibberd et al. 2016). Over the last decade, several attempts have been made to implement HEPMA systems in secondary care. In 2013 only 13% of hospitals had hospital-wide HEPMA systems (Ahmed et al. 2013). This is however expected to rise rapidly as a result of the £500 Million Safer Hospitals Safer Wards technology fund launched in 2013 and a policy target of complete implementation across the NHS by 2020 (Carter 2015). The move towards local selection of systems has resulted in hospitals being faced with a range of options, none of which are however currently perceived as fully meeting the needs of the English market (Mozaffar et al. 2014).

Whilst the first generation of HEPMA systems was developed within hospitals, today we see a marked shift away from home-grown solutions towards COTS ‘packaged’ software (Mozaffar et al. 2014). There are a number of reasons for this move. These include the very substantial costs associated with developing and maintaining bespoke systems (and the stalled progress and anticipated failure of a flagship project to jointly develop an integrated solution within/for English hospitalsFootnote 1), the perceived advantages of packaged solutions (in terms of functionality/price, dependability, maintenance) and problems with limited interoperability between providers (Schiff et al. 2003; Westbrook et al. 2012). However, standard COTS solutions, built around generic models of the user organisation, may be far removed from the workflows of particular adopter organisations, necessitating a considerable effort to configure and customise software or to adjust local working practices (Pollock and Williams 2008). Despite these investments, the HEPMA market in England is faced with a great deal of uncertainty and is undergoing rapid change and evolution (Aarts and Koppel 2009; Mozaffar et al. 2014). As well as intense policy pressures and incentives to adopt HEPMA, hospitals are confronted by the lack of maturity of current supplier offerings, their limited tailoring to the English context, the diversity of systems and lack of knowledge about the available options. These factors all contribute to the challenges that hospitals face in procuring, implementing and realizing the benefits of these systems (Wolfstadt et al. 2008; Bates et al. 2003; Cresswell et al. 2013; Mozaffar et al. 2014).

In this chapter we examine the problems that have arisen in the supply, procurement and implementation of packaged HEPMA solutions. We explore the reasons for this in terms of the state of development of the HEPMA market – encompassing the strategies and capacities of both vendors and adopters. Our analysis brings to bear insights from the Biography of Artefacts and Practices (BoAP) perspective (Pollock and Williams 2008) that emerged from our previous long-term programme of research into the evolution of the Enterprise System market. BoAP draws also upon recent related analytical advances in relation to the conceptualization of information infrastructures and to the formation and maturation of technological fields. As we outline below, this suggests that analysis of the development of information infrastructures (IIs) needs to engage with the exigencies surrounding technology supply and the increasing resort to commercially-supplied solutions. For example (Koch 1997), highlighted the choice between “bricks and clay” when building corporate IIs: between procuring integrated solutions or configuring together large numbers of small infrastructure components. The latter offers greater scope for adopter organisations to exercise choice in the selection of components and (because they tended to be technologically simpler) greater potential influence over their design. Integrated solutions offered less flexibility but transferred the integration challenge to the supplier. They could also operate as a platform onto which other offerings might be erected (Koch 2007). This in turn suggests that theories of the installed base need to go beyond a focus on the evolution of individual IIs and take on board the complex sets of relations linking multiple vendors and their adopter communities. We will explore this conceptual framework in our Discussion.

Methods

This chapter draws upon an extended national research programme investigating the implementation and adoption of HEPMA systems in English hospitals funded by the National Institute for Health Research (NIHR). In this chapter we re-examine these findings in relation to the goals of this book to understand the development of health infrastructures and examine the influence of the installed base.

We draw particularly upon a study of the current status of the English HEPMA market (Mozaffar et al. 2014, 2015; Cresswell et al. 2013; Crowe et al. 2010). We collected qualitative data from both suppliers and adopters of various HEPMA systems in England. Data collection, undertaken over the period October 2012 to October 2014, involved a combination of semi-structured interviews with staff of six English hospitals adopting HEPMA and of four system vendors, ethnographic observations (totalling 21 h) of user groups and hospital practices, a supplier round-table discussion, and collection of publically available documents. Interviews and data analysis were conducted in tandem – research foci and theme emerged inductively over a number of iterations. Table 9.1 summarises the data sources and collection methods.

Table 9.1 Data collection methods
Full size table

2 Understanding the Uneven Success of HEPMA

Overall there had been a relatively low uptake of these products by English hospitals and implementation has been slow (Mozaffar et al. 2014). This market was undergoing rapid cycles of change with many suppliers entering and offering a wide range of products in terms of functionality and architecture. Our analysis suggests a range of explanations for the current uneven growth and variable success of HEPMA systems in England, rooted in suppliers’ strategies and adopters’ current reactions to the technology and the market.

2.1 How HEPMA Systems Are Constituted: Extension of Non-clinical Systems

Our earlier study on the spectrum of available HEPMA systems in England identified a wide range of systems including 13 hospital-wide applications and a range of specialty systems in implementation or use across English hospitals (Mozaffar et al. 2014). Nine of these systems were developed outside England and were introduced into the English market over the past decade.

We studied four HEPMA systems. None were initially designed as HEPMA systems.

One of the products in our sample involved a pharmacy stock control system, which was extended with the addition of HEPMA functionality including what is sometimes described as computerized physician order entry (CPOE) and computerized decision support (CDS). This medication-focused system offered basic integration between the two modules but it was not a fully integrated hospital information system. This was a standalone application that covered inpatient needs, discharge prescribing, and pharmacy stock control. Interfacing strategies were used to connect this system with other systems used in hospitals. During this the course of this study, plans were made to extend this system by designing and developing the discharge prescribing system.

There were two multi-modular integrated ‘systems’, which arose through the expansion of insurance or billing systems for U.S. hospitals into integrated hospital-wide systems with the additional modules covering various areas such as inpatient and outpatient prescribing, electronic medical record, clinical imaging and laboratory, linked into an integrated whole with one underlying database. The final system was initially designed as an electronic patient chart system and then expanded over time to include a scheduling system and HEPMA modules (initially only inpatient prescribing, though during the course of this study, plans were made to extend this system by designing and developing the discharge prescribing system). Thus, we saw that the promotion of HEPMA functionalities had pulled in product offerings and component technologies from different sources with different historical paths, which resulted in packages with rather different architectures and configurations.

Members of adopting organisations noted that the two U.S. ‘integrated systems’ emerged by adding multiple modules to what was originally a billing/insurance management system, formed around calculating the costs of drugs and saw this as an important factor in the problems in implementing and using these systems. They often described these as ‘non-clinical systems’, to draw attention to the fact that they arose as an extension of an already existing product with a different focus.

…over the years they have progressed from the original billing system or pharmacy stock control systems to now be basically sold as EPMA [ePrescribing and medication administration] systems …. It’s just a billing system… the funding for the hospital was gained raising bills from the patients they treated. So they needed a full audit trail to know what went on with the patient so they can charge the right amount of money. So again they were originally billing systems but they started to tag on clinical functionality on them (Adopter Interview, P1)

These users questioned the clinical merits of offerings that were not initially designed as clinical systems, but emerged by adding HEPMA functionality to non-clinical systems:

…in recent times there has been a lot more influx on the market. The EPMA systems are generally changing to focus on the clinical functionality… but whether you could say that the system is totally designed around the clinical users interface is a debatable question… if you want something to be a clinical tool then it should be clinical enabling and not something like clinical disabling … do we want to collect clinical information to make clinical judgment better or do we want it to manage the process that we are doing when we are trying to treat patients (Adopter Interview, P1)

The non-clinical origins of these systems were seen as resulting in interface designs and workflows that were not centred around patient care pathways. A clinician, using the HEPMA system built around a stock control system, felt that system design might usefully take a different starting point:

…our starting point is not just prescribing a drug, our starting point is actually saying you come in with this condition therefore your pathway is this. (Adopter Interview, P2)

We observed a wide range of HEPMA systems shaped by the history through which they were constituted. In general the trend was to add HEPMA functionalities to already existing (non- ePrescribing) systems or to adapt existing systems to accommodate the newly required functions. These systems had inherited some of the characteristics of their source system and this affected their usability. Despite significant technical differences between the solutions, we encountered homologous problems. In particular, in the process of expanding the scope of systems, suppliers seemed to have underestimated the complexity of HEPMA as a clinical system and the particularity of user activities (a failing that closely mirrored criticisms of early ES offerings two decades earlier).

2.2 Adoption of Systems That Had Been Developed Outside England

Mozaffar et al. (2014) highlighted that more than half of the systems available in England originated in other countries. Respondents attempting to implement these systems in English hospitals frequently drew our attention to this point which they saw as representing a major problem, as:

…their [US] way of working is very different to the U.K. based working (Adopter Interview, P2)

The lack of alignment between ‘foreign’ supplier offerings and UK hospitals’ internal processes and needs was seen as a major barrier to implementing these systems.

…[Product Name] is a U.S. system and it works very well for a U.S. hospital, but some things in the U.K. are quite different specially around medicines practices and we are still working with [Supplier Name] to see if we can get some of their products changed to better reflect our workflow (Adopter Interview, P4)

This became clearer when adopters expressed a desire to see England-specific solutions being developed around ‘generic’ English hospitals’ needs.

In terms of medicine there are a number of issues we have with [Product Name] and most of these are issues that aren’t just local to [Place Name] they’re issues that we think are indicative across other U.K. sites… (Adopter Interview, P4)

Well a lot of it is U.S.-based but they have to customize it to the U.K. market because we are different, so I mean that’s why we have had a number of meetings with them and with the [Product Name] user group to explain, you know, we’re different and they know this but we keep having to remind them. (Adopter Interview, P5)

Overseas suppliers emphasized that they were aware of the differences between the two countries and highlighted that they had particular ways of catering for these needs, in particular by offering England-specific versions of the application.

An interface to a formulary vendor for medications is standard in the U.S. but we obviously had to go above and beyond knowing that there are different requirements, there’s different information on drugs in the U.K., you know, how they’re numbered and tracked is different, you know, DM&D [Dictionary of Medicines and Devices – unique identifier given by NHS] number does not exist in our U.S. software (Supplier Interview, P6)

However, despite pressure from hospitals and end-users, participants in user group meetings complained that many suppliers had been slow to create England-specific solutions.

Some vendors appeared reluctant to invest the significant resources needed to implement these changes, particularly where they only had a small presence in the English market. Other suppliers (and particularly those with a stronger foothold in and expectation of a larger share of the market) were deploying strategies to create England-specific versions of the products. However the challenge seemed to be more substantial than they had anticipated. As they began to implement these systems in English hospitals, they were confronted by growing numbers of requests to adapt the systems to local practices and preferences, which forced them to take on board multiple cycles of modification to their products. However at the time of the study, with only a handful of hospitals having implemented their system, the majority of these systems were in the early stages of being ‘anglicized’. Hence, what we observed were products in their infancy with respect to English-specific requirements which arose as a result of differences in national systems and policies (e.g. between private insurance-funded health care in the United States of America [USA] and the public-funded UK NHS) and particular hospital practices (e.g. differences in discharge processes). Some of these overseas suppliers had prior experience and knowledge of the English market. However they tended to develop their English version as an extension of their current non-English HEPMA system. We interviewed one supplier which had had live implementations in England of an older product for over a decade, but which was also offering its new HEPMA product to the English hospitals.

…at that point after several hospitals [in the USA] were up running live and stable with the software that’s pretty much the version that we took as our initial like U.K. kind of starting point… And basically where we started there were certain items that we knew, we knew were going to be different, for example in the U.K. wait lists, 18 week waiting, CDS reporting those are like three kind of big areas that, you know, don’t exist in the U.S. [American] software so we literally had to start with some of those areas and we just started from what we knew the requirements were in the [Old Product Name] environment and fit those to the, you know, the [New Product Name] product, you know, the new version.(Supplier Interview, P7)

NHS England is seen as a target for many overseas suppliers from Europe and the English-speaking world, though it is only a secondary market for many U.S.A. producers. It is not uncommon for systems to be initially developed for local customers within a national market before being redeveloped for the international markets (Pollock and Williams 2008). As a result, system architectures may be sub-optimal for the English market. Users who were attracted by the powerful functionalities offered by non-English systems found themselves caught in an unanticipated and slow process of joint system redevelopment with the supplier in a protracted implementation. Suppliers entering the English HEPMA market found themselves needing to address in a compressed timeframe: (1) the NHS policy context and generic English hospital’s needs; and (2) the widely differing specific needs of individual adopting hospitals. This in turn called for some way of prioritizing user requirements and selectively developing solutions.

2.3 Suppliers’ Configuration and Customization Strategies

Suppliers of packaged organisational technology solutions need to develop effective strategies for addressing the diversity of user demands for modifications and new functionality. Experienced suppliers had learnt the need for strategies to cater for increasing diversity as their user-base grew in size. This required them to develop a strategic vision for their software product and its longer-term development, to keep control over the overall architecture of their product as it moved forwards, in the face of the plurality of adopter demands. This allowed them to decide which change requests they would entertain, which changes they would be unable to support, and which changes could only be undertaken by end-users themselves (Pollock and Williams 2008).

In order to retain overall control over architecture in the face of diverse users, software packages are designed around a basic set of organisational functionalities - a ‘generic kernel’ (Pollock and Williams 2008). Libraries of ‘templates’ are built upon this kernel, catering for commonly encountered workflows and practices. Such software packages are ‘user-configurable’, meaning that they incorporate pre-programmed features, which can be selected to meet the needs of various environments through setting up parameters rather than rewriting program codes (Davenport 2000). However if the range of pre-defined configurations is limited and does not meet particular user needs, adopters may be forced to seek to alter the programme. Issues then arise about whether this will be incorporated into the package (with programming and testing imposing a significant effort and expense for the supplier) or whether it will be an ad-hoc customization (which the adopter may have to pay/take responsibility for). If too many local customizations are made by an adopter, reliability may suffer and upgrades may become difficult to implement (Fincham et al. 1995).

In the case of HEPMA systems in England, suppliers were pursuing various product development strategies but had made very uneven progress in developing their strategies. Some had rather rudimentary arrangements for incorporating user requirements into the system. Others had begun to develop a more organised approach to assessing change requests, generalizing needs and building system enhancements. Moreover, at this stage, most HEPMA solutions in England seemed to be ‘too limited’ in terms of the configurability they offered (the range of pre-programmed options that the user could draw upon) in relation to the diversity of adopter practices and requests. In our observation of user group meetings, we frequently encountered instances where the majority of users asked for a particular configuration that was not offered by the system.

2.4 Localized Adopter Practices Versus Generic Systems

The healthcare context is distinctive in terms of the enormous diversity in specific hospital procedures and individual ways of working. Despite the existence of professional NHS policy guidelines, each NHS hospital is a separate legal entity. It has its own local practices and standard operating procedures. So in performing the day-to-day activities, rather than merely complying with a set of professional guidelines, hospital employees are also expected to abide by the localized operating procedures. This was seen as one of the most significant factors leading to the complexity of HEPMA systems uptake in England. Interviews with users indicated that there were no pre-defined best practices in the health sector because there was still no consensus about what is best. Suppliers, though aware of the differences in localized practices, emphasised the need to introduce standards to the sector.

…every NHS trust in the country considers themselves to be different… if you give them a standard OBS [output based specification]… they make it unique to them… every question [on the OBS] has a nuanced, has a little twist in there… (Comment in supplier event)

The implementation of generic HEPMA systems foregrounded these variations in practices. Operational differences between hospitals became visible, which had not previously been evident. The lack of standard practices became particularly apparent in implementing systems with higher levels of integration and complexity compared to standalone applications. The diversity of practices was not only hospital-specific. Practices varied between departments and specialties, making it difficult for standard applications to cater for the needs of all wards within a hospital.

2.5 ‘Untamed’ Adopter Demands?

Adopters emphasized the particularity of hospital procedures and practices. However their responses highlight the lack of adequate awareness amongst users about the exigencies of packaged applications and in particular the trade-off between the costs of customization versus adapting processes to functionality in the package. This resulted in users having what others portrayed as rather unrealistic, indeed ‘untamed’, expectations of packaged HEPMA solutions. In this respect, users’ expectations from packaged solutions were more in line with what might be expected from bespoke (tailored) information systems. Thus many users expressed a desire for local practices to be directly incorporated into the system.

…we are all doing the same job but we are managing the processes differently, so when we implement technologies we all want to implement it in our own way (Adopter Interview, P1)

…some of the changes we are asking [Product_Name] for are things that individual Trusts [hospitals] do… (Adopter Interview, P4)

Given these expectations, hospitals felt they should have direct links with the vendor company to develop their specific requirements.

So companies I’ve worked for before have always had […] a user that partly worked in the Trust [hospital] and partly worked for them [in the vendor company] so that they are a current user. So they knew the problems so that they could take that back to the [vendor] company and already start to look at ways of sorting that out. (Adopter Interview, P2)

Suppliers referred to escalating adopter expectations as “over-aspirational functional specifications” (Comment in supplier event). They also highlighted the need for early alignment of user expectations and actual system purposes and functions.

…aligning expectations if that managed earlier then everyone is on the same page to begin with… (Comment in supplier event)

A further problem arose from insufficient knowledge about what the actual needs of hospitals were. Both users and vendors expressed concerns about uncertainty surrounding users requirements.

…electronic prescribing and medical administrations are quite complex. Until there is kind of more experience or hospitals on these systems it’s harder to get some kind of consensus on what are the features and what isn’t. (Adopter Interview, P4)

We further noted a lack of knowledge in English hospitals of both HEPMA solutions and of the implementation and use of packaged applications more generally. One issue that, will be the subject of a future paper, concerns the limited circulation of experience in IT procurement and implementation within the NHS. Many of the staff who played a central role in a particular hospital implementation then went back to their health professional role. Apart from a small number who moved over to work for technology suppliers, there was no ready way of carrying forward and exploiting this expertise within NHS professional structures.

3 Discussion

Vendors of HEPMA applications are investing significant effort in expanding their market base internationally. Hospitals in England, in turn, appear keen to implement systems that have the potential to deliver the widely anticipated benefits of such systems. We found that despite this willingness from both sides, for the various reasons considered above, progress with implementing these systems in England is proceeding slowly. To understand the underlying reasons we have developed a broader analytical framework based upon this work and our earlier research into the evolution of Enterprise Systems.

3.1 Analysing the Long-Term Evolution of Information Infrastructure

The concept of installed based, which unites the contributions in this volume, was coined to capture tensions arising in the development of electronic Information Infrastructures (IIs) – defined as systems of (computer-based) systems that support an increasingly wide range of tasks across an ever-more extensive base of users. Efforts to standardize functions around specific existing users and uses may impede the extension of an infrastructure to new users and uses (Hanseth et al. 1996). This concept has informed various development and implementation strategies to prevent lock-in around existing configurations and provide flexibility to allow new functionality to be taken on board (Grisot et al. 2014). The II discussion, however, has largely been at the level of the ‘cultivation’ of individual organisational information infrastructures.

Our research into the development and implementation of Enterprise Systems (ES) and other corporate information infrastructures (Pollock and Williams 2008) suggests that we need to analyse these developments not just at the level of particular infrastructures and organisations but also across communities of vendors and their adopters (Koch 2007). We have studied the development and implementation of these kinds of highly complex technologies over three decades (Pollock and Williams 2008). This extended timeframe of enquiry has provided insights into both the evolution of these technologies and the arrangements for their development and implementation. In the 1980s, initial attempts to supply what were then known as Computer Aided Production Management (CAPM) systems as COTS packaged solutions were characterized by sharp mismatches between supplier offerings and user needs. Our subsequent research allowed us to observe how these offerings have ‘co-evolved’ with their user communities. ES Suppliers have learnt how to develop and exploit close links with their adopter communities to develop generic solutions that can be used and be useful across a wide range of adopter organisations. Our insights derive from extending the scope of empirical research not just laterally, across arrays of vendors and adopters etc., but also along an extended ‘longitudinal’ timescale (Pollock and Williams 2008).

CAPM refers to the set of technologies that resulted from a UK government initiated program during the 1980s. By adding new functions onto existing Manufacturing Resource Planning (MRP II) technologies, CAPM sought to offer integrated packaged solutions to production control and coordination tasks. It was seen as a stepping stone towards Computer Integrated Manufacture (CIM) (Williams 1997; Webster and Williams 1993). In response to the promotion efforts of government (the Department of Trade and Industry, the Science and Engineering Research Council) and other influential actors such as consultants and vendors, a large number of suppliers from different fields were attracted to offer “CAPM” solutions (Clark et al. 1992; Newell and Clark 1990). The availability of government funds encouraged many vendors of MRP II and related systems to project their products under the name CAPM. This resulted in a swarming of supplier offerings around the concept of CAPM, with functionalities being added to existing products to fulfil the expectations of policymakers, pundits and adopter organisations (Webster and Williams 1993). However attempts to implement CAPM packages ran into sharp difficulties which resulted in up to 50% of systems being abandoned. The most immediate features were:

  1. 1.

    An acute lack of fit between the presumptions underpinning the packaged solution and the circumstances of particular adopter organisations; and,

  2. 2.

    The CAPM products launched initially were often still-unfinished with various new functionalities added that were poorly integrated (Webster and Williams 1993).

As a result, would-be adopters found themselves drawn in to an unplanned collaboration with suppliers in a struggle to get these standard packages to work in the adopting organisation’s particular circumstances. In this process we saw a more or less radical reworking of the solution, with some functionalities being abandoned and new functions emerging.

The immediate result of this accelerated development and diffusion was the launch of products that were often immature and unstable (Webster and Williams 1993). In the subsequent decade however a new generation of ERP and ES systems emerged, building very directly upon these applications. They incorporated the underpinning philosophy and many technical elements of CAPM and its predecessors – in particular the idea of connecting multiple functions across the enterprise with an integrated and interoperable system – and were also heralded as a stepping stone to CIM (Xue et al. 2005; Pollock and Williams 2008). The concept of ERP began gaining momentum through the 1990s, particularly as firms renewed their systems to avoid anticipated ‘millennium bug’ problems. A range of successful products emerged. Some (e.g. JDEdwards, Peoplesoft) fell by the wayside as the ES product market restructured, leaving global giants such as Oracle and SAP in dominant positions. As a result we find that today SAP’s R3 system has been adopted by the majority of FTSE 100 and Fortune 1,000 firms CIM (Pollock and Williams 2008).

The success of ESs built upon several decades of experience with its predecessor technologies (stock control, production control, Material Requirements Planning [MRP], MRP II) (Williams 1997). There are two crucial features underpinning these developments:

  1. i.

    Successful suppliers of packaged ES solutions had, over time, elaborated sophisticated generification strategies, through which they elicited, aligned, sifted and sorted the diverse requirements of their communities of adopters

  2. ii.

    Permanent linkages were established within the ES community – in particular through user-clubs linking suppliers and adopter communities (Mozaffar 2016).

The subsequent success of ERP/ES was rooted in the mutual adaptation of both adopter organisation practices/processes and packaged features (Hong and Kim 2002; Leonard 2011).

3.2 Analysing the State of the Technology Market/Technology Field

These considerations suggest that if we wish to understand difficulties encountered in HEPMA procurement and implementation, it may be helpful to analyse the evolution and current state of development of the HEPMA market in England, drawing parallels and insights from our studies of the ES technology field.

The idea of the maturation of technology fields can be traced back to classic 1970s studies by Abernathy and Utterback who proposed a three stage model (Abernathy and Utterback 1978). In an initial experimentation phase, we see the rapid entrance of diverse and changing products into a new market, the ultimate direction of which is still unknown. As the market and the applications of the technology become better appreciated by suppliers and adopters, in the next, transitional phase, the market begins to converge around what is known as a ‘dominant design’ with broadly comparable characteristics. In the mature phase, as dominant designs become established, we find concentration of the market around a smaller number of products with higher performance. The focus of supplier efforts shifts from differentiation to enhancing performance and lowering costs within an existing product paradigm. Similar stage models have been advanced to analyse the cyclical evolution of product markets including the software product life cycle (Agarwal and Tripsas 2008; Fincham et al. 1995). ‘Institutionalist’ organisation theorists have described the homologous processes by which new ‘technological fields’ (Pollock and Williams 2011; Swanson and Ramiller 1997, 2004) emerge and take shape by establishing consensus amongst communities of vendors, consultants and adopters. The establishment of a technological field greatly reduces uncertainties about the characteristics of a technology both for vendors and customers. They are coupled with the emergence and stabilisation of classifications of technologies and criteria for their assessment. Here we reject simplified (e.g. technology management) approaches which take for granted the formation of technological fields and their progression, once established, to maturation and seek a more dynamic, processual account of the evolution of technological fields which explores how boundaries and names may be recast and maturation may be reversed by the emergence of new technical solutions or business models (Fincham et al. 1995). In the ES field we saw the emergence of new kinds of knowledge intermediaries – industry analysts like Gartner Inc. – which capture and collate community experience to advise adopters about available software products and their vendors. By overcoming the asymmetry of access to information between vendor and adopter this provides the ‘knowledge infrastructure’ needed for the operation of the IT markets for these complex software products whose capacities and fit to the needs of particular adopter organisations cannot be readily established, for example, by inspection (Pollock and Williams 2011, 2016).

3.3 Is the HEPMA Market Replicating the Path of ERP?

Our study of the evolving nature of the HEPMA market in England, exhibits some interesting and insightful parallels with the earlier history of integrated systems in the commercial sector: ERP and its predecessor CAPM Systems. This drew our attention to (i) how vendors developed generification strategies to create generic solutions that could bridge to a wide-range of adopter contexts, (ii) the development of multiple webs of relations between vendors and adopters through which knowledge about user requirements and vendor offerings could be exchanged, and (iii) how new knowledge intermediaries emerged to advise adopters in their procurements. We were able to assess the extent to which comparable arrangements had emerged in the UK HEPMA market.

3.4 The English HEPMA Market Is Still in an Emergence Stage

The comparison with the ES case suggests that the HEPMA market in England is still in an early stage of emergence/growth. Various suppliers have entered the market with each one having a relatively small number of implementations in progress (Mozaffar et al. 2014). The HEPMA market exhibits a high technical variety in development of products with diverse features and forms. These products originate from different geographical and technical backgrounds and are offered in different forms with dissimilar features and functions. This would suggest that their technological features have not yet become de facto standards or ‘dominant designs’ (Agarwal and Tripsas 2008; Utterback 1974) in the English market. In this market there is still no accepted architecture, established use practice or evaluation criteria to guide and constrain the efforts of suppliers and adopters (Sheikh et al. 2014). This also contributes to diverse supply strategies and use of numerous terminologies and definitions all of which act as barriers to smooth and rapid adoption.

The lack of shared understanding creates a problem for potential adopters in understanding the options available (Helm and Salminen 2010; Jalkala and Salminen 2010). It also creates uncertainty for vendors about customer requirements. End user requests are typically more diverse than anticipated. Suppliers have difficulties in responding systematically to this diversity (Agarwal and Tripsas 2008; Adner and Levinthal 2001) given this lack of clear ‘preferences’ (Clark 1985). The market remains in the experimental stage with new products and suppliers still emerging.

Suppliers had adopted different approaches to respond to the diverse needs of the English market. On one end of the spectrum were those suppliers which had already grown and stabilized their products in other national markets. Some offered their international products with only minor modifications to cater for the English hospitals’ needs. Others had embarked upon concerted attempts to re-design and develop their applications around the particular needs of English hospitals. When we contrast the HEPMA and ES market today, we can see that HEPMA vendors had not yet developed ‘generification strategies’ (Pollock and Williams 2008) in relation to establishing mechanisms to decide which of the diverse array of user requirements would be taken on board in their core product but instead tended to respond to requests in an ad-hoc manner. Conversely, since HEPMA systems did not yet incorporate sufficient libraries of common workflows that the user could switch on in configuring the system, rather than by rewriting code, adopter organisations felt compelled to submit customisation requests.

The lack of consensus amongst adopter and vendor communities and domain experts indicates that the technological field is still developing. The field has not yet developed structures and actors to mobilize consensus and set the boundaries of technology (a role carried out in other sectors by industry analysts like Gartner (Pollock and Williams 2011), and by entities such as the Health Information Technology Standards Committee and certifying organisations). These could help reduce procurement uncertainties in various ways: enabling development of generic cases for innovations, creating a space for comparison of different artefacts and suppliers, and helping users come to more realistic and realizable expectations about HEPMA functionalities and its effective use.

3.5 Conclusions

We identified several tensions in design and implementation of HEPMA systems in England. The problems can be sorted into six categories: (1) products derived from non-clinical systems proved problematic in England’s increasingly patient-centred health system; (2) the process of Anglicization of systems by suppliers from other countries of origin needs to be given sustained attention; (3) the healthcare sector has particularly diverse needs and practices which run counter to the goals of generic applications; (4) current products are limited in configurability in relation to the diversity of adopter requirements which results in escalating customisation requests (5) rather than respond in an ad-hoc manner to proliferating customisation requests vendors need to develop generification strategies (perhaps through user groups) to sift, sort and prioritise these requests to keep control over the strategic development of their product and (6) adopters have little awareness of the exigencies of exploiting COTS solutions resulting in ‘untamed’ demands from packaged applications.

We conclude that effort to promote HEPMA arguably attracted a range of relatively unfinished solutions into the market prematurely. In this process neither the developers nor the adopting organisation were prepared for the complexities of matching generic products to a diverse adopter context. This echoes elements of previous UK experience with CAPM/ERP systems. We infer that, although policy incentives can be effective in achieving adoption (Aarts and Koppel 2009), they may also have accelerated premature purchase of immature solutions. This suggests a need for a gradual move in the market for such immature technology. So instead of suppliers seeking rapid large-scale implementation of their products, they may need to take a more deliberate and purposeful approach in developing their products for new markets, which will involve partnering with specific institutions until many of the kinks are worked out. Also adopting hospitals need to be more clear and realistic in expressing their needs in relation to packaged applications. Furthermore, more effective mechanisms are required to bridge the gap between the generic standardized technological solutions and the particularity of national and local needs. In order to achieve this, suppliers must not underestimate user diversity. They need to develop strategies to deal with such diversities in the market. At the same time the adopting organisations need to become pre-aligned to these packages and around views within the Health Service of best practice. In short, what is needed is a co-evolution of organisation and technology together. Public policy might usefully be geared towards promoting – and allowing time for – such extended engagement (though competitive public procurement/tendering arrangements may not facilitate this kind of supplier-user engagement) (Lee et al. 2015).

Finally, we suggest that HEPMA is not the final stage in the process of developing health IIs. Though conceived as a discrete, pharmacy technology, HEPMA systems linked the pharmacy to the ward, and went beyond the point of prescription to the administration of medicine throughout and after their hospital stay. As a result HEPMA systems involved a wide range of stakeholders across the hospital junior doctors, consultants, nurses across different specialities, with their various work practices and requirements (a point which becomes crucial when we consider the difficulties catering for diverse ‘end-user’ requirements). HEPMA moreover became – at least in the historical trajectory of English hospitals - bound up with the integration of a growing range of digital information services (most immediately laboratory results) at the point of healthcare delivery throughout the hospital. Once introduced, these packaged HEPMA solutions became the starting point for the continued extension of systems and their integration with other systems within the hospital and beyond (for example discharge letters to general practitioners). HEPMA systems are becoming core components of hospital health information infrastructures. We suggest that HEPMA has served as a stepping stone to information integrated health care (in a way that parallels the earlier history of enterprise systems in industrial organisations (Fleck 1988)). Our research has identified a range of immediate problems associated with development, procurement and implementation of HEPMA systems in the English healthcare system. Our comparison with the prior experiences with ES allows us to see these as part of a longer-term social learning process (Sørensen 1996). To overcome these challenges, vendors and adopters must understand their current and potential user-base and develop strategies to address the heterogeneities and multiplicities of adopter requirements and practices. This diagnosis in turn provides important lessons for attempts to build health information infrastructures. England, as one of the leading countries in Europe in adoption of such technologies, can be seen as a site of innovation in which the market and products are being shaped simultaneously. Similar patterns in terms of difficulties of HEPMA adoption have been observed in many countries (Mäkinen et al. 2011; Aarts and Koppel 2009). However England is one of the leading countries with the highest rates of HEPMA adoption (Aarts and Koppel 2009; Van Dijk et al. 2011; Schoen et al. 2006), and other countries may benefit from analysis of UK experiences.

The large scale of the NIHR-funded research programme allowed us, rather exceptionally, to study the implementation of a range of supplier offerings in multiple sites and over an extended period. We identified sharp echoes between these, still emerging, experiences and findings from our own personal research conducted over three decades into the evolution of ES solutions. These highlighted the need to go beyond single site snapshot studies of information infrastructure implementation and also examine the development of the component technologies (in this case discrete and integrated packaged HEPMA solutions) amongst closely coupled communities of developers and adopters of particular products and within evolving technological fields (Pollock and Williams 2008, 2016). The need to understand longer-term evolution of products across a community requires us to go beyond (or radically re-specify) the concept of Installed Base. Here we have drawn upon a long-established tradition of work from organisational studies and related perspectives: notably the institutionalist concept of technology field and related work on product life-cycles. These have provided a helpful framework to guide the extension of our detailed ethnographic study beyond single sites and moments to encompass longer-term developments across vendor/adopter communities. Our work here has focused upon the ‘community’ of vendors, adopters and consultants linked to a particular technology. This does not however imply a ‘flat’ approach to community which risks portraying the co-evolution of technologies and their adopters as a simple process of joint learning and consensus building. Instead our studies of both ES and HEPMA highlight the overlapping webs of relationship through which these ‘communities’ are structured and segmented into a complex topology (Pollock and Williams 2016; Mozaffar 2016). Here we find a contradictory process in which diverse players grapple to accommodate goals in tension – for example supplier efforts to standardize technologies and adopter desires to differentiate systems around their particular (local or disciplinary) methods of working. These play out and need to be analysed over multiple cycles of design and implementation.