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 presents a cross-case analysis of the different strategies for dealing with the installed base in the 11 empirical chapters of this book. The empirical chapters are organised in two sections. One focused on cases of design and development of e-prescription and one focused on patient-oriented eHealth platforms. Both e-prescription and patient-oriented eHealth initiatives have a transformative role, but they are differently positioned within the eHealth landscape. Overall, e-prescription is more well-defined in terms of functionality than patient-oriented services. Furthermore, there are clear interdependencies between e-prescription and specific existing healthcare applications (e.g. Electronic Health Record systems and Pharmacy systems) and also with well-established work practices (for prescribing, drug dispensing and reimbursements) and tools (the installed base). Compared with e-prescription initiatives, the initiatives to build patient-oriented eHealth platforms are more open in scope, the functionalities to be included are frequently decided after an exploratory process, and the needs for linkages to existing systems and practices are concretised only after the specifics of functionalities are defined. Overall, e-prescription initiatives are usually seen as opportunities to improve healthcare delivery by systematic and not dramatic change while patient-oriented eHealth services are usually seen as opportunities to pursue wider and more radical innovation.

In the sections that follow, we unpack these aspects drawing from the six prescription cases and the five patient-oriented eHealth cases included in this book. Specifically, we present the actual scope of the different initiatives (i.e. the actual services included), their starting points and their motivations. We then, compare the different cases in terms of the observed strategies towards the installed base. We conclude the chapter with some reflections on the importance of a conscious and well-informed strategy towards the installed base for addressing the challenges of putting in place eHealth infrastructures.

2 E-Prescription

2.1 Overview of the Case Studies on E-Prescription: Services Offered, Starting Points, Motivation

The six case studies on e-prescription show similarities and differences with respect to the functionality domains covered, their starting points and their motivations. These are described in the following subsections.

2.1.1 Functionality Domains Covered and Starting Points

The projects cover a variety of processes related to prescribing and medication management. The projects in Norway, Catalonia, England, and Greece started with a broad aim and national scope (in the Catalan case the scope covered the semi-autonomous Catalonia region), and with a focus on the transmission of prescription information from the prescribing doctor to the pharmacies. Most of these projects did not only support prescribing of drugs by General Practitioners (GPs), but also the prescribing at hospital’s outpatient clinics and hospital prescribing for patients that are about to be discharged from the hospital.

The case from Germany and the case on UK hospital prescribing are significantly different from the other cases. The project reported in the case from Germany is not a national e-prescription project, but a project which started with the specific aim to improve medication compliance for polypharmacy patients by providing patient-specific medication packs that could function as dose administration aids. In order to implement this, the electronic transmission of prescriptions was required. The project’s starting point was related to the needs of a specific category of patients and to the possibilities offered by a specific way of drug delivery (medication packs). In addition, this project was one of many other initiatives promoting the dispensing of packaged medications in Germany. The case on e-prescription in the UK hospitals is about the implementation of various different Hospital Electronic Prescribing and Medicine Administration (HEPMA) systems in NHS England. The systems’ functionality and implementation efforts described in this case are specific to hospital contexts and do not cover any primary care activities.

2.1.2 Motivations

Regarding motivations behind the initiatives and expected benefits and outcomes, the cases have a lot in common. Firstly, they all aimed for cost containment, partly through automating parts of the overall process, but also through enhanced monitoring of drugs’ expenditures and physicians’ prescribing practices; also, they aimed for improving patient safety and for improving the overall quality of the service delivered to patients. There was, however, also some variety across the projects regarding motivation.

In two cases the interests of pharmaceutical actors played a major role. In Germany, the project on the medication packs was initiated and managed by a representative of the pharmaceutical industry with business interests to expand its market presence and promote a specific type of solution (blistering). Also in the Catalan case, although the project was initiated by the health authorities, the pharmacies and their association played a central role in defining its aims. The project got a strong focus on improving the practices in the pharmacies, and the pharmacy association managed to get a key role in the process. This key role was secured by establishing an overall architecture that allowed the pharmacy side infrastructure to be as autonomous as possible from the rest of the e-prescription infrastructure.

In Greece, the e-prescription initiative was motivated by some of the common arguments found in other cases: to enhance control over pharmaceutical expenditure, to improve doctor-pharmacy collaboration and patient safety and to capture data required for evidence-based policy development. However, the economic situation of the country played a role in pushing the project forward. The project was run during a difficult period for the Greek economy, and this accelerated the introduction of new electronic tools to reform the healthcare sector. In Norway, the project was initially triggered by the Office of the Auditor General’s critique of inadequate monitoring and control of costs related to drug use. However, in order to ensure physicians’ buy-in, the focus of the project changed early on from monitoring, control, and cost containment, towards improving patient safety.

Finally, in the case for establishing e-prescription in UK hospitals, the interests of the vendors played a significant role. Vendors of HEPMA applications were investing in expanding their market base internationally and in England, and for this purpose they adopted diverse strategies. Overall, this case brings forward the interests that shape the market within the domain of systems for hospital electronic prescribing and medicine administration.

2.2 Strategies Towards the Installed Base

In this section we will compare and contrast the six e-prescription cases regarding their strategies for how to relate to the existing installed base, and how to further develop it.

In section “Strategies for Dealing with Existing Practices and Technologies” we will look more carefully at how the different projects related to their respective installed bases. We will consider the installed base in terms of both existing user practices and technological systems. The different projects under study have followed approaches that were: installed base-friendly, installed base-ignorant and installed base-hostile. The installed base-friendly approach seems to be the one with higher chances to establish a new infrastructure and reach a stage where the adoption and use of the infrastructure get momentum. This approach implies that the new infrastructure first of all supports and aligns with existing work practices, second, that the new technological solution is as simple as possible, third, that it is built upon existing technologies when possible, and, finally, that it requires as few changes to the technological installed base as possible. However, once the infrastructure is established, it remains to see if it will lead to a lock-in process where existing practices are embedded into more complex and hard to change technological structures, or if it may enable future changes and improvement of the actual practices.

Thus, in section “Strategies for Further Development” we will turn our attention to projects’ strategies for enabling future changes by modifying and extending the infrastructure after it is established, i.e. strategies for how to “cultivate” the new installed base built. Across all cases studied, once the initial arrangements for e-prescription were put in place and adopted in practice, a series of modifications and additions followed. These further developments to the e-prescription infrastructures were driven by stakeholders´ interests and were the outcome of case-specific strategies for forward-looking development.

2.2.1 Strategies for Dealing with Existing Practices and Technologies

As described in the introductory chapter on “Information Infrastructures for eHealth”, e-prescription is relatively well-defined in terms of functionality and is built upon pre-existing applications and prescribing tools. Accordingly, the Catalan, Norwegian, English and Greek projects started out with a focus on paper prescriptions and aimed at first to digitalize the paper-based prescribing processes. They started out with the (implicit) strategy of replicating existing paper-based practices and then, to a varying degree, enriching these with additional functions for detection of medication errors and decision support that would improve patient safety. Such projects can, then, be said to be “installed base friendly”. As explained in the analysis of the case on e-prescription in England, new developments show some fidelity to established structures, practices and professional roles within the healthcare system. For instance, in the e-prescription project in England, elements of the old paper prescription form were retained and used also for the electronic solution ensuring a better ‘fit’ of the new prescription service to the wider healthcare context, both conceptually and practically. However, these four projects while trying to stay close to the existing practices, had to find appropriate strategies for actually building e-prescription upon the installed base and faced different challenges.

The Norwegian and Greek projects employed almost opposite strategies for dealing with the existing technological installed base. In the Norwegian case, the strategy chosen was to integrate tightly the e-prescription modules implementing the new functionality with existing systems, in particular Electronic Patient Record and Pharmacy Management systems. Due to the comprehensive functionality specified, this implied that the project required extensive work from the vendors’ side. The vendors had to develop new and quite complex software components, modify their existing solutions, and integrate them. This resulted in a situation where the overall Norwegian project became heavily dependent not only to the activities of the vendors directly involved in the e-prescription project, but also to the overall situation within the vendor organizations. For instance, the project was slowed down by one vendor’s delayed development of a new product.

Differently from the Norwegian project, the Greek one developed first a simple solution based on easily available and straightforward web technologies without pursuing integration with the Electronic Patient Record and Pharmacy Management systems that were already in place. These integrations were made possible at a later stage, after the initial launch of the simple solution. Due to economic and political commitments, the initial solution was developed within a very tight timeline and was launched within less than a year from the moment that development started. This is in huge contrast to the Norwegian solution in terms of both complexity and time. The “rollout” of the solution in Norway started 7–8 years after the project was established.

In the English case, the e-prescription solutions for doctors and pharmacists were developed by software vendors according to a set of output-based specifications describing how to manage and process electronic prescriptions. These solutions were built upon the technological installed base which included agreed national informatics standards and common supporting components such as a data centre and communications backbone (the Spine) which enables the transfer of data between computer systems in the NHS. In the Catalan case, the technological installed base included Pharmacy Management Systems, but lacked a national secure health network. This secure network had to be built before the project proceeded.

Differently from the other four cases, the UK hospital case and the German case started from available technological capabilities, rather than the existing work practices. E-prescription in hospitals in England was based on Commercial Off-The-Shelf (COTS) ‘packaged’ software systems that were used for various purposes different from medication management, rather than existing work practices. The vendors of the systems tried to adapt them to support and improve the activities related to medication management. However, in many cases the COTS systems had non-clinical origins and were ‘foreign’, lacking alignment with UK hospitals’ internal processes and needs, and the diversity of practices across hospitals, department, and specialties. In this case, the approach followed in the project could be said to be “installed base ignorant” as the existing practices were not taken into consideration in the process of infrastructure development. This resulted in requests to adapt the systems to local practices and preferences, which forced vendors to perform multiple cycles of modification to their products. However, the process turned out to be complex and slow, resulting in the current uneven growth and variable success of HEPMA systems in England.

Similarly, the German project started with a technological vantage point and the ambition to change existing practices. The project promoted the dispensing of packaged medications in blisters, with a specific process flow around it, and a controlled medication lists. However, the innovative blistering practice and the infrastructure supporting it, were seen as a controversial by key actors. Blistering practices would require the transformation and extension of various existing practices such as: medication management and related information sharing practices, practices of distributing medication and practices of invoicing and reimbursing medication. In this case new technologies designed for Multi-Dose (or Automatic Dose) Dispensing were not adapted to what was already in place. In addition, core infrastructural components were questioned and opposed. For instance, the assortment of 400 medicines for blistering was perceived as controlling medication practices. Overall, the relation to the installed base in the German case can be seen as ‘hostile’ for various reasons. From the perspective of the project, the innovative blistering project met an ‘installed base of opposition’ as many key actors critiqued and strongly opposed the project. This eventually ended the project. From the perspective of the existing practices and technologies, the project’s approach can be said to be “installed base hostile” considering the mismatch between the novelty of the blistering project, and the existing arrangements in the surrounding environment.

Overall, all the six cases had to deal with what we have described as the ‘paradox’ of the installed base in the chapter on “Information Infrastructures and the challenge of the Installed Base”. This paradox is about aiming for developments that need to fit and make use of existing arrangements and at the same time transform them. This specific need to be both fitted and transformative can explain why cases that initially adopted installed base-friendly approaches may at a later point become more installed base-hostile. For instance, in the Norwegian case, the project aimed initially to establish stronger control of public expenses related to drugs, which implied closer monitoring and control of physicians’ work practices. The project owners realised that physicians might be unwilling to adopt a technological solution aimed just at such monitoring. Accordingly, it was decided to add functionality to the solution specification to make the solution more aligned with physicians´ work practices. This move however, made the technological solution more complex and more “installed base hostile” regarding technology.

2.2.2 Strategies for Further Development

In this section we turn our attention to the different cases’ strategies for enabling forward looking changes by modifying and extending the infrastructure after it was established. Of the six cases examined, three have enough similarities for being cross-analysed. Specifically, the Catalan, Greek, and Norwegian cases covered similar functionalities, started all with installed base-friendly approaches and were pursued to a great extent through centrally decided and implemented development plans. Those information infrastructures evolved more or less continuously after they were put in place according to different strategies. These three projects illustrate three different ways in which the continuous modification and enhancement of an already established and adopted infrastructure can be facilitated, i.e. how an installed base can be “cultivated.”

In Catalonia, the infrastructure was continuously changed and a range of new services have been introduced. Key elements in this process were the architectural changes which turned the SIFARE server into a platform that could be accessed through an API and web services. Over the years the API and the web services have been extended and modified to provide a vast range of services. These services offered Pharmacy Management System vendors (14 in total) possibilities for developing new services supporting and improving the work practices of their customers. Over the years the vendors have been innovative and added many new services to their products based on the SIFARE platform. Partly the vendors have innovated and developed new services individually, partly this has happened through coordinated initiatives like the “Paperless Pharmacy” project.

The Greek solution was first extended by developing and providing APIs that the vendors of Pharmacy Management and Electronic Patient Record systems could use to integrate their solutions with the infrastructure. Then, various new functions were added such as the electronic implementation of therapeutic prescribing protocols, and diagnostic tests’ ordering. These changes were implemented in short time and at low cost. This was possible because the new infrastructure was based on an expandable component-based architecture. In addition, the initiative was run and maintained by a small centralized organization that had flexibility in modifying the solution. Overall, multiple changes have taken place as a sequence of small steps.

The Norwegian infrastructure is significantly more complex than the Greek one. Furthermore, the Norwegian case was the only one of the three that expanded beyond the traditional prescription areas. Specifically, the Norwegian case expanded into medication management of chronically ill patients at home and in nursing homes through the development of new functionalities for supporting Multi-Dose Dispensing. The hospitals in Norway have also expressed interest in integrating the e-prescription solution with their Chart and Medication Systems. For all major changes in this complex infrastructure the application independent GPM module played an important role. The central project organization used this module to develop the new functionalities in an experimental fashion being able to test prototypes and the launch pilots without involving application vendors. After having successfully established a number of pilots, the specifications for the extended functionality could be frozen and then implemented as extension to vendor applications if the vendors wanted to.

Due to these improvements and modifications of the e-prescription infrastructures the installed bases of technologies and user practices also changed. Actually, in all cases work practices evolved as the infrastructures were modified and extended.

3 Patient-Oriented eHealth Platforms

3.1 Overview of the Case Studies on Patient-Oriented eHealth: Services Offered, Starting Points, Motivations

The five case studies on patient-oriented eHealth platforms tell different stories about strategies towards the installed base. This is not unexpected as each case has a different starting point and is related to different sociotechnical settings. Furthermore, the locus of each initiative is different: the case from Italy describes an initiative that started from one municipality growing to the region level, the case from Sweden is about multiple parallel county-level initiatives under national coordination, the other two cases from Scandinavia are about initiatives taken at the national level (Denmark, Norway) while the case from Spain is about an initiative taken centrally at the level of the semiautonomous region of Catalonia. The cases offer a good variety of scenarios in which patient oriented services have been successfully developed.

3.1.1 Services Offered and Starting Points

The types of services offered through the platforms cover the whole spectrum described in the second chapter of this book (on Information Infrastructures for eHealth). The three Scandinavian platforms (Denmark, Norway, Sweden) and the Catalan one include an impressive range of offerings: quality checked information on health and disease, information on the performance of different health institutions, access to personal health data stored in medical records across the health sector, administrative services (e.g. GP change, tracking of referrals, claims or requests), booking services, patient-provider message exchange and e-consultation. Some of these platforms also include tools for disease-specific self-monitoring and self-care and links to patients’ social media platforms or facilities for peer-to-peer networking. There are plans for expanding towards these directions for the platforms that do not yet include such functionalities. The case from Italy is different from the other four as it has a specific focus on booking services, which emerged as an initial service in what later grew to a larger citizens’ platform. The Italian case is very interesting as it offers an account of the evolution of (probably) the first e-booking system in Europe.

Interestingly, the initial offerings for the four platforms that are now broad and all-inclusive, were different. In Catalonia, the platform started as an access point for personal health data from the Shared Electronic Medical Record of Catalonia that was newly established when the initiative started (started in 2008, first pilot in 2009). In Sweden, it started from a Stockholm County Council initiative to provide a “secure message feature” between patients and healthcare providers (initiated in 2000, first pilots in 2002 with a limited number of patient-provider interactions such as requests for appointment scheduling and prescription renewal). In both Denmark and Norway, the starting point was to provide quality assured but non-personalised information. In Norway, the platform started by offering consistent and quality-assured definitions of illnesses and treatments in information pages (started in 2010, launched in 2011); personalised services (that required patient authentication) were added in 2013. In Denmark, the national platform started by offering quality-assured medical information for both citizens and healthcare providers and soon after that, information about waiting lists (the initiative started in 2001, launched in 2003); services that required authentication were added in 2004. The differences in the initial offerings relate both to the different initial motivations for putting in place the patient platforms and also, to the different possibilities offered by the installed base in each country during the early development phases.

In the Italian case, the focus is on one specific type of electronic service (booking of appointments) but as the case narrative starts in 1990, it is interesting to observe the evolution of channels used throughout the years for providing access to patients. The new electronic service was initially (in 1990) offered through 25 e-booking centres (including hospitals, health centres and department stores). In 1996, e-booking was also offered through pharmacies. In 2000, a call centre was added as an additional channel. In 2003, a website for changes, cancellations and bookings for limited types of appointments was made available. In 2013, a comprehensive regional e-booking website was launched. The different access options provided are directly linked to the characteristics of the installed base throughout the years. In the era before widespread home computer use and network access, it was important to link to the available installed base of patient-provider interfaces (e.g. by including service counters in health facilities and enrolling pharmacies) and by leveraging telephony (through the call centre).

3.1.2 Motivations

The five initiatives are also different in terms of the motivations that ignited them. In the Danish case, a key motivation was to support better coordination across healthcare services by providing a government-controlled entry to health information across a relatively decentralized healthcare system. At a strategic level, the ambition was to encourage a common strategy, and to align investments and solutions. In Sweden, the main motivation was to promote the responsibility and participation of citizens in matters of their own health. This was very similar to the motivation for the Norwegian initiative which was centred around the need to promote a more active patient role and to facilitate the engagement of citizens by offering a national-level, comprehensive platform and facilitating access to the fragmented eHealth landscape of many patient-oriented initiatives and webpages related to health. In Catalonia, there was a multifaceted motivation that included both a new vision for the role of the citizens in healthcare and an aim to improve efficiency. The patient oriented eHealth initiative was taken to to promote responsibility and participation of citizens in matters of their own health and to improve the health care quality and coordination between different care areas, levels and professionals. Finally, in Italy, the motivation was to facilitate a transition from a hospital-centred model towards a new healthcare model that would be better aligned to the demand from citizens and regions. Improving citizens’ access to healthcare was an element of this reform and the new electronic booking service aimed to provide remedies for long waiting lists, fragmented offerings and a lack of transparency.

In the section that follows we turn to the specific strategies towards the installed base.

3.2 Strategies Towards the Installed Base

Patient-oriented eHealth initiatives require good coordination across multiple different actors that are already present in the domain as parts of the installed base (central and local government, healthcare providers in primary care and in the specialist sector including hospitals, software vendors, patient associations).

Furthermore, patient-oriented eHealth initiatives need to be built upon a technical installed base characterised by great heterogeneity: multiple different technologies are already part of the healthcare technical landscape and need to be taken into account (health record systems, healthcare organisations’ administrative systems, data repositories, citizen registries, healthcare personnel registries, messaging standards, data structuring standards, networks). This heterogeneity is a key challenge for all initiatives of this type.

Additionally, as the patient-oriented eHealth platforms have an open scope and are not confined to a specific type of functionalities and settings of use, all initiatives of this type have to address the challenge of uncertainty i.e. the challenge of being able to evolve in many different directions. This requirement is shaping the relationship with the installed base as it creates the need for organising responsiveness to evolving needs.

Finally, as all the cases are about governmental platforms, there is a need to entrench all new developments into the wider health system arrangements and ensure that they will trigger wider changes in the sector. In other words, there is the challenge of being transformative i.e. the challenge of becoming embedded into the installed base while reshaping it. The new platforms need to find ways of being patient-oriented in a traditionally provider-centric system.

In the following subsections we identify the different strategies employed for addressing these four key challenges for the relationship with the installed base.

3.2.1 Strategies for Coordination

Different strategies have been employed in the different cases to address the challenge of coordinating the work of development and implementation across multiple different actors. In some cases, there was one core leading entity that had both control and ownership of the core services (Norway, Italy), in other cases, the leading entity was exercising control without owning all services (Catalonia, Denmark) while in one of the cases (Sweden), both the control and the ownership were distributed and coordinated through a common framework. In the next paragraphs we go through these in detail.

In Denmark, a political governing body which included the municipalities, the regions, and the Ministry of Health was put in place. This arrangement allowed wide representation of interested actors in decision making processes. Since the organisational entity that ran the platform did not have any specific strategic mandate or responsibility, the role of this governing body was significant and promoted up to today a collective and consensual work mode. The challenge now is to maintain this model while keeping pace with the increasing needs of different actors and aligning with changes that happen elsewhere within healthcare.

In Sweden, patient-oriented e-health services evolved in a complex landscape of multiple authorities with overlapping jurisdictions that operate under an overarching set of rules, the National Architecture Framework for e-Health services, which has been implemented since 2007. This allowed different actors to pursue their own developments in parallel. The different actors include the 21 county councils, Inera (an organisation funded by the counties to coordinate and support their shared e-health services) and Vinnova (the innovation agency in Sweden). The Framework includes service contracts, legal agreement templates, procurement templates, interoperability standards, procedures for tests and certification and a reference architecture which applies to nationally as well as regionally funded e-health projects. The Swedish experience shows that there are potentially positive consequences of heterogeneity within the installed base (both technical and institutional) if an effective mechanism for coordination is in place. For example, the county councils of Uppsala and Stockholm developed competing viewers of health records for patients – both with national ambitions. At the end of 2015 the Uppsala solution had significantly larger number of users, so Stockholm county council decided to decommission their viewer in favour of the Uppsala one. Nevertheless, the backend of the Stockholm solution was retained and used as a national level component. Hence, the solution eventually used is a combination of Uppsala frontend and Stockholm backend. Furthermore, since 2013, the overall Swedish e-health architecture includes a component which facilitates the engagement of external actors with the installed base. This new component is the Health Innovation Platform (HIP) and includes a software development kit, several APIs and methods, guidelines and program code to support the development of e-health services by freelance developers, designers and software companies, both within and outside the healthcare industry.

In Norway and in Catalonia, the governmental patient-oriented eHealth platforms were developed under the leadership of strong, centrally positioned actors. In the case of Norway, the central actor was the Health Directorate and in the case of Catalonia, the Department of Health. In both cases the central agencies orchestrated activities that included multiple actors. In the case of Norway, the Health Directorate managed the evolution of the platform by setting priorities and keeping the ownership of the services. The Directorate ensured the reuse of public information resources and the enrolment of private software vendors for the development of links to the information systems in use within the health sector. Furthermore, the Directorate established close collaboration with the Norwegian National ICT (NICT) which is the interest body for information and communication technologies in the specialist healthcare sector formed by the four Regional Health Authorities.

In Catalonia, the Department of Health started the initiative similarly to Norway but soon, opened up to include third-party services aiming to leverage existing services offered by health providers, software vendors and pharmaceutical companies. An interoperability framework defined the conditions for including third-party devices, systems and services. With the introduction of this framework, the ownership and control of the services started to separate. The Department gave up the ownership of the new services but not their control (kept the right to decide which new services would be offered). Since 2015, an accreditation process for mobile phone apps was also put in place, aimed at generating trustworthy apps through a quality certificate. Furthermore, apps (and later wearables and medical devices) that are accredited will be allowed to store and/or retrieve information from a governmental repository for patient-generated health data which allows interoperability with both the patient-oriented eHealth services and the health information systems of health providers.

In Italy, the development of e-booking services was owned and managed by a specialised unit created within the Health Department of the municipality of Bologna, the Single Booking Centre (CUP: Centro Unificato di Prenotazione). CUP was an inter-institutional office that included personnel from the three local health units and was led by the city councillor in charge of the department. After the launching of the service an improvement process was also launched involving all the main actors, the Health Department, the three health units, ITALSIEL (the state-owned software company that developed the solution which was at that time the largest software company in Italy) and SYNWARE (which employed the workers that staffed the 25 e-booking centres). The Health Department and specifically the CUP directorate led the process. With the advent of the e-booking project, control moved to the CUP directorate, not only for the technical infrastructure, but also for the non-technical parts of the service offering. This involved lengthy negotiations with hospitals to increase the extent of services to be offered on the centralized booking system. In the Italian case, the Health Department, represented by the city councillor, was the main protagonist and played a leadership role in both the design and realization of the project. The leadership orientation was strongly influenced by the political positioning of the city councillor and also by the specific academic background of the councillor (sociology of healthcare). The support of a well-known academic figure in the field helped to legitimize the city councillor’s position in health management. Although the booking project was strongly contested by many of the participants (most notably the health units’ boards of medical directors and head physicians) it was successfully carried out due to the strong political support.

3.2.2 Strategies for Addressing Heterogeneity in Technical Components

The strategies for addressing the challenge of technical heterogeneity were also diverse. In the case of Sweden, technological heterogeneity was embraced, but a uniform user experience was ensured. Similarly, in Denmark, a uniform user experience was pursued for accessing data from different underlying sources. Still, in the Danish case, the portal included links to external services for information exchange with GP offices that did not have a uniform user interface. In Norway, this was avoided by developing new links to existing GP office health systems. The case from Italy is dissimilar to the other four cases because it started during an earlier technological era. Being a first-mover meant that there were no similar solutions already in the field. In the following paragraphs we go through the different strategies for addressing technical heterogeneity in detail.

In Denmark, the portal solution became part of an eHealth landscape where it was already possible for different technological solutions to “work together” as communication standards for information flows between medical practices, hospitals, and pharmacies were in place. The Danish solution embraced heterogeneity to a great extent. For example, the portal directs patients to the GP websites (provided by various vendors) to initiate booking of appointments and conducting email consultations. Overall, health data and services provided through the portal are based on displaying already existing data from various heterogeneous sources. In some cases, data are extracted from their sources (such as hospital systems, GP systems, prescription databases) and then presented through the portal’s presentation layer. In other cases, services are “framed” to achieve a consistent ‘look and feel’ although the service is located and run somewhere else.

In Norway, the existing heterogeneous technical components were addressed by a series of decisions. One important decision was to not link the platform with the existing private eHealth portals used by several GP offices for communicating with patients. So, differently to the approach followed in Denmark, the platform that was put in place does not redirect users to private portals. Instead, new links with the existing GP office EPR systems were developed in collaboration with the EPR vendors. The main reasons for this decision, were to ensure a uniform user experience and to control the level of security offered. Although the private portals were not linked to the platform, several components of the public eHealth infrastructures were linked. These components include the pre-existing national services for changing GPs and for accessing vaccination history. Furthermore, the platform provided access to prescriptions (leveraging the national e-prescription project) and to summary care records (leveraging the national Summary Care Record project). The platform did not only embrace national-level eHealth initiatives, but also regional ones that were aligned with the platform’s strategy and had the potential to be scaled to a national level. One such initiative provides access to medical records and another one supports message exchange between hospitals and patients. Overall, the aim was to homogenise the quality levels and user experience for services offered nationally.

In Sweden, heterogeneity is embraced as long as a uniform user experience is ensured. For example, it is possible to allow e-services to be developed and deployed outside of the portal platform itself but this should be accomplished in a way that independently deployed e-services would bring the same user experience as that of an e-service developed and deployed using the tools and infrastructure of the core portal. This allows the development of national e-services using the development and deployment infrastructure of choice. This is aligned with one of the national reference architectural principles which stipulates that integrations shall be loosely coupled and reusable for many purposes.

In Catalonia, the strategy was to embrace multiple different solutions including services offered by health providers, software vendors and pharmaceutical companies. Furthermore, an accreditation process for mobile phone apps was also put in place. Practically, the Catalonian portal provides an additional channel to access selected applications, but does not replace the direct access links provided by the service owners. Although this strategy does not ensure a uniform user-experience, it does ensure uniform high levels of quality. As several of the external solutions linked to the portal were developed abroad, keeping pace with the new releases of the APIs proved to be challenging. The experiences from this case study bring forward the complexity of embracing such a wide variety of solutions.

The Italian initiative started during an earlier technological era (the service was launched at the end of January 1990), when many of the currently available technological possibilities for loosely connecting heterogeneous components were not available. Furthermore, the e-booking services were innovative for that era. Being a first mover meant that initiative did not encounter a landscape filled with alternative solutions. The main technological concern was to develop a stable and satisfactorily performing solution given the time constraints (the centralized booking system had to be deployable within 6 months).

3.2.3 Strategies of Addressing Uncertainty by Organising Responsiveness to Evolving Needs

Uncertainty was another major challenge for all cases. It was important for all initiatives to put in place organisational and technological strategies that would allow responsiveness to new needs. There were two main types of strategies followed in the cases studied. In Denmark, Norway and Italy, the initiatives were organised towards fully pre-planned change. In all three cases, an organised process for collecting needs, prioritising them and planning new development was put in place. The cases of Catalonia and Sweden were different to the other three cases in the sense that allowed more organic change to happen with the contribution of multiple distributed actors. In the paragraphs that follow we go through the different strategies towards uncertainty.

In Denmark, development projects were prioritised in collaboration with multiple partners as the organisational entity that ran the platform did not have any specific strategic mandate or responsibility. This was a lengthy process and in some cases the priorities of the partners would shift after certain tasks had been initiated (for example, a new urgent need for adding functionality to register citizens’ wishes for organ donation popped up and had to be accommodated). After the decision to handle most development of services in-house (as opposed to development by external consultants), it became a challenge to keep up with the pace of demands. Furthermore, the partners started being inpatient with the need to constantly discuss prioritizing services. While the portal was very visionary at the beginning, it could easily get behind regarding current trends in a fast moving sector of digital health services where there always new needs for linking up with new data sources and providers. To ensure responsiveness to needs, a re-organisation took place recently to increase delivery capacity and strengthen portfolio management. The future focus is on being proactive and assist the partners in developing and maturing new service concepts.

In Norway, a similar process of collecting needs and prioritising development was put in place. During the early stages of development, a number of studies were prepared with the contribution of multiple stakeholders to plan the services to be developed over time. In 2014, the Health Directorate that has ownership and control over the platform, collaborated with the Norwegian National ICT (NICT) which is the interest body for information and communication technologies in the specialist healthcare sector formed by the four Regional Health Authorities. The collaboration aimed to identify citizens’ needs for digital services in specialized care to obtain insights for further developing the platform. The result was an extensive mapping and analysis of users’ needs involving health personnel, citizens and management bodies of the health regions. The analysis ended up with the identification of priority service areas, informed the formulation of a strategy for digital specialist health services, and led to the formation of a specific project on digital citizen services for the specialist sector.

In Italy, an improvement process was put in place right after launching the e-booking service. The process involved all the main protagonists, the Health Department, the three health units, ITALSIEL and SYNWARE. The Health Department, specifically the CUP directorate, led this process. Overall, also in this case, organisational processes for planning and controlling changes were implemented.

In Sweden the principle of local contribution to the national ecosystem was formalised and became one of the six architecture principles of the national reference architecture. In the cases of local and regional needs that are not aligned with national prioritizations, a group of county councils, municipalities and solution vendors have been able to join forces to develop solutions on their own for more local and regional use. The principles of national functional scope secure that the solution can grow to a national scale in the future. As time passes by, county councils, municipalities and solution vendors continuously negotiate to bring their local or regional solution to a national level, sharing the solution with all publicly funded care in Sweden.

In Catalonia, the new patient-oriented eHealth services had to face uncertainty and multiple possible alternatives. Since many of the services could not be specified in advance, decisions and choices had to be exploratory and adaptable. At the beginning of the project, the sponsors of the portal tied the development to the Public Shared Electronic Medical Record. So, the portal started simple, without a big architectural blueprint and complex anticipatory design. A catalyst for further growth has been the decision to put in place the means for connecting to existing applications and stimulating the development of new ones by third parties. The interoperability framework and the app accreditation process were critical for this.

3.2.4 Strategies Towards Transformation

In all cases, the new platforms were developed with the aim of achieving a patient-orientation within an overall traditionally provider-centric system. In other words, they had to face the challenge of becoming embedded to the installed base while transforming it. In the cases from Denmark, Norway, Sweden and Catalonia the strategies followed were overall “installed base friendly” in the sense, that, all developments were based on wide consensus and transformations were attempted in small steps. The case from Italy stands out as a clearly disruptive strategy was followed. In the next paragraphs we elaborate on each case.

In Denmark, there has been broad support from relevant players in the Danish healthcare arena. Especially the initial phase can be characterized as a political showcase for regional collaboration with solid political unity and common ambition. During this phase, there was little disagreement concerning what should be offered to citizens and healthcare providers. The political unity and broad collaboration of stakeholders were described as key reasons for the success of the portal.

Similarly, in Norway, the views and needs of the health sector and also of the technology providers were taken into account and multiple processes for “anchoring” the initiative within the sector were taken. These anchoring processes allowed stakeholders to voice their concerns and shape the initiative, while at the same time the designers of the new services were able to expose their plans and explain their rationales. The Norwegian platform was expanded by orientating towards the satisfaction of concrete needs expressed by potential users while the overall evolution has been incremental and gradual.

In Sweden, the e-services offered were not perceived as controversial since they did not entail profound changes in the role and relationships between doctors and patients, and between doctors themselves. Instead early on results showed increased work processes effectiveness and less need for accessing healthcare centres by phone for renewal of prescriptions or bookings.

In Catalonia, the underlying vision for the new eHealth services has been the idea of self-care and preventive care – i.e., that citizens become more autonomous, responsible and participative in matters concerning their own health. The realization of this vision requires reconfiguring multiple of the existing relationships and the creation of new ones. For instance, since patients have more information about their own health, their relation with professionals, who are used to have control over the access to the patients’ data, will probably change; the responsibility boundaries among professionals will most likely shift; and since the portal is becoming a new channel for the provision of health services, the public administration will have to reconsider the payment criteria for those services to health professionals and providers. Nevertheless, as the changes are paced there has been no major opposition from the wider sector.

Finally, the Italian case is the one where disruptive changes were pursued (and actually implemented). Improving citizens’ access to healthcare was an element of the National Health Service reform, especially relevant in Bologna where long waiting lists, fragmented offerings and a lack of transparency characterized access to secondary care. The municipality of Bologna addressed these issues by leveraging new technological capabilities that allowed bookings to be performed without being controlled by the healthcare institutions. This created tensions and strong opposition by key actors from the medical establishment. The institutional components of the installed base revealed themselves as obstacles for achieving innovation and only the large mobilization of political, organizational, and technological resources made it possible.

4 Working with the Installed Base for Building eHealth Infrastructures

The cross-case analysis presented in the previous sections should be read together with the rich descriptions and analysis provided in the chapters that relate to each case. The cross-case analysis offers an entry point to the cases and a possible orientation for making sense of the different ways of working with the installed base for building eHealth infrastructures. The perspective taken in this book is that the installed base is the point of departure for change processes. The notion of installed base is a conceptual tool, not a name for some independently existing reality. The notion helps us to ‘look for’ something particular: by focusing on the installed base, attention is directed towards the links with existing arrangements and the evolutionary processes of the new eHealth infrastructure.

All initiatives aiming for novelty in healthcare delivery will entail planning for the existing elements that need to be retained and reused, and the elements that need to be eliminated or replaced. This act of distinguishing between elements to be reused or discarded identifies the relevant installed base for the initiative. In every change process there are aspects of both continuity and discontinuity. The relevant questions then become: What is continued and what is discontinued? In what sequence are the discontinuities introduced? What is the required work to achieve a certain transformation? How to engage with the existing situation – in a confrontational or cautious way? The questions address how initiatives relate to and deal with the installed base.

The main message of the cross-case analysis is that the successful development and implementation of initiatives for eHealth infrastructures require much more than creating a clear description of the goal, and having in place the necessary technological capabilities and human skills. It also requires a discerning and knowledgeable engagement with the particularities of the situation and an informed and conscious approach for working with the installed base.