See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/326158048

Platformization as Generative Entrenchment: A Case of a Public Heaclthcare

System

Conference Paper · June 2018

CITATION READS

1 246

1 author:

Joan Rodon
Universitat Ramon Llull
48 PUBLICATIONS   851 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Governance of platform cooperativism View project

All content following this page was uploaded by Joan Rodon on 09 July 2018.

The user has requested enhancement of the downloaded file.

 PLATFORMIZATION AS GENERATIVE ENTRENCHMENT:
A CASE OF A PUBLIC HEALTHCARE SYSTEM

Joan Rodon Mòdol, ESADE, Ramon Llull University, [email protected]

Abstract
This paper studies the process of platformization in public healthcare. We conduct a case study
around the building of several digital platforms in the regional healthcare system of Catalonia. Draw-
ing upon the concept of generative entrenchment, we observe how certain social (governance) and
technical (architectural) elements became the base for generating new initiatives, which in turn, in-
creased the stability of those elements. Therefore, platformization is a gradual accumulation of addi-
tional layers that extend the functionalities and scope of existing systems while at the same time in-
crease their entrenchment. The concept of generative entrenchment helps theorize the idea that plat-
forms grow from an installed which has downstream enabling and constraining consequences on new
platforms and these in turn, feedback on the same installed base. Second, the installed base has parts
with larger and more pervasive effects, and hence, the elements of the installed base are preserved
differently. Third, the dependencies of new platforms upon the installed base change over time.

Keywords: Platforms, Generative Entrenchment, Process, Installed Base, Public Healthcare.

1 Introduction
Digital platforms are gradually emerging as a powerful way to organize public healthcare in Europe
(Aue et al. 2016; Benedict et al. 2018). This paper aims to study how platformization takes shape in
the context of public healthcare. By platformization we refer to the processes associated with the
gradual formation and evolution of digital platforms. The platformization of public healthcare is chal-
lenging because many of the incumbent healthcare services have not been platform dependent from its
inception. Migrating those services to platforms is a complex endeavour as they usually involve a
whole range of interacting systems and actors (e.g., health care providers, insurance agencies, IT ven-
dors, care professionals, patients) operating at different levels (e.g., departmental, organizational, mu-
nicipal, regional, national).
Hence, theoretically and empirically investigating the process of platformization must account for the
role of the installed base of technical systems, organizational structures, social rules and conventions,
professional practices, and regulations (Aanestad et al. 2017). Hanseth and Lyytinen (2010) argue that
infrastructures must be built upon and expand existing installed base. Managing the “evolution of the
installed base is challenging, as it entails building on the installed base and transforming it at the same
time” (Aanestad et al. 2017; p. 30). Hanseth and Lyytinen (2010) propose the concept of bootstrapping
to capture the idea that the installed base is used to create an infrastructure that supplements or replac-
es the same installed base. This requires that the installed base has to be stable to allow the enrolment
of new artefacts, processes, and actors, and at the same time, it has to “possess flexibility to allow un-
bounded growth” (Tilson et al. 2010; p. 754). In other words, the installed base heavily influences how
new elements can be implemented (Hanseth and Lyytinen 2010); it can be both enabling (i.e., a re-
source for new elements) and constraining (i.e., a trap that hinders the implementation of new ele-
ments).

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018
Platformization as Generative Entrenchment

Overall, we consider the focus on the installed base as an analytical tool can help in our attempt to
study the platformization of public healthcare by directing our “attention towards the links between
existing arrangements and the evolutionary processes” (Aanestad et al. 2017; p. 51). For instance,
Monteiro (1998) contends that because of the inertia of the installed base the evolution of the internet
protocol in the Internet involves gradual transitions of the installed base. Grisot et al. (2014) conceptu-
alize infrastructure innovations as a process of cultivating the installed base with attention to three as-
pects: process-orientation, user mobilization, and learning. Aanestad et al. (2017) report and categorize
several platform initiatives in European healthcare in relation to the installed base as being friendly
(when the new system supports and align with the installed base), ignorant (when the platform is built
without taking into account the installed base) and hostile (when there is a mismatch between the nov-
elty of the platform and the installed base).
Although these studies theorize on the role of the installed base and the strategies to cultivate it, they
still fail to pay explicit attention to the dynamics of the installed base over time. Accordingly, this pa-
per explores some understudied themes: How do the extensions of installed base feedback on certain
elements of the same installed base? How the ability of the installed base to constrain is related to its
ability to enable? How do parts of the installed remain over time and influence new developments
while others dissipate? How do the interdependencies between the elements of the installed base
evolve? How do platforms’ dependencies upon the installed base change over time?
In order to address these research themes, we borrow the notion of generative entrenchment coined by
the philosopher of science William Wimsatt (2007; 2013a; 2013b) and use this concept to study the
dynamics of the installed base in the platformization of public healthcare. We conduct a longitudinal
study about the evolution of the digitalization of the Regional healthcare system of Catalonia covering
a period between 1990s and 2018. We identify three developmental trajectories (integration, re-
programming, convergence), and show how each trajectory is shaped by and influences the generative
entrenchment of certain elements of the installed base. We consider that the notion of general en-
trenchment extends prior accounts on the evolution of the installed base by showing its emergence and
cumulative nature.
The remainder of the paper is structured as follows. In section 2, we present the conceptual back-
ground of the paper. Section 3 introduces the empirical context and the method. This is followed by
the presentation of the case results and analysis of the case. Finally, we conclude the paper with a dis-
cussion of the results and the potential contributions.

2 Background

2.1 Digital platforms

We broadly define a digital platform as a socio-technical foundation for other digital resources to be
built upon (Plantin et al. 2016; Tiwana 2014). “As a foundational element, platforms therefore enable
a degree of control over what is constructed upon them, while simultaneously relying upon the un-
known unpredictable things assembled atop them” (Williams 2015; p.220). Platforms are institutional
and technical forms of organization having distributed interfaces that enable remote coordination of
information and action (Bratton 2016).
From an architectural perspective, platforms have a relative stable core and variable complements at
the periphery (Tiwana 2014). This combination of stability and variability is rendered coherent
through interfaces (e.g., APIs, standards, laws and regulations, protocols) that allow the core and com-
plements to interact (Ghazawneh and Henfridsson 2013). The core remains relative stable and is used
to support the emergence of a wide variety of downstream complements. Platforms remain centrally
controlled and designed, but benefit from the innovation of third-party developers (Plantin et al. 2018).
This entails that platforms are (re)programmable (Helmond 2015; Yoo 2010) meaning that through the
interfaces platforms can perform a wide array of functions.

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 2
Platformization as Generative Entrenchment

In that respect, platforms allow the accommodation of predictability (i.e., platforms respond to prede-
fined requirements) and uncertainty (i.e., platforms evolve in different unforeseen directions). So, plat-
forms both enable and constrain an open-ended range of contingent services, which cannot be identi-
fied in advance (Bratton 2016). “[P]latform builders do not seek to internalize their environments
through vertical integration. Instead, their platforms are designed to be extended and elaborated from
outside, by other actors, provided that those actors follow certain rules” (Plantin et al. 2018; p. 298).
Platforms standardize and fix certain components, “but are strategically agnostic with regards to out-
comes” (Bratton 2016; p. 47). Those standardized components serve as the basis for the emergence of
new downstream components thus creating layered dependencies in which some elements become
crucial in the formation of new ones. Bratton suggests that those dependencies sustain platforms and
refers to those layered dependencies as generative entrenchment.

2.2 Generative Entrenchment

The concept of generative entrenchment was coined by philosopher William C. Wimsatt (2007; 2013a;
2013b) in his studies on a developmental understanding of complex (biological and cultural) system
evolution. Wimsatt (2013b) argues that generative entrenchment applies to systems having structures
generated over time resulting in a developmental history (generativity), and having some elements that
have larger and more pervasive effects than others (entrenchment). In that sense, this reflects the idea
that elements that come earlier in the process of building a system will generally be more entrenched
than elements that are created later.
A generative entrenched element is “one that has many other things depending on it because it has
played a role in generating them.” (Wimsatt 2007; pp. 133-134). Generative entrenchment reflects de-
pendency relations among elements in a developing adaptive system. Greater entrenchment yields
greater conservatism in the evolution of parts of the system, but generatively entrenched parts can also
provide the basis for subsequent adaptive radiations1 of elements that depend upon it (Wimsatt 2013a).
Entrenchment requires recurrence: “Entrenchment requires that the action of downstream consequenc-
es must feed back to maintain the presence of that type of element that is said to be entrenched”
(Wimsatt 2013a; p.82). “In becoming deeply entrenched, elements become more like infrastructure as
they become more polyfunctional: as infrastructural elements are co-opted for more functions because
they are there, they become more deeply entrenched, and in consequence, more strongly conserved,
causing a mutual positive feedback of amplifying stability relations. Thus one can build infrastructure
to facilitate the amplification of structures and processes utilizing them, but one can also simply use
what is there to such an extent that it becomes infrastructural. And generative entrenchment requires
reproduction, so the circle is closed.” (Wimsatt and Griesemer 2007; p.280).

2.3 Platforms and Generative Entrenchment

Generative entrenchment reflects the dependency relations among elements in the process of plat-
formization, and measures the degree to which an element of a platform is connected to downstream
consequences, and hence, becomes more essential and stable. Generative entrenchment considers that
older elements tend to have developed more downstream dependencies and that they therefore tend to
become generalized and strongly conserved: changing them is hard since so many things depend on
them. Generative entrenchment can be thought as a mechanism “promoting evolutionary stability”
(Wimsatt 2007; p.135).

1 “In evolutionary biology, adaptive radiation is a process in which organisms diversify rapidly from an ancestral species into
a multitude of new forms, particularly when a change in the environment makes new resources available, creates new chal-
lenges, or opens new environmental niches” (Wikipedia).

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 3
Platformization as Generative Entrenchment

Once an element of a platform has been established (or becomes a standard), it achieves a high degree
of generative entrenchment and new functionalities and technological capabilities that appear later are
likely to depend on it. The “standardization of essential components produces an effect of generative
entrenchment by which one platform's early consolidation of systems (formats, protocols, and inter-
faces) decreases a User's2 opportunity costs3 to invest more and more transactions into that particular
platform, while it increases the costs to translate earlier investments into another platform's (at least
partially) incompatible systems.” (Bratton 2016; p.47). Accordingly, “[g]enerativity is an extremely
efficient way of building complex adaptive structures, while at the same time locking in their genera-
tors. Since these are two sides of the same coin, their association is a deep fact of nature” (Wimsatt
2007; p. 137).
The more generative a platform, the more entrenched it will become. Conversely, the more entrenched
an element of a platform, the more likely that new elements (functionalities, processes, systems) will
base themselves upon that element. Generativity and entrenchment are therefore deeply coupled to-
gether. The more generative something is, the more difficult, or costly, it will be to shift or transform.
Hence, generative entrenchment captures the idea that platforms’ “ability to enable [is] directly related
to their ability to constrain, and vice versa. The more elements built upon a platform, the more genera-
tively entrenched it will be.” (Williams 2015; p. 223). Moreover, Bratton (2016; p.49) observes,
“many successful platforms are those that provide Users with new capabilities by making their exist-
ing systems more efficient. Platforms that organize existing systems and information tend to achieve
generative entrenchment more quickly than those that seek to introduce new systems from scratch”.
The concept of generative entrenchment shows that evolution is cumulative, that “some things must be
preserved to build on” (Wimsatt and Griesemer 2007; p.282). So, different parts of a platform may
show different degrees of entrenchment. The reason for this has less to do with the circumstances of
their original emergence and more to do with everything that depends on them. This means that par-
ticular contingencies will have greater consequences than others; and accordingly, history matters in
the platformization. This has implications for designers/developers who must constantly battle en-
trenchment because of the prohibitive cost of developing a new platform from scratch and because of
the expectations and capabilities of the diverse actors.

3 Research Site and Method

In order to study platformization through the lens of generative entrenchment we conducted a longitu-
dinal case study (Yin 2009) about the evolution of several digitalization initiatives in the healthcare
system of Catalonia, covering the period between 1990s and 2018. Before we present the details of the
data collection and analysis, we provide some background of the context of the case.

3.1 Case Context

The Catalan healthcare system involves four main actors: the Catalan Department of Health (DoH);
the CatSalut; health providers; and citizens. The DoH is in charge of establishing health policies and
maintaining levels of quality in delivery by creating a health plan, determining a healthcare budget,
and accrediting providers. The CatSalut is the public insurer that is responsible for planning, purchas-
ing, and assessing health services according to the health needs of the population. The CatSalut estab-
lishes service policies in line with the health policies defined by the DoH. The Catalan territory is di-

2 Bratton (2016) uses the term User (capitalized and italized) to refer to the upper layer of the global megastructure that con-

stitutes today’s computing systems. Users include human and non-human agents that interact with computational machines.
3Opportunity cost refers to “the added cost of using resources (as for production or speculative investment) that is the differ-
ence between the actual value resulting from such use and that of an alternative (such as another use of the same resources or
an investment of equal risk but greater return)” (Merriam-webster)

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 4
Platformization as Generative Entrenchment

vided into seven health regions demarcated from geographical factors, socioeconomic and demograph-
ic. Each region is structured in turn in health sectors, which bring together the so-called basic health
areas formed by neighbourhoods or districts in urban areas, or to one or more municipalities in rural
areas. The health providers are those organizations that the CatSalut contracts to provide care services.
Each health provider has a multiannual contract with the CatSalut that is revised on a yearly bases and
that includes health objectives, activity, economic amount, rates (pricing), invoicing system, and eval-
uation system.
The provision of healthcare is done by a diversity of contracted providers having different ownership:
public companies –the Catalan Institute of Health (ICS) is the biggest one–, consortia, municipal
foundations and private foundations. The provision of healthcare is organized into four main levels:
primary care; specialized or hospital care; socio-sanitary care; and mental care. Primary care is the
gatekeeper and responsible for coordinating the patients’ care along the care continuum. Since the
primary healthcare reform (in 1985) primary care has evolved from a predominance of curative care
upon demand from the user population and the work of individual healthcare professionals to a model
that focuses on preventive healthcare, curative healthcare, rehabilitative care and the promotion of
community health. This transformation was structurally achieved through the creation of basic health
areas and the gradual introduction of primary care teams. In 2017 there were 71 hospitals, 369 primary
care centres (77% of them being managed by the public provider ICS), 96 socio-sanitary care centres,
and 41 mental care centres.

3.2 Data collection and analysis

Data was collected from three main sources: semi-structured face-to-face interviews (41 interviews),
participant observation (workshop attendance; and informal conversations), and archival data (press
documents; internal reports about the projects, systems, health plans and health IT plans; meeting
minutes; and videos), aiming at data triangulation (Yin, 2009). Conducting the interviews was orga-
nized in four stages between 2011 and 2018: (1) from March to June 2011 (17 interviews); (2) from
March to June 2013 (10 interviews); (3) from December 2014 to October 2015 (10 interviews); and
(4) from February to March 2018 (5 interviews). We identified interviewees by referral from other
subjects. Another relevant source of archival data were the health IT plans for the period 2008-2011,
2013-2015 and 2018-2022 and the corresponding health plans (2007-2010, 2011-2015, 2016-2020).
Data collection and analysis took place iteratively. In our analysis, we wrote memos to articulate our
interpretations of the data at each of the four data collection stages and across those stages. We also
incorporated feedback from our informants, particularly, from those who we interviewed in more than
one stage. Our data analysis took place at three main levels and at the interactions between those lev-
els: organizational level, the level of networks of organizations (e.g., providers operating in a health
sector that exchange information), and the regional level. Our analysis did not include upper levels
such as the country or EU, and lower levels such as practices and technologies used by an individual
professional in a given organization. Although these levels can influence the platformization of the
healthcare system as they interact with elements at other levels, we did not consider them in our analy-
sis because they would not add much to our findings.
Finally, we grouped the data referring to IT-related projects from the period 1990s – 2018 into seven
major digitalization initiatives. For each initiative, we analysed the governance and architectural ele-
ments that constituted the installed base and that had some enabling and constraining effects on the
initiative. Next section presents these seven initiatives and afterwards we analyse them from the lens
of generative entrenchment.

4 Case Results: Digitalization initiatives

Our analysis considers seven major interdependent initiatives towards the digitalization of public
health promoted by the CatSalut and DoH from 1990s until 2018 (see Figure 1).

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 5
Platformization as Generative Entrenchment

1: Computerization of health providers (EMRs, HIS, PACS, radiology, administrative,…)

2: Providers’ sponsored IT-enabled coordination

3: Regional shared electronic medical record (RegSEMR)

4: Regional personal health record (RegPHR)

5: Regional interoperability (RegInterop)

6: Health apps marketplace

and Digital Health Platform
(regional level)

7: Regional
electronic health
record (RegEHR)

1990s 2000 2008 2009 2013 2015 2017 2018

Figure 1. Major initiatives in the digitalization of the regional health services.

First initiative. Although the computerization of healthcare system started in the 1980s at the level of
the DoH, the public insurer, and some major care providers, it gained momentum in the 1990s with the
implementation a multiplicity of systems: Electronic Medical Record (EMR) systems for primary care,
hospital information systems (HIS) which includes modules such as physician and nurse clinical
workstations, pharmacy, pathological anatomy, etc., departmental systems such as laboratory, radiolo-
gy, PACS, etc., and administrative information systems such as financials, purchasing, human re-
sources. In this period, providers were fully autonomous in the selection and management of these sys-
tems. This led to a multiplicity and heterogeneity of systems, data models and standards, and working
processes. By end 2017, there were 29 different EMRs for primary and HIS.

Second initiative. From 2000s healthcare providers started collaborating in order to use IT to coordi-
nate their work within and across levels of care. This was achieved through bilateral solutions between
providers (e.g., giving manual access to each other EMRs and HIS, or through point-to-point integra-
tion of different systems). Yet from 2010 to 2016, some territorial platforms sponsored by major pro-
viders were built to interconnect different levels (e.g., primary care with hospital care) of the same
health provider or to interconnect providers operating in the same health care sector. These platforms
were proprietary and did not adopt a common standard and architectural model.

Third initiative. In 2008, the DoH sponsored a shared electronic medical record platform at the region-
al level (RegSEMR) to which all health providers would interconnect. The aim was to enhance the
coordination of the delivery of care services across care providers to give continuity of care through a
common repository of data. RegSEMR would store and give access to the following data from primary
care (diagnosis, healthcare reports, immunizations, and chronic patient labels), specialized care, long-
term care and mental care (discharge report, emergency reports, specialized outpatient clinic reports),
diagnosis procedures (pathology and laboratory reports, radiology image, imaging diagnosis reports,
interventions), and the same DoH. Initially, RegSEMR was conceived as a repository of PDF docu-
ments, and in the case of image as an index. From 2014, the RegSEMR was extended to store not only
PDF documents but also structured data about diagnosis, immunizations, spirometry, and patient tra-

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 6
Platformization as Generative Entrenchment

jectory. However, the data stored at RegSEMR continued to be only a part of all the data stored in the
diverse EMRs and HIS.

Fourth initiative. In 2010, the DoH extended/opened the RegSEMR to citizens with the creation of a
personal health record (RegPHR). The RegPHR started simply as a viewer application of the data at
RegSEMR for patients. Yet, since 2013 the RegPHR gradually evolved into a platform; it was opened
to third-parties (e.g., care providers, software vendors, pharmaceutical companies) who could add new
functionalities that enabled citizens to access more personal data (not only stored at RegSEMR) and to
interact with the care providers through the RegPHR. To support the platformization of RegPHR they
implemented an interoperability framework that defined the conditions for third-party devices, systems
and services to interoperate with RegPHR (Rodon 2017).

Fifth initiative. From 2013, the DoH sponsored a new regional interoperability platform (RegInterop)
that was built on top of the RegSEMR aiming to standardize the interactions and work requests across
care providers and care levels. A primary care physician noted the need for RegInterop as follows,
“RegSEMR provides data, but most of it is non-structured data so it can’t be contrasted with other data
and hence we can’t make decisions. For instance, from a diagnosis, it should be possible to generate
and modify alerts in relation to other patient data. In the case of a referral, it should be included the
diagnosis, tests and other relevant data.” To implement RegInterop they adopted the interoperability
standard HL7 and international terminologies such as SNOMED, LOINC, etc. With RegInterop, the
platforms that were initially built as part of the second initiative were gradually disconnected and pro-
viders adapted their EMR systems and HIS (by adding a new layer on top of those systems) to inte-
grate with RegInterop. With the deployment of RegInterop some providers could not afford the
maintenance costs involved in adapting the integration of their EMRs and HIS to RegInterop. Those
providers opted for adopting the EMR for primary care called eCAP developed in 2000 by the ICS
(the major care provider). This decision was backed by the Health Plan 2011-2015, which turned
eCAP as the reference EMR for primary care and proposed to make it available to all providers in Cat-
alonia. However, by that time there were more than seventeen versions of eCAP reflecting its devel-
opmental history across the whole region. By the end of 2017, around 90% of primary care centres
were running eCAP.

Sixth initiative. As part of a mobility master plan for health in 2014, a platform initiative was launched
involving two main components that extended the functionalities of RegPHR for citizens. First, a
health apps marketplace that would match the demand (patients, social and health providers, etc.) and
supply (social and health providers, apps developers, pharmaceutical companies, medical equipment
vendors, etc.) of health and social services. Second, a digital health platform that would allow those
apps that were accredited to interoperate with other platforms of the health system (e.g. RegSEMR)
through the RegPHR.

Seventh initiative. Starting in 2018, the DoH is sponsoring a unique regional electronic health record
(RegEHR) platform aiming to standardize and integrate all the medical and socio-sanitary data (struc-
tured and non-structured) in a single point (so using a unique data model) and create a unique process
model for all healthcare and socio-sanitary providers. This initiative is a response to a main shortcom-
ing of RegInterop (initiative 5); namely, the interoperability across providers (through the RegInterop
platform) was mainly achieved at the syntactic level (and not at the semantic level). This means that
the logic of the clinical workflows still resided at the healthcare provider (i.e., periphery) not at Re-
gInterop (i.e., the platform core). A physician and IT director of a provider criticized that scenario as
follows, “it should be the CatSalut who defines a services portfolio that says which services can and
can’t provide each care centre of a healthcare provider”. Moreover, RegInterop only supported four
main types of messages. So, the amount of data collected at RegInterop did not allow the DoH to
properly analyse, compare and monitor the entire activity of providers. As a conclusion of a working

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 7
Platformization as Generative Entrenchment

group involved in this initiative, “The information system [referring to the new RegEHR] needs to be
oriented to the decision making of all the actors…To achieve this, we need to unify/standardize data,
processes and nomenclature.” Accordingly, the idea of initiative 7 is to build a central platform (Re-
gEHR) that has a common language, data and process models, and a central primary database and ser-
vices portfolio that turn providers’ systems into replicas. As the IT manager of a hospital notes, “It is
clear that we have to replace the interoperability by the exchange of structured data in real-time and
building a single repository [at RegEHR]. But this does not mean having a single system [EMR and
HIS]”. Moreover, RegEHR will also contain a layer of transactional services that providers will be
able to integrate with through an API.

5 Analysis
Our analysis depicts two characteristics of the platformization of the Catalan healthcare system: 1) the
generative entrenchment of healthcare providers’ systems4 and the shared electronic medical record
(RegSEMR), and 2) the identification of three developmental trajectories.

5.1 Generative entrenchment of providers’ systems and RegSEMR

In the first sixth initiatives presented above (see Figure 1), we observe that healthcare providers’ sys-
tems (EMR and HIS) and RegSEMR have been causal generators of other initiatives, and in turn, these
initiatives have kept their dependency on those systems and RegSEMR over time, thus entrenching
them. Figure 2 shows the causal dependencies relating the first six initiatives; arrows represent de-
pendencies in the development of initiatives; each arrow pointing a dependent initiative.
2. Provider 
4. RegPHR
IT‐enabled 
coordination
6. Digital 
1.  Health 
3.  Platform
Providers’ 
RegSEMR
systems

5. 
RegInterop

Time

Figure 2. Generative entrenchment of the initiatives.

An outcome of initiatives 2 (provider IT-enabled coordination), 3 (RegSEMR) and 5 (RegInterop) is

that the healthcare providers’ systems (EMRs and HIS) have been generatively entrenched. First,
RegSEMR was built aiming to keep the diversity of providers’ systems. Second, although these plat-
forms entailed adding a new layer (e.g., central nodes) that would capture all the data of the health
providers, those data have remained in the providers’ systems and they have regarded the data in those
platforms as a replica. In the case of images, providers could use the RegSEMR platform as an index.
Moreover, the different platforms and providers’ systems used diverse databases and data models to
support the same activities. With regard to the process logic, despite the attempt to build an interoper-
ability platform (RegInterop), decisions related to for instance how to execute the process flow (e.g.,
refer a patient) remained at the level of healthcare providers. On the other hand, care providers have

4We only consider the EMR for primary care and HIS. We exclude from our analysis providers’ administrative and depart-
mental systems.

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 8
Platformization as Generative Entrenchment

retained the control and autonomy over the kind of systems. In short, the aspect of the providers’ sys-
tems that remained stable over time and influence the emergence of new initiatives was providers’ au-
tonomy over the kind of system and the data and process models supported by those systems. The sta-
bility of this aspect has fostered the dispersion of systems, databases, and ways of working, and ulti-
mately supported a decentralized healthcare system.
An outcome of initiatives 4 (RegPHR), 5 (RegInterop) and 6 (Digital Health Platform) has been a
larger degree of generative entrenchment of the RegSEMR. First, the RegSEMR has been the basis for
an ecosystem of applications, skills, and services for those platforms. In turn, this panoply of depend-
ent entities has not only extended the functionalities of the RegSEMR beyond its initial scope (and set
of relations) but also served to entrench it. In other words, as the RegSEMR consolidated, a variety of
other initiatives (4, 5 and 6) that used it as their basis were launched. Conversely, as those new plat-
forms were built on top of RegSEMR, it became more entrenched. Another aspect that has increased
the degree of entrenchment of the RegSEMR is its increasing use. For instance, by the end of 2011,
96.5% of primary care centres and 85.5% of hospitals were connected to RegSEMR. In 2014, 100% of
primary care centres and hospitals were connected to RegSEMR. Moreover, while most of care pro-
viders started accessing the RegSEMR through a web viewer, over time a great deal of the access to
the RegSEMR takes place through the providers’ clinical workstation –i.e., providers’ systems and
RegSEMR have become more integrated over time. This in turn, entails a reciprocal entrenchment
between providers’ systems and RegSEMR; that is, as a result of the tight coupling between providers’
systems and RegSEMR the relationship between both becomes one of mutual entrenchment.

5.2 Developmental trajectories

We observe three main developmental trajectories in the platformization of the Catalan Health Service
(see Figure 3).
1st trajectory:  RegSEMR & 
integration RegInterop

First version  3rd trajectory: 

RegEHR
of RegSEMR convergence

RegPHR & 
2nd trajectory: 
re‐programming
Digital Health 
Platform

Figure 3. Platformization trajectories.

The first two developmental trajectories5 begin with the first version of RegSEMR. In the first trajec-
tory (called integration and comprising initiatives 3 and 5), we observe how RegSEMR was built as a
platform to which the diverse providers’ systems had to integrate. The RegSEMR offered a set of web
services for the providers’ systems to store their data and to retrieve patients’ data that was stored by
other providers to the RegSEMR. Initially, the data was mainly stored as PDF documents, thus limit-
ing the analytical capabilities of RegSEMR. Later, in addressing this limitation, they released a second
version of RegSEMR that also stored structured data. The RegInterop, which was built on RegSEMR,
further enhanced this integration trajectory by supporting the interoperability across care providers
(primary, hospital, socio-sanitary and mental care). The core of RegInterop was in charge of routing
the messages underlying a set of processes (e.g., referral, lab tests, medical appointments, notifica-
tions).

5 These two developmental trajectories illustrate levels 1 and 2 of programmability presented by Helmond (2015).

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 9
Platformization as Generative Entrenchment

extension of the RegSEMR to store not only PDF documents but also structured data enabled the de-
velopment of new analytical functionalities but did not change the trajectory.
In the second trajectory (called re-programming and comprising initiatives 4 and 6), the first version of
RegSEMR served as a platform for innovation of patient solutions. It involved creating RegPHR on
top of the RegSEMR to reach citizens and facilitate their interactions with the healthcare system. In
this case, the third-party applications (e.g., from care providers, independent app developers, device
providers) that were approved by the DoH could first draw on data and services from RegSEMR, and
second build new services on top op or migrate existing services to the RegSEMR.
While the first two development trajectories involved a ramification of RegSEMR (see Figure 3), the
third developmental trajectory (that we call convergence) presented in initiative 7 involves the conflu-
ence of the other two trajectories into a single platform (RegEHR). Another difference between the
first two trajectories and this third one is that while the former increased the degree of generative en-
trenchment of RegSEMR and providers’ systems (as shown in the previous section), the third one is
disruptive because it entails making changes to those two deep entrenched entities. On the one hand,
RegEHR composes into a single platform the RegSEMR and RegInterop platforms. In other words,
some functionalities of RegSEMR and RegInterop will be moved to the core of the RegEHR platform,
and then they will be progressively discontinued. On the other hand, RegEHR is also belligerent with
existing providers’ systems as it standardizes and consolidates all the data and clinical processes
across health providers. So, the primary storage of data will be RegEHR not providers’ systems (as it
had been so far), and the latter will be dependent upon the former. Moreover, health providers have to
obey the process logic implemented at RegEHR not at their systems. In other words, the data and pro-
cess logic is taken from providers’ systems and put at RegEHR, thus curtailing the autonomy of
healthcare providers in executing clinical workflows, and decreasing the entrenchment of their sys-
tems. In short, while before the third developmental trajectory RegSEMR and RegInterop depended
upon providers’ systems, in the third development trajectory they will be moved to a single platform
(RegEHR) and care providers’ systems will become dependent upon RegEHR (see Figure 4).

Care providers DoH & CatSalut Care providers DoH & CatSalut

eCAP and 
RegEHR
HIS other EMRs RegSEMR HIS Interfaces (API, 
(shared 
homologation)
(primary  care) business 
processes, 
common data 
Other systems (PACS,  Other systems (PACS,  model)
radiology, pharmacy,  RegInterop radiology, pharmacy,  eCAP
operating room operating room

Without RegEHR (1st trajectory) With RegEHR (3rd trajectory)

Figure 4. Architectural changes resulting from the 3rd trajectory.

This third trajectory is a complex one since reducing the degree of generative entrenchment of provid-
ers’ systems is hard and severe given its potential negative effects –e.g., a malfunction of RegEHR can
collapse the healthcare system given providers’ dependence on RegEHR for their operation. We iden-
tify several architectural and governance measures and decisions that help deal with that complexity.
First, the design of RegEHR started from primary care, which is the gatekeeper and responsible for
coordinating patients’ care along the care continuum. As a manager of a hospital notes, “In the design
of [RegEHR] we must have the ability to use two different logics at the same time. On the one hand, it
makes sense to transfer to the common data repository as soon as possible the huge volume of infor-

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 10
Platformization as Generative Entrenchment

mation that the hospitals are sending ... On the other hand, the conceptual design of the repository
must start from primary care, without forgetting the functionality that hospitals will need”.
Second, by the end of 2017 eCAP becomes an application of (and managed by) the CatSalut instead of
the ICS. This will push all care providers to adopt eCAP as their EMR for primary care. Under this
new organizational dependency, eCAP is redesigned to have a unique version with a modular architec-
ture6 and a set of services accessible through an API. With such a modular architecture providers can
interconnect their HIS and other systems’ (e.g., pharmacy, nursing, operating rooms) with eCAP
through the latter’s API.
Third, connected with the previous two measures, the new version of eCAP (the reference EMR for
primary care) will be a native application of RegEHR (see Figure 4). Therefore, as all care providers
adopt eCAP, integration with RegEHR will be something natural, not an issue, since the database of
eCAP will be that of RegEHR. An IT manager of a hospital and member of the team that designed
RegSEMR and RegPHR notes, “if eCAP will be the only and common EMR for primary care and will
contain all the data, then you have already the common thread for all the data, and you don’t need
RegSEMR anymore… From my hospital [and from my HIS] in order to access data from another hos-
pital I will go through eCAP… So, eCAP will allow the connection between systems”.
Fourth, the DoH has set up a homologation plan for providers’ HIS. The plan defines the requirements
that those HIS have to fulfil to be compatible and integrate with RegEHR; this measure will homoge-
nize the functionalities of HIS and reduce their variety7.

6 Discussion
Our study contributes to the research stream that studies the formation and evolution of digital plat-
forms and infrastructures from the perspective of the installed base (Aanestad et al. 2017; Grisot et al.
2014; Hanseth and Lyytinen 2010; Monteiro 1998; Rodon and Silva 2015). We analyse platformiza-
tion in terms of generative entrenchment, and in line with prior studies, we depict platformization as
roughly cumulative. Our account shows that in the first two developmental trajectories (integration
and reprogramming, see Figure 3) what characterizes the platformization of the Catalan healthcare is a
process of accretion (Wimsatt and Griesemer 2007). That is, a gradual accumulation of layers that ex-
tend the functionalities and scope of care providers’ systems and the shared regional electronic medi-
cal record (RegSEMR), and in doing so, increase their generative entrenchment. Both entities became
the basis for the first two developmental trajectories that in turn, increased the entrenchment of the
former. In other words, the deep entrenchment of providers’ systems and RegSEMR and the fact that
the new platform initiatives were friendly with that installed base (Aanestad et al. 2017) helped their
bootstrapping (Hanseth and Lyytinen 2010).
On the other hand, the third development trajectory also relies on the installed base but in a way that is
more hostile to it (Aanestad et al. 2017). As presented in the analysis section, the third developmental
trajectory entails reducing the entrenchment of providers’ systems and the platforms that depended
upon them and entrenching a new platform (RegEHR). We have identified two main architectural
measures for reducing such entrenchment. The first measure includes: (1) moving some functionalities
(related to primary care) into the core of the platform –e.g., eCAP was turn into a native application of
RegEHR; and (2) developing a common data and process models at the platform core. This measure
promotes the entrenchment and hence stability of RegEHR by shifting the pre-existing dependencies
of providers’ systems and other platforms. While in the first and second trajectories the platforms
(e.g., RegSEMR, RegInter, RegPHR) were dependent upon providers’ systems, in the third develop-

6Previously, eCAP had multiple versions with an integrated architecture, thus having high maintenance costs and low adapt-
ability.
7The variety of HIS has reflected the historical autonomy of healthcare providers at the expense of DoH and CatSalut’s ina-
bility to shape the activity of healthcare providers.

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 11
Platformization as Generative Entrenchment

mental trajectory providers’ systems become dependent upon the new platform (RegEHR). Hence,
RegEHR becomes installed base for any new developments (Aanestad et al. 2017). The second meas-
ure involves modularizing the architecture of eCAP and building two main interfaces (an API and an
homologation plan) to favour the adaptation and integration of providers’ other systems with eCAP
thus reducing the interdependencies between both. So while the first measure deals with the depend-
encies of the new platform upon the installed base, the second measure deals with the interdependen-
cies between components of the installed base.
Our findings show, in line with prior platform studies (deReuver et al. 2017; Tiwana 2014), that the
developmental trajectories are closely related to the platform architecture. For instance, while the first
trajectory is about infrastructuring (Plantin et al. 2018) or meshworking (Rodon and Silva 2015) –i.e.,
linking heterogeneous systems and prioritizing interoperability standards–, the second and third trajec-
tories represent the platformization of an infrastructure (de Reuver et al. 2017; Plantin et al. 2018).
The process described in second developmental trajectory resonates with the notion resourcing
(Ghazawneh and Hendridsson 2013) –i.e., enhancing the scope and diversity of RegSEMR and
RegPHR. The third trajectory is more about building a programmable platform core that consolidates
and integrates all the relevant data (rather than prioritize interoperability) and that allows the entities at
the periphery to interconnect through APIs (controlled by the DoH).
IS literature has also suggested that the tension between change and stability that characterizes the ar-
chitectural arrangements of platforms and infrastructures must be balanced (Bygstad and Hanseth
2016; Lyytinen et al. 2017; Tilson et al. 2010). Bygstad and Hanseth (2016) recommend a simple heu-
ristic: standardize stable elements “to hinder unproductive variety” (p.15). In the third development
trajectory of our case, we show that the variety of care providers’ systems is reduced by moving some
of their functionalities into the core of RegEHR and creating two main boundary resources
(Ghazawneh and Hendridsson 2013): an API and a homologation plan for care providers. Bygstad and
Hanseth (2016) then propose the principle: “stable elements should be integrated and governed top-
down. Unstable elements should be allowed local governance, with loose coupling” (p. 15). In our
case, there is a mixture of integrated (tight-coupling of eCAP and RegEHR) and modular architecture
(of the eCAP application) because RegEHR must not only provide stability but also be the foundation
for existing applications to build on and extend the same platform in the future. Yet, based on our re-
sults we suggest that besides differentiating between stable and unstable elements (Bygstad and
Hanseth 2016), there is also a need to consider the dependencies of new platforms upon the installed
base and the changes in those dependencies that are envisaged. While in the two first developmental
trajectories platforms are built upon the installed base of care providers’ systems and the dependency
of the former upon the latter is maintained, the third trajectory involves building upon the installed
base and at the same time reverting that dependency (i.e., reducing the dependency of the new plat-
form upon the providers’ systems). In that respect, the third developmental trajectory entails a trans-
formation of public healthcare in Catalonia as it will become platform dependent. In particular, the
organization and delivery of public healthcare services will be strongly guided by the logic embedded
in the RegEHR platform.
We acknowledge the existence particularly in the last ten years, of three contextual conditions that
may have influenced the platformization of the Catalan healthcare system. The first two contextual
conditions are the economic crisis from 2009 to 2014, and the political instability related with the in-
dependence movement particularly from 2014 onwards. For instance, both conditions have caused the
delay of existing projects and aborted new ones (particularly, the ones related with the second devel-
opmental trajectory) due to budget constraints. The third condition relates with the lack of an execu-
tive IT unit at the DoH or the CatSalut through the period of our analysis. This condition can help ex-
plain the pace of projects and the fact that historically all the projects have been installed base-friendly
(Aanestad et al. 2017). Despite the impact of these contextual conditions, we consider that including
them in our analysis would have not changed the identification of the three developmental trajectories
and the role of generative entrenchment in the platformization of the healthcare system.

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 12
Platformization as Generative Entrenchment

7 Conclusions
This paper has studied the platformization of a public healthcare system in relation to the role and dy-
namics of the installed base. By doing so, we have addressed recent calls for further research on the
process of platformization (de Reuver et al. 2017). We have analysed platformization in terms of gen-
erative entrenchment, and identified three developmental trajectories. This has enabled us to show: (1)
how the installed base has downstream enabling and constraining consequences on the formation of
new platforms and these in turn, feedback on the same installed base; (2) how the installed base has
parts with larger and more pervasive effects, and hence, the elements of the installed base are pre-
served differently; and (3) how the interdependencies between elements of the installed base and the
dependencies of new platforms upon the installed base (i.e., the degree of entrenchment) change over
time.

References
Aanestad, M., Grisot, M., Hanseth, O., & Vassilakopoulou, P. (2017). Information Infrastructures
within European Health Care: Working with the Installed Base. Springer.
Aue, G, Biesdort, S, Henke, N. (2016) How healthcare systems can become digital-health leaders.
Mckinsey & Company. http://www.mckinsey.com/industries/healthcare-systems-and-services/our-
insights/how-healthcare-systems-can-become-digital-health-leaders
Benedict, M., Herrmann, H. and Esswein, W. (2018) “eHealth-Platforms - the Case of Europe”, Medi-
cal Informatics Europe 2018, Studies in health technology and informatics 247.
Bratton, B. (2016) “The Stack: On Software and Sovereignty”. MIT Press.
Bygstad, B. and Hanseth, O. (2016) “Governing e-Health Infrastructures: Dealing with Tensions”, 37th
International Conference on Information Systems, Dublin, pp. 1-19.
de Reuver, M., Sørensen, C. and Basole, R.C. (2017) “The digital platform: A research agenda”, Jour-
nal of Information Technology, https://doi.org/10.1057/s41265-016-0033-3.
Ghazawneh, A. and Henfridsson, O. (2013) “Balancing platform control and external contribution in
third-party development: the boundary resources model,” Information Systems Journal, (23:2), pp.
173–192.
Grisot, M., Hanseth, O. and Thorseng, A.A. (2014) “Innovation Of, In, On Infrastructures: Articulat-
ing the Role of Architecture in Information Infrastructure Evolution”, Journal of the Association
for Information Systems, 15(April), pp. 197-219.
Hanseth, O. and Lyytinen, K (2010) “Design theory for dynamic complexity in information infrastruc-
tures: the case of building internet”, Journal of Information Technology, 25(1), pp. 1–19.
Helmond, A. (2015) “The platformization of the Web: Making Web Data Platform Ready”, Social
Media + Society, 1(2) pp. 1-11.
Lyytinen, K., Sørensen, C. and Tilson, D. (2017) “The Generativity of Digital Infrastructures: A Re-
search Note”, in R. D. Galliers and M-K. Stein eds., The Routledge Companion to Management In-
formation Systems, Routledge.
Monteiro, E. (1998) “Scaling information infrastructure: the case of the next generation IP in Inter-
net”, The Information Society, 14 (3), pp. 229–245.
Plantin, J-C., Lagoze, C., Edwards, P.N. and Sandwig, C. (2018) “Infrastructure studies meet platform
studies in the age of Google and Facebook”, New Media & Society, 20(1), pp. 293-310
Rodon, J. and Silva, L. (2015) “Exploring the formation of a healthcare information infrastructure:
Hierarchy or meshwork?”, Journal of the Association for Information Systems, 16(5), pp. 394-417.
Rodon, J (2017) “Navigating towards self-care: The Catalan public patient portal,” in Aanestad, M.,
Grisot, M., Hanseth, O., and Vassilakopoulou, P. eds. Information Infrastructures within European
Health Care: Working with the Installed Base. Springer, pp. 173-192.
Tilson, D., Lyytinen, K., and Sorensen, C. (2010). “Research commentary -- Digital infrastructures:
The missing IS research agenda,” Information Systems Research (21)4, pp. 748–759.

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 13
 Platformization as Generative Entrenchment

Tiwana, A. 2014. Platform Ecosystems: Aligning Architecture, Governance, and Strategy, Waltham,
MA: Morgan Kaufmann
Williams, A. (2015). “Control Societies and Platform Logic”, New Formations, 84/85, pp. 209-227.
Wimsatt, W.C. (2007) “Robustness and Entrenchment: How the Contingent Becomes Necessary”, in
William C. Wimsatt eds., Re-engineering Philosophy for Limited Beings: Piecewise Approxima-
tions to Reality, Harvard University Press, pp.133-145.
Wimsatt, W.C. (2013a). “Entrenchment and scaffolding: an architecture for a theory of cultural
change,” in L. Caporael, J. Griesemer and W. Wimsatt, eds., Developing scaffolding in evolution,
cognition and culture, MIT Press, pp. 77-105.
Wimsatt, W.C. (2013b). “The role of generative entrenchment and robustness in the evolution of com-
plexity”, in Charles H. Lineweaver, Paul C. W. Davies and Michael Ruse, eds., Complexity and the
Arrow of Time, Cambridge University Press, pp. 308-331.
Wimsatt, W. C. and J. R. Griesemer, 2007, “Reproducing Entrenchments to Scaffold Culture: The
Central Role of Development in Cultural Evolution,” Chapter 7 in Roger Sansom and Robert Bran-
don (eds.), Integrating Evolution and Development: From Theory to Practice, Cambridge: MIT
Press, 227-323
Yin, R. K. 2009. Case Study Research: Design and Methods, Thousand Oaks, CA: Sage
Yoo, Y., Henfridsson, O. and Lyytinen, K. (2010) “The New Organizing Logic of Digital Innovation:
An Agenda for Information Systems Research,” Information Systems Research, 21(4), pp.724-735.

Pre-ECIS 2018 Workshop on ”Platformization of the Public Sector”, Portsmouth, UK, 2018 14
View publication stats